JP7036844B2 - ブロックチェーンを介して決定性有限オートマトン（ｄｆａ）を実施するシステム及び方法 - Google Patents

Description

本発明は、概して、コンピュータに基づくプロセスのコンピュータプロトコルの自動実行のためのシステム及びプロトコルに関し、より詳細には、例えばコントラクトに関するような条件制御されるプロセスの検証、施行、及び／又は実行に関する。本発明は、しかしながら、コントラクトに関連する使用に限定されない。本発明は、限定ではなくビットコインブロックチェーンのようなブロックチェーン技術にも関し、スマートコントラクトに利益をもたらすために使用され得る。

タスク及びプロセスの実行を自動化し及び制御するためにコンピュータを使用することは、長い間望まれている。これは、例えば、金融上の契約に関するようなパーティ間の合意の実行に関して特に該当する。コントラクトの本質の電子バージョンが一層良好に定められ、その結果、コンピュータにより実行でき実施できるので、スマートコントラクトは学術的研究の主題及び実際的関心である。近年のコントラクト管理に伴う主な問題のうちの１つは、アドホックである傾向があり、手動で維持されているコントラクトのローカルストア及びコピーを伴うことである。このコピーは、互いに同期外れになり、それら自体の記憶及び維持を必要とする。これは、非効率であり、セキュリティ及びコストに関連する問題を生じる。これらの問題は、機械可読及び実行可能文書（従来、「スマートコントラクト」として参照される場合がある）の実行を自動化することにより、少なくとも部分的に解決できる。このような自動化ソリューションは、自然言語及び法律用語から生じる潜在的曖昧さ及び解釈を最小限に抑えることも助ける。結果として、コントラクトは、それらが自動化された場合には、少ないコストで、しかしより効率的且つ信頼できる方法で実行できる。

文献で提案されている異なるアプローチの中で、決定性有限状態機械としても知られる決定性有限オートマトン（deterministic finite automata：ＤＦＡ）は、広範な（全部ではない場合）考えられる金融上の契約を表現するために十分豊富な構造を有することが示されている。有限状態機械及びＤＦＡの概念は、コンピューティング科学の範囲内で良く知られている。ＤＦＡは、有限状態セット中の１つの状態にあり、且つトリガイベント又は条件が生じるとある状態から別の状態へ変化（遷移）し得る、抽象機械として考えられる計算の数学モデルである。その計算能力は、組み合わせ論理のものより大きいが、スタック機械のものより少ない。

コントラクトの自動実行は、また、ブロックチェーン技術と関連して近年研究されている。この一例は、ＣＮ１０５８９３０４２Ａである。該文献は、スマートコントラクトの実行中に生じた状態変化に関連するデータのセキュア記憶設備として、ブロックチェーンの使用を議論している。しかしながら、ブロックチェーン技術、トランザクションアウトプット、及びそれらの関連するスクリプトは、本願明細書で議論するように、より知的な動作を提供するために、遙かに高機能且つ技術的に複雑な方法で使用できる。

ブロックチェーンは、不変ブロックにより構成される、コンピュータにより実装される非集中型の、分散型ピアツーピアコンピュータシステムである。また、不変ブロックはトランザクションにより構成される。これは、合意に基づくプロトコルに関連する。各ブロックは前のブロックのハッシュを含み、ブロックは共にチェーンになって、その発端からブロックチェーンに書き込まれてきた全てのトランザクションの耐タンパー性のある永久的なレコードを生成する。これらのブロックはブロックチェーンの一部になると、改変がハッシュの変更を引き起こし得るので、公衆により検査可能だが、変更又は削除できない。

トランザクションは、そのインプット及びアウトプットに組み込まれるスクリプトとして知られる小さなプログラムを含む。スクリプトは、トランザクションのアウトプットがどのように及び誰によりアクセス可能かを指定する。各未使用トランザクション（ＵＴＸＯとして参照される）は、新トランザクションへのインプットとして使用可能である。したがって、チェーンは時間の経過と共に大きくなる。各アウトプットは、該アウトプットのロックスクリプト内で指定された要件に従う限り、ネットワーク上のアドレスへの使用可能な関連通貨額を有する。アドレスは、暗号非対称鍵ペアの公開鍵である。Ｐ２ＰＫＨ（pay to public key hash）アウトプットは、自身の値をアドレス（公開鍵）に直接支払うアウトプットである。一方、Ｐ２ＳＨ（pay to script hash）トランザクションにおけるアウトプットは、第２スクリプトのハッシュを含むｐｕｂｋｅｙスクリプト（アンロックスクリプトとしても知られる）、アウトプットを使用するために後のトランザクションで受信側が彼の署名と一緒に提供しなければならないＲｅｄｅｅｍスクリプト、に関連付けられる。

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

ブロックチェーン技術は、暗号通貨の実装の使用のために知られている。しかしながら、更に近年は、デジタル起業家が、新しいシステムを実装するために、ビットコインの基づく暗号通貨セキュリティシステムの使用、及びブロックチェーンに格納可能なデータの両者を探索し始めている。結果として、「スマートコントラクト（smart contracts）」として知られるコンピュータプロトコルは、それらが部分的に又は全体的に取引の自動施行又は実行を可能にできるので、注目を集め始めている。ブロックチェーンにより実装されるスマートコントラクトは、拡張されたセキュリティ、耐タンパー性のある且つ永久的な公開イベントレコード、及びトランザクションコストの低減のような利益を提供できる。

したがって、コントラクトのようなプロセスの自動化から生じる利益、及びこの自動化のためにブロックチェーンを使用することの利益をもたらすソリューションを提供することが望ましい。

このような改良されたソリューションが考案されている。本発明は、添付の請求項において定められる。

本発明によると、ブロックチェーンにより実装される方法／システムが提供され得る。これは、技術的プロセスの自動実行及び制御のための方法／システムとして記載され得る。本発明は、ブロックチェーン基盤において有限状態機械又はＤＦＡの実装又は実用的具現によりプロセスの自動実行を助ける技術革新を提供し得る。機械の状態が定められ決定されて良い。各状態遷移の条件又はトリガが格納されて良い。プロセスを実行すると、実行された状態は永久的なブロックチェーン台帳に記録されて良い。ブロックチェーントランザクションは、機械をある状態から別の状態へ移行させるエージェント又は参加者として機能して良い。各状態遷移は、プロセスの中のステップを表し又はそれに対応して良い。ＤＦＡがコントラクトを定めるとき、本発明は、異なる契約パーティの責務、並びに他の条項及び規定の自動実行及び施行のためのメカニズムを提供し得る。

追加又は代替として、本発明は、ブロックチェーン外で実行されるコンピュータにより実施されるプロセスを制御するためにブロックチェーンを使用する方法／ソリューションとして記載され得る。したがって、本発明は、アーキテクチャ及びプロトコルの観点で非常に異なるコンピュータに基づくシステムの相互作用を含み得る。上述の特徴のうちの１又は複数は、本発明の本態様に従い使用されて良い。

本発明の１又は複数の実施形態は、ブロックチェーン上で又はそれに関連してＤＦＡを実施する（具現する又は実現する）方法を提供し得る。ＤＦＡは、ソフトウェアに基づくＤＦＡであって良い。ブロックチェーンは、ビットコインに基づくプロトコルと関連して実施されて良く、又は別のブロックチェーンプロトコルを使用して良い。追加又は代替として、これは、ブロックチェーンにより実施されるＤＦＡの状態の決定を可能にするよう構成される方法であって良い。これは、現在状態であって良い。方法は、ＤＦＡの状態の動的（ランタイムにおける）決定を可能にし得る。したがって、本発明の１又は複数の態様は、単に既に生じたイベントに関するデータを記録するためにセキュア記憶設備として使用するより、正確な複雑な且つ知的な方法で、ブロックチェーン上でＤＦＡを実施するメカニズムを提供し得る。

本発明は、ブロックチェーントランザクション（Ｔｘ_１）の未使用アウトプット（ＵＴＸＯ_１）のロックスクリプトの一部をＤＦＡの所与の状態に関連付けるステップを含んで良い。ロックスクリプトの一部は、ロックスクリプト内のデータの一部であって良い。これはメタデータの一部であって良い。これは識別子、ラベル、又はタグであって良い。

したがって、本発明は、ブロックチェーン上の未使用トランザクションアウトプット（ＵＴＸＯ）を使用して、ＤＦＡが実行中の所与の状態にいる状態及び／又は現在いることを記録し及び識別して良い。

前記方法は、前記トランザクション（Ｔｘ_１）のアウトプット（ＵＴＸＯ_１）を使用することにより、前記ＤＦＡの状態から更なる状態へ遷移させるために更なるトランザクション（Ｔｘ_２）を使用するステップを有し得る。前記更なる状態は、前記更なるトランザクションの未使用アウトプット（ＵＴＸＯ_２）のロックスクリプト内で提供されるデータの一部に関連付けられて良い。したがって、ＵＴＸＯは、ＤＦＡ状態の変化をブロックチェーンに記録させ又は具現させ得る。

前記方法は、コードの一部を用いて、少なくとも１つの状態遷移トリガを実施し又は表すステップであって、前記状態遷移トリガは、実行されると、更なるトランザクション（Ｔｘ_２）に前記トランザクション（Ｔｘ_１）の前記アウトプット（ＵＴＸＯ_１）を使用させ、したがって前記ＤＦＡを別の状態に移動させる、ステップ、を含み得る。

前記コードの一部は、インプット信号に基づきブール結果を提供する機械テスト可能条件を含み得る。前記インプット信号は、ランタイムに決定されて良く、前記ＤＦＡを前記更なる状態に移動させるために前記未使用アウトプット（ＵＴＸＯ_１）が使用されるべきか否かを決定するために前記コードの一部により使用されて良い。

前記未使用アウトプット（ＵＴＸＯ_１）内の前記データの一部は、ロックスクリプト内で提供されて良い。

前記データの一部は、タグ、ラベル、又はメタデータの一部であって良い。

前記ＤＦＡは、機械実行可能スマートコントラクトのモデルであって良い。

