DE202015009601U1

DE202015009601U1 - System zur persönlichen Identifizierung und Verifizierung

Info

Publication number: DE202015009601U1
Application number: DE202015009601.8U
Authority: DE
Original assignee: Black Gold Coin Inc
Current assignee: Black Gold Coin Inc
Priority date: 2015-03-27
Filing date: 2015-03-27
Publication date: 2018-07-24
Anticipated expiration: 2025-03-28

Abstract

System zur persönlichen Identifizierung und Verifizierung zum Überwachen und Beschränken von Transaktionen mit Kryptographie-basiertem elektronischem Geld (CBEM) (201), wobei das System umfasst:
einen zentralen Genehmigungsserver (401), der dazu eingerichtet ist, Client-Identitätsregistierungen, Client-Währungsadressen und CBEM-Transaktionen zu verarbeiten, umfassend:
- Kommunizieren (407) mit einem Client-Wallet (301), um eine oder mehrere vom Nutzer genehmigte Währungsadressen (313) bei Vorliegen von gültigen Anmeldeinformationen zur Verifizierung der persönlichen Identität (319) zu erzeugen;
- Genehmigen einer Anfrage zum Erzeugen einer oder mehrerer vom Nutzer genehmigter Währungsadressen (313) bei Vorliegen von gültigen Anmeldeinformationen zur Verifizierung der Identität (212, 319);
- Kommunizieren (409) mit dem Client-Wallet (301), um eine oder mehrere genehmigte Transaktionen zu erzeugen (311), um eine Einheit des CBEM an eine Währungsadresse bei Vorliegen von gültigen Anmeldeinformationen zur Verifizierung der Identität zu senden (220);
- Genehmigen einer oder mehrerer Transaktionen (311) zum Senden einer Einheit des CBEM an eine Währungsadresse bei Vorliegen von gültigen Anmeldeinformationen zur Verifizierung der Identität (220);
- Untersuchen einer Transaktion unter Verwendung von Transaktionskriterien, die durch eine zentrale Verwaltungsbehörde (501) oder einen Nutzer (502) definiert sind;
- Ablehnen einer Transaktion, die die Transaktionskriterien verletzt (501, 502); und
- Speichern von Transaktionsinformation (414) in einer Transaktionsdatenbank (413);
wobei das System ferner umfasst:
eine oder mehrere genehmigte Währungsadressen;
ein genehmigtes Transaktionsnetzwerk;
eine Client-Informationsdatenbank (115, 404), die kommunikativ mit dem zentralen Genehmigungsserver (401) verbunden ist;
eine Transaktionsdatenbank (413), die kommunikativ mit dem zentralen Genehmigungsserver (401) verbunden ist; und
mindestens ein Client-Gerät (414, 415), das mit einem Client-Wallet (301) versehen ist;
wobei das mindestens eine Client-Gerät (414, 415) eingerichtet ist zum:
- Erlangen einer Genehmigung von dem zentralen Genehmigungsserver zum Erzeugen einer oder mehrerer genehmigter Währungsadressen (313) durch Übermitteln von gültigen Anmeldeinformationen zur Verifizierung der Identität (212, 319); und
- Erlangen einer Genehmigung von dem zentralen Genehmigungsserver zum Erzeugen einer oder mehrerer genehmigter Transaktionen (311), um eine Einheit des CBEM an die Währungsadresse eines Empfängers zu senden, indem gültige Anmeldeinformationen zur Verifizierung der Identität übermittelt werden (220);
- Erstellen einer oder mehrerer genehmigter Transaktionen (311) zum Senden einer Einheit des CBEM an die Währungsadresse eines Empfängers durch Signieren der Transaktion mit einem privaten Client-Schlüssel, der der Währungsadresse des Senders zugeordnet ist (308).

Description

TECHNISCHER BEREICH
Die vorliegende Erfindung betrifft ein System zur persönlichen Identifizierung und Verifizierung. Insbesondere bezieht sich die vorliegende Erfindung auf ein Verfahren zur persönlichen Identifizierung und Verifizierung, ein pseudonymes System und ein Transaktionsnetzwerk zum Überwachen und Beschränken von Transaktionen eines Anmeldeinformations-Authentifizierungsprotokolls mit Verknüpfung von Kryptographie-basiertem elektronischem Geld und persönlicher Identität.
HINTERGRUND
Der Stand der Technik definiert digitale Währung oder digitales Geld. Es ist ein internetbasiertes Tauschmittel (d. h. es unterscheidet sich von einem physischen wie Banknoten und Münzen), das ähnliche Eigenschaften wie physische Währungen aufweist, jedoch sofortige Transaktionen und grenzenlose Eigentumsübertragung erlaubt.
Sowohl virtuelle Währungen als auch Kryptowährungen sind Arten digitaler Währungen, aber umgekehrt gilt das nicht. Wie herkömmliches Geld können diese Währungen verwendet werden, um reale Güter und Dienstleistungen zu kaufen. Digitale Währungen wie Bitcoin werden als „dezentrale digitale Währungen“ bezeichnet, was bedeutet, dass es keinen zentralen Kontrollpunkt für die Geldmenge gibt. (siehe Wikipedia)
Bitcoin ist das erste Kryptographie-basierte elektronische Geld, das 2008 erfunden wurde. Es wird auch als erste Kryptowährung bezeichnet. Bitcoin ist nicht nur virtuelles Geld, sondern auch ein Zahlungssystem, das aus einem dezentralen Peer-to-Peer-Transaktionsnetzwerk zur Erfassung und Verifizierung der Geldtransaktionen besteht.
Bitcoins (d. h. Einheiten von Bitcoin) werden nicht in den Client-Wallets (d. h. elektronischen Brieftaschen) einzelner Besitzer gespeichert, sondern ihre Besitzer werden in einem Public Ledger (d. h. öffentlichen Protokoll) aller Bitcoin-Transaktionen, d. h. der Blockchain, unter Verwendung von Bitcoin-Adressen der Besitzer verzeichnet. Eine Bitcoin-Adresse ist ein 160-Bit-Hash des öffentlichen Teils eines öffentlich/privaten Elliptic Curve Digital Siganture Alorithm- (ECDSA) -Schlüsselpaars. Der private Schlüssel für jede Bitcoin-Adresse wird in dem Client-Wallet des Adressbesitzers gespeichert.
Darüber hinaus sind alle Client-Wallets über das Internet miteinander verbunden und bilden Knoten eines Transaktionsnetzwerks, um die Transaktionen weiterzuleiten und zu verifizieren. Unter Verwendung von Public/Private-Key-Kryptografie kann man „signieren“ (d. h. seinen/ihren privaten Schlüssel verwenden), um eine an seiner/ihrer Bitcoin-Adresse verzeichnete Bitcoin-Menge an eine andere Bitcoin-Adresse zu senden, und im Transaktionsnetzwerk kann jeder, der seinen/ihren öffentlichen Schlüssel kennt, überprüfen, ob die Signatur gültig ist.
Seit der Erfindung von Bitcoin wurden verschiedene Kryptographie-basierte elektronische Währungen geschaffen und werden zusammen als alternative Kryptowährungen bezeichnet. Unter ihnen sind einige modifizierte Formen von Bitcoin unter Verwendung verschiedener kryptographischer Hash-Algorithmen (z. B. Litecoin) und/oder mit zusätzlichen Funktionen (z. B. CinniCoin), während einige unter Verwendung anderer Signaturtechnologien erstellt sind (z. B. CryptoNote).
Bitcoin ist absichtlich pseudonym, während alle alternativen Kryptowährungen entweder pseudonym oder anonym sind. Anonyme Kryptowährungen können leicht für Geldwäscheaktivitäten verwendet werden, da alle Sender und Empfänger von Geldtransaktionen nicht ermittelbar sind. Für pseudonyme Kryptowährung zeigte eine akademische Studie (Meiklejohn S et al. University of California, San Diego, 2013), dass Hinweise auf Interaktionen zwischen Institutionen identifiziert werden konnten, indem das Muster der Beteiligung von Bitcoin-Adressen bei empirischen Einkäufen von Waren und Dienstleistungen analysiert wurde.
Mit diesem Ansatz können möglicherweise illegale Aktivitäten auf der Ebene der Institution identifiziert werden, es ist jedoch immer noch nicht möglich, sie auf die Ebene einer einzelnen Person einzuengen. Eine neuere akademische Studie (Koshy P et al. Pennsylvania State University, 2014) hat gezeigt, dass es möglich ist, eine Bitcoin-Adresse einer IP-Adresse zuzuordnen. Dieser Ansatz ist jedoch nur für weniger als 10% der Bitcoin-Adressen anwendbar. Daher wird allgemein angenommen, dass Bitcoin und andere alternative Kryptowährungen für illegale Aktivitäten wie Geldwäsche verwendet werden können (Bryans D, Indiana Law Journal, 89 (1): 441, 2014).
Diese pseudonyme/anonyme Eigenschaft macht Bitcoin und alternative Kryptowährungen zu attraktiven Zielen für Hacker und Diebe. Zum Beispiel beantragte im Februar 2014 die Firma Mt. Gox, die zu dieser Zeit die weltweit größte Bitcoin-Börse war, Konkurs, da das Unternehmen ständig gehackt wurde, was zu einem Verlust von 850.000 Bitcoins (im Wert von etwa 480 Millionen US-Dollar) führte.
Im Januar 2015 wurde die slowenische Bitcoin-Börse Bitstamp, die zu dieser Zeit die drittgrößte Bitcoin-Börse der Welt war, gehackt, und weniger als 19.000 BTC (im Wert von etwa 5 Millionen US-Dollar) wurden gestohlen. Obwohl die Hacker/Diebe die gestohlenen Bitcoins an ihre Bitcoin-Adressen übertragen müssen, bleiben die Identitäten der meisten dieser Hacker und Diebe unbekannt.
Daher werden Diebstahlschutz-Lösungen für Bitcoin benötigt. Die Besitzrechte von Bitcoins werden durch private Schlüssel geschützt, die in dem Wallet des Nutzers gespeichert sind. Private Schlüssel können aus einer Passphrase erstellt werden. Brainwallet ist beispielsweise eine Website, die ein Werkzeug zum Erzeugen einer Bitcoin-Adresse und ihres privaten Schlüssels aus dem sha256 einer Passphrase bereitstellt. Unter Verwendung eines Passwort-Wörterbuchs könnte man die Bitcoin-Blockchain analysieren und nach aktiven Bitcoin-Adressen suchen, die aus typischen Passwörtern erzeugt wurden, und die Bitcoins von diesen Adressen mit den entsprechenden privaten Schlüsseln stehlen.
Eine einfache Diebstahlschutz-Lösung ist die Verwendung von Bitcoin-Adressen zu vermeiden, die aus typischen Passphrasen erzeugt wurden. Bei anderen Bitcoin-Adressen können Hacker die Computer oder Server von Bitcoin-Besitzern hacken, um nach Dateien zu suchen, die die Datensätze der privaten Schlüssel enthalten. Sobald diese Dateien entdeckt wurden, können Bitcoins, die an den zugehörigen Adressen gespeichert sind, leicht auf eine andere Adresse übertragen werden. Die einfachste Lösung hierfür ist, solche Dateien in einem kalten Speicher (d. h. einem Gerät, das nicht mit dem Internet verbunden ist) zu speichern oder sogar solche Dateien gar nicht zu erzeugen.
Eine weitere Möglichkeit, Bitcoins zu stehlen, besteht darin, die Hauptdatei des Wallets (d. h. die Datei „wallet.dat“) in einem Bitcoin-Wallet zu stehlen, das auf einem Computer oder Server installiert ist, der mit dem Internet verbunden ist. Robert Lipovsky (2013) berichtete von einem Online-Banking-Trojaner, der die wallet.dat-Dateien stehlen kann. Private Schlüssel sind in den wallet.dat-Dateien gespeichert und sind mit Passphrasen geschützt. Sobald die Hauptdatei des Wallets gestohlen wurde, kann die Schutz-Passphrase durch Wörterbuch-Raten, Permutationen von Wörterbuch-Wörtern oder reine Brute-Force geknackt werden.
Ein Beispiel für Lösungen für solche gestohlenen Bitcoin-Geldbörsen ist in der Patentanmeldung mit der Veröffentlichungsnummer CN103927656 (A ) mit dem Titel „Bitcoin terminal wallet with embedded, fixed collecting address and Bitcoin payment method of Bitcoin terminal wallet“ beschrieben.
Eine einfache Lösung besteht darin, Bitcoins bei einer Multisignaturadresse zu speichern, die zwei private Schlüssel zum Ausgeben der Bitcoins benötigt. Ein privater Schlüssel wird im Computergerät (z. B. einem lokalen Computer) gespeichert, während ein anderer Schlüssel in einem separaten Computergerät (z. B. einem Smartphone, einem entfernten Server) gespeichert wird, wodurch eine Zwei-Faktor-Authentifizierung für Transaktionen erzeugt wird. Eine solche Lösung ist bis zur vorliegenden Erfindung noch nicht verfügbar.
Eine weitere Lösung besteht darin, alle Bitcoin-Sender und -Empfänger identifizierbar zu machen. Die persönlichen Identitäten der Diebe oder Hacker können dann aufgedeckt werden, indem die persönlichen Identitäten der Besitzer der Bitcoin-Adressen, die die gestohlenen Bitcoins erhalten, preisgegeben werden. Eine solche Lösung ist bis zur vorliegenden Erfindung noch nicht verfügbar.
Gegenwärtig sind Anti-Geldwäsche-Lösungen (AML) für Bitcoin sehr gefragt. Damit Bitcoin-Dienste, die Unternehmen beliefern, die US-amerikanischen (FinCEN) und weltweiten Vorschriften für AML einhalten, besteht der aktuelle Ansatz in einer kombinierten Nutzung von Know-Your-Customer (KYC) und Transaktionsüberwachung. Um dies zu ermöglichen, müssen alle Händler/Kunden ihre tatsächlichen persönlichen Identitäten angeben und verifiziert werden. Dieser Ansatz leidet jedoch unter zwei Hauptproblemen. Erstens wird dieser Ansatz hauptsächlich von Unternehmen übernommen, die legale Dienstleistungen anbieten. Daher können AML-Aktivitäten mit Bitcoins immer noch weltweit stattfinden. Zweitens haben Unternehmen in der Regel ihre eigenen Systeme zur Kundenregistrierung und Identitätsverifizierung.
Dies führt nicht nur zu Ressourcenredundanz und hohen Betriebskosten, sondern erzeugt auch Ärger für Bitcoin-Nutzer. Als ehrlicher Bitcoin-Nutzer muss man möglicherweise verschiedenen Anbietern von Bitcoin-Diensten Identitätsdokumente zur Identitätsverifizierung vorlegen, bevor man ihre Dienste nutzt.
Am 25. Februar 2015 startete die Bank of England ihre One Bank Research Agenda - ein ehrgeiziger und umfassender Rahmen, um die Art und Weise, wie Forschung in der Bank betrieben wird, zu verändern. Laut diesem Diskussionspapier untersucht die Bank of England, ob die Zentralbanken selbst die Blockchain-Technologie von Bitcoin nutzen sollten, um ihre eigenen digitalen Währungen auszugeben. Die Bank of England hat erklärt, dass Probleme im Zusammenhang mit KYC und AML angegangen werden müssen und untersucht werden sollte, wie digitale Identitätsverwaltung erreicht werden kann, während die Privatsphäre berücksichtigt wird.
Unter Berücksichtigung des Vorstehenden wäre es vorteilhaft, ein Verfahren zur persönlichen Identifizierung und Verifizierung, ein pseudonymes System und ein Transaktionsnetzwerk zum Überwachen und Beschränken von Transaktionen von Kryptographie-basiertem elektronischem Geld zu entwickeln, die zumindest einige der oben genannten Nachteile vermeiden würden.
Die vorliegende Erfindung - ein „mit persönlicher Identität verknüpftes Anmeldeinformations-Authentifizierungsprotokoll“ - ist das erste Protokoll, das eine praktische Lösung für die Probleme im Zusammenhang mit Kryptowährungsdiebstahl, KYC und AML bietet, während die Privatsphäre der Nutzer gewahrt bleibt.
Nicht zuletzt kann die vorliegende Erfindung von den Zentralbanken oder anderen Finanzinstitutionen angenommen oder modifiziert werden, um ihre eigenen digitalen Währungen auszugeben, die durch ein Distributed Ledger-Zahlungssystem unterstützt werden, aber auch von einem zentralen Verwaltungsorgan reguliert werden. Solche digitalen Währungen können daher die Vorteile des bestehenden Bankensystems und die Vorteile von Kryptographie-basiertem elektronischem Geld übernehmen.
ABRISS
Die hier vorgestellte Erfindung kann durch die folgenden Abschnitte zusammengefasst werden.

