特表 2023-517049 暗号データ入力ブロックチェーンデータ構造

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

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

(11)【公表番号】

(43)【公表日】2023-04-21

(54)【発明の名称】暗号データ入力ブロックチェーンデータ構造

(51)【国際特許分類】

   H04L 9/32 20060101AFI20230414BHJP

   G06F 21/60 20130101ALI20230414BHJP

   G06F 21/62 20130101ALI20230414BHJP

   G06F 21/31 20130101ALI20230414BHJP

   G06F 16/182 20190101ALI20230414BHJP

【ＦＩ】

H04L9/32 200Z

G06F21/60 320

G06F21/62 318

G06F21/31

G06F16/182

【審査請求】未請求

【予備審査請求】未請求

(21)【出願番号】P 2022553613

(86)(22)【出願日】2021-03-04

(85)【翻訳文提出日】2022-10-13

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

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

(87)【国際公開日】2021-09-10

(31)【優先権主張番号】62/985,129

(32)【優先日】2020-03-04

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

(81)【指定国・地域】

(71)【出願人】

【識別番号】522352410

【氏名又は名称】リュビデックス，エルエルシー

(74)【代理人】

【識別番号】100118902

【弁理士】

【氏名又は名称】山本 修

(74)【代理人】

【識別番号】100106208

【弁理士】

【氏名又は名称】宮前 徹

(74)【代理人】

【識別番号】100196508

【弁理士】

【氏名又は名称】松尾 淳一

(74)【代理人】

【識別番号】100147991

【弁理士】

【氏名又は名称】鳥居 健一

(72)【発明者】

【氏名】ティール，スティーブン

(72)【発明者】

【氏名】フェルカー，マイケル

(57)【要約】

ブロックチェーン構造を使用してデータを安全に記憶及び送信するための方法。ブロックチェーン構造は、ローカルノード上で、並びにアービタサーバ及びクラウドインフラ構造によるＳＳＨ送信を通じて、操作される。ローカルアプリケーションが、付加されたブロックの順序を調整し、各ブロックは、ブロック順序を示すためにそれぞれのファイル名を使用するフラットファイルである。データ入力及び取得は、プレーンテキストデータが、認証クライアントを通じて復号される際にローカルメモリ内でのみ利用可能である場合に実施される。データは暗号化される際にのみディスクに書き込まれる。

【特許請求の範囲】

【請求項1】

ローカルブロックチェーンノード上の入力インターフェースを介して新規データを受信するステップと、
前記新規データを、ユーザインターフェース上に表示しながら、プレーンテキストとしてローカルメモリ内に記憶するステップと、
前記新規データを、ブロックチェーンデータ構造のローカルコピー上の新規ブロックとして、ローカル不揮発性ストレージ上の暗号化された暗号文として書き込むステップと、
前記新規ブロックをピアネットワークに送信して、前記ピアネットワーク全体にわたってそれぞれのブロックチェーンデータ構造に付加されるようにするステップと
を含む、データストレージ方法。

【請求項2】

前記ローカルブロックチェーンノード上の各ブロックは、前記ローカルブロックチェーンノード内のブロック順序を指定する命名規則を含むフラットファイルを備え、前記方法は、
前記ピアネットワークを通じて前記ローカルブロックチェーンノードにおいて、第２の新規ブロックを受信するステップと、
前記命名規則に基づいて、前記ローカルブロックチェーンノード上の前記第２の新規ブロックを順序付けするステップと
をさらに含む、請求項１に記載の方法。

【請求項3】

前記ローカルブロックチェーンノード上の各ブロックは、タイムスタンプをさらに含み、前記方法は、
前記命名規則によって指定されるような一致ブロック順序を有する前記新規ブロック及び前記第２の新規ブロックに応答して、前記ローカルブロックチェーンノードによって、前記新規ブロック及び前記第２の新規ブロックを、前記タイムスタンプを使用した作成順により曖昧性解消を実行するステップと、
前記新規ブロック又は前記第２の新規ブロックのうちのいずれかを、どちらのブロックが他方のブロックの後に作成されたかを示す前記命名規則に基づいて、再命名するステップと
をさらに含む、請求項２に記載の方法。

【請求項4】

前記ローカルブロックチェーンノード上の各ブロックは、前記ローカルブロックチェーンノード内のブロック順序を指定する命名規則を含むフラットファイルを備え、前記方法は、
前記ローカルブロックチェーンノードによって、オフライン期間の後に前記ピアネットワークに接続するステップと、
前記接続に応答して、前記ローカルブロックチェーンノードによって、前記ブロックチェーンデータ構造のコピーを最新のブロックから始まる前記ピアネットワークと同期させるステップと
をさらに含む、請求項１に記載の方法。

【請求項5】

前記書き込み及び送信ステップは、前記同期の完了前に実施される、請求項４に記載の方法。

【請求項6】

前記ローカルブロックチェーンノード上でブロックチェーン閲覧アプリケーションを実行するステップであって、前記ブロックチェーン閲覧アプリケーションが、第１のユーザのためのユーザログイン認証情報のセットを検証するように構成され、前記第１のユーザが、第１のユーザ鍵を有する、ステップと、
前記第１のユーザ鍵によって復号可能である前記ブロックチェーンデータ構造のサブセットを識別するステップと、
前記ブロックチェーンデータ構造の前記サブセットを前記ローカルブロックチェーンノード上のローカルメモリ内へ読み込むステップと、
前記ローカルメモリ内の前記ブロックチェーンの前記サブセットをプレーンテキストへと復号するステップと
をさらに含む、請求項１に記載の方法。

【請求項7】

前記ブロックチェーン閲覧アプリケーションによって、前記ローカルブロックチェーンノードの物理的な場所を識別するステップをさらに含み、これにより、前記第１のユーザ鍵によって復号可能である前記ブロックチェーンデータ構造の前記サブセットは、前記ローカルブロックチェーンノードの前記物理的な場所が既定のジオフェンス内に入るかどうかの影響下にある、請求項６に記載の方法。

【請求項8】

ブロックチェーン閲覧アプリケーションのグラフィックユーザインターフェースを介して前記第１のユーザから検索クエリを受信するステップと、
前記検索クエリを前記プレーンテキストに適用するステップと、
ブロックチェーン閲覧アプリケーションによって、メモリ内の検索結果を前記第１のユーザに表示するステップと
をさらに含む、請求項６に記載の方法。

【請求項9】

前記ブロックチェーン閲覧アプリケーションを介して、データフィールドポインタを含むグラフィックユーザインターフェースを表示するステップと、
前記ブロックチェーンデータ構造の前記復号されたサブセットからの前記データフィールドポインタをローカルメモリに投入するステップと
をさらに含む、請求項６に記載の方法。

【請求項10】

ブロックチェーンデータ構造のコピーをローカルブロックチェーンノード上に維持するステップであって、前記ブロックチェーンデータ構造が、互いに順序正しくリンクされるデータの暗号化ブロックのセットを含む、ステップと、
ローカルブロックチェーンノード上でブロックチェーン閲覧アプリケーションを実行するステップであって、前記ブロックチェーン閲覧アプリケーションが、第１のユーザのためのユーザログイン認証情報のセットを検証するように構成され、前記第１のユーザが、第１のユーザ鍵を有する、ステップと、
前記第１のユーザ鍵によって復号可能である前記ブロックチェーンデータ構造のサブセットを識別するステップと、
前記ブロックチェーンの前記サブセットを前記ローカルブロックチェーンノード上のローカルメモリ内へ読み込むステップと、
ローカルメモリ内の前記ブロックチェーンの前記サブセットをプレーンテキストへと復号するステップと
を含む、安全なデータ取得方法。

【請求項11】

前記ブロックチェーン閲覧アプリケーションによって、前記ローカルブロックチェーンノードの物理的な場所を識別するステップをさらに含み、前記第１のユーザ鍵によって復号可能である前記ブロックチェーンデータ構造の前記サブセットは、前記ローカルブロックチェーンノードの前記物理的な場所が既定のジオフェンス内に入るかどうかの影響下にある、請求項１０に記載の方法。

【請求項12】

ブロックチェーン閲覧アプリケーションのグラフィックユーザインターフェースを介して前記第１のユーザから検索クエリを受信するステップと、
前記検索クエリを前記プレーンテキストに適用するステップと、
ブロックチェーン閲覧アプリケーションによって、メモリ内の検索結果を前記第１のユーザに表示するステップと
をさらに含む、請求項１０に記載の方法。

【請求項13】

