DE102021004025A1 - Münzverwaltungseinheit sowie Verfahren in einer Münzverwaltungseinheit - Google Patents

Abstract

Die Erfindung betrifft eine Münzverwaltungseinheit, umfassend- eine sichere Ausführungseinheit (31; 391) zur Verwaltung von digitalen Münzdatensätzen, wobei die sichere Ausführungseinheit (31; 391) angepasst ist in Transaktionen digitale Münzdatensätze mit anderen Münzverwaltungseinheiten auszutauschen und Registrierungsanforderungen an ein Münzregister (20) zu senden; und- zumindest einen digitalen Münzdatensatz (305; 395; 435); wobei die sichere Ausführungseinheit (31) weiter angepasst ist für eine Transaktion eine erste Vorgabe und/oder eine zweite Vorgabe zu prüfen; wobeidie erste Vorgabe (333; 393; 433) und die zweite Vorgabe (334; 394; 434) in der Münzverwaltungseinheit als Vorgabedatenelemente gespeichert sind; unddie erste Vorgabe (333; 393; 433) und die zweite Vorgabe (334; 394; 434) das gleiche Prüfkriterium betreffen, wobei die zweite Vorgabe (434) eine Erhöhung der ersten Vorgabe (433) ist und/oder die zweite Vorgabe (334; 394) für eine andere Austauschrichtung zu prüfen ist als die erste Vorgabe (333; 393).

Description

