DE69610719T2

DE69610719T2 - System und verfahren für treuhandvermittler gebrauchende geschäfliche zahlungen

Info

Publication number: DE69610719T2
Application number: DE69610719T
Authority: DE
Inventors: S. Rosen
Original assignee: Citibank NA
Current assignee: Citibank NA
Priority date: 1995-08-30
Filing date: 1996-03-22
Publication date: 2001-05-23
Anticipated expiration: 2016-03-23
Also published as: MX9801523A; KR100329802B1; JPH11500555A; PT886839E; ES2151157T3; EP0886839B1; HK1015497A1; AU699117B2; CA2229012A1; EP0886839A1; RU2145437C1; WO1997008665A1; AU5426496A; PL325154A1; US5671280A; KR19990036292A; JP3390017B2; PL180151B1; ATE197099T1; DK0886839T3

Description

Bereich der Erfindung

Die vorliegende Erfindung betrifft ein System zum Ermöglichen elektronischer kommerzieller Zahlungen ohne vermittelnde Dritte. Im besonderen verwendet das System unverletzliche elektronische Einheiten, die als "vertrauenswürdige Agenten" bezeichnet werden, in Verbindung mit Geldmodulen, um eine sichere Transaktionsumgebung zur Abwicklung kommerzieller. Zahlungen und der begleitenden Überweisungsinformationen zu schaffen.

Hintergrund der Erfindung

Zur Zeit werden zahlreiche elektronische Zahlungssysteme entwickelt, um dem Wachstum des elektronischen Handels (Electronic Commerce) gerecht zu werden. Ein elektronisches Zahlungsverfahren wird in US-A-5453601, veröffentlicht am 26.09.1995, WO-A-95/30211, veröffentlicht am 09.11.1995, und WO- A-96/33476, veröffentlicht am 24.10.96, erläutert. Diese Patentanmeldungen beschreiben ein elektronisches Währungssystem zur Durchführung elektronischer Geldzahlungen als ein alternatives Tauschmittel zu Bargeld, Schecks, Kreditkarten, Debitkarten und elektronisohen Geldüberweisungen. Im besonderen verwendet das beschriebene System in eingriffsicheren Gehäusen verpackte Geldmodule zum Speichern und Überweisen von elektronischen Scheinen. Geldmodulzahlungen können entweder Echtzeit-Offline-Zahlungen zwischen Geldmodulen sein (z. B. zwischen einem in der "elektronischen Brieftasche" eines Kunden enthaltenen Geldmodul und einem in einem Kassenterminal (POS) eines Händlers enthaltenen Geldmodul) oder Online-Zahlungen für Netzdienste, wie Informationsabfrage und Telefonanrufe, oder zum Kauf von Flugtickets, Theaterkarten usw.
Die hierin besprochenen vertrauenswürdigen Agenten werden in WO-A-95/30211 ausführlich erläutert. Diese Patentanmeldung erläutert ein System zum Ermöglichen der sicheren Lieferung elektronischer Waren mit anonymer Echtzeit-Zahlung oder Zahlung auf Berechtigungsbasis. Mit dem System kann sowohl der Kunde als auch der Händler sicher sein, daß seinen Interessen gedient wird.
Kommerzielle Zahlungen werden meistens per Scheck getätigt, zunehmend geht man aber auch zum elektronischen Überweisungsverkehr (EDV-Überweisungen) über. Eine kommerzielle Zahlung, sei es mit Scheck oder EDV-Überweisung, trägt eine Überweisungsanzeige, die es dem Zahlungsempfänger ermöglicht, die Zahlung auf die offenstehende(n) Rechnung(en) des Kunden anzuwenden. Es ist wichtig, daß die Zahlung mit der Überweisungsanzeige gepaart wird, so daß sowohl der Zahler als auch der Zahlungsempfänger im Streitfall seine Sache belegen kann.
Im Fall einer Scheckzahlung wird die Überweisungsanzeige normalerweise mit dem Scheck gedruckt. Scheckzahlungen sind sowohl für den Zahler als auch für den Zahlungsempfänger kostspielig. Der Zahler muß die Schecks drucken, verschicken und abstimmen, und der Zahlungsempfänger muß die Postsendungen öffnen, die Informationen erneut eingeben und warten, bis die Schecks verrechnet sind. Aufgrund dieser Ineffizienz werden Vermittlungsstellen, die Auszahlungs- und Festlegungsdienste (Lock Box Service) bieten, immer mehr benutzt.
Auch gibt es eine Bewegung hin zum EDV-Zahlungsverkehr, da dieser die Kosten für Zahler und Zahlungsempfänger senken wird. Zur Zeit macht der EDV-Zahlungsverkehr weniger als fünf Prozent des kommerziellen Zahlungsverkehrs aus. Eines der Hindernisse für eine Ausdehnung des EDV-Zahlungsverkehrs ist, daß eine Bank als Vermittlungsstelle für die Transaktion agieren muß. Die Zahlungsverarbeitung ist auf die Verfügbarkeit der Systeme der Bank begrenzt und kann nicht benutzt werden, wenn die Bank des Zahlers und die Bank des Zahlungsempfängers keine Vereinbarung für den EDV-Zahlungsverkehr getroffen haben. Das EDV- Zahlungssystem muß die Überweisungsanzeige mit der Zahlungsnachricht übertragen können, so daß die Zahlungsinformation auf die Zahlung abgestimmt werden kann. Der EDV-Zahlungsverkehr benötigt feste Beziehungen zwischen Banken und Zahlern und Zahlungsempfängern. Er legt die Beteiligten auf Beziehungen fest, die schwer zu überarbeiten sind.
EP-A-0 172 670 beschreibt ein System für elektronischen kommerziellen Zahlungsverkehr, das elektronische Brieftaschen umfaßt, wobei eine erste Brieftasche elektronisches Geld zu einer zweiten Brieftasche transferiert. Die zweite Brieftasche sendet eine Quittung an die erste Brieftasche, die den von der ersten Brieftasche bezahlten Wert beinhaltet. Desgleichen sendet die erste Brieftasche eine Quittung an die zweite Brieftasche, die den von der zweiten Brieftasche erhaltenen Wert beinhaltet.
WO-A-9 308 545 beschreibt ein System für elektronischen Zahlungsverkehr, das elektronische Geldbörsen umfaßt, wobei eine Verbrauchergeldbörse Überweisungsanzeigeinformationen (Zusagenachricht) an eine Händlergeldbörse sendet und dann elektronisches Geld zur Händlergeldbörse transferiert.
WO-A-9 310 503 beschreibt ein System für elektronischen kommerziellen Zahlungsverkehr umfassend elektronische Transaktionsvorrichtungen, bei dem eine erste Vorrichtung Überweisungsanzeigeinformationen (Nachricht, die den Transferbetrag mitteilt) an eine zweite Vorrichtung sendet. Die zweite Vorrichtung sendet eine Bestätigung an die erste Vorrichtung. Mit dieser Bestätigung transferiert die erste Vorrichtung dann elektronisches Geld an eine zweite Vorrichtung.
Die vorliegende Erfindung beschreibt ein System, das die sichere und elektronische Durchführung kommerzieller Zahlungen zwischen Zahler und Zahlungsempfänger ohne die Notwendigkeit von Vermittlungsstellen ermöglicht und die Zahlung und die Überweisungsanzeige aufeinander abstimmt. Die Transaktion kann abgewickelt werden, wann es den Beteiligten paßt, und liefert Zahlungsbelege für den Zahler und den Zahlungsempfänger im Fall eines Streitfalls.

Zusammenfassung der Erfindung

Es ist eine Aufgabe der vorliegenden Erfindung, ein vertrauenswürdige Agenten benutzendes sicheres System bereitzustellen, das elektronische kommerzielle Zahlungen vom Zahler an den Zahlungsempfänger ohne irgendwelche Zwischenstellen ermöglicht.
Es ist eine weitere Aufgabe der vorliegenden Erfindung, ein Zahlungssystem bereitzustellen, das die Zahlungsinformationen mit der Zahlung vermählt, so daß die Zahlung endgültig ist und die Zahlungsinformationen nicht nach erfolgter Zahlung auf die tatsächliche Zahlung abgestimmt werden müssen.
Es ist eine weitere Aufgabe der vorliegenden Erfindung, ein Zahlungssystem bereitzustellen, bei dem die Zahlungsinformationen vom vertrauenswürdigen Agenten des Zahlungsempfängers mit einer elektronischen Signatur versehen wird, so daß der Zahlungsempfänger nicht bestreiten kann, daß er bezahlt wurde.
In der vorliegenden Erfindung ist ein Zahlungssystem vorgesehen, das folgendes hat: einen vertrauenswürdigen Kunden- Agenten; ein erstes Geldmodul, das dem vertrauenswürdigen Kunden- Agenten zugeordnet ist und mit dem es sicher kommuniziert; einen vertrauenswürdigen Händler-Agenten, der eine erste kryptographisch sichere Sitzung mit dem vertrauenswürdigen Kunden-Agenten einrichtet; und dem vertrauenswürdigen Händler- Agenten zugeordnetes zweites Geldmodul, das sicher mit ihm kommuniziert. Das erste und das zweite Geldmodul richten eine zweite kryptographisch sichere Sitzung ein. Der vertrauenswürdige Kunden-Agent liefert dem vertrauenswürdigen Händler-Agenten eine Überweisungsanzeigeinformation und der vertrauenswürdige Händler- Agent liefert dem vertrauenswürdigen Kunden-Agenten eine kommerzielle Zahlungsanweisung. Nach Erhalt der kommerziellen Zahlungsanweisung leitet der vertrauenswürdige Kunden-Agent einen Transfer von elektronischem Geld von dem ersten Geldmodul zu dem zweiten Geldmodul ein.
Die kommerzielle Zahlungsanweisung enthält vorzugsweise die digitale Signatur des vertrauenswürdigen Händler-Agenten über die Überweisungsanzeigeinformation. Der vertrauenswürdige Kunden- Agent verifiziert die digitale Signatur dann, bevor er einen Transfer von elektronischem Geld einleitet.

Beschreibung der Zeichnungen

Die Erfindung wird im folgenden unter Bezugnahme auf die Begleitzeichnungen ausführlicher erläutert. Dabei zeigt:
Fig. 1 ein Diagramm, das die Interaktion zwischen vertrauenswürdigen Agenten und Geldmodulen zeigt;
Fig. 2A - 2B die Daten, die in einer von einem Kreditorensystem eines Kunden erstellten Überweisungsanzeige enthalten sind;
Fig. 3 die Abschnitte und Felder einer kommerziellen Zahlungsanweisung;
Fig. 4 die Komponenten einer Transaktionsvorrichtung;
Fig. 5A - 5D die Funktionskomponenten von vertrauenswürdigen Agenten;
Fig. 6 ein Diagramm, das die Netzstruktur für kommerziellen Geldmodul-Zahlungsverkehr zeigt;
Fig. 7A ein Zusageprotokoll;
Fig. 7B ein Abbruchprotokoll;
Fig. 8A - 8D eine kommerzielle Geldmodulzahlung;
Fig. 9A - 9E ein Protokoll zum Einrichten einer Sitzung;
Fig. 10 ein Protokoll zum Senden einer Nachricht;
Fig. 11 ein Referenzprüfprotokoll;
Fig. 12 ein Transaktionsabbruchprotokoll;
Fig. 13A - 13E ein Geldmodulzahlungsprotokoll;
Fig. 14 die diversen, unter vertrauenswürdigen Agenten und Geldmodulen aufgebauten Nachrichtenverschlüsselungsschichten;
Fig. 15A - 15E ein Protokoll zum Einrichten einer Sitzung für Geldmodule;
Fig. 16 ein Protokoll zum Senden einer übertragenen (routed) Nachricht;
Fig. 17 ein Protokoll zum Senden einer mm/TA-Nachricht;
Fig. 18 ein Protokoll zum Senden einer TA/mm-Nachricht;
Fig. 19A - 19B ein Transaktionsabbruchprotokoll für Geldmodule;
Fig. 20 ein Protokoll zum Senden einer elektronisch übertragenen (e-routed) Nachricht;
Fig. 21A - 21B ein Scheinetransferprotokoll;
Fig. 22 ein Zusageprotokoll für Geldmodule.

Erläuterung der bevorzugten Ausgestaltung

