JP3228339U - 個人認証及び確認システム及び方法 - Google Patents

Abstract

【課題】暗号型電子マネー（ＣＢＥＭ）を伴うトランザクションを監視及び規制する、個人／クライアント認証及び検証処理、偽名性システムを提供する。【解決手段】システム規制ユーティリティを実行するシステムプロセッサ４２０と、１又は複数の承認済み通貨アドレスと、承認済みトランザクションネットワークと、システムプロセッサに対して通信可能に接続されるクライアント情報データベース１１５と、トランザクションデータベース４１３と、クライアントウォレット４１６、４１７が設けられる少なくとも１つのクライアント装置４１４、４１５とを有し、クライアント装置は、承認済み通貨アドレスを生成するための許可と、ＣＢＥＭの単位を受取先の通貨アドレスに送金するための承認済みトランザクションを生成する許可を、システムプロセッサから取得し、承認済みトランザクションを生成する。システムプロセッサは、承認済みトランザクションを受信すると、許可前に所定期間遅延させ、条件判定に応じて許可する。【選択図】図４

Description

本発明は、個人認証及び確認システム及び方法に関わる。特に、本発明は、個人／クライアント認証及び確認処理と、偽名性システム、及び暗号型電子マネー／法的身分関連クレデンシャル検証プロトコルのトランザクションを監視、規制するトランザクションネットワークに関する。

デジタル通貨やデジタルマネーが従来技術において定義されている。それらは、インターネットに基づくトランザクション媒体（即ち、紙幣やコインのような物理通貨と異なる）であって、物理通貨と同様の特性を持ちながら、即時トランザクションを可能とし、所有権をボーダレスに移転可能とする。

仮想通貨、暗号通貨はそれぞれデジタル通貨の一種であるが、デジタル通貨がそれら通貨の一種ではない。現状の金銭同様、これら通貨は、物理的な商品やサービスの購入に利用できる。ビットコインのようなデジタル通貨は、「分散型デジタル通貨」とも称される。即ち、中央集権的なマネーサプライ制御が不在である（Ｗｉｋｉｐｅｄｉａ参照）。

ビットコインは、２００８年に発明された暗号型電子マネー（ＣＢＥＭ、暗号型電子マネー）である。ビットコインは仮想通貨であるだけではなく、金銭トランザクションの記録、認証用の分散型ピアツーピアトランザクションネットワークを含む決済システムでもある。

ビットコイン所有者はそれぞれ、固有のビットコインアドレスが１又は複数割り当てられており、クライアントウォレットというソフトウェアを所有している。ビットコイン（即ち暗号通貨単位）の所有権は、各所有者のクライアントに記憶されるのではなく、所有者のビットコインアドレスを利用して、全てのビットコイントランザクションの公開台帳、即ちブロックチェーンに記録されるのである。ビットコインアドレスは、公開／秘密（ＥＣＤＳＡ）楕円曲線デジタル署名アルゴリズム鍵組の公開部分における、１６０ビットハッシュ値である。各ビットコインアドレスの秘密鍵は、当該アドレスの所有者のクライアントウォレットに格納される。

クライアントウォレット同士は、インターネットを介して接続され、トランザクションを仲介、検証するトランザクションネットワークのノードを形成する。公開／秘密鍵暗号化を使用すれば、自身のビットコインアドレスに記録された金額のビットコインを、別のビットコインアドレスに送金するための「署名」（即ち、自身の秘密鍵を使用）を実行できる。通常、秘密鍵によりトランザクションが署名されると、トランザクションネットワーク上の誰もが、署名が有効であるか検証できる。更に、トランザクションネットワーク上の誰もが、台帳を確認してトランザクションが有効か、即ち、ビットコインの送り主が、送金額を実際に所有しているかを判断できる。

２００８年以降、様々なビットコイン以外の暗号型電子通貨が開発されており、それらはまとめてオルトコインと呼ばれる。その中で、独特な暗号化ハッシュアルゴリズムを使うもの（例えばＬｉｔｅコイン）、及び／又は追加機能を有するものや（例えば、Ｃｉｎｎｉコイン）、独特な署名技術を使うもの（例えば、ＣｒｙｐｔｏＮｏｔｅ）が開発されている。

ビットコインが偽名性を伴う一方、オルトコインは全て偽名性又は匿名性を伴う。匿名性を伴う暗号通貨の場合、金銭トランザクションにおける送り主、受取先の全てを追跡することが不可能であるため、マネーロンダリングに使われやすい。

偽名性を伴う暗号通貨に関して、実際の商品、サービスの購入で使用されるビットコインアドレスのパターンを分析することで、施設同士のやり取りの証拠が特定可能であることを示す学術研究が発表された（Ｍｅｉｋｌｅｊｏｈｎ Ｓ，ｅｔ ａｌ． Ｕｎｉｖｅｒｓｉｔｙ ｏｆ Ｃａｌｉｆｏｒｎｉａ，Ｓａｎ Ｄｉｅｇｏ，２０１３）。

この手法は、施設レベルでの不正行為の特定には有効であるが、個人レベルにまで適用範囲を広げるには至っていない。近年、ビットコインアドレスをＩＰアドレスにマッピング可能であるとことを示す学術研究（Ｋｏｓｈｙ Ｐ，ｅｔ ａｌ． Ｐｅｎｎｓｙｌｖａｎｉａ Ｓｔａｔｅ Ｕｎｉｖｅｒｓｉｔｙ，２０１４）が発表された。しかし、この手法が適用できるのは、ビットコインアドレスの１割未満に過ぎない。したがって、ビットコインやオルトコインはマネーロンダリング等の不正行為に使用され得ると一般的に考えられている（Ｂｒｙａｎｓ Ｄ，Ｉｎｄｉａｎａ Ｌａｗ Ｊｏｕｒｎａｌ，８９（１）：４４１、２０１４）。

ビットコインやオルトコインはその偽名性、匿名性により、ハッカーや窃盗犯の格好の標的になってしまっている。例えば、２０１４年２月、当時世界最大のビットコイン取引所であったマウントゴックス社が、度重なるハッキング被害により、破綻手続きに追い込まれた。被害額は、８５０，０００ビットコイン（約４億８千万ＵＳドル）であった。

２０１５年１月、当時世界三位のビットコイン取引所であった、スロヴェニアのビットコイン取引所であるＢｉｔｓｔａｍｐが攻撃を受け、最低１９，０００ＢＴＣ（当時価格で五百万ＵＳドル）が盗まれた。盗んだビットコインは所有するビットコインアドレスに送金する必要があるが、事件に関わったハッカー／窃盗犯の多くの身元は不明である。

したがって、ビットコインの盗難防止ソリューションが求められている。ビットコインの所有権は、ユーザウォレットに格納された秘密鍵で保護されている。秘密鍵はパスフレーズから生成できる。例えば、ビットコインアドレスと、その秘密鍵をパスフレーズのＳＨＡ−２５６から生成するツールを提供するウェブサイトとして、Ｂｒａｉｎｗａｌｌｅｔを利用可能である。パスワード辞書を使えば、ビットコインブロックチェーンを分析して、一般的なパスワードから生成された有効なビットコインアドレスを探して、秘密鍵を取得し、使用することで当該アドレスからビットコインを盗むことができる。

一つの盗難防止対策として、典型的なパスフレーズを使用して生成されたビットコインアドレスの使用を避けることが挙げられる。別のビットコインアドレスについては、ハッカーはビットコイン所有者のコンピュータ又はサーバにハッキングをかけ、秘密鍵の記録を含むファイルを捜索する。当該ファイルが見つかると、そのアドレスに格納されたビットコインは、別のアドレスに容易に移転できる。簡単な対抗策として、そのようなファイルをコールドストレージ（即ち、インターネットに接続されていない装置）に保存するか、そもそもそのようなファイルを生成しないことが挙げられる。

ビットコインを盗む別の方法として、インターネットに接続されたコンピュータ又はサーバにインストールされたビットコインウォレット内のメインウォレットデータファイル（即ち、ｗａｌｌｅｔ．ｄａｔ．ｆｉｌｅ）を盗むことが挙げられる。ｗａｌｌｅｔ．ｄａｔ．ｆｉｌｅを盗むことができるオンラインバンキング型トロイの木馬についてＲｏｂｅｒｔ Ｌｉｐｏｖｓｋｙ（２０１３）で報告されている。秘密鍵は、ｗａｌｌｅｔ．ｄａｔ．ｆｉｌｅに格納され、パスフレーズで保護されている。メインウォレットデータファイルが盗まれると、辞書に基づく推測、辞書単語配列、又はとにかく力業にて保護用のパスフレーズが解読され得る。

そのようなビットコインウォレット盗難に対する対策の一つが、中国特許出願公開第１０３９２７６５６（Ａ）号「埋込式、固定収集アドレスを有するビットコイン端末ウォレット及びビットコイン端末ウォレットのビットコイン支払方法（Ｂｉｔｃｏｉｎ Ｔｅｒｍｉｎａｌ Ｗａｌｌｅｔ ｗｉｔｈ Ｅｍｂｅｄｄｅｄ， Ｆｉｘｅｄ Ｃｏｌｌｅｃｔｉｎｇ Ａｄｄｒｅｓｓ ａｎｄ Ｂｉｔｃｏｉｎ Ｐａｙｍｅｎｔ Ｍｅｔｈｏｄ ｏｆ Ｂｉｔｃｏｉｎ Ｔｅｒｍｉｎａｌ Ｗａｌｌｅｔ）」に記載されている。

上記問題に対するシンプルな対策の一つとして、ビットコインを多署名アドレスに格納することが挙げられる。これは、ビットコインを使うために、２つの秘密鍵が求められる通貨アドレスである。一方の秘密鍵は、コンピューティングデバイス（例えば、ローカルコンピュータ）に格納され、他方の鍵が別のコンピューティングデバイス（例えば、スマートフォン、リモートサーバ）に格納される。これにより、トランザクションの二要素認証が実現される。このようなソリューションは本発明の前に存在しなかった。

別の対策としては、ビットコインの送り主及び受取先を全て特定可能にすることが挙げられる。この場合、盗まれたビットコインを受け取ったビットコインアドレスの所有者の法的身分を確認することで、窃盗犯又はハッカーの身分が特定できる。この方策は、本発明の前に存在しなかった。

現在、ビットコインに対する、ＡＭＬ（アンチマネーロンダリング）ソリューションが大いに望まれている。現在、ビットコインサービス提供企業は、ＫＹＣ（顧客確認）及びトランザクションモニタリングの組み合わせにより、ＡＭＬにおける米国（ＦｉｎＣＥＮ）及び世界的規制に準拠可能となっている。即ち、全てのトレーダ／顧客は、自身の法的身分を提供して、認証される必要がある。但し、この方策は、２つの大きな問題がある。第１に、この方策を利用するのは、主に合法的なサービスを提供する企業である。したがって、これによって世界規模のビットコインに関するＡＭＬがなくなることはないと考えられる。第２に、企業は通常、独自の顧客登録、個人認証システムを有する。

これは、冗長資源や高いビジネスランニングコストにつながるのみならず、ビットコインユーザにとっての煩わしさが増す。即ち、誠実なビットコインユーザは、異なるビットコインサービス提供企業に対して、そのサービス利用前に、身分証明のために毎回身分証明書を提出する必要があり得る。

２０１５年２月２５日、イングランド銀行は、「ワンバンクリサーチアジェンダ」を公表した。当銀行で革新的な調査研究を行うという、野心的且つ広範囲の枠組みである。この討議論文によると、イングランド銀行は、中央銀行が、ビットコインのブロックチェーン技術を利用して、独自のデジタル通貨を発行すべきかを調査している。イングランド銀行は、ＫＹＣ、ＡＭＬについての問題を解決し、プライバシー問題にも配慮しながら、デジタル身元管理を実現できるかを調査すべきであると述べている。

したがって、上述の問題を少なくとも部分的に解決できる、暗号型電子マネーのトランザクション監視及び規制のための個人／クライアント認証及び検証処理、偽名性システム、トランザクションネットワークを設計することは有用であろう。

本発明の「法的身分関連クレデンシャル検証プロトコル」は、ユーザのプライバシーを守りながら、暗号通貨盗難、ＫＹＣ、ＡＭＬに関する問題に対処する初の実践的ソリューションである。

最後に、非常に重要な点として、中央銀行又はその他金融機関が本発明を利用、修正して、台帳支払システムに対応し、且つ中央運営団体により規制され得る独自のデジタル通貨を発行できる。台帳は、公開されてもされなくてもよい。当該デジタル通貨は、現行の銀行業務システム及び暗号型電子マネーの利点を併せ持つことができる。

本発明の実施形態は、以下の態様として、まとめることができる。

１．登録インタフェース（１０２）として機能する少なくとも１つのコンピュータプログラムを含む計算サーバ（１０１）が実行する、暗号型電子マネーを伴うトランザクションのための個人／クライアント認証及び検証方法であって、
・１又は複数の潜在的又は既存の通貨ユーザ（１０３）に対して、アクセスを提供するステップと、
・認証を要するユーザアカウントを登録するために、１又は複数の潜在的通貨ユーザに対して登録インタフェース（１０２）を提供するステップ（１０４）と、
・登録者の法的身分証明のための文書提出をリクエストするステップ（１０５）と、
・登録者の法的身分を検証するステップ（１０６）と、
・法的身分が認証されなかった登録者のアカウント作成を拒否するステップ（１０７）と、
・法的身分が認証された、各認証登録者（１０９）に対して個人／クライアントアカウント（１０８）を作成するステップ（１１０）と、
・認証登録者（１０９）に、関連する認証を含むクレデンシャル（１１１）を生成可能とするステップ（１１２）と、
・クライアント情報データベース（１１５）に、提出された情報を全て格納するステップ（１１６）と、
・クレデンシャルを、中央認証サーバ（４０１）に送信（１１７）するステップと、
・各登録者の１以上の多署名通貨アドレス、クレデンシャル、法的身分をマッピングして格納（１１８）するステップとを含む、方法。

上記の方法は更に、以下のことを１又は複数任意で含んでもよい。
（ｉ）認証は、パスワード保護、二要素認証又は多要素認証により実現されてもよい。
（ｉｉ）クレデンシャル（１１４）を暗号化するステップ、及び／又は
（ｉｉｉ）クレデンシャルは、デジタルな、電子的、又はハードウェアによる存在であって、自己認証用の認証機構として使用可能である。例えば、クレデンシャルは、デジタルコード組（例えば名前とパスワード）、クライアントウォレットソフトウェアを作動させる固有プロダクトキー、携帯電話又は個人セキュアキー発生器等のユーザが所有する物理的装置に結び付けられた、定期的に変化するトークン（例えば、固有の７桁コード）であってもよい。

２．暗号型電子マネー（ＣＢＥＭ）（２０１）と関連するトランザクションネットワーク（２０２）を生成する方法は、ノードとして機能するコンピュータプログラムのネットワークにより事項されるものであって、方法は、
・スタンドアロンコンピュータプログラム、又はクライアントウォレット（１１１）の機能モジュールであってもよいノード（２０３）を、１又は複数のクライアントコンピュータ及び／又はサーバ（２０４）にインストールするステップと、
・全てのノードをつなげて、データ送信ネットワーク（２０６）を介して、ピアツーピアネットワークのリレーノード（２０５）を形成するステップと、
・少なくとも１つのＣＢＥＭの単位（２０７）を生成する方法を制御するステップと、
・少なくとも１つのＣＢＥＭの単位の所有権を、公開／秘密鍵暗号化（２０８）により保護するステップと、
・少なくとも１つのＣＢＥＭの単位の所有権を、所有者の通貨アドレス（３１３）を使用した、全てのトランザクションの台帳（例えば、ブロックチェーン）（２０９）に記録するステップ（２１０）と、
・少なくとも１つのＣＢＥＭの単位の所有権を検証するステップ（２１１）と、
・中央認証サーバ（４０１）の１つで、提出されたクレデンシャル（１１１）を検証することで、少なくとも１つのＣＢＥＭの単位を受信するための１又は複数の有効通貨アドレス（３１３）の生成を、有効登録ユーザ（１０９）のみに限定するステップ（２１２）と、
・少なくとも１つのＣＢＥＭの単位のトランザクションを、台帳（２０９）に記録するステップ（２１３）と、
・少なくとも１つのＣＢＥＭの単位のトランザクションを検証するステップ（２１４）と、
・少なくとも１つのＣＢＥＭの単位のトランザクションを行う方法を制御するステップ（２１５）と、
・トランザクション規則を、少なくとも１つのノードのプログラミングコードに組み込むステップ（２１６）と、
・送り主からの有効クレデンシャル（１１１）が必要であること、中央認証サーバ（４０１）の１つからの１又は複数の認証秘密鍵（４０６）が必要であることの内の少なくとも一方を含む、少なくとも１つのトランザクション承認規則（２１７）を限定するステップと、
・ｐａｙ−ｔｏ−ｓｃｒｉｐｔ−ｈａｓｈ形式又はその他対応する形式での多署名トランザクションのみの生成を許可するステップ（２１８）と、
・それぞれ、少なくとも２の秘密鍵を署名として要する、多署名トランザクションのみの生成を許可するステップ（２１９）と、
・有効クレデンシャル（１１１）の存在下で、多署名トランザクションのみの生成を許可するステップ（２２０）と、
・これら秘密鍵（２１９）の内の１つを、中央認証サーバの１つからの認証秘密鍵（４０６）に限定するステップ（２２１）と、
・残りの秘密鍵（２１９）を、暗号化されて１以上のクライアントウォレット（３０１）に格納されるクライアント秘密鍵（２２２）に限定するステップ（２２３）と、
・クライアントウォレット（３０１）からの全てのトランザクションリクエストを、中央認証サーバ（４０１）の１つに送り、トランザクションを署名するための認証秘密鍵を得るステップ（２２４）と、
・必要な秘密鍵（２１９）の内の任意の１つが不在のトランザクションを全て拒絶するステップ（２２５）とを含む、方法。

３．ユーザのクライアント装置として機能するコンピュータプログラムにより実行される、暗号型電子マネーを伴うトランザクションのための個人／クライアント認証及び検証方法であって、
・クライアント装置のコンピュータプログラムをクライアントウォレット（３０１）として機能するように、少なくとも１つのコンピュータ又は計算サーバ（３０２）にインストールするステップと、
・トランザクションネットワーク（２０２）で生成される、全てのＣＢＥＭ単位（例えばコイン）の情報をリレーする、リレーノード（２０５）の１つとして機能するステップ（３０３）と、トランザクションネットワーク（２０２）の全てのトランザクション情報をリレーする、リレーノード（２０５）の１つとして機能するステップ（３０４）と、
・トランザクションネットワーク（２０２）にブロードキャストされる全てのトランザクションを検証、確認するリレーノードの１つとして機能するステップ（３０５）と、
・全てのトランザクションの台帳（例えば、ブロックチェーン）（２０９）に、あらゆる新たなトランザクション情報を格納することに寄与することで、新たなコインを生成するステップ（３０６）と、
・コインの受取、送金のための、１又は複数の暗号化クライアント公開鍵（３０７）及びクライアント秘密鍵（３０８）組を生成するステップ（３０９）と、
・通貨ユーザにより生成された、１又は複数の通貨アドレスのクライアント公開―秘密鍵組（要素３０７，３０８）を格納するステップ（３１０）と、
・コインの受取、送金のための、通貨ユーザのクライアントウォレットとして機能するステップ（３１１）と、
・中央認証サーバ（４０１）の１つと、登録通貨ユーザ（１０９）との間の通信を行うためのクライアントウォレットとして機能するステップ（３１２）と、
・多署名アドレス（３１３）である通貨アドレスのみを生成するステップ（３１４）と、
・クライアント公開鍵（３０７）及び認証公開鍵（４０５）から、１又は複数の多署名アドレス（３１３）を生成するステップ（３１５）と、
・コインの送金及び受取のためのクライアントウォレット（３０１）に、１又は複数の多署名アドレス（３１３）のみを格納するステップ（３１６）と、
・１又は複数の多署名アドレス（３１３）をクライアント情報データベース（４０１）に送信して格納し、１以上のアドレスの所有者の法的身分へとマッピングするステップ（３１７）と、
・生成した有効多署名アドレス（３１３）を中央認証サーバ（４０１）に送信して格納するステップ（３１８）と、
・有効登録ユーザ（１０９）のクレデンシャル（１１１）を中央認証サーバの１つに提出して、１又は複数の有効多署名アドレス（３１３）を生成するための承認を得るステップ（３１９）と、
・有効登録ユーザ（１０９）のクレデンシャル（１１１）を中央認証サーバの１つに提出して、１又は複数の通貨アドレスへとコインを送金するための１又は複数の有効トランザクション（要素２１８、２１９、２２０、２２１、２２３）を生成するための承認を得るステップ（３２０）と、
・コインの受取、送金の両方のための、多署名アドレス（３１３）を使用するトランザクションのみを生成可能とするステップ（３２１）と、
・コインが送金された直後の通貨アドレスにおいて、ブロックチェーンに未使用分のコイン（全額使用されていない場合）を記録するステップ（３２２）とを含む、方法。

