JP2024001326A - 契約の実行を制御する方法及びシステム - Google Patents

Abstract

【課題】スマートコントラクトの実行を制御するコンピュータにより実現する方法及びシステムを提供する。
【解決手段】方法は、コンピュータベースレポジトリに契約を格納することを含む。契約は、第１ユーザ（Ｕ１）と第２ユーザ（Ｕ２）との間のライセンスに関連する。方法は更に、通信ネットワークを介しエージェント（第１のコンピュータ）からＵ１又はＵ２へのトークンの移動を含むトランザクションを受信することを含む。トランザクションは、契約を格納する場所を示す識別子を含むメタデータを有する。方法はまた、トランザクションが少なくとも１つの未使用出力（ＵＴＸＯ）を有するか判断するため、ピア・ツー・ピア分散型台帳（すなわち、ブロックチェーン）を照会することと、ピア・ツー・ピア分散型台帳を照会したことに応答して、契約の実行を修正するか判断することと、を含む。ブロックチェーンは、ビットコインブロックチェーンであってもよい。
【選択図】図１

Description

本開示は、コンピュータソフトウェアをセキュアにし、分散ハッシュテーブル及びピア・ツー・ピア分散型台帳を利用してコンピュータソフトウェアへのアクセスを許可する方法に関する。

本文献では、全ての形式の電子的なコンピュータベースの分散型台帳を含むよう“ブロックチェーン”という用語を使用する。これらは、コンセンサスベースブロックチェーン及びトランザクションチェーン技術、許可型及び非許可型台帳、共有台帳及びこれらの変形を含む。他のブロックチェーン実現形態が提案及び開発されてきたが、ブロックチェーン技術の最も広く知られている用途は、ビットコイン台帳である。便宜上及び説明のため、ビットコインがここでは参照されるかもしれないが、本発明はビットコインブロックチェーンによる利用に限定されず、他のブロックチェーン実現形態及びプロトコルが本発明の範囲内に属することが留意されるべきである。“ユーザ”という用語は、ここでは人間又はプロセッサベースリソースを表しうる。

ブロックチェーンは、トランザクションから構成されるブロックから構成されたコンピュータベースの非中央化された分散システムとして実現されるピア・ツー・ピア電子台帳である。各トランザクションは、ブロックチェーンシステムにおける参加者間のデジタルアセットの制御の移動を符号化し、少なくとも１つの入力と少なくとも１つの出力とを含むデータ構造である。各ブロックは、開始以来ブロックチェーンに書き込まれてきた全てのトランザクションの永続的で変更不可なレコードを作成するために一緒にチェーン化されたブロックに対する前のブロックのハッシュを含む。トランザクションは、それらの入力及び出力に埋め込まれたスクリプトとして知られる小さなプログラムを含み、それらは、トランザクションの出力が誰によってどのようにしてアクセス可能であるかを指定する。ビットコインプラットフォーム上では、これらのスクリプトは、スタックベーススクリプト言語を利用して記述される。

トランザクションがブロックチェーンに書き込まれるため、それは“検証（validated）”される必要がある。ネットワークノード（マイナー）は、無効なトランザクションがネットワークから拒絶されることによって、各トランザクションが有効であることを保証するための作業を実行する。ノード上にインストールされたソフトウェアクライアントは、それのロック及びアンロックスクリプトを実行することによって、未使用トランザクション（UTXO）に対して当該検証作業を実行する。ロック及びアンロックスクリプトの実行がTRUEと評価された場合、トランザクションは有効であり、当該トランザクションはブロックチェーンに書き込まれる。従って、トランザクションがブロックチェーンに書き込まれるため、それは、i)トランザクションを受信した第１のノードによって検証される必要があり、トランザクションが検証された場合、ノードはそれをネットワークにおけるその他のノードに中継し、ii)マイナーによって構築された新たなブロックに追加され、iii)マイニングされる、すなわち、過去のトランザクションのパブリック台帳に加えられる必要がある。

ブロックチェーン技術は仮想通貨の実現形態の利用について最も広く知られているが、デジタル起業家は、新たなシステムを実現するため、ビットコインが基づく暗号化セキュリティシステムとブロックチェーン上に格納可能なデータとの双方の利用を探求し始めた。ブロックチェーンが仮想通貨の領域に限定されない自動化タスク及びプロセスに利用可能である場合、それは大変効果的であろう。そのような解決策は、それらの用途においてより多用途にしながら、ブロックチェーンの利点（例えば、永続的で改ざん耐性なイベントの記録、分散処理など）を利用することが可能であろう。

現在の研究の１つのエリアは、“スマートコントラクト（smart contract）”の実現のためのブロックチェーンの利用である。これらは、契約又は合意などの機械可読な文書の取り決めの実行を自動化するよう設計されたコンピュータプログラムである。自然言語で記述される従来の契約とは異なり、スマートコントラクトは、結果を生じさせるために入力を処理可能なルールを含み、これらの結果に応じてアクションを実行させる機械実行可能なプログラムである。

ブロックチェーン関連の興味の他のエリアは、ブロックチェーンを介し現実世界のエンティティを表現及び異動するための“トークン”（又は“カラーコイン”）の利用である。潜在的に機密又は秘密のアイテムは、識別可能な意味又は値を有さないトークンによって表すことができる。従って、トークンは、現実世界のアイテムがブロックチェーンから参照可能にする識別子として機能する。

技術研究のこれらのエリアは、例えば、ソフトウェアなどのデジタルアセットの制御に関する効果に適用されうる。コンピュータソフトウェアの完全性及び共有をセキュアにする従来のアプローチは、コンピュータソフトウェアの実行可能ファイルのデジタル署名を伴う。例えば、公開鍵及び秘密鍵などの暗号鍵ペアによって実行可能ファイル又は他の関連するコードを署名する。公開鍵はしばしば、認証機関などの信頼される中央機関から取得される。

コンピュータソフトウェアはしばしば、契約上の義務を含むライセンスを伴う。ライセンスは、ソフトウェアの使用又は再配布を規定する取り決めを含みうる。コンピュータソフトウェア又は関連するライセンスが他のユーザに不当に転送される問題が生じうる。

本明細書に含まれる文献、行為、物質、デバイス、物などの何れの議論も、これらの題材の何れか又は全てが先行技術の基礎の一部を構成するか、あるいは、本出願の各請求項の優先日前に存在するかのような本開示に関連する分野における共通の一般的知識であったという自認としてとられるべきでない。

本明細書を通じて、“有する”という単語又は派生語は、他の何れかの要素、整数若しくはステップ又は要素、整数若しくはステップの群の排除でなく、記載された要素、整数若しくはステップ又は要素、整数若しくはステップの群の包含を意味すると理解される。

本発明は、コンピュータにより実現される制御方法を含みうる。それは、コンピュータにより実行される処理の実行を制御するよう構成されうる。当該処理は、契約によって指定されうる。契約は、マシーン実行可能ドキュメントであるスマートコントラクトであってもよい。“ユーザ”という用語は、ここでは人間のユーザ又はマシーン（コンピュータ）を参照するのに利用されうる。さらに又はあるいは、本発明は、セキュリティ手段（方法／システム）を提供するとして説明されうる。それは、制御されたリソース又はデジタルアセットのインテグリティを保存するよう構成されうる。それは、制御されたリソース又はデジタルアセットの移動を制御するよう構成されうる。リソース又はアセットはソフトウェアであってもよい。

当該方法は、
コンピュータベースレポジトリに（スマート）契約を格納するステップであって、契約は第１ユーザ（Ｕ１）と第２ユーザ（Ｕ２）とに関連する、格納するステップと、
少なくとも１つの出力を含み、通信ネットワークを介しエージェント又は第１コンピュータ（Ａ）から第１ユーザ（Ｕ１）又は第２ユーザ（Ｕ２）（第２ユーザは第２コンピュータである）に移動されるトークンを含むブロックチェーントランザクションを受信するステップであって、トランザクションは、契約が格納されている場所を示す識別子を含むメタデータを含む、受信するステップと、
トランザクションが少なくとも１つの未使用出力（ＵＴＸＯ）を含むか判断するため、ピア・ツー・ピア分散型台帳を照会するステップと、
ピア・ツー・ピア分散型台帳を照会したことに応答して、契約の実行を修正するか判断するステップと、
を有してもよい。

未使用出力（ＵＴＸＯ）は、契約の表現を有してもよい。ピア・ツー・ピア分散型台帳を照会するステップは、トランザクションが契約を表す少なくとも１つの未使用出力（ＵＴＸＯ）を含むか判断するため、ピア・ツー・ピア分散型台帳（ブロックチェーン）をスキャンするステップを含んでもよい。契約は、第１ユーザと第２ユーザとの間のライセンスに関連してもよい。

トランザクションは更に、決定的なリディームスクリプトアドレスを含んでもよい。リディームスクリプトアドレスは、ペイ・ツー・スクリプト・ハッシュ（Ｐ２ＳＨ）アドレスであってもよい。従って、契約の存在は、契約の発行者及び／又は契約のメタデータによって決定又は提供されうるペイ・ツー・スクリプト・ハッシュアドレスを利用して、ピア・ツー・ピア分散型台帳（例えば、ブロックチェーン）に公開されたトランザクションを利用して公的に利用可能とされてもよい。

判断するステップは、少なくとも１つの未使用出力（ＵＴＸＯ）がピア・ツー・ピア分散型台帳から特定不可である場合、契約を終了するステップ、又は、少なくとも１つの未使用出力（ＵＴＸＯ）がピア・ツー・ピア分散型台帳から特定される場合、契約を維持するステップを有してもよい。

契約を終了するステップは、少なくとも１つの未使用出力（ＵＴＸＯ）を使用するため、更なるトランザクションをブロードキャストするステップを含んでもよい。さらに、更なるトランザクションをブロードキャストするステップにおいて、更なるトランザクションは、指定されたデータ及び／又は時間において少なくとも１つの未使用出力（ＵＴＸＯ）を使用する命令を含んでもよい。例えば、命令はＣｈｅｃｋＬｏｃｋＴｉｍｅＶｅｒｉｆｙ命令であってもよい。

更なるトランザクションは、少なくとも１つの未使用出力（ＵＴＸＯ）である入力と、シグネチャ、メタデータ、エージェントに関連するエージェント公開鍵（ＰＡ）及び第１ユーザ（Ｕ１）に関連する第１ユーザ公開鍵（ＰＵ１）を含むリディームスクリプトとを含んでもよい。これは、ピア・ツー・ピア分散型台帳上の未使用出力（ＵＴＸＯ）を使用するためのトランザクションを実現することによって、契約及び従ってライセンスの自動終了の利点を提供する。

契約は、第１ユーザ（Ｕ１）と第２ユーザ（Ｕ２）との間のライセンスの処理に関する少なくとも１つの条件と、実行が条件の評価に依存する少なくとも１つのアクションとを定義してもよい。条件は、真又は偽と評価可能なテストであってもよい。条件は契約の一部（例えば、条項）であってもよい。条件の完了又は実行は、契約の実行のため必要されうる。条件は、それが信徒評価された場合、完了されうる。

メタデータは、契約がコンピュータベースレポジトリに格納されているアドレスのアドレス又は表現、及び／又は契約のハッシュを含んでもよい。

ピア・ツー・ピア分散型台帳を照会するステップは更に、少なくとも１つの未使用出力（ＵＴＸＯ）がピア・ツー・ピア分散型台帳の未使用トランザクション出力のリストに存在するか判断することによって、契約が終了したかチェックするステップを含んでもよい。

コンピュータベースレポジトリは、サーバであってもよいし、あるいは含んでもよい。レポジトリは、コンピュータベースリソース上に設けられるデータベース又はストレージ施設であってもよい。レポジトリは、インデックス付けされ、検索が可能とされてもよい。レポジトリは、分散ハッシュテーブル（ＤＨＴ）を有してもよい。契約は、ＤＨＴ内又は関連付けして格納されてもよい。

契約は、契約を実現する決定的有限オートマトン（ＤＦＡ）を含んでもよい。さらに、決定的有限オートマトン（ＤＦＡ）は、コード化方式を利用して定義されてもよい。