Wie in WO-A-95/30211 erläutert, ist ein vertrauenswürdiger Agent eine Kombination aus Hardware- und Software-Komponenten. Er ist unverletzlich und enthält sichere Protokolle, die mit einem Geldmodul zusammenwirken, um sicheren Zahlungsverkehr mit Lieferung zu synchronisieren. Geldmodule sind unverletzliche Vorrichtungen, die elektronisches Geld speichern und transferieren können. Das elektronische Geld hat vorzugsweise die Form elektronischer Geldscheine, die Währungs- oder Kreditdarstellungen sind. Geldmodule können auch kryptographisch sichere Kommunikationssitzungen mit anderen Vorrichtungen einrichten. Die bevorzugte Ausgestaltung der vorliegenden Erfindung benutzt die in WO-A-96/33476 erläuterten Transaktionsgeldmodule.
Die vertrauenswürdigen Agenten tauschen elektronische Waren und Zahlung aus, wenn sie Einkäufe über ein Netzwerk tätigen. In der vorliegenden Erfindung, wie in Fig. 1 gezeigt, sendet der vertrauenswürdige Agent des Kunden 2 (CTA - Customer's Trusted Agent) Überweisungsanzeigeinformationen an den vertrauenswürdigen Agenten des Händlers 4 (MTA - Merchant's Trusted Agent). Der vertrauenswürdige Agent des Händlers 4 sendet dann eine kommerzielle Zahlungsanweisung an den vertrauenswürdigen Agenten des Kunden 2. Als Gegenleistung sendet das Geldmodul des Kunden 6 über CTA 2 und MTA 4 elektronisches Geld an das Geldmodul des Händlers 6.

Überweisungsanzeige

Das Kreditorensystem des Kunden erstellt eine Überweisungsanzeige, die von einer vertrauenswürdigen Vorrichtung des Kunden zu zahlen ist. Die Überweisungsanzeige wird über das Kundennetzwerk an die vertrauenswürdige Vorrichtung gesendet. Wie in Fig. 2A gezeigt, enthält die Überweisungsanzeige Informationen, die zum Erfüllen der Transaktion benötigt werden, z. B. Kunden- und Händlerinformationen 46, 47, wie der Name und die Anschrift des Kunden und des Händlers, eine Kundenaktennummer und die Netzadresse des Händlers, der zu zahlende Betrag 49, das Zahlungsdatum 48 und die Liste zu bezahlender Rechnungen 50. Wie in Fig. 2B gezeigt, weist die Rechnung genug Informationen für den Händler auf, um sie auf das Debitorensystem abzustimmen und um sie im Streitfall zu verwenden. Derartige Rechnungsinformationen können eine Rechnungsnummer 51, eine Bestellnummer 52, ein Fälligkeitsdatum 53, den Rechnungsbetrag 54, den Rabattbetrag 55 und den Nettobetrag 56 beinhalten.

Tickets

Ein Ticket 8 ist, unter Bezugnahme auf Fig. 1 und Fig. 3, ein elektronischer Artikel, der von einem MTA 4 erstellt und während einer Transaktion an einen CTA 2 übertragen wird. Tickets können als Eigentum der vertrauenswürdigen Agenten betrachtet werden. Ein Kunde, dessen CTA 2 gerade ein Ticket 8 erhalten hat, kann dieses Ticket nur nach erfolgreicher Durchführung der Transaktion verwenden.
Wie in WO-A-95/30211 erläutert, unterstützen vertrauenswürdige Agenten eine Vielfalt von Ticketarten, die für verschiedene Zwecke verwendet werden. Für die vorliegende Erfindung sind jedoch kommerzielle Zahlungsanweisungen die wichtigsten. Eine kommerzielle Zahlungsanweisung identifiziert die Einzelheiten einer kommerziellen Zahlung, hat die digitale Signatur des Zahlungsempfängers über die Überweisungsanzeige und kann vom Kunden in einem Streitszenario benutzt werden.
Fig. 3 zeigt eine bevorzugte Ausgestaltung eines Tickets 8, in der sich das Ticket aus sechs Hauptabschnitten zusammensetzt: Kennung 10, Komponenten 12, Ausstellersignatur 14, Ausstellerzertifikat 16, Transferereignisse 18 und Sendersignaturen 20. Die Abschnitte wiederum bestehen aus verschiedenen Feldern, die Informationen enthalten.
Der Kennungsabschnitt 10 hat ein Feld 22, das Informationen enthält, die den Händler oder die Behörde identifizieren, die das Ticket erstellt. Derartige Informationen, z. B. der Name des Händlers oder der Behörde, werden von einer Händler- oder Behördenreferenz im Besitz des Ticketausstellers abkopiert. Das Feld 22 enthält auch das Verfalldatum der Händler- oder Behördenreferenz. Ein Feld 24 enthält die Kennummer des vertrauenswürdigen Empfänger-Agenten. Außerdem enthält das Feld 24 auch das Verfalldatum der Referenz des vertrauenswürdigen Agenten des Ticketempfängers. Ein Feld 26 bezeichnet die Ticketart (z. B. Kredit- oder Debitkartenanweisung, kommerzielle Zahlungsanweisung usw.).
Der Komponentenabschnitt 12 enthält den grundlegenden Ticketinhalt, der je nach Art des Tickets und seines spezifischen Zwecks variiert. Fig. 3 zeigt ein Beispiel von Komponenten, die in einer kommerziellen Zahlungsanweisung zu finden sind.
Eine kommerzielle Zahlungsanweisung kann folgendes aufweisen: ein Kundeninformationsfeld 36, ein Händlerinformationsfeld 38, ein Zahlungsdatumsfeld 40, ein Feld "Betrag bezahlt" 42 und ein Feld für die Überweisungsanzeigesignatur 44, d. h. die digitale Signatur des MTA über die Überweisungsanzeigeinformationen.
Der Ausstellersignaturabschnitt 14 eines Tickets 8 enthält eine vom Ticketersteller gebildete digitale Signatur über die Abschnitte Kennung und Komponenten 10, 12. Eine derartige Signatur wird mit Hilfe eines privaten (asymmetrischen) Schlüssels, der dem vertrauenswürdigen Agenten des Ausstellers gehört, angefertigt. Der Ausstellerzertifikatabschnitt 16 enthält eine Zertifizierung durch einen vertrauenswürdigen Dritten (im folgenden "vertrauenswürdige Agentur" genannt), die in Verbindung mit der Ausstellersignatur zum Verifizieren der Echtheit des ausgestellten Tickets 8 verwendet wird. Eine solche Zertifizierung hat die Form eines Zertifikats, das dem vertrauenswürdigen Agenten des Ausstellers gehört. Die allgemeine Verwendung von Zertifikaten und digitalen Signaturen ist bekannt und wird z. B. in "Security For Computer Networks" (Sicherheit für Computernetze) von D. W. Davies and W. L. Price (John Wiley & Sons, 1984) beschrieben.
Der Abschnitt Transferereignisse 18 enthält Informationen, die erstellt werden, wenn Ticket s nach dem anfänglichen Ausstellen des Tickets 8 durch einen Händler oder eine Behörde zwischen vertrauenswürdigen Agenten transferiert werden. Ein Feld "Empfänger-ID" 28 enthält die Kennummer des empfangenden vertrauenswürdigen Agenten. Ein Feld "Sender-ID" 30 enthält die Kennummer des sendenden vertrauenswürdigen Agenten. Ein Feld "Senderzert." 32 enthält das Zertifikat des sendenden vertrauenswürdigen Agenten. Ein Datum/Zeiten-Feld 34 enthält das Datum und die Uhrzeit des Transfers des Tickets 8. Bei nachfolgenden Transfers werden dem jeweiligen Feld zusätzliche Empfänger- und Sender-ID, Senderzertifikate sowie Termine und Uhrzeiten angefügt, wodurch eine Liste von Transferereignisinformationen erstellt wird. Es ist zu beachten, daß die Kennung (ID) des vertrauenswürdigen Agenten, die im Empfänger-Feld des Kennungsabschnitts zu finden ist, die gleiche wie die erste Kennung (ID) im Sender-ID-Feld sein sollte.
Außerdem versieht der Sender immer dann, wenn ein Ticket 8 zwischen vertrauenswürdigen Agenten transferiert wird, das Ticket mit Hilfe eines privaten (asymmetrischen) Schlüssels, der dem vertrauenswürdigen Agenten des Senders gehört, mit einer digitalen Signatur über die fünf vorhergehenden Ticketabschnitte. Der Abschnitt "Sendersignaturen" 20 wird dann durch Anfügen der neu erstellten digitalen Signatur aktualisiert, wodurch eine Liste von Sendersignaturen gebildet wird.

Transaktionsvorrichtungen

Ein vertrauenswürdiger Agent 120, siehe Fig. 4, ist in eine Transaktionsvorrichtung 122 eingebettet. Die Transaktionsvorrichtung 122 setzt sich für den Händler und für den Kunden aus drei Hauptkomponenten zusammen. Es gibt einen Host-Rechner 124, einen vertrauenswürdigen Agenten 120 und ein Geldmodul 6. Diese Komponenten sind z. B. durch einen Bus 126 verbunden. Wenn der vertrauenswürdige Agent 120 ein MTA 2 ist, wird die Vorrichtung 122 als eine Händler-Transaktionsvorrichtung (MTD - Merchant Transaction Device) bezeichnet. Wenn der vertrauenswürdige Agent 120 ein CTA 4 ist, wird die Vorrichtung 122 als eine Kunden-Transaktionsvorrichtung (CTD - Customer Transaction Device) bezeichnet.
Fig. 4 zeigt die Funktionskomponenten des Host-Rechners 124. Der Host-Rechner erbringt die folgenden Funktionen: Kommunikation 128, Transaktionsanwendungen 130, Schnittstelle Mensch/Maschine 132, Datum/Zeit 136 und einen Nachrichten-Manager 134.
Die Kommunikationsfunktion 128 unterstützt die Kommunikation zwischen der Transaktionsvorrichtung 122 und der Außenwelt. Kommunikationstechnik dieser Art kann verdrahtet oder drahtlos, Breit- oder Schmalband sein, solange die Kommunikation zwischen den Vorrichtungen kompatibel ist. Die Kommunikationsfunktion 128 baut die Verbindung zwischen zwei Transaktionsvorrichtungen 122 auf oder verbindet eine Transaktionsvorrichtung mit einem Netz zum indirekten Verbinden mit einer anderen Transaktionsvorrichtung oder einem vertrauenswürdigen Server.
Transaktionsanwendungen 130 können eine Vielfalt von Aufgaben durchführen. Beispielsweise kann eine Transaktionsanwendung von früheren Transaktionen erhaltene Rechnungen bezahlen. Im allgemeinen enthält eine Transaktionsvorrichtung 122 all die Prozesse zum Wählen, Kaufen und möglicherweise Benutzen von elektronischen Gegenständen, elektronischem Geld, Referenzen und anderen Tickets 8 oder die Prozesse zum Verkaufen dieser.
Die Mensch/Maschine-Schnittstellenfunktion 132 liefert das Aussehen und die taktilen Eigenschaften der Transaktionsvorrichtung 122. Sie könnte eine Tastatur, eine Maus, einen Stift, Sprache, einen Berührungsbildschirm, Piktogramme, Menüs usw. beinhalten. Die Mensch/Maschine-Schnittstelle 132 kommuniziert durch den Nachrichten-Manager 134 mit anderen Funktionen im vertrauenswürdigen Agenten 120 und dem Geldmodul 6. In einigen Anwendungen ist eine Mensch/Maschine-Schnittstelle eventuell nicht erforderlich, z. B. in einer vollautomatischen Händler- oder Kunden-Transaktionsvorrichtung.
Die Datum/Zeit-Funktion 136 wird vom Besitzer der Transaktionsvorrichtung 122 eingestellt und beinhaltet Datum, Uhrzeit und Zeitzone. Die Datum/Zeit-Informationen werden dem eingebetteten vertrauenswürdigen Agenten 120 immer dann zugeführt, wenn der vertrauenswürdige Agent zur Benutzung geöffnet wird.
Der Nachrichten-Manager 134 routet Nachrichten zwischen Hosts (d. h. Nachrichten zwischen Transaktionsvorrichtungen) und Nachrichten zwischen dem Host-Rechner 124, dem vertrauenswürdigem Agenten 120 und dem Geldmodul 6.

Vertrauenswürdige Agenten

