特許7148933 | 知財ポータル「IP Force」

知財求人 - 知財ポータルサイト「IP Force」

青山学院大学 (神奈川県相模原市中央区淵野辺)

▶ ティービーシーエーソフト，インコーポレイッテッドの特許一覧

特許7148933分散取引合意ネットワーク上でのデジタル財産取引の匿名性及び追跡性

書誌要約請求の範囲詳細な説明課題実施例実施するための形態図面の説明

目に優しい文字サイズ小中大 PDF Top

< >

1
2
3
4A
4B
4C
5
6A
6B
6C
7
8
9
10
11
12

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2022-09-28

(45)【発行日】2022-10-06

(54)【発明の名称】分散取引合意ネットワーク上でのデジタル財産取引の匿名性及び追跡性

(51)【国際特許分類】

H04L 9/32 20060101AFI20220929BHJP

G06Q 20/38 20120101ALI20220929BHJP

【ＦＩ】

H04L9/32 200Z

G06Q20/38 312

【請求項の数】 18

(21)【出願番号】P 2019555444

(86)(22)【出願日】2018-01-22

(65)【公表番号】

(43)【公表日】2020-06-11

(86)【国際出願番号】 US2018014603

(87)【国際公開番号】W WO2018194736

(87)【国際公開日】2018-10-25

【審査請求日】2021-01-20

(31)【優先権主張番号】62/486,916

(32)【優先日】2017-04-18

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】62/619,058

(32)【優先日】2018-01-18

(33)【優先権主張国・地域又は機関】US

(73)【特許権者】

【識別番号】519016413

【氏名又は名称】ティービーシーエーソフト，インコーポレイテッド

(74)【代理人】

【識別番号】100082418

【弁理士】

【氏名又は名称】山口朔生

(74)【代理人】

【識別番号】100167601

【弁理士】

【氏名又は名称】大島信之

(74)【代理人】

【識別番号】100201329

【弁理士】

【氏名又は名称】山口真二郎

(72)【発明者】

【氏名】ウー、ウィリアム

(72)【発明者】

【氏名】チャン、ブライアン

(72)【発明者】

【氏名】リ、チャーシン

(72)【発明者】

【氏名】フー、シーネン

(72)【発明者】

【氏名】ウー、リン

(72)【発明者】

【氏名】リン、ホアン－イー

【審査官】中里裕正

(56)【参考文献】

【文献】特開平０６－１６２０５９（ＪＰ，Ａ）

【文献】特表平１１－５１０２７８（ＪＰ，Ａ）

【文献】特開２０００－３２２４８６（ＪＰ，Ａ）

【文献】米国特許出願公開第２０１６／０３２１６２５（ＵＳ，Ａ１）

【文献】米国特許出願公開第２０１６／０２２４９４９（ＵＳ，Ａ１）

【文献】米国特許出願公開第２０１７／００１１４６０（ＵＳ，Ａ１）

【文献】中国特許出願公開第１０３９２７６５９（ＣＮ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｌ９／３２

Ｇ０６Ｑ２０／３８

(57)【特許請求の範囲】

【請求項1】

デジタル財産管理システムにおいて履行される方法であって、
前記デジタル財産管理システムは、送信者のデジタル財産管理人及び受信者のデジタル財産管理人を備え、前記送信者のデジタル財産管理人は、送信者のデジタル財産管理モジュール及び送信者の取引ノードを備え、前記受信者のデジタル財産管理人は、受信者のデジタル財産管理モジュール及び受信者の取引ノードを備え、前記方法は、
（ａ）前記送信者のデジタル財産管理モジュールによって、受信者の物理的身分証明書を備える送金要求を受信するステップと、
（ｂ）前記送信者のデジタル財産管理モジュールから、前記受信者のデジタル財産管理モジュールによって、前記受信者の物理的身分証明書を備えるトークン要求を受信するステップと、
（ｃ）前記受信者の物理的身分証明書をチェックすることにより、前記受信者が前記受信者のデジタル財産管理人の契約者であることを判定した後、前記受信者のデジタル財産管理モジュールによって、トークンの生成、及び、前記トークンを受信者の仮想身分証明書に関連させるトークン対応付け、を作成するステップと、
（ｄ）前記受信者のデジタル財産管理モジュールから、前記送信者のデジタル財産管理モジュールへ、前記トークンを備えるトークン応答を送信するステップと、
（ｅ）前記送信者のデジタル財産管理モジュールによる、分散取引合意ネットワークの前記送信者の取引ノードへの、又は、前記受信者のデジタル財産管理モジュールによる、前記分散取引合意ネットワークの前記受信者の取引ノードへの、いずれかの場合の送信取引、管理モジュール間取引、及び送達取引の各々を構築及び送信するステップであって、前記送達取引は前記トークン及び前記トークン対応付けを使用することにより構築されるステップと、
を備え、
前記送信取引は、送信者の仮想財布から前記送信者のデジタル財産管理人の仮想財布へデジタル財産を移動させ、
前記管理モジュール間取引は、前記送信者のデジタル財産管理人の前記仮想財布から前記受信者のデジタル財産管理人の仮想財布へデジタル財産を移動させ、且つ、
前記送達取引は、前記受信者のデジタル財産管理人の前記仮想財布から受信者の仮想財布へデジタル財産を移動させることを特徴とする、方法。

【請求項2】

請求項１に記載の方法であって、
前記トークン要求は、送信者のデジタル財産管理モジュールの署名を更に備え、前記署名は、前記送信者のデジタル財産管理モジュールのメッセージ秘密キーを使用することによって、前記受信者の物理的身分証明書の上に作成される、又は、前記トークン要求は、送信者のデジタル財産管理モジュールの身分証明所及び送信者のデジタル財産管理モジュールの署名を更に備え、前記署名は、前記送信者のデジタル財産管理モジュールのメッセージ秘密キーを使用することによって、前記送信者のデジタル財産管理モジュールの前記身分証明書及び前記受信者の物理的身分証明書の両方の上に作成されることを特徴とする、方法。

【請求項3】

請求項２に記載の方法であって、
ステップ（ｂ）は、
前記送信者のデジタル財産管理モジュールのメッセージ公開キーを使用することによって、前記受信されたトークン要求における情報が本物であることを、前記受信者のデジタル財産管理モジュールによって検証するステップ、
を更に備えることを特徴とする、方法。

【請求項4】

請求項１に記載の方法であって、
前記受信者の物理的身分証明書は、受信者の電話番号であることを特徴とする、方法。

【請求項5】

請求項１に記載の方法であって、
前記トークン応答は、前記受信者のデジタル財産管理モジュールの身分証明書及び受信者の署名を更に備え、前記署名は、受信者のメッセージ秘密キーを使用することによって、前記トークンだけの上に、又は前記受信者のデジタル財産管理モジュールの前記身分証明書及び前記トークンの両方の上に作成されることを特徴とする、方法。

【請求項6】

請求項１に記載の方法であって、
前記トークン応答は、前記送信者のデジタル財産管理モジュールのメッセージ公開キーを使用することによって作成された、前記トークン及び前記受信者のデジタル財産管理モジュールの身分証明書の両方を暗号化したものを備えることを特徴とする、方法。

【請求項7】

請求項６に記載の方法であって、
前記トークン応答は、受信者の物理的証明書と、前記送信者のデジタル財産管理モジュールの身分証明書と、前記受信者の物理的身分証明書、前記送信者のデジタル財産管理モジュールの前記身分証明書の上に作成される受信者の署名と、受信者のメッセージ秘密キーを使用することによる、前記トークン及び前記受信者のデジタル財産管理モジュールの前記身分証明書の両方を前記暗号化したものと、を更に備えることを特徴とする、方法。

【請求項8】

請求項１に記載の方法であって、
前記トークンは、タイムスタンプを更に備えることを特徴とする、方法。

【請求項9】

請求項１に記載の方法であって、
ステップ（ｅ）は、
（ｅ１）前記送信者のデジタル財産管理モジュールから、前記受信者のデジタル財産管理モジュールによって、暗号化された送信取引、管理モジュール間取引、及び前記トークンを備える一時的な送達取引を受信するステップと、
（ｅ２）前記受信者のデジタル財産管理モジュールによって、前記トークン対応付けを使用することにより、前記受信された一時的な送達取引から送達取引を構築するステップと、
（ｅ３）前記受信者のデジタル財産管理モジュールから、分散取引合意ネットワークの受信者の取引ノードへ、前記暗号化された送信取引、前記管理モジュール間取引、及び前記送達取引を送信するステップと、
を備えることを特徴とする、方法。

【請求項10】

請求項９に記載の方法であって、
前記受信者のデジタル財産管理モジュールは、前記送達取引を構築する前に、前記トークンが正当なトークンプールにあることを検証し、且つ、前記送達取引が前記分散取引合意ネットワークによって引き渡された後、前記正当なトークンプールから前記トークンを除去することを特徴とする、方法。

【請求項11】

請求項９に記載の方法であって、
（ｆ）前記受信者の取引ノードのメッセージ秘密キーを使用することにより、前記暗号化された送信取引を暗号解読するステップと、
（ｇ）前記送信取引、前記管理モジュール間取引、及び前記送達取引を前記分散取引合意ネットワークへ提出するステップと、
を更に備える、方法。

【請求項12】

請求項１１に記載の方法であって、
前記受信者の取引ノードは、メッセージ公開キーとメッセージ秘密キーの新しい対を繰り返して生成し、且つ、前記公開キーをデジタル財産管理モジュールと供給することを特徴とする、方法。

【請求項13】

請求項１２に記載の方法であって、
ステップ（ｆ）は、
（ｆ１）前記受信者の取引ノードに格納された現在のメッセージ秘密キーによって、前記暗号化された送信取引を暗号解読するステップと、
（ｆ２）もしステップ（ｆ１）が失敗する場合、前記受信者の取引ノードに格納されたすぐ前のメッセージ秘密キーによって、前記暗号化された送信取引を暗号解読するステップと、
を備える、方法。

【請求項14】

請求項１に記載の方法であって、
ステップ（ｅ）は、
（ｅ１）前記送信者のデジタル財産管理モジュールから、前記受信者のデジタル財産管理モジュールによって、管理モジュール間取引及び、前記トークンを備える一時的な送達取引を受信するステップと、
（ｅ２）前記受信者のデジタル財産管理モジュールによって、前記トークン対応付けを使用することにより、前記受信された一時的な送達取引から送達取引を構築するステップと、
（ｅ３）前記受信者のデジタル財産管理モジュールから、前記送信者のデジタル財産管理モジュールによって、暗号化された送達取引を受信するステップと、
（ｅ４）前記送信者のデジタル財産管理モジュールから、分散取引合意ネットワークの前記送信者の取引ノードへ、送信取引、前記管理モジュール間取引、及び前記暗号化された送達取引を送信するステップと、
を備える、方法。

【請求項15】

請求項１４に記載の方法であって、
前記受信者のデジタル財産管理モジュールは、前記送達取引を構築する前に、前記トークンが正当なトークンプールにあることを検証し、且つ、前記送達取引が前記分散取引合意ネットワークによって引き渡された後、前記正当なトークンプールから前記トークンを除去することを特徴とする、方法。

【請求項16】

請求項１４に記載の方法であって、
（ｆ）前記送信者の取引ノードのメッセージ秘密キーによって、前記暗号化された送達取引を暗号解読するステップと、
（ｇ）前記送信取引、前記管理モジュール間取引、及び前記送達取引を前記分散取引合意ネットワークへ提出するステップと、
を更に備える、方法。

【請求項17】

請求項１６に記載の方法であって、
前記送信者の取引ノードは、メッセージ公開キーとメッセージ秘密キーの新しい対を繰り返して生成し、且つ、前記メッセージ公開キーをデジタル財産管理モジュールと共有することを特徴とする、方法。

【請求項18】