1. Verfahren zur persönlichen Identifizierung und Verifizierung von Transaktionen, die Kryptographie-basiertes elektronisches Geld beinhalten, wobei das Verfahren von einem Rechenserver (101) ausgeführt wird, der mindestens ein Computerprogramm umfasst, das als Registrierungsschnittstelle (102) fungiert, und das Verfahren dadurch gekennzeichnet ist, dass es die nachfolgenden Schritte umfasst:
- Gewähren des Zugangs für einen oder mehrere potentielle oder bestehende Währungsnutzer (103);
- Bereitstellen einer Registrierungsschnittstelle (102) für einen oder mehrere potenzielle Währungsnutzer zum Registrieren (104) eines Nutzerkontos, das eine Authentifizierung erfordert;
- Auffordern zur Übermittlung von Unterlagen zum Nachweis der tatsächlichen persönlichen Identität eines Registranten (105);
- Verifizieren der tatsächlichen persönlichen Identität des Registranten (106);
- Ablehnen einer Kontoerstellung für Registranten, deren Verifizierung der persönlichen Identität scheitert (107);
- Erstellen eines persönlichen Kontos (108) für einzelne erfolgreiche Registranten (109) mit erfolgreicher Verifizierung der persönlichen Identität (110);
- Gestatten eines erfolgreichen Registranten (109), Anmeldeinformationen (111) zu erstellen, die eine zugehörige Authentifizierung (112) umfassen;
- Speichern (116) aller übermittelten Informationen in einer Client-Informationsdatenbank (115);
- Senden (117) der Anmeldeinformationen an zentrale Genehmigungsserver (401); und Zuordnen und Speichern (118) einer oder mehrerer Multisignatur-Währungsadressen, der Anmeldeinformationen und der persönlichen Identität einzelner Registranten.
2. Verfahren nach Abschnitt 1, dadurch gekennzeichnet, dass die Authentifizierung mittels Passwortschutz, Zwei-Faktor-Authentifizierung oder Multi-Faktor-Authentifizierung erfolgt.
3. Verfahren nach Abschnitt 1, dadurch gekennzeichnet, dass es ferner einen Schritt zum Verschlüsseln der Anmeldeinformationen (114) umfasst.
4. Verfahren nach Abschnitt 1, dadurch gekennzeichnet, dass die Anmeldeinformationen ein digitales, elektronisches oder Hardwareobjekt sind, das als ein Authentifizierungsmechanismus verwendet werden kann, um sich zu identifizieren. Zum Beispiel kann es ein eindeutiges Paar digitaler Codes sein (z. B. Name und Passwort); es kann ein eindeutiger Produktschlüssel zur Aktivierung einer Client-Wallet-Software sein; und es kann ein sich ständig änderndes Token (z. B. ein eindeutiger 7-stelliger Code) sein, das an ein physisches Gerät gebunden ist, das dem Nutzer gehört, wie beispielsweise ein Mobiltelefon oder ein personalisiertes Gerät zum Erzeugen eines sicheren Schlüssels.
5. Verfahren zum Erzeugen eines Kryptographie-basierten elektronischen Geldes (CBEM) (201) und seines zugehörigen Transaktionsnetzwerks (202), wobei das Verfahren durch ein Netzwerk von als Knoten fungierenden Computerprogrammen ausgeführt wird und das Verfahren dadurch gekennzeichnet ist, dass es die nachfolgenden Schritte umfasst:
- Installieren eines Knotens (203), der ein eigenständiges Computerprogramm oder ein Funktionsmodul eines Client-Wallets (301) sein kann, in einem oder mehreren Client-Computern und/oder -Servern (204);
- Verbinden aller Knoten, um Relaisknoten (205) eines Peer-to-Peer-Netzwerks zu bilden, durch ein Datenübertragungsnetzwerk (206);
- Steuern des Verfahrens zum Erzeugen mindestens einer Einheit des CBEM (207); Schützen des Besitzes von mindestens einer Einheit des CBEM durch Public/Private-Key-Kryptographie (208);
- Aufzeichnen des Besitzes von mindestens einer Einheit des CBEM in einen Public Ledger aller Transaktionen (z. B. der Blockchain) (209) unter Verwendung der Währungsadressen des Besitzers (313) (210);
- Verifizieren des Besitzes von mindestens einer Einheit des CBEM (211);
- Beschränken des Erzeugens einer oder mehrerer gültiger Währungsadressen (313) zum Empfangen mindestens einer Einheit des CBEM nur auf gültig registrierte Nutzer (109) durch Verifizieren der übermittelten Anmeldeinformationen (111) mit einem der zentralen Genehmigungsserver (401) (212);
- Aufzeichnen von Transaktionen von mindestens einer Einheit des CBEM in dem Public Ledger (209) (213);
- Verifizieren von Transaktionen von mindestens einer Einheit des CBEM (214);
- Steuern des Verfahrens zum Übertragen mindestens einer Einheit des CBEM (215); Integrieren der Transaktionsregeln in den Programmcode von mindestens einem Knoten (216);
- Beschränken mindestens einer Transaktionsgenehmigungsregel (217), umfassend mindestens eines von: Anfordern von gültigen Anmeldeinformationen (111) vom Sender, Anfordern eines oder mehrerer privater Genehmigungsschlüssel (406) von einem der zentralen Genehmigungsserver (401);
- Gestatten der Erzeugung von Multisignaturtransaktionen nur im Pay-to-Script-Hash-Format (218);
- Gestatten der Erzeugung nur von Multisignaturtransaktionen, von denen jede mindestens zwei private Schlüssel als Signaturen benötigt (219);
- Gestatten der Erzeugung von Multisignaturtransaktionen nur bei Vorliegen von gültigen Anmeldeinformationen (111) (220);
- Beschränken eines dieser privaten Schlüssel (219) auf einen privaten Genehmigungsschlüssel (406) von einem der zentralen Genehmigungsserver (221);
- Beschränken des Rests der privaten Schlüssel (219) auf private Client-Schlüssel (222), die verschlüsselt und in dem einen oder den mehreren Client-Wallets (301) gespeichert sind (223);
- Senden aller Transaktionsanfragen von den Client-Wallets (301) an einen der zentralen Genehmigungsserver (401), um den privaten Genehmigungsschlüssel zum Signieren der Transaktionen zu erhalten (224); und
- Ablehnen aller Transaktionen, denen einer der erforderlichen privaten Schlüssel fehlt (219); (225).
6. Verfahren zur persönlichen Identifizierung und Verifizierung von Transaktionen, die Kryptographie-basiertes elektronisches Geld beinhalten, wobei das Verfahren von einem Computerprogramm ausgeführt wird, das als Client-Gerät eines Nutzers fungiert, und das Verfahren dadurch gekennzeichnet ist, dass es die nachfolgenden Schritte umfasst:
- Installieren eines Computerprogramms eines Client-Geräts so, dass es als Client-Wallet (301) in mindestens einem Computer oder Computerserver (302) dient;
- Arbeiten als einer der Relaisknoten (205) zum Weiterleiten von Informationen aller CBEM-Einheiten (z. B. Münzen), die in dem Transaktionsnetzwerk (202) erzeugt werden (303); Arbeiten als einer der Relaisknoten (205) zum Weiterleiten aller Transaktionsinformationen in dem Transaktionsnetzwerk (202) (304);
- Arbeiten als einer der Relaisknoten zum Verifizieren und Bestätigen aller Transaktionen, die an das Transaktionsnetzwerk (202) rundgesendet werden (305);
- Erzeugen neuer Münzen durch Beitrag zum Aufzeichnen jeglicher neuer Transaktionsinformationen in dem Public Ledger aller Transaktionen (z. B. (209)) (306); Erzeugen eines oder mehrerer Paare aus einem kryptographischen öffentlichen Client-Schlüssel (307) und einem privaten Client-Schlüssel (308) zum Empfangen und Senden von Münzen (309);
- Speichern der öffentlich-privaten Schlüsselpaare (Elemente 307, 308) einer oder mehrerer von den Währungsnutzern erzeugten Währungsadressen (310);
- Arbeiten als Client-Wallet, so dass die Währungsnutzer Münzen empfangen und senden können (311);
- Arbeiten als Client-Wallet, um zwischen einem der zentralen Genehmigungsserver (401) und registrierten Währungsnutzern (109) zu kommunizieren (312);
- Erzeugen (314) nur von Währungsadressen, die Multisignaturadressen (313) sind;
- Erzeugen einer oder mehrerer Multisignaturadressen (313) aus dem öffentlichen Client-Schlüssel (307) und dem öffentlichen Genehmigungsschlüssel (405) (315);
- Speichern von einer oder mehreren nur Multisignaturadressen (313) in dem Client-Wallet (301) zum Senden und Empfangen von Münzen (316);
- Senden einer oder mehrerer Multisignaturadressen (313) an die Client-Informationsdatenbank (401) zur Speicherung und Zuordnung zur persönlichen Identität des Besitzers der einen oder mehreren Adressen (317);
- Senden der erzeugten gültigen Multisignaturadressen (313) an die zentralen Genehmigungsserver (401) zum Speichern (318);
- Übermitteln von Anmeldeinformationen (111) eines gültig registrierten Nutzers (109) an einen der zentralen Genehmigungsserver zum Erhalten einer Genehmigung zum Erzeugen einer oder mehrerer gültiger Multisignatur-Währungsadressen (313) (319);
- Übermitteln von Anmeldeinformationen (111) eines gültig registrierten Nutzers (109) an einen der zentralen Genehmigungsserver zum Erhalten einer Genehmigung zum Erzeugen einer oder mehrerer gültiger Transaktionen (Elemente 218, 219, 220, 221, 223), um Münzen an einen oder mehrere Währungsadressen (320) zu senden;
- Gestatten der Erzeugung nur von Transaktionen, die Multisignaturadressen (313) sowohl zum Senden als auch zum Empfangen der Münzen verwenden (321); und
- Aufzeichnen unverbrauchter Münzen (falls vorhanden) in der Blockchain an der Währungsadresse, von der die Münzen gerade gesendet wurden (322).
7. Verfahren zur persönlichen Identifizierung und Verifizierung für Transaktionen, die Kryptographie-basiertes elektronisches Geld beinhalten, wobei das Verfahren von einem Computerprogramm in einem als zentraler Genehmigungsserver (401) fungierenden Rechenserver ausgeführt wird und das Verfahren dadurch gekennzeichnet ist, dass es die nachfolgenden Schritte umfasst:
- Kommunizieren (407) mit einem Client-Wallet (301), um eine oder mehrere gültige Multisignatur-Währungsadressen (313) bei Vorliegen von gültigen Anmeldeinformationen zu erzeugen;
- Bereitstellen (408) eines öffentlichen Genehmigungsschlüssels (405) an das Client-Wallet, um eine oder mehrere Multisignaturadressen (313) zu erzeugen;
- Kommunizieren (409) mit dem Client-Wallet (301), um bei Vorliegen von gültigen Anmeldeinformationen eine oder mehrere gültige Transaktionen (218, 219, 220, 221, 223) zu erzeugen, um Münzen an eine oder mehrere Währungsadressen zu senden;
- Bereitstellen (410) eines privaten Genehmigungsschlüssels (406), der zu dem öffentlichen Genehmigungsschlüssel (405) gehört, der bei der Erzeugung der Multisignaturadresse (313) verwendet wurde, um eine Transaktionseingabe für eine oder mehrere gültige Transaktionen zu signieren (218, 219, 220, 221, 223);
- Bereitstellen des jüngsten privaten Schlüssels (411) zum Signieren der gesamten Transaktion für eine oder mehrere gültige Transaktionen (412); und Speichern (414) von Transaktionsinformationen in einer Transaktionsdatenbank (413).
8. Verfahren nach Abschnitt 7, dadurch gekennzeichnet, dass der jüngste private Genehmigungsschlüssel (411) derjenige private Genehmigungsschlüssel ist, der zu dem öffentlichen Genehmigungsschlüssel (405) gehört, der bei der Erstellung der Multisignaturadresse (313) verwendet wurde, oder ein anderer privater Genehmigungsschlüssel ist.
9. Verfahren nach Abschnitt 7, dadurch gekennzeichnet, dass der Schritt des Speicherns (414) von Transaktionsinformationen in einer Transaktionsdatenbank (413) das Speichern einer Transaktions-ID, der Währungsadresse des Senders, der Währungsadresse des Empfängers, der Menge an übertragenen Münzen, der Transaktionszeit und der IP-Adressen der Wallets des Senders und des Empfängers umfasst.
10. Verfahren nach Abschnitt 7, dadurch gekennzeichnet, dass das Verfahren ferner einen Schritt des Verifizierens der Transaktion gegen ein oder mehrere Transaktionskriterien (501, 502) auf dem zentralen Genehmigungsserver (401) umfasst.
11. Verfahren nach Abschnitt 7, dadurch gekennzeichnet, dass das eine oder die mehreren Transaktionskriterien (501, 502) Kriterien enthalten, die von einem zentralen Verwaltungsorgan (601) und/oder dem Registranten vorgegeben sind.
12. Verfahren nach Abschnitt 7, dadurch gekennzeichnet, dass das Verfahren ferner einen Schritt des Ermittelns von persönlichen Identitäten des Senders und des Empfängers durch Zuordnen ihrer Währungsadressen in der Transaktionsdatenbank und der Client-Informationsdatenbank bei Bedarf umfasst.
13. Verfahren zur persönlichen Identifizierung und Verifizierung für Transaktionen, die Kryptographie-basiertes elektronisches Geld beinhalten, wobei das Verfahren durch eine Gruppe von Computerprogrammen, die als Geräte eines zentralen Verwaltungsorgans dienen, und eines Client-Geräts eines Nutzers ausgeführt wird, wobei das Verfahren dadurch gekennzeichnet ist, dass es die nachfolgenden Schritte umfasst:
- Empfangen von Anmeldeinformationen eines Registranten, umfassend mindestens Anmeldeinformationen zur Zwei-Faktor-Authentifizierung, die eine Multisignatur definieren; Verifizieren der tatsächlichen persönlichen Identität des Registranten;
- Einrichten eines persönlichen Kontos (108) für einen einzelnen erfolgreichen Registranten (109) mit erfolgreicher Verifizierung der tatsächlichen persönlichen Identität (110), wobei das persönliche Konto die Zuordnung und Speicherung der Multisignatur einer Währungsadresse und der persönlichen Identität einzelner Registranten erleichtert (118); Bereitstellen eines Wallets des Registranten, das mindestens eine Einheit von elektronischem Geld enthält;
- Verzeichnen des Besitzes der mindestens einen Einheit von elektronischem Geld in einer Transaktionsdatenbank (413) unter Verwendung der Währungsadresse des Registranten (313);
- Erzeugen einer Multisignaturtransaktion in einem Pay-to-Script-Hash-Format (218), die jeweils mindestens zwei private Schlüssel als Genehmigungssignaturen benötigt (219); Beschränken eines dieser privaten Schlüssel (219) auf den privaten Genehmigungsschlüssel (406) von einem der zentralen Genehmigungsserver (221);
- Beschränken des Rests der privaten Schlüssel (219) auf die privaten Schlüssel (222) des Registranten, die in dem Client-Wallet (301) gespeichert sind (223);
- Senden der Transaktionsanfrage von dem Client-Wallet (301) an mindestens einen der zentralen Genehmigungsserver (401), um den privaten Genehmigungsschlüssel zum Signieren der Transaktion zu erhalten (224); und
- Rundsenden der genehmigten Transaktionsnachrichten an alle Relaisknoten in einem Transaktionsnetzwerk (214).
14. System zur persönlichen Identifizierung und Verifizierung von Transaktionen, die Kryptographie-basiertes elektronisches Geld beinhalten, wobei das System umfasst:
- einen zentralen Genehmigungsserver (401), der so eingerichtet ist, dass er das Verfahren gemäß Abschnitt 7 ausführt, um Client-Registrierungsanfragen, Client-Kryptowährungsadressen und Kryptowährungstransaktionen zu verarbeiten;
- eine Client-Informationsdatenbank (404), die kommunikativ mit dem zentralen Genehmigungsserver (401) verbunden ist;
- eine Transaktionsdatenbank (413), die kommunikativ mit dem zentralen Genehmigungsserver (401) verbunden ist;
- mindestens ein Client-Gerät (414, 415), das mit einem Registranten-Wallet (416, 417) versehen ist, das mindestens eine Einheit von elektronischem Geld enthält;
- wobei das mindestens eine Client-Gerät (414, 415) eingerichtet ist, um das Verfahren gemäß Abschnitt 13 auszuführen.
15. Computerprogramm mit Programmcodemitteln zum Ausführen aller Schritte des computerimplementierten Verfahrens gemäß Abschnitt 1, Abschnitt 5, Abschnitt 6, Abschnitt 7, Abschnitt 5 und Abschnitt 13, wenn das Programm auf einem Computer oder einem Rechenserver ausgeführt wird.
16. Computerlesbares Medium, das computerausführbare Befehle speichert, die alle Schritte des computerimplementierten Verfahrens gemäß Abschnitt 1, Abschnitt 5, Abschnitt 6, Abschnitt 7, Abschnitt 5 und Abschnitt 13 ausführen, wenn sie auf einem Computer oder einem Rechenserver ausgeführt werden.
17. Verfahren nach Abschnitt 7, wobei das Paar des öffentlichen Genehmigungsschlüssels (405) und des privaten Genehmigungsschlüssels (406) in einem regulären Zeitraum manuell oder automatisch geändert werden kann, um ein Lecken des öffentlichen Genehmigungsschlüssels und des privaten Genehmigungsschlüssels an die Öffentlichkeit zu vermeiden. Nach dem Wechsel zu einem neuen Paar von Genehmigungsschlüsseln wird der alte private Genehmigungsschlüssel zum Signieren der Transaktionseingabe (410) verwendet und der neue private Genehmigungsschlüssel wird zum Signieren der gesamten Transaktion (d. h. aller Transaktionsdaten) (412) verwendet.
18. Verfahren nach Abschnitt 5, Abschnitt 6 und Abschnitt 7, wobei alle Währungsadressen, die nicht durch die Übermittlung von gültigen Anmeldeinformationen an einen der zentralen Genehmigungsserver (401) erzeugt werden, ungültig sind und keine Münzen erhalten können.
19. Verfahren nach Abschnitt 10, wobei das Transaktionsnetzwerk (202) so modifiziert werden kann, dass es alle Transaktionen ablehnt, die nicht die zentralen Transaktionskriterien (501) erfüllen, die in einem der zentralen Genehmigungsserver (401) gespeichert sind.
20. Verfahren nach Abschnitt 19, wobei die Client-Transaktionskriterien (502) durch einen gültig registrierten Nutzer definiert werden können, um seine/ihre eigenen Transaktionen zu begrenzen.
21. Verfahren nach Abschnitt 19, wobei die Transaktionskriterien (501) durch ein zentrales Verwaltungsorgan (601) definiert werden können, um verdächtige Transaktionen zu stoppen, die wahrscheinlich an illegalen Aktivitäten wie Geldwäsche beteiligt sind.
22. Verfahren nach Abschnitt 5, wobei einzelne Transaktionen mit einer definierten Regel überwacht werden können, um verdächtige Transaktionen zu identifizieren, aufzuzeichnen und zu melden, die wahrscheinlich an illegalen Aktivitäten wie Geldwäsche beteiligt sind.
23. Verfahren nach Abschnitt 5, wobei tatsächliche persönliche Identitäten von Besitzern von einzelnen Währungsadressen in der Client-Informationsdatenbank gespeichert werden. Für diejenigen Transaktionen, bei denen der Verdacht auf illegale Aktivitäten besteht (Abschnitt 22), werden die Identitäten der zugehörigen Sender und Empfänger aus der Client-Informationsdatenbank extrahiert, indem die Währungsadressen der Sender und Empfänger ermittelt werden. Anschließend werden die verdächtigen Aktivitäten und die damit verbundenen Client-Informationen den Regierungsbehörden unter Berücksichtigung der Vorschriften und Gesetze in den betroffenen Ländern gemeldet.
24. Verfahren nach Abschnitt 1 und Abschnitt 5, wobei tatsächliche persönliche Identitäten von Besitzern für einzelne Währungsadressen in der Client-Informationsdatenbank gespeichert sind. Dies erfüllt die behördliche Anforderung „Know-your-customer“. Dadurch kann das System als Zahlungssystem für kommerzielle Aktivitäten verwendet werden.
25. Verfahren nach Abschnitt 1 und Abschnitt 5, wobei tatsächliche persönliche Identitäten von Besitzern für einzelne Währungsadressen in der Client-Informationsdatenbank gespeichert werden. Diese Informationen sind jedoch für die Öffentlichkeit nicht zugänglich, um die pseudonyme Eigenschaft des Kryptographie-basierten elektronischen Geldes (201) und seines Transaktionsnetzwerks (202) zu erhalten.
26. Verfahren nach Abschnitt 1 und Abschnitt 5, wobei ein Nutzer seine/ihre Anmeldeinformationen (111) ändern kann, um zu verhindern, dass Münzen aus einer gestohlenen Hauptdatei (z. B. der wallet.dat-Datei) seines/ihres Währungs-Wallets (301) übertragen werden.
27. Verfahren nach Abschnitt 1, Abschnitt 5, Abschnitt 6 und Abschnitt 12, wobei (i) tatsächliche persönliche Identitäten von Besitzern für einzelne Währungsadressen in der Client-Informationsdatenbank gespeichert werden, (ii) alle Währungsadressen, die nicht durch die Übermittlung von gültigen Anmeldeinformationen an einen der zentralen Genehmigungsserver (401) erzeugt wurden, nicht gültig sind und keine Münzen erhalten können (Abschnitt 18), und (iii) nur gültig registrierte Nutzer gültige Anmeldeinformationen (112) haben. Wenn Münzen von jemandem gestohlen werden, können der Diebstahl oder die Hacker leicht ermittelt werden, indem die eine oder mehreren persönlichen Identitäten der Empfänger aus der Client-Informationsdatenbank gemäß der einen oder den mehreren Währungsadressen der Empfänger abgerufen werden. Daher verhindert die Implementierung der Verfahren nach Abschnitt 1, Abschnitt 5 und Abschnitt 6, dass Kryptowährung gestohlen wird.
28. Verfahren nach Abschnitt 5, Abschnitt 12, wobei die Menge an Münzen, die einem gültig registrierten Nutzer gehört, vollständig und leicht durch das zentrale Verwaltungsorgan (601) durch Analysieren der Transaktionsdatensätze in der Transaktionsdatenbank (413) ermittel- und verfolgbar ist. Neben der Fähigkeit, einzelne Währungsadressen ihren Besitzern zuzuordnen, wird diese einzigartige Eigenschaft durch die Aufzeichnung nicht ausgegebener Münzen (falls vorhanden) an der Währungsadresse, von der die Münzen gerade gesendet/ausgegeben wurden, verbessert (322). Diese einzigartige Eigenschaft ermöglicht Anwendungen unseres Systems für Finanz- und Bankaktivitäten, insbesondere solche, die von Dritten geprüft werden müssen.
29. Verfahren nach Abschnitt 20 und Abschnitt 21, das eine praktische Lösung für die Probleme im Zusammenhang mit Kryptowährungsdiebstahl, KYC und AML bietet, während die Privatsphäre der Nutzer erhalten bleibt.
30. System nach Abschnitt 20 und Abschnitt 21, das von den Zentralbanken oder anderen Finanzinstitutionen übernommen oder modifiziert werden kann, um ihre eigenen digitalen Währungen auszugeben, die durch ein Distributed Ledger-Zahlungssystem unterstützt werden, aber auch von einem zentralen Verwaltungsorgan reguliert werden.

Ferner ist ein Verfahren offenbart, das ein System zum Erzeugen eines neuen Kryptographie-basierten elektronischen Geldes oder einer elektronischen Kryptowährung mit den ermittelbaren Identitäten von Sendern und Empfängern in allen Geldtransaktionen umfasst. Das Verfahren kann in einem System durchgeführt werden, das Folgendes umfasst:

1.1. Mindestens einen Server und mindestens eine webbasierte Registrierungsschnittstelle, wobei der mindestens eine Server mindestens einige oder alle der folgenden Funktionen ausführt:
1. i. Gewähren des Zugangs für einen oder mehrere potenzielle oder bestehende Währungsnutzer;
2. ii. Bereitstellen einer Online-Schnittstelle für einen oder mehrere potenzielle Währungsnutzer zur Registrierung eines Nutzerkontos mit Passwortschutz, Zwei-Faktor-Authentifizierung oder Mehr-Faktor-Authentifizierung;
3. iii. Auffordern zur Übermittlung von Dokumenten zum Nachweis der tatsächlichen persönlichen Identität eines Registranten;
4. iv. Handhaben der Verifikation der tatsächlichen persönlichen Identität des Registranten;
5. v. Ablehnen einer Kontoerstellung für Registranten, deren Verifizierung der persönlichen Identität scheitert;
6. vi. Erstellen eines persönlichen Kontos für einzelne erfolgreiche Registranten mit erfolgreicher Verifizierung der persönlichen Identität;
7. vii. Gestatten eines erfolgreichen Registranten, Anmeldeinformationen zu erstellen, die eine Kennung und ein Passwort umfassen;
8. viii. Gestatten eines erfolgreichen Registranten, die Anmeldeinformationen und die Kontaktinformationen zu ändern;
9. ix. Verschlüsseln der Anmeldeinformationen
10. x. Speichern aller übermittelten Informationen, insbesondere der persönlichen Identität und der verschlüsselten Anmeldeinformationen, in einer Client-Informationsdatenbank;
11. xi. Senden der verschlüsselten Anmeldeinformationen, die neu erzeugt oder geändert wurden, an zentrale Genehmigungsserver;
12. xii. Zuordnen und Speichern der einen oder mehreren Multisignatur-Währungsadressen, der Anmeldeinformationen und persönlichen Identität einzelner Registranten.
1.2. Ein Kryptographie-basiertes elektronisches Geld und sein zugehöriges Transaktionsnetzwerk, wobei es mindestens einige oder alle der folgenden Grundfunktionen und einzigartigen Funktionen ausführt:
- Grundfunktionen, die denen aller anderen Kryptographie-basierten elektronischen Gelder gleichen
  1. i. Bereitstellen der Öffentlichkeit von Client-Wallet-Software;
  2. ii. Verbinden von Computern oder Servern über die Client-Wallets;
  3. iii. Verwenden der verbundenen Computer oder Server zum Bilden von Relaisknoten eines Transaktionsnetzwerks;
  4. iv. Erzeugen einer vorgegebenen Menge an Geldeinheiten (Münzen) mit einer vorgegebenen Geschwindigkeit;
  5. v. Schützen des Besitzes der Münzen durch Public/Private-Key-Kryptographie;
  6. vi. Aufzeichnen des Besitzes der Münzen in einem Public Ledger aller Transaktionen (z. B. unter Verwendung der Währungsadressen der Besitzer);
  7. vii. Verteilen des Public Ledgers aller Transaktionen (z. B. mit seinen Aktualisierungen) an Personen, die über das Client-Wallet mit dem Transaktionsnetzwerk verbunden sind;
  8. viii. Gestatten, dass ein Besitzer eines privaten Schlüssels eine Menge an Münzen nur sendet, wenn sie eine an der entsprechenden Währungsadresse verzeichnete Menge an Münzen nicht übersteigt, nachdem die erforderliche Transaktionsgebühr abgezogen wurde;
  9. ix. Senden aller neuen Transaktionsnachrichten an alle Relaisknoten im Transaktionsnetzwerk;
  10. x. Verifizieren aller neuen Transaktionsnachrichten an einzelnen Relaisknoten;
  11. xi. Aufzeichnen der Transaktionsinformationen (einschließlich, aber nicht beschränkt auf, Sender-Währungsadresse, Empfänger-Währungsadresse, Menge an Münzen, Transaktionskosten, Transaktionszeit) in den Public Ledger aller Transaktionen (z. B. die Blockchain);
- Einzigartige Funktionen
  1. i. Beschränken des Erzeugens einer oder mehrerer gültige Währungsadressen nur auf gültig registrierte Nutzer, um die Münzen zu erhalten, indem die übermittelten Anmeldeinformationen mit einem der zentralen Genehmigungsserver verifiziert werden;
  2. ii. Gestatten der Erzeugung nur von Multisignaturtransaktionen im Pay-to-Script-Hash-Format;
  3. iii. Gestatten der Erzeugung nur von Multisignaturtransaktionen, die jeweils mindestens zwei private Schlüssel als Signaturen benötigen;
  4. iv. Gestatten der Erzeugung von Multisignaturtransaktionen nur in Anwesenheit von gültigen Anmeldeinformationen;
  5. v. Beschränken eines dieser privaten Schlüssel auf einen privaten Genehmigungsschlüssel von einem der zentralen Genehmigungsserver;
  6. vi. Beschränken des Rests der privaten Schlüssel auf private Client-Schlüssel, die verschlüsselt und in dem einen oder den mehreren Client-Wallets gespeichert sind;
  7. vii. Senden aller Transaktionsanfragen von den Client-Wallets an einen der zentralen Genehmigungsserver, um den privaten Genehmigungsschlüssel zum Signieren der Transaktionen zu erhalten;
  8. viii. Ablehnen aller Transaktionen, denen einer der erforderlichen privaten Schlüssel fehlt;
  9. ix. Beschränken der Transaktionsgenehmigungsregeln (einschließlich, aber nicht beschränkt auf, die Anforderung von gültigen Anmeldeinformationen des Senders, die Anforderung eines oder mehrerer privater Genehmigungsschlüssel von einem der zentralen Genehmigungsserver zum Signieren der Transaktionseingabe und zum Signieren der gesamten Transaktion) für einzelne Transaktionen durch Verwendung eines „Pay-To-Script-Hash“-Skripts, das in die Quelle des elektronischen Geldes als einziges Skript für die Transaktionserstellung eingebaut ist;
