Die Erfindung betrifft eine Münzverwaltungseinheit und ein Verfahren zum Verwalten von Münzdatensätzen in einer Münzverwaltungseinheit.

Für eine von einer Zentralbank herausgegebene Digitalwährung (CBDC) sind bereits unterschiedliche technische Lösungsansätze bekannt.

Gemäß einem ersten Ansatz werden Münzdatensätze von einer Zentralbankinstanz nur kryptografisch gesichert und die kryptografisch gesicherten Münzdatensätze direkt zwischen Münzverwaltungseinheiten der Benutzer in verschlüsselter Form ausgetauscht. Die Münzverwaltungseinheiten können anhand der kryptografischen Sicherung, wie Signatur, des Münzdatensatzes dessen Echtheit überprüfen und sollten vorab ein Zertifikat der Zentralbank und/ oder der anderen Münzverwaltungseinheit auf Gültigkeit innerhalb der Zertifikatshierarchie prüfen.

Gemäß einem zweiten Ansatz wird das digitale Geld bzw. werden die Münzdatensätze in einer zentralen oder dezentralen Blockchain einer Zentralbank gespeichert. Wenn ein Münzdatensatz in einer Blockchain im Rahmen einer Transaktion den Besitzer wechselt, werden jedoch oft viele Informationen (Sender/ Empfänger/ Betrag) veröffentlicht und in der Regel benötigen der Sender und der Empfänger zum Zeitpunkt der Transaktion den Zugang zu der Blockchain. Da die Blockchain bzw. dessen Server auf die elektronischen Münzdatensätze zugreifen kann, kann der Server eine Transaktion beispielsweise zu einem vorgegebenen Zeitpunkt selbständig ausführen.

Gemäß einem dritten Ansatz werden die Münzdatensätze durch den Benutzer, beispielsweise in einer lokalen Münzverwaltungseinheit, gespeichert und direkt ausgetauscht. Ein Münzregister speichert eine Registrierung für alle gültigen Münzdatensätze, so dass der Benutzer die Gültigkeit der Münzdatensätze mit Hilfe des Münzregisters überprüfen kann. Da das Münzregister nur Registrierungsdatensätze umfasst, hat es keinen Zugriff auf die Münzdatensätze selbst.

WO 2020/212331 Al verwendet und erweitert diesen dritten Ansatz, durch welchen die Münzdatensätze direkt zwischen den Benutzern ausgetauscht werden können. In WO 2020/212331 Al kann ein direkt ausgetauschter Münzdatensatz auch an einen weiteren Empfänger weitergegeben werden, ohne dass eine Verbindung zu dem Münzregister nötig wäre. Der Empfänger oder der weitere Empfänger kann später einen neuen Münzdatensatz mit gleichem Betrag erzeugen und eine Anforderung an das Münzregister senden, dass die Registrierung des alten Münzdatensatzes im Münzregister durch eine Registrierung des betragsgleichen neuen Münzdatensatzes ersetzt wird.

Ferner beschreibt die WO 2020/212331 Al, dass eine lokale Münzverwaltungseinheit des Benutzers - neben der üblichen Verwaltung der Münzdatensätze einschließlich direktem Austausch der Münzdatensätze und Senden von Registrierungsanforderungen - Münzdatensätze in ein Tresormodul des Benutzers auslagern kann.

Es ist Aufgabe der vorliegenden Erfindung, ein Verfahren, eine Münzverwaltungseinheit oder ein System zu schaffen, in denen eine Bezahltransaktion sicher aber dennoch einfach ausgestaltet ist.

Diese Aufgabe wird gelöst mit einer Münzverwaltungseinheit sowie mit einem Verfahren in einer solchen Einheit, welche die Merkmale der unabhängigen Ansprüche umfassen. Die abhängigen Ansprüche betreffen bevorzugte Ausgestaltungen.

Eine Münzverwaltungseinheit eines Benutzers, umfasst eine Ausführungseinheit zur Verwaltung von digitalen Münzdatensätzen eines digitalen Zentralbankwährungssystems, wobei die Ausführungseinheit angepasst ist, in Transaktionen digitale Münzdatensätze mit anderen Münzverwaltungseinheiten auszutauschen und Registrierungsanforderungen an ein Münzregister der Zentralbank zu senden; und zumindest einen digitalen Münzdatensatz.

Die Münzverwaltungseinheit ist nun angepasst, bedingte Transaktionen als Datenelemente zu speichern, wobei eine Transaktion erst ausgeführt wird, wenn eine Bedingung der gespeicherten bedingten Transaktion erfüllt ist.

Die Münzverwaltungseinheit ist ferner angepasst, die bedingten Transaktionen mit unterschiedlichen Lese- und/ oder Schreibrechten zu speichern.

Mittels der Kombination aus gespeicherter bedingter Transaktion und unterschiedlichen Lese-und/ oder Schreibrechten entsteht eine sehr flexible, vielseitig einsetzbare Lösung. In der Münzverwaltungseinheit weist vorzugsweise mindestens eine erste bedingte Transaktion erste Lese- und/ oder Schreibrechte und mindestens eine zweite bedingte Transaktion zweite, unterschiedliche Lese- und/ oder Schreibrechte auf. Die beiden Lese- und/ oder Schreibrechte können sich in den Leserechten, den Schreibrechten oder den Lese- und den Schreibrechten unterscheiden. Die Münzverwaltungseinheit kann zudem weitere bedingte Transaktionen mit ersten, zweiten oder dritten Lese- und/ oder Schreibrechten umfassen.

In bevorzugten Ausgestaltungen unterscheiden sich die Lese- und/ oder Schreibrechte in den Schreibrechten für den Benutzer und/ oder in den Lese- und/ oder Schreibrechten für Dritte, insbesondere für die anderen Münzverwaltungseinheiten.

Die in der gespeicherten bedingte Transaktion enthaltene Bedingung kann umfassen: eine zeitliche Bedingung, insbesondere einen Zeitpunkt oder eine Periode. Der Zeitpunkt, nach dessen Erreichen die Transaktion auszuführen ist, kann beispielsweise als Uhrzeit, Wochentag und/ oder Datum angegeben sein. Die Periode kann beispielsweise in Stunden, Tagen, Wochen, Monaten und/ oder Jahren angegeben sein, beispielsweise alle 2 Stunden oder täglich oder monatlich. Die Transaktion für die gespeicherte bedingte Transaktion wird dann periodisch (mehrmals) ausgeführt. Sie wird jeweils erneut nach dem Ablauf der Periode ausgeführt.

Die Bedingung kann alternativ eine vergleichende Bedingung sein, insbesondere einen Vergleichswert umfassen, der für einen Vergleich mit einem internen Parameter der Münzverwaltungseinheit, wie Gesamtbetrag der Münzdatensätze in der Münzverwaltungseinheit oder Transaktionszähler oder Transaktionssumme in Zeitraum oder ..., oder mit einem externen Parameter verglichen wird, wie Aktienkurs, Datenelement in einem Server oder einer Datenbank, ... . Den externen Parameter kann die Münzverwaltungseinheit beispielsweise für den Vergleich abrufen oder von einer externen Quelle automatisch erhalten.

Die Bedingung kann weiter alternativ ein Empfangsbedingung sein. Die Transaktion kann insbesondere ausgeführt werden, sobald ein Sicherungswert, wie Signatur, oder ein Codewert, wie Passwort, der bedingten Transaktion empfangen wird. Ebenso jann ein Empfangen einer Empfangstransaktion als Bedingung oder ein Empfangen einer Anfrage für die bedingte Transaktion als Bedingung dienen.

Da die Transaktion erst ausgeführt wird, wenn die in der gespeicherten bedingten Transaktion enthaltene Bedingung erfüllt ist, kann man die Transaktion auch als die auszuführende Transaktion bezeichnen. Im Rahmen der Transaktion wird mit einer anderen Münzverwaltungseinheit ein Münzdatensatz ausgetauscht (gesendet oder empfangen), so dass man die Transaktion gegebenenfalls auch als Austausch- Transaktion bezeichnen könnte.

Die Bedingung kann optional eine Ausführungsbegrenzung enthalten, beispielsweise umfassend eine Ausführungsanzahl (einfach, n-fach oder unbegrenzt oft) und/ oder eine Zeitangabe (ausführbar bis Zeitpunkt).

Die Münzverwaltungseinheit, vorzugsweise deren Ausführungseinheit oder eine Bedingungs-Prüfeinheit, überprüft, ob die Bedingung der bedingten Transaktion erfüllt ist. Das Überprüfen kann dabei insbesondere kontinuierlich, periodisch, beispielsweise stündlich oder täglich (jedoch angepasst an die zu prüfenden Bedingungen), und/ oder in Antwort auf einen Empfangsvorgang in der Münzverwaltungseinheit erfolgen.

Es können unterschiedliche Typen von bedingten Transaktionen in der Münzverwaltungseinheit gespeichert sein. Insbesondere sind zumindest zwei oder drei unterschiedliche Typen von bedingten Transaktionen gespeichert. Als Typen können einzeln oder in Kombination miteinander vorliegen: garantierte bedingte Transaktion, abrufbare bedingte Transaktion, periodische bedingte Transaktion und/ oder bedingte Gegenleistungstransaktion. Vorzugsweise sind in der Münzverwaltungseinheit gespeichert:

- mindestens zwei bedingten Transaktionen eines ersten Typs, welche gleiche oder unterschiedliche Lese- und/ oder Schreibrechte aufweisen, und/ oder

- mindestens zwei bedingte Transaktionen der zumindest zwei unterschiedlichen Typen, welche gleiche oder unterschiedliche Lese- und/ oder Schreibrechte aufweisen.

Die bedingte Transaktion kann neben den Basisdaten der auszuführenden Transaktion, Empfänger, Sender und Betrag, bereits ein oder mehrere weitere Datenelemente der Transaktion, insbesondere den auszutauschenden Münzdatensatz und/ oder die Transaktionsnummer, umfassen. Die bedingte Transaktion kann bereits alle Datenelemente der auszuführenden Transaktion umfassen. Insbesondere für nur vom Benutzer und nicht von Dritten lesbare auszuführende Sendetransaktionen (oder nur vom Sender und nicht vom Benutzer lesbare Empfangstransaktionen) ist eine solche Ausgestaltung möglich. Bevorzugt umfasst die bedingte Transaktion eines oder mehrere der Datenelemente der erst bei Erfüllung der Bedingung auszuführenden Transaktion nicht, insbesondere eines oder mehrere der folgenden Datenelemente:

- einen Identifikator des Senders des mindestens einen Münzdatensatzes, beispielsweise wenn der Sender beliebig ist oder einer Gruppe angehören darf,

- einen Identifikator des Empfängers des mindestens einen Münzdatensatzes, beispielsweise wenn der Sender beliebig ist oder einer Gruppe angehören darf

- eine Transaktionsnummer, insbesondere wenn die Transaktion mehrfach ausführbar ist,

- den mindestens einen Münzdatensatz der auszuführenden Transaktion, nur beispielsweise bei mehrfacher Ausführbarkeit oder bisher fehlendem Transaktionspartner.

Die Münzverwaltungseinheit kann eine Münzverwaltungseinheit mit eigener Ausführungseinheit sein und optional mehrere Münzdepots des Benutzers umfassen. Die Münzverwaltungseinheit kann beispielsweise als Sicherheitsmodul, Chipkarte, Teil eines Mobilfunkgerätes, RFID-, USB- oder Bluetooth-Token oder ... ausgestaltet sein. Die Münzverwaltungseinheit kann in einer Münzdepotverwaltungseinheit, die mehrere Münzdepots, vorzugsweise unterschiedlicher Benutzer, und eine für die mehreren Münzdepots gemeinsame Ausführungseinheit umfasst, vorliegen, wobei die Münzverwaltungseinheit durch eines der Münzdepots zusammen mit der gemeinsamen Ausführungseinheit gebildet ist. Die Münzdepotverwaltungseinheit ist in der Regel ein Server, der den unterschiedlichen Benutzern die Münzdepots bereitstellt.

Jede Münzverwaltungseinheit sollte einen Identifikator (ID) der Münzverwaltungseinheit umfassen und kann optional einen Schlüssel, beispielsweise zur Authentisierung der Münzverwaltungseinheit, und/ oder ein dem Identifikator und/ oder dem (öffentlichen) Schlüssel (des Schlüsselpaares) zugeordnetes Zertifikat umfassen.

Die Münzverwaltungseinheit umfasst zumindest einen Speicherbereich für bedingte Transaktionen der Münzverwaltungseinheit bzw. eines Münzdepots, und zusätzlich einen gemeinsamen Speicherbereich für mehrere Münzdepots - der Münzverwaltungseinheit oder einer Münzdepotverwaltungseinheit mit der Münzverwaltungseinheit -, in welchem eine oder mehrere der folgenden Informationen gespeichert sind:

Referenzen auf eines oder mehrere Münzdepots mit bedingten Transaktionen, insbesondere zeitlich zu prüfende Münzdepots, mehr bevorzugt mit deren Prüfintervall; und/ oder die zu prüfenden Bedingungen von bedingten Transaktionen mehrerer Münzdepots; und/ oder die für jeden Dritten lesbaren bedingten Transaktionen der Münzverwaltungseinheit.

Insbesondere wenn die Bedingungen für viele Münzdepots oder für verschlüsselt gespeicherte Münzdepots zu prüfen sind, ist diese Ausgestaltung hilfreich.

In besonders bevorzugten Varianten sind bedingte Transaktionen anhand der Lese- und/ oder Schreibrechte: von zumindest einer anderen Münzverwaltungseinheit eines anderen Benutzers des digitalen Zentralbankwährungssystems lesbar, aber nur vom Benutzer oder nur gemeinsam vom Benutzer und der zumindest einen anderen Münzverwaltungseinheit des anderen Benutzers des digitalen Zentralbankwährungssystems schreibbar sind; und/ oder nur vom Benutzer lesbar und schreibbar sind; und/ oder von zumindest einer anderen Münzverwaltungseinheit eines anderen Benutzers des digitalen Zentralbankwährungssystems lesbar, aber nur von einer Herausgebereinheit schreibbar sind.

Die Münzverwaltungseinheit kann Vorgaben umfassen, die für auszuführende Transaktionen und/ oder für zu speichernde bedingte Transaktionen geprüft werden. So kann sie insbesondere eingerichtet sein, eine oder mehrere der folgenden Vorgaben vor dem Ausführen von Transaktionen zu prüfen:

- eine Empfängervorgabe, welche die Münzverwaltungseinheit auf genau einen Empfänger, genau eine Empfängergruppe oder auf mehrere Empfänger und/ oder Empfängergruppen beschränkt, und/ oder

- eine Sendervorgabe, welche die Münzverwaltungseinheit auf genau einen Sender, genau eine Sendergruppe oder mehrere Sender und/ oder Sendergruppen beschränkt, und/ oder

- eine funktionelle Vorgabe, die eine von der Ausführungseinheit ausführbare Funktion betreffen, welche insbesondere die ausführbare Funktion für die

Münzverwaltungseinheit, bevorzugt für ein Münzdepot der Münzverwaltungseinheit, vollständig, teilweise oder nicht beschränken; und/ oder

- eine Sende- oder Empfangs-Vorgabe, welche das Senden von Münzdatensätzen respektive das Empfangen von Münzdatensätzen für die Münzverwaltungseinheit, bevorzugt für ein Münzdepot der Münzverwaltungseinheit, beschränkt; und/ oder

- eine Betragsvorgabe mit einem Maximalwert für den Betrag der zu sendenden und/ oder für den Betrag der zu empfangenden Münzdatensätze und/ oder einen Maximalwert oder einen Minimalwert für den Gesamtbetrag der gespeicherten Münzdatensätze;

- eine vom Benutzer wählbare Vorgabe, welche insbesondere vom Benutzer zu wählen ist, so dass sie enger ist als eine vom Herausgeber der Münzverwaltungseinheit festgelegte Vorgabe; und/ oder

- eine Gegenleistungs-Vorgabe, wobei in Antwort auf mindestens einen empfangenen Münzdatensatz als Leistung die Gegenleistung, insbesondere in den Antwortdaten an den Sender des empfangenen Münzdatensatzes, bereitgestellt wird.

Die Münzverwaltungseinheit kann alternativ oder ergänzend Vorgaben umfassen und eingerichtet sein, vor dem Speichern einer bedingten Transaktion die Vorgaben zu prüfen, wobei die Vorgaben vorzugsweise eine Vorgabe für bedingte Transaktionen ist. Als Vorgabe für bedingte Transaktionen kommen beispielsweise - neben den bereits genannten Vorgaben, für Betrag, Empfänger oder Sender, die für bedingte Transaktionen enger sein können als für direkt auszuführende Transaktionen, Vorgaben des Herausgebers der Münzverwaltungseinheit oder des Benutzers in Frage, welche beispielsweise den Typ der bedingten Transaktion und/ oder die Art der Bedingung für die Münzverwaltungseinheit beschränken.

Zwei Münzdepots in der Münzverwaltungseinheit könnten - wie teils bereits beschrieben - dem gleichen Benutzer zugeordnet oder in einer Münzdepotverwaltungseinheit unterschiedlichen Benutzern zugeordnet sein.

Die sichere Ausführungseinheit zur Verwaltung der Münzdatensätze ist zudem vorzugsweise eingerichtet, um

- Transaktionsregisterdaten an ein Transaktionsregister sendet, wobei die Transaktionsregisterdaten insbesondere einen eindeutigen Transaktions-Identifikator, einen Transaktionsbetrag, eine Münzverwaltungseinheits-Identifikator des Senders, eine Münzverwaltungseinheits-Identifikator des Empfängers und die Registerreferenz des Münzdatensatzes im Münzregister umfassen; und/ oder