Fig. 5A zeigt die Funktionskomponenten eines vertrauenswürdigen Agenten 120. Das für den offenen elektronischen Handel erwogene System verwendet drei Arten von vertrauenswürdigen Agenten 120, die sich durch bestimmte eindeutige Transaktorfunktionen 146, die sie bereitstellen, voneinander unterscheiden. Fig. 5B zeigt die in einem CTA 2 gefundenen Transaktorfunktionen. Fig. 5C zeigt die in einem MTA 4 gefundenen Transaktorfunktionen. Fig. 5D zeigt die Transaktorfunktionen, die in einem vertrauenswürdigen Behörden- Agenten (ATA - Authority Trusted Agent) zu finden sind, der wiederum in eine Behörden-Transaktionsvorrichtung (ATD - Authority Transaction Device) eingebettet ist. ATD sind mit Referenzen ausstellenden Behörden, wie z. B. einer Bank, assoziiert.
Eine externe Schnittstellenfunktion 138 sorgt für die physische Kommunikation mit dem Host-Rechner 124 und dem Geldmodul 6 der Transaktionsvorrichtung 122, in die der vertrauenswürdige Agent 120 eingebettet ist. Eine Nachrichten- Schnittstellen-Funktion 140 bearbeitet und routed Nachrichten zwischen Agenten und innerhalb von Agenten. Eine Session-Manager- Funktion 142 baut Sitzungen zwischen Agenten und Sitzungen zwischen Agenten und vertrauenswürdigem Server auf und ab. Eine Sicherheits-Manager-Funktion 144 führt Sicherheitsinformationen (z. B. ein Zertifikat eines vertrauenswürdigen Agenten und eine Liste nicht vertrauenswürdiger Agenten) und richtet eine sichere Kommunikation mit einem vertrauenswürdigen gleichgestellten Agenten (über den Host-Rechner 124) und mit dem lokalen Geldmodul 6 innerhalb der gleichen Transaktionsvorrichtung 122 ein. Die Transaktorfunktion 146 stellt die Protokolle zum Durchführen einer Transaktion bereit. Kunden-, Händler- und Behörden- Transaktoren werden für CTA, MTA beziehungsweise ATA verwendet.
Fig. 5B zeigt die Kunden-Transaktorfunktionen. Eine Kauffunktion 158 tauscht Zahlung gegen Tickets 8 und elektronische Objekte ein. Eine Funktion "zu Host" 160 stellt eine Schnittstelle zum Host-Rechner 124 der Transaktionsvorrichtung bereit. Eine Funktion "Vorlage des Tickets" 164 legt Tickets 8 vor, um Informationen oder Dienstleistungen zu erhalten. Eine Funktion "Referenz einholen" 166 interagiert, um ein Referenzticket zu erhalten. Eine Funktion "Tran.-Protokoll" 162 führt ein Protokoll der Transaktionen vertrauenswürdiger Agenten. Sowohl CTA 2 als auch MTA 4 führen ein Transaktionenprotokoll, das die folgenden Informationen speichert: Transaktionstyp (z. B. Ticketart); ein Vortransaktionsticketbild, ein Nachtransaktionsticketbild, Streitfall-Informationen einschließlich dem Streitfalldatum (wie von jedem vertrauenswürdigen Agenten im Streitfalldialog geführt), Status und Händlerlösung (z. B. ersetzen, rückerstatten, ablehnen) und Neuzertifizierungsinformationen (z. B. Datum der erneuten Zertifizierung). Eine Funktion "Streitfall einleiten" 168 präsentiert elektronische Ware, wenn ein Kunde unzufrieden ist.
Fig. 5C zeigt die Händler-Transaktor-Funktionen. Eine Kauffunktion 170 tauscht Tickets 8 und elektronische Objekte gegen Zahlung ein. Eine Funktion "zu Host" 172 stellt eine Schnittstelle zum Host-Rechner der Transaktionsvorrichtung 124 bereit. Eine Funktion "Erhalt des Tickets" 176 bearbeitet ein erhaltenes Ticket 8, um Dienstleistungen oder Informationen bereitzustellen. Eine Funktion "Referenz einholen" 177 beschafft eine Händlerreferenz. Eine Funktion "Tran.-Protokoll 174" führt ein Protokoll der Transaktionen vertrauenswürdiger Agenten. Eine Funktion "Streitfall lösen" 178 erhält Tickets 8 und elektronische Objekte für eine Lösung bei einer Kundenbeschwerde.
Fig. 5D zeigt die Behörden-Transaktor-Funktionen. Eine Funktion "Referenz erstellen" 180 konstruiert und liefert Referenztickets an einen Anfordernden (Requester). Eine Funktion "zu Host" 182 stellt eine Schnittstelle zum Host-Rechner der Transaktionsvorrichtung 124 bereit. Eine Funktion "Erhalt des Tickets" 184 bearbeitet ein erhaltenes Ticket 8, um Dienstleistungen oder Informationen bereitzustellen. Eine Funktion "Referenz neu validieren" 186 akzeptiert eine laufende Referenz und stellt die Referenz mit einem neuen Verfalldatum neu aus. Eine Funktion "Tran.-Protokoll" 183 führt ein Transaktionenprotokoll. Eine Funktion "Referenz einholen" 185 beschafft eine Behördenreferenz.
Eine Funktion "zu Geldmodul" 150, wieder unter Bezugnahme auf Fig. 5A, kommuniziert mit dem Geldmodul 6 in der gleichen Transaktionsvorrichtung 122 zur Zahlungserbringung. Eine Kryptographie-Funktion 152 bietet asymmetrische und symmetrische kryptographische Funktionen. Es können alle gutbekannten asymmetrischen und symmetrischen Kryptomethoden verwendet werden, z. B. RSA und DES. Eine Ticketinhaber-Funktion 148 erstellt Tickets 8 in einem MTA 4 oder speichert Tickets 8 in einem CTA 2 und ruft sie in ihm ab. Eine Zufallsgenerator-Funktion 156 generiert Zufallszahlen zum Produzieren kryptographischer Schlüssel. Eine Datum/Zeit-Funktion 154 verwaltet das Datum und die Uhrzeit, die vom Host-Rechner 124 zum Datieren von Tickets 8 und zum Validieren von Zertifikaten und vorgelegten Tickets geliefert werden. Aktuelle Zeituhrinformationen werden dem vertrauenswürdigen Agenten 120 jedesmal zugeführt, wenn der vertrauenswürdige Agent geöffnet wird (d. h. zur Benutzung angemeldet wird), und aufrecht erhalten, bis der vertrauenswürdige Agent geschlossen wird.
Die Hardware des vertrauenswürdigen Agenten/Geldmoduls kann aus folgendem bestehen: einem Mikrocontroller (z. B. 196er Intel) zum Ausführen der Transaktionsprotokolle, einem flüchtigen Schnellspeicher (z. B. SRAM) zum Speichern des Betriebssystems, von Teilen der Anwendungen, der Kryptographie usw. während der Ausführung, einem nichtflüchtigen Speicher (z. B. Flash-Speicher) zum Speichern des Betriebssystems, der Anwendungen, der Tickets, des elektronischen Geldes, der Protokolle usw., einer integrierten Taktschaltung zum Erzeugen eines Zeitbezugs, einer Batterie für den Zeitgeber und einer Stördiode oder einer anderen Zufallsquelle für einen Zufallsgenerator.

Systemübersicht

Fig. 6 zeigt die allgemeine Netzarchitektur des betrachteten Systems für kommerzielle Zahlungen. Kundentransaktionsvorrichtung 188 kann über das Kundennetzwerk mit dem Kreditorensystem 189 des Kunden kommunizieren. Das Kreditorensystem des Kunden erstellt die Überweisungsanzeige, das eine Liste von zu bezahlenden Rechnungen hat, und sendet diese Informationen an den CTD 188.
Wenn der CTD 188 die Überweisungsinformationen hat, gewährleistet er, daß sein Geldmodul 6 genug Mittel zum Bezahlen hat oder er beschafft elektronisches Geld von einer anderen Transaktionsvorrichtung oder vom Bankkonto des Kunden, wie in WO- A-95/30211 und WO-A-96/33476 beschrieben. Bezahlt er mit Kredit, muß der CTD 188 entweder den Kredit unmittelbar verfügbar haben oder zur Bank gehen, um ihn zu erhalten.
Wenn der CTD 188 sowohl die Überweisungsanzeige als auch das elektronische Geld hat, kann er über irgendein Gateway-Netz 190 die Verbindung zu einem Händlernetzwerk 134 herstellen. Das Händlernetzwerk stellt die Kommunikation für MTD 198 und für das Debitorensystem 193 des Händlers bereit. Das Debitorensystem 913 wird zum Abstimmen offenstehender Rechnungen auf erhaltene Überweisungsinformationen verwendet. Das kommerzielle Zahlungssystem der vorliegenden Erfindung erlaubt es dann dem Kunden, eine sichere Geldmodulzahlung an einen Händler durchzuführen, und dafür eine kommerzielle Zahlungsanweisung zu erhalten, die die Signatur des MTD über die Überweisungsinformationen aufweist.

Ablaufdiagramme

Die in den folgenden Figuren gezeigten Ablaufdiagramme deuten zwei zusammenwirkende vertrauenswürdige Agenten 120 mit den Bezeichnungen "A" und "B" an. Die gleichen Bezeichnungen A und B können auch auf den Host-Rechner 124 oder das Geldmodul 6, der bzw. das mit einem bestimmten vertrauenswürdigen Agenten 120 assoziiert ist, angewendet werden (d. h. innerhalb der gleichen Transaktionsvorrichtung 122). Die Ablaufdiagramme zeigen die für die Durchführung einer bestimmten Aufgabe hauptverantwortliche Funktionskomponente an. SICHERHEITS-MANAGER A bedeutet beispielsweise, daß die genannte Aufgabe von der Sicherheits- Manager-Funktion 144 (siehe Fig. 5A) in dem vertrauenswürdigen Agenten A durchgeführt wird.
Die Ablaufdiagramme rufen auch Subroutinen auf, von denen einige Parameterbezeichnungen X und Y verwenden. Zum Beispiel ist "SITZUNG EINRICHTEN A -> B" ein Aufruf an die Subroutine "Sitzung einrichten". Das Ablaufdiagramm "Sitzung·einrichten" sollte dann durch den gesamten Ablauf hindurch in dem Verständnis, daß X = A und Y = B ist, verfolgt werden.

Abbruch und Zusage