当該方法は更に、契約に関連する前の鍵に関するサブ鍵を生成するステップと、サブ鍵、契約の場所及び契約のハッシュを含む更なるリディームスクリプトを生成するステップと、更なるリディームスクリプトにある量の仮想通貨を支払うステップと、を実行することによって、契約を更新するステップを有してもよい。

当該方法は更に、契約から導出されるサブ契約を生成するステップを更に有してもよく、サブ契約は、決定的アドレスに関連し、シードを用いて導出される新たな公開鍵を利用するステップと、契約に対するリファレンスと共にコンピュータベースレポジトリにサブ契約を格納するステップと、契約に対するリファレンスを含むサブ契約トランザクションをピア・ツー・ピア分散型台帳にブロードキャストするステップと、契約に関連するメタデータにサブ契約に対するリファレンスを追加するステップと、を実行することによって生成される。

第１ユーザ（Ｕ１）と第２ユーザ（Ｕ２）との間のライセンスは、コンピュータソフトウェアと、音楽、ビデオ及び電子書籍を含むデジタルメディアとの１つ以上に関するものであってもよい。

ピア・ツー・ピア分散型台帳は、ブロックチェーンであってもよい。さらに、仮想通貨は、ビットコインであってもよい。

本発明はまた、上述した発明の何れかの実施例を実行するよう構成されるコンピュータにより実現されるシステムを含んでもよい。

上述した方法を処理デバイスに実現させるマシーン可読命令を有するコンピュータソフトウェアプログラム。

本発明は、上述した方法の何れかの実施例に対応するコンピュータシステムを含みうる。当該方法は、（スマート）契約において定義されるようなコンピュータにより実現される処理の実行を制御するよう構成されうる。当該システムは、コンピュータベースレポジトリに契約を格納し、契約は第１ユーザ（Ｕ１）と第２ユーザ（Ｕ２）との間のライセンスに関連してもよく、
少なくとも１つの出力を含み、通信ネットワークを介しエージェント（Ａ）（例えば、第１コンピュータ）から第２コンピュータ（第１ユーザ（Ｕ１）又は第２ユーザ（Ｕ２）であってもよい）に移動されるトークンの移動を含むブロックチェーントランザクションを受信し、トランザクションは、契約が格納されている場所を示す識別子を含むメタデータを含み、
トランザクションが少なくとも１つの未使用出力（ＵＴＸＯ）を含むか判断するため、ピア・ツー・ピア分散型台帳を照会し、
ピア・ツー・ピア分散型台帳を照会したことに応答して、契約の実行を修正するか判断するよう構成される処理デバイスを有してもよい。

未使用出力（ＵＴＸＯ）は、契約の表現を含んでもよい。ピア・ツー・ピア分散型台帳（ブロックチェーン）を照会することは、トランザクションが契約を表現する少なくとも１つの未使用出力（ＵＴＸＯ）を有するか判断するため、ピア・ツー・ピア分散型台帳をスキャンすることを含んでもよい。

一態様又は実施例に関して上述した何れかの特徴はまた、他の何れかの態様又は実施例と共に利用されてもよい。本発明のシステムに関して説明される何れかの特徴は、対応する方法に適用可能であってもよい。

ハッシュテーブルの具体例を示す。 分散ハッシュテーブルを利用してコンピュータソフトウェアをセキュアにするメタデータ（Ｍ）を決定する一例となるシステムの概略図を示す。 分散ハッシュテーブルを利用してコンピュータソフトウェアをセキュアにするメタデータ（Ｍ）を決定するコンピュータにより実現される方法のフローチャートを示す。 Ｍｅｒｋｌｅツリーの具体例を示す。 コンピュータソフトウェア及びコンピュータソフトウェアに関連するライセンスを参照してＭｅｒｋｌｅツリーの具体例を示す。 分散ハッシュテーブルを利用してコンピュータソフトウェアの位置を示す識別子を決定するコンピュータにより実現される方法のフローチャートを示す。 一例となる処理デバイスの概略を示す。 分散ハッシュテーブル及びピア・ツー・ピア分散型台帳を利用して契約の実行を制御するコンピュータにより実現される方法のフローチャートを示す。

本開示は、一般にビットコインブロックチェーンなどのピア・ツー・ピア（Ｐ２Ｐ）分散型台帳（ブロックチェーン）及び分散ハッシュテーブルを利用して、コンピュータソフトウェアへのアクセスをセキュア及び許可することを可能にする方法及びシステムに関する。

以下に説明される実施例は、具体的にはビットコインブロックチェーン（ここでは、ブロックチェーンとして参照される）上で行われるトランザクションを参照しうるが、本発明は、他のＰ２Ｐ分散型台帳を利用して実現されうる。ブロックチェーンは、それのハイレベルな標準化及び大量の関連する公開文献のため、簡単化のみのため本発明の態様を説明するのに以下で用いられる。
［分散ハッシュテーブル］
典型的なクライアント／サーバモデルでは、中央サーバは、リソースの大多数を担当しうる。これは、中央サーバに対する攻撃又は故障があると、中央サーバに格納されているリソースの大多数は危険にさらされうることを意味する。逆に、分散型モデルが、リソースは参加ノード間に共有（“分散”）される。このようにして、全ての参加ノードの容量が利用され、１つのサーバの故障はリソースの大多数を危険にさらさない。

図１は、ハッシュテーブルの具体例を示す。ハッシュテーブルは、鍵－値のペアから構成される。各鍵－値のペアの鍵は、ハッシュ関数によってインデックスにマッピングされる。インデックスは、鍵－値のペアの格納されている値の位置を規定する。

ＤＨＴは、分散型モデルをハッシュテーブルに適用した具体例である。ハッシュテーブルと同様に、ＤＨＴは鍵－値のペアを有し、鍵が与えられると、鍵－値のペアの値を特定（“ルックアップ”）する効率的な方法を提供する。しかしながら、ハッシュテーブルと対称的に、鍵－値のペアは分散され、いくつかの参加ノードによって格納される。このようにして、鍵－値のペアを格納及び維持する責任は参加ノードによって共有される。

ハッシュテーブルと同様に、ＤＨＴにおける各鍵－値のペアはインデックスにマッピングされる。インデックスは、鍵に対してハッシュ関数を実行することによって、各鍵－値のペアに対して決定される。例えば、暗号化セキュアハッシュアルゴリズムＳＨＡ－１が、インデックスを決定するのに利用されてもよい。

各参加ノードには、鍵空間のパーティションによって少なくとも１つのインデックスが割り当てられる。参加ノードに割り当てられる各インデックスに対して、参加ノードは当該鍵－値のペアの値を格納する。

鍵－値のペアの値が効率的に抽出されうることが効果である。鍵に関連する値を抽出するため、ノードは、“ルックアップ”を実行して、責任ノード（インデックスを介し）を決定してもよい。責任ノードは、それから値を決定するためアクセスされうる。
［ビットコイン及びブロックチェーン］
当該分野において周知なように、ブロックチェーンは、記憶容量がビットコインプロトコルに基づきシステムに参加するネットワーク接続されたノード間に分散されるデータベースのトランザクションタイプ台帳である。各ビットコイントランザクションはネットワークにブロードキャストされ、トランザクションが承認され、その後にブロックにアグリゲートされる。その後、ブロックは、複数の参加ノードにブロックを格納することによってブロックチェーン上に含まれる。

仮想通貨のＰ２Ｐ分散型台帳の完全なコピーは、仮想通貨においてこれまでに実行された全てのトランザクションを含む。従って、トランザクションのデータレコードの継続的に拡大するリストが提供される。ブロックチェーンに入れられる各トランザクションは暗号化が実施されるため、ブロックチェーンは、参加ノードのオペレータによってさえ、改ざん及び変更が困難である。

ブロックチェーンの透過性のため、各トランザクションに対して履歴が公開利用可能である。

トランザクション及びトランザクションのレコードが同じであることがブロックチェーンの更なる効果である。

このようにして、トランザクションに関する情報が実際のトランザクションにおいてキャプチャされる。このレコードは、永続的であって不変であり、従って、第三者がトランザクションレコードを別のデータベースに保持するための要求を取り除く。
［ペイ・ツー・スクリプト・ハッシュ及びマルチシグネチャ］
以下の実施例は、具体的にはビットコインプロトコルのペイ・ツー・スクリプト・ハッシュ（Ｐ２ＳＨ）法を利用するトランザクションを参照しうるが、本発明は、ペイ・ツー・パブリック・キー・ハッシュ法などのビットコインプロトコルの他の方法を利用して実現されてもよい。

ブロックチェーン上の各トランザクションレコードは、トランザクションを示す情報を含むスクリプト及びいくつかの公開鍵を有する。これらの公開鍵は、仮想通貨の送り手及び受け手に関連付けされてもよい。スクリプトは、ユーザがトランザクションレコードに指定される仮想通貨へのアクセスをどのように取得可能かを記述するブロックチェーン上の各トランザクションレコードと共に記録される命令のリストとしてみなすことができる。スクリプトはまた、例えば、要求されるシグネチャなど、仮想通貨にアクセスするための要求を記述しうる。

背景として、ビットコインプロトコルの標準的なＰ２ＳＨ法において、出力スクリプト、すなわち、リディーム（ｒｅｄｅｅｍ）スクリプトは、
＜ＮｕｍＳｉｇｓ ＰｕｂＫ１ ＰｕｂＫ２．．．ＰｕｂＫ１５ ＮｕｍＫｅｙｓ ＯＰ＿ＣＨＥＣＫＭＵＬＴＩＳＩＧ＞
の形態をとりうる。

ただし、ＮｕｍＳｉｇｓはトランザクションをアンロックするためにリディームスクリプトを充足するのに必要とされる有効なシグネチャの数“ｍ”であり、ＰｕｂＫ１ ＰｕｂＫ２．．．ＰｕｂＫ１５はトランザクションをアンロックするシグネチャに対応する公開鍵であり（最大で１５個までの公開鍵）、ＮｕｍＫｅｙｓは公開鍵の数“ｎ”である。

ビットコインプロトコルでは、ユーザの秘密鍵に基づくシグネチャが、楕円曲線デジタルシグネチャアルゴリズムを利用して生成されてもよい。それから、シグネチャは、出力スクリプト又はリディームスクリプトに関連する仮想通貨の償還（ｒｅｄｅｍｐｔｉｏｎ）に利用される。ユーザが出力スクリプト又はリディームスクリプトを償還するとき、ユーザは、シグネチャ及び公開鍵を提供する。出力スクリプト又はリディームスクリプトは、それから公開鍵に対してシグネチャを検証する。

上記のリディームスクリプトを償還するため、公開鍵に対応するシグネチャの数“ｍ”が少なくとも必要とされる。いくつかの具体例では、公開鍵の順序が重要であり、署名のための“ｎ”個のシグネチャからの数“ｍ”が順番に実行される必要がある。例えば、“ｍ”は２であり、“ｎ”は１５である場合を考える。利用可能な２つのシグネチャＳｉｇ１（ＰｕｂＫ１に対応する）及びＳｉｇ１５（ＰｕｂＫ１５に対応する）がある場合、リディームスクリプトはまずＳｉｇ１によって署名され、その後にＳｉｇ１５によって署名される必要がある。
［システムの概略］
図２は、通信ネットワーク５を介し第２ノード７と通信する第１ノード３を含むシステム１を示す。第１ノード３は関連する第１処理デバイス２１を有し、第２ノード５は関連する第２処理デバイス２７を有する。第１ノード３及び第２ノード７の具体例は、コンピュータ、タブレットコンピュータ、モバイル通信デバイス、コンピュータサーバなどの電子デバイスを含む。

図２において、鍵－値のペアを記録及び格納するためのＤＨＴ１３がまた示される。ＤＨＴ１３は、鍵－値のペアの値を受信、記録及び格納するため、１つ以上の処理デバイス１９に関連付けされてもよい。処理デバイス１９は、ＤＨＴ１３の“参加ノード”によって利用されてもよい。上述されたように、ＤＨＴ１３は、鍵－値のペアの値を特定するための効率的な方法を提供する。

