(57)【要約】  分散型ハッシュテーブル(13)及びピア・ツー・ピア分散型台帳(14)を利用してインストール後であって実行前にコンピュータソフトウェアのオーナシップを検証するコンピュータにより実現される方法（600）及びシステム(1)。これは、ビットコインブロックチェーン又は他の実現形態であってもよい。当該方法は、ピア・ツー・ピア分散型台帳(14)に格納されるトランザクションレコードから第2のユーザ(24)に関連する第2のユーザの公開鍵を決定すること（610）を含む。第2のユーザに関連する第2の公開鍵が、分散型ハッシュテーブル(13)上のエントリから決定されてもよい（620）。当該方法は更に、第2のユーザの公開鍵と第2の公開鍵とを比較し（630）、第2のユーザの公開鍵と第2の公開鍵との比較に基づきコンピュータソフトウェアのオーナシップを検証すること（640）を含む。
2019514087.tif 000002
【特許請求の範囲】
【請求項１】
分散型ハッシュテーブル及びピア・ツー・ピア分散型台帳を利用してコンピュータソフトウェアのインストール後であって実行前に前記コンピュータソフトウェアのオーナシップを検証するコンピュータにより実現される方法であって、
前記ピア・ツー・ピア分散型台帳に格納されるトランザクションレコードから、第2のユーザに関連する第2のユーザの公開鍵を決定するステップと、
前記分散型ハッシュテーブルに格納されるエントリから、前記第2のユーザに関連する第2の公開鍵を決定するステップと、
前記第2のユーザの公開鍵と前記第2の公開鍵とを比較するステップと、
前記第2のユーザの公開鍵と前記第2の公開鍵との比較に基づき、前記コンピュータソフトウェアのオーナシップを検証するステップと、
を有する方法。
【請求項２】
前記第2のユーザの公開鍵と前記第2の公開鍵とを比較するステップは、前記第2のユーザの公開鍵と前記第2の公開鍵とが一致するか判断するステップを含む、請求項１記載の方法。
【請求項３】
前記コンピュータソフトウェアは、ヘッダとボディとを含む、請求項１又は２記載の方法。
【請求項４】
前記ヘッダは、前記コンピュータソフトウェアのボディのハッシュ値を含む、請求項３記載の方法。
【請求項５】
前記ヘッダは更に、前記コンピュータソフトウェア又はライセンスに関連するデータのハッシュ値を含む、請求項３又は４記載の方法。
【請求項６】
前記コンピュータソフトウェアのボディは、前記コンピュータソフトウェアの実行可能ファイルを含む、請求項３乃至５何れか一項記載の方法。
【請求項７】
前記第2のユーザの公開鍵を決定するステップの前に、当該方法は、
前記第2のユーザに関連する処理デバイスに前記コンピュータソフトウェアの実行可能ファイルをインストールするステップを含む、請求項５記載の方法。
【請求項８】
前記コンピュータソフトウェアの実行可能ファイルをインストールするステップの前に、当該方法は、
前記コンピュータソフトウェアの実行可能ファイルを暗号化するステップを含む、請求項７記載の方法。
【請求項９】
前記コンピュータソフトウェアの実行可能ファイルを暗号化するステップは、
生成値を決定するステップと、
前記第2のユーザの公開鍵と前記生成値とに基づき第2のユーザの第2の公開鍵を決定するステップであって、前記第2のユーザの第2の公開鍵は第2のユーザの第2の秘密鍵と暗号化ペアを構成する、決定するステップと、
第1のユーザの公開鍵と前記生成値とに基づき第1のユーザの第2の公開鍵を決定するステップであって、前記第1のユーザの第2の公開鍵は第1のユーザの第2の秘密鍵と暗号化ペアを構成する、決定するステップと、
前記第2のユーザの第2の公開鍵と前記第1のユーザの第2の秘密鍵とに基づき共通秘密を決定するステップと、
前記コンピュータソフトウェアの暗号化された実行可能ファイルを生成するため、前記共通秘密によって前記コンピュータソフトウェアの実行可能ファイルを暗号化するステップと、
を含む、請求項８記載の方法。
【請求項１０】
前記コンピュータソフトウェアの暗号化された実行可能ファイルは、
前記第1のユーザの第2の公開鍵と前記第2のユーザの第2の秘密鍵とに基づき前記共通秘密を決定し、
前記コンピュータソフトウェアの解読された実行可能ファイルを生成するため、前記共通秘密によって前記コンピュータソフトウェアの実行可能ファイルを解読することによって、前記コンピュータソフトウェアの実行可能ファイルのインストール前に解読される、請求項９記載の方法。
【請求項１１】
前記コンピュータソフトウェアのオーナシップを検証した後、前記第2のユーザに関連する前記処理デバイスに前記コンピュータソフトウェアの解読された実行可能ファイルの命令を実行するステップを更に含む、請求項１０記載の方法。
【請求項１２】
前記命令を実行するステップの前に、当該方法は更に、
前記第2のユーザからのアクティベーションキーを決定するステップと、
前記第2のユーザに関連する前記処理デバイス上で前記アクティベーションキーに基づき前記コンピュータソフトウェアの解読された実行可能ファイルの命令を実行するステップと、
を更に含む、請求項１１記載の方法。
【請求項１３】
前記コンピュータソフトウェアの実行可能ファイルを暗号化するステップの前に、当該方法は更に、
前記コンピュータソフトウェアに関連するデータを決定するステップと、
前記コンピュータソフトウェアの第1のハッシュ値を決定するステップと、
前記データと前記コンピュータソフトウェアとに基づき第2のハッシュ値を決定するステップと、
通信ネットワークを介し前記分散型ハッシュテーブルに格納するためのエントリに前記データ、前記第1のハッシュ値及び前記第2のハッシュ値を送信するステップであって、前記第2のハッシュ値はキー・値ペアのキーであり、前記データと前記第1のハッシュ値とは前記キー・値ペアの値である、送信するステップと、
前記ピア・ツー・ピア分散型台帳への格納のため前記第2のハッシュ値を含むメタデータを決定するステップと、
を含む、請求項８乃至１２何れか一項記載の方法。
【請求項１４】
請求項１乃至１３何れか一項記載の方法を処理デバイスに実現させるマシーン可読命令を有するコンピュータソフトウェアプログラム。
【請求項１５】
分散型ハッシュテーブル及びピア・ツー・ピア分散型台帳を利用してインストール後であって実行前にコンピュータソフトウェアのオーナシップを検証するコンピュータシステムであって、
当該システムは、ノードのピア・ツー・ピアネットワーク上のノードに関連し、
前記ピア・ツー・ピア分散型台帳に格納されるトランザクションレコードから、第2のユーザに関連する第2のユーザの公開鍵を決定し、
前記分散型ハッシュテーブルに格納されるエントリから、前記第2のユーザに関連する第2の公開鍵を決定し、
前記第2のユーザの公開鍵と前記第2の公開鍵とを比較し、
前記第2のユーザの公開鍵と前記第2の公開鍵との比較に基づき、前記コンピュータソフトウェアのオーナシップを検証するよう構成される処理デバイスを有するコンピュータシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、デジタルアセットの認可された制御を保証するためのセキュリティ、制御及び検証方法に関する。本発明は、特にコンピュータソフトウェアのアイテムのオーナシップ又は認可された利用／制御を検証することに適している。これは、分散型ハッシュテーブル及びピア・ツー・ピア分散型台帳（ブロックチェーン）を利用することを含みうる。
【背景技術】
【０００２】
本文書では、“ブロックチェーン”という用語を用いて、全ての形式の電子的でコンピュータベースの分散型台帳を含む。これらは、コンセンサスベースブロックチェーン及びトランザクションチェーン技術、Permissioned型及びUn-permissioned型台帳、Shared型台帳及びこれらの変形を含む。他のブロックチェーン実現形態が提案及び開発されてきたが、ブロックチェーン技術の最も広く知られた適用はビットコイン台帳である。ここでは利便性及び図示のためビットコインが参照されうるが、本発明はビットコインブロックチェーンによる利用に限定されず、他のブロックチェーンの実現形態及びプロトコルが本発明の範囲内に属することが留意されるべきである。“ユーザ”という用語は、ここでは人間又はプロセッサベースのリソースを参照しうる。
【０００３】
ブロックチェーンは、トランザクションから構成されるブロックから構成されるコンピュータベースの非中央集権型の分散システムとして実現されるピア・ツー・ピアの電子台帳である。各トランザクションは、ブロックチェーンシステムにおける参加者の間のデジタルアセットの制御の移転を符号化するデータ構造であり、少なくとも1つの入力と少なくとも1つの出力とを含む。各ブロックは、前のブロックのハッシュを含み、ブロックは、それの最初からブロックチェーンに書き込まれた全てのトランザクションの永続的で変更不可なレコードを作成するため一緒にチェーン化される。トランザクションは、トランザクションの出力がどのようにして誰によってアクセス可能であるかを指定するその入力及び出力に埋め込まれたスクリプトとして知られる小さなプログラムを含む。ビットコインプラットフォームでは、これらのスクリプトはスタックベースのスクリプト言語を用いて記述される。
【０００４】
トランザクションがブロックチェーンに書き込みされるため、それは“有効化（validate）”される必要がある。ネットワークノード（マイナー（miner））は、無効なトランザクションがネットワークから拒絶されることによって、各トランザクションが有効であることを保証するための作業を実行する。ノード上にインストールされたソフトウェアクライアントは、それのロッキング及びアンロッキングスクリプトを実行することによって、未使用トランザクション（UTXO）に対してこの有効化作業を実行する。ロッキング及びアンロッキングスクリプトの実行がTRUEに評価した場合、トランザクションは有効であり、当該トランザクションがブロックチェーンに書き込まれる。従って、トランザクションがブロックチェーンに書き込まれるためには、それは、i)トランザクションを受信した第1のノードによって有効化され、トランザクションが有効化された場合、ノードがネットワークにおけるその他のノードにそれを中継し、ii)マイナーによって構築された新たなブロックに追加され、iii)マイニング、すなわち、過去のトランザクションのパブリック台帳に追加される必要がある。
【０００５】
ブロックチェーン技術は仮想通貨（cryptocurrency）の実現形態の利用について最も広く知られているが、デジタル企業家は、ビットコインの基礎となる暗号化セキュリティシステムとブロックチェーン上に格納可能なデータとの双方を利用して、新たなシステムを実現することを模索し始めている。ブロックチェーンが仮想通貨の領域に限定されない自動化されたタスク及びプロセスについて利用可能である場合、それは大いに有利であろう。このような解決策は、それらの適用においてより多才でありながら、ブロックチェーンの利点（例えば、永続的で改ざん耐性なイベントの記録、分散処理など）を利用することが可能である。
【０００６】
現在の研究の1つの領域は、“スマートコントラクト（smart  contract）”の実現のためのブロックチェーンの利用である。これらは、マシーン可読な契約又は合意の項目の実行を自動化するよう設計されたコンピュータプログラムである。自然言語により記述される従来の契約と異なって、スマートコントラクトは、結果を生成するために入力を処理可能なルールを含み、その後にこれらの結果に応じてアクションを実行可能なマシーン実行可能なプログラムである。
【０００７】
ブロックチェーン関連の興味の他の領域は、ブロックチェーンを介し現実世界のエンティティを表現及び移転するための“トークン”（又は“カラードコイン（colored  coin）”）の利用である。潜在的に機密又は秘密のアイテムは、認識可能な意味又は値を有さないトークンによって表現できる。従って、トークンは、現実世界のアイテムがブロックチェーンから参照されることを可能にする識別子として機能する。
【０００８】
それらが提供する改ざん耐性な記録のため、ブロックチェーンは、イベントの制御及び可視性及びセキュアなトランザクション／交換が重要であるアプリケーションに良く適している。そのような１つの適した適用領域は、例えば、ソフトウェアなどのデジタルアセットの交換又は移転である。コンピュータソフトウェアのインテグリティ及び共有をセキュアにする従来のアプローチは、コンピュータソフトウェアの実行可能ファイルのデジタル署名に関する。例えば、公開鍵及び秘密鍵などの暗号化キーペアによって実行可能ファイル又は他の関連するコードを署名する。公開鍵は、しばしば認証機関などの信頼された中央機関から取得される。
【０００９】
コンピュータソフトウェアは、しばしば契約上の義務を含むライセンスを伴う。ライセンスは、ソフトウェアの使用又は再配布を管理する条項を含みうる。しかしながら、コンピュータソフトウェア又は関連するライセンスが認可されていない又は所望されない方法で他のユーザに移転される場合、問題が発生しうる。
【００１０】
ソフトウェアのオーナシップ、許諾及び正当な制御を検証することが必要である。これは、例えば、ソフトウェアが誤ったオーナ又は許諾に反して移転されていなことを保証するためである。従って、ソフトウェアなどの制御されたデジタルアセット又はリソースの移転及び／又はオーナシップの検証を実現又は可能にする解決策を提供することが望ましい。これは、次にソフトウェア及び電子移転処理のインテグリティを保証するのに役立ちうる。
【００１１】
本明細書に含まれる文書、行為、物質、装置、物などの何れかの議論は、これらの題材の何れか又は全てが、本出願の各請求項の優先日前に存在していたかのように、先行技術の基礎の一部を構成するか、あるいは、本開示に関連する分野における共通する一般的な知識であるという自認としてとられるべきでない。
【００１２】
本明細書を通じて、“有する”という単語又はその派生語は、述べられた要素、整数若しくはステップ又は要素、整数若しくはステップの群の包含を意味し、他の何れかの要素、整数若しくはステップ又は要素、整数若しくはステップの群の排除を意味しないと理解されるであろう。
【発明の概要】
【００１３】
本発明は、添付した請求項において規定されるような方法及び対応するシステムを提供する。本発明は、コンピュータにより実現される制御及び検証方法／システムを提供しうる。それは、コンピュータベースネットワーク上のユーザ間の被制御アセットの移転を可能又は実現しうる。アセットはデジタルアセットであってもよい。ここで、“ユーザ”という用語はコンピュータベースリソースを参照するのに利用されうる。被制御アセットは、ソフトウェアの一部又はアイテムであってもよい。本発明は、コンピュータソフトウェアの一部など、被制御アセットを検証するコンピュータにより実現される方法を提供しうる。それは、ソフトウェアのオーナシップ又は認可を検証する方法であってもよい。ソフトウェアは、コンピュータベースリソースへのインストールについて検証されうる。
【００１４】
本方法は、分散型ハッシュテーブル及びピア・ツー・ピア分散型台帳（ブロックチェーン）を利用して、インストール後であって実行前にコンピュータソフトウェアのアイテムのオーナシップ又は認可された利用／制御を検証するコンピュータにより実現される方法を含みうる。当該方法は、ピア・ツー・ピア分散型台帳に格納されるトランザクションレコードから、第2のユーザ（U2）に関連する第2のユーザの公開鍵（PU2）を決定し、分散型ハッシュテーブルに格納されるエントリから、第2のユーザ（U2）に関連する第2の公開鍵（P2）を決定し、第2のユーザの公開鍵（PU2）と第2の公開鍵（P2）とを比較し、第2のユーザの公開鍵（PU2）と第2の公開鍵（P2）との比較に基づき、コンピュータソフトウェアのオーナシップを検証することを含んでもよい。
【００１５】
第2のユーザの公開鍵(PU2)と第2の公開鍵（P2）とがそれぞれ別々の技術的ソース、すなわち、ブロックチェーン及びDHTに格納され、抽出されうることに留意すべきである。従って、本発明は、それらの間のデータの相互通信及び移転によって異なる別々の格納リソースの利用を含みうる。DHT及びブロックチェーンからデータを検索、処理及び抽出することによって、本発明は、デジタルアセット（例えば、ソフトウェア）のインストール、移転及び認可に対するよりセキュアなアプローチを生じさせるエンハンスされた制御、セキュリティ及び検証の効果を実現可能である。
【００１６】
当該方法では、第2のユーザの公開鍵（PU2）と第2の公開鍵（P2）との比較は、第2のユーザの公開鍵（PU2）と第2の公開鍵（P2）とが一致するか判断することを含んでもよい。“一致”という用語は、第2のユーザの公開鍵（PU2）と第2の公開鍵（P2）との間の対応、同等又は関連を含みうる。
【００１７】
当該方法では、コンピュータソフトウェアは、ヘッダとボディとを含んでもよい。ヘッダは、コンピュータソフトウェアのボディのハッシュ値を含んでもよい。ヘッダは更に、コンピュータソフトウェア又はライセンスに関連するデータのハッシュ値（H2）を含んでもよい。コンピュータソフトウェアのボディは、コンピュータソフトウェアの実行可能ファイルを含んでもよい。
【００１８】
当該方法では、第2のユーザの公開鍵（PU2）を決定する前に、当該方法は、第2のユーザ(U2)に関連する処理デバイスにコンピュータソフトウェアの実行可能ファイルをインストールすることを含んでもよい。当該方法では、コンピュータソフトウェアの実行可能ファイルをインストールする前に、当該方法は、コンピュータソフトウェアの実行可能ファイルを暗号化することを含んでもよい。
【００１９】
コンピュータソフトウェアの実行可能ファイルを暗号化することは、生成値（GV）を決定し、第2のユーザの公開鍵（PU2）と生成値（GV）とに基づき第2のユーザの第2の公開鍵（P2U2）を決定し、第2のユーザの第2の公開鍵（P2U2）は第2のユーザの第2の秘密鍵（V2U2）と暗号化ペアを構成し、第1のユーザの公開鍵（PU1）と生成値（GV）とに基づき第1のユーザの第2の公開鍵（P2U1）を決定し、第1のユーザの第2の公開鍵（P2U1）は第1のユーザの第2の秘密鍵（V2U1）と暗号化ペアを構成し、第2のユーザの第2の公開鍵（P2U2）と第1のユーザの第2の秘密鍵（V2U1）とに基づき共通秘密（CS）を決定し、コンピュータソフトウェアの暗号化された実行可能ファイルを生成するため、共通秘密（CS）によってコンピュータソフトウェアを暗号化することを含んでもよい。
【００２０】
当該方法では、コンピュータソフトウェアの暗号化された実行可能ファイルは、第1のユーザの第2の公開鍵（P2U1）と第2のユーザの第2の秘密鍵（V2U2）とに基づき共通秘密（CS）を決定し、コンピュータソフトウェアの解読された実行可能ファイルを生成するため、共通秘密（CS）によってコンピュータソフトウェアの実行可能ファイルを解読することによって解読されてもよい。
【００２１】
当該方法は更に、第2のユーザ（U2）に関連する処理デバイスにコンピュータソフトウェアの解読された実行可能ファイルの命令を実行することを更に含んでもよい。
【００２２】
当該方法は更に、第2のユーザ（U2）からのアクティベーションキー（AK）を決定し、第2のユーザ（U2）に関連する処理デバイス上でアクティベーションキー（AK）に基づきコンピュータソフトウェアの解読された実行可能ファイルの命令を実行することを含んでもよい。
【００２３】
当該方法では、コンピュータソフトウェアの実行可能ファイルを暗号化する前に、当該方法は、コンピュータソフトウェアに関連するデータ(D1)を決定し、コンピュータソフトウェアの第1のハッシュ値(H1)を決定し、データ（D1）とコンピュータソフトウェアとに基づき第2のハッシュ値（H2）を決定し、通信ネットワークを介し分散型ハッシュテーブルへの格納のためのエントリにデータ（D1）、第1のハッシュ値及び第2のハッシュ値（H2）を送信し、第2のハッシュ値（H2）はキー・値ペアのキーであり、データ（D1）と第1のハッシュ値（H1）とはキー・値ペアにおける値であり、ピア・ツー・ピア分散型台帳に格納するため第2のハッシュ値（H2）を含むメタデータ（M）を決定することを含んでもよい。
【００２４】
上述した方法を処理デバイスに実現させるマシーン可読命令を有するコンピュータソフトウェアプログラム。
【００２５】
分散型ハッシュテーブル及びピア・ツー・ピア分散型台帳を利用してインストールの後であって実行前にコンピュータソフトウェアのオーナシップを検証するコンピュータシステムであって、当該システムは、ノードのピア・ツー・ピアネットワーク上のノードに関連し、ピア・ツー・ピア分散型台帳に格納されるトランザクションレコードから第2のユーザ（U2）に関連する第2のユーザの公開鍵（PU2）を決定し、分散型ハッシュテーブルに格納されるエントリから第2のユーザ（U2）に関連する第2の公開鍵（P2）を決定し、第2のユーザの公開鍵（PU2）と第2の公開鍵（P2）とを比較し、第2のユーザの公開鍵（PU2）と第2の公開鍵（P2）との比較に基づき、コンピュータソフトウェアのオーナシップを検証するよう構成される処理デバイスを有するコンピュータシステム。
【図面の簡単な説明】
【００２６】
【図１】ハッシュテーブルの具体例を示す。
【図２】分散型ハッシュテーブルを利用したインストール後であって実行前にコンピュータソフトウェアのコンピュータソフトウェアをセキュアにするメタデータ（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スクリプトは、
【００４３】
【数１】
2019514087.tif 000003
の形態をとりうる。
【００４４】
ここで、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を介し分散型ハッシュテーブル13上のエントリにデータ(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はまた、分散型ハッシュテーブル13上に格納されるエントリから第2のユーザ（U2）に関連する第2の公開鍵（P2）を決定すること（620）を含む。第2の公開鍵（P2）は、第2のユーザの公開鍵（PU2）と同じであってもよい。分散型ハッシュテーブル13上のエントリはキー・値ペアを含んでもよい。
【００６１】
方法600は更に、第2のユーザの公開鍵（PU2）と第2の公開鍵（P2）とを比較すること（630）を含む。方法600はまた、第2のユーザの公開鍵（PU2）と第2の公開鍵（P2）との比較に基づき、コンピュータソフトウェアのオーナシップを検証すること（640）を含む。一例では、オーナシップの検証は、第2のユーザの公開鍵（PU2）と第2の公開鍵（P2）とが一致していることを示すものであってもよい。
【００６２】
方法100,  600の詳細な具体例が説明される。
【００６３】
コンピュータソフトウェア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が利用されてもよい。
【００９４】
【数２】
2019514087.tif 000004
第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）は、
【０１０１】
【数３】
2019514087.tif 000005
の形態をとってもよく、ここで、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）は、
【０１０９】
【数４】
2019514087.tif 000006
の形態を有してもよく、ここで、OP_1はトランザクションをアンロックするため第1のredeemスクリプト（RS1）を充足するよう必要とされるシグネチャの数(“NumSigs”)を示し、OP_3はredeemスクリプトにおける公開鍵の数(“NumKeys”)を示す。
【０１１０】
本例では、第1のredeemスクリプト（RS1）は、メタデータの2つの指定されたフィールドMetadata1及びMetadata2を含んでもよい。Metadata1及びMetadata2の具体例が以下のテーブル1に示される。
【０１１１】
【表１】
2019514087.tif 000007
本例は、ライセンスのサイズがメタデータ（M）にそのような詳細を含めることを妨げる場合に有用となりうるMetadata1におけるライセンスへのポインタを提供することを含む。さらに、メタデータ（M）が公開されるか、あるいは、非セキュアネットワークを介し送信されうるため、トークンの具体的詳細はプライバシの理由のため隠される又は隠蔽されることが望ましいかもしれない。
【０１１２】
Metadata1の最初の4バイトはライセンスのタイプを示す。例えば、ライセンスタイプは、BobSoftwareなどのコンピュータソフトウェアの名前を示すものであってもよい。更なる例では、ライセンスタイプは、上述したような“シングルユーザ”又は“マルチデバイス”などのライセンスの認可タイプを示すものであってもよい。次の16バイトは、IPv6アドレスを考慮して、実際の電子ライセンスファイルの位置のIPアドレスを保持する。いくつかの実施例では、この値は、ライセンスファイルが中央化されるのでなくクラウド上に分散可能となるように、トレントファイルのシードをポインティングしうる。次の12バイトは、ライセンスのタイプに固有のデータを含む。
【０１１３】
Metadata2の最初の20バイトは、ライセンスファイルの実際のコンテンツに適用されるSHA256に対してRIPEMD-160を利用した実際のライセンスファイルのハッシュである。実際のライセンスファイルは抽出可能であってもよいため、これは、契約に対するトランザクションの有効性を認める。ライセンスファイル自体は、具体的な実施例の要求に依存して、完全に公開（未暗号化及び人間に読める）であってもよいし、あるいは、プライバシのため暗号化されてもよい。Metadata2の残りの12バイトのコンテンツは、ライセンスのタイプに依存して利用されてもよい。
【０１１４】
上記で提供された第1のredeemスクリプト（RS1）の具体例から、発行トークンは使用されるためエージェント（A）によって署名される必要があることが理解できる。テーブル2において発行トークンのトランザクションの具体例が提供され、簡単化のため、マイナーの費用は示されていない。
【０１１５】
【表２】
2019514087.tif 000008
テーブル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）は、
【０１１９】
【数５】
2019514087.tif 000009
の形式であってもよく、ここで、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）は、
【０１２４】
【数６】
2019514087.tif 000010
の形式をとってもよい。
【０１２５】
本例では、第2のredeemスクリプト（RS2）は、第1のredeemスクリプト（RS1）と同一の2つのメタデータフィールドを含む。第2のredeemスクリプト（RS2）は更に、エージェントに関連するエージェント公開鍵（PA）と、第1のユーザに関連する第1のユーザの公開鍵（PU1）とを含む。
【０１２６】
上記で提供された第2のredeemスクリプト（RS2）の具体例から、移転されるトークンは使用されるためにエージェント（A）又は第1のユーザ23によって署名される必要があることが理解できる。この発行トークンの移転のためのトランザクションの具体例が、再び簡単化のためにマイナーの費用は示されていないテーブル3において提供される。
【０１２７】
【表３】
2019514087.tif 000011
テーブル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）が可能である。
【０１３６】
インストール後のコンピュータソフトウェアのオーナシップの検証（600）
上述したように、方法600は、コンピュータソフトウェアのインストール後にコンピュータソフトウェアのオーナシップを検証する。一例では、第2のユーザ24などのコンピュータのユーザは、コンピュータソフトウェア及びライセンスに関連するトークンを償還してもよい。更なる例では、トークンは、上述した第2のredeemスクリプトを利用して第2のユーザ24によって受信されてもよい。
【０１３７】
第2のユーザ24は、上述した方法500を利用することによって、DHT13上のエントリからコンピュータソフトウェアの位置を示す識別子を決定してもよい。このようにして、第2のユーザ24は、コンピュータソフトウェアの位置を決定し、それを抽出することができる。一例では、コンピュータソフトウェアはインターネット上のURLに格納されうる。他の例では、コンピュータソフトウェアは、コンピュータベースリソース上に提供されるサーバ、データベース又はストレージ施設などのコンピュータベースレポジトリに格納されてもよい。
【０１３８】
第2のユーザ24がコンピュータソフトウェアを抽出した後、コンピュータソフトウェアは、第2のユーザ24に関連する処理デバイス27上にインストールされてもよい。一例では、コンピュータソフトウェアの実行可能ファイルはまたコンピュータソフトウェアのインストーラである。他の例では、コンピュータソフトウェアのインストーラはブートローダであってもよい。
【０１３９】
コンピュータソフトウェアが処理デバイス17上にインストールされた後、コンピュータソフトウェアのオーナシップが検証されてもよい。オーナシップの検証は、トランザクションが上記のテーブル2又はテーブル3に記載されるように決定されうるトランザクションレコードと、DHT13上のエントリのvalue値に格納される情報とを利用してもよい。
【０１４０】
第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及び3に記載されるようなトランザクションに関連するものであってもよい。
【０１４２】
更なる他の例では、第2のノード7は、第2のノード7又は第2のノード7に関連するデータストアにおいてトランザクションレコードにアクセスしてもよい。更なる例では、トランザクションレコードは、www.blockchain.infoなどの公衆に利用可能な施設を利用して第2のノード7によってアクセスされてもよい。
【０１４３】
P2P分散型台帳14上に格納されるトランザクションレコードは、トランザクション又はトランザクションに関連するユーザを特定する情報を含んでもよい。テーブル4において、トランザクションレコードに含まれる情報の具体例が示される。
【０１４４】
【表４】
2019514087.tif 000012
各トランザクションアウトプットは、移転される仮想通貨の数量に関する情報と、仮想通貨を使用するのに充足される必要がある条件を定義したアウトプットスクリプトとを含む。アウトプットスクリプトは、典型的には、仮想通貨の受信者に関連する公開鍵を含む。
【０１４５】
一例では、アウトプットスクリプトにおける仮想通貨の受信者に関連する公開鍵は、第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）を含んでもよい。
【０１５９】
コンピュータソフトウェアのボディは、コンピュータソフトウェアの実行可能ファイルを含んでもよい。
【０１６０】
コンピュータソフトウェアのインストール
コンピュータソフトウェアの実行可能ファイルは、第2のユーザ24に関連する第2の処理デバイス27にコンピュータソフトウェアをインストールさせる命令を含んでもよい。一例では、コンピュータソフトウェアは、第2のユーザの公開鍵（PU2）を決定する(160)前に、第2の処理デバイスにインストールされる。
【０１６１】
コンピュータソフトウェアの実行可能ファイルの暗号化
上述した方法600では、コンピュータソフトウェアの実行可能ファイルをインストールする前に、方法600はコンピュータソフトウェアの実行可能ファイルを暗号化することを含んでもよい。コンピュータソフトウェアの実行可能ファイルは、上述した方法100の後に暗号化されてもよい。
【０１６２】
一例では、コンピュータソフトウェアの実行可能ファイルが、第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）は、楕円曲線の点(xs,  ys)の形式であってもよい。これは、ノード3,7によって合意された標準的な処理を利用して標準的な鍵形式に変換されてもよい。例えば、xsの値は、AES256（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）。
［処理デバイス］
上述したように、第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を有してもよい。
【０１７７】
本開示はユーザ、雇用者、被雇用者、発行者、商人、プロバイダ又は他のエンティティが特定のアクション（署名、発行、決定、計算、送信、受信、生成などを含む）を実行すると説明する場合、当該単語は掲示の簡単化のために利用される。これらのアクションはこれらのエンティティによって運営される計算デバイスによって実行されることが理解されるべきである。
【０１７８】
多数の変形及び／又は修正が、本開示の広範な一般的範囲から逸脱することなく、上述した実施例に対してなされうることが、当業者によって理解されるであろう。従って、本実施例は、限定的でなく、例示的なものとして全ての点でみなされるべきである。
【図１】
2019514087.tif 000013
【図２】
2019514087.tif 000014
【図３】
2019514087.tif 000015
【図４】
2019514087.tif 000016
【図５】
2019514087.tif 000017
【図６】
2019514087.tif 000018
【図７】
2019514087.tif 000019
【図８】
2019514087.tif 000020
【図９】
2019514087.tif 000021
【図１０】
2019514087.tif 000022
【手続補正書】
【提出日】平成30年10月3日(2018.10.3)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
分散型ハッシュテーブル及びピア・ツー・ピア分散型台帳を利用してコンピュータソフトウェアのインストール後であって実行前に前記コンピュータソフトウェアのオーナシップを検証するコンピュータにより実現される方法であって、
前記ピア・ツー・ピア分散型台帳に格納されるトランザクションレコードから、第2のユーザに関連する第2のユーザの公開鍵を決定するステップと、
前記分散型ハッシュテーブルに格納されるエントリから、前記第2のユーザに関連する第2の公開鍵を決定するステップと、
前記第2のユーザの公開鍵と前記第2の公開鍵とを比較するステップと、
前記第2のユーザの公開鍵と前記第2の公開鍵との比較に基づき、前記コンピュータソフトウェアのオーナシップを検証するステップと、
を有する方法。
【請求項２】
前記第2のユーザの公開鍵と前記第2の公開鍵とを比較するステップは、前記第2のユーザの公開鍵と前記第2の公開鍵とが一致するか判断するステップを含む、請求項１記載の方法。
【請求項３】
前記コンピュータソフトウェアは、ヘッダとボディとを含む、請求項１又は２記載の方法。
【請求項４】
前記ヘッダは、前記コンピュータソフトウェアのボディのハッシュ値を含む、請求項３記載の方法。
【請求項５】
前記ヘッダは更に、前記コンピュータソフトウェア又はライセンスに関連するデータのハッシュ値を含む、請求項３又は４記載の方法。
【請求項６】
前記コンピュータソフトウェアのボディは、前記コンピュータソフトウェアの実行可能ファイルを含む、請求項３乃至５何れか一項記載の方法。
【請求項７】
前記第2のユーザの公開鍵を決定するステップの前に、当該方法は、
前記第2のユーザに関連する処理デバイスに前記コンピュータソフトウェアの実行可能ファイルをインストールするステップを含む、請求項５記載の方法。
【請求項８】
前記コンピュータソフトウェアの実行可能ファイルをインストールするステップの前に、当該方法は、
前記コンピュータソフトウェアの実行可能ファイルを暗号化するステップを含む、請求項７記載の方法。
【請求項９】
前記コンピュータソフトウェアの実行可能ファイルを暗号化するステップは、
生成値を決定するステップと、
前記第2のユーザの公開鍵と前記生成値とに基づき第2のユーザの第2の公開鍵を決定するステップであって、前記第2のユーザの第2の公開鍵は第2のユーザの第2の秘密鍵と暗号化ペアを構成する、決定するステップと、
第1のユーザの公開鍵と前記生成値とに基づき第1のユーザの第2の公開鍵を決定するステップであって、前記第1のユーザの第2の公開鍵は第1のユーザの第2の秘密鍵と暗号化ペアを構成する、決定するステップと、
前記第2のユーザの第2の公開鍵と前記第1のユーザの第2の秘密鍵とに基づき共通秘密を決定するステップと、
前記コンピュータソフトウェアの暗号化された実行可能ファイルを生成するため、前記共通秘密によって前記コンピュータソフトウェアの実行可能ファイルを暗号化するステップと、
を含む、請求項８記載の方法。
【請求項１０】
前記コンピュータソフトウェアの暗号化された実行可能ファイルは、
前記第1のユーザの第2の公開鍵と前記第2のユーザの第2の秘密鍵とに基づき前記共通秘密を決定し、
前記コンピュータソフトウェアの解読された実行可能ファイルを生成するため、前記共通秘密によって前記コンピュータソフトウェアの実行可能ファイルを解読する、
ことによって、前記コンピュータソフトウェアの実行可能ファイルのインストール前に解読される、請求項９記載の方法。
【請求項１１】
前記コンピュータソフトウェアのオーナシップを検証した後、前記第2のユーザに関連する前記処理デバイスで前記コンピュータソフトウェアの解読された実行可能ファイルの命令を実行するステップを更に含む、請求項１０記載の方法。
【請求項１２】
前記命令を実行するステップの前に、当該方法は更に、
前記第2のユーザからのアクティベーションキーを決定するステップと、
前記第2のユーザに関連する前記処理デバイス上で前記アクティベーションキーに基づき前記コンピュータソフトウェアの解読された実行可能ファイルの命令を実行するステップと、
を更に含む、請求項１１記載の方法。
【請求項１３】
前記コンピュータソフトウェアの実行可能ファイルを暗号化するステップの前に、当該方法は更に、
前記コンピュータソフトウェアに関連するデータを決定するステップと、
前記コンピュータソフトウェアの第1のハッシュ値を決定するステップと、
前記データと前記コンピュータソフトウェアとに基づき第2のハッシュ値を決定するステップと、
通信ネットワークを介し前記分散型ハッシュテーブルに格納するためのエントリに前記データ、前記第1のハッシュ値及び前記第2のハッシュ値を送信するステップであって、前記第2のハッシュ値はキー・値ペアのキーであり、前記データと前記第1のハッシュ値とは前記キー・値ペアの値である、送信するステップと、
前記ピア・ツー・ピア分散型台帳への格納のため前記第2のハッシュ値を含むメタデータを決定するステップと、
を含む、請求項８乃至１２何れか一項記載の方法。
【請求項１４】
請求項１乃至１３何れか一項記載の方法を処理デバイスに実現させるマシーン可読命令を有するコンピュータソフトウェアプログラム。
【請求項１５】
分散型ハッシュテーブル及びピア・ツー・ピア分散型台帳を利用してインストール後であって実行前にコンピュータソフトウェアのオーナシップを検証するコンピュータシステムであって、
当該システムは、
ノードのピア・ツー・ピアネットワーク上のノードに関連し、
前記ピア・ツー・ピア分散型台帳に格納されるトランザクションレコードから、第2のユーザに関連する第2のユーザの公開鍵を決定し、
前記分散型ハッシュテーブルに格納されるエントリから、前記第2のユーザに関連する第2の公開鍵を決定し、
前記第2のユーザの公開鍵と前記第2の公開鍵とを比較し、
前記第2のユーザの公開鍵と前記第2の公開鍵との比較に基づき、前記コンピュータソフトウェアのオーナシップを検証する、
よう構成される処理デバイスを有するコンピュータシステム。
【国際調査報告】
2019514087.tif 000023
2019514087.tif 000024
2019514087.tif 000025