DE102018009949A1

DE102018009949A1 - Übertragungsverfahren zum flexiblen Übertragen von spezifisch teilbaren elektronischen Münzdatensätzen

Info

Publication number: DE102018009949A1
Application number: DE102018009949.1A
Authority: DE
Inventors: Florian Gawlas; Tilo Fritzhanns
Original assignee: Giesecke and Devrient GmbH
Current assignee: Giesecke and Devrient Advance52 GmbH
Priority date: 2018-12-18
Filing date: 2018-12-18
Publication date: 2020-06-18

Abstract

Die Erfindung betrifft ein Übertragungsverfahren zum flexiblen Übertragen von spezifisch teilbaren elektronischen Münzdatensätzen, STC, zwischen zumindest zwei Teilnehmern in einer de-zentral geführten Bezahltransaktionsdatenbank, DLT, - Infrastruktur, wobei jedem Teilnehmer ein Konto in der DLT-Infrastruktur eindeutig zugeordnet ist und jedes Konto eingerichtet zum Verarbeiten eines STC ist, mit den Schritten: Senden eines Kommandos von einem ersten Teilnehmer unter Verwendung eines ersten Endgeräts an einen zweiten Teilnehmer, wobei unmittelbar vor dem Senden ein Element eines ersten STC auf dem Konto eines Teilnehmers in der DLT-Infrastruktur deaktiviert wird; und Empfangen des Kommandos beim zweiten Teilnehmer unter Verwendung eines zweiten Endgerätes, wobei unmittelbar nach dem Empfangen ein Element eines zweiten STC auf dem Konto des zweiten Teilnehmers in der DLT-Infrastruktur aktiviert wird. Die Erfindung betrifft zudem zum flexiblen Übertragen von spezifisch teilbaren elektronischen Münzdatensätzen, STC, zwischen zumindest zwei Teilnehmern, wobei das Bezahlsystem.

Description