図２はまた、トランザクションを記録するためのＰ２Ｐ分散型台帳１４を示す。Ｐ２Ｐ分散型台帳１４は、トランザクションを受信及び記録するため、１つ以上の処理デバイス２０に関連付けされてもよい。上述したように、Ｐ２Ｐ分散型台帳１４の具体例はビットコインブロックチェーンである。従って、ブロックチェーンに関して、Ｐ２Ｐ分散型台帳１４に関連する処理デバイス２０は、“マイナー”として参照される処理デバイスであってもよい。

第１ノード３は第１ユーザ２３に関連付けされ、第２ノード７は第２ユーザ２４に関連付けされる。一例では、第１ノード３はコンピュータソフトウェアのベンダを表してもよい。他の例では、第１ノード３はエージェント又はサービスプロバイダを表してもよい。更なる他の例では、第１ノード３はコンピュータソフトウェアのユーザを表してもよい。

同様に、第２ノード７はエージェント、サービスプロバイダ、コンピュータソフトウェアのベンダ又はコンピュータソフトウェアのユーザを表してもよい。

一例では、第１ノード３は、図３及び６に指名されるような方法１００，５００を実行する。他の例では、第２ノード７は、方法１００，５００を実行する。以下の実施例がこれらの方法を実行するとして第１ノード３を参照しうるが、本開示はまた他のノードによって実行されるよう適応化又は修正されてもよいことが理解されるべきである。

図３に示されるような方法１００は、コンピュータソフトウェアに関連するデータ（Ｄ１）を決定すること（１１０）を含む。データ（Ｄ１）は更に、コンピュータソフトウェアに関連するライセンスを有してもよい。方法１００はまた、コンピュータソフトウェアに基づき第１のハッシュ値（Ｈ１）を決定すること（１２０）を含む。一例では、第１のハッシュ値（Ｈ１）は、コンピュータソフトウェアの実行可能ファイルに関するものであってもよい。

方法１００はまた、データ（Ｄ１）及びコンピュータソフトウェアに基づき第２のハッシュ値（Ｈ２）を決定すること（１３０）を含む。一例では、第２のハッシュ値（Ｈ２）は、コンピュータソフトウェアの詳細及びコンピュータソフトウェアに関連するライセンスを表してもよい。更なる例では、第２のハッシュ値（Ｈ２）は、付加情報を有してもよい。

方法１００は更に、通信ネットワーク５を介しデータ（Ｄ１）、第１のハッシュ値（Ｈ１）及び第２のハッシュ値（Ｈ２）を分散ハッシュテーブル１３上のエントリに送信すること（１４０）を含み、ここで、第２のハッシュ値（Ｈ２）は鍵－値のペアの鍵に割り当てられ、データ（Ｄ１）及び第１のハッシュ値（Ｈ１）は鍵－値のペアにおける値に割り当てられる。鍵－値のペアにおける値は更に、コンピュータソフトウェア又はライセンスの位置を示す識別子を含んでもよい。

方法１００はまた、ピア・ツー・ピア分散型台帳１４に含めるための第２のハッシュ値（Ｈ２）に基づくメタデータ（Ｍ）を決定すること（１５０）を含む。一例では、メタデータ（Ｍ）は、ピア・ツー・ピア分散型台帳１４に含めるための第１のリディームスクリプト（ＲＳ１）に含まれてもよい。
［コンピュータソフトウェアに関連するデータの決定（１１０）］
上述したように、方法１００は、コンピュータソフトウェアに関連するデータ（Ｄ１）を決定すること（１１０）を含む。データ（Ｄ１）の決定（１１０）は、ユーザ、ノード又はデータストアからデータ（Ｄ１）を受信することを含んでもよい。データ（Ｄ１）の決定（１１０）は更に、第１ノード３においてデータ（Ｄ１）を生成することを含んでもよい。

一例では、第１ノード３は、ユーザインタフェース１５を介し第１ユーザ２３からデータ（Ｄ１）を受信してもよい。他の例では、第１ノード３は、第２ユーザ２４からデータ（Ｄ１）を受信してもよい。更なる他の例では、第１ノード３は、データストア１７からデータ（Ｄ１）を受信してもよい。

データ（Ｄ１）は、コンピュータソフトウェアに関連付けされ、データ（Ｄ１）は、コンピュータソフトウェア、付加情報、コンピュータソフトウェアのライセンス又はコンピュータソフトウェアの位置を特定しうる。例えば、データ（Ｄ１）は、コンピュータソフトウェアを特定する文字列又はデータ構造を有してもよい。文字列又はデータ構造は、コンピュータソフトウェアに関するキーワード及び／又は付加情報を特定する集まりを有してもよい。付加情報の具体例は、コンピュータソフトウェアのバージョンの識別子であってもよい。例えば、コンピュータソフトウェアがＢｏｂＳｏｆｔｗａｒｅという名前であって、バージョンが３．０である場合、文字列又はデータ構造（Ｄ１）は“ＢｏｂＳｏｆｔｗａｒｅ／３．０”を含んでもよい。

更なる例では、データ（Ｄ１）は、コンピュータソフトウェアに関連するライセンスの識別子を有してもよい。これは、ソフトウェアライセンス識別番号（ＩＤ）又はソフトウェアライセンスキーであってもよい。他の例では、ライセンスの識別子は、ライセンスのコンテンツの暗号化ハッシュを含んでもよい。

データ（Ｄ１）は更に、コンピュータソフトウェアの格納位置を示す識別子を有してもよい。一例では、識別子はインターネット上のオブジェクトのＵＲＬを有してもよい。更なる例では、ハッシュテーブル又は分散ハッシュテーブルなどのレポジトリ上のコンピュータソフトウェアの格納位置に対するリンクが提供されてもよい。

更なる他の例では、データ（Ｄ１）は、コンピュータソフトウェアのベンダを特定する情報を含んでもよい。これは、ベンダに関連する名前、アドレス、連絡先の詳細又は公開鍵などのパーソナル詳細を含んでもよい。
［コンピュータソフトウェアに基づく第１のハッシュ値（Ｈ１）の決定（１２０）］
上述したように、方法１００は更に、コンピュータソフトウェアの第１のハッシュ値（Ｈ１）を決定すること（１２０）を含む。第１のハッシュ値（Ｈ１）の決定（１２０）は、ユーザから第１のハッシュ値（Ｈ１）を受信するか、あるいは、データストアから第１のハッシュ値（Ｈ１）にアクセスすることを含んでもよい。第１のハッシュ値（Ｈ１）の決定（１２０）は更に、第１ノード３においてハッシュ値を計算することを含んでもよい。

一例では、第１ノード３は、ユーザインタフェース１５を介し第１ユーザ２３から第１のハッシュ値（Ｈ１）を受信してもよい。他の例では、第１ノード３は、第２ユーザ２４から第１のハッシュ値（Ｈ１）を受信してもよい。更なる他の例では、第１ノード３は、ローカルデータストア１７又はリモートデータストアから第１のハッシュ値（Ｈ１）にアクセスしてもよい。

一例では、第１のハッシュ値（Ｈ１）は、コンピュータソフトウェアの実行可能ファイルのものである。コンピュータソフトウェアの実行可能ファイルは、インターネットなどの通信ネットワーク５から抽出されてもよい。他の例では、実行可能ファイルは、第１ユーザ２３又は第２ユーザ２４によって提供されてもよい。更なる他の例では、実行可能ファイルはデータストア１７から抽出されてもよい。更なる他の例では、実行可能ファイルは、ハッシュテーブル又はＤＨＴなどのレポジトリから抽出可能であってもよい。

ソフトウェアの実行可能ファイルのハッシュは、情報の２５６ビット表現を生成するため、ＳＨＡ－２５６アルゴリズムを利用して決定されてもよい。セキュアハッシュアルゴリズム（ＳＨＡ）ファミリにおける他のアルゴリズムを含むハッシュアルゴリズムが利用されてもよいことが理解されるべきである。いくつかの特定の具体例は、ＳＨＡ３－２２４，ＳＨＡ３－２５６，ＳＨＡ３－３８４，ＳＨＡ３－５１２，ＳＨＡＫＥ１２８，ＳＨＡＫＥ２５６を含むＳＨＡ－３サブセットにおけるインスタンスを含む。他のハッシュアルゴリズムは、ＲＡＣＥ Ｉｎｔｅｇｒｉｔｙ Ｐｒｉｍｉｔｉｖｅｓ Ｅｖａｌｕａｔｉｏｎ Ｍｅｓｓａｇｅ Ｄｉｇｅｓｔ（ＲＩＰＥＭＤ）ファミリにおけるものを含んでもよい。特定の具体例は、ＲＩＰＥＭＤ－１６０を含んでもよい。他のハッシュ関数は、Ｚｅｍｏｒ－Ｔｉｌｌｉｃｈハッシュ関数及びナップザックベースハッシュ関数に基づくファミリを含んでもよい。
［データ（Ｄ１）及びコンピュータソフトウェアに基づく第２のハッシュ値（Ｈ２）の決定（１３０）］
方法１００はまた、データ（Ｄ１）及びコンピュータソフトウェアに基づき第２のハッシュ値（Ｈ２）を決定すること（１３０）を含む。

一例では、第２のハッシュ値（Ｈ２）は、データ（Ｄ１）及びコンピュータソフトウェアの実行可能ファイル（又は実行可能ファイルのハッシュ、すなわち、第１のハッシュ値（Ｈ１））の連接のハッシュに基づき決定されてもよい。更なる例では、第２のハッシュ値（Ｈ２）は、データ（Ｄ１）、コンピュータソフトウェアの実行可能ファイル（又は実行可能ファイルのハッシュ）及び付加情報の連接のハッシュに基づき決定されてもよい。

付加情報は、第１ユーザ２３（ＰＵ１）又は第２ユーザ２４（ＰＵ２）の公開鍵を有してもよい。更なる例では、付加情報は、第１ユーザ２３又は第２ユーザ２４に関連するエンティティの識別子を含んでもよい。例えば、エンティティは、第１ユーザ２３又は第２ユーザ２４の雇用主であってもよい。他の例では、エンティティは、第１ユーザ２３又は第２ユーザ２４のサービスプロバイダであってもよい。

付加情報は更に、第１ノード３、第２ノード７、第１ユーザ２３又は第２ユーザ２４に関連するデバイスのデバイス識別子を含んでもよい。デバイスの具体例は、図２に示されるような第１処理デバイス２１である。デバイス識別子は、ＭＡＣアドレス、マザーボードシリアルナンバー又はデバイス識別番号の少なくとも１つを含んでもよい。デバイス識別子は更に、ＭＡＣアドレス、マザーボードシリアルナンバー又はデバイス識別番号の少なくとも２つの連接であってもよい。更なる例では、デバイス識別子は、ＭＡＣアドレス、マザーボードシリアルナンバー、デバイス識別番号又は上述した連接に関連するハッシュ値を含んでもよい。

更なる例では、付加情報は、コンピュータソフトウェアに関連するライセンスの有効期限を含んでもよい。
［コンピュータソフトウェアに関連する契約（例えば、ライセンス）］
更なる例では、第２のハッシュ値（Ｈ２）は、データ（Ｄ１）、コンピュータソフトウェアの実行可能ファイル（又は実行可能ファイルのハッシュ値）、付加情報又はコンピュータソフトウェアに関連する契約（例えば、ライセンス）の連接に基づき決定されてもよい。

契約（例えば、ライセンス）の表現は、ライセンスのコンテンツを指定するファイル又はドキュメントであってもよい。例えば、プレインＡＳＣＩＩテキスト、ＰＤＦドキュメント又はＷｏｒｄドキュメントである。第２のハッシュ値（Ｈ２）は、それの当初の形式におけるライセンスを含んでもよいし、あるいは、例えば、それは、インターネットなどの公衆にアクセス可能な通信ネットワークにおけるライセンスの位置に対するリンクを提供してもよい。更なる例では、ハッシュテーブル又はＤＨＴなどのレポジトリ上のライセンスの位置に対するリンクが提供されてもよい。更なる例では、データストア１７などのコンピュータベースリスース上のライセンスの位置に対するリンクが提供されてもよい。

