特許 6877448 分散ハッシュテーブル及びブロックチェーンを用いてコンピュータソフトウェアを保証する方法及びシステム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6877448

(24)【登録日】2021年4月30日

(45)【発行日】2021年5月26日

(54)【発明の名称】分散ハッシュテーブル及びブロックチェーンを用いてコンピュータソフトウェアを保証する方法及びシステム

(51)【国際特許分類】

   H04L 9/32 20060101AFI20210517BHJP

   G06F 21/64 20130101ALI20210517BHJP

   G06Q 20/38 20120101ALI20210517BHJP

【ＦＩ】

   H04L9/00 675Z

   G06F21/64

   G06Q20/38 310

【請求項の数】16

【全頁数】24

(21)【出願番号】特願2018-539335(P2018-539335)

(86)(22)【出願日】2017年2月14日

(65)【公表番号】特表2019-511854(P2019-511854A)

(43)【公表日】2019年4月25日

(86)【国際出願番号】IB2017050827

(87)【国際公開番号】WO2017145009

(87)【国際公開日】20170831

【審査請求日】2020年1月15日

(31)【優先権主張番号】1603125.4

(32)【優先日】2016年2月23日

(33)【優先権主張国】GB

(31)【優先権主張番号】1607058.3

(32)【優先日】2016年4月22日

(33)【優先権主張国】GB

(73)【特許権者】

【識別番号】318001991

【氏名又は名称】エヌチェーン ホールディングス リミテッド

【氏名又は名称原語表記】ＮＣＨＡＩＮ ＨＯＬＤＩＮＧＳ ＬＩＭＩＴＥＤ

(74)【代理人】

【識別番号】100107766

【弁理士】

【氏名又は名称】伊東 忠重

(74)【代理人】

【識別番号】100070150

【弁理士】

【氏名又は名称】伊東 忠彦

(74)【代理人】

【識別番号】100091214

【弁理士】

【氏名又は名称】大貫 進介

(72)【発明者】

【氏名】ライト，クレイグ スティーヴン

(72)【発明者】

【氏名】サヴァナ，ステファヌ

【審査官】 金沢 史明

(56)【参考文献】

【文献】 特開２００６−２３６３４９（ＪＰ，Ａ）

【文献】 特開２０１３−０３７７０５（ＪＰ，Ａ）

【文献】 米国特許出願公開第２０１２／０２８４７９４（ＵＳ，Ａ１）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｌ ９／００− ９／３８

Ｇ０９Ｃ １／００

Ｇ０６Ｆ ２１／００−２１／８８

(57)【特許請求の範囲】

【請求項1】

分散ハッシュテーブル及びピアツーピア分散台帳を用いて被制御デジタルリソースを保証する、コンピュータにより実施される方法であって、前記方法は、
前記被制御デジタルリソースに関連付けられたデータを決定するステップと、
前記被制御デジタルリソースの第１ハッシュ値を決定するステップと、
前記データ及び前記被制御デジタルリソースに基づき、第２ハッシュ値を決定するステップと、
通信ネットワークを介して、前記データ、前記第１ハッシュ値、及び前記第２ハッシュ値を分散ハッシュテーブル内の記憶のためのエントリに送信するステップであって、前記第２ハッシュ値はキー値ペアのキーであり、前記データ及び前記第１ハッシュ値は前記キー値ペアの値である、ステップと、
前記ピアツーピア分散台帳に記憶するために、前記第２ハッシュ値を有するメタデータを決定するステップと、
を含む方法。

【請求項2】

前記被制御デジタルリソースはコンピュータソフトウェアである、請求項１に記載の方法。

【請求項3】

第１Ｒｅｄｅｅｍスクリプトを決定するステップ、を更に含み、前記第１Ｒｅｄｅｅｍスクリプトは、
前記メタデータと、
エージェントに関連付けられたエージェント公開鍵と、
に基づく、請求項１に記載の方法。

【請求項4】

前記通信ネットワークを介して、
転送されるべき第１暗号通貨額の指示であって、前記第１暗号通貨額は前記第１Ｒｅｄｅｅｍスクリプトに関連付けられる、第１暗号通貨額の指示と、
前記第１Ｒｅｄｅｅｍスクリプトと、
に基づき、前記ピアツーピア分散台帳に記憶するために、第１データアウトプットを送信するステップ、を更に含む請求項３に記載の方法。

【請求項5】

前記データは、前記被制御デジタルリソースに関連付けられたライセンスを含む、請求項１乃至４のいずれか一項に記載の方法。

【請求項6】

前記ライセンスは、第１ユーザ又は第２ユーザに関連付けられ、前記第１ユーザに関連付けられた第１ユーザ公開鍵又は前記第２ユーザに関連付けられた第２ユーザ公開鍵を更に含む、請求項４又は５に記載の方法。

【請求項7】

前記ライセンスは、前記第１ユーザ又は前記第２ユーザの少なくとも１つの電子装置に関連付けられたハッシュ値を更に含む、請求項４、５、又は６のいずれか一項に記載の方法。

【請求項8】

前記ライセンスは、前記第１ハッシュ値を更に含む、請求項４乃至７のいずれか一項に記載の方法。

【請求項9】

前記ライセンスは、マークル木のトップハッシュ値を含む、請求項４乃至８のいずれか一項に記載の方法。

【請求項10】

第１ユーザに対して被制御デジタルリソースへのアクセスを認可する、コンピュータにより実施される方法であって、前記方法は、
請求項１に従い被制御デジタルリソースを保証するメタデータを決定するステップと、
第２Ｒｅｄｅｅｍスクリプトを決定するステップであって、前記第２Ｒｅｄｅｅｍスクリプトは、
前記メタデータと、
前記エージェントに関連付けられた前記エージェント公開鍵と、
前記第１ユーザに関連付けられた前記第１ユーザ公開鍵と、
に基づく、ステップと、
第２通信ネットワークを介して、第２データアウトプットを前記ピアツーピア分散台帳へ送信するステップであって、
前記第１データアウトプットからの前記第１暗号通貨額が転送されるべきであるという指示と、
前記第２Ｒｅｄｅｅｍスクリプトと、
に基づく、ステップと、
を含む方法。

【請求項11】

前記被制御デジタルリソース又は前記ライセンスの位置を示す識別子を決定するステップと、
前記識別子を前記キー値ペアの中の前記値に割り当てるステップと、
前記通信ネットワークを介して、前記識別子を前記分散ハッシュテーブルの前記エントリへ送信するステップと、
を更に含む請求項１乃至１０のいずれか一項に記載の方法。

【請求項12】

被制御デジタルリソース又はライセンスの位置を決定する、コンピュータにより実施される方法であって、前記方法は、
請求項１に記載の方法に従い、被制御デジタルリソースを保証するメタデータを決定するステップと、
前記被制御デジタルリソース又は前記ライセンスの位置を示す識別子を決定するステップと、
前記キー値ペアの中の前記値に前記識別子を割り当てるステップと、
前記通信ネットワークを介して、前記分散ハッシュテーブルの前記エントリに前記識別子を送信するステップと、
前記第１Ｒｅｄｅｅｍスクリプトから前記メタデータを決定するステップと、
前記メタデータから前記第２ハッシュ値を検索するステップと、
前記通信ネットワークを介して、前記分散ハッシュテーブルの参加ノードに関連付けられたプロセッサへ、前記第２ハッシュ値を送信するステップと、
前記参加ノードの前記プロセッサから、前記被制御デジタルリソース又はライセンスの位置を示す前記識別子を決定するステップと、
を含む方法。

【請求項13】

前記暗号通貨はビットコインである、請求項４又は１０に記載の方法。

【請求項14】

前記ピアツーピア分散台帳はブロックチェーン、望ましくはビットコインブロックチェーンである、請求項１乃至１３のいずれか一項に記載の方法。

【請求項15】

コンピュータソフトウェアプログラムであって、処理装置に請求項１乃至１４のいずれか一項に記載の方法を実施させる機械可読命令を含むコンピュータソフトウェアプログラム。

【請求項16】

