JP2019511150A - ブロックチェーンを介して資産関連活動を制御するシステム及び方法 - Google Patents

Abstract

１つの観点によると、本発明は、資産の現在所有権に比例して費用を計算し、登録し、及び／又は分配し、及び／又は収入を生成する技術的構成を提供する。１又は複数の実施形態は、暗号サブキーを生成する新規技術も含む。したがって、本発明により提供される１つの利点は、ブロックチェーン上に登録され維持される資産の費用及び収入のセキュアな分配を可能にすることである。また、これは、資産自体及び投資団体のような様々なエンティティの現実世界の必要を満たす、このような資産の能力を増大する。一実施形態では、本発明は、ブロックチェーンを介して行われる転送を制御するコンピュータにより実装されるシステムであって、前記システムは、複数の秘密暗号鍵を有する資産であって、各秘密鍵は前記資産の所有者に関連付けられる、資産と、複数の公開暗号鍵を有するレジストリであって、各公開鍵は、前記資産の複数の秘密鍵のうちの１つの秘密鍵に対応し、未使用ブロックチェーントランザクションの中で識別可能なRedeemScriptハッシュに関連付けられる、レジストリと、前記資産に関して転送が行われるための１又は複数のブロックチェーントランザクションの自動生成に関連する少なくとも１つのルールを有するスマートコントラクトと、前記スマートコントラクトの前記少なくとも１つのルールを評価し及び／又は実行するよう構成された計算エージェントと、を含むシステムを提供する。幾つかの実施形態では、計算エージェントの階層構造は、スマートコントラクトの中で定められる資産県連タスクを実行するために、マスタエージェントにより管理される。マスタ及び従属エージェントは、離散タスクを実行するために通信する。

Description

本発明は、概して、コンピュータにより実施される資産の制御、交換、及び処理に関する。特に、本発明は、スマートコントラクトの分野に関し、ブロックチェーンのようなピアツーピア分散ネットワークと共に使用することに適する。これは、ビットコインブロックチェーン又は代替のブロックチェーンプラットフォームであって良い。本発明は、特に、資産の所有権が複数のエンティティの間で分割され、及び／又は該資産から価値が生じ又は生成される状況で有利である。本発明は、このような状況における活動のためのトリガとして機能するイベントを決定し及びそれに応答するメカニズムを提供する。本発明は、電子資産の制御及び転送に関連して向上したセキュリティ及び匿名性を提供する暗号技術も含む。

ブロックチェーンは、ブロックにより構成される、コンピュータにより実装される非集中型の、合意に基づく分散型システムである。また、ブロックはトランザクションにより構成される。各ブロックは前のブロックのハッシュを含み、ブロックは共にチェーンになって、その発端からブロックチェーンに書き込まれている全てのトランザクションの永久的な変更不可能なレコードを生成する。トランザクションは、そのインプット及びアウトプットに組み込まれるスクリプトとして知られる小さなプログラムを含む。スクリプトは、トランザクションのアウトプットがどのように及び誰によりアクセス可能かを指定する。

最も広く知られているブロックチェーン技術の用途はビットコイン台帳であるが、他のブロックチェーンの実装が提案され開発されている。ビットコインは便宜上及び説明を目的として本願明細書において言及されるが、本発明はビットコインのブロックチェーンと共に使用することに限定されず、代替のブロックチェーンの実装が本発明の範囲に含まれることに留意すべきである。

ブロックチェーン技術は、暗号通貨の実装の使用のために最も広く知られている。しかしながら、更に近年は、デジタル起業家が、新しいシステムを実装するために、ビットコインの基づく暗号通貨セキュリティシステムの使用、及びブロックチェーンに格納可能なデータの両者を探索し始めている。これらは、限定ではないが、以下を含む：
・メタデータを格納する。情報をトランザクション内のメタデータとして埋め込むことにより、該情報がブロックチェーンを介して転送可能である。これは、以下のために使用可能である。
・デジタルトークンを実施する。
・デジタル署名により署名された取引を確立する。スマートコントラクトは、どの動作が実行されるべきか、例えば支払が特定パーティに対して行われるべきか否かを決定するために評価され得る条件及びテストを含み得る、自己実行型の機械可読ソリューションを提供するよう設計できる。

自動で、セキュアな且つ効果的な方法で、収入及び／又は費用を計算し及びブロックチェーンに基づく資産の所有者に割り当て可能であることは有利である。これを行うために、このような資産の所有者に又はそれにより支払可能な収入又は費用のような動作を生成するイベント（トリガ）が検出される必要があり得る。次に、収入又は費用支払を実行するためにブロックチェーントランザクションを自動的に（つまり機械により）生成し署名するための技術が必要である。

このような改良されたソリューションが考案されている。本発明は、ブロックチェーントランザクションの自動生成を可能にするブロックチェーンプロトコルに基づき構築される技術ソリューションを含み得る。トランザクションは、収入又は費用の支払のような、ブロックチェーンを介するエンティティ間の転送を行うために使用されて良い。ブロックチェーンの使用は、所与の取引に関して行われる任意の支払のセキュアな、公の記録が存在することを保証する。これは、争いのあるシナリオで、取引に対する滞納の証拠を提供するために独自システム及びデータソースへのアクセスを得る必要を除去し又は少なくとも軽減する。本発明は、暗号鍵の生成のための新規技術も含み及びそれを利用し得る。本発明から生じる他の利点のうちの幾つかは、以下に議論される。

本発明は、ブロックチェーン上での交換を制御し、計算し、生成し、及び／又は実行するコンピュータにより実装されるシステム又はメカニズムを提供できる。交換（転送）は、任意の種類の物理的、仮想的、又は論理的資産に関連して良い。

本発明は、資産に関して、ブロックチェーンを介して行われる転送を制御するよう構成されて良く、資産又は資産の表現を含んで良い。資産又は表現は、１又は複数の秘密暗号鍵を含んで良く、各秘密鍵は資産の所有者に関連付けられる。秘密鍵は、暗号鍵ペアの部分であって良い。秘密鍵のうちの１又は複数は、「サブキー生成の方法」と題される章で後述される技術に従い生成されて良い。秘密鍵のうちの１又は複数は、共通シークレットを用いて生成されて良い。それは、マスタ暗号鍵から生成されるサブキーであって良い。

本発明は、第１及び第２エンティティに共通のシークレットを決定する技術を含み得る。第１又は第２エンティティは資産であって良く、他方のエンティティは制御部又は資産に関連付けられた他のエンティティであって良い。本方法は、以下のステップ：
・少なくとも１つの第１エンティティマスタ秘密鍵及び生成器値に基づき、第１エンティティ第２秘密鍵を決定するステップと、
・少なくとも１つの第２エンティティマスタ秘密鍵及び生成器値に基づき、第２エンティティ第２秘密鍵を決定するステップと、
第１エンティティ第２秘密鍵及び第２エンティティ第２公開鍵に基づき、第１エンティティにおいて共通シークレット（ＣＳ）を決定し、第２エンティティ第２秘密鍵及び第１エンティティ第２公開鍵に基づき、第２エンティティにおいて共通シークレット（ＣＳ）を決定するステップと、を含み、
・第１エンティティ第２公開鍵及び第２エンティティ第２公開鍵は、それぞれ、第１／第２エンティティマスタキー及び生成器値に基づく。

本発明は、レジストリを更に含んで良い。レジストリは、１又は複数の公開暗号鍵を格納して良い。各公開鍵は、資産の秘密鍵のうちの１つに対応して良い。（１又は複数の）公開鍵は、未使用ブロックチェーントランザクション（ＵＴＸＯ）の中で識別可能なRedeemScriptハッシュに関連付けられて良い。

本発明は、転送が資産に関して行われることを可能にする、１又は複数のブロックチェーントランザクションの自動生成に関する少なくとも１つのルールを含むスマートコントラクトを含んで良い。スマートコントラクトは、機械可読及び／又は実行可能であって良い。

本発明は、スマートコントラクトの少なくとも１つのルールを評価し及び／又は実行するよう構成された計算エージェントを含んで良い。計算エージェントは、実質的に後述される通りであって良い。

転送は、例えば公債又は暗号通貨の一部のような何らかの通貨の転送であって良い。これは、資産に関して行われるべき支払であって良い。これは、資産に関連付けられる収入又は費用に関連して良い。転送は、スマートコントラクトの中で指定されるパーティ間で行われて良い。通貨はビットコイン、又は任意のデジタル（暗号）通貨、又はトークン化された値であって良い。

スマートコントラクトの中で提供される少なくとも１つのルールは、資産に関連付けられる支払スケジュールを定めて良い。

計算エージェントは、別の計算エージェントと通信するよう構成されて良い。前記別の計算エージェントの各々は、資産に関連付けられたタスクを実行するよう構成されて良い。計算エージェントは、別の計算エージェントの各々の活動を調整し及び／又は認可するよう構成されて良い。したがって、「マスタ」計算エージェント及び１又は複数の従属（別の）計算エージェントが存在して良い。マスタエージェントは、１又は複数の従属計算エージェントの活動を制御し、指示し、又は監視するよう構成されて良い。

本発明は、資産に関連付けられた収入に関するブロックチェーントランザクションを生成するよう構成される少なくとも１つの別の計算エージェント（後述するような「収入エージェント」）を含んで良い。

本発明は、資産に関連付けられた費用に関するブロックチェーントランザクションを生成するよう構成される少なくとも１つの別の計算エージェント（後述するような「費用エージェント」）を含んで良い。

本発明は、資産に関連付けられた支払に対する収入の相殺決済を処理するよう構成される少なくとも１つの別の計算エージェント（後述するような「相殺決済エージェント」）を含んで良い。

本発明は、警告を生成し及び／又は資産の所有者に送信するよう構成される少なくとも１つの別の計算エージェント（後述するような「通知エージェント」）を含んで良い。該警告は、資産に関するイベントについての通知を提供する。

計算エージェントは、スマートコントラクトの中で指定されたイベント又はトリガを検出すると、ブロックチェーントランザクションを生成するよう構成されて良い。

スマートコントラクトは、分散ハッシュテーブルに格納されて良い。取引のハッシュは、ブロックチェーントランザクションに関連付けられたメタデータの中で提供されて良い。

本発明は、資産に関してブロックチェーンを介して行われる転送を制御する、コンピュータにより実施される方法であって、前記方法は、以下のステップ：
少なくとも１つの秘密暗号鍵を含む資産を定めるステップであって、各秘密鍵は資産の所有者に関連付けられる、ステップと、
少なくとも１つの公開暗号鍵を含むレジストリを生成するステップであって、各公開鍵は、
資産の１又は複数の秘密鍵のうちの１つの秘密鍵に対応し、
未使用ブロックチェーントランザクションの中で識別可能なRedeemScriptハッシュに関連付けられる、ステップと、
転送が資産に関して行われることを可能にする、１又は複数のブロックチェーントランザクションの自動生成に関する少なくとも１つのルールを含むスマートコントラクトを生成するステップと、
スマートコントラクトの少なくとも１つのルールを評価し及び／又は実行するよう構成された計算エージェントを使用するステップと、を含む方法を更に含む。

前記転送は、前記資産に関して行われるべき通貨の転送であって良く、前記転送は、前記資産に関連付けられた収入又は費用に関連する。通貨はビットコイン、又は任意のデジタル通貨、又はトークン化された値であって良い。

スマートコントラクトの中で提供される少なくとも１つのルールは、資産に関連付けられる支払スケジュールを定めて良い。

前記方法は、前記計算エージェントを別の計算エージェントと通信するよう構成し、前記別の計算エージェントの各々を、前記資産に関連付けられたタスクを実行するよう構成するステップ、を更に含んで良い。

計算エージェントは、別の計算エージェントの各々の活動を調整し及び／又は認可するよう構成されて良い。

前記方法は、
ｉ）資産に関連付けられた収入に関するブロックチェーントランザクションを生成するよう構成される少なくとも１つの別の計算エージェントと、
ｉｉ）資産に関連付けられた費用に関するブロックチェーントランザクションを生成するよう構成される少なくとも１つの別の計算エージェントと、
ｉｉｉ）資産に関連付けられた支払に対する収入の相殺決済を処理するよう構成される少なくとも１つの別の計算エージェントと、
ｉｖ）警告を生成し及び／又は資産の所有者に送信するよう構成される少なくとも１つの別の計算エージェントであって、該警告は、資産に関するイベントについての通知を提供する、少なくとも１つの別の計算エージェントと、を提供するステップを更に含んで良い。

計算エージェントは、スマートコントラクトの中で指定されたイベント又はトリガを検出すると、ブロックチェーントランザクションを生成するよう構成されて良い。

前記スマートコントラクトは、分散ハッシュテーブルに格納されて良く、前記取引のハッシュは、ブロックチェーントランザクションに関連付けられるメタデータ内で提供される。

本発明の１又は複数の実施形態は、「サブキー生成の方法」と題される章で後述される技術を含み得る。これは、第１及び第２エンティティに共通のシークレットを決定する技術を含み得る。以後、用語「ノード」は、参照を容易にするために、「エンティティ」の代わりに使用されることがある。本方法は、以下のステップ：
・少なくとも１つの第１ノードマスタ秘密鍵及び生成器値に基づき、第１ノード第２秘密鍵を決定するステップと、
・少なくとも１つの第２ノードマスタ秘密鍵及び生成器値に基づき、第２ノード第２秘密鍵を決定するステップと、
第１ノード第２秘密鍵及び第２ノード第２公開鍵に基づき、第１ノードにおいて共通シークレット（ＣＳ）を決定し、第２ノード第２秘密鍵及び第１ノード第２公開鍵に基づき、第２ノードにおいて共通シークレット（ＣＳ）を決定するステップと、を含んで良く、
・第１ノード第２公開鍵及び第２ノード第２公開鍵は、それぞれ、第１／第２ノードマスタキー及び生成器値に基づく。