- Registrierungsanforderungen an das Münzregister sendet, welche mindestens eine Registerreferenz eines bisher im Münzregister registrierten Münzdatensatzes und eine Registerreferenz eines im Münzregister zu registrierenden Münzdatensatzes umfasst.

In dem digitalen Zentralbank-Währungssystem können digitale Münzdatensätze aufgeteilt (in mehrere Münzdatensätze: 10 => 5,5), umgeschaltet (betragsneutraler Tausch: neue Münze gegen alte Münze) oder mit einem anderen Münzdatensatz verbunden werden (neuer Münzdatensatz: 2 +10 =12). Für die neuen Münzdatensätze bzw. deren Referenzen sind dann entsprechende Registrierungsanforderungen an das Münzregister zu senden.

Es wird darauf hingewiesen, dass die Vorgaben und die bedingten Transaktionen als Datenelemente gespeichert werden, sie sind also nicht durch die Programmierung der Münzverwaltungseinheit (Software) festgelegt sind.

Eine bedingte Transaktion mit Lese- und/ oder Schreibrechten kann für einen Münzdepot der Münzverwaltungseinheit gespeichert sein, insbesondere in einem Zwischenspeicher eines Münzdepots der Münzverwaltungseinheit oder in einem münzdepotübergreifenden Zwischenspeicher der Münzverwaltungseinheit

Insbesondere ein Empfänger der Transaktion oder ein Dritter kann beispielsweise die Transaktion auslösen, wenn er den Sicherungswert kennt und ihn als Auslöser (ggf. zusammen mit der ID der Münzverwaltungseinheit und/ oder einer Transaktionsnummer) sendet. Als Sicherungswert kann beispielsweise eine Zufallswert oder ein kryptographischer Sicherungswert (Hashwert von Daten/ Signatur von Daten/...) dienen.