前記ブロックチェーン閲覧アプリケーションを介して、データフィールドポインタを含むグラフィックユーザインターフェースを表示するステップと、
前記ブロックチェーンデータ構造の前記復号されたサブセットからの前記データフィールドポインタをローカルメモリに投入するステップと
をさらに含む、請求項１０に記載の方法。

【請求項14】

ローカルブロックチェーンノードに実装されるプロセッサと、
ブロックチェーンデータ構造のコピーを含む不揮発性データストアであって、前記ブロックチェーンデータ構造のデータ要素が暗号化される、不揮発性データストアと、
命令を含むメモリであって、前記命令は、実行されると、
前記ローカルブロックチェーンノード上で新規データを受信することと、
前記新規データを、ユーザインターフェース上に表示しながら、プレーンテキストとして前記メモリに記憶することと、
前記新規データを、前記ブロックチェーンデータ構造の前記コピー上への新規ブロックとして、暗号化された暗号文前記不揮発性ストレージとして書き込むことと、
前記新規ブロックをピアネットワークに送信して、前記ピアネットワーク全体にわたってそれぞれのブロックチェーンデータ構造に付加されるようにすることと
を前記プロセッサに行わせる、メモリと、
を備える、データストレージのシステム。

【請求項15】

前記ブロックチェーンデータ構造上の各ブロックは、前記ローカルブロックチェーンノード内のブロック順序を指定する命名規則を含むフラットファイルを備え、前記方法は、
前記ピアネットワークを通じて前記ローカルブロックチェーンノードにおいて、第２の新規ブロックを受信するステップと、
前記命名規則に基づいて、前記不揮発性データストア内で前記第２の新規ブロックを順序付けするステップと
をさらに含む、請求項１４に記載のシステム。

【請求項16】

前記ローカルブロックチェーンノード上の各ブロックは、タイムスタンプをさらに含み、前記メモリは、命令をさらに含み、前記命令は、実行されると、
前記命名規則によって指定されるような一致ブロック順序を有する前記前記新規ブロック及び前記第２の新規ブロックに応答して、前記ローカルブロックチェーンノードによって、前記新規ブロック及び前記第２の新規ブロックを、前記タイムスタンプを使用した作成順により曖昧性解消を実行することと、
前記新規ブロック又は前記第２の新規ブロックのうちのいずれかを、どちらのブロックが他方のブロックの後に作成されたかを示す前記命名規則に基づいて、再命名することと
を前記プロセッサに行わせる、請求項１５に記載のシステム。

【請求項17】

前記ローカルブロックチェーンノード上の各ブロックは、前記ローカルブロックチェーンノード内のブロック順序を指定する命名規則を含むフラットファイルを備え、前記メモリは、命令をさらに含み、前記命令は、実行されると、
前記ローカルブロックチェーンノードによって、オフライン期間の後に前記ピアネットワークに接続することと、
前記接続に応答して、前記ローカルブロックチェーンノードによって、前記ブロックチェーンデータ構造のコピーを最新のブロックから始まる前記ピアネットワークと同期させることと
を前記プロセッサに行わせる、請求項１４に記載のシステム。

【請求項18】

前記メモリは、命令をさらに含み、前記命令は、実行されると、
前記ローカルブロックチェーンノード上でブロックチェーン閲覧アプリケーションを実行することであって、前記ブロックチェーン閲覧アプリケーションが、第１のユーザのためのユーザログイン認証情報のセットを検証するように構成され、前記第１のユーザが、第１のユーザ鍵を有する、実行することと、
前記第１のユーザ鍵によって復号可能である前記ブロックチェーンデータ構造のサブセットを識別することと、
前記ブロックチェーンデータ構造の前記サブセットを前記ローカルブロックチェーンノード上の前記メモリ内へ読み込むことと、
前記メモリ内の前記ブロックチェーンデータ構造の前記サブセットをプレーンテキストへと復号することと
を前記プロセッサに行わせる、請求項１４に記載のシステム。

【請求項19】

ＧＰＳ又はＩＰトレーシングを介して前記ローカルブロックチェーンノードの物理的な場所を識別するように構成される場所センサをさらに含み、これにより、前記第１のユーザ鍵によって復号可能である前記ブロックチェーンデータ構造の前記サブセットは、前記ローカルブロックチェーンノードの前記物理的な場所が既定のジオフェンス内に入るかどうかの影響下にある、請求項１８に記載のシステム。

【請求項20】

前記メモリは、命令をさらに含み、前記命令は、実行されると、
ブロックチェーン閲覧アプリケーションのグラフィックユーザインターフェースを介して前記第１のユーザから検索クエリを受信することと、
前記検索クエリを前記プレーンテキストに適用することと、
ブロックチェーン閲覧アプリケーションによって、前記メモリ内の検索結果を前記第１のユーザに表示することと
を前記プロセッサに行わせる、請求項１８に記載のシステム。

【請求項21】

前記メモリは、命令をさらに含み、前記命令は、実行されると、
前記ブロックチェーン閲覧アプリケーションを介して、データフィールドポインタを含むグラフィックユーザインターフェースを表示することと、
前記ブロックチェーンデータ構造の前記復号されたサブセットからの前記データフィールドポインタを前記メモリに投入することと
を前記プロセッサに行わせる、請求項１８に記載のシステム。

【発明の詳細な説明】

【技術分野】

【0001】

関連出願の相互参照
[001]本出願は、２０２０年３月４日に出願された米国仮特許出願第６２／９８５，１２９号の優先権を主張するものであり、その全体が参照により本明細書に組み込まれる。

【0002】

[002]本開示は、分散ネットワーク内でデータを記憶することに関与する暗号データ構造を識別することに関する。

【背景技術】

【0003】

[003]従来のデータベースは、いくつかの欠陥を含む。例えば、多くのデータベースは、セキュリティの問題に悩まされる。データは、暗号化されずに記憶又は送信され、悪意のある者によって不正アクセスされ得るターゲットを提示する。日々、企業データベースが侵害され、記録が盗まれている。第２の問題は、破損、すなわち、落雷、停電、人的エラー、タイミング不良などの外因子に起因するデータベースデータの全損から生じる。

【0004】

[004]暗号通貨ブロックチェーンデータストレージは、既知のブロックチェーンシステムの本質的な不変性及び全体的なデータ構造に基づいてデータを修正することの困難さを含む。詳細には、記憶されたデータは、真のデータストレージシステムよりも財政システムに結び付けられる。暗号通貨システム内の記憶されたデータは、コインに結び付けられ、記憶されたデータを変更したい場合、大部分が組織化されていないブロックチェーンを見て回らなければならない。暗号通貨は、結局のところ、非効率的かつ非効果的なデータストレージシステムである。

【0005】

[005]既知のデータ暗号化スキームは、攻撃者にとってのターゲットを作り出す本質的な脆弱性を有する傾向がある。

【図面の簡単な説明】

【0006】

【図1】[006]既知のブロックチェーンデータ構造のブロック図である。暗号通貨ネットワークは、分散ネットワークアーキテクチャ上で動作する（先行技術）。

【図2】[007]スマートコントラクトの既知のデータ構造を例証するブロック図である（先行技術）。

【図3】[008]カスタムトークンのデータ構造内に含まれる様々な暗号アドレス及びエンティティのブロック図である。

【図4】[009]クライアントフロントエンドとブロックチェーンへのアクセシビリティとの関係性を例証するブロック図である。

【図5】[0010]データをブロックチェーンへ付加する方法を例証するフローチャートである。

【図6】[0011]ピアネットワーク内のアービタサーバのブロック図である。

【図7】[0012]ブロックチェーンからの正当なデータ取得の方法を例証するフローチャートである。

【図8】[0013]データ入力インターフェース及び関連ブロックチェーンのスクリーンショットである。

【図9】[0014]ブロックチェーンから得るブロックチェーンビューアアプリケーションのスクリーンショットである。

【図10】[0015]例示的なコンピューティングシステムのブロック図である。

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

【0007】

[0016]典型的なブロックチェーンは、分散ネットワークがデータの不変台帳に貢献する暗号データ構造である。ブロックチェーンシステムは、多くの場合、公開鍵（ユーザに言及するために使用され、アドレスとして作用する）及び秘密鍵（ユーザが取る行動に署名するために使用され、一方向関数によって公開鍵に関連している）を含む暗号鍵対により識別されるユーザ基盤と関連付けられる。新規データは、ネットワークに提出され、ネットワーク内のノードが、データをブロックチェーンの終わりに付加する。ブロックチェーンシステムは、従来のデータベースに勝る多くの利点を有する。すなわち、構造が単に成長し続けるため、データ損失がない。ネットワークは分散され、ノード同士の同期は、損傷したノードがピアによって記憶されるデータにより修復され得ることを意味するため、破損に起因するデータ損失がない。ブロックチェーンはまた、データが分散され、また大部分は、不変であるため、データベースよりも攻撃するのが著しく難しい。