追加又は代替で、本発明の１又は複数の実施形態は、以下のようなコンピュータにより実施される方法：
第１ノード（Ｃ）において、第１ノード（Ｃ）及び第２ノード（Ｓ）に共通な共通シークレット（ＣＳ）を決定するステップであって、第１ノード（Ｃ）は第１ノードマスタ秘密鍵（Ｖ_１Ｃ）及び第１ノードマスタ公開鍵（Ｐ_１Ｃ）を有する第１非対称暗号ペアに関連付けられ、第２ノードは第２ノードマスタ秘密鍵（Ｖ_１Ｓ）及び第２ノードマスタ公開鍵（Ｐ_１Ｓ）を有する第２非対称暗号ペアに関連付けられる、ステップ、を含んで良く、前記方法は、
少なくとも１つの第１ノードマスタ秘密鍵（Ｖ_１Ｃ）及び決定キー（ＤＫ）に基づき、第１ノード第２秘密鍵（Ｖ_２Ｃ）を決定するステップと、
少なくとも１つの第２ノードマスタ公開鍵（Ｐ_１Ｓ）及び決定キー（ＤＫ）に基づき、第２ノード第２公開鍵（Ｐ_２Ｓ）を決定するステップと、
第１ノード第２秘密鍵（Ｖ_２Ｃ）及び第２ノード第２公開鍵（Ｐ_２Ｓ）に基づき、共通シークレット（ＣＳ）を決定するステップと、を含み、
第２ノード（Ｓ）は、第１ノード第２公開鍵（Ｐ_２Ｃ）及び第２ノード第２秘密鍵（Ｖ_２Ｓ）に基づく同じ共通シークレット（Ｓ）を有し、
第１ノード第２公開鍵（Ｐ_２Ｓ）は、少なくとも１つの第１ノードマスタ公開鍵（Ｐ_１Ｃ）及び決定キー（ＤＫ）に基づき、
第２ノード第２秘密鍵（Ｖ_２Ｓ）は、少なくとも１つの第２ノードマスタ秘密鍵（Ｖ_１Ｓ）及び決定キー（ＤＫ）に基づく。

決定キー（ＤＫ）は、メッセージ（Ｍ）に基づいて良い。前記方法は、以下のステップ：
メッセージ（Ｍ）及び第１ノード第２秘密鍵（Ｖ_２Ｃ）に基づき、第１署名メッセージ（ＳＭ１）を生成するステップと、
通信ネットワークを介して、第１署名メッセージ（ＳＭ１）を第２ノード（Ｓ）へ送信するステップと、を更に含んで良く、
第１署名メッセージ（ＳＭ１）は、第１ノードを認証するために、第１ノード第２公開鍵（Ｐ_２Ｃ）により検証できる。

望ましくは、前記方法は、以下のステップ：
通信ネットワークを介して、第２署名メッセージ（ＳＭ２）を第２ノード（Ｓ）から受信するステップと、
第２ノード第２公開鍵（Ｐ_２Ｓ）により第２署名メッセージ（ＳＭ２）を検証するステップと、
第２署名メッセージ（ＳＭ２）を検証するステップの結果に基づき、第２ノード（Ｓ）を認証するステップと、を含んで良く、
第２署名メッセージ（ＳＭ２）は、メッセージ（Ｍ）又は第２メッセージ（Ｍ２）、及び第２ノード第２秘密鍵（Ｖ_２Ｓ）に基づき生成される。

望ましくは、前記方法は、以下のステップ：
メッセージ（Ｍ）を生成するステップと、
通信ネットワークを介して、メッセージ（Ｍ）を第２ノード（Ｓ）へ送信するステップと、を含んで良い。

望ましくは、前記方法は、以下のステップ：
通信ネットワークを介して、メッセージ（Ｍ）を第２ノード（Ｓ）から受信するステップ、を含んで良い。

望ましくは、前記方法は、以下のステップ：
通信ネットワークを介して、メッセージ（Ｍ）を別のノードから受信するステップ、を含んで良い。

望ましくは、前記方法は、以下のステップ：
メッセージ（Ｍ）をデータストア、及び/又は第１ノード（Ｃ）に関連付けられた入力インタフェースから受信するステップ、を含んで良い。

望ましくは、第１ノードマスタ公開鍵（Ｐ_１Ｃ）及び第２ノードマスタ公開鍵（Ｐ_１Ｓ）は、それぞれの第１ノードマスタ秘密鍵（Ｖ１Ｃ）及び第２ノードマスタ秘密鍵（Ｖ１Ｓ）及び生成器（Ｇ）の楕円曲線点乗算に基づいて良い。

望ましくは、前記方法は、以下のステップ：
通信ネットワークを介して、第２ノードマスタ公開鍵（Ｐ_１Ｓ）を受信するステップと、
第１ノード（Ｃ）に関連付けられたデータストアに、第２ノードマスタ公開鍵（Ｐ_１Ｓ）を格納するステップと、を含んで良い。

望ましくは、前記方法は、以下のステップ：
第１ノード（Ｃ）において、第１ノード秘密鍵（Ｖ１Ｃ）及び第１ノードマスタ公開鍵（Ｐ１Ｃ）を生成するステップと、
通信ネットワークを介して、第１ノードマスタ公開鍵（Ｐ_１Ｃ）を第２ノード（Ｓ）及び／又は他のノードを送信するステップと、
第１ノード（Ｃ）に関連付けられた第１データストアに、第１ノードマスタ秘密鍵（Ｖ_１Ｃ）を格納するステップと、を含んで良い。

望ましくは、前記方法は、以下のステップ：
通信ネットワークを介して、第２ノードへ、共通シークレット（ＣＳ）を決定する方法のために、共通生成器（Ｇ）と共に共通楕円曲線暗号（ＥＣＣ）システムを使用することを示す通知を送信するステップ、を含んで良く、
第１ノードマスタ秘密鍵（Ｖ_１Ｃ）及び第１ノードマスタ公開鍵（Ｐ_１Ｃ）を生成するステップは、
共通ＥＣＣシステムの中で指定された許容範囲の中のランダム整数に基づき、第１ノードマスタ秘密鍵（Ｖ_１Ｃ）を生成するステップと、
次式：Ｐ_１Ｃ＝Ｖ_１Ｃ×Ｇに従い、第１ノードマスタ秘密鍵（Ｖ_１Ｃ）及び共通生成器（Ｇ）の楕円曲線点乗算に基づき、第１ノードマスタ公開鍵（Ｐ_１Ｃ）を決定するステップと、を含む。

望ましくは、前記方法は、以下のステップ：
メッセージ（Ｍ）のハッシュの決定に基づき、決定キー（ＤＫ）を決定するステップ、を含んで良く、
第１ノード第２秘密鍵（Ｖ_２Ｃ）を決定するステップは、次式：Ｖ_２Ｃ＝Ｖ_１Ｃ＋ＤＫに従い、第１ノードマスタ秘密鍵（Ｖ_１Ｃ）及び決定キー（ＤＫ）のスカラ和に基づき、
第２ノード第２公開鍵（Ｐ_２Ｓ）を決定するステップは、次式Ｐ_２Ｓ＝Ｐ_１Ｓ＋ＤＫ×Ｇに従い、決定キー（ＤＫ）及び共通生成器（Ｇ）の楕円曲線点乗算への第２ノードマスタ公開鍵（Ｐ_１Ｓ）の楕円曲線点加算に基づく。

望ましくは、決定キー（ＤＫ）は、前の決定キーのハッシュを決定することに基づいて良い。

第１非対称暗号ペア及び第２非対称暗号ペアは、それぞれ、前の第１非対称暗号ペア及び前の第２非対称暗号ペアの関数に基づいて良い。

ある実施形態又は態様に関連して上述した任意の特徴は、任意の他の実施形態又は態様に関連して使用されても良い。例えば、方法に関連して記載されて任意の特徴は、システムに関連して使用されて良く、逆も同様である。

本発明の上述の及び他の態様は、本願明細書に記載される実施形態から明らかであり、それらの実施形態を参照して教示される。

本発明の実施形態は、単なる例として添付の図面を参照して以下に説明される。
本発明の実施形態により実装されたシステムの概観を示す。 本発明に関連して利用され得る幾つかの説明のための使用例を示す。 本願で使用される競走馬（Racehorse）例について、図５〜１１のトランザクションで使用されるメタデータのフォーマットを示す。 Ｒａｃｅｈｏｒｓｅ資産の定義を示す。 以下で使用される「競走馬」シナリオのシーケンスを開始するトランザクションを示し、該トランザクションでは、ｓｔａｂｌｅは以下に記載されるサブキーを生成する方法を用いて競走馬のための秘密鍵を生成し、次にｓｅｅｄが株式発行のための競走馬口座を見付ける。 図５から続くブロックチェーントランザクションを示し、該トランザクションでは、次に競走馬が自身で株式（share、持分）を発行する。留意すべきことに、技術的にｓｔａｂｌｅは競走馬の秘密鍵を所有するが、論理的にこれが起こっていることである。 投資家からのｓｔａｂｌｅ料金セットを請求するトランザクションを示す。 競走馬がｓｔａｂｌｅ料金をｓｔａｂｌｅに渡すトランザクションを示す。 競走馬は自身の初めてのレースに勝つと生成されるトランザクションを示し、ｓｔａｂｌｅは£２０，４００を稼ぐ。標準的なＢＴＣブローカトランザクション（図示せず）を用いて、ＧＢＰ２０，４００と引き換えに、ＥｘｃｈａｎｇｅがｓｔａｂｌｅにＢＴＣ等価額を支払う（トランザクションＩＤ＝ＥＸＣＨＡＮＧＥ−Ｓ３−Ｔ１）。ＥＸＣＨＡＮＧＥ−Ｓ３−Ｔ１からのアウトプットをインプットとして用いて、ｓｔａｂｌｅは、競走馬キーにＢＴＣとして賞金を支払うトランザクションを生成する。 競走馬が投資家に自身の賞金を支払うトランザクションを示す。 ＡｌｉｃｅがＥｖｅに１株を売るトランザクションを示す。 後述するような親キーからサブキーを導出する説明のための技術の種々の態様を示す。 後述するような親キーからサブキーを導出する説明のための技術の種々の態様を示す。 後述するような親キーからサブキーを導出する説明のための技術の種々の態様を示す。 後述するような親キーからサブキーを導出する説明のための技術の種々の態様を示す。 後述するような親キーからサブキーを導出する説明のための技術の種々の態様を示す。 後述するような親キーからサブキーを導出する説明のための技術の種々の態様を示す。 後述するような親キーからサブキーを導出する説明のための技術の種々の態様を示す。

本技術は、本発明の態様と関連して使用することに適する。

＜本願明細書で使用される主な用語＞
以下の用語は、鍵の概念及びコンポーネントを定めるために本願明細書で使用される。

１つの観点からは、ここに記載される発明は、ブロックチェーン上の交換を制御する一般的技術メカニズムを提供するとして考えられる。これらの交換は、支払に関連する金融上の交換であって良い。本発明は、この交換を可能にする技術的メカニズム又は箱を対象とする。

１つの観点によると、本発明は、資産の現在所有権に比例して費用を計算し、登録し、及び／又は分配し、及び／又は収入を生成する技術的構成を提供する。したがって、本発明により提供される１つの利点は、ブロックチェーン上に登録され維持される資産の費用及び収入を表すデータの分配又は転送を可能にすることである。また、これは、資産自体及び投資団体のような様々なエンティティの現実世界の必要を満たす、このような資産の能力を増大する。

ブロックチェーンアプリケーションの最近の研究は、「スマートコントラクト」として知られるものを生成し及び使用するメカニズム、及びこれらがブロックチェーンに対してどのように監視され管理され得るかの探索を含む。１つの可能性は、資産の所有権が多数の他のエンティティの間で分割できる資産を表すために、スマートコントラクトを使用することである。この所有権は、次に、転送の箱（vehicle）のようなブロックチェーンを用いるエンティティの間でセキュアに転送され得る。

幾つかの例では、資産は、生成される収入に権利を授与する。追加又は代替で、資産は、保有者を特定の費用債務に結合できる。本発明は、資産に対して未払いの費用又は資産から生成される収入のような値が、ブロックチェーンを介して交換され得るようにする、一般的メカニズムを提供する。

＜本発明の主な要素＞
本発明の幾つかの要素は次の通りである。
・ブロックチェーンに基づく資産の所有者に支払可能な収入を生成するイベント（トリガ）を決定する技術的ソリューション及び技術。
・ブロックチェーンに基づく資産の所有者により支払可能な費用を生成するイベント（トリガ）を決定する技術的ソリューション及び技術。
・所定ルールセットに基づき、ブロックチェーンに基づく資産の収入／費用を計算し所有者に割り当てる技術的ソリューション及び技術。
・収入／費用支払を実行するためのビットコイントランザクションを生成し署名する技術的ソリューション及び技術。

図１に示すように、処理は階層構造のエージェントにより制御される。これらのエージェントは、ブロックチェーンと並列に実行するコンピュータに基づくリソースであって良い。これらは、ブロックチェーンの状態を監視し、テストの結果及び条件に応答するよう適切にプログラムでき、及び／又はブロック外リソースからインプットを受信できる。このようなエージェントがどのように実装できるかの例については、以下の「本発明と共に使用するための説明のための計算エージェント」と題された章を参照する。

本願明細書に記載の例では、以下が仮定される。しかしながら、本例は基礎にある方法において可能な変形を限定しないことが理解される。
・取引毎に（つまり資産毎に）１つのマスタエージェント（Master Agent）がある。離散機能を実行する幾つかの従属エージェント（Agent）があって良い。
・マスタエージェントは全ての従属エージェントを管理し「認可する」。
・本発明の従属エージェントは、以下の種類のエージェントのうちの１又は複数の組み合わせを含む。
− 資産から生成される収入を処理することを担う１又は複数の収入エージェント（Income Agent）。
− 資産から生成される費用を処理することを担う１又は複数の費用エージェント（Cost Agent）。
・任意で、適切な場合には支払に対して収入を相殺することを担う１又は複数の相殺エージェント（Netting Agent）。
− 行われた収入支払、費用未払金、資産に影響する又は関連するイベント、のような種々のイベント、又は任意の他の通知を株（share、持分）所有者に警告することを担う１又は複数の通知エージェント（Notification Agent）。
− 必要な又は任意の離散機能を実行する任意の他の種類のエージェント。

エージェントの動作は、ルールに基づき、任意の所定ルールセットに従って良い。ルールは、実行されるべきタスクの要件に従い決定される。本発明によると、マスタエージェントは全ての他のエージェントを管理する。制御及び処理の階層的及び可能なフローの一例は、以下の通りであって良い。
・マスタエージェントは、収入／費用エージェントがそれらの例えば以下のタスクを実行することを認可する。
− マスタエージェントは全てのトリガを監視する、又は、
− 従属エージェントは、処理するために、トリガを監視し、マスタエージェントから権限を求める、又は、
− 従属エージェントは、それらのタスクを監視し及び実行することを予め認可される、又は、
− 上述の任意の組み合わせ。
・収入／費用エージェントからのアウトプット及び制御は、マスタエージェントに渡される。
・マスタエージェントは、（収入／費用エージェントからのデータを渡すことを）相殺エージェントに保証する。
・相殺エージェントはマスタエージェントにアウトプットを渡す。
・マスタエージェントは、トランザクションブロードキャストを認可する（自身がブロードキャストを行う、又は従属エージェントがブロードキャストすることを認可する、又は組み合わせ、等）。

