特表 2024-529317 コンピュータにより実施される方法及びシステム

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

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2024-08-06

(54)【発明の名称】コンピュータにより実施される方法及びシステム

(51)【国際特許分類】

   H04L 9/32 20060101AFI20240730BHJP

【ＦＩ】

H04L9/32 200B

H04L9/32 200Z

H04L9/32 200E

【審査請求】未請求

【予備審査請求】未請求

(21)【出願番号】P 2024501125

(86)(22)【出願日】2022-08-01

(85)【翻訳文提出日】2024-03-05

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

(87)【国際公開番号】W WO2023012127

(87)【国際公開日】2023-02-09

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

(32)【優先日】2021-08-03

(33)【優先権主張国・地域又は機関】GB

(81)【指定国・地域】

(71)【出願人】

【識別番号】318001991

【氏名又は名称】エヌチェーン ライセンシング アーゲー

(74)【代理人】

【識別番号】100107766

【弁理士】

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

(74)【代理人】

【識別番号】100229448

【弁理士】

【氏名又は名称】中槇 利明

(72)【発明者】

【氏名】ランド，リッキー チャールズ

(57)【要約】

委任された認可を確立する、コンピュータが実施するシステム及び方法が詳述される。委任された認可トークンの検証及び生成の方法は、委任された認可トークンのチェーンの第１委任された認可トークンを取得することを含む。委任された認可トークンのチェーンの更なる委任された認可トークンは、委任された認可トークンのチェーンの先行する委任された認可トークンに基づいて生成される。委任された認可トークンの有効性を検証する場合、第１委任された認可トークンの有効性は、委任された認可トークンのチェーンの中の委任された認可トークンの１つと所定の値との比較に基づく。

【特許請求の範囲】

【請求項1】

コンピュータにより実施される方法であって、
所定の値を取得するステップと、
要求を受信するステップであって、前記要求は委任された認可トークンのチェーンの第１委任された認可トークンを含む、ステップと、
前記委任された認可トークンのチェーンの更なる委任された認可トークンを生成するステップであって、前記委任された認可トークンのチェーンの中の更なる委任された認可トークンの各々の生成は、前記委任された認可トークンのチェーンの中の先行する委任された認可トークンに基づく、ステップと、
前記委任された認可トークンのチェーンの中の委任された認可トークンの１つと前記所定の値との比較に基づいて、前記第１委任された認可トークンの有効性を決定するステップと、
を含む方法。

【請求項2】

前記生成は、前記委任された認可トークンのチェーンの中の前記先行する委任された認可トークンのハッシュに基づく、請求項１に記載のコンピュータにより実施される方法。

【請求項3】

前記委任された認可トークンのチェーンの更なる委任された認可トークンを生成するステップは、更なる委任された認可トークンの各々について、以下：
中間プレイメージを決定するステップであって、前記中間プレイメージは、前記委任された認可トークンのチェーンの中の前記先行する委任された認可トークンに基づくものである、ステップと、
前記中間プレイメージに一方向関数を適用するステップであって、前記一方向関数への出力は、前記更なる委任された認可トークンである、ステップと、
を実行することを含む、請求項１に記載のコンピュータにより実施される方法。

【請求項4】

前記一方向関数は、ハッシュである、請求項３に記載のコンピュータにより実施される方法。

【請求項5】

前記中間プレイメージは、所与の値に更に基づく、請求項３に記載のコンピュータにより実施される方法。

【請求項6】

更なる委任された認可トークンの前記生成は、前記委任された認可トークンのチェーンの中の前記先行する委任された認可トークン及び所与の値に基づく、請求項１に記載のコンピュータにより実施される方法。

【請求項7】

記憶装置から前記所与の値を取得するステップ、を更に含む請求項５に記載のコンピュータにより実施される方法。

【請求項8】

前記所与の値がクライアントから受信されたものである、請求項５に記載のコンピュータにより実施される方法。

【請求項9】

生成が前記所与の値と前記先行する委任された認可トークンの連結に基づく、請求項５に記載のコンピュータにより実施される方法。

【請求項10】

前記生成は、前記所与の値と前記委任された認可トークンのチェーンの中の前記先行する委任された認可トークンとの連結のハッシュに基づく、請求項９に記載のコンピュータにより実施される方法。

【請求項11】

前記要求は、インデックス番号を更に含み、前記委任された認可トークンのチェーンの中の委任された認可トークンの数は、前記インデックス番号に基づく、請求項１に記載のコンピュータにより実施される方法。

【請求項12】

前記第１委任された認可トークンの有効性を決定するステップは、前記委任された認可トークンのチェーンの中の最後の委任された認可トークンと前記所定の値との比較に基づく、請求項１に記載のコンピュータにより実施される方法。

【請求項13】

前記第１委任された認可トークンの有効性を決定するステップは、前記委任された認可トークンのチェーンの中の最後の委任された認可トークンと前記所定の値とを比較するステップを含む、請求項１に記載のコンピュータにより実施される方法。

【請求項14】

前記要求は、ブロックチェーンへの送信又はブロックチェーンからの読み取りである、請求項１に記載のコンピュータにより実施される方法。

【請求項15】

前記要求の処理は、更に、同一の第１委任された認可トークンを含む、以前に受信された要求の数に基づく、請求項１に記載のコンピュータにより実施される方法。

【請求項16】

前記委任された認可トークンのチェーンを格納するステップ、を更に含む請求項１に記載のコンピュータにより実施される方法。

【請求項17】

更なる委任された認可トークンを含む更なる要求を受信するステップと、
前記更なる委任された認可トークンが前記格納された委任された認可トークンのチェーンに存在するかどうかに基づいて、前記更なる委任された認可トークンの有効性を決定するステップと、
前記更なる委任された認可トークンの有効性に基づいて前記更なる要求を処理するステップと、
を更に含む請求項１６に記載のコンピュータにより実施される方法。

【請求項18】

前記要求の有効性の指示を提供し、及び／又は前記委任された認可トークンの有効性に基づいて、前記要求を処理するステップ、
を更に含む請求項１～１７のいずれか１つ以上に記載のコンピュータにより実施される方法。

【請求項19】

関連する委任された認可トークンのチェーンを生成するための、コンピュータにより実施される方法であって、
第１値及び第２値を取得するステップと、
前記委任された認可トークンのチェーンの第１委任された認可トークンを生成するステップであって、前記第１委任された認可トークンは前記第１値及び前記第２値に基づく、ステップと、
前記委任された認可トークンのチェーンの少なくとも１つの更なる委任された認可トークンを生成するステップであって、前記委任された認可トークンのチェーンの中の更なる委任された認可トークンの各々の生成は、前記委任された認可トークンのチェーンの中の先行する委任された認可トークン及び前記第１値に基づく、ステップと、
を含むコンピュータにより実施される方法。

【請求項20】

前記委任された認可トークンのチェーンの更なる委任された認可トークンを生成するステップは、更なる委任された認可トークンの各々について、以下：
中間プレイメージを決定するステップであって、前記中間プレイメージは、前記委任された認可トークンのチェーンの中の前記先行する委任された認可トークン及び前記第１値に基づくものである、ステップと、
前記中間プレイメージに一方向関数を適用するステップであって、前記一方向関数への出力は、前記更なる委任された認可トークンである、ステップと、
を実行することを含む、請求項１９に記載のコンピュータにより実施される方法。

【請求項21】

生成が前記第１値と前記先行する委任された認可トークンの連結に基づく、請求項２０に記載のコンピュータにより実施される方法。

【請求項22】

前記生成は、所与の値と前記委任された認可トークンのチェーンの中の前記先行する委任された認可トークンとの連結のハッシュに基づく、請求項２１に記載のコンピュータにより実施される方法。

【請求項23】

前記委任された認可トークンのチェーンの前記委任された認可トークンの１つをデリゲート装置に提供するステップ、を更に含む請求項１９に記載のコンピュータにより実施される方法。

【請求項24】

前記デリゲート装置は、前記委任された認可トークンのインデックスを更に提供され、前記インデックスは、前記提供された委任された認可トークンが前記委任された認可トークンのチェーンの中のどこにあるかを表す、請求項２３に記載のコンピュータにより実施される方法。

【請求項25】

前記第１値及び前記委任された認可トークンのチェーンの最後の委任された認可トークンを検証装置に提供するステップ、を更に含む請求項１９に記載のコンピュータにより実施される方法。

【請求項26】

前記検証装置は、更に、デリゲート当たりの読み取り又は書き込みの最大数を示す数を提供される、請求項２５に記載のコンピュータにより実施される方法。

【請求項27】

前記委任された認可トークンのチェーンの中の委任された認可トークンの数は、デリゲートの数に基づく、請求項１９に記載のコンピュータにより実施される方法。

【請求項28】

前記委任された認可トークンのチェーンの中の委任された認可トークンの数は、デリゲートの数より多い又は等しい、請求項２７に記載のコンピュータにより実施される方法。

【請求項29】

前記第２値は、前記第１委任された認可トークンが生成された後に削除される、請求項１９に記載のコンピュータにより実施される方法。

【請求項30】

前記第１及び前記第２値は、ランダムに生成される、請求項１９に記載のコンピュータにより実施される方法。

【請求項31】

前記先行する委任された認可トークンは、生成中の委任された認可トークンの直前の委任された認可トークンを指す、請求項１に記載のコンピュータにより実施される方法。

【請求項32】

前記第１委任された認可トークンは、請求項１９の方法に従って、クライアントによって生成されたものである、請求項１に記載のコンピュータにより実施される方法。

【請求項33】

コンピュータにより実施される方法であって、
請求項１９の方法に従って生成された委任された認可トークンを受信するステップと、
前記委任された認可トークンを含む要求を生成するステップと、
前記要求をサーバに送信するステップと、
を含むコンピュータにより実施される方法。

【請求項34】

システムであって、
サーバと、
デリゲートと、
クライアントと、
を含み、
前記クライアントは、
請求項１９の方法に従って、委任された認可トークンのチェーン及び第１値を生成し、
第１値及び前記委任された認可トークンのチェーンの最後の委任された認可トークンをサーバに送信し、
前記委任された認可トークンのチェーンの中の委任された認可トークンの１つを前記デリゲートに送信する、
ように構成される、システム。

【請求項35】

前記サーバは、請求項１の方法に従って、前記デリゲートからの要求を受信し処理するように構成されている、請求項３４に記載のシステム。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、１つ以上のクライアントのための分散台帳、すなわちブロックチェーンに関連する１つ以上のサービスのプラットフォームを実装するための方法及びシステムに関する。より具体的には、本開示は、ブロックチェーンに関連するサービスへの、委任されたアクセスの提供を提供するが、これに限定されない。

【背景技術】

【0002】

ブロックチェーンとは、分散型ピアツーピア（P２P）ネットワーク（以下で「ブロックチェーンネットワーク」とも呼ばれる）内の複数のノードの各々において、ブロックチェーンの重複コピーが維持され広く公表される、分散データ構造の形態を指す。ブロックチェーンは、データのブロックのチェーンを含み、各ブロックは１つ以上のトランザクションを含む。所謂「コインベーストランザクション」以外の各トランザクションは、シーケンス内の先行するトランザクションをポイントする。シーケンスは、１つ以上のコインベーストランザクションまで１つ以上のブロックに跨がってよい。コインベーストランザクションは以下で議論される。ブロックチェーンネットワークに送信されるトランザクションは、新しいブロックに含まれる。新しいブロックは、「マイニング」として知られる処理により生成される。「マイニング」は、複数のノードの各々が「proof-of-work」を実行するために競争する、つまり、ブロックチェーンの新しいブロックに含まれることを待っている順序付き及び妥当性確認済みの保留中のトランザクションの定義されたセットの提示に基づき、暗号パズルを解くことを含む。留意すべきことに、ブロックチェーンはノードにおいてプルーニング（pruned）されてよく、ブロックの公開はブロックヘッダのみの公開を通じて達成できる。

【0003】

ブロックチェーン内のトランザクションは、以下：デジタルアセット（つまり、多数のデジタルトークン）を運ぶこと、仮想台帳又はレジストリの中のジャーナルエントリのセットを順序付けること、タイムスタンプエントリを受信し処理すること、及び／又はインデックスポインタを時系列にすること、のうちの１つ以上を実行するために使用される。ブロックチェーンの上に追加の機能をレイヤ化するために、ブロックチェーンを利用することもできる。ブロックチェーンプロトコルは、トランザクション内のデータに追加のユーザデータ又はインデックスを格納できるようにし得る。単一トランザクション内に格納できる最大データ容量に対する予め指定された限度は存在しない。従って、より複雑なデータを組み込むことができる。例えば、これは、ブロックチェーン内に電子文書（electronic document）、或いはオーディオ若しくはビデオデータを格納するために使用され得る。

【0004】

ブロックチェーンネットワークのノード（「マイナー」と呼ばれることがある）は、以下に説明する分散型トランザクション登録及び検証処理を実行する。つまり、この処理の間、ノードは、トランザクションの妥当性確認を行い、それらをブロックテンプレートに挿入し、それに対して有効なproof-of-work解を特定しようと試みる。有効な解が見付かると、新しいブロックはネットワークの他のノードへと伝播され、それにより、各ノードがブロックチェーンに新しいブロックを記録できるようになる。トランザクションをブロックチェーンに記録させるために、ユーザ（例えば、ブロックチェーンクライアントアプリケーション）は、伝播させるために、ネットワークのノードの１つにトランザクションを送信する。トランザクションを受信したノードは、proof-of-work解を見付けるために競争し、妥当性確認されたトランザクションを新しいブロックに組み込む。各ノードは、トランザクションが有効であるための１つ以上の条件を含む同じノードプロトコルを実施するよう構成される。無効なトランザクションは、伝播されず、ブロックに組み込まれることもない。トランザクションが妥当性確認され、それによってブロックチェーンに受け入れられたと仮定すると、（任意のユーザデータを含む）トランザクションは、従って、不変の公開レコードとしてブロックチェーンネットワークの各ノードに登録されインデックスされたままである。

【0005】

最新のブロックを生成するためにproof-of-workパズルを解くことに成功したノードは、標準的に、デジタルアセットの新しい量、つまりトークンの数を生成する「コインベーストランザクション（coinbase transaction）」と呼ばれる新しいトランザクションにより報酬を受ける。無効なトランザクションの検出及び拒否は、ネットワークのエージェントとして動作し及び不法行為を報告及び阻止するよう奨励される競合ノードの動作により実施される。情報の広範な公開により、ユーザはノードの性能を継続的に監査できる。単なるブロックヘッダの公開により、参加者はブロックチェーンの現下の完全性を保証できる。

【0006】

「アウトプットベースの」モデル（UTXOに基づくモデルと呼ばれることもある）では、所与のトランザクションのデータ構造は、１つ以上のインプット及び１つ以上のアウトプットを含む。任意の使用可能アウトプットは、先行するトランザクションシーケンスから導出可能なデジタルアセットの量を指定する要素を含む。使用可能アウトプットは、時にUTXO（unspent transaction output、未使用トランザクションアウトプット）と呼ばれる。アウトプットは、アウトプットの将来の償還（redemption）のための条件を指定するロックスクリプトを更に含んでよい。ロックスクリプトは、デジタルトークン又はアセットを妥当性確認し及び移転するために必要な条件を定義する述部（predicate）である。（コインベーストランザクション以外の）トランザクションの各インプットは、先行するトランザクション内のそのようなアウトプットへのポインタ（つまり参照）を含み、ポイントされたアウトプットのロックスクリプトをアンロックするためのアンロックスクリプトを更に含んでよい。従って、トランザクションのペアを考えるとき、それらを、第１トランザクション及び第２トランザクション（又は「ターゲット」トランザクション）と呼ぶ。第１トランザクションは、デジタルアセットの量を指定する、及びアウトプットをアンロックする１つ以上の条件を定義するロックスクリプトを含む、少なくとも１つのアウトプットを含む。第２ターゲットトランザクションは、第１トランザクションのアウトプットへのポインタと、第１トランザクションのアウトプットをアンロックするためのアンロックスクリプトとを含む、少なくとも１つのインプットを含む。

【0007】

このようなモデルでは、第２ターゲットトランザクションがブロックチェーンで伝播され記録されるブロックチェーンネットワークに送られるとき、各ノードで適用される有効性の基準の１つは、アンロックスクリプトが第１トランザクションのロックスクリプトで定義された１つ以上の条件の全てを満たすことである。もう１つは、第１トランザクションのアウトプットが、別の前の有効なトランザクションによって未だ償還されていないことである。これらの条件のうちのいずれかに従いターゲットトランザクションが無効であると分かった任意のノードは、該トランザクションを（有効なトランザクションとして）伝播させず（しかし、無効なトランザクションを登録する場合がある）、ブロックチェーンに記録させるために新しいブロックに含めることもしない。

【0008】

トランザクションモデルの代替のタイプは、アカウントに基づくモデルである。この場合、各トランザクションは、過去の一連のトランザクションにおいて、先行するトランザクションのUTXOに戻って参照することによって移転される量を定義するのではなく、絶対的な口座（アカウント）残高を参照することによって移転される。全てのアカウントの現在の状態は、ブロックチェーンと分離してノードによって保管され、絶えず更新される。

【0009】

現在の研究の一分野は、「スマートコントラクト」の実装のためのブロックチェーンに基づくコンピュータプログラムの使用である。これらは、機械可読コントラクト又は合意の条項の実行を自動化するよう設計されたコンピュータプログラムである。自然言語で記述される伝統的なコントラクトと異なり、スマートコントラクトは、結果を生成するためにインプットを処理できるルールを含む機械実行可能プログラムであり、これは次に該結果に依存して動作を実行させる。別の領域のロックチェーンに関連する関心事項は、ブロックチェーンを介して現実世界のエンティティを表現し及び移転するための、「トークン」（又は「カラードコイン（coloured coin）」）の使用である。潜在的に極秘の又は秘密のアイテムは、識別可能な意味又は値を有しないトークンにより表すことができる。従って、トークンは、現実世界のアイテムがブロックチェーンから参照されることを可能にする識別子として機能する。

【0010】

上記の例又はシナリオは、イベントの永続的な耐タンパー性レコードを提供するためにブロックチェーンの利点を利用しながら、クライアント、クライアントエンティティ、コンピューティング装置、又はクライアントに関連付けられている端末に、ソフトウェア又はハードウェア、又はプロセッサ／モジュール、例えば、BSV（Bitcoin Satoshi's Vision）ブロックチェーンで使用される楕円曲線デジタル署名アルゴリズム（Elliptic Curve Digital Signature Algorithm （ECDSA））の暗号化鍵を管理し、デジタル資産（digital asset）を管理するための機能を実装するデジタルウォレットなどを含めるか、実装する必要がある。更に、クライアント装置がブロックチェーントランザクション構築を実装でき、BSVライブラリにアクセスできる必要がある。従って、クライアントは、そのような機能を実装するための処理を含める必要があるだけでなく、スマートコントラクト又は現実世界のアセットトランザクションを表すトークンに関連するデータ及び／又はデジタルアセットを送信、受信、及び閲覧するためにブロックチェーンネットワークを利用する前に、そのようなプロセスのために適切なセキュリティ対策が実装されていることを確認する必要がある。

【発明の概要】

【0011】

第１態様によると、コンピュータにより実施される方法であって、
所定の値を取得するステップと、
要求を受信するステップであって、前記要求は委任された認可トークンのチェーンの第１委任された認可トークンを含む、ステップと、
前記委任された認可トークンのチェーンの更なる委任された認可トークンを生成するステップであって、前記委任された認可トークンのチェーンの中の更なる委任された認可トークンの各々の生成は、前記委任された認可トークンのチェーンの中の先行する委任された認可トークンに基づく、ステップと、
前記委任された認可トークンのチェーンの中の委任された認可トークンの１つと前記所定の値との比較に基づいて、前記第１委任された認可トークンの有効性を決定するステップと、
を含む方法が提供される。

【0012】

第２態様によると、関連する委任された認可トークンのチェーンを生成するための、コンピュータにより実施される方法であって、
第１値及び第２値を取得するステップと、
前記委任された認可トークンのチェーンの第１委任された認可トークンを生成するステップであって、前記第１委任された認可トークンは前記第１値及び前記第２値に基づく、ステップと、
前記委任された認可トークンのチェーンの少なくとも１つの更なる委任された認可トークンを生成するステップであって、前記委任された認可トークンのチェーンの中の更なる委任された認可トークンの各々の生成は、前記委任された認可トークンのチェーンの中の先行する委任された認可トークン及び前記第１値に基づく、ステップと、
を含むコンピュータにより実施される方法が提供される。

【0013】

第３態様によれば、第１態様によるトークンを検証する方法が提供され、第１委任された認可トークンは、第２態様によりクライアントによって生成されたものである。

【0014】

第４態様によれば、方法であって、
第２態様の方法に従って生成された委任された認可トークンを受信するステップと、
前記委任された認可トークンを含む要求を生成するステップと、
前記要求をサーバに送信するステップと、
を含む方法が提供される。

