DE69721038T2

DE69721038T2 - Transaktionssystem

Info

Publication number: DE69721038T2
Application number: DE69721038T
Authority: DE
Inventors: Jake Woodbridge HILL
Original assignee: British Telecommunications PLC
Current assignee: British Telecommunications PLC
Priority date: 1996-11-20
Filing date: 1997-11-12
Publication date: 2004-02-12
Anticipated expiration: 2017-11-13
Also published as: EP0941524A1; JP2001504612A; US6236981B1; WO1998022915A1; AU4957197A; EP0941524B1; DE69721038D1; GB9624127D0

Description

Die vorliegende Erfindung betrifft ein digitales Zahlungstransaktionssystem.
Mit dem Anwachsen und der Kommerzialisierung des Internet gab es einen steigenden Bedarf an Technologien, die die Online-Ausführung von Zahlungen ermöglichen. Für Transaktionen mit verhältnismäßig großem finanziellen Wert ist dieser Bedarf adäquat erfüllt, z. B. durch Systeme, die elektronische Schecks verwenden, die durch eine vertrauenswürdige Seite, wie etwa eine Bank, ausgegeben werden. Diese elektronischen Schecks werden typischerweise durch eine Signatur für gültig erklärt, die unter Verwendung eines öffentlichen Schlüsselalgorithmus, wie etwa RSA, verschlüsselt wird. Es gibt jedoch einen bedeutenden rechentechnischen Aufwand, der mit der Verwendung dieser Algorithmen verbunden ist. Da im reellen Leben ein Scheck wegen der zugehörigen Transaktionskosten wahrscheinlich nicht für die Bezahlung eines geringen Werts akzeptiert wird, sind deshalb auch im elektronischen Handelsverkehr elektronische Schecks nicht für die Bezahlung eines geringen Werts geeignet.
Es wurden mehrere Vorschläge für alternative Transaktionssysteme gemacht, die für die Ausführung der sogenannten "Mikrozahlungen" geeignet sind, die für geringwertige Transaktionen erforderlich sind. Es hat sich jedoch als technisch schwierig herausgestellt, eine Technik für den geringen Verarbeitungsaufwand zu schaffen, die für eine Technologie der Mikrozahlungen erforderlich ist, während gleichzeitig ein adäquater Sicherheitspegel eingehalten wird.
Ein Beispiel eines früheren Vorschlags für ein Mikrozahlungssystem ist der, der durch die US-Gesellschaft "Digital" entwickelt wurde und als "Millicent" bekannt ist. Dieses System wird von seinen Entwick lern als ein einfaches Protokoll beschrieben, das für die Unterstützung von Einkäufen geeignet ist, die weniger als einen Cent kosten. Es basiert auf der dezentralisierten Validation von elektronischem Geld auf dem Server des Verkäufers. Die digitalen Zahlungsmünzen werden in diesem System als "Scrip" bezeichnet. Sie werden von einem zentralen Zahlungsdienst als Gegenleistung für eine Vorauszahlung ausgegeben, die unter Verwendung eines herkömmlichen Zahlungsverfahrens, wie etwa eine Kreditkarte, erfolgt. Der Verkäufer kann dann Scrips vom Anwender bei der Bezahlung von Waren oder typischerweise von Dienstleistungen annehmen. Der Verkäufer erzeugt neue Scrips und gibt sie an den Anwender als Wechselgeld für die Transaktion aus. Der Scrip wird authentifiziert und vom Verkäufer werden neue Scrips unter Verwendung einer Kontrollsummenfunktion erzeugt. Das stellt eine potentielle Sicherheits-Schwachstelle dar, da dann, wenn die Kontrollsummenfunktion geknackt wird, der Scrip für Fälschung und Duplikation offen wäre. Darüber hinaus gibt es einen Verarbeitungsaufwand, der mit der Verwendung der Kontrollsummenfunktion durch den Verkäufer verbunden ist. Obwohl dieser Aufwand geringer ist als der Aufwand, der z. B. mit der Verwendung einer PGP-verschlüsselten Signatur verbunden ist, stellt er trotzdem eine bedeutende Einschränkung dar. Durch die Entwickler des Millicent-Systems wird zugelassen, daß als Folge seiner begrenzten Effektivität eine praktische untere Begrenzung der Transaktionswerte, die behandelt werden können, vorhanden ist. Es wird vorgeschlagen, daß diese untere Begrenzung bei etwa 1/10 Cent liegt. Millicent ist deswegen nicht für die Verwendung z. B. als ein Mechanismus zur Gebührenberechnung für die Internetbenutzung geeignet. Die Kosten einer Paketübertragung im Internet wurden auf etwa 1/600 Cent geschätzt.
Die europäische Patentanmeldung EP-A-0 507 669 offenbart ein Beispiel eines anderen Typs des Zahlungssystems, das auf der Smartcard-Technologie basiert. Anstatt auf die kryptographische Sicherheit zu vertrauen, basiert hier die Sicherheit auf der physikalischen Integrität der Karte. Eine zufällig ausgewählte Untermenge einer Anzahl von Münzwerten wird zurückgehalten, so daß das Vorhandensein von einer der zurückgehaltenen Münzwerte in einer späteren Transaktion als eine Anzeige einer versuchten Fälschung dienen kann. Die Menge der Münzen, die an eine bestimmte Karte ausgegeben werden, ist nicht statistisch zufällig, sondern sie können z. B. alle in einen begrenzten Bereich von numerischen Werten fallen und sie können in eine Folge geordnet werden, die durch ihre numerischen Werte bestimmt wird.
Gemäß einem ersten Aspekt der vorliegenden Erfindung wird ein Verfahren zum Betreiben eines digitalen Zahlungstransaktionssystems geschaffen, das umfaßt

a) Speichern einer Folge von Zufallszahlen in einem Zahlungsserver;
b) Ausgeben einer Menge digitaler Zahlungsmünzen, die eine Folge digital codierter Zufallszahlen enthalten, an einen Anwender;
c) Übertragen einer Zahlungsmünze von einem Anwender an eine Handelsplattform;
d) Übertragen der von dem Anwender im Schritt c) empfangenen Zahlungsmünze von der Handelsplattform an den Zahlungsserver;
e) Authentifizieren der Münze bei dem Zahlungsserver durch Vergleichen des Werts der Zufallszahl der Münze von der Handelplattform mit einem Wert, der von einer entsprechenden Position in der gespeicherten Folge aus Zufallszahlen abgeleitet wird; und
f) anschließendes Senden einer Authentifizierungsnachrichtung von dem Zahlungsserver zu der Handelsplattform, wobei das Verfahren gekennzeichnet ist durch den folgenden Schritt:
g) Ableiten der Menge digitaler Zahlungsmünzen aus der gespeicherten Folge von Zufallszahlen durch Auswählen eines Teils der gespeicherten Folge und Codieren des Teils der gespeicherten Folge mit einem für den Anwender spezifischen Schlüssel.

