DE102022109813A1 - Vorrichtungen, System und Verfahren zum elektronischen bargeldlosen Bezahlen - Google Patents

Vorrichtungen, System und Verfahren zum elektronischen bargeldlosen Bezahlen Download PDF

Info

Publication number
DE102022109813A1
DE102022109813A1 DE102022109813.3A DE102022109813A DE102022109813A1 DE 102022109813 A1 DE102022109813 A1 DE 102022109813A1 DE 102022109813 A DE102022109813 A DE 102022109813A DE 102022109813 A1 DE102022109813 A1 DE 102022109813A1
Authority
DE
Germany
Prior art keywords
communication device
transaction
data communication
payment
user
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE102022109813.3A
Other languages
English (en)
Inventor
Christoph Bösch
Sven Marsing
Florian Peters
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Bundesdruckerei GmbH
Original Assignee
Bundesdruckerei GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Bundesdruckerei GmbH filed Critical Bundesdruckerei GmbH
Priority to DE102022109813.3A priority Critical patent/DE102022109813A1/de
Priority to PCT/EP2023/057540 priority patent/WO2023202836A1/de
Publication of DE102022109813A1 publication Critical patent/DE102022109813A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
    • G06Q20/0655—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash e-cash managed centrally
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3223—Realising banking transactions through M-devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/326—Payment applications installed on the mobile devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/363—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes with the personal data of a user
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3674—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes involving authentication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3821—Electronic credentials
    • G06Q20/38215—Use of certificates or encrypted proofs of transaction rights
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3825—Use of electronic signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/389—Keeping log of transactions for guaranteeing non-repudiation of a transaction
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4014—Identity check for transactions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/405—Establishing or using transaction specific rules
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3218—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using proof of knowledge, e.g. Fiat-Shamir, GQ, Schnorr, ornon-interactive zero-knowledge proofs
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees

Landscapes

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

Abstract

Die Erfindung betrifft eine Datenkommunikationsvorrichtung (110) zum Ausführen einer elektronischen Bezahltransaktion. Die Datenkommunikationsvorrichtung (110) umfasst wenigstens einen Prozessor (111), der ausgebildet ist, eine Payment-Applikation (111a) und eine ID-Applikation (111b) auszuführen, und ein Kommunikationsinterface (113), das ausgebildet ist, mit einer Trustcenter-Serveranordnung (130) und einem Geld-Ledger (150) zu kommunizieren. Die Payment-Applikation (111a) ist ausgebildet, eine Transaktions-ID und eine dezentrale Identität, DID, eines Benutzers (110a) der Datenkommunikationsvorrichtung (110) an einen Payment-Agenten (131a) der Trustcenter-Serveranordnung (130) zu senden. Die ID-Applikation (111b) ist ausgebildet, in Reaktion auf eine die DID enthaltende Anfrage eines ID-Agenten (131b) der Trustcenter-Serveranordnung (130), signierte User-Credentials des Benutzers (110a) der Datenkommunikationsvorrichtung (110) an den ID-Agenten (131b) der Trustcenter-Serveranordnung (130) zu senden. Die Payment-Applikation (111a) ist ferner ausgebildet, eine Signatur der Transaktions-ID von dem Payment-Agenten (131a) der Trustcenter-Serveranordnung (130) zu empfangen und die Signatur der Transaktions-ID an den Geld-Ledger (150) zu senden, um die elektronische Bezahltransaktion mit der Signatur der Transaktions-ID auf dem Geld-Ledger (150) zu verbuchen.