被制御デジタルリソースを保証するコンピュータシステムであって、前記システムは、ノードに関連付けられた処理装置を含み、
前記被制御デジタルリソースに関連付けられたデータを決定し、
前記被制御デジタルリソースの第１ハッシュ値を決定し、
前記データ及び前記被制御デジタルリソースに基づき、第２ハッシュ値を決定し、
通信ネットワークを介して、前記データ、前記第１ハッシュ値、及び前記第２ハッシュ値を分散ハッシュテーブル内の記憶のためのエントリに送信し、前記第２ハッシュ値はキー値ペアのキーであり、前記データ及び前記第１ハッシュ値は前記キー値ペアの値であり、
前記第２ハッシュ値を有するメタデータを決定する、
よう構成されるシステム。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、ブロックチェーン技術、セキュリティメカニズム、及び資産転送に関する。本発明は、特に、コンピュータソフトウェアのようなデジタル資産を保証し、分散ハッシュテーブル及びピアツーピア分散台帳（例えばブロックチェーン）を用いて資産（例えばコンピュータソフトウェア）へのアクセスを認可する／制御するメカニズムとしての使用に適する。

【背景技術】

【0002】

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

【0003】

ブロックチェーンは、ブロックにより構成される、コンピュータに基づく非集中型の分散型システムとして実装されるピアツーピア電子台帳である。また、ブロックはトランザクションにより構成される。各トランザクションは、ブロックチェーンシステム内で参加者間のデジタル資産の制御の転送を符号化するデータ構造であり、少なくとも１つのインプット及び少なくとも１つのアウトプットを含む。各ブロックは前のブロックのハッシュを含み、ブロックは共にチェーンになって、その発端からブロックチェーンに書き込まれている全てのトランザクションの永久的な変更不可能なレコードを生成する。トランザクションは、そのインプット及びアウトプットに埋め込まれたスクリプトとして知られる小さなプログラムを含む。スクリプトは、トランザクションのアウトプットがどのように及び誰によりアクセス可能かを指定する。ビットコインプラットフォーム上で、これらのスクリプトは、スタックに基づくスクリプト言語を用いて記述される。

【0004】

トランザクションがブロックチェーンに書き込まれるために、「検証され」なければならない。ネットワークノード（マイナー）は、各トランザクションが有効であることを保証するために作業を実行し、無効なトランザクションはネットワークから拒否される。ノードにインストールされたソフトウェアクライアントは、自身のロック及びアンロックスクリプトを実行することにより、この検証作業を未使用トランザクション（ＵＴＸＯ）に対して実行する。ロック及びアンロックスクリプトの実行が真と評価した場合、トランザクションは有効であり、トランザクションはブロックチェーンに書き込まれる。したがって、トランザクションがブロックチェーンに書き込まれるためには、トランザクションは、ｉ）トランザクションを受信した第１ノードにより検証され、トランザクションが検証された場合に、ノードは該トランザクションをネットワーク内の他のノードに中継し、ｉｉ）マイナーにより構築された新しいブロックに追加し、ｉｉｉ）マインされ、つまり過去のトランザクションの公開台帳に追加されなければならない。

【0005】

ブロックチェーン技術は、暗号通貨実装の使用で最も広く知られているが、デジタル起業家が、新しいシステムを実装するために、ビットコインの基づく暗号通貨セキュリティシステム、及びブロックチェーンに格納可能なデータの両方の使用を探索し始めている。ブロックチェーンが、暗号通貨の領域に限定されない自動タスク及び処理のために使用できれば、非常に有利である。このようなソリューションは、それらの用途において一層多様でありながら、ブロックチェーンの利点（例えば、永久的、イベントの耐タンパレコード、分散処理、等）を利用できる。

【0006】

現在の研究の一分野は、「スマートコントラクト（smart contracts）」の実装のためのブロックチェーンの使用である。これらは、機械可読取引又は合意の条件の実行を自動化するために設計されたコンピュータプログラムである。ブロックチェーンに関連する関心の他の分野は、ブロックチェーンを介する現実世界のエンティティを表し転送するための「トークン」（又は「カラードコイン」）の使用である。潜在的に機密な又は秘密のアイテムは、識別可能な意味又は値を有しないトークンにより表現できる。したがって、トークンは、現実世界のアイテムをブロックチェーンから参照できるようにする識別子として機能し、拡張されたセキュリティを提供する。

【0007】

例えばコンピュータソフトウェアのようなデジタル資産を送信し、共有し、又はそれへのアクセスを制御する目的で、暗号化及びブロックチェーン技術のようなセキュリティ関連機能を使用できることは有利である。コンピュータソフトウェアの完全性保証及び共有のための伝統的アプローチは、コンピュータソフトウェアの実行ファイルのデジタル署名を含む。例えば、実行ファイル又は他の関連コードに、公開鍵及び秘密鍵のような暗号鍵対により署名することである。公開鍵は、認証局のような信頼できる中央当局から得られる場合が多い。

【0008】

コンピュータソフトウェアは、契約上の義務を含むライセンスを伴う場合が多い。ライセンスは、ソフトウェアの使用又は再分配を規定する条項を含むことがある。コンピュータソフトウェア又は関連ライセンスが別のユーザへ違法に転送される場合に、問題が生じ得る。

【0009】

本願明細書に含まれる文書、動作、材料、装置、製品、等の議論は、これらの項目のうちのいずれか又は全部が従来基盤の部分を形成すること、又は本願の各請求項の優先日前に存在していたような本開示の関連分野における共通の一般知識であったとの承認として解釈されるべきではない。

【0010】

本願明細書を通じて、用語「含む、有する（comprise）」又は「comprises」若しくは「comprising」のような変形は、記述される要素、整数若しくはステップ、又は要素、整数若しくはステップのグループ、の包含を意味すると理解されるが、任意の他の要素、整数若しくはステップ、又は要素、整数若しくはステップのグループを除外しない。

【発明の概要】

【0011】

本発明の実施形態は、被制御デジタルリソース又は資産へのアクセス及び／又はその送信を制御する方法及び対応するシステムを有し得る。本発明は、分散ハッシュテーブル及びピアツーピア分散台帳（例えばブロックチェーン）を用いて被制御デジタルリソースを保証するメタデータＭを決定する、コンピュータにより実施される方法を有し得る。本発明は、セキュリティ方法／システム又は制御方法／システムとして記載され得る。本発明は被制御デジタルリソースの完全性、その制御、及び／又はそれへのアクセスを保証する方法／システムとして記載され得る。本発明は、認証又は認可方法／システムを有し得る。

【0012】

一実施形態では、被制御デジタルリソースはコンピュータソフトウェアであって良い。以後、用語「ソフトウェア」又は「コンピュータソフトウェア」は、「被制御デジタルリソース」の代わりに使用される場合がある。

【0013】

方法は、前記コンピュータソフトウェアに関連付けられたデータ（Ｄ１）を決定するステップと、前記コンピュータソフトウェアの第１ハッシュ値（Ｈ１）を決定するステップと、前記データ（Ｄ１）及び前記コンピュータソフトウェアに基づき、第２ハッシュ値（Ｈ２）を決定するステップと、通信ネットワークを介して、前記データ（Ｄ１）、前記第１ハッシュ値（Ｈ１）、及び前記第２ハッシュ値（Ｈ２）を分散ハッシュテーブル内の記憶のためのエントリに送信するステップであって、前記第２ハッシュ値（Ｈ２）はキー値ペアのキーであり、前記データ（Ｄ１）及び前記第１ハッシュ値（Ｈ１）は前記キー値ペアの値である、ステップと、前記ピアツーピア分散台帳に記憶するために、前記第２ハッシュ値（Ｈ２）を有するメタデータ（Ｍ）を決定するステップと、を含んで良い。

【0014】

方法は、第１Ｒｅｄｅｅｍスクリプト（ＲＳ１）を決定するステップ、を更に含んで良く、前記第１Ｒｅｄｅｅｍスクリプトは、前記メタデータ（Ｍ）と、エージェント（Ａ）に関連付けられたエージェント公開鍵（ＰＡ）と、に基づく。前記Ｒｅｄｅｅｍスクリプトは、ブロックチェーントランザクション（Ｔｘ）のＲｅｄｅｅｍスクリプトであって良い。

【0015】

方法は、前記通信ネットワークを介して、転送されるべき第１暗号通貨額の指示であって、前記第１暗号通貨額は前記第１Ｒｅｄｅｅｍスクリプトに関連付けられる、第１暗号通貨額の指示と、前記第１Ｒｅｄｅｅｍスクリプトと、に基づき、前記ピアツーピア分散台帳に記憶するために、第１データアウトプットを送信するステップ、を更に含んで良い。