以下は、本発明の一実施形態の鍵要件の概要である。

＜現在の所有権を決定する＞
資産に対して費用／収入を配分するために、該資産の現在の所有権を決定可能である必要がある。本発明の一実施形態によると、現在の所有権に関する詳細事項は、レジストリ（公衆又は私設、分散又は集中型）の中に維持される。レジストリは、未使用ブロックチェーントランザクション（ＵＴＸＯ）の中で識別可能なRedeemScriptハッシュに関連付けられた個々の所有者の公開鍵を含んで良い。ＵＴＸＯは、各公開鍵により所有される株数を示す。さらに、電子メールアドレス等のような他の情報が格納されて良い。

＜費用を計算し支払う＞
資産の所有権に費用を生じさせるために、
・資産は、その現在の所有権を決定する能力を有しなければならない、
・資産は、所与の時間期間の間の合計費用／収入を決定可能でなければならない、
・資産は、現在の所有権の間で費用／収入を分割可能でなければならない、
・資産は、現在の資産保有者から／へのこれらの費用／収入の支払をトリガ可能でなければならない、支払は、パーティ間で何らかの値を交換するためのブロックチェーントランザクションを生成することにより、実行される。

支払ルールは、資産の種類、及び収入の種類に依存して、簡易又は複雑であって良く、必要なインプットデータ及び／又はパラメータの提供が可能である。例えば、収入ルールは、それらの現在の所有権比率に従い、合計収入のうちの割り当てを支払うことであり得る。別の例では、各保有者は、収入が生じた時間期間に渡る彼らの所有権比率に基づき、収入の割り当てを与えられるべきであって良い。別の例では、「ボーナス」が、所与の時間長の間の株所有権の保持に対して、支払われて良い。これらの例は、単に説明のためであり、設定可能な異なる支払ルールの数又は種類を限定しない。

取引執行（例えば、未払費用の回収）は、幾つかの方法で達成可能である。これらのうちの幾つかは、自動的に（ここでも計算エージェントを使用することにより）又は非自動的手段により制御できる。例えば、次の通りである。
・法的補償
・資産の所有権の再割り当て（発行人が資産再割り当てに副署することを要求される場合のみ可能であるが）
・費用が回収されるまで、収入の支払を阻止する。

＜他の機能＞
他の（任意的）機能は、エージェントを設計すること及び相応してルールを設定することにより、構築できる。説明のための、非包括的な例は、以下を含む：
・資産は、収入から費用を相殺することが可能であって良い、
・資産は、前の費用が支払われていない場合、収入を保持することが可能であって良い、
・この収入／費用／相殺は、時間期間の終わりに（例えば、６ヶ月毎に）又は生成されるときに（例えば、直ちに）到来して良い。

＜技術的モデル＞
本願明細書に提示される技術的ソリューションは、計算エージェント及びスマートコントラクトの使用を介して資産の制御のためのブロックチェーンに基づくメカニズムを提供する。本発明は、ブロックチェーントランザクションセットの自動生成を可能にする。これらのトランザクションは、スマートコントラクトの実行に関連する費用の取り戻し又は収入の支払のいずれかへの支払のために使用できる。図１は、本発明の一実施形態によるシステムの概観を示す。該システムは、該システムのアーキテクチャを実装するよう構成され得るコンポーネントを含む。

＜Ｃｏｓｔ Ａｇｅｎｔ（費用エージェント）＞
費用エージェントは、トリガ条件が満たされると、
・全体として資産の合計未払い金を計算し、
・取引内で定められた支払ルールに基づき、資産の現在の所有権分割に渡り、例えば比例して、個々の支払を計算し、
・個々の資産保有者の各々について支払トランザクションを生成する。

必要な場合には、所与の取引に対して定められた１つより多くの、例えば定期的な費用について１つ、臨時費用について１つの、費用エージェントが存在し得る。

＜Ｉｎｃｏｍｅ Ａｇｅｎｔ（収入エージェント）＞
収入エージェントは、トリガ条件が外れると、
・全体として資産の合計未払い金を計算し、
・取引内で定められた支払ルールに基づき、資産の現在の所有権分割に渡り、例えば比例して、個々の支払を計算し、
・個々の資産保有者の各々について支払トランザクションを生成する。

必要な場合には、所与の取引に対して定められた１つより多くの（例えば定期的な収入について１つ、臨時収入について１つの）収入エージェントが存在し得る。

＜Ｎｅｔｔｉｎｇ Ａｇｅｎｔ（相殺エージェント）＞
相殺エージェントは、トリガ条件が満たされると、
・支払アドレスの一致する複数の個々のトランザクションから、支払トランザクションを単一の相殺トランザクションに合併整理する。

本願で提供される例では、単一の相殺取引のみが存在する。しかしながら、重要なことに、本発明はこれに関して限定されないことに留意する。１又は複数の実施形態では、複数の相殺エージェントが存在して良い。このような場合には、各インスタンスは、明確に定められた別個のルールセットと共に提供される。

＜現在の所有権の分割を決定する＞
本願明細書に記載される実施形態は、資産の現在の所有権がレジストリ（又はデータベース）及びＵＴＸＯリストの組み合わせにより決定できると仮定する。用語「ＵＴＸＯリスト」は、従来知られており、未だ使用されていないブロックチェーン上のトランザクションアウトプットのリストを表す。

図２は、本願明細書に記載の技術的モデルに関連する幾つかの主要な使用例を示す。これらは、以下に更に詳細に説明される。

＜所有権の決定［１００］＞
留意すべきことに、以下の例は、資産自体により動作が直接実行されると仮定する。しかしながら、他の実施形態では、この主体は、同じ処理を使用する何らかの他の資産制御部により置換されて良い。本使用例では、資産（Asset）は、支払を実現するために自身の現在の所有権を決定する必要がある。
［表１］

＜支払計算［２００］＞
再び、本例における主要主体は資産である。しかしながら、他の実施形態では、資産は別の主要主体により置き換えられて良い。支払計算の本使用例では、資産は、自身が（上述の使用例１００で決定したような）自身の現在の所有者に支払う又はそれらか収集すべき収入及び／又は費用の額を計算したいと望む。
［表２］

＜費用を支払う［３００］＞
再び、本例における主要主体は資産である。資産保持者（Asset Holder）は、資産の所有権の結果として発生した費用を支払うことを望む。
［表３］

＜考察＞
留意すべきことに、資産保持者が彼らの比率の費用を支払う特定の動機がないことである。上述の処理では、２つの経路を通じて可能な補償が存在する。
・費用が支払われない場合、後に生じる収入は保留され得る。これは、取引の中で定められる必要がある（資産に対して生成される収入が存在すると仮定する）。しかし、これは、ステップ１００．１０の中で検出することが容易である。
・関連法的チャネルを通じる法的補償。

資産保持者が支払わない場合、ｎ人のうちのｍ人のマルチシグネチャトランザクションを用いて、彼らの資産所有権が取り消され、資産自体に戻されるように、発行トランザクションについて公証人が存在するように、取引を生成することが可能である。このシナリオでは、以下の通りである。
・ステップ３００．２０が実行された後に、費用を支払うために許可された時間に基づき設定されたロック時間と共に、第２トランザクションが生成される。これは、最後のトランザクション発行のトランザクションインプットを取り入れるが、資産を資産に割り当て戻す。このトランザクションは、関連公証人により署名される。
・資産保持者が彼らの費用を支払う場合、このトランザクションは無効であるが（トランザクションインプットが使用済みなので）、支払わない場合、資産所有権は取り消される。支払トランザクションは効果的に資産と共に株を再発行するので、本トランザクションは、次の期間にロールオーバすることができず、むしろ、費用トランザクションが生成されるときはいつも、２つのトランザクションが生成されなければならない。

＜変形１＞
上述の例は、費用がビットコインで支払われると仮定した。しかしながら、任意のトークン化された値が使用可能なので、これについて要件が存在しない。この状況では、以下の変更が必要である。
・ステップ３００．５０は、単に１つではなく、２つのトランザクションインプットを追加する。１番目はＢＴＣでのマイニング料金であり、２番目は（例えばフィアット通貨での）トークン化された費用トランザクションである。

＜変形２＞
上述の例は、マイニング料金が、（他の費用と一緒に）資産保持者により支払われる。これについて要件は存在しない。資産自体によりマイニング料金が支払われる場合、以下の変更が必要である。
・ステップ３００．２０は、２つのトランザクションインプットを生成し、資産発行トランザクションインプット、及びマイニング料金のためのＢＴＣトランザクションインプットである。

＜変形３＞
資産保有者毎に費用トランザクションを生成するのではなく、単一の費用トランザクションが生成され、各個人資産保有者が彼らのインプットを追加する（資産保有者毎に別個のトランザクションではない）。トランザクションアウトプットは、代替経路を通じて通知される、資産保有者毎の額の詳細による相応の費用の合計値である。

このモデルは、単純な分割、及び比較的少数の資産保有者に有効であるが、全ての所有者が支払に合意するときのみトランザクションが有効なので、多くの場合に実用的ではない。資産の観点から、支払が遅延される又は多くの資産保有者によって行われない場合のあることが想定される状況では、最短可能時間内に受信される収入額を最大化するという点で、変形３が好適である。

支払のために使用される実際の変形は、マスタエージェントに埋め込まれ（ハードコードされ）て良い又は別個のルックアップテーブルに置かれて良い所定ルールセットに基づき、マスタエージェントにより制御できる。例えば、ルールは、単純なブールフラグに基づき、どの変形が使用されるべきかを管理して良い、又は、閾所有者数又は任意の他の適切な試験可能な条件を含んで良い。

＜収入を支払う［４００］＞
再び、本例における主要主体は資産である。資産は、それらの所有権に比例して、自身の所有者に収入を支払いたいと望む。
［表４］

＜変形＞
収入が、固有のＢＴＣではなく、トークン化された形式で支払われる場合を検討する。この状況では、トランザクション収入トランザクションは、以下を含むＲｅｄｅｅｍＳｃｒｉｐｔアドレス指定される。
・資産保有者の公開鍵、
・収入分配に関連付けられたメタデータ
＜例示的シナリオ−競走馬＞
本発明の実行可能な実装を説明する目的で、例示的シナリオが以下に提供される。シナリオのための個々のトランザクションシーケンスは、添付の図面の中で提供される。

この説明のためのシナリオでは、ｓｔａｂｌｅは、競走馬の中で、関連する賞金の権利及びｓｔａｂｌｅ料金のような支払義務を維持しながら、株を発行することを選択する。本例では、ｓｔａｂｌｅは５０％の所有権を保持し、一方でＡｌｉｃｅは３０％、Ｂｏｂは２０％を購入する。

契約上の義務として、所有者は、彼らの詳細を発行人（Ｉｓｓｕｒｅ、Ｓｔａｂｌｅ）に登録しなければならない。これは、ビットコイン支払（つまり、ＢＴＣ Ａｄｄｒｅｓｓ）の公開鍵を簡略化し得る。しかしながら、これは、通知のための電子メールアドレス、正式名称、誕生日、住居／職場所在地、納税番号、等も含んで良い。これらのうちの任意のものは、発行人自身の処理要件及び／又は発行人が満たさなければならないと感じ得る又はそう感じない任意の規定に依存して契約上の要件又は選択肢であって良い。

発行人の要望に依存して、取引トークン（つまり、メタデータを含むビットコイントランザクション）は、所有権の全ての転送のために（つまり、「web−of−trust」の状況で）、発行人の署名を要求して良い、又は（本例におけるように）発行人の署名無しで転送されることを許可されて良い。後者の場合、取引の契約条件により、新しい所有者は、彼らの所有権を登録することを、発行人と契約しなければならない（１．１章を参照）。

これらの登録された詳細は、取引自体の中に格納され、（所有権情報のような）変更可能なフィールドを除く取引のハッシュに依存する。事実上、取引に対するハッシュは、取引自体の中で定められる。これは、取引の必ずしも全ての属性がハッシュに含まれる必要がないことを意味する。これは、所有権リストが取引文書の中に保持されることを可能にするが、所有者はハッシュに含まれない。したがって、文書の署名は、文書の所有者が変更されても、不変のままである。

＜取引の概要＞
以下は、これらの条項を実装する２つのエージェントに関する詳細を含む取引の人間により可読なバージョンの選択された強調部分を提示する。

＜発行（Ｉｓｓｕａｎｃｅ）＞
Ｓｔａｂｌｅは、先ず、自身の秘密鍵と共に競走馬を登録する。これは、完全に新しい秘密鍵であって良く、又は以下に実質的に「サブキー生成の方法」と題された章で後述するようなメカニズムを使用して良い。

Ｓｔａｂｌｅは、次に、ＳＴＡＢＬＥ−Ｓ３−Ｔ１（図５を参照）の中にある発行トランザクションの競走馬口座にシード資金を供給する必要がある。

競走馬は、次に、ＲＡＣＥＨＯＲＳＥ−Ｓ３−Ｔ１（図６を参照）で、自身の株を、様々な資産保有者に発行する。取引が、費用が突出する場合に（所有権が直接無効にされないことを意味する）賞金が支払われないことを明言するので、発行トランザクションは、所有者による直接の資産の自由な転送を可能にする。このトランザクションのアウトプット４は、競走馬自体が取引の条項２８を実施可能にすることをカバーするスマートコントラクトを生成する。

＜費用エージェント（Ｃｏｓｔ Ａｇｅｎｔ）（Ｓｔａｂｌｅ料金）＞
２年毎に、ｓｔａｂｌｅ料金の請求を担う費用エージェントが日にちによりトリガされる。費用は、１０００サトシ／株／日（簡単のため、本例は６ヶ月＝１８０日とする）として計算される。

キャッシュフローを向上するために、エージェントは、公開鍵所有者毎に、別個のトランザクションを生成する。ここで、所有者直詳細は現行取引に関連付けられた資産レジストリ（又は発行人自身の私設内部データベース）から取り入れられ、及び現在の株割り当ては（ＵＴＸＯ上の基本ＢＴＣ及び取引で指定されたペギングレートに基づき）ブロックチェーンから取り入れられる。ペギングレートに関する詳細については、以下の「コード化スキーム」に関する章を参照のこと。