一例では、ライセンスは、コンピュータソフトウェアに関連する第１のハッシュ値（Ｈ１）を含んでもよい。

コンピュータソフトウェアに関連するライセンスは更に、上述したような付加情報を含んでもよい。一例では、ライセンスは、第１ユーザ２３又は第２ユーザ２４に関連してもよい。ライセンスは、第１ユーザ２３（ＰＵ１）又は第２ユーザ２４（ＰＵ２）の公開鍵を含んでもよい。更なる例では、ライセンスは、第１ユーザ２３又は第２ユーザ２４に関連するエンティティの識別子を含んでもよい。

コンピュータソフトウェアに関連するライセンスは更に、第１ノード３、第２ノード７、第１ユーザ２３又は第２ユーザ２４に関連するデバイスのデバイス識別子を含んでもよい。デバイスの具体例は、図２に示されるような第１処理デバイス２１である。デバイス識別子は、ＭＡＣアドレス、マザーボードシリアルナンバー又はデバイス識別番号の少なくとも１つを含んでもよい。デバイス識別子は更に、ＭＡＣアドレス、マザーボードシリアルナンバー又はデバイス識別番号の少なくとも２つの連接であってもよい。更なる例では、デバイス識別子は、ＭＡＣアドレス、マザーボードシリアルナンバー、デバイス識別番号又は上述した連接に関連するハッシュ値を含んでもよい。

第１ユーザ２３はコンピュータソフトウェアのベンダであってもよいし、第２ユーザ２４はコンピュータソフトウェアの受信者（“エンドユーザ”）であってもよい。他の例では、第２ユーザ２３はコンピュータソフトウェアのベンダであってもよいし、第２ユーザ２４はコンピュータソフトウェアのエンドユーザであってもよい。

一例では、コンピュータソフトに関連するライセンスは、１つのみのエンドユーザ（“シングルユーザライセンス”）を許可してもよい。更なる例では、コンピュータソフトウェアに関連するライセンスは、エンドユーザの１つのデバイスを許可してもよい（“シングルデバイスライセンス”）。他の例では、コンピュータソフトウェアに関連するライセンスは、エンドユーザの複数のデバイスを許可してもよい（“マルチデバイスライセンス”）。

他の例では、複数のエンドユーザ（“マルチユーザライセンス”）があってもよい。更なる例では、コンピュータソフトウェアに関連するライセンスは、エンドユーザ毎に１つのデバイスを許可してもよい。他の例では、コンピュータソフトウェアに関連するライセンスは、エンドユーザ毎に複数のデバイスを許可してもよい。

ライセンスが第１ユーザ２３又は第２ユーザ２４に関連する場合、ライセンスは、第１ユーザ２３に関連する第１ユーザ公開鍵（ＰＵ１）及び第２ユーザ２４に関連する第２ユーザ公開鍵（ＰＵ２）を有してもよい。
［Ｍｅｒｋｌｅツリー］
他の例では、ライセンスは、Ｍｅｒｋｌｅツリーの先頭のハッシュ値であってもよい。図４において、Ｍｅｒｋｌｅツリーの具体例が示される。Ｍｅｒｋｌｅツリーでは、各ノードにおけるハッシュ値は、それら各自の“チャイルド”ノードのハッシュである。例えば、ハッシュ値Ｈａｓｈ－Ａ３０５は、２つの“チャイルド”ノード３０９，３１１におけるハッシュ値のハッシュである。Ｍｅｒｋｌｅツリーの先頭のハッシュ値であるＨａｓｈ－ＡＢ３０３は、Ｍｅｒｋｌｅツリーにおける全てのハッシュ値を有する。すなわち、それは、ツリーのボトムにおける４つの“リーフ”であるＡ１ ３１７，Ａ２ ３１９，Ｂ１ ３２１及びＢ２ ３２３のハッシュ値をキャプチャする。

本開示の例では、Ｍｅｒｋｌｅツリーの各“リーフ”はライセンスの情報の側面を表しうる。図５において、例示的なライセンスが示される。データ（Ｄ１）４１７はハッシュ値Ｈａｓｈ－Ｄ４０９においてキャプチャされ、ユーザ２３及び／又は２４の公開鍵４２１はハッシュ値Ｈａｓｈ－Ｐ４１３においてキャプチャされ、有効期限４２３はハッシュ値Ｈａｓｈ－Ｅ４１５においてキャプチャされる。ノード４０５，４０７がデータ（Ｄ１）４１７、ソフトウェア４１９、公開鍵４２１及び有効期限４２３のリーフとそれぞれ関連付けされるハッシュ値をキャプチャすることが理解できる。

上述されない他の情報はハッシュ値（Ｈ２）が基づく付加情報を含みうることが理解されるべきである。
［分散ハッシュテーブルへのデータ（Ｄ１）、第１ハッシュ値（Ｈ１）及び第２ハッシュ値（Ｈ２）の送信（１４０）］
方法１００はまた、通信ネットワーク５を介し分散ハッシュテーブル１３上のエントリにデータ（Ｄ１）、第１ハッシュ値（Ｈ１）及び第２ハッシュ値（Ｈ２）を送信すること（１４０）を含む。

一例では、第２ハッシュ値（Ｈ２）は、鍵－値のペアの鍵であってもよく、データ（Ｄ１）及び第１ハッシュ値（Ｈ１）は、鍵－値のペアの値であってもよい。

更なる例では、上述したような付加情報はまた、鍵－値のペアにおける値の一部であってもよい。これは、限定することなく、第１ユーザ２３若しくは第２ユーザ２４の公開鍵、第１ノード３、第２ノード７、第１ユーザ２３若しくは第２ユーザ２４に関連するデバイスのデバイス識別子、コンピュータソフトウェア若しくはライセンスの位置を示す識別子又はライセンスに関連する更なる付加情報を含む。

上述したように、ＤＨＴ１３は鍵－値のペアから構成され、各鍵－値のペアはインデックスに割り当てられる。一例では、第２ハッシュ値（Ｈ２）は、インデックスを生成するのに利用されてもよい。ハッシュ関数又は暗号化ハッシュ関数は、第２ハッシュ値（Ｈ２）に対して実行されてもよい。例えば、暗号化関数ＳＨＡ－１が利用されてもよい。

Ｉｎｄｅｘ＝ＳＨＡ－１（Ｈ２）
第２のハッシュ値（Ｈ２）がＤＨＴ１３における鍵－値のペアの鍵になって、データ（Ｄ１）及び第１のハッシュ値（Ｈ１）が鍵－値のペアの値になるため、鍵及び値はＤＨＴ１３の何れかの参加ノードに送信される。

一例では、ｐｕｔ（ｋｅｙ，ｖａｌｕｅ）などのメッセージがＤＨＴ１３の参加ノードに送信されてもよく、ここで、ｋｅｙは第２のハッシュ値（Ｈ２）であり、ｖａｌｕｅはデータ（Ｄ１）及び第１のハッシュ値（Ｈ１）である。メッセージは、それが鍵空間のパーティショニングによって示されるようなインデックスに割り当てられる参加ノードによって受信されるまで、全ての参加ノードに送信されてもよい。メッセージにおいて示されたインデックスに割り当てられた参加ノードは、その後、ＤＨＴ１３上に鍵－値のペアを格納し、鍵－値のペアに関連付けされるエントリを維持する責任を想定してもよい。

何れか所与の鍵の値がＤＨＴ１３から抽出されうることは効果である。一例では、第１ユーザ２３又は第２ユーザ２４は当該値を抽出することを所望しうる。第１ユーザ２３又は第２ユーザ２４は、第１ノード３、第２ノード７又は図示されない他のノードを介しｇｅｔ（ｋｅｙ）などのリクエストメッセージをＤＨＴ１３の何れかの参加ノードに提供してもよい。その後、リクエストメッセージは、それが鍵空間のパーティショニングによって示されるようなインデックスに割り当てられる参加ノードによって受信されるまで、全ての参加ノードに送信されてもよい。
［メタデータ（Ｍ）の決定（１５０）］
方法１００は更に、第２のハッシュ値（Ｈ２）を有するメタデータ（Ｍ）を決定すること（１５０）を含む。メタデータ（Ｍ）の決定（１５０）は、ユーザ、ノード又はデータストアからメタデータ（Ｍ）を受信することを含んでもよい。メタデータ（Ｍ）は、例えば、Ｐ２Ｐ分散型台帳１４上のトランザクションのＰ２ＳＨマルチシグネチャの第１リディームスクリプト（ＲＳ１）における公開鍵に利用可能な１５の場所の１つ以上に含まれてもよい。

Ｐ２Ｐ分散型台帳１４上のトランザクションの第１リディームスクリプト（ＲＳ１）は、メタデータ（Ｍ）に含まれるコンテンツを表すトークン化されたトランザクション（“発行トークン”）の発行又は作成を表すものであってもよい。一例では、トークンはエージェント（Ａ）によって発行されてもよい。

ビットコインプロトコルのＰ２ＳＨ法では、メタデータは、その内容の全てが参照によって援用される“Ｕｎｉｖｅｒｓａｌ ｔｏｋｅｎｉｓａｔｉｏｎ ｓｙｓｔｅｍ ｆｏｒ ｂｌｏｃｋｃｈａｉｎ ｂａｓｅｄ ｃｒｙｐｔｏｃｕｒｒｅｎｃｉｅｓ”という名称の共通に所有される英国特許出願番号１６０３１２５．４に最初に紹介された方法によってリディームスクリプトに含まれてもよい。リディームスクリプトにメタデータを含める処理がそこに説明されている。しかしながら、当該処理の簡単な要約が以下に与えられる。
［メタデータ］
メタデータ（Ｍ）は、Ｐ２ＳＨマルチシグネチャリディームスクリプト（ＲＳ１）における公開鍵に利用可能な１５の場所の１つ以上に埋め込まれてもよい。例えば、リディームスクリプト（ＲＳ１）は、
＜ＮｕｍＳｉｇｓ，Ｍｅｔａｄａｔａ１ Ｍｅｔａｄａｔａ２．．．ＰｕｂＫ１ ＰｕｂＫ２．．．ＮｕｍＫｅｙｓ ＯＰ＿ＣＨＥＣＫＭＵＬＴＩＳＩＧ＞
の形態をとってもよい。ここで、Ｍｅｔａｄａｔａ１及びＭｅｔａｄａｔａ２はそれぞれ、リディームスクリプトにおいて公開鍵の場所をとるメタデータを含み、ＰｕｂＫ１及びＰｕｂＫ２は公開鍵である。

メタデータ（Ｍ）は、第２のハッシュ値（Ｈ２）を有してもよい。メタデータ（Ｍ）は更に、コンピュータソフトウェア又はライセンスに関連する条件を記述する説明又はキーワードを有してもよい。例えば、ライセンスの日付、ライセンスに関連するユーザの名前、誕生日、住所、連絡先又は他の詳細などである。更なる例では、仮想通貨の数量に関連する情報は含まれてもよい。

メタデータ（Ｍ）は、いくつかの方法で情報を含んでもよい。一例では、情報のコンテンツが含まれてもよい。更なる例では、情報の暗号化ハッシュが含まれてもよい。情報のハッシュは、ＳＨＡ－２５６アルゴリズムを利用して情報の２５６ビット表現を作成して決定されてもよい。セキュアハッシュアルゴリズム（ＳＨＡ）ファミリの他のアルゴリズムを含む他のハッシュアルゴリズムが利用されてもよいことが理解されるべきである。いくつかの具体例は、ＳＨＡ３－２２４，ＳＨＡ３－２５６，ＳＨＡ３－３８４，ＳＨＡ３－５１２，ＳＨＡＫＥ１２８，ＳＨＡＫＥ２５６を含むＳＨＡ－３サブセットのインスタンスを含んでもよい。他のハッシュアルゴリズムは、ＲＡＣＥ Ｉｎｔｅｇｒｉｔｙ Ｐｒｉｍｉｔｉｖｅｓ Ｅｖａｌｕｔｉｏｎ Ｍｅｓｓａｇｅ Ｄｉｇｅｓｔ（ＲＩＰＥＭＤ）ファミリにおけるものを含んでもよい。特定の具体例は、ＲＩＰＥＭＤ－１６０を含んでもよい。他のハッシュ関数は、Ｚｅｍｏｒ－Ｔｉｌｌｉｃｈハッシュ関数及びナップザックベースハッシュ関数に基づくファミリを含んでもよい。

