特許 7273053 ブロックチェーン通信と順序付け

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

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

(11)【特許番号】

(24)【登録日】2023-05-01

(45)【発行日】2023-05-12

(54)【発明の名称】ブロックチェーン通信と順序付け

(51)【国際特許分類】

   H04L 9/32 20060101AFI20230502BHJP

【ＦＩ】

H04L9/32 200Z

【請求項の数】 14

(21)【出願番号】P 2020547298

(86)(22)【出願日】2018-11-28

(65)【公表番号】

(43)【公表日】2021-02-15

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

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

(87)【国際公開日】2019-06-06

【審査請求日】2021-11-16

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

(32)【優先日】2017-12-01

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

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

(32)【優先日】2017-12-15

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

(73)【特許権者】

【識別番号】520189980

【氏名又は名称】クアント ネットワーク リミテッド

(74)【代理人】

【識別番号】110002860

【氏名又は名称】弁理士法人秀和特許事務所

(72)【発明者】

【氏名】ベルディアン，ギルバート

(72)【発明者】

【氏名】パターソン，コリン

(72)【発明者】

【氏名】モンデッリ，ガエターノ

(72)【発明者】

【氏名】タスカ，パオロ

【審査官】行田 悦資

(56)【参考文献】

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

【文献】国際公開第２０１７／１６３２２０（ＷＯ，Ａ１）

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

Ｈ０４Ｌ ９／３２

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

【請求項1】

１つ以上のブロックチェーン上に現れるトランザクションの順序の記録を維持するためのコンピュータ実装方法であって、前記方法が
複数のトランザクションを識別することであって、前記複数のトランザクションの各トランザクションが前記１つ以上のブロックチェーンのいずれかに含まれていることと、
前記複数のトランザクションの記録をデータストアに保存することであって、前記記録が前記複数のトランザクションの相対順序を示すことと
を含む、方法。

【請求項2】

前記複数のトランザクションを識別することが、
前記１つ以上のブロックチェーンの各々に追加された新しい各ブロックの内容を読み取ることを含む、請求項１に記載の方法。

【請求項3】

前記複数のトランザクションを識別することが、
前記新しい各ブロック内のトランザクションを関連性基準と比較することであって、前記識別された複数のトランザクションが、前記関連性基準を満たすトランザクションを含むことをさらに含む、請求項２に記載の方法。

【請求項4】

前記複数のトランザクションの記録をデータストアに保存することは、トランザクションが新しいブロックで識別される度に、その識別されたトランザクションの記録を前記データストアに保存することを含み、前記複数のトランザクションの相対順序が、前記複数のトランザクションの各々が識別された相対順序である、請求項２または請求項３に記載の方法。

【請求項5】

前記複数のトランザクションの記録が複数の連続した検証セットを含み、
前記複数の連続した検証セットの少なくともいくつかは、前記複数のトランザクションのそれぞれ１つ以上に対応する１つ以上のトランザクション識別子を含む、
請求項１～４のいずれか一項に記載の方法。

【請求項6】

前記１つ以上のブロックチェーンの少なくとも１つに、前記複数の連続する検証セットの直近の検証セットの記録を保存すること
をさらに含む、請求項５に記載の方法。

【請求項7】

前記複数の検証セット内の先行する検証セットの記録が前記１つ以上のブロックチェーンの少なくとも１つに存在することを確認することと、
前記先行する検証セットの記録が前記１つ以上のブロックチェーンの少なくとも１つに存在しない場合には、
前記先行する検証セットの記録を前記１つ以上のブロックチェーンの少なくとも１つで再度行うことと
をさらに含む、請求項６に記載の方法。

【請求項8】

前記先行する検証セットの記録が前記１つ以上のブロックチェーンの少なくとも１つに存在しない場合には、
前記先行する検証セットで識別されたトランザクションの各々が、前記１つ以上のブロックチェーンのその対応するブロックチェーンに存在することを確認することと、
前記先行する検証セットで識別された１つ以上のトランザクションが、前記１つ以上のブロックチェーンのそれらの対応するブロックチェーンに存在しない場合には、
前記１つ以上のトランザクションをそれらの対応するブロックチェーンに再度行うことと
をさらに含む、請求項７に記載の方法。

【請求項9】

前記直近の検証セットで識別されたトランザクションの各々が前記１つ以上のブロックチェーンの少なくとも１つに存在することを確認することと、
前記先行する検証セットで識別された１つ以上のトランザクションが前記１つ以上のブロックチェーンのそれらの対応するブロックチェーンに存在しない場合には、
前記１つ以上のトランザクションをそれらの対応するブロックチェーンに再度行うことと
をさらに含む、請求項６～８のいずれか一項に記載の方法。

【請求項10】

前記直近の検証セットの記録が、前記直近の検証セットの内容に少なくとも部分的に基づいて決定される検証セット識別子を含む、請求項６～９のいずれか一項に記載の方法。

【請求項11】

前記直近の検証セットの前記検証セット識別子が、前記直近の検証セットの内容のハッシュを含む、請求項１０に記載の方法。

【請求項12】

前記複数のトランザクションの記録は、各々がそれぞれのトランザクションの内容に少なくとも部分的に基づいて決定される複数のトランザクション識別子を含む、請求項１～１１のいずれか一項に記載の方法。

【請求項13】

１つ以上のプロセッサと、
ソフトウェアプログラムを保存するメモリであって、前記ソフトウェアプログラムが前記１つ以上のプロセッサによって実行されると請求項１～１２のいずれか一項に記載の方法を前記１つ以上のプロセッサに実行させる、メモリと
を含むシステム。

【請求項14】

１つ以上のプロセッサによって実行されると請求項１～１２のいずれか一項に記載の方法を前記１つ以上のプロセッサに実行させる１つ以上のコンピュータプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、１つ以上のブロックチェーン上に現れるトランザクションの順序の記録を維持するための方法、システム、コンピュータプログラムおよびＳＤＫに関する。また、ブロックチェーン通信に関連する方法、システム、コンピュータプログラムおよびＳＤＫにも関する。

【背景技術】

【0002】

ブロックチェーン技術は、広範な用途の可能性を秘め、中央のデータ認証機関を必要とせずに安全かつ確実にデータを保存し得る方法を提供する。その結果、ブロックチェーン技術は、例えば、データの透明性の向上、特定のストレージエンティティに依存しないより堅牢なデータストレージ、データセキュリティの向上、不正への耐性の向上など、幅広いセクターにわたる多くの技術的メリットを可能にし得て、電気エネルギーの分配やピアツーピアのクラウドストレージなど、様々な分野における用途がすでに見出されている。

【0003】

ブロックチェーンは、サトシ・ナカモトの名前で公開された「ビットコイン：ピアツーピア電子キャッシュシステム」という標題のホワイトペーパーで２００９年に最初に概念化された。ホワイトペーパーのコピーは、ｈｔｔｐｓ：／／ｂｉｔｃｏｉｎ．ｏｒｇ／ｂｉｔｃｏｉｎ．ｐｄｆで見出され得る。このホワイトペーパーでは、ビットコインのピアツーピア転送を記録するための、以降ブロックチェーンと呼ばれているものを利用した「ビットコイン」と呼ばれるピアツーピアバージョンの電子キャッシュが提案された。

【0004】

ブロックチェーンは非中央集権化された分散型デジタル台帳であり、これを使用して、効果的に不変のデータ記録が保存され得る。それらは、データをブロックチェーンに追加したり、ブロックチェーンの整合性を維持したりするために中央の権限を必ずしも必要としないという点で非中央集権化されている。データは、ブロックチェーンに参加するノードのネットワークに「トランザクション」をブロードキャストするエンティティによってブロックチェーンに追加され得て、トランザクションは、ブロックチェーンに追加されるデータと、ブロックチェーンプロトコルに準拠する暗号化要素とを含む。次に、ブロックチェーンに参加している各ノードは、トランザクションの有効性を検証し、承認された場合、作業中の新しいブロックにトランザクションを追加する。

【0005】

各ノードは、その新しいブロックに、ノードのネットワークにブロードキャストされた他の新しいトランザクションの作業中であることを追加する場合もある。しばらくすると、ノードは、その新しいブロックをネットワーク内の他のノードに発行し、その新しいブロックには、様々な新しいトランザクションと、新しいブロックをブロックチェーン内の前のブロックに結び付ける暗号化データとが含まれている。このように、連続するブロックを暗号で結び付けることによって、ブロックチェーン内の１つのブロックが後で改変される場合（例えば、誰かがブロックチェーンに保存されているデータを不正に変更したい場合）に容易に検出可能であり得る。

【0006】

ノードが新しいブロックを発行した後、ネットワーク内の他のノードは新しいブロックの内容を確認し、承認された場合、次の新しいブロックで作業を開始し、それがまたその前のブロックに暗号で結び付けられる。したがって、新しいブロックが発行されて承認される度にブロックチェーンが成長し、新しい承認された各ブロックはその前のブロックに暗号で結び付けられていることがわかる。ノードが、発行された新しいブロックを確認し、それをブロックチェーンに受け入れるこのプロセスは、「コンセンサス」メカニズムと呼ばれることがよくある。

【0007】

ホワイトペーパー「ビットコイン：ピアツーピア電子キャッシュシステム」では、ビットコイン用に特定のプロトコルが提案されている。プロトコルは、トランザクションに含めるべき情報の形式と種類、新しいブロックに含まれる情報の形式と種類、トランザクションおよび新しいブロックに使用すべき暗号化技術とレシピ、ならびに使用されるコンセンサスメカニズムの特定の種類（例えば、ビットコインでは、コンセンサスメカニズムは、ブロックチェーンの各ブロックでハッシュベースの作業証明を利用し、これは、連続する各ブロック間の暗号化タイでもある）のような事柄をカバーする。ブロードキャストトランザクションは、プロトコルに適切に準拠していない場合、いずれの新しいブロックにも含まれない。同様に、新しいブロックがプロトコルに適切に準拠していない場合、ノードのネットワークによってブロックチェーンに受け入れられない。

【0008】

ブロックチェーンは分散型台帳技術（ＤＬＴ）とも呼ばれ、最初は暗号通貨ビットコインを有効にするために提案されたが、その後、他の多くの用途が見出されている。最初に、イーサリアム、リップル、ネームコインなどの新しい暗号通貨が発売され、各々独自の特定のブロックチェーンで動作し、独自の特定のプロトコルを利用している。それ以来、ブロックチェーン技術は暗号通貨よりもはるかに広範に活用され得て、かつデータの効果的に不変の記録が役立つあらゆるシナリオで利用され得ることが認識されている。これにより各々特定の使用例に合わせて作られた現存する様々なブロックチェーンの数が急速に拡大することになり、技術がさらに勢いを増し認知度が高まるにつれて様々なブロックチェーンの数が増え続けると予想される。

【発明の概要】

【0009】

本開示の第１の態様では、１つ以上のブロックチェーン（ＤＬＴ）上に現れるトランザクションの順序の記録を維持するためのコンピュータ実装方法が提供され、この方法は、複数のトランザクションを識別することであって、複数のトランザクションの各トランザクションが１つ以上のブロックチェーンのいずれかに含まれていることと、複数のトランザクションの記録をデータストアに保存することであって、記録が複数のトランザクションの相対順序を示すこととを含む。

【0010】

トランザクションの順序の記録を維持することにより、順序が乱れたメッセージに関連するセキュリティおよび安定性の弱点が低減され得るため、１つ以上のブロックチェーンを利用するシステムのセキュリティおよび安定性が向上する。複数のブロックチェーンにまたがるトランザクションの順序付けは特に問題が多く、セキュリティおよび不正の問題にさらされているため、この技術的な利点は、２つ以上（複数）のブロックチェーンにまたがって現れるトランザクションの順序が記録される場合に特に明白である。

【0011】

複数のトランザクションを識別することは、１つ以上のブロックチェーンの各々に追加された新しい各ブロックの内容を読み取ることを含み得る。

【0012】

複数のトランザクションを識別することは、新しい各ブロック内のトランザクションを関連性基準と比較することであって、識別された複数のトランザクションが、関連性基準を満たすトランザクションを含むことをさらに含み得る。関連性基準と比較することにより、関連するトランザクションのみをデータストアで識別すればよく、これにより、データストアが将来レビューされる場合の速度が向上し、必要なデータストアのサイズが削減され得る。

【0013】

好ましくは、データストアに複数のトランザクションの記録を保存することは、新しいブロックでトランザクションが識別される度にその識別されたトランザクションの記録をデータストアに保存することであって、複数のトランザクションの相対順序は、複数のト
ランザクションの各々が識別された相対順序である。

