JP2022536445A - トークン化された資産に関するデータを管理するためのデータ記憶及び検索システムを構成するための、システム、方法、及び記憶媒体 - Google Patents

Abstract

個々の資産及びファンドなどの複合資産のための非中央集権化された資産管理を容易にするために、コンピューティング・システムを構成するための装置、コンピュータ可読媒体、及びコンピュータ実装方法。実装形態は、スマート・コントラクト・インターフェースを含み、代替性トークンを非代替性資産トークンにリンクして、コードの再使用を容易にするために証券取引ロジック及びコーポレート・ファンクションを資産管理から切り離す。追加的に、具体化される処理は、トークンのネスト化を使用して、同質又は異質な資産を１つのファンド構造に組み合わせられるようにし、さらにファンドをファンド・オブ・ファンドのモデルにコンポーズできるようにする。柔軟な構造は、ファンド管理の自動化を可能にし、開示される構造を活用する革新的な資産管理戦略への幅広い投資家アクセスを容易にするように設計される。

Description

本出願は、２０１９年４月１７日に出願された米国仮特許出願第６２／８３４，９９９の非仮特許出願の利益を主張するものであり、その開示は参照により本明細書に組み込まれる。

本開示は、トークン化された資産に関するデータを管理するためのシステムを構成するための、システム、方法、及び記憶媒体に関する。

著作権の注意
本特許文書の開示の一部には、著作権保護の対象となる内容が含まれる。特許商標庁の特許ファイル又は記録に現れる限りにおいては、著作権の所有者は、誰でも当該特許文書又は特許開示を複製することについて異議を唱えないが、それ以外の場合、如何なる場合でもすべての著作権を留保する。

米国特許出願公開第２０１９０１６４１５１（Ａ１）号

ｈｔｔｐｓ：／／ｇｉｔｈｕｂ．ｃｏｍ／ｅｔｈｅｒｅｕｍ／ＥＩＰｓ／ｂｌｏｂ／ｍａｓｔｅｒ／ＥＩＰＳ／ｅｉｐ－７２１．ｍｄ ｈｔｔｐｓ：／／ｅｉｐｓ．ｅｔｈｅｒｅｕｍ．ｏｒｇ／ＥＩＰＳ／ｅｉｐ－１６１６ ｈｔｔｐｓ：／／ｇｉｔｈｕｂ．ｃｏｍ／ｅｔｈｅｒｅｕｍ／ＥＩＰｓ／ｉｓｓｕｅｓ／１６４３ ｈｔｔｐｓ：／／ｈａｃｋｅｒｎｏｏｎ．ｃｏｍ／ｈｏｗ－ｔｏ－ｍａｋｅ－ｓｍａｒｔ－ｃｏｎｔｒａｃｔｓ－ｕｐｇｒａｄａｂｌｅ－２６１２ｅ７７１ｄ５ａ２

出願人は、資産管理を合理化して非中央集権化しつつ、例えばバリュエーションのデータ処理の向上を実現する、データ・モデル及びコンピュータ・アーキテクチャを作成した。実装形態は、資産（アセット）を表現する暗号化トークンを発行するために、分散台帳上の少なくとも１つのコンピューティング・デバイスによって、スマート・コントラクトを使用してコンピュータ・ネットワークを介して実行される方法を含む。実装形態は、新規なデータ構造、及びトークンのネスト化、つまり他のトークンを資産として含む、資産としてのトークンを可能にするように設計されたインターフェースを含む。投資ファンドは、資産を含む資産であるため、この新規なデータ・モデルは、高度なファンド戦略、バリュエーション、及び資産管理を、非中央集権化されたやり方で行うことができる処理バックボーンを提供する。しかしながら、実装形態は、中央集権化されたアーキテクチャを含み、またこれらのアーキテクチャに関するデータ処理及び通信上の利点を提供する。追加的に、新規なトークン・データ構造及びインターフェース設計は、共有された取引ロジック、総合的な監査可能性、及びスケーラブルな記録保存を可能にしつつ、個々の資産の挙動及び関連ロジックを切り離す。構造は、基本的な取引ロジック及び資産管理ファンクションの再使用を可能にする。開示される実装形態は、広範な資産タイプをサポートし、同質な資産を有する単純なファンド（又は異質な資産を有する複雑な多様化ファンド）構造の形成を可能にし、新規なファンド管理手法において迅速なイノベーションを容易にする「プラグイン・ポイント」を公開することができる。

開示されるファンド構造は、繰返し可能なモデルを作成し、投資家の透明性を向上し、ファンド保守のコストを低減し、新しい資産クラスの市場への経路及びファンド管理戦略を合理化することができる。開示される実装形態を使用して、発行者として知られる資産管理戦略をオファーするパーティは、非中央集権化されたネットワーク化コンピューティング・プラットフォーム上で、所望であれば上場投資信託（ＥＴＦ：Ｅｘｃｈａｎｇｅ Ｔｒａｄｅｄ Ｆｕｎｄ）のような複雑且つ高度に規制された金融商品を含む、市場対応資産を数分でデプロイすることができる。

開示される実装形態は、コンピュータ・アーキテクチャ、コンピュータ可読データ構造、及びコンピュータ・インターフェースの実装形態を定義して、複合資産、例えばファンドを含むあらゆる資産タイプを、検査する、価値評価する、取引する、組み合わせる、及び管理する。米国特許出願公開第２０１９０１６４１５１（Ａ１）号に開示されるトークン・フレームワークと連結して、モデルは、グローバルな企業コンプライアンス、スケーラブルな取引ロジック、単純化された管理、及び透明な資産パフォーマンスのための、十分機能的な非中央集権化されたアーキテクチャを提供する。結果としては、投資家に代わり非中央集権化されたプラットフォーム上で所望の資産管理戦略を自動的に実行するために、あらゆる発行者によって活用され得る、自動化され、規格ベースであり、自己レポーティング型のファンドである。

開示される実装形態は、ファンド・シェルを表現する非代替性トークンを含むフレームワークを提供する、つまり資産を追加及び除去すること、又はバリュエーションを公表することなどの汎用ファンド管理ファンクションを取り扱うファンド構造は、資産でポピュレートすることができ、所望であればファンド売り上げのウォーターフォール処理用にサード・パーティのスマート・コントラクトを組み込むことができる。シェルは、ステークホルダー投票を通じて、又は自動化された資産管理戦略を介してファンド管理戦略を手動で扱うことができるよう、プラグイン構造を提供する。口語的に「ロボ・アドバイザ」として知られる自動化された戦略は、資産割当用の効率的なモデルとして牽引力を獲得している。開示される実装形態は、非中央集権化されたネットワーク上で、資産割当ロジックを汎用ファンド処理から切り離すことによって、自動化された（又は手作業）の管理戦略の開発及びデプロイメントにおける迅速なイノベーションを可能にする。

出願人は、「弾力的な証券化」と呼ばれる新規なファンド管理戦略を開示する。この戦略により、クローズド・エンド型のファンド、つまり固定数の株式が存在するファンドが、認可された関与者を使うことなく、市場需要に基づいてサイズ（管理下の資産）を拡大又は縮小できるようにする。この革新的な手法は、非流動性資産の上場投資信託をサポートするのに役立ち、それによりＥＴＦ利用を介して新しい資産クラスへの投資家アクセスを提供する。

開示される実装形態は、トークン化された資産を代替性トークン取引フレームワークにリンクするインターフェース仕様を含み、価値移転向けの従来的な分散台帳技術（ＤＬＴ：Ｄｉｓｔｒｉｂｕｔｅｄ Ｌｅｄｇｅｒ Ｔｅｃｈｎｏｌｏｇｉｅｓ）の実務（実例として、Ｅｔｈｅｒｅｕｍ ＥＲＣ２０規格）を、コーポレート・ガバナンス、支払い配分、及びポリシー施行（米国特許出願公開第２０１９０１６４１５１（Ａ１）号に開示される通り）のためのロジックで拡大する。結果としてのデータ構造により、非中央集権化されたアーキテクチャがトークン、ファンド、及び他の複雑な資産の価値を自動的に通信できるようになる。このことは、投資家、つまり代替性デジタル・トークンの保有者に、異質な資産及びネスト化された資産（例えば、ファンド・オブ・ファンド）を有する複雑なファンド構造であっても、自身が所有している価値を効率的に検査する能力を与える。投資家、又は他のステークホルダーは、資産ごとのパフォーマンス、キャッシュ・フロー、及びデータに対する一貫性のあるリアルタイムなアクセスを用いて、全体的なパフォーマンス及び基礎となる資産の列挙されたリストの両方をレビューすることができる。開示される実装形態は、基礎となる資産のパフォーマンスへのより高度な透明性、ファンド運用のより高度な規制監視、及びアセット・マネージャのより低い運用コストを可能にする。２００８年より前に、開示されるコンピューティング・アーキテクチャがＲＭＢＳファンドに実装されていれば、世界的な金融危機（ＧＦＣ：Ｇｌｏｂａｌ Ｆｉｎａｎｃｉａｌ Ｃｒｉｓｉｓ）に寄与したと信じられている多くの要因が軽減されていたであろう。

本開示の一態様は、トークン化された資産に関するデータを管理するためのデータ記憶及び検索システムを構成するための方法を含み、方法は、クラス定義に従ってデジタル・トークンを作成することであって、トークンは一意なトークン識別子を含む、作成することと、デジタル・トークンを、資産と関連付けて、一意なレコードとして資産レジストリのメモリ・デバイスに登録することと、クラス定義に従って通信インターフェースをデジタル・トークンに関連付けることであって、通信インターフェースは、資産レジストリによって実装される通信仕様に準拠しており、所定のファンクションのセットを公開するように構成され、所定のファンクションは資産所有権移転ファンクション、資産バリュエーション公表ファンクション、資産属性決定ファンクション、及び資産特有処理ロジックを含む、関連付けることとを含む。

これら及び他の特徴、並びに本技術の特性、同様に、動作の方法及び構造の関連要素のファンクション及び部分の組合せ及び製造の経済は、添付の図面を参照して以下の説明及び添付の特許請求の範囲を検討するとより明らかとなり、それらのすべては本明細書の一部を成し、様々な図面において同じ符号は対応する部分を指す。しかしながら、図面は単に図示及び説明を目的としたものであり、本発明の限定の定義として意図されないことが明示的に理解されよう。本明細書及び特許請求の範囲で使用される場合、単数形「１つ（ａ）」、「１つ（ａｎ）」及び「その（ｔｈｅ）」には、コンテキストが明らかにそうではないと述べない限り、複数形の指示対象が含まれる。

開示される実装形態による、トークン化された資産を作成、構成、及び管理するためのコンピューティング・アーキテクチャの概略図である。 開示される実装形態による、基本的な非代替性資産トークン及びその高レベル・インターフェースの概略図である。 開示される実装形態による、資産トークン販売及び購入の処理フローの図である。 開示される実装形態による、資産バリュエーション・ファンクションのインターフェース仕様の図である。 開示される実装形態による、バリュエーション処理のフローの図である。 開示される実装形態による、基本的なファンド・トークン及びその高レベル・インターフェースの概略図である。 開示される実装形態による、他のトークンを所有するトークン・ウォレットの実例を図示する概略図である。 部分所有権をサポートするための非代替性資産から代替性資産トークンへの接続の概略図であり、開示される実装形態による、基本的な非代替性資産トークンの概略図である。 開示される実装形態による、切り離した資産管理ロジック及びファンド構造を用いて自動化することができる基本的なファンド運用の図である。 開示される実装形態による、ファンド構造を処理するためのコンピューティング・プラットフォームを構成するための方法のフロー・チャートである。