請求項１７に記載の方法であって、
ステップ（ｆ）は
（ｆ１）前記送信者の取引ノードに格納された現在のメッセージ秘密キーを使用することにより、前記暗号化された送達取引を暗号解読するステップと、
（ｆ２）もし（ｆ１）が失敗する場合、前記送信者の取引ノードに格納されたすぐ前のメッセージ秘密キーを使用することにより、前記暗号化された送達取引を暗号解読するステップと、
を備える、方法。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、一般に、分散取引合意ネットワーク上でのデジタル財産取引の匿名性及び追跡性を上げるための方法及び関連システム、装置、並びにコンピュータ可読な媒体に関する。

【背景技術】

【0002】

幾つかの暗号通貨システムは、ビットコインのように、より高い匿名性及びより低い追跡性を有する。個人又は法人は、任意の実世界の身分証明書を開示することなく、口座を開くことが可能である。各口座は、仮想財布アドレスによって識別される。口座所有者は、その後、他者から暗号通貨を受信し、且つ、他者に暗号通貨を送金することが可能である。ブロックチェーンに記録された取引は、送信者の仮想財布アドレス、受信者の仮想財布アドレス、及び送金額を含む。そのようなシステムは、高い匿名性及び低い追跡性を有するが、その理由は、（名前、社会保障番号、及び電話番号のような）所有者の実世界の身分証明書と所有者の仮想世界の身分証明書（仮想財布アドレス）との間に、関連又はつながりが無いからである。システムがハッキングされ、且つ取引台帳が盗まれる場合でさえも、口座所有者の実世界の身分証明書が分かることはないであろう。取引の実際の送信者及び受信者を追跡することは、ほとんど不可能である。その結果、そのようなシステムは、マネーロンダリング促進者となり得る。

【発明の概要】

【0003】

本開示は、デジタル財産管理システムの匿名性及び追跡性を上げるための、方法及び関連システム、装置、並びにコンピュータ可読媒体に向けられ、ここで該デジタル財産管理システムは、取引を処理するための暗号技術を使用して、分散取引合意ネットワーク上でのデジタル財産取引を管理する。

【0004】

デジタル財産管理システムは、複数のデジタル財産管理人を備え、該デジタル財産管理人は、銀行、通信事業者（「通信会社」）などであり得る。各デジタル財産管理人は、（１）その顧客（契約者）情報及び顧客の仮想財布を取り扱うための、及び実際の取引に対して顧客の送金要求を変換するためのデジタル財産管理モジュール（「モジュール」）と、（２）取引を処理するための取引ノード（分散取引合意ネットワークのノード）と、を有する。

【0005】

デジタル財産管理モジュールは、要求される機能を実施するための、様々なハードウェア及びソフトウェアを含む。契約者がデジタル財産管理人に関する仮想財布を開く場合、彼／彼女の個人情報が、そのデジタル財産管理モジュールによって作成されると共に維持されるが、ここで該個人情報は、（名前、社会保障番号、及び電話番号のような）個人又は法人を識別するのに使用され得る物理的身分証明書と、（仮想財布ＩＤ及び仮想財布アドレスのような）彼／彼女の仮想財布を識別するのに使用され得る仮想身分証明書と、を含む。したがって、送信者のデジタル財産管理モジュール（「送信者のモジュール」）は、送信者の物理的身分証明書及び仮想身分証明書を有し、且つ受信者のデジタル財産管理モジュール（「受信者のモジュール」）は、受信者の物理的身分証明書及び仮想身分証明書を有する。送金取引を要求する場合、送信者は、通常、送信者のデジタル財産管理モジュール（「送信者のモジュール」）に、彼／彼女の物理的身分証明書、受信者の物理的身分証証明書及び送金額を提供する。匿名性を上げるために、幾つかの対策を使用することが可能である。一実施形態において、送信者のモジュールは、受信者の仮想身分証明書にアクセスすることが許可されておらず、その結果として、送信者のモジュールは、特定の送金取引を容易には追跡できない。同様に、受信者のモジュールは、送信者の仮想身分証明書にアクセスすることが許可されていない。しかしながら、送金取引を構築するためには、送信者の仮想身分証明書及び受信者の仮想身分証明書の両方を使用しなければならない。したがって、送信者のモジュール及び受信者のモジュールは、協同して働かなければならないが、しかし同時に、個人のプライバシーを保護するために、不必要な情報共有を避けなければならない。一実施形態において、送信者のモジュールは受信者の仮想身分証明書にアクセスできないので、受信者のモジュールは、受信者の仮想身分証明書の一時的な置き換えとして、送信者のモジュールにトークンを提供しなければならない。このアプローチによって、ハッカーは特定の送金取引を追跡できないが、このことは、ハッカーが、分散取引合意ネットワークの分散台帳及びデジタル財産管理モジュールにアクセスできる場合でさえも当てはまる。同様に、いかなる単一のデジタル財産管理モジュールも特定の送金取引を追跡できないが、その理由は、該デジタル財産管理モジュールは、送信者及び受信者両方の物理的身分証明書及び仮想身分証明書を一致させられないからである。

【0006】

匿名性及び安全性を更に上げるために、モジュール及びノードは、メッセージ上に署名を作成し、且つ、メッセージが本物であることを証明するべく、それらの署名を一緒に送信することが可能である。不適切なモジュールがメッセージを傍受し、且つ悪用することを防ぐために、モジュール及びノードもまた、メッセージを暗号化することが可能である。

【0007】

デジタル財産管理システムがマネーロンダリング促進者になることを防ぐために、システムは、必要な場合、特定の取引を追跡するためのメカニズムを提供しなければならない。送金取引は、送信取引、管理モジュール間取引、及び送達取引を含む、複数のサブ取引（集合的に「取引セット」）を備えてもよい。送信者のモジュール又は受信者のモジュールのいずれかは、各サブ取引のための追跡キーを使用することによって、暗号化されたラベルを作成することが可能である。ラベルは、取引内の各サブ取引及びそれらの順序を識別するための情報を含む。追跡キーは、対称キーであり得るか、又は非対称キーであり得る。一実施形態において、追跡キーが対称キーである場合、各デジタル財産管理モジュールは、ラベルを暗号化するために、それ自身の対称キーを作成すると共に保持する。対称追跡キーはまた、ネットワーク管理者ＴＢＣＡ１１０又は、権威付けされた／任命されたノードによって共有される。追跡機能を実施する、権威付けされた又は任命されたノードは、ネットワーク管理者として考えられる。別の実施形態において、追跡キーが非対称キーである場合、ネットワーク管理者ＴＢＣＡ１１０又は、権威付けされた／任命されたノードは、追跡公開キー及び追跡秘密キーを備える追跡キー対を作成する。追跡公開キーは、送金取引セット内の各サブ取引に対するラベルを暗号化するために、デジタル財産管理モジュールによって使用される。追跡秘密キーは、ネットワーク管理者によって機密保持される。必要な場合、ネットワーク管理者又は権威付けされた／任命されたノードは、ラベルを暗号解読し、且つ、送金取引全体を再構築することが可能である。

【0008】

本開示の付加的な特徴及び利点は、後に続く説明の中で述べられるであろう、且つ、部分的には説明から明らかであろう、又は、本開示の実践によって学習されるかもしれない。本開示の目的及び他の利点は、添付された図面はもちろんのこと、記述された説明及びその請求項において特に指摘された構造及び方法によって、実現されると共に達成されるであろう。

【0009】

理解されるべきことであるが、前述の一般的な説明及び次の詳細な説明の両方は、典型的であると共に説明的であり、且つ、特許請求されているような発明の更なる説明を提供するべく意図されている。

【図面の簡単な説明】

【0010】

【図1】分散取引合意ネットワークを例示する模式図である。

【図2】上のネットワークのノード例を例示するブロック図である。

【図3】デジタル財産管理モジュール、契約者、及びそれらの対応する仮想財布を示すブロック図である。

【図4A】ブロック構造の例を例示する表である。

【図4B】ブロックヘッダー構造の例を例示する表である。

【図4C】署名の例を例示する表である。

【図5】ネットワークデバイス例を例示する模式図である。

【図6A】２つの仮想財布間の送金取引に対して使用されるデータ構造の例を例示する表である。

【図6B】２つの仮想財布間の送金取引に対して使用されるデータ構造の例を例示する表である。

【図6C】２つの仮想財布間の送金取引に対して使用されるデータ構造の例を例示する表である。

【図7】送信取引、管理モジュール間取引、及び送達取引を備える送金取引の例を例示する表である。

【図8】送金取引において、受信者の仮想財布アドレスを一時的に置き換えるために、トークンを使用する例を例示する模式図である。

【図9】送金取引において、受信者の仮想財布アドレスを一時的に置き換えるために、トークンを使用する別の例を例示する模式図である。

【図10】送達取引が２つのサブ取引を備える送金取引の例を例示する表である。

【図11】サブ取引の入力デジタル財産が基底額にある、送金取引の例を例示する表である。

【図12】追跡のための取引セットフィールドを含む送金取引データ構造の例を例示する表である。

【発明を実施するための形態】

【0011】

以下に提示される説明の中で使用される用語は、その最も広い合理的な方法で解釈されることが意図されており、このことは、その用語が、技術のある特定の実施形態の詳細な説明と関連して使用される場合においてさえも当てはまる。ある用語が、以下では強調されることがあるかもしれない。しかしながら、任意の制限された方法において解釈されることが意図された任意の用語は、この詳細な説明セクションでそのように明確に画成されるであろう。

【0012】

以下で導入される実施形態は、プログラムされるか又はソフトウェア及び／若しくはファームウェアによって構成されたプログラマブル回路によって、又は完全に専用回路によって、或はそのような形態の組み合わせにおいて、履行することが可能である。（もしあるとすれば）そのような専用回路は、例えば、１つ以上の特定用途向け集積回路（ＡＳＩＣ）、プログラマブルロジックデバイス（ＰＬＤ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）などの形態であり得る。

【0013】

説明される実施形態は、１つ以上の方法、システム、装置、及びプロセッサ実行可能なプロセスステップを格納するコンピュータ可読な媒体に関し、これらは、分散取引合意ネットワークにおいて、暗号化技術に基づいてデジタル財産取引を管理するデジタル財産管理システムの匿名性及び追跡性を上げるためのものである。当業者には既知である様々な暗号化アルゴリズムを使用することが可能である。分散台帳はデジタル財産取引を記録するために使用されるので、分散台帳の完全なコピーが、分散取引合意ネットワーク内の多数のノードにおいて維持される。分散台帳に記録された取引情報に対する、及び、デジタル財産管理モジュールに格納された契約者情報及び仮想財布情報に対する、ハッカーの無許可アクセスのリスクを完全に避けることは可能ではない。したがって、個人の取引情報が悪用されるのを避けるために、匿名性は望ましい。しかしながら、デジタル財産取引のこの匿名性の特徴を仮定しても、そのような分散取引合意ネットワークは、マネーロンダリング促進者となる可能性がある。したがって、デジタル財産管理システムは、特定のデジタル財産取引を追跡可能としながらも、同時に匿名性を上げなければならない。

【0014】

デジタル財産管理システムは、複数のデジタル財産管理人を備え、ここで該デジタル財産管理人は、銀行、通信事業者（「通信会社」）などであり得る。各デジタル財産管理人は、（１）その顧客（契約者）情報及び顧客の仮想財布を取り扱うための、及び実際の送金取引に対して顧客の送金要求を変換するためのデジタル財産管理モジュール（「モジュール」）と、（２）取引を処理するための取引ノード（分散取引合意ネットワークのノード）と、を有する。

【0015】

デジタル財産管理モジュールは、要求される機能を実施するための、様々なハードウェア及びソフトウェアを含む。契約者がデジタル財産管理人に関する仮想財布を開く場合、物理的身分証明書を含む彼／彼女の個人情報が、そのデジタル財産管理モジュールによって作成されると共に維持されるが、ここで該個人情報は、（名前、社会保障番号、及び電話番号のような）実世界における個人又は法人を識別するために使用され得る物理的身分証明書と、（仮想財布ＩＤ及び仮想財布アドレスのような）彼／彼女の仮想財布を識別するために使用され得る仮想身分証明書と、を含む。したがって、送信者のデジタル財産管理モジュール（「送信者のモジュール」）は、送信者の物理的身分証明書及び仮想身分証明書を有し、且つ受信者のデジタル財産管理モジュール（「受信者のモジュール」）は、受信者の物理的身分証明書及び仮想身分証明書を有する。匿名性を上げるために、幾つかの対策を使用することが可能である。一実施形態において、送信者のモジュールは、受信者の仮想身分証明書にアクセスすることが許可されておらず、その結果として、送信者のモジュールは、特定の送金取引を容易には追跡できない。同様に、受信者のモジュールは、送信者の仮想身分証明書にアクセスすることが許可されていない。