• Die Erfindung betrifft eine Münzdepot-Verwaltungseinheit mit mehreren Münzdepots unterschiedlicher Benutzer, ein Verfahren zum Erstellen neuer Münzdepots in einer Münzdepot-Verwaltungseinheit mit mehreren Münzdepots und ein Verfahren zum Verwalten von Münzdatensätzen in einer Münzdepot-Verwaltungseinheit mit mehreren Münzdepots.
• 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 A1 verwendet und erweitert diesen dritten Ansatz, durch welchen die Münzdatensätze direkt zwischen den Benutzern ausgetauscht werden können. In WO 2020/212331 A1 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 wird beschrieben, dass eine lokale Münzverwaltungseinheit des Benutzers abhängig von einer Vorgabe, in Form eines Schwellwertes für einen Gesamtbetrag in der Münzverwaltungseinheit, Münzdatensätze in ein Tresormodul des Benutzers auslagern kann.
• WO 2020/212331 A1 zeigt den Oberbegriff von Anspruch 1.
• Es ist Aufgabe der vorliegenden Erfindung, ein Verfahren, eine Münzverwaltungseinheit und ein System zu schaffen, in denen eine Bezahltransaktion sicher aber dennoch einfach ausgestaltet ist.
• Diese Aufgabe wird gelöst mit einer Münzverwaltungseinheit, mit einem Verfahren zur Erstellung einer Münzverwaltungseinheit sowie mit einem Verfahren in einer Münzverwaltungseinheit, welche die Merkmale der unabhängigen Ansprüche umfassen. Die abhängigen Ansprüche betreffen bevorzugte Ausgestaltungen.
• Eine Münzverwaltungseinheit umfasst eine sichere Ausführungseinheit zur Verwaltung von digitalen Münzdatensätzen und zumindest einen digitalen Münzdatensatz. Die sichere Ausführungseinheit ist angepasst in Transaktionen digitale Münzdatensätze mit anderen Münzverwaltungseinheiten auszutauschen und Registrierungsanforderungen an ein Münzregister zu senden. Die sichere Ausführungseinheit ist weiter angepasst für eine Transaktion eine erste Vorgabe und/oder eine zweite Vorgabe zu prüfen.
• Die erste Vorgabe und die zweite Vorgabe sind in der Münzverwaltungseinheit als Vorgabedatenelemente gespeichert. Die erste Vorgabe und die zweite Vorgabe betreffen das gleiche Prüfkriterium, wobei die zweite Vorgabe eine Erhöhung der ersten Vorgabe ist und/oder die zweite Vorgabe für eine andere Austauschrichtung zu prüfen ist als die erste Vorgabe.
• Die Münzverwaltungseinheit kann somit Transaktionen sicher und unter Einhaltung der Vorgaben ausführen. Die Vorgaben sind nicht durch die sichere Ausführungseinheit festgelegt, sondern separat in einem Datenelement enthalten, so dass eine erhöhte Flexibilität erreicht wird.
• Die zweite Vorgabe kann von einem Benutzer als eine Erhöhung der ersten Vorgabe wählbar sein. Vorzugsweise ist die erste Vorgabe von einem Herausgeber der Münzverwaltungseinheit vorab festgelegt. Der Benutzer kann die erste Vorgabe nicht ändern. Die zweite Vorgabe kann abhängig von der ersten Vorgabe nur so gewählt werden, dass sich insgesamt eine Erhöhung der ersten Vorgabe ergibt. Für das gleiche Prüfkriterium kann es also eine Herausgeber-Vorgabe, die für den Benutzer der Münzverwaltungseinheit festgelegt ist, und eine Benutzer-Vorgabe, die der Benutzer wählen kann, geben. Die Benutzer-Vorgabe ist jedoch eine Erhöhung der Herausgeber-Vorgabe bzw. enger als die Herausgeber-Vorgabe. Naturgemäß sind systemweit 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 bzw. als Erhöhung der Systemvorgaben festlegen. Die sichere Ausführungseinheit hält insofern Systemvorgaben ein und prüft zudem die (funktionellen und anderen) Vorgaben der Münzverwaltungseinheit. Eine angeforderte Transaktion wird nur ausgeführt (oder im Fall einer bedingten Transaktion gespeichert), falls beide Vorgaben (erste und zweite Vorgabe) erfüllt sind.
• Die erste Vorgabe kann (alternativ oder ergänzend) eine Empfangs-Vorgabe und die zweite Vorgabe eine Sende-Vorgabe sein. Die beiden Vorgaben betreffen das gleiche Prüfkriterium sind jedoch für eine andere Austauschrichtung, Senden oder Empfangen, von digitalen Münzdatensätzen zu prüfen. Werden Münzdatensätze in der Transaktion empfangen, ist die Empfangsvorgabe zu prüfen. Werden Münzdatensätze in der Transaktion gesendet, ist die Sendevorgabe zu prüfen. Die Transaktion wird nur ausgeführt (oder im Fall einer bedingten Transaktion gespeichert), wenn die Sende- und/oder Empfangsvorgabe(n) erfüllt sind.
• Die sichere Ausführungseinheit wird vorzugsweise für die Transaktion mehrere, insbesondere mehrere erste und/oder zweite, Vorgaben prüfen. Die vorliegend beschriebenen Vorgaben sind jeweils in der Münzverwaltungseinheit als Vorgabedatenelemente gespeichert. Es können mehrere Paare aus Sende- und Empfangsvorgaben und/oder aus Benutzer- und Herausgebervorgaben vorliegen.
• Insbesondere kann es für das Prüfkriterium ein (oder mehrere) Vorgabenquadrupel geben, welches (jeweils) eine erste Empfangs-Vorgabe und eine zweite erhöhte Empfangsvorgabe sowie eine erste Sende-Vorgabe und eine erhöhte zweite Sendevorgabe umfasst. Bevorzugt liegt eine Empfangs- und eine Sende-Vorgabe des Herausgebers sowie eine Empfangs- und eine Sende-Vorgabe des Benutzers vor.
• Die zweite Vorgabe ist, insbesondere soweit sie nicht die andere Austauschrichtung betrifft, eine Erhöhung der ersten Vorgabe. Eine Erhöhung der ersten Vorgabe liegt insbesondere vor, wenn es durch die zweite Vorgabe schwieriger wird die Vorgabe zu erfüllen bzw. durch die zweite Vorgabe weniger denkbare Transaktionen die Vorgabe erfüllen.
• Die zweite, erhöhte Vorgabe umfasst beispielsweise einen gegenüber der ersten Vorgabe prüfungsbezogen erhöhten Zahlenwert (z.b.: Schwelle für Maximalwert: zweiter Vorgabewert kleiner als erster Vorgabewert; Schwelle für Minimalwert: zweiter Vorgabewert größer als erster Vorgabewert). Das Prüfkriterium kann ein Vergleich des Vorgabewertes als Schwelle (> oder >= bzw. < oder <=) mit einem Zahlenwert der Transaktion (wie Transaktionsbetrag, Anzahl Münzdatensätze, Zeitangabe ...) oder der Münzverwaltungseinheit (wie Anzahl der Münzdatensätze, Betragssumme der Münzdatensätze, Transaktionszahl in Zeitraum oder Transaktionssumme in Zeitraum) sein. Die Transaktion wird ausgeführt (oder als bedingte Transaktion gespeichert), wenn der entsprechende Zahlenwert der Transaktion bzw. der Münzverwaltungseinheit die in der Vorgabe enthaltene Schwelle einhält (Schwellwertkriterium).
• Die zweite, erhöhte Vorgabe kann beispielsweise aber auch mindestens einen (oder mehrere) - im Vergleich zur ersten Vorgabe - zusätzlichen nicht-zulässigen Vergleichswert(e) umfassen. Das Prüfkriterium kann ein Negativkriterium sein. Die Vorgabe enthält nicht-zulässige Vergleichswerte, welche die Transaktion nicht (als Transaktionsdatenelement oder Transaktionseigenschaft) enthalten darf. Die Transaktion wird nur ausgeführt (oder als bedingte Transaktion gespeichert), wenn der Vergleichswert kein Transaktionsdatenelement (wie Sender, Empfänger, Transaktionstyp,...) oder keine Eigenschaft der Transaktion ist.
• Die zweite, erhöhte Vorgabe kann vorzugsweise eine Auswahl oder Beschränkung der zulässigen Vergleichswerte (der ersten Vorgabe) sein. Das Prüfkriterium ist bevorzugt ein Positivkriterium. Die Vorgabe enthält zulässige Vergleichswerte, welche die Transaktion (als Transaktionsdatenelement oder Transaktionseigenschaft) enthalten darf. Die Transaktion wird nur ausgeführt (oder als bedingte Transaktion gespeichert), wenn der Vergleichswert in der Transaktion enthalten ist.
• Die sichere Ausführungseinheit kann die erste und die zweite, erhöhte Vorgabe nacheinander prüfen oder nur die zweite Vorgabe prüfen, welche die erste Vorgabe umfasst. Werden die Vorgaben nacheinander geprüft, erzielt man eine erhöhte Sicherheit. Die zweite Vorgabe kann optional die erste Vorgabe umfassen (also eine Auswahl oder Beschränkung der zulässigen Vergleichswerte der ersten Vorgabe bzw. die nicht-zulässigen Vergleichswerte der ersten Vorgabe und zumindest einen weiteren nicht-zulässigen Vergleichswert). In diesem Fall reicht es aus, nur die zweite Vorgabe zu prüfen. Die sichere Ausführungseinheit wird eine (vom Benutzer) gewählte (Benutzer-)Vorgabe als zweite Vorgabe nur speichern, wenn sie eine Erhöhung der ersten Vorgabe ist und/oder so speichern dass sie eine Erhöhung der ersten Vorgabe ist. Wenn beispielsweise nur die zweite Vorgabe geprüft wird, wird sie die logische Summe beider Vorgaben bilden und nur speichern, falls dadurch eine Erhöhung der ersten Vorgabe entsteht.
• Die bisher genannten und weiterhin genannten Vorgaben werden sich in der Münzverwaltungseinheit in der Regel unterscheiden. Die Vorgabe kann eine vollständige Beschränkung (wie „kein Senden“) eine teilweise Beschränkung (z.b. Angabe zulässiger Empfänger) oder eine fehlende Beschränkung (wie „alle Empfänger“) darstellen. Beispielsweise sind die Sende-Vorgabe und die Empfangsvorgabe für das Prüfungskriterium unterschiedlich. Die Richtungsvorgaben sind für eine Münzverwaltungseinheit also bevorzugt asymmetrisch ausgestaltet. Die Sende-Vorgabe kann das Senden von Münzdatensätzen vollständig beschränken oder teilweise beschränken, auf genau einen Empfänger, genau eine Empfängergruppe oder auf mehrere Empfänger und/oder Empfängergruppen. Der oder die Empfänger und/oder Empfängergruppe(n) sind in der Vorgabe enthalten, insbesondere durch Angabe einer Empfänger-ID, einer Empfängergruppen-ID oder eines Empfänger-ID-Anteils oder einer Zertifikatsgruppe. Ein Zertifikat kann eine Münzverwaltungseinheit als Mitglied einer Gruppe ausweisen, 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. Analog kann die Empfangsvorgabe das Empfangen von Münzdatensätzen vollständig beschränken oder teilweise beschränken, 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“. Das Prüfkriterium kann der Transaktionspartner der Transaktion sein, insbesondere in seiner Rolle als Sender oder Empfänger von Münzdatensätzen.
• Sender und/oder Empfänger können durch ihren Münzverwaltungseinheits-Identifikator angegeben sein, kurz: Sender-ID bzw. Empfänger-ID. Sender- und/oder Empfängergruppen können beispielsweise durch einen Münzverwaltungseinheits-Identifikatoranteil angegeben sein. Insbesondere gehört jeder Empfänger oder Sender zu der Gruppe, wenn deren Münzverwaltungseinheits-Identifikator den Anteil umfasst, also beispielsweise mit diesem Anteil beginnt bzw. sich nur durch einen individuellen Anteil des Identifikators unterscheidet.
• Die erste und die zweite Vorgabe können Vorgaben für bedingte Transaktionen sein. Vorgaben für bedingte Transaktionen enthalten vorzugsweise eine Art der Bedingung, wie zeitbedingt, ereignisbedingt oder sicherungswertbedingt, und/oder eine Art der bedingten Transaktion (beispielsweise eine einfache Transaktion oder eine komplexe Transaktion, wie etwa: mit Gegenleistung oder mit mehreren Empfängern oder mit Empfänger und Sender), insbesondere die zulässigen Arten, welche für die Münzverwaltungseinheit zulässig sind. 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 die Münzverwaltungseinheit jedoch nur noch selektiv bzw. beschränkt zugelassen.
• Die sichere Ausführungseinheit wird eine bedingte Transaktion insbesondere zwischenspeichern, (nur) wenn die Vorgaben für bedingte Transaktionen erfüllt sind. Die sichere Ausführungseinheit wird eine bedingte, insbesondere zwischengespeicherte, Transaktion erst ausführen, wenn eine Bedingung erfüllt. Die bedingte Transaktion kann insbesondere eine zeitliche Bedingung, ein externes Auslöse-Ereignis als Bedingung und/oder einen Sicherungswert als Bedingung umfassen.
• Die zeitliche Bedingung gibt vorzugsweise einen Zeitpunkt an, ab wann die bedingte Transaktion auszuführen ist. Die sichere Ausführungseinheit erkennt, dass die zeitliche Bedingung erfüllt ist, also insbesondere der Zeitpunkt erreicht ist und führt die Transaktion aus. Die zeitliche Bedingung kann alternativ oder als weiterer Zeitpunkt angeben, ab wann die bedingte Transaktion nicht mehr auszuführen ist (ausführbar „bis“ respektive „von bis“). Eine solche zeitliche Bedingung ist in der Regel mit einer weiteren Bedingung verknüpft. Eine bedingte Transaktion kann eine externe Bedingung (Auslöse-Ereignis) und/oder einen Sicherungswert umfassen. Die zwischengespeicherte bedingte Transaktion wird erst ausgeführt, wenn der Sicherungswert empfangen und/oder eine Bestätigung für das Vorliegen der externen Bedingung/für das externe Ereignis empfangen wird. Als Sicherungswert kann beispielsweise eine Zufallswert oder ein kryptographischer Sicherungswert (Hash von Daten/Signatur von Daten) dienen. Insbesondere der Empfänger der Transaktion oder ein Dritter kann 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.
• 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 Vorgabe für bedingte Transaktion kann die Anzahl der Ausführungen, die in der bedingten Transaktion enthalten sein darf, beschränken.
• Ebenso kann die erste und die zweite Vorgabe oder eine weitere Vorgabe eine Betragsvorgabe sein. Die Benutzer-, Herausgeber-, Sende-, oder Empfangsvorgaben können Betragsvorgaben sein. Die Betragsvorgabe kann ein Maximalwert für den Betrag der zu sendenden und/oder für den Betrag der zu empfangenden Münzdatensätze sein. Ebenso kann die Betragsvorgabe ein Maximalwert (oder ein Minimalwert) für einen Gesamtbetrag der in der Münzverwaltungseinheit gespeicherten Münzdatensätze sein oder für eine Transaktionssumme der von der Münzverwaltungseinheit in einem Zeitraum (wie 1 Stunde, 1 Tag, 1 Woche,...) ausgeführten Transaktionen sein.
• Als funktionelle Vorgaben können (betragsunabhängige) Vorgaben zu vorhandenen Funktionen, wie Zwischenspeichern bedingter Transaktionen, Senden oder Empfangen von Münzdatensätzen ..., der sicheren Ausführungseinheit bezeichnet werden. Vorzugsweise wird durch die funktionelle Vorgabe eine der vorhandenen Funktionen der sicheren Ausführungseinheit beschränkt, insbesondere betragsunabhängig beschränkt. Die funktionellen Vorgaben betreffen bevorzugt eine (von mehreren) von der sicheren Ausführungseinheit ausführbare(n) Funktion(en). Die ausführbare Funktion wird durch die funktionelle Vorgabe vollständig oder teilweise beschränkt. Betragsvorgaben sind keine funktionellen Vorgaben im vorliegenden Sinne.
• Eine vollständige Beschränkung, wie beispielsweise bei einer Richtungsvorgabe „kein Senden“ oder „kein Empfangen“, kann in einer Vorgabe unterschiedlich gespeichert werden. Bevorzugt ist die vollständige Beschränkung als Inhalt der 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 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 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.
• In der Münzverwaltungseinheit sind vorzugsweise ferner eines oder mehrere der folgenden Datenelemente gespeichert:
• - ein eindeutiger Münzverwaltungseinheits-Identifikator; und/oder
• - ein öffentlicher Münzverwaltungseinheits-Schlüssel eines asymmetrischen Schlüsselpaares; optional ein geheimer Münzverwaltungseinheits-Schlüssel des asymmetrischen Schlüsselpaares; und/oder
• - ein Münzverwaltungseinheits-Zertifikat, welches insbesondere den Münzdepot-Identifikator und/oder den öffentlichen Münzdepot-Schlüssel als zertifizierte Inhalte umfasst.
• 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-1e325b336031.
• 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.
• Das erste und/oder das zweite Münzdepot kann eine teilweise frei auslesbare Vorgabe umfassen, insbesondere auch die ersten bzw. zweiten 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 erste und/oder die zweite Vorgabe kann eine Gegenleistungs-Vorgabe sein. Vorzugsweise wird die Gegenleistung in Antwort auf mindestens einen empfangenen Münzdatensatz als Leistung, insbesondere in den Antwortdaten an den Sender des empfangenen Münzdatensatzes, bereitgestellt.
• 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.
• Alternativ oder ergänzend kann die sichere Ausführungseinheit zur Verwaltung der Münzdatensätze eine Transaktionsanfrage empfangen (von einem Benutzer oder einer anderen Münzverwaltungseinheit) und/oder einen Münzdatensatz senden (Transaktionen mit anderen Münzverwaltungseinheiten ausführen). Die Transaktionsanfrage umfasst insbesondere einen Transaktionsbetrag, einen Münzverwaltungseinheits-Identifikator des Senders sowie eine Münzverwaltungseinheits-Identifikator des Empfängers. Nur optional umfasst sie ferner bereits einen eindeutigen Transaktions-Identifikator und/oder einen Transaktions-Bezugstext. Ein Ausführen einer Transaktion mit einer anderen Münzverwaltungseinheit umfasst den Übergang mindestens eines Münzdatensatzes von dem Münzdepot an die andere Münzverwaltungseinheit (Empfänger).
• Die Münzverwaltungseinheit kann eine lokale Münzverwaltungseinheit (des Benutzers) sein. Alternativ ist die Münzverwaltungseinheit eine serverbasierte Münzverwaltungseinheit, die entweder für den Benutzer der Münzverwaltungseinheit eine eigene sichere Ausführungseinheit umfasst oder für mehrere Benutzer, in einer Münzdepot-Verwaltungseinheit mit Münzdepots der Benutzer, eine gemeinsame sicheren Ausführungseinheit umfasst. Jedes Münzdepot eines Benutzers in der Münzdepot-Verwaltungseinheit bildet zusammen mit der gemeinsamen sicheren Ausführungseinheit eine Münzverwaltungseinheit, die im vorliegenden Sinne ausgestaltet sein kann.
• Die sichere Ausführungseinheit kann zur Verwaltung der Münzdatensätze in einer Transaktion mit einer weiteren Münzverwaltungseinheit, ein empfangenes Datenelement der weiteren Münzverwaltungseinheit auswerten. Das weitere Datenelement kann eine Vorgabe der weiteren Münzverwaltungseinheit vollständig oder anteilig umfassen und die sichere Ausführungseinheit kann für die Transaktion die Vorgabe der weiteren Münzverwaltungseinheit prüfen.
• In bevorzugten Ausgestaltungen stellt die Münzdepot-Verwaltungseinheit für andere Münzverwaltungseinheiten eine Schnittstelle zum Abruf von Vorgaben (und/oder Bedingungen) der Münzdepots bereit. Die andere Münzverwaltungseinheit sendet die ID eines Münzdepots der Münzdepot-Verwaltungseinheit an die Schnittstelle. In Antwort auf einen Abruf für eine Münzverwaltungseinheits-ID werden die zugehörigen, auslesbaren Vorgaben und/oder Bedingungen des Münzdepots gesendet, insbesondere getrennt von einem Zertifikat (für den öffentlichen Schlüssel) des Münzdepots oder zusätzlich zu einem Zertifikat (für den öffentlichen Schlüssel) des Münzdepots.
• Jedes Münzdepot in der Münzdepot-Verwaltungseinheit bildet zusammen mit der sicheren Ausführungseinheit eine Münzverwaltungseinheit. Die Münzdepot-Verwaltungseinheit umfasst insofern Münzverwaltungseinheiten unterschiedlicher Benutzer. Münzverwaltungseinheiten eines Benutzers mit eigener Ausführungseinheit verwalten dagegen nur Münzdatensätze in einem (oder mehreren) Münzdepot(s) des Benutzers.
• Ein erstes und zweites Münzdepot können einem ersten (dem gleichen) Benutzer zugeordnet sein. Der erste Benutzer hat zwei Münzdepots in der Münzdepotverwaltungs-Einheit, die unterschiedliche Vorgaben umfassen. Der Benutzer kann ein oder mehrere Münzdepots in der Münzdepot-Verwaltungseinheit sowie eine (oder mehrere) lokale Münzverwaltungseinheit(en). Die lokale Münzverwaltungseinheit des Benutzers kann beispielsweise in der Form eines Sicherheitsmoduls, wie Chipkarte, SIM-Karte, RFID-Token, NFC-Modul, eingebautes Sicherheitsmodul oder integriertes Sicherheitsmodul, vorliegen. Die Münzdepot-Verwaltungseinheit wird von einem Betreiber bereitgestellt, der beispielsweise ein Finanzdienstleister, wie eine Geschäftsbank, ein Kreditkartenanbieter oder ein Zahlungsdienstleister (Paypal, ...), sein kann.
• Die Münzdepot-Verwaltungseinheit speichert die Münzdepots vorzugsweise in verschlüsselter Form ab. Erst für ein Auslesen der Münzdepotdaten wird der Münzdepotdatensatz (des Münzdepots) entschlüsselt. Besonders bevorzugt sind die Münzdepotdatensätze individuell verschlüsselt, weiter bevorzugt mit individuellen Schlüsseln verschlüsselt. Die Münzdepot-Verwaltungseinheit kann mit Vorteil ein Hochsicherheitsmodul umfassen, welche zumindest einen Schlüssel speichert. Das Hochsicherheitsmodul stellt den (oder die individuellen, ggf. individuell abgeleiteten) Entschlüsselungsschlüssel bereit. Das Hochsicherheitsmodul kann zudem auch weitere Schlüssel, wie beispielsweise den zumindest einen geheimen Schlüssel (je)des Münzdepots, speichern, der beispielsweise zur Signaturerzeugung, Authentisierung oder Entschlüsselung dienen kann. Die sichere Ausführungseinheit fordert dann beispielsweise eine Signatur, einen Authentisierungswert oder eine Entschlüsselung von dem Hochsicherheitsmodul an, so dass die geheimen Schlüssel nur in dem Hochsicherheitsmodul verwendet werden. Alternativ zur Verwendung eines Hochsicherheitsmoduls kann die Verwaltung der Schlüssel auch auf mehrere Rechner in der Münzdepot-Verwaltungseinheit aufgeteilt werden, nur die mehreren Rechner gemeinsam können den jeweils benötigten Schlüssel berechnen und/oder verwenden.
• Ein Verfahren zur Ausgabe einer neuen Münzverwaltungseinheit, die eine sichere Ausführungseinheit zur Verwaltung von digitalen Münzdatensätzen umfasst, für einen Benutzer, beinhaltet die folgenden Schritte.
• - Empfangen einer Anfrage zur Erstellung der neuen Münzverwaltungseinheit;
• - Bereitstellen der neuen Münzverwaltungseinheit mit gespeicherten Datenelementen, wobei eine sichere Ausführungseinheit eingerichtet ist erste und/oder zweite Vorgaben für eine Transaktion zu prüfen. Vorliegend umfasst die Anfrage zumindest die erste Vorgabe und die im Schritt des Bereitstellens gespeicherten Datenelemente umfassen die erste Vorgabe als Vorgabedatenelement. Die erste Vorgabe ist eine für den Benutzer festgelegte Herausgeber-Vorgabe und eine zweite, als Datenelement speicherbare, Vorgabe wird für das gleiche Prüfkriterium vorgesehen. Die zweite Vorgabe ist entweder für eine andere Austauschrichtung zu prüfen als die erste Vorgabe oder ist - nach dem Schritt des Bereitstellens - vom Benutzer als Erhöhung der ersten Vorgabe wählbar.
• Die Münzverwaltungseinheit zur Ausgabe der neuen Münzverwaltungseinheit kann weiterhin einen oder mehrere der folgenden Schritte ausführen:
• - Prüfen einer in der Anfrage enthaltenen Authentisierung;
• - Erzeugen eines Münzverwaltungseinheits-Identifikators, welche insbesondere einen Anteil einer Vorgabe, vorzugsweise der ersten Vorgabe umfasst;
• - Erzeugen eines Münzverwaltungseinheits-Schlüssels;
• - Bereitstellen eines Münzverwaltungseinheits-Zertifikats, welches insbesondere einen Anteil einer Vorgabe oder einen weiteren Anteil der Vorgabe, vorzugsweise der ersten Vorgabe umfasst. Das Zertifikat umfasst vorzugsweise die ID und/oder einen öffentlichen Schlüssel der Münzverwaltungseinheit. Das Bereitstellen kann ein Erstellen des Zertifikats in der Münzverwaltungseinheit umfassen. Alternativ wird das Zertifikat extern erstellt und von der Münzverwaltungseinheit empfangen.
• Ein Prüfen einer Authentisierung für die Anfrage erfolgt bevorzugt durch Prüfen einer Authentisierung, die in der Anfrage enthalten ist. Alternativ kann die Authentisierung des Anfragenden auch bereits vor oder nach dem Empfang der Anfrage geprüft werden. Der Anfragende ist der Herausgeber der Münzverwaltungseinheit. Im Fall einer Münzdepot-Verwaltungseinheit ist er der Herausgeber der Münzverwaltungseinheit, für welche ein neues Münzdepot erstellt wird. Der Herausgeber ist also weder der Benutzer des Münzdepots noch der Betreiber der Münzdepot-Verwaltungseinheit.
• Die Schritte des Erzeugens von Identifikator, Schlüssel und/oder Zertifikat erfolgen bevorzugt vor dem Speichern der Datenelemente der neuen Münzverwaltungseinheit (bzw. der Münzdepotdaten), so dass die gespeicherten Datenelemente zumindest den Identifikator und optional auch den Schlüssel und weiter optional das Zertifikat umfassen. Alternativ, insbesondere in einer Münzdepot-Verwaltungseinheit, können einer oder mehrere der Schritte des Erzeugens auch nach dem Schritt des Speicherns der Datenelemente der neuen Münzverwaltungseinheit (bzw. der Münzdepotdaten) erfolgen. Das neue Münzdepot wird vorzugsweise ohne das Zertifikat der Münzverwaltungseinheit, weiter vorzugsweise auch ohne den Schlüssel der Münzverwaltungseinheit und alternativ oder noch weiter bevorzugt ohne den Identifikator gespeichert.
• Die Anfrage kann einen Benutzer(namen) umfassen, für welchen die neue Münzverwaltungseinheit erstellt wird. Der Benutzer(name) wird in der Regel nicht in den Datenelementen der Münzverwaltungseinheit gespeichert. Vorzugsweise wird eine Zuordnung ,Münzverwaltungseinheit zu Benutzer durch den Herausgeber oder den Betreiber der Münzdepot-Verwaltungseinheit in einer separaten Speichereinheit gespeichert. Insbesondere wenn der Benutzer bereits bekannt ist, werden Identifikator, Schlüssel und Zertifikat der Münzverwaltungseinheit bereits beim Erstellen des Münzverwaltungseinheit mit erzeugt und im Münzdepot gespeichert, also nicht erst nachgelagert erzeugt und gespeichert.
• Die neue Münzverwaltungseinheit kann auch ohne Benutzer-Zuordnung erstellt werden. Eine Zuordnung des erstellten neuen Münzverwaltungseinheit zu einem Benutzer erfolgt dann in Antwort auf eine Zuordnungsanforderung. Die Zuordnungsanforderung fordert die Zuordnung einer Münzverwaltungseinheit zu dem Benutzer an, welche wiederum vorzugsweise in der separaten Speichereinheit des Herausgebers der Münzverwaltungseinheit oder des Betreibers der Münzdepot-Verwaltungseinheit gespeichert wird. Die Zuordnungsanforderung kann von dem Herausgeber, dem Benutzer oder einem Dritten empfangen werden. Die Zuordnungsanforderung des Benutzers oder Drittens kann einen Berechtigungscode umfassen, den der Benutzer von dem Herausgeber erhalten hat.
• Die gespeicherten Datenelemente der Münzverwaltungseinheit umfassen bevorzugt mindestens einen Münzdatensatz. Vorzugsweise wird die sichere Ausführungseinheit zur Verwaltung von digitalen Münzdatensätzen
• - einen Münzdatensatz für die neue Münzverwaltungseinheit empfangen und/oder
• - eine Registrierungsanforderung an ein Münzregister senden, welche insbesondere als Ersatz für einen empfangenen bisher im Münzregister registrierten Münzdatensatz die Registrierung eines in der neuen Münzverwaltungseinheit zu speichernden Münzdatensatzes anfordert. Im Münzregister ist dann der neue Münzdatensatz registriert (als gültig gespeichert) und der bisher registrierte Münzdatensatz nicht mehr registriert (gelöscht oder als ungültig gespeichert).
• Wie bereits angedeutet, kann die Münzverwaltungseinheit eine serverbasierte Münzverwaltungseinheit sein, die entweder für den Benutzer der Münzverwaltungseinheit eine eigene sichere Ausführungseinheit umfasst oder für mehrere Benutzer, in einer Münzdepot-Verwaltungseinheit mit Münzdepots der Benutzer, eine gemeinsame sicheren Ausführungseinheit umfasst. Das Erstellen eines neuen Münzdepots in der Münzdepot-Verwaltungseinheit, entspricht dem Ausgeben einer neuen Münzverwaltungseinheit.
• Ein Verfahren zur Verwaltung von Münzdatensätzen in einer Münzverwaltungseinheit, die eine sichere Ausführungseinheit und zumindest einen Münzdatensatz umfasst, enthält die folgenden Schritte:
• - Empfangen einer Transaktions-Anfrage;
• - Lesen von in der Münzverwaltungs-Einheit gespeicherten Datenelementen;
• - Prüfen einer ersten Vorgabe und/oder einer zweiten Vorgabe;
• - Ausführen einer Transaktion oder Speichern einer bedingten Transaktion, die der Transaktions-Anfrage entspricht.
• Vorliegend werden die erste Vorgabe und die zweite Vorgabe in der Münzverwaltungseinheit als Vorgabedatenelemente gespeichert. Entsprechend werden in dem Schritt des Lesens die erste Vorgabe und/oder die zweite Vorgabe gelesen. Die erste Vorgabe und die zweite Vorgabe betreffen das gleiche Prüfkriterium, wobei die erste Vorgabe eine Herausgeber-Vorgabe und die zweite Vorgabe eine Benutzer-Vorgabe ist und/oder die erste Vorgabe eine Empfangs-Vorgabe und die zweite Vorgabe eine Sende-Vorgabe ist.
• Die Herausgeber-Vorgabe und die Benutzer-Vorgabe können Richtungsvorgaben sein. Alternativ oder ergänzend sind die erste und zweite Vorgabe Vorgaben für bedingte Transaktionen und/oder Gegenleistungs-Vorgaben und/oder Betrags-Vorgaben. Die ausgeführte Transaktion kann eine einfache Transaktion (Senden oder Empfangen von Münzdatensatz), mit oder ohne Bereitstellung einer Gegenleistung, oder eine zuvor gespeicherte bedingte Transaktion, mit oder ohne Bereitstellung einer Gegenleistung, sein. Ebenso kann die gespeicherte bedingte Transaktion eine Transaktion mit oder ohne Bereitstellung einer Gegenleistung sein.
• In dem Schritt des Prüfens wird für die Transaktion ein Datenelement der Transaktions-Anfrage, insbesondere ein Transaktionsbetrag oder ein Transaktionspartner, und/oder ein Datenelement der Münzverwaltungseinheit, das durch die Ausführung der Transaktion geändert wird, geprüft, insbesondere mit der Vorgabe verglichen. Für ein Datenelement der Münzverwaltungseinheit wird bevorzugt ein Folgezustand des Datenelements nach Ausführung der angeforderten Transaktion mit der Vorgabe verglichen. Es wird also insbesondere geprüft, ob der Schwellwert der Vorgabe durch die Transaktion überschritten werden würde.
• Ferner kann in dem Schritt des Prüfens abhängig von der Austauschrichtung der Transaktion die Sende-Vorgabe und/oder die Empfang-Vorgabe geprüft werden. Zudem kann entweder nur die Benutzer-Vorgabe, welche enger ist als die Herausgeber-Vorgabe, geprüft werden oder können die Benutzer-Vorgabe und die Herausgeber-Vorgabe beide geprüft werden. Weiterhin können in dem Schritt des Prüfens abhängig von der angeforderten Transaktion unterschiedliche Vorgaben, insbesondere mehrere Vorgaben für unterschiedliche Datenelemente der Transaktion oder der Münzverwaltungseinheit, geprüft werden.
• Eine Transaktionsanfrage sendet in der Regel der Benutzer des Münzdepots. In Ausgestaltungen kann die Transaktionsanfrage auch von einer anderen Münzverwaltungseinheit oder einem Transaktionspartner (Sender oder Empfänger von Münzdatensätzen) an die Münzdepot-Verwaltungseinheit gesendet werden.
• Wird die Transaktions-Anfrage von dem Benutzer empfangen kann die bedingte Transaktion als vom Benutzer freigegebene bedingte Transaktion gespeichert werden.
• Alternativ oder ergänzend kann die bedingte Transaktion beim Speichern nur zwischengespeichert und später ausgeführt werden, wenn eine auslösende Bedingung erfüllt ist, oder beim Speichern als Freigaberahmen des Benutzers für spätere Transaktions-Anfragen eines Dritten, der insbesondere als Empfänger in der bedingten Transaktion genannt ist, gespeichert werden. Die Transaktions-Anfrage oder eine weitere Transaktions-Anfrage von einem Dritten, insbesondere des Empfängers der Transaktion, kann eine auslösende Bedingung für eine gespeicherte bedingte Transaktion sein. In diesem Fall wird entweder die zwischengespeicherte bedingte Transaktion ausgeführt wird oder eine vom Dritten angeforderte Transaktion ausgeführt wird, welche unter die vom Benutzer freigegebene, gespeicherte bedingte Transaktion fällt (angeforderter Transaktionsbetrag kleiner und/oder gleich gespeicherter Betrag sowie angeforderter Empfänger entspricht gespeichertem Empfänger oder gespeicherter Empfängergruppe).
• Das Ausführen der Transaktion, insbesondere der angeforderten oder der bedingten 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.
• Der Schritt des Ausführens der Transaktion umfasst, wie bereits gesagt, das Senden mindestens eines Münzdatensatzes von der Münzverwaltungseinheit zu einem Empfänger (oder das Empfangen mindestens eines Münzdatensatzes, der insbesondere in der Transaktionsanfrage 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, der Münzverwaltungseinheit 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 Transaktion-ID 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": "Vorgangsnummer 1234898942"
 }

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

 {
 "Transaktions-ID": "1c102b5f-5496-459d-8a67-3bf1c348b113",
 "Sender": "urn:münzverwaltungseinheit:meine-bank.com:dlafujr3jbd",
 "Empfänger": "urn:münzverwaltungseinheit:deine-bank.com:3hbbda903988r",
 "Münzdatensätze": [
  { 

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

 },

  { 
  "Betrag": 60, "... Nummer": „1aaa77777777777733333c9123812123712814"

 }

 ],
 "Transaktions-Bezugstext": "Rechnung 1234898942"
 }