【0014】

好ましくは、複数のトランザクションの記録は、複数の連続した検証セットを含み、複数の連続した検証セットの少なくともいくつかは、複数のトランザクションのそれぞれ１つ以上に対応する１つ以上のトランザクション識別子を含む。

【0015】

この方法はさらに、１つ以上のブロックチェーンの少なくとも１つに、複数の連続した検証セットの直近の検証セットの記録を保存することを含み得る。このようにして、記録の整合性および否認防止が強化され、それによって方法のセキュリティと安定性が向上し得る。

【0016】

この方法はさらに、複数の検証セット内の先行する検証セットの記録が１つ以上のブロックチェーンの少なくとも１つに存在することを確認することと、先行する検証セットの記録が１つ以上のブロックチェーンの少なくとも１つに存在しない場合には、先行する検証セットの記録を１つ以上のブロックチェーンの少なくとも１つで再度行うこととを含み得る。このようにして、トランザクションの記録された順序の信頼性を維持しつつ、ブロックチェーンの初期のフォークがすばやく識別され得る。

【0017】

先行する検証セットの記録は、直近の検証セットの記録を１つ以上のブロックチェーンの少なくとも１つに保存する前に、１つ以上のブロックチェーンの少なくとも１つで再度行ってもよい。

【0018】

この方法はさらに、先行する検証セットの記録が１つ以上のブロックチェーンの少なくとも１つに存在しない場合には、先行する検証セットで識別されたトランザクションの各々が、１つ以上のブロックチェーンのその対応するブロックチェーンに存在することを確認することと、先行する検証セットで識別された１つ以上のトランザクションが、１つ以上のブロックチェーンのそれらの対応するブロックチェーンに存在しない場合には、１つ以上のトランザクションをそれらの対応するブロックチェーンに再度行うこととを含み得る。

【0019】

この方法はさらに、直近の検証セットで識別されたトランザクションの各々が１つ以上のブロックチェーンの少なくとも１つに存在することを確認することと、先行する検証セットで識別された１つ以上のトランザクションが１つ以上のブロックチェーンのそれらの対応するブロックチェーンに存在しない場合には、１つ以上のトランザクションをそれらの対応するブロックチェーンに再度行うこととを含み得る。

【0020】

１つ以上のトランザクションは、直近の検証セットの記録を１つ以上のブロックチェーンの少なくとも１つに保存する前に、それらの対応するブロックチェーンに再度行われ得る。

【0021】

直近の検証セットの記録は、直近の検証セットの内容に少なくとも部分的に基づいて決定される検証セット識別子を含み得る。

【0022】

直近の検証セットの検証セット識別子は、直近の検証セットの内容のハッシュを含み得る。

【0023】

直近の検証セットの記録を保存することは、少なくとも１つのブロックチェーンに含めるために１つ以上のブロックチェーンの少なくとも１つのブロックチェーンにトランザクションをブロードキャストすることを含み得て、ブロードキャストされるトランザクションは直近の検証セットの一意の識別子を含む。

【0024】

複数のトランザクションの記録は、各々がそれぞれのトランザクションの内容に少なくとも部分的に基づいて決定される複数のトランザクション識別子を含み得る。

【0025】

複数のトランザクション識別子は、複数のトランザクションの内容の複数のハッシュを含み得る。

【0026】

複数のトランザクションの記録は、複数のトランザクションの少なくともいくつかの内容を含み得る。

【0027】

本開示の第２の態様では、１つ以上のプロセッサと、ソフトウェアプログラムを保存するメモリであって、ソフトウェアプログラムが１つ以上のプロセッサによって実行されると先行する請求項のいずれかに記載の方法を１つ以上のプロセッサに実行させるメモリとを含むシステムが提供される。

【0028】

本開示の第３の態様では、１つ以上のプロセッサによって実行されると第１の態様による方法を１つ以上のプロセッサに実行させる１つ以上のコンピュータプログラムが提供される。

【0029】

本開示の第４の態様では、第３の態様の１つ以上のコンピュータプログラムを開発するためのソフトウェア開発ツールのセットを含むソフトウェア開発キットＳＤＫが提供される。

【0030】

本開示の第５の態様では、アプリケーション機能層と複数の異なるブロックチェーンとの間の相互運用性を提供する方法が提供され、ここで、アプリケーション機能層は複数の異なるブロックチェーンの１つ以上を利用する機能的オペレーションを含み、方法は、ブロックチェーン通信層が、アプリケーション機能層からブロックチェーン要求を受信することであって、ブロックチェーン要求が複数の異なるブロックチェーンの１つ以上のブロックチェーン上で実行されるブロックチェーン動作に関することと、ブロックチェーン動作を実行するために１つ以上のブロックチェーンのプロトコルに従って１つ以上のブロックチェーンとインターフェースすることとを含む。したがって、アプリケーション機能層はブロックチェーンプロトコルから切り離され得て、アプリケーションがより簡単にブロックチェーンをまたいで動作し、かつブロックチェーン間で切り替わることを可能にし、それにより、特定のブロックチェーンにおける任意のセキュリティや安定性の脅威をより迅速に軽減することを可能にする。

【0031】

ブロックチェーン要求は、１つ以上のブロックチェーン上のデータを読み取る要求を含み得る。１つ以上のブロックチェーンからデータを読み取る要求は、１つ以上のブロックチェーンから読み取られるデータを示すデータ識別子を含み得る。

【0032】

１つ以上のブロックチェーンとインターフェースすることは、１つ以上のブロックチェーンで要求されたデータを読み取ることを含み、方法は、ブロックチェーン通信層が、１つ以上のブロックチェーンから読み取られたデータをアプリケーション機能層に通信することをさらに含む。

【0033】

ブロックチェーン要求は、１つ以上のブロックチェーンにデータを書き込む要求を含み得る。

【0034】

データの書き込み要求は、１つ以上のブロックチェーンに書き込むデータを含み得る。

【0035】

ブロックチェーン要求は、複数のブロックチェーンのうちの第１のブロックチェーンと複数のブロックチェーンのうちの第２のブロックチェーンとの間で、クロスレジャートランザクションＸＬＴを実行する要求を含み得て、ＸＬＴを実行する要求は、ＸＬＴによって第２のブロックチェーンに転送される第１のブロックチェーン上のデータを示すＸＬＴ識別子を含む。

【0036】

ブロックチェーン通信層とアプリケーション機能層との間の通信は、ブロックチェーンプログラミングインターフェースＢＰＩによって定義された方法に従って実行され得る。

【0037】

本開示の第６の態様では、１つ以上のプロセッサと、ソフトウェアプログラムを保存するメモリであって、ソフトウェアプログラムが１つ以上のプロセッサによって実行されると先行する請求項のいずれかに記載の方法を１つ以上のプロセッサに実行させるメモリとを含むシステムが提供される。

【0038】

本開示の第７の態様では、１つ以上のプロセッサによって実行されると第５の態様による方法を１つ以上のプロセッサに実行させる１つ以上のコンピュータプログラムが提供される。

【0039】

本開示の第８の態様では、第７の態様の１つ以上のコンピュータプログラムを開発するためのソフトウェア開発ツールのセットを含むソフトウェア開発キットＳＤＫが提供される。

【0040】

本開示の第９の態様では、第１のブロックチェーンと第２のブロックチェーンとの間でクロスレジャートランザクションＸＬＴを実行するための方法が提供され、この方法は、第１のブロックチェーン上でＸＬＴに関連するプロポーズ（ｐｒｏｐｏｓｅ）ＸＬＴトランザクションを識別することと、データストアのトランザクション記録にプロポーズＸＬＴトランザクションの記録を保存することと、第２のブロックチェーン上でレディ（ｒｅａｄｙ）ＸＬＴトランザクションを識別することと、レディＸＬＴトランザクションの記録をデータストア内のトランザクション記録に保存することであって、この記録がプロポーズＸＬＴトランザクションとレディＸＬＴトランザクションの相対順序を示すことと、プロポーズＸＬＴトランザクションとレディＸＬＴトランザクションがＸＬＴ基準を満たすかどうかを判定することと、プロポーズＸＬＴトランザクションとレディＸＬＴトランザクションがＸＬＴ基準を満たしている場合には、第１のブロックチェーンと第２のブロックチェーンとの間でＸＬＴを実行するために第１のブロックチェーンおよび第２のブロックチェーンにコミット（ｃｏｍｍｉｔ）ＸＬＴトランザクションをブロードキャストすることであって、ＸＬＴ基準が、レディＸＬＴトランザクションがプロポーズＸＬＴトランザクションに対応するという第１の基準と、プロポーズＸＬＴトランザクションがレディＸＬＴトランザクションに先行することをトランザクション記録が示すという第２の基準とを含むこととを含む。したがって、１つ以上のブロックチェーンにフォークが発生した場合でも、２つ以上のブロックチェーンにまたがるトランザクションの順序が確実に維持および理解され得るため、クロスレジャートランザクションのセキュリティと信頼性が向上し、不正のリスクが低減される。

【0041】

この方法はさらに、１つ以上のトランザクションを第１のブロックチェーンおよび／または第２のブロックチェーンにブロードキャストすることであって、１つ以上のトランザクションがそれぞれ１つ以上の記録識別子を含み得て、各記録識別子はトランザクション記録の内容の少なくとも一部に少なくとも部分的に基づいて決定され、１つ以上の記録識別子は共にプロポーズＸＬＴトランザクションおよびレディＸＬＴトランザクションの記録を示す。

【0042】

１つ以上の記録識別子は、トランザクション記録の内容の少なくとも一部の１つ以上のハッシュを含み得る。

【0043】

ＸＬＴ基準は、１つ以上のトランザクションが第１のブロックチェーンおよび／または第２のブロックチェーンに含まれ、その結果、１つ以上の記録識別子が第１のブロックチェーンおよび／または第２のブロックチェーンに保存されるという第３の基準を含み得る。

【0044】

プロポーズＸＬＴトランザクションの記録はプロポーズＸＬＴトランザクションの内容のハッシュを含み得て、レディＸＬＴトランザクションの記録はレディＸＬＴトランザクションの内容のハッシュを含む。

【0045】

本開示の第１０の態様では、１つ以上のプロセッサと、ソフトウェアプログラムを保存するメモリであって、ソフトウェアプログラムが１つ以上のプロセッサによって実行されると第９の態様による方法を１つ以上のプロセッサに実行させるメモリとを含むシステムが提供される。

【0046】

本開示の第１１の態様では、１つ以上のプロセッサによって実行されると第９の態様による方法を１つ以上のプロセッサに実行させる１つ以上のコンピュータプログラムが提供される。

【0047】

本開示の第１２の態様では、第１１の態様の１つ以上のコンピュータプログラムを開発するためのソフトウェア開発ツールのセットを含むソフトウェア開発キットＳＤＫが提供される。

【0048】

本開示の第１３の態様では、２つ以上のブロックチェーン上で実行されたトランザクションの相対順序の記録を維持するための方法が提供される。このようにして、異なるブロックチェーンのトランザクションの順序を確実に順序付けることができるため、特にブロックチェーンフォークおよび／またはＸＬＴの場合に、セキュリティと信頼性の向上を可能にする。

【0049】

本開示の第１４の態様では、１つ以上のプロセッサと、ソフトウェアプログラムを保存するメモリであって、ソフトウェアプログラムが１つ以上のプロセッサによって実行されると第９の態様による方法を１つ以上のプロセッサに実行させるメモリとを含むシステムが提供される。

【0050】

本開示の第１５の態様では、１つ以上のプロセッサによって実行されると第９の態様による方法を１つ以上のプロセッサに実行させる１つ以上のコンピュータプログラムが提供される。

【0051】

本開示の第１６の態様では、第１１の態様の１つ以上のコンピュータプログラムを開発するためのソフトウェア開発ツールのセットを含むソフトウェア開発キットＳＤＫが提供される。

【図面の簡単な説明】

【0052】

本開示の態様は、以下の図面を参照して、例としてのみ説明される。

【0053】

【図1】図１は、本開示の一態様によるオーバーレジャー通信層の例示的な表現を示す図である。

【0054】

【図2】図２は、図１のオーバーレジャー通信層を利用するシステムの例示的な表現を示す図である。

【0055】

【図3】図３は、図１のオーバーレジャー通信層を利用するさらなるシステムの例示的な表現を示す図である。

【0056】

【図4】図４は、図３のシステムを使用して実行される例示的な方法のステップの表現を示す図である。

【0057】

【図5】図５は、図１のオーバーレジャー通信層を利用するさらなるシステムの例示的な表現を示す図である。

【0058】