Description

  • Die vorliegende Erfindung betrifft Vorrichtungen, ein System und Verfahren zum elektronischen bargeldlosen Bezahlen.
  • Im Zuge der zunehmenden Digitalisierung rücken heutzutage mehr und mehr bargeldlose Zahlungsinstrumente in den Vordergrund, insbesondere basierend auf elektronischen Verfahren zur Zahlungsabwicklung. Im bargeldlosen Zahlungsverkehr erfolgt ein Transfer von Zahlungsmitteln, ohne dass dabei Bargeld transferiert wird. Bei Barzahlungen wird Bargeld, d.h. Banknoten oder Münzen, zwischen Zahlungspflichtigem und Zahlungsempfänger ausgetauscht, während es bei einer bargeldlosen Zahlung nicht zu einem solchen Austausch von Bargeld kommt.
  • Bargeld hat beispielsweise den Vorteil, dass es für jedermann verfügbar ist und schnell sowie überall eingesetzt werden kann. So ist beispielsweise für eine bargeldbasierte Zahlungsabwicklung kein Bankkonto erforderlich. Zudem wird Bargeld von den Besitzern oftmals als Wertaufbewahrungsmittel geschätzt. Bargeldlose Zahlungsverfahren haben demgegenüber beispielsweise den Vorteil, dass sie eine effiziente Zahlungsabwicklung ermöglichen, selbst wenn sich Zahlungspflichtiger und Zahlungsempfänger an entfernten Orten aufhalten, wie es beispielsweise bei Einkäufen über das Internet der Fall ist.
  • Bei Geldtransaktionen mit Bargeld bleibt die Anonymität der beteiligten Parteien im Wesentlichen gewahrt. Bargeldlose elektronische Zahlungsverfahren können ebenfalls anonym durchgeführt werden, es kann jedoch erforderlich sein, beispielsweise aufgrund von gesetzlichen Bestimmungen, die Identitäten der beteiligten Parteien, d.h. des Zahlungspflichtigen und des Zahlungsempfängers, ab bestimmten Beträgen zu erfassen, so dass diese nachverfolgt werden können. Bei bargeldlosen elektronischen Zahlungsverfahren, die auf einer Blockchain basieren, wie beispielweise Bitcoin, ist eine solche Möglichkeit der Nachverfolgung in der Regel nicht gegeben.
  • Es ist die Aufgabe der vorliegenden Erfindung, ein Konzept zum elektronischen bargeldlosen Bezahlen zu schaffen, welches bei Bedarf eine Nachverfolgung der Identitäten der beteiligten Parteien, d.h. des Zahlungspflichtigen und des Zahlungsempfängers, erlaubt.
  • Diese Aufgabe wird durch die Merkmale der unabhängigen Ansprüche gelöst. Vorteilhafte Ausbildungsformen sind Gegenstand der abhängigen Patentansprüche, der Beschreibung sowie der Figuren.
  • Die hier beschriebenen erfindungsgemäßen Ausführungsformen beruhen auf der Idee, dass für die Durchführung einer bargeldlosen elektronischen Transaktion mittels einer Datenkommunikationsvorrichtung, beispielsweise eines Smartphones, ein Vertrauensdiensteanbieter, insbesondere ein Trustcenter, die Identität des Zahlungspflichtigen überprüft, die Identität des Zahlungspflichtigen in einer Datenbank zusammen mit einer Transaktions-ID speichert und die Transaktions-ID digital signiert, so dass die signierte Transaktions-ID von der Datenkommunikationsvorrichtung auf einem Geld-Ledger hinterlegt werden. Gemäß einer Ausführungsform kann die Verknüpfung einer Transaktion mir der Identität des Zahlungspflichtigen durch das Trustcenter durchgeführt werden, falls der Betrag der Transaktion einen Schwellenwert übersteigt. Für eine Transaktion, deren Betrag nicht höher als der Schwellenwert ist, kann die Datenkommunikationsvorrichtung die Transaktion ohne Einbeziehung des Trustcenters hinterlegen, d.h. die Transaktion vollkommen anonym durchgeführt werden. Durch die Verknüpfung einer Transaktion mit der Identität des Zahlungspflichtigen durch das Trustcenter kann die Anonymität einer Transaktion auf dem Geld-Ledger gewahrt werden, jedoch bei Bedarf nachverfolgt werden.
  • Gemäß einem ersten Aspekt wird eine Datenkommunikationsvorrichtung zum Ausführen einer elektronischen Bezahltransaktion bereitgestellt. Dabei umfasst die Datenkommunikationsvorrichtung wenigstens einen Prozessor, der ausgebildet ist, eine Payment-Applikation und eine ID-Applikation auszuführen, sowie ein Kommunikationsinterface, das ausgebildet ist, mit einer Trustcenter-Serveranordnung und einem Geld-Ledger zu kommunizieren. Die Payment-Applikation ist ausgebildet, eine Transaktions-ID und eine dezentrale Identität, DID, eines Benutzers der Datenkommunikationsvorrichtung an einen Payment-Agenten der Trustcenter-Serveranordnung zu senden. Die ID-Applikation ist ausgebildet, in Reaktion auf eine die DID enthaltende Anfrage eines ID-Agenten der Trustcenter-Serveranordnung, signierte User-Credentials des Benutzers der Datenkommunikationsvorrichtung an den ID-Agenten der Trustcenter-Serveranordnung zu senden. Die Payment-Applikation ist ferner ausgebildet, eine Signatur der Transaktions-ID von dem Payment-Agenten der Trustcenter-Serveranordnung zu empfangen und die Signatur der Transaktions-ID an den Geld-Ledger zu senden, um die elektronische Bezahltransaktion mit der Signatur der Transaktions-ID auf dem Geld-Ledger zu verbuchen.
  • In einer Ausführungsform ist die Payment-Applikation zum Ausführen einer weiteren elektronischen Bezahltransaktion, deren Betrag kleiner als ein Schwellenwert ist, ausgebildet, eine weitere Transaktions-ID der weiteren elektronischen Bezahltransaktion ohne eine Signatur der weiteren Transaktions-ID an den Geld-Ledger zu senden, um die elektronische Bezahltransaktion mit der weiteren Transaktions-ID und ohne eine Signatur der weiteren Transaktions-ID auf dem Geld-Ledger zu verbuchen.
  • In einer Ausführungsform ist die Payment-Applikation ferner ausgebildet, die Transaktions-ID zu generieren und/oder auf Anfrage die DID des Benutzers der Datenkommunikationsvorrichtung von der ID-Applikation zu erhalten.
  • In einer Ausführungsform ist die ID-Applikation ferner ausgebildet, in Reaktion auf die Anfrage des ID-Agenten der Trustcenter-Serveranordnung, Zero-Knowledge-Proof-Daten an den ID-Agenten der Trustcenter-Serveranordnung zu senden, um die signierten User-Credentials des Benutzers der Datenkommunikationsvorrichtung zu verifizieren.
  • In einer Ausführungsform ist die Payment-Applikation ferner ausgebildet, eine weitere DID eines weiteren Benutzers einer weiteren Datenkommunikationsvorrichtung zusammen mit der Transaktions-ID und der DID des Benutzers der Datenkommunikationsvorrichtung an den Payment-Agenten der Trustcenter-Serveranordnung zu senden. In einer Ausführungsform ist der weiteren Benutzer der weiteren Datenkommunikationsvorrichtung der Zahlungsempfänger.
  • In einer Ausführungsform handelt es sich bei der Datenkommunikationsvorrichtung um eine mobile und tragbare Datenkommunikationsvorrichtung, insbesondere ein Smartphone.
  • Gemäß einem zweiten Aspekt wird ein Verfahren zum Betreiben einer Datenkommunikationsvorrichtung zum Ausführen einer elektronischen Bezahltransaktion bereitgestellt, wobei die Datenkommunikationsvorrichtung wenigstens einen Prozessor umfasst, der ausgebildet ist, eine Payment-Applikation und eine ID-Applikation auszuführen, sowie ein Kommunikationsinterface, das ausgebildet ist, mit einer Trustcenter-Serveranordnung und einem Geld-Ledger zu kommunizieren. Das Verfahren umfasst die folgenden Schritte:
    • Senden einer Transaktions-ID und einer dezentralen Identität, DID, eines Benutzers der Datenkommunikationsvorrichtung von der Payment-Applikation an einen Payment-Agenten der Trustcenter-Serveranordnung;
    • Senden von signierten User-Credentials des Benutzers der Datenkommunikationsvorrichtung von der ID-Applikation an einen ID-Agenten der Trustcenter-Serveranordnung, in Reaktion auf eine die DID enthaltende Anfrage des ID-Agenten der Trustcenter-Serveranordnung;
    • Empfangen einer Signatur der Transaktions-ID von dem Payment-Agenten der Trustcenter-Serveranordnung durch die Payment-Applikation; und
    • Senden der Signatur der Transaktions-ID von der Payment-Applikation an den Geld-Ledger, um die elektronische Bezahltransaktion mit der Signatur der Transaktions-ID auf dem Geld-Ledger zu verbuchen.
  • Gemäß einem dritten Aspekt wird eine Trustcenter-Serveranordnung zum Ausführen einer elektronischen Bezahltransaktion bereitgestellt. Die Trustcenter-Serveranordnung umfasst wenigstens einen Prozessor, der ausgebildet ist, einen Payment-Agenten und einen ID-Agenten auszuführen, ein Kommunikationsinterface, das ausgebildet ist, mit einer Datenkommunikationsvorrichtung zu kommunizieren, sowie einen Speicher zum Speichern von elektronischen Daten. Der Payment-Agent ist ausgebildet, eine Transaktions-ID und eine dezentrale Identität, DID, eines Benutzers der Datenkommunikationsvorrichtung von einer Payment-Applikation der Datenkommunikationsvorrichtung zu empfangen. Der ID-Agent ist ausgebildet, in Reaktion auf eine die DID enthaltende Anfrage des Payment-Agenten nach User-Credentials des Benutzers der Datenkommunikationsvorrichtung, die signierten User-Credentials des Benutzers der Datenkommunikationsvorrichtung von einer ID-Applikation der Datenkommunikationsvorrichtung zu erhalten. Der Payment-Agent ist ferner ausgebildet, die User-Credentials des Benutzers der Datenkommunikationsvorrichtung zu erhalten und zusammen mit der Transaktions-ID in dem Speicher zu speichern. Der Payment-Agent ist ferner ausgebildet, die Transaktions-ID zu signieren und die signierte Transaktions-ID an die Payment-Applikation der Datenkommunikationsvorrichtung zu senden, um die elektronische Bezahltransaktion mit der Signatur der Transaktions-ID auf einem Geld-Ledger verbuchen zu können.
  • In einer Ausführungsform ist das Kommunikationsinterface ferner ausgebildet, mit einem ID-Ledger zu kommunizieren und der ID-Agent ist ferner ausgebildet, Zero-Knowledge-Proof-Daten von der ID-Applikation der Datenkommunikationsvorrichtung zu erhalten und mittels der Zero-Knowledge-Proof-Daten und dem ID-Ledger die signierten User-Credentials des Benutzers der Datenkommunikationsvorrichtung zu verifizieren.
  • Gemäß einem vierten Aspekt wird ein Verfahren zum Betreiben einer Trustcenter-Serveranordnung zum Ausführen einer elektronischen Bezahltransaktion bereitgestellt, wobei die Trustcenter-Serveranordnung wenigstens einen Prozessor umfasst, der ausgebildet ist, einen Payment-Agenten und einen ID-Agenten auszuführen, ein Kommunikationsinterface, das ausgebildet ist, mit einer Datenkommunikationsvorrichtung zu kommunizieren, sowie einen Speicher zum Speichern von elektronischen Daten. Das Verfahren umfasst die folgenden Schritte:
    • Empfangen einer Transaktions-ID und einer dezentralen Identität, DID, eines Benutzers der Datenkommunikationsvorrichtung von einer Payment-Applikation der Datenkommunikationsvorrichtung durch den Payment-Agenten;
    • Erhalten von signierten User-Credentials des Benutzers der Datenkommunikationsvorrichtung von einer ID-Applikation der Datenkommunikationsvorrichtung durch den ID-Agenten, in Reaktion auf eine die DID enthaltende Anfrage des Payment-Agenten nach den User-Credentials des Benutzers der Datenkommunikationsvorrichtung;
    • Erhalten der User-Credentials des Benutzers der Datenkommunikationsvorrichtung durch den Payment-Agenten;
    • Speichern der User-Credentials des Benutzers der Datenkommunikationsvorrichtung zusammen mit der Transaktions-ID durch den Payment-Agenten in dem Speicher; und Senden der signierten Transaktions-ID von dem Payment-Agenten an die Payment-Applikation der Datenkommunikationsvorrichtung, um die elektronische Bezahltransaktion mit der Signatur der Transaktions-ID auf einem Geld-Ledger verbuchen zu können.
  • Gemäß einem fünften Aspekt wird ein System zum Ausführen einer elektronischen Bezahltransaktion bereitgestellt, wobei das System eine Vielzahl von Datenkommunikationsvorrichtungen gemäß dem ersten Aspekt und eine Trustcenter-Serveranordnung gemäß dem dritten Aspekt umfasst.
  • Die unterschiedlichen Aspekte der Erfindung können in Hardware und/oder Software realisiert werden.
  • Weitere Ausführungsbeispiele werden Bezug nehmend auf die beiliegenden Figuren näher erläutert. Es zeigen:
    • 1 ein schematisches Diagramm eines Systems zum elektronischen Bezahlen gemäß einer Ausführungsform mit einer Datenkommunikationsvorrichtung gemäß einer Ausführungsform und einem Trustcenter-Server-Anordnung gemäß einer Ausführungsform;
    • 2 ein Signalisierungsdiagramm, welches die Interaktion der Komponenten des Systems von 1 gemäß einer Ausführungsform illustriert;
    • 3 ein Flussdiagramm, welches Schritte eines Verfahrens zum Betreiben einer Datenkommunikationsvorrichtung gemäß einer Ausführungsform illustriert; und
    • 4 ein Flussdiagramm, welches Schritte eines Verfahrens zum Betreiben einer Trustcenter-Serveranordnung gemäß einer Ausführungsform illustriert.
  • Elemente der nachfolgenden im Detail beschriebenen Ausführungsformen, die einander entsprechen, werden mit denselben Bezugszeichen gekennzeichnet.
  • Unter einer „Blockchain“ wird hier und im Folgenden eine geordnete Datenstruktur verstanden, welche eine Vielzahl von miteinander verketteten Datenblöcken umfasst. Insbesondere wird unter einer Blockchain eine geordnete Datenstruktur verstanden, bei welcher jeder der Blöcke (außer dem ersten Block) einen Prüfiniert, beispielsweise einen Hashwert, seines Vorgängerblocks umfasst und somit anhand jedes Blocks die Gültigkeit aller seiner Vorgängerblocks geprüft und gegebenenfalls bestätigt werden kann. Das Konzept der Blockchain wurde beispielsweise im Jahre 2008 in einem White Paper unter dem Pseudonym Satoshi Nakamoto zu Bitcoin beschrieben („Bitcoin: Peer-to-Peer Electronic Cash System“ (https://bitcoin.org/bitcoin.pdf)). Die darin beschriebene Blockchain besteht aus einer Reihe von Datenblöcken, in denen jeweils ein oder mehrere Einträge bzw. Transaktionen zusammengefasst und mit einer Prüfsumme in Form eines Hashwerts versehen sind. Zusätzliche Blöcke der Blockchain werden beispielsweise in einem rechenintensiven Prozess erzeugt, der auch als sogenanntes Mining bezeichnet wird. Diese zusätzlich erzeugten Blöcke werden anschließend der Blockchain hinzugefügt und über ein Netzwerk an alle Teilnehmer, bzw. Knoten des Netzwerks, verbreitet.
  • Ausführungsformen können den Vorteil haben, dass die Blockchain durch die Speicherung kryptografischer Prüfsumme, d.h. Hashwerten, des vorangehenden Blocks im jeweils nachfolgenden Block ein hohes Maß an Sicherheit gegenüber nachträglichen Manipulationen bietet. Das Verketten der Blöcke kann dann unter Verwendung dieser Root-Hashwerte überprüft werden. Jeder Block der Blockchain enthält in seinem Header den Hash des gesamten vorherigen Blockheaders. Somit wird die Reihenfolge der Blöcke eindeutig festgelegt und es entsteht eine Kettenstruktur. Durch die so implementierte Verkettung der einzelnen Blöcke miteinander wird erreicht, dass ein nachträgliches Modifizieren vorangegangener Blöcke bzw. einzelner Einträge praktisch ausgeschlossen ist, da hierfür die Hashwerte aller nachfolgenden Blöcke in kurzer Zeit ebenfalls neu berechnet werden müssten.
  • Gemäß einer Ausführungsform handelt es sich bei der Blockchain um eine Blockchain, bei der nur eine ausgewählte Gruppe von Teilnehmern eine Berechtigung zum Hinzufügen gültiger Blöcke besitzt. Eine entsprechende Berechtigung kann beispielsweise mittels einer Signatur unter Verwendung eines privaten kryptografischen Schlüssels nachgewiesen werden. Der private kryptografische Schlüssel kann zu einem asymmetrischen Schlüsselpaar gehören, zu welchem auch ein öffentlicher kryptografischer Schlüssel gehört, mit dem die Signatur geprüft werden kann. Dem asymmetrischen Schlüsselpaar kann zudem beispielsweise ein Zertifikat zugeordnet sein, welches die Berechtigung zum Erzeugen eines gültigen Blocks der Blockchain belegt. Dieses Zertifikat kann ferner einer PKI zugeordnet sein, welche die Authentizität des Zertifikats belegt. Nach einer weiteren Ausführungsform kann beispielsweise für weitere Teilnehmer, welche der ausgewählten Gruppe hinzugefügt werden sollen, ein öffentlicher Schlüssel in der Blockchain in einem Initialisierungseintrag hinterlegt werden. Anhand dieser öffentlichen Schlüssel kann geprüft werden, ob Signaturen von Blöcken und damit die entsprechenden Blöcke selbst gültig sind. Öffentliche Schlüssel ursprünglicher Teilnehmer der ausgewählten Gruppe können beispielsweise in einem Genesisblock der Blockchain hinterlegt sein.
  • Bei der vorliegenden von einer der Zentralbank verwalteten Blockchain handelt es sich beispielsweise um eine öffentliche Blockchain, welche auf Blockchain-Servern der Zentralbank verwaltet wird. Beispielsweise erfolgt ein Eintragen neuer Blöcke ausschließlich durch diese von der Zentralbank verwalteten Blockchain-Server. In diesem Fall können beispielsweise rechenintensiven Prozesse bei Hinzufügen zusätzlicher Blöcke entfallen. Beispielsweise ist für ein Hinzufügen zusätzlicher Blöcke lediglich eine Signatur mit einem der Zentralbank zugeordneten Signaturschlüssel notwendig.
  • Ein Trustcenter stellt eine vertrauenswürdige dritte Instanz („Trusted Third Party“) dar, welche in elektronischen Kommunikationsprozessen die jeweilige Identität des Kommunikationspartners bescheinigen kann. Beispielsweise kann bei der elektronischen Kommunikation im Zusammenhang mit elektronischen Signaturen ein Trustcenter Zertifikate ausstellen, anhand derer die Identität der Kommunikationspartner bescheinigt werden können.
  • Unter einem „Kommunikationsinterface“ bzw. einer „Kommunikationsschnittstelle“ wird hier beispielsweise eine Schnittstelle verstanden, über die Daten empfangen und gesendet werden können, wobei das Kommunikationsinterface kontaktbehaftet oder kontaktlos konfiguriert sein kann.
  • Eine Kommunikation kann beispielsweise über ein Netzwerk erfolgen. Unter einem „Netzwerk“ wird hier jedes Übertragungsmedium mit einer Anbindung zur Kommunikation verstanden, insbesondere eine lokale Verbindung oder ein lokales Netzwerk, insbesondere ein Local Area Network (LAN), ein privates Netzwerk, insbesondere ein Intranet, und ein digitales privates Netzwerk (Virtual Private Network - VPN). Beispielsweise kann ein Computersystem eine Standardfunkschnittstelle zur Anbindung an ein WLAN aufweisen. Ferner kann es sich um ein öffentliches Netzwerk, wie beispielsweise das Internet handeln. Je nach Ausführungsform kann diese Verbindung auch über ein Mobilfunknetz hergestellt werden.
  • Unter einem „Prozessor“ wird hier und im Folgenden eine Logikschaltung verstanden, die zur Ausführung von Programminstruktionen dient. Die Logikschaltung kann auf einem oder mehreren diskreten Bauelementen implementiert sein, insbesondere auf einem Chip. Ein Prozessor umfasst beispielsweise ein Rechenwerk, ein Steuerwerk, Register und Datenleitungen zur Kommunikation mit anderen Komponenten. Insbesondere wird unter einem „Prozessor“ ein Mikroprozessor oder ein Mikroprozessorsystem aus mehreren Prozessorkernen und/oder mehreren Mikroprozessoren verstanden. Der Prozessor ist ausgebildet, Programminstruktionen auszuführen, die beispielsweise in einem Speicher gespeichert sind, um die hierein beschriebenen Operationen und Verfahren auszuführen.
  • Unter einem „Speicher“ wird hier insbesondere ein nichtflüchtiger Speicher verstanden. Unter einem „nichtflüchtigen Speicher“ wird hier beispielsweise ein elektronischer Speicher zur dauerhaften Speicherung von Daten verstanden. Ein nichtflüchtiger Speicher kann als nichtänderbarer Speicher konfiguriert sein, der auch als Read-Only Memory (ROM) bezeichnet wird, oder als änderbarer Speicher, der auch als Non-Volatile Memory (NVM) bezeichnet wird. Insbesondere kann es sich hierbei um ein EEPROM, beispielsweise ein Flash-EEPROM, kurz als Flash bezeichnet, handeln. Ein nichtflüchtiger Speicher zeichnet sich dadurch aus, dass die darauf gespeicherten Daten auch nach Abschalten der Energieversorgung erhalten bleiben.
  • Unter einem „geschützten Speicherbereich“ wird hier ein Bereich eines elektronischen Speichers verstanden, auf den ein Zugriff, das heißt ein Lesezugriff oder ein Schreibzugriff, nur über einen Prozessor eines Sicherheitselements möglich ist. Beispielsweise ist auf den geschützten Speicherbereich kein externer Zugriff möglich, d.h. Daten können hierher weder von außen eingebracht werden, noch nach außen ausgegeben werden. Beispielsweise können Daten über den Prozessor nach außen aus den geschützten Speicherbereich ausgelesen werden. Beispielsweise können Daten über den Prozessor von außen in den geschützten Speicherbereich eingebracht werden. Nach Ausführungsformen ist der Zugriff von dem bzw. über den mit dem Speicher gekoppelten Prozessor nur dann möglich, wenn eine hierzu erforderliche Bedingung erfüllt ist. Hierbei kann es sich zum Beispiel um eine kryptografische Bedingung, insbesondere eine erfolgreiche Authentisierung und/oder eine erfolgreiche Berechtigungsprüfung, handeln. Eine solche Prüfung kann beispielsweise auf einer elektronischen Signatur mit einem Signaturschlüssel beruhen.
  • Asymmetrische Schlüsselpaare werden für eine Vielzahl von Kryptosystemen eingesetzt und spielen auch bei der Signatur elektronischer Daten eine wichtige Rolle. Ein asymmetrisches Schlüsselpaar besteht aus einem öffentlichen Schlüssel, welcher zur Ver- und/oder Entschlüsselung von Daten verwendet wird und an Dritte weitergegeben werden darf, sowie einem privaten Schlüssel, welcher zur Ver- und/oder Entschlüsselung von Daten verwendet wird und im Regelfall geheim gehalten werden muss. Der öffentliche Schlüssel ermöglicht es jedermann, Daten für den Inhaber des privaten Schlüssels zu verschlüsseln und digitale mit dem privaten Schlüssel erstellte Signaturen zu prüfen. Ein privater Schlüssel ermöglicht es seinem Inhaber, mit dem öffentlichen Schlüssel verschlüsselte Daten zu entschlüsseln oder digitale Signaturen zu erstellen. Eine mit einem privaten Schlüssel erstellte Signatur kann mit dem zugehörigen öffentlichen Schlüssel verifiziert werden.
  • Die Erstellung einer digitalen Signatur, im Folgenden auch lediglich als „Signatur“ bezeichnet, ist ein kryptografisches Verfahren, bei dem zu beliebigen Daten ein weiterer Datenwert, welcher als „Signatur“ bezeichnet wird, berechnet wird. Bei einer Signatur kann es sich zum Beispiel um eine mit einem privaten kryptografischen Schlüssel verschlüsselten Hashwert der Ausgangsdaten handeln.
  • Unter eine Sicherheitselement wird hier beispielsweise eine elektronische Komponente verstanden, welche einen Prozessor und einen Speicher umfasst, und auf welche nur bestimmte vordefinierte Zugriffe ermöglicht werden. Beispielsweise können nur bestimmte Datenwerte, welche etwa in bestimmten Bereichen des Speichers abgelegt sind, ausgelesen werden. Beispielsweise können in einem geschützten Speicherbereich abgelegt Datenwerte nicht ausgelesen werden. Beispielsweise ist zum Schreiben eines Datenwerts in den Speicher des Sicherheitselements eine digitale Signatur notwendig, deren Prüfschlüssel in dem Sicherheitselement hinterlegt ist. Beispielsweise besitzt nur der Prozessor Schreibrechte zum Schreiben von Daten in einen geschützten Speicherbereich.
  • Das Sicherheitselement stellt ferner beispielsweise kryptografische Kernroutinen in Form von kryptografischen Programminstruktionen mit kryptografischen Algorithmen für Signaturerstellung und/oder -prüfung, Schlüsselgenerierung, und/oder Zufallszahlengenerierung bereit und kann ferner als sicherer Speicher für kryptografische Schlüssel dienen.
  • Beispielsweise sind zumindest Teile des Sicherheitselements signiert. Vor einer Nutzung des Sicherheitselements wird geprüft, ob die Signatur bzw. die Signaturen, valide sind. Wenn eine der Signaturen nicht valide ist, wird die Nutzung des Sicherheitselements beispielsweise gesperrt.
  • Beispielsweise weist das Sicherheitselement physikalisch beschränkte Zugriffsmöglichkeiten auf. Zudem kann das Sicherheitselement zusätzliche Maßnahmen gegen Missbrauch aufweisen, insbesondere gegen unberechtigte Zugriffe auf Daten im Speicher des Sicherheitselement. Beispielsweise umfassen die Mittel zum Schutz des Sicherheitselements gegen unbefugte Manipulationen mechanische Mittel, die z.B. das Öffnen des Sicherheitselements oder seiner Teile verhindern sollen, oder die bei dem Versuch eines Eingriffs in das Sicherheitselement dieses unbrauchbar machen, beispielsweise indem ein Datenverlust eintritt. Beispielsweise können hierzu zumindest Teile des Sicherheitselements in ein Material eingeschlossen, eingegossen und/oder einlaminiert sein, dessen versuchte Entfernung zu einer unvermeidlichen Zerstörung der entsprechenden Teile des Sicherheitselements führt.
  • 1 zeigt ein System 100 zum nachverfolgbaren Durchführen von elektronischen bargeldlosen Zahlungen zwischen einer ersten Datenkommunikationsvorrichtung 110 eines zahlungspflichtigen Benutzers 110a und einer zweiten Datenkommunikationsvorrichtung 120 eines Zahlungsempfängers. Bei der ersten und/oder der zweiten Datenkommunikationsvorrichtung 110, 120 kann es sich jeweils um eine mobile und tragbare Datenkommunikationsvorrichtung 110, 120, insbesondere um ein Smartphone 110, 120 handeln. Bei den im Folgenden beschriebenen Ausführungsformen handelt es sich bei den Datenkommunikationsvorrichtungen 110, 120 exemplarisch um Smartphones 110, 120.
  • Bei der in 1 dargestellten Ausführungsform umfassen das Smartphone 110 des zahlungspflichtigen Benutzers 110a und das Smartphone 120 des Zahlungsempfängers jeweils einen oder mehrere Prozessoren 111, 121, ein Kommunikationsinterface 113, 123 zur drahtlosen und/oder drahtgebundenen Kommunikation über ein Kommunikationsnetzwerk sowie einen Speicher 115, 125 zum Speichern von elektronischen Daten. Die Smartphones 110, 120 können jeweils ein Sicherheitselement, z.B. eine virtuelle oder physikalische SIM-Karte umfassen, welches ausgebildet ist, sicherheitskritische Daten zu speichern und/oder sicherheitskritische Operationen, insbesondere kryptografische Operationen durchzuführen.
  • Wie in 1 dargestellt, ist der Prozessor 111, 121 des jeweiligen Smartphones 110, 120 ausgebildet, eine Payment-Applikation 111a, 121a und eine ID-Applikation bzw. Ausweis-Applikation 111b, 121b auszuführen, deren Funktion und Zusammenwirken untereinander und mit den anderen Komponenten des Systems 100 nachstehend unter weiterer Bezugnahme auf 2 detailliert beschrieben wird.
  • Neben dem Smartphone 110 des zahlungspflichtigen Benutzers 110a und dem Smartphone 120 des Zahlungsempfängers umfasst das System 100 eine Trustcenter-Serveranordnung 130, einen ID-Ledger 140 für selbstbestimmte Identitäten (Self-Sovereign Identity (SSI); daher in 1 auch als „SSI-Ledger“ 140 bezeichnet), einen Geld-Ledger 150, beispielweise eine Blockchain 150, und eine Zentralbank bzw. einen Zentralbankserver 160 zum Verwalten des Geld-Ledger 150. Die Trustcenter-Serveranordnung 130 kann einen oder mehrere Server umfassen, mit einem oder mehreren Prozessoren 131, einem Kommunikationsinterface 133 zur drahtlosen und/oder drahtgebundenen Kommunikation über ein Kommunikationsnetzwerk sowie einem Speicher 135 zum Speichern von elektronischen Daten.
  • Wie in 1 dargestellt, ist der wenigstens eine Prozessor 131 der Trustcenter-Serveranordnung 130 ausgebildet, einen Payment-Agenten 131a (bzw. Payment-Dienst 131a) und einen ID-Agenten 131b (bzw. ID-Dienst 131b) auszuführen, deren Funktion und Zusammenwirken untereinander und mit den anderen Komponenten des Systems 100 nachstehend unter weiterer Bezugnahme auf 2 detailliert beschrieben wird.
  • Der Geld-Ledger 150 kann beispielsweise auf einem oder mehreren Blockchain-Servern implementiert sein. Mit anderen Worten: die Blockchain-Server können Teil eines Geld-Ledger-Netzwerks 150 sein und somit Blockchain-Knoten des Geld-Ledgers 150 sein. Die Blockchain-Server und/oder der Geld-Ledger 150, d.h. das Blockchain-Netzwerk 150 können beispielsweise von einer Zentralbank 160 verwaltet werden. Handelt es sich bei der Zentralbank 160 um eine Zentralbank 160, welcher mehrere Länder angehören, kann der Geld-Ledger 150 beispielsweise ein oder mehrere Blockchain-Server pro Land umfassen.
  • 2 illustriert die Interaktion der Komponenten des in 1 dargestellten Systems 100 gemäß einer Ausführungsform.
  • Der zahlungspflichtige Benutzer 110a möchte mittels seines Smartphones 110 dem Zahlungsempfänger über dessen Smartphone 120 einen bestimmten Betrag bezahlen. Hierzu startet in Schritt 201 von 2 der Benutzer 110a auf seinem Smartphone 110 die Payment-Applikation 111a (in 2 als „Payment App“ bezeichnet).
  • In der in 2 dargestellten Ausführungsform überprüft die vom Prozessor 111 implementierte Payment-Applikation 111a zunächst die Höhe des zu bezahlenden Betrags. Falls dieser Betrag höher als ein Schwellenwert ist (beispielsweise ein gesetzlich festgelegter Schwellenwert), führt das Smartphone 110 die in 2 dargestellten weiteren Schritte durch (Schritt 203 von 2). Andernfalls, d.h. falls der zu bezahlende Betrag nicht höher als der Schwellenwert ist, kann die Bezahltransaktion ohne das Trustcenter 130 durchgeführt und in im Wesentlichen bekannter Art und Weise auf dem Geld-Ledger 150 verbucht werden. Erfindungsgemäß sind jedoch auch Ausführungsformen vorgesehen, bei denen diese Prüfung entfällt, und die nachstehend beschriebenen Schritte unabhängig von der Höhe des zu zahlenden Betrags durchgeführt werden.
  • Da bei dem in 2 gezeigten Beispiel der zu bezahlenden Betrag größer als der Schwellenwert ist, generiert die von dem Prozessor 111 implementierte Payment-Applikation 111a beim Schritt 205 von 2 eine Anfrage und sendet diese über die Kommunikationsschnittstelle 113 an das Trustcenter 130, insbesondere den Payment-Agenten 131a (in 2 als „TSE-Agent“ 131a gekennzeichnet) des Trustcenters 130, um eine vom Trustcenter 130 digital signierte Transaktions-ID zu erhalten. In Reaktion auf die Anfrage in Schritt 205 sendet der Payment-Agent 131a seinerseits beim Schritt 207 von 2 eine Anfrage an die Payment-Applikation 111a nach der Transaktions-ID und einer Dezentralen-ID für den Benutzer 110a des Smartphones 110. In einer Ausführungsform kann die Transaktions-ID von der Payment-Applikation 111a das Smartphones generiert werden.
  • Bei den innerhalb des Smartphones 110 ablaufenden Schritten 209 von 2 sendet die Payment-Applikation 111a zunächst eine Anfrage an die ID-Applikation 111b und erhält von dieser als Antwort die Dezentrale-ID (DID; im Englischen auch als „Decentralized Identifier“ bekannt) des zahlungspflichtigen Benutzers 110a des Smartphones 110.
  • Beim Schritt 210 von 2 sendet die Payment-Applikation 111a des Smartphones 110 die von der ID-Applikation 111b erhaltene DID und die Transaktions-ID an den Payment-Agenten 131a des Trustcenters 130.
  • Der Payment-Agent 131a des Trustcenters 130 sendet beim Schritt 211 von 2 eine Anfrage nach „User-Credentials“ (bzw. Benutzerinformationen) des Benutzers 110a an den ID-Agenten 131b des Trustcenters 130, wobei die Anfrage die von der ID-Applikation 111b des Smartphones 110 erhaltene DID enthält. Der ID-Agent 131b dient im Wesentlichen zur automatischen Prüfung von Identitäten in dem SSI-Ledger (bzw. ID-Ledger) 140, der auf der „Distributed Ledger Technology (DLT)“ basiert.
  • Beim Schritt 213 von 2 sendet der ID-Agent 131b des Trustcenters 130 eine Anfrage nach den User-Credentials an die ID-Applikation 111b des Smartphones 110, d.h. nach den Benutzerinformationen zur Identitätsfeststellung des Benutzers 110a des Smartphones 110 mittels des SSI-Ledgers 140. Dabei enthält die Anfrage die ursprünglich von der ID-Applikation 111b erhaltene DID.
  • Beim Schritt 215 von 2 signiert die ID-Applikation 111b des Smartphones 110 die User-Credentials bzw. Benutzerinformationen mit einem privaten Schlüssel des Smartphones 110. Ein solcher privater Schlüssel kann beispielsweise in einem gesicherten Speicherbereich eines Sicherheitselements, beispielsweise einer virtuellen oder physikalischen SIM-Karte des Smartphones 110 hinterlegt sein. Wie bereits vorstehend beschrieben, können sicherheitskritische kryptografische Operationen der ID-Applikation 111b und/oder Payment-Applikation 111a in einem solchen Sicherheitselement durchgeführt werden.
  • Beim Schritt 217 beweist die ID-Applikation 111b des Smartphones 110 mittels eines Zero-Knowledge-Proofs (ZKP; Null-Wissen-Beweis) die Echtheit der beim Schritt 215 übermittelten User-Credentials bzw. Benutzerinformationen.
  • Beim Schritt 219 von 2 beschafft sich der ID-Agent 131b des Trustcenters 130 Daten von dem ID-Ledger 140 zur Bestätigung bzw. Verifizierung des ZKP von Schritt 217, indem diese Daten von dem ID-Ledger 140 herunter geladen werden (Schritt 221 von 2).
  • Nach der Bestätigung des ZKP durch den ID-Agent 131b des Trustcenters 130 (aufgrund derer der ID-Agent 131a den User-Credentials vertrauen kann), sendet beim Schritt 223 von 2 der ID-Agent 131b des Trustcenters 130 die User-Credentials an den Payment-Agenten 131a. Daraufhin speichert der Payment-Agent 131a die signierte Transaktions-ID zusammen mit den User-Credentials in einer im Speicher 135 implementierten Datenbank 135a (Schritt 225 von 2). In einer Ausführungsform kann der Payment-Agent 131a hierfür noch eine Identifikationsnummer vergeben und diese mit der Transaktions-ID verknüpfen.
  • Beim Schritt 227 sendet der Payment-Agent 131a des Trustcenters 130 die signierte Transaktions-ID an die Payment-Applikation 111a des Smartphones 110. Somit stellt der Schritt 227 letztendlich die Antwort des Trustcenters 130 auf die in Schritt 205 angefragte signierte Transaktions-ID dar.
  • Zum Abschließen der Bezahltransaktion sendet die Payment-Applikation 111a beim Schritt 229 von 2 die Transaktionsdaten, d.h. insbesondere die Transaktions-ID und den Betrag, sowie die Signatur der Transaktions-ID an den Geld-Ledger 150, wo diese Daten verbucht bzw. abgelegt werden, um bei Bedarf dem Zentralbankserver 160 für eine Nachverfolgung zur Verfügung zu stehen. Der Bezahlvorgang ist damit abgeschlossen. Optional kann zusätzlich auch die Identität des Zahlungsempfängers, d.h. des Benutzers des weiteren Smartphones 120 mit aufgenommen werden, indem sich die Payment-Applikation 111a auch die DID des Benutzers des weiteren Smartphones 120 verschafft. In dem Fall würde der Identity-Agent 131b des Trustcenters 130 zwei getrennte Verbindungen aufbauen, nämlich zum einen zum Smartphone 110 des zahlungspflichtigen Benutzers 110a und zum anderen zum Smartphone des Zahlungsempfängers.
  • 3 zeigt ein Flussdiagramm, welches Schritte eines Verfahrens 300 zum Betreiben der Datenkommunikationsvorrichtung 110 gemäß einer Ausführungsform illustriert. Das Verfahren 300 umfasst die folgenden Schritte:
    • Senden 301 einer Transaktions-ID und einer dezentralen Identität, DID, des Benutzers 110a der Datenkommunikationsvorrichtung 110 von der Payment-Applikation 111a an einen Payment-Agenten 131a der Trustcenter-Serveranordnung 130;
    • Senden 303 von signierten User-Credentials des Benutzers 110a der Datenkommunikationsvorrichtung 110 von der ID-Applikation 111b an einen ID-Agenten 131b der Trustcenter-Serveranordnung 130, in Reaktion auf eine die DID enthaltende Anfrage des ID-Agenten 131b der Trustcenter-Serveranordnung 130;
    • Empfangen 305 einer Signatur der Transaktions-ID von dem Payment-Agenten 131b der Trustcenter-Serveranordnung 130 durch die Payment-Applikation 111a; und
    • Senden 307 der Signatur der Transaktions-ID von der Payment-Applikation 111a an den Geld-Ledger 150, um die elektronische Bezahltransaktion mit der Signatur der Transaktions-ID auf dem Geld-Ledger 150 zu verbuchen.
  • Figure 4 zeigt ein Flussdiagramm, welches Schritte eines Verfahrens 400 zum Betreiben der Trustcenter-Serveranordnung 130 gemäß einer Ausführungsform illustriert.
    Das Verfahren 400 umfasst die folgenden Schritte:
    • Empfangen 401 einer Transaktions-ID und der dezentralen Identität, DID, des Benutzers 110a der Datenkommunikationsvorrichtung 110 von einer Payment-Applikation 111a der Datenkommunikationsvorrichtung 110 durch den Payment-Agenten 131a;
    • Erhalten 403 von signierten User-Credentials des Benutzers 110a der Datenkommunikationsvorrichtung 110 von einer ID-Applikation 111b der Datenkommunikationsvorrichtung 110 durch den ID-Agenten 131b, in Reaktion auf eine die DID enthaltende Anfrage des Payment-Agenten 131a nach den User-Credentials des Benutzers 110a der Datenkommunikationsvorrichtung 110;
    • Erhalten 405 der User-Credentials des Benutzers 110a der Datenkommunikationsvorrichtung 110 durch den Payment-Agenten 131a;
    • Speichern 407 der User-Credentials des Benutzers 110a der Datenkommunikationsvorrichtung 110 zusammen mit der Transaktions-ID durch den Payment-Agenten 131a in dem Speicher 135; und
    • Senden 409 der signierten Transaktions-ID von dem Payment-Agenten 131a an die Payment-Applikation 111a der Datenkommunikationsvorrichtung 110, um die elektronische Bezahltransaktion mit der Signatur der Transaktions-ID auf dem Geld-Ledger 150 verbuchen zu können.
  • BEZUGSZEICHENLISTE
    • 100
    Elektronisches Bezahlsystem
    110
    Datenkommunikationsvorrichtung des Zahlungspflichtigen
    110a
    Zahlungspflichtiger Benutzer
    111
    Prozessor
    111a
    Payment-Applikation
    111b
    ID-Applikation
    113
    Kommunikations-Interface
    115
    Speicher
    120
    Datenkommunikationsvorrichtung des Zahlungsempfängers
    121
    Prozessor
    121a
    Payment-Applikation
    121b
    ID-Applikation
    123
    Kommunikations-Interface
    125
    Speicher
    130
    Trustcenter-Serveranordnung
    131
    Prozessor
    131a
    Payment-Agent
    131b
    ID-Agent
    133
    Kommunikations-Interface
    135
    Speicher
    135a
    Datenbank
    140
    ID-Ledger
    150
    Geld-Ledger
    160
    Zentralbank

Claims (12)

  1. Datenkommunikationsvorrichtung (110) zum Ausführen einer elektronischen Bezahltransaktion, wobei die Datenkommunikationsvorrichtung (110) umfasst: wenigstens einen Prozessor (111), der ausgebildet ist, eine Payment-Applikation (111a) und eine ID-Applikation (111b) auszuführen; und ein Kommunikationsinterface (113), das ausgebildet ist, mit einer Trustcenter-Serveranordnung (130) und einem Geld-Ledger (150) zu kommunizieren; wobei die Payment-Applikation (111a) ausgebildet ist, eine Transaktions-ID und eine dezentrale Identität, DID, eines Benutzers (110a) der Datenkommunikationsvorrichtung (110) an einen Payment-Agenten (131a) der Trustcenter-Serveranordnung (130) zu senden; wobei die ID-Applikation (111b) ausgebildet ist, in Reaktion auf eine die DID enthaltende Anfrage eines ID-Agenten (131b) der Trustcenter-Serveranordnung (130), signierte User-Credentials des Benutzers (110a) der Datenkommunikationsvorrichtung (110) an den ID-Agenten (131b) der Trustcenter-Serveranordnung (130) zu senden; wobei die Payment-Applikation (111a) ferner ausgebildet ist, eine Signatur der Transaktions-ID von dem Payment-Agenten (131a) der Trustcenter-Serveranordnung (130) zu empfangen und die Signatur der Transaktions-ID an den Geld-Ledger (150) zu senden, um die elektronische Bezahltransaktion mit der Signatur der Transaktions-ID auf dem Geld-Ledger (150) zu verbuchen.
  2. Datenkommunikationsvorrichtung (110) nach Anspruch 1, wobei die Payment-Applikation zum Ausführen einer weiteren elektronischen Bezahltransaktion, deren Betrag kleiner als ein Schwellenwert ist, ausgebildet ist, eine weitere Transaktions-ID der weiteren elektronischen Bezahltransaktion ohne eine Signatur der weiteren Transaktions-ID an den Geld-Ledger (150) zu senden, um die elektronische Bezahltransaktion mit der weiteren Transaktions-ID und ohne eine Signatur der weiteren Transaktions-ID auf dem Geld-Ledger (150) zu verbuchen.
  3. Datenkommunikationsvorrichtung (110) nach Anspruch 1 oder 2, wobei die Payment-Applikation (111a) ferner ausgebildet ist, die Transaktions-ID zu generieren und/oder auf Anfrage die DID des Benutzers 110a der Datenkommunikationsvorrichtung (110) von der ID-Applikation (111b) zu erhalten.
  4. Datenkommunikationsvorrichtung (110) nach einem der vorhergehenden Ansprüche, wobei die ID-Applikation (111b) ferner ausgebildet ist, in Reaktion auf die Anfrage des ID-Agenten (131b) der Trustcenter-Serveranordnung (130), Zero-Knowledge-Proof-Daten an den ID-Agenten (131b) der Trustcenter-Serveranordnung (130) zu senden, um die signierten User-Credentials des Benutzers (110a) der Datenkommunikationsvorrichtung (110) zu verifizieren.
  5. Datenkommunikationsvorrichtung (110) nach einem der vorhergehenden Ansprüche, wobei die Payment-Applikation (111a) ferner ausgebildet ist, eine weitere DID eines weiteren Benutzers einer weiteren Datenkommunikationsvorrichtung (120) zusammen mit der Transaktions-ID und der DID des Benutzers (110a) der Datenkommunikationsvorrichtung (110) an den Payment-Agenten (131a) der Trustcenter-Serveranordnung (130) zu senden.
  6. Datenkommunikationsvorrichtung (110) nach einem der vorhergehenden Ansprüche, wobei die Datenkommunikationsvorrichtung (110) eine mobile und tragbare Datenkommunikationsvorrichtung (110), insbesondere ein Smartphone (110) ist.
  7. Verfahren (300) zum Betreiben einer Datenkommunikationsvorrichtung (110) zum Ausführen einer elektronischen Bezahltransaktion, wobei die Datenkommunikationsvorrichtung (110) wenigstens einen Prozessor (111) umfasst, der ausgebildet ist, eine Payment-Applikation (111a) und eine ID-Applikation (111b) auszuführen, sowie ein Kommunikationsinterface (113), das ausgebildet ist, mit einer Trustcenter-Serveranordnung (130) und einem Geld-Ledger (150) zu kommunizieren, wobei das Verfahren (300) umfasst: Senden (301) einer Transaktions-ID und einer dezentralen Identität, DID, eines Benutzers (110a) der Datenkommunikationsvorrichtung (110) von der Payment-Applikation (111a) an einen Payment-Agenten (131a) der Trustcenter-Serveranordnung (130); Senden (303) von signierten User-Credentials des Benutzers (110a) der Datenkommunikationsvorrichtung (110) von der ID-Applikation (111b) an einen ID-Agenten (131b) der Trustcenter-Serveranordnung (130), in Reaktion auf eine die DID enthaltende Anfrage des ID-Agenten (131b) der Trustcenter-Serveranordnung (130); Empfangen (305) einer Signatur der Transaktions-ID von dem Payment-Agenten (131a) der Trustcenter-Serveranordnung (130) durch die Payment-Applikation (111a); und Senden (307) der Signatur der Transaktions-ID von der Payment-Applikation (111a) an den Geld-Ledger (150), um die elektronische Bezahltransaktion mit der Signatur der Transaktions-ID auf dem Geld-Ledger (150) zu verbuchen.
  8. Trustcenter-Serveranordnung (130) zum Ausführen einer elektronischen Bezahltransaktion, wobei die Trustcenter-Serveranordnung (130) umfasst: wenigstens einen Prozessor (131), der ausgebildet ist, einen Payment-Agenten (131a) und einen ID-Agenten (131b) auszuführen; ein Kommunikationsinterface (133), das ausgebildet ist, mit einer Datenkommunikationsvorrichtung (110) zu kommunizieren; und einen Speicher (135) zum Speichern von elektronischen Daten; wobei der Payment-Agent (131a) ausgebildet ist, eine Transaktions-ID und eine dezentrale Identität, DID, eines Benutzers (110a) der Datenkommunikationsvorrichtung (110) von einer Payment-Applikation (111a) der Datenkommunikationsvorrichtung (110) zu empfangen; wobei der ID-Agent (131b) ausgebildet ist, in Reaktion auf eine die DID enthaltende Anfrage des Payment-Agenten (131a) nach User-Credentials des Benutzers (110a) der Datenkommunikationsvorrichtung (110), die signierten User-Credentials des Benutzers (110a) der Datenkommunikationsvorrichtung (110) von einer ID-Applikation (111b) der Datenkommunikationsvorrichtung (110) zu erhalten; wobei der Payment-Agent (131a) ferner ausgebildet ist, die User-Credentials des Benutzers (110a) der Datenkommunikationsvorrichtung (110) zu erhalten und zusammen mit der Transaktions-ID in dem Speicher (135) zu speichern; und wobei der Payment-Agent (131a) ferner ausgebildet ist, die Transaktions-ID zu signieren und die signierte Transaktions-ID an die Payment-Applikation (111a) der Datenkommunikationsvorrichtung (110) zu senden, um die elektronische Bezahltransaktion mit der Signatur der Transaktions-ID auf einem Geld-Ledger (150) verbuchen zu können.
  9. Trustcenter-Serveranordnung (130) nach Anspruch 8, wobei das Kommunikationsinterface (133) ferner ausgebildet ist, mit einem ID-Ledger (140) zu kommunizieren und wobei der ID-Agent (131b) ferner ausgebildet ist, Zero-Knowledge-Proof-Daten von der ID-Applikation (111b) der Datenkommunikationsvorrichtung (110) zu erhalten und mittels der Zero-Knowledge-Proof-Daten und dem ID-Ledger (140) die signierten User-Credentials des Benutzers (110a) der Datenkommunikationsvorrichtung (110) zu verifizieren.
  10. Verfahren (400) zum Betreiben einer Trustcenter-Serveranordnung (130) zum Ausführen einer elektronischen Bezahltransaktion, wobei die Trustcenter-Serveranordnung (130) wenigstens einen Prozessor (131) umfasst, der ausgebildet ist, einen Payment-Agenten (131a) und einen ID-Agenten (131b) auszuführen, ein Kommunikationsinterface (133), das ausgebildet ist, mit einer Datenkommunikationsvorrichtung (110) zu kommunizieren, sowie einen Speicher (135) zum Speichern von elektronischen Daten, wobei das Verfahren (400) umfasst: Empfangen (401) einer Transaktions-ID und einer dezentralen Identität, DID, eines Benutzers (110a) der Datenkommunikationsvorrichtung (110) von einer Payment-Applikation (111a) der Datenkommunikationsvorrichtung (110) durch den Payment-Agenten (131a); Erhalten (403) von signierten User-Credentials des Benutzers (110a) der Datenkommunikationsvorrichtung (110) von einer ID-Applikation (111b) der Datenkommunikationsvorrichtung (110) durch den ID-Agenten (131b), in Reaktion auf eine die DID enthaltende Anfrage des Payment-Agenten (131a) nach den User-Credentials des Benutzers (110a) der Datenkommunikationsvorrichtung (110); Erhalten (405) der User-Credentials des Benutzers (110a) der Datenkommunikationsvorrichtung (110) durch den Payment-Agenten (131a); Speichern (407) der User-Credentials des Benutzers (110a) der Datenkommunikationsvorrichtung (110) zusammen mit der Transaktions-ID durch den Payment-Agenten (131a) in dem Speicher (135); und Senden (409) der signierten Transaktions-ID von dem Payment-Agenten (131a) an die Payment-Applikation (111a) der Datenkommunikationsvorrichtung (110), um die elektronische Bezahltransaktion mit der Signatur der Transaktions-ID auf einem Geld-Ledger (150) verbuchen zu können.
  11. System (100) zum Ausführen einer elektronischen Bezahltransaktion, wobei das System umfasst: eine Vielzahl von Datenkommunikationsvorrichtungen (110) nach einem der Ansprüche 1 bis 6; und eine Trustcenter-Serveranordnung (130) nach einem der Ansprüche 8 oder 9.
  12. Computerprogramm mit einem Programmcode zum Ausführen des Verfahrens (300) nach Anspruch 7 und/oder des Verfahrens (400) nach Anspruch 10, wenn das Computerprogramm auf einem Computer ausgeführt wird.
DE102022109813.3A 2022-04-22 2022-04-22 Vorrichtungen, System und Verfahren zum elektronischen bargeldlosen Bezahlen Pending DE102022109813A1 (de)

Priority Applications (2)

Application Number Priority Date Filing Date Title
DE102022109813.3A DE102022109813A1 (de) 2022-04-22 2022-04-22 Vorrichtungen, System und Verfahren zum elektronischen bargeldlosen Bezahlen
PCT/EP2023/057540 WO2023202836A1 (de) 2022-04-22 2023-03-23 Vorrichtungen, system und verfahren zum elektronischen bargeldlosen bezahlen

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102022109813.3A DE102022109813A1 (de) 2022-04-22 2022-04-22 Vorrichtungen, System und Verfahren zum elektronischen bargeldlosen Bezahlen

Publications (1)

Publication Number Publication Date
DE102022109813A1 true DE102022109813A1 (de) 2023-10-26

Family

ID=85795312

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102022109813.3A Pending DE102022109813A1 (de) 2022-04-22 2022-04-22 Vorrichtungen, System und Verfahren zum elektronischen bargeldlosen Bezahlen

Country Status (2)

Country Link
DE (1) DE102022109813A1 (de)
WO (1) WO2023202836A1 (de)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180316507A1 (en) 2016-04-30 2018-11-01 Civic Technologies, Inc. Methods and systems of revoking an attestation transaction using a centralized or distributed ledger
WO2022155627A1 (en) 2021-01-14 2022-07-21 American Express Travel Related Services Co., Inc. Biometric-based identity verificaton using zero-knowledge proofs

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AU2017225932C1 (en) * 2016-02-29 2021-06-24 Securekey Technologies Inc. Systems and methods for distributed identity verification
US10880089B2 (en) * 2017-03-15 2020-12-29 NuID, Inc. Methods and systems for universal storage and access to user-owned credentials for trans-institutional digital authentication
US11366910B2 (en) * 2018-12-27 2022-06-21 Eli Talmor Method and system for secure applications using blockchain
EP3965040A1 (de) * 2020-09-03 2022-03-09 Sicpa Holding Sa Verfahren und system zum konformen austausch von auf digitaler, auf token basierender währung

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180316507A1 (en) 2016-04-30 2018-11-01 Civic Technologies, Inc. Methods and systems of revoking an attestation transaction using a centralized or distributed ledger
WO2022155627A1 (en) 2021-01-14 2022-07-21 American Express Travel Related Services Co., Inc. Biometric-based identity verificaton using zero-knowledge proofs

Also Published As

Publication number Publication date
WO2023202836A1 (de) 2023-10-26

Similar Documents

Publication Publication Date Title
DE102018106682B4 (de) Bereitstellen einer out-of-band-verifizierung für blockchain-transaktionen
EP3596653B1 (de) Ausstellen virtueller dokumente in einer blockchain
EP3446273B1 (de) Elektronisches verfahren zur kryptographisch gesicherten überweisung eines betrags einer kryptowährung
EP4111348B1 (de) Verfahren zum direkten übertragen von elektronischen münzdatensätzen zwischen endgeräten, bezahlsystem, währungssystem und überwachungseinheit
DE112011100182B4 (de) Datensicherheitsvorrichtung, Rechenprogramm, Endgerät und System für Transaktionsprüfung
DE102019002732A1 (de) Verfahren zum direkten Übertragen von elektronischen Münzdatensätzen zwischen Endgeräten sowie Bezahlsystem
EP3993318B1 (de) Blockchain-basiertes digitales dokumentensystem
EP3814970B1 (de) Manipulationssicheres ausstellen und speichern von elektronischen urkunden
DE102021004548A1 (de) Verfahren und transaktionssystem zum übertragen von token in einem elektronischen transaktionssystems
DE202015009601U1 (de) System zur persönlichen Identifizierung und Verifizierung
DE102020004121A1 (de) Verfahren, teilnehmereinheit, transaktionsregister und bezahlsystem zum verwalten von transaktionsdatensätzen
EP4315117A1 (de) Verfahren und vorrichtung zum erzeugen, bereitstellen und weitergeben eines vertrauenswürdigen elektronischen datensatzes oder zertifikates basierend auf einem einen nutzer betreffenden elektronischen dokument
WO2022233454A1 (de) Verfahren zum registrieren eines elektronischen münzdatensatzes in einem münzregister; ein münzregister; eine teilnehmereinheit und ein computerprogrammprodukt
DE202015009562U1 (de) System zur persönlichen Identifizierung und Verifizierung
EP4111399B1 (de) Verfahren, endgerät, überwachungsinstanz sowie bezahlsystem zum verwalten von elektronischen münzdatensätzen
DE102016202262A1 (de) Verfahren und System zur Authentifizierung eines mobilen Telekommunikationsendgeräts an einem Dienst-Computersystem und mobilen Telekommunikationsendgerät
DE102022109813A1 (de) Vorrichtungen, System und Verfahren zum elektronischen bargeldlosen Bezahlen
EP4179486A1 (de) Bezahlsystem, münzregister, teilnehmereinheit, transaktionsregister, überwachungsregister und verfahren zum bezahlen mit elektronischen münzdatensätzen
DE102021129047B4 (de) Selektiv anonymisierende Überweisung einer Kryptowährung
EP4111347B1 (de) Verfahren zum direkten übertragen von elektronischen münzdatensätzen zwischen endgeräten, bezahlsystem, währungssystem und überwachungsinstanz
EP3180729B1 (de) Digitale identitäten mit fremdattributen
DE102022130483A1 (de) Verfahren zum beglaubigen eines hardware-wallets einer blockchain
DE102010026697A1 (de) Gesicherter automatisierter Austausch von Informationen zur Vertrauenswürdigkeit von Geschäfts- oder Kommunikationspartnern

Legal Events

Date Code Title Description
R012 Request for examination validly filed