JP7062838B2 - ブロックチェーンデータベースにデータをデジタルファイルとして登録する方法 - Google Patents

Description

本発明は、一般に、データの登録及び検証方法に関し、特に、ブロックチェーン標準に従ったデータベースへのデータの登録、登録されたデータの出所、内容及びタイムスタンプの検証、並びにそのようなデータの転送方法に関する。本発明はまた、任意のタイプのデジタルデータの登録及び検証を扱うためのこれらの方法の適用に関する。本発明は更に、これらの方法を実施するためのコンピュータプログラムコード命令を含むコンピュータ読み取り可能な記憶媒体に関する。

ピアツーピア電気通信システムに動作可能に接続された装置間でデータを格納及び交換するように構成された電気通信システムは、デジタルコンテンツを配信するための方法及びシステムを開示するＷＯ２０１８０３２８９０Ａ１に記載されている。この方法は、コンテンツ装置がダウンロードクライアントから送信されたダウンロード要求を受信することであって、前記ダウンロード要求は、ダウンロードされるコンテンツファイルのアップロードトランザクションＩＤとライセンストランザクションＩＤとを含んでいることと；前記コンテンツ装置が前記アップロードトランザクションＩＤ及び前記ライセンストランザクションＩＤに基づいて、前記ダウンロードクライアントが前記コンテンツファイルをダウンロードするためのライセンス情報を有するか否かを判定し、もし有する場合には、前記コンテンツファイルを前記ダウンロードクライアントに送信することと；コンテンツファイルが配信された後、コンテンツ装置がダウンロードトランザクション要求をコンテンツトランザクション処理装置に送信することであって、ダウンロードトランザクション要求には、ダウンロード情報が含まれることと；前記コンテンツトランザクション処理装置がダウンロードトランザクション要求を受信し、ダウンロード情報が有効であると判断し、ダウンロードトランザクションを生成し、ダウンロードトランザクションをブロックチェーン処理装置に送信することと；前記ブロックチェーン処理装置がダウンロードトランザクションを受信し、前記ダウンロードトランザクションをブロックチェーンに追加することと、を含んでいる。

コンテンツ装置は、ダウンロードクライアントがダウンロード許可を有する場合にのみ、コンテンツファイルをダウンロードクライアントに送信することにより、コンテンツファイルの配信範囲を制限する。本発明の実施形態では、コンテンツファイルのアップロード及びダウンロード、ライセンス付与など、複数の著作権管理又はコンテンツ配信プロセスが存在する。

ＵＳ２０１６０２８３９２０Ａ１は、ブロックチェーン技術を利用して保管チェーンを認証するための方法を開示しており、この方法では、デジタル証拠又は他のデジタルコンテンツが取得され、ハッシュ指紋／署名を生成するためにハッシュされ、次いで、ブロックチェーンネットワークプロトコルを使用してブロックチェーンに前記ハッシュ指紋／署名を即時に又は即座に提出し、人の介入なしに、又は、信頼できる第三者を必要とせずに、即時検証可能な保管チェーンを形成する。ＵＳ２０１６０２８３９２０Ａ１によると、ドキュメントのハッシュがブロックチェーンデータベースに格納されるため、このドキュメントの内容を後で検証することができる。しかしながら、ドキュメントの出所／所有者、及び、ドキュメントのその内容がハッシュ化（タイムスタンプ）された時刻に関連する瞬間に関する情報は、この解決策では欠落している。

著作権認証の管理方法及びシステムは、ＷＯ２０１８０２４０６２Ａ１に記載されている。この方法は、著作権者情報を取得することと；著作権所有者の情報に応じて、対応する著作権所有者クライアントに契約決定通知を送信することであって、前記契約決定通知は許諾された著作物の著作権関連情報を含んでいることと；著作権所有者クライアントから返されたトランザクション情報を受け取ることであって、前記トランザクション情報は著作権情報に応じて著作権者が定める契約情報を含んでいることと；トランザクション情報に基づいて有効な契約トランザクションを取得することであって、前記有効な契約トランザクションは予め設定された数の規則を満たす署名を含んでいることと；ブロックチェーン内に前記有効な契約トランザクションを保持することと、を含んでいる。著作権承認管理方法及びシステムは、契約のオンライン署名及びブロックチェーンに基づいて署名された契約の持続性を実装し、それによって著作権承認効率を向上させ、契約がユニークで信頼性があり改ざんのないものであることを保証する。

米国特許出願番号ＵＳ２０１８０１３９０５６Ａ１は、ブロックチェーンネットワークに接続された装置へのアクセスを有するユーザを認証するためのシステム及び方法であって、以下の操作：パブリックブロックチェーン内の特定のソース及びコンテンツのデータを、前記ユーザを識別する情報及びタイムスタンプとともに記録すること；分散ファイル共有ネットワークに追加の関連データを記録し、当該分散ファイル共有ネットワークに記録されたデータにアクセスするとともに、アクセスイベントをパブリックブロックチェーンに記録することを実行するためのシステム及び方法を開示している。ＵＳ２０１８０１３９０５６Ａ１に開示されているユーザ認証方法は、ブロックチェーン技術に基づいた公知のユーザ認証方法である。ＵＳ２０１８０１３９０５６Ａ１は、任意のデータ（デジタルファイル）及びその特性、例えば、そのデータの内容、著者（出所）又はタイムスタンプなどをブロックチェーンデータベースに登録することを可能にする方法を開示している。ＵＳ２０１８０１３９０５６Ａ１は、特定のソース（デジタルファイル）からのデータ（「ＩｏＴ Ｇａｔｅｗａｙ」又は「Ｃｌｉｅｎｔ Ｔｅｒｍｉｎａｌ」と呼ばれる）のみを扱う。しかしながら、ＵＳ２０１８０１３９０５６Ａ１は、ブロックチェーンデータベースに：ａ）ファイルの内容については、当該デジタルファイルのハッシュ（又はファイル自体）及びｂ）ファイルの出所については、デジタルファイルのハッシュのデジタル署名（ファイルの内容をこのファイルの出所と結合する）を格納することを開示も示唆もしていない。更に、ＵＳ２０１８０１３９０５６Ａ１に従ってデータを登録するには、ユーザはブロックチェーンネットワーへのアクセスを有している必要がある。また、ＵＳ２０１８０１３９０５６Ａ１のシステムオペレータは、データが暗号化されていない限り、登録されているデータの内容を「見る」ことになる。

本発明は、任意のソースのデジタルファイルの任意のコンテンツの出所、コンテンツ、及びタイムスタンプを、任意のインターネットユーザ（特に、ブロックチェーンネットワークへのアクセス権を持たないユーザによる）がパブリック又はプライベートブロックチェーンネットワークに登録するための方法を提供する。本発明は、適切なコンパイルの後、（デジタルファイルの内容及び出所に関連する）所望の情報を、単一のブロックチェーントランザクションに「フィード」する。このトランザクションは、ブロックチェーントランザクションを登録するための標準手順を使用して、ユーザから独立したシステムオペレータによってブロックチェーンネットワークに登録される。デジタルファイルのハッシュは、ブロックチェーントランザクション自体に署名するために使用される鍵とは異なる鍵で署名される。このため、本発明による方法は、任意のインターネットユーザ（特に、ブロックチェーンネットワークへのアクセス権を持たないユーザ）に利用可能であり、システムオペレータは、登録された（又は検証された）データを「見る」ことはない。本発明によれば、最終的にブロックチェーンデータベース（すなわち、当該ファイルの内容、出所及びタイムスタンプを特徴付けること）に登録されるデジタルファイルの３つの特徴の全てが１つの同じデジタルファイルに関連することに留意されたい。

従来技術の解決策の何れも、上記のような利点を有する信頼できる方法を提供することはできない。

本発明は、データの内容に関する情報、データの出所／所有者に関する情報、及びこの出所／所有者からのこのコンテンツのデータ登録のタイムスタンプに関する情報を同時にブロックチェーンデータベースに安全に格納することができるデータ登録の方法を提供する。本発明はまた、この安全なデータ登録方法に基づいて、登録の内容、出所／所有者及びタイムスタンプに関してデータファイルの検証を可能にするデータ検証方法を提供する。これらの方法は、電気通信システムに接続された装置間でデータを登録及び交換するように構成された電気通信システムにおいて実行される。

電気通信システムに接続された装置間でデータを登録及び交換するように構成された電気通信システムは、前記電気通信システムの少なくとも２つのノードによって形成することができる。通信システムの前記ノードは、例えば、格納、交換、処理のためにデータ操作を計算するように構成される、例えばコンピュータなどの電気通信装置である。フロントエンド装置は、典型的にはユーザ機器であり、デジタルファイル（本明細書全体を通じて、「デジタルドキュメント」、「デジタル財」、「データ」又は「テストデジタルドキュメント」、「テストデジタル財」、「テストデータ」とも呼ばれる）の形式のデータを、作成、複製、受信、又は送信するなどのユーザデータ処理を行うために構成されたユーザインタフェースを有する第１のコンピュータ装置である。前記第１のコンピュータは、データを格納するように構成された通信システムの１つ又は複数のノードに接続され、前記第１のコンピュータは、データを処理するように構成された１つ又は複数の承認ノードに接続される。データの保存及びデータの処理用に構成されたノードは、同じノードであってもよい（ただし、そうである必要もない）。このデータベースは、既存のレコードを削除したり上書きしたりすることなく、既存のレコードに、レコードの形式で新しい情報を追加するように構成されている。これは、いわゆるインクリメンタルで不変のデータベースである。よく知られているブロックチェーンデータベースは、そのようなデータベースの一例である。各レコードは、そのサイズ及び構造（多くのブロックチェーン標準で：固定サイズ及び固定構造）を有するデータパケットであり、レコードはトランザクションに格納され、トランザクションはブロックに格納され、ブロックから作られたデータベースはブロックチェーンを形成する。このブロックには、コンピュータによって生成されたいわゆるトランザクション、タイムスタンプ、及びブロックチェーン内の先行ブロックに関する情報が含まれる。このトランザクションには整数個のデータコンテナが含まれており、多くのブロックチェーン標準では、標準の固定サイズを有している。具体的には、ビットコインやダッシュなどのブロックチェーン標準では、標準データコンテナは、その標準固定サイズを有している。

