JP6556370B2 - 分散型ハッシュテーブル及びピア・ツー・ピア分散型台帳を利用してデジタルアセットのインテグリティを検証する方法及びシステム - Google Patents

Description

本開示は、デジタルアセットのインテグリティを保証及び維持するためのセキュリティ、制御及び検証方法に関する。本発明は、特にコンピュータソフトウェアのアイテムのオーナシップ及び／又はインテグリティを検証することに適している。これは、分散型ハッシュテーブル及びピア・ツー・ピア分散型台帳（ブロックチェーン）を利用することを含みうる。

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

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

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

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

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

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

それらが提供する改ざん耐性な記録のため、ブロックチェーンは、イベントの制御及び可視性及びセキュアなトランザクション／交換が重要であるアプリケーションに良く適している。そのような１つの適した適用領域は、例えば、ソフトウェアなどのデジタルアセットの交換又は移転である。コンピュータソフトウェアのインテグリティ及び共有をセキュアにする従来のアプローチは、コンピュータソフトウェアの実行可能ファイルのデジタル署名に関する。例えば、公開鍵及び秘密鍵などの暗号化キーペアによって実行可能ファイル又は他の関連するコードを署名する。公開鍵は、しばしば認証機関などの信頼された中央機関から取得される。

コンピュータソフトウェアは、しばしば契約上の義務を含むライセンスを伴う。ライセンスは、ソフトウェアの使用又は再配布を管理する条項を含みうる。コンピュータソフトウェア又は関連するライセンスが違法に他のユーザに移転される場合、問題が発生しうる。

コンピュータソフトウェア又はプログラムは、一般にそこに含まれる命令の実行が行われうる前にインストールを必要とする。インストールは、実行用のコンピュータソフトウェア又はプログラムを準備する。コンピュータソフトウェア又はプログラムは、しばしばインストールを実行するインストーラを備える。インストールが一旦実行された後、それは再び実行される必要はなく、コンピュータソフトウェア又はプログラムは繰り返し実行されうる。

インストールされると、コンピュータソフトウェアのオーナシップ及びインテグリティを検証することが必要である。これは、例えば、コンピュータソフトウェアが誤ったオーナに移転されておらず、コンピュータソフトウェアが輸送中に改ざん又は変更されていないことを保証することである。

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

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

本発明は、添付した請求項において規定されるような方法及び対応するシステムを提供する。本発明は、コンピュータにより実現される制御及び検証方法／システムを提供しうる。それは、コンピュータベースネットワーク上のユーザ間の被制御アセットの移転を可能又は実現しうる。アセットはデジタルアセットであってもよい。ここで、“ユーザ”という用語はコンピュータベースリソースを参照するのに利用されうる。被制御アセットは、ソフトウェアの一部又はアイテムであってもよい。本発明は、コンピュータソフトウェアの一部など、被制御アセットのオーナシップ及び／又はインテグリティを検証するコンピュータにより実現される方法を提供しうる。ソフトウェアは、コンピュータベースリソースへのインストールについて検証されうる。検証は、一致が確定された場合、ユーザがソフトウェアを利用又はやりとりするか、あるいは、ソフトウェアに関連していくつかの処理を実行することを許可又は可能にすることに関するものであってもよい。

当該方法は、分散型ハッシュテーブル(DHT)及びピア・ツー・ピア分散型台帳（ブロックチェーン）を利用して、インストールのためのコンピュータソフトウェアの一部又はアイテムなどのデジタルアセットのインテグリティを検証するコンピュータにより実現される方法を有してもよい。それは、ピア・ツー・ピア分散型台帳に格納されるトランザクションレコード(Tx)に関連するメタデータ(M)を決定し、メタデータ(M)から分散型ハッシュテーブルに格納されるエントリの指示を決定し、コンピュータソフトウェアに基づき第3のハッシュ値(H3)を決定し、分散型ハッシュテーブルのエントリから第4のハッシュ値(H4)を決定し、第3のハッシュ値(H3)と第4のハッシュ値(H4)とを比較し、第3のハッシュ値（H3）と第4のハッシュ値（H4）との比較に基づき、コンピュータソフトウェアのインテグリティを検証することを有してもよい。

従って、本発明は、別々の技術的ソース、すなわち、ブロックチェーンとDHTとのそれぞれの利用を含む。従って、本発明は、それらの間のデータの相互通信及び移転による技術的に異なって別々のストレージリソースの利用を含む。DHT及びブロックチェーンからのデータを検索、処理及び抽出することによって、本発明は、デジタルアセット（例えば、ソフトウェア）のインストール、検証、転送及び認可に対するよりセキュアなアプローチをもたらすエンハンスされた制御、セキュリティ及び検証効果を実現可能である。それはまた、ソフトウェアインテグリティを保証するための機構（すなわち、ソフトウェアがそれの元の又は意図された状態に対していくつかの方法で変更されていないこと）を提供し、期待されるように実行するため、エンハンスされたコンピュータシステムを提供する。

当該方法では、第3のハッシュ値（H3）と第4のハッシュ値（H4）とを比較することは、第3のハッシュ値（H3）と第4のハッシュ値（H4）とが一致するか判断することを含んでもよい。“一致”という用語の意味は、比較されるアイテムの間の対応、同等又は関連を含んでもよい。

当該方法では、メタデータ（M）を決定する前に、当該方法は、ピア・ツー・ピア分散型台帳に格納されるトランザクションレコード（Tx）から、第2のユーザ（U2）に関連する第2のユーザの公開鍵（PU2）を決定し、分散型ハッシュテーブルに格納されるエントリから、第2のユーザ（U2）に関連する第2の公開鍵（P2）を決定し、第2のユーザの公開鍵（PU2）と第2の公開鍵（P2）とを比較し、第2のユーザの公開鍵（PU2）と第2の公開鍵（P2）との比較に基づき、コンピュータソフトウェアのオーナシップを検証することを含んでもよい。当該方法では、第2のユーザの公開鍵（PU2）と第2の公開鍵（P2）との比較は、第2のユーザの公開鍵（PU2）と第2の公開鍵（P2）とが一致するか判断することを含んでもよい。

当該方法では、第2のユーザの公開鍵（PU2）を決定する前に、当該方法は、コンピュータソフトウェアに関連するデータ（D1）を決定し、コンピュータソフトウェアの第1のハッシュ値（H1）を決定し、データ（D1）とコンピュータソフトウェアとに基づき第2のハッシュ値（H2）を決定し、通信ネットワークを介し分散型ハッシュテーブルへの格納のためのエントリにデータ（D1）、第1のハッシュ値（H1）及び第2のハッシュ値（H2）を送信し、第2のハッシュ値（H2）はキー・値ペアのキーであり、データ（D1）及び第1のハッシュ値（H1）はキー・値ペアの値であり、ピア・ツー・ピア分散型台帳への格納のため第2のハッシュ値（H2）を含むメタデータ（M）を決定することを含んでもよい。

当該方法では、コンピュータソフトウェアは、ヘッダとボディとを含んでもよい。第3のハッシュ値（H3）は、コンピュータソフトウェアのボディから決定されてもよい。ヘッダは、コンピュータソフトウェアのボディのハッシュ値を含んでもよい。ヘッダは更に、第2のハッシュ値（H2）を含んでもよい。コンピュータソフトウェアのボディは、コンピュータソフトウェアの実行可能ファイルを含んでもよい。

当該方法では、第2のユーザの公開鍵（PU2）を決定する前に、当該方法は、コンピュータソフトウェアの実行可能ファイルを暗号化することを含んでもよい。コンピュータソフトウェアの実行可能ファイルを暗号化することは、生成値（GV）を決定し、第2のユーザの公開鍵（PU2）と生成値（GV）とに基づき第2のユーザの第2の公開鍵（P2U2）を決定し、第2のユーザの第2の公開鍵（P2U2）は第2のユーザの第2の秘密鍵（V2U2）と暗号化ペアを構成し、第1のユーザの秘密鍵（VU1）と生成値（GV）とに基づき第1のユーザの第2の秘密鍵（V2U1）を決定し、第1のユーザの秘密鍵（VU1）は第1のユーザの公開鍵（PU1）と暗号化ペアを構成し、第2のユーザの第2の公開鍵（P2U2）と第1のユーザの第2の秘密鍵（V2U1）とに基づき共通秘密（CS）を決定し、コンピュータソフトウェアの暗号化された実行可能ファイルを生成するため、共通秘密（CS）によってコンピュータソフトウェアを暗号化することを含んでもよい。

当該方法では、コンピュータソフトウェアの暗号化された実行可能ファイルは、第1のユーザの第2の公開鍵（P2U1）と第2のユーザの第2の秘密鍵（V2U2）とに基づき共通秘密（CS）を決定し、コンピュータソフトウェアの解読された実行可能ファイルを生成するため、共通秘密（CS）によってコンピュータソフトウェアの実行可能ファイルを解読することによって解読されてもよい。それはまた、第2のユーザの秘密鍵（VU2）と生成値（GV）とに基づき第2のユーザの第2の秘密鍵（V2U2）を決定し、第2のユーザの秘密鍵（VU2）は第2のユーザの公開鍵PU2と暗号化ペアを構成し、及び／又は第1のユーザの秘密鍵（VU1）と生成値（GV）とに基づき第1のユーザの第2の秘密鍵（V2U1）を決定し、第1のユーザの秘密鍵（VU1）は第1のユーザの公開鍵（PU1）と暗号化ペアを構成することを含んでもよい。