本開示の更なる実施例では、上記の１つ以上を含む組み合わせがメタデータ（Ｍ）に含まれてもよい。メタデータ（Ｍ）はブロックチェーンなどのＰ２Ｐ分散型台帳１４を介し公開されてもよいし、あるいは、非セキュアネットワークを介し送信されてもよいため、メタデータ（Ｍ）の具体的詳細がプライバシの理由のため秘密にされるか、あるいは隠されることが望ましい。

従って、本開示の実施例におけるマルチシグネチャＰ２ＳＨビットコイントランザクションの利用は、それがコンピュータソフトウェア及びライセンスに関連する情報の移動及び永続的な記録を可能にするため、効果を提供する。この記録は、例えば、リディームスクリプトなどのトランザクションの出力スクリプトにメタデータを含めることによって実現される。
［第１のリディームスクリプト］
上述したように、リディームスクリプトは、ビットコインプロトコルの標準的なＰ２ＳＨ法における出力スクリプトの具体例であり、ユーザがトランザクションレコードにおいて指定される仮想通貨へのアクセスをどのように取得可能であるかを説明する。

本開示では、発行トークンのための第１のリディームスクリプト（ＲＳ１）は、メタデータ（Ｍ）に基づくものであってもよい。第１のリディームスクリプト（ＲＳ１）は更に、エージェントの秘密鍵（ＶＡ）により暗号化ペアを構成するエージェントの公開鍵（ＰＡ）を有してもよい。このようにして、エージェントの秘密鍵（ＶＡ）は、トランザクションに関連する仮想通貨を“アンロック”又は使用することが要求される。

一例では、発行トークンのための第１のリディームスクリプト（ＲＳ１）は、メタデータ（Ｍ）を有してもよい。第１のリディームスクリプト（ＲＳ１）は更に、エージェントの公開鍵（ＰＡ）を有してもよい。本例では、第１のリディームスクリプトは、
＜ＯＰ＿１ ＰＡ Ｍｅｔａｄａｔａ１ Ｍｅｔａｄａｔａ２ ＯＰ＿３ ＯＰ＿ＣＨＥＣＫＭＵＬＴＩＳＩＧ＞
の形態をとってもよい。ここで、ＯＰ＿１はトランザクションをアンロックするため第１のリディームスクリプト（ＲＳ１）を充足するのに必要とされるシグネチャの数（“ＮｕｍＳｉｇｓ”）を示し、ＯＰ＿３はリディームスクリプトにおける公開鍵の数（“ＮｕｍＫｅｙｓ”）を示す。

本例では、第１のリディームスクリプト（ＲＳ１）は、メタデータのための２つの指定されたフィールドＭｅｔａｄａｔａ１及びＭｅｔａｄａｔａ２を有してもよい。以下のテーブル１において、Ｍｅｔａｄａｔａ１及びＭｅｔａｄａｔａ２の具体例が示される。

本例は、有用でありうるＭｅｔａｄａｔａ１におけるライセンスに対するポインタを提供することを含み、ライセンスのサイズは、メタデータ（Ｍ）にそのような詳細を含めることを妨げる。さらに、メタデータ（Ｍ）は公開されてもよいし、あるいは、非セキュアネットワークを介し送信されてもよいため、トークンの具体的詳細がプライバシの理由のために秘密にされるか、あるいは隠されることが望ましいかもしれない。

Ｍｅｔａｄａｔａ１の最初の４バイトは、ライセンスのタイプを示す。例えば、ライセンスタイプは、ＢｏｂＳｏｆｔｗａｒｅなどのコンピュータソフトウェアの名前を示してもよい。更なる例では、ライセンスタイプは、上述したような“シングルユーザ”又は“マルチデバイス”などのライセンスの許可タイプを示してもよい。次の１６バイトは、ＩＰｖ６アドレスを考慮する実際の電子ライセンスファイルの位置のＩＰアドレスを保持する。いくつかの実施例では、この値は、ライセンスファイルが中央化されずクラウドを介し分散可能となるように、トレント（ｔｏｒｒｅｎｔ）ファイルのシードを指し示してもよいことに留意されたい。以降の１２バイトは、ライセンスのタイプに特有のデータを含む。

Ｍｅｔａｄａｔａ２の最初の２０バイトは、ライセンスファイルの実際のコンテンツに適用されるＳＨＡ２５６に対するＲＩＰＥＭＤ１６０を利用した実際のライセンスファイルのハッシュである。実際のライセンスファイルは抽出可能であってもよいため、これは、契約に対するトランザクションの検証を可能にする。ライセンスファイル自体は、具体的な実施例の要求に依存して、完全に公開されてもよいし（非暗号化され、人間に可読である）、あるいは、プライバシのため暗号化されてもよいことに留意されたい。Ｍｅｔａｄａｔａ２の残りの１２バイトのコンテンツが、ライセンスのタイプに依存して利用されてもよい。

上記で提供された第１のリディームスクリプト（ＲＳ１）の具体例から、発行トークンが使用されるためにエージェント（Ａ）によって署名される必要があることが理解できる。テーブル２において、発行トークンのトランザクションの具体例が与えられ、簡単化のため、マイナーの費用は示されていない。

テーブル２の４～８行は、発行トークンに含まれるべき（すなわち、“トークン化”）第１の仮想通貨量（Ｃ１）であるトランザクションに対する入力を表す。本例では、第１の仮想通貨量（Ｃ１）は、第１の仮想通貨量をエージェント（Ａ）の利益に移動した前のトランザクション（ＩＤ－１１０）の結果であり、従って、前のトランザクション（ＩＤ－１１０）の出力スクリプト（リディームスクリプトＩＤ－１１０）はエージェントの公開鍵（ＰＡ）を含む。従って、この前の出力をアンロックするため、スクリプト（リディームスクリプトＩＤ－１１０）は、第１ユーザの秘密鍵（ＶＡ）によって署名される必要がある。最後に、テーブル２の８行は、第１の仮想通貨量（Ｃ１）がこのトランザクション（ＩＤ－６００）における第１の出力であることを示す。

テーブル２の９～１３行は、トランザクション（ＩＤ－６００）の第１の（及び唯一の）出力を表し、この場合、発行トークンが作成され、エージェントに戻されることを表す。１０行は、第１の仮想通貨量（Ｃ１）である出力値を示す。１１行は、ビットコインプロトコルのＰ２ＳＨ法で利用されるような“＜リディームスクリプトのハッシュ＞”を含む出力スクリプトを示す。本例では、リディームスクリプトは、上述したような形式の第１のリディームスクリプト（ＲＳ１）である。

テーブル２に示されるトランザクション（ＩＤ－６００）の出力は、その後、Ｐ２Ｐ分散型台帳１４に第１のデータ出力（Ｏ１）と共に記録される。特に、第１のデータ出力（Ｏ１）は、トランザクションにおいて移動された第１の仮想通貨量（Ｃ１）の表示を含んでもよい。第１のデータ出力（Ｏ１）は更に、第１のリディームスクリプト（ＲＳ１）のハッシュを含んでもよい。

例えば、第１ユーザ２３又は第２ユーザ２４へのトークンの移動などの第１の仮想通貨量（Ｃ１）の以降のトランザクションでは、第１の仮想通貨量（Ｃ１）をアンロックするためのスクリプト（例えば、以降のトランザクションの入力ＳｃｒｉｐｔＳｉｇ）は、
Ｓｉｇ－ＶＡ Ｓｉｇ－ＶＵ１＜ＯＰ＿１ ＰＡ ＰＵ１ Ｍｅｔａｄａｔａ１ Ｍｅｔａｄａｔａ２ ＯＰ＿４ ＯＰ＿ＣＨＥＣＫＭＵＬＴＩＳＩＧ＞
の形態をとってもよく、ここで、Ｓｉｇ－ＶＵ１は第１ユーザ２３のシグネチャを示す。上記スクリプトは、エージェント（Ａ）又は第１ユーザ２３からの１つのシグネチャのみが第１の仮想通貨量（Ｃ１）をアンロックするのに必要とされることに留意されたい。

発行トークンは、第２のリディームスクリプト（ＲＳ２）によって他のユーザに移動されてもよい。
［第２のリディームスクリプト］
コンピュータソフトウェア及びライセンスに関連するトークンが、エージェント（Ａ）から、例えば、第１ユーザ２３又は第２ユーザ２４などの他のユーザに移動されうる。一例では、トークンの移動は、コンピュータソフトウェア又はライセンスに対するユーザへのアクセスを許可するものとして表されうる。当該移動は、第２のリディームスクリプト（ＲＳ２）によって実現されてもよい。

一例では、エージェント（Ａ）は、第１ユーザ２３に発行トークンを移動することを所望する。第１ユーザ２３は、例えば、コンピュータソフトウェアのベンダを表してもよい。

本例では、第２のリディームスクリプト（ＲＳ２）は、メタデータ（Ｍ）、エージェント（Ａ）に関連するエージェント公開鍵（ＰＡ）及び第１ユーザ２３に関連する第１ユーザ公開鍵（ＰＵ１）に基づくものであってもよい。

第２のリディームスクリプト（ＲＳ２）は、
＜ＯＰ＿１ ＰＡ ＰＵ１ Ｍｅｔａｄａｔａ１ Ｍｅｔａｄａｔａ２ ＯＰ＿４ ＯＰ＿ＣＨＥＣＫＭＵＬＴＩＳＩＧ＞
の形態をとってもよい。

本例では、第２のリディームスクリプト（ＲＳ２）は、第１のリディームスクリプト（ＲＳ１）と同じ２つのメタデータフィールドを有する。第２のリディームスクリプト（ＲＳ２）は更に、エージェントに関連するエージェント公開鍵（ＰＡ）及び第１ユーザに関連する第１ユーザ公開鍵（ＰＵ１）を有する。

移動されたトークンが使用されるためにエージェント（Ａ）又は第１ユーザ２３によって署名される必要があることが、上述した第２のリディームスクリプト（ＲＳ２）の例から理解できる。発行トークンの移動のためのトランザクションの具体例がテーブル３において提供され、簡単化のため、マイナーの費用は再び示されない。

テーブル２と同様に、テーブル３の４～８行はトランザクション（ＩＤ－６１０）に対する入力を表す。本例では、入力は発行トークンであり、すなわち、テーブル２に示されるトランザクション（ＩＤ－６００）の出力である。７行目におけるリディームスクリプトは、発行トークンのリディームスクリプト、すなわち、第１のリディームスクリプト（ＲＳ１）に対応することが理解できる。従って、トランザクション（ＩＤ－６００）の出力をアンロックするため、第１のリディームスクリプト（ＲＳ１）はエージェントの公開鍵（ＰＡ）によって署名される必要がある。

テーブル３の９～１３行は、トランザクション（ＩＤ－６１０）の出力を表し、この場合、発行トークンがエージェント（Ａ）又は第１ユーザ２３（Ｕ１）に移動されることを表す。１０行目は、第１の仮想通貨量（Ｃ１）である出力値を示す。１１行目は、ビットコインプロトコルのＰ２ＳＨ法において利用されるような“＜リディームスクリプトのハッシュ＞”を含む出力スクリプトを示す。本例では、リディームスクリプトは、上述したような形式の第２のリディームスクリプト（ＲＳ２）である。