ブロックチェーンは、すべてのトランザクションのデジタル化された分散型台帳である。「完了した」ブロック（直近の取引）が記録され、時系列順に追加されていくにつれて継続的に成長することにより、市場参加者は、中央集権的な記録管理を行うことなく取引を追跡することができる。任意のノード（ネットワークに接続されたコンピュータ）がブロックチェーンの複製を取得でき、それは自動的にダウンロードされる。ネットワークは、各ノードがすべての完成したブロックを包含する同じ情報を有するように、ノード間でデータベースの内容を同期する。

当初、仮想通貨ビットコインの会計方法として開発されたブロックチェーンは、分散型元帳技術（ＤＬＴ）として知られているものを使用しており、今日、様々な商用アプリケーションに登場している。現在、この技術は主に、デジタル通貨内でトランザクションを検証するために使用されているが、実質的に任意のデータをデジタル化し、コード化し、ブロックチェーンに挿入することが可能である。これにより、「事実上」変更できない不変レコードが作成される。更に、単一の一元化された権限の代わりに、ブロックチェーンを使用して、コミュニティ全体でレコードの信頼性を検証することができる。

ブロックはブロックチェーンの一部であり、最近のトランザクションの少なくとも一部を記録している。ブロックは、記録されることを待っているトランザクションがあっても、時には空であってもよい。完了すると、ブロックは永久にブロックチェーンに記録される。ブロックが完了するたびに、新しいブロックが生成され、ネットワークノードによる完了（その内容の暗号化による承認）を待つ。ブロックの数は時間とともに絶えず増加する。ブロックは、（チェーン内のリンクのように）適切な線形の時系列で相互に接続される。すべてのブロックは、前のブロックのハッシュを含んでいる。ブロックチェーンは、ジェネシスブロックから最後に完了したブロックまでのすべてのトランザクションに関する完全な情報を有している。

ブロックチェーンは、これらのトランザクションが不変であるように設計されており、それらを削除したり変更したりすることはできない。ブロックは暗号化によって追加され、干渉のない状態を維持する：データは、配布又は複製することはできるが、変更することはできない。しかしながら、一部にはブロックチェーンのサイズが拡大し続けることが問題であると考えられており、保存及び同期の問題を作り出している。
［ｈｔｔｐ：／／ｓｃｅｔ．ｂｅｒｋｅｌｅｙ．ｅｄｕ／ｗｐ－ｃｏｎｔｅｎｔ／ｕｐｌｏａｄｓ／ＡＩＲ－２０１６－ｂｌｏｃｋｃｈａｉｎ．ｐｄｆ］

本発明によると、ブロックチェーンデータベースにデジタルドキュメントをデジタルファイルとして登録する方法であって、データベーストランザクションは固定サイズを有し得る標準データコンテナで構成され、前記ブロックチェーンデータベースの少なくとも一部を格納するための１つ又は複数の格納ノードと、前記ブロックチェーンデータベース内のトランザクションを承認するための１つ又は複数の承認ノードと、前記ブロックチェーンデータベース内のトランザクションを生成するための第１のコンピュータとを含んだシステムにおいて、前記第１のコンピュータは前記ブロックチェーンデータベースへのアクセスを有し、且つ、第１の秘密鍵へのアクセスを有しており、
ａ）前記デジタルファイルの内容に関する第１のデータセットを提供する工程と；
ｂ）前記デジタルファイルの出所に関連する第２のデータセットを提供する工程と；
ｃ）第１のデータセット、第２のデータセット、任意選択的にヘッダ、及び任意選択的にサフィックスをデータフレームに統合することによって第３のデータセットを生成する工程であって、前記ヘッダは、前記第３のデータセットの構造に関する及び前記第１のデータセットのサイズに関する情報を含んでいてもよく、一方、前記サフィックスのサイズは、前記データフレームのサイズが前記ブロックチェーンデータベースで使用される前記標準データコンテナのサイズの倍数になるように調整される工程と；
ｄ）前記第３のデータセットを整数Ｎ≧１個の同一サイズの部分に分割する工程であって、前記サイズは前記ブロックチェーンデータベースで使用される前記標準データコンテナのサイズに対応している工程と；
ｅ）前記工程ｄ）で得られたＮ個の部分全てについて、単一のブロックチェーントランザクションを、前記第１のコンピュータ又は前記第１のコンピュータに接続された中間コンピュータ及び前記１つ又は複数の承認ノードによって、生成する工程であって、前記第１の秘密鍵によって前記トランザクションに署名し、前記トランザクション及び前記第１の秘密鍵に一致する第１の公開鍵を承認のために前記１つ又は複数の承認ノードに送信する工程と；
ｆ）前記１つ又は複数の承認ノードから前記トランザクションの承認を取得する工程と；
ｇ）前記工程ｆ）で承認されたトランザクションを、前記１つ又は複数の格納ノードによって登録タイムスタンプと共に前記ブロックチェーンデータベースのブロックに登録する工程とを含み、
前記第２のデータセットは、前記デジタルファイルのハッシュのデジタル署名を備え、
前記ブロックチェーンデータベース内の前記デジタルファイルとしての前記デジタルドキュメントの登録は、第１のエンティティによって行われ、前記デジタルドキュメントは、前記第１のエンティティから第２のエンティティに送信される方法が提供される。

本発明の方法によれば、用語「デジタルファイルなどのデジタルドキュメント」は、任意のデジタルデータに関連する。特に、そのようなデータは、ブロックチェーントランザクション以外のドキュメント又はその一部であってもよい。

工程ｃ）で生成された第３のデータセットは、特定の順序のデータを必要としない。単なる例として、第３のデータセットは、ヘッダ、第１のデータセット、第２のデータセット、及び任意選択的にサフィックスをデータフレームに統合することによってコンパイルされ、ヘッダで始まり、第１のデータセットが続き、第２のデータセットが続き、任意選択的にサフィックスで終わっていてもよい。しかしながら、第３のデータセットが第１のデータセット及び第２のデータセットを含む限り、他の順序も許容される。

工程ｅ）に関する限り、特定のデータセットを運ぶブロックチェーントランザクションを構築する方法に関する知識は、一般に利用可能であり、特定のブロックチェーンネットワークのプロトコルにエンコードされた規則から生じる。例えば、ビットコインブロックチェーンのソースコードは、ウェブサイト（ｈｔｔｐｓ：／／ｂｉｔｃｏｉｎ．ｏｒｇ／）からダウンロードすることができる。このソースコードは、あらゆるタイプのビットコイントランザクションを実行するために必要なすべての要件を決定する。

第３のデータセットの長さが所定のブロックチェーンデータベースの標準データコンテナのサイズを超える場合、第３のデータセットはＮ個の部分に分割される。第３のデータセットをＮ個の部分に分割することにより、第３のデータセットを複数のデータコンテナからなる１つのブロックチェーントランザクションに記録することができる。更に、トランザクション（第１のデータセットを含む）をブロックチェーンデータベースに記録するシステムオペレータは、第３のデータセットの構造を知っており、この構造はシステムオペレータによって公開されるので、データの検証は、システムオペレータを通してだけでなく、独立して行うこともできる。データフレームの（即ち、第３のデータセット）の構造は、例えば、ヘッダから、システムオペレータに知られ得る。第３のデータセットの構造に関する情報は、特に、第３のデータセットの要素の内容、順序、及び／又はサイズに関連し得る。

「データコンテナ」／「標準データコンテナ」という用語は，トランザクションの発行者が、このトランザクションと共にブロックチェーンデータベースに記録されることを意図したデータを入力することができる、ブロックチェーンプロトコルから生じる、指定された長さのブロックチェーントランザクションの一部である。１つのブロックチェーントランザクションには、指定された長さの複数のデータコンテナが含まれる場合がある。例として、ビットコインブロックチェーン内の標準データコンテナは、一般的に「ｓｃｒｉｐｔＰｕｂＫｅｙ」（又は「ｐｋＳｃｒｉｐｔ」）と呼ばれ、「Ｔｘｏｕｔ－ｓｃｒｉｐｔ」（「出力セグメント」とも呼ばれる）の一部であり、指定された長さの任意のデータを含むことができる。

一実施形態では、第１のデータセットは、デジタルファイル自体であり得る。

別の実施形態では、第１のデータセットは、好ましくはＳＨＡ２５６アルゴリズム、ＳＨＡ３－２５６アルゴリズム、又はＳＨＡ３－５１２アルゴリズムによって生成された前記デジタルファイルのハッシュであってもよい。

このような場合、好ましくは、第１のデータセットは、前記ＳＨＡ２５６アルゴリズムによって生成された前記デジタルファイルのハッシュであって、６４ディジット、好ましくは６４ｈｅｘディジット、若しくはこれらの倍数のサイズを有しているか、又は、前記ＳＨＡ３－２５６アルゴリズムによって生成された前記デジタルファイルのハッシュであって、６４ディジット、好ましくは６４ｈｅｘディジット、若しくはこれらの倍数のサイズを有しているか、又は、前記ＳＨＡ３－５１２アルゴリズムによって生成された前記デジタルファイルのハッシュであって、１２８ディジット、好ましくは１２８ｈｅｘディジット、若しくはこれらの倍数のサイズを有している。