【0016】

方法では、前記データ（Ｄ１）は、前記コンピュータソフトウェアに関連付けられたライセンスを更に有して良い。前記ライセンスは、第１ユーザ（Ｕ１）又は第２ユーザ（Ｕ２）に関連付けられて良く、前記第１ユーザに関連付けられた第１ユーザ公開鍵（ＰＵ１）又は前記第２ユーザに関連付けられた第２ユーザ公開鍵（ＰＵ２）を更に含む。前記ライセンスは、前記第１ユーザ（Ｕ１）又は前記第２ユーザ（Ｕ２）の少なくとも１つの電子装置に関連付けられたハッシュ値を更に有して良い。前記ライセンスは、前記第１ハッシュ値（Ｈ１）を更に有して良い。

【0017】

方法において、前記第２ハッシュ値（Ｈ２）は、マークル木のトップハッシュ値を有して良い。

【0018】

本発明は、第１ユーザ（Ｕ１）に対してコンピュータソフトウェアへのアクセスを認可する、コンピュータにより実施される方法であって、前記方法は、上述の方法に従いコンピュータソフトウェアを保証するメタデータ（Ｍ）を決定するステップと、第２Ｒｅｄｅｅｍスクリプト（ＲＳ２）を決定するステップであって、前記第２Ｒｅｄｅｅｍスクリプト（ＲＳ２）は、前記メタデータ（Ｍ）と、前記エージェント（Ａ）に関連付けられた前記エージェント公開鍵（ＰＡ）と、前記第１ユーザ（Ｕ１）に関連付けられた前記第１ユーザ公開鍵（ＰＵ１）と、に基づく、ステップと、通信ネットワークを介して、第２データアウトプット（Ｏ２）を前記ピアツーピア分散台帳へ送信するステップであって、前記第１データアウトプット（Ｏ１）からの前記第１暗号通貨額（Ｃ１）が転送されるべきであるという指示と、前記第２Ｒｅｄｅｅｍスクリプト（ＲＳ２）と、に基づく、ステップと、を含む方法を提供し得る。

【0019】

方法は、前記コンピュータソフトウェア又は前記ライセンスの位置を示す識別子を決定するステップと、前記識別子を前記キー値ペアの中の前記値に割り当てるステップと、前記通信ネットワークを介して、前記識別子を前記分散ハッシュテーブルの前記エントリへ送信するステップと、を更に含んで良い。

【0020】

コンピュータソフトウェア又はライセンスの位置を決定する、コンピュータにより実施される方法であって、前記方法は、上述の方法に従い、コンピュータソフトウェアを保証するメタデータ（Ｍ）を決定するステップと、前記コンピュータソフトウェア又は前記ライセンスの位置を示す識別子を決定するステップと、前記キー値ペアの中の前記値に前記識別子を割り当てるステップと、前記通信ネットワークを介して、前記分散ハッシュテーブルの前記エントリに前記識別子を送信するステップと、前記第１Ｒｅｄｅｅｍスクリプトから前記メタデータ（Ｍ）を決定するステップと、前記メタデータ（Ｍ）から前記第２ハッシュ値（Ｈ２）を読み出すステップと、前記通信ネットワークを介して、前記分散ハッシュテーブルの参加ノードに関連付けられたプロセッサへ、前記第２ハッシュ値（Ｈ２）を送信するステップと、前記参加ノードの前記プロセッサから、前記コンピュータソフトウェア又はライセンスの位置を示す前記識別子を決定するステップと、を含む方法。

【0021】

上述の方法では、前記暗号通貨はビットコインであって良く、前記ピアツーピア分散台帳はビットコインブロックチェーンであって良い。

【0022】

本発明の実施形態は、暗号鍵の位置としてブロックチェーンプロトコルで指定される位置に、Ｒｅｄｅｅｍスクリプトの中でメタデータを提供するステップを有して良い。

【0023】

本発明の１又は複数の実施形態は、実質的に「メタデータ」と題される章で後述される、ブロックチェーントランザクションにメタデータを埋め込む方法を含み得る。これは、デジタル資産に関連するアウトプット（ＴｘＯ）及びＲｅｄｅｅｍスクリプトを有するブロックチェーントランザクション（Ｔｘ）を生成するステップであって、Ｒｅｄｅｅｍスクリプトは、トークン化されたエンティティを表す又はそれへの参照であるトークンを含むメタデータと、少なくとも１つの公開暗号鍵と、を含む、ステップ、を有して良い。

【0024】

デジタル資産は、暗号通貨額であって良い。メタデータは、暗号鍵の位置としてブロックチェーンプロトコルで指定される位置に、Ｒｅｄｅｅｍスクリプトの中で提供されて良い。トランザクションＴｘは、ブロックチェーンネットワークに提出されて良い。

【0025】

コンピュータソフトウェアプログラムであって、処理装置に上述の方法を実施させる機械可読命令を含むコンピュータソフトウェアプログラム。

【0026】

分散ハッシュテーブルを用いてコンピュータソフトウェアを保証するメタデータ（Ｍ）を決定するコンピュータシステムであって、前記システムは、ノードに関連付けられた処理装置を含み、前記コンピュータソフトウェアに関連付けられたデータ（Ｄ１）を決定し、前記コンピュータソフトウェアの第１ハッシュ値（Ｈ１）を決定し、前記データ（Ｄ１）及び前記コンピュータソフトウェアに基づき、第２ハッシュ値（Ｈ２）を決定し、通信ネットワークを介して、前記データ（Ｄ１）、前記第１ハッシュ値（Ｈ１）、及び前記第２ハッシュ値（Ｈ２）を分散ハッシュテーブル内の記憶のためのエントリに送信し、前記第２ハッシュ値（Ｈ２）はキー値ペアのキーであり、前記データ（Ｄ１）及び前記第１ハッシュ値（Ｈ１）は前記キー値ペアの値であり、前記第２ハッシュ値（Ｈ２）を有するメタデータ（Ｍ）を決定する、よう構成されるシステム。

【図面の簡単な説明】

【0027】

本開示の例は、以下の図面を参照して記載される。

【図1】ハッシュテーブルの一例を示す。

【図2】分散ハッシュテーブルを用いてコンピュータソフトウェアを保証するメタデータ（Ｍ）を決定する例示的なシステムの概略図を示す。

【図3】分散ハッシュテーブルを用いてコンピュータソフトウェアを保証するメタデータ（Ｍ）を決定するコンピュータにより実施される方法のフローチャートを示す。

【図4】マークル木の一例を示す。

【図5】コンピュータソフトウェア及びコンピュータソフトウェアに関連付けられたライセンスへの参照を有するマークル木の一例を示す。

【図6】分散ハッシュテーブルを用いてコンピュータソフトウェアの位置を示す識別子を決定するコンピュータにより実施される方法のフローチャートを示す。

【図7】例示的な処理装置の概略を示す。

【発明を実施するための形態】

【0028】

本開示は、概して、コンピュータソフトウェアを保証するために、分散ハッシュテーブル、及びビットコインブロックチェーンのようなピアツーピア（peer-to-peer：Ｐ２Ｐ）分散台帳を利用する方法及びシステムに関する。

【0029】

以下に記載する実施形態は、具体的にビットコインブロックチェーン（以後ブロックチェーンとして参照される）上で生じるトランザクションを参照する場合があるが、本発明は他のＰ２Ｐ分散台帳を用いて実施されて良いことが理解される。ブロックチェーンの高度な標準化及び大量の関連する公開された文書のために、単に単純さを目的として、本発明の態様を記載するために以下でブロックチェーンが使用される。

【0030】

＜分散ハッシュテーブル＞
標準的なクライアント／サーバモデルでは、中央サーバは、大部分のリソースを管理し得る。これは、中央サーバに対する攻撃又はその障害が生じた場合に、中央サーバに格納された大部分のリソースが危険に晒され得ることを意味する。対照的に、分散モデルでは、リソースは参加ノード間で共有される（「分散される」）。この場合、全ての参加ノードの能力は利用されず、１つのサーバの障害が大部分のリソースを危険に晒すことはない。

【0031】

図１は、ハッシュテーブルの一例を示す。ハッシュテーブルは、キー値ペアで構成される。各キー値ペアのキーは、ハッシュ関数によりインデックスにマッピングされる。インデックスは、キー値ペアの格納された値の位置を定める。