Die Münzverwaltungseinheit kann wie zuvor beschrieben ausgestaltet sein. Die beschriebenen Verfahren können für eine Münzverwaltungseinheit nacheinander ausgeführt werden.

Ein digitales Währungs-System umfasst eine Vielzahl der beschriebenen Münzverwaltungseinheiten, das Münzregister sowie optional eine Mehrzahl von Münzdepot-Verwaltungseinheiten und/oder ein Transaktionsregister.

Die vorliegende Lösung ist besonders vorteilhaft, da die hohe Flexibilität in der Münzverwaltungseinheit 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:

• 1 ein digitales Zentralbank-Währungs-System mit Münzverwaltungseinheiten sowie einem Münzregister der Zentralbank;
• 2 eine Münzverwaltungseinheit mit einer Ausführungseinheit und einem Münzdatensatz;
• 3 ein digitales Zentralbank-Währungs-System mit einer Münzdepotverwaltungs-Einheit;
• 4 eine Münzdepot-Verwaltungseinheit;
• 5 ein Ablaufdiagramm für ein Verfahren mit einer Transaktions-Anforderung;
• 6 ein Ablaufdiagramm für ein Verfahren mit einer Münzdepot-Anforderung;
• 7 ein Ablaufdiagramm für ein Verfahren mit einer Anforderung einer bedingten Transaktion;
• 8 ein Ausführungsbeispiel für Vorgaben eine Münzdepots.

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 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 kann die Gültigkeit des Münzdatensatzes 5 mit Hilfe des Münzregisters 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 A1 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 A1 gebunden.