1.3. Mindestens einen Computer oder Server zum Ausführen von Client-Wallet-Software, wobei das mindestens ein Client-Wallet mindestens einige oder alle der folgenden Grundfunktionen und einzigartigen Funktionen ausführt:
- Grundfunktionen, die denen aller anderen Kryptographie-basierten elektronischen Gelder gleichen
  1. i. Arbeiten als einer der Relaisknoten zum Weiterleiten aller Transaktionsinformationen im Transaktionsnetzwerk;
  2. ii. Arbeiten als einer der Relaisknoten, um alle Transaktionen zu verifizieren und zu bestätigen, die an das Transaktionsnetzwerk gesendet werden;
  3. iii. Erzeugen neuer Münzen durch Beitrag zur Aufzeichnung neuer Transaktionsinformationen in den Public Ledger aller Transaktionen (z. B. die Blockchain);
  4. iv. Erzeugen eines oder mehrerer Paare eines kryptografischen öffentlichen Client-Schlüssels und eines privaten Client-Schlüssels zum Empfangen und Senden von Münzen;
  5. v. Speichern der öffentlich-privaten Client-Schlüsselpaare einer oder mehrerer der Währungsadressen, die von den Währungsnutzern erzeugt wurden;
  6. vi. Arbeiten als Client-Wallet für die Währungsnutzer, um Münzen zu erhalten und zu senden;
- Einzigartige Funktionen
  1. i. Arbeiten als Client-Wallet für die Kommunikation zwischen einem der zentralen Genehmigungsserver und registrierten Währungsnutzern;
  2. ii. Erzeugen nur von Währungsadressen, die Multisignaturadressen sind;
  3. iii. Erzeugen einer oder mehrerer Multisignaturadressen aus dem öffentlichen Client-Schlüssel und dem öffentlichen Genehmigungsschlüssel;
  4. iv. Speichern von einer oder mehrerer Multisignaturadressen nur in dem Client-Wallet zum Senden und Empfangen von Münzen;
  5. v. Senden einer oder mehrerer Multisignaturadressen an die Client-Informationsdatenbank zum Speichern und Zuordnen der persönlichen Identität des Besitzers der einen oder mehreren Adressen;
  6. vi. Senden der erzeugten gültigen Multisignaturadressen an die zentralen Genehmigungsserver zum Speichern;
  7. vii. Übermitteln von Anmeldeinformationen eines gültig registrierten Nutzers an einen der zentralen Genehmigungsserver, um eine Genehmigung zum Erzeugen einer oder mehrerer gültiger Multisignatur-Währungsadressen zu erhalten;
  8. viii. Übermitteln von Anmeldeinformationen eines gültig registrierten Nutzers an einen der zentralen Genehmigungsserver, um eine Genehmigung zum Erstellen einer oder mehrerer gültiger Transaktionen zum Senden von Münzen an eine oder mehrere Währungsadressen zu erhalten;
  9. ix. Gestatten der Erzeugung nur von Transaktionen, die Multisignaturadressen sowohl zum Senden als auch zum Empfangen der Münzen verwenden;
  10. x. Aufzeichnen von nicht ausgegebenen Münzen (falls vorhanden) in der Blockchain an der Währungsadresse, von der die Münzen gerade gesendet wurden;
1.4. Mindestens einen zentralen Genehmigungsserver, wobei der mindestens eine zentrale Genehmigungsserver mindestens einige oder alle der folgenden Funktionen ausführt:
- i. Abrufen neuer oder aktualisierter Anmeldeinformationen und ihrer zugehörigen Währungsadressen aus der Client-Informationsdatenbank;
- ii. Speichern und Aktualisieren der Nutzer-Anmeldeinformationen und der zugehörigen Währungsadressen in der zentralen Genehmigungsdatenbank;
- iii. Erzeugen, Ändern, Verschlüsseln und Speichern eines oder mehrerer Paare eines öffentlichen Genehmigungsschlüssels und eines privaten Genehmigungsschlüssels;
- iv. Kommunizieren mit dem Client-Wallet, um eine oder mehrere gültige Multisignatur-Währungsadressen in Anwesenheit von gültigen Anmeldeinformationen zu erzeugen;
- v. Bereitstellen des öffentlichen Genehmigungsschlüssels an das Währungs-Wallet, um eine oder mehrere Multisignaturadressen zu erzeugen,
- vi. Kommunizieren mit dem Client-Wallet, um in Anwesenheit von gültigen Anmeldeinformationen eine oder mehrere gültige Transaktionen zu erzeugen, um Münzen an eine oder mehrere Währungsadressen zu senden;
- vii. Bereitstellen eines privaten Genehmigungsschlüssels, der zu dem öffentlichen Genehmigungsschlüssel gehört, der bei der Erstellung der Multisignaturadresse verwendet wurde, um Transaktionseingaben für eine oder mehrere gültige Transaktionen zu signieren;
- viii. Bereitstellen eines weiteren privaten Genehmigungsschlüssels, bei dem es sich um den privaten Genehmigungsschlüssel, der in Element 410 verwendet wird, oder um den letzten privaten Genehmigungsschlüssel handeln kann, um die gesamte Transaktion für eine oder mehrere gültige Transaktionen zu signieren;
- ix. Speichern aller Transaktionsinformationen (einschließlich, aber nicht beschränkt auf, Transaktions-ID, Sender-Währungsadresse, Empfänger-Währungsadresse, Menge der übertragenen Münzen, Transaktionsgebühren, Transaktionszeit und IP-Adressen der Client-Wallets des Senders und Empfängers) in einer Transaktionsdatenbank.

Ferner wird ein Verfahren zur persönlichen Identifizierung und Verifizierung für Transaktionen offenbart, die Kryptographie-basiertes elektronisches Geld beinhalten, wobei das Verfahren mindestens einige oder alle der Schritte umfasst von:

2.1. Verifizieren der tatsächlichen persönlichen Identität eines Registranten;
2.2. Erstellen eines persönlichen Kontos, das durch mindestens Zwei-Faktor-Authentifizierung geschützt ist, für einen einzelnen erfolgreichen Registranten mit erfolgreicher Verifizierung der tatsächlichen persönlichen Identität, während das persönliche Konto die Zuordnung und Speicherung der persönlichen Identität und der einen oder mehreren Währungsadressen der einzelnen Registranten mit dem persönlichen Konto erleichtert;
2.3. Empfangen von Anmeldeinformationen eines einzelnen erfolgreichen Registranten, die die Identität des Registranten, den Besitz einer Währungsadresse und die Senderidentität einer Transaktion anzeigen;
2.4.3. Speichern der persönlichen Identität und der Anmeldeinformationen des Registranten auf einem oder mehreren zentralen Genehmigungsservern;
2.5. Bereitstellen eines Registranten-Wallets zum Senden und Empfangen von mindestens einer Einheit von elektronischem Geld;
2.6. Aufzeichnen des Besitzes an mindestens einer Einheit von elektronischem Geld in einem Public Ledger aller Transaktionen (z. B. unter Verwendung der einen oder mehreren Währungsadressen des Registranten);
2.7 Erhalten und Verifizieren von Anmeldeinformationen, die von einem Registranten-Wallet bei einer Anfrage zur Erzeugung einer Währungsadresse zu einem zentralen Genehmigungsserver übermittelt werden;
2.8 Genehmigen der Erzeugung einer Multisignaturadresse als gültige Währungsadresse, die dem Registranten gehört, durch Bereitstellen eines öffentlichen Genehmigungsschlüssels von dem zentralen Genehmigungsserver an das Registranten-Wallet;
2.9 Erzeugen einer gültigen Währungsadresse zum Empfangen mindestens einer Einheit von elektronischem Geld durch Kombinieren des öffentlichen Schlüssels des Registranten und des öffentlichen Genehmigungsschlüssels des zentralen Genehmigungsservers in dem Registranten-Wallet,
2.10 Speichern und Zuordnen der persönlichen Identität, der Anmeldeinformationen und einer oder mehrerer gültiger Währungsadressen des Registranten in einer Client-Informationsdatenbank;
2.11 Erzeugen einer Transaktion in einem „Pay-to-Script-Hash“-Format, wobei jede mindestens zwei private Schlüssel als Signatur benötigt, in dem Registranten-Wallet; 2.12. Beschränken mindestens eines dieser privaten Schlüssel auf einen privaten Genehmigungsschlüssel durch einen der zentralen Genehmigungsserver;
2.13. Beschränken des Rests der privaten Schlüssel auf die privaten Schlüssel des Registranten, die in den Client-Wallets gespeichert sind;
2.14. Beschränken von Transaktionsgenehmigungsregeln (einschließlich, aber nicht beschränkt auf, die Anforderung von gültigen Anmeldeinformationen vom Sender, die Anforderung eines oder mehrerer privater Genehmigungsschlüssel von einem der zentralen Genehmigungsserver zum Signieren der Transaktionseingabe und zum Signieren der gesamten Transaktion) für einzelne Transaktionen durch Verwendung eines „Pay-To-Script-Hash“-Skripts, die in der Quelle des elektronischen Geldes als einziges Skript zur Transaktionserstellung eingebaut ist;
2.15. Empfangen und Verifizieren von Anmeldeinformationen, die von einem Registranten-Wallet bei einer Anfrage zur Erzeugung einer Transaktion auf einen zentralen Genehmigungsserver übermittelt werden;
2.16. Verifizieren der Transaktion gegen ein oder mehrere Transaktionskriterien (einschließlich, aber nicht beschränkt auf solche, die von dem zentralen Verwaltungsorgan und/oder dem Registranten vorgegeben sind) auf dem zentralen Genehmigungsserver;
2.17. Genehmigen der Ausführung der Transaktion durch Signieren der Transaktion mit einem oder mehreren privaten Schlüsseln an dem einen oder den mehreren Registranten-Wallets und durch Signieren der Transaktion mit einem oder mehreren der privaten Genehmigungsschlüssel von dem zentralen Genehmigungsserver;
2.18. Aufzeichnen der Transaktionsnachricht aller Transaktionen im Public Ledger (z. B. der Blockchain);
2.19. Speichern der Transaktionsinformationen (einschließlich, aber nicht beschränkt auf Transaktions-ID, Sender- und Empfänger-Kryptowährungsadresse, Menge der übertragenen Münzen, Transaktionszeit und IP-Adressen der Client-Wallets des Senders und des Empfängers) in einer Transaktionsdatenbank;
2.20. Senden der signierten Transaktionsnachricht an alle Relaisknoten in einem Transaktionsnetzwerk zur Bestätigung;
2.21. Ermitteln persönlicher Identitäten des Senders und des Empfängers durch Zuordnen ihrer Währungsadressen in der Transaktionsdatenbank und der Client-Informationsdatenbank bei Bedarf.

Die oben beschriebenen Systeme und Verfahren können mindestens einige oder alle der folgenden bevorzugten Merkmale aufweisen.
Vorzugsweise können das Paar von öffentlichem Genehmigungsschlüssel und privatem Genehmigungsschlüssel manuell oder automatisch in einem regelmäßigen Zeitraum geändert werden, um ein Lecken des öffentlichen Genehmigungsschlüssels und des privaten Genehmigungsschlüssels an die Öffentlichkeit zu vermeiden. Nach dem Wechsel zu einem neuen Paar von Genehmigungsschlüsseln wird der alte private Genehmigungsschlüssel zum Signieren der Transaktionseingabe verwendet und der neue private Genehmigungsschlüssel zum Signieren der gesamten Transaktion (d. h. aller Transaktionsdaten) verwendet.
Vorzugsweise sind alle Währungsadressen, die nicht durch die Übermittlung von gültigen Anmeldeinformationen an einen der zentralen Genehmigungsserver erzeugt werden, ungültig und können keine Münzen erhalten.
Vorzugsweise kann das Transaktionsnetzwerk modifiziert werden, um jegliche Transaktionen abzulehnen, die nicht die zentralen Transaktionskriterien erfüllen, die auf einem der zentralen Genehmigungsserver gespeichert sind.
Vorzugsweise können die Client-Transaktionskriterien durch einen gültig registrierten Nutzer definiert werden, um seine/ihre eigenen Transaktionen zu begrenzen.
Vorzugsweise können die Transaktionskriterien von einem zentralen Verwaltungsorgan definiert werden, um verdächtige Transaktionen zu stoppen, die wahrscheinlich an illegalen Aktivitäten wie Geldwäsche beteiligt sind.
Vorzugsweise können einzelne Transaktionen mit einer definierten Regel überwacht werden, um verdächtige Transaktionen zu identifizieren, aufzuzeichnen und zu melden, die wahrscheinlich an illegalen Aktivitäten wie Geldwäsche beteiligt sind.
Vorzugsweise werden tatsächliche persönliche Identitäten von Besitzern einzelner Währungsadressen in der Client-Informationsdatenbank gespeichert. Bei denjenigen Transaktionen, bei denen der Verdacht auf illegale Aktivitäten besteht, werden die Identitäten der zugehörigen Sender und Empfänger aus der Kundendatenbank extrahiert, indem sie mit den Währungsadressen der Sender und Empfänger ermittelt werden. Anschließend werden die verdächtigen Aktivitäten und die damit verbundenen Client-Informationen den Regierungsbehörden unter Berücksichtigung der Vorschriften und Gesetze in den betroffenen Ländern gemeldet.
Vorzugsweise werden die tatsächlichen persönlichen Identitäten von Besitzern für einzelne Währungsadressen in der Client-Informationsdatenbank gespeichert. Dies erfüllt die behördliche Anforderung „Know-your-customer“. Dadurch kann das System als Zahlungssystem für kommerzielle Aktivitäten verwendet werden.
Vorzugsweise werden die tatsächlichen persönlichen Identitäten von Besitzern für einzelne Währungsadressen in der Client-Informationsdatenbank gespeichert. Solche Informationen sind jedoch für die Öffentlichkeit nicht zugänglich, um die pseudonyme Eigenschaft des Kryptographie-basierten elektronischen Geldes und seines Transaktionsnetzwerks zu erhalten.
Vorzugsweise kann ein Nutzer seine/ihre Anmeldeinformationen ändern, um zu verhindern, dass Münzen aus einer gestohlenen Hauptdatei (z. B. der wallet.dat-Datei) seines/ihres Währungs-Wallets übertragen werden.
Vorzugsweise (i) werden tatsächliche persönliche Identitäten von Besitzern für einzelne Währungsadressen in der Client-Informationsdatenbank gespeichert, (ii) sind Währungsadressen, die nicht durch die Übermittlung von gültigen Anmeldeinformationen an einen der zentralen Genehmigungsserver erzeugt wurden, nicht gültig und sind nicht in der Lage, Münzen zu erhalten, und nur gültig registrierte Nutzer haben gültige Anmeldeinformationen. Wenn Münzen von jemandem gestohlen werden, können der oder die Diebstähle oder der oder die Hacker leicht ermittelt werden, indem die eine oder mehreren persönlichen Identitäten des einen oder der mehreren Empfänger aus der Client-Informationsdatenbank abgerufen werden. Daher verhindert die Implementierung des Systems, dass Kryptowährung gestohlen wird.
Vorzugsweise ist die Menge an Münzen, die ein gültig registrierter Nutzer besitzt, vollständig und leicht durch das zentrale Verwaltungsorgan durch Analysieren der Transaktionsdatensätze in der Transaktionsdatenbank ermittel- und verfolgbar. Neben der Fähigkeit, einzelne Währungsadressen ihren Besitzern zuzuordnen, wird diese einzigartige Eigenschaft durch die Aufzeichnung von nicht ausgegebenen Münzen (falls vorhanden) an der Währungsadresse, von der die Münzen gerade gesendet/ausgegeben wurden, verbessert. Diese einzigartige Eigenschaft ermöglicht Anwendungen unseres Systems für Finanz- und Bankaktivitäten, insbesondere solche, die von Dritten geprüft werden müssen.
Vorzugsweise bieten die Systeme eine praktische Lösung für die Probleme im Zusammenhang mit Kryptowährungsdiebstahl, KYC und AML, während die Privatsphäre der Nutzer erhalten bleibt.
Vorzugsweise können die Systeme von den Zentralbanken oder anderen Finanzinstituten übernommen oder modifiziert werden, um ihre eigenen digitalen Währungen auszugeben, die durch ein Distributed Ledger-Zahlungssystem unterstützt werden, aber auch von einem zentralen Verwaltungsorgan reguliert werden.
Figurenliste
Diese und weitere Aufgaben der hier vorgestellten Erfindung werden durch Bereitstellen eines Systems und Verfahrens zur persönlichen Identifizierung und Verifizierung gelöst. Weitere Einzelheiten und Merkmale der vorliegenden Erfindung, ihre Natur und verschiedene Vorteile werden aus der folgenden detaillierten Beschreibung der in einer Zeichnung gezeigten bevorzugten Ausführungsformen deutlicher werden, in denen:

1 ein Registrierungs- und Datenbanksystem zum Erfassen, Verifizieren und Speichern einer tatsächlichen persönlichen Identität eines neuen Nutzers für ein Kryptographie-basiertes elektronisches Geld zeigt;
2 ein Authentifizierungssystem für Anmeldeinformationen, die einer persönlichen Identität zugeordnet sind, zur Erzeugung einer Multisignatur-Währungsadresse zum Empfangen und Senden eines Kryptographie-basierten elektronischen Geldes zeigt;
3 ein Authentifizierungssystem für Anmeldeinformationen, die einer persönlichen Identität zugeordnet sind, und das Zwei-Parteien-Signaturschema zur Erzeugung einer Zahlungstransaktion einer Menge von Münzen zeigt, die einem Nutzer gehören und an einer Multisignaturadresse verzeichnet sind;
4 ein Diagramm eines Systems gemäß der vorliegenden Erfindung zeigt.

NOTATION UND FACHBEGRIFFE
Einige Abschnitte der folgenden detaillierten Beschreibung sind in Form von Datenverarbeitungsvorgängen, -schritten oder anderen symbolischen Darstellungen von Operationen an Datenbits gezeigt, die auf einem Computerspeicher ausgeführt werden können. Somit führt ein Computer solche logischen Schritte aus, was physische Manipulationen physischer Größen erfordert.
Üblicherweise haben diese Größen die Form von elektrischen oder magnetischen Signalen, die in einem Computersystem gespeichert, übertragen, kombiniert, verglichen und anderweitig manipuliert werden können. Aus Gründen der allgemeinen Verwendung werden diese Signale als Bits, Pakete, Nachrichten, Werte, Elemente, Symbole, Zeichen, Begriffe, Zahlen oder dergleichen bezeichnet.
Außerdem müssen alle diese und ähnliche Begriffe den geeigneten physischen Größen zugeordnet werden und sind lediglich zweckmäßige Bezeichnungen, die auf diese Größen angewendet werden. Ausdrücke wie „verarbeiten“ oder „erzeugen“ oder „übertragen“ oder „ausführen“ oder „bestimmen“ oder „erfassen“ oder „erhalten“ oder „auswählen“ oder „berechnen“ oder „generieren“ oder dergleichen beziehen sich auf Handlungen und Verfahren eines Computersystems, das Daten, die als physische (elektronische) Größen in den Registern und Speichern des Computers repräsentiert sind, manipuliert und in andere Daten umwandelt, die in ähnlicher Weise als physische Größen in den Speichern oder Registern oder einem anderen derartigen Informationsspeicher repräsentiert sind.
Ein computerlesbares (Speicher-) Medium, auf das hierin Bezug genommen wird, kann üblicherweise nicht-flüchtig sein und/oder ein nicht-flüchtiges Gerät umfassen. In diesem Zusammenhang kann ein nicht-flüchtiges Speichermedium ein Gerät umfassen, das greifbar sein kann, was bedeutet, dass das Gerät eine konkrete physische Form aufweist, obwohl das Gerät seinen physischen Zustand ändern kann. So bezieht sich beispielsweise „nicht-flüchtig“ auf ein Gerät, das trotz einer Zustandsänderung greifbar bleibt.
Wie hier verwendet, bedeutet der Ausdruck „Beispiel“, dass er als nicht einschränkendes Beispiel, Variante oder Darstellung dient. Wie hierin verwendet, führen die Begriffe „zum Beispiel“ und „z. B.“ eine Liste von einem oder mehreren nicht einschränkenden Beispielen, Varianten oder Darstellungen ein.
BESCHREIBUNG DER AUSFÜHRUNGSFORMEN
Die vorliegende Erfindung betrifft technische Gebiete von Kryptographie-basiertem elektronischem Geld (CBEM), wie zum Beispiel alternative Kryptowährungen und Transaktionssysteme. Insbesondere betrifft die vorliegende Erfindung ein Verfahren und System zum Erzeugen eines neuen CBEM und des zugehörigen Zahlungssystems, das die Offenlegung der tatsächlichen persönlichen Identitäten von Sendern und Empfängern in allen Geldtransaktionen ermöglicht, während die pseudonyme Eigenschaft des CBEM erhalten wird.
Die vorliegende Erfindung ermöglicht die Einbeziehung zusätzlicher Module zur Überwachung aller Transaktionen und zur Identifizierung derjenigen, die möglicherweise mit illegalen Aktivitäten in Verbindung stehen, und zur Aufnahme von Kriterien, die von einem zentralen Verwaltungsorgan oder von CBEM-Nutzern definiert werden, um Transaktionen zu regulieren oder zu begrenzen.
Als Ergebnis liefert die vorliegende Erfindung eine praktische Lösung für die Probleme im Zusammenhang mit Kryptowährungsdiebstahl, KYC und AML, während die Privatsphäre der Nutzer gewahrt bleibt. Darüber hinaus kann die vorliegende Erfindung von den Zentralbanken oder anderen Finanzinstitutionen übernommen oder modifiziert werden, um ihre eigenen digitalen Währungen auszugeben, die durch ein Distributed Ledger-Zahlungssystem unterstützt werden, aber auch von einem zentralen Verwaltungsorgan reguliert werden.
Zu diesem Zweck umfasst die vorliegende Erfindung eine Integration von drei Hauptverfahren, unter anderem (i) Identitätsüberprüfung, (ii) Authentifizierung von Anmeldeinformationen und (iii) ein Zwei-Parteien-Signaturschema. Ausführungsformen der vorliegenden Erfindung können Systeme und Verfahren zum Erzeugen eines CBEM und seines zugehörigen Bezahlsystems vorsehen, die es einem zentralen Verwaltungsorgan ermöglichen, tatsächliche persönliche Identitäten von Sendern und Empfängern bei beliebigen Geldtransaktionen offenzulegen, während die pseudonyme Eigenschaft des CBEM erhalten wird.
Der Anmeldeinformations-Authentifizierungsmechanismus der vorliegenden Erfindung ermöglicht es einem Nutzer, die Anmeldeinformationen zu ändern, um zu verhindern, dass Münzen aus einem gestohlenen Wallet übertragen werden. Und schließlich können, da Sender und Empfänger aller Transaktionen offengelegt werden können, der eine oder die mehreren Diebstähle oder Hacker, die die Münzen gestohlen haben, leicht durch Abrufen der einen oder mehreren persönlichen Identität des einen oder der mehreren Empfänger aus der Client-Informationsdatenbank ermittelt werden. Folglich können die Ausführungsformen der vorliegenden Erfindung verhindern, dass CBEM-Münzen gestohlen werden.
Um persönliche Identitäten von Sendern und Empfängern aller Transaktionen eines CBEM offenlegen zu können, benötigt es die folgenden zwei Schlüsselelemente:

i. tatsächliche persönliche Identitäten aller Empfänger und Sender eines CBEM;
ii. Verbot, dass anonyme Personen Münzen eines CBEM empfangen und senden;