トランザクション（ＩＤ－６１０）の出力は、その後、Ｐ２Ｐ分散型台帳１４に第２のデータ出力と共に記録される。第２のデータ出力（Ｏ２）は、第１のデータ出力（Ｏ１）からの第１の仮想通貨量（Ｃ１）がトランザクションにおいて移動されるべきであるという指示を含みうる。第２のデータ出力（Ｏ２）は更に、第２のリディームスクリプト（ＲＳ２）のハッシュを含みうる。
［契約の実行の制御］
ブロックチェーンに構築されたスマートコントラクトは、ビットコイントランザクション（すなわち、ロック／アンロックスクリプト内）に直接埋め込まれたロジックを介し、及び／又は外部のコンピュータベースアプリケーションを介し実施可能である。そのような外部のコンピュータベースアプリケーションは、“エージェント”、“オラクル”又は“ボット”として参照されうる。さらに、いくつかの契約条件は、ｎＬｏｃｋＴｉｍｅフィールドなどの他のビットコイントランザクション要素を介し実施可能である。

本開示は、契約を表すブロックチェーン上の有効な未使用のトランザクション出力（ＵＴＸＯ）がある限り、契約（例えば、ライセンス）が有効なままであることを提供することによって、契約の実行を制御することに関する。この未使用の状態は、契約自体における条件又は規定によって行動が制御される各種機構（例えば、プログラムされた計算エージェント）の結果として影響を受け、変更されうることが理解されるであろう。例えば、契約は、それが特定の日に満了するか、あるいは、特定の値が指定された閾値に到達したときに満了することを規定する。

未使用のトランザクション出力を利用して契約を表す本原理は、暗号化技術などの他の特徴と組み合わせて利用可能である。これは、複雑なシナリオ及びアクティビティの実現を可能にする。効果的には、使用されることを可能にするスクリプト内の関連するメタデータ及び署名無しのトランザクション出力ＵＴＸＯにおけるコンテクストは、契約の形式的な詳細を含むオフチェーンレポジトリに対するポインタ又はリファレンスとしてトランザクションが機能することを可能にする。ここで、オフチェーンは、それがブロックチェーン自体の一部でないことを意味する。これは、ブロックチェーンを調べることによって、契約が終了したか、あるいは、依然として有効／オープンであるか誰もが判断できる機構を提供する。契約が終了すると、これがトランザクションにおいて使用された出力としてブロックチェーン上に記録され、公衆の調査のために利用可能になる。ブロックチェーントランザクションは、契約の存在及び現在状態の永続的、変更不可及び公開の記録になる。

図８により示されるような方法８００は、コンピュータベースレポジトリに契約を格納すること（８１０）を含み、当該契約は、第１ユーザ（Ｕ１）と第２ユーザ（Ｕ２）との間のライセンスに関連する。コンピュータベースレポジトリ（“レジストリ”又は“レジスタ”とも呼ばれうる）は、例えば、分散ハッシュテーブル（ＤＨＴ）を含む各種方法において実現されうる。契約（例えば、ライセンス）のハッシュは、ブロックチェーントランザクション内のメタデータとして生成及び格納可能であり、ブロックチェーンから契約を参照するためのルックアップキーとして機能しうる。契約の位置に対するリファレンスがまた、トランザクションメタデータ内に与えられる。例えば、レポジトリのためのＵＲＬが提供されうる。メタデータは公衆の閲覧のためオープンであるが、契約自体はプロテクトされなくてもよいし、あるいは、部分的にプロテクトされてもよい。

ＣｈｅｃｋＬｏｃｋＴｉｍｅＶｅｒｉｆｙ（ＣＬＴＶ）などの標準的なビットコイン機能は、契約が将来のある時点において形式的な自動的有効期限を有することを可能にしうる。ブロックチェーンの使用は、この有効期限がセキュア（変更不可）な公的な記録の題材になることを可能にする。このコンセプトは、後述される複数の暗号鍵の利用と組み合わせて、ＣＬＴＶモデルが、明示的にキャンセルされない場合、契約を自動的にロールオン又は更新することを可能にする。

方法８００はまた、通信ネットワークを介しエージェント（Ａ）から第１ユーザ（Ｕ１）又は第２ユーザ（Ｕ２）にトークンの移動を含むトランザクションを受信すること（８２０）を含み、トランザクションは契約が格納されている場所を示す識別子を含むメタデータを有する。

決定的なサブ鍵の使用は、ここで説明されるトークン化機構と組み合わせて、契約に対するサブ契約又はスケジュールが作成されることを可能にする。

さらに、オフブロック計算エージェント（“オラクル”としても知られる）の使用は、契約が信頼される第三者によって条件付きで構成及び修正されることを可能にする。これは、エージェントのアクションが契約の定義内で提供される条件（例えば、“ＩＦ”ステートメント）によって影響を受けうることを意味する。
［キーターム］
以下の用語がここで利用されうる。
・契約発行者
当該エンティティは、ブロックチェーン上への契約の更改の責任がある行為者を表す。
・利害関係者
当該エンティティは、特定の契約が依然として存在するか否かを判断する必要がある行為者を表す。
・レポジトリ
当該エンティティは、ブロックチェーンスマートコントラクトが参照する契約の構造化された表現をセキュア／格納する場所を表す。
・契約相手方
当該エンティティは、特定の契約に対する相手方を表す。多くのケースにおいて、当該エンティティは存在しないことに留意されたい。
・契約
これは、レポジトリ内に格納され、ブロックチェーンから参照される構造化された文書又はファイルである。契約は、何れかのタイプの契約又は合意でありうる。これは、例えば、金融契約、権利書、役務契約などを含んでもよい。契約は、それの内容に関して公的又は私的なものとすることができる。契約は、それがコード化方式を利用して構造化された方法で表現される点で形式化される。
［契約モデル］
契約モデルの基本要素は、以下である。
・何れかのタイプの契約の完全な記載を可能にするコード化方式。当該方式は、新たな構成であってもよいし、あるいは、ＸＢＲＬ，ＸＭＬ，ＪＳＯＮなどの既存のファシリティを利用してもよい。
・コード化方式内で完全に定義可能な契約を実現するためのＤＦＡ（決定的有限オートマトン）。これは、
○パラメータの集合であり、これらのパラメータのソースとなる場所
○状態の定義の集合
○遷移のトリガ及び遷移中に従うルールを含む状態間の遷移の集合
○ルール定義テーブル
から構成される。
・契約の当該インスタンスに特有のパラメータの定義
・契約をセキュア及びプロテクトするための機構
・契約が形式的な法律用語により人間に可読になることを可能にするための“ブラウザ”
・コード化方式をオラクルコード及び／又はビットコインスクリプトなどのスクリプトに変換するための“コンパイラ”
［契約の実現］
契約がコンピュータベースレポジトリに登録されると、ＵＲＬ及びハッシュなどの関連するアドレスが、制御する契約自体とチェーン上のトランザクションとを関連付けるため、ブロックチェーントランザクション内でメタデータとして利用可能である。これは、様々な形式で実現可能であるが、適したコード化方式は“コード化方式”というセクションにおいて完全に提供される。

契約定義内に含まれるＤＦＡがどのように実現可能であるかに関していくつかの異なる方法がある。
・ブロックチェーントランザクション又はトランザクションの系列として。ビットコインスクリプト言語内で各種形式のＤＦＡを直接実現する方法をカバーするいくつかの別々のホワイトペーパーがある。
・エージェントベース（例えば、オラクル）処理又は処理の系列として。“本発明と共に利用される例示的な計算エージェント”の以下のセクションは、ブロックチェーン及び可能な他の外部ソースをモニタするために適したエージェントを定義及び実行するための基本処理を説明する。
・スマートウォレットのための命令セットとして。このコンテンツでは、スマートウォレットは、ブロックチェーントランザクションへのトランザクション入力の割当てなどの特定の契約条件を処理可能な効果的な単なるローカルなオラクル処理である。

所与の契約定義が上記の３つの機構の組み合わせとして実現可能であることに留意されたい。各契約状態遷移は効果的に別の実現形態である。関連するトランザクション／コードの作成を含む契約定義から実現形態を作成するいくつかの方法がある。
［契約の存在の公開］
契約（又は契約内の定義された要素）の存在を公開するため、トランザクション（エージェント（Ａ）から第１ユーザ（Ｕ１）又は第２ユーザ（Ｕ２）へのトークンの移動に関する）は、ペイ・ツー・スクリプト・ハッシュアドレス（Ｐ２ＳＨ）を利用してブロックチェーンに公開される。Ｐ２ＳＨトランザクションでは、トランザクションが使用されるため、受信者がスクリプトハッシュに一致するスクリプトと、スクリプトが本物であると評価させるデータとを提供する必要がある。本開示の実施例に関して、ペイ・ツー・スクリプト・ハッシュ（Ｐ２ＳＨ）は、契約の発行者（例えば、第１ユーザ（Ｕ１）又は第２ユーザ（Ｕ２））及び契約のメタデータから容易に決定可能である。

この出力はブロックチェーン上のＵＴＸＯリスト内に維持されるが（すなわち、トランザクションは依然として未使用である）、これは、メタデータ自体の内部に含まれる契約の有効性を示す。契約は、当該出力が使用されると、完全であるとみなされる。
［サブ契約／条件］
サブ契約は、既存の契約に直接関連する契約である。条件は、契約の取り決めを満たすために公的に実現される必要がある既存の契約内の条項である。本開示の実施例によると、サブ契約と条件との双方が、同じ方法で、すなわち、決定的なリディームスクリプトアドレスによりＵＴＸＯとして実現される契約として実現可能である。双方のケースにおいて、エンティティは、ＵＴＸＯが使用されると、完全であるとみなされる（条件の場合には、これは当該条件が充足されたことを示す）。

条件又はサブ契約のために決定的アドレスを作成するのに利用可能ないくつかの機構がある。
・シード情報を利用して新たな公開鍵を導出
・マスタ契約に対する参照によってレポジトリ内にサブ契約を作成及び公開し、これをメタデータリファレンスとして利用
・既存の契約のメタデータに対する条件／サブ契約リファレンスを追加
［契約のセキュア化］
契約の形式的表現（すなわち、契約内容を指定する文書又はファイル）は、全てのケースにおいて、契約の存在の公的な記録がメタデータレコード内に含まれるブロックチェーン上に公開されるが（具体的なメタデータの構造の詳細についてはセクション“コード化方式”を参照されたい）、具体的な契約の形式的な要求に応じて様々な方法でセキュア化可能である。

このブロックチェーンレコードから、許可されたエンティティは、形式的な表現がトランザクションが公開されて依頼変更されていないことを決定するため、ハッシュと一緒に形式的な表現の場所を知ることが可能である。

しかしながら、いくつかの方法を通じて形式的表現自体を更にセキュアにすることが可能である。
・ドキュメントレポジトリ自体がアクセス制御機構を提供可能であり、
・契約自体が、関連する解読鍵へのアクセスによって当該エンティティへのアクセスを限定する標準的な暗号化技術を通じてセキュア化可能である。
［契約の終了］
ブロックチェーンはトランザクションの永続的で変更不可な記録を提供するため、契約は、単に関連する契約文書を削除することによっては終了可能ではない。これは、セキュアなレポジトリはいくつかの標準的な機構を介しサポートされるブロックチェーン自体と同じストレージ及び存続ルールを有する必要があることを意味する。これは、解決策がブロックチェーンの記録を開始契約の有効期限を直接検出するための機構を提供する必要があることを意味する。

これは、契約を表すＵＴＸＯの使用を介して処理される。いくつかの契約タイプについて、契約の有効期限は契約自体の公開と同時に公開可能である。効果的には、２つのトランザクションが作成され、一方は契約を公開し、契約を表すトランザクション出力を取得し、第２のものは当該出力を利用する。この第２のトランザクションは、所与の将来の日付に（契約のエンドを表す）に出力を使用するため、設定されるＣｈｅｃｋＬｏｃｋＴｉｍｅＶｅｒｉｆｙを有する。

この自動使用は、契約のロールオンをサポートするため延長可能である（例えば、キャンセルされない場合、更に１２ヵ月自動延長される契約）。この状況において、ＵＴＸＯは使用され、それを“新たな”ロールオン契約に送信する。