図１は、開示される実装形態による、資産をトークン化して管理するためのコンピュータ・アーキテクチャ１００を図示している。いくつかの実装形態では、アーキテクチャ１００は、クライアント／サーバ・アーキテクチャ、ピアツーピア・アーキテクチャ、及び／又は他のアーキテクチャに従って、１つ又は複数のリモートのコンピューティング・プラットフォームと通信するように構成することができる１つ又は複数のコンピューティング・プラットフォームを含んでもよい。プラットフォームは、１つ又は複数の命令モジュールを含み得る機械可読命令によって構成されてもよい。命令モジュールは、非一時的なメモリに記憶されるコンピュータ・プログラム・モジュールを含んでもよい。

ＥＴＦなどの投資ファンドは、本明細書では、開示される実装形態を用いて管理することが可能な資産の実例として用いられる。開示される実装形態に従ってＥＴＦファンドを作成して開始するために、発行者は以下を含む複数ステップの処理に従う：（１）ＩＡｓｓｅｔモジュール１０２（以下で詳細に説明する）の所定の仕様（本明細書では「ＩＡｓｓｅｔＴｏｋｅｎ」仕様と称される）を使用してファンド資産をトークン化する；（２）ＩＡｓｓｅｔモジュール１０２（以下で詳細に説明する）の所定の仕様（本明細書では「ＩＡｓｓｅｔＦｕｎｄ」仕様と称される）を使用してファンド自身をトークン化する；（３）資産管理、列挙、及びネスト化を可能にする新規なトークン・データ構造を使用して、ＡｄｄＡｓｓｅｔＲｅｑｕｅｓｔファンクション（以下で詳細に説明する）を使用してトークン化された資産をファンドに付加する；（４）所望であれば、ＩＡｓｓｅｔモジュール１０２（以下で詳細に説明する）のＩＡｓｓｅｔＭａｎａｇｅｍｅｎｔＦｕｎｇｉｂｌｅインターフェース（以下で詳細に説明する）を使用して非代替性トークンを代替性トークンに付加して、部分所有権及び簡略化された取引をサポートする。開示される実装形態のトークンは、本明細書では時に「ＩＡｓｓｅｔトークン」と称されることに留意されたい。これらの仕様、インターフェース処理ステップ、及びデータ構造のすべては、非中央集権化的なシステムにおけるファンド管理を容易にし、本明細書で詳細に説明される。様々なファンクション及びインターフェースを実装するソース・コードの実例が、本特許出願の明細書の一部であるＡｐｐｅｎｄｉｘに含まれている。

資産レジストリ・モジュール１０４は、資産を表現するトークンを発行して追跡するスマート・コントラクト、ＡｓｓｅｔＲｅｇｉｓｔｒｙを含む。これらのトークンは、資産同士の関係を管理して、バリュエーション・ファンクションなどの基本的な資産ファンクションを公開するためのインターフェースを実装する。資産は、ＡｓｓｅｔＣｌａｓｓＲｅｇｉｓｔｒｙモジュール１０６において追跡することが可能なクラスに割り振られてもよい。本明細書で使用される場合、用語「クラス」は、オブジェクト指向プログラミングの分野では周知であり、オブジェクト（特定のデータ構造）を作成するための「ブループリント」を称することができ、状態の初期値（メンバ変数又は属性）及び挙動の実装（メンバ関数又はメソッド）を与える。

資産クラス割り振りにより、トークンはそのクラスに特有の性質及びファンクションを公開することができる。ＣｏｎｔｒａｃｔＲｅｇｉｓｔｒｙモジュール１０８は、開発者が新しいインターフェース及び実装形態を公表して、クラス内のすべての資産の挙動を高度化又は拡張、例えば、アップグレード）できるようにする。ＩＣｏｎｔｒａｃｔＷａｌｌｅｔモジュール１１０は、資産、クラス、又はその資産を介してウォレットの機能性を提供する他の要素を表現する個々のトークンに付加することができるスマート・コントラクトベースの暗号ウォレットを実装して管理する。ＡｔｔｒｉｂｕｔｅｓＲｅｇｉｓｔｒｙモジュール１１２、ＡｔｔｅｓｔａｔｉｏｎＲｅｇｉｓｔｒｙモジュール１１４、ＵｐｄａｔｅｓＲｅｇｉｓｔｒｙモジュール１１６、及びＰｏｌｉｃｙＥｎｇｉｎｅモジュール１１８は、以下で説明される方法で資産（及び他のサービス）によって使用される。

トークンが発行されると、ＡｓｓｅｔＲｅｇｉｓｔｒｙモジュール１０４のＡｓｓｅｔＲｅｇｉｓｔｒｙスマート・コントラクトは、資産クラスをトークンに割り振り、ＩＣｏｎｔｒａｃｔＷａｌｌｅｔインターフェースを実装する新しいスマート・コントラクトをデプロイし、それによりウォレットをトークンに関連付ける。結果として、それぞれ作成されたトークンは、その識別子によってトークンにリンクされる一意なウォレット・アドレスを有することになり（図２に示される通り）、割り振られた資産クラスの性質及びファンクションを実装することができる。ＡｓｓｅｔＲｅｇｉｓｔｒｙモジュール１０４は、ＩＷａｌｌｅｔＣｏｎｔｒａｃｔインターフェースを動作させて、ウォレットに関するアクションについてのポリシーを施行する。典型的には、ポリシーは、トークンの所有者のみが、ウォレット・コントラクトを介してアクションを実行できるようにする。ウォレットは、トークン、及び任意選択でＥｔｈｅｒ（ＥＴＨ）などの暗号通貨の移転又は受け取りの機能性をサポートする。ウォレットは、ＥＲＣ－２０、ＥＲＣ－７２１、ＥＲＣ－１４００及び他の標準的なインターフェース・トークンと互換性のあるトークンをサポートすることができる。

ＩＣｏｎｔｒａｃｔＷａｌｌｅｔモジュール１１０によって実装されるスマート・コントラクトは、ウォレットを運用して、ＵｐｄａｔｅｓＲｅｇｉｓｔｒｙモジュール１１６（すべての他のシステム・コンポーネント同様）を介してアップグレード可能性をサポートする。この構造により、変更された又はアップグレードされた挙動を実装する新しいウォレットのスマート・コントラクトの登録が可能となる。トークンの所有者、又は他の被指定者は、新しいウォレットのコントラクトをトークンに割り振るよう選択して、アップグレードされたファンクションを実装することができるか、又は場合によっては、そのような割り振りを拒否してもよい。ＣｏｎｔｒａｃｔＲｅｇｉｓｔｒｙモジュール１０８は、ＡｓｓｅｔＣｌａｓｓ（ＡｓｓｅｔＣｌａｓｓレジストリ・モジュール１０６から）又はＡｓｓｅｔインスタンス（ＡｓｓｅｔＲｅｇｉｓｔｒｙモジュール１０４から）用にカスタマイズされたファンクションを提供するスマート・コントラクト・インターフェースを記憶する。それぞれのトークンは、属性、ファンクション、及びクラスの実装ロジックへのアクセスを提供するクラスに割り振ってもよい。Ａｓｓｅｔ又はＡｓｓｅｔＣｌａｓｓ所有者（又は被指定者）は、インターフェース・レジストリから実装形態を選ぶことができる。開発者は、所有者の資産についてのカスタム・ロジックを公開するために、所有者が選択できるように、カスタム実装形態を伴う新しいスマート・コントラクトをＣｏｎｔｒａｃｔＲｅｇｉｓｔｒｙモジュール１０８にサブミットすることができる。

スマート・コントラクトは、個々の資産を表現する非代替性トークンの発行を可能にするＡｓｓｅｔＲｅｇｉｓｔｒｙモジュール１０４を実装する分散台帳上にデプロイすることができる。本明細書では、ＡｓｓｅｔＲｅｇｉｓｔｒｙモジュール１０４を実装するスマート・コントラクトの物理的なデプロイメントを詳細に説明していないが、そのようなデプロイメントは当業者に十分に理解される従来的な技法を用いることができるためである。

トークン所有者モジュール１２０は、資産レジストリ１０４で資産（例えば、非代替性トークンによって表現される）に対して制御を行使するパーティのシステムに関連付けられる。この制御は、資産に対して制御権限を有する代替性又は非代替性トークンを介して割り当てられる権利を通じて直接的又は間接的にウォレットを介して行使されてもよい。

ポリシー・エージェント・モジュール１２２は、トークンの挙動を統制するポリシーを公表する権限を有するパーティのシステムに関連付けられる。トークン所有者は、公表されたポリシーを指定して、トークンに対して又はトークンを通じて実施される具体的なアクションを統制してもよい。ポリシー施行の詳細は、Ｃｏｍｐｌｉａｎｃｅ Ａｗａｒｅ Ｔｏｋｅｎの開示において、開示される。

検証エージェント・モジュール１２４は、属性、つまりシステムにおけるオブジェクトの特性又は性質を作成するパーティのシステムに関連付けられる。検証エージェントは、オブジェクトに関する価値を属性付けるために証明する能力を有する。例えば、法律事務所は、規制ポリシー施行の目的で、ファンド資産が投資会社法（１９４０Ａｃｔ）ファンドである検証エージェントとして機能することができる。

クラス・エージェント・モジュール１２６は、資産クラス・トークンに対する制御を行使するパーティのシステムに関連付けられる。この制御を使用して、クラス・エージェントは、クラスに関するすべての資産トークンに適用される属性及びインターフェースを選択することができる。

認証エージェント・モジュール１２８は、コントラクト開発者によって公表されるスマート・コントラクト・コードが説明されるようなファンクションを実施すること、セキュアであること、及び欠陥がないことを認証するパーティのシステムに関連付けられる。

コントラクト開発者モジュール１３０は、資産クラスに関するファンクションを実施するために資産トークンによって使用されるスマート・コントラクト・コードを開発するパーティのシステムに関連付けられる。これらのファンクションは、認証エージェントによって認証されると、クラス・エージェントによって追加され、アップグレードされ、又は除去されてもよい。

システム開発者モジュール１３２は、資産レジストリ・モジュール１０４又はコントラクト・ウォレット・モジュール１１０などのシステムのコア要素に更新を公表するように認可されたパーティのシステムに関連付けられる。

図１に図示されるモジュールは、単一の処理ユニット又は複数の処理ユニット内部に実装することが可能であり、モジュールのうちの１つ又は複数は他のモジュールから離れて実装してもよいことを諒解されたい。別のモジュールによって提供される機能性の説明は、説明を目的としたものであり、限定的であることを意図されていないが、モジュールのいずれも説明されるものより多い機能性、又は少ない機能性を提供してもよいからである。例えば、モジュールのうちの１つ又は複数は、取り除いてもよく、その機能性の一部又はすべては、モジュールのうちの他のものによって提供されてもよい。