Der Ansatz in 1 dargestellt Ansatz ist insbesondere vorteilhaft, da weder das Münzregister 20 noch das Transaktionsregister 25 Münzdatensätze 5 umfassen müssen.

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 Münzdatensätze des Münzdepots zu verwalten (Münzdatensätze senden/empfangen, Registrierungsanforderungen senden).

Weiterhin umfasst die Münzverwaltungseinheit 210 einen Identifikator der Münzverwaltungseinheit 217 als Datenelement. Identifikatoren 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 der Münzverwaltungseinheit 219 sind weitere Datenelemente der Münzverwaltungseinheit 210. Bevorzugt dient der kryptographische Schlüssel zur Authentisierung der Münzverwaltungseinheit und/oder zur Signatur von Daten, insbesondere im Rahmen einer Transaktion. Das Zertifikat kann den Identifikator und/oder den Schlüssel, in der Regel den öffentlichen Schlüssel eines Schlüsselpaares 218, der Münzverwaltungseinheit betreffen.

In den 1 bis 4 sind Datenelemente, wie die Münzdatensätze 215, mit rechteckigen Kästchen und funktionale Einheiten, wie die Ausführungseinheit 211, mit abgerundeten Ecken dargestellt. Die zu 1 und 2 beschriebenen Inhalte sind für sich genommen bekannt, werden aber im Folgenden ebenfalls verwendet.

3 zeigt eine Münzdepot-Verwaltungseinheit 30 mit mehreren Münzdepots 310, 320 und 330 unterschiedlicher Benutzer und einer Ausführungseinheit 31 zur Verwaltung von Münzdatensätzen. Die Münzdepots 310, 320, 350 umfassen mindestens einen Münzdatensatz 315, 325, 335. Die Münzdepots 310, 320, 330 sind Münzdepotdatensätze, bestehen also aus Datenelementen, wie dem jeweils mindestens einen Münzdatensatz sowie weiteren Datenelementen. Dargestellt ist weiterhin eine Münzverwaltungseinheit 390, die eine Ausführungseinheit 391 sowie Münzdatensätze 395 umfasst. Die Münzdepots 310, 320, 330 bilden jeweils zusammen mit der gemeinsamen Ausführungseinheit 31 eigenständige Münzverwaltungseinheiten 310,31; 320,31; 330,31. Jede der Münzverwaltungseinheiten 310,31; 320,31; 330,31; 390 wird seine eigene ID, Schlüssel und/oder Zertifikate umfassen.

Sowohl die Münzdepot-Verwaltungseinheit 30 als auch die Münzverwaltungseinheit 390 sind in der Transaktionsschicht 3 angeordnet. Der Vollständigkeit halber sind in der Systemverwaltungsschicht 2 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ünzverwaltungseinheiten 390; 310,31; 320,31; 330,31 bzw. die Münzdepots 310, 320, 330 umfassen jeweils zwei Richtungsvorgaben für unterschiedliche Austauschrichtungen. Die erste Vorgabe ist eine Empfangs-Vorgabe 393; 313; 323; 333 und die zweite Vorgabe ist eine Sende-Vorgabe 394; 314; 324; 334. In der Figur werden die Richtungsvorgaben mittels der dargestellten Pfeile symbolisiert. Die Pfeilrichtung zeigt die Austauschrichtung (Senden oder Empfangen von Münzdatensätzen). Die unterschiedliche Anzahl der Pfeile deutet bereits an, dass die Vorgaben unterschiedlich sein können. Die als Datenelemente gespeicherten Vorgaben, wie die Richtungsvorgaben, werden von der Ausführungseinheit 31, 391 geprüft, bevor eine Transaktion ausgeführt wird.

Beschrieben wird nun ein Beispiel, in welchem die Richtungsvorgaben zulässige Empfänger oder Sender enthalten. Empfangs-Vorgaben können zulässige (oder nicht zulässige) Sender (Sender-Vorgabe) umfassen. Sende-Vorgaben können entsprechend zulässige Empfänger (Empfänger-Vorgabe) umfassen. Richtungsvorgaben können jedoch alternativ oder zusätzlich zu Sender-Vorgaben bzw. Empfänger-Vorgaben auch Betragsvorgaben umfassen.

Die Empfangsvorgabe 313 des ersten Münzdepots 310 enthält nur eine Sender-ID einer Münzverwaltungseinheit und beschränkt somit den Empfang für das erste Münzdepot 310 auf diesen Sender von Münzdatensätzen. Die Sender-ID könnte beispielsweise einer Münzverwaltungseinheit des Benutzers oder eines Herausgebers des ersten Münzdepots 310 gehören. Das Münzdepot 310 kann dann Münzdatensätze nur vom Benutzer bzw. von seinem Herausgeber empfangen. Die Sendevorgabe 314 des Münzdepots 310 enthält dagegen beispielsweise keine Beschränkung. Das Münzdepot 310 könnte also Münzdatensätze an jede andere Münzverwaltungseinheit senden. Das erste Münzdepot 310 ist also unbeschränkt im Hinblick auf die Empfänger und teilbeschränkt im Hinblick auf Sender.

Die Empfangsvorgabe 323 des zweiten Münzdepots 320 enthält eine Mehrzahl zulässiger Sender-IDs und/oder eine oder mehrere zulässige Sendergruppen. Das zweite Münzdepot 320 kann somit Münzdatensätze von unterschiedlichen Münzverwaltungseinheiten empfangen. Diese müssen jedoch eine ID haben, welche in der Empfangsvorgabe 323 enthalten ist, oder zu der Sendergruppe gehören, was ebenfalls an der ID erkennbar sein kann. Das zweite Münzdepot 320 ist in Senderichtung stärker beschränkt als in Empfangsrichtung. Die Sendevorgabe 324 umfasst beispielsweise nur ein oder zwei zulässige Empfänger oder nur eine zulässige Empfängergruppe. Das zweite Münzdepot 320 ist also teilbeschränkt im Hinblick auf die Empfänger und weniger beschränkt im Hinblick auf Sender.

Das dritte Münzdepot 330 umfasst nochmals andere Richtungsvorgaben. Gemäß Empfangsvorgabe 333 gibt es keine zulässigen Sender. Die Ausführungseinheit 31 wird somit für das Münzdepot 330 keine Empfangs-Transaktionen ausführen. Die Sendevorgabe 334 enthält eine Empfänger-ID (oder eine Empfängergruppe). Das dritte Münzdepot 330 kann seine Münzdatensätze nur an diese(n) Empfänger senden. Das dritte Münzdepot 330 ist also teilbeschränkt im Hinblick auf die Empfänger und vollständig beschränkt im Hinblick auf Sender.

Zunächst als Gegenbeispiel könnte die Münzverwaltungseinheit 390 dienen, wenn sie in beide Richtungen unbeschränkt sein würde, also an beliebige IDs senden oder von beliebigen IDs empfangen kann. Vorliegend umfasst jedoch auch die Münzverwaltungseinheit 390 in ihrer Empfangsvorgaben 393 mehrere Empfänger-IDs (und/oder Empfängergruppen) und in der Sendevorgaben 394 mehrere Sender-IDs (und/oder Sendergruppen). Die Münzverwaltungseinheit 390 kann somit durch die Vorgaben symmetrisch oder asymmetrisch beschränkt sein.