【0008】

[0017]ブロックチェーンデータ構造は、おそらく、暗号通貨と関連付けられたものとして最もよく知られている。基本的に、ブロックチェーンは、分散型リンクリストである。多くのシステムが、暗号通貨ネットワークの上に構築されているが、それらのシステムは、本質的に、何らかの基礎となる通貨の存在及びその使用に基づく。故に、ブロックチェーンの暗号通貨アプリケーションは、単一のエンティティデータ入力システムを効果的に管理するのに最も効果的な構造ではない。

【0009】

[0018]本明細書内では、所与のエンティティのユーザが分散ネットワーク上の各ノードであるシステムが説明される。各ノードは、参加するためにフルノード（例えば、全ブロックチェーンを記憶する）である必要はない。ノードが無活動の期間からログインした後に同期するとき、それらのノードは、まず、チェーン内の最新のブロックを獲得してから、起源ブロックへ向かって逆行して作業する。ブロック内のデータは、情報の最も単純な表現を含む小さいフラットファイルに記憶される。記憶されたデータは、暗号文へと暗号化される。プレーンテキストデータを閲覧することは、悪意のあるユーザの攻撃ウィンドウを低減するためにメモリ内で実施される。本開示の目的のため、「プレーンテキスト」は、「暗号文」の補集合であり、暗号化されていない、又は暗号化前である（複数のサイクルの暗号化の場合）データを意味する。プレーンテキストは、暗号文を生成する１つ又は複数の関数の入力である。

【0010】

[0019]ブロックチェーンは不変であり、すなわち、一旦付加されると、ブロックのデータは、変更するのが不可能ではないが困難である。しかしながら、データ入力は、多くの場合、データへの修正又は編集を含む。所与のブロック内のデータが、変更される必要がある場合、システムは、起源ブロックとして関連データを含有するブロックを使用して新規の分岐ブロックチェーン構造を生み出す。そのデータが編集されると、新規ブロックが、分岐ブロックチェーンに付加される。分岐ブロックチェーンが移転の自由を必要とする通貨資産を参照することが理由で、暗号通貨システムが、分岐ブロックチェーンを処理することができない場合、記憶されたデータは、同じ柔軟性を必要としない異なる構造である。現在のシステムは、暗号通貨ブロックチェーンからの構造変動を含むが、何らかの基本アーキテクチャは保持される。

【0011】

[0020]図１は、既知の暗号通貨ベースのブロックチェーンデータ構造のブロック図である。暗号通貨ネットワークは、分散ネットワークアーキテクチャ上で動作する。暗号通貨を理解する鍵は、ネットワークが動作するデータ構造である。例えば、ビットコイン及びイーサリアムネットワークは、ブロックチェーンと称されるデータ構造を使用する。

【0012】

[0021]ブロックチェーンは、ネットワーク上でこれまでに発生したすべての取引の履歴を含む。分散ネットワーク内の各フルノードは、ブロックチェーンの全コピーを保有する。そもそもネットワークに参加するためには、所与のノードにおけるブロックチェーン履歴は、他のノードの少なくとも大部分の履歴と整合していなければならない。この整合性ルールは、ブロックチェーンが不変であるようにする重要な効果を有する。ビットコイン又はイーサリアム（現行バージョン）などのブロックチェーンを効果的に攻撃するためには、ネットワーク全体の処理能力の５１％超を制御しなければならない。ネットワークが何千ものノードからなる場合、必須の５１％を集めるのは極めて難しい。

【0013】

[0022]所与のノードが取引を生成しようとするとき、その取引は、それが、その取引及び同時期の時間期間の間に生成される他の取引をブロック内へ集めることができるノード又はノードのグループに到達するまで、ノードの至る所に伝播される。取引がブロック内に現れるまで、それは、公開されない、又はパブリックではない。多くの場合、取引は、必要数の追加ブロックが追加されるまで、確認されたとは見なされない。

【0014】

[0023]このファイリングの時、ビットコインブロックは、４ＭＢのサイズに限定され、およそ５～１５分ごとに生成される。これは、１秒当たりおよそ７つの取引のみを処理するというビットコインネットワークの重要な制限を例証する。逆に、イーサリアムは、所与のブロック内のコントラクトが求める処理の量に基づいてブロックサイズを制限し、５～２０秒ごとに付加される。暗号通貨ネットワークは、技術的には、リアルタイムで取引を処理することを開始し、所与の取引を含むブロックの存在が、その取引の真正性を検証するが、そのブロックがブロックチェーンに公開されるまで、取引は検証されない。

【0015】

[0024]検証時間におけるギャップは、「誰がお金を持っているか」の、所与の瞬間におけるビットコインネットワーク内での問題をもたらす。ブロック生成間の１０～１５分のスパンの間、提出された取引は実際には進行しない場合がある。これは、ユーザが、自分が所持していないお金を使用するとき、又は二重使用のときに発生する。これは、ネットワークがブロック間の検証機序を有さないというわけはない。例えば、所与のユーザが別のユーザに支払うことを試みるとき、システムは、少なくとも最も直近に公開されたブロック時点での所与のユーザの残高を調査するために、より古いブロックに容易にクエリし得る。所与のユーザが十分な資金を有する場合、取引を信用することは適度に安全である。

【0016】

[0025]しかしながら、所与のユーザがすべての自分のお金を二重使用することを試みている場合、それらの取引のうちの１つのみが次のブロックにおいて発行することになる。他は拒否されることになる（拒否される取引、及び進行するその取引は、競合状態の影響下にあり（ｓｕｂｊｅｃｔ ｔｏ）、必ずしも生成の時間に依存しない）。取るに足りない金額のお金について論じるとき（例えば、コーヒーの支払い）、これは、大きな懸念では全くない。しかしながら、素早く発生するより大きい購入を処理するとき（例えば、企業における株）、金額は、著しく大きくなり得、１０～１５分のクリアランス時間は理想ではない。

【0017】

[0026]これまでのところ、ビットコインは、ビットコインを取引するためのネットワークとして論じられている。しかしながら、ビットコイン取引は、それらが追加のデータを埋め込むことができるという点でさらなる実用性を有する。上で企図されるように、ビットコインは、購入するため、及び所与の時間点におけるデータの存在を記録するために使用され得る。データを記録することは、所与の取引の出力フィールド内にハッシュ化データを含むことにより実施される。この様式では、任意の文書又は記録されたデータの存在の証明は、ブロックチェーンの不変の履歴へと埋め込まれ得る。

【0018】

[0027]非コイン資産の所有権を譲渡するためにビットコインブロックチェーンを利用するシステムは、ブロックチェーンとは別個であり、単にブロックチェーンの不変性に依拠するにすぎないソフトウェアを必要とする。別個のソフトウェアは、必ずしもそれ自体は安全又は不変ではない。したがって、追加のブロックチェーンソフトウェアは、安全性を確実にするためにブロックチェーンの不変性に依拠するシステムにおける本質的な弱点である。イーサリアムは、非コイン資産を購入及び販売する能力を一歩先へ進める。

【0019】

[0028]イーサリアムスマートコントラクトは、実質的に、ブロックチェーン上で実行するイベント駆動型ソフトウェアである。そのソフトウェアは、オープンソースであり、ブロックチェーン自体に関連する入力の影響下にある。当然ながら、脆弱性を含むコードを依然として書き込むことができるが、本プラットフォームは、チェーン内のより大きい安全性及びより少ない弱いリンクを可能にする。

【0020】

[0029]図２は、スマートコントラクトの既知のデータ構造を例証するブロック図である。スマートコントラクト及び分散型アプリケーション（「ｄＡｐｐ」）は、イーサリアム仮想マシン（「ＥＶＭ」）上で実行する。ＥＶＭは、利用可能なネットワークノード上でインスタンス作成される。スマートコントラクト及びｄＡｐｐは、実行するアプリケーションであり、故に、それを行うための処理能力は、どこかのハードウェアに由来しなければならない。ノードは、それらのプロセッサを自発的に提供して、「ガス」で測定される、イーサと称されるイーサリアムコインで作業に対して支払われているという前提に基づいて、これらの動作を実行しなければならない。ガスは、ＥＶＭにおける作業単位の名前である。ガスの価格は、多くの場合イーサの価格が変動するため、変動し得、スマートコントラクト／ｄＡｐｐ内で指定される。

【0021】