【0015】

第５態様によれば、システムであって、
サーバと、
デリゲートと、
クライアントと、
を含み、
前記クライアントは、第２態様の方法に従って、委任された認可トークンのチェーン及び第１値を生成し、第１値及び前記委任された認可トークンのチェーンの最後の委任された認可トークンをサーバに送信し、前記委任された認可トークンのチェーンの中の委任された認可トークンの１つを前記デリゲートに送信するように構成される、システムが提供される。

【0016】

開示される方法の幾つかの特定のコンポーネント及び実施形態は、添付の図面を参照して例示のためにここで説明される。ここで同様の参照符号は同様の機能を示す。

【図面の簡単な説明】

【0017】

【図1】ブロックチェーンを実装するための例示的なシステムを示す。

【図2】トランザクションプロトコルの例を示している。

【図3A】クライアントアプリケーションとそのユーザインタフェースの実装例を示している。

【図3B】クライアントアプリケーションとそのユーザインタフェースの実装例を示している。

【図4】ネットワークの各ブロックチェーンノードで実行されるノードソフトウェアの例を示している。

【図5】プラットフォームプロセッサ、データベース、ブロックチェーンネットワーク、クライアント及びデリゲートの間の相互作用を示す概略図である。

【図6】委任された認可トークンを生成する方法を示している。

【図7】デリゲートがサービスと相互作用するために必要な情報を配信する方法を示している。

【図8】委任された認可トークンの妥当性を確認する方法を示している。

【図9A】委任された認可トークンの検証に関する例と実施例を示している。

【図9B】委任された認可トークンの検証に関する例と実施例を示している。

【図9C】委任された認可トークンの検証に関する例と実施例を示している。

【図9D】委任された認可トークンの検証に関する例と実施例を示している。

【図10A】イベントストリームサービスとの相互作用の例を示している。

【図10B】イベントストリームサービスとの相互作用の例を示している。

【図10C】イベントストリームサービスとの相互作用の例を示している。

【図10D】イベントストリームサービスとの相互作用の例を示している。

【図10E】イベントストリームサービスとの相互作用の例を示している。

【図11】ある側面に従って、ブロックチェーンに関連付けられた複数のサービスのプラットフォームの概要を示した概略図である。

【図12】ある側面に従って、ブロックチェーンに関連付けられた複数のサービスのプラットフォームのコンポーネントを示した概略図である。

【図13】本開示の種々の態様及び実施形態が実装可能なコンピューティング環境を示す概略図である。

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

【0018】

従って、安全で、複雑さが少なく、ユーザフレンドリで、効率的で、堅牢な技術を実装することが望まれている。これにより、計算が洗練されているかどうかにかかわらず、あらゆるクライアントが、ブロックチェーンに関連する有用なアプリケーションに瞬時にアクセスし、相互作用することができる。これは、計算上も機能上も負担の少ない、簡単で、高速で、正確で、信頼性が高く、安全な方法で行われる。より具体的には、クライアントが承認したデリゲートも、好ましくは安全で、信頼性が高く、及び／又は取り消し可能な方法で、このようなシステムから恩恵を受けることができることが望まれている。

【0019】

このような改良されたソリューションがここで考案された。本開示は、ブロックチェーンに関連する書き込み、読み取り、又はその他の行為のための委任された承認を持つ（及び／又は委任された認可トークンを所有する）ユーザによって、データがブロックチェーンに簡単に、安全に、及び／又は瞬時に書き込まれるか又はブロックチェーンから取得される１つ以上の技術を提案することによって、上記の技術的懸念を解決する。ブロックチェーンに関連する１つ以上のサービス（特にこれらのサービスの委任）のためのアプリケーションプログラミングインタフェース（API）を提供する方法、装置、及びシステムであって、クライアントがブロックチェーンを使用するための処理又は機能、又はユーザ管理のための処理又は機能を実装する必要がなく、ブロックチェーン及びその委任された承認に関連する全ての利点を利用することができる。

【0020】

第１態様によると、コンピュータにより実施される方法であって、
所定の値を取得するステップと、
要求を受信するステップであって、前記要求は委任された認可トークンのチェーンの第１委任された認可トークンを含む、ステップと、
前記委任された認可トークンのチェーンの更なる委任された認可トークンを生成するステップであって、前記委任された認可トークンのチェーンの中の更なる委任された認可トークンの各々の生成は、前記委任された認可トークンのチェーンの中の先行する委任された認可トークンに基づく、ステップと、
前記委任された認可トークンのチェーンの中の委任された認可トークンの１つと前記所定の値との比較に基づいて、前記第１委任された認可トークンの有効性を決定するステップと、
を含む方法が提供される。

【0021】

第１態様の方法を実施する１つ又は複数の装置は、委任された認可トークンを検証するので、バリデータ（validator）とみなすことができる。有利なことに、バリデータに所定の値を提供するだけで、バリデータは、受け取った任意の委任された認可トークンを検証することができるので、最小限のデータ共有しか必要としない安全な認可システムを提供し、従って、攻撃対象領域をより小さくする。より小さな攻撃対象領域は、全体的により高いセキュリティシステムを意味する。利点として、バリデータは検証する委任されたユーザの番号やIDを知る必要がないため、クライアントとデリゲートのプライバシが向上する。

【0022】

必要に応じて、生成は委任されたトークンのチェーンの中の先行する委任された認可トークンのハッシュに基づいている。

【0023】

任意で、委任された認可トークンのチェーンの更なる委任された認可トークンを生成するステップは、更なる委任された認可トークンの各々について、
中間プレイメージを決定するステップであって、中間プレイメージは、委任された認可トークンのチェーンの中の先行する委任された認可トークンに基づくものである、ステップと、
中間プレイメージに一方向関数を適用するステップであって、一方向関数への出力は、更なる委任された認可トークンである、ステップと、
を実行することを含む。好ましくは、一方向関数はハッシュ関数である。好ましくは、中間プレイメージは、所与の値に更に基づく。

【0024】

有利なことに、一方向関数を使用して委任された認可トークンを決定することは、システムのいずれのメンバーも、現在の委任された認可トークンからチェーンの上位にある委任された認可トークンを計算できないことを意味する。

【0025】

有利なことに、プレイメージが所与の値（以下で初期値として説明する）に基づくことにより、当該所与の値がなければ、システムのどのメンバーも、チェーンの上位にある他の委任された認可トークンを計算することができない。所与の値は、第１実施形態の方法を実行する装置以外のいかなる他の装置にも提供されず、それにより、改ざん耐性及び悪意のある者による攻撃に対する回復力を高める。

【0026】

任意で、更なる委任された認可トークンの生成は、委任された認可トークンのチェーンの中の先行する委任された認可トークン及び所与の値に基づく。

【0027】

任意で、方法は、記憶装置から所与の値を取得するステップ、を更に含む。任意で、所定の値はクライアントから受信されたものである。

【0028】

任意で、生成は、所与の値と先行する委任された認可トークンの連結に基づく。望ましくは、生成は、所与の値と委任された認可トークンのチェーンの中の委任された認可トークンとの連結のハッシュに基づく。

【0029】

有利なことに、一方向関数と所与の値の使用の組み合わせは、委任された認可トークンを持つユーザが、委任された認可トークンのチェーンの中の他の委任された認可トークンを計算することを禁止する（これにより、追加のセキュリティを提供する）と同時に、委任された認可トークンを検証する検証サービスを有効にし、有効なトークンを全て送信する必要がない。クライアント又は他の装置が、この第１態様による方法を実行しているバリデータに有効なトークンを送信する必要がなくなることにより、サードパーティが有効なトークンを取得する可能性が再び減少し、システム全体のセキュリティが向上する。

【0030】

任意で、要求は、インデックス番号を更に含み、委任された認可トークンのチェーンの中の委任された認可トークンの数は、インデックス番号に基づく。任意で、インデックスは、クライアントが生成した最後の委任された認可トークンからの距離を表すことができる。

【0031】

デリゲートが彼らの要求に含めるためにインデックスが使用され提供される場合は、敵対的なサードパーティがハッシュとインデックスの２つの情報を知っている必要がある、より高いセキュリティシステムが提供される。サービスが要求を処理するには、両方が正しい必要がある。

【0032】

代替として、インデックスが使用されない。インデックスが使用されない又はデリゲートに提供されない場合、有利なことに、クライアントはチェーンの中の自分の位置を認識しないため、他のデリゲートの数を特定できず、妥当性確認される全てのクライアントとユーザのプライバシが向上する。

【0033】

任意で、第１委任された認可トークンの有効性を決定するステップは、委任された認可トークンのチェーンの中の最後の委任された認可トークンと所定の値との比較に基づく。

【0034】

任意で、第１委任された認可トークンの有効性を決定するステップは、委任された認可トークンのチェーンの中の最後の委任された認可トークンと所定の値とを比較するステップであって、同じ値を有する、ステップを含む。

【0035】

任意で、要求は、ブロックチェーンへの送信又はブロックチェーンからの読み取りである。

【0036】

任意で、要求に含まれるデータの表現がブロックチェーンに記録されるように、ブロックチェーンベースのデータ記録サービスにデータを送信する。更に又は代替として、要求はブロックチェーンベースのデータ記録サービスからデータの表現を読み取ることである。好ましくは、データを読み取る要求は、読み取るべきデータへの参照を含む。好ましくは、ブロックチェーンベースのデータ記録サービスは、本明細書に記載されるように、プラットフォームサービスの一部である。

【0037】

有利なことに、ブロックチェーンベースのデータ記録サービスは、商品データ台帳としてのブロックチェーンの使用を簡素化する方法を提供する。更に、委任された認可トークンは、ブロックチェーンベースのデータ記録サービスに強化されたセキュリティを提供する。従って、ブロックチェーンベースのデータ記録サービスの委任されたユーザは、ブロックチェーンと相互作用し、安全な方法でデータストレージのニーズのためにブロックチェーンの特性（不変性、分散性、任意的な透明性、トレーサビリティなど）を利用することができるが、必ずしもトランザクション又はブロックチェーン自体との直接相互作用を必要としない。

【0038】

必要に応じて、要求の有効性を決定するには、同じ第１委任された認可トークンを構成する以前に受信した要求の数に更に基づいている。

【0039】

有利なことに、これにより、クライアントはシステムを細かく制御し、悪意のあるアクターがスパムを送信する能力を制限できる。或いは、悪意のある第３者が有効な委任された認可トークンを取得した場合、システム全体のセキュリティを向上させるために、発生する可能性のある損害に制限が加えられる。

【0040】

好ましくは、所定の値は、クライアントが生成した委任された認可トークンである。好ましくは、所定の値は、クライアントが生成した委任された認可トークンのチェーンの中の最後の委任された認可トークンである。好ましくは、所定の値は、受信すると、委任された認可トークンの格納されたチェーンに格納される。

【0041】

任意で、本方法は、第１委任された認可トークンの有効性に基づいて、委任された認可トークンのチェーンを格納するステップを更に含む。望ましくは、方法は、更なる委任された認可トークンを含む更なる要求を受信するステップと、
更なる委任された認可トークンが格納された委任された認可トークンのチェーンに存在するかどうかに基づいて、更なる委任された認可トークンの有効性を決定するステップと、
更なる委任された認可トークンの有効性に基づいて更なる要求を処理するステップと、
を更に含む。

【0042】

中間ハッシュ結果が記録され、有利なことに、その後の検証のための処理時間が削減される。トークンが既に受信したものよりも低いインデックス（つまり、最終的な委任された認可トークン又はH_０に近い）と共に受信された場合、ハッシュを実行する必要はなく、コンピュータの処理時間と電力が節約される。

【0043】

任意で、所定の値は、委任された認可トークンの格納されたチェーンの最も高いインデックスを持つ委任された認可トークンである。好ましくは、最後の委任された認可トークンが生成されるまで、更なる委任された認可トークンを生成するステップが行われる。

【0044】

任意で、本方法は、委任された認可トークンの格納されたチェーンの最高インデックスを決定し、最高インデックスと等しいインデックスを有する委任された認可トークンが生成されるまで、受信した委任された認可トークンに基づいて更なる委任された認可トークンを生成し、最終的に生成された委任された認可トークンと、最高インデックスを有する格納された委任された認可トークンとの比較に基づいて、受信した委任された認可トークンの有効性を決定することを更に含む。

【0045】

任意で、各委任された認可トークンがそれに関連付けられたインデックスを有し、インデックスにおいて最後の委任された認可トークンからの距離を表すことができる場合、各委任された認可トークンは、その関連付けられたインデックスと共に格納され、好ましくは、インデックスによって検索することができる。各委任された認可トークンをそのインデックスによって格納することにより、有利なことに、任意のトークンの存在を検索することは、データセットを反復処理して各値を比較するよりも、インデックスによる検索及び／又はインデックスでの検索の方が迅速かつ計算リソースを消費しないため、より多くの時間と計算リソースを効率的にする。

【0046】

任意で、方法は、要求の有効性の指示を提供するステップと、及び／又は、
委任された認可トークンの有効性に基づいて、要求を処理するステップと、
を更に含む。好ましくは、処理とは、要求の転送、要求の廃棄、要求の許可、要求のブロック、ブロックチェーンに基づくストレージシステムへのアクセスの許可、ブロックチェーンに基づくストレージシステムへの読み取りアクセスの許可、ブロックチェーンに基づくストレージシステムへの書き込みアクセスの許可、ブロックチェーンに基づくストレージシステムからのデータの要求に基づく提供、及び／又はブロックチェーンに基づくストレージシステムへのデータの要求に基づく書き込み、のいずれか１つ以上を意味する。

【0047】

第２態様によると、関連する委任された認可トークンのチェーンを生成するための、コンピュータにより実施される方法であって、
第１値及び第２値を取得するステップと、
前記委任された認可トークンのチェーンの第１委任された認可トークンを生成するステップであって、前記第１委任された認可トークンは前記第１値及び前記第２値に基づく、ステップと、
前記委任された認可トークンのチェーンの少なくとも１つの更なる委任された認可トークンを生成するステップであって、前記委任された認可トークンのチェーンの中の更なる委任された認可トークンの各々の生成は、前記委任された認可トークンのチェーンの中の先行する委任された認可トークン及び前記第１値に基づく、ステップと、
を含むコンピュータにより実施される方法が提供される。

【0048】

第２態様による方法を実行する１つ以上の装置は、通常、クライアントであり、クライアントは、自身のアクセスをデリゲート又は委任されたユーザに委任する。

【0049】

任意で、委任された認可トークンのチェーンの更なる委任された認可トークンを生成するステップは、更なる委任された認可トークンの各々について、以下：
中間プレイメージを決定するステップであって、中間プレイメージは、委任された認可トークンのチェーンの中の先行する委任された認可トークン及び第１値に基づくものである、ステップと、
中間プレイメージに一方向関数を適用するステップであって、一方向関数への出力は、更なる委任された認可トークンである、ステップと、
を実行することを含む。好ましくは、一方向関数はハッシュ関数である。好ましくは、中間プレイメージは、所与の値に更に基づく。

【0050】

方法は、セキュリティ及び第１態様に関連して議論されたようなより多くのことに関連した同じ又は類似の利点を提供する。

【0051】

望ましくは、生成は、所与の値と委任された認可トークンのチェーンの中の委任された認可トークンとの連結のハッシュに基づく。

【0052】

任意で、委任された認可トークンのチェーンの委任された認可トークンの１つをデリゲート装置に提供するステップ、を更に含む。望ましくは、デリゲート装置は、委任された認可トークンのインデックスを更に提供され、インデックスは、提供された委任された認可トークンが委任された認可トークンのチェーンの中のどこにあるかを表す。

【0053】

任意で、第１値及び委任された認可トークンのチェーンの最後の委任された認可トークンを検証装置に提供するステップ、を更に含む。望ましくは、検証装置は、更に、デリゲート当たりの読み取り又は書き込みの最大数を示す数を提供される。

【0054】

任意で、委任された認可トークンのチェーンの中の委任された認可トークンの数は、インデックス番号に基づく。望ましくは、委任された認可トークンのチェーンの中の委任された認可トークンの数は、デリゲートの数に等しい。

【0055】

第１態様に関して上述したように、任意で、委任された認可トークンはデリゲートに提供され、デリゲートが（好ましくは、ブロックチェーンベースのデータ記録サービスへのデータの書き込み又はデータの読み取りによって）相互作用できるようにする。

【0056】

従って、上記の委任された認可トークンがブロックチェーンベースのデータ記録サービスにアクセスするときにセキュリティを強化することによって、同じ又は類似の利点が適用される。従って、ブロックチェーンベースのデータ記録サービスの委任されたユーザは、ブロックチェーンと対話し、安全な方法でデータストレージのニーズのためにブロックチェーンの特性（不変性、分散性、任意的な透明性、トレーサビリティなど）を利用することができるが、必ずしもトランザクション又はブロックチェーン自体との直接対話を必要としない。

【0057】

必要に応じて、第１委任された認可トークンが生成された後、第２値が削除される。

【0058】

有利なことに、第２値を削除することによって、誰も第１委任された認可トークンを構築することができず、従ってチェーン全体を構築することができないため、悪意のある第３者がトークンを再生成する機会を排除することによって、セキュリティが向上する。

【0059】

任意で、第１値と第２値はランダムに生成される。

【0060】

好ましくは、第１態様又は第２態様の先行する委任された認可トークンは、生成されている委任された認可トークンの直前の委任された認可トークンを表す。これは、生成又は取得された最新の委任された認可トークンであってもよい。

【0061】

第３態様によれば、第１態様によるトークンを検証する方法が提供され、第１委任された認可トークンは、第２態様によりクライアントによって生成されたものである。

【0062】

第４の態様によれば、方法であって、
第２態様の方法に従って生成された委任された認可トークンを受信するステップと、
前記委任された認可トークンを含む要求を生成するステップと、
前記要求をサーバに送信するステップと、
を含む方法が提供される。

【0063】

第５の態様によれば、システムであって、
サーバと、
デリゲートと、
クライアントと、
を含み、
クライアントは、第２態様の方法に従って、委任された認可トークンのチェーン及び第１値を生成し、第１値及び前記委任された認可トークンのチェーンの最後の委任された認可トークンをサーバに送信し、委任された認可トークンのチェーンの中の委任された認可トークンの１つをデリゲートに送信するように構成される、システムが提供される。

【0064】

任意で、サーバは、第１態様の方法に従って、デリゲートからの要求を受信し、処理するように構成される。

【0065】

上記の態様の１つ以上に従って、任意で、要求は、クライアント及び／又は委任されたユーザからHTTPSプロトコルを介して又はHTTPSプロトコルを使用して受信される。更に又は代替として、要求の受信者は、WebサービスとしてAPIを実装する。任意で、委任された認可トークンは、イベントストリームおよ／又はデータ書き込みサービスへの委任されたアクセスを提供するように構成される。有利なことに、HTTPS及び／又はAPI及び／又はWebサービスの使用は、Web要求の受信者が柔軟なブロックチェーンベースのデータサービスを提供できるようにしながら、補完的なセキュリティ機能を提供する。ブロックチェーンベースのデータ書き込み部又は読み出し部への委任されたアクセスを提供することの更なる利点には、第１クライアントだけでなく、より多くのユーザが、ブロックチェーンベースのデータ書き込み又は読み出しサービスへのアクセスを持つことを（安全な方法で）可能にすることが含まれる。

【0066】

＜例示的なシステムの概要＞
図１は、ブロックチェーン１５０を実装するための例示的なシステム１００を示す。システム１００は、典型的にはインターネットのような広域インターネットワークであるパケット交換ネットワーク１０１を含んでよい。パケット交換ネットワーク１０１は、パケット交換ネットワーク１０１内にピアツーピア（P２P）ネットワーク１０６を形成するように配置され得る複数のブロックチェーンノード１０４を含む。図示されないが、ブロックチェーンノード１０４は、ほぼ完全なグラフとして配置されてよい。各ブロックチェーンノード１０４は、従って、他のブロックチェーンノード１０４と高度に結合される。

【0067】

各ブロックチェーンノード１０４は、異なるピアに属するノード１０４のうちの異なるノード１０４を有す、ピアのコンピュータ装置を含む。各ブロックチェーンノード１０４は、１つ以上のプロセッサ、例えば、１つ以上の中央処理装置（CPU）、アクセラレータプロセッサ、特定用途向けプロセッサ、及び／又はフィールドプログラマブルゲートアレイ（FPGA）、及び特定用途向け集積回路（ASIC）のような他の機器を含む処理装置を含む。各ノードは、メモリ、すなわち、非一時的コンピュータ読み取り可能媒体の形態のコンピュータ読み取り可能記憶装置も含む。メモリは、１つ以上のメモリ媒体、例えば、ハードディスクなどの磁気媒体、固体ドライブ（solid-state drive （SSD））、フラッシュメモリ又はEEPROMなどの電子媒体、及び／又は光ディスクドライブなどの光学媒体を使用する１つ以上のメモリユニットを含んでもよい。