Bei der Transaktionsbearbeitung der betrachteten Art ist es erwünscht, elektronische Artikel, wie z. B. Tickets 8 und elektronische Scheine, zwischen zwei Parteien weiterzugeben, gleichzeitig aber ein Nullsummenspiel beizubehalten. Das bedeutet, daß es nicht erwünscht ist, elektronische Artikel zu duplizieren, so daß es beim Abschluß einer elektronischen Transaktion doppelt so viele Artikel gibt wie vor der Transaktion. Desgleichen ist es nicht erwünscht, elektronische Artikel zu verlieren, so daß es nach der Transaktion weniger Artikel gibt als zuvor. Wenn zum Beispiel am Anfang einer Transaktion A ein elektronisches Ticket 8 hat und sie an B weitergeben möchte, dann ist es wünschenswert sicherzustellen, daß am Ende der Transaktion B das elektronische Ticket 8 hat und A das elektronische Ticket 8 nicht hat. In der Realität ist es aber möglich, daß man zwei andere Ergebnisse erhält, nämlich daß entweder sowohl A als auch B das gleiche elektronische Ticket 8 hat (Duplikation) oder daß weder A noch B das elektronische Ticket 8 hat (Verlust).
Um die Wahrscheinlichkeit einer Duplikation oder eines Verlusts unbedeutend zu machen, muß das Transaktionsprotokoll die Möglichkeit berücksichtigen, daß natürliche oder absichtliche Ereignisse einen typischen Transaktionsablauf unterbrechen können. Eine natürliche Unterbrechung wird durch einen Bruch der Kommunikationeverbindung zwischen A und B während der Transaktion veranschaulicht. Um die Möglichkeit einer Duplikation oder eines Verlustes aufgrund eines derartigen Zufalls zu minimieren, muß das Gelegenheitsfenster für die Schaffung einer Duplikation oder eines Verlustes minimiert werden. Um absichtliche Unterbrechungen (z. B. offene Angriffe) zu minimieren, ist es erwünscht, den wirtschaftlichen Anreiz für einen solchen Angriff zu beseitigen. Wenn ein Angreifer z. B. bei dem Versuch, die Transaktion zu unterbrechen, die Tickets und/oder das Geld nur verlieren könnte, bestünde für den Angreifer schon von vornherein kein Anreiz, einen Angriff zu beginnen.
Diese Konzepte sind in den effizienten Transaktionsprotokollen des erläuterten Systems ausgestaltet. Insbesondere ist es erwünscht, einheitliche Abbruch- und Zusagezustände zwischen den beiden die Transaktion durchführenden vertrauenswürdigen Agenten 120 (oder Geldmodulen 6) zu gewährleisten. Wenn beispielsweise A zu einer Transaktion zusagt, dann sollte B ebenfalls zu der Transaktion zusagen, oder wenn A die Transaktion abbricht, dann sollte B die Transaktion ebenfalls abbrechen. Zum Erreichen der Regelmäßigkeit und zum Minimieren der Duplikations- oder Verlustmöglichkeit (im Fall, daß es eine Unregelmäßigkeit gibt) berücksichtigen die Transaktionsprotokolle den Auftrag und die Zeitsetzung der Zusage von A und B zu einer bestimmten Transaktion.
Fig. 7 zeigt zwei Subroutinen, Abbruch und Zusage. Die Abbruch-Subroutine wird innerhalb eines bestimmten vertrauenswürdigen Agenten 120 intern ausgeführt, wenn die Transaktion, an der er beteiligt ist, nicht funktioniert. Die Abbruch-Subroutine versetzt den vertrauenswürdigen Agenten 120 wieder in genau den Zustand, in dem er sich befand, bevor er an der Subroutine, die nicht funktionierte, beteiligt war (Rollback). Außerdem wird, wenn der vertrauenswürdige Händler- Agent nach einer Berechtigung abbricht, dann die Berechtigung rückgängig gemacht. Umgekehrt wird die Zusage-Transaktion innerhalb eines bestimmten vertrauenswürdigen Agenten 120 intern ausgeführt, wenn die Transaktion, an der er beteiligt ist, erfolgreich abgeschlossen wurde. Der vertrauenswürdige Agent 120 verzeichnet die abgeschlossene Transaktion daher in seinem Transaktionenprotokoll und ist jetzt für eine neue Transaktion bereit. Beispielsweise wird während einer Tickettransfer- Transaktion ein elektronisches Ticket 8 von vertrauenswürdigem Agenten A an den vertrauenswürdigen Agenten B übertragen. Da zu diesem Zeitpunkt weder A noch B zugesagt oder die Transaktion abgebrochen hat, behält A das Ticket 8 vorläufig noch, während B das Ticket 8 ebenfalls vorläufig hat. Wenn A und B zusagen, dann löscht A sein Ticket 8 und B hält das Ticket 8 nicht mehr nur vorläufig. Wenn jedoch sowohl A als auch B die Transaktion abbricht, dann behält A sein Ticket 8 und das Ticket 8, das B vorläufig hielt, wird durch Rückgängigmachen (Rollback) der Transaktion gelöscht. Es ist zu beachten, daß der Löschvorgang auf verschiedene Arten, die im Fach gut bekannt sind, implementiert werden kann. Wie bereits erwähnt, ist es erwünscht, die Möglichkeit, daß ein vertrauenswürdiger Agent 120 zusagt, während ein anderer vertrauenswürdiger Agent 120 abbricht, zu minimieren, weil dies unter einigen begrenzten Umständen zum Duplizieren oder zum Verlust elektronischer Artikel führen kann.
Eine ähnliche Situation existiert bezüglich dem Austauschen elektronischer Scheine durch Geldmodule 6. Während einer Kauftransaktion werden elektronische Scheine von Geldmodul A an Geldmodul B übertragen, so daß A seine elektronischen Scheine vorläufig (um die transferierten Beträge) dekrementiert, während B vorläufig elektronische Scheine (im Wert des transferierten Betrags) hat. Wenn A und B zusagen, dann behält A die Scheine in den dekrementierten Beträgen und B hält die elektronischen Scheine nicht mehr nur vorläufig.
Fig. 7A zeigt die Zusage-Subroutine. "Tran.-Protokoll X" aktualisiert das Transaktionenprotokoll. "zu Host X" benachrichtigt den Host, daß die Transaktion abgeschlossen ist. Session-Manager X nimmt das Ende der Sitzung zur Kenntnis. (Schritte 230-234).
Fig. 7B zeigt die Abbruch-Subroutine. Session-Manager X macht die Änderungen wieder rückgängig (Rollback) und nimmt den Abbruch durch den Agenten zur Kenntnis. Der Session-Manager verfolgt die Aktivitäten seit Beginn einer Sitzung und macht diese Schritte beim Rollback rückgängig. "zu Host X" sendet eine Nachricht an den Host, daß die Transaktion abgebrochen wurde. (Schritte 236-238).
Die Abbruch-Subroutine kann direkt von einem Ablaufdiagramm aufgerufen werden, zum Beispiel, wenn ein vertrauenswürdiger Agent 120 bestimmt, daß ein Zertifikat nicht gültig ist. Die Abbruch-Subroutine kann auch aufgerufen werden, wenn eine erwartete Handlung nicht eintritt. Im besonderen werden zwei vertrauenswürdige Agenten 120, wenn sie miteinander kommunizieren, ein Zeitüberwachungsprotokoll überwachen.
Beispielsweise stellt der Session-Manager des vertrauenswürdigen ersten Agenten (A), nachdem ein erster vertrauenswürdiger Agent 120 eine Nachricht an einen zweiten vertrauenswürdigen Agenten 120 gesendet hat, einen Zeitgeber für eine Antwort ein, wenn eine Antwort erforderlich ist. Eventuell numeriert der Session-Manager auch die gesendete Nachricht. Diese Nummer würde in der Antwortnachricht vom Session-Manager des zweiten vertrauenswürdigen Agenten (B) erscheinen.
Wenn der Zeitgeber abläuft, bevor die Nachricht erhalten wurde, dann befragt Session-Manager A Session-Manager B, um zu bestimmen, ob die Transaktion in B noch läuft. Wenn B nicht antwortet, dann bricht Session-Manager A die Transaktion ab. Wenn eine Antwort erhalten wird, daß die Transaktion läuft, dann wird der Zeitgeber auf eine neue Uhrzeit rückgesetzt. Wenn A B eine vorbestimmte Anzahl von Malen befragt hat, ohne eine Antwort auf die ursprüngliche Nachricht zu erhalten, dann bricht A die Transaktion ab. In den Geldmodulen 6 existiert eine ähnliche Zeitüberwachungsfunktion.

Kommerzielle Geldmodulzahlungen