【0032】

ＤＨＴは、ハッシュテーブルに分散モデルを適用する一例である。ハッシュテーブルと同様に、ＤＨＴは、キー値ペアを有し、単にキーが与えられるとキー値ペアの値の場所を特定する（「ルックアップする」）効率的な方法を提供する。しかしながら、ハッシュテーブルと対照的に、キー値ペアは、多数の参加ノードにより分散され及び共有される。このように、キー値ペアを格納し及び維持する責任は、参加ノードにより共有される。

【0033】

ハッシュテーブルと同じ方法で、ＤＨＴの中の各キー値ペアは、インデックスにマッピングされる。インデックスは、キーに対してハッシュ関数を実行することにより、各キー値ペアについて決定される。例えば、インデックスを決定するために暗号ＳＨＡ（Secure Hash Algorithm）−１が使用されて良い。

【0034】

各参加ノードは、鍵空間の区分化により少なくとも１つのインデックスを割り当てられる。参加ノードの割り当てられた各インデックスについて、参加ノードはキー値ペアの値を格納する。

【0035】

キー値ペアの値が効率的に検索できることは有利である。キーに関連付けられた値を検索するために、ノードは「ルックアップ」を実行して（インデックスにより）責任あるノードを決定して良い。責任あるノードは、次に、値を決定するためにアクセスされて良い。

【0036】

＜ビットコイン及びブロックチェーン＞
従来よく知られているように、ブロックチェーンは、ビットコインプロトコルに基づくシステムに参加するネットワーク接続されたノード間で記憶容量が分散されるトランザクション型台帳である。各ビットコイントランザクションはネットワークにブロードキャストされ、トランザクションが確認され、次にブロックに集約される。ブロックは、次に、ブロックを複数の参加ノードに格納することにより、ブロックチェーンに含まれる。

【0037】

暗号通貨のＰ２Ｐ分散台帳の完全なコピーは、暗号通貨においてこれまでに実行された全てのトランザクションを含む。したがって、トランザクションデータレコードの絶えず増大するリストが提供される。ブロックチェーンに入った各トランザクションは暗号によって実施されるので、ブロックチェーンは、例え参加ノードのオペレータによるものでも、タンパリング及び改訂に対しても強健である。

【0038】

ブロックチェーンの透過性により、各トランザクションについて履歴が公衆に利用可能である。

【0039】

ブロックチェーンの更なる利点は、トランザクションがトランザクションのレコードでもあることである。つまり、トランザクションはブロックチェーンの中に埋め込まれる。

【0040】

このように、トランザクションに関連する情報は実際のトランザクションの中にキャプチャされる。このレコードは、永久的且つ不変であり、したがって、トランザクションレコードを別個のデータベースに保持するための第三者に対する要件を削除する。有利なことに、本発明は、ブロックチェーンを介するソフトウェアのような資産のこの制御又は転送を実現するための技術を用いることができ、転送をセキュアな方法で実行することを可能にし、暗号鍵の使用を組み込み、一方で、基礎となるブロックチェーンプロトコルのいかなる変更も必要としない。

【0041】

＜Pay-to-script-hash及びマルチシグネチャ＞
以下の実施形態は具体的にビットコインプロトコルのＰ２ＳＨ（pay-to-script-hash）方法を使用するトランザクションを参照する場合があるが、本発明はブロックチェーンビットコインプロトコルと別の機能的に等価な方法を用いて実施されて良いことが理解される。

【0042】

ブロックチェーン上の各トランザクションレコードは、トランザクション及び公開鍵の数を示す情報を含むスクリプトを有する。これらの公開鍵は、暗号通貨の送信側及び受信側に関連付けられて良い。Ｐ２ＰＫＨインプットは、送信側の公開鍵を含む。Ｐ２ＰＫＨアウトプットは、受信側の公開鍵のハッシュを含む。Ｐ２ＳＨ ｍｕｌｔｉｓｉｇインプットは、送信側の署名を含む。スクリプトは、ユーザがどのようにトランザクションレコード内で指定された暗号通貨へのアクセスを得ることができるかを記述するブロックチェーン上の各トランザクションレコードと共に記録された命令リストとして考えられる。

【0043】

背景として、ビットコインプロトコルの標準的なＰ２ＳＨ方法では、アウトプットスクリプト又はＲｅｄｅｅｍスクリプトは、以下の形式を取り得る。

【0044】

<NumSigs PubK１ PubK２ … PubK１５ NumKeys OP_CHECKMULTISIG>
ここで、ＮｕｍＳｉｇｓは、トランザクションを解除するためにＲｅｄｅｅｍスクリプトを満たすために必要な有効署名の数「ｍ」である。ＰｕｂＫ１、ＰｕｂＫ２、．．．、ＰｕｂＫ１５は、トランザクションを解除する署名に対応する公開鍵である（最大１５個の公開鍵まで）。ＮｕｍＫｅｙｓは公開鍵の数「ｎ」である。

【0045】

ビットコインプロトコルで、楕円曲線デジタル署名アルゴリズムを用いて、ユーザの秘密鍵に基づく署名が生成されて良い。署名は、次に、アウトプットスクリプト又はＲｅｄｅｅｍスクリプトに関連付けられた暗号通貨の償還のために使用される。ユーザがアウトプットスクリプト又はＲｅｄｅｅｍスクリプトを償還する（redeem、引き換える）とき、ユーザは彼らの署名及び公開鍵を提供する。アウトプットスクリプト又はＲｅｄｅｅｍスクリプトは、次に、公開鍵に対して署名を検証する。

【0046】

上述のＲｅｄｅｅｍスクリプトを償還するために、少なくとも、公開鍵に対応する「ｍ」個の署名が必要である。幾つかの例では、公開鍵の順序が重要であり、「ｎ」人のうちの「ｍ」人の署名する署名者が順次行われなければならない。例えば、「ｍ」が２であり、「ｎ」が１５である場合を考える。使用可能な２つの署名、Ｓｉｇ１（ＰｕｂＫ１に対応する）及びＳｉｇ１５（ＰｕｂＫ１５に対応する）がある場合、Ｒｅｄｅｅｍスクリプトは、先ずＳｉｇ１により署名され、続いてＳｉｇ１５により署名されなければならない。

【0047】

＜システム概要＞
コンピュータソフトウェアを保証するメタデータ（Ｍ）を決定する方法、装置、及びシステムが以下に記載される。

【0048】

図２は、通信ネットワーク５を介して第２ノード７と通信する第１ノード３を含むシステム１を示す。第１ノード３は関連する第１処理装置２１を有し、及び第２ノード５は関連する第２処理装置２７を有する。第１及び第２ノード３、7の例は、コンピュータ、タブレットコンピュータ、モバイル通信装置、コンピュータサーバ、等のような電子装置を含む。

【0049】

キー値ペアを記録し格納するためのＤＨＴ１３も、図２に示される。ＤＨＴ１３は、キー値ペアの値を受信し、記録し、及び格納するために、１又は複数の処理装置１９に関連付けられて良い。処理装置１９は、ＤＨＴ１３の「参加ノード」により使用されて良い。上述のように、ＤＨＴ１３は、キー値ペアの値の場所を特定する効率的方法を提供する。

【0050】

図２は、トランザクションを記録するためのＰ２Ｐ分散台帳１４も示す。Ｐ２Ｐ分散台帳１４は、トランザクションを受信し及び記録するために、１又は複数の処理装置２０に関連付けられて良い。上述のように、Ｐ２Ｐ分散台帳１４の一例は、ビットコインブロックチェーンである。したがって、ブロックチェーンの文脈では、Ｐ２Ｐ分散台帳１４に関連付けられた処理装置２０は、「マイナー」として参照される処理装置であって良い。

【0051】

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

【0052】

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

【0053】

一例では、第１ノード３は、図３及び図６により示されるような方法１００、５００を実行する。別の例では、第２ノード７が、方法１００、５００を実行する。以下の例示的な実施形態は、第１ノード３を方法を実行するとして参照することがあるが、本開示は、他のノードにより実行されるよう適応され又は変更されても良いことが理解される。

【0054】