【0016】

送金取引を要求する場合、送信者は、通常、送信者のモジュールに、彼／彼女の物理的身分証明書、受信者の物理的身分証証明書、及び送金額を提供する。しかしながら、送金取引を構築するためには、送信者の仮想身分証明書及び受信者の仮想身分証明書の両方を使用しなければならない。したがって、送信者のモジュール及び受信者のモジュールは、協同して働かなければならないが、しかし同時に、個人の取引情報を保護するために、不必要な情報共有を避けなければならない。一実施形態において、送信者のモジュールは受信者の仮想身分証明書にアクセスできないので、受信者のモジュールは、受信者の仮想身分証明書の一時的な置き換えとして、送信者のモジュールにトークンを提供しなければならない。このアプローチによって、ハッカーは特定の送金取引を追跡できないが、このことは、ハッカーが、分散取引合意ネットワークの分散台帳及び／又はデジタル財産管理モジュールにアクセスできる場合でさえも当てはまる。同様に、いかなる単一のデジタル財産管理モジュールも特定の送金取引を追跡できないが、その理由は、該デジタル財産管理モジュールが、送信者及び受信者両方の物理的身分証明書及び仮想身分証明書を一致させられないからである。

【0017】

例えば、送信者（例えば、ウイリアム）は、受信者（例えば、スティーブ）にデジタル財産を移動させるために、送金取引を開始する。ウイリアムはＡＴＴに関する仮想財布を有しているが、ここで彼の携帯電話番号（又は携帯契約番号、「ｍｓｎ」）は、サービスをＡＴＴと契約している。ウイリアムの物理的身分証明書は、彼の携帯電話番号であり、且つ彼の仮想身分証明書は、彼の仮想財布アドレスである。スティーブはＦＥＴに関する仮想財布を有しているが、ここで彼の携帯電話番号は、サービスをＦＥＴと契約している。スティーブの物理的身分証明書はまた、彼の携帯電話番号であり、且つ彼の仮想身分証明書は、彼の仮想財布アドレスである。送信者のデジタル財産管理モジュール（「送信者のモジュール」、例えば、ＡＴＴモジュール）は、受信者のデジタル財産管理モジュール（「受信者のモジュール」、例えば、ＦＥＴモジュール）からトークンを要求し、且つ、一時的な取引の構築のために、受信者の仮想財布アドレスの一時的な置き換えとしてトークンを使用する。したがって、ＡＴＴモジュールは、スティーブの仮想財布アドレスに対するアクセスを有さない。もしハッカーがＡＴＴモジュールのサーバに侵入する場合でさえも、完了した送金取引の情報を、依然として保護することが可能である。

【0018】

送金取引が複数のサブ取引を備える場合、送信者の仮想財布、受信者の仮想財布、及び送金取引の額の間の関係を壊すために、幾つかの対策を使用することが可能である。一実施形態において、送信者から受信者への送金取引は３つの部分を備え、それらは、それぞれ、（ａ）送信取引、即ち、送信者の仮想財布から送信者のモジュールの仮想財布へデジタル財産を移動させること、（ｂ）管理モジュール間取引、即ち、送信者のモジュールの財布から受信者のモジュールの財布へデジタル財産を移動させること、及び（ｃ）送達取引、即ち、受信者のモジュールの仮想財布から受信者の仮想財布へデジタル財産を移動させることである。各部分は、1つ以上のサブ取引を構成することが可能である。もし送信取引、管理モジュール間取引、及び送達取引の1つ以上が、更に２つ以上のサブ取引に分裂され得る場合、匿名性は更に上がる。別の実施形態において、サブ取引間の関係を更に壊すために、これらのサブ取引の、入力ＵＴＸＯのような入力デジタル財産は、基底額にある。

【0019】

追跡性を上げるために、送金取引が複数のサブ取引を備える場合、送金取引セット内の各サブ取引の順序を識別すると共に特定するために、暗号化されたラベルが作成される。一実施形態において、送金取引は３つのサブ取引（即ち、送信取引、管理モジュール間取引、及び送達取引）を備え、それらの各々には、それらが特定の取引セット、及び該セット内の順序に属していることを示すために、ラベルが与えられる。ラベルは追跡キーを用いて暗号化され、その結果として、ネットワーク管理者及び／又は権威付けされた取引ノードだけが、暗号解読後に、同じ取引セット内の３つのサブ取引を識別し、これによって、セットを再構築すると共に、特定の取引に関連する仮想財布及び額を追跡することが可能である。

【0020】

デジタル財産管理システムは、取引安全性、匿名性、及び追跡性を上げるために、様々な対称キーアルゴリズム及び／又は非対称キーアルゴリズムを使用する。対称キーアルゴリズムは、ただ１つのキーを有する。非対称キーアルゴリズムは、公開キー及び秘密キーを備えるキー対を有する。例えば、対称キーアルゴリズムＡＥＳ（高度暗号化標準）及びＤＥＳ（データ暗号化標準）は、暗号化に対して使用することが可能であり、非対称キーアルゴリズムＥＣＤＳＡ（楕円曲線デジタル署名アルゴリズム）は、署名に対して使用することが可能であり、非対称キーアルゴリズムＲＳＡ（Ｒｉｖｅｓｔ－Ｓｈａｍｉｒ－Ａｄｌｅｍａｎ）は、署名及び暗号化の両方に対して使用することが可能である。取引安全性を上げるために、仮想財布は、取引公開キー及び取引秘密キーを備える非対称キー対を有する。匿名性を上げるために、契約者、デジタル財産管理モジュール、及び取引ノードは、署名及び／又は暗号化のためのメッセージ公開キー及びメッセージ秘密キーを備える、それ自身の非対称キー対をそれぞれ有することが可能である。追跡性を上げるために、対称キー対又は非対称キー対のいずれかを、暗号化のために使用することが可能である。非対称キー対が使用される場合、ネットワーク管理者又はその権威付けされた／任命されたノードは、追跡公開キー及び追跡秘密キーを有する。対称キーが使用される場合、デジタル財産管理モジュールは、ネットワーク管理者又はその権威付けされた／任命されたノードによって共有される、それ自身の追跡キーを有する。あまり複雑でないシステムについては、メッセージキー対は、取引キー対と同じであり得る。

【0021】

一実施形態において、図１に示されるように、暗号化技術を使用した分散取引合意ネットワーク１００（この開示ではＴＢＣＡ（ブロックチェーンアライアンス）と呼ばれる）は、デジタル財産取引を処理するべく履行される。ＴＢＣＡネットワーク１００は複数のノードを備え、ここで複数のノードは、管理者１１０、取引ノード１２０、１３０、１４０、１５０、合意ノード１３０、１４０、１６０、１７０、及び他のノード１８０、１９０を含む。図２に示されるように、各ノードは、通常、計算を実施すると共にプログラムを実行するためのプロセッサと、ソフトウェア、プログラム、及びデータを格納するためのメモリと、ユーザと意思伝達するためのディスプレイと、ユーザ及び他のデバイスと通信するための入力／出力構成要素と、有線チャンネル又は無線チャンネルを介してネットワークとつながるためのネットワーク構成要素と、を備える。

【0022】

管理者１１０（この開示ではＴＢＣＡと呼ばれる）は、ルールを設定すると共に、ＴＢＣＡネットワーク１００を管理する。管理者１１０は、自身によって発行されるデジタル料金トークン又は、他のデジタル財産管理人によって発行されるデジタル財産を格納するための仮想財布（図示せず）を有する。管理者１１０は、ノードが、分散取引合意ネットワーク１００（ＴＢＣＡネットワーク）に加わると共に、ネットワークのメンバになることを許可することが可能である。加えて、管理者１１０（ＴＢＣＡ）は、デジタル財産管理人に権威付けを行い、デジタル通貨、デジタル株券、デジタル債券、デジタル先物、及びデジタル貴金属のような、様々なデジタル財産を発行させることが可能である。デジタル財産管理人は、そのデジタル財産管理モジュール又は（１２０から１５０のような）その取引ノードを通して、デジタル財産を発行することが可能である。管理者１１０は、他のノードに権威付けするか、又は他のノードを任命して、特定のデジタル財産取引を追跡することのような、その機能の一部分を実施させることが可能である。その程度まで、管理者は、その権威付けされたノード及び／又は任命されたノードを含む。

【0023】

一実施形態において、取引ノード（例えば、１２０、１５０）は、そのデジタル財産管理人に対してデジタル財産を発行することが可能である。取引ノードは、銀行（例えば、ＢａｎｋｏｆＡｍｅｒｉｃａ（「ＢＯＡ」）又はＣｈａｓｅ）、投資／取引機関（例えば、Ｆｉｄｅｌｉｔｙ又はＧｏｌｄｍａｎｎＳａｃｈｓ）、又は通信運営者（例えば、ＡＴ＆Ｔ（ＡＴＴ）、ＳｏｆｔＢａｎｋ（ＳＢＴ）又は中華（Ｃｈｕｎｇｈｗａ）通信）のようなデジタル財産管理人に関連付けられる。一実施形態において、デジタル財産は、デジタル通貨、デジタル株券、デジタル債券、デジタル先物、デジタル貴金属、又はデジタル料金トークンのいずれかで有り得る。図３に示されるように、発行されたデジタル財産は、デジタル財産管理人の仮想財布３１２、３２２に格納される。それ自身のデジタル財産管理人、他のデジタル財産管理人、又は管理者ＴＢＣＡ１１０によって発行された様々なデジタル財産を格納できるそのような仮想財布３１２、３２２は、デジタル財産管理人のデジタル財産管理モジュール３１０、３２０によって管理される。各仮想財布は仮想財布ＩＤを有し、該仮想財布ＩＤは、ある実施形態において、仮想財布アドレスであり得る。加えて、各仮想財布は、取引公開キー及び取引秘密キーを有する。仮想財布に格納されたデジタル財産を使うためには、取引に署名するべく、その仮想財布に関連付けられた取引秘密キーを使用しなければならない。

【0024】

各取引ノード１２０、１５０は、デジタル財産管理モジュール（「モジュール」）に対応し、ここで該デジタル財産管理モジュールは、取引ノードに対して取引を構築するための、取引に署名するための、及び取引を送信するためのハードウェア及びソフトウェアを備える。一実施形態において、デジタル財産管理モジュールは、これらの機能を履行するために、財布サーバ、署名サーバ、（取引処理エンジンとしても知られる）ミドルウェア、トークン対応付けデータベース、取引ノード探索ＡＰＩのメッセージ公開キーなどを含む。

【0025】

合意ノード１３０、１４０、１６０、１７０は、（ＴＢＣＡネットワーク１００のメンバ／ノードに対して開かれている）分散台帳内の取引を提案し、正当と確認し、且つ記録することが可能である。ある分散取引合意ネットワークにおいて、合意ノードは、それが提供するサービスと引き換えに報酬を受け取ってもよい。その状況では、合意ノードは、しばしば採掘者と呼ばれる。報酬は、管理者１１０（ＴＢＣＡ）によって発行されたＴコイン、及び／又はデジタル財産管理人によって発行されたデジタル財産であり得、これらのデジタル財産は、採掘者の仮想財布（図示せず）に格納することが可能である。他の分散取引合意ネットワークにおいて、合意ノードは、任意の報酬を受け取らない。その状況では、合意ノードは、しばしば確認者と呼ばれる。積極的に新しいブロックを提案する確認者は、しばしば提案者又はブロック提案者と呼ばれる。

【0026】