Fig. 8 zeigt das Ablaufdiagramm für eine kommerzielle Geldmodulzahlung. Anfänglich werden Überweisungsinformationen von einem Kreditorensystem 189 zur Host-Transaktionsanwendung A (HTA) gesendet. Das Kreditorensystem 189 ist zwar vorzugsweise ein automatisches System, die Lehre der vorliegenden Erfindung gilt aber auch für ein manuelles System (d. h. bei dem Überweisungsdaten in die HTA eingegeben werden). Die HTA stellt dann, vorzugsweise über ein Kundennetzwerk 191, ein Gateway-Netz 190 und ein Händlernetzwerk 134, die Verbindung zur Host- Transaktionsanwendung B her (Schritt 700), und der Kunde wählt, eine kommerzielle Zahlung zu leisten. Die HTA sendet eine Nachricht an ihren vertrauenswürdigen Agenten A, eine kommerzielle Zahlung zu leisten, und HTB sendet eine Nachricht an ihren vertrauenswürdigen Agenten B, eine kommerzielle Zahlung zu erhalten (Schritte 702-704).
Die vertrauenswürdigen Agenten des Kunden und des Händlers (A und B) richten dann eine Sitzung ein, wie in der mitanhängigen US-Patentanmeldung 08/234,461 erläutert. Im besonderen wird eine Subroutine "Sitzung einrichten" (Schritt 706) zum Aufbauen eines kryptographisch sicheren Kommunikationskanals zwischen dem vertrauenswürdigen Agenten A und dem vertrauenswürdigen Agenten B aufgerufen. Der Session-Manager des vertrauenswürdigen Agenten A, siehe Fig. 9, fordert das Zertifikat von A (d. h. Zert. (TA)) vom Sicherheits-Manager an und erhält es dann (Schritte 296 - 298). Session-Manager A sendet dann Zert. (TA) an den Session- Manager des vertrauenswürdigen Agenten B, der es wiederum an seinen Sicherheits-Manager weiterleitet (Schritte 300-304).
Die Funktion "Öffentlicher Schlüssel" des vertrauenswürdigen Agenten B verifiziert das Zert. (TA) mit Hilfe der Validierungsprotokolle, wie den in WO-A-95/30211 und WO-A- 96/33476 besprochenen.
Wenn Zert. (TA) nicht gültig ist, dann nimmt der Session- Manager B zur Kenntnis, daß die Sitzung beendet wurde, und informiert Session-Manager A, daß die Transaktion verweigert wurde. Session-Manager A nimmt auch zur Kenntnis, daß die Sitzung beendet wurde. (Schritte 310-312). Wenn Zert. (TA) gültig ist, dann prüft Sicherheits-Manager B, ob der vertrauenswürdige Agent A auf der Nichtvertrauenswürdigen-Liste steht (Schritte 314 - 316). Wenn der vertrauenswürdige Agent A nicht vertrauenswürdig ist, dann wird die Sitzung beendet (Schritte 310-312).
Wenn A nicht auf der Nichtvertrauenswürdigen-Liste steht, dann erstellt der Zufallsgenerator B eine Zufallszahl R(B) und auch eine B-Verifizierungsnachricht (Schritt 318). Die Zufallszahl R(B) wird schließlich dazu verwendet werden, einen Sitzungsschlüssel zu bilden. Die B-Verifizierungsnachricht ist eine Zufallszahl, die von B zum Schutz gegen eine Nachrichtenwiedergabe verwendet wird. Anschließend stellt Sicherheits-Manager B R(B), die B-Verifizierungsnachricht und "Zert. (TA)" zu einer Nachricht für den vertrauenswürdigen Agenten A zusammen (Schritt 320). Der öffentliche Schlüssel B verschlüsselt die Nachricht mit dem öffentlichen Schlüssel des vertrauenswürdigen Agenten A (TA (PK)), den der vertrauenswürdige Agent B mit "Zert. (TA)" von A erhalten hat (Schritt 322). Session-Manager B sendet die verschlüsselte Nachricht an den Session-Manager von A (Schritte 324-326).
Der öffentliche Schlüssel A entschlüsselt die Nachricht mit Hilfe seines privaten Schlüssels (der seinem öffentlichen Schlüssel entspricht) und verifiziert die Gültigkeit von "Zert. (TA) " (Schritte 328-330). Wenn "Zert. (TA) " ungültig ist, dann nimmt der Session-Manager A zur Kenntnis, daß die Sitzung beendet wurde, und sendet eine Transaktionsverweigerungsnachricht an B, dessen Session-Manager ebenfalls zur Kenntnis nimmt, daß die Sitzung beendet wurde (Schritte 332-334). Wenn "Zert. (TA) " gültig ist, dann prüft Sicherheits-Manager A, ob der vertrauenswürdige Agent B auf der Nichtvertrauenswürdigen-Liste steht (Schritte 336-338). Wenn der vertrauenswürdige Agent B auf der Liste steht, wird die Sitzung beendet (Schritte 332 - 334).
Wenn B nicht auf der Nichtvertrauenswürdigen-Liste steht, dann erstellt Zufallsgenerator A eine Zufallszahl R(A) und eine A-Verifizierungsnachricht (z. B. eine weitere Zufallszahl) (Schritt 340). Die Datum/Zeit-Funktion leitet das laufende Datum und die aktuelle Uhrzeit an den Sicherheits-Manager (Schritt 342) weiter. A und B tauschen Tagesdaten und Uhrzeiten aus, um sie schließlich während Zusagen in ihren Transaktionenprotokollen aufzuzeichnen. Sicherheits-Manager A bildet und speichert dann Sitzungsschlüssel (TA/TA) durch EXKLUSIV-ODER-Verknüpfung von Zufallszahlen R(A) und R(B) (Schritt 344). Sitzungsschlüssel (TA/TA) wird zum Verschlüsseln der Kommunikation zwischen zwei vertrauenswürdigen Agenten 120 verwendet. Session-Manager A stellt eine Nachricht zusammen, die die A- und B- Verifizierungsnachrichten, die Datum/Zeit-Informationen und R(A) enthält (Schritt 344). Öffentlicher Schlüssel A verschlüsselt die Nachricht mit dem öffentlichen Schlüssel des vertrauenswürdigen Servers B (erhalten von A in Zert. (TA)) und sendet die verschlüsselte Nachricht an den Session-Manager des vertrauenswürdigen Servers B (Schritte 346-350).
Öffentlicher Schlüssel B entschlüsselt die erhaltene Nachricht mit seinem (seinem öffentlichen Schlüssel entsprechenden) Geheimschlüssel (Schritt 352). Sicherheits- Manager B prüft, ob die von A erhaltene B-Verifizierungsnachricht die gleiche B-Verifizierungsnachricht ist, die zuvor an A gesendet wurde (Schritte 354-356). Ist dies nicht der Fall, dann wird die Sitzung beendet (Schritte 310-312). Wenn sie die gleiche Nachricht ist, dann nimmt Session-Manager B den Sitzungsbeginn zur Kenntnis (Schritt 358).
Sicherheits-Manager B bildet Sitzungsschlüssel (TA/TA) durch EXKLUSIV-ODER-Verknüpfung von R(A) und R(B) und speichert dann den Sitzungsschlüssel (Schritt 360). An diesem Punkt haben A und B den gleichen Sitzungsschlüssel erstellt und gespeichert (d. h. Sitzungsschlüssel (TA/TA)), der für ihre laufende Interaktion zu verwenden ist. Als nächstes sendet Datum/Zeit B seine aktuellen Datum- und Uhrzeitinformationen zum Sicherheits-Manager B (Schritt 362). Sicherheits-Manager B stellt eine Nachricht zusammen, die eine Bestätigung an A, die A- Verifizierungsnachricht und die Datum/Uhrzeitinformationen von B enthält (Schritt 364). Zum Senden der Nachricht von B an A wird dann die Subroutine "Nachricht senden" aufgerufen (Schritt 366).
Die Funktion "Symmetrischer Schlüssel" des vertrauenswürdigen Agenten B, siehe Fig. 10, verschlüsselt die Nachricht mit dem Sitzungsschlüssel (TA/TA) (Schritt 376). Nachrichten-Schnittstelle B formattiert dann die Nachricht und sendet sie an den Nachrichten-Manager des Host-Rechners (Schritt 378). Host-Nachrichten-Manager H routet die Nachricht dann über die Kommunikationseinrichtung zum Host-Nachrichten-Manager A im Host-Rechner des vertrauenswürdigen Agenten A (Schritt 380). Host-Nachrichten-Manager A sendet die Nachricht dann an die Nachrichtenschnittstelle des vertrauenswürdigen Agenten A, die die Nachricht entnimmt (Schritte 382-384). Symmetrischer Schlüssel A entschlüsselt die Nachricht mit Sitzungsschlüssel (TA/TA), wodurch die sichere Kommunikation einer Nachricht zwischen vertrauenswürdigem Agenten und vertrauenswürdigem Agenten unter Verwendung von Sitzungsschlüssel (TA/TA) vervollständigt wird (Schritt 386).
Sicherheits-Manager A, siehe wieder Fig. 9, erhält die Bestätigung, die A-Verifizierungsnachricht und die Datum/Uhrzeit- Informationen von B (Schritt 368). Sicherheits-Manager A prüft, ob die A-Verifizierungsnachricht die gleiche A- Verifizierungsnachricht ist, die A zuvor an B gesendet hat (Schritte 370-372). Ist dies nicht der Fall, dann beendet Session-Manager A die Sitzung (Schritte 332-334). Wenn sie die gleiche Nachricht ist, dann nimmt Session-Manager A den Sitzungsbeginn zur Kenntnis (Schritt 374).
Nach dem Einrichten einer Sitzung, siehe wieder Fig. 8, fordert vertrauenswürdiger Agent A die Händlerreferenz von vertrauenswürdigem Agenten B an und prüft sie, wie auch in US- Anmeldung 08/234,461 erläutert. Im besonderen wird, siehe Fig. 11, die Subroutine "Referenz prüfen" aufgerufen (Schritt 708). Alle MTD 198 enthalten eine Referenz, die den Besitzer/Händler (z. B. NYNEX, Ticketron, usw.) kennzeichnen. Derartige Händlerreferenzen können z. B. von einer Händlerausweisstelle ausgestellt werden, die von der vertrauenswürdigen Agentur kontrolliert wird. Andererseits können zu von CTD 188 gehaltenen Kundenreferenzen Führerscheine oder Kreditkarten für Einzelpersonen zählen, oder die Kundenreferenzen können gewerbliche Referenzen sein, wie die in einem MTD 198 gehaltenen, und von diversen Ausweisstellen ausgestellt werden. "Kauf A", siehe Fig. 11, sendet eine Nachricht an "Kauf B" von vertrauenswürdigem Agenten B, mit der sie seine Händlerreferenz anfordert (Schritte 444-448). Ticketinhaber B ruft seine Händlerreferenz auf und sendet die Referenz zur Validierung an A (Schritte 450-456).
Referenzen oder andere Arten von Ticket 8 werden wie folgt validiert:
1) Ausstellerzertifikat validieren und Ausstellersignatur prüfen.
2) Jeden Transfer verifizieren - Empfänger- und Senderkennungen aufeinander abstimmen (d. h. So = Aussteller, Ro = 1. Empfänger, dann Ri = Si+1, i ≥ o).
3) Jedes Senderzertifikat validieren und jede Sendersignatur prüfen.
4) Verifizieren, daß die Kennung des letzten Empfängers mit der Kennung (TA (id)) des Zertifikats (Zert. (TA)) des vertrauenswürdigen Agenten in der laufenden Sitzung übereinstimmt.
Wenn die Referenz des Händlers nicht gültig ist, dann wird die Transaktion durch Aufrufen der Subroutine "Transaktion abbrechen" abgebrochen (Schritt 458). Vertrauenswürdiger Agent A, siehe Fig. 12, bricht die Transaktion ab und sein Session- Manager sendet eine Nachricht an den Session-Manager des vertrauenswürdigen Agenten B, in dem er B mitteilt, daß A abgebrochen hat (Schritte 390-394). Vertrauenswürdiger Agent B bricht dann die Transaktion ab (Schritt 396). Wenn die Referenz des Händlers, siehe wieder Fig. 11, gültig ist, dann sendet "zu Host A" die Referenzinformation an eine Host-Transferanwendung zur Bestätigung (z. B. Bestätigung der Händleridentität in der Überweisungsanzeige durch den Host-Rechner) (Schritte 460-462).
Der Ablauf für die kommerzielle Geldmodulzahlung läuft weiter, siehe wieder Fig. 8. "Kauf A" sendet die Nachricht "Benötigt B die Referenz von A?" an den vertrauenswürdigen Agenten B (Schritte 710-712). "Zu Host B" sendet dann die Nachricht "Referenz von A benötigt?" an HTB (Schritte 714-716). Wenn die Referenz des Kunden benötigt wird, um den Zahler zu identifizieren, dann wird die Subroutine "Referenz prüfen" ausgeführt, und danach sendet "Kauf B" eine Nachricht an A, die Zahlung zu beginnen (Schritte 718-724). Wenn keine Referenz benötigt wird, dann sendet "Kauf B" die Nachricht, daß die Referenz von A nicht benötigt wird (Schritte 722-724). Die Nachricht des vertrauenswürdigen Agenten B wird von "Kauf A" erhalten (Schritt 726), und "zu Host A" fordert die Überweisungsanzeige von der HTA an (Schritt 728). Die HTA sendet dann die Überweisungsanzeige an den vertrauenswürdigen Agenten A (Schritt 730), die von "zu Host A" erhalten wird und an den vertrauenswürdigen Agenten B gesendet wird (Schritte 732-734).
"Kauf B" erhält die Überweisungsanzeige und validiert den Gesamtbetrag der Überweisungsanzeige mit dem Rechnungsbetrag bzw. den Rechnungsbeträgen, der/die von der Überweisungsanzeige abgedeckt wird/werden (Schritt 736). Wenn der Gesamtbetrag nicht korrekt ist, dann wird die Transaktion abgebrochen (Schritte 738 - 740). Wenn die Summe korrekt ist, dann signiert der öffentliche Schlüssel B die Überweisungsanzeige digital und sendet die Signatur an Ticketinhaber B (Schritt 742). Ticketinhaber B erstellt eine kommerzielle Zahlungsanweisung (Schritt 744) und sendet die Anweisung (Ticket) an A (Schritte 746-748).
"Kauf A" erhält und validiert das Ticket (Schritt 750). Ist es ungültig, dann wird die Transaktion abgebrochen (Schritte 752 - 754). Ist es gültig, dann sendet "Kauf A" das Ticket an Ticketinhaber A und sendet die Überweisungsanzeigesignatur zur Verifizierung (Schritt 756).
Der öffentliche Schlüssel A verifiziert die digitale Signatur mit Hilfe des öffentlichen Schlüssels des Händlers, der zusammen mit der Händlerreferenz erhalten wurde (Schritt 758). Wenn die Signatur nicht korrekt ist, dann wird die Transaktion abgebrochen (Schritte 760, 754). Wenn die Signatur korrekt ist, dann wird eine Geldmodulzahlung durchgeführt (Schritte 760 - 762).
Vertrauenswürdiger Agent A führt dann eine Geldmodulzahlung an vertrauenswürdigen Agenten B durch, wie in WO-A-95/30211 erläutert. Im besonderen wird eine Subroutine "Geldmodul-Zahlung" aufgerufen (Schritt 762). Zufallsgenerator A, siehe Fig. 13, erstellt Zufallszahl R(1) (Schritt S20). "Kauf A" sendet dann eine Nachricht an vertrauenswürdigen Agenten B, die andeutet, daß eine "Geldmodul-Zahlung" durchgeführt werden wird, und auch R(1) enthält (Schritte 522-524). "Kauf B" erhält die Nachricht und sendet R(1) an Sicherheits-Manager B (Schritte 526-528).
Zufallsgenerator B erstellt Zufallszahl R(2) und sendet sie an vertrauenswürdigen Agenten A (Schritte 530-532). Die Sicherheits-Manager A und B bilden jeweils durch EXKLUSIV-ODER- Verknüpfung von R(1) und R(2) Sitzungsschlüssel (TA/mm) (Schritte 534-536).
In Fig. 14 werden vier während einer Transaktion eingerichtete Verschlüsselungskanäle gezeigt.
Verschlüsselungskanal 436 zwischen den beiden vertrauenswürdigen Agenten 120 trägt mit Sitzungsschlüssel (TA/TA) verschlüsselte Nachrichten. Kanäle 438 und 440 zwischen einem vertrauenswürdigen Agenten 120 und seinem Geldmodul 6 teilen sich Sitzungsschlüssel (TA/MM). Kanal 442 zwischen Geldmodulen 6 in verschiedenen Transaktionsvorrichtungen 122 verwendet Sitzungsschlüssel (MM/MM).
Sitzungsschlüssel (TA/MM) wird zum Verschlüsseln von Nachrichten verwendet, die über Verschlüsselungskanäle 438 und 440 zwischen einem vertrauenswürdigen Agenten 120 und seinem zugeordneten Geldmodul 6 gesendet werden. Am gegenwärtigen Punkt im Ablaufdiagramm haben nur die zwei vertrauenswürdigen Agenten 120 Sitzungsschlüssel (TA/MM). Beide Geldmodule 6 werden später im Ablaufdiagramm Kopien von Sitzungsschlüssel (TA/MM) bilden, um die verschlüsselte Kommunikation zwischen den vertrauenswürdigen Agenten 120 und ihren Geldmodulen 6 zu ermöglichen.
Es ist zu beachten, daß der vertrauenswürdige Agent 120 und Geldmodul 6, anstatt als diskrete unverletztliche Komponenten ausgestaltet zu werden, als ein unverletzliches Modul gefertigt werden können. In diesem Fall müßte keine sichere Sitzung für die Kommunikation zwischen vertrauenswürdigem Agenten 120 und Geldmodul 6 in der gleichen Transaktionsvorrichtung 122 eingerichtet werden. Diskrete Geldmodule 6 und vertrauenswürdige Agenten 120 sind jedoch vorzuziehen, da eine derartige Konfiguration größere Anwendungsflexibilität zuläßt.
Siehe wieder Fig. 13: "zu Geldmodul A" sendet Nachricht "Zahlung leisten" und R(1) an sein ihm zugeordnetes Geldmodul A. Auch sendet "zu Geldmodul B" eine Nachricht "Zahlung erhalten" und R (2) an sein ihm zugeordnetes Geldmodul B (Schritte 538 - 544).
An diesem Punkt richten Geldmodul A (innerhalb der CTA 2) und Geldmodul B (innerhalb der MTA 4) zwischen sich eine Sitzung ein, so daß jedes Geldmodul 6 im Besitz des neuen Sitzungsschlüssels (MM/MM) abschließt (Schritt S46). Durch Einrichten dieser Geldmodul-Geldmodul-Sitzung tauschen die Geldmodule über die bereits bestehende Sitzung der vertrauenswürdigen Agenten Nachrichten aus. Der Sitzungsschlüssel für Verschlüsselungskanal 442, siehe Fig. 14, wird durch Austauschen von durch Kanal 436 verschlüsselten Nachrichten gebildet. Nach Einrichten der Geldmodul-Sitzung werden zwischen Geldmodulen gesendete Nachrichten entlang dem Teil des Kommunikationswegs zwischen den vertrauenswürdigen Agenten 120 zweifach verschlüsselt, sowohl mit Sitzungsschlüssel (MM/MM) als auch mit Sitzungsschlüssel (TA/TA).
In der bevorzugten Ausgestaltung wird die Geldmodul-Sitzung auf ähnliche Weise eingerichtet wie die Einrichtung einer Sitzung vertrauenswürdiger Agenten. Die Geldmodule 6 würden daher ihre eigenen, ihre öffentlichen Schlüssel enthaltenden Zertifikate halten. Das Tauschen von Zertifikaten und Zufallszahlen (für EXKLUSIV-ODER-Verknüpfung) ermöglicht die sichere Erstellung von Sitzungsschlüsseln (MM/MM). Das von Geldmodulen benutzte Protokoll "Sitzung einrichten" wird in WO-A-96/33476 erläutert und in Fig. 15 gezeigt. "Sicherheit A beibehalten" sendet das Modulzertifikat an den Session-Manager, und Session-Manager A erhält das Zertifikat und prüft, of Geldmodul A an das Netz angeschlossen ist (Schritte 1464-1466). Wenn Geldmodul A nicht an das Netz angeschlossen ist, dann sendet Session-Manager A das von "Sicherheit A beibehalten" erhaltene Zertifikat an Ziel B (Schritt 1476).
Oder aber, wenn Geldmodul A an das Netz angeschlossen ist, dann verschlüsselt der symmetrische Schlüssel A das Zertifikat mit K und Session-Manager A sendet das verschlüsselte Zertifikat zum Netz-Server (Schritte 1468-1472). Der Netz-Server entschlüsselt das Zertifikat mit K und sendet das Zertifikat an Ziel B.
Ungeachtet dessen, ob das Zertifikat vom Netz-Server oder von Session-Manager A gesendet wurde, erhält Session-Manager B das Zertifikat und "Sicherheit beibehalten B" (wenn B ein Sicherheits-Server ist, dann wird diese Aufgabe von dem Session- Manager durchgeführt) validiert das Zertifikat (Schritte 1480 - 1482). Wenn das Zertifikat nicht gültig ist, dann nimmt Session- Manager H zur Kenntnis, daß die Sitzung beendet wurde, und informiert entweder den Teilnehmer oder die Bank (Schritte 1486 - 1492) (wenn B ein Sicherheits-Server ist, dann nimmt B lediglich zur Kenntnis, daß die Transaktion beendet wurde).
Wenn das Zertifikat gültig ist, dann prüft "Sicherheit beibehalten H", ob A auf der Liste der schlechten Kennungen (ID) steht (Schritte 1494-1496). Wenn A auf der Liste steht, dann wird die Sitzung beendet. Wenn A nicht auf der Liste steht, dann erstellt Zufallsgenerator B Zufallszahl R(B) und eine B- Verifizierungsnachricht (Schritt 1498). Uhr/Zeitgeber B ruft die Uhrzeit und das Datum ab (Schritt 1500). "Sicherheit beibehalten B" stellt R (B), B-Verifizierungsnachricht sowie Uhrzeit und Datum zu einer Nachricht zusammen (Schritt 1502). "Öffentlicher Schlüssel B" verschlüsselt die Nachricht mit dem öffentlichen Schlüssel von A, und Session-Manager B fügt der verschlüsselten Nachricht das Zertifikat von B an und sendet die Nachricht an A (Schritte 1504-1506).
Session-Manager A erhält die Nachricht, "Öffentlicher Schlüssel A" entschlüsselt den verschlüsselten Teil der Nachricht und "Sicherheit beibehalten A" validiert das Zertifikat von B (Schritte 1508-1514). Wenn das Zertifikat nicht gültig ist, dann nimmt Session-Manager A die Beendigung der Sitzung zur Kenntnis und informiert entweder den Teilnehmer oder die Bank (Schritte 1516-1522). Wenn das Zertifikat gültig ist, dann prüft "Sicherheit beibehalten A", ob B auf der Liste der schlechten Kennungen (ID) steht (Schritte 1524-1526). Wenn B auf der Liste steht, dann wird die Sitzung beendet. Wenn B nicht auf der Liste steht, dann ruft "Sicherheit beibehalten A" das Datum und die Uhrzeit ab und vergleicht sie mit Datum und Uhrzeit von 3 (Schritte 1528-1530). Wenn das Datum und die Uhrzeit nicht übereinstimmen, dann wird die Sitzung beendet.
Wenn das Datum und die Uhrzeit übereinstimmen, dann erstellt Zufallsgenerator A Zufallszahl R(A) und eine A- Verifizierungsnachricht (Schritt 1532). "Sicherheit beibehalten A" bildet dann einen Sitzungsschlüssel durch EXKLUSIV-ODER- Verknüpfung von R (A) und R (B) (Schritt 1534). Die A- Verifizierungsnachricht, die H-Verifizierungsnachricht, die Uhrzeit, das Datum und R(A) werden zu einer Nachricht zusammengestellt und mit dem öffentlichen Schlüssel von B verschlüsselt (Schritt 1536). Die Nachricht wird von Session- Manager A an B gesendet (Schritt 1538). Session-Manager B erhält die Nachricht, "Öffentlicher Schlüssel B" entschlüsselt die Nachricht und "Sicherheit beibehalten B" prüft die B- Verifizierungsnachricht (Schritte 1540-1546). Wenn die B- Verifizierungsnachricht falsch ist, wird die Sitzung beendet. Wenn die B-Verifizierungsnachricht richtig ist, dann bildet "Sicherheit beibehalten B" den Sitzungsschlüssel durch EXKLUSIV- ODER-Verknüpfung von R (A) und R (B) (Schritt 1548). Die Uhrzeit und das Datum werden abgerufen und mit Uhrzeit und Datum von A verglichen, um zu prüfen, ob sie innerhalb eines vorbestimmten Bereichs zueinander liegen (Schritt 1550). Wenn Uhrzeit und Datum außerhalb des Bereichs liegen, dann wird die Sitzung beendet. Wenn Uhrzeit und Datum innerhalb des Bereichs liegen, dann nimmt
Session-Manager B den Sitzungsbeginn zur Kenntnis (Schritt 1552). Session-Manager B sendet dann eine Bestätigung und die A- Verifizierungsnachricht an A (Schritte 1554-1556). Session- Manager A erhält die Nachricht und "Sicherheit beibehalten A" prüft die A-Verifizierungsnachricht (Schritte 1558-1562). Wenn die Verifizierungsnachricht nicht richtig ist, wird die Sitzung beendet. Wenn die Verifizierungsnachricht richtig ist, dann nimmt Session-Manager A den Sitzungsbeginn zur Kenntnis (Schritt 1564).
Die Gesamtsystemsicherheit in Verbindung mit den Geldmodulen kann in die für die vertrauenswürdigen Agenten 120 integriert werden, ist aber vorzugsweise separat, um erhöhte Systemsicherheit und Systemflexibilität zu bieten.
Geldmodul A, siehe wieder Fig. 13, sendet R(1) an Geldmodul B. Diese Funktion kann von einer in Geldmodul A residenten Anwendung "mm Sicherheit beibehalten A" eingeleitet werden (Schritt S48). Diese Anwendung und andere Geldmodulanwendungen haben als Vorsatz die Bezeichnung "MM".
Zufallszahl R(1) wird durch die Subroutine "Übertragene Nachricht senden" (Schritt S50) von Geldmodul A an Geldmodul B gesendet. "mm symmetrischer Schlüssel A", siehe Fig. 16, verschlüsselt die Nachricht (einschließlich R(1)) mit Sitzungsschlüssel (mm/mm) (Schritt 640). mm Session-Manager A sendet die Nachricht an Host-Nachrichten-Manager A, der die Nachricht wiederum an Nachrichten-Schnittstelle A des vertrauenswürdigen Agenten A sendet (Schritt 642-646). Vertrauenswürdiger Agent A sendet dann die Nachricht mit Hilfe der Subroutine "Nachricht senden" (Schritt 648), die die Nachricht mit Sitzungsschlüssel (TA/TA) zwischen den vertrauenswürdigen Agenten verschlüsselt und entschlüsselt, an Nachrichten-Schnittstelle B des vertrauenswürdigen Agenten B. Nachrichten-Schnittstelle B sendet die Nachricht über Host- Nachrichten-Manager B dann an mm Session-Manager B in Geldmodul B (Schritte 650-654). Zuletzt entschlüsselt "MM symmetrischer Schlüssel B" die Nachricht mit Sitzungsschlüssel (MM/MM) (Schritt 656).
"MM Sicherheit beibehalten B" (in Geldmodul B), siehe wieder Fig. 13, bildet Sitzungsschlüssel (TA/MM) durch EXKLUSIV-ODER- Verknüpfung von R(1) und R(2). Geldmodul B sendet dann R(2) an Geldmodul A, das auch Sitzungsschlüssel (TA/MM) durch EXKLUSIVODER-Verknüpfung von R(1) und R(2) bildet (Schritte 552-556). An diesem Punkt, siehe Fig. 14, existieren drei Sitzungsschlüssel: (MM/MM), (MM/TA) und (TA/TA). Die gezeigten vier Verschlüsselungskanäle sind somit eingerichtet.
"MM zu Teilnehmer A", siehe Fig. 13, fordert vom vertrauenswürdigem Agenten A den Zahlungsbetrag nach Art der Geldscheine an (z. B. Dollar, Yen, Pfund usw.) (Schritt S58). Ein Geldmodul würde im allgemeinen die Anwendung "zu Teilnehmer" zur Kommunikation mit dem Besitzer/Inhaber des Geldmoduls benutzen. Wie im vorliegenden Fall benutzt, kommuniziert die Anwendung "zu Teilnehmer" aber zum Erhalten verschiedener Anweisungen mit dem vertrauenswürdigen Agenten 120. Hier liefert der vertrauenswürdige Agent 120 Zahlungsbetrag- und Geldscheinart- Informationen (vertrauenswürdiger Agent A hat zuvor mit dem Besitzer/Inhaber der CTD 2 kommuniziert, um den Betrag zu bestimmen).
Die Aufforderung vom Geldmodul 6 an den vertrauenswürdigen Agenten 120 wird über die Subroutine "MM/TA-Nachricht senden" gesendet (Schritt S60). Wie in Fig. 17 gezeigt, verschlüsselt "MM symmetrischer Schlüssel A" die Nachricht mit Sitzungsschlüssel (TA/MM) (Schritt 658). mm Session-Manager A sendet die Nachricht über Host-Nachrichten-Manager A zur Nachrichten-Schnittstelle des vertrauenswürdigen Agenten A (Schritte 660-664). Symmetrischer Schlüssel A entschlüsselt die Nachricht mit Sitzungsschlüssel (TA/MM) (Schritt 666). "Kauf A" von vertrauenswürdigem Agenten A, siehe wieder Fig. 13, sendet den Betrag (Preis der ausgewählten Ware) nach Geldscheinart an "mm bezahlen/wechseln A" des Geldmoduls A (Schritte 562-566). Diese Nachricht wird über die Subroutine "TA/mm Nachricht senden" gesendet (Schritt 564). Wie in Fig. 18 gezeigt, verschlüsselt "symmetrischer Schlüssel A" die Nachricht mit Sitzungsschlüssel (TA/mm) (Schritt 668). Nachrichten-Schnittstelle A sendet die Nachricht über Host- Nachrichten-Manager A zum mm Session-Manager des Geldmoduls A (Schritte 670-674). Zuletzt entschlüsselt "mm symmetrischer Schlüssel. A" die Nachricht mit Sitzungsschlüssel (TA/mm) (Schritt 676).
MM Scheineverzeichnis A, siehe Fig. 13, prüft, ob das Geldmodul 6 ausreichend Mittel für die Zahlung hat (Schritte 568 - 570). Reichen die Mittel nicht aus, dann brechen Geldmodule A und B die Transaktion ab (Schritte 572-582).
Das Protokoll "mm Transaktion abbrechen" (Schritt S82) kann das des bevorzugten elektronischen Währungssystems sein, wie in WO-A-96/33476 erläutert und in Fig. 19 gezeigt. Session-Manager X macht die Änderungen rückgängig und nimmt zur Kenntnis, daß die Transaktion abgebrochen wurde (Schritt 1726). Session-Manager X prüft dann, ob die "Zusagebereit"-Nachricht gesendet wurde (Schritte 1728-1730). Wenn ja, dann aktualisiert X sein Transaktionenprotokoll (Schritt 1732) durch Aufzeichnen, daß X nach Senden einer Zusagebereit-Nachricht und Aufzeichnen der Scheinekennungen und der Beträge der einzelnen Geldscheine, die während des Geldschein-Transfer-Protokolls erhalten wurden, zusagte. Das Abbruchprotokoll protokolliert somit Informationen, wenn die Abbruch-Subroutine während einer erfolglosen Zusage- Subroutine aufgerufen wird.
Wenn X ein Transaktionsgeldmodul 1186 ist und die Zusagebereit-Nachricht gesendet wurde, dann informiert "zu Teilnehmer X" seinen Teilnehmer, daß die Transaktion abgebrochen wurde und daß es eventuell einen Geldtransfer-Fehler gegeben hat (Schritte 1734-1738).
Wenn X ein Kassen-Geldmodul 1188 [sic...*2] ist, dann informiert "zu Bank X" die Bank, daß sie ihre Buchhaltungsvorgänge (durch entsprechende Belastungen und Gutschriften) rückgängig machen sollte (Schritte 1740-1742). Wenn X ein Transaktionsgeldmodul 1186 [sic...*3] ist und keine Zusagebereit-Nachricht gesendet wurde, dann informiert "zu Teilnehmer X" den Teilnehmer, daß die Transaktion abgebrochen wurde (Schritt 1744).
Auf jeden Fall sendet Session-Manager X dann eine Nachricht an Y, daß die Transaktion nicht abgeschlossen werden kann (Schritte 1746-1748). Session-Manager Y macht seine Änderungen rückgängig (Rollback) und nimmt zur Kenntnis, daß die Transaktion abgebrochen wurde (Schritt 1750). Y informiert dann seinen Teilnehmer, daß die Transaktion abgebrochen wurde (Schritte 1752 - 1754) oder informiert die Bank, ihren Buchhaltungsvorgang rückgängig zu machen (Schritte 1756-1758).
Wie erläutert, ist es möglich, daß Geldscheine verlorengehen, wenn eine Transaktion während eines Zusage- Protokolls unterbrochen wird. Tritt dies ein, hat der Übertragungsempfänger die Transaktion abgebrochen und der Übertragende zum Geldscheinetransfer zugesagt. In diesem Fall zeichnet das Geldmodul des Übertragungsempfängers Informationen über die Geldscheine auf, die es erhalten haben sollte, und benachrichtigt den Teilnehmer, daß ein potentielles Problem vorliegt (d. h. daß es die von A gesendeten Geldscheine nicht erhalten hat). Es ist zu beachten, daß unter diesen Umständen, was das Geldmodul des Übertragenden betrifft, die Geldscheine ordnungsgemäß transferiert wurden.
Der Teilnehmer des Empfänger-Geldmoduls kann dann bei der Zertifizierungsagentur Anspruch auf das Geld erheben. Die Anspruchinformationen würden die Protokollaufzeichnung der Fehltransaktion beinhalten. Die Zertifizierungsagentur könnte dann bei den ausstellenden Banken nachfragen, um herauszufinden, ob eine Abstimmung der Geldscheine stattfand. Nach einiger Zeit, wenn die Geldscheine nicht abgestimmt wurden, könnte der Teilnehmer sein Geld zurückfordern.
Die Nachrichten zwischen Geldmodul A und Geldmodul B, siehe wieder Fig. 13, werden über eine Subroutine "E-übertragene Nachricht senden" gesendet, die alle drei Sitzungsschlüssel (MM/MM), (TA/MM) und (TA/TA) einsetzt. Wie Fig. 20 zeigt, verschlüsselt "MM symmetrischer Schlüssel A" eine Nachricht mit Sitzungsschlüssel (MM/MM) (Schritt 678). Die Nachricht wird dann von Sitzungsschlüssel (MM/TA) doppelt verschlüsselt, bevor sie an den vertrauenswürdigen Agenten A gesendet wird. Wenn der vertrauenswürdige Agent A sie erhalten hat, wird die Nachricht von Sitzungsschlüssel (MM/TA) entschlüsselt (Schritt 680). Die Nachrichten-Schnittstelle A sendet die Nachricht dann an die Nachrichten-Schnittstelle B (Schritte 682-684). Zwischen den vertrauenswürdigen Agenten 120 wird die Nachricht von Sitzungsschlüssel (TA/TA) doppelt verschlüsselt. Nachrichten- Schnittstelle B sendet die Nachricht gleichermaßen an "MM symmetrischer Schlüssel B" zur abschließenden Entschlüsselung (Schritte 686-690). Fig. 14 illustriert die verschiedenen Verschlüsselungsschichten.
Während der Abbruch-Routinen der Geldmodule A und B (Schritt 582), siehe wieder Fig. 13, erstellen sie an ihre vertrauenswürdigen Agenten A beziehungsweise B gesendete Nachrichten (Schritt S84-586), die sie informieren, daß sie die Transaktion abgebrochen haben und die Zahlung daher erfolglos war. Die Session-Manager A und B nehmen zur Kenntnis, daß die Zahlung erfolglos war, und folglich brechen die vertrauenswürdigen Agenten A und B die Transaktion ab (Schritte 588-598).
Wenn andererseits das Geldmodul 2 des Kunden ausreichend Mittel hat, dann sendet "MM bezahlen/wechseln A" eine Nachricht an das Geldmodul des Händlers, die den zur Zahlung zu transferierenden Geldbetrag und die Art der Geldscheine enthält (Schritt 600). Diese Nachricht wird mit der Subroutine "Eübertragene Nachricht senden" gesendet (Schritt 602).
Geldmodul B empfängt die Nachricht, die den Zahlungsbetrag gemäß Geldmodul A empfängt. "MM zu Teilnehmer B" sendet dann eine Aufforderung an den vertrauenswürdigen Agenten B zum Verifizieren dieses Zahlungsbetrags (Schritte 604-606). "Kauf B" im vertrauenswürdigen Agenten B verifiziert entsprechend, ob der Betrag korrekt ist (Schritte 608-610). Ist er korrekt, dann sendet der vertrauenswürdige Agent B eine "Betrag korrekt"- Nachricht an Geldmodul B. Ist er falsch, dann wird eine "Betrag nicht korrekt"-Nachricht gesendet (Schritte 612-616). Im Fall einer "Betrag nicht korrekt"-Nachricht informiert Geldmodul B Geldmodul A, das wiederum seinen vertrauenswürdigen Agenten auffordert, einen neuen Betrag zu senden oder ansonsten einen Abbruch vorzunehmen (Schritte 618-622, 572-582). Bei während eines elektronischen Warenkaufs getätigten Geldmodulzahlungen sendet der vertrauenswürdige Agent keinen neuen Betrag, und somit nehmen beide Geldmodule 6 und beide vertrauenswürdigen Agenten 120 einen Abbruch vor.
Wenn Geldmodul B andererseits eine "Betrag korrekt"- Nachricht von seinem vertrauenswürdigen Agenten erhält, dann sendet Geldmodul B eine Bestätigungsnachricht an das Geldmodul des Kunden zurück (Schritte 624-626). Wenn "mm bezahlen/wechseln A" die Bestätigungsnachricht erhält, leitet es den Betrag dann an Geldinhaber A weiter (die Anwendung, die die elektronischen Gelddarstellungen enthält und verwaltet) (Schritt 628).
Es ist zu beachten, daß das gerade erläuterte, vom Zahler eingeleitete Protokoll stattdessen auch als eine vom Zahlungsempfänger eingeleitete Zahlung wie im POS- Zahlungsprotokoll implementiert werden kann. In einem derartigen Protokoll unterrichtet der vertrauenswürdige Agent des Händlers sein Geldmodul bezüglich des Zahlungsbetrags, den er zu erhalten erwartet, diese Zahlungsinformation wird zum Geldmodul des Kunden gesendet, das seinen vertrauenswürdigen Agenten zum Verifizieren auffordert, und wenn der Betrag korrekt ist, dann informiert der vertrauenswürdige Agent des Kunden sein Geldmodul.
Das Kunden-Geldmodul A, siehe wieder Fig. 13, transferiert dann elektronische Geldscheine im Wert des angegebenen Betrags über den Weg der "E-übertragene Nachrichten" zum Geldmodul des Händlers 4 (Schritt 630). Fig. 21 zeigt ein Geldschein-Transfer- Protokoll, wie in WO-A-96/33476 erläutert. Scheineverzeichnis X wählt den/die Geldschein(e) und Werte für den Transfer, aktualisiert den Scheine-Betrag/die Scheine-Beträge und die laufende(n) Nummer(n) und sendet dann die Nachricht an "Scheine" (Schritt 1566). Mögliche Aufgaben bei der Wahl der Geldscheine für den Transfer können z. B. die folgenden sein: (1) Minimieren der Anzahl digitaler Signaturen (was Bearbeitungszeit erfordert); (2) Minimieren der Paketgröße; (3) Maximieren der Nützlichkeit der dem transferierenden Teilnehmer verbleibenden elektronischen Scheine (d. h. Weitergeben der Scheine mit der kürzesten Zeit bis zum Verfalldatum). Derartige Aufgaben können durch den folgenden Scheinetransfer-Algorithmus gelöst werden: (1) alle möglichen Alternativen bestimmen, die die kleinste Scheinezahl enthalten; (2) bestimmen, welche dieser Alternativen die geringste Anzahl von Transfers haben; (3) wenn von Schritt 2 noch mehr als eine Möglichkeit zur Auswahl steht, ist die zu wählen, die die geringste Anzahl von Währungseinheitstagen hat. Währungseinheitstage = Restwert eines zu transferierenden Geldscheins multipliziert mit der Anzahl von bis zum Verfall des Geldscheins verbleibenden Tagen, für alle Geldscheine im Paket summiert.
Nach Erhalt der Nachricht von Scheineverzeichnis X erstellt "Scheine X" ein an jeden zu transferierenden Schein anzufügendes Transfer (Schritt 1568). Öffentlicher Schlüssel X erstellt Signaturen für den/die Schein(e) (Schritt 1570). Paket-Manager X stellt den/die Schein(e) dann mit seinem/seinen/ihren neuen Transfer(s) und Signatur(en) zu einem Paket zusammen und sendet das Paket an Y (Schritte 1572-1574). Paket-Manager Y erhält das Paket und zerlegt es (Schritt 1576).
"Verifizieren Y" [sic...*4] validiert alle Zertifikate in dem Schein/den Scheinen (z. B. Geldgeneratorzertifikat und alle Transferzertifikate). "Verifizieren Y" verifiziert dann, daß die Kennummern in der Transfergruppe mit den Modulkennummern der Zertifikate in der Signatur- und Zertifikatgruppe während der ganzen Historie des elektronischen Geldscheins übereinstimmen. Außerdem wird die Übereinstimmung der Transferbeträge für jeden Geldschein validiert, indem sichergestellt wird, daß während der ganzen Historie des elektronischen Geldscheins der in jedem sukzessiven Transfer transferierte Betrag kleiner ist als der des unmittelbar vorangehenden Transfers. Darüber hinaus wird der gesamte transferierte Betrag geprüft, um sicherzustellen, daß es der erwartete Betrage ist (Schritte 1578-1580). Wenn ungültig, dann wird die Transaktion abgebrochen (Schritt 1582).
Wenn gültig und wenn Y ein Transaktionsgeldmodul ist, dann prüft Verifizierer Y die Verfalldaten des Scheins/der Scheine (Schritte 1584-1588). Wenn ein Geldschein verfallen ist, dann wird die Transaktion abgebrochen. Ist kein Geldschein verfallen, dann vergleicht Verifizierer Y jede Kennung (ID) von den Scheinetransfers mit der Liste der schlechten ID (Schritte 1590 - 1592). Steht eine der Transfer-Kennungen auf der Liste der schlechten ID, dann wird die Transaktion abgebrochen.
Wenn die Transfer-Kennungen nicht auf der Liste der schlechten ID stehen (oder Y kein Transaktionsgeldmodul ist), dann verifiziert "öffentlicher Schlüssel Y" die Gültigkeit der Scheinesignaturen nach (Schritte 1594-1596). Wenn eine der Signaturen nicht gültig ist, dann wird die Transaktion abgebrochen. Wenn die Signaturen gültig sind, dann prüft Verifizierer Y, ob die Geldscheinekörper mit Geldscheinekörpern übereinstimmen, die von der Anwendung "Scheine" gespeichert werden oder sich im Tran.-Protokoll (Schritte 1598-1600) befinden. Für jeden übereinstimmenden Geldscheinekörper wird ein Scheinetransferbaum erstellt, um zu bestimmen, ob es eine Scheineduplikation gegeben hat (Schritte 1602-1604). Wenn Geldscheine dupliziert wurden, dann wird die Transaktion abgebrochen. Diese Prüfung auf Duplikation (d. h. Schritte 1598 - 1604) ist insbesondere darauf ausgerichtet und gut geeignet, Personen, die versuchen, Geld durch Transferieren von Geldscheinen durch "Selbstzuteilen" mit Hilfe eines manipulierten Transaktionsgeldmoduls zu erstellen, einen Strich durch die Rechnung zu machen.
Wenn es keine Duplikate gibt oder wenn keine Scheinekörperübereinstimmungen identifiziert wurden, dann legt "Scheine Y" den/die Geldscheine in den Geldhalter (Schritt 1606). Zuletzt aktualisiert Scheineverzeichnis Y die Position(en) und den Betrag/die Beträge des/der Geldscheine(e) und initialisiert zudem die laufend(en) Nummer(n) (Schritt 1608).
Es kann sich verstehen, daß der Scheinetransferprozeß Schritte zum Aktualisieren und Initialisieren einer laufenden Nummer zum Ermöglichen der Geldscheinabstimmung, zum Prüfen, ob der Transferempfänger eines Geldscheins auf der Liste schlechter Kennungen (ID) steht, und zum Prüfen auf Scheineduplikation beinhaltet. Diese zusätzlichen Merkmale und Schritte machen es schwierig für Widersacher, duplizierte Geldscheine einzuführen und in Umlauf zu bringen, und verbessern die Fähigkeit, in Umlauf befindliche duplizierte Geldscheine festzustellen.
Es wird, siehe wieder Fig. 13, eine "mm Zusage"-Subroutine aufgerufen (Schritt 632). Ein Zusage-Protokoll, wie im bevorzugten elektronischen Währungssystem verwendet, wird in 08/427,287 erläutert und in Fig. 22 gezeigt. Session-Manager X sendet eine "Zusagebereit"-Nachricht an Y (Schritte 1702-1704). Dadurch wird die Verpflichtung zur Zusage an das Modul übergeben, das die Nachricht erhält. In einem konventionellen Geldtransfer- Szenario wird diese Methode des Weitergebens der Last der ersten Zusage verwendet, um sicherzustellen, daß die geldüberweisende Partei zuerst zusagt, um dadurch die Möglichkeit einer Duplizierung von Geld auszuschließen.
Session-Manager Y sendet dann eine Bestätigung an X (Schritte 1706-1708) und gibt die Zusage zu allen ausstehenden Transaktionen, indem er sein Transaktionenprotokoll aktualisiert (Schritt 1710). Außerdem informiert "zu Teilnehmer Y", wenn Y ein Transaktionsgeldmodul ist, den Teilnehmer über die erfolgreiche Transaktion (Schritte 1712-1714). Session-Manager Y nimmt das Ende der Sitzung zur Kenntnis (Schritt 1716.)
Tran.-Protokoll X erhält die Bestätigung von Y und aktualisiert sein Transaktionenprotokoll, wodurch es zu allen ausstehenden Überweisungen zusagt. X vervollständigt seine Zusage auf die gleiche Weise wie Y (Schritte 1718-1724).
Dieses Ablaufdiagramm wird auch dann noch eingehalten, wenn Geldmodule 6 mit vertrauenswürdigen Agenten 120 zusammenwirken, wobei davon ausgegangen wird, daß "Nachricht senden" - "Eübertragene Nachricht senden" und daß "zu Teilnehmer"-Nachrichten in Wirklichkeit verschlüsselt an den vertrauenswürdigen Agenten 120 gesendet werden. Der mm Session-Manager des Geldmoduls B, unter Beachtung des vorangehenden, sendet über die Subroutine "Eübertragene Nachricht senden" eine "Zusagebereit"-Nachricht an den mm Session-Manager des Geldmoduls A (Schritte 1702-1704). mm Session-Manager A sendet dann eine Nachricht "Bestätigung" an Geldmodul B und Geldmodul A gibt seine Zusage (Schritte 1706 - 1716). Wenn Geldmodul B die Nachricht "Bestätigung" erhält, gibt es auch seine Zusage (Schritte 1718-1724).
Während der Zusageroutinen der Geldmodule A und B erstellen sie an ihre vertrauenswürdigen Agenten A bzw. B gesendete Nachrichten (Schritte 1714, 1722), in denen sie diese informieren, daß sie ihre Zusage zur Transaktion gegeben haben und daß die Zahlung somit erfolgreich war.
Beide Geldmodule, siehe wieder Fig. 13, senden dann die oben erwähnten Nachrichten "Zahlung erfolgreich" an ihre vertrauenswürdigen Agenten (Schritte 584-586). Diese Nachrichten werden mit dem Sitzungsschlüssel (TA/mm) verschlüsselt. Session-Manager A stellt fest, daß eine erfolgreiche Zahlung getätigt wurde, und Ticketinhaber A aktualisiert das Empfangsticket mit Zahlungsinformationen, wie dem Datum der Transaktion (Schritte 588, 592, 634). Der vertrauenswürdige Agent A gibt dann seine Zusage (Schritt 636), so daß er das Ticket nicht mehr nur "vorläufig" hält. Session- Manager B stellt gleichermaßen eine erfolgreiche Zahlung fest (Schritte 590, 594), und der vertrauenswürdige Agent B gibt seine Zusage (Schritt 638). Die Transaktion ist jetzt abgeschlossen.
Ticketinhaber A, wieder bezugnehmend auf Fig. 8, sendet die kommerzielle Zahlungsanweisung (Ticket) an die HTA (Schritt 764). Die HTA erhält das Ticket und sendet das Ticket und die Überweisungsanzeige als Zahlungsbeleg an das Kreditorensystem 189 (Schritt 766). Ticketinhaber B sendet die kommerzielle Zahlungsanweisung (Ticket) an die HTB (Schritt 768). Die HTB erhält das Ticket und sendet das Ticket und die Überweisungsanzeige an das Debitorensystem 193 zum Abstimmen auf offenstehende Rechnungen. Diese Abstimmfunktion könnte aber auch während der Zahlungstransaktion durchgeführt werden.
In der vorliegenden Offenlegung wird die bevorzugte Ausgestaltung der Erfindung gezeigt und beschrieben, wobei es sich versteht, daß die Erfindung in verschiedenen anderen Kombinationen und Umgebungen verwendet werden kann.