【図6】図６は、ブロックチェーン内のフォークの例示的な表現を示す図である。

【0059】

【図7】図７は、本開示の一態様による、１つ以上のブロックチェーン上に現れるトランザクションの順序の記録を維持するための方法の例示的な表現を示す図である。

【0060】

【図8】図８は、図７の方法が実行される２つのブロックチェーンの例示的な表現を示す図である。

【0061】

【図9】図９は、図７の方法が実行される２つのブロックチェーンのさらなる例示的な表現を示す図である。

【0062】

【図10】図１０は、本開示の態様に従ってクロスレジャートランザクションが実行される２つのブロックチェーンの例示的な表現を示す図である。

【0063】

【図11】図１１は、本開示の一態様によるさらなるシステムの例示的な表現を示す図である。

【0064】

【図12】図１２は、図１１のシステムによって実行される方法の例示的な表現を示す図である。

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

【0065】

本発明者らは、ブロックチェーン技術が成長および発展するにつれて、様々なエンティティが安全、安心、かつ確実にそれを利用することがますます困難になる可能性があることを認識した。例えば、現在、エンティティがブロックチェーン技術を使用する新しいソフトウェアアプリケーションを開発したい場合、独自の新しいブロックチェーンを開始するか（非常に時間がかかり、複雑であり、まったく新しいブロックチェーンプロトコルの確立が必要である）、またはビットコインやイーサリアムなどの既存のブロックチェーン技術を利用しなければならない。

【0066】

本発明者らは、既存のブロックチェーン技術を利用するために、エンティティが、そのブロックチェーンのプロトコルに完全に準拠する、例えばプロトコルによって定められる暗号化技術、トランザクション形式および通信チャネルを使用して、ソフトウェアアプリケーションを開発しなければならないことに気付いた。したがって、使用するブロックチェーン技術の選択は、ソフトウェア開発プロセスの非常に早い段階で、場合によってはソフトウェアアプリケーションの要件と使用法を完全に理解する前に行う必要がある決定である。

【0067】

各ブロックチェーンには、ブロックチェーンの特定のニーズを満たすために策定された
特定のプロトコルがある。ブロックチェーンでハードフォークを発生させずにブロックチェーンプロトコルを変更することはできず、これはブロックチェーンが必要な変更に対してあまり適応性がないことを意味する。その結果、選択したブロックチェーン技術がニーズを満たさなくなったとエンティティが後で判断した場合（例えば、選択したブロックチェーン技術が不安定になったり、安全でなくなったりしたため、または異なるブロックチェーン技術が有利であるようにソフトウェアアプリケーションの要件が変わったため、または最初に選択されたが今では古くなったブロックチェーン技術よりも新しいブロックチェーンが優れているため）、代替となるブロックチェーン技術の使用を開始するには、代替となるブロックチェーン技術のプロトコルに準拠するようにソフトウェアを修正しなければならない。ソフトウェアは最初に選択されたブロックチェーン技術のプロトコルによって設定された基盤上に構築されるため、実際には、これは不可能ではないにしても非常に困難であり得る。したがって、最初から正しいブロックチェーン技術を選択することが非常に重要であるが、ブロックチェーン技術は急速に発展しているため、実際には達成するのが非常に難しい可能性がある。

【0068】

さらに、以前にブロックチェーンに保存された任意のデータは、ブロックチェーンプロトコル間の違いにより、代替となるブロックチェーンに直接転送されない場合がある。

【0069】

本発明者らによって認識されたこれらの長期的な困難に鑑みて、アプリケーションの機能をそれらが利用しているブロックチェーンから分離するために新しい通信層を導入する技術的解決策が本発明者らによって考案され、本開示において提供されている。アプリケーションが動作しているブロックチェーンの様々な要件からアプリケーションの機能を切り離すことにより、アプリケーションとブロックチェーンとの間の相互運用性は改善され得る。以下でより詳細に説明する本開示の態様から理解されるように、これは、将来のブロックチェーン技術の変化に、より効率的かつ柔軟に対応し得ることを意味する可能性がある。これは、セキュリティの脅威への対応（例えば、１つのブロックチェーン技術にセキュリティの欠陥があると認識された場合、アプリケーションがより安全なブロックチェーン技術に簡単に切り替わり得る）、セキュリティおよび信頼性の向上（アプリケーションが複数のブロックチェーン間でより容易に動作し、ブロックチェーン間で重複データを保存し、および／またはブロックチェーン間でデータを転送する可能性があるため）、および／または効率および速度の向上（例えば、より新しいブロックチェーン技術でトランザクションの処理速度が上昇した場合、アプリケーションがそのより新しいブロックチェーン技術に簡単に切り替わり得る）に役立つ可能性がある。

【0070】

以下の開示全体を通じて、「ブロックチェーン」、「ブロックチェーン技術」、「分散型台帳技術（ＤＬＴ）」という用語は互換的に使用される。さらに、以下の開示全体を通じて、「トランザクション」という用語はブロックチェーンに関連して使用される。当業者は、この文脈における「トランザクション」が、例えば通貨など、何らかの所有権の移転に限定されないことを理解するであろう。むしろ、「トランザクション」は、何らかの形の情報をブロックチェーン上に置くことができる手段である。例えば、エンティティは、ブロックチェーン上に置かれる「トランザクション」をブロードキャストする場合があり、トランザクションには、ブロックチェーン上に置かれる情報と、トランザクションがブロックチェーンに承認されるために必要とされるその他のデータ項目（公開鍵、署名、ハッシュなど）とが含まれる。ブロックチェーン上に置かれる情報は、通貨の金融送金に関連する場合があるが、代わりに、任意の他の種類の情報（例えば、エンティティが後で自分自身が参照するためにブロックチェーンに保存したいデータなど）の場合もある。

【0071】

図１は、アプリケーション機能層３０とＤＬＴ層１０との間に位置する「オーバーレジャー通信層」２０の導入の例示的な視覚化を示す。「オーバーレジャー通信層」という用語は、本開示全体を通じて利用され、ＤＬＴのプロトコル要件を、ＤＬＴを利用するアプ
リケーションの機能的オペレーション（「ビジネスロジック」と呼ばれることもある）から切り離す通信層を意味する。

【0072】

図１では、ＤＬＴ層１０の一部として２つのＤＬＴ（第１のＤＬＴ１２および第２のＤＬＴ１４）が示されているが、オーバーレジャー通信層２０は、任意の数の異なるＤＬＴ、例えばビットコイン、イーサリアム、コーダ、オープンチェーン、ハイパーレジャーなどとインターフェース可能であり得ることが理解されよう。各ＤＬＴには、ブロックチェーンからのデータの読み取り、ブロックチェーンへのデータの書き込み、および／または同じブロックチェーン上のあるエンティティから別のエンティティへ、または別のブロックチェーンへ（クロスレジャートランザクション）のデータの所有権の移転など、ブロックチェーン動作用の独自の特定のプロトコルがある（様々なブロックチェーンでは、ブロックチェーンが実行するように構成されている目的に応じて、ブロックチェーン上で読み取り、書き込みおよび移転動作の任意の１つ以上が可能であり得る）。

【0073】

オーバーレジャー通信層２０は、ブロックチェーン動作が第１のＤＬＴ１２および第２のＤＬＴ１４上で実行され得る異なる方法を含む。例えば、第１のＤＬＴ１２はビットコインであり得て、新しいトランザクションをそのブロックチェーンに書き込むための特定のプロトコルを有する。ビットコインの特定のプロトコルは、当業者にはよく理解されているが、簡単に言えば、受取人の公開鍵（受取人の「財布」）、受取人に転送される金額、現在転送中のビットコインを支払者が取得した以前のトランザクションのハッシュ、および（支払者の秘密鍵を使用して署名された）支払者の署名などの情報を含み得る。プロトコルは、これらの各項目の許容される形式（長さやオブジェクトタイプなど）、ハッシュおよび署名を生成するために使用しなければならない暗号技術（ＳＨＡ－２５６など）、ならびに各項目がトランザクション内に表示される順序を定義する。また、プロトコルは、ビットコインのブロックチェーンから情報がどのように読み取られ得るか（例えば、各トランザクションおよびブロックチェーンの各ブロックにどの情報を保持するかを識別する）、情報の形式と順序、ならびに（ブロックチェーンの読み取り時に各々が検証され得るように）ハッシュ、署名および作業証明の生成に使用される暗号技術を定義する場合がある。対照的に、第２のＤＬＴ１４は、読み取り動作のみなど、異なるブロックチェーン動作の実行を許可する完全に異なるプロトコルを備えている場合があり（例えば、それは誰でも読み取ることができる閉じたブロックチェーンであるが、許可されたエンティティのみが書き込みできる）、各ブロックは、異なる情報を異なる順序で含み得る、および／または第１のＤＬＴ１２に対して異なる暗号技術を使用し得る。オーバーレジャー通信層２０は、第１のＤＬＴ１２および第２のＤＬＴ１４の各々で実行される様々な許容可能な動作を可能にする方法を含む。

【0074】

図１に示すアプリケーション機能層３０は、１つ以上のＤＬＴを利用しているアプリケーションの機能的オペレーション（「ビジネスロジック」と呼ばれることもある）を含む。アプリケーションのアプリケーション機能層３０は、ブロックチェーン動作を実行したい場合、関連情報（ブロックチェーン要求）をオーバーレジャー通信層２０に渡し（例えば、ＤＬＴに書き込みたいデータ、またはＤＬＴから読み取りたい情報の性質を含む）、次に、ブロックチェーン動作を実行するために関連するＤＬＴのプロトコルに従って関連するＤＬＴとインターフェースする。次に、オーバーレジャー通信層２０は、任意の関連する結果をアプリケーション機能層３０に返してもよい。この動作は、本開示で後に説明されるより具体的な例からより完全に理解され得る。

【0075】

オーバーレジャー通信層２０に保持されている方法を様々な異なるエンティティが利用できるように、方法は、例えば、ソフトウェア開発キット（ＳＤＫ）にカプセル化されてもよく、これを以降オーバーレジャーＳＤＫと呼ぶ。オーバーレジャー通信層２０に保持されている方法は、任意の他の適切な同等の方法でカプセル化されてもよいことが理解さ
れよう。オーバーレジャーＳＤＫを取得することにより、開発者は、開発している特定のソフトウェアアプリケーション用に利用したいＤＬＴをより簡単に選択してもよく、選択したＤＬＴとの相互作用に必要な方法およびツールをオーバーレジャーＳＤＫに提供させてもよい。

【0076】

図２は、ＳＤＫプロバイダ２１０と、アプリケーション開発者２２０と、開発されたアプリケーション２３０と、第１のＤＬＴネットワーク２４０と、第２のＤＬＴネットワーク２５０とを含むシステム２００の例示的な表現を示す。ＳＤＫプロバイダ２１０は、オーバーレジャーＳＤＫを構築および維持する責任があり得て、オーバーレジャーＳＤＫは、この例では少なくとも第１のＤＬＴ１２および第２のＤＬＴ１４とインターフェース（相互作用）する方法を備えているが、任意の数のＤＬＴのため（すなわち、複数のＤＬＴのため）の相互作用の方法を備えていてもよい。アプリケーション開発者２２０は、第１のＤＬＴ１２および／または第２のＤＬＴ１４を利用するアプリケーションを開発したい場合、ＳＤＫプロバイダ２１０から（例えば、ＳＤＫプロバイダ２１０から、または任意の他のオーバーレジャーＳＤＫホスティングエンティティからダウンロードすることによって）オーバーレジャーＳＤＫを取得し得る。次に、オーバーレジャーＳＤＫを利用してアプリケーション２３０を開発してもよく、次に、アプリケーション２３０は、オーバーレジャーＳＤＫで定義された方法に従って、第１のＤＬＴ１２および／または第２のＤＬＴ１４と相互作用することができる。図２では、第１のＤＬＴネットワーク２４０は第１のＤＬＴ１２の参加ノードのネットワークを表し、第２のＤＬＴネットワーク２５０は第２のＤＬＴ１４の参加ノードのネットワークを表す。図２に示す特定の例では、アプリケーション２３０は、第１のＤＬＴネットワーク２４０および第２のＤＬＴネットワーク２５０の両方と相互作用できることが示されているが、アプリケーション開発者は、代わりにオーバーレジャーＳＤＫを利用して、第１のＤＬＴネットワーク２４０のみ、または第２のＤＬＴネットワーク２５０のみと相互作用するようにアプリケーション２３０を構成してもよいことが理解されよう。

【0077】

