JP3228339U - 個人認証及び確認システム及び方法 - Google Patents
個人認証及び確認システム及び方法 Download PDFInfo
- Publication number
- JP3228339U JP3228339U JP2018600051U JP2018600051U JP3228339U JP 3228339 U JP3228339 U JP 3228339U JP 2018600051 U JP2018600051 U JP 2018600051U JP 2018600051 U JP2018600051 U JP 2018600051U JP 3228339 U JP3228339 U JP 3228339U
- Authority
- JP
- Japan
- Prior art keywords
- client
- transaction
- approved
- system processor
- transactions
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
- 238000000034 method Methods 0.000 title claims abstract description 96
- 238000012795 verification Methods 0.000 title claims abstract description 26
- 230000008569 process Effects 0.000 claims abstract description 32
- 230000001105 regulatory effect Effects 0.000 claims abstract description 17
- 230000000694 effects Effects 0.000 claims description 45
- 238000012546 transfer Methods 0.000 claims description 34
- 238000004900 laundering Methods 0.000 claims description 29
- 238000012545 processing Methods 0.000 claims description 19
- 230000004044 response Effects 0.000 claims description 13
- 238000004458 analytical method Methods 0.000 claims description 7
- 230000005540 biological transmission Effects 0.000 claims description 7
- 239000000725 suspension Substances 0.000 claims 2
- 238000012544 monitoring process Methods 0.000 abstract description 18
- 238000010586 diagram Methods 0.000 abstract description 4
- 230000001934 delay Effects 0.000 abstract description 2
- 230000006870 function Effects 0.000 description 31
- 238000013515 script Methods 0.000 description 19
- 238000012790 confirmation Methods 0.000 description 13
- 238000004590 computer program Methods 0.000 description 12
- 230000002441 reversible effect Effects 0.000 description 10
- 238000004422 calculation algorithm Methods 0.000 description 9
- 230000008859 change Effects 0.000 description 9
- 230000007246 mechanism Effects 0.000 description 9
- 238000001514 detection method Methods 0.000 description 7
- 238000005516 engineering process Methods 0.000 description 7
- 238000013507 mapping Methods 0.000 description 7
- 230000015654 memory Effects 0.000 description 7
- 230000006854 communication Effects 0.000 description 6
- 238000004891 communication Methods 0.000 description 6
- 238000012502 risk assessment Methods 0.000 description 6
- 238000007726 management method Methods 0.000 description 5
- 238000012384 transportation and delivery Methods 0.000 description 4
- 230000009471 action Effects 0.000 description 3
- 238000012550 audit Methods 0.000 description 3
- 230000008901 benefit Effects 0.000 description 3
- 238000012986 modification Methods 0.000 description 3
- 230000004048 modification Effects 0.000 description 3
- 238000011160 research Methods 0.000 description 3
- RTZKZFJDLAIYFH-UHFFFAOYSA-N Diethyl ether Chemical compound CCOCC RTZKZFJDLAIYFH-UHFFFAOYSA-N 0.000 description 2
- 125000002066 L-histidyl group Chemical group [H]N1C([H])=NC(C([H])([H])[C@](C(=O)[*])([H])N([H])[H])=C1[H] 0.000 description 2
- 238000004364 calculation method Methods 0.000 description 2
- 230000003111 delayed effect Effects 0.000 description 2
- 239000003814 drug Substances 0.000 description 2
- 229940079593 drug Drugs 0.000 description 2
- 239000000284 extract Substances 0.000 description 2
- 230000008520 organization Effects 0.000 description 2
- 241000283070 Equus zebra Species 0.000 description 1
- 241000208341 Hedera Species 0.000 description 1
- 238000013475 authorization Methods 0.000 description 1
- 230000007175 bidirectional communication Effects 0.000 description 1
- 230000004397 blinking Effects 0.000 description 1
- 238000006243 chemical reaction Methods 0.000 description 1
- 238000004883 computer application Methods 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 230000005611 electricity Effects 0.000 description 1
- 238000011156 evaluation Methods 0.000 description 1
- ZXQYGBMAQZUVMI-GCMPRSNUSA-N gamma-cyhalothrin Chemical compound CC1(C)[C@@H](\C=C(/Cl)C(F)(F)F)[C@H]1C(=O)O[C@H](C#N)C1=CC=CC(OC=2C=CC=CC=2)=C1 ZXQYGBMAQZUVMI-GCMPRSNUSA-N 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 230000010365 information processing Effects 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 230000010354 integration Effects 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 238000005259 measurement Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000001681 protective effect Effects 0.000 description 1
- 238000012216 screening Methods 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
- 230000002123 temporal effect Effects 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
- 230000009466 transformation Effects 0.000 description 1
- 238000010200 validation analysis Methods 0.000 description 1
- 230000000007 visual effect Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
- G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
- G06Q20/3678—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes e-cash details, e.g. blinded, divisible or detecting double spending
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/401—Transaction verification
- G06Q20/4014—Identity check for transactions
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/405—Establishing or using transaction specific rules
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/088—Usage controlling of secret information, e.g. techniques for restricting cryptographic keys to pre-authorized uses, different access levels, validity of crypto-period, different key- or password length, or different strong and weak cryptographic algorithms
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
- H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/42—Anonymization, e.g. involving pseudonyms
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash
Landscapes
- Engineering & Computer Science (AREA)
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Computer Security & Cryptography (AREA)
- Finance (AREA)
- Computer Networks & Wireless Communication (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Strategic Management (AREA)
- Signal Processing (AREA)
- Development Economics (AREA)
- Economics (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
【課題】暗号型電子マネー(CBEM)を伴うトランザクションを監視及び規制する、個人/クライアント認証及び検証処理、偽名性システムを提供する。【解決手段】システム規制ユーティリティを実行するシステムプロセッサ420と、1又は複数の承認済み通貨アドレスと、承認済みトランザクションネットワークと、システムプロセッサに対して通信可能に接続されるクライアント情報データベース115と、トランザクションデータベース413と、クライアントウォレット416、417が設けられる少なくとも1つのクライアント装置414、415とを有し、クライアント装置は、承認済み通貨アドレスを生成するための許可と、CBEMの単位を受取先の通貨アドレスに送金するための承認済みトランザクションを生成する許可を、システムプロセッサから取得し、承認済みトランザクションを生成する。システムプロセッサは、承認済みトランザクションを受信すると、許可前に所定期間遅延させ、条件判定に応じて許可する。【選択図】図4
Description
本発明は、個人認証及び確認システム及び方法に関わる。特に、本発明は、個人/クライアント認証及び確認処理と、偽名性システム、及び暗号型電子マネー/法的身分関連クレデンシャル検証プロトコルのトランザクションを監視、規制するトランザクションネットワークに関する。
デジタル通貨やデジタルマネーが従来技術において定義されている。それらは、インターネットに基づくトランザクション媒体(即ち、紙幣やコインのような物理通貨と異なる)であって、物理通貨と同様の特性を持ちながら、即時トランザクションを可能とし、所有権をボーダレスに移転可能とする。
仮想通貨、暗号通貨はそれぞれデジタル通貨の一種であるが、デジタル通貨がそれら通貨の一種ではない。現状の金銭同様、これら通貨は、物理的な商品やサービスの購入に利用できる。ビットコインのようなデジタル通貨は、「分散型デジタル通貨」とも称される。即ち、中央集権的なマネーサプライ制御が不在である(Wikipedia参照)。
ビットコインは、2008年に発明された暗号型電子マネー(CBEM、暗号型電子マネー)である。ビットコインは仮想通貨であるだけではなく、金銭トランザクションの記録、認証用の分散型ピアツーピアトランザクションネットワークを含む決済システムでもある。
ビットコイン所有者はそれぞれ、固有のビットコインアドレスが1又は複数割り当てられており、クライアントウォレットというソフトウェアを所有している。ビットコイン(即ち暗号通貨単位)の所有権は、各所有者のクライアントに記憶されるのではなく、所有者のビットコインアドレスを利用して、全てのビットコイントランザクションの公開台帳、即ちブロックチェーンに記録されるのである。ビットコインアドレスは、公開/秘密(ECDSA)楕円曲線デジタル署名アルゴリズム鍵組の公開部分における、160ビットハッシュ値である。各ビットコインアドレスの秘密鍵は、当該アドレスの所有者のクライアントウォレットに格納される。
クライアントウォレット同士は、インターネットを介して接続され、トランザクションを仲介、検証するトランザクションネットワークのノードを形成する。公開/秘密鍵暗号化を使用すれば、自身のビットコインアドレスに記録された金額のビットコインを、別のビットコインアドレスに送金するための「署名」(即ち、自身の秘密鍵を使用)を実行できる。通常、秘密鍵によりトランザクションが署名されると、トランザクションネットワーク上の誰もが、署名が有効であるか検証できる。更に、トランザクションネットワーク上の誰もが、台帳を確認してトランザクションが有効か、即ち、ビットコインの送り主が、送金額を実際に所有しているかを判断できる。
2008年以降、様々なビットコイン以外の暗号型電子通貨が開発されており、それらはまとめてオルトコインと呼ばれる。その中で、独特な暗号化ハッシュアルゴリズムを使うもの(例えばLiteコイン)、及び/又は追加機能を有するものや(例えば、Cinniコイン)、独特な署名技術を使うもの(例えば、CryptoNote)が開発されている。
ビットコインが偽名性を伴う一方、オルトコインは全て偽名性又は匿名性を伴う。匿名性を伴う暗号通貨の場合、金銭トランザクションにおける送り主、受取先の全てを追跡することが不可能であるため、マネーロンダリングに使われやすい。
偽名性を伴う暗号通貨に関して、実際の商品、サービスの購入で使用されるビットコインアドレスのパターンを分析することで、施設同士のやり取りの証拠が特定可能であることを示す学術研究が発表された(Meiklejohn S,et al. University of California,San Diego,2013)。
この手法は、施設レベルでの不正行為の特定には有効であるが、個人レベルにまで適用範囲を広げるには至っていない。近年、ビットコインアドレスをIPアドレスにマッピング可能であるとことを示す学術研究(Koshy P,et al. Pennsylvania State University,2014)が発表された。しかし、この手法が適用できるのは、ビットコインアドレスの1割未満に過ぎない。したがって、ビットコインやオルトコインはマネーロンダリング等の不正行為に使用され得ると一般的に考えられている(Bryans D,Indiana Law Journal,89(1):441、2014)。
ビットコインやオルトコインはその偽名性、匿名性により、ハッカーや窃盗犯の格好の標的になってしまっている。例えば、2014年2月、当時世界最大のビットコイン取引所であったマウントゴックス社が、度重なるハッキング被害により、破綻手続きに追い込まれた。被害額は、850,000ビットコイン(約4億8千万USドル)であった。
2015年1月、当時世界三位のビットコイン取引所であった、スロヴェニアのビットコイン取引所であるBitstampが攻撃を受け、最低19,000BTC(当時価格で五百万USドル)が盗まれた。盗んだビットコインは所有するビットコインアドレスに送金する必要があるが、事件に関わったハッカー/窃盗犯の多くの身元は不明である。
したがって、ビットコインの盗難防止ソリューションが求められている。ビットコインの所有権は、ユーザウォレットに格納された秘密鍵で保護されている。秘密鍵はパスフレーズから生成できる。例えば、ビットコインアドレスと、その秘密鍵をパスフレーズのSHA−256から生成するツールを提供するウェブサイトとして、Brainwalletを利用可能である。パスワード辞書を使えば、ビットコインブロックチェーンを分析して、一般的なパスワードから生成された有効なビットコインアドレスを探して、秘密鍵を取得し、使用することで当該アドレスからビットコインを盗むことができる。
一つの盗難防止対策として、典型的なパスフレーズを使用して生成されたビットコインアドレスの使用を避けることが挙げられる。別のビットコインアドレスについては、ハッカーはビットコイン所有者のコンピュータ又はサーバにハッキングをかけ、秘密鍵の記録を含むファイルを捜索する。当該ファイルが見つかると、そのアドレスに格納されたビットコインは、別のアドレスに容易に移転できる。簡単な対抗策として、そのようなファイルをコールドストレージ(即ち、インターネットに接続されていない装置)に保存するか、そもそもそのようなファイルを生成しないことが挙げられる。
ビットコインを盗む別の方法として、インターネットに接続されたコンピュータ又はサーバにインストールされたビットコインウォレット内のメインウォレットデータファイル(即ち、wallet.dat.file)を盗むことが挙げられる。wallet.dat.fileを盗むことができるオンラインバンキング型トロイの木馬についてRobert Lipovsky(2013)で報告されている。秘密鍵は、wallet.dat.fileに格納され、パスフレーズで保護されている。メインウォレットデータファイルが盗まれると、辞書に基づく推測、辞書単語配列、又はとにかく力業にて保護用のパスフレーズが解読され得る。
そのようなビットコインウォレット盗難に対する対策の一つが、中国特許出願公開第103927656(A)号「埋込式、固定収集アドレスを有するビットコイン端末ウォレット及びビットコイン端末ウォレットのビットコイン支払方法(Bitcoin Terminal Wallet with Embedded, Fixed Collecting Address and Bitcoin Payment Method of Bitcoin Terminal Wallet)」に記載されている。
上記問題に対するシンプルな対策の一つとして、ビットコインを多署名アドレスに格納することが挙げられる。これは、ビットコインを使うために、2つの秘密鍵が求められる通貨アドレスである。一方の秘密鍵は、コンピューティングデバイス(例えば、ローカルコンピュータ)に格納され、他方の鍵が別のコンピューティングデバイス(例えば、スマートフォン、リモートサーバ)に格納される。これにより、トランザクションの二要素認証が実現される。このようなソリューションは本発明の前に存在しなかった。
別の対策としては、ビットコインの送り主及び受取先を全て特定可能にすることが挙げられる。この場合、盗まれたビットコインを受け取ったビットコインアドレスの所有者の法的身分を確認することで、窃盗犯又はハッカーの身分が特定できる。この方策は、本発明の前に存在しなかった。
現在、ビットコインに対する、AML(アンチマネーロンダリング)ソリューションが大いに望まれている。現在、ビットコインサービス提供企業は、KYC(顧客確認)及びトランザクションモニタリングの組み合わせにより、AMLにおける米国(FinCEN)及び世界的規制に準拠可能となっている。即ち、全てのトレーダ/顧客は、自身の法的身分を提供して、認証される必要がある。但し、この方策は、2つの大きな問題がある。第1に、この方策を利用するのは、主に合法的なサービスを提供する企業である。したがって、これによって世界規模のビットコインに関するAMLがなくなることはないと考えられる。第2に、企業は通常、独自の顧客登録、個人認証システムを有する。
これは、冗長資源や高いビジネスランニングコストにつながるのみならず、ビットコインユーザにとっての煩わしさが増す。即ち、誠実なビットコインユーザは、異なるビットコインサービス提供企業に対して、そのサービス利用前に、身分証明のために毎回身分証明書を提出する必要があり得る。
2015年2月25日、イングランド銀行は、「ワンバンクリサーチアジェンダ」を公表した。当銀行で革新的な調査研究を行うという、野心的且つ広範囲の枠組みである。この討議論文によると、イングランド銀行は、中央銀行が、ビットコインのブロックチェーン技術を利用して、独自のデジタル通貨を発行すべきかを調査している。イングランド銀行は、KYC、AMLについての問題を解決し、プライバシー問題にも配慮しながら、デジタル身元管理を実現できるかを調査すべきであると述べている。
したがって、上述の問題を少なくとも部分的に解決できる、暗号型電子マネーのトランザクション監視及び規制のための個人/クライアント認証及び検証処理、偽名性システム、トランザクションネットワークを設計することは有用であろう。
本発明の「法的身分関連クレデンシャル検証プロトコル」は、ユーザのプライバシーを守りながら、暗号通貨盗難、KYC、AMLに関する問題に対処する初の実践的ソリューションである。
最後に、非常に重要な点として、中央銀行又はその他金融機関が本発明を利用、修正して、台帳支払システムに対応し、且つ中央運営団体により規制され得る独自のデジタル通貨を発行できる。台帳は、公開されてもされなくてもよい。当該デジタル通貨は、現行の銀行業務システム及び暗号型電子マネーの利点を併せ持つことができる。
本発明の実施形態は、以下の態様として、まとめることができる。
1.登録インタフェース(102)として機能する少なくとも1つのコンピュータプログラムを含む計算サーバ(101)が実行する、暗号型電子マネーを伴うトランザクションのための個人/クライアント認証及び検証方法であって、
・1又は複数の潜在的又は既存の通貨ユーザ(103)に対して、アクセスを提供するステップと、
・認証を要するユーザアカウントを登録するために、1又は複数の潜在的通貨ユーザに対して登録インタフェース(102)を提供するステップ(104)と、
・登録者の法的身分証明のための文書提出をリクエストするステップ(105)と、
・登録者の法的身分を検証するステップ(106)と、
・法的身分が認証されなかった登録者のアカウント作成を拒否するステップ(107)と、
・法的身分が認証された、各認証登録者(109)に対して個人/クライアントアカウント(108)を作成するステップ(110)と、
・認証登録者(109)に、関連する認証を含むクレデンシャル(111)を生成可能とするステップ(112)と、
・クライアント情報データベース(115)に、提出された情報を全て格納するステップ(116)と、
・クレデンシャルを、中央認証サーバ(401)に送信(117)するステップと、
・各登録者の1以上の多署名通貨アドレス、クレデンシャル、法的身分をマッピングして格納(118)するステップとを含む、方法。
・1又は複数の潜在的又は既存の通貨ユーザ(103)に対して、アクセスを提供するステップと、
・認証を要するユーザアカウントを登録するために、1又は複数の潜在的通貨ユーザに対して登録インタフェース(102)を提供するステップ(104)と、
・登録者の法的身分証明のための文書提出をリクエストするステップ(105)と、
・登録者の法的身分を検証するステップ(106)と、
・法的身分が認証されなかった登録者のアカウント作成を拒否するステップ(107)と、
・法的身分が認証された、各認証登録者(109)に対して個人/クライアントアカウント(108)を作成するステップ(110)と、
・認証登録者(109)に、関連する認証を含むクレデンシャル(111)を生成可能とするステップ(112)と、
・クライアント情報データベース(115)に、提出された情報を全て格納するステップ(116)と、
・クレデンシャルを、中央認証サーバ(401)に送信(117)するステップと、
・各登録者の1以上の多署名通貨アドレス、クレデンシャル、法的身分をマッピングして格納(118)するステップとを含む、方法。
上記の方法は更に、以下のことを1又は複数任意で含んでもよい。
(i)認証は、パスワード保護、二要素認証又は多要素認証により実現されてもよい。
(ii)クレデンシャル(114)を暗号化するステップ、及び/又は
(iii)クレデンシャルは、デジタルな、電子的、又はハードウェアによる存在であって、自己認証用の認証機構として使用可能である。例えば、クレデンシャルは、デジタルコード組(例えば名前とパスワード)、クライアントウォレットソフトウェアを作動させる固有プロダクトキー、携帯電話又は個人セキュアキー発生器等のユーザが所有する物理的装置に結び付けられた、定期的に変化するトークン(例えば、固有の7桁コード)であってもよい。
(i)認証は、パスワード保護、二要素認証又は多要素認証により実現されてもよい。
(ii)クレデンシャル(114)を暗号化するステップ、及び/又は
(iii)クレデンシャルは、デジタルな、電子的、又はハードウェアによる存在であって、自己認証用の認証機構として使用可能である。例えば、クレデンシャルは、デジタルコード組(例えば名前とパスワード)、クライアントウォレットソフトウェアを作動させる固有プロダクトキー、携帯電話又は個人セキュアキー発生器等のユーザが所有する物理的装置に結び付けられた、定期的に変化するトークン(例えば、固有の7桁コード)であってもよい。
2.暗号型電子マネー(CBEM)(201)と関連するトランザクションネットワーク(202)を生成する方法は、ノードとして機能するコンピュータプログラムのネットワークにより事項されるものであって、方法は、
・スタンドアロンコンピュータプログラム、又はクライアントウォレット(111)の機能モジュールであってもよいノード(203)を、1又は複数のクライアントコンピュータ及び/又はサーバ(204)にインストールするステップと、
・全てのノードをつなげて、データ送信ネットワーク(206)を介して、ピアツーピアネットワークのリレーノード(205)を形成するステップと、
・少なくとも1つのCBEMの単位(207)を生成する方法を制御するステップと、
・少なくとも1つのCBEMの単位の所有権を、公開/秘密鍵暗号化(208)により保護するステップと、
・少なくとも1つのCBEMの単位の所有権を、所有者の通貨アドレス(313)を使用した、全てのトランザクションの台帳(例えば、ブロックチェーン)(209)に記録するステップ(210)と、
・少なくとも1つのCBEMの単位の所有権を検証するステップ(211)と、
・中央認証サーバ(401)の1つで、提出されたクレデンシャル(111)を検証することで、少なくとも1つのCBEMの単位を受信するための1又は複数の有効通貨アドレス(313)の生成を、有効登録ユーザ(109)のみに限定するステップ(212)と、
・少なくとも1つのCBEMの単位のトランザクションを、台帳(209)に記録するステップ(213)と、
・少なくとも1つのCBEMの単位のトランザクションを検証するステップ(214)と、
・少なくとも1つのCBEMの単位のトランザクションを行う方法を制御するステップ(215)と、
・トランザクション規則を、少なくとも1つのノードのプログラミングコードに組み込むステップ(216)と、
・送り主からの有効クレデンシャル(111)が必要であること、中央認証サーバ(401)の1つからの1又は複数の認証秘密鍵(406)が必要であることの内の少なくとも一方を含む、少なくとも1つのトランザクション承認規則(217)を限定するステップと、
・pay−to−script−hash形式又はその他対応する形式での多署名トランザクションのみの生成を許可するステップ(218)と、
・それぞれ、少なくとも2の秘密鍵を署名として要する、多署名トランザクションのみの生成を許可するステップ(219)と、
・有効クレデンシャル(111)の存在下で、多署名トランザクションのみの生成を許可するステップ(220)と、
・これら秘密鍵(219)の内の1つを、中央認証サーバの1つからの認証秘密鍵(406)に限定するステップ(221)と、
・残りの秘密鍵(219)を、暗号化されて1以上のクライアントウォレット(301)に格納されるクライアント秘密鍵(222)に限定するステップ(223)と、
・クライアントウォレット(301)からの全てのトランザクションリクエストを、中央認証サーバ(401)の1つに送り、トランザクションを署名するための認証秘密鍵を得るステップ(224)と、
・必要な秘密鍵(219)の内の任意の1つが不在のトランザクションを全て拒絶するステップ(225)とを含む、方法。
・スタンドアロンコンピュータプログラム、又はクライアントウォレット(111)の機能モジュールであってもよいノード(203)を、1又は複数のクライアントコンピュータ及び/又はサーバ(204)にインストールするステップと、
・全てのノードをつなげて、データ送信ネットワーク(206)を介して、ピアツーピアネットワークのリレーノード(205)を形成するステップと、
・少なくとも1つのCBEMの単位(207)を生成する方法を制御するステップと、
・少なくとも1つのCBEMの単位の所有権を、公開/秘密鍵暗号化(208)により保護するステップと、
・少なくとも1つのCBEMの単位の所有権を、所有者の通貨アドレス(313)を使用した、全てのトランザクションの台帳(例えば、ブロックチェーン)(209)に記録するステップ(210)と、
・少なくとも1つのCBEMの単位の所有権を検証するステップ(211)と、
・中央認証サーバ(401)の1つで、提出されたクレデンシャル(111)を検証することで、少なくとも1つのCBEMの単位を受信するための1又は複数の有効通貨アドレス(313)の生成を、有効登録ユーザ(109)のみに限定するステップ(212)と、
・少なくとも1つのCBEMの単位のトランザクションを、台帳(209)に記録するステップ(213)と、
・少なくとも1つのCBEMの単位のトランザクションを検証するステップ(214)と、
・少なくとも1つのCBEMの単位のトランザクションを行う方法を制御するステップ(215)と、
・トランザクション規則を、少なくとも1つのノードのプログラミングコードに組み込むステップ(216)と、
・送り主からの有効クレデンシャル(111)が必要であること、中央認証サーバ(401)の1つからの1又は複数の認証秘密鍵(406)が必要であることの内の少なくとも一方を含む、少なくとも1つのトランザクション承認規則(217)を限定するステップと、
・pay−to−script−hash形式又はその他対応する形式での多署名トランザクションのみの生成を許可するステップ(218)と、
・それぞれ、少なくとも2の秘密鍵を署名として要する、多署名トランザクションのみの生成を許可するステップ(219)と、
・有効クレデンシャル(111)の存在下で、多署名トランザクションのみの生成を許可するステップ(220)と、
・これら秘密鍵(219)の内の1つを、中央認証サーバの1つからの認証秘密鍵(406)に限定するステップ(221)と、
・残りの秘密鍵(219)を、暗号化されて1以上のクライアントウォレット(301)に格納されるクライアント秘密鍵(222)に限定するステップ(223)と、
・クライアントウォレット(301)からの全てのトランザクションリクエストを、中央認証サーバ(401)の1つに送り、トランザクションを署名するための認証秘密鍵を得るステップ(224)と、
・必要な秘密鍵(219)の内の任意の1つが不在のトランザクションを全て拒絶するステップ(225)とを含む、方法。
3.ユーザのクライアント装置として機能するコンピュータプログラムにより実行される、暗号型電子マネーを伴うトランザクションのための個人/クライアント認証及び検証方法であって、
・クライアント装置のコンピュータプログラムをクライアントウォレット(301)として機能するように、少なくとも1つのコンピュータ又は計算サーバ(302)にインストールするステップと、
・トランザクションネットワーク(202)で生成される、全てのCBEM単位(例えばコイン)の情報をリレーする、リレーノード(205)の1つとして機能するステップ(303)と、トランザクションネットワーク(202)の全てのトランザクション情報をリレーする、リレーノード(205)の1つとして機能するステップ(304)と、
・トランザクションネットワーク(202)にブロードキャストされる全てのトランザクションを検証、確認するリレーノードの1つとして機能するステップ(305)と、
・全てのトランザクションの台帳(例えば、ブロックチェーン)(209)に、あらゆる新たなトランザクション情報を格納することに寄与することで、新たなコインを生成するステップ(306)と、
・コインの受取、送金のための、1又は複数の暗号化クライアント公開鍵(307)及びクライアント秘密鍵(308)組を生成するステップ(309)と、
・通貨ユーザにより生成された、1又は複数の通貨アドレスのクライアント公開―秘密鍵組(要素307,308)を格納するステップ(310)と、
・コインの受取、送金のための、通貨ユーザのクライアントウォレットとして機能するステップ(311)と、
・中央認証サーバ(401)の1つと、登録通貨ユーザ(109)との間の通信を行うためのクライアントウォレットとして機能するステップ(312)と、
・多署名アドレス(313)である通貨アドレスのみを生成するステップ(314)と、
・クライアント公開鍵(307)及び認証公開鍵(405)から、1又は複数の多署名アドレス(313)を生成するステップ(315)と、
・コインの送金及び受取のためのクライアントウォレット(301)に、1又は複数の多署名アドレス(313)のみを格納するステップ(316)と、
・1又は複数の多署名アドレス(313)をクライアント情報データベース(401)に送信して格納し、1以上のアドレスの所有者の法的身分へとマッピングするステップ(317)と、
・生成した有効多署名アドレス(313)を中央認証サーバ(401)に送信して格納するステップ(318)と、
・有効登録ユーザ(109)のクレデンシャル(111)を中央認証サーバの1つに提出して、1又は複数の有効多署名アドレス(313)を生成するための承認を得るステップ(319)と、
・有効登録ユーザ(109)のクレデンシャル(111)を中央認証サーバの1つに提出して、1又は複数の通貨アドレスへとコインを送金するための1又は複数の有効トランザクション(要素218、219、220、221、223)を生成するための承認を得るステップ(320)と、
・コインの受取、送金の両方のための、多署名アドレス(313)を使用するトランザクションのみを生成可能とするステップ(321)と、
・コインが送金された直後の通貨アドレスにおいて、ブロックチェーンに未使用分のコイン(全額使用されていない場合)を記録するステップ(322)とを含む、方法。
・クライアント装置のコンピュータプログラムをクライアントウォレット(301)として機能するように、少なくとも1つのコンピュータ又は計算サーバ(302)にインストールするステップと、
・トランザクションネットワーク(202)で生成される、全てのCBEM単位(例えばコイン)の情報をリレーする、リレーノード(205)の1つとして機能するステップ(303)と、トランザクションネットワーク(202)の全てのトランザクション情報をリレーする、リレーノード(205)の1つとして機能するステップ(304)と、
・トランザクションネットワーク(202)にブロードキャストされる全てのトランザクションを検証、確認するリレーノードの1つとして機能するステップ(305)と、
・全てのトランザクションの台帳(例えば、ブロックチェーン)(209)に、あらゆる新たなトランザクション情報を格納することに寄与することで、新たなコインを生成するステップ(306)と、
・コインの受取、送金のための、1又は複数の暗号化クライアント公開鍵(307)及びクライアント秘密鍵(308)組を生成するステップ(309)と、
・通貨ユーザにより生成された、1又は複数の通貨アドレスのクライアント公開―秘密鍵組(要素307,308)を格納するステップ(310)と、
・コインの受取、送金のための、通貨ユーザのクライアントウォレットとして機能するステップ(311)と、
・中央認証サーバ(401)の1つと、登録通貨ユーザ(109)との間の通信を行うためのクライアントウォレットとして機能するステップ(312)と、
・多署名アドレス(313)である通貨アドレスのみを生成するステップ(314)と、
・クライアント公開鍵(307)及び認証公開鍵(405)から、1又は複数の多署名アドレス(313)を生成するステップ(315)と、
・コインの送金及び受取のためのクライアントウォレット(301)に、1又は複数の多署名アドレス(313)のみを格納するステップ(316)と、
・1又は複数の多署名アドレス(313)をクライアント情報データベース(401)に送信して格納し、1以上のアドレスの所有者の法的身分へとマッピングするステップ(317)と、
・生成した有効多署名アドレス(313)を中央認証サーバ(401)に送信して格納するステップ(318)と、
・有効登録ユーザ(109)のクレデンシャル(111)を中央認証サーバの1つに提出して、1又は複数の有効多署名アドレス(313)を生成するための承認を得るステップ(319)と、
・有効登録ユーザ(109)のクレデンシャル(111)を中央認証サーバの1つに提出して、1又は複数の通貨アドレスへとコインを送金するための1又は複数の有効トランザクション(要素218、219、220、221、223)を生成するための承認を得るステップ(320)と、
・コインの受取、送金の両方のための、多署名アドレス(313)を使用するトランザクションのみを生成可能とするステップ(321)と、
・コインが送金された直後の通貨アドレスにおいて、ブロックチェーンに未使用分のコイン(全額使用されていない場合)を記録するステップ(322)とを含む、方法。
4.中央認証サーバ(401)として機能する計算サーバにおけるコンピュータプログラムにより実行される、暗号型電子マネーを伴うトランザクションのための個人/クライアント認証及び検証方法であって、
・有効クレデンシャルの存在下で、1又は複数の有効多署名通貨アドレス(313)を生成するために、クライアントウォレット(301)と通信(407)するステップと、
・1又は複数の多署名アドレス(313)を生成するために、認証公開鍵(405)を通貨ウォレットに提供(408)するステップと、
・有効クレデンシャルの存在下で、1又は複数の通貨アドレスにコインを送金するために、1又は複数の有効トランザクション(218、219、220、221、223)を生成するために、クライアントウォレット(301)と通信(409)するステップと、
・多署名アドレス(313)の生成に使用される認証公開鍵(405)に対応する認証秘密鍵(406)を提供(410)することで、1又は複数の有効トランザクション(218、219、220、221、223)に対するトランザクション入力に署名するステップと、
・1又は複数の有効トランザクション(412)に対して、トランザクション全体に署名するため、最新の秘密鍵(411)を提供するステップと、
・トランザクションデータベース(413)にトランザクション情報を格納(414)するステップとを含む、方法。
・有効クレデンシャルの存在下で、1又は複数の有効多署名通貨アドレス(313)を生成するために、クライアントウォレット(301)と通信(407)するステップと、
・1又は複数の多署名アドレス(313)を生成するために、認証公開鍵(405)を通貨ウォレットに提供(408)するステップと、
・有効クレデンシャルの存在下で、1又は複数の通貨アドレスにコインを送金するために、1又は複数の有効トランザクション(218、219、220、221、223)を生成するために、クライアントウォレット(301)と通信(409)するステップと、
・多署名アドレス(313)の生成に使用される認証公開鍵(405)に対応する認証秘密鍵(406)を提供(410)することで、1又は複数の有効トランザクション(218、219、220、221、223)に対するトランザクション入力に署名するステップと、
・1又は複数の有効トランザクション(412)に対して、トランザクション全体に署名するため、最新の秘密鍵(411)を提供するステップと、
・トランザクションデータベース(413)にトランザクション情報を格納(414)するステップとを含む、方法。
上述の方法のうちの任意のもの又は全ては、以下の特徴の1又は複数を有してもよい。
最新の認証秘密鍵(411)は、多署名アドレス(313)の生成に使用される認証公開鍵(405)に対応する認証秘密鍵、又はその他認証秘密鍵である。
トランザクションデータベース(413)にトランザクション情報を格納(414)するステップは、トランザクションID、送り主の通貨アドレス、受取先の通貨アドレス、コインの送金額、トランザクション時間、送り主及び受取先のクライアントウォレットのIPアドレスを格納することを含む。
方法は更に、中央認証サーバ(401)における1又は複数のトランザクション基準(501、502)に対してトランザクションを検証するステップを含む。
1又は複数のトランザクション基準(501、502)は、中央運営団体(601)及び/又は登録者が予め策定した基準を含む。
更に/或いは、方法は更に、送り主及び受取先の通貨アドレスを、トランザクションデータベース及びクライアント情報データベースに適宜マッピングすることで、送り主及び受取先の法的身分を追跡するステップを含む。
5.中央運営団体及びユーザのクライアント装置の装置として機能する、コンピュータプログラム群により実行される、暗号型電子マネーを伴うトランザクションのための個人/クライアント認証及び検証方法であって、
・多署名を定義する少なくとも二要素認証クレデンシャルを含む、登録者のクレデンシャルを受信するステップと、
・登録者の法的身分を認証するステップと、
・認証成功した法的身分(110)を有する各認証成功登録者(109)の、各登録者(118)の法的身分と通貨アドレスの多署名のマッピング、格納を容易にする、個人/クライアントアカウント(108)を生成するステップと、
・少なくとも1つの電子マネーの単位を含む登録者ウォレットを提供するステップと、
・登録者の通貨アドレス(313)を使用して、トランザクションデータベース(413)に少なくとも1つの電子マネーの単位の所有権を記録するステップと、
・それぞれ少なくとも2の秘密鍵を承認署名(219)として要する多署名トランザクションを、pay−to−script−hash形式又はその他対応する形式(218)で生成するステップと、
・これら秘密鍵(219)を、中央認証サーバ(221)の1つからの認証秘密鍵(406)に限定するステップと、
・残りの秘密鍵(219を、クライアントウォレット(301、223)に格納される登録者の秘密鍵(222)に限定するステップと、
・トランザクション(224)に署名するための認証秘密鍵を取得するため、クライアントウォレット(301)からトランザクションリクエストを中央認証サーバ(401)の少なくとも1に送信するステップと、
・承認トランザクションメッセージを、トランザクションネットワーク(214)における全てのリレーノードにブロードキャストするステップとを含む、方法。
・多署名を定義する少なくとも二要素認証クレデンシャルを含む、登録者のクレデンシャルを受信するステップと、
・登録者の法的身分を認証するステップと、
・認証成功した法的身分(110)を有する各認証成功登録者(109)の、各登録者(118)の法的身分と通貨アドレスの多署名のマッピング、格納を容易にする、個人/クライアントアカウント(108)を生成するステップと、
・少なくとも1つの電子マネーの単位を含む登録者ウォレットを提供するステップと、
・登録者の通貨アドレス(313)を使用して、トランザクションデータベース(413)に少なくとも1つの電子マネーの単位の所有権を記録するステップと、
・それぞれ少なくとも2の秘密鍵を承認署名(219)として要する多署名トランザクションを、pay−to−script−hash形式又はその他対応する形式(218)で生成するステップと、
・これら秘密鍵(219)を、中央認証サーバ(221)の1つからの認証秘密鍵(406)に限定するステップと、
・残りの秘密鍵(219を、クライアントウォレット(301、223)に格納される登録者の秘密鍵(222)に限定するステップと、
・トランザクション(224)に署名するための認証秘密鍵を取得するため、クライアントウォレット(301)からトランザクションリクエストを中央認証サーバ(401)の少なくとも1に送信するステップと、
・承認トランザクションメッセージを、トランザクションネットワーク(214)における全てのリレーノードにブロードキャストするステップとを含む、方法。
6.暗号型電子マネーを伴うトランザクションのための個人/クライアント認証及び検証システムであって、
・クライアント登録リクエスト、クライアント暗号通貨アドレス、暗号通貨トランザクションを処理するために、第7態様の方法を実行するように構成された中央認証サーバ(401)と、
・中央認証サーバ(401)に通信可能に接続されたクライアント情報データベース(404)と、
・中央認証サーバ(401)に通信可能に接続されたトランザクションデータベース(413)と、
・少なくとも1つの電子マネーの単位を含む登録者ウォレット(416、417)が設けられた少なくとも1つのクライアント装置(414、415)とを有し、
・少なくとも1つのクライアント装置(414、415)は上記態様の任意の1又は複数の方法を実行するように構成された、システム。
・クライアント登録リクエスト、クライアント暗号通貨アドレス、暗号通貨トランザクションを処理するために、第7態様の方法を実行するように構成された中央認証サーバ(401)と、
・中央認証サーバ(401)に通信可能に接続されたクライアント情報データベース(404)と、
・中央認証サーバ(401)に通信可能に接続されたトランザクションデータベース(413)と、
・少なくとも1つの電子マネーの単位を含む登録者ウォレット(416、417)が設けられた少なくとも1つのクライアント装置(414、415)とを有し、
・少なくとも1つのクライアント装置(414、415)は上記態様の任意の1又は複数の方法を実行するように構成された、システム。
7.上記態様の任意の1又は複数の、コンピュータ実行方法の全てのステップを実行するプログラムコード手段を含むコンピュータプログラムであって、当該プログラムはコンピュータ又は計算サーバ上で動作する、コンピュータプログラム。
8.コンピュータ又は計算サーバ上で実行されると、上記態様の任意の1又は複数の、コンピュータ実行方法の全てのステップを実行するコンピュータ実行可能命令を格納するコンピュータ可読媒体。
9.認証公開鍵(405)及び認証秘密鍵(406)の組は、一定期間で、手動又は自動で変更可能であることで、認証公開鍵及び認証秘密鍵が外部に漏洩することが防止される、上記態様の任意の1又は複数の方法。新たな認証鍵の組への変化の後、古い認証秘密鍵は、トランザクション入力(410)の署名に使用され、新たな認証鍵は、トランザクション全体の署名(即ち、全てのトランザクションのデータ)に使用される(412)。
10.有効クレデンシャルを中央認証サーバ(401)の1つに提出して生成されなかったあらゆる通貨アドレスが無効であり、どのようなコインも受け取ることができない、上記態様の任意の1又は複数の方法。
11.トランザクションネットワーク(202)は、中央トランザクション基準(501)又は中央認証サーバ(401)の1つに格納されたクライアントトランザクション基準(502)に準拠しないあらゆるトランザクションを拒否するように変形できる、上記態様の任意の1又は複数の方法。
以下のうち1又は複数のものが、上記態様の任意の1又は複数の方法に追加できる。
有効登録ユーザは、自身のトランザクションを制限するためのクライアントトランザクション基準(502)を策定できる。
中央運営団体(601)は、トランザクション基準(501)策定することで、マネーロンダリング等の不正行為に関与する可能性のある疑わしいトランザクションを停止できる。
各トランザクションは、マネーロンダリング等の不正行為に関与する可能性のある疑わしいトランザクションを特定、記録、報告する、所定の規則により監視できる。
各通貨アドレスの所有者の法的身分がクライアント情報データベースに格納される。不正行為の疑いがあるトランザクションについては、送り主及び受取先の通貨アドレスの追跡により、関連する送り主及び受取先の身元がクライアント情報データベース抽出される。その後、疑わしい活動及び関連するクライアント情報が、関連する国の法律、規則に応じて、政府機関に報告される。
各通貨アドレスの所有者の法的身分が、クライアント情報データベースに格納される。これにより、「顧客確認」規制要件が満たされる。システムが商業活動における支払システムとして利用可能となる。
各通貨アドレスの所有者の法的身分が、クライアント情報データベースに格納される。但し、当該情報は誰にでもアクセスできるものではないため、暗号型電子マネー(201)及びそのトランザクションネットワーク(202)の匿名性が保たれる。
ユーザは、自身のクレデンシャル(111)を変更して、自身の通貨ウォレット(301)の盗まれたメインデータファイル(例えばウォレット、datファイル)からの、コインの出金を止めることができる。
(i)各通貨アドレスの所有者の法的身分が、クライアント情報データベースに格納され、(ii)有効クレデンシャルを中央認証サーバ(401)の1つに提出して生成されなかったあらゆる通貨アドレスが無効であり、どのようなコインも受け取ることができず(態様18)、(iii)有効登録ユーザのみが有効クレデンシャル(112)を有する。コインが盗まれると、1以上の受取先の1以上の通貨アドレスに応じて、クライアント情報データベースから1以上の受取先の1以上の法的身分を読み出すことで、容易にコインを盗んだ1以上の窃盗犯又は1以上のハッカーを追跡できる。このように、この形態の上記1以上の方法は、暗号通貨の盗難を防止する。
(ii)有効登録ユーザが所有するコインの金額は、トランザクションデータベース(413)内のトランザクション記録を分析することで、中央運営団体(601)により完全かつ容易に捜索、追跡可能である。各通貨アドレスをその所有者に結び付ける機能とは別に設けられたこの固有の特性は、コインが送金/支払われた直後の通貨アドレスにおける未使用分のコイン(全額使用されていない場合)を記録することに基づく(322)。この固有の特性は、システムを、特に第三者の監査の下に実現される金融、銀行業務に適用可能にするものである。
(iii)ユーザのプライバシーを守りながら、暗号通貨盗難、KYC、AMLに関する問題に対する実践的ソリューションを提供する。
(iv)更に/或いは、中央銀行又はその他金融機関が本発明を利用、修正して、分散型台帳支払システムに対応し、且つ中央運営団体により規制され得る独自のデジタル通貨を発行可能とするために利用可能である。
更に、全ての金銭トランザクションにおける送り主及び受取先の法的身分が追跡可能な、新たな暗号型電子マネー又は暗号通貨を生成するシステムを伴う方法が開示される。方法は、以下の要素を有するシステムにより実行可能である。
1.少なくとも1つのサーバ及び少なくとも1つのウェブ登録インタフェース。少なくともつ1つのサーバは以下の機能のうちの少なくとも一部又は全部を実行する。
・1又は複数の潜在的又は既存の通貨ユーザ(103)に対して、アクセスを提供する
・パスワード保護、二要素認証又は多要素認証によりユーザアカウントを登録するために、1又は複数の潜在的通貨ユーザに対してオンラインインタフェースを提供する
・登録者の法的身分証明のための文書提出をリクエストする
・登録者の法的身分を検証する
・法的身分が認証されなかった登録者のアカウント作成を拒否する
・法的身分が認証された、各認証登録者に対して個人/クライアントアカウントを作成する
・認証登録者に、ラベルとパスワードを含むクレデンシャルを生成可能とする
・認証登録者に、クレデンシャルと連絡先情報を変更可能とする
・クレデンシャルを暗号化する
・全ての提出された情報、特に法的身分及び暗号化クレデンシャルを、クライアント情報データベースに格納する
・新たに作成された又は変更された暗号化クレデンシャルを中央認証サーバに送る
・各登録者の1以上の多署名通貨アドレス、クレデンシャル、法的身分をマッピングして格納する。
・1又は複数の潜在的又は既存の通貨ユーザ(103)に対して、アクセスを提供する
・パスワード保護、二要素認証又は多要素認証によりユーザアカウントを登録するために、1又は複数の潜在的通貨ユーザに対してオンラインインタフェースを提供する
・登録者の法的身分証明のための文書提出をリクエストする
・登録者の法的身分を検証する
・法的身分が認証されなかった登録者のアカウント作成を拒否する
・法的身分が認証された、各認証登録者に対して個人/クライアントアカウントを作成する
・認証登録者に、ラベルとパスワードを含むクレデンシャルを生成可能とする
・認証登録者に、クレデンシャルと連絡先情報を変更可能とする
・クレデンシャルを暗号化する
・全ての提出された情報、特に法的身分及び暗号化クレデンシャルを、クライアント情報データベースに格納する
・新たに作成された又は変更された暗号化クレデンシャルを中央認証サーバに送る
・各登録者の1以上の多署名通貨アドレス、クレデンシャル、法的身分をマッピングして格納する。
1つの暗号型電子マネーと関連するトランザクションネットワークは、以下の基本機能及び独自機能の内の少なくとも一部又は全部を実行する。
1.基本機能(全てのその他の暗号型電子マネーと共通)
・クライアントウォレットソフトウェアを公開する
・コンピュータ又はサーバを、クライアントウォレットを介して接続する
・接続されたコンピュータ又はサーバを利用して、トランザクションネットワークのリレーノードを生成する
・所定金額の金銭単位(コインを)、所定の速度で生成する
・コインの所有権を、公開/秘密鍵暗号化で保護する
・コインの所有権を、所有者の通貨アドレスを利用して、全てのトランザクションの台帳(例えば、ブロックチェーン)に記録する
・全てのトランザクションの台帳(例えば、ブロックチェーン)及びその更新を、クライアントウォレットを介してトランザクションネットワークに接続された人々に配信する
・秘密鍵所有者に、所要のトランザクション費用の低減後の、対応する通貨アドレスに記録されたコインの金額を超えないコインの金額のみを送金可能とする
・全ての新規トランザクションメッセージを、トランザクションネットワークにおける全てのリレーノードにブロードキャストする
・全ての新規トランザクションメッセージを、各リレーノードで検証する
・トランザクション情報(送り主通貨アドレス、受取先通貨アドレス、取引されるコインの金額、トランザクション費用、トランザクション時間を含むがこれらに限定されない)を、全てのトランザクションの台帳(例えば、ブロックチェーン)に記録する。
・クライアントウォレットソフトウェアを公開する
・コンピュータ又はサーバを、クライアントウォレットを介して接続する
・接続されたコンピュータ又はサーバを利用して、トランザクションネットワークのリレーノードを生成する
・所定金額の金銭単位(コインを)、所定の速度で生成する
・コインの所有権を、公開/秘密鍵暗号化で保護する
・コインの所有権を、所有者の通貨アドレスを利用して、全てのトランザクションの台帳(例えば、ブロックチェーン)に記録する
・全てのトランザクションの台帳(例えば、ブロックチェーン)及びその更新を、クライアントウォレットを介してトランザクションネットワークに接続された人々に配信する
・秘密鍵所有者に、所要のトランザクション費用の低減後の、対応する通貨アドレスに記録されたコインの金額を超えないコインの金額のみを送金可能とする
・全ての新規トランザクションメッセージを、トランザクションネットワークにおける全てのリレーノードにブロードキャストする
・全ての新規トランザクションメッセージを、各リレーノードで検証する
・トランザクション情報(送り主通貨アドレス、受取先通貨アドレス、取引されるコインの金額、トランザクション費用、トランザクション時間を含むがこれらに限定されない)を、全てのトランザクションの台帳(例えば、ブロックチェーン)に記録する。
2.独自機能
・中央認証サーバの1つで、提出されたクレデンシャルを検証することで、コインを受け取るための1又は複数の有効通貨アドレスの生成を、有効登録ユーザのみに限定する
・pay−to−script−hash形式又はその他対応する形式での多署名トランザクションのみの生成を許可する
・それぞれ、少なくとも2の秘密鍵を署名として要する、多署名トランザクションのみの生成を許可する
・有効クレデンシャルの存在下で、多署名トランザクションのみの生成を許可する
・これら秘密鍵のうちの1つを、中央認証サーバの1つからの認証秘密鍵に限定する
・残りの秘密鍵を、暗号化されて1以上のクライアントウォレットに格納されるクライアント秘密鍵に限定する
・クライアントウォレットからの全てのトランザクションリクエストを、中央認証サーバの1つに送り、トランザクションを署名するための認証秘密鍵を得る
・必要な秘密鍵の内の任意の1つが不在のトランザクションを全て拒絶する
・「pay−to−script−hash」スクリプト又は電子マネーのソースにトランザクション生成用の唯一のスクリプトとして組み込まれたその他対応スクリプトを使用することで、各トランザクションに対して、トランザクション承認規則を限定する(トランザクション入力及びトランザクション全体の署名のために、送り主からの有効クレデンシャルが必要であること、中央認証サーバの1つからの1又は複数の認証秘密鍵が必要であることを含むがこれらに限定されない)。
・中央認証サーバの1つで、提出されたクレデンシャルを検証することで、コインを受け取るための1又は複数の有効通貨アドレスの生成を、有効登録ユーザのみに限定する
・pay−to−script−hash形式又はその他対応する形式での多署名トランザクションのみの生成を許可する
・それぞれ、少なくとも2の秘密鍵を署名として要する、多署名トランザクションのみの生成を許可する
・有効クレデンシャルの存在下で、多署名トランザクションのみの生成を許可する
・これら秘密鍵のうちの1つを、中央認証サーバの1つからの認証秘密鍵に限定する
・残りの秘密鍵を、暗号化されて1以上のクライアントウォレットに格納されるクライアント秘密鍵に限定する
・クライアントウォレットからの全てのトランザクションリクエストを、中央認証サーバの1つに送り、トランザクションを署名するための認証秘密鍵を得る
・必要な秘密鍵の内の任意の1つが不在のトランザクションを全て拒絶する
・「pay−to−script−hash」スクリプト又は電子マネーのソースにトランザクション生成用の唯一のスクリプトとして組み込まれたその他対応スクリプトを使用することで、各トランザクションに対して、トランザクション承認規則を限定する(トランザクション入力及びトランザクション全体の署名のために、送り主からの有効クレデンシャルが必要であること、中央認証サーバの1つからの1又は複数の認証秘密鍵が必要であることを含むがこれらに限定されない)。
クライアントウォレットソフトウェアを実行する少なくとも1つのコンピュータ又はサーバであって、少なくとも1つのクライアントウォレットは以下の基本機能及び独自機能の内の少なくとも一部又は全部を実行する。
1.基本機能(全てのその他の暗号型電子マネーと共通)
・トランザクションネットワークにおいて、全てのトランザクション情報をリレーする、リレーノードの1つとして機能する
・トランザクションネットワークにブロードキャストされる全てのトランザクションを検証、確認するリレーノードの1つとして機能する
・全てのトランザクションの台帳(例えば、ブロックチェーン)に、あらゆる新たなトランザクション情報を格納することに寄与することで、新たなコインを生成する
・コインの受取、送金のための、1又は複数の暗号化クライアント公開鍵及びクライアント秘密鍵組を生成する
・通貨ユーザにより生成された、1又は複数の通貨アドレスのクライアント公開―秘密鍵組を格納する
・コインの受取、送金のための、通貨ユーザのクライアントウォレットとして機能する。
・トランザクションネットワークにおいて、全てのトランザクション情報をリレーする、リレーノードの1つとして機能する
・トランザクションネットワークにブロードキャストされる全てのトランザクションを検証、確認するリレーノードの1つとして機能する
・全てのトランザクションの台帳(例えば、ブロックチェーン)に、あらゆる新たなトランザクション情報を格納することに寄与することで、新たなコインを生成する
・コインの受取、送金のための、1又は複数の暗号化クライアント公開鍵及びクライアント秘密鍵組を生成する
・通貨ユーザにより生成された、1又は複数の通貨アドレスのクライアント公開―秘密鍵組を格納する
・コインの受取、送金のための、通貨ユーザのクライアントウォレットとして機能する。
2.独自機能
・中央認証サーバの1つと、登録通貨ユーザとの間の通信を行うためのクライアントウォレットとして機能する
・多署名アドレスである通貨アドレスのみを生成する
・クライアント公開鍵及び認証公開鍵から、1又は複数の多署名アドレスを生成する
・コインの送金及び受取のためのクライアントウォレットに、1又は複数の多署名アドレスのみを格納する
・1又は複数の多署名アドレスをクライアント情報データベースに送信して格納し、1以上のアドレスの所有者の法的身分へとマッピングする
・生成した有効多署名アドレスを中央認証サーバに送信して格納する
・有効登録ユーザのクレデンシャルを中央認証サーバの1つに提出して、1又は複数の有効通貨多署名アドレスを生成するための承認を得る
・有効登録ユーザのクレデンシャルを中央認証サーバの1つに提出して、1又は複数の通貨アドレスへとコインを送金するための1又は複数の有効トランザクションを生成するための承認を得る
・コインの受取、送金の両方のための、多署名アドレスを使用するトランザクションのみを生成可能とする
・コインが送金された直後の通貨アドレスにおいて、ブロックチェーンに未使用分のコイン(全額使用されていない場合)を記録する。
・中央認証サーバの1つと、登録通貨ユーザとの間の通信を行うためのクライアントウォレットとして機能する
・多署名アドレスである通貨アドレスのみを生成する
・クライアント公開鍵及び認証公開鍵から、1又は複数の多署名アドレスを生成する
・コインの送金及び受取のためのクライアントウォレットに、1又は複数の多署名アドレスのみを格納する
・1又は複数の多署名アドレスをクライアント情報データベースに送信して格納し、1以上のアドレスの所有者の法的身分へとマッピングする
・生成した有効多署名アドレスを中央認証サーバに送信して格納する
・有効登録ユーザのクレデンシャルを中央認証サーバの1つに提出して、1又は複数の有効通貨多署名アドレスを生成するための承認を得る
・有効登録ユーザのクレデンシャルを中央認証サーバの1つに提出して、1又は複数の通貨アドレスへとコインを送金するための1又は複数の有効トランザクションを生成するための承認を得る
・コインの受取、送金の両方のための、多署名アドレスを使用するトランザクションのみを生成可能とする
・コインが送金された直後の通貨アドレスにおいて、ブロックチェーンに未使用分のコイン(全額使用されていない場合)を記録する。
少なくとも1つの中央認証サーバは、以下の機能の少なくとも一部又は全部を実行する。中央サーバは、トランザクション(311)の許可を得るためのクライアントリクエストを受信すると、AML(アンチマネーロンダリング)基準に関するリスクに関して、トランザクションを調査して、トランザクション許可を遅延する、所定時間、トランザクションに許可を与えるのを遅延する、中央サーバからの警告を、ネットワークを介して、政府機関、リスクコンプライアンス責任者、クライアント、中央サーバが運営するシステムに関連する個人の内の少なくとも1つに関連する電子装置に送信することのうちの少なくとも1つを実行するように構成される。
いくつかの実施形態において、中央認証サーバは、以下の動作の一部又は全部を実行するように構成される。
1.クライアント情報データベースから、新規の又は更新されたクレデンシャル及びそれに関連した通貨アドレスを読み出す
2.ユーザのクレデンシャル及びそれに関連した通貨アドレスを中央認証サーバに格納して更新する
3.認証公開鍵と認証秘密鍵の1又は複数の組を、生成、変更、暗号化及び格納する
4.有効クレデンシャルの存在下で、1又は複数の有効多署名通貨アドレスを生成するように、クライアントウォレットと通信する
5.1又は複数の多署名アドレスを生成するために、認証公開鍵を通貨ウォレットに提供する
6.有効クレデンシャルの存在下で、1又は複数の通貨アドレスにコインを送金するため、1又は複数の有効トランザクションを生成するように、クライアントウォレットを通信する
7.多署名アドレスの生成に使用する認証公開鍵に対応する認証秘密鍵を提供することで、1又は複数の有効トランザクションに対するトランザクション入力に署名する
8.1又は複数の有効トランザクションのトランザクション全体に署名するために、要素410で使用される認証秘密鍵又は最新の認証秘密鍵であり得る、別の認証秘密鍵を提供する
9.全てのトランザクション情報(トランザクションID、送り主通貨アドレス、受取先通貨アドレス、コインの支払い金額、トランザクション費用、トランザクション時間、送り主及び受取先のクライアントウォレットのIPアドレスを含むがこれに限定されない)をトランザクションデータベースに格納する。
2.ユーザのクレデンシャル及びそれに関連した通貨アドレスを中央認証サーバに格納して更新する
3.認証公開鍵と認証秘密鍵の1又は複数の組を、生成、変更、暗号化及び格納する
4.有効クレデンシャルの存在下で、1又は複数の有効多署名通貨アドレスを生成するように、クライアントウォレットと通信する
5.1又は複数の多署名アドレスを生成するために、認証公開鍵を通貨ウォレットに提供する
6.有効クレデンシャルの存在下で、1又は複数の通貨アドレスにコインを送金するため、1又は複数の有効トランザクションを生成するように、クライアントウォレットを通信する
7.多署名アドレスの生成に使用する認証公開鍵に対応する認証秘密鍵を提供することで、1又は複数の有効トランザクションに対するトランザクション入力に署名する
8.1又は複数の有効トランザクションのトランザクション全体に署名するために、要素410で使用される認証秘密鍵又は最新の認証秘密鍵であり得る、別の認証秘密鍵を提供する
9.全てのトランザクション情報(トランザクションID、送り主通貨アドレス、受取先通貨アドレス、コインの支払い金額、トランザクション費用、トランザクション時間、送り主及び受取先のクライアントウォレットのIPアドレスを含むがこれに限定されない)をトランザクションデータベースに格納する。
更に、暗号型電子マネーを伴うトランザクションのための個人/クライアント認証及び検証方法が開示される。方法は、以下のステップのうちの少なくとも1又は全てを含む。
1.登録者の法的身分を検証するステップ
2.認証成功した法的身分を有する各認証成功登録者の、各登録者の法的身分と1以上の通貨アドレスのマッピング及び格納を容易にする、少なくとも二要素認証で保護された個人/クライアントアカウントを生成するステップ
3.各認証成功登録者の、登録者の身元、通貨アドレスの所有権、トランザクションの送り主身元を定義するクレデンシャルを受信するステップ
4.1又は複数の中央認証サーバに、登録者の法的身分とクレデンシャルを格納するステップ
5.少なくとも1つの電子マネーの単位を送金及び受取るための登録者ウォレットを提供するステップ
6.1以上の登録者の通貨アドレスを使用して、全てのトランザクションの台帳(例えば、ブロックチェーン)に、少なくとも1つの電子マネーの単位の所有者を記録するステップ
7.通貨アドレス生成のリクエストに対して、登録者ウォレットから提出されたクレデンシャルを、中央認証サーバで受信、検証するステップ
8.中央認証サーバからの認証公開鍵を登録者ウォレットに提供することで、登録者に属する有効通貨アドレスとして多署名アドレスの生成を許可するステップ
9.登録者ウォレットにおいて、登録者の公開鍵と中央認証サーバの認証公開鍵を組み合わせることで、少なくとも1つの電子マネーの単位を受け取るための有効通貨アドレスを生成するステップ
10.クライアント情報データベースにおいて、登録者の法的身分、クレデンシャル、1又は複数の有効通貨アドレスを格納及びマッピングするステップ
11.それぞれ少なくとも2の秘密鍵を登録者ウォレットにおける署名として要する、「pay−to−script−hash」形式又はその他任意の対応形式のトランザクションを生成するステップ
12.これら秘密鍵の内の少なくとも1つを中央認証サーバの1つからの認証秘密鍵に限定するステップ
13.残りの秘密鍵を、クライアントウォレットに格納された登録者の秘密鍵に限定するステップ
14.「pay−to−script−hash」スクリプト又は電子マネーのソースにトランザクション生成用の唯一のスクリプトとして組み込まれたその他対応スクリプトを使用することで、各トランザクションに対して、トランザクション承認規則を限定する(トランザクション入力及びトランザクション全体の署名のために、送り主からの有効クレデンシャルが必要であること、中央認証サーバの1つからの1又は複数の認証秘密鍵が必要であることを含むがこれらに限定されない)ステップ
15.トランザクション生成のリクエストに対して、登録者ウォレットから提出されたクレデンシャルを、中央認証サーバで受信、検証するステップ
16.中央認証サーバにおいて、1又は複数のトランザクション基準(中央運営団体及び/又は登録者により予め策定されたものを含むが、これに限定されない)に対して、トランザクションを検証するステップ
17.1以上の登録者ウォレットにおける1又は複数の秘密鍵によりトランザクションに署名し、中央認証サーバにおける1又は複数の認証秘密鍵によりトランザクションに署名することで、トランザクションの実行を許可するステップ
18.トランザクションメッセージを、全てのトランザクションの台帳(例えば、ブロックチェーン)に記録するステップ
19.トランザクション情報(トランザクションID、送り主及び受取先の暗号通貨アドレス、取引されるコインの金額、トランザクション時間、送り主及び受取先のクライアントウォレットのIPアドレスを含むがこれらに限定されない)を、トランザクションデータベースに格納するステップ
20.署名されたトランザクションメッセージを、トランザクションネットワークにおける全てのリレーノードに、確認のためブロードキャストするステップ
21.送り主及び受取先の通貨アドレスを、トランザクションデータベース及びクライアント情報データベースに適宜マッピングすることで、送り主及び受取先の法的身分を追跡するステップ。
2.認証成功した法的身分を有する各認証成功登録者の、各登録者の法的身分と1以上の通貨アドレスのマッピング及び格納を容易にする、少なくとも二要素認証で保護された個人/クライアントアカウントを生成するステップ
3.各認証成功登録者の、登録者の身元、通貨アドレスの所有権、トランザクションの送り主身元を定義するクレデンシャルを受信するステップ
4.1又は複数の中央認証サーバに、登録者の法的身分とクレデンシャルを格納するステップ
5.少なくとも1つの電子マネーの単位を送金及び受取るための登録者ウォレットを提供するステップ
6.1以上の登録者の通貨アドレスを使用して、全てのトランザクションの台帳(例えば、ブロックチェーン)に、少なくとも1つの電子マネーの単位の所有者を記録するステップ
7.通貨アドレス生成のリクエストに対して、登録者ウォレットから提出されたクレデンシャルを、中央認証サーバで受信、検証するステップ
8.中央認証サーバからの認証公開鍵を登録者ウォレットに提供することで、登録者に属する有効通貨アドレスとして多署名アドレスの生成を許可するステップ
9.登録者ウォレットにおいて、登録者の公開鍵と中央認証サーバの認証公開鍵を組み合わせることで、少なくとも1つの電子マネーの単位を受け取るための有効通貨アドレスを生成するステップ
10.クライアント情報データベースにおいて、登録者の法的身分、クレデンシャル、1又は複数の有効通貨アドレスを格納及びマッピングするステップ
11.それぞれ少なくとも2の秘密鍵を登録者ウォレットにおける署名として要する、「pay−to−script−hash」形式又はその他任意の対応形式のトランザクションを生成するステップ
12.これら秘密鍵の内の少なくとも1つを中央認証サーバの1つからの認証秘密鍵に限定するステップ
13.残りの秘密鍵を、クライアントウォレットに格納された登録者の秘密鍵に限定するステップ
14.「pay−to−script−hash」スクリプト又は電子マネーのソースにトランザクション生成用の唯一のスクリプトとして組み込まれたその他対応スクリプトを使用することで、各トランザクションに対して、トランザクション承認規則を限定する(トランザクション入力及びトランザクション全体の署名のために、送り主からの有効クレデンシャルが必要であること、中央認証サーバの1つからの1又は複数の認証秘密鍵が必要であることを含むがこれらに限定されない)ステップ
15.トランザクション生成のリクエストに対して、登録者ウォレットから提出されたクレデンシャルを、中央認証サーバで受信、検証するステップ
16.中央認証サーバにおいて、1又は複数のトランザクション基準(中央運営団体及び/又は登録者により予め策定されたものを含むが、これに限定されない)に対して、トランザクションを検証するステップ
17.1以上の登録者ウォレットにおける1又は複数の秘密鍵によりトランザクションに署名し、中央認証サーバにおける1又は複数の認証秘密鍵によりトランザクションに署名することで、トランザクションの実行を許可するステップ
18.トランザクションメッセージを、全てのトランザクションの台帳(例えば、ブロックチェーン)に記録するステップ
19.トランザクション情報(トランザクションID、送り主及び受取先の暗号通貨アドレス、取引されるコインの金額、トランザクション時間、送り主及び受取先のクライアントウォレットのIPアドレスを含むがこれらに限定されない)を、トランザクションデータベースに格納するステップ
20.署名されたトランザクションメッセージを、トランザクションネットワークにおける全てのリレーノードに、確認のためブロードキャストするステップ
21.送り主及び受取先の通貨アドレスを、トランザクションデータベース及びクライアント情報データベースに適宜マッピングすることで、送り主及び受取先の法的身分を追跡するステップ。
本明細書に記載のシステム及び方法は、以下のうちの任意の1又は複数のように変形される。
本明細書に記載のシステム及び方法は、トランザクションを許可するため、1又は複数の独立した中央運営団体からの2以上の認証秘密鍵を必要とするように変形されてもよい。このように変形された電子マネー及び関連した支払ネットワークは、より規制、管理が厳格となる。
或いは、本明細書に記載のシステム及び方法は、トランザクションを許可するため、中央運営団体からの認証秘密鍵を一切必要とせず、電子マネーを受け取り、出金のため、単一のユーザのみが署名する単一署名アドレス又は2以上のユーザにより署名される多署名アドレスを使用するように変形されてもよい。
中央サーバから承認を得るために多署名処理を利用する以外の選択肢として、1以上の中央サーバの機能と同じ機能の一部又は全部を、当該機能のうちの任意のもの又は全てを「スマートコントラクト」に設けることで実行してもよい。スマートコントラクトは、CBEMの転送が許可されるには、所与の入力又は条件の成立が求められるコンピュータ命令の集合である。したがって、1以上の中央サーバにより実行されるコンピュータコードと実質的に同等のものが、中央サーバ機能又は機能を、トランザクションメッセージとブロックチェーン又は分散型台帳へのトランザクションの記録との間の任意の点に設けられることで実行される。スマートコントラクトは、契約条件を実行するためのコンピュータプログラム又はアプリケーションであってもよい。例えば、スマートコントラクトは、実行、暗号化、人又はエンティティ間の合意の実行に関する所定の機能を含んでもよい。スマートコントラクトは、記載の条件の成立に対して、金融又はその他義務の実行のための決済システムであってもよい。当該条件は、CBEM、検証文書、金融手段、法的手段、又はその他データ等のデータの転送を含んでもよい。
本明細書に記載のシステム及び方法は、トランザクションの許可にユーザからの秘密鍵を一切必要とせず、電子マネーを受け取り、出金のため、中央運営団体のみが署名する単一署名アドレス、又は2以上の中央運営団体により署名される多署名アドレスを使用するように変形してもよい。但し、ユーザの、自身の電子マネーの所有権に対する保護が少なくなり得る。当該変形した電子マネー及び関連した支払ネットワークの有効性は、1以上の中央運営団体の信用、誠実さに依存し得る。
上述のシステム及び方法は、以下の好ましい特徴のうちの少なくとも一部、又は全部を有してもよい。
例えば、所与の時間内に、条件又は特定の条件が満たされない場合、システム及び/又はユーザにより、トランザクションが逆転されてもよい。
トランザクションを台帳に記録する前に、保留時間が存在してもよい。当該保留は、自動で実行されてもよく、トランザクション及び/又はその他要素の基づいてもよく、1以上のトランザクション量の増加及び/又はその他要素の存在に応じて延長されてもよい。
システムは、潜在的なトランザクション及び/又は実際のトランザクションを、AML及び/又はその他金融コンプライアンス又はリスクに対して、例えば保留時間中に検査してもよい。
システムは、1又は複数の予め策定された基準又は標準に対する比較により、疑わしいとみなされたあらゆるトランザクションを特定し、自動的に保留、停止、及び/又は逆転してもよい。
当該予め策定された基準又は標準は、AML、KYC、CTF、BSA、FATF及び/又はその他政府、政府間、及び/又はエンティティの、1以上の疑わしい金融トランザクションベースに関する基準を含んでもよい。
ユーザ、第三者配達サービス等の第三者、及び/又はその他入力の内の任意の1又は複数のものからの、システム保留通知に応じて、上記保留が実行されてもよい。
トランザクションに対する保留、及び/又は逆転は、システムから受信された、及び/又は判定されたリスクスコア(例えば、コンプライアンスアルゴリズムに基づく)が所定の閾値以上となることに基づいてもよい。当該リスクスコアは、リスクのある及び/又は違法なソースからの及び/又はへの資金の内の1又は複数に関連付けられた、リスクを含む疑わしい金融トランザクション規則群に基づいて計算されてもよい。当該ソースは、システムに格納された、認証済みの個人身元を1又は複数のリストに基づいて、相互検証することによるデータにより判定される。例えば、当該リストは、公開されたテロリスト及び/又はテロの容疑者、公開されたマネーロンダリング業者及び/又はマネーロンダリングの容疑がある業者、公開された金融犯罪者及び/又は金融犯罪容疑者、暗号通貨窃盗犯リスト、サイバー犯罪関与リスト、FATFブラックリスト及び/又はFATFリスク基準、搭乗拒否リスト、トランザクションロンダリングインジケーター、及び/又はその他コンプライアンス要素に基づくものであってもよい。
システムへのユーザ登録時、IPアドレスの更新等のシステムにおける任意のユーザプロファイルに対するユーザ更新、有効通貨アドレス生成時、任意のトランザクション提示時、ユーザのトランザクション開始時、及び/又は定期的に、システムは単独で又は本明細書に記載のその他監視と協働で、ユーザ及び/又は受取先及び/又はユーザ及び/又は受取先の情報を、IPアドレスリストに対して確認してもよい。
システムは、例えば上述のコンプライアンス要素及び/又はその他要素に基づいて、トランザクション受取先のアカウント等のユーザアカウントを凍結してもよい。
システムは、IPアドレスの所在地に基づいて、及び/又はシステムにおけるユーザ又は受取先のプロファイルの場所に基づいて、制裁リスト及び/又は禁輸リストの国の受取先及び/又はユーザのあらゆるトランザクションを停止、及び/又は逆転してもよい。
上述の任意のステップ、及び/又はその他金融犯罪検出ステップの一部として、システムは更にユーザの疑わしい活動を監視してもよい。例えば、ユーザのウェブブラウジング履歴における疑わしいウェブ上活動を監視してもよい。当該活動は、例えば、公開されたテロリスト、及び/又はテロ容疑者のウェブサイト閲覧が挙げられる。
システムは、疑わしい活動の検出、及び/又は監視に加えて、当該疑わしい活動の検出に応じて、警告を発してもよい。当該警告は、コンピュータモニタ等のユーザインタフェース上に表示される、音声警告、及び/又はその他警告であって、好ましくは中央サーバ及び/又はシステムに関連した個人に送られ、任意でその他任意のユーザにも送られる。好ましくは、当該ユーザは、偽装トランザクションに関わってしまった無罪のユーザ等の、犯罪に関与していない(疑わしくない)1又は複数のユーザに限られる。
システムは、上述の警告の代わりに及び/又は加えて、更に/或いはあらゆる潜在的トランザクション、更に/或いは潜在的受取先、更に/或いは潜在的トランザクションにおけるその他団体、上述の種類のリスクスコアを提供してもよい。
システムは、典型的な多署名チャネルを介して、システムと通信するウォレットを使用して、トランザクションへの署名のリクエスト及び/又はトランザクションを署名した又はしていないユーザからのトランザクションへの署名のリクエストに応答してもよい。
システムは、ユーザからのトランザクションへの署名のリクエストを受信し、所与の条件が満たされるまで署名をしないことで、トランザクションを保留してもよく、更に/或いはトランザクションが金融犯罪に関わるリスクの閾値量及び/又は閾値種類により、トランザクションに署名しなくてもよい。
システムは、トランザクションへのユーザ署名等の潜在的トランザクションに応じて、その本明細書に記載の任意の活動を実行してもよい。
システムは、例えば疑わしいトランザクション及び/又は疑わしいユーザをシステムが検出により実行されるSAR及び/又はSTR及び/又はその他所要の報告のための、SAR、STR及び/又は関連報告対応ソフトウェアを含んでもよい。
ユーザは、システムにおいて、オンライン及び/又はオフラインウォレットを使用してもよい。
好ましくは、認証公開鍵及び認証秘密鍵の組は、一定期間で、手動又は自動で変更可能であることで、認証公開鍵及び認証秘密鍵が外部に漏洩することが防止される。新たな認証鍵の組への変化の後、古い認証秘密鍵は、トランザクション入力の署名に使用され、新たな認証鍵は、トランザクション全体の署名(即ち、全てのトランザクションのデータ)に使用される。
好ましくは、有効クレデンシャルを中央認証サーバの1つに提出して生成されなかったあらゆる通貨アドレスが無効であり、どのようなコインも受け取ることができない。
好ましくは、トランザクションネットワークは、中央認証サーバの1つに格納された中央トランザクション基準に準拠しないあらゆるトランザクションを拒否するように変形できる。
好ましくは、有効登録ユーザは、自身のトランザクションを制限するためのクライアントトランザクション基準を策定できる。
好ましくは、中央運営団体が、マネーロンダリング等の不正行為に関与する可能性の高い疑わしいトランザクションを停止するため、トランザクション基準を策定できる。
好ましくは、各トランザクションは、マネーロンダリング等の不正行為に関与する可能性のある疑わしいトランザクションを特定、記録、報告する、所定の規則により監視できる。
好ましくは、各通貨アドレスの所有者の法的身分が、クライアント情報データベースに格納される。不正行為の疑いがあるトランザクションについては、送り主及び受取先の通貨アドレスの追跡により、関連する送り主及び受取先の身元がクライアント情報データベース抽出される。その後、疑わしい活動及び関連するクライアント情報が、関連する国の法律、規則に応じて、政府機関に報告される。
好ましくは、各通貨アドレスの所有者の法的身分が、クライアント情報データベースに格納される。これにより、「顧客確認」規制要件が満たされる。システムが商業活動における支払システムとして利用可能となる。
好ましくは、各通貨アドレスの所有者の法的身分が、クライアント情報データベースに格納される。但し、当該情報は誰にでもアクセスできるものではないため、暗号型電子マネー及びそのトランザクションネットワークの匿名性が保たれる。
好ましくは、自身のクレデンシャルを変更して、自身の通貨ウォレット(301)の盗まれたメインデータファイル(例えばwallet.dat.file)からの、コインの出金を止めることができる。好ましくは、(i)各通貨アドレスの所有者の法的身分が、クライアント情報データベースに格納され、(ii)有効クレデンシャルを中央認証サーバの1つに提出して生成されなかったあらゆる通貨アドレス無効であり、どのようなコインも受け取ることができない。有効登録ユーザのみが有効クレデンシャル(112)を有する。コインが盗まれると、1以上の受取先の1以上の通貨アドレスに応じて、クライアント情報データベースから1以上の受取先の1以上の法的身分を読み出すことで、容易にコインを盗んだ1以上の窃盗犯又は1以上のハッカーを追跡できる。このように、この形態のシステムは、暗号通貨の盗難を防止する。
有効登録ユーザが所有するコインの金額は、トランザクションデータベース内のトランザクション記録を分析することで、中央運営団体により完全かつ容易に捜索、追跡可能である。各通貨アドレスをその所有者に結び付ける機能とは別に設けられたこの固有の特性は、コインが送金/支払われた直後の通貨アドレスにおける未使用分のコイン(全額使用されていない場合)を記録することに基づく。この固有の特性により、このシステムが、特に第三者により監査を要する金融及び銀行業務に適用可能となっている。
好ましくは、システムはユーザのプライバシーを守りながら、暗号通貨盗難、KYC、AMLに関する問題に対する実践的ソリューションを提供する。
好ましくは、中央銀行又はその他金融機関がシステムを利用、修正して、分散型台帳支払システムに対応し、且つ中央運営団体により規制され得る独自のデジタル通貨を発行可能とする。
本明細書に記載の、上記及びその他本発明の目的は、個人/クライアント認証及び検証システム及び方法を適用することで達成される。本発明の更なる詳細及び特徴、その特性更に各種利点が、以下の図に示される好ましい実施形態の詳細な説明により、明らかになろう。
表記法及び用語
以下の詳細な説明は、コンピュータメモリで実行可能なデータビットに対する動作の、データ処理手順、ステップ、又はその他象徴的表象で表される。したがって、コンピュータは、物理量の物理的操作を要する論理ステップを実行する。
以下の詳細な説明は、コンピュータメモリで実行可能なデータビットに対する動作の、データ処理手順、ステップ、又はその他象徴的表象で表される。したがって、コンピュータは、物理量の物理的操作を要する論理ステップを実行する。
通常、当該物理量は、コンピュータシステムにおいて記憶、転送、結合、比較、又はその他操作が可能な、電気又は磁気信号の形態をとる。一般的な使用のために、これらの信号はビット、パケット、メッセージ、値、要素、記号、文字、用語、数字等と称される。
更に、これらの用語及び類似の用語は適切な物理量と関連付けられ、これらの量に適用される便宜上の標示に過ぎない。「処理する」、「作成する」、「転送する」、「実行する」、「判定する」、「検出する」、「取得する」、「選択する」、「計算する」、「生成する」等の用語は、コンピュータのレジスタ及びメモリ内の物理的(電子的)量として表現されているデータを操作し、当該メモリ、レジスタ、又はその他の同様の情報記憶部内の物理量と同様に表現されている別のデータへと変換するコンピュータシステムの動作及び処理を指す。
本明細書で言及するようなコンピュータ可読(記憶)媒体は、通常、非一時的であり、更に/又は非一時的装置を備える。これに関連して、非一時的ストレージ媒体は有形であり得る装置を備えてもよく、即ち、当該装置はその物理的状態が変化することはあるものの、具体的な物理形態を有する。このように、例えば、非一時的とは、装置の状態変化があっても有形であり続けることを指す。
本明細書において使用される「例」という語は、限定的ではない例、実例、例示を表すことを意味する。本明細書において使用される、「例えば」、「等」という語は、1又は複数の限定的ではない例、実例、例示のリストを導入する。
本発明は、オルトコイン等の暗号型電子マネー(CBEM)及びトランザクションシステムの技術分野に関する。より具体的には、本発明は、新たなCBEMを作成する方法とシステム、及びそれに関連する、CBEMの匿名性を維持した上で、全ての金銭トランザクションに関わる送り主及び受取先の法的身分を開示可能とする支払システムに関する。
本発明は、全てのトランザクションを監視し、不正行為に関わり得るものを特定し、トランザクションを規制又は限定するための、中央運営団体又はCBEMユーザにより定義された基準を含めるための、更なるモジュールの追加を可能とする。
これにより、本発明は、ユーザのプライバシーを守りながら、暗号通貨盗難、KYC、AMLに関する問題に対する実践的ソリューションを提供する。更に、中央銀行又はその他金融機関が本発明を利用、修正して、分散型台帳支払システムに対応し、且つ中央運営団体により規制され得る独自のデジタル通貨を発行可能とする。
このため、本発明は、3つの主要処理を統合する。即ち、(i)法的個人認証、(ii)クレデンシャル認証、(iii)2団体署名方式である。本発明の実施形態は、CBEMを作成する方法とシステム、及びそれに関連する、CBEMの匿名性を維持した上で、全ての金銭トランザクションに関わる送り主及び受取先の法的身分を中央運営団体に開示可能とする支払システムに関する。
本発明のクレデンシャル認証機構は、ユーザがクレデンシャルを変更可能とすることで、盗まれたウォレットからのコインの転送を止めることを可能とする。最後に、非常に重要な点であるが、全てのトランザクションにおける送り主と受取先とを開示できるので、クライアント情報データベースから、1以上の受取先の1以上の法的身分を読み出すことで、容易にコインを盗んだ1以上の窃盗犯又は1以上のハッカーを追跡できる。これにより、本発明の実施形態は、CBEMコインの窃盗を防止できる。
CBEMの全てのトランザクションにおける送り主と受取先の法的身分を明らかにできるようにするためには、以下の2つの主要要素が必要となる。
1.CBEMの全ての受取先及び送り主の法的身分
2.匿名の人物によるCBEMコインの受取、送金禁止
これら2つの主要要素は、単純に認証済みの法的身分を有する登録ユーザのみにCBEMを送金、受取可能とすることで実現できる。法的身分の取得検証のために、各登録者が自身の法的身分を提出証明するためのウェブ登録インタフェースが生成されて、法的身分が認証された人物のみが、有効ユーザと認められる。その後、登録されたものはCBEMを受信、送信できるようになる。但し、どのようにして匿名の人物によるCBEM、特にオープンソースCBEMのコインを受け取り、送金を禁止するかに主要な課題がある。
1.CBEMの全ての受取先及び送り主の法的身分
2.匿名の人物によるCBEMコインの受取、送金禁止
これら2つの主要要素は、単純に認証済みの法的身分を有する登録ユーザのみにCBEMを送金、受取可能とすることで実現できる。法的身分の取得検証のために、各登録者が自身の法的身分を提出証明するためのウェブ登録インタフェースが生成されて、法的身分が認証された人物のみが、有効ユーザと認められる。その後、登録されたものはCBEMを受信、送信できるようになる。但し、どのようにして匿名の人物によるCBEM、特にオープンソースCBEMのコインを受け取り、送金を禁止するかに主要な課題がある。
CBEM(暗号型電子マネー)は、物理通貨と同様な特性を持ちながら、即時トランザクション、暗号化による安全性、所有権のデジタル又は仮想的な移転を可能とする任意の種類のデジタル通貨であってもよい。CBEMの例としては、仮想通貨、暗号通貨、暗号証券(例えば、任意の電子的/デジタル証券又は証券に紐付けされたトークン)、又は中央銀行発行の「デジタル型マネー」であってもよい。CBEMは、更にあらゆる形態の電子的/デジタルトークン(例えば、会社の株式の所有権の証明となる証書又は契約を示すもの、株式投資の証明、事業に対する利益分配権の証明、又は特許のロイヤリティ分配権の証明等)、あらゆる形態のPoEに対する電子的/デジタル証書(例えば、権利付与の証明)、及び任意のその他の好適なデジタル又は仮想的な交換媒体を含むことができる。CBEMにおいて、装置及びメッセージの認証、不正な観察や改竄からのデータ保護のため、暗号がよく使用される。CBEMの例としては、ビットコイン、Ether、リップル、ライトコイン、ダッシュ、又はその他適切な暗号通貨が挙げられる。
あらゆる種類のCBEMトランザクションが、分散型ストレージ、分散型台帳、ブロックチェーン、又はその他適切な分散型トランザクション機構を含む分散型ネットワークに格納可能である。分散型ストレージは、ネットワーク上の1又は複数のノードに格納されたファイル又はファイルセグメントを含んでもよい。分散型ストレージは特定のフォーマット又はプロトコルに限定されるものではなく、サーバ、デスクトップPC、携帯装置、リムーバブルストレージ、又はその他適切な装置を含む、任意のアクセス可能ネットワークノードに格納された、任意の種類のファイルを含んでもよい。一実施形態において、1ファイルの全体が単一のノードに格納され、別のファイルが別のネットワークノードに格納されてもよい。或いは、単一のファイルを複数のセグメントに分けて、1又は複数のネットワークノードに格納してもよい。
ビットコイン等のCBEMは、分散型決済システムとして設計される。そのコンピュータプログラミングコードは、オープンソースオンラインコミュニティにおいて、誰にでも精査可能であることが想定される。オープンソースのCBEMであれば、ソースコードを利用して、誰にでも自分の通貨アドレスを作成し、コインを送金、受取可能である。したがって、KYC登録手法は特定のサービスプロバイダにのみ適用可能で、あらゆる通貨利用者に適用されるわけではない。
分散型台帳は、1又は複数の分散型ネットワーク全体で共有、同期されるデータベース又はデータベースの複製であってもよい。分散型台帳により、トランザクションが全体又は一部に公開されたり、複製されたりが可能であるので、サイバー攻撃を受けにくい。更に、分散型台帳は、信用が低い環境(即ち、共有データベースをホストする参加者がそれぞれ独立して役割を担い、互いに信用していない状況)でも、共有事実の存在や状態についての合意を維持可能である。合意とは、分散型台帳に特有のものではない。別の分散型データベースでも、Paxos又はRaft等の合意アルゴリズムが利用されている。改竄不能という点についても同様である。分散型台帳以外で使用されるデータベース(Google HDFS,Zebra,CouchDB,Datomic等)にも改竄可能なものが存在するのである。
分散型台帳は、通常の分散型データベースと、以下の点で異なる。(a)リード/ライトアクセスが完全に分散化している。ほかの分散型データベースの場合、理論上、集中している。そのため、(b)信頼できる第三者が不在の、困難な環境でも、トランザクションを保護できる。分散型台帳は、ブロックチェーンのように線形な構造を有することができる。或いは、IOTAのTangleのようにDAG(有向非巡回グラフ)を含むことできる。ブロックチェーン、IOTAのTangle、HederaのHashgraphは、所定のフォーマット及びアクセスプロトコルを有する分散型台帳の具体例である。
ブロックチェーンは、CBEMトランザクションを経時的に格納する分散型台帳である。ブロックチェーン台帳の場合、全てのCBEMトランザクションは、定期的に「ブロック」で検証、格納される。ブロックは暗号ハッシュを介して前ブロックにリンクしている。ブロックチェーン台帳は、確認可能となるように公開されているため、CBEMトランザクションは誰にでも視認、追跡可能である。各ネットワークノードは、ブロックチェーンのコピーを受信、保持可能である。
登録ユーザにのみコインの使用を限定するために、登録されていない匿名ユーザにより生成された通貨アドレス(即ち、無効な通貨アドレス)を、登録された非匿名ユーザにより生成されたもの(即ち、有効な通貨アドレス)から区別する、新たな方法が開発されている。更に、コインの送金、受取に、有効通貨アドレスのみを使用可能とする別の方法も開発されている。
本発明は、これら2つの課題に対して実践的ソリューションを提供する。そのために、以下の3つの主要な処理を統合する。(i)法的個人認証、(ii)クレデンシャル認証、(iii)2団体署名方式。統合のためには、以下の技術的修正が必要となる。
1.ビットコインの多署名トランザクションプロトコルを修正
2.修正したものをクライアント情報データベースにリンク付け
3.強制的に、修正したものをトランザクションプロトコルとする
4.強制的に、トランザクション署名を中央認証サーバの1つからの秘密鍵とする
1.ビットコインの多署名トランザクションプロトコルを修正
2.修正したものをクライアント情報データベースにリンク付け
3.強制的に、修正したものをトランザクションプロトコルとする
4.強制的に、トランザクション署名を中央認証サーバの1つからの秘密鍵とする
本発明の実施形態は、以下の主要なステップで実現され得る。
ステップ1:ユーザの法的身分を取得、検証、保存し、ユーザ固有のクレデンシャルを生成するためのコンピュータサーバ及びウェブベースインタフェースを構築
ステップ2:ウェブベースインタフェースを利用して、通貨アドレス生成処理を限定するためのクレデンシャルを生成
ステップ3:多署名手法により、コインの送金、受取を実行
ステップ4:特定の規則で規制されたpay−to−script−hashトランザクションを実行
ステップ1:ユーザの法的身分を取得、検証、保存し、ユーザ固有のクレデンシャルを生成するためのコンピュータサーバ及びウェブベースインタフェースを構築
ステップ2:ウェブベースインタフェースを利用して、通貨アドレス生成処理を限定するためのクレデンシャルを生成
ステップ3:多署名手法により、コインの送金、受取を実行
ステップ4:特定の規則で規制されたpay−to−script−hashトランザクションを実行
上述のステップを、以下により詳細に説明する。
ステップ1:ユーザの法的身分を取得、検証、保存し、ユーザ固有のクレデンシャルを生成するためのコンピュータサーバ及びウェブベースインタフェースを構築
コンピュータサーバ及びウェブベースインタフェース(例えば、BGCwallet.com)を構築するステップは、CBEM(例えば、Atenコイン)のユーザに関する。登録処理では、個人は当人の法的身分についての文書/情報(例えば、パスワードID番号及び、本人のパスポートの身分証ページ)を提供し、その法的身分(例えば、MiiCard又はIDcheckerによる身分承認サービス)を認証する処理が行われる。登録には、その法的身分が適切に認証される必要がある。提供された情報は全て、クライアント情報データベースに格納される。
ステップ1:ユーザの法的身分を取得、検証、保存し、ユーザ固有のクレデンシャルを生成するためのコンピュータサーバ及びウェブベースインタフェースを構築
コンピュータサーバ及びウェブベースインタフェース(例えば、BGCwallet.com)を構築するステップは、CBEM(例えば、Atenコイン)のユーザに関する。登録処理では、個人は当人の法的身分についての文書/情報(例えば、パスワードID番号及び、本人のパスポートの身分証ページ)を提供し、その法的身分(例えば、MiiCard又はIDcheckerによる身分承認サービス)を認証する処理が行われる。登録には、その法的身分が適切に認証される必要がある。提供された情報は全て、クライアント情報データベースに格納される。
図1は、暗号型電子マネーの新規ユーザの法的身分を取得、検証、記憶するための、登録及びデータベースシステムを示す。
少なくとも1つのウェブ登録インタフェース(102)を有する少なくとも1つのサーバは、以下の機能を実行する。最初に、ステップ(105)において、ウェブ登録インタフェース(102)を介して、登録者の法的身分を証明する文書の提出が要求される。次に、ステップ(106)において、登録者の法的身分の認証が行われる。認証失敗の場合、登録失敗(107)となる。
一方、認証された登録者(109)は、その登録ユーザアカウントを不正アクセスと、悪意ある攻撃から守るため、二要素認証又は多要素認証(104)を利用可能となる。
二要素認証は、オンラインユーザアカウント(104)を、安全に保護する方法である。具体的には、ユーザは自身のオンラインアカウントにログインする際に、2つの異なる要素により、本人確認を行うことが求められる。第1認証要素は、ユーザにより生成されたログイン名及びログインパスワードの組である。第2認証要素は、携帯電話又は個人用安全キー生成器等の、ユーザが所有する物理的デバイスに結び付けられた、定期的に変更されるトークン(例えば、固有の7桁コード)である。これにより、オンラインユーザアカウントは、個人の物理的デバイスが盗まれない限り、ハッキングされることはない。ユーザが自身のオンラインアカウントにログインする際に、3つ以上の異なる要素(例えば、ログイン名とログインパスワードの組、携帯電話及びスマートIDカード)が要求されるようにして、多要素認証とすることも可能である。
認証された登録者(109)は、ラベルとパスワードを含むクレデンシャル(111)を生成する(112)ことが求められる。当然、認証された登録者(109)は、クレデンシャル及び連絡先情報(113)を変更できる。これらは、ステップ(114)にて暗号化されることが好ましい。クレデンシャルは、ユーザが自身の1以上の多署名ウォレットアドレス(図2)を生成するために必要なものである。当該アドレスは、コイン(例えばAtenコイン)を受け取り、トランザクション(図3)を実行するために必要である。
任意で、ステップ502において、有効登録ユーザは、自身のトランザクションを制限するためのクライアントトランザクション基準を策定できる。例えば、ユーザは24時間以内に自身の1以上の通貨アドレスから送られるコインの最高金額を制限する基準を設定できる。これにより、通貨ウォレットが盗まれたり、ハッキングされたりした場合にも、損失を最小限にとどめることができる。
上記までの処理が完了すると、ステップ(116)において、全ての提出された情報、特に法的身分及び暗号化クレデンシャルがクライアント情報データベース(115)に格納される。
最後に、ステップ117において、新たに作成された又は変更された暗号化クレデンシャルが中央認証サーバ(401)に送られる。中央認証サーバは、個別の登録者毎に1以上の多署名通貨アドレス、クレデンシャル、法的身分のマッピング(118)及び記憶を実行する。例えば、多署名通貨アドレスは、数字、大文字小文字のアルファベットを含む34桁の文字列である(例えば、Aj8xFozUjo3GoNvi95kABpTjO2qQReZo5P)。個人IDは、(i)ユーザのマイナンバーカード又はパスワードに印字された法律上の名前(フルネーム)、(ii)マイナンバーカード/パスワードに記載の番号、(iii)誕生日を含む。
ステップ2:ウェブベースインタフェースを使用して、通貨アドレス生成処理を規制するためにクレデンシャルを生成
有効登録ユーザ(106、109)のみが、コイン(例えば、Atenコイン)を送金、受取用の(図3に示す)、自身の1以上の多署名アドレス(図2に示す)の生成に要されるクレデンシャル(図1、112)を、ウェブベースインタフェースを使用して生成できる(111)。クレデンシャルを用いることで、未登録の匿名ユーザが、システム内でコインを授受するための有効多署名アドレスを生成することを不可能にできる。言い換えると、CBEMのコインの送金、受取のための全ての有効通貨アドレスは、公知の法的身分を有する実際の人物に結び付けられる。
有効登録ユーザ(106、109)のみが、コイン(例えば、Atenコイン)を送金、受取用の(図3に示す)、自身の1以上の多署名アドレス(図2に示す)の生成に要されるクレデンシャル(図1、112)を、ウェブベースインタフェースを使用して生成できる(111)。クレデンシャルを用いることで、未登録の匿名ユーザが、システム内でコインを授受するための有効多署名アドレスを生成することを不可能にできる。言い換えると、CBEMのコインの送金、受取のための全ての有効通貨アドレスは、公知の法的身分を有する実際の人物に結び付けられる。
ステップ3:多署名手法により、コインの送金、受取を実行
コインの授受のための有効多署名アドレスを生成するには(図2)、1つの中央認証サーバからの1つの認証公開鍵と、少なくとも1つのクライアント公開鍵が必要である。コインを受け取るためのアドレスを生成するためにクライアントウォレット(301)が使用可能となる前に、クライアントウォレットに対してクレデンシャル(111)を入力する必要がある。アドレス生成処理において、クライアントウォレットは先ず、クレデンシャルを電子/デジタルデータ送信ネットワーク(例えば、インターネット)を介して、中央認証サーバ(401)の1つに送信して、検証(407)が行われる。
コインの授受のための有効多署名アドレスを生成するには(図2)、1つの中央認証サーバからの1つの認証公開鍵と、少なくとも1つのクライアント公開鍵が必要である。コインを受け取るためのアドレスを生成するためにクライアントウォレット(301)が使用可能となる前に、クライアントウォレットに対してクレデンシャル(111)を入力する必要がある。アドレス生成処理において、クライアントウォレットは先ず、クレデンシャルを電子/デジタルデータ送信ネットワーク(例えば、インターネット)を介して、中央認証サーバ(401)の1つに送信して、検証(407)が行われる。
クレデンシャルが有効であると確認されれば、即ち、中央認証サーバ(319、401、407)のデータベースにおける有効かつアクティブなクレデンシャルに一致すれば、中央認証サーバは認証公開鍵(408)を、電子/デジタルデータ送信ネットワークを介してクライアントウォレットに提供する。クレデンシャルが無効又は非アクティブである場合、中央認証サーバはクライアントウォレットに失敗メッセージを返す。認証公開鍵を受信すると、クライアントウォレットは多署名アドレス生成処理に進む(315)。
失敗メッセージを受信すると、クライアントウォレットは多署名アドレス生成処理を行わない。認証公開鍵があれば、クライアントウォレットはクライアント公開鍵(307)と秘密鍵(308)の組を生成(309)し、これをクライアントウォレットに格納する(310)。その後、認証公開鍵(405)とクライアント公開鍵(307)を組み合わせて、多署名アドレス(315)を生成する。このように生成された多署名アドレス(315)は、当然認証秘密鍵とクライアント秘密鍵に深く関連する。多署名アドレスは、クライアントウォレット(316)に格納、表示される。ユーザは、多署名アドレスを利用してCBEMコイン(例えばAtenコイン)を受け取ることができる。
各多署名アドレスに認証公開鍵が存在することは、あらゆるトランザクションが有効となるには1つの中央認証サーバからの認証署名(即ち、認証秘密鍵(406))と、クライアント署名(即ち、クライアント秘密鍵(308))が必要であることを示すものである。
この制御システムを利用すれば、有効登録ユーザのみが多署名アドレスを生成できる。該アドレスを使用して、1つの中央認証サーバからのカウンターサインが必要なトランザクションを実行できる。
図2は、暗号型電子マネーを授受するための多署名通貨アドレスを生成するための、法的身分関連クレデンシャル認証システムを示す。
処理における最初のステップ(301)において、好ましくはソフトウェアによりアクセス可能なネットワーク資源であるクライアントウォレットが提供される。次に、ステップ(111)からの入力ユーザクレデンシャルを適用して、クライアントウォレットをアクティブにする。次に、ステップ(314)において、ユーザは通貨アドレスの生成を試みるが、システムは、多署名アドレスである通貨アドレスのみを生成する。
次に、ステップ(319)において、1以上の有効通貨多署名アドレスを生成するための承認を得るため、有効登録ユーザがクレデンシャルを中央認証サーバ(401)の1つに提出する。
承認が得られない場合、適切なエラーメッセージが生成されてもよい。一方、承認された場合、ステップ(309)において、コインの送金、受け取りのため、暗号化クライアント公開鍵(307)及びクライアント秘密鍵(308)の組が、1つ以上生成される。これらクライアント公開鍵及びクライアント秘密鍵は、クライアントウォレット(310)に格納され関連付けられる。更に、承認された場合、ステップ408において、認証秘密鍵(406)に数学的にリンクされた認証公開鍵(405)が、中央認証サーバからクライアントウォレットに提供される。
更に、ステップ(315)において、1以上のクライアント公開鍵(307)からの1以上の多署名アドレスと、1以上の認証公開鍵(405)が生成される。生成された多署名通貨アドレスは、クライアントウォレットに格納され、関連付けられる(316)。
次に、ステップ(317)において、1以上の多署名アドレスが、クライアント情報データベース(115)に送信され、1以上のアドレスの所有者の法的身分にマッピングされて、格納される(118)。
ステップ4:特定の規則で規制されたpay−to−script−hashトランザクションを実行
ビットコインのデベロッパーにより、現在までに、2つの異なるビットコイントランザクションの作成及び承認方法が開発されている。具体的には、2つの方法は、それぞれ異なるscriptSig/scriptPubKey組を使用する、pay−to−pubkey−hashと、pay−to−script−hashである。
ビットコインのデベロッパーにより、現在までに、2つの異なるビットコイントランザクションの作成及び承認方法が開発されている。具体的には、2つの方法は、それぞれ異なるscriptSig/scriptPubKey組を使用する、pay−to−pubkey−hashと、pay−to−script−hashである。
pay−to−pubkey−hashは、通常のビットコイントランザクションにおいて、最も一般的に利用されている方法である。pay−to−pubkey−hashトランザクションでは、ビットコインアドレスは、公開/秘密(ECDSA)楕円曲線デジタル署名アルゴリズム鍵組の公開部分における、160ビットハッシュ値である。ビットコイン送り主は、ビットコインアドレスをscriptPubKeyに設ける。pay−to−pubkey−hashトランザクションの場合、送り主は、ビットコインを公開鍵の所有者に直接送金する。
pay−to−pubkey−hashトランザクションを始めるには、送り主はビットコインが格納された公開鍵を、対応するビットコインアドレス及び対応する署名(即ち、秘密鍵組)と、ビットコインを受け取るためのビットコインアドレスに提供する必要がある。受取用ビットコインアドレスは、対応する公開鍵及び署名に直接リンクされている。ビットコインアドレスに送られたコインを換金する際、受取人は、署名と公開鍵の両方を提供する。スクリプトは、提供された公開鍵がscriptPubKey内のハッシュに対してハッシュしていることを確認してから、署名を公開鍵と照合する。
pay−to−scriptのトランザクションに関連するアドレスは、公開鍵ハッシュではなく、スクリプトのハッシュである。ビットコインをpay−to−script−hashで支払うには、スクリプトのハッシュに一致するスクリプトと、スクリプトを真と評価するデータを提供する処理が必要である。言い換えれば、対象のスクリプトが受け入れられる入力(即ち、回答)を提供すれば、トランザクションが進む。入力が無効で、スクリプトが受け入れられなければ、トランザクションは停止する。
pay−to−script−hashを使用すると、セキュリティ設定の詳細を一切把握していなくとも、様々な独特な方法で保護されているアドレスにビットコインを送信可能である。例えば、受取人が特定のビットコインアドレスに格納されたビットコインを受け取るためには複数人の署名を必要となるか、パスワードが必要となる。或いは、要件は完全に独自のものである可能性もある。ビットコイン及びビットコイン技術を基に開発された現状利用可能なあらゆる暗号通貨に関して、pay−to−script−hashは強制されるものではない。
pay−to−pubkey−hashは、ビットコイントランザクション及びビットコイン技術を基に開発された現状利用可能なあらゆる暗号通貨トランザクションにおいて、一般的な方式である。pay−to−pubkey−hash機能が、暗号通貨のクライアントウォレットソフトウェアに組み込まれている。暗号通貨所有者は、クライアントウォレットソフトウェアを使用して、トランザクションにpay−to−pubkey−hashとpay−to−script−hashのいずれを利用するかを選択できる。
本発明では、CBEMトランザクションネットワークにおいて、pay−to−script−hashトランザクションのみが許可される。この制限は、ビットコイン及びビットコイン技術を基に開発された現状利用可能なあらゆる暗号通貨とは対照的に、クライアントウォレットソフトウェアのソースコード内のみではなく、CBEMのソースコード内で実現される。これにより、CBEMデベロッパーは、あらゆるトランザクションに対して、特定の規則を適用でき、したがって、あらゆるトランザクションの制御に、法的身分関連クレデンシャル認証システムを実現できる。法的身分関連クレデンシャル認証システムでは、CBEMの送受信に、特定ユーザクレデンシャル及び多署名アドレスが使用される。
法的身分関連クレデンシャル認証システムでは、pay−to−script−hashトランザクションにおいて、CBEMの送受信に多署名アドレスのみが使用される。各クライアント多署名アドレスは、クライアント公開鍵(クライアントウォレットから生成)(307)を含むスクリプトと、トランザクションの生成、署名用の認証公開鍵(中央認証サーバの1つが生成)(405)に結び付けられている。したがって、全てのpay−to−script−hashトランザクションは、トランザクションを有効とするために、少なくともクライアント秘密鍵(308)と認証秘密鍵(406)とを必要とする。
pay−to−script−hashトランザクション用のスクリプトは、クライアントウォレット内のみではなく、CBEMのソースコード内で実現される。したがって、スクリプトにより、あらゆるトランザクションを開始及び署名するための、1以上の中央認証サーバからの1以上の認証秘密鍵(406)の要件が実施できる。中央認証サーバを介して認証秘密鍵の提供が規制できるため、中央認証サーバによる要件、規制、及び/又は規則に従わずにpay−to−pubkey−hash又はpay−to−script−hashトランザクションを行うことは不可能となる。
図3は、法的身分関連クレデンシャル認証システムと、ユーザが所有し、多署名アドレスに記録されたコインの金額での支払いトランザクションを行うための2団体署名方式を示す。
Pay−to−script−hashトランザクション(218)を行う際、クライアントウォレット(301)は、その許可を得るため、少なくとも1つの中央認証サーバ(401)からの署名(即ち認証秘密鍵)(406)が必要となる。トランザクションの要求は、中央認証サーバに対するAPIコールで送られ、認証が行われる(220)。認証が失敗すると、適切なエラーメッセージが生成されてもよい。
クライアントウォレットから中央認証サーバ(401)に送られたクレデンシャルが有効で(220、409)、要求されたトランザクションが所定の基準(501、502)に基づいて、疑わしいものではないと判断されれば、クライアントウォレット(即ちクライアント秘密鍵)(308)からの署名と、中央認証サーバの1つからの署名(即ち認証秘密鍵(406、411))が得られ、トランザクションが承認される(410、412)。
pay−to−script―hashのスクリプトは、複数の公開鍵及び/又は認証秘密鍵が必要となるように、変更できる。この場合、支払いトランザクションが実行されるには、1以上のクライアント(送り主、受取先のいずれか)及び/又は1以上の承認機関からの署名が必要となる。更に安全性を高めるために、トランザクション入力(410)と、トランザクション全体(412)の署名に、2つの異なる認証秘密鍵を使用してもよい。
本発明では、あらゆるトランザクションが行われるために、署名として、中央認証サーバからの少なくとも1つの認証秘密鍵が必要となる。認証秘密鍵が提供されるには、送り主からの有効クレデンシャルが認証される必要がある。有効クレデンシャルは全て個別のクライアントウォレットアドレスに結び付けられ、法的身分が認証されてクライアント情報データベース(図2)に格納された登録ユーザにより所有されている。そのため、法的身分がデータベースに格納された登録ユーザのみが、有効クレデンシャルを提出して、自身のウォレットアドレスから、別のウォレットアドレスへとコインを送金できるのである。
CBEM送り主又は受取先の法的身分の開示が必要である場合、クレデンシャルにより中央認証サーバを所有する中央運営団体とクライアント情報データベースとが結び付けられる。法的身分の情報は、pay−to−script−hashトランザクションの処理全体では必要ではないため、送り主と受取先の匿名性は保たれる。
中央認証サーバは、少なくとも1つの中央認証サーバ(401)に格納された中央トランザクション基準(501)に準拠しないあらゆるトランザクションを拒絶できる。具体的には、各トランザクションは、マネーロンダリング等の不正行為に関与する可能性のある疑わしいトランザクションを特定、記録、報告する、所定の規則により監視できる。あらゆる疑わしいトランザクションと、それに関わる送り主及び受取先の身元は、関連する政府機関に報告され、対処される。したがって、本発明は、ビットコインやその他各種通貨の、現在のKYC/AML非準拠の問題に対処する、実践的ソリューションを提供するものである。
任意で、ステップ502において、有効登録ユーザは、自身のトランザクションを制限するためのクライアントトランザクション基準を策定できる。例えば、ユーザは24時間以内に自身の1以上の通貨アドレスから送られるコインの最高金額を制限する基準を設定できる。これにより、通貨ウォレットが盗まれたり、ハッキングされたりした場合にも、損失を最小限にとどめることができる。
その後、トランザクションは確認(305)用にノード(214)のネットワークにブロードキャストされる。生成されたトランザクションは、正式なものになる前に、トランザクションネットワークに送られて処理され、ブロックチェーンのブロックに含まれる必要がある。ノードは、ブロック内の全てのトランザクションが有効(即ち、正しく署名)であり、CBEMがまだ支払われていない場合にのみ、ブロックを受け入れる。ノードが当該ブロックのハッシュを、前ハッシュとして、次のブロックをチェーンに作成することで、そのブロックを受け入れたことが示される。
新たに生成されたブロックでトランザクションを実行する処理を、トランザクション確認と呼ぶ。1つのブロックに取り込まれることを、1つの確認とする。確認の数が、所定数(例えば、ビットコインの場合には6、Atenコインの場合は10)以上となれば、トランザクションが確認済みとなる。ビットコイン技術において、この機能は、システムで同じコインを再使用すること(即ちダブルスペンディング)を防止するために導入されている。
図1から図3に示す構成特有の機能は以下のとおりである。
・有効通貨アドレスとして、多署名アドレス(313)のみの生成(314)を許可する。
・コインを送る場合、受け取る場合の両方で、多署名アドレス(313)を使用するトランザクションのみの生成を許可する(321)。
・pay−to−script−hash形式(218)又はその他対応する形式でのトランザクションのみの生成(311)を許可する。
・署名として少なくとも2の秘密鍵を必要とするトランザクションのみの生成を許可する(308、406)。
・これら秘密鍵(308、406)の内の1つを、中央認証サーバ(401)の1つからの認証秘密鍵(406)に限定する。
・残りの秘密鍵(308、406)を、暗号化されて1以上のクライアントウォレット(301)に格納されるクライアント秘密鍵(308)に限定する。
・有効登録ユーザ(109)のみが有効クレデンシャル(111)を生成可能とする(112)。
・有効クレデンシャル(111)を有するユーザのみが、当該クレデンシャル(111)を提出し、中央認証サーバ(401)の1つを介して認証されることで、コインを受け取るため、1又は複数の有効多署名通貨アドレス(313)を生成可能とする(319,407)。
・有効クレデンシャル(111)と、1又は複数の有効多署名通貨アドレス(313)、対応するクライアント秘密鍵(308,309)を有するユーザのみが、1以上の有効トランザクションを生成可能とする(220、320、409)。
・提出されたクレデンシャル(111)を、中央認証サーバ(401)の1つを介して検証(220、320、409)することで、1又は複数のトランザクション(410、412)を署名するために1又は複数の認証秘密鍵(406、411)を中央認証サーバ(401)の1つから受信可能であるのを、有効クレデンシャル(111)を有するユーザに限定する。
・提出されたクレデンシャル(111)を、中央認証サーバ(401)の1つを介して検証(220、320、409)することで、有効トランザクションを生成するために中央認証サーバ(401)の1つから1又は複数の認証秘密鍵(406、411)を受信可能であるのを、有効クレデンシャル(111)を有するユーザのみに限定する。したがって、有効トランザクションを生成するのを、有効クレデンシャル(111)を有するユーザのみに限定する。
・各クレデンシャル(111、112、113、114)を、ユーザの法的身分(105)に結び付ける(図1)。
・各クレデンシャル(図1、111)を使用して、対応する所有者の法的身分(105)を追跡する(116)。
・各多署名アドレス(313、314)をユーザのクレデンシャル(111)に結び付ける(図2)。
・各多署名アドレス(313)を使用して、所有者に対応するクレデンシャル(111)を追跡する(118)(図2)ことで、クレデンシャル(111)により、所有者の法的身分(105)を追跡(116)する(図1)。
・各トランザクションを使用して、送り主と受取先の多署名アドレス(313)を追跡し(図3)、更に多署名アドレス(313)を使用して送り主と受取先のクレデンシャル(111)を追跡(118)し(図2)、最後にクレデンシャル(図1、111)を使用して送り主と受取先の法的身分(105)を追跡する(116)。
・有効クレデンシャル(111)を有するユーザのみが有効多署名アドレス(図2)を作成して、有効トランザクションを作成できることから、全ての有効トランザクションにおける送り主(図1、105)と受取先の法的身分を追跡、捜索(116)可能(図3)とする。
・有効通貨アドレスとして、多署名アドレス(313)のみの生成(314)を許可する。
・コインを送る場合、受け取る場合の両方で、多署名アドレス(313)を使用するトランザクションのみの生成を許可する(321)。
・pay−to−script−hash形式(218)又はその他対応する形式でのトランザクションのみの生成(311)を許可する。
・署名として少なくとも2の秘密鍵を必要とするトランザクションのみの生成を許可する(308、406)。
・これら秘密鍵(308、406)の内の1つを、中央認証サーバ(401)の1つからの認証秘密鍵(406)に限定する。
・残りの秘密鍵(308、406)を、暗号化されて1以上のクライアントウォレット(301)に格納されるクライアント秘密鍵(308)に限定する。
・有効登録ユーザ(109)のみが有効クレデンシャル(111)を生成可能とする(112)。
・有効クレデンシャル(111)を有するユーザのみが、当該クレデンシャル(111)を提出し、中央認証サーバ(401)の1つを介して認証されることで、コインを受け取るため、1又は複数の有効多署名通貨アドレス(313)を生成可能とする(319,407)。
・有効クレデンシャル(111)と、1又は複数の有効多署名通貨アドレス(313)、対応するクライアント秘密鍵(308,309)を有するユーザのみが、1以上の有効トランザクションを生成可能とする(220、320、409)。
・提出されたクレデンシャル(111)を、中央認証サーバ(401)の1つを介して検証(220、320、409)することで、1又は複数のトランザクション(410、412)を署名するために1又は複数の認証秘密鍵(406、411)を中央認証サーバ(401)の1つから受信可能であるのを、有効クレデンシャル(111)を有するユーザに限定する。
・提出されたクレデンシャル(111)を、中央認証サーバ(401)の1つを介して検証(220、320、409)することで、有効トランザクションを生成するために中央認証サーバ(401)の1つから1又は複数の認証秘密鍵(406、411)を受信可能であるのを、有効クレデンシャル(111)を有するユーザのみに限定する。したがって、有効トランザクションを生成するのを、有効クレデンシャル(111)を有するユーザのみに限定する。
・各クレデンシャル(111、112、113、114)を、ユーザの法的身分(105)に結び付ける(図1)。
・各クレデンシャル(図1、111)を使用して、対応する所有者の法的身分(105)を追跡する(116)。
・各多署名アドレス(313、314)をユーザのクレデンシャル(111)に結び付ける(図2)。
・各多署名アドレス(313)を使用して、所有者に対応するクレデンシャル(111)を追跡する(118)(図2)ことで、クレデンシャル(111)により、所有者の法的身分(105)を追跡(116)する(図1)。
・各トランザクションを使用して、送り主と受取先の多署名アドレス(313)を追跡し(図3)、更に多署名アドレス(313)を使用して送り主と受取先のクレデンシャル(111)を追跡(118)し(図2)、最後にクレデンシャル(図1、111)を使用して送り主と受取先の法的身分(105)を追跡する(116)。
・有効クレデンシャル(111)を有するユーザのみが有効多署名アドレス(図2)を作成して、有効トランザクションを作成できることから、全ての有効トランザクションにおける送り主(図1、105)と受取先の法的身分を追跡、捜索(116)可能(図3)とする。
いくつかの形態では、図1、図2及び/又は図3を参照に示す方法は、1又は複数の処理装置(例えば、デジタルプロセッサ、アナログプロセッサ、情報を処理するよう設計されたデジタル回路、情報を処理するよう設計されたアナログ回路、ステートマシン、及び/又は電子的に情報を処理するその他機構)で実行されてもよい。1又は複数の処理装置は、電子記憶媒体に電子的に記憶された指示に応じて、方法の一部又は全部の動作を実行する1又は複数の装置を含んでもよい。1又は複数の処理装置は、図1、図2、及び/又は図3に示す1以上の方法の1又は複数の動作を実行するように設計されたハードウェア、ファームウェア、及び/又はソフトウェアにより構成された1又は複数の装置を含んでもよい。
図4は、本発明に関わるシステムを示す図である。システムは、クライアント−サーバ構造を有し、サーバは、1又は複数の中央認証サーバである。本発明の1又は複数の形態が実現され得る例示的コンピュータネットワーク(「システム400」)が図示されている。いくつかの形態において、システム400は、1又は複数のサーバ401を含んでもよい。1以上のサーバ401は、クライアント/サーバ構造における、1以上の1又は複数のクライアントコンピューティングプラットフォーム414/415と通信するように構成されてもよい。ユーザは、1以上のクライアントコンピューティングプラットフォーム414/415を介してシステム400にアクセスしてもよい。1以上のサーバ401と、1以上のクライアントコンピューティングプラットフォーム414/415は、機械可読命令を実行するように構成されてもよい。
いくつかの形態では、1以上のサーバ401、1以上のクライアントコンピューティングプラットフォーム414/415、及び/又は1以上の外部資源418は、1又は複数の電子通信リンクを介して動作可能にリンクされていてもよい。例えば、当該電子通信リンクは、少なくとも部分的に、インターネット及び/又はその他のネットワークを介して構築されてもよい。ただしこれに限定するものではなく、1以上のサーバ401、1以上のクライアントコンピューティングプラットフォーム414/415、及び/又は1以上の外部資源418がその他の通信媒体を介して動作可能にリンクされ得る形態も、本開示の範囲に含まれることを理解されたい。
所与のクライアントコンピューティングプラットフォーム414/415は、機械可読命令を実行するように構成された1又は複数のプロセッサを含んでもよい。機械可読命令は、所与のクライアントコンピューティングプラットフォーム414/415に関連付けられた技術者又はユーザが、システム400及び/又は1以上の外部資源418とインタフェース可能とする、更に/或いは本明細書に記載の1以上のクライアントコンピューティングプラットフォーム414/415の他の機能を提供するように構成されてもよい。非限定的な例として、所与のクライアントコンピューティングプラットフォーム414/415は、デスクトップコンピュータ、ノートPC、携帯端末、タブレットコンピューティングプラットフォーム、ネットブック、スマートフォン、ゲーム機、及び/又はその他のコンピューティングプラットフォームの内の1又は複数を含んでもよい。
1以上の外部資源418は、情報源、システム400と協働する外部実体、及び/又はその他の資源を含んでもよい。いくつかの形態では、本明細書に記載の1以上の外部資源418の機能の全て又は一部は、システム400内の1以上の資源により提供されてもよい。
1以上のサーバ401及び/又は1以上のクライアントコンピューティングプラットフォーム414/415は、電子ストレージ419、1又は複数のプロセッサ420、及び/又はその他の要素を含んでもよい。1以上のサーバ401は、ネットワーク及び/又はその他のコンピューティングプラットフォームとの情報交換を可能とする通信回線又はポートを含んでもよい。1以上のサーバ401は、図1に示されたものに限定されるものではない。1以上のサーバ401は、本明細書に記載の1以上のサーバ401の機能を提供するために協働する複数のハードウェア、ソフトウェア、及び/又はファームウェア要素を含んでもよい。例えば、1以上のサーバ401は、1以上のサーバ401として協働するコンピューティングプラットフォームのクラウドにより実現されてもよい。
電子ストレージ419は、電子的に情報を記憶する非一時的記憶媒体を含んでもよい。電子ストレージ419の電子記憶媒体は、1以上のサーバ401に対して一体的に設けられた(即ち、実質的に固定された)システムストレージ、及び/又は例えばポート(例えばUSBポート、ファイやワイヤポート等)又はドライブ(例えばディスクドライブ等)を介して1以上のサーバ401に対して脱着可能に接続可能な着脱可能ストレージの一方又は両方を含んでもよい。電子ストレージ419は、光学的可読記憶媒体(例えば、光ディスク等)、磁気的可読記憶媒体(例えば磁気テープ、磁気ハードドライブ、フロッピードライブ等)、電荷式記憶媒体(例えばEEPROM、RAM等)、ソリッドステート記憶媒体(例えばフラッシュドライブ等)、及び/又はその他の電子的可読記憶媒体の内の1または複数を含んでもよい。電子ストレージ419は、1以上の仮想記憶資源(例えばクラウドストレージ、仮想プライベートネットワーク、及び/又は1以上のその他の仮想記憶資源)を含んでもよい。電子ストレージ419は、ソフトウェアアルゴリズム、プロセッサ420により決定された情報、1以上のサーバ401から受信した情報、1以上のコンピューティングプラットフォーム414/415から受信した情報、及び/又は1以上のサーバ401を本明細書に記載のとおりに機能できるようにするその他の情報を記憶してもよい。
プロセッサ420は、1以上のサーバ401における情報処理能力を実現するように構成されてもよい。このため、1以上のプロセッサ420は、デジタルプロセッサ、アナログプロセッサ、情報を処理するように設計されたデジタル回路、情報を処理するように設計されたアナログ回路、ステートマシン、及び/又は電子的に情報を処理するその他の機構の内の1または複数を含んでもよい。図1ではプロセッサ420は単一のものとして図示されているが、これはあくまで例示的である。いくつかの形態では、プロセッサ420は、複数の処理部を含んでもよい。当該処理部は、単一の装置内に物理的に配置されてもよいし、プロセッサ420は、協働する複数の装置の処理機能を示すものであってもよい。プロセッサ420は、ソフトウェア、ハードウェア、ファームウェア、又はソフトウェア、ハードウェア、及び/又はファームウェアの任意の組み合わせ、及び/又はプロセッサ420上で処理能力を実現するその他の機構により、機械可読命令要素及び/又は機械可読命令要素を実行するように構成されてもよい。本項記載の「要素」という用語は、当該要素の機能を実行する任意の要素又は要素群を指すものであってもよい。これは、プロセッサ可読命令実行中の1又は複数の物理的プロセッサ、プロセッサ可読命令、回路、ハードウェア、記憶媒体、又は任意のその他要素を含んでもよい。
クライアント414/415及びサーバ401は、専用要素又はカスタムメードFPGA又はASIC回路により実現可能なデータ処理資源を含んでもよい。当該計算資源は、本発明に関わる方法のステップを実現するソフトウェアの記憶、実行に適している。中央認証サーバ(401)は、クライアント登録リクエスト(図1)、クライアント暗号通貨アドレス(図2)、クライアントアカウント更新リクエスト、及び暗号通貨トランザクション(図3)を処理する。このために、中央認証サーバ(401)はクライアント情報データベース(404)(例えば、ユーザX:法的名、誕生日、住所、連絡先、クレデンシャル、暗号通貨アドレス、トランザクション基準)と、トランザクションデータベース(413)(例えば、トランザクションY:トランザクションID、送り主及び受取先の暗号通貨アドレス,取引されたコインの金額、トランザクション時間、送り主及び受取先のクライアントウォレットのIPアドレス)と協働する。
各通貨アドレスの所有者の法的身分が、クライアント情報データベースに格納される(図1、115)。これにより、「KYC(顧客確認)」規制要件が満たされ、システムが商業活動における支払システムとして利用可能となる。但し、当該情報は誰にでもアクセスできるものではないため、CBEM及びそのトランザクションネットワークの匿名性が保たれる。
コインが盗まれても、1以上の窃盗犯又は1以上のハッカーは、クライアント情報データベース(115)から1以上の受取先の1以上の法的身分を読み出すことで、容易に追跡できる。このように、この形態のシステムは、CBEMコインの盗難を防止する。
ビットコイン及びビットコイン技術を利用したオルトコインの偽名性又は匿名性により、ブロックチェーンに格納された公開トランザクション記録を分析するのみでは、各コイン所有者のコイン収支を追跡することができない。更に、特定の通貨アドレスに記録されたコインの一部のみが支払われると、新たに生成された通貨アドレスに、コインの未使用分の金額が記録される。第三者がブロックチェーンの分析により、コインの総受領額が最終的にどのアドレスに対するトランザクションにより記録されたかを追跡するためには、膨大な計算負荷がかかる。
本発明によると、有効登録ユーザが所有するコインの金額は、中央運営団体がトランザクションデータベースにおけるトランザクション記録を分析することで、完全に捜索及び追跡可能である(413)。各通貨アドレスを対応する所有者に結び付ける機能に加えて設けられた、本システムのこの固有の特性は、コインが送金/支払われた直後の通貨アドレスにおける未使用分のコイン(全額使用されていない場合)を記録することに基づく。言い換えると、通貨アドレスに記録されたコインの金額は、当該アドレスに送られていたコインの全てが、送金/又は支払われない限り、0とはならない(322)。この固有の特性は、第三者によるブロックチェーンのトランザクション記録の分析を介した、暗号通貨の所有権の移転を追跡する処理が軽減されるだけではなく、システムを、特に第三者の監査の下に実現される金融、銀行業務に適用可能にするものである。
中央認証サーバ(401)は、クライアントウォレット(416、417)を実現する1又は複数のクライアント(414、415)と通信する。ウォレットは、中央認証サーバ(401)に動作可能に接続され、トランザクションに関するデータを送受信可能であってもよい。ウォレットは、ソフトウェア、ハードウェア、オンライン、又はその他適切な手段で実現されてもよい。ウォレットは、特定の暗号通貨を1つ格納、又は複数種の暗号通貨を格納可能であってもよい。
ウォレットのユーザによるトランザクションのリクエストは、1又は複数の中央認証サーバ(401)によって検証される。このため、クライアントは、GSM、UMTS,DSL,イーサネット等の適切な双方向通信リンクにより、サーバ(401)に接続される。
本発明は、疑わしい又は不正なトランザクションを自動的に特定、停止する手段を含んでもよい。更に、本発明は、CBEMが(i)マネーロンダリングに使用されたり、(ii)盗まれたりすることを防止する。AML及びKYCポリシーは、特定のエンティティにより決定されてもよいし、既存の規則、規定に準じてもよい。したがって、本発明は、CBEM及びそのトランザクションネットワークが、AML及びKYCポリシー及び規則に準拠可能とする。例えば、GlobalVision Systemsの高度ルールベースインテリジェントBSA/AML/ATFシステムであるPATRIOT OFFICERは、全てのトランザクションにおける疑わしい活動を監視、スクリーニング、検出、警告、調査、分析することでBSA/AML/ATFワークフローを効果的に自動化できるように、適用できる。
本発明の1又は複数の実施形態の1つの変形例として、特定の条件で、トランザクションを遅延、保留、及び/又は逆転させてもよい。通常、送り主は、トランザクションを行う際に、署名を行う必要がある。一実施形態では、ユーザは、トランザクションを逆転できない。但し、トランザクションネットワークを制御する企業は、ユーザのリクエストを受けて、トランザクションを効果的に「逆転」することができる(有効期限が切れるまで、トランザクションを保留することによる)。通常の暗号通貨では、トランザクションの逆転はできない。しかし、本発明のこの変形例では、システムはトランザクションをある期間保留、例えば所定の1又は複数の条件が満たされるため待機するための所定期間、保留する。例えば、ユーザが商品又はサービスの売り手に対してCBEMを送金するためのトランザクションを生成したとする。すると、例えば中央サーバ等のシステムへのユーザ(買い手)からのリクエストに応じて、システムは所定期間経過するまで、トランザクションを未完成の状態で保留する。売り手が正当な商品又はサービスを所定期間中に届ければ、買い手はトランザクションを取り下げない。売り手が正当な商品又はサービスを所定期間中に届けなければ、所定期間前でも買い手はトランザクションを無効にできる。これにより、売り手の行動を促すことができる。
このシステムの変形例として、例えば、中央サーバがFederal Express(登録商標)、UPS(登録商標)、DHL(登録商標)等の配送会社のような第三者から商品発送、配達通知を受け取るまで、受け取らない限り、支払いを延期できる。或いは、保留はトランザクション金額に基づいてもよい。例えば、ユーザは、自動的に任意の金額を超えるトランザクションが自動的に1週間又は任意の期間保留されることを望む場合があり得る。或いは、システムはユーザに所定の金額を超えるトランザクションのみ保留可能としてもよい。また、システムには最長保留期間が存在してもよい。最長保留期間は、トランザクション金額が所定の額増える度に、所定の長さ延長されてもよい。保留は更に、(1)リスクのあるソースからのトランザクションの特定、(2)制裁リストに記載の団体の特定、(3)ユーザの疑わしい活動の特定、(4)リスクのあるソースからの資金の流れの特定、(5)非合法なソースからの資金の流れの特定、(6)疑わしい活動数が所定の閾値を越えたことを特定、(7)その他適切な判定の特定に基づいて実施されてもよい。
図5は、保留の例を示すフローチャートである。ステップ511において、ユーザは、金額XのCBEMを受取先に送るためのトランザクションを生成する。ステップ502aにおいて、システム(例えば、1以上の中央サーバび/又はスマートコントラクトのような規制ユーティリティ)は、ユーザリクエストに応じて、更に/或いは自動的にトランザクションの保留時間を設定する。自動設定は、例えば異常に大きなトランザクション、及び/又は異常な回数のトランザクションの繰り返し、及び/又は本明細書の他部記載のその他疑わしいトランザクション、及び/又は政府規制に応じて実施されるものであってもよい。ステップ503において、システムは、特定のトランザクションが金融犯罪である可能性が高いか否かを判定してもよい。可能性が高い場合、ステップ504において、システムは、トランザクションを逆転(例えば、トランザクションをキャンセルするか、承認しないことで実施)してもよい。別の形態では、ユーザは、上述の理由(商品又はサービスが予定通り配達されなかった)、及び/又は金融犯罪の検出により、トランザクションをキャンセルするか、逆転させてもよい。その場合、トランザクションは、台帳の一部とはならない、即ち、例えばトランザクションが公開されず、ブロックチェーン又は台帳上に記録されない。
ステップ503においてシステムが金融犯罪を検出しなければ、システムはステップ504において、通常どおりにトランザクションが公開、検証、確認、記録されるようにする。したがって、ステップ505において、トランザクションは検証、確認される。ステップ506において、受取先のアカウントに上記金額のCBEMが入金される。別の任意の変形例では、システムは、金融犯罪トランザクションを検出及び/又はそれについて忠告を受けてもよい。その場合、ステップ508において、システムは、受取先のアカウントを凍結してもよい。ステップ507において、金融犯罪がないとされると、ステップ509において、受取先は、金額XのCBEMを、例えば第三者に送金する等の利用が可能になる。
より好ましくは、ユーザは、ステップ501aにおいてトランザクションに署名する(金額XのCBEMを送る)。したがって、ユーザが自身でトランザクションの逆転が可能でないことが最も好ましい。システム(中央サーバ及び/又はスマートコントラクト)を制御するエンティティ又は団体のみが、ステップ504においてユーザの承認なくトランザクションを逆転できる。別の好ましい変形例では、システムは、上述のようにトランザクションを保留するユーザリクエストに応じて、更に1又は複数の条件が、(例えば、予定した受取先によって)所定時間に満たされないトランザクションを逆転してもよい。この形態では、システム(中央サーバ及び/又はスマートコントラクト)は、自動預託者のように機能する。
いくつかの形態において、ユーザは、例えば以下のようにトランザクションを逆転してもよい。スマートコントラクトは、所定の状況下で限定された期間の間、逆転を可能としてもよい。更に/或いは、いくつかの形態の中央サーバ実施は、多署名クライアントウォレットを生成する際に、3つの公開鍵による多署名アドレスを生成してもよい。上述の形態のいくつかにおいて、一方がクライアント、他方が中央サーバに存在するように、2つの鍵組(各鍵組は公開鍵と秘密鍵を含む)を使用してもよい。これにより、クライアントがトランザクションを開始する際、クライアントが提示したトランザクションが最初に中央サーバの承認を得ることが保証される。更に、例えばクライアントがトランザクションを開始する際に、例えばクライアントのウォレットを介してクライアントと通信するため、中央サーバに使用されてもよい。この種の処理において、クライアントにトランザクションを逆転可能とする方法の1つとして、2つの鍵組から、3つの鍵組(即ち、3つの秘密鍵と公開鍵の組)に変更することが考えられる。最初の2つの鍵組は、上述の実施形態通りに使用されてもよい。クライアントが、追加の秘密鍵(更に、この第三鍵組における対応する公開鍵)を更に有する。
中央サーバが1又は複数の公開鍵及び秘密鍵組を有しながら、クライアントが2つの公開鍵及び秘密鍵組を有することになる。なお、多署名アドレスは、4つの公開鍵等より多くの鍵から生成されてもよい。
クライアントの2つの秘密鍵は、同一のウォレットの2つの異なる.dat.fileに格納されてもよい。トランザクションを開始するための、第1秘密鍵は、通常どおり、wallet.dat.fileに格納されてもよい。トランザクションを確認するための第2秘密鍵は、confirm.dat.fileに格納されてもよい。
クライアントは、ある金額のCBEMを送るために、最初に第1秘密鍵を使用してもよい。トランザクションが期限切れになる前に支払いを確認する際、クライアントは確認ボタンを押して、クライアントの第2秘密鍵を使用して、同じトランザクションに署名してもよい。
或いは、クライアントのウォレットは、計算命令(例えば、トランザクションを開始から1週間後に自動的に署名)に応じて、トランザクションが自動的に署名されるよう、クライアントの第2秘密鍵を使用するように構成されてもよい。クライアントは、停止/一時停止ボタンをクリックして、当該自動処理を停止又は一時停止してもよい。上述のトランザクション有効期限は、トランザクションが逆転不能になる時間を選択することで、所望の期間に設定できる。
監視の際、本明細書の他部に記載のように、マネーロンダリング等の不正行為に関するトランザクションを特定、記録、及び/又は報告(例えば、SAR(疑わしい取引報告)及び/又はSTR(疑わしいトランザクション報告)による)するための所定の規則群(例えば法律、及び/又は規制、及び/又はCBEMユーザによるトランザクションの規制又は制限)に合わせて、トランザクションが監視されてもよい。図5を参照に記載するように、疑わしい金融トランザクションは保留(ステップ502a)される、更に/或いは逆転(ステップ504)されてもよい。
例えば、システムは、様々な形態のCBEM支払及びCBEMウォレットに関する疑わしい及び/又は不正活動を検出してもよい。一つの検出方法として、リスクスコアを判定してもよい。
1.この方法は、リスクのある、及び/又は違法ソースからの資金の流れを特定することに基づいてもよい。これは、あらゆるトランザクションに関わる個人同士が、本明細書で定義される自身の認証済み身分を、1又は複数の制裁リスト(搭乗拒否リスト、公開テロリストリスト、テロリスト容疑者リスト、公開マネーロンダリング業者リスト、例えば米国、国連、及び/又はその他任意で選ばれた国による制裁国リスト)、あらゆる当該疑わしい人物又はエンティティの資金の動き、及び/又は幼児ポルノ、その他暗号通貨窃盗、サイバー犯罪への係わりがあるあらゆる人物及び/又はエンティティを、互いに確認しあうことで行われてもよい。
2.ユーザの疑わしい活動を監視することは、更にトランザクション規模に基づく監視を含んでもよい。疑わしい規模のトランザクションは、少なくとも所定額のトランザクション値、及び/又はトランザクションの頻度に基づいてもよい。当該所定額の例としては、10,000ドル以上が挙げられる。当該頻度とは、所定期間中に、同じ及び/又は異なる通貨アドレスの間で、金額が所定金額以上のトランザクションが行われることである。例えば、1日で10,000ドル以上のトランザクションが行われた場合に疑わしいとされる。これは、BSA(銀行秘密法)に基づき、更にそれを反映させて、CTR(通貨取引報告)を発行されること等で実現される。疑わしいトランザクションの別の例としては、アカウントがそのアカウントにしては異常に大きな額を受け取る、及び/又は送金すること、及び/又は過去に個人又はエンティティが過去に疑わしい活動をしていたことが検出されることが挙げられる。
3.個人が、本出願に関わるCBEM用のウォレット外で、自身のその他暗号通貨(本出願のCBEM以外)を送金した回数を詳細に示す警告及び/又はスコアが利用されてもよい。
4.疑わしい活動の検出は、ウェブブラウザの使用を含んでもよい。当該ブラウザは、政府機関又は関連団体により、閲覧に高いリスクが伴うウェブサイトに対して警告を発することで、疑わしい活動を監視可能とするものであってもよい。
1.この方法は、リスクのある、及び/又は違法ソースからの資金の流れを特定することに基づいてもよい。これは、あらゆるトランザクションに関わる個人同士が、本明細書で定義される自身の認証済み身分を、1又は複数の制裁リスト(搭乗拒否リスト、公開テロリストリスト、テロリスト容疑者リスト、公開マネーロンダリング業者リスト、例えば米国、国連、及び/又はその他任意で選ばれた国による制裁国リスト)、あらゆる当該疑わしい人物又はエンティティの資金の動き、及び/又は幼児ポルノ、その他暗号通貨窃盗、サイバー犯罪への係わりがあるあらゆる人物及び/又はエンティティを、互いに確認しあうことで行われてもよい。
2.ユーザの疑わしい活動を監視することは、更にトランザクション規模に基づく監視を含んでもよい。疑わしい規模のトランザクションは、少なくとも所定額のトランザクション値、及び/又はトランザクションの頻度に基づいてもよい。当該所定額の例としては、10,000ドル以上が挙げられる。当該頻度とは、所定期間中に、同じ及び/又は異なる通貨アドレスの間で、金額が所定金額以上のトランザクションが行われることである。例えば、1日で10,000ドル以上のトランザクションが行われた場合に疑わしいとされる。これは、BSA(銀行秘密法)に基づき、更にそれを反映させて、CTR(通貨取引報告)を発行されること等で実現される。疑わしいトランザクションの別の例としては、アカウントがそのアカウントにしては異常に大きな額を受け取る、及び/又は送金すること、及び/又は過去に個人又はエンティティが過去に疑わしい活動をしていたことが検出されることが挙げられる。
3.個人が、本出願に関わるCBEM用のウォレット外で、自身のその他暗号通貨(本出願のCBEM以外)を送金した回数を詳細に示す警告及び/又はスコアが利用されてもよい。
4.疑わしい活動の検出は、ウェブブラウザの使用を含んでもよい。当該ブラウザは、政府機関又は関連団体により、閲覧に高いリスクが伴うウェブサイトに対して警告を発することで、疑わしい活動を監視可能とするものであってもよい。
本発明において、対象のCBEMに関連して使用されるウォレットは、オリジナルビットコイン、Ether、及び/又はダッシュ等の暗号通貨のような、任意の暗号通貨又は少なくとも複数種の暗号通貨も受取可能であることが最も好ましい。
一例として、ユーザが最も好ましい形態のウォレットを有し、当該ウォレットを全てのデジタル通貨のトランザクションに使用すれば、当該ウォレットは中央サーバ(及び/又はスマートコントラクトコード)と通信し、これにより、システムは本発明の実施形態に係るCBEMの単純な使用とは異なる疑わしい活動を監視及び検出できる。更なる例として、銀行及び/又はその他金融機関は、その顧客に、最も好ましい形態のウォレットを使用するように求めてもよい。当該ウォレットは、システムがそのシステム外のウォレット及び/又は暗号通貨によるトランザクションを検出したことを、検出し、銀行及び/又はその他金融機関に警告を発することができる。
AML(及びCTF(テロ資金対策))リスク評価、及び/又は本明細書その他に記載の別金融トランザクションリスク評価のようなトランザクションリスク評価は、通常、本明細書に記載の要素又はその他要素に基づく、第三者によるリスクスコアを判定することで実現される。FATF(マネーロンダリングに関する金融活動作業部会)は、AML及びテロ対策に助言やガイドラインを提供する、政府間組織である。その活動は更に、いわゆるFATFブラックリストと呼ばれる、非協力国又はテロリストのリストを発行することを含む。テロ活動に対する資金提供防止は、更に、IPアドレスを(1)ユーザ登録の際、(2)トランザクションアドレス生成の際、(3)トランザクション開始の際にIPアドレスを監視し、更に、コイン使用パターンを監視することで、実現できる。
好ましくは、監視、警告、報告の対象となる特定の種類のマネーロンダリングは、トランザクションロンダリングを含む。トランザクションロンダリングは、マーチャントが、(例えば偽装カスタマーから)支払いを受けるというマネーロンダリングの一種である。即ち、実際の商品又はサービスの取引は行われていない可能性がある。或いは、企業が違法商品(窃盗品又は偽造品、武器、及び/又は麻薬)を販売し、それに対する支払いを、合法的な商品を販売するような印象を与えるように設けられた合法的なオンラインストアで支払いを迂回するように処理して受け取れる。トランザクションロンダリングは、厳格なKYC要件に従うことなく実行できるので、インターネットビジネスが花盛りの近年では非常に容易となってしまった。合法に偽装された企業は、世界中のどこからでもインターネットを介して運営できる。これらの理由等が、トランザクションロンダリングの防止を非常に困難なものにしている。しかし、本発明の実施形態のCBEMに関しては少なくとも、ユーザは身分が認証されている必要がある。
第三者ソースにより生成されたデータに基づく警告又はスコアを利用してもよいし、更に/或いは1又は複数のソフトウェアソリューションを利用してもよい。現在利用可能な金融トランザクションコンプライアンス用のソフトウェアソリューションは、好ましくは以下のものを含む。
AML360(オーストラリア、シドニー)によるAML360(www.AML360software.com)、EastNets(登録商標)(ニューヨーク州ニューヨーク)によるSafeWatch Profiling(www.EastNets.com)、Fiserv(ウィスコンシン州ブルックフィールド)によるAML Manager(www.fiserv.com)。
ソフトウェアによるAMLビジネス要件には以下のものをはじめとする監視が挙げられる。
・トランザクション監視システムにより、疑わしい取引報告(SAR)又は疑わしいトランザクション報告(STR)の提出となり得る疑わしいトランザクションのパターンを識別。
・通貨トランザクション報告(CTR)システムにより、多額の現金トランザクション報告要件(米国では10,000ドル以上)を監視。
・顧客身元管理システムにより、各種ネガティブリスト(OAFC等)を確認、監視し、KYC要件の初期及び継続部分を示す。電子的検証を別のデータベースに対して確認し、(英国では、選挙人名簿、銀行や信用調査機関が使用する「共有」データベース、電話番号リスト、電気配給事業者リスト、郵便配達データベース)等のIDの積極的確認を提供。
・コンプライアンスソフトウェア。
・トランザクション監視システムにより、疑わしい取引報告(SAR)又は疑わしいトランザクション報告(STR)の提出となり得る疑わしいトランザクションのパターンを識別。
・通貨トランザクション報告(CTR)システムにより、多額の現金トランザクション報告要件(米国では10,000ドル以上)を監視。
・顧客身元管理システムにより、各種ネガティブリスト(OAFC等)を確認、監視し、KYC要件の初期及び継続部分を示す。電子的検証を別のデータベースに対して確認し、(英国では、選挙人名簿、銀行や信用調査機関が使用する「共有」データベース、電話番号リスト、電気配給事業者リスト、郵便配達データベース)等のIDの積極的確認を提供。
・コンプライアンスソフトウェア。
更なる監視として、登録ユーザに関連付けられた1又は複数のIPアドレスを、テロ資金活動、マネーロンダリング、金融マネーロンダリング、その他不正活動に関連付けられたIPアドレスの1又は複数のデータベースに対して、照合することが挙げられる。これは、システムにおけるユーザ登録の際、関連付けられた1又は複数のIPアドレスの変更につながるあらゆるユーザ更新、所定の間隔で定期的に、トランザクションアドレス生成の際、あらゆるトランザクション提示の際、トランザクション開始の際、疑わしい活動に関する所定の規格又は所定の基準に合うトランザクションパターンの際、あらゆる種類(トランザクション金額、疑わしい個人又はエンティティ等に対するトランザクション)に関するリスクスコア閾値に到達した際の内の任意の1又は複数の、好ましくは全てのタイミングで実行される。
更なる例として、1又は複数のユーザのIPアドレスを上記のようなタイミングで確認して、当該1又は複数のアドレスが、輸出禁止及び/又は制裁中のいずれかの国に存在する場合、トランザクションを停止、及び/又は逆転してもよい。
監視ソフトウェアは、以下のものによる規則及び/又はこれらに関する規則を含んでもよい。
・FinCEN(金融犯罪取締ネットワーク)
・BSA(銀行秘密法)
・AML(反マネーロンダリング)
・SAR(疑わしい取引報告)
・RMLO(住宅担保付ローン原債権者)
・HIFCA(金融犯罪集中地域)
・HIDTA(麻薬取引集中地域)
・OFAC(外国資産管理局)
・財務省
・金融犯罪取締ネットワーク(FinCEN)
・国税庁(IRS)
・消費者金融保護局(CFPPB)
・州の規制当局
・FinCEN(金融犯罪取締ネットワーク)
・BSA(銀行秘密法)
・AML(反マネーロンダリング)
・SAR(疑わしい取引報告)
・RMLO(住宅担保付ローン原債権者)
・HIFCA(金融犯罪集中地域)
・HIDTA(麻薬取引集中地域)
・OFAC(外国資産管理局)
・財務省
・金融犯罪取締ネットワーク(FinCEN)
・国税庁(IRS)
・消費者金融保護局(CFPPB)
・州の規制当局
スマートコントラクト内のソースコードが、規制コンプライアンス確認の一部又は全部、及び/又は中央サーバのその他機能を制御してもよい。
1)承認済みトランザクションアドレスがやはり必要であるが、この構成では、単独署名又は多署名通貨アドレスであってもよい。
2)クライアント身元に結び付けられる承認された通貨アドレスは、上述のように生成される。
3)承認済みトランザクションネットワークがやはり必要であるが、この構成では、承認制御は、CBEMがやり取りできる前に、所定の入力又は条件への適合が求められる、1以上の中央サーバの一部又は全部の機能を実現するためのスマートコントラクトを利用して実現される。
4)クライアント/ユーザ、及び/又は運営団体による制御/承認処理の一部又は全部が、スマートコントラクトに組み込まれる。
1)承認済みトランザクションアドレスがやはり必要であるが、この構成では、単独署名又は多署名通貨アドレスであってもよい。
2)クライアント身元に結び付けられる承認された通貨アドレスは、上述のように生成される。
3)承認済みトランザクションネットワークがやはり必要であるが、この構成では、承認制御は、CBEMがやり取りできる前に、所定の入力又は条件への適合が求められる、1以上の中央サーバの一部又は全部の機能を実現するためのスマートコントラクトを利用して実現される。
4)クライアント/ユーザ、及び/又は運営団体による制御/承認処理の一部又は全部が、スマートコントラクトに組み込まれる。
分散型台帳を実行するソフトウェアは、署名されたトランザクションを受信し、例えば各種条件が合うまで保留し、その後記録するようにプログラムされる。保留は、公開及び検証前でも後でもよい。条件の1つとしては、中央サーバの承認を得ることが挙げられる。
任意で、スマートコントラクトは自身の又は中央サーバによるリスクスコア確認を開始し、リスクスコアが閾値以上となると、スマートコントラクトはトランザクションを拒否してもよい。スマートコントラクトは、中央サーバの既存の制御の一部を、分散型台帳を実行ソフトウェアに単純に移転するものであるため、実質的に中央サーバの一部とみなすことができる。
以下の例示的ワークフローを採用してもよい。
クライアントは、スマートコントラクトを開始して、CBEM送金を開始する。ここで、CBEM送金はスマートコントラクトに予め設定された複数のステップを経ることとなる。即ち、有効にCBEMを送金するには、スマートコントラクトに予め設定された基準を満たさなければならない。
スマートコントラクトに予め設定された当該ステップ及び基準は、例えば図5に概略的に示す、以下の経時的イベントを含んでもよい。別の例としては、トランザクションを保留し、各種条件が満たされたか確認し、スマートコントラクト(例えば、中央サーバによるリスクスコア確認、中央サーバによる承認)が完了又は失敗、完了、ネットワークへの公開、検証、記録するというフローが挙げられる。
各種条件が満たされたかを確認するために、スマートコントラクトは、自身で全ての処理を完了してもよいし、中央サーバと協働で全ての処理を完了してもよい。後者の場合、スマートコントラクトは、リクエストを発行し、1以上の中央サーバからの回答を得るインタフェースとして機能する。その後、スマートコントラクトは1以上の中央サーバからの回答を使用して、全ての必要な条件が満たされたかを確認する。スマートコントラクトは更に、第三者ソース等のその他任意のソースに対して、条件が満たされたかを確認してもよい。
図6は、AML及びリスク評価モジュールの要素を示すフローチャートである。当該要素は、関連データを有する各種データベースに接続することと、トランザクション及び提示されたトランザクションを、当該データベースからのデータと、本システムのIDデータベースからのデータと、本システムのトランザクションデータベースからのデータと、提案されたトランザクション(及び/又は確認中のトランザクション)からのデータと、例えば、FATF要件によるコンプライアンスアルゴリズムを使用して分析することと、リスクを判定することと、当該リスクを適宜/必要に応じて報告することと、更に上述の図5の1以上のアクションを実行してトランザクションを保留又は逆転する更に/或いはアカウントを凍結することとを含む。例えば、ユーザがシステムを介してトランザクションを提案する場合(図5のステップ501a)、ユーザのウォレットは、中央サーバに対してトランザクションの承認をリクエストする。本明細書に記載のとおり、図6に示すようにシステムが監視(ステップ503)を実行する間、保留(ステップ502a)が実行されてもよい。同様に、システムがステップ507同様に監視を行う場合、図6に示し、本明細書で説明する処理が行われてもよい。例えばFATF対応アルゴリズムのようなコンプライアンスアルゴリズムは、以下のものを判定する。
・クライアントID、受取先ID、クライアント及び受取先の所在地(国)、ウォッチリストデータ、及びその他外部データから、KYCを判定。
・法令、ブロックチェーントランザクションデータ、及び外部データから、トランザクションリスクを判定。
・顧客ID、顧客の国、商品データ、企業内部データから、内部リスクを判定。
・法律、ガイドライン、メディア情報、広域的情報から、外部リスクを判定。
・クライアントID、受取先ID、クライアント及び受取先の所在地(国)、ウォッチリストデータ、及びその他外部データから、KYCを判定。
・法令、ブロックチェーントランザクションデータ、及び外部データから、トランザクションリスクを判定。
・顧客ID、顧客の国、商品データ、企業内部データから、内部リスクを判定。
・法律、ガイドライン、メディア情報、広域的情報から、外部リスクを判定。
アルゴリズムは、入力データを処理し、各種関連リスクのレベル又はスコアを判定し、警告等の信号を電子装置(例えば、企業コンプライアンス部署のコンピュータ)に送信してもよい。送信は、リスクスコアが所定の閾値を超えると、例えばディスプレイのモニターのような装置への表示、及び/又は聴覚的警告、及び/又は点滅等の視覚的警告として実行されてもよい。例えばAML、KYC、CTF、BSA,及び/又はFATF等のように、監視される各種リスクに対して、閾値が存在してもよい。コンプライアンス部署の装置、及び/又はシステムは、自動的にSAR、STR及び/又はその他レポートを作成し、自動で適切な1以上の権限者に送信してもよい。リスクがかなり高い(所定の閾値に到達)場合、中央サーバが許可を出す前に、中央サーバが許可を出した後、ネットワークに公開される前又は後、及び/又は認証後にトランザクションは停止、遅延、及び/又は逆転されてもよい(但し、ネットワークによって承認されると、トランザクションは逆転しない方が好ましい)。保証されている場合、これらの内の任意のタイミングで、特に認証済みのトランザクションに関して、受取先及び送り主のCBEMアカウントを凍結してもよい。
別の実施形態では、ウォレットがオンライン、オフラインのいずれで格納されているにかかわらず、多署名ウォレットアドレスが使用されることが好ましい。多署名により、中央システムが、トランザクションに求められるNの署名の内のMの署名(例えば、3つの内の2つ)となることが可能となる。したがって、システムは、本明細書の他部に記載のように、ユーザからの提案されたトランザクションを多署名ウォレットを介して受信し、本明細書に記載のように金融トランザクション監視を実行し、トランザクションに署名するか、疑わしい活動又はトランザクションに関わるその他金融リスクがある限り及びなくなるまで、署名を保留してもよい。
このシステムは、図4に示すものと同様又は同じであってもよい。ストレージ419は、システム命令を、例えば不揮発性メモリに格納してもよい。中央認証サーバ401は、本明細書に記載のあらゆる表示及び本明細書に記載のあらゆる警報、及び/又はその他警告機構のため、命令に関連付けられた1又は複数のモニター(グラフィカルユーザインタフェース)を有してもよい。ストレージ419は更に、本明細書に記載の金融リスク及び/又はリスクスコア判定に応じて、監視、検出、及び/又は警告のための、本明細書に記載のソフトウェアを更に有してもよい。外部資源418は、リスクを計算するためのデータを取得するための各種データベース、及び/又は本明細書に記載のリスクを計算するための外部ソフトウェアを含んでもよい。
図7は、1又は複数の形態又は図4の変形例に関わる例示的な変形システムの概要を示す。ここでは、適用ブロックチェーン(又は分散型台帳)700と、スマートコントラクトが使用される。図示のように、プライバシー層702を有する適用ブロックチェーン又は分散型台帳が設けられる。当該層は、ブロックチェーンアクセスに対する許可管理層として機能できる。これは、例えば、管理用に、イーサリアムブロックチェーン、例えば、ブロックチェーン706上に構築されてもよい。図示のように、ファイル(例えば、生体特徴データ及びその他ファイル)を格納するための機構が存在してもよい。これら要素は、RESTfulAPIのようなAPI(アプリケーションプログラミングインタフェース)704、及び例えばブロックチェーンデータベース708に接続され、ビッグチェーンDBのようなストレージの提供及び/又は改善が実現されてもよい。これは、例えばバイオメトリックアップリケ―ション又はウェブサイト等に接続され得る。更に別の構成も採用可能である。この実施形態において、ブロックチェーンの管理は、スマートコントラクト707を含んでもよい。実際、ブロックチェーン706は、この実施形態又は本明細書における実施形態の一部又は全部において、分散型台帳の代わりに使用できる。更に、実施形態の一部又は全部において、別の形態の分散型ストレージを利用できる。
図4同様、クライアントノード414、415と、トランザクションデータベース413及びクライアント情報データベース115を含む1又は複数の中央サーバ401が設けられてもよい。第三者ソースと、ネットワーク外団体714は、図4の外部資源と、ネットワーク外ノードを含んでもよい。全てのシステム要素は、インターネット720を介して通信可能である。実施形態の一部又は全部では、中央サーバ機能を複数の中央サーバに分けてもよい。上述の実施形態の一部又は全部において、1又は複数の中央サーバは、クライアントが実行したいトランザクション(承認済みトランザクション)についてのクライアント情報(トランザクションの疑わしさ/マネーロンダリングである可能性についての情報等)を提供することで、クライアントに許可を与えてもよい。別の実施形態において、1又は複数の中央サーバは、トランザクションを拒否してもよい。本明細書の他部に記載のように、これは、1又は複数の中央サーバにより判定される、1又は複数の条件の存在に応じた自動承認を要することで実現できる。具体的な方法の1つとして、多署名ウォレットを使用してもよい。この場合、中央サーバは、クライアントが生成したトランザクションを、そのトランザクションが行われるまでに署名しなければならない。このトランザクションの承認を実現できる別の方法として、「スマートコントラクト」という処理がある。スマートコントラクトにおいて、トランザクションを実行するために必要な1又は複数の条件が存在するかは、コンピュータ命令により判定される。実際、1又は複数の中央サーバの機能の一部又は全部は、単純にコンピュータ命令を、ブロックチェーンを制御するピアツーピアネットワーク上で動作するソフトウェアのソースコードに加えることで実現される。例えば、スマートコントラクトは、サーバ上で実行されるか、分散型アプリケーション(DAppとも称される)として実行される。DAppは、フロントエンド(HTMLの場合)と、バックエンド(実質的に、フロントエンド用のデータベース)を有する。
いくつかの形態において、少なくとも1つの専用ノードが第1の個人又はユーザの個人身元の承認の署名を実行する。所与の専用ノードは、1又は複数のサーバを含んでもよい。所与の専用ノードは、新規ブロックを生成する及び/又は承認に署名するように構成された公開ノード又は秘密ノードであってもよい。
いくつかの形態において、システムは、SRU(システム規制ユーティリティ)又はシステムプロセッサにより動作されてもよい。システムプロセッサは、1又は複数のサーバ及び/又はスマートコントラクトを含んでもよい。システムプロセッサ又は1以上のサーバは、クライアント/サーバ構造、ピアツーピア構造、及び/又はその他構造に従って、1又は複数のコンピューティングプラットフォームと通信するように構成されてもよい。ユーザは、システムに1以上のコンピューティングプラットフォームを介してアクセスしてもよい。1以上のサーバ及び/又はスマートコントラクトは、機械可読命令を実行するように構成されてもよい。機械可読命令は、1又は複数のSRU(システム規制ユーティリティ)及び/又はその他機械可読命令要素を含んでもよい。SRUは、CBEMトランザクションを受信でき、分散型ストレージ、分散型台帳、ブロックチェーン、又はその他適切な分散型トランザクション機構に動作可能に接続できる。SRUは、スマートコントラクト及び/又は1又は複数のサーバ上のコンピュータ命令として実現されてもよく、システムプロセッサにより動作されるものと考えてもよい。システムプロセッサは、中央サーバと協働するスマートコントラクト、中央サーバのみ、又はスマートコントラクトのみで構成されてもよい。
疑わしい活動についての警告及び/又は報告が行われる2つの例を以下に示す。具体的には、例Aと例Bである。例Aにおいて、CBEMの金額が、対応ネットワーク外の通貨アドレスから、対応ネットワーク内の通貨アドレスへと送られる。例Bにおいて、CBEMの金額が、対応ネットワークから、対応ネットワーク外の通貨アドレスに送られる。
例Aにおいて、中央サーバは、検出に応じて以下のアクションの内の任意のもの、又は全てを実行してもよい。
1.強制AMLチェック(後ろ向きトランザクション分析)
2.システムが、CBEMの金額を対応ネットワーク外からの受信を検出したことをユーザ(クライアント)に警告
3.ユーザ又はクライアントが、トランザクションに関するAMLリスクの分析レポートを取得(例えば購入)するか選択可能である
4.システムが、当該所定のCBEM金額に関連付けられた適切なフラグ又はラベルを提供し、(i)CBEMの金額の送り主と(ii)送り主の通貨アドレスに関連付けられた過去のトランザクションに結び付ける
1.強制AMLチェック(後ろ向きトランザクション分析)
2.システムが、CBEMの金額を対応ネットワーク外からの受信を検出したことをユーザ(クライアント)に警告
3.ユーザ又はクライアントが、トランザクションに関するAMLリスクの分析レポートを取得(例えば購入)するか選択可能である
4.システムが、当該所定のCBEM金額に関連付けられた適切なフラグ又はラベルを提供し、(i)CBEMの金額の送り主と(ii)送り主の通貨アドレスに関連付けられた過去のトランザクションに結び付ける
例Bにおいて、ユーザ又はクライアントがトランザクション(送金)リクエストを発した際に、システムは当該ユーザに、対応ネットワーク外の通貨アドレスに金額を送金していることを警告してもよい。ユーザは更に、システムのAMLチェック(後ろ向きトランザクション分析)を利用して、少なくとも部分的に、当該受取先通貨アドレスの関連付けられた過去のトランザクションに基づいて、対象の受取通貨アドレスのAMLリスクを評価可能であってもよい。
システムは更に任意で、CBEMの金額を送金できる前に、ユーザに追加確認する機会を与えてもよい。当該追加確認リクエストは、CBEM送金動作に伴うリスクについての警告メッセージを含んでもよい。
(i)ここで、例えば送り主は、このようにAMLリスクが伴うようなトランザクションは自己責任でするべきである。更に/或いは、
(ii)対象の受取先アドレスに関するAMLリスクの例えば低、中、高という評価は、ユーザがシステムAMLチェックを購入することを選択した場合にのみ提供されてもよい。
(i)ここで、例えば送り主は、このようにAMLリスクが伴うようなトランザクションは自己責任でするべきである。更に/或いは、
(ii)対象の受取先アドレスに関するAMLリスクの例えば低、中、高という評価は、ユーザがシステムAMLチェックを購入することを選択した場合にのみ提供されてもよい。
例A及びBの両方で、AMLチェックは強制で、ユーザがAMLリスク分析報告を金銭により取得するか否かを選択できることが好ましい。更に/或いは、送り主(例A:例えば、レポートは送り主通貨アドレス、その過去のトランザクション、CBEM金額の元を含んでもよい)又は受取先(例B:例えば、レポートは受取先通貨アドレス、その過去のトランザクションを含んでもよい)が違法トランザクション活動に関わることが判明した場合に、中央サーバは自動的に規制に関する政府機関へのSAR、STR、又はその他レポートを作成してもよい。
当業者であれば、上述の個人/クライアント認証及び検証方法は、1又は複数のコンピュータプログラムにより実行及び/又は制御されてもよいことが容易に理解できよう。当該コンピュータプログラムは、典型的にはコンピューティングデバイス内の計算資源を利用して実行される。アプリケーションは、非一時的媒体に格納される。非一時的媒体の例としては、例えばフラッシュメモリのような不揮発性メモリが挙げられ、揮発性メモリの例としてはRAMが挙げられる。コンピュータ命令は、プロセッサにより実行される。これらメモリは、本明細書に記載の技術的概念に係るコンピュータ実行方法の全てのステップを実行する、コンピュータ実行可能命令を含むコンピュータプログラムを記憶する、記録媒体の例である。
本発明は、トランザクションの安全性及びトレサビリティの向上という効果を実現する。この効果は、セキュリティの向上、CBEM窃盗の試みの低減が統計的測定により確認されたことからも、具体的且つ確実なものである。したがって、本発明は、有用、具体的、且つ確実な効果を実現する。本発明が実現する安全性の向上は、多署名アドレスの生成及びpay−to−script−hashトランザクション及びその特定な変形、形態、及び適用を要するため、暗号通貨に関わるデータが変換されるという点で、機械又は変換試験の条件は満たされる。具体的な方策の形態により、この概念は抽象的とはならない。
本明細書において、本発明を特定の好ましい実施形態を参照して説明、記載、定義したが、本明細書における形態の参照及び例示が発明をいかようにも制限することはない。本発明に対して、その技術的概念の広い範囲から逸脱することなく、様々な変形例や変更を加えられることは自明であろう。記載された好ましい実施形態は単に例示的なものであり、本明細書に記載された技術的概念の範囲を網羅するものではない。
したがって、保護の範囲は、明細書に記載された好ましい実施形態に限定されず、後続の請求項によってのみ限定される。
Claims (53)
- 暗号型電子マネー(CBEM)を伴うトランザクションを監視及び規制するシステムであって、
システム規制ユーティリティを実行するシステムプロセッサ(420及び/又は707)であって、クライアントID登録、クライアント通貨アドレス、CBEMトランザクションを処理するために、
・1又は複数のクライアントの承認済み通貨アドレスを生成するために、クライアントウォレット(416、417)と通信し、
・1又は複数のクライアントの承認済み通貨アドレスを生成するためのリクエストを承認し、
・1又は複数の承認済みトランザクションを生成するために、前記クライアントウォレット(416、417)と通信し、
・CBEMの単位を、通貨アドレスに送金するため、1又は複数のトランザクションを承認し、
・中央運営団体又はクライアントが策定したトランザクション基準を使用して、トランザクションを検証し、
・トランザクションデータベース(413)内にトランザクション情報を格納するように構成されたシステムプロセッサを有し、
前記システムは更に、
1又は複数の承認済み通貨アドレスと、
承認済みトランザクションネットワークと、
前記システムプロセッサ(420及び/又は707)に対して通信可能に接続されるクライアント情報データベース(115)と、
前記システムプロセッサ(420及び/又は707)に対して通信可能に接続されるトランザクションデータベース(413)と、
クライアントウォレット(416、417)が設けられる少なくとも1つのクライアント装置(414、415)とを有し、
前記少なくとも1つのクライアント装置は、
・1又は複数の承認済み通貨アドレスを生成するための許可を、前記システムプロセッサ(420及び/又は707)から取得し、
・CBEMの単位を受取先の通貨アドレスに送金するため、1又は複数の承認済みトランザクションを生成する許可を、前記システムプロセッサ(420及び/又は707)から取得し、
・CBEMの単位を受取先の通貨アドレスに送金するため、前記トランザクションを署名することにより、1又は複数の承認済みトランザクションを生成するように構成され、
前記システムプロセッサ(420及び/又は707)は、前記承認済みトランザクションを受信すると、前記トランザクションを許可する前に、所定時間、前記承認済みトランザクションを遅延させるように構成され、1又は複数の条件が満たされたか否かの判定に応じて許可されるかが決まる、システム。 - 前記システムプロセッサは、中央サーバを含む、請求項1に記載のシステム。
- 前記システムプロセッサは、スマートコントラクトを使用して制御されるプロセッサを含む、請求項1に記載のシステム。
- 前記システムプロセッサは、スマートコントラクトにより制御される中央サーバとプロセッサとを含む、請求項1に記載のシステム。
- 複数のクライアントが存在する、請求項1から4のいずれか1項に記載のシステム。
- 前記システムプロセッサは更に、
クライアントの個人アカウントを生成し、
クライアントが提出した、実際の個人身元情報を確認し、記録し、
クライアントが提出した、個人認証クレデンシャルを記録し、
クライアントが生成した、承認済み通貨アドレスを記録し、
クライアントの承認済み通貨アドレス、個人身元情報、個人認証クレデンシャルを、前記クライアント情報データベース内にマッピング及び格納し、
前記少なくとも1つのCBEMの単位の所有権を、クライアントの通貨アドレスを使用して、トランザクションデータベースに記録するように構成される、請求項1から5のいずれか1項に記載のシステム。 - 前記1又は複数の条件は、AML、KYC、CTF、BSA、FATFの内の少なくとも1つに関するトランザクション基準に基づく、前記トランザクションの準拠に対する疑わしさの度合いに関する、請求項1から6のいずれか1項に記載のシステム。
- 前記システムプロセッサが所定の疑わしさの度合いであると判定すると、前記システムプロセッサがトランザクションを停止する、請求項1から7のいずれか1項に記載のシステム。
- 前記システムプロセッサは、前記少なくとも1つの条件が満たされたという通知を受信せずに、前記所定期間が経過すると、前記トランザクションを停止する、請求項1から8のいずれか1項に記載のシステム。
- 前記システムプロセッサは、前記トランザクションをキャンセルするという通知を前記クライアントから受信せずに、前記所定期間が経過すると、前記トランザクションを許可する、請求項1から9のいずれか1項に記載のシステム。
- 前記システムプロセッサは、前記少なくとも1つの条件が満たされたという通知を受信せずに、前記所定期間が経過すると、前記トランザクションを停止する、請求項1から10のいずれか1項に記載のシステム。
- 前記1又は複数の条件についての前記通知は、第三者の電子装置から、前記システムプロセッサが受信する、請求項1から11のいずれか1項に記載のシステム。
- 暗号型電子マネー(CBEM)を伴うトランザクションを監視及び規制するシステムであって、
システム規制ユーティリティを実行するシステムプロセッサ(420及び/又は707)であって、クライアントID登録、クライアント通貨アドレス、CBEMトランザクションを処理するために、
・1又は複数のクライアントの承認済み通貨アドレスを生成するために、クライアントウォレット(416、417)と通信し、
・1又は複数のクライアントの承認済み通貨アドレスを生成するためのリクエストを承認し、
・1又は複数の承認済みトランザクションを生成するために、前記クライアントウォレット(416、417)と通信し、
・CBEMの単位を、通貨アドレスに送金するため、1又は複数のトランザクションを承認し、
・中央運営団体又はクライアントが策定したトランザクション基準を使用して、トランザクションを検査し、
・トランザクションデータベース(413)内にトランザクション情報を格納するように構成されたシステムプロセッサを有し、
前記システムは更に、
1又は複数の承認済み通貨アドレスと、
承認済みトランザクションネットワークと、
前記システムプロセッサ(420及び/又は707)に対して通信可能に接続されるクライアント情報データベース(115)と、
前記システムプロセッサ(420及び/又は707)に対して通信可能に接続されるトランザクションデータベース(413)と、
クライアントウォレット(416、417)が設けられる少なくとも1つのクライアント装置(414、415)とを有し、
前記少なくとも1つのクライアント装置は、
・1又は複数の承認済み通貨アドレスを生成するための許可を、前記システムプロセッサ(420及び/又は707)から取得し、
・CBEMの単位を受取先の通貨アドレスに送金するため、1又は複数の承認済みトランザクションを生成する許可を、前記システムプロセッサ(420及び/又は707)から取得し、
・CBEMの単位を受取先の通貨アドレスに送金するため、前記トランザクションを署名することにより、1又は複数の承認済みトランザクションを生成するように構成され、
前記システムプロセッサ(420及び/又は707)は、前記承認済みトランザクションの受信、前記トランザクションネットワークによる前記承認済みトランザクションの検証及び確認、前記受取先のアカウントの前記CBEM受け取り後、中央運営団体又はクライアントが策定したトランザクション基準に基づく、前記トランザクションの準拠に対する疑わしさの度合いを検出すると、前記受取先のアカウントを凍結して、CBEM転送不能とするように構成された、システム。 - 前記システムプロセッサは、中央サーバを含む、請求項13に記載のシステム。
- 前記システムプロセッサは、スマートコントラクトを使用して制御されるプロセッサを含む、請求項13に記載のシステム。
- 前記システムプロセッサは、スマートコントラクトにより制御される中央サーバとプロセッサとを含む、請求項13に記載のシステム。
- 前記システムプロセッサは更に、
クライアントの個人アカウントを生成し、
クライアントが提出した、実際の個人身元情報を確認し、記録し、
クライアントが提出した、個人認証クレデンシャルを記録し、
クライアントが生成した、承認済み通貨アドレスを記録し、
クライアントの承認済み通貨アドレス、個人身元情報、個人認証クレデンシャルを、前記クライアント情報データベース内にマッピング及び格納し、
前記少なくとも1つのCBEMの単位の所有権を、クライアントの通貨アドレスを使用して、トランザクションデータベースに記録するように構成される、請求項13から16のいずれか1項に記載のシステム。 - 前記システムプロセッサは、クライアントのトランザクションにおける疑わしいトランザクションを監視し、前記少なくとも1つの基準は、金融犯罪リスク、テロ資金援助リスク、政府の制裁リストに反するトランザクションであるリスク、トランザクションロンダリングリスクの内の少なくとも1つを示すものであり、前記承認済みトランザクションネットワークは、前記システムプロセッサに格納された前記中央トランザクション基準に沿わないあらゆるトランザクションを拒絶するように変形されてもよい、請求項13から17のいずれか1項に記載のシステム。
- 前記トランザクション基準は、マネーロンダリング等の不正行為に関する可能性が高い疑わしいトランザクションを停止するために、中央運営団体によって策定され、前記システムプロセッサは、疑わしいトランザクションの通知を得ると、前記承認済みトランザクションを停止すること及び、警告を発することの少なくとも一方を行う、請求項13から18のいずれか1項に記載のシステム。
- 前記システムプロセッサは、トランザクションと、受取先の少なくとも一方に関するリスクスコアを決定及び取得し、前記少なくとも1つの基準が前記リスクスコアに関連する、請求項13から19のいずれか1項に記載のシステム。
- 前記リスクスコアは、前記システムにおける少なくとも1つのクライアントのID関連情報と制裁リストとの比較、少なくとも1つのクライアントの過去のトランザクションに疑わしい活動があるかの分析、前記承認済みトランザクションが疑わしい活動のものかの分析、トランザクションロンダリングを識別する分析、前記クライアントのCBEMのソースがリスクがあるか及び違法であるかの内の少なくとも一方であるソースかの分析の内の少なくとも1つに基づく、請求項20に記載のシステム。
- 前記リスクスコアは、(i)前記システムプロセッサが前記対応ネットワーク外からのCBEMの受信又は前記対応ネットワーク外へのCBEMの送信を監視している状況で、前記対応ネットワークにおける前記クライアントウォレット外のCBEMの送信をクライアントが行った1又は複数の回数と、(ii)前記システムプロセッサが前記クライアントのウェブブラウザを監視することで、前記クライアントが閲覧した少なくとも1つのウェブサイトに関するデータを取得する状況で、前記ウェブサイトに関する詐欺のリスク、金融犯罪のリスク及びテロのリスクの内の少なくとも1つに基づき増加する、請求項20又は21に記載のシステム。
- 前記システムプロセッサは、承認済みトランザクションが疑わしい活動に関するかを監視し、前記リスクスコアと、前記リスクスコアを判定するためのデータを第三者ソースから取得する、請求項13から22のいずれか1項に記載のシステム。
- 前記クライアントウォレットは、多署名ウォレット及び/又はスマートコントラクトを処理するためのウォレットである、請求項13から22のいずれか1項に記載のシステム。
- 前記クライアントウォレットは、前記承認済みトランザクションを生成する場合以外では、オフラインで格納される、請求項13から24のいずれか1項に記載のシステム。
- 暗号型電子マネー(CBEM)を伴うトランザクションを監視及び規制する個人認証及び確認システムであって、
システム規制ユーティリティを実行するシステムプロセッサ(420及び/又は707)であって、クライアントID登録、クライアント通貨アドレス、CBEMトランザクションを処理するために
・1又は複数のクライアントの承認済み通貨アドレスを生成するために、クライアントウォレット(416、417)と通信し、
・1又は複数のクライアントの承認済み通貨アドレスを生成するためのリクエストを承認し、
・1又は複数の承認済みトランザクションを生成するために、前記クライアントウォレット(416、417)と通信し、
・CBEMの単位を、通貨アドレスに送金するため、1又は複数のトランザクションを承認し、
・中央運営団体又はクライアントが策定したトランザクション基準を使用して、トランザクションを検査し、
・トランザクションデータベース(413)内にトランザクション情報を格納するように構成されたシステムプロセッサを有し、
前記システムは更に、
1又は複数の承認済み通貨アドレスと、
承認済みトランザクションネットワークと、
前記システムプロセッサ(420及び/又は707)に対して通信可能に接続されるクライアント情報データベース(115)と、
前記システムプロセッサ(420及び/又は707)に対して通信可能に接続されるトランザクションデータベース(413)と、
クライアントウォレット(416、417)が設けられる少なくとも1つのクライアント装置(414、415)とを有し、
前記少なくとも1つのクライアント装置は、
・1又は複数の承認済み通貨アドレスを生成するための許可を、前記システムプロセッサ(420及び/又は707)から取得し、
・CBEMの単位を受取先の通貨アドレスに送金するため、1又は複数の承認済みトランザクションを生成する許可を、前記システムプロセッサ(420及び/又は707)から取得し、
・CBEMの単位を受取先の通貨アドレスに送金するため、前記トランザクションを署名することにより、1又は複数の承認済みトランザクションを生成するように構成され、
前記システムプロセッサ(420及び/又は707)は、承認済みトランザクションを前記クライアント装置から受信すると、前記トランザクション基準に基づいて前記トランザクションを検査し、承認済みトランザクションの疑わしさの度合いを判定し、前記疑わしさの度合いが所定の閾値を超え、所定の規則に基づき違法活動の可能性が高いこと示す場合に、前記トランザクションを拒否し、前記疑わしさの度合いは、前記クライアント情報データベースのクライアント情報、前記トランザクションデータベース、前記承認済みトランザクションに関する前記トランザクション情報、中央運営団体により策定された基準、前記クライアントの所在地、前記受取先の所在地、及び外部ソースに少なくとも部分的に基づいて判定される、システム。 - 前記システムプロセッサは、中央サーバを含む、請求項26に記載のシステム。
- 前記システムプロセッサは、スマートコントラクトを使用して制御されるプロセッサを含む、請求項26に記載のシステム。
- 前記システムプロセッサは、スマートコントラクトにより制御される中央サーバとプロセッサとを含む、請求項26に記載のシステム。
- 複数のクライアントが存在する、請求項26から29のいずれか1項に記載のシステム。
- 前記システムプロセッサは更に、
クライアントの個人アカウントを生成し、
クライアントが提出した、実際の個人身元情報を確認し、記録し、
クライアントが提出した、個人認証クレデンシャルを記録し、
クライアントが生成した、承認済み通貨アドレスを記録し、
クライアントの承認済み通貨アドレス、個人身元情報、個人認証クレデンシャルを、前記クライアント情報データベース内にマッピング及び格納し、
前記少なくとも1つのCBEMの単位の所有権を、クライアントの通貨アドレスを使用して、トランザクションデータベースに記録するように構成される、請求項26から30のいずれか1項に記載のシステム。 - 前記中央運営団体又はクライアントが策定した前記基準は、トランザクションロンダリングに関する基準を含み、前記システムプロセッサは、トランザクションロンダリングの可能性が高いと判断した場合に、トランザクションを拒否する、請求項26から31のいずれか1項に記載のシステム。
- 前記中央運営団体又はクライアントが策定した前記基準は、前記トランザクションにおける前記CBEMのソースに関する基準を含む、請求項26から32のいずれか1項に記載のシステム。
- 前記システムプロセッサは、前記トランザクションデータベース及び外部ソースからの入力を使用する、請求項26から33のいずれか1項に記載のシステム。
- 前記中央運営団体又はクライアントが策定した前記基準は、制裁リストに関する基準を含む、請求項26から34のいずれか1項に記載のシステム。
- 前記システムプロセッサは、前記クライアント又は受取先がウェブサイトにアクセスしたかを判定し、前記中央運営団体又はクライアントが策定した前記基準は、アクセスされたウェブサイトの種類に関する基準を含む、請求項26から35に記載のシステム。
- 暗号型電子マネー(CBEM)を伴うトランザクションを監視及び規制する個人認証及び確認システムであって、
システム規制ユーティリティを実行するシステムプロセッサ(420及び/又は707)であって、クライアントID登録、クライアント通貨アドレス、CBEMトランザクションを処理するために
・1又は複数のクライアントの承認済み通貨アドレスを生成するために、クライアントウォレット(416、417)と通信し、
・1又は複数のクライアントの承認済み通貨アドレスを生成するためのリクエストを承認し、
・1又は複数の承認済みトランザクションを生成するために、前記クライアントウォレット(416、417)と通信し、
・CBEMの単位を、通貨アドレスに送金するため、1又は複数のトランザクションを承認し、
・中央運営団体又はクライアントが策定したトランザクション基準を使用して、トランザクションを検査し、
・トランザクションデータベース(413)内にトランザクション情報を格納するように構成されたシステムプロセッサを有し、
前記システムは更に、
1又は複数の承認済み通貨アドレスと、
承認済みトランザクションネットワークと、
前記システムプロセッサ(420及び/又は707)に対して通信可能に接続されるクライアント情報データベース(115)と、
前記システムプロセッサ(420及び/又は707)に対して通信可能に接続されるトランザクションデータベース(413)と、
クライアントウォレット(416、417)が設けられる少なくとも1つのクライアント装置(414、415)とを有し、
前記少なくとも1つのクライアント装置は、
・1又は複数の承認済み通貨アドレスを生成するための許可を、前記システムプロセッサ(420及び/又は707)から取得し、
・CBEMの単位を受取先の通貨アドレスに送金するため、1又は複数の承認済みトランザクションを生成する許可を、前記システムプロセッサ(420及び/又は707)から取得し、
・CBEMの単位を受取先の通貨アドレスに送金するため、前記トランザクションを署名することにより、1又は複数の承認済みトランザクションを生成するように構成され、
前記システムプロセッサは(420及び/又は707)は、(i)第1種類のクライアントウォレットがCBEMを第2種類のクライアントウォレットに送金しており、前記第2種類のクライアントウォレットが、金融規制対応ネットワーク外であること、(ii)前記第1種類のクライアントウォレットが金融規制対応CBEM以外のCBEMを受け取ったこと、のうちの少なくとも1つに応じて、警告信号を生成し、電子装置に送信するように構成された、システム。 - 前記システムプロセッサは、中央サーバを含む、請求項37に記載のシステム。
- 前記システムプロセッサは、スマートコントラクトを使用して制御されるプロセッサを含む、請求項37に記載のシステム。
- 前記システムプロセッサは、スマートコントラクトにより制御される中央サーバとプロセッサとを含む、請求項37に記載のシステム。
- 複数のクライアントが存在する、請求項37から40のいずれか1項に記載のシステム。
- 前記システムプロセッサは更に、
クライアントの個人アカウントを生成し、
クライアントが提出した、実際の個人身元情報を確認し、記録し、
クライアントが提出した、個人認証クレデンシャルを記録し、
クライアントが生成した、承認済み通貨アドレスを記録し、
クライアントの承認済み通貨アドレス、個人身元情報、個人認証クレデンシャルを、前記クライアント情報データベース内にマッピング及び格納し、
前記少なくとも1つのCBEMの単位の所有権を、クライアントの通貨アドレスを使用して、トランザクションデータベースに記録するように構成される、請求項37から41のいずれか1項に記載のシステム。 - 前記システムプロセッサは、承認済みトランザクションが疑わしい活動であるかを監視し、前記システムプロセッサは、疑わしい活動が検出された場合に、クライアントと政府機関の内の少なくとも1方に、警告を発する、請求項37から42のいずれか1項に記載のシステム。
- 前記システムプロセッサは、前記クライアントウォレットから承認済みトランザクションを受信すると、中央運営団体(501)及び/又はクライアント(502)により策定されたトランザクション基準を使用して、前記承認済みトランザクションをコンプライアンス基準と比較し、前記承認済みトランザクションの停止、前記承認済みトランザクションの所定期間の保留、前記承認済みトランザクション又はクライアントに関する警告の発行、前記中央運営団体及び/又は前記クライアントに対する前記承認済みトランザクションの報告の内の少なくとも1つを行う、請求項37から43のいずれか1項に記載のシステム。
- 前記システムプロセッサは、承認済みトランザクションが、トランザクションロンダリングを含むAML,KYC、CTF、BSA、及びFATFコンプライアンスの内の少なくとも1つに違反しているという疑わしさの度合いを判定する、請求項37から44のいずれか1項に記載のシステム。
- 前記疑わしさの度合いは、前記対応ネットワークにおける前記クライアントウォレット外から、クライアントが暗号通貨の送金又は受取を行った回数の分析に基づく、請求項45に記載のシステム。
- (i)前記システムプロセッサは、クライアントの疑わしいトランザクションを監視し、前記中央運営団体又はクライアントが策定した前記基準は、クライアントが疑わしいトランザクションに関わった回数を含むことと、(ii)前記システムプロセッサは、前記クライアント又は受取先がウェブサイトにアクセスしたかを判定し、前記中央運営団体又はクライアントが策定した前記基準は、アクセスされたウェブサイトの種類に関する基準を含むことと、の内の少なくとも一方が実現される、請求項37から46のいずれか1項に記載のシステム。
- 暗号型電子マネー(CBEM)を伴うトランザクションを監視及び規制する個人認証及び確認システムであって、
システム規制ユーティリティを実行するシステムプロセッサ(420及び/又は707)であって、クライアントID登録、クライアント通貨アドレス、CBEMトランザクションを処理するために
・1又は複数のクライアントの承認済み通貨アドレスを生成するために、クライアントウォレット(416、417)と通信し、
・1又は複数のクライアントの承認済み通貨アドレスを生成するためのリクエストを承認し、
・1又は複数の承認済みトランザクションを生成するために、前記クライアントウォレット(416、417)と通信し、
・CBEMの単位を、通貨アドレスに送金するため、1又は複数のトランザクションを承認し、
・中央運営団体又はクライアントが策定したトランザクション基準を使用して、トランザクションを検査し、
・トランザクションデータベース(413)内にトランザクション情報を格納するように構成されたシステムプロセッサを有し、
前記システムは更に、
1又は複数の承認済み通貨アドレスと、
承認済みトランザクションネットワークと、
前記システムプロセッサ(420及び/又は707)に対して通信可能に接続されるクライアント情報データベース(115)と、
前記システムプロセッサ(420及び/又は707)に対して通信可能に接続されるトランザクションデータベース(413)と、
クライアントウォレット(416、417)が設けられる少なくとも1つのクライアント装置(414、415)とを有し、
前記少なくとも1つのクライアント装置は、
・1又は複数の承認済み通貨アドレスを生成するための許可を、前記システムプロセッサ(420及び/又は707)から取得し、
・CBEMの単位を受取先の通貨アドレスに送金するため、1又は複数の承認済みトランザクションを生成する許可を、前記システムプロセッサ(420及び/又は707)から取得し、
・CBEMの単位を受取先の通貨アドレスに送金するため、前記トランザクションを署名することにより、1又は複数の承認済みトランザクションを生成するように構成され、
前記システムプロセッサ(420及び/又は707)は、クライアントの疑わしいトランザクションを監視し、前記中央運営団体又はクライアントが策定した前記基準は、クライアントが疑わしいトランザクションに関わった回数を含み、(ii)前記システムプロセッサは、前記クライアント又は受取先がウェブサイトにアクセスしたかを判定し、前記中央運営団体又はクライアントが策定した前記基準は、アクセスされたウェブサイトの種類に関する基準を含む、システム。 - 前記システムプロセッサは、中央サーバを含む、請求項48に記載のシステム。
- 前記システムプロセッサは、スマートコントラクトを使用して制御されるプロセッサを含む、請求項48に記載のシステム。
- 前記システムプロセッサは、スマートコントラクトにより制御される中央サーバとプロセッサとを含む、請求項48に記載のシステム。
- 複数のクライアントが存在する、請求項48から51のいずれか1項に記載のシステム。
- 前記システムプロセッサは更に、
クライアントの個人アカウントを生成し、
クライアントが提出した、実際の個人身元情報を確認し、記録し、
クライアントが提出した、個人認証クレデンシャルを記録し、
クライアントが生成した、承認済み通貨アドレスを記録し、
クライアントの承認済み通貨アドレス、個人身元情報、個人認証クレデンシャルを、前記クライアント情報データベース内にマッピング及び格納し、
前記少なくとも1つのCBEMの単位の所有権を、クライアントの通貨アドレスを使用して、トランザクションデータベースに記録するように構成される、請求項48から52のいずれか1項に記載のシステム。
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/US2018/026136 WO2019194803A1 (en) | 2018-04-04 | 2018-04-04 | Systems and methods for personal identification and verification |
Publications (1)
Publication Number | Publication Date |
---|---|
JP3228339U true JP3228339U (ja) | 2020-10-22 |
Family
ID=68101117
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2018600051U Expired - Fee Related JP3228339U (ja) | 2018-04-04 | 2018-04-04 | 個人認証及び確認システム及び方法 |
Country Status (2)
Country | Link |
---|---|
JP (1) | JP3228339U (ja) |
WO (1) | WO2019194803A1 (ja) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP6967211B1 (ja) * | 2021-07-22 | 2021-11-17 | 直樹 柴田 | 違法な取引を防止しつつ匿名ユーザの参加も許容する暗号資産の取引のための完全分散型ブロックチェーンシステム及びコンピュータープログラム |
WO2022092162A1 (ja) * | 2020-10-29 | 2022-05-05 | Line株式会社 | 情報処理装置、プログラム、方法、端末 |
JP7540638B2 (ja) | 2022-01-12 | 2024-08-27 | 一也 西本 | 秘密鍵運用簡易化システム |
Families Citing this family (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111047300B (zh) * | 2019-12-19 | 2023-04-18 | 深圳天玑数据有限公司 | 基于区块链的在线审批方法、终端及可读存储介质 |
EP3961539A1 (en) * | 2020-08-24 | 2022-03-02 | Dunamu Inc. | Method for mediating virtual asset transmission |
US20220188836A1 (en) * | 2020-12-15 | 2022-06-16 | Nicholas Scherling | Anti-Money Laundering Blockchain Technology |
US20220391859A1 (en) * | 2021-06-08 | 2022-12-08 | Vesto LLC | Secure cryptocurrency transaction with identification information |
CA3220726A1 (en) * | 2021-06-30 | 2023-01-05 | Max GUISE | Systems and methods for managing cryptocurrency |
IT202100023090A1 (it) * | 2021-09-07 | 2023-03-07 | It Legals Ltd | Sistema e metodo per la deanonimizzazione di possessori di criptovaluta e la tracciabilita’ delle transazioni di criptovaluta con blockchain |
TWI814635B (zh) | 2022-11-08 | 2023-09-01 | 歐簿客科技股份有限公司 | 多管道支付方法及系統 |
Family Cites Families (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7913302B2 (en) * | 2004-05-02 | 2011-03-22 | Markmonitor, Inc. | Advanced responses to online fraud |
CA2931093A1 (en) * | 2013-12-19 | 2015-06-25 | Visa International Service Association | Cloud-based transactions methods and systems |
US10497037B2 (en) * | 2014-03-31 | 2019-12-03 | Monticello Enterprises LLC | System and method for managing cryptocurrency payments via the payment request API |
EP3767878A1 (en) * | 2015-03-27 | 2021-01-20 | Black Gold Coin, Inc. | A system and a method for personal identification and verification |
-
2018
- 2018-04-04 JP JP2018600051U patent/JP3228339U/ja not_active Expired - Fee Related
- 2018-04-04 WO PCT/US2018/026136 patent/WO2019194803A1/en active Application Filing
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2022092162A1 (ja) * | 2020-10-29 | 2022-05-05 | Line株式会社 | 情報処理装置、プログラム、方法、端末 |
JP6967211B1 (ja) * | 2021-07-22 | 2021-11-17 | 直樹 柴田 | 違法な取引を防止しつつ匿名ユーザの参加も許容する暗号資産の取引のための完全分散型ブロックチェーンシステム及びコンピュータープログラム |
WO2023002640A1 (ja) * | 2021-07-22 | 2023-01-26 | プルーフオブサーチ株式会社 | 違法な取引を防止しつつ匿名ユーザの参加も許容する暗号資産の取引のための完全分散型ブロックチェーンシステム及びコンピュータープログラム |
JP2023016626A (ja) * | 2021-07-22 | 2023-02-02 | 直樹 柴田 | 違法な取引を防止しつつ匿名ユーザの参加も許容する暗号資産の取引のための完全分散型ブロックチェーンシステム及びコンピュータープログラム |
JP7540638B2 (ja) | 2022-01-12 | 2024-08-27 | 一也 西本 | 秘密鍵運用簡易化システム |
Also Published As
Publication number | Publication date |
---|---|
WO2019194803A1 (en) | 2019-10-10 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP3228339U (ja) | 個人認証及び確認システム及び方法 | |
US20220277307A1 (en) | Systems and methods for personal identification and verification | |
US20180240107A1 (en) | Systems and methods for personal identification and verification | |
US11044087B2 (en) | System for digital identity authentication and methods of use | |
US10887098B2 (en) | System for digital identity authentication and methods of use | |
Xu | Are blockchains immune to all malicious attacks? | |
CN107683493B (zh) | 用于基于交易的部分验证来更新分布式账本的系统和方法 | |
Winn | Open Systems, Free Markets, and Regulation of Internet Commerce | |
US8224753B2 (en) | System and method for identity verification and management | |
AU2018100482A4 (en) | Systems and methods for personal identification and verification | |
JPH10504150A (ja) | 商用暗号システムにおけるディジタル署名を安全に使用するための方法 | |
CN101461209A (zh) | 安全的数据传输的装置与方法 | |
Zouina et al. | Towards a distributed token based payment system using blockchain technology | |
KR20190120933A (ko) | 안전한 암호화폐 거래를 위한 분산 원장 기술 기반의 전자지갑 시스템 및 그 방법 | |
US20240104521A1 (en) | System and method for compliance-enabled digitally represented assets | |
Ghonge et al. | A comprehensive review of the security and privacy issues in blockchain technologies | |
Khedekar et al. | Protection to Personal Data Using Decentralizing Privacy of Blockchain. | |
Lohstroh | Why the equifax breach should not have mattered | |
Bhattarai | Blockchain in Cybersecurity, Pros, and Cons | |
Arnone | Security and Privacy in the Digital Currency Space | |
Mundra et al. | Blockchain-Based Novel Solution for Online Fraud Prevention and Detection | |
Kitbuncha | Legal measures on authentication of electronic fund transfer | |
Franjić | BITCOIN TRANSACTIONS | |
KR20230037419A (ko) | 디지털 자산의 잔고 증명 방법 및 시스템 | |
Booyens | A Legal Perspective on the Risks Relating to Internet Banking |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20180814 |
|
R150 | Certificate of patent or registration of utility model |
Ref document number: 3228339 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
LAPS | Cancellation because of no payment of annual fees |