Claims

1. System für elektronischen kommerziellen Zahlungsverkehr, das folgendes umfaßt:

einen vertrauenswürdigen Kunden-Agenten (2);

ein mit dem genannten vertrauenswürdigen Kunden-Agenten assoziiertes erstes Geldmodul (6), das sicher mit dem genannten vertrauenswürdigen Kunden-Agenten kommuniziert;

einen vertrauenswürdigen Händler-Agenten (4), der eine erste kryptographisch sichere Sitzung mit dem genannten vertrauenswürdigen Kunden-Agenten einrichtet;

ein mit dem genannten vertrauenswürdigen Händler-Agenten assoziiertes zweites Geldmodul (6), das sicher mit dem genannten vertrauenswürdigen Händler-Agenten kommuniziert und das eine zweite kryptographisch sichere Sitzung mit dem genannten ersten Geldmodul einrichtet;

bei dem der genannte vertrauenswürdige Kunden-Agent (2) dem genannten vertrauenswürdigen Händler-Agenten eine Überweisungsanzeigeinformation liefert und der genannte vertrauenswürdige Händler-Agent (4) dem genannten vertrauenswürdigen Kunden-Agenten eine kommerzielle Zahlungsanweisung liefert;

wobei der genannte vertrauenswürdige Kunden-Agent nach Erhalt der genannten kommerziellen Zahlungsanweisung einen Transfer von elektronischem Geld von dem genannten ersten Geldmodul zu dem genannten zweiten Geldmodul einleitet.