分散台帳は、本質的にデジタル財産データベース又はデータ構造であり、該データベース又はデータ構造は、様々な現場、地理又は機関における多様なノードの分散取引合意ネットワークにわたって共有することが可能である。ネットワーク内の全てのノードは、それら自身の台帳の同一コピーを有することが可能である。台帳に対する任意の変更は、数分の内に、又は、ある場合には数秒の内に、全てのコピーに反映することが可能である。台帳に格納されたデジタル財産の安全性及び正確さは、分散台帳内で誰が何を実行できるかを制御するべく、キー及び署名を使用することによって、暗号的に維持される。一実施形態において、分散台帳に対して、ブロックチェーンデータ構造が使用される。合意ノードは、正当と確認された取引を記録するために、新しいブロックを作成することが可能であり、且つ、その後、新しいブロックをネットワークの他のノードに伝搬させる。しかしながら、分散台帳は、当業者にとっては既知である、任意の他のデータ構造を使用することが可能である。

【0027】

ＴＢＣＡネットワーク１００が膨大な数の取引を即座に完了できるように、新しいブロック生成の処理能力を最大化するべく、管理者１１０は、合意ノードの数を管理し、且つ／又は、互いに対して競争するために、及び／又は互いに対して援助するために、合意ノードに対するルールを設定し、且つ／又は、取引を記録するための新しいブロックを生成するべく、１つ以上の合意ノードを指定することが可能である。取引ノード１３０、１４０もまた、合意ノードであり得る。他の機能のために、他のノード１８０、１９０がＴＢＣＡネットワーク１００に加入するのを認めることが可能である。

【0028】

デジタル財産管理人の契約者は、そのデジタル財産管理モジュールによって管理されるべき１つ以上の仮想財布を開くと共に、所有することが可能である。各契約者は、社会保障番号、パスポート番号、電話番号のような、１つ以上の物理的身分証明書を有することが可能である。同様に、各契約者は、仮想財布ＩＤ、仮想財布アドレスなどのような、１つ以上の仮想身分証明書を有することが可能である。ある実施形態において、仮想財布ＩＤは仮想財布アドレスである。各契約者の物理的身分証明書を彼／彼女の仮想身分証明書に対応付けるデータ構造が、契約者のデジタル財産管理人のデジタル財産管理モジュールによって、作成されると共に維持される。

【0029】

加えて、各契約者の仮想財布は、取引公開キー及び取引秘密キーを有する。彼又は彼女の仮想財布に格納されたデジタル財産を使うには、契約者は、取引に署名するべく、仮想財布に関連付けられた取引秘密キーを使用しなければならない。図３に示されるような一実施形態において、デジタル財産を格納するために、送信するために、受信するために、及び管理するために、仮想財布３１４、３２４が提供されるが、ここでデジタル財産とは、契約者（例えば、個人、投資家、及び／又は商人）のための、デジタル通貨、デジタル株券、デジタル債券、デジタル先物、デジタル貴金属、及びデジタル料金トークンのような、多様なタイプのデジタル資産、信用貸し、及び債務を含む。各仮想財布３１４、３２４は、デジタル財産管理モジュール３１０、３２０に関連付けられ、且つ、例えば、１Ｆ１ｔＡａｚ５ｘ１ＨＵＸｒＣＮＬｂｔＭＤｑｃｗ６ｏ５ＧＮｎ４ｘｑ、及び１６ＵＬＺＵＪｗｖ１ＨＺＪｋＦｒｓ８ａａ９ｃ３ｘＨＴｊｉａｙｙＴＮＳなどの仮想財布ＩＤ（又は、ある実施形態ではアドレス）によって識別され得る。一実施形態において、仮想財布３１４は、そのデジタル財産管理モジュール３１０を通してデジタル財産管理人によって発行された様々なデジタル財産を、単に格納すること、送信すること、受信すること、及び管理することが可能であるが、ここで仮想財布３１４は、他のデジタル財産管理人によって発行されるデジタル財産というよりはむしろ、デジタル財産管理モジュール３１０に関連付けられる。

【0030】

取引公開キー及び取引秘密キーの対に加えて、各契約者は、メッセージ公開キー及びメッセージ秘密キーの対を有するが、ここで該対は、機密メッセージに関する暗号又は、メッセージが本物であることを証明するための署名を提供するために使用される。契約者をそれらのメッセージ公開キーに一対一に対応させるデータベースは、そのような対応付けが全てのデジタル財産管理モジュールによってアクセス可能であるように、作成されると共に維持される。契約者がデジタル財産管理人に関する仮想財布を開く時はいつでも、対応付けが付加されるべきである。

【0031】

各取引は、ＴＢＣＡネットワーク１００内の他のノードに対して開いている分散台帳に、合意ノード及び取引ノードによって記録される。一実施形態において、分散台帳は、チェーン内にブロックを備える。図４Ａから図４Ｃは、ブロック構造、ブロックヘッダー構造、及び署名の実施形態を例示する。各ブロックは、ブロックハッシュによって識別されるが、該ブロックハッシュは、ＳＨＡ２５６暗号化アルゴリズムを通してブロックヘッダーを２回ハッシュすることによって作られる。加えて、各ブロックは、ブロックヘッダーにおける「前のブロックハッシュ」フィールドを通して、前のブロック（親ブロックとして知られる）を参照する。したがって、ハッシュのシーケンスは、各ブロックをその親にリンクさせ、その結果として、これまでに作成された最初のブロックまでさかのぼるチェーンを作成する。ブロックが互いの上に積み重なるので、取引を逆にすることは指数関数的に難しくなる。それ故に、ブロックに記録された取引は、時間の経過と共にますます信頼されるようになる。ブロックと取引のサイズに依存して、平均的なブロックは、数百の取引を含むことが可能である。完全且つ最新の分散台帳は、管理者、取引ノード、合意ノード、及びそのような台帳を格納するべく管理者１１０によって許可された他のノード（「フルノード」）のデータベース（又はファイル）に格納される。幾つかのノードは、そのような台帳の一部分だけを格納するように選択することが可能である。

【0032】

図５に示されるように、デジタル財産管理人の契約者は、サーバ、デスクトップコンピュータ、ラップトップコンピュータ、タブレット、携帯電話、陸地線電話、及びＰＤＡのような（移動チャンネル、ＷｉＦｉチャンネル、又は有線チャンネルを介して任意のインターネット接続に接続された）ネットワークデバイスを介して、取引がＴＢＣＡネットワーク１００によって処理されると共に記録されることを要求できる。一実施形態において、デジタル財産取引の基本的な構成ブロックは、未使用の取引出力（「ＵＴＸＯ」）である。ＵＴＸＯは、特定の仮想財布に対して、取引秘密キーによってロックされたデジタル財産の分割不可能なかたまりであり、且つ、任意の値であり得る。契約者の仮想財布は、数百のブロックに記録された数百の以前の取引から、多くのＵＴＸＯを備えてもよい。一実施形態において、契約者は、例えば、食事代を支払うために、特定の値のデジタル財産をレストランに移動させるべく、送金取引を要求することが可能である。取引は、契約者の仮想財布からの１つ以上の取引入力（入力ＵＴＸＯ）と、受信仮想財布への１つ以上の取引出力（出力ＵＴＸＯ）と、を備えてもよい（例えば、レストランへの食事代、及び契約者に返すおつり）。取引入力は、以前の取引から生成され、且つ、前には使用されていない、ＵＴＸＯに対するポインターである。取引出力は、受信仮想財布にロックされたＵＴＸＯであり、該ＵＴＸＯは、将来、それらの所有者によって使うことが可能である。一般的なルールとして、取引入力の値の合計は、取引出力の値の合計に等しいはずである。定常的なデジタル財産取引では、いかなる価値も、生成されるべきでなく、又は失われるべきでない。

【0033】

取引は、デジタル財産管理モジュールによって、定常的に準備されるが、該デジタル財産管理モジュールは、その後、取引をその取引ノード（分散台帳に記録するための、ＴＢＣＡネットワーク１００のような分散取引合意ネットワークのノード）に提出する。一実施形態において、デジタル財産管理モジュールは、幾つかのデータ構造／データベース及び格納のためのメモリグリッドはもちろんのこと、財布サーバ、署名サーバ、及びミドルウェアを備える。財布サーバは、契約者から取引要求を受信し、全ての必要な情報を収集し、且つ、それをミドルウェアに提出する。ミドルウェアは、バイトの文字列によって表される取引を構築するために、そのような情報を使用し、且つ、それを財布サーバに送り返すが、該財布サーバは、その後、取引を署名サーバに渡す。仮想財布の取引秘密キーを使用して取引に署名した後、署名サーバは、署名された取引を財布サーバに戻し、該財布サーバは、その後、それを戻してミドルウェアに渡す。ミドルウェアは、署名された取引を取引ノード（分散取引合意ネットワークのノード）に送信し、該取引ノードは、それをネットワークに伝搬させる。署名された取引を受信した後、取引ノード及び合意ノードを含む、分散取引合意ネットワーク上の他のノードは、取引を独立に検証すると共に正当と確認し、且つ、その後、正当と確認された取引を取引プールへ付加する。各ノードは、取引を更に伝搬させる前に、同じ基準を使用して、あらゆる取引を独立に正当と確認する。ブロックチェーンデータ構造を使用する一実施形態において、合意ノードは、取引プールから取引を引き出して、新しいブロックを作成するであろう。新しいブロックを検証すると共に正当と確認した後、合意ノードは、その後、新しいブロックを他のノードへ伝搬させる。新しいブロックを受信した後、ネットワーク上のノードは、同じ基準を使用して、新しいブロックを検証すると共に正当と確認する。一旦ノードが新しいブロックを正当と確認すると、ノードは、その後、新しいブロックをその既存のブロックチェーンに接続させるであろう。その後、この新しいブロック内の取引は引き渡されるであろう。新しい所有者は、これらの取引から出力ＵＴＸＯを使うことが可能である。結局のところ、ネットワークが攻撃される、切断される、又は故障することがなければ、ネットワーク上の各フルノードは、同じ台帳（又はブロックチェーン）のコピーを有するであろう。複数のノード（それらの各々が、同じ基準で同じ取引及び／又はブロックを独立に検証する）が分散台帳上で合意に達することを要求する合意は、取引の安全性を高めるためのメカニズムである。分散取引合意ネットワークが、より多くのノードが合意に達することを要求するほど、ネットワークはますます安全になる。合意に達するかどうかは、当業者には既知である様々なルール及び／又はアルゴリズムによって、決定することが可能である。一実施形態において、フォーキングが起こる場合、チェーンにおけるブロックの長さ（又は深さ）を比較することによって、合意に達することが可能であるが、そこではビットコインネットワークで採用されているようなアルゴリズムによって、より長いチェーンを有するフォークが勝つ。採掘者又は採掘者のグループが、より多くの計算能力を集合的に有するほど、採掘者らは、作業証明アプローチの下で、ますます多くのブロックを生成することが可能である。換言すれば、大部分の計算能力を集合的に有する合意ノードによって受け入れられるブロックは、他のノードによって後に採用される合意となるであろう。別の実施形態において、大多数の合意ノードによって、合意に達することが可能である。したがって、大多数の合意ノードによって正当と確認されるブロックは、検証及び記録のために、他のノードに伝搬されるであろう。分散取引合意ネットワークとして、ＴＢＣＡネットワーク１００は、各取引に関して合意に達する必要があるが、ここで各取引は、その後、複数のノードに格納される分散台帳に記録される。

【0034】