４．中央認証サーバ（４０１）として機能する計算サーバにおけるコンピュータプログラムにより実行される、暗号型電子マネーを伴うトランザクションのための個人／クライアント認証及び検証方法であって、
・有効クレデンシャルの存在下で、１又は複数の有効多署名通貨アドレス（３１３）を生成するために、クライアントウォレット（３０１）と通信（４０７）するステップと、
・１又は複数の多署名アドレス（３１３）を生成するために、認証公開鍵（４０５）を通貨ウォレットに提供（４０８）するステップと、
・有効クレデンシャルの存在下で、１又は複数の通貨アドレスにコインを送金するために、１又は複数の有効トランザクション（２１８、２１９、２２０、２２１、２２３）を生成するために、クライアントウォレット（３０１）と通信（４０９）するステップと、
・多署名アドレス（３１３）の生成に使用される認証公開鍵（４０５）に対応する認証秘密鍵（４０６）を提供（４１０）することで、１又は複数の有効トランザクション（２１８、２１９、２２０、２２１、２２３）に対するトランザクション入力に署名するステップと、
・１又は複数の有効トランザクション（４１２）に対して、トランザクション全体に署名するため、最新の秘密鍵（４１１）を提供するステップと、
・トランザクションデータベース（４１３）にトランザクション情報を格納（４１４）するステップとを含む、方法。

上述の方法のうちの任意のもの又は全ては、以下の特徴の１又は複数を有してもよい。

最新の認証秘密鍵（４１１）は、多署名アドレス（３１３）の生成に使用される認証公開鍵（４０５）に対応する認証秘密鍵、又はその他認証秘密鍵である。

トランザクションデータベース（４１３）にトランザクション情報を格納（４１４）するステップは、トランザクションＩＤ、送り主の通貨アドレス、受取先の通貨アドレス、コインの送金額、トランザクション時間、送り主及び受取先のクライアントウォレットのＩＰアドレスを格納することを含む。

方法は更に、中央認証サーバ（４０１）における１又は複数のトランザクション基準（５０１、５０２）に対してトランザクションを検証するステップを含む。

１又は複数のトランザクション基準（５０１、５０２）は、中央運営団体（６０１）及び／又は登録者が予め策定した基準を含む。

更に／或いは、方法は更に、送り主及び受取先の通貨アドレスを、トランザクションデータベース及びクライアント情報データベースに適宜マッピングすることで、送り主及び受取先の法的身分を追跡するステップを含む。

５．中央運営団体及びユーザのクライアント装置の装置として機能する、コンピュータプログラム群により実行される、暗号型電子マネーを伴うトランザクションのための個人／クライアント認証及び検証方法であって、
・多署名を定義する少なくとも二要素認証クレデンシャルを含む、登録者のクレデンシャルを受信するステップと、
・登録者の法的身分を認証するステップと、
・認証成功した法的身分（１１０）を有する各認証成功登録者（１０９）の、各登録者（１１８）の法的身分と通貨アドレスの多署名のマッピング、格納を容易にする、個人／クライアントアカウント（１０８）を生成するステップと、
・少なくとも１つの電子マネーの単位を含む登録者ウォレットを提供するステップと、
・登録者の通貨アドレス（３１３）を使用して、トランザクションデータベース（４１３）に少なくとも１つの電子マネーの単位の所有権を記録するステップと、
・それぞれ少なくとも２の秘密鍵を承認署名（２１９）として要する多署名トランザクションを、ｐａｙ−ｔｏ−ｓｃｒｉｐｔ−ｈａｓｈ形式又はその他対応する形式（２１８）で生成するステップと、
・これら秘密鍵（２１９）を、中央認証サーバ（２２１）の１つからの認証秘密鍵（４０６）に限定するステップと、
・残りの秘密鍵（２１９を、クライアントウォレット（３０１、２２３）に格納される登録者の秘密鍵（２２２）に限定するステップと、
・トランザクション（２２４）に署名するための認証秘密鍵を取得するため、クライアントウォレット（３０１）からトランザクションリクエストを中央認証サーバ（４０１）の少なくとも１に送信するステップと、
・承認トランザクションメッセージを、トランザクションネットワーク（２１４）における全てのリレーノードにブロードキャストするステップとを含む、方法。

６．暗号型電子マネーを伴うトランザクションのための個人／クライアント認証及び検証システムであって、
・クライアント登録リクエスト、クライアント暗号通貨アドレス、暗号通貨トランザクションを処理するために、第７態様の方法を実行するように構成された中央認証サーバ（４０１）と、
・中央認証サーバ（４０１）に通信可能に接続されたクライアント情報データベース（４０４）と、
・中央認証サーバ（４０１）に通信可能に接続されたトランザクションデータベース（４１３）と、
・少なくとも１つの電子マネーの単位を含む登録者ウォレット（４１６、４１７）が設けられた少なくとも１つのクライアント装置（４１４、４１５）とを有し、
・少なくとも１つのクライアント装置（４１４、４１５）は上記態様の任意の１又は複数の方法を実行するように構成された、システム。

７．上記態様の任意の１又は複数の、コンピュータ実行方法の全てのステップを実行するプログラムコード手段を含むコンピュータプログラムであって、当該プログラムはコンピュータ又は計算サーバ上で動作する、コンピュータプログラム。

８．コンピュータ又は計算サーバ上で実行されると、上記態様の任意の１又は複数の、コンピュータ実行方法の全てのステップを実行するコンピュータ実行可能命令を格納するコンピュータ可読媒体。

９．認証公開鍵（４０５）及び認証秘密鍵（４０６）の組は、一定期間で、手動又は自動で変更可能であることで、認証公開鍵及び認証秘密鍵が外部に漏洩することが防止される、上記態様の任意の１又は複数の方法。新たな認証鍵の組への変化の後、古い認証秘密鍵は、トランザクション入力（４１０）の署名に使用され、新たな認証鍵は、トランザクション全体の署名（即ち、全てのトランザクションのデータ）に使用される（４１２）。

１０．有効クレデンシャルを中央認証サーバ（４０１）の１つに提出して生成されなかったあらゆる通貨アドレスが無効であり、どのようなコインも受け取ることができない、上記態様の任意の１又は複数の方法。

１１．トランザクションネットワーク（２０２）は、中央トランザクション基準（５０１）又は中央認証サーバ（４０１）の１つに格納されたクライアントトランザクション基準（５０２）に準拠しないあらゆるトランザクションを拒否するように変形できる、上記態様の任意の１又は複数の方法。

以下のうち１又は複数のものが、上記態様の任意の１又は複数の方法に追加できる。

有効登録ユーザは、自身のトランザクションを制限するためのクライアントトランザクション基準（５０２）を策定できる。

中央運営団体（６０１）は、トランザクション基準（５０１）策定することで、マネーロンダリング等の不正行為に関与する可能性のある疑わしいトランザクションを停止できる。

各トランザクションは、マネーロンダリング等の不正行為に関与する可能性のある疑わしいトランザクションを特定、記録、報告する、所定の規則により監視できる。

各通貨アドレスの所有者の法的身分がクライアント情報データベースに格納される。不正行為の疑いがあるトランザクションについては、送り主及び受取先の通貨アドレスの追跡により、関連する送り主及び受取先の身元がクライアント情報データベース抽出される。その後、疑わしい活動及び関連するクライアント情報が、関連する国の法律、規則に応じて、政府機関に報告される。

各通貨アドレスの所有者の法的身分が、クライアント情報データベースに格納される。これにより、「顧客確認」規制要件が満たされる。システムが商業活動における支払システムとして利用可能となる。

各通貨アドレスの所有者の法的身分が、クライアント情報データベースに格納される。但し、当該情報は誰にでもアクセスできるものではないため、暗号型電子マネー（２０１）及びそのトランザクションネットワーク（２０２）の匿名性が保たれる。

ユーザは、自身のクレデンシャル（１１１）を変更して、自身の通貨ウォレット（３０１）の盗まれたメインデータファイル（例えばウォレット、ｄａｔファイル）からの、コインの出金を止めることができる。

（ｉ）各通貨アドレスの所有者の法的身分が、クライアント情報データベースに格納され、（ｉｉ）有効クレデンシャルを中央認証サーバ（４０１）の１つに提出して生成されなかったあらゆる通貨アドレスが無効であり、どのようなコインも受け取ることができず（態様１８）、（ｉｉｉ）有効登録ユーザのみが有効クレデンシャル（１１２）を有する。コインが盗まれると、１以上の受取先の１以上の通貨アドレスに応じて、クライアント情報データベースから１以上の受取先の１以上の法的身分を読み出すことで、容易にコインを盗んだ１以上の窃盗犯又は１以上のハッカーを追跡できる。このように、この形態の上記１以上の方法は、暗号通貨の盗難を防止する。

（ｉｉ）有効登録ユーザが所有するコインの金額は、トランザクションデータベース（４１３）内のトランザクション記録を分析することで、中央運営団体（６０１）により完全かつ容易に捜索、追跡可能である。各通貨アドレスをその所有者に結び付ける機能とは別に設けられたこの固有の特性は、コインが送金／支払われた直後の通貨アドレスにおける未使用分のコイン（全額使用されていない場合）を記録することに基づく（３２２）。この固有の特性は、システムを、特に第三者の監査の下に実現される金融、銀行業務に適用可能にするものである。

（ｉｉｉ）ユーザのプライバシーを守りながら、暗号通貨盗難、ＫＹＣ、ＡＭＬに関する問題に対する実践的ソリューションを提供する。

（ｉｖ）更に／或いは、中央銀行又はその他金融機関が本発明を利用、修正して、分散型台帳支払システムに対応し、且つ中央運営団体により規制され得る独自のデジタル通貨を発行可能とするために利用可能である。

更に、全ての金銭トランザクションにおける送り主及び受取先の法的身分が追跡可能な、新たな暗号型電子マネー又は暗号通貨を生成するシステムを伴う方法が開示される。方法は、以下の要素を有するシステムにより実行可能である。

１．少なくとも１つのサーバ及び少なくとも１つのウェブ登録インタフェース。少なくともつ１つのサーバは以下の機能のうちの少なくとも一部又は全部を実行する。
・１又は複数の潜在的又は既存の通貨ユーザ（１０３）に対して、アクセスを提供する
・パスワード保護、二要素認証又は多要素認証によりユーザアカウントを登録するために、１又は複数の潜在的通貨ユーザに対してオンラインインタフェースを提供する
・登録者の法的身分証明のための文書提出をリクエストする
・登録者の法的身分を検証する
・法的身分が認証されなかった登録者のアカウント作成を拒否する
・法的身分が認証された、各認証登録者に対して個人／クライアントアカウントを作成する
・認証登録者に、ラベルとパスワードを含むクレデンシャルを生成可能とする
・認証登録者に、クレデンシャルと連絡先情報を変更可能とする
・クレデンシャルを暗号化する
・全ての提出された情報、特に法的身分及び暗号化クレデンシャルを、クライアント情報データベースに格納する
・新たに作成された又は変更された暗号化クレデンシャルを中央認証サーバに送る
・各登録者の１以上の多署名通貨アドレス、クレデンシャル、法的身分をマッピングして格納する。

１つの暗号型電子マネーと関連するトランザクションネットワークは、以下の基本機能及び独自機能の内の少なくとも一部又は全部を実行する。

１．基本機能（全てのその他の暗号型電子マネーと共通）
・クライアントウォレットソフトウェアを公開する
・コンピュータ又はサーバを、クライアントウォレットを介して接続する
・接続されたコンピュータ又はサーバを利用して、トランザクションネットワークのリレーノードを生成する
・所定金額の金銭単位（コインを）、所定の速度で生成する
・コインの所有権を、公開／秘密鍵暗号化で保護する
・コインの所有権を、所有者の通貨アドレスを利用して、全てのトランザクションの台帳（例えば、ブロックチェーン）に記録する
・全てのトランザクションの台帳（例えば、ブロックチェーン）及びその更新を、クライアントウォレットを介してトランザクションネットワークに接続された人々に配信する
・秘密鍵所有者に、所要のトランザクション費用の低減後の、対応する通貨アドレスに記録されたコインの金額を超えないコインの金額のみを送金可能とする
・全ての新規トランザクションメッセージを、トランザクションネットワークにおける全てのリレーノードにブロードキャストする
・全ての新規トランザクションメッセージを、各リレーノードで検証する
・トランザクション情報（送り主通貨アドレス、受取先通貨アドレス、取引されるコインの金額、トランザクション費用、トランザクション時間を含むがこれらに限定されない）を、全てのトランザクションの台帳（例えば、ブロックチェーン）に記録する。

２．独自機能
・中央認証サーバの１つで、提出されたクレデンシャルを検証することで、コインを受け取るための１又は複数の有効通貨アドレスの生成を、有効登録ユーザのみに限定する
・ｐａｙ−ｔｏ−ｓｃｒｉｐｔ−ｈａｓｈ形式又はその他対応する形式での多署名トランザクションのみの生成を許可する
・それぞれ、少なくとも２の秘密鍵を署名として要する、多署名トランザクションのみの生成を許可する
・有効クレデンシャルの存在下で、多署名トランザクションのみの生成を許可する
・これら秘密鍵のうちの１つを、中央認証サーバの１つからの認証秘密鍵に限定する
・残りの秘密鍵を、暗号化されて１以上のクライアントウォレットに格納されるクライアント秘密鍵に限定する
・クライアントウォレットからの全てのトランザクションリクエストを、中央認証サーバの１つに送り、トランザクションを署名するための認証秘密鍵を得る
・必要な秘密鍵の内の任意の１つが不在のトランザクションを全て拒絶する
・「ｐａｙ−ｔｏ−ｓｃｒｉｐｔ−ｈａｓｈ」スクリプト又は電子マネーのソースにトランザクション生成用の唯一のスクリプトとして組み込まれたその他対応スクリプトを使用することで、各トランザクションに対して、トランザクション承認規則を限定する（トランザクション入力及びトランザクション全体の署名のために、送り主からの有効クレデンシャルが必要であること、中央認証サーバの１つからの１又は複数の認証秘密鍵が必要であることを含むがこれらに限定されない）。

クライアントウォレットソフトウェアを実行する少なくとも１つのコンピュータ又はサーバであって、少なくとも１つのクライアントウォレットは以下の基本機能及び独自機能の内の少なくとも一部又は全部を実行する。

１．基本機能（全てのその他の暗号型電子マネーと共通）
・トランザクションネットワークにおいて、全てのトランザクション情報をリレーする、リレーノードの１つとして機能する
・トランザクションネットワークにブロードキャストされる全てのトランザクションを検証、確認するリレーノードの１つとして機能する
・全てのトランザクションの台帳（例えば、ブロックチェーン）に、あらゆる新たなトランザクション情報を格納することに寄与することで、新たなコインを生成する
・コインの受取、送金のための、１又は複数の暗号化クライアント公開鍵及びクライアント秘密鍵組を生成する
・通貨ユーザにより生成された、１又は複数の通貨アドレスのクライアント公開―秘密鍵組を格納する
・コインの受取、送金のための、通貨ユーザのクライアントウォレットとして機能する。

２．独自機能
・中央認証サーバの１つと、登録通貨ユーザとの間の通信を行うためのクライアントウォレットとして機能する
・多署名アドレスである通貨アドレスのみを生成する
・クライアント公開鍵及び認証公開鍵から、１又は複数の多署名アドレスを生成する
・コインの送金及び受取のためのクライアントウォレットに、１又は複数の多署名アドレスのみを格納する
・１又は複数の多署名アドレスをクライアント情報データベースに送信して格納し、１以上のアドレスの所有者の法的身分へとマッピングする
・生成した有効多署名アドレスを中央認証サーバに送信して格納する
・有効登録ユーザのクレデンシャルを中央認証サーバの１つに提出して、１又は複数の有効通貨多署名アドレスを生成するための承認を得る
・有効登録ユーザのクレデンシャルを中央認証サーバの１つに提出して、１又は複数の通貨アドレスへとコインを送金するための１又は複数の有効トランザクションを生成するための承認を得る
・コインの受取、送金の両方のための、多署名アドレスを使用するトランザクションのみを生成可能とする
・コインが送金された直後の通貨アドレスにおいて、ブロックチェーンに未使用分のコイン（全額使用されていない場合）を記録する。

少なくとも１つの中央認証サーバは、以下の機能の少なくとも一部又は全部を実行する。中央サーバは、トランザクション（３１１）の許可を得るためのクライアントリクエストを受信すると、ＡＭＬ（アンチマネーロンダリング）基準に関するリスクに関して、トランザクションを調査して、トランザクション許可を遅延する、所定時間、トランザクションに許可を与えるのを遅延する、中央サーバからの警告を、ネットワークを介して、政府機関、リスクコンプライアンス責任者、クライアント、中央サーバが運営するシステムに関連する個人の内の少なくとも１つに関連する電子装置に送信することのうちの少なくとも１つを実行するように構成される。

いくつかの実施形態において、中央認証サーバは、以下の動作の一部又は全部を実行するように構成される。

１．クライアント情報データベースから、新規の又は更新されたクレデンシャル及びそれに関連した通貨アドレスを読み出す
２．ユーザのクレデンシャル及びそれに関連した通貨アドレスを中央認証サーバに格納して更新する
３．認証公開鍵と認証秘密鍵の１又は複数の組を、生成、変更、暗号化及び格納する
４．有効クレデンシャルの存在下で、１又は複数の有効多署名通貨アドレスを生成するように、クライアントウォレットと通信する
５．１又は複数の多署名アドレスを生成するために、認証公開鍵を通貨ウォレットに提供する
６．有効クレデンシャルの存在下で、１又は複数の通貨アドレスにコインを送金するため、１又は複数の有効トランザクションを生成するように、クライアントウォレットを通信する
７．多署名アドレスの生成に使用する認証公開鍵に対応する認証秘密鍵を提供することで、１又は複数の有効トランザクションに対するトランザクション入力に署名する
８．１又は複数の有効トランザクションのトランザクション全体に署名するために、要素４１０で使用される認証秘密鍵又は最新の認証秘密鍵であり得る、別の認証秘密鍵を提供する
９．全てのトランザクション情報（トランザクションＩＤ、送り主通貨アドレス、受取先通貨アドレス、コインの支払い金額、トランザクション費用、トランザクション時間、送り主及び受取先のクライアントウォレットのＩＰアドレスを含むがこれに限定されない）をトランザクションデータベースに格納する。

更に、暗号型電子マネーを伴うトランザクションのための個人／クライアント認証及び検証方法が開示される。方法は、以下のステップのうちの少なくとも１又は全てを含む。