特定の一態様では、アプリケーション２３０の開発の一部として、アプリケーション開発者２３０は、アプリケーション２３０のオーバーレジャー通信層２０とアプリケーション機能層３０との間の通信を処理するプログラミングインターフェースを開発してもよい。これ以降、このインターフェースをブロックチェーン・プログラミング・インターフェース（ＢＰＩ）と呼び、ＢＰＩは、アプリケーション機能層３０とオーバーレジャー通信層２０との相互作用を簡素化するのに役立つように構成されている。例えば、アプリケーション２３０のオーバーレジャー通信層２０は、第１のＤＬＴネットワーク２４０および／または第２のＤＬＴネットワーク２５０間の通信を処理するためにオーバーレジャーＳＤＫで定義された方法に従って動作してもよい。アプリケーション開発者２２０は、ＢＰＩを開発して、１つ以上のブロックで実行されるブロックチェーン動作に関連するブロックチェーン要求の中でアプリケーション２３０のアプリケーション機能層３０がオーバーレジャー通信層２０に渡し得る特定の種類の情報、および／またはオーバーレジャー通信層２０から受信し得る特定の種類の情報を定義してもよい。例えば、「第１のＤＬＴ１２への書き込み」コマンドを提供してもよく、これは、第１のＤＬＴ１２に書き込むデータの任意の関連パラメータ（最大長、オブジェクトタイプなど）を指定してもよく、および／または「第２のＤＬＴ１４からの読み取り」コマンドを提供してもよく、これは、第２のＤＬＴ１４から情報を読み取るために必要な任意の関連データを指定してもよい（例えば、特定のエンティティによって第２のＤＬＴ１４に書き込まれた第２のＤＬＴ１４のデータを読み取りたい場合、「第２のＤＬＴ１４からの読み取り」コマンドは、公開鍵など、特定のエンティティのブロックチェーン識別子が必要であることを指定してもよく、これを使用して、オーバーレジャー通信層２０がそのブロックチェーン識別子を含むトランザクションについて第２のＤＬＴ１４の内容を検索してもよい）。その結果、オーバーレジャー通信層２０が、オーバーレジャーＳＤＫによってサポートされているＤＬＴのいず
れかとインターフェースできるように、アプリケーション２３０のアプリケーション機能層３０は、ＢＰＩによって提供される様々なコマンドを利用し得ることがわかる。

【0078】

したがって、アプリケーション２３０のアプリケーション機能層３０は、オーバーレジャーＳＤＫに従って動作するオーバーレジャー通信層２０によって、第１のＤＬＴ１２および第２のＤＬＴ１４の特定のＤＬＴ層１０プロトコル要件から切り離される。アプリケーション機能層３０は、第１のＤＬＴ１２および／または第２のＤＬＴ１４と相互作用するために、ＢＰＩによって定義された方法でオーバーレジャー通信層２０にデータを送受信するだけでよい。その結果、第１のＤＬＴ１２または第２のＤＬＴ１４のいずれかで将来的にそのプロトコルが変更される場合、これはオーバーレジャーＳＤＫへの変更によりオーバーレジャー通信層２０によって処理され得る。アプリケーション２３０のアプリケーション機能層３０は、ＢＰＩで定義されているようにオーバーレジャー通信層２０とデータを送受信するため、不変のままであり得るか、またはＤＬＴプロトコル変更によりＢＰＩを何らかの方法で変更しなければならない場合にせいぜい最小限変更される（例えば、ＤＬＴに書き込むことができるオブジェクトタイプが変更される場合、ＢＰＩも変更される可能性があり、それにより、異なるオブジェクトタイプのデータを提供することがアプリケーション機能層３０に要求される可能性がある）。それにもかかわらず、アプリケーション機能層３０に変更が必要な場合であっても、それは最小限の変更であり、アプリケーション機能層３０の基本的な態様は不変のままであり得ることは明らかである。

【0079】

同様に、アプリケーション開発者２２０が、別のＤＬＴの使用を開始するように決定を下した場合（例えば、最初に選択されたＤＬＴが今では不安定であるか、セキュリティの欠陥があるため、あるいは速度および／または効率が向上した新しいＤＬＴが発売されたため）、同様のことが見られる。その異なるＤＬＴがオーバーレジャーＳＤＫによってサポートされる場合、アプリケーション開発者２２０は、ＢＰＩを単に更新して、その異なるＤＬＴと相互作用するためのコマンドを提供してもよく、その後アプリケーション２３０のアプリケーション機能層３０はその異なるＤＬＴを利用することができる。この場合も、アプリケーション機能層３０は、１つの特定のＤＬＴおよびそのＤＬＴが必要とする特定のプロトコルと相互作用するように開発されておらず、代わりに、アプリケーションの機能要件を実行し、何らかの形のブロックチェーンの相互作用が必要なときはいつでもＢＰＩを利用するように開発されているため、アプリケーション２３０のアプリケーション機能層３０に必要な変更は最小限のみであるか皆無であり得ることがわかる。

【0080】

オーバーレジャー通信層２０を使用してアプリケーション機能層３０をＤＬＴ層１０から分離することの利点は、アプリケーション開発者２２０が他の「クライアント」アプリケーション開発者が利用するサービスオファリングを開発するシナリオを考慮することによってさらに理解され得る。サービスオファリングは、例えば、特定の種類の情報をブロックチェーンに書き込むことを可能にするサービス（これについては「メッセージングの態様」のセクションで詳しく説明する）および／またはクロスレジャートランザクションを可能にするサービス（これについては「クロスレジャートランザクションの態様」のセクションで詳しく説明する）および／またはＤＬＴから特定の種類の情報を読み取ることを可能にするサービスなど、他のアプリケーション開発者が利用したい可能性がある、あらゆる種類のブロックチェーンサービスに関連し得る。

【0081】

図３は、「クライアント」アプリケーション開発者によって利用され得るサービスオファリングを実証するための例示的なシステム３００を示す。システム３００は、ＳＤＫプロバイダ２１０（前述）、サービスオファリング開発者３１０、クライアントアプリケーション開発者３２０、クライアントアプリケーション３３０、第１のＤＬＴネットワーク２４０（前述）、および第２のＤＬＴネットワーク２５０（前述）を含む。

【0082】

図４は、サービスオファリング開発者がオーバーレジャーＳＤＫをどのように利用し得るかを例示する方法ステップの例を示す。

【0083】

ステップＳ４１０において、サービスオファリング開発者３１０は、ＳＤＫプロバイダ２１０からオーバーレジャーＳＤＫを取得し得る（例えば、ＳＤＫプロバイダ２１０からダウンロードするか、または任意の他のオーバーレジャーＳＤＫホスティングエンティティからダウンロードすることによる）。

【0084】

ステップＳ４２０において、サービスオファリング開発者３１０は、提供しているサービスのＢＰＩを開発し、それを適切にカプセル化し得る（例えばＢＰＩ構成ファイルにカプセル化されるが、代わりに任意の他の適切な代替が使用されてもよい）。ＢＰＩは、先に説明したように、１つ以上のＤＬＴと相互作用するためにクライアントアプリケーション３３０のアプリケーション機能層３０によって使用され得る機能、コマンドなどを指定する。

【0085】

ステップＳ４３０において、クライアントアプリケーション開発者３２０は、オーバーレジャーＳＤＫおよびＢＰＩ構成ファイルを取得し得る（例えば、サービスオファリング開発者３１０からダウンロードするか、または任意の他の適切なホスティングエンティティからダウンロードすることによる）。

【0086】

ステップＳ４４０において、クライアントアプリケーション開発者３２０は、クライアントアプリケーション３３０のアプリケーション機能層３０を開発する。アプリケーション機能層３０が何らかの方法でＤＬＴと相互作用する必要がある場合、アプリケーション機能層３０は単にブロックチェーン要求をオーバーレジャー通信層２０に通信するためにＢＰＩのコマンドまたは機能を適切に利用すればよく、ブロックチェーン要求は、１つ以上のブロックチェーンで実行されるブロックチェーン動作に関する。したがって、サービスオファリング開発者３１０によって提供されるオーバーレジャーＳＤＫおよびＢＰＩは、アプリケーション機能層３０をＤＬＴ層１０から切り離すことがわかる。したがって、オーバーレジャーＳＤＫはオーバーレジャー通信層２０の機能を実行すると見なしてもよく、ＢＰＩは、サービスオファリング開発者によって提供される特定のサービスを実行するためにアプリケーション機能層３０がオーバーレジャー通信層２０とどのようにインターフェースし得るかを定義すると見なしてもよい。

【0087】

結果として、クライアントアプリケーション開発者３２０が後日、クライアントアプリケーション３２０に使用するＤＬＴを変更したいと決定した場合（例えば、最初にクライアントアプリケーション３３０の機能アプリケーション層３０は、ＢＰＩの機能およびコマンドを使用して第１のＤＬＴ２２と相互作用するように構成されている場合があるが、第２のＤＬＴ２４を代わりに使用すべきであると後に決定される）、機能アプリケーション層２０が使用する特定のＢＰＩの機能およびコマンドを変更する必要があるのみである（オーバーレジャーＳＤＫおよびＢＰＩが、第１のＤＬＴ２２および第２のＤＬＴ２４の両方をサポートすると想定）。同様に、オーバーレジャーＳＤＫによってサポートされている任意のＤＬＴのプロトコルについて何かが変更された場合、オーバーレジャーＳＤＫが変更される可能性があり、サービスオファリング開発者３１０は結果として必要に応じてＢＰＩを変更し得る。その結果、多くの場合、クライアントアプリケーション開発者は、クライアントアプリケーション３３０の機能アプリケーション層３０が使用する特定のＢＰＩの機能およびコマンドを変更するだけでよく、クライアントアプリケーションの機能アプリケーション層３０の基本的な態様はいずれも変更する必要がない。

【0088】

オプションで、クライアントアプリケーション開発者３２０が、取得したＢＰＩ構成ファイルが有効であることを確認し得るように、サービスオファリング開発者３１０は、Ｂ
ＰＩ構成ファイルを作成した後に標準の公開秘密鍵暗号化技術を使用してそれに署名してもよい。

【0089】

オーバーレジャーＳＤＫは、特定の種類のＤＬＴ相互作用の実行を可能にする多くの異なる機能を含み得る。これらの特定の機能の２つである「メッセージングの態様」と「クロスレジャートランザクション」の態様について、以下で詳しく説明する。

【0090】

アプリケーション機能層３０およびオーバーレジャー通信層２０は両方とも「層」として上記で説明されているが、それらは代替的にソフトウェアモジュールまたはパッケージと見なしてもよいことが理解されよう。例えば、それらは、アプリケーション２３０またはクライアントアプリケーション３３０内の２つのモジュールであり得る。あるいは、それらは各々異なるアプリケーション内に配置され、異なる電子デバイスで動作する可能性がある。例えば、アプリケーション機能層３０は、クライアント電子デバイス上で動作するソフトウェアモジュールまたはパッケージであり得て、オーバーレジャー通信層２０は、サービスオファリング電子デバイス上で動作する異なるソフトウェアモジュールまたはパッケージであり得て、この２つの層は、任意の適切な通信インターフェースを介してＢＰＩに従って通信する。さらに、オーバーレジャー通信層２０は、特定のブロックチェーン動作を任意の１つ以上の異なるＤＬＴで実行できるように構成されたソフトウェアモジュールまたはパッケージと見なしてもよく、サービスオファリング開発者３１０は、クライアントアプリケーション開発者がオーバーレジャー通信層２０をダウンロードし、ＢＰＩを介してそれを利用するか、ＢＰＩを介してリモートで利用することを可能にする。

【0091】

メッセージングの態様
ブロックチェーンが保存するように必ずしも設計されていない情報の不変の記録をブロックチェーン上に維持することがしばしば有用であり得ることが発明者らによって認識された。以下の全体を通して、「メッセージ」という用語が使用されているが、「メッセージ」には、ブロックチェーンを使用して記録を保持したいあらゆる種類の情報が包含されることを理解すべきである。

【0092】

ブロックチェーンを使用してメッセージの記録を保持することにより、メッセージの内容を将来検証できるように、メッセージの事実上不変の記録を保持することができる。ブロックチェーンは、各ブロックに含まれるトランザクション内のいくつかの種類の情報を承認するように装備されているが、通常、その情報が何であるかについて非常に規範的である。例えば、人気のある多くのブロックチェーン（ビットコインなど）は元来、暗号通貨と単純な金融送金のために設計された。他のブロックチェーンは他の特定の目的のために開発されており、将来さらに多くのブロックチェーンがさらなる特定の目的のために開発される可能性がある。オーバーレジャー通信層２０を開発する過程で、本発明者らは、その目的のために設計されなかったブロックチェーン上のいくつかの種類の情報を保存できることが非常に有用であり得ることに気付いた。具体的な使用例の１つは、後で説明するように、１つ以上のブロックチェーン上に現れるトランザクションの順序の記録を維持する一環としてであるが、他にも多くの潜在的な用途と利点がある。