第２のデータセットに含まれる前記デジタルファイルの前記ハッシュの前記デジタル署名は、好ましくは、前記デジタルファイルの前記ハッシュと、前記デジタルファイルの出所に対応する秘密鍵との関数として計算される。前記秘密鍵に対応する公開鍵は、任意選択的に、第２のデータセットに追加することができる。デジタルファイルの出所に対応する前記秘密鍵は、前記第１の秘密鍵とは異なるものであってもよい（ほとんどの場合異なっている）。

第２のデータセットがデジタルファイルのハッシュのデジタル署名である場合、第２のデータセットは、好ましくは、１３０ディジット、好ましくは１３０ｈｅｘディジットのサイズを有している。

ヘッダはオプションであり、ほとんどの場合、ヘッダを第３のデータセットに含める必要はない。ヘッダは、単数又は複数のデジタルファイルの署名者の数が１より多い場合、又は、データフレームに格納されるべきデジタルファイルのハッシュの数が１より多い場合に、便利であり、推奨される。このような場合、ヘッダは、単数又は複数のデジタルファイルのハッシュの数及び第３のデータセットに格納されたデジタルファイルのハッシュの数を含むべきである。単数又は複数のデジタルファイルのハッシュの署名数は、デジタルファイルの署名者の数を参照してもよく、デジタルファイルのハッシュ数は、単一のブロックチェーントランザクションでブロックチェーンデータベースに登録されることを意図したデジタルファイルの数に関連させることができる。何れにしても、システムオペレータは、データフレームを正しく作成し、後で正しく読み取ることができるように、データフレームの（即ち、第３のデータセットの）構造を知っていなければならない。データフレームの（即ち、第３のデータセットの）構造は、例えば、ヘッダから、システムオペレータに知られ得る。ヘッダには、第１のデータセットのサイズに関する情報が含まれる場合がある。第３のデータセットの構造に関する情報は、特に、第３のデータセットの要素の内容、順序、及び／又はサイズに関連し得る。

好ましくは、ヘッダは、６ディジット、好ましくは６ｈｅｘディジットのサイズを有し、以下の情報：前記デジタルファイルのバージョン、前記デジタルファイルのタイプ、前記データフレームに格納されるべきハッシュの数、前記デジタルファイルの署名者の数を備えている。

好ましくは、ブロックチェーンデータベースはダッシュデータベース又はビットコインデータベースであり、前記標準データコンテナは４０ｈｅｘディジットのサイズを有している。

本発明の好ましい態様では、第１のデータセットに関連して、以下の情報：前記工程ｅ）で生成された前記トランザクションに対応するトランザクションハッシュ、ブロックハッシュ、ブロックハイト、及び、前記工程ｇ）で言及された前記ブロックに対応する登録のブロックタイムスタンプが別個のデータベースに格納される。

１つの好ましいオプションでは、本発明の方法は、
ｈ１）ユーザが、好ましくはウェブブラウザを介してテストデジタルファイルを提供する工程と；
ｉ１）前記テストデジタルファイルのハッシュを計算する工程と；
ｊ１）前記テストデジタルファイルの前記ハッシュと、上に記載したデジタルファイルの登録手順に係る方法の結果として前記ブロックチェーンデータベースの前記ブロック内に以前に格納された前記デジタルファイルの前記ハッシュである前記第１のデータセットとが一致するかどうかをチェックする工程であって、前記ユーザへの肯定的な送信確認において、好ましくは前記ウェブブラウザを介して、前記確認は、前記テストデジタルファイルの内容に関する情報を含み、任意選択的に、前記テストデジタルファイルの出所に関する情報及び／又は登録のブロックタイムスタンプに関する情報を含んでいる工程と、を更に含んでいる。

別の好ましいオプションでは、本発明の方法は、
ｈ２）ユーザが、好ましくはウェブブラウザを介してテストデジタルファイルを提供する工程と；
ｉ２）前記テストデジタルファイルのハッシュを計算する工程と；
ｊ２）前記テストデジタルファイルの前記ハッシュと、上に記載したデジタルファイルの登録手順（前記別個のデータベースに情報を格納することを含む）の結果として前記別個のデータベースに以前に格納された前記デジタルファイルの前記ハッシュである前記第１のデータセットとが一致するかどうかをチェックする工程であって、前記ユーザへの肯定的な送信確認において、好ましくは前記ウェブブラウザを介して、前記確認は、前記テストデジタルファイルの内容に関する情報を含み、任意選択的に、前記テストデジタルファイルの出所に関する情報及び／又は登録のブロックタイムスタンプに関する情報を含んでいる工程と、を更に含んでいる。

上述の２つの段落で説明した２つのオプションは、したがって、任意のデジタルドキュメント／デジタルファイルの検証のための手順を提供する。

そのような場合、好ましくは、前記テストデジタルファイルの前記ハッシュが、前記工程ｊ１）又はｊ２）において、それぞれ、複数の第１のデータセットと一致する場合、１つの選択された登録タイムスタンプ、好ましくは最も古い登録タイムスタンプを保持するトランザクションに対応する情報のみが、前記工程ｊ１）又はｊ２）のそれぞれにおける前記ユーザへの前記確認を生成するための基礎として使用される。

更に別の好ましいオプションでは、本発明は、
・前記第１のエンティティによって前記デジタルドキュメントを生成することと、
・上記のデジタルドキュメントの登録手順に従って、前記ブロックチェーンデータベースにおける前記第１のエンティティによる前記デジタルドキュメントの前記デジタルファイルとしての登録を行うことと；
・任意選択的にユーザ端末を介して、前記デジタルドキュメントを前記第１のエンティティから前記第２のエンティティに送信することと、
・上記のデジタルドキュメントの検証手順に従って、前記第２のエンティティによる前記テストデジタルファイルとしての前記デジタルドキュメントの検証を行うことと
を含んだ方法を提供する。

好ましくは、前記デジタルドキュメントは、クライアントの個人データ及び前記クライアントのトランザクション履歴を含んでおり、好ましくは、前記デジタルファイルは、前記クライアントの銀行取引明細書、又は、前記クライアントの銀行口座上における前記クライアントの個人情報及びトランザクション履歴を含んだ類似のドキュメントである。

このように、前の２つの段落で説明した好ましいオプションは、信頼できるコンテンツ、ソース及びタイムスタンプのデジタルドキュメントを２つのエンティティ間で送信するための方法を提供する。この方法は、すべてのデジタルドキュメント／デジタルファイルに適用される。

本発明は、コンピュータ可読媒体に格納されたプログラムコードを含むコンピュータプログラム製品であって、前記プログラムコードは上で規定された方法を実行するためのコンピュータ命令を含んでいるコンピュータプログラム製品にも関する。

図１は、本発明の実施形態による第３のデータセット５を示し、この場合、第３のデータセット５は、ヘッダ１と、第１のデータセット２と、第２のデータセット３と、サフィックス４と、を含むデータフレームであり、ヘッダ１は、デジタルファイルのバージョンに関する情報を含む第１の桁（Ａ）と、データのタイプに関する第２の桁（Ｂ）と、このフレームに格納されるべきデジタルファイルのハッシュの数に関する情報を含む第３の桁（Ｃ）及び第４の桁（Ｄ）と、デジタルファイルの所有者の数に関する情報を知らせる第５の桁（Ｅ）と、この実施形態では関係のない追加情報を格納するための第６の桁（Ｆ）と、を更に含んでいる。この例では、データフレーム内のデータの特定の順序を示している。しかしながら、第３のデータセット５が、第１のデータセット２及び第２のデータセット３によって構成されている限り、他の順序も許容される。この例は、ヘッダ１とサフィックス４とを含んでいるが、一般的に、これらの各要素は、任意選択的なものである。

本発明は、ブロックチェーンデータベースにデータを登録するための方法を提案する。前述したように、ブロックチェーンデータベースは、トランザクションが固定サイズを有する標準データコンテナから構成されるインクリメンタルデータベースの一般的に知られている例である。ブロックチェーンデータベースは、ブロックチェーンデータベースの少なくとも一部を格納するための１つ又は複数の格納ノードと、前記ブロックチェーンデータベース内のトランザクションを承認する１つ又は複数の承認ノード（一般に「マイナー」と呼ばれる）とを含むシステムに実装されることが知られている。データの保存及びデータの処理用に構成されたノードは、同じノードであってもよい（ただし、そうである必要もない）。また、ブロックチェーンデータベース内のトランザクションを生成するコンピュータが存在し、前記コンピュータは、前記ブロックチェーンデータベース及びノードにアクセスすることができる。このコンピュータは、システムオペレータの秘密鍵（第１の秘密鍵、又はノードの秘密鍵）へのアクセスも有している。

本発明の方法は、以下の工程を含んでいる：

ａ）デジタルファイルの内容に関する第１のデータセット２を提供する工程。
「デジタルファイル」という用語は、任意の「デジタル財」を包含しており、すなわち、標準フォーマット（ｐｄｆ、ｄｏｃ、ｍｐ３、ａｖｉ、ｊｐｅｇなど）の何れかのファイル又は任意の他のデータセット若しくはストリングなど、確立された（ｗｅｌｌ－ｅｓｔａｂｌｉｓｈｅｄ）データ構造を有するデータファイルであり得る。「デジタルファイルの内容に関する第１のデータセット」という用語は、デジタルファイルの内容に関する情報を包含する。特に、それは、デジタルファイル自体、その一部、又はこのデジタルファイルのハッシュであってもよく、当該ハッシュは、任意の公知の方法（ハッシュ関数の詳細については本文中で説明する）によって得られる。この方法は、任意の「デジタルドキュメント」／「デジタルファイル」に関する。