１．登録者の法的身分を検証するステップ
２．認証成功した法的身分を有する各認証成功登録者の、各登録者の法的身分と１以上の通貨アドレスのマッピング及び格納を容易にする、少なくとも二要素認証で保護された個人／クライアントアカウントを生成するステップ
３．各認証成功登録者の、登録者の身元、通貨アドレスの所有権、トランザクションの送り主身元を定義するクレデンシャルを受信するステップ
４．１又は複数の中央認証サーバに、登録者の法的身分とクレデンシャルを格納するステップ
５．少なくとも１つの電子マネーの単位を送金及び受取るための登録者ウォレットを提供するステップ
６．１以上の登録者の通貨アドレスを使用して、全てのトランザクションの台帳（例えば、ブロックチェーン）に、少なくとも１つの電子マネーの単位の所有者を記録するステップ
７．通貨アドレス生成のリクエストに対して、登録者ウォレットから提出されたクレデンシャルを、中央認証サーバで受信、検証するステップ
８．中央認証サーバからの認証公開鍵を登録者ウォレットに提供することで、登録者に属する有効通貨アドレスとして多署名アドレスの生成を許可するステップ
９．登録者ウォレットにおいて、登録者の公開鍵と中央認証サーバの認証公開鍵を組み合わせることで、少なくとも１つの電子マネーの単位を受け取るための有効通貨アドレスを生成するステップ
１０．クライアント情報データベースにおいて、登録者の法的身分、クレデンシャル、１又は複数の有効通貨アドレスを格納及びマッピングするステップ
１１．それぞれ少なくとも２の秘密鍵を登録者ウォレットにおける署名として要する、「ｐａｙ−ｔｏ−ｓｃｒｉｐｔ−ｈａｓｈ」形式又はその他任意の対応形式のトランザクションを生成するステップ
１２．これら秘密鍵の内の少なくとも１つを中央認証サーバの１つからの認証秘密鍵に限定するステップ
１３．残りの秘密鍵を、クライアントウォレットに格納された登録者の秘密鍵に限定するステップ
１４．「ｐａｙ−ｔｏ−ｓｃｒｉｐｔ−ｈａｓｈ」スクリプト又は電子マネーのソースにトランザクション生成用の唯一のスクリプトとして組み込まれたその他対応スクリプトを使用することで、各トランザクションに対して、トランザクション承認規則を限定する（トランザクション入力及びトランザクション全体の署名のために、送り主からの有効クレデンシャルが必要であること、中央認証サーバの１つからの１又は複数の認証秘密鍵が必要であることを含むがこれらに限定されない）ステップ
１５．トランザクション生成のリクエストに対して、登録者ウォレットから提出されたクレデンシャルを、中央認証サーバで受信、検証するステップ
１６．中央認証サーバにおいて、１又は複数のトランザクション基準（中央運営団体及び／又は登録者により予め策定されたものを含むが、これに限定されない）に対して、トランザクションを検証するステップ
１７．１以上の登録者ウォレットにおける１又は複数の秘密鍵によりトランザクションに署名し、中央認証サーバにおける１又は複数の認証秘密鍵によりトランザクションに署名することで、トランザクションの実行を許可するステップ
１８．トランザクションメッセージを、全てのトランザクションの台帳（例えば、ブロックチェーン）に記録するステップ
１９．トランザクション情報（トランザクションＩＤ、送り主及び受取先の暗号通貨アドレス、取引されるコインの金額、トランザクション時間、送り主及び受取先のクライアントウォレットのＩＰアドレスを含むがこれらに限定されない）を、トランザクションデータベースに格納するステップ
２０．署名されたトランザクションメッセージを、トランザクションネットワークにおける全てのリレーノードに、確認のためブロードキャストするステップ
２１．送り主及び受取先の通貨アドレスを、トランザクションデータベース及びクライアント情報データベースに適宜マッピングすることで、送り主及び受取先の法的身分を追跡するステップ。

本明細書に記載のシステム及び方法は、以下のうちの任意の１又は複数のように変形される。

本明細書に記載のシステム及び方法は、トランザクションを許可するため、１又は複数の独立した中央運営団体からの２以上の認証秘密鍵を必要とするように変形されてもよい。このように変形された電子マネー及び関連した支払ネットワークは、より規制、管理が厳格となる。

或いは、本明細書に記載のシステム及び方法は、トランザクションを許可するため、中央運営団体からの認証秘密鍵を一切必要とせず、電子マネーを受け取り、出金のため、単一のユーザのみが署名する単一署名アドレス又は２以上のユーザにより署名される多署名アドレスを使用するように変形されてもよい。

中央サーバから承認を得るために多署名処理を利用する以外の選択肢として、１以上の中央サーバの機能と同じ機能の一部又は全部を、当該機能のうちの任意のもの又は全てを「スマートコントラクト」に設けることで実行してもよい。スマートコントラクトは、ＣＢＥＭの転送が許可されるには、所与の入力又は条件の成立が求められるコンピュータ命令の集合である。したがって、１以上の中央サーバにより実行されるコンピュータコードと実質的に同等のものが、中央サーバ機能又は機能を、トランザクションメッセージとブロックチェーン又は分散型台帳へのトランザクションの記録との間の任意の点に設けられることで実行される。スマートコントラクトは、契約条件を実行するためのコンピュータプログラム又はアプリケーションであってもよい。例えば、スマートコントラクトは、実行、暗号化、人又はエンティティ間の合意の実行に関する所定の機能を含んでもよい。スマートコントラクトは、記載の条件の成立に対して、金融又はその他義務の実行のための決済システムであってもよい。当該条件は、ＣＢＥＭ、検証文書、金融手段、法的手段、又はその他データ等のデータの転送を含んでもよい。

本明細書に記載のシステム及び方法は、トランザクションの許可にユーザからの秘密鍵を一切必要とせず、電子マネーを受け取り、出金のため、中央運営団体のみが署名する単一署名アドレス、又は２以上の中央運営団体により署名される多署名アドレスを使用するように変形してもよい。但し、ユーザの、自身の電子マネーの所有権に対する保護が少なくなり得る。当該変形した電子マネー及び関連した支払ネットワークの有効性は、１以上の中央運営団体の信用、誠実さに依存し得る。

上述のシステム及び方法は、以下の好ましい特徴のうちの少なくとも一部、又は全部を有してもよい。

例えば、所与の時間内に、条件又は特定の条件が満たされない場合、システム及び／又はユーザにより、トランザクションが逆転されてもよい。

トランザクションを台帳に記録する前に、保留時間が存在してもよい。当該保留は、自動で実行されてもよく、トランザクション及び／又はその他要素の基づいてもよく、１以上のトランザクション量の増加及び／又はその他要素の存在に応じて延長されてもよい。

システムは、潜在的なトランザクション及び／又は実際のトランザクションを、ＡＭＬ及び／又はその他金融コンプライアンス又はリスクに対して、例えば保留時間中に検査してもよい。

システムは、１又は複数の予め策定された基準又は標準に対する比較により、疑わしいとみなされたあらゆるトランザクションを特定し、自動的に保留、停止、及び／又は逆転してもよい。

当該予め策定された基準又は標準は、ＡＭＬ、ＫＹＣ、ＣＴＦ、ＢＳＡ、ＦＡＴＦ及び／又はその他政府、政府間、及び／又はエンティティの、１以上の疑わしい金融トランザクションベースに関する基準を含んでもよい。

ユーザ、第三者配達サービス等の第三者、及び／又はその他入力の内の任意の１又は複数のものからの、システム保留通知に応じて、上記保留が実行されてもよい。

トランザクションに対する保留、及び／又は逆転は、システムから受信された、及び／又は判定されたリスクスコア（例えば、コンプライアンスアルゴリズムに基づく）が所定の閾値以上となることに基づいてもよい。当該リスクスコアは、リスクのある及び／又は違法なソースからの及び／又はへの資金の内の１又は複数に関連付けられた、リスクを含む疑わしい金融トランザクション規則群に基づいて計算されてもよい。当該ソースは、システムに格納された、認証済みの個人身元を１又は複数のリストに基づいて、相互検証することによるデータにより判定される。例えば、当該リストは、公開されたテロリスト及び／又はテロの容疑者、公開されたマネーロンダリング業者及び／又はマネーロンダリングの容疑がある業者、公開された金融犯罪者及び／又は金融犯罪容疑者、暗号通貨窃盗犯リスト、サイバー犯罪関与リスト、ＦＡＴＦブラックリスト及び／又はＦＡＴＦリスク基準、搭乗拒否リスト、トランザクションロンダリングインジケーター、及び／又はその他コンプライアンス要素に基づくものであってもよい。

システムへのユーザ登録時、ＩＰアドレスの更新等のシステムにおける任意のユーザプロファイルに対するユーザ更新、有効通貨アドレス生成時、任意のトランザクション提示時、ユーザのトランザクション開始時、及び／又は定期的に、システムは単独で又は本明細書に記載のその他監視と協働で、ユーザ及び／又は受取先及び／又はユーザ及び／又は受取先の情報を、ＩＰアドレスリストに対して確認してもよい。

システムは、例えば上述のコンプライアンス要素及び／又はその他要素に基づいて、トランザクション受取先のアカウント等のユーザアカウントを凍結してもよい。

システムは、ＩＰアドレスの所在地に基づいて、及び／又はシステムにおけるユーザ又は受取先のプロファイルの場所に基づいて、制裁リスト及び／又は禁輸リストの国の受取先及び／又はユーザのあらゆるトランザクションを停止、及び／又は逆転してもよい。

上述の任意のステップ、及び／又はその他金融犯罪検出ステップの一部として、システムは更にユーザの疑わしい活動を監視してもよい。例えば、ユーザのウェブブラウジング履歴における疑わしいウェブ上活動を監視してもよい。当該活動は、例えば、公開されたテロリスト、及び／又はテロ容疑者のウェブサイト閲覧が挙げられる。

システムは、疑わしい活動の検出、及び／又は監視に加えて、当該疑わしい活動の検出に応じて、警告を発してもよい。当該警告は、コンピュータモニタ等のユーザインタフェース上に表示される、音声警告、及び／又はその他警告であって、好ましくは中央サーバ及び／又はシステムに関連した個人に送られ、任意でその他任意のユーザにも送られる。好ましくは、当該ユーザは、偽装トランザクションに関わってしまった無罪のユーザ等の、犯罪に関与していない（疑わしくない）１又は複数のユーザに限られる。

システムは、上述の警告の代わりに及び／又は加えて、更に／或いはあらゆる潜在的トランザクション、更に／或いは潜在的受取先、更に／或いは潜在的トランザクションにおけるその他団体、上述の種類のリスクスコアを提供してもよい。

システムは、典型的な多署名チャネルを介して、システムと通信するウォレットを使用して、トランザクションへの署名のリクエスト及び／又はトランザクションを署名した又はしていないユーザからのトランザクションへの署名のリクエストに応答してもよい。

システムは、ユーザからのトランザクションへの署名のリクエストを受信し、所与の条件が満たされるまで署名をしないことで、トランザクションを保留してもよく、更に／或いはトランザクションが金融犯罪に関わるリスクの閾値量及び／又は閾値種類により、トランザクションに署名しなくてもよい。

システムは、トランザクションへのユーザ署名等の潜在的トランザクションに応じて、その本明細書に記載の任意の活動を実行してもよい。

システムは、例えば疑わしいトランザクション及び／又は疑わしいユーザをシステムが検出により実行されるＳＡＲ及び／又はＳＴＲ及び／又はその他所要の報告のための、ＳＡＲ、ＳＴＲ及び／又は関連報告対応ソフトウェアを含んでもよい。

ユーザは、システムにおいて、オンライン及び／又はオフラインウォレットを使用してもよい。

好ましくは、認証公開鍵及び認証秘密鍵の組は、一定期間で、手動又は自動で変更可能であることで、認証公開鍵及び認証秘密鍵が外部に漏洩することが防止される。新たな認証鍵の組への変化の後、古い認証秘密鍵は、トランザクション入力の署名に使用され、新たな認証鍵は、トランザクション全体の署名（即ち、全てのトランザクションのデータ）に使用される。

好ましくは、有効クレデンシャルを中央認証サーバの１つに提出して生成されなかったあらゆる通貨アドレスが無効であり、どのようなコインも受け取ることができない。

好ましくは、トランザクションネットワークは、中央認証サーバの１つに格納された中央トランザクション基準に準拠しないあらゆるトランザクションを拒否するように変形できる。

好ましくは、有効登録ユーザは、自身のトランザクションを制限するためのクライアントトランザクション基準を策定できる。

好ましくは、中央運営団体が、マネーロンダリング等の不正行為に関与する可能性の高い疑わしいトランザクションを停止するため、トランザクション基準を策定できる。

好ましくは、各トランザクションは、マネーロンダリング等の不正行為に関与する可能性のある疑わしいトランザクションを特定、記録、報告する、所定の規則により監視できる。

好ましくは、各通貨アドレスの所有者の法的身分が、クライアント情報データベースに格納される。不正行為の疑いがあるトランザクションについては、送り主及び受取先の通貨アドレスの追跡により、関連する送り主及び受取先の身元がクライアント情報データベース抽出される。その後、疑わしい活動及び関連するクライアント情報が、関連する国の法律、規則に応じて、政府機関に報告される。

好ましくは、各通貨アドレスの所有者の法的身分が、クライアント情報データベースに格納される。これにより、「顧客確認」規制要件が満たされる。システムが商業活動における支払システムとして利用可能となる。

好ましくは、各通貨アドレスの所有者の法的身分が、クライアント情報データベースに格納される。但し、当該情報は誰にでもアクセスできるものではないため、暗号型電子マネー及びそのトランザクションネットワークの匿名性が保たれる。

好ましくは、自身のクレデンシャルを変更して、自身の通貨ウォレット（３０１）の盗まれたメインデータファイル（例えばｗａｌｌｅｔ．ｄａｔ．ｆｉｌｅ）からの、コインの出金を止めることができる。好ましくは、（ｉ）各通貨アドレスの所有者の法的身分が、クライアント情報データベースに格納され、（ｉｉ）有効クレデンシャルを中央認証サーバの１つに提出して生成されなかったあらゆる通貨アドレス無効であり、どのようなコインも受け取ることができない。有効登録ユーザのみが有効クレデンシャル（１１２）を有する。コインが盗まれると、１以上の受取先の１以上の通貨アドレスに応じて、クライアント情報データベースから１以上の受取先の１以上の法的身分を読み出すことで、容易にコインを盗んだ１以上の窃盗犯又は１以上のハッカーを追跡できる。このように、この形態のシステムは、暗号通貨の盗難を防止する。

有効登録ユーザが所有するコインの金額は、トランザクションデータベース内のトランザクション記録を分析することで、中央運営団体により完全かつ容易に捜索、追跡可能である。各通貨アドレスをその所有者に結び付ける機能とは別に設けられたこの固有の特性は、コインが送金／支払われた直後の通貨アドレスにおける未使用分のコイン（全額使用されていない場合）を記録することに基づく。この固有の特性により、このシステムが、特に第三者により監査を要する金融及び銀行業務に適用可能となっている。

好ましくは、システムはユーザのプライバシーを守りながら、暗号通貨盗難、ＫＹＣ、ＡＭＬに関する問題に対する実践的ソリューションを提供する。

好ましくは、中央銀行又はその他金融機関がシステムを利用、修正して、分散型台帳支払システムに対応し、且つ中央運営団体により規制され得る独自のデジタル通貨を発行可能とする。

本明細書に記載の、上記及びその他本発明の目的は、個人／クライアント認証及び検証システム及び方法を適用することで達成される。本発明の更なる詳細及び特徴、その特性更に各種利点が、以下の図に示される好ましい実施形態の詳細な説明により、明らかになろう。

図１は、暗号型電子マネーの新規ユーザの法的身分を取得、検証、格納する登録及びデータベースを示す。 図２は、暗号型電子マネーを送受信するための多署名通貨アドレスを生成するための、法的身分関連クレデンシャル認証システムを示す。 図３は、ユーザが所有し、多署名アドレスに記録されたコインの金額の支払いトランザクションを発行するための、法的身分関連クレデンシャル認証システム及び２団体署名方式を示す。 図４は、本発明に関わるシステムの図である。 図５は、は、リスク要因に基づく、トランザクションの保留及び／又は逆転を示す例示的フローチャートである。 図６は、リスク評価モジュールの要素を示すフローチャートである。 図７は、は、スマートコントラクトを使用した、１又は複数の実施形態の変形例のシステムを示す図である。

表記法及び用語
以下の詳細な説明は、コンピュータメモリで実行可能なデータビットに対する動作の、データ処理手順、ステップ、又はその他象徴的表象で表される。したがって、コンピュータは、物理量の物理的操作を要する論理ステップを実行する。

通常、当該物理量は、コンピュータシステムにおいて記憶、転送、結合、比較、又はその他操作が可能な、電気又は磁気信号の形態をとる。一般的な使用のために、これらの信号はビット、パケット、メッセージ、値、要素、記号、文字、用語、数字等と称される。

更に、これらの用語及び類似の用語は適切な物理量と関連付けられ、これらの量に適用される便宜上の標示に過ぎない。「処理する」、「作成する」、「転送する」、「実行する」、「判定する」、「検出する」、「取得する」、「選択する」、「計算する」、「生成する」等の用語は、コンピュータのレジスタ及びメモリ内の物理的（電子的）量として表現されているデータを操作し、当該メモリ、レジスタ、又はその他の同様の情報記憶部内の物理量と同様に表現されている別のデータへと変換するコンピュータシステムの動作及び処理を指す。

本明細書で言及するようなコンピュータ可読（記憶）媒体は、通常、非一時的であり、更に／又は非一時的装置を備える。これに関連して、非一時的ストレージ媒体は有形であり得る装置を備えてもよく、即ち、当該装置はその物理的状態が変化することはあるものの、具体的な物理形態を有する。このように、例えば、非一時的とは、装置の状態変化があっても有形であり続けることを指す。

本明細書において使用される「例」という語は、限定的ではない例、実例、例示を表すことを意味する。本明細書において使用される、「例えば」、「等」という語は、１又は複数の限定的ではない例、実例、例示のリストを導入する。

本発明は、オルトコイン等の暗号型電子マネー（ＣＢＥＭ）及びトランザクションシステムの技術分野に関する。より具体的には、本発明は、新たなＣＢＥＭを作成する方法とシステム、及びそれに関連する、ＣＢＥＭの匿名性を維持した上で、全ての金銭トランザクションに関わる送り主及び受取先の法的身分を開示可能とする支払システムに関する。

本発明は、全てのトランザクションを監視し、不正行為に関わり得るものを特定し、トランザクションを規制又は限定するための、中央運営団体又はＣＢＥＭユーザにより定義された基準を含めるための、更なるモジュールの追加を可能とする。

これにより、本発明は、ユーザのプライバシーを守りながら、暗号通貨盗難、ＫＹＣ、ＡＭＬに関する問題に対する実践的ソリューションを提供する。更に、中央銀行又はその他金融機関が本発明を利用、修正して、分散型台帳支払システムに対応し、且つ中央運営団体により規制され得る独自のデジタル通貨を発行可能とする。

このため、本発明は、３つの主要処理を統合する。即ち、（ｉ）法的個人認証、（ｉｉ）クレデンシャル認証、（ｉｉｉ）２団体署名方式である。本発明の実施形態は、ＣＢＥＭを作成する方法とシステム、及びそれに関連する、ＣＢＥＭの匿名性を維持した上で、全ての金銭トランザクションに関わる送り主及び受取先の法的身分を中央運営団体に開示可能とする支払システムに関する。

本発明のクレデンシャル認証機構は、ユーザがクレデンシャルを変更可能とすることで、盗まれたウォレットからのコインの転送を止めることを可能とする。最後に、非常に重要な点であるが、全てのトランザクションにおける送り主と受取先とを開示できるので、クライアント情報データベースから、１以上の受取先の１以上の法的身分を読み出すことで、容易にコインを盗んだ１以上の窃盗犯又は１以上のハッカーを追跡できる。これにより、本発明の実施形態は、ＣＢＥＭコインの窃盗を防止できる。

ＣＢＥＭの全てのトランザクションにおける送り主と受取先の法的身分を明らかにできるようにするためには、以下の２つの主要要素が必要となる。
１．ＣＢＥＭの全ての受取先及び送り主の法的身分
２．匿名の人物によるＣＢＥＭコインの受取、送金禁止
これら２つの主要要素は、単純に認証済みの法的身分を有する登録ユーザのみにＣＢＥＭを送金、受取可能とすることで実現できる。法的身分の取得検証のために、各登録者が自身の法的身分を提出証明するためのウェブ登録インタフェースが生成されて、法的身分が認証された人物のみが、有効ユーザと認められる。その後、登録されたものはＣＢＥＭを受信、送信できるようになる。但し、どのようにして匿名の人物によるＣＢＥＭ、特にオープンソースＣＢＥＭのコインを受け取り、送金を禁止するかに主要な課題がある。