2. System nach Anspruch 1, bei dem der genannte vertrauenswürdige Händler-Agent eine digitale Signatur über die genannte Überweisungsanzeigeinformation generiert und die genannte digitale Signatur in die genannte kommerzielle Zahlungsanweisung einschließt.

3. System nach Anspruch 2, bei dem der genannte vertrauenswürdige Kunden-Agent nach Erhalten der genannten kommerziellen Zahlungsanweisung die genannte digitale Signatur verifiziert, bevor er den genannten Transfer von elektronischem Geld einleitet.

4. System nach Anspruch 3, bei dem die genannte Überweisungsanzeigeinformation eine Liste von Rechnungen aufweist.

5. Verfahren für elektronische kommerzielle Zahlungen unter Einsatz eines vertrauenswürdigen Kunden-Agenten (2), eines ersten Geldmoduls (6), eines vertrauenswürdigen Händler-Agenten (4) und eines zweiten Geldmoduls (6), das folgende Schritte umfaßt:

(a) Einrichten einer ersten kryptographisch sicheren Sitzung zwischen dem genannten vertrauenswürdigen Kunden-Agenten und dem genannten vertrauenswürdigen Händler-Agenten;

(b) Transfer einer Überweisungsanzeigeinformation durch den genannten vertrauenswürdigen Kunden-Agenten über die genannte erste kryptographisch sichere Sitzung zu dem genannten vertrauenswürdigen Händler-Agenten;