Die vorliegende Erfindung schafft ein digitales Zahlungstransaktionssystem, das eine verbesserte Effektivität und Sicherheit bietet, und das für die Ausführung von Mikrozahlungen geeignet ist, die Zahlungen mit sehr geringem Wert enthalten. Das wird erreicht, indem ein "Carnet" oder eine Menge von digitalen Zahlungsmünzen, die eine Menge von Zufallszahlen in einer vorgegebenen Folge umfassen, ausgegeben wird. Die Zahlen in der Folge sind untereinander vollkommen ohne Beziehung und es gibt keine Korrelation zwischen dem numerischen Wert einer Münze und ihrer Position in der Folge. Das ist der Unterschied zu Vorschlägen des Standes der Technik, bei denen die Münzen untereinander durch kryptographische Transformationen in Beziehung stehen. Die Münzen werden für gültig erklärt, indem sie zum Zahlungsserver geleitet werden, wo die Münze mit der entsprechenden Zahl in der im Server gespeicherten zufälligen Folge verglichen wird. Auf diese Weise bietet das System einen hohen Pegel der kryptographischen Sicherheit, wobei der Verarbeitungsaufwand vom Verkäufer vollständig weggenommen wird.
Das Erzeugen des Carnets durch das Verschlüsseln eines Teils der Zufallsfolge unter Verwendung eines für den Anwender spezifischen Schlüssels stellt sicher, daß die geforderte Länge der Zufallszahlfolge und die zugehörige Speichereinrichtung, die im Zahlungsserver benötigt wird, in akzeptabler Weise ansteigt, wenn sich die Anzahl der Anwender vergrößert. Gleichzeitig wird die Sicherheit des Verfahrens durch die Verschlüsselung mit dem Anwenderschlüssel weiter verbessert.
In der Beschreibung und in den Ansprüchen wird der Term "zufällig" so verwendet, daß er sowohl echte Zufallszahlen als auch Pseudo-Zufallszahlen umfaßt, die innerhalb eines erforderlichen Grads der Genauigkeit die statistischen Eigenschaften einer echten Zufallsfolge erfüllen.
Der Zahlungsserver befindet sich vorzugsweise in einer Entfernung von der Handelsplattform und die Handelsplattform kommuniziert über ein Kommunikationsnetz mit dem Zahlungsserver. Der Anwender, der Händler und der Zahlungsserver sind typischerweise durch Internetverbindungen miteinander verbunden, obwohl das nicht notwendigerweise der Fall ist.
Der Teil der Folge wird vorzugsweise durch einen symmetrischen Blockverschlüsselungsschlüssel codiert. Das ist bevorzugt, da der höchste Grad der Sicherheit erreicht wird. Alternativ kann in Anwendungsbereichen, bei denen es wichtiger ist, den mit der Erzeugung des Carnets verbundenen rechentechnischen Aufwand zu vermindern, eine verschlüsselte Kontrollsummenfunktion verwendet werden. Es ist klar, daß im Unterschied zum oben erläuterten Millicent-Vorschlag die Kontrollsumme lediglich im Zahlungsserver verwendet wird, um die Münzwerte aus der gespeicherten zufälligen Zahlenfolge zu erzeugen und nicht die Beziehung zwischen den verschiedenen Zahlen im Carnet bestimmt. Die Sicherheit des Systems beruht deswegen nicht allein auf der Integrität der Kontrollsummenfunktion.
Vorzugsweise im Schritt (d) des Verfahrens sendet der Händler zusammen mit der Zahlungsmünze eine Authentifizierungsmünze aus einer Folge von von dem Zahlungsserver ausgegebenen Authentifizierungsmünzen.
Obwohl es typischerweise ein größeres Vertrauen zwischen dem Verkäufer und dem Zahlungsserver gibt, besteht trotzdem ein Bedarf, eine Sicherheit für die Transaktionen zwischen diesen beiden Parteien zu schaffen. In der bevorzugten Implementierung der vorliegenden Erfindung besteht eine besonders effektive Lösung darin, den selben Mechanismus zu verwenden, der verwendet wird, um die eigentlichen Zahlungsmünzen zu erzeugen. Anschließend gibt der Zahlungsserver eine Folge von Authentifizierungsmünzen an den Händler aus. Diese Authentifizierungsmünzen können aus der Folge von Zufallszahlen in der gleichen Weise abgeleitet werden wie die Zahlungsmünzen. Der Händler kann dann Paare aus Zahlungsmünzen und Authentifizierungsmünzen an den Zahlungsserver zur Authentifizierung zurückleiten. Der Zahlungsserver kann dann einen Händlerkonten-Datensatz nach der Authentifizierung einer für gültig erklärten Zahlungsmünze und einer Authentifizierungsmünze, die von der Handelsplattform empfangen werden, automatisch aktualisieren.
Der Schritt des Authentifizierens der digitalen Zahlungsmünze umfaßt vorzugsweise:

I) Versuchen, die digitale Zahlungsmünze in Gegenüberstellung mit einem Wert an einer Position in der im Zahlungsserver gespeicherten Folge von Zufallszahlen zu authentifizieren; und
II) wenn die Münze im Schritt I) nicht authentifiziert wird, Versuchen, die digitale Zahlungsmünze in Gegenüberstellung mit einem der mehreren anderen Werte in der gespeicherten Folge zu authentifizieren, wobei die anderen Werte innerhalb eines vorgegebenen maximalen Abstandes von dieser Position liegen;

Der zugrundeliegende Zahlungsmechanismus nimmt an, daß der Anwender und der Zahlungsserver ihre Folgen von gespeicherten Zufallszahlen schrittweise durchgehen. Manchmal können jedoch Münzen an der Zahlungsstelle außer der Reihe eintreffen, da z. B. ein Händler bei der Übertragung von Münzen zum Löschen langsamer ist als ein anderer. Dieses Merkmal der Erfindung ermöglicht, daß das System unter diesen Umständen robust funktioniert. Anstatt lediglich die nächste Position in der Folge gespeicherter Zufallszahlen im Zahlungsserver zu überprüfen, wird ein gleitendes Fenster verwendet, um einen Bereich (in Bezug auf die Folgeposition) von gespeicherten Zufallszahlen auszuwählen. Eine übertragene Münze kann erfolgreich für gültig erklärt werden in Gegenüberstellung mit einem gespeicherten Wert, der in dem Fenster liegt (vorausgesetzt, daß der gespeicherte Wert nicht zuvor verwendet wurde).
Das Verfahren umfaßt vorzugsweise ferner:

h) Halten eines Datensatzes über den momentanen Zustand der Menge digitaler Zahlungsmünzen in dem Zahlungsserver; und
i) wenn die an den Anwender ausgegebenen digitalen Zahlungsmünzen verloren oder verfälscht sind, Senden von Daten von dem Zahlungsserver zum Anwender und dadurch Aktualisieren der Menge digitaler Zahlungsmünzen auf einen Zustand, der jenem entspricht, der in dem Zahlungsserver aufgezeichnet ist.