[0030]イーサリアムプラットフォーム上の取引又はコントラクトによって実施され得る全動作は、特定の数のガスがかかり、より多くの計算リソースを必要とする動作には、より少ない計算リソースを必要とする動作よりも多くのガスがかかる。例えば、乗算命令は、５ガスを必要とし得る一方、加算命令は、３ガスを必要とし得る。逆に、Ｋｅｃｃａｋ２５６暗号ハッシュなどのより複雑な命令は、３０初期ガス、及び２５６ビットのデータがハッシュされるごとに追加の６ガスを必要とする。

【0022】

[0031]ガスの目的は、かなり安定した比率でのスマートコントラクトの実行時のネットワークの処理能力に対して支払うことである。そもそもコストが存在するということが、実施されている作業／処理が有用であり、誰かにとって価値があるものであるということを確実にする。故に、イーサリアム戦略は、取引のキロバイト単位のサイズにのみ依存するビットコイン取引手数料とは異なる。イーサリアムのガスは演算に根差しているため、コードの短セグメントさえも、著しい量の処理が実施されるということを結果としてもたらし得る。ガスの使用は、さらに、プログラマが効率的なスマートコントラクト／アルゴリズムを生成することを奨励する。さもなければ、実行のコストは、手に負えない状況に陥り得る。無制限の指数関数は、所与のユーザを破産させ得る。

【0023】

[0032]イーサリアム仮想マシン（ＥＶＭ）における動作はガスコストを有するが、ガスは、イーサで測定される「ガス価格」を有する。取引は、ガスの各単位についてイーサでの所与のガス価格を指定する。取引による価格の固定は、イーサの価格と（ガスで測定されるような）演算動作のコストとの関係性を市場が決定することを可能にする。取引によって支払われる合計手数料は、使用されるガスにガス価格を乗じたものである。

【0024】

[0033]所与の取引がガス価格に関してかなり少なく申し出る場合、その取引は、ネットワーク上で低優先度を有することになる。場合によっては、ネットワークマイナーは、各々が実行／処理する意思のあるガス価格に対してしきい値を置き得る。所与の取引がすべてのマイナーのためのそのしきい値未満である場合、プロセスは決して実行しない。取引が、添付される十分なイーサを含まない場合（例えば、取引が、ガスコストが添付イーサを超えるほどあまりに多くの演算作業をもたらすため）、使用されたガスは、依然としてマイナーに提供される。ガスが使い果たされると、マイナーは、取引を処理することを停止し、なされた変更を取り消し、ブロックチェーンに「失敗した取引」を付加する。失敗した取引は、マイナーが効率性のためにスマートコントラクトを直接評価しないことから発生し得る。マイナーは、適切なガス価格が添付された状態のコードを実行するにすぎない。コードが完了まで実行するか、過剰な演算複雑性に起因して行き詰まるかは、マイナーには関係ないことである。

【0025】

[0034]高いガス価格が取引に添付される場合、その取引は優先されることになる。マイナーは、経済的価値の順に取引を処理することになる。イーサリアムブロックチェーンにおける優先度は、ビットコインブロックチェーンと同様に働く。ユーザが所与の取引に対して必要よりも多くのイーサを添付する場合、過剰な量は、取引が実行／処理された後に、そのユーザに返金される。マイナーは、実施される作業に対してのみ請求する。ガスコスト及び価格に関する有用な類似性は、ガス価格がマイナーに対する時間給に類似する一方、ガスコストは実施される作業のタイムシートのようなものであるということである。

【0026】

[0035]イーサリアムブロックチェーン上に存在するスマートコントラクトのタイプは、ＥＲＣ－２０トークン（Ｅｔｈｅｒｅｕｍ Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔ－２０）である。ＥＲＣ－２０は、代替可能な実用トークンのための技術的仕様である。ＥＲＣ－２０は、より大きいイーサリアムエコシステム内で従うべきイーサリアムトークンのためのルールの共通リストを規定し、開発者がトークン間の相互作用を正確に予測することを可能にする。これらのルールは、トークンがアドレス間でどのように転送されるか、及び各トークン内のデータがどのようにアクセスされるかを含む。ＥＲＣ－２０は、ベース暗号通貨の上にトークンを構築するための手段のためのフレームワークを提供する。本明細書内のいくつかの実施形態において、エンハンスメントがＥＲＣ－２０フレームワークの上に構築されるが、ＥＲＣ－２０技術的仕様の使用は、本質的に必要ではなく、イーサリアムがベース暗号通貨として使用される状況に適用可能である。

【0027】

[0036]これまでのところ、議論はビットコイン及びイーサリアムに焦点を合わせてきた。本開示において適用可能な場合、これらは、ベース暗号通貨である。他のベース暗号通貨が現在及び将来存在する。本開示は、特にビットコイン又はイーサリアムブロックチェーンに対する適用に限定されない。

【0028】

[0037]実用トークンの概念は、今日のブロックチェーン空間において理解される。実用トークンは、ネットワークへのアクセスを表し、所与の実用トークン購入は、そのネットワークから商品又はサービスを購入する能力を表し、例えば、アーケードトークンは、ユーザがアーケードゲーム機で遊ぶことを可能にする。実用トークンは、製品又はサービスへのその同じタイプのアクセスをユーザに与える。一方で、カスタムトークンは、資産における完全又は分割所有を表す（企業、不動産資産、美術品などにおけるシェアなど）。企業の株式、不動産、又は知的財産を所有することはすべて、カスタムトークンによって表され得る。カスタムトークンは、ブロックチェーン及びその関連公開台帳の使用を通じて、従来の紙共有に勝る著しい透明性をもたらすという利点を提供する。投資家に影響を及ぼし得るカスタムトークン構造、配布、又は変更が、ここではすべてブロックチェーンを介してアクセス可能である。

【0029】

[0038]図３は、分岐ブロックチェーンを実装するブロックチェーンデータ構造を例証する。メインブロックチェーン２０は、第１のブロック２２から始まり、第２のブロック２４、第３のブロック２６、及び第４のブロック２８を含む。メインブロックチェーン２０は、第１のブロックチェーン、又は一次ブロックチェーンと称され得る。ブロックの数は、単に例証のために存在する。実際の使用事例において、メインブロックチェーン２０は、経時的に、多くの、さらに多くのブロックを含む。各ブロックは、データストレージである。いくつかの実施形態において、各ブロックには、暗号通貨ブロックチェーンのようなデータ構造が付加されるが、関連付けられた暗号通貨は存在しない。すなわち、新規データを、及び以て新規ブロックを、ブロックチェーンへ提出しているノードは、新規ブロックを前のブロック又は最後のブロックと照合するために処理動作を実施する。

【0030】

[0039]ブロックは、マイニングされず、むしろユーザがデータを取引する度に作成される。例において、ユーザは、２ページワード文書を保存し得、それがブロックに、次いで１ページ文書になり、別のブロックとしてそれを保存し得る。ブロックは、即座に作成され、ブロックチェーンのようにハッシュ化される。このプロセスは、データを作成するのと同じやり方で発生する。例えば、ユーザは、空のワード文書を開き、タイプし、保存し得、その文書がブロックになる。

【0031】

[0040]各ブロックは、好ましくは、ブロックＩＤ、最後のハッシュ、新規ハッシュ、ユーザハッシュ、時刻／日付、及びデータ入力ユーザのユーザ名と一緒に、何らかのペイロードデータを含有する。データは、ブロックチェーン２０、３０に記憶される間、暗号化された暗号文である。ブロックは、さらに、ブロックを生成するユーザ又はブロック生成ユーザを監督するユーザと関連付けられたそれぞれの鍵対を使用してハッシュ化される。

【0032】

[0041]ペイロード又はデータは、任意の好適なサイズのものであり得る。ブロックは、単一のビット又は文書全体を記憶し得る。データの範囲は、データの一形式及び／又は形式全体にフィールドを含む。いくつかの実施形態において、チェーン内のブロックは、ディスクに記憶される各ファイル（例えば、フラットファイル）である。ビットコインブロックチェーンが、多くの場合、継続的に修正される単一のフラットファイルとして記憶されることを受けて、本システムの実施形態は、新規ブロックのための追加のフラットファイルを生成する。ブロックチェーンのリンクリスト態様は、ファイル名が、先行ブロックへの参照を含むように動的に作成されるファイル命名スキームによってサポートされる。ペイロード、又はブロックのためのデータは、フラットファイル内に記憶される。

【0033】