前に議論したように、各仮想財布は、特定のデジタル財産管理モジュールに関連付けられるが、ここで特定のデジタル財産管理モジュールは、銀行、金融機関、証券取引会社、投資会社、通信事業者（「通信会社」）などによって運営することが可能である。各仮想財布は、ＴＢＣＡネットワーク１００において、一意的な仮想財布ＩＤを有する。例えば、ウイリアムは、契約者として、複数の仮想財布を有することが可能であり、それらの各々は、仮想財布ＩＤによって識別され、且つ、口座番号を介して、それぞれ、ＢａｎｋｏｆＡｍｅｒｉｃａ（「ＢＯＡ」）、Ｆｉｄｅｌｉｔｙ、又はＧｏｌｄｍａｎＳａｃｈｓに関連付けられ、又は、電話番号を介して、それぞれ、ＡＴ＆Ｔ株式会社（「ＡＴＴ」）、ＳｏｆｔＢａｎｋ社（「ＳＢＴ」）、若しくはＦａｒＥａｓＴｏｎｅＴｅｌｅｃｏｍ（「ＦＥＴ」）に関連付けられる。一実施形態において、各仮想財布は、仮想財布が関連付けられるデジタル財産管理人によって発行されるデジタル財産だけを格納することが可能である。例えば、ＢａｎｋｏｆＡｍｅｒｉｃａに関連付けられたウイリアムの仮想財布は、ＢａｎｋｏｆＡｍｅｒｉｃａによって発行されたデジタル財産だけを格納することが可能であり、ＡＴＴに関連付けられたウイリアムの仮想財布は、ＡＴＴによって発行されたデジタル財産だけを格納することが可能である。

【0035】

各取引ノードは、デジタル通貨（例えば、デジタル米ドル、デジタル日本円、デジタルユーロ、及びデジタル新台湾ドル）、デジタル株券（例えば、デジタルアップル株、デジタルグーグル株、及びデジタル投資信託）、デジタル貴金属（例えば、デジタル金、デジタル白金、及びデジタル銀）、及びデジタル先物（例えば、コーヒー豆、大豆、及びとうもろこしのデジタル先物）のような、種々異なるタイプのデジタル財産を発行することが可能である。各デジタル財産は、デジタル財産のタイプ及びそのデジタル財産管理人の両方の組み合わせによって特徴付けられる。一実施形態において、該組み合わせは、デジタル財産のタイプに対する記号であり得るが、ここで該記号の後には、両方の記号を分離するドットと共に、デジタル財産管理人に対する記号が続く。一実施形態において、ＢａｎｋｏｆＡｍｅｒｉｃａ（これの記号は「ＢＯＡ」である）は、デジタル米ドル（これの記号は「＄ＵＳＤ」である）及びデジタル日本円（これの記号は「＄ＪＰＹ」である）の両方を発行することが可能であり、これらは、この実施形態では、＄ＵＳＤ．ＢＯＡ（１＄ＵＳＤ．ＢＯＡは、この実施形態では、１米ドルの価値がある）及び＄ＪＰＹ．ＢＯＡ（１＄ＪＰＹ．ＢＯＡは、この実施形態では、１日本円の価値がある）として識別され得る。

【0036】

一実施形態において、ＵＴＸＯのフレーバーコイン（「ＦＣ」）フィールドは、デジタル財産のタイプ及びその発行者を指し示すのに使用される。例として、ＦＣは、ＦＥＴによって発行されたデジタル米ドルを指し示すべく、１０（＄ＵＳＤ．ＦＥＴ）に等しい。ＦＣは、ＦＥＴによって発行されたデジタル新台湾ドルを指し示すべく、１１（＄ＮＴＤ．ＦＥＴ）に等しい。ＦＣは、ＡＴＴによって発行されたデジタル米ドルを指し示すべく、２０（＄ＵＳＤ．ＡＴＴ）に等しい。ＦＣは、ＡＴＴによって発行されたデジタル新台湾ドルを指し示すべく、２１（＄ＮＴＤ．ＡＴＴ）に等しい。値（又は、デジタル財産の額若しくは単位）に加えて、各出力ＵＴＸＯは、デジタル財産のタイプ及びその発行者を指し示すべく、ＦＣフィールドを含む。

【0037】

一実施形態において、送信者から受信者への送金取引は、３つの部分を備え、それらは、それぞれ、（ａ）送信取引、即ち、（送信者のデジタル財産管理人によって発行された）デジタル財産を、送信者の仮想財布から送信者のモジュールへ移動させること、（ｂ）管理モジュール間取引、即ち、（送信者のデジタル財産管理人又は受信者のデジタル財産管理人から発行された）デジタル財産を、送信者のモジュールの仮想財布から受信者のモジュールの仮想財布へ移動させること、及び（ｃ）送達取引、即ち、（受信者のデジタル財産管理人によって発行された）デジタル財産を、受信者のモジュールの仮想財布から受信者の仮想財布へ移動させること、である。この送金取引を完成させるために、３つの部分（取引セット）、例えば、もし各部分がサブ取引を構成する場合、３つのサブ取引は、全体として正当と確認され、且つ、確かめられなければならない。もし１つのサブ取引が拒絶される場合、３つの全てのサブ取引が拒絶されなければならない。図６Ａから図６Ｃは、送金取引のデータ構造及びその取引の入力と出力の実施形態を例示する。一実施形態において、この履行は、送信者及び受信者のような契約者の仮想財布が、契約者の仮想財布が関連付けられるデジタル財産管理人によって発行されたデジタル財産だけを格納する、という任意選択的な要件にも準拠している。

【0038】

一実施形態において、米国にいるウイリアムは、ＡＴＴモジュール（送信者のモジュール）に関連付けられた彼の仮想財布に格納されたデジタル財産を使用して、ＦＥＴ（受信者のモジュール）に関連付けられた仮想財布を有する、台湾にいるスティーブに支払を送金したいと思う。ウイリアムは、彼の携帯電話からＡＴＴモジュール（送信者のモジュール）へ送金要求を送信する。送金要求は、ＡＴＴに関するウイリアムの携帯電話番号（携帯契約者番号、ＭＳＮとも呼ばれる）と、ＦＥＴに関するスティーブの携帯電話番号と、送金されるべきデジタル財産の額及びタイプ（例えば、６０＄ＵＳＤ．ＡＴＴ（ＡＴＴによって発行されたデジタル米ドル））と、を含む。ＡＴＴモジュール（送信者のデジタル財産管理モジュール）は、その後、ＦＥＴモジュール（受信者のデジタル財産管理モジュール）と通信し、それによって、全ての必要な情報を収集すると共に、送金取引を共同して構成するが、ここで該送金取引は、送信取引、管理モジュール間取引、及び送達取引を含み、これらの取引は、ＴＢＣＡネットワーク１００のような分散取引合意ネットワークのＡＴＴ取引ノード又はＦＥＴ取引ノードのいずれかに送信される。

【0039】

匿名性を改善するための１つのアプローチは、送信者のデジタル財産管理モジュールと受信者のデジタル財産管理モジュールとの間で新奇な相互作用を履行することであり、その結果として、共同して送金取引を構成するプロセスにおいて、どちらのモジュールも、特定の送金取引を追跡するための、送信者の仮想財布ＩＤ及び受信者の仮想財布ＩＤの両方に対するアクセスを有さないであろう。例えば、送信者のデジタル財産管理モジュールは、送信者の携帯電話番号、送信者の仮想財布ＩＤ、及び（送信者によって提供された）受信者の携帯電話番号を有するが、しかし、受信者の仮想財布ＩＤに対するアクセスを有さない。同様に、受信者のデジタル財産管理モジュールは、受信者の携帯電話番号、受信者の仮想財布ＩＤ、（送信者のモジュールによって提供された）送信者の携帯電話番号を有するが、しかし、送信者の仮想財布ＩＤに対するアクセスを有さない。その結果、任意のデジタル財産管理モジュールに侵入するハッカーは、任意の特定の送金取引を追跡するための、全ての必要な情報を得られない。

【0040】

図７は一実施形態を例示し、該実施形態では、送金取引は３つの部分を備えるが（各部分はサブ取引を構成する）、これらの部分は、ウイリアムの仮想財布からスティーブの仮想財布への支払移動を完了するためのものである。最後に、スティーブは、６０＄ＵＳＤ．ＦＥＴ（ＦＥＴによって発行されたデジタル米ドル）を受信するであろう。送金取引を完了させるためのこれら３つのサブ取引は、集合的に取引セットと呼ばれる。（各サブ取引を、ＴＢＣＡネットワーク１００による取引として考えることが可能である、ということに注意されたい。）送金取引の前には、ウイリアムの仮想財布は３つのＵＴＸＯを有しており、それらは、＄ＵＳＤ．ＡＴＴのタイプのもので、それぞれ、４、２１、及び５０という額である。ＡＴＴの仮想財布は３つのＵＴＸＯを有しており、それらは、＄ＵＳＤ．ＡＴＴのタイプのもので、それぞれ、２８、３６、及び６６という額である。ＦＥＴの仮想財布は３つのＵＴＸＯを有しており、それらは、＄ＵＳＤ．ＦＥＴタイプのもので、それぞれ、１７、４８、及び１２３という額である。そしてスティーブの仮想財布は１つのＵＴＸＯを有しており、それは、＄ＵＳＤ．ＦＥＴのタイプのもので、１００という額である。送信取引は、２つの入力ＵＴＸＯ（ウイリアムの仮想財布から選択された２１＄ＵＳＤ．ＡＴＴ及び５０＄ＵＳＤ．ＡＴＴ）と、２つの出力ＵＴＸＯ（ＡＴＴの仮想財布にロックされた６０＄ＵＳＤ．ＡＴＴ及びウイリアムの仮想財布にロックされた１１＄ＵＳＤ．ＡＴＴ（ウイリアムに返されるおつり））と、を有する。管理モジュール間取引は、１つの入力ＵＴＸＯ（ＡＴＴの仮想財布から選択された６６＄ＵＳＤ．ＡＴＴ）と、２つの出力ＵＴＸＯ（ＦＥＴの仮想財布にロックされた６０＄ＵＳＤ．ＡＴＴ及びＡＴＴの仮想財布にロックされた６＄ＵＳＤ．ＡＴＴ（ＡＴＴに返されるおつり））と、を有する。送達取引は、２つの入力ＵＴＸＯ（ＦＥＴの仮想財布から選択された１７＄ＵＳＤ．ＦＥＴ及び４８＄ＵＳＤ．ＦＥＴ）と、２つの出力ＵＴＸＯ（スティーブの仮想財布にロックされた６０＄ＵＳＤ．ＦＥＴ及びＦＥＴの仮想財布にロックされた５＄ＵＳＤ．ＦＥＴ（ＦＥＴに返されるおつり））と、を有する。これら３つの全てのサブ取引が、ＴＢＣＡネットワーク１００のような分散取引合意ネットワークに伝搬され且つ引き渡された後、ウイリアムの仮想財布は、２つのＵＴＸＯを有し、それらは、＄ＵＳＤ．ＡＴＴタイプのもので、それぞれ、４及び１１という額である。ＡＴＴの仮想財布は、４つのＵＴＸＯを有し、それらは、＄ＵＳＤ．ＡＴＴタイプのもので、それぞれ、６、２８、３６、及び６０という額である。ＦＥＴの仮想財布は、３つのＵＴＸＯを有し、それらは、それぞれ、＄ＵＳＤ．ＡＴＴタイプのものが６０という額であり、＄ＵＳＤ．ＦＥＴタイプのものが５及び１２３という額である。スティーブの仮想財布は、２つのＵＴＸＯを有し、それらは、＄ＵＳＤ．ＦＥＴタイプのもので、それぞれ、６０及び１００という額である。

【0041】

一実施形態において、図８に示されるように、送信者のデジタル財産管理モジュールは、受信者のデジタル財産管理モジュールと協同して働き、それによって、送信者の送金要求を受信すると共に、該送金要求を送金取引へ変換するが、ここで該送金取引は、送金取引の匿名性を維持しながら、分散取引合意ネットワークのための適切な形式をした３つの部分を備える。送信者のデジタル財産管理モジュール８００は、送信者の財布サーバ８０２と、送信者のミドルウェア８０４と、デジタル財産管理モジュール８００自身のメッセージ公開キー及びメッセージ秘密キーの対と、受信者の取引ノードのメッセージ公開キーを取り出すための探索ＡＰＩと、を備える。受信者のデジタル財産管理モジュール８１０は、受信者の財布サーバ８１２と、受信者のミドルウェア８１４と、デジタル財産管理モジュール８１０自身のメッセージ公開キー及びメッセージ秘密キーの対と、を備える。

【0042】

メッセージ公開キーは、他のデジタル財産管理モジュールと共有されると共に、該デジタル財産管理モジュールによってアクセス可能であり、且つメッセージ秘密キーは、機密が保たれると共に、それらの所有者だけによってアクセス可能である。メッセージ秘密キーは、メッセージ上に署名を作成するために、（キー所有者である）メッセージ送信者によって使用されるが、ここで該署名は、（キー所有者ではない）メッセージ受信者が、メッセージ公開キーを使用して、それらが変更されていない本物のメッセージである、ということを証明するためのものである。メッセージ公開キーは、暗号化されたメッセージを作成するために、（キー所有者ではない）メッセージ送信者によって使用することが可能であり、その結果として、意図された（キー所有者である）メッセージ受信者は、メッセージ秘密キーを使用することにより、メッセージを暗号解読して、内容を知ることが可能である。

【0043】

図８のステップ８３０では、送信者の財布サーバ８０２は、送信者（例えば、ウイリアム）から受信者（例えば、スティーブ）へある額（例えば、６０デジタル米ドル）を移動させるための送金要求を受信する。送金要求は、少なくとも、（１）ウイリアムの携帯電話番号のような送信者の物理的身分証明書と、（２）スティーブの携帯電話番号のような受信者の身分証明書と、（３）送金のためのデジタル財産の額及びそのタイプと、を含む。送信者の財布サーバ８０２は、送信者の仮想身分証明書（ウイリアムの仮想財布ＩＤ）を送信者から直接受信してもよく、又は、送信者のデジタル財産管理モジュールのデータ格納庫から、該身分証明書を取り出してもよい。

【0044】

送金取引を完了させるために、分散取引合意ネットワークは、受信者の仮想身分証明書（スティーブの仮想財布ＩＤ）を必要とする。送信者のデジタル財産管理モジュールは、受信者のデジタル財産管理モジュールが誰にあるのかを知らないので、受信者のデジタル財産管理モジュールの場所を突きとめると共に、取引のための受信者の仮想身分証明書（スティーブの仮想財布ＩＤ）を取り出すために、受信者の物理的身分証明書（スティーブの携帯電話番号）を、他の全てのデジタル財産管理モジュールへ伝搬させなければならない。匿名性を改善するために、送信者のデジタル財産管理モジュールは、受信者の仮想財布ＩＤを有することを許可されておらず、したがって、受信者のデジタル財産管理モジュールは、送信者のデジタル財産管理モジュールに、最後には受信者の仮想財布ＩＤに関連し得るトークンを送信しなければならない。

【0045】

ステップ８３２では、送信者の財布サーバ８０２は、受信者の財布サーバ８１２からトークン応答を捜すために、（例えば、通信事業者（「通信会社」）によって運営される）他の全てのデジタル財産管理モジュールの財布サーバにトークン要求を送信するが、その理由は、送信者の財布サーバが、受信者がどのデジタル財産管理モジュールに関連付けられているかを知らないからである。例えば、ＦＥＴがスティーブの携帯電話番号が関連付けられている通信会社であることを、ＡＴＴは知らない。トークン要求は、暗号化されたネットワークを介して、他の全てのデジタル財産管理モジュールに直接送信することが可能である。代わりに、受信者のデジタル財産管理モジュールに到達すると共に、トークン応答を得ることを目的として、トークン要求は、他の全てのデジタル財産管理モジュールを含むネットワークに向けて放送され、且つ、ピアツウピアのうわさ話を頼りすることも可能である。そのような仕組みにおいては、トークン要求を受信する不適切なデジタル財産管理モジュールが、受信者のデジタル財産管理モジュールでない場合、該仕組みは、トークン要求をそのピアの全てに対して伝搬させる。もしそのような不適切なデジタル財産管理モジュールがトークン応答を受信する場合、該仕組みは、トークン応答を、トークン要求を送信したピアに中継して返す。

【0046】

一実施形態において、トークン要求は、ＡＴＴのような、送信者のデジタル財産管理モジュール（「送信者のモジュール」）の身分証明書と、スティーブの携帯電話番号のような、受信者の物理的身分証明書と、送信者のモジュールのメッセージ秘密キーを使用することによって、送信者のモジュールの身分証明書及び受信者の物理的身分証明書の両方のハッシュ又は生データの上に作成された署名と、を含む。その結果、受信者のデジタル財産管理モジュール（「受信者のモジュール」）は、送信者のモジュールのメッセージ公開キーを使用すると共に、メッセージのハッシュ又は生データを比較することによって、トークン要求内のメッセージ（例えば、ＡＴＴ及びスティーブの携帯電話番号）が本物である、ということを検証できる。

【0047】

トークン要求を受信した後、受信者のモジュールは、メッセージが本物であるということを検証し、且つ、その後、スティーブの携帯電話番号のような、彼／彼女の物理的身分証明書をチェックすることによって、受信者が契約者であるということを確認する。その後、受信者のモジュールは、トークンを生成し、且つ、トークン対応付けを作成するが、該トークン対応付けは、トークンを、スティーブの仮想財布のＩＤのような、受信者の仮想身分証明書に関連させるものである。一実施形態において、トークンは、無作為に生成された文字列であり得る。不適切なデジタル財産管理モジュールがトークンを傍受し、且つ、それを悪用することを防ぐために、一実施形態において、受信者のモジュールは、トークンを更に暗号化するか、又は、送信者のメッセージ公開キーを使用して、トークン及び（ＦＥＴのような）受信者のモジュールの身分証明書の両方を暗号化する。したがって、送信者のモジュールだけが、それ自身のメッセージ秘密キーを使用して、トークンを暗号解読することが可能である。トークンは、暗号化されたトークン又は暗号化されていないトークンを意味することが可能である。

【0048】

一実施形態において、トークンが生成される場合、トークンのコピーもまた、正当なトークンプールに配置される。構築するためにトークンが使用される送達取引が分散台帳に引き渡された後、該コピーは、それが再び使用されるのを防ぐために、正当なトークンプールから除去される。別の実施形態において、トークンは、トークンが生成された時刻を指し示すためのタイムスタンプを含む。ある与えられた時間期間が経過した後、トークンは拒絶されるであろう。そして該トークンは、取引を構築するために、もはや使用できない。

【0049】

ステップ８３４では、受信者の財布サーバ８１２は、トークン応答を送信者の財布サーバ８０２へ直接送り返す。代わりに、トークン応答は、他の全てのデジタル財産管理モジュールの財布サーバを含むネットワークへ送られ、且つ、その後、ピアツウピアのうわさ話によって、送信者の財布サーバへ中継して返される。トークン応答は、（１）送信者のデジタル財産管理モジュールの身分証明書（例えば、ＡＴＴ）と、（２）受信者の物理的身分証明書（例えば、スティーブの携帯電話番号）と、（３）送信者のデジタル財産管理モジュールのメッセージ公開キーを使用して暗号化されたトークン及び受信者のデジタル財産管理モジュールの身分証明書（例えば、ＦＥＴ）の両方と、（４）彼／彼女のメッセージ秘密キーを使用することによって、上記の項目（１）から項目（３）の上に作成された受信者の署名と、を含むことが可能である。受信者の署名によって、送信者のデジタル財産管理モジュールは、受信者のデジタル財産管理人を検証すると共に、上記の項目（１）から項目（３）のメッセージにおける情報が本物であることを検証し、それによって、該情報が、にせのソースからのものでなく、且つ、変更されていない、ということを保証することが可能である。

【0050】

トークン応答を受信した後、送信者のデジタル財産管理モジュールは、受信者のメッセージ公開キーを使用して、受信者の署名をチェックし、それによって、該トークン応答が、受信者のために署名できるただ１つのモジュールである、受信者のデジタル財産管理モジュールから実際に来ている、ということを検証する。送信者のデジタル財産管理モジュールはまた、そのメッセージ秘密キーを使用して、暗号化されたトークン及び受信者のモジュールの身分証明書を暗号解読し、それによって、トークン及びＦＥＴのようなメッセージを取り出さなければならない。

【0051】

ステップ８３６では、必要な全ての情報を収集した後、送信者の財布サーバ８０２は、分散取引合意ネットワークに対する送金取引を構築するために、送信者のミドルウェア８０４に情報を提供する。一実施形態において、送信者のミドルウェア８０４は、送信取引、管理モジュール間取引、及び送達取引を構築することを試みる。送信取引を構築するために、送信者のミドルウェア８０４は、図７における２１＄ＵＳＤ．ＡＴＴ及び５０＄ＵＳＤ．ＡＴＴのような送金額に基づいて、送信者の仮想財布から１つ以上のＵＴＸＯを選択する。送信取引は、送信者の取引秘密キーによって署名される必要がある。送信者のミドルウェアは、それを送信者の財布サーバ８０２へ送り返すが、ここで送信者の財布サーバ８０２は、送信取引が署名されるべく、署名サーバとインターフェースで連結されている。署名サーバは、その後、署名された送信取引を送信者の財布サーバ８０２へ逆に戻し、送信者の財布サーバ８０２は、それを送信者のミドルウェア８０４へ戻す。同様に、管理モジュール間取引を構築するために、送信者のミドルウェア８０２は、送信者のデジタル財産管理人の仮想財布から、図７における６６＄ＵＳＤ．ＡＴＴのような、１つ以上のＵＴＸＯを選択する。管理モジュール間取引はまた、送信取引のプロセスと同じ又は同様なプロセスに従って、署名される必要がある。送達取引を構築するために、送信者のミドルウェア８０２は、受信者の仮想財布ＩＤを置き換えるためにトークンを使用し、且つ、一時的な送達取引を構築する。

【0052】

ステップ８３７では、送信者のミドルウェア８０４は、取引ノード探索ＡＰＩ８０６のメッセージ公開キーから、受信者の取引ノードのメッセージ公開キーを取り出す。探索ＡＰＩ８０６は、受信者の取引ノードのメッセージ公開キーを引き出すために、２つのデータベース（デジタル財産管理人から取引ノードキャッシュまで（８０７）、及び取引ノードからメッセージ公開キーキャッシュまで（８０８））に格納された情報をチェックする必要がある。匿名性を改善するために、受信者のデジタル財産管理モジュールは、仮想財布ＩＤのような、送信者の仮想身分証明書に対するアクセスを有することを許可されていない。したがって、送信者のデジタル財産管理モジュールは、受信者の取引ノードのメッセージ公開キーを使用することによって、署名された送信取引を暗号化する。

【0053】

安全性の理由のために、８５０、８６０のような取引ノードは、メッセージ公開キー及びメッセージ秘密キーを備える新しいキー対を周期的に生成し、それを分散取引合意ネットワークに提出し、且つ、それが分散台帳に記録されるようにする。新しいキー対が生成される時はいつでも、取引ノード８５０、８６０は、８０８、８１８のような、ノードから公開キーキャッシュまでに対して、新しい公開キーを押し出すであろう。取引ノード８５０、８６０は、現在のメッセージ公開キー及びすぐ前のメッセージ秘密キーの両方を、そのメモリに保存するであろう。

【0054】

ステップ８３８では、送信者のデジタル財産管理モジュールの送信者のミドルウェア８０４は、暗号化された送信取引、管理モジュール間取引、及び一時的な送達取引を、受信者のデジタル財産管理モジュールの受信者のミドルウェア８１４へ送信する。受信者のデジタル財産管理モジュールは、受信者のデジタル財産管理人の仮想財布が、送信者のデジタル財産管理人の仮想財布からの資金移動を受信するであろうということを確認するために、管理モジュール間取引を検証する。受信者のモジュール８１０は、トークン及びトークン対応付けデータベース８１３を使用することによって、スティーブの仮想財布ＩＤのような受信者の仮想身分証明書を取り出し、それによって、一時的な送達取引を正規のものに変換する。受信者のデジタル財産管理モジュールはまた、送達取引を構築する前に、トークンが依然として正当なトークンプールにあるかどうかを検証するであろう。そして該デジタル財産管理モジュールは、分散取引合意ネットワークによって送達取引が引き渡された後は、正当なトークンプールから該トークンを除去する。結果として、トークンは、再使用されないであろう。受信者のモジュール８１０はまた、受信者のデジタル財産管理人の仮想財布から、図７における１７＄ＵＳＤ．ＦＥＴ及び４８＄ＵＳＤ．ＦＥＴのような、１つ以上のＵＴＸＯを選択し、且つ、送信取引のプロセスと同じ又は同様なプロセスに従って、受信者のデジタル財産管理人の仮想財布の取引秘密キーを使用することによって、それが署名されるようにしなければならない。