TECHNISCHES GEBIET DER ERFINDUNG
Die Erfindung betrifft ein Übertragungsverfahren zum Übertragen eines spezifisch teilbaren elektronischen Münzdatensatzes, STC, zwischen zumindest zwei Teilnehmern in einer Bezahltransaktionsdatenbank, DLT, -Infrastruktur, wobei die DLT-Infrastruktur bevorzugt dezentral geführt ist. Dazu betrifft die Erfindung ein Bezahlsystem zum Übertragen eines STC zwischen zumindest zwei Teilnehmern.
TECHNISCHER HINTERGRUND DER ERFINDUNG
In der Blockchain-Technologie sind Blockchains, deutsch: Blockketten, fälschungssichere, verteilte Datenstrukturen, in denen Transaktionen in der Zeitfolge protokolliert, nachvollziehbar, unveränderlich und ohne zentrale Instanz abgebildet sind. Mit der Blockchain-Technologie lassen sich Eigentumsverhältnisse direkter und effizienter als bislang sichern und regeln, da eine lückenlose und unveränderliche Datenaufzeichnung hierfür die Grundlage schafft.
Über Blockchain-Technologie lassen sich beispielsweise neuartige Zahlungsmittel, also virtuelle Währung, digitale Währung, alternative Währung oder Kryptowährung, wie Bitcoin, Litecoin, Ripple, Ethereum oder ERC-Token, nachfolgend als virtuelle Währung, VC, bezeichnet, darstellen.
VC ist eine digitale Abbildung eines geldwerten Betrags, der nicht von einer Zentralbank oder Behörde geschaffen wird und auch keine Verbindung zu gesetzlichen Zahlungsmitteln haben muss. VC werden von natürlichen und juristischen Personen als Tauschmittel verwendet und können elektronisch übertragen, verwahrt oder gehandelt werden. Eine VC-Einheit wird auch als elektronischer Münzdatensatz bezeichnet.
Neben VC sind auch sogenannte „Smart Contracts“ über die Blockchain-Technologie realisierbar. Diese ermöglichen die Abbildung einer vertraglichen Logik durch Computeralgorithmen. Es handelt sich um programmierbare Verträge, die durch den Programmcode definiert werden und dann automatisch auf Blockchains ausgeführt und durchgesetzt werden können. Zu bestimmten Zeitpunkten überprüfen Smart Contracts automatisch zuvor festgelegte Bedingungen. Sie bestimmen also automatisch, ob z.B. eine Transaktion ausgeführt oder rückabgewickelt wird. Das Ziel ist eine Reduktion von Transaktionskosten und eine Erhöhung der Vertragssicherheit. Nur der Programmcode eines Smart Contracts entfaltet vertragliche Wirkung. Smart Contracts stellen eine Kontroll- oder Geschäftsregel innerhalb des technischen Protokolls dar. Beispielsweise könnte ein per Smart Contract geleasten Kraftfahrzeug nur dann gestartet werden, wenn eine fällige Leasingrate auf dem Konto des Leasinggebers eingegangen ist. Hierzu würde eine Abfrage der Blockchain genügen.
Die VC oder Smart Contracts an den jeweiligen Endgeräten (Nodes) und alle bisherigen Transaktionen sind in einer zentralen Datei, der Blockchain, öffentlich einsehbar. Anhand der Endgeräte ist in der DLT-Infrastruktur jedoch nicht erkennbar, welcher Teilnehmer tatsächlich der Inhaber der VC oder des Smart Contracts ist. Eine getätigte Transaktion ist grundsätzlich irreversibel. Neben der Übertragung von VC oder Smart Contracts innerhalb der DLT-Infrastruktur ist es auch möglich, Stellen und Schlüssel physisch zwischen Teilnehmern zu übertragen, indem diese etwa auf Datenträgern weitergegeben werden.
Problematisch bei der Blockchain-Technologie ist es, dass die VC oder der Smart Contracts keine individuellen Datensätze sind und stets nur als Ganzes übertragen werden können.
Es ist somit Aufgabe der vorliegenden Erfindung, ein Verfahren und ein System zu schaffen, in welchem eine Blockchain-Technologie flexible Datensätze anbietet, die individuell (spezifisch) behandelt werden können. Dabei soll insbesondere ein direkter Austausch zwischen Teilnehmern bzw. den entsprechenden Endgeräten geschaffen werden, der unkompliziert und schnell ist. Das dazu notwendige Übertragen von geldwerten Beträgen in elektronischer Form zwischen den Endgeräten soll fälschungssicher und vertrauenswürdig sein und bestehende Infrastrukturen sollen weitestgehend genutzt werden.
ZUSAMMENFASSUNG DER ERFINDUNG
Die gestellte Aufgabe wird mit den Merkmalen der unabhängigen Patentansprüche gelöst. Weitere vorteilhafte Ausgestaltungen sind in den jeweils abhängigen Patentansprüchen beschrieben.
Die Aufgabe wird insbesondere durch ein Verfahren zum Übertragen eines spezifisch teilbaren elektronischen Münzdatensatzes, STC, zwischen zumindest zwei Teilnehmern in einer Bezahltransaktionsdatenbank, DLT, -Infrastruktur gelöst, wobei jedem Teilnehmer ein Konto in der DLT-Infrastruktur eindeutig zugeordnet ist. Das Verfahren umfasst dabei die Schritte: Senden eines Kommandos von einem ersten Teilnehmer unter Verwendung eines ersten Endgeräts an einen zweiten Teilnehmer, wobei unmittelbar vor dem Senden ein Element eines ersten STC auf einem Konto eines Teilnehmers in der DLT-Infrastruktur deaktiviert wird; und Empfangen des Kommandos beim zweiten Teilnehmer unter Verwendung eines zweiten Endgerätes, wobei unmittelbar nach dem Empfangen ein Element eines zweiten STC auf einem Konto des zweiten Teilnehmers in der DLT-Infrastruktur aktiviert wird.
Jeder Teilnehmer an dem Verfahren betreibt bevorzugt eine lokale Applikation auf einem Endgerät, englisch: Node, mittels derer sie an einem Netzwerk teilnehmen. Dazu muss das Endgerät die entsprechende Leistungsfähigkeit aufweisen, insbesondere zum kryptografisch gesicherten Kommunizieren mit anderen Endgeräten der DLT-Infrastruktur. Das Netzwerk funktioniert als „Peer-to-Peer“, bei dem sich alle Teilnehmer grundsätzlich gleichberechtigt gegenüberstehen. Es gibt keine zentrale Instanz, die Transaktionen bzw. Guthaben kontrolliert oder verwaltet. Das Netzwerk wird daher als dezentral geführte Transaktionsdatenbank oder auch dezentral geführte Kontobuchführung bezeichnet, englisch: Distributed Ledger Technology, kurz DLT. Das Netzwerk wird hier als DLT-Infrastruktur bezeichnet.
Die DLT-Infrastruktur ist dabei bereits etabliert und ist beispielsweise Ethereum. Ethereum bietet das Anlegen, Verwalten und Ausführen von dezentralen Programmen bzw. Kontrakten (Smart Contracts) in Blockchains an und stellt einen Gegenentwurf zur klassischen Client-Server-Architektur dar. Ethereum verwendet als VC-Einheit Ether (abgekürzt mit ETH) als Zahlungsmittel für Transaktionsverarbeitungen, welche durch teilnehmende Endgeräte abgewickelt werden. Ethereum ist keine reine VC, sondern auch eine Plattform für Distributed Apps (Dapps), die aus Smart Contracts bestehen. Für Smart Contracts gibt es eine Vielzahl von Anwendungen, unter anderem E-Voting-Systeme, virtuelle Organisationen, Identitätsmanagement und Crowdfunding, die nachfolgend als Dienst bezeichnet werden.
Es werden erfindungsgemäß neuartige STCs eingeführt, also VC-Einheiten, die für spezifische Zwecke aufgeteilt werden können. Ein Element des STC ist ein Teil des STC. Dies STC werden auch als Token bezeichnet. Ein Token ist dabei eine VC-Einheit oder ein Smart Contract, also eine Wenn-Dann-Beziehung, die regelt unter welchen Bedingungen ein geldwerter Betrag von einem Konto eines Teilnehmers auf ein Konto eines anderen Teilnehmers verschoben werden kann.
Die STCs sind identifizierbaren Stellen, nachfolgend als Adressen bezeichnet, zugeordnet. Diese Adressen sind in der DLT-Infrastruktur eindeutig. Diese Adressen bestehen in der Regel aus willkürlich generierten Ziffern- bzw. Zahlenfolgen. Die DLT-Infrastruktur verwaltet jeweilige Inhaber mit privaten und öffentlichen Schlüsselpaaren zur Authentifizierung von Transaktionen. Alle Nutzer können ihre VC untereinander innerhalb der DLT-Infrastruktur übertragen, die jeweiligen Zieladressen müssen sie sich ggf. außerhalb der DLT-Infrastruktur mitteilen.
Das Element kann beispielsweise von einem Konto eines (dritten) Teilnehmers deaktiviert, das Kommando ist dann ein „Übertrage-von“, englisch „Transferfrom“ Kommando. Dieses Kommando ermöglicht das Senden zumindest eines Elements eines STC von einer Adresse zu einer anderen Adresse, wobei keine der Adressen mit der Adresse des das Kommando aussendenden Teilnehmers entsprechen muss.
Der STC kann dabei spezifisch verwendbar sein und ist entsprechend der Anforderungen in seine Elemente teilbar. Dazu kann der STC bevorzugt für einen angeforderten Dienst geteilt werden. Der Begriff Dienst (auch Service oder Daemon) beschreibt hierbei allgemein eine technische, autarke Einheit, die zusammenhängende Funktionalitäten zu einem Themenkomplex bündelt und über eine klar definierte Schnittstelle zur Verfügung stellt. Typische Beispiele sind Webservices, die Funktionalitäten für Dritte über das Inter- bzw. Intranet verfügbar machen, Netzwerkdienste, Systemdienste oder auch Telekommunikationsdienste.
Netzwerkdienste werden von Service-Anbietern als Teilnehmern angeboten, um auf Ressourcen zuzugreifen, insbesondere Authentifikation, Identifikation, Verifikation aber auch Druckservice, Nachrichtenservice, Anwendungsservice, Datenbankservice. Telekommunikationsdienste werden als Sprachdienste, Textdienste, Datendienste von dienstleistenden Teilnehmern angeboten. Auch Multimediadienste, zum Beispiel zur Freischaltung von Streamingdiensten für Audio, Video, Bücher werden von Dienstleistern angeboten.
Alle diese Dienste können erfindungsgemäß mit STC freigeschaltet oder autorisiert werden.
In einer bevorzugten Ausgestaltung ist der erste STC einem Konto des ersten Teilnehmers zugeordnet, das Kommando ist dann ein „Übertrage“, englisch „Transfer“, Kommando. Dieses Kommando ermöglicht das Senden zumindest eines Elements eines STC von der Adresse des ersten Teilnehmers zu einer anderen Adresse (des zweiten Teilnehmers) in der DLT-Infrastruktur.
Bevorzugt wird das STC vor dem Senden aktiviert. Damit wird im Netzwerk signalisiert, dass ein STC verwendet wird, also eine VC-Einheit teilbar ist und auch geteilt werden kann. Ab dem Zeitpunkt der Aktivierung des STC ist die Aktivierung im Übertragungsverfahren sichtbar und per Kommando sind Details zum STC, beispielsweise Anzahl der Elemente insgesamt, Anzahl deaktivierbarer Elemente des STC, etc. abrufbar.
Bevorzugt umfasst jedes Konto ein Sammeldepot, von dem ein STC abgeleitet und/oder auf das ein STC hinzugefügt werden kann. Das Sammeldepot stellt ein Sammelkonto dar. Hier wird die Anzahl der in der DLT-Infrastruktur für diesen Teilnehmer verfügbaren STCs gespeichert. Von diesem Sammeldepot können nicht-geteilte STCs, also NSTC, zu anderen Adressen (Blockchain-Konten) verschoben werden. Ein NSTC ist nachfolgend ein STC der mit allen deaktivierbaren Elementen, also vollständig (ohne ein deaktiviertes Element) übertragen wird. Aufgrund der DLT-Infrastruktur wird die Anzahl der STCs im Konto des ersten Teilnehmers in gleicherweise erniedrigt oder erhöht wie sie im Konto eines anderen Teilnehmers erhöht oder erniedrigt wird. Das Sammeldepot ermöglicht die Kompatibilität mit den bestehenden VC-Konzepten, beispielsweise Ether oder Bitcoin.
In einer bevorzugten Ausgestaltung werden unmittelbar nach dem Ableiten eines neuen STC, alle Elemente des abgeleiteten STC aktiviert und das Sammeldepot um einen Zählwert dekrementiert. Das Ableiten kann als ein Lade-Vorgang eines neuen STC angesehen werden, beispielsweise um initial das Übertragungsverfahren zu starten oder um ein STC, bei dem alle Elemente deaktiviert sind, zu ersetzen, sodass der Teilnehmer weiter am Übertragungsverfahren mittels STC teilnehmen kann.
Das Ableiten eines neuen STC kann mit einer Prüfung einhergehen, ob bereits alle Elemente eines bereits aktivierten STC deaktiviert sind. Ist dies nicht der Fall, erfolgt das Ableiten in einem vom bereits geladenen STC verschiedenen Datenfeld. Auf diese Weise werden (noch) nicht deaktivierte Elemente nicht gelöscht, und auf diese Weise werden keine deaktivierbaren Elemente verschwendet.
Das Ableiten eines neuen STC kann auch einem Addieren der Elemente eines neuen STC zu einem bereits abgeleiteten STC bedeuten. Die Anzahl der Elemente des bereits abgeleiteten STC wird dann um die Elemente des neuen STC erhöht.
Das Ableiten kann automatisch erfolgen, nachdem alle Elemente eines STC deaktiviert sind.
In einer bevorzugten Ausgestaltung werden unmittelbar vor dem Hinzufügen alle Elemente eines STC aktiviert und das Sammeldepot um einen Zählwert inkrementiert. Das Hinzufügen kann als ein Einlösen-Vorgang eines STC angesehen werden, beispielsweise wenn alle Elemente aktiviert sind und der Teilnehmer dieses STC seinem Sammeldepot gutschreiben möchte.
In einer bevorzugten Ausgestaltung wird das STC unmittelbar nach dem Hinzufügen deaktiviert. Damit wird in der DLT-Infrastruktur angezeigt, dass bei diesem Teilnehmer keine einzelnen Elemente von STCs mehr austauschbar sind.
Das Hinzufügen kann automatisiert erfolgen. Beispielsweise kann bei Erhalt einer Mehrzahl von Elementen, die restlichen Elemente des aktuellen STC aktiviert werden und bei Erkennen, dass alle Elemente aktiviert sind, erfolgt das Hinzufügen. Auf diese Weise können weitere Elemente, in einem neuen STC aktiviert werden. Alternativ wird die Anzahl der Elemente des aktuellen STC um die übrigen Elemente erhöht.
In einer weiter bevorzugten Ausgestaltung werden mittels des Verfahrens die STCs und/oder die NSTC gemäß einer ERC20-Schnittstelle übertragen. ERC20 ist ein technischer Standard für Smart Contracts auf einer spezifischen DLT-Infrastruktur, nämlich dem Ethereum-Blockchain zur Implementierung von Token. ERC steht für „Ethereum Request for Comment“ und 20 ist die Nummer, die diesem Request (Antrag) zugewiesen wurde. ERC20 definiert eine Liste von Regeln für Ethereum-Token Übertragung innerhalb des Ethereum-Systems, sodass eine Interaktion zwischen Token (STC oder NSTC) genau vorhergesagt werden kann. Diese Regeln beinhalten, wie die Token zwischen den Adressen übertragen werden und wie auf die Daten innerhalb jeden Tokens, beispielsweise die Elemente der STC oder NSTC zugegriffen werden kann.
Die Kommandos der ERC20-Schnittstelle umfassen zumindest eines oder mehrere der nachfolgenden Kommandos:

- ein Kommando zum Erfassen der aktivierbaren STC auf einem Konto eines Teilnehmers, auch als „BalanceOf“-Kommando bezeichnet. Damit kann der aktuelle Kontostand (beispielsweise ein Zählwert der STC/NSTC) eines anderen Teilnehmers erfragt werden, sodass sichergestellt ist, ob ausreichend STCs oder NSTCs zum übertragen vorhanden sind.
- ein Kommando zum Autorisieren eines Teilnehmers, zumindest ein STC auf einem Konto des das Kommando sendenden Teilnehmers zu deaktivieren, auch als „Approve“-Kommando bezeichnet. Damit kann ein Teilnehmer NSTCs und STCs von einem anderen Teilnehmerkonto aktiveren/deaktivieren.
- ein Kommando zum Erfassen der Anzahl deaktivierbarer STC, die ein Teilnehmer von einem Konto eines anderen Teilnehmers deaktivieren darf, auch als „Allowance“-Kommando bezeichnet. Damit kann ein Teilnehmer einen anderen Teilnehmer autorisieren, STCs oder NSTCs von seinem Konto zu aktiveren/deaktivieren.
- ein Kommando zum Übertragen von STCs oder NSTCs von einem Konto eines Teilnehmers zu dem Konto des zweiten Teilnehmers, auch als „Transfer/TransferFrom“ -Kommando bezeichnet.

In einer bevorzugten Ausgestaltung sind die ausgetauschten Kommandos eine Erweiterung einer ERC20-Schnittstelle. Die Erweiterung der ERC20-Schnittstelle umfasst zumindest eines oder mehrere der nachfolgenden Kommandos:

- ein Kommando zum Erfassen der Anzahl deaktivierbarer Elemente eines aktivierten STC auf einem Konto eines Teilnehmers, auch als „BalanceOfStripes“-Kommando bezeichnet. Damit kann der aktuelle Zustand eines aktivierten STCs auf dem Konto eines anderen Teilnehmers erfragt werden, sodass sichergestellt ist, ob ausreichend Elemente aktivierbar/deaktivierbar sind.
- ein Kommando zum Autorisieren eines Teilnehmers, zumindest ein Element eines STC auf einem Konto des das Kommando sendenden Teilnehmers zu deaktivieren, auch als „ApproveStripes“-Kommando bezeichnet. Damit kann ein Teilnehmer einzelne Elemente eines STCs von einem anderen Teilnehmerkonto aktiveren/deaktivieren.
- und/oder ein Kommando zum Erfassen der Anzahl deaktivierbarer Elemente, die ein Teilnehmer von einem Konto eines anderen Teilnehmers deaktivieren darf, auch als „AllowanceStripes“-Kommando bezeichnet. Damit kann ein Teilnehmer einen anderen Teilnehmer autorisieren, einzelne Elemente eines STC von seinem Konto zu aktiveren/deaktivieren.