図３に示される方法１００は、コンピュータソフトウェアに関連付けられたデータ（Ｄ１）を決定するステップ１１０を含む。データ（Ｄ１）は、コンピュータソフトウェアに関連付けられたライセンスを更に有して良い。方法１００は、コンピュータソフトウェアに基づき第１ハッシュ値（Ｈ１）を決定するステップ１２０を更に含む。一例では、第１ハッシュ値（Ｈ１）は、コンピュータソフトウェアの実行ファイルに関連して良い。

【0055】

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

【0056】

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

【0057】

方法１００は、ピアツーピア分散台帳１４に含めるために、第２ハッシュ値（Ｈ２）に基づくメタデータ（Ｍ）を決定するステップ１５０を更に含む。一例では、メタデータ（Ｍ）は、ピアツーピア分散台帳１４に含めるために第１Ｒｅｄｅｅｍスクリプトに含まれて良い。

【0058】

方法の詳細な例が以下に記載される。

【0059】

＜コンピュータソフトウェアに関連付けられたデータを決定する１１０＞
上述のように、方法１００は、コンピュータソフトウェアに関連付けられたデータ（Ｄ１）を決定するステップ１１０を含む。データ（Ｄ１）を決定するステップ１１０は、ユーザ、ノード、又はデータストアからデータ（Ｄ１）を受信するステップを含んで良い。データ（Ｄ１）を決定するステップ１１０は、第１ノード３においてデータ（Ｄ１）を生成するステップを更に含んで良い。

【0060】

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

【0061】

データ（Ｄ１）は、コンピュータソフトウェアに関連付けられる。ここで、データ（Ｄ１）は、コンピュータソフトウェア、追加情報、コンピュータソフトウェアのライセンスを識別し、又はコンピュータソフトウェアの位置を示して良い。例えば、データ（Ｄ１）は、コンピュータソフトウェアを識別する文字列又はデータ構造を有して良い。文字列又はデータ構造は、識別キーワード及び／又はコンピュータソフトウェアに関する追加情報の集合を有して良い。追加情報の一例は、コンピュータソフトウェアのバージョンの識別子、例えば数値であって良い。例えば、コンピュータソフトウェアがＢｏｂＳｏｆｔｗａｒｅでありバージョンが３．０である場合、文字列又はデータ構造（Ｄ１）は「ＢｏｂＳｏｆｔｗａｒｅ／３．０」を有して良い。

【0062】

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

【0063】

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

【0064】

更なる例では、データ（Ｄ１）は、コンピュータソフトウェアのベンダを識別する情報を有して良い。これは、ベンダに関連付けられた、名称、アドレス、連絡先の詳細事項、又は公開鍵のような個人の詳細事項を含み得る。

【0065】

＜コンピュータソフトウェアに基づき第１ハッシュ値（Ｈ１）を決定する１２０＞
上述のように、方法１００は、コンピュータソフトウェアの第１ハッシュ値（Ｈ１）を決定するステップ１２０を更に含む。第１ハッシュ値（Ｈ１）を決定するステップ１２０は、ユーザから第１ハッシュ値（Ｈ１）を受信する、又はデータストアから第１ハッシュ値（Ｈ１）にアクセスするステップを含んで良い。第１ハッシュ値（Ｈ１）を決定するステップ１２０は、第１ノード３においてハッシュ値を計算するステップを更に含んで良い。

【0066】

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

【0067】

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

【0068】

ソフトウェアの実行ファイルのハッシュは、情報の２５６ビット表現を生成するために、ＳＨＡ−２５６アルゴリズムを用いて決定されて良い。理解されるべきことに、ＳＨＡ（Secure Hash Algorithm）ファミリの中の他のアルゴリズムを含む他のハッシュアルゴリズムが使用されて良い。幾つかの特定の例は、ＳＨＡ３−２２４、ＳＨＡ３−２５６、ＳＨＡ３−３８４、ＳＨＡ３−５１２、ＳＨＡＫＥ１２８、ＳＨＡＫＥ２５６を含むＳＨＡ−３サブセットの中のインスタンスを含む。他のハッシュアルゴリズムは、ＲＩＰＥＭＤ（RACE Integrity Primitives Evaluation Message Digest）ファミリの中のアルゴリズムを含んで良い。特定の例は、ＲＩＰＥＭＤ−１６０を含んで良い。他のハッシュ関数は、Ｚｅｍｏｒ−Ｔｉｌｌｉｃｈハッシュ関数及びナップサック・ハッシュ関数に基づくファミリを含んで良い。

【0069】

＜データ（Ｄ１）及びコンピュータソフトウェアに基づき第２ハッシュ値（Ｈ２）を決定する１３０＞
方法１００は、データ（Ｄ１）及びコンピュータソフトウェアに基づき第２ハッシュ値（Ｈ２）を決定するステップ１３０を更に含む。

【0070】

一例では、第２ハッシュ値（Ｈ２）は、データ（Ｄ１）とコンピュータソフトウェアの実行ファイル（又は実行ファイルのハッシュ、つまり第１ハッシュ値（Ｈ１））との連結のハッシュに基づき決定されて良い。更なる例では、第２ハッシュ値（Ｈ２）は、データ（Ｄ１）とコンピュータソフトウェアの実行ファイル（又は実行ファイルのハッシュ）と追加情報との連結のハッシュに基づき決定されて良い。

【0071】

追加情報は、第１ユーザ２３（ＰＵ１）又は第２ユーザ２４（ＰＵ２）の公開鍵を有して良い。更なる例では、追加情報は、第１ユーザ２３又は第２ユーザ２４に関連付けられたエンティティの識別子を有して良い。例えば、エンティティは、第１ユーザ２３又は第２ユーザ２４の従業員であって良い。別の例では、エンティティは、第１ユーザ２３又は第２ユーザ２４のサービスプロバイダであって良い。

【0072】

追加情報は、第１ノード３、第２ノード７、第１ユーザ２３、又は第２ユーザ２４に関連付けられた装置の装置識別子を更に有して良い。装置の一例は、図２に示されるような第１処理装置２１である。装置識別子は、ＭＡＣアドレス、マザーボード製造番号、又は装置識別番号のうちの少なくとも１つを含んで良い。装置識別子は、ＭＡＣアドレス、マザーボード製造番号、又は装置識別番号のうちの少なくとも２つの連結を更に含んで良い。更なる例では、装置識別子は、ＭＡＣアドレス、マザーボード製造番号、又は装置識別番号に関連付けられたハッシュ値、又はそれらの連結を有して良い。

【0073】

更なる例では、追加情報は、コンピュータソフトウェアに関連付けられたライセンスの有効期限を有して良い。

【0074】

＜コンピュータソフトウェアに関連付けられたライセンス＞
更なる例では、第２ハッシュ値（Ｈ２）は、データ（Ｄ１）とコンピュータソフトウェアの実行ファイル（又は実行ファイルのハッシュ）と追加情報又はコンピュータソフトウェアに関連するライセンスとの連結のハッシュに基づき決定されて良い。

【0075】

ライセンスの表現は、ライセンスの内容を指定するファイル又は文書であって良い。例えば、ＡＳＣＩＩ平文、ＰＤＦ文書又はＷｏｒｄ文書である。第２ハッシュ値（Ｈ２）は、元の形式のライセンスを含んで良く、又は、例えば、インターネットのような公衆にアクセス可能な通信ネットワーク上のライセンスの位置へのリンクを提供して良い。更なる例では、ハッシュテーブル又はＤＨＴのようなレポジトリ上のライセンスの位置へのリンクが提供されて良い。更なる例では、データストア１７のようなコンピュータに基づくリソース上のライセンスの位置へのリンクが提供されて良い。

【0076】

一例では、ライセンスは、コンピュータソフトウェアに関連付けられた第１ハッシュ値（Ｈ１）を有して良い。

【0077】

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

【0078】

コンピュータソフトウェアに関連付けられたライセンスは、第１ノード３、第２ノード７、第１ユーザ２３、又は第２ユーザ２４に関連付けられた装置の装置識別子を更に有して良い。装置の一例は、図２に示されるような第１処理装置２１である。装置識別子は、ＭＡＣアドレス、マザーボード製造番号、又は装置識別番号のうちの少なくとも１つを含んで良い。装置識別子は、ＭＡＣアドレス、マザーボード製造番号、又は装置識別番号のうちの少なくとも２つの連結を更に含んで良い。更なる例では、装置識別子は、ＭＡＣアドレス、マザーボード製造番号、又は装置識別番号に関連付けられたハッシュ値、又はそれらの連結を有して良い。