前記未使用アウトプット（ＵＴＸＯ_１）は、パズルのハッシュを有するロックスクリプトを含んで良く、前記パズルの解は、前記アウトプット（ＵＴＸＯ_１）を使用し及び前記ＤＦＡを別の状態に遷移させるために更なるトランザクションのインプットにより提供されなければならない。

前記未使用アウトプット（ＵＴＸＯ_１）は、Ｒｅｄｅｅｍスクリプトのハッシュを有するロックスクリプトを含んで良く、前記Ｒｅｄｅｅｍスクリプトは、前記アウトプット（ＵＴＸＯ_１）を使用し及び前記ＤＦＡを別の状態に遷移させるために更なるトランザクションのインプットにより提供されなければならない。Ｒｅｄｅｅｍスクリプトは、暗号鍵を有して良い。

方法は、上述の又は以下に記載の任意の特徴を実行するために１又は複数のコンピューティングエージェントを使用するステップを含んで良い。

本発明は、上述の任意の実施形態の方法を実施するよう構成されるシステムも提供する。前記システムは、ブロックチェーンプラットフォーム（これは、ビットコインブロックチェーンであって良く又はそうでなくて良い）と、ブロックチェーンによりＤＦＡを実施するよう構成される少なくとも１つのコンピューティングエージェントと、を含み得る。

追加又は代替として、前記方法は、少なくとも１つのインプット信号を使用して、少なくとも１つの条件を実行し、前記条件の実行の結果に基づき、前記ＤＦＡの状態遷移テーブルに従いアクションを実行するステップを含み得る。

アクションの実行は、ブロックチェーン台帳の状態から識別可能又は検出可能であって良い。これは、１又は複数のブロックチェーントランザクションのアウトプットを考察する又は分析することにより達成できる。トランザクションがＤＦＡに及び／又はＤＦＡの関連するコントラクトに関連する場合、アウトプットが使用されたか否かを決定するために、アウトプットが検査されて良い。ＤＦＡの状態は、アウトプットが未だ使用されていないという事実から認識できる。これは、ＤＦＡのために考案された状態遷移テーブルを参考にすることにより認識できる。これは、方法／システムの実行前に考案されている。

アクションは、ブロックチェーン上のトランザクション（Ｔｘ）を用いて実行されて良い。アクションは、ブロックチェーン上の少なくとも１つのトランザクションのアウトプット及び／又はインプットから識別可能である。

方法は、アクションが実行されたか否かに基づきＤＦＡの現在状態を決定するために、ブロックチェーンの状態を分析するステップを含み得る。

ＤＦＡは、コントラクトの実行を表し又はモデル化して良い。コントラクトはスマートコントラクト（smart contract）であって良い。

少なくとも１つのインプット信号は、人間又は非人間ソースにより生成され及び／又は提供される信号又は値であって良い。例えば、これは、方法の実行されているコンピュータ、例えばシステムクロックから導出された時間又は日にち、により生成されて良い。これは、コンピュータの外部のソースから、例えばリモートセンサ又はリモートコンピューティングリソースから受信されて良い。

少なくとも１つのインプット信号は、ＤＦＡのある状態から別の状態への遷移のトリガを提供して良く、又はトリガを「発火（fire）」又は起動させて次のアクションを生じて良い。

方法は、ＤＦＡの状態遷移テーブルを決定するステップを含み得る。状態遷移テーブルは、ソフトウェアでコード化されて良い。ソフトウェアは、所与のインプット信号及び状態遷移及び／又はそれらのトリガする機械実行可能アクションに関連する命令を含み得る。

本方法は、ブロックチェーントランザクション（Ｔｘ_１）の未使用アウトプット（ＵＴＸＯ_１）のロックスクリプト（内のデータ）の一部をＤＦＡの所与の状態に関連付けるステップを含んで良い。方法は、前記トランザクション（Ｔｘ_１）のアウトプット（ＵＴＸＯ_１）を使用することにより、前記ＤＦＡの状態から更なる状態へ遷移させるために更なるトランザクション（Ｔｘ_２）を使用するステップを有し得る。前記更なる状態は、前記更なるトランザクションの未使用アウトプット（ＵＴＸＯ_２）のロックスクリプト内で提供されるデータの一部に関連付けられて良い。

前記方法は、少なくとも１つのコンピュータ実行可能条件を含むコードの一部を用いて、少なくとも１つの状態遷移トリガを実施し又は表すステップであって、前記状態遷移トリガは、実行されると、更なるトランザクション（Ｔｘ_２）に前記トランザクション（Ｔｘ_１）の前記アウトプット（ＵＴＸＯ_１）を使用させ、したがって前記ＤＦＡを別の状態に移動させる、ステップ、を含み得る。前記コードの一部は、インプット信号に基づきブール結果を提供する条件を含み得る。

前記方法は、特定の状態が前記ＤＦＡにより占有された回数の記録を維持するステップを含み得る。記録は、ループ又は繰り返し構成の範囲内でインクリメントされるインデックスを用いて維持されて良い。ループ又は繰り返し構成は、所定条件が満たされると終了して良い。

ソフトウェアにより実施されるＤＦＡは、分散型アーキテクチャ又はシステムを用いて実施され及び／又は実行されて良い。本発明は、上述又は以下に記載の方法の任意の実施形態を実施するよう構成されるシステムも提供し得る。

本発明は、ソフトウェアを含むソフトウェアにより実施されるＤＦＡであって、前記ソフトウェアは、少なくとも１つのインプット信号を用いて、少なくとも１つの条件を実行し、前記条件の前記実行の結果に基づき、前記ＤＦＡの状態遷移テーブルに従いアクションを実行するよう構成され、前記アクションの実行は、ブロックチェーン台帳の状態から識別可能である、ソフトウェアにより実施されるＤＦＡを提供する。

本発明は、ブロックチェーントランザクション（Ｔｘ_１）の未使用アウトプット（ＵＴＸＯ_１）のロックスクリプトの一部をＤＦＡの所与の状態に関連付けるステップを含む方法を提供し得る。ロックスクリプトの一部は、ロックスクリプト内のデータの一部であって良い。これはメタデータの一部であって良い。これは識別子、ラベル、又はタグであって良い。したがって、本発明は、ブロックチェーン上の未使用トランザクションアウトプット（ＵＴＸＯ）を使用して、ＤＦＡが実行中の所与の状態にいる状態及び／又は現在いることを記録し及び識別して良い。

方法は、前記トランザクション（Ｔｘ_１）のアウトプット（ＵＴＸＯ_１）を使用することにより、前記ＤＦＡの状態から更なる状態へ遷移させるために更なるトランザクション（Ｔｘ_２）を使用するステップを有し得る。前記更なる状態は、前記更なるトランザクションの未使用アウトプット（ＵＴＸＯ_２）のロックスクリプト内で提供されるデータの一部に関連付けられて良い。したがって、ＵＴＸＯは、ＤＦＡ状態の変化をブロックチェーンに記録させ又は具現させる。

本発明は、実質的に本記載の「コード化技術」の章を参照して記載され得るが、本願明細書の他の章からの特徴も組み込んで良く、本願明細に記載の任意の特徴を組み込んで良い。

追加又は代替として、本発明は、インプット信号を監視し及び／又は受信し、前記インプット信号に応答して、未使用アウトプット（ＵＴＸＯ）を含み且つ前のトランザクションＴｘ１のアウトプットを使用するブロックチェーントランザクションＴｘ_２を生成するよう構成されるプログラムを実行するステップを含み得る。

前のトランザクションＴｘ_１のアウトプットは、ＤＦＡの第１状態に関連付けられた識別子を含むロックスクリプトを有して良く、トランザクションＴｘ２の未使用アウトプット（ＵＴＸＯ）は、ＤＦＡの更なる状態に関連付けられた更なる識別子を含むロックスクリプトを有して良い。識別子は、任意の形式又はフォーマットのラベル、タグ、又は状態を識別する手段であり得る。これは、メタデータのようなデータの一部、又は暗号鍵を有し得る。

プログラムは、ＤＦＡの第１状態に関連付けられた識別子を含み得る。プログラムは、ＤＦＡの更なる状態に関連付けられ且つ更なるトランザクションＴｘ_２のＵＴＸＯに含まれる更なる識別子を含む更なるプログラムを生成し及び／又は実行するよう構成されて良い。

ＤＦＡは、（機械実行可能）スマートコントラクトの実行をモデル化し又は表して良い。スマートコントラクトは、テンプレートコントラクトにパラメータを移植することにより、コンピュータに基づくリソースにより生成されて良い。したがって、コントラクト生成は自動化できる。

方法は、ＤＦＡの状態遷移テーブルを決定し、コンピュータに基づく記憶リソースに状態遷移テーブルを格納するステップを含み得る。

プログラムは、ブロックチェーントランザクションＴｘ１のロックスクリプト内の識別子を用いて、ＤＦＡの現在状態を決定すること、ＤＦＡの状態遷移テーブルを用いて、現在状態及びインプット信号に基づき更なる状態及びその関連付けられた識別子を決定すること、によりインプット信号に応答してブロックチェーントランザクションＴｘ_２を生成するよう構成されて良い。

方法は、ブロックチェーントランザクションＴｘ_２及び／又は前のトランザクションＴｘ_１をブロックチェーンネットワークに提出するステップを有して良い。

複数のプログラムが生成され実行されて良く、各プログラムは、ＤＦＡの状態を一意に識別するための識別子を有する。したがって、一連のプログラム（スクリプト）は、コントラクトを実行するために使用されて良い。各スクリプトは、状態の期間に実質的に対応する寿命を有する。つまり、ＤＦＡがどれだけ長いかは、その所与の状態であり又はそれであって良い。

トランザクション（Ｔｘ_２）の未使用アウトプット（ＵＴＸＯ）及び／又は前のトランザクション（Ｔｘ_１）のアウトプットは、パズルのハッシュを有するロックスクリプトを含んで良く、前記パズルの解は、前記アウトプットを使用し及び前記ＤＦＡを別の状態に遷移させるために別のブロックチェーントランザクションのインプットにより提供されなければならない。