当該方法は更に、第2のユーザ（U2）に関連する処理デバイスにコンピュータソフトウェアの解読された実行可能ファイルをインストールすることを更に含んでもよい。

当該方法は更に、第2のユーザ（U2）からのアクティベーションキー（AK）を決定し、アクティベーションキー（AK）に基づきコンピュータソフトウェアの解読された実行可能ファイルの命令を実行することを含んでもよい。

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

分散型ハッシュテーブル及びピア・ツー・ピア分散型台帳を利用してインストールのためのコンピュータソフトウェアのインテグリティを検証するコンピュータシステムであって、当該システムは、ノードのピア・ツー・ピアネットワーク上のノードに関連し、ピア・ツー・ピア分散型台帳に格納されるトランザクションレコードに関連するメタデータ（M）を決定し、メタデータ（M）から分散型ハッシュテーブル上のエントリの位置の指示を決定し、コンピュータソフトウェアに基づき第3のハッシュ値（H3）を決定し、分散型ハッシュテーブルのエントリから第4のハッシュ値（H4）を決定し、第3のハッシュ値（H3）と第4のハッシュ値（H4）とを比較し、第3のハッシュ値（H3）と第4のハッシュ値（H4）との比較に基づき、コンピュータソフトウェアのインテグリティを検証するよう構成される処理デバイスを有するコンピュータシステム。

ハッシュテーブルの具体例を示す。 分散型ハッシュテーブルを利用したインストール用のコンピュータソフトウェアのコンピュータソフトウェアをセキュアにするメタデータ（M）を決定する一例となるシステムの概略図を示す。 分散型ハッシュテーブルを利用したコンピュータソフトウェアをセキュアにするメタデータ（M）を決定するコンピュータにより実現される方法のフローチャートを示す。 マークルツリーの具体例を示す。 コンピュータソフトウェア及びコンピュータソフトウェアに関連するライセンスを参照したマークルツリーの具体例を示す。 分散型ハッシュテーブルを利用してコンピュータソフトウェアの位置を示す識別子を決定するコンピュータにより実現される方法のフローチャートを示す。 分散型ハッシュテーブル及びピア・ツー・ピア分散型台帳を利用したインストール用のコンピュータソフトウェアのオーナシップを検証するコンピュータにより実現される方法のフローチャートを示す。 共通秘密を決定するコンピュータにより実現される方法のフローチャートを示す。 コンピュータソフトウェアの実行可能ファイルを暗号化するコンピュータにより実現される方法のフローチャートを示す。 分散型ハッシュテーブル及びピア・ツー・ピア分散型台帳を利用したインストール用のコンピュータソフトウェアのインテグリティを検証するコンピュータにより実現される方法のフローチャートを示す。 一例となる処理デバイスの概略を示す。

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

以下に説明される実施例はビットコインブロックチェーン（ここではブロックチェーンとして参照される）上で行われるトランザクションを特に言及するが、本発明は他のP2P分散型台帳を利用して実現されうることが理解されるであろう。ブロックチェーンは、それのハイレベルな規格化及び大量の関連する公開文献によってのみ簡単化のため本発明の態様を説明するのに利用される。

分散型ハッシュテーブル
典型的なクライアント／サーバモデルでは、中央サーバは、リソースの大多数を担当しうる。これは、中央サーバ上の攻撃又は故障のイベントにおいて、中央サーバに格納されているリソースの大多数が危険にさらされうることを意味する。他方、分散モデルでは、リソースは参加ノードの間で共有（分散）される。このようにして、全ての参加ノードのキャパシティが利用され、1つのサーバの故障がリソースの大多数を危険にさらさない。

図1は、ハッシュテーブルの具体例を示す。ハッシュテーブルは、キー・値ペア（key-value pair）から構成される。各キー・値ペアのキーは、ハッシュ関数を介しインデックスにマッピングされる。インデックスは、キー・値ペアの格納された値の位置を規定する。

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

ハッシュテーブルと同じように、DHTにおける各キー・値ペアはインデックスにマッピングされる。インデックスは、キーに対してハッシュ関数を実行することによって、各キー・値ペアについて決定される。例えば、暗号化セキュアハッシュアルゴリズムSHA-1が、インデックスを決定するのに利用されてもよい。

各参加ノードには、キースペースパーティショニングによって少なくとも1つのインデックスが割り当てられる。参加ノードに割り当てられる各インデックスについて、参加ノードは当該キー・値ペアの値を格納する。

キー・値ペアの値が効率的に抽出されうることは効果的である。キーに関連する値を抽出するため、ノードは、（インデックスを介し）責任のあるノードを決定するため、“ルックアップ”を実行してもよい。責任ノードは、それから値を決定するためにアクセスされてもよい。

ビットコイン及びブロックチェーン
当該技術において周知のように、ブロックチェーンは、記憶容量がビットコインプロトコルに基づきシステムに参加しているネットワーク接続されたノード間で分散されるトランザクションタイプ台帳のデータベースである。各ビットコイントランザクションはネットワークにブロードキャストされ、承認されて、その後にブロックにアグリゲートされる。その後、ブロックは、当該ブロックを複数の参加ノードに格納することによってブロックチェーン上に含まれる。

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

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

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

このようにして、トランザクションに関する情報が実際のトランザクションにおいて取得される。このレコードは永続的で不変であり、従って、第三者が別のデータベース上でトランザクションレコードを保持する必要性を取り除く。

pay-to-script-hash及びマルチシグネチャ
以下の実施例は、具体的にはビットコインプロトコルのpay-to-script-hash(P2SH)法を利用するトランザクションについて言及するが、本発明はpay-to-public-key-hash法などのビットコインプロトコルの他の方法を利用して実現されてもよい。

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

背景として、ビットコインプロトコルの標準的なP2SH法では、アウトプットスクリプト又はredeemスクリプトは、

の形態をとりうる。

ここで、NumSigsはトランザクションをアンロックするためredeemスクリプトを充足させるのに必要とされる有効なシグネチャの数”m”であり、PubK1, PubK2 … PubK15はトランザクションをアンロックするシグネチャに対応する公開鍵であり（最大で15までの公開鍵）、NumKeysは公開鍵の数”n”である。

ビットコインプロトコルでは、ユーザの秘密鍵に基づくシグネチャは、楕円曲線デジタルシグネチャアルゴリズムを利用して生成されうる。このとき、シグネチャは、アウトプットスクリプト又はredeemスクリプトに関連する仮想通貨の償還（redemption）に利用される。ユーザがアウトプットスクリプト又はredeemスクリプトを償還するとき、ユーザはシグネチャ及び公開鍵を提供する。アウトプットスクリプト又はredeemスクリプトは、その後に公開鍵に対してシグネチャを検証する。

上記のredeemスクリプトを償還するため、公開鍵に対応するシグネチャの数”m”が少なくとも必要とされる。いくつかの具体例では、公開鍵の順序が重要であり、署名のための”n”のシグネチャのうちの数”m”が順序通りに実行される必要がある。例えば、”m”が2であり、”n”が15である場合を検討する。2つのシグネチャ、Sig1（PubK1に対応する）及びSig15（PubK15に対応する）が利用可能である場合、redeemスクリプトはまずSig1によって、その後にSig15によって署名される必要がある。

システムの概要
インストールのためにコンピュータソフトウェアをセキュアにし、コンピュータソフトウェアのオーナシップを検証するためのメタデータ（M）を決定する方法、デバイス及びシステムが説明される。

図2は、通信ネットワーク5を介し第2のノード7と通信する第1のノード3を含むシステム1を示す。第1のノード3は関連する第1の処理デバイス21を有し、第2のノード5は関連する第2の処理デバイス27を有する。第1及び第2のノード3,7の具体例は、コンピュータ、タブレットコンピュータ、モバイル通信デバイス、コンピュータサーバなどの電子デバイスを含む。

図2において、キー・値ペアを記録及び格納するためのDHT13がまた示される。DHT13は、キー・値ペアの値を受信、記録及び格納するため1つ以上の処理デバイス19に関連付けされてもよい。処理デバイス19は、DHT13の参加ノードによって利用されてもよい。上述したように、DHT13は、キー・値ペアの値を特定する効率的な方法を提供する。

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

第1のノード3は第1のユーザ23に関連し、第2のノード7は第2のユーザ24に関連する。一例では、第1のノード3はコンピュータソフトウェアのベンダを表すものであってもよい。他の例では、第1のノード3はエージェント又はサービスプロバイダを表すものであってもよい。更なる他の例では、第1のノード3はコンピュータソフトウェアのユーザを表すものであってもよい。

第2のノード7はコンピュータシステムのユーザを表すものであってもよい。他の例では、第2のノード7はエージェント、サービスプロバイダ又はコンピュータソフトウェアのベンダを表すものであってもよい。

一例では、第1のノード3が、図3、図6、図7、図8及び図9によって示されるような方法100,300,400,500,600,700,800を実行する。他の例では、第2のノード7が、方法100,300,400,500,600,700,800を実行する。

例示的な以下の実施例は第1のノード3が当該方法を実行するとして、あるいは、第2のノード7が当該方法を実行するとして言及するが、本開示はまた他のノードによって実行されるように適応又は修正されてもよいことが理解されるべきである。

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

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