[0042]ブロックチェーン２０は、不変である。１つのノードにおいて変更がなされる場合、強制同期化は、そのノードを、ブロックが未変更のままであった他のノードと一致させる。データベース内のデータは、多くの場合、数々の正当な理由のために変更される。いくつかの実施形態において、新規データ又は古いデータに対する編集は、将来のブロック３２においてブロックチェーン２０の上に付加される。いくつかの実施形態において、正当なデータ編集は、編集されるべきデータを含有するブロックから分岐ブロックチェーン３０に付加される。分岐ブロックチェーン３０は、第２の、第３の、もしくは第Ｎのブロックチェーンと、又はサブチェーンと称され得る。分岐ブロックチェーン３０は、メインブロックチェーン２０上にある起源ブロックを有する。いくつかの実施形態において、メインブロックチェーン２０上の所与のブロックが分岐ブロックチェーン３０の起源ブロックではない場合、その所与のブロックに記憶される関連データへの編集は存在していなかったことになる。そのブロックのための分岐ブロックチェーンの存在は、データへの修正を示す。

【0034】

[0043]図に描写されるように、第２のブロック２６は、ユーザが編集したいデータを含む。メインブロックチェーン２０上に新規ブロックを生成する代わりに、将来のブロック３２空間において、データへの編集は、ブロック２プライム３４において表される。ブロック２プライム３４は、新規起源ブロックとしてメインブロックチェーン２０の第２のブロック２６を使用する分岐ブロックチェーン３０内の第２のブロックである。第２のブロック２６に関連したデータがさらに編集されると、それらの編集は、ブロック２データへの将来の編集の空間３６において分岐ブロックチェーン３０に追加されるブロックを結果としてもたらす。

【0035】

[0044]第２のブロック２６と関連付けられたデータが読み出されるとき、システムは、そのデータへの任意の参照についてメインブロックチェーン２０全体をチェックするのではなく、存在するならば、関連分岐ブロックチェーン３０のみをチェックする必要がある。メインブロックチェーン２０は、データのすべてのインスタンスを表すために使用される一方、分岐ブロックチェーン３０は、データの所与のインスタンスの変更ログ及び現在の状態を表す。

【0036】

[0045]いくつかの実施形態において、ブロック内のデータは、暗号化される。所与のブロック内のデータを復号するための鍵は、それらのノードクライアントのユーザのコピーに従って記憶される。これらの実施形態において、ノードクライアントのすべてのインスタンスが、すべてのブロックを読み出す／書き込むことを有効にされるわけではない。例えば、いくつかの実施形態において、クライアントＡは、クライアントＡブロックを読み出す／書き込むことができ、クライアントＢは、クライアントＢブロックを読み出す／書き込むことができるが、クライアントＡは、クライアントＢブロックを読み出す／書き込むことができず、その逆も然りである。

【0037】

[0046]図４は、クライアントフロントエンドとブロックチェーンへのアクセシビリティとの関係性を例証するブロック図である。所与のユーザは、データ操作システム３８のノードを動作させる。データ操作システム３８は、ディスク、クラウドサーバ、ブロックチェーンネットワークピアノードのハードディスク、又は他の好適な記憶媒体もしくはストレージ場所に記憶されるブロックチェーン２０、３０を参照するユーザのフロントエンドＵＩ４０を含む。ブロックチェーン２０、３０内のデータは、暗号化され、フロントエンドＵＩ４０における使用のためにローカルシステムメモリ内で復号される。この文脈における「メモリ」は、ランダムアクセスメモリ（「ＲＡＭ」）又は他の揮発性ストレージ構造体を指す。メモリは、不揮発性ストレージを指す「ディスク」又は「ハードディスクストレージ」とは全く異なる。

【0038】

[0047]フロントエンドＵＩ４０の使用は、ブロックチェーン２０、３０の存在を曖昧にし、フロントエンドＵＩ４０のユーザは、必ずしもブロックチェーンの存在に気が付かない。ブロックチェーン２０、３０は、ユーザのデータを安全に記憶するデータ構造である。ブロックチェーン２０、３０は、データ操作システム３８のバックエンドに存在し、ユーザは、ブロックチェーンと直接インタラクトしない。人間のユーザは、ブロックファイルの各々が暗号化及びハッシュ化されたデータを含有することが理由で、ブロックファイルの意味を理解することはできない。故に、悪意のある者は、解読できるデータにアクセスするためには、フロントエンドＵＩ４０への、又はフロントエンドＵＩ４０が使用中である間にローカルシステムメモリへのアクセスを有さなければならない。

【0039】

[0048]フロントエンドＵＩ４０は、所与のユーザ又は組織の目的に合わせてカスタマイズ可能である。ユーザ／組織が有するデータニーズが何であるにしても、フロントエンドＵＩ４０は、それに応じて構築される。フロントエンドＵＩ４０を使用している間、ユーザは、フロントエンドＵＩ４０に存在するフィールド又は入力インターフェースが何であるにせよそれらを介して新規データ４２を入力する。その入力された新規データ４２が依然としてローカルシステムメモリ内にある間、データ操作システム３８は、そのデータ４４をブロックチェーン２０上の新規ブロック４６へと変換する。新規ブロック４６は、ブロックチェーン２０の終わりに付加される。新規データ４２は、ユーザによって入力された後、メモリ内でリアルタイムに暗号化される。暗号化されたデータは、次いで、新規ブロック４６に記憶される。いくつかの実施形態において、ブロックは、ノード、サーバに書き込まれ、同時にクラウド／バックアップドライブに送られる。サーバ及びバックアップドライブに送られるブロックは、エンドツーエンドの暗号化トンネルを可能にするＳＳＨ送信を使用してそのように行われる。

【0040】

[0049]ユーザが以前に入力されたデータ４６を求める場合、データ操作システム３８は、データがブロックチェーン２０、３０から取得され、データが復号され、フロントエンドＵＩ３８上でユーザに提示されるプロセスをトリガする。データは、各ブロックの暗号化されていないユーザＩＤ部分の使用により取得される。ユーザＩＤに基づいて、システムは、復号可能なデータを有するブロックを識別する。データ取得プロセスは、フロントエンドＵＩ４０の動作に基づいてユーザに対して透過的である。データのソースは、ユーザに対してはっきりと明らかにされない。データは、ブロックチェーン２０、３０から取得され、メモリ５０内で復号される。一旦メモリ５０内で復号されると、プレーンテキストデータが、フロントエンドＵＩ４０上でユーザに提示される。

【0041】

[0050]ユーザが以前に入力されたデータ４８に対して変更を行う場合、変更は、メモリ５２内でなされ、暗号化され、実装される実施形態及び／又は修正されているデータのタイプに基づいて分岐ブロックチェーン３０上の新規ブロック４６又は編集ブロック５４のいずれかに入れられる。分岐ブロックチェーン３０なしのいくつかの実施形態において、編集されたデータは、新規ブロック４６に入り、メインブロックチェーン２０に付加される。

【0042】

[0051]データセキュリティは、暗号化されていないデータをハードディスクから離すことにより維持される。攻撃者がデータを消費するための機会は、暗号化されていないデータを送信する、又は暗号化されていないデータを記憶するシステムよりも著しく狭い。

【0043】

[0052]図５は、データをブロックチェーンへ付加する方法を例証するフローチャートである。ユーザは、フロントエンドＵＩを介してデータをブロックチェーンに付加する。正当な付加は、ログイン認証情報を入力したログインユーザによって、フロントエンドＵＩを通じてのみ開始され得る。いくつかの実施形態において、暗号鍵対は、ブロックチェーンに付加する能力を行使する。フロントエンドＵＩ内の鍵対にアクセスするプログラムコードは、ログインなしに実行されることはできない。故に、ステップ５０２において、システムは、現在のユーザの認証情報を確認する。認証情報は、多要素認証（ＭＦＡ）を含むいくつかの手段を通じて調査され得る。要素の包括的でないリストは、地理位置情報ロック付き（例えば、フロントエンドＵＩを使用するデバイスの場所）、第２のデバイスロック付き、外部の活動期間コード、生体認証鍵、及びログイン認証情報を含み得る。

【0044】

[0053]ステップ５０４において、ローカルノードは、ログイン情報を介して第１のサーバによりセキュアトンネル（例えば、ＳＳＨ及び／又はＳＣＰ暗号化トンネル形式）を確立する。いくつかの実施形態において、第１のサーバは、アービタサーバと称され得る。アービタサーバは、いくつかのノードによるブロックチェーンへの付加における複数の同時の試みにわたるブロック順序を調整するように構成される。ステップ５０６において、ローカルノードは、フロントエンドＵＩを介して、入力データを受信し、データを変数としてローカルシステムメモリに記憶する。フロントエンドＵＩ上への新規データの表示は、メモリへのアクセスを介して実施される。プレーンテキスト形式にある新規データは、ローカルノードのローカルディスクドライブ上に記憶されない。入力データがメインブロックチェーンに付加されるか、分岐ブロックチェーンに付加されるかは、データ取得プロセスの関数である（以下にさらに詳細に論じられる）。