エージェントの高レベル処理は、次の通りである。
・Ｏｗｎｅｒｓｈｉｐ Ｒｅｇｉｓｔｒｙ（所有権レジストリ）及び関連ＵＴＸＯから所有権を決定する。
− 本例では、これはＳｔａｂｌｅ−５（ＰｕｂＫ−Ｓｔａｂｌｅ）、Ａｌｉｃｅ−３（ＰｕｂＫ−Ａｌｉｃｅ）、Ｂｏｂ−２（ＰｕｂＫ−Ｂｏｂ）のリストを提供する。
・期間の間の、相応する合計費用を計算する。
− 本例では、これは合計１８０，０００サトシを提供する。
・取引（Ｃｏｎｔｒａｃｔ）から割り当てルールを決定する。
− 本例では、Ａｌｉｃｅ（５４，０００サトシ）及びＢｏｂ（３６，０００サトシ）及びＳｔａｂｌｅ（９０，０００サトシ）のみに課金する。
・支払トランザクションを生成し、（トランザクションインプットが続いて追加されることを可能にするために）いかなるトランザクションインプットもＳＩＧＨＡＳＨ＿ＡＮＹＯＮＥＣＡＮＰＡＹマーカを用いて署名されない。
− 本例では、これは、ＲＡＣＥＨＯＲＳＥ−Ｓ３−Ｔ２及びＲＡＣＥＨＯＲＳＥ−Ｓ３−Ｔ３である。
・支払がブロックチェーン上に公開されるのを待つ。取引自体は、エージェントに、支払が受信されないとき、どのように振る舞うべきかを指示する。例えば、支払が１４日以内に受信されない場合に、リマインダが送信されて良く、６０日後に口座が滞納とマークされる。
・支払が後に受信された場合、更なる収集活動を止めるために、監視エージェントを更新する。

図７は、本例の本態様に関連するトランザクションを示す。ここで、ｓｔａｂｌｅ料金の第１セットは、投資家から請求される必要がある（６ヶ月の価値、１８００００サトシ／株）。金銭がｓｔａｂｌｅに返済されるので、費用トランザクションは、隠れ所有者に生成されもとされない（ｓｔａｂｌｅが自身の株を「隠そう」としていた場合、ブロックチェーン上の公開記録は所有者の間を区別しない）。Ａｌｉｃｅ及びＢｏｂに変化が与えられないので、正しいサイズのトランザクションインプットを生成すると想定されたトランザクションがある（ＡＬＩＣＥ−Ｓ３−Ｔ１及びＢＯＢ−Ｓ３−Ｔ１であると仮定する）。

＜費用の投資家による支払＞
不完全なトランザクションを受信すると、投資家（Ａｌｉｃｅ及びＢｏｂ）は、料金を満たし及び彼らのビットコインウォレットを用いてトランザクションを完成させるために、正しいトランザクションインプットを割り当てる。これは、スタブ（stubbed）トランザクションＲＡＣＥＨＯＲＳＥ−Ｓ３−Ｔ２（Ａｌｉｃｅ）及びＲＡＣＥＨＯＲＳＥ−Ｓ３−Ｔ３（Ｂｏｂ）にトランザクションインプットを追加する（図７を参照）。

＜収入エージェント（Ｉｎｃｏｍｅ Ａｇｅｎｔ）（賞金）＞
競走馬により生じた賞金は、ｓｔａｂｌｅが競馬場からの支払を受信すると、支払われる。状況に依存して、賞金は、ＢＴＣで受信されて良く（例えば、競馬産業がビットコイントランザクションが可能である場合、又は、特定の競馬場がビットコインでの賞金を有効にする、等）、又はフィアット通貨で受信されて良い。後者の場合、ｓｔａｂｌｅは、収入分配ステップを実行する前に、賞金をＢＴＣに変換するステップを実行して良い。

このエージェントの高レベル処理は、次の通りである。
・取引の使用は、この投資についてどのように収入を生じるかを決定する。
− 本例では、レース結果の詳細について、外部ニュースフィードが調べられる。
・資金供給要件について、（取引の中で定められるような）関連パーティと通信する。
− 本例では、彼らが競走馬を代表して競馬場から受信すべき賞金に基づき支払うための請求書を含む電子メールが、Ｓｔａｂｌｅへ送信される。
・Ｏｗｎｅｒｓｈｉｐ Ｒｅｐｏｓｉｔｏｒｙから所有権を決定する。
− 本例では、これはＳｔａｂｌｅ−５（ＰｕｂＫ−Ｓｔａｂｌｅ）、Ａｌｉｃｅ−３（ＰｕｂＫ−Ａｌｉｃｅ）、Ｂｏｂ−２（ＰｕｂＫ−Ｂｏｂ）のリストを提供する。
・収入が関連口座に支払われるのを待つ。
− 本例では、８０ＢＴＣになる£２０，４００の賞金が、競走馬の公開鍵ハッシュ（Ｐｕｂｌｉｃ Ｋｅｙ Ｈａｓｈ）アドレスに支払われる。
・期間の間の、相応する賞金をどのように分けるかを計算する。
− 本例では、これは合計８ＢＴＣ／株を提供する。
・取引（Ｃｏｎｔｒａｃｔ）から割り当てルールを決定する。
− 本例では、Ｓｔａｂｌｅ４０ＢＴＣ、Ａｌｉｃｅ２４ＢＴＣ、及びＢｏｂ１６ＢＴＣである。
・報酬を支払うために支払トランザクションを生成する。

図８は、競走馬がｓｔａｂｌｅ料金をｓｔａｂｌｅに渡すトランザクションを示す。ｓｔａｂｌｅが自身の所有権を秘密に保っていなかった場合、Ｓ３−Ｔ２〜Ｓ３−Ｔ５における競走馬の公開鍵ではなく、単にｓｔａｂｌｅの公開鍵を用いることにより、ｓｔａｂｌｅ料金をｓｔａｂｌｅに直接支払わせることが可能であることに留意する。

本発明と関連して使用され得る他の技術及びメカニズムは、以下に更に詳述される。

＜コード化スキーム＞
ブロックチェーントランザクションの中のメタデータは、種々の方法でフォーマット化できる。しかしながら、１つの可能なコード化スキームがここに記載される。

取引の定める権利が取引の保持者又は所有者に贈与される場合、取引は転送可能である。非転送可能取引の一例は、参加者が指名される取引である。つまり、権利が、取引の保持者ではなく特定の指名されたエンティティに贈与される。転送可能取引だけが、このコード化スキームで議論される。

トークンは、取引により贈与される権利を詳述する又は定める特定取引を表す。トークンは、ビットコイントランザクションの形式の取引の表現である。

このコード化方法は、３つのパラメータ又はデータアイテムを有するメタデータを使用する。このデータは、以下を示し得る：
ｉ）取引の下で利用可能な株の量
（これは、本願明細書で「ＮｕｍＳｈａｒｅｓ」と呼ばれることがある）、
ｉｉ）送り手から少なくとも１つの受け手へ転送されるべき転送単位の量（これは、「ＳｈａｒｅＶａｌ」と呼ばれることがある）、
ｉｉｉ）転送単位の量の値を計算するための因子（これは、「ペギングレート（pegging rate）」と呼ばれることがある）。

このコード化スキームの利点は、上述の３つのパラメータだけを用いて、ブロックチェーン上のトークンとして取引をカプセル化又は表現するために使用できることである。実際に、取引は、これらの３つのデータアイテムのうちの最小限を用いて指定できる。このコード化スキームは任意の種類の転送可能取引のために使用可能なので、共通アルゴリズムが考案され適用され得る。これらのメタデータアイテムの更なる詳細は、以下に提供される。

分割可能トークンは、トランザクションアウトプット上の値が、複数のトークンに渡り（つまり、複数のトランザクションに渡り）割り当てられるより小さな量に細分化され得るものである。典型は、トークン化されたフィアット通貨である。分割可能取引は、非ゼロペギングレート（PeggingRate）を指定する取引として定められる。分割可能取引では、トランザクションアウトプットの中で転送されるトークン化された値は、ペギングレートにより基礎ビットコイン（bitcoin：ＢＴＣ）値に結び付けられる。つまり、取引は、ペギングレートの観点で、保持者の権利を指定する。非分割可能トークンでは、ペギングレートが存在せず、取引は、固定値の観点で、保持者の権利を指定する（例えば、「この取引は、正確に＄１０００で換金できる」という無記名債券、又は「この取引は１ヘアカットと交換可能である」という商品引換券のように）。非」分割可能取引では、基礎トランザクションＢＴＣ値は取引値と無関係である。

表現「基礎ＢＴＣ値」は、トランザクションアウトプットに付加されるビットコイン額（ＢＴＣ）を表す。ビットコインプロトコルでは、各トランザクションアウトプットは、有効と考えられる非ゼロＢＴＣ額を有しなければならない。実際には、ＢＴＣ額は、記述時に現在５４６サトシに設定される設定最小値（「ダスト（dust）」）より大きくなければならい。１ビットコインは、１００百万サトシに等しいと定められる。ビットコイントランザクションは本願明細書では所有権の交換を助ける手段としてのみ使用されるので、実際の基礎ＢＴＣ額は任意である。真の値は、取引仕様の中にある。理論上、全てのトークンは、ダストにより伝達され得る。

本発明のコード化スキームに従い、具体的に、分割可能トークンでは、基礎ＢＴＣ値は次の意味：ペギングレートにより取引値との関係を運ぶ、を有する。ペギングレートは、それ自体任意であり、基礎ＢＴＣ額を小さく保つために選択される。単にダストを有する基礎となる各トークントランザクションではなく、ペギングレートを使用する理由は、本発明のプロトコルが可視性を実現するからである。トークンが幾つかの小さな額のトランザクションアウトプットに分けられるとき、元の取引を調整する必要がない。むしろ、各細分化トークンの取引値は、単に、ペギングレート及び基礎ＢＴＣ値の細分化された額に基づき計算される。

限定トークンは、ＮｕｍＳｈａｒｅｓと呼ばれる量により定められる固定非ゼロの株数により合計発行値が固定された（又は「限定された」）トークンである。したがって、限定取引の下では更なる株は発行されない。例えば、競走馬の共同所有権のための取引は、競走馬の１００％に限定される（例えば、それぞれ１％で１００個の株、又はそれぞれ１０％で１０個の株、等）。非限定取引は、例えば要求額のフィアット通貨を彼らの引当金（Reserve Account）に追加することにより、発行人が株の更なる発行を引き受け可能であることを意味する。ＮｕｍＳｈａｒｅｓは、全ての取引に明示的に記載されなければならない。限定取引は、ＮｕｍＳｈａｒｅｓ＞０を有しなければならない。非限定取引は、ＮｕｍＳｈａｒｅｓ＝０を設定することにより示される。

典型的な例は、準備預金口座に保持される合計値が存在する約束手形（つまり未償還トークン）の合計値に一致するようにする、通貨準備（金準備と類似する）である。この概念は、通貨準備を超えて、在庫ストックにまで拡大する。例えば、認可印刷Ｔシャツトークンの発行人は、１０，０００枚のＴシャツの在庫で開始して良く、これらの１０，０００枚のＴシャツを表す分割可能トークンを発行して良い（ここで、各株＝１枚のＴシャツを表す）。元のトークンは細分化でき、各細分化トークンは、ペギングレートにより定められるトランザクションアウトプットの基礎ＢＴＣ値に従い、Ｔシャツの枚数に償還可能である。しかしながら、需要が増大する場合、発行人は更なる株を発行することを決定して良い（つまり、更に１０，０００枚だけ流通株数を増大する）。このような場合には、更なる発行を引き受けるために、発行人の準備口座（つまり、在庫倉庫）に更に１０，０００枚のＴシャツを預けることが、発行人の義務である。したがって、在庫にあるＴシャツの合計枚数は、常に、合計未償還株数である（ここで、在庫は「準備口座」として作用する）。

ペギングレートは、分割可能取引にのみ適用される。ここで、（ＳｈａｒｅＶａｌと呼ばれる量により表される）株の値は、基礎ＢＴＣ額に固定される。例えば、取引は、発行人が基礎１ＢＴＣ毎に＄１０，０００のレートでトークンを償還することを約束すると指定して良い。これは、（例えば）１５，４００サトシのトークン化された基礎アウトプット値を有するトランザクションが＄１．５４で償還可能であることを意味し得る。ペギングレートについて０の値は、取引が非分割可能であることを示す（つまり、無記名債券のように、全体のみが転送可能である）。ペギングレートが０に設定されると（非分割可能トークンを意味する）、基礎ＢＴＣ値は、取引値と無関係であり、任意の額に設定可能である。通常、この場合には、運用コストを最小化するために、基礎ＢＴＣ額を可能な限り小さく保つ（つまり、ダストに設定する）ことが望ましい。

ＮｕｍＳｈａｒｅｓは、（限定）取引の下で利用可能な合計（固定）株数である。限定取引では、ＮｕｍＳｈａｒｅｓは、ゼロより大きい全体数でなければならない。非限定取引では、いつでも（引き受けられるならば）より多くの株が発行可能なので、ＮｕｍＳｈａｒｅｓは固定されない。これは、値を０に設定することにより示される。

株は、転送単位として定められ、ＳｈａｒｅＶａｌはその単位の値である。例えば、フィアット通貨では、転送単位は１セントに設定されて良い。あるいは、例えば、転送単位は５０セントに設定されて良く、この場合には、転送は５０セントの「ロット」でのみ実行できる。ＳｈａｒｅＶａｌは、パーセンテージとしても表現できる。例えば、ブリーダが競走馬を１０個の等しい株で売りたいと望む場合、ＳｈａｒｅＶａｌ＝０を設定１０％である。ＳｈａｒｅＶａｌは０より大きくなければならず、且つ取引において定められなければならない。

ＴｏｔａｌＩｓｓｕａｎｃｅは、発行された株の合計値を表す。この値は限定取引にのみ関連する。非限定取引については、発行は固定されず、より多くの株が発行されて良い。株がパーセンテージとして表現される場合、定義によりＴｏｔａｌＩｓｓｕａｎｃｅ＝０を設定１００％である。

限定取引では、ＮｕｍＳｈａｒｅｓ、ＳｈａｒｅＶａｌ、及びＴｏｔａｌＩｓｓｕａｎｃｅは、以下のように関連する。

ＮｕｍＳｈａｒｅｓ×ＳｈａｒｅＶａｌ＝ＴｏｔａｌＩｓｓｕａｎｃｅ
ＴｏｔａｌＩｓｓｕａｎｃｅの０の値は、非限定取引であることを意味する。非限定取引の一例は、フィアット通貨である（したがって、ＴｏｔａｌＩｓｓｕａｎｃｅは０に設定される）。限定取引の例は、（ｉ）限定版記念硬貨（１０００個鋳造され、１株＝１硬貨である）、ＴｏｔａｌＩｓｓｕａｎｃｅ＝１０００×１＝１０００個の硬貨、（ｉｉ）入場券のある会場の席、ＴｏｔａｌＩｓｓｕａｎｃｅ＝利用可能な合計席数、である。