Diese zwei Schlüsselelemente können erhalten werden, indem nur registrierte Nutzer mit einer verifizierten tatsächlichen persönlichen Identität ein CBEM empfangen und senden können. Für die Erfassung und Verifizierung persönlicher Identitäten wird eine webbasierte Registrierungsschnittstelle erstellt, die es einzelnen Registranten ermöglicht, Informationen zu übermitteln, um seine/ihre tatsächliche persönliche Identität zu übermitteln und nachzuweisen, und nur Personen mit einer erfolgreich verifizierten persönlichen Identität werden als gültige Nutzer akzeptiert. Sie können dann das CBEM empfangen und senden. Die Hauptschwierigkeit besteht jedoch darin, zu verhindern, dass anonyme Personen Münzen eines CBEM, insbesondere eines Open-Source-CBEM, empfangen und senden.
CBEMs, wie Bitcoin, sind als dezentrales Zahlungssystem konzipiert. Es wird erwartet, dass ihre Computerprogrammcodes für jedermann in der Open-Source-Online-Community zu Prüfung zur Verfügung gestellt werden können. Wenn ein CBEM Open Source ist, kann jeder den Quellcode verwenden, um seine/ihre Währungsadresse zum Empfangen und Senden der Münzen zu erstellen. Daher kann der KYC-Registrierungsansatz nur auf bestimmte Diensteanbieter angewendet werden, nicht jedoch auf alle Münzen-Nutzer.
Um die Münznutzung auf nur registrierte Nutzer zu beschränken, wurde ein neues Verfahren entwickelt, um von registrierten, nicht anonymen Nutzern erzeugte Währungsadressen (d. h. gültige Währungsadressen) von denen zu unterscheiden, die von nicht registrierten anonymen Nutzern erzeugt wurden (d. h. ungültige Währungsadressen), und ein weiteres Verfahren wurde entwickelt, um nur diese gültigen Währungsadressen zum Empfangen und Senden von Münzen zu verwenden.
Die vorliegende Erfindung sieht eine praktische Lösung für diese zwei Aufgaben durch eine Integration von drei Hauptverfahren vor, unter anderem (i) Identitätsüberprüfung, (ii) Authentifizierung von Anmeldeinformationen und (iii) ein Zwei-Parteien-Signaturschema. Eine solche Integration erfordert technische Änderungen durch:

(1) Modifizieren des Bitcoin-Multisignatur-Transaktionsprotokolls;
(2) seine Verknüpfung mit einer Client-Informationsdatenbank;
(3) seine Festlegung als verpflichtendes Transaktionsprotokoll; und
(4) Erzwingen, dass eine Transaktionssignatur ein privater Schlüssel von einem der zentralen Genehmigungsserver ist.

Die Ausführungsformen der vorliegenden Erfindung können durch die folgenden Hauptschritte erreicht werden:

Schritt 1: Einrichten eines Computerservers und einer webbasierten Schnittstelle zum Erfassen, Verifizieren und Speichern persönlicher Identitäten von Nutzern und zum Erstellen benutzerspezifischer Anmeldeinformationen;
Schritt 2: Verwenden der webbasierten Nutzerschnittstelle zum Erstellen von Anmeldeinformationen zum Regulieren des Vorgangs der Erstellung von Währungsadressen;
Schritt 3: Verwenden eines Multisignatur-Ansatzes zum Empfangen und Senden von Münzen; und
Schritt 4: Erzwingen von Pay-to-Script-Hash-Transaktionen, die durch bestimmte Regeln reguliert sind.

Die zuvor erwähnten Schritte werden nun detaillierter beschrieben.
Schritt 1: Einrichten eines Computerservers und einer webbasierten Schnittstelle zum Erfassen, Verifizieren und Speichern persönlicher Identitäten von Nutzern und zum Erstellen benutzerspezifischer Anmeldeinformationen
Der Schritt des Einrichtens eines Computerservers und einer webbasierten Schnittstelle (z. B. BGCwallet.com) für Nutzer eines CBEM (z. B. Aten Coin). Beim Vorgang der Registrierung sollte eine Person Dokumente/Informationen über seine/ihre persönliche Identität (z. B. Pass-Seriennummer und Kopie der Datenseite seines/ihres Passes) zur Verfügung stellen und ein Verfahren zum Verifizieren seiner/ihrer persönlichen Identität durchlaufen (z. B. den Identitätsprüfungsdienst von MiiCard oder IDchecker). Eine erfolgreiche Registrierung erfordert ein erfolgreiches Verifizieren seiner/ihrer persönlichen Identität. Alle bereitgestellten Informationen werden in einer Client-Informationsdatenbank gespeichert.
1 zeigt ein Registrierungs- und Datenbanksystem zum Erfassen, Verifizieren und Speichern der tatsächlichen persönlichen Identität eines neuen Nutzers für ein Kryptographie-basiertes elektronisches Geld.
Mindestens ein Server, der mindestens eine webbasierte Registrierungsschnittstelle (102) umfasst, führt die folgenden Funktionen aus. Zuerst wird in Schritt (105) über die webbasierte Registrierungsschnittstelle (102) eine Übermittlung von Dokumenten zum Nachweis der tatsächlichen persönlichen Identität eines Registranten angefordert. Als nächstes wird in Schritt (106) die Verifizierung der tatsächlichen persönlichen Identität des Registranten durchgeführt. Eine erfolglose Verifizierung führt zu einem Registrierungsfehler (107). Alternativ dazu kann ein erfolgreicher Registrant (109) eine Zwei-Faktor-Authentifizierung oder eine Multi-Faktor-Authentifizierung (104) erstellen, um einen nicht autorisierten Zugriff auf sein/ihr registriertes Nutzerkonto und böswillige Angriffe zu verhindern.
Die Zwei-Faktor-Authentifizierung ist ein sicheres Verfahren zum Schutz eines Online-Nutzerkontos (104). Sie funktioniert so, dass ein Nutzer sich mit zwei verschiedenen Objekten identifizieren muss, wenn er/sie sich in seinem/ihrem Online-Konto anmeldet. Das erste Authentifizierungsobjekt ist ein Paar aus Login-Name und Login-Passwort, die vom Nutzer erstellt werden; das zweite Authentifizierungsobjekt ist ein sich ständig änderndes Token (z. B. ein eindeutiger 7-stelliger Code), das an ein physisches Gerät gebunden ist, das dem Nutzer gehört, beispielsweise ein Mobiltelefon oder ein personalisiertes Gerät zum Erzeugen eines sicheren Schlüssels. Dann kann ein solches Online-Nutzerkonto nicht gehackt werden, ohne das persönliche physische Gerät zu stehlen. Eine Multi-Faktor-Authentifizierung kann auch möglich sein, bei der ein Nutzer sich bei Anmeldung in seinem/ihrem Online-Konto mit drei oder mehr verschiedenen Objekten identifizieren muss (z. B. einem Paar von Login-Namen und Login-Passwort, einem Mobiltelefon und einem intelligenten Personalausweis).
Ein erfolgreicher Registrant (109) muss Anmeldeinformationen (111) erstellen, die eine Kennung und ein Passwort (112) umfassen. Natürlich kann ein erfolgreicher Registrant (109) die Anmeldeinformationen und Kontaktinformationen (113) ändern, die alle vorzugsweise in Schritt (114) verschlüsselt werden. Die Anmeldeinformationen werden benötigt, damit ein Nutzer seine/ihre eine oder mehreren Wallet-Multisignaturadressen ( 2) zum Empfangen von Münzen (z. B. Atencoins) und zum Erstellen von Transaktionen ( 3) erzeugen kann.
Optional können bei Schritt 502 Client-Transaktionskriterien durch einen gültig registrierten Nutzer definiert werden, um seine/ihre eigenen Transaktionen zu begrenzen. Zum Beispiel kann ein Nutzer ein Kriterium festlegen, das die maximale Menge an Münzen begrenzt, die von seiner/ihrer einen oder mehreren Währungsadressen innerhalb von 24 Stunden gesendet werden können. Dies kann den Verlust seiner/ihrer Münzen minimieren, wenn sein/ihr Währungs-Wallet gestohlen oder gehackt wurde.
Wenn das Obige abgeschlossen ist, wird in Schritt (116) das Speichern aller übermittelten Informationen, insbesondere der persönlichen Identität und der verschlüsselten Anmeldeinformationen, in der Client-Informationsdatenbank (115) ausgeführt.
Schließlich wird in Schritt 117 das Senden der verschlüsselten Anmeldeinformationen, die neu erzeugt oder geändert wurden, an zentrale Genehmigungsserver (401) ausgeführt. Die zentralen Genehmigungsserver führen das Zuordnen und Speichern der einen oder mehreren Multisignatur-Währungsadressen, der Anmeldeinformationen und der persönlichen Identität einzelner Registranten (118) aus. Zum Beispiel ist eine Multisignatur-Währungsadresse eine eindeutige Zeichenfolge aus 34 Zeichen, die aus numerischen Zahlen, kleinen und großen Buchstaben besteht (z. B. Aj8xFoZUjo3GoNvi95kABpTjO2qQReZo5P);
die persönliche Identität besteht aus (i) einem vollständigen, auf dem Personalausweis oder Reisepass des Nutzers aufgedruckten gesetzlichen Namen, (ii) Personalausweis-/Reisepassnummer und (iii) Geburtsdatum.
Schritt 2: Verwenden der webbasierten Nutzerschnittstelle zum Erstellen von Anmeldeinformationen zum Regulieren des Verfahrens der Währungsadressenerzeugung
Unter Verwendung der webbasierten Schnittstelle kann nur ein gültig registrierter Nutzer (106,109) Anmeldeinformationen (111) erzeugen (1, 112), die zum Erzeugen seiner/ihrer einen oder mehreren Multisignaturadressen benötigt werden (wie in 2 gezeigt), um Münzen (z. B. Atencoins) zu empfangen und zu senden (wie in 3 gezeigt). Die Verwendung von Anmeldeinformationen verhindert, dass nicht registrierte, anonyme Nutzer gültige Multisignaturadressen erzeugen, um Münzen im System zu empfangen und zu senden. Mit anderen Worten sind alle gültigen Währungsadressen zum Senden oder Empfangen von Münzen eines CBEM tatsächlichen Personen mit bekannten, tatsächlichen persönlichen Identitäten zugeordnet.
Schritt 3: Verwenden eines Multisignatur-Ansatzes zum Empfangen und Senden von Münzen
Konstruktionsgemäß sind für die Erstellung gültiger Multisignaturadressen für das Empfangen und Senden von Münzen ein öffentlicher Genehmigungsschlüssel von einem der zentralen Genehmigungsserver und mindestens ein öffentlicher Client-Schlüssel erforderlich (2). Bevor man das Client-Wallet (301) verwenden kann, um eine Adresse zum Empfangen von Münzen zu erzeugen, muss er/sie seine/ihre Anmeldeinformationen (111) in das Client-Wallet eingegeben haben. Im Verfahren der Adresserzeugung übermittelt das Client-Wallet zuerst die Anmeldeinformationen an einen der zentralen Genehmigungsserver (401) über ein elektronisches/digitales Datenübertragungsnetzwerk (z. B. das Internet) zur Validierung (407).
Nach der Überprüfung, ob die Anmeldeinformationen gültig sind, d. h. nach einem erfolgreichen Abgleich mit gültigen und aktiven Anmeldeinformationen in der Datenbank der zentralen Genehmigungsserver (319, 401, 407), stellt der zentrale Genehmigungsserver den öffentlichen Genehmigungsschlüssel (408) dem Client-Wallet durch das elektronische/digitale Datenübertragungsnetz bereit. Wenn die Anmeldeinformationen als ungültig oder inaktiv befunden werden, gibt der zentrale Genehmigungsserver eine Fehlernachricht an das Client-Wallet zurück. Nach dem Erhalt des öffentlichen Genehmigungsschlüssels fährt das Client-Wallet mit dem Erzeugen einer Multisignaturadresse fort (315).
Nach dem Erhalt der Fehlernachricht stoppt das Client-Wallet das Verfahren der Multisignaturadresserzeugung. In Anwesenheit des öffentlichen Genehmigungsschlüssels erzeugt (309) das Client-Wallet ein Paar aus öffentlichem Client-Schlüssel (307) und privatem Client-Schlüssel (308) und speichert sie (310) in dem Client-Wallet und kombiniert anschließend den öffentlichen Genehmigungsschlüssel (405) und den öffentlichen Client-Schlüssel (307), um eine Multisignaturadresse zu erzeugen (315), die somit eng mit dem privaten Genehmigungsschlüssel und dem privaten Client-Schlüssel verknüpft ist. Die Multisignaturadresse wird gespeichert und in dem Client-Wallet angezeigt (316). Der Nutzer kann die Multisignaturadresse verwenden, um Münzen eines CBEM (z. B. Atencoins) zu empfangen.
Die Anwesenheit des öffentlichen Genehmigungsschlüssels in jeder Multisignaturadresse erzwingt, dass alle Transaktionen sowohl die Genehmigungssignatur (d. h. den privaten Genehmigungsschlüssel (406)) von einem der zentralen Genehmigungsserver als auch die Client-Signatur (d. h. den privaten Client-Schlüssel (308)) erhalten müssen, um Validität zu erlangen.
Unter Verwendung dieses Steuersystems können nur gültig registrierte Nutzer Multisignaturadressen erzeugen. Diese Adressen können dann verwendet werden, um Transaktionen auszuführen, die von einem der zentralen Genehmigungsserver gegengezeichnet werden müssen.
2 zeigt ein Authentifizierungssystem für Anmeldeinformationen, die einer persönlichen Identität zugeordnet sind, das zur Erzeugung einer Multisignatur-Währungsadresse zum Empfangen und Senden eines Kryptographie-basierten elektronischen Geldes dient.
Das Verfahren beginnt bei Schritt (301) mit der Bereitstellung eines Client-Wallets, das eine Netzwerkressource ist, auf die vorzugsweise als Software zugegriffen werden kann. Als nächstes werden die eingegebenen Nutzer-Anmeldeinformationen von Schritt (111) angewendet, um das Wallet eines Kunden zu aktivieren. Anschließend versucht ein Nutzer bei Schritt (314), eine Währungsadresse zu erzeugen, wobei das System nur Währungsadressen erzeugt, bei denen es sich um Multisignaturadressen handelt. Als nächstes wird in Schritt (319) das Übermitteln von Anmeldeinformationen von gültig registrierten Nutzern an einen der zentralen Genehmigungsserver (401) ausgeführt, um eine Genehmigung zum Erzeugen einer oder mehrerer gültiger Multisignaturadressen zu erhalten.
Bei fehlgeschlagener Genehmigung kann eine entsprechende Fehlermeldung erzeugt werden. Andernfalls wird im Fall der Genehmigung in Schritt (309) das Erzeugen eines oder mehrerer Paare eines kryptographischen öffentlichen Client-Schlüssels (307) und privaten Client-Schlüssels (308) zum Empfangen und Senden von Münzen ausgeführt. Dieser öffentliche Client-Schlüssel und private Client-Schlüssel werden gespeichert und dem Wallet des Kunden zugeordnet (310). Im Falle einer Genehmigung wird auch bei Schritt 408 das Bereitstellen eines öffentlichen Genehmigungsschlüssels (405), der mathematisch mit einem privaten Genehmigungsschlüssel (406) verknüpft ist, von dem zentralen Genehmigungsserver an das Client-Wallet ausgeführt.
Ferner wird bei Schritt (315) das Erzeugen einer oder mehrerer Multisignaturadressen aus dem einen oder den mehreren öffentlichen Client-Schlüsseln (307) und dem einen oder den mehreren öffentlichen Genehmigungsschlüsseln (405) ausgeführt. Die erzeugte Multisignatur-Währungsadresse wird gespeichert und dem Wallet des Kunden zugeordnet (316).
Anschließend wird in Schritt (317) das Senden der einen oder mehreren Multisignaturadressen an die Client-Informationsdatenbank (115) zum Speichern und Zuordnen zu der persönlichen Identität des Besitzers der einen oder mehreren Adressen (118) ausgeführt.
Schritt 4: Erzwingen von Pay-to-Script-Hash-Transaktionen, die durch bestimmte Regeln reguliert werden
Bitcoin-Entwickler haben derzeit zwei verschiedene Verfahren zum Erstellen und Genehmigen von Bitcoin-Transaktionen mit unterschiedlichen scriptSig/scriptPubKey-Paaren erstellt. Die beiden Verfahren sind Pay-to-Pubkey-Hash und Pay-to-Script-Hash.
Der Pay-to-Pubkey-Hash ist das am häufigsten verwendete Verfahren in täglichen Bitcoin-Transaktionen. In einer Pay-to-Pubkey-Hash-Transaktion ist eine Bitcoin-Adresse ein 160-Bit-Hash des öffentlichen Teils eines öffentlich/privaten Elliptic Curve Digital Signature Algorithm- (ECDSA) -Schlüsselpaars und ein Bitcoin-Sender stellt eine Bitcoin-Adresse in scriptPubKey bereit. Bei einer Pay-to-Pubkey-Hash-Transaktion überträgt ein Sender Bitcoins direkt an einen Besitzer eines öffentlichen Schlüssels.
Um eine Pay-to-Pubkey-Hash-Transaktion zu initiieren, muss der Sender einen öffentlichen Schlüssel, dessen Bitcoins an der zugehörigen Bitcoin-Adresse gespeichert sind, und die zugehörige Signatur (d. h. einen zugehörigen privaten Schlüssel) sowie eine Bitcoin-Adresse bereitstellen, um die Bitcoins zu empfangen. Die empfangende Bitcoin-Adresse ist direkt mit dem zugehörigen öffentlichen Schlüssel und der Signatur verknüpft. Beim Einlösen von Münzen, die an die Bitcoin-Adresse gesendet wurden, stellt der Empfänger sowohl die Signatur als auch den öffentlichen Schlüssel zur Verfügung. Das Skript verifiziert, ob der bereitgestellte öffentliche Schlüssel auf den Hashwert in scriptPubKey hasht, und überprüft dann auch die Signatur anhand des öffentlichen Schlüssels.
Adressen, die mit Pay-to-Script-Transaktionen verknüpft sind, sind Hashs von Skripten anstelle von Hashs von öffentlichen Schlüsseln. Um Bitcoins über Pay-to-Script-Hash ausgeben zu können, muss das Verfahren ein Skript bereitstellen, das zu dem Skript-Hash und den Daten passt, wodurch das Skript als wahr bewertet wird. Mit anderen Worten muss man dem fraglichen Skript eine Eingabe (d. h. eine Antwort) bereitstellen, die das Skript akzeptiert, und die Transaktion wird fortgesetzt. Wenn die Eingabe ungültig ist und das Skript sie nicht akzeptiert, führt dies zum Abbruch der Transaktion.
Mit Pay-to-Script-Hash kann man Bitcoins an eine Adresse senden, die auf verschiedene ungewöhnliche Arten abgesichert ist, ohne etwas über die Details zu wissen, wie die Sicherheit eingerichtet ist. Zum Beispiel könnte der Empfänger die Signaturen mehrerer Personen benötigen, um Bitcoins zu erhalten, die an einer bestimmten Bitcoin-Adresse gespeichert sind, oder ein Passwort könnte erforderlich sein, oder die Anforderungen könnten vollständig individuell sein. Für Bitcoin und alle anderen heutigen Kryptowährungen, die auf Basis der Bitcoin-Technologie entwickelt wurden, ist Pay-to-Script-Hash nicht zwingend erforderlich.
Der Pay-to-Pubkey-Hash ist das Standardverfahren in Bitcoin-Transaktionen sowie in den Transaktionen für alle anderen heutigen Kryptowährungen auf Basis der Bitcoin-Technologie. Die Pay-to-Script-Hash-Funktion ist in der Client-Wallet-Software einer Kryptowährung integriert. Ein Kryptowährungsbesitzer kann die Client-Wallet-Software dazu verwenden, Pay-to-Pubkey-Hash oder Pay-to-Script-Hash zum Erstellen von Transaktionen zu verwenden.
Gemäß der vorliegenden Erfindung sind in dem CBEM-Transaktionsnetzwerk nur Pay-to-Script-Hash-Transaktionen erlaubt. Im Gegensatz zu Bitcoin und allen anderen aktuellen Kryptowährungen, die auf der Bitcoin-Technologie basieren, wird diese Einschränkung in den Quellcodes des CBEM implementiert und nicht nur in dem Quellcode der Client-Wallet-Software. Auf diese Weise kann ein CBEM-Entwickler in allen Transaktionen spezifische Regeln durchsetzen und dies ermöglicht die Implementierung eines Authentifizierungssystems für Anmeldeinformationen, die der persönlichen Identität zugeordnet sind, um alle Transaktionen zu steuern. Das Authentifizierungssystems für Anmeldeinformationen, die der persönlichen Identität zugeordnet sind, beinhaltet die Verwendung von benutzerspezifischen Anmeldeinformationen und Multisignaturadressen zum Empfangen und Senden des CBEM.
In dem Authentifizierungssystem für Anmeldeinformationen, die der persönlichen Identität zugeordnet sind, werden nur Multisignaturadressen in den Pay-to-Script-Hash-Transaktionen zum Empfangen und Senden des CBEM verwendet. Jede Client-Multisignaturadresse ist mit einem Skript verknüpft, das einen öffentlichen Client-Schlüssel (der von dem Client-Wallet erzeugt wird) (307) und einen öffentlichen Genehmigungsschlüssel (der von einem der zentralen Genehmigungsserver erzeugt wird) (405) enthält, um Transaktionen zu erzeugen und zu signieren. Daher erfordert jede Pay-to-Script-Hash-Transaktion mindestens einen privaten Client-Schlüssel (308) und einen privaten Genehmigungsschlüssel (406), um die Transaktion gültig zu machen.
Das Skript für Pay-to-Script-Hash-Transaktionen ist in den Quellcodes des CBEM implementiert und nicht nur in den Client-Wallets. Dadurch kann das Skript die Anforderung eines oder mehrerer privater Genehmigungsschlüssel (406) von einem oder mehreren zentralen Genehmigungsservern zum Initialisieren und Signieren aller Transaktionen erzwingen. Da die Bereitstellung der privaten Genehmigungsschlüssel über die zentralen Genehmigungsserver reguliert werden kann, kann niemand eine Pay-to-Pubkey-Hash- oder Pay-to-Script-Hash-Transaktion erstellen, die die Anforderungen, Vorschriften und/oder Regeln umgehen kann, die auf den zentralen Genehmigungsservern vorgegeben sind.
3 zeigt ein Authentifizierungssystem für Anmeldeinformationen, die der persönlichen Identität zugeordnet sind, und das Zwei-Parteien-Signaturschema zur Erzeugung einer Zahlungstransaktion einer Menge von Münzen, die einem Nutzer gehören und an einer Multisignaturadresse verzeichnet sind.
Um eine Pay-to-Script-Hash-Transaktion (218) zu erzeugen, benötigt ein Wallet (301) eines Kunden eine Signatur (d. h. einen privaten Genehmigungsschlüssel) (406) von einem der zentralen Genehmigungsserver (401), um eine Genehmigung zu erhalten. Diese Anfrage wird mit einem API-Aufruf zur Authentifizierung an die zentralen Genehmigungsserver gesendet (220). Bei einem Scheitern der Authentifizierung kann eine entsprechende Fehlermeldung erzeugt werden.
Wenn die von dem Client-Wallet an die zentralen Genehmigungsserver (401) übermittelten Anmeldeinformationen gültig sind (220, 409) und diese angeforderte Transaktion gemäß vorgegebenen Kriterien (501, 502) nicht als verdächtig betrachtet wird, erhält sie die Signatur von dem Client-Wallet (d. h. den privaten Client-Schlüssel) (308) und die Signaturen (d. h. den einen oder die mehreren privaten Genehmigungsschlüssel) (406, 411) von einem der zentralen Genehmigungsserver, um die Transaktion zu genehmigen (410, 412).
Das Skript eines Pay-to-Script-Hashs kann so geändert werden, dass mehr als ein öffentlicher Client-Schlüssel und/oder privater Genehmigungsschlüssel erforderlich sind, was zu Zahlungstransaktionen führt, die mehr als eine Signatur von einem oder mehreren Nutzern (entweder Sendern oder Empfängern) und/oder einer oder mehreren Genehmigungsbehörden benötigen, um eine Transaktion auszuführen. Um die Sicherheit zu erhöhen, können außerdem zwei verschiedene private Genehmigungsschlüssel zum Signieren der Transaktionseingabe (410) und zum Signieren der gesamten Transaktion (412) verwendet werden. Die vorliegende Erfindung erzwingt, dass alle Transaktionen mindestens einen privaten Genehmigungsschlüssel von einem zentralen Genehmigungsserver als Signatur erfordern, um eine Transaktion fortzusetzen. Darüber hinaus erfordert die Bereitstellung von privaten Genehmigungsschlüsseln eine erfolgreiche Validierung von gültigen, vom Sender bereitgestellten Anmeldeinformationen. Daher sind alle gültigen Anmeldeinformationen mit einzelnen Client-Wallet-Adressen verknüpft und gehören registrierten Nutzern, deren tatsächliche persönliche Identitäten verifiziert und in der Client-Informationsdatenbank gespeichert wurden (2). Auf diese Weise kann nur ein registrierter Nutzer mit seiner/ihrer tatsächlichen persönlichen Identität, die in der Datenbank gespeichert ist, Münzen von seinen/ihren Wallet-Adressen zu anderen Wallet-Adressen übertragen, wenn er gültige Anmeldeinformationen übermittelt.
Die Anmeldeinformationen stellt eine Verbindung für ein zentrales Verwaltungsorgan bereit, das die zentralen Genehmigungsserver und die Client-Informationsdatenbank besitzt, um bei Bedarf die persönliche Identität eines CBEM-Senders oder -Empfängers aufzudecken. Da im gesamten Verfahren einer Pay-to-Script-Hash-Transaktion keine Informationen über tatsächliche persönliche Identität benötigt werden, bleiben Sender und Empfänger pseudonym.
Ein zentraler Genehmigungsserver kann alle Transaktionen ablehnen, die nicht die zentralen Transaktionskriterien erfüllen (501), die auf mindestens einem der zentralen Genehmigungsserver (401) gespeichert sind. Insbesondere können einzelne Transaktionen mit vorgegebenen Regeln überwacht werden, um verdächtige Transaktionen zu identifizieren, aufzuzeichnen und zu melden, die wahrscheinlich an illegalen Aktivitäten wie Geldwäsche beteiligt sind. Verdächtige Transaktionen und Identitäten der zugehörigen Sender und Empfänger können den zuständigen Regierungsbehörden zur weiteren Bearbeitung gemeldet werden. Die Erfindung stellt somit eine praktische Lösung für die aktuellen KYC/AML-Compliance-Probleme für Bitcoin und verschiedene alternative Währungen bereit.
Optional können bei Schritt 502 Client-Transaktionskriterien durch einen gültig registrierten Nutzer definiert werden, um seine/ihre eigenen Transaktionen zu schützen. Zum Beispiel kann ein Nutzer ein Kriterium festlegen, das die maximale Menge an Münzen begrenzt, die von seiner/ihrer einen oder mehreren Währungsadressen innerhalb von 24 Stunden gesendet werden. Dies kann den Verlust seiner/ihrer Münzen minimieren, wenn sein/ihr Währungs-Wallet gestohlen oder gehackt wurde.
Die Transaktion wird dann an das Netzwerk von Knoten (214) zur Bestätigung gesendet (305). Nachdem eine Transaktion erzeugt wurde, wird sie zur Verarbeitung an das Transaktionsnetzwerk gesendet und muss in einen Block der Blockchain eingefügt werden, bevor sie legitim wird. Knoten akzeptieren den Block nur, wenn alle darin enthaltenen Transaktionen gültig (d. h. korrekt signiert) sind und nicht bereits ausgegeben wurden. Knoten drücken ihre Akzeptanz des Blocks aus, indem sie daran arbeiten, den nächsten Block in der Kette zu erzeugen, wobei der Hash des akzeptierten Blocks als vorheriger Hash verwendet wird.
Der Vorgang der Implementierung einer Transaktion in einen neu erstellten Block wird Transaktionsbestätigung genannt. Die Aufnahme in einen Block gilt als Bestätigung. Wenn es ebenso viele oder mehr Bestätigungen als eine vorgegebene Anzahl gibt (z. B. 6 bei Bitcoin, 10 bei Aten Coin), gilt die Transaktion als bestätigt. Bei der Bitcoin-Technologie wurde diese Funktion eingeführt, um das System vor wiederholtem Ausgeben (d. h. mehrfachem Ausgeben) derselben Münzen zu schützen.
Die einzigartigen Funktionen der in 1-3 gezeigten Anordnung sind:

Gestatten der Erzeugung nur von Multisignaturadressen (313) als gültige Währungsadressen; (314) Gestatten der Erzeugung nur von Transaktionen, die Multisignaturadressen (313) sowohl zum Senden als auch zum Empfangen der Münzen verwenden; (321) Gestatten der Erzeugung von Transaktionen nur im Pay-to-Script-Hash-Format (218); (311) Gestatten der Erzeugung nur von Transaktionen, die jeweils mindestens zwei private Schlüssel als Signaturen benötigen;
(308, 406) Beschränken eines dieser privaten Schlüssel (308, 406) auf einen privaten Genehmigungsschlüssel (406) von einem der zentralen Genehmigungsserver (401); Beschränken des Rests der privaten Schlüssel (308, 406) auf private Client-Schlüssel (308), die verschlüsselt und in dem einen oder den mehreren Client-Wallets (301) gespeichert sind; Beschränken der Erzeugung von gültigen Anmeldeinformationen (111) nur auf gültig registrierte Nutzer (109);
(112) Beschränken der Erzeugung einer oder mehrerer gültiger Multisignatur-Währungsadressen (313) zum Empfangen von Münzen nur auf Nutzer mit gültigen Anmeldeinformationen (111) durch Verifizieren der übermittelten Anmeldeinformationen (111) durch einen der zentralen Genehmigungsserver (401);
(319, 407) Beschränken der Erzeugung einer oder mehrerer gültiger Transaktionen nur auf Nutzer, die gültige Anmeldeinformationen (111), eine oder mehrere gültige Multisignatur-Währungsadressen (313) und die zugehörigen privaten Client-Schlüssel (308, 309) haben;
(220, 320, 409) Beschränken des Empfangens eines oder mehrerer privater Genehmigungsschlüssel (406, 411) von einem der zentralen Genehmigungsserver (401) zum Signieren einer oder mehrerer Transaktionen (410, 412) nur auf Nutzer, die gültige Anmeldeinformationen (111) haben, durch Verifizieren (220, 320, 409) der übermittelten Anmeldeinformationen (111) durch einen der zentralen Genehmigungsserver (401); Beschränken des Erzeugens von gültigen Transaktionen nur auf Nutzer, die einen oder mehrere private Genehmigungsschlüssel (406, 411) von einem der zentralen Genehmigungsserver (401) erhalten haben, durch Verifizieren (220, 320, 409) der übermittelten Anmeldeinformationen (111) durch einen der zentralen Genehmigungsserver
(401) und daher Beschränken des Erzeugens von gültigen Transaktionen nur auf Nutzer, die gültige Anmeldeinformationen haben (111);
Verknüpfen einzelner Anmeldeinformationen (111, 112, 113, 114) mit den tatsächlichen persönlichen Identitäten der Nutzer (105);
(1) Verwenden einzelner Anmeldeinformationen (1, 111), um die wahren persönlichen Identitäten ihrer Besitzer zu ermitteln (105);
(116) Verknüpfen einzelner Multisignaturadressen (313, 314) mit den Anmeldeinformationen des Nutzers (111);
(2) Verwenden einzelner Multisignaturadressen (313) zum Ermitteln (118) von Anmeldeinformationen (111) ihrer Besitzer (2) und folglich Verwenden der Anmeldeinformationen (111) zum Ermitteln (116) tatsächlicher persönlicher Identitäten (105) der Besitzer (1);
Verwenden einzelner Transaktionen zum Ermitteln von Multisignaturadressen (313) von Sendern und Empfängern (3), anschließendes Verwenden der Multisignaturadressen (313) zum Ermitteln (118) von Anmeldeinformationen (111) der Sender und Empfänger ( 2) und schließlich Verwenden der Anmeldeinformationen (1, 111) zum Ermitteln (116) der tatsächlichen persönlichen Identitäten (105) der Sender und Empfänger;
Gestatten der Ermittlung und Verfolgung (116) tatsächlicher persönlicher Identitäten von Sendern (1, 105) und Empfängern in allen gültigen Transaktionen (3), weil nur Nutzer mit gültigen Anmeldeinformationen (111) gültige Multisignaturadressen erzeugen können (2) und gültige Transaktionen erzeugen können (3).

4 zeigt ein Diagramm des Systems gemäß der vorliegenden Erfindung. Das System ist eine Client-Server-Anordnung, bei der der Server aus einem oder mehreren zentralen Genehmigungsservern besteht.
Der Client und der Server können Datenverarbeitungsressourcen umfassen, die unter Verwendung dedizierter Komponenten oder kundenspezifischer FPGA- oder ASIC-Schaltungen realisiert werden können. Diese Rechenressourcen sind geeignet, Software zu speichern und auszuführen, die Schritte des Verfahrens gemäß der vorliegenden Erfindung implementiert.
Der zentrale Genehmigungsserver (401) verarbeitet Client-Registrierungsanfragen (1), Client-Kryptowährungsadressen (2), Client-Kontoaktualisierungsanfragen sowie Kryptowährungstransaktionen (3). Der zentrale Genehmigungsserver (401) arbeitet somit mit einer Client-Informationsdatenbank (404) (z. B. Nutzer X: gesetzlicher Name, Geburtsdatum, Anschrift, Kontaktadresse, Anmeldeinformationen, Kryptowährungsadresse, Transaktionskriterien) sowie mit einer Transaktionsdatenbank (413) (z. B. Transaktion Y: Transaktions-ID, Kryptowährungsadressen des Senders und des Empfängers, Menge der übertragenen Münzen, Transaktionszeitpunkt und IP-Adresse des Client-Wallets des Senders und Empfängers) zusammen.
Tatsächliche persönliche Identitäten von Besitzern für einzelne Währungsadressen sind in der Client-Informationsdatenbank gespeichert (1, 115). Dies erfüllt die behördliche Anforderung „Know-Your-Customer“ und ermöglicht die Nutzung des Systems als Zahlungssystem für kommerzielle Aktivitäten. Diese Informationen sind jedoch für die Öffentlichkeit nicht zugänglich, um die pseudonyme Eigenschaft des CBEM und seines Transaktionsnetzwerks zu erhalten.
Wenn Münzen von jemandem gestohlen werden, können der oder die Diebstähle oder Hacker leicht ermittelt werden, indem die eine oder mehreren persönlichen Identitäten des einen oder der mehreren Empfänger aus der Client-Informationsdatenbank (115) abgerufen werden. Daher verhindert die Implementierung des Systems, dass Münzen des CBEM gestohlen werden.
Aufgrund der pseudonymen oder anonymen Natur von Bitcoin und alterativen Kryptowährungen, die auf der Bitcoin-Technologie basieren, ist das Münzguthaben einzelner Münzbesitzer nicht ermittelbar, indem nur die in der Blockchain gespeicherten öffentlichen Transaktionsdatensätze analysiert werden. Des Weiteren wird absichtlich, wenn man nur einen Teil der an einer bestimmten Währungsadresse verzeichneten Münzen ausgibt, die Menge nicht ausgegebener Münzen an einer neu erzeugten Währungsadresse verzeichnet. Durch die Analyse der Blockchain ist es für eine dritte Partei rechenintensiv zu verfolgen, wohin eine empfangene Summe von Münzen schließlich übertragen und an welcher Adresse sie verzeichnet wurde.
Mit der vorliegenden Erfindung ist eine Menge von Münzen, die einem gültig registrierten Nutzer gehört, durch das zentrale Verwaltungsorgan durch Analyse der Transaktionsdatensätze in der Transaktionsdatenbank (413) vollständig ermittel- und verfolgbar. Neben der Fähigkeit, einzelne Währungsadressen mit ihren Besitzern zu verknüpfen, wird diese einzigartige Eigenschaft des vorliegenden Systems durch die Verzeichnung nicht ausgegebener Münzen (falls vorhanden) an der Währungsadresse, von der die Münzen gerade gesendet/ausgegeben wurden, verbessert. Mit anderen Worten wird die Menge der an einer Währungsadresse verzeichneten Münzen erst dann Null, nachdem alle Münzen, die zuvor an diese Adresse gesendet wurden, gesendet/ausgegeben wurden (322). Diese einzigartige Eigenschaft vereinfacht nicht nur das Verfahren eines Drittanbieters zur Ermittlung und Verfolgung der Eigentumsübertragung von Kryptowährungsmünzen durch Analyse der Transaktionsdatensätze in der Blockchain, sondern ermöglicht auch Anwendungen des Systems für Finanz- und Bankaktivitäten, insbesondere solche, die von Dritten geprüft werden müssen.
Der zentrale Genehmigungsserver (401) kommuniziert mit einem oder mehreren Clients (414, 415), die Client-Wallets (416, 417) implementieren.
Ein Nutzer eines Wallets fordert eine Transaktion an, die von einem oder mehreren zentralen Genehmigungsservern validiert werden muss (401). Daher sind die Clients über eine geeignete bidirektionale Datenübertragungsverbindung wie GSM, UMTS, DSL mit den Servern (401) verbunden.
Die Erfindung kann Mittel umfassen, um verdächtige oder nicht autorisierte Transaktionen automatisch zu identifizieren und zu stoppen. Außerdem verhindert diese Erfindung, dass ein CBEM (i) für Geldwäsche verwendet wird und (ii) gestohlen wird. Die vorliegende Erfindung ermöglicht somit, dass das CBEM und sein Transaktionsnetzwerk AML- und KYC-Richtlinien und -Vorschriften einhält. Zum Beispiel kann der PATRIOT OFFICER von GlobalVision Systems, ein fortschrittliches regelbasiertes intelligentes BSA/AML/ATF-System, zur effektiven Automatisierung des BSA/AML/ATF-Workflows durch Überwachung, Screening, Erkennung, Alarmierung, Untersuchung und Analyse verdächtiger Aktivitäten aller Transaktionen eingesetzt werden.
Die Erfindung liefert ein nützliches Ergebnis, das in verbesserter Sicherheit und Rückverfolgbarkeit von Transaktionen liegt. Dieses Ergebnis ist auch konkret und greifbar, da statistische Messungen eine verbesserte Sicherheit und weniger Versuche von CBEM-Diebstahl zeigen. Somit liefert die Erfindung ein nützliches, konkretes und greifbares Ergebnis. Der Arbeits- oder Änderungsbeleg wird durch die Tatsache erfüllt, dass die durch die Mittel der vorliegenden Erfindung erzielte verbesserte Sicherheit Generationen von Multisignaturadressen und Pay-to-Script-Hash-Transaktionen und deren spezifische Modifikationen, Implementierungen und Anwendungen benötigt, wodurch mit Kryptowährungen verbundene Daten transformiert werden. Aufgrund eines spezifischen Implementierungsschemas ist die Idee nicht abstrakt.
Für den Fachmann ist leicht erkennbar, dass das vorgenannte Verfahren zur persönlichen Identifizierung und Verifizierung durch ein oder mehrere Computerprogramme ausgeführt und/oder gesteuert werden kann. Solche Computerprogramme werden üblicherweise unter Verwendung der Rechenressourcen in einem Computergerät ausgeführt. Anwendungen werden auf einem nicht-flüchtigen Medium gespeichert. Ein Beispiel eines nicht-flüchtigen Mediums ist ein nicht-flüchtiger Speicher, beispielsweise ein Flash-Speicher, während ein Beispiel eines flüchtigen Speichers RAM ist. Die Computerbefehle werden von einem Prozessor ausgeführt. Diese Speicher sind beispielhafte Aufzeichnungsmedien zum Speichern von Computerprogrammen, die computerausführbare Befehle umfassen, die alle Schritte des computerimplementierten Verfahrens gemäß dem hier vorgestellten technischen Konzept ausführen.
Während die hier gezeigte Erfindung mit Bezug auf bestimmte bevorzugte Ausführungsformen gezeigt, beschrieben und definiert wurde, implizieren diese Referenzen und Beispiele der Implementierung in der vorstehenden Beschreibung keine Einschränkung der Erfindung. Es ist jedoch offensichtlich, dass verschiedene Modifikationen und Änderungen daran vorgenommen werden können, ohne vom breiteren Umfang des technischen Konzepts abzuweichen. Die gezeigten bevorzugten Ausführungsformen sind nur beispielhaft und nicht erschöpfend für den Umfang des hier vorgestellten technischen Konzepts.
Beispiele der vorliegenden Offenbarung umfassen Folgendes:

Beispiel 1: Verfahren zur persönlichen Identifizierung und Verifizierung von Transaktionen, die Kryptographie-basiertes elektronisches Geld beinhalten, wobei das Verfahren von einem Rechenserver (101) ausgeführt wird, der zum Betreiben eines Computerprogramms als Registrierungsschnittstelle (102) eingerichtet ist, und das Verfahren dadurch gekennzeichnet ist, dass es die nachfolgenden Schritte umfasst:
- - Gewähren des Zugangs für einen oder mehrere potentielle oder bestehende Währungsnutzer (103);
- - Bereitstellen einer Registrierungsschnittstelle (102) für einen oder mehrere potentielle Währungsnutzer zum Registrieren eines Nutzerkontos, das eine Authentifizierung erfordert (104);
- - Anfordern der Übermittlung von Dokumenten zum Nachweis der tatsächlichen persönlichen Identität eines Registranten (105);
- - Verifizieren der tatsächlichen persönlichen Identität des Registranten (106);
- - Ablehnen einer Kontoerstellung für Registranten, deren Verifizierung der persönlichen Identität gescheitert ist (107);
- - Erstellen eines persönlichen Kontos (108) für einzelne erfolgreiche Registranten (109) mit erfolgreicher Verifizierung der persönlichen Identität (110);
- - Gestatten, dass ein erfolgreicher Registrant (109) Anmeldeinformationen (111) erstellt, die eine zugehörige Authentifizierung (112) umfassen;
- - Speichern (116) aller übermittelten Informationen in einer Client-Informationsdatenbank (115);
- - Senden (117) der Anmeldeinformationen an zentrale Genehmigungsserver (401); und
- - Zuordnen und Speichern (118) einer oder mehrerer Multisignatur-Währungsadressen, der Anmeldeinformationen und der persönlichen Identität einzelner Registranten.
Beispiel 2: Das Verfahren von Beispiel 1, wobei tatsächliche persönliche Identitäten von Besitzern für einzelne Währungsadressen in der Client-Informationsdatenbank gespeichert werden.
Beispiel 3: Das Verfahren von Beispiel 1, wobei tatsächliche persönliche Identitäten von Besitzern für einzelne Währungsadressen in der Client-Informationsdatenbank gespeichert werden, wobei diese Informationen für die Öffentlichkeit nicht zugänglich sind, um die pseudonyme Eigenschaft des Kryptographie-basierten elektronischen Geldes (201) und seines Transaktionsnetzwerks (202) zu erhalten.
Beispiel 4: Das Verfahren von Beispiel 1, wobei ein Nutzer die Anmeldeinformationen (111) des Nutzers ändern kann, um zu verhindern, dass Münzen aus einer gestohlenen Hauptdatei des Währungs-Wallets des Nutzers (301) übertragen werden.
Beispiel 5: Das Verfahren von Beispiel 1, wobei (i) tatsächliche persönliche Identitäten von Besitzern für einzelne Währungsadressen in der Client-Informationsdatenbank gespeichert werden, (ii) jegliche Währungsadressen, die nicht durch die Übermittlung von gültigen Anmeldeinformationen an einen der zentralen Genehmigungsserver (401) erzeugt wurden, nicht gültig sind und keine Münzen empfangen können, und (iii) nur gültig registrierte Nutzer gültige Anmeldeinformationen (112) haben.
Beispiel 6: Das Verfahren von Beispiel 1, dadurch gekennzeichnet, dass die Authentifizierung mittels Passwortschutz, Zwei-Faktor-Authentifizierung oder Multi-Faktor-Authentifizierung erfolgt.
Beispiel 7: Das Verfahren von Beispiel 1, dadurch gekennzeichnet, dass es ferner einen Schritt zum Verschlüsseln der Anmeldeinformationen (114) umfasst.
Beispiel 8: Das Verfahren von Beispiel 1, dadurch gekennzeichnet, dass die Anmeldeinformationen ein digitales, elektronisches oder Hardwareobjekt sind, das als ein Authentifizierungsmechanismus verwendet werden kann, um sich zu identifizieren, und das vorzugsweise mindestens eines ist von: einem eindeutigen Paar digitaler Codes, einem eindeutigen Produktschlüssel zum Aktivieren einer Client-Wallet-Software, einem sich ständig ändernden Token, das an ein physisches Gerät gebunden ist, das dem Nutzer gehört, wie beispielsweise ein Mobiltelefon oder ein personalisiertes Gerät zum Erzeugen eines sicheren Schlüssels.
Beispiel 9: Verfahren zum Erzeugen eines Kryptographie-basierten elektronischen Geldes (CBEM) (201) und seines zugehörigen Transaktionsnetzwerks (202), wobei das Verfahren durch ein Netzwerk von Computerprogrammen ausgeführt wird, die als Knoten (203) fungieren, und das Verfahren dadurch gekennzeichnet, dass es die nachfolgenden Schritte umfasst:
- - Installieren eines Knotens (203), der ein eigenständiges Computerprogramm oder ein Funktionsmodul eines Client-Wallets (111) sein kann, in einem oder mehreren Client-Computern und/oder -Servern (204);
- - Verbinden aller Knoten, um Relaisknoten (205) eines Peer-to-Peer-Netzwerks zu bilden, durch ein Datenübertragungsnetzwerk (206);
- - Steuern des Verfahrens zum Erzeugen mindestens einer Einheit des CBEM (207);
- - Schützen des Besitzes von mindestens einer Einheit des CBEM durch Public/Private-Key-Kryptographie (208);
- - Aufzeichnen des Besitzes von mindestens einer Einheit des CBEM in einen Public Ledger (209) unter Verwendung der Währungsadressen des Besitzers (313) (210);
- - Verifizieren des Besitzes von mindestens einer Einheit des CBEM (211);
- - Beschränken des Erzeugens einer oder mehrerer gültiger Währungsadressen (313) zum Empfangen mindestens einer Einheit des CBEM nur auf gültig registrierte Nutzer (109) durch Verifizieren der übermittelten Anmeldeinformationen (111) mit einem der zentralen Genehmigungsserver (401) (212);
- - Aufzeichnen von Transaktionen von mindestens einer Einheit des CBEM in dem Public Ledger (209) (213);
- - Verifizieren von Transaktionen von mindestens einer Einheit des CBEM (214);
- - Steuern des Verfahrens zum Übertragen mindestens einer Einheit des CBEM (215);
- - Integrieren der Transaktionsregeln in den Programmcode von mindestens einem Knoten (216);
- - Beschränken mindestens einer Transaktionsgenehmigungsregel (217), umfassend mindestens eines von: Anfordern von gültigen Anmeldeinformationen (111) vom Sender, Anfordern eines oder mehrerer privater Genehmigungsschlüssel (406) von einem der zentralen Genehmigungsserver (401);
- - Gestatten der Erzeugung von Multisignaturtransaktionen nur im Pay-to-Script-Hash-Format (218);
- - Gestatten der Erzeugung nur von Multisignaturtransaktionen, von denen jede mindestens zwei private Schlüssel als Signaturen benötigt (219);
- - Gestatten der Erzeugung von Multisignaturtransaktionen nur bei Vorliegen von gültigen Anmeldeinformationen (111) (220);
- - Beschränken eines dieser privaten Schlüssel (219) auf einen privaten Genehmigungsschlüssel (406) von einem der zentralen Genehmigungsserver (221);
- - Beschränken des Rests der privaten Schlüssel (219) auf private Client-Schlüssel (222), die verschlüsselt und in dem einen oder den mehreren Client-Wallets (301) gespeichert sind (223);
- - Senden aller Transaktionsanfragen von den Client-Wallets (301) an einen der zentralen Genehmigungsserver (401), um den privaten Genehmigungsschlüssel zum Signieren der Transaktionen zu erhalten (224); und
- - Ablehnen aller Transaktionen, denen einer der erforderlichen privaten Schlüssel fehlt (219); (225).
Beispiel 10: Das Verfahren von Beispiel 9, wobei alle Währungsadressen, die nicht durch die Übermittlung von gültigen Anmeldeinformationen an einen der zentralen Genehmigungsserver (401) erzeugt wurden, nicht gültig sind und keine Münzen empfangen können.
Beispiel 11: Das Verfahren von Beispiel 9, wobei einzelne Transaktionen mit einer definierten Regel überwacht werden können, um verdächtige Transaktionen zu identifizieren, aufzuzeichnen und zu melden, die wahrscheinlich an illegalen Aktivitäten wie beispielsweise Geldwäsche beteiligt sind.
Beispiel 12: Das Verfahren von Beispiel 9, wobei tatsächliche persönliche Identitäten von Besitzern von einzelnen Währungsadressen in der Client-Informationsdatenbank gespeichert sind. Bei Transaktionen, bei denen der Verdacht auf illegale Aktivitäten besteht (Beispiel 11), werden die Identitäten ihrer zugehörigen Sender und Empfänger aus der Client-Informationsdatenbank extrahiert, indem sie mit den Währungsadressen der Sender und Empfänger ermittelt werden. Anschließend werden die verdächtigen Aktivitäten und die damit verbundenen Client-Informationen den Regierungsbehörden unter Berücksichtigung der Vorschriften und Gesetze in den betroffenen Ländern gemeldet.
Beispiel 13: Das Verfahren von Beispiel 9, wobei die Menge an Münzen, die ein gültig registrierter Nutzer besitzt, vollständig und leicht durch das zentrale Verwaltungsorgan (601) durch Analysieren der Transaktionsdatensätze in der Transaktionsdatenbank (413) ermittel- und verfolgbar ist. Neben der Fähigkeit, einzelne Währungsadressen ihren Besitzern zuzuordnen, wird diese einzigartige Eigenschaft durch die Aufzeichnung nicht ausgegebener Münzen (falls vorhanden) an der Währungsadresse, von der die Münzen gerade gesendet/ausgegeben wurden, verbessert (322). Diese einzigartige Eigenschaft ermöglicht Anwendungen unseres Systems für Finanz- und Bankaktivitäten, insbesondere solche, die von Dritten geprüft werden müssen.
Beispiel 14: Verfahren zur persönlichen Identifizierung und Verifizierung von Transaktionen, die Kryptographie-basiertes elektronisches Geld beinhalten, wobei das Verfahren von einem Computerprogramm ausgeführt wird, das als Client-Gerät eines Nutzers fungiert, und das Verfahren dadurch gekennzeichnet ist, dass es die folgenden Schritte umfasst:
- - Installieren eines Computerprogramms eines Client-Geräts, um als Client-Wallet (301) in mindestens einem Computer oder Computerserver (302) zu fungieren;
- - Arbeiten als einer der Relaisknoten (205) zum Weiterleiten von Informationen aller CBEM-Einheiten, die in dem Transaktionsnetzwerk (202) erzeugt werden (303);
- - Arbeiten als einer der Relaisknoten (205) zum Weiterleiten aller Transaktionsinformationen in dem Transaktionsnetzwerk (202) (304);
- - Arbeiten als einer der Relaisknoten zum Verifizieren und Bestätigen aller Transaktionen, die an das Transaktionsnetzwerk rundgesendet werden (202) (305);
- - Erzeugen neuer Münzen durch Beitragen zur Aufzeichnung neuer Transaktionsinformationen in den Public Ledger aller Transaktionen (209) (306);
- - Erzeugen eines oder mehrerer Paare eines kryptographischen öffentlichen Client-Schlüssels (307) und privaten Client-Schlüssels (308) zum Empfangen und Senden von Münzen (309);
- - Speichern der öffentlich-privaten Client-Schlüsselpaare (Elemente 307, 308) einer oder mehrerer von den Währungsnutzern erzeugten Währungsadressen (310);
- - Arbeiten als Client-Wallet für die Währungsnutzer zum Empfangen und Senden von Münzen (311);
- - Arbeiten als Client-Wallet zum Kommunizieren zwischen einem der zentralen Genehmigungsserver (401) und registrierten Währungsnutzern (109) (312);
- - Erzeugen (314) nur von Währungsadressen, die Multisignaturadressen sind (313);
- - Erzeugen einer oder mehrerer Multisignaturadressen (313) aus dem öffentlichen Client-Schlüssel (307) und dem öffentlichen Genehmigungsschlüssel (405) (315);
- - Speichern einer oder mehrerer nur Multisignaturadressen (313) in dem Client-Wallet (301) zum Senden und Empfangen von Münzen (316);
- - Senden einer oder mehrerer Multisignaturadressen (313) an die Client-Informationsdatenbank (401) zum Speichern und Zuordnen zu einer persönlichen Identität des Besitzers der einen oder mehreren Adressen (317);
- - Senden der erzeugten gültigen Multisignaturadressen (313) an die zentralen Genehmigungsserver (401) zum Speichern (318);
- - Übermitteln von Anmeldeinformationen (111) eines gültig registrierten Nutzers (109) an einen der zentralen Genehmigungsserver zum Erhalten einer Genehmigung zum Erzeugen einer oder mehrerer gültiger Multisignatur-Währungsadressen (313) (319);
- - Übermitteln von Anmeldeinformationen (111) eines gültig registrierten Nutzers (109) an einen der zentralen Genehmigungsserver zum Erhalten einer Genehmigung zum Erstellen einer oder mehrerer gültiger Transaktionen (Elemente 218, 219, 220, 221, 223), um Münzen an eine oder mehrere Währungsadressen (320) zu senden;
- - Gestatten der Erzeugung nur von Transaktionen, die Multisignaturadressen (313) sowohl zum Senden als auch zum Empfangen der Münzen verwenden (321); und
- - Verzeichnen unverbrauchter Münzen (falls vorhanden) in der Blockchain an der Währungsadresse, von der die Münzen gerade gesendet wurden (322).
Beispiel 15: Verfahren zur persönlichen Identifizierung und Verifizierung für Transaktionen, die Kryptographie-basiertes elektronisches Geld beinhalten, wobei das Verfahren von einem Computerprogramm in einem als zentralem Genehmigungsserver (401) fungierenden Rechenserver ausgeführt wird und das Verfahren dadurch gekennzeichnet ist, dass es die nachfolgenden Schritte umfasst:
- - Kommunizieren (407) mit einem Client-Wallet (301), um eine oder mehrere gültige Multisignatur-Währungsadressen (313) bei Vorliegen von gültigen Anmeldeinformationen zu erzeugen;
- - Bereitstellen (408) eines öffentlichen Genehmigungsschlüssels (405) an das Währungs-Wallet zum Erstellen einer oder mehrerer Multisignaturadressen (313);
- - Kommunizieren (409) mit der Client-Wallet (301), um bei Vorliegen von gültigen Anmeldeinformationen eine oder mehrere gültige Transaktionen zu erzeugen (218, 219, 220, 221, 223), um Münzen an eine oder mehrere Währungsadressen zu senden;
- - Bereitstellen (410) eines privaten Genehmigungsschlüssels (406), der zu dem öffentlichen Genehmigungsschlüssel (405) gehört, der bei der Erzeugung der Multisignaturadresse (313) verwendet wurde, um eine Transaktionseingabe für eine oder mehrere gültige Transaktionen (218, 219, 220 221, 223) zu signieren;
- - Bereitstellen des letzten privaten Schlüssels (411) zum Signieren der gesamten Transaktion für eine oder mehrere gültige Transaktionen (412); und
- - Speichern (414) von Transaktionsinformationen in einer Transaktionsdatenbank (413).
Beispiel 16: Das Verfahren von Beispiel 15, wobei das Paar aus öffentlichem Genehmigungsschlüssel (405) und privatem Genehmigungsschlüssel (406) in einem regelmäßigen Zeitraum manuell oder automatisch geändert werden kann, um ein Lecken des öffentlichen Genehmigungsschlüssels und des privaten Genehmigungsschlüssels an die Öffentlichkeit zu vermeiden. Nach dem Wechsel zu einem neuen Paar von Genehmigungsschlüsseln wird der alte private Genehmigungsschlüssel zum Signieren der Transaktionseingabe (410) verwendet und der neue private Genehmigungsschlüssel wird zum Signieren der gesamten Transaktion (d. h. aller Transaktionsdaten) (412) verwendet.
Beispiel 17: Das Verfahren von Beispiel 15, dadurch gekennzeichnet, dass der jüngste private Genehmigungsschlüssel (411) derjenige private Genehmigungsschlüssel, der zu dem öffentlichen Genehmigungsschlüssel (405) gehört, der bei der Erzeugung der Multisignaturadresse (313) verwendet wurde, oder ein anderer privater Genehmigungsschlüssels ist.
Beispiel 18: Das Verfahren von Beispiel 15, dadurch gekennzeichnet, dass der Schritt des Speicherns (414) von Transaktionsinformationen in einer Transaktionsdatenbank (413) das Speichern einer Transaktions-ID, einer Sender-Währungsadresse, einer Empfänger-Währungsadresse, einer Menge der übertragenen Münzen, einer Transaktionszeit und IP-Adressen der Client-Wallets des Senders und des Empfängers umfasst.
Beispiel 19: Das Verfahren von Beispiel 15, dadurch gekennzeichnet, dass das Verfahren ferner einen Schritt des Verifizierens der Transaktion gegen ein oder mehrere Transaktionskriterien (501, 502) auf dem zentralen Genehmigungsserver (401) umfasst.
Beispiel 20: Das Verfahren von Beispiel 19, wobei das Transaktionsnetzwerk (202) modifiziert werden kann, um jegliche Transaktionen abzulehnen, die nicht die zentralen Transaktionskriterien (501) erfüllen, die in einem der zentralen Genehmigungsserver (401) gespeichert sind.
Beispiel 21: Das Verfahren von Beispiel 20, wobei die Client-Transaktionskriterien (502) durch einen gültig registrierten Nutzer definiert werden können, um seine/ihre eigenen Transaktionen zu begrenzen.
Beispiel 22: Das Verfahren von Beispiel 21, das eine praktische Lösung für die Probleme im Zusammenhang mit Kryptowährungsdiebstahl, KYC und AML bietet, während die Privatsphäre des Nutzers erhalten wird.
Beispiel 23: Das Verfahren von Beispiel 21, das von den Zentralbanken oder anderen Finanzinstitutionen übernommen oder geändert werden kann, um ihre eigenen digitalen Währungen auszugeben, die von einem Distributed Ledger-Zahlungssystem unterstützt, aber auch von einem zentralen Verwaltungsorgan reguliert werden.
Beispiel 24: Das Verfahren von Beispiel 20, wobei die Transaktionskriterien (501) durch ein zentrales Verwaltungsorgan (601) definiert werden können, um verdächtige Transaktionen zu stoppen, die wahrscheinlich in illegale Aktivitäten wie Geldwäsche involviert sind.
Beispiel 25: Das Verfahren von Beispiel 15, dadurch gekennzeichnet, dass das eine oder die mehreren Transaktionskriterien (501, 502) Kriterien enthalten, die von einem zentralen Verwaltungsorgan (601) und/oder dem Registranten vorgegeben sind.
Beispiel 26: Das Verfahren von Beispiel 15, dadurch gekennzeichnet, dass das Verfahren ferner einen Schritt des Ermittelns von persönlichen Identitäten des Senders und des Empfängers bei Bedarf durch Zuordnen ihrer Währungsadressen in der Transaktionsdatenbank und der Client-Informationsdatenbank umfasst.
Beispiel 27: Verfahren zur persönlichen Identifizierung und Verifizierung für Transaktionen, die Kryptographie-basiertes elektronisches Geld beinhalten, wobei das Verfahren durch eine Gruppe von Computerprogrammen, die als Geräte eines zentralen Verwaltungsorgans fungieren, und ein Client-Gerät eines Nutzers ausgeführt wird, wobei das Verfahren dadurch gekennzeichnet ist, dass es die nachfolgenden Schritte umfasst:
- - Erhalten von Anmeldeinformationen eines Registranten, umfassend mindestens Anmeldeinformationen zur Zwei-Faktor-Authentifizierung, die eine Multisignatur definieren;
- - Verifizieren der tatsächlichen persönlichen Identität des Registranten;
- - Einrichten eines persönlichen Kontos (108) für einen einzelnen erfolgreichen Registranten (109) mit erfolgreicher Verifizierung der tatsächlichen persönlichen Identität (110), wobei das persönliche Konto die Zuordnung und Speicherung der Multisignatur einer Währungsadresse und der persönlichen Identität einzelner Registranten erleichtert (118);
- - Bereitstellen eines Wallets eines Registranten, das mindestens eine Einheit von elektronischem Geld enthält;
- - Verzeichnen des Besitzes der mindestens einen Einheit von elektronischem Geld in einer Transaktionsdatenbank (413) unter Verwendung der Währungsadresse des Registranten (313);
- - Erzeugen einer Multisignaturtransaktion in einem Pay-to-Script-Hash-Format (218), die jeweils mindestens zwei private Schlüssel als Genehmigungssignaturen benötigt (219);
- - Beschränken eines dieser privaten Schlüssel (219) auf den privaten Genehmigungsschlüssel (406) von einem der zentralen Genehmigungsserver (221);
- - Beschränken des Rests der privaten Schlüssel (219) auf die privaten Schlüssel (222) des Registranten, die in dem Client-Wallet (301, 223) gespeichert sind;
- - Senden der Transaktionsanfrage von dem Client-Wallet (301) an mindestens einen der zentralen Genehmigungsserver (401), um den privaten Genehmigungsschlüssel zum Signieren der Transaktion zu erhalten (224); und
- - Senden der genehmigten Transaktionsnachrichten an alle Relaisknoten in einem Transaktionsnetzwerk (214).
Beispiel 28: System zur persönlichen Identifizierung und Verifizierung von Transaktionen, die Kryptographie-basiertes elektronisches Geld beinhalten, wobei das System umfasst:
- - einen zentralen Genehmigungsserver (401), der so eingerichtet ist, dass er das Verfahren gemäß Beispiel 15 ausführt, um Client-Registrierungsanfragen, Client-Kryptowährungsadressen und Kryptowährungstransaktionen zu verarbeiten;
- - eine Client-Informationsdatenbank (404), die kommunikativ mit dem zentralen Genehmigungsserver (401) verbunden ist;
- - eine Transaktionsdatenbank (413), die kommunikativ mit dem zentralen Genehmigungsserver (401) verbunden ist;
- - mindestens ein Client-Gerät (414, 415), das mit einem Registranten-Wallet (416, 417) versehen ist, das mindestens eine Einheit von elektronischem Geld enthält;
- - wobei das mindestens eine Client-Gerät (414, 415) konfiguriert ist, um das Verfahren gemäß Beispiel 27 auszuführen.
Beispiel 29: Computerprogramm mit Programmcodemitteln zum Ausführen aller Schritte des computerimplementierten Verfahrens gemäß Beispiel 1, Beispiel 9, Beispiel 14, Beispiel 15 oder Beispiel 27, wenn das Programm auf einem Computer oder einem Rechenserver ausgeführt wird.
Beispiel 30: Computerlesbares Medium, das computerausführbare Befehle speichert, die alle Schritte des computerimplementierten Verfahrens gemäß Beispiel 1, Beispiel 9, Beispiel 14, Beispiel 15 oder Beispiel 27 ausführen, wenn sie auf einem Computer oder einem Rechenserver ausgeführt werden.

Dementsprechend ist der Umfang nicht auf die in der Beschreibung beschriebenen bevorzugten Ausführungsformen beschränkt, sondern ist nur durch die folgenden Ansprüche begrenzt.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

CN 103927656 A [0015]

Zitierte Nicht-Patentliteratur

Meiklejohn S et al. University of California, San Diego, 2013 [0008]
Koshy P et al. Pennsylvania State University, 2014 [0009]
Bryans D, Indiana Law Journal, 89 (1): 441, 2014 [0009]

Claims