図２は、開示される実装形態による、トークン・データ・レコード（トークン及び関連データ構造）２００の概略表現である。資産レジストリ１０４は、例えば、Ｅｔｈｅｒｅｕｍ Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔ（ＥＲＣ７２１）標準インターフェース（又は他の分散台帳で等価なもの）を実装して、非代替性トークンの発行を可能にすることができる。（例えば、ｈｔｔｐｓ：／／ｇｉｔｈｕｂ．ｃｏｍ／ｅｔｈｅｒｅｕｍ／ＥＩＰｓ／ｂｌｏｂ／ｍａｓｔｅｒ／ＥＩＰＳ／ｅｉｐ－７２１．ｍｄを参照）。追加的に、資産レジストリ１０４は、分散台帳などの非中央集権化された環境における資産管理用のファンクションを容易にする、本明細書で説明される新規なインターフェースを実装する。ファンクションには、資産バリュエーション・ファンクション２０２、所有権移転ファンクション２０４、及びデータ管理ファンクション２０６を含むことができる。以降で詳細に説明される、これらのインターフェース及び関連するデータ構造は、再帰的である可能性がある構造において、複合トークン、つまり他のトークンを含む又は他のトークンにリンクされるトークンの作成を可能にする。この新規な構造は、以降で非常に詳細に説明され、非中央集権化されたコンピュータ・アーキテクチャ上での、ファンドの実装形態、他の資産を含む複合資産を可能にする。

ＥＲＣ－７２１のトークン仕様と一致して、資産レジストリ・モジュール１０４は、非代替性トークンの発行を容易にし、各トークンは一意な資産を表現している。発行されたトークンごとに、資産レジストリ・モジュール１０４は、資産トークンの一意な識別子、資産クラス・レジストリ・モジュール１０６からの資産クラス、資産名称及び説明、トークンのウォレット２１０のアドレス（以降で説明する）、並びに資産に望まれるような他のデータなど、データ２０８を記録する。資産レジストリ・モジュール１０４によって記憶されるトークン・データ・レコード２００は、非代替性トークンを定義する。トークンには、米国特許出願公開第２０１９０１６４１５１（Ａ１）号において開示された方法を用いて追加的な属性及び価値が割り振られてもよい。デジタル・トークンは、ＩＡｓｓｅｔインターフェース・モジュール１０２のＩＡｓｓｅｔインターフェースを実装することができ、以降で説明するやり方で非中央集権化されたコンピューティング・プラットフォーム上で資産管理を容易にするファンクション２０２、２０４、及び２０６など、ファンクションのセットを公開する。データ構造２００を用いて、任意の価値の資産を「トークン化」することができる。つまり、資産の所有権を反映し、ファンド運用などのスケーラブルな運用をサポートするために必要とされるサポート用本質的な資産管理ファンクションに連結される、分散台帳上の一意なレコードとして発行することができる。以降で詳細に説明されるように、ＩＡｓｓｅｔインターフェース・モジュール１０２は、資産が次のことをできるようにする具体的なファンクションをサポートする：一貫性のあるデータ及びバリュエーション情報を提示すること；ファンド及び他の資産管理構造に参加すること；資産特有ロジックを実装すること；及び／又はネイティブな資産管理機能で作成されたのではない価値証書を表現する他のトークンをカプセル化すること。

上述のように、また図２及び図３で示されるように、トークン２００は暗号ウォレット２１０に関連付けられる。開示される実装形態にはインターフェース仕様及びデータ構造が含まれ、スマート・コントラクト及び／又は別個のトークンが、暗号ウォレットに関連付けられるようにする、つまり暗号ウォレットを所有できるようにする。この新規な構造は、トークンが他のトークンを所有すること、及び他のトークンをその所有権に追加又はそれから除去することを可能にして、他のトークン又はエンティティに対応するウォレット２１１と対話することにより、他のエンティティと取引を行うことを可能にする。他のトークンを含んでいる対応するウォレットを所有することにより、トークン・イン・トークン構造を表現しているトークンは、本明細書では「複合トークン」と称する。

資産レジストリ中の非代替性トークンには、資産レジストリ１０４によって、ＩＡｓｓｅｔＷａｌｌｅｔＦａｃｔｏｒｙインターフェースを用いてＩＡｓｓｅｔＲｅｇｉｓｔｒｙ．ＩｓｓｕｅＡｓｓｅｔファンクションを実装することにより、発行時にウォレット２１０が割り振られる（図２）（コード実例についてはＡｐｐｅｎｄｉｘ参照）。このインターフェースは、コントラクト・レジストリ１０８に記憶されるＩＣｏｎｔｒａｃｔＷａｌｌｅｔインターフェースを実装するスマート・コントラクトを、一意なトークンＩＤと関連付けて発行する。このインターフェースを実装するコードの実例は、Ａｐｐｅｎｄｉｘで見ることができる。

ウォレット・コントラクトのインターフェースは、ＩＡｓｓｅｔＷａｌｌｅｔラッパー、つまり、ＩＡｓｓｅｔトークンの所有者又はスマート・コントラクト・ロジックで実装されるような他のパーミッション構造体による使用のため、ＡｓｓｅｔＲｅｇｉｓｔｒｙスマート・コントラクトを介して利用可能な、付録で公表されるＩＡｓｓｅｔＷａｌｌｅｔインターフェース仕様に準拠するファンクションのセットを用いて実行することができる。署名者が、資産レジストリ１０４によって指定されるように、ファンクションを実行するよう認可されていない場合、例えばスマート・コントラクト・ロジックとして実装される場合、提案される動作（例えば、「トークンを送る」）は、許可されず、よって発生しない。ＩＡｓｓｅｔＷａｌｌｅｔは、付加されるコードのＧｅｔＷａｌｌｅｔファンクションを介してそのウォレット・アドレスを公開する。このアドレスは、分散台帳上のあらゆるウォレットと同じ方法で、取引の発信元又は目的地として使用することができる。

この構造では、ウォレットをトークンにリンクすることにより、以下のような有用な効果がもたらされる：トークンに対応する資産に代わって、実施されるアクションの完全なトレーサビリティ；ある戦略に基づいて売買する資産管理スマート・コントラクトを通じてアクションを自動化する能力；あるエンティティと取引しているかのように、資産のウォレットとの取引を行う能力；資産ウォレットを介する運用を含め資産運用にロバストなポリシーを挿入する能力（米国特許出願公開第２０１９０１６４１５１（Ａ１）号で開示されるようなもの）。

図３に示されるように、トークンに対応するウォレットが他のトークンを所有することが可能な「トークン・イン・トークン」構造により、トークン化された複合資産の作成が可能となる。複合資産の１タイプは、ファンド、他の資産を含む金融資産である。ＩＡｓｓｅｔＭａｎａｇｅｍｅｎｔインターフェースをサポートするＩＡｓｓｅｔトークンとして発行されると、トークンは資産管理取引をサポートして、ファンド・マネージャによって手動で、又は分散台帳上のスマート・コントラクトベースのアルゴリズムを介して自動的に、ファンド管理戦略の実行を可能にする。このモデルを使用して、複合資産は、トークン化され、暗号通貨、他の資産トークン（単純、又は複合）、又はトークン化された資産の株などの資産を含むこと、追加すること、又は除去することが可能である。

さらには、トークン・イン・トークン構造は、ＩＡｓｓｅｔトークン・インターフェースで資産管理をサポートしていないサード・パーティのトークンを「ラップ」するために使用して、個々の資産としてファンド構造内で管理できるようにすることができる。サード・パーティのトークンをラップすることは、ＩＡｓｓｅｔトークンのウォレットへの単純な移転を通じて達成することができる。これにより、あらゆるトークン又はスマート・コントラクトを資産としてラップ及び処理できるようにして、自動化された資産管理及びファンド運用のための一貫した構造を公開する。これらの技術的な要素が整うと、複雑な自己処理ファンドを迅速に開始することが可能である。例えば、ＥＴＦ構造では、個々の資産を表現する１つ又は複数の非代替性トークンを、ＩＡｓｓｅｔＲｅｇｉｓｔｒｙ．ＩｓｓｕｅＡｓｓｅｔファンクションを使用して資産レジストリ・モジュール１０４を介して発行することができる（コード実例についてはＡｐｐｅｎｄｉｘ参照）。それぞれのトークンは、ＩＡｓｓｅｔインターフェースを実装し、これはＩＡｓｓｅｔＴｒａｎｓｆｅｒａｂｌｅインターフェースを介して実装された所有権移転ファンクションを用いて基本的なＥＲＣ７２１仕様を拡張して、資産管理をサポートし、透明性を向上させ、マーケットプレイスでの資産の購入と販売をサポートする。

図４は、資産所有権の移転ファンクション（図２の２０４として示される）の処理フロー４００を概略的に示している。上述のように、トークンは、ＥＲＣ７２１標準インターフェースを実装することができ、このインターフェースは、従来的な所有権及びＥＲＣ７２１仕様で定義される移転ファンクションを含む。トークンはまた、米国特許出願公開第２０１９０１６４１５１（Ａ１）号で開示されるコンプライアンス意識フレームワークを実装することもできる。本明細書で開示される実装形態は、このフレームワークを、体系立った資産の購入、販売、及びリンクを可能にするためのファンクションで拡張する。

図４の４０２に示されるように、トークンの売り注文は、パラメータ（ｕｉｎｔ ｔｏｋｅｎｉｄ．ｕｎｉｔ ｐｕｒｃｈａｓｅ Ｔｏｋｅｎｉｄ，ｆｌｏａｔ ｐｒｉｃｅ，ｕｉｎｔ ｅｘｐｉｒｅｓ，ａｄｄｒｅｓｓ ｂｕｙｅｒ，ｂｙｔｅｓ ｄａｔａ）ｅｘｔｅｒｎａｌ ｒｅｔｕｒｎｓ（ｕｉｎｔ ｏｒｄｅｒＩｄ）を含むデータ構造に対して演算するｃｒｅａｔｅＳｅｌｌＯｒｄｅｒファンクションを用いて作成することができる。ｃａｎｃｅｌＳｅｌｌＯｒｄｅｒファンクションは、ｏｒｄｅｒ ｉｄに対して演算し、Ｂｏｏｌｅａｎを返す。ｃａｎｃｅｌＳｅｌｌＯｒｄｅｒファンクションがＦＡＬＳＥを返すと仮定すると、トークンの買い手は売り注文を受け入れ、ａｃｃｅｐｔＳｅｌｌＯｒｄｅｒファンクションが実行される。４０４に示されるように、ｃａｎｃｅｌＳｅｌｌＯｒｄｅｒファンクションがＴＲＵＥを返す場合、つまり売り注文がキャンセルされた場合、注文処理は、販売で終了する。