Jedes der Münzdepots 310, 320 und 330 ist einem Benutzer zugeordnet. Die Zuordnung des Münzverwaltungseinheits-ID zu dem Benutzer wird jedoch vorzugsweise nicht in dem Münzdepot und weiter vorzugsweise nicht in der Münzdepot-Verwaltungseinheit 30 gespeichert, sondern in einer externen (nicht dargestellten) Datenstruktur (welche die ID zusammen mit dem vollständigen Namen des Benutzers enthält). Die Münzdepot-Verwaltungseinheit 30 umfasst Münzdepots unterschiedlicher Benutzer, die gezeigten Münzdepots können unterschiedlichen Benutzern oder mindestens teilweise einem einzigen Benutzer zugeordnet sein.

In Ausgestaltungen enthält die Münzverwaltungseinheit keine Richtungsvorgabe für eine nicht vorhandene Beschränkung. Bevorzugt enthält die Richtungsvorgabe jedoch die Nicht-Beschränkung. Beispielsweise ist sie kodiert durch: „*“ oder „alle“ für beliebige IDs.

Es ist anzumerken, dass eine Richtungsvorgabe nicht nur genau eine ID, oder mehrere IDs umfassen kann, sondern auch Gruppen von IDs oder Mischungen aus Gruppen und einzelnen IDs umfassen kann. Eine Gruppe von IDs kann beispielsweise mit einer ID-Maske angegeben werden. Die ID-Maske gibt nur Anteile einer ID vor, die übereinstimmen müssen, wie beispielsweise „ABC??1311560*“. So können beispielsweise alle IDs, 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 im Endanteil folgenden Seriennummer).

Eine weitere mögliche Ausgestaltung soll nun zu 3 anhand einer anderen Auslegung der Bedeutung der Pfeile an den Münzdepots 310, 320, 330 und 390 beschrieben werden. Die Anzahl der Pfeile deutet die maximale Höhe des erlaubten Transaktionsbetrages (einer Transaktion) an. Mit einem Pfeil könnte in 3 ein geringer Maximalbetrag, wie 10 dW oder 20 dW (dW = digitale Währungseinheiten) und mit drei Pfeilen ein hoher Maximalbetrag, wie 1000 oder 2000 dW, angedeutet sein. Ohne Pfeil bedeutet dass der Maximalbetrag gleich Null ist. Eine im digitalen Währungssystem gültige Systemgrenze, von beispielsweise 5000 dW, wird von den Ausführungseinheiten stets berücksichtigt (geprüft). Die in den Datenelementen der Münzverwaltungseinheiten enthaltenen Betragsvorgaben sind dagegen spezifisch für die Münzverwaltungseinheiten.

Das erste Münzdepot 310 könnte in einer Sende-Transaktion maximal den geringen ersten Maximalbetrag empfangen, aber maximal den höheren zweiten Maximalbetrag senden. Das zweite Münzdepot 320 könnte in einer Sende-Transaktion maximal den höheren zweiten Maximalbetrag empfangen und maximal den geringeren ersten Maximalbetrag senden. Das dritte Münzdepot 330 ist im Senden betragsmäßig stark eingeschränkt und darf (wiederum) keine Empfangs-Transaktionen annehmen.

Die Münzverwaltungseinheit 390 wäre für den Transaktionsbetrag einer Sende- oder Empfangstransaktion gleichermaßen beschränkt.

Wie bereits angedeutet kann jede der Richtungsvorgaben neben einer Sender- oder Empfängervorgabe auch eine Betragsvorgabe umfassen.

Ein Herausgeber eines Münzdepots könnte in einem Beispiel für einen Benutzer ein Münzdepot 330 mit Münzdatensätzen 335 bereitstellen und vorab den einzig zulässigen Empfänger oder eine einzige zulässige Empfängergruppe festlegen.

Ein Herausgeber von Münzdepots könnte in einem anderen Beispiel für einen Benutzer das zweite Münzdepot 320 ohne Empfangsbeschränkung und das erste Münzdepot 310 ohne Sendebeschränkung anlegen. Das zweite Münzdepot 320 ist dabei auf ein Senden an das erste Münzdepot 310 beschränkt. Das erste Münzdepot 310 kann in Empfangsrichtung unbeschränkt oder anders beschränkt sein.

4 zeigt eine Münzdepot-Verwaltungseinheit 30, eine Benutzereinheit 40 sowie eine Herausgeberinstanz 50.

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

Gegebenenfalls optionale Datenelemente oder Einheiten sind hier und in den weiteren Figuren mit gestrichelten Linien dargestellt. In dem Münzdepot 430 enthalten sind als optionale, aber in der Regel vorhandene, Datenelemente beispielsweise ein Identifikator 437, zumindest ein Schlüssel 438 und ein Zertifikat 439 (jeweils der Münzverwaltungseinheit, gebildet durch das Münzdepot 430 und die Ausführungseinheit 31 der Münzdepot-Verwaltungseinheit 30).

Die Vorgaben 432 umfassen Herausgeber-Vorgaben 434 und Benutzer-Vorgaben 433. Die Herausgeber-Vorgaben 434 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 433. Die Benutzer-Vorgaben 434 sind eine Erhöhung der Herausgeber-Vorgaben 433. Die Herausgeber-Vorgaben 433 bleiben insofern gültig. Sie werden zusätzlich zu den Benutzer-Vorgaben 434 geprüft werden oder werden (direkt oder indirekt) in die Benutzer-Vorgaben übernommen. 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) Vorgabe des Herausgebers, wie „Senden an alle“ und/oder „Empfangen von allen“ und/oder „keine Betragseinschränkung“, kann der Benutzer eine Benutzer-Vorgabe vollkommen frei wählen. Ausgehend von einer teilbeschränkenden Vorgabe des Herausgebers, wie „Senden nur an ID-Gruppe 1 oder an ID-Gruppe 2“ kann der Benutzer (optional für sich) eine engere Benutzer-Vorgabe wählen, wie „Senden nur an ID1 aus ID-Gruppel oder an ID2 aus ID-Gruppel“. Ausgehend von einer vorhanden Betragsschwelle des Herausgebers, wie „maximal 500 dW“, kann er (optional für sich) eine prüfungsbezogen erhöhte Betragsschwelle wählen, wie „maximal 400 dW“.

Die Münzdepot-Verwaltungseinheit 30 umfasst eine Münzdepot-Erstellungseinheit 33, welche eine Münzdepot-Anforderung 402 des Herausgebers verarbeiten kann und eine Benutzervorgaben-Einheit 34, welche eine Konfigurations-Anforderung 403 des Benutzers verarbeiten kann. Ein Benutzer kann von seiner Benutzereinheit 40, wie Mobilfunkgerät, PC oder Terminal, die Konfigurations-Anforderung 403 an die Münzdepot-Verwaltungseinheit 30 senden.

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

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

Die Ausführungseinheit 31 ist eingerichtet die Münzdatensätze der Münzdepots in Transaktionen 405, 406 mit anderen Münzverwaltungseinheiten auszutauschen und Registrierungsanforderungen an das Münzregister zu senden.

Ein Schlüsselverwaltungsmodul 38 der Münzdepot-Verwaltungseinheit 30 ist vorzugsweise ein Hochsicherheitsmodul für kryptographische Schlüssel. Das Schlüsselverwaltungsmodul 38 kann geheime Schlüssel der Münzdepots 310, 320, 330 speichern. Der im Münzdepot 330 gespeicherte Schlüssel 338 der Münzverwaltungseinheit 330, 31 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 sichere Ausführungseinheit 31 mit dem geheimen Schlüssel oder anderen Schlüsseln des Münzdepots. Für die unterschiedlichen Zwecke können eigene Schlüsselpaare vorgesehen sein. Das Schlüsselverwaltungsmodul 38 kann ferner abgeleitete Schlüssel, wie Sitzungsschlüssel, erstellen und verwenden (oder der Ausführungseinheit 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 310, 320, 330 werden vorzugsweise verschlüsselt in der Münzdepot-Verwaltungseinheit 30 gespeichert. Bei Bedarf, also beispielsweise bei einer Transaktions- oder Konfigurations-Anforderung für das Münzdepot 330, wird das Münzdepot entschlüsselt. Es wird nur das Münzdepot 330 entschlüsselt, wobei insbesondere ein für das Münzdepot 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ünzdepot) enthält, kann es alternativ den abgeleiteten Schlüssel für die Entschlüsselung/Verschlüsselung des Münzdepots der sicheren Ausführungseinheit 31 bereitstellen.

Der Benutzer kann von seiner Benutzereinheit 40 eine Transaktions-Anforderung 401 an die Münzdepot-Verwaltungseinheit 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 5 beschrieben. Die Ausführungseinheit 31 prüft die Vorgaben 432, bevor die Sende-Transaktion abhängig vom Prüfungsergebnis ausgeführt wird (oder nicht). Ebenfalls zu 5 wird die Prüfung der Vorgabe 432 im Falle des Empfangs von Münzdatensätzen (Empfangs-Transaktion 406) beschrieben.

Die Vorgaben 332 können nicht nur Richtungsvorgaben sein, sondern beispielsweise auch Vorgaben für bedingte Transaktionen 416 oder Vorgaben für Transaktionen mit Gegenleistung 419. In 3 angedeutet ist bereits, dass diese Vorgaben 416, 419 auch zusätzlich vorliegen können.

In dem Münzdepot 330 oder münzdepotübergreifend kann ein Speicherbereich 426, 36 zur (Zwischen-)Speicherung bedingter Transaktionen vorgesehen sein. Bedingte Transaktionen werden erst gespeichert und später - nachdem die Bedingung erfüllt ist - ausgeführt. Ein entsprechendes Verfahren wird genauer beschrieben mit Bezug auf 7.

Um eine Transaktion mit Gegenleistung ausführen zu können, umfasst die Münzdepot-Verwaltungseinheit 30 eine Gegenleistungseinheit 39. 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 in Gegenleistungsdaten 429 des Münzdepots 330 einstellbar ist. Die Gegenleistungsvorgaben 419 beschränken die für das Münzdepot 330 zulässigen Gegenleistungsfunktionen. Ausgehend von den in der Gegenleistungseinheit 39 verfügbaren Gegenleistungsfunktionen, werden also für das Münzdepot selektiv bestimmte Gegenleistungsfunktionen, -kodierungen oder -subtypen ausgeschlossen.

Das Konzept der aufeinander aufbauenden Herausgeber- und Benutzer-Vorgaben wurde anhand von 4 für Münzverwaltungseinheiten einer Münzdepot-Verwaltungseinheit beschrieben, ist aber analog anwendbar auf Münzverwaltungseinheiten mit eigener sicherer Ausführungseinheit. So kann die Münzverwaltungseinheit 390 aus 3 alternativ zu den Richtungsvorgaben 393, 394 (oder in den Richtungsvorgaben 393, 394 zusätzlich) Herausgeber- und Benutzer-Vorgaben umfassen. Der Benutzer kann beispielsweise zu einer festgelegten Herausgeber-Vorgabe in Empfangsrichtung und/oder in Senderichtung (Beispiel Senden: „Sender-Gruppe und Maximalbetrag = 200 dW“), eine demgegenüber erhöhte Benutzer-Vorgabe wählen (im Beispiel Senden: „2 Sender-IDs aus Sender-Gruppe und Maximalbetrag = 150 dW“).