トランザクション（Ｔｘ_２）の未使用アウトプット（ＵＴＸＯ）及び／又は前のトランザクション（Ｔｘ_１）のアウトプットは、Ｒｅｄｅｅｍスクリプトのハッシュを有するロックスクリプトを含んで良く、前記Ｒｅｄｅｅｍスクリプトは、前記アウトプット（ＵＴＸＯ）を使用し及び前記ＤＦＡを別の状態に遷移させるために別のブロックチェーントランザクションのインプットにより提供されなければならない。Ｒｅｄｅｅｍスクリプトは、暗号鍵を有して良い。

ＤＦＡの状態は、ブロックチェーン上のトランザクション内の未使用アウトプット（ＵＴＸＯ）により表される。所与のＵＴＸＯを使用することは、異なる状態への遷移を表し得る。状態、アクション、条件、及びトリガは、ＤＦＡの遷移テーブル内に提供され及び／又はソフトウェアで符号化されて良い。

本発明は、ソフトウェアに基づくＤＦＡを実施し、実現し、又は具現化するよう構成されるシステムを提供し得る。本発明は、これをブロックチェーンにより行い得る。前記システムは、ブロックチェーン（ブロックチェーンはビットコインネットワークを用いて実装されて良く又はそうでなくて良い）と、上述の又は以下に記載の任意の方法に従い少なくとも１つのプログラムを生成し及び／又は実行するよう構成される１又は複数のコンピューティングエージェントと、例えばハッシュテーブル又は分散ハッシュテーブルであって良い、ＤＦＡの状態遷移テーブルを格納する記憶リソースと、及び／又は、ブロックチェーントランザクションのための少なくとも１つのテンプレート及び／又はスマートコントラクトのための少なくとも１つのテンプレートと、を有して良い。

本発明は、実質的に以下の「ソフトウェアにより実施されるＤＦＡのコンパイル及び実行」と題される章に記載され得る。しかしながら、説明の他の章からの特徴も適用できる。
システムは、（スマート）コントラクトの自動実行を実行するために、ブロックチェーン上の状態機械の実行を実施し又は実現するよう構成されて良い。

本発明のシステムに関連して言及される任意の特徴は、本発明の対応する方法に適用可能であって良く、逆も同様である。本発明のある実施形態又は態様に関連して本願明細書で言及される任意の特徴は、任意の他の実施形態又は態様に適用されても良い。
本発明のブロックチェーンに基づくＤＦＡは、少なくとも以下の主要な特徴を組み込む：
・有限状態セット中の１つの状態にあり、且つ有限セットのトリガイベント（インプットと呼ばれる）が生じるとある状態から別の状態へ変化（遷移）し得る、抽象機械として考えられる計算の数学モデルのブロックチェーンに基づく実装を提供する。
・ブロックチェーン上の計算及び記憶構造で具現される決定性有限オートマトン（ＤＦＡ）のような、異なるパーティの責務の技術的実現に基づきコントラクトの確立及び自動実行のための新規な技術を提供する。

既存のブロックチェーン基盤及びプロトコルを使用できる。
・スマートコントラクトの自動生成、制御及び実行を可能にし及び実現する。
・コンピュータにより自動的に実行可能及び施行可能である。
・コントラクト、それらの実行及び結果の永久的な不変の記録。

本発明は、ブロックチェーンプロトコル及びフラットフォームに固有の少なくとも以下の利点を提供し及び利用する：
・設計により本来セキュアである（ビットコインプロトコルは信頼できるパーティを必要としない）。
・分散型である。したがって、大規模の単一の障害発生時点を回避し、攻撃に対して脆弱ではない。
・管理及び維持が容易である（ビットコインネットワークは使用するのに分かり易い）。
・高価でない（通常、ビットコインプロトコルの下で少ないトランザクション料金が期待されるだけである）。
・地理的に制限又は限定されず、インターネットへのアクセスを有する誰でもどこでもいつでも使用できる。
・データがブロックチェーンに書き込まれると、誰でもそれを見ることができ、透過である。
・データがブロックチェーンに書き込まれると、誰もそれを変更できず、不変である。
・プライバシが維持され、個人特定情報が関与しない。

本発明の上述の及び他の態様は、本願明細書に記載される実施形態から明らかであり、それらの実施形態を参照して教示される。本発明の実施形態は、単なる例として添付の図面を参照して以下に説明される。
本発明の実施形態により構成されたシステムの概観を示す。 スマートコントラクトがトリガされる種々の状態遷移を表すためにＰ２ＰＫＨトランザクションを用いてブロックチェーン上で実施されるＤＦＡとして実行される、本発明の説明に役立つ実施形態を示す。 以下に議論する例毎に、ブロックチェーンに基づくＤＦＡを示す。 以下に記載するパズルに基づく実装のための開始（状態ｓ_０）トランザクション（ｏ）の一例を示す。 遷移（状態ｓ_０から状態ｆ_ｆへ）トランザクション（ｔ_ｆ）の一例を示す。 完了（状態ｆ_ｆから）トランザクション（ｃ_ｆ）の一例を示す。 図４と類似するが、ＤＦＡ状態のＰ２ＳＨトランザクション型を用いるブロックチェーントランザクションを示す。 図５と類似するが、ＤＦＡ状態のＰ２ＳＨトランザクション型を用いる一例を示す。 図６と類似するが、ＤＦＡ状態のＰ２ＳＨトランザクション型を用いる一例を示す。 本発明の一実施形態に従い使用され得るコード化技術の例１の債券（bond）の状態図である。図１０は、図示のインプットに関連付けられた状態（太字）及びトランザクション（接続線）を示す。 再帰状態を有する例２のクーポン債券（bond）の状態図を示す。 図１１の例に関連する再帰状態の内部状態図を示す。 本願の「コンパイル及び実行」の章の欧州買い付け選択権（コールオプション）の例の状態図を示し、状態（太字）及び提出されるべきブロックチェーントランザクション（三角形）：発生（ｏ）、遷移（ｔ）、及び完了（ｃ）を示す。

本願明細書では、ブロックチェーン及びトランザクションチェーン技術、許可及び未許可台帳、共有台帳及びそれらの変形を含むがこれらに限定されない、総意に基づく電子、コンピュータに基づく分散型台帳の全ての形式を包含するために、用語「ブロックチェーン」を使用する。最も広く知られているブロックチェーン技術の用途はビットコイン台帳であるが、他のブロックチェーンの実装が提案され開発されている。ビットコインは便宜上及び説明を目的として本願明細書において言及されるが、本発明はビットコインのブロックチェーンと共に使用することに限定されず、代替のブロックチェーンの実装及びプロトコルが本発明の範囲に含まれることに留意すべきである。

本発明の説明のための実施形態は、コントラクトのようなプロセス又はタスク、並びにエージェント又は「ボット」として参照されることのあるコンピューティングリソースの関連システムをモデル化するＤＦＡの定義を含む。エージェントは、トランザクションを生成しそれらをブロックチェーンに提出するよう構成される。本発明は、しかしながら、コントラクトに関連する使用に限定されない。

図１を参照すると、本発明は、ハードウェア及びソフトウェアコンポーネントを含むコンピューティングプラットフォーム－ブロックチェーン－上で具現化される抽象ＤＦＡとしてプロセスの実現を提供する。図１は、本発明の説明のための実施形態に従い構成されたシステムの概観を提供する。システムは、命令を受信するために他のエンティティ４（例えば、人間又は他のコンピュータ）と相互作用可能なコンピューティングエージェント３を有する。これらの命令は、例えばどのスマートコントラクトを生成し及び実行すべきかであり得る。したがって、コンピューティングエージェント３は、物理的世界と相互作用して、それら自身の外部で、「現実世界」において、イベントに応答し及びイベントを生じることにより、本発明を実施する。

コントラクト自体の仕様は、任意の機械実行可能フォーマット、例えばｘＢＲＬで提供され、セキュア且つ非集中的方法で、例えばトレント（torrent）ネットワーク上の分散ハッシュテーブル（distributed hash table：ＤＨＴ）５内に、格納され得る。コントラクトの仕様から、コンピューティングエージェントはＤＦＡ２を構成する。ＤＦＡ２は、１又は複数のエージェントによりブロックチェーン１上で後に具現化される。

ＤＦＡ２自体は、有限セット｛Ｓ，Ｉ，ｔ，ｓ_０，Ｆ｝として指定される。ここで、Ｓは、コントラクト／ＤＦＡが存在し得る可能な状態の（有限）集合であり、Ｉは、本願明細書の文脈ではコントラクトと関連して生じ得る任意のイベント又は条件、例えば支払が行われる、証券の満期に達する、契約相手の債務不履行、等を意味するインプット（アルファベットとしても知られる）の（有限）集合である。本願のメカニズムでは、これらのインプット信号は、１又は複数のエージェントにより受信され／生成され、該エージェントは次にシステムの次の状態（場合によっては同じ状態）を決定する。

ＤＦＡの第３コンポーネントは、トランザクション関数ｔ：Ｓ×Ｉ→Ｓである。「ＤＦＡ」における用語「決定性」は、決定の一意性：状態及びインプットが与えられると、唯一の新しい状態（場合によっては同じ状態）が存在する、を表す。したがって、初期状態（Ｓ_０）及びインプットの履歴が与えられると、計算（コントラクト）の結果は、全ての可能な最終結果の集合の中のユニークな１つである（Ｆ⊆Ｓ）。全てのこれらの要素が確立されると、ＤＦＡは、遷移テーブルにより完全に定められ、全ての可能な現在状態及びインプット信号についての将来の状態を指定する。ＤＦＡの状態は、それ自体が、ブロックチェーン上の未使用トランザクションアウトプット（ＵＴＸＯ）に関連付けられる。従来知られているように、ビットコインネットワークは、全ての利用可能ＵＴＸＯを絶えず追跡する。本発明によると、ＤＦＡがある状態から別の状態へ移行するメカニズムは、ブロックチェーントランザクションにより本発明に従い具現化される（実施される）。事実上、ブロックチェーン上のトランザクションはある状態（前のトランザクションのインプット）に関連付けられたＵＴＸＯを使用し、次の状態（アウトプット）に関連付けられたＵＴＸＯを生成する。

