DE102020004122A1 - Bezahlsystem, münzregister, teilnehmereinheit, transaktionsregister, überwachungsregister und verfahren zum bezahlen mit elektronischen münzdatensätzen - Google Patents

Bezahlsystem, münzregister, teilnehmereinheit, transaktionsregister, überwachungsregister und verfahren zum bezahlen mit elektronischen münzdatensätzen Download PDF

Info

Publication number
DE102020004122A1
DE102020004122A1 DE102020004122.1A DE102020004122A DE102020004122A1 DE 102020004122 A1 DE102020004122 A1 DE 102020004122A1 DE 102020004122 A DE102020004122 A DE 102020004122A DE 102020004122 A1 DE102020004122 A1 DE 102020004122A1
Authority
DE
Germany
Prior art keywords
register
coin
electronic coin
data record
transaction
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.)
Withdrawn
Application number
DE102020004122.1A
Other languages
English (en)
Inventor
Wolfram Seidemann
Raoul-Thomas Herborg
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.)
Giesecke and Devrient Advance52 GmbH
Original Assignee
Giesecke and Devrient GmbH
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 Giesecke and Devrient GmbH filed Critical Giesecke and Devrient GmbH
Priority to DE102020004122.1A priority Critical patent/DE102020004122A1/de
Priority to CN202180053519.4A priority patent/CN116057555A/zh
Priority to US18/015,028 priority patent/US20230267426A1/en
Priority to EP21739313.1A priority patent/EP4179486A1/de
Priority to PCT/EP2021/068059 priority patent/WO2022008320A1/de
Publication of DE102020004122A1 publication Critical patent/DE102020004122A1/de
Withdrawn legal-status Critical Current

Links

Images

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
    • G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
    • 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/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • 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
    • G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
    • G06Q20/0655—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash e-cash managed centrally
    • 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
    • G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
    • G06Q20/0658—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash e-cash managed locally
    • 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/223—Payment schemes or models based on the use of peer-to-peer networks
    • 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/363—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes with the personal data of a user
    • 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/3821—Electronic credentials
    • G06Q20/38215—Use of certificates or encrypted proofs of transaction rights
    • 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
    • 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/389—Keeping log of transactions for guaranteeing non-repudiation of a transaction
    • 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/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4014—Identity check for transactions
    • 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/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/405—Establishing or using transaction specific rules
    • 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/42—Confirmation, e.g. check or permission by the legal debtor of payment
    • G06Q20/425—Confirmation, e.g. check or permission by the legal debtor of payment using two different networks, one for transaction and one for security confirmation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/008—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols involving homomorphic encryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Finance (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

Die Erfindung betrifft ein Bezahlsystem zum Bezahlen mit elektronischen Münzdatensätzen aufweisend ein Münzregister, eingerichtet zum Registrieren der elektronischen Münzdatensätzen; Teilnehmereinheiten, eingerichtet zum Ausführen von Bezahltransaktionen durch Übertragen der elektronischen Münzdatensätze und zum Senden von Status- und Registrierungsanforderungen betreffend die elektronischen Münzdatensätze an das Münzregister und ein Überwachungsregister, eingerichtet zum Auswerten von Überwachungsdatensätzen betreffend die Bezahltransaktionen, wobei ein Überwachungsdatensatz im Überwachungsregister aus zumindest einem Registerdatensatz und zumindest einem Transaktionsdatensatz gebildet wird, wobei der zumindest eine Registerdatensatz von dem Münzregister bereitgestellt wird und wobei der zumindest eine Transaktionsdatensatz von einer Transaktionsdatensatzquelle und/oder dem Münzregister bereitgestellt wird. Die Erfindung betrifft zudem ein Münzregister, ein Überwachungsregister, ein Transaktionsregister, eine Teilnehmereinheit und ein Verfahren zum Bezahlen mit elektronischen Münzdatensätzen.

Description

  • TECHNISCHES GEBIET DER ERFINDUNG
  • Die Erfindung betrifft ein Bezahlsystem, ein Münzregister, eine Teilnehmereinheit, ein Transaktionsregister, ein Überwachungsregister und ein Verfahren zum Bezahlen mit elektronischen Münzdatensätzen.
  • TECHNISCHER HINTERGRUND DER ERFINDUNG
  • Schutz der Privatsphäre ist ein wichtiger Wert für die Gesellschaft, besonders wenn sehr sensible Daten, wie Zahlungsinformationen, betroffen sind. Sicherheit von Bezahltransaktionen und den dazugehörigen Bezahltransaktionsdaten bedeutet sowohl Schutz der Vertraulichkeit der ausgetauschten Daten; als auch Schutz der Integrität der ausgetauschten Daten; als auch Schutz der Verfügbarkeit der ausgetauschten Daten.
  • Für elektronische Münzdatensätze müssen dabei grundlegende Kontrollfunktionen, insbesondere (1) das Erkennen von Mehrfachausgabe-Verfahren, auch Double-Spending genannt, und (2) das Erkennen von ungedeckten Zahlungen nachgewiesen werden können. Im Fall (1) versucht jemand denselben Münzdatensatz mehrfach auszugeben und im Fall (2) versucht jemand einen Münzdatensatz auszugeben, obwohl er kein Guthaben (mehr) besitzt.
  • Um den Fall (1) zu verdeutlichen, ist in 1a und 1b ein Bezahlsystem dargestellt, bei dem es möglich ist, einen geldwerten Betrag in Form von elektronischen Münzdatensätzen C direkt zwischen Endgeräten M im Bezahlsystem auszutauschen. Bei einem direkten Übertragen zwischen den Endgeräten M wird keine zentrale Instanz des Bezahlsystems, beispielsweise ein Münzregister 2 oder Überwachungsregister, benötigt. In 1a teilt ein Endgerät M1 einen Münzdatensatz Ca auf, um einen Münzdatensatz Cb zu erhalten. Das Endgerät M1 gibt den Münzdatensatz Cb in unerlaubter Weise an Endgeräte M2 und M3 gleichzeitig weiter.
  • Im Bezahlsystem der 1a teilt das Endgerät M2 den Münzdatensatz Cb weiter und erhält den Münzdatensatz Cc, der sodann direkt an das Endgerät M4 weitergegeben wird. Das Endgerät M4 gibt den Münzdatensatz Ce an das Endgerät M6 direkt weiter. Das Endgerät M6 gibt den Münzdatensatz Cc an das Endgerät M8 direkt weiter. Der arglose Teilnehmer mit Endgerät M3 gibt den Münzdatensatz Cb direkt an das Endgerät M5 weiter. Das Endgerät M3 gibt den Münzdatensatz Cb an das Endgerät M5 direkt weiter. Das Endgerät M5 gibt den Münzdatensatz Cb an das Endgerät M7 direkt weiter. Somit wechseln beide Münzdatensätze Cb und Cc häufig den Besitzer, ohne dass ein Münzregister 2 des Bezahlsystems dies erfährt.
  • Wenn - wie in 1b dargestellt - das Endgerät M7 den Münzdatensatz Cb in einem Münzregister 2 des Bezahlsystems auf sich registrieren lässt (=Umschalten), wird der Münzdatensatz Cb ungültig (dargestellt durch das Durchstreichen des Münzdatensatzes) und ein Münzdatensatz Cd wird gültig. Wenn nun auch das Endgerät M8 den Münzdatensatz Cc als den Münzdatensatz Ce beim Münzregister 2 registrieren lassen möchte, stellt das Münzregister 2 fest, dass der Münzdatensatz Cb bereits ungültig ist. Der Angriff oder Betrug von M1 wird erst jetzt entdeckt. In der Folge akzeptiert das Münzregister 2 weder den Münzdatensatz Cc noch den Münzdatensatz Ce, was den jeweiligen Besitzern der Endgeräte M7 und M8 finanziell schaden könnte.
  • Zudem steigt durch die Vielzahl von Transaktionen eines elektronischen Münzdatensatzes und auch durch die fortschreitende Lebensdauer das Risiko, dass an dem elektronischen Münzdatensatz Manipulation(en) vorgenommen werden.
  • Es soll perspektivisch möglich sein, ganz auf Bargeld (Banknoten und analoge Münzen), zumindest aber auf analoge Münzen, zu verzichten.
  • In der US 5,872,844 A ist ein elektronisches Bezahlsystem beschrieben. Elektronische Münzdatensätze (assets) werden in dem System von einer zentralen Institution ausgegeben. Die elektronischen Münzdatensätze werden von einem Endgerät (wallet) des Zahlers auf ein Endgerät des Zahlungsempfängers übertragen. Das Endgerät des Zahlungsempfängers reicht die übertragenen Münzdatensätze routinemäßig für eine mögliche Prüfung ein. Ein Betrugserkennungssystem entnimmt Stichproben von den zur Prüfung eingereichten Münzdatensätzen, um „schlechte“ Münzdatensätze aufzudecken, die in betrügerischer Weise verwendet wurden. Bei einer solchen Aufdeckung identifiziert das Betrugserkennungssystem die das Endgerät, das den schlechten Münzdatensatz verwendet hat, und kennzeichnet sie als „schlechtes Endgerät“. Das Betrugserkennungssystem stellt eine Liste derartiger schlechter Endgeräte zusammen und verteilt die Liste, um anderen Endgeräten vor den schlechten Endgeräten zu warnen. Wenn ein schlechtes Endgerät anschließend versucht, Münzdatensätze auszugeben (ob in betrügerischer Absicht oder nicht), wird der beabsichtigte Empfänger die Liste der schlechten Endgeräte überprüfen und eine Bezahltransaktion mit dem schlechten Endgerät nicht ausführen.
  • Dieses bekannte System ist nicht anonym, denn ein Teilnehmer generiert aus einer Identitätsnummer ein Pseudonym, das sowohl für die Bezahltransaktionen zum anderen Teilnehmer als auch bei der Generierung und Ausgabe der elektronischen Münzdatensätze von der Institution verwendet werden muss. Die ausgegebenen elektronischen Münzdatensätze enthalten zudem zwingend eine Signaturkette, wodurch der Speicherbedarf des elektronischen Münzdatensatzes pro Bezahltransaktion größer wird, der elektronische Münzdatensatz also wächst. Endgeräte, die nicht vertrauenswürdig sind, werden an dem System gar nicht zugelassen.
  • Es ist daher die Aufgabe der vorliegenden Erfindung, ein Verfahren und ein System zu schaffen, in denen eine Bezahltransaktion zwischen Teilnehmern eines öffentlichen Bezahlsystems sicher, flexibel und einfach ausgestaltet ist. Dabei soll insbesondere eine direkte und anonyme Bezahlung zwischen den Teilnehmern des Bezahlsystems geschaffen werden. Die ausgetauschten elektronischen Münzdatensätze sollen vertraulich gegenüber anderen Systemteilnehmern sein, aber jedem Systemteilnehmer erlauben, grundlegende Prüfungen an dem elektronischen Münzdatensatz durchzuführen, nämlich (1) das Erkennen von Mehrfach-Ausgabe-Versuchen; (2) das Erkennen von Versuchen mit nicht vorhandenen monetären Beträgen zu zahlen und (3) das Erkennen von Rückgabekriterien für bereits ausgegebene Münzdatensätze, beispielsweise dass ein elektronischer Münzdatensatz verfallen soll.
  • Dieses anonyme Bezahlsystem soll - insbesondere zu Kontrollzwecken oder bei der Teilnahme unbekannter anonymer Teilnehmer - skalierbar pseudonymisierbar oder gar personalisierbar (nicht-anonym, identitäts- bzw. betragsoffen) sein, um sicherzustellen, dass dieses öffentliche Bezahlsystem nicht missbraucht wird.
  • Anonyme Teilnehmer oder nicht-vertrauenswürdige Teilnehmer sollen also am Bezahlsystem teilnehmen dürfen, ohne die Sicherheit zu gefährden. Ein elektronischer Münzdatensatz soll ungeachtet seines Alters oder der damit verbundenen Transaktionen immer den gleichen Speicherplatz verbrauchen.
  • ZUSAMMENFASSUNG DER ERFINDUNG
  • Die gestellten Aufgaben werden mit den Merkmalen der unabhängigen Patentansprüche gelöst. Weitere vorteilhafte Ausgestaltungen sind in den abhängigen Patentansprüchen beschrieben.
  • Die Aufgabe wird insbesondere durch ein Bezahlsystem zum Bezahlen mit elektronischen Münzdatensätzen gelöst. Das Bezahlsystem weist ein Münzregister auf, das eingerichtet ist zum Registrieren der elektronischen Münzdatensätze. Das Bezahlsystem weist zudem Teilnehmereinheiten auf, die eingerichtet sind zum Ausführen von Bezahltransaktionen durch Übertragen der elektronischen Münzdatensätze und zum Senden von Status- und Registrierungsanforderungen betreffend die elektronischen Münzdatensätze an das Münzregister. Das Bezahlsystem weist zudem ein Überwachungsregister auf, das eingerichtet ist zum Auswerten von Überwachungsdatensätzen betreffend die Bezahltransaktionen. Ein Überwachungsdatensatz wird dabei im Überwachungsregister aus zumindest einem Registerdatensatz und zumindest einem Transaktionsdatensatz gebildet, wobei der zumindest eine Registerdatensatz von dem Münzregister bereitgestellt wird und wobei der zumindest eine Transaktionsdatensatz von einer Transaktionsdatensatzquelle und/oder dem Münzregister bereitgestellt wird.
  • Damit wird eine dreischichtige Systemarchitektur für ein Bezahlsystem vorgeschlagen. Diese drei Schichten umfassen eine anonyme Direkttransaktions-Schicht (= erste Schicht, Bezahltransaktionsschicht), in der die Teilnehmereinheiten elektronische Münzdatensätze untereinander übertragen (austauschen). Diese drei Schichten umfassen eine Registrier-Schicht (= zweite Schicht, Verifizier-Schicht) bestehend aus einem Münzregister und einem Überwachungsregister, in der Status und Gültigkeit bezüglich der elektronischen Münzdatensätze für jeden Teilnehmer nachprüfbar registriert sind. Diese drei Schichten umfassen eine Prüf-Schicht (= dritte Schicht, Audit-Schicht), bestehend aus dem Münzregister und einem Transaktionsregister, die unter gewissen (System-)Voraussetzungen oder bei der Teilnahme bestimmter Teilnehmereinheiten (insbesondere anonymer Teilnehmereinheiten) oder nach vorgegebenen Mustern/Parametern zum Einsatz kommt.
  • Durch diesen dreischichtigen Aufbau kann ein Paradoxon - nämlich der Erhalt einer Anonymität und gleichzeitig ein Aufrechterhalten von Vertrauenswürdigkeit - aufgelöst werden. Die jeweilige Bezahltransaktion ist so weiterhin in vorteilhafter Weise grundsätzlich anonym, kann aber durch entsprechende Parametrisierung eines korrespondierenden Registerdatensatzes oder eines Transaktionsdatensatzes skalierbar pseudonym oder sogar personalisiert werden. Dies erhöht die Teilnehmerakzeptanz, da die Freiheit, direkt, also ohne Prüfinstanz, zu bezahlen, berücksichtigt ist und gleichzeitig die Vertrauenswürdigkeits-Anforderung einer Herausgeberinstanz, einer Zentralbank bzw. einer Geschäftsbank erfüllt, nämlich sicherzustellen, dass das Bezahlsystem nicht missbraucht wird.
  • Ein elektronischer Münzdatensatz ist insbesondere ein elektronischer Datensatz, der einen geldwerten (=monetären) Betrag repräsentiert und umgangssprachlich auch als „digitale Münze“ oder „elektronische Münze“, englisch „digital/electronic coin“ bezeichnet wird. Dieser geldwerte Betrag kann bei dem Verfahren von einem ersten Endgerät zu einem anderen Endgerät wechseln. Als ein geldwerter Betrag (Vermögenwert) wird im Folgenden ein digitaler Betrag verstanden, der z.B. auf einem Konto eines Geldinstituts gutgeschrieben werden kann, oder gegen ein anderes Zahlungsmittel getauscht werden kann. Ein elektronischer Münzdatensatz repräsentiert also Bargeld in elektronischer Form.
  • Ein elektronischer Münzdatensatz zum Übertragen von geldwerten Beträgen unterscheidet sich wesentlich von dem elektronischen Datensatz zum Datenaustausch oder Datentransfer, beispielsweise einem Registerdatensatz oder einem Transaktionsdatensatz, da eine klassische Datentransaktion beispielsweise auf Basis eines Frage-Antwort-Prinzips bzw. auf einer Interkommunikation zwischen den Datentransferpartnern, beispielsweise der Teilnehmereinheit und einer der Registerinstanzen (Münzregister, Überwachungsregister, Transaktionsregister) stattfindet. Dabei können im Rahmen von Authentifizierungen, Identifizierungs- bzw. Kennungsdaten ausgetauscht werden, die Rückschlüsse auf eine Teilnehmerkennung und/oder eine Identifizierungsnummer einer natürlichen Person als Nutzer (Teilnehmer) des Bezahlsystems liefern können. Damit ist ein anonymes Bezahlen nicht möglich. Ein elektronischer Münzdatensatz ist dementgegen anonym, einmalig, eindeutig und steht im Kontext eines Sicherheitskonzepts. In einem elektronischen Münzdatensatz sind prinzipiell alle Datenelemente enthalten, die für eine empfangende Instanz benötigt werden. Im Unterschied zum Kopieren von elektronischen Datensätzen, also der Vervielfältigung digitaler Daten, darf ein gültiger elektronischer Münzdatensatz nur ein einziges Mal im Bezahlsystem existieren. Diese Systemvoraussetzung ist insbesondere beim Übertragen von elektronischen Münzdatensätzen zu beachten.
  • In einer vorteilhaften Ausgestaltung weist der elektronische Münzdatensatz als Datenelement einen monetären Betrag, also ein Datum, das einen Geldwert des elektronischen Münzdatensatzes darstellt, und als Datenelement einen Verschleierungsbetrag, beispielsweise eine Zufallszahl, auf. Der Verschleierungsbetrag ist nur in der ersten Schicht bekannt. Der Verschleierungsbetrag ist außer der Herausgeberinstanz keinem der Bezahlsysteminstanzen der zweiten oder dritten Schicht, beispielsweise einem der Register, wie Münzregister, Überwachungsregister, Transaktionsregister, Personenregister bekannt. Der Verschleierungsbetrag ist - außer in der ersten Schicht (Direkttransaktionsschicht) -ein geheimes Datenelement. Der Verschleierungsbetrag ist geheim für das Münzregister und das Überwachungsregister. Ein elektronischer Münzdatensatz wird durch diese wenigstens zwei Datenelemente (monetärer Betrag, Verschleierungsbetrag) eindeutig repräsentiert. Jeder, der Zugriff auf diese Datenelemente eines elektronischen Münzdatensatzes hat, kann diesen elektronischen Münzdatensatz zum Bezahlen in einer Bezahltransaktion verwenden. Die Kenntnis dieser zwei Datenelemente (monetärer Betrag, Verschleierungsbetrag) ist also gleichbedeutend mit dem Besitz des digitalen Geldes. Dieser elektronische Münzdatensatz kann zwischen zwei Teilnehmereinheiten direkt übertragen werden. Zum Austausch von digitalem Geld (=Bezahltransaktion) ist nur die Übertragung des monetären Betrags und des Verschleierungsbetrags notwendig.
  • In einer Ausgestaltung weist jeder elektronische Münzdatensatz noch zumindest einen Prüfwert als Datenelement auf, sodass dieser dann aus mindestens drei Daten (monetärer Betrag, Verschleierungsbetrag, Prüfwert) besteht. Der Prüfwert wird beim direkten Übertragen des elektronischen Münzdatensatzes zwischen zwei Teilnehmereinheiten inkrementiert. Die Funktion des Prüfwerts des elektronischen Münzdatensatzes wird später erläutert. Zusätzlich kann ein Status (gültig/nicht-gültig) eines elektronischen Münzdatensatzes als Datenelement im elektronischen Münzdatensatz vorhanden sein. Der Status kann in einer Ausgestaltung nicht an den elektronischen Münzdatensatz angefügt sein und ist in dieser Ausgestaltung nur der Teilnehmereinheit(Sicherheitselement) selbst und/oder dem Münzregister bekannt und wird dort geführt.
  • In einer Ausgestaltung kann jeder elektronische Münzdatensatz eine Münzkennung als Datenelement aufweisen, wobei die Münzkennung bevorzugt zur Identifizierung eines Registerdatensatzes bezüglich des elektronischen Münzdatensatzes und eines Transaktionsdatensatzes bezüglich des elektronischen Münzdatensatzes verwendet wird. Eine Münzkennung ist, ähnlich wie eine Transaktionskennung im Transaktionsdatensatz, ein Datenelement zur eindeutigen Zuordnung des elektronischen Münzdatensatzes im Bezahlsystem. Diese Münzkennung ist bevorzugt eine Zufallszahl. Die Münzkennung (falls verfolgbar) gibt Rückschlüsse über den Lebenszyklus eines elektronischen Münzdatensatzes.
  • Darüber hinaus kann der elektronische Münzdatensatz weitere Datenelemente aufweisen, beispielsweise welche Währung der monetäre Betrag repräsentiert, von welcher Herausgeberinstanz er erzeugt wurde und/oder eine Signatur einer Herausgeberinstanz.
  • Um ein Übertragungsprotokoll sicher auszugestalten, werden die elektronischen Münzdatensätze durch jeweiliger Teilnehmereinheiten, beispielsweise durch dort integrierte Sicherheitselemente, verwaltet und auch durch diese übertragen. In einer bevorzugten Ausgestaltung ist das Sicherheitselement betriebsbereit in die Teilnehmereinheit eingebracht. Dabei kann die Teilnehmereinheit eine Applikation beinhalten, durch die ein Benutzer (= Teilnehmer) einen Bezahlvorgang steuert und in diesem Bezahlvorgang auf elektronische Münzdatensätze des Sicherheitselements zurückgreift.
  • Die Teilnehmereinheit kann beispielsweise ein mobiles Endgerät, wie z.B. ein Smartphone, ein Tablet-Computer, ein Computer, ein Server oder eine Maschine sein. Ein Übertragen des elektronischen Münzdatensatzes vom (ersten) Sicherheitselement einer ersten Teilnehmereinheit erfolgt beispielsweise zum (zweiten) Sicherheitselement einer anderen Teilnehmereinheit. Dabei kann eine Teilnehmereinheit-zu-Teilnehmereinheit Übertragungsstrecke aufgebaut werden, über die beispielsweise ein sicherer Kanal zwischen den beiden Sicherheitselementen aufgebaut wird, über den dann das Übertragen des elektronischen Münzdatensatzes erfolgt. Eine auf der Teilnehmereinheit betriebsbereit eingebrachte Applikation (installiert) kann die Übertragung des Münzdatensatzes durch Nutzung von Eingabe- und/oder Ausgabemittel der jeweiligen Teilnehmereinheit initiieren und steuern. Beispielsweise können Beträge von elektronischen Münzdatensätzen angezeigt werden und das Übertragungsverfahren überwacht werden.
  • Eine Transaktionsdatensatzquelle - als Teil der dritten Schicht - ist dabei eine Datenquelle, die Transaktionsdatensätze bereitstellt. Der Transaktionsdatensatz umfasst diejenigen Informationen, die benötigt werden, um die Übertragung des Münzdatensatzes zwischen zwei Teilnehmereinheiten des Bezahlsystems eindeutig in der Gesamtheit der Übertragungen (Bezahltranskationen) identifizieren zu können. Der Transaktionsdatensatz umfasst dabei insbesondere die an der Übertragung teilnehmenden Teilnehmereinheiten und eine Information bezüglich des zu übertragenden Münzdatensatzes. Mit einem Transaktionsdatensatz kann das Übertragen des elektronischen Münzdatensatz bezüglich der beteiligten Teilnehmereinheiten eindeutig oder zumindest pseudonymisiert rekonstruiert werden.
  • Diese Transaktionsdatenquelle kann in einer Ausgestaltung eine Teilnehmereinheit, insbesondere eine den Münzdatensatz sendende oder gesendete Teilnehmereinheit sein. In dieser Ausgestaltung erstellt die Teilnehmereinheit den Transaktionsdatensatz und stellt diesen - als Transaktionsdatenquelle - dem Überwachungsregister bereit. Dabei kann auch ein Kommunikationskanal zwischen der Teilnehmereinheit und dem Münzregister genutzt werden, die Kommunikation zwischen Teilnehmereinheit und Überwachungsinstanz ist bevorzugt kryptografisch gesichert und von etwaigen Zwischeninstanzen (wie dem Münzregister) nicht einsehbar.
  • Diese Transaktionsdatenquelle kann in einer Ausgestaltung ein Transaktionsregister, bevorzugt ein Transaktionsregister des Bezahlsystems, sein. Diese Transaktionsregister stellt bevorzugt, die von einer Teilnehmereinheit, insbesondere eine den elektronischen Münzdatensatz sendende oder gesendete Teilnehmereinheit, an das Transaktionsregister bereitgestellten Transaktionsdatensatz zur Verfügung, insbesondere in einer geänderten Anonymitätsstufe, beispielsweise als anonymisierten und/oder pseudonymisierten Transaktionsdatensatz.
  • Das initiale Erzeugen eines Transaktionsdatensatzes kann auch hier in einer Teilnehmereinheit erfolgen. Dieser Transaktionsdatensatz kann mittels eines Transaktionsregisters in seiner Anonymitätsstufe verändert werden und wird vom Transaktionsregister - als die Transaktionsdatensatzquelle - an das Überwachungsregister bereitgestellt. Eine Erläuterung zur Anonymitätsstufe und deren Einstellung bzw. Veränderung erfolgt später. In dieser Ausgestaltung verändert das Transaktionsregister den von der Teilnehmereinheit erzeugten Transaktionsdatensatz und stellt diesen - als Transaktionsdatenquelle - dem Überwachungsregister bereit. Dabei kann ein Kommunikationskanal zwischen einer Teilnehmereinheit und dem Münzregister genutzt werden. In dieser Ausgestaltung ist die Kommunikation zur Übertragung des Transaktionsdatensatzes zwischen dem Transaktionsregister und dem Überwachungsregister bevorzugt kryptografisch gesichert und kann von etwaigen dazwischengeschalteten Instanzen, beispielsweise einem Münzregister oder einer Teilnehmereinheit nicht eingesehen oder überprüft werden.
  • Unter bestimmten Umständen kann es wünschenswert sein, die Privatsphäre nach einem ordnungsgemäßen Verfahren weiter einzuschränken, beispielsweise wenn kriminelle Aktivitäten vermutet werden oder die hohe Privatsphäre benutzerseitig gewünscht wird. Diesem Teilnehmer (=Benutzer) soll der Zugang zu diesem Bezahlsystem nicht verwehrt bleiben. In einer Ausgestaltung des Verfahrens wird einem definierten (bestimmten) Personenkreis, insbesondere Vollzugsbehörden bei der Strafverfolgung, Zugang zu vertraulichen Informationen gestattet, um Verbrechen zu verhindern oder zu verfolgen. Um den legitimen Zugang abzusichern, kann ein komplexes Verschlüsselungsverfahren angewendet werden. Die in der Teilnehmereinheit erzeugten Transaktionsdaten werden nach der Erstellung umgehend mit einem kryptografischen Schlüssel verschlüsselt. Dieser Schlüssel setzt sich aus mehreren Teilschlüsseln von entfernten Instanzen zusammen. Um den verschlüsselten Transaktionsdatensätze entschlüsseln zu können damit er von dem Überwachungsregister auswertbar ist, sind mehrere (mindestens zwei) Teilschlüssel verschiedener entfernter Instanzen notwendig. Damit ist die Vertraulichkeit und auch die Datenintegrität des Bezahlsystems weiter gewahrt.
  • In der nachfolgenden Beschreibung wird der Kommunikationsvorgang mit Transaktions- und/oder Registerdatensätzen (=Senden) begrifflich vom Kommunikationsvorgang mit Münzdatensätzen getrennt (Übertragen). Ein Transaktionsdatensatz hat bevorzugt seinen Ursprung in einem der Teilnehmereinheiten und wird von diesem erzeugt. Weitere Bearbeitungen, beispielsweise das Anpassen einer Anonymitätsstufe erfolgen dann beispielsweise von einem Transaktionsregister. Ein Registerdatensatz hat bevorzugt seinen Ursprung in einem der Teilnehmereinheiten oder dem Münzregister und wird von diesem erzeugt. Weitere Bearbeitungen, beispielsweise das Anpassen einer Anonymitätsstufe erfolgen dann beispielsweise von dem Münzregister.
  • In einer alternativen Ausgestaltung werden die Transaktionsdatensätze und/oder die Registerdatensätze nicht von der Teilnehmereinheit erzeugt. In diesem Fall werden Kommunikationen zwischen den Teilnehmereinheiten und die dazugehörigen Status- und Registrierungsanforderungen vom Transaktionsregister (im Fall eines Transaktionsdatensatz) und/oder dem Münzregister (im Falle eines Registerdatensatzes) protokolliert und/oder ausgewertet und zur Erzeugung und Bereitstellung des jeweiligen Transaktionsdatensatzes und/oder Registerdatensatzes herangezogen.
  • Ein elektronischer Münzdatensatz kann im Unterschied zu einem Transaktionsdatensatz und/oder einem Registerdatensatz nicht von einer Teilnehmereinheit oder dem Transaktionsregister oder dem Münzregister oder dem Überwachungsregister erzeugt werden. Das Erzeugen eines elektronischen Münzdatensatzes (und auch dessen Vernichtung bzw. Löschen) erfolgt durch eine Herausgeberinstanz des Bezahlsystems, bevorzugt ausschließlich durch die Herausgeberinstanz des Bezahlsystems.
  • In einer bevorzugten Ausgestaltung weist der Transaktionsdatensatz zumindest eine Teilnehmerkennung oder Adresse einer ersten Teilnehmereinheit (=Sender) auf, also ein Datenelement, mit dem dieses Sicherheitselement eindeutig im Bezahlsystem identifiziert werden kann. Zudem weist der Transaktionsdatensatz zumindest, eine Teilnehmerkennung oder Adresse einer zweiten Teilnehmereinheit, (=Empfänger) auf, also ein Datenelement, mit dem dieses Sicherheitselement eindeutig im Bezahlsystem identifiziert werden kann. Zudem weist der Transaktionsdatensatz beispielsweise einen geldwerten Betrag des elektronischen Münzdatensatzes auf.
  • In einer weiter bevorzugten Ausgestaltung weist der Transaktionsdatensatz eine Transaktionsnummer als Datenelement auf. Diese Transaktionsnummer ist beispielsweise eine vor dem Erzeugen-Schritt erzeugte Zufallszahl. Bevorzugt wird dazu ein Zufallszahlengenerator der Teilnehmereinheit oder des Sicherheitselements verwendet. Alternativ oder zusätzlich ist die Transaktionsnummer eine Identifizierungsnummer der Transaktion, die für die Übertragung von der sendenden Teilnehmereinheit eindeutig und einmalig ist. Zusätzlich kann die Transaktionsnummer eine Identifizierung der Transaktion im Bezahlsystem sein.
  • In einer weiter bevorzugten Ausgestaltung weist der Transaktionsdatensatz weiter einen maskierten elektronischen Münzdatensatz korrespondierend zu dem zu übertragenden elektronischen Münzdatensatz, bevorzugt anstelle des geldwerten Betrags des elektronischen Münzdatensatzes oder anstelle des elektronischen Münzdatensatzes, auf. Das Maskieren wird später erläutert. Das Nicht-Einbringen des elektronischen Münzdatensatzes ermöglicht die Einbehaltung zweier Systemvoraussetzungen, nämlich erstens dass der elektronische Münzdatensatz nur einmal im System vorhanden ist (und eben nicht in Kopie im Transaktionsdatensatz vorhanden ist), und zweitens dass der Besitz des elektronischen Münzdatensatzes zur Zahlung berechtigt, also ein noch nicht verschlüsselter Transaktionsdatensatz (ggf. nach dem Übertragen an die zweite Teilnehmereinheit) oder ein entschlüsselter Transaktionsdatensatz potenziell für Bezahlvorgänge verwendbare elektronische Münzdatensätze enthalten würde und damit das Risiko für einen Betrug stiege.
  • In einer weiter bevorzugten Ausgestaltung weist der Transaktionsdatensatz einen Transaktionszeitpunkt auf. Dazu wird ein Zeitstempel generiert und dem Transaktionsdatensatz angefügt. Der Zeitstempel ist bevorzugt bezahlsystemweit eindeutig.
  • In einer bevorzugten Ausgestaltung fügt die Teilnehmereinheit einen Transaktionszeitpunkt an den verschlüsselten Transaktionsdatensatz (im Klartext) an, beispielsweise als Metadatum. So kann dieser Transaktionszeitpunkt im Transaktionsregister als ein Eingangsparameter zur Berechnung eines Löschungszeitpunkts des verschlüsselten Transaktionsdatensatzes sein. So könnte, beispielsweise im Rahmen einer Vorratsdatenspeicherung, der verschlüsselte Transaktionsdatensatz automatischen nach Ablauf einer eingestellten Speicherzeit, beispielsweise X Monate oder Y Jahre, aus einem Transaktionsregister wieder gelöscht werden. Dies ist vorteilhaft für den Fall, dass der Transaktionsdatensatz zeitlich erst viel später nach der Übertragung des Münzdatensatzes an das Transaktionsregister gesendet wird, um die Speicherung nicht (ggf. in illegaler Weise) zu verlängern.
  • Als ein weiteres Metadatum könnte auch eine Teilnehmerkennung oder die Transaktionsnummer des Transaktionsdatensatzes in Klartext angefügt werden.
  • In einer weiter bevorzugten Ausgestaltung weist der Transaktionsdatensatz eine Empfangsbestätigung der zweiten Teilnehmereinheit auf. Die Empfangsbescheinigung dient als Nachweis bzw. Quittierung eines ordnungsgemäßen Empfangs des elektronischen Münzdatensatzes in der zweiten Teilnehmereinheit und der Besitz der Empfangsbestätigung in der ersten Teilnehmereinheit beweist eine ordnungsgemäße Übertragung des elektronischen Münzdatensatzes.
  • Dieser Transaktionsdatensatz widerspricht zunächst einmal dem Wunsch nach Anonymität für die Bezahltranskationen des Bezahlsystems. In einer Ausgestaltung wird der Transaktionsdatensatz deshalb in der Teilnehmereinheit verschlüsselt. Das Verschlüsseln des Transaktionsdatensatzes erfolgt bevorzugt unmittelbar nach dessen Erzeugung, mehr bevorzugt erfolgt das Erzeugen und das Verschlüsseln als eine atomare Operation. Das Verschlüsseln erfolgt mit einem kryptografischen Schlüssel. Damit ist der Transaktionsdatensatz für einen unbeteiligten Dritten nicht einsehbar und dessen Inhalt für diesen unbeteiligten Dritten verborgen. So ist sichergestellt, dass ein Angriff auf das Teilnehmeridentitätsmodul zum Ausspähen unverschlüsselter Transaktionsdaten erfolglos bleibt.
  • Dieser kryptografische Schlüssel ist aus zumindest zwei Teilschlüsseln zusammengesetzt. Jeder Teilschlüssel stammt von einer (einzigen) entfernten Instanz. Die entfernten Instanzen sind voneinander unabhängig. Eine entfernte Instanz hat Kenntnis und Besitz von nur einem (eigenen) Teilschlüssel. Eine entfernte Instanz hat insbesondere keine Kenntnis und ist nicht im Besitz eines Teilschlüssels einer anderen entfernten Instanz. Das Zusammensetzen des kryptografischen Schlüssels beinhaltet auch das Ableiten eines zum Verschlüsseln zu verwendenden öffentlichen Schlüsselteil einer PKI-Schlüsselinfrastruktur, der ggf. unter Verwendung eines zusammengesetzten privaten Schlüsselteils generiert wurde.
  • Mit entfernter Instanz ist hier gemeint, dass diese Instanz keine (lokale) Instanz einer Teilnehmereinheit ist. Die entfernte Instanz ist bevorzugt nicht das Münzregister des Bezahlsystems, nicht das Transaktionsregister des Bezahlsystems und auch nicht das Überwachungsregister des Bezahlsystems, sodass zur Wahrung der Anonymität und Neutralität im Bezahlsystem, eine Unabhängigkeit die Registerinstanzen des Bezahlsystems den verschlüsselten Transaktionsdatensatz nicht entschlüsseln können bzw. keinen Teilschlüssel zur Entschlüsselung beisteuern können.
  • Damit kann der Transaktionsdatensatz bevorzugt an einem vertrauenswürdigen Ort, dem Transaktionsregister, in verschlüsselter Form gespeichert werden. Als Ergebnis eines Gerichtsurteils kann dieser verschlüsselte Transaktionsdatensatz von autorisierten Parteien als den entfernten Instanzen entschlüsselt werden. Diese autorisierten Parteien könnten z.B. eine Strafverfolgungsbehörde, ein Notar, das Justizministerium, eine Zentralbank, eine Herausgeberinstanz des Bezahlverfahrens, eine Gerichtsinstanz oder andere sein.
  • In einer bevorzugten Ausgestaltung sind die kryptografischen Teilschlüssel jeweils von einer Vollzugsbehördeninstanz; einer Notarinstanz; einer Justizministeriuminstanz; einer zentrale Herausgeberinstanz des Bezahlsystems; oder einer Geschäftsbankinstanz des Bezahlsystems.
  • In einer bevorzugten Ausgestaltung ist der kryptografische Schlüssel zum Verschlüsseln des Transaktionsdatensatzes ein öffentlicher Schlüsselteil einer asymmetrischen Schlüsselinfrastruktur (Public-Key-Infrastructure, kurz PKI), wobei der korrespondierende private Schlüsselteil zum Entschlüsseln des verschlüsselten Transaktionsdatensatzes durch eine Additions-Operation oder eine bitweise XOR-Operation aus allen kryptografischen Teilschlüsseln der verschiedenen entfernten Instanzen zusammengesetzt ist.
  • In einer bevorzugten Ausgestaltung ist der kryptografische Schlüssel zum Verschlüsseln des Transaktionsdatensatzes ein öffentlicher Schlüsselteil einer asymmetrischen Schlüsselinfrastruktur (PKI), wobei der korrespondierende private Schlüsselteil zum Entschlüsseln des verschlüsselten Transaktionsdatensatzes aus einer vordefinierten Anzahl von kryptografischen Teilschlüsseln verschiedener entfernter Instanzen zusammengesetzt ist, wobei die vordefinierte Anzahl geringer ist als die Gesamtanzahl der verschiedenen - einen Teilschlüssel aufweisenden - entfernten Instanzen.
  • Alle entfernten Instanzen besitzen nur jeweils einen Teilschlüssel des Entschlüsselungsschlüssel, d.h. alle entfernten Instanzen beziehungsweise eine Untermenge der entfernten Instanzen sind stets erforderlich, um gemeinsam den verschlüsselten Transaktionsdatensatz zu entschlüsseln. Dies verbessert Sicherheit vor Missbrauch, da mehre Instanzen für die Durchführung eines Datenzugriffs benötigt werden, was in einem Angriffsszenario einen bedeutenden Mehraufwand darstellt.
  • Die Teilschlüssel werden zu einem gemeinsamen (privaten) Entschlüsselungsschlüssel kombiniert. Dieses Kombinieren erfolgt beispielsweise in dem Transaktionsregister. Alternativ erfolgt das Kombinieren in der ersten Teilnehmereinheit. Dieses Kombinieren erfolgt beispielsweise durch Addition oder durch bitweise XOR-Verknüpfung, die keine entfernte Instanz in bloßer Kenntnis der/des Teilschlüssels für sich allein erhalten kann. Dieser gemeinsame (private) Entschlüsselungsschlüssel wird dann zur Entschlüsselung des verschlüsselten Transaktionsdatensatzes verwendet.
  • Der entsprechende öffentliche Schlüsselteil dieses gemeinsamen privaten Entschlüsselungsschlüssels wird in der ersten Teilnehmereinheit zum Verschlüsseln des erzeugten Transaktionsdatensatzes verwendet. Dazu wird dieser öffentliche Schlüsselteil bevorzugt von dem Transaktionsregister an die Teilnehmereinheit versendet und dort empfangen.
  • In einer alternativen Ausgestaltung ist der kryptografische Schlüssel zum Verschlüsseln ein symmetrischer Schlüssel, wobei der korrespondierende private Schlüsselteil zum Entschlüsseln des Transaktionsdatensatzes durch eine Additions-Operation oder eine bitweise XOR-Operation aus zumindest zwei kryptografischen Teilschlüsseln zusammengesetzt ist.
  • Dieses Schlüssel-Konzept garantiert, dass keine entfernte Instanz alle anderen umgehen könnte, um Daten allein zu entschlüsseln. In einer Ausgestaltung wird eine Schwellenwert-Kryptographie angewendet, um es zu ermöglichen, dass nicht zwingend alle entfernten Instanzen ihren Teilschlüssel beisteuern müssen, sondern dass eine Untermenge der Instanzen ausreicht, um den Entschlüsselungsschlüssel zusammenzusetzen. Dabei gilt, dass zumindest die Anzahl der Untermenge ihren jeweiligen Teilschlüssel beisteuern muss. Ist die Untermenge kleiner als eine vordefinierte Mindestanzahl an entfernten Instanzen, so ist eine Entschlüsselung nicht möglich.
  • Die hier beschriebenen Verschlüsselungs-Verfahren sind transparent, um eine Benutzerakzeptanz zu gewährleisten.
  • Der (verschlüsselte) Transaktionsdatensatz wird an ein Transaktionsregister gesendet. Dabei kann eine übliches Kommunikationsprotokoll, wie TCP/IP oder einen Mobilfunkkommunikation, verwendet werden. Im Fall eines Sicherheitselements als erzeugende Instanz des Transaktionsdatensatzes wird beispielsweise ein proaktives Kommando an die Teilnehmereinheit gesendet.
  • Das Transaktionsregister ist bevorzugt eine Instanz des Bezahlsystems und dient der Archivierung des (verschlüsselten) Transaktionsdatensatzes. Dieser (verschlüsselte) Transaktionsdatensatz kann dort insbesondere nach behördlicher Anfrage, beispielsweise mittels zusammengesetzten (kombinierten) Teilschlüsseln der entfernten Instanzen entschlüsselt werden und in der Folge, von der anfragenden Instanz (Gerichtsbehörde, etc.) eingesehen werden. Eine Einsicht zu Kontroll-Überprüfzwecken in jeden übertragenen elektronischen Münzdatensatz im Bezahlsystem und/oder in jeden Registerdatensatz, beispielsweise einer zu registrierenden Modifikation oder registrierten Modifikation eines elektronischen Münzdatensatzes im Bezahlsystem, ist somit ermöglicht, bei Anwendung der komplexen Verschlüsselung aber nur unter sehr strengen Auflagen technisch umsetzbar.
  • Die behördliche Anfrage, beispielsweise ein Gerichtsbeschluss, enthält eine Teilnehmereinheiten-Kennung und fragt alle Transaktionsdatensätze dieser Kennung innerhalb eines bestimmten Zeitraums oder zu einem bestimmten Zeitpunkt ab. Die Metadaten des Transaktionsdatensatzes vereinfachen dann die Beantwortung dieser Anfrage beim Transaktionsregister.
  • Das Transaktionsregister kann beispielsweise eine nicht-öffentliche Datenbank des Bezahlsystems sein. In dieser Datenbank werden die verschlüsselten Transaktionsdatensätze - für eine mögliche spätere Überprüfung - abgelegt. Das Transaktionsregister ist beispielsweise als eine zentral geführte Datenbank in Form eines Datenspeichers oder Dienste-Servers des Bezahlsystems ausgebildet.
  • In einer bevorzugten Ausgestaltung ist ein Sicherheitselement betriebsbereit in einer Teilnehmereinheit eingebracht. Damit ist sichergestellt, dass die Transaktionsdatensätze ohne Manipulationen erzeugt und verschlüsselt und ggf. auch gesendet werden. In einer Ausgestaltung wird der Transaktionsdatensatz im Sicherheitselement erstellt und dann durch die Teilnehmereinheit verschlüsselt.
  • Ein Sicherheitselement ist eine technische ressourcenbeschränkte Einrichtung. Ein Sicherheitselement ist beispielsweise ein spezielles Computerprogrammprodukt, insbesondere in Form einer abgesicherten Laufzeitumgebung innerhalb eines Betriebssystems eines Endgeräts, englisch Trusted Execution Environments, TEE, oder einer eSIM-Software, gespeichert auf einem Datenspeicher, beispielsweise einer Teilnehmereinheit, wie (mobiles) Endgerät, einer Maschine oder eines Bankautomat. Alternativ oder zusätzlich ist das Sicherheitselement beispielsweise als spezielle Hardware, insbesondere in Form eines gesicherten Hardware-Plattform-Moduls, englisch Trusted Platform Module, TPM oder als eine Chipkarte oder ein eingebettetes Sicherheitsmodul, eUICC, eSIM, ausgebildet. Das Sicherheitselement stellt eine vertrauenswürdige Umgebung bereit und hat damit ein höheres Level-of-Trust als ein Endgerät, in dem das Sicherheitselement ggf. betriebsbereit integriert ist.
  • Das Übertragen eines elektronischen Münzdatensatzes erfolgt bevorzugt zwischen zwei Sicherheitselementen, um eine vertrauenswürdige Umgebung zu schaffen. Dabei erfolgt die logische Übertragung des elektronischen Münzdatensatzes direkt, wohingegen eine physikalische Übertragung eines oder mehrere dazwischenliegende Instanzen aufweisen kann, beispielsweise eines oder mehrere Teilnehmereinheiten zur Herstellung der Betriebsbereitschaft des/der Sicherheitselemente und/oder ein entfernter Datenspeicherdienst, bei dem eine Geldbörsen-Applikation mit elektronischen Münzdatensätzen physikalisch gespeichert sind.
  • Sicherheitselemente können elektronische Münzdatensätze untereinander übertragen und dann direkt - ohne Registerprüfung(en) - weiterverwenden, insbesondere wenn das Bezahlsystem voraussetzt, dass elektronische Münzdatensätze von Sicherheitselementen per se als gültig anzusehen sind.
  • In einer Teilnehmereinheit bzw. einem Sicherheitselement können ein oder mehre elektronische Münzdatensätze sicher abgelegt sein, beispielsweise kann eine Vielzahl von elektronischen Münzdatensätzen in einem exklusiv einer Teilnehmereinheit oder einem Sicherheitselement zugeordneten Datenspeicher gesichert abgelegt sein. Der Datenspeicher stellt dann beispielsweise eine elektronische Geldbörsen-Applikation dar. Dieser Datenspeicher kann beispielsweise intern, extern oder virtuell zum Sicherheitselement sein.
  • Das erste Sicherheitselement könnte zudem elektronische Münzdatensätze auch von weniger vertrauenswürdigen Einheiten, wie Teilnehmereinheiten, also einem Endgerät oder einer Maschine, erhalten haben, beispielsweise über eine Import/Export Funktion des Sicherheitselements. Derartig erhaltene elektronische Münzdatensätze, die nicht direkt von einem anderen Sicherheitselement erhalten wurden, gelten als weniger vertrauenswürdig. Es könnte eine Voraussetzung des Bezahlsystems sein, derartige elektronische Münzdatensätze auf Gültigkeit mittels des Münzregisters prüfen zu müssen oder durch eine Aktion (Modifikation) durch das empfangende Sicherheitselement, den elektronischen Münzdatensatz auf das empfangende Sicherheitselement umzutragen, bevor dieser weitergegeben werden darf.
  • Ein Übertragen des elektronischen Münzdatensatzes zwischen dem ersten und dem zweiten Sicherheitselement kann in ein Übertragungsprotokoll zwischen zwei Teilnehmereinheiten integriert sein und/oder in einem sicheren Kanal zwischen zwei Anwendungen der jeweiligen Teilnehmereinheit integriert sein. Zudem kann die Übertragung eine Internet-Datenverbindung zu einem externen Datenspeicher, beispielsweise einem Online-Speicher, beinhalten.
  • Der (zu übertragende oder zu modifizierende) elektronische Münzdatensatz ist in einem Münzregister des Bezahlsystems registriert. Damit ist beispielsweise zum Registrieren des elektronischen Münzdatensatzes der Aufbau einer Kommunikationsverbindung zu dem Münzregister vorgesehen. Diese Kommunikationsverbindung muss nunmehr nicht zwangsläufig während des Übertragungsvorgangs (Bezahlvorgang) vorhanden sein. Vorzugsweise ist das Münzregister zur Verwaltung und Prüfung von maskierten elektronischen Münzdatensätzen vorgesehen. Das Münzregister kann zusätzlich weitere (Nicht-Bezahl-) Transaktionen zwischen Teilnehmereinheiten verwalten und prüfen.
  • Das Münzregister - als Teil der zweiten Schicht - ist beispielsweise eine Datenbank, in der ein Registerdatensatz erzeugt und/oder abgelegt ist. Das Münzregister ist dazu eingerichtet, zumindest einen Registerdatensatz an das Überwachungsregister bereitzustellen. Ein Registerdatensatz ist ein Datensatz, der es ermöglicht, die Gültigkeit, den Status, die Historie und/oder den Verbleib eines elektronischen Münzdatensatzes zu erfahren und/oder zu verifizieren. Ein Registerdatensatz ist bevorzugt einem elektronischen Münzdatensatz eindeutig zugeordnet. Der Registerdatensatz dient nur der Überprüfung und kann nicht verwendet werden, um anstelle des elektronischen Münzdatensatzes für Bezahltransaktionen verwendet zu werden.
  • Ein Registerdatensatz weist dabei eines oder mehrere der folgenden Datenelemente auf: eine Signatur des elektronischen Münzdatensatzes; einen Bereichsnachweis eines elektronischen Münzdatensatzes; einen Prüfwert des elektronischen Münzdatensatzes; einen Prüfwert betreffend den elektronischen Münzdatensatz; einen Zählerwert betreffend den elektronischen Münzdatensatz; eine Teilnehmerkennung einer, den Registerdatensatz sendenden Teilnehmereinheit; einen maskierten elektronischen Münzdatensatz; und/oder einen geldwerten Betrag des elektronischen Münzdatensatz. Alle diese Datenelemente und deren Funktion werden an den geeigneten Stellen definiert.
  • In einer bevorzugten Ausgestaltung stellt das Münzregister einen Registerdatensatz bereit. Der Registerdatensatz weist beispielsweise als Datenelement einen maskierten elektronischen Münzdatensatz korrespondierend zu einem elektronischen Münzdatensatz auf. Der maskierte elektronische Münzdatensatz wurde beispielsweise von einer Teilnehmereinheit oder einer Herausgeberinstanz bereitgestellt. Der Besitz eines maskierten elektronischen Münzdatensatzes erlaubt keine Offenlegung von Datenelementen des (korrespondierenden) elektronischen Münzdatensatzes, wodurch ein derartiger Registerdatensatz mit (nur) maskierten Münzdatensätzen anonym in Bezug auf eine Teilnehmerkennung (dies wird nachfolgend auch als identitätsanonym bezeichnet) und auch anonym bezüglich eines geldwerten Betrags des elektronischen Münzdatensatzes (dies wird nachfolgend auch als betragsanonym bezeichnet) ist. Das Maskieren wird später erläutert.
  • In einer weiteren Ausgestaltung weist der Registerdatensatz beispielsweise als Datenelemente einen maskierten elektronischen Münzdatensatz (korrespondierend zu einem elektronischen Münzdatensatz) und eine Betragskategorie betreffend einen geldwerten Betrag des elektronischen Münzdatensatzes korrespondierend zu dem maskierten elektronischen Münzdatensatz auf. Ein derartiger Registerdatensatz mit maskiertem Münzdatensatz ist identitätsanonym und betragspseudonym. Das Maskieren und auch das Verwenden von Betragskategorien wird später erläutert.
  • In einer weiteren Ausgestaltung weist der Registerdatensatz beispielsweise als Datenelemente eine Münzkennung eines elektronischen Münzdatensatzes, einen Prüfwert des elektronischen Münzdatensatzes und ein Pseudonym der Teilnehmerkennung auf. Ein derartiger Registerdatensatz ist identitätspseudonym und betragsanonym. Beispielsweise sind maskierte elektronische Münzdatensätze als Datenelement im Registerdatensatz oder als der Registerdatensatz vorgesehen. Diese maskierten elektronischen Münzdatensätze sind mit ihrer entsprechenden Verarbeitung im Münzregister registriert. Das Maskieren wird später erläutert werden. In einer bevorzugten Ausgestaltung lässt sich daraus ein Gültigkeitsstatus des (maskierten) elektronischen Münzdatensatzes ableiten. Bevorzugt wird die Gültigkeit der (maskierten) elektronischen Münzdatensätze in dem Münzregister vermerkt (registriert).
  • Modifikationen, wie Umschalten, Aufteilen oder Kombinieren, zu den einzelnen elektronischen Münzdatensätzen werden im Münzregister registriert.
  • Bevorzugt verursachen angefragte bzw. durchgeführte bzw. durchzuführende Modifikationen ebenfalls das oben beschriebene Bereitstellen (und ggf. Verschlüsseln) eines Transaktionsdatensatzes. Auf diese Weise dient die Transaktionsdatenquelle, also beispielsweise ein Transaktionsregister, auch zur Archivierung von Modifikationen eines elektronischen Münzdatensatzes. Diese zu den Informationen des Münzregisters oder des Überwachungsregisters möglicherweise redundanten Informationen im Bezahlsystem erhöhen die Stabilität und die Sicherheit des Bezahlsystems.
  • Die Registrierung der Verarbeitung bzw. der Verarbeitungsschritte für eine jeweilige Modifikation in dem Münzregister kann in einer Ausgestaltung des Bezahlsystems auch das Registrieren von Prüfergebnissen und Zwischenprüfergebnissen betreffend die Gültigkeit eines elektronischen Münzdatensatzes im Münzregister betreffen, insbesondere das Bestimmen von Prüfwerten und Zählerwerten entsprechender elektronischer Münzdatensätze. Ist eine Verarbeitung endgültig, wird dies beispielsweise durch entsprechende Markierungen oder einer abgeleiteten Gesamtmarkierung im Münzregister angezeigt. Eine endgültige Verarbeitung entscheidet sodann, ob ein elektronischer Münzdatensatz gültig oder ungültig ist.
  • In einer bevorzugten Ausgestaltung des Bezahlsystems erfolgt das Registrieren von Prüfergebnissen und Zwischenprüfergebnissen betreffend eine jeweilige Modifikation oder einen Übertragungsvorgang zwischen Teilnehmereinheiten bzw. deren Sicherheitselementen und betreffend die Gültigkeit (insbesondere für ein Anzeigen) eines elektronischen Münzdatensatzes, insbesondere das Bestimmen von Prüfwerten und Zählerwerten entsprechender elektronischer Münzdatensätze nicht im Münzregister des Bezahlsystems, sondern in einem Überwachungsregister des Bezahlsystems.
  • In einer bevorzugten Ausgestaltung wird im Münzregister ein Registerdatensatz betreffend den elektronischen Münzdatensatz durch einen zu registrierenden Registrierdatensatz betreffend den elektronischen Münzdatensatz oder den modifizierten elektronischen Münzdatensatz ersetzt. Damit werden im Münzregister (nur) aktuelle - im Bezahlsystem existierende - Münzdatensätze als Registerdatensatz gepflegt. Etwaige Vorgängerversionen oder frühere Modifikationen werden dann beispielsweise im Überwachungsregister (als Überwachungsdatensatz) geführt und werden zu diesem Zweck vom Münzregister während des Ersetzen-Vorgangs an das Überwachungsregister bereitgestellt und werden dort aufbewahrt. Damit kann die Historie zu dem elektronischen Münzdatensatz durch das Überwachungsregister protokolliert werden. Damit wird das Münzregister registerdatensatzoptimiert (=speicheroptimiert) ausgestaltet und reagiert schneller auf Register- oder Statusanforderungen von Teilnehmereinheiten und/oder dem Überwachungsregister.
  • In einer bevorzugten Ausgestaltung des Bezahlsystems ist das Überwachungsregister eingerichtet zum Speichern von Überwachungsdatensätzen. Ein Überwachungsdatensatz wird aus zumindest einem Transaktionsdatensatz und zumindest einem Registerdatensatz im Überwachungsregister gebildet.
  • Dabei korrespondiert in einer Ausgestaltung ein Überwachungsdatensatz mit genau einem elektronischen Münzdatensatz und wird aus genau einem Transaktionsdatensatz (ebenfalls korrespondierend zu dem elektronischen Münzdatensatz) und genau einem Registerdatensatz (ebenfalls korrespondierend zu dem elektronischen Münzdatensatz) im Überwachungsregister gebildet. Dieses Bilden erfolgt nach dem Bereitstellen durch Transaktionsdatenquelle und/oder Münzregister. Ein Überwachungsdatensatz betrifft dann genau eine Bezahltransaktion.
  • In einer alternativen Ausgestaltung kann ein Überwachungsdatensatz auch eine Mehrzahl von elektronischen Münzdatensätzen betreffen, beispielsweise elektronische Münzdatensätze, die von einer Teilnehmereinheit, bevorzugt innerhalb eines vordefinierten Zeitraums, versendet werden. Dabei wird ein Überwachungsdatensatz beispielsweise aus mehreren Transaktionsdatensätzen betreffend diese Teilnehmereinheit, bevorzugt auch betreffend diesen Transaktionszeitraum, gebildet. Zudem wird der Überwachungsdatensatz beispielsweise aus mehreren Registerdatensätzen betreffend Modifikationen an Münzdatensätzen initiiert und/oder angefordert und/oder statusgeprüft von der Teilnehmereinheit, bevorzugt auch betreffend diesen Transaktionszeitraum, gebildet. Sodann betrifft ein Überwachungsdatensatz eine Mehrzahl von Transaktionsdatensätzen (korrespondierend zu jeweiligen elektronischen Münzdatensätzen dieser Teilnehmereinheit, bevorzugt in diesem Transaktionszeitraum) und zumindest einem, bevorzugt mehreren Registerdatensätzen (ebenfalls korrespondierend zu den jeweiligen elektronischen Münzdatensätzen dieser Teilnehmereinheit, bevorzugt in diesem Transaktionszeitraum) im Überwachungsregister gebildet. Dieses Bilden erfolgt bevorzugt nach dem Bereitstellen durch Transaktionsdatenquelle und/oder Münzregister. Ein Überwachungsdatensatz betrifft dann mehrere Bezahltransaktionen dieser Teilnehmereinheit, bevorzugt innerhalb eines vordefinierten Zeitraums.
  • Nach der Bildung des jeweiligen Überwachungsdatensatzes kann eine Auswertung des Überwachungsdatensatzes durch das Überwachungsregister erfolgen. Diese Auswertung betrifft das Prüfen auf doppeltes Ausgeben der elektronischen Münzdatensätze oder das unerlaubte Generieren von geldwerten Beträgen durch eine Teilnehmereinheit und/oder auch das Prüfen einer Alterung von elektronischen Münzdatensätze. Durch das Bilden und Auswerten im Überwachungsregister kann beispielsweise festgestellt werden, dass eine Teilnehmereinheit einen Münzdatensatz doppelt ausgegeben hat oder einen geldwerten Betrag verändert hat. Zudem kann festgestellt werden, dass ein Münzdatensatz eine vordefinierte Zeitspanne nicht verwendet wurde und dies dem Teilnehmer mitgeteilt wird oder eine automatische Rückgabe an die Herausgeberinstanz initiiert wird.
  • Aufgrund eingestellter Anonymitätsstufen wird sichergestellt, dass das Bezahlsystem weiterhin anonym oder pseudonym ist, jedoch eine verlässliche Prüfung der Gültigkeit durch Überwachung der Transkationen erfolgt.
  • Das Bilden und Auswerten erfolgt beispielsweise für jede Transaktion, sodass ein späteres Aufdecken von Betrugsversuchen garantiert möglich ist.
  • Die aus (anonymisierten und/oder pseudonymisierten) Transaktionsdatensätzen und Registerdatensätzen gebildeten Überwachungsdatensätze ermöglichen eine Überwachung der Transaktionen im laufenden Betrieb des Bezahlsystems. Das Überwachungsregister ist eine von dem Münzregister getrennte Instanz des gleichen Bezahlsystems. Durch die Aufteilung von Münzregister und Überwachungsregister innerhalb eines Bezahlsystems kann das Münzregister weniger komplex ausgebildet sein und eine oberflächliche Prüfung der Gültigkeit abbilden während im Überwachungsregister die Korrektheit von Übertragungsvorgängen, eine ggf. geforderte Deanonymisierung einer Teilnehmereinheit und/oder die Prüfung von Zählwerten bzw. Prüfwerten elektronischer Münzdatensätze erfolgt.
  • Sowohl das Münzregister als auch das Überwachungsregister können beispielsweise dezentrale öffentliche Datenbanken sein. Diese Datenbank ermöglicht es auf einfache Weise, elektronische Münzdatensätze bezüglich ihrer Gültigkeit zu prüfen und „Double-Spending“, also Mehrfachausgaben, zu verhindern, ohne dass das Übertragen selbst registriert oder protokolliert wird. Die Datenbank, beispielsweise eine Distributed-Ledger-Technologie, DLT, beschreibt dabei eine Technik für vernetzte Computer, die zu einer Übereinkunft über die Reihenfolge von bestimmten Transaktionen kommen und darüber, dass diese Transaktionen Daten aktualisieren. Es entspricht einem dezentral geführten Verwaltungssystem oder einer dezentral geführten Datenbank.
  • Alternativ ist das Münzregister eine zentral geführte Datenbank, beispielsweise in Form eines öffentlich zugänglichen Datenspeichers oder als Mischform aus zentraler und dezentraler Datenbank. Beispielsweise sind das Münzregister und das Überwachungsregister als ein Dienste-Server des Bezahlsystems ausgebildet.
  • Das Münzregister ist bevorzugt in zumindest zwei unterschiedlichen Modi betriebsbereit. In einem ersten Modus werden nur Registerdatensätze und in einem zweiten Modus werden die Registerdatensätze und die Transaktionsdatensätze vom Münzregister an das Überwachungsregister bereitstellt. Die Auswahl des Modus erfolgt bevorzugt auf Basis einer Anonymität der Teilnehmereinheit. In der Regel authentisieren sich Teilnehmerkennungen am Münzregister, um einen elektronischen Münzdatensatz registrieren zu lassen (Registeranforderung) oder um einen Status eines elektronischen Münzdatensatzes abzufragen (Statusanforderung). Im Rahmen dieser Authentisierung übermittelt die authentifizierende Teilnehmereinheit eine Teilnehmerkennung oder ein Pseudonym der Teilnehmerkennung, was zur erfolgreichen Authentisierung der Teilnehmereinheit am Münzregister führt.
  • Der zweite Modus im Münzregister wird dabei nur eingestellt ist, wenn eine Teilnehmereinheit sich am Münzregister erfolgreich authentisiert hat. Durch die Authentisierung in diesem zweiten Modus (er)kennt das Münzregister die Teilnehmereinheit. Alle diesbezüglichen Register- und Statusanforderungen sind dem Münzregister gegenüber nicht (mehr) anonym. Aufgrund der Kombination aus Authentisierung der Teilnehmereinheit und den teilnehmereinheitenseitig gewünschten Anforderungen kann das Münzregister (automatisch) sowohl Registerdatensätze als auch Transaktionsdatensätze an das Überwachungsregister bereitstellen. Dort werden diese Registerdatensätze und Transaktionsdatensätze zu Überwachungsdatensätzen gebildet. Alternativ werden die von der Teilnehmereinheit erzeugten Transaktionsdaten (anstelle einem Transaktionsregister) direkt an das Münzregister bereitgestellt und von dort an das Überwachungsregister bereitgestellt.
  • Der erste Modus wird immer dann eingestellt, wenn sich eine Teilnehmereinheit nicht am Münzregister zu erkennen gibt, sich also nicht authentisiert oder eine geforderte Authentisierung fehlschlägt. Dies kann teilnehmereinheitenseitig gewünscht sein, beispielsweise wenn der entsprechende Teilnehmer am Bezahlsystem anonym bleiben möchte. In diesem Fall kann das Münzregister keine zu einem Registerdatensatz dazugehörigen Transaktionsdatensätze bereitstellen, da eine Identifizierung der sendenden Teilnehmereinheit nicht möglich ist. In diesem Fall werden die Transaktionsdatensätze von dem Transaktionsregister an das Überwachungsregister oder auf anderem Weg direkt von der Teilnehmereinheit dem Überwachungsregister bereitgestellt. Dort werden diese Registerdatensätze und Transaktionsdatensätze zu Überwachungsdatensätzen gebildet.
  • Der Modus kann beispielsweise auf Basis einer Topologie der Teilnehmereinheit eingestellt werden. So können Sicherheitselemente (trusted wallets) als Teilnehmereinheiten eine hohe Vertrauenswürdigkeit aufweisen und dann automatisch der zweite Modus ausgewählt werden. Alternativ könnten unbekannte Endgeräte (non-trusted wallets) aufgrund fehlender Vertrauenswürdigkeit dazu führen, dass das Münzregister automatisch im ersten Modus betrieben wird, einer möglicherweise erfolgreichen Authentisierung dieses unbekannten Endgeräts wird bevorzugt im Münzregister nicht vertraut.
  • In einer bevorzugten Ausgestaltung ist das Münzregister auch dazu eingerichtet, modifizierte elektronische Münzdatensätze zu registrieren, wobei die Status- und/oder Registeranforderungen der Teilnehmereinheiten zudem die modifizierten elektronischen Münzdatensätze betreffen können. Somit führt auch jede - von einer Teilnehmereinheit - geplante oder durchgeführte Modifikation eines Münzdatensatzes zur Erzeugung von Registerdatensätzen und Transaktionsdatensätzen, die im Überwachungsregister zu Überwachungsdatensätzen gebildet und ausgewertet werden. Damit werden auch Modifikationen am Münzdatensatz im Überwachungsregister archiviert und überprüfbar.
  • In einer bevorzugten Ausgestaltung sendet die erste, den elektronischen Münzdatensatz sendende, Teilnehmereinheit den (verschlüsselten) Transaktionsdatensatz an das Transaktionsregister. In der Folge kann die erste Teilnehmereinheit lokal den Transaktionsdatensatz löschen, um Speicherplatz einzusparen.
  • In einer bevorzugten Ausgestaltung wird der Transaktionsdatensatz kryptografisch transportgesichert gesendet. Dabei wird beispielsweise eine gegenseitige Authentifizierung zwischen Teilnehmereinheit und Transaktionsregister angewendet. Ein Schlüsselaustausch wird dabei entweder als Sitzungsschlüssel vorab ausgehandelt oder vorab ausgegeben. Diese zusätzliche Transportsicherung verhindert, dass ein Angreifer erfährt, dass nun ein Transaktionsdatensatz übertragen wird. Dies erhöht die Sicherheit beim Übertragen der Transaktionsdatensätze.
  • In einer bevorzugten Ausgestaltung wird der verschlüsselte Transaktionsdatensatz vom ersten Sicherheitselement an das Transaktionsregister versendet. Damit wird das Transaktionsregister auf einem aktuellen Stand hinsichtlich erfolgter/geplanter Übertragung gehalten und kürzlich erfolgte Transaktionen werden prompt im Transaktionsregister archiviert. Das Versenden wird darüber hinaus priorisiert für den Fall, dass zum Zeitpunkt der Übertragung des Münzdatensatzes keine Verbindung zum Transaktionsregister verfügbar war und die Teilnehmereinheit bzw. dessen Sicherheitselement wird angehalten, bei (erkannter) verfügbarer Kommunikationsverbindung den verschlüsselten Transaktionsdatensatz prompt an das Transaktionsregister zu versenden.
  • In einer bevorzugten Ausgestaltung wird der elektronische Münzdatensatz von der ersten Teilnehmereinheit an die zweite Teilnehmereinheit übertragen. Das Übertragen erfolgt beispielsweise unmittelbar vor dem Erzeugen des Transaktionsdatensatzes. Das Übertragen erfolgt beispielsweise unmittelbar nach dem Erzeugen-Schritt, sodass das Übertragen ein Teil der oben beschriebenen atomaren Operation sein könnte und nur die gesamte Kette von Erzeugen-Übertragen(-Verschlüsseln) ausgeführt werden kann. Damit werden Differenzen zwischen erzeugtem Transaktionsdatensatz und tatsächlich übertragenem Münzdatensatz vermieden.
  • Zum Übertragen des elektronischen Münzdatensatzes zur zweiten Teilnehmereinheit ist nicht zwingend eine Datenverbindung zu übrigen Instanzen des Bezahlsystems vorhanden. Um ein Übertragungsprotokoll sicher auszugestalten, werden die elektronischen Münzdatensätze beispielsweise durch Sicherheitselemente innerhalb jeweiliger Teilnehmereinheiten verwaltet und auch durch diese übertragen. In einer (Offline)- Übertragungsumgebung ist es wichtig, dass Übertragungsfehler oder Übertragungskonflikte ohne dazwischengeschaltete zentrale Instanzen eines Bezahlsystems, beispielsweise dem Münzregister oder dem Überwachungsregister, gelöst werden können. Ein Übertragungsprotokoll kann durch Prüfen des Vorhandenseins einer Empfangsnachricht und Verwendung von Sicherheitselementen sicherstellen, dass ein Übertragungsprozess (Bezahlvorgang), obwohl er asynchron ausgeführt wird, vertrauenswürdig ist. Ein zweistufiges Übertragen (Senden, dann Löschung) ist bevorzugt zu gewährleisten, so dass geldwerte Beträge nicht vernichtet werden noch, dass sie im aktiven Zustand dupliziert werden.
  • In einer bevorzugten Ausgestaltung wird der erzeugte Transaktionsdatensatz in der ersten Teilnehmereinheit, bevorzugt nicht-flüchtig, gespeichert. Die Speicherung kann eine Zwischenspeicherung sein, solange der elektronische Münzdatensatz noch nicht erfolgreich an die zweite Teilnehmereinheit übertragen wurde. Die Speicherung erfolgt dabei lokal. Der Transaktionsdatensatz kann im Falle einer fehlerhaften Übertragung herangezogen werden, um den Übertragungsvorgang zwischen den Teilnehmereinheiten zu wiederholen. Dabei muss am Münzdatensatz oder dem Transaktionsdatensatz selbst keine Veränderung vorgenommen werden. Der gespeicherte Transaktionsdatensatz dient so für eine notwendige Wiederholung (RETRY) der Übertragung bei Verbindungsfehlern oder Authentisierungsproblemen bei der Übertragung.
  • Zusätzlich oder alternativ dient der gespeicherte Transaktionsdatensatz zur Rückabwicklung (ROLLBACK) bei fehlgeschlagener Übertragung des Münzdatensatzes. Damit stellt das Verfahren sowohl ein Abwicklungsverfahren als auch ein Wiederholungsverfahren bereit, um im Übertragungsfehlerfall, bei dem das Übertragen des Münzdatensatzes nicht zu Ende geführt wurde, die Transkation rückabwickeln zu können oder wiederholen zu können.
  • Damit wird die Übertragung im Wiederholungsfall ganz abgeschlossen oder komplett ungeschehen gemacht.
  • In einer bevorzugten Ausgestaltung wird in einem Übertragungsfehlerfall anhand des gespeicherten Transaktionsdatensatzes der elektronische Münzdatensatz erneut gesendet. Dabei wird angenommen, dass die Übertragung des elektronischen Münzdatensatzes fehlgeschlagen ist, der Übertragungsvorgang dennoch abzuschließen ist. Das Übertragen des elektronischen Münzdatensatzes wird prompt wiederholt. Der erneut zu versendende elektronische Münzdatensatz entspricht dem elektronischen Münzdatensatz, bei dessen Übertragung ein Übertragungsfehlerfall eintrat. Am Münzdatensatz sind also für das erneute Versenden keine Veränderungen erforderlich. In einer Ausgestaltung wird zu Protokollzwecken ein weiterer Transaktionsdatensatz generiert.
  • Ein Übertragungsfehlerfall wird beispielsweise angenommen, wenn eine Empfangsbestätigung nicht innerhalb einer vordefinierten Zeitdauer im ersten Sicherheitselement empfangen wurde. Dazu wird beispielsweise ein Timer gestartet, bevorzugt wird der Timer während des Senden-Schritts des elektronischen Münzdatensatzes gestartet.
  • Der Übertragungsfehlerfall kann alternativ oder zusätzlich durch eine Fehlermeldung des ersten oder des zweiten Sicherheitselements angezeigt werden. Damit wird der Fehlerfall explizit angezeigt.
  • Der Übertragungsfehlerfall kann auch durch eine erkannte Verbindungsstörung (connectivity failure) angenommen werden. Damit wird der Fehlerfall implizit angezeigt.
  • Der Übertragungsfehlerfall kann auch aufgrund von misslungener Authentifizierung (authentication failure) eintreten.
  • Der Übertragungsfehlerfall kann auch durch das Abschalten eines Endgeräts (device shutdown), in dem eines der Sicherheitselement betriebsbereit eingebracht ist, oder durch Überschreiten der Übertragungsreichweite (exceeded distance) aufgrund einer Bewegung eines Teilnehmers eintreten.
  • Der Übertragungsfehlerfall kann auch durch einen internen Fehler (internal error) im ersten oder zweiten Sicherheitselement, in einer Applikation des Endgeräts, oder im jeweiligen Endgerät eintreten.
  • In einer bevorzugten Ausgestaltung fragt die erste Teilnehmereinheit, bevorzugt das erste Sicherheitselement, in vordefinierten periodischen Zeitabständen die zweite Teilnehmereinheit, bevorzugt das zweite Sicherheitselement, ab und fordert eine Empfangsbestätigung aktiv an, alternativ auch, wenn ein Zeitwert eines Timers überschritten ist.
  • In einer bevorzugten Ausgestaltung wird nach dem Übertragen-Schritt ein erfolgreiches Übertragen in der ersten Teilnehmereinheit angezeigt. Dabei kann eine Benutzeranzeige aktualisiert werden oder der geldwerte Betrag aus einer Liste verfügbarer geldwerter Beträge gelöscht werden. Einem Teilnehmer (Benutzer) am Bezahlsystem wird durch dieses Anzeigen visualisiert, dass der Übertragungsvorgang erfolgreich war. Zudem oder alternativ wird ein verfügbarer geldwerter Betrag aktualisiert, insbesondere entsprechend des übertragenen geldwerten Betrags reduziert.
  • In einer bevorzugten Ausgestaltung wird im Anzeigen-Schritt der elektronische Münzdatensatz als Eingangsparameter einer Applikation der ersten Teilnehmereinheit ausgewertet. Die Transaktionsdaten dieses elektronischen Münzdatensatzes steuern damit aktiv den Übertragungsvorgang ungeachtet einer Applikation, die in der ersten Teilnehmereinheit ausführbar eingebracht ist. Änderungen am elektronischen Münzdatensatz werden für einen Benutzer durch die Applikation auf der ersten Teilnehmereinheit visualisiert, der Benutzer erhält demnach prompte Rückmeldung über die Gültigkeit/den Status des zu übertragenden/übertragenen elektronischen Münzdatensatzes.
  • In einer bevorzugten Ausgestaltung wird der Übertragen-Schritt erst ausgeführt, wenn ein Prüfen-Schritt ergibt, dass ein Prüfwert für eine Anzahl von Übertragungen an die zweite Teilnehmereinheit oder an eine oder mehrere weitere Teilnehmereinheiten bei fehlgeschlagenem Kommunikationsverbindungsaufbau zum Transaktionsregister oder fehlgeschlagenem Versenden des (verschlüsselten) Transaktionsdatensatzes an das Transaktionsregister oder das Überwachungsregister unterhalb oder gleich einem vordefinierten Schwellwert ist. Damit wird die Anzahl von Übertragungen von Münzdatensätze von der ersten Teilnehmereinheit auf einen Maximalwert begrenzt, wenn in der Zwischenzeit kein Senden der jeweiligen Transaktionsdatensätze an das Transaktionsregister erfolgt ist bzw. erfolgen konnte. Damit wird die erste Teilnehmereinheit gezwungen, stets zu prüfen, ob ein Schwellwert, beispielsweise 100, mehr bevorzugt 50, mehr bevorzugt 10 Übertragungen, idealerweise 5 Übertragungen, erreicht ist.
  • In einer bevorzugten Ausgestaltung muss bei Überschreiten eines vordefinierten Schwellwerts eines Prüfwerts für eine Anzahl von Übertragungen an die zweite Teilnehmereinheit oder an eine oder mehrere weitere Teilnehmereinheiten bei fehlgeschlagenem Kommunikationsverbindungsaufbau zum Transaktionsregister beziehungsweise das Überwachungsregister oder fehlgeschlagenem Versenden des verschlüsselten Transaktionsdatensatz an das Transaktionsregister beziehungsweise das Überwachungsregister ein Versenden des verschlüsselten Transaktionsdatensatzes und/oder eines gespeicherten Transaktionsdatensatzes an das Transaktionsregister beziehungsweise das Überwachungsregistervor dem Übertragen des elektronischen Münzdatensatzes erfolgen. Damit wird die Anzahl von Übertragungen von Münzdatensätzen von der ersten Teilnehmereinheit auf einen Maximalwert begrenzt, wenn in der Zwischenzeit kein Senden der jeweiligen Transaktionsdatensätze an das Transaktionsregister beziehungsweise das Überwachungsregister erfolgt ist bzw. erfolgen konnte. Damit wird die erste Teilnehmereinheit gezwungen, die verschlüsselten Transaktionsdatensätze zu senden. Ein Übertragen von Münzdatensätzen ist bis zum Erfolgreichen Versenden der Transaktionsdatensätze unterbunden. Der Schwellwert ist beispielsweise 100, mehr bevorzugt 50, mehr bevorzugt 10 Übertragungen, idealerweise 5 Übertragungen.
  • In einer bevorzugten Ausgestaltung wird bei erfolgreicher Übertragung des elektronischen Münzdatensatzes und fehlgeschlagenem Kommunikationsverbindungsaufbau zum Transaktionsregister oder fehlgeschlagenem Versenden des verschlüsselten Transaktionsdatensatz an das Transaktionsregister ein Prüfwert in der ersten Teilnehmereinheit inkrementiert. Auf diese Weise ist der zu prüfende Prüfwert stets aktuell in Bezug auf übertragene Münzdatensätze, deren korrespondierender Transaktionsdatensatz noch nicht von der Teilnehmereinheit an das Transaktionsregister versendet wurde.
  • In einer bevorzugten Ausgestaltung werden im Bezahlsystem die weiteren Schritte ausgeführt: Maskieren des elektronischen Münzdatensatzes durch Anwenden einer homomorphen Einwegfunktion auf den elektronischen Münzdatensatz zum Erhalten eines maskierten elektronischen Münzdatensatzes und Registrieren des maskierten elektronischen Münzdatensatzes in einem Münzregister des Bezahlsystems, wobei das Registrieren bevorzugt für ein Umschalten, Aufteilen oder Verbinden maskierter elektronischer Münzdatensätze. Damit werden Modifikationen am Münzdatensatz in dem Münzregister nachgehalten und dokumentiert, ohne dass eine Anonymität im Bezahlsystem aufgehoben ist. Das Maskieren wird später erläutert.
  • In einer bevorzugten Ausgestaltung ist das Ablegens in dem Transaktionsregister zeitlich auf einen vordefinierten Zeitraum begrenzt. Dieser Zeitraum beginnt beispielsweise mit dem Zeitpunkt des Empfangens des verschlüsselten Transaktionsdatensatzes im Transaktionsregister oder wird durch einen Transaktionszeitpunkt, der als Metadatum am verschlüsselten Transaktionsdatensatz angefügt ist, gestartet. Dieser Zeitraum beträgt beispielsweise einer gesetzlichen Vorgabe, also einer Mindest- oder Maximalzeitdauer zur Aufbewahrung der Transaktionsdatensätze, beispielsweise im Rahmen einer Vorratsdatenspeicherung, beispielsweise X- Monate oder Y-Jahre, wie 6 Monate oder 2 Jahre.
  • In einer bevorzugten Ausgestaltung umfasst das Verfahren den weiteren Schritt des Entschlüsselns des verschlüsselten Transaktionsdatensatzes mit einem kryptografischen Schlüssel, wobei der Schlüssel zum Entschlüsseln des verschlüsselten Transaktionsdatensatzes aus zumindest zwei kryptografischen Teilschlüsseln jeweiliger verschiedener entfernter Instanzen in dem Transaktionsregister zusammengesetzt wird.
  • In einer bevorzugten Ausgestaltung erfolgt das Zusammensetzen durch eine Additions-Operation oder eine bitweise XOR-Operation.
  • In einer bevorzugten Ausgestaltung ist der kryptografische Schlüssel zum Entschlüsseln des verschlüsselten Transaktionsdatensatzes aus einer vordefinierten Anzahl von kryptografischen Teilschlüsseln verschiedener entfernter Instanzen zusammengesetzt, wobei die vordefinierte Anzahl geringer ist als die Gesamtanzahl der verschiedenen Instanzen.
  • In einer bevorzugten Ausgestaltung erfolgt das Entschlüsseln nur auf externe Anfrage. Diese Anfrage kann das Ergebnis eines Ermittlungsverfahrens sein, in dessen Rahmen zu prüfen ist, ob eine Transaktion tatsächlich erfolgt ist.
  • In einer bevorzugten Ausgestaltung weist das Transaktionsregister ein Hardware Security Module, kurz HSM, auf, wobei das Hardware Security Module ein sicherer Schlüsselspeicher ist, in welchem verschiedene Generationen der Teilschlüssel der jeweiligen entfernten Instanzen aufbewahrt sind. Somit können Teilschlüssel einzelner entfernter Instanzen erneuert bzw. ausgetauscht werden, ohne dass die bis dahin abgelegten verschlüsselten Transaktionsdatensätze umverschlüsselt werden müssen oder gar unentschlüsselbar im Transaktionsregister verbleiben müssten. Das Nachhalten der Schlüssel-Generationen erfolgt bevorzugt durch ein HSM des Transaktionsregisters.
  • In einer bevorzugten Ausgestaltung weist das Transaktionsregister ein Hardware Security Module auf gegenüber dem sich die verschiedenen Instanzen vor dem Entschlüsseln des abgelegten verschlüsselten Transaktionsdatensatzes authentisieren. Das HSM kann demnach verschiedene Funktionen erfüllen, es ist primär ein sicherer Schlüsselspeicher und eine sichere Verarbeitungseinheit. Das HSM-Modul kann beispielsweise verschiedene Schlüsselgenerationen der Teilschlüssel enthalten, wobei die entfernten Instanzen sich gegenüber dem HSM authentisieren, um die Entschlüsselung mit allen Generationen freizugeben.
  • In einer bevorzugten Ausgestaltung wird nach dem Empfangen des verschlüsselten Transaktionsdatensatzes von der ersten Teilnehmereinheit der verschlüsselte Transaktionsdatensatz umverschlüsselt. Damit wird stets beim Empfang der verschlüsselten Transaktionsdaten umverschlüsselt (d.h. entschlüsselt und neu verschlüsselt) und so vermieden, dass im Transaktionsregister Transaktionsdatensätze verschieden verschlüsselt abgelegt sind. Dies vereinfacht die Administration der verschlüsselten Transaktionsdatensätze im Transaktionsregister.
  • Alternativ wird nach dem Empfangen eines aktualisierten Teilschlüssels von einer der Instanzen der verschlüsselte Transaktionsdatensatz umverschlüsselt. Damit wird bei einem Schlüsselwechsel einer Instanz vermieden, dass im Transaktionsregister Transaktionsdatensätze verschieden verschlüsselt abgelegt sind.
  • In einer bevorzugten Ausgestaltung wird nach dem Empfangen des verschlüsselten Transaktionsdatensatzes von der ersten Teilnehmereinheit der verschlüsselte Transaktionsdatensatz entschlüsselt.
  • In einer bevorzugten Ausgestaltung wird im Transaktionsdatensatz und/oder im Registerdatensatz eine Kennung einer (ersten und/oder zweiten) Teilnehmereinheit durch ein Pseudonym im Transaktionsdatensatz bzw. dem Registerdatensatz ersetzt, um einen pseudonymisierten Transaktionsdatensatz (=identitätspseudonymer Transaktionsdatensatz) und/oder eine pseudonymisierten Registerdatensatz (=identitätspseudonymer Registerdatensatz) zu erhalten. Das Ablegen der empfangenen verschlüsselten Transaktionsdatensätze ist in einer Ausgestaltung des Verfahrens davon unberührt.
  • In einer bevorzugten Ausgestaltung weist das Bezahlsystem ein Personenregister auf, wobei im Personenregister natürliche Personen zu jeweiligen Teilnehmerkennungen von Teilnehmereinheiten des Bezahlsystems und/oder zu jeweiligen Pseudonymen von Teilnehmereinheiten zugeordnet sind. Damit ist eine Kennung einer Teilnehmereinheit (beispielsweise der Teilnehmer-ID eines Endgeräts) im Bezahlsystem eindeutig einer natürlichen Person zugeordnet. Diese Personenzuordnung wird beispielsweise von einer Herausgeberinstanz des Bezahlsystems oder einer Bankinstanz des Bezahlsystems durchgeführt und ggf. auch dort verwaltet. Diese Personenzuordnung kann auch von einer Dienste-Instanz, beispielsweise einer Instanz, die eine Geldbörse-Applikation für das Endgerät bereitstellt oder die einen Online-Zugang zu einer Cloud-Geldbörse bereitstellt, verwaltet. Diese Zuordnung von Person zu Kennung wird von der jeweiligen Instanz erst nach erfolgreicher Identifizierung der Person, beispielsweise durch Vorlage eines amtlichen Identifikationsdokuments, wie Personalausweis oder Pass, durchgeführt.
  • In einer bevorzugten Ausgestaltung wird nach dem Empfangen des Transaktionsdatensatzes und/oder des Registerdatensatzes ein geldwerter Betrag eines elektronischen Münzdatensatzes durch eine oder mehrere Betragskategorie im Transaktionsdatensatz ersetzt, um einen betragskategorisierten Transaktionsdatensatz (=betragspseudonymer Transaktionsdatensatz) und/oder einen betragskategorisierten Registerdatensatz (=betragspseudonymer Registerdatensatz) zu erhalten. Eine Betragskategorie ist beispielsweise ein Betragsbereich (von-bis), in dem der geldwerte Betrag des Münzdatensatzes liegt. Eine Betragskategorie ist beispielsweise ein gerundeter Betragswert des geldwerten Betrags, entweder auf- oder abgerundet. Das Ablegen der empfangen verschlüsselten Transaktionsdatensätze ist in einer Ausgestaltung des Verfahrens davon unberührt.
  • In einer bevorzugten Ausgestaltung wird der pseudonymisierte oder betragskategorisierte Transaktionsdatensatz an ein Überwachungsregister des Bezahlsystems gesendet und dort abgelegt. Im Überwachungsregister können so anonymisierte oder pseudonymisierte Transaktionsdatensätze gespeichert werden, wodurch eine Überwachung der Transaktionen im laufenden Betrieb ermöglicht ist.
  • Ein pseudonymisierter Transaktionsdatensatz kann betragspseudonym und/oder identitätspseudonym sein. Ein anonymisierter Transaktionsdatensatz kann betragsanonym und/oder identitätsanonym sein.
  • In einer bevorzugten Ausgestaltung wird der pseudonymisierte Registerdatensatz an das Überwachungsregister des Bezahlsystems gesendet und dort abgelegt. Im Überwachungsregister können so anonymisierte oder pseudonymisierte Registerdatensätze gespeichert werden, wodurch eine Überwachung der Transaktionen im laufenden Betrieb ermöglicht wird.
  • Ein pseudonymisierter Registerdatensatz kann betragspseudonym und/oder identitätspseudonym sein. Ein anonymisierter Registerdatensatz kann betragsanonym und/oder identitätsanonym sein.
  • Mit dem Erstellen von pseudonymisierten oder anonymisierten Transaktions- oder Registerdatensätzen wird eine Anonymitätsstufe für den jeweiligen Transaktionsdatensatz geändert. Der pseudonymisierte oder anonymisierte Transaktions- oder Registerdatensatz weist immer eine höhere Anonymität auf als der (nicht-pseudonymisierte) Transaktions- oder Registerdatensatz. Mit dieser höheren Anonymitätsstufe kann der pseudonymisierte Transaktions- oder Registerdatensatz - in einer Vorgabe des Bezahlsystems - auch unverschlüsselt in den Registerinstanzen (Münzregister, Überwachungsregister, Transaktionsregister) abgelegt werden und für weitergehende Validitäts-Prüfungen im Bezahlsystem verwendet werden. Damit könnten Betrugsfälle oder Manipulationen im Bezahlsystem durch das Bezahlsystem selbst verbessert aufgedeckt werden, eine behördliche Anfrage (richterlicher Beschluss) ist dann ggf. nicht notwendig.
  • Eine Anonymitätsstufe eines Datensatzes spiegelt einen Grad an Anonymität des (Münz- oder Transaktions- oder Register-) Datensatzes, also eine Möglichkeit der Zuordnung einer konstanten Identität, wie Teilnehmerkennung, ID-Nummer, natürliche Person, etc., zu einem Datensatz. Bevorzugt wird zwischen mehreren Stufen, beispielsweise 3 Stufen, im Verfahren unterschieden: vollständig-anonym (Stufe 1), pseudonym (Stufe 2) oder nicht-anonym (Stufe 3). Ziel des Bezahlsystems ist es, geldwerte Beträge anonym zu übertragen (Stufe 1), d.h. einem Teilnehmer am Bezahlsystem soll es - in Anlehnung an analoges Bargeld - nicht möglich sein, ausgehend von einem empfangenen elektronischen Münzdatensatz auf die konstante Identität des Teilnehmers zu schließen. Für die Teilnahme von anonymen (nicht-vertrauenswürdigen) Teilnehmern und/oder für die Strafverfolgung ist es im Gegenzug aber wichtig, eine konstante Identität zu einem elektronischen Münzdatensatz zweifelsfrei zuordnen zu können. Deshalb sind die erzeugten Transaktions- oder Registerdatensätze nicht-anonym (Stufe 3), sie sind also eindeutig einer konstanten Identität zugeordnet, beispielsweise einer Teilnehmerkennung, die über eine Personenzuordnung zu einer natürlichen Person führen kann.
  • Eine Mischform aus den beiden Stufen 1 und 3 ist die Stufe 2, nämlich das Verwenden eines Pseudonyms (Stufe 2). Dies ist die temporäre oder dauerhafte Zuordnung einer abgeleiteten Identität zu einem Datensatz. Die Ableitung wird beispielsweise in einer vertrauenswürdigen Instanz, wie einem Überwachungsregister, generiert.
  • Eine Teilnehmerkennung im verschlüsselten Transaktions- oder Registerdatensatz weist bevorzugt eine Stufe 3 Anonymität auf, sodass ein (Entschlüsseln des) Transaktions- oder Registerdatensatz die konstante Teilnehmerkennung anzeigt.
  • Ein geldwerter Betrag im Transaktions- oder Registerdatensatz weist bevorzugt eine Stufe 3 Anonymität auf, sodass ein (Entschlüsseln des) Transaktions- oder Registerdatensatz den exakten Betrag anzeigt.
  • In einer bevorzugten Ausgestaltung ist die Anonymitätsstufe einer Teilnehmerkennung im Transaktions- oder Registerdatensatz von einer Anonymitätsstufe einer Betragskategorie verschieden, sodass Mischformen (unterschiedliche Abstufungen) in einem pseudonymisierten oder anonymisierten Transaktions- oder Registerdatensatz vorhanden sein können.
  • In einer bevorzugen Ausgestaltung weist ein Registerdatensatz eine von verschiedenen Anonymitätsstufen auf, wobei das Münzregister dazu eingerichtet ist, die Anonymitätsstufe des Registerdatensatzes vor dem Bereitstellen an das Überwachungsregister einzustellen.
  • In einer weiter bevorzugten Ausgestaltung weist ein Transaktionsdatensatz eine von verschiedenen Anonymitätsstufen auf, wobei die Transaktionsdatensatzquelle dazu eingerichtet ist, die Anonymitätsstufe des Transaktionsdatensatzes vor dem Bereitstellen an das Überwachungsregister einzustellen.
  • Bevorzugt wird zum Einstellen der Anonymitätsstufe eine Teilnehmerkennung einer Teilnehmereinheit pseudonymisiert oder anonymisiert (=identitätspseudonym oder identitätsanonym).
  • Bevorzugt wird zum Einstellen der Anonymitätsstufe ein geldwerter Betrag eines elektronischen Münzdatensatzes pseudonymisiert oder anonymisiert (=betragspseudonym oder betragsanonym).
  • Bevorzugt ist die Anonymitätsstufe eines geldwerten Betrags eines elektronischen Münzdatensatzes in einem Registerdatensatz zu der Anonymitätsstufe einer Teilnehmerkennung einer Teilnehmereinheit in dem Registerdatensatz verschieden.
  • Bevorzugt ist die Anonymitätsstufe eines geldwerten Betrags eines elektronischen Münzdatensatzes in einem Transaktionsdatensatz zu der Anonymitätsstufe einer Teilnehmerkennung einer Teilnehmereinheit in dem Transaktionsdatensatz verschieden.
  • Bevorzugt ist die Anonymitätsstufe eines geldwerten Betrags eines elektronischen Münzdatensatzes in einem Transaktionsdatensatz zu der Anonymitätsstufe eines geldwerten Betrags eines elektronischen Münzdatensatzes in einem (zum Transaktionsdatensatz korrespondierenden) Registerdatensatz verschieden.
  • Bevorzugt ist die Anonymitätsstufe einer Teilnehmerkennung einer Teilnehmereinheit in einem Transaktionsdatensatz verschieden zu der Anonymitätsstufe einer Teilnehmerkennung einer Teilnehmereinheit im (zum Transaktionsdatensatz korrespondierenden) Registerdatensatz.
  • Bevorzugt ist die Anonymitätsstufe eines Registerdatensatzes geringer als die Anonymitätsstufe eines (zum Registerdatensatz korrespondierenden) Transaktionsdatensatzes.
  • Bevorzugt wird das Einstellen der Anonymitätsstufe verändert, indem eine Kennung einer Teilnehmereinheit durch ein Pseudonym im Transaktionsdatensatz oder im (zum Transaktionsdatensatz korrespondierenden) Registerdatensatz ersetzt wird.
  • Bevorzugt wird das Einstellen der Anonymitätsstufe verändert, indem ein geldwerter Betrag eines elektronischen Münzdatensatzes durch eine Betragskategorie im Transaktionsdatensatz oder im (zum Transaktionsdatensatz korrespondierenden) Registerdatensatz ersetzt wird.
  • Mit dem Einstellen der Anonymitätsstufe im Bezahlsystem können unterschiedliche SystemVoraussetzungen erfüllt sein. Dabei kann eine Systemvoraussetzung sein, dass eine Übertragung betragsanonym sein muss, also ausgehend von den Transaktions- und Registerdatensätzen nicht auf den geldwerten Betrag des elektronischen Münzdatensatzes und/oder eine Teilnehmeridentität geschlossen werden soll.
  • Dabei kann eine andere Systemvoraussetzung sein, dass eine Übertragung identitätsanonym sein muss, also ausgehend von den Transaktions- und Registerdatensätzen nicht auf die (natürliche Person der) Teilnehmereinheit des elektronischen Münzdatensatzes und/oder eine Teilnehmeridentität geschlossen werden soll.
  • Das Einstellen der Anonymitätsstufe kann in Abhängigkeit eines Modus des Münzregisters erfolgen, sodass bei nicht-vertrauenswürdigen anonymen Teilnehmern (erster Modus) eine höhere Stufe an Anonymität für die Transaktionsdatensätze bzw. die Registerdatensätze einzustellen sind, um eine einfachere Nachverfolgbarkeit der Münzdatensätze zu ermöglichen.
  • Als eine geringe Stufe an Anonymität wird hierbei verstanden, dass der Datensatz vollständig anonym ist, also weder auf eine Teilnehmer(-kennung) noch auf einen Betrag geschlossen werden kann. Die höchste Stufe der Anonymität ist dabei das unverschleierte (für jeden einsehbare) Übertragen der Teilnehmeridentität (Kennung) und des Betrags des elektronischen Münzdatensatzes.
  • Die Aufgabe wird zudem durch eine Teilnehmereinheit in dem oben beschriebenen Bezahlsystem gelöst. Die Teilnehmereinheit ist bevorzugt ein Sicherheitselement. Die Teilnehmereinheit weist eine Recheneinheit auf, die zum Übertragen eines elektronischen Münzdatensatzes an eine andere Teilnehmereinheit eingerichtet ist. Zudem weist die Teilnehmereinheit Mittel zum Zugreifen auf einen Datenspeicher auf, wobei im Datenspeicher zumindest ein elektronischer Münzdatensatz abgelegt ist. die Teilnehmereinheit weist zudem eine Schnittstelle auf, die eingerichtet ist zum Senden von Status- und Registrierungsanforderungen betreffend die elektronischen Münzdatensätze oder die modifizierten elektronischen Münzdatensätze an das Münzregister.
  • In einer bevorzugten Ausgestaltung ist die Recheneinheit weiter eingerichtet zum Erzeugen eines Transaktionsdatensatzes betreffend die Übertragung des elektronischen Münzdatensatzes, wobei die Schnittstelle weiter zum Aufbau einer Kommunikationsverbindung zu einem Transaktionsregister als eine Transaktionsdatenquelle eingerichtet ist, um den erzeugten Transaktionsdatensatz an das Transaktionsregister zu senden.
  • Die Aufgabe wird zudem durch ein Münzregister in dem oben beschriebenen Bezahlsystem. Das Münzregister weist eine Recheneinheit auf, die eingerichtet ist zum Einstellen eines ersten Modus oder eines zweiten Modus des Münzregisters entsprechend eines Authentifizierungserfolgs einer Teilnehmereinheit am Münzregister. Zudem weist das Münzregister Mittel zum Zugreifen auf einen Münzspeicher auf, wobei im Münzspeicher elektronische Münzdatensätze registriert sind. Zudem weist das Münzregister eine Schnittstelle auf, die eingerichtet ist zum Bereitstellen von Registerdatensätzen in einem ersten Modus und zum Bereitstellen von Registerdatensätzen und Transaktionsdatensätzen in einem zweiten Modus für das Überwachungsregister.
  • Bevorzugt ist die Recheneinheit des Münzregisters dazu eingerichtet, eine Anonymitätsstufe eines Registerdatensatzes einzustellen.
  • Bevorzugt ist die Recheneinheit des Münzregisters dazu eingerichtet, Registerdatensätze zu erstellen. Ein Registerdatensatz weist bevorzugt einen maskierten elektronischen Münzdatensatz auf, der von einer Teilnehmereinheit oder einer Herausgeberinstanz bereitgestellt wird. Der Registerdatensatz ist sodann identitäts- und betragsanonym und hat eine sehr geringe Anonymitätsstufe. Ein Registerdatensatz weist (alternativ) bevorzugt einen maskierten elektronischen Münzdatensatz und eine Betragskategorie betreffend einen geldwerten Betrag eines elektronischen Münzdatensatzes korrespondierend zu dem maskierten elektronischen Münzdatensatz auf. Der Registerdatensatz ist sodann identitätsanonym und betragspseudonym und hat eine mittlere Anonymitätsstufe. Ein Registerdatensatz weist (alternativ) bevorzugt eine Münzkennung eines elektronischen Münzdatensatzes, einen Prüfwert des elektronischen Münzdatensatzes und ein Pseudonym der Teilnehmerkennung auf. Der Registerdatensatz ist sodann identitätspseudonym und betragsneutral und hat eine höhere mittlere Anonymitätsstufe. Der Prüfwert des Registerdatensatzes ist beispielsweise eine Signatur oder ein bekannter maskierter elektronischer Münzdatensatz, bspw. eine Vorgängerversion.
  • Bevorzugt ist die Schnittstelle oder eine weitere Schnittstelle des Münzregisters eingerichtet zum Erhalten von Status- und Registrierungsanforderungen betreffend die elektronischen Münzdatensätze oder die modifizierten elektronischen Münzdatensätze von der Teilnehmereinheit.
  • Bevorzugt weist das Münzregister einen Status-Verifikator auf, der eingerichtet ist zum Erstellen einer Statusmeldung bezüglich eines registrierten elektronischen Münzdatensatzes auf Basis einer Statusanforderung von der Teilnehmereinheit, wobei die Schnittstelle oder eine weitere Schnittstelle eingerichtet ist, den Statusbericht der Teilnehmereinheit bereitzustellen.
  • Bevorzugt weist das Münzregister einen Änderungs-Verifikator auf, der eingerichtet ist zum Ändern eines Eintrags im Münzregister bezüglich einer registrierten elektronischen Münzdatensatzes auf Basis einer Registeranforderung von der Teilnehmereinheit.
  • Bevorzugt ist die Schnittstelle oder eine weitere Schnittstelle des Münzregisters dazu eingerichtet, einen Nachweis bei der Teilnehmereinheit abzufragen, bevor die Änderung registriert im Münzregister registriert wird.
  • Bevorzugt ist die Schnittstelle oder eine weitere Schnittstelle eingerichtet zum Empfangen von Registerdatensätzen von erzeugten elektronischen Münzdatensätzen von einer Herausgeberinstanz des Bezahlsystems.
  • In einer bevorzugten Ausgestaltung ist im Münzregister ein Modul, bevorzugt ein Hardware Security Modul, eingerichtet zum Ersetzen von einer Teilnehmerkennung der Teilnehmereinheit durch ein Pseudonym der Teilnehmereinheit im Registerdatensatz, um einen pseudonymisierten Registerdatensatz zu erhalten. Zusätzlich oder alternativ ist das Modul eingerichtet zum Ersetzen von einem Pseudonym der Teilnehmereinheit durch eine Teilnehmerkennung der Teilnehmereinheit im Registerdatensatz, um einen identitätsoffenen Registerdatensatz zu erhalten. Zusätzlich oder alternativ ist das Modul eingerichtet zum Ersetzen eines geldwerten Betrags eines elektronischen Münzdatensatzes durch eine Betragskategorie im Registerdatensatz, um einen pseudonymisierten Registerdatensatz zu erhalten. Zusätzlich oder alternativ ist das Modul eingerichtet zum Ersetzen einer Betragskategorie des elektronischen Münzdatensatzes durch einen geldwerten Betrags des elektronischen Münzdatensatzes im Registerdatensatz, um einen betragsoffenen Registerdatensatz zu erhalten.
  • Die Aufgabe wird zudem durch ein Transaktionsregister für das oben beschriebene Bezahlsystem gelöst. Das Transaktionsregister weist Mittel zum Zugreifen auf einen Datenspeicher auf, wobei im Datenspeicher zumindest ein Transaktionsdatensatz abgelegt ist. Das Transaktionsregister weist zudem eine Schnittstelle auf, die eingerichtet ist zur Kommunikation mit einer Teilnehmereinheit, um einen Transaktionsdatensatz von der Teilnehmereinheit zu empfangen.
  • In einer bevorzugten Ausgestaltung ist im Transaktionsregister ein Modul, bevorzugt ein Hardware Security Modul, eingerichtet zum Ersetzen von einer Teilnehmerkennung der Teilnehmereinheit durch ein Pseudonym der Teilnehmereinheit im Transaktionsdatensatz, um einen pseudonymisierten Transaktionsdatensatz zu erhalten. Zusätzlich oder alternativ ist das Modul eingerichtet zum Ersetzen von einem Pseudonym der Teilnehmereinheit durch eine Teilnehmerkennung der Teilnehmereinheit im Transaktionsdatensatz, um einen identitätsoffenen Transaktionsdatensatz zu erhalten. Zusätzlich oder alternativ ist das Modul eingerichtet zum Ersetzen eines geldwerten Betrags eines elektronischen Münzdatensatzes durch eine Betragskategorie im Transaktionsdatensatz, um einen pseudonymisierten Transaktionsdatensatz zu erhalten. Zusätzlich oder alternativ ist das Modul eingerichtet zum Ersetzen einer Betragskategorie des elektronischen Münzdatensatzes im Transaktionsdatensatz durch einen geldwerten Betrags des elektronischen Münzdatensatzes, um einen betragsoffenen Transaktionsdatensatz zu erhalten.
  • Bevorzugt ist die Schnittstelle oder eine weitere Schnittstelle des Transaktionsregisters eingerichtet zum Senden eines Transaktionsdatensatzes an das Überwachungsregister des Bezahlsystems. In einer Ausgestaltung ist der Transaktionsdatensatz entweder anonymisiert oder pseudonymisiert oder er entspricht dem Transaktionsdatensatz, so wie er von der Teilnehmereinheit bereitgestellt wurde, bevorzugt in entschlüsselter Form.
  • Bevorzugt ist die Schnittstelle oder eine weitere Schnittstelle des Transaktionsregisters eingerichtet ist zum Empfangen einer Teilnehmerkennung oder eines Pseudonyms der Teilnehmerkennung von einem Personenregister des Bezahlsystems.
  • In einer bevorzugten Ausgestaltung weist das Transaktionsregister weiter auf: ein Hardware Security Modul, eingerichtet zum sicheren Aufbewahren von Teilschlüsseln unterschiedlicher Generationen; und Entschlüsseln von verschlüsselten Transaktionsdatensätzen.
  • In einer bevorzugten Ausgestaltung ist das HSM des Transaktionsregister eingerichtet zum Entschlüsseln von verschlüsselten Transaktionsdatensätzen; Ersetzen von einer Kennung einer Teilnehmereinheit durch ein Pseudonym im Transaktionsdatensatz, um einen entschlüsselten pseudonymisierten Transaktionsdatensatz zu erhalten.
  • In einer bevorzugten Ausgestaltung ist das HSM des Transaktionsregister eingerichtet zum Entschlüsseln von verschlüsselten Transaktionsdatensätzen und zum Ersetzen eines geldwerten Betrags eines elektronischen Münzdatensatzes durch eine Betragskategorie im Transaktionsdatensatz, um einen entschlüsselten betragskategorisierten Transaktionsdatensatz zu erhalten.
  • In einer bevorzugten Ausgestaltung ist die Schnittstelle eingerichtet zum Senden des entschlüsselten pseudonymisierten oder des entschlüsselten betragskategorisierten Transaktionsdatensatzes an ein Überwachungsregister des Bezahlsystems.
  • Die Aufgabe wird zudem durch ein Überwachungsregister in einem zuvor beschriebenen Bezahlsystem gelöst, wobei das Überwachungsregister eine Schnittstelle zum Empfangen von Transaktionsdatensätzen und/oder Registerdatensätzen von dem Münzregister aufweist, wobei die Schnittstelle oder eine weitere Schnittstelle weiter eingerichtet ist zum Empfangen von Transaktionsdatensätzen von einer Transaktionsdatenquelle aufweist. Das Überwachungsregister weist zudem eine Recheneinheit auf, die eingerichtet ist zum Bilden von Überwachungsdatensätzen aus den empfangenen Transaktionsdatensätzen und Registerdatensätzen und die weiter eingerichtet ist zum Auswerten der gebildeten Überwachungsdatensätze.
  • Die Aufgabe wird zudem durch ein Verfahren zum Bezahlen mit elektronischen Münzdatensätzen in einem hierin beschriebenen Bezahlsystem gelöst. Das Verfahren umfasst die Verfahrensschritte: Registrieren der elektronischen Münzdatensätze in einem Münzregister des Bezahlsystems; Ausführen von Bezahltransaktionen durch Übertragen der elektronischen Münzdatensätze durch Teilnehmereinheiten des Bezahlsystems; Senden von Status- und/oder Registrierungsanforderungen betreffend die elektronischen Münzdatensätze durch die Teilnehmereinheiten des Bezahlsystems; Auswerten von Überwachungsdatensätzen betreffend die Bezahltransaktionen durch ein Überwachungsregister des Bezahlsystems, wobei ein Überwachungsdatensatz im Überwachungsregister aus zumindest einem Registerdatensatz und zumindest einem Transaktionsdatensatz gebildet wird, wobei der zumindest eine Registerdatensatz von dem Münzregister bereitgestellt wird und wobei der zumindest eine Transaktionsdatensatz von einer Transaktionsdatensatzquelle und/oder dem Münzregister bereitgestellt wird.
  • In einer bevorzugten Ausgestaltung weist das Bezahlsystem weiter auf eine Herausgeberinstanz auf, die ausgebildet ist, einen elektronischen Münzdatensatzes für das Bezahlsystem zu erstellen.
  • In einer bevorzugten Ausgestaltung wird im jeweiligen Verfahren jedem elektronischen Münzdatensatz ein entsprechender maskierter elektronischer Münzdatensatz zugeordnet. Die Kenntnis eines maskierten elektronischen Münzdatensatzes berechtigt nicht dazu, das digitale Geld, das durch den elektronischen Münzdatensatz repräsentiert wird, auszugeben. Dies stellt einen wesentlichen Unterschied zwischen den maskierten elektronischen Münzdatensätzen und den (nicht maskierten) elektronischen Münzdatensätzen dar. Ein maskierter elektronischer Münzdatensatz ist einzigartig und zudem eindeutig einem elektronischen Münzdatensatz zuzuordnen, es gibt also eine 1-zu-1 Beziehung zwischen einem maskierten elektronischen Münzdatensatz und einem (nicht-maskierten) elektronischen Münzdatensatz. Das Maskieren des elektronischen Münzdatensatzes erfolgt bevorzugt durch eine Recheneinheit der Teilnehmereinheit. Die Teilnehmereinheit weist zumindest einen elektronischen Münzdatensatz auf. Alternativ kann das Maskieren durch eine Recheneinheit einer den elektronischen Münzdatensatz empfangende Teilnehmereinheit erfolgen.
  • Dieser maskierte elektronische Münzdatensatz wird durch Anwenden einer homomorphen Einwegfunktion, insbesondere einer homomorphen kryptographischen Funktion, erhalten. Diese Funktion ist eine Einwegfunktion, also eine mathematische Funktion, die komplexitätstheoretisch „leicht“ berechenbar, aber „schwer“ bis praktisch unmöglich umzukehren ist. Hierbei wird unter Einwegfunktion auch eine Funktion bezeichnet, zu der bislang keine in angemessener Zeit und mit vertretbarem Aufwand praktisch ausführbare Umkehrung bekannt ist. Somit ist die Berechnung eines maskierten elektronischen Münzdatensatzes aus einem elektronischen Münzdatensatz vergleichbar mit der Generierung eines öffentlichen Schlüssels in einem Verschlüsselungsverfahren über eine Restklassengruppe. Vorzugsweise wird eine Einwegfunktion verwendet, die auf eine Gruppe operiert, in der das diskrete Logarithmusproblem schwer zu lösen ist, wie z. B. ein kryptographisches Verfahren analog einer elliptischer-Kurve-Verschlüsselung, kurz ECC, aus einem privaten Schlüssel eines entsprechenden Kryptographie-Verfahrens. Die umgekehrte Funktion, also die Erzeugung eines elektronischen Münzdatensatzes aus einem maskierten elektronischen Münzdatensatz, ist dabei - äquivalent zur Erzeugung des privaten Schlüssels aus einem öffentlichen Schlüssel in einem Verschlüsselungsverfahren über einer Restklassengruppe - sehr zeitintensiv. Wenn im vorliegenden Dokument von Summen und Differenzen oder anderen mathematischen Operationen die Rede ist, dann sind dabei im mathematischen Sinn die jeweiligen Operationen auf der entsprechenden mathematischen Gruppe zu verstehen, beispielsweise der Gruppe der Punkte auf einer elliptischen Kurve.
  • Die Einwegfunktion ist homomorph, also ein kryptographisches Verfahren, welches über Homomorphie-Eigenschaften verfügt. Somit können mit dem maskierten elektronischen Münzdatensatz mathematische Operationen durchgeführt werden, die parallel dazu auch auf dem (nicht maskierten) elektronischen Münzdatensatz durchgeführt und somit nachvollzogen werden können. Mit Hilfe der homomorphen Einwegfunktion können Berechnungen mit maskierten elektronischen Münzdatensätzen in dem Münzregister und/oder dem Überwachungsregister nachvollzogen werden, ohne dass die entsprechenden (nicht maskierten) elektronischen Münzdatensätze dort bekannt sind. Daher können bestimmte Berechnungen mit elektronischen Münzdatensätzen, beispielsweise für ein Verarbeiten des (nicht maskierten) elektronischen Münzdatensatzes (zum Beispiel Aufteilen oder Verbinden), auch parallel mit den dazugehörigen maskierten elektronischen Münzdatensätzen im Münzregister nachgewiesen werden, beispielsweise zu Validierungsprüfungen (=Gültigkeiten). Zudem kann parallel die Überwachung über die Rechtmäßigkeit des jeweiligen elektronischen Münzdatensatzes im Überwachungsregister nachgewiesen werden. Die Homomorphie-Eigenschaften treffen zumindest auf Additions- und Subtraktionsoperationen zu, sodass ein Umschalten (=Switch), Aufteilen (=Split) oder Kombinieren (=Verbinden) von elektronischen Münzdatensätzen auch mittels der entsprechend maskierten elektronischen Münzdatensätze im Münzregister bzw. der Prüfung, ob der elektronische Münzdatensatz zurückzugeben (löschen) oder Umzumünzen ist im Überwachungsregister festgehalten und von anfragenden Teilnehmereinheiten bzw. deren Sicherheitselementen und/oder von dem Münzregister und/oder von dem Überwachungsregister nachvollzogen werden kann, ohne Kenntnis über den monetären Betrag und die durchführende Teilnehmereinheit zu erlangen.
  • Die Homomorphie-Eigenschaft ermöglicht es also, eine Eintragung von gültigen und ungültigen elektronischen Münzdatensätzen auf Basis ihrer maskierten elektronischen Münzdatensätze in einem Münzregister und einem Überwachungsregister zu führen, ohne Kenntnis der elektronischen Münzdatensätze, auch wenn diese elektronische Münzdatensätze verarbeitet (aufgeteilt, verbunden, umschalten) oder direkt übertragen werden, also eine Aktion mit diesen elektronischen Münzdatensätzen durchgeführt wird. Dabei wird stets sichergestellt, dass kein zusätzlicher monetärer Betrag geschaffen wurde oder dass eine Identität der Teilnehmereinheiten bzw. deren Sicherheitselementen in dem Münzregister oder dem Überwachungsregister festgehalten wird. Das Maskieren ermöglicht ein hohes Maß an Sicherheit, ohne einen Einblick in den monetären Betrag oder die Teilnehmereinheit zu geben.
  • Beim direkten Übertragen eines elektronischen Münzdatensatzes von der ersten Teilnehmereinheit an eine zweite Teilnehmereinheit haben zwei Teilnehmereinheiten gleichzeitig Kenntnis über den zu übertragenden elektronischen Münzdatensatz. Es gilt zu verhindern, dass die sendende erste Teilnehmereinheit den elektronischen Münzdatensatz bei einer anderen (dritten) Teilnehmereinheit ebenfalls zum Bezahlen verwendet (sogenanntes Double-Spending). Dabei kann vor dem Übertragen ein Status des elektronischen Münzdatensatzes auf Inaktiv-Status gesetzt, um den elektronischen Münzdatensatz zu invalidieren, dann erfolgt das Senden (als erster Schritt des Übertragens) an die zweite Teilnehmereinheit und bei Vorhandensein einer Empfangsbestätigung von der zweiten Teilnehmereinheit erfolgt ein Löschen des elektronischen Münzdatensatzes in der ersten Teilnehmereinheit (als zweiter Schritt des Übertragens). Eine Löschungsbestätigung von der ersten Teilnehmereinheit kann an das Münzregister oder die zweite Teilnehmereinheit gesendet werden, um ein erfolgreiches Löschen (durchgeführt in der ersten Teilnehmereinheit) des elektronischen Münzdatensatzes anzuzeigen.
  • Zudem kann der übertragene elektronische Münzdatensatz von der ersten Teilnehmereinheit an eine zweite Teilnehmereinheit umgeschaltet (=switch) werden. Das Umschalten kann bevorzugt automatisch beim Empfangen der Löschungsbestätigung eines elektronischen Münzdatensatzes in der zweiten Teilnehmereinheit erfolgen. Zusätzlich kann es auch auf Anforderung, beispielsweise eines Befehls von der ersten Teilnehmereinheit und/oder der zweiten Teilnehmereinheit erfolgen. Zusätzlich kann ein elektronischer Münzdatensatz auch in zumindest zwei elektronische Münzteildatensätze aufgeteilt werden (=split). Zusätzlich können zwei elektronische Münzdatensätze zu einem elektronischen Münzdatensatz verbunden werden („Merge“).
  • Das Umschalten, das Aufteilen und das Verbinden sind verschiedene Modifikation an einem elektronischen Münzdatensatz, also Aktionen mit dem elektronischen Münzdatensatz. Diese Modifikationen bedingen ein Registrieren des maskierten Münzdatensatzes im Münzregister des Bezahlsystems. Das konkrete Durchführen der einzelnen Modifikationen wird später erläutert.
  • Ein Umschalten erfolgt zudem, wenn ein elektronischer Münzdatensatz verändert, beispielsweise aufgeteilt oder mit anderen elektronischen Münzdatensätzen verbunden wurde, insbesondere um einen zu zahlenden monetären Betrag passend begleichen zu können. Dabei sollte das Bezahlsystem stets in der Lage sein, jeden monetären Betrag zu zahlen.
  • Nachstehend wird dieses Pseudonymisieren näher erläutert: Das Übertragen von elektronischen Münzdatensätzen im Bezahlsystem ist anonym soweit die Anonymität nicht explizit durch zusätzliche Maßnahmen aufgehoben werden soll. Es könnte eine Forderung im Bezahlsystem sein, die Anonymität in Abhängigkeit eines Werts für monetäre Beträge aufzuheben. Mit anderen Worten: Eine typische Anforderung im Bezahlsystem könnte sein, monetäre Beträge, unterhalb eines bestimmten Grenzwerts anonym zu senden. Wird dieser Grenzwert überschritten, erfolgt die Übertragung im System deanonymisiert.
  • In einer bevorzugten Ausgestaltung ist das Bezahlsystem eingerichtet, die weiteren Schritte auszuführen: Maskieren des elektronischen Münzdatensatzes durch Anwenden einer homomorphen Einwegfunktion auf den elektronischen Münzdatensatz zum Erhalten eines maskierten elektronischen Münzdatensatzes; Verknüpfen des maskierten elektronischen Münzdatensatzes mit einem Pseudonym zum Erhalten eines pseudonymisierten maskierten elektronischen Münzdatensatzes; und Senden des pseudonymisierten maskierten elektronischen Münzdatensatzes an ein Münzregister und/oder ein Überwachungsregister des Bezahlsystems. Damit werden Modifikationen am elektronischen Münzdatensatz in dem Münzregister nachgehalten und in der Überwachungsregister unter einem Pseudonym dokumentiert, ohne dass eine Anonymität im Bezahlsystem aufgehoben ist. Das Überwachungsregister kann somit auch bei Kenntnis der Zugehörigkeit von Pseudonym und Teilnehmereinheit die bei der Teilnehmereinheit ausgehenden Transaktionen identifizieren.
  • Im oben erwähnten erfindungsgemäßen Verfahren wird der pseudonymisierter maskierter elektronischer Münzdatensatz bevorzugt im Erzeugen-Schritt durch die erste Teilnehmereinheit, weiter bevorzugt anstelle des maskierten elektronischen Münzdatensatzes, mit in den Transaktionsdatensatz eingebracht und bevorzugt in verschlüsselter Form an das Transaktionsregister gesendet. Eine spätere Entschlüsselung deckt dann auch das Pseudonym auf, unter dem die Transkation stattgefunden hat.
  • Dies stellt eine Alternative zu dem oben beschriebenen Bereitstellen der pseudonymisierten Transaktionsdaten des Transaktionsregister dar und könnte parallel oder zusätzlich im Münzregister oder auch im Überwachungsregister eingesetzt sein. Die Auswahl des jeweiligen Pseudonymisierens kann im Bezahlsystem flexibel eingestellt und an die tatsächlichen Anforderungen des Bezahlsystems angepasst werden, beispielsweise an die Rechenleistung des Transaktionsregisters oder des Münzregisters oder des Überwachungsregisters oder eine Übertragungskapazität im Bezahlsystem. Die Auswahl kann eine Bezahlsystemvorgabe sein.
  • Da eine digitale Bezahltransaktion (das Übertragung von elektronischen Münzdatensätzen) eines großen geldwerten Betrags auch in mehrere digitale Bezahltransaktionen kleinerer geldwerter Beträge aufgeteilt werden könnte, die jeweils unterhalb des Grenzwertes liegen können, muss der Grenzwert teilnehmereinheitenspezifisch und/oder zeitraumabhängig sein. Aufgrund der intransparenten vielfachen (direkten) Übertragung eines Münzdatensatzes zwischen einer Vielzahl von verschiedenen Teilnehmereinheiten, ist diese Forderung nach einer Deanonymisierung, auch Re-Identifikation genannt, zudem nicht auf einzelne Übertragungen (Transaktionen) zwischen zwei Teilnehmereinheiten gerichtet, sondern betrifft in der Regel die Summe aller Transaktionen innerhalb einer bestimmten Zeiteinheit (Zeitdauer), die von einer Teilnehmereinheit empfangen und/oder gesendet werden. Es wird daher ein Mechanismus bereitgestellt, mit dem festgestellt werden kann, wie hoch die Summe aller monetären Beträge, die von einer Teilnehmereinheit gesendet oder empfangen wurden, innerhalb einer bestimmten Zeiteinheit ist. Dazu wird ein Verfahren beschrieben, das die Aufhebung der Anonymität einer sendenden Teilnehmereinheit bei Überschreitung eines Grenzwertes pro Zeiteinheit ermöglicht.
  • Um einen solchen Mechanismus zur Deanonymisierung zu ermöglichen, wird in einer bevorzugten Ausgestaltung das Pseudonymisieren oder gar Anonymisieren durchgeführt. Dazu wird vor dem Maskieren-Schritt ein Verknüpfen-Schritt durchgeführt, um ein Pseudonym der ersten Teilnehmereinheit mit dem elektronischen Münzdatensatz zu verknüpfen. Das Pseudonym ist bevorzugt teilnehmereinheitenspezifisch.
  • Allgemein für dieses System gilt: Ein Pseudonym ist jegliche Art von verschleierter Identität, die es ermöglicht, dass nicht in bloßer Kenntnis des elektronischen Münzdatensatzes direkt auf die Teilnehmereinheit und die damit durchgeführten Transaktionen zurückgeschlossen werden kann. Das Pseudonym ist beispielsweise temporär und kann durch ein anderes Pseudonym ersetzt werden. Es verschleiert die konstante Identität (Teilnehmerkennung) eines Teilnehmers am Bezahlsystem. Eine Zuordnung zwischen Pseudonym und konstanter Teilnehmerkennung ist beispielsweise im System in einer gesicherten Umgebung, wie einem Personenregister, hinterlegt und kann entsprechend nachgeprüft werden.
  • Ein anonymer Datensatz ist im Gegensatz dazu nicht mit einer Teilnehmerkennung versehen oder die Teilnehmerkennung ist frei wählbar und im Bezahlsystem nicht zu einer natürlichen Person zugeordnet.
  • Die Teilnehmereinheit muss für jeden empfangenen Münzdatensatz eine Modifikation (Aufteilen, Umschalten, Verbinden) durchführen können, um das Pseudonym mit dem Münzdatensatz zu verknüpfen. Das mit jeder Modifikation (für das Validieren der Modifikation) einhergehende Registrieren in dem Münzregister ist ausreichend, um alle Münzdatensatz-Transaktionen, die mit der Teilnehmereinheit durchgeführt wurden, aufgrund des verknüpften Pseudonyms eindeutig dieser Teilnehmereinheit zuordnen zu können. Ein Überwachungsregister kann bei Kenntnis der Zugehörigkeit von Pseudonym und Teilnehmereinheit die bei der Teilnehmereinheit eingehenden Transaktionen identifizieren.
  • Somit werden Modifikationen des elektronischen Münzdatensatzes mit einem auf der Teilnehmereinheit gespeicherten Pseudonym verknüpft. Dieses Pseudonym kann entweder dauerhaft oder nur für einen bestimmten Zeitraum gültig sein.
  • Der Unterschied zwischen einem anonymen maskierten elektronischen Münzdatensatz und einem pseudonymisierten maskierten elektronischen Münzdatensatz liegt also in der Identifizierbarkeit der Teilnehmereinheit durch das Überwachungsregister, wenn es das Pseudonym verwendet. Ein anonymer maskierter elektronischer Münzdatensatz enthält keinerlei Information über seine Herkunft, kann also nicht mit einer Teilnehmereinheit in Verbindung gebracht werden. Dementgegen hat ein pseudonymisierter maskierter elektronischer Münzdatensatz eine Verknüpfung mit einem Pseudonym der Teilnehmereinheit, so dass die Teilnehmereinheit, was den pseudonymisierten maskierten elektronischen Münzdatensatz an das Überwachungsregister versendet hat, über das verknüpfte Pseudonym identifiziert werden kann.
  • Der beschriebene Mechanismus ist ausreichend, um zu bestimmen, ob die Summe der monetären Beträge aller Transaktionen einer Teilnehmereinheit unterhalb eines Grenzwertes, bevorzugt innerhalb einer bestimmten Zeiteinheit, liegen. Wird erkannt, dass der Grenzwert durch eine gewünschte Modifikation überschritten wird, könnte das Münzregister oder das Überwachungsregister eine derartige Modifikation prompt unterbinden, indem es die Registrierung des entsprechenden elektronischen Münzdatensatzes in dem Münzregister blockiert bzw. ablehnt. Alternativ oder zusätzlich könnte die Teilnehmereinheit informiert werden, dass die Modifikation (und damit die Transkation) nur durchgeführt würde, wenn die Teilnehmereinheit sich deanonymisiert, also beispielsweise persönliche Zugangsdaten offenlegt, bevor die Modifikation registriert und der elektronische Münzdatensatz auf gültig gesetzt wird, wodurch die Transaktion akzeptiert würde.
  • In einer bevorzugten Ausgestaltung des Pseudonymisierens wird durch das Senden des pseudonymisierten maskierten elektronischen Münzdatensatzes anstelle eines anonymen maskierten elektronischen Münzdatensatzes die Anzahl von Bereichsbestätigungen oder Bereichsnachweisen, welche das Überwachungsregister von der ersten Teilnehmereinheit anfordert, reduziert.
  • Das Überwachungsregister, das Münzregister, das Transaktionsregister und/oder die Teilnehmereinheiten können die maskierten elektronischen Münzdatensätze in einem anonymen oder in einem pseudonymen Modus verarbeiten. Das Überwachungsregister fordert in einem anonymen Modus notwendige und weitere (nachholbare) Bereichsnachweise oder Bereichsbestätigungen an. Im pseudonymen Modus fordert das Überwachungsregister zumindest eine der weiteren Bereichsnachweise oder Bereichsbestätigungen nicht an, prüft jedoch für das Pseudonym ob ein (Nachhol-)Kriterium erfüllt ist. Ein elektronischer Münzdatensatz kann bereits als gültig behandelt werden, wenn die notwendigen Prüfungen erfolgt sind. Erst wenn das (Nachhol-)Kriterium erfüllt ist, werden Bereichsnachweise oder ein Summenbereichsnachweis (bzw. -bestätigung) von der Teilnehmereinheit angefordert. Als (Nachhol-)Kriterien können beispielsweise für das Pseudonym ein Zeitraum oder eine Anzahl maskierter elektronischer Münzdatensätze verwendet werden.
  • In einer weiter bevorzugten Ausgestaltung des Pseudonymisierens empfängt die erste (sendende) Teilnehmereinheit eine Anforderung für eine Summenbereichsbestätigung oder eines Summenbereichsnachweises von dem Überwachungsregister, und sendet die angeforderte Summenbereichsbestätigung oder den angeforderten Summenbereichsnachweis an das Überwachungsregister.
  • In einer alternativen Ausgestaltung erstellt die erste Teilnehmereinheit eine unaufgeforderte Summenbereichsbestätigung oder einen unaufgeforderten Summenbereichsnachweis, und sendet die unaufgeforderte Summenbereichsbestätigung oder den angeforderten Summenbereichsnachweises an das Überwachungsregister.
  • Eine Summenbereichsbestätigung bzw. ein Summenbereichsnachweis ist dabei eine Angabe der Teilnehmereinheit über eine Summe von monetären Beträgen einer Mehrzahl von elektronischen Münzdatensätzen, bevorzugt direkt zwischen Teilnehmereinheiten übertragenen elektronischen Münzdatensätzen. Diese Summenangabe wird in dem Überwachungsregister mit einer Bereichsangabe abgeglichen. Bei Überschreitung der Bereichsangabe erfolgt ein Deanonymisieren der elektronischen Münzdatensätze, um das Übertragen großer monetärer Beträge abzusichern bzw. kontrollieren zu können.
  • Bevorzugt bildet die erste Teilnehmereinheit dazu eine Summe aus monetären Beträgen mehrerer elektronischer Münzdatensätze bestätigt mit der Summenbereichsbestätigung, dass die gebildete Summe in einem Bereich liegt. Die Summenbereichsbestätigung wird in dem Überwachungsregister als eine Anzeige der Teilnehmereinheit verstanden und die Teilnehmereinheit wird als vertrauenswürdig eingestuft.
  • In einer alternativen Ausgestaltung des Pseudonymisierens erstellt die Teilnehmereinheit für mehrere elektronische Münzdatensätze einen durch das Überwachungsregister überprüfbaren Summenbereichsnachweis. Der Summenbereich wird dann also von dem Überwachungsregister geprüft und dort erfolgt die Bestätigung, dass die Summe im Bereich liegt (oder nicht). Der Summenbereichsnachweis ist bevorzugt auch Teil des Transaktionsdatensatzes für das Transaktionsregister.
  • In einer bevorzugten Ausgestaltung des Pseudonymisierens umfassen die mehreren elektronischen Münzdatensätze nur ausgewählte elektronische Münzdatensätze. Somit wird die Summenbereichsbestätigung bzw. der Summenbereichsnachweis nicht für alle elektronische Münzdatensätze der Teilnehmereinheiten durchgeführt, sondern nur für eine gezielte Auswahl. Die Auswahl betrifft in einer Ausgestaltung nur elektronische Münzdatensätze von gesendeten pseudonymisierten maskierten elektronischen Münzdatensätzen. In einer alternativen Ausgestaltung des Pseudonymisierens sind nur elektronische Münzdatensätze von gesendeten anonymen maskierten elektronischen Münzdatensätzen oder gesendeten pseudonymisierten maskierten elektronischen Münzdatensätzen betroffen. In einer alternativen Ausgestaltung des Pseudonymisierens sind nur elektronische Münzdatensätze von gesendeten anonymen maskierten elektronischen Münzdatensätzen, gesendeten pseudonymisierten maskierten elektronischen Münzdatensätzen und/oder nicht an das Überwachungsregister gesendeten maskierten elektronischen Münzdatensätzen betroffen. In einer bevorzugten Ausgestaltung des Pseudonymisierens werden die mehreren elektronischen Münzdatensätze nach einem vorausgewählten Zeitraum als Auswahlkriterium ausgewählt. Als Zeitraum kann ein Tag, eine Woche oder auch ein viel geringerer Zeitraum ausgewählt werden.
  • Diese Auswahl wird bevorzugt maskiert und dann als Teil des Transaktionsdatensatzes dem Transaktionsregister in verschlüsselter Form gesendet.
  • In einer alternativen oder zusätzlichen Ausgestaltung des Pseudonymisierens ist als Auswahlkriterium eine Liste in der ersten Teilnehmereinheit oder dem Überwachungsregister zu verwenden, anhand derer Liste die elektronischen Münzdatensätze ausgewählt werden.
  • Diese Liste wird bevorzugt maskiert und dann als Teil des Transaktionsdatensatzes dem Transaktionsregister in verschlüsselter Form gesendet.
  • In einer bevorzugten Ausgestaltung des Pseudonymisierens fordert das Überwachungsregister im Rahmen einer Summenprüfung Bereichsbestätigungen oder Bereichsnachweise von Teilnehmereinheiten an. Vorzugsweise wendet das Überwachungsregister für anonyme maskierte elektronische Münzdatensatze einen ersten Summenprüfmodus an. Vorzugsweise wendet das Überwachungsregister für pseudonymisierte maskierte elektronische Münzdatensätze einen zweiten Summenprüfmodus an.
  • In einer bevorzugten Ausgestaltung des Pseudonymisierens prüft das Überwachungsregister für jeden empfangenen modifizierten elektronischen Münzdatensatz einen Bereichsnachweis.
  • In einer bevorzugten Ausgestaltung des Pseudonymisierens fordert das Überwachungsregister regelmäßig oder quasizufällig Bereichsbestätigungen oder Bereichsnachweise von Teilnehmereinheiten an. Dies erfolgt beispielsweise in dem ersten Summenprüfmodus.
  • In einer alternativen oder zusätzlichen Ausgestaltung des Pseudonymisierens fordert das Überwachungsregister erst ab einer Anzahl von für ein Pseudonym empfangenen Münzdatensätzen von der Teilnehmereinheit eine Bereichsbestätigung oder einen Bereichsnachweis an. Dies erfolgt beispielsweise in dem zweiten Summenprüfmodus. Diese Anzahl ist bevorzugt abhängig vom Teilnehmereinheitentyp und/oder vom Münzbetragsbereich. Damit können die Bereichsnachweise bzw. Bereichsbestätigungen flexibel auf eine bestimmte Nutzersituation abgestimmt werden und erhöhen so die Sicherheit des Bezahlsystems.
  • Ausreichend ist prinzipiell das Identifizieren der ausgehenden Transaktionen oder der eingehenden Transaktionen, sodass in einer Ausgestaltung das Maskieren des elektronischen Münzdatensatzes und Verknüpfen des maskierten elektronischen Münzdatensatzes in der zweiten Teilnehmereinheit mit einem Pseudonym der zweiten Teilnehmereinheit in der zweiten Teilnehmereinheit und Senden des pseudonymisierten maskierten elektronischen Münzdatensatzes an das Überwachungsregister nicht durchgeführt wird.
  • Diese identifizierten ausgehenden Transaktionen werden bevorzugt als Teil des Transaktionsdatensatzes dem Transaktionsregister in verschlüsselter Form gesendet.
  • Der Verknüpfen-Schritt des Pseudonymisierens wird bevorzugt durch ein Signieren des jeweiligen maskierten elektronischen Münzdatensatzes in der zweiten Teilnehmereinheit mit einem privaten Signaturschlüssel der zweiten Teilnehmereinheit zum Erhalten eines signierten maskierten elektronischen Münzdatensatzes als pseudonymisierter maskierter elektronischer Münzdatensatz oder als pseudonymisierter maskierter übertragener elektronischer Münzdatensatz durchgeführt.
  • Das Signieren erfolgt mit einem privaten Signaturschlüssel der Teilnehmereinheit. Dieser Signaturschlüssel ist bevorzugt teilnehmereinheitenspezifisch, d.h. in Kenntnis des Verifikationsschlüssels kann nachvollzogen werden, wer den Münzdatensatz zuletzt modifiziert (umgeschaltet, aufgeteilt, verbunden) hat. Der signierte maskierte elektronische Münzdatensatz wird in dem Überwachungsregister registriert.
  • Im oben erwähnten erfindungsgemäßen Verfahren wird der signierte maskierte elektronische Münzdatensatz bevorzugt im Erzeugen-Schritt durch die erste Teilnehmereinheit, weiter bevorzugt anstelle des maskierten elektronischen Münzdatensatzes, mit in den Transaktionsdatensatz eingebracht und somit in verschlüsselter Form an das Transaktionsregister gesendet. Eine spätere Entschlüsselung deckt dann auch die Signatur auf, unter der die Transkation stattgefunden hat.
  • Zum Erzeugen einer Signatur wird demnach bevorzugt ein asymmetrisches Kryptosystem, bei dem die Teilnehmereinheit mit Hilfe eines geheimen Signaturschlüssels, hier als privater Signaturschlüssel oder „Private Key“ bezeichnet, zu einem Datensatz einen Wert berechnet. Dieser Wert ermöglicht es jedem, mit Hilfe eines öffentlichen Verifikationsschlüssels, dem „Public Key“, die Urheberschaft und Integrität des Datensatzes zu prüfen.
  • Bevorzugt wird mit dem Schritt des Registrierens eine Prüfung der Signatur in der Überwachungsregister erfolgen, wobei das Überwachungsregister dazu den öffentlichen Verifikationsschlüssel der Signatur aufweist. Die Signatur kann nun von dem Überwachungsregister geprüft werden, indem ein öffentlicher Verifikationsschlüssel der Signatur dort bekannt ist.
  • Der öffentliche Verifikationsschlüssel zum Prüfen der Signatur ist bevorzugt nur dem Überwachungsregister bekannt, wodurch das Verfahren für die Teilnehmereinheiten untereinander weiterhin anonym bleibt.
  • Bevorzugt registriert das Münzregister jegliches Modifizieren, also das Umschalten, Aufteilen und/oder Verbinden zusammen mit der Signatur der Teilnehmereinheit. Auf diese Weise kann eine Überwachung und Bestimmung der Summe von monetären Beträgen für alle Transaktionen einer Teilnehmereinheit durch das Münzregister und/oder das Überwachungsregister erfolgen. Die Signatur ist beispielsweise ein Teil des Transaktionsdatensatzes und wird entweder in verschlüsselter Form oder auch im Klartext an das Transaktionsregister gesendet und dort abgelegt (archiviert).
  • Bevorzugt ist die Signatur innerhalb einer bestimmten Zeiteinheit gültig, wobei die bestimmte Zeiteinheit bevorzugt ein Tag ist. Somit kann für diese bestimmte Zeiteinheit das Transaktionsvolumen (=Summe der monetären Beträge bei Transaktionen) pro Teilnehmereinheit geprüft werden.
  • Jede Teilnehmereinheit hat demnach ein asymmetrisches Schlüsselpaar, um jede Modifikation mit dem privaten Signaturschlüssel zu signieren. Der öffentliche Schlüssel ist dem Überwachungsregister (und auch dem Münzregister) bekannt. Somit kann das Überwachungsregister jede Transaktion mit der Teilnehmereinheit als Absender oder Empfänger des Münzdatensatzes verknüpfen.
  • Der beschriebene Mechanismus ist ausreichend, um zu erfassen (messen), ob die Summe aller monetären Beträge pro Teilnehmereinheit (=Transaktionen) innerhalb eines Grenzwertes pro Zeiteinheit, beispielsweise einem Tagesgrenzwert, liegt.
  • Nachfolgend wird das Erkennen von Rückgabekriterien für bereits ausgegebene Münzdatensätze, beispielsweise dass eine Münzdatensatz verfallen soll, erläutert:
    • Die elektronischen Münzdatensätze werden von einer zentralen Herausgeberinstanz ausgegeben, wobei jeder elektronische Münzdatensatz zusätzlich einen Prüfwert aufweist. Der Prüfwert wird bei direktem Übertragen des elektronischen Münzdatensatzes zwischen zwei Teilnehmereinheiten inkrementiert oder der Prüfwert ist invariant bei einer, von Teilnehmereinheiten mit dem elektronischen Münzdatensatz durchgeführten Aktion (Modifikation). Das Verfahren umfasst den folgenden Schritt: Bestimmen durch die Teilnehmereinheit anhand des Prüfwertes eines elektronischen Münzdatensatzes, ob dieser elektronische Münzdatensatz von der Teilnehmereinheit bei dem Bezahlsystem angezeigt wird oder Bestimmen durch die Teilnehmereinheit anhand des Prüfwerts des elektronischen Münzdatensatzes, ob der elektronische Münzdatensatz an die zentrale Herausgeberinstanz zurückgegeben wird. Somit wird in einer bevorzugten Ausgestaltung für das Erkennen von Rückgabekriterien anhand des bereits oben erwähnten Prüfwerts für nichtgesendete Transaktionsdatensätze oder anhand eines weiteren Prüfwerts auch bestimmt, ob der elektronische Münzdatensatz von der ersten Teilnehmereinheit bei dem Bezahlsystem, insbesondere einem Münzregister, angezeigt wird und/oder ob der elektronische Münzdatensatz an die zentrale Herausgeberinstanz zurückgegeben wird.
  • Jeder Prüfwert des elektronischen Münzdatensatzes wird im Verfahren verwendet, um eine Kontrollfunktion im Bezahlsystem zu ermöglichen beziehungsweise zu verbessern. Jeder Prüfwert ist bevorzugt ein Datenelement des elektronischen Münzdatensatzes das von der Teilnehmereinheit ausgelesen werden kann oder ein Datenelement in der Teilnehmereinheit und dessen Wert kann von der Teilnehmereinheit bestimmt werden. Der Prüfwert für die Rückgabekriterien ist an einen elektronischen Münzdatensatz gekoppelt.
  • Der Prüfwert für die Rückgabekriterien wird in einer ersten Ausgestaltung bei direktem Übertragen des elektronischen Münzdatensatzes zwischen zwei Teilnehmereinheiten inkrementiert (=schrittweise erhöht). Das Inkrementieren erfolgt entweder von einer sendenden Teilnehmereinheit unmittelbar vor dem Senden des Münzdatensatzes an ein empfangendes Endgerät inkrementiert. Oder das Inkrementieren erfolgt in einer empfangenden Teilnehmereinheit unmittelbar nach dem Empfang des Münzdatensatzes. Somit wird die Anzahl von direkten Übertragungen zwischen Teilnehmereinheiten für jeden Münzdatensatz festgehalten.
  • Der Prüfwert ist in einer zweiten (alternativ zur ersten) Ausgestaltung invariant bei einer, von Teilnehmereinheiten mit dem elektronischen Münzdatensatz durchgeführten Aktion (aktionsinvariant). Aktionsinvariant bedeutet, dass bei einer Aktion mit dem Münzdatensatz der Prüfwert unverändert erhalten bleibt. Der aktionsinvariante Prüfwert ist nicht-individuell für den elektronischen Münzdatensatz, sondern gruppenspezifisch und gilt daher für eine Mehrzahl von unterschiedlichen Münzdatensätzen, um eine Anonymität zu bewahren und eine Münzdatensatz-verfolgung zu verhindern.
  • Als Aktion mit einem Münzdatensatz wird jede von einem Endgerät durchgeführte Modifikation am Münzdatensatz, also insbesondere das Umschalten, das Aufteilen, das Kombinieren, wie später noch beschrieben wird. Zudem ist als Aktion jedes Übertragen des Münzdatensatzes, beispielsweise zu einer (anderen) Teilnehmereinheit oder auch einer Instanz im Bezahlsystem, gemeint. Zudem ist als Aktion das Einlösen des Münzdatensatzes zum Gutschreiben eines monetären Betrags des Münzdatensatzes oder das Wechseln des Währungssystems gemeint. Diese Aktionen werden von Teilnehmereinheiten durchgeführt und verändern den Prüfwert nicht.
  • Anhand des Prüfwerts des elektronischen Münzdatensatzes wird durch die Teilnehmereinheit bestimmt, ob dieser elektronische Münzdatensatz bei dem Bezahlsystem angezeigt (=gemeldet) wird. Beispielsweise wenn die Anzahl von Übertragungen zwischen Teilnehmereinheiten einen vordefinierten Schwellwert übersteigt, wird so dem Bezahlsystem der elektronischen Münzdatensatz angezeigt. Das Anzeigen entspricht in einer beispielhaften Ausgestaltung des Verfahrens dem Senden eines Umschalten-Kommando an ein Münzregister des Bezahlsystems, um dort ein Umschalten des Münzdatensatz auf die den Münzdatensatz sendende Teilnehmereinheit zu veranlassen. Das Anzeigen veranlasst in einer alternativen beispielhaften Ausgestaltung des Verfahrens ein Markieren des Münzdatensatzes in einem Überwachungsregister des Bezahlsystems. Der Prüfwert und/oder der Münzdatensatz kann, muss aber nicht, für den Zweck des Anzeigens an das Bezahlsystem übertragen werden. Die Rückgabe des elektronischen Münzdatensatzes durch die Teilnehmereinheit bedingt entweder das Einlösen eines mit dem elektronischen Münzdatensatz verbundenen monetären Betrags oder das Ausgeben eines neuen elektronischen Münzdatensatzes mit einem identischen monetären Betrag.
  • Die Rückgabe des elektronischen Münzdatensatzes durch die Teilnehmereinheit kann ein Zurücksetzen oder Löschen aller zu dem elektronischen Münzdatensatz vorhandenen Einträge in dem Überwachungsregister im Bezahlsystem auslösen. Damit werden digitale Spuren des elektronischen Münzdatensatzes gelöscht und die Anonymität des Verfahrens abgesichert.
  • Alternativ wird anhand des Prüfwerts des elektronischen Münzdatensatzes durch die Teilnehmereinheit bestimmt, ob der elektronische Münzdatensatz an die zentrale Herausgeberinstanz zurückgegeben wird. Damit kann mit dem Prüfwert ein Kriterium für die Rückgabe eines elektronischen Münzdatensatzes definiert werden. Auf diese Weise können elektronische Münzdatensätze beispielsweise aufgrund ihrer Lebensdauer oder der Anzahl von mit dem Münzdatensatz durchgeführten Aktionen verfallen, um die Sicherheit am Bezahlsystem zu erhöhen.
  • In einer bevorzugten Ausgestaltung wird der elektronische Münzdatensatz in Folge des Anzeigens von dem Bezahlsystem (dem Überwachungsregister) an die zentrale Herausgeberinstanz zurückgegeben. Durch das Anzeigen beim Bezahlsystem wird also im Bezahlsystem bestimmt, ob der Münzdatensatz zurückzugeben ist. Das Bestimmen, ob eine Rückgabe erfolgen muss, wird in dieser Ausgestaltung im Bezahlsystem anstelle der Teilnehmereinheit durchgeführt. Das Ergebnis des Bestimmens wird der Teilnehmereinheit mitgeteilt und die Teilnehmereinheit wird von dem Bezahlsystem aufgefordert, den elektronischen Münzdatensatz zurückzugeben.
  • In einer bevorzugten Ausgestaltung fordert das Bezahlsystem (das Überwachungsregister) in Folge des Anzeigens das Modifizieren des elektronischen Münzdatensatzes. Ein Modifizieren, beispielsweise ein Aufteilen, Kombinieren oder Umschalten, bedingt ein Registrieren des elektronischen Münzdatensatzes in dem Bezahlsystem. In vielen Ausgestaltungen des digitalen Währungs-Systems ist eine Rückgabe an die Herausgeberinstanz nicht notwendig und manchmal auch nicht sinnvoll. Dies gilt insbesondere, wenn der Münzdatensatz prompt nach seiner Ausgabe schnell modifiziert wurde. In dieser Ausgestaltung wird der Münzdatensatz nicht zurückgegeben, er gilt aber als zurückgegeben.
  • In einer bevorzugten Ausgestaltung wird ein Zählerwert im Bezahlsystem (dem Überwachungsregister) betreffend diesen elektronischen Münzdatensatz in Folge des Anzeigens durch das Bezahlsystem unter Verwendung des Prüfwerts des elektronischen Münzdatensatzes bestimmt. Der Prüfwert des Münzdatensatzes wird bevorzugt von der Teilnehmereinheit an das Bezahlsystem (dem Überwachungsregister) übertragen. Der Zählerwert ist dabei kein Bestandteil des Münzdatensatzes. Bevorzugt wird der Zählerwert im Bezahlsystem verwaltet. Bevorzugt wird der Zählerwert mit jeder Aktion (Modifikation, Übertragung, Einlösung) betreffend den elektronischen Münzdatensatz erhöht. Bevorzugt wird für unterschiedliche Aktionen der Zählerwert mit unterschiedlicher Gewichtung erhöht. Dadurch ist es möglich, die Rückgabe entsprechend unterschiedlicher Aktionen verbessert zu steuern. Somit ist im Münzdatensatz der Prüfwert als Datenelement vorgesehen, der insbesondere mit jeder direkten Übertragung zwischen Teilnehmereinheiten inkrementiert wird. Der Zählerwert im Bezahlsystem bezieht den Prüfwert ein, beispielsweise durch Addieren des bisherigen Zählerwerts mit dem Prüfwert.
  • In einer bevorzugten Ausgestaltung weist jeder elektronische Münzdatensatz einen ersten Prüfwert und einen zweiten Prüfwert auf. Der erste Prüfwert wird dann entsprechend beim direkten Übertragen des elektronischen Münzdatensatzes zwischen zwei Teilnehmereinheiten inkrementiert, wobei anhand des ersten Prüfwertes des elektronischen Münzdatensatzes bestimmt wird, ob der elektronische Münzdatensatz von der Teilnehmereinheit beim Bezahlsystem angezeigt wird. Anhand zumindest des zweiten Prüfwertes des elektronischen Münzdatensatzes wird bestimmt, ob der elektronische Münzdatensatz an die zentrale Herausgeberinstanz zurückgegeben wird. Somit ist ein Anzeige-Prüfwert getrennt von einem Rückgabe-Prüfwert im Münzdatensatz vorgesehen.
  • Bevorzugt ist der zweite Prüfwert invariant bei einer, von Teilnehmereinheiten mit dem elektronischen Münzdatensatz durchgeführten Aktion, wobei bevorzugt der zweite Prüfwert zumindest ein Wert aus der folgenden Liste ist: Rückgabedatum des elektronischen Münzdatensatzes; Ausgabedatum des elektronischen Münzdatensatzes; Registrierungsdatum des elektronischen Münzdatensatzes; und Identifizierungswert des elektronischen Münzdatensatzes. Der aktionsinvariante Prüfwert ist nicht-individuell für den elektronischen Münzdatensatz, sondern gruppenspezifisch und gilt daher für eine Mehrzahl von unterschiedlichen Münzdatensätzen, um eine Anonymität zu bewahren und eine Münzdatensatz-verfolgung zu verhindern. Der zweite aktionsinvariante Prüfwert ist dabei nicht individuell für den elektronischen Münzdatensatz, sondern gilt für eine Mehrzahl von unterschiedlichen Münzdatensätzen (Gruppen-ID), um eine Anonymität zu bewahren und eine Münzdatensatz-verfolgung zu verhindern.
  • In einer vorteilhaften Ausgestaltung ist der zweite Prüfwert variabel und umfasst den ersten Prüfwert, um zu bestimmen, ob der elektronische Münzdatensatz zurückgegeben wird. Dabei könnte eine Summe gebildet werden und diese Summe mit einem vordefinierten Schwellwert verglichen werden. Beispielsweise könnte die Anzahl von Direktübertragungen ein Rückgabekriterium sein, sodass keine Infrastruktur zur Auswertung der Münzdatensätze hinsichtlich der Rückgabe des Münzdatensätze in dem Bezahlsystem vorzuhalten wäre, also eine einfachere und sicherere Verwaltung unter Schaffung der Kontrollfunktionen ermöglicht wäre.
  • In einer vorteilhaften Ausgestaltung wird das Überschreiten eines Schwellwerts des Prüfwerts des elektronischen Münzdatensatzes durch ein erstes Endgerät festgestellt und eine Aktion mit diesem elektronischen Münzdatensatz, insbesondere das direkte Übertragen dieses elektronischen Münzdatensatzes von dem ersten Endgerät an ein zweites Endgerät, wird nur dann durchgeführt, wenn im ersten Endgerät festgestellt wurde, dass kein anderer elektronischer Münzdatensatz im ersten Endgerät vorhanden ist. Auf diese Weise wird sichergestellt, dass mit dem Münzdatensatz eine Bezahltransaktion zwischen zwei Endgeräten trotz hoher Anzahl von direkten Übertragungen dieses Münzdatensatzes zwischen Endgeräten mangels alternativer Münzdatensätze in dem Endgerät dennoch durchgeführt und abgeschlossen werden kann.
  • In einer vorteilhaften Ausgestaltung wird das Überschreiten eines Blockier-Schwellwerts des Prüfwerts des elektronischen Münzdatensatzes durch eine erste Teilnehmereinheit festgestellt und eine Aktion mit diesem elektronischen Münzdatensatz, insbesondere das direkte Übertragen dieses elektronischen Münzdatensatzes von der ersten Teilnehmereinheit an eine zweite Teilnehmereinheit, blockiert wird, unabhängig davon, ob in der ersten Teilnehmereinheit ein anderer elektronischer Münzdatensatz vorhanden ist oder nicht. Somit wird ein Schwellwert definiert, bei dessen Erreichen eine direkte Weitergabe (Übertragung) zwischen Teilnehmereinheiten vollständig unterbunden (blockiert) wird. Beispielsweise könnte dieser Münzdatensatz in einen sicheren Speicherbereich abgelegt werden, zudem nur ein Rückgabe-Prozess aber kein Aktionsprozess der Teilnehmereinheit Zugriff hat.
  • Das drohende Blockieren kann der Teilnehmereinheit vorab erfasst werden und einem Nutzer der Teilnehmereinheit mitgeteilt werden, um das Blockieren des Münzdatensatzes durch sofortiges Rückgeben des Münzdatensatzes zu unterbinden. Zusätzlich oder alternativ kann die Teilnehmereinheit bei Erkennen des Überschreitens des Blockier-Schwellwerts den elektronischen Münzdatensatz zurückgeben.
  • Bevorzugt ist der Schwellwert des Prüfwerts geringer als der Blockier-Schwellwert des Prüfwerts. Der Blockier-Schwellwert kann ein Vielfaches des Schwellwertes sein, um den Münzdatensatz nicht zu früh zu blockieren. Der Schwellwert liegt beispielsweise bei zehn, oder beispielsweise bei fünf oder beispielsweise bei 3. Der Blockier-Schwellwert liegt entsprechend bei 30, oder beispielsweise bei 15 oder beispielsweise bei 10.
  • In einer bevorzugten Ausgestaltung fragt die Herausgeberinstanz in vordefinierten periodischen Zeitabständen oder gezielt gesteuert Prüfwerte von Münzdatensätzen ab und fordert einen elektronischen Münzdatensatz automatisch zurück, wenn ein Prüfwert des elektronischen Münzdatensatzes überschritten ist.
  • In einer bevorzugten Ausgestaltung des Rückgabe-Verfahrens wird durch das Überwachungsregister des Bezahlsystems ein Zählerwert im Überwachungsregister betreffend den elektronischen Münzdatensatz unter Verwendung des Prüfwerts des elektronischen Münzdatensatzes bestimmt. Bei Überschreiten eines Schwellwertes des Zählerwertes, wird der elektronische Münzdatensatz (direkt oder indirekt) an die zentrale Herausgeberinstanz zurückgegeben. Dabei werden im Überwachungsregister bevorzugt ausschließlich maskierte Münzdatensätze verwaltet. Die Herausgeberinstanz oder das Bezahlsystem fordert den entsprechenden Münzdatensatz von der Teilnehmereinheit an oder stellt eine entsprechende Information vom Bezahlsystem an die Teilnehmereinheit zur (direkten) Rückgabe bereit. Der Zählerwert wird bevorzugt mit jeder Aktion am elektronischen Münzdatensatzes erhöht, wobei bevorzugt für unterschiedliche Aktionen der Zählerwert mit unterschiedlicher Gewichtung erhöht wird. Auf die oben genannten Vorteile bei einem derartigen Verfahren wird verwiesen.
  • In einer bevorzugten Ausgestaltung des Rückgabe-Verfahrens wird bei einer Durchführung einer Aktion mit dem elektronischen Münzdatensatz durch das Überwachungsregister der Prüfwert des elektronischen Münzdatensatzes von dem Bezahlsystem zurückgesetzt. Das vereinfacht das Verfahren, da die Teilnehmereinheit nicht an die Summe aller erlaubten Aktionen angepasst werden muss, sondern nur an die Summe nacheinander erlaubter direkter Übertragungen.
  • In einer bevorzugten Ausgestaltung wird beim Kombinieren (=Verbinden) von elektronischen Münzteildatensätzen zu einem kombinierten elektronischen Münzdatensatz durch das Bezahlsystem der höchste Prüfwert der elektronischen Münzteildatensätze bestimmt und dieser höchste Prüfwert als der Prüfwert des kombinierten elektronischen Münzdatensatzes übernommen wird.
  • In einer bevorzugten Ausgestaltung wird beim Kombinieren von elektronischen Münzteildatensätzen zu einem kombinierten elektronischen Münzdatensatz durch das Überwachungsregister ein neuer Prüfwert aus der Summe aller Prüfwerte der elektronischen Münzteildatensätzen geteilt durch das Produkt der Anzahl der Münzteildatensätze mit einem konstanten Korrekturwert bestimmt, wobei dieser neue Prüfwert als der Prüfwert des kombinierten elektronischen Münzdatensatzes übernommen wird, wobei der Korrekturwert größer gleich 1 ist und wobei bevorzugt der Korrekturwert von einer maximalen Abweichung der einzelnen Prüfwerte der elektronischen Münzteildatensätze oder von einem maximalen Prüfwert einer der elektronischen Münzteildatensätze abhängt, wobei weiter bevorzugt der Korrekturwert kleiner gleich 2 ist. Der Korrekturwert ist bezahlsystemweit konstant.
  • In einer bevorzugten Ausgestaltung erfolgt das Zurückgeben des elektronischen Münzdatensatzes von dem Überwachungsregister an die Herausgeberinstanz, wenn das Endgerät das Einlösen eines geldwerten Betrag des elektronischen Münzdatensatzes auf ein Konto des Bezahlsystems veranlasst und/oder wenn die Teilnehmereinheit einen Wechsel des geldwerten Betrags des elektronischen Münzdatensatzes in ein anderes Währungssystem des Bezahlsystems anfordert.
  • Ein elektronischer Münzdatensatz kann in einer Teilnehmereinheit aufgeteilt werden und dieses Aufteilen wird anschließend in dem Münzregister registriert. Das hat den Vorteil, dass ein Besitzer des zumindest einen elektronischen Münzdatensatzes nicht gezwungen ist, stets den gesamten monetären Betrag auf einmal zu übertragen, sondern nunmehr entsprechende monetäre Teilbeträge zu bilden und zu übertragen. Der Geldwert kann ohne Einschränkungen symmetrisch oder asymmetrisch aufgeteilt werden, solange alle elektronische Münzdatenteilsätze einen positiven monetären Betrag aufweisen, der kleiner ist als der monetäre Betrag des elektronische Münzdatensatzes, von dem aus aufgeteilt wird und die Summe der elektronischen Münzteildatensätze gleich dem aufzuteilenden elektronischen Münzteildatensatzes ist. Alternativ oder zusätzlich können feste Denominationen genutzt werden. Die Aufteilung in Teilbeträge ist beliebig. Das Aufteilen löst beispielsweise das Ausführen des oben beschriebenen Verfahrens zum Erzeugen und Verschlüsseln eines Transaktionsdatensatzes aus und der maskierte aufgeteilte elektronische Münzteildatensatz kann Teil eines Transaktionsdatensatzes für das Transaktionsregister sein.
  • Das Verfahren weist bevorzugt die weiteren folgenden Schritte auf: Umschalten des übertragenen elektronischen Münzteildatensatzes; und/oder Verbinden des übertragenen elektronischen Münzdatensatzes mit einem zweiten elektronischen Münzdatensatz zu einem (neuen) verbundenen elektronischen Münzdatensatz.
  • Beim Umschalten ergibt der von der ersten Teilnehmereinheit erhaltene elektronische Münzteildatensatz einen neuen elektronischen Münzdatensatz, bevorzugt mit gleichem monetärem Betrag, dem sogenannten umzuschaltenden elektronischen Münzdatensatz. Der neue elektronische Münzdatensatz wird von der zweiten Teilnehmereinheit generiert, vorzugsweise indem der monetäre Betrag des erhaltenen elektronischen Münzdatensatzes als monetärer Betrag des umzuschaltenden elektronischen Münzdatensatzes verwendet wird. Dabei wird ein neuer Verschleierungsbetrag, beispielsweise eine Zufallszahl, generiert. Der neue Verschleierungsbetrag wird beispielsweise zum Verschleierungsbetrag des erhaltenen elektronischen Münzdatensatzes addiert, damit die Summe beider Verschleierungsbeträge (neu und erhalten) als Verschleierungsbetrag des umzuschaltenden elektronischen Münzdatensatzes dient. Nach dem Umschalten wird bevorzugt der erhaltene elektronische Münzteildatensatz und der umzuschaltende elektronische Münzteildatensatz in der Teilnehmereinheit durch Anwenden der homomorphen Einwegfunktion auf jeweils den erhaltenen elektronischen Münzteildatensatz und den umzuschaltenden elektronischen Münzteildatensatz maskiert, um entsprechend einen maskierten erhaltenen elektronischen Münzteildatensatz und einen maskierten umzuschaltenden elektronischen Münzteildatensatz zu erhalten. Das Umschalten löst beispielsweise das Ausführen des oben beschriebenen Verfahrens zum Erzeugen und Verschlüsseln eines Transaktionsdatensatzes aus und der maskierte umzuschaltende elektronische Münzteildatensatz kann Teil eines Transaktionsdatensatzes für das Transaktionsregister sein.
  • Das Umschalten wird also durch Hinzufügen eines neuen Verschleierungsbetrags zum Verschleierungsbetrag des erhaltenen elektronischen Münzdatensatz abgesichert, wodurch ein Verschleierungsbetrag erhalten wird, den nur die zweite Teilnehmereinheit kennt. Neu geschaffene Verschleierungsbeträge müssen eine hohe Entropie aufweisen, da sie als Blendungsfaktor für die entsprechenden maskierten elektronischen Münzteildatensätze verwendet werden. Bevorzugt wird dazu ein Zufallszahlengenerator auf dem Sicherheitselement verwendet. Diese Absicherung kann in dem Münzregister nachverfolgt werden.
  • Im Rahmen des Umschaltens werden bevorzugt zusätzliche Informationen, die zum Registrieren des Umschaltens des maskierten elektronischen Münzdatensatzes in dem Münzregister benötigt werden, in der Teilnehmereinheit berechnet. Bevorzugt beinhalten die zusätzlichen Informationen einen Bereichsnachweis über den maskierten umzuschaltenden elektronischen Münzdatensatz und einen Bereichsnachweis über den maskierten erhaltenen elektronischen Münzdatensatz. Bei dem Bereichsnachweis handelt es sich um einen Nachweis, dass der monetäre Betrag des elektronischen Münzdatensatzes nicht negativ ist, der elektronische Münzdatensatz gültig erstellt und/ oder der monetäre Betrag und der Verschleierungsbetrag des elektronischen Münzdatensatzes dem Ersteller des Bereichsnachweises bekannt sind. Insbesondere dient der Bereichsnachweis dazu, diese(n) Nachweis(e) zu führen ohne den monetären Betrag und/oder den Verschleierungsbetrag des maskierten elektronischen Münzdatensatzes zu offenbaren. Diese Bereichsnachweise werden auch „Zero-Knowledge-Range-Proofs“ genannt. Bevorzugt werden als Bereichsnachweis Ringsignaturen verwendet. Anschließend erfolgt ein Registrieren des Umschaltens des maskierten elektronischen Münzdatensatzes in dem entfernten Münzregister. Das Registrieren löst beispielsweise das Ausführen des oben beschriebenen Verfahrens zum Erzeugen und Verschlüsseln eines Transaktionsdatensatzes aus und der maskierte umzuschaltende elektronische Münzteildatensatz kann Teil eines Transaktionsdatensatzes für das Transaktionsregister sein.
  • Der Schritt des Registrierens wird vorzugsweise dann ausgeführt, wenn die zweite Teilnehmereinheit mit dem Münzregister verbunden ist. Während die elektronischen Münzdatensätze für direktes Bezahlen zwischen zwei Teilnehmereinheiten verwendet werden, können die maskierten Münzdatensätze mit einem Pseudonym in dem Münzregister registriert werden. Das Registrieren löst beispielsweise das Ausführen des oben beschriebenen Verfahrens zum Erzeugen und Verschlüsseln eines Transaktionsdatensatzes aus und der pseudonymisierte maskierte umzuschaltende elektronische Münzteildatensatz kann Teil eines Transaktionsdatensatzes für das Transaktionsregister sein.
  • In einer weiter bevorzugten Ausgestaltung des Verfahrens wird für ein Verbinden von elektronischen Münzteildatensätzen ein weiterer elektronischer Münzdatensatz (verbundener elektronischer Münzdatensatz) aus einem ersten und einem zweiten elektronischen Münzteildatensatz bestimmt. Dabei wird der Verschleierungsbetrag für den zu verbindenden elektronischen Münzdatensatz durch Bilden der Summe aus den jeweiligen Verschleierungsbeträgen des ersten und des zweiten elektronischen Münzdatensatzes berechnet. Weiterhin wird vorzugsweise der monetäre Betrag für den verbundenen elektronischen Münzdatensatz durch Bilden der Summe aus den jeweiligen monetären Beträgen des ersten und des zweiten elektronischen Münzdatensatzes berechnet.
  • Nach dem Verbinden wird der erste elektronische Münzteildatensatz, der zweite elektronische Münzteildatensatz, sowie der zu verbindende elektronische Münzdatensatz in der (ersten und/ oder zweiten) Teilnehmereinheit durch Anwenden der homomorphen Einwegfunktion auf jeweils den ersten elektronischen Münzteildatensatz, den zweiten elektronischen Münzteildatensatz, sowie den zu verbindenden elektronischen Münzdatensatz maskiert, um entsprechend einen maskierten ersten elektronischen Münzteildatensatz, einen maskierten zweiten elektronischen Münzteildatensatz, sowie einen maskierten zu verbindenden elektronischen Münzdatensatz zu erhalten. Des Weiteren werden zusätzliche Informationen, die zum Registrieren des Verbindens der maskierten elektronischen Münzdatensätze in dem entfernten Münzregister benötigt werden, in der Teilnehmereinheit berechnet. Bevorzugt beinhalten die zusätzlichen Informationen einen Bereichsnachweis über den maskierten ersten elektronischen Münzteildatensatz und einen Bereichsnachweis über den maskierten zweiten elektronischen Münzteildatensatz. Bei dem Bereichsnachweis handelt es sich um einen Nachweis, dass der monetäre Betrag des elektronischen Münzdatensatzes nicht negativ ist, der elektronische Münzdatensatz gültig erstellt und/ oder der monetäre Betrag und der Verschleierungsbetrag des elektronischen Münzdatensatzes dem Ersteller des Bereichsnachweises bekannt sind. Insbesondere dient der Bereichsnachweis dazu, diese(n) Nachweis zu führen ohne den monetären Wert und/oder den Verschleierungsbetrag des maskierten elektronischen Münzdatensatzes zu offenbaren. Diese Bereichsnachweise werden auch „Zero-Knowledge-Range-Proofs“ genannt. Bevorzugt werden als Bereichsnachweis Ringsignaturen verwendet. Anschließend erfolgt ein Registrieren des Verbindens der beiden maskierten elektronischen Münzteildatensätze in dem entfernten Münzregister. Das Registrieren löst beispielsweise das Ausführen des oben beschriebenen Verfahrens zum Erzeugen und Verschlüsseln eines Transaktionsdatensatzes aus und der maskierte verbundene elektronische Münzteildatensatz kann Teil eines Transaktionsdatensatzes für das Transaktionsregister sein.
  • Mit dem Schritt des Verbindens können zwei elektronische Münzdatensätze bzw. zwei elektronische Münzteildatensätze zusammengefasst werden. Dabei werden die monetären Beträge sowie auch die Verschleierungsbeträge addiert. Wie beim Aufteilen kann somit auch beim Verbinden eine Validität der beiden ursprünglichen Münzdatensätze durchgeführt werden.
  • In einer bevorzugten Ausgestaltung umfasst der Registrieren-Schritt das Empfangen des maskierten umzuschaltenden elektronischen Münzteildatensatzes in dem Münzregister, das Prüfen des maskierten umzuschaltenden elektronischen Münzteildatensatzes auf Validität; und das Registrieren des maskierten umzuschaltenden elektronischen Münzdatensatzes in dem Münzregister, wenn der Prüfen-Schritt erfolgreich ist, wodurch der umzuschaltende elektronische Münzteildatensatz als überprüft gilt.
  • Somit ergibt sich beispielsweise ein zumindest dreischichtiges Bezahlsystem. In einer ersten Schicht (Direkttransaktionsschicht) werden elektronische Münzdatensätze zwischen einzelnen Teilnehmereinheiten bzw. deren Sicherheitselementen direkt übertragen. In einer zweiten Schicht (Prüfschicht) werden maskierte elektronische Münzdatensätze in einem Münzregister und einem Überwachungsregister registriert und geprüft. In der zweiten Schicht werden bevorzugt keine Bezahltransaktionen festgehalten, sondern ausschließlich maskierte elektronische Münzdatensätze, deren Status, ggf. Prüfwerte, Signaturen und Modifikationen zum Zweck der Verifizierung der Gültigkeit von (nicht maskierten) elektronischen Münzdatensätzen. So wird die Anonymität der Teilnehmer des Bezahlsystems gewährleistet. Die zweite Schicht gibt Auskunft über gültige und ungültige elektronische Münzdatensätze, um beispielsweise eine Mehrfach-Ausgabe des gleichen elektronischen Münzdatensatzes zu vermeiden oder die Echtheit des elektronischen Münzdatensatzes als gültig herausgegebenes elektronisches Geld zu verifizieren oder die Summe monetärer Beträge pro Sicherheitselement zu erfassen, um diese Summe mit einem Grenzwert zu vergleichen und eine Modifikation entsprechend zu unterbinden oder zu gestatten. Die zweite Schicht kann anhand eines Zählerwerts eines elektronischen Münzdatensatzes bestimmen, ob der elektronische Münzdatensatz verfallen ist und zurückzugeben ist, oder entsprechend zu modifizieren ist, sodass er als zurückgegeben gilt. In einer dritten Schicht (Archivierungsschicht) werden verschlüsselte Transaktionsdatensätze in einem Transaktionsregister abgelegt und auf behördliche Anfrage wie oben dargestellt entschlüsselt und geprüft.
  • Darüber hinaus umfasst das Bezahlsystem beispielsweise auch eine Herausgeberinstanz, die elektronische Münzdatensätze generiert (Erstellen) und wieder einfordert (Löschen). Bei der Herausgabe eines elektronischen Münzdatensatzes von der Herausgeberinstanz an eine Teilnehmereinheit kann parallel ein maskierter elektronischer Münzdatensatz von der Herausgeberinstanz an das Münzregister und/oder das Überwachungsregister des Bezahlsystems zur Registrierung des elektronischen Münzdatensatzes mit ausgegeben werden.
  • Eine Teilnehmereinheit kann vorliegend ein Sicherheitselement aufweisen oder selbst ein Sicherheitselement sein, in dem der elektronische Münzdatensatz sicher abgelegt ist. Auf der Teilnehmereinheit kann eine Applikation betriebsbereit eingebracht sein, die Teile des Übertragen-Verfahrens steuert oder zumindest initiiert.
  • Die Übertragung von elektronischen Münzdatensätzen kann jeweils unter Zuhilfenahme von Endgeräten als Teilnehmereinheit erfolgen, die mit den Sicherheitselementen logisch und/oder physisch verbunden sind.
  • Die Kommunikation zwischen zwei Teilnehmereinheiten, ggf. mit den jeweiligen Sicherheitselementen, kann drahtlos oder drahtgebunden, oder z.B. auch auf optischem Weg, bevorzugt über QR-Code oder Barcode, erfolgen und kann als ein gesicherter Kanal, beispielsweise zwischen Applikationen der Teilnehmereinheiten ausgebildet sein. Der optische Weg kann beispielsweise die Schritte des Generierens einer optischen Codierung, insbesondere einer 2D-Codierung, vorzugsweise ein QR-Code, und des Einlesens der optischen Codierung umfassen.
  • Das Übertragen des elektronischen Münzdatensatzes ist beispielsweise durch kryptografische Schlüssel gesichert, beispielsweise einem für einen elektronischen Münzdatensatz-Austausch ausgehandelten Sitzungsschlüssel oder einem symmetrischen oder asymmetrischen Schlüsselpaar.
  • Durch das Kommunizieren zwischen Teilnehmereinheiten, beispielsweise über ihre Sicherheitselemente, werden die ausgetauschten elektronischen Münzdatensätze vor Diebstahl oder Manipulation geschützt. Die Ebene der Sicherheitselemente ergänzt so die Sicherheit etablierter Blockchain-Technologie.
  • In einer bevorzugten Ausgestaltung erfolgt das Übertragen der Münzdatensätze als APDU Kommandos. Dazu ist der Münzdatensatz bevorzugt in einer (embedded) UICC als Sicherheitselement abgelegt und wird dort verwaltet. Ein APDU ist ein kombinierter Kommando-/Datenblock eines Verbindungsprotokolls zwischen der UICC und einem Endgerät. Die Struktur der APDU ist durch den Standard ISO-7816-4 definiert. APDUs stellen ein Informationselement der Anwendungsebene (Schicht 7 des OSI-Schichtenmodels) dar.
  • Darüber hinaus ist es vom Vorteil, dass die elektronischen Münzdatensätze in beliebiger Formatierung übertragen werden können. Dies impliziert, dass sie auf beliebigen Kanälen kommuniziert, also übertragen werden können. Sie müssen nicht in einem festgelegten Format oder in einem bestimmten Programm gespeichert werden.
  • Als eine Teilnehmereinheit wird insbesondere ein mobiles Telekommunikationsendgerät, beispielsweise ein Smartphone angesehen. Alternativ oder zusätzlich kann die Teilnehmereinheit auch ein Gerät, wie Wearable, Smartcard, Maschine, Werkzeug, Automat oder auch Behälter bzw. Fahrzeug sein. Eine Teilnehmereinheit ist somit entweder stationär oder mobil. Die Teilnehmereinheit ist vorzugsweise ausgebildet, das Internet und/ oder andere öffentliche oder private Netze zu nutzen. Dazu verwendet die Teilnehmereinheit eine geeignete Verbindungstechnologie, beispielsweise Bluetooth, LoRa, NFC und/ oder WiFi und weist wenigstens eine entsprechende Schnittstelle auf. Die Teilnehmereinheit kann auch ausgebildet sein, mittels Zugangs zu einem Mobilfunknetz mit dem Internet und/ oder anderen Netzen verbunden zu werden.
  • Beispielsweise stellen zwei Teilnehmereinheiten eine lokale drahtlos Kommunikationsverbindung über deren Protokoll dann die Übertragung zwischen den beiden darin befindlichen Sicherheitselementen eingebracht ist.
  • In einer Ausgestaltung kann vorgesehen sein, dass das erste und/ oder zweite Sicherheitselement die empfangenen elektronischen Münzdatensätze bei Vorliegen oder Empfang mehrerer elektronischer Münzdatensätze diese entsprechend ihrer monetären Wertigkeit abarbeitet. So kann vorgesehen sein, dass elektronische Münzdatensätze mit höherer monetärer Wertigkeit vor elektronische Münzdatensätze mit niedriger monetärer Wertigkeit verarbeitet.
  • In einer Ausgestaltung kann die Teilnehmereinheit ausgebildet sein, nach Empfang eines elektronischen Münzdatensatzes diesen in Abhängigkeit von beigefügter Information, beispielsweise einer Währung oder Denomination, mit bereits in der Teilnehmereinheit vorhandenem elektronischen Münzdatensatz zu verbinden und entsprechend einen Schritt des Verbindens auszuführen. Weiterhin kann die Teilnehmereinheit auch zum automatisierten Ausführen eines Umschaltens nach Empfang des elektronischen Münzdatensatzes ausgebildet sein.
  • In einer Ausgestaltung werden beim Übertragen weitere Informationen, insbesondere Metadaten, von der ersten Teilnehmereinheit bzw. ersten Sicherheitselement auf die zweite Teilnehmereinheit bzw. zweite Sicherheitselement übermittelt, beispielsweise eine Währung. Diese Information kann in einer Ausgestaltung vom elektronischen Münzdatensatz umfasst sein.
  • Die Verfahren sind nicht auf eine Währung beschränkt. So kann das Bezahlsystem eingerichtet sein, verschiedene Währungen von unterschiedlichen Herausgeberinstanzen zu verwalten. Das Bezahlsystem ist beispielsweise eingerichtet einen elektronischen Münzdatensatz einer ersten Währung in ein elektronischen Münzdatensatz einer anderen Währung umzusetzen (=wechseln). Dieses Wechseln ist ebenfalls eine Modifikation des elektronischen Münzdatensatzes. Mit dem Wechsel wird der ursprüngliche Münzdatensatz ungültig und gilt als zurückgegeben. Ein flexibles Bezahlen mit unterschiedlichen Währungen ist damit möglich und die Benutzerfreundlichkeit ist erhöht.
  • Die Verfahren ermöglichen zudem das Umsetzen des elektronischen Münzdatensatzes in Buchgeld, also beispielsweise das Einlösen des monetären Betrags auf ein Konto des Teilnehmers am Bezahlsystem. Dieses Umsetzen ist ebenfalls eine Modifikation. Mit dem Einlösen wird der elektronische Münzdatensatz ungültig und gilt als zurückgegeben.
  • Bevorzugt wird der zumindest eine initiale elektronische Münzdatensatz ausschließlich von der Herausgeberinstanz erstellt, wobei vorzugsweise die aufgeteilten elektronischen Münzdatensätze, insbesondere elektronischen Münzteildatensätze, auch durch eine Teilnehmereinheit generiert werden können. Das Erstellen und das Wählen eines monetären Betrags beinhalten bevorzugt auch das Wählen eines Verschleierungsbetrags mit hoher Entropie. Die Herausgeberinstanz ist ein Rechensystem, welches bevorzugt entfernt von der ersten und/ oder zweiten Teilnehmereinheit ist. Nach dem Erstellen des neuen elektronischen Münzdatensatzes wird der neue elektronische Münzdatensatz in der Herausgeberinstanz durch Anwenden der homomorphen Einwegfunktion auf den neuen elektronischen Münzdatensatz maskiert, um entsprechend einen maskierten neuen elektronischen Münzdatensatz zu erhalten. Des Weiteren werden zusätzliche Informationen, die zum Registrieren des Erstellens des maskierten neuen elektronischen Münzdatensatzes in dem entfernten Münzregister benötigt werden, im der Herausgeberinstanz berechnet. Bevorzugt sind diese weiteren Informationen ein Nachweis, dass der (maskierte) neue elektronische Münzdatensatz von der Herausgeberinstanz stammt, beispielsweise durch ein Signieren des maskierten neuen elektronischen Münzdatensatzes. In einer Ausgestaltung kann vorgesehen sein, dass die Herausgeberinstanz einen maskierten elektronischen Münzdatensatz beim Erzeugen des elektronischen Münzdatensatzes mit ihrer Signatur signiert. Die Signatur der Herausgeberinstanz wird dazu in dem Münzregister hinterlegt. Die Signatur der Herausgeberinstanz ist von der erzeugten Signatur einer Teilnehmereinheit bzw. eines Sicherheitselements verschieden.
  • Bevorzugt kann die Herausgeberinstanz einen elektronischen Münzdatensatz, der sich in ihrem Besitz befindet (also von dem sie den monetären Betrag und den Verschleierungsbetrag kennt) deaktivieren, indem sie den maskierten zu deaktivierenden elektronischen Münzdatensatz mit der homomorphen Einwegfunktion maskiert und einen Deaktivieren-Befehl für das Münzregister vorbereitet. Ein Teil des Deaktivieren-Befehls ist bevorzugt neben dem maskierten zu deaktivierenden elektronischen Münzdatensatzes auch der Nachweis, dass der Deaktivieren Schritt von der Herausgeberinstanz initiiert wurde, beispielsweise in Form des signierten maskierten zu deaktivierenden elektronischen Münzdatensatzes. Als zusätzliche Information könnten im Deaktivieren-Befehl Bereichsprüfungen für den maskierten zu deaktivierenden elektronischen Münzdatensatz enthalten sein. Das Deaktivieren kann die Folge eines Zurückgebens sein. Anschließend erfolgt ein Registrieren des Deaktivierens des maskierten elektronischen Münzdatensatzes in dem entfernten Münzregister. Mit dem Deaktivieren-Befehl wird der Schritt des Deaktivierens ausgelöst.
  • Die Schritte Erstellen und Deaktivieren erfolgen bevorzugt an gesicherten Orten, insbesondere nicht in den Teilnehmereinheiten. In einer bevorzugten Ausgestaltung werden die Schritte des Erstellens und Deaktivierens nur von der Herausgeberinstanz durchgeführt bzw. angestoßen. Vorzugsweise finden diese Schritte an einen gesicherten Ort statt, beispielsweise in einer Hard- und Software-Architektur, die zur Verarbeitung von sensiblem Datenmaterial in unsicheren Netzen entwickelt wurde. Das Deaktivieren des entsprechenden maskierten elektronischen Münzdatensatz bewirkt, dass der entsprechende maskierte elektronische Münzdatensatz nicht mehr für weitere Verarbeitung, insbesondere Transaktionen, verfügbar ist. Jedoch kann in einer Ausführungsform vorgesehen sein, dass der deaktivierte maskierte elektronische Münzdatensatz bei der Herausgeberinstanz archivarisch bestehen bleibt. Dass der deaktivierte maskierte elektronische Münzdatensatz nicht mehr gültig bzw. zurückgegeben wird, kann beispielsweise mithilfe eines Flags oder einer anderen Codierung gekennzeichnet oder der deaktivierte maskierte elektronische Münzdatensatz kann zerstört und/ oder gelöscht werden. Der deaktivierte elektronische Münzdatensatz wird auch physisch von der Teilnehmereinheit bzw. dem Sicherheitselement entfernt.
  • Durch das erfindungsgemäße Verfahren werden verschiedene Verarbeitungsoperationen (Modifikationen) für die elektronischen Münzdatensätze und die entsprechenden maskierten elektronischen Münzdatensätze ermöglicht. Jeder der Verarbeitungsoperationen (insbesondere das Erstellen, Deaktivieren, Aufteilen, Verbinden und Umschalten) wird dabei in dem Münzregister registriert und dort in unveränderlicher Form an die Liste der vorherigen Verarbeitungsoperationen für den jeweiligen maskierten elektronischen Münzdatensatz angehängt. Jede der Verarbeitungsoperationen löst beispielsweise das Verfahren zum Erzeugen und Verschlüsseln eines Transaktionsdatensatzes aus. Die Registrierung ist dabei vom Bezahlvorgang zwischen den Teilnehmereinheiten sowohl zeitlich als auch örtlich (räumlich) unabhängig. Die Verarbeitungsoperationen „Erstellen“ und „Deaktivieren“ (=Zurückgeben), die die Existenz des monetären Betrags an sich betreffen, also die Schaffung und die Vernichtung bis hin der Zerstörung von Geld bedeuten, bedürfen einer zusätzlichen Genehmigung, beispielsweise in Form einer Signatur, durch die Herausgeberinstanz, um in dem Münzregister registriert (also protokolliert) zu werden. Die übrigen Verarbeitungsoperationen (Aufteilen, Verbinden, Umschalten), von denen das Aufteilen und das Verbinden auch von einer Teilnehmereinheit auch an eine weitere Teilnehmereinheit delegiert werden können, bedürfen keiner Autorisierung durch die Herausgeberinstanz oder durch den Befehlsinitiator (= Zahler, bspw. Teilnehmereinheit oder Sicherheitselement).
  • Eine Verarbeitung in der Direkttransaktionsschicht betrifft nur die Besitzverhältnisse und/ oder die Zuordnung der Münzdatensätze zu Teilnehmereinheiten der jeweiligen elektronischen Münzdatensätze. Eine Registrierung der jeweiligen Verarbeitung in dem Münzregister bzw. dem Überwachungsregister wird beispielsweise durch entsprechende Listeneinträge in einer Datenbank realisiert, die eine Reihe von Markierungen umfasst, die von dem Münzregister durchgeführt werden müssen. Eine mögliche Struktur für einen Listeneintrag umfasst beispielsweise Spalte(n) für einen Vorgänger-Münzdatensatz, Spalte(n) für einen Nachfolger-Münzdatensatz, eine Signatur-Spalte für die Herausgeberinstanz, eine Signatur-Spalte für das sendende und/oder empfangende Sicherheitselement, eine Signatur-Spalte für Münzteilungsvorgänge und zumindest eine Markierungsspalte. Eine Änderung (Modifikation) ist endgültig, wenn und die erforderlichen Markierungen durch das Münzregister oder das Überwachungsregister validiert wurden, d.h. nach der entsprechenden Prüfung beispielsweise vom Status „0“ in den Status „1“ gewechselt wurden. Scheitert eine Prüfung oder dauert zu lang, so wird sie stattdessen beispielsweise vom Status „-“ in den Status „0“ gewechselt. Weitere Statuswerte sind denkbar und/oder die hier genannten Statuswerte sind austauschbar. Die Status bezüglich der Modifikationen sind unabhängig vom Status während des Übertragenvorgangs (Inaktiv/Aktiv). Bevorzugt wird die Gültigkeit der jeweiligen (maskierten) elektronischen Münzdatensätze aus den Statuswerten der Markierungen zusammengefasst jeweils in einer Spalte für jeden maskierten elektronischen Münzdatensatz, der im Registrieren der Verarbeitung involviert ist, dargestellt.
  • In einem weiteren Ausführungsbeispiel können wenigstens zwei vorzugsweise drei oder sogar alle der vorhergenannten Markierungen auch durch eine einzige Markierung ersetzt werden, die dann gesetzt wird, wenn alle Prüfungen erfolgreich abgeschlossen wurden. Des Weiteren lassen sich die je zwei Spalten für Vorgänger-Datensätze und Nachfolger-Datensätze zu jeweils einem zusammenfassen, in welchem alle Münzdatensätze gemeinsam ausgelistet sind. Dadurch könnten dann auch mehr als zwei elektronische Münzdatensätze je Feldeintrag verwaltet werden, und somit z.B. eine Aufspaltung in mehr als zwei Münzdatensätze realisiert werden.
  • Die Prüfungen durch das Überwachungsregister, um zu prüfen, ob eine Verarbeitung endgültig ist sind bereits oben beschrieben und sind insbesondere:
    • - Sind die maskierten elektronischen Münzdatensätze der Vorgänger-Spalte(n) gültig?
    • - Ergibt eine Überwachung den korrekten Prüfwert?
    • - Sind die Bereichsnachweise für die maskierten elektronischen Münzdatensätze erfolgreich?
    • - Ist die Signatur des maskierten elektronischen Münzdatensatzes eine gültige Signatur der Herausgeberinstanz?
    • - Überschreitet die sendende/empfangende Teilnehmereinheit (Pseudonym) einen Grenzwert für einen maximal zulässigen monetären Betrag, insbesondere pro Zeiteinheit?
    • - Ist der Münzdatensatz Inaktiv aufgrund Übertragen zwischen Teilnehmereinheiten?
  • Bevorzugt gilt zudem, dass ein maskierter elektronischer Münzdatensatz ungültig ist, wenn einer der folgenden Prüfungen zutrifft, also wenn:
    • (1) der maskierte elektronische Münzdatensatz nicht in dem Münzregister registriert ist;
    • (2) die letzte Verarbeitung des maskierten elektronischen Münzdatensatzes angibt, dass es für ihn Vorgänger-Münzdatensätze gibt, diese letzte Verarbeitung aber nicht endgültig ist; oder
    • (3) die letzte Verarbeitung des maskierten elektronischen Münzdatensatzes angibt, dass es für ihn Nachfolger-Münzdatensätze gibt und diese letzte Verarbeitung endgültig ist;
    • (4) der maskierte elektronische Münzdatensatz nicht der Nachfolger von einem gültigen maskierten elektronischen Datensatz ist, es sei denn er ist von der Herausgeberinstanz signiert;
    • (5) der monetäre Betrag des maskierten elektronischen Münzdatensatzes dazu führt, dass ein Grenzwert für einen maximal zulässigen monetären Betrag, insbesondere pro Zeiteinheit, überschritten wird und die geforderte Deanonymisierung von der entsprechenden Teilnehmereinheit abgelehnt wird;
    • (6) Ein Aktiv-Status für ein Sicherheitselement im Münzregister eingetragen ist, aber eine andere Teilnehmereinheit eine Aktion (Umschalten, Kombinieren, Aufteilen) unter Besitzanzeige anfragt.
  • Bevorzugt ist das Bezahlsystem zum Durchführen des oben genannten Verfahrens und/ oder wenigstens einer der Ausführungsvarianten ausgebildet.
  • Ein weiterer Aspekt betrifft ein Währungssystem umfassend eine Herausgeberinstanz, eine Münzregisterschicht, ein erstes Sicherheitselement und ein zweites Sicherheitselement, wobei die Herausgeberinstanz ausgebildet ist, einen elektronischen Münzdatensatzes zu erstellen. Der maskierte elektronische Münzdatensatz ist ausgebildet, nachweisbar durch die Herausgeberinstanz erstellt zu sein. Die Prüfschicht ist zum Ausführen eines Registrierschritts wie in dem oben genannten Verfahren ausgeführt, ausgebildet. Vorzugsweise sind die Sicherheitselemente, d.h. wenigstens das erste und zweite Sicherheitselement zum Ausführen eines der oben genannten Verfahren (i) zum Übertragen und (ii) zum Erzeugen + Verschlüsseln + Initiieren geeignet.
  • In einer bevorzugten Ausführung des Währungssystems ist lediglich die Herausgeberinstanz berechtigt, einen elektronischen Münzdatensatz initial zu erstellen und final zurückzunehmen. Eine Verarbeitung, beispielsweise der Schritt des Verbindens, des Aufteilens und/ oder des Umschaltens, kann und wird vorzugsweise durch eine Teilnehmereinheit durchgeführt. Der Verarbeitungsschritt des Deaktivierens kann vorzugsweise nur von der Herausgeberinstanz ausgeführt werden.
  • Bevorzugt sind das Münzregister, das Überwachungsregister und die Herausgeberinstanz in einer gemeinsamen Serverinstanz angeordnet oder liegen als Computerprogrammprodukt auf einem Server und/ oder einem Computer vor.
  • Bevorzugt ist das Transaktionsregister in einer von der gemeinsamen Serverinstanz verschiedenen Serverinstanz angeordnet oder liegt dort als Computerprogrammprodukt vor.
  • Ein elektronischer Münzdatensatz kann dabei in einer Vielzahl von unterschiedlichen Erscheinungsformen vorliegen und damit über verschiedene Kommunikationskanäle, nachfolgend auch Schnittstellen genannt, ausgetauscht werden. Ein sehr flexibler Austausch von elektronischen Münzdatensätzen ist damit geschaffen.
  • Der elektronische Münzdatensatz ist beispielsweise in Form einer Datei darstellbar. Eine Datei besteht dabei aus inhaltlich zusammengehörigen Daten, die auf einem Datenträger, Datenspeicher oder Speichermedium gespeichert sind. Jede Datei ist zunächst eine eindimensionale Aneinanderreihung von Bits, die normalerweise in Byte-Blöcken zusammengefasst interpretiert werden. Ein Anwendungsprogramm (Applikation) oder ein Betriebssystem des Sicherheitselements und/oder des Endgeräts interpretieren diese Bit- oder Bytefolge beispielsweise als einen Text, ein Bild oder eine Tonaufzeichnung. Das dabei verwendete Dateiformat kann unterschiedlich sein, beispielsweise kann es eine reine Textdatei sein, die den elektronischen Münzdatensatz repräsentiert. Dabei werden insbesondere der monetäre Betrag und die blinde Signatur als Datei abgebildet.
  • Der elektronische Münzdatensatz ist beispielsweise eine Folge von American Standard Code for Information Interchange, kurz ASCII, Zeichen. Dabei werden insbesondere der monetäre Betrag und die blinde Signatur als diese Folge abgebildet.
  • Der elektronische Münzdatensatz kann in einer Teilnehmereinheit auch von einer Darstellungsform in eine andere Darstellungsform umgewandelt werden. So kann beispielsweise der elektronische Münzdatensatz als QR-Code in einer Teilnehmereinheit empfangen werden und als Datei oder Zeichenfolge von der Teilnehmereinheit ausgegeben werden.
  • Diese unterschiedlichen Darstellungsformen von ein und demselben elektronischen Münzdatensatz ermöglichen einen sehr flexiblen Austausch zwischen Teilnehmereinheiten bzw. Sicherheitselementen bzw. Endgeräten unterschiedlicher technischer Ausrüstung unter Verwendung unterschiedlicher Übertragungsmedien (Luft, Papier, drahtgebunden) und unter Berücksichtigung der technischen Ausgestaltung einer Teilnehmereinheit. Die Wahl der Darstellungsform der elektronischen Münzdatensätze erfolgt bevorzugt automatisch, beispielsweise aufgrund erkannter oder ausgehandelter Übertragungsmedien und Gerätekomponenten. Zusätzlich kann auch ein Benutzer einer Teilnehmereinheit die Darstellungsform zum Austausch (=Übertragen) eines elektronischen Münzdatensatzes wählen.
  • In einem einfachen Fall ist der Datenspeicher ein interner Datenspeicher der Teilnehmereinheit. Hier werden die elektronischen Münzdatensätze abgelegt. Ein einfacher Zugriff auf elektronische Münzdatensätze ist somit gewährleistet.
  • Der Datenspeicher ist insbesondere ein externer Datenspeicher, auch Online-Speicher genannt. Somit weist das Sicherheitselement bzw. die Teilnehmereinheit nur ein Zugriffsmittel auf die extern und damit sicher abgelegten elektronischen Münzdatensätze auf. Insbesondere bei einem Verlust des Sicherheitselements bzw. der Teilnehmereinheit oder bei Fehlfunktionen des Sicherheitselements bzw. der Teilnehmereinheit sind die elektronischen Münzdatensätze nicht verloren. Da der Besitz der (nicht maskierten) elektronischen Münzdatensätze gleich dem Besitz des monetären Betrags entspricht, kann durch Verwendung externer Datenspeicher Geld sicherer aufbewahrt und verwaltet werden.
  • Ist das Münzregister eine entfernte Instanz, so verfügt die Teilnehmereinheit bevorzugt über eine Schnittstelle zur Kommunikation mittels einem üblichen Internet-Kommunikationsprotokoll, beispielsweise TCP, IP, UDP oder HTTP. Die Übertragung kann eine Kommunikation über das Mobilfunknetz beinhalten.
  • In einer bevorzugten Ausgestaltung ist die Schnittstelle zum Ausgeben (=Senden) des zumindest einen elektronischen Münzdatensatzes eine Protokollschnittstelle zum drahtlosen Senden des elektronischen Münzdatensatzes an das andere Sicherheitselement über eine Teilnehmereinheit mittels eines Kommunikationsprotokolls für Drahtloskommunikation. Dabei ist insbesondere eine Nahfeldkommunikation, beispielsweise mittels Bluetooth-Protokoll oder NFC-Protokoll oder IR-Protokoll vorgesehen, alternativ oder zusätzlich sind WLAN-Verbindungen oder Mobilfunkverbindungen denkbar. Der elektronische Münzdatensatz wird dann gemäß den Protokolleigenschaften angepasst oder in das Protokoll integriert und übertragen.
  • In einer bevorzugten Ausgestaltung ist die Schnittstelle zum Ausgeben des zumindest einen elektronischen Münzdatensatzes eine Datenschnittstelle zum Bereitstellen des elektronischen Münzdatensatzes an die andere Teilnehmereinheit mittels einer Applikation. Im Unterschied zur Protokollschnittstelle wird hier der elektronische Münzdatensatz mittels einer Applikation übertragen. Diese Applikation überträgt sodann den elektronischen Münzdatensatz in einem entsprechenden Dateiformat. Es kann ein für elektronische Münzdatensätze spezifisches Dateiformat verwendet werden. In einfachster Form wird der Münzdatensatz als ASCII-Zeichenfolge oder als Textnachricht, beispielsweise SMS, MMS, Instant-Messenger-Nachricht (wie Threema oder WhatsApp) übertragen. In einer alternativen Form wird der Münzdatensatz als APDU-Zeichenfolge übertragen. Es kann auch eine Geldbörsen-Applikation vorgesehen sein.
  • Hierbei stellen die austauschenden Teilnehmereinheiten bevorzugt sicher, dass ein Austausch mittels der Applikation möglich ist, also dass beide Teilnehmereinheiten die Applikation aufweisen und austauschbereit sind.
  • In einer bevorzugten Ausgestaltung weist die Teilnehmereinheit weiter eine Schnittstelle zum Empfangen von elektronischen Münzdatensätzen auf.
  • In einer bevorzugten Ausgestaltung ist die Schnittstelle zum Empfangen des zumindest einen elektronischen Münzdatensatzes ein elektronisches Erfassungsmodul des Sicherheitselements bzw. des Endgeräts, eingerichtet zum Erfassen eines, in visueller Form dargestellten elektronischen Münzdatensatzes. Das Erfassungsmodul ist dann beispielsweise eine Kamera oder ein Barcode bzw. QR-Code Scanner.
  • In einer bevorzugten Ausgestaltung ist die Schnittstelle zum Empfangen des zumindest einen elektronischen Münzdatensatzes eine Protokollschnittstelle zum drahtlosen Empfangen des elektronischen Münzdatensatzes von einem anderen Sicherheitselement bzw. Endgerät mittels eines Kommunikationsprotokolls für Drahtloskommunikation. Dabei ist insbesondere eine Nahfeldkommunikation, beispielsweise mittels Bluetooth-Protokoll oder NFC-Protokoll oder IR-Protokoll, vorgesehen. Alternativ oder zusätzlich sind WLAN-Verbindungen oder Mobilfunkverbindungen denkbar.
  • In einer bevorzugten Ausgestaltung ist die Schnittstelle zum Empfangen des zumindest einen elektronischen Münzdatensatzes eine Datenschnittstelle zum Empfangen des elektronischen Münzdatensatzes von der anderen Teilnehmereinheit mittels einer Applikation. Diese Applikation empfängt sodann den Münzdatensatz in einem entsprechenden Dateiformat. Es kann ein für Münzdatensätze spezifisches Dateiformat verwendet werden. In einfachster Form wird der Münzdatensatz als ASCII-Zeichenfolge oder als Textnachricht, beispielsweise SMS, MMS, Threema oder WhatsApp übertragen. In einer alternativen Form wird der Münzdatensatz als APDU-Zeichenfolge übertragen. Zusätzlich kann die Übertragung mittels einer Geldbörsen-Applikation erfolgen.
  • In einer bevorzugten Ausgestaltung umfassend die Teilnehmereinheit zumindest ein Sicherheitselement-Lesegerät, eingerichtet zum Lesen eines Sicherheitselements; einen Zufallszahlengenerator; und/oder eine Kommunikationsschnittstelle zu einem Tresormodul und/ oder Bankinstitut mit zu autorisierendem Zugriff auf ein Bankkonto.
  • In einer bevorzugten Ausgestaltung ist der Datenspeicher ein gemeinsamer Datenspeicher, auf den zumindest noch eine andere Teilnehmereinheit zugreifen kann, wobei jedes davon eine Applikation aufweist, wobei diese Applikation zum Kommunizieren mit dem Münzregister zum entsprechenden Registrieren von elektronischen Münzteildatensätzen eingerichtet ist.
  • Vorgeschlagen wird hierbei also eine Lösung, die digitales Geld in Form von elektronischen Münzdatensätzen herausgibt, die an die Verwendung von konventionellen (analogen) Banknoten und/oder Münzen angelehnt ist. Das digitale Geld wird hierbei durch elektronische Münzdatensätze abgebildet. Wie bei (analogen) Banknoten werden auch diese elektronischen Münzdatensätze für alle Formen von Zahlungen, einschließlich Peer-to-Peer-Zahlungen und/oder POS-Zahlungen, verwendbar. Die Kenntnis aller Bestandteile (insbesondere monetärer Betrag und Verschleierungsbetrag) eines gültigen elektronischen Münzdatensatzes ist gleichbedeutend mit dem Besitz (Eigentum) des digitalen Geldes. Es ist daher ratsam, diese gültigen elektronischen Münzdatensätze vertraulich zu behandeln, also beispielsweise in einem Sicherheitselement/ Tresormodul (eines Endgeräts) aufzubewahren und dort zu verarbeiten. Um über die Authentizität eines elektronischen Münzdatensatzes zu entscheiden und Doppelausgaben zu verhindern, werden in dem Münzregister maskierte elektronische Münzdatensätze als einzigartige, korrespondierende öffentliche Darstellung des elektronischen Münzdatensatzes vorgehalten. Die Kenntnis oder der Besitz eines maskierten elektronischen Münzdatensatzes stellt nicht den Besitz von Geld dar. Vielmehr gleicht dies dem Überprüfen der Echtheit des analogen Zahlungsmittels.
  • Das Münzregister enthält beispielsweise auch Markierungen über durchgeführte und geplante Verarbeitungen des maskierten elektronischen Münzdatensatzes. Aus den Markierungen zu den Verarbeitungen wird ein Status des jeweiligen maskierten elektronischen Münzdatensatzes abgeleitet, der angibt, ob der entsprechende (nicht maskierte) elektronische Münzdatensatz gültig, d.h. zahlungsbereit ist. Daher wird ein Empfänger eines elektronischen Münzdatensatzes zunächst einen maskierten elektronischen Münzdatensatz erzeugen und sich durch das Münzregister die Gültigkeit der maskierten elektronischen Münzdatensatz authentifizieren lassen. Ein großer Vorteil dieser erfindungsgemäßen Lösung ist, dass das digitale Geld auf Endgeräte, Händler, Banken und andere Nutzer des Systems verteilt wird, aber kein digitales Geld oder weitere Metadaten bei dem Münzregister oder dem Überwachungsregister - also gemeinsamer Instanzen - gespeichert wird.
  • Die vorgeschlagene Lösung kann in bestehende Zahlsysteme und Infrastrukturen eingebunden werden. Insbesondere können eine Kombination aus analogen Zahlungsvorgängen mit Geldscheinen und Münzen und digitale Zahlungsvorgänge gemäß der vorliegenden Lösung vorliegen. So kann ein Bezahlvorgang mit Banknoten und/ oder Münzen erfolgen, das Wechselgeld bzw. Rückgeld liegt aber als elektronischer Münzdatensatz vor. Zur Transaktion können beispielsweise ATMs mit entsprechender Konfiguration, insbesondere mit geeigneter Kommunikationsschnittstelle, und/ oder mobile Endgeräte vorgesehen sein. Weiterhin ist ein Umtausch von elektronischem Münzdatensatz in Banknoten bzw. Münzen denkbar.
  • Die vorliegend aufgeführten Schritte des Erstellens, Umschaltens, Aufteilens, Verbinden und Deaktivierens (Zurückgebens) werden jeweils durch einen entsprechenden Erstell-, Umschalt-, Aufteil-, Verbinden- bzw. Deaktivier-Befehl (Rückgabe-Befehle) ausgelöst.
  • Figurenliste
  • Nachfolgend wird anhand von Figuren die Erfindung bzw. weitere Ausführungsformen und Vorteile der Erfindung näher erläutert, wobei die Figuren lediglich Ausführungsbeispiele der Erfindung beschreiben. Gleiche Bestandteile in den Figuren werden mit gleichen Bezugszeichen versehen. Die Figuren sind nicht als maßstabsgetreu anzusehen, es können einzelne Elemente der Figuren übertrieben groß bzw. übertrieben vereinfacht dargestellt sein.
  • Es zeigen:
    • 1 a,b ein Ausführungsbeispiel eines Bezahlsystems gemäß dem Stand der Technik;
    • 2 ein Ausführungsbeispiel eines Bezahlsystems gemäß der Erfindung;
    • 3 eine Weiterbildung des Ausführungsbeispiels eines Bezahlsystems der 2;
    • 4a ein Ausführungsbeispiel eines Münzregisters des Bezahlsystems gemäß der Erfindung in einem ersten Modus;
    • 4b ein Ausführungsbeispiel des Münzregisters des Bezahlsystems gemäß der Erfindung in einem zweiten Modus;
    • 5 eine Weiterbildung des Ausführungsbeispiels eines Bezahlsystems der 2;
    • 6 ein Ausführungsbeispiel eines Verfahrensablaufdiagramms eines erfindungsgemäßen Verfahrens in einer Teilnehmereinheit;
    • 7 ein Ausführungsbeispiel eines Verfahrensablaufdiagramms eines erfindungsgemäßen Verfahrens in einem Transaktionsregister;
    • 8 ein Ausführungsbeispiel einer Verschlüsselung und Entschlüsselung eines Transaktionsdatensatzes;
    • 9 eine alternative Weiterbildung des Ausführungsbeispiels eines Bezahlsystems der 2;
    • 10 ein Ausführungsbeispiel einer Datenstruktur im Münzregister und Überwachungsregister;
    • 11 ein Ausführungsbeispiel eines Systems gemäß der Erfindung zum Aufteilen und Umschalten und Direkt-Übertragen von elektronischen Münzdatensätzen;
    • 12 ein Ausführungsbeispiel eines Bezahlsystems gemäß der Erfindung zum Verbinden von elektronischen Münzdatensätzen;
    • 13 ein Ausführungsbeispiel eines Verfahrensablaufdiagramms eines erfindungsgemäßen Verfahrens und entsprechenden Verarbeitungsschritte eines Münzdatensatzes;
    • 14 ein Ausführungsbeispiel eines Verfahrensablaufdiagramms eines erfindungsgemäßen Verfahrens und entsprechenden Verarbeitungsschritte eines Münzdatensatzes;
    • 15 ein Ausführungsbeispiel eines erfindungsgemäßen Sicherheitselements;
    • 16 ein Bezahlsystem gemäß der Erfindung;
    • 17 ein Ausführungsbeispiel eines Ablaufs von erfindungsgemäßen Bezahlvorgängen unter Überwachung der monetären Beträge pro Teilnehmereinheit; und
    • 18 ein Ausführungsbeispiel eines Ablaufs einer erfindungsgemäßen Bereichsbestätigung.
  • FIGURENBESCHREIBUNG
  • Die 1a und Fig.lb zeigen ein Ausführungsbeispiel eines Bezahlsystems BZ gemäß dem Stand der Technik. Diese 1a und 1b sind in der Beschreibungseinleitung bereits beschrieben. Wiederholend wird darauf hingewiesen, dass ein Endgerät M8 den Münzdatensatz Cc als den Münzdatensatz Ce an dem Münzregister 2 registrieren lassen möchte und das Münzregister 2 feststellt, dass der Münzdatensatz Cb bereits ungültig ist. In der Folge akzeptiert das Münzregister 2 weder den vermeintlich gültigen Münzdatensatz Cc noch den umzuschaltenden Münzdatensatz Ce.
  • Das Problem kann auftreten, wenn beispielsweise ein Angreifer mit Endgerät M1 einen Münzdatensatz Cb (unerlaubt) an zwei Endgeräte M2 und M3 direkt weitergibt. Sobald einer der zwei Teilnehmer mit Endgerät M2 den Münzdatensatz in dem Münzregister 2 auf sich registrieren lässt (sogenanntes Ummünzen), wird der Münzdatensatz Cb ungültig. Ein argloser Teilnehmer mit Endgerät M3 gibt stattdessen den Münzdatensatz Cb direkt an Endgerät M5 weiter, ohne ihn registrieren zu lassen. Erst das Endgerät M7 durchbricht die direkte Übertragungskette und zeigt den Münzdatensatz Cb beim Münzregister 2. Parallel dazu teilt der Teilnehmer mit Endgerät M2 den Münzdatensatz Cb in den Münzdatensatz Cc und Cx auf und gibt Ce direkt an Endgerät M4 weiter. Endgerät M4 gibt den Münzdatensatz Ce direkt an Endgerät M6 weiter. Endgerät M6 gibt den Münzdatensatz Cc direkt an Endgerät M8 weiter. Erst das Registrieren von Münzdatensatz Cc bei dem Münzregister 2 lässt die Ungültigkeit vom Münzdatensatz Cb und in der Folge das Double-Spending erkennen. Ein Angriff (doppeltes Ausgeben eines elektronischen Münzdatensatz) von M1 wird im Stand der Technik also erst spät entdeckt und es wurden eine Vielzahl von Direktübertragungen in unerlaubter Weise ausgeführt. Zudem steigt durch die Vielzahl von Transaktionen eines elektronischen Münzdatensatzes und auch durch die fortschreitende Lebensdauer das Risiko, dass an dem elektronischen Münzdatensatz Manipulation(en) vorgenommen wurden.
  • In einem Bezahlsystem soll daher bei Übersteigen einer gewissen Lebensdauer oder Anzahl von Aktionen insgesamt am/mit dem Münzdatensatz, der Münzdatensatz verfallen, also einerseits die Anzahl des direkten Übertragens von Münzdatensätzen limitiert werden und andererseits im Fall eines erkannten Angriffs nachvollzogen werden können, wer den Angriff (hier Endgerät M1) durchgeführt hat. Für eine Beweissicherung wird nachfolgend ein Verfahren/System beschrieben, bei dem Transaktionsdaten von Teilnehmereinheiten (Endgeräte bzw. Sicherheitselemente) in einem entfernten Transaktionsregister archiviert werden und bei behördlichem Beschluss, geprüft werden können.
  • Das erfindungsgemäße Bezahlsystem umfasst dazu zumindest zwei, bevorzugt eine Vielzahl von Teilnehmereinheiten TEs, die nachfolgend auch als Sicherheitselemente SEx bzw. Endgeräte Mx bezeichnet oder dargestellt sind und ein Transaktionsregister. Das Bezahlsystem kann darüber hinaus beispielsweise zumindest eine Herausgeberinstanz 1, eine oder mehrere Geschäftsbanken, ein (oder mehrere) zentrale Münzregister 2, die die Registrierung der Münzdatensätze vornimmt und die Modifikationen am Münzdatensatz prüft und protokolliert. Weitere erfindungsgemäße Beispiele für Bezahlsysteme sind in 6, 7, 14 und 16 dargestellt.
  • Die 2 zeigt ein Ausführungsbeispiel eines Bezahlsystems BZ gemäß der Erfindung. Die gestrichelt dargestellten Blöcke und Pfeile des Bezahlsystems BZ sind dabei optional. Das Bezahlsystem BZ umfasst zumindest zwei Sicherheitselemente SE1 und SE2. Die SE1 und SE2 können dabei in jeweiligen Endgeräten M1 und M2 betriebsbereit eingebracht und logisch oder physisch mit dem jeweiligen Endgerät M1 und M2 verbunden sein. Zudem ist ein Transaktionsregister 4 des Bezahlsystems BZ dargestellt.
  • Im Bezahlsystem der 2 ist optional zudem eine Herausgeberinstanz 1, beispielsweise eine Zentralbank vorgesehen, die den elektronischen Münzdatensatz C erzeugt. Zudem ist eine Personenzuordnung 7 vorgesehen. Zu dem elektronischen Münzdatensatz C wird ein Registerdatensatz RDS, beispielsweise ein maskierter elektronischer Münzdatensatz Z, erzeugt und in einem Münzregister 2 des Bezahlsystems registriert 104. Der elektronische Münzdatensatz C wird im Schritt 102 von der Herausgeberinstanz 1 an das erste Endgerät M1 ausgegeben. Der Registerdatensatz RDS, beispielsweise der maskierte elektronische Münzdatensatz Z, wird im Schritt 104 beispielsweise von der Herausgeberinstanz 1 direkt oder über das erste Endgerät M1 an das Münzregister 2 ausgegeben. Der Registerdatensatz RDS, beispielsweise der maskierte elektronische Münzdatensatz Z, wird alternativ vom ersten Endgerät M1 (oder zweiten Endgerät M2) erzeugt und an das Münzregister 2 im Schritt 104 gesendet.
  • Bei einer geplanten oder bereits durchgeführten Übertragung 105 eines elektronischen Münzdatensatzes C, wie es nachfolgend noch ausführlich beschrieben wird, wird im ersten Endgerät M1 ein Transaktionsdatensatz TDS erzeugt. Der Transaktionsdatensatz TDS weist eine Teilnehmer-ID des sendenden Endgeräts M1, eine Teilnehmer-ID des empfangenden Endgeräts M2, optional eine Transaktionsnummer, optional einen geldwerten Betrag des Münzdatensatzes, optional einen zum elektronischen Münzdatensatz C korrespondierenden maskierten Münzdatensatz Z (Maskierung wird später erläutert) und optional einen Transaktionszeitpunkt auf. Jede Teilnehmer-ID eines Endgeräts ist bezahlsystemweit einer natürlichen Person zugeordnet, was in der Personenzuordnung 7 durchgeführt und auch verwaltet wird. Diese Zuordnung 7 wird erst nach erfolgreicher Identifizierung der Person durch Vorlage eines Personalausweises oder Passes durchgeführt. Diese Zuordnung 7 kann auf Wunsch der Person geändert werden, beispielsweise bei Wechsel der Teilnehmereinheit oder Hinzufügen einer weiteren Teilnehmereinheit.
  • Nach der Erzeugung des Transaktionsdatensatzes TDS kann dieser von dem ersten Endgerät M1 mit einem kryptografischen Schlüssel verschlüsselt werden, dies ist in 5 ausführlicher dargestellt.
  • Als Ergebnis der Gerichtsentscheidung können die Transaktionsdaten ausgelesen werden
  • Das Bezahlsystem BZ der 2 führt demnach mindestens drei verschiedene Schichten für die münzdatensatzbasierte Übertragung ein. Diese Schichten bearbeiten unterschiedliche Aufgaben, haben unterschiedliche Interessengruppen, unterschiedliche Angriffsvektoren und unterschiedliche Implementierungen. Die Trennung dieser spezifischen Aufgaben innerhalb des Bezahlsystems BZ in isolierte Schichten reduziert die Komplexität innerhalb der einzelnen Schichten und macht das Bezahlsystem flexibler, sicherer und widerstandsfähiger gegenüber Angriffe. Der Vorteil dieses mehrschichtigen Bezahlsystems BZ besteht darin, dass datenschutzrelevanten Daten streng vom Rest des Bezahlökosystems getrennt sind und nur auf der Grundlage strikter organisatorischer Prozesse zugänglich gemacht werden.
  • Das in 2 gezeigte Bezahlsystem ist dreischichtig aufgebaut. In einer ersten Schicht, ist die Herausgeberinstanz 1, beispielsweise eine Zentralbank, für die Geldschöpfung und -vernichtung verantwortlich, wie später noch erläutert wird. Geschäftsbanken (nicht dargestellt) können Münzdatensätze C lagern, beispielsweise in Tresormodulen, die als hochsichere Module, beispielsweise als HSM, ausgestaltet sind. Diese Schicht verteilt Geld an Benutzer und sendet oder empfängt Geld an die/von der Zentralbank.
  • In dieser ersten Schicht ist auch die Personenzuordnung 7 angeordnet. Die Herausgeberinstanz 1 ist beispielsweise über eine Luftschnittstelle, beispielsweise Mobilfunk oder WLAN oder NFC für die TEs erreichbar. Das Bereitstellen von Teilnehmereinheiten TE muss regulatorischen Anforderungen genügen. Letztendlich sollten alle Teilnehmereinheiten TE von einer Instanz bereitgestellt werden, die zur Ausgabe von Teilnehmereinheiten TE berechtigt ist. In einer Ausgestaltung ist die Personenzuordnung (Personenregister 7) für das Verwalten persönlicher Identitäten der Nutzer (natürliche Person) zuständig. Technisch kann dies dadurch realisiert werden, dass jede Teilnehmereinheit mit einem individuellen Schlüssel und einem von ihrer Zwischen- oder Root-CA (Certificate Authority) signierten Zertifikat ausgestattet wird. Damit können nur von der Root-CA signierte Teilnehmereinheiten TE einen sicheren Kommunikationskanal aufbauen, und böswillige oder modifizierte Teilnehmereinheiten TE mit ungültigen Schlüsseln werden blockiert. Durch die eindeutige Seriennummer jedes Zertifikats kann eine Zuordnung zu einem bestimmten Benutzer hergestellt werden, wenn in dem Personenregister 7 die Beziehung zwischen Seriennummer und Benutzer aufgezeichnet sind.
  • In einer zweiten Schicht sind das Münzregister 2, das Überwachungsregister 6 und das Transaktionsregister 4 vorgesehen. Diese Schicht dient dem sicheren Ablauf der Prüfung der Münzdatensätze C, insbesondere der Gültigkeit, dem Vorhandensein des korrekten geldwerten Betrags und der Echtheit der im Umlauf befindlichen Münzdatensätze C und prüft, ob Münzdatensätze C doppelt ausgegeben wurden. Diese Schicht kann ein „Distributed-Network“ sein. Bis zu diesem Punkt in der zweiten Schicht ist das Bezahlsystem BZ vollständig privat. Standardmäßig sind Bezahltransaktionen nicht nachvollziehbar, also anonym. Das gilt sowohl für den Teilnehmer (Zahler, Zahlungsempfänger) als auch für den geldwerten Betrag (Bezahlbetrag).
  • Es gibt länderspezifische Anforderungen hinsichtlich der Rückverfolgbarkeit der elektronischen Münzdatensätze sowohl bezüglich der aktuellen Münzstände in den Teilnehmereinheiten TE als auch der bereits durchgeführten Transaktionen (Historie). Um ein Strafverfolgungssystem einzurichten und/oder, um anonyme - nicht-vertrauenswürdige Teilnehmer am Bezahlsystem BZ zuzulassen, ist das Transaktionsregister 4 vorgesehen. Es ist denkbar, dieses Transaktionsregister 4 vom Bezahlsystem BZ zu entkoppeln, um dem Prinzip der „Trennung der Belange“ zu folgen.
  • Der Einfachheit halber wird das Transaktionsregister 4 nachfolgend der zweiten Schicht des Bezahlsystems BZ zugeordnet.
  • Informationen, die für die Rückverfolgung eines Münzdatensatzes C relevant sind, werden in einem Transaktionsregister 4 (der zweiten Schicht) als „Trusted Entity“, also einer vertrauenswürdigen Instanz, gespeichert. Der Zweck des Transaktionsregisters 4 ist es, Datenelemente (Zahler, Zahlungsempfänger, geldwerter Betrag) der Bezahltransaktionen am Bezahlsystem 2 nachvollziehbar zu halten und Zahlungen mit den zugehörigen Teilnehmereinheiten TE, deren geldwerte Beträge und einen Transaktionszeitpunkt neben anderen Informationen zu verfolgen. Das Transaktionsregister 4 kann Transaktionen auf verschiedene Szenarien wie Geldwäsche, Terrorismusfinanzierung oder Steuerhinterziehung hin überwachen, aber auch die Nutzung eines einzelnen Münzdatensatzes analysieren. Im Transaktionsregister werden bevorzugt keine persönlichen Informationen einer natürlichen Person gespeichert, sondern lediglich Teilnehmereinheitenkennungen bzw. deren Pseudonyme.
  • Im Falle verdächtiger Aktivitäten kann so die Teilnehmereinheit ermittelt werden. Optional werden Teilnehmereinheiten nicht an natürliche Personen gebunden, um anonym zu bleiben. Hier wird die Teilnahme an das Bezahlsystem nur mit eingeschränkter Funktionalität oder Einschränkungen bei den geldwerten Beträgen zugelassen. Der Zugriff auf das Transaktionsregister kann streng kontrolliert werden, und die dort abgelegten TDS abzusichern. Vorteil dieses Aufbaus ist es, dass das unerlaubte Abgreifen aus dem Transaktionsregister keine Beschaffung von Geld darstellt und die geldwerten Beträge damit nicht gestohlen werden können. Das Transaktionsregister 4 ist als vertrauenswürdige Instanz dafür verantwortlich, die Privatsphäre der Menschen in regulären Situationen zu schützen und (verschlüsselte) Transaktionsdatensätze TDS offenzulegen, wenn dies aufgrund von Gerichtsentscheidungen erforderlich ist oder wenn dies vom Überwachungsregister 6 eingefordert wird. Damit kann geprüft werden, dass keine irregulären Transaktionen oder Geldoperationen stattfinden, insbesondere dass kein (neues) Geld illegal geschaffen oder vernichtet wird. Das Transaktionsregister 4 stellt einerseits eine Erweiterung für Anwendungsfälle in der Strafverfolgung dar, mit dem Ziel, verdächtige Transaktionsdaten aufzudecken. Das Transaktionsregister 4 stellt andererseits eine Erweiterung für Anwendungsfälle dar, bei denen Teilnehmereinheiten sich nicht beim Münzregister 2 authentisieren können oder wollen. Das Transaktionsregister 4 speichert (verschlüsselte) Datensätze über Transaktionen TDS, die von den beteiligten Teilnehmern gemeldet werden (müssen) und gibt sie nach einem ordnungsgemäßen Verfahren an die Behörden oder das Überwachungsregister 6 des Bezahlsystems BZ weiter. In dem Transaktionsregister 4 können die Transaktionsdatensätze TDS in verschlüsselter Form gespeichert werden. Dadurch wird sichergestellt, dass ein ordnungsgemäßes Verfahren eingehalten werden muss und niemand auf diese sensible Transaktionsdaten nach Belieben zugreifen kann. Zusätzlich kann im Transaktionsregister 4 eine Re-Verschlüsselungs-Einheit eingesetzt werden, die eine Umverschlüsselung der TDS durchführt, so dass eine Strafverfolgungsbehörde nur Zugang zu den behördlich genehmigten Daten erhält. Metadaten, wie Transaktionszeitpunkt und Teilnehmer-ID, dienen dazu, die angefragten Daten bereitzustellen. Die Umverschlüsselungseinheit des Transaktionsregisters 4 kann auf alle Daten zugreifen und diese entschlüsseln.
  • Die dritte Schicht ist eine Direkttransaktionsschicht 3, an der alle Teilnehmer, also Verbraucher, Händler, etc. gleichermaßen über ihre Teilnehmereinheiten TE teilnehmen, um elektronische Münzdatensätze C auszutauschen. Jede Teilnehmereinheit TE kann eine Geldbörse-Applikation aufweisen, um Münzdatensätze C zu verwalten. Die Münzdatensätze C können lokal in der Teilnehmereinheit TE abgelegt sein oder diese sind in einem Online-Speicher (=Cloud-Speicher) abgelegt und die Teilnehmereinheit TE kann diese fernverwalten. Im Falle eines Offline-Szenarios, bei dem eine Übertragung 105 ohne Kontrollinstanzen bzw. Registerinstanzen 2, 4, 6 des Bezahlsystems BZ erfolgen, können Teilnehmereinheiten TE unmittelbar (direkt) mit anderen Teilnehmereinheiten TE interagieren. Die tatsächliche Datenübertragung für eine Münzdatensatz kann weitere dazwischengeschaltete Instanzen umfassen. Dieses Offline-Design des Bezahlsystems BZ macht es erforderlich, dass die Münzdatensätze C in zertifizierten Bereichen, beispielsweise einer Geldbörsen-Applikation aufbewahrt werden, idealerweise innerhalb von Sicherheitselementen SE, beispielsweise Smartcards oder einer eSim Umgebung, um eine Vertrauenswürdigkeit im Bezahlsystem BZ zu erhalten.
  • Um einen elektronischen Münzdatensatz C zu erzeugen wird folgendes Verfahren vorgeschlagen.
  • Die Übertragung 105 erfolgt beispielsweise drahtlos über WLAN, NFC oder Bluetooth, also bevorzugt lokal. Die Übertragung 105 kann durch kryptografische Verschlüsselungsverfahren zusätzlich abgesichert sein, indem beispielsweise ein Sitzungsschlüssel ausgehandelt wird oder eine PKI-Infrastruktur angewendet wird. Die Übertragung 105 kann auch unter Einbeziehen eines Online-Datenspeichers erfolgen, aus dem der elektronische Münzdatensatz C an das TE2 (M2, SE2) übertragen wird.
  • Im Übertragenschritt 105 wird beispielsweise ein sicherer Kanal zwischen dem SE1 und dem SE2 aufgebaut, in dessen Rahmen beide SEs sich gegenseitig authentifizieren. Die Übertragungsstrecke zwischen SE1 und SE2 ist nicht zwingend unmittelbar direkt, sondern kann eine Internet- oder auch Nahfeldkommunikationsstrecke mit dazwischengeschalteten Instanzen (Endgeräte, Router, Switches, Applikationen) sein. Durch die Verwendung von SEs als sichere Umgebung anstelle von Endgeräten ME als TEs wird eine höhere Vertrauensstufe, englisch Level-of-Trust, erzeugt, also eine Vertrauenswürdigkeit im Bezahlsystem BZ erhöht. Gleichzeitig mit dem Senden des eMD C bzw. unmittelbar davor oder danach wird optional ein Timer gestartet. Zuvor kann der eMD C invalidiert werden und dann nicht mehr vom SE1 für Aktionen (wie unten beschrieben) verwendet werden. Der eMD C ist damit im Bezahlsystem BZ blockiert aufgrund eines bereits angestoßenen (und noch nicht beendeten) Übertragungsvorgang 105. Damit wird ein Doublespending unterbunden. Das Invalidieren ermöglicht eine einfache Handhabung während des Übertragungsvorgangs 105.
  • Bei ordnungsgemäßem Empfang des eMD C im SE2 wird vom SE2 eine Empfangsbestätigung generiert und an das SE1 zurückgesendet. Die Empfangsbestätigung vom SE2 kann als eine Löschungsaufforderung gesendet werden, denn erst nach dem Löschen der eMD C im SE1 kann (darf) die eMD C im SE2 validiert und verwendet werden. Optional kann das Löschen des eMD C vom SE1 angezeigt werden. Dabei wird beispielsweise eine Betragsanzeige des SE1 (oder eines Endgeräts ME1, in dem sich das SE1 logisch befindet) aktualisiert. Beispielsweise wird der monetäre Betrag des eMD C von einem für Bezahltranskationen zur Verfügung stehenden Betrag des SE1 subtrahiert. Es kann eine Löschbestätigung vom SE1 an das SE2 versendet werden. Dies dient einer Quittierung, dass der eMD C im SE1 nicht mehr vorhanden ist und somit im SE2 validiert werden kann. Mit Erhalt der Löschbestätigung im SE2 kann das SE2 einen Status des eMD C im SE2 in einen Aktiv-Status umsetzen, die eMD C ist damit validiert und kann ab diesem Zeitpunkt für weitere Bezahltranskationen oder Aktionen (Aufteilen, Kombinieren, Umschalten) im SE2 verwendet werden. Optional wird das eMD C des SE2 im Münzregister 2 auf das SE2 umgeschaltet (siehe unten), wodurch das eMD C auf das SE2 registriert ist (Schritt 104).
  • Ein Übertragungs-Fehlerfall des Übertragens 105 kann im SE1 festgestellt werden, beispielsweise durch Überschreiten einer vordefinierten Zeitdauer, indiziert durch einen Timer oder durch das Empfangen einer Fehlermeldung vom SE2 oder dem Endgerät M1 bzw. dem anderen Endgerät M2 (nicht dargestellt). Beispielsweise kann mit jedem erneuten Sendeversuch zum Übertragen des eMD C (RETRY) ein Zählerwert inkrementiert werden und bei Überschreitung einer maximal zulässigen Anzahl von Wiederholungsversuchen, beispielsweise 10 oder 5 oder 3 mal, wird im Schritt 308 automatisch und unabhängig vom Fehlerfall entschieden, dass kein erneuter Sendeversuch (RETRY) durchgeführt wird, sondern das Übertragen 105 als erfolglos zu beenden ist und ein ROLLBACK zu erfolgen hat.
  • In einer alternativen Ausgestaltung des Übertragen-Verfahrens 105 wird der Status des eMD vom SE1 an das Münzregister 2 gemeldet. Dann wird eine Verbindung mit dem Münzregister 2 zur Statusabfrage zu dem eMD C aufgebaut. Wenn das Münzregister 2 weiterhin einen inaktiven Status zum eMD C (registriert auf das SE1) zurückmeldet, wird kein Transaktionsfehler (Manipulationsversuch) angenommen. Wenn das Münzregister 2 aber einen aktiven Status zum eMD C oder eine Registrierung auf einen anderen SE zurückmeldet, wird ein Transaktionsfehler (Manipulationsversuch) angenommen und das Bezahlsystem alarmiert. Zum Beleg wird der Transaktionsdatensatz TDS des SE1 verwendet.
  • Der elektronischer Münzdatensatz C kann vorab bei einer Herausgeberinstanz 1 angefragt und optional von einem Endgerät M (oder einem SE) oder der Herausgeberinstanz 1 oder einem anderen Bezahlsystem empfangen werden. Die Schritte 104 und 105 können den Schritten 104 und 105 der 11 entsprechen. Eine Aktion (Aufteilen, Verbinden, Umschalten, Übertragen, Einlösen, Wechseln) am eMD C kann einer der Aktionen der 9 bis 12 entsprechen.
  • Beispielsweise wird als Verschleierungsbetrag ri eine echte Zufallszahl erzeugt. Der Verschleierungsbetrag ri ist zwar in der Direkttransaktionsschicht 3 und auch in der Herausgeberinstanz 1 bekannt, aber für das Transaktionsregister 4, das Überwachungsregister 6 und das Münzregister 2 geheim. Der Verschleierungsbetrag ri wird mit einem monetären Betrag υi verknüpft. Ein erfindungsgemäßer i-ten elektronischen Münzdatensatz könnte demnach lauten: C i = { υ i ; r i }
    Figure DE102020004122A1_0001
  • Zusätzlich zu diesen Datenelementen kann der elektronische Münzdatensatz C zumindest einen Prüfwert umfassen. Der Prüfwert bildet beispielsweise die Anzahl von Offline-Übertragungen (Bezahltransaktionen) mit diesem elektronischen Münzdatensatz ab. Der Prüfwert bildet beispielsweise die Anzahl von Offline-Übertragungen (Bezahltransaktionen) der Teilnehmereinheit ohne Durchführen eines Registrierens ab.
  • Zusätzlich zu diesen Datenelementen kann der elektronische Münzdatensatz C eine Münzkennung M-ID umfassen. Die Münzkennung ist beispielsweise eine eindeutige Nummer, die im Bezahlsystem BZ einmalig ist. Beispielsweise ist die Münzkennung M-ID eine von der Teilnehmereinheit oder der Herausgeberinstanz 1 generierte Zufallszahl.
  • Ein gültiger elektronischer Münzdatensatz kann zur Bezahlung eingesetzt werden. Der Besitzer der beiden Werte υi und ri ist daher im Besitz des digitalen Geldes. Das digitale Geld ist definiert durch ein Paar bestehend aus einem gültigen elektronischen Münzdatensatz Ci und einem entsprechenden maskierten elektronischen Münzdatensatz Zi. Ein Registerdatensatz, kurz RDS wird dem elektronischen Münzdatensatz zugeordnet.
  • Beispielsweise wird ein maskierter elektronischer Münzdatensatz Zi als RDS, durch Anwenden einer homomorphen Einwegfunktion f (Ci) gemäß Gleichung (2) erhalten: Z i = ƒ ( C i )
    Figure DE102020004122A1_0002
  • Diese Funktion f(Ci) ist öffentlich, d.h. jeder Systemteilnehmer kann diese Funktion aufrufen und verwenden. Diese Funktion f(Ci) ist gemäß Gleichung (3) definiert: Z i = υ i ⋅ H + r i ⋅ G
    Figure DE102020004122A1_0003
    wobei H und G Generatorpunkte einer Gruppe G, in der das diskrete Logarithmusproblem schwer ist, mit den Generatoren G und H, für die der diskrete Logarithmus der jeweils anderen Basis unbekannt ist. Beispielsweise sind G und H Generatorpunkte einer elliptischen Kurvenverschlüsselung, ECC, - also private Schlüssel der ECC, sind. Diese Generatorpunkte G und H müssen in der Art gewählt werden, dass der Zusammenhang von G und H nicht öffentlich bekannt ist, sodass bei: G = n ⋅ H
    Figure DE102020004122A1_0004
    die Verknüpfung n praktisch nicht auffindbar sein darf, um zu verhindern, dass der monetäre Betrag υi manipuliert wird und trotzdem ein gültiges Zi berechnet werden könnte. Die Gleichung (3) ist ein „Pederson-Commitment für ECC“, das sicherstellt, dass der monetäre Betrag υi einem Münzregister 2 zugestanden, also „commited“, werden kann, ohne diesen dem Münzregister 2 zu offenbaren.
  • Alternativ kann der RDS neben dem maskierten Münzdatensatz Zi auch noch eine Betragskategorie umfassen. Die Betragskategorie ist eine pseudonymisierte Form des geldwerten Betrags υi des elektronischen Münzdatensatzes C. Beispielsweise ist die Betragskategorie eine Bereichsangabe (von bis), in der der geldwerte Betrag υi liegt. Beispielsweise ist die Betragskategorie ein Bereichsschwellwert (größer als; kleiner als), oberhalb bzw. unterhalb dessen der geldwerte Betrag υi liegt. Beispielsweise ist die Betragskategorie ein abgerundeter Wert des geldwerten Betrags υi Beispielsweise ist die Betragskategorie ein aufgerundeter Wert des geldwerten Betrags υi Damit ist das RDS betragspseudonym und identitätsanonym.
  • Alternativ kann der RDS neben oder anstelle dem maskierten Münzdatensatz Zi eine Münzkennung M-ID umfassen. Damit ist im RDS ein eindeutiger Bezug zum elektronischen Münzdatensatz C geschaffen.
  • Alternativ kann der RDS ein Pseudonym P der Teilnehmereinheit umfassen. Das Pseudonym kann in der Personenzuordnung 7 verwaltet sein. Damit ist das RDS betragsanonym und identitätspseudonym. In dieser Ausgestaltung kann das RDS einen Prüfwert p des Münzdatensatzes mit umfassen.
  • Nachfolgend kann der Einfachheit halber ein RDS mit einem maskierten Münzdatensatz Z gleichgesetzt werden, da dies eine sehr bevorzugte Ausgestaltung ist.
  • Dem Münzregister 2 wird daher nur der RDS, beispielsweise der maskierte Münzdatensatz Zi zugesendet (offenbart), was in 2 als Schritt 104 (Registrieren, Registrierungsanforderung) dargestellt ist.
  • Auch wenn im vorliegenden Beispiel eine Verschlüsselung basierend auf elliptischen Kurven beschrieben ist bzw. wird, so wäre auch ein anderes kryptographisches Verfahren denkbar, welches auf einem diskreten logarithmischen Verfahren beruht.
  • Die Gleichung (3) ermöglicht durch die Entropie des Verschleierungsbetrags ri, dass auch bei kleinem Wertebereich für monetäre Beträge υi ein kryptografisch starkes Zi erhalten wird. Somit ist ein einfacher Brute-Force-Angriff durch bloßes Schätzen von monetären Beträgen υi praktisch nicht möglich.
  • Die Gleichung (3) ist eine Einwegfunktion, das heißt, dass die Berechnung von Zi aus Ci einfach ist, da ein effizienter Algorithmus existiert, wohingegen die Berechnung von Ci ausgehend von Zi sehr schwer ist, da kein in polynomialer Zeit lösbarer Algorithmus existiert.
  • Zudem ist die Gleichung (3) homomorph für Addition und Subtraktion, das heißt es gilt: Z i + Z j = ( υ i ⋅ H + r i ⋅ G ) + ( υ j ⋅ H + r j ⋅ G ) = ( υ i + υ j ) ⋅ H + ( r i + r j ) ⋅ G
    Figure DE102020004122A1_0005
  • Somit können Additions-Operationen und Subtraktions-Operationen sowohl in der Direkttransaktionsschicht 3 also auch parallel in dem Münzregister 2 ausgeführt werden, ohne dass das Münzregister 2 Kenntnis von den elektronischen Münzdatensätzen Ci hat. Die homomorphe Eigenschaft der Gleichung (3) ermöglicht eine Überwachung von gültigen und ungültigen elektronischen Münzdatensätzen Ci auf alleiniger Basis der maskierten Münzdatensätze Zi zu führen und sicherzustellen, dass kein neuer monetärer Betrag υj geschaffen wurde.
  • Durch diese homomorphe Eigenschaft kann der Münzdatensatz Ci gemäß Gleichung (1) aufgeteilt werden in: C i = C j + C k = { υ j ; r j } + { υ k ; r k }
    Figure DE102020004122A1_0006
    wobei gilt: υ i = υ j + υ k
    Figure DE102020004122A1_0007
     r i = r j + r k
    Figure DE102020004122A1_0008
  • Für die entsprechenden maskierten Münzdatensätze gilt: Z i = Z j + Z k
    Figure DE102020004122A1_0009
  • Mit Gleichung (9) kann beispielsweise auf einfache Weise eine „symmetrische oder asymmetrische Aufteilen“-Verarbeitung bzw. ein „symmetrischer oder asymmetrischer Aufteilen“-Verarbeitungsschritt eines Münzdatensatzes gemäß 11 oder 14 geprüft werden, ohne dass das Münzregister 2 Kenntnis von Ci, Cj, Ck hat. Insbesondere wird die Bedingung der Gleichung (9) geprüft, um aufgeteilte Münzdatensätze Cj und Ck für gültig zu erklären und den Münzdatensatz Ci für ungültig zu erklären. Ein derartiges Aufteilen eines elektronischen Münzdatensatzes Ci ist in 11 oder 14 gezeigt.
  • Auf die gleiche Weise können elektronische Münzdatensätze C auch zusammengefügt (verbunden) werden, siehe dazu 12 oder 13 und die Erläuterungen dazu.
  • Zusätzlich gilt es zu prüfen, ob (nicht erlaubte) negative monetäre Beträge registriert werden. Ein Besitzer eines elektronischen Münzdatensatzes Ci muss dabei dem Münzregister 2 und/oder einem Überwachungsregister 6 nachweisen können, dass alle monetären Beträge υi in einer Verarbeitungs-Operation innerhalb eines Wertebereichs von [0, ..., n] liegen, ohne dem Münzregister 2 dabei die monetären Beträge υi mitzuteilen. Diese Bereichsnachweise werden auch „Range-Proofs“ genannt. Als Bereichsnachweise werden bevorzugt Ringsignaturen (engl. ring signature) verwendet. Für das vorliegende Ausführungsbeispiel werden sowohl der monetäre Betrag υ als auch der Verschleierungsbetrag r eines elektronischen Münzdatensatzes C in Bitdarstellung aufgelöst. Es gilt: υ i = ∑ a j ⋅ 2 j f u ¨ r 0 ≤ j ≤ n und a j ∈ { 0 ; 1 }
    Figure DE102020004122A1_0010
    sowie r i = ∑ b j ⋅ 2 j f u ¨ r 0 ≤ j ≤ n und b j ∈ { 0 ; 1 }
    Figure DE102020004122A1_0011
  • Für jedes Bit wird vorzugsweise eine Ringsignatur mit C ij = a j ⋅ H + b j ⋅ G
    Figure DE102020004122A1_0012
    und C ij − a j ⋅ H
    Figure DE102020004122A1_0013
    durchgeführt, wobei in einer Ausgestaltung vorgesehen sein kann, nur für bestimmte Bits eine Ringsignatur durchzuführen.
  • Gemäß 2 kann in dem elektronischen Münzdatensatz C zusätzlich noch mindestens ein Prüfwert pi1 als weiteres Datenelement geführt werden. Dieser Prüfwert pi1 wird bei jeder direkten Übertragung 105 dieses elektronischen Münzdatensatzes C zwischen Teilnehmereinheiten TE1, TE2, also Endgeräten M1, M2 oder Sicherheitselementen SE1, SE2 als Teilnehmereinheiten TE1, TE2 inkrementiert.
  • Im Bezahlsystem BZ kann zudem ein Zählerwert pi2 geführt oder bestimmt werden, der den Prüfwert pi1 einbezieht, beispielsweise als Summe des bisherigen (registrierten) Zählerwerts pi2 und des Prüfwerts pi1, um zu bestimmen, ob der Münzdatensatz C zurückzugeben ist. Jede Aktion mit dem Münzdatensatz C erhöht diesen Zählerwert pi2. Verschiedene Aktionstypen gewichten den Zählerwert pi2 unterschiedlich, sodass beispielsweise eine direkte Weitergabe des Münzdatensatzes C ein höheres Gewicht hat als eine Modifikation (Aufteilen, Kombinieren, Umschalten). Auf diese Weise wird die Lebensdauer und die darin geführten Aktionen eines Münzdatensatzes C bewertet und Kriterien für dessen Rückgabe entsprechend der geführten Aktionen definiert. Der Prüfwert pi1 und auch der Zählerwert pi2 bilden den Lebenszyklus des Münzdatensatzes C ab, anhand dessen dann über eine Rückgabe entschieden wird.
  • Im Bezahlsystem BZ kann in einer Teilnehmereinheit TE (also den in 2 dargestellten Endgeräten M1, M2 oder Sicherheitselementen SE1, SE2) zudem auch noch ein Prüfwert p vorgesehen, der die Anzahl bereits übertragener Münzdatensätze C ohne (unmittelbares) dazugehöriges Senden eines verschlüsselten Transaktionsdatensatzes TDS an das Transaktionsregister 4 repräsentiert. Dieser Prüfwert p wird bei Feststellen eines Verbindungsfehlers (im Schritt 307 der 6) mit einem Schwellwert X verglichen. Dabei wird festgestellt, ob eine weitere (Offline) Übertragung 105 durchgeführt werden darf (Bezahlsystemvorgabe) oder nicht.
  • In 2 ist das Transaktionsregister 4 dargestellt. Das Transaktionsregister 4 steht mit dem Überwachungsregister 6 in Kommunikationsverbindung, um die RDS oder anonymisierte bzw. pseudonymisierte Transaktionsdatensätze TDS* im Überwachungsregister 6 zu registrieren. Dazu wird (gemäß Schritt 410 der 7) beispielsweise eine Teilnehmereinheiten-Kennung im entschlüsselten Transaktionsdatensatz TDS durch ein Pseudonym P der Teilnehmereinheit TE ersetzt. Zudem wird (gemäß Schritt 411 der 7) beispielsweise zusätzlich oder alternativ (zum Schritt 410 der 7) ein geldwerter Betrag im Transaktionsdatensatz TDS durch eine Betragskategorie ersetzt. Dies (Schritte 410 und/oder 411 der 7) kann von einem HSM im Transaktionsregister 4 durchgeführt werden. Die pseudonymisierten Transaktionsdaten TDS* und/oder die betragskategorisierten Transaktionsdaten TDS* werden (gemäß Schritt 412 der 7) an das Überwachungsregister 6 gesendet, während die von der Teilnehmereinheit TE erzeugten Transaktionsdatensätze TDS im Transaktionsregister 4 abgelegt sind.
  • In 2 wird vom elektronischen Münzdatensatz Ci ein RDS, beispielsweise mittels der Gleichung (3) ein maskierter elektronischer Münzdatensatz Zi, beispielsweise im SE1, errechnet und dieser RDS wird zusammen mit dem Prüfwert pi in einem Überwachungsregister 6 registriert.
  • Im SE2 wird der übertragene elektronische Münzdatensatz Ci als Ci* erhalten. Mit dem Erhalt des elektronischen Münzdatensatzes Ci* ist das SE2 im Besitz des digitalen Geldes, den der elektronische Münzdatensatz Ci* repräsentiert. Mit der direkten Übertragung 105 steht es dem SE2 für weitere Aktionen zur Verfügung.
  • Aufgrund der höheren Vertrauenswürdigkeit bei der Verwendung von SEs können sich SE1, SE2 gegenseitig vertrauen und es sind prinzipiell keine weiteren Schritte für das Übertragen 105 notwendig. Allerdings ist dem SE2 nicht bekannt, ob der elektronische Münzdatensatz Ci* tatsächlich gültig ist. Zur weiteren Absicherung des Übertragens 105 können weitere Schritte im Verfahren vorgesehen sein, wie nachfolgend erläutert wird.
  • Zum Prüfen der Validität des erhaltenen elektronischen Münzdatensatzes Ci* kann im SE2 mit der - öffentlichen - Einwegfunktion aus Gleichung (3) ein weiterer RDS, beispielsweise der maskierte übertragene elektronische Münzdatensatz Zi*, errechnet werden. Der RDS, also beispielsweise der maskierte übertragene elektronische Münzdatensatz Zi* wird dann an das Münzregister 2 im Schritt 104 übertragen und dort gesucht. Bei Übereinstimmung beider RDS bezüglich des gleichen Münzdatensatzes C, also beispielsweise einer Übereinstimmung mit einem registrierten und gültigen maskierten elektronischen Münzdatensatz Zi, wird dem SE2 die Validität des erhaltenen Münzdatensatzes Ci* angezeigt und es gilt, dass der erhaltene elektronische Münzdatensatz Ci* gleich dem registrierten elektronischen Münzdatensatz Ci ist. Mit der Prüfung auf Validität kann in einer Ausgestaltung festgestellt werden, dass der erhaltene elektronische Münzdatensatz Ci* noch gültig ist, d.h., dass er nicht bereits durch einen anderen Verarbeitungsschritt oder bei einer anderen Transaktion/Aktion bereits verwendet wurde und/ oder einer weiteren Veränderung unterworfen war.
  • Bevorzugt findet danach ein Umschalten (=Switch) des erhaltenen elektronischen Münzdatensatzes statt.
  • Die alleinige Kenntnis eines RDS, also beispielsweise eines maskierten elektronischen Münzdatensatzes Zi, berechtigt nicht dazu, das digitale Geld des korrespondierenden elektronischen Münzdatensatzes Ci auszugeben.
  • Die alleinige Kenntnis des elektronischen Münzdatensatzes Ci berechtigt zum Bezahlen, d.h. eine Transaktion erfolgreich durchzuführen, insbesondere wenn der Münzdatensatz Ci gültig ist, beispielsweise wenn der elektronische Münzdatensatz Ci einen aktiven Status aufweist. Der Status wird bevorzugt erst bei Erhalt der Löschbestätigung des SE1 in einen Aktiv-Status gesetzt. Es herrscht eine eineindeutige Beziehung zwischen den elektronischen Münzdatensätzen Ci und den entsprechenden maskierten elektronischen Münzdatensätzen Zi. Die maskierten elektronischen Münzdatensätze Zi werden in dem Münzregister 2, beispielsweise einer öffentlichen Datenbank, registriert. Durch dieses Registrieren 104 wird zunächst die Gültigkeit des elektronischen Münzdatensatzes Ci prüfbar, beispielsweise ob neue monetäre Beträge (illegaler Weise) erschaffen wurden.
  • Die maskierten elektronischen Münzdatensätze Zi werden in dem Münzregister 2 gespeichert. Alle Verarbeitungen an dem elektronischen Münzdatensatz Zi werden dort oder in dem Überwachungsregister 6 registriert, wohingegen die tatsächliche Übertragung des digitalen Geldes in einer (geheimen, d.h. einer der Öffentlichkeit nicht bekannten) Direkttransaktionsschicht 3 des Bezahlsystems BZ erfolgt. Zudem können in diesem Bezahlsystem BZ Überwachungen am Münzdatensatz C und der Teilnehmereinheit TE in einem Überwachungsregister 6 erfasst werden.
  • Um ein mehrfaches Ausgeben zu verhindern oder um ein flexibleres Übertragen 105 zu gewährleisten, können die elektronischen Münzdatensätze C modifiziert werden. In der nachfolgenden Tabelle 1 sind beispielhafte Operationen aufgelistet, wobei mit dem angegebenen Befehl auch ein entsprechender Verarbeitungsschritt ausgeführt wird: Tabelle 1 - Anzahl von pro Verarbeitung eines C im TE bzw. der Herausgeberinstanz durchführbaren Operationen
    Befehl bzw. Schritt Signatur erstellen Zufallszahl erstellen Maskierung erstellen Bereichsnachweis erstellen
    Erzeugen 1 1 1 0 oder 1
    Zurückgeben 1 0 1 0 oder 1
    Aufteilen 1 1 3 0 oder 1
    Verbinden 1 0 3 1
    Umschalten 1 1 2 1
  • Weitere Operationen, die in Tabelle 1 nicht aufgeführt sind, können benötigt werden, beispielsweise das Wechseln der Währung oder das Einlösen des monetären Betrags auf einem Konto. Anstelle der angeführten Implementierung sind auch andere Umsetzungen denkbar, die andere Operationen implizieren. Die Tabelle 1 zeigt, dass für jeden Münzdatensatz, jede der Verarbeitungen (Modifikationen) „Erstellen“, „Zurückgeben“, „Aufteilen“, „Verbinden“ und „Umschalten“ verschiedene Operationen „Signatur erstellen“; „Zufallszahl erstellen“; „Maskierung erstellen“; „Bereichsprüfung“ vorgesehen sein können, wobei jede der Verarbeitungs-Operation in dem Münzregister 2 registriert wird. Alternativ und bevorzugt wird jede der Verarbeitungs-Operation in dem Überwachungsregister 6 in unveränderlicher Form an eine Liste vorheriger Verarbeitungs-Operationen für maskierte elektronische Münzdatensätze Zi angehängt. Das Überwachungsregister 6 stellt damit ein Archiv für RDS betreffend vorhergehende Münzdatensätze dar. Die Operationen der Verarbeitungen „Erstellen“ und „Zurückgeben“ eines elektronischen Münzdatensatzes C werden nur an sicheren Orten und/oder nur von ausgewählten Instanzen, beispielsweise der Herausgeberinstanz 1, ausgeführt, während die Operationen aller übrigen Verarbeitungen auf den Teilnehmereinheiten TE, also den Endgeräten M bzw. deren Sicherheitselementen SE ausgeführt werden können.
  • Die Anzahl der Operationen für die einzelnen Verarbeitungen ist in der Tabelle 1 mit „0“, „1“ oder „2“ gekennzeichnet. Die Anzahl „0“ zeigt dabei an, dass ein Teilnehmereinheit TE oder die Herausgeberinstanz 1 diese Operation für diese Verarbeitung des elektronischen Münzdatensatzes C nicht durchführen muss. Die Anzahl „1“ zeigt dabei an, dass das Teilnehmereinheit TE bzw. die Herausgeberinstanz 1 diese Operation für diese Verarbeitung des elektronischen Münzdatensatzes C einmal durchführen können muss. Die Anzahl „2“ zeigt dabei an, dass das Teilnehmereinheit TE bzw. die Herausgeberinstanz 1 diese Operation zweimal für diese Verarbeitung des elektronischen Münzdatensatzes durchführen können muss.
  • Grundsätzlich kann in einer Ausgestaltung auch vorgesehen sein, dass eine Bereichsprüfung durch die Herausgeberinstanz 1 auch beim Erzeugen und/ oder Löschen durchgeführt wird.
  • In der nachfolgenden Tabelle 2 sind für die einzelnen Verarbeitungen die für das Münzregister 2 und/oder das Überwachungsregister 6 benötigten Operationen aufgelistet: Tabelle 2 - Anzahl pro Verarbeitung eines C in dem Münzregister durchführbaren Operationen
    Befehl bzw. Schritt Signatur vom Herausgeber prüfen Signatur vom Sicherheit selement prüfen Gültigkeit des maskierten elektronischen Münzdatensatze s prüfen Bereichsnachweis nachvollziehen homomorphe Eigenschaften der maskierten elektronischen Münzdatensätze nachvollziehen, d.h. Addieren oder Subtrahieren
    Erzeugen 1 0 0 0 oder 1 0
    Zurückgeben 1 0 1 0 oder 1 0
    Aufteilen 0 1 1 2 oder mehr 1
    Verbinden 0 1 2 oder mehr 1 1
    Umschalten 0 1 1 1 0
  • Weitere Operationen, die in Tabelle 2 nicht aufgeführt sind, können benötigt werden. Anstelle der angeführten Implementierung sind andere Umsetzungen denkbar, die andere Operationen implizieren. Alle Operationen der Tabelle 2 können in dem Münzregister 2 durchgeführt werden, die als vertrauenswürdige Instanz, beispielsweise als Serverinstanz, beispielsweise als Distributed-Trusted-Server, für eine ausreichende Integrität der elektronischen Münzdatensätze C sorgt.
  • Die Tabelle 3 zeigt die für die Systemteilnehmer im Bezahlsystem der 1 bevorzugt zu installierenden Komponenten: Tabelle 3 - Bevorzugte Einheiten in den Systemkomponenten
    Befehl bzw. Schritt Herausgeberinstanz Teilnehmer einheit Münzregister/Über wachungsregister/T ransaktionsregister
    Zufallszahlgenerator (hohe Sicherheit) Ja - -
    Zufallsgenerator (deterministisch) - Ja -/-/Ja
    PKI zum Signieren Ja Ja -/-/Ja
    PKI zur Signaturprüfung - (Ja) Ja
    Lesezugriff Ja Ja Ja
    Schreibzugriff Ja Ja Ja
    Zurückgeben des elektronischen Münzdatensatzes Ja Ja -
    Transportverschlüsselung Ja Ja -/-/Ja
    Sicherer Speicher (Ja) Ja -/-/Ja
    Maskierungs-Einheit Ja Ja -
    Bereichsnachweis - Ja -
    Bereichsnachweis prüfen - - Ja/Ja/-
  • Tabelle 3 zeigt eine Übersicht über die bevorzugt zu verwendenden Komponenten in jedem Systemteilnehmer, also der Herausgeberinstanz 1, einer Teilnehmereinheit TE und den Registerinstanzen, nämlich dem Münzregister 2, dem Überwachungsregister 6, dem Transaktionsregister 4.
  • Die Teilnehmereinheiten TE können mittels e-Wallet für elektronische Münzdatensätze Ci (mit den Prüfwert p, pi1 pi2) d.h. als elektronische Geldbörse mit einem Speicherbereich, in dem eine Vielzahl von Münzdatensätzen Ci hinterlegt sein können, ausgebildet sein und so beispielsweise in Form einer Applikation auf einem Smartphone oder IT-System eines Händlers, einer Geschäftsbank oder eines anderen Marktteilnehmers implementiert sein. Somit sind die Komponenten in der Teilnehmereinheit TE, so wie sie in Tabelle 3 gezeigt sind, als Software implementiert. Es wird davon ausgegangen, dass das Münzregister 2, das Transaktionsregister 4 und/oder das Überwachungsregister 6 auf einem Server oder auf einer DLT basiert und von einer Reihe vertrauenswürdiger Marktteilnehmer betrieben wird.
  • Im Münzregister 2 kann ein RDS betreffend den elektronischen Münzdatensatz C durch einen zu registrierenden RDS betreffend den elektronischen Münzdatensatz C oder eines modifizierten elektronischen Münzdatensatzes C ersetzt werden. Damit werden im Münzregister 2 (nur) aktuelle - im Bezahlsystem BZ existierende - Münzdatensätze C als RDS gepflegt. Etwaige Vorgängerversionen oder frühere Modifikationen werden dann beispielsweise im Überwachungsregister 6 als Überwachungsdatensatz ÜDS geführt und werden zu diesem Zweck vom Münzregister 2 während des Ersetzen-Vorgangs an das Überwachungsregister 6 bereitgestellt und werden dort aufbewahrt. Damit kann die Historie zu dem elektronischen Münzdatensatz C durch das Überwachungsregister 6 protokolliert werden. Damit wird das Münzregister 2 registerdatensatzoptimiert (=speicheroptimiert) ausgestaltet und reagiert schneller auf Register- oder Statusanforderungen von Teilnehmereinheiten TE und/oder dem Überwachungsregister 6.
  • Das Überwachungsregister 6 speichert dazu Überwachungsdatensätze, kurz ÜDS. Ein ÜDS wird aus zumindest einem TDS und zumindest einem RDS im Überwachungsregister 6 gebildet.
  • Dabei korrespondiert ein ÜDS mit genau einem elektronischen Münzdatensatz C und wird aus genau einem TDS, der ebenfalls zu dem elektronischen Münzdatensatz korrespondiert und genau einem RDS, der ebenfalls zu dem elektronischen Münzdatensatz korrespondiert, im Überwachungsregister 6 gebildet. Dieses Bilden erfolgt nach dem Bereitstellen des TDS durch das Transaktionsregister und Bereitstellen des RDS durch das Münzregister. Ein Überwachungsdatensatz ÜDS betrifft genau eine Bezahltransaktion.
  • In einer alternativen Ausgestaltung kann ein ÜDS auch eine Mehrzahl von elektronischen Münzdatensätzen C betreffen, beispielsweise alle elektronische Münzdatensätze C, die von einer Teilnehmereinheit TEx innerhalb eines vordefinierten Zeitraums versendet wurden. Dabei wird ein ÜDS beispielsweise aus mehreren TDS betreffend diese Teilnehmereinheit TEx in dem Zeitraum gebildet. Zudem wird der ÜDS beispielsweise aus mehreren RDS betreffend Modifikationen an Münzdatensätzen C gebildet. Die Modifikationen sind dabei von der TEx innerhalb des Zeitraums initiiert und/oder angefordert und/oder statusgeprüft. Sodann betrifft ein ÜDS eine Mehrzahl von TDS (korrespondierend zu jeweiligen elektronischen Münzdatensätzen C dieser Teilnehmereinheit TE, bevorzugt in diesem Transaktionszeitraum) und zumindest einem, bevorzugt mehreren Registerdatensätzen RDS (ebenfalls korrespondierend zu den jeweiligen elektronischen Münzdatensätzen C dieser Teilnehmereinheit TE, bevorzugt in diesem Transaktionszeitraum) im Überwachungsregister 6 gebildet. Ein Überwachungsdatensatz ÜDS betrifft dann mehrere Bezahltransaktionen dieser Teilnehmereinheit TEx, bevorzugt innerhalb eines vordefinierten Zeitraums.
  • Nach der Bildung des jeweiligen Überwachungsdatensatzes ÜDS kann eine Auswertung des Überwachungsdatensatzes ÜDS durch das Überwachungsregister 6 erfolgen. Diese Auswertung betrifft das Prüfen auf doppeltes Ausgeben der elektronischen Münzdatensätze C oder das unerlaubte Generieren von geldwerten Beträgen durch eine Teilnehmereinheit TE und/oder auch das Prüfen einer Alterung von elektronischen Münzdatensätze C. Durch das Bilden und Auswerten im Überwachungsregister 6 kann beispielsweise festgestellt werden, dass eine Teilnehmereinheit TE einen Münzdatensatz C doppelt ausgegeben hat oder einen geldwerten Betrag verändert hat. Zudem kann festgestellt werden, dass ein Münzdatensatz C eine vordefinierte Zeitspanne nicht verwendet wurde und dies dem Teilnehmer TE mitgeteilt wird oder eine automatische Rückgabe an die Herausgeberinstanz 1 initiiert wird.
  • Die 3 zeigt eine Weiterbildung des Ausführungsbeispiels eines Bezahlsystems der 2. Auf die Ausführungen der 2 wird zur Vermeidung von Wiederholungen verwiesen. Die Ausgestaltungen der 3 können auch mit den Ausgestaltungen der 2 kombiniert werden.
  • In 3 ist der Datenfluss von elektronischen Münzdatensätzen C, RDS, TDS und ÜDS im Bezahlsystem BZ durch unterschiedliche Linien verdeutlicht. Die Übertragung 105 von elektronischen Münzdatensätzen C ist durch eine gepunktete Linie zwischen zwei Teilnehmereinheiten TE dargestellt. Diese Übertragung 105 stellt einen Bezahlvorgang (Bezahltransaktion) im Bezahlsystem BZ dar.
  • Zudem wird das Senden von TDS im Bezahlsystem BZ mit durchgezogener Linie dargestellt. Prinzipiell werden TDS von einer TE erstellt und dem Transaktionsregister 4 (siehe 6 bis 8) zur Verfügung gestellt. Zusätzlich können die TDS auch direkt an ein Überwachungsregister 6 gesendet werden. In einer Ausgestaltung wird ein Kommunikationskanal zwischen Teilnehmereinheit und Münzregister 2 verwendet, um die TDS an das Überwachungsregister zu senden. In dieser Ausgestaltung ist dem Münzregister 2 der Zugriff auf die TDS verwehrt. Im Überwachungsregister 6 werden aus den TDS und den RDS dann die ÜDS gebildet.
  • Dabei werden im Bezahlsystem BZ auch Datenelemente, die zu einem TDS führen können, als durchgezogene Linie dargestellt. Einerseits werden Teilnehmerkennungen bzw. davon abgeleitete Pseudonyme P in dem Personenregister 7 bzw. einer Geschäftsbank 1a oder einem Dienste-Server (nicht gezeigt) geführt.
  • Diese Zuordnung wird dann dem Transaktionsregister 4 bereitgestellt, um beispielsweise einen TDS einer Teilnehmereinheit TE1 zu pseudonymisieren, um einen pseudonymisierten TDS* an das Überwachungsregister 6 bereitzustellen. Das Pseudonymisieren eines TDS wird mit Schritten 410 und/oder 411 der 7 näher erläutert werden.
  • In einer Ausgestaltung des Bezahlsystems BZ authentisiert sich eine TE (hier die TE2) am Münzregister 2. Bei der Authentisierung werden Teilnehmerkennungen oder Pseudonyme P abgefragt. Somit ist das Münzregister 2 in Kenntnis von Teilnehmerkennungen und kann diese in einem zweiten Modus (4b) verwenden, um TDS an das Überwachungsregister 6 bereitzustellen.
  • In einer alternativen Ausgestaltung des Bezahlsystems BZ authentisiert sich eine TE (hier die TE2) nicht am Münzregister 2. Somit ist das Münzregister 2 nicht in Kenntnis von Teilnehmerkennungen und stellt in einem ersten Modus (4a) nur RDS an das Überwachungsregister 6 bereit.
  • In 3 ist das Senden von RDS im Bezahlsystem BZ mit gestrichelter Linie dargestellt. Prinzipiell werden RDS von einer TE erstellt und dem Münzregister 4 (gemäß 2) zur Verfügung gestellt. Zusätzlich werden die RDS in beiden Modi des Münzregisters der Überwachungsregister 6 bereitgestellt, um dort die Gültigkeit, den Status, die Modifikationen, die Prüfwerte und die Lebensdauer (Rückgabewert) eines elektronischen Münzdatensatzes C zu prüfen.
  • In einer Ausgestaltung wird eine Zuordnung des Personenregisters 7 oder der TE dem Münzregister 2 bekanntgemacht, um beispielsweise einen RDS zu pseudonymisieren, um einen pseudonymisierten RDS* an das Überwachungsregister 6 bereitzustellen. Das Pseudonymisieren eines RDS erfolgt ähnlich zu den Schritten 410 und/oder 411 der 7, ist aber vom Pseudonymisieren eines TDS unabhängig.
  • In 3 sind für das Münzregister drei logische Repräsentanten von Schnittstellen gezeigt, eine Schnittstelle des Münzregisters 2 zur TE, eine Schnittstelle des Münzregisters 2 zum Überwachungsregister 6 und eine Schnittstelle zur Herausgabeinstanz 1. Nicht dargestellt aber denkbar ist eine Schnittstelle zu einem Transaktionsregister 4, um TDS an das Überwachungsregister 6 weiterzuleiten. Dies Schnittstellen können physisch als eine Schnittstelle ausgebildet sein und nur logisch getrennt ausgebildet sein.
  • Ein Modus-Schalter MODUS im Münzregister 2 stellt entweder den ersten Modus des Münzregisters 2 ein, in welchem nur die RDS an das Überwachungsregister 6 bereitgestellt werden oder stellt den zweiten Modus des Münzregisters 2 ein, in welchem die RDS und die TDS an das Überwachungsregister 6 bereitgestellt werden. Die TDS können dabei aus den Authentisierungsdaten gewonnen werden.
  • In 4a ist ein Ausführungsbeispiel eines Münzregisters 2 des Bezahlsystems BZ gemäß der Erfindung in einem ersten Modus dargestellt. Die Schnittstelle zum TE des Münzregisters 2 empfängt dabei eine Registrierungs- und/oder Statusanforderung von der TE bezüglich eines elektronischen Münzdatensatzes C. Dabei wird festgestellt, dass das TE diese Anforderungen anonym gesendet hat. Es erfolgt keine Authentisierung, sodass das Münzregister 2 im ersten Modus betrieben wird. Die Registrierungsanforderungen können mittels Status-Verifikator geprüft werden und die TE kann eine entsprechende Statusmeldung erhalten. Alternativ oder zusätzlich können mittels Status-Verifikator und Änderungs-Verifikator weitere Prüfungen eingefordert werden und für diese Zwecke ein RDS dem Überwachungsregister 6 bereitgestellt werden. Die zur Prüfung der Anforderungen der TE möglicherweise notwendigen TDS werden nicht vom Münzregister 2 bereitgestellt und können beispielsweise auf Anfrage des Überwachungsregisters 6 bei der TE direkt oder dem Transaktionsregister 4 abgefragt werden.
  • In 4b ist ein Ausführungsbeispiel des Münzregisters 2 des Bezahlsystems BZ gemäß der Erfindung in einem zweiten Modus dargestellt. Die Schnittstelle zum TE des Münzregisters 2 empfängt dabei eine Registrierungs- und/oder Statusanforderung von der TE bezüglich eines elektronischen Münzdatensatzes C. Dabei wird festgestellt, dass das TE sich am Münzregister 2 authentisieren kann/will. Es erfolgt eine Authentisierung bei der eine Teilnehmerkennung oder ein Pseudonym vom Münzregister 2 abgefragt und im Münzregister 2 erhalten wird. Die erfolgreiche Authentisierung des TE führt dazu, dass das Münzregister 2 im zweiten Modus betrieben wird. Zur Erstellung der RDS können die Registrierungsanforderungen mittels Status-Verifikator geprüft werden und die TE kann eine entsprechende Statusmeldung erhalten. Alternativ oder zusätzlich können mittels Status-Verifikator und Änderungs-Verifikator weitere Prüfungen eingefordert werden und für diese Zwecke ein RDS dem Überwachungsregister 6 bereitgestellt werden. Die zur Prüfung der Anforderungen der TE möglicherweise notwendigen TDS werden durch die mit der Authentisierung bereitgestellte Teilnehmerkennung oder deren Pseudonym in Kombination mit den RDS vom Münzregister 2 verwendet, um TDS an das Überwachungsregister 6 bereitzustellen.
  • In 5 ist eine Weiterbildung des Ausführungsbeispiels eines Bezahlsystems der 2 dargestellt. Auf die Ausführungen der 2 und der 3 wird zur Vermeidung von Wiederholungen verwiesen. Die Ausgestaltungen der 5 können auch mit den Ausgestaltungen der 2 kombiniert werden. In 5 wird als RDS ein oben beschriebener maskierter elektronischer Münzdatensatz Z verwendet. Dieser ist betragsanonym und identitätsanonym.
  • Nach der Erzeugung des Transaktionsdatensatzes TDS wird dieser von dem ersten Endgerät M1 mit einem kryptografischen Schlüssel verschlüsselt werden. Dieser kryptografische Schlüssel ist beispielsweise ein öffentlicher Schlüsselteil eines korrespondierenden zusammengesetzten privaten Schlüsselteils. Dieser private Schlüsselteil ist aus drei Teilschlüsseln 8a, 8b, 8c zusammengesetzt, wobei die Teilschlüssel 8a, 8b, 8c beispielsweise addiert oder XOR-verknüpft wurden. Diese Verknüpfung der Teilschlüssel 8a, 8b, 8c erfolgt entweder in dem ersten Endgerät M1 oder in dem Transaktionsregister 4. Diese Verknüpfung der Teilschlüssel 8a, 8b, 8c ist beispielsweise systemweit geheim. Die Kenntnis oder der Besitz nur eines Teilschlüssels 8a, 8b, 8c ermöglicht keine Entschlüsselung des Transaktionsdatensatzes TDS. 8 zeigt ein Ausführungsbeispiel zum Verschlüsseln und Entschlüsseln eines Transaktionsdatensatzes TDS.
  • In 5 wird der verschlüsselte Transaktionsdatensatz TDS von dem ersten Endgerät M1 an das Transaktionsregister 4 gesendet und dort abgelegt. Der Zeitpunkt des Sendens ist bevorzugt eng mit dem Übertragen 105 des elektronischen Münzdatensatzes verknüpft, sodass das Transaktionsregister 4 stets auf einem aktuellen Stand der im Bezahlsystem BZ durchgeführten Transaktionen ist.
  • Bei Betrugsverdachtsfällen könnte im Rahmen eines behördlichen Beschlusses, beispielsweise eine Gerichtsentscheidung, angeordnet werden, den verschlüsselten Transaktionsdatensatz TDS zu entschlüsseln, um die damit aufgezeichnete Transaktion (das Übertragen 105) aufzudecken und zu analysieren. Mittels des behördlichen Beschlusses würden dann beispielsweise an dem Transaktionsregister 4 für ein Endgerät M (mittels der Kennung) über einen bestimmten Zeitpunkt bzw. eine bestimmte Zeitdauer alle abgelegten Transaktionen abgefragt werden. Darüber hinaus könnten weitere Attribute der Transaktionsdaten, wie die Höhe geldwerter Beträge der Münzdatensätze, die jeweiligen Transaktionspartner etc. abgefragt werden.
  • Als Ergebnis der Gerichtsentscheidung können die Transaktionsdaten entschlüsselt ausgelesen werden, indem eine Mehrzahl von entfernten Instanzen als autorisierte Parteien durch Kombination ihrer Teilschlüssel, einen Entschlüsselungsschlüssel generiert (bzw. bereitstellen). Die entfernten Instanzen sind beispielsweise Vollzugsbehörden, Notare, das Justizministerium, eine Zentralbank oder andere.
  • Alle entfernten Instanzen (berechtigte Parteien) besitzen nur Teilschlüssel 8a, 8b, 8c des Entschlüsselungsschlüssels. Alle Mitglieder bzw. eine Mindestanzahl n von m entfernten Instanzen sind erforderlich, um den Transaktionsdatensatz TDS gemeinsam zu entschlüsseln. Technisch gesehen werden die einzelnen Teilschlüssel 8a, 8b, 8c der verschiedenen entfernten Instanzen durch Addition oder durch bitweise XOR-Verknüpfung zu einem gemeinsamen privaten Schlüsselteil zusammengesetzt. Dieser private Schlüsselteil (der zum entsprechenden öffentlichen Schlüsselteil der Verschlüsselung korrespondiert) wird dann zur Entschlüsselung des Transaktionsdatensatzes TDS verwendet. Dieses Konzept garantiert, dass keine entfernte Instanz allein den Transaktionsdatensatz TDS entschlüsseln kann und damit andere Instanzen umgehen könnte. Wenn das Konzept nicht auf die Verfügbarkeit aller m entfernten Instanzen angewiesen sein sollte, könnte eine Schwellenwert-kryptographie angewendet werden, um eine Untermenge n dieser Teilschlüssel 8a, 8b, 8c zu verwenden. Diese Untermenge n definiert dann die Mindestanzahl von zu kombinierenden Teilschlüsseln 8a, 8b, 8c.
  • Neben der Identifizierung illegaler Aktivitäten kann das Ablegen der Transaktionsdaten im Transaktionsregister nachfolgende weitergehende Aufgaben erfüllen:
    • 1. Eine Überwachung der Bewegung und Verwendung eines Münzdatensatzes: Alle Informationen sind in einem Transaktionsregister 4, beispielsweise einem großen Datenspeicher verfügbar abgelegt. Die entsprechende Datenanalyse ermöglicht eine Adaption des Verhaltens einer Zentralbank bei der Ausgabe der Münzdatensätze.
    • 2. Sichtbarkeit der Münzdatensätze im Umlauf zur Steuerung des Angebote: Die Herausgeberinstanz, beispielsweise eine Zentralbank kennt immer die genaue Menge an aktuell umlaufenden Münzdatensätzen. Es ist damit möglich, sowohl Teilnehmereinheiten als auch Münzdatensätze, die über eine lange Zeitdauer, beispielsweise 1 Jahr, nicht am Bezahlsystem BZ teilgenommen haben, zu verfolgen und zu deaktivieren, um die Sicherheit am Bezahlsystem BZ nicht zu gefährden.
    • 4. Keine Bereitstellung von Überwachungsinformationen durch Geschäftsbanken oder Dienstleistungsanbieter mehr notwendig. Diese Informationen werden auf transaktionsbasierter Ebene automatisch von allen Teilnehmereinheiten bereitgestellt.
  • In 6 ist ein Ausführungsbeispiel eines Verfahrensablaufdiagramms eines Verfahrens 300 in einer Teilnehmereinheit TE, nachfolgend auch als Endgeräte M oder Sicherheitselemente SE genannt, dargestellt. Die gestrichelt dargestellten Blöcke des Verfahrens 300 sind dabei optional. Jeder dieser Schritte kann eine Teilnehmerinteraktion oder zumindest ein Teilnehmerinformieren beinhalten, beispielsweise über eine GUI der TE.
  • Im Schritt 301 wird ein Transaktionsdatensatz TDS erzeugt. Der Transaktionsdatensatz TDS umfasst die Teilnehmer-Kennungen von der ersten Teilnehmereinheit TE1 (sendende TE) und von der zweiten Teilnehmereinheit TE2. Zudem sind Informationen über den zu übertragenden (bzw. den übertragenen) elektronischen Münzdatensatz C enthalten, beispielsweise der geldwerte Betrag υ. Anstelle der Informationen über den zu übertragenden (bzw. den übertragenen) elektronischen Münzdatensatz C kann der maskierte elektronische Münzdatensatz Z in den TDS eingebracht werden. Zudem kann ein Transaktionszeitpunkt im TDS enthalten sein, der den Zeitpunkt der Übertragung 105 des elektronischen Münzdatensatzes C zwischen beiden Teilnehmereinheiten TE kennzeichnet. Der Zeitpunkt des Erzeugens 301 kann zeitlich eng mit dem Zeitpunkt des Übertragens 105 gekoppelt sein. In einer Vorgabe des Bezahlsystems BZ kann gefordert sein, dass zuerst der elektronische Münzdatensatz C übertragen werden muss (Schritt 105), bevor der verschlüsselte Transaktionsdatensatz TDS zu versenden ist.
  • Nach dem Erzeugen-Schritt 301 wird der erzeugte Transaktionsdatensatz TDS verschlüsselt. Dazu weist die erste Teilnehmereinheit TE1 einen öffentlichen Schlüsselteil K auf, der aus Teilschlüsseln verschiedener entfernter Instanzen zusammengesetzt ist. Die Schlüsselzusammensetzung ist beispielsweise in 8 gezeigt. Alternativ empfängt die Teilnehmereinheit TE1 einen entsprechenden kryptografischen Schlüssel K im Schritt 302, beispielsweise auf Anfrage des Schlüssels bei dem Transaktionsregister 4. Der Schlüssel K kann ein Schlüssel einer PKI-Struktur oder ein symmetrischer Schlüssel sein.
  • Im Schritt 303 erfolgt dann das Verschlüsseln des Transaktionsdatensatzes TDS mit dem kryptografischen Schlüssel K in der ersten Teilnehmereinheit TE1, beispielsweise durch ein Verschlüsselungsmodul oder eine Recheneinheit der ersten Teilnehmereinheit TE1.
  • Nicht in der 6 dargestellt ist ein optionaler Anknüpfen-Schritt von (Klartext-) Metadaten an den verschlüsselten Transaktionsdatensatz TDS, beispielsweise einer Kennung der ersten Teilnehmereinheit TE1, einer Kennung der zweiten Teilnehmereinheit TE2 und/oder einem Transaktionszeitpunkt. Diese Metadaten erlauben es, den lokal und/oder im Transaktionsregister 4 abgelegten verschlüsselten TDS zu indexieren oder zu katalogisieren.
  • Im Schritt 304 wird dann eine Kommunikationsverbindung zum Transaktionsregister 4 initiiert. Damit wird versucht, einen Kommunikationskanal zwischen der ersten Teilnehmereinheit TE1 und dem Transaktionsregister 4 herzustellen. Das Initiieren umfasst auch, dass die jeweilige Teilnehmereinheit TE erkennt/weiß, dass momentan eine Offline-Transaktion geplant/durchgeführt ist und keine Verbindung zu dem entfernten Transaktionsregister 4 aufgebaut werden kann oder soll.
  • Im nachfolgenden Prüfschritt 305 wird in der Teilnehmereinheit TE1 abgefragt, ob eine Verbindung im Schritt 304 aufgebaut werden konnte.
  • Im Ja-Fall des Prüfschritts 305 wird der verschlüsselte Transaktionsdatensatz TDS im Schritt 306 an das Transaktionsregister 4 versendet. Ggf. werden auch weitere Transaktionsdatensätze TDS von früheren Übertragungen von elektronischen Münzdatensätzen C gesendet, sollte diese Kommunikationsverbindung erstmalig seit diesen Übertragungen erstellt worden sein. In diesem Zusammenhang wird dann auch ein Prüfwert zurückgesetzt (nicht dargestellt in 6), der eine Anzahl von Übertragungen von elektronischen Münzdatensätzen C, die ohne Versenden eines Transaktionsdatensatzes TDS erfolgt sind, repräsentiert. In einem Prüfschritt 305a wird ggf. abgefragt, ob ein Sendefehler beim Senden 305 des verschlüsselten Transaktionsdatensatzes TDS aufgetreten ist. Im Nein-Fall des Prüfschritts 305a wird dann optional der verschlüsselte und/oder der unverschlüsselte Transaktionsdatensatz TDS lokal in der ersten Teilnehmereinheit TE2 zu Archivierungszwecken oder zur Speicherung einer Historie oder für Abfragen aufgrund behördlicher Anfrage gespeichert. Anschließend wird der elektronische Münzdatensatz C im Schritt 105 an die zweite Teilnehmereinheit TE2 übertragen, falls eine Vorgabe im Bezahlsystem BZ ist, dass zuerst der verschlüsselte Transaktionsdatensatz TDS zu versenden ist, bevor der elektronische Münzdatensatz C im Schritt 105 übertragen werden darf. In einer Ausgestaltung des Verfahrens 300 erfolgt nach dem Übertragen 105 zwingend ein Registrieren 104 des maskierten elektronischen Münzdatensatzes Z in dem Münzregister 2. In einer Ausgestaltung des Verfahrens 300 wird im Schritt 104 ein pseudonymisierter maskierter Münzdatensatz in dem Münzregister 2 oder dem Überwachungsregister 6 registriert, wie es in den 9, 17 und 18 beschrieben ist.
  • Im Nein-Fall des Prüfschritts 305 (Offline-Transaktion, Flug-Modus, kein Senden der Transaktionsdaten TDS (vom Teilnehmer) gewünscht) und auch im Ja-Fall des Prüfschritts 305a (Übertragungsfehler, Verbindungsabbruch) wird ein Verbindungsfehler im Schritt 307 festgestellt. Daran anschließend wird im Prüfschritt 308 ein Prüfwert p in derersten Teilnehmereinheit TE1 mit einem Schwellwert X verglichen. Der Prüfwert im Schritt 308 repräsentiert eine Anzahl von (offline) Übertragungen 105 von elektronischen Münzdatensätzen C, die ohne Versenden eines Transaktionsdatensatzes TDS erfolgt sind. Diese (offline) Übertragungen 105 ausgehend von der ersten Teilnehmereinheit TE1 können zu einer x-beliebigen anderen Teilnehmereinheit TEx übertragen worden sein. Im Ja-Fall des Prüfschritts 308, also wenn dieser Prüfwert p größer ist als der Schwellwert X, beispielsweise 100 oder 50 oder 10 Übertragungen, wird der Transaktionsdatensatz TDS gespeichert (verschlüsselt und/oder unverschlüsselt) und zwingend der Schritt 304 wiederholt. Im Nein-Fall des Prüfschritts 308 erfolgt das Übertragen 105 falls eine Vorgabe im Bezahlsystem BZ ist, dass zuerst der verschlüsselte Transaktionsdatensatz TDS zu versenden ist, bevor der elektronische Münzdatensatz C im Schritt 105 übertragen werden darf. Im Schritt 310 wird dann der Prüfwert p inkrementiert, d.h. stufenweise erhöht, bevorzugt um 1 erhöht.
  • Mit den Schritten 308 bis 310 wird sichergestellt, dass das Offline-Verhalten der Teilnehmereinheiten TE überwacht bleibt und nicht über einen vordefinierten bestimmten (bezahlsystemvorgegebenen) Schwellwert X von Übertragungsanzahlen hinausgehend möglich ist. Nicht sofort sendbare Transaktionsdatensätze TDS einer Offline-Transaktion, also einem Übertragen 105 ohne Registrieren 104 oder Berichten zu einer der Registerinstanz 2, 4, 6 des Bezahlsystems BZ, werden im Schritt 309 zwischengespeichert und zu einem späteren Zeitpunkt gesendet. Die Anzahl der Offline-Transaktionen, die eine Teilnehmereinheit TE durchführen darf, wird bezahlsystemtechnisch begrenzt und mittels des Prüfwerts p kontrolliert im Schritt 308. Ist der Schwellwert X erreicht müssen zunächst die Transaktionsdatensätze TDS gesendet werden, bevor eine weitere Offline-Transaktion 105 möglich ist (siehe Schritt 309 zu Schritt 304). Dieser Prüfwert p kann unabhängig von anderen Prüfungen in der Teilnehmereinheit TE erfasst und geführt werden. Dieser Prüfwert p kann mit anderen Prüf- bzw. Zählwerten pi1, pi2, des Münzdatensatzes C zur Prüfung im Münzregister 2 oder dem Überwachungsregister 6 kombiniert werden, siehe Bezahlsystem BZ der 9.
  • Einzelne Verfahrensschritte können dabei vertauscht werden. So kann eine generelle erste Vorgabe im Bezahlsystem BZ sein, dass Münzdatensätze C erst zwischen TEs übertragen werden, bevor ein Transaktionsdatensatz TDS dazu erstellt wird. Dann würde ein TDS immer ein bereits übertragenen Münzdatensatz C betreffen, der Schritt 105 wäre vor dem dazugehörigen Schritten 301, 303 durchzuführen.
  • Alternativ kann eine generelle erste Vorgabe im Bezahlsystem BZ sein, dass Münzdatensätze C erst zwischen TEs erst übertragen (Schritt 105) werden, nachdem ein Transaktionsdatensatz TDS dazu erstellt wurde (Schritt 301). Dann würde ein TDS immer ein noch zu übertragenden Münzdatensatz C betreffen, der Schritt 105 wäre nach dem dazugehörigen Schritt 301 durchzuführen.
  • Eine zweite generelle Vorgabe im Bezahlsystem BZ könnte die lokale Speicherung der TDS im TE betreffen. So kann gefordert sein, dass TDS auch lokal (also Historie oder Archivierung) abzulegen sind. Der Speicherschritt 309 ist dann nicht nur für Übertragen-Wiederholungen (im Fehlerfall eines ersten Übertragenversuchs) vorzusehen. Es kann dabei ein Vorgabedetail sein, dass die TDS auch verschlüsselt im TE zu speichern sind. Diese lokale Speicherung des TDS, die redundant zur Speicherung des TDS im Transaktionsregister 4 ist, kann im Rahmen einer behördlichen Anfrage (einem Gerichtsbeschluss) mit ausgelesen werden, der Teilnehmer also gezwungen werden, diese lokale Speicherung bereitzustellen bzw. kann der Transfer der lokalen Speicherung in einem (Hintergrund-)Prozess der Teilnehmereinheit TE ohne Teilnehmerinteraktion erfolgen.
  • Eine dritte generelle Vorgabe im Bezahlsystem BZ kann sein, pseudonymisierte TDS* in einem Überwachungsregister 6 des Bezahlsystems BZ abzulegen. Diese pseudonymisierten TDS* werden bei der Gültigkeit der Münzdatensätze mit berücksichtigt, um Betrugsszenarien bereits bezahlsystemintern entdecken zu können.
  • Eine vierte generelle Vorgabe im Bezahlsystem BZ kann sein, verschlüsselte TDS nicht an das Transaktionsregister 4 zu senden, wenn eine Offline-Transaktion geplant/durchgeführt ist. Diese Vorgabe kann eng mit dem Prüfwert p gekoppelt sein, sodass eine Teilnehmereinheit TE eine Warnung bereits vor der Auswahl eines Übertragenmodus (Online oder Offline) an den Teilnehmer ausgibt, dass ein Prüfwert p einen Schwellwert für die maximale Anzahl von Ofline-Übertragungen 105 überschritten hat und ohne vorhergehendes Versenden (alter) TDS an das Transaktionsregister 4 (mit Zurücksetzen des Prüfwert-Zählers) keine weitere Offline-Übertragung möglich ist.
  • In der 7 ist ein Ausführungsbeispiel eines Verfahrensablaufdiagramms eines erfindungsgemäßen Verfahrens 400 in einem Transaktionsregister 8 gezeigt. Die gestrichelt dargestellten Blöcke des Verfahrens 400 sind dabei optional.
  • Dabei wird im Schritt 401 ein verschlüsselter Transaktionsdatensatz TDS von einer Teilnehmereinheit TE in dem Transaktionsregister 4 empfangen. Dieser Transaktionsdatensatz TDS ist gemäß dem in 6 dargestellten Verfahren erzeugt worden.
  • Im optionalen Prüfschritt 402 wird geprüft, ob verschiedene Generationen von Teilschlüsseln im Bezahlsystem BZ, beispielsweise dem Transaktionsregister 4, bevorzugt einem HSM-Modul innerhalb des Transaktionsregisters 4 als Schlüsselspeicher, vorhanden sind. Im Ja-Fall des Schritts 402 wird der Transaktionsdatensatz TDS mit dem privaten Schlüsselteil k des kryptografischen Schlüssels als Entschlüsselungsschlüssel im Schritt 403 entschlüsselt und mit einem kryptografischen Schlüssel wieder verschlüsselt, beispielsweise mit einem HSM-Schlüssel des Transaktionsregisters 4. Auf diese Weise kann das Ablegen von verschieden verschlüsselten Transaktionsdatensätzen TDS, die mit verschiedenen Schlüsselversionen der entfernten Instanzen verschlüsselt sind, im Transaktionsregister 4 verhindert werden. Der Verwaltungsaufwand im Transaktionsregister 4 ist damit verringert.
  • Nach dem Umverschlüsseln-Schritt 403 oder im Nein-Fall des Prüfschritts 402 wird der Transaktionsdatensatz TDS in einem Speicherbereich abgelegt und dort archiviert. Ggf. weist der Transaktionsdatensatz TDS Metadaten im Klartext auf, die in einer Datenbank des Transaktionsregisters 4 eingetragen bzw. nachgehalten werden. Wenn beispielsweise ein Transaktionszeitpunkt als Metadatum des TDS vorhanden ist, kann ein Löschzeitpunkt im Rahmen einer Vorratsdatenspeicherung generiert werden. Der TDS würde dann automatisch nach Ablauf einer eingestellten Zeitspanne (dem Löschungszeitpunkt) aus dem Transaktionsregister 4 gelöscht werden.
  • Im Transaktionsregister 4 (bspw. eine Datenbank als vertrauenswürdige Entität) werden die TDS in verschlüsselter Form gespeichert, für deren Entschlüsselung mehrere Teilschlüssel erforderlich sind. Dadurch wird sichergestellt, dass ein ordnungsgemäßes Verfahren eingehalten werden muss und niemand nach Belieben auf sensible Transaktionsdaten TDS zugreifen kann.
  • Optional, beispielsweise bei Nichtvorhandensein eines Schlüsselspeichers im Transaktionsregister 4, werden im Schritt 405 Teilschlüssel des kryptografischen Schlüssels k empfangen und im Schritt 406 im Transaktionsregister 4 kombiniert, beispielsweise zum privaten Schlüsselteil des privaten Schlüsselteils bei Verwendung einer PKI-Schlüsselstruktur. Die Kombination ist beispielsweise geheim, um es Besitzern der Teilschlüssel 8a, 8b, 8c nicht zu ermöglichen, den Entschlüsselungsschlüssel zu kombinieren. Der kombinierte Schlüssel kann auch nur aus einer Untermenge von Teilschlüsseln zusammengesetzt werden, was durch Anwenden einer Schwellwert-Kryptographie möglich ist.
  • Im Rahmen einer - von außerhalb des Bezahlsystems BZ erzeugten - behördlichen Anfrage, insbesondere auf Basis eines richterlichen Beschlusses, wird im Schritt 407 eine Entschlüsselungsanfrage an das Transaktionsregister 4 gestellt. Dabei können die Metadaten der Transaktionsdatensätze mit Parametern der Entschlüsselungsfrage abgeglichen werden, beispielsweise um alle Transaktionsdatensätze mit einer bestimmten Teilnehmer-ID für einen bestimmten Zeitpunktpunkt oder Zeitraum abzufragen. In der Folge wird im Schritt 408 jede entfernte Instanz zur Authentifizierung am Transaktionsregister 4 aufgefordert. Alternativ wird nur eine benötigte Untermenge an entfernten Instanzen abgefragt, die notwendig ist, um den oder die gewünschten Transaktionsdatensätze TDS zu entschlüsseln. Im Schritt 409 erfolgt dann die Entschlüsselung mit dem kombinierten Schlüssel aus den gemeinsam vorhandenen Teilschlüsseln der entfernten Instanzen.
  • Optional wird im Schritt 410 beispielsweise auch ohne den Schritt 407 eine Teilnehmereinheiten-Kennung im entschlüsselten Transaktionsdatensatz TDS durch ein Pseudonym der Teilnehmereinheit TE ersetzt. Das Pseudonym entspricht bevorzugt dem Pseudonym der 9, 17 und 18. Damit wird eine Anonymitätsstufe für das TDS geändert, sodass der TDS in unverschlüsselter Form für die Prüfung von Münzdatensätzen im Überwachungsregister 6 verwendet werden kann.
  • Optional wird im Schritt 411 beispielsweise auch ohne den Schritt 407 zusätzlich oder alternativ zum Schritt 410 ein geldwerter Betrag im entschlüsselten Transaktionsdatensatz TDS durch eine oder mehrere Betragskategorie ersetzt. In einer Ausgestaltung wird beispielsweise der geldwerte Betrag des Münzdatensatzes C auf oder abgerundet, beispielsweise:
    • • geldwerter Betrag von 1,97 wird zur Betragskategorie „2 Euro“
    • • geldwerter Betrag von 878,99 wird zur Betragskategorie „1000 Euro“ • geldwerter Betrag von 4,07 wird zur Betragskategorie „4 Euro“
    • • geldwerter Betrag von 2118,22 wird zur Betragskategorie „2000 Euro“
  • In einer weiteren Ausgestaltung erfolgt ein Einsortieren des geldwerten Betrags in eine oder mehrere Betragskategorien, die Betragsbereiche abbilden, beispielsweise:
    • • geldwerter Betrag von 1,97 wird zur Betragskategorie „kleiner 10 Euro“
    • • geldwerter Betrag von 878,99 wird zur Betragskategorie „zwischen 100 und 1000 Euro“)
    • • geldwerter Betrag von 4,07 wird zur Betragskategorie „größer 1 Euro“
  • Die Schritte 410 und/oder 411 können von einem HSM im Transaktionsregister 4 durchgeführt werden. Die pseudonymisierten Transaktionsdaten TDS* und/oder die betragskategorisierten Transaktionsdaten werden im Schritt 412 an das Überwachungsregister 6 oder die Teilnehmereinheit TE (zurück)gesendet. für den jeweiligen Transaktionsdatensatz geändert. Die verschlüsselten Transaktionsdatensätze TDS werden im Transaktionsregister abgelegt (Schritt 404 ggf. nach Schritt 412).
  • Der pseudonymisierte Transaktionsdatensatz TDS* weist immer eine höhere Anonymität auf als der (nicht-pseudonymisierte) Transaktionsdatensatz TDS. Mit dieser höheren Anonymitätsstufe kann der pseudonymisierte Transaktionsdatensatz TDS* - in einer Vorgabe des Bezahlsystems BZ - auch unverschlüsselt im Münzregister 2, Überwachungsregister 6 und/oder dem Transaktionsregister 4 abgelegt werden und für weitergehende Validitäts-Prüfungen im Bezahlsystem BZ verwendet werden. Damit könnten Betrugsfälle oder Manipulationen im Bezahlsystem BZ durch das Bezahlsystem BZ selbst verbessert aufgedeckt werden, eine behördliche Anfrage (richterlicher Beschluss) ist dann ggf. nicht notwendig.
  • Die hier beschriebenen Maßnahmen zum Pseudonymisieren oder Anonymisieren eines TDS zum Erhalten eines pseudonymisierten TDS* oder eines anonymisierten TDS* können auch für das Anonymisieren oder Pseudonymisieren von Registerdatensätzen RDS zum Erhalten eines pseudonymisierten RDS* oder eines anonymisierten RDS* angewendet werden.
  • Somit sind erfindungsgemäß verschiedene Anonymitätsstufen für die RDS und die TDS vorgesehen. Diese Anonymitätsstufen können beispielsweise 3 Stufen umfassen, beispielsweise die Stufe 1 (anonym), die Stufe 2 (pseudonym) und die Stufe 3 (offen, nicht-anonym, personalisiert). Diese Stufen können im Münzregister 2 und/oder dem Transaktionsregister 4 eingestellt werden. Diese Stufen können Systemvoraussetzungen sein, um Münzdatensätze C nachverfolgen zu können ohne (oder um) Identitäten/Beträge nachverfolgen zu können.
  • Diese Anonymitätsstufen gelten insbesondere für das Datenelement „Teilnehmerkennung der TE“ im jeweiligen RDS oder TDS. Damit kann jedes TDS oder RDS entweder identitätsanonym, identitätspseudonym und identitätsoffen sein.
  • Diese Anonymitätsstufen gelten insbesondere für das Datenelement „geldwerter Betrag des Münzdatensatzes C“ im jeweiligen RDS oder TDS. Damit kann jedes TDS oder RDS entweder betragsanonym, betragspseudonym und betragsoffen sein.
  • Diese Anonymitätsstufen können innerhalb des RDS bzw. TDS für verschiedene Datenelemente variieren. Zudem kann die Anonymitätsstufe einer Teilnehmerkennung (Identität) von einer Anonymitätsstufe eines geldwerten Betrags verschieden sein. Bevorzugt ist die Anonymitätsstufen einer Teilnehmerkennung (Identität) kleiner als von einer Anonymitätsstufe eines geldwerten Betrags, um die Identität des Teilnehmers vorrangig zum Bezahlbetrag zu schützen.
  • Vorzugsweise haben die TDS für die Teilnehmerkennung und/oder den geldwerten Betrag eine geringere Anonymitätsstufe als die RDS.
  • Es können auch betragsneutrale Registeränderungen durchgeführt werden, wobei im Münzregister 2 mindestens ein RDS einer bereits registrierten Münzdatensatz durch mindestens ein RDS eines zu registrierenden Münzdatensatz ersetzt wird. Damit wird das Münzregister 2 nur RDS zu aktuell im Bezahlsystem BZ verfügbaren elektronischen Münzdatensätzen aufweisen.
  • In 8 ist ein Ausführungsbeispiel einer Verschlüsselung und Entschlüsselung eines Transaktionsdatensatzes TDS gezeigt. Die entfernten Instanzen 8a, 8b, 8c verfügen jeweils über Teilschlüssel, deren bitweise Addition einen privaten Schlüsselteil k eines kryptografischen Schlüssels (Schlüsselpaars) ergibt. Der private Schlüsselteil k wird beispielsweise in einem Schlüsselspeicher des Transaktionsregisters 4, beispielsweise einem Hardware-Security-Modul des Transaktionsregister 4, abgelegt.
  • Der öffentliche Schlüsselteil K wird vom privaten Schlüsselteil k abgeleitet und der Teilnehmereinheit TE zur Verfügung gestellt. Der Verschlüsselungsschritt 303 in 6 des erzeugten Transaktionsdatensatzes TDS oder der Umverschlüsselungsschritt 403 in 7 des entschlüsselten Transaktionsdatensatzes TDS wird dann mit dem öffentlichen Schlüsselteil K erfolgen. Dieses asymmetrische Krypto-System muss sicherstellen sein, dass der öffentliche Schlüsselteil K tatsächlich der vom kombinierten privaten Schlüsselteil k abgeleitete Schlüsselteil ist und es sich hier nicht um eine Fälschung eines Betrügers handelt. Dazu dienen digitale Zertifikate, die die Authentizität des öffentlichen Schlüsselteils K bestätigen. Das digitale Zertifikat kann selbst durch eine digitale Signatur geschützt sein. Der mit dem öffentlichen Schlüsselteil K verschlüsselte Transaktionsdatensatz TDS wird im Transaktionsregister 4 abgelegt.
  • Vor einer Verwendung des privaten Schlüsselteils k zum Entschlüsseln der abgelegten verschlüsselten Transaktionsdatensätze TDS müssen sich die Untermenge oder alle entfernten Instanzen beim Transaktionsregister 4 authentisieren. Bei erfolgreicher Authentisierung wird der Transaktionsdatensatz TDS unter Verwendung des privaten Schlüsselteils k entschlüsselt.
  • Der erzeugte Transaktionsdatensatz bestehend beispielsweise aus einer Transaktionsnummer, einer Empfängeradresse (hier von TE2), einer Sendeadresse (hier von TE1) und einem geldwerten Betrag des eMD C. Der erzeugte Transaktionsdatensatz kann im TE1 auch zum Protokollieren des Übertragens 105 verwendet werden, um im Übertragungs-Fehlerfall eine Rückabwicklung (ROLLBACK) oder Wiederholung (RETRY) des Übertragens 105 durchzuführen.
  • Die 9 zeigt eine zu 5 alternative Weiterbildung des Ausführungsbeispiels eines Systems der 2. Auf die Ausführungen der 2 und der 5 wird zur Vermeidung von Wiederholungen verwiesen. Die Ausgestaltungen der 9 können auch mit den Ausgestaltungen der 5 kombiniert werden.
  • 9 zeigt ein Ausführungsbeispiel eines Bezahlsystems BZ mit Endgeräten M1 und M2 (als Beispiele für Teilnehmereinheiten TE), einer Herausgeberinstanz 1, einem Münzregister 2, einem Überwachungsregister 6 und einem Transaktionsregister 4. Die Endgeräte M1 und M2 können dabei auch Geräte oder Sicherheitselemente SE1, SE2 sein.
  • Das Münzregister 2 enthält ein Register 210, in welchem nur gültige maskierte elektronische Münzdatensatz Zi gespeichert sind. Der elektronische Münzdatensatz Ci repräsentiert einen monetären Betrag υi. Der elektronische Münzdatensatz Ci wird an ein erstes Endgerät M1 ausgegeben. Elektronische Münzdatensätze Ci, bevorzugt für welche ein maskierter elektronischer Münzdatensatz Zi registriert ist, können zur Bezahlung verwendet werden. Der maskierte elektronische Münzdatensatz Zi kann auch als betragsmaskierter elektronischer Münzdatensatz bezeichnet werden, da der monetäre Betrag υi für das Münzregister 2 unbekannt ist (und auch im weiteren Verlauf unbekannt bleibt). Ein Empfänger, hier beispielsweise ein zweites Endgerät M2, des elektronischen Münzdatensatzes Ci kann dessen Gültigkeit mit Hilfe des Münzregisters 2 prüfen. Das Münzregister 2 kann die Gültigkeit des elektronischen Münzdatensatzes Ci mit Hilfe des maskierten elektronischen Münzdatensatzes Zi bestätigen. Für das Münzregister 2 ist der maskierte elektronische Münzdatensatz Zi ein anonymer elektronischer Münzdatensatz, insbesondere da es einen Besitzer des zugehörigen elektronischen Münzdatensatz Ci nicht kennt. Die Anonymitätsstufe eines maskierten Münzdatensatzes Zi in dem Register 201 des Münzregisters 2 ist demnach Stufe 1 (vollständig anonym).
  • In 9 ist dargestellt, dass das zweite Endgerät M2 maskierte elektronische Münzdatensätze Zi* in einem anonymen Modus M2a anonym an das Münzregister 2 sendet, also insbesondere nur den maskierten elektronischen Münzdatensatz Zi* sendet. Das Münzregister 2 bearbeitet die anonym gesendeten maskierten elektronischen Münzdatensatz Zi* in einem anonymen Modus 2a, in welchem beispielsweise dem zweiten Endgerät M2 nur bestätigt wird, dass der gesendete maskierte elektronische Münzdatensatz Zi* gültig ist.
  • Das Münzregister 2 speichert in dem Register 210 anonyme (betrags)maskierte Münzdatensätze Zi von elektronischen Münzdatensätzen Ci der Herausgeberinstanz 1 oder von modifizierten elektronischen Münzdatensätzen der Endgeräte M.
  • In 9 ist weiterhin dargestellt, dass das zweite Endgerät M2 maskierte elektronische Münzdatensätze Si* auch in einem pseudonymen Modus M2p pseudonymisiert über das Münzregister 2 an das Überwachungsregister 6 senden kann. Das zweite Endgerät M2 verknüpft beispielsweise den maskierten elektronischen Münzdatensatz Zi* mit einem Pseudonym PM2 und sendet den pseudonymisierten maskierten elektronischen Münzdatensatz Si* über das Münzregister 2 an das Überwachungsregister 6. Das zweite Endgerät M2 könnte einen pseudonymisierten maskierten elektronischen Münzdatensatz Si* durch Anhängen des Pseudonyms PM2 an den maskierten elektronischen Münzdatensatz Zi* erzeugen. In der dargestellten Ausgestaltung erstellt das zweite Endgerät M2 eine Signatur über den maskierten elektronischen Münzdatensatz Zi* und fügt die Signatur dem Münzdatensatz Zi* hinzu. Als Pseudonym PM2 kann beispielsweise der öffentliche Schlüssel des Signaturschlüsselpaares dienen. Alternativ ist als Pseudonym PM2 eine Ableitung von einer Teilnehmerkennung, wie Endgerätenummer, IMEI, IMSI oder einer vergleichbar abgeleiteten Kennung.
  • Das Pseudonym P kann eine Ableitung der oben erwähnte Teilnehmereinheiten-Kennung sein. Das Pseudonym P kann zusätzlich in der Personenzuordnung 7 der Herausgeberinstanz 1 (oder alternativ eines Diensteanbieters, bspw. einem Geldbörsen-Applikations-Anbieter oder eines Online-Speicher-Bereitstellers) neben der Teilnehmereinheiten-Kennung aufgelistet sein. Zum Schutz der natürlichen Person kann das Pseudonym P ggf. nur in einer vertrauenswürdigen Instanz einer natürlichen Person zugeordnet werden.
  • Das Überwachungsregister 6 bearbeitet die pseudonym gesendeten maskierten elektronischen Münzdatensatz Si* in einem pseudonymen Modus 2p, in welchem dem zweiten Endgerät M2 ebenfalls bestätigt wird, dass der gesendete maskierte elektronische Münzdatensatz Zi* gültig ist. Jedoch wird zusätzlich in einer Datenstruktur 220 des Überwachungsregister 6 die Zuordnung des maskierten elektronischen Münzdatensatzes Zi zum Pseudonym PM2 gespeichert. Wie in den weiteren Ausgestaltungen deutlich wird, kann die Datenstruktur 220 als ein Register für noch zu prüfende maskierte elektronische Münzdatensatze Zi verwendet werden, also auch die Funktion eines Münzregisters 2 erfüllen. Das Überwachungsregister 6 verschiebt oder überspringt im pseudonymen Modus 2p insbesondere einen im anonymen Modus 2a (häufiger oder stets) ausgeführten Prüfungsschritt. Im Prüfungsschritt wird geprüft - bevorzugt weiterhin in Unkenntnis des monetären Betrages υi, ob der monetäre Betrag υi des maskierten elektronischen Münzdatensatzes Zi in einem Bereich liegt.
  • Die anschließend beschriebenen Aspekte, bauen zumindest teilweise auf Details dieser Ausgestaltung der 2, 3 oder 5 auf. Beschrieben wird dort primär der komplexere pseudonyme Modus 2p bzw. M2p, da der einfachere anonyme Modus 2a bzw. M2a ohne Pseudonym (bzw. Signatur) abläuft. In den 17 und 18 werden dagegen Ausgestaltungen beschrieben, die nur optional mit den Details der anderen Ausgestaltungen kombiniert werden können.
  • 10 zeigt eine Datenstruktur für ein Münzregister 2 und/oder ein Überwachungsregisters 6 der vorhergehenden Figuren. In der 10 sind Daten des Münzregisters 2 und/oder des Überwachungsregisters 6 zur Veranschaulichung in einer gemeinsamen Datenstruktur als Tabelle gemeinsam dargestellt. In den Registern 2, 6 sind die maskierten elektronischen Münzdatensätze Zi und ggf. ihre Verarbeitungen registriert. Das Münzregister 2 und das Überwachungsregister 6 können in einer gemeinsamen Serverinstanz untergebracht sein und sind nur logisch voneinander getrennt, um den Rechenaufwand für die einzelnen Überprüfungen durch strikte Zuweisungen reduzieren zu können. Alternativ sind die Register 2, 6 auch physisch voneinander getrennt. Beide Register 2, 6 sind bevorzugt lokal entfernt von den Teilnehmereinheiten TE angeordnet und beispielsweise in einer Server-Architektur untergebracht.
  • Jede Verarbeitungs-Operation für eine Verarbeitung (Erstellen, Deaktivieren, Aufteilen, Verbinden und Umschalten) wird dabei in dem Münzregister 2 registriert und dort beispielsweise in unveränderlicher Form an eine Liste vorheriger Verarbeitungs-Operationen für maskierte elektronische Münzdatensätze Zi angehängt. Die einzelnen Operationen bzw. deren Prüfergebnis, also quasi die Zwischenergebnisse einer Verarbeitung, werden in dem Münzregister 2 festgehalten. Zwar wird im Folgenden von einer sich fortsetzenden Liste ausgegangen, jedoch kann auch diese Datenstruktur, gegebenenfalls nach vorbestimmten Regeln, bereinigt oder komprimiert werden bzw. in einer bereinigten oder komprimierten Form separat bereitgestellt werden.
  • Die Verarbeitungen „Erstellen“ und „Deaktivieren“, die die Existenz des monetären Betrags υi, an sich betreffen, also die Schaffung und die Vernichtung von Geld bedeuten, bedürfen einer zusätzlichen Genehmigung durch die Herausgeberinstanz 1, um in dem Münzregister 2 und/oder dem Überwachungsregister 6 registriert (also protokolliert) zu werden. Die übrigen Verarbeitungsoperationen (Aufteilen, Verbinden, Umschalten) bedürfen keiner Autorisierung durch die Herausgeberinstanz 1 oder durch den Befehlsinitiator (= Zahler, bspw. das erste Endgerät M1). Die übrigen Verarbeitungsoperationen sind jedoch hinsichtlich verschiedener Prüfkriterien zu prüfen.
  • Eine Registrierung der jeweiligen Verarbeitung wird beispielsweise durch entsprechende Listeneinträge in der Datenbank gemäß 10 realisiert. Diese Listeneinträge sind die RDS. Jeder Listeneintrag hat dabei weitere Markierungen 25 bis 28, die die Zwischenergebnisse der jeweiligen Verarbeitung dokumentiert, die von dem Münzregister 2 und/oder dem Überwachungsregister 6 durchgeführt werden müssen. Bevorzugt werden die Markierungen 25 bis 28 als Hilfestellung benutzt und nach Abschluss der Befehle von dem Münzregister 2 und/oder dem Überwachungsregister 6 verworfen.
  • Für anonyme Münzdatensätze sind stets alle Prüfungen auszuführen, so dass auch alle Markierungen 25 -28 verworfen werden könnten. Für pseudonymisierte Münzdatensätze kann dagegen eine Prüfung auch entfallen bzw. später ausgeführt werden.
  • In 10 sind beispielsweise die Prüfungen, die den Markierungen 27b und 27c entsprechen, für pseudonymisierte Münzdatensätze nicht nötig, weil sie später in anderer Form durchgeführt werden. Die Prüfungsschritte der Markierungen 25, 26, 27a und 28 sind dagegen notwendig. Im Folgenden wird entsprechend teilweise von notwendigen bzw. gültigkeitsrelevanten Prüfungsschritten und nachholbaren bzw. gültigkeitsunabhängigen Prüfungsschritten gesprochen, da sie die direkt oder indirekt nachgeholt werden. Ein Münzdatensatz kann als gültig behandelt werden, wenn die notwendigen Prüfungen erfolgt sind. Die in 10 fett hervorgehobenen Daten in den Spalten 24, 28 und 29 sind nur für pseudonymisiert erhaltene Münzdatensätze relevant und betreffen daher vorrangig Eintragungen im Überwachungsregister 6.
  • Eine optionale Markierung 29 kann beispielsweise den Abschluss der Verarbeitung anzeigen. Die Markierungen 29 sind bei Eingehen eines Verarbeitung-Befehls beispielsweise im Zustand „-“ und werden nach erfolgreichem Absolvieren aller Prüfungen (zu Markierungen 25-28) auf den Zustand „1“ gesetzt und bei mindestens einer gescheiterten Prüfung auf den Zustand „0“ gesetzt. Eine (Abschluss-)Markierung 29 könnte mit dem Wert „2“ beispielsweise anzeigen, dass nur die notwendigen Prüfungen abgeschlossen und nachholbare Prüfungen ausgelassen wurden. Werden später von dem Endgerät mit dem Pseudonym Prüfungen für einen oder mehrere Einträge nachgeholt, kann die Markierung auf den Wert „1“ gesetzt werden. Anstelle einer solchen Verwendung der Abschluss-Markierung 29 könnten natürlich auch die Markierungen 27b und 27c der nachzuholenden Prüfungen verwendet und/oder eine separate Pseudonym-Markierung eingesetzt werden.
  • Eine mögliche Struktur für einen Listeneintrag eines Münzdatensatzes umfasst beispielsweise zwei Spalten 22a, 22b für einen Vorgänger-Münzdatensatz (O1, O2), zwei Spalten 23a, 23b für einen Nachfolger-Münzdatensatz (S1, S2), eine Signatur-Spalte 24 für Signaturen von Herausgeberinstanz(en) 1 und Signaturen von Endgeräten M, und sechs Markierungsspalten 25, 26, 27a, 27b und 27c sowie 28. Jeder der Einträge in den Spalten 25 bis 28 weist drei alternative Zustände „-“, ,,1" oder „0“ auf.
  • Die Spalte 25 (O-Flag) zeigt an, ob eine Gültigkeitsprüfung bezüglich eines elektronischen Vorgänger-Münzdatensatzes in Spalte 22a/b erfolgreich war. Der Zustand „1“ bedeutet, dass eine Validitäts-Prüfung ergab, dass der elektronische Münzdatensatz der Spalte 22a/b gültig ist und der Zustand „0“ anzeigt, dass eine Validitäts-Prüfung ergab, dass der elektronische Münzdatensatz der Spalte 22a/b ungültig und der Zustand „-“ anzeigt, dass eine Validitäts-Prüfung noch nicht abgeschlossen ist. Für mehrere Vorgänger-Münzdatensätze wird bevorzugt ein gemeinsames O-Flag eingesetzt (beide gültig), anstatt zwei getrennte O-Flags. Die Spalte 26 (C-Flag) zeigt an, ob eine erste Prüfberechnung für die maskierten elektronischen Münzdatensätze erfolgreich war. Mit der ersten Prüfberechnung wird insbesondere überprüft, ob der Befehl betragsneutral ist, also primär dass die Summe der beteiligten monetären Beträge Null ergibt. Der Zustand „1“ bedeutet, dass eine Berechnung erfolgreich war und der Zustand „0“ gibt an, dass Berechnung nicht erfolgreich war und der Zustand „-“ anzeigt, dass eine Berechnung noch nicht abgeschlossen ist.
  • Die in Spalte 26 durchzuführende Berechnung lautet beispielsweise: ( Z O 1 + Z O 2 ) − ( Z S 1 + Z S 2 ) = = 0
    Figure DE102020004122A1_0014
  • Die Spalte 27a (R1-Flag) zeigt an, ob eine erste Prüfung eines Bereichsnachweises oder des Bereichsnachweises erfolgreich war. Gleiches gilt für die weiteren Spalten 27b (R2-Flag) und 27c (R3-Flag). Der Zustand „1“ bedeutet, dass eine Validitäts-Prüfung ergab, dass die Bereichsnachweise oder der Bereichsnachweis nachzuvollziehen sind oder ist und der Zustand „0“ zeigt an, dass eine Validitäts-Prüfung ergab, dass die Bereichsnachweise oder der Bereichsnachweis nicht nachvollzogen werden konnten oder konnte und der Zustand „-“ zeigt an, dass eine Validitäts-Prüfung noch nicht abgeschlossen ist, nicht erfolgreich war. Der erste Bereichsnachweis der Spalte 27a ist immer nötig, damit der oder die Münzdatensätze als gültig betrachtet werden können. Ein typisches Beispiel für eine notwendige Prüfung ist die Prüfung, dass der monetäre Betrag nicht negativ ist (bzw. keiner der monetären Beträge negativ ist). Der zweite und dritte Bereichsnachweis beeinflusst die Gültigkeit des Münzdatensatzes nicht und kann/können für pseudonymisierte maskierte Münzdatensätze, beispielsweise bei einer späteren Transaktion des Pseudonyms, nachgeholt werden. Mit dem Bereichsnachweis der Spalte 27b wird geprüft, ob der monetäre Betrag des maskierten Münzdatensatzes (bzw. jedes Münzdatensatzes) unter einem Maximalbetrag liegt. Der Maximalbetrag kann systemweit oder für bestimmte Endgerätetypen vorbestimmt sein. Mit dem Bereichsnachweis der Spalte 27c wird beispielsweise eine Summe monetärer Beträge, die die Teilnehmereinheit TE (gesendet oder) in einem bestimmten Zeitraum - wie 24 Stunden - empfangen hat, mit einem Summengrenzwert verglichen oder beispielsweise eine Transaktionsanzahl pro Zeiteinheit für die Teilnehmereinheit TE geprüft, wie maximal 5 pro Minute oder 100 pro Tag. Die Grenzwerte können vom Bezahlsystem BZ systemweit vorgegeben oder für bestimmte Teilnehmereinheiten-Typen (also teilnehmereinheitenspezifisch) definiert werden. Beispielsweise kann eine Kaffeemaschine vom Typ X gerätebedingt nur vier Portionen Heißgetränke pro Minute ausgeben und dementsprechend sind nur vier Münztransaktionen pro Minute gestattet.
  • Die Spalte 28 (S-Flag) zeigt an, ob eine Signatur des elektronischen Münzdatensatzes mit der Signatur der Spalte 24 übereinstimmt, wobei Zustand „1“ bedeutet, dass eine Validitäts-Prüfung ergab, dass die Signatur als die der Herausgeberinstanz identifiziert werden konnte und der Zustand „0“ anzeigt, dass eine Validitäts-Prüfung ergab, dass die Signatur nicht als die der Herausgeberinstanz identifiziert werden konnte und der Zustand „-“ anzeigt, dass eine Validitäts-Prüfung noch nicht abgeschlossen ist.
  • Eine Änderung des Status eines der Markierungen (auch als „Flag“ bezeichnet) bedarf der Genehmigung durch das Münzregister 2 und/oder das Überwachungsregister 6 und muss sodann unveränderlich in der Datenstruktur der 10 gespeichert werden. Eine Verarbeitung ist im anonymen Modus (bzw. für einen anonymen maskierten Münzdatensatz) endgültig, wenn und nur wenn die erforderlichen Markierungen 25 bis 28 durch das Münzregister 6 validiert wurden, d.h. nach der entsprechenden Prüfung vom Zustand „0“ in den Zustand „1“ oder den Zustand „1“ gewechselt wurden. Eine Verarbeitung ist im pseudonymen Modus (bzw. für einen pseudonymisiert maskierten Münzdatensatz) abgeschlossen, wenn die Prüfungen zu den Markierungen 25 bis 27a und 28 durch das Überwachungsregister 6 erfolgt sind.
  • Im Folgenden wird von einer Datenstruktur ohne Abschlussmarkierungen 29 ausgegangen und zunächst die Gültigkeit anonymer Münzdatensätze betrachtet. Um festzustellen, ob ein maskierter elektronischer Münzdatensatz Z gültig ist, sucht das Münzregister 2 nach der letzten Änderung, die den maskierten elektronischen Münzdatensatz Z betrifft. Es gilt, dass der maskierte elektronische Münzdatensatz Z gültig ist, sofern der maskierte elektronische Münzdatensatz Z für seine letzte Verarbeitung in einer der Nachfolger-Spalten 23a, 23b aufgeführt ist, wenn und nur wenn diese letzte Verarbeitung die entsprechende endgültige Markierung 25 bis 28 aufweist. Es gilt auch, dass der maskierte elektronische Münzdatensatz Z gültig ist, sofern der maskierte elektronische Münzdatensatz Z für seine letzte Verarbeitung in einer der Vorgänger-Spalten 22a, 22b aufgeführt ist, wenn und nur wenn diese letzte Verarbeitung fehlgeschlagen ist, also zumindest einer der entsprechend geforderten Zustände der Markierungen 25 bis 28 auf „0“ gesetzt ist.
  • Wenn der maskierte elektronische Münzdatensatz Z nicht in dem Münzregister 2 gefunden wird, ist er ungültig. Es gilt zudem, dass der anonyme maskierte elektronische Münzdatensatz Z für alle übrigen Fälle nicht gültig ist. Beispielsweise wenn die letzte Verarbeitung des maskierten elektronischen Münzdatensatzes Z in einer der Nachfolger-Spalten 23a, 23b aufgeführt ist, diese letzte Verarbeitung aber nie endgültig wurde oder wenn die letzte Verarbeitung des maskierten elektronischen Münzdatensatzes Z in einer der Vorgänger-Spalten 22a, 22b ist und diese letzte Verarbeitung endgültig ist.
  • Die Prüfungen, die durch das Münzregister 2 und/oder das Überwachungsregister 6 erfolgen, um festzustellen, ob eine Verarbeitung endgültig ist, werden durch die Spalten 25 bis 28 abgebildet: Der Zustand in der Spalte 25 zeigt an, ob der/die maskierten elektronischen Münzdatensätze gemäß Vorgänger-Spalten 22a, 22b gültig sind. Der Zustand in der Spalte 26 gibt an, ob die Berechnung des maskierten elektronischen Münzdatensatzes gemäß Gleichung (10) stimmt. Der Zustand in der Spalte 27a gibt an, ob die Bereichsnachweise für die maskierten elektronischen Münzdatensätze Z erfolgreich geprüft werden konnten. Der Zustand in Spalte 28 zeigt an, ob die Signatur in der Spalte 24 des maskierten elektronischen Münzdatensatzes Z eine gültige Signatur der Herausgeberinstanz 1 ist.
  • Der Zustand „0“ in einer Spalte 25 bis 28 zeigt dabei an, dass die Prüfung nicht erfolgreich war. Der Zustand „1“ in einer Spalte 25 bis 28 zeigt dabei an, dass die Prüfung erfolgreich war. Der Zustand „-“ in einer Spalte 25 bis 28 zeigt dabei an, dass keine Prüfung erfolgt ist. Die Zustände können auch einen anderen Wert aufweisen, solange eindeutig zwischen Erfolg/Misserfolg einer Prüfung unterschieden werden kann und ersichtlich ist, ob eine bestimmte Prüfung durchgeführt wurde.
  • Beispielhaft sind fünf verschiedene Verarbeitungen definiert, die hier im Einzelnen erläutert werden. Dabei wird auf den entsprechenden Listeneintrag in der 10 verwiesen.
  • Eine Verarbeitung ist beispielsweise „Erzeugen“ eines elektronischen Münzdatensatzes Ci. Das Erzeugen in der Direkttransaktionsschicht 3 durch die Herausgeberinstanz 1 beinhaltet das Wählen eines monetären Betrags υi und das Erstellen eines Verschleierungsbetrags ri, wie mit Gleichung (1) bereits beschrieben wurde. Wie in 10 gezeigt, bedarf es bei der Verarbeitung „Erzeugen“ keiner Eintragungen/Markierungen in den Spalten 22a, 22b, 23b und 25 bis 27. In der Nachfolger-Spalte 23a wird der maskierte elektronische Münzdatensatz Zi registriert. Diese Registrierung erfolgt bevorzugt vor dem Übertragen 105 an eine Teilnehmereinheit TE, insbesondere oder bereits beim Generieren durch die Herausgeberinstanz 1, wobei in beiden Fällen dazu die Gleichung (3) ausgeführt werden muss. Der maskierte elektronische Münzdatensatz Zi ist beim Erstellen von der Herausgeberinstanz 1 signiert, diese Signatur ist in der Spalte 24 eingetragen, um sicherzustellen, dass der elektronische Münzdatensatz Ci tatsächlich von einer Herausgeberinstanz 1 erstellt wurde, wobei auch andere Verfahren dafür in Frage kommen. Stimmt die Signatur eines erhaltenen Zi mit der Signatur in Spalte 24 überein, so wird die Markierung in Spalte 28 gesetzt (von „0“ auf „1“). Die Markierungen gemäß Spalte 25 bis 27 benötigen keine Statusänderung und können ignoriert werden. Der Bereichsnachweis wird nicht benötigt, da das Münzregister 2 und/oder das Überwachungsregister 6 darauf vertrauen kann, dass die Herausgeberinstanz 1 keine negativen monetären Beträge ausgibt. In einer alternativen Ausführung kann er aber von der Herausgeberinstanz 1 im Erstellen-Befehl mitgesendet werden und von dem Münzregister 2 und/oder dem Überwachungsregister 6 geprüft werden.
  • Eine Verarbeitung ist beispielsweise „Deaktivieren“. Das Deaktivieren, also das Geldvernichten, bewirkt, dass der maskierte elektronische Münzdatensatz Zi nach erfolgreichem Ausführen des Deaktivieren-Befehls durch die Herausgeberinstanz 1 ungültig wird. Man kann also den zu deaktivierenden (maskierten) elektronischen Münzdatensatz in dem Münzregister 2 und/oder in dem Überwachungsregister 6 nicht mehr weiterverarbeiten. Um Verwirrung zu vermeiden, sollten die entsprechenden (nicht maskierten) elektronischen Münzdatensätze Ci auch in der Direkttransaktionsschicht 3 deaktiviert werden. Beim „Deaktivieren“ wird die Vorgängerspalte 22a mit dem elektronischen Münzdatensatz Zi beschrieben, aber keine Nachfolgerspalte 23a, 23b besetzt. Der maskierte elektronische Münzdatensatz Zi ist beim Deaktivieren daraufhin zu prüfen, ob die Signatur mit der Signatur gemäß Spalte 24 übereinstimmt, um sicherzustellen, dass der elektronische Münzdatensatz Ci tatsächlich von einer Herausgeberinstanz 1 erstellt wurde, wobei wieder andere Mittel für diese Prüfung verwendet werden können. Kann das signierte Zi, das im Deaktivieren-Befehl mitgesendet wird, als von der Herausgeberinstanz 1 signiert bestätigt werden, wird die Markierung 28 gesetzt (von „0“ auf „1“) Die Markierungen gemäß Spalte 26 bis 27 benötigen keine Statusänderung und können ignoriert werden. Die Markierungen gemäß Spalte 25 und 28 werden nach entsprechender Prüfung gesetzt.
  • Eine Verarbeitung (Modifikation) ist beispielsweise das „Aufteilen“. Das Aufteilen, also das Teilen eines elektronischen Münzdatensatzes Zi in eine Anzahl n, beispielsweise 2, von elektronischen Münzteildatensätzen Zj und Zk erfolgt zunächst in der Direkttransaktionsschicht 3, so wie es in den 11, 13 und 14 noch gezeigt wird, wobei die monetären Beträge υj und des Verschleierungsbetrags rj generiert werden. vk und rk ergeben sich durch Gleichungen (7) und (8). In dem Münzregister 2 und/oder dem Überwachungsregister 6 werden die Markierungen 24 bis 27 gesetzt, die Vorgängerspalte 22a wird mit dem elektronischen Münzdatensatz Zi beschrieben, Nachfolgerspalte 23a wird mit Zj und Nachfolgerspalte 23b wird mit Zk beschrieben. Die gemäß Spalten 24 bis 27 benötigten Statusänderungen erfolgen nach der entsprechenden Prüfung durch das Münzregister 2 und/oder das Überwachungsregister 6 und dokumentieren das jeweilige Prüfungsergebnis. Die Markierung gemäß Spalte 28 wird insbesondere im anonymen Modus ignoriert. Ein erster Bereichsnachweis R1 nach Spalte 27a muss beispielsweise erbracht werden, um zu zeigen, dass kein monetärer Betrag negativ ist. Ein zweiter Bereichsnachweis R2 in Spalte 27b ist nicht nötig, da die monetären Teilbeträge der Nachfolger stets kleiner als der monetäre Ausgangsbetrag des Vorgängers sind. Ein Summenbereichsnachweis R3 in Spalte 27c ist ebenfalls in der Regel nicht erforderlich (keine neuen monetären Beträge). Die Spalte 24 wird zum Eintragen einer den Münzdatensatz aufteilenden Teilnehmereinheit TE erzeugten Signatur verwendet.
  • Eine Verarbeitung ist beispielsweise „Verbinden“. Das Verbinden, also das Zusammenfügen zweier elektronischer Münzdatensätze Zi und Zj zu einem elektronischen Münzdatensatz Zm erfolgt zunächst in der Direkttransaktionsschicht 3, so wie es in 12 und 13 noch gezeigt wird, wobei der monetäre Betrag υm und der Verschleierungsbetrag rm berechnet werden. In dem Münzregister 2 und/oder dem Überwachungsregister 6 werden die Markierungen 25 bis 28 gesetzt, die Vorgängerspalte 22a wird mit dem elektronischen Münzdatensatz Zi beschrieben, Vorgängerspalte 22b wird mit Zj und Nachfolgerspalte 23b wird mit Zm beschrieben. Die Markierungen in den Spalten 25 bis 28 benötigen Statusänderungen und das Münzregister 2 und/oder das Überwachungsregister 6 führt die entsprechenden Prüfungen durch. Ein erster Bereichsnachweis R1 nach Spalte 27a muss erbracht werden, um zu zeigen, dass kein neues Geld generiert wurde. Ein zweiter Bereichsnachweis R2 in Spalte 27b ist sinnvoll, da der neue monetäre Betrag des Nachfolgers größer sein könnte als ein Maximalwert. Ein Summenbereichsnachweis R3 in Spalte 27c ist ebenfalls in der Regel sinnvoll, da das Endgerät neu empfangene Vorgänger nutzen könnte. Die Markierung gemäß Spalte 28 kann ignoriert werden. Die Spalte 24 wird zum Eintragen einer den Münzdatensatz verbindenden Teilnehmereinheit TE erzeugten Signatur verwendet.
  • Eine weitere Verarbeitung ist beispielsweise „Umschalten“. Das Umschalten ist dann nötig, wenn ein elektronischer Münzdatensatz auf eine andere Teilnehmereinheit TE übertragen wurde und ein erneutes Ausgeben durch die übertragende Teilnehmereinheit TE ausgeschlossen werden soll. Beim Umschalten, auch „switch“ genannt, wird der von der ersten Teilnehmereinheit TE1 erhaltene elektronische Münzdatensatz Ck gegen einen neuen elektronischen Münzdatensatz Cl mit gleichem monetärem Betrag ausgetauscht. Der neue elektronische Münzdatensatz Ci wird von der zweiten Teilnehmereinheit TE2 generiert. Dieses Umschalten ist notwendig, um den von der ersten Teilnehmereinheit TE2 erhaltenen elektronischen Münzdatensatz Ck zu invalideren (ungültig machen), wodurch ein erneutes Ausgeben des gleichen elektronischen Münzdatensatzes Ck vermieden wird. Denn, solange der elektronische Münzdatensatz Ck nicht umgeschaltet ist, kann - da die erste Teilnehmereinheit TE1 in Kenntnis des elektronischen Münzdatensatzes Ck ist - die erste Teilnehmereinheit TE1 diesen elektronischen Münzdatensatz Ck an eine drittes Teilnehmereinheit TE weitergeben. Das Umschalten erfolgt beispielsweise durch Hinzufügen eines neuen Verschleierungsbetrags radd zum Verschleierungsbetrag rk des erhaltenen elektronischen Münzdatensatz Ck, wodurch ein Verschleierungsbetrag rl erhalten wird, die nur die zweite Teilnehmereinheit TE2 kennt. Dies kann auch in dem Münzregister 2 oder dem Überwachungsregister 6 erfolgen. Um zu beweisen, dass nur ein neuer Verschleierungsbetrag radd zum Verschleierungsbetrag rk des maskierten erhaltenen elektronischen Münzdatensatzes Zk hinzugefügt wurde, der monetäre Betrag aber gleichgeblieben ist, und also Gleichung (11): υ k = υ l
    Figure DE102020004122A1_0015
    gilt, so muss die zweite Teilnehmereinheit TE2 nachweisen können, dass sich Zl-Zk als skalares Vielfaches von G also als radd*G darstellen lässt. Das heißt, dass nur ein Verschleierungsbetrag radd erzeugt wurde und der monetäre Betrag von Zi gleich dem monetären Betrag von Zk ist, also Zl=Zk+ radd*G. Dies erfolgt durch das Erzeugen einer Signatur mit dem öffentlichen Schlüssel Zl-Zk=radd*G.
  • Die Modifikationen „Aufteilen“ und „Verbinden“ an einem elektronischen Münzdatensatz können auch von einer Teilnehmereinheit TE1 an eine andere Teilnehmereinheit TE delegiert werden, beispielsweise wenn eine Kommunikationsverbindung zu dem Münzregister 2 und/oder zu dem Überwachungsregister 6 nicht vorhanden ist.
  • In 11 ist ein Ausführungsbeispiel eines Bezahlsystems BZ gemäß der Erfindung zu den Aktionen „Aufteilen“, „Verbinden“ und „Umschalten“ von elektronischen Münzdatensätzen C gezeigt. In 11 hat die erste Teilnehmereinheit TE1 den Münzdatensatz Ci erhalten und möchte nun eine Bezahltransaktion nicht mit dem gesamten monetären Betrag υi, sondern nur mit einem Teilbetrag vk durchführen. Dazu wird der Münzdatensatz Ci aufgeteilt. Dazu wird zunächst der monetäre Betrag geteilt: υ i = υ j + υ k
    Figure DE102020004122A1_0016
  • Dabei muss jeder der erhaltenen Beträge υj, υk, größer 0 sein, denn negative monetäre Beträge sind nicht zulässig.
  • In einer bevorzugten Ausgestaltung erfolgt eine symmetrische Aufteilung des monetären Betrags υi in eine Anzahl n aus gleichgroßen monetäre Teilbeträge υj. υ j = υ i / n
    Figure DE102020004122A1_0017
  • Die Anzahl n ist dabei eine Ganzzahl größer gleich zwei. Beispielsweise kann ein monetärer Betrag von 10 Einheiten in 2 Teilbeträge von 5 Einheiten (n=2) oder in 5 Teilbeträge von jeweils 2 Einheiten (n=5) oder 10 Teilbeträge von jeweils einer Einheit (n=10) aufgeteilt werden.
  • Zudem werden neue Verschleierungsbeträge abgeleitet: r i = r j + r k
    Figure DE102020004122A1_0018
  • Wenn symmetrisch aufgeteilt wird, wird für jeden Münzteilbetrag ein individueller, einzigartiger Verschleierungsbetrag rj in der Teilnehmereinheit TE1 gebildet, wobei die Summe der Anzahl n von Verschleierungsbeträgen rj der Münzteildatensätze gleich dem Verschleierungsbetrag ri des aufgeteilten Münzdatensatz ist: r i = ∑ k = 1 n r j _ k
    Figure DE102020004122A1_0019
  • Es gilt insbesondere, dass der letzte Verschleierungsteilbetrag rj_n gleich der Differenz des Verschleierungsbetrags ri und der Summer der restlichen Verschleierungsteilbeträge ist: r j _ n = r i − ∑ k = 1 n − 1 r j _ k
    Figure DE102020004122A1_0020
  • Auf diese Weise können die Verschleierungsbeträge rj_1 bis rj_n-1 beliebig gewählt werden und die Vorschrift der Gleichung (13a) wird durch entsprechende Berechnung des „letzten“ individuellen Verschleierungsbetrags rj_n erfüllt.
  • Bei einem asymmetrischen Aufteilen werden maskierte Münzdatensätze Zj und Zk gemäß Gleichung (3) aus den Münzdatensätzen Cj und Ck erhalten und in dem Münzregister 2 und/oder dem Überwachungsregister 6 registriert. Für das Aufteilen werden die Vorgängerspalte 22a mit dem Münzdatensatz Zi, die Nachfolgerspalte 23a mit Zj und die Nachfolgerspalte 23b mit Zk beschrieben. Zusätzliche Informationen für den Bereichsnachweis (zero-knowledge-proof) sind zu generieren. Die Markierungen in den Spalten 25 bis 27 benötigen Statusänderung und das Münzregister 2 und/oder das Überwachungsregister 6 führt die entsprechenden Prüfungen durch. Die Markierung gemäß Spalte 28 und der Stauts gemäß Spalte 29 werden ignoriert.
  • Bei einem symmetrischen Aufteilen wird in der jeweiligen Teilnehmereinheit TE eine Signatur berechnet. Dazu wird für den k-te Münzteildatensatz Cj_k der folgende Signaturschlüssel sig verwendet: s i g = r i − n ⋅ r j _ k
    Figure DE102020004122A1_0021
  • Dabei ist n die Anzahl der symmetrisch geteilten Münzteildatensätze. Bei einem symmetrischen Aufteilen kann die Signatur des k-ten Münzteildatensatz Cj_k gemäß (13c) mit folgendem Verifikationsschlüssel Sig geprüft werden: S i g = Z i − n ⋅ Z j _ k
    Figure DE102020004122A1_0022
  • Dabei ist Zj_k der maskierte k-te Münzteildatensatz und n ist die Anzahl der symmetrisch geteilten Münzteildatensätze. Diese Vereinfachung ergibt sich aus dem Zusammenhang mit Gleichung (3): Z i − n ⋅ Z j _ K = ( υ i − n ⋅ υ j _ k ) ⋅ H + ( r i − n ⋅ r j _ k ) ⋅ G
    Figure DE102020004122A1_0023
    wobei durch die Symmetrieeigenschaften der Aufteilung gilt: ( υ i − n ⋅ υ j _ k ) ⋅ H = 0
    Figure DE102020004122A1_0024
    sodass die Gleichung 13e vereinfacht wird zu: Z i − n ⋅ Z j _ K = ( r i − n ⋅ r j _ k ) ⋅ G
    Figure DE102020004122A1_0025
  • Die Vereinfachung aufgrund Gleichung 13f ermöglicht den kompletten Verzicht auf Zero-Knowledge-Nachweise, wodurch die Anwendung einer symmetrischen Aufteilung enorm Rechenleistung und Datenvolumen einspart.
  • Dann wird ein Münzteildatensatz, hier Ck von der ersten Teilnehmereinheit TE1 an die zweite Teilnehmereinheit TE2 übertragen. Um ein doppeltes Ausgeben zu verhindern, ist eine Umschalt-Operation sinnvoll, um den von der ersten Teilnehmereinheit TE1 erhaltenen elektronischen Münzdatensatz Ck gegen einen neuen elektronischen Münzdatensatz Ci mit gleichem monetären Betrag auszutauschen. Der neue elektronische Münzdatensatz Ci wird von der zweiten Teilnehmereinheit TE2 generiert. Dabei wird der monetäre Betrag des Münzdatensatzes Cl übernommen und nicht verändert, siehe Gleichung (11).
  • Dann wird gemäß Gleichung (14) ein neuer Verschleierungsbetrag radd zum Verschleierungsbetrag rk des erhaltenen elektronischen Münzdatensatz Ck hinzugefügt, r l = r k + r a d d
    Figure DE102020004122A1_0026
    wodurch ein Verschleierungsbetrag rl erhalten wird, die nur die zweite Teilnehmereinheit TE2 kennt. Um zu beweisen, dass nur ein neuer Verschleierungsbetrag radd zum Verschleierungsbetrag rk des erhaltenen elektronischen Münzdatensatz Zk hinzugefügt wurde, der monetäre Betrag aber gleichgeblieben ist (υk = υl), muss die zweite Teilnehmereinheit TE2 nachweisen können, dass sich Zl-Zk als Vielfaches von G darstellen lässt. Dies erfolgt mittels öffentlicher Signatur Radd gemäß Gleichung (15): R a d d = r a d d ⋅ G = Z l − Z k = ( v l − v k ) * H + ( r k + r a d d − r k ) * G
    Figure DE102020004122A1_0027
    wobei G der Generatorpunkt der ECC ist. Dann wird der umzuschaltende Münzdatensatz Cl maskiert mittels der Gleichung (3), um den maskierten Münzdatensatz Zl zu erhalten. In dem Münzregister 2 und/oder dem Überwachungsregister 6 kann dann die private Signatur radd genutzt werden um beispielsweise den maskierten umzuschaltenden elektronischen Münzdatensatz Zl zu signieren, was als Beweis gilt, dass die zweite Teilnehmereinheit TE2 nur ein Verschleierungsbetrag radd zum maskierten elektronischen Münzdatensatz hinzugefügt hat und keinen zusätzlichen monetären Wert, d.h. vl = vk.
  • Der Beweis lautet wie folgt: Z k = υ k ⋅ H + r k ⋅ G Z l = υ l ⋅ H + r l ⋅ G = υ k ⋅ H + ( r k + r a d d ) ⋅ G Z l − Z k = ( r k + r a d d − r k ) ⋅ G = r a d d ⋅ G
    Figure DE102020004122A1_0028
  • Die 12 zeigt ein Ausführungsbeispiel eines Bezahlsystems gemäß der Erfindung zum Verbinden (auch Kombinieren genannt) von elektronischen Münzdatensätzen. Dabei werden in der zweiten Teilnehmereinheit TE2 die beiden Münzdatensätze Ci und Cj erhalten. In Anlehnung an das Aufteilen gemäß 11 wird nun ein neuer Münzdatensatz Zm erhalten, indem sowohl die monetären Beträge als auch der Verschleierungsbetrag der beiden Münzdatensätze Ci und Cj addiert werden. Dann wird der erhaltene zu verbindende Münzdatensatz Cm maskiert und der maskierte Münzdatensatz Zm wird in dem Münzregister 2 registriert. Sodann wird beim „Verbinden“ die Signatur der zweiten Teilnehmereinheit TE2 eingetragen, da dieses die Münzdatensätze Ci und Cj erhalten hat.
  • Bei einem Kombinieren durch das Bezahlsystem BZ wird der höchste der beiden einzelnen Prüfwert der jeweiligen elektronischen Münzteildatensätze Ci und Cj bestimmt. Dieser höchste Prüfwert wird als der Prüfwert Ci und Cj des kombinierten elektronischen Münzdatensatzes übernommen.
  • Alternativ wird beim Kombinieren (= Verbinden) durch ein Bezahlsystem BZ ein neuer Prüfwert aus der Summe aller Prüfwerte der elektronischen Münzteildatensätzen Ci und Cj geteilt durch das Produkt der Anzahl (hier zwei) der Münzteildatensätze Ci und Cj mit einem konstanten Korrekturwert bestimmt. Der Korrekturwert ist bezahlsystemweit konstant. Der Korrekturwert ist größer gleich 1. Bevorzugt ist der Korrekturwert von einer maximalen Abweichung der einzelnen Prüfwerte der elektronischen Münzteildatensätze Ci und Cj oder von einem maximalen Prüfwert einer der elektronischen Münzteildatensätze Ci und Cj abhängig. Weiter bevorzugt ist der Korrekturwert kleiner gleich 2. Dieser neue Prüfwert wird als der Prüfwert des kombinierten elektronischen Münzdatensatzes Cm übernommen.
  • In den 13 und 14 ist jeweils ein Ausführungsbeispiel eines Verfahrensablaufdiagramms eines Verfahrens 100. Nachfolgend werden die 13 und 14 gemeinsam erläutert. In den optionalen Schritten 101 und 102 wird ein Münzdatensatz angefragt und seitens der Herausgeberinstanz 1 der ersten Teilnehmereinheit TE1 nach Erstellen des elektronischen Münzdatensatzes bereitgestellt. Ein signierter maskierter elektronischer Münzdatensatz wird im Schritt 103 an das Münzregister 2 und/oder das Überwachungsregister 6 gesendet. Im Schritt 103 erfolgt ein Maskieren des erhaltenen elektronischen Münzdatensatzes Ci gemäß der Gleichung (3) und ein Signieren im Schritt 103p gemäß Gleichung (3a). Dann wird im Schritt 104 der maskierte elektronische Münzdatensatz Zi in dem Münzregister 2 bzw. dem Überwachungsregister 6 registriert. Optional kann die Teilnehmereinheit TE1 den erhaltenen elektronischen Münzdatensatz umschalten, dann würde eine Signatur Si in dem Münzregister 2 bzw. dem Überwachungsregister 6 eingetragen. Im Schritt 105 erfolgt das Übertragen des Münzdatensatzes Ci in der Direkttransaktionsschicht 3 an die zweite Teilnehmereinheit TE2. In den optionalen Schritten 106 und 107 erfolgt eine Validitäts-Prüfung mit vorheriger Maskierung, bei der im Gutfall das Münzregister 2 und/oder das Überwachungsregister 6 die Gültigkeit des Münzdatensatzes Zi bzw. Ci bestätigt wird.
  • Im optionalen Schritt 108 erfolgt dann das Umschalten eines erhaltenen Münzdatensatzes Ck (es könnte natürlich auch der erhaltene Münzdatensatz Ci umgeschaltet werden) auf einen neuen Münzdatensatz Cl, wodurch der Münzdatensatz Ck ungültig wird und ein Doppeltausgeben verhindert wird. Dazu wird der monetäre Betrag vk des übertragenen Münzdatensatzes Ck als „neuer“ monetärer Betrag vl verwendet. Zudem wird, wie bereits mit Gleichungen (14) bis (17) erläutert, der Verschleierungsbetrag rl erstellt. Der zusätzliche Verschleierungsbetrag radd wird verwendet, um zu beweisen, dass kein neues Geld (in Form eines höheren monetären Betrags) von der zweiten Teilnehmereinheit TE2 generiert wurde. Dann wird der maskierte Münzdatensatz signiert und der signierte maskierte umzuschaltende Münzdatensatz Zl an das Münzregister 2 und/oder das Überwachungsregister 6 gesendet und das Umschalten von Ck auf Cl beauftragt. Zudem wird eine Signatur Sk von der ersten Teilnehmereinheit TE1 oder der zweiten Teilnehmereinheit TE2 erstellt und in dem Münzregister 2 und/oder dem Überwachungsregister 6 hinterlegt. Zudem oder alternativ könnte auch eine Signatur Sl erstellt und in dem Münzregister 2 und/oder Überwachungsregister 6 hinterlegt werden, wenn sendende Teilnehmereinheiten TE anstelle empfangende Teilnehmereinheiten TE registriert würden.
  • Im Schritt 108' erfolgt die entsprechende Prüfung in dem Münzregister 2 und/oder dem Überwachungsregister 6. Dabei wird Zk in die Spalte 22a gemäß Tabelle in 10 eingetragen und in Spalte 23b der umzuschreibende Münzdatensatz Zl. Es erfolgt sodann eine Prüfung in dem Münzregister 2 und/oder dem Überwachungsregister 6, ob Zk (noch) gültig ist, also ob die letzte Verarbeitung von Zk in einer der Spalten 23a/b eingetragen ist (als Beweis dafür, dass Zk nicht weiter aufgeteilt oder deaktiviert oder verbunden wurde) und ob eine Prüfung für die letzte Verarbeitung fehlgeschlagen ist. Zudem wird Zl in die Spalte 23b eingetragen und die Markierungen in den Spalten 25, 26, 27 werden zunächst auf „0“ gesetzt. Nun erfolgt eine Prüfung, ob Zl gültig ist, wobei dabei die Prüfung gemäß Gleichungen (16) und (17) verwendet werden können. Im Gutfall wird die Markierung in Spalte 25 auf „1“ gesetzt, ansonsten auf „0“. Nun erfolgt eine Prüfung, die Berechnung gemäß Gleichung (10) ergibt, dass Zk und Zl gültig sind und entsprechend wird die Markierung in Spalte 26 gesetzt. Weiterhin wird geprüft, ob die Bereiche schlüssig sind, sodann wird die Markierung in Spalte 27 gesetzt. Dann wird die Signatur Sl mit dem entsprechend in dem Münzregister 2 und/oder dem Überwachungsregister 6 vorhandenen öffentlichen Verifikationsschlüssel verifiziert und entsprechend protokolliert. Wenn alle Prüfungen erfolgreich waren, und dies entsprechend unveränderlich in dem Münzregister 2 und/oder dem Überwachungsregister 6 festgehalten wurde, gilt der Münzdatensatz als umgeschaltet. D.h. der Münzdatensatz Ck ist nicht mehr gültig und ab sofort ist der Münzdatensatz Cl gültig. Ein Doppeltausgeben ist nicht mehr möglich, wenn eine dritte Teilnehmereinheit TE die Validität des (doppelt ausgegebenen) Münzdatensatz an dem Münzregister 2 und/oder dem Überwachungsregister 6 erfragt. Beim Prüfen der Signatur kann im pseudonymen Modus geprüft werden, ob die zweite Teilnehmereinheit TE2 einen Grenzwert für monetäre Beträge überschritten hat. Die Prüfung erfolgt im Hinblick auf eine Zeiteinheit, beispielsweise könnte ein Tagesgrenzwert damit überwacht werden. Wenn der Grenzwert überschritten ist, verweigert das Münzregister 2 und/oder das Überwachungsregister 6 zunächst das Umschalten des Münzdatensatzes Cl und fordert die zweite Teilnehmereinheit TE2 auf, sich zu deanonymisieren. Systembedingt ist ein deanonymisiertes Umschalten möglicherweise gestattet.
  • Im optionalen Schritt 109 erfolgt ein Verbinden von zwei Münzdatensätzen Ck und Ci auf einen neuen Münzdatensatz Cm, wodurch die Münzdatensätze Ck, Ci ungültig werden und ein Doppeltausgeben verhindert wird. Dazu wird der monetäre Betrag υm aus den beiden monetären Beträgen υk und υi gebildet. Dazu wird der Verschleierungsbetrag rm aus den beiden Verschleierungsbeträgen rk und ri gebildet. Zudem wird mittels Gleichung (3) der maskierte zu verbindende Münzdatensatz Zm erhalten und dieser (mit anderen Informationen zusammen) an das Überwachungsregister 6 und/oder das Münzregister 2 gesendet und das Verbinden als Verarbeitung erbeten. Zudem wird eine Signatur Sk und eine Signatur Si erzeugt und dem Überwachungsregister 6 und/oder dem Münzregister 2 mitgeteilt.
  • Im Schritt 109' erfolgt die entsprechende Prüfung in dem Münzregister 2 und/oder dem Überwachungsregister 6. Dabei wird Zm in die Spalte 23b gemäß Tabelle in 10 eingetragen, was auch gleich einer Umschreibung. Es erfolgt sodann eine Prüfung in dem Münzregister 2 und/oder dem Überwachungsregister 6, ob Zk und Zi (noch) gültig sind, also ob die letzte Verarbeitung von Zk oder Zi in einer der Spalten 23a/b eingetragen ist (als Beweis dafür, dass Zk und Zi nicht weiter aufgeteilt oder deaktiviert oder verbunden wurden) und ob eine Prüfung für die letzte Verarbeitung fehlgeschlagen ist. Zudem werden die Markierungen in den Spalten 25, 26, 27 zunächst auf „0“ gesetzt. Nun erfolgt eine Prüfung, ob Zm gültig ist, wobei dabei die Prüfung gemäß Gleichungen (16) und (17) verwendet werden können. Im Gutfall wird die Markierung in Spalte 25 auf „1“ gesetzt, ansonsten auf „0“. Nun erfolgt eine Prüfung, die Berechnung gemäß Gleichung (10) ergibt, dass Zi plus Zk gleich Zm ist und entsprechend wird die Markierung in Spalte 26 gesetzt. Weiterhin wird geprüft, ob die Bereiche schlüssig sind, sodann wird die Markierung in Spalte 27 gesetzt. Beim Prüfen der Signatur kann geprüft werden, ob die zweite Teilnehmereinheit TE2 einen Grenzwert für monetäre Beträge überschritten hat. Die Prüfung erfolgt im Hinblick auf eine Zeiteinheit, beispielsweise könnte ein Tagesgrenzwert damit überwacht werden. Wenn der Grenzwert überschritten ist, verweigert das Münzregister 2 und/oder das Überwachungsregister 6 zunächst das Verbinden des Münzdatensatzes Cm und fordert die zweite Teilnehmereinheit TE2 auf, sich zu deanonymisieren. Ein deanonymisiertes Verbinden ist dann möglicherweise gestattet.
  • Im optionalen Schritt 110 erfolgt ein asymmetrisches Aufteilen eines Münzdatensatz Ci in zwei Münzteildatensätzen Ck und Cj, wodurch der Münzdatensatz Ci ungültig gemacht wird und die beiden asymmetrisch geteilten Münzteildatensätze Ck und Cj gültig gemacht werden sollen. Bei einem asymmetrischen Aufteilen wird der monetären Betrag υi in verschieden große monetäre Teilbeträge υk und υj aufgeteilt. Dazu wird der Verschleierungsbetrag ri in die beiden Verschleierungsbeträge rk und rj aufgeteilt. Zudem werden mittels Gleichung (3) die maskierten Münzteildatensätze Zk und Zj erhalten und diese mit weiteren Informationen, beispielsweise den Bereichsprüfungen (Zero-knowledge-proofs), an das Münzregister 2 und/oder das Überwachungsregister 6 gesendet und das Aufteilen als Verarbeitung erbeten. Zudem wird eine Signatur Si erstellt und an das Münzregister 2 und/oder an das Überwachungsregister 6 gesendet.
  • Im Schritt 110' erfolgt die entsprechende Prüfung in dem Münzregister 2 und/oder dem Überwachungsregister 6. Dabei werden Zj und Zk in die Spalten 23a/b gemäß Tabelle in 10 eingetragen. Es erfolgt sodann eine Prüfung in dem Überwachungsregister 6 und/oder dem Münzregister 2, ob Zi (noch) gültig ist, also ob die letzte Verarbeitung von Zi in einer der Spalten 23a/b eingetragen ist (als Beweis dafür, dass Zi nicht weiter aufgeteilt oder deaktiviert oder verbunden wurde) und ob eine Prüfung für die letzte Verarbeitung fehlgeschlagen ist. Zudem werden die Markierungen in den Spalten 25, 26, 27 zunächst auf „0“ gesetzt. Nun erfolgt eine Prüfung, ob Zj und Zk gültig sind, wobei dabei die Prüfung gemäß Gleichungen (16) und (17) verwendet werden können. Im Gutfall wird die Markierung in Spalte 25 auf „1“ gesetzt. Nun erfolgt eine Prüfung, die Berechnung gemäß Gleichung (10) ergibt, dass Zi gleich Zk plus Zj ist und entsprechend wird die Markierung in Spalte 26 gesetzt. Weiterhin wird geprüft, ob die Bereiche schlüssig sind, sodann wird die Markierung in Spalte 27 gesetzt. Beim Prüfen der Signatur kann geprüft werden, ob die zweite Teilnehmereinheit TE2 einen Grenzwert für monetäre Beträge überschritten hat. Die Prüfung erfolgt im Hinblick auf eine Zeiteinheit, beispielsweise könnte ein Tagesgrenzwert damit überwacht werden. Wenn der Grenzwert überschritten ist, verweigert das Münzregister 2 und/oder das Überwachungsregister 6 zunächst das Aufteilen des Münzdatensatzes Ci und fordert die zweite Teilnehmereinheit TE2 auf, sich zu deanonymisieren. Ein deanonymisiertes Aufteilen ist dann möglicherweise gestattet.
  • In der 15 ist ein Ausführungsbeispiel einer erfindungsgemäßen ersten Teilnehmereinheit TE1 gezeigt. Die erste Teilnehmereinheit TE1 kann ein Gerät M1 sein, in dem ein Sicherheitselement SE1 eingebracht ist. Zur Vereinfachung wird nachfolgend der Begriff Gerät M1 verwendet. Im Gerät M1 kann elektronische Münzdatensätze Ci in einem Datenspeicher 10, 10' ablegen. Dabei können die elektronischen Münzdatensätze Ci auf dem Datenspeicher 10 des Geräts M1 liegen oder in einem externen Datenspeicher 10' verfügbar sein. Bei Verwenden eines externen Datenspeichers 10' könnten die elektronischen Münzdatensätze Ci in einem Online-Speicher abgelegt sein, beispielsweise einem Datenspeicher 10' eines Anbieters für digitale Geldbörsen. Zusätzlich könnten auch private Datenspeicher, bspw. ein Network-Attached-Storage, NAS in einem privaten Netzwerk verwendet werden.
  • In einem Fall ist der elektronische Münzdatensatz Ci als ein Ausdruck auf Papier dargestellt. Dabei kann der elektronische Münzdatensatz durch einen QR-Code, ein Bild eines QR-Codes dargestellt werden, oder aber auch eine Datei oder eine Zeichenfolge (ASCII) sein.
  • Das Gerät M1 hat mindestens eine Schnittstelle 12 als Kommunikationskanal zum Ausgeben des Münzdatensatzes Ci zur Verfügung. Diese Schnittstelle 12 ist beispielsweise eine optische Schnittstelle, beispielsweise zum Darstellen des Münzdatensatzes Ci auf einem Anzeigeeinheit (Display), oder einen Drucker zum Ausdrucken des elektronischen Münzdatensatzes Ci als Papier-Ausdruck. Diese Schnittstelle 12 kann auch eine digitale Kommunikationsschnittstelle, beispielsweise für Nahfeldkommunikation, wie NFC, Bluetooth, oder eine Internetfähige Schnittstelle, wie TCP, IP, UDP, HTTP oder ein Zugriff auf eine Chipkarte als Sicherheitselement sein. Diese Schnittstelle 12 ist beispielsweise eine Datenschnittstelle, sodass der Münzdatensatz Ci über eine Applikation, beispielsweise einem Instant-Messenger-Dienst oder als Datei oder als Zeichenfolge zwischen Geräten übertragen wird.
  • Zudem ist die Schnittstelle 12 oder eine weitere Schnittstelle (nicht dargestellt) des Geräts M1 dazu eingerichtet, mit dem Münzregister 4 zu interagieren. Das Gerät M1 ist dazu bevorzugt onlinefähig.
  • Darüber hinaus kann das Gerät M1 auch eine Schnittstelle zum Empfang von elektronischen Münzdatensätzen aufweisen. Diese Schnittstelle ist eingerichtet visuell präsentierte Münzdatensätze, beispielsweise mittels Erfassungsmodul wie Kamera oder Scanner, oder digital präsentierte Münzdatensätze, empfangen via NFC, Bluetooth, TCP, IP, UDP, HTTP oder mittels einer Applikation präsentierte Münzdatensätze zu empfangen.
  • Das Gerät M1 umfasst auch eine Recheneinheit 13, die das oben beschriebene Verfahren zum Maskieren von Münzdatensätzen und die Verarbeitungen an Münzdatensätzen durchführen kann.
  • Das Gerät M1 ist onlinefähig und kann bevorzugt mittels eines Standorterkennungs-Moduls 15 erkennen, wenn es mit einem WLAN verbunden ist. Optional kann ein spezifisches WLAN-Netz als bevorzugt markiert sein (=Standortzone), sodass das Gerät M1 besondere Funktionen nur ausführt, wenn es in diesem WLAN-Netz angemeldet ist. Alternativ erkennt das Standorterkennungs-Modul 15, wenn das Gerät M1 in vordefinierten GPS-Koordinaten inklusive eines definierten Radius ist und führt die besonderen Funktionen entsprechend der so definierten Standortzone durch. Diese Standortzone kann entweder manuell in das Gerät M1 oder via andere Einheiten/Module in das Gerät M1 eingebracht werden. Die besonderen Funktionen, die das Gerät M1 bei Erkennen der Standortzone durchführt, sind insbesondere das Übertragen von elektronischen Münzdatensätzen von/zum externen Datenspeicher 10 von/zu einem Tresormodul 14 und ggf. das Übertragen maskierter Münzdatensätze Z an das Münzregister 4 und/oder das Überwachungsregister 6, beispielsweise im Rahmen von den o.g. Verarbeitungen an einem Münzdatensatz. Das Gerät M1 ist demnach dazu eingerichtet, das Verfahren gemäß 6 auszuführen. Das Gerät M1 ist dazu eingerichtet, einen Transaktionsdatensatz TDS zu erstellen und zu verschlüsseln. Das Gerät M1 ist dazu eingerichtet eine Kommunikation zu einem Transaktionsregister zu initiieren. Das Gerät M1 ist dazu eingerichtet den verschlüsselten Transaktionsdatensatz TDS an das Transaktionsregister zu versenden. Das Gerät M1 ist dazu eingerichtet, an den Transaktionsdatensatz TDS Metadaten (im Klartext) anzuknüpfen. Das Gerät M1 ist dazu eingerichtet, den Transaktionsdatensatz TDS lokal (zwischen-) zu speichern.
  • Im einfachsten Fall werden im Gerät M1 alle Münzdatensätze Ci nach Erhalt automatisch zu einem Münzdatensatz verbunden (siehe Verbinden-Verarbeitung bzw. Verbinden-Schritt). Das heißt, sobald ein neuer elektronischer Münzdatensatz empfangen wird, wird ein Verbinden bzw. Umschalten-Befehl an das Münzregister 4 gesendet. Das Gerät M1 kann elektronische Münzdatensätze auch in algorithmisch festgelegten Denominationen vorbereiten und im Datenspeicher 10, 10' vorhalten, damit auch ohne Datenverbindung zum Münzregister 4 und/oder Überwachungsregister 6 ein Bezahlvorgang möglich ist.
  • In 16 ist ein Bezahlsystem zum besseren Verständnis dargestellt. Das erfindungsgemäße Gesamtsystem umfasst eine Herausgeberinstanz (Zentralbank) 1a. Zudem können weitere Herausgeberinstanzen 1b, 1c vorgesehen sein, die beispielsweise elektronische Münzdatensätze in einer anderen Währung ausgeben. Zudem ist mindestens ein Bezahlsystem BZ dargestellt, in dem mindestens ein Münzregister 2, ein Überwachungsregister 6 und ein Transaktionsregister 4 des Bezahlsystems BZ vorgesehen sind, um eine Registrierung der Münzdatensätze Ci bzw. Zi vorzunehmen und die Modifikationen am Münzdatensatz Ci zu prüfen und zu protokollieren. Die Herausgeberinstanz 1a kann auch als Teil des Bezahlsystems BZ vorgesehen sein. Zudem können Bankinstanz(en) zwischen der Herausgeberinstanzen 1a-c und den Bezahlsystem BZ angeordnet sein. Die Register 2, 4, 6 sind beispielsweise in einer Serverinstanz zusammen untergebracht und dort logisch voneinander getrennt. Alternativ sind die Register 2, 4, 6 auch räumlich/physisch voneinander getrennt. Das Transaktionsregister 4 kann auch als eine zum Bezahlsystem BZ externe Einheit angeordnet sein. Zudem ist eine richterliche/gerichtliche Behörde 9 gezeigt, die bei einem Betrugsverdacht eine richterliche Anfrage zum Entschlüsseln von verschlüsselten Transaktionsdatensätzen TDS beim Bezahlsystem BZ (oder direkt dem Transaktionsregister) anfragt. Entfernte Instanzen 8a-c mit entsprechenden Teilschlüsseln sind ebenfalls dargestellt, um im Fall einer Anfrage, ihre Teilschlüssel dem Transaktionsregister 4 zur Verfügung zu stellen, damit ein kryptografischer Schlüssel als Entschlüsselungsschlüssel erhalten wird.
  • Zudem ist in der 16 eine Vielzahl von Teilnehmern, die als Endgeräte Mx (mit jeweiligen SEx) dargestellt sind, vorgesehen. Die Endgeräte M1 bis M6 können Münzdatensätze Ci in der Direkttransaktionsschicht 3 direkt austauschen. Beispielsweise überträgt das Endgerät M5 einen Münzdatensatz an das Endgerät M4. Beispielsweise überträgt das Endgerät M4 den Münzdatensatz an das Endgerät M3. Beispielsweise überträgt das Endgerät M6 einen Münzdatensatz an das Endgerät M1. In jedem sendenden Endgerät Mx bzw. jedem empfangenden Endgerät Mx wird der Prüfwert pi1 des zu sendenden bzw. zu empfangenden Münzdatensatzes und ggf. der Zählerwert pi2 verwendet, um zu prüfen, ob der Münzdatensatz beim Bezahlsystem angezeigt wird und/oder ob der Münzdatensatz bei der Herausgeberinstanz 1a zurückzugeben ist. Das Bezahlsystem BZ prüft beispielsweise anhand des Prüfwerts pi1 bzw. eines vom Prüfwert pi1 abgeleiteten Zählerwertes pi2 für jeden Münzdatensatz C, ob der Münzdatensatz C zurückzugeben ist oder nicht. Zudem ist ein Prüfwert in jedem Endgerät Mx vorgesehen, um eine Anzahl von noch nicht gesendeten Transaktionsdatensätzen TDS trotz übertragener Münzdatensätze zu überwachen.
  • In 17 ist ein Ablaufschema eines Verfahrens gezeigt, mit dem beispielsweise das Einhalten eines Grenzwertes für monetäre Beträge pro Zeiteinheit ermöglicht wird.
  • Im oberen Teil der Figur ist das Bezahlsystem BZ bestehend aus drei Endgeräten M1, M2, M3 gezeigt. Im unteren Teil der Figur sind drei Datenstrukturen 910, 920, 930 der jeweiligen Register 2, 4, 6 gezeigt. In der Datenstruktur 910 des Münzregister 2 sind die gültigen maskierten Münzdatensätze Zi gespeichert. Die Datenstruktur 920 des Überwachungsregisters 6 umfasst die Zuordnung pseudonym gesendeter maskierten Münzdatensätze zu dem Pseudonym und von kann als Überwachungsregister 6 noch zu prüfender pseudonym gesendeter Münzdatensätze betrachtet werden. Anhand der Daten in der Datenstruktur 920 kann das Überwachungsregister 6 entscheiden, ob für ein Pseudonym ein Bereichsnachweis angefordert wird. In der Datenstruktur 930 des Transaktionsregisters sind verschlüsselte Transaktionsdatensätze TDS abgelegt.
  • Folgende Transaktionen wurden durchgeführt:
    1. 1. Das erste Endgerät M1 hat eine Münze aufgeteilt 901. Das Münzregister 2 weiß daher, dass die Münze Cl ein Ergebnis dieser Aufteilung ist und speichert den maskierten Münzdatensatz Zl in der Datenstruktur 910. Das erste Endgerät M1 könnte die Aufteilung dem Überwachungsregister 6 anonym oder pseudonym senden. In der Darstellung wird davon ausgegangen, dass die Endgeräte M1 und M3 ihre maskierten Münzdatensätze anonym an das Überwachungsregister 6 senden.
    2. 2. Das erste Endgerät M1 sendet die Münze Cl direkt an das zweite Endgerät M2 in einem direkten Übertragungsschritt 902. Weder das Münzregister 2 noch das Überwachungsregister 6 erhalten hierüber eine Informationen. Das erste Endgerät M1 erzeugt einen Transaktionsdatensatz TDS902 bezüglich des Übertragenschritts 902, verschlüsselt diesen Transaktionsdatensatz TDS902 und sendet diesen an das Transaktionsregister 4. Der verschlüsselte Transaktionsdatensatz TDS902 beinhaltet eine Kennung des ersten Endgeräts M1, eine Kennung des zweiten Endgeräts M2 und den geldwerten Betrag υl der Münze Cl.
    3. 3. Das zweite Endgerät M2 wandelt die Münze Cl in die Münze C2 um (schaltet um) 903. In der Datenstruktur 910 des Münzregister 2 wird der neue maskierte Münzdatensatz Z2 gespeichert und der alte maskierte Münzdatensatz Zl gelöscht (bzw. als ungültig markiert). Das zweite Endgerät M2 sendet seine maskierten (oder zumindest die dargestellten) Münzdatensätze pseudonymisiert an das Überwachungsregister 6. Somit erhält das Überwachungsregister 6 zudem die Information, dass das zweite Endgerät M2 mit dem Pseudonym PM2 die Münze Cl empfangen hat (und nun Münze C2 besitzt) und speichert entsprechend in der Datenstruktur 920 des Überwachungsregisters 6 den maskierten Münzdatensatz Z2 (und/oder den maskierten Münzdatensatz Zl) für PM2. Zudem wird das Überwachungsregister 6 mindestens einen Prüfungsschritt, wie einen Bereichsnachweis für den Münzdatensatz Z2 oder einen Summenbereichsnachweis für das Endgerät M2, überspringen.
    4. 4. Das zweite Endgerät M2 sendet die Münze C2 in einem weiteren direkten Übertragungsschritt 905 an das dritte Endgerät M3. Weder das Münzregister 2 noch das Überwachungsregister 6 erhalten hierüber eine Informationen. Das zweite Endgerät M2 erzeugt einen Transaktionsdatensatz TDS905 bezüglich des Übertragenschritts 905, verschlüsselt diesen Transaktionsdatensatz TDS905 und sendet diesen an das Transaktionsregister 4. Der verschlüsselte Transaktionsdatensatz TDS905 beinhaltet eine Kennung des zweiten Endgeräts M2, eine Kennung des dritten Endgeräts M3 und den geldwerten Betrag υ2 der Münze C2.
    5. 5. Das dritte Endgerät M3 verbindet im Schritt 904 die empfangene Münze C2 zur verbundenen Münze C3 und sendet diese Information mit anonymen maskierten Münzdatensätzen an das Münzregister 2. Das Münzregister 2 führt alle Prüfungsschritte aus, also insbesondere alle Bereichsnachweise für die beteiligten maskierten Münzdatensätze Z2 ... und Z3 oder auch einen Summenbereichsnachweis für das dritte Endgerät M3. Das Münzregister 2 löscht erst danach den maskierten Münzdatensatz Z2 (sowie die anderen Münzdatensätze des Vorgangs) aus der Datenstruktur 910 und speichert den neuen maskierten Münzdatensatz Z3 als gültigen maskierten Münzdatensatz ab.
    6. 6. Das dritte Endgerät M3 sendet im Schritt 906 die Münze C3 direkt an das zweite Endgerät M2. Weder das Münzregister 2 noch das Überwachungsregister 6 erhalten hierüber eine Informationen. Das dritte Endgerät M3 erzeugt einen Transaktionsdatensatz TDS906 bezüglich des Übertragenschritts 906, verschlüsselt diesen Transaktionsdatensatz TDS906 und sendet diesen an das Transaktionsregister 4. Der verschlüsselte Transaktionsdatensatz TDS906 beinhaltet eine Kennung des dritten Endgeräts M3, eine Kennung des zweiten Endgeräts M2 und den geldwerten Betrag υ3 der Münze C3.
    7. 7. Das zweite Endgerät M2 wandelt in einem weiteren Schritt 903 die Münze C3 in die Münze C4 um (umschalten) und sendet einen maskierten Münzdatensatz Z4 zusammen mit seinem Pseudonym an das Überwachungsregister 6. Das Überwachungsregister 6 erhält die Information führt die notwendigen Prüfungen aus. Mit Hilfe der Datenstruktur 920 bestimmt das Überwachungsregister 6, ob nun für das Pseudonym des Endgerätes M2 eine oder mehrere Prüfungen nachgeholt werden sollen. Ist das Kriterium für ein Nachholen, wie Zeitablauf oder Anzahl an Transaktionen für ein Pseudonym, noch nicht erfüllt, vermerkt lediglich den weiteren maskierten Münzdatensatz Z4 für das Pseudonym in der Datenstruktur 920 des Überwachungsregisters 6. Das Münzregister 2 speichert den maskierten Münzdatensatz Z4 in die Datenstruktur 910 und löscht dort den maskierten Münzdatensatz Z3. Ist ein Kriterium für einen nachholbaren Prüfungsschritt dagegen erfüllt, führt es dagegen zunächst den nachholbaren Prüfungsschritt aus (oder dessen Äquivalent).
  • Das Überwachungsregister 6 hat im konkreten Beispiel die Information, dass das zweite Endgerät M2 die Münze C2 hatte (siehe Schritt 3). Da die Summe der monetären Beträge von Münze C2 und Münze C4 einen Münzschwellwert überschreiten könnte, fordert das Überwachungsregister 6 von dem zweiten Endgerät M2 einen Summenbereichsnachweis (oder eine Summenbereichsbestätigung) an. Der Summenbereichsnachweis zeigt, dass die Summe der monetären Beträge der Münzen C2 und C4 noch nicht das - beispielsweise tägliche - Limit der Transaktionen für das zweite Endgerät M2 überschreitet. Das Überwachungsregister 6 kann auch ein Limit für eine zeitunabhängige Anzahl von Transaktionen überwachen (Bereichsnachweis nach 3/5/10/... Transaktionen). Alternativ oder zusätzlich zu einer Summenprüfung mehrerer Münzdatensätze kann das Überwachungsregister 6 eine Bereichsprüfung für die einzelnen Münzdatensätze nachholen, die in der Datenstruktur 920 des Überwachungsregisters 6 mit dem Pseudonym PM2 verknüpft sind (Ist der monetäre Betrag jedes Münzdatensatzes Z2 und Z4 kleiner als X?). Wurden Prüfungen erfolgreich nachgeholt, können auch die entsprechenden Datensätze in der Datenstruktur 920 des Überwachungsregisters 6 gelöscht werden.
  • Das Transaktionsregister 4 hat in seiner Datenstruktur 930 die Transaktionsdatensätze TDS902, TDS905 und TDS906 in verschlüsselter Form.
  • In einer nicht gezeigten Ausgestaltung der 17 werden die Transaktionsdatensätze entschlüsselt und pseudonymisiert. Bei der Pseudonymisierung werden die Kennungen der Endgerät M1 bis M3 durch die Pseudonyme P ersetzt und der jeweilige Betrag wird in Betragskategorien umgesetzt. Die pseudonymisierten unverschlüsselten Transaktionsdatensätze werden an das Überwachungsregister 6 gesendet. Da die Summe der monetären Beträge von Münze C2 und Münze C4 einen Münzschwellwert überschreiten könnte, fordert das Überwachungsregister 6 von dem zweiten Endgerät M2 einen Summenbereichsnachweis (oder eine Summenbereichsbestätigung) an. Alternativ sind die Betragskategorien in den pseudonymisierten Transaktionsdatensätze TDS* derart aussagekräftig, dass das Überwachungsregister 6 den Summenbereichsnachweis anhand der pseudonymisierten Transaktionsdatensätze TDS* selbst durchführen kann. Alternativ oder zusätzlich zu einer Summenprüfung kann das Überwachungsregister 6 nun auch eine Bereichsprüfung für die einzelnen Münzdatensätze anhand der pseudonymisierten Transaktionsdatensätze TDS* nachholen.
  • In 18 ist ein weiteres Ausführungsbeispiel eines Ablaufs in einem Bezahlsystem BZ mit maskierten Münzdatensätzen gezeigt. Ein erstes Endgerät M1 sendet in Schritten 151 anonyme maskierte Münzdatensätze an das Münzregister 2. Ein zweites Endgerät M2 sendet dagegen in Schritten 161 pseudonymisierte maskierte Münzdatensätze an das Überwachungsregister 6.
  • Das Münzregister 2 reagiert auf jeden der anonymen Sendeschritte 151 des ersten Endgerätes M1 (in seinem anonymen Modus) mit einer (nachholbaren) Prüfung für den maskierten Münzdatensatz oder das erste Endgerät M1. Die gegebenenfalls zusätzlichen, notwendigen Prüfungen sind in 13 nicht dargestellt. In Schritt 152 fordert das Münzregister 2 für jeden maskierten Münzdatensatz einen Bereichsnachweis, dass der monetäre Betrag des maskierten Münzdatensatzes aus dem Schritt 151 unter einem Maximalwert liegt (oder eine entsprechende Bereichsbestätigung). Alternativ oder zusätzlich fordert das Münzregister 2 mit Schritt 152 einen Summenbereichsnachweis (oder - bestätigung) von dem ersten Endgerät M1. Den (oder die) angeforderten Nachweis(e) muss das erste Endgerät M1 in Schritt 153 erstellen und in Schritt 154 senden, damit der (mindestens eine) maskierte Münzdatensatz des Schrittes 151 in dem Münzregister 2 als gültig behandelt wird.
  • Das Überwachungsregister 6 reagiert auf den ersten Sendeschritte 161 des zweiten Endgerätes M2 (in seinem pseudonymen Modus) mit dem Überspringen einer (nachholbaren) Prüfung für den maskierten Münzdatensatz oder das zweite Endgerät M2. Der pseudonym gesendete maskierte Münzdatensatz wird als gültig registriert. Es erfolgen beispielsweise hier nicht dargestellte notwendige Prüfungen, die jedoch nicht eine weitere Kommunikation mit dem zweiten Endgerät M2 voraussetzen. Wie zuvor an anderen Beispielen beschrieben, speichert das das Überwachungsregister 6 eine Zuordnung zwischen dem Pseudonym und dem(/n) pseudonym gesendeten maskierten Münzdatensatz(-sätzen). In dem gezeigten Beispiel reagiert das Überwachungsregister 6 auch auf einen zweiten (oder weitere) Sendeschritte 161 des zweiten Endgerätes M2 analog. Sie prüft dabei jeweils für das Pseudonym, ob ein Nachholkriterium erfüllt ist.
  • Erst im dritten dargestellten Schritt 161 stellt das Überwachungsregister 6 fest, dass für das Pseudonym eine Prüfung nachgeholt werden soll. Es sendet eine Aufforderung 162 an das zweite Endgerät M2, beispielsweise Bereichsnachweise für mehrere Münzdatensätze oder eine Summenbereichsnachweis zu erstellen. In Schritt 163 erstellt das zweite Endgerät M2 mehrere Bereichsnachweise, eine Summenbereichsnachweis oder eine Summenbereichsbestätigung und sendet diese in Schritt 164 an das Überwachungsregister 6. Im Schritt 163 werden beispielsweise mehrere Münzdatensätze des zweiten Endgeräts M2 ausgewählt und über deren monetären Beträge eine Summe gebildet. Diese Münzdatensätze betreffen entweder nur pseudonymisierte Münzdatensätze oder anonyme und pseudonymisierte Münzdatensätze (hierbei wird auf die bereits versendeten maskierten Münzdatensätze abgestellt und die Summe wird aus den monetären Beträgen der korrespondierenden unmaskierten Münzdatensätzen gebildet). Die Auswahl kann anhand von Kriterien getroffen werden, die entweder systembedingt bekannt sind oder im Schritt 162 von dem Überwachungsregister 6 übertragen wurden. Die Kriterien sind beispielsweise ein Zeitraum, insbesondere eine vordefinierte Zeitspanne in der eine Summe aller monetären Beträge einen bestimmten Bereich nicht überschreiten sollten/dürfen, beispielsweise ein monetärere Betrag x Euro pro Zeiteinheit y. Das Kriterium kann alternativ oder zusätzlich auch eine Liste im ersten Endgerät M1 oder dem Überwachungsregister 6 sein. Damit wird eine gewisse Randomisierung des Bereichs möglich, mit der das System noch weiter abgesichert wird. Die gebildete Summe wird dann mit dem Bereich (und ggf. unter Anwendung des Kriteriums) abgeglichen. Im Schritt 164 wird die angeforderte Summenbereichsbestätigung (oder der angeforderte Summenbereichsnachweis) von dem zweiten Endgerät M2 an das Überwachungsregister 6 übertragen.
  • Da eine Bezahltransaktion (Übertragung von Münzdatensätzen) eines großen geldwerten Betrags auch in mehrere Bezahltransaktionen kleinerer geldwerter Beträge aufgeteilt werden kann, die jeweils unterhalb eines Bereichs liegen könnten, wird mit dem Verfahren der Bereich (=Grenzwert) gegebenenfalls endgerätspezifisch und zeitraumabhängig definiert. Der Bereich betrifft in der Regel eine Summe aller Transaktionen innerhalb einer bestimmten Zeiteinheit, die von einem Endgerät empfangen und/oder gesendet werden. Es wird daher ein Mechanismus geschaffen, mit dem festgestellt wird, wie hoch die Summe aller monetären Beträge, die von einem Endgerät gesendet oder empfangen wurden, innerhalb einer bestimmten Zeiteinheit ist.
  • Im Rahmen der Erfindung können alle beschriebenen und/oder gezeichneten und/oder beanspruchten Elemente beliebig miteinander kombiniert werden.
  • Bezugszeichenliste
    • BZ
    Bezahlsystem
    1, 1a-c
    Herausgeberinstanz oder Bank
    2
    Münzregister
    21
    Befehls-Eintrag
    22a, b
    Eintrag eines zu verarbeitenden elektronischen Münzdatensatzes (Vorgänger)
    23a, b
    Eintrag eines verarbeiteten elektronischen Münzdatensatzes (Nachfolger)
    24
    Signatur-Eintrag
    25
    Markierung der Gültigkeitsprüfung
    26
    Markierung der Berechnungsprüfung
    27
    Markierung der Bereichsnachweisprüfung
    28
    Markierung der Signatur-Prüfung
    29
    Abschluss-Markierung
    3
    Direkttransaktionsschicht
    4
    Transaktionsregister
    5
    Applikation gemeinsame Geldbörse
    6
    Überwachungsregister
    7
    Personenregister, Zuordnung von Person zu Kennung
    8a-c
    Teilschlüssel von entfernter Instanz
    9
    Gerichtliche Behörde
    10, 10'
    Datenspeicher
    11
    Anzeige
    12
    Schnittstelle
    13
    Recheneinheit
    14
    Tresormodul
    15
    Standorterkennungs-Modul
    Mx
    x-tes Gerät
    M-ID
    Münzkennung
    Ci
    elektronischer Münzdatensatz
    Cj, Ck
    aufgeteilter elektronischer Münzteildatensatz,
    Cj_k
    k-ter aufgeteilter elektronischer Münzteildatensatz bei symmetrischer Aufteilung
    Cl
    umzuschaltender elektronischer Münzdatensatz
    Cm
    zu verbindendender elektronischer Münzdatensatz
    Zi
    maskierter elektronischer Münzdatensatz
    Zj, Zk
    maskierter aufgeteilter elektronischer Münzteildatensatz
    Zl
    maskierter umzuschaltender elektronischer Münzdatensatz
    Zm
    maskierter zu verbindender elektronischer Münzdatensatz
    S
    Signierter maskierter elektronischer Münzdatensatz
    SEx
    x-tes Sicherheitselement
    TEx
    x-te Teilnehmereinheit
    ID
    Teilnehmerkennung einer Teilnehmereinheit
    TDS
    (verschlüsselter) Transaktionsdatensatz
    TDS*
    Pseudonymisierter/anonymisierter Transaktionsdatensatz
    RDS
    Registerdatensatz
    RDS*
    Pseudonymisierter/anonymisierter Registerdatensatz
    ÜDS
    Überwachungsdatensatzui, Monetärer Betrag
    υj, υj
    Aufgeteilter monetärer Betrag
    υl,
    Monetärer Betrag eines umzuschaltenden/umgeschalteten elektr. Münzdatensatzes
    υm,
    Monetärer Betrag eines zu verbindenden/verbundenen elektr. Münzdatensatz
    pi1,
    Prüfwert (für Direktübertragung des Münzdatensatzes)
    pi2,
    Zählerwert (für Alterung des Münzdatensatzes)
    p
    Prüfwert für Transaktionsregister
    n
    Anzahl symmetrisch geteilter Münzteildatensätze
    ri
    Verschleierungsbetrag, Zufallszahl
    rj, rj
    Verschleierungsbetrag eines aufgeteilten elektronischen Münzdatensatzes
    rm
    Verschleierungsbetrag eines zu verbindenden elektronischen Münzdatensatzes
    Ci*
    übertragener elektronischer Münzdatensatz
    Cj*, Ck*
    übertragener aufgeteilter elektronischer Münzteildatensatz,
    Zi*
    maskierter übertragener elektronischer Münzdatensatz
    Zj*,
    Zk* maskierter übertragener aufgeteilter elektronischer Münzdatensatz
    f(C)
    Homomorphe Einwegfunktion
    [Zi]Sig(PKl)
    Signatur der Herausgeberinstanz
    101-110
    Verfahrensschritte des Bezahlsystems gemäß einem Ausführungsbeispiel
    301-310
    Verfahrensschritte in der Teilnehmereinheit gemäß einem Ausführungsbeispiel
    401-412
    Verfahrensschritte in dem Transaktionsregister gemäß einem Ausführungsbeispiel
  • ZITATE ENTHALTEN IN DER BESCHREIBUNG
  • Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
  • Zitierte Patentliteratur
    • US 5872844 A [0009]

Claims (45)

  1. Ein Bezahlsystem (BZ) zum Bezahlen mit elektronischen Münzdatensätzen (C) mit: - einem Münzregister (2), eingerichtet zum Registrieren der elektronischen Münzdatensätze (C); - Teilnehmereinheiten (TE1, TE2), eingerichtet zum Ausführen von Bezahltransaktionen durch Übertragen der elektronischen Münzdatensätze (C) und zum Senden von Status- und/oder Registrierungsanforderungen betreffend die elektronischen Münzdatensätze (C); und - einem Überwachungsregister (6), eingerichtet zum Auswerten von Überwachungsdatensätzen (ÜDS) betreffend die Bezahltransaktionen, dadurch gekennzeichnet, dass: - ein Überwachungsdatensatz (ÜDS) im Überwachungsregister (6) aus zumindest einem Registerdatensatz (RDS) und zumindest einem Transaktionsdatensatz (TDS) gebildet wird, - wobei der zumindest eine Registerdatensatz (RDS) von dem Münzregister (2) bereitgestellt wird und - wobei der zumindest eine Transaktionsdatensatz (TDS) von einer Transaktionsdatensatzquelle und/oder dem Münzregister (2) bereitgestellt wird.
  2. Das Bezahlsystem (BZ) nach Anspruch 1, wobei das Münzregister (2) in einem ersten Modus nur den zumindest einen Registerdatensatz (RDS) bereitstellt und in einem zweiten Modus den zumindest einen Registerdatensatz (RDS) und den zumindest einen Transaktionsdatensatz bereitstellt.
  3. Das Bezahlsystem (BZ) nach Anspruch 1 oder 2, wobei das Münzregister (2) zudem eingerichtet ist, modifizierte elektronische Münzdatensätze (C) zu registrieren und wobei die Status- und/oder Registeranforderungen der Teilnehmereinheiten (TE1, TE2) zudem die modifizierten elektronischen Münzdatensätze (C) betreffen.
  4. Das Bezahlsystem (BZ) nach einem der vorhergehenden Ansprüche, wobei die Transaktionsdatensatzquelle eine Teilnehmereinheit (TE1, TE2) oder ein Transaktionsregister (4), bevorzugt des Bezahlsystems (BZ), ist.
  5. Das Bezahlsystem (BZ) nach einem der vorhergehenden Ansprüche, wobei jede Teilnehmereinheit (TE1, TE2) eingerichtet ist zum Bereitstellen eines Transaktionsdatensatzes (TDS) betreffend das Übertragen (105) eines elektronischen Münzdatensatzes (C) an eine andere Teilnehmereinheit (TE2) oder betreffend ein beim Münzregister (2) zu registrierenden elektronischen Münzdatensatz (C).
  6. Das Bezahlsystem (BZ) nach einem der vorhergehenden Ansprüche, wobei jeder elektronische Münzdatensatz (C) zumindest einen geldwerten Betrag (υ) als Datenelement und einen Verschleierungsbetrag (r) als Datenelement aufweist, wobei der Verschleierungsbetrag (r) geheim für das Münzregister (2) und das Überwachungsregister (6) ist.
  7. Das Bezahlsystem (BZ) nach Anspruch 6, wobei jeder elektronische Münzdatensatz (C) einen ersten Prüfwert (p1) als Datenelement aufweist, der beim direkten Übertragen (105) des elektronischen Münzdatensatzes (C) zwischen zwei Teilnehmereinheiten (TE1, TE2) inkrementiert wird.
  8. Das Bezahlsystem nach Anspruch 6 oder 7, wobei jeder elektronische Münzdatensatz (C) eine Münzkennung (M-ID) als Datenelement aufweist, wobei die Münzkennung (M-ID) bevorzugt zur Identifizierung eines Registerdatensatzes (RDS) bezüglich des elektronischen Münzdatensatzes (C) und eines Transaktionsdatensatzes (TDS) bezüglich des elektronischen Münzdatensatzes (C) verwendet wird.
  9. Das Bezahlsystem (BZ) nach einem der vorhergehenden Ansprüche, wobei ein Registerdatensatz (RDS) eines oder mehrere der folgenden Datenelemente aufweist: - eine Signatur ([C]Sig) des elektronischen Münzdatensatzes (C); - einen Bereichsnachweis eines elektronischen Münzdatensatzes (C); - einen Prüfwert (p1) des elektronischen Münzdatensatzes (C); - einen Prüfwert (p2) betreffend den elektronischen Münzdatensatz (C); - eine Teilnehmerkennung (ID) einer, den Registerdatensatz (RDS) sendenden Teilnehmereinheit (TE1, TE2); - einen maskierten elektronischen Münzdatensatz (Z); und/oder - einen geldwerten Betrag (υ) des elektronischen Münzdatensatzes (C).
  10. Das Bezahlsystem (BZ) nach einem der vorhergehenden Ansprüche, wobei im Münzregister (2) ein Registerdatensatz (RDS) betreffend den elektronischen Münzdatensatz (C) durch einen zu registrierenden Registrierdatensatz (RDS) betreffend den elektronischen Münzdatensatz (C) oder den modifizierten elektronischen Münzdatensatz (C) ersetzt wird.
  11. Das Bezahlsystem (BZ) nach einem der Ansprüche 2 bis 8, wobei der Modus im Münzregister (2) in Abhängigkeit von einer durchgeführten Authentifizierung einer Teilnehmereinheit (TE1, TE2) am Münzregister (2) eingestellt wird, wobei der zweite Modus im Münzregister (2) nur eingestellt ist, wenn eine Teilnehmereinheit (TE1, TE2) sich am Münzregister (2) erfolgreich authentisiert.
  12. Das Bezahlsystem (BZ) nach Anspruch 9, wobei eine Status- und Registrierungsanforderung betreffend einen elektronischen Münzdatensatz (C) oder einen modifizierten elektronischen Münzdatensatz (C) von einer anonymen Teilnehmereinheit (TE1, TE2) an das Münzregister (2) nur bearbeitet wird, wenn ein Transaktionsdatensatz (TDS) bezüglich des elektronischen Münzdatensatzes (C) oder des modifizierten elektronischen Münzdatensatzes in dem Überwachungsregister (6) auswertbar bereitgestellt wird.
  13. Das Bezahlsystem (BZ) nach einem der vorhergehenden Ansprüche, wobei das Bezahlsystem (BZ) ein Personenregister (7) aufweist, wobei im Personenregister (7) natürliche Personen zu jeweiligen Teilnehmerkennungen (ID) von Teilnehmereinheiten (TE1, TE2) des Bezahlsystems (BZ) und/oder zu jeweiligen Pseudonymen (P) von Teilnehmereinheiten (TE1, TE2) zugeordnet sind.
  14. Das Bezahlsystem (BZ) nach einem der vorhergehenden Ansprüche, wobei ein Registerdatensatz (RDS, RDS*) eine von verschiedenen Anonymitätsstufen aufweist und wobei das Münzregister (2) dazu eingerichtet ist, die Anonymitätsstufe des Registerdatensatzes (RDS, RDS*) vor dem Bereitstellen an das Überwachungsregister (6) einzustellen.
  15. Das Bezahlsystem (BZ) nach einem der vorhergehenden Ansprüche, wobei ein Transaktionsdatensatz (TDS, TDS*) eine von verschiedenen Anonymitätsstufen aufweist, wobei die Transaktionsdatensatzquelle dazu eingerichtet ist, die Anonymitätsstufe des Transaktionsdatensatzes (TDS, TDS*) vor dem Bereitstellen an das Überwachungsregister (6) einzustellen.
  16. Das Bezahlsystem (BZ) nach Anspruch 14 oder 15, wobei zum Einstellen der Anonymitätsstufe eine Teilnehmerkennung (ID) einer Teilnehmereinheit (TE1, TE2) pseudonymisiert oder anonymisiert wird.
  17. Das Bezahlsystem (BZ) nach Anspruch 14, 15 oder 16, wobei zum Einstellen der Anonymitätsstufe ein geldwerter Betrag (υ) eines elektronischen Münzdatensatzes (C) pseudonymisiert oder anonymisiert wird.
  18. Das Bezahlsystem (BZ) nach einem der Ansprüche 14 bis 17, wobei in einem Registerdatensatz (RDS, RDS*) die Anonymitätsstufe eines geldwerten Betrags (υ) eines elektronischen Münzdatensatzes (C) zu der Anonymitätsstufe einer Teilnehmerkennung (ID) einer Teilnehmereinheit (TE1, TE2) verschieden ist.
  19. Das Bezahlsystem (BZ) nach einem der Ansprüche 14 bis 18, wobei in einem Transaktionsdatensatz (TDS, TDS*) die Anonymitätsstufe eines geldwerten Betrags (υ) eines elektronischen Münzdatensatzes (C) zu der Anonymitätsstufe einer Teilnehmerkennung (ID) einer Teilnehmereinheit (TE1, TE2) verschieden ist.
  20. Das Bezahlsystem (BZ) nach einem der Ansprüche 14 bis 19, wobei die Anonymitätsstufe eines geldwerten Betrags (υ) eines elektronischen Münzdatensatzes (C) in einem Transaktionsdatensatz (TDS, TDS*) zu der Anonymitätsstufe eines geldwerten Betrags (υ) eines elektronischen Münzdatensatzes (C) in einem Registerdatensatz (RDS, RDS*) verschieden ist.
  21. Das Bezahlsystem (BZ) nach einem der Ansprüche 14 bis 20, wobei die Anonymitätsstufe einer Teilnehmerkennung (ID) einer Teilnehmereinheit (TE1, TE2) in einem Transaktionsdatensatz (TDS, TDS*) verschieden ist zu der Anonymitätsstufe einer Teilnehmerkennung (ID) einer Teilnehmereinheit (TE1, TE2) im Registerdatensatz (RDS, RDS*).
  22. Das Bezahlsystem (BZ) nach einem der Ansprüche 15 bis 21, wobei die Anonymitätsstufe eines Registerdatensatzes (RDS, RDS*) höher ist als die Anonymitätsstufe eines Transaktionsdatensatzes (TDS, TDS*).
  23. Das Bezahlsystem (BZ) nach einem der Ansprüche 14 bis 22, wobei das Einstellen der Anonymitätsstufe verändert wird, indem eine Teilnehmerkennung (ID) einer Teilnehmereinheit (TE1, TE2) durch ein Pseudonym (P) im Transaktionsdatensatz (TDS, TDS*) oder im Registerdatensatz (RDS, RDS*) ersetzt (410) wird.
  24. Das Bezahlsystem (BZ) nach einem der Ansprüche 14 bis 23, wobei das Einstellen der Anonymitätsstufe verändert wird, indem ein geldwerter Betrag (υ) eines elektronischen Münzdatensatzes (C) durch eine Betragskategorie im Transaktionsdatensatz (TDS, TDS*) oder im Registerdatensatz (RDS, RDS*) ersetzt wird.
  25. Das Bezahlsystem (BZ) nach einem der vorhergehenden Ansprüche, wobei ein Transaktionsdatensatz (TDS, TDS*) eines oder mehrere der folgenden Datenelemente aufweist: - eine Teilnehmerkennung (ID) oder Adresse der ersten Teilnehmereinheit (TE1), - eine Teilnehmerkennung (ID) oder Adresse einer zweiten Teilnehmereinheit (TE2), - einen geldwerten Betrag (υ) des elektronischen Münzdatensatzes (C), - eine Transaktionsnummer, - einen maskierten elektronischen Münzdatensatz (Z) korrespondierend zu dem zu übertragenden oder einem zu modifizierenden oder einem modifizierten elektronischen Münzdatensatz (C), bevorzugt anstelle des geldwerten Betrags (υ) des elektronischen Münzdatensatzes (C), und/oder - einen Transaktionszeitpunkt.
  26. Das Bezahlsystem (BZ) nach einem der vorhergehenden Ansprüche, wobei ein Übertragen (105) eines elektronischen Münzdatensatzes (C) nur ausgeführt wird, wenn ein Prüfen-Schritt in der sendenden Teilnehmereinheit (TE1, TE2) ergibt, dass ein Prüfwert (p1) für eine Anzahl von Übertragungen (105) zu anderen Teilnehmereinheiten (TE) unterhalb einem vordefinierten Schwellwert ist.
  27. Das Bezahlsystem (BZ) nach einem der vorhergehenden Ansprüche, wobei ein elektronischer Münzdatensatz (C) durch Anwenden einer homomorphen Einwegfunktion (f(C)) auf den elektronischen Münzdatensatz (C) durch eine Teilnehmereinheit (TE1, TE2) maskiert wird zum Erhalten eines maskierten elektronischen Münzdatensatzes (Z), wobei der maskierte elektronische Münzdatensatz (Z) in dem Münzregister (2) des Bezahlsystems (BZ) registriert wird, wobei das Registrieren (104) bevorzugt für einen modifizierten elektronischen Münzdatensätzen (C) ist.
  28. Das Bezahlsystem (BZ) nach einem der vorhergehenden Ansprüche, wobei ein elektronischer Münzdatensatz (C) durch Anwenden einer homomorphen Einwegfunktion (f(C)) auf den elektronischen Münzdatensatz (C) durch eine Teilnehmereinheit (TE1, TE2) maskiert wird zum Erhalten eines maskierten elektronischen Münzdatensatzes (Z), wobei der maskierte elektronische Münzdatensatz (Z) in der Teilnehmereinheit (TE1, TE2) mit einem Pseudonym (P) verknüpft wird zum Erhalten eines pseudonymisierten maskierten elektronischen Münzdatensatzes (S) und der pseudonymisierte maskierte elektronische Münzdatensatz (S) an das Münzregister (6) des Bezahlsystems (BZ) gesendet wird.
  29. Eine Teilnehmereinheit (TE1), bevorzugt ein Sicherheitselement (SE), in einem Bezahlsystem (BZ) nach einem der vorhergehenden Ansprüche, wobei die Teilnehmereinheit (TE1) aufweist: - eine Recheneinheit (13), eingerichtet zum Übertragen (105) eines elektronischen Münzdatensatzes (C) an eine andere Teilnehmereinheit (TE2); - Mittel zum Zugreifen auf einen Datenspeicher (10, 10'), wobei im Datenspeicher (10, 10') zumindest ein elektronischer Münzdatensatz (C) abgelegt ist; und - eine Schnittstelle (12) eingerichtet zum Senden von Status- und Registrierungsanforderungen betreffend die elektronischen Münzdatensätze (C) oder die modifizierten elektronischen Münzdatensätze (C) an das Münzregister (2).
  30. Die Teilnehmereinheit (TE1) nach Anspruch 29, wobei die Recheneinheit (13) weiter eingerichtet ist zum Erzeugen eines Transaktionsdatensatzes (TDS) betreffend das Übertragen (105) des elektronischen Münzdatensatzes (C) und wobei die Schnittstelle (12) weiter zum Aufbau einer Kommunikationsverbindung zu einem Transaktionsregister (4) als eine Transaktionsdatenquelle eingerichtet ist, um den erzeugten Transaktionsdatensatz (TDS) an das Transaktionsregister (4) zu senden.
  31. Ein Münzregister (2) in einem Bezahlsystem (BZ) nach einem der vorhergehenden Ansprüche 1 bis 28, wobei das Münzregister (2) aufweist: - eine Recheneinheit eingerichtet zum Einstellen eines ersten Modus oder eines zweiten Modus des Münzregisters entsprechend eines Authentifizierungserfolgs einer Teilnehmereinheit (TE1, TE2) am Münzregister (2), - Mittel zum Zugreifen auf einen Münzspeicher, wobei im Münzspeicher elektronische Münzdatensätze (C) registriert sind; - eine Schnittstelle eingerichtet zum Bereitstellen von Registerdatensätzen (RDS, RDS*) in einem ersten Modus und zum Bereitstellen von Registerdatensätzen (RDS, RDS*) und Transaktionsdatensätzen (TDS, TDS*) in einem zweiten Modus an das Überwachungsregister (6).
  32. Das Münzregister (2) nach Anspruch 31, wobei die Recheneinheit eingerichtet ist, eine Anonymitätsstufe eines Registerdatensatzes (RDS, RDS*) entsprechend der Ansprüche 14 bis 24 einzustellen.
  33. Das Münzregister (2) nach Anspruch 31 oder 32, wobei die Recheneinheit dazu eingerichtet ist, Registerdatensätze (RDS, RDS*) zu erstellen, wobei ein Registerdatensatz (RDS, RDS*) aufweist: - einen maskierten elektronischen Münzdatensatz (Z), der von einer Teilnehmereinheit (TE1, TE2) oder einer Herausgeberinstanz (1) bereitgestellt wird; oder - einen maskierten elektronischen Münzdatensatz (Z) und eine Betragskategorie betreffend einen geldwerten Betrag (υ) eines elektronischen Münzdatensatzes (C) korrespondierend zu dem maskierten elektronischen Münzdatensatz (Z); oder - eine Münzkennung (M-ID) eines elektronischen Münzdatensatzes (C), einen Prüfwert (p, p1, p2) des elektronischen Münzdatensatzes (C) und ein Pseudonym (P) der Teilnehmerkennung (ID).
  34. Das Münzregister (2) nach einem der Ansprüche 31 bis 32, wobei die Schnittstelle oder eine weitere Schnittstelle des Münzregisters (2) eingerichtet ist zum Erhalten von Status- und Registrierungsanforderungen betreffend die elektronischen Münzdatensätze (C) oder die modifizierten elektronischen Münzdatensätze (C) von der Teilnehmereinheit (TE1, TE2).
  35. Das Münzregister (2) nach einem der Ansprüche 31 bis 34, weiter aufweisend einen Status-Verifikator, eingerichtet zum Erstellen einer Statusmeldung bezüglich eines registrierten elektronischen Münzdatensatzes (C) auf Basis einer Statusanforderung von einer Teilnehmereinheit (TE1, TE2), wobei die Schnittstelle oder eine weitere Schnittstelle eingerichtet ist, den Statusbericht der Teilnehmereinheit (TE1, TE2) bereitzustellen, bevorzugt in Form eines Registerdatensatzes (RDS, RDS*).
  36. Das Münzregister (2) nach einem der Ansprüche 31 bis 35, weiter aufweisend einen Änderungs-Verifikator, eingerichtet zum Ändern eines Eintrags im Münzregister (2) bezüglich eines registrierten elektronischen Münzdatensatzes (C) auf Basis einer Registeranforderung von einer Teilnehmereinheit (TE1, TE2).
  37. Das Münzregister (2) nach Anspruch 36, wobei die Schnittstelle oder eine weitere Schnittstelle eingerichtet ist, einen Nachweis bei der Teilnehmereinheit (TE1, TE2) abzufragen, bevor die Änderung des Eintrags bezüglich des registrierten elektronischen Münzdatensatzes (C) im Münzregister (2) registriert wird.
  38. Das Münzregister (2) nach einem der Ansprüche 31 bis 37, wobei die Schnittstelle oder eine weitere Schnittstelle eingerichtet ist, Registerdatensätze (RDS, RDS*) von erzeugten elektronischen Münzdatensätzen (C) von einer Herausgeberinstanz (1) des Bezahlsystems (BZ) zu empfangen.
  39. Das Münzregister (2) nach einem der Ansprüche 31 bis 38, weiter aufweisend: - ein Modul, bevorzugt ein Hardware Security Modul, eingerichtet zum: - Ersetzen von einer Teilnehmerkennung (ID) der Teilnehmereinheit (TE1, TE2) durch ein Pseudonym (P) der Teilnehmereinheit (TE1, TE2) im Registerdatensatz (RDS, RDS*), um einen pseudonymisierten Registerdatensatz (RDS, RDS*) zu erhalten; und/oder - Ersetzen von einem Pseudonym (P) der Teilnehmereinheit (TE1, TE2) durch eine Teilnehmerkennung (ID) der Teilnehmereinheit (TE1, TE2) im Registerdatensatz (RDS, RDS*), um einen identitätsoffenen Registerdatensatz (RDS, RDS*) zu erhalten; und/oder - Ersetzen eines geldwerten Betrags (υ) eines elektronischen Münzdatensatzes (C) durch eine Betragskategorie im Registerdatensatz (RDS, RDS*), um einen pseudonymisierten Registerdatensatz (RDS, RDS*) zu erhalten; und/oder - Ersetzen einer Betragskategorie des elektronischen Münzdatensatzes (C) durch einen geldwerten Betrags (υ) des elektronischen Münzdatensatzes (C) im Registerdatensatz (RDS, RDS*), um einen betragsoffenen Registerdatensatz (RDS, RDS*) zu erhalten.
  40. Ein Transaktionsregister (4) in einem Bezahlsystem (BZ) nach einem der vorhergehenden Ansprüche 1 bis 28, wobei das Transaktionsregister (4) aufweist: - eine Schnittstelle eingerichtet zur Kommunikation mit einer Teilnehmereinheit (TE1, TE2), um einen Transaktionsdatensatz (TDS, TDS*) von der Teilnehmereinheit (TE1, te2) zu empfangen, - Mittel zum Zugreifen auf einen Datenspeicher, wobei im Datenspeicher zumindest ein Transaktionsdatensatz (TDS, TDS*) abgelegt ist.
  41. Das Transaktionsregister (4) nach Anspruch 40, weiter aufweisend: - ein Modul, bevorzugt ein Hardware Security Modul, eingerichtet zum: - Ersetzen von einer Teilnehmerkennung (ID) der Teilnehmereinheit (TE1, TE2) durch ein Pseudonym (P) der Teilnehmereinheit (TE1, TE2) im Transaktionsdatensatz (TDS, TDS*), um einen pseudonymisierten Transaktionsdatensatz (TDS, TDS*)zu erhalten; - Ersetzen von einem Pseudonym (P) der Teilnehmereinheit (TE1, TE2) durch eine Teilnehmerkennung (ID) der Teilnehmereinheit (TE1, TE2) im Transaktionsdatensatz (TDS, TDS*), um einen identitätsoffenen Transaktionsdatensatz (TDS, TDS*) zu erhalten; und/oder - Ersetzen eines geldwerten Betrags (υ) eines elektronischen Münzdatensatzes (C) durch eine Betragskategorie im Transaktionsdatensatz (TDS, TDS*), um einen pseudonymisierten Transaktionsdatensatz (TDS, TDS*) zu erhalten; und/oder - Ersetzen einer Betragskategorie des elektronischen Münzdatensatzes (C) im Transaktionsdatensatz (TDS, TDS*) durch einen geldwerten Betrags (υ) des elektronischen Münzdatensatzes (C), um einen betragsoffenen Transaktionsdatensatz (TDS, TDS*) zu erhalten.
  42. Das Transaktionsregister (4) nach einem der Ansprüche 40 oder 41, wobei die Schnittstelle oder eine weitere Schnittstelle des Transaktionsregisters (4) eingerichtet ist zum Senden eines Transaktionsdatensatzes (TDS, TDS*) an das Überwachungsregister (6) des Bezahlsystems (BZ).
  43. Das Transaktionsregister (4) nach einem der Ansprüche 40 bis 42, wobei die Schnittstelle oder eine weitere Schnittstelle des Transaktionsregisters (4) eingerichtet ist zum Empfangen einer Teilnehmerkennung (ID) oder eines Pseudonyms (P) der Teilnehmerkennung (ID) der Teilnehmereinheit (TE1, TE2) von einem Personenregister (7) des Bezahlsystems (BZ).
  44. Ein Überwachungsregister (6) in einem Bezahlsystem (BZ) nach einem der vorhergehenden Ansprüche 1 bis 28, wobei das Überwachungsregister (6) aufweist: - eine Schnittstelle eingerichtet zum Empfangen von Transaktionsdatensätzen (TDS, TDS*) und/oder Registerdatensätzen (RDS, RDS*) von dem Münzregister (4), wobei die Schnittstelle oder eine weitere Schnittstelle weiter eingerichtet ist zum Empfangen von Transaktionsdatensätzen (TDS, TDS*) von einer Transaktionsdatenquelle (4); und - eine Recheneinheit, eingerichtet zum Bilden von Überwachungsdatensätzen (ÜDS) aus den empfangenen Transaktionsdatensätzen (TDS, TDS*) und Registerdatensätzen (RDS, RDS*) und zum Auswerten der gebildeten Überwachungsdatensätze (ÜDS).
  45. Ein Verfahren zum Bezahlen mit elektronischen Münzdatensätzen (C) in einem Bezahlsystem gemäß der Ansprüche 1 bis 28 mit den Verfahrensschritten: - Registrieren der elektronischen Münzdatensätze (C) in einem Münzregister (2) des Bezahlsystems (BZ); - Ausführen von Bezahltransaktionen durch Übertragen der elektronischen Münzdatensätze (C) durch Teilnehmereinheiten (TE1, TE2) des Bezahlsystems (BZ); - Senden von Status- und/oder Registrierungsanforderungen betreffend die elektronischen Münzdatensätze (C) durch die Teilnehmereinheiten (TE1, TE2) des Bezahlsystems (BZ); - Auswerten von Überwachungsdatensätzen (ÜDS) betreffend die Bezahltransaktionen durch ein Überwachungsregister (6) des Bezahlsystems (BZ); - dadurch gekennzeichnet, dass: - ein Überwachungsdatensatz (ÜDS) im Überwachungsregister (6) aus zumindest einem Registerdatensatz (RDS) und zumindest einem Transaktionsdatensatz (TDS) gebildet wird, - wobei der zumindest eine Registerdatensatz (RDS) von dem Münzregister (2) bereitgestellt wird und - wobei der zumindest eine Transaktionsdatensatz (TDS) von einer Transaktionsdatensatzquelle und/oder dem Münzregister (2) bereitgestellt wird.
DE102020004122.1A 2020-07-08 2020-07-08 Bezahlsystem, münzregister, teilnehmereinheit, transaktionsregister, überwachungsregister und verfahren zum bezahlen mit elektronischen münzdatensätzen Withdrawn DE102020004122A1 (de)

Priority Applications (5)

Application Number Priority Date Filing Date Title
DE102020004122.1A DE102020004122A1 (de) 2020-07-08 2020-07-08 Bezahlsystem, münzregister, teilnehmereinheit, transaktionsregister, überwachungsregister und verfahren zum bezahlen mit elektronischen münzdatensätzen
CN202180053519.4A CN116057555A (zh) 2020-07-08 2021-06-30 支付系统、币登记册、参与者单元、交易登记册、监督登记册和利用电子币数据组进行支付的方法
US18/015,028 US20230267426A1 (en) 2020-07-08 2021-06-30 Payment system, coin register, participant unit, transaction register, monitoring register and method for payment with electronic coin data sets
EP21739313.1A EP4179486A1 (de) 2020-07-08 2021-06-30 Bezahlsystem, münzregister, teilnehmereinheit, transaktionsregister, überwachungsregister und verfahren zum bezahlen mit elektronischen münzdatensätzen
PCT/EP2021/068059 WO2022008320A1 (de) 2020-07-08 2021-06-30 Bezahlsystem, münzregister, teilnehmereinheit, transaktionsregister, überwachungsregister und verfahren zum bezahlen mit elektronischen münzdatensätzen

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102020004122.1A DE102020004122A1 (de) 2020-07-08 2020-07-08 Bezahlsystem, münzregister, teilnehmereinheit, transaktionsregister, überwachungsregister und verfahren zum bezahlen mit elektronischen münzdatensätzen

Publications (1)

Publication Number Publication Date
DE102020004122A1 true DE102020004122A1 (de) 2022-01-13

Family

ID=76829537

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102020004122.1A Withdrawn DE102020004122A1 (de) 2020-07-08 2020-07-08 Bezahlsystem, münzregister, teilnehmereinheit, transaktionsregister, überwachungsregister und verfahren zum bezahlen mit elektronischen münzdatensätzen

Country Status (5)

Country Link
US (1) US20230267426A1 (de)
EP (1) EP4179486A1 (de)
CN (1) CN116057555A (de)
DE (1) DE102020004122A1 (de)
WO (1) WO2022008320A1 (de)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5872844A (en) 1996-11-18 1999-02-16 Microsoft Corporation System and method for detecting fraudulent expenditure of transferable electronic assets
WO2019072264A2 (en) 2018-11-07 2019-04-18 Alibaba Group Holding Limited PROTECTION OF BLOCK CHAIN DATA USING A HOMOMORPHIC ENCRYPTION
EP3549082B1 (de) 2018-11-27 2020-08-26 Alibaba Group Holding Limited System und verfahren zum informationsschutz

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130311348A1 (en) * 2012-03-09 2013-11-21 Gideon Samid Fitting digital currency into modern transactional ecosystems
ZA201502969B (en) * 2014-05-09 2016-01-27 Univ Stellenbosch Enabling a user to transact using cryptocurrency
WO2017218440A1 (en) * 2016-06-13 2017-12-21 CloudMode, LLC Secure initiation and transfer of a cryptographic database and/or a cryptographic unit
KR102256377B1 (ko) * 2019-01-24 2021-05-27 주식회사 더휴먼플러스 블록체인 기반 가상화폐 자동이체 방법 및 그를 위한 서버

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5872844A (en) 1996-11-18 1999-02-16 Microsoft Corporation System and method for detecting fraudulent expenditure of transferable electronic assets
WO2019072264A2 (en) 2018-11-07 2019-04-18 Alibaba Group Holding Limited PROTECTION OF BLOCK CHAIN DATA USING A HOMOMORPHIC ENCRYPTION
EP3549082B1 (de) 2018-11-27 2020-08-26 Alibaba Group Holding Limited System und verfahren zum informationsschutz

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
The Riksbank’s e-krona project Report 2 In: riksbank.se Bearbeitungsstand: Oktober 2018 URL: https://www.riksbank.se/globalassets/media/rapporter/e-krona/2018/the-riksbanks-e-krona-project-report-2.pdf [abgerufen am 21.05.2021]
The technology of retail central bank digital currencyIn: BIS.orgBearbeitungsstand: 01.03.2020URL: https://www.bis.org/publ/qtrpdf/r_qt2003j.htm[abgerufen 21.05.2021]
What is Monero? [The Most Comprehensive Step-by-Step Guide]In: BlockgeeksBearbeitungsstand: 04.05.2020 URL: https://blockgeeks.com/guides/monero/ [abgerufen am 20.05.2021]
Wiese, L., Homann, D., Waage, T. & Brenner, M., (2018) „Homomorphe Verschlüsselung für Cloud-Datenbanken: Übersicht und Anforderungsanalyse." In: Langweg, H., Meier, M., Witt, B. C. & Reinhardt, D. (Hrsg.), SICHERHEIT 2018, Bonn: Gesellschaft für Informatik e.V., S. 221-234, DOI: 10.18420/sicherheit2018_17
X. Han, Y. Yuan and F. Wang, (2019)"A Blockchain-based Framework for Central Bank Digital Currency,"In: IEEE International Conference on Service Operations and Logistics, and Informatics (SOLI), S. 263-268, doi: 10.1109/SOLI48380.2019.8955032.

Also Published As

Publication number Publication date
WO2022008320A1 (de) 2022-01-13
CN116057555A (zh) 2023-05-02
EP4179486A1 (de) 2023-05-17
US20230267426A1 (en) 2023-08-24

Similar Documents

Publication Publication Date Title
DE69534490T2 (de) Verfahren zur sicheren anwendung digitaler unterschriften in einem kommerziellen verschlüsselungssystem
Çabuk et al. A survey on feasibility and suitability of blockchain techniques for the e-voting systems
CN110380858A (zh) 用于区块链的游戏共识协议
CN109417478A (zh) 多链路密码逻辑区块链
EP4111348B1 (de) Verfahren zum direkten übertragen von elektronischen münzdatensätzen zwischen endgeräten, bezahlsystem, währungssystem und überwachungseinheit
DE102019002732A1 (de) Verfahren zum direkten Übertragen von elektronischen Münzdatensätzen zwischen Endgeräten sowie Bezahlsystem
DE102019002731A1 (de) Gerät zum direkten Übertragen von elektronischen Münzdatensätzen an ein anderes Gerät sowie Bezahlsystem
EP3319006A1 (de) Verfahren zur offline-echtheitsprüfung eines virtuellen dokuments
DE112021002053T5 (de) Verrauschte Transaktion zum Schutz von Daten
EP4179487A1 (de) Verfahren, teilnehmereinheit, transaktionsregister und bezahlsystem zum verwalten von transaktionsdatensätzen
DE202015009601U1 (de) System zur persönlichen Identifizierung und Verifizierung
EP4111399B1 (de) Verfahren, endgerät, überwachungsinstanz sowie bezahlsystem zum verwalten von elektronischen münzdatensätzen
EP4179488A1 (de) Herausgabeinstanz und verfahren zum herausgeben von elektronischen münzdatensätzen sowie bezahlsystem
WO2022200035A1 (de) Verfahren und vorrichtung zum erzeugen, bereitstellen und weitergeben eines vertrauenswürdigen elektronischen datensatzes oder zertifikates basierend auf einem einen nutzer betreffenden elektronischen dokument
DE102020004122A1 (de) Bezahlsystem, münzregister, teilnehmereinheit, transaktionsregister, überwachungsregister und verfahren zum bezahlen mit elektronischen münzdatensätzen
EP4111347B1 (de) Verfahren zum direkten übertragen von elektronischen münzdatensätzen zwischen endgeräten, bezahlsystem, währungssystem und überwachungsinstanz
DE102021002329A1 (de) Verfahren zum registrieren eines elektronischen münzdatensatzes in einem münzregister; ein münzregister; eine teilnehmereinheit und ein computerprogrammprodukt
DE102021000570A1 (de) Verfahren zum bereitstellen eines nachweisdatensatzes; verfahren zum prüfen eines nachweisdatensatzes; ein münzregister; eine teilnehmereinheit und ein computerprogrammprodukt
DE102020004117A1 (de) Verfahren, endgerät sowie münzregister zum übertragen von elektronischen münzdatensätzen
Bakshi Improving privacy in e-governance in a country Like India using attribute-based cryptographic Schemes
DE102020104902A1 (de) Verfahren zum direkten übertragen von elektronischen münzdatensätzen zwischen endgeräten, bezahlsystem, währungssystem und überwachungsinstanz
WO2023202836A1 (de) Vorrichtungen, system und verfahren zum elektronischen bargeldlosen bezahlen

Legal Events

Date Code Title Description
R163 Identified publications notified
R081 Change of applicant/patentee

Owner name: GIESECKE+DEVRIENT ADVANCE52 GMBH, DE

Free format text: FORMER OWNER: GIESECKE+DEVRIENT GESELLSCHAFT MIT BESCHRAENKTER HAFTUNG, 81677 MUENCHEN, DE

R119 Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee