特表 2022-549951 スマートコントラクトアーキテクチャを有する分散台帳貸し付けシステム並びにその方法

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

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2022-11-29

(54)【発明の名称】スマートコントラクトアーキテクチャを有する分散台帳貸し付けシステム並びにその方法

(51)【国際特許分類】

   G06Q 40/02 20120101AFI20221121BHJP

【ＦＩ】

G06Q40/02 300

【審査請求】未請求

【予備審査請求】未請求

(21)【出願番号】P 2022519805

(86)(22)【出願日】2020-09-25

(85)【翻訳文提出日】2022-05-30

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

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

(87)【国際公開日】2021-04-01

(31)【優先権主張番号】62/906,211

(32)【優先日】2019-09-26

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

(81)【指定国・地域】

【公序良俗違反の表示】

（特許庁注：以下のものは登録商標）

１．ＪＡＶＡＳＣＲＩＰＴ

２．ＪＡＶＡ

３．ＡＮＤＲＯＩＤ

４．ＷＩＮＤＯＷＳ

５．ＳＷＩＦＴ

６．ＰＹＴＨＯＮ

７．ｉＯＳ

(71)【出願人】

【識別番号】522123452

【氏名又は名称】シリフカ，ルカシュ ヤクブ

(71)【出願人】

【識別番号】520380794

【氏名又は名称】ヤンティス， ジョナサン

(71)【出願人】

【識別番号】522123463

【氏名又は名称】クイグリー，ウィリアム エドワード

(74)【代理人】

【識別番号】110001999

【氏名又は名称】弁理士法人はなぶさ特許商標事務所

(72)【発明者】

【氏名】シリフカ，ルカシュ ヤクブ

(72)【発明者】

【氏名】ヤンティス，ジョナサン

(72)【発明者】

【氏名】クイグリー，ウィリアム エドワード

【テーマコード（参考）】

5L055

【Ｆターム（参考）】

5L055BB23

(57)【要約】

本開示の実施形態によれば、分散化されたローンプロセスが開示される。例示的な方法は、担保アイテムを示すローンプロセスを開始するための要求を受信することを含む。本方法はまた、担保アイテムに対応する担保トークンを生成することを含む。本方法は、ローンプロセスのワークフローに従ってローンプロセスを管理するように構成されるローンプロセスのスマートコントラクトインスタンスをインスタンス化することをさらに含み、ローンスマートコントラクトをインスタンス化するように構成されるローンプロセスのスマートコントラクトインスタンスは、貸し手及び借り手によって合意されたローンの1以上のローン期間パラメータを示すローン合意通知を受け取り、1以上のローン期間パラメータに基づくローンに返済するよう管理することを特徴とする。担保トークンは、ローンが完全に返済されるかデフォルト状態になるまで、分散台帳に格納されたエスクローアカウントにロックされる。

【特許請求の範囲】

【請求項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】

保管スマートコントラクトインスタンスは、保管リポートを受け取ることに応答して、保管アカウントからエスクローアカウントへの通貨トークンおよび／またはトークン化トークンの預託を開始し、通貨トークンおよび／またはトークン化トークンの金額は、担保アイテムの鑑定者によって決定された鑑定価値以下である、請求項５２に記載の方法。

【請求項54】

預託された金額の少なくとも一部は、ローンプロセスが完了するまでエスクロー口座にロックされる、請求項５３に記載の方法。

【請求項55】

保管スマートコントラクトインスタンスは、保管デバイスから保管リポートを受け取ることに応答して、保管通知をローンプロセスのスマートコントラクトに出力し、保管通知は、ローンプロセスのスマートコントラクトインスタンスに担保トークンの生成を開始させる、請求項４６に記載の方法。

【請求項56】

保管スマートコントラクトインスタンスは、保管リポートと保管リポートに少なくとも部分的に基づいて生成される暗号ハッシュ値を含むデータブロックとを生成すること、及びデータブロックを分散台帳に書き込むこと、を行うようにさらに構成される、請求項４６に記載の方法。

【請求項57】

保管のレーティングは、保管タスクに関連する結果に基づいて更新される、請求項４２に記載の方法。

【請求項58】

保管者デバイスは、担保アイテムの仮想表現を生成するために使用される担保アイテムの１つまたは複数の画像を提供する、請求項４２に記載の方法。

【請求項59】

担保トークンがエスクローアカウントからロック解除された後、保管スマートコントラクトインスタンスは、償還ワークフローを実行するように構成される、請求項４２に記載の方法。

【請求項60】

償還ワークフローは、担保トークンの償還者が保管者から担保アイテムを所有するという結果になる、請求項５９に記載の方法。

【請求項61】

ローンスマートコントラクトインスタンスは、ローンがデフォルト状態にあると判定することに応答して、清算プロセスを開始するように構成される、請求項１に記載の方法。

【請求項62】

担保トークンは、清算イベント中に担保トークンを購入する買い手に譲渡され、買い手は、担保アイテムを保管する保管者から担保アイテムを所有するために担保トークンを換金する、請求項６１に記載の方法。

【請求項63】

ローンスマートコントラクトインスタンスは、ローンが完全に返済されたと判定すると、エスクローアカウントから借り手のアカウントへの担保トークンの譲渡を開始するように構成される、請求項１に記載の方法。

【請求項64】

担保トークンは、担保トークンの現在の所有者を定義する所有権データを、所有権データが分散台帳上の借り手のアカウントのアドレスを含むように更新することによって、エスクローアカウントから借り手のアカウントに譲渡される、請求項６３に記載の方法。

【請求項65】

担保トークンは、担保アイテムの仮想表現を包む、請求項１に記載の方法。

【請求項66】

ローンスマートコントラクトは、ローン条件パラメータに定義されたローンのローン期間及びローン金額に基づいてローン返済スケジュールを決定するように構成され、支払スケジュールに従って予め定義された額の支払が行われない場合、ローンはデフォルトステージにあると見なされる、請求項１に記載の方法。

【請求項67】

ローンプロセスのワークフローは、認証者によって実行される認証タスクを定義する認証ステージ、鑑定者によって実行される鑑定タスクを定義する鑑定ステージ、および保管者によって実行される保管タスクを定義する保管ステージを含み、認証ステージ、鑑定ステージ、および保管ステージは、担保トークンが生成される前に実行される、請求項１に記載の方法。

【請求項68】

ローンインスタンスのスマートコントラクトインスタンスは、ローンプロセスの完了に応答して、認証者、鑑定者、および保管者に報酬を割り当てることを容易化する、請求項６３に記載の方法。

【請求項69】

担保アイテムが有形物である、請求項１に記載の方法。

【請求項70】

ローンの状態の変化は、ローンが完全に返済された状態になること、ローンがデフォルト状態になり担保アイテムが正常に清算されること、およびローン契約に定義されているように担保がもはや必要とされない返済の状態、のうちの少なくとも１つである、請求項１に記載の方法。

【発明の詳細な説明】

【技術分野】

【0001】

本出願は、２０１９年９月２６日に出願された米国特許仮出願第６２／９０６２１１号の優先権を主張する。この出願の開示全体は、参照により本明細書に組み込まれる。

【0002】

本開示は、スマートコントラクト及びブロックチェーン等の分散台帳を活用して、トラストレスまたは実質的にトラストレスの担保付きローンエコシステムを提供する分散ローンシステム及び方法に関する。

【背景技術】

【0003】

従来の電子商取引（ｅコマース）プロセスは、不必要な摩擦を伴う。これらのプロセスは、買い手が、欲しいもの、支払い方法、配送先、受取人、そしてできるだけ早く欲しいことを正確に把握した上で注文を行うような使用事例を中心に設計されている。従来の電子商取引では、このような購入の意思決定にあまり柔軟性がなかった。例えば、プレゼントを購入したいユーザは、通常、ウェブサイトやモバイルアプリケーションで購入し、受取人の住所を入力し（受取人が通常その住所で荷物を受け取るかどうかに関係なく）、代金を支払うことになる。その後、受取人が荷物を受け取ることができるかどうかに関係なく、プレゼントは直ちに受取人に送られる。したがって、当該技術分野では、購入の選択、支払い、所有権の譲渡、および配達の場所とタイミングを含むがこれらに限定されない取引のすべての側面について、より大きな柔軟性を有する電子商取引プラットフォームに対するニーズが存在する。

【0004】

一方、ビデオゲームなどでは、スキンや武器、道具などさまざまなアイテムを購入し、プレイヤー間で取引する仮想アイテムが人気を集めている。仮想アイテムは、他のデジタルアイテムと同様に、物理アイテム（物理的な物品）のような輸送、配送、保管の制約を受けることなく、所持、使用、譲渡することが可能である。しかし、仮想アイテムは、制作者が無制限にコピーを作成できるため、その価値は一過性のものであり、当初は希少価値の高いものであったものが、次第に価値が下がっていく可能性がある。そこで、仮想アイテム取引の柔軟性・利便性と、物理アイテム取引の信頼性・価値の双方を提供する方法・システムを備えたプラットフォームが求められている。

【0005】

ほとんどのローン（ローン）シナリオにおいて、借り手は貸し手からローンを受けることを希望する。一般的に、貸し手は、条件に同意する前にローンを確保するための担保を要求することがある。従来、借り手は、物理的な質屋に行くことができ、質屋のオーナー／代理店が物品の認証、物品の鑑定、物品の安全な保管、および資金の貸し付けに責任を持ち、その代わり、借り手は、物品を担保として提供することができる。この仕組みでは、貸し手と借り手が同時に不利な立場に立たされることになる。貸し手は、質屋のオーナー／代理店が担保アイテムに公正な鑑定額をつけ、誠実に保管してくれることを信用しなければならず、質屋は、担保アイテムが本物であること、借り手が貸し倒れになった場合に質屋が担保アイテムを清算できることを信用しなければならない。このようなジレンマにより、借り手は担保アイテムの評価額を大幅に下げられ、質屋はリスクを負うことになり、その結果、ローン額が下がり、金利やローンコストが高くなる。そのため、質屋は最後の貸し手とみなされ、借り手は、質屋を装った便乗高利貸しにしばしば利用されることになる。そのため、トラストレスまたは実質的にトラストレスのローンエコシステムを提供する分散ローンシステムが必要とされている。

【発明の概要】

【0006】

本明細書で提供されるのは、スマートコントラクトアーキテクチャで分散型ローンプロセスを促進するためのシステム及び方法である。実施形態において、分散型ローンプロセスは、担保アイテムが認証される認証ステージ、担保アイテムが鑑定される鑑定ステージ、及びそのアイテムが保管施設において物理的に確保される保管ステージを含む、一連のステージにおいて実行される。実施形態において、担保アイテムは「トークン化」され、これによって、担保アイテムは、保管状態に留まりながら、物理的な担保アイテムを表すデジタル担保トークンを使用して、その所有権を譲渡することが可能となる。実施形態において、一組のスマートコントラクトが、ローンプロセスの１つ以上のステージを含むローンプロセスを管理する。

【0007】

本開示のいくつかの実施形態に従って、以下の方法が開示される。本方法は、１つ以上の処理デバイスが、借り手デバイスからローンプロセスを開始する要求を受け取るステップを含み、この要求は、担保アイテムを示し、該担保アイテムは有形物である。本方法はまた、１つ以上の処理デバイスが、担保アイテムの仮想表現を生成するステップを含み、この仮想表現は、担保アイテムの説明及び担保アイテムの少なくとも一部をそれぞれ描写する１つ以上のメディアコンテンツのうちの少なくとも一方を含む。本方法は、さらに、１つ以上の処理デバイスが、担保アイテムの仮想表現に基づいて、担保アイテムに対応する担保トークンを生成するステップを含み、この担保トークンは、一組のノードデバイスにわたって分散される分散台帳上に格納されるデジタルトークンである。本方法は、さらに、１つ以上の処理デバイスが、ローンプロセスのワークフローに従ってローンプロセスを管理するように構成されているコンピュータ可読命令を含むローンプロセスのスマートコントラクトインスタンスをインスタンス化するステップを含み、ローンプロセスのスマートコントラクトインスタンスは、分散台帳を格納する一組のノードデバイスによって実行される。ローンプロセスのスマートコントラクトインスタンスは、貸し手と借り手とによって合意されたローンの１つ以上のローン条件パラメータを示すローン契約通知を受け取り、かつ１つ以上のローン条件パラメータに基づいてローンの返済を管理するように構成されたコンピュータ可読命令を含むローンのスマートコントラクトをインスタンス化するように構成される。担保トークンは、ローンのスマートコントラクトインスタンスが、ローンは完全に返済された、またはローンはデフォルト状態にあると判定するまで、分散台帳上に格納されるエスクローアカウントにロックされる。

【0008】

いくつかの実施形態において、ローンプロセスのスマートコントラクトインスタンスのコンピュータ可読命令は、さらに、担保アイテムを認証するために認証者によって実行される認証タスクを管理し、かつ鑑定タスクが完了したことを確認すると認証通知を発行するように構成されたコンピュータ可読命令を含む認証スマートコントラクトインスタンスをインスタンス化するように構成される。これらの実施形態のいくつかでは、ローンプロセスのスマートコントラクトインスタンスは、ローンプロセスのワークフローに従って、認証スマートコントラクトインスタンスをインスタンス化する。これらの実施形態のいくつかでは、ローンプロセスのワークフローは、分散台帳上に格納されるシステムレベルのガバナンス文書において定義され、システムレベルのガバナンスは、認証タスクを開始するための条件を定義する。いくつかの実施形態では、ローンプロセスのスマートコントラクトインスタンスは、借り手がローンプロセスを開始することを要求したことを示す要求通知を受け取ることに応答して、認証スマートコントラクトインスタンスをインスタンス化する。いくつかの実施形態では、ローンプロセスのスマートコントラクトインスタンスのコンピュータ可読命令は、さらに、認証者の認証デバイスから認証リポートを受け取り、認証リポートは、認証者が担保アイテムを真正とみなしたか否かを含む認証状態を示す、認証者の認証見解を含む、ように構成される。これらの実施形態のいくつかでは、認証リポートは、認証見解を支持するために認証者によって提供されるサポート文書をさらに含む。これらの実施形態のいくつかでは、認証リポートは、１つ以上のそれぞれの二次認証者によって発行された１つ以上の検証をさらに含み、各検証は、それぞれの二次認証者が認証見解を確認したことを示す。これらの実施形態のいくつかでは、認証リポートは、認証タスクの実行に関連する一連の規則および規制を定義する認証ステージレベルのガバナンスに従って定義されるフォームテンプレートから生成される。これらの実施形態のいくつかにおいて、認証ステージレベルのガバナンスは、認証タスクワークフローを定義し、認証タスクワークフローは、認証タスクを完了し、ローンプロセスが準拠するローンプロセスのワークフローにおける次のステージをトリガーするために満たされなければならない１つ以上の条件を含む。これらの実施形態のいくつかでは、認証ステージレベルのガバナンスは、認証者がギルドメンバーである認証ギルドによって少なくとも部分的に定義される。これらの実施形態のいくつかでは、認証ギルドは、複数の異なる専門の認証ギルドを含み、各専門の認証ギルドは、それぞれのタイプの担保アイテムの認証を専門に行う。これらの実施形態のいくつかにおいて、複数の異なる専門の認証ギルドは、時計の認証を専門とする時計認証ギルド、靴の認証を専門とする靴認証ギルド、ハンドバッグの認証を専門とするハンドバッグ認証ギルド、美術品の認証を専門とする美術品認証ギルド、スポーツ記念品の認証を専門とするスポーツ記念品認証ギルド、収集価値のあるおもちゃの認証を専門とするおもちゃ認証ギルド、宝飾品の認証を専門とする宝飾品認証ギルド、デザイナーズ衣料の認証を専門とする衣料品認証ギルド、楽器の認証を専門とする楽器認証ギルド、希少なまたは収集価値のあるレコードの鑑定を専門とするレコード鑑定ギルド、あるユニット（例えば、樽またはボトル）のワインの認証を専門とするワイン認証ギルド、ある単位（例えば、樽またはボトル）のウイスキーの認証を専門とするウイスキー認証ギルド、及び限定車の認証を専門とする自動車認証ギルド、を含むグループの少なくとも部分集合を含んでいる。これらの実施形態のいくつかでは、認証者は、異なる専門の認証ギルドのうちの専門の認証ギルドに所属する。これらの実施形態のいくつかでは、認証者は、認証者が属する専門の認証ギルドと担保アイテムのアイテムタイプとに基づいて、認証タスクを割り当てられる。いくつかの実施形態では、認証ステージレベルのガバナンスは、認証スマートコントラクトを定義し、その認証スマートコントラクトから認証スマートコントラクトインスタンスがインスタンス化される。いくつかの実施形態では、認証スマートコントラクトインスタンスは、認証者が担保アイテムを真正であるとみなしたことを示す認証リポートに応答して、認証者のアカウントからエスクローアカウントへの通貨トークン及び／又はトークン化されたトークンの預託（エスクロー）を開始する。いくつかの実施形態では、預託された金額の少なくとも一部は、ローンプロセスが完了するまでエスクローにロックされる。いくつかの実施形態では、認証スマートコントラクトインスタンスは、認証者デバイスから認証リポートを受信することに応答して、認証通知をローンプロセスのスマートコントラクトに出力し、認証通知は、ローンプロセススマートコントラクトインスタントに、ローンプロセスの鑑定ステージを開始させる。いくつかの実施形態では、認証スマートコントラクトインスタンスは、さらに、認証リポートと認証リポートに少なくとも部分的に基づいて生成される暗号ハッシュ値とを含むデータブロックを生成し、データブロックを分散台帳に書き込む、ように構成される。いくつかの実施形態では、認証者のレーティング（格付け又は評価）は、認証タスクに関連する結果に基づいて更新される。

【0009】

いくつかの実施形態において、ローンプロセスのスマートコントラクトインスタンスのコンピュータ可読命令は、担保アイテムの鑑定価値を決定するために鑑定者によって実行される鑑定タスクを管理し、鑑定タスクが完了したことを確認して鑑定通知を発行するように構成されるコンピュータ可読命令を含む鑑定スマートコントラクトインスタンスをインスタンス化するようにさらに構成されている。これらの実施形態のいくつかでは、ローンプロセスのスマートコントラクトは、ローンプロセスのワークフローに従って、鑑定スマートコントラクトインスタンスをインスタンス化する。これらの実施形態のいくつかでは、ローンプロセスのワークフローは、分散台帳上に格納されるシステムレベルのガバナンス文書において定義され、システムレベルガバナンスは、鑑定タスクを開始するための条件を定義する。いくつかの実施形態では、ローンプロセスのスマートコントラクトは、認証者が担保アイテムを認証し、担保アイテムを真正であると見なしたことを示す認証通知を受け取ることに応答して、鑑定スマートコントラクトインスタンスをインスタンス化する。いくつかの実施形態では、ローンプロセスのスマートコントラクトインスタンスのコンピュータ可読命令は、鑑定者の鑑定デバイスから鑑定リポートを受け取るようにさらに構成され、鑑定リポートは、担保アイテムの鑑定価値及び担保アイテムの清算価値の少なくとも一方を含む担保アイテムの評価を含む。これらの実施形態のいくつかでは、鑑定リポートは、担保アイテムの物理的状態、担保アイテムの新品または中古の状態、担保アイテムの動作状態、類似アイテムの以前の販売価格、および類似アイテムのブルーブックの評価のうちの１つ以上をさらに含む。いくつかの実施形態では、鑑定リポートは、１人以上のそれぞれの二次鑑定者によって発行された１つ以上の検証をさらに含み、各検証は、それぞれの二次鑑定者が鑑定価値を確認したことを示す。いくつかの実施形態では、鑑定リポートは、鑑定タスクの実行に関連する一連の規則及び規制を定義する鑑定ステージレベルのガバナンスに従って定義されるフォームテンプレートから生成される。いくつかの実施形態では、鑑定ステージレベルのガバナンスは、鑑定タスクワークフローを定義し、鑑定タスクワークフローは、鑑定タスクを完了し、ローンプロセスのワークフローにおける次のステージをトリガーするために満たされなければならない１つ以上の条件を含む。これらの実施形態のいくつかでは、鑑定ステージ-レベルのガバナンスは、鑑定者がギルドメンバーである鑑定ギルドによって少なくとも部分的に定義される。これらの実施形態のいくつかでは、鑑定ギルドは、複数の異なる専門の鑑定ギルドを含み、各専門の鑑定ギルドは、それぞれのタイプの担保アイテムの鑑定に特化している。いくつかの実施形態では、複数の異なる専門の鑑定ギルドは、時計の鑑定を専門とする時計鑑定ギルド、靴の鑑定を専門とする靴鑑定ギルド、ハンドバッグの鑑定を専門とするハンドバッグ鑑定ギルド、美術品の鑑定を専門とする美術品鑑定ギルド、スポーツ記念品の鑑定を専門とするスポーツ記念品鑑定ギルド、収集価値のあるおもちゃの鑑定を専門にするおもちゃ鑑定ギルド、宝飾品の鑑定を専門とする宝飾品鑑定ギルド、デザイナーズ衣料の鑑定を専門とする衣料品鑑定ギルド、楽器の鑑定を専門とする楽器鑑定ギルド、希少なまたは収集価値のあるレコードの鑑定を専門とするレコード鑑定ギルド、ある単位（例えば、樽またはボトル）のワインの鑑定を専門とするワイン鑑定ギルド、ある単位（例えば、樽またはボトル）のウイスキーの鑑定を専門とするウイスキー鑑定ギルド、および限定車の鑑定を専門とする自動車鑑定ギルドを含むグループの少なくとも部分集合を含む。これらの実施形態のいくつかでは、鑑定者は、異なる専門の鑑定ギルドの１つの専門の鑑定ギルドに属している。いくつかの実施形態では、鑑定者は、鑑定者が属する専門の鑑定ギルドと担保アイテムのアイテムタイプとに基づいて、鑑定タスクを割り当てられる。いくつかの実施形態では、鑑定ステージレベルのガバナンスは、鑑定スマートコントラクトを定義し、その鑑定スマートコントラクトから鑑定スマートコントラクトインスタンスがインスタンス化される。いくつかの実施形態では、鑑定スマートコントラクトインスタンスは、鑑定リポートを受け取ることに応答して、鑑定者のアカウントからエスクローアカウントへの通貨トークンおよび／またはトークン化トークンの預託を開始し、通貨トークンおよび／またはトークン化トークンの金額は鑑定価値以下である。いくつかの実施形態では、預託された金額の少なくとも一部は、ローンプロセスが完了するまで、エスクローアカウントにロックされる。いくつかの実施形態では、鑑定スマートコントラクトインスタンスは、鑑定者デバイスから鑑定リポートを受け取ることに応答して、ローンプロセスのスマートコントラクトに鑑定通知を出力し、鑑定通知は、ローンプロセスのスマートコントラクトインスタンスに、ローンプロセスの保管ステージを開始させる。いくつかの実施形態では、鑑定スマートコントラクトインスタンスは、鑑定リポートと鑑定リポートに少なくとも部分的に基づいて生成される暗号ハッシュ値とを含むデータブロックを生成し、データブロックを分散台帳に書き込むようにさらに構成される。いくつかの実施形態では、鑑定者のレーティングは、鑑定タスクに関連付けられた結果に基づいて更新される。

【0010】

いくつかの実施形態において、ローンプロセスのスマートコントラクトインスタンスのコンピュータ可読命令は、ローンプロセスの少なくとも一部の間に担保アイテムを安全に保管するために保管者によって実行される保管タスクを管理し、保管タスクが完了したことを確認すると保管通知を発行するように構成されているコンピュータ可読命令を含む保管スマートコントラクトインスタンスをインスタンス化するようにさらに構成されている。いくつかの実施形態では、ローンプロセスのスマートコントラクトは、ローンプロセスのワークフローに従って、保管スマートコントラクトインスタンスをインスタンス化する。これらの実施形態のいくつかでは、ローンプロセスのワークフローは、分散台帳上に格納されるシステムレベルのガバナンス文書において定義され、システムレベルのガバナンスは、保管タスクを開始するための条件を定義する。いくつかの実施形態では、ローンプロセスのスマートコントラクトインスタンスは、鑑定者が担保アイテムを鑑定したことを示す鑑定通知を受け取ることに応答して、保管スマートコントラクトインスタンスをインスタンス化する。いくつかの実施形態では、ローンプロセスのスマートコントラクトインスタンスのコンピュータ読み取り可能な命令は、保管者の保管者デバイスから保管者リポートを受信し、保管者リポートは、担保アイテムが保管者に関連付けられた施設に保管されているという検証を含み、担保アイテムが受け取られたときに保管者によって観察された任意の可視損傷の表示を含む、ようにさらに構成される。いくつかの実施形態では、保管リポートは、保管タスクの完了の証明として、保管によって提供されるサポート文書をさらに含む。いくつかの実施形態では、保管リポートは、担保アイテムが保管者によって受け取られたときに保管者によって観察された可視損傷の写真文書をさらに含む。いくつかの実施形態において、保管リポートは、保管タスクの実行に関連する一連の規則及び規制を定義する保管ステージレベルのガバナンスに従って定義される保管フォームテンプレートから生成され、場合によっては、保管リポートは、保管タスクの実行に関連する規則及び規制を定義する。いくつかの実施形態において、保管ステージレベルのガバナンスは、保管タスクワークフローを定義し、保管タスクワークフローは、保管タスクを完了し、ローンプロセスのワークフローにおける次のステージをトリガーするために満たされなければならない１つまたは複数の条件を含む保管タスクワークフローを定義する。いくつかの実施形態では、保管ステージレベルのガバナンスは、保管者がギルドメンバーである保管者ギルドによって少なくとも部分的に定義される。いくつかの実施形態では、保管ステージレベルのガバナンスは、保管スマートコントラクトを定義し、その保管スマートコントラクトから保管スマートコントラクトインスタンスがインスタンス化される。いくつかの実施形態では、保管スマートコントラクトインスタンスは、保管リポートを受け取ることに応答して、保管アカウントからエスクローアカウントへの通貨トークンおよび／またはトークン化トークンの預託を開始し、通貨トークンおよび／またはトークン化トークンの金額は、担保アイテムの鑑定者によって決定される鑑定価値以下である。いくつかの実施形態では、預託された金額の少なくとも一部は、ローンプロセスが完了するまで、エスクローアカウントにロックされる。いくつかの実施形態では、保管スマートコントラクトインスタンスは、保管者デバイスから保管者リポートを受け取ることに応答して、ローンプロセスのスマートコントラクトに保管者通知を出力し、保管者通知は、ローンプロセスのスマートコントラクトインスタンスに担保トークンの生成を開始させる。いくつかの実施形態では、保管スマートコントラクトインスタンスは、保管リポートと保管リポートに少なくとも部分的に基づいて生成される暗号ハッシュ値とを含むデータブロックを生成し、データブロックを分散台帳に書き込むようにさらに構成される。いくつかの実施形態において、保管者のレーティングは、保管者タスクに関連する結果に基づいて更新される。いくつかの実施形態において、保管者デバイスは、担保アイテムの仮想表現を生成するために使用される担保アイテムの１つ又は複数の画像を提供する。いくつかの実施形態では、保管スマートコントラクトインスタンスは、担保トークンがエスクローアカウントからロック解除された後、償還ワークフローを実行するように構成される。これらの実施形態のいくつかにおいて、償還ワークフローは、担保トークンの償還者が、保管者から担保アイテムを所有するという結果になる。

【0011】

いくつかの実施形態において、本方法は、ローンスマートコントラクトインスタンスが、ローンがデフォルト状態にあると判定することに応答して、清算プロセスを開始するように構成されることをさらに含む。いくつかの実施形態では、担保トークンは、清算イベント中に担保トークンを購入する買い手に譲渡され、買い手は、担保アイテムを保管する保管者から担保アイテムを所有するために担保トークンを換金する。

【0012】

いくつかの実施形態において、ローンスマートコントラクトインスタンスは、ローンが完全に返済されたと判定すると、エスクローアカウントから借り手のアカウントへの担保トークンの譲渡を開始するように構成される。これらの実施形態のいくつかでは、担保トークンは、担保トークンの現在の所有者を定義する所有権データを、所有権データが分散台帳上の借り手のアカウントのアドレスを含むように更新することによって、エスクローアカウントから借り手のアカウントに譲渡される。

【0013】

いくつかの実施形態において、ローン条件パラメータは、ローン期間及びローン金額を含む。いくつかの実施形態では、ローンスマートコントラクトは、ローン期間及びローン金額に基づいてローン返済スケジュールを決定するように構成され、支払いスケジュールに従って予め定義された額の支払いが行われない場合、ローンはデフォルトステージにあると見なされる。

【0014】

いくつかの実施形態において、認証者によって実行される認証タスクを定義する認証ステージ、鑑定者によって実行される鑑定タスクを定義する鑑定ステージ、及び保管者によって実行される保管タスクを定義する保管ステージを含むローンプロセスのワークフローは、担保トークンを生成する前に実行される。いくつかの実施形態では、認証ステージ、鑑定ステージ、および保管ステージは、担保トークンが生成される前に実行される。いくつかの実施形態において、ローンインスタンスのスマートコントラクトインスタンスは、ローンプロセスの完了に応答して、認証者、鑑定者、及び保管者に報酬を割り当てることを容易化する。

【0015】

いくつかの実施形態において、担保トークンのロック解除をトリガーするローンの状態の変化は、ローンが完全に返済された状態になること、ローンがデフォルト（貸し倒れ）状態になり担保アイテムが正常に清算されること、およびローン契約に定義されているように担保がもはや必要とされない返済の状態、のうちの少なくとも１つである。

【0016】

いくつかの実施形態では、担保トークンは、担保アイテムの仮想表現を包む。

【0017】

いくつかの実施形態において、ローンスマートコントラクトは、ローン条件パラメータに定義されたローンのローン期間及びローン金額に基づいてローン返済スケジュールを決定するように構成され、支払いスケジュールに従って予め定義された額の支払いが行われない場合、ローンはデフォルトステージにあると見なされる。

【0018】

いくつかの実施形態において、ローンプロセスのワークフローは、認証者によって実行される認証タスクを定義する認証ステージと、鑑定者によって実行される鑑定タスクを定義する鑑定ステージと、保管者によって実行される保管タスクを定義する保管ステージとを含み、認証ステージ、鑑定ステージ、および保管ステージは、担保トークンが生成される前に実行される。これらの実施形態のいくつかにおいて、ローンインスタンススマートコントラクトインスタンスは、ローンプロセスの完了に応答して、認証者、鑑定者、および保管者に報酬を割り当てることを容易化する。

【0019】

いくつかの実施形態において、担保アイテムは、有形物である。いくつかの実施形態において、ローンの状態の変化は、ローンが完全に返済された状態になること、ローンがデフォルト状態になり担保アイテムが正常に清算されること、およびローン契約に定義されているように担保がもはや要求されない返済の状態、のうちの少なくとも１つである。

【0020】

いくつかの実施形態において、分散台帳は、ブロックチェーンである。

【0021】

本開示のより完全な理解は、以下の説明および添付図面、ならびに請求項から得られるであろう。

【0022】

本開示のより良い理解を提供するために含まれた添付図面は、本開示の１つまたは複数の実施形態を示し、説明と共に本開示の原理を説明するのに役立つものである。

【図面の簡単な説明】

【0023】

【図1】図１は、本開示のいくつかの実施形態に従う例示的なトークン化プラットフォーム環境を示す概略図である。

【0024】

【図2】図２は、本開示のいくつかの実施形態に従う例示的な市場システムを示す概略図である。

【0025】

【図3】図３は、本開示のいくつかの実施形態に従う例示的な台帳管理システムを示す概略図である。

【0026】

【図4】図４は、本開示のいくつかの実施形態に従う例示的な取引システムを例示する概略図である。

【0027】

【図5】図５は、本開示のいくつかの実施形態に従う例示的なインテリジェンス及びオートメーションシステムを示す概略図である。

【0028】

【図6】図６は、本開示のいくつかの実施形態に従う例示的なアナリティクス及びリポートシステムを示す概略図である。

【0029】

【図7】図７は、本開示のいくつかの実施形態に従う、ウォレット内のトークンを表示するユーザインタフェースである。

【0030】

【図8】図８は、本開示のいくつかの実施形態に従うトークン化プラットフォームの構成要素の組の一例を示す概略図である。

【0031】

【図9】図９は、本開示のいくつかの実施形態に従う、アイテムをトークン化するための方法を示すフローチャートである。

【0032】

【図10】図１０は、本開示のいくつかの実施形態に従う。デジタル市場を使用してトークンを譲渡するための方法を示すフローチャートである。

【0033】

【図11】図１１は、本開示のいくつかの実施形態に従う、キーボード相互作用を介してウォレット間でトークンを譲渡するための方法を示すフローチャートである。

【0034】

【図12】図１２は、本開示のいくつかの実施形態に従う、トークンを換金するための方法を示すフローチャートである。

【0035】

【図13】図１３は、本開示のいくつかの実施形態に従う、担保化及び／又は証券化のための方法を示すフローチャートである。

【0036】

【図14】図１４は、本開示のいくつかの実施形態に従う、アイテム認証のための方法を示すフローチャートである。

【0037】

【図15】図１５は、本開示のいくつかの実施形態に従う、ＶＲ環境をレンダリングするための方法を示すフローチャートである。

【0038】

【図16】図１６は、本開示のいくつかの実施形態に従う、ブロックのサイドチェーンを有する分散台帳を使用して取引を促進するための方法を示すフローチャートである。

【0039】

【図17】図１７は、本開示のいくつかの実施形態に従う、ユーザ獲得を容易にするための方法を示すフローチャートである。

【0040】

【図18】図１８は、本開示のいくつかの実施形態に従う、ミステリボックスを管理するための方法を示すフローチャートである。

【0041】

【図19】図１９は、本開示のいくつかの実施形態に従う、ビデオゲーム統合のための方法を示すフローチャートである。

【0042】

【図20】図２０は、本開示のいくつかの実施形態に従う例示的な分散型貸し付けシステムのエコシステムを示す概略図である。

【0043】

【図21】図２１は、本開示のいくつかの実施形態に従う、分散型ローンプロセスの様々なステージを運営するギルド、サブギルド、及び様々なタイプのガバナンスの一例を示す概略図である。

【0044】

【図22】図２２は、本開示のいくつかの実施形態に従う、認証ワークフローを実行するための方法の一連の動作の一例を示すフローチャートである。

【0045】

【図23】図２３は、本開示のいくつかの実施形態に従う、鑑定ワークフローを実行するための方法の一連の動作の一例を示すフローチャートである。

【0046】

【図24】図２４は、本開示のいくつかの実施形態に従う、保管ワークフローを実行するための方法の一連の動作の一例を示すフローチャートである。

【0047】

【図25】図２５は、本開示のいくつかの実施形態に従う、ローンワークフローを実行するための方法の一連の動作の一例を示すフローチャートである。

【0048】

【図26】図２６は、本開示のいくつかの実施形態に従う、ローン前清算ワークフローを実行するための方法の一連の動作の一例を示すフローチャートである。

【0049】

【図27】図２７は、本開示のいくつかの実施形態に従う、ローンプロセスのワークフローの一連のステージを示す図である。

【0050】

【図28】図２８は、本開示のいくつかの実施形態に従う、ローンプロセスのワークフローの一連のステージを示す図である。

【0051】

【図29】図２９は、本開示のいくつかの実施形態に従う、ローンプロセスのワークフローの一連のステージを示す図である。

【0052】

【図30】図３０は、本開示のいくつかの実施形態に従う、ローンプロセスのワークフローの一連のステージを示す図である。

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

【0053】

取引の自動化に対する法的制約を維持し尊重しながら、そのような取引の多くを自動化する方法で様々な取引を実施するシステム及び方法における使用のために、ブロックチェーン技術とスマートコントラクトの組み合わせが提案されてきた。このようなシステムの自動化に関する制約の１つは、（i）当事者間で法的拘束力のある契約を作成すること、及び（ii）所有権、担保権、又は他の同様の利益を法的拘束力のある方法で譲渡（移転）する方法で財産を交換するための、管轄区域（jurisdiction）固有の規則及びプロセスの存在である。

【0054】

提案されたシステムのいくつかは、不動産記録、米国統一商事法典のファイリングシステム、及び他の同様のシステムを含む、このような譲渡の記録に関する法的システムに対するブロックチェーン技術の将来の実装に依存する。この移行は、政府機関がブロックチェーンベースの記録管理システムを作成し、採用することに依存する。例えば、米国の不動産記録は、通常、公選された役職者によって郡（county）レベルで管理され、文書は、記録に対する提出の形式と方法に関する特定の規則の対象となる。このような役職者は、それぞれ独自のシステムを利用して書類を受理し、記録している。そのため、ブロックチェーンベースの記録管理システムを採用する場合、各管轄区域がそのようなシステムを選択し、導入する必要がある。このプロセスは、そのようなシステムの技術が開発され、導入が可能になったとしても、何年もかかる可能性がある。また、管轄区域によって新しい技術の採用に対する意欲も大きく異なる可能性があるため、すべての管轄区域がブロックチェーンベースのシステムに移行するとしても、その時期を決定することは不可能である。

【0055】

ブロックチェーン技術の便益は、政府の記録担当者がその技術に基づくシステムの実装を開始することを決定するまで待つべきものではないため、ギャップを埋めるのためにブロックチェーン技術の便益を提供しながら、既存の記録保持および他の法的システムと連絡も有するハイブリッドシステムが必要である。本明細書に開示されたシステムは、システムのユーザにブロックチェーンの便益を提供し、既存の法的システムおよび方法と連絡し、そして、完全なブロックチェーンに基づくシステムが利用可能になれば、そのへの移行をより容易にするものである。

【0056】

本明細書に記載される分散台帳取引システム及び方法は、分散台帳技術（例えば、ブロックチェーン技術）をスマートコントラクトと組み合わせて利用し、ユーザが様々な異なる取引を交渉し、文書化し、及び／又は実行することを可能にする。いくつかの実施形態によれば、異なる取引は、証券化された分散型ローン取引を含む。これらのローン取引は、従来のタイプの担保によって、及び／又はデジタル資産によって担保される、ローン取引を含む。

【0057】

一般に、分散台帳技術は、適用及び採用が急速に拡大している暗号通貨の基礎を形成する。そのような暗号通貨は、現金などの既存の支払方法を補強または代替するが、暗号通貨の譲渡を処理するための分散型システムも提供する。分散台帳／ブロックチェーン技術の基礎となるのは、データブロックのリンクリストである。各ブロックは、チェーン内の先行ブロックへのリンクと暗号化されたデータを含んでいる。分散台帳のいくつかの実装では、暗号化されたデータは、デジタル通貨の交換を文書化した取引データ、実行可能なデジタル契約などのソフトウェア、および特定の当事者によるデジタル契約の使用に関連するデータを含むことができるが、以下でさらに詳細に説明するように、他の種類のデータも含むことができる。分散台帳の各ブロックのデータは、分散台帳の以前のブロックを変更する企てを特定しかつ防止する手段として、チェーン内の以前のブロックのハッシュを含んでいる。

【0058】

分散台帳技術の多くの実装では、分散台帳の管理と拡張は、システムに計算能力を提供する多数の独立したエンティティによって運用されるコンピュータシステム上に分散化及び非集中化されている。これらの分散化された貢献者は、分散台帳のコピーを保存し、取引を処理するのに必要なアルゴリズムを実行し、それを分散台帳上の新しいブロックに展開し、それらのブロックをシステムの他の部分に配布することによって、分散台帳システムのインフラを提供する。分散台帳の実装によっては、貢献者は、このサービスに対して、分散台帳の新しいブロックを処理する見返りとして暗号通貨建ての手数料を受け取ることで報酬を得ている場合もある。分散台帳のセキュリティの重要な点は、分散台帳に追加されメインブランチに受け入れられた後のブロックを修正することが困難であることであるが、分散台帳には一時的に競合するブランチが存在する。

【0059】

分散台帳技術は、「スマートコントラクト」という概念によって強化されてきた。スマートコントラクトは、スマートコントラクトの開発者によって分散台帳のブロック内のデータにコンパイルされる実行可能なコンピュータプログラムである。スマートコントラクトが分散台帳に展開（配備、デプロイ）されると、分散台帳の他の利用者は、悪意のある第三者によって改ざんされていないことを確信しながら、スマートコントラクトを実行することができるようになる。このような実行可能なコンピュータプログラムは、デジタル通貨やその他の種類の資産の譲渡に関する様々な当事者間の合意を表し、実行するために用いられることがあるため、「スマートコントラクト」と呼ばれているが、契約上の取り決めを表すものである必要はない。ソフトウェア開発者は、JavaScript、Solidity などのスクリプト言語、Javaなどのオブジェクトコーディング言語、CやC++などのマシンコーディング言語などを用いてプログラムコードを記述し、スマートコントラクトを開発する。スマートコントラクトが分散台帳に展開されると、プログラムコードは分散台帳上の他の取引と同様に、システムの貢献者の一人によってブロックに加工され、通常、契約／プログラムをコンパイルしたノードの貢献者に手数料が支払われる。スマートコントラクトを展開するプロセスは、プログラムコードをバイトコード、オブジェクトコード、バイナリコード、または他の何らかの実行可能な形態にコンパイルすることを含んでもよい。
スマートコントラクトがブロックチェーンに正常にデプロイされると、他の分散台帳取引と同様にアドレスが割り当てられる。このアドレスは、スマートコントラクトにアクセスし、その中で提供される機能を実行するために使用される。通常、アプリケーションプログラミングインターフェースに似たアプリケーションバイナリインターフェース（ABI）情報が、コントラクトのユーザ、またはコントラクトとインターフェースするソフトウェア（ウォレットアプリケーションなど）に提供され、ユーザはスマートコントラクトのさまざまな機能と対話できるようになる。ABIは、スマートコントラクトの一部として提供される様々な機能およびメソッドを記述し、ユーザまたはユーザのソフトウェアがアクセスできるようにするものである。

【0060】

分散台帳に展開されたコントラクト／プログラムは、その後、分散台帳上でコントラクトのアドレスを持つ誰もが利用することができる。コントラクトやその一部を実行しても、そのステップの一部として分散台帳の更新が必要でない限り、必ずしも手数料が発生することはない。コントラクト／プログラムが適切に実装されていれば、多くの異なるユーザが同時にコントラクト／プログラムを利用し、それぞれの特定の契約や取引を管理することができる。

【0061】

実施形態において、スマートコントラクト／プログラムは、契約の異なる当事者によって実行または完了される複数のステップを有することができる。例えば、コントラクト／プログラムは、第１の当事者によって呼び出され、特定のコントラクトのコピーをインスタンス化することによって、第２の当事者または潜在的な契約当事者のグループに対してオファーを行うことができる。第２の当事者（または、グループの１つ）は、コントラクトのそのインスタンスに「署名」することによって応答することができる。コントラクトに「署名」するプロセスは、コントラクトの一部として定義されたプログラムメソッドを呼び出すことからなる場合がある。いくつかのコントラクトは、買い手、販売者、貸し手、借り手、エスクロー代理人、認証者、鑑定者、及び／又は同様のものなどの複数の当事者を提供してもよく、これらの者のすべてが、独立してスマートコントラクトの特定のインスタンスと対話し、それに署名し、又はスマートコントラクトの特定のタイプに関連する他のアクションを行うことができる。

【0062】

スマートコントラクトは、デジタル資産を含む契約、または契約当事者、分散台帳、デジタル資産、およびインターネット上のリソース、またはその他の方法でデジタル接続されたリソース間のプログラム的相互作用を介して完全に実行され得る契約によく適合している。例えば、スマートコントラクトは、デジタル資産の制御と所有権を自動的に譲渡したり、ACHまたは他の電子決済システムを介してPayPalまたは銀行アカウント間で金銭を譲渡したりすることができる場合がある。外部システムによって提供されるアプリケーションプログラミングインターフェースは、デジタルコントラクトが、非プログラム的なプロセスなしに当事者間で資産または資金の実際の譲渡を実行するための方法を提供する。

【0063】

スマートコントラクトによって、不動産、動産、及び政府又は民間の登録システムの管理下にある他のタイプの資産などの有形資産を含む契約を完全に実施することは、それほど容易ではない。これらの登録システムは、紙ベースであることが多く、また、電子化されている場合でも、第三者によるプログラム的な相互作用のために設計されているわけではない。このようなシステムの例としては、不動産の所有権記録、所有権付き資産の動産記録、統一商事法典の記録、特許および商標登録データベースなどが挙げらる。これらのシステムの多くは、部分的にデジタル化されている場合があるが、スマートコントラクトが完全に自動化された方法でシステムと相互作用するためのプログラム的なインターフェースが欠けているか、本質的に独自性が高いものである。他のシステムは、独自の個別のファイリングシステムを有する多くの管轄区域に分断されている可能性があり、単一のスマートコントラクトがすべての関連システムにわたって機能することはないであろう。例えば、統一商事法典のファイリングは、通常、異なる州の管轄区域にまたがる異なるシステムによって処理されるため、スマートコントラクトは、単一の管轄区域外の取引を処理できるように、またそのようなインターフェースが所定の管轄区域で利用できるかどうかに応じて、様々なインターフェースを実装する必要があるであろう。

【0064】

スマートコントラクト／プログラムのプログラム的機能を介して完全に実行することができなかった契約の１つのタイプは、担保付きローン取引である。そのような取引の多くの部分は、当事者とスマートコントラクトとの間の相互作用を介して完了することができるが、取引の他の側面のうち、所有権および所有権の譲渡、ならびに貸し手の利益のための担保権の設定は、スマートコントラクトを介して完了することに容易に適応されない。本開示の実施形態によれば、１つ以上のタイプのスマートコントラクトをサポートするために、１組の分散台帳及び促進する１組のスマートコントラクトを組み込んだ分散型貸付システムが作成される。システムの様々な実施形態において、分散台帳のセットは、ギルドガバナンススマートコントラクト、認証者スマートコントラクト、鑑定スマートコントラクト、ローンスマートコントラクト、及び／又は他のスマートコントラクトが証券化された分散型ローンプロセスをサポートするように実装されるなど、様々なタイプのスマートコントラクトをホストしうる。プログラム型スマートコントラクトは、分散台帳にコンパイルされ、分散台帳のそれぞれのブロック内の特定のアドレスに存在する。ユーザは、アドレスとスマートコントラクトに関連するメソッドまたは関数を呼び出すことによって、これらのスマートコントラクトを利用することができる。例えば、例示的なローン契約は、ローン要求、ローン承認、担保割り当て、支払い承認、及び／又はローンの形成及び実行、担保の提供、並びにその条件に従ってローンの返済に必要な他の同様の機能のためのメソッドを有していてもよい。

【0065】

ローン契約の例を続けると、ユーザがスマートコントラクトを利用し、そのコントラクトのメソッドまたは関数を呼び出すとき、ユーザは、特定のメソッドまたは関数によって指定されるパラメータおよび他の情報をスマートコントラクトに提出し得る。スマートコントラクトは、それらのパラメータに従って、選択されたメソッドまたは関数をプログラム的に実行することができる。ローンリクエスト（要求）機能の場合、ローンスマートコントラクトは、ローンを組むことを望むユーザから受け取ったパラメータを受け取り、そのリクエスト情報をブロックチェーン内の新しいブロックに組み込んで、潜在的な貸し手がそのリクエストを見ることができるようにしてもよい。いくつかの実施形態では、ローンリクエストは分散台帳に組み込まれなず、ウェブサービス経由など、潜在的な貸し手がプログラム的に利用できるデータベースに格納される場合がある。

【0066】

本開示は、物品、サービス、および／または体験などのアイテムの仮想表現（「VIRL」とも呼ばれる）の作成を可能にするトークン化プラットフォームに関するものである。本明細書で使用される場合、用語「アイテム」は、デジタル資産（例えば、ギフトカード、デジタル音楽ファイル、デジタルビデオファイル、ソフトウェア、デジタル写真など）、物理的商品、デジタルサービス（例えば、ビデオストリーミング配信）、物理サービス（例えば、運転手サービス、メイドサービス、クリーニングサービス）、および／または購入した体験（例えば、ホテルパッケージ、コンサートチケット、航空券など）、またはそれらの任意の組み合わせを指すことができる。アイテムは、既に存在する商品、または後の時点で生産することができる商品を指す場合があることに留意されたい。例えば、アイテムは、未加工のピザまたは１点の衣類であってもよい。このようなアイテムの買い手は、アイテムを購入することができ、アイテムは、購入後の時点で生産され得る。仮想アイテムという用語は、商品化されたアイテムを仮想的に表現したものを指す場合がある。商品に対する仮想表現を作成する場合、従来の電子商取引に必要な購入時の決定の多くを延期し、取引自体から分岐させることができ、それによって買い手にとっての付加価値を創出することができる。例えば、買い手は靴を注文したいが、その靴がいつ必要になるのか、配送先はどこがいいのか、まだわからないとする。買い手は、靴の仮想表現を購入することができる。この仮想表現は、後日、償還者（買い手や贈答品の受取人など）が希望するときに、配達時間や配達場所を指定できるようにすることができる。このように、仮想アイテムを作ることで、買い手や贈答品に新たな価値を与え、交換時期まで保留することができる。

【0067】

さらに、従来の電子商取引プラットフォームでは、未知の当事者間で譲渡される物品を確認し、信頼できる記録メカニズムはない。さらに、中央集権的なエンティティなしで機密性の高い財務情報を保存する方法も存在しない。したがって、いくつかの実施形態において、トークン化プラットフォームは、暗号的に安全な台帳に格納されるように構成される電子トークン（または「トークン」）を発行するように構成され、仮想表現が未知の当事者間のアイテムの譲渡を可能にし、同時に、誰もがいつでもトークンの状態を確認して、それが正しいことを信頼できるプロセスを提供することができる。本明細書で使用される場合、文脈によって特に示されない限り、「暗号的に」は、ハッシュアルゴリズムのような暗号アルゴリズムの使用を示す。

【0068】

電子商取引プラットフォームは、追加の又は代替のエコシステムをサポートするように構成されてもよい。実施形態では、トークン化プラットフォームは、トークンベースの貸し付けシステムをサポートするように構成され、それによって、貸し手は、担保（例えば、宝飾品、収集品、美術品など）に対応する仮想アイテムを作成することができる。電子商取引プラットフォームは、仮想アイテムをトークン化してもよく、トークンを分散台帳に保存してもよい。このようにして、ローンが販売され、トークンだけが貸し手間で譲渡される必要がある、ようにすることもできる。いくつかの実施形態において、スマートコントラクトは、ローン、トークンの所有、及びローンに対応する他の取引を管理するために使用されてもよい。

【0069】

いくつかの実施形態では、トークン化プラットフォームは、実世界のアイテムを認証するように構成される。これらの実施形態のいくつかでは、トークン化プラットフォームは、アイテムの仮想表現を使用してアイテムを認証するために対象分野の専門家を参加させることができる。対象分野の専門家は、基礎となる専門家の見解の注記を含む認証リポートを提供してもよい。認証リポートは、アイテムがプラットフォーム上で担保に使用されること又は販売されることを拒否又は許可するために使用されてもよい。さらに、いくつかの実施形態では、認証リポートは、プラットフォームがアイテムを認証するためにマシンビジョン、機械学習、センサ（例えば、スケール）、及び／又は他の適切な技術を使用し得るように、機械学習モデルを訓練するために使用されるものであってもよい。

【0070】

実施形態では、トークン化プラットフォームは、「ミステリボックス」ゲームをサポートするように構成される。ミステリボックスゲームは、ユーザがミステリボックスからトークンを獲得することができ、トークンがアイテムを表し、トークンが償還、取引、販売、贈与などされ得るような、変化のあるゲームである。これらの実施形態のいくつかでは、トークン化プラットフォームは、カジノスタイルのゲームをサポートし、それによって、ミステリボックスゲームは、カジノ及び他の実在の店舗でプレイされ得る。

【0071】

実施形態では、トークン化プラットフォームは、ビデオゲーム内ストリーミングをサポートするように構成される。これらの実施形態のいくつかでは、トークン化プラットフォームは、ビデオゲームのインスタンスにトークンのインジケータを提供してもよく、それによって、ビデオゲームメーカーは、多くの異なる方法でトークンを使用することができる。例えば、トークンは、フードデリバリーサービスがゲーム内で配達可能な食品を販売することを可能にするために、ビデオゲームに現れてもよい。別の例では、トークンは、ゲーム内で使用することができるが、その後、デジタルアイテムに対応する現実世界のアイテムを得るために償還することができるデジタルアイテムを表すものであってもよい。

【0072】

実施形態では、トークン化プラットフォームは、報酬ベースのユーザ獲得プログラムを提供してもよく、それによって、ユーザは紹介コードを登録することができる。ユーザがトークン化プラットフォームへのユーザの紹介に成功すると、ユーザにはトークンで報酬が支払われる。トークンは、金銭的報酬または物品（例えば、ギフトカード、靴、音楽アルバム、DVDなど）を表すことができる。

【0073】

図１は、本開示のいくつかの実施形態によるトークン化プラットフォーム100（または「プラットフォーム」）の例示的なエコシステムを示す図である。環境は、プラットフォーム100、ノードコンピューティングデバイス160、外部データソース170、コンテンツプラットフォーム180、およびユーザデバイス190を含む。プラットフォーム100、ノードコンピューティングデバイス160、外部データソース170、コンテンツプラットフォーム180、及びユーザデバイス190は、通信ネットワーク10（例えば、インターネット及び／又はセルラーネットワーク）を介して通信し得る。

【0074】

いくつかの実施形態において、トークン化プラットフォーム100は、１つまたは複数の暗号台帳（または「分散台帳」）を管理し、商品、サービス、および／または体験などのアイテムの仮想表現と、そのアイテムの充足および満足との柔軟な機能性を提供する。実施形態において、プラットフォーム100は、トークンを使用してアイテムの取引を行うために、第３者の販売者のための市場を提供し、それによって、トークンは、特定のアイテムにおける所有権を定義するデジタルマーカである。加えて、または代替的に、プラットフォーム100のプロバイダは、プロバイダによって提供されるアイテムを販売、リース、譲渡、またはその他の方法で取引することができる。本明細書で使用される場合、用語「取引」は、販売／購入、リース、贈与、担保設定、またはトークンの所有権に影響を与える他の任意のアクションを指す場合がある。後述するように、いくつかの実施形態では、トークンの所有者は、トークンの償還時にアイテムを所有することができるように、トークンは、トークンの所有者によって償還されることができる。

【0075】

いくつかの実施形態では、アイテムの販売者（または他の任意の適切なユーザ）は、プラットフォーム100にアクセスして、販売者が取引のために提供しているアイテムの仮想表現を定義することができる。アイテムの仮想表現は、アイテムを識別する情報（例えば、アイテムに対応するシリアル番号、アイテムのモデル番号など）、アイテムに関する情報（例えば、アイテムの分類、テキスト説明、画像、音声、動画、仮想現実データ、拡張現実データなど）、および／またはアイテムを含む取引を促進または検証するために使用され得るコード（例えば、スマートコントラクト）を含んでもよい。いくつかの実施形態では、プラットフォームは、アイテムの仮想表現に基づいてトークンのセットを生成し、トークンおよび関連するメタデータを暗号的に安全な分散台帳に格納し、それによってトークン（および仮想表現）を検証可能、譲渡可能、および追跡可能にして、アイテムの販売者に代わってアイテムを「トークン化」することができる。

【0076】

実施形態において、プラットフォーム100は、１つまたは複数の外部データソース170からデータを受信してもよい。外部データソース170は、プラットフォームにデータを提供することができる任意のシステムまたはデバイスを指す場合がある。実施形態において、データソースは、利用可能なアイテムに関連するデータをプラットフォーム100に提供する販売者、製造業者、又はサービス提供者システム、及び／又はデータベースを含んでもよい。外部データソースはまた、ユーザデバイス190が関連するデータ（例えば、連絡先、クッキーなど）を提供することができるように、ユーザデバイス190を含んでもよい。外部データソース170の例は、電子商取引ウェブサイト、組織ウェブサイト、ソフトウェアアプリケーション、および連絡先リスト（例えば、電話連絡先、電子メール連絡先、メッセンジャークライアント連絡先、および同種のもの）を含んでもよい。プラットフォーム100は、任意の適切な方法（例えば、クローラ、ユーザ許可／APIなど）で、ネットワーク10（例えば、インターネット）を介して外部データソース170にアクセスしてもよい。

【0077】

実施形態において、プラットフォーム100は、コンテンツ公開プラットフォーム180と相互作用する。コンテンツ公開プラットフォーム190は、個人及び／又は組織に代わってコンテンツを公開する任意のシステムを指すものであってもよい。コンテンツ公開プラットフォームは、ソーシャルネットワークプラットフォーム、ブログプラットフォーム、ニュースサイトなどを含むことができる。実施形態において、消費者は、コンテンツ公開プラットフォーム190を介してアイテムに対応するコンテンツを出力してもよい。例えば、消費者は、購入したアイテムに関連するコンテンツをソーシャルネットワークプラットフォームに投稿してもよいし、コンテンツをブログ投稿に埋め込んでもよい。コンテンツは、アイテムへのリンク（例えば、アイテムに対応するウェブページ又はアプリケーションの状態へのリンク）を含んでもよい。

【0078】

実施形態において、プラットフォーム100は、様々なユーザデバイス190とインターフェースする。ユーザデバイス190は、ユーザ（例えば、消費者、販売者、製造者、プロバイダ等）がプラットフォームにアクセスすることができる任意のコンピューティングデバイスを指すことができる。ユーザデバイスの例としては、スマートフォン、タブレットコンピュータデバイス、ラップトップコンピュータデバイス、パーソナルコンピュータデバイス、スマートテレビ、ゲームコンソールなどが挙げられるが、これらに限定されるものではない。ユーザデバイスは、ウェブサイト、ウェブアプリケーション、ネイティブアプリケーションなどを介してプラットフォーム100にアクセスしてもよい。実施形態において、プラットフォーム100は、販売者に関連するユーザデバイス190に第１のグラフィカルユーザインターフェースを提供し、エンドユーザに関連するユーザデバイス190に第２のグラフィカルユーザインターフェースを提供してもよい。第１のグラフィカルユーザインターフェースは、販売者に関連するユーザが、販売用のアイテムを提供し、販売用のアイテムに対応する新しい仮想表現を作成することを可能にし得る。第２のユーザインタフェースは、ユーザが、販売用のアイテムに対応するトークンを購入すること、トークンを譲渡すること、及び／又はトークンを償還することを可能にしてもよい。いくつかの実施形態では、プラットフォーム100は、ユーザのトークンを格納するデジタルウォレットをサポートしてもよい。デジタルウォレットは、プラットフォーム100によって提供および／またはサポートされるクライアントアプリケーションであってもよい。いくつかの実施形態では、デジタルウォレットは、デジタルウォレットに関連付けられたユーザが所有する任意のトークンを格納し、ユーザがトークンを含む取引に償還、譲渡、販売、交換、またはその他の方法で参加することを可能にするインターフェースを提供する。

【0079】

実施形態では、アイテムのトークン化は、トークンによって表されるアイテムに関して安全に取引を行うためのフレームワークを提供する。例えば、トークンは、信頼できる当事者または信頼できない当事者を含む取引において、アイテムが取引、レンタル、購入、販売、交換、贈与、スワップ、または譲渡され得る仕組みを提供する。一部の実施形態では、トークンは、取引される（例えば、販売、取引、リース、贈与など）単一のユニットを表す。例えば、販売者が１０個のウィジェットを販売している場合、プラットフォーム100は、１０個のトークンを生成し、各トークンが異なるウィジェットに対応することができる。このシナリオでは、１０個のウィジェットはすべて、ウィジェットの同じ仮想表現に対応してもよく、１０個のトークンは、仮想表現のインスタンス（「仮想資産」とも呼ばれる）を表してもよい。実施形態において、トークンは、アイテムの仮想表現のデジタル署名されたインスタンスであってもよく、それによって、デジタル署名は、トークンの妥当性を検証するために使用されてもよい。

【0080】

いくつかの実施形態において、アイテムの各仮想表現は、例えば、仮想表現によって表されるアイテムに関連する取引（例えば、所有権の譲渡または期限切れ）を自己実行するために満たされなければならない検証可能な条件の組を提供するスマートコントラクトを含むかまたは関連付けられるものであってもよい。いくつかの実施形態において、仮想表現に対応する各トークンは、仮想表現に対応するスマートコントラクトに関連付けられ得る。いくつかの実施形態において、仮想表現に対応するスマートコントラクトは、新しいトークンを生成するために検証されなければならない条件、トークンの所有権を譲渡するために検証されなければならない条件、トークンを償還するために検証されなければならない条件、及び／又はトークンを破棄するために満たさなければならない条件を定義してもよい。スマートコントラクトは、特定の条件が満たされたときに実行されるアクションを定義するコードも含むことができる。関与している場合、スマートコントラクトは、そこに定義された条件が満たされているかどうかを判定し、満たされている場合、条件に対応するアクションを自己実行するために、その条件を満たすことができる。いくつかの実施形態において、各スマートコントラクトは、分散台帳上に格納され、分散台帳上でアクセスされるものであってもよい。いくつかの実施形態では、自身に関連付けられたスマートコントラクトを有しないトークンは、プレースホルダートークンと呼ばれることがあり、プレースホルダートークンは取引に関与しない場合がある。いくつかの実施形態では、トークンは贈与され得る。いくつかの実施形態において、贈与されたトークンの受領者は、トークンを償還すること、償還前にトークンによって表される仮想資産をカスタマイズすること、別のトークンに交換すること、現金価値相当物を取得すること、等をすることができる。

【0081】

プラットフォーム100がトークンを生成すると、プラットフォームは、新しいトークンの存在を示すために分散台帳を更新し得る。本明細書で使用されるように、分散台帳は、取引を記録する電子台帳を指す場合がある。分散台帳は、公開されてもよく、非公開であってもよい。分散台帳がプライベート（非公開）である実施形態では、プラットフォーム100は、プラットフォームに関連するコンピューティングデバイスノード160上に分散台帳全体を維持し、保存してもよい。分散台帳がパブリック（公開）である実施形態では、プラットフォーム100に関連しない１つまたは複数のサードパーティのコンピューティングノードデバイス160（または「コンピューティングノード」）が、分散台帳を一括して保存してもよい。これらの実施形態のいくつかでは、プラットフォーム100は、分散台帳及び／又はその一部をローカルに保存することもできる。いくつかの実施形態において、分散台帳は、ブロックチェーン（例えば、イーサリアム・ブロックチェーン）である。あるいは、分散台帳は、他の適切なプロトコル（例えば、ハッシュグラフ、バイトボール、ナノブロックラティス、及びIOTA）に準拠してもよい。トークンを分散台帳に格納することで、そのトークンの状態は、台帳に問い合わせることでいつでも確認でき、それが正しいことを信頼することができる。トークン方式で実装することで、トークンを勝手にコピーしたり換金したりすることはできなくなる。

【0082】

いくつかの実施形態では、プラットフォーム100は、分散台帳のメインチェーンから分岐するサイドチェーンが存在するように、分散台帳をシャーディングするように構成される。これらの実施形態のいくつかでは、サイドチェーンは、特定のカテゴリ又はクラスを有するアイテムの仮想表現を格納し得る。実施形態において、アイテムの特定のクラスに対応するサイドチェーンは、特定のクラスに属するアイテムに対応するトークンと、それらのトークンの現在および以前の所有権を示す所有権記録とを格納してもよい。トークンの所有権が変更されるたびに、関与するトークンを含むサイドチェーンは、トークンの新しい所有者を示すように修正されてもよい。いくつかの実施形態において、サイドチェーンは、仮想表現に関連付けられるメディアコンテンツを格納してもよい。例えば、サイドチェーンは、それぞれの仮想表現によって参照されるビデオ、写真、オーディオクリップ、および他の適切なメディアコンテンツを格納してもよい。

【0083】

アイテムデータ（例えば、仮想表現）、トークン、およびトークンに関連する取引データに加えて、分散台帳は、アカウント情報をさらに格納してもよい。例えば、いくつかの実施形態において、分散台帳は、各有効なアカウントのパブリックアドレスを格納してもよい。実施形態において、有効なアカウントは、プラットフォームによって検証され、取引に参加することが許可されたエンティティに属してもよい。したがって、いくつかの実施形態では、当事者は、当事者が既知のアカウントを有する場合にのみ、トークンを販売、購入、贈与、受領、または他の方法で譲渡することができる。各アカウントには、プラットフォーム100上で取引するために使用され得る公開鍵および秘密鍵が割り当てられてもよい。実施形態において、アカウントのアドレスは、アカウントの公開鍵に基づいてもよい（例えば、アドレスは、公開鍵のハッシュ値であってもよい）。これらのアドレスは、分散台帳に格納されてもよく、取引に関与するアドレスは、分散台帳を使用して有効なアカウントに対応するものとして検証され得るように、分散台帳に格納されてもよい。

【0084】

動作において、販売者は、各仮想表現が取引のために利用可能であるそれぞれのアイテムを表すように、１つ以上のそれぞれのアイテムの仮想表現を生成するようにプラットフォーム100に指示し得る。本開示における取引の例の多くは、物品、サービス、及び／又は体験の購入に関するものであるが、取引は、リース、レンタル、ローン、ギフト、取引、報酬、又は景品も含み得ることに留意されたい。実施形態において、販売者は、取引可能なアイテムの数、アイテムの価格情報、アイテムの配送制限、アイテムに関する有効期限（例えば、取引の有効期間）、アイテムの説明、シリアル番号（例えば、物理アイテムの）、アイテムに関するメディア（例えば、写真、ビデオ、及び／又はオーディオコンテンツ）等、１つまたは複数のアイテムの組に関するアイテム属性を提供し得る。販売者がアイテム情報を提供することに応答して、プラットフォーム100は、取引可能なアイテムの数に対応するトークンの組を生成する。例えば、販売者が、販売可能なModel Xのウィジェットが１００個あることを示す場合、プラットフォーム100は、Model Xのウィジェットの仮想表現を生成し、仮想表現に対応する１００個の非代替性トークンを生成してもよく、それによって各トークンが、仮想表現のそれぞれのインスタンスに対応する。仮想表現は、ウィジェットの説明、ウィジェットの価格、ウィジェットに関連する出荷制限、ウィジェットの写真、ウィジェットの動画、ウィジェットに関連する仮想現実データなどを含んでもよい。そして、プラットフォーム100は、仮想表現と対応するトークンを分散台帳に格納してもよい。各トークンについて、分散台帳は、トークン、トークンに関連する所有権データ、トークン（またはトークンが対応する仮想表現）に対応するメディアコンテンツ、および／またはトークンに関連する他の適切なデータを分散台帳に格納してもよい。トークンの所有権は、初期的に、販売者に割り当てられる場合がある。そのため、分散台帳は、トークンの存在と、販売者がトークンを所有していることを示すことができる。トークン化されると、エンドユーザ（例えば、買い手）は、対応するトークンを使用してアイテムの取引に参加することができる。例えば、ユーザは、プラットフォーム100のプロバイダによって提供またはサポートされるウェブインターフェースまたはアプリケーションを介して、販売者からアイテムに対応するトークンを購入してもよい。取引に応答して、プラットフォーム100は、分散台帳を更新して、ユーザへの（例えば、ユーザのアカウントに関連付けられたウォレットへの）トークンの割り当てを示してもよい。実施形態において、トークンのコピーは、トークンの新しい所有者（例えば、買い手）に対応するデジタルウォレットに格納されてもよい。

【0085】

トークンは、任意の適切な方法で、ユーザ間で送信されることができる。例えば、トークンは、電子メール、インスタントメッセージ、テキストメッセージ、デジタル譲渡、ソーシャルメディアプラットフォームなどを介して送信されてもよい。これらの実施形態のいくつかでは、トークンは、送信者のユーザデバイス190から（例えば、ユーザのデジタルウォレットから）、意図する受信者に関連するユーザデバイス190（例えば、スマートフォン）またはアカウント（例えば、電子メールアカウントまたはメッセージングアプリケーション）に直接送信されてもよい。送信を開始すると、デジタルウォレットは、プラットフォーム100に譲渡要求を送信してもよく、受信者のユーザデバイス190または指定されたアカウントにトークンのコピーを送信してもよい。いくつかの実施形態では、送信されたトークンは、受信者がメディアコンテンツを受信し、トークンを受け入れることを選択し得るように、画像、絵文字、またはビデオなどのメディアコンテンツに埋め込まれてもよい。この例では、トークンは、トークンを受信したユーザデバイス190に、受信者がトークンを受け入れると受信者のアカウントにトークンを追加させるリンクおよび／またはソフトウェア命令を伴っていてもよい。トークンを受け入れることを選択すると、受信者のユーザデバイス190は、受信者のアカウントにトークンを追加するための要求をプラットフォームに送信してもよい。プラットフォーム100は、要求を受信してもよく、分散台帳におけるトークンの所有権記録を更新して、所有権の譲渡を示してもよい。

【0086】

いくつかの実施形態では、トークンの所有者は、トークンを償還してもよい。いくつかの実施形態において、ユーザは、ユーザのデジタルウォレットから償還するトークンを選択してもよい。選択に応答して、デジタルウォレットは、プラットフォーム100に償還要求を送信してもよい。償還要求は、トークン（又はその識別子）及びユーザのパブリックアドレス（又はユーザの他の任意の適切な識別子）を含んでもよい。プラットフォーム100は、償還要求を受信し、トークンの有効性及び／又はトークンの所有権を検証する。検証されると、ユーザは、トークンを償還する許可を付与される。いくつかのシナリオでは、ユーザは、デジタルアイテム（例えば、ギフトカード、MP3、映画、デジタル写真）に対応するトークンを償還することができる。これらのシナリオでは、プラットフォーム100は、デジタルアイテムを請け出すためのワークフローを決定してもよい。例えば、プラットフォーム100は、ユーザから電子メールアドレスを要求してもよいし、分散台帳からユーザの電子メールアドレスを調べてもよい。この例では、プラットフォーム100は、デジタルアイテムをダウンロードするためのリンクをユーザの電子メールアカウントに電子メールで送信してもよく、または、ユーザの電子メールアカウントに送信される電子メールにデジタルアイテムのコピーを添付してもよい。別のシナリオでは、ユーザは、物理的な物品（例えば、衣類、食品、電子機器など）または物理的なサービス（例えば、メイドサービス）に対応するトークンを償還することができる。物理的な物品の場合、プラットフォーム100は、物理的な物品を請け出すためのワークフローを決定してもよい。例えば、プラットフォーム100は、ユーザから出荷情報を要求してもよいし、分散台帳からユーザの出荷情報を調べてもよい。その後、プラットフォーム100は、物理的な物品の出荷を開始してもよい。例えば、プラットフォーム100は、出荷情報を示す出荷要求を、物品の出荷を取り扱う倉庫に送信してもよい。上記は、トークンがどのように償還され得るかの例である。プラットフォーム100は、トークンの償還を処理するために、追加の又は代替のワークフローを実行してもよい。

【0087】

いくつかの実施形態では、トークンは、実店舗で換金され得るように、物理的媒体に印刷されてもよい。例えば、トークン（例えば、英数字の文字列）は、QRコード（登録商標）又はバーコードに符号化されてもよい。これらの実施形態では、トークンをデジタル署名するために使用された当事者の公開鍵（例えば、プラットフォーム100に関連する公開鍵）も、物理媒体において提供されてもよい。このようにして、トークンは、プラットフォーム100に関連付けられたクライアントアプリケーションを使用してQRコード（登録商標）またはバーコードをスキャンすることによって検証されてもよい。クライアントアプリケーションは、トークン及び公開鍵をプラットフォーム100に提供してもよく、プラットフォーム100は、トークン及び公開鍵に基づいて、トークンの有効性を検証してもよい。トークン及び所有権が検証された場合、プラットフォーム100は、検証の確認をクライアントアプリケーションに送信してもよい。その後、店員は、ユーザが取引を完了すること（例えば、アイテムの所有権を取得すること）を許可してもよい。

【0088】

いくつかの実施形態では、トークンは、所定の時間または所定のイベントの発生時にすべての価値を失うという意味で、可滅性のものであってよい。これらの実施形態では、販売者は、仮想表現がもはや有効でない日時を示す有効期限を仮想表現に提供してもよく、有効期限に達すると、トークンが無効とみなされ得るようにする。

【0089】

トークンは、代替性トークンまたは非代替性トークンであってもよい。代替性トークンは、交換可能なトークンを指す場合がある。たとえば、代替性トークンは、すべて同じ識別子を持つことができる。非代替トークンは、一意のトークンである。非代替性トークンは、譲渡可能であるが、互換性がない。

【0090】

いくつかの実施形態において、プラットフォーム100は、市場システム102、台帳管理システム104、取引システム106、APIシステム108、インテリジェンス及びオートメーションシステム110、アナリティクス及びリポートシステム112、及び／又は仮想世界プレゼンスシステム114のうちの１以上を実行してもよく、これらは全て、本開示を通じてより詳細に説明される。

【0091】

いくつかの実施形態では、プラットフォーム100は、アイテムの仮想表現を定義、生成、閲覧、および／または償還することを可能にする市場システム102を提供する。実施形態において、市場システム102は、販売者が仮想表現を定義することを可能にし、消費者がアイテムの仮想表現を閲覧し、アイテムに対応するトークンに対して取引することを可能にし、トークン所有者がトークンを償還し、それによって償還されたトークンが示すアイテムに対して取引を完了することを可能にするグラフィカルユーザインターフェースを含んでもよい。市場システム102は、これらのオペレーションをサポートするためのバックエンド機能をさらに含んでもよい。

【0092】

いくつかの実施形態において、プラットフォーム100は、トークンを生成し、生成されたトークンの所有権の管理を含む、１つまたは複数の分散台帳を管理する台帳管理システム104を提供する。実施形態において、台帳管理システム104はまた、分散台帳に関与する１つまたは複数のスマートコントラクトとインターフェースし得る。

【0093】

実施形態において、プラットフォーム100は、１つまたは複数の関連アプリケーション（例えば、プラットフォーム100プロバイダによって提供されるネイティブおよび／またはウェブアプリケーション）、プラットフォーム100によってサポートされるか、さもなければプラットフォーム100と相互作用する第三者システム、およびプラットフォーム100とインターフェースするように構成されるスマートコントラクトにAPIを公開するよう、プラットフォームの１つまたは複数のアプリケーションプログラミングインターフェース（API）を管理する、APIシステム106を含む。APIシステム106は、APIシステム106が要求するデバイスまたはシステムからAPIコールを受信してもよく、および／またはサブスクライブするデバイスまたはシステムにデータをプッシュしてもよいように、１つまたは複数のAPIを公開してもよい。APIシステム106は、REST、SOAPなどを含む任意の適切なタイプのAPIを実装してもよい。実施形態において、APIシステム106は、スマートコントラクトがプラットフォームとインターフェースすることを可能にするスマートコントラクトAPI、ユーティリティAPI、販売者がアイテムの仮想表現に対応するトークンを作成することを可能にする販売者API、および任意の他の適切なAPIを含んでいてもよい。いくつかの実施形態において、プラットフォーム100は、サービスが、APIおよび／またはソフトウェア開発キット（SDK）などによって、クライアントによってアクセスされ得るようなマイクロサービスアーキテクチャを実装してもよい。サービスは、ブロックチェーン作成、オブジェクト処理、所有権譲渡、データ統合、アイデンティティ管理などの複雑さを抽象化し、プラットフォームユーザがプラットフォーム機能を容易に構築、提供、および／または消費できるようにする。実施形態において、SDKタイプは、Android SDK、iOS SDK、Windows SDK、JavaScript SDK、PHP SDK、Python SDK、Swift SDK、Ruby SDKなどを含むが、これらに限定されるものでない。

【0094】

いくつかの実施形態において、プラットフォーム100は、対応するアイテムを表すトークンの売買、取引、レンタル、リース、交換、スワップ、譲渡、および／または償還を含む、プラットフォームに関する任意の適切な取引をサポートする取引システム108を含む。

【0095】

いくつかの実施形態において、プラットフォーム100は、機械学習および人工知能タスクを実行するインテリジェンスおよびオートメーションシステム110を含む。例えば、インテリジェンス及びオートメーションシステム110は、機械学習モデルを訓練する、機械学習モデルに基づいて分類及び予測を行う、製品をユーザに推薦する、特定のユーザを対象とする広告を識別する、サービス提供者をサービス希望者にマッチングする、及び／又はユーザへの通知を自動化する、ものであってもよい。

【0096】

いくつかの実施形態において、アナリティクスおよびリポートシステム112は、トークン化プラットフォーム100の様々な側面に関連する分析関連のタスクを実行し、結果の分析を利害関係者（例えば、プラットフォームプロバイダ100の従業員および／またはプラットフォーム100上の販売者）にリポートしてもよい。

【0097】

いくつかの実施形態において、プラットフォームは、仮想世界環境においてアイテムの仮想表現を提示する仮想世界プレゼンスシステム114を含むか、またはサポートする。例えば、仮想世界プレゼンスシステム114は、仮想現実ストアをユーザに提示してもよく、それによってアイテムの仮想表現がストア内で提示され、ユーザは仮想世界環境内で仮想アイテムの「買い物」をすることができる。これらの実施形態において、仮想世界プレゼンスシステム114は、クライアントアプリケーションで表示され得る仮想世界環境をレンダリングしてもよい。仮想世界環境は、販売者または販売者のグループと関連付けられてもよく、それによって、販売者または販売者によって販売されるアイテムが仮想世界環境において利用可能にされる。これらの実施形態において、仮想世界プレゼンスシステム114は、アイテムの仮想表現に基づいて、販売者又は販売者から利用可能であるアイテムの3D表現をさらにレンダリングしてもよい。次いで、3D表現は、ユーザがアイテムの3D表現を調べる（例えば、異なる角度から表現を見る）ことができるように、仮想世界環境において提示されてもよい。ユーザがアイテムを購入したい場合、ユーザは取引を開始することができる（例えば、仮想表現内の「購入」ボタンを選択する）。ユーザが取引を開始すると、仮想世界プレゼンスシステム114は、ユーザの選択を取引システム106に通知してもよく、取引は上述した方法で先行してもよい。

【0098】

実施形態において、プラットフォーム100は、ユーザ管理システム116を含む。いくつかの実施形態において、ユーザ管理システム116は、新しいユーザアカウントを作成する、ユーザに関連するリスクを評価する、取引に参加する際にユーザに関連するそれぞれのリスクに基づいてユーザに条件を提供する、等々を行うことができる。

【0099】

いくつかの実施形態では、ユーザ管理システム116は、ユーザのための新しいアカウントを作成する。これらの実施形態では、新しいユーザは、プラットフォーム100にアクセスし、新しいアカウントを要求してもよい。実施形態において、プラットフォーム100は、ユーザが自分のアカウントを外部システム（例えば、Google（登録商標）、Facebook（登録商標）、Twitter（登録商標）など）のアカウントにリンクさせることを可能にし得る。加えて、または代わりに、ユーザは、電子メールアドレスを提供し、ログインすることができる。いくつかの実施形態において、ユーザ管理システム116は、自宅の住所又は会社の住所、パスポート番号（及び／又はパスポートの画像）、運転免許証番号（及び／又はその画像）、州IDカード（及び／又はその画像）などの追加の認証情報を提供するようにユーザに要求することができる。ユーザ管理システム116は、クレジットカード番号、銀行情報、暗号通貨ウォレット（例えば、Coinbase（登録商標）アカウント）などを入力することを含め、ユーザが任意の金融情報をプラットフォームにリンクするための機構をさらに提供してもよい。要求された情報を受け取ると、ユーザ管理システム116は、ユーザに対応するアカウントの新しいパブリックアドレスを作成することを含む、ユーザの新しいアカウントを作成する。アカウントが作成されると、ユーザは、プラットフォーム100上の取引に参加し始めることができる。

【0100】

いくつかの実施形態において、ユーザ管理システム116は、ユーザがプラットフォーム100を使用して取引に参加しようとするたびに、ユーザのリスクスコアを決定する。ユーザのリスクスコアは、ユーザを含む特定の取引を促進することに関連するリスクの程度を示し得る。リスクの例としては、販売者が他のユーザによって購入されたアイテムを配送しないリスク、販売者が他のユーザに偽物又は規格外のアイテムを配送するリスク、ユーザがローンをデフォルト（不履行）にするリスク、ユーザが詐欺に関与するリスク、及び同様のものが挙げられ得る。ユーザのリスクスコアに関連し得る要因としては、ユーザが二次認証情報（例えば、パスポートまたは運転免許証）を提供したかどうか、ユーザが銀行情報を提供したかどうか、ユーザがプラットフォーム100上で行った購入または販売の数、それらの取引のサイズ、ユーザが以前の取引でどれだけの問題（例えば、どれだけの不払いまたは不引渡、苦情など）を抱えていたか、ユーザがプラットフォームが促進するローンをデフォルトにしたか、および同様のものが挙げられるが、それに限定されるものではない。

【0101】

いくつかの実施形態では、ユーザ管理システム116は、取引を与えられたユーザに関連するリスクを評価するために訓練されたリスクスコアリングモデルを使用してリスクスコアを決定してもよい。ユーザが取引に従事しようとすると、ユーザ管理システム116は、取引の特徴（例えば、取引のタイプ、取引のサイズなど）及びユーザの特徴（ユーザの以前の取引の結果、それらの取引のタイプ、ユーザが二次認証情報を提供したかどうか、ユーザが銀行情報を提供したかどうか、ユーザが過去に問題を起こしたことがあるかなど）を判定してもよい。ユーザ管理システム116は、例えば、ユーザがアイテムの売却を要求したとき、担保付きローンを要求したときなどに、リスクスコアを決定してもよい。ユーザ管理システム116は、インテリジェンス及びオートメーションシステム110に特徴を提供してもよく、このシステムは、特徴をリスクスコアリングモデルに入力してもよい。リスクスコアリングモデルは、特徴に基づいてリスクスコアを出力してもよく、リスクスコアは、取引の特徴及びユーザの特徴が与えられた場合に取引が成功する確率を示す。実施形態において、リスクスコアリングモデルは、後述するように、インテリジェンス及びオートメーションシステム110（例えば、図５の機械学習システム502）により訓練されてもよい。

【0102】

いくつかの実施形態において、ユーザ管理システム116は、ユーザに関連するリスクに基づいて、取引への参加を要求するユーザに対して一連の条件を課してもよい。条件の例は、プラットフォーム上で販売されるアイテムの販売価格（例えば、販売者が商品を提供しないか、または偽の商品を提供した場合に返金される金額）に等しい額の資金をエスクローに入金するようユーザに要求すること、ユーザがローンをデフォルトにするリスクが大きい場合、ユーザにローン額を超える担保を提供するよう求める、ユーザがローンを要求していてその情報を提供していない場合、ユーザに二次認証情報の提供を求める、などを含み得る。例えば、ユーザがプラットフォーム100上でアイテムを販売することを要求しているが、ユーザがアイテムを販売した履歴を持っていない場合、潜在的な取引に関連するリスクスコアは、販売者がアイテムを正常に引き渡さないリスク、またはアイテムが偽物であるかもしくは満足できない状態の取引である可能性を示す可能性がある。この例では、プラットフォーム100は、ユーザが売却を希望するアイテム又はアイテムの販売価格以上の額の資金をユーザが入金する（又は自分のアカウントに持つ）ことを要求してもよい。このようにして、プラットフォーム100は、ユーザ（すなわち、販売者）が取引を正常に完了しない場合、買い手に払い戻しを発行してもよい。実施形態において、ユーザ管理システム116は、ユーザが取引に従事することを望む場合、特定の取引に関してユーザに課すべき条件がある場合には、その条件を決定するために、一連の規則を実装してもよい。実施形態において、規則は、特定のタイプの取引（例えば、販売、取引、借入など）に対応する１つ以上の条件を定義してもよく、１つ以上の条件をトリガーするリスクスコア閾値を定義してもよい。

【0103】

プラットフォーム100は、追加の又は代替のシステムも実行してもよい。例えば、実施形態において、プラットフォーム100は、プラットフォーム100の側面をゲーム化するゲーム化システム（図示せず）、及び／又は特定の活動に参加したユーザに対して報酬を与える報酬システム（図示せず）を含んでもよい。例えば、ゲーム化システムは、ユーザがソーシャルメディアプラットフォーム上で最も共有された仮想アイテムのために競争することに挑戦する環境を提供してもよい。この例では、報酬システムは、ユーザがソーシャルメディアプラットフォーム上で最も多くの仮想アイテムを共有したとみなされたときに、アイテムを交換するためのトークンをユーザに報酬として与えてもよい。別の例では、報酬システムは、ユーザがある値又は額の仮想アイテムを購入したときに、ユーザに報酬（例えば、特定のアイテムへのトークン）を発行してもよい。

【0104】

いくつかの実施形態では、プラットフォーム100は、物品又は食品などのアイテムの物理的な配達を可能にする物流システム（図示せず）を含むことができる。物流システムは、アイテムが存在する場所（例えば、倉庫又はレストラン）からトークンの償還者（例えば、償還者の家又は現在地）までの物流を管理するように構成されてもよい。実施形態において、物流システムは、配送場所を決定するためのジオロケーションシステム（図示せず）を含んでもよい。例えば、ピザ配達チェーンからの１つのトッピングを有するピザに対応するトークンの所有者がトークンを償還する場合、ジオロケーションシステムは、配達のための受取人の現在の位置を決定してもよい。ジオロケーション情報は、スマートフォン、ウェブブラウザ（例えば、IPアドレス）等によって取得されてもよい。この例では、物流システムは、ユーザのジオロケーション（又は選択された配達場所）及びユーザの注文（例えば、ユーザが選択したトッピング）に基づき電子通知を生成してもよく、意図した配達場所に最も近いピザ配達チェーンの場所に電子通知を送信してもよい。

【0105】

図２は、本開示のいくつかの実施形態による市場システム102の一例を示す図である。実施形態において、市場システム102は、アイテム管理システム202と、買い手市場システム204と、償還システム206とを含むことができる。

【0106】

アイテム管理システム202は、アイテムの販売者がアイテムの仮想表現を定義することを可能にする。実施形態では、アイテム管理システム202は、販売者がアイテムの属性を定義することを可能にするGUIを販売者のユーザデバイス190に提示する。アイテムがプラットフォーム100上で販売されたことがない場合、販売者は、新しいアイテムを追加するオプションを選択することができる。そうすることに応答して、販売者は、アイテムの種類（例えば、「靴」、「ピザ」、「写真」、「映画」、「コンサートチケット」、「ギフトカード」等）及びアイテムの名称を示すアイテム分類を提供してもよい。次に、販売者は、アイテムの１つ以上の追加の属性を定義してもよい。例えば、実施形態では、販売者は、アイテムの説明、アイテムに関連するメディアコンテンツ（例えば、写真、ビデオ、オーディオクリップなど）、関連リンク（例えば、販売者のウェブサイトへのリンク）、アイテムの価格、アイテムに関する制限（例えば、「米国の配送のみ」または「販売者の店舗の営業時間は１０－６」）、償還指示（例えば、「店舗での償還が許可されているか否か、店舗での償還が許可、許容、または必須であるかどうか、デジタル資産がダウンロードまたは電子メールで送信されるかどうか、アイテムが譲渡可能であるかどうか、など）、取引可能なアイテムの数（例えば、何単位が利用可能か）、および／または他の任意の適切な属性が挙げられる。販売者がアイテム属性を提供することに応答して、アイテム管理システム202は、アイテムの仮想表現を生成してもよい。実施形態において、仮想表現は、アイテムの属性を含むデータレコードであってもよい。仮想表現が以前に定義されたシナリオでは、販売者は、以前に定義されたアイテムを選択してもよく、１つ又は複数の属性を更新してもよい。例えば、販売者は、追加のメディアコンテンツを提供してもよく、価格を変更してもよく、及び／又は、利用可能なアイテムの数を更新してもよい。更新された仮想表現であっても新たに定義された仮想表現であっても、アイテム管理システム202は、仮想表現を台帳管理システム104に出力してもよく、台帳管理システム104は、仮想表現のインスタンスをトークン化してトークンの集合を得てもよい。

【0107】

いくつかの実施形態では、アイテム管理システム202は、販売者が販売者属性を提供することも可能にし得る。販売者は、物理的アイテムが出荷され得る物理的な場所、デジタルアイテムが取得され得るデジタルロケーション、販売者の実店舗の物理的な場所、販売者の営業時間などの情報を提供してもよい。これらの属性は、仮想表現に含まれてもよく、代替の日付レコードに格納されてもよい。

【0108】

いくつかの実施形態において、アイテム管理システム202は、プラットフォーム100が新しいタイプの資産の販売及び取引をサポートすることを可能にするために、新しいタイプのアイテムを作成し定義するための資産タイプマネージャを含んでもよい。これらの実施形態では、資産タイプマネージャは、ユーザが新しいタイプの資産を定義することを可能にするGUIを提供してもよい。これらの実施形態において、資産タイプ属性フィールドは、新しい資産タイプが定義されているときに、ユーザが新しい資産タイプに特有の情報を追加することを可能にする。属性情報は、買い手が購入を決定する際の材料となる情報と理解することができ、資産タイプに固有の情報であり、プラットフォーム上に表示可能な情報でなければならない。資産タイプの属性フィールドには、資産タイプ名、資産タイプ画像、資産償還URL、資産デスクリプタ（例えば、物理的またはデジタル）などが含まれるが、これらに限定されるものではない。

【0109】

実施形態において、アイテム管理システム202は、プラットフォーム上にリストされ得るように、アイテムの新しいタイプを定義するためのアイテムタイプ定義マネージャを含んでもよい。実施形態において、アイテムタイプ定義マネージャは、ユーザが新しいアイテムの属性を定義することを可能にするGUIを提供してもよい。新しいアイテムタイプを定義するために、ユーザは、ドロップダウンメニューから適切な資産タイプを選択するように促され得る。次に、GUI は、ユーザがアイテム属性フィールドにアイテム属性を定義することを可能にすることができる。アイテム属性フィールドは、アイテム名、アイテムの説明、アイテムのメモ、アイテムの画像、アイテムの価格データ（例えば、希望価格、希望最低価格）、即売フラグ、アイテムを購入するためのウェブページにリンクするアイテムURL、アイテムの数額などを含み得るが、これらに限定されるものではない。ユーザが必要なアイテム属性を提供すると、アイテム管理システム202は、新しいアイテムを定義する新しい仮想表現を作成することができる。

【0110】

いくつかの実施形態では、アイテム管理システム202は、十分な履歴のない販売者に対して、トークン化プラットフォーム100で販売されている商品の価値に等しい額の資金をエスクローすることを要求してもよい。販売者は、アイテムを表すトークンを販売してもよく、トークン所有者（例えば、買い手または下流受領者）によってトークンが償還されると、資金がエスクローから移され、販売者のアカウントに戻される。これらの実施形態では、販売者は、倉庫または他の保管施設に少なくとも１つの追加の出荷を行う必要がある物理的なアイテムを預託する必要がない。

【0111】

実施形態において、買い手市場システム204は、消費者がアイテムを閲覧又は検索し、アイテムの仮想表現を閲覧し、アイテムの取引に関与することを可能にする。実施形態では、買い手市場システム204は、ユーザが１つ以上の検索用語で構成される検索クエリを入力することを可能にする検索バーを含むGUIを提示する。検索クエリを受け取ることに応答して、買い手市場システム204は、１つ以上の検索用語を使用して仮想表現をインデックス化する１つ以上のインデックスにクエリを発行してもよい。買い手市場システム204は、検索クエリを処理し、任意の適切な検索技術を使用して、後続の検索を実行してもよい。検索を実行することに応答して、買い手市場システム204は、検索によって意味付けられた仮想表現を取得してもよく、仮想表現を視覚的な方法で提示してもよい。例えば、GUIは、1つ以上の検索結果を表示する検索エンジン結果ページ（SERP）を表示してもよく、各検索結果は、異なる仮想表現に対応し、ユーザが、アイテムに関連する任意のメディアコンテンツ及びアイテムの価格を含むアイテムの仮想表現で定義されるアイテムの属性を表示でき、アイテムに対応するトークンを購入することを選択できる各ページにリンクしている。

【0112】

実施形態において、買い手市場システム204は、ユーザがプラットフォーム上で提供される仮想アイテムをブラウズすることを可能にし得る。例えば、買い手市場システム204は、消費者がカテゴリによって又は他の属性によってアイテムをフィルタリングすることを可能にするGUIを提示してもよい。GUIは、ユーザがアイテムに対応するリンクを選択することを可能にしてもよく、このリンクは、ユーザが、アイテムに関連する任意のメディアコンテンツ及びアイテムの価格を含むアイテムの仮想表現において定義されるアイテムの属性を閲覧でき、アイテムに対応するトークンを購入することを選択できるページへとユーザを誘導する。

【0113】

実施形態において、消費者がアイテムを購入することを選択すると、買い手市場システム204は、購入に関して台帳管理システム104に通知してもよい。買い手市場システム204は、ユーザのパブリックアドレスと、選択されたアイテムの仮想表現の識別子とを台帳管理システム104に提供してもよい。台帳管理システム104は、仮想表現に対応するトークンのセットから、ユーザのパブリックアドレスに関連付けられたアカウントにトークンを割り当て、割り当てられたトークンの所有権がユーザのパブリックアドレスに変更されたことを示すように分散台帳を更新することによって、取引を実現することができる。例えば、買い手市場システム204（または取引システム106）は、販売者によって現在所有されているトークンを特定し、そのトークンの所有権を買い手のアカウントに移行してもよい。これが起こると、トークンのコピーがユーザのアカウントに預け入れられることがある。例えば、トークンは、ユーザのデジタルウォレットに預け入れられることがある。

【0114】

実施形態において、買い手市場システム205は、アイテムを個々のサムネイル画像として描写することができる。これらの実施形態のいくつかでは、アイテム詳細ページに、アイテム説明属性、アイテム注記属性、及び販売者URL属性を含むアイテムの属性を表示するために、単純なボックススタイルのユーザインタフェース要素を追加することができる。GUI上のアイテム説明フィールドは、プラットフォームユーザを製品に関するより多くの情報を有するページまたは他の関連するページにリダイレクトすることができるクリック可能なURLをサポートすることができる。商品説明のテキストボックスを表示し、サードパーティのドメインへのリンクをサポートすることができます。

【0115】

実施形態において、買い手市場システム204は、ユーザがオーダーメイドのアイテムを購入することを可能にし得る。例えば、ユーザは、カスタマイズされたピザ、家具の一部、フラワーアレンジメントなどを注文することができる。ユーザは、複数のマーチャントからの複数のアイテムからなるアイテムをデジタル的に構築し、そのアイテムを3Dプリントステーションで3Dプリントさせることができる。

【0116】

図３は、本開示のいくつかの実施形態に従って１つまたは複数の分散台帳210を管理する、トークン化プラットフォーム100の台帳管理システム104の一例を示す図である。実施形態では、台帳管理システム104は、トークン生成システム302と、台帳更新システム304と、検証システム306とを含む。トークン生成システム302は、取引のために利用可能にされたアイテムに対応し、アイテムのそれぞれの仮想表現に基づくトークンを生成するように構成されてもよい。台帳更新システム304は、分散台帳310を更新する要求を受信し、それに応じて分散台帳310を更新する。検証システム306は、トークンやアカウントなどを検証する要求を受信し、分散台帳に基づいてトークンやアカウントの検証を試みる。

【0117】

実施形態において、分散台帳310は、N個のノードコンピューティングデバイス160が台帳310のN個のそれぞれのコピーを格納し、それぞれのコピーが分散台帳310の少なくとも一部を含むような、公開台帳であってよい。他の実施形態では、分散台帳310は、台帳がプラットフォーム100の制御下にあるノード間で分散される、プライベートな台帳である。実施形態において、分散台帳310は、ブロックチェーン（例えば、ETCプロトコルに準拠したイーサリアム・ブロックチェーン）である。あるいは、分散台帳310は、他の適切なプロトコル（例えば、Hashgraph、Byteball、Nano-Block Lattice、又はIOTA）に準拠してもよい。トークンを分散台帳310に格納することによって、そのトークンの状態は、台帳に問い合わせることによっていつでも検証することができ、それが正しいことを信頼することができる。実装にトークンアプローチを用いることで、トークンを勝手にコピーして換金することはできない。

【0118】

分散台帳310は、アイテム、ユーザ、販売者などに関連する任意の適切なデータを格納してもよい。実施形態において、分散台帳310は、アイテム関連データを格納してもよい。アイテム関連データは、アイテム識別子、アイテムの有効期限、アイテムに付けられた条件又は制限、アイテムの説明、アイテムに関連するメディアコンテンツ（例えば、写真、ロゴ、ビデオなど）、アイテムの文書、カスタマイズオプション、利用可能なサイズ、利用可能な色、利用可能な材料、機能性オプション、成分、価格、アイテムに関する特別提供又は割引、場所情報（例えば、アイテムを配達／提供できる場所）、利用可能時間、オーナー／管理者データ、レビュー、アイテムタイプ、及び同様のものを含み得るが、それだけに限られるわけではない。実施形態において、分散台帳310は、ユーザデータを格納してもよい ユーザデータは、識別情報（例えば、ユーザID、電子メールアドレス、名前など）、公的住所、財務情報（例えば、クレジットカード情報）、取引履歴、ロケーションデータ（例えば。ユーザの地域又はユーザの国）、嗜好、ウィッシュリスト、ユーザのサブスクリプション、ユーザに属するアイテム、ユーザ接続又はコンタクト、ユーザに関連するメディアコンテンツ（例えば、ユーザの写真又はビデオ）、ユーザのアバター、等である。実施形態において、分散台帳310は、マーチャント関連データを格納してもよい。加盟店関連データは、識別情報（例えば、加盟店の名称、加盟店ID、及び／又は同種のもの）、加盟店の連絡先、経験データ、位置データ、利用可能時間、レビュー、メディアコンテンツ（写真、ビデオ、及び同種のもの）、及び／又は他の任意の適切な加盟店関連データを含み得るが、これらに限定されるものではない。分散台帳310は、追加のデータおよび／または代替のデータを格納してもよい。

【0119】

実施形態において、分散台帳310は、サイドチェーン314を含む。サイドチェーン314は、台帳310のメインチェーン312のセグメント（例えば、ブロック）から延びる分散台帳310のシャードを参照してもよい。実施形態において、メインチェーン312は、アカウント（例えば、パブリックアドレス）を有するマーチャント及びユーザに関連するデータを格納してもよい。さらに、または代替的に、メインチェーン312は、アイテム分類の説明などのアイテム分類データを格納してもよい。実施形態において、サイドチェーン314は、アイテムの特定の分類に関連していてもよい。これらの実施形態のいくつかでは、サイドチェーン314は、アイテムのそれぞれの属またはクラスに属するアイテムの仮想表現と、それらのアイテムに関連するデータとを格納してもよい。例えば、第1のサイドチェーン314-1は、プラットフォーム100上で利用可能な靴の仮想表現と、それらの仮想表現に関連する任意のトークン関連データとを格納してもよい。実施形態では、サイドチェーン314は、プラットフォーム上で取引可能なアイテムに関連して使用されるメディアコンテンツを格納してもよい。例えば、第2のサイドチェーン314-2は、第1のサイドチェーン314-1に表された靴を描写する写真、第1のサイドチェーン314-1に表された靴を描写するビデオクリップ、第1のサイドチェーン314-1に表された靴に関するオーディオクリップ、第1のサイドチェーン314-1に表された靴を描写する仮想現実コンテンツ、第1のサイドチェーン314-1に表された靴を描写する拡張現実コンテンツ等を格納してもよい。以上、分散台帳をシャード化する一態様を説明した。分散台帳310は、他の任意の好適な態様でシャーディングされてもよい。

【0120】

実施形態では、トークン生成システム302は、仮想表現を受信し、仮想表現に対応する1つまたは複数のトークンを生成する。実施形態では、仮想表現は、利用可能なアイテムの数（すなわち、取引に利用可能なアイテムの数）を含む、アイテムの属性を含む。実施形態では、利用可能なアイテムの数は、トークン生成システム302が特定の仮想表現について生成するトークンの数を示す。属性は、トークンの有効期限（例えば、トークンが有効である期間）など、アイテムに関連する他の制限も含んでもよい。トークン生成システム302は、初期所有権データも受信してもよい。初期所有権データは、トークンの初期所有者を定義する。デフォルトとして、仮想表現によって表されるアイテムを提供するエンティティ（例えば、アイテムの販売者）は、トークンの初期所有者である。しかし、初期所有権は、異なるエンティティに割り当てられてもよい。

【0121】

実施形態において、トークンは、仮想表現のインスタンスを包むラッパーである。これらの実施形態のいくつかでは、トークン生成システム302は、トークンを識別するトークン識別子を生成してよい。トークンが非代替性トークンであるシナリオでは、トークン生成システム302は、仮想表現に対応するそれぞれのトークンに対して一意の識別子を生成してもよい。トークン生成システム302は、任意の適切な技法を用いてトークン識別子を生成してもよい。例えば、トークン生成システム302は、トークンを識別する値を生成するために、乱数発生、格発生、単純発生、及び／又はトークン・ブリッジ発生を実装してもよい。実施形態において、トークン生成システム302は、秘密鍵／公開鍵ペアを用いて、値にデジタル署名してもよい。トークン生成システム302は、プラットフォーム100又は加盟店に関連する秘密鍵／公開鍵ペアを利用して、トークンを識別する値にデジタル署名してもよい。トークン生成システム302は、トークンを識別する値にデジタル署名するために、任意の適切なデジタル署名アルゴリズムを実装してもよく、例えば、国立標準技術研究所によって開発されたデジタル署名アルゴリズム（DSA）などが挙げられる。実施形態では、結果として得られるデジタル署名は、トークン識別子として使用されてもよい。各トークンについて、トークン生成システム302は、トークン識別子及びアイテムの仮想表現を含むトークンラッパーを生成してもよい。実施形態において、トークン生成システム302は、トークンにデジタル署名するために使用される公開鍵をトークンに埋め込むか、または他の方法でエンコードしてもよい。あるいは、トークン生成システム302は、トークンが新しい所有者に譲渡されるたびにトークン所有者のアカウントに公開鍵が伝達されるように、公開鍵をトークンとは別に保存してもよい。非代替性トークンを生成すると、トークン生成システム302は、非代替性トークンを台帳更新システム304に出力してもよい。ラッパーは、代替性トークン及び非代替性トークンを含む複数のトークンをラップしてもよい。

【0122】

いくつかの実施形態では、トークン生成システム302は、カビ可能なトークンを生成してもよい。これらの実施形態では、トークン生成システム302は、各トークンが同じトークン識別子を有する、同一のトークンを生成してもよい。これらの実施形態では、トークン生成システム302は、上述の方法で単一のトークン識別子を生成してもよく、そのトークン識別子を使用してN個のカビ可能なトークンを生成してもよく、ここでNは全トークンの数である。N個のファンジブルトークンを生成すると、トークン生成システム302は、N個のファンジブルトークンを台帳更新システム304に出力してもよい。

【0123】

実施形態において、台帳更新システム304は、1つまたは複数の分散台帳310を更新および維持するように構成される。本明細書で使用されるように、分散台帳310を更新および維持することは、分散台帳310へのデータの書き込みを指す場合がある。実施形態において、台帳更新システム304は、分散台帳が準拠するプロトコルに従ってブロックを生成してもよく、ブロックは、分散台帳310に書き込まれるデータを含む。実施形態において、台帳更新システム304は、生成されたブロックを分散台帳310を格納するコンピューティングノード160にブロードキャストすることにより、分散台帳310を更新してもよい。コンピューティングノード160が、受信したブロックを分散台帳310のそのローカルコピーに修正するかどうかを決定する方法は、分散台帳が準拠しているプロトコルによって定義されてもよい。

【0124】

実施形態において、台帳更新システム304は、トークンを受信し、それに基づいて分散台帳310を更新する。これらの実施形態のいくつかでは、台帳更新システム304は、トークンと所有権データ（例えば、トークンが割り当てられるべきエンティティのパブリックアドレス）とを受け取り、それに基づいて分散台帳310を更新する。例えば、台帳更新システム304は、トークンをその中に埋め込んだブロックを生成してもよい。生成されたブロック又はその後に生成されたブロックは、トークンに係る所有権データを含んでもよい。そして、台帳更新システム304は、生成されたブロック（複数可）を分散台帳310に書き込んでもよい。例えば、台帳更新システム304は、プラットフォーム100で維持される分散台帳310のコピーにブロック（複数可）を修正してもよく、及び／又は、分散台帳310のコピーを格納するコンピューティングノード160にブロック（複数可）をブロードキャストし、分散台帳のそれぞれのコピーを、今度はブロードキャストしたブロック（複数可）で修正することができる。分散台帳310がシャーディングされる実施形態では、台帳更新システム304は、トークンが対応するサイドチェーン314（例えば、アイテム分類）を指定してもよい。これらの実施形態では、生成されたブロックは、トークンの存在及びトークンの現在の所有権を示すために、指定されたサイドチェーン314に修正される。

【0125】

実施形態では、台帳更新システム304は、トークンの所有権を別のアカウントに変更することを要求する所有権変更要求を受信する。例えば、台帳更新システム304は、トークンの購入、トークンの贈与、トークンの転売、トークンの取引などに応答して、所有権変更要求を受信してもよい。いくつかの実施形態では、所有権変更要求は、譲渡されるトークンと、トークンの譲受人（例えば、トークンの受領者）のパブリックアドレスとを定義してもよい。いくつかの実施形態では、所有権変更要求は、トークンの現在の所有者（トークンが現在の所有者を有すると仮定する）のパブリックアドレスをさらに含んでもよい。台帳更新システム304は、所有権変更要求を受信してもよく、インプライドトークンの新しい所有者を示すためのブロックを生成してもよい。その後、台帳更新システム304は、生成されたブロック（複数可）を分散台帳310に書き込んでもよい。例えば、台帳更新システム304は、ブロック（複数可）を分散台帳310に修正してもよく、および／またはブロック（複数可）を分散台帳310を格納するコンピューティングノード160にブロードキャストしてもよい。分散台帳310がシャーディングされる実施形態では、台帳更新システム304は、トークンが対応するサイドチェーン314（例えば、アイテム分類）を指定してもよい。これらの実施形態では、生成されたブロックは、トークンの新しい所有者を示すために、指定されたサイドチェーン314に修正される。

【0126】

実施形態において、台帳更新システム304は、新しい又は変更された仮想表現を受信し、新しい又は変更された仮想表現を反映するために分散台帳310を更新する。例えば、台帳更新システム304は、販売者が取引可能な新しいアイテムを定義したときに、新しい仮想表現を受信してもよい。台帳更新システム304は、販売者が以前に定義された仮想表現の1つ以上の属性を変更したことに応答して、変更された仮想表現を受信してもよい。実施形態において、台帳更新システム304は、新しい又は変更された仮想表現を受信し、受信した仮想表現に基づいて1つ又は複数のブロックを生成する。次に、台帳更新システム304は、生成されたブロック（複数可）に基づいて分散台帳310に書き込んでもよい。例えば、台帳更新システム304は、ブロック（複数可）を分散台帳に修正してもよく、及び／又は、ブロック（複数可）を分散台帳を格納するコンピューティングノード160にブロードキャストしてもよい。分散台帳310がシャーディングされる実施形態では、仮想表現に係るメディアコンテンツは、別個のサイドチェーン314に格納されてもよい。これらの実施形態のいくつかでは、メディアコンテンツは、仮想表現とは別のブロックに格納されてもよく、仮想表現を含むブロックは、対応するメディアコンテンツを含むブロックへの参照を含んでもよい。台帳更新システム304は、仮想表現が対応するサイドチェーン314（例えば、アイテム分類）と、１つまたは複数のメディアコンテンツブロックが対応すべきサイドチェーン314とを指定してもよい。これらの実施形態において、生成されたブロックは、新しいまたは修正された仮想表現を示すために、それぞれの指定されたサイドチェーン314に修正される。その後、台帳更新システム304は、１つまたは複数の生成されたブロックを分散台帳310に書き込むことができる。例えば、台帳更新システム304は、１つまたは複数のブロックを分散台帳310に修正してもよく、及び／又は、１つまたは複数のブロックを分散台帳310を格納するコンピューティングノード160にブロードキャストしてもよい。分散台帳310がシャーディングされる実施形態では、台帳更新システム304は、焼失したトークンが対応するサイドチェーン314（例えば、アイテム分類）を指定してもよい。これらの実施形態では、生成されたブロックは、新しいおよび／または修正された１つまたは複数の仮想表現を示すために、指定されたサイドチェーン314に修正される。

【0127】

実施形態において、台帳更新システム304は、トークンを「バーン」するようにさらに構成される。トークンをバーンする（燃やす）ことは、トークンがもはや償還不可能とみなされるメカニズムを指す場合がある。トークンは、トークンの有効期限が切れたとき、またはトークンが償還されたときに、燃やされてもよい。実施形態において、台帳更新システム304は、トークンが現在所有されていない（例えば、所有者＝NULL）ことを示すためにトークンの所有権を更新してもよく、及び／又は、トークンがもはや有効でないことを示すためにトークン状態を更新してもよい。これらの実施形態のいくつかでは、台帳更新システム304は、トークンが現在所有されていないこと、またはトークンの状態が有効でないことを示すブロックを生成してもよい。その後、台帳更新システム304は、生成されたブロック（複数可）を分散台帳310に書き込んでもよい。例えば、台帳更新システム304は、ブロック（複数可）を分散台帳310に修正してもよく、及び／又は、ブロック（複数可）を分散台帳310を格納するコンピューティングノード160にブロードキャストしてもよい。いくつかの実施形態では、分散台帳310はシャーディングされる。これらの実施形態において、台帳更新システム304は、トークンが対応するサイドチェーン314（例えば、アイテム分類）を指定してもよい。これらの実施形態では、生成されたブロックは、焼かれたトークンを示すために、指定されたサイドチェーン314に修正される。

【0128】

台帳更新システム304は、他のデータを示すために、分散台帳310を同様に更新してもよい。実施形態において、台帳更新システム304は、分散台帳310上のマーチャントデータおよび／またはユーザデータを維持および更新してもよい。例えば、台帳更新システム304は、有効なアカウントのパブリックアドレスリストを維持してもよい。台帳更新システム304は、プラットフォーム310に追加された新しいアカウントを、それらのアカウントのパブリックアドレスとともに反映するために、暗号台帳を更新してもよい。台帳更新システム304は、追加または代替の加盟店データおよびユーザデータも分散台帳に格納してもよい。

【0129】

実施形態では、検証システム306は、分散台帳310に格納されたデータを検証する。実施形態において、検証システム306は、トークンの有効性を検証してもよく、および／または、トークンの所有権を検証してもよい。検証システム306は、分散台帳310に格納された他のタイプのデータも検証するように構成されてもよい。

【0130】

実施形態において、検証システム306は、トークン検証要求を受信する。トークン検証リクエストは、検証されるトークンまたはそのトークン識別子を含んでもよい。これらの実施形態において、検証システム306は、検証されるトークンのトークン識別子が分散台帳310に格納されているか否かを判断してもよい。分散台帳310に格納されていない場合、検証システム306は、そのトークンが無効であると判断してもよい。いくつかの実施形態では、トークン検証要求は、トークンの検証に使用される公開鍵をさらに含んでもよい。これらの実施形態では、検証モジュール306は、受信した公開鍵を使用して、公開鍵が分散台帳310に格納されているトークンに対応するかどうかを決定してもよい。これらの実施形態のいくつかでは、検証システム306は、受け取った公開鍵と、デジタル署名を符号化するために使用された秘密鍵とを使用して、受け取った公開鍵がトークンに署名するために使用された公開鍵であるか否かを判断する。例えば、実施形態では、検証システム306は、秘密鍵と受信した公開鍵とを用いてデジタル署名の復号化を試みてもよい。秘密鍵および受信した公開鍵が、トークンの生成に使用された値を得るためにデジタル署名の復号を可能にする場合、検証システム306は、トークンを有効とみなし、その検証を要求システムに通知してもよい。

【0131】

実施形態において、検証システム306は、トークンの所有権を検証するように構成されてもよい。これらの実施形態では、検証システム306は、検証されるパブリックアドレスとトークン（またはその識別子）とを受信してもよい。いくつかの実施形態では、検証システム306は、パブリックアドレスがプラットフォーム100上のアカウントに対応することを検証してもよい。例えば、検証システム306は、パブリックアドレスが分散台帳310上のパブリックアドレスリストに格納されているか否かを判断してもよい。そうである場合、検証システム306は、トークンに関連する所有権データが、受信したパブリックアドレスによって示されるアカウントによって現在所有されているかどうかを判断してもよい。そうである場合、検証システム306は、トークンの所有権を検証してもよく、検証を要求システムに出力してもよい。

【0132】

図４は、本開示のいくつかの実施形態による、トークン化プラットフォーム100の取引システム106の一例を示す図である。いくつかの実施形態では、取引システム106は、トークン譲渡システム402及び償還システム404を含む。取引システム106は、本開示の範囲から逸脱することなく、追加のまたは代替のシステムを含んでもよい。例えば、取引システム106は、デジタルウォレットシステム408、エクスプレス取引システム410、支払統合システム412、加入システム414、及び／又はトークン架け橋システム416を含んでもよい。

【0133】

実施形態では、トークン譲渡システム402は、トークンの所有者のアカウントから別のユーザのアカウントへのトークンの譲渡を促進する。実施形態において、トークン譲渡システム402は、トークンが譲渡され得る条件を定義するスマートコントラクトを含んでもよい。これらの実施形態のいくつかでは、スマートコントラクトは、スマートコントラクトがノードコンピューティングデバイスで、および／またはデジタルウォレットから実行され得るように、トークンに常駐していてもよい。これらの実施形態のいくつかでは、スマートコントラクトは、APIシステム108によって公開されるスマートコントラクトAPIを介して、トークン譲渡システム402とインターフェースしてもよい。

【0134】

実施形態では、トークン譲渡システム402は、アカウントへのトークンの譲渡を要求する譲渡要求を受信する。譲渡要求は、トークン保有者のアカウントから、またはトークンの意図された受信者のアカウントから受信されてもよい。実施形態において、譲渡要求は、トークンが譲渡されるアカウントのパブリックアドレスを含んでもよく、譲渡されるトークンをさらに含んでもよいし、示してもよい。例えば、譲渡要求は、トークンのコピーまたはトークンを一意に識別する値（例えば、英数字の文字列）を含んでもよい。いくつかの実施形態では、譲渡要求は、トークンに電子署名を行ったエンティティの公開鍵を含む。いくつかの実施形態では、譲渡要求は、トークンの譲渡を要求しているトークン所有者のパブリックアドレスを含んでもよい。

【0135】

トークン保有者は、トークン保有者のデジタルウォレットからトークンの譲渡を開始することができる。いくつかの実施形態では、トークンの譲渡は、プラットフォーム100を介して実行されてもよい。これらの実施形態では、トークン所有者は、（例えば、デジタルウォレットのGUIを介して）トークン譲渡システム402に譲渡要求を送信するようデジタルウォレットに指示することによって、トークンの譲渡を開始してもよい。これらの実施形態では、トークン譲渡システム402は、譲渡要求を受信し、トークンが有効なトークンであるかどうか、及び所有者及び／又は受取人のパブリックアドレスが有効であるかどうかを判断してもよい。トークンが有効であり、所有者及び／又は受取人のパブリックアドレスが有効である場合、トークン譲渡システム402は、意図する受取人に関連するユーザデバイス及び／又はアカウントにトークンのコピーを譲渡してもよい。受信者によって受け入れられると、トークン譲渡システム402は、分散台帳が受信者がトークンの現在の所有者であることを示すように、トークンの所有権の変更を示すために分散台帳を更新するように台帳管理システム104に指示することができる。

【0136】

ここで図７Ａを参照すると、ウォレット700のディスプレイの図解が示されている。ウォレット700のディスプレイは、トークン化されたトークン702a～702n（全体として702）、非代替性トークン704a～704"（全体として704）、および代替性トークン706a～706n（全体として706）などの複数のトークンを含む。見て分かるように、実施形態では、トークンは、トークンタイプによってグループ化される。トークン化されたトークン702は、それぞれのトークン化されたトークン702内に含まれる特定のコンテンツ705のタイプおよび実施形態ではその額を伝える表示されたインジケーション703を含んでもよい。例えば、プラットフォーム100内のユーザのビットコインは、カビ可能なトークン706aの残高と1つまたは複数のトークン化されたトークン702aとの間で分割されてもよい。さらに、ユーザのカビ可能なビットコイン706aは、連結された残高であってもよいし、別々の残高（例えば、単一の取引でプラットフォーム100に譲渡されたビットコインの額に等しい残高）であってもよい。

【0137】

非代替性トークン704は、トークンに関連する適切な情報を伝達するための表示インジケータを含んでもよい。例えば、複数の購入可能なスキン704a、704b及びワークフォーハイヤー704がグループ化され、それぞれが、商品の画像などのインジケーションを表示してもよい。代替性トークン706a～706nは、代替性グッズに対応するトークンである。例えば、代替性トークン706a～706nは、通貨、暗号通貨、コモディティなどを含んでもよい。

【0138】

実施形態では、デジタルウォレットは、ユーザデバイス190またはアカウント（例えば、電子メールアカウント、サードパーティメッセージングアプリのアカウント）にトークンを直接送信するように構成され、それによって、トークンの受信者はトークンを受理することができる。これらの実施形態のいくつかでは、受取人のデジタルウォレットは、意図する受取人へのトークンのコピーの送信に加えて、受取人へのトークンの譲渡要求を示す譲渡要求をトークン譲渡システム402に送信してよい。これらの実施形態では、トークン譲渡システム402は、トークンが有効なトークンであるかどうか、及び所有者及び／又は受領者のパブリックアドレスが有効であるかどうかを判断してもよい。トークンが有効であり、所有者及び／又は受取人のパブリックアドレスが有効である場合、トークン譲渡システム402は、受取人がトークンを受取人のそれぞれのデジタルウォレットに受け入れることを許可してもよい。受領者によって受け入れられると、トークン譲渡システム402は、分散台帳310が受領者がトークンの現在の所有者であることを示すように、トークンの所有権の変更を示すために分散台帳を更新するよう台帳管理システム104に指示してもよい。

【0139】

あるいは、いくつかの実施形態では、トークン所有者のデジタルウォレットは、トークン譲渡システム402に譲渡要求を送信しない。これらの実施形態では、トークンの受信者のユーザデバイス190は、トークン所有者がトークンを受け入れることができるメカニズムを提示してよい。例えば、ユーザデバイス190は、トークンを受け入れるためのリンクを提示してよい。意図された受取人がトークンを受け入れると、ユーザデバイス190は（例えば、受取人のデジタルウォレットのインスタンスを介して）、譲渡要求をトークン譲渡システム402に送信してもよい。このシナリオでは、トークン譲渡システム402は、トークンが有効なトークンであるかどうか、および所有者および／または受領者のパブリックアドレスが有効であるかどうかを判断してもよい。トークンが有効であり、所有者及び／又は受取人のパブリックアドレスが有効である場合、トークン譲渡システム402は、分散台帳が受取人がトークンの現在の所有者であることを示すように、トークンの所有権の変更を示すために分散台帳を更新するように台帳管理システム104に指示してもよい。

【0140】

上述したように、譲渡要求に応答して、トークン譲渡システム402は、トークンが有効なトークンであるかどうか、および所有者および／または受信者のパブリックアドレスが有効であるかどうかを判断してもよい。実施形態では、トークンは、トークンに関連する公開鍵を使用して検証されてもよい。例えば、トークン譲渡システム402は、トークン（又はその指標）及び譲渡要求で示された公開鍵を台帳管理システム104に提供してもよい。台帳管理システム104は、トークン識別子が分散台帳に格納されているかどうかを判断してもよく、格納されている場合には、譲渡要求とともに提供された公開鍵がトークンにデジタル署名するために使用された公開鍵であることを検証してもよい。実施形態において、トークン譲渡システム402は、そのパブリックアドレスを用いて、トークンの譲渡を希望する受信者及び／又はトークン所有者の身元を検証してもよい。これらの実施形態のいくつかにおいて、トークン譲渡システム402は、受取人のパブリックアドレス及び／又はトークン所有者のパブリックアドレスを台帳管理システム104に提供してもよく、台帳管理システム104は、今度はそれぞれのパブリックアドレスを調べて、パブリックアドレスが分散台帳に格納されていることを確認してもよい。トークンが有効であり、トークン所有者及び／又は受領者のパブリックアドレスが有効であると判断することに応答して、トークン譲渡システム402は、トークンの譲渡を許可してもよく、分散台帳が受領者をトークンの現在の所有者とすることを示すように、分散台帳を更新してトークンの所有権の変更を示すよう台帳管理システム104に指示してもよい。

【0141】

実施形態では、償還システム404は、トークンの所有者がトークンを償還することを可能にする。償還システム404は、トークンを償還するための要求（または「償還要求」）を受信してもよい。償還要求は、トークン又はトークンの識別子（例えば、英数字の文字列）を含んでもよく、トークンを償還しようとするユーザのパブリックアドレスを含んでもよい。実施形態では、償還要求は、トークンにデジタル署名するために使用される公開鍵をさらに含んでもよい。償還要求の受信に応答して、償還システム404は、トークン、トークンを償還しようとするユーザのパブリックアドレス、及びトークンにデジタル署名するために使用される公開鍵を台帳管理システム104に提供してもよい。次に、台帳管理システム104は、トークン／パブリックアドレスの組合せを検証してもよいし、拒否してもよい。台帳管理システム104は、トークンが有効なトークンでない場合、及び／又はユーザがトークンのリストされた所有者でない場合、その組み合わせを拒否してもよい。台帳管理システム104は、トークンが有効であるとみなされ、要求ユーザがトークンの所有者であるとみなされる場合、トークン／パブリックアドレスの組み合わせを検証してもよい。

【0142】

トークン／パブリックアドレスの組み合わせを検証することに応答して、償還システム206は、償還されたトークンが対応する仮想表現に対応するワークフローを実行することができる。例えば、いくつかのシナリオでは、ユーザは、デジタルアイテム（例えば、ギフトカード、MP3、映画、デジタル写真）に対応するトークンを償還している場合がある。これらのシナリオでは、償還システム404は、デジタルアイテムを請け出すためのワークフローを決定してもよい。例えば、償還システム404は、ユーザから電子メールアドレスを要求してもよいし、分散台帳からユーザの電子メールアドレスを調べてもよい。この例では、償還システム404は、デジタルアイテムをダウンロードするためのリンクをユーザの電子メールアカウントに電子メールで送信してもよく、またはユーザの電子メールアカウントに送信される電子メールにデジタルアイテムのコピーを添付してもよい。別のシナリオでは、ユーザは、物理的な物品（例えば、衣類、食品、電子機器など）または物理的なサービス（例えば、メイドサービス）に対応するトークンを償還することができる。物理的な物品の場合、償還システム404は、物理的な物品を請け出すためのワークフローを決定してもよい。例えば、償還システム404は、ユーザの出荷情報を入力させるGUIをユーザに提示してもよい。あるいは、償還システム404は、例えば、分散台帳又はユーザデータベースからユーザの出荷情報を検索してもよい。その後、償還システム404は、物理的な商品の出荷を開始してもよい。例えば、償還システム404（又は物流システム）は、発送情報を示す発送要求を、物品の発送を取り扱う倉庫に送信してもよい。上記は、トークンがどのように償還され得るかの例である。

【0143】

償還システム404は、トークンの換金を処理するために、追加または代替のワークフローを実行することができる。例えば、いくつかのシナリオでは、トークンの最初の買い手は、取引を満たすために必要なアイテムの特定のパラメータを指定していない可能性がある。例えば、アイテムが衣服の場合、最初の買い手はアイテムのサイズおよび／または色を指定していない可能性がある。別の例では、アイテムが食品である場合、最初の買い手はサイドオーダー、トッピング、ドリンクの選択などを指定しなかったかもしれない。アイテムが航空券やホテルの予約などの経験である場合、最初の買い手は、旅行の日付を指定していない可能性がある。これらのシナリオでは、交換システム404は、トークンの交換者が必要なパラメータを指定することができるGUIを提示し、取引を指定することができるようにすることができる。パラメータを受け取ることに応答して、償還システム404は、取引が満たされ得るように、これらのパラメータを仮想表現のインスタンスまたは取引の充足に対応する他の適切なデータ構造（例えば、配送命令、購入命令など）に帰属させてもよい。

【0144】

実施形態では、取引システム106は、デジタルウォレットをサポートするデジタルウォレットシステム408を含む。デジタルウォレットは、デジタルウォレットに関連付けられたアカウントの所有者によって所有されるトークンであってもよく、ユーザがそのトークンを表示、換金、取引、譲渡、贈与、入金、引き出し、またはその他の取引を行うことができるグラフィカルユーザインターフェースを提供することができる。実施形態では、デジタルウォレットシステム408は、ユーザがアイテムに対応するトークンの販売に同意することができる、インスタントセル能力を提供する。例えば、インスタントセル機能は、ユーザがフロア価格の９０％の割合でアイテムを販売することを可能にし得る。いくつかの実施形態では、他のユーザは、ユーザのプライバシー設定に従って、アカウント所有者が所有する仮想表現インスタンスの一部または全部を閲覧することができる。ユーザは、個々の仮想表現又は全ての仮想表現を隠す又は非公開にすることを選択することができる。

【0145】

いくつかの実施形態では、プラットフォーム100および／またはユーザのデジタルウォレットは、別の人に譲渡されるときにトークンに関連付けられ得る視覚的インジケーションを提供してもよい。例えば、アトークンに関連付けられ得る視覚的指標は、絵文字、画像、GIF、動画などを含んでもよい。これらの視覚的指標は、トークンを別のユーザに譲渡するときに、ユーザによって使用されてもよい。例えば、トークンが花束に対応し、視覚的指標が花の絵文字である場合、ユーザは、花の絵文字を使用してメッセージでトークンを送信してもよい。この例では、ユーザは、デジタルウォレット内のトークンにアクセスしてもよく（例えば、ユーザデバイス190上のネイティブアプリケーションを介して）、トークンを受信者に送信するためのオプションを選択してもよい。ユーザは、受信者を特定し（例えば、連絡先のリストから選択し）、メッセージを入力する機会が提供される場合がある。クライアントアプリケーション（例えば、デジタルウォレット）は、花の絵文字を含むキーボードを提示することができ、花の絵文字はトークンを表します。花の絵文字のユーザ選択及びその後のトークンの「送信」に応答して、デジタルウォレットアプリケーションは、トークン／花の絵文字を含むメッセージの送信を開始することができる。この例では、デジタルウォレットは、譲渡ユーザがトークンの譲渡を要求したことを示す譲渡要求をトークン譲渡システム402に送信することもできる。譲渡要求は、トークンのコピー及び譲渡ユーザのパブリックアドレスを含んでもよい。実施形態では、譲渡要求は、トークンの意図された受取人のパブリックアドレス又は他の指標（例えば、電子メールアドレス、電話番号、ユーザIDなど）をさらに含んでもよい。

【0146】

実施形態では、取引システム106は、ユーザが金銭を交換することなく1つ以上の資産を取引することができるエクスプレス取引システム410を含む。これらの実施形態では、エクスプレス取引システム410は、ユーザがトークンを安全に取引できるメカニズムを提供し、各トークンは異なるアイテムを表す。例示的な動作では、第1のユーザは、第2のユーザに対して、1つまたは複数のトークンと1つまたは複数のトークンを見返りに交換するために、スマートコントラクトで取引オファーを行ってよい。第2のユーザは、要求された仮想資産を譲渡することによって承諾してもよい。その後、スマートコントラクトは、取引を完了したとマークする。実施形態において、エクスプレストレードシステム410は、ユーザがトークンのインベントリを表示し、オファーを作成し、オファーを受け入れ、及び／又はオファーをキャンセルすることを可能にするGUIを提供してもよい。

【0147】

実施形態において、取引システム106は、支払統合システム412を含む。支払い統合システム412は、ユーザがアイテムに対応するトークンを購入することを可能にする。支払統合システム412は、クレジットカード、異なる形態の通貨、及び／又は暗号通貨を受け入れることができる。

【0148】

いくつかの実施形態では、取引システム106は、サブスクリプションシステム414を含む。これらの実施形態では、ユーザは、サブスクリプションシステム414を介して、定期的に消費するアイテムを受け取るためのサービスに加入することができる。

【0149】

実施形態において、取引システム106は、台帳ブリッジシステム416を含む。台帳ブリッジシステム416は、第1の分散台帳システム（または従来の銀行を含む任意の通貨保有者）において元の仮想資産を確保またはロックダウンし、第2の分散台帳システムにおいて取引可能な複製を作成するためのフレームワークを提供する。このようにして、ユーザは、異なる通貨及び異なる送金手段でトークン化プラットフォーム100上の自分のアカウントに資金を供給してもよく、その後、異なる通貨を使用して取引（例えば、取引、贈与、又は償還）に従事することができる。いくつかの実施形態では、分散型台帳ブリッジシステム416は、分散型台帳システム（例えば、プラットフォーム100の分散型台帳310から分離して離れた台帳システム）間でエスクロー機能を提供する。実施形態において、台帳ブリッジシステム416またはデジタルウォレットは、トークン入金GUIおよび／またはトークン引き出しGUIを提供し得る。

【0150】

実施形態では、台帳ブリッジシステム416は、ユーザが1つ以上の外部通貨で自分のアカウントに資金を供給することを可能にする。例えば、ユーザは、ビットコイン、イーサリアムコイン、他の適切な暗号通貨、及び／又は従来の通貨（例えば、米国ドル、英国ポンド、ユーロ、中国元、日本円、及び／又は同様のもの）を用いてアカウントに資金を供給することができる。暗号通貨の場合、ユーザは、例えば、ユーザの暗号通貨を保管する非関連デジタルウォレットを使用して、外部アカウントからの暗号通貨の譲渡を促進することができる。伝統的な通貨の場合、ユーザは、例えば、クレジットカード、直接送金、ACH送金などを用いて、自分のアカウントに資金を送金することができる。いくつかの実施形態では、ユーザがトークン化プラットフォーム110のアカウントに資金（暗号通貨または従来の通貨）を送金すると（これは「資金調達取引」と呼ばれ得る）、台帳ブリッジシステム416は、資金調達取引に対応するレコードを生成してもよく、台帳管理システム104にレコードを提供してもよく、分散台帳を更新して資金調達取引を反映させることができる。記録は、資金が送金されたアカウント、資金が送金されたアカウント、送金された金額、送金の日時、及び／又は他の任意の適切なデータを示してもよい。

【0151】

アカウントに資金が供給されると、ユーザは、次に、譲渡された資金を使用して、トークン化プラットフォーム100上の任意の取引に参加することができる。いくつかの実施形態では、送金された資金の少なくともサブセットは、トークン化プラットフォーム100及び／又はそれに対応する分散台帳312によってサポートされるプロトコルに準拠する方法でトークン化される。実施形態において、台帳ブリッジシステム416は、ユーザに対応する要求に応答して、１つ以上の暗号コイン（例えば、ビットコイン）、暗号コインの任意の分数、または任意の額の通貨をトークン化してもよい。資金をトークン化する要求は、明示的な要求であっても暗黙的な要求であってもよい。明示的な要求は、ユーザがある額の通貨のトークン化を具体的に要求する場合を指すことがある。暗黙的な要求は、ユーザがトークン化プラットフォーム100上で、ユーザのアカウント内の送金された資金を含む取引を行い、その取引を容易にするためにこれらの資金の少なくとも一部をトークン化する必要がある場合を指す場合があります（たとえば、ユーザがアイテムを購入し、ユーザのアカウント内の送金資金の一部を使用してアイテムに対する支払いを選択した場合など。要求が暗黙的であるか明示的であるかにかかわらず、台帳ブリッジシステム416は、ある額の通貨をトークン化することができる。

【0152】

これらの実施形態のいくつかでは、台帳ブリッジシステム416は、ある額の通貨を「ラップする（包む）」トークン化トークンを鋳造（ミンティング）することによって、ある額の通貨をトークン化する。トークン化されたトークンは、通貨の種類及びコインによって表される通貨の額（例えば、ビットコイン、イーサリアム、ドル、ポンドなどの額）を定義する属性を有する非代替性トークンを参照してもよい。これらの実施形態のいくつかでは、トークン化トークンは、トークン化トークンおよび／または他のデジタルアイテム（複数可）内に封入されたデジタル通貨残高（複数可）を表す一組の代替性および／または非代替性トークンを有することに加えて、かかるトークンの特性を定義する一連の属性を有する非代替性トークンを指すことができる。さらに、トークン化トークンは、償還、譲渡、および他のトークン化トークンのライフサイクルメカニズムを管理するビジネスルールを含むことができる。いくつかの実施形態では、台帳ブリッジシステム416は、トークン生成システム302による新しいトークンの生成を要求することによって、新しいトークンを鋳造する。台帳ブリッジシステム416は、通貨の種類、通貨の額、及び所有権データ（例えば、新しいトークン化トークンが属することになるアカウント）をトークン生成システム302に提供してもよい。これに応答して、トークン生成システム302は、例えば、上述した方法で、トークン化されたトークンを生成する。このようにして、トークン生成システム302は、通貨を 「アイテム」として扱う。このようにして、トークン化トークンは、交換（例えば、他のトークン化トークンまたはトークン化アイテムと）、贈与、および／または償還され得る。いくつかの実施形態では、トークン化されたトークンが参加することができる取引の種類は制限される場合がある。たとえば、不安定な通貨を表すトークン化されたトークンは、交換されることは制限されるが、償還または贈与されることは可能であろう。

【0153】

実施形態では、台帳ブリッジシステム416は、鋳造プロセスの一部として、トークン化されたトークンに対応する視覚的インジケーションをさらに生成する。いくつかの実施形態では、視覚的インジケーションは、デジタルステッカー（または「ステッカー」）である。例えば、いくつかの実施形態では、ステッカーは、金額及び通貨を表す記号を描写してよい（例えば、5ドルのトークン化を表すステッカーは、「5ドル」を描写してよく、又はビットコインの10分の1のトークン化を表すステッカーは、「B5」を描写してよい）。このようにして、ステッカーは、トークン化されたトークンの所有者のウォレットに表示されてもよい。議論したように、視覚的指標は、ユーザが所有するトークン化されたトークンをユーザに伝えるために使用されてもよい。さらに、いくつかの実施形態では、視覚的指標は、本開示の他の箇所で説明されているように、（例えば、テキストメッセージ、メッセージングアプリケーション、電子メールなどを介して）他の当事者にトークン化トークンを譲渡するために使用されてもよい。

【0154】

いくつかの実施形態では、台帳ブリッジシステム416は、鋳造プロセスの一部として、トークン化されたトークンに対応するスマートコントラクトをインスタンス化（またはインスタンス化を要求する）することができる。これらの実施形態では、スマートコントラクトは、所有権譲渡および／または償還ロジックなどのトークン化されたトークンのライフサイクル機構を支配する1つまたは複数の基本機能を定義してもよい。基本機能性は、トークン化されたトークンの所有権を変更する能力、トークン化されたトークンが使用され得る取引の種類（例えば、購入、贈与、交換、現金との交換など）などを含んでもよい。新しいトークン化されたトークンが鋳造されると、台帳ブリッジシステム416は、新しく鋳造されたトークン化されたトークンに対応するスマートコントラクトのインスタンスをインスタンス化してもよい。スマートコントラクトのインスタンスは、トークン化されたトークンが譲渡（例えば、交換、贈与、または償還）に関与するたびに実行されてもよい。例えば、トークン化されたトークンの所有者がトークン化されたトークンの譲渡を要求するたびに、スマートコントラクトのインスタンスは、その要求によって関与してもよく、スマートコントラクトのインスタンスは、要求及びスマートコントラクトの内容に応じて、譲渡を不許可又は促進することができる。

【0155】

トークン化トークンが鋳造されると、トークン化トークンによって表される資金は、台帳ブリッジシステム416によって「預託（エスクロー）」され得る。このようにして、ユーザは、トークン化されたトークンが償還されるまで、自分のアカウントから資金を取り出すことが防止される。いくつかの実施形態では、台帳ブリッジシステム416は、トークン化されたトークンに対応する資金を、ユーザのアカウントから指定されたエスクローアカウントに譲渡してよい。代替的に、台帳ブリッジシステム416は、トークン化されたトークンが償還されるまで資金がユーザによって譲渡されないように、トークン化されたトークンに対応する資金を凍結してもよい。トークン化されたトークンが償還されると、トークン化されたトークンによって表される資金がエスクローから解放され、償還するユーザのアカウントに入金され、トークン化されたトークンが破壊されてもよい（「無効化される」とも称される）。

【0156】

実施形態では、台帳ブリッジシステム416は、分散台帳を更新するか、または分散台帳の更新を開始する。分散台帳は、多くの異なる発生時に更新されてもよい。議論されたように、実施形態では、分散台帳は、ユーザが最初にアカウントに資金を供給するときに更新されてもよい。実施形態において、台帳ブリッジシステム416は、新しいトークン化されたトークンが鋳造されたときに分散台帳を更新する（または更新olを開始する）。これらの実施形態では、分散台帳は、新しいトークン化されたトークンの存在およびそのトークンの所有権を反映するように更新される。実施形態において、台帳ブリッジシステム416は、トークン化されたトークンに対応するスマートコントラクトのインスタンスで分散台帳を更新する（または更新を開始する）。実施形態において、台帳ブリッジシステム416は、トークン化されたトークンが譲渡されるたびに、分散台帳を更新してもよい（または、更新を開始してもよい）。これらの実施形態において、分散台帳は、トークン化されたトークンの新しい所有者を反映するように更新されてもよい。実施形態において、台帳ブリッジシステム416は、トークン化されたトークンが償還され、その後破棄されたときに、分散台帳を更新してもよい（または、更新olを開始してもよい）。これらの実施形態において、分散台帳は、トークン化されたトークンがもはや有効でないこと、トークンを償還したアカウント、および／またはトークンが償還されたときを反映するように更新されてもよい。

【0157】

図５は、本開示のいくつかの実施形態によるインテリジェンス及びオートメーションシステム110を例示している。実施形態において、プラットフォームは、インテリジェンス及びオートメーションシステム110を含む。インテリジェンスおよびオートメーションシステム110は、機械学習システム502、人工知能システム504、推薦エンジン506、サービスマッチングエンジン508、広告システム508、および／または通知システム510を含んでもよい。

【0158】

実施形態において、機械学習システム502は、学習データに基づいて機械学習モデルを訓練してもよい。機械学習の例は、様々なタイプのニューラルネットワーク、回帰ベースのモデル、隠れマルコフモデル、スコアリングモデルなどを含んでもよい。機械学習システム502は、教師あり、半教師あり、又は教師なし方式でモデルを訓練してもよい。訓練は、訓練目的のために収集又は生成されてもよい訓練データを用いて行うことができる。機械学習されたモデルは、モデルデータストアに格納されてもよい。

【0159】

一例において、機械学習システム502は、ギフト予測モデルを訓練するように構成されてもよい。ギフト予測モデル（又は予測モデル）は、受信者属性（例えば、意図された受信者に関連するプロファイル）及び／又はギフトとして提供され得る1つ又は複数のアイテムのアイテム属性を受信し、その特定の消費者にギフトトークンを送信することに関する1つ又は複数の予測を出力するモデルであってよい。予測の例は、そのユーザにギフトを送るかどうか、ユーザが評価するであろうギフト、などであってもよい。実施形態において、機械学習システム502は、学習データに基づいてモデルを訓練する。実施形態において、機械学習システム502は、ユーザデータ（例えば、取引履歴、好み、ウィッシュリスト仮想資産など）、仮想資産データ（例えば、価格、色、生地など）、及び結果（例えば、償還、交換など）を含むベクターを受信してもよい。各ベクトルは、それぞれのアウトカムと、それぞれのユーザ及びそれぞれのアイテムの属性とに対応してもよい。機械学習システム502は、ベクトルを取り込み、それに基づいて予測モデルを生成する。

【0160】

実施形態において、機械学習システム502は、取引に参加するユーザの特徴、取引の特徴（例えば、取引のタイプ（例えば、購入、ローン、販売など）、取引のサイズ（例えば。など）、及び取引が成功したか失敗したかを示す取引の結果（例えば、買い手が購入後にアイテムの代金を支払ったか、借り手がローンを完済したか又はローンを不履行にしたか、購入したアイテムが配達され十分な状態にあったか、など）である。）学習データセットは、プラットフォームによって促進された取引、及び／又は専門家によって生成された取引に基づいてもよい。

【0161】

実施形態において、機械学習システム502は、予測モデルをモデルデータストアに格納してもよい。実施形態において、機械学習システム502は、捕捉された結果に基づいてモデルを更新するようにさらに構成されてもよく、これは、"強化学習 "とも称される。実施形態において、機械学習システムは、予測につながった一連の状況（例えば、アイテム属性及びユーザ属性）及び処置に関連する結果（例えば、アイテムの償還、アイテムの交換、アイテムの返金）を受信してもよく、フィードバックに従ってモデルを更新してもよい。本明細書で使用されるように、機械学習システムによって活用され得る機械学習技術は、決定木、K-最近傍、線形回帰、K-平均クラスタリング、深層学習ニューラルネットワーク、ランダムフォレスト、ロジスティック回帰、ナイーブベイズ、学習ベクトル額子化、サポートベクター機械、線形判別分析、ブースティング、主成分分析、及びハイブリッドアプローチを含むがそれだけに限定される訳ではない。

【0162】

実施形態では、人工知能（AI）システム504は、機械学習されたモデルを活用して、ユーザデータ及び資産データに関して、購入、贈与、又は他のEコマースの結果に関する予測又は分類を行う。予測の例としては、ユーザがアイテムを購入するかどうか、ユーザが贈与されたアイテムを交換するかどうか、配達タイミング及び配達場所などの償還オプション、及び同様のものが挙げられる。例えば、AIシステム504は、ギフト予測モデルを活用して、特定のアイテムの受取人がギフトを好むかどうか、ギフトを返すかどうか、又はギフトを交換するかどうかについての予測を行うことができる。

【0163】

実施形態において、推薦システム506は、アイテムに関する推薦をユーザに提供するように構成されてもよい。推薦システム506は、ユーザの属性に基づいてAIシステム504に推薦を要求してもよい。AIシステム504は、推薦のセットを出力してもよく、推薦システム506は、推薦をユーザまたは別の当事者に提供してもよい。例えば、推薦システム506は、ユーザの購入履歴に基づいて、購入すべきアイテムの推薦をユーザに提供してもよい。

【0164】

実施形態では、広告システム508は、ユーザに表示する広告を決定するように構成され、広告は、プラットフォーム上で取引のために提供されているアイテムに関連する。実施形態において、広告システム508は、割引、プロモーションなどをユーザに提示することができる。

【0165】

実施形態では、サービスマッチングシステム510は、ユーザが選択したサービスに対するサービス提供者と消費者をマッチングするように構成される。これらの実施形態において、ユーザはサービスを求めてもよく、サービスマッチングシステム510は、サービスを提供するのに最適なサービス提供者を特定してもよい。例えば、サービスマッチングシステム510は、価格、可用性、位置などに基づいて、サービス希望者とサービス提供者とをマッチングさせてもよい。

【0166】

図６は、本開示のいくつかの実施形態によるインテリジェンス及びオートメーションシステム110を例示している。実施形態において、アナリティクス及びリポートシステム112は、電子商取引プラットフォーム100の様々な側面に関連する分析を取り込み、リポートするように構成される。実施形態において、アナリティクス及びリポートシステム112は、アナリティクスシステム602、リポートシステム604、及び／又は規制資産システム606を含んでもよい。実施形態において、アナリティクス及びリポートシステム112は、ユーザがアナリティクス及びリポートシステム112にアクセスすることを可能にする分析インターフェースを提供してもよい。

【0167】

実施形態において、アナリティクスシステム602は、消費者データ、アイテムデータ、販売者、製造業者、またはプロバイダデータ、ユーザ行動（例えば、購入行動、遠隔測定など）、および取引イベント（例えば、いつアイテムを購入したか、どのようにアイテムを購入したか、どのようにアイテムを譲渡したかなど）に関するデータを追跡および分析してもよいが、これらに限定はされない。

【0168】

実施形態において、リポートシステム604は、アナリティクスシステム602によって得られた分析を1つ以上の関係者にリポートする。利害関係者は、リポートシステム604にアクセスしてもよく、及び／又は、アナリティクスリポートを受け取るためにサブスクライブしてもよい。リポートシステム604は、収集されたアナリティクスに基づいてリポートを生成し、リポートを利害関係者に提供するように構成されてもよい。実施形態において、規制当局GUIは、その後、規制当局がプラットフォーム100にアクセスすることを可能にし得る。例えば、規制当局は、3Dプリント銃器などの規制されたアイテムを追跡及び監視するためにプラットフォームにアクセスしてもよい。

【0169】

実施形態において、アナリティクス及びリポートシステム112は、規制された資産システム606を含む。実施形態において、規制対象資産システム606は、規制対象アイテムを管理するように構成される。例えば、規制資産システム606は、武器又は銃器、医薬品、アルコール、タバコ製品、食品、イベント／会場入場、航空券等へのアクセスを管理してもよい。実施形態において、規制対象資産システム606は、規制対象アイテムに関する取引を追跡及び監視してもよく、取引及び対応するワークフローに基づいて、特定の規制機関に通知してもよい。非限定的な例では、トークンは、3Dプリントされた銃器を追跡するために使用され得、ここで、購入されるアイテムは、銃器をプリントするために使用されるモデルであろう。

【0170】

図１に戻って参照すると、実施形態では、プラットフォーム100は、仮想世界環境内でトークン化された物理世界アイテムを表現するための仮想世界プレゼンスシステム114を含む。いくつかの実施形態では、仮想世界環境は、仮想世界アバターを描写してよい。仮想世界アバターは、ユーザ（例えば、潜在的な買い手）を表してもよく、仮想世界環境内で仮想アイテムと相互作用してもよい。ユーザは、仮想世界ストアにおいて仮想世界アバターを制御することによって「買い物」してもよい。例えば、仮想世界アバターは、仮想世界試着室で、トークン化された物理世界の帽子の仮想表現を試着してもよい。いくつかの実施形態では、仮想世界プレゼンスシステムは、仮想世界環境を表示するためのフレームワークを提供する仮想現実システムを含んでもよい。実施形態において、仮想世界プレゼンスシステムは、ユーザが所有しているアイテム、ユーザが保管しているアイテム、ユーザが所望するアイテムなどを含むがこれらに限定されない、ユーザに関連するアイテムを表示する仮想資産表示システムも含んでもよい。これらのアイテムは、他のユーザに対して公に表示することができ、又は他のユーザから個別に又は集合的に隠すことができる。いくつかの実施形態では、仮想資産表示システムは、ユーザが所有または所持しているアイテムを決定するために、ユーザが所有するトークンのセットを決定し得る。

【0171】

実施形態において、仮想世界プレゼンスシステム114は、仮想資産に関連するコンテンツをコンテンツプラットフォームに共有することを可能にするコンテンツ共有システムを含んでもよい。コンテンツ共有システムは、ユーザが所有する、又はユーザが保管している、又はユーザが所望する仮想資産に関連するコンテンツをユーザが共有することを可能にする。ユーザは、仮想資産に関する追加情報を取得したり、購入、レンタル、借入、取引等を依頼したりすることができる。共有コンテンツは、仮想世界プレゼンスシステムからのデータを含んでもよい。例えば、ユーザは、ユーザの関連する仮想世界アバターが仮想ピザ屋で仮想ピザを食べている動画を共有してもよい。

【0172】

ここで図８を参照すると、トークン化プラットフォーム100は、多数の異なるアプリケーションをサポートし、および／または多数の異なるサービスを提供することができる。例えば、プラットフォーム100は、担保ローンアプリケーション、認証サービス、「ミステリボックス」アプリケーション、カジノゲーミングサービス、及びビデオゲームストリーミングサービスをサポートしてもよい。

【0173】

実施形態では、プラットフォーム100は、担保管理システム802を含む。実施形態では、担保管理システム802は、借り手が担保を提供し、ローンを要求することを可能にする。これらの実施形態のいくつかでは、お金を借りることを望むユーザは、担保アイテム（例えば、収集品、宝飾品、銃器、貴金属など）をプラットフォーム100が提携する、又は他の方法でサポートする施設に持ち込むことができる。施設において、施設の従業員は、担保管理システム802によって提供されるインターフェースを用いて担保アイテムをインベントリ化してもよく、担保アイテムをインベントリ化することは、担保アイテムのアイテム識別子を要求すること、アイテム識別子担保アイテムをユーザ（すなわち、担保アイテムの所有者）のアカウントと関連付けること、担保アイテムの高解像度写真を撮ること、スケールを用いて担保アイテムを計額すること、担保アイテムの説明、担保アイテムの評価等を入力すること等を含み得る。インベントリ化されると、担保管理システム802は、担保アイテムを表す仮想アイテムを作成することができ、その後、仮想アイテムに対応する非代替性トークン（これは、「担保トークン」と呼ばれ得る）を生成することができる。例えば、担保管理システム802は、台帳管理システム104に仮想アイテム及び担保トークンの生成を要求してもよい。担保トークンが生成されると、台帳管理システム104は、新しい担保トークンおよび借り手による担保トークンの所有権を反映するために分散台帳を更新してもよい。その後、担保トークンは、借り手のデジタルウォレットに表示されてもよい。いくつかの実施形態では、担保トークンは、デジタルウォレット内の視覚的指標によって表されてもよい。担保トークンに対応する担保アイテムは、担保トークンが償還されるまで、施設に保管されてもよい。償還されると、償還するユーザ（借り手または担保トークンの譲受人）は、施設から担保アイテムを引き取ってもよく、または担保アイテムがそこへ発送されてもよい。

【0174】

実施形態では、担保管理システム802は、借り手が担保トークンを使用してローンを求めることを可能にし得る。実施形態において、担保管理システム802は、借り手がローン額を要求し、担保として担保トークンを提供することができる市場（例えば、グラフィカルユーザインターフェースを介してアクセス可能である）を提供してもよい。次に、（トークン化プラットフォーム100にアカウントを有する）貸し手は、市場を介して借り手にローンオファーを行うことができる。例示的な実施形態では、ローンオファーは、ローン額、金利、及びローン長を指定してもよい。ローンの申し出は、追加の条件も含んでもよい。例えば、ローンオファーは、ローンを別の貸し手に売却できるかどうか、売却できる場合には、元の貸し手に支払われるべきペイオフ額を示すことができる。借り手はローンオファーに目を通して、最終的に受け入れるローンオファーを決定することができる。

【0175】

借り手がオファーを受け入れると、担保管理システム802は、ローンの期間を記念するローンスマートコントラクトのインスタンスをインスタンス化してもよく、担保トークンをエスクローしてもよい（例えば、誰もスマートコントラクトに従わずに担保トークンを償還すること又は担保トークンを譲渡することはできない）。担保トークンをエスクローする際、担保管理システム802（又はローンスマートコントラクト）は、担保トークンがエスクローアカウントにある間、取引のどの当事者も担保トークンに対する所有権を有しないように、担保トークンをエスクローアカウントに預けてもよい。そのような動作は、ローンが完済されるか、または基礎となるアイテムが清算されるまで、担保トークンをロックする。実施形態において、ローンスマートコントラクトは、貸し手、借り手、ロックされた担保トークン（及びそのアドレス）、ローン額、支払いスケジュール、ローンが譲渡可能かどうか、ローンがデフォルトとみなされるとき、デフォルト時の担保トークンの所有権等を示してもよい。台帳管理システム104は、ローンスマートコントラクトを反映させるために分散台帳を更新してもよい。

【0176】

スマートコントラクトのインスタンスがインスタンス化されると、借り手は、ローンスケジュールに従ってローンの返済を開始しなければならない。ローンスケジュールは、所定の時間までに単一の一括払いを要求してもよく、または所定の間隔で行われるべき複数の支払いを要求してもよいことが理解される。実施形態において、借り手は、彼又は彼女のデジタルウォレットを介して貸し手への支払いを行うことができる。これらの実施形態において、借り手は、銀行、クレジットカード、他の通貨を保持するデジタルウォレットなどから資金を送金してもよい。その後、借り手は、デジタルウォレットを介して貸し手にそれらの資金を送金してもよい。いくつかの実施形態では、台帳ブリッジシステム416は、借り手のアカウントから貸し手のアカウントへの資金の譲渡を促進する。

【0177】

実施形態において、担保管理システム802は、ローンを管理するスマートコントラクトのインスタンスに対応するリスニングスレッドを配備してもよい。リスニングスレッドは、スマートコントラクトのインスタンスに定義された借り手による支払いをリッスンしてもよい。支払いが行われると、リスニングスレッドは、台帳管理システム104に通知してもよく、台帳管理システムは、支払いを反映するために分散台帳を更新する。この更新の間、ローンを管理するスマートコントラクトのインスタンスは、支払いイベントを示す通知を提供され、これにより、スマートコントラクトは、ローンが完全に返済されたかどうかを決定し得る。ローンが完全に返済された場合、スマートコントラクトは、担保トークンを借り手に解放し、スマートコントラクトを終了させる。ローン額が返済されていない場合、スマートコントラクトの条件（例えば、ローン額及び次の返済）は、支払いに基づいて更新されてもよい。リスニングスレッドが支払期日前に支払の受領を検出しない場合、リスニングスレッドは、帳票管理システム104に、支払を怠ったことを通知してもよい。通知に応答して、台帳管理システム104は、分散台帳を更新して、不払いを反映させてもよく、これにより、スマートコントラクトは、契約の条件に従ってローンが不履行であるかどうかを決定し得る。ローンがデフォルトにあると判断された場合、スマートコントラクトは、担保トークンの所有権をスマートコントラクトによって指定された当事者（例えば、貸し手）に譲渡させる。これが起こると、貸し手が担保トークンの所有者となるため、貸し手は、担保トークンを償還してもよく、担保トークンを売却してもよく、担保トークンを贈与してもよく、担保トークンを交換してもよい。

【0178】

実施形態において、担保管理システム802は、購入または譲渡され得るローンのための市場を提供してもよい。市場は、ローンの返済額、ローンの価値（例えば、完済時に回収される額）、ローンの支払履歴（例えば、借り手が支払いを行っているか、または支払いを怠っているか）、ローンを担保する担保アイテム、ローンを購入するための価格などを提示してもよい。いくつかの実施形態では、潜在的な貸し手は、現在の貸し手からローンを購入することを選択することができる。これらの実施形態において、ローンの購入は、担保管理システム802に、現在のスマートコントラクトを終了させ、新しい所有者を反映するために新しいスマートコントラクトをインスタンス化させ、又は、支払いが新しい貸し手のアカウントに向けられるように、及び借り手がデフォルトした場合に新しい貸し手を担保トークンの宛先として指定するためにスマートコントラクトを調整するようにさせる。さらに、またはその代わりに、借り手は、市場を使ってより良い条件のローンを求めることができる。ローンが譲渡可能であると仮定すると、借り手は、潜在的な貸し手が借り手の支払い履歴、ローンの残額、ローン返済額、および担保物件を見ることができる市場にローンを掲載することができる。潜在的な貸し手は、借り手に対して、各貸付条件付きの貸付を申し出ることができる。借り手は、ローンの申し出を受け入れることができます。借り手がローンオファーを受け入れることに応答して、新しい貸し手は、ローンペイオフ額を前の貸し手に譲渡しなければならず、これにより、担保管理システム802は、現在のスマートコントラクトを終了させ、ローンオファーの新たに受け入れられた条件に従って、スマートコントラクトの新しいインスタンスをインスタンス化させる。

【0179】

実施形態において、プラットフォーム100は、認証システム804を含む。認証システム804は、プラットフォーム100に代わって、認証及び／又は鑑定サポートサービスを提供してもよい。いくつかの実施形態では、認証システム804は、販売のために提供される、または担保のために提供されるアイテムを認証するために使用されてもよい。加えて、又は代替的に、認証システム804は、販売のために提供される、又は担保のために提供されるアイテムの鑑定を得るために使用されてもよい。

【0180】

いくつかの実施形態では、認証システム804は、ユーザ（例えば、販売者又はアイテムを保持する施設の従業員）がアイテムの仮想表現をアップロードすることを可能にするポータルを提示する。ユーザは、アイテムの分類（例えば、野球カード、古着、宝飾品、美術品など）、及び仮想アイテムの１つ以上の高解像度写真、アイテムの3D表現、アイテムの寸法、アイテムの重額、及び／又は同様のものを提供してもよい。認証システム804は、ドメイン固有の専門家が、その専門分野で分類されるアイテムを認証及び／又は鑑定できるように、ドメイン固有の専門家が認証者／鑑定者としてサインアップすることを可能にし得る。例えば、スポーツ記念品専門家は、野球カード及び記念品を認証することを許可されてもよいが、宝飾品または美術品を認証することは許可されない。いくつかの実施形態では、認証者は、その専門領域内及びその専門領域内の下位領域について評価され得る（例えば、スポーツ記念品の一般的なカテゴリ内で、専門家は、野球記念品、バスケットボール記念品、サッカー記念品などに関するその知識に関して評価され得る）。新しいアイテムがポータルに入力されると、ドメイン固有の専門家は、鑑定/認証の仕事に入札することができ、入札は、専門家が鑑定/認証の仕事を行う条件（例えば、価格）を示している。次に、ユーザは、それぞれの入札および／またはその評価に基づいて、1人以上の専門家を選択することができる。あるいは、認証システム804は、それぞれの入札および／またはそれらのレーティング（格付け）に基づいて、１人以上の専門家を選択してもよい。専門家が落札すると、専門家は、ユーザによってアップロードされた情報（例えば、仮想アイテムの1つ以上の高解像度写真、アイテムの3D表現、アイテムの寸法、アイテムの重額など）に基づいて、認証及び／又は鑑定を実行する。専門家は、アイテムの真正性を示す鑑定価値及び／又は判定を提供してもよい。認証システム804は、仮想アイテムの仮想表現に専門家の鑑定価値及び／又は真正性の決定を含んでもよく、いくつかの実施形態では、認証システム804は、専門家の鑑定価値及び／又は真正性の決定で分散台帳を更新してもよい。理解され得るように、鑑定及び／又は真正性決定は、アイテムがプラットフォーム上に維持されるか又はプラットフォームから削除される結果となる場合があり、又はアイテムを使用してローンを担保する能力に影響を与える場合がある。

【0181】

いくつかの実施形態では、認証システム804は、専門家に、専門家の判断の理由を示す鑑定／認証メモを提供することを要求する。鑑定を提供し、及び／又は真正性の決定を提供する際に、専門家は、その所見に対する1つ又は複数の理由を提供する。例えば、特定の靴がノックオフであると見解する際に、専門家は、靴の縫い目がノックオフであることを示していることをメモに示すことができる。認証システム804は、専門家の鑑定／真正性メモを仮想アイテムの仮想表現に含めてもよく、一部の実施形態では、認証システム804は、専門家の鑑定／真正性メモで分散台帳を更新してもよい。

【0182】

実施形態において、専門家の認証決定、ならびに認証メモは、機械学習システム502（図５）によって、アイテムが偽物である可能性が高いかどうかを決定できる1つまたは複数のモデルを訓練するために使用されてもよい。これらの実施形態では、モデルは、偽物であるとみなされたアイテムの画像、重み、寸法、及び／又は他の特徴で訓練され得る。認証システム804は、（人工知能システム804を介して）これらのモデルを活用して、新しいアイテムが偽物である可能性が高いかどうかを判断することができる。モデルがアイテムを偽物の可能性が高いと分類した場合、認証システム804は、その決定を仮想アイテムの仮想表現に含めてもよく、いくつかの実施形態では、認証システム804は、アイテムが偽物の可能性が高いという決定で分散台帳を更新してもよい。モデルがアイテムを偽物の可能性が高いと分類できない場合、認証システム804は、専門家がアイテムの真正性を評価できるように、ポータルにアイテムをリストアップしてもよい。実施形態において、モデルは、アイテムが偽物である可能性が高いと分類することができるが、偽造者は、モデルを騙して偽の認証を発行させるために偽造アイテムの品質を適合及び改善し得るので、専門家のみがアイテムを認証し得ることに留意されたい。

【0183】

いくつかの実施形態では、担保管理システム802、認証システム804、及び台帳管理システム104は、証券化された分散型ローンプロセスをサポートするように構成され得る。証券化された分散型ローンプロセスの例示的な実装は、図XXXを参照することを含め、本開示全体を通じて説明される。

【0184】

実施形態では、トークン化プラットフォーム100は、ミステリボックスゲームをサポートするミステリボックスシステム806を含む。実施形態では、「ミステリボックス」は、プレイヤーによって潜在的に獲得され得るトークンのセットを指す場合があり、各トークンは、トークンを使用して償還され得る異なる項目を表す。実施形態において、各トークンは、選択される確率が異なっていてもよい。いくつかの実施形態では、各トークンに数字の範囲が割り当てられてもよく、各トークンの数字の範囲は、プレイヤーによって獲得される確率を反映する。例えば、3つのトークンがあり、第１のトークンが当選する確率が10％、第２のトークンが当選する確率が20％、第３のトークンが当選する確率が30％であり、トークンが当選しない確率が40％の場合、第１のトークンは1～10を割り当てられ、第２のトークンは11～30を割り当てられ、第３のトークンは31～60を割り当てられても良い。この例では、選択され得る値の範囲は、1～100であろう。プレイヤーは、ミステリボックス内のアイテムを獲得するチャンスのために支払ってもよい。いくつかの実施形態では、各トークンの当選確率、及びトークンによって表されるアイテムが、ミステリボックスとの関係で描かれている。このようにして、プレイヤーは、様々なアイテムを獲得するチャンスについて知らされる。

【0185】

プレイヤーからの支払いを受け取ることに応答して、ミステリボックスシステム806は、ボックスの値の全体の範囲（例えば、1～100）によって拘束される乱数を生成してもよい。次いで、ミステリボックスシステム806は、もしあればどのトークンがプレイヤーによって獲得されたかを乱数に基づいて決定してもよい。例えば、ミステリボックスは、宝飾品をテーマとすることができ、それによって、ミステリボックスは、ダイヤモンドリングを表す第１のトークンと、キュービックジルコニアリングを表す第２のトークンと、それぞれが特定の宝石店（例えば、リングを提供した宝石店）で使用できる25ドルのギフトカードを表す８つのトークンとを含む。この例では、第１のトークンが当選する確率は0.1％、第２のトークンが当選する確率は4.9％、ギフトカードがそれぞれ当選する確率は10％であり、それによって、プレイヤーが賞を獲得できない確率が15％である場合がある。この例では、数字の範囲は1～1000であってよく、第１のトークンは数字の1に対応し、第２のトークンは2～50の範囲に対応し、第３～第８のトークンは51～850の範囲の集合を有する。この例では、ギフトカードが宝石店へのトラフィックを促進するための機構と考えられるように、プレイするための価格は宝石店によって設定されてもよい。前述の例では、トークンの範囲は順次であるが、範囲は順次である必要はなく、任意の適切な方法でスロット化することができることに留意されたい。

【0186】

実施形態において、ミステリボックスシステム806は、プレイヤーがミステリボックスから賞品を獲得したことに応答して、獲得したプレイヤーのアカウントにトークンを譲渡してよい。これらの実施形態において、獲得されたトークンは、プレイヤーのデジタルウォレットに現れてもよい。あるいは、ミステリボックスシステム806は、電子メッセージ（例えば、テキストメッセージ、メッセージングアプリのメッセージ、電子メールなど）を介して、獲得したトークンをユーザに配信してもよい。後述するように、いくつかの実施形態では、ミステリボックスシステム806は、ミステリボックスゲームが物理的なデバイスで実装されるような、実店舗のカジノにサービスを提供する。これらの実施形態において、ミステリボックスシステム806は、当選したチケットのトークン識別子（例えば、QRコード（登録商標））を有するチケットをプリントアウトしてもよい。

【0187】

実施形態では、ミステリボックスシステム806は、プレイヤーが複数の利用可能なミステリボックスからプレイするミステリボックスを選択することを可能にし得、各ミステリボックスはそれぞれのテーマを有し得る。例えば、第１のミステリボックスは、ミステリボックスが美術品関連アイテム（例えば、美術品、美術関連製品、美術に関するサービス（例えば、画家に依頼した絵画）等）に対応するトークンを含むように美術をテーマとしてもよく、第２のボックスは、第２のボックスが映画及びテレビ関連アイテム（例えば、人気のある映画及び／又はテレビ番組の記念品、映画及び／又はテレビ番組のDVD又はダウンロードコード、映画館の商品券など）であってもよく、第３のボックスは、スポーツをテーマとするものであってもよい。第３のボックスは、特定のチームに対応するスポーツ関連のアイテムに対応するトークンを含むことができる。例えば、第４のボックスは、ゲームをテーマとすることができ、第４のボックスは、ゲーム関連アイテム（例えば、ビデオゲームシステム、ビデオゲーム、ギフト商品など）に対応するトークンを含むことができる。第５のボックスは、音楽をテーマとするものであってもよく、このボックスは、特定のバンド又はアーティストに対応するアイテム（例えば、サイン入りライヴポスター、バンド又はアーティストの記念品、ライヴチケット、アルバム又は楽曲のダウンロードコードなど）に関連するトークンを含むことができる。このように、プレイヤーは、自分にとって魅力的な賞品を求めてプレイすることを選択することができる。

【0188】

実施形態において、ミステリボックスは、補充可能なアイテム及び／又は非補充可能なアイテムに対応するトークンを含むことができる。補充可能なアイテムは、プレイヤーがアイテムを表すトークンを獲得したときにミステリボックス内に補充することができるアイテムである。例えば、商品券、映画チケット、スポーツ試合チケット、DVD、電子機器、ビデオゲーム、レプリカジャージ、及びほとんどの衣類アイテムは補充可能であり、時計、高級ジュエリー、ゲームウエアスポーツウェア、サイン入り記念品、限定靴、オリジナルアートワーク、などのアイテムは、補充不可能なアイテムの例である。いくつかの実施形態では、ミステリボックスを提供する当事者は、ミステリボックス内の非交換可能アイテムに対して同様の価値を有する交換アイテムを指定してもよく、このように、非交換可能アイテムがミステリボックスから獲得されると、それは指定された交換アイテムのうちの1つと交換され得る。これらの実施形態のいくつかでは、ミステリボックスは、"レシピ "に従って配置されてもよい。レシピは、ミステリボックス内のアイテムの2つ以上の階層と、各階層について、その階層からアイテムを獲得するためのオッズとを指定する。これらの実施形態において、ミステリボックスの提供者は、各階層に属するアイテムのリストを提供してもよい。例えば、最も高い層（例えば、最も低いオッズを有する層）は、価値の高い非補充可能なアイテムを含んでもよく、一方、低い層は、様々なレベルの補充可能なアイテムを含んでもよい。レシピの各アイテムは、トークンがミステリボックスで使用するために予約されるように、トークン化されてもよい。ある層からのアイテムがプレイヤーによって獲得されるたびに、ミステリボックスシステム806は、アイテムを表すトークンを、獲得されたトークンと同じ層からの別のトークンに置き換えてもよい。このようにして、ミステリボックスをプレイするための価格、及びミステリボックス内の各アイテムに関連するオッズは、補充不可能なアイテムがミステリボックスから獲得されたときに変化することはない。

【0189】

実施形態では、各ミステリボックスは、スマートコントラクトによって支配される。スマートコントラクトは、異なるアイテム又はアイテムの階層、及びそれぞれのアイテム又はアイテムの階層のそれぞれについて、それぞれのアイテムを獲得するためのオッズを定義してもよい。新しいミステリボックスが作成されるとき、ミステリボックスシステム806は、新しいミステリボックスに対応する新しいスマートコントラクトをインスタンス化してもよい。スマートコントラクトのインスタンスは、新しいミステリボックスのアイテムまたはアイテムの層、それぞれのアイテム（またはアイテムの層）のオッズ、ミステリボックス内のアイテム（またはミステリボックスに含まれ得る交換アイテム）のそれぞれのトークン識別子、およびミステリボックスをプレイするための価格を定義し得る。ミステリボックスにおいてアイテムが交換されない実施形態では、スマートコントラクトは、特定のアイテムが枯渇したときにアイテムの確率またはゲームの価格が調整され得る方法をさらに定義し得る。例えば、ミステリボックス内の最も価値の高いアイテムが獲得された場合、ゲームをプレイするための価格が下げられてよく、及び／又は残りのアイテムの獲得確率が調整されてよい。

【0190】

ミステリボックスシステム806は、様々な異なるマナーでミステリボックスゲームを提供してもよい。実施形態では、ミステリボックスシステム806は、トークン化プラットフォーム100を介してミステリボックスゲームを提供してもよく、それによって、トークン化プラットフォーム100のユーザは、トークン化プラットフォーム100によって提供されるウェブサイトまたはアプリケーション上でミステリボックスゲームをプレイすることができる。加えて、または代替的に、ミステリボックスシステム806は、サードパーティのウェブサイトまたはアプリケーションを介して、ミステリボックスゲームをユーザに提供してもよい。これらの実施形態では、サードパーティのウェブサイトまたはアプリケーションは、トークン化プラットフォーム100のAPIシステム108を介してミステリボックスシステム806にアクセスしてもよい。

【0191】

いくつかの実施形態では、ミステリボックスシステム806は、カジノスタイルの機械をサポートしてもよく、それによってプレイヤーは、例えば、カジノ又は任意の他の適切な実店舗の場所にある物理的な機械でミステリボックスゲームをプレイすることができる。これらの実施形態において、アイテムは、物理的デバイスが配置される実店舗に配置されてもよく、それによって、プレイヤーがミステリボックスからアイテムを獲得すると、プレイヤーは、実店舗でトークンを交換することができる。これらの実施形態では、トークン化プラットフォーム100は、実店舗でプレイされるミステリボックスゲームをサポートするミステリボックスシステム806を含む。これらの実施形態では、ミステリボックスシステム806は、ネットワーク接続された物理ゲームデバイスがトークン化プラットフォーム100と通信することを可能にするAPIを提供してもよい。ミステリボックスシステム806は、APIシステム108を介して物理ゲームデバイスにミステリボックスゲームを提供してもよい。実施形態において、ミステリボックスシステム806は、物理的ゲームデバイスが、獲得したトークンを示すチケットを印刷し得るように、獲得したチケットのトークン識別子を提供してもよい。いくつかの実施形態では、チケットは、獲得したトークンを示すQRコード（登録商標）を含んでもよい。

【0192】

実施形態では、プレイヤーは、獲得したトークンを示すチケットを実店舗の場所で換金してもよい。これらの実施形態では、実店舗は、チケットを走査し、ウォントークンのトークン識別子をカジノゲームシステムに通信する走査デバイスを含んでもよい。ウォントークンのトークン識別子を受信することに応答して、ミステリボックスシステム806は、プレイヤーに代わってウォントークンを換金してもよく、ウォントークンの換金の検証を走査デバイスに伝達してもよい。次いで、走査デバイスを使用する従業員は、プレイヤーによって獲得されたアイテムをプレイヤーに提供してもよい。あるいは、プレイヤーは、獲得したトークンをプレイヤーのユーザカウントに追加してもよい。これらの実施形態において、プレイヤーは、チケット（例えば、QR-コード（登録商標））をスキャンしてもよい。プレイヤーがチケットをスキャンすることに応答して、ミステリボックスシステム806は、プレイヤーのアカウントへのトークンの譲渡を促進してもよく、それによって、チケットはプレイヤーのデジタルウォレットに表示されてもよい。これが起こると、プレイヤーは、トークンを償還、販売、贈与、担保、または他の方法で取引することができる。

【0193】

実施形態では、トークン化プラットフォーム100は、ビデオゲーム統合システム808を含む。ビデオゲーム統合システム808は、ビデオゲームをプレイするゲームがビデオゲーム内のトークンを見つける、買う、取引する、または他の方法で相互作用することができるように、ビデオゲームメーカーがビデオゲームにトークンを配置することを可能にする。実施形態では、ビデオゲームメーカーは、ビデオゲームのインスタンスがトークン化プラットフォーム100から特定のトークンまたはトークンのタイプを要求し得るように、APIシステム108を介してトークン化プラットフォーム100のAPIにアクセスし得る。要求に応答して、ビデオゲーム統合システム808は、ビデオゲームのインスタンスにトークンを提供してもよい。トークンは、代替性であってもよいし、非代替性であってもよい。後者の場合、トークンは、複数のビデオゲームによって取得、購入、または他の方法で取引されてもよい。非代替性トークンの場合、トークンのために取引する最初のユーザは、トークンの所有者である。ユーザがトークンのために取引することに応答して、ビデオゲーム統合システム808は、トークンの新しい所有権を反映するために分散台帳を更新してもよい。

【0194】

いくつかの例示的な実施形態では、ビデオゲームメーカーは、第三者がビデオゲーム内で販売するアイテムを広告することを許可することができ、それによってユーザは、アイテムに対応するトークンを表すビデオゲーム内に表示されるアイコン（または他の視覚的指標）を選択することによってアイテムを購入することができる。例えば、宅配ピザチェーンの広告主は、特定の場所にいるユーザに宅配ピザを提供したいと思うかもしれません。この例では、ビデオゲームのインスタンスは、ビデオゲーム統合システム808から食品関連トークンを要求してもよく、それによって、各要求は、ビデオゲームのそれぞれのインスタンスを実行するデバイスの位置を示す。ビデオゲーム統合システム808は、ビデオゲームのそれぞれのインスタンスが実行されている場所に配達することができる食品アイテムに対応するトークンを識別してもよい。例えば、ビデオゲーム統合システム808は、要求で示された場所を含む配達半径を示す関連するメタデータを有するトークンを識別してもよい。要求に応答して、ビデオゲーム統合システム808は、識別されたトークンをビデオゲームの要求インスタンスに提供する。その後、トークンを表す視覚的指標がビデオゲームのインスタンスによって表示され、それによって、ユーザ（すなわち、ビデオゲームプレイヤー）は、トークンを取引することを選択することができる。ユーザがトークンの所有権を取引すると、ビデオゲーム統合システム808は、トークンがユーザによって所有されていることを反映するために、トークンの所有権データを更新する。配送情報又は他の物流情報が必要なシナリオでは、ビデオゲームのインスタンス及び／又はユーザは、取引時にそれらの詳細を提供することができ、又はユーザは、取引を完了するために必要な情報を提供することができる。例えば、ユーザが宅配ピザチェーンからピザトークンを購入することを選択した場合、ビデオゲームのインスタンス及び／又はユーザは、ピザが配達される場所の住所を提供することができる。ユーザは、ビデオゲームのインスタンスを介して、ピザのトッピングなどの詳細も提供することができる。

【0195】

いくつかの例示的な実施形態では、ビデオゲームメーカーは、トークンによって表されるアイテムを、ビデオゲームのデジタル環境において使用することと、「現実の」において償還することの両方を可能にすることができる。これらの実施形態では、ビデオゲームメーカーは、ビデオゲームに特定の代替性または非代替性トークンを含めることができ、それによって、ユーザは、ビデオゲームに現れるトークンを見つける、買う、交換する、または他の方法で取引することができる。ビデオゲームに現れるトークンが取引されると、ビデオゲーム統合システム808は、ユーザがトークンの所有者であることを反映するために、取引されたトークンの所有権データを更新することができる。トークンの視覚的インジケーションは、ユーザに対応するビデオゲームインスタンスおよび／またはユーザのデジタルウォレットに表示されてもよい。ユーザがトークンを所有すると、ユーザはビデオゲームでトークンを使用することができ、その後、トークンを換金して、トークンで表される物理的なアイテムを受け取ることができる。例えば、ロールプレイングゲームでは、トークンは、ビデオゲームのプレイヤーに特別な力（例えば、透明化）を与える一対のイヤリングを表すことができる。ユーザは、ゲーム内でイヤリングを使用して特別な力を享受することも、イヤリングと交換することもできる。後者のシナリオでは、イヤリングは、ユーザによって物理的に着用され得るが、ビデオゲームにおいてもはや使用することができないように、ユーザに出荷されてもよい。これらの実施形態のいくつかにおいて、ビデオゲームメーカーは、ユーザがトークンを取引することを許可してもよい。例えば、トークンの所有者は、トークンを別のアイテムに対応するトークンと取引又は売却してもよい。所有権が変更されるたびに、ビデオゲーム統合システム808は、所有権の変更を反映するために分散台帳を更新してもよい。ユーザがトークンを所有しなくなると、ユーザは、トークンによって示されるアイテムを使用または交換することができなくなる。いくつかの実施形態では、ビデオゲームは、ユーザがアイテムを認証された場所（例えば、保管倉庫）に返却することを許可してもよく、それによって、アイテムが認証されると、ユーザはその後、ビデオゲームにおいてアイテムのデジタル表現を再び使用することができる。

【0196】

ビデオゲーム統合システム808は、ビデオゲームメーカーが追加的または代替的な方法でトークンをビデオゲームに統合することを可能にし得る。例えば、ビデオゲームメーカーは、トークンを「イースターエッグ」またはプレイヤーがトークンを発見するときに獲得することができる賞品として使用することができる。別の例では、ビデオゲームメーカーは、ビデオゲームに1つまたは複数のミステリボックスを組み込んでもよい。別の例では、ユーザは、ビデオゲームの構成内でデジタルアイテムを作成し、デジタルアイテムをトークン化して取引（取引、贈与、販売など）することができる。

【0197】

実施形態では、トークン化プラットフォーム100は、ユーザ獲得システム810を含む。実施形態において、ユーザ獲得システム810は、トークン化プラットフォームのプロモーション、特に、新規ユーザの加入を促進するメカニズムを提供する。いくつかの実施形態では、ユーザ獲得システム810は、各既存ユーザに、それぞれの各ユーザが友人、ソーシャルメディアのフォロワー、連絡先などと共有することができる一意の紹介コードを提供する。さらに、ユーザ獲得システム810は、各既存ユーザにインセンティブを提供してもよく、それによって、インセンティブは、アカウントにサインアップする各新規ユーザ又はユーザ数（例えば、３人のユーザ）に対する報酬を示す。インセンティブは、通貨（例えば、従来の通貨又は暗号通貨）、ギフトカード、物理的アイテム、デジタルアイテムなどを含む、任意の形態の支払いであってよい。いくつかの実施形態では、報奨は、トークン化されたトークンとして提供され、それによって、トークン化されたトークンは、設定された額の通貨を表す。実施形態において、ユーザ獲得システム810は、異なるユーザに対して異なるインセンティブを提供してもよい。いくつかの実施形態では、インセンティブは、それぞれのユーザの潜在的なリーチに基づいて決定されてもよい。例えば、大きなリーチを有するユーザ（例えば、ソーシャルメディアの影響力、有名人など）は、比較的小さなリーチを有するユーザよりも大きなインセンティブを与えられてもよい。いくつかの実施形態では、インセンティブは、それぞれの各ユーザの関心に基づいて決定されてもよい。例えば、ゴルフに関心のある第1のユーザにはゴルフ関連のアイテム又は商品券でインセンティブを与え、芸術に関心のある第2のユーザには芸術関連のアイテム又は商品券でインセンティブを与えてもよい。いくつかの実施形態では、ユーザ獲得システム810は、各ユーザのインセンティブをスマートコントラクトのそれぞれのインスタンスでコード化する。これらの実施形態のいくつかでは、ユーザのインセンティブ／報酬を支配するスマートコントラクトのインスタンスは、ユーザの紹介コード及び／又はユーザのパブリックアドレスに関連付けられる。ユーザの紹介コードが新しいアカウントを登録するために成功裏に使用されるとき、スマートコントラクトは、報酬を表すトークンの紹介ユーザのアカウントへの譲渡を促進することができる。

【0198】

新しいユーザが紹介コードを使用してアカウントにエンリストするたびに、ユーザ獲得システム810は、新しいユーザが正当であるかどうか（例えば、ホットではない、不正なアカウントではない、など）を判断する。新規ユーザがアカウントを付与される（例えば、検出された不正行為がない）と仮定して、ユーザ獲得システム810は、紹介コードに関連するユーザカウントを決定する。いくつかの実施形態では、ユーザ獲得システム810は、ユーザカウント及び／又は紹介コードに関連するスマートコントラクトを決定する。ユーザ獲得システム810は、ユーザカウント及び／又は紹介コードに関連付けられたスマートコントラクトに、新しいアカウントの通知を提供してもよい。次いで、スマートコントラクトは、報酬を表すトークンの、ユーザのアカウントへの譲渡を開始してもよい。

【0199】

実施形態では、ユーザ獲得システム810は、第三者顧客に対してこれらのサービスを実行してもよい。これらの実施形態では、第三者顧客は、信頼できる第三者ホルダ（例えば、トークン化プラットフォームまたは別の信頼できるホルダ）に報酬（例えば、現金、暗号通貨、ギフトカード、物理アイテムなど）を提供してもよい。その後、報酬はトークン化され、エスクローで保持されてもよい。第三者は、報酬を支配するパラメータ（例えば、付与するインセンティブの額、誰がプロモーターであり得るか、など）をさらに定義してもよい。ユーザ獲得システム810は、第三者の顧客に代わってスマートコントラクトを生成してもよい。ユーザが紹介コードを要求すると、ユーザ獲得システム810は、顧客に代わってスマートコントラクトのインスタンスを生成してもよく、スマートコントラクトのインスタンスをユーザのアカウントと関連付けてもよい。ユーザが紹介コードを使用して買い手を顧客に紹介することに成功すると、ユーザ獲得システム810（及び／又はスマートコントラクトのインスタンス）は、報酬を表すトークンを紹介したユーザのアカウントに譲渡してもよい。

【0200】

いくつかの実施形態をさらに詳細に説明するために、次に、電子商取引システム、例えばプラットフォーム100によって、又はそれに関連して実行され得る技法の例を参照する。方法は、図９の方法900、図１０の方法1000、図１１の方法1100、図１２の方法1200、図１３の方法1300、図１４の方法1400、図１５の方法1500、図１６の方法1600、図１７の方法1700、図１８の方法1800、および図１９の方法1900を含んでいる。方法900、方法1000、方法1100、方法1200、方法1300、方法1400、方法1500、方法1600、方法1700、方法1800、及び方法1900は、本明細書に記載のシステム、ハードウェア、及びソフトウェアなどの計算デバイスを用いて実行することが可能である。方法900、方法1000、方法1100、方法1200、方法1300、方法1400、方法1500、方法1600、方法1700、方法1800、及び方法1900は、例えば、機械可読プログラム又は他のコンピュータ実行可能命令、例えばルーチン、命令、プログラム、又は他のコードを実行することによって実行することが可能である。方法900、方法1000、方法1100、方法1200、方法1300、方法1400、方法1500、方法1600、方法1700、方法1800、及び方法1900のステップ、又は動作、又は本明細書に開示される実施形態に関連して説明される別の技法、方法、プロセス、若しくはアルゴリズムは、ハードウェア、ファームウェア、ハードウェア、回路、又はその組み合わせで直接実装することが可能である。説明を簡単にするために、方法900、方法1000、方法1100、方法1200、方法1300、方法1400、方法1500、方法1600、方法1700、方法1800、および／または方法1900はそれぞれ、一連のステップまたは動作として本明細書に描かれ説明される。しかしながら、本開示に従ったステップ又は動作は、様々な順序で、及び／又は同時に発生することができる。さらに、本明細書で提示及び説明されていない他のステップ又は動作が使用されてもよい。さらに、開示された主題に従った技術を実施するために、すべての図示されたステップまたは動作が必要とされるとは限らない。

【0201】

図９は、本開示のいくつかの実施形態によるアイテムをトークン化するための方法900を示すフローチャートである。9002で、アイテム情報が取得される。アイテム情報は、アイテムの一意のユニットに対する一意の識別子と、アイテム属性のセットとを含んでもよい。実施形態において、トークン化プラットフォームの処理システムは、情報を取得する。

【0202】

904で、１つまたは複数のデジタルトークンが生成される。実施形態では、デジタルトークンは、一意のデジタルトークンである。それぞれの一意のデジタルトークンは、アイテム属性のセットに対応するデジタル属性のセットを含んでもよい。実施形態では、N個のデジタルトークンが生成され、アイテムまたはその仮想表現にリンクされる。実施形態では、トークン生成システムが、１つまたは複数のデジタルトークンを生成する。

【0203】

906で、デジタルトークンは、アイテム情報に結合される。実施形態では、暗号化リンクは、デジタルトークンがアイテムの表現を提供するように、デジタルトークンをアイテム情報に結合させる。例えば、デジタルトークン及びアイテムは、一意のデジタルトークン及びアイテムの一意のユニットの一意の識別子が、アイテムの一意のユニットの一意のデジタル表現を提供するために暗号的に連結されるように、一意であってよい。実施形態では、トークン生成システム302のモジュールなどのリンクシステムが、デジタルトークンをアイテム情報に結合させる。

【0204】

実施形態では、トークンは、（例えば、資金額を表すトークンを生成する場合）トークン化されてもよい。例えば、アイテム情報は、プラットフォーム100内の資金であっても、サードパーティソースからの資金であってもよい。トークン化されたトークンは、資金の受領の検証に応答して生成され得、資金は、ユーザによる取引から保持され得る。いくつかの実施形態では、資金は、公にユーザに帰属したままであり、台帳は、プラットフォーム100による承認なしにトークン化された資金のユーザによる取引を防止するために、資金に対して記録された保留または先取特権で更新される。いくつかの実施形態では、台帳は、ユーザからプラットフォーム100への資金の譲渡を反映するように更新される。有益なことに、譲渡された資金は、プラットフォーム100によって取引可能であってもよく（例えば、第三者との預託又は投資のために）、トークン化されたトークンは、預託された資金がプラットフォーム100と第三者の間の経済取引に参加できる一方で、トークン化されたトークンがプラットフォーム100内の取引によって使用され得るように、換金された資金がもともとトークン化された資金ではない場合でも元の資金の相当額に交換することが可能である。

【0205】

図１０は、本開示のいくつかの実施形態による、デジタル市場を使用してトークンを譲渡するための技術1000を示すフローチャートである。1002において、台帳が維持される。台帳は、複数のパブリックアドレスと、複数のそれぞれのアイテムの複数の仮想表現と、それぞれの仮想表現について、トークンのセットと、それぞれのトークンの所有権データとを格納する。トークンのセットは、それぞれ、仮想表現によって表されるアイテムのそれぞれのインスタンスに対応する。さらに、それぞれのパブリックアドレスは、トークン化プラットフォームのそれぞれのユーザのそれぞれのアカウントに対応する。

【0206】

1004で、デジタル市場が提供される。実施形態では、デジタル市場は、消費者が、アイテムの仮想表現を含むアイテムの仮想表現の視覚化を閲覧し、N個のデジタルトークンを購入することによってアイテムのインスタンスのために取引することを可能にするグラフィカルユーザインターフェースを提供する。ユーザがトークンを購入すると、台帳は、トークンの販売者からユーザへのトークンの所有権の変更を反映するように更新されてもよい。ユーザがトークンを所有すると、ユーザは、トークンを他のユーザに譲渡すること、トークンを売却すること、トークンを担保として使用すること、および／またはトークンを償還することが許可されてもよい。

【0207】

1006において、トークンの償還を要求するユーザに応答して、償還が処理される。実施形態において、償還は、仮想表現に対応する特定のトークンを取引するユーザのアカウントに関連付けることによって開始されてもよい。関連付けは、取引への参加要求を検証することに応答して行われてもよい。特定のトークンを譲受人に譲渡することを要求する譲渡要求を受信する。譲渡要求は、特定トークンを識別するデジタルトークン識別子と、異なるユーザのパブリックアドレスとを含む。さらに、特定トークンは、検証される。検証は、デジタルトークン識別子と台帳とに基づき行うことができる。その際、プラットフォーム100上の譲受人のアカウントは、ユーザのパブリックアドレスと台帳とに基づいて、検証及び／又は妥当性確認されてもよい。さらに、台帳は、所有権データを含み、仮想表現に対応する特定のトークンが取引を行うユーザによって所有されていることを示すブロックで更新される。実施形態において、更新は、特定のトークンを検証することと、譲受人を検証することの両方に応答して起こる。さらに、譲受人のユーザデバイスからデジタルトークンを換金するための換金要求が受信され、トークンに対応するアイテムのインスタンスのための取引を満たすためにワークフローが実行される。ワークフローは、償還要求の受信に応答して開始されてもよい。

【0208】

図１１は、本開示のいくつかの実施形態による、キーボード対話を介してウォレット間でトークンを譲渡するための技法1100を示すフローチャートである。1102で、1つまたは複数のウォレットが表示される。つまたは複数のウォレットの表示は、例えば、デジタルウォレットに関連付けられたユーザのユーザデバイスを介してデジタルウォレットのグラフィカルユーザインターフェースを表示することを含んでもよい。さらに、ユーザによって所有されているトークンのインベントリが、デジタルウォレットのグラフィカルユーザインターフェースによって表示されてもよい。実施形態において、各トークンは、それぞれのアイテムに対応し、それぞれのアイテムのインスタンスのための取引を満たすために、ユーザによって交換可能であってもよい。

【0209】

1104で、譲渡命令が受信される。譲渡命令は、トークンのインベントリからの1つまたは複数のデジタルトークンの指示と、デジタルトークンの受信者とを含むことができる。譲渡命令は、デジタルウォレットのグラフィカルユーザインターフェースによって受信され得る。

【0210】

1106で、デジタルトークンは、キーボードの相互作用（対話）に応答して譲渡される。実施形態において、デジタルキーボードは、デジタルウォレットのグラフィカルユーザインターフェースによって表示される。デジタルキーボードは、譲渡要求内のデジタルトークンに対応する項目を代表する、選択可能なメディアコンテンツを含む。デジタルキーボードによる選択可能なメディアコンテンツの選択を含むテキストベースのメッセージを生成するユーザ入力が受信される。例えば、ユーザは、譲渡を取り巻くメッセージ（例えば、「私からのこの贈り物を楽しんでください」）を入力し、次に、トークンを表す選択可能なメディアコンテンツ（例えば、トークンで表されるアイテムの画像）を選択して、そこに埋め込まれたトークンを有するメッセージを作成することができる。選択可能なメディアコンテンツは、デジタルトークン／デジタルトークンの識別子（例えば、デジタルトークンを一意に識別するハッシュ値）を含む。デジタルトークン（例えば、その識別子）は、デジタルキーボードによってテキストベースのメッセージ内に埋め込まれ、デジタルウォレットは、テキストベースのメッセージを受信者のメッセージ・アカウントに送信する。受信すると、受信者が選択可能なメディアコンテンツを選択することに応答して、デジタルトークンは受信者のそれぞれのデジタルウォレットに受け入れられる。

【0211】

図１２は、本開示のいくつかの実施形態による、トークンを換金するための手法1200を示すフローチャートである。1202で、台帳データが維持される。台帳データは、複数のパブリックアドレスと、複数の仮想表現と、複数の仮想表現のそれぞれのためのトークンのセットと、トークンのセットのそれぞれのための所有権データとを含み得る。それぞれのパブリックアドレスは、トークン化プラットフォームのそれぞれのユーザのそれぞれのアカウントに対応する。仮想表現は、それぞれのアイテムに対応し、トークンの集合は、それぞれの仮想表現について、それぞれのアイテムのそれぞれのインスタンスにそれぞれ対応する。

【0212】

1204で、償還要求が受信される。償還要求は、ユーザのユーザデバイスからデジタルトークンを償還しようとするものであり、デジタルトークンは、償還されるアイテムのインスタンスに対応するものである。1206において、ユーザによるデジタルトークンの所有権が検証される。検証は、複数のパブリックアドレス、デジタルトークンのセット、及び償還要求に基づいて行われ得る。例えば、償還要求は、トークン識別子によって示されるトークンを償還することを希望するユーザのユーザIDを含んでもよい。プラットフォーム100は、台帳データが、償還要求で示されたトークン識別子と償還要求で示されたユーザのパブリックアドレスとをリンクしていることを確認することによって、トークンの所有権を検証してもよい。その場合、デジタルトークンの所有権が検証される。

【0213】

1208において、フルフィルメント及び／又は配送のための詳細が、プラットフォーム100によって管理される。いくつかの実施形態では、プラットフォーム100は、（例えば、グラフィカルユーザインターフェースを介して）配信の詳細を提供するようにユーザを促してもよい。これに応答して、プラットフォーム100は、ユーザデバイスを介してユーザから配達の詳細を受信してもよい。次いで、配信の詳細は、償還されたトークンの配信を開始する配信システムに出力されてもよい。例えば、ユーザは、物理的な住所及び他の関連する配送データ（例えば、配送に最適な時間帯又は電話番号）を提供してもよい。この場合、配送システムは、提供された住所を使用して、償還されたトークンで表される物品の配送を開始することができる。別の例では、トークンは、デジタルアイテムを表すことができる。このような場合、ユーザは、デジタルアイテム（またはそれへのリンク）が配信され得る電子メールアドレスまたは他のアカウントデータを提供してもよい。いくつかの実施形態では、プラットフォーム100は、ユーザがトークンの所有者であることを確認することに応答して、フルフィルメントの詳細を要求してもよい。フルフィルメントの詳細は、トークンが取引された時点では提供されなかった、アイテムのための取引を満たすために必要な情報を含む。例えば、履行詳細は、アイテムの構成材料、サイズ、色、それらの組み合わせなどを含むことができる。フルフィルメントの詳細は、ユーザのユーザデバイスから受信され、フルフィルメントシステムに出力されてもよい。フルフィルメントシステムは、フルフィルメント詳細を満足するアイテムの配送を開始してもよい。

【0214】

図１３は、本開示のいくつかの実施形態による担保化および／または証券化のための手法1300を示すフローチャートである。1302において、アイテム変換要求が受信される。実施形態において、アイテムは有形物である。他の実施形態では、アイテムは、他の形態の担保である。1304において、アイテム情報が受信される。アイテム情報は、アイテムの評価を決定する際に必要とされる又は役立つ情報を含んでもよい。例えば、アイテム情報は、アイテムの1つ以上の写真、アイテムの説明、アイテムの評価額、及び／又はアイテムの保有場所を含んでもよい。

【0215】

1306において、アイテム情報に基づいて担保アイテムの仮想表現が生成される。1308において、１つ以上のトークンが、仮想表現に基づいて生成される。1310において、デジタルトークンの所有権が割り当てられる。当初、デジタルトークンの所有権は、デジタルトークンによって表される担保アイテムの所有者に割り当てられる。1312で、アイテムによって担保される契約が、記念される。実施形態において、アイテムは、プロバイダによってユーザのためにサービスを提供する契約の担保として使用される資産である。実施形態において、サービスを支配するスマートコントラクトのインスタンスが生成される。スマートコントラクトは、ユーザがプロバイダに提供すべき額と、デジタルトークンの所有権をプロバイダに譲渡させる１つ以上の条件とを示す。その後、スマートコントラクトのインスタンスは、処理システムによってデプロイされてもよい。実施形態では、アイテムは、ローン担保として使用される担保可能なアイテムである。貸し手によって定義された金額の資金をユーザにローンする合意が、処理システムによって受け取られる。ローンを支配するスマートコントラクトのインスタンスが、処理システムによって生成される。スマートコントラクトのインスタンスは、ユーザが貸し手に返済すべき金額と、トークンの所有権が貸し手に譲渡する原因となる１つ以上の条件（例えば、デフォルト条件）とを示す。その後、スマートコントラクトのインスタンスは、処理システムによってデプロイされる。いくつかの実施形態では、ローンが支払われるまでレンダーがトークンを償還または譲渡できないように、トークンはエスクローに置かれ得る。これらの実施形態において、スマートコントラクトは、トークンがレンダーイーに戻される（例えば、支払いが完了したとき）ことになる条件を定義してもよい。

【0216】

図１４は、本開示のいくつかの実施形態によるアイテム認証のための技術1400を示すフローチャートである。1402で、トークン化要求がユーザデバイスから受信される。1404で、アイテム情報が受信される。いくつかの実施形態では、アイテム情報は、ユーザによって、または自動化されたプロセスを介して提供され得る。1406で、アイテムの仮想表現が生成される。

【0217】

1408において、アイテムの真正性は、適切な認証プロセスを通じて決定される。実施形態において、アイテムの認証は、主題の認証専門家がアクセス可能なポータルを介して要求されてもよい。これらの実施形態では、ポータルは、アイテムの仮想表現をさらに表示してもよい。例えば、主題の専門家は、アイテムの画像、アイテムの説明（例えば、重額、寸法など）、アイテムのビデオ、および／または同様のものを提示されてもよい。その後、処理システムによって認証リポートが受信されてもよい。認証リポートは、主題の認証専門家により提供されてもよく、主題の認証専門家がアイテムを真正または非真正とみなしたかどうかを示す見解と、その見解の１つまたは複数の理由とを含んでもよい。いくつかの実施形態では、プラットフォームは、アイテムが真正とみなされることを示す見解に応答してデジタルトークンを生成し、デジタルトークンの所有権をアイテムの所有者に割り当ててもよい。デジタルトークンは、アイテムの仮想表現に基づいてもよい。

【0218】

図１５は、VR環境をレンダリングするための技術1500を示すフローチャートである。レガーデータは、1502において、上述したような適切なプロセスを用いて維持される。1504で、環境がレンダリングされる。実施形態では、仮想現実ストア環境がレンダリングされ、これは、ユーザが利用可能なアイテムの仮想現実ビジュアリゼーションを見ることができ、利用可能なアイテムのインスタンスに対して取引を行うことができるインターフェースを提供するものである。利用可能なアイテムは、取引のために利用可能であるアイテムである。さらに、仮想表現によって表されるアイテムの仮想現実ビジュアリゼーションも、仮想現実ストア環境内に含まれ得る。1506において、仮想環境内のアイテムは、適切な処理によって取引される。例えば、アイテムのインスタンスに対する取引に参加するための要求は、取引するユーザのユーザデバイスからプラットフォーム100によって受信される。実施形態において、取引に参加するための要求は、取引するユーザが仮想現実ストア環境においてアイテムの仮想現実表現を見ることに応答して受信される。要求に関連付けられた情報は検証されてもよく、仮想表現に対応する特定のトークンは、取引に参加する要求を検証することに応答して、取引するユーザのアカウントに関連付けられる。

【0219】

図１６は、本開示のいくつかの実施形態による、ブロックのサイドチェーンを有する分散台帳を使用して取引を促進するための技術1600を示すフローチャートである。

【0220】

1602で、台帳が維持される。台帳は、ブロックのメインチェーンと、ブロックのサイドチェーンとを含む。実施形態において、メインチェーンのブロックは、アイテムプロバイダ及びアイテム消費者の両方を含む複数のユーザに関連する情報をまとめて格納する。複数のユーザに関連する情報は、複数のパブリックアドレスを含み、それぞれのパブリックアドレスは、トークン化プラットフォームのそれぞれのユーザのそれぞれのアカウントに対応する。サイドチェーンのブロックは、複数のそれぞれのアイテムの複数の仮想表現と、それぞれの仮想表現に対するトークンのセットと、それぞれのトークンの所有権データとを集合的に格納する。各仮想表現は、それぞれのアイテムの仮想現実視覚化をレンダリングするための仮想現実コンテンツを含み、トークンの各セットは、それぞれ、仮想表現によって表されるアイテムのそれぞれのインスタンスに対応する。

【0221】

1604で、上述したような適切なプロセスを通じて、取引要求が受信される。1606において、アイテムの取引が発生する。実施形態では、ブロックの第1の側鎖における仮想表現に対応する特定のトークンの所有権データは、取引するユーザが特定のトークンを所有していることを示すように更新される。実施形態において、アイテムの取引は、デジタルトークン識別子および第1のブロックチェーンに基づいて特定トークンを検証することと、ユーザのパブリックアドレスおよび主ブロックチェーンに基づいて異なるユーザがトークン化プラットフォーム上に有効なアカウントを有することを検証することと、特定トークンを検証し、異なるユーザを検証することに応答して、第2のブロックチェーンを新しいブロックに更新することとを含む。新しいブロックは、仮想表現に対応する特定のトークンが異なるユーザによって所有されていることを示す所有権データを含む。

【0222】

図１７は、本開示のいくつかの実施形態による、ユーザ獲得を促進するための技法1700を示すフローチャートである。1702において、トークン化プラットフォームのユーザに対応する紹介コードが生成される。紹介コードは、トークン化プラットフォームの処理システムによって生成されてもよい。1704で、トークン化プラットフォームのユーザに対応するスマートコントラクトのインスタンスが生成される。スマートコントラクトのインスタンスは、トークン化プラットフォームによって生成されてもよい。スマートコントラクトのインスタンスは、ユーザがトークン化プラットフォームの参照に成功したときにユーザに提供されるインセンティブを示す。1706で、スマートコントラクトのインスタンスは、処理システムによってデプロイされる。1708において、新しいアカウントを作成するための要求が、処理システムによって新しいユーザから受信される。リクエストは、ユーザの紹介コードを含む。1710において、処理システムによって、新しいアカウントが新しいユーザに対して作成される。1712で、処理システムは、ユーザに対応するスマートコントラクトのインスタンスに、新しいアカウントの通知を提供する。次いで、スマートコントラクトは、通知に応答して、インセンティブを表すトークンの譲渡を促進する。

【0223】

図18は、本開示のいくつかの実施形態によるミステリボックスを管理するための技法1800を示すフローチャートである。1802で、ミステリボックスを作成するための要求が処理システムによって受信される。1804で、ミステリボックスに含まれるべきトークンのセットが、処理システムによって受信される。トークンのセット内の各トークンは、それぞれのアイテムを表し、それに割り当てられた確率を有する。確率は、それぞれのアイテムを獲得する確率を示す。

【0224】

1806で、ミステリボックスは、トークンのセットとそれに割り当てられた確率に基づいて処理システムによって生成される。トークンのセット内の各トークンは、値の間隔に関する値の範囲がトークンに割り当てられた確率に比例するように、値の間隔内の値の範囲が割り当てられる。

【0225】

1808で、スマートコントラクトのインスタンスが処理システムによって生成される。スマートコントラクトは、ミステリボックスに関連付けられ、ミステリボックスをサポートするトークンのセットからのトークンの譲渡を支配する。1810において、スマートコントラクトのインスタンスは、処理システムによってデプロイされる。

【0226】

図１９は、本開示のいくつかの実施形態によるビデオゲーム統合のための技術1900を示すフローチャートである。1902で、利用可能なトークンのインベントリが維持される。利用可能なトークンは、ビデオゲームに統合するために利用可能である。トークンのインベントリ内の各トークンは、それぞれのアイテムを表す。1904において、デジタルトークンのためのトークン要求が処理システムによって受信される。デジタルトークンは、APIを介してビデオゲームのインスタンスからである。1906において、処理システムは、トークン要求に基づいて、利用可能なトークンのインベントリからデジタルトークンを選択する。1908において、トークンのインジケータが、処理システムによってビデオゲームのインスタンスに提供される。1910で、処理システムは、ビデオゲームのインスタンスから取引要求を受信する。取引要求は、ビデオゲームのインスタンスに提供されたトークンの、ビデオゲームのインスタンスのユーザのアカウントへの譲渡を要求するように構成される。1912において、台帳は、ユーザがトークンの所有者であることを反映するように更新される。

【0227】

図２０は、証券化された分散型ローンプロセス（「分散型ローンプロセス」、「証券化ローンプロセス」、または「ローンプロセス」とも呼ばれる）を促進するための例示的なエコシステム2000を示す図である。）証券化された分散型ローンプロセスは、一連の参加者の間で分散されるプロセスを指し得る（例えば。対コンピューティングシステム100、2014およびデバイス2002、2004、2006、2008、2010）および分散台帳2016のセット上でホストされるスマートコントラクトのセットであって、借り手が無信託または実質的に無信託の方法で1つまたは複数の物理アイテムを担保することができ、貸し手が（例えば、担保アイテムを個人的に認証、鑑定、安全保管、および／または清算しなくても）無信託または実質的に無信託の方法で借り手にお金をローンする権限を有するような、分散台帳のセット。特に、開示されたエコシステムとそれをサポートするシステムおよび方法は、デジタル担保トークン2042がスマートコントラクトを使用して貸し手からのローンを確保するために使用され得るように、借り手が物理アイテムをデジタル担保トークン2042にデジタル化することを可能にする機構を提供する。実施形態において、分散型ローンプロセスのステージは、以下のうちの1つまたは複数を含み得る。借り手がローンプロセスを行うことを要求する要求ステージ、担保アイテムが1つ以上の認証者によって認証される認証ステージ、担保アイテムが1つ以上の鑑定者によって鑑定される鑑定ステージ、ローンプロセスのインスタンスが終了するまで担保アイテムが保管者に預けられる保管ステージ、担保アイテムに対応するVIRLが生成される仮想化ステージ、VIRLが担保トークン2042にトークン化されるトークン化ステージ。借り手がローンを要求し、かつ／または1つ以上の潜在的な貸し手とローンの条件を交渉し、借り手および貸し手が取引の条件に合意し、ローンプロセスが完了するまで担保トークンをエスクローアカウントにロックすることで終了するローン要求ステージ、ローンが借り手によって返済されるかまたはデフォルトになるローン返済ステージ及び、ローンが正常に返済された場合には担保トークン2042が借り手に戻され、借り手がデフォルトした場合には買い手に清算され、担保トークンが金庫から担保アイテムと交換され、及び／又は任意のローン後分析が行われるローン後のステージである。

【0228】

いくつかの例示的な実施形態では、トークン化プラットフォーム100は、証券化された分散型ローンプロセスをサポートする。これらの例示的な実施形態では、市場システム102、台帳管理システム104、担保管理システム802、認証システム804、及びアナリティクス及びリポートシステム112は、ノードデバイス2014のセットによってホストされる分散台帳2016のセットに対する分散ローンプロセスを促進する際に、ユーザデバイス（例えば、借り手デバイス2002、認証者デバイス2004、鑑定者デバイス2006、保管者デバイス2008、及び／又は貸し手デバイス2010）のセットとインターフェースするように構成されてもよい。実施形態において、証券化分散型ローンエコシステム2000は、証券化分散型ローンプロセスの異なるステージに参加する多数の異なる参加者を含む。いくつかの実施形態では、ローンの参加者は、物理的担保アイテムを使用してローンを得ようとする借り手、物理的担保アイテムを認証する認証者、物理的担保アイテムを鑑定する鑑定者、物理的担保アイテムを安全に保管する保管者、借り手に通貨を貸す貸し手、ならびに分散台帳エコシステムをサポートする他の適切な参加者（例えば、「マイナー」及び／又は分散台帳ノードデバイス2014）を含みうる。議論されるように、いくつかのタイプの参加者は、認証、鑑定、および保管などの特定のステージに関連する主題専門知識を有するエンティティ（例えば、個人および／または企業）のグループであるギルドに組織化されてもよい。証券化分散型エコシステム2000の参加者は、ラップトップコンピュータ、デスクトップコンピュータ、タブレット、ビデオゲームコンソール、サーバコンピュータ、および／または同様のものなどの様々なコンピューティングデバイスを介して、互いにおよび分散台帳（複数可）2106と対話し得ることが理解されよう。説明の便宜上、借り手は借り手デバイス2002を介してエコシステム2000に参加し、認証者は認証者デバイス2004を介してエコシステム2000に参加し、鑑定者は鑑定者デバイス2006を介してエコシステム2000に参加し、保管者は保管者デバイス2008を介してエコシステム2000に参加し、貸し手は貸し手デバイス2010を介してエコシステム2000に参加するなど、様々なものがある。

【0229】

実施形態において、証券化された分散型ローンプロセスは、ノードデバイス2014のネットワークによってホストされる分散台帳2016のセットを使用して少なくとも部分的に実装されてもよく、ノードデバイス2014は、1つまたは複数の担保アイテムの認証、鑑定、および／または証券化を管理する1つまたは複数のスマートコントラクトを含む証券化ローンプロセスに関連して作成されるスマートコントラクトインスタンスを実行する。いくつかの実施形態では、分散型ローンプロセスにおける1つ又は複数のステージは、スマートコントラクトのそれぞれのセットによって管理される。一般に、スマートコントラクトは、実行されると、1つ又は複数のアクションをトリガーする条件ロジックを実行するコンピュータ実行可能コードを含んでもよい。スマートコントラクトは、1つ以上のデータソースからデータを受信してもよく、それにより、条件ロジックは、データを分析して、特定の条件が満たされているかどうかを判断し、満たされている場合、1つ以上のそれぞれのアクションをトリガーする。スマートコントラクトの例は、条件付きロジック及びトリガーアクションの例を含む、本開示全体にわたって議論される。実施形態において、スマートコントラクトは、イーサリアムプロトコル、WAXプロトコルなどの1つまたは複数のプロトコルに従って定義されてもよい。スマートコントラクトは、コンピュータ実行可能コードとして具現化されてもよく、Solidity、Golang、Java、JavaScript、C++などの任意の適切なプログラミング言語で記述されてもよい。証券化された分散型の様々な実施形態に関連して使用され得るスマートコントラクトの様々な例が、本開示を通じて議論される。図20の例示的な実施形態において、分散台帳2016は、以下のインスタンスを格納してもよく、ノードデバイス2014は、以下のインスタンスを実行してもよい。それらは、ローンプロセスのスマートコントラクト2022、ステージレベルガバナンスのスマートコントラクト2024、ギルドガバナンスのスマートコントラクト2026、認証スマートコントラクト2028、鑑定スマートコントラクト2030、保管スマートコントラクト2032、ローンスマートコントラクト2034、及び／又は他の適切なスマートコントラクトである。スマートコントラクトの様々なタイプは、本開示を通じて説明される。

【0230】

実施形態において、分散台帳2016は、分散型ローンプロセスに関連して使用されるトークンを格納してもよく、これには、分散型ローンプロセスに関連して生成され、ローンを確保するために担保として保持される担保トークン2042が含まれるが、これらに限定されない。分散型ローンプロセスに関連して特定のタスクを実行するギルドメンバーによって所有および／または使用されるギルドトークン2044（後述するように、ギルドメンバーによって投票のために使用され得る）、分散型ローンプロセスに関連して利用される通貨／トークン2046（例えば、貸し付け用、返済用、報酬用、ステーキング用など）、および他の適切なトークンを含む。実施形態において、担保トークン2042は、分散型ローンプロセスにおいてローンを証券化するために使用される1つまたは複数のそれぞれの担保アイテムの物理アイテムの1つまたは複数の仮想表現（VIRL）を包むデジタルトークンであってよい。実施形態において、VIRLは、物理的アイテムに対応し、アイテムの説明、アイテムの写真、アイテムのビデオなどを含むことができる。物理的アイテムの仮想表現（VIRL）は、本開示全体を通じて議論される。実施形態において、担保トークン2042は、担保トークンの所有者が（ローンが返済された後および／または清算イベントの後に担保トークンの所有記録から決定されるように）トークンを償還したときに（上記で議論されたように）、担保トークン2042に関連付けられたスマートコントラクトが担保トークン2042によって表される担保アイテムの保管者に担保アイテムを提供するよう通知を提供してもよいように、スマートコントラクト包みを含んでもよい。保管者が、担保トークン2042の保有者が担保アイテムを所有したことを確認すると、担保トークン2042のスマートコントラクトは、上述のように、償還された担保トークン2042をバンプしてもよい。通貨トークンは、通貨として使用されるデジタルトークンを参照してもよい。通貨トークンの例は、ビットコイントークン、イーサリアムトークン、リップルトークン、ワックストークンなどを含んでもよい。いくつかの実施形態では、トークン化トークンは、通貨額（例えば、通貨トークンおよび／または不換紙幣）を「ラップする（包む）」デジタルトークンを指す。トークン化トークンが作成されると、通貨の額がエスクローで保持され、トークン化トークンは、エスクローされた通貨の額に対する所有権を表し、トークン化トークンの検証済みの所有者がトークン化トークンを償還すると、所有者はエスクローされた通貨の額を所有し得るようにする。通貨トークンとトークン化されたトークンはどちらも通貨の代表であるため、「通貨／トークン化」トークンという用語の使用は、通貨トークン、トークン化トークン、または通貨トークンとトークン化トークンの両方の組み合わせを指す場合がある。

【0231】

実施形態において、分散台帳2016は、イベントレコード2052、所有権データ2054、および／またはサポートデータ2056などの追加のデータを格納してもよい。イベントレコード2052は、分散型ローンプロセスに関連して発生する任意のイベントを記念するレコードを含んでもよい。イベントレコード2052は、以下のようなイベントのレコードを含んでもよい（ただし、これらに限定されない）。ローンプロセスを行うための借り手による要求、割り当てられる認証タスク、完了する認証タスク、割り当てられる評価タスク、完了する評価タスク、割り当てられる保管タスク、完了する保管タスク、借り手によって要求されるローン、貸し手によって受け入れられるローンがある。借り手によって締結されたローン契約に対応してエスクローにロックされた借り手の担保トークンのロック、借り手から貸し手への支払い、借り手の支払い遅延、現在の貸し手から二次貸し手へのローン契約の譲渡、借り手によるローンの不履行と判断される、清算イベントの発生、借り手によるローンの完全な返済。分散型プロセスの参加者に与えられる報酬、清算イベントの後に偽物とみなされるアイテム、清算イベント中に評価額に達しないアイテム、などである。実施形態において、イベント記録は、トークン化プラットフォーム100、借り手デバイス2002、認証者デバイス2004、鑑定者デバイス2006、保管者デバイス2008、貸し手デバイス2010、ノードデバイス2014（例えば、ノードデバイス2014によって実行されるスマートコントラクトによって）、または他の適切なデバイスなど、エコシステム2000内の任意の適切なコンピューティングデバイスによって生成されてもよい。実施形態において、イベントレコード2052は、ハッシュ値を得るために、ハッシュ関数を用いてハッシュ化されてもよい。イベントレコード2052は、データブロックに書き込まれ、分散台帳に格納されてもよく、データブロックは、ハッシュ値を含んでもよい。このようにして、イベントレコード2052のハッシュ値を変更しない限り、イベントレコード2052内のデータを変更することはできず、それによって、イベントレコード2052は不変となる。イベントレコード2052を含むブロックが分散台帳に格納されると、イベントレコード2052は、分散台帳2016に関するブロックのアドレスを用いて参照され得る。

【0232】

実施形態において、サポートデータ2056は、分散型ローンプロセス及び／又は分散型ローンプロセスの参加者に関連して行われるタスク又は他のイベントをサポートするために提供される文書及びデータであってよい。議論されるように、サポートデータ2056は、認証リポート及びサポート写真、ビデオ、スキャン等、鑑定リポート及びサポート写真、ビデオ、スキャン等、保管リポート及びサポート写真、ビデオ、スキャン等、ローン契約の交渉中に交渉イベントを示すローン交渉記録、貸し手による借り手への払い出しイベントに対応する払い出し記録、貸し手による支払いイベントを示す返済記録、デフォルトイベントを示すデフォルト記録、及び／又は他の適切なデータを含んでもよい。

【0233】

実施形態では、所有権データ2054は、トークン（例えば、担保トークン2042、通貨／トークン2046、および／またはギルドトークン2044）をアカウントに関連付けるデータを含んでもよい。実施形態では、所有権データ2054は、データブロックに格納されてもよく、データブロックは、トークンアドレスとアカウントアドレスとの間のリンクを含んでもよい。例えば、ボブが１０個の通貨トークン（例えば、ビットコイン）を所有する場合、各トークンの所有権データ2054は、分散台帳に格納されてもよく、それぞれのトークンをボブに関連するアカウントにリンクしてよい。ボブがそれらのトークン2046の１つを使用してアリスからアイテムを購入する場合、トークンの所有権データ2054は、アイテムを購入するために使用されたトークン2046をアリスのアカウントにリンクさせるために更新され得る。所有権が新しいアカウントに変更されると、トークンを新しいアカウントにリンクさせる新しいブロックが分散台帳2016に修正され得る。実施形態において、トークン（例えば、担保トークン2042および／または通貨／トークン2046）は、ローンプロセスの過程でロックされてもよい。本明細書で使用されるように、トークンを「ロックする」とは、トークンをエスクローアカウントに（例えば、エスクローされたトークンを格納する分散台帳に）格納することを指す場合があり、それによって、トークンに関連するスマートコントラクトがトークンがロックされたことを決定しない限り、エスクローアカウントからロックしたトークンを譲渡することができない。実施形態において、担保トークンは、例えば、借り手および貸し手がローン条件に合意した時点で「ロック」されてもよい。いくつかの実施形態では、参加者（例えば、認証者、鑑定者、および／または保管者）に属する一定額の通貨／トークン2046は、参加者がローンの確保に関連する特定のタスクを実行する際にロックされてもよい（例えば。認証タスク、鑑定タスク、および保管タスク）を実行したときに、参加者が誠実にローンプロセスに参加するインセンティブを提供することができる（例えば、担保アイテムを認証しない側に回る、鑑定の報酬を増やすために担保アイテムを過剰評価しない、および担保アイテムを財産として保管する）。トークンが「ロック」されると、トークンを信頼できる第三者（例えば、トークン化プラットフォーム100）によって管理されるエスクローアカウントにリンクする所有権データ2054が分散台帳に追加され得る。エスクローアカウントにロックされると、トークンは、ロック解除されない限り、償還または譲渡することができない。トークンの所有権の変更を誘発するイベント（例えば、ローンの少なくとも一部の返済）が発生すると、トークンの所有権データ2054は、トークンが正当な所有者（例えば、借り手、参加者、トークンの買い手など）によって所有されていることを反映して、所有権データ2054を格納する分散台帳2016において更新されてよく、それによってトークンがロック解除されている。いくつかの実施形態では、担保トークン2054がロックされると、物理的なアイテムの所有者は、仮想環境におけるアイテムの仮想表現を使用することが妨げられる場合がある。例えば、VIRLを介してビデオゲームに結び付けられた物理的アイテムの所有者（例えば、靴の所有者は、ビデオゲーム内で使用されると、所有者にビデオゲーム内でより速く走る、またはより高く跳ぶなどの特別な機能を与える靴のVIRLも所有する）が、本明細書に記載の技術を使用して物理的アイテムを担保し、得られた担保トークン2042をエスクローアカウントにロックすると、担保トークンをロックすることによって、ユーザがビデオゲームで物理アイテムのVIRLを使うことが排除されることになる。実施形態において、市場、ビデオゲーム、ソーシャルメディアプラットフォームなどの外部の仮想環境は、VIRLの所有権データ2054を取得するために分散台帳に問い合わせるように構成されてもよい。VIRLがエスクローで保持される担保トークン2042で包まれている場合、仮想環境は、対応する担保トークンがエスクローで保持されていると判断し、VIRLの所有権データ2054がユーザがVIRLを所有していると示すまでユーザが仮想環境内でVIRLを使用することを妨げてもよい。

【0234】

分散台帳2016に加えて、イベントレコード2052、所有権データ2054、およびサポートデータ2056、ならびに分散型ローンプロセスをサポートする他の適切なデータが、非分散型データストア、ファイルシステム、データベースなどに格納されてもよいことが留意される。例えば、実施形態において、トークン化プラットフォーム100は、イベントレコード2052、所有権データ2054、およびサポートデータ2056、ならびに分散型ローンプロセスをサポートする他の好適なデータを格納するデータストアを維持してもよい。

【0235】

実施形態において、分散型ローンプロセスにおける参加者の特定のグループ（例えば、認証者、鑑定者、保管者など）は、証券化された分散型ローンプロセスを促進するために定義される一連のガバナンスに従って、ある領域における共通の専門性に基づいてギルドを形成または組織化することができる。一般に、ギルドの結成、加入、運営、ローンプロセスで行われる取引（および他のイベント）、ローンプロセスを促進するための仕組みは、一連のガバナンスを遵守している。ガバナンスは、ローンプロセスおよび参加者の1つまたは複数の側面が順守する規則および／または規制のそれぞれのセットを指す場合がある。実施形態において、ガバナンスは、分散台帳及び／又は集中コンピューティングシステム（例えば、トークン化プラットフォーム）上に格納される一連のファイル及び／又は文書（例えば、ガバナンス文書）において定義されてもよい。いくつかの実施形態では、ガバナンスは、集中コンピューティングシステム（例えば、トークン化プラットフォーム100）によって実行されるスマートコントラクト及び／又はソフトウェアアプリケーションの使用によって実施され得る。実施形態において、ガバナンスのセットは、ローンプロセス全体に適用されるシステムレベルガバナンスを含んでもよい（例えば、ローンプロセスに参加するすべての取引および参加者）、ローンプロセスの特定のステージ（またはステージのセット）に参加する参加者および特定のステージ（またはステージのセット）中に実行される取引に適用されるステージレベルのガバナンス、それぞれのステージに参加するそれぞれのギルドおよび／またはギルドメンバーが参加する取引に適用されるギルドレベルのガバナンス、および／またはそれぞれのギルドから形成されるそれぞれのサブギルドおよびサブギルドメンバーが参加する取引に適用されるサブギルドガバナンスがある。実施形態では、一連のガバナンスは階層的であり、システムレベルのガバナンスは、ローンプロセスのそれぞれのステージに対応するステージレベルのガバナンスに優先し、それぞれのステージのステージレベルのガバナンスは、それぞれのステージに参加するそれぞれのギルドのギルドレベルのガバナンスに優先し、それぞれのギルドのギルドレベルのガバナンスは、それぞれのギルド内より形成されるサブギルドのサブギルドガバナンスに優先する。別の言い方をすれば、サブギルドのサブギルドガバナンスは、サブギルドが形成されたギルドのギルドレベルガバナンスに提示された規則および規定を拡張またはさらに洗練することができ、矛盾しない。ギルドレベルのガバナンスは、ギルドが参加しているステージのステージレベルのガバナンスに提示された規則および規定を拡張またはさらに洗練することができるが矛盾しない、ステージレベルのガバナンスはシステムレベルのガバナンスに提示された規則および規定を拡張またはさらに洗練することができるが矛盾することはない。異なるタイプのガバナンスのいずれも必須ではなく、特定のステージおよびギルドは、本開示の範囲から逸脱することなく、より高いレベルのガバナンス（例えば、システムレベルのガバナンスまたはステージレベルのガバナンス）を堅持してもよいことが理解される。

【0236】

上述したように、用語「ギルド」は、ドメイン固有（例えば、時計の認証、スニーカーの鑑定、貴重品及び／又は生鮮品の保管）であってよく、それによってギルドのメンバーが一連のガバナンスを遵守する、定義されたタイプの専門的タスク（例えば、特定のタイプの担保アイテムの認証、鑑定及び／又は保管）を行う一連のエンティティ（例えば、個人又は企業）を指す場合がある。説明のために、ギルドのメンバーは個人として記述されているが、組織は、同じ専門分野を持つ個人で構成されてもよく、したがって、ギルドに含まれてもよいことが理解される。いくつかの実施形態では、ギルドは、システムレベルのガバナンス、ギルドが参加するステージに対応するステージレベルのガバナンス、及び／又はギルドメンバーが所属するギルドのギルドレベルのガバナンスに従わなければならない。ステージレベルガバナンスは、あるステージ（例えば、認証ステージ、鑑定ステージ、保管ステージ、貸し付けステージなど）に参加できる全ての参加者に関係する規則及び規制を定義してもよい。例えば、認証ステージレベルのガバナンスは、分散型ローンプロセスにおいて関連して認証タスクを実行する任意の認証者に適用されてもよく、鑑定ステージのガバナンスは、分散型ローンプロセスに関連して鑑定タスクを実行する任意の鑑定者に適用されてもよく、保管ステージのガバナンスは、分散型ローンプロセスに関連して保管タスクを実行する任意の保管者に適用されてもよく、貸付ステージのガバナンスは、分散型ローンプロセスでお金を貸す任意の貸付人に適用されてもよく、そのようなものは、すべてそうである。ギルドレベルのガバナンスは、特定のステージに参加する特定のギルドのメンバーに対する規則及び規制を定義してもよい。例えば、時計認証ギルドガバナンスは、時計認証ギルドのメンバーのみに関係してもよく、ハンドバッグ認証ギルドガバナンスは、ハンドバッグ認証ギルドのメンバーのみに関係してもよく、宝飾品認証ギルドガバナンスは、宝飾品認証ギルドのメンバーのみに関係してもよい。時計鑑定ギルドガバナンスは、時計鑑定ギルドの会員にのみ関係してもよく、ハンドバッグ鑑定ギルドガバナンスは、ハンドバッグ鑑定ギルドの会員にのみ関係してもよく、スニーカー鑑定ギルドガバナンスは、スニーカー鑑定ギルドの会員にのみ関係してもよい等である。実施形態において、ステージレベルのギルドガバナンスは、ギルドが作成され得る方法、ギルドメンバーがギルドに追加される方法、ギルドメンバーがギルドから削除される方法、ギルドメンバーがガバナンスの修正について投票する方法、ワークフロー、スマートコントラクト、および／またはそれぞれのギルドによって行われる特定のタスク（たとえば鑑定、認証、保管など）に関係する文書、投票の仕組み、および同様のものの１または複数を定義してもよい。議論されたように、ガバナンスのセットは、下位レベルのガバナンスが上位レベルのガバナンスを遵守することおよび／または矛盾しないことが要求されるような、本質的に階層的であってもよい。例えば、認証ステージレベルのガバナンスは、すべての認証者に適用される規則および規制のセットを定義してもよく、ギルドレベルのガバナンスは、認証者のより広いグループ（例えば、すべての認証者）内のそれぞれのギルド（例えば、時計認証ギルドまたは宝飾品認証ギルド）に適用する規則、勧告、および／または規制のセットを定義してもよい。この例では、ギルドレベルのガバナンスは、ステージレベルのガバナンスを遵守し、矛盾しないように要求されてもよいが、ステージレベルのガバナンスにおける規則および／または規定を改良し、またステージレベルのガバナンスに定義されていなかった新しい規則および／または規定を追加してもよい。例えば、認証ステージレベルガバナンスの例では、ギルドメンバーが行う認証タスクごとに、認証者が少なくとも一定額の資金（例えば、ローン額の半分）を一時的に出資することを要求することができる。この例では、認証ギルド（例えば、時計認証ギルド）のギルドレベルガバナンスは、ギルドメンバーによって実行される認証タスクに関連して、そのギルドメンバーに少なくとも認証ステージレベルガバナンスで定義された金額の資金を出資することを要求しなければならないが、ギルドレベルガバナンスは、認証ステージレベルガバナンスで定義された金額よりも大きい金額（例えば、ローン金額全体）を要求しても良い。別の例では、鑑定ステージレベルのガバナンスは、鑑定者が鑑定のための文書サポートを提供することを要求してもよく、鑑定者の特定のギルドに関係するギルドレベルの鑑定者ガバナンスは、ギルドメンバーによって行われる鑑定のサポートで提供されるべき文書サポートをさらに洗練してもよい。ガバナンスの規則、勧告、および/または規制の追加の例は、本開示を通じて提供される。

【0237】

いくつかの実施形態では、ギルドへのメンバーシップは、少なくとも部分的に、ギルドのステージレベル及び／又はギルドレベルのガバナンスに従って、既存のギルドメンバーによって決定される。例えば、例示的な実施形態では、ギルドのステージレベルのガバナンス及び／又はギルドレベルのガバナンスは、ギルドメンバーがギルドに追加されるためにギルドにいない個人を推薦し、ギルドのメンバーがその実体をギルドに認めるか否かを投票してもよく、さらに新しいメンバーをギルドに推薦、投票及び認める方法に関する機構を含んでもよいことを定めてもよい。したがって、ギルドに新しいメンバーを加えるためには、既存のギルドメンバーは、制御するガバメントに従って推薦および投票プロセスを行う必要がある。いくつかの実施形態では、投票は、ギルドガバナンススマートコントラクト2026を使用して管理されてもよい。ギルドガバナンススマートコントラクト2026は、ギルドレベルガバナンス及び／又はステージレベルガバナンス（ギルドガバナンススマートコントラクト2026が広義のギルドに係る場合）の修正に関する投票、ギルドへの新規メンバーの追加に関する投票、ギルドからのメンバーの削除に関する投票、ギルドメンバーへのギルドトークン2044の発行等、ギルドの管理作業を管理するよう構成されているスマートコントラクトを指すことができる。これらの実施形態のいくつかでは、ギルドに新しいメンバーを投票するために使用されるギルドガバナンススマートコントラクト2026は、潜在的ギルドメンバーの指名を受信し、特定の条件が満たされているかどうかを判断する条件論理を含んでもよい（例えば、指名者は指名するのに十分高い評価を持っているか、指名者は指名するのに十分長くギルドメンバーになっているか、指名者は新しいギルドメンバーを指名するための最低数のギルドトークン2044又は他の類似の状態指標を持っているか、適切なプロトコルは使われたか、といったものである）。指名が有効であることを検証することに応答して、ギルドガバナンススマートコントラクト2026は、現在のギルドメンバーから投票を勧誘するアクションと、投票を集計するアクションを実行することができる。メンバーが投票されると、ギルドガバナンススマートコントラクト2026は、ノミニーがギルドに認められるのに十分な票を獲得したかどうかを判断するように構成されてもよい。そうである場合、ノミニーはギルドに追加される。そうでない場合、ノミニーは、ギルドへの入会を拒否される。そうすることで、ギルドガバナンススマートコントラクト2026は、投票の結果及び／又は新しいメンバーがギルドに追加されたかどうかを識別する１つ又は複数のイベントレコード2052を作成することができる。実施形態において、イベント記録2052は、分散台帳2016に書き込まれてもよい。ギルドガバナンス契約2026は、新しいメンバーにギルドトークン2044を付与する、新しいギルドメンバーのプロファイルを作成する、タスクを実行するためにギルドメンバーが選択されるロスターに新しいギルドメンバーを追加するなど、追加のアクションを実行してもよい。ギルドメンバーは、本開示の範囲から逸脱することなく、他の様式でギルドに追加されてもよい。

【0238】

実施形態では、認証ギルドは、特定のタイプ（複数可）のアイテムを認証するドメイン固有の専門知識を有する個人または組織の集合を含むことができる。例えば、時計認証ギルドは、時計を認証する専門知識を有する個人で構成されてもよく、靴認証ギルドは、靴を認証する専門知識を有する個人で構成されてもよく、ハンドバッグ認証ギルドは、ハンドバッグを認証する専門知識を有する個人で構成されてもよく、美術品認証ギルドは、美術品を認証する専門知識を有する個人で構成されてもよく、また、スポーツ用品認証ギルドは、美術品を認証する専門知識を有する個人で構成されてもよく、また、スポーツ用品認証は、美術品を認証する専門知識を有する個人で構成されてもよく。スポーツ記念品認証ギルドは、スポーツ記念品の認証に関する専門知識を有する個人で構成される場合があり、おもちゃ認証ギルドは、収集価値のあるおもちゃの認証に関する専門知識を有する個人で構成される場合があり、宝飾品認証ギルドは、宝飾品の認証に関する専門知識を有する個人で構成されるものであってもよい。楽器認証ギルドは、楽器の認証に精通した個人で構成され、レコード認証ギルドは、希少または収集価値のあるレコードの認証に精通した個人で構成される場合があります。ワイン認証ギルドは、ボトルを単位とするワインの認証に精通した個人で構成され、ウイスキー認証ギルドは、ボトルを単位とするウイスキーの認証に精通した個人で構成され、自動車認証ギルドは、限定車の認証に精通した個人で構成されるものであってもよい。その他任意の適切な認証ギルドがあり得る。

【0239】

実施形態では、鑑定ギルドは、特定のタイプ（または複数のタイプ）のアイテムを鑑定するドメイン固有の専門知識を有する個人または組織の集合を含むことができる。例えば、時計鑑定ギルドは、時計の鑑定の専門知識を有する個人で構成されてもよく、靴鑑定ギルドは、靴の鑑定の専門知識を有する個人で構成されてもよく、ハンドバッグ鑑定ギルドは、ハンドバッグの鑑定の専門知識を有する個人で構成されてもよく、美術鑑定ギルドは、美術品の鑑定の専門知識を有する個人で構成されてもよく、美術品の鑑定の専門知識を有する個人で構成されてもよく、スポーツ記念品鑑定ギルドは、スポーツ記念品の鑑定に精通した個人で構成されてもよく、おもちゃ鑑定ギルドは、収集価値のあるおもちゃの鑑定に精通した個人で構成されてもおよく、宝飾品鑑定ギルドは、宝飾品の鑑定に精通した個人で構成されてもよく、楽器鑑定ギルドは、楽器の鑑定に精通した個人によって構成されてもよく、ワイン鑑定ギルドは、ボトルを単位とするワインの鑑定を専門とする個人で構成されてもよく、ウイスキー鑑定ギルドは、ボトルを単位とするウイスキーの鑑定を専門とする個人で構成されてもよく、自動車鑑定ギルドは、限定車の鑑定を専門とする個人で構成されてもよい。その他のギルドも同様である。その他適当な鑑定ギルドがあり得る。

【0240】

一部のギルド内では、他よりもはるかに人気のある、および／または追加の専門知識を必要とする可能性のある、異なるクラスのアイテムが存在する可能性がある。例えば、時計認証ギルド内では、市場に出回っているそのような時計の数と、Rolex（登録商標）時計を装うことを意図した偽造時計の数の両方から、Rolex（登録商標）時計を認証するための多数の認証要求がいくつかのギルドに存在する可能性がある。したがって、いくつかの実施形態では、いくつかのステージレベルのガバナンスおよび/またはギルドレベルのガバナンスは、ギルドのサブギルドがギルドの専門分野の特定のサブドメインの認証の専門知識を有するギルドの個人で構成されている、1つ以上のサブギルドを形成することができるメカニズムを提供することができる。例えば、時計ギルドの中には、Rolex（登録商標）時計、Omega（登録商標）時計、Hamilton（登録商標）時計など、異なるブランドの時計の認証に特化したそれぞれのサブギルドが存在する場合がある。別の例として、靴の認証ギルドでは、スニーカー、ハイトップ、スケートボードシューズ、ヒール、ドレスシューズなど、異なる種類の靴の認証を専門とするそれぞれのサブギルド、および／またはナイキ（登録商標）シューズ、ジョーダン（登録商標）シューズ、アディダス（登録商標）シューズ、グッチ（登録商標）シューズ、ルブタン（登録商標）シューズなど、異なるブランドの靴の認証に特化するサブギルドが存在する場合がある。別の例では、美術品認証ギルドの中に、絵画、油絵、彫刻、リトグラフ、コンサートポスター、剣、花瓶、陶器などの異なる媒体の美術品、印象派絵画、抽象絵画、ポストモダンアート、ポップアート、グラフィティ、日本刀、中国花瓶、ファベルジェエッグなどの異なるスタイルのアート、及び／又は異なるアーティストによるアート作品の認証を専門とするそれぞれのサブギルドがあってもよい。このように、異なるギルドは、異なる方法でサブギルドに分割されることがある。さらに、ギルドのサブドメインに対してサブギルドが存在するからといって、すべてのアイテムがサブギルドに含まれなければならないというわけではない。例えば、時計認証ギルドにロレックスサブギルドがあり、他のサブギルドがない場合、Rolex（登録商標）時計はロレックスサブギルドの１人以上の認証者によって認証されるが、Omega（登録商標）時計はロレックスサブギルドのメンバーを含む、より広い時計認証ギルド内の１人以上の認証者によって認証されるものであってもよい。

【0241】

実施形態において、それぞれのギルド内からサブギルドを形成する能力は、それぞれのギルドのギルドレベルガバナンスおよび／またはステージレベルガバナンスにおいて定義されてもよい。これらの実施形態のいくつかでは、それぞれのギルドからの新しいサブギルドの形成は、それぞれのギルドに対応するギルドガバナンススマートコントラクト2026を使用して管理および実施され得る。いくつかの実施形態では、ギルドガバナンススマートコントラクト2026は、サブギルドが（例えば、自動的に、またはギルドメンバーのセットによって）要求され、作成され得る仕組みを定義してよい。例えば、特定の認証ギルド（例えば、時計認証ギルド）によって使用されるギルドガバナンススマートコントラクト2026は、新しいサブギルド（例えば、Rolexサブギルド）の作成を要求／承認するために必要なギルドメンバー（例えば、時計認証者）の最小数及び／又は最小割合を定義する条件論理を含んでもよい。この例では、特定の認証ギルドのギルドレベルのガバナンスは、少なくとも10人のギルドメンバーおよび／またはギルドメンバーの少なくとも50％の投票権（ここで、投票権は、より多くのギルドトークン2044を有するメンバーがより多くの投票権を有する投票トークン方式またはすべてのメンバーが1つの等しく重み付けされた投票権を有する「1メンバー1投票」方式を用いて決定してもよい）をサブギルドの設立に同意するように要求してもよい。加えて又は代替的に、ギルドガバナンススマートコントラクト2026は、新しいサブギルドの作成を承認するために、特定のサブクラスのアイテムを含むギルドメンバーによって行われた検証済みの成功認証イベント（又は別のステージであれば他のタスク）の最小数又は最小割合を要求する条件付きロジックを含んでもよい。例えば、靴認証ギルドのギルドガバナンススマートコントラクト2026は、少なくとも1000件の成功した認証イベントの証明と、認証イベント全体の少なくとも5％が特定のクラスの靴を含むことを要求してもよく、靴認証ギルドが一対の靴を含む1万件の成功した認証イベントを集団で行い、それらの認証イベントの1000件以上がナイキ（登録商標）スニーカーに関係している場合、靴ギルドはナイキ（登録商標）サブギルド（または「スニーカー」サブギルド）を作成するために投票を行うこともできる。この例では、靴認証ギルドのギルドガバナンススマートコントラクトは、1000以上の認証成功イベント（ノックオフスニーカーの認証成功および／または本物のナイキ（登録商標）スニーカーの認証成功を含み得る）を証明するための分析を要求し得る。実施形態において、ギルドが成功した認証の必要な数に達したことを証明するための分析は、認証記録を格納する分散台帳の分析に基づいて取得されてもよい。さらに、靴認証ギルドレベルのガバナンスは、その後、ギルドメンバーに新しいナイキ（登録商標）サブギルドの創設について投票することを要求してもよく、投票スキームは、靴ギルドレベルのガバナンスおよび／または認証ステージレベルのガバナンスで定義される。靴ギルド内に新しいサブギルドを作成する条件のすべてが満たされていると仮定すると、ギルドガバナンススマートコントラクトは、「新しいサブギルドを作成する」アクションをトリガーすることができる。実施形態において、新しいサブギルドを作成するアクションは、サブギルドへのメンバーシップのルール、サブギルドの報酬および手数料、サブギルドに分類されるアイテムを検証するための仕組み、サブギルドが認証イベントを確保する方法、サブグループによって用いられる認証フォーム、などを含む特定のサブギルドのルールを定義するサブギルドに対応する新しいガバナンスを作成することを含んでもよい。実施形態において、サブギルドのガバナンスは、当初、より広いギルドガバナンスの1つまたは複数の側面（そのうちのいくつかはサブギルドによって変更可能であり、そのうちのいくつかはサブギルドによって変更されなくてもよい）を継承し得ることに留意されたい。実施形態において、「新しいサブギルドを作成する」アクションは、プラットフォーム100が、新しいサブギルドの専門知識の下に分類されるアイテムを含む認証タスクの割り当てを新しいサブギルドに更新し得るように、新しいサブギルドの通知をトークン化プラットフォーム100に発行することを含んでもよい。

【0242】

図２１は、分散型ローンエコシステム2000内のギルドの例と、ギルドメンバー及び／又はローンシステムの異なる側面をガバナンスし得る異なるタイプのガバナンスとを示す。図示された例では、ステージレベルのギルドは、認証タスクを実行する認証者により構成される認証ギルド2102、鑑定タスクを実行する鑑定者により構成される鑑定ギルド2104、および保管タスクを実行する保管者により構成される保管ギルド2106を含み得る。追加のまたは代替のタイプの参加者が、異なる実施例においてギルドを形成し得ることが理解される。例えば、貸し手は貸し手ギルドを形成してもよい（図示せず）。上述したように、認証ギルド内には、特定の認証専門性を有するメンバーを含むギルド、または特定の地域に位置するギルドが存在してもよい。図示の例では、認証ギルド内に、時計認証ギルド2112-1、靴認証ギルド2112-2、及び／又は他の任意の適切な認証ギルド（例えば、N番目の認証ギルド2112-N）が存在してもよい。認証ギルドのいくつか内では、認証サブギルドが形成されてもよい。例えば、時計ギルド2112-1内に、ロレックスサブギルドが形成されてもよく、ロレックスサブギルド2122のメンバーは、ロレックス(R)時計の認証に関する特別な専門知識を有する時計ギルドメンバーであってもよい。このように、ロレックスサブギルド2112-1のメンバーには、ロレックス(R)時計（および潜在的には他の種類の時計）に関する認証業務が割り当てられ、サブギルド2122に属さない時計ギルド2112-1のメンバーは、Rolex（登録商標）時計の認証はできないが、他の種類の時計を認証できる（他の時計サブギルドが存在しないと仮定した場合）。同様に、靴認証ギルド2112-2内には、靴認証ギルド2112-2のメンバーによって、スニーカー認証サブギルド2124-1とグッチ認証サブギルド2124-1が形成されている。この例では、スニーカー認証サブギルド2124-1のメンバーは、あらゆる種類のスニーカーを認証することができるが、スニーカー認証サブギルド2124-1に所属しない靴認証者は、スニーカーを認証することができない。同様に、グッチ認証サブギルド2124-2のメンバーは、グッチ（登録商標）シューズを認証できるが、グッチ認証サブギルド2124-2に属さない靴認証者は、グッチ（登録商標）シューズを認証することができない。

【0243】

鑑定ギルド2104内には、特定の鑑定専門性を有する会員に向けられたギルドや、特定の地域に所在するギルドが存在してもよい。図示の例では、鑑定ギルド2104内に、時計鑑定ギルド2114-1、靴鑑定ギルド2114-2、及び／又は他の任意の適切な鑑定ギルド（例えば、N番目の鑑定ギルド2114-3）が存在してもよい。図示された例では、ロレックス鑑定サブギルド2126が時計鑑定ギルド2114-1から形成されており、ナイキ鑑定ギルド2128が靴鑑定ギルド2114-2から形成されている。理解できるように、様々なギルドの中から形成されるサブギルドは、異なるステージに参加するギルドから形成されるサブギルドと一致する必要はない。例えば、ロレックス認証業者とロレックス鑑定業者はそれぞれのサブギルド2122，2126を形成しているが、対になるナイキ認証サブギルドや対になるスニーカー鑑定サブギルドやグッチ鑑定サブギルドは形成されていない。サブギルドが形成される方法は、サブギルドが形成されるギルドのステージレベルガバナンスおよび／またはギルドガバナンスで定義される場合がある。

【0244】

この例では、保管者ギルド2106からギルドは形成されていない。この例ではそうなっているが、シナリオによっては、特定の保管者の専門性を有する保管者を含むギルドや、特定の地域に所在するギルドが存在する場合もある。図示の例では、保管者ギルド内にギルドは存在しないが、保管者は、地域（例えば、州、都市など）、特定の種類の物品（例えば、車両、生鮮品、および／または同類）を保管する能力、または他の適切な共通の特徴に従って組織化してもよい。

【0245】

実施形態において、全体的なエコシステム2100（全体的なローンプロセスのワークフローを含む）は、システムレベルのガバナンス2130によってガバナンスされてもよい。この例では、１つ以上のステージは、ステージの参加者及び／又はステージに関連して実行されるワークフローに関連するステージレベルガバナンスによって支配されてもよい。例えば、認証ステージレベルガバナンス2132は、全ての認証者2102及び認証ステージに関わり、鑑定ステージレベルガバナンス2134は、全ての鑑定者2104及び鑑定ステージに関わり、保管ステージレベルガバナンス2136は、全ての保管者2106及び保管ステージに関わり、貸付ステージレベルガバナンス2138は、貸付者（図示せず）及び貸付交渉及び返済ステージ等に関わり、等とすることができる。上述したように、ステージレベルのガバナンス2132、2134、2136、2138は、システムレベルのガバナンス2130を洗練することができ、システムレベルのガバナンス2130と矛盾しない規則および規制を追加することができる。同様に、時計ギルドレベルのガバナンスは、時計認証ギルド2112-1に2142が関係するが、他の認証ギルド2112-2．．．2112-Nには関係しない。時計ギルドレベルガバナンス2142は、システムレベルガバナンス2130をさらに洗練させる規則、および／または認証ステージレベルガバナンス2132に規則および規制を追加する規則を含んでもよい。実施例では、ロレックスサブギルドガバナンス2144は、ロレックス認証サブギルド2122のメンバーによって作成されてもよい。ロレックスサブギルドガバナンス2144は、ロレックス(R)時計の認証を行う際にロレックスサブギルド2122のメンバーに適用されるが、時計認証ギルド2112-1の他のメンバーには適用されない追加の規則及び規定を定義する。サブギルドはサブギルドのガバナンスを必要とせず、サブギルドが形成されたギルドのギルドレベルのガバナンスを使用することができることに留意されたい。ギルドとガバナンスのより詳細な説明は後述する。

【0246】

図２０に戻ると、ガバナンスは、証券化された分散型ローンプロセスの異なる側面に関連する規則および規制を定義し得る。実施形態において、システムレベルのガバナンスは、ローンプロセス全体に関連する規則及び規制を定義する。システムレベルのガバナンスの例は、ローンプロセスのワークフローの定義（例えば、どのステージがどのような順序で実行されなければならないか）、許容される担保アイテムのタイプ、ギルド形成及びメンバーシップに関する規則（例えば、ギルドを形成することができるか、ギルドが規則を変更できるか、ギルドが規則を変更する方法、及び／又はその類）、ステージ間のローンプロセスのワークフローの管理のための規則（例えば、担保アイテムを認証した認証者が同じ担保アイテムを鑑定できる、及び／又は担保アイテムを保管できる、ローンプロセスが次のステージに進行できるタイミング、など）；ギルドメンバーが通貨をステークすることを要求するルール（例えば。担保アイテムを含む認証タスク、鑑定タスク、及び／又は保管タスクに関連して、ギルドメンバーに通貨（例えば、暗号通貨及び／又はトークン化されたトークンに包まれた不換紙幣）を出資させるルール、タスクを実行するためのルール（例えば、合意を示すために必要なサポートドキュメントのタイプ）、ガバナンスを変えるためのルール（例えば、ガバナンスを変更するために投票できる人、ガバナンスを変更するための投票の実施方法など）、参加者に報酬を与えるための規則（例えば、特定のタスクを実行する際に行われ得る支払いの額または割合に関する要件および／または制限、異なる法域の規制要件）、および／または他の適切な規則および規制を提供する。

【0247】

実施形態において、システムレベルのガバナンスは、分散台帳2016上に格納される１つまたは複数のそれぞれのローンプロセスのスマートコントラクト2022への参照を含んでもよい。ローンプロセスのスマートコントラクト2022は、例えば、システムレベルガバナンスに定義されたローンプロセスのワークフローに従って前のステージが完了したときにローンプロセスの各ステージを開始することを含む、分散型ローンプロセスのインスタンスに対するシステムレベルガバナンスの１つまたは複数の態様を実施してもよい。実施形態において、ローンプロセスのスマートコントラクト2022は、一旦インスタンス化されると、ステージが正常に完了したことを示すステージレベルのスマートコントラクトからの通知を（例えば、イベントリスナスレッドを用いて）リッスンする条件付きロジックを含む。ステージが完了したことに応答して、ローンプロセスのスマートコントラクト2022は、次に、ローンプロセスのワークフローにおける次のステージを開始し得る。例えば、例示的なローンプロセスのワークフローは、借り手が１つ以上のアイテムを担保に入れることを要求する要求ステージと、１つ以上の認証者が１つ以上のアイテムを認証する認証ステージと、認証されたアイテムが鑑定される鑑定ステージとを含むように定義することができる。鑑定されたアイテムが信頼できる保管者に保管される保管ステージと、台帳管理システム104（または別の適切なコンポーネント）が１つ以上の預託された物品のVIRLを生成し、預託された物品のVIRLをトークン化して担保トークンを生成し、担保トークンをロック（例えば、分散台帳2016上のエスクローアカウントにおいて）、借り手および貸し手によってローンが交渉され受け入れられる貸し付けステージ、借り手によってローンが返済される返済ステージ、および借り手がローンを不履行にした場合に担保トークンがロック解除されて借り手に返却または清算されるローン後ステージが含まれる。この例示的なローンプロセスのワークフローを促進する際に、ローンプロセスのスマートコントラクト2022は、現在のステージが正常に完了したかどうかを判断し、そうであればローンプロセスのワークフローにおける次のステージを開始する条件付きロジックを備えて構成されてもよい。実施形態において、ローンプロセスのワークフローの次のステージを開始することは、ステージレベルスマートコントラクト（例えば、認証スマートコントラクト2028、評価スマートコントラクト2030、保管スマートコントラクト2032、またはローンスマートコントラクト2034）のインスタンス化を含み得、それによって、ステージレベルスマートコントラクトのインスタンスはステージ特定ワークフローを行い、ステージ特定ワークフローが成功または失敗して完了するとローンプロセスのワークフローが受信する通知を発行する。実施形態において、ローンプロセスのスマートコントラクト2022は、他のタイプのスマートコントラクトによって実行されるものとして説明される１つ以上のタスクを実行してもよい。例えば、ローンプロセスのスマートコントラクト2022は、ローン交渉及びローン署名、ローンの返済の監視、デフォルトイベントの決定、清算イベントのトリガー、参加者への報酬の授与、及び／又は同様のことを容易にするように構成されてもよい。

【0248】

システムレベルプロセスガバナンスは、追加の規則および要件を含んでもよく、その例は、本開示全体を通じて提供される。例えば、システムレベルプロセスガバナンスは、単一のエンティティが認証者および鑑定者として機能することを妨げる規則、認証者、鑑定者、および／または保管者がローン価値の少なくともパーセントを出資する（例えば、システムの操作を防止する）ことを要求する規則、および／またはローンプロセスの分散化、詐欺の可能性の低減、信頼の促進、参加者の価値の最大化、トークンの鋳造等に関連する他の規則を含んでいてもよい。実施形態において、システムレベルプロセスガバナンスの少なくとも一部は、ローンプロセスのスマートコントラクト2022によって実装される。実施形態において、ローンプロセスガバナンスのスマートコントラクトは、それぞれのステージが正常に完了したかどうかを判断し、完了した場合、ローンプロセスにおける次のアクションをトリガーする条件付きロジックを含んでもよい。

【0249】

実施形態において、ステージレベルガバナンスは、ローンプロセスの各ステージが１つ以上のそれぞれのステージレベルガバナンスに従って実行され得るように、ローンプロセスのそれぞれのステージに関連する規則及び規制を定義する。いくつかの実施形態において、ステージレベルガバナンスは、２つのステージに適用されてもよいことが理解される。例えば、認証ステージは、分散型ローンプロセスに関連して実行される任意の認証タスクのための規則を定義するステージレベルの認証ガバナンスに準拠してもよく、鑑定ステージは、分散型ローンプロセスに関連して実行される任意の鑑定タスクのための規則を定義するステージレベルの鑑定ガバナンスに準拠してもよく、保管ステージは、分散型ローンプロセスに関連して実行される任意の保管タスクのための規則を定義するステージレベルの保管ガバナンスに準拠してもよい。担保アイテムのVIRLを生成するためのルールを定義するVIRLステージレベルガバナンス、担保アイテムのVIRLのトークンを生成するためのルールを定義するトークン化ステージレベルガバナンス（一部の実施形態では、VIRLステージおよびトークン化ステージは単一のステージとして扱われてよい）、ローンを要求し交渉するためのルールを定義するローンガバナンス、および／または任意の他の適切なステージレベルガバナンスを含むことができる。

【0250】

実施形態において、ステージレベルのガバナンスは、システムレベルのガバナンスに規定された規則をさらに洗練させることができ、及び／又はステージに関連する追加の規則を含むことができる。例えば、ステージレベルのガバナンスは、ギルドメンバーの追加および／または削除のさらなる洗練、ギルドメンバーがギルド固有のタスク（例えば、認証タスク、鑑定タスク、または保管タスク）に関連してどのように通貨をステークするかについてのさらなる洗練、認証タスクをサポートするために必要な証拠のタイプについてのさらなる洗練など、システムレベルのガバナンスのルールおよび／または規則をさらに洗練させてもよい。例えば、システムレベルのガバナンスは、新しいメンバーはどのギルドにも投票されなければならず、少なくとも60％の多数決で削除されるかもしれないと述べることができるが、他の具体的な内容は定義しないことができる。この例では、認証ステージレベルのガバナンスルールは、認証ギルドに投票しメンバーを削除するための第１の投票スキームを定義してもよく、一方、鑑定ステージレベルのガバナンスは、鑑定ギルドに投票しメンバーを削除するための第２のスキームを定義してもよい。例えば、認証者は、単純多数決で新しいメンバーをギルドに追加し、60％の多数決で削除することができる１メンバー１票投票スキームを有してよく、一方、鑑定者は、各ギルドメンバーが一定額のギルドトークン2044を有し、それによって各ギルドメンバーの投票力がギルドメンバーが所有するギルドトークン2044の額に比例するトークンバーステートンを有してよく、この場合、鑑定者は、ギルドメンバー2044を削除し、ギルドメンバーを削除するために、ギルドメンバーの投票力を低下させる。第2の方式では、より年長またはアクティブなメンバーが、より年長またはアクティブでないギルドメンバーよりも多くの議決権を有する。実施形態において、ステージレベルのガバナンスは、そのステージのギルドによって要求される文書およびサポートデータのタイプをさらに定義してもよい。この例では、認証ステージレベルガバナンスは、認証者が認証リポートに記入し、リポートをサポートするために証拠写真を提供することを要求するように、この規則をさらに洗練してもよい。同様に、鑑定ステージレベルのガバナンスは、この規則をさらに改良して、鑑定者が鑑定価値を示す鑑定リポートを提出し、鑑定価値を支持するために類似のアイテムの過去の販売の証拠書類を提供することを要求することができる。この例では、保管者ステージレベルガバナンスは、保管者が、安全に保管されているアイテムの証拠写真を提供し、アイテムが所有者（例えば、借主）によって預けられたときに見えた損傷とこの見えた損傷のアイテムの所有者による検証を示す保管リポートを記入することを要求するように、この規則をさらに改良してもよい。さらに、鑑定ステージレベルのガバナンスは、鑑定リポートが、担保アイテムの鑑定価格に加え、担保アイテムの清算価値を含むことをさらに定義してもよく、清算価値は、担保アイテムが（例えば、短期間の通知による清算イベントにおいて、または迅速な清算販売を達成するための設定価格販売で）販売されると予想されるローエンド価格を示している。

【0251】

前述のように、ステージレベルガバナンスは、それらの新しい規則及び規制がシステムレベルガバナンスと矛盾しないか、さもなければ無効とならない範囲において、新しい規則及び規制を定義することもできる。例えば、システムレベルガバナンスでそのような規則が定義されていないと仮定すると、ステージレベルガバナンスは、ステージ固有のタスクがどのように実行されるかについての規則を定義してもよい。例えば、認証ステージに関して、認証ステージレベルガバナンスは、一次認証者が担保アイテムの真正性の決定を行い、少なくとも一つの他の認証者（「二次認証者」として機能する）がアイテムの真正性に関する一次認証者の決定を検証することを要求してもよい。この例では、ステージレベルのガバナンスは、一次認証者が認証料／報酬のある割合（例えば、60％または70％）を取得し、残りの金額は１人以上の二次認証者の間で分割されることをさらに定義してもよい。さらに、この例では、認証ステージレベルのガバナンスは、一次認証者と他の二次認証者へのリスクの配分を定義することによって、認証者が通貨トークンをステークするためのシステムレベルの要件を洗練してもよい（例えば、一次認証者はローン金額の60％または70％をステークし（ローンが合意されたと仮定する）、二次認証者はローン金額の残りの部分を均等に分割する）。別の例では、鑑定ステージレベルのガバナンスは、鑑定の仕組みとワークフローを定義してもよい。例えば、ガバナンスは、鑑定タスクが鑑定者に割り当てられる方法と、いかなる鑑定も１人以上の追加の鑑定者によって検証されなければならないことを定義してもよい。この例では、鑑定ステージレベルのガバナンスは、一次および二次鑑定者が報酬を受ける方法および/または一次および二次鑑定者がその鑑定を確保するために賭けなければならない通貨の額をさらに洗練することができる。別の例では、保管者ステージレベルガバナンスは、ある種の担保アイテムの保管のための追加ルールを定義してもよい。例えば、アイテムが温度管理された保管を必要とする場合、保管ステージレベルのガバナンスは、保管者がそのような温度管理された保管の証明を提供することを要求する規則を定義してもよい。別の例では、担保アイテムが車両である場合、保管ステージレベルのガバナンスは、車両が最初に受け取られた日及び正当な所有者（例えば、清算による借り手又は買い手）によって差し押さえられる日の車両の走行距離の証拠を提供することを保管業者が要求するルールを定義してもよい。ステージレベルのガバナンスは、システムレベルの規則および規制の追加的または代替的な改良、および／またはシステムレベルのガバナンスで示されなかった規則および／または要求事項の追加的または代替的な定義を含むことができる。

【0252】

実施形態において、いくつかのステージレベルガバナンスは、ステージに関連して使用されるフォームテンプレートまたはその参照（例えば、フォームテンプレートが取得され得るアドレス）を含んでもよい。いくつかの例示的な実施形態において、認証ステージレベルガバナンスは、認証タスクを実行するときに認証者によって使用され得る認証フォームテンプレートへの参照を含んでもよい。フォームテンプレートは、認証者がフォームを記入し、認証システム804、認証者スマートコントラクト2028、及び／又はローン処理スマートコントラクト2022にフォームを提出するように、担保アイテムを認証することをタスクとする認証者によって記入されるべきフィールドのセットを含んでもよい。フォームに記入する際に、認証者は、アイテムの真正性に関する見解を提供することができ、その見解を支持する分析を提供することができる。フォームには、写真、シリアル番号、ビデオなどのサポートとなる証拠を提供する指示が含まれてもよい。いくつかの例示的な実施形態では、鑑定ステージレベルのガバナンスは、鑑定者タスクを実行するときに鑑定者が使用することができる鑑定書テンプレートへの参照を含んでもよい。鑑定前に認証が行われると仮定すると、鑑定者は、物品が本物であると信頼することができるが、適切な評価を提供するために、物品自体、または物品の写真及び／またはビデオのいずれかの検査を必要とする場合がある。鑑定者フォームは、担保アイテムの鑑定を任務とする鑑定者がフォームを記入し、完成したフォームを認証システム804及び／又は鑑定スマートコントラクト）に提出するような、一連のフィールドを含んでもよい。フォームに記入する際に、鑑定者は鑑定価値を提供することができ、鑑定価値を支持する分析を提供することができる。フォームは、類似のアイテムの過去の販売の証拠、ブルーブック値、オークションデータなどの、サポートとなる証拠を提供する指示を含むことができる。いくつかの例示的な実施形態では、保管ステージレベルのガバナンスは、保管タスクを実行する際に保管者によって使用され得る保管フォームテンプレートへの参照を含んでもよい。いくつかの実施形態では、書式は、鑑定者が、鑑定価格に加えて、担保アイテムの清算価値を提供することを要求してもよい。清算価値は、担保アイテムが迅速に清算される必要がある場合など、担保アイテムのローエンド評価額であってもよい。評価額と組み合わせた清算価値は、潜在的な貸し手に、担保物件の評価額と清算価値を考慮して、お金を貸すことに関連するリスクを評価する機会を提供することができる。フォームには、認証者がフォームを記入し、それを（例えば、担保管理システム802及び／又は保管スマートコントラクトに）提出するように、担保アイテムの保管を任務とする保管者によって記入されるべき一連のフィールドが含まれてもよい。フォームに記入する際に、保管者は、担保アイテムを受け取ったときの状態を提供し、担保アイテムを保護するための適切な予防措置を有する物理的な場所に担保アイテムが保管されていることを検証することができる。フォームには、担保アイテム（目に見える損傷を含む）の写真などの証拠を提供するよう指示が含まれていてもよい。フォームテンプレートは例として提供され、追加または代替のフォームテンプレートが分散型ローンプロセスの様々なステージの間に使用されてもよいことが理解される。さらに、いくつかのギルドは、特定のタイプの担保アイテムのためのフォームテンプレートをさらに改良してもよい。これらのシナリオでは、ステージレベルガバナンスで定義されたフォームテンプレートの代わりに、ギルドで洗練されたフォームテンプレートがそれぞれのタスクに関連して使用されるかもしれません。他のステージレベルガバナンスは他のフォームテンプレートを含むことができることに留意されたい。さらに、いくつかのギルドレベルのガバナンスおよび／またはサブギルドレベルのガバナンスは、ステージレベルのガバナンスで定義されたフォームテンプレートの代わりに、またはステージレベルのガバナンスがより広いフォームテンプレートを含むか参照しない場合に、ギルドまたはサブギルドのメンバーによって使用されるべきフォームテンプレートを含むか参照できることを理解されたい。

【0253】

いくつかの実施形態では、ステージレベルガバナンスは、ステージレベルのタスク及び／又はステージに参加するギルドの管理に関連して使用される1つ又は複数のスマートコントラクトへの参照を含むことができる。これらのスマートコントラクトは、それぞれのステージのステージレベルガバナンス、ならびにシステムレベルガバナンスで定義された任意の関連する規則および規制を実施するそれぞれのステージの参加者を管理することに対応するステージレベルガバナンススマートコントラクト2024を含んでもよい。実施形態において、ステージレベルガバナンススマートコントラクト2024は、特定のステージの仕組みを実施するように構成されてもよい。例えば、特定のステージのステージレベルガバナンスは、ガバナンスへの変更がステージのすべての参加者によって投票されることを要求してもよく、投票プロセスを実施するためにステージレベルガバナンススマートコントラクト2024を用いてもよい。この例では、（すべてのギルドにわたる）認証者は、アイテムが偽物であると判断されたとき、または借り手がローン契約を締結しないことを決定した場合（これは、認証者がローン取引に参加するための報酬を払い出されることを妨げる）にも認証者が支払いを受けられるように、借り手が認証者に支払う認証料金を（ローン処理が正常に完了したときに認証者に支払う報酬に加えて）要求するよう認証ステージのガバナンスを変更したいと望むかもしれない。ステージレベルガバナンス2024は、認証者がステージレベルガバナンスを修正するためにスーパーマジョリティ（例えば、2／3の多数）の投票を有することを要求してもよく、そのような修正を行うために中央当局に所属する意思決定者からさらに承認を受けなければならない。この例では、ステージレベルガバナンススマートコントラクト2024は、認証者から投票を受け取り、認証ステージレベルガバナンスを修正するために超多数が投票したかどうかを決定するリスニングスレッドを含んでもよい。そうである場合、スマートコントラクトは、認証ステージレベルガバナンスを改正するアクションを実行してもよく、対応する分散台帳2014に書き込まれる投票の結果を示すブロックを生成してもよい。この例は、認証ステージに関して、及び投票に関して説明されたが、ステージレベルガバナンススマートコントラクト2024は、様々なステージレベルガバナンスの他の側面を実施するように構成されてもよい。

【0254】

さらに、例示的な実施形態では、ステージレベルガバナンスは、ステージレベルのイベントおよび取引を管理するために使用されるそれぞれのスマートコントラクトへの参照を含むことができる。例えば、認証ステージレベルガバナンスは、ローンプロセスに関連して実行される認証タスクを容易にするために使用される認証スマートコントラクト2028への参照を含んでもよく、評価ステージレベルガバナンスは、ローンプロセスに関連して実行される評価タスクを容易にするために使用される評価スマートコントラクト2030への参照を含んでもよい。保管ステージレベルガバナンスは、ローンプロセスに関連して実行される鑑定タスクを容易にするために使用される保管スマートコントラクト2032への参照を含んでもよく、ローンステージレベルガバナンスは、ローン契約及びローン返済ステージを管理するために使用されるローンスマートコントラクト2034への参照を含んでもよい。いくつかの実施形態では、ローンワークフローは、ローン前清算ステージレベルガバナンスによって管理されるローン前清算ステージ（後述）を含んでもよい。これらの実施形態において、ローン前清算ステージレベルガバナンスは、以下でより詳細に説明されるローン前清算スマートコントラクトへの参照を含んでもよい。

【0255】

例示的な実施形態では、認証ステージレベルガバナンスは、認証タスクに使用され得る認証スマートコントラクト2028の参照（例えば、アドレス）を含んでもよい。参照は、認証スマートコントラクト2028を（例えば、分散台帳2016から）取得するために使用され得るアドレスを定義してもよい。これらの実施形態において、ローンプロセスのスマートコントラクト2022、認証者デバイス2004、及び／又はトークン化プラットフォーム100は、認証者が新しい認証タスクを割り当てられたこと及び／又は認証者が認証者デバイス2004を介して新しい認証タスクを受け入れることに応答して、認証スマートコントラクト2028のインスタンスをインスタンス化してもよい。インスタンス化されると、認証スマートコントラクト2028のインスタンスは、分散台帳2016に書き込まれ、認証スマートコントラクトインスタンスは、認証タスクを管理するために実行される場合がある。実施形態において、認証スマートコントラクト2028は、認証者デバイス2004、借り手デバイス2002、及び／又は担保管理システム804から入力を受け取るように構成されてもよく、受け取った入力に基づいて認証タスクに関連してすべての必要なステップが実行されたかどうかを決定する条件付きロジックを含んでもよい。

【0256】

図２２は、認証ワークフローを実行するために実行され得る例示的な方法2200の一連の動作を示す図である。方法2200は、認証スマートコントラクト2028またはローン工程スマートコントラクト2022などのスマートコントラクトによって実行され得る。説明の便宜上、方法2200は、認証スマートコンタクトによって実行されるものとして説明される。

【0257】

2202で、認証スマートコントラクト2028のインスタンスは、認証者デバイスから担保アイテムの受信者の確認を受信してもよい。いくつかのシナリオでは、担保アイテムは、タスクを実行するために一次認証者に物理的に送られる。このようなシナリオでは、一次認証者は、認証者デバイス2004を使用して担保アイテムの受領を確認してもよい。これらの実施形態において、認証者は、担保アイテムの画像を提供することができ、アイテムに見えるいかなる損傷も注記することができる。代替的に、一次認証者は、担保アイテムのVIRLを送信されてもよい。これらの実施形態において、VIRLは、認証者が認証タスクを実行するのを助けることができる担保アイテムの超高解像度画像及び／又は他の媒体を含むことができる。

【0258】

2204において、認証スマートコントラクトインスタンスは、一次認証者から認証リポート及び支持文書を受信してもよい。これらの実施形態において、一次認証者は、認証ステージレベルのガバナンス及び／又は認証者が属する認証ギルドのギルドレベルのガバナンスに従って、認証リポートを生成することを要求されてもよい。いくつかの実施形態では、一次認証者は、ステージ認証ステージレベルガバナンスおよび／またはギルドレベルガバナンスに含まれるフォームテンプレートを使用して、リポートを生成してもよい。リポートにおいて、一次認証者の結論（例えば、アイテムが本物であるか偽物であるか）及びその理由を示すことができる。サポート文書には、写真、シリアル番号、テスト結果など、認証者の結論をサポートるものを含めることができる。認証者が認証リポートを提供すると、リポート及びサポート文書は、（ステージ的ガバナンスによって要求される場合）１人以上の二次認証者に提供される場合がある。

【0259】

2206で、認証スマートコントラクトインスタンスは、1つまたは複数の二次認証者から検証を受け取る。いくつかの実施形態では、認証スマートコントラクト2028は、一次認証者のリポートの受信に応答して、二次認証者の見解を要求する条件付きロジックを含んでもよい。いくつかの実施形態では、スマートコントラクトインスタンス（または一次認証者）は、（タスクに割り当てられた後に）一次認証者のリポートおよび支持証拠を二次認証者に提供してもよく、二次認証者からの応答を聴取してもよい。受信されると、認証スマートコントラクト2028は、必要な数の二次認証者が支持見解を提供したかどうかを判断してもよく、提供した場合、認証スマートコントラクトインスタンスは、二次認証者が担保アイテムの真正性に関して一次認証者の見解を検証したかどうかを判断するために、ロジックを実行する。

【0260】

2208において、認証リポート、サポート文書、および二次認証者の見解に基づくデータブロックが生成され、データブロックは、分散台帳2016に書き込まれてもよい。いくつかの実施形態において、認証スマートコントラクトは、データブロックを生成し、データブロックを分散台帳に書き込んでもよい。あるいは、認証スマートコントラクトは、認証リポート、サポート文書、および二次認証者の見解を台帳管理システム202（または別の適切なシステム）に送信してもよく、この台帳管理システムは、今度はデータブロックを生成し、データブロックを分散台帳に書き込んでもよい。

【0261】

2210において、認証スマートコントラクトインスタンスは、認証タスクの結果を示す通知を、ローン処理スマートコントラクト2022に提供してもよい。特に、認証スマートコントラクトは、アイテムが一次認証者及び二次認証者（複数可）によって真正とみなされたかどうかを示す通知を、ローンプロセスのスマートコントラクト2022に提供してもよい。そうである場合、認証スマートコントラクトインスタンスは、認証プロセスに参加した認証者（複数可）が（例えば、返済資金及び／又は清算イベントの収益から）報酬を受けるまで、認証ワークフローを進め続けてもよい。そうでない場合、認証スマートコントラクトインスタンスは、認証タスクを終了してもよい。

【0262】

2212において、認証スマートコントラクトインスタンスは、アイテムが認証されていないとみなされた場合に、認証を確保するために、認証者から通貨の額をロックしてもよい。いくつかの実施形態では、認証スマートコントラクトインスタンスは、貸し手により大きな額のセキュリティを提供するように、認証者（複数可）がアイテムを真正とみなすときに一定額の通貨（例えば、通貨／トークン）をロックするために認証者の認証ステージレベルのガバナンス及び／又はギルドレベルのガバナンスに規定される要件を強制してよい。このようにして、認証者は、偽物である可能性があるアイテムを認証するインセンティブを少なくすることができる。実施形態において、ロックされる金額は、ローン金額、総返済額、鑑定額、または別の適切な値に等しいか、またはその割合であってよく、ここでロックされる金額は、鑑定ステージガバナンスに従って定義される。いくつかの実施形態では、ロックされた通貨トークンは、ロックされた通貨が後に認証された物品が偽物であることが発見された場合の不測の事態を提供するように、ローンの残りの残高を超えない認証者からのロックされた通貨の額が返済の過程で認証者に返却される。

【0263】

2214において、認証スマートコントラクトインスタンスは、ローンの返済時に、認証タスクに参加した認証者に報酬額を譲渡してもよい。ローンプロセスが完了すると（例えば、ローンの返済及び担保アイテムが借り手に返却された後、担保アイテムの買い手が担保アイテムを検査するための売却後の所定の時間を有する清算イベントの後、及び／又は買い手がローンに関与しないことを決定し担保アイテムの占有を取り戻すことを望む場合）認証タスクに参加した第一認証者及び任意の第二認証者に対して報酬を発行してもよい。例えば、認証者は、ローン又は返済額のパーセンテージ、予め定められた手数料、及び／又はそのようなもので報酬を得てもよい。ローンプロセスが完了すると、認証スマートコントラクトのインスタンスは、分解されてもよい。

【0264】

図２２の例は、認証ワークフローの例として提供されている。他の認証ワークフローは、認証タスクに関連して実行され得る。さらに、それぞれの認証ギルド内で、それぞれの認証ギルドのメンバーは、特定のタスクの認証を改善するために、認証ワークフロー及び／又は認証スマートコントラクトを改良することができるが、そのような改良は認証ステージレベルのガバナンスに従うものであることが条件である。

【0265】

図２０に戻って参照すると、鑑定ステージレベルガバナンスは、鑑定タスクに使用され得る鑑定スマートコントラクト2030の参照（例えば、アドレス）を含んでもよい。参照は、鑑定スマートコントラクト2030を（例えば、分散台帳2016から）取得するために使用され得るアドレスを定義してもよい。これらの実施形態において、ローンプロセスのスマートコントラクト2022、鑑定者デバイス2006、及び／又はトークン化プラットフォーム100は、鑑定者が新しい鑑定タスクを割り当てられたこと及び／又は鑑定者が鑑定者デバイス2006を介して新しい鑑定タスクを受け入れることに応答して、鑑定スマートコントラクト2030のインスタンスをインスタンス化してもよい。インスタンス化されると、鑑定者スマートコントラクト2030のインスタンスは、分散台帳2016に書き込まれ、そこで鑑定スマートコントラクトインスタンスは、鑑定タスクを管理するために実行されることができる。実施形態において、鑑定スマートコントラクト2030は、鑑定者デバイス2006、借り手デバイス2002、および／またはトークン化プラットフォーム100から入力を受け取るように構成されてもよく、受け取った入力に基づいて鑑定タスクに関連してすべての必要なステップが実行されたかどうかを判断する条件付きロジックを含んでもよい。

【0266】

図２３は、鑑定ワークフローを実行するために実行され得る方法2300の動作の例示である。方法2300は、鑑定スマートコントラクト2030またはローンプロセスのスマートコントラクト2022などのスマートコントラクトによって実行され得る。説明の便宜上、方法2300は、鑑定スマートコンタクトによって実行されるものとして説明される。

【0267】

2302において、鑑定スマートコントラクト2030のインスタンスは、鑑定者デバイス2006から担保アイテムの受信者の確認を受信してもよい。いくつかのシナリオでは、担保アイテムは、タスクを実行するために一次鑑定者に物理的に送られる。このようなシナリオでは、一次鑑定者は、鑑定者デバイス2006を使用して担保アイテムの受領を確認してもよい。これらの実施形態において、鑑定者は、担保アイテムの画像を提供することができ、物品に見えるいかなる損傷も記録することができる。代替的に、一次鑑定者は、担保アイテムのVIRLを送信されてもよい。これらの実施形態において、VIRLは、鑑定者が鑑定作業を行う際に補助することができる担保アイテムの超高解像度画像及び／又は他の媒体を含むことができる。いくつかの実施形態では、鑑定者は、一組の認証者が担保アイテムを認証したことの確認などの追加情報を受信してもよい。

【0268】

2304で、鑑定スマートコントラクトインスタンスは、一次鑑定者の鑑定者デバイス2006から鑑定リポート及びサポート文書を受信してもよい。これらの実施形態において、一次鑑定者は、鑑定者が所属する鑑定ギルドの鑑定ステージレベルのガバナンス及び／又はギルドレベルのガバナンスに従って鑑定リポートを生成するよう要求されてもよい。いくつかの実施形態では、一次鑑定者は、鑑定者の鑑定ギルドの鑑定ステージレベルのガバナンス及び／又はギルドレベルのガバナンスに含まれるフォームテンプレートを使用して、リポートを生成してもよい。リポートには、鑑定者によって決定された鑑定価格と、鑑定価格をサポートる文書とが示されてもよい。サポート文書には、類似品のブルーブック値へのリンク、類似品の販売のスクリーンショット、類似品の販売に関する履歴データ、および/または鑑定者の鑑定価値をサポートる他の適切な情報が含まれてもよい。鑑定者が鑑定リポートを提供すると、そのリポート及びサポート文書は、（鑑定ステージレベルのガバナンスによって要求される場合）１人以上の二次鑑定者（複数可）に提供され得る。いくつかの実施形態では、鑑定ステージレベルのガバナンス又は鑑定者のギルドレベルのガバナンスは、鑑定者に、鑑定価格に加えて、鑑定リポートにおいて清算価値を提出することを要求することができる。

【0269】

2306で、鑑定スマートコントラクトインスタンスは、１以上の二次鑑定者から検証を受信する。いくつかの実施形態では、鑑定スマートコントラクト2030は、一次鑑定者のリポートを受け取ることに応答して、二次鑑定者の見解を要求する条件付きロジックを含んでもよい。いくつかの実施形態では、鑑定スマートコントラクト2030（または一次鑑定者）は、（タスクに割り当てられた後）一次鑑定者の鑑定リポート及びサポート証拠を二次鑑定者に提供してもよく、二次鑑定者からの応答を聴いてもよい。受信されると、鑑定スマートコントラクト2030は、必要な数の二次鑑定者が一次鑑定者の評価額を確認したかどうかを判断してもよい。

【0270】

2308において、鑑定書、サポート文書、および二次鑑定者の見解に基づくデータブロックが生成され、データブロックは、分散台帳2016に書き込まれてもよい。いくつかの実施形態において、鑑定スマートコントラクトは、データブロックを生成し、データブロックを分散台帳206に書き込んでもよい。あるいは、鑑定スマートコントラクトは、鑑定リポート、サポート文書、及び二次鑑定者の見解を台帳管理システム202（又は別の適切なシステム）に送信してもよく、台帳管理システムは、今度はデータブロックを生成し、データブロックを分散台帳2016に書き出してもよい。いくつかの実施形態では、データブロックは、鑑定者によって決定された担保アイテムの清算価値をさらに含んでもよい。

【0271】

2310において、鑑定スマートコントラクトは、鑑定タスクの結果を示す通知をローンプロセスのスマートコントラクト2022に提供してもよい。特に、鑑定スマートコントラクトは、鑑定された値を示す通知をローンプロセスのスマートコントラクト2022に提供してもよい。借り手がローン契約に同意すると仮定すると、鑑定スマートコントラクトは、鑑定プロセスに参加した１または複数の鑑定者が（例えば、返済資金及び／又は清算イベントの収益から）報酬を得るまで、鑑定ワークフローを進め続けてもよい。借り手がローン契約を形成せず、ローンプロセスを終了させることを決定した場合、鑑定スマートコントラクトは、鑑定タスクを終了させてもよい。

【0272】

2312において、鑑定スマートコントラクトは、アイテムが鑑定者によって提供された鑑定価値以上で清算されない場合に、鑑定を確保するために鑑定者から通貨の額をロックしてもよい。いくつかの実施形態では、鑑定スマートコントラクト2030は、貸し手により大きなセキュリティ額を提供するように、１または複数の鑑定者が鑑定価値を提供するときに一定額の通貨（例えば、通貨／トークン）をロックするために鑑定者のギルドの鑑定ステージレベルのガバナンスおよび／またはギルドレベルのガバナンスに定められた要件を強制し得る。このようにして、鑑定者は、ローン契約が締結される可能性を向上させるために、物品をより高い価格で鑑定するインセンティブを少なくすることができる。実施形態において、ロックされる金額は、ローン金額、総返済額、鑑定価格、または別の適切な値に等しいか、またはその割合であってよく、ここでロックされる金額は、鑑定ステージガバナンスに従って定義される。いくつかの実施形態では、ロックされた通貨トークンは、鑑定されたアイテムが鑑定された値よりも低い値で清算イベントで販売される場合の不測の事態を提供するので、鑑定者からのロックされた通貨の額がローンの残りの残高を超えないように、返済の過程で鑑定者に返却される。

【0273】

2314において、鑑定スマートコントラクトは、ローンの返済時に、鑑定タスクに参加した鑑定者に報酬額を譲渡してもよい。ローンプロセスが完了すると（例えば、ローンの返済および担保アイテムが借り手に返却された後、または清算イベントの後）、一次鑑定者および鑑定タスクに参加した任意の二次鑑定者に報酬を発行してよい。例えば、鑑定者は、ローンまたは返済額の割合、予め定められた手数料、及び／または同様のもので報酬を得てもよい。ローンプロセスが完了すると、鑑定スマートコントラクトのインスタンスは、分解されてもよい。

【0274】

図２３の例は、鑑定ワークフローの例として提供されている。他の鑑定ワークフローは、鑑定タスクに関連して実行され得る。さらに、それぞれの鑑定ギルド内では、それぞれの鑑定ギルドのメンバーは、特定のタスクの鑑定を改善するために、鑑定ワークフローおよび／または鑑定スマートコントラクトを改良することができるが、そのような改良は鑑定ステージレベルのガバナンスに従ったものであることが条件である。

【0275】

図２０に戻って参照すると、保管ステージレベルのガバナンスは、鑑定タスクに使用され得る保管スマートコントラクト2032の参照（例えば、アドレス）を含んでもよい。参照は、（例えば、分散台帳2016から）保管スマートコントラクト2032を取得するために使用され得るアドレスを定義してもよい。これらの実施形態において、ローンプロセスのスマートコントラクト2022、鑑定者デバイス2006、および／またはトークン化プラットフォーム100は、保管者が新しい鑑定タスクを割り当てられたこと、および／または保管者が保管者デバイス2008を介して新しい保管タスクを受け入れることに応答して、保管スマートコントラクト2030のインスタンスをインスタンス化し得る。インスタンス化されると、鑑定者スマートコントラクト2030のインスタンスは、分散台帳2016に書き込まれ、そこで、保管スマートコントラクトインスタンスが実行されて、保管タスクを管理することができる。実施形態において、保管スマートコントラクト2032は、保管デバイス2008、借り手デバイス2002、及び／又はトークン化プラットフォーム100から入力を受信するように構成されてもよく、受信した入力に基づいて保管タスクに関連してすべての必要なステップが実行されたかどうかを決定する条件付きロジックを含んでもよい。

【0276】

図２４は、保管ワークフローを実行するために実行され得る方法2400の動作の一例を示す図である。方法2400は、保管スマートコントラクト2032またはローンプロセスのスマートコントラクト2022などのスマートコントラクトによって実行され得る。説明の便宜上、方法2400は、保管スマートコンタクトのインスタンスによって実行されるものとして説明される。

【0277】

2402において、保管スマートコントラクト2032のインスタンスは、保管者デバイス2008から担保アイテムの受取人の確認を受信してもよい。いくつかのシナリオでは、担保アイテムは、ローンの係属期間中に保管のために保管者に送られる。あるいは、担保物件は、借り手などの別の当事者によって、保管者に預けられることもある。いずれのシナリオにおいても、保管者は、鑑定者デバイス2006を使用して担保アイテムの受領を確認することができる。これらの実施形態において、保管者は、担保アイテムの画像を取り、アイテムに目に見えるあらゆる損傷を指摘することなどにより、受領時に担保アイテムを文書化することができる。

【0278】

2404において、保管スマートコントラクトインスタンスは、保管者の保管者デバイス2008から保管リポート及びサポート文書を受信してもよい。これらの実施形態において、保管者は、保管者が属する保管者ギルドの保管ステージレベルガバナンス及び／又はギルドレベルガバナンス（そのようなギルドが存在する限り）に従って保管リポートを生成するよう要求されてもよい。いくつかの実施形態では、保管者は、リポートを生成するために、保管者のステージレベルのガバナンスおよび/または保管者ギルドのギルドレベルのガバナンスに含まれるフォームテンプレートを使用することができる。リポートにおいて、保管者は、アイテムが受け取られたこと、受け取られた状態、担保アイテムに見られる損傷、アイテムが保管されている場所、アイテムが安全な保管場所にあるかどうか、及び／又は他の関連情報を示すことができる。実施形態において、保管者は、目立つダメージのあらゆる文書を含む担保アイテムの画像、保管中のアイテムの画像などのサポート文書を提供してもよい。保管者が安全保管リポートを提供すると、保管者リポート及びサポート文書は、分散台帳2016に書き込まれてもよい。

【0279】

2406において、保管リポートおよびサポート文書、ならびに二次鑑定者の見解に基づくデータブロックが生成され、データブロックは分散台帳2016に書き込まれてもよい。いくつかの実施形態において、保管スマートコントラクトは、データブロックを生成し、データブロックを分散台帳206に書き込んでもよい。あるいは、保管スマートコントラクトは、保管リポート、サポート文書、及び二次鑑定者の見解を台帳管理システム202（又は別の適切なシステム）に送信してもよく、台帳管理システムは、今度はデータブロックを生成し、データブロックを分散台帳2016に書き出してもよい。

【0280】

2408で、保管スマートコントラクトインスタンスは、保管中の財産損失または損傷に関連するリスクを軽減するために、保管庫から通貨の額をロックしてもよい。いくつかの実施形態では、保管スマートコントラクト2030は、貸し手により大きなセキュリティ額を提供するように、物品がセーフキープされるときにある額の通貨（例えば、通貨／トークン）をロックするために、保管ステージレベルのガバナンスおよび／またはギルドレベルのガバナンスに規定される要件を強制してもよい。実施形態では、ロックされる額は、ローン額、総返済額、評価額、または別の適切な値に等しいか、またはその割合であってよく、ロックされる額は、金庫保管ステージのガバナンスに従って定義される。いくつかの実施形態では、ロックされた通貨トークンは、保管された担保アイテムが損傷または紛失した場合の不測の事態を提供するように、保管庫からのロックされた通貨の額がローンの残額を超えないように、返済の過程で保管庫に戻される。2410において、保管者スマートコントラクトインスタンスは、担保アイテムが確保されたこと、及び保管者タスクに関連するイベントレコード2052が分散台帳2016に書き込まれたことを示す通知をローン処理スマートコントラクト2022に提供し得る。

【0281】

2412において、保管スマートコントラクトインスタンスは、償還イベント時に、担保アイテムに対応する担保トークン2042の所有者への担保アイテムの所有権の譲渡を促進してもよい。実施形態において、担保トークン2042の償還は、オフチェーン（例えば、トークン化プラットフォーム100などの信頼される第三者のコンピューティングシステムによって）および／またはオンチェーン（例えば、1つまたは複数のスマートコントラクトのインスタンスによって）実行され得る担保償還ワークフローに従って実行されてもよい。実施形態において、担保償還ワークフローは、以下の動作を含み得るが、これらに限定されない。それらは、担保トークン2042によって示される担保アイテムを償還する要求をユーザデバイスから受信すること、担保トークン2042を償還しようとしているユーザが、分散台帳2016に格納された所有権データ2052に基づいて担保トークン2042の正当な所有者であることを検証し、担保トークン2042によって示される担保アイテムの保管者を分散台帳2016及び／又はローンプロセスのスマートコントラクト2022から識別すること、権利者が担保トークン2042を償還したことを示す償還通知を、特定された保管者の保管者デバイス2008に送信すること、担保トークンの権利者が担保アイテムの所有権を取得したことを示す確認通知を特定された保管者の保管者デバイス2008から受け取ること、及び（上述したように）保管者からの通知を受け取ることに応答して担保トークンをバーンする（燃やす）こと、である。実施形態において、償還ワークフローは、担保アイテムが満足のいく状態で返却されたことを示す担保アイテムの償還所有者からのフィードバックを受信すること、及び／又はそのようなフィードバックイベントの発生及び内容を示すために分散台帳2016を更新すること（これは、分析及び／又は保管者の格付けを更新するために使用されてよい）などの追加又は代替ステップを含むことができる。

【0282】

2414において、保管スマートコントラクトは、ローンの返済および／または担保アイテムの償還時に、報酬額を保管者に譲渡してもよい。例えば、保管者は、ローン又は返済額のパーセンテージ、予め定義された手数料、及び／又はそのようなもので報酬を得てもよい。ローンプロセスが完了すると、保管者スマートコントラクトのインスタンスは、分解されてもよい。

【0283】

図２４の例は、例示的な保管ワークフローとして提供されている。他の保管ワークフローは、保管タスクに関連して実行され得る。さらに、保管者ギルド内では、それぞれのギルドのメンバーは、特定のアイテムの保管者を改善するために、保管者ワークフローおよび／または保管者・スマートコントラクトを改良することができるが、そのような改良は保管者ステージレベルのガバナンスに準拠していることが前提である。

【0284】

図２０に戻って参照すると、貸付ステージレベルガバナンスは、貸付の返済を監視するために使用され得る貸付スマートコントラクト2034の参照（例えば、アドレス）を含んでもよい。参照は、ローンスマートコントラクト2034を（例えば、分散台帳2016から）取得するために使用することができるアドレスを定義してもよい。これらの実施形態において、ローンプロセスのスマートコントラクト2022、借り手デバイス2002、貸し手デバイス2010、および／またはトークン化プラットフォーム100は、ローン合意が成立したことに応答して、ローンスマートコントラクト2034のインスタンスをインスタンス化し得る。実施形態において、ローンの交渉は、借り手および貸し手によってオフチェーンで（例えば、トークン化プラットフォーム100を介して）実行される。これらの実施形態において、ローンスマートコントラクトインスタンスは、ローン契約の条件に対する当事者の合意に応答してインスタンス化され得る。インスタンス化されると、ローンスマートコントラクトインスタンスは、分散台帳2016に書き込まれ、ローンスマートコントラクトインスタンスは、ローン返済ステージを管理するために実行されてもよい。実施形態において、ローンスマートコントラクト2034は、借り手デバイス2002、貸し手デバイス2010、および／またはトークン化プラットフォーム100から入力を受信するように構成されてもよい。

【0285】

図２５は、ローン返済ワークフローを実行するために実行され得る方法2500の動作の一例を示す。方法2500は、ローンスマートコントラクト2034またはローンプロセスのスマートコントラクト2022などのスマートコントラクトによって実行されてもよい。説明の便宜上、方法2500は、ローンスマートコントラクトのインスタンスによって実行されるものとして説明される。描かれた例では、ローンスマートコントラクト2034は、借り手と貸し手がオフチェーンでローン契約に合意した時点でインスタンス化されてもよい。しかしながら、いくつかの実施形態では、ローンコントラクト2032は、ローンの交渉を同様に促進するように構成されてもよい。

【0286】

2502において、ローンスマートコントラクト2034のインスタンスは、ローン契約条件を受信してもよく、ローン契約条件に従って返済スケジュールを確立してもよい。いくつかのシナリオでは、ローンスマートコントラクト2034は、ローン契約の交渉を促進したコンピューティングシステム（例えば、トークン化プラットフォーム）からローン契約条件を受信してもよい。ローン契約条件は、ローン金額、ローン期間、ローン返済額、金利、遅延料金ペナルティ、デフォルト条件定義などを含んでもよい。実施形態において、ローンスマートコントラクトインスタンスは、返済額及びローン期間に基づいて、返済スケジュールを決定してもよい。ローンスマートコントラクトインスタンスは、支払いがローン期間にわたって均等に分配されるように、返済スケジュールを決定してもよい。ローンスマートコントラクトインスタンスは、任意の他の適切な方法で返済スケジュールを決定してもよい。

【0287】

2504で、ローンスマートコントラクトインスタンスは、担保トークンをエスクローアカウントにロックし、貸し手のアカウントから借り手への資金の譲渡を促進する。実施形態において、ローン契約が成立すると、ローンスマートコントラクトインスタンスは、ローン返済期間の間、担保トークンをエスクローアカウントにロックしてもよい。担保トークンがロックされると、それによって、借り手が担保トークンを償還することを防止し、ローンスマートコントラクトインスタンスは、貸し手のアカウントから買い手のアカウントへのローン額に等しい資金の譲渡を促進してもよい。いくつかの実施形態では、ローンスマートコントラクトインスタンスは、貸し手によって所有される通貨／トークン2044のセットの所有データ2054を更新して、借り手のアカウントを反映させることによって、資金を譲渡してよい。

【0288】

2506で、ローンスマートコントラクトインスタンスは、支払いイベント通知を待機（リッスン）する。実施形態において、ローンスマートコントラクト2034は、支払いイベント通知を待機するイベントリスナーを備えて構成されてもよい。いくつかの実施形態では、支払いイベント通知は、借り手デバイス2002、貸し手デバイス2004、またはローンの返済を促進している信頼できる第三者コンピューティングシステム（例えば、トークン化プラットフォーム100）から受信されてもよい。実施形態において、支払いイベント通知は、支払われた額と、支払いが受け取られた日付及び／又は時刻とを示すことができる。

【0289】

2508で、ローンスマートコントラクトインスタンスは、予定された支払いが受け取られたかどうかを決定し得る。支払いが受け取られなかった場合、ローンスマートコントラクトインスタンスは、ローン契約に従って、ローンがデフォルト状態にあるかどうかを決定してもよい。ローンは、借り手が１つ以上の支払いを怠った場合に、デフォルト状態になる可能性があり、ローン契約は、ローンがデフォルト状態になる前に、何回支払いを怠ってもよいかを定義し得るようである。ローンがデフォルト状態にない場合、ローンスマートコントラクトインスタンスは、任意のペナルティ及び／又は手数料を元本残高に適用してもよく、支払いイベント通知を引き続きリッスンしてもよい。

【0290】

ローンがデフォルト状態にある場合、ローンスマートコントラクトインスタンスは、2512で示されるように、担保アイテムの清算を開始することができる。いくつかの実施形態では、ローンスマートコントラクトインスタンスは、担保トークン2042および／またはそこに包まれたVIRLを示す清算要求を市場（例えば、市場システム102）に提供してもよい。清算要求は、鑑定額、鑑定記録、認証記録、保管記録、および／またはローン返済額の残額などの追加データを含んでもよい。これに応答して、市場は、清算販売を実施することができる。実施形態において、清算販売は、固定価格販売（例えば、鑑定額で設定）又はオークション（例えば、ローン返済額の残額で開始）であってよい。アイテムが清算され、買い手が担保アイテムの代金を支払うと、ローン・スマートコントラクトインスタンスは、アイテムが清算されたことを示す清算通知を受信してもよい。これに応答して、ローン・スマートコントラクトインスタンスは、デフォルトされたローンを担保するために使用された担保トークン2042を、それが保持されていたエスクローアカウントから担保アイテムの買い手のアカウントに譲渡することを開始してもよい。担保トークンの所有権データ2054が、担保トークン2042が買い手によって所有されていることを示すように更新されると、買い手は、次に、担保トークン2042を償還してもよい（例えば、本開示全体を通じて説明されるように）。実施形態において、ローンの残額は、売却の収益から貸し手に支払われるだけでなく、ローンプロセスの参加者（例えば、認証者、鑑定者、および／または保管者）に対する報酬も支払われる。2514において、ローンスマートコントラクトインスタンスは、デフォルトイベントを示すデータブロックを生成してもよく、データブロックを分散台帳に書き込んで、それによって、デフォルトイベントの記録を作成してもよい。

【0291】

2508において支払いが受け取られた場合、ローンスマートコントラクトインスタンスは、2516に示すように、ローンが全額支払われているかどうかを決定してもよい。ローンが全額支払われていない場合、ローンスマートコントラクトインスタンスは、ローン返済額の残額を決定してもよい。いくつかの実施形態では、ローンスマートコントラクトインスタンスは、それぞれの認証、鑑定、および保管タスクの遂行に関連してトークンをステークしたギルドメンバーの通貨／トークン2044のロックを解除してもよい。実施形態では、ローンスマートコントラクトインスタンスは、2518で示すように、受け取った支払いに比例する額のトークンのロックを解除してもよい。これらの実施形態において、任意のギルドメンバーの残りのロックされたトークンは、ローン返済額の残額を超えない。

【0292】

2516において、ローンスマートコントラクトインスタンスが、ローンが全額支払われたと判断した場合、ローンスマートコントラクトインスタンスは、返済イベントを示すデータブロックを生成してもよく、1520に示すように、データブロックを分散台帳に書き出してもよい。このようにして、ローンスマートコントラクトインスタンスは、ローンが全額支払われたことを示す返済イベントのレコードを作成する。ローンが全額返済されると、ローンスマートコントラクトインスタンスは、ローンをガバナンスするローンプロセススマートコントラクトインスタンスに、および／またはトークン化プラットフォーム100に返済通知を発行し、通知が、ローンプロセスの参加者（例えば、認証者、鑑定者、および／または保管者）に報酬を授与するのを開始するようにしてもよい。

【0293】

2522において、ローンスマートコントラクトインスタンスは、エスクローアカウントから担保トークン2042のロックを解除してもよく、借り手に所有権を復活させてもよい。実施形態において、ローンスマートコントラクトインスタンスは、借り手が担保トークンの所有者であることを再び反映するために、担保トークン2042の所有権データ2054を更新してもよい。ローンプロセスが完了すると、保管スマートコントラクトのインスタンスは、解体されてもよい。

【0294】

図２５の例は、例示的なローン返済ワークフローとして提供される。他のローン返済ワークフローは、本開示の範囲から逸脱することなく、貸し付け及びローン返済に関連して実行され得る。

【0295】

図２０に戻って参照すると、いくつかの実施形態において、分散型ローンプロセスの異なるバリエーションは、ローン前清算イベントを含んでもよい。ローン前清算イベントは、ローンが交渉される前に実施される条件付き清算販売であってよい。売却は、価格が売却に先立って設定される設定価格売却であってもよいし、担保アイテムが競売される競売売却であってもよいことに留意されたい。いくつかの実施形態において、例示的なローンプロセスのワークフローは、要求ステージと、それに続く認証ステージ、安全保管ステージ、及びトークン化ステージ（任意の適切な順序で）と、それに続くローン前清算ステージと、それに続くローンステージ及び返済ステージとを含んでもよい。これらの例示的な実施形態では、担保アイテムが認証され、預託され、トークン化されると、担保アイテムに対してオークションまたは設定価格販売が行われ（例えば、市場システム102を介して）、それによって担保アイテムの買い手が、借り手のデフォルト時に（または借り手がローンを見送り、物品に対する所有権を放棄することに決定すると）トリガーされる所有権を取得する。このようにして、借り手及び貸し手は、ローンが交渉される前に担保アイテムの真の価値を知り、これにより、借り手がどれだけ借りることができるかが決定され、鑑定者の必要性が取り除かれる。さらに、いくつかの実施形態では、臨時の買い手は、購入アイテム（またはその一部）の金額に等しい額の通貨／トークン2046をエスクローすること、および／または（例えば、買い手のアカウントのアドレスを提供するか、銀行情報を提供することによって）売却をカバーするだけの資金があることを証明することを要求される場合がある。それと償還に、臨時の買い手は、借り手がローンの返済に成功した場合に返済額の一部を報酬として受け取ることができ、ここで報酬額は、定額料金、販売価格の割合、または金利ベースの報酬であってもよい。

【0296】

例示的な実施形態では、ローン前清算ステージを取り巻く規則及び規制は、ローン前清算ステージレベルのガバナンスで定義される。これらの実施形態において、ローン前清算ステージレベルのガバナンスは、臨時の買い手が臨時の販売を確保するために預けなければならない通貨の額、ローンが正常に返済された場合に臨時の買い手に提供される金銭報酬の額、ローン前清算イベントの許される仕組み（例えば、競売、セット価格販売など）、及び他の適切な規則及び規定などの規則を洗練及び／又は定義してもよい。

【0297】

いくつかの実施形態では、ローン前清算ステージレベルガバナンスは、ローン前清算イベントを促進する際に使用され得るローン前清算スマートコントラクト（図示せず）の参照（例えば、アドレス）を含んでもよい。参照は、（例えば、分散台帳2016から）ローン前清算スマートコントラクトを取得するために使用され得るアドレスを定義してもよい。これらの実施形態において、ローンプロセスのスマートコントラクト2022及び／又はトークン化プラットフォーム100は、ローンプロセスがローン前清算ステージに進行することに応答して、ローン前清算スマートコントラクトのインスタンスをインスタンス化してもよい。実施形態において、ローン前清算スマートコントラクトは、借り手デバイス2002、条件付き買い手デバイス、ローンプロセスのスマートコントラクト2022、ローンプロセスのスマートコントラクト2028、および／またはトークン化プラットフォーム100（例えば、市場システム102）から入力を受け取るように構成され得る。インスタンス化されると、ローン前清算スマートコントラクトのインスタンスは、分散台帳2016に書き込まれてもよく、ローン前清算スマートコントラクトインスタンスは、ローン前清算販売ステージ、取引検証ステージ、及び偶発的解決ステージを含んでもよいローン前清算ワークフローを実行する。例示的な実施形態では、ローン前清算スマートコントラクトは、ローン前清算売却ステージ中に担保アイテムの売却を開始し、担保アイテムに対応する担保トークンに基づいてローン前清算イベントを開始し得る。担保アイテムが（条件付きの事態に従って）売却されると仮定すると、ローン前清算スマートコントラクトは、取引検証ステージを実行してもよく、ここで、借り手は、a）売却価格を拒否してローンプロセスを終了する、b）売却価格で条件付き買い手に担保アイテムを売却しローンプロセスを終了することに同意する、又はc）与えられた売却価格でローンプロセスを進める機会を提供される。条件付き解決ステージの間、ローン清算スマートコントラクトインスタンスは、ローンが完全に返済された場合、ローン前清算スマートコントラクトが、エスクローアカウントから借り手への担保トークン2042の譲渡を開始し、定義された報酬額を偶発的買い手に報いるように、その後のローンの状態に関する通知を受信してもよい。逆に、販売者がデフォルトした場合、ローン生産前清算スマートコントラクトは、担保トークン2042をエスクローアカウントから買い手に譲渡してもよく、合意された購入価格を貸し手および参加者（例えば、認証者および保管者）に譲渡し、任意の残りの残高が借り手に返されるようにしてもよい。

【0298】

図２６は、本開示のいくつかの実施形態によるローン前清算ワークフローを実行するための方法2600の動作の一例を示す図である。方法2600は、ローン前清算スマートコントラクトまたはローンプロセスのスマートコントラクト2022などのスマートコントラクトによって実行され得る。説明の便宜上、方法2600は、ローン前清算スマートコントラクトのインスタンスによって実行されるものとして説明される。

【0299】

2602で、ローン前清算スマートコントラクトインスタンスは、担保トークン2052（または、担保トークンのブロックアドレスなどのその指標）を受け取る。2604で、ローン前清算スマートコントラクトインスタンスは、担保トークン2052に対応するVIRLを決定する。いくつかの実施形態では、ローン前清算スマートコントラクトインスタンスは、担保トークン2052から、および／または分散台帳2016から、VIRLのVIRL識別子を決定し得る。後者のシナリオでは、プレローンリキデーションスマートコントラクトインスタンスは、トークン2042を格納する分散台帳2016から担保トークン2042を含むデータブロックを読み出してもよく、そこからVIRL識別子を得てもよい。

【0300】

2606において、ローン前清算スマートコントラクトインスタンスは、市場（例えば、市場システム102）に担保アイテムの偶発的な売却の要求を提供してもよい。実施形態において、要求は、VIRL（またはVIRL IDなどのその指標）および／または担保アイテムを説明するおよび／もしくは示す他の文書を含んでもよい。実施形態において、臨時販売要求は、他の適切な情報、例えば、臨時販売タイプ（例えば、オークションまたは設定価格販売）、担保アイテムの場所、担保アイテムの求める価格（設定価格販売の場合）、担保アイテムの最低価格（オークションの場合）、臨時の長さ（例えば、借り手がローンを確保し返済するのに必要な時間）、報酬の提供（例えば、予め定義された報酬額、または購入価格、希望ローン額、または返済額の割合）、および／または同様のものである。これに応答して、市場は、偶発的販売を促進することができ、その結果、担保アイテムは、偶発的なセットで販売されるか（例えば、偶発的な買い手が担保アイテムを設定価格で購入するか、オークションに勝つ）、販売されないことがある。

【0301】

2608で、ローン前清算スマートコントラクトは、市場からコンティンジェントセールの結果を受信し得る。臨時販売が完了すると、市場は、ローン前清算イベントの結果を示す売却通知を清算スマートコントラクトインスタンスに送信することができる。実施形態において、ローン前清算イベントの結果は、アイテムが売却されたかどうか、及び売却された場合、アイテムが売却された価格（売却をホストするために市場が取った手数料を差し引いたもの）を示す。

【0302】

2610において、ローン前清算スマートコントラクトは、（担保アイテムのローン前売却が発生したと仮定して）借り手の借り手デバイス2002に臨時売却通知を提供し得る。）臨時販売通知を受信することに応答して、借り手は、ローンプロセスを進めるために臨時販売に同意すること、臨時販売を拒否すること（例えば、販売がオークションであり、合意した清算価格がローンを確保するには低すぎる場合）、または臨時販売を完了すること（例えば、販売がオークションであり、価格が買い手に、担保アイテムを使用してローンを求めるのではなく担保アイテムを売却するように確信させるには十分に高かった場合）、を選択肢として持つことができる。借り手が売却を拒否した場合、2612に示すように、担保トークン2042の所有権を保持する。借り手が臨時の売却を完了することに同意する場合、ローン前清算スマートコントラクトは、2614で示すように、担保トークン2042を臨時の買い手に譲渡し、売却の収益を買い手に譲渡すること（例えば、通貨／トークンまたは不換通貨での購入額から、市場が取った手数料を引く）を開始し得る。借り手がコンティンジェント売却に同意した場合、ローン前清算スマートコントラクトは、2616で示すように、担保アイテムをエスクローアカウントにロックしてもよい。

【0303】

2618において、ローン前清算スマートコントラクトインスタンスは、コンテント売却額に基づいて、コンテントバイヤーから定義された額の通貨をエスクローしてもよい。取引検証ステージにおいて、ローン前清算スマートコントラクトは、ローンがデフォルトになった場合に、臨時の買い手が販売価格を支払うことができることを保証するように構成されてもよい。いくつかの実施形態では、ローン前清算スマートコントラクトは、売却額全額または売却額全額の一部（例えば、50％）に等しい通貨／トークン2046をエスクローするようコンティンジェント買い手に要求してもよく、これは、コンティンジェント買い手のアカウントから通貨／トークン2046の規定額をエスクローアカウントにロックすることによって達成され得る。あるいは、臨時の買い手は、流動性閾値が満たされていることを証明するための証拠書類（例えば、銀行明細書、税金明細書など）を提供し、それによって、借り手がデフォルトした場合に、臨時の買い手が販売を完了する余裕があることを確信することができる。これらの実施形態において、ローン前清算スマートコントラクトインスタンスは、証拠書類を分散台帳2016に書き込んでもよい。

【0304】

2620において、ローン前清算スマートコントラクトインスタンスは、コンティンジェンシー売却を解決してもよい。借り手が条件に同意し、買い手が売却価格を支払うことができることを確認すると、ローン前清算スマートコントラクトインスタンスは、条件付き解決ステージを実行してもよい。条件付き解決ステージの間、ローン前清算スマートコントラクトインスタンスは、借り手がローンを確保することができたことを確認するために、ローンプロセスを監視してもよい。借り手がローンを確保することができず、ローンプロセスを終了することを決定した場合、ローン前清算スマートコントラクトは、条件付き買い手への任意のエスクローされた資金（および潜在的に報酬手数料）の払い戻しを開始してもよく、エスクローアカウントから借り手のアカウントへの担保トークン2042の譲渡を開始してもよい。借り手がローン契約を締結すると仮定して、ローン前清算スマートコントラクトは、ローンの返済を監視してもよい。いくつかの実施形態では、ローン前清算スマートコントラクトは、借り手がローン契約の条件に従ってローンの返済を不履行にしたとみなされる場合（例えば、ローンプロセスのスマートコントラクト2022又はローンを管理するローンスマートコントラクト2034から）、デフォルト通知を受信してもよい。これに応答して、ローン前清算スマートコントラクトは、（買い手によって全額がエスクローに入れられなかったと仮定して）担保アイテムの任意の残額を支払うようにコンティンジェント買い手に通知を提供し得る。条件付き買い手が価格の全残高を支払ったことを確認すると、又は買い手が条件付き売却時に売却価格全体を預託していた場合、ローン前清算スマートコントラクトは、売却額が確保された旨の通知を（例えば、ローンプロセスのスマートコントラクトインスタンス2022及び／又はローンスマートコントラクト2034に）発行し、臨時の買い手に担保トークン2052の譲渡を開始することができる。貸し手への資金の返済、及び／又は偶発的売却の収益からの保管者及び認証者（複数可）への報酬の発行は、異なるワークフローを介して処理され得ることに留意されたい。いくつかの実施形態において、ローン前清算スマートコントラクトは、借り手がローンの全返済額（ローン額および任意の利息および手数料）を正常に返済したときに、返済イベントの通知を受信してもよい。返済通知を受信すると、ローン前清算スマートコントラクトインスタンスは、賭けられた任意の資金を臨時の買い手に戻す譲渡を開始してもよく、臨時の販売に参加することによってローンの確保を助けるために資金を賭けた買い手に対する報酬として臨時の買い手のアカウントへの報酬（例えば、通貨／トークン2046）譲渡を開始してもよい。実施形態において、報酬額は、貸し手によって支払われてもよく、及び／又は、ローンの返済ステージ中に借り手によって貸し手に行われた支払いからエスクローで保持されてもよい。ローン前清算ワークフローは、本開示の範囲から逸脱することなく、追加の又は代替のステージを含んでもよい。

【0305】

図２６の例は、例示的なローン前清算ワークフローとして提供される。他のローン前清算ワークフローは、ローン前清算イベントに関連して実行されてもよい。

【0306】

図２０に戻って参照すると、本開示のいくつかの実施形態によれば、分散型ローンプロセスのそれぞれのステージに関連付けられたスマートコントラクトは、特定のタスクを実行するギルドメンバーが、ステージレベルのガバナンスだけでなく特定のギルドによって設定されたギルドレベルのガバナンスを遵守することを保証するように構成された様々なタイプのギルドレベルのスマートコントラクト（またはサブギルドレベルのスマートコントラクト）を含んでいてもよい。例えば、分散型ローンプロセスに関連するスマートコントラクトは、特に、認証プロセスのインスタンスが、特定の認証ギルドレベルガバナンス（例えば、ウォッチ認証ギルドレベルガバナンス）によって定義される認証ワークフローに適合することを保証するように構成されるギルドレベルの認証スマートコントラクトを含んでもよい。

【0307】

実施形態では、トークン化プラットフォーム100の1つまたは複数の構成要素は、証券化された分散型ローンプロセスをサポートする。いくつかの実施形態では、トークン化プラットフォーム100は、借り手（または他の当事者）から、ローンプロセスのインスタンスを開始するための要求を受信してもよい。例示的な実施形態において、担保管理システム804は、ユーザ（例えば、借り手）にGUIを提示してもよく、それによって、ユーザは、GUIを介して新しいローンプロセスの開始を要求することができる。例えば、ユーザは、場所又は一般的な地域、担保アイテムの種類（例えば、時計、スニーカーのペア、車、ウィスキーコレクション、宝飾品など）、及び借り手が確保することを望むおおよそのローン額を提供してもよい。いくつかの実施形態では、担保管理システム804は、要求を受信し、台帳管理システム104（または別の適切なシステム）に対して、新しいローンプロセスのスマートコントラクト2022をインスタンス化するように指示してもよい。実施形態において、ローンプロセスのスマートコントラクト2022は、分散型ローンプロセスの様々なステージを通じてローンプロセスを進行させることによって、ローンプロセスのワークフローを管理する。代替的に、担保管理システム2022は、ローンプロセスが分散型ローンプロセスのステージを通じて進行することによって、ローンプロセスのワークフローを管理してもよい。議論されたように、ローンプロセスのワークフローは、分散型ローンプロセスのインスタンスに関連して実行されるステージのセットを定義してもよく、ステージは、予め定義された順序で実行される。分散型ローンプロセスの異なるバリエーションは、異なるローンプロセスのワークフローを実装してもよい。ローンプロセスのワークフローの一連のステージの一例は、以下の通りであってもよい。ユーザが新しいローンプロセスを要求する要求ステージ、借り手が１以上の認証者によって認証される担保アイテムを提供する認証ステージ、アイテムが１以上の鑑定者によって鑑定される鑑定ステージ（アイテムが本物であるとみなされる場合）、担保アイテムが保管者によってエスクローに保管される保管ステージ、担保アイテムを表すVIRLが生成されてVIRLがトークン化されるトークン化ステージがそれに続く。に続き、借り手が１以上の貸し手とローンを交渉するローンステージと、貸し手がローンを返済するかまたはローンを不履行にする返済ステージと、販売者が返済額の少なくとも一部を不履行にした場合に担保アイテムを清算することができるローン後ステージとがあり、ローンプロセスの様々な参加者に報酬が発行され、及び／またはローンプロセスの結果に基づいて分析が更新される。前述のローンプロセスのワークフローは、例示的なローンプロセスのワークフローであり、他のローンプロセスのワークフローが開示され、本開示の範囲内である。異なるローンプロセスのワークフローは、異なる効率を達成し得、異なるタイプの担保及び／又はローンのサイズに対してより適している可能性があることに留意されたい。上述した例示的なローンプロセスのワークフローは、アイテムが認証者によって偽物とみなされた場合に実行されるステージの数を最小化することを意図している。他のワークフローは、担保アイテムが参加者間で譲渡される必要がある回数を減らすこと、担保アイテムを当事者間で譲渡する必要性を軽減すること、ローン額を最大化すること、及び／又は他の望ましい効率性など、異なる効率性を達成し得る。

【0308】

いくつかの実施形態では、担保管理システム804は、ユーザからの要求を受信したときに、ローンプロセスのワークフローのセットから特定のローンプロセスのワークフローを選択してもよい。これらの実施形態のいくつかでは、担保管理システム804は、借り手の場所、担保の種類、及び／又は借り手がローンで確保することを望む金額に基づいて、異なるローンプロセスのワークフローのセットから特定のローンプロセスのワークフローを選択してもよい。例えば、担保アイテムが、異なる参加者間で輸送することが大きい、及び／又は困難もしくは高価である場合（例えば、自動車、大量のワインもしくはウィスキーコレクション、珍しい絵画、又はクリスタルシャンデリア）、担保管理システム804は、場所間で担保アイテムを輸送するのではなく、認証者及び鑑定者に提供され得るVIRLを生成するのに用いられる写真、ビデオ、及び／又は他のサポートデータを保管者が取り得るように、（要求ステージの後の）保管ステージと、それに続くトークン化ステージから始まるローンプロセスのワークフローを選択してもよい。別の例では、アイテムがしばしば偽造されるタイプのアイテム（例えば、時計、ハンドバッグ、またはスニーカー）である場合、担保管理システム804は、他の任意のステージを進める前に認証者（複数可）がアイテムが偽物かどうかを決定し得るように、鑑定および／または保管の前に認証が生じるローン過程を選択してもよい。ローンプロセスのワークフローのいくつかのバリエーションは、追加の又は代替のステージを含んでもよいことに留意されたい。例えば、いくつかの実施形態において、ローンプロセスのワークフローは、本開示において説明されるように、ローン前清算イベントが実施されるローン前清算ステージを含んでもよい。

【0309】

実施形態において、担保管理システム802及び認証システム804は、台帳管理システム104と連携して動作し、分散型ローンプロセス全般の管理に使用される一連のスマートコントラクトインスタンスのインスタンス化又はその開始（例えば、ローンプロセスのスマートコントラクト2022）、及び／又はアイテム認証（例えば、認証スマートコントラクト2028）、アイテム鑑定（例えば、鑑定スマートコントラクト2030）、有事の清算イベント（例えば、清算スマートコントラクト）、アイテム保管（例えば、保管スマートコントラクト2032）、及び／又はローン生成／返済（例えば、ローンスマートコントラクト2034）などの分散型ローンプロセスのそれぞれのステージを管理するために使用される、一連のスマートコントラクトのインスタンス化を開始する。いくつかの実施形態では、担保管理システム802は、ローンプロセスのスマートコントラクト2022をインスタンス化してもよく、ローンプロセスのスマートコントラクト2022は、ローンプロセスのスマートコントラクト2022が特定の定義された条件が満たされたと判断してローンプロセスのワークフローを通じて進行するようにローンプロセスの１つ又は複数のステージを管理するスマートコントラクトを順にインスタンス化してもよい。

【0310】

いくつかの実施形態では、認証システム804は、ローンプロセスが異なるステージに進むにつれて、異なる参加者にタスクを割り当てるように構成されてもよい。実施形態において、認証システム804は、ローンプロセス中に参加者にタスクを割り当てるように構成されてもよい。特に、認証システム804は、認証タスクを認証者に、鑑定タスクを鑑定者に、及び／又は、金庫タスクを保管者に割り当てるように構成されてもよい。実施形態において、認証システム804は、要求の内容に基づいて、認証者、鑑定者、及び保管者を選択してもよい。例えば、認証者及び鑑定者が、特定のタイプのアイテムの認証又は鑑定を専門とするギルドに組織される実施形態では、認証システム804は、認証及び鑑定されるアイテムのタイプに基づいて、それぞれの認証ギルド又は鑑定ギルドを決定してもよい。例えば、時計の認証及び鑑定が行われている場合、認証システム804は、時計認証ギルド及び時計鑑定ギルドを関連するギルドとして特定してもよい。認証システム804は、特定したギルドから、認証タスクと鑑定タスクとを行うそれぞれのギルドメンバーを選択してもよい。全ての適格な保管者で構成される単一のギルドとは対照的に、保管者が専門的及び／又は地域的なギルドを有する限り、認証システム804は、ギルドのタイプ（例えば、自動車保管者、生鮮品の保管者等）に基づき、及び／又は特定のギルドと担保アイテムの近さ（例えば、担保アイテムがネバダ州にある又はその近くにある場合にネバダ州の保管者ギルドを選択する）に基づいて特定の保管者のギルドを選択してもよい。タスクを実行するためにギルドが識別されると（タスクがギルドメンバーに割り当てられる前にギルドが識別される必要があると仮定して）、認証システム804は、タスクを実行するためにギルドの１以上のメンバーを割り当ててもよい。

【0311】

実施形態では、認証システム804は、タスクを実行するためにギルドメンバーを識別するための多数の異なるアプローチを実施することができる。例示的な実施形態では、認証システム804は、ギルドメンバーがキューによって決定される順序でそれぞれのタスクに割り当てられる先入れ先出しのキューを使用することができる。例示的な実施形態では、認証システム804は、参加者を選択するためにラウンドロビン選択スキームを使用してもよい。実施形態において、認証システム804は、認証タスク及び鑑定タスクをギルドメンバーにランダムに割り当てる。例示的な実施形態では、認証システム804は、ギルドメンバーが、タスクを実行できる参加者のそれぞれの帯域幅などの一連の選択基準に基づいてそれぞれのタスクに割り当てられる、重み付け選択プロセスを使用してもよい（例えば、ギルドメンバー）、担保アイテムのブランドまたは亜種、それぞれの参加者の評価、それぞれの参加者の担保アイテムへのそれぞれの近接性、直近のタスクがそれぞれの参加者に割り当てられてからのそれぞれの時間長、それぞれの参加者が実行した成功タスクの数、それぞれの参加者が実行した失敗タスクの数、それぞれの参加者が行った成功または失敗タスクの割合、および／または同様のものなど、一連の選択基準に基づいてギルドメンバーがそれぞれのタスクに割り当てられる。実施形態では、認証システム804は、ギルドメンバーがタスクに入札することができ、ギルドメンバーが入札（及び／又は他の選択基準）に基づいて選択される入札システムを採用してもよい。実施形態において、入札は、ギルドメンバーがタスクを実行する価格であることを示していてもよい。これらの実施形態では、認証システム804は、入札額および／または選択基準に基づいてギルドメンバーを選択してもよく（例えば、入札額だけでなく他の任意の適切な選択基準を要因として取り込む選択モデルを使用して）、または借り手が認証者を選択してもよい（例えば、借り手がそれぞれの入札者に支払う必要があるそれぞれの手数料として入札額を提示され、さらにその場所と評価を示されてもよく、借り手は自分にとって最も理にかなっている入札者を選択する）。あるいは、入札は、ギルドメンバーがそれぞれのタスクを得るために支払うことを望む価格を示していてもよい。これらの実施形態では、認証システム804は、最高入札額に基づいてギルドメンバーを選択するように構成されてもよい。一次および二次参加者がタスクを実行するシナリオ（例えば、一次および二次認証者および一次／二次鑑定者）では、利用可能な参加者は、一次参加者になるための入札および／または二次参加者になるための入札を提供でき、一次参加者および1以上の二次参加者がそれぞれの入札に基づいて選択され、一次タスクを実行する権利の勝者は、二次タスクを実行する権利の勝者になれないように、することができる。認証システム804は、認証タスクまたは鑑定タスクを実行するギルドメンバーを選択するために、任意の他の適切な技術を採用してもよい。認証システム804が個人へのタスクを有すると、認証システム804は、選択された個人及び／又は問題となるローンプロセスを支配するローンプロセスのスマートコントラクト2022のインスタンスに通知を提供し得る。

【0312】

説明のために、認証システム804は、参加者にタスクを割り当てるものとして説明されるが、トークン化プラットフォーム100の他の適切な構成要素は、参加者にタスクを割り当ててもよい。代替的に、タスクの割り当ては、１つまたは複数のスマートコントラクトがタスクを参加者に割り当てるように構成され得るように、「オンチェーン」で処理され得る。例えば、ローンプロセスのスマートコントラクト2022のインスタンスは、ローンプロセスのインスタンスの実行中に参加者にタスクを割り当てるように構成され得る。加えて又は代替的に、ステージレベルスマートコントラクトのインスタンスは、ローンプロセスの過程でインスタンス化される際に参加者にタスクを割り当てるように構成されてもよい。後者の実装では、ステージレベルスマートコントラクトは、タスクを割り当てるために、選択基準及び／又は選択スキームの組合せを使用してもよい。例えば、ステージレベルスマートコントラクト（例えば。認証スマートコントラクト2028、鑑定スマートコントラクト2030、及び／又は保管スマートコントラクト2032）又はギルドレベルスマートコントラクト（ギルドがギルドレベルスマートコントラクトを有する場合）は、それぞれのタスクを、ランダムに、待ち行列に従って、入札プロセスを介して、ラウンドロビン方式で、及び／又は一連の選択基準に従って1人又は複数の参加者に割り当てるよう構成され得る 選択基準の例は、タスクを実行できる参加者のそれぞれのバンド幅（例えば。ギルドメンバー）、それぞれの参加者の評価、それぞれの参加者の担保アイテムへのそれぞれの近接性、それぞれの参加者に直近のタスクが割り当てられてからのそれぞれの時間額、それぞれの参加者が実行した成功タスクの数、それぞれの参加者が実行した失敗タスクの数、それぞれの参加者が実行した成功または失敗タスクのパーセント、および／または同様のものであることがある。

【0313】

いくつかの実施形態では、市場システム202（例えば、アイテム管理システム202（図２）は、担保アイテムの仮想表現（VIRL）を生成するように構成され、台帳管理システム104（例えば、トークン生成システム302）は、一つ以上のVIRLを担保トークンにトークン化するように構成されてもよい。借り手が単一のローンを担保するために複数のアイテムを担保することを望む場合、アイテム管理システム202は、異なる担保アイテムにそれぞれ対応するVIRLのセットを生成してもよく、一方、台帳管理システム102は、VIRLをそれぞれの担保トークン2042に個別にトークン化してもよく、またはVIRLのセットを包む単一の担保トークン2042でトークン化してもよいと理解される。VIRLおよびトークンを生成するための例示的な方法およびシステムは、図１～４に関して、および本開示全体を通して他の場所でより詳細に議論される。当初、台帳管理システム104は、担保トークン2042への所有権データ2054を分散台帳2019に書き込み、および／または担保トークン2042を借り手のアカウントに預けることにより、担保トークン2042の所有権を借り手に割り当ててもよい。借り手が対応する担保アイテムを保管者に提供した後でも、借り手は、担保トークン2042に対する所有権を維持することができる。借り手及び1つ以上の貸し手がローンに同意し、ローンを実行すると、担保トークン2042をエスクローアカウントに移し、担保トークン2042の所有権データ2054を更新して、担保トークン2042が現在エスクローで保持されていることを示すことにより、担保トークン2042を「ロック」してもよい。ローンが返済されると（例えば、借り手によって、またはデフォルト後の清算イベントの収益から）、担保トークン2042は、借り手（ローンが完全に返済された場合）または担保トークン2042の買い手（担保アイテムが清算された場合）のいずれかのアカウントに譲渡されることによってロックが解除される。担保トークンのロックを解除する際に、台帳管理システム104又はスマートコントラクト（例えば、スマートローンプロセススマートコントラクト2022又はローンスマートコントラクト3034のインスタンス）は、分散台帳2054の担保トークン2042に対応する所有権データ2054を担保トークン2042の所有者のアカウントを示すデータブロックで更新することにより、返済後の正当な所有者への担保トークン2042の譲渡を促進し得る。

【0314】

いくつかの実施形態では、担保管理システム802（またはトークン化プラットフォームの任意の他の好適な構成要素）は、借り手と貸し手との間のローン契約の交渉を容易にする。担保管理システム802は、任意の好適な方法でローン契約の交渉を促進するように構成されてもよい。いくつかの実施形態では、担保管理システム802は、借り手がローンを要求することを可能にするGUIを借り手に提供してもよい。担保アイテムが認証され、鑑定された（又は有事で買い取られた）と仮定して、担保管理システム802は、ユーザが、鑑定された価値を超えないローン額を要求し、ローンを返済する時間の長さを要求することを可能にしてもよい。これらの実施形態のいくつかにおいて、担保管理システム802は、GUIを介して潜在的な貸し手に提示されるローンリクエストを生成してもよく、それによってローンリクエストは、求める金額、ローンの長さ、及び借り手によって提供される担保アイテムに関連する情報を示す。担保アイテムに関連する情報は、担保アイテムのVIRL（画像、説明、動画、及び他の適切な情報を含み得る）、認証リポート、鑑定リポート、保管リポート、認証、鑑定、及び保管者がそれぞれのタスクを確保したことの検証（上述）、及び／又は同様のものを含んでもよい。実施形態において、担保管理システム802は、ローンのためのローン返済額及び／又は金利（例えば、現在の市場状況に基づく）を提案してもよい。代替的に、潜在的な貸し手は、GUIを介して、借り手が返済しなければならないであろう金利又は総返済額を提供してもよい。さらに、潜在的な貸し手は、ローン額及び／又は返済期間などのローン条件のうちの1つ又は複数を提示してもよい。その後、ローンオファーは、GUIを介して借り手に伝達されてもよく、借り手は、借り手デバイス2002を介してローンオファーを見ることができる。これに対して、借り手は、ローンオファーを受け入れるか、ローンオファーを拒否するか、またはカウンターオファーを提供することができる。当事者は、合意に達するか、一方または両方の当事者がローンの申し出を拒否するまで、このような方法を繰り返すことができる。ローンが合意されると、当事者は、ローン合意を実行してもよく、担保管理システム802は、ローン合意が借り手によって合意されたことを示す通知をローンプロセスのスマートコントラクトに提供してもよく、貸し手は、ローン合意の詳細を（例えば、JSONファイルにおいて）スマートコントラクトに提供してもよい。これに応答して、ローンプロセスのスマートコントラクト2022（又は担保管理システム802）は、上述の方法で、ローン返済ワークフローを実行するローンスマートコントラクトインスタンスをインスタンス化することができる。いくつかの実施形態において、スマートコントラクトインスタンス（例えば、ローンプロセスのスマートコントラクト2022のインスタンス又はローンスマートコントラクトのインスタンス）が、上記の方法でローン契約の交渉を促進するように、ローン交渉がオンチェーン処理されてもよいことが理解される。ローンが交渉されると、担保トークン2042は、エスクローアカウントにロックされてもよく、ローンの返済は、ローンスマートコントラクトインスタンスによって処理され得る。ローンが全額返済されると、担保トークン2042はロック解除されて借り手に返されてもよく、それによって、トークン2042の所有権データ2052は、借り手が担保トークン2052の所有者であることを反映して更新され、借り手は、担保アイテムを再び所有するためにトークン2052を償還してもよい。借り手がローン契約の条件に従ってローンを正常に返済しない場合、ローン契約インスタンスは、ローンを不履行とみなしてもよい。

【0315】

いくつかの実施形態では、ローンのデフォルトは、担保トークン2042がローンの残額をカバーするために清算される、清算ステージをトリガーしてもよい。実施形態において、清算ステージは、借り手がローン契約に従ってローンを不履行にしたときに自動的にトリガーされてもよい。実施形態において、スマートコントラクトインスタンス（例えば、ローンプロセスのスマートコントラクト2022のインスタンス又はローンスマートコントラクト2036のインスタンス）は、ローンの返済に向けて借り手によって行われた支払いを示す支払いイベント通知を受信してもよい。支払期日が来るたびに、スマートコントラクトインスタンスは、支払が受け取られたかどうかを判断してもよい。予定の支払いが滞った場合、スマートコントラクトインスタンスは、借り手がデフォルト状態であるかどうかを判断してもよい。デフォルト状態は、必ずしも１回の支払いの欠落でなくてもよいが、ローン契約において、多数の連続した支払いの欠落またはローン返済額に対する一定額の支払いの遅れと定義されてもよい。借り手がデフォルト状態にある場合、スマートコントラクトインスタンスは、清算イベントをトリガーしてもよい。いくつかの実施形態では、スマートコントラクトは、担保トークン2042および／またはそこに包まれたVIRLを示す市場（例えば、市場システム102）に対して清算要求を発行してもよい。清算要求は、鑑定額、鑑定記録、認証記録、保管記録、および／またはローン返済額に対する残額などの追加データを含んでもよい。これに応答して、市場は、清算販売を実施することができる。実施形態において、清算販売は、固定価格販売（例えば、鑑定額で設定）又はオークション（例えば、ローン返済額の残額で開始）であってよい。アイテムが清算されると、スマートコントラクトインスタンスは、アイテムが清算されたことを示す清算通知を受信してもよい。これに応答して、スマートコントラクトインスタンスは、デフォルトされたローンを担保するために使用された担保トークン2042を、それが保持されていたエスクローアカウントから担保アイテムの買い手のアカウントに譲渡することを開始してもよい。担保トークンの所有権データ2054が、担保トークン2042が買い手によって所有されていることを示すように更新されると、買い手は、次に、（例えば、本開示全体を通して説明されるように）担保トークン2042を償還してもよい。

【0316】

担保トークン2042の所有権を取得すると、担保トークン2042の所有者は、トークンを償還することができる（例えば、トークンの償還を開始するためのメカニズムを提供するGUIを使用して）。担保トークンの償還は、トークン化プラットフォーム100の償還システム404などの信頼できる第三者によってオフチェーンで処理されてもよく、及び／又は完了したローン取引に対応するスマートコントラクトのインスタンスによってオンチェーンに処理されてもよい。例えば、ローン取引を管理したローンプロセスのスマートコントラクト2022のインスタンス、及び／又は担保アイテムが担保アイテムの保管者に預けられたときに作成されたセーフキースマートコントラクト2032のインスタンスなど、担保アイテムが信頼できる方法で正しい所有者に戻されることを保証するために、保管者が担保アイテムを正しい所有者に戻していることに自信を持てるような、信頼できる方法で担保アイテムを正しい所有者に戻すことができる。

【0317】

実施形態において、担保トークン2042の償還は、オフチェーン（例えば、信頼できる第三者のコンピューティングシステムによって）またはオンチェーン（例えば、１つまたは複数のスマートコントラクトのインスタンスによって）実行され得る担保償還ワークフローに従って実行され得る。実施形態において、担保償還ワークフローは、以下の動作を含んでもよいが、これらに限定されるものではない。それらは、担保トークン2042によって示される担保アイテムを償還する要求をユーザデバイスから受信すること、担保トークン2042を償還しようとしているユーザが、分散台帳2016に格納された所有権データ2052に基づいて担保トークン2042の正当な所有者であることを検証し、担保トークン2042によって示される担保アイテムの保管者を分散台帳2016及び／又はローンプロセスのスマートコントラクト2022から識別すること、権利者が担保トークン2042を償還したことを示す償還通知を、特定された保管者の保管者デバイス2008に送信すること、担保トークンの権利者が担保アイテムの所有権を取得したことを示す確認通知を特定された保管者の保管者デバイス2008から受け取ること、及び（上述したように）保管者からの通知の受信に応じて担保トークンをバーンすること、である。実施形態において、償還ワークフローは、担保アイテムが満足のいく状態で返却されたことを示す担保アイテムの償還所有者からのフィードバックを受信すること、及び／又はそのようなフィードバックイベントの発生及び内容を示すために分散台帳2016を更新すること（これは、分析及び／又は保管者の格付けを更新するために使用されてよい）などの追加又は代替ステップを含んでもよい。

【0318】

実施形態において、トークン化プラットフォーム100は、実行されたローンプロセスの様々なステージについて分析を実行するように構成される。これらの実施形態のいくつかでは、分析およびリポートシステム112は、分散台帳2016のセットからイベント記録2052および／またはサポートデータ2056を取得して、偽陽性認証（例えばアイテムが本物とみなされたが後に偽物であると証明された場合）などの否定的な結果を含むローンプロセスに関連する結果を決定するように構成されてもよい、偽陰性認証（例えばアイテムが偽物とみなされたが後に本物であると証明された場合）、過大評価鑑定、過小評価鑑定、保管中の担保アイテムの破損または損失、ローンデフォルト、またはそのようなものである。例えば、分析およびリポートシステム112は、各ギルドおよび／またはギルドメンバーによって発行された偽陽性認証の割合などの認証関連統計値を決定するように構成されてもよい。この例では、分析およびリポートシステム112は、ギルドまたはギルドメンバーによって本物であるとみなされ、後に買い手によって偽物であるとリポートされた（これは「偽陽性」と呼ばれ得る）清算品に関連する任意のイベントレコード2052を、ギルドまたはギルドメンバーによって行われた認証の総数に対して読み取ることができる。別の例では、分析およびリポートシステム112は、認証タスクが過小評価または過大評価された鑑定価値をもたらしたインスタンスを特定してもよい。この例では、分析およびリポートシステム112は、すべての鑑定および／または成功した鑑定の数（例えば、清算価値の一定割合以内）との関連で、鑑定者によって提供された鑑定価値よりも低く（清算価値から一定割合で過大評価）または高く（清算価値から一定割合で過小評価）売却された清算品と関連するイベントレコード2052の数を決定してもよい。次に、これらのタイプの統計的洞察は、成功したケースと共有されない負の結果（例えば、偽陽性ケース、偽陰性ケース、過小評価ケース、過大評価ケース、及び／又は損失若しくは損傷した担保ケース）をもたらすタスクの共通の特徴を特定するために使用されてもよく、場合によっては、これらの特徴を緩和するためにステージレベルのガバナンスを調整してもよい。

【0319】

別の例では、アナリティクス及びリポートシステム112は、タスク実行者（例えば、認証者及び／又は鑑定者）によるターンオーバー時間を決定してもよい。この例では、分析およびリポートシステム112は、タスクがローンプロセスを持つ特定の参加者に割り当てられた時を示すイベントレコード2052、およびそれらの参加者がタスクを終了した時を示すイベントレコード2052など、ローンプロセスの特定の部分に関連する様々なイベントレコード2052を取得してもよい。次に、分析およびリポートシステム112は、タスクの各インスタンスを完了する時間を決定してもよく、個々のギルドメンバーに対する平均ターンオーバー時間、ギルドまたはサブギルド全体に対する特定のタスクの平均ターンアラウンド時間、すべてのステージ参加者に対する平均ターンアラウンド時間、特定のタイプの担保アイテムまたは担保アイテムの亜種に対する平均ターンアラウンド時間などの様々な分析的洞察を決定することができる。これらの洞察は、将来のガバナンスにおいてタスクに時間制約を設定し、時間制約が満たされない場合に参加者の報酬を少なくするために使用されてもよい。

【0320】

実施形態において、アナリティクス及びリポートシステム112は、借り手、認証者、鑑定者、保管者、及び／又は貸し手など、ローン・プロセス・エコシステム2000における異なる参加者に評価を提供するように構成されてもよい。実施形態において、分析およびリポートシステム112は、借り手による返済成功対デフォルトイベント、認証者による偽陰性／偽陽性対認証成功、鑑定者による過小評価および／または過大評価対鑑定者による鑑定成功、担保アイテムの損傷または喪失のインスタンス対保管人による保管作業成功など、様々な異なる参加者に関連するネガティブおよびポジティブ結果を決定してもよい。アナリティクス及びリポートシステム112は、他の参加者のフィードバックなど、参加者に関連する追加の又は代替のデータを収集してもよい。次に、分析およびリポートシステム112は、参加者にスコアを割り当てるために、参加者に関連する結果および他のフィードバックデータにスコアリング関数を適用してもよい。これらのスコアは、タスクを割り当てるとき、ギルドトークンを授与するとき、参加者に報酬を与えるとき、及び／又はそのようなものに関連する可能性がある。

【0321】

実施形態において、アナリティクス及びリポートシステム112は、分散台帳からデータを取得してもよい。これらの実施形態のいくつかにおいて、アノードデバイス2014は、分散台帳2016に書き込まれているすべてのデータブロックを監視する「履歴ノード」として構成されてもよい。履歴ノードデバイスは、各ブロックが台帳2016に書き込まれているときに処理し、インデックスを付けてもよく、この情報を分析およびリポートシステム112に提供してもよい。分析およびリポートシステム112は、次に、履歴ノードによって収集されたデータに対してその分析を実行してもよい。アナリティクス及びリポートシステム112は、本開示の範囲から逸脱することなく、他の適切な様式で分散台帳2016からデータを収集してもよい。

【0322】

図２７は、本開示のいくつかの実施形態によるローンプロセスのワークフロー2700の例を示している。図２７の例では、ローンプロセスのワークフローは、時計、宝飾品、ハンドバッグ、スニーカーなどの偽造されやすい担保アイテムに対して実行されてもよい。図２７の例では、ローンプロセスのワークフロー2700は、以下を含んでもよい。それらは、借り手がローンプロセスの開始を要求する要求ステージ2702、１以上の認証者が１つ以上のアイテムを認証する認証ステージ2704、次いで、認証された物品が鑑定される鑑定ステージ2706、鑑定されたアイテムが信頼できる保管者に預けられる保管ステージ2708、および、次いで、台帳管理システム104（または別の適切なコンポーネント）が１つまたは複数の預けられたアイテムのVIRLを生成し、預けられたアイテムのVIRLをトークン化して担保トークンを生成するトークン化ステージ2710、借り手および貸し手によってローンが交渉され、受け入れられる貸し付けステージ2712、次いで、借り手によってローンが返済される返済ステージ2714、次いで、担保トークンがロック解除されて借り手に返却されるか、借り手がローンをデフォルトした場合に清算されて、ローンプロセスの参加者に任意の報酬が発行される貸し付け後ステージ2716である。

【0323】

要求ステージ2702の間、借り手は、借り手が所有するアイテムを担保にすることを含む新しいローンプロセスを開始するよう要求することができる。実施形態において、借り手は、トークン化プラットフォーム100とインターフェースする借り手デバイス2002を介してローンを要求してもよい。これらの実施形態では、トークン化プラットフォーム100（または別の適切なシステム）は、借り手が、担保に入れるべき担保アイテム、担保アイテムの場所、求めるローン額、および／または提案されたローン期間などの情報を提供し得るGUIを提供してもよい。借り手の要求に応答して、トークン化プラットフォーム100は、ローンプロセスのスマートコントラクトインスタンスをインスタンス化してもよい。実施形態において、ローンプロセスのスマートコントラクトインスタンスは、（例えば、借り手によって提供された要求から）担保アイテムのタイプを決定してもよく、担保アイテムを認証するために認証者（及び潜在的に二次認証者）を要求してもよく、それによって、ローンプロセスを認証ステージ2704に進行させることができる。

【0324】

認証ステージ2704の間、ローンプロセスのスマートコントラクトインスタンスは、認証スマートコントラクト2028のインスタンスをインスタンス化してもよい。実施形態において、トークン化プラットフォーム100は、上述のように、担保アイテムのようなアイテムの認証を専門に行う認証ギルドからの一次認証者（および潜在的に二次認証者）に認証タスクを割り当ててもよい。実施形態において、一次認証者は、認証者デバイス2004を介して、認証されるアイテムの受領を確認してもよい。実施形態において、認証者は、担保アイテムの真正性に対する判定を示す認証リポート、及び任意のサポート文書を生成してもよい。実施形態において、認証リポート及びサポート証拠は、1つ以上の二次認証者に提供されてもよく、二次認証者は、順に、認証リポートを検証してもよく、追加のサポート文書を提供してもよい。実施形態において、認証リポートおよび任意のサポート文書は、分散台帳2016に書き込まれてもよい。いくつかの実施形態では、認証タスクに参加した認証者は、アイテムが清算され、後に偽物とみなされた場合のセーフガードとして、通貨／トークンの額を出資するよう要求されてもよい。例示的な実施形態では、ローンプロセスのスマートコントラクト2022は、アイテムが認証者（複数可）によって本物であったか、または偽物とみなされたかを示すインスタンス化された認証スマートコントラクト2028によって発行された認証通知を待機（リスニング）する待機スレッドを含み得、認証スマートコントラクト2028からの通知は、認証者の見解（例えば、偽物または本物）、認証リポートおよびその他の支持証拠のハッシュ値、ならびに／または認証リポートおよび支持証拠へのブロックアドレスを含んでもよい。ローンプロセスのスマートコントラクトインスタンスが、アイテムが真正とみなされたと判断した場合、ローンプロセスのスマートコントラクトインスタンスは、ローンプロセスを鑑定ステージ2706に進めてもよい。

【0325】

鑑定ステージ2706の間、ローンプロセスのスマートコントラクトインスタンスは、認証されたアイテムを鑑定するために１人または複数の鑑定者を要求してもよく、鑑定スマートコントラクト2030のインスタンスをインスタンス化してもよい。実施形態において、トークン化プラットフォーム100は、上述したように、担保アイテムのタイプに基づいて、タスクを実行する1または複数の鑑定者を識別してもよい。実施形態において、一次鑑定者は、担保アイテムを（例えば、郵便または他の発送を介して）受け取ってよく、および／または担保アイテムのVIRLを受け取ってよい。アイテムが認証機関によって真正とみなされたことを知っている鑑定者は、担保アイテムの鑑定価格を決定してもよく、鑑定価格及び鑑定価格を支持する任意の支持文書を示す鑑定リポートを生成してもよい。いくつかの実施形態では、１人以上の二次鑑定者は、鑑定リポートを検証してもよく、それぞれの検証のためのサポート文書を提供してもよい。実施形態において、鑑定リポート及び任意のサポート文書は、分散台帳2016に書き込まれてもよい。いくつかの実施形態では、鑑定タスクに参加した鑑定者は、アイテムが返済額および／または鑑定額の残額を大幅に下回る価格で清算された場合のセーフガードとして、担保アイテムの鑑定額に等しいまたは比例する額の通貨／トークンを出資するよう要求されてもよい。実施形態において、鑑定スマートコントラクト2030は、鑑定ワークフローが正常に完了したことを示す通知をローン処理スマートコントラクト2022に送信してもよく、通知は、鑑定価値、鑑定書及び他のサポート証拠のハッシュ値、及び／又は鑑定書及びサポート証拠へのブロックアドレスを含んでもよい。鑑定ステージが完了したと決定すると、ローンプロセスのスマートコントラクト2022は、ローンプロセスを保管ステージ2708に進めてもよい。

【0326】

保管ステージ2708の間、ローンプロセスのスマートコントラクトインスタンスは、鑑定されたアイテムを保管するために保管者を要求してもよく、保管ワークフローを実行する保管スマートコントラクト2032のインスタンスをインスタンス化してもよい。実施形態において、トークン化プラットフォーム100は、例えば、担保アイテムの種類及び／又は担保アイテムへの保管者の近接性に基づいて、保管者を保管タスクに割り当ててもよい。保管者がアイテムの受領を確認すると、保管者は、アイテムが保管されていることを示す保管リポートを生成し、担保アイテムが受領され検査された時点の担保アイテムに対するあらゆる損傷、及び保管リポートを支持するあらゆる支持文書に留意してもよい。実施形態において、保管リポート及び任意のサポート文書は、分散台帳2016に書き込まれてもよい。いくつかの実施形態では、保管者は、担保アイテムが保管中に紛失または破損した場合の安全デバイスとして、担保アイテムの評価額と等しいまたは比例する額の通貨／トークン化トークンを出資することを要求されてよい（または保険の証明を提供してもよい）。実施形態において、保管スマートコントラクトインスタンスは、その後、アイテムがエスクローに安全に保管されたことを示す通知をローン処理スマートコントラクトインスタンスに提供してもよく、通知は、保管リポートのハッシュ値および任意の他の支持証拠および／または保管リポートおよび支持証拠へのブロックアドレスが含まれてもよい。通知に応答して、ローンプロセスのスマートコントラクトは、ローンプロセスをトークン化ステージ2710に進めてもよい。

【0327】

トークン化ステージ2710の間、トークン化プラットフォーム100（または別の適切なコンポーネント）は、担保アイテムをトークン化することを生成してもよい。実施形態において、トークン化プラットフォーム100は、担保アイテムの説明、画像、ビデオ、2Dスキャン、および／または3Dスキャンなど、担保アイテムを説明および／または描写するデータに基づいて、担保アイテムのVIRLを生成してもよい。実施形態において、借り手、保管者、および／または認証者は、VIRLを生成するために使用されるデータを提供してもよい。実施形態において、トークン化プラットフォーム100は、担保アイテムのVIRLに基づいて、アイテムの担保トークンを生成する。アイテムがトークン化されると、トークン化プラットフォーム100は、分散台帳2016にトークンを書き込んでよく、（ローン契約が成立するまで）担保トークンの所有権を借り手に最初に割り当ててもよい。担保アイテムがトークン化されると、トークン化プラットフォーム100は、トークン化イベント及び／又は担保トークンのアドレスを示す通知をローンプロセスのスマートコントラクト2022に提供してもよい。トークン化イベントの通知を受信すると、ローンプロセスのスマートコントラクト2022は、ローンプロセスを貸し付けステージ2712に進めてもよい。

【0328】

貸し付けステージ2712の間、借り手は、ローンを要求してもよく、及び／又は、1人以上の貸し手とローンを交渉してもよい。貸し手及び借り手がローン条件に合意したという確認を受けると、ローンプロセスのスマートコントラクト2022は、合意されたローン条件に従ってローンスマートコントラクト2034をインスタンス化してもよい。いくつかの実施形態では、トークン化プラットフォーム100は、借り手が1つまたは複数の潜在的な貸し手にローンを要求すること、および／または1つまたは複数の貸し手とローン契約を交渉することを可能にするGUIを借り手に提供し得る。いくつかの実施形態では、ローン交渉は、トークン化プラットフォーム100などの集中型サービスを経由するのではなく、オンチェーンで処理されてもよいことが理解される。実施形態において、借り手は、評価額を超えないローン額と、ローンを返済するための時間長を示す提案されたローン条件とを要求してもよい。これらの実施形態のいくつかでは、トークン化プラットフォーム100は、GUIを介して潜在的な貸し手に提示されるローン要求を生成してもよく、それによって、ローン要求は、求める金額、ローンの長さ、および借り手が提供した担保アイテムに関する情報（例えば、担保アイテムのVIRL、認証リポート、鑑定リポート、保管リポート、認証、鑑定および保管者がそれぞれのタスクを確保したこと（上述）、および／または同様のもの）を示している。実施形態において、トークン化システム100は、ローンの返済額および／または金利（例えば、現在の市場条件に基づいて）を提案してもよい。代替的に、潜在的な貸し手は、GUIを介して、借り手が返済しなければならないであろう金利または総返済額を提供してもよい。さらに、潜在的な貸し手は、ローン額及び／又は返済期間など、要求されたローン条件のうちの１つ又は複数に対抗してもよい。その後、ローンオファーは、GUIを介して借り手に伝達されてもよく、借り手は、借り手デバイス2002を介してローンオファーを見ることができる。これに対して、借り手は、ローンオファーを受け入れるか、ローンオファーを拒否するか、またはカウンターオファーを提供することができる。当事者は、合意に達するか、一方または両方の当事者がローンの申し出を拒否するまで、このような方法を繰り返すことができる。ローンが合意されると、当事者は、ローン合意を実行してもよく、トークン化プラットフォーム100は、ローン合意が借り手と貸し手とによって合意されたことを示す通知をローンプロセススマートコントラクトインスタンスに提供してもよい。実施形態において、通知は、ローン契約の条件を含むローン契約の詳細を含んでもよい。これに応答して、ローンプロセスのスマートコントラクトインスタンスは、ローン返済ワークフローを実行するローンスマートコントラクトインスタンスをインスタンス化してもよい。ローン契約が実行されると、ローンスマートコントラクトは、担保トークンをエスクローアカウントにロックしてもよく、貸し手のアカウントから借り手のアカウントへの資金の譲渡を促進してもよい。実施形態において、ローン契約、任意のオファー／カウンターオファーの記録、及び担保トークンのエスクロー及び借り手への譲渡資金に関連する記録は、分散台帳2016に書き込まれてもよい。ローンプロセスのスマートコントラクトインスタンスが、担保トークンがロックされ、資金が送金されたという通知を受信すると、ローンプロセスのスマートコントラクトインスタンスは、ローンプロセスを返済ステージ2714に進めてもよい。

【0329】

返済ステージ2714の間、ローンスマートコントラクトインスタンスは、借り手によって貸し手（または貸し手に支払いを分配するアカウント）に支払いがローンスケジュールに従って行われ、ローンがデフォルト状態でないことを保証するために、借り手の支払い履歴を監視してもよい。ローン返済のステージでは、借り手は支払いを送金することができます。支払いが行われるたびに、ローン処理スマートコントラクトインスタンスは、支払いが行われたこと及び支払いの金額を示す支払い通知を受信してもよい。その後、ローンスマートコントラクトインスタンスは、ローンが全額返済されたか否かを判断してもよい。ローンが全額返済されていない場合、ローンスマートコントラクトインスタンスは、ローン返済額を調整してもよく、新しいローン返済額を反映するために認証者、鑑定者、及び／又は保管者から賭けられた資金の一部を戻すなどの追加のオペレーションを実行してもよい。ローン返済額が全額支払われたとローンスマートコントラクトインスタンスが判断した場合、ローンスマートコントラクトインスタンスは、ローンが全額支払われたことを示す返済通知をローンプロセスのスマートコントラクトインスタンスに送信してもよく、ローンプロセスをローン後ステージ2716に進ませてもよい。実施形態において、返済通知は、支払いが行われたことを示す支払いイベントレコードのハッシュ値、及び支払いの金額、及び／又は分散台帳2016上の支払いレコードのアドレスを含んでもよい。逆に、ローンスマートコントラクトインスタンスが、借り手がデフォルトになったと判断した場合、ローンスマートコントラクトインスタンスは、清算イベントをトリガーしてもよく、及び／又はローンの条件に従ってローンがデフォルトであることを示すデフォルト通知をローンプロセススのマートコントラクトに送ってもよい。実施形態において、デフォルト通知は、どの支払いが滞り、ローンの残額を示すデフォルトイベントレコードのハッシュ値及び／又は分散台帳2016上のデフォルトイベントレコードのアドレスを含んでもよい。デフォルト通知を受信することに応答して、ローンスマートコントラクトインスタンスは、リケーションイベントを開始してもよく、ローンプロセスをローン後ステージ2716に進めてもよい。

【0330】

ローン後ステージ2716の間、担保トークンは、ローンが完全に支払われた場合に所有者に返却されるか、または清算イベントが実施されるかのいずれかである。ローンが全額返済されたという返済通知の受信に応答して、ローンスマートコントラクトインスタンスは、エスクローアカウントから借り手のアカウントへの担保トークンの譲渡を開始してもよく、借り手は次に担保トークンを償還して担保アイテムの所有権を取得することができる。ローンが正常に返済されると、ローンプロセスのスマートコントラクトインスタンスは、認証スマートコントラクト、鑑定スマートコントラクト、及び保管契約に定められた条件に従って、認証者、鑑定者、及び保管者のアカウントに（例えば、貸し手に返済された資金から）報酬を授与することを開始し得る。

【0331】

清算イベントを開始する際に、ローンスマートコントラクトインスタンスは、担保トークンのアドレスを適切な市場（例えば、市場システム102）に送信してもよく、市場は担保アイテムを（例えば、オークションで）清算することができる。）清算イベントの間、買い手は、担保トークンを購入してもよく、その結果、担保トークンの所有権データ2054が買い手に割り当てられ、買い手は、担保トークンを換金して担保アイテムの所有権を取得してもよい。清算されると、ローンプロセスのスマートコントラクトインスタンスは、清算イベントの収益から、未払い残高の残りを貸し手（又は、ローンが二次貸し手に売却された場合には二次貸し手）に分配してよい。清算イベントの後、ローンプロセスのスマートコントラクトインスタンスは、認証スマートコントラクト、鑑定スマートコントラクト、及び保管契約に定められた条件に従って、清算イベントの収益から認証者、鑑定者、及び保管者のアカウントに報酬を授与することを開始してもよい。残額がある限り、残額は借主のアカウントに入金することができる。

【0332】

ローンプロセスが完了すると、ローンプロセスのスマートコントラクトインスタンスは、ローンプロセスが完了したことをトークン化プラットフォーム100に通知してもよく、トークン化プラットフォーム100は、完了したローンプロセスに基づいて分析プロセスを実行してもよい。いくつかの実施形態では、ローンプロセスの結果は、認証者、鑑定者、保管者、貸し手、および／または借り手のうちの1つまたは複数の評価を更新するために使用されてもよい。

【0333】

上述した説明は、分散型ローンプロセスのワークフロー2700の一例であり、代替のワークフローが実行され得ることが理解される。さらに、分散型ローンプロセスのワークフロー2700は、明示的に説明されなかった追加的または代替的なステップを含んでもよい。

【0334】

図２８は、本開示のいくつかの実施形態に従うローンプロセスのワークフロー2800の一例を示す図である。図２８の例では、ローンプロセスのワークフロー2800は、自動車、美術品、繊細な物体（例えば、花瓶又はシャンデリア）、ワイン又はウイスキーのコレクション等、容易に出荷されない及び／又は非常に大きい担保アイテムに対して実行されてもよい。図２８のワークフロー2800において、担保アイテムは、保管者に預けられ、保管者は、順に、担保トークンにトークン化されるVIRLを生成することができる。その後、担保アイテムのVIRLは、当事者間で物理的な担保アイテムを輸送することなく、認証者及び鑑定者に提供され得る。図２８の例では、ローンプロセスのワークフロー2800は、借り手がローンプロセスを開始することを要求する要求ステージ2802と、担保アイテムの所有が保管者によって取られる保管ステージ2804と、担保アイテムのVIRLが担保トークン化されるために必要な文書を保管者が提供し得るトークン化ステージ2806と、１または複数の認証者が１つまたは複数のアイテムを認証する認証ステージ2808と、次いで、認証されたアイテムが鑑定される鑑定ステージ2810と、借り手と貸し手によってローンが交渉され受け入れられる貸し付けステージ2812と、借り手によってローンが返済される返済ステージ2814と、次いで、担保トークンがロック解除されて借り手に返却されるか、借り手がローンをデフォルトした場合に清算されて、ローンプロセスの参加者に任意の報酬が発行されるローン後ステージ2816と、を含み得る。

【0335】

要求ステージ2802の間、借り手は、借り手が所有するアイテムを担保することを含む新しいローンプロセスを開始することを要求することができる。実施形態では、借り手は、トークン化プラットフォーム100とインターフェースをとる借り手デバイス2002を介して、ローンを要求してもよい。これらの実施形態では、トークン化プラットフォーム100（または別の適切なシステム）は、借り手が、担保に入れるべき担保アイテム、担保アイテムの場所、求めるローン額、および／または提案されたローン期間などの情報を提供し得るGUIを提供してもよい。借り手の要求に応答して、トークン化プラットフォーム100は、ローンプロセスのスマートコントラクトインスタンスをインスタンス化してもよい。実施形態において、ローンプロセスのスマートコントラクトインスタンスは、（例えば、借り手によって提供された要求から）担保アイテムのタイプを決定してもよく、ローンプロセス中に担保アイテムをエスクローで保管するように保管者に要求してもよく、それによってローンプロセスを保管ステージ2804に進行させる。

【0336】

保管ステージ2804の間、ローンプロセスのスマートコントラクトインスタンスは、担保アイテムを保管するために保管者を要求してもよく、保管ワークフローを実行する、保管スマートコントラクト2032のインスタンスをインスタンス化してもよい。実施形態において、トークン化プラットフォーム100は、例えば、担保アイテムのタイプ及び／又は担保アイテムに対する保管者の近接性に基づいて、保管者を保管タスクに割り当ててもよい。保管者がアイテムの受領を確認すると、保管者は、アイテムが保管されていることを示す保管リポートを生成し、受領され検査された時点における担保アイテムのあらゆる損傷、及び保管リポートを支持するあらゆる支持文書に留意してもよい。実施形態において、保管リポート及び任意のサポート文書は、分散台帳2016に書き込まれてもよい。いくつかの実施形態では、保管者は、保管中にアイテムが紛失または破損した場合のセーフガードとして、担保アイテムのおおよその価値に等しいまたは比例する額の通貨／トークン化トークンを出資するよう求められてもよい（または保険の証拠を提供してもよい）。実施形態において、保管スマートコントラクトインスタンスは、その後、アイテムがエスクローに安全に保管されたことを示す通知をローン処理スマートコントラクトインスタンスに提供してもよく、通知は、保管リポートのハッシュ値および任意の他の支持証拠および／または保管リポートおよび支持証拠へのブロックアドレスが含まれ得る。通知に応答して、ローンプロセスのスマートコントラクトは、ローンプロセスをトークン化ステージ2806に進めてもよい。

【0337】

トークン化ステージ2806の間、トークン化プラットフォーム100（または別の適切なコンポーネント）は、担保アイテムをトークン化することを生成してもよい。実施形態において、トークン化プラットフォーム100は、担保アイテムの説明、画像、ビデオ、2Dスキャン、および／または3Dスキャンなど、担保アイテムを説明および／または描写するデータに基づいて、担保アイテムのVIRLを生成してもよい。実施形態において、借り手または保管人は、VIRLを生成するために使用されるデータを提供してもよい。実施形態において、トークン化プラットフォーム100は、担保アイテムのVIRLに基づいて、アイテムの担保トークンを生成する。アイテムがトークン化されると、トークン化プラットフォーム100は、トークンを分散台帳2016に書き込んでよく、担保トークンの所有権を借り手に（ローン契約が成立するまで）最初に割り当ててもよい。担保アイテムがトークン化されると、トークン化プラットフォーム100は、トークン化イベント及び／又は担保トークンのアドレスを示す通知をローンプロセスのスマートコントラクト2022に提供してもよい。トークン化イベントの通知を受信すると、ローンプロセスのスマートコントラクト2022は、ローンプロセスを認証ステージ2808に進めてもよい。

【0338】

認証ステージ2808の間、ローンプロセスのスマートコントラクトインスタンスは、認証スマートコントラクト2028のインスタンスをインスタンス化してもよい。実施形態において、トークン化プラットフォーム100は、上述のように、担保アイテムのようなアイテムの認証を専門に行う認証ギルドからの一次認証者（および潜在的に二次認証者）に認証タスクを割り当ててもよい。実施形態において、一次認証者は、認証されるアイテムのVIRLを送信されてもよく、認証者は、担保アイテムの真正性に対する決定を示す認証リポート、ならびに任意のサポート文書を生成してもよい。実施形態において、認証リポート及びサポート証拠は、１以上の二次認証者に提供されてもよく、二次認証者は、順に、認証リポートを検証し、追加のサポート文書を提供してもよい。実施形態において、認証リポートおよび任意のサポート文書は、分散台帳2016に書き込まれてもよい。いくつかの実施形態では、認証タスクに参加した認証者は、アイテムが清算され、後に偽物とみなされた場合のセーフガードとして、通貨／トークンの額を出資するよう要求されてもよい。例示的な実施形態では、ローンプロセスのスマートコントラクト2022は、アイテムが１または複数の認証者によって本物であったか、または偽物とみなされたかを示すインスタンス化された認証スマートコントラクト2028によって発行された認証通知を待機（リスン）する待機スレッドを含んでよく、認証スマートコントラクト2028からの認証通知は、認証者の見解（例えば、偽物または本物）、認証リポートおよび他の任意の支持証拠のハッシュ値、および／または認証リポートおよび支持文書へのブロックアドレスを含んでよく、このとき、この認証通知は、認証者の見解（例：偽物、本物）、認証リポートのハッシュ値、および他の任意の支持証拠のハッシュ値を含んでよい。ローンプロセスのスマートコントラクトインスタンスが、アイテムが真正とみなされたと判断した場合、ローンプロセスのスマートコントラクトインスタンスは、ローンプロセスを鑑定ステージ2810に進めてもよい。

【0339】

鑑定ステージ2810の間、ローンプロセスのスマートコントラクトインスタンスは、認証されたアイテムを鑑定するために１人または複数の鑑定者を要求してもよく、鑑定スマートコントラクト2030のインスタンスをインスタンス化してもよい。実施形態において、トークン化プラットフォーム100は、上述したように、担保アイテムのタイプに基づいて、タスクを実行する１人または複数の鑑定者を識別してもよい。実施形態において、一次鑑定者は、担保アイテムのVIRLを送信されてもよい。アイテムが真正とみなされたことを知っている鑑定者は、担保アイテムの鑑定価格を決定してもよく、鑑定価格及び鑑定価格を支持する任意の支持文書を示す鑑定リポートを生成してもよい。いくつかの実施形態では、１人以上の二次鑑定者は、鑑定リポートを検証してもよく、それぞれの検証のためのサポート文書を提供してもよい。実施形態において、鑑定リポート及び任意のサポート文書は、分散台帳2016に書き込まれてもよい。いくつかの実施形態では、鑑定タスクに参加した鑑定者は、アイテムが返済額および／または鑑定額の残額を大幅に下回る価格で清算された場合のセーフガードとして、担保アイテムの鑑定額に等しいまたは比例する額の通貨／トークンをステークするよう要求されてもよい。実施形態において、鑑定スマートコントラクト2030は、鑑定ワークフローが正常に完了したことを示す通知をローン処理スマートコントラクト2022に送信してもよく、通知は、鑑定価値、鑑定書及び他のサポート証拠のハッシュ値、及び／又は鑑定書及びサポート証拠へのブロックアドレスを含んでもよい。鑑定ステージが完了したと決定すると、ローンプロセスのスマートコントラクト2022は、ローンプロセスを貸し付けステージ2812に進めてもよい。

【0340】

貸し付けステージ2812の間、借り手は、ローンを要求してもよく、及び／又は、1つ以上の貸し手とローンを交渉してもよい。貸し手及び借り手がローン条件に合意したという確認を受けると、ローンプロセスのスマートコントラクト2022は、合意されたローン条件に従ってローンスマートコントラクト2034をインスタンス化してもよい。いくつかの実施形態では、トークン化プラットフォーム100は、借り手が1つまたは複数の潜在的な貸し手にローンを要求すること、および／または1つまたは複数の貸し手とローン契約を交渉することを可能にするGUIを借り手に提供し得る。いくつかの実施形態では、ローン交渉は、トークン化プラットフォーム100などの集中型サービスを経由するのではなく、オンチェーンで処理されてもよいことが理解される。実施形態において、借り手は、評価額を超えないローン額と、ローンを返済するための時間額を示す提案されたローン期間とを要求してもよい。これらの実施形態のいくつかでは、トークン化プラットフォーム100は、GUIを介して潜在的な貸し手に提示されるローンリクエストを生成してもよく、それによって、ローンリクエストは、求める金額、ローンの長さ、および借り手によって提供される担保アイテムに関連する情報（例えば、担保アイテムのVIRL、認証リポート、鑑定リポート、保管リポート、認証、鑑定、および（上述したように）保管者がそれぞれのタスクを確保したことの確認、および／または同様のものを示す。実施形態において、トークン化システム100は、ローンの返済額および／または金利（例えば、現在の市場条件に基づいて）を提案してもよい。代替的に、潜在的な貸し手は、GUIを介して、借り手が返済しなければならないであろう金利または総返済額を提供してもよい。さらに、潜在的な貸し手は、ローン額及び／又は返済期間など、要求されたローン条件のうちの1つ又は複数に対抗してもよい。その後、ローンオファーは、GUIを介して借り手に伝達されてもよく、借り手は、借り手デバイス2002を介してローンオファーを見ることができる。これに対して、借り手は、ローンオファーを受け入れるか、ローンオファーを拒否するか、またはカウンターオファーを提供することができる。当事者は、合意に達するか、一方または両方の当事者がローンの申し出を拒否するまで、このような方法を繰り返すことができる。ローンが合意されると、当事者は、ローン合意を実行してもよく、トークン化プラットフォーム100は、ローン合意が借り手と貸し手とによって合意されたことを示す通知をローンプロセススマートコントラクトインスタンスに提供してもよい。実施形態において、通知は、ローン契約の条件を含むローン契約の詳細を含んでもよい。これに応答して、ローンプロセスのスマートコントラクトインスタンスは、ローン返済ワークフローを実行するローンスマートコントラクトインスタンスをインスタンス化してもよい。ローン契約が実行されると、ローンスマートコントラクトは、担保トークンをエスクローアカウントにロックしてもよく、貸し手のアカウントから借り手のアカウントへの資金の譲渡を促進してもよい。実施形態において、ローン契約、任意のオファー／カウンターオファーの記録、及び担保トークンのエスクロー及び借り手への譲渡資金に関連する記録は、分散台帳2016に書き込まれてもよい。ローンプロセスのスマートコントラクトインスタンスが、担保トークンがロックされ、資金が送金されたという通知を受信すると、ローンプロセスのスマートコントラクトインスタンスは、ローンプロセスを返済ステージ2814に進めてもよい。

【0341】

返済ステージ2814の間、ローンスマートコントラクトインスタンスは、借り手によって貸し手（または貸し手に支払いを分配するアカウント）に支払いがローンスケジュールに従って行われ、ローンがデフォルト状態でないことを保証するために、借り手の支払い履歴を監視してもよい。ローン返済のステージでは、借り手は支払いを送金することができます。支払いが行われるたびに、ローン処理スマートコントラクトインスタンスは、支払いが行われたこと及び支払いの金額を示す支払い通知を受信してもよい。その後、ローンスマートコントラクトインスタンスは、ローンが全額返済されたか否かを判断してもよい。ローンが全額返済されていない場合、ローンスマートコントラクトインスタンスは、ローン返済額を調整してもよく、新しいローン返済額を反映するために認証者、鑑定者、及び／又は保管者から賭けられた資金の一部を戻すなどの追加のオペレーションを実行してもよい。ローン返済額が全額支払われたとローンスマートコントラクトインスタンスが判断した場合、ローンスマートコントラクトインスタンスは、ローンが全額支払われたことを示す返済通知をローンプロセススマートコントラクトインスタンスに送信してもよく、ローンプロセスをローン後ステージ2816に進ませてもよい。実施形態において、返済通知は、支払いが行われたことを示す支払いイベントレコードのハッシュ値、及び支払いの金額、及び／又は分散台帳2016上の支払いレコードのアドレスを含んでもよい。逆に、ローンスマートコントラクトインスタンスが借り手がデフォルトになったと判断した場合、ローンスマートコントラクトインスタンスは、清算イベントをトリガーしてもよく、及び／又はローンがローンの条件に従ってデフォルトであることを示すデフォルト通知をローンプロセスのスマートコントラクトへ送信してもよい。実施形態において、デフォルト通知は、どの支払いが滞り、ローンの残額を示すデフォルトイベントレコードのハッシュ値および／または分散台帳2016上のデフォルトイベントレコードのアドレスを含んでもよい。デフォルト通知を受信することに応答して、ローンスマートコントラクトインスタンスは、清算イベントを開始してもよく、ローンプロセスをローン後ステージ2816に進めてもよい。

【0342】

ローン後ステージ2816の間、担保トークンは、ローンが完全に支払われた場合に所有者に返されるか、または清算イベントが実施されるかのいずれかである。ローンが全額返済されたという返済通知の受信に応答して、ローンスマートコントラクトインスタンスは、エスクローアカウントから借り手のアカウントへの担保トークンの譲渡を開始してもよく、借り手は次に担保トークンを償還して担保アイテムの所有権を取得することができる。ローンが正常に返済されると、ローンプロセスのスマートコントラクトインスタンスは、認証スマートコントラクト、鑑定スマートコントラクト、及び保管契約に定められた条件に従って、認証者、鑑定者、及び保管者のアカウントに（例えば、貸し手に返済された資金から）報酬を授与することを開始し得る。

【0343】

清算イベントを開始する際に、ローンスマートコントラクトインスタンスは、担保トークンのアドレスを適切な市場（例えば、市場システム102）に送信してもよく、市場は担保アイテムを清算してもよい（例えば、オークションにおいて）。清算イベントの間、買い手は、担保トークンを購入してもよく、その結果、担保トークンの所有権データ2054が買い手に割り当てられ、買い手は、担保トークンを換金して担保アイテムの所有権を取得してもよい。清算されると、ローンプロセスのスマートコントラクトインスタンスは、清算イベントの収益から、未払い残高の残りを貸し手（又は、ローンが二次貸し手に売却された場合には二次貸し手）に分配してよい。清算イベントの後、ローンプロセスのスマートコントラクトインスタンスは、認証スマートコントラクト、鑑定スマートコントラクト、及び保管契約に定められた条件に従って、清算イベントの収益から認証者、鑑定者、及び保管者のアカウントに報酬を授与することを開始してもよい。残額がある限り、残額は借主のアカウントに入金することができる。

【0344】

ローンプロセスが完了すると、ローンプロセスのスマートコントラクトインスタンスは、ローンプロセスが完了したことをトークン化プラットフォーム100に通知してもよく、トークン化プラットフォーム100は、完了したローンプロセスに基づいて分析プロセスを実行してもよい。いくつかの実施形態では、ローンプロセスの結果は、認証者、鑑定者、保管者、貸し手、および／または借り手のうちの1つまたは複数の評価を更新するために使用されてもよい。

【0345】

上述した説明は、分散型ローンプロセスのワークフロー2800の一例であり、代替的なワークフローが実行されてもよいことが理解される。さらに、分散型ローンプロセスのワークフロー2800は、明示的に説明されなかった追加的または代替的なステップを含んでもよい。

【0346】

図２９は、本開示のいくつかの実施形態に従うローンプロセスのワークフロー2900の一例を示す図である。図２９の例では、ローンプロセスのワークフロー2900は、借り手が担保アイテムを過大評価している可能性が高い場合に実行され得る。例えば、借り手は、１万ドルに等しいローン額を確保することを希望し、１足のデザイナーズスニーカーでローンを確保することを希望している可能性がある。この状況では、図２９のローンプロセスのワークフロー2900が実行され、鑑定ステージが認証ステージ及び保管ステージの前に実行されてもよい。このようにして、鑑定された値が所望のローン額よりはるかに少ない場合、借り手は、認証手数料及び／又は保管手数料を支払うことなく、ローンプロセスを見送ることを選択することができる。図２９の例では、ローンプロセスのワークフロー2900は、以下を含むことができる。それれは、借り手がローンプロセスの開始を要求する要求ステージ2902、1人以上の鑑定者が１つ以上のアイテムを鑑定する鑑定ステージ2904、次いで、鑑定されたアイテムが認証される認証ステージ2906、認証された物品が信頼できる金庫に預けられる保管ステージ2908、次いで、台帳管理システム104（または別の適切なコンポーネント）が１つ以上の預けられたアイテムのVIRLを生成し、預けられた物品のVIRLをトークン化することによって担保トークンを生成するトークン化ステージ2910、次いで、借り手と貸し手とによってローンが交渉され、受け入れられる貸し付けステージ2912、借り手によってローンが返済される返済ステージ2914、担保トークンがロック解除されて借り手に返却されるか、借り手がローンをデフォルトした場合に清算されて、ローンプロセスの参加者に任意の報酬が発行される貸し付け後ステージ2916、である。

【0347】

要求ステージ2902の間、借り手は、借り手が所有するアイテムを担保に入れることを含む新しいローンプロセスを開始することを要求することができる。実施形態において、借り手は、トークン化プラットフォーム100とインターフェースする借り手デバイス2002を介してローンを要求してもよい。これらの実施形態では、トークン化プラットフォーム100（または別の適切なシステム）は、借り手が、担保に入れるべき担保アイテム、担保アイテムの場所、求めるローン額、および／または提案されたローン期間などの情報を提供し得るGUIを提供してもよい。借り手の要求に応答して、トークン化プラットフォーム100は、ローンプロセスのスマートコントラクトインスタンスをインスタンス化してもよい。実施形態において、ローンプロセスのスマートコントラクトインスタンスは、（例えば、借り手によって提供された要求から）担保アイテムのタイプを決定してもよく、担保アイテムを鑑定するために鑑定者（及び潜在的に二次鑑定者）を要求してもよく、それによって、ローンプロセスを鑑定ステージ2904に進行させる。

【0348】

鑑定ステージ2904の間、ローンプロセスのスマートコントラクトインスタンスは、鑑定スマートコントラクト2030のインスタンスをインスタンス化してもよく、1人または複数の鑑定者に、認証されたものを鑑定するように要求してもよい。実施形態において、トークン化プラットフォーム100は、上で説明されたように、担保アイテムのタイプ、アイテムの場所、および／またはそのようなものに基づいて、タスクを実行する１人または複数の鑑定者を識別してもよい。実施形態において、一次鑑定者は、担保アイテムを（例えば、郵便または他の発送を介して）受け取ってもよく、担保アイテムの鑑定価値を決定してもよい。このワークフロー2900では、鑑定者は、アイテムが認証者によって真正とみなされたことを知る利益を有しない。それにもかかわらず、鑑定者は、アイテムが認証者によって真正とみなされることを仮定してもよい。実施形態において、一次鑑定者は、決定された鑑定価値及びその鑑定価値を裏付ける任意のサポート文書を示す鑑定リポートを作成してもよい。いくつかの実施形態では、１人以上の二次鑑定者は、鑑定リポートを検証してもよく、それぞれの検証のためのサポート文書を提供してもよい。実施形態において、鑑定リポート及び任意のサポート文書は、分散台帳2016に書き込まれてもよい。いくつかの実施形態では、鑑定タスクに参加した鑑定者は、アイテムが返済額および／または鑑定額の残額を大幅に下回る価格で清算された場合のセーフガードとして、担保アイテムの鑑定額に等しいまたは比例する額の通貨／トークンを出資するよう要求されてもよい。実施形態において、鑑定スマートコントラクト2030は、鑑定ワークフローが正常に完了したことを示す通知をローンプロセス スマートコントラクト2022に送信してもよく、通知は、鑑定価値、鑑定書および他のサポート証拠のハッシュ値、および／または鑑定書およびサポート証拠へのブロックアドレスを含んでもよい。いくつかのシナリオでは、鑑定価格が要求されたローン額よりかなり低く、その場合、借り手はローンプロセスを終了することを選択することができる。借り手が、鑑定された価値を与えられてローンプロセスを継続することを決定したと仮定すると、ローンプロセスのスマートコントラクト2022は、ローンプロセスを鑑定ステージ2906に進めてもよい。

【0349】

認証ステージ2906の間、ローンプロセスのスマートコントラクトインスタンスは、認証スマートコントラクト2028のインスタンスをインスタンス化してもよい。実施形態において、トークン化プラットフォーム100は、上述のように、担保アイテムのようなアイテムの認証を専門に行う認証ギルドからの一次認証者（及び潜在的に二次認証者）に認証タスクを割り当ててもよい。実施形態において、担保アイテムは、一次認証者に物理的に送られるか（例えば、鑑定者から）、または担保アイテムのVIRLが認証者にデジタルで送られるかのいずれかである。実施形態において、一次認証者は、認証されるべき担保アイテム（またはそのVIRL）の受領を、認証者デバイス2004を介して確認することができる。実施形態において、認証者は、担保アイテムの真正性についての決定を示す認証リポート、及び、任意の補助文書を生成してもよい。実施形態において、認証リポート及びサポート証拠は、1つ以上の二次認証者に提供されてもよく、二次認証者は、順に、認証リポートを検証してもよく、追加のサポート文書を提供してもよい。実施形態において、認証リポートおよび任意のサポート文書は、分散台帳2016に書き込まれてもよい。いくつかの実施形態では、認証タスクに参加した認証者は、アイテムが清算され、後に偽物とみなされた場合の保証手段として、一定額の通貨／トークン出資するよう要求されてもよい。例示的な実施形態では、ローンプロセスのスマートコントラクト2022は、アイテムが１または複数の認証者によって本物であったか、または偽物とみなされたかを示すインスタンス化された認証スマートコントラクト2028によって発行された認証通知をリスンするリスニングスレッドを含み得、認証スマートコントラクト2028からの通知は、認証者の見解（例えば、偽物または本物）、認証リポートおよび他の任意の支持証拠のハッシュ値、および／または認証リポートおよび支持証拠へのブロックアドレスが含まれてもよい。ローンプロセスのスマートコントラクトインスタンスが、アイテムが真正とみなされたと判断した場合、ローンプロセスのスマートコントラクトインスタンスは、ローンプロセスを保管ステージ2908に進めてもよい。

【0350】

保管ステージ2908の間、ローンプロセスのスマートコントラクトインスタンスは、担保アイテムを保管するために保管者を要求してもよく、保管ワークフローを実行する、保管スマートコントラクト2032のインスタンスをインスタンス化してもよい。実施形態において、トークン化プラットフォーム100は、例えば、担保アイテムのタイプ及び／又は担保アイテムに対する保管者の近接性に基づいて、保管者を保管タスクに割り当ててもよい。保管者がアイテムの受領を確認すると、保管者は、アイテムが保管されていることを示す保管リポートを生成し、受領され検査された時点における担保アイテムのあらゆる損傷、及び保管リポートを支持するあらゆる支持文書に留意してもよい。実施形態において、保管リポート及び任意のサポート文書は、分散台帳2016に書き込まれてもよい。いくつかの実施形態では、保管者は、担保アイテムが保管中に紛失または破損した場合の安全デバイスとして、担保アイテムの評価額と等しいまたは比例する額の通貨／トークン化トークンを出資することを要求されてよい（または保険の証明を提供してもよい）。実施形態において、保管スマートコントラクトインスタンスは、その後、アイテムがエスクローに安全に保管されたことを示す通知をローン処理スマートコントラクトインスタンスに提供してもよく、通知は、保管リポートのハッシュ値および任意の他の支持証拠および／または保管リポートおよび支持証拠へのブロックアドレスが含まれてもよい。通知に応答して、ローンプロセスのスマートコントラクトは、ローンプロセスをトークン化ステージ2910に進めてもよい。

【0351】

トークン化ステージ2910の間、トークン化プラットフォーム100（または別の適切な構成要素）は、担保アイテムをトークン化することを生成してもよい。実施形態において、トークン化プラットフォーム100は、担保アイテムの説明、画像、ビデオ、2Dスキャン、および／または3Dスキャンなど、担保アイテムを説明および／または描写するデータに基づいて、担保アイテムのVIRLを生成してもよい。実施形態において、借り手、保管者、および／または認証者は、VIRLを生成するために使用されるデータを提供することができる。実施形態において、トークン化プラットフォーム100は、担保アイテムのVIRLに基づいて、アイテムの担保トークンを生成する。アイテムがトークン化されると、トークン化プラットフォーム100は、分散台帳2016にトークンを書き込んでよく、（ローン契約が成立するまで）担保トークンの所有権を借り手に最初に割り当ててもよい。担保アイテムがトークン化されると、トークン化プラットフォーム100は、トークン化イベント及び／又は担保トークンのアドレスを示す通知をローンプロセスのスマートコントラクト2022に提供してもよい。トークン化イベントの通知を受信すると、ローンプロセスのスマートコントラクト2022は、ローンプロセスを貸し付けステージ2912に進めてもよい。

【0352】

貸し付けステージ2912の間、借り手は、ローンを要求してもよく、及び／又は、1つ以上の貸し手とローンを交渉してもよい。貸し手及び借り手がローン条件に合意したという確認を受けると、ローンプロセスのスマートコントラクト2022は、合意されたローン条件に従ってローンスマートコントラクト2034をインスタンス化してもよい。いくつかの実施形態では、トークン化プラットフォーム100は、借り手が1つまたは複数の潜在的な貸し手にローンを要求すること、および／または1つまたは複数の貸し手とローン契約を交渉することを可能にするGUIを借り手に提供し得る。いくつかの実施形態では、ローン交渉は、トークン化プラットフォーム100などの集中型サービスを経由するのではなく、オンチェーンで処理されてもよいことが理解される。実施形態において、借り手は、評価額を超えないローン額と、ローンを返済するための時間額を示す提案されたローン期間とを要求してもよい。これらの実施形態のいくつかでは、トークン化プラットフォーム100は、GUIを介して潜在的な貸し手に提示されるローン要求を生成してもよく、それによって、ローン要求は、求める金額、ローンの期間、および借り手が提供した担保アイテムに関する情報（例えば、担保アイテムのVIRL、認証リポート、鑑定リポート、保管リポート、認証、鑑定および保管者がそれぞれのタスクを確保したこと（上述）、および／または同様のもの）を示している。実施形態において、トークン化システム100は、ローンの返済額および／または金利（例えば、現在の市場条件に基づいて）を提案してもよい。代替的に、潜在的な貸し手は、GUIを介して、借り手が返済しなければならないであろう金利または総返済額を提供してもよい。さらに、潜在的な貸し手は、ローン額及び／又は返済期間など、要求されたローン条件のうちの1つ又は複数に対抗してもよい。その後、ローンオファーは、GUIを介して借り手に伝達されてもよく、借り手は、借り手デバイス2002を介してローンオファーを見ることができる。これに対して、借り手は、ローンオファーを受け入れるか、ローンオファーを拒否するか、またはカウンターオファーを提供することができる。当事者は、合意に達するか、一方または両方の当事者がローンの申し出を拒否するまで、このような方法を繰り返すことができる。ローンが合意されると、当事者は、ローン合意を実行してもよく、トークン化プラットフォーム100は、ローン合意が借り手と貸し手とによって合意されたことを示す通知をローンプロセススマートコントラクトインスタンスに提供してもよい。実施形態において、通知は、ローン契約の条件を含むローン契約の詳細を含んでもよい。これに応答して、ローンプロセスのスマートコントラクトインスタンスは、ローン返済ワークフローを実行するローンスマートコントラクトインスタンスをインスタンス化してもよい。ローン契約が実行されると、ローンスマートコントラクトは、担保トークンをエスクローアカウントにロックしてもよく、貸し手のアカウントから借り手のアカウントへの資金の譲渡を促進してもよい。実施形態において、ローン契約、任意のオファー／カウンターオファーの記録、及び担保トークンのエスクロー及び借り手への譲渡資金に関連する記録は、分散台帳2016に書き込まれてもよい。ローンプロセスのスマートコントラクトインスタンスが、担保トークンがロックされ、資金が送金されたという通知を受信すると、ローンプロセスのスマートコントラクトインスタンスは、ローンプロセスを返済ステージ2914に進めてもよい。

【0353】

返済ステージ2914の間、ローンスマートコントラクトインスタンスは、借り手によって貸し手（又は貸し手に支払いを分配するアカウント）に支払いがローンスケジュールに従って行われ、ローンがデフォルト状態でないことを保証するために、借り手の支払い履歴を監視してもよい。ローン返済のステージでは、借り手は支払いを送金することができます。支払いが行われるたびに、ローンプロセスのスマートコントラクトインスタンスは、支払いが行われたこと及び支払いの金額を示す支払い通知を受信してもよい。次に、ローンスマートコントラクトインスタンスは、ローンが全額返済されたか否かを判断してもよい。ローンが全額返済されていない場合、ローンスマートコントラクトインスタンスは、ローン返済額を調整してもよく、新しいローン返済額を反映するために認証者、鑑定者、及び／又は保管者から賭けられた資金の一部を戻すなどの追加のオペレーションを実行してもよい。ローン返済額が全額支払われたとローンスマートコントラクトインスタンスが判断した場合、ローンスマートコントラクトインスタンスは、ローンが全額支払われたことを示す返済通知をローンプロセススマートコントラクトインスタンスに送信してもよく、ローンプロセスをローン後ステージ2916に進ませてもよい。実施形態において、返済通知は、支払いが行われたことを示す支払いイベントレコードのハッシュ値、及び支払いの金額、及び／又は分散台帳2016上の支払いレコードのアドレスを含んでもよい。逆に、ローンスマートコントラクトインスタンスが借り手がデフォルトしたと判断した場合、ローンスマートコントラクトインスタンスは、清算イベントをトリガーしてもよく、及び／又はローンがローンの条件に従ってデフォルトであることを示すデフォルト通知をローンプロセスのスマートコントラクトへ送信してもよい。実施形態において、デフォルト通知は、どの支払いが滞り、ローンの残額を示すデフォルトイベントレコードのハッシュ値及び／又は分散台帳2016上のデフォルトイベントレコードのアドレスを含んでもよい。デフォルト通知を受信することに応答して、ローンスマートコントラクトインスタンスは、清算イベントを開始してもよく、ローンプロセスをローン後ステージ2916に進めてもよい。

【0354】

ローン後ステージ2916の間、担保トークンは、ローンが完全に支払われた場合に所有者に返却されるか、または清算イベントが実施されるかのいずれかである。ローンが全額返済されたという返済通知の受信に応答して、ローンスマートコントラクトインスタンスは、エスクローアカウントから借り手のアカウントへの担保トークンの譲渡を開始してもよく、借り手は次に担保トークンを償還して担保アイテムの所有権を得ることができる。ローンが正常に返済されると、ローンプロセスのスマートコントラクトインスタンスは、認証スマートコントラクト、鑑定スマートコントラクト、及び保管契約に定められた条件に従って、認証者、鑑定者、及び保管者のアカウントに（例えば、貸し手に返済された資金から）報酬を授与することを開始し得る。

【0355】

清算イベントを開始する際に、ローンスマートコントラクトインスタンスは、担保トークンのアドレスを適切な市場（例えば、市場システム102）に送信してもよく、市場は、（例えば、オークションにおいて）担保アイテムを清算することができる。清算イベントの間、買い手は、担保トークンを購入してもよく、その結果、担保トークンの所有権データ2054が買い手に割り当てられ、買い手は、担保トークンを換金して担保アイテムの所有権を取得してもよい。清算されると、ローンプロセスのスマートコントラクトインスタンスは、清算イベントの収益から、未払い残高の残りを貸し手（又は、ローンが二次貸し手に売却された場合には二次貸し手）に分配してよい。清算イベントの後、ローンプロセスのスマートコントラクトインスタンスは、認証スマートコントラクト、鑑定スマートコントラクト、及び保管契約に定められた条件に従って、清算イベントの収益から認証者、鑑定者、及び保管者のアカウントに報酬を授与することを開始してもよい。残額がある限り、残額は借主のアカウントに入金することができる。

【0356】

ローンプロセスが完了すると、ローンプロセスのスマートコントラクトインスタンスは、ローンプロセスが完了したことをトークン化プラットフォーム100に通知してもよく、トークン化プラットフォーム100は、完了したローンプロセスに基づいて分析プロセスを実行してもよい。いくつかの実施形態では、ローンプロセスの結果は、認証者、鑑定者、保管者、貸し手、および／または借り手のうちの1つまたは複数の評価を更新するために使用されてもよい。

【0357】

上記の説明は、分散型ローンプロセスのワークフロー2900の一例であり、代替的なワークフローが実行されてもよいことが理解される。さらに、分散型ローンプロセスのワークフロー2900は、明示的に議論されなかった追加的または代替的なステップを含んでもよい。

【0358】

図３０は、本開示のいくつかの実施形態によるローンプロセスのワークフロー3000の一例を示す図である。例示的なローンプロセスのワークフロー3000では、ローン条件が合意される前に、ローン前清算イベントが実施される。例示的なローン前清算ステージの間、市場（例えば、トークン化プラットフォーム100の市場システム102によってホストされるか、又はそれと通信する市場）は、一連の偶発事象を伴う担保アイテムを含むローンの交渉及び／又は実行に先立って、担保アイテムを設定価格で条件付き買い手に売却してもよく、又は担保アイテムを条件付き買い手に対して競売にかけてもよい。実施形態において、条件付き事象のセットは、条件付き所有及び条件付き報酬事象を含んでもよい。実施形態において、条件付き所有は、担保アイテムによって担保される借り手によって締結されたローン契約に関して確認されたデフォルトイベントに関して、担保アイテムに対する条件付き買い手の所有権を条件とする。別の言い方をすれば、条件付き買い手は、借り手が担保アイテムを担保にしたローンを確保することができ、借り手が後にそのローンを不履行にした場合にのみ、担保アイテムを所有することができる（例えば、対応する担保アイテムを償還することによって）。実施形態において、条件付き報酬は、借り手がローンを正常に返済した場合に、報酬（例えば、通貨／トークンまたは不換通貨の額）を条件付き買い手に授与すること（例えば、報酬をその電子アカウントに預けること）を条件とし得る。このように、条件付き買い手は、ローンが正常に返済された場合に報酬を得ることができるので、条件付き買い手は、条件付きで担保アイテムを購入するインセンティブを与えられる。別の言い方をすれば、条件付き買い手は、担保アイテムの現在の所有者（すなわち、借り手）によってローンが締結される前に担保アイテムの清算価格を設定することに同意することと償還に、金銭的報酬を提供され得る。いくつかの実施形態において、借り手は、担保アイテムを条件付き買い手に売却することに同意し、ローン前清算ステージの後にローンを求める機会を見送ることができることに留意されたい。ローン前清算ステージは、鑑定ステージの代わりに行われてもよく、または（例えば、当事者の一方または両方が担保アイテムの鑑定価値に同意しない場合、借り手および／または貸し手によって）鑑定ステージの後に要求されてもよい。

【0359】

図３０の例は、以下の通りである。30では、ローンプロセスのワークフロー3000は、以下を含むことができる。それらは、借り手がローンプロセスの開始を要求する要求ステージ3002と、１つ以上の認証者が担保アイテムを認証する認証ステージ3004と、認証された物品が信頼できる金庫に保管される保管ステージ3006と、担保アイテムに対応するVIRLが生成されて担保トークンにトークン化されるトークン化ステージ3010と、次いで、ローン条件が交渉される前に担保アイテムの清算価値を設定するために、認証されたアイテムが市場を通じて条件付きで販売されるローン前清算ステージ3006と、次いで、借り手と貸し手によってローンが交渉され受け入れられるローンステージ3012と、次いで、ローンが借り手によって返済される返済ステージ3014と、次いで、ローン後ステージ3016が続き、担保トークンがロック解除されて借り手に返却されるか、借り手がローンを不履行にした場合は清算され、ローンプロセスの参加者に任意の報酬が発行される。

【0360】

要求ステージ3002の間、借り手は、借り手が所有するアイテムを担保に入れることを含む新しいローンプロセスを開始するよう要求することができる。実施形態において、借り手は、トークン化プラットフォーム100とインターフェースする借り手デバイス2002を介してローンを要求してもよい。これらの実施形態では、トークン化プラットフォーム100（または別の適切なシステム）は、借り手が、担保に入れるべき担保アイテム、担保アイテムの場所、求めるローン額、および／または提案されたローン期間などの情報を提供し得るGUIを提供してもよい。借り手の要求に応答して、トークン化プラットフォーム100は、ローンプロセスのスマートコントラクトインスタンスをインスタンス化してもよい。実施形態において、ローンプロセスのスマートコントラクトインスタンスは、（例えば、借り手によって提供された要求から）担保アイテムのタイプを決定してもよく、担保アイテムを認証するために認証者（及び潜在的に二次認証者）を要求してもよく、それによって、ローンプロセスを認証ステージ3004に進行させる。

【0361】

認証ステージ3004の間、ローンプロセスのスマートコントラクトインスタンスは、認証スマートコントラクト2028のインスタンスをインスタンス化してもよい。実施形態において、トークン化プラットフォーム100は、上述のように、担保アイテムのようなアイテムの認証を専門とする認証ギルドからの一次認証者（及び潜在的に二次認証者）に認証タスクを割り当ててもよい。実施形態において、一次認証者は、認証者デバイス2004を介して、認証されるアイテムの受領を確認してもよい。実施形態において、認証者は、担保アイテムの真正性に対する判定を示す認証リポート、及び任意のサポート文書を生成してもよい。実施形態において、認証リポート及びサポート証拠は、1つ以上の二次認証者に提供されてもよく、二次認証者は、順に、認証リポートを検証してもよく、追加のサポート文書を提供してもよい。実施形態において、認証リポートおよび任意のサポート文書は、分散台帳2016に書き込まれてもよい。いくつかの実施形態では、認証タスクに参加した認証者は、アイテムが清算され、後に偽物とみなされた場合の保証として、通貨／トークンの額を出資するよう要求されてもよい。例示的な実施形態では、ローンプロセスのスマートコントラクト2022は、アイテムが認証者（複数可）によって本物であったか、または偽物とみなされたかを示すインスタンス化された認証スマートコントラクト2028によって発行された認証通知を待機（リスニング）する待機スレッドを含み得、認証スマートコントラクト2028からの通知は、認証者の見解（例えば、偽物または本物）、認証リポートおよびその他の支持証拠のハッシュ値、および／または認証リポートおよび支持証拠へのブロックアドレスを含んでもよい。ローンプロセスのスマートコントラクトインスタンスが、アイテムが真正とみなされたと判断した場合、ローンプロセスのスマートコントラクトインスタンスは、ローンプロセスを保管ステージ3006に進めてもよい。

【0362】

保管ステージ3006の間、ローンプロセスのスマートコントラクトインスタンスは、担保アイテムを保管するために保管者を要求してもよく、保管ワークフローを実行する、保管スマートコントラクト2032のインスタンスをインスタンス化してもよい。実施形態において、トークン化プラットフォーム100は、例えば、担保アイテムのタイプ及び／又は担保アイテムに対する保管者の近接性に基づいて、保管者を保管タスクに割り当ててもよい。保管者がアイテムの受領を確認すると、保管者は、アイテムが保管されていることを示す保管リポートを生成し、受領され検査された時点における担保アイテムのあらゆる損傷、及び保管リポートを支持するあらゆる支持文書に留意してもよい。実施形態において、保管リポート及び任意のサポート文書は、分散台帳2016に書き込まれてもよい。いくつかの実施形態では、保管者は、保管中にアイテムが紛失または破損した場合のセーフガードとして、担保アイテムのおおよその価値に等しいまたは比例する額の通貨／トークン化トークンを出資するよう求められてもよい（または保険の証拠を提供してもよい）。実施形態において、保管スマートコントラクトインスタンスは、その後、アイテムがエスクローに安全に保管されたことを示す通知をローン処理スマートコントラクトインスタンスに提供してもよく、通知は、保管リポートのハッシュ値および任意の他の支持証拠および／または保管リポートおよび支持証拠へのブロックアドレスが含まれ得る。通知に応答して、ローンプロセスのスマートコントラクトは、ローンプロセスをトークン化ステージ3008に進めてもよい。

【0363】

トークン化ステージ3008の間、トークン化プラットフォーム100（または別の適切なコンポーネント）は、担保アイテムをトークン化することを生成してもよい。実施形態において、トークン化プラットフォーム100は、担保アイテムの説明、画像、ビデオ、2Dスキャン、および／または3Dスキャンなど、担保アイテムを説明および／または描写するデータに基づいて、担保アイテムのVIRLを生成してもよい。実施形態において、借り手、保管者、および／または認証者は、VIRLを生成するために使用されるデータを提供することができる。実施形態において、トークン化プラットフォーム100は、担保アイテムのVIRLに基づいて、アイテムの担保トークンを生成する。アイテムがトークン化されると、トークン化プラットフォーム100は、分散台帳2016にトークンを書き込んでよく、（ローン契約が成立するまで）担保トークンの所有権を借り手に最初に割り当ててもよい。担保アイテムがトークン化されると、トークン化プラットフォーム100は、トークン化イベント及び／又は担保トークンのアドレスを示す通知をローンプロセスのスマートコントラクト2022に提供してもよい。トークン化イベントの通知を受信すると、ローンプロセスのスマートコントラクト2022は、ローンプロセスをローン前清算ステージ3010に進めてもよい。

【0364】

ローン前清算ステージ3010の間、ローンプロセスのスマートコントラクトインスタンスは、ローン前清算スマートコントラクトのインスタンスをインスタンス化してもよい。実施形態において、ローン前清算スマートコントラクトインスタンスは、ローン前清算要求を市場（例えば、市場システム102）に提供してもよい。実施形態において、要求は、VIRL（またはVIRL IDなどのそのインジケータ）および／または担保アイテムを説明するおよび／もしくは示す他の文書を含んでもよい。実施形態において、臨時販売要求は、他の適切な情報、例えば、条件付き販売タイプ（例えば、オークションまたは設定価格販売）、担保アイテムの場所、担保アイテムの求める価格（設定価格販売の場合）、担保アイテムの最低価格（オークションの場合）、条件の期間（例えば、借り手がローンを確保し返済するのに必要な時間）、報酬の提供（例えば、予め定義された報酬額、または購入価格、希望ローン額、または返済額の割合）、および／または同様のものである。これに応答して、市場は、条件付き販売を促進することができ、その結果、担保アイテムは、条件付きのセットで販売されるか（例えば、条件付き買い手が担保アイテムをセット価格で購入するか、オークションに勝利する）、または販売されないことになり得る。実施形態において、ローン前清算スマートコントラクトは、市場から条件付き販売の結果を受信してもよい。条件付き販売が完了すると、市場は、ローン前清算イベントの結果を示す売却通知を清算スマートコントラクトインスタンスに送信することができる。実施形態において、ローン前清算イベントの結果は、アイテムが売れたかどうか、及び売れた場合、アイテムが売れた価格（販売をホストするために市場が取った手数料を差し引いたもの）を示す。この時点で、ローン前清算スマートコントラクトは、（担保アイテムのローン前販売が発生したと仮定して）借り手のデバイス2002に臨時販売通知を提供してもよく、借り手は、a）条件付き販売に同意してローンプロセスを進める、b）条件付き販売を拒否してローンプロセスを終了する（例えば、販売がオークションであり合意した清算価格が低すぎてローンを確保できない場合）、またはc）条件付き販売を完了してローンプロセスを終了すると決定することができる。借り手が条件付き販売を完了することに同意する場合、ローン前清算スマートコントラクトは、担保トークン2042の臨時の買い手への譲渡、および売却収益の買い手への譲渡（例えば、通貨／トークンまたは不換通貨での購入額）から市場が取った手数料を差し引くことを開始し得る。借り手が条件付き販売に同意した場合、ローン前清算スマートコントラクトインスタンスは、担保アイテムをエスクローアカウントにロックしてもよい。さらに、ローン前清算スマートコントラクトインスタンスは、ローンがデフォルトになった場合に条件付き買い手が販売価格を支払うことができるように、条件付き買い手からの売却収益（又はその一部）をエスクローアカウントに預託してもよい。ローン前清算スマートコントラクトインスタンスは、分散台帳にローン前清算イベントレコードを書き込んでよく、条件付売却が完了したこと及び担保アイテムのローン前清算価格を示す通知をローンプロセススマートコントラクトインスタンスに発行してよい。これに応答して、ローンプロセススマートコントラクトインスタンスは、ローンプロセスを貸し付けステージ3012に進めてもよい。

【0365】

貸し付けステージ3012の間、借り手は、ローンを要求してもよく、及び／又は、1人以上の貸し手とローンを交渉してもよい。貸し手及び借り手がローン条件に合意したという確認を受けると、ローンプロセスのスマートコントラクト2022は、合意されたローン条件に従ってローンスマートコントラクト2034をインスタンス化してもよい。いくつかの実施形態では、トークン化プラットフォーム100は、借り手が1つまたは複数の潜在的な貸し手にローンを要求すること、および／または1つまたは複数の貸し手とローン契約を交渉することを可能にするGUIを借り手に提供し得る。いくつかの実施形態では、ローン交渉は、トークン化プラットフォーム100などの集中型サービスを経由するのではなく、オンチェーンで処理されてもよいことが理解される。実施形態において、借り手は、ローン前の清算売却価値を超えないローン額と、ローンを返済するための時間額を示す提案されたローン期間とを要求してよい。これらの実施形態のいくつかでは、トークン化プラットフォーム100は、GUIを介して潜在的な貸し手に提示されるローン要求を生成してもよく、それによって、ローン要求は、求める金額、ローンの長さ、および借り手が提供した担保アイテムに関する情報（例えば、担保アイテムのVIRL、認証リポート、販売前の清算リポート、保管リポート、認証、鑑定および保管者がそれぞれのタスクを確保したこと（上述）等の確認）を示している。実施形態において、トークン化システム100は、ローンの返済額および／または金利（例えば、現在の市場条件に基づいて）を提案してもよい。代替的に、潜在的な貸し手は、GUIを介して、借り手が返済しなければならないであろう金利または総返済額を提供してもよい。さらに、潜在的な貸し手は、ローン額及び／又は返済期間など、要求されたローン条件のうちの1つ又は複数に対抗してもよい。その後、ローンオファーは、GUIを介して借り手に伝達されてもよく、借り手は、借り手デバイス2002を介してローンオファーを見ることができる。これに対して、借り手は、ローンオファーを受け入れるか、ローンオファーを拒否するか、またはカウンターオファーを提供することができる。当事者は、合意に達するか、一方または両方の当事者がローンの申し出を拒否するまで、このような方法を繰り返すことができる。ローンが合意されると、当事者は、ローン合意を実行してもよく、トークン化プラットフォーム100は、ローン合意が借り手と貸し手とによって合意されたことを示す通知をローンプロセススマートコントラクトインスタンスに提供してもよい。実施形態において、通知は、ローン契約の条件を含むローン契約の詳細を含んでもよい。これに応答して、ローンプロセスのスマートコントラクトインスタンスは、ローン返済ワークフローを実行するローンスマートコントラクトインスタンスをインスタンス化してもよい。ローン契約が実行されると、ローンスマートコントラクトは、担保トークンをエスクローアカウントにロックしてもよく、貸し手のアカウントから借り手のアカウントへの資金の譲渡を促進してもよい。実施形態において、ローン契約、任意のオファー／カウンターオファーの記録、及び担保トークンのエスクロー及び借り手への譲渡資金に関連する記録は、分散台帳2016に書き込まれてもよい。ローンプロセスのスマートコントラクトインスタンスが、担保トークンがロックされ、資金が送金されたという通知を受信すると、ローンプロセスのスマートコントラクトインスタンスは、ローンプロセスを返済ステージ3014に進めてもよい。

【0366】

返済ステージ3014の間、ローンスマートコントラクトインスタンスは、借り手によって貸し手（又は貸し手に支払いを分配するアカウント）に支払いがローンスケジュールに従って行われ、ローンがデフォルト状態でないことを保証するために、借り手の支払い履歴を監視してもよい。ローン返済のステージでは、借り手は支払いを送金することができます。支払いが行われるたびに、ローンプロセスのスマートコントラクトインスタンスは、支払いが行われたこと及び支払いの金額を示す支払い通知を受信してもよい。その後、ローンスマートコントラクトインスタンスは、ローンが全額返済されたか否かを判断してもよい。ローンが全額返済されていない場合、ローンスマートコントラクトインスタンスは、ローン返済額を調整してもよく、新しいローン返済額を反映するために認証機関及び／又は金庫から賭けられた資金の一部を戻すなどの追加の動作を実行してもよい。ローン返済額が全額支払われたとローンスマートコントラクトインスタンスが判断した場合、ローンスマートコントラクトインスタンスは、ローンが全額支払われたことを示す返済通知をローンプロセススマートコントラクトインスタンスに送信してもよく、ローンプロセスをローン後ステージ2716に前進させてもよい。実施形態において、返済通知は、支払いが行われたことを示す支払いイベントレコードのハッシュ値、及び支払いの金額、及び／又は分散台帳2016上の支払いレコードのアドレスを含んでもよい。逆に、ローンスマートコントラクトインスタンスが借り手がデフォルトしたと判断した場合、ローンスマートコントラクトは、ローンの条件に従ってローンがデフォルトであることを示すデフォルト通知をローンプロセスのスマートコントラクトに送信してもよい。実施形態において、デフォルト通知は、どの支払いが滞ったか、及びローンの残額を示すデフォルトイベントレコードのハッシュ値及び／又は分散台帳2016上のデフォルトイベントレコードのアドレスを含んでもよい。デフォルト通知を受信することに応答して、ローンスマートコントラクトインスタンスは、担保トークン2042の条件付き買い手への譲渡を開始するために、ローンプロセススマートコントラクトインスタンス及び／又はプレローンリクイデーションイベントスマートコントラにデフォルト通知を提供し得る。デフォルト条件が決定されると、ローンプロセスは、ローン後ステージ3016に進んでもよい。

【0367】

ローン後ステージ3016の間、担保トークン2042は、ローンが完全に支払われた場合に所有者に返却されるか、または担保トークン2042が、所有コンティンジェンシーに従ってコンティンジェントバイヤーに譲渡されるかのいずれかである。ローンが全額返済されたという返済通知の受信に応答して、ローンスマートコントラクトインスタンスは、エスクローアカウントから借り手のアカウントへの担保トークンの譲渡を開始してもよく、借り手は次に担保トークンを償還して担保アイテムの占有を取得することができる。ローンが正常に返済されると、ローンプロセスのスマートコントラクトインスタンスは、認証スマートコントラクト、ローン前清算スマートコントラクト、及び保管コントラクトに規定される条件に従って、認証者、条件付き報酬に基づく条件付き買い手、及び保管者のアカウントへの報酬の授与（例えば、貸し手に返済された資金から）を開始し得る。

【0368】

デフォルト条件の場合、ローンコントラクトインスタンスは、デフォルト通知を、ローンプロセスのスマートコントラクト及びローン前清算スマートコントラクトに提供してもよい。デフォルト条件の受信に応答して、ローン前清算スマートコントラクトは、ローン前清算イベント中に条件付き買い手から預託された資金をロック解除してもよい。ローンプロセスのスマートコントラクトインスタンスは、ローン前清算イベントの収益（例えば、臨時の買い手からのロック解除された資金、及び臨時の買い手が負っている残額）から、貸し手（又はローンが第２の貸し手に売却された場合には第２の貸し手）に対してローン返済額に対する残額を分配してよい。臨時の買い手が清算前販売を形成する未払い残高を有さないことを確認すると、ローン前清算スマートコントラクトインスタンスは、担保トークン2042をエスクローからロック解除してもよく、担保トークン2042を臨時の買い手のアカウントに譲渡してもよく、その人は次に担保トークンを償還して担保アイテムを所有し得る。さらに、ローンプロセスのスマートコントラクトインスタンスは、認証スマートコントラクト及び保管コントラクトに定められた条件に従って、ローン前清算イベントの収益から認証者及び保管者のアカウントに報酬を授与することを開始してもよい。任意の残高が残っている範囲において、残りは借り手のアカウントに入金され得る。

【0369】

ローンプロセスが完了すると、ローンプロセススマートコントラクトインスタンスは、ローンプロセスが完了したことをトークン化プラットフォーム100に通知してもよく、トークン化プラットフォーム100は、完了したローンプロセスに基づいて分析プロセスを実行してもよい。いくつかの実施形態では、ローンプロセスの結果は、認証者、保管者、条件付き買い手、貸し手、および／または借り手のうちの１または複数のレーティング（評価）を更新するために使用されてもよい。

【0370】

上述した説明は、分散型ローンプロセスのワークフロー3000の一例であり、代替的なワークフローが実行されてもよいことが理解される。さらに、分散型ローンプロセスのワークフロー3000は、明示的に説明されなかった追加的又は代替的なステップを含んでもよい。ローンプロセスのワークフロー3000のいくつかのステージの順序は、特定の効率性を達成するために変化してもよいことに留意されたい。例えば、担保アイテムが出荷困難であり、及び／又は腐敗しやすい場合、保管ステージ及びトークン化ステージは、認証ステージの前に実行されてもよい。

【0371】

本開示のいくつかの実施形態のみを示し、説明したが、以下の請求項に記載される本開示の精神及び範囲から逸脱することなく、多くの変更及び修正がそれに対してなされ得ることは、当業者には明らかであろう。本明細書で参照されるすべての特許出願および特許（外国および国内の両方）ならびにすべての他の刊行物は、法律で許可される最大限の範囲において、その全体が本明細書に組み込まれる。

【0372】

本明細書に記載された方法及びシステムは、プロセッサ上でコンピュータソフトウェア、プログラムコード、及び／又は命令を実行する機械を通して、一部又は全部を展開することができる。本開示は、機械上の方法として、機械の一部または機械に関連するシステムまたはデバイスとして、または機械の１つまたは複数で実行されるコンピュータ可読媒体に具現化されたコンピュータプログラム製品として実施されてもよい。実施形態において、プロセッサは、サーバ、クラウドサーバ、クライアント、ネットワークインフラ、モバイルコンピューティングプラットフォーム、据置型コンピューティングプラットフォーム、または他のコンピューティングプラットフォームの一部であってよい。プロセッサは、中央処理デバイス（CPU）、汎用処理デバイス（GPU）、論理ボード、チップ（例えば、グラフィックチップ、ビデオ処理チップ、データ圧縮チップなど）、チップセット、コントローラ、システムオンチップ（例えば。RFシステムオンチップ、AIシステムオンチップ、映像処理システムオンチップなど）、集積回路、特定用途向け集積回路（ASIC）、フィールドプログラマブルゲートアレイ（FPGA）、近似計算プロセッサ、量子計算プロセッサ、並列計算プロセッサ、ニューラルネットワークプロセッサ、又は他の種類のプロセッサである。プロセッサは、信号プロセッサ、デジタルプロセッサ、データプロセッサ、組み込みプロセッサ、マイクロプロセッサ、または、その上に格納されたプログラムコードまたはプログラム命令の実行を直接的または間接的に促進し得るコプロセッサ（数学コプロセッサ、グラフィックコプロセッサ、通信コプロセッサ、ビデオコプロセッサ、AIコプロセッサなど）等の任意の変種であってもよいし、それを含んでいてもよい。さらに、プロセッサは、複数のプログラム、スレッド、及びコードの実行を可能にしてもよい。スレッドは、プロセッサの性能を向上させ、アプリケーションの同時動作を容易にするために、同時に実行されてもよい。実施態様として、本明細書に記載される方法、プログラムコード、プログラム命令などは、１つまたは複数のスレッドで実装されてもよい。スレッドは、それらに関連する割り当てられた優先順位を有することができる他のスレッドを生成してもよく、プロセッサは、プログラムコードに提供される命令に基づく優先順位または他の任意の順序に基づいてこれらのスレッドを実行してもよい。プロセッサ、またはプロセッサを利用する任意の機械は、本明細書および他の場所で説明されるような方法、コード、命令およびプログラムを格納する非一時的メモリを含んでもよい。プロセッサは、本明細書および他の場所で説明されるような方法、コード、および命令を格納することができるインターフェースを介して非一時的な記憶媒体にアクセスしてもよい。コンピューティングまたは処理デバイスによって実行可能な方法、プログラム、コード、プログラム命令または他のタイプの命令を格納するためのプロセッサに関連する記憶媒体は、CD-ROM、DVD、メモリ、ハードディスク、フラッシュドライブ、RAM、ROM、キャッシュ、ネットワーク接続ストレージ、サーバベースストレージなどのうちの１以上を含むことができるが、それに限定されるものではない。

【0373】

プロセッサは、マルチプロセッサの速度及び性能を強化し得る１つ又は複数のコアを含んでもよい。実施形態では、プロセスは、２つ以上の独立したコア（ダイと呼ばれることもある）を組み合わせたデュアルコアプロセッサ、クアッドコアプロセッサ、他のチップレベルマルチプロセッサ等であってもよい。

【0374】

本明細書に記載された方法およびシステムは、サーバ、クライアント、ファイアウォール、ゲートウェイ、ハブ、ルータ、スイッチ、インフラストラクチャ・アズ・ア・サービス、プラットフォーム・アズ・ア・サービス、または他のそのようなコンピュータおよび／またはネットワークハードウェアもしくはシステム上でコンピュータソフトウェアを実行する機械を通じて一部または全部を展開することができる。ソフトウェアは、ファイルサーバ、プリントサーバ、ドメインサーバ、インターネットサーバ、イントラネットサーバ、クラウドサーバ、インフラストラクチャアズサービスサーバ、プラットフォームアズサービスサーバ、Webサーバ、およびセカンダリサーバ、ホストサーバ、分散サーバ、フェイルオーバーサーバ、バックアップサーバ、サーバファームなどの他の変形を含み得るサーバと関連してもよい。サーバは、メモリ、プロセッサ、コンピュータ可読媒体、記憶媒体、ポート（物理および仮想）、通信デバイス、および有線または無線媒体を通じて他のサーバ、クライアント、マシン、およびデバイスにアクセスすることができるインターフェースのうちの1つ以上を含んでもよい。本明細書等に記載された方法、プログラム、またはコードは、サーバによって実行され得る。さらに、本願に記載されるような方法の実行に必要な他のデバイスは、サーバに関連するインフラの一部とみなすことができる。

【0375】

サーバは、クライアント、他のサーバ、プリンタ、データベースサーバ、プリントサーバ、ファイルサーバ、通信サーバ、分散サーバ、ソーシャルネットワークなどを含む他のデバイスへのインターフェースを提供してもよい。さらに、この結合および／または接続は、ネットワークを介したプログラムのリモート実行を促進してもよい。これらのデバイスの一部またはすべてのネットワーク化は、本開示の範囲から逸脱することなく、１つまたは複数の場所でのプログラムまたは方法の並列処理を容易にし得る。さらに、インターフェースを介してサーバに接続されたデバイスのいずれかが、方法、プログラム、コード及び／又は命令を格納することができる少なくとも1つの記憶媒体を含んでもよい。中央リポジトリは、異なるデバイス上で実行されるようにプログラム命令を提供してもよい。この実施態様では、リモートリポジトリは、プログラムコード、命令、及びプログラムのための記憶媒体として機能してもよい。

【0376】

ソフトウェアプログラムは、ファイルクライアント、プリントクライアント、ドメインクライアント、インターネットクライアント、イントラネットクライアント、および二次クライアント、ホストクライアント、分散クライアントなどの他の変形を含むことができるクライアントに関連付けられることがある。クライアントは、メモリ、プロセッサ、コンピュータ可読媒体、記憶媒体、ポート（物理および仮想）、通信デバイス、および有線または無線媒体を通じて他のクライアント、サーバ、マシン、およびデバイスにアクセスすることができるインターフェースなどのうちの1つまたは複数を含んでもよい。本明細書等に記載された方法、プログラム、またはコードは、クライアントによって実行され得る。さらに、本願に記載されるような方法の実行に必要な他のデバイスは、クライアントに関連するインフラの一部と考えることができる。

【0377】

クライアントは、サーバ、他のクライアント、プリンタ、データベースサーバ、プリントサーバ、ファイルサーバ、通信サーバ、分散サーバなどを含む他のデバイスへのインターフェースを提供してもよい。さらに、この結合および／または接続は、ネットワークを介したプログラムのリモート実行を促進してもよい。これらのデバイスの一部またはすべてのネットワーク化は、本開示の範囲から逸脱することなく、1つまたは複数の場所でのプログラムまたは方法の並列処理を容易にすることができる。さらに、インターフェースを介してクライアントに取り付けられるデバイスのいずれかが、方法、プログラム、アプリケーション、コードおよび／または命令を格納することができる少なくとも1つの記憶媒体を含んでもよい。中央リポジトリは、異なるデバイス上で実行されるプログラム命令を提供してもよい。この実施態様では、リモートリポジトリは、プログラムコード、命令、およびプログラムのための記憶媒体として機能してもよい。

【0378】

本明細書に記載された方法およびシステムは、その一部または全部を、ネットワークインフラストラクチャーを通じて配備することができる。ネットワークインフラは、コンピューティングデバイス、サーバ、ルータ、ハブ、ファイアウォール、クライアント、パーソナルコンピュータ、通信デバイス、ルーティングデバイス、および当該技術分野で知られている他のアクティブおよびパッシブデバイス、モジュールおよび／またはコンポーネントなどの要素を含むことができる。ネットワークインフラに関連するコンピューティング及び／又は非コンピューティングデバイス（複数可）は、他の構成要素とは別に、フラッシュメモリ、バッファ、スタック、RAM、ROMなどの記憶媒体を含んでもよい。本明細書および他の場所で説明されるプロセス、方法、プログラムコード、命令は、ネットワークインフラストラクチャー要素の1つまたは複数によって実行されてもよい。本明細書に記載された方法及びシステムは、サービスとしてのソフトウェア（SaaS）、サービスとしてのプラットフォーム（PaaS）、及び／又はサービスとしてのインフラストラクチャ（IaaS）の特徴を伴うものを含む、任意の種類のプライベート、コミュニティ、又は、ハイブリッドクラウドコンピューティングネットワーク又はクラウドコンピューティング環境での使用に適合されうる。

【0379】

本明細書および他の場所で説明した方法、プログラムコード、および命令は、複数のセルを有するセルラーネットワークで実施することができる。セルラーネットワークは、周波数分割多重アクセス（FDMA）ネットワークまたは符号分割多重アクセス（CDMA）ネットワークのいずれかであってよい。セルラーネットワークは、モバイルデバイス、セルサイト、基地局、リピータ、アンテナ、タワーなどを含んでもよい。セルラーネットワークは、GSM、GPRS、3G、4G、5G、LTE、EVDO、メッシュ、または他のネットワークタイプであってもよい。

【0380】

本明細書および他の場所で説明された方法、プログラムコード、および命令は、モバイルデバイス上で、またはモバイルデバイスを通して実施されてもよい。モバイルデバイスは、ナビゲーションデバイス、携帯電話、モバイルパーソナルデジタルアシスタント、ラップトップ、パームトップ、ネットブック、ポケットベル、電子ブックリーダー、音楽プレイヤーなどを含んでもよい。これらのデバイスは、他の構成要素とは別に、フラッシュメモリ、バッファ、RAM、ROMなどの記憶媒体、及び1つ以上のコンピューティングデバイスを含んでもよい。モバイルデバイスに関連するコンピューティングデバイスは、そこに格納されたプログラムコード、方法、および命令を実行することが可能であってもよい。あるいは、モバイルデバイスは、他のデバイスと協働して命令を実行するように構成されてもよい。モバイルデバイスは、サーバとインターフェース接続され、プログラムコードを実行するように構成された基地局と通信してもよい。モバイルデバイスは、ピアツーピアネットワーク、メッシュネットワーク、または他の通信ネットワーク上で通信してもよい。プログラムコードは、サーバに関連付けられた記憶媒体に格納され、サーバ内に組み込まれたコンピューティングデバイスによって実行されてもよい。基地局は、コンピューティングデバイスと記憶媒体とを含んでもよい。記憶媒体は、プログラムコードと、基地局に関連するコンピューティングデバイスによって実行される命令とを記憶してもよい。

【0381】

コンピュータソフトウェア、プログラムコード、および／または命令は、コンピュータコンポーネント、デバイス、およびコンピューティングに使用されるデジタルデータをある間隔の間保持する記録媒体、ランダムアクセスメモリ（RAM）として知られる半導体ストレージ、光ディスク、ハードディスク、テープ、ドラム、カードなどの磁気ストレージの形態など、より永久的に保存するための通常マスストレージ、プロセッサレジスタ、キャッシュメモリ、揮発メモリ、不揮発メモリ、CD、DVDなどの光学ストレージ、フラッシュメモリなどの取り外し可能メディア（例えば、USBスティックまたはキー）、フロッピーディスク、磁気テープ、紙テープ、パンチカード、スタンドアロンRAMディスク、Zipドライブ、リムーバブルマスストレージ、オフラインなどのリムーバブルメディア、動的メモリ、静的メモリ、リード／ライトストレージ、可変ストレージ、読み取り専用、ランダムアクセス、順次アクセス、ロケーションアドレス可能、ファイルアドレス可能、コンテンツアドレス可能、ネットワーク接続ストレージ、ストレージエリアネットワーク、バーコード、磁気インク、ネットワーク接続ストレージ、ネットワークストレージ、NVMEアクセス可能ストレージ、PCIE接続ストレージ、分散ストレージなど他のコンピュータメモリなどである。

【0382】

本明細書に記載される方法及びシステムは、物理的及び／又は無形のアイテムをある状態から別の状態に変換することができる。本明細書に記載される方法及びシステムは、物理的及び／又は無形のアイテムを表すデータを、ある状態から別の状態に変換することもできる。

【0383】

図中のフローチャートおよびブロック図を含め、本明細書で説明および描写される要素は、要素間の論理的な境界を意味するものである。しかしながら、ソフトウェアまたはハードウェア工学の実践に従って、描かれた要素およびその機能は、モノリシックソフトウェア構造として、スタンドアロンソフトウェアモジュールとして、または外部ルーチン、コード、サービスなどを採用するモジュールとして、またはこれらの任意の組み合わせとして、そこに格納されたプログラム命令を実行できるプロセッサを用いてコンピュータ実行コードを通じて機械に実装されてよく、そのような実装のすべてが本開示の範囲内にあり得る。このような機械の例としては、パーソナルデジタルアシスタント、ラップトップ、パーソナルコンピュータ、携帯電話、他の携帯コンピューティングデバイス、医療機器、有線または無線通信デバイス、トランスデューサ、チップ、電卓、衛星、タブレットPC、電子書籍、ガジェット、電子デバイス、デバイス、人工知能、コンピューティングデバイス、ネットワーク機器、サーバ、ルータなどが挙げられ得るが、それらに限定されることはない。さらに、フローチャートやブロック図に描かれた要素、あるいはその他の論理的構成要素は、プログラム命令を実行可能な機械に実装されてもよい。したがって、前述の図面および説明は、開示されたシステムの機能的側面を示しているが、これらの機能的側面を実装するためのソフトウェアの特定の配置は、明示的に記載されているか、または文脈から明らかでない限り、これらの説明から推論されるべきではない。同様に、上記で特定され、説明された様々なステップは、変化させてもよく、ステップの順序は、本明細書に開示された技術の特定の用途に適合させてもよいことが理解されるであろう。全てのそのような変形及び修正は、本開示の範囲内に入ることが意図されている。そのため、様々なステップに対する順序の描写及び／又は説明は、特定の用途によって要求されない限り、又は明示的に記載されているか、又は文脈から明らかでない限り、それらのステップに対する特定の実行順序を要求すると理解すべきではない。

【0384】

上述した方法及び／又はプロセス、並びにそれに関連するステップは、ハードウェア、ソフトウェア、又は特定の用途に適したハードウェアとソフトウェアの任意の組み合わせで実現することができる。ハードウェアは、汎用コンピュータ及び／又は専用コンピューティングデバイス又は特定のコンピューティングデバイス又は特定の側面若しくはコンポーネントを含んでもよい。プロセスは、内部及び／又は外部メモリと共に、1つ又は複数のマイクロプロセッサ、マイクロコントローラ、組み込みマイクロコントローラ、プログラム可能なデジタル信号プロセッサ又は他のプログラム可能なデバイスで実現されてもよい。プロセスはまた、またはその代わりに、特定用途向け集積回路、プログラマブルゲートアレイ、プログラマブルアレイロジック、または電子信号を処理するように構成され得る任意の他のデバイスまたはデバイスの組み合わせにおいて具現化され得る。さらに、プロセスの１つ以上は、機械可読媒体上で実行可能なコンピュータ実行可能コードとして実現されてもよいことが理解されよう。

【0385】

コンピュータ実行可能コードは、Cなどの構造化プログラミング言語、C＋＋などのオブジェクト指向プログラミング言語、または他の高位または低位プログラミング言語（アセンブリ言語、ハードウェア記述言語、データベースプログラミング言語および技術を含む）を使用して作成されてよく、上記のデバイスの1つ、ならびにプロセッサ、プロセッサアーキテクチャ、または異なるハードウェアおよびソフトウェアの異種組み合わせ、またはプログラム命令を実行できる他のマシンで実行するために格納、コンパイルまたはインタープリットされてもよい。コンピュータソフトウェアは、仮想化、仮想マシン、コンテナ、ドックファシリティー、ポーテナー、および他の機能を採用してもよい。

【0386】

したがって、１つの態様において、上述した方法およびその組み合わせは、１つまたは複数のコンピューティングデバイス上で実行されると、そのステップを実行するコンピュータ実行可能コードで具現化されてもよい。別の態様では、方法は、そのステップを実行するシステムで具現化されてもよく、多くの方法でデバイス間に分散されてもよく、または機能のすべてが、専用のスタンドアロンデバイスまたは他のハードウェアに統合されてもよい。別の態様では、上述のプロセスに関連するステップを実行するための手段は、上述のハードウェアおよび／またはソフトウェアのいずれかを含んでもよい。そのようなすべての順列および組み合わせは、本開示の範囲に入ることが意図されている。

【0387】

本開示は、詳細に示され説明された好ましい実施形態に関連して開示されているが、それに対する様々な変更及び改良は、当業者にとって容易に明らかになるであろう。従って、本開示の精神及び範囲は、前述の例によって限定されるものではなく、法律で許容される最も広い意味で理解されるものである。

【0388】

本開示を説明する文脈における（特に以下の請求項の文脈における）単数の用語の使用は、本明細書において特に示されるか又は文脈によって明らかに矛盾しない限り、単数と複数の両方をカバーするように解釈されるものである。用語「からなる」、「有する」、「含む」、及び「含む」は、特に断らない限り、オープンエンドな用語（すなわち、「含むが、これに限定されない」という意味）として解釈されるものとする。本明細書における値の範囲の叙述は、本明細書に特に示されない限り、範囲内に入る各別の値を個別に参照するための略記法として役立つことを単に意図しており、各別の値は、本明細書に個別に叙述されているかのように本明細書に組み込まれる。本明細書に記載される全ての方法は、本明細書に別途示されない限り、または文脈によって明らかに矛盾しない限り、任意の適切な順序で実行することができる。本明細書で提供される任意の及び全ての例、又は例示的な言語（例えば、「など」）の使用は、単に本開示をより良く説明することを意図しており、特に主張しない限り本開示の範囲に制限を与えるものではない。用語「セット」、「組」は、単一の部材を有するセットを含むことができる。本明細書におけるいかなる文言も、請求されていない要素を本開示の実施に必須であると示すものとして解釈されるべきではない。

【0389】

上述した説明により、当業者は、現在その最良の態様と考えられるものを製造し使用することができるが、当業者は、本明細書における特定の実施形態、方法、及び例の変形、組み合わせ、及び同等物の存在を理解し理解するであろう。したがって、本開示は、上述した実施形態、方法、及び例によって限定されるべきではなく、本開示の範囲及び精神の範囲内の全ての実施形態及び方法によって限定されるべきである。

【0390】

本明細書で参照されるすべての文書は、本明細書に完全に記載されているかのように、参照により本明細書に組み込まれる。

【図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】

【国際調査報告】