＜単純なＤＦＡの例：割引（ゼロクーポン）債券＞
説明のために、以下では、通常、ある価格で（通常はその額面価格に対して割引して）購入され次にその元金が満期時に返金されるまでの特定時間の間保持される単純な債券類である、割引（ゼロクーポン）債券を検討する。したがって、クーポン債券は、最終クーポンに加えて債券の元金も支払われるときであるその満期まで保持者がコントラクトの発行人から受け取る定期的利子支払（クーポン）による債務契約である。

検討する可能な状態はＳ＝｛ｓ_０，ｆ_０，ｆ_１｝であり、それぞれ保持状態（ｓ_０）、コントラクトの正常終了（幸運な経路を辿った場合）又は幸せな結末（ｆ_０）、及び失敗した、例えば訴訟、の状態（ｆ_１）を示す。システムの最終状態は、したがってＦ＝｛ｆ_０，ｆ_１｝である。検討するアルファベットは、Ｉ＝｛ｒ，ｄ，ｅ｝であり、それぞれ満了時（又は前）の元金の返済金（ｒ）、満了時（又は前）の発行人の債務不履行（ｄ）、及び返金を伴わないコントラクトの満了（ｅ）を示す。この単純なコントラクトのトランザクションマトリクスは表１に示される。

［表１］ゼロクーポン債券を表すＤＦＡの遷移テーブル

留意すべきことに、最終状態はコントラクトの完了を表し、したがってそれらから更なる状態が指定される必要はない（現在、遷移テーブル内の「－」として示されるが、これらの線は省略され得る）。原則として、より多くの状態及び／又はインプット（並びにアクション）がこの証券について定められ得るが、これは、コントラクトの複雑性に関連する邪魔な詳細事項を挿入するのではなく、本発明の基本的な新規な態様を説明するために、単純性及び明確性のために本願明細書において行われていない。

図３は、（ビットコイン）ブロックチェーン上のゼロクーポン債券ＤＦＡの実施形態を表す。状態は円により表され、機械をある状態から他の状態へ移行させるビットコイントランザクションは青色三角形により表される。図３ではエージェントにより受信されるインプットは省略されるが、各状態において、これらのインプットに従い１つ又は他の遷移が生じるべきであり、これが１つ又は他のビットコイントランザクション（例えば、状態ｓ_０の中のｔ_０又はｔ_１）の構成により図中に反映されること、状態を変更しない遷移にはトランザクションが必要ないこと、したがってそれらは省略されることに留意する。ＤＦＡの遷移トランザクション（ｔ_ｉ）に加えて、初期発生トランザクション（ｏ）、及びコントラクトの完了に対応するトランザクション（ｃ_ｉ）が考えられる。

以下では、トランザクション（発生、遷移、及び完了）における資金の流れに注意を向ける。重要なことに、ＤＦＡ及び（金融）コントラクトの有限性により、プロセスは多数の遷移の後に完了することに気付く。これは、コントラクトの確立及び実行の最大コストが結合され、予め、例えばＤＦＡの確立時に、決定できることを必ずしも意味しない（関与するコンピューティングエージェント及びビットコインマイナーのための幾つかの有限料金を想定する）。これは、考えられる最長経路を辿るコントラクトを実行するために必要な合計資金額により与えられる。これは、勿論、実行中の無限ループの可能性を排除するが、しかし、これは現在の（金融）コントラクトに関連しないこと、永久債権のようなコントラクトでさえ、その名称にも拘わらず将来の特定時点で完了すべき債券であること、例えば負債のあるエンティティが消滅する又はインフレにより支払が無視できるほど小さくなること、に留意する。

料金の特定の分配、各エージェントが彼らの作業に対していくら受け取るかは、実際の重要性に拘わらず、本発明の主要な要素ではない。合理化されたゼロクーポン債券の例を続けると、本願明細書は、以下の：３ｍＢＴＣの発生トランザクション（ｏ）の料金、１ｍＢＴＣの遷移料金（ｔ_ｉトランザクション）、２ｍＢＴＣの完了トランザクション（ｃｉ）のための料金を想定する。これらの料金は、トランザクション自体に自動的に含まれる。３つのトランザクションのための合計マイニング料金の３ｍＢＴＣと一緒に、これは、合計で９ｍＢＴＣの最大コストを生じる。本願明細書の非常に単純な例では、全ての経路の長さは等しい。したがって、コントラクトの最終コストは、確実にその最大コストと一致する。これは概して、資金の一般的流れを完全に説明するための例である必要がないので、コントラクトの実行のために提供される資金は１０ｍＢＴＣであり、１ｍＢＴＣが完了後に資金の同一供給源に返金されると仮定する。これは、完了時に最終的な未使用資金に取って代わる。つまり、最大及び使用済み資金は異なる。

コントラクトの確立及び実行のための資金（１０ｍＢＴＣ）は、最初に、「原資産所有者（originator）」として参照される特定の資金供給源により提供されると仮定する。上述のように、本例では、この供給源は、完了後に１ｍＢＴＣの未使用資金も受け取る。原則的に、トランザクションに資金の追加インプット及びアウトプットをを含めることもできる。例えば、ゼロクーポン債券のために支払われる価格、元金の返済、又は資金の任意の他の考えられる送金である。これは実際の関心事であって良いが、この点では、本発明の基本的要素を不明瞭にしてしまうだけである。明確性のために、このような詳細事項は以下の例には含まれない。しかしながら、構造は完全に一般的であり、このような可能性は排除されないことに留意すべきである。

＜技術的ソリューションの説明のための実装－ＤＦＡシステム及び方法＞
当業者は、システムが種々の方法で実装され得ることを直ちに理解する。これらの変形は依然として本発明の範囲内に含まれる。例えば、エージェントシステム３の構成及びアーキテクチャは変化し得る。例えば関与する特定エージェントが予め知られているか否か。ここでは、説明のために２つの技術的設計オプションを検討する。
１．コントラクトへの参加が比較的開放的に保たれ、様々なコンピューティングエージェントが参加できる場合、「トランザクションパズル」型の標準的ブロックチェーントランザクションに基づく構造が可能である。
２．逆に、各状態のトランザクションが特定エージェント（又はエージェントのグループ）に予め割り当てられる場合、Ｐ２ＳＨ（pay－to－script－hash）トランザクションが使用できる。

パズルに基づくブロックチェーントランザクション及びＰ２ＳＨトランザクションは、ブロックチェーン技術の分野で知られている。当業者は、上述の２つのオプションに加えて又はその代替として多数の可能性が存在し得ることも理解する。例えば、一実施形態は、時間により変化する複数のエージェント、及び／又はエージェントの階層構造、等を使用して良い。可能性は多数あるが、本願明細書では、当業者が他の可能な変形及び実装オプションを直ちに導出する２つのオプションだけを記載する。

しかしながら、トランザクションの中で資金を提供する／受け取るパーティ（例えば、発行人、購入者、受取人、等）は本発明にとって必須ではないので、一実施形態において使用されるブロックチェーントランザクションの種類は、本発明にとって必須ではないことに留意する。代わりに、本発明の主要な要素は、任意の時点で、タスク／コントラクトの状態がブロックチェーン内で定められること、それがコントラクトの自動生成、ブロックチェーン上での実行、生じる一連のイベントに従う適切な結果の実施、を可能にするメカニズム（その詳細な具体的実現に拘わらず）を提供することである。メカニズム全体がブロックチェーン上で具現化されるので、これは、多くの他の利点の中でも特に、本来、コントラクトの履歴及び結果の永久的に不変な記録を提供することに留意する。

＜実装オプション１：トランザクション－パズルアプローチ＞
本発明の１つの可能な実施形態では、エージェントシステム３は、何らかのインターネット処理能力を備える誰もが参加でき何らかの処理能力をシステム（例えば、ブロックチェーンに基づくＤＦＡコントラクトの確立及び実行のプロバイダ）に提供でき並びに彼らのリソースに対して報酬を与えられる、開放型コンピュータネットワークとして構成される。このような状況では、どの特定エージェントがブロックチェーンにトランザクションを提出するかを予め知ることは不可能である。つまり、エージェントについての任意の特定の情報（例えば、その公開鍵）を使用することは不可能である。しかしながら、トランザクション－パズル種類は、このような状況での使用に適する。この種のトランザクションの一般的なロック／アンロックメカニズムは、次の通りである：
Locking Script: OP_HASH２５６<state s_i puzzle>OP_EQUAL
Unlocking Script:<puzzle s_i solution>
ここで、<state s_i puzzle>=HASH(<state s_i puzzle solution>)であり、パズル解（puzzle solution）自体は、コントラクトのコード、状態のラベル、任意の他の所望の情報、例えば追加セキュリティのための何らかのソルトを含む任意の所望の情報を含み得る。
<state s_i puzzle solution>=HASH(<contract code; state s_i; other data; salt>)
「ソルト（salt）」の概念は従来知られており、本発明の内容において当業者に直ちに理解される。一連のアクションは、図１及び２を参照して以下の通りである。先ず、エージェントシステム（３、ステップ１０１）は、ＤＦＡ構造２を生成する。

遷移テーブルは、ＤＦＡをある状態から別の状態へ移行させるトリガイベントを指定し及び含む。遷移テーブルは、各々の可能な状態遷移について少なくとも１つのトリガイベント又は条件を含む。したがって、トリガは、現在の状態、つまり該状態からＤＦＡがこのトリガイベントの後に移行する、現在の状態と、新しい状態、つまりトリガが開始する遷移の後にＤＦＡが存在する状態である、新しい状態と、に関連付けられる。

図２のステップ１０２で、場合によってはコンピューティングエージェントにより、ＤＦＡの各々の可能な状態のパズルが生成される。遷移テーブル及びその関連付けられた各遷移についてのパズルは外部に格納される。これは、何らかの種類のデータベース又はＤＨＴであって良い。パズルは、コントラクトの実行に参加することを許可されるエージェントにセキュアに分配される。この分配が達成され得る方法には多数の可能性が存在する。好適な実施形態では、これらのステップは、人間の介入を必要とせずに、コンピューティングエージェントにより自動的に実行される。