４０６に示されるように、トークン購入では、ｃｒｅａｔｅＰｕｒｃｈａｓｅＯｒｄｅｒファンクションがパラメータを含む（ｕｉｎｔ ｔｏｋｅｎｉｄ，ｕｎｉｔ ｐｕｒｃｌｌａｓｅＴｏｋｅｎｉｄ，ｆｌｏａｔ ｐｒｉｃｅ，ｕｎｉｔ ｅｘｐｉｒｅｓ，ｂｙｔｅｓ ｄａｔａ）データ構造に対して実行され、注文識別情報を（ｕｉｎｔ ｏｒｄｅｒｉｄ）の形式の注文ＩＤとして返す。ｃａｎｃｅｌＰｕｒｃｈａｓｅＯｒｄｅｒファンクションは、パラメータ（ｏｒｄｅｒｔｄ）に対して実行され、Ｂｏｏｌｅａｎを返す。戻り値がＦＡＬＳＥである場合、購入は、パラメータ（ｏｒｄｅｒｉｄ）に対するａｃｃｅｐｔＰｕｒｃｈａｓｅＯｒｄｅｒファンクションの実行によって受け入れることができ、購入がクリアされる。代替的に、４０８に示されるように、購入はパラメータ（ｏｒｄｅｒｉｄ）に対してｒｅｊｅｃｔＰｕｒｃｈａｓｅＯｒｄｅｒファンクションを実行することによって拒否される。代替的な手法として、売り注文は、ｐｕｒｃｈａｓｅＦｒｏｍファンクションをパラメータ（ａｄｄｒｅｓｓ＿ｉｒｏｍ，ａｄｄｒｅｓｓ＿ｔｏ，ｕｉｎｔ２５６＿ｔｏｋｅｎＩｄ，ｕｉｎｔ＿ｏｒｄｅｒＩｄ，ｂｙｔｅｓ ｄａｔａ）を含むデータ構造に対して実行することによって、ペイロード中にｏｒｄｅｒＩＤを含む資産レジストリ・ウォレットへの支払いを行うことによって実行されてもよい。

上述のように、トークン同士の取引は、個々のトークンに関連付けられるウォレットのおかげで達成される。トークンのウォレット・アドレスは、例えばＡｐｐｅｎｄｉｘにあるコードを実行することによって実装することが可能なＩＡｓｓｅｔＷａｌｌｅｔ．ＧｅｔＷａｌｌｅｔインターフェースを介して取得されてもよい。配分ロジックは、資産によって内部的に、又はインターフェースを使用して外部的に開始されてもよい。

金融市場における透明性という重要な態様は、投資家及び投資予定者が資産のメタデータ、文書、及びサポート・データ・フィードを見る能力である。この情報は、投資家に公正な市場価格に対する彼ら自身のセンスをみがくための手段を与え、同様に、市場における価格を評価する責任をタスクとされたアセット・マネージャなどの仲介のパフォーマンスを評価するメカニズムを提供する。従来的に、そのような情報は、静的なやり方で照合されなければならず、したがってデータの時間ベースのレポーティングは先行技術のシステムでは実用的ではない。開示される実装形態は、資産デュー・ディリジェンス用の包括的なデータ構造を含み、スケーラブルな透明性；ＲＭＢＳポートフォリオに欠落しているファンクション及び先行技術の他の複雑な資産を提供する。

透明性は、資産の性質又は属性を、作成する、維持する、及び検査する能力を必要とする。資産のタイプは広範にわたるため、それに従って資産の属性はさらに幅広く変化する。広範囲な資産の全体に対するデータ分析をサポートするべく、あらゆる認可されたパーティによって証明された通りにあらゆる資産のあらゆる性質を管理するために、一貫性のあるフレームワークが必要とされる。実装形態は、資産の性質を管理する基本的なメカニズムとして、属性管理（ＥＲＣ１６１６）仕様（ｈｔｔｐｓ：／／ｅｉｐｓ．ｅｔｈｅｒｅｕｍ．ｏｒｇ／ＥＩＰＳ／ｅｉｐ－１６１６）を含む。開示される実装形態はまた、この仕様をＣｏｍｐｌｉａｎｃｅ Ａｗａｒｅ Ｔｏｋｅｎフレームワーク（米国特許出願公開第２０１９０１６４１５１（Ａ１）参照）を介して、これらの属性に基づいてスケーラブルな信用証明及びポリシー施行を含むよう拡張することが可能である。

追加的に、資産デュー・ディリジェンスは、しばしば文書及びデータ管理を必要とする。分散台帳は、文書化及びデータ並びにこのデータにアクセスするためのアクセス可能なフレームワークをサポートするために不変な記録を提供することができるという点で、文書管理に具体的な利点を提供する。実装形態は、文書管理（ＥＲＣ１６４３）仕様（ｈｔｔｐｓ：／／ｇｉｔｈｕｂ．ｃｏｍ／ｅｔｈｅｒｅｕｍ／ＥＩＰｓ／ｉｓｓｕｅｓ／１６４３）を含む。開示される実装形態はまた、非代替性トークンを使用してサポート・データのスキーマ及び他の特性を説明する非代替性トークンを介して、サポート・データセットをトークン化するためのメカニズムを含む。この仕様は、配分制御及び機密データの監査を実現するための認可トークンの使用を含む、高度なデータ承認技法をサポートする。ポリシーベースのデータ・アクセス及び管理は、米国特許出願公開第２０１９０１６４１５１（Ａ１）号によって示される、非中央集権化されたアクセス制御によって示される技法を用いて達成することができる。

アセット・マネージャの１つの最も重要な信託責任は、管理する資産のバリュエーションを評価して公表することである。このことは、マネージャに利用可能な情報に基づいて、アセット・マネージャの価値の理解の記録を投資家に提供するが、この情報は、ほとんどの資産では、評価の時点で投資家によって入手可能な情報を上回っている。図５は、開示される実装形態の資産バリュエーション・ファンクションについて処理フロー５００及び関連するデータ構造の実例を図示している。これらのファンクションは、資産バリュエーションの公表及びアクセスのための、一貫性のあるメカニズムを提供する。バリュエーション用の共通インターフェースは、分析ツールの統合を簡略化する。これはまた、異種資産のバリュエーションを容易にし、多様化したファンドの形成を促進する。上述のように、資産トークンはバリュエーション・インターフェースを公開して、投資家が資産価値の現在の評価を見ることを可能にする。ある範囲の既知の会計技法を使用して資産価値を評価することができる。使用される技法は、資産のｖａｌｕｅＴｙｐｅ属性フィールドで指定される。資産トークンは、価値評価をサポートするために、内部ロジックを有することができる。資産バリュエーション・ファンクションは、Ａｐｐｅｎｄｉｘにあるコード実例を実行することによって、実装することができる。

図５に示されるように、リクエスト側（投資家など）は、トークン１に対してｇｅｔＶａｌｕａｔｉｏｎリクエストを行うことができ、トークン１のバリュエーションはトークン１によって返される。リクエストには、適用されるバリュエーション・モデルが含まれる可能性がある。必要であれば、トークン１によってどのバリュエーション・モデルがサポートされるかを確かめるために、ｇｅｔＳｕｐｐｏｒｔｅｄＶａｌｕａｔｉｏｎＭｏｄｅｌリクエストを行うことができる。資産バリュエーションを生成するためのロジックは、実装形態及び資産クラスによって変わってもよい。

一実装形態では、バリュエーションは証明として、つまり検証済パーティによって完全な帰属が割り振られた属性値として、資産所有者、マネージャ、又は他の認可されたパーティによって公表される可能性がある。他の実装形態では、バリュエーション・データは、資産 レジストリ・モジュール１０４（図１）のスマート・コントラクト・コードによって、又は資産クラス・レジストリ・モジュール１０６（図１）のクラスに割り振られた通りに生成される。このロジックは、価値を評価するために資産のリアルタイム属性、為替価格などの外部のデータのソースに到達するための「オラクル」、又は他のソースを使用することができる。例えば、ローンを表現する資産トークンでは、ＰＡＲバリュエーションは、ローン・トークンの属性（図１の属性レジストリ・モジュール１１２で見つかる）、ローンの未払い元本である。ローンによって返済が処理されると、この属性に割り振られた価値は、ローン処理スマート・コントラクトによって変化し、属性は異なる値となる。関連する値をｓｅｔ及びｇｅｔするための、属性レジストリ・モジュール１１２の実装形態及びメカニズムに関する詳細は、米国特許出願公開第２０１９０１６４１５１（Ａ１）号に開示されている。

一実装形態では、バリュエーション・タイプ「ＰＡＲ」へのリクエスト（ＧｅｔＶａｌｕａｔｉｏｎ）は、ＡｓｓｅｔＲｅｇｉｓｔｒｙスマート・コントラクトの実装形態を介して、属性レジストリ・モジュール１１２（図１）の「ＰＡＲ」Ｖａｕｌｅ属性を指すように構成される。この属性は、現在の元本、つまりローンの未払い残高を含み、これがリクエストに応答して返される。いくつかのバリュエーション結果は、バリュエーションを生成するためにデータの複雑なリアルタイム分析を必要とする場合がある。バリュエーションを取得するための別個のメカニズムを図示するために、ローンの純資産価値（ＮＡＶ：Ｎｅｔ Ａｓｓｅｔ Ｖａｌｕｅ）計算が、割引キャッシュ・フロー及びローン受け取り側の支払い挙動に基づいて決定されてもよい。具体的には、バリュエーション・タイプ「ＮＡＶ」に対するバリュエーション・リクエストは、コントラクト・レジストリ・モジュール１０８（図１）を介してＡｔｔｒｉｂｕｔｅＣｌａｓｓ「Ｌｏａｎ」に割り振られたスマート・コントラクト・コードを利用して、現在の利率、ローンの利率、及び資産ウォレットで観察することができるキャッシュ・フローに基づく借主の支払い履歴に基づいてローンの純現在価値を計算してもよい。

別の実例として、「ＭＡＲＫＥＴ」値は、分散台帳の外部のソースからデータを取得するために一般的に使用される方法である、オラクルを活用してもよい。別個に開示されるように、属性レジストリ・モジュール１１２は、最新の価値、この場合では資産の現在の為替価格を取得するための命令を含む。明瞭さのためにいくつかの実例を与えたが、実装形態はそれらに限定されない。しかしながら、資産ごとに構成され得るこのデータを取得するための方法を割り振るための手段は、「自己レポーティング資産」、つまり自身のデータ構造内に自身のバリュエーションを計算して公表する手段を含む資産を提供するための新規なメカニズムを提供する。開示される方法は、監査又はレポーティング・システムの、バリュエーション・データのソースの具体的な実装形態への依存性を解消する。これは、多くの異なるバリュエーション・データのソースを含むファンドなど、複雑な資産のバリュエーションを生成するために必要とされる、複雑なシステム統合を解消する。開示される技法なしには、投資家はこのデータを取得するための手段を持たないことが多い。透明性が欠落することの結果として、２００８年の世界的な金融危機で実証されたような破滅的な影響を及ぼす可能性がある。

リクエストのデータ構造が、５０２に示される。重要なことに、複合資産の場合では、トークン１は、子トークンを所有することができるか、及び又は上述のやり方で別のトークンの「ラッパー」として機能することができる。そのような場合、トークン１は、リクエスト側への応答に先立つバリュエーションと類似のやり方で、すべてのそのようなトークン、図５ではトークン２をクエリする必要がある。５０４で示されるように、トークンが発行されると、トークン発行者ファンクションを通じてバリュエーションをセットすることが可能である。