Bevorzugt weist ein STC einen STC-Kopfteil beinhaltend das ERC20-Kommando und einen STC-Datenteil beinhaltend die Erweiterung des ERC20-Kommandos auf. Somit wird im Kopfteil das ERC20-Kommando übertragen und in der Erweiterung werden die entsprechenden Kommandos betreffend die einzelnen Elemente des STC übertragen. Damit lässt sich das erfindungsgemäße Verfahren in die Ethereum Infrastruktur ohne große System-Änderungen integrieren.
Insbesondere werden die entsprechenden STC/NSTC Kommandos der ERC20-Schnittstelle mit entsprechenden STC-Elemente Kommandos der ERC20-Schnittstellen-Erweiterung gekoppelt. Somit wird bevorzugt ein „transfer/transferFrom“ Kommando und eine „transferStripes/transferFromStripes“ Kommandoerweiterung als ein STC-Kommando übertragen. Somit wird bevorzugt ein „BalanceOf“ Kommando und eine „BalanceOfStripes“ Kommandoerweiterung als ein STC-Kommando übertragen. Somit wird bevorzugt ein „Allowance“ Kommando und eine „AllowanceStripes“ Kommandoerweiterung als ein STC-Kommando übertragen. Somit wird bevorzugt ein „Approve“ Kommando und eine „ApproveStripes“ Kommandoerweiterung als ein STC-Kommando übertragen.
In einer bevorzugten Ausgestaltung weist der STC eine definierte Anzahl von Elementen zum jeweiligen Aktivieren und Deaktivieren auf.
Die einzelnen Elemente können dabei unterschiedliche geldwerte Beträge repräsentieren. Damit wird der STC für unterschiedliche Anwendungen flexibel einsetzbar. Der STC repräsentiert ggf. ein Nutzerdepot, vergleichbar mit einer Geldbörse, in dem Elemente des STC unterschiedlicher geldwerter Beträge aktivierbar/deaktivierbar sind.
In einem weiteren Aspekt ist ein Bezahlsystem zum flexiblen Übertragen von spezifisch teilbaren elektronischen Münzdatensätzen, STC, zwischen zumindest zwei Teilnehmern vorgesehen. Das Bezahlsystem umfasst eine dezentral geführte Bezahltransaktionsdatenbank, DLT, -Infrastruktur zum Übertragen von Kommandos gemäß einem der vorhergehend beschriebenen Art; ein erstes Endgerät in Kommunikationsverbindung mit der DLT, -Infrastruktur, eingerichtet zum Senden von Kommandos von einem ersten Teilnehmer und Empfangen für den ersten Teilnehmer; zumindest ein zweites Endgerät in Kommunikationsverbindung mit der DLT, -Infrastruktur, eingerichtet zum Senden von Kommandos von einem zweiten Teilnehmer und Empfangen für den zweiten Teilnehmer.
Ein STC ist insbesondere ein elektronischer Datensatz der einen geldwerten Betrag repräsentiert und umgangssprachlich auch als „digitale Münze“ oder „elektronische Münze“ bezeichnet wird. Das Recht zumindest an Teilen dieses geldwerten Betrags wechselt bei dem Verfahren in Form der Elemente der STC von einem ersten Konto zu einem anderen Konto. Als ein geldwerter Betrag wird im Folgenden ein digitaler Betrag verstanden, der auf einem Konto eines Geldinstituts gutgeschrieben werden kann. Der STC repräsentiert also Bargeld in elektronischer Form.
Die STCs unterscheiden sich wesentlich von elektronischen Datensätzen zum Datenaustausch oder Datentransfer, da beispielsweise eine klassische Datentransaktion auf Basis eines Frage-Antwort-Prinzips bzw. auf einer Interkommunikation zwischen den Datentransferpartnern stattfindet. STCs kennzeichnen sich dementgegen durch Teilbarkeit, Kombinierbarkeit, Einmaligkeit, Eindeutigkeit und Sicherheitsmerkmal (Signatur, Verschlüsselung) aus. In einem STC sind prinzipiell alle Daten enthalten, die für eine empfangende Instanz bezüglich Verifikation, Authentisierung und Weitergeben an andere Instanzen, bevorzugt Teilnehmer der DLT-Infrastruktur, benötigt werden. Eine Interkommunikation für eine derartige Verifikation, Validierung etc. ist daher bei dieser Art Datensätze grundsätzlich nicht erforderlich.
Zur Übertragung kann ein Sicherheitselement in einem Endgerät vorgesehen sein. Ein Sicherheitselement ist bevorzugt eine spezielle Software, insbesondere in Form einer abgesicherten Laufzeitumgebung innerhalb eines Betriebssystems eines Endgeräts, englisch Trusted Execution Environments, TEE. Alternativ ist das Sicherheitselement beispielsweise als spezielle Hardware, insbesondere in Form eines gesicherten Hardware-Plattform-Moduls, englisch Trusted Platform Module, TPM oder als ein eingebettetes Sicherheitsmodul, eUICC, eSIM, ausgebildet. Das Sicherheitselement stellt eine vertrauenswürdige Umgebung bereit und sichert beispielsweise auch eine Machine-2-Machine, M2M Anwendung ab.
Die Kommunikation zwischen zwei Endgeräten bzw. Sicherheitselement kann drahtlos oder drahtgebunden erfolgen und kann als ein gesicherter Kanal ausgebildet sein. Somit ist der Austausch des STC durch kryptografische Schlüssel, beispielsweise einem für einen Münzdatensatz-Austausch ausgehandelten Sitzungsschlüssel oder einem symmetrischen oder asymmetrischen Schlüsselpaar, gesichert.
Als ein Endgerät wird jegliches ein Programmcode verarbeitendes Endgerät mit Benutzer-Ein-Ausgabe abgesehen, beispielsweise ein PC, ein Smartphone, ein Tablet.
Zudem kann das Endgerät auch Teil einer M2M-Umgebung sein, beispielsweise eine Maschine, Werkzeug, Automat oder auch Behälter und Fahrzeug verstanden. Ein erfindungsgemäßes Endgerät ist somit entweder stationär oder mobil. M2M steht dabei für den (voll-) automatisierten Informationsaustausch zwischen diesen Endgeräten, beispielsweise unter Nutzung des Internets und den entsprechenden Zugangsnetzen, wie dem Mobilfunknetz.
Die DLT-Infrastruktur, beschreibt dabei eine Technik für vernetzte Computer, die zu einer Übereinkunft über die Reihenfolge von bestimmten Transaktionen kommen und darüber, dass diese Transaktionen Daten aktualisieren. Es entspricht einem dezentral geführten Kontobuch oder einer dezentral geführten Transaktionsdatenbank. Die von dem Distributed-Ledger verwalteten Daten können zum Beispiel der Kontostand einer Bitcoinadresse, der Zustand eines Smart Contracts oder die Herkunft eines Diamanten sein. DLTs unterscheiden sich durch die Art, wie die vernetzen Computer zu einer Vereinbarung kommen, sogenannte Konsensus-Protokolle, etwa durch „Proof of Work“, „Proof of Stake“ etc.
Figurenliste
Nachfolgend wird anhand von Figuren die Erfindung bzw. weitere Ausführungsformen und Vorteile der Erfindung näher erläutert, wobei die Figuren lediglich Ausführungsbeispiele der Erfindung beschreiben. Gleiche Bestandteile in den Figuren werden mit gleichen Bezugszeichen versehen. Die Figuren sind nicht als maßstabsgetreu anzusehen, es können einzelne Elemente der Figuren übertrieben groß bzw. übertrieben vereinfacht dargestellt sein.
Es zeigen:

1 ein Ausführungsbeispiel eines Bezahlsystems gemäß der Erfindung;
2 ein Ausführungsbeispiel eines Kontos mit NSTC und STC gemäß dem erfindungsgemäßen Verfahren;
3 ein Ausführungsbeispiel eines erfindungsgemäßen Kommandos für die Übertragung von STC;
4 ein Ausführungsbeispiel eines Verfahrensablaufdiagramms eines erfindungsgemäßen Verfahrens;
5 ein Ausführungsbeispiel für Übertragen von Elementen eines STC gemäß dem erfindungsgemäßen Verfahren; und
6 ein Ausführungsbeispiel eines Verfahrensablaufs zum Übertragen von STC gemäß der Erfindung.

FIGURENBESCHREIBUNG
1 zeigt ein Ausführungsbeispiel eines Bezahlsystems A mit Endgeräten M1, M2, M3 gemäß der Erfindung. Das erfindungsgemäße System A basiert auf dem Ansatz, dass jedem Teilnehmer T1, T2, T3 ein Bankkonto 5 zugewiesen ist. Das System A hat eine dezentral geführte Transaktionsdatenbank, die auch als Distributed-Ledger-Technologie, kurz DLT, -Infrastruktur 1 bezeichnet wird. In dieser DLT-Infrastruktur 1 werden jedem Teilnehmer T1, T2, T3 Geldkonten 5 als Blockchains, englisch Block-Chain zugeteilt. Die hier ausgetauschten geldwerten Beträge sind spezifisch teilbare elektronischen Münzdatensätze, STCs. Diese STCs werden zwischen den einzelnen Konten 5(T1), 5(T2), 5(T3) der Teilnehmer T1, T2, T3 im Block-Chain-Verfahren ausgetauscht, um Bezahlvorgänge mit geldwerten Beträgen durchzuführen (=Banktransaktionen) oder um Dienstleistungen freizuschalten.
Für die Autorisierung von derartigen Transaktionen von einem Konto 5(M1), 5(M2), 5(M3) muss die Transaktion mit dem entsprechenden privaten kryptographischen Schlüssel (PrK) des einen Teilnehmers T1, T2, T3 gesichert sein. Klassische DLT-Implementierungen, wie Ethereum, Bitcoin etc. sind in dieser DLT-Infrastruktur 1 vorgesehen, die STCs werden beispielsweise mittels ERC20 Schnittstelle übertragen.
Im System A der 1 sind die Teilnehmer T1 und T3 Nutzer eines oben aufgezählten Dienstes, während der Teilnehmer T2 (hier als Warenkorb dargestellt) ein entsprechender Diensteanbieter ist. Dabei deckt das erfindungsgemäße System den Erwerb einer Dienstleistung ab. Man kann die Dienstleistung innerhalb eines längeren Zeitpunkts einlösen. Der STC könnte ein Gültigkeitsdatum haben. Die Dienstleistung kann gehandelt - also weiterverkauft werden.
Als Dienstleistung ist beispielsweise ein Multimedia-Stream Dienst oder ein On-Demand-Dienst, beispielsweise für Audio (Musik, Hörbuch, Potcast, Webinar), Video (Film, Serie, Livestream, Sportereignis, Webinar), Text (Bücher, Zeitschriften, Zeitungen) vorgesehen.
Zusätzlich kann als Dienstleistung ein e-Voting Dienst, ein Digital-Rights-Management oder ein Authentifizieren/Identifizieren-Dienst sein. Die Art und Ausgestaltung der Dienstleistung kann beliebig sein.
2 zeigt ein Ausführungsbeispiel einer visuellen Darstellung eines in der DLT-Infrastruktur 1 gemäß 1 verwendeten Kontos 5 gemäß dem erfindungsgemäßen Verfahren.
Für die erfindungsgemäßen STCs gibt es ein STC-Sammeldepot 6. Diesem Sammeldepot 6 wird ein kontoindividueller Sammeldepot-Zählerstand 2 zugeordnet. Hier wird die Anzahl der auf dem Konto 5, bspw. 5(T1), insgesamt verfügbaren STCs gespeichert. Dieser Zählerstand 2 ist beispielsweise mittels Kommando „balanceof“ vom Teilnehmer T1 selbst oder von anderen Teilnehmern T2, T3 abrufbar. Aus dem Sammeldepot 6 des Kontos 5(T1) können STCs in andere Konten 5(T2), 5(T3) der DLT-Infrastruktur 1 verschoben werden. Der Zählerstand 2 im Konto 5(T1) wird in gleicherweise erniedrigt oder erhöht wie sie im anderen Konto 5(T2), 5(T3) erhöht oder erniedrigt wird.
Für dieses Sammeldepot 6 des Kontos 5 gilt beispielsweise eines oder mehrere der folgenden ERC20-Kommandos: totalSupply; balanceOf; transfer; transferFrom; approve; allowance, die beispielsweise gemäß 3 als Kopfteil 7 eines STC Kommandos übertragen werden.
Das erfindungsgemäße Konto 5 weist zudem ein kontoindividuelles aktiviert-Datenfeld 3 auf. Dieses Datenfeld 3 zeigt an, ob momentan ein STC im Konto 5 aktiviert ist oder nicht. Das Datenfeld 3 hat demnach den Zustand „0“ für deaktiviert oder den Zustand „1“ für aktiviert. Befindet sich ein STC im Konto 5 im aktivierten Zustand wird dies im Datenfeld mit „1“ angezeigt, Befindet sich ein STC im Konto 5 im deaktivierten Zustand wird dies im Datenfeld mit „0“ angezeigt. Mit diesem Datenfeld wird den Teilnehmern der DLT-Infrastruktur 1 angezeigt, ob der Teilnehmer ein STC fähiges Konto 5 hat und ob dieses STC-fähige Konto 5 für das Übertragen von STC, insbesondere von Elementen eines STC, aktiviert ist.
Das erfindungsgemäße Konto 5 weist zudem ein STC individuelles Datenfeld 4 auf. In diesem Datenfeld 4 sind die Elemente v eines STC angezeigt. Gemäß 2 weist das STC acht Elemente v₁ bis v₈ auf. Diese Anzahl n = 8 kann STC spezifisch sein. Somit können STCs mit unterschiedlicher Elemente-Anzahl n verwendet werden, was zu geringeren administrativem Aufwand beim Teilnehmer T1, T2, T3 und/oder zu geringerem Datenaufwand in der DLT-Infrastruktur 1 führen kann, beispielsweise wenn eine größere Anzahl von Elementen eines STC gleichzeitig an einen anderen Teilnehmer übertragen werden sollen.
Dieses Datenfeld 4 zeigt an, welche Elemente v eines STC aktiviert sind und welche deaktiviert. Das Datenfeld 4 hat für ein Element v demnach den Zustand „0“, wenn dieses Element deaktiviert (verbraucht) ist oder den Zustand „ungleich 0“, wenn es (noch) aktiviert ist. Bevorzugt hat jedes Element v eines STC einen elementindividuellen Wert v_W der im STC festgelegt ist.
Für die Datenfelder 3, 4 gelten beispielsweise eines oder mehrere der folgenden ERC20-Kommando-Erweiterungen: balanceOfStripes; transferStripes; transferStripesFrom; approveStripes; allowanceStripes, die beispielsweise gemäß 3 als Datenteil 8 eines STC Kommandos übertragen werden.
Die Übertragung wird ausgeführt, wenn der Wert v_w in dem Element v_x bei erfolgreich durchgeführter Übertragung größer „0“ ist.
In 3 ist ein Ausführungsbeispiel eines erfindungsgemäßen Kommandos für die Übertragung von STC gezeigt. Das Kommando ist dabei zweigeteilt und hat einen STC-Kopfteil 7 und einen STC-Datenteil 8. Der STC-Datenteil 8 wird hierin auch als Erweiterung eines Kommandos bezeichnet. Bevorzugt ist das Kommando gemäß ERC20 Schnittstelle strukturiert, wobei der Kopfteil 7 dem ERC20 Standard entspricht und hier nicht näher erläutert wird. Zudem wird der ERC20 Standard beispielsweise um folgende Kommandos im Datenteil 8 erweitert:

- balanceOfStripes mit Sendeadresse, Empfängeradresse, Nummer x des Elements v_x . Diese Kommandoerweiterung gibt der Sendeadresse den Wert v_w des Elements v_x zurück. Optional wird ein Bereich im Datenfeld 4 angegeben, dann wird der Wert v_w des Bereichs im Datenfeld 4 zurückgegeben.
- TransferStripes mit Sendeadresse, Empfängeradresse, Nummer x des Elements v_x . Mit diesem Kommando wird der Wert v_w des Elements v_x von der angegebenen Sendeadresse an die angegebene Empfängeradresse übertragen. Optional wird der Wert v_w des Elements v_x und/oder ein Bereich im Datenfeld 4 angegeben, der zu übertragen ist.
- transferStripesFrom mit Sendeadresse, Empfängeradresse, Nummer x des Elements v_x . Mit diesem Kommando wird der Wert v_w des Elements v_x von der angegebenen Sendeadresse - die nicht zwangsläufig der Adresse des Kommandosenders entspricht - an die Empfängeradresse übertragen. Optional wird der Wert v_w des Elements v_x und/oder ein Bereich im Datenfeld 4 angegeben, der zu übertragen ist.
- approveStripes mit Spenderadresse, Nummer x des Elements v_x . Mit diesem Kommando wird die angegebene Spenderadresse autorisiert, den Wert v_w des Elements v_x vom Konto des Kommandosendenden zu deaktivieren. Optional wird der Wert v_w des Elements v_x und/oder ein Bereich im Datenfeld 4 mit angegeben.
- allowanceStripes mit Sendeadresse, Spenderadresse, Nummer x des Elements v_x . Mit diesem Kommando wird der Wert v_w des Elements v_x abgefragt, für den die angegebene Spenderadresse autorisiert ist.