【0045】

[0054]ローカルノードによる付加リクエストに基づいて、ステップ５０８において、アービタサーバは、新規ブロックファイル又はフォルダを生成し、ファイル又はフォルダ名をローカルノードと同期させる。アービタサーバは、ブロックチェーン上のブロックの線形順序付けを維持する。アービタサーバが新規ブロックファイルを生成する場合、アービタサーバは、ブロックチェーン上の所与の位置へのローカルノードのリクエストを確立している。この段階で、新規ブロックファイル又はフォルダは、いかなるペイロードデータも含まない。代替の実施形態において、ローカルノードは、まず、新規ブロックファイル／フォルダを作成し、最後のブロックへのリンクリスト参照を確立するアービタサーバから命名コンポーネントを獲得する。新規ブロックの生成中、最後のブロックは、ブロックを提出する他のノードに基づいて変化し得る。新規ブロックの名前は、最後のブロックへの参照を更新するために生成全体を通じて動的に修正される。

【0046】

[0055]このプロセスは、ブロックチェーンのどの部分が付加されているかにかかわらず、変わらない。新規ブロックがどこに行くかにかかわらず、依然として何らかのチェーン上に新規ブロックが存在する。新規ブロックの命名規則は、ブロックチェーン内のブロックの順序を示す。ブロックの名前は、データを付加することを同時に試みる複数のノードを受け入れるために動的に生成される。いくつかの実施形態において、ブロックファイル／フォルダ命名規則は、「＿ｘ」を名前の終わりに追加することを含み、ｘは、最後のブロック＋「．ｂｌ」（例えば、ファイルタイプ指定）である。ファイルタイプ指定「．ｂｌ」は、恣意的な選択であり、任意のファイル名拡張子が使用され得る。システムは、システム設計に基づいて特定のファイルタイプ指定を認識するように構成される。新規ブロックは、最後のブロック番号を使用して命名される。

【0047】

[0056]ステップ５１０において、ローカルノードは、最後のブロックをアービタサーバと同期させて、最新ハッシュを比較することによってノードが直近のコピーを有することを確実にする。ステップ５１２において、識別データは、新規ブロックのためのファイル／フォルダ内へ挿入される。識別データは、最後のブロックのハッシュが新規ブロックファイル内へ挿入される、ログインユーザのユーザＩＤ、新規ブロックハッシュ、及び時刻／日付スタンプを含む。識別データは、新規ブロックファイルのヘッダ部分において、又はデリミタの使用により、示され得る。同期装置は、必要なときに（例えば、同時提出に起因して）ブロックを再順序付けするために有効にされ、最後のハッシュ完全性を確実にする。最後のブロック整数カウンタの使用は、付加プロセス中にファイル名を更新する（いくつかの実施形態において、更新は、最後のハッシュをさらに含む）。このファイルはまた、それが外部ソースによって変更されることができないことを確実にするために、０００の許可にロックされる。いくつかの実施形態において、ローカルノードは、各受信ブロックの時間スタンプに基づいてブロックをローカルで再順序付けする。

【0048】

[0057]いくつかの実施形態において、ブロックのすべての部分は、ＩＤ、最後のハッシュ、及びハッシュを除き、ブロック内で暗号化される。新規ブロックシステムにおいて、ログイン情報もまた、ブロック自体に含まれる。ブロックは、ＩＤ（最後のブロック番号）、前のブロックからの最後のハッシュ、新規ハッシュ、時刻／日付スタンプ、ブロックを作成したログインユーザ名、グループへの所属、及び暗号化されるべきすべての新規データを含む。

【0049】

[0058]同期は、別個のソフトウェアユーティリティ（ノードごと）によって開始されるバックグラウンドプロセスであり、自動的である。ユーザ入力は必要とされない。同期は、コンピュータがリブートされ／オンにされ、バックグラウンドで静かに実行する起動時に、同期を必要とする欠損又は新規ブロックを読み込む。同期は、新規ブロックが、サーバ、クラウドにアップロードされ、以て他のノードに利用可能であるように利用可能なインターネットがない期間中に作成されることを可能にする。ファイル名内のブロック番号による再命名／再順序付けは、必要に応じて自動的に行われ、時刻／日付スタンプによってソートされる。タイムスタンプが暗号化される場合、ブロックは、タイムスタンプを評価するために復号され、次いで再暗号化され、新規ブロッカ順序番号を使用して再命名される。

【0050】

[0059]ステップ５１４において、ローカルノードは、プレーンテキスト新規データを（メモリ内で）暗号化して、新規ブロックファイル／フォルダのペイロード内の暗号文へ書き込む。システムは、最後／新規のハッシュ、ユーザ識別情報などの識別データを暗号化しない。いくつかの実施形態において、時刻／日付は、同様に暗号化されない。いくつかの実施形態において、新規データは、暗号化の前に新規ブロックファイル／フォルダのローカルコピーに書き込まれ得るか、又はその逆も然りである。この様式では、新規データのプレーンテキストは、プレーンテキストを暗号化するのに必要とされるよりも長い時間にわたってローカルシステムメモリの外側には存在しない。

【0051】

[0060]暗号化は、ユーザ関連鍵を使用して実施される。いくつかの実施形態において、ユーザ関連鍵は、秘密鍵又はユーザ関連暗号鍵対である。いくつかの実施形態において、新規データを暗号化するために使用される鍵は、許可レベルを示す（例えば、ユーザの所与のサブクラス内のすべてのユーザが暗号鍵を共有する）別個の関係のない鍵である。ユーザの様々なレベルの階層におけるユーザは、データにアクセスするために必要とされる許可のレベルに基づいて複数の暗号鍵を有し得る。好適な暗号化法の例は、ＳＨＡ３－５１２ビット及びＡＥＳ－１２８又は２５６ビットレベル暗号化を含む。いくつかの実施形態において、システムは、無作為の強力なパスワード及び三重入れ子アレイ内のハードウェア鍵ルックアップを使用する。いくつかの実施形態において、同じ単一の暗号鍵が、すべての許可レベルにわたって使用され、所与のユーザの「鍵」は、代わりに、システムがそのユーザのための復号の際に単一の暗号鍵を実装するブロック番号への関連性を指す。それらの実施形態において、ユーザの鍵は、暗号関係とは対照的にプロトコル許可の問題である。

【0052】

[0061]ステップ５１６において、最後のブロックは、ローカルノードが依然として最新バージョンを有することを決定するために、ローカルノードとアービタサーバとの間で再び同期される。ステップ５１８において、新規ブロックは、ローカルノード上のディスクに保存される。ステップ５２０において、ローカルノードは、安全な通信トンネルを介して、アービタサーバに保存される際に新規ブロックを更新する。完全性は、最後のブロックが真に最後のブロックであることを確実にするために、一貫してチェックされる（例えば、保存プロセス中、最後のブロックが６０から６１へ変わる場合、ノードは、ブロックを６２として書き込み、それをアップロードし、次いで番号６２を有する新たな最後のブロックファイルをアップロードする）。２つの同じ番号の付いたブロックが同時に書き込まれようとする場合に備えて、同期装置が存在する。

【0053】

[0062]ステップ５２２において、新規ブロックは、他のノード及び第２のサーバと同期される。いくつかの実施形態において、第２のサーバは、クラウドサーバと称され得る。ステップ５２４において、成功又は失敗メッセージが、参加デバイスに対して発行される。

【0054】

[0063]ブロックは、すべてのノード上でほぼリアルタイムにサーバ及びクラウドドライブに送信され、ブロックは、サーバ及びバックアップドライブ上に存在する。ノードは、ブロックをダウンロードして戻し、次いで、暗号化されたデータをアレイ内（メモリ内）へ読み出す。データは、次いで、アレイ内で復号される。最後のブロックは、ブロックデータが書き込まれる前に１回（ステップ５１２において）、及び所与のブロックが真に最後のブロックであることを確実にするためにブロックデータが書き込まれた後に再度（ステップ５１６）、２回付加される。新たな最後のブロックがサーバ／バックアップドライブ上にまだない場合、アービタサーバは、エラーを生成し、わずかな待機時間があった後に、再びトライする。同期装置は、重複ブロックが存在しないことを確実にし、任意の２つのノードが同時に（ミリ秒に至るまで）同じブロックに書き込むことがたまたま発生する場合は、再順序付けを実施し、そのような場合、時刻／日付スタンプは、順序を確実にするために使用される（ここでも、ミリ秒に至るまで）。最も早い時間に優先度が与えられる。

【0055】