流通は、未使用トークンの合計値として定められる（つまり、ＵＴＸＯ（未使用トランザクションアウトプット）の中のトランザクションにより決定される）。全部の未使用トランザクションの完全な集合は、全てのビットコインノードに利用可能なリストの中に保持される。例えば、発行人が最初に＄１０，０００をフィアット通貨型のトークンとして発行し、時間を経て＄５５００の価値のトークンが償還された場合、流通＝＄４５００である（未償還トークンの値である）。この値は、関連する準備口座の差引残高に調整されるべきである。

＜サブキー生成の方法＞
以上では、元の（マスタ）キーからサブキーを生成することが有利である状況を参照した。これが実行され得る１つの方法を説明するために、これを達成する方法が以下に提供される。以下の説明は、図１２〜１８を参照して与えられる。

図１２は、通信ネットワーク５を介して第２ノード７と通信する第１ノード３を含むシステム１を示す。第１ノード３は関連する第１処理装置２３を有し、及び第２ノード５は関連する第２処理装置２７を有する。第１及び第２ノード３、７は、コンピュータ、電話機、タブレットコンピュータ、モバイル通信装置、コンピュータサーバ、等のような電子装置を含んで良い。一例では、第１ノード３はクライアント（ユーザ）装置であって良く、第２ノード７はサーバであって良い。サーバは、デジタルウォレットプロバイダのサーバであって良い。

第１ノード３は、第１ノードマスタ秘密鍵（Ｖ_１Ｃ）及び第１ノードマスタ公開鍵（Ｐ_１Ｃ）を有する第１非対称暗号対に関連付けられる。第２ノード７は、第２ノードマスタ秘密鍵（Ｖ_１Ｓ）及び第２ノードマスタ公開鍵（Ｐ_１Ｓ）を有する第２非対称暗号対に関連付けられる。言い換えると、第１及び第２ノードは、それぞれ、個々の公開−秘密鍵対を保有する。

個々の第１及び第２ノード３、７の第１及び第２非対称暗号対は、ウォレットの登録のような登録処理中に生成されて良い。各ノードの公開鍵は、通信ネットワーク５に渡るように、公に共有されて良い。

第１ノード３及び第２ノード７の両者において共通シークレット（common secret：ＳＣ）を決定するために、ノード３、７は、通信ネットワーク５を介して秘密鍵を通信することなく、それぞれ方法３００、４００のステップを実行する。

第１ノード３により実行される方法３００は、少なくとも第１ノードマスタ秘密鍵（Ｖ_１Ｃ）及び生成器値（Generator Value：ＧＶ）に基づき、第１ノード第２秘密鍵（Ｖ_２Ｃ）を決定するステップ３３０を含む。生成器値は、第１ノードと第２ノードとの間で共有されるメッセージ（Ｍ）に基づいて良い。これは、以下に詳述するように、通信ネットワーク５を介してメッセージを共有するステップを含んで良い。方法３００は、少なくとも第２ノードマスタ公開鍵（Ｐ_１Ｓ）及び生成器値（Generator Value：ＧＶ）に基づき、第２ノード第２公開鍵（Ｐ_２Ｓ）を決定するステップ３７０を更に含む。方法３００は、第１ノード第２秘密鍵（Ｖ_２Ｃ）及び第２ノード第２公開鍵（Ｐ_２Ｓ）に基づき、共通シークレット（common secret：ＣＳ）を決定するステップ３８０を含む。

重要なことに、同じ共通シークレット（ＣＳ）が、方法４００により第２ノード７においても決定できる。方法４００は、第１ノードマスタ公開鍵（Ｐ_１Ｃ）及び生成器値（Generator Value：ＧＶ）に基づき、第１ノード第２公開鍵（Ｐ_２Ｃ）を決定するステップ４３０を含む。方法４００は、第２ノードマスタ秘密鍵（Ｖ_１Ｓ）及び生成器値（Generator Value：ＧＶ）に基づき、第２ノード第２秘密鍵（Ｖ_２Ｓ）を決定するステップ４７０を更に含む。方法４００は、第２ノード第２秘密鍵（Ｖ_２Ｓ）及び第１ノード第２公開鍵（Ｐ_２Ｃ）に基づき、共通シークレット（common secret：ＣＳ）を決定するステップ４８０を含む。

通信ネットワーク５は、ローカルエリアネットワーク、ワイドエリアネットワーク、セルラネットワーク、無線通信ネットワーク、インターネット、等を含んで良い。これらのネットワークでは、データは電気線、光ファイバ、又は無線のような通信媒体を介して送信されて良く、盗聴者１１による様な盗聴を受けやすい場合がある。方法３００、４００は、通信ネットワーク５を介して共通シークレットを送信することなく、第１ノード３及び第２ノード７が共通シークレットを両方とも独立して決定できるようにする。

したがって、１つの利点は、安全でない可能性のある通信ネットワーク５を介して秘密鍵を送信する必要を有しないで、共通シークレット（ＣＳ）が安全に且つ各ノードにより独立して決定できることである。また、共通シークレットは、秘密鍵として（又は秘密鍵の基礎として）使用されて良い。

方法３００、４００は、追加ステップを含んで良い。図１３を参照する。方法３００は、第１ノード３において、メッセージ（Ｍ）及び第１ノード第２秘密鍵（Ｖ_２Ｃ）に基づき、署名メッセージ（ＳＭ１）を生成するステップを含んで良い。方法３００は、第１署名メッセージ（ＳＭ１）を通信ネットワークを介して第２ノード７へ送信するステップ３６０を更に含む。一方、第２ノード７は、第１署名メッセージ（ＳＭ１）を受信するステップ４４０を実行して良い。方法４００は、第１署名メッセージ（ＳＭ２）を第１ノード第２公開鍵（Ｐ２Ｃ）により検証するステップ４５０、及び第１署名メッセージ（ＳＭ１）を検証するステップの結果に基づき第１ノード３を認証するステップ４６０を更に含む。有利なことに、これは、第２ノード７が、（第１署名メッセージが生成された場所である）意図された第１ノードが第１ノード３であることを認証することを可能にする。これは、第１ノード３だけが、第１ノードマスタ秘密鍵（Ｖ_１Ｃ）へのアクセスを有する、したがって、第１ノード３だけが、第１署名メッセージ（ＳＭ１）を生成するための第１ノード第２秘密鍵（Ｖ_２Ｃ）を決定できるという仮定に基づく。理解されるべきことに、同様に、第２署名メッセージ（ＳＭ２）は、第２ノード７において生成され、第１ノード３へ送信され得る。したがって、ピアツーピアシナリオにおけるように、第１ノード３は、第２ノード７を認証できる。

第１ノードと第２ノードの間のメッセージ（Ｍ）の共有は、様々な方法で達成されて良い。一例では、メッセージは、第１ノード３において生成されて良く、次に通信ネットワーク５を介して第２ノード７へ送信される。代替として、メッセージは、第２ノード７において生成されて良く、次に通信ネットワーク５を介して第１ノード３へ送信される。幾つかの例では、メッセージ（Ｍ）は公開されて良く、したがってセキュアでないネットワーク５を介して送信されて良い。１又は複数のメッセージ（Ｍ）は、データストア１３、１７、１９に格納されて良い。当業者は、メッセージの共有が様々な方法で達成できることを理解する。

有利なことに、共通シークレット（ＣＳ）の再生成を可能にするレコードは、そのレコード自体が秘密に格納され又はセキュアに送信される必要がなく、保持され得る。

＜登録の方法１００、２００＞
登録の方法１００、２００の一例は、図１４を参照して記載される。図１４では、方法１００は第１ノード３により実行され、方法２００は第２ノード７により実行される。これは、それぞれ第１ノード３及び第２ノード７のために第１及び第２非対称暗号対を確立するステップを含む。

非対称暗号対は、公開鍵暗号化で使用されるような、関連付けられた秘密鍵及び公開鍵を含む。本例では、非対称暗号対は、楕円曲線暗号システム（Elliptic Curve Cryptography：ＥＣＣ）及び楕円曲線演算の特性を用いて生成される。

方法１００、２００では、これは、共通ＥＣＣシステムに合意している１１０、２１０、且つ基点（Ｇ）を用いる、第１ノード及び第２ノードを含む（注：基点は、共通生成器として参照され得るが、用語「基点」は、生成器値ＧＶとの混同を避けるために使用される）。一例では、共通ＥＣＣシステムは、ビットコインにより使用されるＥＣＣシステムであるｓｅｃｐ２５６Ｋ１に基づいて良い。基点（Ｇ）は、選択され、ランダムに生成され、又は割り当てられて良い。

ここで第１ノード３について考えると、方法１００は、共通ＥＣＣシステム及び基点（Ｇ）を解決するステップ１１０を含む。これは、第２ノード７又は第３ノード９から、共通ＥＣＣシステム及び基点を受信するステップを含んで良い。代替として、ユーザインタフェース１５は、第１ノード３に関連付けられる。これにより、ユーザは、共通ＥＣＣシステム及び／又は基点（Ｇ）を選択的に提供できる。更に別の代替案では、共通ＥＣＣシステム及び／又は基点（Ｇ）の一方又は両方が、第１ノード３によりランダムに選択されて良い。第１ノード３は、通信ネットワーク５を介して、基点（Ｇ）と共に共通ＥＣＣシステムを使用することを示す通知を、第２ノード７へ送信して良い。また、第２ノード７は、共通ＥＣＣシステム及び基点（Ｇ）の使用に対する肯定応答を示す通知を送信することにより、解決して良い２１０。

方法１００は、第１ノード３が、第１ノードマスタ秘密鍵（Ｖ_１Ｃ）及び第１ノードマスタ公開鍵（Ｐ_１Ｃ）を有する第１非対称暗号対を生成するステップ１２０を更に含む。これは、共通ＥＣＣシステムの中で指定された許容範囲の中のランダム整数に少なくとも部分的に基づき、第１マスタ秘密鍵（Ｖ_１Ｃ）を生成するステップを含む。これは、次式に従い第１ノードマスタ秘密鍵（Ｖ_１Ｃ）及び基点（Ｇ）の楕円曲線点乗算に基づき、第１ノードマスタ公開鍵（Ｐ_１Ｃ）を決定するステップを更に含む。
Ｐ_１Ｃ＝Ｖ_１Ｃ×Ｇ （式１）
したがって、第１非対称暗号対は、以下を含む：
Ｖ_１Ｃ：第１ノードにより秘密に保持される第１ノードマスタ秘密鍵。
Ｐ_１Ｃ：公に知らされる第１ノードマスタ公開鍵。

第１ノード３は、第１ノードマスタ秘密鍵（Ｖ_１Ｃ）及び第１ノードマスタ公開鍵（Ｐ_１Ｃ）を、第１ノード３に関連付けられた第１データストア１３に格納して良い。セキュリティのために、第１ノードマスタ秘密鍵（Ｖ_１Ｃ）は、鍵が秘密のままであることを保証するために、第１データストア１３のセキュアな部分に格納されて良い。

方法１００は、図１４に示すように、第１ノードマスタ公開鍵（Ｐ_１Ｃ）を通信ネットワーク５を介して第２ノード７へ送信するステップ１３０を更に含む。第２ノード７は、第１ノードマスタ公開鍵（Ｐ_１Ｃ）を受信すると２２０、第１ノードマスタ公開鍵（Ｐ_１Ｃ）を第２ノード７に関連付けられた第２データストア１７に格納して良い２３０。

第１ノード３と同様に、第２ノード７の方法２００は、第２ノードマスタ秘密鍵（Ｖ_１Ｓ）及び第２ノードマスタ公開鍵（Ｐ_１Ｓ）を有する第２非対称暗号対を生成するステップ２４０を含む。第２ノードマスタ秘密鍵（Ｖ_１Ｓ）も、許容範囲内のランダム整数である。また、第２ノードマスタ公開鍵（Ｐ_１Ｓ）は、次式により決定される。
Ｐ_１Ｓ＝Ｖ_１Ｓ×Ｇ （式２）
したがって、第２非対称暗号対は、以下を含む：
Ｖ_１Ｓ：第２ノードにより秘密に保持される第２ノードマスタ秘密鍵。
Ｐ_１Ｓ：公に知らされる第２ノードマスタ公開鍵。

第２ノード７は、第２非対称暗号対を第２データストア１７に格納して良い。方法２００は、第２ノードマスタ公開鍵（Ｐ_１Ｓ）を第１ノード３へ送信するステップ２５０を更に含む。また、第１ノード３は、第２ノードマスタ公開鍵（Ｐ_１Ｓ）を受信し１４０、格納して良い１５０。

理解されるべきことに、幾つかの代案では、それぞれの公開マスタ鍵は、受信され、（信頼できる第三者のような）第３ノード９に関連付けられた第３データストア１９に格納されて良い。これは、認証機関のような、公開ディレクトリとして動作する第三者を含んで良い。したがって、幾つかの例では、第１ノードマスタ公開鍵（Ｐ_１Ｃ）は、共通シークレット（ＣＳ）が要求されるときだけ、第２ノード７により要求され受信されて良い（逆も同様である）。

登録ステップは、初期設定として１度生じるだけで良い。

＜セッション開始及び第１ノード３による共通シークレットの決定＞
共通シークレット（ＣＳ）を決定する一例は、図１５を参照してここに記載される。共通シークレット（ＣＳ）は、第１ノード３と第２ノード７との間の特定のセッション、時間、トランザクション、又は他の目的のために使用されて良く、同じ共通シークレット（ＣＳ）を使用することが望ましい又はセキュアでなくて良い。したがって、共通シークレット（ＣＳ）は、異なるセッション、時間、トランザクション、等の間で変更されて良い。

以下は、上述したセキュアな送信技術の説明のために提供される。

［メッセージ（Ｍ）を生成する３１０］
本例では、第１ノード３により実行される方法３００は、メッセージ（Ｍ）を生成するステップ３１０を含む。メッセージ（Ｍ）は、ランダム、疑似ランダム、又はユーザ定義であって良い。一例では、メッセージ（Ｍ）は、Ｕｎｉｘ時間又はノンス（及び任意の値）に基づく。例えば、メッセージ（Ｍ）は次のように与えられ得る。

メッセージ（Ｍ）＝Ｕｎｉｘ時間＋ノンス （式３）
幾つかの例では、メッセージ（Ｍ）は任意である。しかしながら、理解されるべきことに、メッセージ（Ｍ）は、幾つかのアプリケーションで有用であり得る（Ｕｎｉｘ時間、等のような）選択的値を有して良い。