【0068】

ブロックチェーン１５０は、データのブロック１５１のチェーンを含み、ブロックチェーン１５０の各々のコピーは、分散型又はブロックチェーンネットワーク１６０内の複数のノード１０４の各々において維持される。上述のように、ブロックチェーン１５０のコピーを維持することは、必ずしも、ブロックチェーン１５０全体を格納することを意味しない。代わりに、各ブロックチェーンノード１５０が各ブロック１５１のブロックヘッダ（後述する）を格納する限り、ブロックチェーン１５０からデータを取り除くことができる。チェーン内の各ブロック１５１は、１つ以上のトランザクション１５２を含み、この文脈ではトランザクションは、一種のデータ構造を表す。データ構造の性質は、トランザクションモデル又はスキームの一部として使用されるトランザクションプロトコルのタイプに依存する。所与のブロックチェーンは、全体を通して、１つの特定のトランザクションプロトコルを使用する。１つの一般的なタイプのトランザクションプロトコルでは、各トランザクション１５２のデータ構造は、少なくとも１つのインプット及び少なくとも１つのアウトプットを含む。各アウトプットは、資産としてのデジタルアセットの量を表す量を指定する。この例では、アウトプットが暗号的にロックされているのはユーザ１０３である（ロックを解除し、それによって償還又は使用するために、そのユーザの署名又は他の解を必要とする）。各インプットは、先行するトランザクション１５２のアウトプットを指し示し、それによって、トランザクションをリンクする。

【0069】

各ブロック１５１は、また、ブロック１５１への逐次的順序を定義するように、チェーン内の先に生成されたブロック１５１を遡ってポイントするブロックポインタ１５５を含む。（コインベーストランザクション以外の）各トランザクション１５２は、トランザクションのシーケンスに順序を定義するために、前のトランザクションへのポインタを含む（注：トランザクション１５２のシーケンスは、分岐することが許される）。ブロック１５１のチェーンは、チェーンの第１ブロックであったジェネシスブロック（genesis block （Gb））１５３にまで戻る。チェーン１５０の初期に１つ以上のオリジナルトランザクション１５２は、先行するトランザクションではなくジェネシスブロック１５３を指し示した。

【0070】

ブロックチェーンノード１０４の各々はトランザクション１５２を他のブロックチェーンノード１０４へ転送し、それにより、ネットワーク１０６に渡りトランザクション１５２を伝播させるよう構成される。各ブロックチェーンノード１０４は、ブロック１５１を生成し、同じブロックチェーン１５０の各々のコピーを自身の各々のメモリに格納するよう構成される。各ブロックチェーンノード１０４はまた、ブロック１５１に組み込まれるのを待つトランザクション１５２の順序付きセット１５４を維持する。順序付きセット１５４は、時に「メモプール（mempool）」と呼ばれる。この用語は、本願明細書では、任意の特定のブロックチェーン、プロトコル、又はモデルに限定されない。それは、ノード１０４が有効であるとして受け付けた、及びノード１０４が同じアウトプットを使用しようと試みる他のトランザクションを受け付けないよう義務付けられたトランザクションの順序付きセットを表す。

【0071】

所与の現在のトランザクション１５２jにおいて、インプット（又はその各々）は、トランザクションのシーケンスの中の先行トランザクション１５２iのアウトプットを参照するポインタを含み、このアウトプットが現在のトランザクション１５２jにおいて償還されるか又は「使用される（spent）」ことを指定する。一般に、先行するトランザクションは、順序付きセット１５４又は任意のブロック１５１内の任意のトランザクションであり得る。先行するトランザクション１５２iは、必ずしも、現在のトランザクション１５２jが生成された又はネットワーク１０６へ送信されたときに存在する必要はないが、先行するトランザクション１５２iは、現在のトランザクションが有効であるために存在し妥当性確認されている必要がある。従って、本願明細書で「先行する」は、ポインタによりリンクされた論理的シーケンスの中で先行するものを表し、必ずしも時系列の中での生成又は送信の時間を表さない。従って、それは、必ずしも、トランザクション１５２i,１５２jが順不同で生成され又は送信されることを排除しない（以下の親のない（orphan）トランザクションに関する議論を参照する）。先行するトランザクション１５２iは、等しく、祖先（antecedent）又は先行（predecessor）トランザクションと呼ばれ得る。

【0072】

現在のトランザクション１５２jのインプットは、インプット認可、例えば先行するトランザクション１５２iのアウトプットがロックされているユーザ１０３aの署名も含む。次に、現在のトランザクション１５２jのアウトプットは、新しいユーザ又はエンティティ１０３bに暗号的にロックすることができる。従って、現在のトランザクション１５２jは、先行するトランザクション１５２iのインプットに定義された量を、現在のトランザクション１５２jのアウトプットに定義された新しいユーザ又はエンティティ１０３bに移転することができる。ある場合には、トランザクション１５２は、複数のユーザ又はエンティティ間でインプット量を分割するために複数のアウトプットを有してもよいエンティティ（そのうちの１つは、お釣りを与えるために、元のユーザ又はエンティティ１０３aであってもよい）。幾つかの場合には、トランザクションが複数のインプットを有し、１つ以上の先行するトランザクションの複数のアウトプットから量をまとめ、現在のトランザクションの１つ以上のアウトプットに再分配することもできる。

【0073】

ビットコインのようなアウトプットに基づくトランザクションプロトコルによると、ユーザ又はマシンのようなエンティティ１０３は、新しいトランザクション１５２jに作用したいとき、エンティティは新しいトランザクションを自身のコンピュータ端末１０２から受信側へ送信する。エンティティ又は受信側は、結局、このトランザクションをネットワーク１０６のブロックチェーンノード１０４のうちの１つ以上（これらは、今日では、標準的にサーバ又はデータセンタであるが、原理的に他のユーザ端末も可能である）へと送信する。幾つかの例では、新しいトランザクション１５２jに作用するエンティティ１０３が、トランザクションを、受信側ではなくブロックチェーンノード１０４のうちの１つ以上へと送信し得ることも排除されない。トランザクションを受信するブロックチェーンノード１０４は、各ブロックチェーンノード１０４に適用されるブロックチェーンノードプロトコルに従って、トランザクションが有効であるかどうかをチェックする。ブロックチェーンノードプロトコルは、典型的には、ブロックチェーンノード１０４に、新しいトランザクション１５２j内の暗号署名が、トランザクション１５２の順序付きシーケンスの中の前のトランザクション１５２iに依存する、期待される署名と一致することをチェックすることを要求する。このようなアウトプットに基づくトランザクションプロトコルの場合、これは、新しいトランザクション１５２jのインプットに含まれるエンティティ１０３の暗号署名又は他の認証が、新しいトランザクションが割り当てる先行するトランザクション１５２jのアウトプットに定義された条件と一致することをチェックすることを含んでよく、この条件は、典型的には、新しいトランザクション１５２jのインプット内の暗号署名又は他の認証が、新しいトランザクションのインプットがリンクされた前のトランザクション１５２iのアウトプットをアンロックすることを少なくともチェックすることを含む。条件は、先行するトランザクション１５２iのアウトプットに含まれるスクリプトにより少なくとも部分的に定義されてよい。或いは、単にブロックチェーンノードプロトコルだけで固定することもできるし、或いは、これらの組み合わせによることもある。いずれにせよ、新しいトランザクション１５２jが有効であれば、ブロックチェーンノード１０４は、新しいトランザクションをブロックチェーンネットワーク１０６内の１つ以上の他のブロックチェーンノード１０４に転送する。これらの他のブロックチェーンノード１０４は、同じノードプロトコルに従って同じテストを適用し、新しいトランザクション１５２jを１つ以上の更なるノード１０４に転送し、以下で同様である。このようにして、新しいトランザクションは、ブロックチェーンノード１０４のネットワーク全体に伝播される。

【0074】

アウトプットベースのモデルでは、与えられ割り当てアウトプット（例えば、UTXO）が割り当てられるかどうかの定義は、ブロックチェーンノードプロトコルに従って別の今後の（onward）トランザクション１５２jのインプットによって既に有効に償還されているかどうかである。トランザクションが有効であるための別の条件は、それが割り当て又は償還を試みる先行するトランザクション１５２iのアウトプットが、別のトランザクションによって未だ割り当て／償還されていことである。ここでも、有効でない場合、トランザクション１５２jは、（無効であるとしてフラグが立てられ変更するために伝播されない限り）ブロックチェーン１５０に伝播又は記録されない。これは、取引者が同じトランザクションのアウトプットを複数回割り当てようとする二重支出を防ぐ。一方、アカウントベースモデルは、口座残高を維持することによって、二重支出を防ぐ。この場合も、トランザクションの順序が定義されているため、口座残高は、一度に単一の定義された状態を有する。

【0075】

妥当性確認トランザクションに加えて、ブロックチェーンノード１０４は、また、「proof -of -work」により支えられているマイニングと呼ばれるプロセスで、トランザクションのブロックを最初に作成するために競合する。ブロックチェーンノード１０４では、ブロックチェーン１５０に記録されたブロック１５１に未だ現れていない有効なトランザクションの順序付きセット１５４に新しいトランザクションが追加される。ブロックチェーンノードは、次に、暗号パズルを解くことを試みることにより、トランザクションの順序付きセット１５４からトランザクション１５２の新しい有効なブロック１５１を組み立てるために競争する。これは、典型的には、ノンス（nonce）がトランザクションの順序付きセット１５４の表現と連結され、ハッシュされるときに、ハッシュのアウトプットが所定の条件を満たすような「ノンス」値を探すことを含む。例えば、所定の条件は、ハッシュのアウトプットが、所定の数の先頭ゼロを有することであってもよい。これは、単に１つの特定の種類のproof-of-workパズルであり、他の種類が排除されないことに留意する。ハッシュ関数の特性は、インプットに関して予測不可能なアウトプットを持つことである。従って、この探索は、ブルートフォースによってのみ実行することができ、従って、パズルを解決しようとしている各ブロックチェーンノード１０４において、相当量の処理リソースを消費する。

【0076】

パズルを解いた第１ブロックチェーンノード１０４は、これをネットワーク１０６に通知し、その解を証明として提供する。この解は、ネットワーク内の他のブロックチェーンノード１０４によって簡単にチェックすることができる（ハッシュに対する解が与えられれば、ハッシュのアウトプットが条件を満たすことを確認することは簡単である）。第１ブロックチェーンノード１０４は、該ブロックを受け入れる閾値の他のノードの合意に、ブロックを伝播させ、従ってプロトコルルールを実施する。トランザクションの順序付きセット１５４は、次に、ブロックチェーンノード１０４の各々により、ブロックチェーン１５０内の新しいブロック１５１として記録されるようになる。また、新しいブロック１５１nにはブロックポインタ１５５が割り当てられ、チェーン内で前に作成されたブロック１５１n-１を指すようになっている。proof-of-work解を生成するために必要とされる例えばハッシュの形式の有意な量の労力が、ブロックチェーンプロトコルのルールに従うという第１ノード１０４の意図をシグナリングする。そのようなルールは、前に妥当性確認されたトランザクションと同じアウトプットを割り当てる場合に有効としてトランザクションを受け付けないこと、或いは二重支払いとして知られいることを含む。一旦生成されると、ブロック１５１は、ブロックチェーンネットワーク１０６内のブロックチェーンノード１０４の各々で認識され、維持されるので、修正することができない。また、ブロックポインタ１５５は、ブロック１５１に順序を課す。トランザクション１５２は、ネットワーク１０６内の各ブロックチェーンノード１０４において順序付きブロックに記録されるので、これは、トランザクションの不変の公開台帳を提供する。

【0077】

パズルを解決するために常に競争している異なるブロックチェーンノード１０４は、いつ解を探し始めたか、又はトランザクションが受信された順序によって、いつでも未だ公開されていないトランザクションの順序付きセット１５４の異なるスナップショットに基づいてパズルを解いているかもしれないことに留意する。パズルを解く者は誰でも、最初に次の新しいブロック１５１nに含まれるトランザクション１５２を定義し、その順序で、未公開のトランザクションの現在のセット１５４が更新される。そして、ブロックチェーンノード１０４は、新たに定義された未公開トランザクションの現在の順序付きセット１５４からブロックを作り出すために、競争を続ける。また、生じ得る「分岐（フォーク、fork）」を解決するためのプロトコルも存在する。これは、２つのブロックチェーンノード１０４が互いに非常に短い時間内にパズルを解き、ブロックチェーンの矛盾したビューがノード１０４の間で伝播する場合である。要するに、分岐の枝が伸びるときは常に、最長のものが最終的なブロックチェーン１５０になる。これは、同じトランザクションが両方の分岐に現れるので、ネットワークのユーザ又はエージェントに影響しないことに留意する。

【0078】

ビットコインブロックチェーン（及び殆どの他のブロックチェーン）によると、新しいブロック１０４を構成するのに成功したノードは、デジタルアセットの所定量を分配する新しい特別な種類のトランザクションの中でデジタルアセットの承認された量を割り当てる能力を与えられる（１人のエージェント又はユーザから別のエージェント又はユーザへとデジタルアセットの量を移転するエージェント間又はユーザ間トランザクションと異なる）。この特別な種類のトランザクションは、通常、「コインベーストランザクション」と呼ばれるが、「開始（initiation）トランザクション」とも呼ばれることがある。それは標準に新しいブロック１５１nの第１トランザクションを形成する。proof-of-workは、この特別なトランザクションが後に償還できるように、新しいブロックを構成したノードがプロトコルルールに従うことを意図していることをシグナリングする。ブロックチェーンプロトコルルールは、この特別なトランザクションが償還できる前に、満期、例えば１００ブロックを必要としてよい。通常の（非生成）トランザクション１５２は、そのアウトプットの１つに追加のトランザクション料を指定し、そのトランザクションが公開されたブロック１５１nを生成したブロックチェーンノード１０４に更に報酬を与えることが多い。この手数料は、通常、「トランザクション料」と呼ばれ、後述する。

【0079】

トランザクションの妥当性確認及び公開に関連するリソースのために、典型的には、少なくともブロックチェーンノード１０４の各々は、１つ以上の物理的サーバユニットを含むサーバ、又はデータセンタ全体の形態をとる。しかしながら、原理的に、任意の所与のブロックチェーンノード１０４は、ユーザ端末又は互いにネットワーク接続されたユーザ端末又はユーザ端末のグループの形態をとることができる。

【0080】

各ブロックチェーンノード１０４のメモリは、各々の１つ以上の役割を実行し、ブロックチェーンノードプロトコルに従ってトランザクション１５２を処理するために、ブロックチェーンノード１０４の処理装置上で動作するように構成されたソフトウェアを記憶する。ブロックチェーンノード１０４に属するいずれの動作も、各々のコンピュータ装置の処理装置上で実行されるソフトウェアによって実行され得ることが理解されよう。ノードソフトウェアは、アプリケーションレイヤにおける１つ以上のアプリケーション、又はオペレーティングシステムレイヤ若しくはプロトコルレイヤのような下位レイヤ、又はこれらの任意の組み合わせの中に実装されてよい。

【0081】

また、ネットワーク１０１には、消費者ユーザの役割を果たす複数のパーティ１０３の各々のコンピュータ装置１０２も接続されている。これらのユーザは、ブロックチェーンネットワークと相互作用できるが、トランザクション及びブロックを妥当性確認し、構成し、又は伝播させることに参加しない。これらのユーザ又はエージェントのうちの一部は、トランザクションにおいて送信側及び受信側として動作してよい。他のユーザは、必ずしも送信側又は受信側として動作することなく、ブロックチェーン１５０と相互作用してよい。例えば、幾つかのパーティは、ブロックチェーン１５０のコピーを格納する（例えば、ブロックチェーンノード１０４からブロックチェーンのコピーを取得した）記憶エンティティとして動作してよい。

【0082】

パーティ１０３の一部又は全部は、異なるネットワーク、例えば、ブロックチェーンネットワーク１０６の上に重ねられたネットワークの部分として結合されてよい。ブロックチェーンネットワークのユーザ（「クライアント」と呼ばれることが多い）は、ブロックチェーンネットワークを含むシステムの部分であると言うことができる。しかしながら、これらのユーザは、ブロックチェーンノードの要求される役割を実行しないので、ブロックチェーンノード１０４ではない。代わりに、各パーティ１０３は、ブロックチェーンネットワーク１０６と相互作用し、それにより、ブロックチェーンノード１０６に結合する（つまり通信する）ことにより、ブロックチェーン１５０を利用してよい。２つのパーティ１０３及び各々の機器１０２は、説明のために示されており、第１パーティ１０３a及びその各々のコンピュータ機器１０２a、ならびに第２パーティ１０３b及びその各々のコンピュータ機器１０２bである。より多くのこのようなパーティ１０３及びそれらの各々のコンピュータ機器１０２がシステム１００に存在し、参加することができるが、便宜上、それらは図示されていないことが理解されよう。各パーティ１０３は、個人又は組織であってもよい。純粋に例示として、第１パーティ１０３ａは、本明細書においてAliceと称され、第２パーティ１０３ｂは、Bobと称されるが、これは限定的なものではなく、本明細書においてAlice又はBobという言及は、各々「第１パーティ」及び「第２パーティ」と置き換えることができることは理解されるであろう。

【0083】

各パーティ１０３のコンピュータ機器１０２は、１つ以上のプロセッサ、例えば、１つ以上のCPU、GPU、他のアクセラレータプロセッサ、特定用途向けプロセッサ、及び／又はFPGAを備える各々の処理装置を備える。各パーティ１０３のコンピュータ機器１０２は、更に、メモリ、すなわち、非一時的コンピュータ読み取り可能媒体又は媒体の形態のコンピュータ読み取り可能記憶装置を備える。このメモリは、１つ以上のメモリ媒体、例えば、ハードディスクのような磁気媒体、SSD、フラッシュメモリ又はEEPROMのような電子媒体、及び／又は光ディスクドライブのような光学媒体を使用する１つ以上のメモリユニットを含むことができる。各パーティ１０３のコンピュータ機器１０２上のメモリは、処理装置上で動作するように配置された少なくとも１つのクライアントアプリケーション１０５の各々のインスタンスを含むソフトウェアを記憶する。本明細書で与えられたパーティ１０３に帰属するいずれのアクションも、各々のコンピュータ装置１０２の処理装置上で実行されるソフトウェアを使用して実行され得ることが理解されよう。各パーティ１０３のコンピュータ機器１０２は、少なくとも１つのユーザ端末、例えばデスクトップ又はラップトップコンピュータ、タブレット、スマートフォン、又はスマートウォッチのようなウェアラブルデバイスを備えている。所与のパーティ１０３のコンピュータ装置１０２は、ユーザ端末を介してアクセスされるクラウドコンピューティングリソースのような、１つ以上の他のネットワーク化されたリソースを含んでもよい。

【0084】

クライアントアプリケーション１０５は、最初に、１つ以上の適切なコンピュータ読み取り可能な記憶媒体、例えばサーバからダウンロードされたもの、又はリムーバブルSSD、フラッシュメモリキー、リムーバブルEEPROM、リムーバブル磁気ディスクドライブ、磁気フロッピーディスク又はテープ、光ディスク、例えばCD又はDVD ROM、又はリムーバブル光ドライブなどのリムーバブル記憶装置上で、任意の所与のパーティ１０３のコンピュータ機器１０２に提供され得る。

【0085】

クライアントアプリケーション１０５は、少なくとも「ウォレット」機能を備える。これには主に２つの機能を有する。これらのうちの１つは、各々のパーティ１０３が、ブロックチェーンノード１０４のネットワーク全体に渡り伝播され、それによってブロックチェーン１５０に含まれるべきトランザクション１５２を作成し、認可し（例えば署名し）、送信することを可能にすることである。もう１つは、現在所有しているデジタルアセットの量を各々のパーティに報告することである。アウトプットベースのシステムでは、この第２機能は、当該パーティに属するブロックチェーン１５０全体に散在する様々なトランザクション１５２のアウトプットの中で定義される量を照合することを含む。

【0086】

注：種々のクライアント機能が所与のクライアントアプリケーション１０５に統合されるとして説明されることがあるが、これは、必ずしも限定的ではなく、代わりに、本願明細書に記載される任意のクライアント機能が２つ以上の異なるアプリケーションのスーツに実装されてよく、例えばAPIを介してインタフェースし、又は一方が他方へのプラグインである。より一般的には、クライアント機能は、アプリケーションレイヤ、又はオペレーティングシステムのような下位レイヤ、又はこれらの任意の組み合わせにおいて実装され得る。以下は、クライアントアプリケーション１０５の観点で説明されるが、これは限定的ではないことが理解される。

【0087】