[0064]図６は、ピアネットワーク５８内のアービタサーバ５６のブロック図である。ピアネットワーク５６は、いくつかの分散ノード、又はピアノード６０を含む。ピアノード６０は、アービタサーバ５８及びクラウドサーバ６２の両方に記憶されるブロックチェーン２０のコピーと同期する。ローカルノードがピアネットワーク５８上で動作するために、ピアノード６０は、必ずしも各々が、ブロックチェーン２０の全体、又はその最新のバージョンを記憶しなければならないということはない。

【0056】

[0065]ピアノード６０の同期は、ピアノード６０がネットワークと通信している間に一定間隔で発生するが、いくらかの時間にわたってオフラインであった所与のノード６０は、ブロックチェーン２０の最新のバージョンを必ずしも有さない。ノードがある期間の無活動後にネットワークに再参加している場合、同期は、ノードにすべての欠損ブロックを受信させる。いくつかの実施形態において、ピアノード６０は、ブロックチェーンデータに対して周期的同期プロセスを実行しながら互いに直接通信し、更新された同期データを互いの中から獲得する。

【0057】

[0066]同期は、従来の暗号通貨ベースのブロックチェーンで行われるコンセンサスに対するアナログプロセスである。同期を通じて、ブロックチェーン２０、３０の不変性が行使される。

【0058】

[0067]図７は、ブロックチェーンからの正当なデータ取得の方法を例証するフローチャートである。フロントエンドＵＩのユーザは、ブロックチェーンの存在をはっきりとは知らされない。ブロックチェーン上のデータのデータリクエストは、フロントエンドＵＩの構成に基づいていくつかの方法でなされ得る。しかしながら、結局のところ、フロントエンドＵＩは、検索機能を使用して動作する。使用される検索クエリは、構成及び各々の所与の使用事例に基づいて、ユーザ生成され得るか、又はインターフェース生成され得る。

【0059】

[0068]データを付加することと同様に、ユーザは、データをプレーンテキストとして受信するためにはフロントエンドＵＩにログインしなければならない。ブロックチェーンへのアクセスを有する者は誰でも、その中のデータを見ることができるが、データは、暗号文として記憶され、フロントエンドＵＩを介して（間接的に）アクセスされる関連暗号鍵のない者には理解不可能である。故に、ステップ７０２において、ローカルノードは、図５のステップ５０２と同じ様式でユーザ認証情報を検証する。

【0060】

[0069]ユーザは、様々なレベルの許可を有する。いくつかの実施形態において、ユーザは、自分がブロックチェーンに付加したデータのリクエストのみを行うことができる。いくつかの実施形態において、ユーザは、自分のユーザクラス内の（又はより低い階層のユーザクラス）のデータのリクエストのみを行うことができる。ユーザクラス階層は、横方向であってもよく、すなわち、１つの分岐内の最高階層ユーザでさえ、横の（しかしながらより低い）ユーザクラスのユーザによって付加されるデータへのアクセスを有さない場合がある（例えば、ＣＥＯは、ＨＲによって入力される機密人事苦情に関するデータにアクセスすることが妨げられる）。

【0061】

[0070]ステップ７０４において、システムは、検索クエリを規定する。フロントエンドＵＩが特定のフィールドを埋めることを検討している場合、検索クエリは、フロントエンドＵＩによって規定され得る。詳細には、データが関連フィールドに入力されるとき、固有コードが、検索クエリに直接対応するデータに付加され得る。故に、検索クエリは、固有コードを含むデータによってのみ満足されることになる。クエリの検索結果は、単一の結果を有することになり、ＵＩ要素は、適切なデータを取得する。いくつかの実施形態において、検索クエリは、あまり詳細ではなく、所与のユーザは、他の技術を使用して所望のデータのためのブロックチェーンを検索している場合がある。

【0062】

[0071]ステップ７０６において、ローカルノードは、そのユーザによって復号され得るブロックチェーンの部分を読み込み、ローカルメモリ内にプレーンテキストを記憶する。ノードローカルメモリ内に読み込まれるブロックは、ローカルディスクに記憶されるローカルコピー、又はアービタサーバもしくはクラウドサーバのいずれかからのものであるか、のいずれかであり得る。所与のユーザによって復号され得るブロックチェーンの部分は、各ブロックに記録される暗号化されていないユーザＩＤに基づいて示される。

【0063】

[0072]ステップ７０８において、ローカルノードは、メモリ内に記憶されるブロックを復号する。復号は、ローカルノードにより保持され、アクティブユーザによって認証される適切な暗号鍵を使用する。ブロックチェーンの復号は、各ブロックのために別個のファイルが存在するため、並行して発生し得る。暗号化は、ブロックチェーン全域（例えば、ブロックチェーンのすべての文字）ではなく、ブロック当たりで実施される。

【0064】

[0073]ステップ７１０において、検索クエリは、復号されたブロックのプレーンテキストに適用される。ブロックチェーンが、ユーザにとってメモリ内に全体的に記憶するには大きくなりすぎてしまった場合、検索クエリは、ブロックに、各々が復号される際に適用され得る。検索ノードは、検索クエリを用いて動作している検索エンジンが所与のブロックのプレーンテキストに対するしきい値信頼性又は妥当性スコアを下回る場合、メモリからブロックを破棄する。説明した技術と対照的に、データベースは、一般的には、本明細書に説明されるようなエントリごととは反対に、それらの全体において暗号化又は復号される。暗号化／ブロックレベルでの暗号化は、より離散的であり、より効率的なデータ処理を可能にする。加えて、データベース内の各データ要素は、より大きいデータサイズを有する傾向があり、したがって、アルゴリズム的にも個別にもより扱いにくい。

【0065】

[0074]しきい値信頼性は、適用された検索アルゴリズムに基づく。検索エンジンが、完全一致を使用する（例えば、特定のポインタコードを探している）場合、完全一致に満たないプレーンテキストブロックは、破棄され得る。検索エンジンは、キーワード検索又は知識グラフを使用してもよく、この場合、結果は、所与の結果が最初のキーワード検索にどのように関係しているか、又は所与の結果が知識グラフに基づいてどのように関連しているかに関係した所与の信頼性又は妥当性評価である。使用される検索エンジンスタイルにかかわらず、しきい値フィルタは、各ブロック内の結果に適用される。所与のブロックが、しきい値信頼性又は妥当性スコアを上回るいかなるプレーンテキストコンテンツも含まない場合、限られたメモリ空間内にそのデータを保持する理由はほとんどない。したがって、低い信頼性／妥当性スコアのプレーンテキストデータは、破棄される。

【0066】

[0075]１つのブロックが破棄されると、新規ブロックが、メモリ内に読み出され、復号され、検索される（検索の結果は、破棄されるか、該当する場合はメモリ内に保持される）。「破棄すること」は、揮発性メモリ内の関連空間をクリアすることを指す。復号されたブロックが破棄されるとき、元のブロックは、不揮発性ストレージ内に暗号化形式で記憶される。しかしながら、プレーンテキストバージョンはなくなる。ステップ７１２において、検索結果は、フロントエンドＵＩを介して提示される。

【0067】

[0076]図８は、データ入力インターフェース及び関連ブロックチェーンのスクリーンショットである。いくつかの実施形態において、ブロックチェーンデータ構造は、平均的なユーザにとっては大部分が不可視である。それは、フィールド内に表されるデータ及びブロックチェーンデータ構造内の暗号化されたデータの関係性が、ユーザインターフェースの機能のためにユーザインターフェースを介してユーザに表示される必要がないということである。例えば、図に描写されるのは、クレジットカードアプリケーションのためのデータ入力インターフェース８００である。ユーザがクレジットカードアプリケーションフォーム８０４のフィールド８０２内へデータを入力すると、このデータは、暗号化されたブロック８０６へと変換される。いくつかの実施形態において、新規ブロックは、各フィールド８０２について生成され、またユーザがそのフィールドから離れる方へ移動する（例えば、別のフィールドをクリックする）度に生成される。

【0068】

[0077]新規ブロックは、フィールド８０２における変化に応答して生成される。フィールド８０２における変化は、ユーザインターフェースアプリケーションを介して検出され得る。詳細には、入力インターフェースは、メモリ内で変化したデータに基づいて変更がなされたことを識別する（例えば、キーストローク検出、メモリ内でデータを変更するプロセスの部分として）。代替的に、変更は、メモリ内の現在のデータを暗号化し、不揮発性ストレージ内の暗号化されたブロック内のデータと比較することに基づいて検出され得る。不一致が存在する場合、データが変更されており、ノードが新規ブロックを生成する。

【0069】