【0055】

ステップ８４０では、受信者のミドルウェア８１４は、暗号化された送信取引、管理モジュール間取引、及び送達取引を受信者の取引ノード８５０に送信する。受信者の取引ノード８５０は、その現在のメッセージ秘密キーを使用することによって、暗号化された送信取引を暗号解読する。もし現在のメッセージ秘密キーが働かない場合、受信者の取引ノード８５０は、暗号解読のために、それのすぐ前のメッセージ秘密キーを使用するであろう。暗号解読の後、受信者の取引ノード８５０は、送信取引、管理モジュール間取引、及び送達取引を、分散取引合意ネットワークの他のノードへ伝搬させる。

【0056】

図８に示されたプロセス（該プロセスでは、受信者のミドルウェア８１４は、送信取引、管理モジュール間取引、及び送達取引の全てを受信者の取引ノードへ送信する）とは違って、図９に示されるような別の実施形態において、送信者のミドルウェアは、３つの全てのサブ取引を送信者の取引ノードへ送信する。ステップ９３０、９３２、９３４、及び９３６は、図８に示されるようなステップ８３０、８３２、８３４、及び８３６と、それぞれ同じである。ステップ９３７では、送信者のミドルウェア９０４は、受信者のミドルウェア９１４に管理モジュール間取引及び一時的な送達取引を送信する。受信者のデジタル財産管理モジュールは、受信者のデジタル財産管理人の仮想財布が、送信者のデジタル財産管理人の仮想財布から資金移動を受信するであろうということを確認するために、管理モジュール間取引を検証する。その後、受信者のモジュールは、トークン及びトークン対応付けデータベース９１３を使用することによって、一時的な送達取引を正規なものに変換する。

【0057】

ステップ９３８では、受信者のミドルウェア９１４は、取引ノード探索ＡＰＩ９１６のメッセージ公開キーから送信者の取引ノードのメッセージ公開キーを取り出す。探索ＡＰＩ９１６は、送信者の取引ノードのメッセージ公開キーを引き出すために、２つのデータベース（デジタル財産管理人から取引ノードキャッシュまで（９１７）、及び取引ノードからメッセージ公開キーキャッシュまで（９１８））に格納された情報をチェックする必要がある。匿名性を改善するために、送信者のデジタル財産管理モジュールは、仮想財布ＩＤのような、受信者の仮想身分証明者に対するアクセスを有することを許可されていない。したがって、受信者のデジタル財産管理モジュールは、送信者の取引ノードのメッセージ公開キーを使用することによって、署名された送達取引を暗号化する。

【0058】

ステップ９３９では、受信者のデジタル財産管理モジュールの受信者のミドルウェア９１４は、送信者のデジタル財産管理モジュールの送信者のミドルウェア９０４へ、暗号化された送達取引を送信する。

【0059】

ステップ９４０では、送信者のモジュールは、送信者の取引ノードへ、送信取引、管理モジュール間取引、及び暗号化された送達取引を送信する。送信者の取引ノードは、自身の現在のメッセージ秘密キーを使用して、暗号化された送達取引を暗号解読する。もしそれが働かない場合、送信者の取引ノードは、自身のすぐ前のメッセージ秘密キーを使用することを試みるであろう。暗号解読の後、送信者の取引ノードは、その後、送信取引、管理モジュール間取引、及び送達取引の全てを、分散取引合意ネットワークに伝搬させる。

【0060】

第３の実施形態において、最初の５つのステップは、第２の実施形態のステップ９３０、９３２、９３４、９３６、９３７と同じである。受信者のデジタル財産管理モジュールは、受信者のデジタル財産管理人の仮想財布が、送信者のデジタル財産管理人の仮想財布からの資金移動を受信するであろうということを確認するために、管理モジュール間取引を検証する。その後、受信者のモジュールは、トークン及びトークン対応付けデータベースを使用することによって、一時的な送達取引を正規なものに変換する。送信者のモジュールは、送信者の取引ノードへ送信取引を送信する。受信者のモジュールは、受信者の取引ノードへ管理モジュール間取引及び送達取引を送信する。送信取引及び送達取引のどちらも、暗号化される必要はない。送信者の取引ノード及び受信者の取引ノードの両方が、分散取引合意ネットワークへ取引を伝搬させる。

【0061】

上の２つの実施形態は、送信者のモジュールが、スティーブの仮想財布ＩＤのような、受信者の仮想身分証明書に対するアクセスを有さず、且つ、受信者のモジュールが、ウイリアムの仮想財布ＩＤのような、送信者の仮想身分証明書に対するアクセスを有さない、ということを保証するためのプロセスを提供する。その結果、匿名性は実質的に上がるが、その理由は、送信者のモジュール又は受信者のモジュールのいずれかが、送金取引を再構築するために、分散台帳に記録された送信取引、管理モジュール間取引、及び送達取引の３つ全てを追跡すると共に結合させることは、ありそうにないからである。しかしながら、もし分散台帳のコピーを有する誰かが、各サブ取引を注意深く分析する場合、移動させることを意図したデジタル財産の額を一致させることによって、送金取引内の３つのサブ取引を結合させることは、依然として可能かもしれない。例えば、図７に示されるように、送信取引において、ウイリアムが６０デジタル米ドルをＡＴＴの仮想財布に移動させたこと、及び、管理モジュール間取引において、ＡＴＴの仮想財布が、６０デジタル米ドルをＦＥＴの仮想財布に移動させたことを、ＡＴＴは知っている。その後、もしＡＴＴが、同じ又は隣接したブロック内で、ＦＥＴから６０デジタル米ドルを受信した受信者を一致させることを試みるならば、ＡＴＴは、スティーブの仮想財布ＩＤに気付き、且つ、３つの全てのサブ取引を再構築できるかもしれない。

【0062】

匿名性を更に改善するために、送信取引、管理モジュール間取引、及び送達取引の１つ以上を、２つ以上のサブ取引に更に分裂させることが可能である。例えば、送達取引は、第１の送達取引と第２の送達取引に分解することが可能であり、それらの各々は、移動させるべき異なる額を有するが、しかし合計は、元の送達取引と同じである。この状況では、１つの送金取引を再構築するために、４つのサブ取引を結合しなければならない。同様に、送信取引を、第１の送信取引、第２の送信取引、及び第３の送信取引のような、２つ以上のサブ取引に更に分裂させることが可能である。このアプローチを使用することによって、送信者のモジュール、受信者のモジュール、及び／又は分散台帳へのアクセスを有するハッカーは、送金取引を再構築するために、サブ取引の移動させるべき額を、容易には一致させられない。

【0063】

図１０に示されるような第４の実施形態において、送信取引及び管理モジュール間取引が、図７におけるのと同じままでありながら、送達取引は、第１の送達取引と第２の送達取引に分解される。第１の送達取引は、１つの入力ＵＴＸＯ（１７＄ＵＳＤ．ＦＥＴ）と、スティーブの仮想財布にロックされた１つの出力ＵＴＸＯ（１７＄ＵＳＤ．ＦＥＴ）と、を有する。第２の送達取引は、１つの入力ＵＴＸＯ（４８＄ＵＳＤ．ＦＥＴ）と、２つの出力ＵＴＸＯ（スティーブの仮想財布にロックされた４３＄ＵＳＤ．ＦＥＴ及びＦＥＴの仮想財布にロックされた５＄ＵＳＤ．ＦＥＴ（おつり））と、を有する。サブ取引において移動させるべき額が互いに一致しないこと、及び、ある状況では、送信者のモジュールがサブ取引の合計数に気付かないかもしれないことを考えると、ハッカーは送金取引を再構築できないであろう。

【0064】

匿名性を上げるための別の代替案において、入力デジタル財産の額は、基底額にある複数の小片に分解することが可能であり、且つ各小片は、別々のサブ取引を構成する。分散取引合意ネットワーク、取引ノード、又はデジタル財産管理モジュールは、発行されるべき、ＵＴＸＯのような、デジタル財産の基底額を決定することが可能である。例えば、基底額は、５、１０、２０、５０、１００、２００、５００などであり得る。したがって、基底額にある複数のＵＴＸＯは、送信取引、管理モジュール間取引、又は送達取引のいずれかに対して、多数のサブ取引の入力ＵＴＸＯとして使用することが可能である。特に、管理モジュール間取引を基底額にある複数のサブ取引に分裂させることは、送金取引の追跡をより困難にするであろう。

【0065】

取引の匿名性と性能の効率をバランスさせるために、移動させるべき額は、限られた数の小片だけに分割することが可能である。当業者は、移動させるべき額を基底額にある幾つかの小片に分割することの最適化を試みる、様々なアルゴリズムを使用することが可能である。幾つかの状況において、もし特定の基底額にあるＵＴＸＯが利用可能でない場合、より大きな額のＵＴＸＯを使用することが可能である。換言すれば、より良い性能を達成するためには、小片の合計は、移動させる額よりも大きいことが可能であり、且つ差額のおつりは、送信する仮想財布に戻すことが可能である。例えば、＄３６８．４６の移動させるべき額は、１つの＄２００、１つの＄１００、１つの＄５０、及び１つの＄２０に分割することが可能である。＄１．５４のおつりは、送信者に戻すことが可能である。

【0066】

図１１に示されるような第５の実施形態において、ウイリアムは、１６デジタル米ドルをスティーブに送信したいと思う。送信取引は、１つの入力ＵＴＸＯ（２０＄ＵＳＤ．ＡＴＴ）及び３つの出力ＵＴＸＯを有し、ここで３つの出力ＵＴＸＯは、それぞれ、ＡＴＴの仮想財布にロックされた１０＄ＵＳＤ．ＡＴＴ、ＡＴＴの仮想財布にロックされた６＄ＵＳＤ．ＡＴＴ、及びウイリアムの仮想財布にロックされた４＄ＵＳＤ．ＡＴＴ（おつり）である。管理モジュール間取引は、３つのサブ取引を備える。第１の管理モジュール間取引は、１つの入力ＵＴＸＯ（１０＄ＵＳＤ．ＡＴＴ）と、１つの出力ＵＴＸＯ（ＦＥＴの仮想財布にロックされた１０＄ＵＳＤ．ＡＴＴ）と、を有する。第２の管理モジュール間取引は、１つの入力ＵＴＸＯ（５＄ＵＳＤ．ＡＴＴ）と、１つの出力ＵＴＸＯ（ＦＥＴの仮想財布にロックされた５＄ＵＳＤ．ＡＴＴ）と、を有する。第３の管理モジュール間取引は、１つの入力ＵＴＸＯ（５＄ＵＳＤ．ＡＴＴ）と、２つの出力ＵＴＸＯ（ＦＥＴの仮想財布にロックされた１＄ＵＳＤ．ＡＴＴ及びＡＴＴの仮想財布にロックされた４＄ＵＳＤ．ＡＴＴ（おつり））と、を有する。送達取引は２つのサブ取引を備える。第１の送達取引は、１つの入力ＵＴＸＯ（１０＄ＵＳＤ．ＦＥＴ）と、１つの出力ＵＴＸＯ（スティーブの仮想財布にロックされた１０＄ＵＳＤ．ＦＥＴ）と、を有する。第２の送達取引は、１つの入力ＵＴＸＯ（１０＄ＵＳＤ．ＦＥＴ）と、２つの出力ＵＴＸＯ（スティーブの仮想財布にロックされた６＄ＵＳＤ．ＦＥＴ及びＦＥＴの仮想財布にロックされた４＄ＵＳＤ．ＦＥＴ（おつり））と、を有する。その結果、ウイリアムからスティーブへの１６デジタル米ドルのこの送金取引は、６つのサブ取引を備える。６つの全てのサブ取引は、同時に正当と確認されなければならないか、又は、同時に失敗とされなければならない。（各サブ取引を、ＴＢＣＡネットワーク１００による取引として考えることが可能である、ということに注意されたい。）