Die 4 zeigt nun ein Ausführungsbeispiel eines Verfahrensablaufdiagramms eines erfindungsgemäßen Verfahrens 100, was in Kombination mit 5 und 6 erläutert wird.
Die 5 zeigt zudem ein Ausführungsbeispiel zum Übertragen von Elementen v eines STC gemäß dem erfindungsgemäßen Verfahren am Beispiel von zwei Konten 5(T1) und 5(T2) der Teilnehmer T1 und T2. Der Teilnehmer T2 ist ein Diensteanbieter. Der Teilnehmer T1 ist dabei ein Nutzer der einen, vom Diensteanbieter angebotenen, Dienst nutzen möchte und dazu eine Freischaltung erkauft. Zum Freischalten des Dienstes fordert der Diensteanbieter im vorliegenden Beispiel eine Bezahlung in Höhe eines Elements v eines STC vom Teilnehmer T1.
Das Sammeldepot 2 des Kontos 5(T1) des ersten Teilnehmers T1 weist dabei vier NSTC auf. Das Sammeldepot 2 des Konto 5 (T1) des ersten Teilnehmers T1 kann unter anderem die Kommandos „balanceOf“,; „transfer“, „transferFrom“, „approve“ und „allowance“ abgefragt werden kann.
Das Datenfeld 3 des Kontos 5(T1) des ersten Teilnehmers T1 zeigt den Zustand „0“ an. Das Datenfeld 4 des Kontos 5 (T1) des ersten Teilnehmers T1 zeigt acht Elemente, die je den Wert „0“ aufweisen. Somit ist das Konto 5 (T1) des ersten Teilnehmers nicht aktiviert für das Senden oder Empfangen von STCs, die Kommandoerweiterungen können demnach nicht auf dieses Konto 5(T1) angewendet werden.
Das Sammeldepot 2 des Kontos 5(T2) des zweiten Teilnehmers T2 weist 32 NSTC auf. Das Datenfeld 3 des Kontos 5(T2) des zweiten Teilnehmers T2 zeigt den Zustand „1“ an. Das Datenfeld 4 des Kontos 5 (T1) des ersten Teilnehmers T1 zeigt acht Elemente, von das erste Element v₁ den Wert „0“ und die sieben übrigen Element v₂ bis v₈ den Wert „1“ aufweisen. Somit ist das Konto 5 (T2) des zweiten Teilnehmers T2 aktiviert für das Senden oder Empfangen von STCs, was mit den entsprechenden Kommandos „balanceOf“ und „balanceOfStripes“ abgefragt werden kann. Zudem können hier neben den Kommandos auch die Kommandoerweiterungen „transfer/transferStripes“, „transferFrom/transferFromStripes“, „approve/approveStripes“ und „allowance/AllowanceStripes“ auf das STC angewendet werden.
Die 6 zeigt zudem ein Ausführungsbeispiel eines Verfahrensablaufs zum Übertragen von STC gemäß der Erfindung.
Nachfolgend wird das in 4, 5 und 6 dargestellte Verfahren 100 erläutert. Dieses Verfahren 100 wird beispielsweise auf einem in 1 dargestellten System A betrieben. Die Bezugszeichen für gleiche Schritte wurden identisch gewählt in diesen Figuren, um deren gleiche Funktion zu untermauern.
Wie erwähnt, fordert der zweite Teilnehmer T2 vom ersten Teilnehmer T1 ein Element v mit dem Wert „1“, um den Teilnehmer T1 für einen digitalen Dienst freischalten zu können. In 4 und 6 ist dazu mit dem Schritt 101 ein Ableiten eines STC von einem Sammeldepot 6 des Kontos 5(T1) des ersten Teilnehmers T1 mittels ersten Endgeräts M1 gezeigt. Unmittelbar nach dem Ableiten-Schritt 101 wird der Zählerwert des Datenfelds 2 des Kontos 5(T1) des ersten Teilnehmers dekrementiert, siehe 5, wo der Wert des Datenfelds 2 des Kontos 5 (T1) von vier auf drei verändert wird. Zudem werden unmittelbar nach dem Ableiten-Schritt 101 alle Elemente v₁ bis v₈ des Datenfelds 4 des Kontos 5 (T1) des ersten Teilnehmers T1 vom Wert „0“ auf den Wert „1“ geschaltet und somit vom Zustand deaktiviert in den Zustand „aktiv“ bzw. „deaktivierbar“ geschaltet.
Im Schritt 102 der 4 und 6 wird nun das STC aktiviert. Dazu wird das Datenfeld 3 des Kontos 5(T1) des ersten Teilnehmers T1 vom Zustand „0“ in den Zustand „1“ geschaltet. Somit ist das Konto 5 (T1) aktiviert für das Senden oder Empfangen von STCs, was mit den entsprechenden Kommandos „balanceOf“ und „balanceOf stripes“ abgefragt werden kann. Zudem können nun auch die Kommandoerweiterungen „transferStripes“, „transferFromStripes“, „approveStripes“ und „allowanceStripes“ auf das STC angewendet werden.
Nach dem Schritt 102 sind die Konten 5(T1) und 5(T2) eingerichtet, um STCs auszutauschen. Der Teilnehmer T1 veranlasst nun mittels Endgerät M1, die Zahlung des geforderten einen Elements v, um den Dienst des Diensteanbieters T2 freigeschaltet zu bekommen. Dies erfolgt mittels des Kommandos „transferStripes“, initiert vom Teilnehmer T1.
Das Endgerät M1 veranlasst sodann das Deaktivieren des zusendenden Elements v₁ im Schritt 103. Das Deaktivieren bedingt eine Zustandsänderung des Elements v₁ vom Zustand „1“ (aktiv) in den Zustand „0“ (inaktiv) welcher sofort mit den entsprechenden Kommandos „balanceOf/balanceOfStripes“ abgefragt werden kann.
Im Folgeschritt 104 wird das Kommando „transferStripes“ von dem ersten Teilnehmer T1 gesendet und vom zweiten Teilnehmer T2 im Schritt 105 empfangen. Dazu bedient sich das System 1 an der etablierten DLT-Infrastruktur und verwendet die entsprechend definierten Blockchain Algorithmen.
Im Folgeschritt 106 veranlasst das Endgerät M2 sodann das Aktivieren des Elements v₁ im Konto 5(T2) des zweiten Teilnehmers T2. Das Aktivieren bedingt eine Zustandsänderung des Elements v₁ vom Zustand „0“ (inaktiv) in den Zustand „1“ (aktiv) welcher sofort mit den entsprechenden Kommandos „balanceOf/balanceOf stripes“ abgefragt werden kann.
Mit dem Schritt 106 ist der Teilnehmer T2 im Besitz des geldwerten Betrags, der mit dem Element v₁ des angezeigt wird. Der Teilnehmer T2 veranlasst nun das Freischalten eines Dienstes für den Teilnehmer T1.
Gemäß 5 wird gezeigt, dass nach dem Schritt 106 alle Elemente v des Datenfelds 4 im Zustand „1“ sind. Dieser Zustand des Datenfelds 4 wird im Prüfen-Schritt 107 erkannt und als „JA“ Fall bewertet. Sodann wird im Schritt 108 der Zählerstand des Datenfelds 2 im Konto 5(T2) des zweiten Teilnehmers T2 erhöht, und von 32 auf 33 inkrementiert, siehe 5. Somit wird ein STC zum Sammeldepot 6 hinzugefügt. Ergibt der Prüfschritt 107, dass nicht alle Elemente des STC aktiv sind, wird der Nein-Fall im Prüfschritt 107 eintreten. Sodann ist ein Hinzufügen 108 des STC zum Sammeldepot 6 nicht möglich, da hier nur nicht-geteilte STCs angezeigt werden können.
Zeitgleich zum Schritt 108 oder unmittelbar darauffolgend wird im Schritt 109 der STC im Konto 5(T2) des zweiten Teilnehmers T2 deaktiviert, indem das Datenfeld 3 vom Zustand „1“ in den Zustand „0“ gesetzt wird. Mit dem Schritt 109 werden sodann alle Elemente v des Datenfelds 4 vom Zustand „1“ in den Zustand „0“ gesetzt.
In 6 wird unterhalb der Strichlinie noch ein weiteres erfindungsgemäßes Szenario beschrieben. Hierbei wird zwischen dem ersten Teilnehmer T1 und dem dritten Teilnehmer T3 die Kommandoerweiterungen „ApproveStripe“ gesendet. Damit wird der dritte Teilnehmer T3 autorisiert, Elemente eines STCs vom ersten Teilnehmer T1 zu deaktivieren.
Im Folgeschritt (Strichpfeil) wird die Anzahl der deaktivierbaren Elemente mittels der Kommandoerweiterung „balanceOfStripes“ abgefragt. Dieses Kommando gibt beispielsweise die Anzahl 3 zurück, wodurch angezeigt wird, dass der dritte Teilnehmer T3 vom ersten Teilnehmer T1 drei Elemente v eines STC deaktivieren kann. Dies wird im Folgeschritt auch veranlasst, indem die Kommandoerweiterung „transferFromStripes“ gesendet wird. Diese Kommandoerweiterung führt dann zur Durchführung der Schritte 103 bis 106 zwischen dem ersten Teilnehmer T1 und dem zweiten Teilnehmer T2, bei welchem drei Elemente v von einem STC des Kontos 5(T1) des ersten Teilnehmers T1 an das Konto 5 (T2) des zweiten Teilnehmers T2 gesendet werden.
Im Rahmen der Erfindung können alle beschriebenen und/oder gezeichneten und/oder beanspruchten Elemente beliebig miteinander kombiniert werden.
Bezugszeichenliste

1: Bezahltransaktionsdatenbank, DLT Infrastruktur
2: Zählerstand Sammeldepot
3: kontoindividuelles Aktiviert-Datenfeld
4: STC individuelles Datenfeld
5: Konto in der DLT Infrastruktur
6: Sammeldepot
7: STC-Kopfteil
8: STC-Datenteil
A: Bezahlsystem
M1: erstes Endgerät
M2: zweites Endgerät
M3: drittes Endgerät
T1: erster Teilnehmer
T2: zweiter Teilnehmer
T3: weiterer Teilnehmer
SE: Sicherheitselement
STC: spezifisch teilbarer Münzdatensatz
NSTC: nicht-geteilter spezifisch teilbarer Münzdatensatz
v_x: x-tes Element des STC
n: Anzahl der Elemente des STC
101-109: Verfahrensschritte gemäß einem Ausführungsbeispiel
201: Verfahrensschritte zum Übertragen ganzer STCs