ｂ）前記デジタルファイルの出所に関連する第２のデータセット３を提供する工程。
「出所」は、ファイルのソース、例えば、ノードのＩＰアドレス、ブロックチェーンアドレス、そのデジタルファイルの作成者又は所有者であるユーザのＩＤ又は名前を参照する。第２のデータセット３は、デジタルファイルのハッシュのデジタル署名を含み、好ましくは、前記デジタルファイルの前記ハッシュと、前記デジタルファイルの出所に対応する秘密鍵（第２の秘密鍵、即ち、デジタルファイルの所有者（又は保持者）の秘密鍵）との関数として計算される。第２のデータセット３のサイズは、格納する情報の量、デジタルファイルのハッシュの長さ、格納するハッシュの数、デジタル署名の長さ、及び格納するデジタル署名の数に関連している。例えば、ＳＨＡ３－２５６ハッシュ関数を使用すると、ハッシュは６４ディジットの長さになり、ＳＨＡ３－５１２を使用すると、１２８ディジットの長さになる。前記第２の秘密鍵に対応する公開鍵は、任意選択的に、第２のデータセット３に追加され得る。

ｃ）前述の２つのデータセット（つまり、第１のデータセット２及び第２のデータセット３）を統合し、任意選択的にヘッダ１を追加し、任意選択的にサフィックス４を追加することにより、第３のデータセット５を生成する工程。
第３のデータセット５は、ヘッダ１と、第１のデータセット２と、第２のデータセット３と、サフィックス４とを有するデータフレームである。これは、第３のデータセット５が、構造、即ちデータの特定の順序を有することを意味している。例として、それは、ヘッダ１から始まり、第１のデータセット２が続き、第２のデータセット３が続き、必要に応じてサフィックス４で終わる。ヘッダ１は６ｈｅｘディジットを有し、第１のディジット（Ａ）はデジタルファイルのバージョンに関する情報を含み、第２のディジット（Ｂ）はデジタルファイルのタイプに関する情報を含み、第３のディジット（Ｃ）及び第４のディジット（Ｄ）はこのフレームに格納されるべきデジタルファイルのハッシュ数に関する情報を含み、第５のディジット（Ｅ）はデジタルファイル所有者の数に関する情報を含み、第６のディジット（Ｆ）は本実施形態には関係しない追加情報を登録するためのものである。データフレームにサフィックス４を付加することにより、データフレーム（即ち、第３のデータセット５）を等しいサイズの整数個の部分に分割することが可能となる。したがって、サフィックス４のサイズは、データフレームの（即ち、第３のデータセット５の）合計サイズが、前記ブロックチェーンデータベースで使用される標準データコンテナのサイズの倍数になるように調整される。たとえば、ビットコインデータベースでコンテナが４０桁の場合、フレームサイズは４０の倍数、例えば４０、８０，１２０などにする必要がある。なお、サフィックス４の内容は、本実施形態には関連しない（例として、それは、ゼロ、ディジット、又はストリングスの形態であってもよい）。本項で説明するデータフレーム内のデータの特定の順序は、一例として示されている。第３のデータセット５が第１のデータセット２及び第２のデータセット３を含む限り、他の任意の順序が許容される。この例は、ヘッダ１とサフィックス４とを含んでいるが、一般的に、これらの各要素は、任意選択的なものである。

何れにしても、システムオペレータは、データフレームを正しく作成し、後で（例えば検証を実行するために）正しく読み取ることができるように、データフレームの（即ち、第３のデータセット５の）構造を知っていなければならない。データフレームの構造は、例えば、ヘッダから、システムオペレータに知られ得る。

例えば、ビットコインブロックチェーンデータベースにおけるこのようなデータフレームの生成は、以下のように実行される。この実施形態では、前述の第３のデータセット５は、以下の部分を有するデータフレームである：６ディジットのヘッダ１＋第１のデータセット２としての６４ディジットのハッシュ＋第２のデータセット３としての１３０ディジットのデジタル署名：これらが２００ディジットを与え、２００は４０（標準ビットコインコンテナのサイズ）の倍数であるため、サフィックス４を付け加える必要はない。

別の実施形態では、ＳＨＡ３－５１２アルゴリズムを使用して計算されるハッシュについて、第３のデータセット５は、以下の部分を有するデータフレームである：６ディジットのヘッダ１＋第１のデータセット２としての１２８ディジットのハッシュ＋第２のデータセット３としての１３０ディジットのデジタル署名：これらは２６４ディジットを与え、これは４０（標準ビットコインコンテナのサイズ）の倍数ではないため、サフィックス４を付け加える必要があり、それは１６ディジットを有していなければならない。この実施形態では、サフィックス４は、データのストリングである。この操作では、４０の倍数である２８０ディジットの長さのフレームが、第３のデータセット５として生成される。この第３のデータセット５の場合、ビットコインブロックチェーンの標準コンテナのサイズの整数部分の数Ｎは、７である。

ｄ）第３のデータセット５を整数Ｎ≧１個の同一サイズの部分に分割する工程であって、前記サイズは前記標準データコンテナのサイズに対応している（前記ブロックチェーンデータベースに対応している）工程。
上述したように、第３のデータセット５は、次に、固定された等しいサイズを有する整数個の部分に分割される。このサイズは、ブロックチェーンデータベースのタイプに起因する。ビットコイン及びダッシュブロックチェーンデータベースの場合、標準のコンテナサイズは４０ディジットである。上記の実施形態では、第３のデータセット５は：
－第１の実施形態では、４０ディジットのＮ＝５個の部分に、
－第２の実施形態では、４０ディジットのＮ＝７個の部分に、
分割される。

ｅ）前記工程ｄ）で得られたＮ個の部分全てについて、単一のブロックチェーントランザクションを、前記第１のコンピュータ又は前記第１のコンピュータに接続された中間コンピュータ並びに前記１つ又は複数の承認ノードによって、生成する工程であって、前記第１の秘密鍵によって前記トランザクションに署名し、前記トランザクション及び前記第１の秘密鍵に一致する第１の公開鍵を承認のために前記１つ又は複数の承認ノードに送信する工程。
前記トランザクションの生成は、前記トランザクションの生成に必要なコンテンツを前記第１のコンピュータから取得する仲介コンピュータによってトランザクションが生成される状況も包含している。前記トランザクションの送信は、直接（第１のコンピュータと１つ又は複数の承認ノードとの間で）又は間接的に、即ち、第１のコンピュータからＡＰＩ及びバックエンドを介して１つ又は複数の承認ノードへと実行されてもよい。このトランザクションは、承認ノードがブロードキャストして他のノードと情報を共有するときにネットワーク内で伝播される。生成されたトランザクションは、コンセンサス及びセキュリティレベルを最大化するために、複数の承認ノードに認識されるようになっている。

ｆ）前記１つ又は複数の承認ノードから前記トランザクションの承認を取得する工程。
承認ノードは、承認情報をネットワークに送信し、伝達する。

ｇ）前記工程ｆ）で承認されたトランザクションを、前記１つ又は複数の格納ノードによってブロック生成タイムスタンプ（即ち、登録タイムスタンプ）と共に前記ブロックチェーンデータベースのブロックに登録する工程。
承認されたトランザクションは、ブロックチェーンデータベースのブロックに配置される。ブロックチェーンに追加された新しいレコード（新しいブロック）に関する情報は、ネットワークを介して拡散される。このようにして、デジタル財に関する全ての情報が、そのソース／出所／所有者に関する情報及び登録タイムスタンプと共に、ブロックチェーンデータベースに格納される。

前記ブロックチェーンデータベース内の前記デジタルファイルとしての前記デジタルドキュメントの登録は、第１のエンティティによって行われ、前記デジタルドキュメントは、前記第１のエンティティから第２のエンティティに送信される。

本発明による方法の一実施形態では、第１のデータセット２は、デジタルファイルである。「デジタルファイル」という用語は、任意の「デジタル財」を包含しており、すなわち、標準フォーマット（ｐｄｆ、ｄｏｃ、ｍｐ３、ａｖｉ、ｊｐｅｇなど）の何れかのファイル又は任意の他のデータセット若しくはストリングなど、確立された（ｗｅｌｌ－ｅｓｔａｂｌｉｓｈｅｄ）データ構造を有するデータファイルであり得る。「デジタルファイルの内容に関する第１のデータセット２」という用語は、デジタルファイルの内容に関する情報を包含する。特に、それは、デジタルファイル自体、その一部、又はこのデジタルファイルのハッシュであってもよく、当該ハッシュは、任意の公知の方法（ハッシュ関数の詳細については本文中で説明する）によって得られる。

本発明に係る方法の別の実施形態では、第１のデータセット２は、好ましくはＳＨＡ２５６アルゴリズム、ＳＨＡ３－２５６アルゴリズム、又はＳＨＡ３－５１２アルゴリズムによって生成された前記デジタルファイルのハッシュである。ハッシュは、他の既知の暗号アルゴリズムを使用して生成することができ、出力として一連の数字を与える。この一連の数字は、デジタルファイルの一意の識別子であり、ハッシュ関数を逆にしてハッシュからデジタルファイルを再作成することは事実上不可能である。好ましくは、ハッシュは、楕円曲線暗号法（ＥＣＣ）を用いて生成され、特に、米国連邦情報処理規格（ＦＩＰＳ）として米国標準技術局（ＮＩＳＴ）によって公開されている暗号ハッシュ関数のファミリであるセキュアハッシュアルゴリズムを用いて生成される。このようなアルゴリズムには、以下が含まれる：ＳＨＡ－０：オリジナルバージョンの１６０ビットハッシュ関数に適用されるレトロニム；ＳＨＡ－１：初期のＭＤ５アルゴリズムに似た１６０ビットのハッシュ関数；ＳＨＡ－２：ＳＨＡ－２５６及びＳＨＡ－５１２として知られる異なるブロックサイズを持つ２つの類似したハッシュ関数のファミリ；それらはワードサイズが異なっている：ＳＨＡ－２５６は３２ビットワードを使用し、ＳＨＡ－５１２は６４ビットワードを使用している；ＳＨＡ－２２４、ＳＨＡ－３８４、ＳＨＡ－５１２／２２４、及びＳＨＡ－５１２／２５６として知られる各標準の短縮版もある；ＳＨＡ－３：以前はＫｅｃｃａｋと呼ばれていたハッシュ関数；ＳＨＡ－２と同じハッシュサイズをサポートし、その内部構造は他のＳＨＡファミリとは大きく異なる；対応する規格は、ＦＩＰＳ ＰＵＢ １８０（オリジナルのＳＨＡ）、ＦＩＰＳ ＰＵＢ １８０－１（ＳＨＡ－１）、ＦＩＰＳ ＰＵＢ １８０－２（ＳＨＡ－１、ＳＨＡ－２５６、ＳＨＡ－３８４、及びＳＨＡ－５１２）である；ＮＩＳＴは、ドラフトＦＩＰＳパブリケーション２０２、ＳＨＡ－３標準を、Ｓｅｃｕｒｅ Ｈａｓｈ Ｓｔａｎｄａｒｄ（ＳＨＳ）とは別に更新している。