方法８００はまた、トランザクションが少なくとも１つの未使用出力（ＵＴＸＯ）を有するか判断するため、ピア・ツー・ピア分散型台帳に照会すること（８３０）を含む。ピア・ツー・ピア分散型台帳に照会するための当該処理は、契約に関連するＵＴＸＯが使用されたか否かを確認するため、ブロックチェーンをチェックすることを伴う。ＵＴＸＯが依然として未使用である場合、契約は有効なままである。ＵＴＸＯが依然として未使用であるが、ロックタイムトランザクションが保留中である場合、これは、契約の有効期限を決定する。ＵＴＸＯが使用されている場合、契約はある点で完了している。

ピア・ツー・ピア分散型台帳を照会する処理（８３０）は、利害関係者（例えば、エージェント、第１ユーザ（Ｕ１）又は第２ユーザ（Ｕ２））が他のルートを介し契約を支配するトランザクションを認識していることを仮定する（一般に、それは契約発行者又は契約相手方の何れかであること）。しかしながら、契約文書へのアクセスと契約発行者の知識を有する何れのエンティティも、
・ＵＴＸＯトランザクションに対するリディームスクリプトを導出し、
・一致したリディームスクリプトのハッシュによってＵＴＸＯを検出するためブロックチェーンをスキャンする、
ことによってチェックできる。

本開示の他の実施例では、ピア・ツー・ピア分散型台帳を照会するステップ（８３０）は、自動化されたポーリング処理の一部として実行され、これによって、ブロックチェーンは、トランザクションが少なくとも１つの未使用出力（ＵＴＸＯ）を有するか判断するため（すなわち、トランザクションが未使用のままであるか判断するため）、所定の時間間隔でスキャンされる。

方法８００はまた、ピア・ツー・ピア分散型台帳を照会したことに応答して、契約の実行を変更するか判断すること（８４０）を含む。判断するステップ（８４０）は、少なくとも１つの未使用出力（ＵＴＸＯ）がピア・ツー・ピア分散型台帳から特定できない場合に契約を終了するか、あるいは、少なくとも１つの未使用出力（ＵＴＸＯ）がピア・ツー・ピア分散型台帳から特定される場合に契約を維持するかを含む。判断するステップ（８４０）は自動か処理の一部を構成してもよいことが理解されるべきである。例えば、コンピュータソフトウェアの特定のライセンスは、定期的（例えば、毎月又は毎年）に支払を要求するか、あるいは、特定の時間のみに実行するよう設計されているかもしれない。各ケースにおいて、ソフトウェアは、ピア・ツー・ピア分散型台帳をポーリングし、対応して動作することが可能である必要がある（例えば、コンピュータソフトウェアに対するアクティブなライセンスを維持するため、ユーザからの支払を要求する）。他の外部条件に対して条件付きで実行するソフトウェアの能力を有することがまた可能であってもよく、この場合、ソフトウェアはオラクルをポーリング可能である。地域的ロックアウト（すなわち、地理的な起動制限）が必要とされる場合、ユーザのＩＰアドレスがハッシュ化され、分散ハッシュテーブルに他のフィールドを作成するため利用可能である。

あるいは又はさらに、ライセンスは所与の日付で満了することになっていてもよく、この場合、契約トランザクションは、それがオラクル（又はエージェント（Ａ））のシグネチャによって使用可能であるように形式化されてもよく、他のトランザクションは、トランザクションの未使用出力（ＵＴＸＯ）をオラクル（又はエージェント（Ａ））に自動的に払い戻す有効期限に設定されたロックタイムによって形式化される。

少なくとも１つの未使用出力（ＵＴＸＯ）がピア・ツー・ピア分散型台帳から特定できない場合、契約発行者（例えば、エージェント又はベンダ）又は契約相手方（例えば、ライセンシ）は、既存の契約をクローズすることを所望しうる（すなわち、コンピュータソフトうぇなどのライセンスを終了する）。当該クロージャの扇動者は（大部分の場合、コンピュータソフトウェアのベンダ又はベンダのためのエージェント（Ａ））、以前のＵＴＸＯが使用されたか否か検証することによって、契約がキャンセルされたか判断するため、ブロックチェーンをチェックする（方法８００のステップ８３０に従って）。使用されていた場合、契約はすでにクローズされたとして、当該処理は終了する。しかしながら、少なくとも１つの未使用出力（ＵＴＸＯ）がピア・ツー・ピア分散型台帳から特定できない場合、ユーザ（例えば、ライセンシ）は分散ハッシュテーブル（ＤＨＴ）を介しベンダのサーバに接続され、例えば、ライセンスを更新するために支払をする機会が与えられてもよいことが理解されるべきである。

既存のクロージャトランザクションが存在する場合、扇動者は当該トランザクションを単に署名し、ブロックチェーンに提出する。既存のクロージャトランザクションがない場合、扇動者は、トランザクション入力が最後の契約のＵＴＸＯであることによってトランザクションを作成し、アンロックスクリプトは、それらのシグネチャ、契約に関連するメタデータ及び公開鍵である。

トランザクションがブロックチェーン上で承認された時点で、それは、契約がクローズされたという公的な知識となる（参加者しか具体的な理由を知らないが）。

テーブル４において、少なくとも１つの未使用出力（ＵＴＸＯ）を使用することによって契約（例えば、ライセンス）を終了するためのトランザクションの具体例が提供され、簡単化のため、マイナー費用が再び示されない。

テーブル３と同様に、テーブル３の４～８行は、トランザクション（ＩＤ－６１０）に対する入力を表す。本例では、入力は１・オブ・４マルチシグネチャＰ２ＳＨトランザクション、すなわち、テーブル３に示されるトランザクション（ＩＤ－６１０）の出力である。７行目におけるリディームスクリプトは１・オブ・４マルチシグネチャＰ２ＳＨトランザクションのリディームスクリプト、すなわち、第２のリディームスクリプト（ＲＳ２）に対応することが理解できる。従って、トランザクション（ＩＤ－６１０）の出力をアンロックするため、第２のリディームスクリプト（ＲＳ２）は、エージェントの公開鍵（ＰＡ）又は第１ユーザの公開鍵（ＰＵ１）の何れかによって署名される必要がある。

テーブル３の９～１３行は、トランザクション（ＩＤ－６２０）の出力を表し、この場合、未使用出力（ＵＴＸＯ）が使用されたことを表す（すなわち、仮想通貨量（Ｃ１）がエージェント（Ａ）又はオラクルに払い戻された）。１０行目は、第１の仮想通貨量（Ｃ１）である出力値を示す。
［コンピュータソフトウェア又はライセンスの場所を示す識別子］
上述されたように、データ（Ｄ１）又はライセンスは、コンピュータソフトウェア又はライセンスそれぞれの場所を示す識別子を有してもよい。

一例では、識別子は、データ（Ｄ１）又はライセンスから独立に決定され、データ（Ｄ１）又はライセンスに対して別々のままであってもよい。識別子は更に、方法１００において上述したように、データ（Ｄ１）及び第１のハッシュ値（Ｈ１）と一緒に鍵－値のペアの値に割り当てられてもよい。このようにして、識別子は、メッセージｐｕｔ（ｋｅｙ，ｖａｌｕｅ）のｖａｌｕｅフィールドに含まれ、上述したように、ＤＨＴ１３における参加ノードに送信されてもよい。

一例では、場所を示す識別子は、インターネット上のオブジェクトのＵＲＬを有してもよい。他の例では、場所を示す識別子はハッシュテーブル又はＤＨＴ１３などのレポジトリのアドレスを有してもよい。更なる他の例では、場所を示す識別子は、第１ノード３の第１処理デバイス２１に関連するデータストア１７などのコンピュータベースリソース上に提供されるサーバ、データベース又はストレージ施設などのコンピュータベースレポジトリのアドレスを有してもよい。

図６は、コンピュータソフトウェア又はライセンスの場所を決定する方法５００を示す。方法５００は、第１のリディームスクリプト（ＲＳ１）からメタデータ（Ｍ）を決定すること（５１０）を含む。上述したように、メタデータ（Ｍ）は、第１のリディームスクリプト（ＲＳ１）における公開鍵に利用可能な１５の場所の１つ以上に埋め込まれてもよい。

ビットコインプロトコルのＰ２ＳＨ法では、トランザクションの出力が以降のトランザクションにおいて使用されるとき、リディームスクリプトは、以降のトランザクションにおいて可視的になる。テーブル２を参照して上述したように、発行トークンのトランザクション（ＩＤ－６００）は、エージェント（Ａ）に払い戻される。このようにして、エージェント（Ａ）は、この発行トークンを使用して第１のリディームスクリプト（ＲＳ１）を公開してもよい。従って、第２のハッシュ値（Ｈ２）に基づくメタデータ（Ｍ）は、Ｐ２Ｐ分散型台帳１４上で可視的である。このようにして、第２のハッシュ値（Ｈ２）は、第１のリディームスクリプト（ＲＳ１）におけるメタデータ（Ｍ）から抽出可能である（５２０）。一例では、鍵－値のペアの鍵に関連する値は、リクエストメッセージｇｅｔ（ｋｅｙ）を利用してＤＨＴ１３から抽出可能である。

方法５００は更に、通信ネットワーク５を介しＤＨＴ１３の参加ノードに関連するプロセッサに第２のハッシュ値（Ｈ２）を送信すること（５３０）を含む。上述したように、第２のハッシュ値（Ｈ２）は、鍵－値のペアの値であってもよい。また上述したように、所与の鍵に対する値は、ＤＨＴ１３の何れかの参加ノードに鍵を含むメッセージを提供することによって抽出されてもよい。従って、識別子が鍵－値のペアの値フィールドに含まれる例では、方法５００は、参加ノードのプロセッサからコンピュータソフトウェア又はライセンスの場所を示す識別子を決定すること（５４０）が可能である。
［処理デバイス］
上述したように、第１ノード３及び第２ノード７は、コンピュータ、タブレットコンピュータ、モバイル通信デバイス、コンピュータサーバなどの電子デバイスであってもよい。電子デバイスは、処理デバイス２１，２７、データストア１７及びユーザインタフェース１５を有してもよい。

図７は、処理デバイス２１，２７の具体例を示す。処理デバイス２１，２７は、第１ノード３、第２ノード７又は図示されない他のノードにおいて利用されてもよい。処理デバイス２１，２７は、バス１５３０を介し互いに通信するプロセッサ１５１０、メモリ１５２０及びインタフェースデバイス１５４０を有する。メモリ１５２０は、上述した方法１００，５００を実現するためのマシーン可読命令及びデータを含むコンピュータソフトウェアプログラムを格納し、プロセッサ１５１０は、方法１００，５００を実現するためのメモリ１５２０からの命令を実行する。インタフェースデバイス１５４０は、通信ネットワーク５と、いくつかの具体例では、ユーザインタフェース１５及びデータストア１７などの周辺機器との通信を実現する通信モジュールを有してもよい。処理デバイス１５１０は独立したネットワーク要素であってもよいが、処理デバイス１５１０はまた他のネットワーク要素の一部であってもよいことが留意されるべきである。さらに、処理デバイス１５１０によって実行されるいくつかの機能は、複数のネットワーク要素間で分散されてもよい。例えば、第１ノード３は、第１ノード３に関連するセキュアなローカルエリアネットワークにおいて方法１００，５００を実行するための複数の処理デバイス２１を有してもよい。

本開示はユーザ、雇用者、被雇用者、発行者、商人、プロバイダ又は他のエンティティが特定のアクション（署名、発行、判断、計算、送信、受信、作成などを含む）を実行することを説明している場合、当該単語は説明の簡単化のために利用される。これらのアクションはこれらのエンティティによって運営される計算デバイスによって実行されることが理解されるべきである。

多数の変形及び／又は修正が本開示の広範な一般的範囲から逸脱することなく上述した実施例に対して行われうることが、当業者によって理解されるであろう。従って、本実施例は、全ての点において限定的でなく例示的なものとしてみなされるべきである。