ＣＢＥＭ（暗号型電子マネー）は、物理通貨と同様な特性を持ちながら、即時トランザクション、暗号化による安全性、所有権のデジタル又は仮想的な移転を可能とする任意の種類のデジタル通貨であってもよい。ＣＢＥＭの例としては、仮想通貨、暗号通貨、暗号証券（例えば、任意の電子的／デジタル証券又は証券に紐付けされたトークン）、又は中央銀行発行の「デジタル型マネー」であってもよい。ＣＢＥＭは、更にあらゆる形態の電子的／デジタルトークン（例えば、会社の株式の所有権の証明となる証書又は契約を示すもの、株式投資の証明、事業に対する利益分配権の証明、又は特許のロイヤリティ分配権の証明等）、あらゆる形態のＰｏＥに対する電子的／デジタル証書（例えば、権利付与の証明）、及び任意のその他の好適なデジタル又は仮想的な交換媒体を含むことができる。ＣＢＥＭにおいて、装置及びメッセージの認証、不正な観察や改竄からのデータ保護のため、暗号がよく使用される。ＣＢＥＭの例としては、ビットコイン、Ｅｔｈｅｒ、リップル、ライトコイン、ダッシュ、又はその他適切な暗号通貨が挙げられる。

あらゆる種類のＣＢＥＭトランザクションが、分散型ストレージ、分散型台帳、ブロックチェーン、又はその他適切な分散型トランザクション機構を含む分散型ネットワークに格納可能である。分散型ストレージは、ネットワーク上の１又は複数のノードに格納されたファイル又はファイルセグメントを含んでもよい。分散型ストレージは特定のフォーマット又はプロトコルに限定されるものではなく、サーバ、デスクトップＰＣ、携帯装置、リムーバブルストレージ、又はその他適切な装置を含む、任意のアクセス可能ネットワークノードに格納された、任意の種類のファイルを含んでもよい。一実施形態において、１ファイルの全体が単一のノードに格納され、別のファイルが別のネットワークノードに格納されてもよい。或いは、単一のファイルを複数のセグメントに分けて、１又は複数のネットワークノードに格納してもよい。

ビットコイン等のＣＢＥＭは、分散型決済システムとして設計される。そのコンピュータプログラミングコードは、オープンソースオンラインコミュニティにおいて、誰にでも精査可能であることが想定される。オープンソースのＣＢＥＭであれば、ソースコードを利用して、誰にでも自分の通貨アドレスを作成し、コインを送金、受取可能である。したがって、ＫＹＣ登録手法は特定のサービスプロバイダにのみ適用可能で、あらゆる通貨利用者に適用されるわけではない。

分散型台帳は、１又は複数の分散型ネットワーク全体で共有、同期されるデータベース又はデータベースの複製であってもよい。分散型台帳により、トランザクションが全体又は一部に公開されたり、複製されたりが可能であるので、サイバー攻撃を受けにくい。更に、分散型台帳は、信用が低い環境（即ち、共有データベースをホストする参加者がそれぞれ独立して役割を担い、互いに信用していない状況）でも、共有事実の存在や状態についての合意を維持可能である。合意とは、分散型台帳に特有のものではない。別の分散型データベースでも、Ｐａｘｏｓ又はＲａｆｔ等の合意アルゴリズムが利用されている。改竄不能という点についても同様である。分散型台帳以外で使用されるデータベース（Ｇｏｏｇｌｅ ＨＤＦＳ，Ｚｅｂｒａ，ＣｏｕｃｈＤＢ，Ｄａｔｏｍｉｃ等）にも改竄可能なものが存在するのである。

分散型台帳は、通常の分散型データベースと、以下の点で異なる。（ａ）リード／ライトアクセスが完全に分散化している。ほかの分散型データベースの場合、理論上、集中している。そのため、（ｂ）信頼できる第三者が不在の、困難な環境でも、トランザクションを保護できる。分散型台帳は、ブロックチェーンのように線形な構造を有することができる。或いは、ＩＯＴＡのＴａｎｇｌｅのようにＤＡＧ（有向非巡回グラフ）を含むことできる。ブロックチェーン、ＩＯＴＡのＴａｎｇｌｅ、ＨｅｄｅｒａのＨａｓｈｇｒａｐｈは、所定のフォーマット及びアクセスプロトコルを有する分散型台帳の具体例である。

ブロックチェーンは、ＣＢＥＭトランザクションを経時的に格納する分散型台帳である。ブロックチェーン台帳の場合、全てのＣＢＥＭトランザクションは、定期的に「ブロック」で検証、格納される。ブロックは暗号ハッシュを介して前ブロックにリンクしている。ブロックチェーン台帳は、確認可能となるように公開されているため、ＣＢＥＭトランザクションは誰にでも視認、追跡可能である。各ネットワークノードは、ブロックチェーンのコピーを受信、保持可能である。

登録ユーザにのみコインの使用を限定するために、登録されていない匿名ユーザにより生成された通貨アドレス（即ち、無効な通貨アドレス）を、登録された非匿名ユーザにより生成されたもの（即ち、有効な通貨アドレス）から区別する、新たな方法が開発されている。更に、コインの送金、受取に、有効通貨アドレスのみを使用可能とする別の方法も開発されている。

本発明は、これら２つの課題に対して実践的ソリューションを提供する。そのために、以下の３つの主要な処理を統合する。（ｉ）法的個人認証、（ｉｉ）クレデンシャル認証、（ｉｉｉ）２団体署名方式。統合のためには、以下の技術的修正が必要となる。
１．ビットコインの多署名トランザクションプロトコルを修正
２．修正したものをクライアント情報データベースにリンク付け
３．強制的に、修正したものをトランザクションプロトコルとする
４．強制的に、トランザクション署名を中央認証サーバの１つからの秘密鍵とする

本発明の実施形態は、以下の主要なステップで実現され得る。
ステップ１：ユーザの法的身分を取得、検証、保存し、ユーザ固有のクレデンシャルを生成するためのコンピュータサーバ及びウェブベースインタフェースを構築
ステップ２：ウェブベースインタフェースを利用して、通貨アドレス生成処理を限定するためのクレデンシャルを生成
ステップ３：多署名手法により、コインの送金、受取を実行
ステップ４：特定の規則で規制されたｐａｙ−ｔｏ−ｓｃｒｉｐｔ−ｈａｓｈトランザクションを実行

上述のステップを、以下により詳細に説明する。
ステップ１：ユーザの法的身分を取得、検証、保存し、ユーザ固有のクレデンシャルを生成するためのコンピュータサーバ及びウェブベースインタフェースを構築
コンピュータサーバ及びウェブベースインタフェース（例えば、ＢＧＣｗａｌｌｅｔ．ｃｏｍ）を構築するステップは、ＣＢＥＭ（例えば、Ａｔｅｎコイン）のユーザに関する。登録処理では、個人は当人の法的身分についての文書／情報（例えば、パスワードＩＤ番号及び、本人のパスポートの身分証ページ）を提供し、その法的身分（例えば、ＭｉｉＣａｒｄ又はＩＤｃｈｅｃｋｅｒによる身分承認サービス）を認証する処理が行われる。登録には、その法的身分が適切に認証される必要がある。提供された情報は全て、クライアント情報データベースに格納される。

図１は、暗号型電子マネーの新規ユーザの法的身分を取得、検証、記憶するための、登録及びデータベースシステムを示す。

少なくとも１つのウェブ登録インタフェース（１０２）を有する少なくとも１つのサーバは、以下の機能を実行する。最初に、ステップ（１０５）において、ウェブ登録インタフェース（１０２）を介して、登録者の法的身分を証明する文書の提出が要求される。次に、ステップ（１０６）において、登録者の法的身分の認証が行われる。認証失敗の場合、登録失敗（１０７）となる。

一方、認証された登録者（１０９）は、その登録ユーザアカウントを不正アクセスと、悪意ある攻撃から守るため、二要素認証又は多要素認証（１０４）を利用可能となる。

二要素認証は、オンラインユーザアカウント（１０４）を、安全に保護する方法である。具体的には、ユーザは自身のオンラインアカウントにログインする際に、２つの異なる要素により、本人確認を行うことが求められる。第１認証要素は、ユーザにより生成されたログイン名及びログインパスワードの組である。第２認証要素は、携帯電話又は個人用安全キー生成器等の、ユーザが所有する物理的デバイスに結び付けられた、定期的に変更されるトークン（例えば、固有の７桁コード）である。これにより、オンラインユーザアカウントは、個人の物理的デバイスが盗まれない限り、ハッキングされることはない。ユーザが自身のオンラインアカウントにログインする際に、３つ以上の異なる要素（例えば、ログイン名とログインパスワードの組、携帯電話及びスマートＩＤカード）が要求されるようにして、多要素認証とすることも可能である。

認証された登録者（１０９）は、ラベルとパスワードを含むクレデンシャル（１１１）を生成する（１１２）ことが求められる。当然、認証された登録者（１０９）は、クレデンシャル及び連絡先情報（１１３）を変更できる。これらは、ステップ（１１４）にて暗号化されることが好ましい。クレデンシャルは、ユーザが自身の１以上の多署名ウォレットアドレス（図２）を生成するために必要なものである。当該アドレスは、コイン（例えばＡｔｅｎコイン）を受け取り、トランザクション（図３）を実行するために必要である。

任意で、ステップ５０２において、有効登録ユーザは、自身のトランザクションを制限するためのクライアントトランザクション基準を策定できる。例えば、ユーザは２４時間以内に自身の１以上の通貨アドレスから送られるコインの最高金額を制限する基準を設定できる。これにより、通貨ウォレットが盗まれたり、ハッキングされたりした場合にも、損失を最小限にとどめることができる。

上記までの処理が完了すると、ステップ（１１６）において、全ての提出された情報、特に法的身分及び暗号化クレデンシャルがクライアント情報データベース（１１５）に格納される。

最後に、ステップ１１７において、新たに作成された又は変更された暗号化クレデンシャルが中央認証サーバ（４０１）に送られる。中央認証サーバは、個別の登録者毎に１以上の多署名通貨アドレス、クレデンシャル、法的身分のマッピング（１１８）及び記憶を実行する。例えば、多署名通貨アドレスは、数字、大文字小文字のアルファベットを含む３４桁の文字列である（例えば、Ａｊ８ｘＦｏｚＵｊｏ３ＧｏＮｖｉ９５ｋＡＢｐＴｊＯ２ｑＱＲｅＺｏ５Ｐ）。個人ＩＤは、（ｉ）ユーザのマイナンバーカード又はパスワードに印字された法律上の名前（フルネーム）、（ｉｉ）マイナンバーカード／パスワードに記載の番号、（ｉｉｉ）誕生日を含む。

ステップ２：ウェブベースインタフェースを使用して、通貨アドレス生成処理を規制するためにクレデンシャルを生成
有効登録ユーザ（１０６、１０９）のみが、コイン（例えば、Ａｔｅｎコイン）を送金、受取用の（図３に示す）、自身の１以上の多署名アドレス（図２に示す）の生成に要されるクレデンシャル（図１、１１２）を、ウェブベースインタフェースを使用して生成できる（１１１）。クレデンシャルを用いることで、未登録の匿名ユーザが、システム内でコインを授受するための有効多署名アドレスを生成することを不可能にできる。言い換えると、ＣＢＥＭのコインの送金、受取のための全ての有効通貨アドレスは、公知の法的身分を有する実際の人物に結び付けられる。

ステップ３：多署名手法により、コインの送金、受取を実行
コインの授受のための有効多署名アドレスを生成するには（図２）、１つの中央認証サーバからの１つの認証公開鍵と、少なくとも１つのクライアント公開鍵が必要である。コインを受け取るためのアドレスを生成するためにクライアントウォレット（３０１）が使用可能となる前に、クライアントウォレットに対してクレデンシャル（１１１）を入力する必要がある。アドレス生成処理において、クライアントウォレットは先ず、クレデンシャルを電子／デジタルデータ送信ネットワーク（例えば、インターネット）を介して、中央認証サーバ（４０１）の１つに送信して、検証（４０７）が行われる。

クレデンシャルが有効であると確認されれば、即ち、中央認証サーバ（３１９、４０１、４０７）のデータベースにおける有効かつアクティブなクレデンシャルに一致すれば、中央認証サーバは認証公開鍵（４０８）を、電子／デジタルデータ送信ネットワークを介してクライアントウォレットに提供する。クレデンシャルが無効又は非アクティブである場合、中央認証サーバはクライアントウォレットに失敗メッセージを返す。認証公開鍵を受信すると、クライアントウォレットは多署名アドレス生成処理に進む（３１５）。

失敗メッセージを受信すると、クライアントウォレットは多署名アドレス生成処理を行わない。認証公開鍵があれば、クライアントウォレットはクライアント公開鍵（３０７）と秘密鍵（３０８）の組を生成（３０９）し、これをクライアントウォレットに格納する（３１０）。その後、認証公開鍵（４０５）とクライアント公開鍵（３０７）を組み合わせて、多署名アドレス（３１５）を生成する。このように生成された多署名アドレス（３１５）は、当然認証秘密鍵とクライアント秘密鍵に深く関連する。多署名アドレスは、クライアントウォレット（３１６）に格納、表示される。ユーザは、多署名アドレスを利用してＣＢＥＭコイン（例えばＡｔｅｎコイン）を受け取ることができる。

各多署名アドレスに認証公開鍵が存在することは、あらゆるトランザクションが有効となるには１つの中央認証サーバからの認証署名（即ち、認証秘密鍵（４０６））と、クライアント署名（即ち、クライアント秘密鍵（３０８））が必要であることを示すものである。

この制御システムを利用すれば、有効登録ユーザのみが多署名アドレスを生成できる。該アドレスを使用して、１つの中央認証サーバからのカウンターサインが必要なトランザクションを実行できる。

図２は、暗号型電子マネーを授受するための多署名通貨アドレスを生成するための、法的身分関連クレデンシャル認証システムを示す。

処理における最初のステップ（３０１）において、好ましくはソフトウェアによりアクセス可能なネットワーク資源であるクライアントウォレットが提供される。次に、ステップ（１１１）からの入力ユーザクレデンシャルを適用して、クライアントウォレットをアクティブにする。次に、ステップ（３１４）において、ユーザは通貨アドレスの生成を試みるが、システムは、多署名アドレスである通貨アドレスのみを生成する。

次に、ステップ（３１９）において、１以上の有効通貨多署名アドレスを生成するための承認を得るため、有効登録ユーザがクレデンシャルを中央認証サーバ（４０１）の１つに提出する。

承認が得られない場合、適切なエラーメッセージが生成されてもよい。一方、承認された場合、ステップ（３０９）において、コインの送金、受け取りのため、暗号化クライアント公開鍵（３０７）及びクライアント秘密鍵（３０８）の組が、１つ以上生成される。これらクライアント公開鍵及びクライアント秘密鍵は、クライアントウォレット（３１０）に格納され関連付けられる。更に、承認された場合、ステップ４０８において、認証秘密鍵（４０６）に数学的にリンクされた認証公開鍵（４０５）が、中央認証サーバからクライアントウォレットに提供される。

更に、ステップ（３１５）において、１以上のクライアント公開鍵（３０７）からの１以上の多署名アドレスと、１以上の認証公開鍵（４０５）が生成される。生成された多署名通貨アドレスは、クライアントウォレットに格納され、関連付けられる（３１６）。

次に、ステップ（３１７）において、１以上の多署名アドレスが、クライアント情報データベース（１１５）に送信され、１以上のアドレスの所有者の法的身分にマッピングされて、格納される（１１８）。

ステップ４：特定の規則で規制されたｐａｙ−ｔｏ−ｓｃｒｉｐｔ−ｈａｓｈトランザクションを実行
ビットコインのデベロッパーにより、現在までに、２つの異なるビットコイントランザクションの作成及び承認方法が開発されている。具体的には、２つの方法は、それぞれ異なるｓｃｒｉｐｔＳｉｇ／ｓｃｒｉｐｔＰｕｂＫｅｙ組を使用する、ｐａｙ−ｔｏ−ｐｕｂｋｅｙ−ｈａｓｈと、ｐａｙ−ｔｏ−ｓｃｒｉｐｔ−ｈａｓｈである。

ｐａｙ−ｔｏ−ｐｕｂｋｅｙ−ｈａｓｈは、通常のビットコイントランザクションにおいて、最も一般的に利用されている方法である。ｐａｙ−ｔｏ−ｐｕｂｋｅｙ−ｈａｓｈトランザクションでは、ビットコインアドレスは、公開／秘密（ＥＣＤＳＡ）楕円曲線デジタル署名アルゴリズム鍵組の公開部分における、１６０ビットハッシュ値である。ビットコイン送り主は、ビットコインアドレスをｓｃｒｉｐｔＰｕｂＫｅｙに設ける。ｐａｙ−ｔｏ−ｐｕｂｋｅｙ−ｈａｓｈトランザクションの場合、送り主は、ビットコインを公開鍵の所有者に直接送金する。

ｐａｙ−ｔｏ−ｐｕｂｋｅｙ−ｈａｓｈトランザクションを始めるには、送り主はビットコインが格納された公開鍵を、対応するビットコインアドレス及び対応する署名（即ち、秘密鍵組）と、ビットコインを受け取るためのビットコインアドレスに提供する必要がある。受取用ビットコインアドレスは、対応する公開鍵及び署名に直接リンクされている。ビットコインアドレスに送られたコインを換金する際、受取人は、署名と公開鍵の両方を提供する。スクリプトは、提供された公開鍵がｓｃｒｉｐｔＰｕｂＫｅｙ内のハッシュに対してハッシュしていることを確認してから、署名を公開鍵と照合する。

ｐａｙ−ｔｏ−ｓｃｒｉｐｔのトランザクションに関連するアドレスは、公開鍵ハッシュではなく、スクリプトのハッシュである。ビットコインをｐａｙ−ｔｏ−ｓｃｒｉｐｔ−ｈａｓｈで支払うには、スクリプトのハッシュに一致するスクリプトと、スクリプトを真と評価するデータを提供する処理が必要である。言い換えれば、対象のスクリプトが受け入れられる入力（即ち、回答）を提供すれば、トランザクションが進む。入力が無効で、スクリプトが受け入れられなければ、トランザクションは停止する。

ｐａｙ−ｔｏ−ｓｃｒｉｐｔ−ｈａｓｈを使用すると、セキュリティ設定の詳細を一切把握していなくとも、様々な独特な方法で保護されているアドレスにビットコインを送信可能である。例えば、受取人が特定のビットコインアドレスに格納されたビットコインを受け取るためには複数人の署名を必要となるか、パスワードが必要となる。或いは、要件は完全に独自のものである可能性もある。ビットコイン及びビットコイン技術を基に開発された現状利用可能なあらゆる暗号通貨に関して、ｐａｙ−ｔｏ−ｓｃｒｉｐｔ−ｈａｓｈは強制されるものではない。

ｐａｙ−ｔｏ−ｐｕｂｋｅｙ−ｈａｓｈは、ビットコイントランザクション及びビットコイン技術を基に開発された現状利用可能なあらゆる暗号通貨トランザクションにおいて、一般的な方式である。ｐａｙ−ｔｏ−ｐｕｂｋｅｙ−ｈａｓｈ機能が、暗号通貨のクライアントウォレットソフトウェアに組み込まれている。暗号通貨所有者は、クライアントウォレットソフトウェアを使用して、トランザクションにｐａｙ−ｔｏ−ｐｕｂｋｅｙ−ｈａｓｈとｐａｙ−ｔｏ−ｓｃｒｉｐｔ−ｈａｓｈのいずれを利用するかを選択できる。

本発明では、ＣＢＥＭトランザクションネットワークにおいて、ｐａｙ−ｔｏ−ｓｃｒｉｐｔ−ｈａｓｈトランザクションのみが許可される。この制限は、ビットコイン及びビットコイン技術を基に開発された現状利用可能なあらゆる暗号通貨とは対照的に、クライアントウォレットソフトウェアのソースコード内のみではなく、ＣＢＥＭのソースコード内で実現される。これにより、ＣＢＥＭデベロッパーは、あらゆるトランザクションに対して、特定の規則を適用でき、したがって、あらゆるトランザクションの制御に、法的身分関連クレデンシャル認証システムを実現できる。法的身分関連クレデンシャル認証システムでは、ＣＢＥＭの送受信に、特定ユーザクレデンシャル及び多署名アドレスが使用される。