System zur persönlichen Identifizierung und Verifizierung zum Überwachen und Beschränken von Transaktionen mit Kryptographie-basiertem elektronischem Geld (CBEM) (201), wobei das System umfasst: einen zentralen Genehmigungsserver (401), der dazu eingerichtet ist, Client-Identitätsregistierungen, Client-Währungsadressen und CBEM-Transaktionen zu verarbeiten, umfassend: - Kommunizieren (407) mit einem Client-Wallet (301), um eine oder mehrere vom Nutzer genehmigte Währungsadressen (313) bei Vorliegen von gültigen Anmeldeinformationen zur Verifizierung der persönlichen Identität (319) zu erzeugen; - Genehmigen einer Anfrage zum Erzeugen einer oder mehrerer vom Nutzer genehmigter Währungsadressen (313) bei Vorliegen von gültigen Anmeldeinformationen zur Verifizierung der Identität (212, 319); - Kommunizieren (409) mit dem Client-Wallet (301), um eine oder mehrere genehmigte Transaktionen zu erzeugen (311), um eine Einheit des CBEM an eine Währungsadresse bei Vorliegen von gültigen Anmeldeinformationen zur Verifizierung der Identität zu senden (220); - Genehmigen einer oder mehrerer Transaktionen (311) zum Senden einer Einheit des CBEM an eine Währungsadresse bei Vorliegen von gültigen Anmeldeinformationen zur Verifizierung der Identität (220); - Untersuchen einer Transaktion unter Verwendung von Transaktionskriterien, die durch eine zentrale Verwaltungsbehörde (501) oder einen Nutzer (502) definiert sind; - Ablehnen einer Transaktion, die die Transaktionskriterien verletzt (501, 502); und - Speichern von Transaktionsinformation (414) in einer Transaktionsdatenbank (413); wobei das System ferner umfasst: eine oder mehrere genehmigte Währungsadressen; ein genehmigtes Transaktionsnetzwerk; eine Client-Informationsdatenbank (115, 404), die kommunikativ mit dem zentralen Genehmigungsserver (401) verbunden ist; eine Transaktionsdatenbank (413), die kommunikativ mit dem zentralen Genehmigungsserver (401) verbunden ist; und mindestens ein Client-Gerät (414, 415), das mit einem Client-Wallet (301) versehen ist; wobei das mindestens eine Client-Gerät (414, 415) eingerichtet ist zum: - Erlangen einer Genehmigung von dem zentralen Genehmigungsserver zum Erzeugen einer oder mehrerer genehmigter Währungsadressen (313) durch Übermitteln von gültigen Anmeldeinformationen zur Verifizierung der Identität (212, 319); und - Erlangen einer Genehmigung von dem zentralen Genehmigungsserver zum Erzeugen einer oder mehrerer genehmigter Transaktionen (311), um eine Einheit des CBEM an die Währungsadresse eines Empfängers zu senden, indem gültige Anmeldeinformationen zur Verifizierung der Identität übermittelt werden (220); - Erstellen einer oder mehrerer genehmigter Transaktionen (311) zum Senden einer Einheit des CBEM an die Währungsadresse eines Empfängers durch Signieren der Transaktion mit einem privaten Client-Schlüssel, der der Währungsadresse des Senders zugeordnet ist (308).
System nach Anspruch 1, wobei der zentrale Genehmigungsserver (401) und/oder das Client-Gerät (414, 415) dazu eingerichtet sind, die genehmigten Transaktionsnachrichten an alle Relaisknoten in einem genehmigten Transaktionsnetzwerk (214) rundzusenden (202).
System nach Anspruch 1 oder 2, wobei der zentrale Genehmigungsserver (401) eingerichtet ist zum: - Erstellen eines persönlichen Kontos (108) für einen Nutzer; - Verifizieren (106) und Aufzeichnen (116) von Informationen zu tatsächlichen persönlichen Identitätsinformationen (105), die von einem Nutzer übermittelt wurden; - Aufzeichnen von Anmeldeinformationen zur Verifizierung der Identität (111), die von einem Nutzer übermittelt wurden; - Aufzeichnen einer genehmigten Währungsadresse (313), die von einem Nutzer erzeugt wurde; - Zuordnen und Speichern (118) einer genehmigten Währungsadresse, von Informationen zur persönlichen Identität und von Anmeldeinformationen zur Verifizierung der Identität eines Nutzers in einer Client-Informationsdatenbank (115, 404); und - Aufzeichnen des Besitzes der mindestens einen Einheit des CBEM in einer Transaktionsdatenbank (413) unter Verwendung der Währungsadresse eines Nutzers (313).
System nach einem der vorhergehenden Ansprüche, wobei - die Implementierung eines CBEM-Systems unter Verwendung von genehmigten Währungsadressen festlegt, dass alle Währungsadressen eine Reihe vordefinierter Kriterien erfüllen, einschließlich, aber nicht beschränkt auf Know Your Customer- (KYC) -Compliance und Anti-Geldwäschebekämpfung- (AML) - Compliance; - die Erzeugung einer genehmigten Währungsadresse (313) ein Element zum Erhalten einer Genehmigung (319) von dem zentralen Genehmigungsserver (401) erfordert; - die Anmeldeinformationen zur Verifizierung der Identität eines Nutzers (212) als ein Element verwendet werden können, um die Genehmigung (319) von dem zentralen Genehmigungsserver (401) zu erhalten; und - die Anmeldeinformationen zur Verifizierung der Identität (212) eines Nutzers verwendet werden, um eine Verbindung zwischen einer genehmigten Währungsadresse und den Informationen zur persönlichen Identität (105) des Nutzers bereitzustellen.
System nach einem der vorhergehenden Ansprüche, wobei - der zentrale Genehmigungsserver (401) und das Client-Gerät (414, 415) dazu eingerichtet sind, um ein genehmigtes Transaktionsnetzwerk (214) zu erzeugen; - ein genehmigtes Transaktionsnetzwerk (214) geeignet ist, eine oder mehrere genehmigte Transaktionen zu erzeugen; - die Implementierung eines CBEM-Systems unter Verwendung eines genehmigten Transaktionsnetzwerks (214) festlegt, dass alle Währungstransaktionen die Kriterien des zentralen Genehmigungsservers erfüllen, einschließlich, aber nicht beschränkt auf KYC-Compliance und AML-Compliance; - die Erstellung einer genehmigten Transaktion (311) mindestens zwei Arten von Elementen erfordert: ein Element von einem Client-Gerät, um eine Genehmigungsanfrage (220) an den zentralen Genehmigungsserver (401) zum Erzeugen einer Transaktion zu tätigen, und ein Element zum Steuern der Fortsetzung einer Transaktion durch den zentralen Genehmigungsserver (401); - gültige Anmeldeinformationen zur Verifizierung der Identität (212) eines Nutzers als ein Element von dem Client-Gerät verwendet werden, um eine Genehmigungsanfrage an den zentralen Genehmigungsserver (401) zum Erstellen einer Transaktion zu tätigen; - ein Element zum Steuern der Fortführung einer Transaktion durch den zentralen Genehmigungsserver (401) an jedem Verarbeitungspunkt einer Transaktion implementiert werden kann; - ein Element zum Steuern der Fortführung einer Transaktion durch den zentralen Genehmigungsserver (401) als privater Genehmigungsschlüssel von einem zentralen Genehmigungsserver (401) implementiert wird, um es dem Nutzer zu ermöglichen, eine Einheit des CBEM zu verwenden, die an der genehmigten Währungsadresse des Nutzers registriert ist; - ein oder mehrere private Genehmigungsschlüssel auf Währungsadressenebene unter Verwendung einer Mehrfachsignatur-Währungsadresse (313) als das Konstruktionsformat einer genehmigten Währungsadresse implementiert sind; wobei die Mehrfachsignatur-Währungsadresse (313) mindestens ein Paar des öffentlichen Client-Schlüssels (307) und des privaten Client-Schlüssels (308) umfasst und der private Client-Schlüssel als Authentifizierung eines Nutzers verwendet wird, um eine Einheit des CBEM auszugeben, die an der genehmigten Währungsadresse des Nutzers aufgezeichnet ist; - ein oder mehrere private Genehmigungsschlüssel (406) als Genehmigung des zentralen Genehmigungsservers (220) bereitgestellt werden, um eine oder mehrere Einheiten des CBEM auszugeben, die an der genehmigten Währungsadresse des Nutzers aufgezeichnet sind; - eine erfolgreich genehmigte Transaktion eine oder mehrere private Client-Schlüssel (308) und einen oder mehrere private Genehmigungsschlüsseln (406) zum Signieren der Transaktion erfordert; - nachdem der zentrale Genehmigungsserver (401) eine Transaktionsanfrage zusammen mit den gültigen Anmeldeinformationen zur Verifizierung der Identität (212) eines Nutzers empfangen hat, um eine Einheit des CBEM auszugeben, die an der vom Nutzer genehmigten Währungsadresse aufgezeichnet wurde, der zentrale Genehmigungsserver die Gültigkeit der Identitätsinformationen des Nutzers, Transaktionsinformationen und Transaktionshistorie des Nutzers prüft; - nachdem der zentrale Genehmigungsserver (401) die Gültigkeit der Identitätsinformationen des Nutzers, der Transaktionsinformationen und des Transaktionsverlaufs des Nutzers geprüft hat, der zentrale Genehmigungsserver entscheidet, ob eine Genehmigung (220) der Transaktion erteilt werden soll, indem die Transaktion mit einem oder mehreren privaten Genehmigungsschlüsseln signiert wird oder nicht signiert wird; - der letzte private Genehmigungsschlüssel (411) ein privater Genehmigungsschlüssel, der bei der Erstellung einer genehmigten Transaktion (313) verwendet wurde, oder ein anderer privater Genehmigungsschlüssel ist; und - ein privater Genehmigungsschlüssel (406) manuell oder automatisch in einem regelmäßigen Zeitraum geändert werden kann, um ein Lecken des privaten Genehmigungsschlüssels an die Öffentlichkeit zu vermeiden.
System nach einem der vorhergehenden Ansprüche, wobei der zentrale Genehmigungsserver (401) dazu eingerichtet ist, eine Transaktions-ID, die genehmigte Sender-Währungsadresse, die genehmigte Empfänger-Währungsadresse, die übertragenen Einheiten des CBEM, den Zeitstempel der Transaktion und die IP-Adressen des Client-Wallets des Senders und des Empfängers zu speichern.
System nach einem der vorhergehenden Ansprüche, wobei der zentrale Genehmigungsserver (401) dazu eingerichtet ist, die Transaktion gegen ein oder mehrere Transaktionskriterien (501, 502) zu verifizieren.
System nach Anspruch 7, wobei das genehmigte Transaktionsnetzwerk (202) modifiziert werden kann, um jegliche Transaktionen abzulehnen, die nicht die zentralen Transaktionskriterien (501) erfüllen, die in einem der zentralen Genehmigungsserver (401) gespeichert sind.
System nach Anspruch 7 oder 8, wobei die Client-Transaktionskriterien (502) durch einen Nutzer definiert werden können, um seine/ihre eigenen Transaktionen zu begrenzen.
System nach einem der Ansprüche 7 bis 9, wobei die Transaktionskriterien (501) durch ein zentrales Verwaltungsorgan (601) definiert werden können, um verdächtige Transaktionen zu stoppen, die wahrscheinlich an illegalen Aktivitäten wie Geldwäsche beteiligt sind.
System nach einem der Ansprüche 7 bis 10, wobei das eine oder die mehreren Transaktionskriterien (501, 502) Kriterien enthalten, die durch ein zentrales Verwaltungsorgan (601) und/oder einen Nutzer vorgegeben sind.
System nach einem der vorhergehenden Ansprüche, das dazu eingerichtet ist, eine praktische Lösung für die Probleme im Zusammenhang mit Kryptowährungsdiebstahl, KYC und AML zu bieten, während die Privatsphäre des Nutzers erhalten wird.
System nach einem der vorhergehenden Ansprüche, das dazu eingerichtet ist, von den Zentralbanken oder anderen Finanzinstituten übernommen oder modifiziert zu werden, um ihre eigenen digitalen Währungen auszugeben, die durch ein Distributed Ledger-Zahlungssystem unterstützt werden, aber auch von einem zentralen Verwaltungsorgan reguliert werden.
System nach einem der vorhergehenden Ansprüche, wobei der zentrale Genehmigungsserver (401) dazu eingerichtet ist, die persönlichen Identitäten des Senders und des Empfängers zu ermitteln, indem soweit erforderlich ihre Währungsadressen in der Transaktionsdatenbank und der Client-Informationsdatenbank zugeordnet werden.
System nach einem der vorhergehenden Ansprüche, ferner dazu geeignet, verdächtige Aktivitäten zu überwachen, vor ihnen zu warnen, sie zu untersuchen und/oder zu analysieren.
Computerlesbares Medium, das computerausführbare Befehle speichert, die dazu eingerichtet sind, ein Computerprogramm auszuführen, das als eine Registrierungsschnittstelle (102) fungiert, wobei das Computerprogramm Befehle umfasst, die die nachfolgenden Schritte implementieren: - Gewähren des Zugangs für einen oder mehrere potentielle oder bestehende Währungsnutzer (103); - Bereitstellen einer Registrierungsschnittstelle (102) für einen oder mehrere potentielle Währungsnutzer zum Registrieren eines Nutzerkontos, das eine Authentifizierung erfordert (104); - Anfordern der Übermittlung von Dokumenten zum Nachweis der tatsächlichen persönlichen Identität eines Registranten (105); - Verifizieren der tatsächlichen persönlichen Identität des Registranten (106); - Ablehnen einer Kontoerstellung für Registranten, deren Verifizierung der persönlichen Identität gescheitert ist (107); - Erstellen eines persönlichen Kontos (108) für einzelne erfolgreiche Registranten (109) mit erfolgreicher Verifizierung der persönlichen Identität (110); - Gestatten, dass ein erfolgreicher Registrant (109) Anmeldeinformationen zur Verifizierung der Identität (111) erstellt, die eine zugehörige Authentifizierung (112) umfassen; - Speichern (116) aller übermittelten Informationen in einer Client-Informationsdatenbank (115); - Senden (117) der Anmeldeinformationen zur Verifizierung der Identität an zentrale Genehmigungsserver (401); und - Zuordnen und Speichern (118) einer oder mehrerer genehmigter Währungsadressen, der Anmeldeinformationen zur Verifizierung der Identität und der Informationen zur persönlichen Identität einzelner Registranten.
Computerlesbares Medium nach Anspruch 16, wobei tatsächliche persönliche Identitäten von Besitzern für einzelne genehmigte Währungsadressen in der Client-Informationsdatenbank gespeichert sind.
Computerlesbares Medium nach Anspruch 16 oder 17, wobei tatsächliche persönliche Identitäten von Besitzern für einzelne Währungsadressen in der Client-Informationsdatenbank gespeichert sind, wobei solche Informationen für die Öffentlichkeit nicht zugänglich sind, um die pseudonyme Eigenschaft des CBEM (201) und seines Transaktionsnetzwerks (202) zu erhalten.
Computerlesbares Medium nach einem der Ansprüche 16 bis 18, wobei ein Nutzer die Anmeldeinformationen zur Verifizierung der Identität (111) des Nutzers ändern kann, um zu verhindern, dass Einheiten des CBEM aus einer gestohlenen Hauptdatei des Währungs-Wallets (301) des Nutzers heraus übertragen werden.
Computerlesbares Medium nach einem der Ansprüche 16 bis 19, wobei (i) tatsächliche persönliche Identitäten von Besitzern für einzelne genehmigte Währungsadressen in der Client-Informationsdatenbank gespeichert sind, (ii) jegliche Währungsadressen, die nicht durch Übermittlung von gültig erzeugten Anmeldeinformationen an einen der zentralen Genehmigungsserver (401) erzeugt wurden, nicht gültig sind und keine Einheiten des CBEM empfangen können, und (iii) nur gültig registrierte Nutzer gültige Anmeldeinformationen zur Verifizierung der Identität (112) haben.
Computerlesbares Medium nach einem der Ansprüche 16 bis 20, wobei die Authentifizierung mittels eines Passwortschutzes, einer Zwei-Faktor-Authentifizierung oder einer Multi-Faktor-Authentifizierung erfolgt.
Computerlesbares Medium nach einem der Ansprüche 16 bis 21, wobei das Computerprogramm Befehle zum Verschlüsseln der Anmeldeinformationen (114) umfasst.
Computerlesbares Medium nach einem der Ansprüche 16 bis 22, wobei die Anmeldeinformationen ein digitales, elektronisches oder Hardwareobjekt sind, das als Authentifizierungsmechanismus verwendet werden kann, um sich zu identifizieren, und vorzugsweise mindestens eines sind von: einem individuellen Paar digitaler Codes, einem individuellen Produktschlüssel zum Aktivieren einer Client-Wallet-Software, einem sich ständig ändernden Token, das an ein physisches Gerät gebunden ist, das dem Nutzer gehört, wie etwa ein Mobiltelefon oder ein personalisiertes Gerät zum Erzeugen eines sicheren Schlüssels.
Computerlesbares Medium nach einem der Ansprüche 16 bis 23, wobei nur einem erfolgreichen Registranten (109) erlaubt ist, die Anmeldeinformationen zur Verifizierung der Identität (111) zu erzeugen, die die zugehörige Authentifizierung (112) umfasst.
Computerlesbares Medium, das computerausführbare Befehle speichert, die geeignet sind, die nachfolgenden Schritte auszuführen: - Installieren eines Knotens (203), der ein eigenständiges Computerprogramm oder ein Funktionsmodul eines Client-Wallets (301) sein kann, in einem oder mehreren Client-Computern und/oder -Servern (204); - Verbinden aller Knoten, um Relaisknoten (205) eines Peer-to-Peer-Netzwerks zu bilden, durch ein Datenübertragungsnetzwerk (206); - Steuern des Verfahrens zum Erzeugen mindestens einer Einheit des CBEM (207); - Schützen des Besitzes von mindestens einer Einheit des CBEM durch Public/Private-Key-Kryptographie (208); - Aufzeichnen des Besitzes von mindestens einer Einheit des CBEM in einen Public Ledger (209) unter Verwendung der Währungsadressen des Besitzers (313) (210); - Verifizieren des Besitzes von mindestens einer Einheit des CBEM (211); - Beschränken des Erzeugens einer oder mehrerer gültiger genehmigter Währungsadressen (313) zum Empfangen mindestens einer Einheit des CBEM nur auf gültig registrierte Nutzer (109) durch Verifizieren der einen oder mehreren übermittelten Anmeldeinformationen zur Verifizierung der Identität (111) mit einem der zentralen Genehmigungsserver (401) (212); - Aufzeichnen von Transaktionen von mindestens einer Einheit des CBEM in dem Public Ledger (209) (213); - Verifizieren von Transaktionen von mindestens einer Einheit des CBEM (214); - Steuern des Verfahrens zum Übertragen mindestens einer Einheit des CBEM (215); - Integrieren der Transaktionsregeln in den Programmcode von mindestens einem Knoten (216); - Beschränken mindestens einer Transaktionsgenehmigungsregel (217), umfassend mindestens eines von: Fordern von einer oder mehreren gültigen Anmeldeinformationen zur Verifizierung der Identität (111) vom Sender, Fordern eines oder mehrerer privater Genehmigungsschlüssel (406) von einem oder mehreren zentralen Genehmigungsservern (401); - Gestatten der Erstellung nur genehmigter Transaktionen (321); - Gestatten der Erstellung nur genehmigter Transaktionen, die jeweils einen oder mehrere private Client-Schlüssel und einen oder mehrere private Genehmigungsschlüssel als Signaturen aufweisen (219); - Gestatten der Erstellung von genehmigten Transaktionen nur in Anwesenheit von einer oder mehreren gültigen Anmeldeinformationen zur Verifizierung der Identität (111) (220); - Beschränken eines dieser privaten Client-Schlüssel (219) auf einen privaten Genehmigungsschlüssel (406) von einem der zentralen Genehmigungsserver (221); - Beschränken eines dieser privaten Client-Schlüssel (219) auf private Client-Schlüssel (222), die in dem einen oder den mehreren privaten Client-Wallets verschlüsselt und gespeichert sind (301) (223); - Senden aller Transaktionsanfragen von den Client-Wallets (301) an einen der zentralen Genehmigungsserver (401), um den privaten Genehmigungsschlüssel zum Signieren der Transaktionen zu erhalten (224); und - Ablehnen aller Transaktionen, denen einer der erforderlichen privaten Schlüssel fehlt (219); (225).
Computerlesbares Medium nach Anspruch 25, wobei jegliche Währungsadressen, die nicht durch die Übermittlung von gültigen Anmeldeinformationen zur Verifizierung der Identität an einen der zentralen Genehmigungsserver (401) erzeugt wurden, nicht gültig sind und keine Einheiten des CBEM empfangen können.
Computerlesbares Medium nach Anspruch 25 oder 26, wobei einzelne Transaktionen mit einer definierten Regel überwacht werden können, um verdächtige Transaktionen zu identifizieren, aufzuzeichnen und zu melden, die wahrscheinlich an illegalen Aktivitäten wie Geldwäsche beteiligt sind.
Computerlesbares Medium nach einem der Ansprüche 25 bis 27, wobei tatsächliche persönliche Identitäten von Besitzern einzelner genehmigter Währungsadressen in der Client-Informationsdatenbank gespeichert sind.
Computerlesbares Medium nach einem der Ansprüche 25 bis 28, wobei die Menge an Einheiten des CBEM, die einem gültig registrierten Nutzer gehören, durch das zentrale Verwaltungsorgan (601) durch Analysieren der Transaktionsdatensätze in der Transaktionsdatenbank (413) vollständig und leicht ermittel- und verfolgbar ist.
Computerlesbares Medium nach einem der Ansprüche 25 bis 29, wobei die computerlesbaren Befehle ferner dazu ausgelegt sind, verdächtige Aktivitäten zu überwachen, vor ihnen zu warnen, sie zu untersuchen und/oder zu analysieren.
Computerlesbares Medium, das computerausführbare Befehle speichert, die geeignet sind zum Implementieren der nachfolgenden Schritte: - Installieren eines Computerprogramms eines Client-Geräts, um als Client-Wallet (301) in mindestens einem Computer oder Computer-Server (302) zu dienen; - Arbeiten als einer der Relaisknoten (205) zum Weiterleiten von Informationen aller Einheiten des CBEM, die in dem genehmigten Transaktionsnetzwerk (202) erzeugt werden (303); - Arbeiten als einer der Relaisknoten (205) zum Weiterleiten aller Transaktionsinformationen in dem genehmigten Transaktionsnetzwerk (202) (304); - Arbeiten als einer der Relaisknoten zum Verifizieren und Bestätigen aller Transaktionen, die an das genehmigte Transaktionsnetzwerk (202) gesendet werden (305); - Erzeugen neuer Einheiten des CBEM durch Beitragen zum Aufzeichnen neuer Transaktionsinformationen im Public Ledger aller Transaktionen (209) (306); - Erzeugen eines oder mehrerer Paare von kryptografischem öffentlichem Client-Schlüssel (307) und privatem Client-Schlüssel (308) zum Empfangen und Senden einer oder mehrerer Einheiten des CBEM (309); - Speichern der öffentlich/privaten Client-Schlüssel-Paare (307, 308) einer oder mehrerer genehmigter Währungsadressen, die von den Währungsnutzern erzeugt wurden (310); - Arbeiten als Client-Wallet für die Währungsnutzer, um eine oder mehrere Einheiten des CBEM zu empfangen und zu senden; (311); - Arbeiten als Client-Wallet zur Kommunikation zwischen einem der zentralen Genehmigungsserver (401) und registrierten Währungsnutzern (109) (312); - Erzeugen (314) nur genehmigter Währungsadressen, die Multisignaturadressen sein können (313); - Erzeugen einer oder mehrerer Multisignaturadressen (313) aus einem öffentlichen Client-Schlüssel (307) und einem öffentlichen Genehmigungsschlüssel (405) (315); - Speichern nur einer oder mehrerer genehmigter Währungsadressen (313) in dem Client-Wallet (301) zum Senden und Empfangen einer oder mehrerer Einheiten des CBEM (316); - Senden einer von mehreren genehmigten Währungsadressen (313) an die Client-Informationsdatenbank (401) zum Speichern und Zuordnen zu der persönlichen Identität des Besitzers der einen oder mehreren Adressen (317); - Senden der erzeugten gültigen genehmigten Währungsadressen (313) an die zentralen Genehmigungsserver (401) zum Speichern (318); - Übermitteln einer oder mehrerer Anmeldeinformationen zur Verifizierung der Identität (111) eines gültig registrierten Nutzers (109) an einen der zentralen Genehmigungsserver zum Erhalten einer Genehmigung zum Erzeugen einer oder mehrerer gültig genehmigter Währungsadressen (313) (319); - Übermitteln von Anmeldeinformationen zur Verifizierung der Identität (111) eines gültig registrierten Nutzers (109) an einen der zentralen Genehmigungsserver zum Erhalten einer Genehmigung zum Erstellen einer oder mehrerer gültig genehmigter Transaktionen (Elemente 218, 219, 220, 221, 223), um eine oder mehrere Einheiten des CBEM zu einer oder mehreren genehmigten Währungsadressen (320) zu senden; - Gestatten nur der Erstellung von Transaktionen, die genehmigte Währungsadressen (313) sowohl zum Senden als auch zum Empfangen einer oder mehrerer Einheiten des CBEM verwenden (321); und - Aufzeichnen von nicht ausgegebenen Einheiten des CBEM, falls vorhanden, in der Blockchain an der genehmigten Währungsadresse, von der eine oder mehrere Einheiten des CBEM gerade gesendet wurden (322), oder einer anderen genehmigten Währungsadresse des Senders.
Computerlesbares Medium nach Anspruch 31, wobei die computerlesbaren Anweisungen ferner dafür ausgelegt sind, verdächtige Aktivitäten zu überwachen, vor ihnen zu warnen, sie zu untersuchen und/oder zu analysieren.
Computerlesbares Medium, das computerausführbare Befehle speichert, die geeignet sind, die nachfolgenden Schritte auszuführen: - Kommunizieren (407) mit einem Client-Wallet (301), um eine oder mehrere gültige genehmigte Währungsadressen (313) in Anwesenheit eines oder mehrerer gültiger Anmeldeinformationen zur Verifizierung der Identität (111) zu erzeugen; - Kommunizieren (409) mit dem Client-Wallet (301), um eine oder mehrere gültige genehmigte Transaktionen (218, 219, 220, 221, 223) zu erzeugen, um eine oder mehrere Einheiten des CBEM an eine oder mehrere genehmigte Währungsadressen in Anwesenheit von gültigen Anmeldeinformationen zur Verifizierung der Identität zu senden (111); - Bereitstellen (410) eines oder mehrerer privater Genehmigungsschlüssel (406) beim Erzeugen des genehmigten Transaktionsnetzwerks, um eine Transaktionseingabe für eine oder mehrere gültige genehmigte Transaktionen zu signieren (218, 219, 220, 221, 223); - Bereitstellen des letzten privaten Schlüssels (411) zum Signieren der gesamten Transaktion für eine oder mehrere gültige genehmigte Transaktionen (412); und - Speichern (414) der Transaktionsinformationen in einer Transaktionsdatenbank (413).
Computerlesbares Medium nach Anspruch 33, wobei der private Genehmigungsschlüssel (406) in einem regelmäßigen Zeitraum manuell oder automatisch geändert werden kann, um ein Lecken des privaten Genehmigungsschlüssels an die Öffentlichkeit zu vermeiden; nach dem Wechsel zu einem neuen Paar von Genehmigungsschlüsseln wird der alte private Genehmigungsschlüssel zum Signieren der Transaktionseingabe verwendet (410) und der neue private Genehmigungsschlüssel wird zum Signieren der gesamten Transaktion (d. h. aller Transaktionsdaten) verwendet (412).
Computerlesbares Medium nach Anspruch 33 oder 34, wobei der letzte private Genehmigungsschlüssel (411) der private Genehmigungsschlüssel ist, der bei der Erstellung einer oder mehrerer genehmigter Transaktionen (313) verwendet wurde, oder ein anderer privater Genehmigungsschlüssel.
Computerlesbares Medium nach einem der Ansprüche 33 bis 35, wobei der Schritt des Speicherns (414) von Transaktionsinformationen in einer Transaktionsdatenbank (413) das Speichern einer Transaktions-ID, der genehmigten Sender-Währungsadresse, der genehmigten Empfänger-Währungsadresse, der übertragenen Einheiten des CBEM, des Transaktionszeitstempels und der IP-Adresse der Client-Wallets des Senders und des Empfängers umfasst.
Computerlesbares Medium nach einem der Ansprüche 33 bis 36, wobei die computerausführbaren Befehle geeignet sind, den Schritt zu implementieren von: Verifizieren der Transaktion gegen ein oder mehrere Transaktionskriterien (501, 502) auf dem zentralen Genehmigungsserver (401).
Computerlesbares Medium nach Anspruch 33, wobei das Transaktionsnetzwerk (202) modifiziert werden kann, um jegliche Transaktionen abzulehnen, die nicht die zentralen Transaktionskriterien (501) erfüllen, die in einem der zentralen Genehmigungsserver (401) gespeichert sind.
Computerlesbares Medium nach Anspruch 37 oder 38, wobei die Client-Transaktionskriterien (502) durch einen gültig registrierten Nutzer definiert werden können, um seine/ihre eigenen Transaktionen zu begrenzen.
Computerlesbares Medium nach einem der Ansprüche 37 bis 39, wobei die Transaktionskriterien (501) durch ein zentrales Verwaltungsorgan (601) definiert werden können, um verdächtige Transaktionen zu stoppen, die wahrscheinlich an illegalen Aktivitäten wie Geldwäsche beteiligt sind.
Computerlesbares Medium nach einem der Ansprüche 37 bis 40, wobei das eine oder die mehreren Transaktionskriterien (501, 502) Kriterien enthalten, die durch ein zentrales Verwaltungsorgan (601) und/oder den Registranten vorgegeben sind.
Computerlesbares Medium nach einem der Ansprüche 33 bis 41, wobei die computerausführbaren Befehle eingerichtet sind zum Implementieren des Schritts von: Ermitteln von persönlichen Identitäten des Senders und des Empfängers bei Bedarf durch Zuordnen ihrer genehmigten Währungsadressen in der Transaktionsdatenbank und der Client-Informationsdatenbank.
Computerlesbares Medium nach einem der Ansprüche 33 bis 42, wobei die computerlesbaren Befehle ferner dazu ausgelegt sind, verdächtige Aktivitäten zu überwachen, vor ihnen zu warnen, sie zu untersuchen und/oder zu analysieren.
Computerlesbares Medium, das computerausführbare Befehle speichert, die geeignet sind, die nachfolgenden Schritte auszuführen: - Empfangen einer oder mehrerer Anmeldeinformationen zur Verifizierung der Identität (111) von einem Registranten; - Verifizieren von Informationen zur tatsächlichen persönlichen Identität des Registranten; - Erzeugen eines persönlichen Kontos (108) für einen einzelnen erfolgreichen Registranten (109) mit erfolgreicher Verifizierung der Informationen zur tatsächlichen persönlichen Identität (110), während das persönliche Konto die Zuordnung und Speicherung einer genehmigten Währungsadresse und von Informationen zur persönlichen Identität einzelner Registranten erleichtert (118); - Bereitstellen eines Client-Wallets zum Aufzeichnen einer oder mehrerer Einheiten des CBEM; - Aufzeichnen des Besitzes einer oder mehrerer Einheiten des CBEM in einer Transaktionsdatenbank (413) unter Verwendung der genehmigten Währungsadresse des Registranten (313); - Erstellen einer genehmigten Transaktion, die einen oder mehrere private Client-Schlüssel und einen oder mehrere private Genehmigungsschlüssel als Signaturen erfordert (219); - Beschränken eines oder mehrerer dieser privaten Genehmigungsschlüssel auf private Genehmigungsschlüssel (406) von einem der zentralen Genehmigungsserver (221); - Beschränken eines oder mehrerer dieser privaten Client-Schlüssel auf die privaten Schlüsseln des Registranten (222), die in dem Client-Wallet (301, 223) gespeichert sind; - Senden der Transaktionsanfrage von dem Client-Wallet (301) an mindestens einen der zentralen Genehmigungsserver (401), um einen oder mehrere private Genehmigungsschlüssel zum Signieren der Transaktion zu erhalten (224); und - Senden der genehmigten Transaktionsnachrichten an alle Relaisknoten in einem Transaktionsnetzwerk (214).
Computerlesbares Medium nach Anspruch 44, wobei die computerlesbaren Anweisungen ferner dafür ausgelegt sind, verdächtige Aktivitäten zu überwachen, vor ihnen zu warnen, sie zu untersuchen und/oder zu analysieren.
Signalfolge von Datensignalen, die einen Computerprogrammcode darstellen, der eingerichtet ist, die nachfolgenden Schritte zu implementieren: - Gewähren des Zugangs für einen oder mehrere potentielle oder bestehende Währungsnutzer (103); - Bereitstellen einer Registrierungsschnittstelle (102) für einen oder mehrere potentielle Währungsnutzer zum Registrieren eines Nutzerkontos, das eine Authentifizierung erfordert (104); - Anfordern der Übermittlung von Dokumenten zum Nachweis der tatsächlichen persönlichen Identität eines Registranten (105); - Verifizieren der Informationen zur tatsächlichen persönlichen Identität des Registranten (106); - Ablehnen einer Kontoerstellung für Registranten, deren Verifizierung der persönlichen Identität gescheitert ist (107); - Erstellen eines persönlichen Kontos (108) für einzelne erfolgreiche Registranten (109) mit erfolgreicher Verifizierung der persönlichen Identität (110); - Gestatten, dass ein erfolgreicher Registrant (109) eine oder mehrere Anmeldeinformationen zur Verifizierung der Identität (111) erstellt, die eine zugehörige Authentifizierung (112) umfassen; - Speichern (116) aller übermittelten Informationen in einer Client-Informationsdatenbank (115); - Senden (117) der einen oder mehreren Anmeldeinformationen zur Verifizierung der Identität an zentrale Genehmigungsserver (401); und - Zuordnen und Speichern (118) einer oder mehrerer genehmigter Währungsadressen, einer oder mehrerer Anmeldeinformationen zur Verifizierung der Identität und der Informationen zur persönlichen Identität einzelner Registranten.
Signalfolge nach Anspruch 46, wobei tatsächliche persönliche Identitäten von Besitzern für einzelne Währungsadressen in der Client-Informationsdatenbank gespeichert werden.
Signalfolge nach Anspruch 46 oder 47, wobei tatsächliche persönliche Identitäten von Besitzern für einzelne genehmigte Währungsadressen in der Client-Informationsdatenbank gespeichert werden, wobei solche Informationen für die Öffentlichkeit nicht zugänglich sind, um die pseudonyme Eigenschaft des Kryptographie-basierten elektronischen Geldes (201) und seines Transaktionsnetzwerks (202) zu erhalten.
Signalfolge nach einem der Ansprüche 46 bis 48, wobei ein Nutzer die Anmeldeinformationen zur Verifizierung der Identität (111) des Nutzers ändern kann, um zu verhindern, dass eine oder mehrere Einheiten des CBEM aus einer gestohlenen Hauptdatendatei des Währungs-Wallets (301) des Nutzers übertragen werden.
Signalfolge nach einem der Ansprüche 46 bis 49, wobei (i) tatsächliche persönliche Identitäten von Besitzern für einzelne genehmigte Währungsadressen in der Client-Informationsdatenbank gespeichert werden, (ii) jegliche Währungsadressen, die nicht durch die Übermittlung von gültigen Anmeldeinformationen zur Verifizierung der Identität (111) an einen der zentralen Genehmigungsserver (401) erzeugt wurden, nicht gültig sind und keine Einheiten des CBEM empfangen können, und (iii) nur gültig registrierte Nutzer eine oder mehrere gültige Anmeldeinformationen zur Verifizierung der Identität haben (112).
Signalfolge nach einem der Ansprüche 46 bis 50, wobei die Authentifizierung mittels eines Passwortschutzes, Zwei-Faktor-Authentifizierung oder Multi-Faktor-Authentifizierung erfolgt.
Signalfolge nach einem der Ansprüche 46 bis 51, wobei der Computerprogrammcode geeignet ist, einen Schritt zum Verschlüsseln der Anmeldeinformationen zur Verifizierung der Identität zu implementieren (114).
Signalfolge nach einem der Ansprüche 46 bis 52, wobei die Anmeldeinformationen ein digitales, elektronisches oder Hardwareobjekt sind, das als ein Authentifizierungsmechanismus verwendet werden kann, um sich zu identifizieren, und die vorzugsweise mindestens eines sind von: einem eindeutigen Paar digitaler Codes, einem eindeutigen Produktschlüssel zum Aktivieren einer Client-Wallet-Software, einem sich ständig ändernden Token, das an ein physisches Gerät gebunden ist, das dem Nutzer gehört, wie beispielsweise ein Mobiltelefon oder ein personalisiertes Gerät zum Erzeugen eines sicheren Schlüssels.
Signalfolge nach einem der Ansprüche 46 bis 53, wobei nur einem erfolgreichen Registrant (109) erlaubt ist, die Anmeldeinformationen zur Verifizierung der Identität (111) zu erzeugen, die die zugehörige Authentifizierung (112) umfassen.
Signalfolge von Datensignalen, die einen Computerprogrammcode darstellen, der dazu eingerichtet ist, die nachfolgenden Schritte zu implementieren: - Einrichten eines Knotens (203), der ein eigenständiges Computerprogramm oder ein Funktionsmodul eines Client-Wallets (111) sein kann, in einem oder mehreren Client-Computern und/oder -Servern (204); - Verbinden aller Knoten, um Relaisknoten eines Peer-to-Peer-Netzwerks (205) über ein Datenübertragungsnetzwerk (206) zu bilden; - Steuern des Verfahrens zum Erzeugen einer oder mehrerer Einheiten des CBEM (207); - Schützen des Besitzes einer oder mehrerer Einheiten des CBEM durch Public/Private-Key-Kryptographie (208); - Aufzeichnen des Besitzes einer oder mehrerer Einheiten des CBEM in einen Public Ledger (209) unter Verwendung der genehmigten Währungsadressen der Nutzer (313) (210); - Verifizieren des Besitzes einer oder mehrerer Einheiten des CBEM (211); - Beschränken nur auf gültig registrierte Nutzer (109) des Erzeugens einer oder mehrerer gültiger genehmigter Währungsadressen (313) zum Empfangen einer oder mehrerer Einheiten des CBEM durch Verifizieren eines oder mehrerer übermittelter Anmeldeinformationen zur Verifizierung der Identität (111) mit einem der zentralen Genehmigungsserver (401) (212); - Aufzeichnen von Transaktionen einer oder mehrerer Einheiten des CBEM in den Public Ledger (209) (213); - Verifizieren von Transaktionen einer oder mehrerer Einheiten des CBEM (214); - Steuern des Verfahrens zum Übertragen einer oder mehrerer Einheiten des CBEM (215); - Integrieren der Transaktionsregeln in den Programmcode von mindestens einem Knoten (216); - Beschränken von mindestens einer Transaktionsgenehmigungsregel (217), umfassend mindestens eines von: Fordern von gültigen Anmeldeinformationen zur Verifizierung der Identität (111) vom Sender und Fordern eines oder mehrerer privater Genehmigungsschlüssel (406) von einem der zentralen Genehmigungsserver (401); - Gestatten der Erstellung nur von genehmigten Transaktionen; - Gestatten der Erstellung nur von genehmigten Transaktionen, von denen jede einen oder mehrere private Client-Schlüssel und einen oder mehrere private Genehmigungsschlüssel als Signaturen benötigt (219); - Gestatten der Erstellung nur von genehmigten Transaktionen in Anwesenheit von gültigen Anmeldeinformationen zur Verifizierung der Identität (111) (220); - Beschränken eines oder mehrerer dieser privaten Genehmigungsschlüssel (219) als private Genehmigungsschlüssel (406) von einem der zentralen Genehmigungsserver (221); - Beschränken eines oder mehrerer dieser privaten Client-Schlüssel (219) auf private Client-Schlüssel (222), die verschlüsselt sind und in dem einen oder den mehreren Client-Wallets (301) gespeichert sind (223); - Senden aller Transaktionsanfragen von den Client-Wallets (301) an einen der zentralen Genehmigungsserver (401), um den privaten Genehmigungsschlüssel zum Signieren der Transaktionen zu erhalten (224); und - Zurückweisen aller Transaktionen, denen einer der erforderlichen privaten Schlüssel fehlt (219); (225).
Signalfolge nach Anspruch 55, wobei jegliche Währungsadressen, die nicht durch die Übermittlung einer oder mehrerer gültiger Anmeldeinformationen zur Verifizierung der Identität an einen der zentralen Genehmigungsserver (401) erzeugt wurden, nicht gültig sind und keine Einheiten des CBEM empfangen können.
Signalfolge nach Anspruch 55 oder Anspruch 56, wobei einzelne Transaktionen mit definierten Regeln überwacht werden können, um verdächtige Transaktionen zu identifizieren, aufzuzeichnen und zu melden, die wahrscheinlich an illegalen Aktivitäten wie Geldwäsche beteiligt sind.
Signalfolge nach einem der Ansprüche 55 bis 57, wobei tatsächliche persönliche Identitäten von Besitzern einzelner genehmigter Währungsadressen in der Client-Informationsdatenbank gespeichert werden.
Signalfolge nach einem der Ansprüche 54 bis 57, wobei die Menge an Einheiten des CBEM, die einem gültig registrierten Nutzer gehören, durch das zentrale Verwaltungsorgan (601) durch Analysieren der Transaktionsdatensätze in der Transaktionsdatenbank vollständig und leicht ermittel- und verfolgbar ist (413).
Signalfolge nach einem der Ansprüche 55 bis 59, ferner dazu geeignet, verdächtige Aktivitäten zu überwachen, vor ihnen zu warnen, sie zu untersuchen und/oder zu analysieren.
Signalfolge von Datensignalen, die einen Computerprogrammcode darstellen, der dazu eingerichtet ist, die nachfolgenden Schritte zu implementieren: - Installieren eines Computerprogramms eines Client-Geräts, um als ein Client-Wallet (301) in mindestens einem Computer oder Computer-Server (302) zu dienen; - Arbeiten als einer der Relaisknoten (205) zum Weiterleiten von Informationen aller Einheiten des CBEM, die in dem genehmigten Transaktionsnetzwerk erzeugt werden (202) (303); - Arbeiten als einer der Relaisknoten (205) zum Weiterleiten aller Transaktionsinformationen in dem genehmigten Transaktionsnetzwerk (202) (304); - Arbeiten als einer der Relaisknoten, um alle genehmigten Transaktionen zu verifizieren und zu bestätigen, die an das genehmigte Transaktionsnetzwerk gesendet werden (202) (305); - Erzeugen neuer Einheiten des CBEM durch Beitragen zum Aufzeichnen aller neuer Transaktionsinformationen in den Public Ledger aller Transaktionen (209) (306); - Erzeugen eines oder mehrerer Paare aus kryptographischem öffentlichem Client-Schlüssel (307) und privatem Client-Schlüssel (308) zum Empfangen und Senden einer oder mehrerer Einheiten des CBEM (309); - Speichern der Paare aus öffentlichem/privatem Client-Schlüssel (Elemente 307, 308) einer oder mehrerer genehmigter Währungsadressen, die von den Währungsnutzern (310) erzeugt wurden; - Arbeiten als Client-Wallet für die Währungsnutzer, um eine oder mehrere Einheiten des CBEM zu empfangen und zu senden (311); - Arbeiten als Client-Wallet zur Kommunikation zwischen einem der zentralen Genehmigungsserver (401) und registrierten Währungsnutzern (109) (312); - Erzeugen (314) nur von Währungsadressen, die genehmigte Währungsadressen sind (313) ; - Erzeugen einer von mehreren genehmigten Währungsadressen (313) aus dem öffentlichen Client-Schlüssel (307) und dem öffentlichen Genehmigungsschlüssel (405) (315); - Speichern nur von einer oder mehreren genehmigten Währungsadressen (313) in dem Client-Wallet (301) zum Senden und Empfangen einer oder mehrerer Einheiten des CBEM (316); - Senden einer von mehreren genehmigten Währungsadressen (313) an die Client-Informationsdatenbank (401) zum Speichern und Zuordnen zu Informationen zur persönlichen Identität des Besitzers der einen oder mehreren Adressen (317); - Senden der erzeugten gültigen genehmigten Währungsadressen (313) an die zentralen Genehmigungsserver (401) zum Speichern (318); - Übermitteln eines oder mehrerer Anmeldeinformationen zur Verifizierung der Identität (111) eines gültig registrierten Nutzers (109) an einen der zentralen Genehmigungsserver zum Erhalten einer Genehmigung zum Erzeugen einer oder mehrerer gültiger genehmigter Währungsadressen (313) (319); - Übermitteln einer oder mehrerer Anmeldeinformationen zur Verifizierung der Identität (111) eines gültig registrierten Nutzers (109) an einen der zentralen Genehmigungsserver zum Erhalten einer Genehmigung zum Erstellen einer oder mehrerer gültiger genehmigter Transaktionen (Elemente 218, 219, 220, 221, 223), um eine oder mehrere Einheiten des CBEM an eine oder mehrere genehmigte Währungsadressen (320) zu senden; - Gestatten der Erstellung nur von Transaktionen, die genehmigte Währungsadressen (313) sowohl zum Senden als auch zum Empfangen der einen oder mehreren Einheiten des CBEM (321) verwenden; und - Aufzeichnen unverbrauchter Einheiten des CBEM (falls vorhanden) in die Blockchain an der genehmigten Währungsadresse, von der eine oder mehrere Einheiten des CBEM gerade gesendet wurden (322), oder einer anderen genehmigten Währungsadresse des Senders.
Signalfolge nach Anspruch 61, ferner geeignet, verdächtige Aktivitäten zu überwachen, vor ihnen zu warnen, sie zu untersuchen und/oder zu analysieren.
Signalfolge von Datensignalen, die einen Computerprogrammcode darstellen, der dazu eingerichtet ist, die Schritte zu implementieren von: - Kommunizieren (407) mit einem Client-Wallet (301), um eine oder mehrere gültige genehmigte Währungsadressen (313) in Anwesenheit einer oder mehrerer gültiger Anmeldeinformationen zur Verifizierung der Identität (111) zu erzeugen; - Kommunizieren (409) mit dem Client-Wallet (301), um eine oder mehrere gültige genehmigte Transaktionen (218, 219, 220, 221, 223) zu erzeugen, um eine oder mehrere Einheiten des CBEM an eine oder mehrere genehmigte Währungsadressen in Anwesenheit von gültigen Anmeldeinformationen zur Verifizierung der Identität zu senden; - Bereitstellen (410) eines oder mehrerer privater Genehmigungsschlüssel (406) zum Signieren der Transaktionseingabe für eine oder mehrere gültige genehmigte Transaktionen (218, 219, 220, 221, 223); - Bereitstellen des letzten privaten Genehmigungsschlüssels (411) zum Signieren der gesamten Transaktion für eine oder mehrere gültige genehmigte Transaktionen (412); und - Speichern (414) von Transaktionsinformationen in einer Transaktionsdatenbank (413).
Signalfolge nach Anspruch 63, wobei ein privater Genehmigungsschlüssel (406) in einem regelmäßigen Zeitraum manuell oder automatisch geändert werden kann, um ein Lecken des privaten Genehmigungsschlüssels an die Öffentlichkeit zu vermeiden, nach dem Wechsel zu einem neuen privaten Genehmigungsschlüssel wird der alte private Schlüssel zum Signieren der Transaktionseingabe (410) verwendet, und der neue private Genehmigungsschlüssel wird zum Signieren der gesamten Transaktion (d. h. aller Transaktionsdaten) (412) verwendet.
Signalfolge nach Anspruch 63 oder 64, wobei der letzte private Genehmigungsschlüssel (411) der private Genehmigungsschlüssel, der bei der Erstellung der genehmigten Transaktion (313) verwendet wurde, oder ein anderer privater Genehmigungsschlüssel ist.
Signalfolge nach einem der Ansprüche 63 bis 65, wobei der Schritt des Speicherns (414) von Transaktionsinformationen in einer Transaktionsdatenbank (413) das Speichern einer Transaktions-ID, der genehmigten Sender-Währungsadresse, der genehmigten Empfänger-Währungsadresse, von übertragenen Einheiten des CBEM, eines Transaktionszeitstempels und einer IP-Adresse der Client-Wallets des Senders und des Empfängers umfasst.
Signalfolge nach einem der Ansprüche 63 bis 66, wobei der Computerprogrammcode eingerichtet ist, den Schritt zu implementieren von: Verifizieren der Transaktion gegen ein oder mehrere Transaktionskriterien (501, 502) auf dem zentralen Genehmigungsserver (401).
Signalfolge nach Anspruch 67, wobei das Transaktionsnetzwerk (202) modifiziert werden kann, um jegliche Transaktionen abzulehnen, die nicht die zentralen Transaktionskriterien (501) erfüllen, die in einem der zentralen Genehmigungsserver (401) gespeichert sind.
Signalfolge nach Anspruch 67 oder 68, wobei die Client-Transaktionskriterien (502) durch einen gültig registrierten Nutzer definiert werden können, um seine/ihre eigenen Transaktionen zu begrenzen.
Signalfolge nach einem der Ansprüche 67 bis 69, wobei die Transaktionskriterien (501) durch ein zentrales Verwaltungsorgan (601) definiert werden können, um verdächtige Transaktionen zu stoppen, die wahrscheinlich an illegalen Aktivitäten wie Geldwäsche beteiligt sind.
Signalfolge nach einem der Ansprüche 67 bis 70, wobei das eine oder die mehreren Transaktionskriterien (501, 502) Kriterien enthalten, die durch ein zentrales Verwaltungsorgan (601) und/oder den Registranten vorgegeben sind.
Signalfolge nach einem der Ansprüche 63 bis 71, wobei der Computerprogrammcode eingerichtet ist zum Implementieren des Schritts von: bei Bedarf, Ermitteln der persönlichen Identität des Senders und des Empfängers durch Zuordnen ihrer genehmigten Währungsadressen in der Transaktionsdatenbank und der Client-Informationsdatenbank.
Signalfolge nach einem der Ansprüche 63 bis 72, die ferner dazu geeignet ist, verdächtige Aktivitäten zu überwachen, vor ihnen zu warnen, sie zu untersuchen und/oder zu analysieren.
Signalfolge von Datensignalen, die einen Computerprogrammcode darstellen, der dazu eingerichtet, die nachfolgenden Schritte zu implementieren: - Empfangen einer oder mehrerer Anmeldeinformationen zur Verifizierung der Identität eines Registranten; - Verifizieren der Informationen zur tatsächlichen persönlichen Identität des Registranten; - Erzeugen eines persönlichen Kontos (108) für einen einzelnen erfolgreichen Registranten (109) mit erfolgreicher Verifizierung der Informationen zur tatsächlichen persönlichen Identität (110), wobei das persönliche Konto die Zuordnung und Speicherung der genehmigten Währungsadresse und persönlichen Identität einzelner Registranten erleichtert (118); - Bereitstellen eines Client-Wallets zum Aufzeichnen einer oder mehrerer Einheiten des CBEM; - Aufzeichnen des Besitzes einer oder mehrerer Einheiten des CBEM in einer Transaktionsdatenbank (413) unter Verwendung der genehmigten Währungsadresse der Registranten (313); - Erstellen einer genehmigten Transaktion, die einen oder mehrere private Client-Schlüssel und einen oder mehrere private Genehmigungsschlüssel als Signaturen erfordert (219); - Beschränken eines dieser privaten Genehmigungsschlüssel auf private Genehmigungsschlüssel (406) von einem der zentralen Genehmigungsserver (221); - Beschränken eines dieser privaten Client-Schlüssel auf die privaten Schlüssel des Registranten (222), die in dem Client-Wallet (301, 223) gespeichert sind; - Senden der Transaktionsanfrage von dem Client-Wallet (301) an mindestens einen der zentralen Genehmigungsserver (401), um den privaten Genehmigungsschlüssel zum Signieren der Transaktion zu erhalten (224); und - Senden der genehmigten Transaktionsnachrichten an alle Relaisknoten in einem Transaktionsnetzwerk (214).
Signalfolge nach Anspruch 74, ferner dazu eingerichtet, verdächtige Aktivitäten zu überwachen, vor ihnen zu warnen, sie zu untersuchen und/oder zu analysieren.