方法100は更に、通信ネットワーク5を介しDHT13上のエントリにデータ(D1)、第1のハッシュ値（H1）及び第2のハッシュ値（H2）を送信すること（140）を含み、第2のハッシュ値（H2）はキー・値ペアのキーに割り当てられ、データ（D1）及び第1のハッシュ値（H1）はキー・値ペアにおける値に割り当てられる。キー・値ペアにおける値は更に、コンピュータソフトウェア又はライセンスの位置を示す識別子を含んでもよい。

方法100はまた、ピア・ツー・ピア分散型台帳14上に含めるため、第2のハッシュ値（H2）に基づくメタデータ(M)を決定すること（150）を含む。一例では、メタデータ(M)は、ピア・ツー・ピア分散型台帳14上に含めるため第1のredeemスクリプト（RS1）に含まれてもよい。

図7によって示されるような方法600は、コンピュータソフトウェアのオーナシップを検証し、上述した方法の後に実行される。これは、図7における任意的ステップ100として示される。方法600は、ピア・ツー・ピア分散型台帳14上に格納されるトランザクションレコードから第2のユーザ（U2）に関連する第2のユーザの公開鍵（PU2）を決定すること（610）を含む。第2のユーザの公開鍵（PU2）は、トランザクションレコードのアウトプットスクリプトに含まれてもよい。他の例では、第2のユーザの公開鍵（PU2）は、上述したようなピア・ツー・ピア分散型台帳14上にあるメタデータ（M）に含まれてもよい。

方法600はまた、DHT13上に格納されるエントリから第2のユーザ（U2）に関連する第2の公開鍵（P2）を決定すること（620）を含む。第2の公開鍵（P2）は、第2のユーザの公開鍵（PU2）と同じであってもよい。DHT13上のエントリはキー・値ペアを含んでもよい。

方法600は更に、第2のユーザの公開鍵（PU2）と第2の公開鍵（P2）とを比較すること（630）を含む。方法600はまた、第2のユーザの公開鍵（PU2）と第2の公開鍵（P2）との比較に基づき、コンピュータソフトウェアのオーナシップを検証すること（640）を含む。一例では、オーナシップの検証は、第2のユーザの公開鍵（PU2）と第2の公開鍵（P2）とが一致していることを示すものであってもよい。すなわち、第2のユーザの公開鍵（PU2）と第2の公開鍵（P2）との間の一致は、オーナシップが検証されていることを示すものであってもよい。

図10によって示されるような方法900は、コンピュータソフトウェアのインテグリティを検証し、上述した方法の後に実行される。これは、図10における任意的ステップ600として示される。方法900は、ピア・ツー・ピア分散型台帳14上に格納されるトランザクションレコードに関連するメタデータ（M）を決定すること（910）を含む。メタデータ（M）は、トランザクションレコードのアウトプットスクリプトに含まれてもよい。方法900はまた、メタデータ（M）からDHT13上に格納されるエントリの指示を決定すること（920）を含む。一例では、エントリの指示は、分散型ハッシュテーブル13上のエントリを特定するアドレスを含んでもよい。

方法900はまた、コンピュータソフトウェアに基づき第3のハッシュ値（H3）を決定すること（930）を含む。一例では、第3のハッシュ値（H3）は、コンピュータソフトウェアのコンテンツに基づき計算される。方法はまた、DHT13上のエントリから第4のハッシュ値（H4）を決定すること（640）を含む。

方法900は更に、第3のハッシュ値（H3）と第4のハッシュ値（H4）とを比較すること（950）を含む。方法900はまた、第3のハッシュ値（H3）と第4のハッシュ値（H4）との比較に基づき、コンピュータソフトウェアのインテグリティを検証すること（960）を含む。一例では、インテグリティの検証は、第3のハッシュ値（H3）と第4のハッシュ値（H4）とが一致することを示すものであってもよい。すなわち、第3のハッシュ値（H3）と第4のハッシュ値（H4）との間の一致は、インテグリティが検証されていることを示すものであってもよい。

方法100, 600, 900の詳細な具体例が説明される。

コンピュータソフトウェア110に関連するデータの決定
上述したように、方法100は、コンピュータソフトウェアに関連するデータ（D1）を決定すること（110）を含む。データ（D1）の決定（110）は、ユーザ、ノード又はデータストアからデータ（D1）を受信することを含むものであってもよい。データ（D1）の決定（110）は更に、第1のノード3においてデータ（D1）を生成することを含むものであってもよい。

一例では、第1のノード3は、ユーザインタフェース15を介し第1のユーザ23からデータ（D1）を受信してもよい。他の例では、第1のノード3は、第2のユーザ24からデータ（D1）を受信してもよい。更なる他の例では、第1のノード3は、データストア17からデータ（D1）を受信してもよい。

データ（D1）はコンピュータソフトウェアと関連し、データ（D1）はコンピュータソフトウェア、付加情報、コンピュータソフトウェアのライセンスを特定するか、あるいは、コンピュータソフトウェアの位置を示すものであってもよい。例えば、データ(D1)は、コンピュータソフトウェアを特定する文字列又はデータ構造を含んでもよい。文字列又はデータ構造は、コンピュータソフトウェアに関するキーワード及び／又は付加情報を特定する集まりを含んでもよい。付加情報の具体例は、例えば、数値などのコンピュータソフトウェアのバージョンの識別子であってもよい。例えば、コンピュータソフトウェアがBobSoftwareという名前であり、バージョンが3.0である場合、文字列又はデータ構造（D1）は“BobSoftware/3.0”を含んでもよい。

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

データ（D1）は更に、コンピュータソフトウェアの格納位置を示す識別子を含むものであってもよい。一例では、識別子はインターネット上のオブジェクトのURLを含んでもよい。更なる例では、ハッシュテーブル又は分散型ハッシュテーブルなどのレポジトリ上のコンピュータソフトウェアの格納位置へのリンクが提供されてもよい。

更なる他の例では、データ（D1）は、コンピュータソフトウェアのベンダを特定する情報を含んでもよい。これは、名前、アドレス、連絡の詳細又はベンダに関連する公開鍵などのパーソナル詳細を含むものであってもよい。

コンピュータソフトウェア120に基づく第1のハッシュ値（H1）の決定
上述したように、方法100は更に、コンピュータソフトウェアの第1のハッシュ値（H1）を決定すること（120）を含む。第1のハッシュ値（H1）の決定（120）は、ユーザから第1のハッシュ値（H1）を受信すること、あるいは、データストアから第1のハッシュ値（H1）にアクセスすることを含んでもよい。第1のハッシュ値（H1）の決定（120）は更に、第1のノード3においてハッシュ値を計算することを含んでもよい。

一例では、第1のノード3は、ユーザインタフェース15を介し第1のユーザ23から第1のハッシュ値（H1）を受信してもよい。他の例では、第1のノード3は、第2のユーザ24から第1のハッシュ値（H1）を受信してもよい。更なる他の例では、第1のノード3は、ローカルなデータストア17又はリモートなデータストアから第1のハッシュ値（H1）にアクセスしてもよい。

一例では、第1のハッシュ値（H1）は、コンピュータソフトウェアの実行可能ファイルのものである。コンピュータソフトウェアの実行可能ファイルは、インターネットなどの通信ネットワーク5から抽出されてもよい。他の例では、実行可能ファイルは、第1のユーザ23又は第2のユーザ24によって提供されてもよい。更なる他の例では、実行可能ファイルはデータストア17から抽出されてもよい。また更なる具体例では、実行可能ファイルは、ハッシュテーブル又はDHTなどのレポジトリから抽出可能であってもよい。

ソフトウェアの実行可能ファイルのハッシュは、SHA-256アルゴリズムを利用して情報の256ビット表現を生成して決定されてもよい。Secure Hash Algorithm(SHA)ファミリにおける他のアルゴリズムを含む他のハッシュアルゴリズムが利用されてもよいことが理解されるべきである。いくつかの特定の具体例は、SHA3-224, SHA3-256, SHA3-384, SHA3-512, SHAKE128, SHAKE256を含むSHA-3サブセットにおけるインスタンスを含む。他のハッシュアルゴリズムは、RIPEMD（RACE Integrity Primitives Evaluation Message Digest）ファミリにおけるものを含んでもよい。特定の具体例は、RIPEMD-160を含んでもよい。他のハッシュ関数は、Zemor-Tillichハッシュ関数及びナップザックベースハッシュ関数に基づくファミリを含んでもよい。

データ（D1）及びコンピュータソフトウェア130に基づく第2のハッシュ値（H2）の決定
方法100はまた、データ（D1）及びコンピュータソフトウェアに基づき第2のハッシュ値（H2）を決定すること（130）を含む。

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

付加情報は、第1のユーザ23（PU1）又は第2のユーザ24（PU2）の公開鍵を含んでもよい。更なる例では、付加情報は、第1のユーザ23又は第2のユーザ24に関連するエンティティの識別子を含んでもよい。例えば、当該エンティティは、第1のユーザ23又は第2のユーザ24の雇用者であってもよい。他の例では、当該エンティティは、第1のユーザ23又は第2のユーザ24のサービスプロバイダであってもよい。

付加情報は更に、第1のノード3、第2のノード7、第1のユーザ23又は第2のユーザ24に関連するデバイスのデバイス識別子を含んでもよい。デバイスの具体例は、図2に示されるような第1の処理デバイス21である。デバイス識別子は、以下の少なくとも1つ、MACアドレス、マザーボードシリアルナンバー又はデバイス識別番号を含んでもよい。デバイス識別子は更に、MACアドレス、マザーボードシリアルナンバー又はデバイス識別番号の少なくとも2つの連接であってもよい。更なる例では、デバイス識別子は、MACアドレス、マザーボードシリアルナンバー、デバイス識別番号又は上記の連接に関連するハッシュ値を含んでもよい。