【0079】

第１ユーザ２３は、コンピュータソフトウェアのベンダであって良く、第２ユーザ２４は、コンピュータソフトウェアの受信者（「エンドユーザ」）であって良い。別の例では、第２ユーザ２３は、コンピュータソフトウェアのベンダであって良く、第２ユーザ２４は、コンピュータソフトウェアの受信者（「エンドユーザ」）であって良い。

【0080】

一例では、コンピュータソフトウェアに関連付けられたライセンスは、１人のエンドユーザのみを認可して良い（「単一ユーザライセンス」）。更なる例では、コンピュータソフトウェアに関連付けられたライセンスは、１人のエンドユーザの１台の装置を認可して良い（「単一装置ライセンス」）。別の例では、コンピュータソフトウェアに関連付けられたライセンスは、エンドユーザの１台より多数の装置を認可して良い（「複数装置ライセンス」）。

【0081】

別の例では、１人より多くのエンドユーザが存在して良い（「マルチユーザライセンス」）。更なる例では、コンピュータソフトウェアに関連付けられたライセンスは、エンドユーザ当たり１台の装置を認可して良い。別の例では、コンピュータソフトウェアに関連付けられたライセンスは、エンドユーザ当たり１台より多数の装置を認可して良い。

【0082】

ライセンスが第１ユーザ２３又は第２ユーザ２４に関連付けられる場合には、ライセンスは、第１ユーザ２３に関連付けられた第１ユーザ公開鍵（ＰＵ１）、及び第２ユーザ２４に関連付けられた第２ユーザ公開鍵（ＰＵ２）を有して良い。

【0083】

＜マークル木＞
別の例では、ライセンスはマークル（Merkle）木のトップハッシュ値であって良い。マークル木の一例は図４に示される。マークル木では、各ノードにおけるハッシュ値は、それら個々の「子」ノードのハッシュである。例えば、ハッシュ値Ｈａｓｈ−Ａ３０５は、２個の「子」ノード３０９及び３１１におけるハッシュ値のハッシュである。マークル木のトップハッシュ値、Ｈａｓｈ−ＡＢ３０３は、マークル木の中の全部のハッシュ値を含むことが分かる。つまり、これは、木の最下部にある４枚の「葉」のハッシュ値であるＡ１ ３１７、Ａ２ ３１９、Ｂ１ ３２１、及びＢ２ ３２３をキャプチャする。

【0084】

本開示の一例では、マークル木の各「葉」は、ライセンスの情報の一態様を表す。図５に、例示的なライセンスを示す。データ（Ｄ１）４１７はハッシュ値Ｈａｓｈ−Ｄ４０９の中にキャプチャされ、ソフトウェアの実行ファイル４１９はハッシュ値Ｈａｓｈ−Ｓ４１１（Ｈ１）の中にキャプチャされ、ユーザ２３及び／又は２４の公開鍵４２１はハッシュ値Ｈａｓｈ−Ｐ４１３の中にキャプチャされ、有効期限データ４２３はハッシュ値Ｈａｓｈ−Ｅ４１５の中にキャプチャされる。ノード４０５及び４０７が、それぞれ、データ（Ｄ１）４１７及びソフトウェア４１９の葉、並びに公開鍵４２１及び有効期限４２３の葉に関連付けられたハッシュ値をキャプチャすることが分かる。

【0085】

理解されるべきことに、上述されていない他の情報は、ハッシュ値（Ｈ２）の基づく追加情報を有して良い。

【0086】

＜データ（Ｄ１）、第１ハッシュ値（Ｈ１）、及び第２ハッシュ値（Ｈ２）を分散ハッシュテーブルへ送信する１４０＞
方法１００は、通信ネットワーク５を介して、データ（Ｄ１）、第１ハッシュ値（Ｈ１）、及び第２ハッシュ値（Ｈ２）を、分散ハッシュテーブル１３のエントリへ送信するステップ１４０を更に含む。

【0087】

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

【0088】

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

【0089】

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

【0090】

Ｉｎｄｅｘ＝ＳＨＡ−１（Ｈ２）
ＤＨＴ１３の中のキー値ペアのキーであるべき第２ハッシュ値（Ｈ２）、及びキー値ペアの値であるべき第１ハッシュ値（Ｈ１）について、キー及び値は、ＤＨＹＴ１３の任意の参加ノードへ送信される。

【0091】

一例では、ｐｕｔ（ｋｅｙ，ｖａｌｕｅ）のようなメッセージが、ＤＨＴ１３の参加ノードへ送信されて良い。ここで、ｋｅｙは第２ハッシュ値（Ｈ２）であり、ｖａｌｕｅはデータ（Ｄ１）及び第１ハッシュ値（Ｈ１）である。メッセージは、鍵空間の区分により示されるインデックスに割り当てられる参加ノードにより受信されるまで、全ての参加ノードのあちこちに送信されて良い。メッセージ内で示されたインデックスに割り当てられた参加ノードは、次に、キー値ペアをＤＨＴ１３に格納し、キー値ペアに関連付けられたエントリを維持する責任を引き受けて良い。

【0092】

有利なことに、任意の所与の鍵の値は、ＤＨＴ１３から検索できる。一例では、第１ユーザ２３又は第２ユーザ２４は、値を検索したいと望む。第１ユーザ２３又は第２ユーザ２４は、第１ノード３、第２ノード７、又は図示されない別のノードを介して、ＤＨＴ１３の任意の参加ノードに、ｇｅｔ（ｋｅｙ）のような要求メッセージを提供して良い。要求メッセージは、次に、鍵空間の区分により示されるインデックスに割り当てられる参加ノードにより受信されるまで、全ての参加ノードのあちこちに送信されて良い。

【0093】

＜メタデータ（Ｍ）を決定する１５０＞
方法１００は、第２ハッシュ値（Ｈ２）を有するメタデータ（Ｍ）を決定するステップ１５０を更に含む。メタデータ（Ｍ）を決定するステップ１５０は、ユーザ、ノード、又はデータストアからメタデータ（Ｍ）を受信するステップを含んで良い。メタデータ（Ｍ）は、例えば、Ｐ２Ｐ分散台帳（ブロックチェーン）１４上のトランザクションのＰ２ＳＨマルチシグネチャ第１Ｒｅｄｅｅｍスクリプト（ＲＳ１）の中の公開鍵のために利用可能な１５個の場所のうちの１又は複数の含まれて良い。

【0094】

Ｐ２Ｐ分散台帳１４上のトランザクションの第１Ｒｅｄｅｅｍスクリプト（ＲＳ１）は、メタデータ（Ｍ）に含まれるコンテンツを表すトークン化トランザクション（「発行トークン」）の発行又は生成を表して良い。一例では、トークンは、エージェント（Ａ）により発行されて良い。

【0095】

ビットコインプロトコルのＰ２ＳＨ方法では、メタデータは、以下に記載する方法を用いてＲｅｄｅｅｍスクリプトに含められて良い。

【0096】

＜メタデータ＞
メタデータ（Ｍ）は、Ｐ２ＳＨマルチシグネチャＲｅｄｅｅｍスクリプト（ＲＳ１）の中の公開鍵のために利用可能な１５個の場所のうちの１又は複数に埋め込まれて良い。例えば、Ｒｅｄｅｅｍスクリプト（ＲＳ１）は次の形式を取って良い。

【0097】

<NumSigs Metadata１ Metadata２… PubK１ PubK２… NumKeys OP_CHECKMULTISIG>
ここで、Ｍｅｔａｄａｔａ１及びＭｅｔａｄａｔａ２は、それぞれ、Ｒｅｄｅｅｍスクリプトの中の公開鍵の場所を取り入れるメタデータを含み、ＰｕｂＫ１及びＰｕｂＫ２は公開鍵である。言い換えると、メタデータは、暗号鍵が提供されるべき位置としてブロックチェーンプロトコルにより指定された位置において、Ｒｅｄｅｅｍスクリプトの中で提供されて良い。これは、基礎にあるブロックチェーンプロトコルに対するいかなる変更も伴わずに、メタデータがトランザクション（Ｔｘ）に組み込まれ得るという利点を提供する。

【0098】