(c) Erstellen einer kommerziellen Zahlungsanweisung durch den genannten vertrauenswürdigen Händler-Agenten, die, wenigstens teilweise, die genannte Überweisungsanzeigeinformation beinhaltet;

(d) Transfer der genannten kommerziellen Zahlungsanweisung durch den genannten vertrauenswürdigen Händler-Agenten über die genannte erste kryptographisch sichere Sitzung zu dem genannten vertrauenswürdigen Kunden-Agenten, der die genannte Anweisung vorläufig einbehält;

(e) Einrichten einer zweiten kryptographisch sicheren Sitzung zwischen dem genannten ersten Geldmodul und dem genannten zweiten Geldmodul;

(f) Transfer von elektronischem Geld durch das genannte erste Geldmodul über die genannte zweite kryptographisch sichere Sitzung zu dem genannten zweiten Geldmodul, das das genannte elektronische Geld vorläufig einbehält;

(g) Zusage des genannten ersten Geldmoduls und sicheres Informieren des genannten vertrauenswürdigen Kunden-Agenten über den erfolgreichen Transfer von elektronischem Geld;

(h) Zusage des genannten zweiten Geldmoduls, woraufhin das genannte Einbehalten des genannten elektronischen Geldes nicht mehr vorläufig ist, und sicheres Informieren des genannten vertrauenswürdigen Händler-Agenten über den erfolgreichen Erhalt des elektronischen Geldes;

(i) Zusage des genannten vertrauenswürdigen Kunden-Agenten, woraufhin das genannte Einbehalten der genannten kommerziellen Zahlungsanweisung nicht mehr vorläufig ist, und

(j) Zusage des genannten vertrauenswürdigen Händler-Agenten.

6. Verfahren nach Anspruch 5, bei dem der genannte vertrauenswürdige Händler-Agent eine digitale Signatur über die genannte Überweisungsanzeigeinformation generiert und die genannte digitale Signatur in die genannte kommerzielle Zahlungsanweisung einschließt.

7. Verfahren nach Anspruch 6, das des weiteren den folgenden Schritt aufweist: Verifizieren der genannten digitalen Signatur durch den genannten vertrauenswürdigen Kunden-Agenten vor Einleiten des genannten Transfers von elektronischem Geld.

8. System zum sicheren Verbinden von elektronischen kommerziellen Zahlungen mit Überweisungsanzeigeinformationen über ein Kommunikationsnetzwerk, das folgendes aufweist:

einen unverletzlichen ersten elektronischen Agenten mit einem ersten Prozessor;

ein unverletzliches erstes Geldmodul, das mit dem genannten ersten elektronischen Agenten assoziiert ist und sicher mit ihm kommuniziert und das einen zweiten Prozessor hat;

einen unverletzlichen zweiten elektronischen Agenten, der über das genannte Kommunikationsnetzwerk eine erste kryptographisch sichere Sitzung mit dem genannten ersten elektronischen Agenten einrichtete [sic...*1] und der einen dritten Prozessor hat;

ein unverletzliches zweites Geldmodul, das mit dem genannten zweiten elektronischen Agenten assoziiert ist und sicher mit ihm kommuniziert und das eine zweite kryptographisch sichere Sitzung mit dem genannten ersten Geldmodul einrichtet und das einen vierten Prozessor hat;

wobei der genannte erste Prozessor ausgestaltet ist, um eine Überweisungsanzeigeinformation über die genannte erste kryptographisch sichere Sitzung zu dem genannten zweiten elektronischen Agenten zu transferieren;

wobei der genannte dritte Prozessor eine kommerzielle Zahlungsanweisung auf der Grundlage der genannten Überweisungsanzeigeinformation erstellt und die genannte kommerzielle Zahlungsanweisung über die genannte erste kryptographisch sichere Sitzung zu dem genannten ersten elektronischen Agenten transferiert;

wobei der genannte erste Prozessor nach Verifizieren der genannten kommerziellen Zahlungsanweisung eine Zahlung von elektronischem Geld von dem genannten ersten Geldmodul an das genannte zweite Geldmodul veranlaßt.

9. Kommerzielles Zahlungssystem nach Anspruch 8, bei dem der genannte dritte Prozessor eine digitale Signatur über die genannte Überweisungsanzeigeinformation bildet und die genannte digitale Signatur in die genannte kommerzielle Zahlungsanweisung einschließt.

10. Kommerzielles Zahlungssystem nach Anspruch 9, bei dem die genannte Überweisungsanzeigeinformation eine Liste von Rechnungen aufweist.

11. Kommerzielles Zahlungssystem nach Anspruch 10, bei dem mit Rechnungen der genannten Liste assoziierte Beträge summiert und mit einem in der genannten Überweisungsanzeigeinformation enthaltenen Gesamtbetrag verglichen werden.

12. System zum sicheren Verbinden elektronischer kommerzieller Zahlungen mit Überweisungsanzeigeinformationen, das folgendes umfaßt:

eine unverletzliche erste elektronische Transaktionsvorrichtung mit einem ersten Prozessor;

eine unverletzliche zweite Transaktionsvorrichtung, die einen zweiten Prozessor aufweist und über eine kryptographisch sichere Sitzung mit der genannten ersten elektronischen Transaktionsvorrichtung kommuniziert;

wobei der genannte erste Prozessor ausgestaltet ist, um eine Überweisungsanzeigeinformation, die eine Liste von Rechnungen aufweist, zu der genannten zweiten elektronischen Transaktionsvorrichtung zu transferieren;

wobei der genannte zweite Prozessor wenigstens Teil der genannten Überweisungsanzeigeinformation mit einer digitalen Signatur versieht und die genannte digitale Signatur in eine kommerzielle Zahlungsanweisung integriert;

wobei der genannte zweite Prozessor die genannte kommerzielle Zahlungsanweisung zu der genannten ersten elektronischen Transaktionsvorrichtung transferiert und wobei die genannte erste elektronische

Transaktionsvorrichtung elektronisches Geld zu der genannten zweiten elektronischen Transaktionsvorrichtung transferiert, wodurch eine Abschlußzahlung vom Zahler an den Zahlungsempfänger ohne Dritt-Vermittler vervollständigt wird.

13. Kommerzielles Zahlungssystem nach Anspruch 12, bei dem die genannte kommerzielle Zahlungsanweisung als Zahlungsbeleg an ein rechnerimplementiertes Kreditorensystem gesendet wird.

14. Kommerzielles Zahlungssystem nach Anspruch 12, bei dem die genannte zweite elektronische Transaktionsvorrichtung die genannte Überweisungsanzeigeinformation an ein rechnerimplementiertes Debitorensystem zum Abstimmen auf offenstehende Rechnungen sendet.

15. Kommerzielles Zahlungssystem nach Anspruch 12, bei dem die genannte erste elektronische Transaktionsvorrichtung die genannte digitale Signatur vor dem Einleiten des genannten Transfers von elektronischem Geld verifiziert.

16. Kommerzielles Zahlungssystem nach Anspruch 12, bei dem die genannte erste elektronische Transaktionsvorrichtung die Gültigkeit einer mit der genannten zweiten elektronischen Transaktionsvorrichtung assoziierten elektronischen Händlerreferenz prüft.