各コンピュータ機器１０２上のクライアントアプリケーション又はソフトウェア１０５のインスタンスは、ネットワーク１０６のブロックチェーンノード１０４の少なくとも１つに動作可能に結合される。これにより、クライアント１０５のウォレット機能は、トランザクション１５２をネットワーク１０６に送信することができる。クライアント１０５は、また、ブロックチェーンノード１０４にコンタクトして、各々のパーティ１０３が受信側である任意のトランザクションについてブロックチェーン１５０に問い合わせることができる（又は、実施形態では、ブロックチェーン１５０は、部分的にその公開視認性を通じてトランザクションの信頼を提供する公開的設備であるため、実際には、ブロックチェーン１５０内の他のパーティのトランザクションを検査する）。各コンピュータ機器１０２上のウォレット機能は、トランザクションプロトコルに従ってトランザクション１５２を形成し、送信するように構成される。上述のように、各ブロックチェーンノード１０４は、ブロックチェーンノードプロトコルに従いトランザクション１５２を妥当性確認し、トランザクション１５２をブロックチェーンネットワーク１０６全体に渡り伝播させるために、トランザクション１５２を転送するよう構成されるソフトウェアを実行する。トランザクションプロトコルとノードプロトコルは互いに対応し、所与のトランザクションプロトコルは所与のノードプロトコルと共に所与のトランザクションモデルを実装する。同じトランザクションプロトコルは、ブロックチェーン１５０内の全部のトランザクション１５２について使用される。同じノードプロトコルは、ネットワーク１０６内の全部のノード１０４について使用される。

【0088】

所与のパーティ１０３、例えばAliceがブロックチェーン１５０に含まれる新たなトランザクション１５２jを送信したいと望む場合、彼女は関連するトランザクションプロトコルに従って（彼女のクライアントアプリケーション１０５のウォレット機能を使用して）新たなトランザクションを作成する（formulate）。彼女は、次に、クライアントアプリケーション１０５からトランザクション１５２を、彼女が接続されている１つ以上のブロックチェーンノード１０４に送信する。例えば、これは、Aliceのコンピュータ１０２に最も良好に接続されているブロックチェーンノード１０４であってもよい。任意の所与のブロックチェーンノード１０４が新しいトランザクション１５２jを受信すると、ブロックチェーンノードプロトコル及びその各々の役割に従って、それを処理する。これは、最初に、新たに受信されたトランザクション１５２jが「有効」であるための特定の条件を満たしているかどうかをチェックすることを含み、その例については、簡単に詳述する。幾つかのトランザクションプロトコルでは、妥当性確認のための条件は、トランザクション１５２に含まれるスクリプトによってトランザクション毎に構成可能であってよい。或いは、条件は単にノードプロトコルの組み込み機能であってもよく、或いはスクリプトとノードプロトコルの組み合わせによって定義されてもよい。

【0089】

新たに受信されたトランザクション１５２jが、有効であるとみなされるテストに合格したという条件で（すなわち、「妥当性確認された」という条件で）、トランザクション１５２jを受信した任意のブロックチェーンノード１０４は、そのブロックチェーンノード１０４に維持されているブロックチェーンの順序付きセット１５４に、新たな妥当性確認済みトランザクション１５２を追加する。更に、トランザクション１５２jを受信する任意のブロックチェーンノード１０４は、妥当性確認済みトランザクション１５２をネットワーク１０６内の１つ以上の他のブロックチェーンノード１０４に伝播する。各ブロックチェーンノード１０４は同じプロトコルを適用するので、トランザクション１５２jが有効であると仮定すると、これは、ネットワーク１０６全体に間もなく伝播されることを意味する。

【0090】

所与のブロックチェーンノード１０４において維持されるトランザクションの順序付きセット１５４に入れられると、該ブロックチェーンノード１０４は、新しいトランザクション１５２を含む、彼ら各々のトランザクションの順序付きセットの最新バージョンについて、proof-of-workパズルを解く競争を開始する（他のブロックチェーンノード１０４は、トランザクションの異なる順序付きセット１５４に基づきパズルを解こうとしているが、誰であっても１番の者が、最新のブロック１５１に含まれるトランザクションの順序付きセットを定義することに留意する。）。最終的に、ブロックチェーンノード１０４は、Aliceのトランザクション１５２jを含む順序付きセット１５４の一部についてパズルを解くだろう。）。一旦、新しいトランザクション１５２jを含む順序付きセット１５４についてproof-of-workが行われると、それは不変の方法でブロックチェーン１５０内のブロック１５１のうちの１つの一部となる。各トランザクション１５２は、以前のトランザクションへのポインタを含むので、トランザクションの順序もまた、不変的に記録される。

【0091】

異なるブロックチェーンノード１０４は、最初に所与のトランザクションの異なるインスタンスを受信する可能性があり、従って、１つのインスタンスが公開（Publishing）されて新しいブロック１５１になる前に、どのインスタンスが「有効」であるかについて矛盾するビューを有することがあり、その時点で、全部のブロックチェーンノード１０４は公開されたインスタンスのみが有効なインスタンスであることに合意する。ブロックチェーンノード１０４が１つのインスタンスを有効であるとして受け入れ、次に第２インスタンスがブロックチェーン１５０に記録されていることを発見した場合、該ブロックチェーンノード１０４は、これを受け入れなければならず、最初に受け入れたインスタンス（つまり未だブロック１５１の中で公開されていないもの）を破棄する（つまり、無効であるとして扱う）。

【0092】

アカウントベースのトランザクションモデルの一部として、幾つかのブロックチェーンネットワークにより運用される別のタイプのトランザクションプロトコルを「アカウントベース」のプロトコルと呼ぶことがある。アカウントベースの場合、各トランザクションは、過去の一連のトランザクションにおいて、先行するトランザクションのUTXOに戻って参照することによって移転される量を定義するのではなく、絶対的な口座（アカウント）残高を参照することによって移転される。全てのアカウントの現在の状態は、ブロックチェーンと分離して、ネットワークのノードにより格納され、絶えず更新される。このようなシステムでは、トランザクションは、アカウントの連続したトランザクション記録（いわゆる「ポジション」）を用いて発注される。この値は、送信者により彼らの暗号署名の一部として署名され、トランザクション参照計算の一部としてハッシュされる。更に、任意的なデータフィールドもトランザクションに署名することができる。このデータフィールドは、例えば、前のトランザクションIDがデータフィールドに含まれている場合、前のトランザクションを遡ってポイントしてよい。

【0093】

＜UTXOベースのモデル＞
図２は、トランザクションプロトコルの例を示している。これは、UTXOベースのプロトコルの例である。トランザクション１５２（「Tx」と略す）は、ブロックチェーン１５０（各ブロック１５１は１つ以上のトランザクション１５２を含む）の基本的なデータ構造である。以下は、アウトプットベース又は「UTXO」ベースのプロトコルを参照して説明される。しかし、これは、全ての可能な実施形態に限定されるものではない。例示的なUTXOベースのプロトコルは、ビットコインを参照して説明されるが、他の例示的なブロックチェーンネットワーク上でも等しく実施できることに留意する。

【0094】

UTXOベースのモデルでは、各トランザクション（「Tx」）１５２は、１つ以上のインプット２０２及び１つ以上のアウトプット２０３を含むデータ構造を含む。各アウトプット２０３は、未使用トランザクションアウトプット（UTXO）を含んでもよく、これは、別の新しいトランザクションのインプット２０２のソースとして使用することができる（UTXOが未だ償還されていない場合）。UTXOは、デジタルアセットの量を指定する値を含む。これは、分散型台帳上のトークンの設定数を表す。また、他の情報の中でも、UTXOは、それが由来するトランザクションのトランザクションIDも含んでよい。トランザクションデータ構造はまた、ヘッダ２０１も含んでよく、ヘッダ２０１は、インプットフィールド２０２及びアウトプットフィールド２０３のサイズの指示子を含んでもよい。ヘッダ２０１は、トランザクションのIDも含んでもよい。実施形態において、トランザクションIDは、トランザクションデータ（トランザクションID自体を除く）のハッシュであり、ノード１０４に送信された未処理トランザクション１５２のヘッダ２０１に格納される。

【0095】

例えばAlice１０３aは、問題のデジタルアセットの量をBob１０３bに移転するトランザクション１５２jを作成したいと考えているとする。図２において、Aliceの新しいトランザクション１５２jは「Tx_１」とラベル付けされている。これは、Aliceにロックされているデジタルアセットの量を、シーケンス内の先行するトランザクション１５２iのアウトプット２０３に取り入れ、その少なくとも一部をBobに移転する。先行するトランザクション１５２iは、図２において「Tx_０」とラベル付けされている。Tx_０とTx_１は、単なる任意のラベルである。これらは、必ずしも、Tx_０がブロックチェーン１５１の第１トランザクションであること、又は、Tx_１がプール１５４の直ぐ次のトランザクションであることを意味しない。Tx_１は、未だAliceへのロックされた未使用アウトプット２０３を有する任意の先行する（つまり祖先）トランザクションのいずれかを指し示すことができる。

【0096】

先行するトランザクションTx_０は、Aliceが彼女の新しいトランザクションTx_１を作成するとき、又は少なくとも彼女がそれをネットワーク１０６に送信するときに、既に妥当性確認され、ブロックチェーン１５０のブロック１５１に含まれていてもよい。それは、その時点で既にブロック１５１のうちの１つに含まれていてもよく、或いは、順序付きセット１５４内で未だ待機していてもよく、その場合、新しいブロック１５１にすぐに含まれることになる。或いは、Tx０及びTx１が生成されネットワーク１０６に送信されることができ、或いは、ノードプロトコルが「孤児（orphan）」トランザクションのバッファリングを許容する場合にはTx１の後にTx０が送信されることもできる。ここでトランザクションのシーケンスの文脈で使用される「先行する」及び「後の」という用語は、トランザクション内で指定されたトランザクションポインタ（どのトランザクションがどの他のトランザクションを指すかなど）によって定義されるシーケンス内のトランザクションの順序を指す。それらは、「先行する」及び「相続する」又は「祖先」及び「子孫」、「親」及び「子」、等により、等しく置き換えられ得る。これは、必ずしも、それらが作成され、ネットワーク１０６に送られ、又は任意の所与のブロックチェーンノード１０４に到達する順序を意味しない。それにもかかわらず、先行するトランザクション（祖先トランザクション又は「親」）を指す後続のトランザクション（子孫トランザクション又は「子」）は、親トランザクションが妥当性確認されない限り、妥当性確認されない。親の前にブロックチェーンノード１０４に到着した子は孤児とみなされる。それは、ノードプロトコル及び／又はノードの行動に応じて、親を待つために特定の時間、破棄又はバッファリングされることがある。

【0097】

先行するトランザクションTx_０の１つ以上のアウトプット２０３のうちの１つは、本明細書でUTXO_０とラベル付けされた特定のUTXOを含む。各UTXOは、UTXOによって表されるデジタルアセットの量を指定する値と、後続のトランザクションが妥当性確認されるために、従ってUTXOが正常に償還されるために、後続のトランザクションのインプット２０２の中のアンロックスクリプトによって満たされなければならない条件を定義するロックスクリプトとを含む。典型的には、ロックスクリプトは、特定のパーティ（それが含まれているトランザクションの受益者）に量をロックする。すなわち、ロックスクリプトは、標準的に以下のようなアンロック条件を定義する：後続のトランザクションのインプット内のアンロックスクリプトは、先行するトランザクションがロックされたパーティの暗号署名を含む。

【0098】

ロックスクリプト（別名scriptPubKey）は、ノードプロトコルによって認識されるドメイン固有の言語で書かれたコードの一部である。そのような言語の特定の例は、ブロックチェーンネットワークにより使用される「スクリプト」（Script，大文字S）と呼ばれる。ロックスクリプトは、トランザクションアウトプット２０３を消費するために必要な情報、例えば、Aliceの署名の必要条件を指定する。トランザクションのアウトプットには、アンロックスクリプトが現れる。アンロックスクリプト（別名：scriptSig）は、ロックスクリプトの基準を満たすために必要な情報を提供するドメイン固有の言語で書かれたコードの一部である。例えば、Bobの署名を含んでもよい。アンロックスクリプトは、トランザクションのインプット２０２に現れる。

【0099】

図示の例では、Tx_０のアウトプット２０３のUTXO_０は、ロックスクリプト[ChecksigP_A]を含み、これは、UTXO_０が償還されるために（厳密には、UTXO_０を償還しようとする後続のトランザクションが有効であるために）、Aliceの署名SigP_Aを必要とする。[Checksig P_A]は、Aliceの公開－秘密鍵ペアからの公開鍵P_Aの表現（つまりハッシュ）を含む。Tx_１のインプット２０２は、Tx_１を指すポインタ（例えば、そのトランザクションID、実施形態ではトランザクションTx_０全体のハッシュであるTxID_０による）を含む。Tx_１のインプット２０２は、Tx_０の任意の他の可能なアウトプットの中でそれを識別するために、Tx_０内のUTXO_０を識別するインデックスを含む。Tx１のインプット２０２は、更に、Aliceが鍵ペアからのAliceの秘密鍵をデータの所定の部分（暗号において「メッセージ」と呼ばれることもある）に適用することによって作成された、Aliceの暗号署名を含むアンロックスクリプト<SigPA>を含む。有効な署名を提供するためにAliceが署名する必要があるデータ（又は「メッセージ」）は、ロックスクリプトにより、又はノードプロトコルにより、又はこれらの組み合わせによって定義され得る。

【0100】

新しいトランザクションTx_１がブロックチェーンノード１０４に到着すると、ノードはノードプロトコルを適用する。これは、ロックスクリプトとアンロックスクリプトを一緒に実行して、アンロックスクリプトがロックスクリプトで定義されている条件（この条件は１つ以上の基準を含むことができる）を満たしているかどうかをチェックすることを含む。実施形態では、これは、２つのスクリプトの連結を含む。

【数1】

ここで、「||」は連結を表し、「<...>」はスタックにデータを配置することを意味し、「[...]」はロックスクリプトに含まれる機能である（本例では、スタックベースの言語）。同等に、スクリプトは。、スクリプトを連結するのではなく共通のスタックにより１つずつ実行されてよい。いずれの方法でも、一緒に実行する場合、スクリプトは、Tx_０のアウトプット内のロックスクリプトに含まれるAliceの公開鍵P_Aを使用して、Tx_１のインプット内のアンロックスクリプトが、データの期待部分に署名するAliceの署名を含むことを認証する。また、データの期待部分（「メッセージ」）も、この認証を実行するために含まれる必要がある。実施形態において、署名されたデータは、Tx_１の全体を含む（従って、データの署名された部分が既に本質的に存在するので、データの署名された部分を平文で指定する別個の要素が含まれる必要はない）。

【0101】

公開－秘密暗号法による認証の詳細は、当業者には周知であろう。基本的に、Aliceが彼女の秘密鍵を用いてメッセージに署名した場合、Aliceの公開鍵とそのメッセージが平文ならば、ノード１０４のような別のエンティティは、そのメッセージがAliceによって署名されていなければならないことを認証することができる。署名は、典型的には、メッセージをハッシュし、ハッシュに署名し、署名としてメッセージにこれをタグ付けすることによって、公開鍵の所有者が署名を認証することを可能にする。従って、実施形態では、特定のデータ片又はトランザクションの部分等に署名するという言及は、データ片又はトランザクションの部分のハッシュに署名することを意味し得る。

【0102】

Tx_１内のアンロックスクリプトが、Tx_０のロックスクリプトで指定された１つ以上の条件を満たす場合（示される例では、Aliceの署名がTx_１内で提供され、認証されている場合）、ブロックチェーンノード１０４は、Tx_１が有効であるとみなす。これは、ブロックチェーンノード１０４がTx_１をトランザクションの順序付きセット１５４に追加することを意味する。ブロックチェーンノード１０４は、トランザクションTx_１をネットワーク１０６内の１つ以上の他のブロックチェーンノード１０４に転送し、それによって、それがネットワーク１０６全体に電波されることになる。一旦、Tx_１が妥当性確認され、ブロックチェーン１５０に含まれると、これは、Tx_０からのUTXO_０を消費したものとして定義する。Tx_１は、未使用トランザクションアウトプット２０３を使用する場合にのみ有効であることに留意されたい。別のトランザクション１５２によって既に消費されたアウトプットを消費しようとする場合、Tx_１は、たとえ他の全ての条件が満たされていても無効となる。従って、ブロックチェーンノード１０４は、先行するトランザクションTx_０において参照されたUTXOが既に使用されているかどうか（既に別の有効なトランザクションへの有効なインプットを形成しているかどうか）もチェックする必要がある。これが、ブロックチェーン１５０がトランザクション１５２に定義された順序を課すことが重要である理由の１つである。実際には、所与のブロックチェーンノード１０４は、トランザクション１５２が消費されたUTXO２０３をマークする別個のデータベースを維持することができるが、最終的には、UTXOが消費されたかどうかを定義するのは、ブロックチェーン１５０内の別の有効なトランザクションへの有効なインプットを既に形成しているかどうかである。

【0103】

所与のトランザクション１５２の全部のアウトプット２０３の中で指定された総量が全部のそのインプット２０２により指される総量より大きい場合、これは、殆どのトランザクションモデルにおいて無効の別の基礎である。従って、このようなトランザクションは、伝播されず、ブロック１５１に含まれることもない。

【0104】

UTXOベースのトランザクションモデルでは、所定のUTXOを全体として使用する必要があることに注意する。UTXOで定義されている量のうち、別の分量が消費されている一方で、ある分量を「残しておく」ことはできない。ただし、UTXOからの量は、次のトランザクションの複数のアウトプットに分割できる。例えば、Tx_０のUTXO_０で定義された量は、Tx_１の複数のUTXOに分割できる。従って、AliceがBobにUTXO_０で定義された量の全てを与えることを望まない場合、彼女は残りの量を使って、Tx_１の第２アウトプットの中で自分自身にお釣りを与えるか、又は別のパーティに支払うことができる。

【0105】

特に、Aliceは、通常、彼女のトランザクションを公開するビットコインノード１０４のために手数料も含む必要がある。Aliceがマイナーのための手数料を含まない場合、Tx_０はマイナーのブロックチェーンノード１０４によって拒否される可能性が高く、従って、技術的には有効であるが、それは依然として伝播されず、ブロックチェーン１５０に含まれない（ノードプロトコルは、彼らが望まない場合には、ブロックチェーンノード１０４にトランザクション１５２を受け入れることを強制しない）。一部のプロトコルでは、トランザクション手数料は、独自の別個のアウトプット２０３を必要としない（すなわち、別個のUTXOを必要としない）。代わりに、インプット２０２によって示される総量と、所与のトランザクション１５２のアウトプット２０３で指定される総量との間の差は、トランザクションを公開するブロックチェーンノード１０４に自動的に与えられる。例えば、UTXO_０へのポインタがTx_１への唯一のインプットであり、Tx_１は１つのアウトプットUTXO_１しか持っていないとする。UTXO_０で指定されたデジタルアセットの量がUTXO_１で指定された量より多い場合、その差は、UTXO_１を含むブロックを公開するノード１０４により割り当てられてよい。しかし、代替的又は追加的に、必ずしも、トランザクション１５２のUTXO２０３のうちの独自のものにおいて、トランザクション手数料を明示的に指定できることは除外されない。

【0106】

Alice及びBobのデジタルアセットは、ブロックチェーン１５０内の任意のトランザクション１５２の中で彼らにロックされたUTXOで構成されている。従って、典型的には、所与のパーティ１０３のアセットは、ブロックチェーン１５０を通して、様々なトランザクション１５２のUTXO全体に分散される。ブロックチェーン１５０内のどこにも、所与のパーティ１０３の総残高を定義する１つの数値は記憶されていない。各パーティへのロックされた、別の将来の（onward）トランザクションに未だ使用されていない全ての様々なUTXOの値をまとめることは、クライアントアプリケーション１０５におけるウォレット機能の役割である。ビットコインノード１０４のいずれかに格納されたブロックチェーン１５０のコピーをクエリすることにより、これを行うことができる。

【0107】

スクリプトコードは、概略的に表現されることが多い（すなわち、正確な言語を用いない）ことに注意する。例えば、特定の機能を表現するオペレーションコード（opcode、オペコード）を使用してよい。「OP_....」は、スクリプト言語の特定のオペコードを表す。例として、OP_RETURNは、ロックスクリプトの始めにあるOP_FALSEが先行するとき、トランザクション内にデータを格納することができ、それによってデータをブロックチェーン１５０に不変に記録することができるトランザクションの使用不可能アウトプットを生成するためのスクリプト言語のオペコードである。例えば、データは、ブロックチェーンに格納することが望ましい文書を含むことができる。

【0108】