法的身分関連クレデンシャル認証システムでは、ｐａｙ−ｔｏ−ｓｃｒｉｐｔ−ｈａｓｈトランザクションにおいて、ＣＢＥＭの送受信に多署名アドレスのみが使用される。各クライアント多署名アドレスは、クライアント公開鍵（クライアントウォレットから生成）（３０７）を含むスクリプトと、トランザクションの生成、署名用の認証公開鍵（中央認証サーバの１つが生成）（４０５）に結び付けられている。したがって、全てのｐａｙ−ｔｏ−ｓｃｒｉｐｔ−ｈａｓｈトランザクションは、トランザクションを有効とするために、少なくともクライアント秘密鍵（３０８）と認証秘密鍵（４０６）とを必要とする。

ｐａｙ−ｔｏ−ｓｃｒｉｐｔ−ｈａｓｈトランザクション用のスクリプトは、クライアントウォレット内のみではなく、ＣＢＥＭのソースコード内で実現される。したがって、スクリプトにより、あらゆるトランザクションを開始及び署名するための、１以上の中央認証サーバからの１以上の認証秘密鍵（４０６）の要件が実施できる。中央認証サーバを介して認証秘密鍵の提供が規制できるため、中央認証サーバによる要件、規制、及び／又は規則に従わずにｐａｙ−ｔｏ−ｐｕｂｋｅｙ−ｈａｓｈ又はｐａｙ−ｔｏ−ｓｃｒｉｐｔ−ｈａｓｈトランザクションを行うことは不可能となる。

図３は、法的身分関連クレデンシャル認証システムと、ユーザが所有し、多署名アドレスに記録されたコインの金額での支払いトランザクションを行うための２団体署名方式を示す。

Ｐａｙ−ｔｏ−ｓｃｒｉｐｔ−ｈａｓｈトランザクション（２１８）を行う際、クライアントウォレット（３０１）は、その許可を得るため、少なくとも１つの中央認証サーバ（４０１）からの署名（即ち認証秘密鍵）（４０６）が必要となる。トランザクションの要求は、中央認証サーバに対するＡＰＩコールで送られ、認証が行われる（２２０）。認証が失敗すると、適切なエラーメッセージが生成されてもよい。

クライアントウォレットから中央認証サーバ（４０１）に送られたクレデンシャルが有効で（２２０、４０９）、要求されたトランザクションが所定の基準（５０１、５０２）に基づいて、疑わしいものではないと判断されれば、クライアントウォレット（即ちクライアント秘密鍵）（３０８）からの署名と、中央認証サーバの１つからの署名（即ち認証秘密鍵（４０６、４１１））が得られ、トランザクションが承認される（４１０、４１２）。

ｐａｙ−ｔｏ−ｓｃｒｉｐｔ―ｈａｓｈのスクリプトは、複数の公開鍵及び／又は認証秘密鍵が必要となるように、変更できる。この場合、支払いトランザクションが実行されるには、１以上のクライアント（送り主、受取先のいずれか）及び／又は１以上の承認機関からの署名が必要となる。更に安全性を高めるために、トランザクション入力（４１０）と、トランザクション全体（４１２）の署名に、２つの異なる認証秘密鍵を使用してもよい。

本発明では、あらゆるトランザクションが行われるために、署名として、中央認証サーバからの少なくとも１つの認証秘密鍵が必要となる。認証秘密鍵が提供されるには、送り主からの有効クレデンシャルが認証される必要がある。有効クレデンシャルは全て個別のクライアントウォレットアドレスに結び付けられ、法的身分が認証されてクライアント情報データベース（図２）に格納された登録ユーザにより所有されている。そのため、法的身分がデータベースに格納された登録ユーザのみが、有効クレデンシャルを提出して、自身のウォレットアドレスから、別のウォレットアドレスへとコインを送金できるのである。

ＣＢＥＭ送り主又は受取先の法的身分の開示が必要である場合、クレデンシャルにより中央認証サーバを所有する中央運営団体とクライアント情報データベースとが結び付けられる。法的身分の情報は、ｐａｙ−ｔｏ−ｓｃｒｉｐｔ−ｈａｓｈトランザクションの処理全体では必要ではないため、送り主と受取先の匿名性は保たれる。

中央認証サーバは、少なくとも１つの中央認証サーバ（４０１）に格納された中央トランザクション基準（５０１）に準拠しないあらゆるトランザクションを拒絶できる。具体的には、各トランザクションは、マネーロンダリング等の不正行為に関与する可能性のある疑わしいトランザクションを特定、記録、報告する、所定の規則により監視できる。あらゆる疑わしいトランザクションと、それに関わる送り主及び受取先の身元は、関連する政府機関に報告され、対処される。したがって、本発明は、ビットコインやその他各種通貨の、現在のＫＹＣ／ＡＭＬ非準拠の問題に対処する、実践的ソリューションを提供するものである。

任意で、ステップ５０２において、有効登録ユーザは、自身のトランザクションを制限するためのクライアントトランザクション基準を策定できる。例えば、ユーザは２４時間以内に自身の１以上の通貨アドレスから送られるコインの最高金額を制限する基準を設定できる。これにより、通貨ウォレットが盗まれたり、ハッキングされたりした場合にも、損失を最小限にとどめることができる。

その後、トランザクションは確認（３０５）用にノード（２１４）のネットワークにブロードキャストされる。生成されたトランザクションは、正式なものになる前に、トランザクションネットワークに送られて処理され、ブロックチェーンのブロックに含まれる必要がある。ノードは、ブロック内の全てのトランザクションが有効（即ち、正しく署名）であり、ＣＢＥＭがまだ支払われていない場合にのみ、ブロックを受け入れる。ノードが当該ブロックのハッシュを、前ハッシュとして、次のブロックをチェーンに作成することで、そのブロックを受け入れたことが示される。

新たに生成されたブロックでトランザクションを実行する処理を、トランザクション確認と呼ぶ。１つのブロックに取り込まれることを、１つの確認とする。確認の数が、所定数（例えば、ビットコインの場合には６、Ａｔｅｎコインの場合は１０）以上となれば、トランザクションが確認済みとなる。ビットコイン技術において、この機能は、システムで同じコインを再使用すること（即ちダブルスペンディング）を防止するために導入されている。

図１から図３に示す構成特有の機能は以下のとおりである。
・有効通貨アドレスとして、多署名アドレス（３１３）のみの生成（３１４）を許可する。
・コインを送る場合、受け取る場合の両方で、多署名アドレス（３１３）を使用するトランザクションのみの生成を許可する（３２１）。
・ｐａｙ−ｔｏ−ｓｃｒｉｐｔ−ｈａｓｈ形式（２１８）又はその他対応する形式でのトランザクションのみの生成（３１１）を許可する。
・署名として少なくとも２の秘密鍵を必要とするトランザクションのみの生成を許可する（３０８、４０６）。
・これら秘密鍵（３０８、４０６）の内の１つを、中央認証サーバ（４０１）の１つからの認証秘密鍵（４０６）に限定する。
・残りの秘密鍵（３０８、４０６）を、暗号化されて１以上のクライアントウォレット（３０１）に格納されるクライアント秘密鍵（３０８）に限定する。
・有効登録ユーザ（１０９）のみが有効クレデンシャル（１１１）を生成可能とする（１１２）。
・有効クレデンシャル（１１１）を有するユーザのみが、当該クレデンシャル（１１１）を提出し、中央認証サーバ（４０１）の１つを介して認証されることで、コインを受け取るため、１又は複数の有効多署名通貨アドレス（３１３）を生成可能とする（３１９，４０７）。
・有効クレデンシャル（１１１）と、１又は複数の有効多署名通貨アドレス（３１３）、対応するクライアント秘密鍵（３０８，３０９）を有するユーザのみが、１以上の有効トランザクションを生成可能とする（２２０、３２０、４０９）。
・提出されたクレデンシャル（１１１）を、中央認証サーバ（４０１）の１つを介して検証（２２０、３２０、４０９）することで、１又は複数のトランザクション（４１０、４１２）を署名するために１又は複数の認証秘密鍵（４０６、４１１）を中央認証サーバ（４０１）の１つから受信可能であるのを、有効クレデンシャル（１１１）を有するユーザに限定する。
・提出されたクレデンシャル（１１１）を、中央認証サーバ（４０１）の１つを介して検証（２２０、３２０、４０９）することで、有効トランザクションを生成するために中央認証サーバ（４０１）の１つから１又は複数の認証秘密鍵（４０６、４１１）を受信可能であるのを、有効クレデンシャル（１１１）を有するユーザのみに限定する。したがって、有効トランザクションを生成するのを、有効クレデンシャル（１１１）を有するユーザのみに限定する。
・各クレデンシャル（１１１、１１２、１１３、１１４）を、ユーザの法的身分（１０５）に結び付ける（図１）。
・各クレデンシャル（図１、１１１）を使用して、対応する所有者の法的身分（１０５）を追跡する（１１６）。
・各多署名アドレス（３１３、３１４）をユーザのクレデンシャル（１１１）に結び付ける（図２）。
・各多署名アドレス（３１３）を使用して、所有者に対応するクレデンシャル（１１１）を追跡する（１１８）（図２）ことで、クレデンシャル（１１１）により、所有者の法的身分（１０５）を追跡（１１６）する（図１）。
・各トランザクションを使用して、送り主と受取先の多署名アドレス（３１３）を追跡し（図３）、更に多署名アドレス（３１３）を使用して送り主と受取先のクレデンシャル（１１１）を追跡（１１８）し（図２）、最後にクレデンシャル（図１、１１１）を使用して送り主と受取先の法的身分（１０５）を追跡する（１１６）。
・有効クレデンシャル（１１１）を有するユーザのみが有効多署名アドレス（図２）を作成して、有効トランザクションを作成できることから、全ての有効トランザクションにおける送り主（図１、１０５）と受取先の法的身分を追跡、捜索（１１６）可能（図３）とする。

いくつかの形態では、図１、図２及び／又は図３を参照に示す方法は、１又は複数の処理装置（例えば、デジタルプロセッサ、アナログプロセッサ、情報を処理するよう設計されたデジタル回路、情報を処理するよう設計されたアナログ回路、ステートマシン、及び／又は電子的に情報を処理するその他機構）で実行されてもよい。１又は複数の処理装置は、電子記憶媒体に電子的に記憶された指示に応じて、方法の一部又は全部の動作を実行する１又は複数の装置を含んでもよい。１又は複数の処理装置は、図１、図２、及び／又は図３に示す１以上の方法の１又は複数の動作を実行するように設計されたハードウェア、ファームウェア、及び／又はソフトウェアにより構成された１又は複数の装置を含んでもよい。

図４は、本発明に関わるシステムを示す図である。システムは、クライアント−サーバ構造を有し、サーバは、１又は複数の中央認証サーバである。本発明の１又は複数の形態が実現され得る例示的コンピュータネットワーク（「システム４００」）が図示されている。いくつかの形態において、システム４００は、１又は複数のサーバ４０１を含んでもよい。１以上のサーバ４０１は、クライアント／サーバ構造における、１以上の１又は複数のクライアントコンピューティングプラットフォーム４１４／４１５と通信するように構成されてもよい。ユーザは、１以上のクライアントコンピューティングプラットフォーム４１４／４１５を介してシステム４００にアクセスしてもよい。１以上のサーバ４０１と、１以上のクライアントコンピューティングプラットフォーム４１４／４１５は、機械可読命令を実行するように構成されてもよい。

いくつかの形態では、１以上のサーバ４０１、１以上のクライアントコンピューティングプラットフォーム４１４／４１５、及び／又は１以上の外部資源４１８は、１又は複数の電子通信リンクを介して動作可能にリンクされていてもよい。例えば、当該電子通信リンクは、少なくとも部分的に、インターネット及び／又はその他のネットワークを介して構築されてもよい。ただしこれに限定するものではなく、１以上のサーバ４０１、１以上のクライアントコンピューティングプラットフォーム４１４／４１５、及び／又は１以上の外部資源４１８がその他の通信媒体を介して動作可能にリンクされ得る形態も、本開示の範囲に含まれることを理解されたい。

所与のクライアントコンピューティングプラットフォーム４１４／４１５は、機械可読命令を実行するように構成された１又は複数のプロセッサを含んでもよい。機械可読命令は、所与のクライアントコンピューティングプラットフォーム４１４／４１５に関連付けられた技術者又はユーザが、システム４００及び／又は１以上の外部資源４１８とインタフェース可能とする、更に／或いは本明細書に記載の１以上のクライアントコンピューティングプラットフォーム４１４／４１５の他の機能を提供するように構成されてもよい。非限定的な例として、所与のクライアントコンピューティングプラットフォーム４１４／４１５は、デスクトップコンピュータ、ノートＰＣ、携帯端末、タブレットコンピューティングプラットフォーム、ネットブック、スマートフォン、ゲーム機、及び／又はその他のコンピューティングプラットフォームの内の１又は複数を含んでもよい。

１以上の外部資源４１８は、情報源、システム４００と協働する外部実体、及び／又はその他の資源を含んでもよい。いくつかの形態では、本明細書に記載の１以上の外部資源４１８の機能の全て又は一部は、システム４００内の１以上の資源により提供されてもよい。

１以上のサーバ４０１及び／又は１以上のクライアントコンピューティングプラットフォーム４１４／４１５は、電子ストレージ４１９、１又は複数のプロセッサ４２０、及び／又はその他の要素を含んでもよい。１以上のサーバ４０１は、ネットワーク及び／又はその他のコンピューティングプラットフォームとの情報交換を可能とする通信回線又はポートを含んでもよい。１以上のサーバ４０１は、図１に示されたものに限定されるものではない。１以上のサーバ４０１は、本明細書に記載の１以上のサーバ４０１の機能を提供するために協働する複数のハードウェア、ソフトウェア、及び／又はファームウェア要素を含んでもよい。例えば、１以上のサーバ４０１は、１以上のサーバ４０１として協働するコンピューティングプラットフォームのクラウドにより実現されてもよい。

電子ストレージ４１９は、電子的に情報を記憶する非一時的記憶媒体を含んでもよい。電子ストレージ４１９の電子記憶媒体は、１以上のサーバ４０１に対して一体的に設けられた（即ち、実質的に固定された）システムストレージ、及び／又は例えばポート（例えばＵＳＢポート、ファイやワイヤポート等）又はドライブ（例えばディスクドライブ等）を介して１以上のサーバ４０１に対して脱着可能に接続可能な着脱可能ストレージの一方又は両方を含んでもよい。電子ストレージ４１９は、光学的可読記憶媒体（例えば、光ディスク等）、磁気的可読記憶媒体（例えば磁気テープ、磁気ハードドライブ、フロッピードライブ等）、電荷式記憶媒体（例えばＥＥＰＲＯＭ、ＲＡＭ等）、ソリッドステート記憶媒体（例えばフラッシュドライブ等）、及び／又はその他の電子的可読記憶媒体の内の１または複数を含んでもよい。電子ストレージ４１９は、１以上の仮想記憶資源（例えばクラウドストレージ、仮想プライベートネットワーク、及び／又は１以上のその他の仮想記憶資源）を含んでもよい。電子ストレージ４１９は、ソフトウェアアルゴリズム、プロセッサ４２０により決定された情報、１以上のサーバ４０１から受信した情報、１以上のコンピューティングプラットフォーム４１４／４１５から受信した情報、及び／又は１以上のサーバ４０１を本明細書に記載のとおりに機能できるようにするその他の情報を記憶してもよい。

プロセッサ４２０は、１以上のサーバ４０１における情報処理能力を実現するように構成されてもよい。このため、１以上のプロセッサ４２０は、デジタルプロセッサ、アナログプロセッサ、情報を処理するように設計されたデジタル回路、情報を処理するように設計されたアナログ回路、ステートマシン、及び／又は電子的に情報を処理するその他の機構の内の１または複数を含んでもよい。図１ではプロセッサ４２０は単一のものとして図示されているが、これはあくまで例示的である。いくつかの形態では、プロセッサ４２０は、複数の処理部を含んでもよい。当該処理部は、単一の装置内に物理的に配置されてもよいし、プロセッサ４２０は、協働する複数の装置の処理機能を示すものであってもよい。プロセッサ４２０は、ソフトウェア、ハードウェア、ファームウェア、又はソフトウェア、ハードウェア、及び／又はファームウェアの任意の組み合わせ、及び／又はプロセッサ４２０上で処理能力を実現するその他の機構により、機械可読命令要素及び／又は機械可読命令要素を実行するように構成されてもよい。本項記載の「要素」という用語は、当該要素の機能を実行する任意の要素又は要素群を指すものであってもよい。これは、プロセッサ可読命令実行中の１又は複数の物理的プロセッサ、プロセッサ可読命令、回路、ハードウェア、記憶媒体、又は任意のその他要素を含んでもよい。

クライアント４１４／４１５及びサーバ４０１は、専用要素又はカスタムメードＦＰＧＡ又はＡＳＩＣ回路により実現可能なデータ処理資源を含んでもよい。当該計算資源は、本発明に関わる方法のステップを実現するソフトウェアの記憶、実行に適している。中央認証サーバ（４０１）は、クライアント登録リクエスト（図１）、クライアント暗号通貨アドレス（図２）、クライアントアカウント更新リクエスト、及び暗号通貨トランザクション（図３）を処理する。このために、中央認証サーバ（４０１）はクライアント情報データベース（４０４）（例えば、ユーザＸ：法的名、誕生日、住所、連絡先、クレデンシャル、暗号通貨アドレス、トランザクション基準）と、トランザクションデータベース（４１３）（例えば、トランザクションＹ：トランザクションＩＤ、送り主及び受取先の暗号通貨アドレス，取引されたコインの金額、トランザクション時間、送り主及び受取先のクライアントウォレットのＩＰアドレス）と協働する。

各通貨アドレスの所有者の法的身分が、クライアント情報データベースに格納される（図１、１１５）。これにより、「ＫＹＣ（顧客確認）」規制要件が満たされ、システムが商業活動における支払システムとして利用可能となる。但し、当該情報は誰にでもアクセスできるものではないため、ＣＢＥＭ及びそのトランザクションネットワークの匿名性が保たれる。

コインが盗まれても、１以上の窃盗犯又は１以上のハッカーは、クライアント情報データベース（１１５）から１以上の受取先の１以上の法的身分を読み出すことで、容易に追跡できる。このように、この形態のシステムは、ＣＢＥＭコインの盗難を防止する。

ビットコイン及びビットコイン技術を利用したオルトコインの偽名性又は匿名性により、ブロックチェーンに格納された公開トランザクション記録を分析するのみでは、各コイン所有者のコイン収支を追跡することができない。更に、特定の通貨アドレスに記録されたコインの一部のみが支払われると、新たに生成された通貨アドレスに、コインの未使用分の金額が記録される。第三者がブロックチェーンの分析により、コインの総受領額が最終的にどのアドレスに対するトランザクションにより記録されたかを追跡するためには、膨大な計算負荷がかかる。

本発明によると、有効登録ユーザが所有するコインの金額は、中央運営団体がトランザクションデータベースにおけるトランザクション記録を分析することで、完全に捜索及び追跡可能である（４１３）。各通貨アドレスを対応する所有者に結び付ける機能に加えて設けられた、本システムのこの固有の特性は、コインが送金／支払われた直後の通貨アドレスにおける未使用分のコイン（全額使用されていない場合）を記録することに基づく。言い換えると、通貨アドレスに記録されたコインの金額は、当該アドレスに送られていたコインの全てが、送金／又は支払われない限り、０とはならない（３２２）。この固有の特性は、第三者によるブロックチェーンのトランザクション記録の分析を介した、暗号通貨の所有権の移転を追跡する処理が軽減されるだけではなく、システムを、特に第三者の監査の下に実現される金融、銀行業務に適用可能にするものである。

中央認証サーバ（４０１）は、クライアントウォレット（４１６、４１７）を実現する１又は複数のクライアント（４１４、４１５）と通信する。ウォレットは、中央認証サーバ（４０１）に動作可能に接続され、トランザクションに関するデータを送受信可能であってもよい。ウォレットは、ソフトウェア、ハードウェア、オンライン、又はその他適切な手段で実現されてもよい。ウォレットは、特定の暗号通貨を１つ格納、又は複数種の暗号通貨を格納可能であってもよい。