【0093】

その目的のために設計されなかったブロックチェーンにメッセージを保存することの潜在的な利点に気付いたため、本発明者らは既存のブロックチェーンアーキテクチャ内のトランザクションの詳細を調査した。多くのブロックチェーンアーキテクチャにはトランザクション内のフィールドが含まれており、その中に必須ではないデータを追加できることに気付いた。例えば、ビットコインにはＯＰ－ＲＥＴＵＲＮフィールドがあり、イーサリアムにはスクリプトバイトコードに使用されるフィールドがあり、リップルには「メモ」フィールドがある。これらのフィールドは、一般に「非必須データフィールド」と呼ばれることがある。ただし、これらの各フィールドのサイズ、したがって有用性は、比較的限
定されている。

【0094】

本発明者らによって特定された解決策は、そのようなフィールドを使用して、あるメッセージ（ハッシュまたはメッセージの暗号化など）に少なくとも部分的に基づき、かつそれを一意に示す値を保存し、次にそのメッセージを別の場所（オフチェーン）に保存することである。メッセージを一意に示す値は、オフチェーンに保存されている完全なメッセージへのポインタ（例えば、ハッシュポインタ）として機能し得る。メッセージを一意に示す値をブロックチェーンに保存することにより、オフチェーンに保存されたメッセージに基づいてテスト値を生成し、それをブロックチェーンに保存された値に対して確認するだけで、メッセージの整合性はいつでも確認され得る。テスト値はブロックチェーンに保存された値と同じ方法で生成されているため（例えば、同じハッシュレシピを使用して）、テスト値がブロックチェーンに保存された値と一致する場合、オフチェーンに保存されたメッセージには整合性がある（すなわち、改変されていない）。それらが一致しない場合には、オフチェーンに保存されたメッセージは何らかの方法で改ざんされている。これは、ブロックチェーンの内容が事実上不変であるため、ブロックチェーンに保存されている値はどのようにしても改変することができないためである。

【0095】

当業者は、メッセージを一意に示す値が、任意の適切な方法で生成され得ることを理解するであろう。例えば、この値は、ＳＨＡ－２（例えば、ＳＨＡ－２５６、ＳＨＡ－５１２など）またはＳＨＡ－３などのハッシュアルゴリズムを使用してメッセージの内容をハッシュすることにより生成され得て、メッセージを一意に示す値はハッシュであり、ブロックチェーン内でハッシュポインタとして機能する。あるいは、値は、任意の適切な暗号化アルゴリズムを使用してメッセージの内容を暗号化することによって生成され得る。メッセージを一意に示す値が生成され得る特定の方法は、メッセージが保存される特定のブロックチェーンの要件、および／または満たす必要がある特定の暗号要件（例えば、アルゴリズムによって提供される整合性のレベルなど）に基づいて選択され得る。例えば、値が保存されるトランザクションフィールドは、特定の最大長を有する場合があり、特定のハッシュアルゴリズムは、生成されるハッシュが長すぎる可能性があるために除外される。オーバーレジャーＳＤＫは、それがサポートするＤＬＴに適した特定のハッシュアルゴリズムおよび／または暗号化アルゴリズムを含み得て、これにより、アプリケーション機能層はオーバーレジャー通信層２０にメッセージを渡すだけでよく、次に、オーバーレジャー通信層２０は、ＤＬＴにメッセージの記録を保存するためにメッセージを適切に処理してもよい。次に、アプリケーションはメッセージのコピーをオフチェーンの別の場所（例えば、アプリケーションが動作しているデバイスのローカルメモリ、またはリモートデータベースやクラウドストレージなどのリモートメモリ）に保存してもよい。

【0096】

前述のように、上記のメッセージングの態様には多くの潜在的な用途があり得る。特定の非限定的な使用例の１つを、図５を参照して以下で説明する。

【0097】

図５は、サービスオファリング開発者３１０と、クライアントアプリケーション開発者３２０と、クライアントアプリケーションバックエンド５１０と、第１のクライアントアプリケーション５２０と、第２のクライアントアプリケーション５３０と、第１のＤＬＴネットワーク２４０とを含むシステム５００を示す。サービスオファリング開発者３１０は、上述のメッセージングの態様を使用して１つ以上のＤＬＴにメッセージを記録するためのＢＰＩ機能を提供するメッセージングサービス用のＢＰＩを作成することができる。次に、クライアントアプリケーション開発者３２０は、オーバーレジャーＳＤＫおよびサービスオファリング開発者３１０のＢＰＩ構成ファイルを使用して、メッセージングアプリケーションのユーザが互いに安全にメッセージを送信できるようにするメッセージングアプリケーションを開発することができる。第１のクライアントアプリケーション５２０および第２のクライアントアプリケーション５３０は、第１および第２のユーザの電子デ
バイス、例えばモバイル電子デバイス（スマートフォン、またはタブレットコンピュータ、またはラップトップコンピュータなど）またはデスクトップコンピュータ上でそれぞれ動作するクライアントアプリケーションを複製することができる。第１のクライアントアプリケーション５２０および第２のクライアントアプリケーション５３０は、第１および第２のユーザの電子デバイス上で、デバイス上のソフトウェアインストールとして、またはウェブブラウザベースのアプリケーションなどとして動作し得る。

【0098】

第１のユーザが第２のユーザにメッセージを伝えたい場合、メッセージと第２のユーザのＩＤ（ＩＤは、例えばクライアントアプリケーションの第２のユーザのユーザ名など、任意の適切な形式を取り得る）を第１のクライアントアプリケーション５２０に入力してもよい。クライアントアプリケーションの機能アプリケーション層３０は、サービスオファリング開発者３１０が作成したＢＰＩの適切な機能／コマンドを使用して、第１のＤＬＴ１２に追加するために、第１のクライアントアプリケーション５２０のオーバーレジャー通信層２０にメッセージを渡すように構成され得る。次に、オーバーレジャー通信層２０は、第１のＤＬＴ１２と相互作用するためのＳＤＫの方法に従ってメッセージをハッシュし、メッセージのハッシュを含む第１のＤＬＴ１２のための適切なトランザクションを構築し、トランザクションを第１のＤＬＴネットワーク２４０に通信してもよい。したがって、メッセージのハッシュは第１のＤＬＴ１２に含まれる。また、第１のクライアントアプリケーション５２０のオーバーレジャー通信層２０は、オプションで、トランザクションが第１のＤＬＴ１２に首尾よく追加されたと判定したときに、アプリケーション機能層３０に通知を返すように構成されてもよい。メッセージ全体のコピーとメッセージのハッシュはまた、例えば、アプリケーション機能層３０がオーバーレジャー通信層２０からメッセージのハッシュを受信し、それをメッセージと共にクライアントアプリケーションバックエンド５１０に通信することにより、クライアントアプリケーションバックエンド５１０（これは例えば、メッセージを受信、保存および検索するためにクライアントアプリケーション開発者３２０が提供するサーバ、データベース、またはクラウドベースのストレージシステムなどであり得る）に通信されてもよい。第１のクライアントアプリケーション５２０とクライアントアプリケーションバックエンド５１０との間の通信は、オプションで、任意の適切な暗号化技術を使用して保護されてもよい。

【0099】

次に、第２のユーザは、メッセージが待機していることに気付き得る。これが発生し得る多くの異なる方法が存在し、例えば、第２のユーザ識別子は、第２のユーザのＤＬＴ公開鍵またはＤＬＴウォレットであり得るか、または第２のユーザのＤＬＴ公開鍵またはＤＬＴウォレットを取得するために第１のクライアントアプリケーション５２０によって使用されていてもよく、ＤＬＴ１２上のトランザクションは、第２のユーザの公開鍵またはＤＬＴウォレットをトランザクションの受信者として識別してもよい。この場合、第２のクライアントアプリケーション５３０は、第１のＤＬＴ１２における新しいトランザクションで第２のユーザが識別されることに気付いてもよい（第２のクライアントアプリケーション５３０が、第１のＤＬＴ１２に追加される新しい各ブロックの内容を監視して、第２のユーザのＤＬＴ公開鍵またはＤＬＴウォレットを識別する任意の新しいトランザクションを探すように構成されている場合）。あるいは、サードパーティのサービスがこの監視プロセスを実行して、第２のクライアントアプリケーション５３０に通知してもよい。次に、第２のクライアントアプリケーション５３０のアプリケーション機能層３０は、適切なＢＰＩ「読み取り」機能を使用して、第１のＤＬＴ１２からメッセージのハッシュを取得することができる。

【0100】

第２のクライアントアプリケーション５３０がメッセージハッシュのコピーを有すると、アプリケーション機能層３０は、クライアントアプリケーションバックエンド５１０に対して第２のユーザを認証するために、何らかの形式の認証と共にそれをクライアントアプリケーションバックエンド５１０に通信してもよい（例えば、これは、第２のクライア
ントアプリケーション５３０およびクライアントアプリケーションバックエンド５１０が確立した認証プロセスの任意の形式を使用するか、または第２のユーザのＤＬＴ秘密鍵によって署名されたデジタル署名を提供することにより、クライアントアプリケーションバックエンド５１０は、第１のＤＬＴ２４０に保存されたメッセージハッシュに関連付けられた公開鍵を使用して確認することができる）。認証が渡された場合、メッセージハッシュに対応する完全なメッセージが第２のクライアントアプリケーション５３０に返されてもよい。次に、第２のクライアントアプリケーション５３０は、第１のクライアントアプリケーション５２０で使用されたものと同じハッシュアルゴリズムを介してそれを渡すことによって、返却されたメッセージの整合性を検証して（例えば、適切な「チェックメッセージ」ＢＰＩ機能を使用するか、またはサービスオファリングプロバイダ３１０および／またはクライアントアプリケーション開発者３２０が適合すると見なす任意の他の方法で）、テストハッシュを作成し、次にそのテストハッシュを、第１のＤＬＴ１２から取得したメッセージハッシュと比較してもよい。

【0101】

この特定のプロセス例の多くの利点は直ちに明らかであろう。まず、暗号化された電子メールや、２人のユーザ間でパスワードの合意を必要とするパスワードで保護されたドキュメントなど、複雑で確実に実行するのが難しいことが多い技術を行う必要がなく、メッセージの内容が第１のユーザから第２のユーザに安全に渡る可能性がある。さらに、第２のユーザ５３０は、さもなければテストハッシュが第１のＤＬＴ１２に保存されたメッセージハッシュと一致しないため、クライアントアプリケーションバックエンド５１０が何らかの方法でメッセージを改ざんしていないことを確信することができる。さらに、将来の任意の時点で、メッセージの内容に関して第１のユーザと第２のユーザとの間に何らかの形の紛争がある場合、第１のＤＬＴ１２に保存されたメッセージハッシュを使用して、紛争を完全に解決することができる。

【0102】

第２のユーザは同様に、類似の方法でメッセージに返信してもよい。

【0103】

これは、本開示のメッセージングの態様の単なる１つの特定の使用例であり、多くの他のものが可能であり得ることが理解されよう。さらに、上記の特定の使用例の多くの代替的な実装が可能である。例えば、アプリケーションバックエンドは代替的にサービスオファリング開発者３１０によって提供されてもよく、ＢＰＩは単にメッセージを受信するように構成されてもよく、オーバーレジャーコミュテーション層２０は、メッセージハッシュを第１のＤＬＴ１２に置くこと、またアプリケーションバックエンド５１０にメッセージおよびメッセージハッシュを通信することを処理してもよい。この場合、クライアントアプリケーションのアプリケーション機能層３０は、ＧＵＩおよびクライアントアプリケーションによって提供される他の機能など、他の機能のみに関係し得る。さらに、アプリケーション機能層３０は、ＢＰＩによって提供される機能またはコマンドを利用して、１つだけでなく多くのＤＬＴにメッセージハッシュを置いてもよく、それによって、メッセージハッシュのさらなる冗長性およびバックアップを提供する。

【0104】

