DE69632482T2 - Elektronisches geldsystem ohne ursprungserkennung - Google Patents

Elektronisches geldsystem ohne ursprungserkennung Download PDF

Info

Publication number
DE69632482T2
DE69632482T2 DE69632482T DE69632482T DE69632482T2 DE 69632482 T2 DE69632482 T2 DE 69632482T2 DE 69632482 T DE69632482 T DE 69632482T DE 69632482 T DE69632482 T DE 69632482T DE 69632482 T2 DE69632482 T2 DE 69632482T2
Authority
DE
Germany
Prior art keywords
party
image
bank
seller
money
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE69632482T
Other languages
English (en)
Other versions
DE69632482D1 (de
Inventor
R. Daniel SIMON
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Microsoft Corp
Original Assignee
Microsoft Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Microsoft Corp filed Critical Microsoft Corp
Application granted granted Critical
Publication of DE69632482D1 publication Critical patent/DE69632482D1/de
Publication of DE69632482T2 publication Critical patent/DE69632482T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G06Q20/042—Payment circuits characterized in that the payment protocol involves at least one cheque
    • G06Q20/0425—Payment circuits characterized in that the payment protocol involves at least one cheque the cheque being electronic only
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/22—Payment schemes or models
    • G06Q20/24—Credit schemes, i.e. "pay after"
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3678—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes e-cash details, e.g. blinded, divisible or detecting double spending
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3825—Use of electronic signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/383—Anonymous user system
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
    • G07F7/1016—Devices or methods for securing the PIN and other transaction-data, e.g. by encryption

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Finance (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Radar Systems Or Details Thereof (AREA)
  • Testing Of Coins (AREA)
  • Inspection Of Paper Currency And Valuable Securities (AREA)
  • Character Discrimination (AREA)
  • Reverberation, Karaoke And Other Acoustics (AREA)
  • Cash Registers Or Receiving Machines (AREA)
  • Detergent Compositions (AREA)

Description

  • Die Erfindung bezieht sich generell auf elektronische Geldsysteme.
  • Das instinktive Endziel eines elektronischen Geldsystems ist, die besten Merkmale realen Gelds (Geheimhaltung, Anonymität, Fälschungssicherheit) mit den besten Merkmalen von E-Commerce (Geschwindigkeit, Leichtigkeit und potenzielle Sicherheit von Transport und Lagerung) zu kombinieren. Das grundlegende Problem beim Versuch ein anonymes elektronisches Geldsystem zu implementieren, lässt sich aber leicht nennen: Wenn der Besitzer bzw. die Besitzerin einer elektronischen "Münze" nicht in zwei aufeinander folgenden Transaktionen identifiziert wird, wie soll dann er bzw. sie daran gehindert werden, so zu handeln, als ob die erste Transaktion nie geschah und die gleiche Münze erneut auszugeben? Die erste vorgeschlagene Lösung dieses Problems wurde von Chaum, Fiat und Naor (siehe D. Chaum, A. Fiat und M. Naor, Untraceable Electronic Cash, Prot. CRYPTO '88, Springer-Verlag (1990), pp. 319–327.) vorgelegt und beruhte auf der Prämisse, dass es ausreichend wäre, ein solches „doppeltes Ausgeben", nach zweimaligem Vorlegen derselben „elektronischen Münze" bei der Zentralbank, zu erkennen und den Ausgebenden zu identifizieren. Diese Prämisse wurde ebenso mehrere Male verwendet, jeweils mit dem Vorteil, dass die Bank nicht in jede Transaktion verwickelt sein braucht. Konkret gesagt, hat diese Prämisse aber enorme Nachteile. Betrügerische Transaktionen werden erst lange nach Stattfinden festgestellt und, wenn der Täter zuversichtlich sein kann, nicht vor Gericht gebracht zu werden (entweder dadurch, dass kein Zugriff auf ihn möglich ist oder er es schafft, Identität und Geld von jemand anderem zu benutzen), dann kann er oder sie beliebig doppelt ausgeben.
  • Wenn aber derartige betrügerische Verwendung von elektronischem Geld verhindert werden soll, dann muss irgendeine Behörde irgendwie in jede Transaktion verwickelt sein, sowie diese stattfindet, um Zielpersonen von Doppelausgabe erkennen und alarmieren zu können. Wie lässt sich dann Anonymität bewahren? Ein Ansatz ist Verlass auf missbrauchsichere Hardware, um Ausgebende zu zwingen, sich „ehrlich" zu benehmen und nicht doppelt auszugeben) (siehe, beispielsweise, S. Even, O. Goldreich und Y. Yacobi, Electronic Wallet, Proc. CRYPTO '83, Plenum Press (1984), PP. 383–386). Auf dieser Prämisse beruhende Programme sind aber äußerst "empfindlich". Wenn sich jemand erfolgreich an der Hardware zu schaffen gemacht hat, dann ist diese Person nicht nur der Doppelausgabe fähig, sondern jeder, irgendwo, der sich die in der Hardware enthaltenen Informationen beschafft (vielleicht, z. B. kauft), kann willkürlich hohe Beträge nach Belieben ausgeben. Heutige Technologie in Bezug auf Missbrauchsicherheit ist weit davon entfernt, ausreichend verlässlich zu sein, dass man ihr trauen kann, solch ein enormes Risiko zu vereiteln.
  • Ein weiterer Ansatz ist kryptografisch. Beispielsweise ist es unter gewissen sehr starken kryptografischen Voraussetzungen möglich, Protokolle zu konstruieren, die „blinde" Geld-Informationen erstellen, die später als gültiges Geld erkannt, aber nicht mit irgendeinem besonderen Ablauf des Protokolls in Verbindung gebracht werden können. (Siehe, beispielsweise, D. Chaum, Privacy Protected Payments-Unconditional Payer and/or Payee untraceability, SMART CARD 2000: The future of IC Cards-Proc. IFIP WG 11.6 Intl Conf., North-Holland (1989). pp. 69–93; und D. Chaum, Online Cash Checks Proc. Eurocrypt '89, Springer-Verlag (1989), pp. 288–293.
  • US 4,914,698 beschreibt ein kryptografisches System und ein digitales Unterschriftssystem mit öffentlichem Schlüssel, das „Unverknüpfbarkeit" bereitstellt. Ein Objekt der US 4,914,698 ist, ein digitales Unterschriftssystem mit Schlüssel bereitzustellen, das es einer ersten Partei ermöglicht, Unterschriften an eine zweite Partei auszustellen, und das es der zweiten Partei erlaubt sie einer dritten Partei bereitzustellen, wobei Kooperation der ersten und dritten Partei nicht in der Lage ist, zweite Parteien zurückzuverfolgen und jede Unterschrift nicht mehr als einmal gezeigt wird. Die Offenbarung der US 4,914,698 verlässt sich auf ein „blindes Unterschriftssystem" und um eine Blindsicherheit zu erzielen, ist intensive patenverarbeitung erforderlich.
  • Die US 4,937,593 bezieht sich ebenso auf ein „blindes" elektronisches Geldsystem, und sowohl die US 4,914,698 als auch die US 4,987,593 erfordern blinden Transfer zwischen einer Partei und einer Bank, zusammen mit mehrfachen Verifizierungsschritten, um zu überprüfen, dass Transfers erfolgreich und sicher gewesen sind.
  • Zusammenfassung der Erfindung
  • Wir stellen ein einfaches, praktisches, elektronisches Online-Geldsystem beruhend auf der Annahme eines Netzes vor, in dem anonyme Kommunikation ohne Ursprungserkennung möglich ist. Im Allgemeinen verwendet die Erfindung zwei einfache graphische Grundformen, nämlich eine Einwegfunktion und ein Unterschriftsprogramm. Beide sind auf dem Fachgebiet gut bekannt und Beschreibungen sind in der öffentlich verfügbaren Literatur über Kryptographie, z. B. Applied Cryptoaraphy, Bruce Schneier, John Wiley & Sons, Inc. (1994) zu finden. Das System schützt die Anonymität der Ausgebenden und garantiert außerdem die Validität ihrer elektronischen Münzen, und die verwendeten Münzen sind unvergesslich und können nicht mehr als einmal ausgegeben werden.
  • Im Allgemeinen umfasst die Erfindung, in einem Aspekt, ein elektronisches Geldsystemprotokoll für sichere Transaktionen ohne Ursprungserkennung, gekennzeichnet durch:
    Verwendung einer öffentlich zu offenbarenden Einwegfunktion f1(x), um ein Bild f1(x1) ab einem Urbild x1 zu generieren; Senden des Bilds f1(x1) in einer nicht blinden Form an eine zweite Partei (30); Empfangen ab der zweiten Partei (30) eines öffentlich zu offenbarenden Vermerks einschließlich einer digitalen Unterschrift, wobei besagter öffentlich zu offenbarender Vermerk eine Verpflichtung seitens der zweiten Partei (30) repräsentiert, einem ersten Vorleger besagten Urbilds x1 an die zweite Partei (30) einen vorbestimmten Geldbetrag zu kreditieren. Der empfangene, unterzeichnete Vermerk repräsentiert eine Verpflichtung seitens der zweiten Partei, einem ersten Vorleger des Urbilds x1 an die zweite Partei einen vorbestimmten Geldbetrag zu kreditieren.
  • Bevorzugte Ausführungsbeispiele schließen folgendes Merkmal ein. Das elektronische Geldsystemprotokoll schließt außerdem das Senden des Urbilds x1 an eine dritte Partei als Zahlung für den Kauf von Gütern oder Dienstleistungen von der dritten Partei ein.
  • Als andere Möglichkeit schließt es weiter ein:
    Selektieren eines zweiten Urbilds x2;
    Verwendung einer zweiten öffentlich zu offenbarenden Einwegfunktion f2(x), um ein zweites Bild f2(x2) ab dem zweiten Urbild x2 zu generieren;
    Senden des ersten Urbilds x1 und der nicht blinden Form des zweiten Bilds f2 (x2) an die zweite Partei (30); und
    Empfangen ab der zweiten Partei (3d) eines zweiten öffentlich zu offenbarenden Vermerks, einschließlich einer digitalen Unterschrift, wobei besagter zweite öffentlich zu offenbarende Vermerk eine Verpflichtung durch die zweite Partei (30) repräsentiert, einem ersten Vorleger besagten zweiten Urbilds x2 an die zweite Partei (3d) einen vorbestimmten Geldbetrag zu kreditieren. In beiden Fällen sind f1(x) und f2(x) dieselbe Funktion. Im letzteren Fall geschieht das Senden des ersten Urbilds x1 und der nicht blinden Form des zweiten Bilds f2(x2) an die zweite Partei anonym und die zweite Partei ist eine Bank.
  • Außerdem schließt das Protokoll in bevorzugten Ausführungsbeispielen die Schritte Verkettung eines Unterschriftsschlüssels einer dritten Partei mit dem ersten Urbild x1, um einen Informationsblock zu bilden; der Verschlüsselung des Informationsblocks durch Verwendung eines Verschlüsselungsschlüssels der zweiten Partei, um einen verschlüsselten Informationsblock zu generieren; und Senden des verschlüsselten Informationsblocks an die dritte Partei ein.
  • Im Allgemeinen ist die Erfindung, in einem weiteren Aspekt, ein elektronisches Geldsystemprotokoll, das die Schritte Empfangen eines ersten Urbilds x1 ab einer ersten Partei, worin das Urbild x1 ein erstes Bild f1(x1) produziert, wenn es durch eine erste Einwegfunktion f1(x) verarbeitet wird und wobei mit besagtem ersten Urbild x1 eine Verpflichtung seitens einer zweiten Partei assoziiert ist, einem ersten Vorleger des besagten ersten Urbilds x1 einen vorbestimmten Geldbetrag zu kreditieren; Selektieren eines zweiten Urbilds x2; Verwendung einer zweiten Einwegfunktion f2(x), um ein zweites Bild f2(x2) ab dem zweiten Urbild x2 zu generieren; Senden des ersten Urbilds x1 und einer nicht blinden Form des zweiten Bilds f2(x2) an die zweite Partei; und Empfangen eines Vermerks, einschließlich einer digitalen Unterschrift ab der zweiten Partei, einschließt, worin der Vermerk eine Verpflichtung seitens der zweiten Partei repräsentiert, einem ersten Vorleger des zweiten Urbilds x2 an die zweite Partei einen vorbestimmten Geldbetrag zu kreditieren.
  • Im Allgemeinen ist die Erfindung, in noch einem weiteren Aspekt, ein elektronisches Geldsystemprotokoll, das die Schritte Empfangen eines verschlüsselten Informationsblocks ab einer ersten Partei, wobei man den Block verschlüsselter Information generierte, indem zuerst ein öffentlicher Unterschriftsschlüssel einer zweiten Partei mit einem ersten Urbild x1 verkettet wurde, um einen Informationsblock zu bilden und der Infonnationsblock dann durch Verwendung eines Verschlüsselungsschlüssels einer dritten Partei verschlüsselt wurde; Selektieren eines zweiten Urbilds x2; Verwendung einer zweiten Einwegfunktion f2(x) zum Generieren eines Bilds f(x2) ab dem Urbild x2; Formen einer Mitteilung einschließlich des verschlüsselten Informationsblocks zusammen mit dem Bild f(x2) in einer nicht blinden Form; Senden der Mitteilung an die dritte Partei; und Empfangen ab der dritten Partei eines unterzeichneten Vermerks, einschließlich einer digitalen Unterschrift, worin der Vermerk eine Verpflichtung durch die dritte Partei repräsentiert einem ersten Vorleger des Urbilds x2 einen vorbestimmten Geldbetrag zu kreditieren, einschließt.
  • Im Allgemeinen ist die Erfindung, in noch einem weiteren Aspekt, ein elektronisches Geldsystemprotokoll, das die Schritte Empfangen ab einer ersten Entität einer nicht blinden Form eines Bilds f1(x1), das durch Anwendung einer Einwegfunktion f1(x) auf ein Urbild x1 generiert wurde; Generieren einer Mitteilung, die eine Verpflichtung enthält, einer vorbestimmten Betrag an einen ersten Vorleger des Urbilds x1 zu kreditieren; Unterschreiben der Mitteilung mit einer digitalen Unterschrift; und Senden der Mitteilung zusammen mit der digitalen Unterschrift an die erste Partei einschließt.
  • In bevorzugten Ausführungsbeispielen schließt das elektronische Geldsystemprotokoll außerdem anschließendes Empfangen des Urbilds x1 ab einer dritten Partei; Überprüfen einer Datenbank auf das Urbild x1; falls das Urbild x1 nicht in der Datenbank gefunden wird, Kreditieren der dritten Partei mit dem vorbestimmten Geldbetrag; und Hinzufügen des Urbilds x1 zur Datenbank ein. Als andere Möglichkeit schließt das Protokoll anschließendes Empfangen des Urbilds x1 und eines nicht blinden Bilds f2(x2) ab einer dritten Partei, worin das nicht blinde Bild f2(x2) durch Anwendung einer Einwegfunktion f2(x) auf ein Urbild x2 generiert wurde; Überprüfen einer Datenbank auf das Urbild x1; falls das Urbild x1 nicht in der Datenbank aufgefunden wird, Generieren eines unterzeichneten Vermerks, einschließlich einer digitalen Unterschrift, worin der Vermerk eine Verpflichtung representiert, einen vorbestimmten Geldbetrag an einen ersten Vorleger des Urbilds x2 zu kreditieren; und Hinzufügen des Urbilds x1 zur Datenbank ein.
  • Ebenso in bevorzugten Ausführungsbeispielen kennzeichnet die Erfindung das Empfangen einer Mitteilung ab einer zweiten Partei, worin die Mitteilung durch Verketten eines Verschlüsselungsschlüssels einer dritten Partei mit einem ersten Urbild x1 generiert wurde, um einen Informationsblock, durch Verschlüsseln des Informationsblocks mit einem ersten Verschlüsselungsschlüssel, zu bilden, um einen verschlüsselten ersten Block zu generieren, und durch Verketten eines nicht blinden Bilds f2(x2) mit dem verschlüsselten ersten Informationsblock, worin das nicht blinde Bild f2(x2) durch Verwendung einer Einwegfunktion f2(x) generiert wurde, um ein Bild f2(x2) ab einem Urbild x2 zu generieren. Es kennzeichnet sie weiter das Entschlüsseln des verschlüsselten ersten Informationsblocks; Generieren eines Vermerks einschließlich einer digitalen Unterschrift, worin der Vermerk eine Verpflichtung repräsentiert, einem ersten Vorleger des Urbilds x2 einen vorbestimmten Geldbetrag zu kreditieren; und Schicken des Vermerks an die zweite Partei.
  • Im Allgemeinen ist die Erfindung, in noch einem weiteren Aspekt, ein elektronisches Geldsystemprotokoll, das die Schritte Senden eines nicht blinden Bilds f2(x2) an eine zweite Partei, worin das nicht blinde Bild f2(x2) durch Anwendung einer Einwegfunktion f2(x) auf ein Urbild x2 generiert wurde; Empfangen eines unterschriebenen Vermerks ab der zweiten Partei, worin der nicht blinde Vermerk eine digitale Unterschrift einschließt und eine Verpflichtung repräsentiert, einem ersten Vorleger des Urbilds x2 einen vorbestimmten Geldbetrag zu kreditieren; und als Antwort auf den Empfang des nicht blinden Vermerks ab der zweiten Partei, Autorisieren der Lieferung von Gütern und/oder Dienstleistungen an eine dritte Partei einschließt.
  • Die Erfindung bietet eine einfache, billige Art und Weise bargeldartige Transaktionen zu tätigen, wobei der Austauschgegenstand (d. h. die abgehobene Münze) die Eigenschaften tatsächlichen Bargelds hat. Beispielsweise ist er: (1) mehr oder weniger anonym; (2) sicher; (3) billig zu verwenden; und (4) leicht herumzutragen und auszutauschen.
  • Parteien sind durch die Tatsache, dass sie den Wert x1 für eine spezielle Münze geheim halten, bis sie ausgegeben ist, dagegen geschützt, dass eine unehrliche Bank abgehobene Münzen nicht einlöst, So lang wie eine spezielle Münze f(x1) öffentlich und nicht anonym deponiert wird, kann von der Bank verlangt werden, dass sie diese einlöst, außer sie kann die zugehörige x1 liefern. Natürlich kann die Bank eine anonym ausgetauschte Münze f(x1), während des eigentlichen Austausches, nicht einlösen, indem sie nach Empfangen von x1 behauptet, dass die Münze bereits ausgegeben worden ist. Jedoch kann die Bank unmöglich wissen, wer durch solch einen „Zeche prellenden" Trick betrogen wird, und sie ist daher anfällig für Überwachung und öffentliche Bloßstellung.
  • Abschließend sei gesagt, dass die Banken selbst durch die Sicherheit des digitalen Unterschriftsprogramms, das zum Unterzeichnen elektronsicher Münzen eingesetzt wird, gegen Fälschung geschützt sind. Überdies sind sie gegen „Doppelausgabe" (oder "Doppeleinzahlung") durch ihre Fähigkeit geschützt, x1-Werte für Münzen ewig zu speichern.
  • Andere Vorteile und Merkmale werden an Hand der folgenden Beschreibung des bevorzugten Ausführungsbeispiels und der Ansprüche offenkundig.
  • Kurzbeschreibung der Zeichnungen
  • 1 ist ein Diagramm eines nicht anonymen Abhebungsprotokolls;
  • 2 ist ein Diagramm eines anonymen Austauschprotokolls;
  • 3 ist ein Diagramm eines anonymen Kaufprotokolls;
  • 4 ist ein Diagramm eines nicht anonymen Einzahlungsprotokolls;
  • 5 ist ein Diagramm eines anonymen alternativen Zahlungsprotokolls;
  • 6 ist ein Diagramm eines Protokolls für eine anonyme oder nicht anonyme „Hinterlegungszahlung" oder Zahlungsanweisung; und
  • 7 ist ein Diagramm eines verschlüsselten Protokolls für eine Zahlungsanweisung.
  • Beschreibung der bevorzugten Ausführungsbeispiele
  • Die Fähigkeit anonym zu kommunizieren ist in gewissem Sinne a priori notwendig, wenn anonyme Geldtransaktionen stattfinden sollen, da Informationen über Kommunikationen einer Partei offensichtlich Informationen über die Geschäftstätigkeiten der Partei offenbaren werden. In der Praxis könnte die Anonymität der Kommunikation vielleicht auf nicht mehr als der Zuversicht beruhen, dass die Telefongesellschaft die Vertraulichkeit ihres Systems schützt. Oder aber vertrauen Parteien vielleicht in einen oder mehrere „anonyme Weiterversender", um ihre Identitäten zu verschleiern, oder verlassen sich auf die Durchführung einer der anderen Techniken aus der öffentlich verfügbaren Literatur.
  • Angenommen, dass nicht nur Kommunikationen zwischen Parteien in Bezug auf dritte Parteien anonym sind, sondern ebenso, dass die kommunizierenden Parteien einander anonym sind. (Bei typischen Durchführungen ist die letztere Kondition, Selbstidentifizierung ausgenommen, eine natürliche Folge der Ersteren). Ein einfaches, irgendwie anonymes elektronisches Geldsystemprotokoll in solch einer Umgebung ist in 1 gezeigt.
  • In den folgenden Beschreibungen verschiedener Protokolle (siehe 1–7), nehmen wir generell auf drei Parteien Bezug, nämlich einen Kunden 10, einen Verkäufer 20 und eine Bank 34. Der Kunde 10 ist natürlich generell repräsentativ für den Zahler und der Verkäufer 20 ist generell repräsentativ für den Zahlungsempfänger. Es versteht sich aber, dass diese Bezeichnungen für den Zweck der Klarheit gewählt wurden und, dass sie nicht den Umfang der Erfindung begrenzen sollen. Es wäre ebenso gültig, wenn man sie als Partei A, Partei B und Partei C bezeichnen würde.
  • In den Abbildungen sind die verschiedenen Entitäten durch Blöcke repräsentiert und die Informationsübertragungen von einer Entität zu einer anderen sind durch Linien angezeigt, die die entsprechenden Blöcke verbinden. Jede Linie repräsentiert eine Übertragung gewisser Informationen von einer Entität zu einer anderen in der durch einen Pfeil am Ende der Linie angezeigten Richtung. Die Informationen, die übertragen werden, sind unter den Linien symbolisch zusammengefasst.
  • Obwohl jeder Block etikettiert ist und unten als eine spezielle Entität repräsentierend beschrieben wird, kann er durch ein Rechengerät implementiert werden, das die Berechnungen und die Kommunikationen verrichtet, die von jener Entität ausgeführt werden. Bei den Rechengeräten könnte es sich um eine breite Palette elektronischer Geräte handeln, die beispielsweise einen Personalcomputer, eine PCMCIA-Karte, ein PDI (Personaldatenaustauschgerät), eine Chipkarte, einen Handcomputer oder eine leistungsfähigere Workstation einschließen, um nur einige zu nennen. Die Bankseite der Protokolle, die nachfolgend beschrieben sind, lässt sich von einem Server durchführen, der programmiert ist, elektronische Transaktionen zu handhaben, die jenen ähneln, die gegenwärtig Transaktionen von SB-Bankautomaten handhaben. Der Server würde mehrere einlaufende Telefonleitungen aufweisen und eine Datenspeichermöglichkeit zum Speichern der relevanten Daten einschließen.
  • Natürlich sollte ebenso verstanden werden, dass die Rechengeräte, entweder intern oder extern, alle Speicherkapazität einschließen, die für die Daten und Programme erforderlich ist, die mit der Durchführung der Protokolle zu tun haben. Überdies schließen sie Geräte (z. B. ein Modem) ein, die ihnen ermöglichen, mit anderen Rechengeräten zu kommunizieren. Außerdem können die Kommunikationsmedien, über die die Informationsübertragungen stattfinden, ebenso irgendwelche einer großen Zahl von Möglichkeiten sein, die beispielsweise Telefonleitungen, Kabel, das Internet, Satellitenübertragungen oder Funkübertragungen einschließen. Anders ausgedrückt ist nicht beabsichtigt, dass die Erfindung entweder hinsichtlich der verwendeten Gerätearten oder der eingesetzten Kommunikationsverfahren eingeschränkt wird. Den Möglichkeiten und Kombinationen werden nur durch die eigene Phantasie Grenzen gesetzt.
  • Für die folgenden Protokolle wird angenommen, dass die Bank 30 eine Einwegfunktion f(x) auswählt und öffentlich verfügbar macht. Oder aber könnte solch eine Funktion durch eine beliebige Partei öffentlich verfügbar gemacht werden, so lang alle Parteien der Transaktionen Zugriff darauf haben und sie benutzen können. Generell meinen wir mit einer Einwegfunktion eine Funktion f(x), so dass f(x1) durch Verwenden von x1 produziert wird und, wenn f(x1) gegeben ist, man x1 nicht bestimmen kann. In der folgenden Beschreibung wird auf x1 auch als ein Urbild von f(x1) und auf f(x1) als ein Bild von x1 Bezug genommen.
  • Es könnte sein, dass perfekte Einwegfunktionen in der Praxis eigentlich nicht existieren. Das heißt, dass für alle Funktionen, von denen man jetzt glaubt, dass sie Einwegfunktionen sind, eines Tages genügend Rechenkraft oder Techniken vorliegen können, um x1 zu bestimmen, wenn f(x1) gegeben ist. Daher beabsichtigen wir mit dem Begriff Einwegfunktion auch jene Funktionen einzuschließen, für die es sehr schwer, aber nicht notwendigerweise unmöglich ist, x1 zu berechnen, wenn f(x1) bekannt ist.
  • Die Einwegfunktion kann eine einer Reihe von gebräuchlichen Hash-Funktionen (z. B. MD5, SHA usw.) sein. Außerdem könnte es man mehrere Einwegfunktionen verwenden und verketten. Auf dem Fachgebiet sind eine Menge Einwegfunktionen bekannt und typisch lassen sich viele davon leicht berechnen und daher auf einer Chipkarte implementieren.
  • Anhand dieses Hintergrunds werden jetzt die verschiedenen Protokolle, die die Erfindung verkörpern, beginnend mit einem Abhebungsprotokoll beschrieben, bei dem sich ein Kunde „Bargeld" von der Bank beschafft.
  • Abhebungsprotokoll
  • Eine Abhebung wird auf die in 1 gezeigte Weise durchgeführt. Der Kunde 10 wählt eine beliebige Zahl x1 und verwendet f(x), um ein Bild von x1 zu generieren. Der Wert x1 ist eine von einem Zufallsgenerator erhaltene zufällige Zahlenkette, auf die vielleicht optional einige Nachverarbeitung angewandt werden kann. Sie könnte beispielsweise 128 Bits lang sein. Kunde 10 hält sie geheim, bis eine Zahlung stattfindet und dann wird sie als die Zahlung gesendet.
  • Der Kunde 10 hebt dann eine Münze (nicht anonym) von der Bank 30 ab, indem er jene Bank 30 ersucht, einen Geldwert mit f(x1) zu assoziieren. Die Bank 30 entspricht, indem sie digital eine Erklärung dahingehend unterschreibt, somit f(x1) als eine gültige Münze „zertifiziert" und ein Konto, das der Kunde 10 bei der Bank 30 unterhält, um den Betrag des Werts der Münze belastet. Anders ausgedrückt, gibt die Bank 30 eine Erklärung oder eine Angabe heraus, die im Effekt anzeigt, dass „Dem ersten Vorleger des Urbilds von f(x1) ein Betrag Z kreditiert wird" und danach unterzeichnet oder zertifiziert die Bank 30 dann jene Erklärung.
  • Techniken für das Unterzeichnen oder Zertifizieren von Informationen (z. B. durch Verwendung eines Paars privater-öffentlicher Schlüssel) und die Verwendung digitaler Unterschriften sind auf dem Fachgebiet gut bekannt. Für weitere Einzelheiten beziehen Sie sich bitte auf die weit anerkannten Referenzen auf dem Gebiet, z. B. Angewandte Kryptographie von Bruce Schneier, John Wiley & Sons, Inc., (1994).
  • Im Allgemeinen ist ein Unterschriftsprogramm eine Art und Weise ein Skript zu etikettieren. Typischerweise verwendet es ein Paar öffentlicher privater Schlüssel. Öffentliche-private Schlüssel lassen sich durch Einwegfunktionen implementieren, obwohl ein praktischerer Ansatz darin besteht, eine Falltürfunktion zu verwenden, die die Tendenz hat, effizienter zu sein (z. B. siehe von Schneier beschriebene RSA, DSS, EIGamal Algorithmen). Der private Schlüssel wird verwendet, um das Skript oder einen Hash des Skripts zu verschlüsseln, um eine digitale Unterschrift zu produzieren, die dann an das Skript angehängt wird. Die digitale Unterschrift repräsentiert eine Unterschrift der Entität, der der private Schlüssel gehört, da keine andere Entität solch eine Unterschrift ab jenem Skript generieren kann. Wenn eine zweite Entität das Etikett mittels des öffentlichen Schlüssels entschlüsseln kann, weiß sie, dass die Unterschrift von der Entität generiert wurde, der der private Schlüssel gehört.
  • Damit Zertifizierung funktioniert, wird offensichtlich angenommen, dass jeder den öffentlichen Schlüssel der Unterzeichnerbehörde hat und diesem vertraut und Zuversicht hat, dass der private Schlüssel nicht kompromittiert worden ist.
  • Durch das Veröffentlichen ihres öffentlichen Schlüssels und das Anhängen digitaler Unterschriften an eine Erklärung, dass die Bank 30 eine spezifizierte Summe an die Entität zahlt, die zuerst ein Urbild von f(x1) präsentiert, verknüpft sich die Bank 30 eindeutig mit ihrer Verpflichtung und schützt sich gegen mögliche Fälscher.
  • Die von der Bank generierte, zertifizierte Erklärung wird hierin als C(f(x1)) designiert, und hierin ebenso als ein Vermerk bezeichnet. Dieser Vermerk wird dem Kunden 10 zurückgegeben. Außerdem kann er öffentlich verfügbar gemacht werden, da er keinen Wert für jemanden hat, der x1 nicht kennt.
  • Austauschprotokoll
  • Eine Partei (z. B. Kunde 10 oder Verkäufer 20) kann jederzeit anonym eine Münze bei der Bank 30 „austauschen". In der Tat, ist es wichtig dies sofort nach Empfang einer Münze ab einer anderen Partei zu tun, um das Risiko zu minimieren, dass jemand anders der Bank 30 x1 vor dem echten Empfänger der Münze liefern wird. Eine unehrliche Partei könnte versuchen, die Münze mehrmals zu senden, indem sie x1 mehreren Parteien gibt. Wenn das geschieht, wird der erste Empfänger, der die Bank 30 erreicht, ihren Wert erhalten und alle anderen Empfänger der Münze werden sie nicht gegen eine andere Münze umtauschen können. Für den Verkäufer 20 ist der Zeitpunkt des Austausches weniger kritisch, weil der Verkäufer 20 vermutlich nicht die Güter oder Dienstleistungen liefern wird, die gekauft werden, bis ihm versichert wurde, dass die erhaltene Münze immer noch gültig ist.
  • Mit Bezug auf 2 und unter der Annahme, dass der Kunde 10 eine Münze anonym austauschen möchte, werden x1 und ein weiteres Bild der Funktion, f(x2) für ein zufällig gewähltes x2 vom Kunden 10 an die Bank 30 geliefert. Anders ausgedrückt versucht der Kunde 10 eine wie vorher beschriebene Abhebung vorzunehmen, liefert aber gleichzeitig den abzuhebenden Betrag wie er von x1 repräsentiert wird. Die Bank 30 zertifiziert einfach f(x2) und hält x1 in einer Datenbank 40 als Nachweis, dass f(x1) bereits „ausgegeben" worden ist. Es ist eigentlich diese Interaktion, die doppeltes Ausgeben von x1 verhindert.
  • Da sich f(x1) und C(f(x1)) bereits im Besitz der Bank 30 befinden, ist das Senden jener Information an die Bank 30 zusammen mit x1 und f(x2) optional.
  • Wenn der bankseitige Teil des Protokolls auf einem Server durchgeführt wird, speichert er automatisch die empfangenen xi. Und jedes Mal, wenn die Bank 30 ein weiteres xj empfängt, prüft sie es zuerst gegen die xi, die bereits kassiert (d. h., empfangen) worden sind.
  • Man kann eine Reihe von Austauschtransaktionen verwenden, um zu verschleiern, wer eigentlich die Münze ausgibt. Beachten Sie, dass bei einer Austauschtransaktion nur f(x2) nicht aber der Besitzer von x2 offenbart werden braucht. Im Gegensatz zu alternativen Ansätzen, Anonymität zu erzielen, ist das Blindmachen der Münze nicht erforderlich. Tatsächlich ist es wünschenswert, dass f(x1) nicht blind gemacht wird, sondern öffentlich bekannt gemacht wird.
  • Was immer die Schritte sind, die man vornehmen möchte, um die Anonymität von Kommunikation zu sichern, sind diese ausreichend die Anonymität der Transaktion zu sichern (d. h., Erzielen von Anonymität ist möglich aber auch optional).
  • Dieses Verfahren lässt sich auch dafür verwenden, Wechselgeld für eine Münze eines gegebenen Werts herauszugeben. Anstatt f(x2) zu senden, kann die das Wechselgeld suchende Partei mehrfache f(x), z. B. f(x2), f(x3), f(x4), jede für einen speziellen Wert, senden, deren Summe dem mit f(x1) assoziierten Wert entspricht. Die Bank sendet mehrere unterzeichnete Vermerke, C(f(xi), zurück.
  • Kaufprotokoll
  • Bezugnehmend auf 3, verwendet das tatsächliche Ausgeben von Münzen ein Protokoll, das dem Austauschprotokoll ähnlich ist. Die ausgebende Partei (z. B. Kunde 10) leitet x1 an die empfangende Partei (z. B. Verkäufer 20) weiter. Da es wahrscheinlich ist, dass der Verkäufer 20 keinen direkten und unmittelbaren Zugriff auf f(x1) und C(f(x1)) hat, schließt der Kunde 10 auch diese Informationen als Teil der Transaktion ein. Der Verkäufer 20 ruft dann sofort die Bank 30 an und tauscht x1 gegen eine „frische" Münze aus, unter der Annahme, dass die Bank 30 zuerst verifiziert, dass sie nicht vorher ausgegeben worden ist. Der Verkäufer 20 verwendet das in 2 dargestellte Austauschprotokoll, um diesen Austausch durchzuführen. Angenommen, dass der Austausch erfolgreich war, liefert der Verkäufer 20 dann die gekauften Güter und/oder Dienstleistungen an den Kunden 10.
  • Einzahlungsprotokoll
  • Bezugnehmend auf 4 können auch Münzen jederzeit nicht anonym bei der Bank 30 eingezahlt werden. Wenn der Verkäufer 20, beispielsweise, eine Münze f(x1) einzahlen möchte, die er nicht ausgegeben hat, sendet er x1, zusammen mit einer Einzahlungsaufforderung, an die Bank 30. Der Verkäufer 20 kann auch optional f(x1) sowie den Vermerk C(f(x1)) senden.
  • Nach Erhalt von x1 und der Einzahlungsaufforderung prüft die Bank 30 ihre Datenbank, um zu bestimmen ob x1 bereits der Bank vorgelegt worden ist. Natürlich, wenn sie bereits vorgelegt worden ist, wird die Bank 30 das Konto des Verkäufers nicht kreditieren und dem Verkäufer 20 mitteilen, dass es keine gültige Münze ist. Wenn die Bank 30 x1 nicht bereits erhalten hat, kreditiert sie das Konto des Verkäufers mit dem entsprechenden Betrag und sendet dem Verkäufer 20 eine Einzahlungsquittung, die bestätigt, dass eine Gutschrift eingetragen worden ist.
  • Erweiterungen der Protokolle
  • Die Austausch- und Zahlungsprotokolle in dem oben beschriebenen elektronischen Geldprogramm erlauben eine Reihe von Variationen, die den verfügbaren Kommunikationsmitteln und den gewünschten Anonymitätsebenen angepasst werden können. Wenn der Kunde 10, beispielsweise mit Bezug auf 5, leichteren Zugriff auf die Bank 30 als der Verkäufer 20 hat, dann kann der Verkäufer 20 zuerst ein f(x2) an den Kunden 10 liefern, der dann das Austauschprotokoll für den Verkäufer 20 durchführt und die unterzeichnete Münze, d. h. C(f(x2)), als Nachweis der Zahlung zurücksendet. Das Austauschprotokoll lässt sich, wie bereits erwähnt, anonym durchführen.
  • Oder aber, wenn sowohl der Kunde 10 als auch der Verkäufer 20 besseren Kommunikationszugriff auf die Bank 30 als aufeinander haben, dann können die Parteien ein Protokoll für eine „Hinterlegungszahlung", wie es in 6 dargestellt ist, verwenden. In Übereinstimmung mit diesem Protokoll, liefert der Kunde 70 die Zahlung bei der Bank 30 für den Verkäufer 20 ab und der Verkäufer 20 holt sich anschließend die Zahlung von der Bank 30 ab.
  • Die Schritte des Protokolls für eine „Hinterlegungszahlung" sind wie folgt. Zunächst liefert der Kunde 10 ein x2 für eine gültige Münze eines spezifischen Betrags, zusammen mit einem öffentlichen Unterschriftsschlüssel p des Verkäufers 20, und andere Informationen bezüglich der Transaktion an die Bank 30. Zum Beispiel möchte der Kunde 10 vielleicht, unter den anderen Informationen, die zu kaufenden Güter identifizieren, die Transaktion und/oder den Verkäufer identifizieren, und die deklarierten Absichten des Kunden hinsichtlich Zahlung anzeigen, wobei das Bargeld in eine Art „elektronische Zahlungsanweisung" verwandelt wird. Optional kann der Kunde 10 auch f(x1) und den Vermerk C(f(x1)) senden. Da aber, wie vorher erwähnt, diese Informationen der Bank 30 bereits bekannt sind, könnte sich dies als nicht notwendig erweisen.
  • Beachten Sie, dass eine Aufzeichnung, die vielleicht anhand der vom Kunden 10 gelieferten anderen Informationen zusammengestellt wird, bei Fernzahlungseinstellungen von besonderen Nutzen sein kann, wo die Natur der Transaktion anderweitig in der Zahlungshandlung selbst nicht implizit enthalten ist, wie es typischerweise bei Zahlungen der Fall ist, die persönlich geleistet werden.
  • Wenn der Verkäufer 20 nicht anonym bleiben möchte, könnte der öffentliche Unterschriftsschlüssel öffentlich mit der Identität des Verkäufers 20 assoziiert werden; oder, wenn Anonymität gewünscht wird, kann der öffentliche Unterschriftsschlüssel ein zweckgebundener öffentlicher Unterschriftsschlüssel ohne assoziierte Identität sein. Im letzteren Fall wird der öffentliche Schlüssel vertraulich an getreue Bekannte weitergegeben oder einfach unter einem Pseudonym veröffentlicht,
  • Die Bank 30 erklärt sich einverstanden, den mit x1 assoziierten Betrag der ersten Münze f(x1) zuzuordnen, die ihr vorgelegt wird, die auch mit dem privaten Unterschriftsschlüssel unterschrieben wird, der dem vorher gelieferten öffentlichen Unterschriftsschlüssel p entspricht. Daher braucht der Verkäufer 20, um die Zahlung für die Güter zu erhalten, die der Käufer 10 kaufen möchte, nur einfach eine Abhebung von der Bank 30, unter Verwendung des in Verbindung mit 1 beschriebenen Protokolls, zu tätigen. Das heißt der Verkäufer 20 wählt zufällig ein x2 und verwendet f(x), um das entsprechende Bild f(x2) zu generieren. In diesem Fall unterschreibt der Verkäufer 20 aber f(x2) mit seinem privaten Unterschriftsschlüssel, bevor er f(x2) an die Bank 30 sendet. Außerdem geschieht in diesem Fall die Abhebung nicht vom Konto des Verkäufers, sondern ist einfach ein Transfer des vorher vom Kunden 10 gelieferten Betrags.
  • Die Bank 30 verwendet den öffentlichen Unterschriftsschlüssel des Verkäufers, um zu verifizieren, dass f(x2) vom Verkäufer 20 unterschrieben ist (d. h., von der Partei an die der Geldtransfer zu tätigen ist). Nach Bestätigen der Unterschrift auf f(x2), stellt die Bank 30 einen Vermerk C(f(x2)) aus, den sie dem Verkäufer 20 sendet.
  • Nachdem der Verkäufer 20 den Vermerk C(f(x2)) erhält, der bestätigt, dass das Geld eingegangen ist, sendet der Verkäufer 20 die Güter an den Kunden 10.
  • Natürlich könnte die Bank 30 theoretisch betrügen, indem sie einfach das Geld behält, anstatt es dem Zahlungsempfänger zuzuordnen. Um die Bank 30 ehrlich zu halten, verlassen wir uns jedoch auf die Anonymität des Zahlenden oder wenigstens auf die Möglichkeit, dass der Zahlende die Transaktion der öffentlichen Aufsichtsbehörde offenbaren könnte.
  • In einer Umgebung, in der Kommunikationen unter den Parteien vielleicht abgefangen werden können, gibt es eine Reihe Wege, die Austauschprotokolle und speziell den darin weitergeleiteten geheimen x-Wert vor Lauschern zu sichern. Das natürlichste Verfahren ist die Verschlüsselung des öffentlichen Schlüssels. Wenn Parteien ihre gegenseitigen öffentlichen Verschlüsselungsschlüssel sowie die Banken kennen, dann können alle der obigen Protokolle gleich gut in der durch Lauscher gefährdeten Umgebung funktionieren, so lang jede Mitteilung, außer die von der Bank 30 gesendeten Mitteilungen, mit dem öffentlichen Verschlüsselungsschlüssel des Empfängers verschlüsselt wird oder mit einem symmetrischen "Sitzungsschlüssel", der den öffentlichen Verschlüsselungsschlüssel des Empfängers benutzt, verschlüsselt wird. Die Mitteilungen der Bank können natürlich als nicht vertraulich erachtet werden, da sie nur aus unterschriebenen Münzen der Form f(xi) bestehen, wobei xi von jemand anders geheim gehalten wird. Die Verwendung von Mitteilungs-Authentizierungsscodes, bzw. MAC's, mit jeder Verschlüsselung macht es außerdem möglich sicherzustellen, dass sich niemand, außer dem Versender, an der Mitteilung zu schaffen macht, bevor sie an ihrem Bestimmungsort eintrifft.
  • Die Verwendung von Verschlüsselung mit einem öffentlichen Schlüssel (Public-Key-Verschlüsselung) ermöglicht außerdem eine andere Art "elektronische Zahlungsanweisung". In diesem Fall, der in 7 dargestellt ist und auf den generell als ein verschlüsseltes Protokoll für eine Zahlungsanweisung Bezug genommen wird, verschlüsselt der Kunde 10 den geheimen x1-Wert für irgendeine gültige elektronische Münze, zusammen mit dem öffentlichen Schlüssel p des Verkäufers 20 und jeder anderen gewünschten Identitäts- oder Transaktionsinformation, wie beim vorhergehenden Protokoll für eine „Hinterlegungszahlung". Der Kunde 10 verschlüsselt diese Informationen mit dem öffentlichen Verschlüsselungsschlüssel der Bank oder mit einem Sitzungsschlüssel, der dann mit Hilfe des öffentlichen Verschlüsselungsschlüssels der Bank verschlüsselt wird. Der Kunde 10 sendet dann die verschlüsselten Daten direkt an den Verkäufer 20.
  • Um sie "einzulösen", wählt der Verkäufer 20 einen Zufallswert x2, generiert sein Bild f(x2) und hängt f(x2) an die Mitteilung E an, die er vom Kunden 10 erhielt. Wie zuvor ist f(x2) von der Bank zu unterschreiben, so dass es den Transfer von Geld an den Verkäufer 20 repräsentieren wird. Der Verkäufer 20 unterzeichnet die komplette Mitteilung (oder wenigstens f(x2)) mit dem privaten Unterschriftsschlüssel, der mit der öffentlichen Unterschrift p assoziiert ist, und leitet E, f(x2) und die Unterschrift an die Bank 30 weiter. Optional könnte der Verkäufer 20 diese Mitteilung auf die zuvor beschriebene Weise weiter verschlüsseln, d. h. mit dem Verschlüsselungsschlüssel der Bank und möglicherweise einem zusätzlichen symmetrischen Schlüssel.
  • Nachdem die Bank 30 mit ihrem privaten Schlüssel die Mitteilung vom Verkäufer 20 entschlüsselt hat, überprüft sie dann, dass x1 nicht bereits in ihrer Datenbank gespeichert ist, und wenn es nicht vorgefunden wird, speichert die Bank 30 dann x1. Die Bank 30 generiert dann einen Vermerk C(f(x2)), der eine Geldüberweisung an den Verkäufer 20 für den Betrag des mit f(x1) assoziierten Werts repräsentiert. Der Vermerk wird dann an den Verkäufer 20 gesandt, der nach Erhalt und Verifizierung die gekauften Güter an den Kunden 10 sendet.
  • In Wirklichkeit ist dieses verschlüsselte letzte Protokoll mit dem vorhergehenden identisch. Das Hinzufügen von Verschlüsselung hat dem Zahlenden einfach erlaubt die "Zahlungsanweisung" über den Zahlungsempfänger weiterzuleiten, während sichergestellt wird, dass an den geheimen und zusätzlichen, vom Zahlenden bereitgestellten, Informationen nicht herumgepfuscht wird.
  • Für den Vermerk, C(f(xi)), könnte es vorteilhaft sein, ein Verfalldatum einzuschließen. In diesem Fall werden die in der Datenbank der Bank 30 gespeicherten xi nicht zu groß. Das heißt die xi brauchen nicht für ewig in der Datenbank der Bank festgehalten werden. Um zu verhindern, dass der Wert der Münzen abläuft, könnte die Chipkarte (oder egal was für Ausrüstung die Transaktionen des Kunden handhabt) automatisch die alten Münzen gegen Neue mit einem neuen Verfalldatum austauschen.
  • Das Verfalldatum macht das Geld außerdem erstattungsfähig. Falls die Chipkarte eines Benutzers funktionsunfähig wird und alle der xi verloren sind, kann der Benutzer der Bank 30 einfach die f(xi) mit der Bitte vorlegen, dass, wenn sie nicht innerhalb von 3 Monaten nach dem Verfalldatum beansprucht werden, der Kunde dann den Betrag des Werts der Münzen kreditiert haben möchte. Damit dies funktioniert, muss sich jedoch der Kunde oder die Kundin 10, während der ursprünglichen Kommunikation mit der Bank 30, dann, wenn die Münzen abgehoben werden, identifizieren.
  • Die Kundenseite der Protokolle lässt sich leicht mit einer Chipkarte durchführen, da nur die xi gespeichert werden müssen und sie typischerweise nicht viel Speicherkapazität erfordern. Um Diebstahl der xi durch jemand zu verhindern, der die Chipkarte stiehlt, lässt sich eine PIN in der Chipkarte verwenden, die geheim ist, und die vom Benutzer eingegeben werden muss, bevor Zugriff auf irgendwelche der xi möglich ist.
  • Beachten Sie bitte, dass ebenso vorausgesetzt wurde, dass alle der obigen Interaktionen, die oben beschrieben wurden, automatisiert sind. Das heißt sie wurden automatisch von einem entsprechend programmierten Computer oder Prozessor ausgeführt, der unter Kontrolle der Partei stand, für die die Transaktion durchgeführt wurde.
  • Andere Ausführungsbeispiele befinden sich in den folgenden Ansprüchen. Beispielsweise besteht ein weiterer Weg für das Verbinden identifizierender Informationen mit elektronischen Münzen darin, den geheimen Wert xi zu benutzen, um das Verbinden auszuführen. In der obigen Beschreibung wurde angenommen, dass die geheimen Werte xi zufällig vom Erzeuger der Münze generiert werden. Der geheime Wert lässt sich aber als das Bild einiger identifizierenden Daten unter einer Einwegfunktion h(x) generieren, die vielleicht dieselbe Funktion f(x) sein könnte, die bei der Konstruktion normaler elektronischer Münzen benutzt wird. Die identifizierenden Informationen könnten den Zweck und das Datum der Zahlung und den Namen des Zahlenden und des beabsichtigten Zahlungsempfängers einschließen – kurz gesagt, alle Informationen, die der Zahlende vielleicht in der Bank archiviert haben möchte. Diese Informationen würden dann durch h(x) geleitet, um einen xi zu generieren, der als der geheime Wert dient.
  • In diesem Fall bestünde für die Bank keine. Notwendigkeit Transaktionsinformationen zu archivieren, die mit elektronischen Zahlungen in entweder den oben beschriebenen Protokollen für „Hinterlegungs-zahlungen" oder Protokollen für "elektronische Zahlungs-anweisungen" empfangen wurden. Tatsächlich ist nur erforderlich, dass die Zahlung dahingehend etikettiert wird, dass der Zahlungsempfänger nicht anonym sein soll. So lang die Bank den Zahlungsempfänger positiv identifiziert und normale Unterlagen der Transaktion, einschließlich der Identität des Zahlungsempfängers, aufbewahrt, kann der Zahlende später "Zahlerstatus" demonstrieren, indem er öffentlich das Urbild von xi unter f(x) enthüllt, das, wie oben angedeutet, Informationen hinsichtlich Zweck und Datum der Zahlung und die Namen des Zahlenden und des beabsichtigten Zahlungsempfängers einschließen könnte. Der Zahlende kann sich Münzen mit solchen ausdrücklich informationstragenden xi-Werten einfach beschaffen, in dem er sie normal konstruiert und dann andere Münzen gegen sie austauscht. In diesem Zusammenhang brauchen die Zahlungsinformationen aber nicht an die Bank gesendet werden, da sie ausdrücklich in xi enthalten sind. Deshalb ist die einzige Information, die der Zahlende sicher an die Bank weiterleiten muss, der öffentliche Unterschriftsschlüssel, der zur Identifizierung des Zahlungsempfängers zu verwenden ist und ausdrücklich die Anforderungen kommuniziert, dass der Zahlende nicht anonym sein soll.
  • Tatsächlich kann selbst diese letztere Anforderung nach auf Unterschrift beruhender Identifizierung von Zahlungsempfängern eliminiert werden, wenn Information in xi (oder f(xi)) eingebettet wird, dass die Bank das Geld nicht auf nicht anonyme Weise einlösen soll. Beispielsweise könnte irgendeine Eigenschaft von xi (z. B. der Wert des ersten Bits gleich 1) von der Bank öffentlich dahingehend deklariert werden, anzuzeigen, dass die in Frage stehende Münze ausschließlich nicht anonym eingelöst werden wird. Ein Zahlender kann dann ein geheimes xi generieren, indem er f(sj) berechnet wobei sj die Verkettung der Zahlungsinformation für eine beabsichtigte Transaktion mit irgendeinem Zufallswert r ist, der so gewählt wird, dass xi die Eigenschaft von Nichtanonymität hat. Beachten Sie, dass die Eigenschaft so gewählt werden sollte, dass grob die Hälfte der Urbilder sj von f(s), irgendeiner speziellen Länge, ein f(sj) mit der Eigenschaft ergeben, so dass nicht viele Versuche zur Wahl von r notwendig sein werden, bevor einer gefunden wird, der den erwünschen Effekt auf xi hat. Diese Münze würde jetzt die Eigenschaft haben, dass jemand, der sie zur Einlösung vorlegt, außerdem eine Identität liefern und sie zur Zufriedenheit der Bank nachweisen muss, so dass die Bank die Identität des Austauschenden als Teil ihrer normalen Buchhaltung aufzeichnen kann. Demzufolge würde der Erzeuger der Münze später ihren Ursprung, sowie andere Einzelheiten der Transaktion, bei der ihr Einsatz beabsichtigt war, demonstrieren können, indem er auf die Buchhaltungsunterlagen der Bank verweist und das zum Generieren von xi verwendete sj enthüllt. Selbst wenn die Münze völlig normal, ohne zusätzliche Verschlüsselung oder anhängende Information für die Bank ausgegeben wird, versieht sie daher den Zahlenden mit allem Schutz, den die früher beschriebene "elektronische Zahlungsanweisung" liefert.

Claims (5)

  1. Ein elektronisches Geldsystemprotokoll für sichere Transaktionen ohne Ursprungserkennung, gekennzeichnet durch: Verwenden einer öffentlich anzeigepflichtigen Einwegfunktian f1(x), um ein Bild f1(x1) ab einem Urbild x1 zu generieren; Senden des Bilds f1(x1) in einer ungeblendeten Form an eine zweite Partei (30); Empfangen ab der zweiten Partei (30) einer öffentlich anzeigepflichtigen Aufzeichnung einschließlich einer digitalen Unterschrift, wobei besagte öffentlich anzeigepflichtige Aufzeichnung eine Verpflichtung durch die zweite Partei (30) repräsentiert einen vorbestimmten Geldbetrag einem ersten Vorleger besagten Urbilds x1 an die zweite Partei (30) zu kreditieren.
  2. Das elektronische Geldsystempratokoll des Anspruchs 1, werter gekennzeichnet durch Senden des Urbilds x1 an eine dritte Partei (20) als Zahlung für den Kauf von Gütern oder Dienstleistungen von der dritten Partei (20).
  3. Das elektronische Geldsystemprotokoll des Anspruchs 1 für sichere Transaktionen ohne Ursprungserkennung, weiter gekennzeichnet durch: Selektieren eines zweiten Urbilds x2; Verwenden einer zweiten öffentlich anzeigepflichtigen Einwegfunktion f2(x), um ein zweites Bild f2(x2) ab des zweiten Urbilds x2 zu generieren; Senden des ersten Urbilds x1 und der ungeblendete Form des zweiten Bilds f2(x2) an die zweite Partei (30); und Empfangen ab der zweiten Partei (30) einer zweiten öffentlich anzeigepflichtigen Aufzeichnung einschließlich einer digitalen Unterschrift, wobei besagte zweite öffentlich anzeigepflichtige Aufzeichnung eine Verpflichtung durch die zweite Partei (30) repräsentiert einem ersten Vorleger besagten zweiten Urbilds x2 an die zweite Partei (30) einen vorbestimmten Geldbetrag zu kreditieren.
  4. Das elektronische Geldsystemprotokoll des Anspruchs 3 für sichere Transaktionen ohne Ursprungserkennung, dadurch gekennzeichnet, dass f1(x) und f2(x) dieselbe Funktion sind. Senden des ersten Urbilds x1 und der ungeblendete Form des zweiten Bilds f2(x2) an die zweite Partei (30); und Empfangen ab der zweiten Partei (30) einer zweiten öffentlich anzeigepflichtigen Aufzeichnung einschließlich einer digitalen Unterschrift, wobei besagte zweite öffentlich anzeigepflichtige Aufzeichnung eine Verpflichtung durch die zweite Partei (30) repräsentiert einem ersten Vorleger besagten zweiten Urbilds x2 an die zweite Partei (30) einen vorbestimmten Geldbetrag zu kreditieren.
  5. Das elektronische Geldsystemprotokoll des Anspruchs 3 für sichere Transaktionen ohne Ursprungserkennung, dadurch gekennzeichnet, dass f1(x) und f2(x) dieselbe Funktion sind.
DE69632482T 1995-08-29 1996-08-29 Elektronisches geldsystem ohne ursprungserkennung Expired - Lifetime DE69632482T2 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US521124 1995-08-29
US08/521,124 US5768385A (en) 1995-08-29 1995-08-29 Untraceable electronic cash
PCT/US1996/014078 WO1997009688A2 (en) 1995-08-29 1996-08-29 Untraceable electronic cash

Publications (2)

Publication Number Publication Date
DE69632482D1 DE69632482D1 (de) 2004-06-17
DE69632482T2 true DE69632482T2 (de) 2005-05-12

Family

ID=24075466

Family Applications (1)

Application Number Title Priority Date Filing Date
DE69632482T Expired - Lifetime DE69632482T2 (de) 1995-08-29 1996-08-29 Elektronisches geldsystem ohne ursprungserkennung

Country Status (7)

Country Link
US (1) US5768385A (de)
EP (1) EP0873615B1 (de)
JP (1) JP2000503786A (de)
AT (1) ATE266919T1 (de)
CA (1) CA2229206C (de)
DE (1) DE69632482T2 (de)
WO (1) WO1997009688A2 (de)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102006017911A1 (de) * 2006-04-18 2007-10-25 Telego! Gmbh Elektronisches Bezahlsystem und Verfahren zum Ausführen eines Bezahlvorgangs
EP3226191A1 (de) * 2016-04-03 2017-10-04 Trinkaus, Hans Alternatives zahlungsmittel, stark personifiziert, schwach personifiziert oder ohne personifizierung

Families Citing this family (133)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10361802B1 (en) 1999-02-01 2019-07-23 Blanding Hovenweep, Llc Adaptive pattern recognition based control system and method
US5983207A (en) * 1993-02-10 1999-11-09 Turk; James J. Electronic cash eliminating payment risk
FR2737032B1 (fr) * 1995-07-19 1997-09-26 France Telecom Systeme de paiement securise par transfert de monnaie electronique a travers un reseau interbancaire
US6385645B1 (en) * 1995-08-04 2002-05-07 Belle Gate Investments B.V. Data exchange system comprising portable data processing units
DK0757336T3 (da) 1995-08-04 2001-03-19 Belle Gate Invest B V Data-Udvekslings-System omfattende bærbare databehandlingsenheder
US6076078A (en) * 1996-02-14 2000-06-13 Carnegie Mellon University Anonymous certified delivery
US6945457B1 (en) 1996-05-10 2005-09-20 Transaction Holdings Ltd. L.L.C. Automated transaction machine
US6373950B1 (en) 1996-06-17 2002-04-16 Hewlett-Packard Company System, method and article of manufacture for transmitting messages within messages utilizing an extensible, flexible architecture
US6026379A (en) * 1996-06-17 2000-02-15 Verifone, Inc. System, method and article of manufacture for managing transactions in a high availability system
GB2317790B (en) * 1996-09-26 1998-08-26 Richard Billingsley Improvements relating to electronic transactions
US6029150A (en) * 1996-10-04 2000-02-22 Certco, Llc Payment and transactions in electronic commerce system
US5999919A (en) * 1997-02-26 1999-12-07 At&T Efficient micropayment system
US7324972B1 (en) * 1997-03-07 2008-01-29 Clickshare Service Corporation Managing transactions on a network: four or more parties
US6061665A (en) * 1997-06-06 2000-05-09 Verifone, Inc. System, method and article of manufacture for dynamic negotiation of a network payment framework
EP0887776A1 (de) * 1997-06-23 1998-12-30 Rainer Grunert Transaktionseinheit-/Transaktionsverfahren zur Zahlungsabwicklung im Internet und/oder ähnlichen öffentlichen Client-Server-Systemen
US6125349A (en) * 1997-10-01 2000-09-26 At&T Corp. Method and apparatus using digital credentials and other electronic certificates for electronic transactions
JPH11143976A (ja) * 1997-11-14 1999-05-28 Hitachi Ltd トークン・バリュー混合型電子マネーカード及び電子マネーカードを取り扱う装置
US6856974B1 (en) * 1998-02-02 2005-02-15 Checkfree Corporation Electronic bill presentment technique with enhanced biller control
US6069955A (en) * 1998-04-14 2000-05-30 International Business Machines Corporation System for protection of goods against counterfeiting
US6807530B1 (en) * 1998-08-05 2004-10-19 International Business Machines Corporation Method and apparatus for remote commerce with customer anonymity
KR100358426B1 (ko) 1998-08-18 2003-01-29 한국전자통신연구원 전자현금거래방법
US6601761B1 (en) 1998-09-15 2003-08-05 Citibank, N.A. Method and system for co-branding an electronic payment platform such as an electronic wallet
RU2153191C2 (ru) 1998-09-29 2000-07-20 Закрытое акционерное общество "Алкорсофт" Способ изготовления вслепую цифровой rsa-подписи и устройство для его реализации (варианты)
US6996213B1 (en) 1998-09-29 2006-02-07 Sun Microsystems, Inc. Superposition of data over voice
US7010512B1 (en) 1998-11-09 2006-03-07 C/Base, Inc. Transfer instrument
US7254557B1 (en) 1998-11-09 2007-08-07 C/Base, Inc. Financial services payment vehicle and method
RU2157001C2 (ru) * 1998-11-25 2000-09-27 Закрытое акционерное общество "Алкорсофт" Способ проведения платежей (варианты)
US7093122B1 (en) 1999-01-22 2006-08-15 Sun Microsystems, Inc. Techniques for permitting access across a context barrier in a small footprint device using shared object interfaces
US6907608B1 (en) 1999-01-22 2005-06-14 Sun Microsystems, Inc. Techniques for permitting access across a context barrier in a small footprint device using global data structures
US6633984B2 (en) 1999-01-22 2003-10-14 Sun Microsystems, Inc. Techniques for permitting access across a context barrier on a small footprint device using an entry point object
US6823520B1 (en) 1999-01-22 2004-11-23 Sun Microsystems, Inc. Techniques for implementing security on a small footprint device using a context barrier
US6922835B1 (en) 1999-01-22 2005-07-26 Sun Microsystems, Inc. Techniques for permitting access across a context barrier on a small footprint device using run time environment privileges
US6678664B1 (en) * 1999-04-26 2004-01-13 Checkfree Corporation Cashless transactions without credit cards, debit cards or checks
DE19919909C2 (de) 1999-04-30 2001-07-19 Wincor Nixdorf Gmbh & Co Kg Signierung und Signaturprüfung von Nachrichten
US7110978B1 (en) * 1999-05-10 2006-09-19 First Data Corporation Internet-based money order system
WO2000070487A1 (en) * 1999-05-14 2000-11-23 Frenkel Marvin A Anonymous on-line cash management system
CN1278236C (zh) 1999-06-10 2006-10-04 贝勒加特投资公司 在分离的存储区域中存储数据组的不同版本的装置和更新存储器中数据组的方法
DE60029455T2 (de) 1999-08-26 2007-07-19 Moneycat Ltd. Elektronisches geld, zugehörige elektronische börse und diese anwendende elektronische bezahlungssysteme
US7889052B2 (en) 2001-07-10 2011-02-15 Xatra Fund Mx, Llc Authorizing payment subsequent to RF transactions
US6789068B1 (en) 1999-11-08 2004-09-07 At&T Corp. System and method for microbilling using a trust management system
AU1586500A (en) * 1999-12-06 2001-06-12 Sun Microsystems, Inc. Computer arrangement using non-refreshed dram
WO2001043129A1 (en) 1999-12-07 2001-06-14 Sun Microsystems Inc. Computer-readable medium with microprocessor to control reading and computer arranged to communicate with such a medium
DE69932643T2 (de) * 1999-12-07 2007-04-05 Sun Microsystems, Inc., Santa Clara Identifizierungsvorrichtung mit gesichertem foto sowie mittel und verfahren zum authentifizieren dieser identifizierungsvorrichtung
WO2001045008A1 (en) * 1999-12-16 2001-06-21 Debit.Net, Inc. Secure networked transaction system
US7222097B2 (en) * 2000-01-18 2007-05-22 Bellosguardo Philippe A Anonymous credit card
US8429041B2 (en) 2003-05-09 2013-04-23 American Express Travel Related Services Company, Inc. Systems and methods for managing account information lifecycles
US8543423B2 (en) 2002-07-16 2013-09-24 American Express Travel Related Services Company, Inc. Method and apparatus for enrolling with multiple transaction environments
US7308429B1 (en) * 2000-02-08 2007-12-11 Tozzi Mario S Electronic withdrawal authorization store and forward for cash and credit accounts
EP1132878A3 (de) * 2000-03-03 2004-04-14 Dietrich Heinicke Verfahren zur Zahlungsabwicklung in zumindest teilweise öffentlich zugänglichen, elektronischen Netzen
US8121941B2 (en) 2000-03-07 2012-02-21 American Express Travel Related Services Company, Inc. System and method for automatic reconciliation of transaction account spend
US7627531B2 (en) 2000-03-07 2009-12-01 American Express Travel Related Services Company, Inc. System for facilitating a transaction
US7111176B1 (en) 2000-03-31 2006-09-19 Intel Corporation Generating isolated bus cycles for isolated execution
US7376629B1 (en) * 2000-04-03 2008-05-20 Incogno Corporation Method of and system for effecting anonymous credit card purchases over the internet
FR2807593B1 (fr) * 2000-04-06 2003-06-06 Inovatel Procede de paiement securise a distance faisant intervenir une collaboration entre banques
CA2305249A1 (en) * 2000-04-14 2001-10-14 Branko Sarcanin Virtual safe
DE10031220C2 (de) * 2000-06-27 2002-05-29 Ulrich Michael Kipper Verfahren und Vorrichtung zur Abwicklung einer Transaktion in einem elektronischen Kommunikationsnetzwerk
JP2004505354A (ja) 2000-07-20 2004-02-19 ベル　ゲイト　インヴェストメント　ベスローテン　フェンノートシャップ データ転送を保護して装置を通信させる方法及びシステム及びそのための装置
US20020049681A1 (en) * 2000-07-20 2002-04-25 International Business Machines Corporation Secure anonymous verification, generation and/or proof of ownership of electronic receipts
US7356696B1 (en) * 2000-08-01 2008-04-08 Lucent Technologies Inc. Proofs of work and bread pudding protocols
EP1205889A1 (de) * 2000-11-10 2002-05-15 TELEFONAKTIEBOLAGET LM ERICSSON (publ) Geld wiedergabe in einem Elektronischen Zahlungssystem
US7640432B2 (en) * 2000-12-11 2009-12-29 International Business Machines Corporation Electronic cash controlled by non-homomorphic signatures
US20020087468A1 (en) * 2000-12-28 2002-07-04 Ravi Ganesan Electronic payment risk processing
US20020087481A1 (en) * 2000-12-29 2002-07-04 Shlomi Harif System, method and program for enabling an electronic commerce heterogeneous network
US20020087473A1 (en) * 2000-12-29 2002-07-04 Shlomi Harif System, method and program for creating an authenticatable, non-repudiatable transactional identity in a heterogeneous network
US20020087483A1 (en) * 2000-12-29 2002-07-04 Shlomi Harif System, method and program for creating and distributing processes in a heterogeneous network
JPWO2002067160A1 (ja) * 2001-02-21 2004-06-24 株式会社鷹山 制御委譲システム、制御委譲方法、電子決済システム、電子決済方法、移動体通信端末装置、認証サーバ装置、通信装置、通信端末および決済サーバ装置
WO2002075624A1 (fr) * 2001-03-19 2002-09-26 Fujitsu Limited Procede de remise d'argent electronique
US7181017B1 (en) 2001-03-23 2007-02-20 David Felsher System and method for secure three-party communications
US7526112B2 (en) * 2001-04-30 2009-04-28 Chase Medical, L.P. System and method for facilitating cardiac intervention
GB2400963B (en) 2001-05-02 2004-12-29 Virtual Access Ltd Secure payment method and system
ATE371240T1 (de) * 2001-05-02 2007-09-15 Virtual Access Ltd Gesichertes zahlungsverfahren und -system
US7725427B2 (en) 2001-05-25 2010-05-25 Fred Bishop Recurrent billing maintenance with radio frequency payment devices
US20040139002A1 (en) * 2001-05-31 2004-07-15 Horst Henn Micropayment system
EP1405517B1 (de) * 2001-06-11 2013-01-02 NDS Limited Anonymes bestellungssystem
US7110525B1 (en) 2001-06-25 2006-09-19 Toby Heller Agent training sensitive call routing system
US7503480B2 (en) 2001-07-10 2009-03-17 American Express Travel Related Services Company, Inc. Method and system for tracking user performance
US7762457B2 (en) 2001-07-10 2010-07-27 American Express Travel Related Services Company, Inc. System and method for dynamic fob synchronization and personalization
US8635131B1 (en) 2001-07-10 2014-01-21 American Express Travel Related Services Company, Inc. System and method for managing a transaction protocol
US7805378B2 (en) 2001-07-10 2010-09-28 American Express Travel Related Servicex Company, Inc. System and method for encoding information in magnetic stripe format for use in radio frequency identification transactions
US8548927B2 (en) 2001-07-10 2013-10-01 Xatra Fund Mx, Llc Biometric registration for facilitating an RF transaction
US7668750B2 (en) 2001-07-10 2010-02-23 David S Bonalle Securing RF transactions using a transactions counter
US9454752B2 (en) 2001-07-10 2016-09-27 Chartoleaux Kg Limited Liability Company Reload protocol at a transaction processing entity
US7925535B2 (en) 2001-07-10 2011-04-12 American Express Travel Related Services Company, Inc. System and method for securing RF transactions using a radio frequency identification device including a random number generator
US8001054B1 (en) 2001-07-10 2011-08-16 American Express Travel Related Services Company, Inc. System and method for generating an unpredictable number using a seeded algorithm
US7705732B2 (en) 2001-07-10 2010-04-27 Fred Bishop Authenticating an RF transaction using a transaction counter
US20040236699A1 (en) 2001-07-10 2004-11-25 American Express Travel Related Services Company, Inc. Method and system for hand geometry recognition biometrics on a fob
US9024719B1 (en) 2001-07-10 2015-05-05 Xatra Fund Mx, Llc RF transaction system and method for storing user personal data
US9031880B2 (en) 2001-07-10 2015-05-12 Iii Holdings 1, Llc Systems and methods for non-traditional payment using biometric data
US7996324B2 (en) 2001-07-10 2011-08-09 American Express Travel Related Services Company, Inc. Systems and methods for managing multiple accounts on a RF transaction device using secondary identification indicia
US8279042B2 (en) 2001-07-10 2012-10-02 Xatra Fund Mx, Llc Iris scan biometrics on a payment device
US20050160003A1 (en) * 2001-07-10 2005-07-21 American Express Travel Related Services Company, Inc. System and method for incenting rfid transaction device usage at a merchant location
US8960535B2 (en) 2001-07-10 2015-02-24 Iii Holdings 1, Llc Method and system for resource management and evaluation
US7735725B1 (en) 2001-07-10 2010-06-15 Fred Bishop Processing an RF transaction using a routing number
US8250025B2 (en) * 2001-11-06 2012-08-21 Business Controls, Inc. Anonymous reporting system
US7372952B1 (en) 2002-03-07 2008-05-13 Wai Wu Telephony control system with intelligent call routing
US8396809B1 (en) 2002-05-14 2013-03-12 Hewlett-Packard Development Company, L.P. Method for reducing purchase time
US6805289B2 (en) 2002-05-23 2004-10-19 Eduardo Noriega Prepaid card payment system and method for electronic commerce
SG145524A1 (en) * 2002-08-07 2008-09-29 Mobilastic Technologies Pte Lt Secure transfer of digital tokens
US6805287B2 (en) 2002-09-12 2004-10-19 American Express Travel Related Services Company, Inc. System and method for converting a stored value card to a credit card
AU2002368386A1 (en) * 2002-11-27 2004-06-18 Institute For Infocomm Research Peer to peer electronic-payment system
US9818136B1 (en) 2003-02-05 2017-11-14 Steven M. Hoffberg System and method for determining contingent relevance
US7676034B1 (en) 2003-03-07 2010-03-09 Wai Wu Method and system for matching entities in an auction
US7783563B2 (en) * 2003-12-09 2010-08-24 First Data Corporation Systems and methods for identifying payor location based on transaction data
US7472827B2 (en) 2004-05-17 2009-01-06 American Express Travel Related Services Company, Inc. Limited use PIN system and method
US7318550B2 (en) 2004-07-01 2008-01-15 American Express Travel Related Services Company, Inc. Biometric safeguard method for use with a smartcard
US8079904B2 (en) * 2004-08-20 2011-12-20 Igt Gaming access card with display
KR20060034464A (ko) * 2004-10-19 2006-04-24 삼성전자주식회사 사용자의 익명성을 보장하는 디지털 티켓을 이용한전자상거래 방법 및 장치
US8049594B1 (en) 2004-11-30 2011-11-01 Xatra Fund Mx, Llc Enhanced RFID instrument security
US7113925B2 (en) * 2005-01-19 2006-09-26 Echeck21, L.L.C. Electronic check
US8874477B2 (en) 2005-10-04 2014-10-28 Steven Mark Hoffberg Multifactorial optimization system and method
US20070219902A1 (en) * 2006-03-20 2007-09-20 Nortel Networks Limited Electronic payment method and related system and devices
US8300798B1 (en) 2006-04-03 2012-10-30 Wai Wu Intelligent communication routing system and method
WO2007127881A2 (en) 2006-04-26 2007-11-08 Business Controls, Inc. Anonymous reporting system
US8566247B1 (en) 2007-02-19 2013-10-22 Robert H. Nagel System and method for secure communications involving an intermediary
US7958057B2 (en) * 2007-03-28 2011-06-07 King Fahd University Of Petroleum And Minerals Virtual account based new digital cash protocols with combined blind digital signature and pseudonym authentication
EP2026267A1 (de) * 2007-07-31 2009-02-18 Nederlandse Organisatie voor toegepast- natuurwetenschappelijk onderzoek TNO Ausstellung elektronischer Belege
US7877331B2 (en) * 2007-09-06 2011-01-25 King Fahd University Of Petroleum & Minerals Token based new digital cash protocols with combined blind digital signature and pseudonym authentication
AU2009249272B2 (en) * 2008-05-18 2014-11-20 Google Llc Secured electronic transaction system
US20100042536A1 (en) * 2008-08-15 2010-02-18 Tim Thorson System and method of transferring funds
US20100198733A1 (en) * 2009-02-04 2010-08-05 Qualcomm Incorporated Enabling Payment Using Paperless Image Of A Check
US8706626B2 (en) 2009-05-26 2014-04-22 Bradley Wilkes Systems and methods for provisionally transferring an electronic currency
US9721261B2 (en) 2009-05-26 2017-08-01 CapitalWill, LLC Systems and methods for electronically circulating a conditional electronic currency
US8630951B2 (en) * 2009-05-26 2014-01-14 Capitalwill Llc Systems and methods for electronically circulating a currency
US9721235B2 (en) 2009-05-26 2017-08-01 Capitalwill Llc Systems and methods for electronically circulating a currency
US8306910B2 (en) * 2009-05-26 2012-11-06 Capital Will LLC Systems and methods for electronically circulating a currency
DE112010004426B4 (de) * 2010-01-22 2015-11-12 International Business Machines Corporation Nicht verknüpfbare Übertragung ohne Gedächtnis mit Preisangaben und wiederaufladbaren Geldbörsen
US20150278806A1 (en) * 2012-10-11 2015-10-01 Bull Sas E-payment architecture preserving privacy
JP6197887B2 (ja) * 2014-01-31 2017-09-20 富士通株式会社 情報処理装置およびセンサ出力制御プログラム
MX2017005751A (es) 2014-11-03 2018-04-10 Genentech Inc Métodos y biomarcadores para predecir la eficacia y evaluación de un tratamiento con agonista de ox40.
US10013682B2 (en) 2015-02-13 2018-07-03 International Business Machines Corporation Storage and recovery of digital data based on social network
US12099997B1 (en) 2020-01-31 2024-09-24 Steven Mark Hoffberg Tokenized fungible liabilities
US20220084015A1 (en) * 2020-09-16 2022-03-17 Asante Technology LLC Methods and systems for ethical cryptocurrency management
JP7566233B1 (ja) 2023-11-21 2024-10-15 久利寿 帝都 電子通貨基盤を実現するための方法およびシステム

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4947430A (en) * 1987-11-23 1990-08-07 David Chaum Undeniable signature systems
US4914698A (en) * 1988-03-16 1990-04-03 David Chaum One-show blind signature systems
US4987593A (en) * 1988-03-16 1991-01-22 David Chaum One-show blind signature systems
US4949380A (en) * 1988-10-20 1990-08-14 David Chaum Returned-value blind signature systems
US4991210A (en) * 1989-05-04 1991-02-05 David Chaum Unpredictable blind signature systems
US4996711A (en) * 1989-06-21 1991-02-26 Chaum David L Selected-exponent signature systems
DE69031614T2 (de) * 1990-01-29 1998-05-07 Security Techn Corp Wahlweise moderierte Transaktionssysteme
US5373558A (en) * 1993-05-25 1994-12-13 Chaum; David Desinated-confirmer signature systems

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102006017911A1 (de) * 2006-04-18 2007-10-25 Telego! Gmbh Elektronisches Bezahlsystem und Verfahren zum Ausführen eines Bezahlvorgangs
DE102006017911B4 (de) 2006-04-18 2023-01-26 creditPass GmbH Elektronisches Bezahlsystem und Verfahren zum Ausführen eines Bezahlvorgangs
EP3226191A1 (de) * 2016-04-03 2017-10-04 Trinkaus, Hans Alternatives zahlungsmittel, stark personifiziert, schwach personifiziert oder ohne personifizierung

Also Published As

Publication number Publication date
EP0873615B1 (de) 2004-05-12
US5768385A (en) 1998-06-16
CA2229206C (en) 2003-07-15
EP0873615A4 (de) 1999-11-24
EP0873615A2 (de) 1998-10-28
WO1997009688A2 (en) 1997-03-13
ATE266919T1 (de) 2004-05-15
JP2000503786A (ja) 2000-03-28
DE69632482D1 (de) 2004-06-17
CA2229206A1 (en) 1997-03-13
WO1997009688A3 (en) 1997-04-10

Similar Documents

Publication Publication Date Title
DE69632482T2 (de) Elektronisches geldsystem ohne ursprungserkennung
DE69828971T2 (de) Symmetrisch gesichertes elektronisches Kommunikationssystem
DE69635143T2 (de) Verfahren und Vorrichtung zur Erzeugung und Verwaltung eines privaten Schlüssels in einem kryptografischen System mit öffentlichem Schlüssel
DE69423454T2 (de) Anonyme Kreditkartentransaktionen
DE69801668T2 (de) Verfahren und system zum bezahlen mit elektronischem scheck
DE69932512T2 (de) Gerät und verfahren zur elektronischen versendung, speicherung und wiedergewinnung von authentifizierten dokumenten
DE69215501T2 (de) Werttransfersystem
Brickell et al. Trustee-based Tracing Extensions to Anonymous Cash and the Making of Anonymous Change.
Medvinsky et al. NetCash: A design for practical electronic currency on the Internet
DE69633217T2 (de) Verfahren zum Implentieren von elektronischem Geld mit Hilfe einer Lizenz eines anonymen öffentlichen Schlüssels
DE69934530T2 (de) Elektronisches Wasserzeichenverfahren und elektronisches Informationsverteilungssystem
DE69630738T2 (de) Verfahren und Einrichtung für ein elektronisches Geldsystem mit Ursprungserkennung
DE69620994T2 (de) Verfahren und vorrichtung zum durchführen von elektronischem handel
US5983207A (en) Electronic cash eliminating payment risk
US6411942B1 (en) Electronic transaction system and systems for issuing and examining electronic check
DE69736074T2 (de) Sicheres interaktives elektronisches ausgabesystem für kontoauszüge
DE69602265T2 (de) Treuhandvermittler zur offenen ausgabe von elektronischem geld
DE69617941T2 (de) Verfahren und einrichtung zum authentifizieren des ursprungs einer nachricht
WO2020212331A1 (de) Gerät zum direkten übertragen von elektronischen münzdatensätzen an ein anderes gerät sowie bezahlsystem
US6859795B1 (en) Method for carrying out transactions and device for realizing the same
WO2023036458A1 (de) Verfahren und transaktionssystem zum übertragen von token in einem elektronischen transaktionssystems
WO2022233454A1 (de) Verfahren zum registrieren eines elektronischen münzdatensatzes in einem münzregister; ein münzregister; eine teilnehmereinheit und ein computerprogrammprodukt
DE69605654T2 (de) Elektronisch verhandelbare dokumente
DE102005008610A1 (de) Verfahren zum Bezahlen in Rechnernetzen
DE69636612T2 (de) Zahlungsverfahren in einer Datenübertragungsanordnung und Anordnung zu dessen Implementierung

Legal Events

Date Code Title Description
8364 No opposition during term of opposition