標準的に、トランザクションのインプットは、公開鍵P_Aに対応するデジタル署名を含む。実施形態において、これは楕円曲線secp２５６k１を使用するECDSAに基づく。デジタル署名は、特定のデータに署名する。幾つかの実施形態では、所与のトランザクションについて、署名はトランザクションインプットの一部、及びトランザクションアウトプットの全部又は一部に署名する。署名するアウトプットの特定の部分はSIGHASHフラグに依存する。SIGHASHフラグは、通常、署名の最後に含まれる４バイトのコードであり、どのアウトプットが署名されるかを選択する（従って、署名の時点で固定される）。

【0109】

ロックスクリプトは、通常、各々のトランザクションがロックされているパーティの公開鍵を含んでいることを表す「scriptPubKey」と呼ばれることがある。アンロックスクリプトは、通常、対応する署名を提供することを表す「scriptSig」と呼ばれることがある。しかし、より一般的には、UTXOが償還される条件が署名を認証することを含むことは、ブロックチェーン１５０の全てのアプリケーションにおいて必須ではない。より一般的には、スクリプト言語は、任意の１つ以上の条件を定義するために使用され得る。従って、より一般的な用語「ロックスクリプト」及び「アンロックスクリプト」が好ましい。

【0110】

図１に示されるようにAlice及びBobのコンピュータ装置１０２a、１２０bの各々にあるクライアントアプリケーションは、付加的な通信機能を備えてよい。この追加機能は、Alice１０３aが、（いずれかのパーティ又は第３者の勧誘で）Bob１０３bと別個のサイドチャネル３０１を確立することを可能にする。サイドチャネル３０１は、ブロックチェーンネットワークと別個にデータの交換を可能にする。このような通信は、時に「オフチェーン」通信と呼ばれる。例えば、これは、パーティの一方がネットワーク１０６にトランザクション１５２をブロードキャストすることを選択するまで、ブロックチェーンネットワーク１０６上に登録されることなく、又はチェーン１５０上に進むことなく、AliceとBobとの間でトランザクション１５２を交換するために使用され得る。このようにトランザクションを共有することは、時に、「トランザクションテンプレート」の共有と呼ばれる。トランザクションテンプレートは、完全なトランザクションを形成するために必要な１つ以上のインプット及び／又はアウトプットが欠けていてよい。代替又は追加で、サイドチャネル３０１は、任意の他のトランザクションに関連するデータ、例えば、鍵、交渉される量又は条項、データコンテンツ、等を交換するために使用されてよい。

【0111】

サイドチャネル３０１は、ブロックチェーンネットワーク１０６と同じパケット交換ネットワーク１０１を介して確立されてもよい。代替又は追加で、サイドチャネル３０１は、モバイルセルラネットワーク、又はローカル無線ネットワークのようなローカルエリアネットワーク、又はAliceとBobの装置１０２a、１０２bの間の直接有線若しくは無線リンクのような異なるネットワークを介して確立されてよい。一般に、本願明細書のどこかで言及されるサイドチャネル３０１は、「オフチェーン」で、つまりブロックチェーンネットワーク１０６と別個にデータを交換するための１つ以上のネットワーキング技術又は通信媒体を介する任意の１つ以上のリンクを含んでよい。１つより多くのリンクが使用されるとき、全体としてのオフチェーンリンクのバンドル又は集合がサイドチャネル３０１と呼ばれてよい。従って、Alice及びBobが特定の情報又はデータ片等をサイドチャネル３０１を介して交換すると言われる場合、これは、必ずしも全部のこれらのデータ片が正確に同じリンク又は同じ種類のネットワークを介して送信される必要があることを意味しないことに留意する。

【0112】

＜クライアントソフトウェア＞
図３Aは、本開示の方式の実施形態を実装するためのクライアントアプリケーション１０５の例示的な実装を示す。クライアントアプリケーション１０５は、トランザクションエンジン３５１と、ユーザインタフェース（UI）レイヤ３５２と、を含む。トランザクションエンジン３５１は、クライアント１０５の基礎トランザクション関連機能、例えば、トランザクション１５２を形成し、トランザクション及び／又はサイドチャネル３０１を介して他のデータを受信及び／又は送信し、及び／又はブロックチェーンネットワーク１０６を介して伝播されるように１つ以上のノード１０４にトランザクションを送信するように、上述したスキームに従って、更に詳細に説明するように、構成される。ここに開示された実施形態によると、各クライアント１０５のトランザクションエンジン３５１は、機能３５３を含む。

【0113】

UIレイヤ３５２は、各々のユーザコンピュータ機器１０２のユーザ入力／出力（I／O）手段を介して、機器１０２のユーザ出力手段により各々のユーザ１０３へ情報を出力すること及び機器１０２のユーザ入力手段により各々のユーザ１０３から入力を受信することを含む、ユーザインタフェースをレンダリングするよう構成される。例えば、ユーザ出力手段は、視覚的出力を提供する１つ以上のディスプレイスクリーン（タッチ又は非タッチスクリーン）、オーディオ出力を提供する１つ以上のスピーカ、及び／又は触覚出力を提供する１つ以上の触覚出力装置、等を含み得る。ユーザ入力手段は、例えば、１つ又は複数のタッチスクリーンの入力アレイ（出力手段に使用されるものと同じか又は異なる）、マウス、トラックパッド又はトラックボールなどの１つ又は複数のカーソルベースの装置、音声又は声の入力を受け取るための１つ又は複数のマイクロフォン及び音声認識アルゴリズム、手動又は身体のジェスチャの形態で入力を受け取るための１つ又は複数のジェスチャベースの入力装置、又は１つ又は複数の機械的ボタン、スイッチ又はジョイスティックなどを含むことができる。

【0114】

注：本明細書における種々の機能は、同一のクライアントアプリケーション１０５に統合されていると記述することができるが、これは、必ずしも限定するものではなく、代わりに、２つ以上の別個のアプリケーション、例えば、一方が他方へのプラグインであるか、又はAPI（アプリケーションプログラミングインタフェース）を介したインタフェースで実装することができる。例えば、トランザクションエンジン３５１の機能は、UIレイヤ３５２と別個のアプリケーション、又は所与のモジュールの機能に実装されてよく、トランザクションエンジン３５１が１つより多くのアプリケーションの間で分割されてよい。また、記載の機能の一部又は全部が、例えばオペレーティングシステムレイヤに実装されることを除外しない。本願明細書のどこかで、単一の又は所与のアプリケーション１０５等を参照する場合、これが単に例としてであること、より一般的には、記載の機能が任意の形式のソフトウェアで実装され得ることが理解される。

【0115】

図３Bは、Aliceの機器１０２a上のクライアントアプリケーション１０５aのUI層３５２によりレンダリングされてよいユーザインタフェース（UI）３６０の例の模擬表示を与える。同様のUIが、任意の他のパーティのクライアント１０５b、Bobの機器１０２b、又は任意の他のパーティの機器によりレンダリングされてよいことが理解される。

【0116】

例示として、図３Bは、Aliceの観点からUI３６０を示す。UI３６０は、ユーザ出力手段を介して別個のUI要素として描画される１つ以上のUI要素３６２、３６２、３６３を含んでもよい。

【0117】

例えば、UI要素は、例えば、画面上の異なるボタン、又はメニュー内の異なるオプション等の１つ以上のユーザ選択可能要素３６２を含むことができる。ユーザ入力手段は、スクリーン上のUI要素をクリック若しくはタッチすることにより、又は所望のオプションの名称を発話することにより、ユーザ１０３（この場合にはAlice１０３a）がオプションのうちの１つを選択又は操作できるよう構成される（注：ここで使用される「手動（manual）」は単に自動の反対を意味し、必ずしも手の使用に限定されない）。

【0118】

代替的又は追加的に、UI要素は、１つ以上のデータ入力フィールド３６２を含んでもよいく、ユーザはそれらを通じてデータを入力できる。これらのデータエントリフィールドは、ユーザ出力手段、例えば、オンスクリーンを介してレンダリングされ、データは、ユーザ入力手段、例えば、キーボード又はタッチスクリーンを介してフィールドに入力することができる。或いは、データは、例えば、音声認識に基づいて口頭で受信され得る。

【0119】

代替的又は追加的に、UI要素は、ユーザに情報を出力するために出力される１つ以上の情報要素３６３を含んでもよい。例えば、これ／これらは、スクリーン上に描画されるか、又は可聴でレンダリングされることがある。

【0120】

例えば、この／これらは、スクリーン上に描画されるか、又は可聴で描画されることがある。これらのUI要素の機能は、間もなく更に詳細に議論される。また、図３に示されたUI３６０は、単に概略的なモックアップであり、実際には、１つ以上の更なるUIエレメントを含んでもよく、これは、簡潔さのために示されていないことが理解される。

【0121】

＜ノードソフトウェア＞
図４は、UTXO又はアウトプットに基づくモデルの例における、ネットワーク１０６の各ブロックチェーンノード１０４で実行され得るノードソフトウェア４５０の例を示す。別のエンティティが、ネットワーク１０６上でノード１０４として分類されずに、つまり、ノード１０４に必要なアクションを実行せずに、ノードソフトウェア４５０を実行できることに注意する。ノードソフトウェア４５０は、プロトコルエンジン４５１、スクリプトエンジン４５２、スタック４５３、アプリケーションレベルの決定エンジン４５４、及び１つ以上のブロックチェーン関連機能モジュールのセット４５５を含んでよいが、それらに限定されない。各ノード１０４は、合意モジュール４５５C（例えば、proof-of-work）、伝播モジュール４５５P、及びストレージモジュール４５５S（例えば、データベース）の３つ全てを含むが、これらに限定されないノードソフトウェアを実行できる。プロトコルエンジン３５１は、標準的に、トランザクション１５２の異なるフィールドを認識し、それらをノードプロトコルに従い処理するよう構成される。トランザクション１５２j（Tx_j）が受信され、別の先行するトランザクション１５２i（Tx_m-１）のアウトプット（例えばUTXO）をポイントするインプットを有するとき、プロトコルエンジン４５１は、Tx_j内のアンロックスクリプトを識別し、それをスクリプトエンジン４５２に渡す。プロトコルエンジン４５１は、更に、Tx_jのインプットの中のポインタに基づき、Tx_iを識別し検索する。Tx_iはブロックチェーン１５０上で公開されてよい。この場合、プロトコルエンジンは、ノード１０４に格納されているブロックチェーン１５０のブロック１５１のコピーからTxiを取得できる。又は、Tx_iは、未だブロックチェーン１５０上で公開されていない可能性がある。その場合、プロトコルエンジン４５１は、ノード１５４によって保持されている未公開トランザクションの順序付きセット１５４からTx_iを取得することができる。いずれの方法も、スクリプトエンジン４５１は、Txiの参照されるアウトプットの中のロックスクリプトを識別し、これをスクリプトエンジン４５２に渡す。

【0122】

スクリプトエンジン４５２は、従って、Tx_iのロックスクリプト、及びTx_j対応するインプットからのアンロックスクリプトを有する。例えば、Tx_０及びTx_１が図２に示されるが、同じことがトランザクションの任意のペアに適用され得る。スクリプトエンジン４５２は、前述のように２つのスクリプトを一緒に実行し、これらは、使用されているスタックに基づくスクリプト言語（例えばScript）に従い、スタック４５３にデータを置くことと、データを検索することとを含む。

【0123】

スクリプトを一緒に実行することにより、スクリプトエンジン４５２は、アンロックスクリプトがロックスクリプトの中で定義された１つ以上の基準を満たすか否か、つまり、アンロックスクリプトがロックスクリプトが含まれるアウトプットを「アンロック」するか否かを決定する。スクリプトエンジン４５２は、この決定の結果をプロトコルエンジン４５１に返す。スクリプトエンジン４５２は、アンロックスクリプトは対応するロックスクリプトの中で指定された１つ以上の基準を満たすと決定した場合、結果「真」を返す。その他の場合、それは結果「偽」を返す。

【0124】

アウトプットに基づくモデルでは、スクリプトエンジン４５２からの結果「真」は、トランザクションの有効性についての条件のうちの１つである。標準的に、同様に満たされなければならない、プロトコルエンジン４５１により評価される１つ以上の更なるプロトコルレベルの条件が更にあり、Tx_jのアウトプットの中で指定されたデジタルアセットの総量がそのインプットによりポイントされる総量を超えないこと、Tx_iのポイントされるアウトプットは別の有効なトランザクションにより未だ使用されていないこと、等である。プロトコルエンジン４５１は、１つ以上のプロトコルレベルの条件と一緒にスクリプトエンジン４５２からの結果を評価し、それら全部が真である場合、トランザクションTx_jを妥当性確認する。プロトコルエンジン４５１は、トランザクションが有効であるかどうかの指示を、アプリケーションレベル決定エンジン４５４に出力する。Tx_jが実際に妥当性確認されたことのみを条件として、決定エンジン４５４は、合意モジュール４５５C及び伝播モジュール４５５Pの一方又は両方を、それらの各々のブロックチェーンに関連する機能をTx_jに関して実行するよう制御することを選択してよい。これは、ブロック１５１に組み込むためにノードの各々の順序付きトランザクションセット１５４にTx_jを追加する合意モジュール４５５Cと、ネットワーク１０６内の別のブロックチェーンノード１０４にTx_jを転送する伝播モジュール４５５Pを含む。任意的に、実施形態では、アプリケーションレベル決定エンジン４５４は、これらの機能のうちのいずれか又は両方をトリガする前に、１つ以上の追加条件を適用してよい。例えば、決定エンジンは、トランザクションがだとうせされたこと、及び十分なトランザクション手数料が残されることの両方を条件としてのみ、トランザクションを公開することを選択してよい。

【0125】

用語「真（true）」及び「偽（false）」は、本願明細書では、必ずしも単一の２進数字（ビット）のみの形式で表現される結果を返すことに限定しないが、それは勿論１つの可能な実装であることに留意する。より一般的には、「真」は、成功又は肯定的な結果を示す任意の状態を表すことができ、「偽」は、不成功又は非肯定的な結果を示す任意の状態を表すことができる。例えば、アカウントに基づくモデルでは、「真」の結果は、署名の暗示的なプロトコルレベルの検証と、スマートコントラクトの追加の肯定的なアウトプットとの組み合わせにより示され得る（全体の結果は、両方の個々の結果が真である場合に、真を伝達すると考えられる）。

【0126】

開示された技術の他の変形例又は使用事例は、本明細書で開示されると、当業者に明らかになり得る。本開示の範囲は、記載された実施形態によって限定されるものではなく、添付の特許請求の範囲によってのみ限定される。

【0127】

例えば、上述の幾つかの実施形態は、ビットコインネットワーク１０６、ビットコインブロックチェーン１５０、及びビットコインノード１０４の観点で説明された。しかしながら、ビットコインブロックチェーンは、ブロックチェーン１５０の１つの特定の例であり、上述の説明は任意のブロックチェーンに一般的に適用されてよいことが理解される。つまり、本発明は、ビットコインブロックチェーンに何ら限定されない。より一般的には、上述のビットコインネットワーク１０６、ビットコインブロックチェーン１５０、及びビットコインノード１０４への言及は、ブロックチェーンネットワーク１０６、ブロックチェーン１５０、及びブロックチェーンノード１０４により各々置き換えられてよい。ブロックチェーン、ブロックチェーンネットワーク、及び／又はブロックチェーンノードは、ビットコインブロックチェーン１５０、ビットコインネットワーク１０６、及びビットコインノード１０４の上述の特性の一部又は全部を共有してよい。

【0128】

本発明の好適な実施形態では、ブロックチェーンネットワーク１０６は、ビットコインネットワークであり、ビットコインノード１０４はブロックチェーン１５０のブロック１５１を生成し、公開し、伝播し、及び格納する上述の機能の少なくとも全部を実行する。これらの機能の全部ではなく１つ又は一部のみを実行する他のネットワークエンティティ（又はネットワーク要素）が存在することが除外されない。つまり、ネットワークエンティティは、ブロックを伝播し及び／又は格納する機能を実行してよいが、ブロックを生成し公開しなくてよい（これらのエンティティが好適なビットコインネットワーク１０６のノードとみなされないことを思い出してほしい）。

【0129】

本発明の好適でない実施形態では、ブロックチェーンネットワーク１０６はビットコインネットワークでなくてもよい。これらの実施形態では、ノードが、ブロックチェーン１５０のブロック１５１を生成し、公開し、伝播し、及び格納する機能の全部ではなく少なくとも１つ又は一部を実行してよいことが除外されない。例えば、これらの他のブロックチェーンネットワークでは、「ノード」は、ブロック１５１を生成し公開するよう構成されるが該ブロック１５１を格納し及び／又は他のノードに伝播しないネットワークエンティティを表すために使用されてよい。

【0130】

更に一般的には、上述の用語「ビットコインノード」１０４の言及は、用語「ネットワークエンティティ」又は「ネットワーク要素」と置き換えられてよい。このようなエンティティ／要素は、ブロックを生成し、公開し、伝播し、及び格納する役割のうちの一部又は全部を実行するよう構成される。そのようなネットワークエンティティ／要素の機能は、ハードウェアで、ブロックチェーンノード１０４を参照して上述したのと同じ方法で実装されてよい。

【0131】

委任された認可
図５は、委任された認可トークンの提供及び使用のための本開示の第１態様によるシステム５００に関するものであり、好ましくは、ブロックチェーン１０１に関連する複数のサービスを提供するプラットフォームプロセッサ５０４の一部である。プラットフォームプロセッサ５０４は、任意で、図１１及び図１３に関して以下により詳細に説明されるプラットフォームである。しかしながら、本明細書に記載されるような委任された認可の方法及びシステムは、ブロックチェーン１０１に関連付けられていないサービスを含む他のサービスにおいて使用することができる。プラットフォームプロセッサ５０４は、ブロックチェーン１０１、クライアント５０２、及び／又は委任されたユーザ５０６と通信し、及び／又は他の方法で相互作用するように構成される。プラットフォームプロセッサ５０４は、説明を容易にするために、本明細書ではモノリシックサーバとして説明される。「クライアント」、「ユーザ」、又は同様の用語が使用される場合、これはしばしば、当該クライアント又はユーザが所有する装置を指すことが理解される。当業者は、それが単一のサーバ、メインフレーム、サーバの集合、マイクロサービス、マイクロサービスの集合、クラウドサービス、前述の及び／又は１つ以上の他のコンピューティングプラットフォームの任意の組み合わせとして実装され得ることを理解するであろう。ここで使用される「（１つ以上の）サービス」という用語は、計算機能又は動作の集合に対する一般的な用語として理解されるべきであり、１つのサーバ上で実行される１つの単一アプリケーションに厳密に特定されるものではない。ここでは、例とオプションの非網羅的なリストを示す。サービスは、１つのアプリケーション又は複数のアプリケーションであってよい。サービスは、１つのハードウェアサーバ／装置又は複数で実行されてよい。例えば、次の例では、サービスとは別のデータベースが提供されるが、これは代替として同じサービスの一部として等価的に構成されている場合もある。

【0132】

システム５００は、プラットフォーム５０４上のサービスに対する権限を有するユーザであるクライアント５０２を含む。クライアントの権限は、クライアント５０２が他のユーザ５０６（以下、委任されたユーザ（delegated user）又はデリゲート（delegate）と呼ぶ）に委任された権限を提供することを可能にする。クライアント５０２は、サービスの「所有者」とみなすことができ、好ましくは、プラットフォーム５０４上でのサービスの生成をトリガする。クライアント５０２は、他のユーザがサービスにアクセスできるように、認可を委任したいと考えている。好ましくは、委任された認可は、委任されたユーザ５０６に、サービスを実行しているプラットフォーム５０４と相互作用する（５１２）ための許可を与える。より好ましくは、相互作用は、サービスに対する読み取り、書き込み、又はサービスに対する読み取りと書き込みの両方である。更に好ましくは、記載されるサービスは、図１０A～C、１１及び１２を参照して以下により詳細に説明されるイベントストリームである。当業者は、ここでのサービスの委任された認可に関連する方法及びシステムが、他のサービスでも使用できることを理解するであろう。

【0133】

任意で、委任されたユーザがサービスと行うことができる他の相互作用がある。許可される相互作用の種類は、サービスによって異なる。例えば、サービスが金融トランザクションを提供している場合、委任されたユーザがトランザクションの生成又は署名することの委任を受けている場合がある。望ましくは、委任された認可は、より多くの委任されたユーザを追加したり、委任された認可トークンを生成したりする権限を与えない。

【0134】

図６及び図７を参照して以下により詳細に説明するように、本態様の一実施形態によれば、クライアント５０２は、委任された認可トークンを生成し、委任されたユーザ５０６に提供する（５０８）。

【0135】

図８及び図９A～図９Cを参照して以下により詳細に説明するように、本態様の一実施形態によれば、委任されたユーザ５０６は、これらのトークンを含む要求を生成するように構成され、要求は、プラットフォーム５０４上で実行されるサービスに送信される（５１２）。要求を受信すると、サービスは、要求を妥当性確認し、委任された認可トークンの有効性に応じて、要求を処理する。