更なる他の例では、付加情報はコンピュータソフトウェアに関連するライセンスの有効期限日を含んでもよい。

コンピュータソフトウェアに関連するライセンス
更なる例では、第2のハッシュ値（H2）は、データ（D1）、コンピュータソフトウェアの実行可能ファイル（又は実行可能ファイルのハッシュ）、付加情報又はコンピュータソフトウェアに関連するライセンスの連接に基づき決定されてもよい。

ライセンスの表現は、ライセンスのコンテンツを指定するファイル又はドキュメントであってもよい。例えば、プレーンASCIIテキスト、PDFドキュメント又はWordドキュメントである。第2のハッシュ値（H2）は、それのオリジナルの形式によるライセンスを含むか、あるいは、インターネットなどの公衆にアクセス可能な通信ネットワーク上のライセンスの位置へのリンクを提供してもよい。更なる例では、ハッシュテーブル又はDHTなどのレポジトリ上のライセンスの位置へのリンクが提供されてもよい。更なる他の例では、データストア17などのコンピュータベースリソース上のライセンスの位置へのリンクが提供されてもよい。

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

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

コンピュータソフトウェアに関連するライセンスは更に、第1のノード3、第2のノード7、第1のユーザ23又は第2のユーザ24に関連するデバイスのデバイス識別子を含んでもよい。デバイスの具体例は、図2に示されるような第1の処理デバイス21である。デバイス識別子は、以下の少なくとも1つ、MACアドレス、マザーボードシリアルナンバー又はデバイス識別番号を含んでもよい。デバイス識別子は更に、MACアドレス、マザーボードシリアルナンバー又はデバイス識別番号の少なくとも2つの連接であってもよい。更なる例では、デバイス識別子は、MACアドレス、マザーボードシリアルナンバー、デバイス識別番号又は上記の連接に関連するハッシュ値を含んでもよい。

第1のユーザ23はコンピュータソフトウェアのベンダであってもよく、第2のユーザ24はコンピュータソフトウェアの受信者（“エンドユーザ”）であってもよい。他の例では、第2のユーザ24はコンピュータソフトウェアのベンダであってもよく、第1のユーザ23はコンピュータソフトウェアのエンドユーザであってもよい。

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

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

ライセンスが第1のユーザ23又は第2のユーザ24に関連する場合、ライセンスは、第1のユーザ23に関連する第1のユーザの公開鍵（PU1）と、第2のユーザ24に関連する第2のユーザの公開鍵（PU2）とを含んでもよい。

マークルツリー
他の例では、ライセンスは、マークルツリーの先頭のハッシュ値であってもよい。図4において、マークルツリーの具体例が示される。マークルツリーでは、各ノードにおけるハッシュ値は各自の“チャイルド”ノードのハッシュである。例えば、ハッシュ値Hash-A305は、2つの“チャイルド”ノード309，311におけるハッシュ値のハッシュである。マークルツリーの先頭のハッシュ値Hash-AB303はマークルツリーにおける全てのハッシュ値を含むことが理解できる。すなわち、それは、ツリーのボトムにおける4つの“リーフ”であるA1 317, A2 319, B1 321, B2 323のハッシュ値をキャプチャする。

本開示の例では、マークルツリーの各“リーフ”は、ライセンスの情報の側面を表すものであってもよい。図5において、一例となるライセンスが示される。データ（D1）417はハッシュ値Hash-D409においてキャプチャされ、ソフトウェア419の実行可能ファイルはハッシュ値Hash-S411（H1）においてキャプチャされ、ユーザ23及び／又は24の公開鍵421はハッシュ値Hash-P413においてキャプチャされ、有効期限日423はハッシュ値Hash-E415においてキャプチャされる。ノード405,407は、データ（D1）417、ソフトウェア419、公開鍵421及び有効期限日423のそれぞれのリーフに関連するハッシュ値をキャプチャすることが理解できる。

上述されない他の情報がハッシュ値（H2）が基づく付加情報を含みうることが理解されるべきである。

分散型ハッシュテーブル140へのデータ（D1）、第1のハッシュ値（H1）及び第2のハッシュ値(H2)の送信
方法100はまた、通信ネットワーク5を介し分散型ハッシュテーブル13上のエントリにデータ（D1）、第1のハッシュ値（H1）及び第2のハッシュ値（H2）を送信すること（140）を含む。

一例では、第2のハッシュ値（H2）はキー・値ペアのキーであってもよく、データ（D1）及び第1のハッシュ値（H1）はキー・値ペアにおける値であってもよい。

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

上述したように、DHT13はキー・値ペアから構成され、各キー・値ペアにはインデックスが割り当てられる。一例では、第2のハッシュ値（H2）はインデックスを生成するために利用されうる。ハッシュ関数又は暗号化ハッシュ関数が、第2のハッシュ値（H2）に対して実行されてもよい。例えば、暗号化関数SHA-1が利用されてもよい。

第2のハッシュ値（H2）がDHT13におけるキー・値ペアのキーとなるため、また、データ（D1）及び第1のハッシュ値（H1）がキー・値ペアにおける値になるため、キー及び値がDHT13の何れかの参加ノードに送信される。

一例では、put(key, value)などのメッセージがDHT13の参加ノードに送信されてもよく、keyは第2のハッシュ値（H2）であり、valueはデータ（D1）及び第1のハッシュ値（H1）である。メッセージは、それがキースペースパーティショニングによって示されるようなインデックスに割り当てられる参加ノードによって受信されるまで、全ての参加ノードにわたって送信されうる。メッセージにおいて示されるインデックスに割り当てられた参加ノードは、その後にDHT13上にキー・値ペアを格納し、キー・値ペアに関連するエントリを維持する責任を仮定する。

何れか所与のキーの値がDHT13から抽出されてもよいことが効果である。一例では、第1のユーザ23又は第2のユーザ24は値を抽出することを所望しうる。第1のユーザ23又は第2のユーザ24は、第1のノード3、第2のノード7又は図示されない他のノードを介しget(key)などのリクエストメッセージをDHT13の何れかの参加ノードに提供してもよい。リクエストメッセージは、その後、それがキースペースパーティショニングによって示されるインデックスに割り当てられる参加ノードによって受信されるまで、全ての参加ノードにわたって送信されてもよい。

メタデータ(M)150の決定
方法100は更に、第2のハッシュ値（H2）を含むメタデータ（M）を決定すること（150）を含む。メタデータ（M）の決定（150）は、ユーザ、ノード又はデータストアからメタデータ（M）を受信することを含んでもよい。メタデータ（M）は、例えば、P2P分散型台帳14上のトランザクションのP2SHマルチシグネチャの第1のredeemスクリプト（RS1）における公開鍵に利用可能な15の場所の1つ以上に含まれてもよい。

P2P分散型台帳14上のトランザクションの第1のredeemスクリプト（RS1）は、メタデータ（M）に含まれるコンテンツを表すトークン化されたトランザクション（“発行トークン”）の発行又は生成を表すものであってもよい。一例では、トークンはエージェント（A）によって発行されてもよい。

ビットコインプロトコルのP2SH法では、メタデータは以下に提供されるプロセスによってredeemスクリプトに含まれてもよい。

メタデータ
メタデータ(M)は、P2SHマルチシグネチャredeemスクリプト（RS1）における公開鍵に利用可能な15の場所の1つ以上に埋め込まれてもよい。例えば、redeemスクリプト（RS1）は、

の形態をとってもよく、ここで、Metadata1及びMetadata2はそれぞれ、redeemスクリプトにおける公開鍵の場所をとるメタデータを含み、PubK1及びPubK2は公開鍵である。

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

メタデータ（M）は、いくつかの方法で情報を含みうる。一例では、情報のコンテンツが含まれてもよい。更なる例では、情報の暗号化ハッシュが含まれてもよい。情報のハッシュは、SHA-256アルゴリズムを利用して情報の256ビット表現を生成して決定されてもよい。SHA（Secure Hash Algorithm）ファミリにおける他のアルゴリズムを含む他のハッシュアルゴリズムが利用されてもよいことが理解されるべきである。いくつかの特定の具体例は、SHA3-224, SHA3-256, SHA3-384, SHA3-512, SHAKE128, SHAKE256を含むSHA-3サブセットにおけるインスタンスを含む。他のハッシュアルゴリズムは、RIPEMD（RACE Integrity Primitives Evaluation Message Digest）ファミリにおけるものを含んでもよい。特定の具体例は、RIPEMD-160を含んでもよい。他のハッシュ関数は、Zemor-Tillichハッシュ関数に基づくファミリ及びナップザックベースハッシュ関数を含んでもよい。

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

従って、本開示の実施例におけるマルチシグネチャP2SHビットコイントランザクションの利用は、コンピュータソフトウェア及びライセンスに関連する情報の転送及び永続的な記録を可能にするため、効果を提供する。この記録は、例えば、redeemスクリプトなどのトランザクションのアウトプットスクリプトにメタデータを含めることによって実現される。

第1のredeemスクリプト
上述されたように、redeemスクリプトは、ビットコインプロトコルの標準的なP2SH法におけるアウトプットスクリプトの具体例であり、ユーザがトランザクションレコードにおいて指定される仮想通貨に対するアクセスをどのように取得可能であるかを記述する。