Claims

Ein Verfahren (100) zum Übertragen eines spezifisch teilbaren elektronischen Münzdatensatzes, STC, zwischen zumindest zwei Teilnehmern (T1, T2, T3) in einer Bezahltransaktionsdatenbank, DLT, -Infrastruktur (1), wobei jedem Teilnehmer (T1, T2; T3) ein Konto (5) in der DLT-Infrastruktur (1) eindeutig zugeordnet ist, mit den Schritten: - Senden (104) eines Kommandos von einem ersten Teilnehmer (T1) unter Verwendung eines ersten Endgeräts (M1) an einen zweiten Teilnehmer (T2), wobei unmittelbar vor dem Senden (104) ein Element (v) eines ersten STC auf dem Konto (5) eines Teilnehmers (T1, T3) in der DLT-Infrastruktur (1) deaktiviert (103) wird; und - Empfangen (105) des Kommandos beim zweiten Teilnehmer (T2) unter Verwendung eines zweiten Endgerätes (M2), wobei unmittelbar nach dem Empfangen (105) ein Element (v) eines zweiten STC auf dem Konto (5) des zweiten Teilnehmers (T2) in der DLT-Infrastruktur (1) aktiviert wird.
Das Verfahren (100) nach Anspruch 1, wobei der erste STC dem Konto (5) des ersten Teilnehmers (T1) zugeordnet ist.
Das Verfahren (100) nach einem der vorhergehenden Ansprüche, wobei vor dem Deaktivieren (103) des Elements (V) des ersten STCs der STC aktiviert (102) wird.
Das Verfahren (100) nach einem der vorhergehenden Ansprüche, wobei jedes Konto (5) ein Sammeldepot (6) umfasst, von dem ein STC abgeleitet (101) und/oder auf das ein STC hinzugefügt (108) werden kann.
Das Verfahren (100) nach Anspruch 4, wobei unmittelbar nach dem Ableiten (101) eines STC alle Elemente (V) des abgeleiteten STC aktiviert (102) sind und das Sammeldepot (6) einen Sammeldepot-Zählwert (2) dekrementiert.
Das Verfahren (100) nach einem der Ansprüche 4 oder 5, wobei unmittelbar vor dem Hinzufügen (108) geprüft (107) wird, ob alle Elemente (V) eines STC aktiviert sind, wobei nur im Ja-Fall der STC hinzugefügt (108) wird und das Sammeldepot (6) einen Sammeldepot-Zählwert (2) inkrementiert.
Das Verfahren (100) nach Anspruch 5 oder 6, wobei unmittelbar nach dem Hinzufügen (108) das STC deaktiviert (109) wird.
Das Verfahren (100) nach einem der vorhergehenden Ansprüche 4 bis 7, wobei ein nicht-geteilter spezifisch teilbarer elektronischer Münzdatensatz, NSTC, aus dem Sammeldepot (6) übertragen (201) wird.
Das Verfahren (100) nach einem der vorhergehenden Ansprüche, wobei das Kommando eine Erweiterung einer ERC20-Schnittstelle ist und/oder das Verfahren (100) zumindest ein Kommando gemäß einer ERC20-Schnittstelle überträgt (201).
Das Verfahren (100) nach Anspruch 9, wobei die Erweiterung der ERC20-Schnittstelle zumindest auch eines der nachfolgenden Kommandos umfasst: - ein Kommando zum Erfassen der Anzahl deaktivierbarer Elemente (V) eines aktivierten STC auf dem Konto (5) eines Teilnehmers (T1, T2, T3); - ein Kommando zum Autorisieren eines Teilnehmers (T1, T2, T3), zumindest ein Element (V) eines STC auf dem Konto (5) des das Kommando sendenden Teilnehmers (T1, T2, T3) zu deaktivieren; und/oder - ein Kommando zum Erfassen der Anzahl (n) deaktivierbarer Elemente (V), die ein Teilnehmer (T1, T2, T3) von dem Konto (5) eines anderen Teilnehmers (T1, T2, T3) deaktivieren darf.
Das Verfahren (100) nach Anspruch 9 oder 10, wobei das zumindest eine Kommando der ERC20-Schnittstelle zumindest eines der nachfolgenden Kommandos umfasst: - ein Kommando zum Erfassen der aktivierbaren STC auf dem Konto (5) eines Teilnehmers (T1, T2, T3); - ein Kommando zum Autorisieren eines Teilnehmers (T1, T2, T3), zumindest ein STC auf einem Konto (5) des das Kommando sendenden Teilnehmers (T1, T2, T3) zu deaktivieren; - ein Kommando zum Erfassen der Anzahl von STCs, bevorzugt eines Sammeldepot-Zählerstands (2), die ein Teilnehmer (T1, T2, T3) von dem Konto (5) eines anderen Teilnehmers (T1, T2, T3) deaktivieren darf; und/oder - ein Kommando zum Übertragen (201) von STCs von dem Konto (5) eines anderen Teilnehmers (T1, T2, T3) zu dem Konto (5) eines noch anderen Teilnehmers (T1, T2, T3).
Das Verfahren (100) nach einem der Ansprüche 9 bis 11, wobei der STC einen STC-Kopfteil (7) beinhaltend die ERC20-Kommandos und einen STC-Datenteil (8) beinhaltend die Erweiterung der ERC20-Kommandos aufweist.
Das Verfahren (100) nach einem der vorhergehenden Ansprüche, wobei der STC eine definierte Anzahl (n) von Elementen (V) zum jeweiligen Aktivieren (103) und Deaktivieren (106) aufweist.
Das Verfahren (100) nach einem der vorhergehenden Ansprüche, wobei Elemente (V) des STC unterschiedliche geldwerte Beträge repräsentieren.
Ein Bezahlsystem (A) zum flexiblen Übertragen von spezifisch teilbaren elektronischen Münzdatensätzen, STC, zwischen zumindest zwei Teilnehmern (T1, T2, T3), wobei das Bezahlsystem (A) umfasst: - eine dezentral geführte Bezahltransaktionsdatenbank, DLT, -Infrastruktur (1) zum Übertragen zumindest eines Kommandos gemäß einem der vorhergehenden Ansprüche 1 bis 14; - ein erstes Endgerät (M1) in Kommunikationsverbindung mit der DLT, - Infrastruktur (1), eingerichtet zum Senden (104) eines der Kommandos von einem ersten Teilnehmer (T1) und Empfangen (105) für den ersten Teilnehmer (T1); - ein zweites Endgerät (M2) in Kommunikationsverbindung mit der DLT, - Infrastruktur (1), eingerichtet zum Senden (104) eines der Kommandos von einem zweiten Teilnehmer (T2) und Empfangen (105) für den zweiten Teilnehmer (T2).