Ein weiterer bedeutender Vorteil, der durch bevorzugte Implementierungen der Erfindung geboten wird, besteht darin, daß das Carnet, wenn es zerstört oder gestohlen ist, durch den Zahlungsserver erneut erzeugt werden kann.
Das Verfahren umfaßt vorzugsweise ferner:
Ausgeben einer Identifizierungsnummer (PIN) an den Anwender;
Modifizieren der aus der gespeicherten Folge von Zufallszahlen abgeleiteten Zahlen unter Verwendung der Identifizierungsnummer;
und weiterhin Modifizieren der digitalen Zahlungsmünze, die im Schritt (c) an den Händler übertragen wird, unter Verwendung der Identifizierungsnummer.
Dieses bevorzugte Merkmal erhöht die Sicherheit des Systems weiter, ohne den Verarbeitungsaufwand an der Händlerplattform wesentlich zu vergrößern.
Im Schritt des Modifizierens der digitalen Zahlungsmünze wird der digital codierte Wert, der vom Zahlungsserver ausgegeben wird, vorzugsweise mit der Identifizierungsnummer unter Verwendung einer Booleschen Logikoperation kombiniert und das Ergebnis dieser Operation wird als modifizierte digitale Zahlungsmünze ausgegeben. Diese binäre Logikoperation ist vorzugsweise eine Exklusiv-ODER-Verknüpfung.
Die Erfindung umfaßt außerdem Handelsplattformen, Client-Plattformen und Zahlungsserver zur Verwendung in den Verfahren der ersten und zweiten Aspekte der Erfindung sowie Netze, die diese Vorrichtungen enthalten. In dem unten beschriebenen Beispiel ist die Client-Plattform ein Personalcomputer, auf dem ein Web-Browser läuft. Weitere Beispiele von Client-Plattformen enthalten Smartcards und Personal-Digitalassistenten (PDAs).
Es werden nun Systeme, die die vorliegende Erfindung ausführen, lediglich beispielhaft unter Bezugnahme auf die beigefügte Zeichnung genauer beschrieben, in der:
1 eine schematische Darstellung ist, die die Hauptkomponenten des Zahlungssystems zeigt;
2 ein Ablaufplan ist, der die Hauptausführungsschleife des Zahlungsdienst-Freigabemoduls zeigt;
3 ein Ablaufplan ist, der die Hauptausführungsschleife des Händlermoduls zeigt;
4 ein Ablaufplan ist, der den Vorgang zum Verifizieren von Münzen zeigt, die vom Zahlungsdienst empfangen werden;
5 ein Ablaufplan ist, der das Aktualisierungsmodul zeigt, das verwendet wird, um eine Client- oder Händler-Münzendatenbank wiederherzustellen;
6 ein Ablaufplan ist, der das Sammelmodul beim Händler zeigt;
7 ein Ablaufplan ist, der das Zahleinrichtungs-Modul im Carnet zeigt;
8 eine schematische Darstellung eines Netzes ist, das die vorlie gende Erfindung ausführt;
9 eine schematische Darstellung einer alternativen Ausführungsform ist; und
10 den Betrieb des Zahlungsdienstes unter Verwendung eines gleitenden Fensters darstellt.
Wie in 8 gezeigt ist, ist ein Client-Terminal 1, das in diesem Beispiel ein Personalcomputer ist, über ein Modem 2 und das PSDN (öffentliches Fernsprechwählnetz) 3 mit einem Internet-Serviceprovider (ISP) 4 verbunden. Über das Internet baut das Client-Terminal zu verschiedenen Zeiten Verbindungen zu einem Zahlungsserver 6 (der hier auch als "Zahlungsdienst" bezeichnet ist) und zu einem Online-Händler 5 auf. Der Händler 5 bietet als Gegenleistung für eine Zahlung eine Dienstleistung an. Der Händler kann z. B. HTTP-Seiten (Hypertext Transfer Protocol) von personengebundenen Nachrichten zu einer geringen festen Gebühr pro Seite anbieten. Der Händler kann alternativ z. B. einen Knoten 5a steuern, der den Zugang zu einer schnellen Internetverbindung schafft. Der Zugang zu dem Knoten kann dem Anwender zu einer Gebühr zur Verfügung gestellt werden, die z. B. auf Grundlage der Zeitdauer, während der der Anwender verbunden ist, berechnet wird. Zahlungsmünzen können vom Anwender in regelmäßigen Intervallen gefordert werden oder eine Zahlungsmünze kann bei jedem Paket, das den Knoten passiert, eingezogen werden. Das Zahlungssystem, das die vorliegende Erfindung ausführt, wird von dem Erfinder als "QuickPay" bezeichnet.
Im Gebrauch wird ein Modul, das als "Carnet"-Modul bezeichnet wird, im Client-Terminal installiert. Dieses Modul, das später ge nauer beschrieben wird, enthält Programme, die die Wechselwirkungen zwischen dem Händler und dem Zahlungsdienst unterstützen. Das Terminal speichert außerdem Daten, die alle Zahlungsmünzen betreffen, die momentan durch den Anwender gehalten werden.
Anfangs stellt der Anwender eine Internetverbindung mit dem Zahlungsdienst her und kauft Münzen für einen bestimmten Wert. Diese Transaktion kann z. B. ausgeführt werden, indem vom Client zum Zahlungsdienst eine Anforderung nach Münzen für einen bestimmten Wert, z. B. 10 Pfund, gemeinsam mit einer Kreditkartennummer gesendet wird. Diese Nummer kann unter Verwendung eines von mehreren Verschlüsselungswerkzeugen mit öffentlichem Schlüssel, wie etwa PGP, verschlüsselt werden. Der Zahlungsdienst bucht die betreffende Summe vom Kreditkartenkonto ab und erzeugt eine Anzahl von Zahlungsmünzen, z. B. 1000 Münzen zum Wert von 1p. Diese werden unter Verwendung des Algorithmus mit öffentlichem Schlüssel verschlüsselt und über die Internetverbindung zusammen mit einem einmaligen Schlüssel an den Anwender zurückgeleitet. Jede Münze umfaßt in diesem Beispiel eine 64 Bit-Zufallshexamalzahl, die im Zahlungsdienst aus einer großen Liste von n Zufallszahlen R = r0, r1, r2, ..., rn – 2, rn – 1) entnommen werden. Für jeden Anwender bewahrt der Zahlungsdienst zwei Teile einer geheimen Information k und s auf. k ist ein Zufallsschlüssel zur Verwendung mit einem symmetrischen Blockverschlüsselungsschlüssel. s ist ein zufälliger Sicherheitsparameter, wobei (0) ≤ s ≤ n – 1) gilt, der aus einem Bereich (0 ... n) zufällig entnommen ist. Es gibt außerdem eine ganzzahlige Indexvariable i. Ihre Geheimhaltung ist nicht wesentlich, obwohl ihre Integrität wichtig ist.
Das Carnet, das im Client-Terminal gespeichert wird, hält eine Liste von m Zufallszahlen T = (t1, t2, t3, ..., tm – 1, tm), wobei (m << n). Die unten aufgeführte Tabelle 1 zeigt einen Teil der Liste der Zufallszahlen, die im Carnet gehalten wird. Der Zahlungsdienst leitet T von R ab, wenn sich der Anwender registriert. T ist eine verschlüsselte Untermenge von R, so daß gilt:
tx = E(k, r(s+xmodn))
wobei E (a, b) die Verschlüsselung von b unter Verwendung des Schlüssel a angibt. Die Variable i wird zu diesem Zeitpunkt auf 0 initialisiert. Das Carnet enthält außerdem eine Kopie dieser Variable.
Um eine einzelne Mikrozahlung auszuführen, sendet der Anwender ti (die I-te Zahlungsmünze) an den Zahlungsdienst. Der Zahlungsdienst führt eine Prüfung aus, um sicherzustellen, daß gilt:
D(k, ti) = rs+imodn
und die Zahlung wird erfolgreich ausgeführt. Der Carnet und der Zahlungsdienst erhöhen beide ihre Kopien von i.
Anschließend stellt der Anwender eine Internetverwendung mit dem Händler her. Dies kann z. B. dazu dienen, um HTML-Seiten von Informationen zu gewinnen, die durch den Händler unter Verwendung einer Suchmaschine und Suchkriterien, die zuvor durch den Anwender festgelegt wurden, gewonnen wurden. Als Reaktion auf eine Anforderung zum Herunterladen der HTML-Seiten fordert der Händler die Zahlung von z. B. 10p. Die Zurückleitung der Zahlungsaufforderung wird typischerweise unter Verwendung von CGI-Scripts, die auf dem HTML-Server beim Händler laufen, automatisch ausgeführt.
Als Antwort auf die Anforderung vom Händler gibt der Anwender die zehnte Münze vom Carnet aus. Da die Münzen in einer bestimmten Folge sind, ist es ausreichend, z. B. gerade die zehnte Münze zu senden, anstelle aller zehn Münzen, die gefordert wurden, um die Zahlung vollständig zu machen. Diese Münze wird durch das Carnet-Modul durch eine Exklusiv-ODER-Operation mit einer PIN modifiziert, die der Anwender am Terminal eingeben muß, um die Ausgabe von Münzen zu autorisieren. Die modifizierte Münze wird dann auf der Internetverbindung zum Händler übertragen.
Der Händler besitzt eine offene Internetverbindung zum Zahlungsdienst. Wenn die Münzen vom Anwender empfangen werden, sendet der Händler ein Datenpaar zum Zahlungsdienst, das die Zahlungsmünzen gemeinsam mit einer entsprechenden Menge von Authentifizierungsmünzen enthält. Der Händler, der hier auch als der "Third Party Service Provider" TPSP (Diensteanbieter als Drittperson) bezeichnet wird, erhält eine Menge von Authentifizierungsmünzen, die im wesentlichen die gleichen sind, wie die Zahlungsmünzen, die an einen Anwender ausgegeben werden, die jedoch wie einmalige Kennwörter funktionieren. Die Menge der Authentifizierungsmünzen A ist eine verschlüsselte Untermenge von R, so daß gilt
ax = E(k, rs+xmodn)
wobei k ein geheimer Verschlüsselungsschlüssel ist, s ist ein zufälliger Sicherheitsparameter und n ist die Größe der Zufallswert-Datenbank R.
Der TPSP sammelt Zahlungsmünzen ti vom Anwender, wie zuvor beschrieben wurde. Um jede Münze zu verifizieren, leitet der Händler die Münze gemeinsam mit aj (die nächste Authentifizierungsmünze) an den Zahlungsdienst weiter. Der Zahlungsdienst verifiziert, daß sowohl ti als auch aj die erwarteten Werte sind, bevor er eine Bestäti gung zurückleitet. Durch Zählen der (ti, aj)-Paare, die vom Händler erfolgreich übermittelt wurden, besitzt das Zahlungssystem eine Aufzeichnung der Menge, die der Händler schuldet.
Der Zahlungsdienst leitet eine Authentifizierungsmünze in der Authentifizierungsnachricht zurück. Wenn die Zahlungsmünze vom Händler mit der Authentifizierungsmünze aj übermittelt wurde, leitet der Zahlungsserver a(j + 1) zurück, das ist die nächste Authentifizierungsmünze in der Folge, die vom Händler gehalten wird, um anzuzeigen, daß die Authentifizierung erfolgreich war. Der Zahlungsserver kann das Komplement von a(j + 1) senden, um anzugeben, daß die Authentifizierung mißlungen ist.
Die Nachrichten, die vom Anwender, vom Händler und vom Zahlungsserver ausgetauscht werden, sind alle kurz und sind für einen Einschluß z. B. in HTTP- (Hypertext Transfer Protocol) oder MIME-(Multi Purpose Internet Mail Extensions) Kopfinformationen geeignet.
Das bisher beschriebene Zahlungssystem ist potentiell offen für mehrere Fehlertypen. Um diese zu behandeln, sind Mechanismen in dieser Implementierung eingeschlossen.
Es gibt zwei Hauptklassen von wiederherstellbaren Fehlern:

1) Ein Carnet oder eine Indexvariable des Händlermoduls kann mit der Indexvariable des Zahlungsdienstes außer Schritt geraten. Diese Fehler werden durch ein Neu-Synchronisations-Schema behandelt. Wenn eine empfangene Münze nicht ihrem erwarteten Wert entspricht, liest der Zahlungsdienst in der Folge von Zufallszahlen in Vorwärtsrichtung die nächsten Werte und sucht nach einem Wert, der übereinstimmt. Eine Begrenzung des Vorwärtslesens ist als Systemparameter gesetzt. Wenn eine übereinstimmende Münze in dem eingestellten Bereich gefunden wird, akzeptiert das Zahlungssystem die Münze. Es registriert die Anzahl von Münzen, die für jedes Carnet ausgelassen werden. Ein Carnet kann die Münzen später wiederherstellen (z. B. wenn die Anzahl der verbleibenden Münzen klein wird), indem ein Auffrischen durchgeführt wird. Dieses Schema kann wahlweise vervollkommnet werden, indem ein gleitendes Fenster verwendet wird, das den Bereich von Werten definiert, in dem eine Münze bewertet werden kann.
2) Die Liste von Münzen oder die Indexvariable in einem Carnet könnte verloren gehen oder beschädigt werden. Ein Carnet kann aufgefrischt werden, wodurch sein Zustand mit den im Zahlungsdienst gehaltenen Informationen in Übereinstimmung gebracht wird. Wenn ein Carnet neu initialisiert wird, wird eine neue Menge von Zahlungsmünzen für den Anwender zusammengestellt. Die Anzahl von Münzen ist gleich der Anzahl der nicht ausgegebenen Münzen im vorhergehenden Carnet plus die Anzahl von Münzen, die durch Synchronisationsfehler verloren wurden.