本発明による方法では、第２のデータセット３は、好ましくはＳＨＡ２５６アルゴリズム、ＳＨＡ３－２５６アルゴリズム、又はＳＨＡ３－５１２アルゴリズムによって生成される、上述のハッシュ関数の１つを用いて、好ましくはデジタルファイルのハッシュ（又はデジタルファイル自体）及びデジタルファイルの出所に対応する秘密鍵（上で第２のデジタル鍵と呼ばれる）の関数として計算される、デジタルファイルのハッシュのデジタル署名を含んでいる。典型的には、署名関数は、ブロックチェーンプロトコルに埋め込まれた関数であり、ブロックチェーントランザクションに署名するために使用される（例えば、ビットコインについての適切な説明は、以下に記載されている、ｈｔｔｐｓ：／／ｅｎ．ｂｉｔｃｏｉｎ．ｉｔ／ｗｉｋｉ／Ｅｌｌｉｐｔｉｃ＿Ｃｕｒｖｅ＿Ｄｉｇｉｔａｌ＿Ｓｉｇｎａｔｕｒｅ＿Ａｌｇｏｒｉｔｈｍ）。ハッシュは、出力として一連の数字を与える他の既知の暗号アルゴリズムを使用して生成することもできる。詳細は以前の段落に記載されている。デジタルファイルのハッシュの典型的なデジタル署名は、このデジタルファイルのハッシュ及びデジタルファイルの署名者の秘密鍵の関数である。署名者の前記秘密鍵に対応する公開鍵を、第２のデータセット３に追加することができる。

第２のデータセット３がデジタルファイルのハッシュのデジタル署名である場合、第２のデータセット３は、１３０ディジット、好ましくは１３０ｈｅｘディジット（１２８ディジットは楕円曲線暗号を使用して計算されたデジタル署名であり、２ディジットはプレフィックスであり、計算ノードによって追加される）のサイズを有することができる。

本発明に係る方法の好ましい態様では、第１のデータセット2に関連して、以下の情報：前記工程ｅ）で生成された前記トランザクションに対応するトランザクションハッシュ、ブロックハッシュ、ブロックハイト、及び、前記工程ｇ）で言及された前記ブロックに対応する登録のブロックタイムスタンプが別個のデータベースに格納される。このデータは、ブロックチェーンデータベースに永続的又は一時的に接続されたサーバ又はコンピュータ上の別のデータベースに格納することができる。前記別個のデータベースは、別個のコンピュータ又はサーバに、複製又は転送及び格納することができる。データベースは、あらゆる方法で変更することができ、ブロックチェーンのようなインクリメンタルデータベースである必要はない。複製、書き込み、削除、読み取り、編集、統合など、レコードに対する任意の操作が可能である。前記データベースはまた、デジタルファイル（デジタル財）に関する追加情報、例えば、ファイルサイズ、ファイルタイプ、ファイル所有者、ファイル作成者、ファイルバージョン、ファイル要約、ファイル内容、デジタル財全体、又はファイル等を格納することができる。別個のデータベースは、デジタル財の出所に関する追加情報、例えば、ノードのＩＰアドレス、ブロックチェーンアドレス、当該デジタル財の著者又は所有者であるユーザのＩＤ又は名前、所有者の数、ブロックチェーンに送信する時刻、ブロックチェーン内のブロックの登録のタイムスタンプ、ブロックチェーンタイプ等を格納することができる。もちろん、このすべての情報は、ブロックチェーンデータベース自体に保存することもできる。しかしながら、この情報を、別個の、好ましくは専用のデータベースに登録する利点は、特定のデジタルファイルに関する情報が、例えばその検証の目的のために求められるときに、この情報を迅速に検索できることである。専用の別個のデータベースからの情報の取得は、ブロックチェーンデータベースからの取得よりもはるかに高速な場合がある。別個のデータベースから検索された情報は、ブロックチェーンデータベース内の関連するブロック及びトランザクションを見つけるために使用することができ、トランザクションには、デジタルファイルの内容及び出所に関する完全な情報が、関連する登録タイムスタンプと共に格納されている。

したがって、本発明は、上記の登録方法に基づいて、テストデジタルファイルを検証するための方法を提案する。ここで、「検証」とは、テスト用デジタルファイルの内容の検証、デジタルファイルの出所の検証、及び登録タイムスタンプの検証を意味する。テストデジタルファイルは、任意のデジタルドキュメント／デジタルファイルであってもよい。

本発明によれば、最初に、ユーザは、検証のためにテストデジタルファイル（テストドキュメント）を提供する。テストデジタルファイルの真正性の検証は、テストデジタルファイルのハッシュを計算し、このテストデジタルファイルのハッシュが、上述のデータ登録方法の結果としてブロックチェーンデータベースのブロックに予め登録されているデジタルファイルのハッシュである第１のデータセット２と一致するかどうかをチェックすることによって行われる。肯定の場合、テスト用デジタルファイルを提供したユーザに確認（ｃｏｎｆｉｒｍａｔｉｏｎ）が送信される。前記確認は、テストデジタルファイルの内容に関する情報を含み、任意選択的に、テストデジタルファイルの出所に関する情報及び／又はブロックの登録のタイムスタンプに関する情報を含んでいる。

言い換えると、この検証方法では、テストデジタルファイルの次の３つの重要な機能を検証することができる：
ＷＨＡＴ－テストドキュメントの内容。
ＷＨＯ－テストデジタルファイルの出所／所有者。例えば、楕円曲線暗号（ＥＣＣ）を使用する場合、所有者（即ち、テストドキュメントのハッシュの署名者）を確立するために、所有者は任意のランダムなストリングに自分の秘密鍵で署名する必要があり、これにより、ランダムなストリング署名が作成される。典型的には、署名機能は、ブロックチェーンプロトコルに埋め込まれた機能である。このランダムなストリング署名に基づいて、所有者の秘密鍵に対応する公開鍵を計算することができる。これは、公開鍵回復操作と呼ばれる既知の手順であり、例えば以下で説明されている（ｈｔｔｐ：／／ｗｗｗ．ｓｅｃｇ．ｏｒｇ／ｓｅｃ１－ｖ２．ｐｄｆ）。

同様に、公開鍵は、テストドキュメントのハッシュの署名の関数として計算できる。このようにして取得された公開鍵が同一である場合、それは、同じ所有者がテストデジタルファイル及び前述のランダムストリング（又は、より正確には、両方の場合で同じ秘密鍵が署名に使用されたことの確認）の両方に署名したことの確認となる。同様に、これらの公開鍵は、デジタルファイルのハッシュの署名の関数として計算された公開鍵と照合することができ、上記の情報は、本発明のデータ登録方法に従って、ブロックチェーンデータベース又は別個のデータベースに予め格納されている。このようにして、ファイルの所有者の検証を実行することができる。

ＷＨＥＮ－ブロックチェーンデータベース内の関連ブロックの登録タイムスタンプがチェックされ、返却される。

本発明の好ましい実施形態では、ユーザは、ウェブブラウザを介して（例えば、ファイルをウェブフォームのフィールドにドラッグ及びドロップすることによって）、テストデジタルファイルを提供する。同様に、上記のような検証手順（確認）の結果は、ウェブブラウザを介してユーザに提供されることが好ましい。しかしながら、他の通信手段をウェブブラウザの代替手段として又はウェブブラウザと並列に使用してもよい。例えば、ユーザは、ウェブブラウザを介して検証用のテストファイルを送信し、検証結果を電子メールで受信することができる。或いは、ユーザは、電子メール等で検証用のテストファイルを提出し、検証結果を電子メール等で受け取ることもできる。

本発明による検証方法の好ましい代替の実施形態では、前述の段落（すなわち、ユーザが検証のためにテストデジタルファイルを提供し、テストファイルのハッシュが計算される）で説明したように同様の工程が実行されるが、次に、チェック工程では、テストデジタルファイルのハッシュが、前述のデータ登録方法の結果として以前に前記別個のデータベースに格納されたデジタルファイルのハッシュである第１のデータセット２と一致するかどうかがチェックされる。肯定の場合、前の段落で説明したように、確認がユーザに送信される。

上記検証処理において、テストデジタルファイルのハッシュが複数のデータと一致する場合の検証方法：テストデジタルファイルのハッシュが複数の第１のデータセットと一致する場合、１つの選択されたタイムスタンプを有するトランザクションに対応する情報のみが、ユーザに対する確認を生成するための基礎として使用される。一実施形態では、前記１つの選択されたタイムスタンプは、最も古いタイムスタンプである。これは好ましいオプションであるが、他の実施形態も除外されず、例えば、全ての新しいレコードも返却され得る。

上述の方法は、コンピュータプログラム製品の形態を有することができ、メモリスティック、ＣＤ、コンピュータのハードドライブ若しくはインターネットサーバなどのコンピュータ可読媒体に格納されたプログラムコード、又は、異なるサーバに格納された命令のアセットとして格納されたプログラムコード、好ましくは、ユーザのコンピュータ上に、又はユーザ操作のために構成されたユーザインタフェース及び必要に応じてネットワーク接続のためのネットワークインターフェースを有するサーバ上に、前記方法を実行するように構成されたウェブツール製品を含む。