開示される実装形態はバリュエーション用に共通のインターフェースを公開しているが、上述のように、サポートされる範囲の資産タイプのバリュエーションを計算するために異なる技法を使用することが可能である。ある資産タイプのバリュエーションを計算するための一意なスマート・コントラクト・ロジックは、（ｈｔｔｐｓ：／／ｈａｃｋｅｒｎｏｏｎ．ｃｏｍ／ｈｏｗ－ｔｏ－ｍａｋｅ－ｓｍａｒｔ－ｃｏｎｔｒａｃｔｓ－ｕｐｇｒａｄａｂｌｅ－２６１２ｅ７７１ｄ５ａ２）で開示されるような既知のｐｒｏｘｙ技法を介して参照することができる。例えば、多くの資産はＰＡＲ価格、つまりその額面をサポートしている。ほとんどの管理資産は、市場価格、流動性、割引キャッシュ・フロー、又はその内容の他の評価値に基づいて計算されるＮＡＶを有している。資産が定期的に売買される場合、この資産は市場価格と価値を有する。ＰＡＲ、ＮＡＶ及び市場価値は、同じ資産でも異なる場合がある。例えば、ローンは、未払い元本に基づいたＰＡＲ価格、割引キャッシュ・フロー及び債務不履行の確率に基づいたＮＡＶ、並びに資産が容易に売買される場合又は最近購入された場合は市場価値を有する。これらの価値の違いは、資産パフォーマンス、格付けエンティティ、又はそのアセット・マネージャの価値評価における信頼に対する変化する市場認識に対する洞察を与えることができる。

資産バリュエーションは、一度だけ、定期的に、又は継続してほぼリアルタイムに評価されてもよい。データ・フォーマットは、価値評価がどれくらい古いか、及びどれくらいの間隔でそれが有効なままであると期待されるかを知るためのビューワ（例えば、及び所有者又は他の市場関係者）情報を提供する。追加的に、仕様は、バリュエーション履歴の標準化フィードへのリンクを提供することができる。これは、レビュワーに資産の履歴的なパフォーマンスを見るツールを与える。リンクは、データへの直接的なアクセスの代わりに設けられるが、履歴的な分析に必要な記憶、探索、及びインデックス付け用のツールは資産トークンが記憶されるツール（本実装形態では分散台帳）とは異なる可能性があるためである。

開示される実装形態はデータ通信を改善して、それによりマネージャに利用可能な情報と投資家に利用可能な情報とのギャップを埋めることができるが、データのフローは、図１のポリシー・エンジン１１８においてアーキテクチャによって、例えば設計による決定ギャップを作成するよう制御することができる。例えば、特定の情報に関するデータ・フローの限度は、所望の限度又は投資家の利益になる限度であってもよい。例えば、アセット・マネージャは、「フロント・ランニング」（経済上の利点を得るために、大規模な非公表注文の直前に、ブローカ又はトレーダーが売買を行う慣行）を防止するために、又はその他の方法で投資パフォーマンス若しくは投資技法を保護するために、一般提供からの特定情報を保留したいと思う場合がある。投資家は、パフォーマンスと透明性との間でトレードオフを行うよう選ぶ場合があり、アセット・マネージャは機密性の必要に対してバランスの取れた市場需要に基づく開示を余儀なくされる。

図１に関して上述したように、資産がいったんＩＡｓｓｅｔモジュール１０２のＩＡｓｓｅｔＴｏｋｅｎインターフェースを使用してトークン化されると、ＥＴＦ自己レポーティング・ファンドなどのファンドを開発する際の次のステップは、開示される実装形態によると、ＩＡｓｓｅｔモジュール１０２のＩＡｓｓｅｔＦｕｎｄインターフェース構造を使用するファンド・トークンの発行である。この構造は、ＩＡｓｓｅｔＴｏｋｅｎ構造及びファンクションをＩＡｓｓｅｔＭａｎａｇｅｍｅｎｔインターフェースで拡張する。ファンド・トークンは、資産クラス・レジストリ・モジュール１０６のＩＡｓｓｅｔＲｅｇｉｓｔｒｙインターフェースを介して発行されるが（他のトークン同様）、資産クラス・レジストリ・モジュール１０６からの、このクラス用の値を割り振ることによって、「Ｆｕｎｄ」に等しいタイプ・パラメータが割り振られる。もちろん、ファンドは他の資産を含むことができる資産である。個々の資産に利用可能な同一のファンクションがファンドに適用される。しかしながら、ファンドは、ファンド内に含まれる資産を管理するために必要なファンクションを提供することによって、ＩＡｓｓｅｔトークンの基本的なロジックを拡張する。

図６に示されるように、開示される実装形態のファンド資産トークン６００は、図２の資産トークン２００に類似している。しかしながら、ファンド資産管理トークンは、資産管理ファンクション２１２を含む。資産管理ファンクションは、資産レジストリ・モジュール１０２のＩＡｓｓｅｔＭａｎａｇｅｍｅｎｔインターフェースを介して実装され、処理スマート・コントラクトが割り振られ、トークン・ウォレットを利用するため、すべての取引は分散台帳に記録することができ、不変である。このことは記録管理、監査、及びレポーティングを簡略するための透明性を与える。資産管理インターフェースは、一貫性のある取引インフラストラクチャを提供して、それぞれの資産クラス又はファンド管理戦略に特有のロジックの開発を合理化している。このことは、中心部のトークン構造及びインターフェース・フットプリントを変更することなく置換、拡張、又はアップグレード可能な内部ロジックにより実行される新しい資産タイプのための管理戦略のデプロイメントを容易にする。さらには、この実装形態は、共通の資産管理ファンクションを介して広範な資産タイプをサポートし、本実装形態の特性である。

より具体的には、ファンド・トークン６００のファンド・トークン仕様は、基本的な資産インターフェースを拡張して、認可されたエンティティがＩＦｕｎｄＭａｎａｇｅｍｅｎｔ．ＧｅｔＡｓｓｅｔｓインターフェースを使用してファンド内のすべての資産を列挙できるようにする。ファンド内の資産を列挙することにより、それぞれがＩＡｓｓｅｔインターフェースをサポートして、ビューワが含まれる資産の利用可能な情報を掘り下げることが可能となる。例えば、次のファンド管理ファンクション及び関連データ構造を、サポートすることが可能である。
・ａｄｄＡｓｓｅｔＲｅｑｕｅｓｔ（ｕｉｎｔ ｔｏｋｅｎｅｄ，ｕｉｎｔ ｐｕｒｃｈａｓｅＴｏｋｅｎｉｄ，ｆｌｏａｔ ｐｒｉｃｅ，ｕｉｎｔ ｅｘｐｉｒｅｓ，ｂｙｔｅｓ ｄａｔａ）ｅｘｔｅｒｎａｌ ｒｅｔｕｒｎｓ（ｕｉｎｔｏｒｄｅｒｉｄ）；
・ｃａｎｃｅｌＡｄｄＡｓｓｅｔＲｅｑｕｅｓｔ（ｏｒｄｅｒｅｄ）ｅｘｔｅｒｎａｌ ｒｅｔｕｒｎｓ（ｂｏｏｌ）；
・ｒｅｍｏｖｅＡｓｓｅｔＲｅｑｕｅｓｔ（ｕｉｎｔ ｔｏｋｅｎｅｄ，ｕｉｎｔ ｐｕｒｃｈａｓｅＴｏｋｅｎｉｄ，ｆｌｏａｔ ｐｒｉｃｅ，ｕｉｎｔｅｘｐｉｒｅｓ，ａｄｄｒｅｓｓ ｂｕｙｅｒ，ｂｙｔｅｓ ｄａｔｅ）ｅｘｔｅｒｎａｌ ｒｅｔｕｒｎｓ（ｕｉｎｔ ｏｒｄｅｒｅｄ）；
・ｃａｎｃｅｌＲｅｍｏｖｅＡｓｓｔＲｅｑｕｅｓｔ（ｏｒｄｅｒｅｄ）ｅｘｔｅｒｎａｌ ｒｅｔｕｒｎｓ（ｂｏｏｌ）；
・ｇｅｔＡｓｓｅｔｓ（）ｅｘｔｅｒｎａｌ ｒｅｔｕｒｎ（ｕｉｎｔ［］）；／／付加された非代替性トークンのアドレスのアレイを返す
・ｅｖｅｎｔ ＡｓｓｅｔＡｄｄｅｄ（ｕｉｎｔ ｔｏｋｅｎｅｄ）；
・ｅｖｅｎｔ ＡｓｓｅｔＲｅｍｏｖｅｄ（ｕｉｎｔ ｔｏｋｅｎｅｄ）

それぞれのファンクションの実例は、Ａｐｐｅｎｄｉｘに含まれている。ファンド・トークンが発行されると、ファンド作成処理における次のステップは、資産をファンドへ移転することである可能性がある。ファンドは、ゼロから多くの資産まで含む可能性があることに留意されたい。資産は、トークンの資産管理ファンクション、ＡｄｄＡｓｓｅｔＲｅｑｕｅｓｔ及びＲｅｍｏｖｅＡｓｓｅｔＲｅｑｕｅｓｔを使用して購入される又はファンドから清算される。あらゆるトークン取引と同様、資産管理アクションは分散台帳に記録される。これらのファンクションは資産レジストリによるインターフェースとして公開され、ＩＡｓｓｅｔトークン・ウォレット及び資産所有権移転ファンクションを利用して、図２のトークン２００に関して上述したのと類似のやり方で資産取引を実行する。

非代替性ファンド・トークン６００は、売買及び他の取引を容易にするために、ＩＡｓｓｅｔＭａｎａｇｅｍｅｎｔＦｕｎｇｉｂｌｅインターフェースを使用してトークン２００などの代替性トークンに連結する（つまり、代替性トークンで「ラップ」する）ことができる。あらゆる資産トークンは、ＩＡｓｓｅｔＭａｎａｇｅｍｅｎｔＦｕｎｇｉｂｌｅインターフェースを実装する代替性トークンでラップして、資産の部分所有権を容易にし、株主への配当配分、株主投票、コーポレート・コミュニケーションなどの非代替性トークン用に構築されたコーポレート・ファンクション用のロジックを再使用することができる。ＩＡｓｓｅｔＭａｎａｇｅｍｅｎｔＦｕｎｇｉｂｌｅ構造を実装するトークンは、ＥＲＣ２０標準（イーサリアム代替性トークン）を拡張する新しいスマート・コントラクト・インターフェース（ＡｄｄＡｓｓｅｔＲｅｑｕｅｓｔ、ＲｅｍｏｖｅＡｓｓｅｔＲｅｑｕｅｓｔ）を含む。これらのインターフェースにより、代替性トークン発行者が、ＩＡｓｓｅｔＭａｎａｇｅｍｅｎｔＦｕｎｇｉｂｌｅインターフェース内の定義されたファンクションを使用して非代替性資産トークンを移転することによって、１つ（且つ、１つだけ）の資産トークンを代替性トークン・シェルに／から追加又は除去できるようになる。