[0078]いくつかの実施形態において、フィールド８０２ごとに単一のブロックを生成するのではなく、単一のブロックが、フォーム全体８０４のために使用される。ユーザによって入力されるデータに加えて、ビューアアプリケーションは、ユーザ入力されたデータがどのフィールドと関係しているかを示すために使用されるポインタデータを自動的に含み得る。

【0070】

[0079]図の右側には、ブロックチェーンデータ構造の一部分が描写される８０８。示されるブロック８０６は、ユーザがアプリケーションのユーザインターフェース上のクレジットカード取り込みフォームを完了すると、更新する。とりわけ、ブロックチェーンデータ構造の描写の左側のユーザＩＤカラム８１０は、多数のユーザが同時にブロックチェーンに追加していることを示す。各々は、独立したデータ入力タスクを実施している。

【0071】

[0080]図９は、ブロックチェーンから得るブロックチェーンビューアアプリケーション９００のスクリーンショットである。スクリーンショットに描写されるのは、ブロックチェーンビューアアプリケーション９００の実施形態のための閲覧ページである。描写される円グラフ及び表は、全国的な、及び時系列でのクレジットカードアカウントの分布を示すブロックチェーンデータ構造からの構造化データの例を例証する。

【0072】

[0081]例は、詳細には、大量の顧客アカウントのクレジットカードデータを呼び出し、そのデータを単一の場所に表示する。描写されたデータは、ページがアクセスされるときに自動的に取得される。データの各表現は、ブロックチェーンデータ構造の関連部分から抽出されるソースデータのグラフィック変換である。アプリケーションの所与のユーザがブロックチェーンの関連部分を復号するために必要な許可を有する場合、それらの部分は、メモリ内に引き込まれ、復号され、記録されたデータを特定の様式で表示する機能のための入力としてビューアアプリケーションに適用される。

【0073】

[0082]ブロックチェーンデータ構造から呼び出されるデータは、比較的小さいフラットファイルのセットであり、故にこのデータを呼び出すことは迅速である。データの表現の機能及び様式は、ビューアアプリケーション自体に縛られる。記憶されたデータが厄介なデータ処理コード（例えば、データがどのように鍵をかけられるべきか、データがどのように提示され得るかなど）を含む、データベースソフトウェアの多くのアプリケーションとは異なり、フラットファイル内のデータの処理は、ビューアアプリケーション自体によって実施される。データ自体からビューアアプリケーションへの処理のシフトは、各データ要素をより軽量にし、データを呼び出して提示するための全体的な処理時間／負荷を低減する。

【0074】

[0083]図１０は、上に説明される方法／アルゴリズムのうちのいずれかを実行するためのシステムを表現することができる処理デバイス１０００の例を示す高レベルブロック図である。システムは、ネットワーク又は複数のネットワークを介して互いに結合され得る、図１０に表されるものなどの２つ以上の処理デバイスを含み得る。ネットワークは、通信ネットワークと称され得る。

【0075】

[0084]例証された実施形態において、処理デバイス１０００は、１つ又は複数のプロセッサ８１０、デジタルストレージ１０１１、通信デバイス１０１２、及び１つ又は複数の入力／出力（Ｉ／Ｏ）デバイス１０１３を含み、すべてが相互接続１０１４により互いに結合される。相互接続１０１４は、１つ又は複数の導電性トレース、バス、ポイントツーポイント接続、コントローラ、スキャナ、アダプタ、及び／又は他の従来の接続デバイスであり得るか、又はこれらを含み得る。各プロセッサ１０１０は、例えば、１つ又は複数の汎用プログラマブルマイクロプロセッサもしくはマイクロプロセッサコア、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、プログラマブルゲートアレイ、又は同様のもの、あるいはそのようなデバイスの組み合わせであり得るか、又はこれらを含み得る。プロセッサ１０１０は、処理デバイス１０００の全体的な動作を制御する。デジタルストレージ１０１１は、ランダムアクセスメモリ（ＲＡＭ）、リードオンリメモリ（ＲＯＭ）（消去可能及びプログラム可能であり得る）、フラッシュメモリ、小型ハードディスクドライブ、又は他の好適なタイプのストレージデバイス、又はそのようなデバイスの組み合わせの形態にあり得る、１つ又は複数の物理ストレージデバイスであり得るか、又はこれらを含み得る。デジタルストレージ１０１１は、データ、及び上に説明される技術に従って動作を実行するようにプロセッサ１０１０を構成する命令を記憶し得る。通信デバイス１０１２は、例えば、イーサネットアダプタ、ケーブルモデム、Ｗｉ－Ｆｉアダプタ、セルラー送受信機、ブルートゥース（登録商標）送受信機、又は同様のもの、あるいはそれらの組み合わせであり得るか、又はこれらを含み得る。処理デバイス１０００の特定の性質及び目的に応じて、Ｉ／Ｏデバイス１０１３は、ディスプレイ（タッチスクリーンディスプレイであってもよい）、音声スピーカ、キーボード、マウス又は他のポインティングデバイス、マイク、カメラなどのデバイスを含み得る。

【0076】

[0085]物理的可能性に反しない限り、（ｉ）上に説明される方法／ステップが、任意の配列で及び／又は任意の組み合わせで実施され得ること、並びに（ｉｉ）それぞれの実施形態の構成要素が、任意の様式で組み合わせられ得ることが想起される。

【0077】

[0086]上で紹介される技術は、ソフトウェア及び／もしくはファームウェアによってプログラムされる／構成されるプログラマブル回路によって、又は全体的に特殊目的回路によって、あるいはそのような形態の組み合わせによって、実施され得る。そのような特殊目的回路（ある場合）は、例えば、１つ又は複数の特定用途向け集積回路（ＡＳＩＣ）、プログラマブル論理デバイス（ＰＬＤ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）などの形態にあり得る。

【0078】

[0087]ここに紹介される技術を実施するためのソフトウェア又はファームウェアは、マシン可読ストレージ媒体に記憶され得、１つ又は複数の汎用又は特殊目的プログラマブルマイクロプロセッサによって実行され得る。「マシン可読媒体」は、本用語が本明細書内で使用される場合、マシンによってアクセス可能な形態で情報を記憶することができる任意の機序を含む（マシンは、例えば、コンピュータ、ネットワークデバイス、携帯電話、パーソナルデジタルアシスタント（ＰＤＡ）、製造ツール、１つ又は複数のプロセッサを有する任意のデバイスなどであり得る）。例えば、マシンアクセス可能媒体は、記録可能／記録不可能な媒体（例えば、リードオンリメモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、磁気ディスクストレージ媒体、光学ストレージ媒体、フラッシュメモリデバイスなど）などを含む。

【0079】

[0088]処理デバイス１０００と関連付けられた物理及び機能構成要素（例えば、デバイス、エンジン、モジュール、及びデータレポジトリなど）は、回路、ファームウェア、ソフトウェア、他の実行可能な命令、又はそれらの任意の組み合わせとして実装され得る。例えば、機能構成要素は、１つ又は複数の適切にプログラムされたプロセッサ、単一のボードチップ、フィールドプログラマブルゲートアレイ、実行可能な命令によって構成される汎用コンピューティングデバイス、実行可能な命令によって構成される仮想マシン、実行可能な命令によって構成されるクラウドコンピューティング環境、又はそれらの任意の組み合わせの形態にある、特殊目的回路の形態で実装され得る。例えば、説明される機能構成要素は、プロセッサ又は他の集積回路チップ（例えば、ソフトウェア、ソフトウェアライブラリ、アプリケーションプログラムインターフェースなど）によって実行されることができる有形ストレージメモリ上の命令として実装され得る。有形ストレージメモリは、コンピュータ可読データストレージであり得る。有形ストレージメモリは、揮発性又は不揮発性メモリであってもよい。いくつかの実施形態において、揮発性メモリは、それが一時的な信号ではないという意味で、「非一時的」と見なされ得る。図に説明されるメモリ空間及びストレージは、揮発性又は不揮発性メモリを含む有形ストレージメモリによっても実装され得る。

【0080】

[0089]上に説明される実施形態のいずれか及びすべては、それが上記とは別の方式で記載される得る限り、又は任意のそのような実施形態が機能及び／又は構造において相互排他的であり得る限りを除き、互いと組み合わされ得るということに留意されたい。

【0081】

[0090]本発明は、特定の例示的な実施形態を参照して説明されているが、本発明は、説明される実施形態に限定されず、添付の特許請求の範囲の趣旨及び範囲内の修正及び変更を伴って実践され得るということが認識されるものとする。したがって、本明細書及び図面は、制限的意味よりも例証的な意味で考えられるものとする。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【国際調査報告】