本発明による方法の好ましい実施形態を以下に説明する。特に前述の教示を考慮して、本実施形態の変形が可能であることが理解されるべきである。

ブロックチェーンにデータを登録する手順
このプロセスは、ユーザがユーザ端末のメモリにデータをアップロードすることから始まる。データは、ハッシュ関数ＳＨＡ－２５６によって処理される。ＳＨＡ－２５６は、データをエンコードするために公開されているアルゴリズムである。これは暗号ハッシュ関数であり、そのタスクは、任意のサイズのデータを、この特定のブロックチェーン標準で使用される標準データコンテナのサイズに対応するサイズのビット列にマップすることである。ビットコインやダッシュなどの幾つかのブロックチェーン標準では、標準データコンテナは、その標準固定サイズ（２５６ビット、６４ｈｅｘ文字に等しい）を有している。この６４文字のハッシュを生成する鍵は、ハッシュからデータを再作成できないこと（一方向演算）と、同じハッシュを生成する他のデータが存在する可能性が非常に低いこと（衝突抵抗）である。ハッシュ化後、データはユーザ端末のメモリから除去され、ハッシュのみがユーザ端末のメモリに残る。

データをハッシュすると、ハッシュを入力として使用してブロックチェーン上のデータを検証する手順が実行される。データがブロックチェーンで見つかった場合、システムオペレータは、ユーザがデータの登録を続行できるかどうかを決定する。システムオペレータがユーザに続行を許可した場合、又は、ハッシュがブロックチェーン内で見つからなかった場合、ユーザは、ブロックチェーン内のデータの記録を続行するかどうかを尋ねられる。
ユーザが続行を選択すると、データのハッシュは、ユーザの秘密鍵（前述の第２の秘密鍵に対応する）を使用して署名される。データのハッシュのブロックチェーン署名の関数は、公開されているＥＣＤＳＡ（楕円曲線デジタル署名アルゴリズム）関数であり、鍵生成関数に対応し、データのハッシュ及びユーザの秘密鍵からデータのハッシュの署名を計算する。署名は１２８ｈｅｘ文字の長さの数であり、ユーザの秘密鍵もデータのハッシュも計算できない。計算された署名は、ユーザ端末のメモリに保存される。

署名を作成した後、安全なＡＰＩ接続を使用して、ユーザ端末のメモリをシステムオペレータコンピュータのメモリに送信する。

システムオペレータは、データのハッシュの署名がユーザの公開鍵と一致するかどうかをチェックする関数を実行する。これは、ＥＣＤＳＡファミリから公開されている関数であり、その入力は、ハッシュ、署名、及び公開鍵である。この関数は、メッセージ（ポジティブ又はネガティブ）をシステムオペレータに報告する。ネガティブの場合、メッセージはユーザに転送される。

ユーザ端末のメモリからのデータに互換性がある場合、システムオペレータは、ブロックチェーントランザクションの作成に進む。

トランザクションの作成
ブロックチェーントランザクションの作成は、このアドレスへのトランザクション入力（即ち、以前のトランザクションの未使用出力）に署名することと、提供されたデータからトランザクション出力を作成することと、トランザクションスクリプト及びそのハッシュを生成することとを含んでいる。それは、トランザクションの署名及び秘密鍵の保存の関数から始まる。これは、ＥＣＤＳＡの一部である公開されている関数である。これは、システムオペレータが受け取った未使用トランザクション出力に、対応する秘密鍵（第１の秘密鍵又は前述のノードの秘密鍵）で署名する。

入力に署名することに続いて、ブロックチェーンネットワークに永続的に記録されることが意図されたデータを含むトランザクションの出力が構成される。このようなデータは、データのハッシュ、データのハッシュに対するユーザの署名、及び、任意選択的に、一意のユーザ識別子及びパブリックノートである。この関数は、次の要素を接続して、１６進文字の長い文字列を作成することから始まる： データのハッシュ、セパレータ（例えば０１）、ハッシュの署名、セパレータ（例えば００～ｆｆの後続する要素のサイズ）、一意のユーザ識別子の１６進表記、セパレータ、及び、最後に、データパブリックノートの１６進表記。生成されたストリングは、その後４０文字（１６０ビット）の長さのセクションに分割され、必要に応じて最後の部分にゼロ（又はその他の１６進文字）が追加されて、必要なサイズが達成される。４０ｈｅｘ文字のセクションの各々は、現在作成されているトランザクションの受信者となる架空の存在しない公開鍵の最後のハッシュ１６０である。本項で説明するデータフレーム内のデータの特定の順序は、一例として示されている。データのハッシュ、ハッシュの署名、及び、任意選択的に、一意のユーザＩＤの１６進表記のデータが１６進文字の長いストリングに含まれている限り、その他の順序も可能である。何れにしても、システムオペレータは、データフレームを正しく作成し、後で（例えば検証を実行するために）正しく読み取ることができるように、データフレームの構造（即ち、データフレーム中のデータの順序）を知っていなければならない。

出力のハッシュ１６０を生成した後、上記手順は、システムオペレータの署名及びシステムオペレータの公開鍵を使用して標準Ｐ２ＰＫＨトランザクションスクリプトを作成することに進む。この公開鍵は、入力スクリプトに対しては以前に署名された出力に対応し、出力スクリプトに対しては以前に生成されたハッシュ１６０ストリングスに対応する。この出力スクリプトでは、各出力アドレスが最小許容量の暗号通貨（例えばビットコインの場合、ビットコインコア０．１４．１から５４３０Ｓａｔｏｓｈｉ）を受け取る。

スクリプトは、ｈａｓｈ２５６関数によって処理される。これは、データをエンコードするために公開されているアルゴリズムである。ハッシュ２５６は、任意のサイズのデータを６４ｈｅｘ文字の固定サイズのビットストリングにマップする暗号化ハッシュ関数である。生成されたハッシュは、システムオペレータのメモリに保存される。

ブロックチェーンへのトランザクションの追加
トランザクションを作成した後、それがブロックチェーンに登録される。まず、トランザクションをブロックチェーンに提出する関数から始まる。この関数は、前に作成されたトランザクションスクリプトをブロックチェーンノードに送信する。

指定された時間（例えば３０分）が経過すると、システムオペレータは、トランザクションが最近のブロックに追加されたかどうかをブロックチェーンノードに照会することによって、トランザクションがブロックチェーンに追加されたかどうかをチェックする。答えが否定的な場合、システムオペレータは、ブロックチェーンに送信するトランザクションの機能に戻る。トランザクションがブロックチェーンに正常に追加された場合、トランザクションの詳細は、ブロックチェーンからシステムオペレータコンピュータのメモリにインポートされる。

これらの２組のデータは、ブロックチェーンからのデータがシステムオペレータのデータベースからのデータと一致するかどうかをチェックする機能において比較される（前述の別個のデータベースに対応）。関数が否定的なメッセージを返した場合、それをユーザに転送することができる。関数の結果がポジティブの場合（即ち、ブロックチェーンからのデータがシステムオペレータのデータベースからのデータと一致しない場合）、トランザクションの詳細がシステムオペレータのデータベースに送信される。

本発明の大きな利点は、登録（上述）がユーザから独立してシステムオペレータによって行われ、且つ、システムオペレータが本方法によって登録されるデータを見ないことである。本発明の方法によれば、内容、出所／ソース、及びタイムスタンプに関するデータが第１のエンティティによってブロックチェーンデータベースに登録されたデジタルドキュメントを、通信ネットワークを介して、エンティティ間で安全に送信することができる。例えば、デジタルドキュメントは、インターネットを介して第１のエンティティから第２のエンティティに送信することができる。

ブロックチェーン内のデータの検証手順
検証の手順は、ユーザがブロックチェーンで検証するデータをアップロードすることから始まる。提供されたデータは、ハッシュ関数ＳＨＡ－２５６によって処理され、データ自体は削除されてもよいが、データのハッシュは保存される。

ハッシュが生成されると、本手順は、システムオペレータのデータベース内でハッシュを検索することに移行する。これは、データのハッシュがシステムオペレータのデータベースに含まれているかどうかをチェックする関数を実行することによって行われる。これは関数であり、そのタスクは、データのハッシュがデータベースに存在するかどうかをチェックすることである。それは、適切なクエリを使用して、ハッシュが登録されているかどうかをデータベースに確認する。この関数は、ハッシュがデータベースに存在する場合には、正のメッセージをユーザ及び／又はシステムオペレータに報告し、そのデータベースに登録されているハッシュに対応するデータをアップロードし、そうでない場合には、負のメッセージをユーザ及び／又はシステムオペレータに報告する。

報告されたメッセージが肯定的である場合、データのハッシュに割り当てられたデータは、ユーザ端末のメモリに報告される。その後、ユーザは、システムオペレータデータベースで指定されたブロックチェーンブロック内にハッシュが存在するかどうかのチェックを続行するかどうかを決定することができる。ユーザが継続を決定した場合、システムオペレータは、指定されたブロック内のハッシュを検索し、データの完全性をチェックする手順を実行する。

本手順から肯定メッセージが返された場合、ユーザは、データの所有権の確認を続行することができる。次に、データの所有者を識別して検証する手順が呼び出される。

データのハッシュがシステムオペレータのデータベース内に見つからない場合、又は、そのデータベース内で指定されたブロック内のデータが検証対象のデータと一致しない場合、ユーザは、ハッシュがブロックチェーン内に登録されたことがあるかどうかのチェックを続行するかどうかを決定することができる。ユーザが続行を選択すると、データのハッシュがブロックチェーンに追加されたかどうかをチェックする機能が実行される。ハッシュがブロックチェーン内で見つかった場合、システムオペレータのデータベースは、このハッシュがブロックチェーン内で見つかったトランザクションに関する情報で更新され、ユーザは所有権の検証を続行することを選択することができる。