【0136】

委任された認可トークンの生成
図６は、第１態様の実施形態による方法６００の例を示す。方法６００は、委任された認可トークン（ここでは、delegatedAuthトークンとしても記述される）の生成を示し、クライアント５０２が、複数の委任されたユーザが委任されたサービスと相互作用することを認可したい場合に使用される。好ましくは、この方法は、システム５００内の他のエンティティとの相互作用なしに、クライアントによって完全に実行される。任意で、委任された認可トークンは、委任された認可トークンと共に提供され得る関連インデックスを有する。

【0137】

委任された認可トークンは、関連するトークンのセットを形成するように生成される。望ましくは、後述するように、各委任された認可トークン（第１委任された認可トークンを除く）はチェーンの中の先行する委任された認可トークンに基づいているため、セットはトークンの「チェーン」である。

【0138】

最初に、２つの乱数：初期値（以下でIVとして表す）とシード値（以下でシードとして表す）が生成される（６０２）。

【0139】

任意で、必要な委任された認可トークンの数が決定される（６０４）。この数は通常、クライアントが委任された認可を提供することを希望するユーザの数と等しい（場合によってはそれよりも多い）。

【0140】

次に、これらの２つの値に基づいて、第１委任された認可トークンが生成される（６０６）。好ましくは、第１委任された認可トークンは、初期値とシード値の連結に基づいている。より好ましくは、第１委任された認可トークンは、初期値とシード値を入力として使用する一方向関数に基づいている。更に好ましくは、第１委任された認可トークンは、初期値とシード値の連結のハッシュに基づいている。

【0141】

任意で、シード値は、エンティティが再び使用できないように安全に削除される。

【0142】

更なる委任された認可トークンが生成される（６０８）。生成された各委任された認可トークンは、少なくとも以前に生成された委任された認可トークンに基づく。好ましくは、更なる委任された認可トークンの各々は、初期値及び以前に生成された委任された認可トークンに基づいて生成される。以前に生成された認可トークンは、望ましくは、現在生成されている認可トークンの直前に生成された委任された認可トークンを表し、先行する委任された認可トークンとして記述することもある。更に好ましくは、更なる委任された認可トークンの各々は、初期値と以前に生成された委任された認可トークンとの組み合わせに基づいて生成される。更に好ましくは、更なる委任された認可トークンの各々は、初期値と以前に生成された委任された認可トークンとの組み合わせを入力として取り入れる一方向関数に基づいて生成される。更により好ましくは、更なる委任された認可トークンの各々は、初期値と以前に生成された委任された認可トークンとの組み合わせのハッシュに基づいて生成される。更に好ましくは、その組み合わせは、以前に生成された認可トークンに初期値を連結したものである。

【0143】

初期値と以前に生成された委任された認可トークンとの組み合わせは、プレイメージとして記述することができる。

【0144】

以前の委任された認可トークンに初期値をプリペンディングする代わりに（上記の連結）、初期値をまったく使用せず、以前の委任された認可トークンは、生成された以前の委任された認可トークンのみに基づいている。この方法で次の委任された認可トークンを生成するには、以前の委任された認可トークンに対して一方向関数を使用し、その関数の出力が次の委任された認可トークンになる。好ましくは、一方向関数はハッシュ関数である。

【0145】

委任された認可トークンは、好ましくはバイナリ文字列及び／又はバイト文字列の形式である。バイナリ文字列の長さは、使用される一方向関数に依存する。使用される一方向関数がSHA２５６の場合、委任された認可トークンの長さは２５６ビット（又は３２バイト）になる。任意で、このバイナリ文字列は、１６進文字列、base６４文字列、又はその他の適切な符号化方式として表現及び／又は符号化できる。

【0146】

この生成ステップ６０８は、トークンを生成するクライアント５０２が十分なトークンを持っていると判断したとき、及び／又は生成されたトークンの数がステップ６０４で決定された数以上であるときに停止される。

【0147】

好ましくは、上述の方法６００は、委任されたユーザとサービスとの間の相互作用のタイプ毎に生成するために使用される。好ましくは、委任された認可トークンの一方のチェーンは、サービスへの読み取りアクセスのために生成され、委任された認可トークンの他方のチェーンは、サービスへの書き込みアクセスのために生成される。クライアントが読み取り認可を提供したい各ユーザは、読み取りの委任された認可トークンの１つを受け取り、クライアントが書き込み認可を提供したい各ユーザは、書き込みの委任された認可トークンの１つを受け取る。読み取りと書き込みの委任された認可トークンの数は同じである必要はない。

【0148】

任意で、委任されたユーザは複数のトークンを受け取ることができる。これにより、ここで説明されているような書き込みなど、相互作用の制限された例では、委任されたユーザはより多くの書き込みを行うことができる。

【0149】

委任トークンのチェーンの生成に関連するステップ（６０６、６０８）を次の表に示すこともできる。この表では、「読み取り」許可に関連するトークンとデータを表すために「R」が使用され、「書き込み」許可に関連するトークンとデータを表すために「W」が使用される。「H」関数は一方向関数であり、好ましくはハッシュ関数であり、「||」記号は、好ましくはその記号の各辺の連結を表す。各々の４つのトークンは、例としてのみ生成される。トークンの種類毎に異なる番号を使用することもできる。

【表1】

【0150】

上の表から分かるように、委任された認可トークンのチェーンの中の最後の委任された認可トークンはH０ハッシュである。

【0151】

好ましくは、書き込みの委任された認可トークンの場合、トークン当たりの最大書き込み数もある。これは、クライアントが各トークンが実行できる相互作用の数を制限したい場合に、他の相互作用にも拡張できる。

【0152】

上で説明した方法６００の例を、図１０Dを参照して説明する。システム１０７０の例が示され、クライアントがランダムな初期値IVとシードを受け取り、委任された認可トークンのチェーンを生成する。次に、イベントストリーム「生成（create）」メッセージがイベントストリーム（Event Stream）サービスに送信され、イベントストリーム生成メッセージは、最後の委任された認可トークン（H０）と初期値を含む。イベントストリームサービスは、イベントストリームを生成し、最終的なトークンと初期値を生成されたストリームに関連付け、「esid」（event stream identifier、イベントストリーム識別子）により生成メッセージに応答する。esidは、クライアント及び／又は委任されたユーザによる今後の相互作用に使用される。

【0153】

生成要求は、望ましくはJSONオブジェクトであり、以下を含む：

【数2】

【0154】

更なる実施形態によれば、図７は、委任された認可をユーザに提供するために必要な情報を配信する方法７００を示す。

【0155】

任意的に図６に記載された実施形態によって、委任された認可トークンが生成されると（７０２）、クライアントは各委任されたユーザにトークンを提供し（７０４）、プラットフォーム又はサービスが任意の委任されたトークンの有効性を決定するために必要な任意のデータを提供する（７０６）。好ましくは、プラットフォーム又はサービスがトークンの有効性を決定するために必要なデータは、委任された認可トークンのチェーンの中の最後の委任された認可トークン（上記の例に見られるように、WH０及び／又はRH０）及び初期値（上記の例に見られるように、WIV及び／又はRIV）を含む。

【0156】

委任された認可トークンは、本質的にそれらに順序性を持たせ、従ってインデックス付けされることができる。好ましくは、各委任されたユーザにそれらのトークンを提供するとき（７０４）、トークンのインデックスも提供される。

【0157】

委任されたユーザ及びプラットフォームへのデータの提供に関連するステップ７０４、７０６は、順次に提示されるが、それらは任意の順序で、又は同時に実施されてもよい。

【0158】

トークンの各チェーンは、相互作用（例えば、読み取り又は書き込み）毎に生成されるので、方法７００は、クライアントが委任したい相互作用のタイプ毎に実施される。

【0159】

デリゲートは、サービスが設定される前に委任された認可トークンを提供されてもよいし、サービスが実行された後にオンデマンドで提供されてもよい。

【0160】

クライアント５０２は、いつでも、これらのトークンのうちの任意の数又は全部を取り消すことができる。これは、クライアントが、トークンを取り消すサービス（以下の例では、特定のイベントストリームを識別することを意味する）、トークンが取り消される相互作用のタイプ（例えば、読み取り又は書き込み）、取り消されるトークン及び／又は取り消されるトークンのインデックスを示すデータを含む要求を生成することによって実行される。好ましくは、取り消されるトークンとインデックスの両方が使用され、任意で一方のみが使用される。好ましくは、全てのトークンが有効である／取り消されていとして開始され、クライアント５０２はそれらを取り消さなければならない。取り消しの具体例を図１０C及び図１０Eに示す。

【0161】

個々のトークンを取り消すことができると、サービスへのアクセスの管理において、クライアント５０２の柔軟性と制御が向上する。更に、委任されたユーザ５０６は他のトークンを知らず、それらを計算することができないため、クライアントがアクセスを取り消したいときに、未だ有効である／取り消されていない他の委任されたユーザに通知する又は更新する必要がなく、それによって計算リソースと時間を節約する。

【0162】

委任された認可トークンの使用
図８を参照すると、更なる実施形態による方法８００が示されており、サービスと相互作用する要求を受信し（８０４）、検証し（８０６）、及び処理する（８０８）プロセスが説明されている。本実施形態では、説明を容易にするために、この方法８００は、プラットフォーム上で実行されるサービスによって実行されるものとして説明されている。別の実施形態では、プラットフォームは、ここで方法８００を実行するように構成された更なるプロセスを実行している。このプロセスは、「認可サービス」又は「アクセス制御サービス」として記述することができ、任意で、相互作用されるサービスと同じプラットフォーム５０４上で実行される。更に別の方法として、認可サービスは、サービスが要求を受信する前にフィルタとして動作する。

【0163】

委任されたユーザから要求を受信するステップの前に、サービスは、委任された認可トークンを生成したクライアントから適切な妥当性確認データを受信する（８０２）。妥当性確認データは、少なくとも、委任された認可トークンのチェーンの中の最終ハッシュ（又は最後の委任された認可トークン）を含む。この最後のトークンは、クライアントから受け取った最後の委任された認可トークンとしても記述される。この最終ハッシュは、ここで使用されているように、H０、R_H０、又はW_H０として表すことができる。好ましくは、妥当性確認データは、図６を参照して上述したように、委任された認可トークンのチェーンを生成するプロセスで使用される初期値も含む。

【0164】

サービスは、委任されたユーザからの要求を妥当性確認する前に、任意の時点でこのデータを受け取ることができる（８０２）。好ましくは、新しいイベントストリームが生成されるときに、妥当性確認情報がサービスに提供される。

【0165】

しばらくすると、サービスは、委任されたユーザから、サービス及び／又はイベントストリームを使用するための要求を受け取る（８０４）。これらの要求は、委任された認可トークンを含む。要求が委任された認可トークンを含まない場合、又はクライアントからのものでない場合は、有効とはみなされない。クライアントからの要求は、望ましくは、委任された認可トークンを必要とせず、別のシステムを使用して妥当性確認又は認証される。

【0166】

サービスは、委任された認可トークンと妥当性確認データに基づいて、要求の有効性を判断する（８０６）。このステップは、図９A～Dに関してより詳細に説明する。妥当性確認は、受け取った委任された認可トークンから最後の委任された認可トークンまで、委任された認可トークンのチェーンのサブセットを再生成することを含む場合がある。再生成された最後の委任された認可トークンが、クライアントが受け取った最後の委任された認可トークンと同じである場合、受け取った委任された認可トークンは有効である。

【0167】

任意で、サービスは、委任された認可トークンが取り消されたかどうかに基づいて、要求の有効性を更に判断する。このサービスと相互作用に対してトークン及び／又はインデックスが取り消された場合、要求は無効であることが分かる。

【0168】

最後に、ステップ８０６で決定された有効性に応じて、要求が処理される。トークンが有効でない場合、要求は処理されない。

【0169】

この方法８００が認可サービスによって実行される場合、処理ステップ８０６は、妥当性確認の結果に関する指示をサービス及び／又はプラットフォームに提供する認可サービスを含む。代替として、認可サービスがフィルタとして機能する場合、処理ステップ８０６は、要求をドロップすることを含み、トークンが無効である場合、要求をサービスに転送しない。トークンが有効である場合、それは、任意で、要求が有効であることを示す追加情報と共に、サービスに要求を渡す。

【0170】

図９A～Dに示す方法は、サービスが受信した委任された認可トークンを妥当性確認する方法の様々な例を示している。第１方法９００は、第１要求が受信されたときを示している。委任された認可トークンのチェーンは、受信された委任された認可トークンから開始して、再生成される。第２方法は、更なる要求が受信されたときに、それが以前に受信された委任された認可トークンよりもチェーン内で上位にあり、サービスが計算しなかったようなインデックスを持つ場合を示す。第３方法は、別の更なる要求が受信されたときに、それがチェーン内で下位にあり、サービスが既に計算したようなインデックスを持つ場合を示す。

【0171】

「上位」と「下位」がチェーンに関して使用されている場合、これは提供されるインデックスを表す。「上位」は、高いインデックス番号を有し、最終的に委任された認可トークンから離れていることに関連し、「下位」はその逆である。インデックス０は最も低いインデックスであり、チェーンの中の最終／最後に生成された委任された認可トークンにインデックスを付ける。インデックス０の委任された認可トークンは、前述の検証目的でクライアントによって提供されるトークンである。

【0172】

好ましくは、妥当性確認方法は、クライアントが委任された認可トークンのチェーンを構築するのと同じ方法を使用する。第１、第２及び第３例示的な状況の方法９００、９２０、９４０は、ハッシュチェーン（又はそのサブセット）が、それが生成されたのと実質的に同じ方法を使用して再構築されることを示している。

【0173】

図９Aは、トークンがサービスによって最初に受信される（９０２）、第１妥当性確認方法９００を示している。第１要求は、最初に受信された委任された認可トークンを含む。好ましくは、要求はインデックスも含む。

【0174】

これは最初に受信された委任された認可トークンであるため、サービスは委任された認可トークンのチェーンの他の部分を生成していない。

【0175】

次に、最初に受信された委任された認可トークンから開始して、委任された認可トークンのチェーンが再生成される。チェーンは、前述のように生成したのと同じ方法を使用して生成される。従って、チェーンは、初期値を最初に受信した委任された認可トークンと連結し、それをハッシュしてチェーンの中の次の委任された認可トークンを受信することによって生成されることが好ましいである。このステップは何度も繰り返される。インデックスが要求の中に存在する場合、生成されたチェーンの中の委任された認可トークンの数はインデックスに基づく。インデックスは、委任された認可トークンのチェーンの中の最後の委任された認可トークンからの距離とみなすことができる。最後の委任された認可トークンが生成されるまで、更なる委任された認可トークンが生成される。例えば、要求の中のインデックスが３の場合、次に示すように、更に３つのハッシュが生成される（H２’、H１’、H０’）。この記号は、受信した委任された認可トークンに基づくチェーンであり、クライアントが生成したチェーンと同じではない可能性があることを示すために使用される。ここでは、読み取り（「R」）、書き込み（「W」）、又はその他の相互作用でプロセスが同じであるため、「R」と「W」は使用されない。

【数3】

【0176】

H０'の取得は、次の１つの式で行うこともできる：

【数4】

【0177】

好ましくは、受け取った委任された認可トークン（H３'）及びチェーンの中の中間ハッシュH２'及びH１'（これらも委任された認可トークンであり、将来のデリゲートによって使用される可能性がある）の各々は、トークンが有効であることが判明した場合に将来使用するために格納される。これらの中間トークンの使用は、図９Cに示す以下の例示的な方法９４０に関連して更に説明される。更に好ましくは、受信された及び生成された委任された認可トークンは、チェーンの中の位置に従ってインデックス付けできるように、データ記憶メカニズム（アレイ、データベース、ハードドライブ、又はその他の同様のシステム又はモジュール）に格納される。有利なことに、委任された認可トークンをそれらのインデックスに関連付ける（インデックス付けとも呼ばれる）ことにより、図９Cを参照して説明された状況のように、検索が容易になる。トークンが無効であることが判明した場合、構築されたチェーン全体は格納されない及び／又は削除される。

【0178】

最初に受信したトークンの有効性は、上述した妥当性確認方法８００の第１ステップ８０２において、生成された最終ハッシュH０’と妥当性確認データの一部としてクライアントから受信した最終ハッシュとの比較に基づいて決定される。H０とH０’が等しい場合、委任された認可トークンは有効である。

【0179】

代替として、インデックスが使用されていない場合は、委任された認可トークンが継続的に生成され、生成された各トークンがH０と比較されるように、方法が変更される。比較が成功するか、トークンの最大数に達すると、プロセスは停止する。最大数に達しても比較が成功しない場合は、最初に受信した委任された認可トークンが無効であることが分かる。

【0180】

図９Bを参照すると、方法９２０が示されており、そこでは、委任された認可トークン及びインデックスも含む更なる要求が受信される（９２２）。説明のために、この例示的な方法では、委任された認可トークン及び／又はインデックスは、以前にサービスによって認識されておらず、事前に計算された委任された認可トークンのチェーンには存在しない。

【0181】

受信されると、サービスは、委任された認可トークンが以前に生成されたチェーンに既に存在するかどうかを決定する（９２４）。好ましくは、インデックス付けされたデータ記憶メカニズムを使用して、インデックスに基づいて検索が行われる。データ記憶メカニズムがアレイの場合、これはインデックスのエントリにあるデータにアクセスすることを意味する。この例では、インデックスには委任された認可トークンは存在しない。

【0182】

インデックスを使用して委任された認可トークンをインデックス付けする代わりに、方法は格納されている全ての委任された認可トークンをループし、存在するかどうかを確認することもできる。

【0183】

トークンは現在格納されているチェーンに未だ存在しないため、クライアントによって生成されたチェーンに存在することを確認するために、委任された認可トークンチェーンを更に生成する必要がある。チェーンは、前述と同様に／同じように構築される（これは、望ましくは、初期値を更なる受け取った委任された認可トークンと連結し、それを一方向の関数に繰り返し渡すことである）。好ましくは、チェーンの中の最後の委任された認可トークン（H０）までこれらのステップ全部を繰り返すのではなく、これらのステップは、委任された認可トークンのチェーン内で最初に生成された又は受信された委任された認可トークンに遭遇するまで繰り返される。トークンの生成方法は決定論的であるため、開始データが同じであれば、同じチェーンが生成される。これは、第１委任された認可トークンだけでなく、チェーンの中の任意のポイントから開始する場合にも当てはまる。

【0184】

一方向関数が使用されるため、チェーンの構築では、サービス（又は他のデリゲートを含むシステム内の他の装置）は、トークンの前に初期値が付加されている場合でも、任意の所与のポイントからチェーンの上位にある委任された認可トークンを計算できない。これは、出力を有していても入力を算出できないという、一方向関数の特性である。従って、チェーンは常に、任意の受信した委任された認可トークンから順方向に構築する必要がある。

【0185】

例えば、受信したトークンのインデックスが５であり、インデックス３、２、１、０（H３、H２、H１、H０）の委任された認可トークンが既にデータ記憶メカニズムに格納されている場合、更なる受信された委任された認可トークンが有効かどうかを決定するには、次の計算を実行するだけでよい：

【数5】

【0186】

H３'が既に格納されているH３と等しい場合、チェーンの残りの部分は同じになり、更なる受信された委任された認可トークンが有効になり、残りの連結及び一方向関数のステップをスキップできる。H３'がH３と等しくない場合、残りのチェーンも異なり（従って、計算もスキップできる）、委任された認可トークンは無効になる。

【0187】

従って、この例では、受信された委任された認可トークンの有効性は、現在生成されている委任された認可トークンのうちの委任された認可トークンの１つ（好ましくは、現在生成されている委任された認可トークンの最後のもの）と、格納されている及び／又は以前に生成された委任された認可トークンとの比較に基づいて決定される。好ましくは、格納された及び／又は以前に生成された委任された認可トークンの最も高いインデックスを持つトークンである。

【0188】

最も高いインデックスを持つ格納された委任された認可トークンは、有効であることが判明した以前に受信された委任された認可トークンである可能性が高い。従って、本方法は、任意の以前に受信された委任された認可トークンのうちの最高インデックスを決定し、以前に受信された有効な委任された認可トークンのインデックスと等しいインデックスを有する委任された認可トークンが生成されるまで、受信した委任された認可トークンに基づいて更なる委任された認可トークンを生成し、最後に生成された委任された認可トークンと、以前に受信された委任された認可トークンとの比較に基づいて、受信した委任された認可トークンの有効性を決定することを更に含む。受信したトークンが有効である場合、このトークンは、任意の以前に受信したトークンのうち最も高いインデックスを持つトークンになる。

【0189】

図９Cを参照すると、例示的な方法が示されており、そこでは、別の更なる委任された認可トークン及びインデックスを含む別の更なる要求が受信される（９４２）。この例では、トークンは既に委任された認可トークンの格納されたチェーンの一部である。このトークンが以前に使用されたことがあるか、このトークンを受信する前に、より高いインデックスを持つ有効なトークンを受信したために、トークンが既に格納されている可能性がある。