（付記１）
契約の実行を制御するコンピュータにより実現される方法であって、
コンピュータベースレポジトリに契約を格納するステップであって、前記契約は第１ユーザと第２ユーザとの間のライセンスに関連する、格納するステップと、
通信ネットワークを介しエージェントから前記第１ユーザ又は前記第２ユーザへのトークンの移動を含むトランザクションを受信するステップであって、前記トランザクションは、前記契約が格納されている場所を示す識別子を含むメタデータを含む、受信するステップと、
前記トランザクションが少なくとも１つの未使用出力を含むか判断するため、ピア・ツー・ピア分散型台帳を照会するステップと、
前記ピア・ツー・ピア分散型台帳を照会したことに応答して、前記契約の実行を修正するか判断するステップと、
を有する方法。
（付記２）
前記トランザクションは更に、決定的なリディームスクリプトアドレスを含む、付記１記載の方法。
（付記３）
リディームスクリプトアドレスは、ペイ・ツー・スクリプト・ハッシュ（Ｐ２ＳＨ）アドレスである、付記１又は２記載の方法。
（付記４）
前記判断するステップは、
前記少なくとも１つの未使用出力が前記ピア・ツー・ピア分散型台帳から特定不可である場合、前記契約を終了するステップ、又は、
前記少なくとも１つの未使用出力が前記ピア・ツー・ピア分散型台帳から特定される場合、前記契約を維持するステップ
を有する、付記１乃至３何れか一項記載の方法。
（付記５）
前記契約を終了するステップは、前記少なくとも１つの未使用出力を使用するため、更なるトランザクションをブロードキャストするステップを含む、付記４記載の方法。
（付記６）
前記更なるトランザクションをブロードキャストするステップにおいて、前記更なるトランザクションは、指定されたデータ及び／又は時間において前記少なくとも１つの未使用出力を使用する命令を含む、付記５記載の方法。
（付記７）
前記更なるトランザクションは、
前記少なくとも１つの未使用出力である入力と、
シグネチャ、前記メタデータ、前記エージェントに関連するエージェント公開鍵及び前記第１ユーザに関連する第１ユーザ公開鍵を含むリディームスクリプトと、
を含む、付記５又は６記載の方法。
（付記８）
前記契約は、
前記第１ユーザと前記第２ユーザとの間の前記ライセンスの処理に関する少なくとも１つの条件と、
実行が前記条件の評価に依存する少なくとも１つのアクションと、
を定義する、付記１乃至７何れか一項記載の方法。
（付記９）
前記メタデータは、
前記契約が前記コンピュータベースレポジトリに格納されているアドレスのアドレス又は表現、及び／又は
前記契約のハッシュを含む、付記１乃至８何れか一項記載の方法。
（付記１０）
前記ピア・ツー・ピア分散型台帳を照会するステップは更に、
前記少なくとも１つの未使用出力が前記ピア・ツー・ピア分散型台帳の未使用トランザクション出力のリストに存在するか判断することによって、前記契約が終了したかチェックするステップを含む、付記１乃至９何れか一項記載の方法。
（付記１１）
前記契約は、分散ハッシュテーブルに格納される。付記１乃至１０何れか一項記載の方法。
（付記１２）
前記契約は、前記契約を実現する決定的有限オートマトンを含む、付記１乃至１１何れか一項記載の方法。
（付記１３）
前記決定的有限オートマトンは、コード化方式を利用して定義される、付記１２記載の方法。
（付記１４）
前記契約に関連する前の鍵に関するサブ鍵を生成するステップと、
前記サブ鍵、前記契約の場所及び前記契約のハッシュを含む更なるリディームスクリプトを生成するステップと、
前記更なるリディームスクリプトにある量の仮想通貨を支払うステップと、
を実行することによって、前記契約を更新するステップを更に有する、付記１乃至１３何れか一項記載の方法。
（付記１５）
前記契約から導出されるサブ契約を生成するステップを更に有し、
前記サブ契約は、決定的アドレスに関連し、
シードを用いて導出される新たな公開鍵を利用するステップと、
前記契約に対するリファレンスと共に前記コンピュータベースレポジトリに前記サブ契約を格納するステップと、
前記契約に対するリファレンスを含むサブ契約トランザクションを前記ピア・ツー・ピア分散型台帳にブロードキャストするステップと、
前記契約に関連する前記メタデータに前記サブ契約に対するリファレンスを追加するステップと、
を実行することによって生成される、付記１乃至１４何れか一項記載の方法。
（付記１６）
前記第１ユーザと前記第２ユーザとの間の前記ライセンスは、
コンピュータソフトウェアと、
音楽、ビデオ及び電子書籍を含むデジタルメディアと、
の１つ以上に関する、付記１乃至１５何れか一項記載の方法。
（付記１７）
前記ピア・ツー・ピア分散型台帳は、ブロックチェーンである、付記１乃至１６何れか一項記載の方法。
（付記１８）
仮想通貨は、ビットコインである、付記１乃至１７何れか一項記載の方法。
（付記１９）
付記１乃至１８何れか一項記載の方法を処理デバイスに実現させるマシーン可読命令を有するコンピュータソフトウェアプログラム。
（付記２０）
契約の実行を制御するコンピュータシステムであって、
コンピュータベースレポジトリに契約を格納し、前記契約は第１ユーザと第２ユーザとの間のライセンスに関連し、
通信ネットワークを介しエージェントから前記第１ユーザ又は前記第２ユーザへのトークンの移動を含むトランザクションを受信し、前記トランザクションは、前記契約が格納されている場所を示す識別子を含むメタデータを含み、
前記トランザクションが少なくとも１つの未使用出力を含むか判断するため、ピア・ツー・ピア分散型台帳を照会し、
前記ピア・ツー・ピア分散型台帳を照会したことに応答して、前記契約の実行を修正するか判断する、
よう構成される処理デバイスを有するシステム。

Claims (20)

1. 契約の実行を制御するためにコンピュータが実現する方法であって、
   コンピュータベースレポジトリに契約を格納するステップであって、前記契約は第１ユーザと第２ユーザとの間のライセンスに関連し、前記契約は、真又は偽に評価されることが可能な条件を定義している、格納するステップと、
   通信ネットワークを介しエージェントから前記第１ユーザ又は前記第２ユーザへのトークンの移動を含むトランザクションを受信するステップであって、前記トランザクションは、前記契約が格納されている場所を示す識別子を含むメタデータを含む、受信するステップと、
   前記トランザクションが少なくとも１つの未使用出力を含むか否かを判断するため、ピア・ツー・ピア分散型台帳を照会するステップと、
   前記ピア・ツー・ピア分散型台帳を照会したことに応答して、前記契約の実行を修正するか否かを判断するステップと、
   を有する方法。
2. 前記トランザクションは、更に、決定的なリディームスクリプトアドレスを含む、請求項１に記載の方法。
3. 前記契約は、スマートコントラクトである、請求項１又は２に記載の方法。
4. 前記判断するステップは、
   前記少なくとも１つの未使用出力が前記ピア・ツー・ピア分散型台帳から特定できない場合、前記契約を終了するステップ、又は、
   前記少なくとも１つの未使用出力が前記ピア・ツー・ピア分散型台帳から特定される場合、前記契約を維持するステップ
   を有する、請求項１乃至３のうちの何れか一項に記載の方法。
5. 前記契約を終了するステップは、前記少なくとも１つの未使用出力を使用するため、更なるトランザクションをブロードキャストするステップを含む、請求項４に記載の方法。
6. 前記更なるトランザクションをブロードキャストするステップにおいて、前記更なるトランザクションは、指定されたデータ及び／又は時間において前記少なくとも１つの未使用出力を使用する命令を含む、請求項５に記載の方法。
7. 前記更なるトランザクションは、
   前記少なくとも１つの未使用出力である入力と、
   シグネチャ、前記メタデータ、前記エージェントに関連するエージェント公開鍵、及び前記第１ユーザに関連する第１ユーザ公開鍵、を含むリディームスクリプトと、
   を含む、請求項５又は６に記載の方法。
8. 前記契約は、
   前記第１ユーザと前記第２ユーザとの間の前記ライセンスの処理に関する少なくとも１つの条件と、
   実行が前記条件の評価に依存する少なくとも１つのアクションと、
   を定義する、請求項１乃至７のうちの何れか一項に記載の方法。
9. 前記ピア・ツー・ピア分散型台帳を照会するステップは更に、
   前記少なくとも１つの未使用出力が前記ピア・ツー・ピア分散型台帳の未使用トランザクション出力のリストに存在するか否かを判断することによって、前記契約が終了したか否かをチェックするステップを含む、請求項１乃至８のうちの何れか一項に記載の方法。
10. 前記契約は、分散ハッシュテーブルに格納される。請求項１乃至９のうちの何れか一項に記載の方法。
11. 前記契約は、前記契約を実現する決定的有限オートマトンを含む、請求項１乃至１０のうちの何れか一項に記載の方法。
12. 前記決定的有限オートマトンは、コード化方式を利用して定義される、請求項１１に記載の方法。
13. 前記決定的有限オートマトンは、
    （i）ブロックチェーントランザクション又はトランザクションの系列、
    （ii）エージェントベース処理又は処理の系列、
    （iii）スマートウォレットのための命令セット
    のうちの少なくとも１つとして実現される、請求項１１又は１２に記載の方法。
14. 前記契約に関連する前の鍵に関するサブ鍵を生成するステップと、
    前記サブ鍵、前記契約の場所、及び前記契約のハッシュ、を含む更なるリディームスクリプトを生成するステップと、
    前記更なるリディームスクリプトに、ある量の仮想通貨を支払うステップと、
    を実行することによって、前記契約を更新するステップを更に有する、請求項１乃至１３のうちの何れか一項に記載の方法。
15. 前記契約から導出されるサブ契約を生成するステップを更に有し、
    前記サブ契約は、決定的アドレスに関連し、且つ：
    シードを用いて導出される新たな公開鍵を利用するステップと、
    前記契約に対するリファレンスと共に前記コンピュータベースレポジトリに前記サブ契約を格納するステップと、
    前記契約に対するリファレンスを含むサブ契約トランザクションを、前記ピア・ツー・ピア分散型台帳にブロードキャストするステップと、
    前記契約に関連する前記メタデータに、前記サブ契約に対するリファレンスを追加するステップと、
    を実行することによって生成される、請求項１乃至１４のうちの何れか一項に記載の方法。
16. 前記第１ユーザと前記第２ユーザとの間の前記ライセンスは、
    コンピュータソフトウェア、及び
    音楽と、ビデオと、と電子書籍を含むデジタルメディア、
    のうちの１つ以上に関する、請求項１乃至１５のうちの何れか一項に記載の方法。
17. 前記ピア・ツー・ピア分散型台帳は、ブロックチェーンである、請求項１乃至１６のうちの何れか一項に記載の方法。
18. 仮想通貨は、ビットコインである、請求項１乃至１７のうちの何れか一項に記載の方法。
19. 請求項１乃至１８のうちの何れか一項に記載の方法を処理デバイスに実現させる機械読み取り可能な命令を有するコンピュータソフトウェアプログラム。
20. 契約の実行を制御するコンピュータシステムであって、処理デバイスを有し、
    前記処理デバイスは、コンピュータベースレポジトリに契約を格納するように構成されており、前記契約は第１ユーザと第２ユーザとの間のライセンスに関連し、前記契約は、真又は偽に評価されることが可能な条件を定義しており、
    前記処理デバイスは、通信ネットワークを介しエージェントから前記第１ユーザ又は前記第２ユーザへのトークンの移動を含むトランザクションを受信するように構成されており、前記トランザクションは、前記契約が格納されている場所を示す識別子を含むメタデータを含み、
    前記処理デバイスは、前記トランザクションが少なくとも１つの未使用出力を含むか否かを判断するため、ピア・ツー・ピア分散型台帳を照会するように構成されており、
    前記処理デバイスは、前記ピア・ツー・ピア分散型台帳を照会したことに応答して、前記契約の実行を修正するか判断するように構成されている、システム。

Images