本開示では、発行トークンの第1のredeemスクリプト（RS1）はメタデータ(M)に基づくものであってもよい。第1のredeemスクリプト（RS1）は更に、エージェント秘密鍵（VA）を備えた暗号化ペアを形成するエージェント公開鍵（PA）を含んでもよい。このようにして、エージェント秘密鍵（VA）は、トランザクションに関連する仮想通貨を“アンロック”又は使用することが必要とされる。

一例では、発行トークンの第1のredeemスクリプト（RS1）はメタデータ（M）を含んでもよい。第1のredeemスクリプト（RS1）は更に、エージェント公開鍵（PA）を含んでもよい。本例では、第1のredeemスクリプト（RS1）は、

の形態を有してもよく、ここで、OP_1はトランザクションをアンロックするため第1のredeemスクリプト（RS1）を充足するよう必要とされるシグネチャの数(“NumSigs”)を示し、OP_3はredeemスクリプトにおける公開鍵の数(“NumKeys”)を示す。

本例では、第1のredeemスクリプト（RS1）は、メタデータの2つの指定されたフィールドMetadata1及びMetadata2を含んでもよい。Metadata1及びMetadata2の具体例が以下のテーブル1に示される。

本例は、ライセンスのサイズがメタデータ（M）にそのような詳細を含めることを妨げる場合に有用となりうるMetadata1におけるライセンスへのポインタを提供することを含む。さらに、メタデータ（M）が公開されるか、あるいは、非セキュアネットワークを介し送信されうるため、トークンの具体的詳細はプライバシの理由のため隠される又は隠蔽されることが望ましいかもしれない。

Metadata1の最初の4バイトはライセンスのタイプを示す。例えば、ライセンスタイプは、BobSoftwareなどのコンピュータソフトウェアの名前を示すものであってもよい。更なる例では、ライセンスタイプは、上述したような“シングルユーザ”又は“マルチデバイス”などのライセンスの認可タイプを示すものであってもよい。次の16バイトは、IPv6アドレスを考慮して、実際の電子ライセンスファイルの位置のIPアドレスを保持する。いくつかの実施例では、この値は、ライセンスファイルが中央化されるのでなくクラウド上に分散可能となるように、トレントファイルのシードをポインティングしうる。次の12バイトは、ライセンスのタイプに固有のデータを含む。

Metadata2の最初の20バイトは、ライセンスファイルの実際のコンテンツに適用されるSHA256に対してRIPEMD-160を利用した実際のライセンスファイルのハッシュである。実際のライセンスファイルは抽出可能であってもよいため、これは、契約に対するトランザクションの有効性を認める。ライセンスファイル自体は、具体的な実施例の要求に依存して、完全に公開（未暗号化及び人間に読める）であってもよいし、あるいは、プライバシのため暗号化されてもよい。Metadata2の残りの12バイトのコンテンツは、ライセンスのタイプに依存して利用されてもよい。

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

テーブル2の第4〜8行は、発行トークンに含まれるべき（すなわち、“トークン化”）第1の数量の仮想通貨（C1）であるトランザクションに対するインプットを表す。本例では、第1の数量の仮想通貨（C1）は、第1の数量の仮想通貨をエージェント（A）の利益に移転した前のトランザクション（ID-110）の結果であり、従って、前のトランザクション（ID-110）のアウトプットスクリプト（redeemスクリプトID-110）は、エージェントの公開鍵（PA）を含む。従って、この前のアウトプットをアンロックするため、スクリプト（redeemスクリプトID-110）は、第1のユーザの秘密鍵（VA）により署名される必要がある。最終的に、テーブル2の第8行は、第1の数量の仮想通貨（C1）がこのトランザクション（ID-600）における第1のアウトプットとなることを示す。

テーブル2の第9〜13行は、トランザクション（ID-600）の第1の（及び唯一の）アウトプットを表し、本ケースでは、発行トークンが生成されてエージェントに戻されることを表す。第10行は、第1の数量の仮想通貨（C1）であるアウトプット値を示す。第11行は、ビットコインプロトコルのP2SH法において利用されるような”< hash of redeem script >”を含むアウトプットスクリプトを示す。本例では、redeemスクリプトは、上述されたような形式における第1のredeemスクリプト（RS1）である。

テーブル2に示されるトランザクション（ID-600）のアウトプットが、その後にP2P分散型台帳14上に第1のデータアウトプット（O1）と共に記録される。特に、第1のデータアウトプット（O1）は、トランザクションにおいて移転された第1の数量の仮想通貨（C1）の指示を含むものであってもよい。第1のデータアウトプット（O1）は更に、第1のredeemスクリプト（RS1）のハッシュを含んでもよい。

例えば、第1のユーザ23又は第2のユーザ24へのトークンの移転など、第1の数量の仮想通貨（C1）の以降のトランザクションでは、第1の数量の仮想通貨（C1）をアンロックするためのスクリプト（例えば、以降のトランザクションのインプットScriptSig）は、

の形式であってもよく、ここで、Sig-VU1は第1のユーザ23のシグネチャを示す。上記のスクリプトは、エージェント（A）又は第1のユーザ23からの1つのシグネチャのみが第1の数量の仮想通貨（C1）をアンロックするのに必要とされることを仮定していることに留意されたい。

発行トークンは、第2のredeemスクリプト（RS2）を介し他のユーザに転送されてもよい。
［変形］
第2のredeemスクリプト
コンピュータソフトウェア及びライセンスに関連するトークンは、エージェント（A）から、例えば、第1のユーザ23又は第2のユーザ24などの他のユーザに移転されてもよい。一例では、トークンの移転は、コンピュータソフトウェア又はライセンスのユーザへのアクセスを認可するものとして表してもよい。当該移転は、第2のredeemスクリプト（RS2）によって実現されてもよい。

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

本例では、第2のredeemスクリプト（RS2）は、メタデータ（M）、エージェント（A）に関連するエージェント公開鍵（PA）及び第1のユーザ23に関連する第1のユーザの公開鍵（PU1）に基づくものであってもよい。

第2のredeemスクリプト（RS2）は、

の形式をとってもよい。

本例では、第2のredeemスクリプト（RS2）は、第1のredeemスクリプト（RS1）と同一の2つのメタデータフィールドを含む。第2のredeemスクリプト（RS2）は更に、エージェントに関連するエージェント公開鍵（PA）と、第1のユーザに関連する第1のユーザの公開鍵（PU1）とを含む。

上記で提供された第2のredeemスクリプト（RS2）の具体例から、移転されるトークンは使用されるためにエージェント（A）又は第1のユーザ23によって署名される必要があることが理解できる。この発行トークンの移転のためのトランザクションの具体例が、再び簡単化のためにマイナーの費用は示されていないテーブル3において提供される。

テーブル2と同様に、テーブル3の第4〜8行は、トランザクション（ID-610）に対するインプットを表す。本例では、インプットは発行トークン、すなわち、テーブル2に示されるトランザクション（ID-600）のアウトプットである。第7行におけるredeemスクリプトは、発行トークンのredeemスクリプト、すなわち、第1のredeemスクリプト（RS1）に対応することが理解できる。従って、トランザクション（ID-600）のアウトプットをアンロックするため、第1のredeemスクリプト（RS1）はエージェントの公開鍵（PA）により署名される必要がある。

テーブル3の第9〜13行は、本ケースでは、発行トークンがエージェント（A）又は第1のユーザ23（U1）の何れかに移転されることを表すトランザクション（ID-610）のアウトプットを表す。第10行は、第1の数量の仮想通貨（C1）であるアウトプット値を示す。第11行は、ビットコインプロトコルのP2SH法において利用されるような“< hash of redeem script >”を含むアウトプットスクリプトを示す。本例では、redeemスクリプトは、上述された形式による第2のredeemスクリプト（RS2）である。

その後、トランザクション（ID-610）のアウトプットは、P2P分散型台帳14上に第2のデータアウトプット（O2）と共に記録される。第2のデータアウトプット（O2）は、第1のデータアウトプット（O1）からの第1の数量の仮想通貨（C1）がトランザクションにおいて移転されるべきであるという指示を含んでもよい。第2のデータアウトプット（O2）は更に、第2のredeemスクリプト（RS2）のハッシュを含んでもよい。

コンピュータソフトウェア又はライセンスの位置を示す識別子
上述されたように、データ（D1）又はライセンスはそれぞれ、コンピュータソフトウェア又はライセンスの位置を示す識別子を含んでもよい。

一例では、当該識別子は、データ（D1）又はライセンスとは独立して決定されてもよく、データ（D1）又はライセンスと別々のままであってもよい。識別子は更に、方法100において上述されたように、データ（D1）及び第1のハッシュ値（H1）と一緒にキー・値ペアの値に割り当てられてもよい。このようにして、識別子はメッセージput(key, value)のvalueフィールドに含まれ、上述されたように、DHT13における参加ノードに送信されてもよい。

一例では、位置を示す識別子は、インターネット上のオブジェクトのURLを含んでもよい。他の例では、位置を示す識別子は、ハッシュテーブル又はDHT13などのレポジトリのアドレスを含んでもよい。更なる他の例では、位置を示す識別子は、第1のノード3の第1の処理デバイス21に関連するデータストア17など、コンピュータベースリソース上で提供されるサーバ、データベース又はストレージ施設などのコンピュータベースレポジトリのアドレスを含んでもよい。

図6は、コンピュータソフトウェア又はライセンスの位置を決定する方法500を示す。方法500は、第1のredeemスクリプト（RS1）からメタデータ（M）を決定すること（510）を含む。上述されたように、メタデータ（M）は、第1のredeemスクリプト（RS1）における公開鍵に利用可能な15の場所の1つ以上に埋め込まれてもよい。