5 zeigt einen Verfahrensablauf 501 bis 528 in der Münzdepot-Verwaltungseinheit 30, der mit dem Empfang einer Transaktionsanforderung 501 von einem Benutzer 40 (bzw. dessen Benutzereinheit) beginnt, sowie den Verfahrensablauf 551 bis 568 beim Empfangen von Münzdatensätzen von einer Münzverwaltungseinheit 390.

Die Transaktionsanforderung 501 umfasst eine ID einer Münzverwaltungseinheit (bzw. des Münzdepots) in der Münzdepot-Verwaltungseinheit 30 und fordert das Senden eines Betrages von dieser Sender-ID an eine Empfänger-ID an. Die sichere Ausführungseinheit 31 der Münzdepot-Verwaltungseinheit 30 liest die Münzdepotdaten des Münzdepots. Bevorzugt stellte das Schlüsselverwaltungsmodul 38 der sicheren Ausführungseinheit 31 entweder den Entschlüsselungsschlüssel, der individuell für das Münzdepot gewählt ist, bereit oder die bereits entschlüsselten Münzdepotdaten bereit. In den Schritte 503, 504, 506 führt die sichere Ausführungseinheit 31 mehrere Prüfungen aus, bevor es die angeforderte Transaktion in den Schritte 507 bis 526 ausführt. 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 Transaktionsanforderung 501 enthalten sein oder in Schritt 503 separat angefordert und empfangen werden.

Zumindest eine (der) Vorgabe(n) des Münzdepots wird in Schritt 504 geprüft. Im vorliegenden Beispiel einer einfachen Sende-Transaktion, wird geprüft ob die Empfänger-ID, eine ID gemäß der funktionellen Vorgabe ist. Ist das Münzdepot gemäß Herausgeber-Vorgabe in Empfangsrichtung unbeschränkt oder ist die Herausgeber-Vorgabe in Empfangsrichtung erfüllt, wird die Benutzervorgabe, die eine ID-Gruppe und zwei IDs von Empfängern umfasst, geprüft. Entspricht die Empfänger-ID der Transaktionsanfrage nicht der Vorgabe, wird die Transaktionsanforderung 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 entspricht, wird das Verfahren fortgesetzt (und die Transaktion ausgeführt). In Schritt 506 wird geprüft, ob der Depotbetrag, also der Betrag des Münzdatensatzes im Münzdepot oder der Summe der Beträge der Münzdatensätze im Münzdepot, größer ist als der angeforderte Betrag.

Vorzugsweise sendet die Münzdepot-Verwaltungseinheit 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 sichere Ausführungseinheit 31 erstellt in Schritt 520 nun eine Transaktionsnachricht 521, die an die Münzverwaltungseinheit 210 mit der Empfänger-ID gesendet wird. Die Transaktionsnachricht 521 umfasst eine Transaktions-ID, die ID des Münzdepots, die Empfänger-ID und den neuen Münzdatensatz. Optional enthält die Transaktionsnachricht 521 einen Transaktionsbezugstext, der in der Regel aus der Transaktionsanfrage stammt, und/oder einen Authentisierungswert, der für die Transaktion mit Hilfe des geheimen Schlüssels des Münzdepots erzeugt ist. Vorzugsweise wird für die Transaktion, insbesondere also in Schritt 521, eine gegenseitige Authentisierung der beiden beteiligten Münzverwaltungseinheiten (310, 31 und 210) vorgenommen. Der Schritt 520 des Erstellens und Sendens der Transaktionsnachricht 521 kann in mehreren Teilschritten mit einer Mehrzahl von ausgetauschten Teilnachrichten (nur beispielsweise für die Authentisierung) ablaufen.

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

In Schritt 525, also vorzugsweise erst nach Erhalt der Transaktionsbestätigung 524, speichert die sichere Ausführungseinheit 31 die geänderten Münzdepotdaten des Münzdepots 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 526 kann an den Benutzer 40 gesendet werden. In bevorzugten Varianten wird in Schritt 527 ein Transaktionsregisterdatensatz 528 erstellt und an das Transaktionsregister 25 gesendet.

Vorzugsweise wird für die Transaktionsanfrage 501 und/oder die Transaktionsnachricht 521 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 Transaktionsanfrage 501 und/oder die Transaktionsnachricht 521 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 210 (oder eine gegenseitige Authentisierung) ausgeführt werden, bevor ein Münzdatensatz ausgetauscht wird.

Der zweite in 5 gezeigte Ablauf wird durch den Empfang einer Transaktionsnachricht 551 bzw. eine 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. Die Münzverwaltungseinheit 390 will also einen Münzdatensatz an das Münzdepot senden. Die sichere Ausführungseinheit 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 Lesen 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 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.

Die in den 5 bis 7 jeweils für ein Münzdepot mit gemeinsamer Ausführungseinheit beschriebenen Abläufe, können analog in einer Münzverwaltungseinheit mit eigener Ausführungseinheit ablaufen. Das Verfahren wird allenfalls geringfügig einfacher, da anfänglich gegebenenfalls die Identifizierung des Münzdepots und die Entschlüsselung entfällt.

In 5 wurde die Sende-Transaktion vom Benutzer angefordert, es ist jedoch denkbar, dass die Transaktions-Anforderung von der anderen Münzverwaltungseinheit 210, 390 empfangen wird. Eine solche Sende-Transaktions-Anforderung eines Dritten, insbesondere des Empfängers, sollte dann jedoch einen Authentisierungswert des Benutzers umfassen oder wäre notfalls vom Benutzer separat freizugeben (in Schritt 503). Es wäre theoretisch sogar denkbar, ein Freigabeanforderungskriterium für Transaktionsanforderungen Dritter zu definieren. Ist das Kriterium erfüllt, wird für die vom Dritten angeforderte Transaktion eine Freigabe angefordert. Die gemeinsame Wirkung von Kriterien und Vorgaben ist für manchen Benutzer nicht mehr ausreichend zuverlässig nachvollziehbar. Wie zu 7 beschrieben werden wird, gibt es einen besseren Weg Sende-Transaktionsanforderungen Dritter zu ermöglichen.

6 zeigt den Ablauf eines Verfahrens zur Ausgabe einer neuen Münzverwaltungseinheit, hier durch 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 Herausgeber- und Benutzer-Vorgaben, die Sende- und/oder Empfangsvorgaben enthalten können. 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.

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 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 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 (D1, D2, D3) beziehen (z.b.: „encrypt(D1,D2,D3...)“ oder „encrypt(D1), 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 6 ausgelöst. Der Herausgeber 50 könnte somit eine Mehrzahl an neuen Münzdepots erstellen lassen (Schritte 601 bis 612). Erst bedarfsweise (zu einem späteren Zeitpunkt und gegebenenfalls einzeln) werden die (noch nicht nutzbaren) Münzdepots einem Benutzer zugeordnet (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 VideoIdent-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äß 6 kann beispielsweise eine Münzverwaltungseinheit nach einer der 2 bis 8 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.

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 5. Da als bedingte Transaktion in 7 zudem, wie in 5, eine Sende-Transaktion betrachtet wird, entsprechen die späteren Schritte 720 bis 728 den bekannten Schritten 520 bis 528 respektive. Es wird auf solche bereits beschriebenen Schritte nur verkürzt eingegangen.

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

Ebenfalls analog erfolgt eine Ablehnung 705 der Anforderung 701 falls beim Prüfen 704 der Vorgabe(n) des Münzdepots festgestellt wird, dass für das Münzdepot die Transaktion nicht zulässig ist.

Im Schritt des Prüfens 704 wird als funktionelle Vorgabe nun (zumindest auch) eine Vorgabe für bedingte Transaktionen geprüft, nur beispielsweise ob die Art der Bedingung zulässig ist. Neben der Vorgabe für bedingte Transaktionen 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. Eine oder mehrere Vorgaben für bedingte Transaktionen können also ergänzend zu den generellen Vorgaben (für einfache Transaktionen) zu prüfen sein. Die Vorgaben für bedingte Transaktionen können jedoch auch Richtungsvorgaben für bedingte Transaktionen und/oder Betragsvorgaben für bedingte Transaktionen umfassen.

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 5 erfolgen.

Eine bedingte Transaktion wird zunächst (zwischen)gespeichert 710. Sie wird also noch nicht ausgeführt, sondern erst später ausgeführt, wenn die in der Transaktion enthaltene Bedingung erfüllt ist. Wie in 4 dargestellt, kann das Zwischenspeichern in einen Zwischenspeicher für bedingte Transaktionen 426 des Münzdepots 330 oder in einen münzdepotübergreifenden Zwischenspeicher 36 für bedingte Transaktionen erfolgen. Anzumerken ist, dass der dargestellte Ablauf, erst Prüfen 703 bis 705 dann Zwischenspeichern 710, gewährleistet, dass 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 Zwischenspeichern 710 kann wiederum ein Verschlüsseln der Münzdepotdaten, wie zuvor beschrieben, umfassen. Die Münzdepotdaten haben sich sich beispielsweise geändert, wenn der Zwischenspeicher 426 des Münzdepots genutzt wird. Ebenso kann mit den optionalen Schritten 707 bis 709 kann 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 Zwischenspeicher 426 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 zwischengespeicherten 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 in 7 ist angedeutet, dass die weiteren Schritte 712 bis 728 erst zu einem späteren Zeitpunkt folgen. Die Bearbeitung der Transaktionsanfrage 701 für eine bedingte Transaktion ist abgeschlossen.

Die Ausführung der bedingten Transaktion erfolgt nur falls und/oder erst wenn die Bedingung erfüllt ist. In 7 dargestellt ist ein Schritt des Prüfens der Bedingung 713, welcher beispielsweise in regelmäßigen zeitlichen Abständen ausgeführt wird oder in Antwort auf den Empfang eines Prüf-Auslösers 712 ausgeführt wird.

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).

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ätigen der Transaktion 726 und des Registrieren der Transaktion im Transaktionsregister 727, 728 sind bereits zu 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.

Bisher wurde zu 7 beschrieben und betrachtet, dass die bedingte Transaktion zwischengespeichert und dann so wie zwischengespeichert ausgeführt wird. Es ist eine modifizierte Verwendung einer bedingten Transaktion denkbar, in welcher die bedingte Transaktion gespeichert wird, die der Transaktions-Anfrage des Benutzers entspricht. Ein von einem Dritten (bzw. dessen Münzverwaltungseinheit) angeforderte Transaktion wird ausgeführt, wenn sie die gespeicherte bedingte Transaktion erfüllt. Die gespeicherte bedingte Transaktion ist ein Freigaberahmen des Benutzers für Transaktionen des Dritten, der bevorzugt als Empfänger in der bedingten Transaktion genannt ist. Die Münzverwaltungseinheit des Dritten kann nun aber nicht nur exakt die gespeicherte bedingte Transaktion anfordern (als Auslöser), sondern beispielsweise ebenfalls eine Transaktion mit einem geringeren Sende-Transaktionsbetrag als in der gespeicherten Transaktionsbetragsschwelle. Somit kann auch die Sende-Transaktionsanforderung eines Dritten ausgeführt werden, wenn zuvor eine passende bedingte Transaktion durch den Benutzer gespeichert wurde.

Am Beispiel von 8 werden verschiedene Vorgaben in einer Münzverwaltungseinheit, wiederum nur am Beispiel eines Münzdepotdatensatzes anstelle am Beispiel der korrespondierenden Datenelemente der Münzverwaltungseinheit, beschrieben. Diese kann grundsätzlich und mit unterschiedlichem Inhalt in jedem der diskutierten Münzverwaltungseinheiten (ggf. mit Münzdepot) vorliegen könnte.

Als Datenelemente eines Münzdepotdatensatzes 800 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 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 3 sind in 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 umfasst zudem auch Betragsvorgaben 813, 838, 828. Gerade Betrags- und Richtungsvorgaben können - wie teilweise zuvor beschrieben - jedoch jeweils auch Teil der Vorgaben für bedingte Transaktionen oder Gegenleistungsvorgaben sein.

Die Herausgeber-Vorgaben 810 hat der Herausgeber zum Zeitpunkt der Erstellung des Münzdepots vorab festgelegt. Die Benutzer-Vorgaben 820 sind vom Benutzer gewählt, jedoch enger gewählt als die gleichartigen Herausgeber-Vorgaben 810 bzw. genauer als Erhöhung der Herausgebervorgaben 810 gewählt.

Der Herausgeber ist im Beispiel Inhaber eines Geschäftes. Er beschränkt das von ihm für den Benutzer erstellte Münzdepot, 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 nur an das fest vorgegebene Geschäft senden. Der Benutzer darf diese Vorgabe in dem Beispiel nicht weiter beschränken, deshalb wird ihm nicht angeboten eine Sende-Vorgabe des Benutzers 826 zu wählen. Dies wird in der Figur 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 erhöhte Benutzer-Empfangsvorgabe 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 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 hat der Herausgeber zudem Betragsvorgaben 813, 818 fest vorgegeben. Das Münzdepot 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“).