指定されたブロック内のハッシュの検索及びデータの整合性のチェック
この手順は、データのハッシュが指定されたブロックチェーンブロックに追加されているかどうかをチェックする機能から始まる。これは、指定されたブロックチェーンブロック内のトランザクションのスクリプトにデータのハッシュが存在するかどうかをチェックするための関数である。

この関数の入力は、ブロックの詳細（ブロックチェーン識別子、ブロックハイト、及びブロックハッシュ）並びにデータのハッシュである。

この関数は、（ブロックチェーン識別子で指定されたブロックチェーンの）ブロックチェーンノードに対して、指定されたブロックに格納されているすべてのトランザクションのハッシュを問い合わせる。受信したトランザクションハッシュごとに、この関数は、元のトランザクションスクリプトを要求する。このようなスクリプトから、１つの長い１６進ストリングを受け取るために、出力公開鍵のハッシュ１６０が取得され、接続される。最初のｎ文字は、データのハッシュの候補である（ここで、ｎはハッシュ関数が生成するハッシュのサイズであり、例えば、ＳＨＡ－２５６の場合はｎ＝６４である）。候補が元のハッシュと等しい場合、肯定メッセージが報告され、データのハッシュが見つかったトランザクションデータ（つまり、ハッシュ及びその元のスクリプト）がシステムオペレータコンピュータのメモリに送信される。元のハッシュと一致する候補がない場合、関数は否定的なメッセージを報告する。

肯定メッセージが報告された場合、システムオペレータは、システムオペレータのデータベースからのデータがブロックチェーンからのデータと一致するかどうかをチェックする機能を実行し、この機能は肯定メッセージ又は否定メッセージの何れかを報告する。

データのハッシュがブロックチェーンに追加されているかどうかをチェックする関数
データのハッシュがブロックチェーンに追加されたことがあるかどうかをチェックする関数は、ハッシュがブロックチェーンに登録されたことがあるかどうかを判断するための関数である。ハッシュが見つかった場合、関数は、データのハッシュが登録されているブロック及びトランザクションハッシュの詳細を返すべきである。例えば、署名、システムオペレータの公開鍵、パブリックノートなど。

この関数の唯一の入力は、検証されるデータのハッシュである。
システムオペレータがデータのハッシュを登録するブロックチェーンデータベースごとに、関数は、すべてのブロックのハッシュに適したブロックチェーンノードを照会する。取得したブロックハッシュごとに、この関数は、ノードにブロックの詳細を照会する（例：ブロックハッシュ及びブロックハイト）。

この関数は、ブロックの詳細（ブロックチェーン識別子、ブロックハイト、ブロックハッシュ）及びデータのハッシュを引数として指定したブロックチェーンブロックにデータのハッシュが追加されたかどうかをチェックする関数を呼び出す。出力が肯定的で、正のメッセージ及びトランザクションデータが返された場合、関数は、正のメッセージ及びブロックの詳細をトランザクションデータと共に報告する。データのハッシュが指定されたブロックチェーンブロックに追加されたかどうかをチェックする関数が否定メッセージを報告した場合、その関数は、次のブロックに対して呼び出される。ブロックチェーンデータベース内のどのブロックにもハッシュが見つからない場合、データのハッシュがブロックチェーンに追加されたことがあるかどうかをチェックする関数は、否定メッセージを報告する。

前述の方法の適用例：「ワンドロップ」

以下では、データ登録及びデータ検証の前述の方法の特に有用なアプリケーションについて説明する。前述したようにブロックチェーンデータベースに登録されているデジタルファイル、及び、前述したように検証されているテストデジタルファイルは、本例では「ワンドロップ」ドキュメントと呼ばれる特定のドキュメントである。ここに示したプロセスの単純さ及び利点は、オンボーディングプロセスを含むマネーロンダリング対策に関連する規制及び手続き、信用履歴及び財務状況の特定、並びに以下の点から明らかである：

マネーロンダリング対策－犯罪の収益を代表する共謀犯罪者と、脱税、制裁回避、窃盗、偽造、詐欺などの前提犯罪との間の不正な価値の流れを阻止、中断、検出するために適用されるシステムと制御のプロセス。

オンボーディングプロセス－クライアント又は関係（ＫＹＣを含む）に関連するすべてのリスクを評価するプロセスで、これが異常で報告可能かどうかを判断するために、クライアントの行為及び取引全体を評価する必要がある。オンボーディングプロセスでは、義務を負ったエンティティは、関係に入る前にリスクを評価し、その後もトリガーイベントや疑わしい活動などに応じて、継続的にリスクを評価する必要がある。これは、顧客のリスクの変化を評価及び監視するための継続的なプロセスである。

ＫＹＣ（Ｋｎｏｗ Ｙｏｕｒ Ｃｌｉｅｎｔ）－氏名及び住所等の特定情報を通じた自然人、法人又は法的アレンジメントの特定及び検証、並びに詐欺、不実表示等を特定するためのこれらの詳細の検証。

「ワンドロップ」アプリケーションプロセスの説明：

１．オンボーディングプロセスを実施した、又は、オンボーディングサブジェクトのオンボーディングプロセスに関するオンボーディングサブジェクトのデータをこのオンボーディングサブジェクト上に保持している第１のエンティティ（「オンボーディングプロバイダ」、例えば銀行）のクライアント（「オンボーディングサブジェクト」）は、ソースノード（例えば、オンボーディングプロバイダのサーバ）から、宛先ノード（例えば、オンボーディングサブジェクトの端末）に、「ワンドロップ」ドキュメントを送信又はダウンロードし、前記「ワンドロップ」ドキュメントは、
（ａ）前記オンボーディングサブジェクトの関連する個人データ、及び
（ｂ）前記オンボーディングサブジェクトのトランザクション履歴
を含み、
情報（ａ）及び／又は（ｂ）は、データの受信者（「オンボーディングテイカー」）によって必要とされ、その要件に沿ってデータを検証した後、次の目的で使用される：
（ａ）オンボーディングサブジェクトを特定する；又は
（ｂ）デリバリのためにオンボーディングサブジェクトのアドレスを特定する；又は
（ｃ）オンボーディングサブジェクトの信用履歴及び財政状態を特定する；又は
（ｄ）オンボーディングプロバイダによって実行されたオンボーディングプロセスを受容し、結果的に、オンボーディングプロバイダによって実施されたオンボーディングプロセスの結果に（関連する法規制に従って）全体的に若しくは部分的に依存する；又は
（ｅ）オンボーディングテイカーを用いてオンボーディングサブジェクトのアカウントを設定する；又は
（ｆ）名前、住所、取引履歴などの「ワンドロップ」ドキュメントに含まれるデータに依存する。

なお、ここでいう「ワンドロップ」ドキュメントとは、例えば、オンボーディングサブジェクトの個人データ及び銀行口座における取引履歴を含む銀行取引明細書等であり得る。
オンボーディングサブジェクトは、個人、会社、又はその他の法人であってもよい。

２．オンボーディングプロバイダは、本特許出願で提供されるブロックチェーンデータベースにデータを登録する方法に従って、「ワンドロップ」ドキュメントをブロックチェーンデータベースに登録する。

この文脈では、「ワンドロップ」ドキュメントは、ブロックチェーンデータベースに登録されているデジタルファイルに対応する。

３．オンボーディングサブジェクトは、「ワンドロップ」ドキュメントをオンボーディングテイカーに提供する。

これは、例えば、「ワンドロップ」ドキュメントを、上記宛先ノード（例えば、オンボーディングサブジェクトの端末）から、第２の宛先ノード（例えば、オンボーディングテイカーのサーバ）に送信又はアップロードすることによって行うことができる。

４．前記「ワンドロップ」ドキュメントを所有したオンボーディングテイカーは、本特許出願で提供されるデータ検証の方法に従って、その真正性（即ち、発行者／所有者、タイムスタンプ及び内容）を検証する。

この文脈では、「ワンドロップ」ドキュメントは、検証されるテストデジタルファイルに対応する。

５．データ検証プロセスの結果、「ワンドロップ」ドキュメントが真正であり、オンボーディングテイカーが必要とする全てのデータが含まれていることが判明した場合、オンボーディングテイカーは、以下を行うために、「ワンドロップ」ドキュメントをオンボーディングサブジェクトに関連するデータの識別及び認証のための有効且つ十分なアイテムであるとみなすことができる：
（ａ）オンボーディングサブジェクトを特定する；又は
（ｂ）デリバリのためにオンボーディングサブジェクトのアドレスを特定する；又は
（ｃ）オンボーディングサブジェクトの信用履歴及び財政状態を特定する；又は
（ｄ）オンボーディングプロバイダによって実行されたオンボーディングプロセスを受容し、結果的に、オンボーディングプロバイダによって実施されたオンボーディングプロセスの結果に（関連する法規制に従って）全体的に若しくは部分的に依存する；又は
（ｅ）オンボーディングテイカーを用いてオンボーディングサブジェクトのアカウントを設定する；又は
（ｆ）名前、住所、取引履歴などの「ワンドロップ」ドキュメントに含まれるデータに依存する。

「ワンドロップ」ドキュメントは、次の場合に、真正と見なされてもよい：
（ａ）それが、適用される法令に従って、オンボーディングプロセスを実施するための信頼できる当事者と見なされる、特定のオンボーディングプロバイダによって発行されたものであること；及び
（ｂ）ドキュメントの内容が有効であり、オンボーディングプロバイダのシステムから生成された後に変更されていないこと；
（ｃ）タイムスタンプで示されているオンボーディングテイカーが必要とする場合には、それが、適切な時間枠内で、上記のブロックチェーンデータベースに登録されている（プロセスのステップ２を参照）こと。