代替性トークンの実装形態はまた、インターフェース（ＩＡｓｓｅｔＭａｎａｇｅｍｅｎｔＦｕｎｇｉｂｌｅ．ＧｅｔＡｓｓｅｔ）を含み、認可されたパーティが代替性トークンによって表現される株式の基礎となる資産を検査することを可能にしている。非代替性トークンによって公開される、バリュエーション・ファンクションは、代替性トークンに連結され、株主（代替性トークンの所有者）が基礎となる資産のうち自身の所有割合を容易に計算することを可能にしている。例えば、基礎となる資産のＮＡＶが１，０００，０００ドルであり、ウォレットがその資産の流通における全株式１０００のうち１００（１０％）を保有している場合、１００株式を表現するそのウォレット中の代替性トークンの全ＮＡＶは、１００，０００ドルである。

代替性トークンを、資産及びその管理に特有な非代替性トークンに取り込まれるロジックから分離することによって、実装形態は最大の再使用を容易にして、資産特有コードの開発及び検証を簡略化する。追加的に、この手法は資産構造を保持して、合併、又は税務上の理由、ガバナンスの理由若しくは責任の理由から株式獲得の代わりに資産獲得が所望される獲得手法を容易にする。資産獲得は金融では一般的な技法であり、データ・モデル及び開示される実装形態のアーキテクチャがない場合、実用的なタスクにはならない。リンクされたトークン手法は、為替売買ファンドへの、及び為替売買ファンドからの資産の移転を容易にして、親ファンドから切り離された時の資産の流動性を可能にしているが、証券化のためにファンドによって購入されると便利な管理が可能となる。

図７は、例えばファンド・トークンによって表現されるファンドの部分所有権を可能にする取引のために非代替性資産トークンを代替性トークンでラッピングするためのデータ・モデル７００の概略図である。「部分所有権」とは、代替性の資産が細かく分割できるために、２者以上の資産の所有者が存在できるような状況を指す。７０２に示されるように、基本的なトークンのタイプは「ウォレット」、「代替性の株式」、及び「非代替性の資産」である。７０４で示されるように、トークンに関連付けられるウォレットは、例えば図１に関して上述したメカニズムを通じて代替性の株式及び／又は非代替性の資産を表現する他のトークンを所有することができる。これにより、非代替性トークンのラッパーの配当配分及びコーポレート・ガバナンス・ファンクションを利用することができるため、資産非代替性トークンの構造及びスマート・コントラクト・コードが簡略化される。ファンド内の株式は、代替性トークンによって表現され、７０６に示されるように１つ若しくは複数のウォレットによって、又は資産によって所有することができる。代替性トークンにリンクされるスマート・コントラクトは、７０８に示されるように、ファンド内の代替性資産についての所有権及び管理ファンクションを公開する。ファンクションは、Ａｐｐｅｎｄｉｘにも示されているが、以下を含むことができる：
・ａｄｄＡｓｓｅｔＲｅｑｕｅｓｔ（ｕｉｎｔ ｔｏｋｅｎＩｄ，ｕｉｎｔ ｐｕｒｃｈａｓｅＴｏｋｅｎＩｄ，ｆｌｏａｔ ｐｒｉｃｅ，ｕｉｎｔ ｅｘｐｉｒｅｓ，ｂｙｔｅｓ ｄａｔａ）ｅｘｔｅｒｎａｌ ｒｅｔｕｒｎｓ（ｕｉｎｔ ｏｒｄｅｒｉｄ）；
・ｃａｎｃｅｌＡｄｄＡｓｓｅｔＲｅｑｕｅｓｔ（ｏｒｄｅｒＩｄ）ｅｘｔｅｒｎａｌ ｒｅｔｕｒｎｓ（ｂｏｏｌ）；
・ｒｅｒｎｏｖｅＡｓｓｅｔＲｅｑｕｅｓｔ（ｕｉｎｔ ｔｏＫｅｎＩｄ，ｕｉｎｔ ｐｕｒｃｈａｓｅＴｏｋｅｎＩｄ，ｆｌｏａｔ ｐｒｉｃｅ，ｕｉｎｔ ｅｘｐｉｒｅｓ，ａｄｄｒｅｓｓ ｂｕｙｅｒ，ｂｙｔｅｓ ｄａｔａ）ｅｘｔｅｒｎａｌ ｒｅｔｕｒｎｓ（ｕｉｎｔ ｏｒｄｅｒ１ｄ）；
・ｃａｎｃｅｌＲｅｒｎｏｖｅＡｓｓｅｔＲｅｑｕｅｓｔ（ｏｒｄｅｒ１ｄ）ｅｘｔｅｒｎａｌ ｒｅｔｕｒｎｓ（ｂｏｏｌ）；
・ｇｅｔＡｓｓｅｔ（） ｅｘｔｅｒｎａｌ ｒｅｔｕｒｎ（ｕｉｎｔ）；／／付加された非代替性トークンのアドレスを返す
・ｅｖｅｎｔ ＡｓｓｅｔＡｄｄｅｄ（ｕｎｉｔ ｔｏｋｅｎＩｄ）；
・ｅｖｅｎｔ ＡｓｓｅｔＲｅｒｎｏｖｅｄ（ｕｎｒｔ ｔｏＫｅｎＩｄ）；

例えば、資産は、ローン返済が受け取られると、資産を所有するウォレットを支払う自己処理ローンであってもよい。このウォレットが代替性トークン・スマート・コントラクトによって所有されている場合、これらの売り上げは、代替性トークンの所有者に比例して配分されてもよい。親子トークン構造はまた、代替性トークンにおける確立された取引ロジック及び交換ファンクションの再使用を容易にしつつ、資産特有ファンクションにおける特殊化、この場合ではローン処理を可能にする。上述のように、ファンドは代替性トークン及びリンクされた管理スマート・コントラクトによって定義されるため、ファンドはゼロ（ヌル）資産を有することができる。

ＩＡｓｓｅｔＦｕｎｄトークンは、資産、他のファンドのための資産トークン、他の資産の代替性の株式、又はファンド資産の株式、のうちのいずれかを含んでもよいため、実装形態は、図８に示されるように資産のネスト化をサポートしており、図８はそのようなネスト化のためのデータ・モデルの概略的表現である。ネスト化は、ファンド・オブ・ファンド構造及び大規模なポートフォリオの多様化技法を容易にする。８０２に示されるように、トークン・ウォレットは、ファンド内の株式を表現する代替性トークンを所有することができ、このファンドは８０４に示されるように、非代替性の資産を所有する。さらには、８０４に示されるように、非代替性トークン（例えばファンドを表現する）、代替性トークン、及び他の資産（この実例では、暗号通貨ｅｔｈｅｒなど）が、非代替性トークンによって所有され得る。図１、図２、及び図６に関して上述したウォレット構造及びアーキテクチャは、この再帰的な所有権構造が非中央集権化されたシステムに関連して使用することができるデータ・モデルによって表現できるようにする。

ＩＡｓｓｅｔＦｕｎｄがＩＡｓｓｅｔ構造を拡張してＦｕｎｄ管理ファンクションを実装するのと同じ方法で、ＩＡｓｓｅｔ構造は他の資産タイプに対して拡張して、トークンの多型性を可能にすることができる。例えば、実装形態は、ＩＡｓｓｅｔＬｏａｎトークン、つまり図１の資産クラス・レジストリ・モジュール１０６からのクラス・タイプＬｏａｎを有するＩＡｓｓｅｔトークンを発行することができる。このクラスは、自己処理ローン、つまり、ＩＡｓｓｅｔウォレット及び割り振られたＰｒｏｃｅｓｓＷａｔｅｒｆａｌｌスマート・コントラクト・ロジックを介して内部的に支払いを処理するローンを実装することができる。支払い処理向けのカスタムのスマート・コントラクトは、それらの所有者によってＡｓｓｉｇｎＷａｔｅｒｆａｌｌＰｒｏｃｅｓｓインターフェースを用いてローンに割り振ることができる。継承を通じて導出クラスによってファンクションを置き換えられるようにするこの慣行は、オーバーローディングとして知られている。インターフェース構造を使用するオーバーローディングにより、同じファンド内で異なるローン処理戦略の実行が可能となる。

ＩＡｓｓｅｔ構造を継承することによって、ＩＡｓｓｅｔＬｏａｎトークンは、そのウォレットへの支払いをあらゆる受け入れ通貨で受け取り、そのあらゆる未払い元本への更新を含めて支払いを処理し、手数料を処理して、その売り上げを所有者に渡すことができる。すべての取引及び支払いは、台帳上で検査することができ、透明性及び資産バリュエーションに必要とされるデータを与える。ＩＡｓｓｅｔＦｕｎｄの資産管理ファンクションを使用して、ＩＡｓｓｅｔＬｏａｎトークンは、ファンド・トークンに付加されてもよい。ローン・トークンは、証券化されたファンドを作成するための、多くのＩＡｓｓｅｔＬｏａｎトークンのうちの１つであってもよい。ローン支払いは、それぞれのローンによって自動的に処理され、売り上げは親ファンドに渡され、そこでさらに管理手数料、配当配分、及びＩＡｓｓｅｔＦｕｎｄトークンによって管理されるような他のファンド・ファンクションとして処理することができる。この構造は、完全に透明であり、無期限にスケーリングできる自己処理型の証券化されたローン・プールを作成する。

自己処理、自己処理における自己レポーティング・ローン資産、自己レポーティング・ファンドは、世界的な金融危機の発端となった大規模な証券化ローン（例えば、ＲＭＢＳ）ファンドには存在しない透明性を与える。類似の技法を使用して、あらゆるタイプの資産のファンドを作成することができ、投資家に新しい投資機会の多様なセットへのアクセスを提供する。さらには、上述のデータ・モデル及びアーキテクチャは、より高度化されたファンド管理戦略の自動化を簡略化する。図９は、発行市場及び流通市場における資産管理用の、一般的な取引を伴うファンド管理環境９００を概略的に図示している。実装形態は、上で開示されるＩＡｓｓｅｔ及びＩＡｓｓｅｔＦｕｎｄインターフェースの使用を通じて運用のそれぞれをサポートする。図９のそれぞれの取引を以下で説明する。

資産収入から資本準備金への処理（１）：資産プール（リース、債券、債務証書、配当支払い株式など）内の収入を得る資産は、内部的な自動化されたモデル又は外部モデルを使用して収入を処理する。これらの利益は、配分用の資産ウォレットを介して処理され、資産パフォーマンスの完全なトレーサビリティを提供する。ファンド・トークンの所有者が、ＰｒｏｃｅｓｓＷａｔｅｒｆａｌｌリクエストを、そのＩＡｓｓｅｔインターフェースを介して実行すると、ファンドによって所有されるＩＡｓｓｅｔのそれぞれに対してＰｒｏｃｅｓｓＷａｔｅｒｆａｌｌリクエストが呼び出される。このリクエストの結果、ファンドの資産は利益をファンドの資本準備金（ＩＡｓｓｅｔウォレット）に移転する。ファンドは、内部的なウォーターフォール・ロジックを実行してこれらの利益を処理する。ウォーターフォールのロジックは、革新的又は繰返し可能なファンド管理戦略をサポートするための、プラグインのスマート・コントラクトであってもよい。処理が完了すると、ファンドは、トークンの処理ロジックによって定義される通りにトークンの所有者に移転される（これによってトークンの所有者によってさらなる配分ロジックが実行される場合がある）。