方法３００は、メッセージ（Ｍ）を通信ネットワーク５を介して第２ノード７へ送信するステップ３１５を含む。メッセージ（Ｍ）は秘密鍵についての情報を含まないので、メッセージ（Ｍ）は、セキュアでないネットワークを介して送信されて良い。

［生成器値（ＧＶ）を決定する３２０］
方法３００は、メッセージ（Ｍ）に基づき生成器値（Generator Value：ＧＶ）を決定するステップ３２０を更に含む。本例では、これは、メッセージの暗号ハッシュを決定するステップを含む。暗号ハッシュアルゴリズムの一例は、２５６ビット発生器値（ＧＶ）を生成するためにＳＨＡ−２５６を含む。つまり、
ＧＶ＝ＳＨＡ−２５６（Ｍ） （式４）
理解されるべきことに、他のハッシュアルゴリズムが使用されて良い。これは、セキュアなハッシュアルゴリズム（Secure Hash Algorithm：ＳＨＡ）ファミリの中の他のハッシュアルゴリズムを含んで良い。幾つかの特定の例は、ＳＨＡ３−２２４、ＳＨＡ３−２５６、ＳＨＡ３−３８４、ＳＨＡ３−５１２、ＳＨＡＫＥ１２８、ＳＨＡＫＥ２５６を含むＳＨＡ−３サブセットの中のインスタンスを含む。他のハッシュアルゴリズムは、ＲＩＰＥＭＤ（RACE Integrity Primitives Evaluation Message Digest）ファミリの中のアルゴリズムを含んで良い。特定の例は、ＲＩＰＥＭＤ−１６０を含んで良い。他のハッシュ関数は、Ｚｅｍｏｒ−Ｔｉｌｌｉｃｈハッシュ関数及びナップサック・ハッシュ関数に基づくファミリを含んで良い。

［第１ノード第２秘密鍵を決定する３３０］
方法３００は、次に、第２ノードマスタ秘密鍵（Ｖ_１Ｃ）及び生成器値（ＧＶ）に基づき、第１ノード第２秘密鍵（Ｖ_２Ｃ）を決定するステップ３３０を含む。これは、次式に従い第１ノードマスタ秘密鍵（Ｖ_１Ｃ）及び生成器値（ＧＶ）のスカラ加算に基づき得る。
Ｖ_２Ｃ＝Ｖ_１Ｃ＋ＧＶ （式５）
したがって、第１ノード第２秘密鍵（Ｖ_２Ｃ）は、ランダム値ではないが、代わりに第１ノードマスタ秘密鍵から確定的に導出される。暗号対の中の対応する公開鍵、つまり第１ノード第２公開鍵（Ｐ_２Ｃ）は、以下の関係を有する。
Ｐ_２Ｃ＝Ｖ_２Ｃ×Ｇ （式６）
式５から式６にＶ_２Ｃを代入すると、次式を得る。
Ｐ_２Ｃ＝（Ｖ_１Ｃ＋ＧＶ）×Ｇ （式７）
ここで、「＋」演算子は楕円曲線点加算を表す。楕円曲線暗号代数は、分配的であり、式７は次式のように表すことができる。
Ｐ_２Ｃ＝Ｖ_１Ｃ×Ｇ＋ＧＶ×Ｇ （式８）
最後に、（式１）は（式７）に代入され、次式を得る。
Ｐ_２Ｃ＝Ｐ_１Ｃ＋ＧＶ×Ｇ （式９．１）
Ｐ_２Ｃ＝Ｐ_１Ｃ＋ＳＨＡ−２５６（Ｍ）×Ｇ （式９．２）
したがって、対応する第１ノード第２公開鍵（Ｐ_２Ｃ）は、第１ノードマスタ公開鍵（Ｐ_１Ｃ）及びメッセージ（Ｍ）の導出可能な所与の知識であり得る。方法４００に関して以下に更に詳述するように、第２ノード７は、第１ノード第２公開鍵（Ｐ_２Ｃ）を独立に決定するために、このような知識を有して良い。

［メッセージ及び第１ノード第２秘密鍵に基づき、第１署名メッセージ（ＳＭ１）を生成する３５０］
方法３００は、メッセージ（Ｍ）及び決定した第１ノード第２秘密鍵（Ｖ_２Ｃ）に基づき、第１署名メッセージ（ＳＭ１）を生成するステップ３５０を更に含む。署名メッセージを生成するステップは、メッセージ（Ｍ）にデジタル方式で署名するために、デジタル署名アルゴリズムを適用するステップを含む。一例では、これは、第１署名メッセージ（ＳＭ１）を得るために、楕円曲線デジタル署名アルゴリズム（Elliptic Curve Digital Signature Algorithm：ＥＣＤＳＡ）の中でメッセージに第１ノード第２秘密鍵（Ｖ_２Ｃ）を適用するステップを含む。ＥＣＤＳＡの例は、ｓｅｃｐ２５６ｋ１、ｓｅｃｐ２５６ｒ１、ｓｅｃｐ３８４ｒ１、ｓｅ３ｃｐ５２１ｒ１を有するＥＣＣシステムに基づくものを含む。

第１署名メッセージ（ＳＭ１）は、第２ノード７において対応する第１ノード第２公開鍵（Ｐ_２Ｃ）により検証できる。第１署名メッセージ（ＳＭ１）のこの検証は、第１ノード３を認証するために第２ノード７により使用されて良い。これは、方法４００において以下に議論される。

［第２ノード第２公開鍵を決定する３７０’］
第１ノード３は、次に、第２ノード第２公開鍵（Ｐ_２Ｓ）を決定して良い３７０。上述のように、第２ノード第２公開鍵（Ｐ_２Ｓ）は、少なくとも第２ノードマスタ公開鍵（Ｐ_１Ｓ）及び生成器値（ＧＶ）に基づいて良い。本例では、公開鍵は、基点（Ｇ）との楕円曲線点乗算により秘密鍵として決定されるので３７０’、第２ノード第２公開鍵（Ｐ_２Ｓ）は、式６と同様に次のように表すことができる。
Ｐ_２Ｓ＝Ｖ_２Ｓ×Ｇ （式１０．１）
Ｐ_２Ｓ＝Ｐ_１Ｓ＋ＧＶ×Ｇ （式１０．２）
式１０．２の数学的証明は、第１ノード第２公開鍵（Ｐ_２Ｃ）について式９．１を導出するために上述したものと同じである。理解されるべきことに、第１ノード３は、第２ノード７と独立に第２ノード第２公開鍵を決定できる３７０。

［第１ノード３において共通シークレットを決定する３８０］
第１ノード３は、次に、第１ノード第２秘密鍵（Ｖ_２Ｃ）及び決定した第２ノード第２公開鍵（Ｐ_２Ｓ）に基づき、共通シークレット（ＣＳ）を決定して良い３８０。共通シークレット（ＣＳ）は、第１ノード３により次式により決定されて良い。
Ｓ＝Ｖ_２Ｃ×Ｐ_２Ｓ （式１１）
＜第２ノード７において実行される方法４００＞
第２ノード７において実行される対応する方法４００が、ここで説明される。理解されるべきことに、これらのステップのうちの幾つかは、第１ノード３により実行された上述のステップと同様である。

方法４００は、メッセージ（Ｍ）を通信ネットワーク５を介して第１ノード３から受信するステップ４１０を含む。これは、ステップ３１５において第１ノード３により送信されたメッセージ（Ｍ）を含んで良い。第２ノード７は、次に、メッセージ（Ｍ）に基づき生成器値（ＧＶ）を決定する４２０。第２ノード７により生成器値（ＧＶ）を決定するステップ４２０は、上述の第１ノードにより実行されるステップ３２０と同様である。本例では、第２ノード７は、第１ノード３と独立の、この決定するステップ４２０を実行する。

次のステップは、第１ノードマスタ公開鍵（Ｐ_１Ｃ）及び生成器値（ＧＶ）に基づき、第１ノード第２公開鍵（Ｐ_２Ｃ）を決定するステップ４３０を含む。本例では、公開鍵は、基点（Ｇ）との楕円曲線点乗算により秘密鍵として決定されるので４３０’、第１ノード第２公開鍵（Ｐ_２Ｃ）は、式９と同様に次のように表すことができる。
Ｐ_２Ｃ＝Ｖ_２Ｃ×Ｇ （式１２.１）
Ｐ_２Ｃ＝Ｐ_１Ｃ＋ＧＶ×Ｇ （式１２．２）
式１２．１及び１２．２の数学的証明は、式１０．１及び１０．２について上述したものと同じである。

［第２ノード７が第１ノード３を認証する］
方法４００は、未確認第１ノード３が第１ノード３であることを認証するために、第２ノード７により実行されるステップを含んで良い。上述のように、これは、第１ノード３から第１署名メッセージ（ＳＭ１）を受信するステップ４４０を含む。第２ノード７は、次に、ステップ４３０で決定された第１ノード第２公開鍵（Ｐ_２Ｃ）により第１署名メッセージ（ＳＭ１）の署名を検証して良い４５０。

デジタル署名の検証は、上述の楕円曲線デジタル署名アルゴリズム（Elliptic Curve Digital Signature Algorithm：ＥＣＤＳＡ）に従い行われて良い。重要なことに、第１ノード第２秘密鍵（Ｖ_２Ｃ）により署名された第１署名メッセージ（ＳＭ１）は、Ｖ_２Ｃ及びＰ_２Ｃが暗号対を形成するので、対応する第１ノード第２公開鍵（Ｐ_２Ｃ）によってのみ正しく検証されるべきである。これらの鍵は、第１ノード３の登録で生成された第１ノードマスタ秘密鍵（Ｖ_１Ｃ）及び第１ノードマスタ公開鍵（Ｐ_１Ｃ）において確定するので、第１署名メッセージ（ＳＭ１）の検証は、第１署名メッセージ（ＳＭ１）を送信する未確認第１ノードが登録中と同じ第１ノード３であることを認証する基礎として使用できる。したがって、第２ノード７は、第１署名メッセージを検証するステップ（４５０）の結果に基づき、第１ノード３を認証するステップ（４６０）を更に実行して良い（図１６を参照）。

［第２ノード７が共通シークレットを決定する］
方法４００は、第２ノード７が、第２ノードマスタ秘密鍵（Ｖ_１Ｓ）及び生成器値（ＧＶ）に基づき、第２ノード第２秘密鍵（Ｖ_２Ｓ）を決定するステップ４７０を更に含んで良い。第１ノード３により実行されるステップ３３０と同様に、第２ノード第２秘密鍵（Ｖ_２Ｓ）は、次式に従い、第２ノードマスタ秘密鍵（Ｖ_１Ｓ）及び生成器値（ＧＶ）のスカラ加算に基づき得る。
Ｖ_２Ｓ＝Ｖ_１Ｓ＋ＧＶ （式１３．１）
Ｖ_２Ｓ＝Ｖ_１Ｓ＋ＳＨＡ−２５６（Ｍ） （式１３．２）
第２ノード７は、次に、第１ノード３と独立して、次式に基づき、第２ノード第２秘密鍵（Ｖ_２Ｓ）及び第１ノード第２公開鍵（Ｐ_２Ｃ）に基づき、共通シークレット（ＣＳ）を決定して良い４８０。
Ｓ＝Ｖ_２Ｓ×Ｐ_２Ｃ （式１４）
［第１ノード３及び第２ノード７により決定された共通シークレット（ＣＳ）の証明］
第１ノード３により決定された共通シークレット（ＣＳ）は、第２ノード７において決定された共通シークレット（ＣＳ）と同じである。式１１及び式１４が同じ共通シークレット（ＣＳ）を提供することの数学的証明が、ここで記載される。

第１ノード３により決定された共通シークレット（ＣＳ）を考えると、次のように式１０．１は式１１に代入できる。
Ｓ＝Ｖ_２Ｃ×Ｐ_２Ｓ （式１１）
Ｓ＝Ｖ_２Ｃ×（Ｖ_２Ｓ×Ｇ）
Ｓ＝（Ｖ_２Ｃ×Ｖ_２Ｓ）×Ｇ （式１５）
第２ノード７により決定された共通シークレット（ＣＳ）を考えると、次のように式１２．１は式１４に代入できる。
Ｓ＝Ｖ_２Ｓ×Ｐ_２Ｃ （式１４）
Ｓ＝Ｖ_２Ｓ×（Ｖ_２Ｃ×Ｇ）
Ｓ＝（Ｖ_２Ｓ×Ｖ_２Ｃ）×Ｇ （式１６）
ＥＣＣ代数学は可換性なので、次の通り式１５及び式１６は等価である。
Ｓ＝（Ｖ_２Ｃ×Ｖ_２Ｓ）×Ｇ＝（Ｖ_２Ｓ×Ｖ_２Ｃ）×Ｇ （式１７）
［共通シークレット（ＣＳ）及び秘密鍵］
共通シークレット（ＣＳ）は、ここで、第１ノード３と第２ノード７との間のセキュアな通信のために、対称鍵アルゴリズムにおいて、秘密鍵として又は秘密鍵の基礎として、使用できる。

共通シークレット（ＣＳ）は、楕円曲線点（ｘ_Ｓ，ｙ_Ｓ）の形式であって良い。これは、ノード３、７により合意された標準的な公に知られた演算を用いて、標準的な鍵フォーマットに変換されて良い。例えば、ｘ_Ｓ値は、ＡＥＳ_２５６暗号鍵として使用され得る２５６ビットの整数であって良い。これは、更に、１６０ビットの長さの鍵を必要とする任意のアプリケーションのために、ＲＩＰＥＭＤ１６０を用いて１６０ビットの整数に変換され得る。

共通シークレット（ＣＳ）は、必要に応じて決定されて良い。重要なことに、共通シークレット（ＣＳ）はメッセージ（Ｍ）に基づき再決定できるので、第１ノード３は共通シークレット（ＣＳ）を格納する必要がない。幾つかの例では、使用されるメッセージ（Ｍ）は、マスタ秘密鍵のために要求されるのと同レベルのセキュリティを有しないデータストア１３、１７、１９（又は他のデータストア）に格納されて良い。幾つかの例では、メッセージ（Ｍ）は公に利用可能であって良い。

しかしながら、幾つかのアプリケーションに依存して、共通シークレット（ＣＳ）が第１ノードマスタ秘密鍵（Ｖ_１Ｃ）と同じくらいセキュアに保たれるならば、共通シークレット（ＣＳ）は、第１ノードに関連付けられた第１データストア（Ｘ）に格納され得る。

有利なことに、この技術は、単一のマスタキー暗号対に基づき、複数のセキュアな秘密鍵に対応し得る複数の共通シークレットを決定するために使用できる。