【0067】

取引の匿名性を上げるために、上で説明された様々な対策は、単独で又は組み合わせて、適用することが可能である。しかしながら、分散取引合意ネットワーク（ＴＢＣＡネットワーク１００）がマネーロンダリング促進者となるのを防ぐために、デジタル財産管理システムが特定のデジタル財産取引を追跡可能であることは必要である。追跡性を上げるために、送金取引が（セットとなっている）複数のサブ取引を備える場合、同じ送金取引セット内の各サブ取引の順序を識別すると共に特定するべく、ラベルが作成される。一実施形態において、送金取引は、３つのサブ取引（１つの送信取引、１つの管理モジュール間取引、及び１つの送達取引）を備え、これらの各々には、それらが特定の送金取引セット及び該セット内のそれらの順序に属する、ということを示すためのラベルが与えられる。ラベルは、その後、追跡キーによって暗号化される。一実施形態において、ラベルは暗号化され、且つ管理者１１０（ＴＢＣＡ）だけが、同じ送金取引セット内の３つのサブ取引を識別するための追跡秘密キーを有し、それによって、セットを再構築すると共に、特定の取引に関連する仮想財布及び額を追跡する。

【0068】

一実施形態において、送信者のモジュール又は受信者のモジュールのいずれかが、各サブ取引に対して、｛ｓｅｔ｝＿１＿｛ｎｏｎｃｅ｝、｛ｓｅｔ｝＿２＿｛ｎｏｎｃｅ｝、及び｛ｓｅｔ｝＿３＿｛ｎｏｎｃｅ｝のような、人間が可読な（且つコンピュータが解析可能な）ラベルを生成することが可能である。ここで｛ｓｅｔ｝は、送金取引セット内の全てのサブ取引が同じ取引セット番号を共有するような、取引セット番号であり、そして｛ｎｏｎｃｅ｝は、何らかの大きい無作為な数である。新しいノンス（ｎｏｎｃｅ）は、デジタル財産管理モジュールが全てのセット番号を使い尽くす前に、生成されなければならないが、しかし、例えば、各ブロックが異なるノンスを有し得るなど、必要に応じて何度でも生成されることが可能である。一実施形態において、送信者のモジュールのミドルウェアは、ノンス「ｎ」を無作為に生成すると共に、保持することが可能である（これは、もし該ミドルウェアが、１つのノンスも生成していない場合、又は該ミドルウェアが、既に生成したノンスに対して、可能なセット番号を使い果たした場合に当てはまる）。同様に、ミドルウェアはまた、セット番号｛ｓｅｔ｝を保持するべきであるが、ここで該セット番号｛ｓｅｔ｝は、ミドルウェアが送金取引セットにラベルを付けた後は、毎回１だけ増加する。新しいノンスが生成される時はいつでも、セット番号を０にリセットすることが可能である。一実施形態において、セットフィールドサイズは、暗号化アルゴリズム（例えば、ＡＥＳ対称キーアルゴリズム）の使用を考慮して、選択することが可能である。ラベルのノンス部分は、約２４バイトであり得る。

【0069】

一実施形態において、表面上は無作為で異なる文字列を生成するために、各ラベルは、その後、２５６ビットキーを有するＡＥＳ対称アルゴリズムによって暗号化される（ｈｔｔｐｓ：／／ｅｎ．ｗｉｋｉｐｅｄｉａ．ｏｒｇ／ｗｉｋｉ／Ａｄｖａｎｃｅｄ＿Ｅｎｃｒｙｐｔｉｏｎ＿Ｓｔａｎｄａｒｄ）。ＲＳＡのような、他の暗号化アルゴリズムを使用することが可能である。実際、当業者は、安全性と性能必要性をバランスさせられる任意の暗号化アルゴリズムを選択することが可能である。対称暗号化の仕組みの下で、ＴＢＣＡ１１０は、デジタル財産管理モジュールごとに少なくとも１つの対称キーを取っておくであろう。そして各モジュールは、送金取引セット内のサブ取引に対するラベルを暗号化するために、それ自身の対称キーを保持するであろう。送金取引セット内の各サブ取引は、その後、その暗号化されたラベル（これらの無作為に見える文字列の１つ）を有する取引セットフィールドを含み、且つ、ブロックチェーンに記録されるであろう。送金取引が、１つの送金取引セット内に６つのサブ取引（Ｔ１、Ｔ２、Ｔ３、Ｔ４、Ｔ５、及びＴ６）を備える一実施形態において、対称追跡キーが使用される場合、ＡＥＳ（ＴｒａｃｉｎｇＫｅｙ，Ｌａｂｅｌ）が、我々の暗号化アルゴリズムである。別の実施形態において、ラベルを暗号化するために、非対称キー対の追跡公開キーを使用することが可能である。９つのサブ取引のラベル、即ち、ｘ＿１＿ｎ、ｘ＿２＿ｎ、．．．ｘ＿９＿ｎ、が生成され（ｘは取引セット番号、そしてｎはノンスである）、且つ、その後、対称追跡キー又は追跡公開キー（非対称）のいずれかを使用することによって暗号化される。その後、これらの暗号化されたラベルは、送金取引セット内の各サブ取引に対する取引セットフィールドの中に挿入される。その後、ｘが既にその最大値に達していないならば、ｘは１だけ増加する。もしｘがその最大値にある場合、ｘは０にリセットされ、且つ新しいｎが生成される。図１２に示されるように、各サブ取引は、暗号化されたラベルを格納するための、「取引セット」と名付けられた新しいフィールドを含む。（各サブ取引を、ＴＢＣＡネットワーク１００における取引として考えることが可能である、ということに注意されたい。）

【0070】

送金取引セットを回復するために、暗号化されたラベルＬｎと共にブロック内のＴｎ取引を仮定し、且つ、ＡＥＳ’（ＴｒａｃｉｎｇＫｅｙ，Ｌｎ）＝Ｌ’ｎが我々の暗号解読アルゴリズムである、ということを仮定せよ。即ち、（１）各Ｌｎに対して、ＡＥＳ’（ＴｒａｃｉｎｇＫｅｙ，Ｌｎ）＝Ｌ’ｎを見つけよ、（２）Ｌ’ｎは、｛ｓｅｔ｝＿（１，２，３，４，５，ｏｒ６）＿｛ｎｏｎｃｅ｝の形であろう、（３）同じセット番号を有する全ての取引は、同じ送金取引内にある。

【0071】

非対称追跡キーが使用される場合、そのデジタル財産管理モジュール及び、通信事業者（「通信会社」）のような取引ノードを含むデジタル財産管理人は、追跡秘密キーを有さないので、デジタル財産管理人は、特定の送金取引を追跡するために、送金取引セット内で暗号化されたラベルを回復できない。追跡秘密キーによって、必要な場合、管理者（ＴＢＣＡ１１０）又は、分散取引合意ネットワークの権威付けされた／任命されたノードは、特定の取引を回復すると共に追跡し、それによって、送信者の仮想財布ＩＤ、受信者の仮想財布ＩＤ、及び移動させるデジタル財産の額とタイプを識別することが可能である。対称キーが使用される場合、各デジタル財産管理人は、暗号化されたラベルを該デジタル財産管理人自身が提供するサブ取引については暗号解読できるが、しかしネットワーク管理者は、全てのサブ取引を暗号解読できる。その理由は、ネットワーク管理者が、各デジタル財産管理モジュールが使用する追跡キーのコピーを有するからである。実世界において、送信者及び受信者を実際に識別するために、ネットワーク管理者は、依然としてデジタル財産管理人と共に働く必要があるが、ここで該デジタル財産管理人は、仮想財布ＩＤをその契約者の電話番号又は、社会保障番号のような他の物理的身分証明書に結びつけることが可能である。

【0072】

以下は、匿名性及び追跡性に関して上で説明された実施形態に対する疑似コードの例である。

【0073】

***********************************************************************
Telco Module Function:
Function SendRemittance(FromMsn, ToMsn, Asset)
TokenRequest = ConstructTokenRequest(ToMsn)
For All Peer Telcos:
If Not Empty Peer.RelayTokenRequest(TokenRequest)
(Token, TargetTelco) = This.TelcoPrivateKey.Decrypt(Not Empty Peer.TelcoRelayTokenRequest(TokenRequest).EncryptedData)
ReceivingNodePublicKey = LookupNodePublicKey(TargetTelco)
SendingTxn = ReceivingNodePublicKey.Encrypt(ConstructSendingTxn(FromMsn, Asset))
InterManageeTxn = ConstructInterManageeTxn(FromMsn, ToMsn, Asset)
DeliveryTxn = ConstructDeliveryTxn(Token, Asset)
SignTxns([SendingTxn, InterManageeTxn])
TargetTelco.ReceiveTxns(SendingTxn, InterManagerTxn, DeliveryTxn)
Function ConstructTokenRequest(toMsn)
TokenRequest.SendingTelco = GetTelcoFor(toMsn)
TokenRequest.Msn = toMsn
TokenRequest.Signature = This.TelcoPrivateKey.Sign(TokenRequest.SendingTelco, TokenRequest.Msn)
Return TokenRequest
Function RelayTokenRequest(TokenRequest)
If IsValid(TokenRequest)And IsNew(TokenRequest)
If OwnsMsn(TokenRequest.Msn)
Token = CreateToken(TokenRequest.Msn)
MapToken(Token, TokenRequest.Msn)
TokenResponse = CreateTokenResponse(TokenRequest)
Return TokenResponse
Else
For All Peer Telcos:
If Not Empty Peer.RelayTokenRequest(TokenRequest)
Return Not Empty Peer.RelayTokenRequest(TokenRequest)
Else Return Empty TokenResponse
Function CreateTokenResponse(TokenRequest)
TokenResponse.Msn = TokenRequest.Msn
TokenResponse.SendingTelco = TokenRequest.SendingTelco
TokenResponse.EncryptedData = GetPublicKeyFor(TokenRequest.SendingTelco).Encrypt( Token, This.Telco)
TokenResponse.Signature = This.TelcoPrivateKey.Sign(TokenResponse.Msn, TokenResponse.SendingTelco, TokenResponse.EncryptedData)
Return TokenResponse
Function ReceiveTxns(SendingTxn, InterManagerTxn, DeliveryTxn)
ReplaceTokenFromMap(DeliveryTxn)
SignTxns([DeliveryTxn])
(LabelA, LabelB, LabelC) = CreateLabelSet()
ApplyLabel(LabelA, SendingTxn)
ApplyLabel(LabelB, InterManagerTxn)
AppyLabel(LabelC, DeliveryTxn)
Ledger.SubmitTxns(SendingTxn, InterManagerTxn, DeliveryTxn)
Property SetNumber initialized at 0
Property Nonce initialized at Random()
Function CreateLabelSet()
LabelA = TBCAPublicKey.Encrypt(SetNumber, Nonce, 1)
LabelB = TBCAPublicKey.Encrypt(SetNumber, Nonce, 2)
LabelC = TBCAPublicKey.Encrypt(SetNumber, Nonce, 3)
If SetNumber = Maximum Set Number
SetNumber = 0
Nonce = Random()
Else
SetNumber++
Return LabelA, LabelB, LabelC
Function TxnFromLedger(Txn)
If Txn is a KeyUpdateTxn
UpdateNodePublicKey(Txn)
Node Functions:
Property CurrentPrivateKey
Property LastPrivateKey
Function RotateKeys()
(PublicKey, PrivateKey) = CreateNewKeypair()
(CurrentPrivateKey, LastPrivateKey) = (PrivateKey, CurrentPrivateKey)
KeyUpdateTxn = CreateKeyUpdateTxn(PublicKey)
BroadcastTxns([KeyUpdateTxn])
Function SubmitTxns(SendingTxn, InterManagerTxn, DeliveryTxn)
If CurrentPrivateKey.Decrypt(SendingTxn) || LastPrivateKey.Decrypt(SendingTxn)
BroadcastTxns([SendingTxn, InterManagerTxn, DeliveryTxn])
Else
Reject Txns
**********************************************************************

【0074】

【表1】

表１：疑似コードで使用される用語の解説