ポートフォリオ・ヘッジ／管理手数料の処理（２）：典型的には、ファンドのウォーターフォールは、資産管理手数料の支払いを含み、またヘッジ及び保険などのファンド運用向けの他の内部的なサービスを伴ってもよい。これらの手数料は、ウォレット移転ロジックを使用して資本準備金（資産ウォレット）から支払われ、ウォーターフォール・ロジックのスマート・コントラクトを介して実行されてもよい。ファンドの一貫した額面価格を維持するために、これらの支払いは、資産収入又は他のソースへ、資産収入又は他のソースから補充されなければならない。

償却／ターンオーバを補充する処理（３）：資産は、所与の期間（残りの価値をゼロとする）で償却される場合がある。償却は、ローンの債務不履行又は資産のアンダーパフォーミングにより生じる。一定の額面価格を維持するために、ウォーターフォールを処理する一部として資本準備金からの資産を使用して、償却は補充されなければならない。「リスクのある」収入の流れ、つまり今後の期間に債務不履行になり得る延滞ローン、又はアンダーパフォーミングの資産をサポートするために、十分な残高が資本準備金に（配分されずに）保たれるべきである。

資産の満了を補充する処理（４）：満了する、非流動性資産で構成されるファンドなど、あるタイプのファンドでは、資産から収入が処理されると、資産残存価値（収益力）が減少する。例えば、ローンの元本を減少させる住宅ローンの支払いは、結果として資産の収益力、その残存価値を減少させる。ファンドの一貫した収益力を維持するために、残存部分は、資産の購入を通じて、類似又はより良好な収益力で置き換えられるべきである。収益力が実現されると、結果として資産プールの残存価値が減少し（満了）、一方でファンド資本準備金におけるキャッシュが増加する。資本準備金資産を使用する資産購入は、ＩＡｓｓｅｔ ＣｒｅａｔｅＰｕｒｃｈａｓｅＯｒｄｅｒファンクションを使用する。含まれているファンドへの資産分配から収入をＲｅａｌｉｚｉｎｇするための資産購入は、典型的には資産の収入源リスクに比例してポートフォリオの全体的なＮＡＶを増大させる（資本準備金残高の増大が、資産プールのＮＡＶの減少を超える）。すぐに満了する資産（貿易金融）から構成されるポートフォリオでは、所与の期間にかなりの満了を迎える。満了割合が高いほど、ファンドの弾力性が大きくなる（ファンドの弾力性は、基礎となる資産の弾力性に関係する）。

クーポン又は配当配分の処理（５）：ファンドは、クーポン収入又はキャッシュ配当を所有者／株主に提供することができる。「キャッシュ」は、あらゆる資産（フィアット、暗号通貨、又は他の資産タイプ）であってもよいが、典型的には、流動的で、ファンドの株とペアで容易に売買され、資産収入と同一の資産タイプである。クーポン配分は、他のファンド支払いより先に優先的に支払われるが、配当配分は、他のウォーターフォール責任が満足された後に残る売り上げから成る。ファンドの安定性を確保するために、クーポン配分は、特に資産収入が揮発性又は不確実性の場合、ファンド資産からの全体的な期待収入未満であるべきである。配分は、ＰｒｏｃｅｓｓＷａｔｅｒｆａｌｌメソッドを介して行われる。ＣＡＴ代替性トークンは、株主配分ファンクションを含む。資産トークンを代替性トークンに付加することによって、ファンド株主への配分は、自動的に大規模に処理することができる。多くのファンドは、クーポン配分又は配当支払いを提供しない。これらの場合では、資産収入は、ファンドの額面価格を上昇させる。

現物株配当の処理（６）：ファンドは、キャッシュの配当ではなく、ファンドの株式を使用して配分を支払ってもよい。この戦略は、税務目的又は流動性を向上させるために、一部のファンドで用いられる。資本準備金からのファンドは、配分される株式を購入するために使用されてもよい。これらの株式は、いくつかの戦略を用いて購入することができる：流動的な流通市場から、ファンドＮＡＶにおける発行市場での流動性準備金プール（後述）から、又はファンドＮＡＶと一貫する株式トークンを発行することによって。株式の購入、償還、及び配分モデルの柔軟性により、ＩＡｓｓｅｔＦｕｎｄ構造が、ＥＴＦ、ミューチュアル・ファンド、又はクローズドエンド型のファンドを含むあらゆる既存のファンド管理戦略をサポートすることが可能となる。これはまた、税務又は流動性の恩恵のために、ファンド収益最適化戦略をサポートする。

発行市場購入の処理（７）：ＩＡｓｓｅｔＦｕｎｄトークンは、部分所有権を容易にするために、代替性トークンに付加されてもよい。投資家は、代替性トークン・インターフェースによってサポートされるＳｈａｒｅＰｕｒｃｈａｓｅＲｅｑｕｅｓｔ及びＳｈａｒｅＰｕｒｃｈａｓｅＳｗａｐＲｅｑｕｅｓｔメソッドを使用して発行市場においてファンド株式を購入又は売却することができる。オープンエンド型のファンド、つまり株式数が基礎となる資産の市場需要に基づいて変わり得るファンドでは、リクエストをサポートするために、株式が発行される（購入）、又は買い戻される（償還）。ファンドの運用モデルに基づいて、株式は、資産又は資産の相当金額（ＣＩＬ：ｃａｓｈ－ｉｎ－ｌｉｅｕ）と引き換えに購入側パーティに渡される。ＳｈａｒｅＰｕｒｃｈａｓｅＲｅｑｕｅｓｔは、ＣＩＬ取引である。このタイプの取引では、株式はファンドの権利行使価格、つまりファンドのＮＡＶを株式の総数で割った価格で売却される。ＳｈａｒｅＰｕｒｃｈａｓｅＲｅｑｕｅｓｔが行われ、ＮＡＶが割り振られ、購入者は、注文を遂行するために必要な「キャッシュ」資産を供給することによって、遂行しなければならない。ＩＡｓｓｅｔＦｕｎｄトークンは、キャッシュを受け取り、資産マーケットプレイスからの、又はＩＡｓｓｅｔ ＣｒｅａｔｅＰｕｒｃｈａｓｅＲｅｑｕｅｓｔファンクションを使用して、基礎となるものを購入又は割り振らなければならない。ＳｈａｒｅＰｕｒｃｈａｓｅＳｗａｐＲｅｑｕｅｓｔは、株式購入に使用される資産がファンドの投資テーゼ又はインデックス（ファンドの基礎となる資産に対する株式の割合）と一貫性のある、取引で使用される。

発行市場償還の処理（８）：この取引は、発行市場購入取引とは反対である。代替性トークンの株式は、キャッシュ（ＳｈａｒｅＲｅｄｅｅｍＲｅｑｕｅｓｔ）又は基礎となるファンドからの資産（ＳｈａｒｅＲｅｄｅｅｍＳｗａｐＲｅｑｕｅｓｔ）と引き換えにファンドに売却される。資本準備金におけるキャッシュに応じて、ＣｒｅａｔｅＳｅｌｌＲｅｑｕｅｓｔを使用してＩＡｓｓｅｔＦｕｎｄトークンから資産を清算する必要がある場合がある。

一実装形態は、弾力的な証券化を可能にするために、代替性トークンの一部として流動性リザーバの確立を含む。流動性リザーバは、資本からファンドへの純流入又は流出に基づいて、発行市場取引（又は、別個の実装形態では流通市場限度注文）を価格決定するスマート・コントラクトである。リザーバは、株式のプール及び注文を遂行することができるキャッシュを維持する。価格は、ファンド・マネージャによってセットされた通りの所望の残高からの準備金プール残高の偏差に基づいてＮＡＶ付近で調節される。例えば、ＳｈａｒｅＰｕｒｃｈａｓｅＲｅｑｕｅｓｔの不均衡による資本の著しい流入は、リザーバ内のキャッシュ・プールを増加させるが、利用可能な株式プールは減少させる。価格決定アルゴリズム（ファンド・マネージャ戦略に基づくスマート・コントラクトのプラグイン）は、準備金プール内の株価を上昇させ、償還の見込みを増大させるが、新規購入の需要は低下させる。アルゴリズムは、リザーバを残高に戻す投資家需要の変化に直面すると流動性の価格を調節するように反応する。

資産購入の処理（９）：一部のポートフォリオでは、ポートフォリオのマネージャは、資本準備金からのキャッシュを使用して資産を購入する。これらの購入はＩＡｓｓｅｔ ＣｒｅａｔｅＰｕｒｃｈａｓｅＲｅｑｕｅｓｔを使用する。例えば、満了する資産は、資産収入によって補充される資本準備金からのキャッシュで置き換えることが可能である。ＮＡＶ評価及びヘッジ戦略は、これらの決定が全体的なポートフォリオ・アルファに反映されるため、ポートフォリオ・マネージャの、主要な責任である。

資産清算の処理（１０）：準備金残高が清算しきい値を下回ると、アクションがトリガされ、資産を売却してポートフォリオの流動性要件を回復するようポートフォリオ・マネージャに要求する。これらのトリガは、スマート・コントラクトを介して定められる場合があり、ＩＡｓｓｅｔ ＣｒｅａｔｅＳｅｌｌＲｅｑｕｅｓｔを通じて実行される。

スワップ処理（１１）：他のポートフォリオでは、資産はスワップ、つまり収入を得る株式と資産の収益力に対する権利との交換を介してポートフォリオに参加している。いくつかのポートフォリオは、資産を獲得するために両方の技法を使用してもよい。スワップの使用はポートフォリオにさらなる流動性をもたらすため、キャッシュ購入の代わりに、スワップの使用が好まれる。

リザーバ補充処理（１３）：収入を生み出す資産のファンドに適用される弾力的な証券化モデルでは、株主の持続的な撤退に基づいてリザーバのキャッシュ・レベルが低い場合、キャッシュ配分を使用して、リザーバにおける流動性を回復することができる。このステップにおいて、回復するリザーバ流動性の量は、アルゴリズム的に、リザーバ残高、資本準備金及び市場状況の関数で決定される。著しい流動性の回復が必要とされる場合、満了資産を補充するためのリソースが利用不可能になる場合があり、ポートフォリオの額面価格の減少につながる。収入レベルが清算しきい値を下回ると、これは以下で説明するような資産清算ステップをトリガする。

弾力的なポートフォリオ成長処理（１４）：持続的な購入注文の不均衡による、ＮＡＶを上回る持続的な価格は、リザーバにおけるキャッシュの不均衡を作り出す。この価格がＮＡＶをしきい値で超えると、資産は資本準備金に移転されて、ファンドにさらなる資産を購入してファンドの全体的なＮＡＶの成長を推進してもよい。このモデルを使用して、ファンドのＮＡＶは、認可された関係者の使用又は新規株式の発行しに、弾力的に成長することができる。

弾力的なポートフォリオ低減処理（１５）：投資家の流動性ニーズは、キャッシュ・プールからの価値の純流出となる場合がある。ＮＡＶを下回る価格決定をもたらす持続する不均衡は、ファンドからの資産を清算して、キャッシュ・プールを回復させるために必要なキャッシュを提供する必要性をシグナリングする。ポートフォリオのアンダーパフォーマンスが持続することは、ファンド・マネージャの制御下での資産のパフォーマンスに基づき、ファンド・マネージャの影響をきれいに引き下げた管理下において制御された資産の清算を行うことになる。専門的にはクローズド型のファンドであるが、投資家需要及び資産パフォーマンスに基づく額面価格の弾力的な変動は、オープン型ファンドの望ましい特性を与える。