ステップ１０４で、エージェントは状態Ｓ_０への発生トランザクションを生成する。これは図４に示される通りであって良い。コントラクトに割り当てられる資金は１０ｍＢＴＣ、エージェント料金は３ｍＢＴＣ、及びコントラクトの更なる処理のために出て行く資金は６ｍＢＴＣであるとする（１ｍＢＴＣマイニング料金は暗黙的である）。この段階で、コントラクトはブロックチェーン上の構造として具現化され、その最初の状態ｓ_０にある。つまり、ブロックチェーン上の特定コントラクトの状態ｓ_０に関連付けられたＵＴＸＯが存在する。

図４の説明のためのトランザクションでは、コントラクトに割り当てられる資金は１０ｍＢＴＣ、エージェント（ボットネット）料金は３ｍＢＴＣ、及びコントラクトの更なる処理のために出て行く資金は６ｍＢＴＣであるとする。１ｍＢＴＣマイニング料金は暗黙的である。

図４のトランザクションを検討することにより推測できるように、コントラクトの元の資金はＰ２ＰＫＨ型トランザクションにより（本例では「原資産所有者（originator）」から）受信され、アウトプット０（パズルに基づく）は、パズル解を所有する任意のエージェントによりアンロックでき、アウトプット１（Ｐ２ＰＫＨ）は所望の料金を、ブロックチェーン上にトランザクションを配置することに成功したエージェント３に支払う。

コントラクトの実行により連続するトランザクションが、図５に例示したものと類似する方法で、自動エージェント３により実行される。エージェントは、現在の状態（ｓ_０）に対応するパズル解を取得し、生成し、又は受信するよう構成される。エージェントは、また、適切なインプットを受信し、遷移テーブル（又は遷移テーブルの、現在の状態に対応する一部だけ）を読み出し、及び適切な次の状態（ｆ_ｆ）に対応するパズルを得るために、何らかのエンティティ又は複数のエンティティ（例えば、エージェントシステム内の何らかの他のコンピュータ、又は何らかのデータ／信号ソース）と相互作用する。エージェントは、次に、ブロックチェーンへトランザクションを提出できる。トランザクションがブロックチェーンネットワークにより検証された場合、エージェントは関連する料金を受け取り、ＤＦＡは状態ｆ_ｆになる。図５の遷移では、入ってくる資金は６ｍＢＴＣ、エージェント料金は１ｍＢＴＣ、及びコントラクトの更なる処理のために出て行く資金は４ｍＢＴＣであるとする（１ｍＢＴＣマイニング料金は暗黙的である）。

図６は、可能なトランザクションのうちの最後の構造、つまりコントラクトの実行を完了するトランザクション（ｃ_ｆ）を示す。図６では、インプット部分は、前と同じトランザクションパズルロジックに従い、一方で、アウトプット０は原資産所有者（originator）に返される未使用資金を支払い（上述のように１ｍＢＴＣ）、アウトプット１はエージェントに料金を支払う。図６では、入ってくる資金は４ｍＢＴＣであり、１ｍＢＴＣの未使用資金が原資産所有者（originator）に返され、エージェント料金は２ｍＢＴＣであると仮定する（１ｍＢＴＣのマイニング料金は暗黙的である）。

＜実装オプション２：Ｐ２ＳＨに基づくトランザクション＞
オプション１に記載されたパズルに基づくアプローチは、多数の先験的に不明な参加者が存在する使用に適する。しかしながら、他の場合には、限られた又は許容可能な少数の認知されたコンピューティングエージェント３が、本発明と関連した使用のために設計されて良い。この場合、Ｐ２ＳＨ型のトランザクションは、既知のエージェント３の公開鍵を含むよう構成でき、それにより追加セキュリティレイヤを提供するので、使用に一層適する場合がある。単一の認知されたエージェントの場合には、トランザクションのための実現可能なロック／アンロックメカニズムは次の通りである：
ロックスクリプト：OP_HASH１６０<state s_i redeem script hash>OP_EQUAL
アンロックスクリプト：OP_０<agent signature><state s_i redeem script>
Ｒｅｄｅｅｍスクリプト：OP_１<state s_i metadata><agent public key>OP_２ OP_CHECKMULTISIG
留意すべきことに、これは、多数の認知されたエージェントの署名も含むことにより、多数の認知されたエージェントに拡張できる。前述のように、状態ｓ_ｉのメタデータは、例えば次の任意の所望の情報を含み得る：
<state s_i metadata>=HASH(<contract code; state s_i; other data>)
一連のアクションは、パズルに基づくアプローチの前述の場合と同様である。先ず、エージェントシステム３は、ＤＦＡ構造を生成し、遷移テーブルを外部に（例えばＤＨＴに）格納する。次に、どのエージェントがトランザクションを処理し、彼らの公開鍵を検索し／生成するかが決定される。この公開鍵は、次に、ＤＦＡの各々の可能な状態のＲｅｄｅｅｍスクリプトに含まれる。留意すべきことに、これらのスクリプトは、外部に（ブロックチェーンの外に）格納でき、セキュアに送信される必要がない。次に、コンピューティングエージェントは、図７に指定されるように、発生トランザクションを生成する。図７の例は、図４と類似するが、ＤＦＡ状態のＰ２ＳＨトランザクション型を用いる。

この段階で、コントラクトは、ブロックチェーン上の構造として具現化され、その最初の状態ｓ_０にある。図４に対してトランザクションの唯一の変更は、アウトプット０であり、これはここではＰ２ＳＨ型であり、上述のように認知されたエージェントの公開鍵を含む。

変更は類似するが、詳細のために図８及び９は、Ｐ２ＳＨトランザクション型に基づく遷移トランザクション及び完了トランザクションの例を提供する。資金の流れは上述と同じである。図８は、図５と類似するが、ＤＦＡ状態のＰ２ＳＨトランザクション型を用いる一例を示す。図９は、図６と類似するが、ＤＦＡ状態のＰ２ＳＨトランザクション型を用いる一例を示す。

＜コンピュータにより実施されるＤＦＡのための新規なコード化技術＞
以上にブロックチェーンに基づくＤＦＡを記載したが、ここでは本発明の特に有利な且つ新規な側面に注意を向ける。この章では、ＤＦＡの状態をコンピュータ可読且つ実行可能形式にコード化する新規な本発明の技術を説明する。

このような機械に関する従来の方法では、状態は静的に（先験的に）定められ、システムの何らかの特定の構成又は何らかの特定の意味を表す。例えば、状態はセット又は名称を与えられ、タグのセットに、又はブロックチェーンに基づくＤＦＡについて上述したような未使用トランザクションアウトプット（ＵＴＸＯ）に関連付けられ得る。これは、システムが状態間をどれだけ移動するかにより、計算自体（のアウトプット）が決定され、一方でインプットのチェーンを受け付けるので、システムが動作するのに十分である。

この意味で、ＤＦＡ（つまり、状態、トランザクション、等のセット）はユニークではなく、２つのＤＦＡは等価であり得る。つまり、状態について先験的であると考えられる解釈は非常に難しい可能性があるが、各々の与えられたインプットのチェーンに対して同じアウトプットを生じ得る。例えば、それらが異なる物理的機械に展開され、又は異なる問題を解くために考えられた場合を検討する。これは、また、自然にＤＦＡ最小化の概念につながる（https://en.wikipedia.org/wiki/DFA_minimizationを参照）。

状態の静的決定（タギング）は状態機械自体の抽象機能のために十分であり、計算のアウトプットだけが関連する多くの問題にとって十分であるが、状態自体の意味が実際的に重要であり、状態のタグから推定できない場合がある。これは、例えば、プライバシ又は機密性の理由で意図的に隠されるからであり得る。一例は、計算が分散され、（意図的に）システムについての完全な情報を有しないコンピューティングエージェントにより実行される場合に見出される。これらの場合には、システムの状態の動的決定が、実行時間で必要である。

本願明細書に記載される本発明の有利な態様は、ＤＦＡの状態の動的（オンザフライの、実行時間での）決定を可能にするコード化技術である。このようなＤＦＡは、上述のようなコントラクトの分散型実行に関連付けられるものを含み得るが、包括的ではなく、本発明は、本発明の技術が使用されるＤＦＡの目的、又はそれらの特定の実装に関して限定されない。従来のアプローチは静的方法で状態を予め定めるので、本発明の動的状態決定は、伝統的な方法と逆であり、当業者に完全に異なる技術的ソリューションを提供する。本発明は、生じているイベントに関するデータを格納するためのブロックチェーンの単なる使用の域を超える。

本発明のコード化技術の記載及び説明のために、例としてクーポン債券及び永久債権を使用するが、本発明はこれらの例示的使用又は用途に限定されるものではない。本発明は、非金融用途及び状況に等しく適用可能である。クーポン債券の特性は上述されている。永久債権は、終わりのない絶え間なく続く支払である。つまり、クーポン支払は原則的に永遠に継続する。実際には、しかしながら、正の利率の複利計算（compounding）の効果により、特定の時点で、クーポンの量は実際的意義を有しないので、コントラクトの割引値は実際には有限である。

＜本発明のコード化技術の例１－直接シナリオ＞
既に説明したように、ＤＦＡは有限集合｛Ｓ，Ｉ，ｔ，ｓ_０，Ｆ｝で構成され、それぞれ可能な状態（Ｓ）、インプット（Ｉ）、遷移（ｔ）、初期状態（Ｓ_０）、及び最終状態（Ｆ）を表し、許容状態とも呼ばれる。さらに、アクション（ａ）の集合が定められ、これは実行の副作用を表し、計算のアウトプットを決定しない。

本発明の記載及び説明のために、３期間クーポン債券を検討する。このようなコントラクトについて検討するＤＦＡの要素（及び表記法）は、表２～４に与えられるように静的に定められる。初期状態は、本発明の表記法ではＳにより指定され、許容状態はＦ_０及びＦ_１である。

［表２］クーポン債券のコントラクト状態のリスト

［表３］クーポン債券のコントラクトインプット（イベントアルファベット）のリスト