ビットコインプロトコルのP2SH法では、トランザクションの出力が以降のトランザクションにおいて使用されるとき、redeemスクリプトは、以降のトランザクションにおいて可視的になる。テーブル2を参照して上述されたように、発行トークンのトランザクション（ID-600）は、エージェント（A）に払い戻される。このようにして、エージェント（A）は、第1のredeemスクリプト（RS1）を公開するため当該発行トークンを使用してもよい。従って、第2のハッシュ値（H2）に基づくメタデータ（M）は、P2P分散型台帳14上で可視的である。このようにして、第2のハッシュ値（H2）は、第1のredeemスクリプト（RS1）におけるメタデータ（M）から抽出可能である（520）。一例では、キー・値ペアのキーに関連する値は、リクエストメッセージget(key)を利用してDHT13から抽出可能である。

方法500は更に、通信ネットワーク5を介しDHT13の参加ノードに関連するプロセッサに第2のハッシュ値（H2）を送信すること（530）を含む。上述したように、第2のハッシュ値（H2）は、キー・値ペアのキーであってもよい。また上述したように、所与のキーの値は、DHT13の何れかの参加ノードに当該キーを含むメッセージを提供することによって抽出されてもよい。従って、識別子がキー・値ペアの値フィールドに含まれる具体例では、方法500は、コンピュータソフトウェア又はライセンスの位置を示す識別子を参加ノードのプロセッサから決定すること（540）が可能である。

第2のユーザ（U2）に関連する第2のユーザの公開鍵（PU2）の決定（610）
上述されたように、方法600は、P2P分散型台帳14上に格納されるトランザクションレコードから第2のユーザ（U2）に関連する第2のユーザの公開鍵（PU2）を決定すること（610）を含む。トランザクションレコードからの第2のユーザの公開鍵（PU2）の決定は、ユーザ、ノード又はデータストアからトランザクションレコードを受信し、第2のユーザの公開鍵（PU2）についてトランザクションレコードをクエリすることを含んでもよい。トランザクションレコードからの第2のユーザの公開鍵（PU2）の決定は更に、ユーザ、ノード又はデータストアにおいてトランザクションレコードにアクセスし、第2のユーザの公開鍵（PU2）についてトランザクションレコードをクエリすることを含んでもよい。

一例では、第2のユーザ24に関連する第2のノード7は、第1のノード3又は第1のノード3に関連するデータストア17からトランザクションレコードを受信してもよい。他の例では、第2のノード7は、第1のユーザ23又は第2のユーザ24からトランザクションレコードを受信してもよい。

更なる他の例では、第2のノード7は、第2のノード7又は第2のノード7に関連するデータストアにおいてトランザクションレコードにアクセスしてもよい。更なる例では、トランザクションレコードは、www.blockchain.infoなどの公衆に利用可能な施設を利用して第2のノード7によってアクセスされてもよい。

P2P分散型台帳14上に格納されるトランザクションレコードは、トランザクション又はトランザクションに関連するユーザを特定する情報を含んでもよい。テーブル4において、トランザクションレコードに含まれる情報の具体例が示される。

各トランザクションアウトプットは、移転される仮想通貨の数量に関する情報と、仮想通貨を使用するのに充足される必要がある条件を定義したアウトプットスクリプトとを含む。アウトプットスクリプトは、典型的には、仮想通貨の受信者に関連する公開鍵を含む。

一例では、アウトプットスクリプトにおける仮想通貨の受信者に関連する公開鍵は、第2のユーザの公開鍵（PU2）であってもよい。このようにして、第2のユーザ（U2）に関連する第2のユーザの公開鍵（PU2）は、P2P分散型台帳14上に格納されるトランザクションレコードに関するアウトプットスクリプトから決定される。

上述したように、ビットコインプロトコルのP2SH法では、アウトプットスクリプトはredeemスクリプトである。redeemスクリプトは、仮想通貨の送信者及び受信者に関連するいくつかの公開鍵を含みうる。一例では、第2のユーザ（U2）に関連する第2のユーザの公開鍵（PU2）は、トランザクションレコードのredeemスクリプトから決定されてもよい。

他の例では、第2のユーザの公開鍵（PU2）は、redeemスクリプトのメタデータ（M）に格納されてもよい。上述したように、P2SH法において、トランザクションのアウトプットが以降のトランザクションにおいて使用されるとき、redeemスクリプトはP2P分散型台帳14上で可視的になる。このようにして、第2のユーザの公開鍵（PU2）は、redeemスクリプトにおけるメタデータ（M）から抽出可能である。

第2のユーザ（U2）に関連する第2の公開鍵（P2）の決定（620）
方法600は更に、DHT13上に格納されるエントリから第2のユーザ（U2）に関連する第2の公開鍵（P2）を決定すること（620）を含む。第2の公開鍵（P2）の決定は、DHT13上に格納されるエントリに関連するキー・値ペアの値を抽出することを含んでもよい。第2の公開鍵（P2）の決定はまた、他のノードからキー・値ペアの値を受信することを含んでもよい。

一例では、DHT13上のエントリに関連するキー・値ペアの値は、DHT13の参加ノードにリクエストメッセージを送信することによって抽出されてもよい。上述したように、リクエストメッセージはget(key)を含んでもよく、ここで、keyはDHT13上のエントリに関連するキー・値ペアのキーである。

更なる例では、キー・値ペアのキーは第2のハッシュ値（H2）である。

他の例では、第2のノード7は、第1のノード3又は図示されない他のノードからDHT13上に格納される値を受信してもよい。第1のノード3又は他のノードは、DHT13の参加ノードにリクエストメッセージget(key)を提供してもよい。その後、第1のノード3又は他のノードは、DHT13上のエントリに関連するキー・値ペアの値を受信してもよい。その後、キー・値ペアの値は、通信ネットワーク5を介し第1のノード3又は他のノードから第2のノード7に送信されてもよい。

第2のユーザの公開鍵（PU2）と第2の公開鍵（P2）との比較（630）
当該方法は更に、第2のユーザの公開鍵（PU2）と第2の公開鍵（P2）とを比較すること（630）を含む。比較は、第2のユーザの公開鍵（PU2）と第2の公開鍵（P2）とが一致するか判断することを含みうる。

一例では、一致は、第2のユーザの公開鍵（PU2）と第2の公開鍵（P2）とが等しいことを示すものであってもよい。

他の例では、一致は、第2のユーザの公開鍵（PU2）と第2の公開鍵（P2）とが同じ仮想通貨ウォレットに属することを示すものであってもよい。

更なる例では、仮想通貨ウォレットは、決定性ウォレットであってもよく、一致は、第2のユーザの公開鍵（PU2）と第2の公開鍵（P2）とが共通のシードから導出されることを示すものであってもよい。共通のシードは、文字列であってもよい。

比較に基づきコンピュータソフトウェアのオーナシップを検証（640）
方法600は更に、第2のユーザの公開鍵（PU2）及び第2の公開鍵（P2）との比較に基づきコンピュータソフトウェアのオーナシップを検証すること（640）を含む。

一例では、比較が第2のユーザの公開鍵（PU2）と第2の公開鍵（P2）とが一致すると判断した場合、コンピュータソフトウェアのオーナシップの検証が行われる。
［変形］
コンピュータソフトウェア
コンピュータソフトウェアは、ヘッダ及びボディを含んでもよい。一例では、ヘッダはコンピュータソフトウェアに関連する情報を含んでもよい。更なる例では、ヘッダはコンピュータソフトウェアのボディのハッシュ値を含んでもよい。更なる他の例では、ヘッダは上述したような第2のハッシュ値（H2）を含んでもよい。

コンピュータソフトウェアのボディは、コンピュータソフトウェアの実行可能ファイルを含んでもよい。

コンピュータソフトウェアの実行可能ファイルの暗号化
上述した方法600では、第2のユーザの公開鍵（PU2）を決定する前に、方法600はコンピュータソフトウェアの実行可能ファイルを暗号化することを含んでもよい。

一例では、コンピュータソフトウェアの実行可能ファイルが、第1のユーザ23又は第2のユーザ24に関連する公開鍵によって暗号化される。他の例では、コンピュータソフトウェアの実行可能ファイルは、第1のノード3又は第2のノード7に関連する公開鍵により暗号化される。更なる他の例では、コンピュータソフトウェアの実行可能ファイルは、第三者又は図示されないノードに関連する公開鍵によって暗号化される。

他の例では、コンピュータソフトウェアの実行可能ファイルは、以下に提供される技術と同様に、共通秘密分散アプローチ（common secret sharing approach）を利用して暗号化されてもよい。

共通秘密（CS）の決定
暗号化のための共通秘密は、図8に示されるような方法300,400のステップをそれぞれ実行することによって、ノードに関連するユーザ23,24によってノード3,7において決定されてもよい。このようにして、共通秘密は通信ネットワーク5を介しユーザ23,24に関連する秘密鍵を通信することなく独立して決定されてもよい。

図8に示されるように、第1のユーザ23によって実行される方法300は、少なくとも第1のユーザの秘密鍵（VU1）及び生成値（GV）に基づき第1のユーザの第2の秘密鍵（V2U1）を決定すること（300）を含む。第1のユーザの秘密鍵（VU1）は、第1のユーザの公開鍵（PU1）と暗号化ペアを構成する。