Der Benutzer kann nun also beispielsweise zunächst 50 dW von einer anderen Münzverwaltungseinheit an das Münzdepot senden. In dem Münzdepot liegt dann insgesamt ein Depotbetrag von 85 dW vor. An das angegebene Geschäft könnte er nun den ganzen Depotbetrag in einer einzigen Transaktion senden (in einem neuen Münzdatensatz mit 85 dW oder mit den drei vorhandenen Münzdatensätzen). Er kann aber ebenfalls eine bedingte Sende-Transaktion anlegen, die eine zeitliche Bedingung verwendet, sofern der Empfänger das Geschäft ist. Der Benutzer könnte beispielsweise eine bedingte Sende-Transaktion anfordern, welche alle zwei Wochen 20 dW an die Münzverwaltungseinheit des Geschäftes sendet. Die angeforderte Transaktion wird - wie zu 7 beschrieben - geprüft, zwischengespeichert und dann alle zwei Wochen ausgeführt. Das Geschäft liefert dem Benutzer dann alle zwei Wochen eine - vorab oder in einem Transaktionsbezugstext angegebene - Gegenleistung (je nach Geschäft: Gemüsekiste, frischer Kaffee oder Rasen mähen). Die Gegenleistung kann jedoch fallweise auch in digitaler Form, insbesondere in einer E-Mail, SMS oder einer Antwort auf die Transaktionsnachricht gesendet werden (im Beispiel: 2 Wochen gültiger Zugangscode für Fitness-Studio).

Die Kodierung der Vorgaben 811-828 ist zur besseren Lesbarkeit in der Figur 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 der Münzverwaltungseinheit bzw. Münzdepots als TLV-Struktur (Tag, Length, Value) ist ebenso denkbar wie eine Kodierung des Münzdepots in einem JSON-Format. 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 437-439 oder 429, 426 aus 3.

Im 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ünzdepot-Verwaltungseinheit

390

Münzverwaltungseinheit

31,391

Ausführungseinheit

310, 320, 330

Münzdepot

313, 323, 333, 393

Empfangsvorgabe

312, 322, 332, 392

Sendevorgabe

315, 325, 335, 395

Münzdatensätze

32

Münzdepot-Erstellungseinheit

33

Benutzervorgaben-Einheit

36

Bedingte Transaktions-Anforderungsdatensätze

38

Schlüsselverwaltungsmodul

39

Gegenleistungseinheit

40

Benutzer-Einheit

50

Herausgeber-Einheit

401

Transaktions-Anforderung

402

Münzdepot-Anforderung

403

Konfigurations-Anforderung

405

Sende-Transaktion

410, 420, 430

Münzdepot

416

Vorgabe für bedingte Transaktionen

419

Vorgabe für Gegenleistungen

426

Bedingte Transaktions-Anforderungsdatensätze

429

Gegenleistungsdaten

433

Benutzer-Vorgaben

434

Herausgeber-Vorgaben

437

Identifikator

438

Schlüssel

439

Zertifikat

501

Transaktions-Anforderung

502

Lesen der Münzdepotdaten

503

Prüfen der Benutzer-Authentisierung

504

Prüfen der funktionellen Vorgabe

505

Ablehnung der Anforderung

506

Prüfen des Depotbetrages

507

Erstellen und registrieren eines Münzdatensatzes

508,522

Registrierungsanforderung

509, 523

Registrierungsbestätigung

520

Erstellen der Transaktion

521

Senden der Transaktion

524, 526

Transaktionsbestätigung

525

Schreiben der Münzdepotdaten

527

Erstellen des Transaktions-Registerdatensatzes

528

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ünzdepotanforderung

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

Lesen der Münzdepotdaten

703

Prüfen der Benutzer-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

Zwischenspeichern der bedingten Transaktion

711

Schreibe Münzdepotdaten

712

Prüf-Auslöser

713

Prüfen der Bedingung der Transaktion

720

Erstelle Transaktion

721

Transaktion (mit Münzdatensatz)

722

Registrierungsanforderung für modifizierten Münzdatensatz

723

Registrierungsbestätigung

724, 726

Transaktionsbestätigung

725

Schreiben der Münzdepotdaten

727

Erstellen Transaktions-Registerdatensatz

728

Transaktions-Registrierung

805

Münzdatensätze des Münzdepots

809

Herausgeber-Daten

810

Herausgeber-Vorgaben

820

Herausgeber-Einstellungen

811, 821

Sender-Beschränkung

812, 822

Empfangsvorgabe für bedingte Transaktionen

813, 823

Betragsgrenze Empfang

814

Empfangsvorgabe für Gegenlseistungen

816,826

Empfänger-Beschränkung

817, 827

Sendevorgabe für bedingte Transaktionen

818, 828

Betragsgrenze Senden

819

Sendevorgabe für Gegenleistungen

ZITATE ENTHALTEN IN DER BESCHREIBUNG

Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.

Zitierte Patentliteratur

• WO 2020212331 A1 [0006, 0007, 0078]

Claims (27)