ウォレットのユーザによるトランザクションのリクエストは、１又は複数の中央認証サーバ（４０１）によって検証される。このため、クライアントは、ＧＳＭ、ＵＭＴＳ，ＤＳＬ，イーサネット等の適切な双方向通信リンクにより、サーバ（４０１）に接続される。

本発明は、疑わしい又は不正なトランザクションを自動的に特定、停止する手段を含んでもよい。更に、本発明は、ＣＢＥＭが（ｉ）マネーロンダリングに使用されたり、（ｉｉ）盗まれたりすることを防止する。ＡＭＬ及びＫＹＣポリシーは、特定のエンティティにより決定されてもよいし、既存の規則、規定に準じてもよい。したがって、本発明は、ＣＢＥＭ及びそのトランザクションネットワークが、ＡＭＬ及びＫＹＣポリシー及び規則に準拠可能とする。例えば、ＧｌｏｂａｌＶｉｓｉｏｎ Ｓｙｓｔｅｍｓの高度ルールベースインテリジェントＢＳＡ／ＡＭＬ／ＡＴＦシステムであるＰＡＴＲＩＯＴ ＯＦＦＩＣＥＲは、全てのトランザクションにおける疑わしい活動を監視、スクリーニング、検出、警告、調査、分析することでＢＳＡ／ＡＭＬ／ＡＴＦワークフローを効果的に自動化できるように、適用できる。

本発明の１又は複数の実施形態の１つの変形例として、特定の条件で、トランザクションを遅延、保留、及び／又は逆転させてもよい。通常、送り主は、トランザクションを行う際に、署名を行う必要がある。一実施形態では、ユーザは、トランザクションを逆転できない。但し、トランザクションネットワークを制御する企業は、ユーザのリクエストを受けて、トランザクションを効果的に「逆転」することができる（有効期限が切れるまで、トランザクションを保留することによる）。通常の暗号通貨では、トランザクションの逆転はできない。しかし、本発明のこの変形例では、システムはトランザクションをある期間保留、例えば所定の１又は複数の条件が満たされるため待機するための所定期間、保留する。例えば、ユーザが商品又はサービスの売り手に対してＣＢＥＭを送金するためのトランザクションを生成したとする。すると、例えば中央サーバ等のシステムへのユーザ（買い手）からのリクエストに応じて、システムは所定期間経過するまで、トランザクションを未完成の状態で保留する。売り手が正当な商品又はサービスを所定期間中に届ければ、買い手はトランザクションを取り下げない。売り手が正当な商品又はサービスを所定期間中に届けなければ、所定期間前でも買い手はトランザクションを無効にできる。これにより、売り手の行動を促すことができる。

このシステムの変形例として、例えば、中央サーバがＦｅｄｅｒａｌ Ｅｘｐｒｅｓｓ（登録商標）、ＵＰＳ（登録商標）、ＤＨＬ（登録商標）等の配送会社のような第三者から商品発送、配達通知を受け取るまで、受け取らない限り、支払いを延期できる。或いは、保留はトランザクション金額に基づいてもよい。例えば、ユーザは、自動的に任意の金額を超えるトランザクションが自動的に１週間又は任意の期間保留されることを望む場合があり得る。或いは、システムはユーザに所定の金額を超えるトランザクションのみ保留可能としてもよい。また、システムには最長保留期間が存在してもよい。最長保留期間は、トランザクション金額が所定の額増える度に、所定の長さ延長されてもよい。保留は更に、（１）リスクのあるソースからのトランザクションの特定、（２）制裁リストに記載の団体の特定、（３）ユーザの疑わしい活動の特定、（４）リスクのあるソースからの資金の流れの特定、（５）非合法なソースからの資金の流れの特定、（６）疑わしい活動数が所定の閾値を越えたことを特定、（７）その他適切な判定の特定に基づいて実施されてもよい。

図５は、保留の例を示すフローチャートである。ステップ５１１において、ユーザは、金額ＸのＣＢＥＭを受取先に送るためのトランザクションを生成する。ステップ５０２ａにおいて、システム（例えば、１以上の中央サーバび／又はスマートコントラクトのような規制ユーティリティ）は、ユーザリクエストに応じて、更に／或いは自動的にトランザクションの保留時間を設定する。自動設定は、例えば異常に大きなトランザクション、及び／又は異常な回数のトランザクションの繰り返し、及び／又は本明細書の他部記載のその他疑わしいトランザクション、及び／又は政府規制に応じて実施されるものであってもよい。ステップ５０３において、システムは、特定のトランザクションが金融犯罪である可能性が高いか否かを判定してもよい。可能性が高い場合、ステップ５０４において、システムは、トランザクションを逆転（例えば、トランザクションをキャンセルするか、承認しないことで実施）してもよい。別の形態では、ユーザは、上述の理由（商品又はサービスが予定通り配達されなかった）、及び／又は金融犯罪の検出により、トランザクションをキャンセルするか、逆転させてもよい。その場合、トランザクションは、台帳の一部とはならない、即ち、例えばトランザクションが公開されず、ブロックチェーン又は台帳上に記録されない。

ステップ５０３においてシステムが金融犯罪を検出しなければ、システムはステップ５０４において、通常どおりにトランザクションが公開、検証、確認、記録されるようにする。したがって、ステップ５０５において、トランザクションは検証、確認される。ステップ５０６において、受取先のアカウントに上記金額のＣＢＥＭが入金される。別の任意の変形例では、システムは、金融犯罪トランザクションを検出及び／又はそれについて忠告を受けてもよい。その場合、ステップ５０８において、システムは、受取先のアカウントを凍結してもよい。ステップ５０７において、金融犯罪がないとされると、ステップ５０９において、受取先は、金額ＸのＣＢＥＭを、例えば第三者に送金する等の利用が可能になる。

より好ましくは、ユーザは、ステップ５０１ａにおいてトランザクションに署名する（金額ＸのＣＢＥＭを送る）。したがって、ユーザが自身でトランザクションの逆転が可能でないことが最も好ましい。システム（中央サーバ及び／又はスマートコントラクト）を制御するエンティティ又は団体のみが、ステップ５０４においてユーザの承認なくトランザクションを逆転できる。別の好ましい変形例では、システムは、上述のようにトランザクションを保留するユーザリクエストに応じて、更に１又は複数の条件が、（例えば、予定した受取先によって）所定時間に満たされないトランザクションを逆転してもよい。この形態では、システム（中央サーバ及び／又はスマートコントラクト）は、自動預託者のように機能する。

いくつかの形態において、ユーザは、例えば以下のようにトランザクションを逆転してもよい。スマートコントラクトは、所定の状況下で限定された期間の間、逆転を可能としてもよい。更に／或いは、いくつかの形態の中央サーバ実施は、多署名クライアントウォレットを生成する際に、３つの公開鍵による多署名アドレスを生成してもよい。上述の形態のいくつかにおいて、一方がクライアント、他方が中央サーバに存在するように、２つの鍵組（各鍵組は公開鍵と秘密鍵を含む）を使用してもよい。これにより、クライアントがトランザクションを開始する際、クライアントが提示したトランザクションが最初に中央サーバの承認を得ることが保証される。更に、例えばクライアントがトランザクションを開始する際に、例えばクライアントのウォレットを介してクライアントと通信するため、中央サーバに使用されてもよい。この種の処理において、クライアントにトランザクションを逆転可能とする方法の１つとして、２つの鍵組から、３つの鍵組（即ち、３つの秘密鍵と公開鍵の組）に変更することが考えられる。最初の２つの鍵組は、上述の実施形態通りに使用されてもよい。クライアントが、追加の秘密鍵（更に、この第三鍵組における対応する公開鍵）を更に有する。

中央サーバが１又は複数の公開鍵及び秘密鍵組を有しながら、クライアントが２つの公開鍵及び秘密鍵組を有することになる。なお、多署名アドレスは、４つの公開鍵等より多くの鍵から生成されてもよい。

クライアントの２つの秘密鍵は、同一のウォレットの２つの異なる．ｄａｔ．ｆｉｌｅに格納されてもよい。トランザクションを開始するための、第１秘密鍵は、通常どおり、ｗａｌｌｅｔ．ｄａｔ．ｆｉｌｅに格納されてもよい。トランザクションを確認するための第２秘密鍵は、ｃｏｎｆｉｒｍ．ｄａｔ．ｆｉｌｅに格納されてもよい。

クライアントは、ある金額のＣＢＥＭを送るために、最初に第１秘密鍵を使用してもよい。トランザクションが期限切れになる前に支払いを確認する際、クライアントは確認ボタンを押して、クライアントの第２秘密鍵を使用して、同じトランザクションに署名してもよい。

或いは、クライアントのウォレットは、計算命令（例えば、トランザクションを開始から１週間後に自動的に署名）に応じて、トランザクションが自動的に署名されるよう、クライアントの第２秘密鍵を使用するように構成されてもよい。クライアントは、停止／一時停止ボタンをクリックして、当該自動処理を停止又は一時停止してもよい。上述のトランザクション有効期限は、トランザクションが逆転不能になる時間を選択することで、所望の期間に設定できる。

監視の際、本明細書の他部に記載のように、マネーロンダリング等の不正行為に関するトランザクションを特定、記録、及び／又は報告（例えば、ＳＡＲ（疑わしい取引報告）及び／又はＳＴＲ（疑わしいトランザクション報告）による）するための所定の規則群（例えば法律、及び／又は規制、及び／又はＣＢＥＭユーザによるトランザクションの規制又は制限）に合わせて、トランザクションが監視されてもよい。図５を参照に記載するように、疑わしい金融トランザクションは保留（ステップ５０２ａ）される、更に／或いは逆転（ステップ５０４）されてもよい。

例えば、システムは、様々な形態のＣＢＥＭ支払及びＣＢＥＭウォレットに関する疑わしい及び／又は不正活動を検出してもよい。一つの検出方法として、リスクスコアを判定してもよい。
１．この方法は、リスクのある、及び／又は違法ソースからの資金の流れを特定することに基づいてもよい。これは、あらゆるトランザクションに関わる個人同士が、本明細書で定義される自身の認証済み身分を、１又は複数の制裁リスト（搭乗拒否リスト、公開テロリストリスト、テロリスト容疑者リスト、公開マネーロンダリング業者リスト、例えば米国、国連、及び／又はその他任意で選ばれた国による制裁国リスト）、あらゆる当該疑わしい人物又はエンティティの資金の動き、及び／又は幼児ポルノ、その他暗号通貨窃盗、サイバー犯罪への係わりがあるあらゆる人物及び／又はエンティティを、互いに確認しあうことで行われてもよい。
２．ユーザの疑わしい活動を監視することは、更にトランザクション規模に基づく監視を含んでもよい。疑わしい規模のトランザクションは、少なくとも所定額のトランザクション値、及び／又はトランザクションの頻度に基づいてもよい。当該所定額の例としては、１０，０００ドル以上が挙げられる。当該頻度とは、所定期間中に、同じ及び／又は異なる通貨アドレスの間で、金額が所定金額以上のトランザクションが行われることである。例えば、１日で１０，０００ドル以上のトランザクションが行われた場合に疑わしいとされる。これは、ＢＳＡ（銀行秘密法）に基づき、更にそれを反映させて、ＣＴＲ（通貨取引報告）を発行されること等で実現される。疑わしいトランザクションの別の例としては、アカウントがそのアカウントにしては異常に大きな額を受け取る、及び／又は送金すること、及び／又は過去に個人又はエンティティが過去に疑わしい活動をしていたことが検出されることが挙げられる。
３．個人が、本出願に関わるＣＢＥＭ用のウォレット外で、自身のその他暗号通貨（本出願のＣＢＥＭ以外）を送金した回数を詳細に示す警告及び／又はスコアが利用されてもよい。
４．疑わしい活動の検出は、ウェブブラウザの使用を含んでもよい。当該ブラウザは、政府機関又は関連団体により、閲覧に高いリスクが伴うウェブサイトに対して警告を発することで、疑わしい活動を監視可能とするものであってもよい。

本発明において、対象のＣＢＥＭに関連して使用されるウォレットは、オリジナルビットコイン、Ｅｔｈｅｒ、及び／又はダッシュ等の暗号通貨のような、任意の暗号通貨又は少なくとも複数種の暗号通貨も受取可能であることが最も好ましい。

一例として、ユーザが最も好ましい形態のウォレットを有し、当該ウォレットを全てのデジタル通貨のトランザクションに使用すれば、当該ウォレットは中央サーバ（及び／又はスマートコントラクトコード）と通信し、これにより、システムは本発明の実施形態に係るＣＢＥＭの単純な使用とは異なる疑わしい活動を監視及び検出できる。更なる例として、銀行及び／又はその他金融機関は、その顧客に、最も好ましい形態のウォレットを使用するように求めてもよい。当該ウォレットは、システムがそのシステム外のウォレット及び／又は暗号通貨によるトランザクションを検出したことを、検出し、銀行及び／又はその他金融機関に警告を発することができる。

ＡＭＬ（及びＣＴＦ（テロ資金対策））リスク評価、及び／又は本明細書その他に記載の別金融トランザクションリスク評価のようなトランザクションリスク評価は、通常、本明細書に記載の要素又はその他要素に基づく、第三者によるリスクスコアを判定することで実現される。ＦＡＴＦ（マネーロンダリングに関する金融活動作業部会）は、ＡＭＬ及びテロ対策に助言やガイドラインを提供する、政府間組織である。その活動は更に、いわゆるＦＡＴＦブラックリストと呼ばれる、非協力国又はテロリストのリストを発行することを含む。テロ活動に対する資金提供防止は、更に、ＩＰアドレスを（１）ユーザ登録の際、（２）トランザクションアドレス生成の際、（３）トランザクション開始の際にＩＰアドレスを監視し、更に、コイン使用パターンを監視することで、実現できる。

好ましくは、監視、警告、報告の対象となる特定の種類のマネーロンダリングは、トランザクションロンダリングを含む。トランザクションロンダリングは、マーチャントが、（例えば偽装カスタマーから）支払いを受けるというマネーロンダリングの一種である。即ち、実際の商品又はサービスの取引は行われていない可能性がある。或いは、企業が違法商品（窃盗品又は偽造品、武器、及び／又は麻薬）を販売し、それに対する支払いを、合法的な商品を販売するような印象を与えるように設けられた合法的なオンラインストアで支払いを迂回するように処理して受け取れる。トランザクションロンダリングは、厳格なＫＹＣ要件に従うことなく実行できるので、インターネットビジネスが花盛りの近年では非常に容易となってしまった。合法に偽装された企業は、世界中のどこからでもインターネットを介して運営できる。これらの理由等が、トランザクションロンダリングの防止を非常に困難なものにしている。しかし、本発明の実施形態のＣＢＥＭに関しては少なくとも、ユーザは身分が認証されている必要がある。

第三者ソースにより生成されたデータに基づく警告又はスコアを利用してもよいし、更に／或いは１又は複数のソフトウェアソリューションを利用してもよい。現在利用可能な金融トランザクションコンプライアンス用のソフトウェアソリューションは、好ましくは以下のものを含む。

ＡＭＬ３６０（オーストラリア、シドニー）によるＡＭＬ３６０（ｗｗｗ．ＡＭＬ３６０ｓｏｆｔｗａｒｅ．ｃｏｍ）、ＥａｓｔＮｅｔｓ（登録商標）（ニューヨーク州ニューヨーク）によるＳａｆｅＷａｔｃｈ Ｐｒｏｆｉｌｉｎｇ（ｗｗｗ．ＥａｓｔＮｅｔｓ．ｃｏｍ）、Ｆｉｓｅｒｖ（ウィスコンシン州ブルックフィールド）によるＡＭＬ Ｍａｎａｇｅｒ（ｗｗｗ．ｆｉｓｅｒｖ．ｃｏｍ）。

ソフトウェアによるＡＭＬビジネス要件には以下のものをはじめとする監視が挙げられる。
・トランザクション監視システムにより、疑わしい取引報告（ＳＡＲ）又は疑わしいトランザクション報告（ＳＴＲ）の提出となり得る疑わしいトランザクションのパターンを識別。
・通貨トランザクション報告（ＣＴＲ）システムにより、多額の現金トランザクション報告要件（米国では１０，０００ドル以上）を監視。
・顧客身元管理システムにより、各種ネガティブリスト（ＯＡＦＣ等）を確認、監視し、ＫＹＣ要件の初期及び継続部分を示す。電子的検証を別のデータベースに対して確認し、（英国では、選挙人名簿、銀行や信用調査機関が使用する「共有」データベース、電話番号リスト、電気配給事業者リスト、郵便配達データベース）等のＩＤの積極的確認を提供。
・コンプライアンスソフトウェア。

更なる監視として、登録ユーザに関連付けられた１又は複数のＩＰアドレスを、テロ資金活動、マネーロンダリング、金融マネーロンダリング、その他不正活動に関連付けられたＩＰアドレスの１又は複数のデータベースに対して、照合することが挙げられる。これは、システムにおけるユーザ登録の際、関連付けられた１又は複数のＩＰアドレスの変更につながるあらゆるユーザ更新、所定の間隔で定期的に、トランザクションアドレス生成の際、あらゆるトランザクション提示の際、トランザクション開始の際、疑わしい活動に関する所定の規格又は所定の基準に合うトランザクションパターンの際、あらゆる種類（トランザクション金額、疑わしい個人又はエンティティ等に対するトランザクション）に関するリスクスコア閾値に到達した際の内の任意の１又は複数の、好ましくは全てのタイミングで実行される。

更なる例として、１又は複数のユーザのＩＰアドレスを上記のようなタイミングで確認して、当該１又は複数のアドレスが、輸出禁止及び／又は制裁中のいずれかの国に存在する場合、トランザクションを停止、及び／又は逆転してもよい。

監視ソフトウェアは、以下のものによる規則及び／又はこれらに関する規則を含んでもよい。
・ＦｉｎＣＥＮ（金融犯罪取締ネットワーク）
・ＢＳＡ（銀行秘密法）
・ＡＭＬ（反マネーロンダリング）
・ＳＡＲ（疑わしい取引報告）
・ＲＭＬＯ（住宅担保付ローン原債権者）
・ＨＩＦＣＡ（金融犯罪集中地域）
・ＨＩＤＴＡ（麻薬取引集中地域）
・ＯＦＡＣ（外国資産管理局）
・財務省
・金融犯罪取締ネットワーク（ＦｉｎＣＥＮ）
・国税庁（ＩＲＳ）
・消費者金融保護局（ＣＦＰＰＢ）
・州の規制当局

スマートコントラクト内のソースコードが、規制コンプライアンス確認の一部又は全部、及び／又は中央サーバのその他機能を制御してもよい。
１）承認済みトランザクションアドレスがやはり必要であるが、この構成では、単独署名又は多署名通貨アドレスであってもよい。
２）クライアント身元に結び付けられる承認された通貨アドレスは、上述のように生成される。
３）承認済みトランザクションネットワークがやはり必要であるが、この構成では、承認制御は、ＣＢＥＭがやり取りできる前に、所定の入力又は条件への適合が求められる、１以上の中央サーバの一部又は全部の機能を実現するためのスマートコントラクトを利用して実現される。
４）クライアント／ユーザ、及び／又は運営団体による制御／承認処理の一部又は全部が、スマートコントラクトに組み込まれる。

分散型台帳を実行するソフトウェアは、署名されたトランザクションを受信し、例えば各種条件が合うまで保留し、その後記録するようにプログラムされる。保留は、公開及び検証前でも後でもよい。条件の１つとしては、中央サーバの承認を得ることが挙げられる。

任意で、スマートコントラクトは自身の又は中央サーバによるリスクスコア確認を開始し、リスクスコアが閾値以上となると、スマートコントラクトはトランザクションを拒否してもよい。スマートコントラクトは、中央サーバの既存の制御の一部を、分散型台帳を実行ソフトウェアに単純に移転するものであるため、実質的に中央サーバの一部とみなすことができる。

以下の例示的ワークフローを採用してもよい。

クライアントは、スマートコントラクトを開始して、ＣＢＥＭ送金を開始する。ここで、ＣＢＥＭ送金はスマートコントラクトに予め設定された複数のステップを経ることとなる。即ち、有効にＣＢＥＭを送金するには、スマートコントラクトに予め設定された基準を満たさなければならない。