トランザクションの順序付けの態様
信頼できるブロックチェーン動作の重要な要件は、トランザクションの順序付けである。例えば、二重使用の暗号通貨詐欺を防止するために、新しいトランザクションがブロックチェーンネットワークにブロードキャストされるときに、その新しいトランザクションで識別された暗号通貨が以前に使われたかどうかを判定することが可能でなければならず、新しいトランザクションが以前に使われていない場合にのみ新しいトランザクションを新しいブロックに含める（すなわち、二重の使用を防ぐ）ことが従来認識されている。多くの既存のブロックチェーンは、ブロックチェーン上のブロックの年代順の性質のおかげでこれを達成し、各ブロックにはタイムスタンプが含まれ、新しいトランザクションで識別された暗号通貨がまだ使われていないことを既存のブロックの中で確認する。

【0105】

しかしながら、本発明者らは、トランザクションの信頼できる順序付けが、暗号通貨ブロックチェーンだけでなく、より一般的には全ての種類のブロックチェーンにとって重要であり得ることを認識した。例えば、様々なインターネットおよび電気通信分野およびプロトコルにおいて、誤って順序付けられたメッセージングがセキュリティおよび安定性の弱点として悪用され得ることが理解されよう。例えば、ＴＣＰ／ＩＰパケットの順序と同期がシステムのセキュリティに影響を与え得る方法は数多くあり、例えば、メッセージが正しい順序から外れたり、メッセージセットが不完全であったりすると、整合性または可用性のいずれかの点でシステムのセキュリティが低下する。そのため、本発明者らは、ブロックチェーン内でトランザクションの正しい順序を維持することが、例えば、上記のメッセージングの態様に従ってメッセージを運ぶために使用する場合だけでなく任意の他の目的で使用する場合に、１つ以上のＤＬＴを利用する安全、確実かつ不正に強いシステムを獲得する上で非常に重要であり得ると認識した。

【0106】

ＤＬＴで正しいトランザクション順序を維持する上での２つの特定の課題が本発明者らによって特定されている。

【0107】

１．ブロックチェーンが分岐する場合、フォークの短い方のプロングに現れた１つ以上のトランザクションがブロックチェーンから失われる可能性がある。当業者は、ＤＬＴが分岐する可能性、およびその場合のＤＬＴの挙動の特徴を容易に理解するであろう。ただし、伝統的に、フォークによってトランザクションが失われた場合、そのトランザクションは、トランザクションが失われたと認識された場合に、参加しているノードのネットワークによってフォークのより長いプロングに後で追加される可能性があることに注意されたい。

【0108】

図６は、ブロックチェーン内のフォークの例示的な表現を示している。トランザクション１は、ブロックチェーンの「プロング１」に現れているブロックＢ１の一部である。ただし、フォークの結果、ブロックチェーンがより長いプロングである「プロング２」で続いているため、トランザクション１はブロックチェーンから事実上失われている。トランザクション２はブロックＢ３の一部であり、「プロング２」に現れている。しばらくすると、トランザクション１は、「プロング２」のブロックＢ８の一部としてブロックチェーンに追加される。したがって、トランザクション１は、ブロックチェーンにおいてトランザクション２よりも後に現れる。しかし、トランザクション１がトランザクション２に先行することが重要である場合（例えば、それらが連続したメッセージに関連している場合）、これはセキュリティまたは安定性の欠陥を引き起こす可能性があるか、あるいはブロックチェーンを利用しているアプリケーションにおいて不正の発生を可能にし得る。

【0109】

２．前に説明したように、いくつかのシナリオでは、１つのアプリケーションが２つ以上の異なるＤＬＴを利用することが望ましい場合がある。この一部として、あるＤＬＴから別のＤＬＴへデータ（例えば、メッセージ（前述）、または暗号通貨の一部、またはＤＬＴに保存されている他の種類の別の情報）を移動するために、クロスレジャートランザクション（ＸＬＴ）を実行することが場合によっては必要であり得る。しかし、各ブロックチェーンは、そのブロックチェーン上の異なるブロック間の順序を維持するように開発されている場合があり（例えば、タイムスタンプを使用して）、各ＤＬＴが異なるタイムスタンプ手順を利用している可能性があるため、および／またはタイムスタンプに使用されるクロックが同期していない可能性があるため、異なるブロックチェーンに現れるトランザクション間で順序を確実に識別することは非常に難しい場合がある。したがって、２つ以上（複数）のＤＬＴを利用する場合、ＤＬＴ上に現れるトランザクションの順序を決定および維持することは、ＤＬＴを使用しているアプリケーションのセキュリティと安定性にとって非常に重要であり得る。

【0110】

図７は、「検証セット」を使用してトランザクションの順序を維持するために本発明者らによって開発されたプロセスの例示的な方法ステップを示す。図８は、図７の方法ステップを理解するのに役立つ２つのＤＬＴと検証セットの視覚化の例を示す。

【0111】

ステップ７１０において、第１のＤＬＴ１２および第２のＤＬＴ１４は、対象の新しいトランザクションが第１のＤＬＴ１２または第２のＤＬＴ１４に追加されたブロックに含まれるときを識別するために監視される。第１のＤＬＴ１２および第２のＤＬＴ１４は、それがＤＬＴに追加されるときに各新しいブロックの内容を読み取ることによって監視され得る。対象のトランザクションを構成するものの関連性基準は、この方法の特定の実装の問題である。例えば、上記で開示したＢＰＩは、ＢＰＩを利用してＤＬＴに置かれている任意のトランザクションが、任意の他の手段によって（例えば、そのＢＰＩを利用していない他のエンティティによって）ＤＬＴに置かれたトランザクションとそれを区別する特定の識別子を含むように構成され得る。特定の識別子は、例えば、トランザクションに使用される公開鍵、またはトランザクション内の何らかの他の種類の情報であり得る。その結果、関連性基準は、サービスオファリング開発者３１０によって提供されるサービスを使用している第１のＤＬＴ１２または第２のＤＬＴ１４に含まれる任意のトランザクション（例えば、第１のクライアントアプリケーション５２０または第２のクライアントアプリケーション５３０によって追加されるか、さらに言えば、必要に応じてＤＬＴにトランザクションを置くためにサービスオファリング開発者が操作する何らかのサービスアプリケーションによって追加されるトランザクション）が関連性基準を満たし、かつ関連性があると識別され得るように、ＢＰＩによって含まれる識別子であり得る。これは、第１のＤＬＴ１２および／または第２のＤＬＴ１４が、多くの異なるエンティティに利用され得る汎用ＤＬＴである場合に特に有用であり得るが、サービスオファリング開発者３１０は、トランザクションの適切な順序を保証して、サービスオファリングのセキュリティと安定性を保護するために、そのサービスに関連するトランザクションを識別する必要がある。

【0112】

図８において、トランザクションＡ、Ｃ、Ｅ、Ｏは全て対象のトランザクションである。「トランザクションＸ」というラベルの付いたトランザクションは対象外である。

【0113】

新しいブロックが第１のＤＬＴ１２または第２のＤＬＴ１４のいずれかに追加され、ステップ７１０で関連するトランザクションを含むことが識別されると、ステップＳ７２０において、トランザクションの内容に少なくとも部分的に基づいて識別された各々についてトランザクション識別子（例えば、ハッシュ）が決定され得る。次に、この識別子が直近または「進行中」の検証セットに追加される。検証セットは、任意の適切なメモリ、データベース、データアレイ、クラウドストレージなどのデータストアに保存されている関連するトランザクションのオフチェーン記録の一部である。トランザクション識別子は、ＤＬＴ内の関連するトランザクションへのポインタ（例えば、ハッシュポインタ）として機能し得る。新しい各トランザクションＩＤは、検出された順に「進行中」の検証セットに追加される。したがって、識別されたトランザクションの記録は、トランザクションが第１のＤＬＴ１２に現れたか、第２のＤＬＴ１４に現れたかに関係なく、トランザクションの相対順序を示す。その結果、両方のＤＬＴを監視し、第１のＤＬＴ１２または第２のＤＬＴ１４に追加されるとすぐに関連する各トランザクションのトランザクション識別子を追加することにより、トランザクションの相対順序が１つ以上の異なるＤＬＴをまたがって記録され得ることがわかる。当業者は、「進行中」の検証セットが、関連するトランザクションの順序を維持する任意の適切なデータストレージ技術を使用して保存され得ることを認識するであろう。新しい関連するトランザクションが「進行中」の検証セットに追加されると、プロセスはステップＳ７１０に戻り、第１のＤＬＴ１２および第２のＤＬＴ１４の監視を続けてもよい。

【0114】

特定の時間に、プロセスはステップＳ７３０に進み、「進行中」の検証セット（例えば、「進行中」の検証セットの内容に少なくとも部分的に基づくハッシュまたは暗号化）の記録（検証セット識別子など）を第１のＤＬＴ１２および第２のＤＬＴ１４に保存するプロセスを開始してもよい。プロセスがステップＳ７３０に進む特定の時間は実装の問題であり、例えば、直近の以前の検証セットの記録がＤＬＴに追加されてから特定の時間がＤＬＴの監視に費やされた後、または「進行中」の検証セットに特定の数の関連するトランザクションが追加された後、または直近の以前の検証セットの記録がＤＬＴに追加されてから特定の数のブロックが第１のＤＬＴ１２または第２のＤＬＴ１４に追加された後などであってもよい。

【0115】

ステップＳ７３０において、直近の先行する検証セットの内容の記録（例えば、ハッシュまたは暗号化）が第１のＤＬＴ１２および第２のＤＬＴ１４の両方に存在するか否かが判定される（例えば、どちらのＤＬＴにもその記録が失われる原因となるフォークがないことを確認するため）。記録が両方のＤＬＴに現れている場合（図７の「Ｙｅｓ」）、プロセスはステップＳ７５０に進む。記録が両方のＤＬＴに現れていない場合（図７の「Ｎｏ」）、プロセスはステップＳ７４０に進む。この確認は、両方のＤＬＴで直前の検証セットの記録を検索することにより実行され得る。

【0116】

ステップＳ７４０において、欠落している記録は、それが欠落しているＤＬＴ上で再度行われ得る（本質的には、記録が最初にＤＬＴ上に置かれたトランザクションが、例えば上記の「メッセージングの態様」を使用して、再度ブロードキャストされ、ＤＬＴに追加される）。ただし、欠落している記録を再度行う前に、直前の検証セット内で識別されたトランザクションのいずれかが、それが表れているべき対応するＤＬＴから欠落しているかどうかを最初に判定してもよい。これは、トランザクションの記録に保存されている直前の検証セット内のトランザクション識別子のポインタの性質（例えば、ハッシュポインタ）を使用することにより、すばやく判定され得る。その後、任意の欠落しているトランザクションは、直前の検証セットの欠落している記録を再度行う前に、関連するＤＬＴ上で再度行われ得る。任意の再度行われたトランザクションはここで、欠落していたトランザクションが先行していた（欠落していなかった場合の）トランザクションよりも後のＤＬＴに現れる可能性があるが、検証セットはトランザクションの正しい順序の適切な記録を依然として維持しているであろう。結果として、欠落している検証セットの記録、およびそれらに関連付けられている任意の欠落しているトランザクションは、トランザクションが発生した適切な順序を失うことなく、ＤＬＴに再び追加され得る。このステップの詳細は、以下の図８および図９の説明からさらに完全に理解され得る。

【0117】

ステップＳ７５０において、「進行中」の検証セットで識別された全てのトランザクションが関連するＤＬＴに依然として現れているどうかが判定される（例えば、ＤＬＴの一方または両方のフォークによって失われたものがないことを確認する）。それらが関連するＤＬＴに全て依然として現れている場合（図７の「Ｙｅｓ」）、プロセスはステップＳ７７０に進む。それらが関連するＤＬＴに全て現れていない場合（図７の「Ｎｏ」）、プロセスはステップＳ７６０に進む。この確認は、「進行中」の検証セット内の遷移識別子のポインタの性質によって実行され得る。

【0118】

ステップＳ７６０において、現在欠落していると識別されたトランザクションは、それが現れるべきであった対応するＤＬＴ上で再度行われ得る（本質的に、再度ブロードキャストされ、ＤＬＴに追加される）。任意の再度行われたトランザクションはここで、欠落していたトランザクションが先行していた（欠落していなかった場合の）トランザクションよりも後のＤＬＴに現れる可能性があるが、「進行中」の検証セットはトランザクションの正しい順序の適切な記録を依然として維持しているであろう。結果として、欠落した
トランザクションは、トランザクションが発生した適切な順序を失うことなく、ＤＬＴに再び追加され得る。

【0119】