生成値は、第1のユーザ23と第2のユーザ24との間で共有されるメッセージに基づくものであってもよく、通信ネットワーク5を介しメッセージを共有することを含むものであってもよい。方法300はまた、少なくとも第2のユーザの公開鍵（PU2）と生成値（GV）とに基づき第2のユーザの第2の公開鍵（P2U2）を決定すること（370）を含む。方法300は更に、第2のユーザの第2の公開鍵（P2U2）と第1のユーザの第2の秘密鍵（V2U1）とに基づき、第1のユーザ23において共通秘密（CS）を決定すること（380）を含む。

意義あることに、同じ共通秘密（CS）が方法400によって第2のノード7に関連する第2のユーザ24によって決定可能である。方法400は、第1のユーザの公開鍵（PU1）と生成値（GV）とに基づき第1のユーザの第2の公開鍵（P2U1）を決定すること（430）を含む。方法400は更に、第2のユーザの秘密鍵（VU2）と生成値（GV）とに基づき第2のユーザの第2の秘密鍵（V2U2）を決定すること（470）を含む。第2のユーザの秘密鍵（VU2）は、第2のユーザの公開鍵（PU2）と暗号化ペアを構成する。

方法400は更に、第1のユーザの第2の公開鍵（P2U1）と第2のユーザの第2の秘密鍵（V2U2）とに基づき、第2のユーザ24において共通秘密（CS）を決定すること（480）を含む。方法300,400は、第1のユーザの追加の公開鍵又は第2のユーザの追加の公開鍵を生成するよう繰り返されてもよい。

コンピュータソフトウェアの実行可能ファイルの暗号化
共通秘密（CS）は、暗号化のための対称鍵を生成するための基礎として利用されてもよい。一例では、共通秘密（CS）は、楕円曲線の点(x_s, y_s)の形式であってもよい。これは、ノード3,7によって合意された標準的な処理を利用して標準的な鍵形式に変換されてもよい。例えば、x_sの値は、AES₂₅₆（Advanced Encryption Standard)暗号化のための鍵として利用可能な256ビットの整数であってもよい。それはまた、RIPEMD160を利用して160ビットの整数に変換可能である。第1のユーザ23による暗号化によるセキュア通信の方法700,800が、図9を参照して説明される。

以下に提供される例示的な実施例では、第1のノード3に関連する第1のユーザ23は、コンピュータソフトウェアの実行可能ファイルを暗号化する方法700を実行する。方法700は第2のノード7において第2のユーザ24に等しく適用可能であることが理解されるべきである。

第1のユーザ23は、上記の方法300,400において決定された共通秘密（CS）に基づき対称鍵を決定する（710）。これは、上述したように標準的な鍵形式に共通秘密（CS）を変換することを含んでもよい。同様に、第2のユーザ24はまた、共通秘密（CS）に基づき対称鍵を決定可能である。

対称鍵は、コンピュータソフトウェアの暗号化された実行可能ファイルを構成するために、コンピュータソフトウェアの実行可能ファイルを暗号化するため（720）、第1のユーザ23によって利用されてもよい。その後、コンピュータソフトウェアの暗号化された実行可能ファイルは、コンピュータソフトウェアのボディに含まれる（730）。

コンピュータソフトウェアの暗号化された実行可能ファイルを含むコンピュータソフトウェアは、通信ネットワーク5を介し格納位置に送信されてもよい（740）。一例では、格納位置は、ハッシュテーブル又はDHT13などのレポジトリであってもよい。他の位置では、格納位置はインターネット上であってもよい。更なる他の例では、格納位置は、第1のノード3の第1の処理デバイス21に関連するデータストア17など、コンピュータベースリソース上で提供されるサーバ、データベース又は格納施設などのコンピュータベースレポジトリであってもよい。

第2のユーザ24は、次にコンピュータソフトウェアの暗号化された実行可能ファイルを決定する。コンピュータソフトウェアの暗号化された実行可能ファイルの決定は、上述したように格納位置からコンピュータソフトウェアをダウンロードすることを含むものであってもよい。一例では、第2のユーザ24は、DHT13上のエントリからコンピュータソフトウェアの暗号化された実行可能ファイルをダウンロードする。

第2のユーザ24は、対称鍵によってコンピュータソフトウェアの暗号化された実行可能ファイルをコンピュータソフトウェアの実行可能ファイルに解読してもよい（830）。

コンピュータソフトウェアのインストール
コンピュータソフトウェアの実行可能ファイルは、第2のユーザ24に関連する第2の処理デバイス27にコンピュータソフトウェアをインストールさせる命令を含んでもよい。一例では、コンピュータソフトウェアは、第2のユーザ24がコンピュータソフトウェアの暗号化された実行可能ファイルを解読した後（830）、第2の処理デバイス27にインストールされる。

更なる例では、アクティベーションキー(AK)が、第2のユーザ24がコンピュータソフトウェアの暗号化された実行可能ファイルを解読した後（830）、第2のユーザ24から決定される。一例では、第2の処理デバイス27に関連するユーザインタフェースは、アクティベーションキー（AK）に対して第2のユーザ24を促してもよい。第2のユーザ24は、キーボードデバイス、タッチ画面若しくはタッチパッドデバイス、マウスデバイス又はマイクロフォンデバイスなど、第2の処理デバイス27に関連する入力デバイスによってアクティベーションキー（AK）を提供してもよい。

アクティベーションキー（AK）は、シードアクティベーションキーから決定的に導出されてもよい。一例では、第1のユーザ23は、第1のノード3においてシードアクティベーションキーを決定してもよい。第1のユーザ23は、それからメッセージに基づき生成値（GV）を決定してもよい。その後、アクティベーションキー（AK）は、シードアクティベーションキーと生成値（GV）とに基づき決定されてもよい。

メタデータ（M）の決定（910）
上述したように、方法900は、P2P分散型台帳14上に格納されるトランザクションレコードに関連するメタデータ（M）を決定すること（910）を含む。メタデータ（M）の決定は、トランザクションレコードについてP2P分散型台帳14をクエリし、トランザクションレコードからメタデータ（M）を抽出することを含んでもよい。メタデータ（M）の決定は更に、ユーザ、ノード又はデータストアからトランザクションレコードに関連するメタデータ（M）を受信することを含んでもよい。

一例では、第2のノード7は、メタデータ（M）に関連するトランザクションレコードにアクセスするため、P2P分散型台帳14をクエリすることによってメタデータ（M）を決定する。更なる例では、トランザクションレコードは、www.blockchain.infoなどの公衆に利用可能な施設を利用してアクセスされてもよい。

他の例では、第1のノード3又は図示されない他のノードが、トランザクションレコードについてP2P分散型台帳14をクエリしてもよい。このようにして、メタデータ（M）は、第1のノード3又は図示されない他のノードから第2のノード７において受信されてもよい。

上述したように、メタデータ（M）は、例えば、P2SHマルチシグネチャredeemスクリプトにおける公開鍵に利用可能な場所の1つ以上などにおいてトランザクションレコードに含まれてもよい。

他の例では、第2のノード7は、コンピュータベースリソース上で提供されるサーバ、データベース又はストレージ施設などのコンピュータベースレポジトリからメタデータ（M）を受信してもよい。更なる例では、メタデータ（M）は、第1のノード3の第1の処理デバイス21に関連するデータストア17からアクセスされる。

DHT920上に格納されるエントリの指示の決定
方法900は更に、メタデータ（M）からDHT13上に格納されるエントリの指示を決定すること（920）を含む。DHT13上に格納されるエントリの指示の決定は、関連するトランザクションレコードからメタデータ（M）におけるフィールドから指示を抽出することを含んでもよい。

上述したように、テーブル1は、メタデータ（M）に含まれうる情報の具体例を提供する。テーブル1の第2行は、DHT13上に格納されるエントリの指示の具体例を示し、当該指示は、DHT13上に格納されるエントリの位置を特定するIPアドレスである。一例では、第2のノード7は、メタデータ（M）のLicencePointerフィールドに関連する値を抽出することによってエントリの指示を決定してもよい。

更なる例では、エントリの指示は、図示されないメタデータ（M）におけるフィールドに格納されてもよい。

コンピュータソフトウェア930に基づく第3のハッシュ値（H3）の決定
上述したように、方法900は更に、コンピュータソフトウェアに基づき第3のハッシュ値（H3）を決定すること（930）を含む。第3のハッシュ値（H3）の決定は、第2のノード7において第3のハッシュ値を計算することを含んでもよい。

一例では、第2のノード7は、コンピュータソフトウェアのコンテンツに基づき第3のハッシュ値（H3）を計算してもよい。更なる例では、第3のハッシュ値（H3）は、コンピュータソフトウェアのボディに基づくものであってもよい。更なる他の例では、第3のハッシュ値（H3）は、コンピュータソフトウェアの実行可能ファイルに基づくものであってもよい。

第3のハッシュ値（H3）は、コンピュータソフトウェアの256ビット表現を生成するためSHA-256アルゴリズムを利用して計算されてもよい。SHAファミリにおける他のアルゴリズムを含む他のアルゴリズムが利用されてもよいことが理解されるべきである。他のハッシュアルゴリズムは、RIPEMDファミリにおけるものを含んでもよい。

分散型ハッシュテーブル940上のエントリからの第4のハッシュ値（H4）の決定
方法900は更に、DHT13上のエントリから第4のハッシュ値（H4）を決定すること（940）を含む。第4のハッシュ値（H4）の決定は、第4のハッシュ値（H4）が格納されるDHT13上のエントリにアクセスすることを含んでもよい。