スマートコントラクトに予め設定された当該ステップ及び基準は、例えば図５に概略的に示す、以下の経時的イベントを含んでもよい。別の例としては、トランザクションを保留し、各種条件が満たされたか確認し、スマートコントラクト（例えば、中央サーバによるリスクスコア確認、中央サーバによる承認）が完了又は失敗、完了、ネットワークへの公開、検証、記録するというフローが挙げられる。

各種条件が満たされたかを確認するために、スマートコントラクトは、自身で全ての処理を完了してもよいし、中央サーバと協働で全ての処理を完了してもよい。後者の場合、スマートコントラクトは、リクエストを発行し、１以上の中央サーバからの回答を得るインタフェースとして機能する。その後、スマートコントラクトは１以上の中央サーバからの回答を使用して、全ての必要な条件が満たされたかを確認する。スマートコントラクトは更に、第三者ソース等のその他任意のソースに対して、条件が満たされたかを確認してもよい。

図６は、ＡＭＬ及びリスク評価モジュールの要素を示すフローチャートである。当該要素は、関連データを有する各種データベースに接続することと、トランザクション及び提示されたトランザクションを、当該データベースからのデータと、本システムのＩＤデータベースからのデータと、本システムのトランザクションデータベースからのデータと、提案されたトランザクション（及び／又は確認中のトランザクション）からのデータと、例えば、ＦＡＴＦ要件によるコンプライアンスアルゴリズムを使用して分析することと、リスクを判定することと、当該リスクを適宜／必要に応じて報告することと、更に上述の図５の１以上のアクションを実行してトランザクションを保留又は逆転する更に／或いはアカウントを凍結することとを含む。例えば、ユーザがシステムを介してトランザクションを提案する場合（図５のステップ５０１ａ）、ユーザのウォレットは、中央サーバに対してトランザクションの承認をリクエストする。本明細書に記載のとおり、図６に示すようにシステムが監視（ステップ５０３）を実行する間、保留（ステップ５０２ａ）が実行されてもよい。同様に、システムがステップ５０７同様に監視を行う場合、図６に示し、本明細書で説明する処理が行われてもよい。例えばＦＡＴＦ対応アルゴリズムのようなコンプライアンスアルゴリズムは、以下のものを判定する。
・クライアントＩＤ、受取先ＩＤ、クライアント及び受取先の所在地（国）、ウォッチリストデータ、及びその他外部データから、ＫＹＣを判定。
・法令、ブロックチェーントランザクションデータ、及び外部データから、トランザクションリスクを判定。
・顧客ＩＤ、顧客の国、商品データ、企業内部データから、内部リスクを判定。
・法律、ガイドライン、メディア情報、広域的情報から、外部リスクを判定。

アルゴリズムは、入力データを処理し、各種関連リスクのレベル又はスコアを判定し、警告等の信号を電子装置（例えば、企業コンプライアンス部署のコンピュータ）に送信してもよい。送信は、リスクスコアが所定の閾値を超えると、例えばディスプレイのモニターのような装置への表示、及び／又は聴覚的警告、及び／又は点滅等の視覚的警告として実行されてもよい。例えばＡＭＬ、ＫＹＣ、ＣＴＦ、ＢＳＡ，及び／又はＦＡＴＦ等のように、監視される各種リスクに対して、閾値が存在してもよい。コンプライアンス部署の装置、及び／又はシステムは、自動的にＳＡＲ、ＳＴＲ及び／又はその他レポートを作成し、自動で適切な１以上の権限者に送信してもよい。リスクがかなり高い（所定の閾値に到達）場合、中央サーバが許可を出す前に、中央サーバが許可を出した後、ネットワークに公開される前又は後、及び／又は認証後にトランザクションは停止、遅延、及び／又は逆転されてもよい（但し、ネットワークによって承認されると、トランザクションは逆転しない方が好ましい）。保証されている場合、これらの内の任意のタイミングで、特に認証済みのトランザクションに関して、受取先及び送り主のＣＢＥＭアカウントを凍結してもよい。

別の実施形態では、ウォレットがオンライン、オフラインのいずれで格納されているにかかわらず、多署名ウォレットアドレスが使用されることが好ましい。多署名により、中央システムが、トランザクションに求められるＮの署名の内のＭの署名（例えば、３つの内の２つ）となることが可能となる。したがって、システムは、本明細書の他部に記載のように、ユーザからの提案されたトランザクションを多署名ウォレットを介して受信し、本明細書に記載のように金融トランザクション監視を実行し、トランザクションに署名するか、疑わしい活動又はトランザクションに関わるその他金融リスクがある限り及びなくなるまで、署名を保留してもよい。

このシステムは、図４に示すものと同様又は同じであってもよい。ストレージ４１９は、システム命令を、例えば不揮発性メモリに格納してもよい。中央認証サーバ４０１は、本明細書に記載のあらゆる表示及び本明細書に記載のあらゆる警報、及び／又はその他警告機構のため、命令に関連付けられた１又は複数のモニター（グラフィカルユーザインタフェース）を有してもよい。ストレージ４１９は更に、本明細書に記載の金融リスク及び／又はリスクスコア判定に応じて、監視、検出、及び／又は警告のための、本明細書に記載のソフトウェアを更に有してもよい。外部資源４１８は、リスクを計算するためのデータを取得するための各種データベース、及び／又は本明細書に記載のリスクを計算するための外部ソフトウェアを含んでもよい。

図７は、１又は複数の形態又は図４の変形例に関わる例示的な変形システムの概要を示す。ここでは、適用ブロックチェーン（又は分散型台帳）７００と、スマートコントラクトが使用される。図示のように、プライバシー層７０２を有する適用ブロックチェーン又は分散型台帳が設けられる。当該層は、ブロックチェーンアクセスに対する許可管理層として機能できる。これは、例えば、管理用に、イーサリアムブロックチェーン、例えば、ブロックチェーン７０６上に構築されてもよい。図示のように、ファイル（例えば、生体特徴データ及びその他ファイル）を格納するための機構が存在してもよい。これら要素は、ＲＥＳＴｆｕｌＡＰＩのようなＡＰＩ（アプリケーションプログラミングインタフェース）７０４、及び例えばブロックチェーンデータベース７０８に接続され、ビッグチェーンＤＢのようなストレージの提供及び／又は改善が実現されてもよい。これは、例えばバイオメトリックアップリケ―ション又はウェブサイト等に接続され得る。更に別の構成も採用可能である。この実施形態において、ブロックチェーンの管理は、スマートコントラクト７０７を含んでもよい。実際、ブロックチェーン７０６は、この実施形態又は本明細書における実施形態の一部又は全部において、分散型台帳の代わりに使用できる。更に、実施形態の一部又は全部において、別の形態の分散型ストレージを利用できる。

図４同様、クライアントノード４１４、４１５と、トランザクションデータベース４１３及びクライアント情報データベース１１５を含む１又は複数の中央サーバ４０１が設けられてもよい。第三者ソースと、ネットワーク外団体７１４は、図４の外部資源と、ネットワーク外ノードを含んでもよい。全てのシステム要素は、インターネット７２０を介して通信可能である。実施形態の一部又は全部では、中央サーバ機能を複数の中央サーバに分けてもよい。上述の実施形態の一部又は全部において、１又は複数の中央サーバは、クライアントが実行したいトランザクション（承認済みトランザクション）についてのクライアント情報（トランザクションの疑わしさ／マネーロンダリングである可能性についての情報等）を提供することで、クライアントに許可を与えてもよい。別の実施形態において、１又は複数の中央サーバは、トランザクションを拒否してもよい。本明細書の他部に記載のように、これは、１又は複数の中央サーバにより判定される、１又は複数の条件の存在に応じた自動承認を要することで実現できる。具体的な方法の１つとして、多署名ウォレットを使用してもよい。この場合、中央サーバは、クライアントが生成したトランザクションを、そのトランザクションが行われるまでに署名しなければならない。このトランザクションの承認を実現できる別の方法として、「スマートコントラクト」という処理がある。スマートコントラクトにおいて、トランザクションを実行するために必要な１又は複数の条件が存在するかは、コンピュータ命令により判定される。実際、１又は複数の中央サーバの機能の一部又は全部は、単純にコンピュータ命令を、ブロックチェーンを制御するピアツーピアネットワーク上で動作するソフトウェアのソースコードに加えることで実現される。例えば、スマートコントラクトは、サーバ上で実行されるか、分散型アプリケーション（ＤＡｐｐとも称される）として実行される。ＤＡｐｐは、フロントエンド（ＨＴＭＬの場合）と、バックエンド（実質的に、フロントエンド用のデータベース）を有する。

いくつかの形態において、少なくとも１つの専用ノードが第１の個人又はユーザの個人身元の承認の署名を実行する。所与の専用ノードは、１又は複数のサーバを含んでもよい。所与の専用ノードは、新規ブロックを生成する及び／又は承認に署名するように構成された公開ノード又は秘密ノードであってもよい。

いくつかの形態において、システムは、ＳＲＵ（システム規制ユーティリティ）又はシステムプロセッサにより動作されてもよい。システムプロセッサは、１又は複数のサーバ及び／又はスマートコントラクトを含んでもよい。システムプロセッサ又は１以上のサーバは、クライアント／サーバ構造、ピアツーピア構造、及び／又はその他構造に従って、１又は複数のコンピューティングプラットフォームと通信するように構成されてもよい。ユーザは、システムに１以上のコンピューティングプラットフォームを介してアクセスしてもよい。１以上のサーバ及び／又はスマートコントラクトは、機械可読命令を実行するように構成されてもよい。機械可読命令は、１又は複数のＳＲＵ（システム規制ユーティリティ）及び／又はその他機械可読命令要素を含んでもよい。ＳＲＵは、ＣＢＥＭトランザクションを受信でき、分散型ストレージ、分散型台帳、ブロックチェーン、又はその他適切な分散型トランザクション機構に動作可能に接続できる。ＳＲＵは、スマートコントラクト及び／又は１又は複数のサーバ上のコンピュータ命令として実現されてもよく、システムプロセッサにより動作されるものと考えてもよい。システムプロセッサは、中央サーバと協働するスマートコントラクト、中央サーバのみ、又はスマートコントラクトのみで構成されてもよい。

疑わしい活動についての警告及び／又は報告が行われる２つの例を以下に示す。具体的には、例Ａと例Ｂである。例Ａにおいて、ＣＢＥＭの金額が、対応ネットワーク外の通貨アドレスから、対応ネットワーク内の通貨アドレスへと送られる。例Ｂにおいて、ＣＢＥＭの金額が、対応ネットワークから、対応ネットワーク外の通貨アドレスに送られる。

例Ａにおいて、中央サーバは、検出に応じて以下のアクションの内の任意のもの、又は全てを実行してもよい。
１．強制ＡＭＬチェック（後ろ向きトランザクション分析）
２．システムが、ＣＢＥＭの金額を対応ネットワーク外からの受信を検出したことをユーザ（クライアント）に警告
３．ユーザ又はクライアントが、トランザクションに関するＡＭＬリスクの分析レポートを取得（例えば購入）するか選択可能である
４．システムが、当該所定のＣＢＥＭ金額に関連付けられた適切なフラグ又はラベルを提供し、（ｉ）ＣＢＥＭの金額の送り主と（ｉｉ）送り主の通貨アドレスに関連付けられた過去のトランザクションに結び付ける

例Ｂにおいて、ユーザ又はクライアントがトランザクション（送金）リクエストを発した際に、システムは当該ユーザに、対応ネットワーク外の通貨アドレスに金額を送金していることを警告してもよい。ユーザは更に、システムのＡＭＬチェック（後ろ向きトランザクション分析）を利用して、少なくとも部分的に、当該受取先通貨アドレスの関連付けられた過去のトランザクションに基づいて、対象の受取通貨アドレスのＡＭＬリスクを評価可能であってもよい。

システムは更に任意で、ＣＢＥＭの金額を送金できる前に、ユーザに追加確認する機会を与えてもよい。当該追加確認リクエストは、ＣＢＥＭ送金動作に伴うリスクについての警告メッセージを含んでもよい。
（ｉ）ここで、例えば送り主は、このようにＡＭＬリスクが伴うようなトランザクションは自己責任でするべきである。更に／或いは、
（ｉｉ）対象の受取先アドレスに関するＡＭＬリスクの例えば低、中、高という評価は、ユーザがシステムＡＭＬチェックを購入することを選択した場合にのみ提供されてもよい。

例Ａ及びＢの両方で、ＡＭＬチェックは強制で、ユーザがＡＭＬリスク分析報告を金銭により取得するか否かを選択できることが好ましい。更に／或いは、送り主（例Ａ：例えば、レポートは送り主通貨アドレス、その過去のトランザクション、ＣＢＥＭ金額の元を含んでもよい）又は受取先（例Ｂ：例えば、レポートは受取先通貨アドレス、その過去のトランザクションを含んでもよい）が違法トランザクション活動に関わることが判明した場合に、中央サーバは自動的に規制に関する政府機関へのＳＡＲ、ＳＴＲ、又はその他レポートを作成してもよい。

当業者であれば、上述の個人／クライアント認証及び検証方法は、１又は複数のコンピュータプログラムにより実行及び／又は制御されてもよいことが容易に理解できよう。当該コンピュータプログラムは、典型的にはコンピューティングデバイス内の計算資源を利用して実行される。アプリケーションは、非一時的媒体に格納される。非一時的媒体の例としては、例えばフラッシュメモリのような不揮発性メモリが挙げられ、揮発性メモリの例としてはＲＡＭが挙げられる。コンピュータ命令は、プロセッサにより実行される。これらメモリは、本明細書に記載の技術的概念に係るコンピュータ実行方法の全てのステップを実行する、コンピュータ実行可能命令を含むコンピュータプログラムを記憶する、記録媒体の例である。

本発明は、トランザクションの安全性及びトレサビリティの向上という効果を実現する。この効果は、セキュリティの向上、ＣＢＥＭ窃盗の試みの低減が統計的測定により確認されたことからも、具体的且つ確実なものである。したがって、本発明は、有用、具体的、且つ確実な効果を実現する。本発明が実現する安全性の向上は、多署名アドレスの生成及びｐａｙ−ｔｏ−ｓｃｒｉｐｔ−ｈａｓｈトランザクション及びその特定な変形、形態、及び適用を要するため、暗号通貨に関わるデータが変換されるという点で、機械又は変換試験の条件は満たされる。具体的な方策の形態により、この概念は抽象的とはならない。

本明細書において、本発明を特定の好ましい実施形態を参照して説明、記載、定義したが、本明細書における形態の参照及び例示が発明をいかようにも制限することはない。本発明に対して、その技術的概念の広い範囲から逸脱することなく、様々な変形例や変更を加えられることは自明であろう。記載された好ましい実施形態は単に例示的なものであり、本明細書に記載された技術的概念の範囲を網羅するものではない。

したがって、保護の範囲は、明細書に記載された好ましい実施形態に限定されず、後続の請求項によってのみ限定される。

Claims (53)

1. 暗号型電子マネー（ＣＢＥＭ）を伴うトランザクションを監視及び規制するシステムであって、
   システム規制ユーティリティを実行するシステムプロセッサ（４２０及び／又は７０７）であって、クライアントＩＤ登録、クライアント通貨アドレス、ＣＢＥＭトランザクションを処理するために、
   ・１又は複数のクライアントの承認済み通貨アドレスを生成するために、クライアントウォレット（４１６、４１７）と通信し、
   ・１又は複数のクライアントの承認済み通貨アドレスを生成するためのリクエストを承認し、
   ・１又は複数の承認済みトランザクションを生成するために、前記クライアントウォレット（４１６、４１７）と通信し、
   ・ＣＢＥＭの単位を、通貨アドレスに送金するため、１又は複数のトランザクションを承認し、
   ・中央運営団体又はクライアントが策定したトランザクション基準を使用して、トランザクションを検証し、
   ・トランザクションデータベース（４１３）内にトランザクション情報を格納するように構成されたシステムプロセッサを有し、
   前記システムは更に、
   １又は複数の承認済み通貨アドレスと、
   承認済みトランザクションネットワークと、
   前記システムプロセッサ（４２０及び／又は７０７）に対して通信可能に接続されるクライアント情報データベース（１１５）と、
   前記システムプロセッサ（４２０及び／又は７０７）に対して通信可能に接続されるトランザクションデータベース（４１３）と、
   クライアントウォレット（４１６、４１７）が設けられる少なくとも１つのクライアント装置（４１４、４１５）とを有し、
   前記少なくとも１つのクライアント装置は、
   ・１又は複数の承認済み通貨アドレスを生成するための許可を、前記システムプロセッサ（４２０及び／又は７０７）から取得し、
   ・ＣＢＥＭの単位を受取先の通貨アドレスに送金するため、１又は複数の承認済みトランザクションを生成する許可を、前記システムプロセッサ（４２０及び／又は７０７）から取得し、
   ・ＣＢＥＭの単位を受取先の通貨アドレスに送金するため、前記トランザクションを署名することにより、１又は複数の承認済みトランザクションを生成するように構成され、
   前記システムプロセッサ（４２０及び／又は７０７）は、前記承認済みトランザクションを受信すると、前記トランザクションを許可する前に、所定時間、前記承認済みトランザクションを遅延させるように構成され、１又は複数の条件が満たされたか否かの判定に応じて許可されるかが決まる、システム。
2. 前記システムプロセッサは、中央サーバを含む、請求項１に記載のシステム。
3. 前記システムプロセッサは、スマートコントラクトを使用して制御されるプロセッサを含む、請求項１に記載のシステム。
4. 前記システムプロセッサは、スマートコントラクトにより制御される中央サーバとプロセッサとを含む、請求項１に記載のシステム。
5. 複数のクライアントが存在する、請求項１から４のいずれか１項に記載のシステム。
6. 前記システムプロセッサは更に、
   クライアントの個人アカウントを生成し、
   クライアントが提出した、実際の個人身元情報を確認し、記録し、
   クライアントが提出した、個人認証クレデンシャルを記録し、
   クライアントが生成した、承認済み通貨アドレスを記録し、
   クライアントの承認済み通貨アドレス、個人身元情報、個人認証クレデンシャルを、前記クライアント情報データベース内にマッピング及び格納し、
   前記少なくとも１つのＣＢＥＭの単位の所有権を、クライアントの通貨アドレスを使用して、トランザクションデータベースに記録するように構成される、請求項１から５のいずれか１項に記載のシステム。
7. 前記１又は複数の条件は、ＡＭＬ、ＫＹＣ、ＣＴＦ、ＢＳＡ、ＦＡＴＦの内の少なくとも１つに関するトランザクション基準に基づく、前記トランザクションの準拠に対する疑わしさの度合いに関する、請求項１から６のいずれか１項に記載のシステム。
8. 前記システムプロセッサが所定の疑わしさの度合いであると判定すると、前記システムプロセッサがトランザクションを停止する、請求項１から７のいずれか１項に記載のシステム。
9. 前記システムプロセッサは、前記少なくとも１つの条件が満たされたという通知を受信せずに、前記所定期間が経過すると、前記トランザクションを停止する、請求項１から８のいずれか１項に記載のシステム。
10. 前記システムプロセッサは、前記トランザクションをキャンセルするという通知を前記クライアントから受信せずに、前記所定期間が経過すると、前記トランザクションを許可する、請求項１から９のいずれか１項に記載のシステム。
11. 前記システムプロセッサは、前記少なくとも１つの条件が満たされたという通知を受信せずに、前記所定期間が経過すると、前記トランザクションを停止する、請求項１から１０のいずれか１項に記載のシステム。
12. 前記１又は複数の条件についての前記通知は、第三者の電子装置から、前記システムプロセッサが受信する、請求項１から１１のいずれか１項に記載のシステム。
13. 暗号型電子マネー（ＣＢＥＭ）を伴うトランザクションを監視及び規制するシステムであって、
    システム規制ユーティリティを実行するシステムプロセッサ（４２０及び／又は７０７）であって、クライアントＩＤ登録、クライアント通貨アドレス、ＣＢＥＭトランザクションを処理するために、
    ・１又は複数のクライアントの承認済み通貨アドレスを生成するために、クライアントウォレット（４１６、４１７）と通信し、
    ・１又は複数のクライアントの承認済み通貨アドレスを生成するためのリクエストを承認し、
    ・１又は複数の承認済みトランザクションを生成するために、前記クライアントウォレット（４１６、４１７）と通信し、
    ・ＣＢＥＭの単位を、通貨アドレスに送金するため、１又は複数のトランザクションを承認し、
    ・中央運営団体又はクライアントが策定したトランザクション基準を使用して、トランザクションを検査し、
    ・トランザクションデータベース（４１３）内にトランザクション情報を格納するように構成されたシステムプロセッサを有し、
    前記システムは更に、
    １又は複数の承認済み通貨アドレスと、
    承認済みトランザクションネットワークと、
    前記システムプロセッサ（４２０及び／又は７０７）に対して通信可能に接続されるクライアント情報データベース（１１５）と、
    前記システムプロセッサ（４２０及び／又は７０７）に対して通信可能に接続されるトランザクションデータベース（４１３）と、
    クライアントウォレット（４１６、４１７）が設けられる少なくとも１つのクライアント装置（４１４、４１５）とを有し、
    前記少なくとも１つのクライアント装置は、
    ・１又は複数の承認済み通貨アドレスを生成するための許可を、前記システムプロセッサ（４２０及び／又は７０７）から取得し、
    ・ＣＢＥＭの単位を受取先の通貨アドレスに送金するため、１又は複数の承認済みトランザクションを生成する許可を、前記システムプロセッサ（４２０及び／又は７０７）から取得し、
    ・ＣＢＥＭの単位を受取先の通貨アドレスに送金するため、前記トランザクションを署名することにより、１又は複数の承認済みトランザクションを生成するように構成され、
    前記システムプロセッサ（４２０及び／又は７０７）は、前記承認済みトランザクションの受信、前記トランザクションネットワークによる前記承認済みトランザクションの検証及び確認、前記受取先のアカウントの前記ＣＢＥＭ受け取り後、中央運営団体又はクライアントが策定したトランザクション基準に基づく、前記トランザクションの準拠に対する疑わしさの度合いを検出すると、前記受取先のアカウントを凍結して、ＣＢＥＭ転送不能とするように構成された、システム。