Es gibt potentiell einen dritten Typ von Fehlern, der nicht wiederherstellbar ist. Eine Verstümmelung der Informationen des Zahlungsdienstes wäre fatal und muß verhindert werden. Das wird realisiert, indem im Zahlungsdienst eine Redundanz aufgebaut wird, z. B. durch Spiegeln der Daten von einem Zahlungsserver auf einen anderen Server an einer anderen Stelle und durch die Verwendung von robusten Speichertechnologien, wie etwa RAID.
Ein weiteres Merkmal der vorliegenden Implementierung besteht darin, daß jedes Carnet, das an einen Anwender ausgegeben wird, mit einer digitalen Signatur versehen ist. Die Signatur wird in einer herkömmlichen Weise unter Verwendung eines Verschlüsselungsalgorithmus mit öffentlichem Schlüssel gebildet. Es ist insbesondere bevorzugt, daß für diesen Zweck DSA oder eine weitere El-Gammal-Variante verwendet werden sollte. Die digitale Signatur kann dann für Rechtsanspruchentscheidungen verwendet werden. Wenn z. B. der Anwender Münzen kauft, die im Ergebnis eines Systemfehlers nicht ausgegeben werden können, kann der Anwender von der Partei, die das Carnet ausgegeben hat, Ersatz verlangen. Diese Partei kann sicherstellen, daß das Carnet unverfälscht ist, indem überprüft wird, ob die digitale Signatur jene ist, die bei der Ausgabe des Carnets erzeugt wurde.
Es ist klar, daß die obige Anwendung der QuickPay-Technologie lediglich beispielhaft beschrieben wurde und die Erfindung in einer großen Vielzahl von unterschiedlichen Zusammenhängen immer dann, wenn ein sicherer und effizienter Zahlungsdienst gefordert wird, verwendet werden kann. Obwohl die Erfindung wegen der geringen Benachrichtigungskosten spezielle Vorteile im Kontext von Internet-Diensten besitzt, kann sie außerdem in anderen Bereichen verwendet werden. Das Carnet und zugehörige Klienten-Anwendungen könnten in einer Smartcard gespeichert sein, die einen Mikroprozessor und einen nichtflüchtigen Speicher enthält. Auf die Handelsplattform könnte in diesem Fall über einen Kartenleser an einem EPOS Terminal (EPOS, Electronic Point of Sale, elektronischer Verkaufspunkt) zugegriffen werden. 9 zeigt ein derartiges System, bei dem sich das Carnet auf einer Smartcard 901 in einem Kartenleser 902 befindet, der an eine Handelsplattform 903 angeschlossen ist. Die Handelsplattform ist über das PSDN mit dem Zahlungsserver 904 verbunden. Die Karte könnte außerdem verwendet werden, um Telephondienstleistungen über einen Kartenleser zu kaufen, der z. B. an einem öffentlichen Telephon angebracht ist. In diesem Fall können die vorhandenen Telephonnetz-Signalisierungskanäle, wie etwa NUP (National User Part) und ISOP (ISDN User Part) im britischen PSDN, für die Verbindungen zwischen den verschiedenen Plattformen anstelle der TCP/AIP-Signalisierung in dem ersten, obenbeschriebenen Beispiel verwendet werden.
In einem weiteren Beispiel wird QuickPay verwendet, um für die Benutzung des NetSumm-Service von BT zu bezahlen. NetSumm (Handelsmarke) ist ein netzgestütztes Werkzeug zur Textzusammenfassung. Mit ihm können Internetbenutzer Zusammenfassungen von englischsprachigen World Wide Web- (WWW) Dokumenten erzeugen. Auf den Dienst wird über einen Web-Browser zugegriffen.
Der Anwender besucht zunächst die QuickPay-Webseite. Zuerst richtet er ein Konto ein, indem ein Formular ausgefüllt wird, das einen Benutzernamen und ein Kennwort bereitstellt. Der Benutzernamen sollte eine gültige E-Mail-Adresse sein, das Kennwort kann jede Zeichenfolge mit einer Länge bis zu 64 Byte sein. Der Anwender besucht anschließend eine Seite, auf der er ein QuickPay-Carnet kaufen kann. Der Anwender füllt ein weiteres Formular aus, auf dem er den Typ der von ihm verwendeten Plattform und die Größe des geforderten Carnets spezifiziert. Wenn er den "Kaufen"-Knopf anklickt, erzeugt der Zahlungsdienst ein neues QuickPay-Carnet und lädt es zum Client herunter. Der Benutzer installiert dann sein neues Carnet. Er kann den Ort festlegen, an dem der QuickPay-Client installiert wird, und er muß eine PIN angeben, um die Zahlungsmünzen zu schützen. Von der NetSumm-Homepage legt der Benutzer die URL (Uniform Resource Locater, d. h. die Adresse) eines WWW-Dokuments fest, das zusammengefaßt werden soll. NetSumm leitet eine zusammengefaßte Version des Dokuments zurück. Alle Netzverweise im Dokument werden so modifiziert, daß beim Anklicken eine Zusammenfassung des Zieldokuments ausgegeben wird. NetSumm bietet dem Anwender außerdem zusätzliche Steuerungsmöglichkeiten an, damit er die Regeln der Zusammenfassung ändern kann.
Die Verwendung von NetSumm wird pro Zusammenfassung mit 0,002 Pfund (0,2 Pence) berechnet. Jedesmal wenn eine Seite übermittelt wird, berechnet NetSumm dem Benutzer 2 QuickPay-Münzen, bevor das Ergebnis zurückgeleitet wird (der Münzwert beträgt in diesem Beispiel 0,1p). Ein einziger Aufruf an das QuickPay-Händlermodul ermöglicht der NetSumm-Anwendung, diese Münzen anzufordern und ein Ergebnis zu erhalten, das anzeigt, ob die Zahlung erfolgreich war oder nicht. Bevor er NetSumm verwendet, muß der Anwender sein Clientprogramm QuickPay laufen lassen. Das ist eine vom Web-Browser des Anwenders getrennte Anwendung. Sie besitzt ein einzelnes kleines Fenster, das eine optische Anzeige der Anzahl der verbleibenden Münzen gibt. Das Fenster enthält außerdem einige Steuerungsmöglichkeiten, damit der Anwender die Anwendung beenden, die PIN ändern, das Carnet aktualisieren kann usw. Wenn der Anwender versäumt, den Client vor der Benutzung von NetSumm zu starten, erhält er beim Versuch, einen Text zusammenzufassen, eine Fehlerseite vom Dienst. Das erste Mal, wenn der NetSumm-Dienst versucht, Münzen vom QuickPay-Client einzuziehen, wird dem Anwender eine Dialogbox angeboten, die ihn bittet, die Zahlung zu bestätigen. Er muß seine PIN eingeben, um die Zahlungsmünzen freizugeben, und er kann wählen, wie spätere Zahlungsaufforderungen von diesem Händler zu behandeln sind. Wenn der Anwender wählt, daß spätere Zahlungen möglich sind, kann NetSumm zusätzliche Münzen ohne Anwendereingriff einziehen. Alternativ kann der Anwender wählen, jede Anforderung einzeln anzunehmen oder zurückzuweisen. Diese Regeln bleiben bestehen, bis der Anwender die Anwendung des QuickPay-Client schließt.
Wenn der Benutzer seine gelieferten Zahlungsmünzen erschöpft hat, erhält er weitere Münzen, indem er die QuickPay-Webseite besucht, auf der er einem Link zu "Wiederauffüllen Carnet" folgt. Das Wiederauffüllen des Carnets ist sehr ähnlich zum Kauf des ersten Carnets, mit der Ausnahme, daß alle unbenutzten Münzen vom vorherigen Carnet zum neuen Carnet des Anwenders addiert werden. Der Anwender muß seine Authentifizierungsangaben (Benutzername und Kennwort) eingeben, um zusätzliche Münzen zu kaufen. Er muß außerdem Zahlungsangaben liefern (d. h. eine Kreditkartennummer) und den Typ und die Größe des gewünschten Carnets auswählen. Alle nichtbenutzten Münzen vom vorherigen Carnet werden zum neuen Carnet addiert, bevor es ausgeliefert wird und das alte Carnet des Anwenders ungültig wird.
Eine Implementierung der Erfindung wird nun genauer beschrieben.
1 zeigt die hauptsächlichen Softwarekomponenten in dieser Implementierung von QuickPay. Der Zahlungsdienst und das Händlermodul sind Back-End-Anbindungen mit geringer oder keiner Anwender-Wechselwirkung. Diese Komponenten sind in diesem Beispiel als UNIX-Client- und Server-Anwendungen implementiert und sollten auf den meisten UNIX-Plattformen laufen. Das Carnet tritt mit seinem Anwender nicht in Wechselwirkung und kann in einer Vielzahl von Formen auf verschiedenen Typen von Computern implemen tiert sein. Ein typischer UNIX-Client ist hier beschrieben, der auf UNIX-Arbeitsstationen laufen kann, oder er kann als Basis von selbständigen Clients verwendet werden, die an anderen Plattformen angeschlossen sind. Als eine weitere Alternative kann der QuickPay-Client mit anderen Anwendungen integriert sein, z. B. WWW- und E-Mail-Clients.
Zahlungsdienst
Der Zahlungsdienst umfaßt die Löscheinrichtung (Clearer), die Erzeugungseinrichtung (Creator), die Aktualisierungseinrichtung (Updater) und vier Datenbanken.
Datenbanken
Alle vier Datenbanken sind einfache Sammlungen von Aufzeichnungen. In der URD (Benutzerregistrierung-Datenbank) werden die Einträge durch eine alphanumerische Folge (der Benutzername) indexiert. In allen anderen Datenbanken werden die Einträge nacheinander durch eine Zahl indexiert. Es gibt keine Forderung, daß die Zuweisung von Indizes zusammenhängend sein soll. Carnet-IDs (Carnet-Kennungen) werden z. B. als Zufallswerte im Bereich [0 ... 264 – 1 ] zugewiesen und wahrscheinlich ist lediglich ein Bruchteil davon zu einem Zeitpunkt zugewiesen.
Datenbank Anwenderregistrierung
struct {
char passwd[]; /*Password*/
verylong cid; /*Carnet ID*/
}
Die URD hält Informationen über QuickPay-Benutzer. Ihr hauptsächlicher Verwendungszweck ist die Authentifizierung von Benutzern, die administrative Funktionen ausführen.
Einträge in der URD enthalten ein Kennwort und eine Carnet-ID.
Die Datenbank Carnet-Informationen
struct {
verylong key;
verylong dbid;
u_long start;
u_long size;
u_long Index;
u_long resyncs;
}
Die CID (Datenbank Carnet-Informationen) hält Zustandsinformationen für die Benutzer-Carnets und für die Händler-Module. Diese Datenbank wird von der Löscheinrichtung verwendet, um die nächsten erwarteten Zahlungs- oder Authentifizierungsmünzen zu identifizieren. Sie ermöglicht außerdem, daß die Aktualisierungseinrichtung jede Menge von Zahlungs- oder Authentifizierungsmünzen aus der RND rekonstruiert.
Der Schlüssel ist der Wert, der in der verschlüsselten Kontrollsumme verwendet wird, um die Münzen aufzubauen. Die ID, der Startversatz und die Feldgrößen der Datenbank identifizieren die Quelle der Zufallsdaten in der RND. Der Münzindex ist der Index der nächsten erwarteten Münze und liegt im Bereich [0 ... Größe]. Der Resync-Zähler (Zähler Neusynchronisation) ist eine Aufzeichnung von Nummern von Münzen, die ausgelassen wurden, um eine empfangene Münze zu löschen.
Datenbank Händler-Informationen
struct {
u_long accepted;
}
Die MID (Datenbank Händler-Informationen) hält die Aufzeichnung von Transaktionen, die für jeden Händler gelöscht wurden. Dort, wo ein Eintrag für ein Carnet in der CID für einen Händler vorhanden ist, gibt es einen entsprechenden Eintrag in der MID.
Die Zufallszahl-Datenbank
struct {
u_long size;
verylong token[];
}
Die RND (Zufallszahl-Datenbank) hält einen Vorrat von Zufallsdaten, die verwendet werden, um Mengen von Zahlungs- und Authentifizierungsmünzen aufzubauen. Jeder Eintrag in der Datenbank enthält eine Zufallsfolge von 64 Bit-Werten. Das Größenfeld gibt an, wie groß diese Folge ist. Die RND wird mit Daten von einem Hardware-Generator für Zufallszahlen in der folgenden Weise gefüllt: Das Programm RandomCommServer kann in drei Abschnitte unterteilt werden. Der Zufallsgenerator erscheint unter dem Quellen-Dateinamen Random Generator.cpp mit der Kopfdatei Random Generator.h, die Zufallsprüfeinrichtung verwendet die Quellendateien Main tester.cpp, tester.cpp, und Random IO.cpp und verwendet die Kopfdateien Main Tester.h, tester.h, stats.h und Random IO.h. Die restlichen Teile dienen als Windows-Schnittstelle und als Server. Die hauptsächlichen Quellen-Dateien sind RCServerDoc.cpp, ServerSocket.cpp und "CommSocket.cpp".
1. Erzeugung der Daten
Die Zufallszahlen werden unter Verwendung eines Hardware-Generators für Zufallszahlen, der von BT hergestellt wird und als Lektor 3900 bekannt ist, in Blöcken von 256 K (= 2.097.152 Bits) erzeugt. Der Zufallszahl-Generator ist eine Karte, die in einen Personalcomputer paßt und eine Diode und einen Verstärker enthält, der Schrotrauschen an der Diode verstärkt, um einen Zufallsstrom von binären Werten zu erzeugen. Der Generator besitzt eine geringe Vorspannung, und um das zu korrigieren, werden die Daten komprimiert, indem zwei Datenbits in ein Bit oder in kein Bit umgewandelt werden. 00 und 11 werden verworfen, 01 wird zu 0 und 10 wird zu 1. Das bedeutet, daß 3/4 der Daten verloren gehen, die Vorspannung ist jedoch entfernt. Diese Daten werden dann auf der Platte unter der Bezeichnung "raw.dat" gespeichert.
2. Prüfung der Daten
Die folgenden Prüfungen werden an den 256 K-Blöcken ausgeführt.