Funktionelle Vorgaben können für die Prüfung der Vorgaben als positives oder negatives Prüfkriterium vorgesehen sein. Die Funktion darf verwendet werden, wenn ein positives Prüfkriterium erfüllt ist bzw. nicht verwendet werden, wenn ein negatives Prüfkriterium erfüllt ist. Für teilweise beschränkende funktionelle Vorgaben werden bevorzugt positive Prüfkriterien verwendet. So enthält vorzugsweise eine teilweise beschränkende Richtungsvorgabe die zulässigen Sender und/ oder Empfänger (positives Prüfkriterium). Alternativ oder ergänzend denkbar ist es, in der Richtungsvorgabe nicht-zulässige Sender und/ oder Empfänger zu speichern (negatives Prüfkriterium). Auch eine vollständige Beschränkung, wie beispielsweise bei einer Richtungsvorgabe „kein Senden" oder „kein Empfangen", kann in einer funktionellen Vorgabe unterschiedlich gespeichert werden. Bevorzugt ist die vollständige Beschränkung als Inhalt der funktionellen Vorgabe gespeichert (wie „nicht zulässig" oder „nein"). Alternativ könnte das Speichern eines leeren Inhalts („" oder „ ") oder eines ungültigen Inhalts (wie „-" als Zahl, ID oder ...) die vollständige Beschränkung angeben. Es kann vorgesehen sein, eine (oder mehrere) nicht beschränkende funktionelle Vorgabe(n) zu speichern. Ein Beispiel wäre ein Münzdepot, dass an beliebige Empfänger senden darf, aber nur von bestimmten Sendern empfangen darf. In bevorzugten Ausgestaltungen wird die nicht beschränkende funktionelle Vorgabe durch das Fehlen dieser Vorgabe angegeben, im Beispiel: für das Münzdepot gibt es eine Sender-Vorgabe aber keine Empfänger-Vorgabe. Alternativ kann jedoch der Inhalt der funktionellen Vorgabe angeben, dass die funktionelle Vorgabe keine Beschränkung enthält, im Beispiel: Empfänger-Vorgabe mit Inhalt „jeder", „alle", oder Ähnliches.

Eine funktionelle Vorgabe für bedingte Transaktionen kann wiederum eine Voll-, Teiloder Nicht-Beschränkung enthalten. So kann die erste funktionelle Vorgabe angeben, dass für das erste Münzdepot bedingte Transaktionen nicht zulässig sind (Vollbeschränkung), und die zweite funktionelle Vorgabe angeben, dass für das zweite Münzdepot bedingte Transaktionen entweder unbeschränkt oder teilbeschränkt möglich sind. Alternativ könnte die erste funktionelle Vorgabe für das erste Münzdepot eine Teilbeschränkung für bedingte Transaktionen enthalten und die zweite funktionelle Vorgabe für das zweite Münzdepot keine Beschränkung für bedingte Transaktionen enthalten. Weiter alternativ könnten die beiden funktionellen Vorgaben für die Münzdepots bedingte Transaktion unterschiedlich beschränken.

Es kann verschiedene Arten von bedingten Transaktionen geben, die sich in ihrer Komplexität und/ oder in ihrer Kodierung (bedingte Transaktion kodiert gemäß Standard A oder Typ B oder proprietär C ...) unterscheiden. Die verschiedenen Arten bedingter Transaktionen werden durch die sichere Ausführungseinheit unterstützt, vorliegend für Münzdepots durch entsprechende Vorgaben jedoch nur noch selektiv bzw. beschränkt zugelassen.

In bevorzugten Ausgestaltungen unterscheidet sich eine Sendevorgabe (bzw. Empfängervorgabe) eines Münzdepots, also insbesondere auch des ersten und/ oder zweiten Münzdepots, von seiner Empfangsvorgabe (bzw. Sendervorgabe). Die Richtungsvorgaben sind für ein Münzdepot also bevorzugt asymmetrisch ausgestaltet.

Die bedingte Transaktion kann aufweisen eine Sende- oder Empfangs-Vorgabe als Bedingung, welche das Senden von Münzdatensätzen respektive das Empfangen von Münzdatensätzen für die Münzverwaltungseinheit, bevorzugt für ein Münzdepot der Münzverwaltungseinheit, beschränkt.

Eine Benutzer-Vorgabe kann vom Benutzer zu wählen sein. Sie wird vorzugsweis so zu wählen sein, dass sie enger ist als die entsprechende vom Herausgeber festgelegte Vorgabe. Der Benutzer hat also die Möglichkeit eine Vorgabe des Herausgebers weiter zu beschränken. Man kann die Vorgaben als Herausgeber-Vorgaben und Benutzer- Vorgaben bezeichnen. Naturgemäß sind system weit gültige Vorgaben (fest in der sicheren Ausführungseinheit programmiert und) nicht mehr vom Herausgeber festlegbar oder vom Benutzer wählbar. Der Herausgeber kann seine Vorgaben entsprechend ebenfalls nur enger als die Systemvorgaben festlegen. Die sichere Ausführungseinheit hält insofern System vorgaben ein und prüft zudem die (funktionellen und anderen) Vorgaben des Münzdepots.

Als Münzverwaltungseinheits-Identifikator wird vorzugsweise

- ein einheitlicher Ressourcenidentifikator, Uniform Resource Identifier (URI), insbesondere nach RFC 3986,

- ein Uniform Resource Name (URN), insbesondere nach RFC 8141, und/ oder

- ein systemweit eindeutiger Identifikator, Universally Unique IDentifier (UUID), insbesondere nach RFC 4122, verwendet. Die URI kann eine UUID und/ oder eine URN enthalten.

Der URI umfasst als Anteile beispielsweise ein Schema, wie URN oder UUID, einen Anbieter, wie Betreibernamen oder Domainnamen des Betreibers, sowie den eindeutigen Anteil, wie UUID oder Seriennummer. In einem Beispiel: urn:uuid:965ecc78-3182-4d5b-8f6a-le325b336031.

Die URN umfasst als Anteile beispielsweise einen Ressourcentyp (Beispiel: Münzverwaltungseinheit), einen Betreibernamen, in der Regel den Domänennamen des Betreibers (Beispiel: meineBank.com), sowie einen zumindest bei dem Betreiber, aber vorzugsweise systemweit, eindeutigen Anteil (Beispiele: Seriennummer oder UUID). Ein Sender und ein Empfänger einer Transaktion könnten dann beispielsweise wie folgt angegeben sein: Sender-ID: münzverwaltungseinheit:meine-bank.com:dlafujr3jbd" bzw. Empfänger-ID: münzverwaltungseinheit:deine-bank.com:3hbbda903988r".

In einer UUID „xxxxxxxx-xxxx-Mxxx-Nxxx-SVxxxxxxxxxx" wird gemäß RFC 4122 im Halfbyte M die Version und im Halfbyte N die Variante der UUID kodiert. Nun kann in mindestens einem weiteren Anteil der UUID, wie beispielsweise den Halfbytes S und/ oder V (in Version 4, Variante 1), eine funktionelle Vorgabe angegeben werden. So kann im Halfbyte S beispielsweise kodiert sein, dass das Münzdepot in einer Münzdepot-Verwaltungseinheit vorliegt. In einem Anteil der UUID, wie diesem oder einem weiteren Halfbyte, können zumindest kurze funktionelle Vorgaben kodiert sein. Beispielsweise könnte in 3 Bits kodiert werden „keine Richtungsbeschränkung", „kein Senden" oder „kein Empfangen". Ebenso könnte in den 3 Bits oder weiteren 3 Bits eine Vorgabe für bedingte Transaktionen kodiert sein, beispielsweise könnte die Zulässigkeit von drei Arten von Bedingungen oder von drei Arten von bedingten Transaktionen kodiert sein. Der Münzverwaltungseinheits-Identifikator kann zumindest eine (kurze) funktionelle Vorgabe oder einen Anteil der funktionellen Vorgaben umfassen. Ein Zertifikat kann mehr Daten enthalten als ein Identifikator. Entsprechend kann das Münzverwaltungseinheits-Zertifikat eine oder mehrere funktionelle Vorgaben enthalten.

Ein Zertifikat kann eine Münzverwaltungseinheit als Mitglied einer Gruppe aus weisen, beispielsweise als Gruppenzertifikat, wie „ID/ Schlüssel gehört zu Gruppe XY", oder als Attributzertifikat, wie „Attribut YZ erfüllt". In der Vorgabe kann eine Empfängergruppe beispielsweise auch durch die Gruppe und/ oder einen Zertifikatstyp angegeben sein, wie „Zertifikat für Gruppe XY" oder „Zertifikat für Attribut YZ". Beispielsweise kann die Vorgabe ein Zertifikat für das Attribut „Buchladen" aus der Verlagsgruppe „SchöneBücher" fordern. In alternativen oder ergänzenden Ausgestaltungen beschränkt zumindest eine teilbeschränkende Empfangsvorgabe das Empfangen von Münzdatensätzen auf genau einen Sender, genau eine Sendergruppe oder mehrere Sender und/ oder Sendergruppen. Der oder die Sender und/ oder Sendergruppe(n) sind in der Vorgabe enthalten, insbesondere durch Angabe einer Sender-ID, einer Sendergruppen-ID oder eines Sender-ID- Anteils oder einer Zertifikatsgruppe. In der Vorgabe kann eine Sendergruppe beispielsweise jedoch auch durch eine Gruppe und/ oder einen Zertifikatstyp angegeben sein, wie „Zertifikat für Gruppe XY" oder „Zertifikat für Attribut YZ". hn Rahmen einer Transaktion wird zumindest ein Münzdatensatz zwischen zwei Münzverwaltungseinheiten ausgetauscht. Vorzugsweise wird für einen aus dem ausgetauschten Münzdatensatz abgeleiteten Münzdatensatz eine Registrierungsanfrage an das Münzregister gesendet und/ oder ein Transaktionsdatensatz an ein Transaktionsregister gesendet. Der zumindest eine Münzdatensatz ist zunächst bei dem Sender, wie erstes oder zweites Münzdepot, des Münzdatensatzes gespeichert. Der Münzdatensatz (oder ein daraus abgeleiteter Münzdatensatz) ist nach der Transaktion beim Empfänger gespeichert. Bevorzugt wird der Münzdatensatz direkt zwischen Sender und Empfänger übertragen, insbesondere kann der Münzdatensatz direkt an einen weiteren Empfänger weitergegeben werden. WO 2020/212331 Al beschreibt bereits das entsprechende Grundprinzip. Die vorliegende Lösung ist jedoch nicht an die dort beschriebene Maskierung des Betrages der Münzdatensätze oder die konkreten Protokolle der WO 2020/212331 Al gebunden. Bedingte Transaktionen werden bevorzugt genau einmal ausgeführt. Es ist jedoch möglich bedingte Transaktionen vorzusehen, die mehrfach ausgeführt werden, insbesondere auch mit oder ohne Begrenzung der Anzahl der Ausführungen (z.b. alle 2 Wochen oder ereignisbedingt genau viermal). Die bedingte Transaktion kann ausgeführt werden, also beispielsweise mit dem gespeicherten Betrag und Empfänger, oder alternativ kann eine - insbesondere von einem Dritten/ Empfänger - angeforderte Transaktion ausgeführt werden, welche unter die gespeicherte, bedingte Transaktion fällt. Also beispielsweise eine vom Empfänger angeforderte Transaktion mit einem Transaktionsbetrag, der kleiner ist als der gespeicherte Betrag und/ oder einem Empfänger, der zu einer gespeicherten Empfängergruppe gehört.

Münzdepots können einem ersten (dem gleichen) Benutzer zugeordnet sein. Der erste Benutzer hat beispielsweise zwei Münzdepots in der Münzverwaltungseinheit, die unterschiedliche Vorgaben umfassen. Alternativ kann ein erstes Münzdepot einem ersten Benutzer und ein zweites Münzdepot einem zweiten Benutzer zugeordnet sein. Der erste und/ oder der zweite Benutzer kann mehrere Münzdepots in der Münzverwaltungseinheit sowie eine (oder mehrere) lokale Münzverwaltungseinheit(en) haben, beispielsweise in der Form eines Sicherheitsmoduls, wie Chipkarte, SIM-Karte, RFID-Token, NFC-Modul, eingebautes Sicherheitsmodul.

Eine Münzdepotverwaltungseinheit für mehrere Benutzer wird von einem Betreiber bereitgestellt, der beispielsweise ein Finanzdienstleister, wie eine Geschäftsbank, ein Kreditkartenanbieter oder ein Zahlungsdienstleister (Paypal, ...), sein kann. Das Erstellen des Münzdepots wird in der Regel von einem Dritten, dem Herausgeber, beauftragt.

Das Münzdepot kann eine teilweise frei auslesbare Vorgabe umfassen, insbesondere auch die funktionellen Vorgaben. Insbesondere können ein auslesbarer Anteil und ein nicht auslesbarer Anteil der mindestens teilweise frei auslesbaren Vorgabe vorliegen. Die beiden Anteile sind bevorzugt in unterschiedlichen Datenelementen gespeichert, insbesondere einem frei auslesbaren Datenelement, wie dem Münzverwaltungseinheits-Zertifikat oder -Identifikator oder einem nicht-vertraulichen Vorgabedatenelement, und in einem nicht frei auslesbaren Datenelement des Münzdepots, wie einem dedizierten vertraulichen Vorgabendatenelement. Alternativ sind die beiden Anteile in einem gemeinsamen Datenelement nicht frei auslesbar gespeichert und zusätzlich ist der lesbare Anteil in einem separaten lesbaren Datenelement gespeichert, wie dem Münzverwaltungseinheits-Zertifikat oder - Identifikator oder einem nicht- vertraulichen Vorgabedatenelement.

Die sichere Ausführungseinheit kann zur Verwaltung der Münzdatensätze Transaktionsregisterdaten an ein Transaktionsregister senden. Die Transaktionsregisterdaten umfassen insbesondere einen eindeutigen Transaktions- Identifikator, einen Transaktionsbetrag, eine Münzverwaltungseinheits-Identifikator des Senders, eine Münzverwaltungseinheits-Identifikator des Empfängers und die (mindestens eine) Registerreferenz des Münzdatensatzes im Münzregister.

Alternativ oder ergänzend kann die sichere Ausführungseinheit zur Verwaltung der Münzdatensätze Registrierungsanforderungen an das Münzregister senden, welche insbesondere mindestens eine Registerreferenz eines bisher im Münzregister registrierten Münzdatensatzes und eine Registerreferenz eines im Münzregister zu registrierenden Münzdatensatzes umfasst.

Ein Verfahren zur Verwaltung von Münzdatensätzen eines digitalen Zentralbankwährungssystems mit Münzregister in einer Münzverwaltungseinheit, die eine Ausführungseinheit und zumindest einen Münzdatensatz der Zentralbank umfasst, umfasst die folgenden Schritte in der Münzverwaltungseinheit.

Speichern einer ersten bedingten Transaktion, die eine Bedingung für das Ausführen einer Transaktion enthält, wobei die Transaktion den Austausch zumindest eines Münzdatensatzes zwischen der Münzverwaltungseinheit und einer anderen Münzverwaltungseinheit des digitalen Zentralbankwährungssystems umfasst. Die erste bedingte Transaktion wird dabei in der Münzverwaltungseinheit als Datenelement gespeichert und die gespeicherte erste bedingte Transaktion weist Lese- und/ oder Schreibrechte auf, die sich von Lese- und/ oder Schreibrechte einer bereits gespeicherten zweiten bedingten Transaktion unterscheiden.

Prüfen ob die Bedingung erfüllt ist, und Ausführen der Transaktion erst wenn die Bedingung erfüllt ist.

Alle vorherigen Anmerkungen zur Vorrichtung sind in diesem zugehörigen Verfahren analog anwendbar. Das Ausführen der Transaktion umfasst vorzugsweise: ein Senden des Münzdatensatzes an die andere Münzverwaltungseinheit oder ein Empfangen des Münzdatensatzes von der anderen Münzverwaltungseinheit; und/ oder ein Senden einer Registrierungsanforderung an ein Münzregister der Zentralbank, welche insbesondere mindestens eine Registerreferenz eines bisher im Münzregister registrierten Münzdatensatzes und eine Registerreferenz eines im Münzregister zu registrierenden Münzdatensatzes umfasst, und/ oder ein Senden von Transaktionsregisterdaten an ein Transaktionsregister, und/ oder das Bereitstellen einer Gegenleistung, insbesondere nach einem Empfangen des Münzdatensatzes als die Bedingung.

Das Verfahren kann zudem den Lese- und/ oder Schreibvorgang umfassen. Vorzugsweise folgende Schritte können erfolgen:

- Empfangen einer Lese- und/ oder Schreibanfrage eines Anfragenden, insbesondere eines Benutzers der Münzverwaltungseinheit oder einer anderen Münzverwaltungseinheit, für zumindest eine bedingte Transaktion;

- optionales Prüfen einer Authentisierung des Anfragenden;

- Prüfen der Lese- und/ oder Schreibrechte der zumindest einen bedingten Transaktion,

- Beantworten der Lese- und/ oder Schreibanfrage abhängig von den Lese- und/ oder Schreibrechten, insbesondere im Fall einer Leseanfrage durch Bereitstellen der bedingten Transaktion für den Anfragenden oder im Fall einer Schreibanfrage durch Schrieben der bedingten Transaktion.

Das Ausführen der Transaktion kann umfassen: ein Senden oder ein Empfangen eines Münzdatensatzes der Zentralbank, und/ oder ein Senden einer Registrierungsanforderung an ein Münzregister der Zentralbank, welche insbesondere für einen empfangenen bisher registrierten Münzdatensatz die Registrierung eines in der neuen Münzverwaltungseinheit zu speichernden Münzdatensatzes anfordert, und/ oder ein Senden von Transaktionsregisterdaten an ein Transaktionsregister, und/ oder das Bereitstellen einer Gegenleistung, wobei insbesondere die Transaktions- Anforderung einen Münzdatensatz umfasst.

Eine Transaktions- Anfrage umfasst insbesondere einen Transaktionsbetrag, einen Münzverwaltungseinheits-Identifikator des Senders sowie eine Münzverwaltungseinheits-Identifikator des Empfängers. Nur optional umfasst sie ferner einen eindeutigen Transaktions-Identifikator und/ oder einen Transaktions- Bezugstext. Eine Transaktions-Anfrage sendet in der Regel der Benutzer des Münzdepots. In Ausgestaltungen kann die Transaktions- Anfrage auch von einer anderen Münzverwaltungseinheit oder einem Transaktionspartner (Sender oder Empfänger von Münzdatensätzen) an die Münzdepot-Verwaltungseinheit gesendet werden. Der Schritt des Ausführens der Transaktion umfasst das Senden mindestens eines Münzdatensatzes des Münzdepots zu einem Empfänger (oder das Empfangen mindestens eines Münzdatensatzes, der insbesondere in der Transaktions- Anfrage enthalten ist). In dem Schritt des Ausführens der Transaktion kann ein zu übertragender Münzdatensatz erzeugt und beim Münzregister registriert werden, insbesondere wenn der Betrag des zu übertragenden Münzdatensatzes einem Transaktionsbetrag entsprechen soll. Mindestens ein Münzdatensatz, also gegebenenfalls zwei oder mehrere Münzdatensätze, des Münzdepots werden in dem Schritt des Ausführens der Transaktion übertragen. Münzdatensätze können separat oder in Transaktionsnachrichten, beispielsweise zusammen mit einer Transaktions-ID, übertragen werden, insbesondere wenn bereits eine verschlüsselte Verbindung zwischen Sender und Empfänger aufgebaut ist. Alternativ kann jedoch (gerade zwischen Münzdepot-Verwaltungseinheiten) auch eine vollständige Transaktionsnachricht übertragen werden. Eine vollständige Transaktionsnachricht enthält insbesondere die in der Transaktions-Anfrage enthaltenen Datenelemente und den mindestens einen Münzdatensatz.

Transaktions-Anfragen, Münzdatensätze und/ oder vollständige Transaktionsnachrichten können bevorzugt in einer http-Nachricht enthalten sein. Transaktions-Anfragen, Münzdatensätze und/ oder vollständige Transaktionsnachrichten können alternativ oder ergänzend in einem JSON-Format übertragen werden. Das JavaScript Object Notation(JSON)-Format entspricht vorzugsweise RFC 8259 (und/ oder ECMA 404 bzw. ISO/IEC 21778). Eine TransaktionID kann als UUID formatiert sein. Eine Transaktions- Anfrage könnte dann beispielsweise wie folgt formatiert sein:

{

"Sender": "urn:münzverwaltungseinheit:meine-bank.com:dlafujr3jbd",

"Empfänger": "urn:münzverwaltungseinheit:deine-bank.com:3hbbda903988r", „Betrag": „1,60 eCBDC"

"Transaktions-Bezugstext": " Vorgangs nummer 1234898942"

}

Eine zugehörige Transaktions-Nachricht, hier mit 2 Münzdatensätzen, könnte dann beispielsweise wie folgt formatiert sein:

{

"Transaktions-ID": "lcl02b5f-5496-459d-8a67-3bflc348bll3",

"Sender": "urn:münzverwaltungseinheit:meine-bank.com:dlafujr3jbd", "Empfänger": "urn:münzverwaltungseinheit:deine-bank.com:3hbbda903988r",

"Münzdatensätze": [

{

"Betrag": 1000, "... Nummer":„116e782982383e9d0ea2c728f2a5f80d8a6121"

},

{

"Betrag": 60, "... Nummer": „Iaaa77777777777733333c9123812123712814"

}

],

"Transaktions-Bezugstext": "Rechnung 1234898942"

}

Die beschriebenen Verfahren können in einer der zuvor beschriebenen Münzdepot- Verwaltungseinheiten ausgeführt werden. Die unterschiedlichen Verfahren und Ausgestaltungen sind miteinander kombinierbar und können beispielsweise unterschiedliche Münzdepots oder jeweils das erste und/ oder zweite Münzdepot betreffen.

Ein digitales Zentralbank-Währungs-System umfasst eine Münzverwaltungseinheit - in einer der beschriebenen Ausgestaltungen bzw. eingerichtet zur Ausführung eines der beschriebenen Verfahren. Das System umfasst ferner das Münzregister der Zentralbank sowie optional eine Vielzahl von Münzverwaltungseinheiten und/ oder ein Transaktionsregister.

Die vorliegende Lösung ist besonders vorteilhaft, da die hohe Flexibilität in der Münzdepot-Verwaltungseinheit unabhängig von dem Münzregister und/oder dem Transaktionsregister angeboten werden kann. Insbesondere wird das Münzregister, an welches in einem digitalen Währungssystem bereits besonders hohe Anforderungen gestellt werden, nicht verlangsamt.

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: Fig.l ein digitales Zentralbank-Währungs-System mit Münzverwaltungseinheiten sowie einem Münzregister der Zentralbank;

Fig.2 eine Münzverwaltungseinheit mit einer Ausführungseinheit und einem Münzdatensatz;

Fig.3 ein digitales Zentralbank-Währungs-System mit einer Münzdepot- verwaltungs-Einheit;

Fig.4 eine Münzdepot-Verwaltungseinheit;

Fig.5 ein Ablaufdiagramm für ein Verfahren mit einer Transaktions- Anforderung;

Fig.6 ein Ablauf diagramm für ein Verfahren mit einer Münzdepot- Anforderung;

Fig.7 ein Ablauf diagramm für ein Verfahren mit einer Anforderung einer bedingten Transaktion;

Fig. 8 ein Ausführungsbeispiel für Vorgaben eine Münzdepots; und

Fig. 9 ein Ausführungsbeispiel einer Liste mit bedingten Transaktionen.

Fig. 1 zeigt ein digitales Zentralbank-Währungs-System, wie es für sich genommen bereits bekannt ist. Durch gestrichelte Linien ist die Unterteilung des Systems in eine Ausgabeschicht 1, eine Systemverwaltungsschicht 2 und eine Transaktionsschicht 3 dargestellt.

Eine Zentralbankinstanz 10 gibt digitale Münzdatensätze 5 heraus. Die Zentralbankinstanz 10 fordert zudem eine initiale Registrierung des digitalen Münzdatensatzes 5 in einem Münzregister 20 der Zentralbank an. Münzverwaltungseinheiten 210, 220 können digitale Münzdatensätze austauschen und Registrierungsanforderungen an das Münzregister 20 senden.

In einem optionalen Transaktionsregister 25 werden Transaktionsdatensätze 7 gespeichert. Ein Transaktionsdatensatz 7 wird beispielsweise den Transaktionsbetrag, eine Transaktions-ID, Identifikatoren für Sender und Empfänger, hier der Münzverwaltungseinheit 210 als Sender und der Münzverwaltungseinheit 220 als Empfänger, und zumindest die Registerreferenz des übertragenen Münzdatensatzes 5 umfassen.

Das Münzregister 20 speichert zumindest für jeden gültigen digitalen Münzdatensatz 5 einen Registerdatensatz 6. Der Registerdatensatz 6 enthält beispielsweise den Betrag des Münzdatensatzes und eine Registerreferenz. Die Registerreferenz ist aus dem Münzdatensatz 5 ableitbar, erlaubt jedoch nicht die Bestimmung des Münzdatensatzes 5. In Fig. 1 enthält die von der Zentralbankinstanz 10 gesendete initiale Registrierungsanfrage den Registerdatensatz 6. In der Figur dargestellt ist, dass die erste Münzverwaltungseinheit 210 den digitalen Münzdatensatz 5 von der Zentralbankinstanz 10 erhält. Der digitale Münzdatensatz 5 kann jedoch auch mittelbar von der Zentralbank an eine Münzverwaltungseinheit eines Benutzers herausgegeben werden (z.b. über eine Geschäftsbank) oder von einer anderen Münzverwaltungseinheit empfangen worden sein.

Der digitale Münzdatensatz 5 kann von der ersten Münzverwaltungseinheit 210 direkt an die zweite Münzverwaltungseinheit 220 übertragen werden. Die zweite Münzverwaltungseinheit 220 kann die Gültigkeit des Münzdatensatzes 5 mit Hilfe des Münzregisters 20 prüfen. Es kann eine Gültigkeitsanfrage, welche die aus dem Münzdatensatz 5 ableitbare Registerreferenz und optional den Betrag enthält, an das Münzregister 20 senden. Das Münzregister 20 prüft, ob die Registerreferenz vorliegt und bestätigt gegebenenfalls, dass der Münzdatensatz 5 gültig ist. Alternativ erzeugt die Münzverwaltungseinheit 220 einen neuen Münzdatensatz und sendet an das Münzregister 20 eine Registrierungsanfrage, die zumindest die Registerreferenz des bisher gültigen Münzdatensatzes 5 und eine Registerreferenz des neuen Münzdatensatz umfasst. Im Münzregister 20 wird die Registrierungsanfrage geprüft. Im einfachsten Fall wird die Registerreferenz des neuen Münzdatensatzes registriert und die bisher gültige Registerreferenz gelöscht (oder als ungültig markiert).

Wenn eine Münzverwaltungseinheit 210, 220 einen betragsgleichen neuen Münzdatensatz erzeugt und den neuen Münzdatensatz anstelle des bisherigen Münzdatensatzes registriert, wird dies auch als Umschalten bezeichnet.

Münzverwaltungseinheiten 210, 220 können jedoch auch Münzdatensätze aufteilen oder verbinden, also aus mehreren bisher gültigen Münzdatensätzen einen neuen zu registrierenden Münzdatensatz erzeugen bzw. aus einem bisherigen Münzdatensatz mehrere zu registrierende Münzdatensätze erzeugen. Das Münzregister 20 prüft dann insbesondere ob die Registrierungsanforderung (mit den zugehörigen mehreren bisherigen oder neuen Registerreferenzen) betragsneutral ist. WO 2020/212331 Al beschreibt entsprechende Beispiele. Die vorliegende Lösung ist jedoch nicht an die dort beschriebene Maskierung des Betrages der Münzdatensätze oder die konkreten Protokolle der WO 2020/212331 Al gebunden, wie beispielsweise WO 2021/170646 Al zeigt.

Der in Fig.l dargestellte Ansatz ist insbesondere vorteilhaft, da weder das Münzregister 20 noch das Transaktionsregister 25 Münzdatensätze 5 umfassen müssen. DE 102020 004 121 Al beschreibt ein Transaktionsregister und dessen Absicherung näher.

Fig. 2 zeigt eine Münzverwaltungseinheit 210 mit seinen typischen Komponenten. Die Münzverwaltungseinheit 210 umfasst eine Ausführungseinheit 211 und zumindest einen Münzdatensatz 215. Die Ausführungseinheit 211 ist in der Regel als Software ausgestaltet und eingerichtet die gespeicherten Münzdatensätze zu verwalten (Münzdatensätze senden/ empfangen, Registrierungsanforderungen senden).

Weiterhin umfasst die Münzverwaltungseinheit 210 einen Identifikator 217 der Münzverwaltungseinheit 210. Identifikatoren 217 werden im Folgenden teils auch verkürzt als ID bezeichnet, beispielsweise als Sender-ID oder Empfänger-ID. Ein kryptographischer Schlüssel 218, ggf. ein asymmetrisches Schlüsselpaar, sowie ein Zertifikat 219 der Münzverwaltungseinheit 210 sind weitere Datenelemente der Münzverwaltungseinheit 210. Bevorzugt dient der kryptographische Schlüssel zur Authentisierung der Münzverwaltungseinheit 210 und/ oder zur Signatur von Daten, insbesondere im Rahmen einer Transaktion. Das Zertifikat 219 kann den Identifikator 217 und/ oder den Schlüssel 218, in der Regel den öffentlichen Schlüssel eines Schlüsselpaares 218, der Münzverwaltungseinheit 210 betreffen.

In den Fig. 1 bis 4 sind Datenelemente, beispielweise Münzdatensatz oder bedingte Transaktion, mit rechteckigen Kästchen dargestellt. Funktionale Einheiten, beispielsweise die Ausführungseinheit, sind mit abgerundeten Ecken dargestellt. Optionale Datenelemente oder Einheiten sind in der Regel mit gestrichelten Linien dargestellt.

Eine Münzverwaltungseinheit umfasst zumindest einen digitalen Münzdatensatz und eine Ausführungseinheit zur Verwaltung von Münzdatensätzen.

Fig. 3 zeigt eine Münzdepotverwaltungseinheit 30 mit mehreren

Münzverwaltungseinheiten 31, 310; 31, 320; 31, 330, die eine gemeinsame Ausführungseinheit 31 aufweisen, und eine Münzverwaltungseinheit 390 mit eigener Ausführungseinheit 391. Münzdepotverwaltungseinheiten umfassen Münzdepots unterschiedlicher Benutzer. In dem digitalen Zentralbankwährungssystems wird es eine Vielzahl von Münzverwaltungseinheiten geben. Zudem kann es eine Mehrzahl von Münzdepotverwaltungseinheiten geben.

Der Vollständigkeit halber sind in der Sy stem Verwaltungsschicht 2 der Fig. 3 neben einem Münzdatensatz 5, auch das Münzregister 20 der Zentralbank mit Registerdatensätzen 6 und das optionale Transaktionsregister 25 mit einem Transaktionsdatensatz 7 gezeigt.

Die Münzverwaltungseinheit 390 umfasst neben der Ausführungseinheit 391, mindestens einen Münzdatensatz 395, in der Regel mehrere Münzdatensätze, sowie mindestens zwei bedingte Transaktionen 396a, 396b, 396c mit unterschiedlichen Lese- und/ oder Schreibrechten 397a, 398a, 397b, 398b, 397c, 398c. Die Unterschiede sind in der Figur mittels Pfeilen angedeutet. Zwei bedingte Transaktionen können mit gleichen Schreibrechten und unterschiedlichen Leserechten, mit unterschiedlichen Schreibrechten und gleichen Leserechten oder mit unterschiedlichen Lese- und Schreibrechten ausgestaltet sein. Zusätzlich können auch - nicht dargestellte - bedingte Transaktionen vorhanden sein, welche gleiche Schreib- und Leserechte aufweisen.

Optionale Vorgaben 392, 393 könnten die Münzverwaltungseinheit 390 im Hinblick auf Transaktionen beschränken, nur beispielsweise: die Art der Transaktion, den Transaktionsbetrag oder den Transaktionspartner. Wie mit den drei Doppelpfeilen in beide Richtungen angedeutet ist, soll die Münzverwaltungseinheit 390 in diesem Beispiel jedoch zunächst weder durch seine Empfangsvorgabe 392 noch durch seine Sendevorgabe 393 hinsichtlich der Transaktionspartner beschränkt sein. Die Einhaltung der Vorgaben sowohl beim (direkten) Ausführen einer Transaktion als auch beim Erstellen einer bedingten Transaktion wird später - mit Bezug auf Figur 5 und 7 respektive - genauer beschrieben. Auch der Unterschied zwischen normalen, direkt auszuführenden, Transaktionen und den gespeicherten bedingten Transaktion, die erst ausgeführt werden, wenn ihre Bedingung erfüllt ist, kann anhand dieser beiden Figuren besser erkannt werden.

Die erste bedingte Transaktion 396a darf gemäß Leserecht 398a von jedem Dritten (insbesondere jeder Münzverwaltungseinheit oder jeder Münzdepotverwaltungseinheit) und natürlich vom Benutzer der Münzverwaltungseinheit gelesen werden. Dies ist mit drei nach rechts gerichteten Pfeilen angedeutet. Die zweite bedingte Transaktion 396b darf gemäß Leserecht 398b nur vom Benutzer und von einer oder mehreren bestimmten Münzverwaltungseinheiten (oder einer oder mehreren Münzdepotverwaltungseinheiten) gelesen werden. Dies wird mit den zwei nach rechts gerichteten Pfeilen angedeutet. Die dritte bedingte Transaktion 396c darf gemäß Leserecht 398c nur vom Benutzer ausgelesen werden, so dass nur ein nach rechts gerichteter Pfeil dargestellt ist.

Der Benutzer hat nur ein Schreibrecht 397a auf die erste bedingte Transaktion 396a.

Gemäß den Schreibrechten 397b und 397c der zweiten bzw. dritten bedingten Transaktion 396b und 396c darf niemand diese bedingten Transaktionen ändern. Dritte können keine der drei bedingten Transaktionen 396a-c ändern.

Die Münzdepotverwaltungseinheit 30 der Fig. 3 hat mehrere, hier drei, Münzdepots 310, 320 und 330 unterschiedlicher Benutzer und eine Ausführungseinheit 31 zur Verwaltung von Münzdatensätzen 315, 325, 335 der Münzdepots 310, 320, 330 des digitalen Zentralbankwährungssystems. Die Münzdepotverwaltungseinheit 30 wird in der Regel wesentlich mehr als drei, beispielsweise mehr als 100, Münzdepots umfassen.

Die Münzdepots 310, 320, 330 sind Münzdepotdatensätze. Die Münzdepots 310, 320, 330 bestehen aus Datenelementen, wie dem jeweils mindestens einen Münzdatensatz 315, 325, 335 sowie weiteren Datenelementen. Jedes Münzdepot 310, 320, 330 der Fig. 3 umfasst den mindestens einen Münzdatensatz 315, 325, 335. Die Münzdepots 310, 320, 330 können jeweils auch mehrere Münzdatensätze umfassen. Die entsprechenden Bezugszeichen, wie 315, 325, 335 und 395 in der Figur 3, sollen also einen oder mehrere Münzdatensätze der Münzverwaltungseinheit 31,310; 31,320; 31,330 und 390 darstellen.

In dem Münzdepot 310 ist keine bedingte Transkation enthalten. Eine bedingte Transaktion 316 könnte optional angelegt werden. Alternativ könnte eine Vorgabe des Münzdepots 310 jedoch auch ausschließen, dass bedingte Transaktionen in dem Münzdepot 310 gespeichert werden können.

Die Münzdepots 320, 330 enthalten jeweils zwei bedingte Transkation 326a, 326b und 336a, 336b. Die Schreib- und/ oder Leserechte 327a, 328a, 337a, 338a der ersten bedingten Transaktion 326a, 336a unterscheiden sich von den Schreib- und/ oder Leserechten 327b, 328b, 337b, 338b der zweiten bedingten Transaktion 326b, 336b.

Für das Münzdepot 330 mit dem mindestens einen Münzdatensatz 335, deuten die Pfeile wiederum die Rechte an. Auf die gespeicherte bedingte Transaktion 336b hat niemand schreibenden Zugriff - gemäß Schreibrecht 337b. Die bedingte Transaktion 336a kann dagegen geändert werden von genau einem Berechtigten - gemäß Schreibrecht 337a. Dieser Berechtigte ist im Regelfall der Benutzer, kann aber auch der Transaktionspartner sein. Beispielsweise im Fall einer Empfangs-Transaktion für das Münzdepot 330 könnte der Sender der Münzdatensätze, die in der bedingten Transaktion enthalten sind, das Schreibrecht haben. Auf diesem Weg könnte eine Münzverwaltungseinheit, die keine bedingten Transaktionen unterstützt oder - wie das Münzdepot 310 - durch eine Vorgabe keine bedingten Transaktionen speichern darf, dennoch eine bedingte Transaktion zusammen mit einem Transaktionspartner speichern.

Die zweite bedingte Transaktion 336b des Münzdepots kann nur der Benutzer lesen - gemäß Leserecht 338b. Ein Dritter, der bei der Münzdepotverwaltungseinheit 30 die vorhandenen bedingten Transaktionen des Münzdepots 330 anfragt, sieht also nur die erste bedingte Transaktion 336a. Die Leserechte 338a sind so gewählt, dass jede Münzverwaltungseinheit des Zentralbankwährungssystems die erste bedingte Transaktion 336a auslesen kann.

Für das Münzdepot 320 mit dem mindestens einen Münzdatensatz 325 deuten die Doppelpfeile an den Vorgaben 322, 323 an, wie die Vorgaben für die Münzverwaltungseinheiten bzw. Münzdepots in der Münzdepotverwaltungseinheit 30 gewählt sein können. Wie mit den Doppelpfeilen dargestellt, können sich beispielsweise Empfangsvorgaben 322 von Sendevorgaben 323 unterscheiden. Die Vorgaben können dabei Vorgaben des Herausgebers des Münzdepots und/ oder des Benutzers sein. Die Vorgaben können für das Münzdepot beispielsweise die Transaktionstypen, Funktionen der Ausführungseinheit, Empfänger, Sender oder Betragsgrenzen vorgeben. Das Münzdepot 320 kann beispielsweise Münzdatensätze von jeder Münzverwaltungseinheit als Sender empfangen (3 Doppelpfeile), aber nur Münzdatensätze an ausgewählte Empfänger senden (2 Doppelpfeile), die beispielsweise mit ihrer ID oder als Gruppe, in der Sende-Vorgabe 323 enthalten sind. Die Sende-Vorgabe 323 des Münzdepot 320 beschränkt das Münzdepot 323 somit auf das Senden von Münzdatensätzen (Sende-Vorgabe) an bestimmte Empfänger. Das Münzdepot 320 ist also unbeschränkt im Hinblick auf die Sender und teilbeschränkt im Hinblick auf Empfänger.

Zugunsten der Lesbarkeit sind die Vorgaben der weiteren Münzdepots nicht in Figur 3 dargestellt. Die Vorgaben der Münzdepots 310, 320, 330 der

Münzdepotverwaltungseinheit 30 werden sich voneinander unterscheiden, auch wenn einige Münzdepots natürlich einheitliche Vorgaben enthalten können. Die Ausführungseinheit 31 prüft die Vorgabe des jeweiligen Münzdepots 310, 320, 330, bevor es eine Transaktion ausführt, also insbesondere einen Münzdatensatz des jeweiligen Münzdepots 310, 320, 330 sendet oder einen empfangenen Münzdatensatz in dem Münzdepot 310, 320, 330 speichert. Die Vorgaben werden ebenfalls geprüft, bevor die bedingte Transaktion gespeichert wird.

Jedes Münzdepot 310, 320, 330 hat seine eigene ID, also den Identifikator (ID) der Münzverwaltungseinheit, und umfasst optional auch seine Schlüssel und/ oder seine Zertifikate. Alternativ oder ergänzend können, insbesondere geheime, Schlüssel und/ oder Zertifikate auch von der Münzdepotverwaltungseinheit bereitgestellt werden.

Jedes der Münzdepots 310, 320 und 330 ist einem Benutzer zugeordnet. Die Zuordnung des Münzverwaltungseinheiten-ID zu dem Benutzernamen wird jedoch vorzugsweise nicht in dem Münzdepot gespeichert, sondern in einer münzdepot-externen Datenstruktur (welche den ID zusammen mit dem vollständigen Namen des Benutzers enthält, ein sogenanntes Tupel). Die Münzdepotverwaltungseinheit 30 umfasst hier drei Münzdepots 310, 320, 330 von unterschiedlichen Benutzern.

Es ist denkbar dass nicht beschränkende Vorgaben wie die Vorgaben 392, 393 und 322 entweder explizit kodiert werden (beispielsweise durch: oder „alle" für beliebigen IDen) oder entfallen (keine Vorgabe => keine Beschränkung).

Eine Sende- oder eine Empfangs-Vorgabe muss nicht nur genau einen ID, oder mehrere IDen umfassen, sondern kann auch Gruppen von IDen oder Mischungen aus Gruppen und einzelnen IDen umfassen. Eine Gruppe von IDen kann beispielsweise mit einer ID- Maske angegeben werden. Die ID-Maske gibt nur Anteile eines IDs vor, die übereinstimmen müssen, wie beispielsweise „ABC??1311560*". So können beispielsweise alle IDen, die einen bestimmten Anfangsanteil und/ oder Mittelanteil (im Beispiel Anfang „ABC" und Mitte „1311560") aufweisen zulässig sein, unabhängig von den konkreten Werten in weiteren Anteilen (im Beispiel den zwei Zeichen „??" oder einer am Ende des ID folgenden Seriennummer) des jeweiligen ID.

Ein Herausgeber von Münzdepots 310, 320, 330 könnte in einem Beispiel für einen Benutzer ein Münzdepot 330 mit Münzdatensätzen 335 bereitstellen und vorab in einer Sende-Vorgabe des Herausgebers den einzig zulässigen Empfänger oder eine einzige zulässige Empfängergruppe festlegen. Mit Bezug auf Fig. 4 sollen die Komponenten der Münzdepotverwaltungseinheit 30 genauer betrachtet werden. Fig. 4 zeigt eine Münzdepotverwaltungseinheit 30, eine Benutzereinheit 40, eine Herausgeberinstanz 50 sowie eine weitere Münzverwaltungseinheit 390. Die weitere Münzverwaltungseinheit 390 kann der Münzverwaltungseinheit 390 aus Fig. 3 entsprechen, alternativ könnte sie aber auch jede andere Münzverwaltungseinheit, also auch eine Münzverwaltungseinheit einer weiteren Münzdepotverwaltungseinheit, sein.

Die Münzdepotverwaltungseinheit 30 umfasst Münzdepots 410, 420, 430 und die Ausführungseinheit 31. Der Münzdepotdatensatz des Münzdepots 430 ist ausführlicher dargestellt, er enthält genau einen oder mehrere Münzdatensätze 435 sowie optional Vorgaben 432, 433.

In dem Münzdepot 330 enthalten sind als optionale, aber in der Regel vorhandene, Datenelemente beispielsweise ein Identifikator 237, zumindest ein Schlüssel 238 und ein Zertifikat 239 (hier das Zertifikat der Münzverwaltungseinheit, gebildet durch das Münzdepot 430 und die Ausführungseinheit 31 der Münzdepotverwaltungseinheit 30).

Die Vorgaben umfassen Herausgeber-Vorgaben 432 und Benutzer-Vorgaben 433. Die Herausgeber-Vorgaben 432 sind vom Herausgeber des Münzdepots fest vorgegeben. Sie können bereits in einer Münzdepot- Anforderung 402 enthalten sein. Die Benutzer- Vorgaben 433 sind dagegen vom Benutzer frei wählbar, zumindest sofern sie enger sind als eine (möglicherweise vorhandene gleichartige) Herausgeber-Vorgabe 432.

Ausgehend von einer vollbeschränkenden Herausgeber-Vorgabe, wie beispielsweise „kein Senden" oder „kein Empfangen", hat der Benutzer keine Wahlfreiheit mehr. Ausgehend von einer unbeschränkten (ggf. nicht vorhandenen) funktionelle Vorgabe des Herausgebers, wie „Senden an alle" und/ oder „Empfangen von allen", kann der Benutzer eine Benutzer-Vorgabe vollkommen frei wählen. Ausgehend von einer teilbeschränkenden funktionellen Vorgabe des Herausgebers, wie „Senden nur an ID- Gruppe 1 oder an ID-Gruppe 2" kann der Benutzer eine engere Benutzer-Vorgabe wählen, wie „Senden nur an ID1 aus ID-Gruppel oder an ID2 aus ID-Gruppel".

Die Münzdepotverwaltungseinheit 30 kann eine Münzdepot-Erstellungseinheit 32 umfassen, welche eine Münzdepot- Anforderung 402 von der Herausgeber-Einheit 50 verarbeiten kann. Die Münzdepotverwaltungseinheit 30 kann eine Benutzervorgaben-Einheit 33 umfassen, welche eine Konfigurations-Anforderung 403 von der Benutzer-Einheit 40 verarbeiten kann. Ein Benutzer kann von seiner Benutzer-Einheit 40, wie Mobilfunkgerät, PC oder Terminal, die Konfigurations-Anforderung 403 an die Münzdepotverwaltungseinheit 30 senden.

Die Benutzervorgaben-Einheit 33 prüft insbesondere, ob die in der Konfigurations- Anforderung 403 enthaltenen, vom Benutzer gewählten Vorgaben 433 für sein Münzdepot 430 enger sind als die vorhandenen Herausgeber-Vorgaben 432 des Münzdepots 430. In diesem Fall werden die Vorgaben in der Konfigurations- Anforderung 403 als Benutzer-Vorgaben 433 in dem Münzdepot 430 gespeichert. In der Münzdepotverwaltungseinheit 30 kann die Benutzer-Vorgabe 433 stets enger sein als die Herausgeber-Vorgabe 432 und die Beschränkungen der Herausgeber-Vorgabe 432 umfassen. Es ist dann ausreichend, dass die Ausführungseinheit 31 die Benutzer- Vorgabe 433 prüft. Bei Angabe der zulässigen Empfänger und/ oder Sender in der funktionellen Vorgabe 432, 433 ist diese Variante bevorzugt. Andererseits kann die Ausführungseinheit 31, bevorzugt für andere Vorgaben oder Kodierungen, auch eingerichtet sein, stets beide Vorgaben 432, 433 zu prüfen. Die Benutzer-Vorgabe 433 muss dann nicht die eventuell vorhandenen Beschränkungen der Herausgeber-Vorgabe 432 umfassen. Die Verwaltung der Benutzervorgabe(n) 433 kann somit vereinfacht werden.

Das Münzdepot 330 kann als neues Münzdepot auf die Anforderung 402 der Herausgeber-Einheit 50 erstellt werden bzw. worden sein. Die Münzdepot- Anforderung 402 enthält als Datenelement zumindest eine, in der Regel mehrere, Herausgeber-Vorgaben 432 für das neue Münzdepot 330. Ein entsprechendes Verfahren wird später mit Bezug auf Fig. 6 näher beschrieben.

Die Ausführungseinheit 31 ist eingerichtet die Münzdatensätze der Münzdepots 410, 420, 430 in Transaktionen 405, 406 mit anderen Münzverwaltungseinheiten von anderen Benutzern des Zentralbanksystems auszutauschen und (in Fig. 4 nicht dargestellte) Registrierungsanforderungen an das (in Fig. 4 nicht dargestellte) Münzregister 20 zu senden.

Der Benutzer kann von seiner Benutzereinheit 40 eine Transaktions-Anforderung 401 an die Münzdepotverwaltungseinheit 30 senden. Ein entsprechendes Verfahren zur Verarbeitung der Transaktions- Anforderung 401 wird für den Fall des Sendens eines Münzdatensatzes, Sende-Transaktion 405, mit Bezug auf Fig. 5 beschrieben. Die Transaktions-Anforderung 401 ist eine Transaktionsanfrage der Benutzereinheit 40 des Benutzers, welche insbesondere anhand eines Authentisierungs-Datenelements oder einer vorangehenden Authentisierung der Benutzereinheit 40 als Anfrage des Benutzers erkennbar ist. Die Ausführungseinheit 31 prüft die Vorgaben 432, 433 bevor die Sende-Transaktion 405 abhängig vom Prüfungsergebnis ausgeführt wird (oder nicht). Ebenfalls zu Fig. 5 wird die Prüfung der Vorgaben im Falle des Empfangs von Münzdatensätzen (Empfangs-Transaktion 406) beschrieben.

Die Vorgaben 432,433 können nicht nur Richtungsvorgaben (Senden/ Empfangen) sein, sondern beispielsweise auch Vorgaben für bedingte Transaktionen oder Vorgaben für Transaktionen mit Gegenleistung sein.

In dem Münzdepot 430 oder münzdepotübergreifend sind bedingte Transaktionen 436 gespeichert, die sich in ihren Leserechten 438 und/ oder Schreibrechten 437 unterscheiden. Die bedingten Transaktionen werden auf Anfrage gespeichert und später - nachdem die Bedingung erfüllt ist - wird eine Transaktion, die der gespeicherten bedingten Transaktion entspricht, ausgeführt. Ein entsprechendes Verfahren wird genauer beschrieben mit Bezug auf Fig. 7.

Die Münzdepotverwaltungseinheit 30 umfasst eine Benutzerzugriffs-Einheit für bedingte Transaktionen 34 sowie eine Drittzugriffs-Einheit für bedingte Transaktionen 39. Die Einheiten 34, 39 sind separat dargestellt, können jedoch als Zugriffseinheit für bedingte Transaktionen 34, 39 ausgebildet sein oder als Untereinheiten der Ausführungseinheit 31 ausgebildet sein.

Der Benutzer kann eine, mehrere oder alle bedingten Transaktionen 436 auslesen 408. Die Benutzer-Einheit 40 sendet eine entsprechende Leseanfrage des Benutzers und die Benutzerzugriffs-Einheit für bedingte Transaktionen 34 prüft die Zugriffsrechte 438 der auszulesenden bedingten Transaktionen 436. Der Benutzer kann eine bedingte Transaktionen 436 ändern 409. Die Benutzer-Einheit 40 sendet eine entsprechende Änderungsanfrage des Benutzers und die Benutzerzugriffs-Einheit für bedingte Transaktionen 34 prüft die Zugriffsrechte 437 der zu schreibenden (bereits gespeicherten) bedingten Transaktionen 436. Der Benutzer kann beispielsweise alle bedingten Transaktionen 436 auslesen, jedoch nur bestimmte bedingte Transaktionen 436 ändern. Dritte, wie die dargestellte weitere Münzverwaltungseinheit 390, können ebenfalls bedingte Transaktionen auslesen 409. Sie können eine Leseanfrage für eine, mehrere oder alle (für sie lesbaren) bedingten Transaktionen senden. Die Drittzugriffs- Einheit 39 prüft die Leserechte 438 der bedingten Transaktionen 436 für den Dritten. Für den Driten werden nur die bedingten Transaktionen 436 ausgelesen, für welche die entsprechenden Leserechte 438 vorliegen. Es wäre denkbar, dass alle bedingten Transaktionen 436, in denen der Dritte Transaktionspartner ist oder sein könnte (Gruppenangaben), entsprechende Leserechte haben. Bevorzugt darf ein Driter jedoch aus der Gruppe der bedingten Transaktionen 436, in denen er als Transaktionspartner genannt ist (mit seiner ID) oder der Transaktionspartner sein könnte (Gruppenangabe), auch nur bestimmte bedingte Transaktionen 436 lesen.

Ein Schlüsselverwaltungsmodul 38 der Münzdepotverwaltungseinheit 30 ist vorzugsweise ein Hochsicherheitsmodul für kryptographische Schlüssel. Das Schlüsselverwaltungsmodul 38 kann geheime Schlüssel der Münzdepots 410, 420, 430 speichern. Der im Münzdepot 430 gespeicherte Schlüssel 338 der Münzdepotverwaltungseinheit 30 ist beispielsweise ein öffentlicher Schlüssel eines asymmetrischen Schlüsselpaares. Der zugehörige geheime Schlüssel wird in dem Schlüsselverwaltungsmodul 38 gespeichert (und nur in diesem verwendet). Das Schlüsselverwaltungsmodul 38 verschlüsselt, authentisiert oder signiert beispielsweise Daten für die Ausführungseinheit 31 mit dem geheimen Schlüssel des Münzdepots. Für diese unterschiedlichen Zwecke können eigene Schlüsselpaare vorgesehen sein. Das Schlüsselverwaltungsmodul 38 kann ferner abgeleitete Schlüssel, wie Sitzungsschlüssel, erstellen und der Ausführungseinheit 31 bereitstellen.

Neben der Verwaltung der Transaktionsschlüssel (für die Transaktionen benötigte Schlüssel) kann das Schlüsselverwaltungsmodul 38 auch für die verschlüsselte Speicherung der Münzdepotdatensätze verwendet werden.

Die Datensätze der Münzdepots 410, 420, 430 (Münzdepotdatensätze) werden vorzugsweise verschlüsselt in der Münzdepotverwaltungseinheit 30 gespeichert. Bei Bedarf, also beispielsweise bei einer Transaktions- oder Konfigurations-Anforderung für das Münzdepot 430, wird das entsprechende Münzdepot 410, 420, 430 entschlüsselt. Es wird jeweils nur das benötigte Münzdepot 430 entschlüsselt, wobei insbesondere ein für das Münzdepot 430 individueller Schlüssel verwendet werden kann. Das Schlüsselverwaltungsmodul 38 kann beispielsweise das Entschlüsseln (und ein späteres wieder Verschlüsseln) ausführen. Wenn das Schlüsselverwaltungsmodul 38 einen Ableitungsschlüssel (optional gemeinsam für mehrere Münzdepots) enthält, kann es alternativ den abgeleiteten Schlüssel für die Entschlüsselung/ Verschlüsselung des Münzdepots 430 der Ausführungseinheit 31 bereitstellen. Münzdepotverwaltungseinheit 30 prüft für die bedingten Transaktionen der Münzdepots 410, 420, 430, ob die darin enthaltene Bedingung erfüllt ist. Es kann eine Bedingungs-Prüfeinheit 37 in der Münzdepotverwaltungseinheit 30 vorgesehen sein. Die Bedingungs-Prüfungseinheit 37 prüft - insbesondere laufend, in regelmäßigen zeitlichen Abständen oder in Antwort auf ein externes Ereignis, wie ein Auslöser- Ereignis 404 - ob eine Bedingung (wie: Zeitpunkt, Datum, Grenzwert überschritten, externes Ereignis, Anfrage empfangen) der bedingten Transaktion 436 erfüllt ist. Optional kann sie eine Prüfliste 36 verwenden, in welcher zumindest die zu prüfenden Bedingungen der bedingten Transaktionen der Münzdepots 410, 420, 430 der Münzdepotverwaltungseinheit 30 gespeichert sind. Nicht nur wenn die Münzdepotdaten verschlüsselt gespeichert sind, vereinfacht die Prüfliste 36 das Prüfen der Bedingungen. Ist die Bedingung einer bedingten Transaktion erfüllt, wird eine Transaktion ausgeführt, die der bedingten Transaktion entspricht.

Um eine Transaktion mit Gegenleistung ausführen zu können, umfasst die Münzdepotverwaltungseinheit 30 eine (nicht in der Figur dargestellte) Gegenleistungseinheit. Die Gegenleistungseinheit erzeugt beispielsweise Antwortdaten, die als Gegenleistung für einen (oder mehrere) in einer Empfangs- Transaktion 406 empfangenen Münzdatensatz in einer Antwort zu senden sind. Die Gegenleistungseinheit stellt eine Gegenleistung bereit, die beispielsweise in Gegenleistungsdaten des Münzdepots 430 einstellbar ist. Alternativ oder ergänzend soll vorliegend eine Gegenleistung in einer bedingten Transaktion angegeben werden können. Die Gegenleistungsvorgaben könnten die für das Münzdepot 430 zulässigen Gegenleistungsfunktionen beschränken. Ausgehend von den in der Gegenleistungseinheit verfügbaren Gegenleistungsfunktionen, werden also für das Münzdepot 430 selektiv bestimmte Gegenleistungsfunktionen, -kodierungen oder - subtypen ausgeschlossen.

Alle zu Fig. 4 beschriebenen Aspekte, die nicht spezifisch für die Verwaltung von Münzdepots unterschiedlicher Benutzer sind, können auch in einer Münzverwaltungseinheit mit eigener Ausführungseinheit vorliegen (nur beispielsweise die Einheiten 34, 36, 37 und 39 oder mehrere Münzdepots mit eigenen IDen).

Fig. 5 zeigt den Verfahrensablauf 501 bis 518 in der Münzdepotverwaltungseinheit 30 nach Empfang einer Transaktions-Anforderung 501 von einem Benutzer (bzw. dessen Benutzereinheit 40) sowie den Verfahrensablauf 551 bis 568 beim Empfangen von Münzdatensätzen von einer Münzverwaltungseinheit 390. Die Transaktions-Anforderung 501 umfasst einen ID eines Münzdepots 430 in der Münzdepotverwaltungseinheit 30 und fordert das Senden eines Betrages von dieser Sender-ID an eine Empfänger-ID an. Die sichere Ausführungseinheit 31 der Münzdepotverwaltungseinheit 30 liest in Schritt 502 den Münzdepotdatensatz des Münzdepots 430 mit der Sender-ID. Bevorzugt stellte das Schlüsselverwaltungsmodul 38 der Ausführungseinheit 31 entweder den Entschlüsselungsschlüssel, der individuell für das Münzdepot 430 anhand dem ID gewählt ist, bereit oder den bereits entschlüsselten Münzdepotdatensatz bereit. In den Schritte 503, 504, 506 führt die Ausführungseinheit 31 mehrere Prüfungen aus, bevor es die angeforderte Transaktion in den Schritte 507 bis 516 ausführt. Fig. 5 zeigt die bevorzugte Reihenfolge der Prüfungsschritte. Zunächst wird eine Authentisierung geprüft 503, in der Regel die Authentisierung des Benutzers. Ein entsprechender Authentisierungswert kann in der Transaktions-Anforderung 501 enthalten sein oder in Schritt 503 separat angefordert und empfangen werden.

Zumindest eine (der) Vorgabe(n) 432, 433 des Münzdepots 430 mit dem ID wird in Schritt 504 geprüft. Im vorliegenden Beispiel einer einfachen Sende-Transaktion, wird geprüft, ob die Empfänger-ID, eine ID gemäß Sende-Vorgaben in der Herausgeberund/ oder Benutzervorgaben 432, 433 ist. Ist das Münzdepot 330 gemäß Herausgeber- Vorgabe 432 in Empfangsrichtung unbeschränkt oder ist die Herausgeber-Vorgabe 432 in Empfangsrichtung erfüllt, wird die Benutzervorgabe 433, die beispielsweise eine ID- Gruppe und zwei IDs von Empfängern umfasst, geprüft. Entspricht die Empfänger-ID der Transaktions- Anfrage nicht den Vorgaben 432, 433, wird die Transaktions- Anforderung 501 abgelehnt, der Benutzer 40 erhält eine Ablehnungsnachricht 505. Ist die Empfänger-ID dagegen zulässig, weil sie eine ID aus der ID-Gruppe ist oder einer der beiden IDs von Empfängern in der Benutzervorgabe 334a entspricht, wird das Verfahren fortgesetzt (und die Transaktion ausgeführt). In Schritt 506 wird geprüft, ob der Depotbetrag, Betrag des Münzdatensatzes 435 im Münzdepot 430 oder Summe der Beträge der Münzdatensätze 435 im Münzdepot 430, größer ist als der angeforderte Betrag.

Vorzugsweise sendet die Münzdepotverwaltungseinheit 30 in Transaktionen genau einen Münzdatensatz, dessen Betrag dem Transaktionsbetrag entspricht, anstatt den Transaktionsbetrag als Summe von Beträgen mehrerer Münzdatensätze zu senden. Entspricht der angeforderte Betrag dem Betrag eines im Münzdepot vorhandenen Münzdatensatzes, entfallen die nächsten Schritte 507 bis 509. In Schritt 507 wird ein neuer Münzdatensatz erstellt, dessen Betrag dem angeforderten Betrag entspricht. Bevorzugt wird ein vorhandener Münzdatensatz aufgeteilt in den neuen Münzdatensatz und einen weiteren Münzdatensatz (Betrag = Differenz aus Betrag des vorhandenen Münzdatensatzes und Transaktionsbetrag). Alternativ könnten zwei oder mehr vorhandene Münzdatensätze zu dem neuen Münzdatensatz (und optional einem oder mehreren weiteren Münzdatenätzen) verbunden werden. Eine Registrierungsanforderung 508 wird für den neuen Münzdatensatz (bzw. dessen Registerreferenz) an das Münzregister 20 gesendet. Das Münzregister 20 bestätigt 509 die Registrierung.

Die Ausführungseinheit 31 erstellt in Schritt 510 nun eine Transaktionsnachricht 511, die an die Münzverwaltungseinheit 220 mit der Empfänger-ID, insbesondere eines anderen Benutzers des Zentralbanksystems gesendet wird. Die Transaktionsnachricht 511 umfasst eine Transaktions-ID, die ID des Münzdepots 430, die ID der anderen Münzverwaltungseinheit 220 als Empfänger-ID und den neuen Münzdatensatz. Optional enthält die Transaktionsnachricht 511 einen Transaktionsbezugstext, der in der Regel aus der Transaktions- Anfrage 501 stammt, und/oder einen Authentisierungswert, der für die Transaktion mit Hilfe des geheimen Schlüssels des Münzdepots 430 erzeugt ist. Vorzugsweise wird in der Transaktion, insbesondere also in Schritt 511, eine gegenseitige Authentisierung der beiden beteiligten Münzverwaltungseinheiten (430,31; 220) vorgenommen. Der Schritt 510 des Erstellens und Sendens der Transaktionsnachricht 511 kann optional bzw. alternativ in mehreren Teilschritten mit einer Mehrzahl von ausgetauschten Teilnachrichten (nur beispielsweise für die Authentisierung) ablaufen.

Die andere Münzverwaltungseinheit 220 erzeugt optional einen eigenen Münzdatensatz, der insbesondere betragsgleich mit dem empfangenen, neuen Münzdatensatz ist, sendet eine Registrierungsanfrage 512 für seinen eigenen Münzdatensatz an das Münzregister 20 und erhält daraufhin eine Registrierungsbestätigung 513 von dem Münzregister 20. Die Münzverwaltungseinheit 210 sendet eine Transaktionsbestätigung 514 an die Münzdepot-Verwaltungseinheit 30.

In Schritt 515, also vorzugsweise erst nach Erhalt der Transaktionsbestätigung 514, speichert die Ausführungseinheit 31 die geänderten Münzdepotdaten des Münzdepots 430 ab. Eine münzdepotindividuelle Verschlüsselung der Münzdepotdaten kann, wie zuvor beschrieben - wiederum optional mit Hilfe des Schlüsselverwaltungsmoduls 38 - erfolgen. Eine Transaktionsbestätigung 516 kann an den Benutzer 40 gesendet werden. In bevorzugten Varianten wird in Schritt 517 ein Transaktionsregisterdatensatz 518 erstellt und an das Transaktionsregister 25 gesendet.

Vorzugsweise wird für die Transaktions-Anfrage 501 und/ oder die Transaktionsnachricht 511 ein JSON-Format verwendet. Bevorzugt wird für Nachrichten innerhalb der Transaktionsschicht 3 ein erstes, einheitliches Format, insbesondere das JSON-Format, verwendet. Es ist jedoch anzumerken, dass die Inhalte der Transaktions-Anfrage 501 und/ oder die Transaktionsnachricht 511 auch getrennt voneinander übertragen werden können. Beispielsweise kann ein Authentisierungswert erst in Schritt 503 oder eine Empfänger-ID erst in Schritt 504 übertragen werden und/ oder kann zunächst eine Authentisierung der Münzverwaltungseinheit 220 (oder eine gegenseitige Authentisierung) ausgeführt werden, bevor ein Münzdatensatz ausgetauscht wird.

Der zweite in Fig. 5 gezeigte Ablauf wird durch den Empfang einer Transaktionsnachricht 551 bzw. Empfangs-Transaktion von einer Münzverwaltungseinheit 390 ausgelöst. Die Transaktionsnachricht 551 enthält zumindest eine ID eines Münzdepots in der Münzdepot-Verwaltungseinheit 30 sowie mindestens einen Münzdatensatz. Die Münzverwaltungseinheit 390 will also einen Münzdatensatz an das Münzdepot senden. Die sichere Ausführungseinheit 31 prüft jedoch wiederum, ob die Transaktion den Vorgaben des Münzdepots entspricht.

Zunächst werden die Münzdepotdaten des Münzdepots mit der angegebenen ID gelesen 552. Das Fesen 552 der Münzdepotdaten wird - wie zuvor - ein Entschlüsseln umfassen. Optional wird eine Authentisierung der Münzverwaltungseinheit 390 geprüft oder eine gegenseitige Authentisierung ausgeführt. Nun prüft 554 die sichere Ausführungseinheit 31, die Vorgaben des Münzdepots. Ist für das Münzdepot das Empfangen beispielsweise vollständig beschränkt, wird die Transaktionsnachricht 551 abgelehnt. Im Beispiel sei für das Münzdepot das Empfangen jedoch durch eine Sender-Vorgabe des Herausgebers teilbeschränkt. Die sichere Ausführungseinheit 31 prüft also, ob die ID der Münzverwaltungseinheit 390 die Sender-Vorgabe des Herausgebers für das Münzdepot erfüllt. Im Negativfall wird die Transaktion abgelehnt, im Positivfall die Transaktion ausgeführt. Bevorzugt erzeugt die sichere Ausführungseinheit 31 einen eigenen Münzdatensatz unter Verwendung des empfangenen Münzdatensatzes. Sie kann einen eigenen betragsgleichen Münzdatensatz erzeugen 557 und, durch Registrierungsanforderung 558 und Registrierungsbestätigung 559, beim Münzregister registrieren. Die Münzdepotdaten des Münzdepots werden (verschlüsselt) gespeichert 565 und eine Transaktionsbestätigung 566 an die Münzverwaltungseinheit 390 gesendet. Optional kann auch ein Empfänger von Münzdatensätzen in dem digitalen Zentral-Bank- Währungssystem verpflichtet sein, einen Transaktionsregisterdatensatz zu erzeugen 567 und an das Transaktionsregister 25 zu senden 568.

Fig. 6 zeigt den Ablauf eines Verfahrens zur Erstellung eines neuen Münzdepots.

Ein Herausgeber 50 des neuen Münzdepots sendet eine Münzdepotanforderung 601 an die Münzdepot-Verwaltungseinheit 30. Die Münzdepot-Erstellungseinheit 32 der Münzdepot-Verwaltungseinheit 30 verarbeitet die Münzdepotanforderung 601 und legt das neue Münzdepot an. Zunächst wird die Authentisierung des Herausgebers geprüft 602. Scheitert die Prüfung der Authentisierung, beispielsweise weil der Anfragende kein Herausgeber, sondern ein Benutzer ist, wird die Anfrage abgelehnt (bzw. kein neues Münzdepot) erstellt. Die Münzdepot-Verwaltungseinheit 30 umfasst eine Vielzahl von Münzdepots, die unterschiedlichen Benutzern zugeordnet sind. Die Münzdepots umfassen unterschiedliche Vorgaben, insbesondere unterschiedliche funktionelle Vorgaben. Die Vielzahl von Münzdepots ist von einer Mehrzahl von Herausgebern erstellt worden. Die Vielzahl M der Münzdepots liegt in der Größenordnung einer Vielzahl B der Benutzer (M = a*B, beispielsweise mit 1 < a < 9 für 1 bis 9 Münzdepots pro Benutzer). Die Vielzahl der Münzdepots M ist um Größenordnungen größer als die Mehrzahl H der Herausgeber: M » H (beispielsweise: M = b*H mit b> 50, vorzugsweise >100).

In Schritt 603 wird ein Münzdepotdatensatz für das neue Münzdepot erstellt. Die Datenelemente des erstellten Münzdepotdatensatzes sind zunächst leer und/ oder mit einem Standardwert belegt. In dem Schritt des Erstellens 603 des Münzdepotdatensatzes kann der individuelle Verschlüsselungsschlüssel für das Münzdepot bereitgestellt werden, insbesondere von dem Schlüsselverwaltungsmodul 38. Die Datenelemente, wie Vorgaben und Münzdatensätze, oder insbesondere auch Identifikator, Schlüssel und/ oder Zertifikat, werden nun in weiteren Schritten 604 - 608 bereitgestellt oder aus der Münzdepotanforderung 601 übernommen.

Eine (oder mehrere) in der Münzdepotanforderung 601 enthaltene Vorgabe(n) des Herausgebers werden als Herausgeber-Vorgabe(n) in dem Münzdepotdatensatz gespeichert. Zunächst wird ein Identifikator für das neue Münzdepot in der Münzdepot- Verwaltungseinheit 30 erzeugt 604. Das neue Münzdepot bildet zusammen mit der sicheren Ausführungseinheit 31 eine neue Münzverwaltungseinheit. Identifikatoren sind in dem System Münzverwaltungseinheiten zugeordnet. Der Identifikator ist insbesondere als URI, Unified Ressource Identifier, oder URN, Unified Ressource Name, (einheitlicher Ressourcenname) gestaltet und enthält eine systemweit eindeutige ID (UUID). Ein Identifikator als URN hat beispielsweise folgendes Format: „münzverwaltungseinheit:meine-münzdepot-bank.com:UUID". Eine UUID kann als Identifikator oder als Teil einer URN verwendet werden. Die UUID ist gemäß RFC 4122 kodiert. Sie umfasst entsprechend ein Halfbyte M, welches eine Version der UUID angibt, und ein Halfbyte N, welches eine Variante der UUID angibt. Nun werden weitere Bits der UUID verwendet, um eine funktionelle Vorgabe zumindest teilweise zu kodieren. Dabei können beispielsweise Bits der Halfbytes S und/ oder V verwendet werden: „xxxxxxxx-xxxx-Mxxx-Nxxx-SVxxxxxxxxxx", die ansonsten mit Zufallszahlen belegt wären. In einem ersten Bit der UUID wird kodiert, dass das Münzdepot in einer Münzdepot-Verwaltungseinheit vorliegt. In einem zweiten Bit der UUID wird kodiert, ob eine richtungsbezogene funktionelle Vorgabe vorliegt („0": keine Richtungsvorgabe, „1": „Richtungsvorgabe"). In einem dritten Bit der UUID wird kodiert, ob bedingte Transaktionen zulässig sind („0": „keine bedingten Transaktionen" oder „1: bedingte Transaktionen zulässig"). In einem vierten Bit der UUID könnte optional kodiert sein, ob eine Gegenleistung zulässig ist („0": keine Gegenleistung zulässig, „1" Gegenleistung zulässig). Für herkömmliche Münzverwaltungseinheiten könnten die 3 Bits der UUID somit auf „000" gesetzt werden.

Für das neue Münzdepot soll gemäß Münzdepotanforderung 601 das Senden auf zwei verschiedene Empfängergruppen beschränkt sein, eine genannte Variante von bedingten Transaktionen zulässig sein, die eine Gegenleistung umfassen kann. Die drei Bits der UUID sind daher für das neue Münzdepot auf „111" gesetzt. Erwartungsgemäß wird für die Mehrzahl der Münzdepots in der Münzdepot- Verwaltungseinheit 30 nur eine (oder mehrere) Richtungsvorgabe existieren, bedingte Transaktionen oder Gegenleistungen jedoch unzulässig sein. Für die meisten Münzdepots wären also, in ihrer URN bzw. UUID, die drei Bits mit „100" kodiert.

In einem weiteren Schritt wird zumindest ein Schlüssel für das Münzdepot bereitgestellt bzw. erzeugt. Erzeugt wird, vorzugsweise vom Schlüsselverwaltungsmodul, ein Schlüsselpaar, umfassend einen öffentlichen Schlüssel und einen geheimen Schlüssel. Der geheime Schlüssel kann optional in dem Schlüsselverwaltungsmodul verbleiben. Alternativ wird er in verschlüsselter Form in dem (ggf. zusätzlich verschlüsselten) Münzdepot gespeichert. Der öffentliche Schlüssel wird in dem Münzdepot gespeichert. Der Schlüssel bzw. das Schlüsselpaar dient vorzugsweise der Authentisierung der neuen Münzverwaltungseinheit.

In einem weiteren Schritt 606 wird ein Zertifikat für das Münzdepot erstellt. Das Zertifikat umfasst zumindest die ID und/ oder den öffentlichen Schlüssel des Münzdepots. Zertifikate bestätigen für Dritte die Echtheit der enthaltenen Datenelemente. Das Zertifikat ist - ebenso wie die ID oder der öffentliche Schlüssel - ein zur Weitergabe an Dritte, wie andere Münzverwaltungseinheiten, vorgesehenes (öffentliches) Datenelement des Münzdepotdatensatzes. Die funktionellen Vorgaben zu Gegenleistungen sind daher nicht in dem Zertifikat enthalten. Auch die genaue Beschränkung in Sende- und Empfangsrichtung, also hier die beiden zulässigen Empfängergruppen, werden als interne Information behandelt. In dem Zertifikat enthalten ist jedoch ein (weiterer) Teil der funktionellen Vorgaben. Das Zertifikat enthält beispielsweise die Angabe, dass das Münzdepot in Empfangsrichtung unbeschränkt ist („keine Sender-Vorgabe") und in Senderichtung teilbeschränkt ist.

Optional empfängt 607 die sichere Ausführungseinheit 31 einen oder mehrere Münzdatensätze für das neue Münzdepot. Die sichere Ausführungseinheit wird - wie zuvor bereits beschrieben - für den/ die empfangenen Münzdatensatz/ -sätze einen eigenen (oder mehrere eigene) Münzdatensatz (-sätze) erzeugen 608. Sie sendet eine Registrierungsanforderung an das Münzregister 609 und erhält eine Bestätigung 610 für die Registrierung des/ der eigenen Münzdatensatzes/ Münzdatensätze im Münzregister 20. In der Regel werden betragsgleiche eigene Münzdatensätze erzeugt und registriert (umschalten). Nicht figürlich gezeigt ist, dass vorzugsweise wiederum ein Transaktionsregisterdatensatz an das Transaktionsregister 25 übertragen wird.

In Schritt 611 wird der Münzdepotdatensatz, insbesondere einschließlich der genannten erzeugten Datenelemente, der extern bereitgestellten Datenelemente und optional mindestens eines Münzdatensatzes, gespeichert. Er wird vorzugsweise individuell verschlüsselt gespeichert. Die Verschlüsselung kann sich auf den gesamten Münzdepotdatensatz oder auf einzelne Datenelemente (Dl, D2, D3) beziehen (z.b.: „encrypt(Dl,D2,D3 ...)" oder „encrypt(Dl), encrypt(D2), encrypt(D3) ...").

Die Münzdepot-Erstellungseinheit 32 kann nach dem Erstellen des neuen Münzdepots eine Münzdepot-Bestätigung 612 an den Herausgeber 50 senden. Ein Schritt 614 des Registrierens des neuen Münzdepots für einen Benutzer kann zu unterschiedlichen Zeitpunkten erfolgen. Die Zuordnung zwischen einem eindeutigen Benutzernamen, gegebenenfalls inklusive „Vorname, Nachname, Geburtsdatum und/ oder Adresse" oder „Steuernummer mit oder ohne , Vorname, Nachname'" des Benutzers und dem Münzdepot, also der ID des Münzdepots, wird in der Regel in einer externen Datenstruktur gespeichert. Ist der Benutzer bereits in der Münzdepotanforderung 601 genannt, kann die Zuordnung bzw. das Registrieren 614 erfolgen, sobald die ID des Münzdepots feststeht (im Beispiel: ab Schritt 604).

Mit einer separaten Zuordnungs-Anforderung 613, welche sich auf zumindest ein bereits erstelltes, noch keinem Benutzer zugeordnetes Münzdepot bezieht, wird das Registrieren 614 in Fig. 6 ausgelöst. Der Herausgeber 50 könnte somit eine Mehrzahl an neuen Münzdepots erstellen lassen (Schritte 601 bis 612) und erst bedarfsweise (zu einem späteren Zeitpunkt und gegebenenfalls einzeln) einem Benutzer zuordnen (Schritte 613, 614). Es ist denkbar für mehrere Münzdepots gleichzeitig die Zuordnung anzufordern. Die Zuordnungs-Anforderung 613 kann der Herausgeber senden. In der Regel wird der Benutzer danach darüber informiert, dass ein neues Münzdepot für ihn erstellt ist (beispielsweise inkl. Angabe der ID bzw. Zugangsdaten). Alternativ kann der Benutzer oder ein Dritter die Zuordnungs- Anforderung 613 senden. Der Herausgeber teilt dem Benutzer einen Berechtigungscode (z.B. in einer Mail und/ oder als Barcode) mit. Der Benutzer oder ein Dritter, welcher zunächst die Identität des Benutzers verifiziert (z.B. mittels Postident- oder Video Ident-Verfahren), sendet dann den Berechtigungscode mit oder in der Zuordnungs-Anforderung 613.

Vorzugsweise umfasst das Münzdepot zum Zeitpunkt der Registrierung 614 noch keine Münzdatensätze. Somit können - beispielsweise ausgehend vom Transaktionsregister 25 - alle Transaktionen im System Benutzern zugeordnet werden.

Es wird nun erkennbar, dass die zu einzelnen Figuren beschriebenen Aspekte oder Merkmale auch einzeln oder gemeinsam in anderen Figuren verwendbar sind. Das neue Münzdepot gemäß Fig. 6 kann beispielsweise ein Münzdepot nach einer der Figuren 2 bis 9 sein. Zur Vermeidung von Wiederholungen werden nicht alle Details zu jeder Figur erneut wiederholt oder zu Details jeweils alle Alternativen genannt. Das Schlüsselmanagement, die Kommunikation mit dem Münz- und dem Transaktionsregister und insbesondere die unterschiedlich kombinierbaren Vorgaben sind nur einige entsprechende Beispiele. Fig. 7 zeigt den Ablauf eines Verfahrens, wenn eine bedingte Transaktion angefordert wird. Die Anforderung einer bedingten Transaktion 701 vom Benutzer 40 löst zunächst fast die gleichen Schritte 702, 703, 706, 707, 708 aus, wie eine normale, sofort auszuführende Transaktion mit den Schritten 502, 503, 506, 507, 508 in Fig. 5. Da als bedingte Transaktion in Fig. 7 zudem, wie in Fig. 5, eine Sende-Transaktion betrachtet wird, entsprechen die späteren Schritte 750 bis 758 den bekannten Schritten 510 bis 518 respektive. Es wird auf solche bereits beschriebenen Schritte nur verkürzt eingegangen.

Das Lesen der Münzdepotdaten 702 des in der Transaktions-Anforderung 701 mit seiner ID angegebenen Münzdepots und das Prüfen der Benutzer-Authentisierung 703 des Benutzers 40 erfolgen beispielsweise, wie zu Fig. 5 beschrieben.

Ebenfalls analog erfolgt eine Ablehnung 705 der Anforderung 701 falls beim Prüfen 704 der funktionellen Vorgabe(n) des Münzdepots festgestellt wird, dass für das Münzdepot die Transaktion nicht zulässig ist. hn Schritt des Prüfens 704 wird als funktionelle Vorgabe nun (zumindest auch) eine Vorgabe für bedingte Transaktionen geprüft. Wäre das Münzdepot beispielsweise auf einen anderen Typ bedingter Transaktionen und/ oder andere Bedingungen beschränkt, wäre die Anforderung abzulehnen. Neben der funktionellen Vorgabe kann optional beispielsweise eine Richtungsvorgabe und/ oder eine Betragsvorgabe zu prüfen sein, im vorliegenden Beispiel einer Sende-Transaktion die Vorgabe für die Senderichtung und eine eventuell vorhandene Betragsgrenze für das Senden.

Die weiteren Schritte des Prüfens des Depotbetrages 706 sowie des Erstellens 707 und registrieren eines Münzdatensatzes 708, 709 für die Transaktion könnten wiederum analog zu Fig. 5 erfolgen.

Eine bedingte Transaktion wird zunächst gespeichert 710. Es wird also noch nicht die zugehörige Transaktion ausgeführt, sondern erst später ausgeführt, wenn die in der Transaktion enthaltene Bedingung erfüllt ist. Die bedingte Transaktion umfasst die zu prüfende Bedingung und Datenelemente der späteren Transaktion. Wie in Fig. 4 dargestellt, kann das Speichern in einem Speicher für bedingte Transaktionen 436 des Münzdepots 430 oder in einen münzdepotübergreifenden Speicher 36 für bedingte Transaktionen erfolgen. In einer Variante wird in den Speicher 36 als Prüfliste nur die Bedingung zusammen mit einem Verweis auf die bedingte Transaktion gespeichert. Anzumerken ist, dass der dargestellte Ablauf, erst Prüfen 703 bis 705 dann Zwischenspeichern 710, gewährleistet, dass die spätere Transaktion für die bedingte Transaktion tatsächlich ausgeführt werden kann, sobald die Bedingung erfüllt ist.

In einem optionalen Schritt 711 speichert die sichere Ausführungseinheit 31 den Münzdepotdatensatz, insbesondere falls sich die Münzdepotdaten geändert haben. Das Speichern 711 oder das Speichern 710 kann wiederum ein Verschlüsseln der Münzdepotdaten, wie zuvor beschrieben, umfassen. Die Münzdepotdaten haben sich beispielsweise geändert, wenn der Speicher 436 des Münzdepots genutzt wird. Ebenso kann mit den optionalen Schritten 707 bis 709 bereits ein Münzdatensatz für die bedingte Transaktion erzeugt worden sein. Der Münzdatensatz für die bedingte Transaktion kann in den Münzdatensätzen des Münzdepots gespeichert werden. Vorzugsweise ist er dort als für die bedingte Transaktion reservierter bzw. gesperrter Münzdatensatz markiert. In einer Alternative könnte der Münzdatensatz für die bedingte Transaktion in der bedingten Transaktion selbst zwischengespeichert werden, insbesondere wenn der Speicher 436 des Münzdepots genutzt wird. In einer weiteren Alternative wird der Münzdatensatz für die bedingte Transaktion erst nach dem Zwischenspeichern 710 erstellt. Um die Ausführbarkeit der späteren Transaktion für die gespeicherten bedingte Transaktion zu gewährleisten, gibt es verschiedene Möglichkeiten. Der Transaktionsbetrag kann vom verfügbaren Depotbetrag abgezogen werden (für Schritte des Prüfens des Depotbetrags wie Schritt 706 oder 506). Ist der verfügbare Depotbetrag als separates Datenelement des Münzdepots vorgesehen, wird er reduziert. Auch könnte ein für bedingte Transaktionen reservierter Betrag als Datenelement des Münzdepotdatensatzes vorgesehen werden. Eine weitere speicherplatzsparende Möglichkeit wäre es, in Schritten des Prüfens 506, 706 des Depotbetrages nicht nur die verfügbaren Münzdatensätze zu berücksichtigen, sondern ebenso die zwischengespeicherten bedingten Transaktionen des Münzdepots auszulesen.

Mit den drei Punkten nach Schritt 711 und nach Schritt 734 in Fig. 7 ist angedeutet, dass die weiteren Schritte 721 bis 758 bzw. 741 bis 758 erst zu einem späteren Zeitpunkt folgen. Die Bearbeitung der Transaktions-Anfrage 701 für eine bedingte Transaktion ist abgeschlossen.

Die Ausführung einer Transaktion, die der bedingten Transaktion entspricht, erfolgt nur falls und/ oder erst wenn die Bedingung erfüllt ist. In Fig. 7 dargestellt ist ein Schritt des Prüfens der Bedingung 742, welcher beispielsweise in regelmäßigen zeitlichen Abständen ausgeführt wird oder in Antwort auf den Empfang eines Prüf- Auslösers 741 ausgeführt wird. Optional führt die Prüfung die Bedingungs- Prüfungseinheit 37 der Münzdepotverwaltungseinheit 30 aus.

Die gespeicherte bedingte Transaktion kann nun entsprechend ihrer Schreib- und/ oder Leserechte von Dritten oder vom Benutzer gelesen oder geschrieben werden 721-725, 731-735.

Im Beispiel der Fig. 7 sendet eine andere Münzverwaltungseinheit 390, die vorzugsweise einem anderen Benutzer zugeordnet ist, eine Leseanfrage 721 für ein Münzdepot. Die Leseanfrage kann gerichtet sein auf das Auslesen von

- genau einer bedingten Transaktion aus dem Münzdepot, die anhand ihrer Transaktionsnummer oder einer Referenznummer angegeben ist,

- einer Auswahl von bedingten Transaktionen des Münzdepots, die beispielsweise ein bestimmtes Kriterium, wie Transaktionstyp oder Transaktionspartner erfüllen, oder

- aller bedingten Transaktionen des Münzdepots.

Die Münzdepotdaten werden gelesen 722 und optional die Authentisierung der anfragenden Münzverwaltungseinheit 390 geprüft 723. Nach Prüfung der Leserechte 724 wird/werden die bedingte/ n Transaktion/ en der Münzverwaltungseinheit 390 bereitgestellt 725 (ausgelesen). Gegebenenfalls werden mehrere bedingte Transaktionen ausgelesen, wobei aus den bedingten Transaktionen des Münzdepots, insgesamt oder entsprechend der angeforderten Auswahl, jeweils nur die bedingten Transaktionen ausgelesen werden, für welche die Leserechte vorliegen. Prinzipiell könnte eine externe Schreibanfrage analog ablaufen, insbesondere falls die Anfrage zusätzlich zur Authentisierung des Dritten eine Authentisierung des Benutzers umfasst. hn Beispiel der Figur 7 sendet der Benutzer von seiner Benutzereinheit 40 eine Schreiboder Leseanfrage 731 für sein Münzdepot an die Münzdepotverwaltungseinheit 30. Eine Schreibanfrage wird auf genau eine bedingte Transaktion gerichtet sein. Die Leseanfrage kann wiederum genau eine bedingte Transaktion, eine Auswahl der bedingten Transaktionen oder alle bedingten Transaktionen betreffen. Die Münzdepotdaten werden in der Münzdepotverwaltungseinheit 30 gelesen 732, ggf. inklusive der nötigen Entschlüsselungsschritte, und die Authentisierung der Benutzers geprüft 733. Danach werden die Schreib- und/ oder Leserechte geprüft 734. Abhängig vom Vorliegen der Lese- und/ oder Schreibrechte wird die bedingte Transaktion geschrieben (geändert oder gelöscht) bzw. die bedingte(n) Transaktion(en) an die Benutzereinheit 40 gesendet 735 (und somit ausgelesen). Die bedingte Transaktion kann beispielsweise eine zeitliche Bedingung umfassen. Die Sende-Transaktion ist erst an einem bestimmten Datum oder erst zu einem bestimmten Zeitpunkt auszuführen (beispielsweise nach 36 Stunden oder ab 23:00 Uhr oder an einem bestimmten Wochentag).

Ein ggf. erfolgloses Prüfen der Bedingung 742 kann bereits vor den Lese-und/ oder Schreibanforderungen 721, 731 durchgeführt worden sein.

Es gibt bedingte Transaktionen, für die nur einmal eine Transaktion ausgeführt wird, beispielsweise zu einem Zeitpunkt (mit Datum und Uhrzeit) oder einem Auslöser, der in der Bedingung enthalten ist. Für andere bedingte Transaktionen kann mehrfach eine entsprechende Transaktion ausgeführt werden. Wenn beispielsweise eine bedingte Transaktion ein Angebot für eine Transaktion mit Gegenleistung enthält, die an Münzverwaltungseinheiten einer bestimmten Gruppe gerichtet ist, kann beispielsweise das Leserecht für diese Gruppe vergeben werden. Unabhängig davon ob die Münzverwaltungseinheiten die bedinge Transaktion erst durch ein Auslesen der bedingten Transaktion oder anderweitig kennen, könnten nacheinander verschiedene Münzverwaltungseinheiten der Gruppe das Angebot beispielsweise durch Senden eines Münzdatensatzes mit dem geforderten Betrag annehmen und die Gegenleistung zu erhalten. Beispielsweise kann das Münzdepot als Gegenleistung ein digitales Eingangs ticket für eine Veranstaltung an die Münzverwaltungseinheit senden.

Die bedingte Transaktion kann einen Sicherungswert umfassen. Erst oder nur falls der Sicherungswert der sicheren Ausführungseinheit bereitgestellt wird, wird die Transaktion ausgeführt. Der Sicherungswert kann eine Zufallszahl sein oder ein kryptographischer Sicherheitswert sein, der insbesondere aus den Daten der bedingten Transaktion abgeleitet ist (wie ein Hashwert oder eine Signatur, über einen Teil der bedingten Transaktion oder die bedingte Transaktion respektive). Der Sicherungswert kann insbesondere als der oder in dem Prüf- Auslöser 712 empfangen werden.

Die bedingte Transaktion kann ein externes Auslöse-Ereignis umfassen. Der Eintritt des externen Auslöse-Ereignisses wird vorzugsweise in oder mit dem Prüf- Auslöser 712 (von einem Dritten oder dem Transaktionspartner) empfangen. Geprüft wird dann der Inhalt der mit dem Prüf- Auslöser 712 empfangenen Daten. Alternativ kann die sichere Ausführungs-Einheit prüfen, beispielsweise durch Anfrage bei einem externen Server oder bei einer externen Datenstruktur (wie Blockchain oder Datenbank), ob das Auslöse-Ereignis eingetreten ist. Die bedingte Transaktion kann ferner eine zeitliche Begrenzung umfassen (Ausführung vor einem Zeitpunkt oder Datum). Die Bedingung, wie Sicherungswert oder externes Ereignis, muss also vor dem Erreichen der zeitlichen Begrenzung erfüllt sein. Nach Erreichen der zeitlichen Begrenzung wird die bedingte Transaktion nicht mehr ausgeführt. Eine zwischengespeicherte bedingte Transaktion wird nach Ablauf ihrer zeitlichen Begrenzung gelöscht.

Eine bedingte Transaktion wird optional genau einmal oder mehrfach ausgeführt. Die Anzahl der Ausführungen der bedingten Transaktion kann in der bedingten Transaktion angegeben sein.

Eine Vorgabe für bedingte Transaktionen kann beispielsweise eine zulässige Art bzw. die zulässigen Arten der Bedingung angeben, wie zeitliche Bedingung, Sicherungswert und/ oder externes Ereignis. Alternativ oder zusätzlich kann eine Vorgabe für bedingte Transaktionen eine Art der bedingten Transaktion enthalten, welche für das Münzdepot zulässig ist. Beispielsweise kann die Vorgabe angeben, ob eine bedingte Sende-Transaktion zulässig ist, ggf. unbeschränkt oder teilbeschränkt entsprechend einer allgemeinen Sendevorgabe oder entsprechend einer separaten Sendevorgabe für bedingte Transaktionen. Analog kann die Vorgabe angeben, ob eine bedingte Empfangs-Transaktion, eine bedingte Transaktion mit Gegenleistung oder eine bedingte Transaktion nach einem bestimmten Schema (Standard 1 oder proprietär 2) zulässig ist. Solche Vorgaben für bedingte Transaktionen können insbesondere vom Herausgeber vorab für das Münzdepot festgelegt und/ oder vom Benutzer gewählt worden sein. Sie beschränken, wie bereits gesagt, das Münzdepot funktionell auf bestimmte Funktionen aus den verfügbaren Funktionen, welche die sichere Ausführungseinheit bereitstellt.

Die weiteren Schritte des Erstellens 720 der Transaktion(snachricht), des Austauschens mindestens eines Münzdatensatzes 721 bis 724, des Schreibens 725 der Münzdepotdaten, des Bestätigens der Transaktion 726 und des Registrierens der Transaktion im Transaktionsregister 727, 728 sind bereits zu Fig. 5 beschrieben worden.

Ebenso wie ein Münzdepot mehrere Richtungsvorgaben und Betragsvorgaben umfassen kann, kann das Münzdepot alternativ oder zusätzlich auch eine Mehrzahl von Vorgaben für bedingte Transaktionen (wie Vorgaben von Herausgeber und/ oder Benutzer für die verschiedenen Arten und/ oder Richtungen) umfassen. Nicht in Fig. 7 separat dargestellt ist, dass eine bedingte Transaktion automatisch gelöscht wird. Beispielsweise wenn die bedingte Transaktion ihre Ausführungsbegrenzung (wie Anzahl der Ausführungen oder Zeitraum der möglichen Ausführung) erreicht hat oder unerfüllbar geworden ist, wird sie gelöscht. Sie kann also von der Ausführungseinheit 31 (und/oder der Prüfungs-Einheit 37) gelöscht werden, insbesondere wenn eine (oder mehrere) entsprechende Transaktion(en) ausgeführt wird/ worden ist (sind), wenn die Bedingung nicht mehr erfüllbar ist oder nach Ablauf eines Begrenzungszeitraums.

Anzumerken ist, dass das Verfahren gemäß Fig. 7 analog ablaufen würde, wenn man die Rollen der beteiligten Münzverwaltungseinheiten 31, 410 und 390 vertauscht. Die bedingten Transaktionen können also in der Münzverwaltungseinheit 390 gespeichert sein und von einer anderen Münzverwaltungseinheit, ggf. einer anderen Münzdepotverwaltungseinheit 30 ausgelesen oder geschrieben werden. Nur wenige Schritte, wie das Lesen der Münzdepotdaten, vereinfachen sich (keine Entschlüsselung) .

Am Beispiel von Fig. 8 werden verschiedene Aspekte der Vorgaben beschrieben, wie sie grundsätzlich und mit unterschiedlichem Inhalt in jedem der diskutierten Münzdepots bzw. der Münzverwaltungseinheiten vorliegen könnten.

Als Datenelemente sind mehrere Vorgaben 811-828 dargestellt und in den Münzdatensätzen 805 sind zwei Münzdatensätze symbolisch vereinfacht dargestellt (Betrag 13 bzw. 23 mit „dW" als digitale Währungseinheiten der Zentralbank- Währung).

Das Münzdepot bzw. die Münzverwaltungseinheit umfasst einerseits Herausgeber- Vorgaben 810 und Benutzer-Vorgaben 820. Andererseits umfasst es sowohl Empfangsvorgaben 811-814; 821-823 als auch Sendevorgaben 816-819; 826-828. In Anlehnung an die Darstellung in Fig. 3 sind in Fig. 8 die Empfangsvorgaben links von den Münzdatensätzen 805 und die Sende-Vorgaben rechts davon angeordnet.

Schließlich wird für funktionelle Vorgaben unterschieden zwischen Richtungsvorgaben 821, 811, 816, 826, Vorgaben für bedingte Transaktionen 822, 812, 817, 827 und Vorgaben für Transaktionen mit Gegenleistungen 814, 819. Das Münzdepot bzw. die Münzverwaltungseinheit umfasst zudem auch Betragsvorgaben 813, 838, 828. Die Herausgeber-Vorgaben 810 hat der Herausgeber zum Zeitpunkt der Erstellung des Münzdepots bzw. der Münzverwaltungseinheit vorab festgelegt. Die Benutzer- Vorgaben 820 sind vom Benutzer gewählt, jedoch enger gewählt als die gleichartigen Herausgeber-Vorgaben 810 (falls diese vorhanden sind).

Der Herausgeber ist Inhaber eines Geschäftes. Er beschränkt das von ihm für den Benutzer erstellte Münzdepot bzw. Münzverwaltungseinheit, daher in der Sende- Vorgabe 816 auf sein Geschäft „Das Geschäft". Die Sende-Vorgabe 816 enthält in der Praxis also die ID(s) der Münzverwaltungseinheit(en) des Geschäfts und nicht einen Klartextnamen, wie in der Figur dargestellt. Der Benutzer kann somit Münzdatensätze des vom Herausgeber erstellten Münzdepots bzw. Münzverwaltungseinheit nur an das fest vorgegebene Geschäft senden. Der Benutzer darf diese Vorgabe nicht weiter beschränken, deshalb wird ihm nicht angeboten eine Sende-Vorgabe des Benutzers 826 zu wählen. Dies wird in der Fig. 8 durch ein Kästchen mit gepunktetem Rand angezeigt. In Empfangsrichtung hat der Herausgeber in seiner Empfangsvorgabe 811 vorgesehen, dass Münzdatensätze von dem Geschäft oder vom Benutzer empfangen werden dürfen. Der Benutzer kann (optional und daher gestrichelt dargestellt) eine strengere Empfangsvorgabe des Benutzers 821 wählen. Der Benutzer hat im Beispiel keine Empfangsvorgabe ausgewählt, hätte aber beispielsweise eine Beschränkung auf „Das Geschäft" oder „Keiner" wählen können.

Wie in den Herausgeber-Vorgaben zu bedingten Transaktionen 812, 817 erkennbar, hat der Herausgeber das Münzdepot bzw. die Münzverwaltungseinheit des Benutzers hinsichtlich bedingter Transaktionen nicht separat beschränkt. Seine Sende- und Empfangsvorgaben 811, 816 sind jedoch auch für bedingte Transaktionen gültig. Der Benutzer hat sich entschieden bedingte Empfangs-Transaktionen nicht zuzulassen, wie es in der Benutzervorgabe 822 für die Empfangsrichtung von bedingten Transaktionen erkennbar ist („inaktiv"). Weiterhin möchte der Benutzer keine beliebigen bedingten Sende-Transaktionen zulassen, sondern nur die für ihn nützliche Art der Bedingung zulassen, die zeitliche Bedingung, die er für das Geschäft verwenden will. Er hat in seiner Benutzervorgabe 827 „Zeitbedingung" ausgewählt.

Für das Münzdepot bzw. die Münzverwaltungseinheit hat der Herausgeber zudem Betragsvorgaben 813, 818 fest vorgegeben. Das Münzdepot bzw. die Münzverwaltungseinheit darf gemäß Herausgeber-Vorgabe 813 maximal 50 digitale Währungseinheiten in einer Transaktion empfangen und gemäß Herausgeber-Vorgabe 818 maximal 200 digitale Währungseinheiten in einer Transaktion senden. Eine weitere Beschränkung des Betrages wird dem Benutzer in Empfangsrichtung nicht angeboten (gepunktetes Kästchen) für Benutzer-Vorgabe 823. In Senderichtung hat der Benutzer als maximalen Sendebetrag 50 digitale Währungseinheiten für sein Münzdepot in der Vorgabe 828 ausgewählt.

Schließlich hat der Herausgeber die vorhandene Option mit dem Münzdepot Transaktionen mit Gegenleistungen auszuführen ausgeschlossen. Die Herausgeber- Vorgaben für Transaktionen mit Gegenleistungen 814, 819 sind eine vollständige Beschränkung („inaktiv").

Herausgeber-Daten 809 können beispielsweise einen Ablaufzeitpunkt für das Münzdepot (Gültigkeitsgrenze) enthalten. Nicht dargestellt sind, aber natürlich vorhanden sein können, weitere der bereits genannten Datenelemente eines Münzdepots, wie nur beispielsweise die weiteren Datenelemente 237 - 239, 396a-c - 398a-c oder 436 - 438 aus Figur 3 und 4.

Der Benutzer kann mit diesen Vorgaben nun beispielsweise zwei bedingte Transaktion anlegen, die sich in den Schreibrechten und den Leserechten unterscheiden. Eine erste bedingte Transaktion ist nur vom Benutzer lesbar und schreibbar. Von dem Münzdepot sollen an den Empfänger „das Geschäft" mit der Bedingung „wöchentlich immer Sonntag morgens" ein Münzdatensatz mit dem Betrag 3 dW gesendet werden. Die bedingte Transaktion enthält als Transaktionstext für die spätere Transaktion „3 Einheiten liefern". Die bedingte Transaktion enthält jedoch noch keinen Münzdatensatz. Diese bedingte Transaktion kann die Münzverwaltungseinheit des Geschäfts nicht lesen. Eine zweite bedingte Transaktion ist für einen bestimmten Zeitpunkt vorgesehen und enthält bereits einen höherwertigen an das Geschäft zu sendenden Münzdatensatz, beispielsweise mit dem Betrag von 100 dW. Die zweite bedingte Transaktion ist eine garantierte, bedingte Transaktion. Der Benutzer und das Geschäft haben das Leserecht für die bedingte Transaktion, ein Schreibrecht ist jedoch nicht vergeben, so dass die Ausführung der zugehörigen Transaktion zum genannten Zeitpunkt garantiert ist. Abhängig von Implementierungsdetails der Transaktion, ist der Münzdatensatz ohne eine Zusatzinformation sowieso noch nicht verwendbar oder wird ein geheimes Datenelement des Münzdatensatzes abgesichert, beispielsweise erst beim Ausführen der Transaktion entschlüsselt. Die Münzverwaltungseinheit des Geschäftes kann die bedingte Transaktion lesen und weiß dadurch, dass und wann er den Münzdatensatz erhalten wird. Er kann nun beispielsweise eine höherwertige Ware für den Benutzer bestellen. Mit Schreib- und/ oder Leserechten selektiv versehene bedingte Transaktionen stellen, mit oder ohne Vorgaben, einen sehr flexiblen Weg dar, um eine überraschend große Vielfalt an Transaktionstypen zu ermöglichen.

Anhand von Fig. 9 sollen verschiedene bedingte Transaktionen und deren Datenelemente noch einmal genauer beschrieben werden.

Fig. 9 zeigt als Zeileneinträge einer Liste dargestellt, verschiedene bedingte Transaktionen, die anhand der Transaktionsnummer 931 unterscheidbar sind. Die Basisdaten 91 der bedingten Transaktion umfassen Sender 911, Empfänger 912 und Betrag 931. Die Bedingung 92 der bedingten Transaktion umfasst ein Prüfkriterium 921, eine Ausführungsbegrenzung 922 und optional den Typ 923 der bedingten Transaktion. Die Ausführungsbegrenzung 922 kann eine Ausführungsanzahl und/ oder eine Zeitangabe umfassen (wie „nur einmal" und/ oder „nur bis 03.03.2021 09.00 Uhr"). Die unterschiedlichen Lese- und/ oder Schreibrechte 96 sind verkürzt in Spalte 96 gezeigt. Die Erweiterungsdaten 93 umfassen Datenelemente, die optional sind und/ oder gegebenenfalls erst beim Ausführen der Transaktion erzeugt werden. Als Referenz 931 sind die Transaktionsnummern T-l bis T-2 die tatsächlichen Transaktionsnummern der später ausgeführten Transaktion. Dagegen sind die Transaktionsnummern R-l bis R-4 temporäre Referenzen für die bedingten Transaktionen. Münzdatensätze 932 enthalten nur die ersten beiden bedingten Transaktionen. Ein Transaktions-Bezugstext 933 kann vorgesehen sein.

Die ID der Münzverwaltungseinheit des Benutzers ist ID1. Die erste bedingte Transaktion mit der bereits erzeugten Transaktionsnummer T-l ist eine garantierte bedingte Transaktion. Es wird der bereits vorbereitete Münzdatensatz CI mit dem Betrag 913 ,100' vom Sender 911 mit ID1 an den Empfänger 921 mit ID2 in einer Transaktion gesendet, sobald das Prüfkriterium 921 , Datum' erfüllt ist (also an einem bestimmten Tag). Die Ausführungsanzahl 922 ist eins (einmalige Ausführung) und der Typ A, was in dem Beispiel für garantierte bedingte Transaktion stehen soll. Entsprechend hat der Benutzer gemäß den Schreib- und/ oder Leserechten ,T kein Schreibrecht, beide Transaktionspartner 911, 912 aber ein Leserecht. Der Transaktions- Bezugstext 933 enthält eine Information , A789', welche den Transaktionspartnern eine Zuordnung erlaubt, beispielsweise zu einer Rechnung.

Für garantierte bedingte Transaktionen hat der Benutzer kein Schreibrecht, die Lese- und/ oder Schreibrechte Dritter können sich jedoch unterscheiden. Beispielsweise die vierte bedinge Transaktion mit der Referenznummer R2 ist eine weitere garantierte bedingte Transaktion (Typ A). Wenn als Bedingung 921 der Gesamtbetrag der Münzdatensätze in der Münzverwaltungseinheit des Benutzers eine , Schwelle' überschreitet, wird ein Münzdatensatz mit dem Betrag 931 von ,10' von der Münzverwaltungseinheit des Benutzers an den Empfänger 912, die Münzverwaltungseinheit mit der ID4, gesendet. Die vierte bedingte Transaktion wird unbegrenzt oft ausgeführt, da keine Ausführungsbegrenzung 922 enthalten ist. Gemäß den Schreib- und/ oder Leserechten 96 ,IIT, hat der Benutzer kein Schreibrecht aber die Münzverwaltungseinheit mit der ID4 (Leserecht haben dagegen beide). Verschiedene bedingte Transaktionen eines Typs von bedingter Transaktion können die gleichen Schreib- und/ oder Leserechte 96 haben, ihre Schreib- und/ oder Leserechte 96 können sich - wie soeben gezeigt - jedoch auch unterscheiden.

Die zweite bedingte Transaktion mit der Referenznummer R-2 enthält ebenfalls bereits einen Münzdatensatz 932 ,C2'. Die Bedingung ist jedoch ein externes Ereignis, beispielsweise der Empfang eines geheimen Sicherungs wertes, wie Signatur oder Passwort für die bedingte Transaktion. Wenn die Münzverwaltungseinheit des Benutzers den Sicherungswert erhält, wird der Münzdatensatz in einer Sende- Transaktion an den Empfänger 912 ,ID3' gesendet. Die zweite bedingte Transaktion kann als abrufbare bedingte Transaktion bezeichnet werden. Als Typ 923 ist entsprechend ,B' eingetragen. Sie ist - in diesem Beispiel - gemäß Ausführungsanzahl 922 nur einmal abrufbar. Mit den Lese- und/ oder Schreibrechten 96 ,IT wird angegeben, dass nur die beiden Transaktionspartner das Leserecht haben und der Benutzer ein Schreibrecht hat.

Ebenfalls eine abrufbare bedingte Transaktion (Typ B) zeigt die fünfte Zeile. Abrufbare bedingte Transaktion enthalten eine Referenz, also insbesondere eine Transaktionsnummer oder (temporäre) Referenznummer, um eindeutig abrufbar zu sein. Die bedingte Transaktion mit der Referenznummer R-3 ist gemäß Spalte 922 dreimal abrufbar, kann gemäß Spalte 912 von allen Münzverwaltungseinheiten der Gruppe Gl abgerufen werden und kann auf Anfrage einer Münzverwaltungseinheit der Gruppe Gl an die aktuelle Münzverwaltungseinheit mit ID1, also ohne Kenntnis des Sicherungswertes, abgerufen werden. Die zweite und die fünfte bedingte Transaktion haben die gleichen Schreib- und/ oder Leserechte 96. In einer nicht separat dargestellten Variante ist eine abrufbare bedingte Transaktion für einen bestimmten Empfänger - einmalig, mehrmals oder unbegrenzt - durch eine Transaktionsanfrage abrufbar. Auch für diese Variante sind Schreib- und/ oder Leserechte 96 ,IT sinnvoll. Die dritte bedingte Transaktion mit der Referenz 931 ,R-T ist eine periodische bedingte Transaktion (Typ 923 ,C'). Sie wird periodisch ausgeführt, mit der Periode ,Zeit', also beispielsweise täglich, wöchentlich oder alle 2 Stunden, die in dem Prüfkriterium Bedingung 921 angegeben ist. In dieser bedingten Transaktion ist die Münzverwaltungseinheit des Benutzers der Empfänger 912. Sie erhält also periodisch einen (oder mehrere) Münzdatensatz mit dem angegebenen Betrag 913 von der Münzverwaltungseinheit ID4 als Sender 911. Die dritte und die vierte bedingte Transaktion haben die gleichen Schreib- und/ oder Leserechte 96, die Münzverwaltungseinheit ID4 kann diese bedingten Transaktionen schreiben. Anzumerken ist, dass die beiden bedingten Transaktionen aufeinander abgestimmt sind, die dritte bedingte Transaktion fordert periodisch das Senden von Münzdatensätzen von ID4 zu ID1 an und die vierte bedingte Transaktion sendet bei Überschreitung der genannten Schwelle - und solange diese Bedingung erfüllt ist - Münzdatensätze wieder zurück.

Die bedingten Transaktion eines Typs, wie beispielsweise periodische bedingte Transaktion, können Empfangs- oder Sendetransaktionen sein. Die vierte bedingte Transaktion könnte also auch als Sendetransaktion gestaltet sein.

Die sechste Transaktion mit der (optionalen) Referenznummer R-4 ist eine bedingte Gegenleistungstransaktion (Typ 923 ,D'). Die Bedingung 921 ist der Eingang einer Empfangstransaktion (Empfänger 912 ,IDT) mit dem Betrag 912 ,40' als Ereignis. Der Sender 911 muss der Gruppe G2 angehören. Die Gegenleistung GL kann im Transaktions-Bezugstext 933 beschrieben sein. Beispielsweise erhält der Sender ein Zugangsticket für eine Veranstaltung, beispielsweise als QR-Code an seine eMail- Adresse gesandt, die im Transaktions-Bezugstext der Empfangstransaktion angegeben ist. Da die Veranstaltung in dem Beispiel am Dienstag stattfindet, umfasst die sechste bedingte Transaktion eine zeitliche Ausführungsbegrenzung 922, sie ist bis ,Mo' (Montag) begrenzt. Die Schreib- und/ oder Leserechte 96 können unterschiedlich gewählt sein, im Beispiel mit ,IV' soll nur der Benutzer Lese- und Schreibrechte haben. Die Sender müssten über die Existenz der bedingten Transaktion auf anderem Wege, beispielsweise via eMail/ SMS/ Broadcast ... informiert werden. Wählt man dagegen Schreib- und Leserechte 96, welche auch den Münzverwaltungseinheiten der Gruppe G2 das Lesen ermöglichen, kann die separate Information entfallen.

Ohne Bezug zu Figur 9 sollen weitere Optionen für bedingte Transaktionen beschrieben werden, für eine Münzverwaltungseinheit, welche eine Gegenleistung anbietet. Die Gegenleistung könnte in digitaler Form bereitgestellt werden, in vielen Anwendungsfällen wird die Gegenleistung lokal erbracht und soll auch offline (ohne Netzverbindung) möglich sein. Die Gegenleistung kann beispielsweise ein Zugang zu einem Bereich (wie Stadion, Zoo oder Museum), Bereitstellung von Strom oder Betrieb einer Maschine (wie Waschmaschine oder Waschanlage) sein. Die Münzverwaltungseinheit des Benutzers, der die Gegenleistung erbringt, ist vorzugsweise eine lokale Münzverwaltungseinheit mit eigener Ausführungseinheit, die am Ort der Gegenleistung angeordnet ist, insbesondere ist sie ein reversibel einsetzbares oder fest eingebautes Sicherheitsmodul.

Die Münzverwaltungseinheit des Benutzers (Erbringer der Gegenleistung) kann unterschiedliche bedingte Gegenleistungstransaktionen mit zueinander unterschiedlichen (und optional gleichen) Schreib- und/ oder Leserechten umfassen.

Eine bedingte Gegenleistungstransaktion kann eine garantierte bedingte Transaktion sein (die der Benutzer also nicht ändern kann). Die garantierte bedingte Gegenleistungstransaktion wird beispielsweise bei der Herstellung der Münzverwaltungseinheit geschrieben und ist nicht mehr schreibbar, aber von jedermann lesbar. Bei einer Empfangstransaktion mit dem Betrag X, erhält der Sender stets eine Gegenleistung der Art Y und/ oder der Dauer Z, beispielsweise Strom oder Betrieb der Waschmaschine jeweils für 30 Minuten.

Eine weitere bedingte Gegenleistungstransaktion kann temporär abrufbar sein. Sie enthält eine zeitliche Ausführbarkeitsbegrenzung. Diese bedingte Transaktion ist für alle lesbar und vom Benutzer schreibbar. Im Beispiel wird die gleiche Gegenleistung in einem Zeitraum (wie , heute') für einen geringeren Betrag angeboten (wie Betrag: ,X - 10%').

Eine andere bedingte Gegenleistungstransaktion mit einem verringerten Betrag (wie Betrag: X- 5%) oder einer verbesserten Gegenleistung (Dauer: Z*l,2) kann den Empfang eines in der Bedingung oder dem Transaktions-Bezugstext angegebenen Codewertes voraussetzen. Diese bedingte Gegenleistungstransaktion ist für Dritte nicht lesbar (und für den Benutzer schreib- und lesbar). Der Dritte erfährt den Codewort nicht durch Auslesen der bedingten Transaktion. Er könnte den Codewert beispielsweise in der Zeitung, einer App, im Internet oder auf anderen Wegen erhalten. Dann sendet der Dritte den Codewert, insbesondere zusammen mit dem Münzdatensatz (beispielsweise im Transaktions-Bezugstext), an die Münzverwaltungseinheit des Benutzers. Die Bedingung der bedingten Transaktion ist erfüllt und die Gegenleistung wird bereitgestellt. Eine weitere bedingte Gegenleistungstransaktion kann nur für eine bestimmte Gruppe lesbar sein. Die Gegenleistung ist nur für Mitglieder dieser Gruppe, wie Stammkunden oder Firmenmitglieder, für den verringerten Betrag oder mit der verbesserten Gegenleistung (wie längere Dauer oder höhere Intensität der Gegenleistung, z.b.

Stromstärke an Ladesäule) lesbar und somit beispielsweise über die Referenznummer oder mit einem mitgelesenen Codewert abrufbar.

Die Münzverwaltungseinheit kann eine periodische bedingte Transaktion umfassen, welche die (insbesondere alle) empfangenen Münzdatensätze, beispielsweise einmal täglich, an eine Sammel-Münzverwaltungseinheit des Benutzers sendet. Mehrere Münzverwaltungseinheiten des Benutzers können eingerichtet sein, periodisch an die Sammel-Münzverwaltungseinheit zu senden. Falls die Münzverwaltungseinheit keine eigene Internetverbindung hat, werden die empfangenen Münzdatensätze erst zu einem späteren Zeitpunkt im Münzregister registriert und/ oder an die Sammel- Münzverwaltungseinheit des Benutzers übertragen.

Die Kodierung der Vorgaben 811-828 in Fig. 8 und der Datenelemente der bedingten Transaktion in Fig. 9 ist zur besseren Lesbarkeit in der Figur teils als Text dargestellt, kann aber in Länge und Kodierung beliebig (ein oder mehrere Bits, ein oder mehrere Bytes, Bytefolgen ... oder numerisch, hexadezimal, binär, String ... kodiert) sein. Eine Kodierung der Datenelemente des Münzdepots oder der bedingten Transaktion als TLV-Struktur (Tag, Length, Value) ist ebenso denkbar wie eine Kodierung der Transaktionen, der bedingten Transaktionen oder des Münzdepots in einem JSON- Format. hn Rahmen der Erfindung können alle beschriebenen und/oder gezeichneten und/ oder beanspruchten Elemente beliebig miteinander kombiniert werden.

BEZUGSZEICHENLISTE

1 Ausgabeschicht

2 Systemverwaltungsschicht

3 Transaktionsschicht

5 Münzdatensatz

6 Registerdatensatz

7 Transaktionsdatensatz

10 Zentralbankinstanz

20 Münzregister

25 Transaktionsregister

210, 220 Münzverwaltungseinheit

211 Ausführungseinheit

215 Münzdepot

217 Identifikator der Münzverwaltungseinheit

218 Kryptographischer Schlüssel

219 Zertifikat der Münzverwaltungseinheit

30 Münzdepotverwaltungseinheit

31, 391 Ausführungseinheit

310, 320, 330 Münzdepot

315, 325, 335, 395 Münzdatensatz

316 bedingte Transaktion

322, 392 Empf angs-V orgabe

323, 393 Sende-Vorgabe

326a, 336a, 396a erste bedingte Transaktion 326b, 336b, 396b zweite bedingte Transaktion 326c, 336c, 396c dritte bedingte Transaktion 327a, 337a, 397a erste Leserechte 327b, 337b, 397b zweite Leserechte

397c dritte Leserechte

328a, 338a, 398a erste Schreibrechte 328b, 338b, 398b zweite Schreibrechte 398c dritte Schreibrechte

32 Münzdepot-Erstellungseinheit

33 Benutzervorgaben-Einheit 34 Benutzerzugriffs-Einheit für bedingte Transaktionen

36 Prüfliste bedingter Transaktionen

37 Bedingungs-Prüfeinheit

38 Schlüsselverwaltungsmodul

39 Drittzugriffs-Einheit für bedingte Transaktionen

40 Benutzer-Einheit

50 Herausgeber-Einheit

237 Identifikator

238 Schlüssel

239 Zertifikat

401 Transaktions-Anforderung

402 Münzdepot-Anforderung

403 Konfigurations-Anforderung

404 Auslöse-Ereignis

405 Sende-Transaktion

406 Empfangs-Transaktion

407 Schreiben bedingter Transaktion

408, 409 Lesen bedingter Transaktionen

410, 420, 430 Münzdepots

432, 433 Vorgaben

435 Münzdatensatz

436 bedingte Transaktion

437 Schreibrechte bedingte Transaktion

438 Leserechte bedingte Transaktion

501 Transaktions-Anforderung

502 Lesen der Münzdepotdaten

503 Prüfen der Benutzer- Authentisierung

504 Prüfen der Vorgabe

505 Ablehnung der Anforderung

506 Prüfen des Depotbetrages

507 Erstellen und registrieren eines Münzdatensatzes

508. 512 Registrierungsanforderung

509. 513 Registrierungsbestätigung

510 Erstellen der Transaktion

511 Senden der Transaktion

514, 516 Transaktionsbestätigung

515 Schreiben der Münzdepotdaten 517 Erstellen des Transaktions-Registerdatensatzes

518 Transaktionsdaten-Registrierung

551 Transaktions- Anforderung

552 Lesen der Münzdepotdaten

554 Prüfen der funktionellen Vorgabe

557 Umschalten eines Münzdatensatzes

558 Registrierungsanforderung

559 Registrierungsbestätigung

565 Schreiben der Münzdepotdaten

566 Transaktionsbestätigung

567 Erstellen des Transaktions-Registerdatensatzes

568 Transaktionsdaten-Registrierung

601 Münzdepot- Anforderung

602 Prüfen der Herausgeber- Authentisierung

603 Erstellen des neuen Münzdepots

604 Erzeugen eines Identifikators

605 Erzeugen eines Schlüssels

606 Erstellen eines Zertifikats

607 Empfangen eines Münzdatensatzes

608 Erstellen einer Umschaltanforderung

609 Umschaltanforderung

610 Umschaltbestätigung

611 Schreiben der Münzdepotdaten

612 Münzdepot-Bestätigung

613 Zuordnungs-Anforderung

614 Registrieren des Münzdepot für Benutzer

701 Anforderung einer bedingten Transaktion

702, 722, 732 Lesen der Münzdepotdaten

703, 723, 733 Prüfen der Authentisierung

704 Prüfen der funktionellen Vorgabe

705 Ablehnung der Anforderung

706 Prüfen des Depotbetrages

707 Erstellen und registrieren eines Münzdatensatzes

708 Registrierungsanforderung

709 Registrierungsbestätigung 710 Speichern der bedingten Transaktion

711 Schreibe Münzdepotdaten

721, 731 Schreib-/ Leseanfrage für bedingte Transaktion

724, 734 Schreib-/ Leserechte prüfen

741 Prüf-Auslöser

742 Prüfen der Bedingung der Transaktion

750 Erstelle Transaktion

751 Transaktion (mit Münzdatensatz)

752 Registrierungsanforderung für modifizierten Münzdatensatz

753 Registrierungsbestätigung

754, 756 Transaktionsbestätigung

755 Schreiben der Münzdepotdaten

757 Erstellen Transaktions-Registerdatensatz

758 Transaktions-Registrierung

805 Münzdatensätze des Münzdepots

809 Herausgeber-Daten

810 Herausgeber-V orgaben

820 Herausgeber-Einstellungen

811, 821 Sender-Beschränkung

812, 822 Empfangsvorgabe für bedingte Transaktionen

813, 823 Betragsgrenze Empfang 814 Empfangsvorgabe für Gegenleistungen

816, 826 Empfänger-Beschränkung

817, 827 Sendevorgabe für bedingte Transaktionen

818, 828 Betragsgrenze Senden 819 Sendevorgabe für Gegenleistungen

91 Basisdaten der bedingten Transaktion

92 Bedingung der bedingten Transaktion

93 Erweiterungsdaten

911 Sender

912 Empfänger

913 Betrag

921 Prüfkriterium

922 Ausführungsbegrenzung

923 Typ der bedingten Transaktion

96 Schreib- und/ oder Leserechte Transaktionsnummer Münzdatensatz Textfeld/Transaktions-Bezugstext