オンボーディングプロバイダによって生成され、オンボーディングサブジェクトによって提示／提供される信頼できるドキュメント（「ワンドロップ」ドキュメント）に基づいて、オンボーディングプロバイダによって実行されるオンボーディングプロセスの全部又は少なくとも一部に依存すること（又は、言い換えると：オンボーディングテイカーによるオンボーディングプロセスの全部又は一部の放棄）は、オンボーディングテイカー側の多くの作業（及び、それゆえ、スタッフ、費やされる時間、計算能力などのリソース）を節約する。これは、ワンドロップドキュメントが信頼できる場合、すなわち、そのソース、内容、及びタイムスタンプが信頼できる場合にのみ可能である。ドキュメント（デジタルファイルである「ワンドロップドキュメント」）のこれら３つの特徴（ソース、内容、タイムスタンプ）は、本特許出願において提供されるデータ登録及びデータ検証方法によって保証される。

Claims (19)

1. ブロックチェーンデータベースにデジタルドキュメントをデジタルファイルとして登録する方法であって、データベーストランザクションは固定サイズを有し得る標準データコンテナで構成され、前記ブロックチェーンデータベースの少なくとも一部を格納するための１つ又は複数の格納ノードと、前記ブロックチェーンデータベース内のトランザクションを承認するための１つ又は複数の承認ノードと、前記ブロックチェーンデータベース内のトランザクションを生成するための第１のコンピュータとを含んだシステムにおいて、前記第１のコンピュータは前記ブロックチェーンデータベースへのアクセスを有し、且つ、第１の秘密鍵へのアクセスを有しており、
   ａ）前記デジタルファイルの内容に関する第１のデータセット（２）を提供する工程と；
   ｂ）前記デジタルファイルの出所に関連する第２のデータセット（３）を提供する工程と；
   ｃ）第１のデータセット（２）、第２のデータセット（３）、ヘッダ（１）、及びサフィックス（４）をデータフレームに統合することによって第３のデータセット（５）を生成する工程であって、前記ヘッダ（１）は、前記第３のデータセットの構造に関する及び前記第１のデータセットのサイズに関する情報を含んでいてもよく、一方、前記サフィックス（４）のサイズは、前記データフレームのサイズが前記ブロックチェーンデータベースで使用される前記標準データコンテナのサイズの倍数になるように調整される工程と；
   ｄ）前記第３のデータセット（５）を整数Ｎ≧１個の同一サイズの部分に分割する工程であって、前記サイズは前記ブロックチェーンデータベースで使用される前記標準データコンテナのサイズに対応している工程と；
   ｅ）前記工程ｄ）で得られたＮ個の部分全てについて、単一のブロックチェーントランザクションを、前記第１のコンピュータ又は前記第１のコンピュータに接続された中間コンピュータ及び前記１つ又は複数の承認ノードによって、生成する工程であって、前記第１の秘密鍵によって前記トランザクションに署名し、前記トランザクション及び前記第１の秘密鍵に一致する第１の公開鍵を承認のために前記１つ又は複数の承認ノードに送信する工程と；
   ｆ）前記１つ又は複数の承認ノードから前記トランザクションの承認を取得する工程と；
   ｇ）前記工程ｆ）で承認されたトランザクションを、前記１つ又は複数の格納ノードによって登録タイムスタンプと共に前記ブロックチェーンデータベースのブロックに登録する工程と
   を含み、
   前記第２のデータセット（３）は、前記デジタルファイルのハッシュのデジタル署名を備え、
   前記ブロックチェーンデータベース内の前記デジタルファイルとしての前記デジタルドキュメントの登録は、第１のエンティティによって行われ、前記デジタルドキュメントは、前記第１のエンティティから第２のエンティティに送信される、方法。
2. 前記第１のデータセット（２）は、前記デジタルファイルである、請求項１に記載の方法。
3. 前記第１のデータセット（２）は、ＳＨＡ２５６アルゴリズム、ＳＨＡ３－２５６アルゴリズム、又はＳＨＡ３－５１２アルゴリズムによって生成された前記デジタルファイルのハッシュである、請求項１に記載の方法。
4. 前記第１のデータセット（２）は、前記ＳＨＡ２５６アルゴリズムによって生成された前記デジタルファイルのハッシュであって、６４ディジット、６４ｈｅｘディジット、若しくはこれらの倍数のサイズを有しているか、又は、前記ＳＨＡ３－２５６アルゴリズムによって生成された前記デジタルファイルのハッシュであって、６４ディジット、６４ｈｅｘディジット、若しくはこれらの倍数のサイズを有しているか、又は、前記ＳＨＡ３－５１２アルゴリズムによって生成された前記デジタルファイルのハッシュであって、１２８ディジット、１２８ｈｅｘディジット、若しくはこれらの倍数のサイズを有している、請求項３に記載の方法。
5. 前記第２のデータセット（３）に含まれる前記デジタルファイルの前記ハッシュの前記デジタル署名は、前記デジタルファイルの前記ハッシュと、前記デジタルファイルの出所に対応する秘密鍵との関数として計算される、請求項１乃至４の何れか１項に記載の方法。
6. 前記第２のデータセット（３）は、前記デジタルファイルの前記ハッシュの前記デジタル署名であって、１３０ディジット又は１３０ｈｅｘディジットのサイズを有している、請求項５に記載の方法。
7. 前記ヘッダ（１）は、６ディジット又は６ｈｅｘディジットのサイズを有し、以下の情報：前記デジタルファイルのバージョン、前記デジタルファイルのタイプ、前記データフレームに格納されるべきハッシュの数、前記デジタルファイルの署名者の数を備えている、請求項１乃至６の何れか１項に記載の方法。
8. 前記ブロックチェーンデータベースはダッシュデータベース又はビットコインデータベースであり、前記標準データコンテナは４０ｈｅｘディジットのサイズを有している、請求項１乃至７の何れか１項に記載の方法。
9. 第１のデータセット（２）に関連して、以下の情報：前記工程ｅ）で生成された前記トランザクションに対応するトランザクションハッシュ、ブロックハッシュ、ブロックハイト、及び、前記工程ｇ）で言及された前記ブロックに対応する登録のブロックタイムスタンプが別個のデータベースに格納される、請求項１乃至８の何れか１項に記載の方法。
10. ｈ１）ユーザがテストデジタルファイルを提供する工程と；
    ｉ１）前記テストデジタルファイルのハッシュを計算する工程と；
    ｊ１）前記テストデジタルファイルの前記ハッシュと、請求項３乃至８の何れか１項に記載の方法の結果として前記ブロックチェーンデータベースの前記ブロック内に以前に格納された前記デジタルファイルの前記ハッシュである前記第１のデータセット（２）とが一致するかどうかをチェックする工程であって、前記ユーザへの肯定的な送信確認において、前記確認は、前記テストデジタルファイルの内容に関する情報を含んでいる工程と、
    を更に含んだ請求項３乃至８の何れか１項に記載の方法。
11. 前記テストデジタルファイルはウェブブラウザを介して前記ユーザから提供され、前記確認は前記ウェブブラウザを介して前記ユーザに送信される、請求項１０に記載の方法。
12. 前記確認は、前記テストデジタルファイルの出所に関する情報及び／又は登録のブロックタイムスタンプに関する情報を更に含んでいる、請求項１０又は１１に記載の方法。
13. ｈ２）ユーザがテストデジタルファイルを提供する工程と；
    ｉ２）前記テストデジタルファイルのハッシュを計算する工程と；
    ｊ２）前記テストデジタルファイルの前記ハッシュと、請求項９に記載の方法の結果として前記別個のデータベース内に以前に格納された前記デジタルファイルの前記ハッシュである前記第１のデータセット（２）とが一致するかどうかをチェックする工程であって、前記ユーザへの肯定的な送信確認において、前記確認は、前記テストデジタルファイルの内容に関する情報を含んでいる工程と、
    を更に含んだ請求項９に記載の方法。
14. 前記テストデジタルファイルはウェブブラウザを介して前記ユーザから提供され、前記確認は前記ウェブブラウザを介して前記ユーザに送信される、請求項１３に記載の方法。
15. 前記確認は、前記テストデジタルファイルの出所に関する情報及び／又は登録のブロックタイムスタンプに関する情報を更に含んでいる、請求項１３又は１４に記載の方法。
16. 前記テストデジタルファイルの前記ハッシュが、前記工程ｊ１）又はｊ２）において、それぞれ、複数の第１のデータセットと一致する場合、１つの選択された登録タイムスタンプを保持するトランザクションに対応する情報のみが、前記工程ｊ１）又はｊ２）のそれぞれにおける前記ユーザへの前記確認を生成するための基礎として使用される、請求項１０乃至１５の何れか１項に記載の方法。
17. 前記第１のエンティティによって前記デジタルドキュメントを生成することと、
    請求項１乃至９の何れか１項に記載された方法に従って、前記ブロックチェーンデータベースにおける前記第１のエンティティによる前記デジタルドキュメントの前記デジタルファイルとしての登録を行うことと、
    前記デジタルドキュメントを前記第１のエンティティから前記第２のエンティティに送信することと、
    請求項１０乃至１６の何れか１項に記載された方法に従って、前記第２のエンティティによるテストデジタルファイルとしての前記デジタルドキュメントの検証を行うことと、
    を含んだ請求項１乃至１６の何れか１項に記載の方法。
18. 前記デジタルドキュメントは、クライアントの個人データ及び前記クライアントのトランザクション履歴を含んでいる、請求項１７に記載の方法。
19. コンピュータ読み取り可能な記憶媒体であって、前記記憶媒体に格納されたプログラムコードを含み、前記プログラムコードは、請求項１乃至１８の何れか１項に記載の方法を実行するためのコンピュータ命令を含んでいる、コンピュータ読み取り可能な記憶媒体。

Images