(i) Bitprüfung: Prüfung der Anzahl von Nullen gegen die Anzahl von Einsen.
(ii) Serielle Prüfung: Prüfungen der Häufigkeiten von 00, 01, 10 und 11.
(iii) Laufprüfung: Prüfung des Vorkommens von langen Folgen von 0 ... 0 oder 1 ... 1.
(iv) Poker-Prüfung der Größe 2 bis 8: Prüfung des Auftretens von 2-Bit- und 8-Bit-Kombinationen.
(v) Autokorrelationsprüfung für Perioden von 1 bis 1000: Prüfung nach einer Periodizität in den Daten.
(vi) Maurer-Universal-Statistikprüfung: betrachtet die Möglichkeit der Komprimierung von Daten.

Die Bitprüfung wird außerdem kumulativ für alle erzeugten Daten berechnet. Sie prüft nach einer Gesamtvorspannung, die möglicherweise in den Prüfungen der Daten von lediglich 128 K nicht offensichtlich ist.
3. Akzeptanz/Zurückweisung der Daten
Die Daten werden an den Signifikanzpegeln 5% und 1% geprüft. Das sollte bedeuten, daß die Anzahl der Prüfungen, die am 5%-Pegel fehlschlagen 1 von 20 sein sollten und die Anzahl bei dem Signifikanzpegel 1% sollte 1 von 100 sein. Falls die Daten bei bedeutend mehr als bei diesen 1011 Prüfungen unzulässig sind (> 80 beim 5%-Fehler, > 15 beim 1%-Fehler, oder 1 "nicht maßstäblicher" Fehler), werden die Daten zurückgewiesen. Zusätzlich wird ein Bewertungs stand der Ausfälle bei einer bestimmten Prüfung gespeichert. Wenn eine Prüfung ständig mißlingt, wird dies angezeigt.
4. Speicherung von Daten und Verwendung als Server
Wenn die Daten als wirklich zufällig akzeptiert worden sind, wird die 256 K-Datei in acht 32 K-Dateien unterteilt und unter dem Dateinamen "use_n.dat" gespeichert (wobei n eine dreistellige Zahl ist). Dieser Dateiname steht jeder Client-Maschine zur Verfügung, die mit dem Server verbunden ist. Der Server sendet Dateien aus, wobei die älteste zuerst verwendet wird. Wenn eine Datei an einen Client gesendet wurde, wird sie aus der Speichereinrichtung gelöscht. Zu einem beliebigen Zeitpunkt sind bis zu 1000 32 K-Dateien für Clients verfügbar. Wenn die Befürchtung besteht, daß auf die Zufallsdaten zugegriffen werden kann, während sie gesendet werden, wird empfohlen, daß der Client die empfangenen Zufallsdaten verschlüsselt.
Erzeugungseinrichtung (Creator)
Die Erzeugungseinrichtung wird aufgerufen, um für einen Anwender ein neues Carnet zu erzeugen. 2 gibt einen Ablaufplan für diesen Prozeß an. Es wird angenommen, daß dann, wenn es sich um das erste Carnet des Benutzers handelt, in der URD bereits ein Konto erzeugt wurde.
Die Erzeugungseinrichtung nimmt eine neue Carnet-ID, einen Schlüssel, eine Datenbank-ID und einen Startversatz als Zufallswerte auf und fügt diese Angaben der CID hinzu. Sie liest anschließend Münzen von der RND, verschlüsselt sie unter Verwendung des Schlüssels und packt sie (gemeinsam mit der Client-Software) in einer Installierungseinrichtung zur Verteilung.
Löscheinrichtung (Clearer)
3 gibt einen Ablaufplan für die hauptsächliche Ausführungsschleife des Löscheinrichtungs-Moduls des Zahlungsdienstes an. Seine Funktion besteht darin, Zahlungsmünzen zu verarbeiten, die von QuickPay-Händlern eingezogen wurden. Die Löscheinrichtung lauscht auf Anforderungen von Händlern an das Netz. Wenn eine Anforderung erfolgt, liest die Löscheinrichtung den Datensatz {im, tm, ic, tc, n}, (wobei im die Kennung eines Carnets beim Händler ist, tm ist eine Münze von diesem Carnet beim Händler, ic ist die Kennung eines Carnets beim Klienten, tc ist eine Münze von diesem Carnet beim Klienten und n ist die Anzahl von Münzen von dem Klienten) und prüft, ob er richtig formatiert ist. Die Löscheinrichtung ignoriert falsche Anforderungen. Die Löscheinrichtung prüft {im, tm} und {ic, tc, n} (siehe unten). Wenn beide Prüfungen durchlaufen werden, erhöht der Zahlungsdienst die Kontoaufzeichnung für den Händler, um die Annahme von weiteren n Münzen anzuzeigen. Eine Authentifizierungsnachricht wird an den Händler zurückgeleitet. Wahlweise kann die Authentifizierungsnachrichtung die Form der nächsten Authentifizierungsmünze in einer Folge von Authentifizierungsmünzen, die zuvor an den Händler ausgegeben wurden, annehmen. Das Komplement des Münzwertes kann übertragen werden, wenn die Authentifizierung fehlgeschlagen ist. 4 beschreibt den Vorgang der Verifizierung des Tupels {i, t} {i, t, n}. Die Löscheinrichtung beginnt mit dem Lesen des Schlüssels k, der Datenbank-ID d, des Startversatzes s und des Münzzählers c von der CID. Unter Verwendung von s, c und n bestimmt die Löscheinrichtung die Position der nächsten erwarteten Münze für das Carnet in der raw-Datenbank d.
Sie liest diese Münze und bildet unter Verwendung von k die verschlüsselte Kontrollsumme. Wenn das Ergebnis gleich dem gelieferten Wert ist, wird die Münze akzeptiert.
Manchmal entsteht der Zustand, daß der Indexzeiger im Carnet vor jenen im Zahlungsdienst vorläuft. Das erfolgt im Ergebnis von Münzen, die eingezogen, jedoch nicht gelöscht werden. Die Löscheinrichtung besitzt ein Mechanismus, um dieses Problem zu behandeln. Wenn die erste Münze, die von der RND wiedergewonnen wird, nicht übereinstimmt, sucht die Löscheinrichtung in Vorwärtsrichtung, indem sie die nächste Münze probiert, anschließend die nächste usw. Die Löscheinrichtung wird eine Münze akzeptieren, die innerhalb von 100 Versuchen übereinstimmt (diese Zahl ist gemäß den Anforderungen einer speziellen Implementierung veränderlich) . Für j ede Münze in der RND, die ausgelassen wird, erhöht die Löscheinrichtung den Resync-Zähler für das Carnet in der CID. Die Löscheinrichtung berichtet über den Erfolg oder das Mißlingen durch Zurückleiten eines numerischen Codes. Wie oben erwähnt wurde, kann das grundlegende Schema flexibler gemacht werden, indem ein gleitendes Fenster verwendet wird, anstatt einfach einen feststehenden Bereich in Vorwärtsrichtung von dem gegenwärtigen Index-Zeiger im Zahlungsdienst zu verwenden.
10 zeigt das Schema des gleitenden Fensters. Die Figur zeigt, wie die Tupel {i, t} und {i, t, n} verifiziert werden. Die Löscheinrichtung startet durch das Lesen des Schlüssels k, der Datenbank-ID d, des Startversatzes s und des Münzzählers c für das Carnet i von der CID. Die Werte s, c und n werden von der Löscheinrichtung verwendet, um die Position der nächsten erwarteten Münze für das Carnet innerhalb der raw-Datenbank d zu bestimmen. Sie liest diese Münze und bildet unter Verwendung von k die verschlüsselte Kontrollsumme. Wenn das Ergebnis gleich dem gelieferten Wert t ist, ist die Münze akzeptiert. Um eine gewisse geringe Neuordnung von Transaktionen zu ermöglichen, unterhält die Löscheinrichtung ein Transaktionsfenster, das die Position der nächsten erwarteten Münze umgibt. Anstelle der einfachen Prüfung des Werts an dieser Position akzeptiert die Löscheinrichtung eine Münze, wenn sie irgendwo innerhalb des Fensters auftritt.
Anfangs beginnt das Fenster an der Position der nächsten erwarteten Münze. Wenn Transaktionen außerhalb der Reihe eintreffen, sucht die Löscheinrichtung in Vorwärtsrichtung innerhalb des Fensters bei einem Versuch, die Münze zu löschen. Wenn eine Übereinstimmung gefunden wird, zeichnet die Löscheinrichtung die Tatsache auf, daß eine spezielle Münze gelöscht wurde, um das doppelte Ausgeben zu verhindern. Positionen in der gespeicherten Folge, die gelöschten Münzen entsprechen, sind in der Figur schattiert gezeigt. Die Größe des Fensters ist ein konfigurierbarer Systemparameter. Die Löscheinrichtung muß einen Merker speichern, um den Zustand jeder Münze innerhalb des Fensters anzugeben, deshalb beeinflußt die Größe des Fensters die Speicheranforderungen der Löscheinrichtung.
Wenn Münzen ausgegeben sind, bewegt sich das Fenster längs der Liste von Nummern in der raw-Datenbank in Vorwärtsrichtung. Das Fenster bewegt sich in zwei Situationen:

1. Wenn Münzen an der Rückseite des Fensters gelöscht werden.
2. Wenn die Löscheinrichtung in Vorwärtsrichtung über die Vorderseite des Fensters hinaus suchen muß, um eine Münze zu löschen.

Im zweiten Fall sind Münzen an der Rückseite des Fensters verloren, wenn sich das Fenster vorwärtsbewegt. Die Löscheinrichtung unterhält zusätzlich einen Zählerstand von Münzen, die auf diese Weise verloren gehen (der Resync-Zählerstand).
Wahlweise kann eine Implementierung des QuickPay-Systems die Fenstertechnik nicht verwenden, indem eine Fenstergröße von 1 konfiguriert wird. Auf diese Weise vermeidet die Löscheinrichtung das Unterhalten von Zustandsmerkern für Elemente im Fenster, sie ist jedoch nicht in der Lage, Transaktionen außer der Reihe zu löschen.
Aktualisierungseinrichtung (Updater)
Die Aktualisierungseinrichtung ist der Erzeugungseinrichtung ähnlich, mit der Ausnahme, daß sie Carnets aus vorhandenen Einträgen in der URD und der CID neu bildet. Sie wird verwendet, um eine Münzendatenbank eines Klienten oder eines Händlers wiederherzustellen, falls sie beschädigt werden sollte oder mit dem Zahlungsdienst außer Synchronisation gerät. Die Aktualisierungseinrichtung kann außerdem verwendet werden, um Münzen wiederherzustellen, die vom Zahlungsdienst verworfen (niemals gelöscht) wurden. 5 zeigt einen Ablaufplan für die Aktualisierungseinrichtung.
Die Aktualisierungseinrichtung liest die Carnetgröße s, den Münzzähler c und den Resync-Zähler r von der CID. Sie berechnet die Anzahl der verbleibenden Münzen und erzeugt einen neuen Schlüssel, eine Datenbank-ID und einen Startindex. Der Rest des Algorithmus ist wie bei der Erzeugungseinrichtung.
Händler-Modul
Das Händler-Modul umfaßt die Einzugseinrichtung, Administrationsfunktionen und die Authentifizierungsmünzen-Datenbank.
Die Einzugseinrichtung (Collector)
Die Einzugseinrichtung wird aufgerufen, wenn der Händler wünscht, eine Zahlung von einem Benutzercarnet einzuziehen. 6 zeigt ein Ablaufdiagramm für die Ausführung der Einzugseinrichtung. Im Schritt 61 stellt das Einzug-Modul eine Verbindung zur Brieftasche (Wallet) im Zahleinrichtungs-Modul (wird später beschrieben) her. Im Schritt 62 wird die N-te Münze von der Zahleinrichtung gefordert, wobei N durch die Anzahl von Münzen bestimmt wird, die erforderlich ist, damit sich der erforderliche Geldwert für die Transaktion ergibt. Im Schritt 63 wird die Antwort von der Zahleinrichtung empfangen. Die Antwort wird im Schritt 64 geprüft und falls die Anforderung zurückgewiesen wurde, wird im Schritt 610 das Mißlingen signalisiert. Andernfalls verbindet sich der Händler im Schritt 65 mit dem Zahlungsdienst. Im Schritt 66 wird das Tupel gesendet, das die folgenden Werte enthält: Händler-ID (MID), Autorisierungsmünze (AT), N, Brieftaschen-ID (Wallet-ID, WID), Zahlungsmünze (PT). Im Schritt 67 wird eine Antwort vom Zahlungsserver empfangen und im Schritt 68 wird diese Antwort geprüft. Falls die Anforderung zur Autorisierung nicht zurückgewiesen wird, wird im Schritt 69 die erfolgreiche Ausführung an die Zahleinrichtung signalisiert. Wenn andererseits die Anforderung zur Autorisierung zurückgewiesen wurde, wird im Schritt 610 das Mißlingen signalisiert.
Administrationsfunktionen
Das Händler-Modul enthält Administrationsfunktionen. Diese unterhalten einen Zählerstand, wie viele nicht verwendete Authentifizierungsmünzen verbleiben und senden eine Anforderung für weitere Münzen an den Zahlungsdienst, wenn diese Zahl unter einen vorgegebenen Schwellenwert fällt.
Carnet
Das Carnet umfaßt die Zahleinrichtung, die Zahlungsmünzen-Datenbank und die Administrationsfunktionen. Es ist außerdem eine Installationseinrichtung vorhanden, die für die anfängliche Installation auf der Client-Plattform verantwortlich ist.
Die Zahleinrichtung (Payer)
Der Zahleinrichtung ist verantwortlich für die Behandlung der Anforderungen nach Zahlungsmünzen. Sie empfängt Anforderungen vom Netz und entscheidet, ob sie erfüllt werden. Diese Entscheidung basiert auf mehreren Faktoren, die die Benutzereingabe, die Anzahl der verbleibenden Münzen und den Ablauf früherer Transaktionen enthalten. 7 zeigt einen Ablaufplan für die Zahlungseinrichtung.
Administrationsfunktionen
Wie das Händler-Modul enthält das Carnet einen Mechanismus zum Auffrischen des Carnets und zum Hinzufügen neuer Münzen. Außerdem werden die in der Benutzermaschine gespeicherten Zahlungsmünzen durch eine PIN (persönliche Identifizierungsnummer) ge schützt.
Die Installierungseinrichtung
Die Installierungseinrichtung richtet den QuickPay-Client auf der Benutzermaschine ein. Sie erzeugt eine Anzahl von Dateien und Verzeichnissen und ermöglicht dem Benutzer, die neuinstallierten Zahlungsmünzen durch eine PIN zu schützen. In diesem Beispiel ist der QuickPay-Client verteilt als eine komprimierte TAR-Datei für UNIX-Systeme.

Tabelle 1

Wallet-ID	0xbfb0a569fcbc61f0
0	0x502a1d6c3351d07c
1	0xc30ce637bd6091b3
2	0x6420dda77f68a7db
3	0x85e354f3229f48f1
4	0x81399aa9cb5a87ae
5	0x26c5724d56794a57
6	0xccf8b8add7765a7f
7	0x4ab802396f89d6ed
8	0x5f9a820ce1e667e7
9	0x1e5a225186e01181
10	0xa32cd70d233c50d7
11	0x956e712aaa29cf4d
12	0xb92d9eecad3f16ec
13	0x11493c8bfcee102e
14	0xa870480af34d6778
15	0x9cc5f5945e153bba
16	0xb6abd8c968c47312
17	0x7cfb9ab0555c58c5
18	0x1051e7a417766c01
19	0x5d5e95685bc01249
...