14. 前記システムプロセッサは、中央サーバを含む、請求項１３に記載のシステム。
15. 前記システムプロセッサは、スマートコントラクトを使用して制御されるプロセッサを含む、請求項１３に記載のシステム。
16. 前記システムプロセッサは、スマートコントラクトにより制御される中央サーバとプロセッサとを含む、請求項１３に記載のシステム。
17. 前記システムプロセッサは更に、
    クライアントの個人アカウントを生成し、
    クライアントが提出した、実際の個人身元情報を確認し、記録し、
    クライアントが提出した、個人認証クレデンシャルを記録し、
    クライアントが生成した、承認済み通貨アドレスを記録し、
    クライアントの承認済み通貨アドレス、個人身元情報、個人認証クレデンシャルを、前記クライアント情報データベース内にマッピング及び格納し、
    前記少なくとも１つのＣＢＥＭの単位の所有権を、クライアントの通貨アドレスを使用して、トランザクションデータベースに記録するように構成される、請求項１３から１６のいずれか１項に記載のシステム。
18. 前記システムプロセッサは、クライアントのトランザクションにおける疑わしいトランザクションを監視し、前記少なくとも１つの基準は、金融犯罪リスク、テロ資金援助リスク、政府の制裁リストに反するトランザクションであるリスク、トランザクションロンダリングリスクの内の少なくとも１つを示すものであり、前記承認済みトランザクションネットワークは、前記システムプロセッサに格納された前記中央トランザクション基準に沿わないあらゆるトランザクションを拒絶するように変形されてもよい、請求項１３から１７のいずれか１項に記載のシステム。
19. 前記トランザクション基準は、マネーロンダリング等の不正行為に関する可能性が高い疑わしいトランザクションを停止するために、中央運営団体によって策定され、前記システムプロセッサは、疑わしいトランザクションの通知を得ると、前記承認済みトランザクションを停止すること及び、警告を発することの少なくとも一方を行う、請求項１３から１８のいずれか１項に記載のシステム。
20. 前記システムプロセッサは、トランザクションと、受取先の少なくとも一方に関するリスクスコアを決定及び取得し、前記少なくとも１つの基準が前記リスクスコアに関連する、請求項１３から１９のいずれか１項に記載のシステム。
21. 前記リスクスコアは、前記システムにおける少なくとも１つのクライアントのＩＤ関連情報と制裁リストとの比較、少なくとも１つのクライアントの過去のトランザクションに疑わしい活動があるかの分析、前記承認済みトランザクションが疑わしい活動のものかの分析、トランザクションロンダリングを識別する分析、前記クライアントのＣＢＥＭのソースがリスクがあるか及び違法であるかの内の少なくとも一方であるソースかの分析の内の少なくとも１つに基づく、請求項２０に記載のシステム。
22. 前記リスクスコアは、（ｉ）前記システムプロセッサが前記対応ネットワーク外からのＣＢＥＭの受信又は前記対応ネットワーク外へのＣＢＥＭの送信を監視している状況で、前記対応ネットワークにおける前記クライアントウォレット外のＣＢＥＭの送信をクライアントが行った１又は複数の回数と、（ｉｉ）前記システムプロセッサが前記クライアントのウェブブラウザを監視することで、前記クライアントが閲覧した少なくとも１つのウェブサイトに関するデータを取得する状況で、前記ウェブサイトに関する詐欺のリスク、金融犯罪のリスク及びテロのリスクの内の少なくとも１つに基づき増加する、請求項２０又は２１に記載のシステム。
23. 前記システムプロセッサは、承認済みトランザクションが疑わしい活動に関するかを監視し、前記リスクスコアと、前記リスクスコアを判定するためのデータを第三者ソースから取得する、請求項１３から２２のいずれか１項に記載のシステム。
24. 前記クライアントウォレットは、多署名ウォレット及び／又はスマートコントラクトを処理するためのウォレットである、請求項１３から２２のいずれか１項に記載のシステム。
25. 前記クライアントウォレットは、前記承認済みトランザクションを生成する場合以外では、オフラインで格納される、請求項１３から２４のいずれか１項に記載のシステム。
26. 暗号型電子マネー（ＣＢＥＭ）を伴うトランザクションを監視及び規制する個人認証及び確認システムであって、
    システム規制ユーティリティを実行するシステムプロセッサ（４２０及び／又は７０７）であって、クライアントＩＤ登録、クライアント通貨アドレス、ＣＢＥＭトランザクションを処理するために
    ・１又は複数のクライアントの承認済み通貨アドレスを生成するために、クライアントウォレット（４１６、４１７）と通信し、
    ・１又は複数のクライアントの承認済み通貨アドレスを生成するためのリクエストを承認し、
    ・１又は複数の承認済みトランザクションを生成するために、前記クライアントウォレット（４１６、４１７）と通信し、
    ・ＣＢＥＭの単位を、通貨アドレスに送金するため、１又は複数のトランザクションを承認し、
    ・中央運営団体又はクライアントが策定したトランザクション基準を使用して、トランザクションを検査し、
    ・トランザクションデータベース（４１３）内にトランザクション情報を格納するように構成されたシステムプロセッサを有し、
    前記システムは更に、
    １又は複数の承認済み通貨アドレスと、
    承認済みトランザクションネットワークと、
    前記システムプロセッサ（４２０及び／又は７０７）に対して通信可能に接続されるクライアント情報データベース（１１５）と、
    前記システムプロセッサ（４２０及び／又は７０７）に対して通信可能に接続されるトランザクションデータベース（４１３）と、
    クライアントウォレット（４１６、４１７）が設けられる少なくとも１つのクライアント装置（４１４、４１５）とを有し、
    前記少なくとも１つのクライアント装置は、
    ・１又は複数の承認済み通貨アドレスを生成するための許可を、前記システムプロセッサ（４２０及び／又は７０７）から取得し、
    ・ＣＢＥＭの単位を受取先の通貨アドレスに送金するため、１又は複数の承認済みトランザクションを生成する許可を、前記システムプロセッサ（４２０及び／又は７０７）から取得し、
    ・ＣＢＥＭの単位を受取先の通貨アドレスに送金するため、前記トランザクションを署名することにより、１又は複数の承認済みトランザクションを生成するように構成され、
    前記システムプロセッサ（４２０及び／又は７０７）は、承認済みトランザクションを前記クライアント装置から受信すると、前記トランザクション基準に基づいて前記トランザクションを検査し、承認済みトランザクションの疑わしさの度合いを判定し、前記疑わしさの度合いが所定の閾値を超え、所定の規則に基づき違法活動の可能性が高いこと示す場合に、前記トランザクションを拒否し、前記疑わしさの度合いは、前記クライアント情報データベースのクライアント情報、前記トランザクションデータベース、前記承認済みトランザクションに関する前記トランザクション情報、中央運営団体により策定された基準、前記クライアントの所在地、前記受取先の所在地、及び外部ソースに少なくとも部分的に基づいて判定される、システム。
27. 前記システムプロセッサは、中央サーバを含む、請求項２６に記載のシステム。
28. 前記システムプロセッサは、スマートコントラクトを使用して制御されるプロセッサを含む、請求項２６に記載のシステム。
29. 前記システムプロセッサは、スマートコントラクトにより制御される中央サーバとプロセッサとを含む、請求項２６に記載のシステム。
30. 複数のクライアントが存在する、請求項２６から２９のいずれか１項に記載のシステム。
31. 前記システムプロセッサは更に、
    クライアントの個人アカウントを生成し、
    クライアントが提出した、実際の個人身元情報を確認し、記録し、
    クライアントが提出した、個人認証クレデンシャルを記録し、
    クライアントが生成した、承認済み通貨アドレスを記録し、
    クライアントの承認済み通貨アドレス、個人身元情報、個人認証クレデンシャルを、前記クライアント情報データベース内にマッピング及び格納し、
    前記少なくとも１つのＣＢＥＭの単位の所有権を、クライアントの通貨アドレスを使用して、トランザクションデータベースに記録するように構成される、請求項２６から３０のいずれか１項に記載のシステム。
32. 前記中央運営団体又はクライアントが策定した前記基準は、トランザクションロンダリングに関する基準を含み、前記システムプロセッサは、トランザクションロンダリングの可能性が高いと判断した場合に、トランザクションを拒否する、請求項２６から３１のいずれか１項に記載のシステム。
33. 前記中央運営団体又はクライアントが策定した前記基準は、前記トランザクションにおける前記ＣＢＥＭのソースに関する基準を含む、請求項２６から３２のいずれか１項に記載のシステム。
34. 前記システムプロセッサは、前記トランザクションデータベース及び外部ソースからの入力を使用する、請求項２６から３３のいずれか１項に記載のシステム。
35. 前記中央運営団体又はクライアントが策定した前記基準は、制裁リストに関する基準を含む、請求項２６から３４のいずれか１項に記載のシステム。
36. 前記システムプロセッサは、前記クライアント又は受取先がウェブサイトにアクセスしたかを判定し、前記中央運営団体又はクライアントが策定した前記基準は、アクセスされたウェブサイトの種類に関する基準を含む、請求項２６から３５に記載のシステム。
37. 暗号型電子マネー（ＣＢＥＭ）を伴うトランザクションを監視及び規制する個人認証及び確認システムであって、
    システム規制ユーティリティを実行するシステムプロセッサ（４２０及び／又は７０７）であって、クライアントＩＤ登録、クライアント通貨アドレス、ＣＢＥＭトランザクションを処理するために
    ・１又は複数のクライアントの承認済み通貨アドレスを生成するために、クライアントウォレット（４１６、４１７）と通信し、
    ・１又は複数のクライアントの承認済み通貨アドレスを生成するためのリクエストを承認し、
    ・１又は複数の承認済みトランザクションを生成するために、前記クライアントウォレット（４１６、４１７）と通信し、
    ・ＣＢＥＭの単位を、通貨アドレスに送金するため、１又は複数のトランザクションを承認し、
    ・中央運営団体又はクライアントが策定したトランザクション基準を使用して、トランザクションを検査し、
    ・トランザクションデータベース（４１３）内にトランザクション情報を格納するように構成されたシステムプロセッサを有し、
    前記システムは更に、
    １又は複数の承認済み通貨アドレスと、
    承認済みトランザクションネットワークと、
    前記システムプロセッサ（４２０及び／又は７０７）に対して通信可能に接続されるクライアント情報データベース（１１５）と、
    前記システムプロセッサ（４２０及び／又は７０７）に対して通信可能に接続されるトランザクションデータベース（４１３）と、
    クライアントウォレット（４１６、４１７）が設けられる少なくとも１つのクライアント装置（４１４、４１５）とを有し、
    前記少なくとも１つのクライアント装置は、
    ・１又は複数の承認済み通貨アドレスを生成するための許可を、前記システムプロセッサ（４２０及び／又は７０７）から取得し、
    ・ＣＢＥＭの単位を受取先の通貨アドレスに送金するため、１又は複数の承認済みトランザクションを生成する許可を、前記システムプロセッサ（４２０及び／又は７０７）から取得し、
    ・ＣＢＥＭの単位を受取先の通貨アドレスに送金するため、前記トランザクションを署名することにより、１又は複数の承認済みトランザクションを生成するように構成され、
    前記システムプロセッサは（４２０及び／又は７０７）は、（ｉ）第１種類のクライアントウォレットがＣＢＥＭを第２種類のクライアントウォレットに送金しており、前記第２種類のクライアントウォレットが、金融規制対応ネットワーク外であること、（ｉｉ）前記第１種類のクライアントウォレットが金融規制対応ＣＢＥＭ以外のＣＢＥＭを受け取ったこと、のうちの少なくとも１つに応じて、警告信号を生成し、電子装置に送信するように構成された、システム。
38. 前記システムプロセッサは、中央サーバを含む、請求項３７に記載のシステム。
39. 前記システムプロセッサは、スマートコントラクトを使用して制御されるプロセッサを含む、請求項３７に記載のシステム。
40. 前記システムプロセッサは、スマートコントラクトにより制御される中央サーバとプロセッサとを含む、請求項３７に記載のシステム。
41. 複数のクライアントが存在する、請求項３７から４０のいずれか１項に記載のシステム。
42. 前記システムプロセッサは更に、
    クライアントの個人アカウントを生成し、
    クライアントが提出した、実際の個人身元情報を確認し、記録し、
    クライアントが提出した、個人認証クレデンシャルを記録し、
    クライアントが生成した、承認済み通貨アドレスを記録し、
    クライアントの承認済み通貨アドレス、個人身元情報、個人認証クレデンシャルを、前記クライアント情報データベース内にマッピング及び格納し、
    前記少なくとも１つのＣＢＥＭの単位の所有権を、クライアントの通貨アドレスを使用して、トランザクションデータベースに記録するように構成される、請求項３７から４１のいずれか１項に記載のシステム。
43. 前記システムプロセッサは、承認済みトランザクションが疑わしい活動であるかを監視し、前記システムプロセッサは、疑わしい活動が検出された場合に、クライアントと政府機関の内の少なくとも１方に、警告を発する、請求項３７から４２のいずれか１項に記載のシステム。
44. 前記システムプロセッサは、前記クライアントウォレットから承認済みトランザクションを受信すると、中央運営団体（５０１）及び／又はクライアント（５０２）により策定されたトランザクション基準を使用して、前記承認済みトランザクションをコンプライアンス基準と比較し、前記承認済みトランザクションの停止、前記承認済みトランザクションの所定期間の保留、前記承認済みトランザクション又はクライアントに関する警告の発行、前記中央運営団体及び／又は前記クライアントに対する前記承認済みトランザクションの報告の内の少なくとも１つを行う、請求項３７から４３のいずれか１項に記載のシステム。
45. 前記システムプロセッサは、承認済みトランザクションが、トランザクションロンダリングを含むＡＭＬ，ＫＹＣ、ＣＴＦ、ＢＳＡ、及びＦＡＴＦコンプライアンスの内の少なくとも１つに違反しているという疑わしさの度合いを判定する、請求項３７から４４のいずれか１項に記載のシステム。
46. 前記疑わしさの度合いは、前記対応ネットワークにおける前記クライアントウォレット外から、クライアントが暗号通貨の送金又は受取を行った回数の分析に基づく、請求項４５に記載のシステム。
47. （ｉ）前記システムプロセッサは、クライアントの疑わしいトランザクションを監視し、前記中央運営団体又はクライアントが策定した前記基準は、クライアントが疑わしいトランザクションに関わった回数を含むことと、（ｉｉ）前記システムプロセッサは、前記クライアント又は受取先がウェブサイトにアクセスしたかを判定し、前記中央運営団体又はクライアントが策定した前記基準は、アクセスされたウェブサイトの種類に関する基準を含むことと、の内の少なくとも一方が実現される、請求項３７から４６のいずれか１項に記載のシステム。
48. 暗号型電子マネー（ＣＢＥＭ）を伴うトランザクションを監視及び規制する個人認証及び確認システムであって、
    システム規制ユーティリティを実行するシステムプロセッサ（４２０及び／又は７０７）であって、クライアントＩＤ登録、クライアント通貨アドレス、ＣＢＥＭトランザクションを処理するために
    ・１又は複数のクライアントの承認済み通貨アドレスを生成するために、クライアントウォレット（４１６、４１７）と通信し、
    ・１又は複数のクライアントの承認済み通貨アドレスを生成するためのリクエストを承認し、
    ・１又は複数の承認済みトランザクションを生成するために、前記クライアントウォレット（４１６、４１７）と通信し、
    ・ＣＢＥＭの単位を、通貨アドレスに送金するため、１又は複数のトランザクションを承認し、
    ・中央運営団体又はクライアントが策定したトランザクション基準を使用して、トランザクションを検査し、
    ・トランザクションデータベース（４１３）内にトランザクション情報を格納するように構成されたシステムプロセッサを有し、
    前記システムは更に、
    １又は複数の承認済み通貨アドレスと、
    承認済みトランザクションネットワークと、
    前記システムプロセッサ（４２０及び／又は７０７）に対して通信可能に接続されるクライアント情報データベース（１１５）と、
    前記システムプロセッサ（４２０及び／又は７０７）に対して通信可能に接続されるトランザクションデータベース（４１３）と、
    クライアントウォレット（４１６、４１７）が設けられる少なくとも１つのクライアント装置（４１４、４１５）とを有し、
    前記少なくとも１つのクライアント装置は、
    ・１又は複数の承認済み通貨アドレスを生成するための許可を、前記システムプロセッサ（４２０及び／又は７０７）から取得し、
    ・ＣＢＥＭの単位を受取先の通貨アドレスに送金するため、１又は複数の承認済みトランザクションを生成する許可を、前記システムプロセッサ（４２０及び／又は７０７）から取得し、
    ・ＣＢＥＭの単位を受取先の通貨アドレスに送金するため、前記トランザクションを署名することにより、１又は複数の承認済みトランザクションを生成するように構成され、
    前記システムプロセッサ（４２０及び／又は７０７）は、クライアントの疑わしいトランザクションを監視し、前記中央運営団体又はクライアントが策定した前記基準は、クライアントが疑わしいトランザクションに関わった回数を含み、（ｉｉ）前記システムプロセッサは、前記クライアント又は受取先がウェブサイトにアクセスしたかを判定し、前記中央運営団体又はクライアントが策定した前記基準は、アクセスされたウェブサイトの種類に関する基準を含む、システム。
49. 前記システムプロセッサは、中央サーバを含む、請求項４８に記載のシステム。
50. 前記システムプロセッサは、スマートコントラクトを使用して制御されるプロセッサを含む、請求項４８に記載のシステム。
51. 前記システムプロセッサは、スマートコントラクトにより制御される中央サーバとプロセッサとを含む、請求項４８に記載のシステム。
52. 複数のクライアントが存在する、請求項４８から５１のいずれか１項に記載のシステム。
53. 前記システムプロセッサは更に、
    クライアントの個人アカウントを生成し、
    クライアントが提出した、実際の個人身元情報を確認し、記録し、
    クライアントが提出した、個人認証クレデンシャルを記録し、
    クライアントが生成した、承認済み通貨アドレスを記録し、
    クライアントの承認済み通貨アドレス、個人身元情報、個人認証クレデンシャルを、前記クライアント情報データベース内にマッピング及び格納し、
    前記少なくとも１つのＣＢＥＭの単位の所有権を、クライアントの通貨アドレスを使用して、トランザクションデータベースに記録するように構成される、請求項４８から５２のいずれか１項に記載のシステム。