これらのインプットの全部は、コンピュータにより自動的に検出され決定され得る。表３の上述の例では、特定の日／時間に達したか否か、又は特定の支払がブロックチェーントランザクションを介して行われたか／行われていないかを、コンピュータがチェックすることが可能である。台帳上で支払を行うトランザクションが存在するか否かを調べるために、ブロックチェーンがトラバースされ得る。ビットコインブロックチェーンは永久的な公開された耐タンパー性の記録を提供するので、この検証は、人間の介入を必要とせずに、コンピューティングエージェントにより行うことができる。

［表４］クーポン債券のコントラクトアクションのリスト

これらの要素が定められると、システムの機能は、状態遷移テーブルにより完全に指定され得る。状態遷移テーブルでは、システムの現在の（初期／遷移元）状態（行）と共に適切なインプット（列）が、該テーブルに従い、システムの次の（最終／遷移先）状態、及び遷移と並行して実行されるべきアクションを決定する。本発明の例では、これは、表５に与えられる。実行が初期状態（Ｓ）で開始し、可能な最終（許容）状態はＦ_０及びＦ_１だけであることに留意する。これらの状態は、実行の最終処理を示すので、つまり、それらに関連付けられた遷移が存在しないので、それらはテーブルの行から省略できる。遷移テーブルの代替フォーマットは表５に与えられる。

［表５］クーポン債券の状態遷移テーブル：システムが特定の状態（行）にあり及び特定のインプット（列）が生じると、システムは示された状態に遷移し、示されたアクションを実行する（状態／アクション）；ハイフンは、インプットが所与の状態に無関係であることを示し、つまり状態に適用されない。

状態機械の機能を指定する別の等価な方法は、所謂、状態図である。状態図では、システムの状態は円（blob）により表現され、インプット及びアクションは付随のラベルにより与えられ、遷移は接続矢印により表現される。本発明の例では、図１０に状態図が与えられる。最終（許容）状態Ｆ_０及びＦ_１は、便宜のために、２倍の太さの線の円により示されることに留意する。簡単のため、それらはシステムの実行に関連しないので、アクションは、この図から省略されている。破線ボックス（再帰状態）の意味は、以下で明確にされる。

上述のように、ＤＦＡの機能について厳格である必要はないが、人間及びコンピュータの両者により可読である、システムの状態の動的決定は、実際的に必要であり、本願明細書に記載の本発明の態様を構成する。各状態は、特定の状態の結果として起きる若しくは起きない又は無関係であるユニークな条件セットにより特徴付けられる。各条件は、明示的且つ（機械）テスト可能なものでなければならない。言い換えると、条件が結果として起きるか否かを知らせる明確な計算方法が存在しなければならない。このように、本発明の一実施形態は、物理的世界と、又は、テストのための値若しくはインプットが１又は複数の外部ソースから受信され得るという点で少なくともソフトウェアの実行しているコンピュータの外部の世界と、相互作用して良い。例えば、データが到着すると、又はセンサにより示されるように温度閾が超過すると、又は通知が別のコンピュータから受信されると、等である。これらの条件は、上述のコンピューティングエージェントによりテストされて良い。

本発明の例では、これは、表６に提示した条件セットにより達成できる。表６では、テストされるべき状態は行で与えられ、定義した条件は列で与えられる。各条件ｔは、特定日が到来したか否かを示す。例えば、ｔ０と示される条件はｔ＞ｔ_０を意味し、各条件ｃｉ（又はｐ）は対応する支払が行われたか否かである。未だ期限の来ていないクーポン（又は元金）の支払は、対応する満期に達する前に生じる状態と無関係であることに留意する。

勿論、この又は等価な条件セットが使用されるか否かは、それらが全ての可能な状態を一意に決定する限り、無関係である。つまり、各状態についての真、偽、又は無関係な値のチェーンはユニークである。更に留意すべきことに、本例では２進値（真又は偽）又は無関係な状態だけを検討したが、これらは原理上は複数の値をとり得る。さらに、本願明細書に記載のような原子的な（atomic）条件に加えて、各条件は、また、幾つかの（サブ）条件から成る合成（composed）条件を表し得る。全てのこれらの変形は、当業者に直ちに明らかであり、本発明の範囲内に包含される。

図１０の破線ボックスは、解決すべき最後の点を意味する。現状では、図は完全に有効であり、クーポン債券の動態を正しく記述すべきであるが、状態Ｔ_ｉ及び状態Ｃ_ｉの間には興味深い類似性が存在することに留意する。つまり、これらの状態は、意味において非常に類似し、それらの参照する時間期間又はクーポンの番号（ｉ）においてのみ異なる。したがって、これらの状態は、共通の反復又は再帰状態、並びにそれらがどのクーポン／期間を参照するかを示す追加情報によっても表現され得る。これは、無期限に自身を繰り返す状態に自然に拡張でき、したがって永久債権のコード化の可能性を拓く。このような再帰状態によるコード化方式の定義は、以下の次章で解決される。

［表６］状態定義テーブル：各条件は、特定の状態について、真（Ｔ）、偽（Ｆ）、又は無関係（－）であり、したがって動的テスト可能な値の集合により定められる。

＜本発明のコード化技術の例２－再帰状態＞
上述のように、最後の部分からのクーポン債券ＤＦＡの状態の幾つかのサブセット又はクーポン債券（Ｔ_ｉ及びＤ_ｉ状態）は、状態機械の状態の非常に類似する解釈に対応し、それらの参照する時間期間又はクーポンの番号（ｉ）においてのみ異なる。つまり、ある意味で、それらの状態は、何回も自身を繰り返す状態として考えられる（例えば、ｉ＝１から所与のｉｍａｘまで、本例ではｉｍａｘ＝３）。この場合、全てのこれらの状態を別個に取り扱われるべき再帰状態（Ｒ）に含めることにより、ＤＦＡの表現を簡略化することは意味がある。この簡略化により、以下に、本発明の例示的なクーポン債券のＤＦＡについて、コントラクト条件のリスト（表７）、状態遷移テーブル（表８）、等価状態図（図１１）、状態定義テーブル（表９）を提示する。ＤＦＡの他の要素（インプット及びアクション）が前の章と変わらないことに留意する。

［表７］再帰状態を有するクーポン債券のコントラクト状態のリスト

［表８］再帰状態を有するクーポン債券の状態遷移テーブル

［表９］状態定義テーブル：各条件は、特定の状態について、真（Ｔ）、偽（Ｆ）、又は無関係（－）であり、したがって値の集合により定められ、各条件について１つの値である（また、条件は複数のコンポーネントを有し得る）。

勿論、これは全て、再帰状態の内部の債券動態の複雑性を隠蔽するだけであり、再帰状態は別個に指定されなければならない。しかしながら、複雑な状態機械の場合、この簡略化は重要であり得る。明らかな類似は、プログラミング言語におけるループの導入である。再帰状態自体は、状態機械としても定められる。しかしながら、抽象計算の実行は再帰状態内部の開始又は終了を意味しないので、初期及び許容状態は、この文脈では入口（entry）点及び出口（exit）点により置き換えられることに留意する。以下に、再帰状態についての、コントラクト状態のリスト（表１０）、状態遷移テーブル（表１１）、及び状態図（図１２）を提示する。

［表１０］再帰状態のコントラクトサブ状態のリスト

［表１１］再帰状態の内部状態遷移テーブル

本アプローチの新規性は、状態が何回占有されたかの経過を追うインデックス（ｉ）である。このインデックス及び類似の量（例えば、合計支払金額）の増大は、（後述のようにコード化方式では）外部で計算され、又は状態Ｃについて表１１に示されるように追加ＤＦＡアクションにより達成され得る。この再帰状態の内部状態のインプット（アルファベット）が内部インデックス（ｉ）及び／又は類似の量に依存する可能性があることにも留意する。上述のように、システムの許容され得る状態は、出口点により置き換えられている。対応する等価な状態図は図１２に提示される。

このような再帰状態のコード化方式は、拡張されると、表５の関連部分に非常に類似して見える。しかしながら、このアプローチの精神は、各内部（サブ）状態を別個に拡張し取り扱うことであるので、それを表中に明示的に示さないことはより自然と考えられる。代わりに、図４に、状態機械コード化の条件に関連付けられた変数に正しい値（真又は偽）を割り当てるアルゴリズムの擬似コードを提示する。勿論、無関係な条件に関連付けられた変数は、いかなる値も割り当てられる必要がない。図４では、上記の表５におけるように、各条件ｔｉは、特定日が来たか否かを示し（つまり、ｔｉ＝Ｔはｔ≧ｔ_ｉを意味する）、各条件ｃｉは、対応する（ｉ番目の）クーポンが支払われたか否かを示す。

以下に、再帰状態の内部状態のコード化方式の条件に関連付けられた変数に適切な値を割り当てるアルゴリズムの擬似コードを提供する。

解決されるべき最後の点は、インデックスｉｍａｘにより表される終了点の必要である。通常のクーポン債券は有限の満期を有するが、永久債権は、特に永久に実行する同様の証券である。本発明の再帰状態のコード化技術により、これは、以下に提示するような擬似コードの単純な変更により達成できる。本例では、ループは満期に達していない第１期間に遭遇すると終了するが、勿論、これらの変数は重要ではなく、そのポイントで全ての状態がコード化技術により一意に定められることに留意する。つまり、真及び偽の値の組み合わせは各状態にユニークである。以下の擬似コードは永久債権のためのものである。

［表１１］表５のクーポン債券の状態遷移テーブルの代替フォーマット

＜コンピュータにより実施されるＤＦＡのコンパイル及び実行＞
ここでは、状態機械としてモデル化された計算構造としての異なるパーティの責務の実現（及び他の条項及び規定）に基づくコントラクト上の合意の確立（コンパイル）及び実行のための新規技術を説明する。

このシナリオでは、ブロックチェーンを介するこのようなスマートコントラクトの確立及び実行に関する、システムの有利な技術的側面を記載する。これは、コントラクトを事実上履行する異なる（コンピュータ）エージェント間の情報の流れを扱う。非常に一般的に、このシステムを「ボットネット」（コンピューティングエージェントの集合）と表し、どのエージェントが実際に記載のアクションを実行するかを指定しない場合が多い。当業者は、このような実装の詳細事項を具現化する多くの方法が存在することを理解する。