第4のハッシュ値（H4）は、コンピュータソフトウェアに基づくものであってもよい。一例では、第4のハッシュ値（H4）は、コンピュータソフトウェアの非ヘッダコンテンツに基づく。他の例では、第4のハッシュ値（H4）はコンピュータソフトウェアの実行可能ファイルに基づく。

一例では、第4のハッシュ値（H4）は、トランザクションレコードに関連するメタデータ（M）が930を参照して上述したように格納されるエントリ上に格納される。このようにして、第4のハッシュ値（H4）の決定は、エントリの指示によって参照されるようなDHT13上のエントリから第4のハッシュ値（H4）を抽出することを含んでもよい。すなわち、メタデータ（M）のLicencePointerフィールドによってである。

他の例では、第4のハッシュ値（H4）は第1のハッシュ値（H1）である。方法100において上述したように、第1のハッシュ値（H1）はDHT13上に格納される。このようにして、第4のハッシュ値（H4）は、keyがキー・値ペアのキーであるget(key)などのリクエストメッセージをDHT13の何れかの参加ノードに提供することによって、第2のノード7によって抽出されてもよい。本例では、keyは第2のハッシュ値（H2）である。リクエストメッセージは、それがキースペースパーティショニングによって示されるようなインデックスに割り当てられる参加ノードによって受信されるまで、参加ノードにわたって送信されてもよい。

第3のハッシュ値（H3）と第4のハッシュ値（H4）との比較（950）
上述したように、方法900は更に、第3のハッシュ値（H3）と第4のハッシュ値（H4）とを比較すること（950）を含む。比較は、第3のハッシュ値（H3）と第4のハッシュ値（H4）とが一致するか判断することを含んでもよい。

一例では、一致は、第3のハッシュ値（H3）と第4のハッシュ値（H4）とが等しいことを示すものであってもよい。

比較に基づくコンピュータソフトウェアのインテグリティの検証（960）
方法900は更に、第3のハッシュ値（H3）と第4のハッシュ値（H4）との比較に基づきコンピュータソフトウェアのインテグリティを検証すること（960）を含む。

一例では、比較が第3のハッシュ値（H3）と第4のハッシュ値（H4）とが一致すると判断した場合、コンピュータソフトウェアのインテグリティの検証が行われる。
［処理デバイス］
上述したように、第1のノード3と第2のノード7とは、コンピュータ、タブレットコンピュータ、移動通信デバイス、コンピュータサーバなどの電子デバイスであってもよい。電子デバイスは、処理デバイス21，27、データストア17及びユーザインタフェース15を含んでもよい。

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

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

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

Claims (17)

1. 分散型ハッシュテーブル及びピア・ツー・ピア分散型台帳を利用してインストールのためのコンピュータソフトウェアのインテグリティを検証するコンピュータにより実現される方法であって、
   前記ピア・ツー・ピア分散型台帳に格納されるトランザクションレコードに関連するメタデータを決定するステップと、
   前記メタデータから前記分散型ハッシュテーブルに格納されるエントリの指示を決定するステップと、
   前記コンピュータソフトウェアに基づき第3のハッシュ値を決定するステップと、
   前記分散型ハッシュテーブル上の前記エントリから第4のハッシュ値を決定するステップと、
   前記第3のハッシュ値と前記第4のハッシュ値とを比較するステップと、
   前記第3のハッシュ値と前記第4のハッシュ値との前記比較に基づき、前記コンピュータソフトウェアの前記インテグリティを検証するステップと、
   を含む方法。
2. 前記第3のハッシュ値と前記第4のハッシュ値とを比較するステップは、前記第3のハッシュ値と前記第4のハッシュ値とが一致するか判断するステップを含む、請求項１記載の方法。
3. 前記メタデータを決定するステップの前に、当該方法は、
   前記ピア・ツー・ピア分散型台帳に格納されるトランザクションレコードから、第2のユーザに関連する第2のユーザの公開鍵を決定するステップと、
   前記分散型ハッシュテーブルに格納されるエントリから、前記第2のユーザに関連する第2の公開鍵を決定するステップと、
   前記第2のユーザの公開鍵と前記第2の公開鍵とを比較するステップと、
   前記第2のユーザの公開鍵と前記第2の公開鍵との前記比較に基づき、前記コンピュータソフトウェアのオーナシップを検証するステップと、
   を含む、請求項１又は２記載の方法。
4. 前記第2のユーザの公開鍵と前記第2の公開鍵とを比較するステップは、前記第2のユーザの公開鍵と前記第2の公開鍵とが一致するか判断するステップを含む、請求項３記載の方法。
5. 前記第2のユーザの公開鍵を決定するステップの前に、当該方法は、
   前記コンピュータソフトウェアに関連するデータを決定するステップと、
   前記コンピュータソフトウェアの第1のハッシュ値を決定するステップと、
   前記データと前記コンピュータソフトウェアとに基づき第2のハッシュ値を決定するステップと、
   通信ネットワークを介し前記分散型ハッシュテーブルへの格納のためのエントリに前記データ、前記第1のハッシュ値及び前記第2のハッシュ値を送信するステップであって、前記第2のハッシュ値はキー・値ペアのキーであり、前記データと前記第1のハッシュ値とは前記キー・値ペアにおける値である、ステップと、
   前記ピア・ツー・ピア分散型台帳への格納のため前記第2のハッシュ値を含む前記メタデータを決定するステップと、
   を含む、請求項３又は４記載の方法。
6. 前記コンピュータソフトウェアは、ヘッダとボディとを含む、請求項１乃至５何れか一項記載の方法。
7. 前記第3のハッシュ値は、前記コンピュータソフトウェアの前記ボディから決定される、請求項６記載の方法。
8. 前記ヘッダは、前記コンピュータソフトウェアの前記ボディのハッシュ値を含む、請求項６又は７記載の方法。
9. 前記ヘッダは更に、前記第2のハッシュ値を含む、請求項５に従属する場合の請求項６乃至８何れか一項記載の方法。
10. 前記コンピュータソフトウェアの前記ボディは、前記コンピュータソフトウェアの実行可能ファイルを含む、請求項６乃至９何れか一項記載の方法。
11. 前記第2のユーザの公開鍵を決定するステップの前に、当該方法は、
    前記コンピュータソフトウェアの前記実行可能ファイルを暗号化するステップを含む、請求項３に従属する場合の請求項１０記載の方法。
12. 前記コンピュータソフトウェアの前記実行可能ファイルを暗号化するステップは、
    生成値を決定するステップと、
    前記第2のユーザの公開鍵と前記生成値とに基づき第2のユーザの第2の公開鍵を決定するステップであって、前記第2のユーザの第2の公開鍵は第2のユーザの第2の秘密鍵と暗号化ペアを構成する、ステップと、
    第1のユーザの公開鍵と前記生成値とに基づき第1のユーザの第2の公開鍵を決定するステップであって、前記第1のユーザの第2の公開鍵は第1のユーザの第2の秘密鍵と暗号化ペアを構成する、ステップと、
    前記第2のユーザの第2の公開鍵と前記第1のユーザの第2の秘密鍵とに基づき共通秘密を決定するステップと、
    前記コンピュータソフトウェアの暗号化された実行可能ファイルを生成するため、前記共通秘密によって前記コンピュータソフトウェアの前記実行可能ファイルを暗号化するステップと、
    を含む、請求項１１記載の方法。
13. 前記コンピュータソフトウェアの前記暗号化された実行可能ファイルは、
    前記第1のユーザの第2の公開鍵と前記第2のユーザの第2の秘密鍵とに基づき前記共通秘密を決定し、
    前記コンピュータソフトウェアの解読された実行可能ファイルを生成するため、前記共通秘密によって前記コンピュータソフトウェアの前記実行可能ファイルを解読する
    ことによって解読される、請求項１２記載の方法。
14. 前記第2のユーザに関連する処理デバイスに前記コンピュータソフトウェアの前記解読された実行可能ファイルをインストールするステップを更に含む、請求項１３記載の方法。
15. 前記第2のユーザからのアクティベーションキーを決定するステップと、
    前記アクティベーションキーに基づき前記コンピュータソフトウェアの前記解読された実行可能ファイルの命令を実行するステップと、
    を更に含む、請求項１４記載の方法。
16. 請求項１乃至１５何れか一項記載の方法を処理デバイスに実現させるマシーン可読命令を有するコンピュータソフトウェアプログラム。
17. 分散型ハッシュテーブル及びピア・ツー・ピア分散型台帳を利用してインストールのためのコンピュータソフトウェアのインテグリティを検証するコンピュータシステムであって、
    当該システムは、
    ノードのピア・ツー・ピアネットワーク上のノードに関連する処理デバイスであって、
    前記ピア・ツー・ピア分散型台帳に格納されるトランザクションレコードに関連するメタデータを決定し、
    前記メタデータから前記分散型ハッシュテーブル上のエントリの位置の指示を決定し、
    前記コンピュータソフトウェアに基づき第3のハッシュ値を決定し、
    前記分散型ハッシュテーブル上の前記エントリから第4のハッシュ値を決定し、
    前記第3のハッシュ値と前記第4のハッシュ値とを比較し、
    前記第3のハッシュ値と前記第4のハッシュ値との前記比較に基づき、前記コンピュータソフトウェアの前記インテグリティを検証する
    よう構成される処理デバイス
    を有するコンピュータシステム。

Images