弾力的な証券化は、非流動性の資産を含むファンドのサイズをきれいに成長及び低減できるようにする処理である。処理は、非流動性資産の為替売買を容易にするためのファンド構造を提供するよう市場のニーズに対処し、ある為替に対する流動性資産売買と、基礎となるファンドにおける非流動性の資産との間に流動性バッファを与えてＳＥＣ Ｒｕｌｅ ２２ｅ－４に関する懸念に対処する。

リンクされたＩＡｓｓｅｔＦｕｎｄとＩＡｓｓｅｔ構造の柔軟性は、一般的且つ高度なファンド管理戦略を実行するメカニズムを提供する。構造により、一般的な資産管理ファンクションを自動化して、革新的なファンド管理戦略を投入しつつ、透明性並びに簡略化された監査及びレポーティングを提供することが可能となる。代替性トークンを非代替性のＩＡｓｓｅｔＦｕｎｄトークンにリンクすることは、ファンド株式の新しい有用性を実現する。株式は、収入（配当）又は成長のために保持されてもよい；支払いのために移転されてもよい；担保としてエスクローに保持されてもよい；認可された流通市場でＵＳＤ、ＢＴＣ、ＥＵＲ又は他の証券との交換を通じて現金化されてもよい；及び／又は代理投票を通じてファンド・ガバナンスに参加するために使用されてもよい。

開示される実装形態は、スワップ・メカニズムを介してファンド株式を使用してファンド資産を購入又は資産プールから償還できるようにする。このことは「バッキング」モデルを作成し、トークンの発行及び破壊を使用して、アセットが追加されること、又はファンドから除去されることを可能にしている。追加的に、実装形態は、流動性プールを含み、資本のファンドへの純流入及び流出を管理してもよい。流動性アルゴリズムを適用して、株価を設定して償還を管理するのを支援し、ファンドの株式用の流通市場の形成を容易にすることができる。このモデルは、繰返し可能であり、ほぼあらゆるファンド構造を満たすために使用することができる：貸与、債務証券、売掛金、定期金賠償、ファクタリング、貿易金融、保険、リースなど。

開示される実装形態によって自動化されるファンド構造の一実例として、クローズドエンド型のＬｅｎｄｉｎｇ Ｐｏｏｌファンドをファンドのスマート・コントラクトを活用して作成することができる。プールは、既存の資産、ウエアハウス・ローン、再担保契約、又は資本形成から繰り入れられる。最初、プールは貸与に必要な資本（フィアット又は暗号通貨）だけを含んでいる。ファンドのスマート・コントラクトのフォーマットを使用して、Ｐｏｏｌは、ＮＡＶ及びＰＡＲ価格（プール内のすべての資産のＮＡＶとＰＡＲ価格の合計）を公開して、サポート文書及び資産の一覧をリアルタイムに公表する。すべてのファンド取引は、不変な台帳に記録される。プールは、ポートフォリオ・マネージャ、資産マネージャ、及び任意選択で他のサービス（ヘッジ、資産保険など）を有し、ローンは、認可されたエージェント及び自動化された処理を通じて支出されたファンドによって始まる。始まりでは、ローンは、資産としてファンドに追加される。開示される実装形態を使用して、すべての資産（利用可能な貸与資本、売掛金、及び他の資産）は、認可されたパーティによってリアルタイムに閲覧することができる。

ローンは、ＩＡｓｓｅｔスマート・コントラクトを拡張するスマート・コントラクトとしてプールから始まる。このことは、証券化、ファンド運用、及び準拠した移転を容易にする。資産オブジェクトとして、それらはサポート文書、取引履歴、及びリアルタイムの資産ＮＡＶ＆ＰＡＲ価格を認可された閲覧者に公表する。ローン・トークンは、ＩＡｓｓｅｔ構造を活用してローン特性を公表し、独立的な分析及びバリュエーションを可能にする。ローン・トークンは、ＥＲＣ－２０、ＥＲＣ－７２１、又は移転を統制するために他のトークンにラップされてもよい。

ローン・トークンに組み込まれるのは、バリュエーション及び支払い処理ロジックである。支払いは、ローンに特有のアドレス（例えば、ＱＲコード（登録商標）で指定される実例）への単純な移転を介して行われる。支払いは、処理されて、売り上げは、ファンドであってもよい資産の所有者に転送される。ローンごとのＰＡＲ価格（ローン元本）及びＮＡＶ（キャッシュ・フローのリスク調節済ＮＰＶ）は、それぞれの支払いに伴いリアルタイムで更新される。ローンごとの取引履歴は、不変な台帳に記録され、認可されたユーザによる分析用に利用可能である。

プール支払い処理は、自動化され、透明である。ファンド内の個々のローン資産の返済からの売り上げは、さらなる処理のために、Ｒｉｓｋ Ｐｏｏｌに移転される。リスク・プール処理ロジックは、カスタマイズ可能なスマート・コントラクトを活用して償還、ローン償却、Ｐｏｏｌ資本補充、管理手数料、及び透明且つ検証可能なウォーターフォールにより配当＆クーポン支払いを自動化する。配当及びクーポン支払い、並びに他の配分は、スマート・コントラクトに具体化されるファンド・ロジックを使用して自動的にファンド所有者に移転される。

高度化された流動性及びリスク管理では、資産はポートフォリオから売却されてもよい（又は購入してポートフォリオに入れてもよい）。サポートされる資産取引は、ローン市場を介した購入／販売、償還及びファンド・トークンを使用したスワップを含む。他の取引は、回収及び償却を含む。配当支払いは、暗号通貨、フィアット、又は現物プール・トークンで行うことができる。トークンの発行は、発行市場の提供を通じて、オークション、又は既存利率のトークン化を通じて発生してもよい。株主（トークン保有者）は、クーポン＆配当配分を自動的に、株式所有権に比例して受け取る。結果は、配当支払いトークンである。資産に裏付けされるセキュリティ・トークンは、革命的な金融商品である。トークンは、（１）配当を受け取るために保持することができる；（２）支払いとして移転することができる；（３）担保契約としてエスクローに保持されてもよい；及び／又は（４）認可された流通市場におけるフィアット通貨、暗号通貨、又は他の証券との交換を通じて現金化することができる。

弾力的な証券化メカニズムを使用して、トークンの需要の増加は、資本の流入となる（ミューチュアル・ファンドの需要の増加に類似するモデルにおいて）。追加的な資本は、貸与プールＰＡＲ価格の拡大につながり、貸与向けにより多くの資産を提供する。このモデルは、無期限に、成長することができる。同様に、アンダーパフォーマンス又は他のファクタによって生じる資本の撤退は、ポートフォリオＮＡＶの制御されたドローダウンをもたらす。このモデルは、繰返し可能であり、ほぼあらゆる証券化ニーズを満たすために使用することができ、貸与、債務証券、売掛金、定期金賠償、ファクタリング、貿易金融、保険、リースなどを含む。

図１０は、トークン化された資産に関連するデータを管理するためのデータ記憶及び検索システムを構成するための方法１０００を図示している。１００２において、クラス定義に従って、デジタル・トークンが作成され、このトークンは一意なトークン識別子を含む。１００４において、デジタル・トークンは、資産と関連させて一意なレコードとして資産レジストリのメモリ・デバイスに登録される。１００６において、クラス定義に従って、通信インターフェースがデジタル・トークンに関連付けられる。通信インターフェースは、資産レジストリによって実装される通信仕様に準拠することができ、所定のファンクションのセットを公開するように構成される。所定のファンクションは、資産所有権移転ファンクション、資産バリュエーション公表ファンクション、資産属性決定ファンクション、及び資産特有処理ロジックを含むことができる。

１０１０において、暗号ウォレットをデジタル・トークンに関連付けることができる。ウォレットは、資産レジストリに記録されたトークンのファンクションを行うように構成される。デジタル・トークンが非代替性である場合、１０１２において代替性のデジタル・トークンを作成することが可能である。１０１４において、暗号ウォレットを代替性のデジタル・トークンに関連付けることができる。ウォレットは、トークンのファンクションを行うように構成される。１０１６において、非代替性デジタル・トークンを代替性デジタル・トークンでラップするために、非代替性デジタル・トークンの所有権は、代替性デジタル・トークンに移転することが可能であり、それによって、マルチパーティ配当配分、コーポレート・ガバナンス、及び株式売買などの共有所有権に関連付けられるファンクションを含む非代替性デジタル・トークンによって表現される資産の部分所有権が可能となる。

いくつかの実装形態では、方法１０００は、１つ又は複数の処理デバイスに実装されてもよい（例えば、デジタル・プロセッサ、アナログ・プロセッサ、情報を処理するように設計されたデジタル回路、情報を処理するように設計されたアナログ回路、状態機械、及び／又は電気的に情報を処理するための他のメカニズム）。１つ又は複数の処理デバイスは、電子的記憶媒体に電子的に記憶される命令に応答して、方法１０００の動作のうちの一部又はすべてを実行する１つ又は複数のデバイスを含んでもよい。１つ又は複数の処理デバイスは、方法１０００の動作のうちの１つ又は複数の実行用に特に設計されるハードウェア、ファームウェア、及び／又はソフトウェアを通じて構成される１つ又は複数のデバイスを含んでもよい。例えば、方法１０００は、図１のアーキテクチャによって実装することができる。もちろん、方法は、分散台帳などの非中央集権化されたシステムによって、中央集権化されたシステムによって、又は２つのタイプのシステムの組合せによって、実装されてもよい。

開示される実装形態は、分散台帳技術（ＤＬＴ）を用いて資本市場へのアクセスに革命を起こし、包括的で、内蔵型の透明性、不変性、及び取引効率を有した資産を作成することが可能なやり方で、データ管理及び送信を改善する。実装形態は、体系立ったスケーラブルなフレームワークを提供してこれらの恩恵をあらゆる資産クラスのファンド管理に適用し、発行者に革新的な戦略を伴う市場への容易な経路を提供する。米国特許出願公開第２０１９０１６４１５１（Ａ１）号で説明されるコンプライアンス意識代替性トークンと関連して使用される場合、配当、クーポン支払い、又は他の配分は、埋め込まれたスマート・コントラクト・ロジックを通じて自動化することができ、トークン保有者ウォレットへの直接的な支払いを可能にする。

資産管理ファンクションを行うために、追加的な代替構造及び機能上の設計が実装されてもよい。したがって、実装形態及び実例が図示され、説明されたが、発明は本明細書に開示された正確な構築及びコンポーネントに限定されないことを理解されたい。添付の特許請求の範囲で定義される本発明の思想及び範囲を逸脱することなく、配置構成、運用、並びに本明細書において開示される方法及び装置の詳細において、様々な修正形態、変更、及び変形形態が成され得る。

ＣＯＤＥ ＡＰＰＥＮＤＩＸ

Claims (28)

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. クラスのすべてのトークンは、前記クラス・トークンに関連付けられる属性又はファンクションを、作成すること、更新すること、又は除去することによって、同時にアップグレードすることができる、請求項２２に記載の方法。

Images