上述のように、欧州買い付け選択権（コールオプション）のコントラクトを、本発明の本態様を説明するための一例として用いる。欧州買い付け選択権（コールオプション）は、投資家に株式、債券、産物、又は他の資産を指定価格（権利行使価格、strike price）で指定日（満期日、exercise date）に購入する権利を与えるが義務を与えない合意である。買い手がオプションを実行することを決定した場合、この決定はその日の資産の価格が権利行使価格（strike）より高い場合に（合理的に）生じるが、オプションの作者（売り手）自身は、その日に、その価格で、資産を保持者（買い手）に売る。この場合、コントラクトは代替として、満期日における資産の市場価格から権利行使価格を差し引いた額に等しい額の保持者への支払により精算されて良く、その他の場合に支払は必要なく、オプションは行使されずに終了すると仮定する。

（金融）コントラクトを確立し及び実行する標準的な方法は、人間により、法的文書に署名し、その条項を解釈させ及び実行させ、時には争わせることである。これらのコントラクトは、項目を定める文字、及びコントラクトに特有のパラメータの値の集合、例えば日付、作者、公開鍵、等から成ると考えられる。これらの別個の要素は、本発明のシステムでは分離される。ここで、コントラクトの文字の本質は、抽象機械としてキャプチャされ、ＤＦＡ、及びコントラクトの特定インスタンスのパラメータの値の集合は、上述のように独立して提供される。

本発明の例に戻ると、ＤＦＡ計算システムは有限集合｛Ｓ，Ｉ，ｔ，ｓ_０，Ｆ｝で構成され、それぞれ可能な状態（Ｓ）、インプット（Ｉ）、遷移（ｔ）、初期状態（Ｓ_０）、及び最終状態（Ｆ）を表し、許容状態とも呼ばれる。さらに、ＤＦＡ構造自体にとって本質的ではないが、ここでは、エージェントがトランザクションの提出と並行して実行することを要求されるアクション（ａ）の集合を検討する。以下では、従来のように、現在時間（日付）はｔにより、満期日はＴにより、満了時の資産価格はＳ_Ｔにより、及び行使価格はＫにより示される。

本願の本章における主な焦点は、ＤＦＡ機械の状態に関連付けられたコンピュータエージェントの確立である。これらは、スクリプトを有するコンピューティングリソースとして実装される。留意すべきことに、用語「スクリプト」は、この文脈で、アンロック又はロックスクリプトのようなブロックチェーントランザクションのスクリプトと混同されるべきではない。ここで、用語「スクリプト」は、より一般的なコンピュータ処理上の意味で使用される。当業者は、これを直ちに理解し、用語の意味を文脈から解釈し得る。

エージェント（スクリプト）は、状態を変え、遷移を実施し、並行して、後の状態に関連付けられたスクリプトの他のセットを派生（スピンオフ、spin－off）できる。適切な能力を有するコンピュータスクリプトによるＤＦＡ状態の動態、つまり実行時間識別は、本発明の本態様の主要な独創的要素である。本発明の合理化された例では、コントラクトの可能な状態及びそれらの定義のための十分な条件は、表１２に与えられる。ここで、状態の（ＸＭＬ）ラベル及び状態の自然（人間の）言語による説明も与えられる。

必ずしも全ての考えられる状態が、例えば倒産、保持者の死、インターネットのシャットダウン、等のイベントで何が生じ得るかが、コントラクトの中で検討されないことに留意する。しかしながら、本発明の本章における現在の焦点は、コントラクトのコンパイル及び実行の分析であり、ＤＦＡ自体の複雑性ではないので、本発明の例は適切であり、これ以上ではないが可能な限り単純である。

［表１２］本章の例についての状態定義テーブルを示す：各条件は、特定の状態について、真（Ｔ）、偽（Ｆ）、又は無関係（－）であり、したがってこの値の集合により定められ、各条件について１つの値がある；また、条件は複数のコンポーネントを有し得ることに留意する。

抽象ＤＦＡの異なる要素の説明を続け、以下のインプットのリストを参照する。これは、イベント、アルファベットとしても呼ばれる。これは、コントラクトと関連して生じ得るイベントのリストである。例えば、満了に達した、支払を受け取った、等である。これらのインプットは、ＤＦＡの現在の状態のセットと一緒に、ブロックチェーンに提出されるべきトランザクション、並びに、エージェントにより実行されるべき並行アクションを決定する。しかしながら、技術的には遷移関数はＳ×Ｉ→Ｓマッピングであるが、必ずしも全てのインプットが全ての状態に関連しないことに留意する。本発明の合理化された例では、これらは、（ＸＭＬ）ラベル及びイベントの自然言語による説明と一緒に、表１３に与えられる。

［表１３］コントラクトインプット（イベントアルファベット）のリスト

計算上、イベントは、状態を定義する条件の中の変化としても考えられるが、上述のように、幾つかのイベントは、一部の（又は全部の）状態と無関係であり、状態遷移を生じない。同じように、可能なアクションのリストは、必ずしも全部が全部の状態に関連しないが、表１４に指定され得る。

［表１４］コントラクトアクションのリスト

全てのこれらの要素が定められると、状態遷移テーブルに集められる。状態遷移テーブルでは、システムの現在の（初期）状態（行）は、適切なインプット（列）と一緒に、該テーブルに従い、システムの次の（最終）状態、並びに遷移と並行して実行されるべきアクションを決定する。本発明のＤＦＡでは、遷移トランザクションに加えて、完了トランザクションも考えられる。完了トランザクションは、システムを後の状態に置く代わりに、システムを許容状態（ｆ）に置く。許容状態（ｆ）は、コントラクトの事項の終了を表す仮想（例えば、ブロックチェーン上で具現化されず、どのスクリプトにも関連付けられない）状態である。本発明の欧州買い付け選択権（コールオプション）の例は表１５に与えられる。表１５では、初期状態は行に、インプットは列に関連付けられ、各セルは後の状態／アクションフィールドを含む。

［表１５］コントラクトの状態遷移テーブル

さらに、本発明の例では、図１３に示す状態図により抽象ＤＦＡを表すことが一般的である。本図と（計算上有用である）状態遷移テーブルとの間の対応があることに留意する。したがって、いかなる追加情報も図自体に含まれない。図１３は、欧州買い付け選択権（コールオプション）の例を示し、状態（円）及び提出されるべきブロックチェーントランザクション（三角形）：発生（ｏ）、遷移（ｔ）、及び完了（ｃ）を示す。

＜技術的説明＞
ＤＦＡコンパイルメカニズムは、以下に議論される異なる要素及びファイルで構成される。これらのファイルに埋め込まれる計算構造、異なる状態に関連付けられたスクリプトがブロックチェーントランザクションだけでなく、コントラクトを完全に実行する後のスクリプトをどのように生成するかが、本願の本章の主な焦点である。始めに、システムは、本例では以下の２つのソースファイルを使用する。

DFA European call option－parameters.xml
DFA European call option－script.py
ここで、具体性のために、後のファイルの生成及びコントラクトの実行のために使用される主要言語はＰｙｔｈｏｎ３．５であり、及びパラメータはＸＭＬ１．０文書で提供されると仮定する。勿論、これらの実装の詳細事項は、本発明にとって必須ではなく、当業者は、他の規格の使用が等しく許容可能であることを理解する。

ＸＭＬ文書は、間近な特定のコントラクト、つまり、ある特定の欧州買い付け選択権のための（ＸＭＬタグにより指定される）パラメータフィールド及び値のリストを含む。本例では、これは手書きであるが、自動的に、つまりコンピューティングリソース又はエージェントにより、又は人間がここでもＰｙｔｈｏｎにより作成され得るグラフィカルユーザインタフェース（ＧＵＩ）を介して適切な値を入力することにより、生成されても良い。

システムの技術的仕様の主要ファイルは、（Ｐｙｔｈｏｎ）主要スクリプトである。このファイルは、抽象状態遷移テーブル（可能な状態、インプット、及びアクション）のハードコードバージョン、考慮されるべきＤＦＡインプット及びアクション（例えば、株価、クロック、等をどのように調べるか）を指定するハードコードされた関数、を含み、又は実行されると挿入する。関連する場合、つまりブロックチェーンに基づくＤＦＡ実装では、このファイルは、スクリプトによりネットワークへ提出されるべき（ビットコイン）トランザクションのハードコードされたテンプレートを含んで良い。

上述のように、状態遷移テーブルは、抽象レベルでＤＦＡを完全に決定し、それ自体の機能のために必要な要素だけである。しかしながら、法律文とＤＦＡ状態遷移テーブルとの間に対応があることに留意する。これらの必須要素に加えて、任意で、スクリプトは、異なる人間可読文書、例えば状態図、アルファベット、等を含み／生成することも可能である。

ブロックチェーンに基づくＤＦＡコントラクトをコンパイルし及び実行するために、ユーザ（人間又はコンピュータ）は、パラメータの値を埋め、主要スクリプトを実行する必要がある。スクリプト上のこのハードコードされた情報、及びパラメータの値を用いて、実行すると、スクリプトは、コントラクトを確立し、例えばコントラクトをブロックチェーン上に置き、１又は複数のコンピュータプログラム（他のスクリプト）を生成する。該１又は複数のコンピュータプログラムは、コントラクトを実行するコンピューティングエージェントのシステムにより連続して実行される。これを達成し得る可能な一連の命令は以下の通りである：
１．パラメータ値（又は値をＧＵＩから直接入力する）を読み出す。これは、パラメータ値をメモリに、例えばハッシュテーブル（ＨＴ）構造（これはＰｙｔｈｏｎではディクショナリと呼ばれる）に又は分散ハッシュテーブル（ＤＨＴ）に、例えば、これが何らかの利益をもたらす場合にはビットトレント（bitTorrent）ネットワークに、ロードする。
２．適法コントラクトを生成するために、パラメータ及びハードコードされたコントラクトテンプレートを使用する。この文書は、買い付け選択権の作成者により（デジタル方式で）署名される必要がある。
３．（任意）コントラクトの人間可読文書を生成する。
４．適切なパラメータ値により、これらの関数のインスタンスを生成するために、パラメータ及びハードコードされたインプット及びアクション関数を使用する。
５．メモリ（ＨＴ又はＤＨＴ）に状態遷移テーブルをロードする。
６．関連する場合、指定されたように発生トランザクションを生成し、それをブロックチェーンネットワークに提出する。これは、Pybitcointoolsライブラリを用いることにより実行できる。これは、上述のように、ビットコインブロックチェーン上のコントラクトの特定の状態に関連付けられたブロックチェーン内にＵＴＸＯを生成する。
７．発生状態（ｓ_０）に関連付けられたＰｙｔｈｏｎスクリプトを生成し、それを（同じ又は他のコンピュータ上で）実行する。このエージェント（又はエージェントの集合）は、適切なインプットを受信し／生成し、適切なアクション、状態に適合するアクションを実行し、最終的にはコントラクトの実行を完了し又は別の状態への遷移トランザクション並びにこれらの状態を制御する派生した後のスクリプトを生成する。
８．コンパイル（主要スクリプト）を終了する。