メタデータ（Ｍ）は、第２ハッシュ値（Ｈ２）を有して良い。メタデータ（Ｍ）は、コンピュータソフトウェア又はライセンスに関連付けられた条件を記述する記述又はキーワードを更に有して良い。例えば、ライセンスの日付、名称、誕生日、住所、連絡先の詳細、又はライセンスに関連付けられたユーザの他の詳細事項である。更なる例では、暗号通貨額に関連付けられた情報が含まれて良い。

【0099】

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

【0100】

本開示の更なる実施形態では、上述の１又は複数を含む組み合わせがメタデータ（Ｍ）に含まれて良い。メタデータ（Ｍ）はブロックチェーンのようなＰ２Ｐ分散台帳１４により公開され、又は非セキュアネットワークを介して送信され得るので、メタデータ（Ｍ）の特定の詳細事項は、プライバシを理由に秘密にされ又は隠されることが望ましい場合がある。

【0101】

したがって、本開示の実施形態におけるマルチシグネチャＰ２ＳＨビットコイントランザクションの使用は、コンピュータソフトウェア及びライセンスに関連付けられた情報の転送及び永久記録を可能にするという利点を提供する。この記録は、トランザクションのアウトプットスクリプト、例えばＲｅｄｅｅｍスクリプトにメタデータを含めることにより達成される。

【0102】

＜第１Ｒｅｄｅｅｍスクリプト＞
上述のように、Ｒｅｄｅｅｍスクリプトは、ビットコインプロトコルの標準的なＰ２ＳＨ方法におけるアウトプットスクリプトの一例であり、ユーザがどのようにトランザクションレコード内で指定された暗号通貨へのアクセスを得ることができるかを記述する。

【0103】

本開示では、発行トークンの第１Ｒｅｄｅｅｍスクリプト（ＲＳ１）はメタデータ（Ｍ）に基づいて良い。第１Ｒｅｄｅｅｍスクリプト（ＲＳ１）は、エージェント秘密鍵（agent private key：ＶＡ）との暗号対を形成するエージェント公開鍵（agent public key：ＰＡ）を更に有して良い。このように、エージェント秘密鍵（ＶＡ）は、トランザクションに関連付けられた暗号通貨を「アンロック（解除）」する又は使用するために必要である。

【0104】

一例では、発行トークンの第１Ｒｅｄｅｅｍスクリプト（ＲＳ１）はメタデータ（Ｍ）を含んで良い。第１Ｒｅｄｅｅｍスクリプト（ＲＳ１）は、エージェント公開鍵（ＰＡ）を更に含んで良い。本例では、第１Ｒｅｄｅｅｍスクリプト（ＲＳ１）は次の形式を取って良い。

【0105】

<OP_１ PA Metadata１ Metadata２ OP_３ OP_CHECKMULTISIG>
ここで、ＯＰ＿１はトランザクションを解除するために第１Ｒｅｄｅｅｍスクリプト（ＲＳ１）を満たすために必要な署名の数（「ＮｕｍＳｉｇｓ」）を示し、ＯＰ＿３はＲｅｄｅｅｍスクリプトの中の公開鍵の数（「ＮｕｍＫｅｙｓ」）を示す。

【0106】

本例では、第１Ｒｅｄｅｅｍスクリプト（ＲＳ１）は、メタデータのための２個の指定されたフィールド、Ｍｅｔａｄａｔａ１及びＭｅｔａｄａｔａ２を含んで良い。Ｍｅｔａｄａｔａ１及びＭｅｔａｄａｔａ２の特定の例は、以下の表１に示される。

【0107】

［表１］

【0108】

【表1】

本例は、Ｍｅｔａｄａｔａ１内にライセンスへのポインタを提供することを含む。これは、ライセンスのサイズがこのような詳細事項をメタデータ（Ｍ）に含むことを妨げる場合に有用であり得る。さらに、メタデータ（Ｍ）は公表され、非セキュアなネットワークを介して送信され得るので、トークンの特定の詳細事項はプライバシを理由に秘密にされ又は隠されることが望ましい場合がある。

【0109】

Ｍｅｔａｄａｔａ１の最初の４バイトは、ライセンス種類を示す。例えば、ライセンス種類は、ＢｏｂＳｏｆｔｗａｒｅのようなコンピュータソフトウェアの名称を示して良い。更なる例では、ライセンス種類は、上述のような「単一ユーザ」又は「複数装置」のようなライセンスの権限付与の種類を示して良い。次の１６バイトは、実際の電子ライセンスファイルの位置のＩＰアドレスを保持し、ＩＰｖ６アドレスを許容する。幾つかの実施形態では、この値は、ライセンスファイルが集中化されるのではなく、クラウドに渡り分散され得るように、Ｔｏｒｒｅｎｔファイルのシードを指して良い。続く１２バイトは、ライセンス種類に固有のデータを含む。

【0110】

Ｍｅｔａｄａｔａ２の最初の２０バイトは、ライセンスファイルの実際のコンテンツに適用されるＳＨＡ２５６によるＲＩＰＥＭＤ−１６０を用いる実際のライセンスファイルのハッシュである。実際のライセンスファイルは検索可能であるので、これは、コントラクトに対するトランザクションの検証を可能にする。ライセンスファイル自体は、特定の実施形態の要件に依存して、完全に公表されて良く（暗号化されず、人間により可読である）、又はプライバシを理由に暗号化されて良い。Ｍｅｔａｄａｔａ２の残りの１２バイトの内容は、ライセンス種類に依存して使用されて良い。

【0111】

上述の第１Ｒｅｄｅｅｍスクリプト（ＲＳ１）の例から分かるように、発行トークンは使用されるためにエージェント（Ａ）により署名されなければならない。発行トークンのトランザクションの一例は、表２に提供される。ここで、簡潔さのためにマイナー料金は示されない。

【0112】

［表２］

【0113】

【表2】

表２の行４〜８は、発行トークンに含まれるべき（つまり「トークン化される」）第１暗号通貨額（Ｃ１）である、トランザクションへのインプットを表す。本例では、第１暗号通貨額（Ｃ１）は、第１暗号通貨額をエージェント（Ａ）の利益へと転送した前のトランザクション（ＩＤ−１１０）の結果であった。したがって、前のトランザクション（ＩＤ−１１０）のアウトプットスクリプト（ＲｅｄｅｅｍスクリプトＩＤ−１１０）は、エージェントの公開鍵（ＰＡ）を含む。したがって、この前のアウトプットを解除するために、スクリプト（ＲｅｄｅｅｍスクリプトＩＤ−１１０）は、第１ユーザの秘密鍵（ＶＡ）で署名されなければならない。

【0114】

表２の行１０〜１２は、トランザクション（ＩＤ−６００）の第１アウトプット（のみ）を表す。これは、本例では、生成され、エージェントに転送されて戻される発行トークンを表す。行１０は、アウトプット値を示し、第１暗号通貨額（Ｃ１）である。行１２は、ビットコインプロトコルのＰ２ＳＨ方法で使用されるような「＜hash of redeem script＞」を含むアウトプットスクリプトを示す。本例では、Ｒｅｄｅｅｍスクリプトは、上述のような形式の第１Ｒｅｄｅｅｍスクリプト（ＲＳ１）である。

【0115】

表２に示されるトランザクション（ＩＤ−６００）のアウトプットは、次に、第１データアウトプット（Ｏ１）と共に、Ｐ２Ｐ分散台帳１４に記録される。特に、第１データアウトプット（Ｏ１）は、トランザクションの中で転送された第１暗号通貨額（Ｃ１）の指示を有して良い。第１データアウトプット（Ｏ１）は、第１Ｒｅｄｅｅｍスクリプト（ＲＳ１）のハッシュを更に有して良い。

【0116】

第１暗号通貨額（Ｃ１）の将来のトランザクション、例えば、第１ユーザ２３又は第２ユーザ２４へのトークンの転送では、第１暗号通貨額（Ｃ１）を解除するためのスクリプト（例えば将来のトランザクションのインプットスクリプト署名（ＳｃｒｉｐｔＳｉｇ））は、以下の形式であって良い。

【0117】

OP_０ Sig-VA Sig-VU１ <OP_１ PAPU１ Metadata１ Metadata２ OP_４ OP_CHECKMULTISIG>
ここで、Ｓｉｇ−ＶＵ１は第１ユーザ２３の署名を示す。上述のスクリプトは、第１暗号通貨額（Ｃ１）を解除するために、エージェント（Ａ）又は第１ユーザ２３からの１つの署名だけが必要であることを想定していることに留意する。