＜生成器値（鍵）の階層構造＞
例えば、一連の連続する生成器値（ＧＶ）が決定されて良い。ここで、各連続ＧＶは、前の生成器値（ＧＶ）に基づき決定されて良い。例えば、連続する専用鍵を生成するためにステップ３１０〜３７０、４１０〜４７０を繰り返す代わりに、ノード間の事前合意により、生成器値の階層構造を確立するために、前に使用された生成器値（ＧＶ）が両方のパーティにより繰り返し再ハッシュされ得る。実際に、メッセージ（Ｍ）のハッシュに基づく生成器値は、次世代生成器値（ＧＶ’）のための次世代メッセージ（Ｍ’）になり得る。これを行うことは、計算されるべき共有シークレットの連続生成を可能にし、更なるプロトコルにより確立される送信、特に共通シークレットを生成する毎に複数のメッセージの送信の必要がない。次世代共通シークレット（ＣＳ’）は、以下のように計算できる。

先ず、第１ノード３及び第２ノード７の両者が、次世代生成器値（ＧＶ’）を独立して決定する。これは、ステップ３２０及び４２０と同様であるが、次式により適応される。
Ｍ’＝ＳＨＡ−２５６（Ｍ） （式１８）
ＧＶ’＝ＳＨＡ−２５６（Ｍ’） （式１９．１）
ＧＶ’＝ＳＨＡ−２５６（ＳＨＡ−２５６（Ｍ）） （式・１９．２）
第１ノード３は、次に、次世代の第２ノード第２公開鍵（Ｐ_２Ｓ’）及び第１ノード第２秘密鍵（Ｖ_２Ｃ’）を上述のステップ３７０及び３３０と同様であるが次式により適応され、決定して良い。
Ｐ_２Ｓ’＝Ｐ_１Ｓ＋ＧＶ’×Ｇ （式２０．１）
Ｖ_２Ｃ’＝Ｖ_１Ｃ＋ＧＶ’ （式２０．２）
第２ノード７は、次に、次世代の第１ノード第２公開鍵（Ｐ_２Ｃ’）及び第２ノード第２秘密鍵（Ｖ_２Ｓ’）を上述のステップ４３０及び４７０と同様であるが次式により適応され、決定して良い。
Ｐ_２Ｃ’＝Ｐ_１Ｃ＋ＧＶ’×Ｇ （式２１．１）
Ｖ_２Ｓ’＝Ｖ_１Ｓ＋ＧＶ’ （式２１．２）
第１ノード３及び第２ノード７は、次に、それぞれ、次世代共通シークレット（ＣＳ’）を決定して良い。特に、第１ノード３は、次式により次世代共通シークレット（ＣＳ’）を決定する。
ＣＳ’＝Ｖ_２Ｃ’×Ｐ_２Ｓ’ （式２２）
第２ノード７は、次式により次世代共通シークレット（ＣＳ’）を決定する。
ＣＳ’＝Ｖ_２Ｓ’×Ｐ_２Ｃ’ （式２３）
更なる世代（ＣＳ’’、ＣＳ’’’、等）は、チェーン階層構造を生成するために同じ方法で計算できる。この技術は、第１ノード３及び第２ノード７の両者が元のメッセージ（Ｍ）又は最初に計算された生成器値（ＧＶ）、及びそれがどのノードに関連するか、を見失わないことを要求する。これは公に知られた情報なので、この情報の保有に関してセキュリティ問題は存在しない。したがって、この情報は、（ハッシュ値を公開鍵にリンクする）「ハッシュテーブル」に保持され、（例えばＴｏｒｒｅｎｔを用いて）ネットワーク５に渡り自由に配布されて良い。さらに、階層構造内の任意の個々の共通シークレット（ＣＳ）が今までに解決されていない場合、これは、秘密鍵Ｖ_１Ｃ、Ｖ_１Ｓがセキュアなままであるならば、階層構造の中の任意の他の共通シークレットのセキュリティに影響しない。

＜鍵の木構造＞
上述のようなチェーン（線形）階層構造と同様に、木構造の形式の階層構造が生成できる。木構造によると、認証鍵、暗号鍵、署名鍵、支払鍵、等のような異なる目的の様々な鍵が決定されて良い。それにより、これらの鍵は、全て単一のセキュアに維持されるマスタキーにリンクされる。これは、種々の異なる鍵を有する木構造９０１を示す図１７に図示される。これらの各々は、別のパーティと共有されるシークレットを生成するために使用できる。枝分かれする木は、幾つかの方法で達成でき、それらのうちの３つが以下に記載される。

（ｉ）マスタキー・スポーニング
チェーン階層構造では、乗算した再ハッシュしたメッセージを元のマスタキーに加算することにより、各々の新しい「リンク」（公開／秘密鍵ペア）が生成される。例えば（明確性のため、第１ノード３の秘密鍵のみを示す）、
Ｖ_２Ｃ＝Ｖ_１Ｃ＋ＳＨＡ−２５６（Ｍ） （式２４）
Ｖ_２Ｃ’＝Ｖ_１Ｃ＋ＳＨＡ−２５６（ＳＨＡ−２５６（Ｍ）） （式２５）
Ｖ_２Ｃ’’＝Ｖ_１Ｃ＋ＳＨＡ−２５６（ＳＨＡ−２５６（ＳＨＡ−２５６（Ｍ））） （式２６）
等である。

枝を生成するために、任意の鍵がサブマスタキーとして使用できる。例えば、Ｖ_２Ｃ’は、正規のマスタキーに対して行われるように、ハッシュを加算することにより、サブマスタキー（Ｖ_３Ｃ）として使用できる。
Ｖ_３Ｃ＝Ｖ_２Ｃ’＋ＳＨＡ−２５６（Ｍ） （式２７）
サブマスタキー（Ｖ_３Ｃ）は、それ自体が、次世代鍵（Ｖ_３Ｃ’）を有して良い。例えば次式の通りである。
Ｖ_３Ｃ’＝Ｖ_２Ｃ’＋ＳＨＡ−２５６（ＳＨＡ−２５６（Ｍ）） （式２８）
これは、図１８に示すマスタキー・スポーニング（spawning）方法を用いて、木構造９０３を提供する。

（ｉｉ）論理的関連付け
この方法では、木の中の全てのノード（公開／秘密鍵ペア）は、チェーンとして（又は任意の他の方法で）生成され、木の中のノード間の論理的関係は、ポインタを用いて木の中の各ノードが木の中の自身の親ノードに単純に関連付けられるテーブルにより維持される。したがって、ポインタは、セッションの共通シークレットキー（ＣＳ）を決定するために、関連する公開／秘密鍵ペアを決定するために使用できる。

（ｉｉｉ）メッセージ多様性
新しい公開／秘密鍵ペアは、チェーン又は木の任意のポイントに新しいメッセージを導入することにより、生成できる。メッセージ自体は、任意であって良く、又は何らかの意味若しくは関数を伝達して良い（例えば、それは、「現実の」銀行口座番号に関連して良い、等である）。新しい公開／秘密鍵ペアを形成するためのこのような新しいメッセージがセキュアに保持されることが望ましい場合がある。

＜本発明と共に使用するための説明のための計算エージェント＞
本発明は、取引処理の自動化された態様を実行するために、計算リソース又はエージェントを利用できる。適切なエージェントの一例が以下に提供されるが、他の実装が使用されて良い。

エージェントは、チューリング（Turing）機械の実装において非消去可能テープとしてブロックチェーンを使用して、ブロックチェーンと連携して動作して良い。このエージェントは、ブロックチェーンネットワークと並列に実行し、（ループ）処理の実行を監督し及び扱う。ループ処理は、例えば装置又はシステムの処理又は制御の自動化のような所与のタスクを実行するよう設計される。この並列リソースは、ブロックチェーンの状態を監視し、トランザクションをブロックチェーンに書き込ませることができる。ある意味で、これは、ブロックチェーンをチューリング機械の非消去可能テープとして利用し、以下の定義及び特徴を有する。
１．ブロックチェーンは、チューリング機械のテープとして作用する。ブロックチェーンの中の各トランザクションは、テープ上のセルを表す。このセルは、有限なアルファベットからの記号を含み得る。
２．テープヘッドは、ブロックチェーン上に既に書き込まれているブロックから情報を読み出すことができる。
３．テープヘッドは、多くのトランザクションを含む新しいブロックを、ブロックチェーンの終わりに書き込むことができる。しかしながら、それらは、既に存在するブロックに書き込むことができない、このように、ブロックチェーンテープは非消去可能である。
４．各トランザクションのマルチシグネチャのＰ２ＳＨ（pay−to−script−hash）トランザクションの部分として格納され得る。

エージェントに重要な機能は、ブロックチェーンの現在状態を監視する自動エンティティとして作用することである。これは更に、任意のオフブロックソースから、信号又は入力を受信できる。ブロックチェーン状態及び／又は受信した入力に依存して、エージェントは特定動作を実行して良い。エージェントは、どの動作が実行されるべきかを決定する。これらは、「現実世界」（つまり、オフブロック）の中の作用、及び／又（新しいトランザクションを生成する及びブロードキャストするような）はブロックチェーンに対する作用を含んで良く又は含まなくて良い。エージェントが取る作用は、ブロックチェーン状態によりトリガされて良い。エージェントは、更に、ビットコインネットワークにブロードキャストされるべき次のトランザクションセットについて決定し、後にブロックチェーンに書き込んで良い。

エージェントの作用は、並列に且つ同時にブロックチェーン（例えば、ビットコイン）ネットワークに対して実行する。ある意味で、これは、ブロックチェーン（例えば、ビットコイン）スクリプトの機能を格納する。この連続監視は、結合されたエージェント及びブロックチェーンシステムチューリング完全（Turing Complete）を作成する「ループ」制御フロー構成を実施する。

チューリング機械は、以下の２つのスタックを含む。
・データスタック：これは、上述のようにブロックチェーンにより表される。
・制御スタック：これは、エージェント機能により表される。これは、繰り返し制御フロー機能に関連する情報を格納する。

制御スタックのデータスタックからの分離は、無限ループがビットコイン中核で生じることを防ぎ、サービス拒否攻撃を軽減するという利点を提供する。

エージェントは、任意の種類のループ構成（例えば、ＦＯＲ−ＮＥＸＴ、ＲＥＰＥＡＴ ＵＮＴＩＬ、等）によりループ可能なサブルーチンを管理し及び実行する。本願明細書に記載の説明のための実施形態は、「繰り返し（ｒｅｐｅａｔ）」構成の一例を用いる処理を含む。ユーザは、インデックス（ｉ）及び限界（Ｊ）を指定して良い。これらはそれぞれ、現在の反復番号（標準的に０から開始してカウントされる）、及び繰り返しループの合計反復数、を表す。

各反復について、
１．インデックスが１だけ増大する。終了条件については、インデックスが限界に達すると、反復は停止する。
２．「if condition then action（［条件］ならば［動作］する）」（ＩＣＴＡ）文を含むコードブロックが実行される。動作は、ブロックチェーン上の又は外の任意の動作であって良い。
３．このサブルーチンの暗号ハッシュが計算される。これは、トランザクションの部分としてブロックチェーンに格納できる。ハッシュは各コードにユニークなので、どのコードが使用されているかの検証を可能にする。

ループ本体は、コードブロックを含む。各コードブロックは、「if condition then action（［条件］ならば［動作］する）」（ＩＣＴＡ）文を含む。これは、以下に一致するトランザクションについて、ブロックチェーンの現在状態を監視する。
・開始又はトリガ条件（例えば、特定日に達したとき）、
・繰り返し条件（つまり、前の反復に関連付けられたメタデータ又はハッシュ）、
・停止条件（つまり、ループの最後の反復）。

ＩＣＴＡ文は、エージェントが、ブロックチェーンの現在状態に基づき、次のトランザクションについて決定することを可能にする。次のトランザクションを生成することは、トランザクションをビットコインネットワークにブロードキャストすること、及び新しいトランザクションをブロックチェーンに書き込むことを含む。これは、この反復が実行されたことの記録として作用する。トランザクションがブロックチェーンに書き込まれると、マネジャは、続いて、前の反復が実行されブロックチェーンに書き込まれたことを知り、次の反復を実行するだろう。後者は、インデックス（ｉ）がコードブロックの中で指定された限度（Ｊ）に達するとき、繰り返しループが存在するまで継続する。

各トランザクションは、再利用可能な方法で、ブロックチェーンに保存される。ビットコイン実装では、トランザクションの中の各署名は、ＳＩＧＨＡＳＨフラグを付加される。このフラグは、異なる値を取ることができる。これらの値の各々は、この署名の所有者の関与無しに、トランザクションの他の部分が変更され得るか否かを示す。再利用可能トランザクションは、トランザクションインプットのうちの１つの中にＳＩＧＨＡＳＨフラグ「ＳｉｇＨａｓｈ＿ＡｎｙｏｎｅＣａｎＰａｙ」を有する。これは、誰もがトランザクションのインプットに貢献することを許容する。このパラメータは、エージェントのＩＣＴＡ関数が、複数回、異なるインプットで、実行され且つ繰り返されることを可能にする。この関数の使用は、例えば再利用トランザクションの複製により、認可パーティに制限できる。

ＩＣＴＡコードブロックの「If condition」部分は、任意の種類の条件を監視できる。これは、他のプログラミング言語（例えば、Ｃ、Ｃ＋＋、Ｊａｖｅ）と同様であり、ブロックチェーンに格納された情報に限定されない。例えば、これは、日付及び時間（つまり、特定の日時に達したとき）を監視し、又は天気（つまり、気温が１０℃より低く且つ雨が降っているとき）を監視し、取引又は信用の条件（つまり、企業Ａが企業Ｂを買うとき）を監視し得る。

ＩＣＴＡコードブロックの「Then action」部分は、多数の動作を実行できる。本発明は、取り得る動作の数又は種類に関して限定されない。動作は、ブロックチェーン上のトランザクションに限定されないが、動作に関連するメタデータを含むトランザクションは、ブロックチェーンに書き込まれて良い。

メタデータは、任意の形式であり得る。しかしながら、一実施形態では、メタデータは、動作に関連するより多くのデータ又は指示を含むファイルへのハイパーリンクを格納して良い。メタデータは、動作に関連するより多くのデータ又は指示を含むハッシュテーブルへのハイパーリンク、及びハッシュテーブルに対する検索キーとして作用する動作のハッシュの両方を格納して良い。

エージェントの制御スタックは、各ユーザの必要に特化した多数の方法で実装できる。例えば、制御スタックの繰り返しループは、任意のチューリング完全言語に基づき得る。言語の１つの可能な選択は、Ｆｏｒｔｈ型スタックに基づく言語である。この言語を使用する利点は、制御スタックを、既知であり且つ広く使用されているビットコインスクリプトとプログラミング型において一貫性を保つことである。