【0190】

受信された別の更なる委任された認可トークンとそのインデックスがあれば（９２４）、（この例では）そのインデックスに関連付けられて事前に生成され格納されている委任された認可トークンがあると決定される（９４４）。好ましくは、この決定は、与えられたインデックスにおける委任された認可トークンについてデータ記憶メカニズムに問い合わせることを含む。別の更なる受信された委任された認可トークンと、インデックスに関連付けられて格納された委任された認可トークンとの間で比較が行われる。トークンの有効性は、この比較に基づいている。好ましくは、トークンが同じであれば、受け取ったトークンは有効である。トークンが同じでない場合、受け取ったトークンは無効である。

【0191】

好ましくは、第１、第２及び第３方法９００、９２０、９４０は、委任された認可トークンを妥当性確認するために一緒に使用される。有利なことに、これらの方法９００、９２０、９４０は、委任された認可トークンが受信されるたびに委任された認可トークンのチェーンを計算する必要がないように、キャッシュを提供するので、強力なアクセス制御セキュリティを提供しながら、コンピュータ処理能力と時間を節約する。多数のデリゲートが存在する場合、ハッシュ処理は計算に時間がかかるかもしれない。

【0192】

代替として、第１方法９００のみが使用される。第１方法９００のみが使用される場合、委任された認可トークンのチェーン全体は、全ての要求が受信されると生成され、チェーンは格納されない。これは、使用されない可能性があり、強力なアクセス制御セキュリティを維持する中間の委任された認可トークンを記憶する必要がないという利点を提供する。

【0193】

図９Dを参照すると、全体的な方法９６０は、これらがいつどのように発生するかを示すために示されている。委任された認可トークンとインデックスを含む任意の要求が受信されると（９６２）、それが以前に計算され、データ記憶装置に格納されているかどうかについての決定が行われる（９６４）。

【0194】

委任された認可トークンが以前に生成されていない場合、インデックスから開始して、最後の委任された認可トークンが生成されるか、又は以前に計算された／受信された既知の有効な委任された認可トークンが生成されるまで、更なる委任された認可トークンが生成される（９６６）。生成された委任された認可トークンのいずれかが、以前に受信又は生成された委任された認可トークンと値及びインデックスの両方で等しい場合、受信されたトークンは有効であるとみなされる。好ましくは、以前に受信又は生成された委任された認可トークンのインデックスが満たすのに十分な数の委任された認可トークンのみが生成される。例えば、H３が以前に受信又は生成され、H５’が現在受信されている場合、H５’、H４’、及びH３’のみが生成される。現在受信されているトークンの有効性は、最も低いインデックスを有する現在委任されている認可トークンと、最も高いインデックスを有する以前に受信又は生成された委任された認可トークンのインデックスとを比較することによって決定される。例えば、図９Bに関して前述したように、H３とH３’を比較する。

【0195】

書き込みの委任された認可トークンを妥当性確認する場合、好ましくは、クライアントは、上述した妥当性確認方法８００の第１ステップ８０２において、妥当性確認データの一部として「最大書き込み数」の値も提供する。好ましくは、別の妥当性確認ステップを使用して、委任されたユーザが許可されたより多くのデータをサービスに書き込まないようにする。サービスは、各委任された認可トークンに関連付けられた「書き込み回数」の値を格納する。これは０から始まり、委任されたユーザがサービスに書き込むたびに増加する。トークンの妥当性確認の後、「最大書き込み数」の妥当性確認も実行される。この妥当性確認では、「書き込み回数」と「最大書き込み数」が比較される。委任された認可トークンの「書き込み回数」が「最大書き込み数」の値以上の場合、要求は処理されない。それ未満の場合は、「書き込み回数」の値がインクリメントされ、要求が処理される。任意で、「書き込み回数」は、要求がイベントストリーム及び／又はブロックチェーンに正常にデータを書き込んだ場合にのみインクリメントされる。当業者は、これが書き込み以外の他の相互作用にも適用できることを理解する。書き込みは単なる例として使用された。

【0196】

幾つかの実施形態では、要求はHTTP（Hypertext Transfer Protocol）要求又はHTTPS（Hypertext Transfer Protocol Secure）要求の形式である。任意で、委任された認可トークンはHTTP（S）要求のヘッダに格納される。任意で、ヘッダは次の形式である：

【数6】

【0197】

２つの値delegatedAuthIndexとdelegatedAuthのBase６４符号化は任意である。代替として、２つのバイナリ表現が使用される。

【0198】

有利なことに、委任された認可をヘッダに移動することによって、認可プロセスはRFC７２３５に記述されているBasic HTTP Authenticationフレームワークとの互換性を高めることができる。

【0199】

単一のデリゲート
読み取り及び／又は書き込みに１つのデリゲートのみが必要な場合、一方向関数への入力として使用される初期値とシード値の組み合わせに基づく、図６を参照して説明されている方法６００を使用して、１つのハッシュのみが生成される。サービスは、妥当性確認の目的で、この「最終的な」（及び唯一の）委任された認可トークンを受け取る。再構築する委任された認可トークンのチェーンがないため、初期値は使用されない。そのため、クライアントは彼らが望む任意のランダムなデータをサービスに渡すことができ、或いは何も渡さない。サービスは最後の委任された認可トークンのみを受け取るため、受信した要求の妥当性確認は、受信した要求の委任された認可トークンと最後の委任された認可トークンの比較になる。その他のトークンは無効になる。

【0200】

プラットフォームシステム
ある態様によれば、クライアントの委任に関連する上記のいずれか１つ以上の態様を、ここに記載されているようなプラットフォームプロセッサと共に使用することができる。好ましくは、クライアント委任の態様は、API１５０８によって提供されるデータサービス１５０２、計算サービス１５０４、及び／又は商取引サービス１５０６へのアクセスを委任する際に使用される。委任されたアクセスは、読み取り、書き込み、読み取り／書き込み、送信、及び／又は特定のサービスに関連付けられ得る他の任意のアクションの形式であることができる。本態様は、BSVブロックチェーンのようなブロックチェーンネットワークを使用して、ソフトウェア制御技術システム又はスマートコントラクトの管理など、実用的な実世界のビジネス及び技術アプリケーションの迅速な供給を有利に可能にするサービスとしてのプラットフォーム（PaaS）及びサービスとしてのソフトウェア（SaaS）である場合がある。

【0201】

図１０A～図１０Eを参照して、プラットフォームサービスとの相互作用の例（図１１～図１３を参照して以下で詳細に説明）を示す。示されている相互作用の例は、イベントストリームへのイベントの追加、イベントストリーム上のイベントのクエリ（又は読み取り）、委任されたユーザのイベントストリームとの相互作用の取り消し、イベントストリームと委任された認可トークンの生成、及びシステムの様々な実施形態と側面を含む全体的な方法である。これらは、委任された認可トークンがイベントストリームとプラットフォームサービスのコンテキストでどのように使用されるかの例として提供される。

【0202】

これらの実施例では、（前の実施例で説明したように）プラットフォームは、イベントストリームサービス１００４、クライアント認可サービス１００６、データベース１００８、及びメッセージバス１０１０を含む多くのコンポーネントを含む。

【0203】

これらの例では、プラットフォームサービスは多数の異なるEventStreamを提供し、従って、クライアント及び／又は委任されたユーザは、相互作用したい特定のEventStreamの識別子を提供する。従って、要求は更にサービス識別子を含む。任意で、プラットフォームが相互作用するためにそのようなサービスを１つだけ提供する場合、識別子は必要ない。

【0204】

図１０A以降では、前述のようにクライアント５０４又は委任されたユーザ５０６であるクライアントアプリケーション１００２が、イベントストリームサービス１００４にイベントを追加している。クライアントアプリケーション１００２は、イベントストリームサービスに「appendEvent」要求を送信する。「appendEvent」要求は、イベントに関連付けられたデータと、クライアントアプリケーションが委任されたユーザである場合には、委任された認可トークンとインデックスとを含むdelegatedAuth情報を含む。クライアントアプリケーションがクライアント５０２である場合には、（上記で説明した、又は特に図８を参照して説明した認可サービスとは別の）クライアント認可サービス１００６を使用して、異なるクライアント認可プロセスが実行される。

【0205】

イベントストリームサービス１００４は、データを妥当性確認し、要求に関連付けられた委任された認可情報がある場合には、その情報をデータベース１００８に渡す（１０１４）。データベースは、図８～９Dを参照して説明された妥当性確認方法を実行し、以前に生成された委任された認可トークンを格納するように構成される。データベースは、受信した委任された認可情報に対して、委任された認可の有効性（図示せず）により応答する。これは書き込みサービスであるため、データベースは、使用される特定の委任された認可トークンに関連付けられた書き込みの回数が、事前に定義された「最大書き込み数」を超えていないことも妥当性確認する。

【0206】

有効な認可の指示子を使用して、イベントストリームサービス１００４は、追加情報の処理を続行する。これには、イベントをデータベース１００８に挿入する（１０１６）、イベントのインデックスを受信する（１０１８）、メッセージバス１０１０を介してイベントをブロックチェーンに発行する（１０２０）、請求処理を完了する（１０２２）、及びイベントが正常に追加されたことの指示により、クライアントアプリケーション１００２に最終的に応答する（１０２４）ことが含まれる。

【0207】

図１０Bを参照すると、クライアントアプリケーション１００２は、イベントストリームサービス１００４からのデータの読み取りを要求している。クライアントアプリケーション１００２は、イベントストリームサービス１００４に「queryData」要求を送信する。イベントストリームサービス１００４は、パラメータを妥当性確認し、「appendEvent」の例１０００と同じ又は類似の方法で、承認するか（１０１４）（委任された認可トークンが存在する場合）、認可する（別のクライアント認可サービスが使用されている場合）。これは読み取りサービスであるため、望ましくは、記録すべき最大読み取り数、書き込み数、又はその他の最大相互作用数がない。

【0208】

クライアントアプリケーション１００２が認証又は認可されると、データクエリの一部である任意のフィルタ（時間範囲、データの種類、データを提供したユーザなど）がデータベースクエリを構築するために使用される。データベースクエリはSQL形式であってもよい。クエリがフォーマットされた状態で、選択の形式でデータベース１００８に送信される。請求情報は、他のサービスが確認及び管理するために、メッセージバス１０１０に送信される（１０３４）。最後に、要求されたデータは、JSON応答の形式でクライアントアプリケーションに返される（１０３６）。

【0209】

図１０Cでは、クライアントアプリケーション１００２は、委任された認可トークンを取り消すことを望んでいる。好ましくは、クライアント５０２のみがそのようなアクションを実行することができ、従って、委任された認可トークンが承認されるオプションはなく、クライアント認証方法のみが利用可能である。

【0210】

クライアントは、取り消すべきPUTメソッドを含むHTTP要求をイベントストリームサービス１００４に送信する（１０５２）。要求は、以下を含む：
・EventStreamのIDであるesid。
・accessType。これは、データベースが参照するEventStreamに関連付けられたチェーンを認識できるように、クライアントが変更しようとしている相互作用であり、好ましくは「読み取り」又は「書き込み」である。
・index。これは、チェーンの中の委任された認可トークンのインデックスである。
・token。これは、委任された認可トークンである。

【0211】

これらのパラメータが妥当性確認され、クライアントが承認される。

【0212】

イベントストリームサービス１００４は、委任されたユーザ情報を格納しているデータ記憶メカニズムを更新するために、データベース１００８に更なる要求を送信する（１０５４）。好ましくは、各委任された認可トークン及び／又は各インデックス（全ての委任された認可トークンが知られていない可能性があるため）に関連付けられた列、フラグ又はその他のデータがある。このデータは、正しいインデックスと委任された認可トークンが提供された場合でも、トークンが有効とみなされないことを反映するように更新される。代替として、サービスに関連付けられている「最大書き込み数」がある場合は、その委任された認可トークンの書き込み回数が「最大書き込み数」に等しく設定される。これにより、今後の全ての相互作用が無効になる。

【0213】

データベース１００８は、委任された認可トークンが使用された回数をイベントストリームサービス１００４に返す（１０５６）。請求情報は、他のサービスが確認及び管理するために、メッセージバス１０１０に送信される（１０５８）。最後に、取り消しが成功したかどうかを含む応答が、望ましくはJSON応答の形式で、クライアントアプリケーションに返される（１０６０）。任意で、応答は、取り消された委任された認可トークンを使用して相互作用が行われた回数も含む。

【0214】

上述したように、図１０Dは、クライアントが第２態様及び図６による方法に従って委任された認可トークンのチェーンを生成し、イベントストリームサービス上にイベントストリームを生成するシステム１０７０を示している。

【0215】

図１０Eを参照すると、本明細書に記載された多数の実施形態及び特徴を含む全体的なシステムが示されている。クライアントは、委任された認可トークンのチェーンを生成し、図１０Dを参照して記載されたイベントストリームを生成する。後の時間に、必ずしも直後ではなく、クライアントは、デリゲートがイベントストリームと相互作用するために必要な詳細を提供する。詳細には、イベントストリームサービス上のどのイベントストリームと相互作用するかを識別するための識別情報（図では「esid」）、委任された認可トークン（図では「H」）、及びインデックス（この例では「３」）が含まれる。この情報を使用すると、デリゲートは「appendEvent」要求を使用してイベントストリームサービスにデータを送信するのに十分な情報を有することになる。要求は、クライアントから受信したものと同じ詳細の全部と、デリゲートがイベントストリームに送信したいデータとを含む。

【0216】

図１０Eは、発生している取り消しの例も示している。ここで、クライアントは委任された認可トークンを取り消す要求を送信する。要求は、（esid）からトークンを取り消すべきイベントストリーム、トークンのインデックスを持つトークン自体、及び取り消すべき相互作用の種類（この例では「書き込み」）を識別する。有効なトークンとインデックスが所与のイベントストリームについて一致する場合、イベントストリームサービスはトークンを無効にする。

【0217】

プラットフォームサービスの概要は、システムの高レベルの概要を示す図１１に示されている。プラットフォームサービスは、API１５０８を提供するプラットフォームプロセッサ１５００を有し、それを介して、１つ以上のクライアントがサービスにアクセスすることができる。

【0218】

この図１１に示されているプラットフォームサービス１５００は、３つのサービスファミリで構成されており、ユーザと組織が、クライアント側で実際にブロックチェーンベースのソフトウェア、知識、又はライブラリを実装することなく、ブロックチェーンの固有の特性によって提供される利点を簡単かつ安全に利用できるようにすることを目的としている。これらのサービスは次の通りである：
・商品データ台帳としてのチェーンの使用を簡素化することを目的としたデータサービス１５０２。データサービスは、望ましくは、ブロックチェーンへのデータの書き込みと読み取りを実装するために、ここで提供されるデータ構造と方法を使用する。
・BitcoinSVなどのデジタルアセットに裏付けられた汎用コンピューティングフレームワークを提供することを目的としたコンピューティングサービス１５０４。
・BitcoinSVなどのデジタルアセットを使用して取引するためのエンタープライズクラスの機能を提供するコマースサービス１５０６。

【0219】

APIはWebサービスとして実装されているため、APIにおいてクライアントからHTTPSプロトコルを介して又はHTTPSプロトコルを使用して要求を受信できる。次に、要求されたサービスは、ブロックチェーンに関連付けられている基礎ソフトウェア１５１０のような基礎ソフトウェア１５１０を使用して、１つ以上のサービスモジュール又は処理リソース１５０２～１５０６によって実装され、つまり、ブロックチェーンに関連付けられたトランザクションを生成、処理及び送信するためのリソース、ライブラリ及び／又は鍵管理ウォレットの実装が実装される。一度処理されると、トランザクションは（クライアントがそのような機能又はトランザクションライブラリを実装するのではなく）ブロックチェーンネットワーク１５１２に送信できる。多くても、クライアントは、暗号通貨又は他のデジタルアセットに関連するデジタルウォレットなどを実装するだけでよく、又は実装することができるが、プラットフォームサービス１５００は、クライアントのためにデジタルアセットを提供し、管理することもできるので、これは必須ではない。

【0220】

図１２は、ブロックチェーンに関連する複数のサービスのより詳細な概略図を提供し、これらのサービスは、提供されるサービスのいずれか１つ以上にアクセスできるAPIに関連するプラットフォーム１６００によって実装することができる。この図１２に見られるように、データサービス１６０２は、データ書き込みサービス１６０２a及びデータ読み取りサービス１６０２bを含むことができる。上記のような委任された認可は、イベントストリーム、及び／又はデータ書き込み部、及び／又はデータ読み取り部への委任されたアクセスを提供するために使用されることが好ましい。同様に、データ読み取り部１６０２bを使用してデータアーカイブにアクセスすることを望む委任されたユーザは、上記の説明に従って委任された認可を有することが望ましい。イベントストリームの更なる詳細は、英国特許出願第２００２２８５．１号（２０２０年２月１９日にnChain Holdings Limitedにより出願）の図４から図８を参照して議論され、参照によりここに組み込まれる。データ書き込みサービス１６０２aは、クライアントが簡単、安全かつ最適化された方法でブロックチェーンにデータを書き込むことを可能にする。データ読み取りサービス１６０２bは、クライアントがクエリを送信して、それが、ブロックチェーンに格納されているデータを返すことを可能にする。これは、クライアントが、特定の時間枠内で、アドホックに又は定期的にブロックチェーンから読み取りたいデータのタイプ、又はブロックチェーン１６１０で処理される一連の関連する又は関連しないイベント又はドキュメントに関連付けられているデータのタイプを事前に定義することができるフィルタ処理されたストリームを使用することであってよい。データアーカイブ機能は、指定されたイベント又はコントラクトの以前のトランザクションのログへのアクセスを許可する。

【0221】

プラットフォーム１６００のコンピューティングサービス１６０６は、スマートコントラクトに関連付けられたアプリケーション１６０６a及びフレームワーク１６０６bを含み、幾つかの実施形態では、これらはブロックチェーン１６１０内のステートマシンとして表される。コンピューティングサービス１６０６は、データが入力され、そのような計算のためにクライアントに結果が提供される必要があるので、データサービス１６０２と相互作用する。

【0222】

コマースサービス１６０４は、最高クラスのセキュリティ慣行と技術に基づいて、ブロックチェーン１６１０を介して取引するためのエンタープライズウォレット１６０４aを介して、エンタープライズクラスの機能を提供する責任を負う。例えば、幾つかの実施形態では、エンタープライズウォレットは、複数の人、ユーザ、又はアカウントが定義された基準を満たすトランザクションでサインオフする必要がある場合に、ブロックチェーントランザクション処理を可能にする機能を実装することができる。すなわち、特定の事前定義された制限を超える大きな価値の暗号通貨に関連付けられる。エンタープライズウォレットには、別のリソースを表す暗号通貨やトークンなどの大量のデジタルアセットを移動するための閾値数の及び／又は種類の署名を実装する機能も含まれる場合がある。これらの資産の移動は、そのようなエンタープライズウォレットの実装によって適用される基準に基づいて処理された後、ブロックチェーン上で表現できる。

【0223】

SPVサービス１６０８（簡略化された支払い検証）は、ブロックチェーンからの情報を必要とするアプリケーションであるが、マイナーノードを実行しないため、ブロックチェーンへの直接リンクは含まれない。このようなSPVサービス１６０８は、軽量クライアントが、ブロックチェーン１６１０全体をダウンロードすることなく、トランザクションがブロックチェーンに含まれていることを検証することを可能にする。

【0224】

＜例示的な使用例＞
ここで説明するシステムと方法は、スマートコントラクト、ブロックチェーン、より具体的にはイベントストリームに関連して、多くの異なる使用シナリオを可能にする。ここで提供される使用例は例であり、当業者は、より多くの使用が可能であることを理解する。当業者は、具体的にイベントストリームに言及しているが、これらの例は、他のスマートコントラクト技術、他のブロックチェーン技術、又は同様のものを使用して実行することもできることを理解する。

【0225】

例１：投票サービス
一般市民があるテーマ又は別のテーマについて投票する機会を提供されるケースが増え続けている（例えば、The Voice、Strictly、Goal of the Month、Favorite Artistなど）。このような投票には、制限された期間内に投票（又は複数の投票）を希望する潜在的に多数の独立した人々が関与している。このような一般投票では、通常、電話イン、Web、電話アプリのフロントエンドが使用される。ここで説明する実施形態は、イベントストリームと委任された認可を使用して透明性と一般的な投票検査を提供する、低コストのスケーラブルなバックエンドを提供できる。

【0226】