Claims

Verfahren zum Betreiben eines digitalen Zahlungstransaktionssystems, das umfaßt: a) Speichern einer Folge von Zufallszahlen in einem Zahlungsserver (6); b) Ausgeben einer Menge digitaler Zahlungsmünzen, die eine Folge digital codierter Zufallszahlen enthalten, an einen Anwender (1); c) Übertragen einer Zahlungsmünze von einem Anwender (1) an eine Handelsplattform (5); d) Übertragen der von dem Anwender (1) im Schritt c) empfangenen Zahlungsmünze von der Handelsplattform (5) an den Zahlungsserver (6); e) Authentifizieren der Münze bei dem Zahlungsserver (6) durch Vergleichen des Wertes der Zufallszahl der Münze von der Handelsplattform (5) mit einem Wert, der von einer entsprechenden Position in der gespeicherten Folge aus Zufallszahlen abgeleitet wird; und f) anschließendes Senden einer Authentifizierungsnachricht von dem Zahlungsserver (6) zu der Handelsplattform (5), wobei das Verfahren gekennzeichnet ist durch den folgenden Schritt: g) Ableiten der Menge digitaler Zahlungsmünzen aus der gespeicherten Folge von Zufallszahlen durch Auswählen eines Teils der gespeicherten Folge und Codieren des Teils der gespeicherten Folge mit einem für den Anwender spezifischen Schlüssel.
Verfahren nach Anspruch 1, bei dem sich der Zahlungsserver (6) in einer Entfernung von der Handelsplattform (5) befindet und die Handelsplattform (5) über ein Kommunikationsnetz (3) mit dem Zahlungsserver kommuniziert.
Verfahren nach Anspruch 1 oder Anspruch 2, bei dem der Teil der gespeicherten Folge durch einen symmetrischen Blockverschlüsselungsschlüssel codiert wird.
Verfahren nach einem der vorhergehenden Ansprüche, bei dem der Anwender (1) sich in einer Entfernung von der Handelsplattform (5) befindet und im Schritt (c) die Zahlungsmünze an die Handelsplattform (5) über ein Kommunikationsnetz (3) überträgt.
Verfahren nach einem der vorhergehenden Ansprüche, bei dem der Schritt des Authentifizierens der digitalen Zahlungsmünze umfaßt: I) Versuchen, die digitale Zahlungsmünze in Gegenüberstellung mit einem Wert an einer Position in der im Zahlungsserver (6) gespeicherten Folge von Zufallszahlen zu authentifizieren; und II) wenn die Münze im Schritt I) nicht authentifiziert wird, Versuchen, die digitale Zahlungsmünze in Gegenüberstellung mit einem der mehreren anderen Werten in der gespeicherten Folge zu authentifizieren, wobei die anderen Werte innerhalb eines vorgegebenen maximalen Abstandes von dieser Position liegen; und bei dem die Authentifizierungsnachricht im Schritt f) angibt, daß die Authentifizierung erfolgreich ist, wenn die Münze entweder im Schritt (I) oder im Schritt (II) erfolgreich authentifiziert wird.
Verfahren nach einem der vorhergehenden Ansprüche, bei dem im Schritt d) der Händler zusammen mit der Zahlungsmünze eine Authentifizierungsmünze aus einer Folge von von dem Zahlungsserver (6) ausgegebenen Authentifizierungsmünzen sendet.
Verfahren nach Anspruch 6, bei dem der Zahlungsserver (6) einen Händlerkonten-Datensatz nach der Authentifizierung einer für gültig erklärten Zahlungsmünze und Authentifizierungsmünze, die von der Handelsplattform (5) empfangen werden, automatisch aktualisiert.
Verfahren nach einem der vorhergehenden Ansprüche, das ferner umfaßt: h) Halten eines Datensatzes über den momentanen Zustand der Menge digitaler Zahlungsmünzen in dem Zahlungsserver (6); und i) wenn die an den Anwender (1) ausgegebenen digitalen Zahlungsmünzen verloren oder verfälscht sind, Senden von Daten von dem Zahlungsserver (6) zum Anwender (1) und dadurch Aktualisieren der Menge digitaler Zahlungsmünzen auf einen Zustand, der j enem entspricht, der in dem Zahlungsserver aufgezeichnet ist.
Verfahren nach einem der vorhergehenden Ansprüche, das ferner umfaßt: Ausgeben einer Identifizierungsnummer (PIN) an den Anwender (1); Modifizieren der aus der gespeicherten Folge von Zufallszahlen abgeleiteten Zahlen unter Verwendung der Identifizierungsnummer; und weiterhin Modifizieren der digitalen Zahlungsmünze, die im Schritt (c) an den Händler übertragen wird, unter Verwendung der Identifizierungsnummer.
Verfahren nach Anspruch 11, bei dem in den Schritten des Modifizierens und weiteren Modifizierens der digitalen Zahlungsmünze der aus der gespeicherten Folge von Zufallszahlen abgeleitete digital codierte Wert mit der Identifizierungsnummer unter Verwendung einer Booleschen Logikoperation kombiniert wird.
Verfahren nach Anspruch 10, bei dem die Boolesche Logikoperation eine Exklusiv-ODER-Verknüpfung ist und bei dem dann, wenn in den Schritten des Modifizierens und des weiteren Modifizierens dieselbe Identifizierungsnummer verwendet wird, der Schritt des weiteren Modifizierens des digital codierten Werts den ursprünglichen Wert, der aus der gespeicherten Folge von Zufallszahlen abgeleitet wurde, erneut erzeugt.
Verfahren nach einem der vorhergehenden Ansprüche, bei dem eine Authentifizierungsmünze durch den Zahlungsserver (6) zusammen mit der Authentifizierungsnachricht zurückgeleitet wird.
Handelsplattform (5) für die Verwendung in einem Verfahren nach einem der vorhergehenden Ansprüche, wobei die Handelsplattform (5) umfaßt: Mittel, die von einem Anwender (1) eine digitale Zahlungsmünze empfangen, die eine digital codierte Zufallszahl enthält; Mittel, die die digitale Zahlungsmünze an einen Zahlungsserver (6) übertragen; und Mittel, die in Reaktion auf ein Authentifizierungssignal ansprechen, das von dem Zahlungsserver (6) ausgegeben wird, wenn die digitale Zahlungsmünze erfolgreich authentifiziert wird.
Handelsplattform (5) nach Anspruch 13, die ferner einen Speicher umfaßt, der mit einer Folge von Authentifizierungsmünzen programmiert ist, die von dem Zahlungsserver (6) ausgegeben werden, wobei im Gebrauch eine Authentifizierungsmünze zum Zahlungsserver (6) zusammen mit jeder digitalen Zahlungsmünze zurückgeleitet wird.
Zahlungsserver (6) für die Verwendung in einem Verfahren nach einem der Ansprüche 1 bis 12, wobei der Zahlungsserver (6) umfaßt: einen Datenspeicher, der mit einer Folge von Zufallszahlen programmiert ist; Mittel, die digitale Zahlungsmünzen ausgegeben, die eine Folge digital codierter Zufallszahlen enthalten, die aus der Folge in dem Datenspeicher abgeleitet werden; Mittel, die von einer Handelsplattform (5) zurückgeleitete digitale Zahlungsmünzen empfangen; Mittel, die die zurückgeleiteten digitalen Zahlungsmünzen authentifizieren; und Mittel, die eine Authentifizierungsnachricht an die Handelsplattform (5) ausgeben.
Client-Plattform für die Verwendung in einem Verfahren nach einem der Ansprüche 1 bis 12, wobei die Client-Plattform umfaßt: Mittel, die von einem Zahlungsserver (6), der sich in einer Entfernung von der Client-Plattform befindet, digitale Zahlungsmünzen empfangen, die eine Folge digital codierter Zufallszahlen umfassen; einen Münzenspeicher, der die digitalen Zahlungsmünzen speichert; und Zahlungsmittel, die eine Münze aus der Folge an eine Handelsplattform (5) ausgeben.
Kommunikationsnetz, das eine oder mehrere Handelsplattformen (5) nach Anspruch 13 oder 14, einen Zahlungsserver (6) nach Anspruch 15 und eine Client-Plattform nach Anspruch 16 umfaßt.