【0118】

発行トークンは、第２Ｒｅｄｅｅｍスクリプト（ＲＳ２）により、別のユーザへ転送されて良い。

【0119】

＜変形＞
＜第２Ｒｅｄｅｅｍスクリプト＞
コンピュータソフトウェア及びライセンスに関連付けられたトークンは、エージェント（Ａ）から別のユーザ、例えば第１ユーザ２３又は第２ユーザ２４へ転送されて良い。一例では、トークンの転送はコンピュータソフトウェア又はライセンスのユーザへのアクセスを許可することと同様であって良い。転送は第２Ｒｅｄｅｅｍスクリプト（ＲＳ２）により実施されて良い。

【0120】

一例では、エージェント（Ａ）は、第１ユーザ２３へ発行トークンを転送したいと望む。第１ユーザ２３は、例えばコンピュータソフトウェアのベンダを表して良い。

【0121】

本例では、第２Ｒｅｄｅｅｍスクリプト（ＲＳ２）は、メタデータ（Ｍ）、エージェント（Ａ）に関連付けられたエージェント公開鍵（ＰＡ）、及び第１ユーザ２３に関連付けられた第１ユーザ公開鍵（ＰＵ１）に基づいて良い。

【0122】

第２Ｒｅｄｅｅｍスクリプト（ＲＳ２）は次の形式であって良い。

【0123】

<OP_１ PA PU１ Metadata１ Metadata２ OP_４ OP_CHECKMULTISIG>
本例では、第２Ｒｅｄｅｅｍスクリプト（ＲＳ２）は、第１Ｒｅｄｅｅｍスクリプト（ＲＳ１）と同じ２個のメタデータフィールドを含む。第２Ｒｅｄｅｅｍスクリプト（ＲＳ２）は、エージェント（Ａ）に関連付けられたエージェント公開鍵（ＰＡ）、及び第１ユーザに関連付けられた第１ユーザ公開鍵（ＰＵ１）を更に有する。

【0124】

上述の第２Ｒｅｄｅｅｍスクリプト（ＲＳ２）の例から分かるように、転送されるトークンは使用されるためにエージェント（Ａ）又は第１ユーザ２３により署名されなければならない。発行トークンのこの転送のためのトランザクションの一例は、表３に提供される。ここで、再び簡潔さのためにマイナー料金は示されない。

【0125】

［表３］

【0126】

【表3】

表２と同様に、表３の行４〜８は、トランザクション（ＩＤ−６１０）へのインプットを表す。本例では、インプットは発行トークンであり、つまり、表２に示されるトランザクション（ＩＤ−６００）のアウトプットである。行７のＲｅｄｅｅｍスクリプトは発行トークンのＲｅｄｅｅｍスクリプト、つまり第１Ｒｅｄｅｅｍスクリプト（ＲＳ１）に対応することが分かる。したがって、トランザクション（ＩＤ−６００）のアウトプットを解除するために、第１Ｒｅｄｅｅｍスクリプト（ＲＳ１）は、エージェントの公開鍵（ＰＡ）で署名されなければならない。

【0127】

表３の行１０〜１２は、トランザクション（ＩＤ−６１０）のアウトプットを表す。これは、本例では、エージェント（Ａ）又は第１ユーザ２３（Ｕ１）に転送される発行トークンを表す。行１０は、アウトプット値を示し、第１暗号通貨額（Ｃ１）である。行１２は、ビットコインプロトコルのＰ２ＳＨ方法で使用されるような「＜hash of redeem script＞」を含むアウトプットスクリプトを示す。本例では、Ｒｅｄｅｅｍスクリプトは、上述のような形式の第２Ｒｅｄｅｅｍスクリプト（ＲＳ２）である。

【0128】

トランザクション（ＩＤ−６１０）のアウトプットは、次に、第２データアウトプット（Ｏ２）と共に、Ｐ２Ｐ分散台帳１４に記録される。第２データアウトプット（Ｏ２）は、トランザクションの中で転送されるべき第１データアウトプット（Ｏ１）からの第１暗号通貨額（Ｃ１）の指示を有して良い。第２データアウトプット（Ｏ２）は、第２Ｒｅｄｅｅｍスクリプト（ＲＳ２）のハッシュを更に有して良い。

【0129】

＜コンピュータソフトウェア又はライセンスの位置を示す識別子＞
上述のように、データ（Ｄ１）又はライセンスは、それぞれコンピュータソフトウェア又はライセンスの位置を示す識別子を有して良い。

【0130】

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

【0131】

一例では、識別子は、インターネット上のオブジェクトのＵＲＬを有して良い。別の例では、位置を示す識別子は、ハッシュテーブル又はＤＨＴ１３のようなレポジトリのアドレスを有して良い。更に別の例では、位置を示す識別子は、第１ノード３の第１処理装置２１に関連付けられたデータストア１７のような、サーバ、データベース、又はコンピュータに基づくリソースに設けられた記憶設備のようなコンピュータに基づくレポジトリのアドレスを有して良い。

【0132】

図６は、コンピュータソフトウェア又はライセンスの位置を決定する方法５００を示す。方法５００は、第１Ｒｅｄｅｅｍスクリプト（ＲＳ１）からメタデータ（Ｍ）を決定するステップ５１０を含む。上述のように、メタデータ（Ｍ）は、第１Ｒｅｄｅｅｍスクリプト（ＲＳ１）の中の公開鍵のために利用可能な１５個の場所のうちの１又は複数に埋め込まれて良い。

【0133】

ビットコインプロトコルのＰ２ＳＨ方法では、トランザクションのアウトプットが後のトランザクションで使用されるとき、Ｒｅｄｅｅｍスクリプトが後のトランザクションの中で見えるようになる。上述のように、表２を参照すると、発行トークンのためのトランザクション（ＩＤ−６００）は、エージェント（Ａ）に払い戻される。このように、エージェント（Ａ）は、第１Ｒｅｄｅｅｍスクリプト（ＲＳ１）を公表する（expose）ためにこの発行トークンを使用して良い。第２ハッシュ値（Ｈ２）に基づくメタデータ（Ｍ）は、したがって、Ｐ２Ｐ分散台帳１４上で可視である。このように、第２ハッシュ値（Ｈ２）は、第１Ｒｅｄｅｅｍスクリプト（ＲＳ１）内のメタデータ（Ｍ）から検索できる５２０。一例では、キー値ペアのキーに関連付けられた値は、要求メッセージｇｅｔ（ｋｅｙ）を用いてＤＨＴ１３から検索できる。

【0134】

方法５００は、通信ネットワーク５を介して、ＤＨＴ１３の参加ノードに関連付けられたプロセッサへ、第２ハッシュ値（Ｈ２）を送信するステップ５３０を更に含む。上述のように、第２ハッシュ値（Ｈ２）は、キー値ペアのキーであって良い。さらに上述したように、所与のキーに対する値は、キーを含むメッセージをＤＨＴ１３の任意の参加ノードに提供することにより検索できる。したがって、識別子がキー値ペアの値フィールドに含まれる例では、方法５００は、参加ノードのプロセッサから、コンピュータソフトウェア又はライセンスの位置を示す識別子を決定できる５４０。

【0135】

＜処理装置＞
上述のように、第１ノード３及び第２ノード７は、コンピュータ、電話機、タブレットコンピュータ、モバイル通信装置、コンピュータサーバ、等のような電子装置であって良い。電子装置は、処理装置２１、２７、データストア１７、及びユーザインタフェース１５を含んで良い。

【0136】

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

【0137】

本開示はユーザ、従業員、発行人、商人、プロバイダ、又は他のエンティティが特定の動作（署名、発行、決定、計算、送信、受信、生成、等を含む）を実行することを記載したが、この用語は提示の明確化のために使用される。理解されるべきことに、これらの動作は、これらのエンティティにより操作されるコンピューティング装置により実行される。

【0138】

本開示の広範な一般的範囲から逸脱せずに、多数の変形及び／又は変更が上述の実施形態に対して行われることが、当業者により理解される。本発明の実施形態は、したがって、あらゆる面で、単に説明であり限定的でないと考えられる。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】