ステップＳ７７０において、「進行中」の検証セットの内容に少なくとも部分的に基づいて「進行中」の検証セットの記録が決定され（例えば、検証セットの内容に少なくとも部分的に基づくハッシュまたは暗号化などの検証セット識別子の決定）、第１のＤＬＴ１２および第２のＤＬＴ１４の両方に追加される。記録は、上記の「メッセージングの態様」で説明した手法を利用することにより両方のＤＬＴに追加され得る。結果として、上記の「メッセージングの態様」を使用することにより「進行中」の検証セットの内容の記録を両方のＤＬＴに追加でき、それにより、その検証セットの内容の効果的に不変の記録が提供され、それを使用して、関連するトランザクションの記録のデータ整合性、したがってセキュリティと信頼性の向上が実現され得ることがわかる。次に、プロセスはステップＳ７１０に戻り、ＤＬＴの監視を続け、次の「進行中」の検証セットの作業を開始し得る。

【0120】

図８に戻ると、検証セット_ｎ－１８１０、検証セット_ｎ８２０、および検証セット_ｎ＋１８３０を含む、オフチェーンのデータストア（任意の適切な種類のデータストア、データベース、クラウドストレージ、または任意の他の種類のメモリ）に保存された関連するトランザクションの記録８４０を見ることができる。検証セット_ｎ－１８１０は、トランザクションＹのハッシュとトランザクションＺのハッシュとを含み、これらは、第１のＤＬＴ１２または第２のＤＬＴ１４上の以前のトランザクションであり、単純化のために図８では別段示されていない。検証セット_ｎ８２０は、トランザクションＡのハッシュ８２２’と、トランザクションＯのハッシュ８２４’と、トランザクションＣのハッシュ８２６’とを含む。トランザクションＡ８２２およびトランザクションＣ８２６は、第１のＤＬＴ１２に現れ、トランザクションＯ８２４は第２のＤＬＴ１４に現れる。それらが検証セット_ｎ８２０に現れる順序は、トランザクションＯ８２４が、トランザクションＡ８２２の後に検出されたが、トランザクションＣ８２６の前に検出されたことを示す。検証セット_ｎ＋１８３０はトランザクションＥのハッシュ８３２’を含み、この例では「進行中」の検証セットと見なすことができる。

【0121】

見てわかるように、検証セット_ｎ－１８１０’のハッシュおよび検証セット_ｎ８２０’のハッシュは両方とも、上記のステップＳ７７０に従って、両方のＤＬＴに以前に追加されている。検証セット_ｎ８２０が「進行中」の検証セットであった場合、それが上記のステップＳ７３０に来ると、検証セット_ｎ－１８１０’のハッシュが両方のＤＬＴに存在するため、プロセスはステップＳ７５０に直接進むことができると理解される。同様に、それがステップＳ７５０に来ると、トランザクションＡ８２２、トランザクションＯ８２４およびトランザクションＣ８２６は全て関連するＤＬＴにまだ現れているため、プロセスはステップＳ７７０に直接進み、両方のＤＬＴに検証セット_ｎ８２０’のハッシュが追加され得る。

【0122】

このプロセスの結果として、２つのブロックチェーンに現れるトランザクションの順序のオフチェーン記録が、トランザクションの記録８４０内の検証セットによって保持されることがわかるであろう。オフチェーン記録は、それらが関連するトランザクションの相対順序を示す。上記の「メッセージングの態様」も使用して各検証セットのハッシュポインタを両方のＤＬＴに保存することにより、各検証セットの記録がＤＬＴに保持され得て、これは検証セットのオフチェーン記録のデータの整合性およびセキュリティを維持する上で、また以下で説明するように第１のＤＬＴ１２および／または第２のＤＬＴ１４でフォークが発生した場合に特に役立ち得る。

【0123】

図９は、図７の方法ステップ、特にステップＳ７３０～Ｓ７６０の理解を助けるための
２つのＤＬＴおよび検証セットのさらなる例示的な視覚化を示す。図９は図８に類似しているが、図９には第１のＤＬＴ１２のフォークの表現が含まれており、これにより２つのトランザクションおよび検証セットの１つの記録が第１のＤＬＴ１２から失われている。

【0124】

図９では、トランザクションＣ８２６を含める前に、第１のＤＬＴ１２がフォークする。トランザクションＣ８２６、検証セット_ｎのハッシュ８２０’、およびトランザクションＥ８３２は全て、フォークの「プロング１」に現れている。ただし、この例では、ＤＬＴ１２として前進するのはフォークの「プロング２」であり、「プロング１」の内容は（少なくとも一時的に）実質的に失われる。検証セット_ｎのハッシュ８２０’をＤＬＴに追加すると、検証セット_ｎ＋１９３０で作業が開始され、これは見てわかるようにトランザクションＥのハッシュ８３２’およびトランザクションＧのハッシュ９３４’をこの順序で含む。図９で識別されるポイントＰで、図７のプロセスはステップＳ７３０に進み、その時点で、検証セット_ｎ８２０’およびトランザクションＣ８２６のハッシュが第１のＤＬＴ１２にもはや現れないことが識別される（それらは両方とも「プロング１」に現れ、これは失われたフォークのプロングであるため）。その結果、ステップＳ７４０において、トランザクションＣが再度行われ（図９では参照番号９２６で識別されているが、元のトランザクションＣ８２６と再度行われたトランザクションＣ９２６の内容は同じであることが理解されるであろう）、次に検証セット_ｎのハッシュが再度行われる（図９では参照番号９２０’で識別されているが、検証セット８２０’の元のハッシュは、再度行われた検証セット９２０’のハッシュと同じであることが理解されるであろう）。その後、ステップＳ７５０において、トランザクションＥ８３２（「進行中」の検証セット_ｎ＋１９３０で識別されている）は「プロング１」に含まれていたため、第１のＤＬＴ１２にもはや現れないことが決定される。したがって、ステップＳ７６０において、トランザクションＥが再度行われる（図９では参照番号９３２で識別されているが、元のトランザクションＥ８３２と再度行われたトランザクションＥ９３２の内容は同じであることが理解されるであろう）。その後、ステップＳ７７０において、検証セット_ｎ＋１のハッシュ９３０’が両方のＤＬＴに追加される。したがって、トランザクションＣ８２６、検証セット_ｎのハッシュ８２０’、およびトランザクションＥ８３２が第１のＤＬＴ１２から全て失われたとしても、それらはトランザクションの真の順序の信頼できる記録を失うことなくトランザクションＧ９３４（トランザクションＣ８２６およびトランザクションＥ８３２の後に最初に行われた）の後に第１のＤＬＴ１２に再び追加され、それによってシステムのセキュリティと安定性が保証され得ることがわかる。その結果、検証セットのハッシュをＤＬＴに含めることはオプションであるが（別の方法では、トランザクションのオフチェーン記録は、検証セットのいずれのハッシュもＤＬＴに保存せずに単に保持され得る）、各検証セットの記録をＤＬＴに保存することは、オフチェーン検証セットのデータの整合を可能にすることによってセキュリティと信頼性の向上を可能にするだけでなく、フォークをすばやく識別し、欠落している記録および／またはトランザクションを関連するＤＬＴに再度追加することも可能にすることが理解されよう。

【0125】

図９に示す各ブロックは単一のトランザクションのみを含むが、実際には各ブロックが多くのトランザクションを含む可能性が高いことが理解されよう。さらに、上記は２つのＤＬＴを使用するプロセスを説明しているが、プロセスは単一のＤＬＴ、または３つ以上の異なるＤＬＴに適用され得ることが理解されよう。さらに、上記では、検証セットおよびトランザクションの「ハッシュ」が説明されているが、検証セットの内容に少なくとも部分的に基づいて決定される任意の適切な検証セット識別子、およびトランザクションの内容に少なくとも部分的に基づく任意の適切なトランザクション識別子を代わりに使用してもよい。

【0126】

さらに、上記のプロセスでは検証セットのハッシュが両方のＤＬＴに追加されるが、別の方法ではハッシュはＤＬＴのうちの１つのみに追加されてもよい。すなわち、プロセス
が動作している２つ以上のＤＬＴに検証セットのハッシュを含めることが望ましい場合があり、これは、フォークが発生した場合でも、直前の検証セットの少なくとも１つの記録が常に存在するはずであるためである（２つのＤＬＴが同時に独立して分岐し、両方が直前の検証セットのハッシュを失う原因になることは極めてあり得ない）。これはデータの整合性、すなわちセキュリティの理由で有用であり得る。

【0127】

さらに、関連するトランザクションのハッシュを検証セットに保存することに加えて、またはその代わりに、関連するトランザクションの完全なコピーを保存してもよい。ただし、データストレージの効率を高めるために、関連するトランザクションのハッシュを保存する方が望ましい場合がある。一実装例では、関連する各トランザクションのハッシュを保存してもよく、かつ最近の関連するトランザクションの完全なコピーを保存してもよく（例えば、直前の１つ、２つ、３つ、４つの検証セットのトランザクション）、これは欠落しているトランザクションを再度行うのに役立ち得る。最近の関連するトランザクションのみを保存することにより、データストレージ要件をなおも最小限に抑えることができる。

【0128】

さらに、欠落しているトランザクションの識別と再実行はオプションであるが、ＤＬＴが可能な限り最新であり、ＤＬＴ上のトランザクションの順序が、トランザクションの記録８４０で識別されるように実際のトランザクションの順序に可能な限り密接に対応していることを保証するために、これらの手順を実行することが望ましい可能性がある。

【0129】

クロスレジャートランザクションの態様
上述したトランザクションの順序付けの態様の重要性をさらに理解するのを助けるため、次に、トランザクションの順序付けの態様を利用する例示的なクロスレジャートランザクション（ＸＬＴ）プロセスについて説明する。

【0130】

この例では、第１のＤＬＴ１２のトランザクションに現れる情報を第２のＤＬＴ１４に転送することが望まれる。その情報は、例えば、暗号通貨の量、ハッシュメッセージ（上記の「メッセージングの態様」で説明したとおり）、または任意の他のデータなど、何でもよい。トランザクションは、第１の所有者から第２の所有者に情報を転送する場合もあれば、所有権がまったく移転されない場合もある（例えば、エンティティは単に別のＤＬＴに情報を保存して、以前のＤＬＴから情報を効率的に削除したい場合がある）。

【0131】

図１０は、２つのＤＬＴの視覚化の例と、ＸＬＴが実行される、オフチェーンに保存されたトランザクションの記録１０４０を構成する対応する検証セットを示す。トランザクションＳ１０１２は、第１のＤＬＴ１２から第２のＤＬＴ１４に転送される情報を含む。検証セット_ｎ－１１０１０は、トランザクションＳのハッシュ１０１２’を含む。ＸＬＴは、２フェーズコミットプロセスを使用して実行され得る。２フェーズコミットプロセスは当業者にはよく理解されているであろうが、それでも完全を期すため以下に簡単に説明されている。トランザクションＳの情報をＤＬＴ１２からＤＬＴ１４に転送するための提案が最初にＤＬＴ１２に追加される（図１０の「プロポーズド（ｐｒｏｐｏｓｅｄ）ＸＬＴ（Ｓ）１０２２」で識別される）。これによりトランザクションＳ１０１２が効果的にロックされ、他のいずれのトランザクションでも使用できなくなる。その後、意図された受信者（状況によっては、先に説明したように、転送される情報の現在の所有者と同じエンティティであり得る）は、ＤＬＴ１４で転送を受け入れる準備ができていることを示してもよい（「レディ（ｒｅａｄｙ）ＸＬＴ（Ｓ）１０２６」で識別される）。別の方法では、いくつかのＤＬＴプロトコルでは第２のＤＬＴ１４で「プロポーズドＸＬＴ（Ｓ）１０２２」を再度行うことによって準備ができていることを示してもよい。準備ができていることが第２のＤＬＴ１４に示されると、ＤＬＴの両方（図１０では「コミット（ｃｏｍｍｉｔ）ＸＬＴ（Ｓ）１０３２」および「コミットＸＬＴ（Ｓ）１０３４」で識別される
）に追加されるコミットトランザクションによって、クロスレジャートランザクションが実行され得る。当業者によってよく理解されるように、このコミットメントは、取引されたアイテムを第１のＤＬＴ１２から効果的に削除し、それを第２のＤＬＴ１４に置く。

【0132】

不正やシステム障害のリスクなしにＸＬＴを安全かつ確実に実行するために、ＸＬＴを実行できる前に、コミットトランザクションが２つのＤＬＴに置かれる前に第２のＤＬＴ１４に準備ができていることを示す表示が現れることを確認する必要があり得る。さらに、準備ができていることの表示が常に提案の後に続き、２つを適切に照合して認証できるようにすることが望ましい可能性がある。このようにして、準備ができていることの表示が、何らかの他の類似しているが異なるトランザクション（例えば、同じパーティ間のＸＬＴ提案に関連しているが、ＤＬＴ１２上の異なる以前のトランザクションの内容に関するもの）に実際には関連していないことを保証することができる。また、準備ができていることの表示によって、ＸＬＴの詳細の一部が不正に変更されないことを保証することもできる。