＜ビットコインスクリプトの交互形式スタック（Alternate Stack）をデータ記憶空間として使用する＞
ビットコインスクリプトは、コマンド、更に呼び出されるオペコード、を含む。これらは、ユーザが、データを「ａｌｔ ｓｔａｃｋ」として知られる交互形式スタックに移動させることを可能にする。

オペコードは、次の通りである。
・ＯＰ＿ＴＯＡＬＴＳＴＡＣＫ。これは、データを主スタックの最上部からａｌｔ ｓｔａｃｋの最上部に移動させる。
・ＯＰ＿ＦＲＯＭＡＬＴＳＴＡＣＫ。これは、データをａｌｔ ｓｔａｃｋの最上部から主スタックの最上部に移動させる。

これは、計算機にデータを格納させる「記憶（memory）」機能と同様に、中間計算ステップからのデータをａｌｔ ｓｔａｃｋに格納させる。一実施形態では、ａｌｔ ｓｔａｃｋは、小さな計算タスクを解決するようビットコインスクリプトを構成するために、及び結果を計算に返すために、使用される。

＜エージェントを管理するためにコードレジスタを使用する＞
エージェントは、また、自身の所有し且つ実行する全てのコードのレジストリを管理する。このレジストリは、特定キーを特定値にマッピングするルックアップテーブル又は辞書のように構造化される。キー及び値ペアは、それぞれ、コードブロックのハッシュ（Ｈ_１）及びコードが格納された場所のＩＰｖ６アドレスにより表される。キーＨ_１を用いてコードブロックを読み出すために、ルックアップテーブルが使用されて、関連する値（これは、コードの格納されている場所である）を読み出し、及びそれに応じてソースコードを読み出す。コードレジストリの実装は変化し得る。

＜エージェントのコードのトランザクションメタデータ、及びループの再スポーニング＞
特定の反復でエージェントのループを再スポーニングするために必要な情報は、ブロックチェーンに記録されたトランザクションの中にメタデータとして格納される。

このように、ブロックチェーン上のトランザクションは、エージェント上で実行されているループの所与の反復に関する情報を格納し、又はそれへのアクセスを提供する。この情報は、ループに関連付けられた任意の変数の値、例えばインデックスｉ、及び任意の他の必要な情報、例えばコードブロック内で使用されるパラメータの値又は更に要求される情報がアクセス可能な場所の位置関連データ、を含み得る。

メタデータ自体は、トランザクションの中のマルチシグネチャのＰ２ＳＨ（pay−to−script−hash）スクリプトの部分として格納される。トランザクションと共に記録されたメタデータは、コードが過去にどのように実行されたかのオーディットトレイルを記録する能力も与える。

エージェントが各反復で繰り返しループコードブロックを再スポーニングできる幾つかの方法が存在する。コードブロックは、エージェント自体にハードコードされて良く、又は秘密に若しくは公に利用可能なファイルに格納でき、又は、秘密若しくは公開ハッシュテーブルファイル上のエントリとして格納され得る、又はこれらの組み合わせである。コードブロックは、ハードコードされた変数に固定され、又は固定であるが、移植可能なパラメータを含み得る。パラメータは、任意のデータフォーマットの単一値であって良く、又は小さなコードチャンクであって良く、又はそれらの組み合わせであって良い。パラメータは、トランザクション（例えば、ビットコイントランザクション）の中のメタデータから、又は内部データベース又は秘密／公開ファイル又はハッシュテーブル又はこれらの任意の組み合わせのような外部ソースから、直接に該パラメータを読み出すことにより移植され得る。パラメータ値の外部ソースへのポインタは、トランザクションの中のメタデータに格納されて良い。

以下のステップは、エージェントがｉ番目の反復で繰り返しループコードブロックをどのように再スポーニングできるかの一例を提供する。本例では、コードレジストリは、ハッシュテーブルである。これにより、ハッシュ値がテーブルの検索キーとして作用し、トランザクション上のメタデータに格納される。
１．エージェントは、コードレジストリ内のエントリに一致するコードブロックのハッシュを含むトランザクションについて、ブロックチェーンを監視する。
２．エージェントは、対応するハッシュ（Ｈ_１）を含むトランザクションを見付ける。
３．エージェントは、「メタデータ−ＣｏｄｅＨａｓｈ」を読み出し、Ｈ_１を得るためにＣｏｄｅＨａｓｈフィールドを得て、Ｈ_１を用いてコード（Ｃ_１）を読み出す。ＲＩＰＥＭＤ−１６０（ＳＨＡ２５６（Ｃ_１））がＨ_１に等しい場合、コードは変化しておらず、安全に次のステップに進める。
４．エージェントは、インデックスＩを格納する「メタデータ−ＣｏｄｅＨａｓｈ」を読み出し、ｉ番目の反復でコードを再スポーニングする。言い換えると、ループが、適切な反復で「リロード」される。
５．メタデータの発生元を検証するために、ユーザの署名がＰ２ＳＨコマンドに含まれる。
６．これらのデータがループのこの反復のために必要な場合、エージェントは、「メタデータ−ＯｕｔｐｕｔＨａｓｈ」及び「メタデータ−ＯｕｔｐｕｔＰｏｉｎｔｅｒ」を読み出し、前のステップのアウトプットを検索する。

留意すべきことに、上述の実施形態は、本発明を限定するのではなく、当業者は添付の請求項により定められる本発明の範囲から逸脱することなく多数の代替の実施形態を考案できる。請求項中、括弧内に記載された如何なる参照符号も、請求項を制限すると見なされるべきではない。用語「有する（comprising又はcomprises）」等は、全体としていかなる請求項中に及び明細書に列挙された以外の要素又はステップの存在を排除するものではない。本願明細書において、「有する（comprises）」は「含む（includes）又は構成される（consists of）」を意味し、「有する（comprising）」は「含む（including）又は構成される（including of）」を意味する。要素の単数の参照は、該要素の複数の存在を排除するものではなく、逆も同様である。本発明は、複数の別個の要素を有するハードウェアにより又は適切にプログラムされたコンピュータにより、実施され得る。複数の手段を列挙している装置の請求項では、これらの複数の手段は、１つの同一のハードウェア要素により実装することができる。特定の量が相互に異なる従属請求項に記載されるという事実は、これらの量の組合せが有利に用いることが出来ないことを示すものではない。

Claims (19)

1. ブロックチェーンを介して行われる転送を制御するよう構成されたコンピュータにより実装されるシステムであって、前記システムは、
   複数の秘密暗号鍵を有する資産であって、各秘密鍵は前記資産の所有者に関連付けられる、資産と、
   複数の公開暗号鍵を有するレジストリであって、各公開鍵は、
   前記資産の複数の秘密鍵のうちの１つの秘密鍵に対応し、
   未使用ブロックチェーントランザクションの中で識別可能なRedeemScriptハッシュに関連付けられる、レジストリと、
   前記資産に関して転送が行われるための１又は複数のブロックチェーントランザクションの自動生成に関連する少なくとも１つのルールを有するスマートコントラクトと、
   前記スマートコントラクトの前記少なくとも１つのルールを評価し及び／又は実行するよう構成された計算エージェントと、
   を含むシステム。
2. 前記複数の秘密鍵のうちの少なくとも１つの秘密鍵は、既存暗号鍵ペアのサブキーとして生成され、
   少なくとも１つの第１エンティティマスタ秘密鍵と生成器値とに基づき、第１エンティティ第２秘密鍵を決定するステップと、
   少なくとも１つの第２エンティティマスタ秘密鍵と前記生成器値とに基づき、第２エンティティ第２秘密鍵を決定するステップと、
   前記第１エンティティ第２秘密鍵と前記第２エンティティ第２公開鍵とに基づき、前記第１エンティティにおいて共通シークレット（ＣＳ）を決定し、前記第２エンティティ第２秘密鍵と第１エンティティ第２公開鍵とに基づき、前記第２エンティティにおいて前記共通シークレット（ＣＳ）を決定するステップと、
   を含み、
   前記第１エンティティ第２公開鍵及び前記第２エンティティ第２公開鍵は、それぞれ、少なくとも１つの前記第１／第２エンティティマスタ鍵及び前記生成器値に基づき、
   前記第１又は第２エンティティの一方は前記資産であり、他方のエンティティは制御部又は前記資産に関連付けられた他のエンティティである、請求項１に記載のシステム。
3. 前記転送は、前記資産に関して行われるべき通貨の転送であり、前記転送は、前記資産に関連付けられた収入又は費用に関連する、請求項１又は２に記載のシステム。
4. 前記通貨はビットコイン、又は任意のデジタル通貨、又はトークン化された値である、請求項３に記載のシステム。
5. 前記スマートコントラクトの中で提供される前記少なくとも１つのルールは、前記資産に関連付けられる支払スケジュールを定める、請求項１乃至４のいずれか一項に記載のシステム。
6. 前記計算エージェントは、別の計算エージェントと通信するよう構成され、前記別の計算エージェントの各々は、前記資産に関連付けられたタスクを実行するよう構成される、請求項１乃至５のいずれか一項に記載のシステム。
7. 前記計算エージェントは、前記別の計算エージェントの各々の活動を調整し及び／又は認可するよう構成される、請求項６に記載のシステム。
8. ｉ）前記資産に関連付けられた収入に関するブロックチェーントランザクションを生成するよう構成される少なくとも１つの別の計算エージェントと、
   ｉｉ）前記資産に関連付けられた費用に関するブロックチェーントランザクションを生成するよう構成される少なくとも１つの別の計算エージェントと、
   ｉｉｉ）前記資産に関連付けられた支払に対する収入の相殺決済を処理するよう構成される少なくとも１つの別の計算エージェントと、
   ｉｖ）警報を生成し及び／又は前記資産の所有者に送信するよう構成される少なくとも１つの別の計算エージェントであって、前記警報は前記資産に関するイベントの通知を提供する、少なくとも１つの別の計算エージェントと、
   を更に含む請求項１乃至７のいずれか一項に記載のシステム。
9. 計算エージェントは、前記スマートコントラクトの中で指定されたイベント又はトリガを検出すると、ブロックチェーントランザクションを生成するよう構成される、請求項１乃至８のいずれか一項に記載のシステム。
10. 前記スマートコントラクトは、分散ハッシュテーブルに格納され、前記取引のハッシュは、ブロックチェーントランザクションに関連付けられるメタデータ内で提供される、請求項１乃至９のいずれか一項に記載のシステム。
11. ブロックチェーンを介して行われる転送を制御するコンピュータにより実施される方法であって、前記方法は、
    複数の秘密暗号鍵を有する資産を定めるステップであって、各秘密鍵は前記資産の所有者に関連付けられる、ステップと、
    複数の公開暗号鍵を有するレジストリを生成するステップであって、各公開鍵は、
    前記資産の複数の秘密鍵のうちの１つの秘密鍵に対応し、
    未使用ブロックチェーントランザクションの中で識別可能なRedeemScriptハッシュに関連付けられる、ステップと、
    前記資産に関して転送が行われるための１又は複数のブロックチェーントランザクションの自動生成に関連する少なくとも１つのルールを有するスマートコントラクトを生成するステップと、
    前記スマートコントラクトの前記少なくとも１つのルールを評価し及び／又は実行するために、計算エージェントを使用するステップと、
    を含む方法。
12. 前記複数の秘密鍵のうちの少なくとも１つの秘密鍵は、既存暗号鍵ペアのサブキーとして生成され、
    少なくとも１つの第１エンティティマスタ秘密鍵と生成器値とに基づき、第１エンティティ第２秘密鍵を決定するステップと、
    少なくとも１つの第２エンティティマスタ秘密鍵と前記生成器値とに基づき、第２エンティティ第２秘密鍵を決定するステップと、
    前記第１エンティティ第２秘密鍵と前記第２エンティティ第２公開鍵とに基づき、前記第１エンティティにおいて共通シークレット（ＣＳ）を決定し、前記第２エンティティ第２秘密鍵と第１エンティティ第２公開鍵とに基づき、前記第２エンティティにおいて前記共通シークレット（ＣＳ）を決定するステップと、
    を含み、
    前記第１エンティティ第２公開鍵及び前記第２エンティティ第２公開鍵は、それぞれ、少なくとも１つの前記第１／第２エンティティマスタ鍵及び前記生成器値に基づき、
    前記第１又は第２エンティティの一方は前記資産であり、他方のエンティティは制御部又は前記資産に関連付けられた他のエンティティである、請求項１１に記載の方法。
13. 前記転送は、前記資産に関して行われるべき通貨の転送であり、前記転送は、前記資産に関連付けられた収入又は費用に関連し、
    望ましくは、前記通貨はビットコイン、又はデジタル通貨、又はトークン化された値である、請求項１２に記載の方法。
14. 前記スマートコントラクトの中で提供される前記少なくとも１つのルールは、前記資産に関連付けられる支払スケジュールを定める、請求項１２又は１３に記載の方法。
15. 前記計算エージェントを別の計算エージェントと通信するよう構成し、前記別の計算エージェントの各々を、前記資産に関連付けられたタスクを実行するよう構成するステップ、を更に含む請求項１２乃至１４のいずれか一項に記載の方法。
16. 前記計算エージェントは、前記別の計算エージェントの各々の活動を調整し及び／又は認可するよう構成される、請求項１５に記載の方法。
17. ｉ）前記資産に関連付けられた収入に関するブロックチェーントランザクションを生成するよう構成される少なくとも１つの別の計算エージェントと、
    ｉｉ）前記資産に関連付けられた費用に関するブロックチェーントランザクションを生成するよう構成される少なくとも１つの別の計算エージェントと、
    ｉｉｉ）前記資産に関連付けられた支払に対する収入の相殺決済を処理するよう構成される少なくとも１つの別の計算エージェントと、
    ｉｖ）警報を生成し及び／又は前記資産の所有者に送信するよう構成される少なくとも１つの別の計算エージェントであって、前記警報は前記資産に関するイベントの通知を提供する、少なくとも１つの別の計算エージェントと、
    を提供するステップ、を更に含む請求項１２乃至１６のいずれか一項に記載の方法。
18. 計算エージェントは、前記スマートコントラクトの中で指定されたイベント又はトリガを検出すると、ブロックチェーントランザクションを生成するよう構成される、請求項１２乃至１７のいずれか一項に記載の方法。
19. 前記スマートコントラクトは、分散ハッシュテーブルに格納され、前記取引のハッシュは、ブロックチェーントランザクションに関連付けられるメタデータ内で提供される、請求項１２乃至１８のいずれか一項に記載の方法。

Images