投票マスター（前述のようにクライアント５０２として機能する）が、投票者のグループ（前述のように委任されたユーザ５０６として機能する）の間で投票を行いたいとする。各投票者は、制限された期間内に１からN回の投票を行うことができる。これは、次のようにイベントストリームサービスと委任された認可トークンを使用して実現できる。
１． 投票マスターは、一連のdelegatedAuthトークンとそのdelegatedAuthIndex値（これらを総称して「投票者認可トークン」（Voter Authorisation Tokens （VAT））と呼ぶ）を生成して、投票期間の開始前に有権者に配布する責任がある。個々の有権者は、投票が行われるときに表示するために自身のVATを保存する。
２． 投票マスターは、特定の時刻に開始及び終了するイベントストリームを生成する。
３． 投票者は、appendEventエンドポイントを呼び出すことによって、投票期間内であればいつでも投票を行うことができる。投票は、有効なVATと共に提示される必要がある。
４． 各投票はVATを使用して承認され、sequenceNumberを使用せずにストリームに追加される。通常、個々のイベントの順序は重要ではない。ストリームは、イベントストリームの生成中にオプションで提供された最大書き込み数を使用して、VATあたり１～N回の投票を受け入れるように構成できる。
５． 投票期間の終了時に、投票マスターはイベントストリームを終了し、queryDataエンドポイントを使用して投票を集計する。監査人は、委任された読み取りアクセスを使用してqueryDataを使用して投票を反復処理し、必要に応じてイベントデータを妥当性確認し、チェーン上のストリームの状態を検証することもできる。

【0227】

この投票サービスの特徴は以下を含む：
・投票は、有効なVATを所有する有権者の人口に厳密に制限される。
・投票者１人あたりの最大投票数は、投票期間前に投票マスターによって厳密に制限される。
・投票期間は投票マスターの直接制御下にあり、投票マスターは、ストリームを生成するときに固定の開始時間と終了時間を設定できる。
・イベントストリームサービスは投票者のIDを認識しないため、１つの投票を別の投票よりも優先する根拠はない（ただし、投票者のIPアドレスが知られる可能性がある）。
・投票はおおよそ到着時間順に記録される。
・全ての投票の記録は変更不可能であり、特にイベントストリーム技術とより一般的なブロックチェーン技術の結果として監査可能である。イベントメッセージ自体は（投票マスターによって設定されたルールに従って）難読化されている場合とされていない場合があり、公開監査の実用性を決定する。

【0228】

イベントストリームを生成するときに使用される構成データの例：

【数7】

【0229】

ここでのイベントストリームとブロックチェーン技術の使用は、他の「公開」投票状況では通常見られないレベルの透明性を提供するという利点がある。投票は、任意の投票者がデータセット内の自分の投票を確認し、自分で投票の結果を計算できるように構成されてよい。このような投票の結果は、投票データが平文で格納されている場合はすぐに利用できるが、投票データが難読化されている場合は、投票マスターが投票の結果を宣言するまで待機する必要がある。

【0230】

VAT分配
公正な投票のために、VATは投票期間の開始前に有権者に分配されなければならない。VATは、使用例にとって実用的な方法で分配することができる。例えば、各VATを電話アプリに分配することができる。VATは、登録されたユーザに関連付けられている場合と関連付けられていない場合がある。

【0231】

別の方法として、VATをアカウントデータに保持し、アカウントユーザにWebインタフェースを提供することもできる。

【0232】

別の方法として、ダイヤルアップ電話サービスを、通話及び／又はキーパッド入力を投票データに変換するドライバーに接続し、各々をVATのキャッシュに関連付けることもできる。

【0233】

各投票者アプリケーションは、VAT_Nと呼ばれる委任された認可トークンとインデックスNとを含むVATを受け取る。トークンとインデックスは、両方とも、投票が行われるたびに提示される必要がある。

【0234】

VAT検証
イベントストリームを生成するときに、WIVとWH０が提供されているため、イベントサービスは、通常のクライアント認証データではなく、VAT_NとNを含むappendEventの呼び出しを期待する。検証プロセスは、図８及び図９A～Dを参照して前述したものと同じか類似している。前に分かっている場合、サービスは、VAT毎の最大投票数の構成と、VAT_Nを使用して投じられた以前の投票数に応じて、投票を受け入れるか拒否する。前に分からない場合、サービスはVAT_NをN回繰り返しハッシュし、最終結果をWH０と比較する必要がある。これらが等しい場合、投票は承認され、記録される。例えば、N=３の場合、WH０がH（WIV||H（WIV||H（WIV||H（WIV||VAT３））））に等しい場合、投票は受け付けられる。

【0235】

投票の評価
投票を評価し、結果を決定するのは、投票マスターの単独の責任であることが望ましい。

【0236】

例２：機器アクティビティログ
ハイエンド機器メーカーは、保証契約又はサービス契約の一部として、顧客の機器の重要なアクティビティログへのアクセスを希望する場合がある。ログを分析することで、メーカーは、機器が最高の効率で動作していることを確認するための積極的な措置を講じることができる。委任された認可トークンを機器に工場出荷時に取り付けることで、機器がその有効期間中（登録から開始する）に重要なイベントを自動的に記録できるようになる。

【0237】

この場合、次のことが推奨される：
・メーカーは、製品ライン毎に個別のイベントストリームを構成できる。
・委任された認可トークンは、メーカーのクライアントデータベースに記録されているデリゲートインデックスを使用して、工場で装置に取り付けられる。
・装置は、登録から開始する有効期間中に重要なイベントを自動的に記録する。
・メーカーは、以下を含む任意のアクティビティをリモートで監視できる：ハートビート、実行時間、重要なコンポーネントの変更、認定された材料の使用など。

【0238】

イベントストリームを生成するときに使用される構成データの例：

【数8】

【0239】

例３：入札による入札プロセス
誠実でオープンな入札プロセスを行いたい地方議会を考える。議会は、要件と落札の根拠を明確に特定する入札文書を発行する。

【0240】

２０社が入札の意思を登録したとする。議会は、少なくとも２０個の要素の委任されたトークンを生成し、入札を記録するためにイベントストリームを生成する必要がある。２０社は、入札文書を送信するときに使用するトークンを各々与えられる。入札期間が終了した後、各社が全ての入札を読み取ることができるように、同じ又は別のトークンを提供することもできる。

【0241】

ストリームID（上記の例では「esid」）は、入札条件が受け入れ可能であることを確認するために、ストリームのメタデータをチェックするために事前に使用できる。

【0242】

入札プロセスが偏見なく実行されるように、イベントストリームを次のように構成できる：

【数9】

構成パラメータの説明

【表2】

【0243】

この構成により、delegatedAuthトークンを受け取った企業は、入札文書を登録し、３回まで修正することができる。入札は指定された期間内に厳格に受け入れられ、入札期間が終了するまで入札を閲覧することはできない。ブロックチェーン上にそのような入札情報を記録することは、そのような入札プロセスを公的に監査する方法を提供し、それによって全体的なプロセスが遵守されていることを保証し、それによって悪意のあるアクターが入札プロセスに干渉する可能性を減らし、全体的にそのような複数の当事者の相互作用のセキュリティを向上させる。

【0244】

各入札が送信された直後に、企業は入札のダイジェストをオンチェーンで監視することもできる。このようなダイジェストは、存在証明として機能するため、入札の内容が送信と監査の間で変更されていないことを保証する。有利なことに、入札が何であったかを示すことなく、入札の存在を記録することができる。

【0245】

例４：メッセージの難読化
イベントデータ（以下では、ED（Event data））を難読化する必要性は、使用例によって異なる。透明性と公開監査の容易さのために、平文のイベントデータが推奨される。ただし、イベントデータは非常に機密性が高いため、イベントストリームを提供するサービスにも公開されるべきではない。このような場合、クライアントは、クライアントが各イベントを読み取ることはできても、他のイベントを読み取ることはできないように、イベントを難読化することを指定できる。これを実現する比較的簡単な方法は、共有シークレットを使用することである。

【0246】

delegatedAuthトークンとインデックスと共に、クライアントは各コントリビュータに別の乱数IV（以下でfIV）も提供する（すなわち、秘密に保たれるべき共有シークレット）。これは、コントリビュータのデータを暗号化するときに初期ベクターとして使用される。

【0247】

各コントリビュータは、クライアントによって指定されたルールに従って、自身のイベントデータEDをフォーマットする。

【0248】

EDは、AESなどの一般的な方法を使用して暗号化される。EDは、コントリビュータとクライアントのみが読み取ることができるように、コントリビュータの個々のivが使用される。

【0249】

次に、イベントメッセージを次のように構成できる。

【数10】

【0250】

クライアントがコントリビュータのデータを評価する場合は、queryDataを使用してイベントレコードを取得できる。このレコードには、コントリビュータのIDを検索するために使用できるデリゲートのインデックスと、共有シークレットivが含まれる。これを使用して、難読化されたデータ要素から平文のイベントデータを復元できる。

【0251】

プラットフォーム装置
図１３を参照すると、本開示の少なくとも一実施形態を実施するために使用され得るコンピューティング装置２６００の説明のための簡略ブロック図が提供される。種々の実施形態で、コンピューティング装置２６００は、上述の及び図示されたシステム又は方法のうちのいずれかを実装するために使用されてよい。例えば、コンピューティング装置２６００は、図５の前述したシステム５００において、１つ以上の構成要素として使用されるように構成され得る。コンピューティング装置２６００は、所定のユーザに関連付けられたクライアントエンティティ、つまりプラットフォームプロセッサへのデータベース要求及び／又は送信を行うクライアントエンティティとして構成することができる。コンピュータ装置２６００は、委任されたユーザとして構成されてよい。委任されたユーザは、委任された認可トークンを受信すると、プラットフォームプロセッサに対してデータ要求及び／又は送信を行うことができる。従って、コンピューティング装置２６００は、ポータブルコンピューティング装置、パーソナルコンピュータ、又は任意の電子コンピューティング装置であってよい。図１３に示すように、コンピューティング装置２６００は、主メモリ２６０８及び永久記憶装置２６１０を含む記憶サブシステム２６０６と通信するよう構成され得る１つ以上のレベルのキャッシュメモリ及びメモリ制御部（集合的に２６０２とラベル付けされる）を備える１つ以上のプロセッサを含んでよい。主メモリ２６０８は、図示のように、動的ランダムアクセスメモリ（ＤＲＡＭ）２６１８及び読み出し専用メモリ（ROM）２６２０を含み得る。記憶サブシステム２６０６及びキャッシュメモリ２６０２は、本開示で説明されたようなトランザクション及びブロックに関連付けられた詳細事項のような情報の記憶のために使用されてよい。プロセッサ２６０２は、本開示で説明されたような任意の実施形態のステップ又は機能を提供するために利用されてよい。

【0252】

プロセッサ２６０２は、１つ以上のユーザインタフェース入力装置２６１２、１つ以上のユーザインタフェース出力装置２６１４、及びネットワークインタフェースサブシステム２６１６とも通信できる。

【0253】

バスサブシステム２６０４は、コンピューティング装置２６００の種々のコンポーネント及びサブシステムが意図した通りに互いに通信できるようにするメカニズムを提供してよい。バスサブシステム２６０４は、単一のバスとして概略的に示されるが、バスサブシステムの代替の実施形態は、複数のバスを利用してよい。

【0254】

ネットワークインタフェースサブシステム２６１６は、他のコンピューティング装置及びネットワークへのインタフェースを提供してよい。ネットワークインタフェースサブシステム２６１６は、幾つかの実施形態では、コンピューティング装置２６００の他のシステムからデータを受信し及びそれへデータを送信するインタフェースとして機能してよい。例えば、ネットワークインタフェースサブシステム２６１６は、データ技術者が、装置をネットワークに接続することを可能にする。その結果、データ技術者は、データセンタのような遠隔地にいがなら、データを装置へ送信し、データを装置から受信できる。

【0255】

ユーザインタフェース入力装置２６１２は、キーボード、統合型マウス、トラックボール、タッチパッド、又はグラフィックタブレットのようなポインティング装置、スキャナ、バーコードスキャナ、ディスプレイに組み込まれたタッチスクリーン、音声認識システム、マイクロフォンのようなオーディオ入力装置、及び他の種類の入力装置のような、１つ以上のユーザ入力装置を含んでよい。通常、用語「入力装置」の使用は、コンピューティング装置２６００に情報を入力する全ての可能な種類の装置及びメカニズムを含むことを意図する。

【0256】

１つ以上のユーザインタフェース出力装置２６１４は、ディスプレイサブシステム、プリンタ、又は音声出力装置のような非視覚的ディスプレイ、等を含んでよい。ディスプレイサブシステムは、陰極線管（CRT）、液晶ディスプレイ（LCD）、発光ダイオード（LED）ディスプレイ、又はプロジェクションのような平面パネル装置、又は他のディスプレイ装置を含んでよい。通常、用語「出力装置」の使用は、コンピューティング装置２６００から情報を出力する全ての可能な種類の装置及びメカニズムを含むことを意図する。１つ以上のユーザインタフェース出力装置２６１４は、例えば、ユーザインタフェースを提示して、ここに記載したプロセス及び変形を実行するアプリケーションとのユーザ相互作用が適切であるとき、そのような相互作用を実現するために使用されてよい。

【0257】

記憶サブシステム２６０６は、本開示の少なくとも１つの実施形態の機能を提供する基本プログラミング及びデータ構造を記憶するコンピュータ可読記憶媒体を提供してよい。アプリケーション（例えば、プログラム、コードモジュール、命令）は、１つ以上のプロセッサにより実行されると、本開示の１つ以上の実施形態の機能を提供し、記憶サブシステム２６０６に格納されてよい。これらのアプリケーションモジュール又は命令は、１つ以上のプロセッサ２６０２により実行されてよい。記憶サブシステム２６０６は、更に、本開示に従い使用されるデータを格納するレポジトリを提供する。例えば、主メモリ２６０８及びキャッシュメモリ２６０２は、プログラム及びデータのための揮発性記憶を提供できる。永久記憶装置２６１０は、プログラム及びデータの永久（不揮発性）記憶を提供でき、磁気ハードディスクドライブ、取り外し可能媒体に関連付けられた１つ以上のフロッピディスクドライブ、取り外し可能媒体に関連付けられた１つ以上の光ドライブ（例えば、CD－ROM、又はDVD、又はＢｌｕｅ－Ｒａｙ）ドライブ、及び他の同様の記憶媒体を含んでよい。このようなプログラム及びデータは、本開示に記載した１つ以上の実施形態のステップを実行するためのプログラム、及び本開示に記載したトランザクション及びブロックに関連付けられたデータを含み得る。

【0258】

コンピューティング装置２６００は、ポータブルコンピュータ装置、タブレットコンピュータ、ワークステーション、又は後述する任意の他の装置を含む種々のタイプのものであってよい。更に、コンピューティング装置２６００は、１つ以上のポート（例えば、USB、ヘッドフォンジャック、光コネクタ、等）を通じてコンピューティング装置２６００に接続可能な別の装置を含み得る。コンピューティング装置２６００に接続され得る装置は、光ファイバコネクタを受けるよう構成される複数のポートを含んでよい。従って、この装置は、光信号を、処理のために装置を接続するポートを通じてコンピューティング装置２６００に送信される電気信号に変換するよう構成されてよい。コンピュータ及びネットワークの絶えず変化する特性により、図１３に示したコンピューティング装置２６００の説明は、装置の好適な実施形態を説明する目的の特定の例としてのみ意図される。図１３に示したシステムより多くの又は少ないコンポーネントを有する多くの他の構成が可能である。

【0259】

上記の様々な方法は、コンピュータプログラムによって実装され得る。コンピュータプログラムは、上記の様々な方法の１つ以上の機能を実行するようにコンピュータに指示するように構成されたコンピュータコードを含むことができる。コンピュータプログラム及び／又はそのような方法を実行するためのコードは、１つ以上のコンピュータ可読媒体又はより一般的にはコンピュータプログラムプロダクト上で、コンピュータのような装置に提供することができる。コンピュータ可読媒体は、一時的又は非一時的であり得る。１つ以上のコンピュータ可読媒体は、例えば、電子、磁気、光、電磁気、赤外線、又は半導体システム、又は、例えば、インターネットを介してコードをダウンロードするためのデータ伝送のための伝送媒体であり得る。代替として、１つ以上のコンピュータ可読媒体は、半導体又は固体メモリ、磁気テープ、リムーバブルコンピュータディスケット、ランダムアクセスメモリ（RAM）、読み出し専用メモリ（ROM）、硬質磁気ディスク、及びCD-ROM、CD-R／W又はDVDのような光ディスクのような１つ以上の物理的コンピュータ可読媒体の形態をとり得る。

【0260】

実装では、本明細書に記載されるモジュール、構成要素及び他の特徴は、個別の構成要素として実装されるか、又はASIC、FPGA、DSP又は同様の装置のようなハードウェア構成要素の機能に統合され得る。

【0261】

「ハードウェア構成要素」又は「ハードウェアモジュール」は、特定の操作を実行することができる有形（例えば、非一時的）物理構成要素（例えば、１つ以上のプロセッサのセット）であり、特定の物理的方法で構成又は配置され得る。ハードウェア構成要素は、特定の動作を実行するように恒久的に構成される専用の回路又はロジックを含むことができる。ハードウェア構成要素は、フィールドプログラマブルゲートアレイ（FPGA）又はASICなどの特定用途プロセッサであるか、又はこれを含むことができる。ハードウェア構成要素は、特定の動作を実行するようにソフトウェアにより一時的に構成されるプログラム可能なロジック又は回路を含むこともできる。

【0262】

従って、「ハードウェア構成要素」又は「ハードウェアモジュール」という語句は、物理的に構築され、永続的に構成され（例えば、有線）、又は一時的に構成され（例えば、プログラムされた）、特定の方法で動作し、又は本明細書に記載された特定の操作を実行するように構成される有形の実体を含むものと理解されるべきである。

【0263】

更に、モジュール及び構成要素は、ハードウェア装置内のファームウェア又は機能回路として実装することができる。更に、モジュール及び構成要素は、ハードウェア装置とソフトウェアコンポーネントの任意の組み合わせで実装することも、ソフトウェアのみで実装することもできる（例えば、機械可読媒体又は伝送媒体に格納され又は他の方法で具現化されたコード）。

【0264】

特に明記しない限り、以下の議論から明らかなように、説明全体を通じて、「決定する」、「提供する」、「計算する（calculating）」、「計算する（computing）」、「識別する」、「結合する」、「確立する」、「送信する」、「受信する」、「格納する」、「推定する」、「確認する」、「取得する」等の用語を用いた議論は、コンピュータシステムのレジスタ及びメモリ内の物理的（電子的）量として表されるデータを、コンピュータシステムのメモリ又はレジスタ又は他のそのような情報記憶、送信又は表示装置内の物理的量として同様に表される他のデータに操作及び変換するコンピュータシステム又は同様の電子計算装置の動作及びプロセスを指すことが理解される。

【0265】

本明細書及び特許請求の範囲において使用される「含む」という用語は、「少なくとも一部を構成する」を意味する。本明細書及び特許請求の範囲の「含む（comprising）」という用語を含む各記述を解釈する場合には、それ以外の特徴又は用語の前に付けられた特徴も存在することがある。「含む（comprise、comprises）」のような関連する用語は、同様に解釈される。

【0266】

本明細書に開示される数値の範囲（例えば、１から１０）への参照は、その範囲内の全ての有理数（例えば、１、１．１、２、３、３．９、４、５、６、６．５、７、８、９、１０）への参照及びその範囲内の任意の有理数の範囲（例えば、２から８、１．５から５．５、３．１から４．７）への参照も含むことを意図しており、従って、本明細書に明示的に開示される全ての範囲の全てのサブ範囲は、本明細書に明示的に開示されている。これらは、具体的に意図されたものの例にすぎず、列挙された最低値と最高値の間の数値の全ての可能な組み合わせは、本出願において同様の方法で明示的に記載されているとみなされる。

【0267】

本明細書で使用される用語「及び／又は」は、「及び」又は「又は」又はその両方を意味する。

【0268】

本明細書で使用される、名詞に続く「（s）」は、名詞の複数形及び／又は単数形を意味する。

【0269】

要素の単数の参照は、そのような要素の複数の参照を排除しない。逆も同様である。

【0270】

上記の説明は例示的なものであり、限定的なものではないことを理解されたい。他の多くの実装は、上記の説明を読んで理解すれば、当業者には明らかであろう。開示は、具体的な実施例を参照して説明されているが、開示は、記載された実施例に限定されるものではなく、添付の特許請求の範囲内で修正及び変更を加えて実施することができることが認められる。従って、明細書及び図面は、限定的意味ではなく説明的意味で考えられるべきである。開示の範囲は、従って、添付の請求の範囲を参照して、権利の与えられた該請求の範囲の均等な全範囲とともに、決定されるべきである。

【図1】

【図2】

【図3A】

【図3B】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9A】

【図9B】

【図9C】

【図9D】

【図10A】

【図10B】

【図10C】

【図10D】

【図10E】

【図11】

【図12】

【図13】

【国際調査報告】