コンパイル段階の終了により、システムは、起動し実行する。本例の一実施形態によると、コントラクトの初期状態に関連付けられたブロックチェーン上のＵＴＸＯが存在し、インプットを監視している１又は複数のエージェント（ボットネットエージェント上で実行するＰｙｔｈｏｎスクリプト）は、アクションを行い及びＤＦＡの状態を別の状態に変更する又は終了させる適切な遷移を生成する準備ができている。

遷移のための一連の命令は次の通りである：
１．ＤＦＡインプットを監視し又は生成する。クロックのチェック、メッセージの受信、等のような関数呼び出し。
２．インプットが決定されると、現在の状態のための遷移テーブルを読み出す。これは、次の状態、及び場合によっては行われるべきアクションを決定する。
３．もしあれば、複雑性に依存して、場合によってはサブルーチン又は関数呼び出しに対してアクションを行う。
４．関連する場合、ブロックチェーンに従い遷移トランザクションを生成し、それをブロックチェーンに提出する。
５．次の状態に関連付けられたＰｙｔｈｏｎを生成し実行する。
６．現在のスクリプトを終了する。
コントラクトの完了のための一連の命令は次の通りである：
１．ＤＦＡインプットを監視し又は生成する。これらは、クロックのチェック、メッセージの受信、等のようなサブルーチン又は関数呼び出しであり得る。
２．インプットが決定されると、現在の状態のための遷移テーブルを読み出す。これは、コントラクトが完了されるべきであること、及び場合によっては行われたアクションを決定する。
３．もしあれば、複雑性に依存して、場合によっては関数呼び出しに対してアクションを行う。
４．関連する場合、ブロックチェーンに従い完了トランザクションを生成し、それをブロックチェーンに提出する。これは、コントラクトに関連付けられた最後のＵＴＸＯを使用する。
５．現在の（且つ最後の）スクリプトを終了する。

したがって、ＤＦＡは、独立エージェント（スクリプト）の集合により実行される。独立エージェント（スクリプト）の集合は、前のエージェントから十分な情報を受信し、次に初期主要スクリプト及びパラメータファイルに戻る。

したがって、本発明の一実施形態によると、コントラクトは、エージェントの集合（スクリプトとして実装される）により実行され、システムが状態間で移行するとき動的に生成される。これらのエージェントは、システムの現在の状態へのアクセスを有し（例えば、ブロックチェーン上のＵＴＸＯにより具現化されるとき）、現実世界で生じるイベントに従い適正なインプットを受信し又は生成し、適切なアクションを行い、並びに適切なトランザクションを実行する必要がある。このうち全部が、適切に定義された関数及び既存のライブラリを用いて、（例えばＰｙｔｈｏｎ）スクリプト内で達成されて良い。例えば、本願明細書における欧州買い付け選択権の例では、クロックへの、コントラクトの満了に達したか否かのチェックへの、及び資産の現在価格へのアクセスを有するべきである。この情報が与えられると、パラメータに従い検討すべき適切なインプットがどれかを決定できる。これ、及びトランザクション行列の中で指定されたアクションが与えられると、エージェントは、どのブロックチェーントランザクションを生成すべきかを決定でき、それによりシステムを次の状態に置き（本例では、１つの状態だけがある）、又は適切にコントラクトの実行を完了する。

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

１ ブロックチェーン
２ ＤＦＡ
３ エージェント
４ 世界
５ ＤＨＴ

Claims (18)

1. ブロックチェーン上でＤＦＡを実施する方法であって、
   ブロックチェーントランザクション（Ｔｘ_１）の未使用アウトプット（ＵＴＸＯ_１）のロックスクリプト内のデータの一部を前記ＤＦＡの所与の状態に関連付けるステップ、
   を含み、
   前記ＤＦＡは、特定期間の間保持される債権に関連付けられる、方法。
2. 前記ＤＦＡの前記状態は、前記債権が保持されている保持状態、前記債権が正常終了した正常終了状態、又は前記債権が失敗した失敗状態である、請求項１に記載の方法。
3. 前記トランザクション（Ｔｘ_１）の前記アウトプット（ＵＴＸＯ_１）を使用することにより、更なるトランザクション（Ｔｘ_２）を用いて、前記ＤＦＡの前記状態を更なる状態へ遷移させるステップ、
   を更に含み、前記更なる状態は、前記更なるトランザクションの未使用アウトプット（ＵＴＸＯ_２）のロックスクリプト内で提供されるデータの一部に関連付けられる、請求項１又は２に記載の方法。
4. コードの一部を用いて、少なくとも１つの状態遷移トリガを実施し又は表すステップであって、前記状態遷移トリガは、実行されると、更なるトランザクション（Ｔｘ_２）に前記トランザクション（Ｔｘ_１）の前記アウトプット（ＵＴＸＯ_１）を使用させ、したがって前記ＤＦＡを別の状態に移動させる、ステップ、
   を更に含む請求項１乃至３のいずれか一項に記載の方法。
5. 前記コードの一部は、インプットに基づくブール結果を提供する機械テスト可能条件を含む、請求項４に記載の方法。
6. 前記インプットは、ランタイムにおいて決定され、前記ＤＦＡを前記更なる状態に移動させるために前記未使用アウトプット（ＵＴＸＯ_１）が使用されるべきか否かを決定するために前記コードの一部により使用される、請求項５に記載の方法。
7. 前記未使用アウトプット（ＵＴＸＯ_１）内の前記データの一部はロックスクリプト内で提供される、請求項１乃至６のいずれか一項に記載の方法。
8. 前記データの一部は、タグ、ラベル、又はメタデータの一部である、請求項７に記載の方法。
9. 前記ＤＦＡは機械実行可能スマートコントラクトのモデルである、請求項１乃至８のいずれか一項に記載の方法。
10. 前記未使用アウトプット（ＵＴＸＯ_１）は、パズルのハッシュを有するロックスクリプトを含み、前記パズルの解は、前記アウトプット（ＵＴＸＯ_１）を使用し及び前記ＤＦＡを別の状態に遷移させるために更なるトランザクションのインプットにより提供されなければならない、請求項１乃至９のいずれか一項に記載の方法。
11. 前記未使用アウトプット（ＵＴＸＯ_１）は、Ｒｅｄｅｅｍスクリプトのハッシュを有するロックスクリプトを含み、前記Ｒｅｄｅｅｍスクリプトは、前記アウトプット（ＵＴＸＯ_１）を使用し及び前記ＤＦＡを別の状態に遷移させるために更なるトランザクションのインプットにより提供されなければならない、請求項１乃至１０のいずれか一項に記載の方法。
12. 前記Ｒｅｄｅｅｍスクリプトは暗号鍵を有する、請求項１１に記載の方法。
13. 前記更なるトランザクションの前記インプットは、前記債権の満了時の返済金、前記債権の満了時の債務不履行、又は前記債権の返金を伴わない終了である、請求項１０乃至１２のいずれか一項に記載の方法。
14. １又は複数のコンピューティングエージェントを使用して、請求項１乃至１３のいずれか一項に記載のステップを実行するステップ、を更に含む請求項１乃至１３のいずれか一項に記載の方法。
15. ブロックチェーン上でＤＦＡを実施する方法であって、前記方法は、
    プログラムを実行するステップであって、前記プログラムは、インプット信号を監視し及び／又は受信し、前記インプット信号に応答し、未使用アウトプット（ＵＴＸＯ）を含み且つ前のトランザクションＴｘ_１のアウトプットを使用するブロックチェーントランザクションＴｘ_２を生成するよう構成される、ステップを含み、
    前のトランザクションＴｘ_１の前記アウトプットは、前記ＤＦＡの第１状態に関連付けられた識別子を含むロックスクリプトを有し、
    トランザクションＴｘ_２の前記未使用アウトプット（ＵＴＸＯ）は、前記ＤＦＡの更なる状態に関連付けられた更なる識別子を含むロックスクリプトを有し、前記ＤＦＡは、特定期間の間保持される債権に関連付けられ、前記ＤＦＡの前記状態は、前記債権が保持されている保持状態、前記債権が正常終了した正常終了状態、又は前記債権が失敗した失敗状態である、方法。
16. ブロックチェーン上でＤＦＡを実施する方法であって、
    少なくとも１つのインプット信号を用いて、少なくとも１つの条件を実行し、前記条件の前記実行の結果に基づき、前記ＤＦＡの状態遷移テーブルに従いアクションを実行するステップ、
    を含み、前記アクションの実行は、ブロックチェーン台帳の状態から識別可能であり、前記ＤＦＡは、特定期間の間保持される債権に関連付けられ、前記ＤＦＡの前記状態は、前記債権が保持されている保持状態、前記債権が正常終了した正常終了状態、又は前記債権が失敗した失敗状態である、方法。
17. 請求項１乃至１６のいずれか一項に記載の方法を実行するよう構成されたシステム。
18. 前記システムは、
    ブロックチェーンプラットフォームと、
    前記ブロックチェーンを介して前記ＤＦＡを実施するよう構成される少なくとも１つのコンピューティングエージェントと、
    を含む請求項１７に記載のシステム。

Images