1. Münzverwaltungseinheit, umfassend - eine sichere Ausführungseinheit (31; 391) zur Verwaltung von digitalen Münzdatensätzen, wobei die sichere Ausführungseinheit (31; 391) angepasst ist in Transaktionen digitale Münzdatensätze mit anderen Münzverwaltungseinheiten auszutauschen und Registrierungsanforderungen an ein Münzregister (20) zu senden; und - zumindest einen digitalen Münzdatensatz (305; 395; 435); wobei die sichere Ausführungseinheit (31) weiter angepasst ist eine erste Vorgabe und/oder eine zweite Vorgabe zu prüfen; dadurch gekennzeichnet, dass die erste Vorgabe (333; 393; 433) und die zweite Vorgabe (334; 394; 434) in der Münzverwaltungseinheit als Vorgabedatenelemente gespeichert sind; und die erste Vorgabe (333; 393; 433) und die zweite Vorgabe (334; 394; 434) das gleiche Prüfkriterium betreffen, wobei die zweite Vorgabe (434) eine Erhöhung der ersten Vorgabe (433) ist und/oder die zweite Vorgabe (334; 394) für eine andere Austauschrichtung zu prüfen ist als die erste Vorgabe (333; 393).
2. Münzverwaltungseinheit nach Anspruch 1, dadurch gekennzeichnet, dass die zweite Vorgabe (434) von einem Benutzer als eine Erhöhung der ersten Vorgabe (433) wählbar ist; wobei vorzugsweise die erste Vorgabe (433) von einem Herausgeber der Münzverwaltungseinheit vorab festgelegt ist.
3. Münzverwaltungseinheit nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass die erste Vorgabe eine Empfangs-Vorgabe (333; 393) und die zweite Vorgabe eine Sende-Vorgabe (334; 394) ist.
4. Münzverwaltungseinheit nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass - die sichere Ausführungseinheit (31) für die Transaktion mehrere, insbesondere erste und/oder zweite, Vorgaben prüft; und/oder - die sichere Ausführungseinheit (31) die erste und die zweite Vorgabe nacheinander prüft oder nur die zweite Vorgabe prüft, welche die erste Vorgabe umfasst; und/oder - mindestens ein Vorgabenquadrupel das Prüfkriterium betrifft, umfassend eine erste Empfangs-Vorgabe und eine zweite erhöhte Empfangs-Vorgabe sowie eine erste Sende-Vorgabe und eine erhöhte zweite Sende-Vorgabe.
5. Münzverwaltungseinheit nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass die zweite erhöhte Vorgabe umfasst: - einen gegenüber der ersten Vorgabe prüfungsbezogen erhöhten Zahlenwert, - mindestens einen zusätzlichen nicht-zulässigen Vergleichswert, oder - eine Auswahl oder Beschränkung der zulässigen Vergleichswerte.
6. Münzverwaltungseinheit nach einem der Ansprüche 3 bis 5, dadurch gekennzeichnet, dass - die Sende-Vorgabe sich von der Empfangsvorgabe unterscheidet; und/oder - die Sende-Vorgabe das Senden von Münzdatensätzen vollständig beschränkt oder teilweise beschränkt auf genau einen Empfänger, genau eine Empfängergruppe oder auf mehrere Empfänger und/oder Empfängergruppen; und/oder - die Empfangsvorgabe das Empfangen von Münzdatensätzen vollständig beschränkt oder teilweise beschränkt auf genau einen Sender, genau eine Sendergruppe oder mehrere Sender und/oder Sendergruppen; und/oder - das Prüfkriterium der Transaktionspartner der Transaktion ist, insbesondere in seiner Rolle als Sender oder Empfänger von Münzdatensätzen.
7. Münzverwaltungseinheit nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, dass die erste und die zweite Vorgabe Vorgaben für bedingte Transaktionen sind, wobei vorzugsweise Vorgaben für bedingte Transaktionen eine Art der Bedingung und/oder eine Art der bedingten Transaktion enthalten, welche für die Münzverwaltungseinheit zulässig ist.
8. Münzverwaltungseinheit nach Anspruch 7, dadurch gekennzeichnet, dass - die sichere Ausführungseinheit (31) eine bedingte Transaktion speichert, wenn die Vorgaben für bedingte Transaktionen erfüllt sind; und/oder - die sichere Ausführungseinheit (31) eine bedingte, insbesondere gespeicherte, Transaktion erst ausführt, wenn eine Bedingung erfüllt ist, insbesondere eine weitere Transaktions-Anfrage für eine Transaktion empfangen wird, welche unter die gespeicherte bedingte Transaktion fällt; und/oder - eine bedingte Transaktion eine zeitliche Bedingung, ein externes Auslöse-Ereignis als Bedingung und/oder einen Sicherungswert als Bedingung umfasst.
9. Münzverwaltungseinheit nach einem der Ansprüche 1 bis 8, dadurch gekennzeichnet, dass die erste und die zweite Vorgabe oder eine weitere Vorgabe eine Betragsvorgabe ist, insbesondere: - ein Maximalwert für den Betrag der zu sendenden und/oder für den Betrag der zu empfangenden Münzdatensätze, oder - einen Maximalwert oder einen Minimalwert für einen Gesamtbetrag in der Münzverwaltungseinheit gespeicherter Münzdatensätze, oder - ein Maximalwert für eine Summe von Transaktionsbeträgen innerhalb eines Zeitraums ausgeführter Transaktionen.
10. Münzverwaltungseinheit nach einem der Ansprüche 1 bis 9, dadurch gekennzeichnet, dass ferner eines oder mehrere der folgenden Datenelemente gespeichert sind: - ein eindeutiger Münzverwaltungseinheits-Identifikator; und/oder - ein öffentlicher Münzverwaltungseinheits-Schlüssel eines asymmetrischen Schlüsselpaares; optional ein geheimer Münzverwaltungseinheits-Schlüssel des asymmetrischen Schlüsselpaares; und/oder - ein Münzverwaltungseinheits-Zertifikat, welches insbesondere den Münzdepot-Identifikator und/oder den öffentlichen Münzdepot-Schlüssel als zertifizierte Inhalte umfasst.
11. Münzverwaltungseinheit nach einem der Ansprüche 1 bis 10, dadurch gekennzeichnet, dass mindestens eine Vorgabe teilweise frei auslesbar gespeichert ist, insbesondere die erste bzw. zweite Vorgabe; wobei insbesondere ein auslesbarer Anteil und ein nicht auslesbarer Anteil der mindestens teilweise frei auslesbaren Vorgabe vorliegt; und wobei die beiden Anteile vorzugsweise - in unterschiedlichen Datenelementen gespeichert sind, oder - in einem gemeinsamen Datenelement nicht auslesbar gespeichert sind und zusätzlich der auslesbare Anteil in einem separaten frei auslesbaren Datenelement gespeichert ist.
12. Münzverwaltungseinheit nach einem der Ansprüche 1 bis 11, dadurch gekennzeichnet, dass die erste und/oder die zweite Vorgabe eine Gegenleistungs-Vorgabe ist, wobei vorzugsweise die Gegenleistung in Antwort auf mindestens einen empfangenen Münzdatensatz als Leistung, insbesondere in den Antwortdaten an den Sender des empfangenen Münzdatensatzes, bereitgestellt wird.
13. Münzverwaltungseinheit nach einem der Ansprüche 1 bis 12, dadurch gekennzeichnet, dass, dass die sichere Ausführungseinheit zur Verwaltung der Münzdatensätze - 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.
14. Münzverwaltungseinheit nach einem der Ansprüche 1 bis 13, dadurch gekennzeichnet, dass die Münzverwaltungseinheit - eine lokale Münzverwaltungseinheit ist, oder - eine serverbasierte Münzverwaltungseinheit ist, die entweder für den Benutzer der Münzverwaltungseinheit eine eigene sichere Ausführungseinheit umfasst oder für mehrere Benutzer, in einer Münzdepot-Verwaltungseinheit mit Münzdepots der Benutzer, eine gemeinsame sicheren Ausführungseinheit umfasst.
15. Münzverwaltungseinheit nach einem der Ansprüche 1 bis 14, dadurch gekennzeichnet, dass die sichere Ausführungseinheit zur Verwaltung der Münzdatensätze in einer Transaktion mit einer weiteren Münzverwaltungseinheit, ein empfangenes Datenelement der weiteren Münzverwaltungseinheit auswertet, wobei das weitere Datenelemente eine Vorgabe der weiteren Münzverwaltungseinheit vollständig oder anteilig umfasst und die sichere Ausführungseinheit für die Transaktion die Vorgabe der weiteren Münzverwaltungseinheit prüft.
16. Verfahren zur Ausgabe einer neuen Münzverwaltungseinheit, die eine sichere Ausführungseinheit (31) zur Verwaltung von digitalen Münzdatensätzen umfasst, für einen Benutzer, mit den Schritten: - Empfangen einer Anfrage (601) zur Erstellung der neuen Münzverwaltungseinheit; - Bereitstellen der neuen Münzverwaltungseinheit mit gespeicherten Datenelementen, wobei eine sichere Ausführungseinheit (31) eingerichtet ist erste und/oder zweite Vorgaben zu prüfen; dadurch gekennzeichnet, dass die Anfrage zumindest die erste Vorgabe (322; 332) umfasst, die im Schritt des Bereitstellens gespeicherten Datenelemente die erste Vorgabe (322; 332) als Vorgabedatenelement umfassen, die erste Vorgabe (322; 332) eine für den Benutzer festgelegte Herausgeber-Vorgabe ist, und eine zweite, als Datenelement speicherbare, Vorgabe für das gleiche Prüfkriterium vorgesehen wird, wobei die zweite Vorgabe entweder für eine andere Austauschrichtung zu prüfen ist als die erste Vorgabe oder nach dem Schritt des Bereitstellens vom Benutzer als Erhöhung der ersten Vorgabe wählbar ist.
17. Verfahren nach Anspruch 16, dadurch gekennzeichnet, dass weiterhin einer oder mehrere der folgenden Schritte ausgeführt wird: - Prüfen (602) einer in der Anfrage enthaltenen Authentisierung; - Erzeugen (604) eines Münzverwaltungseinheits-Identifikators, welche insbesondere einen Anteil einer Vorgabe, vorzugsweise der ersten Vorgabe umfasst; - Erzeugen (605) eines Münzverwaltungseinheits-Schlüssels; - Bereitstellen (606) eines Münzverwaltungseinheits-Zertifikats, welches insbesondere einen Anteil einer Vorgabe oder einen weiteren Anteil der Vorgabe, vorzugsweise der ersten Vorgabe umfasst.
18. Verfahren nach Anspruch 16 oder 17, dadurch gekennzeichnet, dass die gespeicherten Datenelemente mindestens einen Münzdatensatz umfassen; wobei vorzugsweise die sichere Ausführungseinheit (31) zur Verwaltung von digitalen Münzdatensätzen - einen Münzdatensatz für die neue Münzverwaltungseinheit empfängt und/oder - eine Registrierungsanforderung an ein Münzregister (20) der Zentralbank sendet, welche insbesondere für einen empfangenen bisher registrierten Münzdatensatz die Registrierung eines in der neuen Münzverwaltungseinheit zu speichernden Münzdatensatzes anfordert.
19. Verfahren nach einem der Ansprüche 16 bis 18, dadurch gekennzeichnet, dass - die Anfrage (601) einen Benutzer umfasst, für welchen die neue Münzverwaltungseinheit erstellt wird; oder - die neue Münzverwaltungseinheit ohne Benutzer-Zuordnung erstellt wird, und eine Zuordnung des erstellten neuen Münzdepots zu einem Benutzer in Antwort auf eine Zuordnungsanforderung (613) erfolgt.
20. Verfahren nach einem der Ansprüche 16 bis 19, dadurch gekennzeichnet, dass die Münzverwaltungseinheit eine serverbasierte Münzverwaltungseinheit ist, die entweder für den Benutzer der Münzverwaltungseinheit eine eigene sichere Ausführungseinheit umfasst oder für mehrere Benutzer, in einer Münzdepot-Verwaltungseinheit mit Münzdepots der mehreren Benutzer, eine gemeinsame sichere Ausführungseinheit umfasst.
21. Verfahren zur Verwaltung von Münzdatensätzen in einer Münzverwaltungseinheit, die eine sichere Ausführungseinheit (31) und zumindest einen Münzdatensatz umfasst, mit den Schritten: - Empfangen einer Transaktions-Anfrage (501; 701); - Lesen (502; 702) von in der Münzverwaltungs-Einheit gespeicherten Datenelementen; - Prüfen (504; 704) einer ersten Vorgabe und/oder einer zweiten Vorgabe; - Ausführen (520-528) einer Transaktion oder Speichern (710) einer bedingten Transaktion, die der Transaktions-Anfrage (501; 701) entspricht; dadurch gekennzeichnet, dass die erste Vorgabe und die zweite Vorgabe in der Münzverwaltungseinheit als Vorgabedatenelemente gespeichert sind; in dem Schritt des Lesens (502; 702) die erste Vorgabe und/oder die zweite Vorgabe gelesen werden; und die erste Vorgabe und die zweite Vorgabe das gleiche Prüfkriterium betreffen, wobei die erste Vorgabe eine Herausgeber-Vorgabe (433) und die zweite Vorgabe eine Benutzer-Vorgabe (434) ist und/oder die erste Vorgabe eine Empfangs-Vorgabe (333; 393) und die zweite Vorgabe eine Sende-Vorgabe (334; 394) ist.
22. Verfahren nach Anspruch 21, dadurch gekennzeichnet, dass - die Herausgeber-Vorgabe (433) und die Benutzer-Vorgabe (434) Richtungsvorgaben sind; und/oder - die erste Vorgabe und die zweite Vorgabe Vorgaben für bedingte Transaktionen sind, und/ oder - die erste Vorgabe und die zweite Vorgabe Gegenleistungs-Vorgaben sind; und/oder - die erste Vorgabe und die zweite Vorgabe Betrags-Vorgaben sind.
23. Verfahren nach Anspruch 21 oder 22, dadurch gekennzeichnet, dass in dem Schritt des Prüfens für die Transaktion - ein Datenelement der Transaktions-Anfrage, insbesondere ein Transaktionsbetrag oder ein Transaktionspartner, und/oder ein Datenelement der Münzverwaltungseinheit mit der Vorgabe verglichen wird; und/oder - abhängig von der Austauschrichtung der Transaktion die Sende-Vorgabe und/oder die Empfang-Vorgabe geprüft wird; und/oder - nur die Benutzer-Vorgabe (434), welche enger ist als die Herausgeber-Vorgabe (433), geprüft wird oder die Benutzer-Vorgabe (434) und die Herausgeber-Vorgabe (433) geprüft werden; und/oder - abhängig von der angeforderten Transaktion unterschiedliche Vorgaben, insbesondere mehrere Vorgaben für unterschiedliche Datenelemente der Transaktion oder der Münzverwaltungseinheit, geprüft werden.
24. Verfahren nach einem der Ansprüche 21 bis 23, dadurch gekennzeichnet, dass die Transaktions-Anfrage vom Benutzer empfangen wird und die bedingte Transaktion als vom Benutzer freigegebene bedingte Transaktion gespeichert wird; und/oder die bedingte Transaktion beim Speichern nur zwischengespeichert wird und ausgeführt wird, wenn eine auslösende Bedingung erfüllt ist, oder beim Speichern als Freigaberahmen des Benutzers für spätere Transaktions-Anfragen eines Dritten, der insbesondere als Empfänger in der bedingten Transaktion genannt ist, gespeichert wird; und/oder die Transaktions-Anfrage oder eine weitere Transaktions-Anfrage von einem Dritten eine auslösende Bedingung für eine gespeicherte bedingte Transaktion ist, wobei insbesondere entweder die zwischengespeicherte bedingte Transaktion ausgeführt wird oder eine vom Dritten angeforderte Transaktion ausgeführt wird, welche unter die vom Benutzer freigegebene, gespeicherte bedingte Transaktion fällt.
25. Verfahren nach einem der Ansprüche 21 bis 24, dadurch gekennzeichnet, dass das Ausführen der Transaktion, insbesondere der angeforderten oder der bedingten Transaktion, umfasst: ein Senden oder ein Empfangen eines Münzdatensatzes der Zentralbank, und/oder ein Senden einer Registrierungsanforderung an ein Münzregister (20) 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.
26. Verfahren nach einem der Ansprüche 16 bis 25, dadurch gekennzeichnet, dass die Münzverwaltungseinheit nach einem der Ansprüche 1 bis 15 ausgestaltet ist; und/oder wobei nach einem Verfahren gemäß einem der Ansprüche 16 bis 20 die Schritte des Verfahrens nach Anspruch 21 bis 25 ausgeführt werden.
27. Digitales Währungs-System, umfassend: eine Vielzahl von Münzverwaltungseinheiten, die nach einem der Ansprüche 1 bis 15 ausgestaltet oder zur Ausführung eines Verfahrens nach einem der Ansprüche 16 bis 26 eingerichtet sind, das Münzregister sowie optional eine Mehrzahl von Münzdepot-Verwaltungseinheiten und/ oder ein Transaktionsregister.

Images