【0133】

従来、前に説明したように、特に１つ以上のＤＬＴでフォークが発生した場合、異なるＤＬＴ上でトランザクションの正しい順序を判断することは非常に困難であった。その結果、安全で簡単かつ確実な方法でＸＬＴを実行することは困難であった。しかし、上記のトランザクションの順序付けの態様を利用することにより、１つ以上のＤＬＴでフォークが発生した場合でも、関連するトランザクションの正しい順序が記録され得る。

【0134】

例えば、トランザクションの順序付けの態様を使用して、例えば、プロポーズドＸＬＴ（Ｓ）１０２２がレディＸＬＴ（Ｓ）１０２６に対応していること（およびオプションで両方ともそれぞれ第１のＤＬＴ１２と第２のＤＬＴ１４上に依然として現れていること）、かつ（フォークが発生した場合でも）プロポーズドＸＬＴ（Ｓ）１０２２がレディＸＬＴ（Ｓ）に先行していることの両方など、ＸＬＴ基準が満たされていることが保証され得る。この点で、コミットＸＬＴ（Ｓ）１０３２トランザクションは、ＸＬＴ基準が満たされた後にのみ、ＤＬＴに追加され得る。必要に応じて、ＸＬＴ基準は、プロポーズドＸＬＴ（Ｓ）１０２２とレディＸＬＴ（Ｓ）１０２６トランザクションを識別する検証セットのハッシュが一方または両方のＤＬＴに存在するという基準を含んでもよく、これにより、プロポーズドＸＬＴ（Ｓ）１０２２およびレディＸＬＴ（Ｓ）１０２６トランザクションの両方がそれぞれのＤＬＴに存在することを保証し得る。この例では、プロポーズドＸＬＴ（Ｓ）のハッシュ１０２２’とレディＸＬＴ（Ｓ）のハッシュ１０２６’は同じ検証セットに現れるが、場合によっては別の検証セットに現れ得ることが理解される。プロポーズドＸＬＴ（Ｓ）のハッシュ１０２２’が、レディＸＬＴ（Ｓ）のハッシュ１０２６’が現れる検証セットに先行する検証セットに現れる場合、正しい順序を確認できる。プロポーズドＸＬＴ（Ｓ）のハッシュ１０２２’が、レディＸＬＴ（Ｓ）のハッシュ１０２６’が現れる検証セットの後に続く検証セットに現れる場合、トランザクションが間違った順序であることが確認できるため、ＸＬＴは発生しない。

【0135】

図１０に見られるように、検証セット_ｎ１０２０は、プロポーズドＸＬＴ（Ｓ）のハッシュ１０２２’を含み、その後にレディＸＬＴ（Ｓ）のハッシュ１０２６’が続く（検証セット_ｎ１０２０は、関連すると見なされる他のトランザクションのハッシュも含むが、それらはここで説明しているＸＬＴとは関係がない。実際には、検証セットを構築するエンティティは、ＤＬＴで多くの関連するトランザクションを識別し、検証セットでそれらを識別する可能性がある。それらの関連するトランザクションの一部は、特定のＸＬＴに関連するトランザクションなど、互いに関連している可能性があり、他のものは、例えば異なるＸＬＴや、エンティティが関連性があると見なす任意の他の種類のＤＬＴトランザクションに関連しているなど、互いにどのようにも関連していない）。検証セット_ｎのハッシュ１０２０’は両方のＤＬＴに現れ、その後、第１のＤＬＴ１２のコミットＸＬＴ（
Ｓ）１０３２と、第２のＤＬＴ１４のコミットＸＬＴ（Ｓ）１０３４が続く（これらはその後、次の検証セット_ｎ＋１１０３０で識別される）。

【0136】

この種類のＸＬＴは、様々な他の方法で実装され得る。図１１は、サービスオファリング開発者３１０を含む１つの特定の実装例を示し、サービスオファリング開発者は、この特定の例では、ＸＬＴを実行するためのサービスアプリケーション（またはソフトウェアパッケージ／モジュール）１１１０を開発し、また、クライアントアプリケーション開発者３２０にＢＰＩを提供し、クライアントアプリケーション開発者が特定のＸＬＴクライアントアプリケーションを開発できるようにする（代替として、サービスオファリング開発者３１０自身がクライアントアプリケーションを作成してもよく、その場合にはＢＰＩはいかなる外部開発者にも提供されない）。第１のクライアントアプリケーション１１２０および第２のクライアントアプリケーション１１３０は、第１のエンティティ１１４０および第２のエンティティ１１５０がクライアントアプリケーション開発者３２０からそれぞれ入手したＸＬＴクライアントアプリケーションの複製である。この例のクライアントアプリケーションは、アプリケーション機能層３０を効果的に実装することができ、ソフトウェアパッケージまたはモジュール１１１０は、オーバーレジャー通信層２０を効果的に実装することができる。

【0137】

図１２は、図１１に示されているシステム例によってＸＬＴが実行され得る例示的なステップを示す。

【0138】

ステップＳ１２１０において、サービスアプリケーション１１１０は、ＸＬＴを実行して第１のＤＬＴ１２に現れている情報のアイテムを第２のＤＬＴ１４に転送して所有権を第２のエンティティ１１５０に転送するために、第１のクライアントアプリケーション１１２０から要求を受信する。理解されるように、要求は、ＢＰＩで定義されているように、ＸＬＴを実行するために必要な任意の情報を含み得る。

【0139】

ステップＳ１２２０において、サービスアプリケーション１１１０は、第１のＤＬＴ１２に追加するために、第１のＤＬＴネットワーク２４０に対してプロポーズドＸＬＴトランザクションをブロードキャストすることができる。

【0140】

次に、ステップＳ１２３０において、サービスアプリケーション１１１０は、第２のＤＬＴ１４に追加するために、第２のＤＬＴネットワーク２５０にレディＸＬＴトランザクションをブロードキャストすることができる。オプションで、サービスアプリケーション１１１０は、ＸＬＴを実行する意図を第２のクライアントアプリケーション１１３０に伝えることができ、次に、トランザクションが行われるべきであるという第２のアプリケーション１１３０からの確認を受け取った後にのみステップＳ１２２０またはＳ１２３０を実行する。

【0141】

その間、サービスアプリケーション１１１０は、上記のトランザクションの順序付けの態様を実行し、関連するトランザクションの順序を示す関連するトランザクションの記録をデータストア１１１５に保存している。

【0142】

ステップＳ１２４０において、サービスアプリケーション１１１０は、プロポーズドＸＬＴトランザクションが、対応するレディＸＬＴトランザクションの前に行われたものとしてトランザクションの保存された記録内において識別されることと、オプションとして、関連する検証セットのハッシュが一方または両方のＤＬＴ内に現れたことも確認できる。

【0143】

この確認に合格すると、ステップＳ１２５０において、サービスアプリケーション１１
１０は、第１および第２のＤＬＴに追加するために、第１のＤＬＴネットワーク２４０および第２のＤＬＴネットワーク２５０にコミットＸＬＴトランザクションをブロードキャストする。オプションで、サービスアプリケーション１１１０は、第１のクライアントアプリケーション１１２０および／または第２のクライアントアプリケーション１１３０に、成功したＸＬＴを通知してもよい（これは両方のＤＬＴにコミットＸＬＴトランザクションが現れた後、またはコミットＸＬＴトランザクションが識別された検証セットのハッシュがＤＬＴの一方または両方に含まれた後に実行され得る）。確認に合格しない場合、一定期間の後にＸＬＴプロセスはタイムアウトしてもよく、第１のクライアントアプリケーション１１２０および／または第２のクライアントアプリケーション１１３０に障害が通知され得る。

【0144】

したがって、上記の順序付けの態様を実行することによって、そして次に検証セットでプロポーズドＸＬＴトランザクションおよび対応するレディＸＬＴトランザクションが正しい順序で行われていることが検証された後にコミットトランザクションをＤＬＴにポストするだけで、サービスアプリケーション１１１０は、ＸＬＴが安全にかつ安定して実行されることを保証し得る。

【0145】

これは単に１つの特定の非限定的な例であることが理解されるであろう。代替案では、サービスオファリング開発者３１０によって提供される特定のＢＰＩおよび／またはクライアントアプリケーション開発者３２０によって提供されるクライアントアプリケーションの実装に応じて、第１のクライアントアプリケーション１１２０自体が第１のＤＬＴネットワーク２４０にプロポーズドＸＬＴトランザクションをブロードキャストしてもよく、および／または第２のクライアントアプリケーション１１３０自体が第２のＤＬＴネットワーク２５０にレディＸＬＴトランザクションをブロードキャストしてもよい。この場合、サービスアプリケーション１１１０は上述のトランザクションの順序付けの態様を単に実行し、次に、関連するＤＬＴにおいてプロポーズドＸＬＴトランザクションおよび対応するレディＸＬＴトランザクションを識別したときにステップＳ１１４０およびＳ１１５０を実行してもよい。さらに、ＸＬＴは１つのエンティティのみを含む場合があり、これはエンティティが、所有権の任意の変更を伴って、あるＤＬＴから別のＤＬＴに情報を単に移動する場合があるためである。

【0146】

オーバーレジャーＳＤＫは、トランザクションの順序付けの態様およびオプションでＸＬＴの態様も実行するためのルールおよび方法を含み得ることが理解されよう。このように、オーバーレジャーＳＤＫは、オーバーレジャーＳＤＫでサポートされている任意の選択したＤＬＴでトランザクションの順序付けの態様を（およびオプションでＸＬＴの態様も）利用する任意のサービスアプリケーション／モジュールをサービスオファリング開発者３１０が実装できるツールを提供する。次に、選択したものの対応するＢＰＩを作成して、サービスオファリングの任意の適切な機能をクライアントアプリケーション開発者３２０が利用できるようにして、順序付けの態様を実行する際のＤＬＴとの相互作用がオーバーレジャー通信層２０によって実行され、クライアントアプリケーション上の任意のアプリケーション機能層３０の動作から切り離され得るようにする。結果として、クライアントアプリケーションは、ＤＬＴとの直接の相互作用から切り離されたまま、トランザクションの順序付けの態様によって得られるセキュリティと安定性の利点を利用できる。

【0147】

その結果、トランザクションの順序付けの態様を実行するためのルールおよび方法を含むオーバーレジャーＳＤＫを提供することにより、ブロックチェーンの相互作用をアプリケーション機能層３０からなおも切り離しつつ、トランザクションの順序付けの態様の技術的利点を幅広い様々なエンティティが様々な方法で利用する大きな柔軟性と機会が存在することがわかる。

【0148】

当業者は、本開示の範囲から逸脱することなく、本開示の上記の態様に対して様々な変更または修正を行うことができることを容易に理解するであろう。

【0149】

図２、図３、図５、および図１１に矢印で示されている全てのインターフェースは、異なるエンティティとモジュールの各々の間の直接接続を示しているが、例えば通信ルータなど、これらのインターフェースの一部として任意の数の中間エンティティまたはモジュールが存在し得ることが理解されよう。さらに、各インターフェースは、任意の適切な通信アーキテクチャおよびプロトコルに従って、エンティティおよびモジュールの各々の間でデータ／通信を伝達することがある。

【0150】

上記の全てで説明した本開示の態様は、ソフトウェア、ハードウェア、またはソフトウェアとハードウェアの組合せによって実装され得る。例えば、トランザクションの順序付けの態様および／またはＸＬＴの態様および／またはオーバーレジャーメッセージング層は、コンピュータ可読コードを含むソフトウェアによって実装されてもよく、ソフトウェアは、任意の電子デバイス（例えば、サーバ、デスクトップコンピュータ、またはラップトップコンピュータなどの任意の標準的なコンピューティングデバイス）の１つ以上のプロセッサ（１つ以上のマイクロプロセッサ、またはプログラム可能なロジックなど）で実行されると上記の機能を実行する。ソフトウェアは、任意の適切なコンピュータ可読媒体、例えば、読み取り専用メモリ、ランダムアクセスメモリ、ＣＤ－ＲＯＭ、ＤＶＤ、ブルーレイ、磁気テープ、ハードディスクドライブ、ソリッドステートドライブおよび光学ドライブなどの非一時的コンピュータ可読媒体に保存されてもよい。コンピュータ可読媒体は、コンピュータ可読命令が分散された方法で保存および実行されるように、ネットワーク結合されたコンピュータシステムにわたって分散されてもよい。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】