(57)【特許請求の範囲】
【請求項１】
複数のノードを含む第１のノード群と、少なくとも１つのノードを含む第２のノード群とを備え、
前記第２のノード群に含まれるノードの少なくとも１つは、
前記第１のノード群に含まれるノードの少なくともいずれかに、情報を要求する要求信号であって、前記要求信号を送信するごとに生成される検証用の情報である検証情報を含む要求信号を送信する要求手段と、
前記要求信号に対して前記第１のノード群に含まれるノードのいずれかから送られてきた情報である応答情報を検証する検証手段とを有し、
前記検証手段は、
前記応答情報に関し、前記要求信号で要求した情報である所望情報もしくはそのダイジェストが含まれているか否か、正しい検証情報が含まれているか否か、当該応答情報に対して一方向性関数を適用して得られる値が、前記第１のノード群と前記第２のノード群との間で共通に定められる所定の規則を満たすか否か、および、前記要求信号を送信してから前記所望情報を得るまでにかかった時間である応答時間を判定し、それらの判定結果に基づいて、前記所望情報の信頼性の有無または信頼度を判断する
ことを特徴とする情報検証システム。
【請求項２】
前記第１のノード群に含まれるノードの少なくとも１つは、
前記第２のノード群に含まれるノードのいずれかから送信された前記要求信号に対する前記応答情報として、当該応答情報が前記規則を満たすように設定されるノンスと、前記所望情報またはそのダイジェストと、前記要求信号に含まれていた前記検証情報とを含む情報を、要求元のノードに送信する応答手段と、
一方向性関数を用いて前記規則を満たす前記ノンスの値を探索する探索手段とを有する
請求項１に記載の情報検証システム。
【請求項３】
前記要求手段は、同じ情報を要求する要求信号を複数回、前記第１のノード群に含まれるノードの少なくともいずれかに送信し、
前記検証手段は、複数回分の前記判定結果に基づいて、前記所望情報の信頼性の有無または信頼度を判断する
請求項１または請求項２に記載の情報検証システム。
【請求項４】
前記規則が、前記要求信号に含まれる前記検証情報によって指定される
請求項１から請求項３のうちのいずれか１項に記載の情報検証システム。
【請求項５】
前記所望情報の属性情報に基づいて、前記規則が定められている
請求項１から請求項４のうちのいずれか１項に記載の情報検証システム。
【請求項６】
前記検証手段は、前記所望情報の属性情報に基づいて、前記応答時間の判定を行う
請求項１から請求項５のうちのいずれか１項に記載の情報検証システム。
【請求項７】
前記第２のノード群は、分散台帳システムにおける台帳管理ノードまたは前記台帳管理ノードが管理する分散台帳を参照可能なノードとして実装される複数のノードを含み、
前記要求手段は、前記分散台帳に含まれる情報に基づいて生成される検証情報を含む要求信号を送信し、
前記検証手段は、第１のノード群に含まれるノードから直接または前記第２のノード群に含まれる他のノードを介して間接的に得られる応答情報に関し、当該応答情報に含まれる検証情報の正しさを、当該検証情報が前記分散台帳に含まれる情報に基づいて生成されているか否かにより判定し、前記応答時間を、当該応答情報に含まれる検証情報が前記分散台帳のどの時点の情報に基づいて生成されているかおよびその時点から少なくとも当該応答情報を得た時点までの間に前記分散台帳に追加された台帳の数に基づいて判定する
請求項１から請求項６のうちのいずれか１項に記載の情報検証システム。
【請求項８】
複数のノードを含む第１のノード群が管理する情報の信頼性を判断するための情報検証装置であって、
前記第１のノード群に含まれるノードの少なくともいずれかに送信された、前記情報を要求する要求信号であって、前記要求信号を送信するごとに生成される検証用の情報である検証情報を含む要求信号に対して、前記第１のノード群に含まれるノードのいずれかから送られてきた情報である応答情報を検証する検証手段を有し、
前記検証手段は、
前記応答情報に関し、前記要求信号で要求した情報である所望情報もしくはそのダイジェストが含まれているか否か、正しい検証情報が含まれているか否か、当該応答情報に対して一方向性関数を適用して得られる値が、前記第１のノード群と少なくとも前記情報検証装置との間で共通に定められる所定の規則を満たすか否か、および、前記要求信号を送信してから前記所望情報を得るまでにかかった時間である応答時間を判定し、それらの判定結果に基づいて、前記所望情報の信頼性の有無または信頼度を判断する
ことを特徴とする情報検証装置。
【請求項９】
複数のノードを含む第１のノード群が管理する情報の信頼性を、前記第１のノード群とは異なる第２のノード群に含まれるノードが判断するための情報検証方法であって、
第２のノード群に含まれるノードが、
前記第１のノード群に含まれるノードの少なくともいずれかに送信された、前記情報を要求する要求信号であって、前記要求信号を送信するごとに生成される検証用の情報である検証情報を含む要求信号に対して、前記第１のノード群に含まれるノードのいずれかから送られてきた情報である応答情報を検証し、
前記応答情報を検証する処理で、前記応答情報に関し、前記要求信号で要求した情報である所望情報もしくはそのダイジェストが含まれているか否か、正しい検証情報が含まれているか否か、当該応答情報に対して一方向性関数を適用して得られる値が、前記第１のノード群と前記第２のノード群との間で共通に定められる所定の規則を満たすか否か、および、前記要求信号を送信してから前記所望情報を得るまでにかかった時間である応答時間を判定し、それらの判定結果に基づいて、前記所望情報の信頼性の有無または信頼度を判断する
ことを特徴とする情報検証方法。
【請求項１０】
複数のノードを含む第１のノード群が管理する情報の信頼性を、前記第１のノード群とは異なる第２のノード群に含まれるノードが判断するための情報検証プログラムであって、
前記第２のノード群に含まれるノードが備えるコンピュータに、
前記第１のノード群に含まれるノードの少なくともいずれかに送信された、前記情報を要求する要求信号であって、前記要求信号を送信するごとに生成される検証用の情報である検証情報を含む要求信号に対して、前記第１のノード群に含まれるノードのいずれかから送られてきた情報である応答情報を検証する検証処理を実行させ、
前記検証処理で、前記応答情報に関し、前記要求信号で要求した情報である所望情報もしくはそのダイジェストが含まれているか否か、正しい検証情報が含まれているか否か、当該応答情報に対して一方向性関数を適用して得られる値が、前記第１のノード群と前記第２のノード群との間で共通に定められる所定の規則を満たすか否か、および、前記要求信号を送信してから前記所望情報を得るまでにかかった時間である応答時間を判定させ、それらの判定結果に基づいて、前記所望情報の信頼性の有無または信頼度を判断させる
ための情報検証プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、他の装置が保持する情報の信頼性を評価する情報検証システム、情報検証装置、情報検証方法および情報検証プログラムに関する。
【背景技術】
【０００２】
ＰｏＷ（Proof of Work）と呼ばれるコンセンサスアルゴリズムがある。ＰｏＷでは、あるデータについて、そのデータを一方向性関数により処理したときに得られる値が予め決められた規則を満たすように、当該データ内に含まれるノンスと呼ばれる領域に設定する値を探す処理（以降、単にノンスを探す処理と呼ぶ）が行われる。【０００３】
このとき、一方向性関数として、例えば、ハッシュ関数を用いることができる。また、そのときの規則を、「ハッシュ値が閾値（ターゲット値）以下であること」とすることができる。一般に、ノンスを探す処理は一方向性関数の性質から効率の良く行うことができないため、当該処理を行う装置は、実際にはノンスに適当な値を設定して規則を満たすか否かを確認する作業を繰り返すこととなる。このような設定と確認の作業を多くのノードに並列して行わせ、最も早く規則を満たすノンスを見つけたノードが他のノードに情報を発信することにより、当該情報に基づいて全ノードに当該ノンスの値を含むデータの状態を確定させる（コンセンサスをとる）。【０００４】
ＰｏＷを利用したシステムの例として、分散台帳システムがある。特に、ブロックと呼ばれる所定のデータ構造を備えたデータをつなげた構成のデータ群（ブロックチェーン）を台帳とし、該ブロックチェーンを複数のノードが共有して管理する分散台帳システムがある。【０００５】
このような分散台帳システムでは、管理対象とする情報が発生すると、ブロックチェーンにその情報を記録したブロックを随時追加していく。このブロック追加の際に、ＰｏＷを用いて複数のノードでコンセンサスをとることにより、当該情報が信頼性の高い情報であることを示しながら複数のノード間で情報を共有させることができる。【０００６】
ブロックチェーンを構成する各ブロックは、自ブロックが予め定められた規則を満たすように値が設定されるノンスと、当該ブロックチェーンにおいて自ブロックより前に位置する一つ以上のブロックに基づく情報とを格納する領域（以下、前ブロック管理領域という）を持つ。以下、ブロックチェーンにおいて自ブロックより前に位置する一つ以上のブロックをまとめて前ブロックといい、そのうち直前に位置するブロックを直前ブロックという場合がある。なお、前ブロックは、より具体的には、自ブロックより前に情報が記録されたブロックであり、直前ブロックは、自ブロックの直前に情報が記録されたブロックである。【０００７】
各ブロックは、前ブロックに基づく情報として、例えば、直前ブロックに記録されている情報のハッシュ値を格納することができる。さらに、各ブロックは、自ブロックに関連づけられる何らかの情報、例えば、自ブロックにおいて管理対象とされる任意の情報を格納する領域（以下、自ブロックデータ領域という）を持つ。この場合、ノンスを探す処理では、前ブロック管理領域と自ブロックデータ領域とノンスとを含む自ブロックの領域に格納された情報が、予め所定の規則を満たすように、ノンスに設定する値が探索される。以下、ノンスを探す処理において規則が適用される領域であってノンス以外の領域を、そのブロックのデータ領域という場合がある。上記の例では、前ブロック管理領域と自ブロックデータ領域とを併せたものが、データ領域とされる。【０００８】
以下、台帳分散システムにおいて、ＰｏＷを行うノードを台帳管理ノードという。台帳管理ノードは各々、ブロックチェーンのコピーを保持する。【０００９】
あるノードがなんらかの情報をブロックチェーン（台帳）に記録させたい場合、そのノードが当該情報を台帳管理ノードに通知する。すると、台帳管理システムが備える台帳管理ノードによるＰｏＷを経て、ブロックチェーンにブロックが追加される。【００１０】
具体的には、台帳管理ノードは、情報が通知されると、当該情報をデータ領域（より具体的には自ブロックデータ領域）に格納したブロックを作成する。また、当該ブロックのデータ領域（より具体的には前ブロック管理領域）に、追加後に前ブロックとなる１つ以上のブロックに格納されている情報を基に生成したハッシュ値を格納する。その後、当該ブロックのハッシュ値がターゲット値以下となるノンスを探索する。【００１１】
各台帳管理ノードが上記処理を同時並列的に行い、最も早くＰｏＷを終えた台帳管理ノードが、ノンスが設定された当該ブロックを他の台帳管理ノードに通知する。ＰｏＷを終えた台帳管理ノードおよび、ＰｏＷを終えた台帳管理ノードからブロックを通知された各台帳管理ノードは、現在行っているＰｏＷの処理を終了し、保持しているブロックチェーンの末尾に当該ブロックを追加する。【００１２】
ＰｏＷを終えるタイミングは台帳管理ノードによって異なるため、多くの場合、ＰｏＷを終えたある１つの台帳管理ノードが作成したブロックが、全ての台帳管理ノードのブロックチェーンに追加される。したがって、全台帳管理ノードが同一のチェーンを持つこととなる。【００１３】
また、台帳管理ノードは、上記に加えて、ブロック作成時やＰｏＷを終えた台帳管理ノードからブロックが通知された際に、当該ブロックに含まれる情報を何らかの方法で検証することが可能である。検証した結果、問題がある場合には当該情報を含まずにブロックを作成することや、問題がある情報を含むブロックをブロックチェーンに追加しないといった処理が行われる。【００１４】
このようなＰｏＷを活用した分散台帳システムは、全ての台帳管理ノードに同じ情報を持たすことが可能となるだけでなく、台帳を改ざんすることが困難であるという特徴がある。一例として、悪意あるノードがブロックチェーン中のあるブロックの改ざんを試みた場合を考える。改ざんを検出されないようにするためには、改ざんを試みたブロック以降の全てのブロックのノンスを再設定しなければならない。上記の例でいえば、改ざんを試みたブロック以降の全てのブロックについて、ハッシュ値がターゲット値以下となるようなノンスを探索して設定しなければならない。この計算は一般に膨大な計算量を要する。また、探索している最中にも新たなブロックの追加が行われ得る。そのことから、悪意あるノードが改ざんを検出されないようにするためには、正常な台帳管理ノード群を上回る速さでノンスの再設定を行なわなければならず、悪意あるノードが仮に性能面で個々の台帳管理ノードを上回っていたとしても正規の台帳管理ノード群の数的有利さにより、現実にはそのような再設定は困難となる。【００１５】
ところで、あるノードから情報を取得するにあたって、当該情報が正規のものかといった情報の信頼性を評価する方法が求められている。そのような評価方法の一例として、送信側で情報に認証情報を付加して送信し、受信側がその認証情報の正当性を検証する方法が挙げられる。しかし、この方法は、通信経路上における改ざんの有無は検証できるが、送信側が悪意あるノードであった場合、そのノードによって改ざんされた情報の正当性を評価することはできない。【００１６】
情報の信頼性を評価する技術に関して、例えば、特許文献１には、複数のノード装置のうち一のノード装置の認証情報の正当性を、他の複数のノード装置が記憶している検証情報に基づいて検証する認証システムの一例が記載されている。特許文献１に記載の認証システムでは、第１のノードの認証情報の検証を依頼された第２のノードが、当該認証情報の検証を複数の第３のノードに依頼する。第３のノードの各々は、受信した認証情報と、自身で記憶している該認証情報の正当性の検証に用いる検証情報とに基づいて、該認証情報を検証し、その結果を第２のノードに返す。第２のノードは、第３のノードの各々からの検証結果と、該第３のノードの各々に対する信頼性を示す加重値とに、第１のノードを認証する。
【先行技術文献】
【特許文献】
【００１７】
【特許文献１】特開２００９−１６９８６１号公報
【発明の概要】
【発明が解決しようとする課題】
【００１８】
しかし、上記のような装置に対する認証情報を用いた方法は、情報を受け取る側の装置が、情報の送信元の装置の認証情報を検証する機能を持たなければならないという問題がある。【００１９】
仮に、特許文献１に記載された方法のように検証処理を代行する装置を別途設けたとしても、その代行装置の正当性を検証しなければならないといった新たな問題が生じる。認証情報の検証には、予め相手側装置に対応づけられる情報を保持しておくことが多く、相手側装置が予め特定されないようなケースには対応できない。【００２０】
課題は、取得先となる相手側装置に関して、事前に認証に用いる情報の対応づけなしに、取得した情報の信頼性が評価するのは困難であるという点である。【００２１】
相手側装置に関する情報の対応づけを要せずに情報の信頼性を評価する方法に関し、例えば、取得したい情報が複数の装置に共有されていれば、そのうちの一つの装置から情報を取得した際に、同じ内容の情報を保持している他の複数の装置に該情報を検証させることにより、該情報が多くの装置により承認されたものであって、一定の信頼性を有する情報であることを確認できる。【００２２】
しかし、情報を取得する装置がそのような多くの装置に対して、情報の検証を依頼してその結果を受信する方法では、情報を取得する装置と検証を行う装置との間の通信負荷が大きくなるという問題がある。例えば、ある第１のノード群が管理している情報を当該第１のノード群に属さない第２のノードが取得することを考える。この場合、当該第２のノードが、取得した情報が第１のノード群の多くのノードにより検証され、承認されたものであるかを少ない通信負荷で判断することは困難である。なお、ここでの通信負荷は、第１のノード群と第２のノードとの間の通信負荷を指す。【００２３】
なお、上記の問題は、第２のノードが、第１のノード群の各々に検証を依頼する場合だけでなく、以下のような場合にもあてはまる。例えば、複数の装置間で情報を安全に共有する仕組みとして、上述したような台帳管理システムのブロックチェーンが利用されていたとする。その場合、台帳管理ノードにより行われるＰｏＷを、ある情報が多くのノードに検証され、承認されたものかの判断の根拠に用いることができる。上述したとおり、台帳管理ノードはブロックの作成時やブロックの追加時に当該ブロックに含まれる情報を検証することができる。検証の結果、承認できない情報が当該ブロックから除外されたり、ブロック自体が破棄される。すなわち、悪意あるノードが、正常な台帳管理ノードに承認されないような不正な情報を含むブロックをブロックチェーンにつなげようとした場合、当該ブロックは正常な台帳管理ノードからは承認されないため、悪意あるノード（この場合、悪意ある台帳管理ノード）のみでＰｏＷを行うことになる。すると、ネットワーク中に、正常な台帳管理ノードによるＰｏＷを経た正常なブロックチェーンと、悪意ある台帳管理ノードのみによるＰｏＷを経た不正なブロックを含む不正なブロックチェーンの、２通りのブロックチェーンが存在することとなる。【００２４】
このとき、悪意ある台帳管理ノードの総計算能力に比べ、正常な台帳管理ノードの総計算能力が高ければ、正常な台帳管理ノードの管理する正常なブロックチェーンの方が不正なブロックチェーンに比べてブロックの追加頻度が高くなる。これは、正常な台帳管理ノード群の方が不正な台帳管理ノード群に比べてＰｏＷに要する時間が平均して短いためである。したがって、あるノードが、それらの台帳管理ノードが管理しているブロックチェーンに含まれている情報の信頼性を評価しようとした場合、より長いブロックチェーンに含まれる情報がより多くの台帳管理ノードに承認された情報であると判断することができる。言い換えると、より長いブロックチェーンに含まれる情報はより多くの台帳管理ノードによって承認されたものであることが期待できる。【００２５】
ところが、このようなブロックチェーンの特徴を利用して、情報の信頼性を評価しようとした場合、情報を受け取るノードも、ブロックチェーン全体を取得して全てのブロックのハッシュ値を確認する必要がある。しかも、信頼性の高い情報であればあるほど、当該ノードはより長いブロックチェーンを取得しなければならず、ブロックチェーン内の一部の情報の取得のために大きな通信負荷が生じる。【００２６】
なお、本発明が解決する課題はこれに限られない。本明細書中では、本発明が解決する他の課題についても明らかにされる。【００２７】
本発明は、上述した課題に鑑みてなされたものであり、他の装置が保持する情報の信頼性を、通信負荷を増加させずに、かつ取得先となる相手側装置に関する事前の情報の対応づけなしに、評価できる情報検証システム、情報検証装置、情報検証方法および情報検証プログラムを提供することを目的とする。
【課題を解決するための手段】
【００２８】
本発明による情報検証システムは、複数のノードを含む第１のノード群と、少なくとも１つのノードを含む第２のノード群とを備え、第２のノード群に含まれるノードの少なくとも１つは、第１のノード群に含まれるノードの少なくともいずれかに、情報を要求する要求信号であって、要求信号を送信するごとに生成される検証用の情報である検証情報を含む要求信号を送信する要求手段と、要求信号に対して第１のノード群に含まれるノードのいずれかから送られてきた情報である応答情報を検証する検証手段とを有し、検証手段は、応答情報に関し、要求信号で要求した情報である所望情報もしくはそのダイジェストが含まれているか否か、正しい検証情報が含まれているか否か、当該応答情報に対して一方向性関数を適用して得られる値が、第１のノード群と第２のノード群との間で共通に定められる所定の規則を満たすか否か、および、要求信号を送信してから所望情報を得るまでにかかった時間である応答時間を判定し、それらの判定結果に基づいて、所望情報の信頼性の有無または信頼度を判断することを特徴とする。【００２９】
また、本発明による情報検証装置は、複数のノードを含む第１のノード群が管理する情報の信頼性を判断するための情報検証装置であって、第１のノード群に含まれるノードの少なくともいずれかに送信した、情報を要求する要求信号であって、要求信号を送信するごとに生成される検証用の情報である検証情報を含む要求信号に対して、第１のノード群に含まれるノードのいずれかから送られてきた情報である応答情報を検証する検証手段を有し、検証手段は、応答情報に関し、要求信号で要求した情報である所望情報もしくはそのダイジェストが含まれているか否か、正しい検証情報が含まれているか否か、当該応答情報に対して一方向性関数を適用して得られる値が、第１のノード群と少なくとも情報検証装置との間で共通に定められる所定の規則を満たすか否か、および、要求信号を送信してから所望情報を得るまでにかかった時間である応答時間を判定し、それらの判定結果に基づいて、所望情報の信頼性の有無または信頼度を判断することを特徴とする。【００３０】
また、本発明による情報検証方法は、複数のノードを含む第１のノード群が管理する情報の信頼性を、第１のノード群とは異なる第２のノード群に含まれるノードが判断するための情報検証方法であって、第２のノード群に含まれるノードが、第１のノード群に含まれるノードの少なくともいずれかに送信した、情報を要求する要求信号であって、要求信号を送信するごとに生成される検証用の情報である検証情報を含む要求信号に対して、第１のノード群に含まれるノードのいずれから送られてきた情報である応答情報を検証し、応答情報を検証する処理で、応答情報に関し、要求信号で要求した情報である所望情報もしくはそのダイジェストが含まれているか否か、正しい検証情報が含まれているか否か、当該応答情報に対して一方向性関数を適用して得られる値が、第１のノード群と第２のノード群との間で共通に定められる所定の規則を満たすか否か、および、要求信号を送信してから所望情報を得るまでにかかった時間である応答時間を判定し、それらの判定結果に基づいて、所望情報の信頼性の有無または信頼度を判断することを特徴とする。【００３１】
また、本発明による情報検証プログラムは、複数のノードを含む第１のノード群が管理する情報の信頼性を、第１のノード群とは異なる第２のノード群に含まれるノードが判断するための情報検証プログラムであって、第２のノード群に含まれるノードが備えるコンピュータに、第１のノード群に含まれるノードの少なくともいずれかに送信した、情報を要求する要求信号であって、要求信号を送信するごとに生成される検証用の情報である検証情報を含む要求信号に対して、第１のノード群に含まれるノードのいずれかから送られてきた情報である応答情報を検証する検証処理を実行させ、検証処理で、応答情報に関し、要求信号で要求した情報である所望情報もしくはそのダイジェストが含まれているか否か、正しい検証情報が含まれているか否か、当該応答情報に対して一方向性関数を適用して得られる値が、第１のノード群と第２のノード群との間で共通に定められる所定の規則を満たすか否か、および、要求信号を送信してから所望情報を得るまでにかかった時間である応答時間を判定させ、それらの判定結果に基づいて、所望情報の信頼性の有無または信頼度を判断させることを特徴とする。
【発明の効果】
【００３２】
本発明によれば、他の装置が保持する情報の信頼性を、通信負荷を増加させずに、かつ取得先となる相手側装置に関する事前の情報の対応づけなしに、評価できる。
【図面の簡単な説明】
【００３３】
【図１】第１の実施形態の情報検証システムの構成の概要を示す説明図である。
【図２】第１の実施形態の情報取得ノード２の構成例を示すブロック図である。
【図３】ブロックのデータ構造を示す説明図である。
【図４】第１の実施形態の検証ノード１の構成例を示すブロック図である。
【図５】第１の実施形態の情報検証システムの全体の動作例を示すフローチャートである。
【図６】第１の実施形態の情報取得ノード２の動作例を示すフローチャートである。
【図７】第１の実施形態のＧＷ検証ノード１’の動作例を示すフローチャートである。
【図８】第１の実施形態の他の検証ノード１の動作例を示すフローチャートである。
【図９】第２の実施形態の情報検証システムの構成の概要を示す説明図である。
【図１０】第２の実施形態の情報取得ノード２の構成例を示すブロック図である。
【図１１】情報取得ノードグループ２０が管理するブロックチェーンと検証情報の関係を示す説明図である。
【図１２】第２の実施形態のＧＷ情報取得ノード２’の動作例を示すフローチャートである。
【図１３】第２の実施形態の他の情報取得ノード２の動作例を示すフローチャートである。
【図１４】本発明の各実施形態にかかるコンピュータの構成例を示す概略ブロック図である。
【図１５】本発明の情報検証システムの概要を示すブロック図である。
【図１６】本発明の情報検証システムの他の例を示すブロック図である。
【発明を実施するための形態】
【００３４】
以下、本発明の実施形態について図面を参照して説明する。なお、以下の説明における各実施形態は例示であり、単独で実施することもできるし、適宜組み合わせて実施することもできる。
【００３５】
［第１の実施形態］
図１は、第１の実施形態の情報検証システムの構成の概要を示す説明図である。本実施形態の情報検証システム１００は、複数の検証ノード１を含む検証ノードグループ１０と、少なくとも１つの情報取得ノード２とを備える。本実施形態では、検証ノードグループ１０は、情報取得ノード２が所望する情報を共有で管理しているノードからなるグループであるとする。なお、検証ノードグループ１０を、当該グループで管理対象とされる情報の正当性を検証する機能を少なくとも提供するノードからなるグループと捉えることも可能である。
【００３６】
本例において、検証ノード１の各々と情報取得ノード２はそれぞれ通信手段を有しており、通信ネットワークを介して相互に通信可能に接続されている。また、検証ノードグループ１０内では、検証ノード１の各々が、互いに、直接または他の検証ノード１を介して間接的に通信可能に接続されている。なお、情報取得ノード２は、少なくとも１つの検証ノード１と通信可能であればよい。なお、図１はあくまで例示であり、検証ノードや情報取得ノードの数はこれに限定されない。また、以下では、情報取得ノード２から情報取得要求を受け付けた検証ノード１を、ゲートウェイ（ＧＷ）検証ノード１’と呼ぶ場合がある。
【００３７】
本実施形態では、検証ノードグループ１０内で検証ノード１が共有して管理している情報を情報取得ノード２が取得し、該情報取得ノード２において、取得した情報が信頼性評価に関する所定の条件を満たした情報であるか否かを判断する方法について説明する。以下では、情報取得ノード２が検証ノード１に対して要求する情報を所望情報と呼ぶ。また、信頼性評価に関する所定の条件を満たした情報のことを高信頼情報と呼ぶ。当該所定の条件は、例えば、一定数以上の検証ノード１に承認されたことが示されるような条件であってもよい。
【００３８】
図２は、情報取得ノード２の構成例を示すブロック図である。図２に示すように、情報取得ノード２は、情報要求部２０１と、検証情報生成部２０２と、情報検証部２０３と、情報記憶部２０４とを含んでいてもよい。
【００３９】
情報要求部２０１は、検証ノード１のいずれかに情報を要求するとともに、検証ノード１のいずれかから、要求した情報（所望情報）を含むブロックを受信する。
【００４０】
図３は、ブロックのデータ構造を示す説明図である。本実施形態では、図３に示されるようなノンスと呼ばれる領域と任意のデータを格納する領域（データ領域）とを少なくとも含むデータ構造を「ブロック」と呼ぶ。ブロックの生成方法は後述するが、ブロックのデータ領域には所望情報を含ませることができる。
【００４１】
情報要求部２０１は、より具体的に、所望情報を検証するための情報である検証情報と、所望情報を特定可能な情報（所望情報の識別子など）とを少なくとも含む情報取得要求信号を、検証ノード１のいずれかに送信する。また、情報要求部２０１は、情報取得要求信号を送信した時刻を示す送信時刻情報と、情報取得要求信号に含ませた検証情報とを情報記憶部２０４に記憶させる。また、情報要求部２０１は、検証ノード１のいずれかから所望情報を含むブロックを受信すると、該ブロックを情報検証部２０３に通知する。
【００４２】
検証情報は、より具体的には、検証ノード１から送られるブロックにおけるノンスの抽選作業が情報取得要求を送信して以降に行われたことを確認するための情報である。
【００４３】
検証情報生成部２０２は、情報取得要求信号に含ませる検証情報を生成する。検証情報生成部２０２は、検証情報として、情報取得要求信号ごとに異なり、かつその変化が不規則である情報を生成することが好ましい。検証情報生成部２０２は、例えば、情報取得ノード２内の時刻をシードとして生成した乱数に基づいて検証情報を生成してもよい。なお、検証情報は乱数に基づいて生成される情報に限定されない。例えば、後述する第２の実施形態において、検証情報の他の例が示される。
【００４４】
情報検証部２０３は、検証ノード１から受信したブロックに含まれる所望情報の検証を行う。情報検証部２０３は、受信したブロックおよび情報記憶部２０４に記憶された情報に基づいて、所望情報の検証を行う。情報検証部２０３は、より具体的に、以下に示す判定条件に基づいて、所望情報の検証を行う。
【００４５】
・（Ａ１）ブロック内に、情報取得要求で指定した所望情報が存在していること
・（Ａ２）ブロック内に、情報記憶部２０４に記憶されている検証情報と一致する情報が含まれていること
・（Ａ３）ブロックが、検証ノードグループ１０との間で共通に定められている所定の規則を満たすこと
・（Ａ４）ブロックの受信が、情報取得要求信号を送信してから一定時間内に行われていること
【００４６】
情報検証部２０３は、上記の項目をそれぞれ確認し、これらの全ての項目が満たされている場合に受信した所望情報が高信頼情報であると判断する。なお、上記の各項目については後述する。
【００４７】
情報記憶部２０４は、各種情報を記憶する。例えば、情報記憶部２０４は、情報取得要求信号の内容と、送信時刻情報と、検証情報とを記憶する。情報記憶部２０４は、例えば、所望情報を特定可能な情報と対応づけて、送信時刻情報と、検証情報とを記憶してもよい。
【００４８】
また、図４は、検証ノード１の構成例を示すブロック図である。図４に示すように、検証ノード１は、外部向け情報共有部１０１と、検証ノード間情報共有部１０２と、ブロック生成部１０３と、抽選実行部１０４と、情報検証部１０５と、情報記憶部１０６とを含んでいてもよい。なお、機能部間の関係を実線で示しているが、これは例示であり、これに限定されない。
【００４９】
外部向け情報共有部１０１は、情報取得ノード２との情報交換を担う。より具体的には、外部向け情報共有部１０１は、情報取得ノード２からの情報取得要求の受け付けを行う。
【００５０】
外部向け情報共有部１０１は、情報取得要求を受け付けると、当該要求の内容をグループ内の検証ノード間で共有させるために、当該要求の内容がわかる情報を、検証ノード間情報共有部１０２に通知する。以下、簡単のため、検証ノード間で共有させる当該情報のことも、情報取得要求という。なお、情報取得ノード２から受信した情報取得要求をそのまま検証ノード１間で共有してもよいし、情報取得ノード２から受信した情報取得要求の一部の情報を変更、削除等したものや新たな情報を付加したものを検証ノード間で共有することも可能である。
【００５１】
また、外部向け情報共有部１０１は、検証ノード間情報共有部１０２より応答ブロックを受信すると、当該応答ブロックを情報取得ノード２に送信する。ここで、応答ブロックとは、情報取得要求に対応したブロックであり、ノンスに適切な値が設定され、かつ情報検証部１０５による検証用の条件を満たしたブロックをいう。
【００５２】
検証ノード間情報共有部１０２は、自ノードが属する検証ノードグループ１０内の検証ノード間での情報交換を担う。より具体的には、検証ノード間情報共有部１０２は、外部向け情報共有部１０１より通知された情報取得要求や、後述する抽選実行部１０４より通知された抽選完了済みのブロックや、他の検証ノードから受信したこれら情報を、適宜他の検証ノードに送信する。
【００５３】
なお、検証ノード間情報共有部１０２は、これらの情報を適宜、他の検証ノードに転送することによって、可能な限りグループ内の全ての検証ノードでこれらの情報を共有する。具体的な情報共有のアルゴリズムは多数存在するが、単純な方法としてはフラッディングにより情報を共有することができる。例えば、ある検証ノード１−Ａの検証ノード間情報共有部１０２は、他の検証ノード１−Ｂから信号を受信すると、その信号がそれまで転送したことがない信号であれば、隣接する検証ノード１−Ｃに転送する。これを検証ノード１の各々が行うことで、全ての検証ノード１に当該信号を通知することが可能となる。なお、情報取得要求や応答ブロックといった情報の共有は、必ずしも検証ノードグループ１０内の全ての検証ノードを対象としなくてもよい。高信頼度を証明するという観点では全ての検証ノードに転送されることが好ましいが、より多くの検証ノード１に転送される方法であれば、転送方法は特に問わない。
【００５４】
このとき、転送先となる検証ノード１の情報は、例えば、次のような方法により取得可能である。すなわち、所望情報を取得している全ての検証ノード１の情報を、特定のサーバなどで公開しておき、情報取得ノード２や検証ノード１の各々は、そのサーバにアクセスすることにより必要な情報を得てもよい。また、例えば、情報取得ノード２や検証ノード１の各々に、予め設定情報として、情報取得ノード２やＧＷ検証ノード、他の検証ノード１のアドレス情報といった、情報検証システム１００のトポロジ情報を与えておいてもよい。また、検証ノード１間は、既存のＰ２Ｐ（Peer to Peer）ネットワークで使用されている技術と同様の方法で認識することも可能である。
【００５５】
典型的には、このような転送先ノードの情報取得は、検証ノード１の各々に、検証ノードグループ１０内の他の全ての検証ノード１の情報（検証ノードリスト）を持たせることで実現可能である。この場合には、ある検証ノードが新たに検証ノードグループに加わる場合には、既にグループに加わっている検証ノードからリストを取得するとともに、当該リストに記載されている全ての検証ノードへと自ノードの情報を送信し、リストに加えてもらうことで、検証ノードリストを管理すればよい。また、検証ノードの各々は、必ずしも他の全ての検証ノードの情報を保持していなくてもよい。単純な例としては、各検証ノードは、転送経路における次ノードの情報を保持していればよい。また、他の例としては、各検証ノードは、隣接する１つ以上の検証ノードの情報（アドレス）を保持していればよい。また、上記の方法と同様の方法で、情報取得ノード２は、要求先の検証ノードの情報を取得することができる。
【００５６】
また、検証ノード間情報共有部１０２は、情報取得ノード２または他の検証ノード１から送信される情報取得要求に対して、自ノード内での処理を開始させる。より具体的には、検証ノード間情報共有部１０２は、外部向け情報共有部１０１を介して情報取得ノード２から、または他の検証ノード１から情報取得要求を受信すると、ブロック生成部１０３に当該要求を通知して、当該要求に対応するブロックを生成させる。また、検証ノード間情報共有部１０２は、要求内容を、情報記憶部１０６に格納する。
【００５７】
詳細は動作の説明で述べるが、ここで通知された情報取得要求を基に、ブロック生成部１０３によってブロックが生成され、抽選実行部１０４によってノンスを探す作業が、検証ノード１の各々において同時並列的に行われる。また、情報記憶部１０６に格納された情報取得要求の内容は、情報検証部１０５においてブロックの検証に用いられる。
【００５８】
さらに、検証ノード間情報共有部１０２は、他の検証ノード１から、情報取得要求に対応するブロックであってノンスが設定済みのブロック（以下、応答候補ブロックという）を受信すると、当該応答候補ブロックを情報検証部１０５で検証させ、承認するか拒絶するかの判断をさせる。検証ノード間情報共有部１０２は、承認すると判断された場合、抽選実行部１０４に抽選終了を通知する。一方、検証ノード間情報共有部１０２は、拒絶すると判断された場合、当該応答候補ブロックを破棄する。また、その場合において、検証ノード間情報共有部１０２は、当該応答候補ブロックを他の検証ノード１に転送しないようにしてもよい。情報検証部１０５で承認された応答候補ブロックは自ノードにおいて正式な応答ブロックとされる。
【００５９】
また、検証ノード間情報共有部１０２は、他の検証ノード１から受信した応答候補ブロックが情報検証部１０５で承認されて応答ブロックとなった場合、自ノードがＧＷ検証ノード１’であれば、外部向け情報共有部１０１に当該応答ブロックを通知する。当該応答ブロックは、その後、外部向け情報共有部１０１により、情報取得ノード２に送信される。
【００６０】
なお、検証ノード間情報共有部１０２は、他の検証ノード１から受信した応答候補ブロックに限らず、自ノードで生成され、ノンスが設定された応答候補ブロックが情報検証部１０５で承認されて応答ブロックとなった場合にも同様の処理を行う。なお、この場合において、検証ノード間情報共有部１０２は、当該応答候補ブロックに対する情報検証部１０５による検証処理を省略してもよい。
【００６１】
ブロック生成部１０３は、検証ノード間情報共有部１０２から通知される情報取得要求に基づいて、当該要求に対応するブロックを生成する。より具体的には、ブロック生成部１０３は、情報取得要求の内容と、情報記憶部１０６に格納されている所望情報とを少なくともデータ領域に含むブロックを生成する。また、ブロック生成部１０３は、生成したブロックを、検証ノード間情報共有部１０２を介して抽選実行部１０４に通知する。なお、ブロック生成部１０３が直接、抽選実行部１０４に通知してもよい。
【００６２】
ブロック生成部１０３が、このようにブロックを生成することにより、検証ノード１の各々が所持するブロックには、情報取得要求の内容と、所望情報とが必ず含まれることになる。
【００６３】
抽選実行部１０４は、ブロック生成部１０３で生成された、情報取得要求に対応するブロックに、適切にノンスを設定する作業を行う。ここでノンスは、ブロックが予め決められた規則を満たすように設定される。
【００６４】
例えば、ブロック全体をある決められたハッシュ関数、例えばＳＨＡ−２５６（Secure Hash Algorithm 256-bit）などで処理した値が予め決められた範囲内となるようなノンスを設定することができる。ここで、ブロックのデータ領域に変更が加えられた場合、ブロックのハッシュ値が大きく変化することに注意されたい。すなわち、一度ブロックにノンスが設定されると、以降悪意あるノードがデータ領域の改ざんを検出されないように行うためには当該ブロックのノンスを再設定する必要がある。このことが、ブロック内のデータの改ざんされ難さに寄与している。
【００６５】
また、ブロック全体をハッシュ関数で処理した値が予め決められた範囲内となるようなノンスを探す作業は、一般に効率的に行うことができないため、ノンスの値を変えながら実際にハッシュ値を計算して規則を満たしているか否かを確認する作業が繰り返される。この処理は、計算処理を伴う抽選とみなすことができる。本実施形態では、抽選実行部１０４によるこのようなノンスを探す作業を、抽選作業を呼ぶ。
【００６６】
抽選実行部１０４におけるノンスの設定方法は、計算処理を伴う抽選としての特徴を有する方法であれば、上述した例に限られない。つまり、規則を満たすノンスを効率的に見つけることが困難であり膨大な計算量を要し（典型的には総当たりと同程度の効率でしか見つけられない）、かつ、あるノンスを設定したブロックが規則を満たしていることを少ない計算量で確認できる（典型的には一定時間内に確認できる）方法であればよい。例えば、ブロックをハッシュ関数以外の一方向性関数で処理することや、ある一方向性関数で処理した値に予め決められたビット列が含まれることとすることもできる。なお、規則の決め方によって、当該規則を満たすようなノンスの値を発見することができる確率（抽選に成功する確率）を変えることができる。すると、その結果として、規則を満たすノンスを探す作業時間を変えることができる。
【００６７】
同一内容のブロックに対して抽選が成功するまでの時間は、ノンスを探す作業を並行して行うノード数と当該規則に依存して決まる。したがって、抽選に要した時間からその作業を行っているノード数を推測できる。上述した情報取得ノード２における所望情報の検証は、このことを利用して、取得した所望情報が高信頼情報であることを判断している（上記の判定条件の項目（Ａ４）参照）。
【００６８】
また、抽選実行部１０４は、予め決められた規則を満たすノンスの値を発見すると、ブロック生成部１０３によって生成されたブロックに当該ノンスの値を設定し、応答候補ブロックとして検証ノード間情報共有部１０２に通知する。そして、抽選作業を終了する。また、抽選実行部１０４は、自身がノンスを発見していない場合でも、検証ノード間情報共有部１０２から抽選終了（または応答ブロックの受領）が通知された場合には、抽選作業を終了する。
【００６９】
情報検証部１０５は、情報記憶部１０６に記憶された情報に基づいて、検証ノード間情報共有部１０２から通知されたブロック（応答候補ブロック）内の情報の検証を行う。情報検証部１０５は、より具体的には、以下に示す判定条件に基づいて、応答候補ブロックの検証を行う。
【００７０】
・（Ｂ１）ブロック内の所望情報が自ノードの情報記憶部１０６内に格納されている所望情報と一致すること
・（Ｂ２）ブロック内に含まれる情報取得要求が自ノードの情報記憶部１０６に格納されている情報と一致すること
・（Ｂ３）ブロック内に情報取得要求に対応する所望情報が格納されていること
・（Ｂ４）ブロックに、決められた規則を満たすノンスが設定されていること
【００７１】
情報検証部１０５は、上記の項目（Ｂ１）〜（Ｂ４）をそれぞれ確認し、これら全ての項目が満たされている場合には当該ブロックを承認し、一つ以上満たされていない場合には当該ブロックの承認を拒絶する。情報検証部１０５による検証結果は、検証ノード間情報共有部１０２に通知される。
【００７２】
情報記憶部１０６は、各種情報を記憶する。例えば、情報記憶部１０６は、情報取得ノード２からの要求対象とされる情報（所望情報）と、情報取得要求内容とを記憶する。
なお、所望情報は全ての検証ノードが共通して保持しているものとする。情報記憶部１０６に記憶された所望情報は、ブロック生成部１０３におけるブロック生成処理や情報検証部１０５におけるブロック検証処理で参照される。なお、所望情報の格納タイミングは特に問わない。また、情報取得要求内容は、検証ノード間情報共有部１０２によって情報記憶部１０６に記憶され、情報検証部１０５のブロック検証処理で参照される。
【００７３】
以下、情報検証部２０３における所望情報の検証処理について、検証ノード１の動作との関連を示しつつ補足する。
【００７４】
情報検証部２０３は、上記の項目（Ａ１）に示したように、受信したブロック内に、情報取得要求で指定した所望情報が存在していることを確認する。これは、例えば、受信したブロックに、情報記憶部２０４に格納されている情報取得要求で指定されている所望情報を特定する情報により特定される所望情報が含まれているか否かを判定することにより行ってもよい。また、例えば、所望情報自体に、当該所望情報の識別子といった所望情報を特定する情報が含まれている場合には、受信したブロックの所望情報が格納される領域に、情報記憶部２０４に格納されている情報取得要求で指定されている識別子と同じ識別子を有する情報が含まれているか否かを判定することにより行ってもよい。なお、情報検証部１０５は、上記の項目（Ｂ３）で同様の判定を行う。この場合、「受信したブロック」を「応答候補ブロック」と読み替え、「情報記憶部２０４」を「情報記憶部１０６」と読み替えればよい。
【００７５】
また、情報検証部２０３は、上記の項目（Ａ２）に示したように、受信したブロック内の検証情報と情報記憶部２０４内の検証情報とが一致することを確認する。上述したように、検証情報生成部２０２で生成された検証情報は、情報要求部２０１を介して情報取得要求の一部として検証ノード１（より具体的にはＧＷ検証ノード１’）に送られると同時に、情報記憶部２０４に格納される。そして、ＧＷ検証ノード１’に送信された情報取得要求の内容は、ＧＷ検証ノード１’が生成したブロックに所望情報とともに格納され、検証ノード１間で共有される。その後、いずれかの検証ノード１が該ブロックに対してノンスの抽選に成功し、ブロックの検証処理を経て承認を得ると、当該ブロックが応答ブロックとして情報取得ノード２に通知される。したがって、通常、情報取得ノード２が受信するブロックに含まれる検証情報と、情報記憶部２０４に格納されている検証情報とは一致することになる。この情報が一致しない場合、検証ノード１群による抽選作業が情報取得要求を送信して以降に行われたことが保証されなくなる。このため、そのような場合には、受信ブロック内に格納された所望情報を高信頼情報であるとの判断はできない。
【００７６】
また、情報検証部２０３は、上記の項目（Ａ３）に示したように、受信したブロックが、検証ノードグループ１０との間で共通に定められている所定の規則を満たすことを確認する。ここで、所定の規則は、より具体的には、検証ノード１の抽選実行部１０４において抽選成功と判断される規則である。すなわち、上記の項目（Ａ３）として、上記の項目（Ｂ４）と同じ確認を行えばよい。より具体的には、情報検証部２０３は、受信したブロックに対して一方向性関数を適用して得られた値が、決められた規則を満たしていることを確認すればよい。ブロック内のどの領域のデータに対して一方向性関数を適用するかは予め検証ノードグループ１０と情報取得ノード２との間で定められているものとするが、少なくとも所望情報が格納される領域と検証情報が格納される領域とノンスとが含まれるものとする。
【００７７】
また、情報検証部２０３は、上記の項目（Ａ４）に示したように、ブロックの受信が情報取得要求信号を送信してから一定時間内に行われているか否かを確認する。既に説明したように、情報要求部２０１は、情報記憶部２０４に情報取得要求の送信時刻情報を格納する。このため、情報検証部２０３は、ブロックの受信時に当該送信時刻情報を参照し、現在時刻すなわちブロックの受信時刻との差を求めることで、ブロックの受信が情報取得要求信号を送信してから一定時間内に行われていることが確認可能である。
【００７８】
上記の一定時間は、所望情報の性質に基づいて決めることも可能である。例えば、所望情報が改ざんされた場合の影響度が大きいほど、上記の一定時間を短く設定してもよい。これにより、より短い時間でブロックが得られた場合のみ高信頼情報と判断できる。ここで、所望情報が改ざんされた場合の影響度は、情報取得ノード２のユーザにより設定されてもよいし、所望情報の所有者や所望情報を利用するアプリケーションに基づいて決定することも可能である。
【００７９】
また、上記の影響度を、より具体的に所望情報の属性情報と言い換えてもよい。所望情報の属性情報の例としては、以下のものが挙げられる。
・情報のサイズ
・情報の作成日時（新しいほど重要度が高い等）
・ユーザが情報の内容ごとに指定する属性値（キーワード等）
・ユーザが情報のカテゴリごとに指定する属性値（分類コード等）
・情報の作成者、所有者または要求者の情報
・要求するアプリケーションごとに指定される属性値
・データであるか制御情報であるか（データプレーン情報であるか制御プレーン情報であるか等）
【００８０】
なお、情報の作成者、所有者または要求者の情報に関して、例えば、別途ユーザ情報のデータベースを用意し、ユーザの地位（優先度や役職等）が高いほど取得対象とされる情報の重要度が高いとしてもよい。また、ユーザのアクセス制御情報を利用して、より多くの情報にアクセス可能なユーザほど取得対象とされる情報の重要度が高いとしてもよい。
【００８１】
本実施形態において、ＧＷ検証ノード１’で生成されたブロックは、各々の検証ノード１の抽選実行部１０４により、予め決められた規則を満たすようなノンスを探す処理が行われる。すなわち、当該ブロックのノンスを探す処理が、当該ブロックに含まれる情報を承認する複数の検証ノード１によって同時並行的に行われる。そのため、多くの検証ノード１が承認する情報ほど早く抽選が終わることが期待される。そのことから、検証ノード１に情報取得要求を送信してから、より短い時間で得られたブロックに含まれる所望情報ほど多くの検証ノード１群に検証されたものであることが期待できる。
【００８２】
なお、上述した説明では、情報検証部２０３による所望情報の検証処理を、高信頼情報であるか否かの２状態を返す判断としているが、他の方法も考えられる。例えば、情報検証部２０３は、他の条件が全て満たされている場合において、項目（Ａ４）に代えて、情報取得要求を送信してからブロックが得られるまでにかかった時間を、得られた所望情報の信頼度とみなし、その時間が短いほど当該情報が信頼できると判定することも可能である。その場合は、情報検証部２０３は、得られた所望情報とともに信頼度を出力してもよい。
【００８３】
本実施形態において、情報要求部２０１、検証情報生成部２０２および情報検証部２０３は、例えば、情報取得ノード２として動作するコンピュータが備えるＣＰＵ等のプログラムに従って動作する情報処理装置により実現される。また、情報記憶部２０４は、例えば、情報取得ノード２として動作するコンピュータが備える記憶装置により実現される。また、外部向け情報共有部１０１、検証ノード間情報共有部１０２、ブロック生成部１０３、抽選実行部１０４および情報検証部１０５は、例えば、検証ノード１として動作するコンピュータが備えるＣＰＵ等のプログラムに従って動作する情報処理装置により実現される。また、情報記憶部１０６は、例えば、検証ノード１として動作するコンピュータが備える記憶装置により実現される。
【００８４】
次に、図５〜図８を参照して、本実施形態の動作を説明する。
【００８５】
まず、図５を参照して、本実施形態の情報検証システム全体の動作を説明する。図５は、本実施形態の情報検証システム１００の全体の動作の一例を示すシーケンス図である。図５に示す例は、検証ノード１−ＡがＧＷ検証ノード１’として動作し、検証ノード１−Ｂが抽選を成功させた場合の例である。
【００８６】
図５に示す例では、まず情報取得ノード２が、情報取得要求Ｍ１１をＧＷ検証ノード１’とされる検証ノード１−Ａに送信する（ステップＳ１１）。検証ノード１−Ａは、情報取得要求Ｍ１１を他の検証ノード１に転送し、検証ノードグループ１０内で共有させる（ステップＳ１２）。
【００８７】
検証ノード１の各々は、情報取得要求Ｍ１１を受信すると、情報取得要求Ｍ１１の内容と、要求された所望情報とを含むブロックを作成する（ステップＳ１３）。
【００８８】
次いで、検証ノード１の各々は、作成したブロックに対してノンスを探す処理（抽選作業）を行う（ステップＳ１４）。本例では、検証ノード１−Ｂが抽選に成功したとする（ステップＳ１５）。検証ノード１−Ｂは、抽選作業を終了し、抽選に成功したブロックＭ１２すなわちステップＳ１３で作成された後、ノンスが適切に設定されたブロックＭ１２（応答候補ブロック）を他の検証ノード１に転送し、検証ノードグループ１０内で共有させる（ステップＳ１６）。
【００８９】
ステップＳ１６で、検証ノード１の各々は、他の検証ノード１からブロックＭ１２を受信すると、ブロックの検証を行った上で承認する場合には、抽選作業を終了する。
【００９０】
ＧＷ検証ノード１’である検証ノード１−Ａは、抽選作業を終了すると、検証済みのブロックＭ１２を情報取得ノード２に送信する（ステップＳ１７）。
【００９１】
情報取得ノード２は、ブロックＭ１２を受信すると、ブロックＭ１２に含まれる所望情報が高信頼情報であるかを検証する（ステップＳ１８）。
【００９２】
次に、各ノードの動作をより詳細に説明する。図６は、情報取得ノード２の動作の一例を示すフローチャートである。本実施形態の情報検証動作は、情報取得ノード２が、検証ノードグループ１０に属する検証ノード１のいずれかに情報取得要求を送信することで開始される。
【００９３】
情報取得ノード２は、まず情報取得要求送信処理（ステップＳ１０１）を行う。この処理において、まず、検証情報生成部２０２が、検証情報を生成する。次いで、情報要求部２０１が、生成された検証情報と、所望情報を特定可能な情報とを含む情報取得要求Ｍ１１を生成し、検証ノードグループ１０に含まれるいずれかの検証ノード１に送信する。また、情報要求部２０１は、この時、情報取得要求Ｍ１１を送信した時刻を示す送信時刻情報と、情報取得要求Ｍ１１に含ませた検証情報とを情報記憶部２０４に記憶させる。
【００９４】
その後、情報取得ノード２は応答待ち処理（ステップＳ１０２）を行う。この処理で、情報取得ノード２は、検証ノードグループ１０に含まれるいずれかの検証ノード１から、ステップＳ１０１で送信した情報取得要求の応答とされるブロックＭ１２を受信するまで待つ。
【００９５】
ブロックＭ１２を受信すると、情報取得ノード２の情報検証部２０３が、所望情報の検証処理（ステップＳ１０３）を行う。この処理において、情報検証部２０３は、受信したブロックＭ１２に含まれる所望情報が高信頼情報であるかの検証を行い、結果を出力する。検証方法の詳細は上述したとおりである。
【００９６】
次に、検証ノード１の動作を説明する。図７は、情報取得ノード２から情報取得要求を受信するＧＷ検証ノード１’の動作の一例を示すフローチャートである。また、図８は、ＧＷ検証ノード１’以外の検証ノード１の動作の一例を示すフローチャートである。図８中のステップＳ３０１〜ステップＳ３０６の動作は、図７中のステップＳ２０２〜ステップＳ２０７の動作と同様であるため、簡単な説明にとどめる。
【００９７】
図７に示すように、ＧＷ検証ノード１’は、まず情報取得要求受信処理（ステップＳ２０１）を行う。この処理では、外部向け情報共有部１０１が、情報取得ノード２から送信される情報取得要求Ｍ１１を受信する。また、外部向け情報共有部１０１は、受信した情報取得要求Ｍ１１を検証ノード間情報共有部１０２に通知する。
【００９８】
情報取得要求Ｍ１１の通知を受けると、検証ノード間情報共有部１０２が、情報取得要求共有処理（ステップＳ２０２）を行う。この処理では、検証ノード間情報共有部１０２が、情報取得要求Ｍ１１を他の検証ノード１に転送するとともに、当該情報取得要求Ｍ１１を情報記憶部１０６に記憶させる。また、検証ノード間情報共有部１０２は、情報取得要求Ｍ１１を受信した旨を、ブロック生成部１０３に通知する。
【００９９】
情報取得要求Ｍ１１の受信が通知されると、ブロック生成部１０３は、ブロック生成処理（ステップＳ２０３）を行う。この処理では、ブロック生成部１０３が、通知された情報取得要求Ｍ１１の内容を基にブロックを生成する。また、ブロック生成部１０３は、生成されたブロックを、抽選実行部１０４に通知する。
【０１００】
ブロックが通知された抽選実行部１０４は、抽選実行処理（ステップＳ２０４）を行う。この処理では、抽選実行部１０４が、予め決められた規則を満たすノンスを探す作業（抽選作業）を行う。抽選実行部１０４は、決められた規則を満たすノンスを発見した場合、すなわち抽選が成功した場合には（ステップＳ２０５のＹｅｓ）、抽選作業を終了し、ブロックの転送処理（ステップＳ２０６）に移る。
【０１０１】
ステップＳ２０６では、検証ノード間情報共有部１０２が、ノンスが設定されたブロックＭ１２を検証ノードグループ１０内で共有する処理が行われる。なお、情報共有の方法は、ステップＳ２０２と同様でよい。この処理によってノンスが設定済みのブロックＭ１２が他の検証ノード１に通知されると、当該ブロックＭ１２を受信した検証ノードはステップＳ２０７に移る。
【０１０２】
ステップＳ２０７では、情報検証部１０５が、受信したブロックＭ１２を検証する検証処理を行う。そして、当該ブロックＭ１２が承認された場合には、他ノードが抽選を成功したものと判断し、抽選作業を終える（ステップＳ２０７のＹｅｓ）。このとき、自ノードがＧＷ検証ノード１’であれば、要求元への応答処理（ステップＳ２０８）に移る。
【０１０３】
ステップＳ２０８では、外部向け情報共有部１０１が、自ノードで抽選を終えたブロックＭ１２または他のノードから通知され自ノードが承認したブロックＭ１２を、情報取得ノード２に送信する。このブロックＭ１２は、所望情報と情報取得要求がデータ領域に格納され、かつ、決められた規則を満たすようなノンスが設定されたブロックである。
【０１０４】
なお、抽選実行部１０４は、決められた規則を満たすノンスを発見するまで、または他のノードが抽選を成功するまで、抽選作業を繰り返し行う。より具体的には、抽選実行部１０４は、設定したノンスが規則を満たさない場合すなわち抽選が失敗した場合（ステップＳ２０５のＮｏ）であって、他のノードが抽選を成功してない場合（ステップＳ２０７のＮｏ）には、ステップＳ２０４に戻り、抽選実行処理を再度行う。
【０１０５】
なお、ＧＷ検証ノード１’以外の検証ノード１では、ＧＷ検証ノード１’による情報取得要求共有処理で転送された情報取得要求Ｍ１１を直接または間接的に受信することにより処理が開始される。図８に示すように、ＧＷ検証ノード１’以外の検証ノード１は、情報取得要求Ｍ１１を受信すると、情報取得要求共有処理（ステップＳ３０１）〜抽選実行処理（ステップＳ３０３）を行う。なお、これらの処理は上述したステップＳ２０２〜ステップＳ２０４と同様である。これにより、全ての検証ノード１で情報取得要求Ｍ１１が共有されて、ＧＷ検証ノード１’以外の検証ノード１の各々において、同様のブロックが生成され、抽選作業が行われる。
【０１０６】
ここで、ＧＷ検証ノード１’以外の検証ノード１が、抽選実行処理中に、決められた規則を満たすノンスを発見した場合には（ステップＳ３０４のＹｅｓ）、抽選作業を終了し、ブロックの転送処理（ステップＳ３０５）に移る。
【０１０７】
また、ＧＷ検証ノード１’以外の検証ノード１が、抽選が成功していない状態で他の検証ノード１からブロックＭ１２を受信した場合には、受信したブロックＭ１２を検証する検証処理を行い、当該ブロックＭ１２が承認された場合には、他ノードが抽選を成功したものと判断し、抽選作業を終える（ステップＳ３０６のＹｅｓ）。このようにして、ＧＷ検証ノード１’以外の検証ノード１は、決められた規則を満たすノンスを発見するまで、または他のノードが抽選を成功するまで、抽選作業を繰り返し行う。
【０１０８】
以上のように、本実施形態では、ノンスを探す作業が、多くの検証ノード１が並行して行わない限り短時間で終えることが困難であるという性質を利用して、取得した情報の信頼性を評価する。より具体的には、情報取得ノード２が、情報取得要求を送ってから、抽選が実行され適切にノンスが設定されたブロックが返されるまでの時間に基づいて、取得した情報が多くの検証ノードに承認された情報であるか否かを判断する。また、情報取得要求に対する応答として送信されるブロックに、情報取得ノード２が生成した検証情報を含ませることで、当該ブロックの抽選が情報取得要求を情報取得ノード２が送信して以降に行われたことを確認可能とする。このような特徴的要素を有することにより、情報取得ノード２において、取得先となる相手側装置に関して、事前に認証に用いる情報の対応づけなしに、取得される情報の信頼性を評価することができる。
【０１０９】
仮に、所望情報を管理している検証ノードグループ１０の中に、悪意ある検証ノード１が含まれていた場合、悪意ある一部の検証ノード１が改ざんした情報を情報取得ノード２に通知するためには、悪意ある一部の検証ノード１だけで抽選を成功させる必要がある。悪意ある一部の検証ノード１の総計算量が小さければ、それだけ応答までにかかる時間が長くなることから、応答までにかかる時間に基づいて信頼性を評価することで、悪意ある一部の検証ノード１によって改ざんされた情報を高信頼情報として受領するのを防止することが可能となる。
【０１１０】
ここで、悪意ある一部の検証ノード１が偶然短時間で抽選を成功させる可能性がある。この場合、これまでに説明した第１の実施形態では、悪意ある検証ノード１にしか承認されていない情報が情報取得ノード２に通知されることがあり得る。
【０１１１】
なお、このような悪意ある検証ノード１が含まれている可能性を考慮して、さらに、上述した第１の実施形態を次のように拡張してもよい。すなわち、情報取得ノード２が、情報取得要求を送信し、応答としてブロックを受信する一連の処理を所定の回数、繰り返し行う。その上で、情報取得ノード２が、毎回同じ結果、すなわち一定の時間以内でかつ同程度の応答時間でブロックが得られることを、高信頼情報であるかの判断基準に加えてもよい。このようにすることで、悪意ある検証ノード１が改ざんした所望情報を情報取得ノード２に高信頼情報として受領させるためには、悪意ある検証ノード１のみによる抽選を、毎回、短時間で終える必要がある。したがって、繰り返し回数を多くするほど、より判断の精度を向上させることが可能である。この繰り返し回数は、取得する情報の種別や重要度などの性質に基づいて決めることができる。すなわち、より正確であることが求められる情報ほど繰り返し回数を増やすようにすることができる。
【０１１２】
［第１の実施形態の変形例］
第１の実施形態には上記以外にも、様々な変形例が存在する。ここでその一部について説明する。
【０１１３】
［変形例１］
第１の実施形態で述べた検証ノード１の構成および動作は、ＰｏＷを活用してブロックチェーンを管理する分散台帳システムの台帳管理ノードと共通する部分が多く、当該台帳管理ノードを検証ノード１とすることができる。このとき、検証ノード１の各々は、情報取得ノード２から送信された情報取得要求を受けて生成した所望情報等を含むブロックについてＰｏＷを行い、ブロックチェーンへ当該ブロックを追加してもよい。その場合、検証ノード１のいずれかが、当該ブロックがブロックチェーンに追加された場合に、追加されたブロックまたはそのようなブロックが追加された旨を情報取得ノード２に通知することができる。この場合において、情報取得ノード２は、情報取得要求に対する応答ブロックに相当する当該ブロックが分散台帳システムが管理するブロックチェーンに追加されるための所要時間に基づいて、当該ブロックに含まれる所望情報が高信頼情報であるか否かを判断してもよい。
【０１１４】
このような構成により、分散台帳システムに参加していないノード（情報取得ノード２）が台帳全体を取得することなく、多くの台帳管理ノード（検証ノード１）が承認したことを確認しながら、台帳の情報の一部を取得することが可能となる。第１の実施形態の効果は、分散台帳システムの観点からこのように言い換えることもできる。
【０１１５】
さらに、検証ノード１がＰｏＷを活用してブロックチェーンを管理する分散台帳システムの台帳管理ノードである場合において、第１の実施形態を次のように変形してもよい。すなわち、検証ノード１を、情報取得要求を受信してから一定時間たってから応答ブロックに相当するブロックが追加された旨、または、当該ブロックを含むそれ以降に追加された全てのブロックを情報取得ノード２に通知する構成としてもよい。この場合、情報取得ノード２は、該一定時間内に、検証ノードが参加する台帳管理システムが管理するブロックチェーンに、応答ブロックに相当するブロック以降に追加されたブロックの数に基づいて、応答ブロックに相当するブロックに含まれる所望情報が高信頼情報であるかを判断することができる。
【０１１６】
ＰｏＷを活用してブロックチェーンを管理する分散台帳システムにおいて、台帳管理ノードは、他の台帳管理ノードから通知された情報やブロックを検証し、ブロックチェーンに追加するかを判断することができる。そのため、多くの台帳管理ノードが承認する情報しか存在しないような状況では、ブロックチェーンにブロックが追加される頻度が高くなる。言い換えると、少数の台帳管理ノードにしか承認されていないようなブロックを含むブロックチェーンは、それら少数の台帳管理ノードのみがブロックを追加することとなり、ブロックの追加頻度が遅くなる。このことを利用して、分散台帳システムが管理するブロックチェーンにおいて、応答ブロックに相当するブロックが追加されて以降に追加されたブロックの数が多いほど、応答ブロックに相当するブロックに含まれる所望情報は多くの検証ノードによって承認された情報であると期待できる。
【０１１７】
［変形例２］
第２の変形例では、ブロックに含ませるデータ量を削減し、通信負荷を軽減する。ここまでの第１の実施形態の説明では、ブロック生成部１０３が所望情報自体を生成したブロックのデータ領域に格納していた。所望情報そのものをブロック内に含ませるのではなく、その代替として所望情報のダイジェストを格納することが可能である。ここでは、ある情報をハッシュ関数などの一方向性関数で処理した値をダイジェストと呼ぶ。ある情報Ｘのダイジェストは、当該情報Ｘとは異なる情報Ｙのダイジェストと一致する可能性が極めて低いことから、情報Ｘの検証に用いることができる。例えば、情報Ｘを持つノードは、自身が有する情報ＸのダイジェストＤｘと、ブロック内の情報Ｘのダイジェストとされる値Ｄｘ’とを比較することで、ダイジェストの元となった２つの情報が同一の情報であるかを検証することができる。
【０１１８】
このような場合に、情報検証部１０５は、上記の項目（Ｂ１）および項目（Ｂ３）に代えて、ブロックに含まれる所望情報のダイジェストと、情報記憶部１０６に記憶されている、情報取得要求に対応する所望情報を同じ方法でダイジェスト化したものとを比較して一致するか否かを確認してもよい。一般にダイジェストは元の情報よりデータサイズが少ないことから、このような構成とすることで、検証ノード１間のブロック共有時の通信負荷を軽減しうる。
【０１１９】
なお、この場合、ブロック内に所望情報そのものを含まないため、外部向け情報共有部１０１は情報取得ノード２にブロックを送信する際に、併せて所望情報自体を送信する処理を追加することができる。また、その場合において、情報取得ノード２の情報検証部２０３は、所望情報の検証処理において、送られたブロック内の所望情報のダイジェストと、ブロックと併せて送られた所望情報のダイジェストとが一致するかを確認する処理を追加することができる。
【０１２０】
［変形例３］
一つのブロック内に、複数の情報取得要求と所望情報のペアを含ませてもよい。この場合、検証ノード１の情報検証部１０５は、上述した項目（Ｂ１）〜項目（Ｂ３）の判定を、ブロック内の全ての情報取得要求と所望情報について行えばよい。また、情報取得ノード２の情報検証部２０３は、上述した項目（Ａ１）および項目（Ｂ２）の判定を、ブロック内の全ての情報取得要求と所望情報について行えばよい。
【０１２１】
［変形例４］
上記の説明では、簡単化のため、情報取得ノード２から情報取得要求を受信したＧＷ検証ノード１’が、情報取得ノード２にブロックの送信を行うものとしたが、一般には情報取得ノード２から情報取得要求を受信する検証ノード１（ＧＷ検証ノード１’）と情報取得ノード２にブロックを送信する検証ノード１とは異なっていてもよい。例えば、抽選に成功した検証ノード１が直接、ブロック内の情報取得要求の内容に基づいて情報取得ノード２にブロックを送信してもよい。
【０１２２】
［変形例５］
また、上記の説明では、全てのノードが所望情報を予め保持しているものとしたが、これに限定されない。例えば、少なくとも１つの検証ノード１が所望情報を保持しており、他の検証ノード１が当該所望情報を検証可能な情報を保持していてもよい。検証可能な情報としては、例えば、所望情報のダイジェストや、所望情報が満たすべき条件（値の範囲等）などが挙げられる。このような場合、検証ノード１の各々は、所望情報に代えて、検証可能な情報を含むブロックを生成してもよい。その上で、いずれかの検証ノード１で抽選が成功したブロックが検証ノード１間で共有される過程で、所望情報を保持する検証ノード１が当該ブロックと所望情報とを併せて情報取得ノード２に送信してもよい。なお、検証ノード１の各々は、情報取得要求を他の検証ノード１と共有する処理で、情報取得要求とともに、所望情報を保持する検証ノード１が生成したブロックを共有してもよい。この場合、情報取得要求が所望情報を保持する検証ノード１へと転送され、そこでブロックが生成される。その上で、該検証ノード１により生成されたブロックを、他の検証ノードへと転送する。そのようにして所望情報を含むブロックを受信した複数の検証ノード１が、同時並列的に抽選作業を行ってもよい。その場合、情報検証部１０５は、上記の項目（Ｂ１）に代えて、自ノードが保持している、当該所望情報を検証可能な情報を基に、ブロック内の所望情報が正しい情報であるか否かを確認してもよい。
【０１２３】
別のバリエーションとして、所望情報を保持する専用ノード（クラウド上のストレージなど）を用意してもよい。そのような場合、全ての検証ノード１は、所望情報を保持していなくてもよい。なお、本例の場合も、全ての検証ノード１が、当該所望情報を検証可能な情報を保持しているものとする。本例では、例えば、検証ノード１の各々が、ブロック生成部１０３におけるブロックの生成処理で、上記の専用ノードから所望情報を取得してブロックを生成してもよい。
【０１２４】
［変形例６］
ノンスを探すための規則に関しても様々な変形例が存在する。例えば、所望情報の性質に基づいて当該規則を決めることができる。例えば、所望情報が改ざんされた場合の影響度が大きいほど、抽選実行部１０４で規則を満たすノンスを探すことが困難になるように当該規則を定めることができる。一例として、ブロックのハッシュ値がターゲット値以下であるという規則に基づいて抽選が実行される場合、所望情報が改ざんされた場合の影響度が大きいほど当該ターゲット値を低く定めることができる。このとき、所望情報が改ざんされた場合の影響度は、ユーザが設定することもできるし、所望情報の所有者や所望情報を利用するアプリケーションに基づいて決めることもできる。
【０１２５】
［変形例７］
さらに、ノンスを探すための規則は、検証情報を用いて決定されてもよい。例えば、情報取得要求に含ませる検証情報に、当該規則の情報を含ませてもよい。このようにして、抽選実行部１０４において適切なノンスが設定されているかの判断基準となる規則を検証情報に基づいて定める。この場合、抽選実行部１０４は、情報記憶部１０６に格納されている情報取得要求に含まれる検証情報により示される規則を基に、設定したノンスを確認してもよい。また、情報検証部１０５は、情報記憶部１０６に格納されている情報取得要求に含まれる検証情報により示される規則を基に、他の検証ノードから送られてきたブロックを検証してもよい。同様に、情報検証部２０３は、情報記憶部２０４に格納されている検証情報により示される規則を基に、検証ノード１から取得したブロックに含まれる所望情報を検証してもよい。
【０１２６】
具体例として、検証情報に、ブロックのハッシュ値の上限と下限の情報を含ませることができる。
【０１２７】
［第２の実施形態］
次に、本発明の第２の実施形態を説明する。第２の実施形態では、複数の情報取得ノード２が存在し、それらすべての情報取得ノード２において、検証ノード１から取得した情報が高信頼情報であることを確認する方法を説明する。なお、第１の実施形態と同じ構成および動作については適宜説明を省略する。
【０１２８】
本実施形態は、情報取得ノード２が複数存在する場合であって、情報取得ノード２間の通信資源と比較して、情報取得ノード２と検証ノード１間の通信資源が限られているような場合に、特に効果がある。例えば、検証ノード１と情報取得ノード２とを接続するネットワークの通信帯域が狭い場合、全ての情報取得ノード２が第１の実施形態で示した方法により個別に検証ノード１から情報を取得しようとすることは、通信負荷の観点で好ましくない。そこで、本実施形態では、一部の情報取得ノードが検証ノードから情報を得た後で、当該情報を他の情報取得ノードと共有する。
【０１２９】
しかし、ある情報取得ノードが検証ノードから取得した情報を、他の情報取得ノードに転送して単純に共有させる方法では、次のような問題がある。すなわち、所望情報を取得した情報取得ノードが悪意あるノードであった場合に、他の情報取得ノードは、該所望情報が多くの検証ノード１に承認されたものであるかを判断ができない。
【０１３０】
例えば、検証ノードから情報を直接取得する情報取得ノードと一部の検証ノードとが結託すると、改ざんされた情報を高信頼情報として他の情報取得ノードに通知することができる。具体例として、悪意ある情報取得ノードが、予め自ノード内で生成した情報取得要求を、結託している検証ノードに通知する。当該検証ノードは結託している検証ノードのみからなるグループ内で当該情報取得要求を共有し、当該グループ内の各検証ノードで抽選を実行させる。この抽選は、一部の結託した検証ノードのみで行うため、一般には成功するまで長い時間がかかる。しかし、情報取得要求を送信した情報取得ノード以外の情報取得ノードは、抽選が長い時間をかけて行われたことを、情報取得要求を送信した情報取得ノードから転送される応答ブロックのみからでは判断できない。このため、一部の悪意ある検証ノードと悪意ある情報取得ノードとが結託すると、悪意ある検証ノードによる承認のみを経た改ざんされた情報であっても、高信頼情報であるかのように他の情報取得ノード２に通知することが可能となる。
【０１３１】
そこで、仮に悪意ある情報取得ノードが悪意ある検証ノードと結託して所望情報を取得した場合であっても、他の情報取得ノードがそれを検証できる仕組みを本実施形態では導入する。すなわち、本実施形態では、検証ノードから直接所望情報を得ていない情報取得ノード２においても、得られた所望情報が高信頼情報であるかを判断する手段を提供する。
【０１３２】
図９は、第２の実施形態の情報検証システムの構成の概要を示す説明図である。図９に示す情報検証システム２００は、検証ノードグループ１０と、情報取得ノードグループ２０とを備える。検証ノードグループ１０は、複数の検証ノード１を含む。また、情報取得ノードグループ２０は、複数の情報取得ノード２を含む。ここで、情報取得ノードグループ２０は、検証ノードグループ１０が管理している情報を所望するノードのグループである。なお、検証ノードグループ１０および検証ノード１は第１の実施形態と同様である。
【０１３３】
このような構成において、情報取得ノードグループ２０のうちの一の情報取得ノード２（図中のＧＷ情報取得ノード２’）が検証ノード１から直接、所望情報を取得し、取得した所望情報を他の情報取得ノード２と共有する。以下、検証ノード１に対して情報取得要求を送信する情報取得ノード２をゲートウェイ（ＧＷ）情報取得ノード２’と呼ぶ場合がある。
【０１３４】
本実施形態において、情報取得ノード２の各々は、全ての情報取得ノード２で共有される情報であって、かつその情報が記録された時刻を推測可能な情報をもつ。このような情報を持たせるために、情報取得ノード２の各々を、分散台帳システムの一部として構成する。すなわち、情報取得ノード２の各々は、分散台帳システムによって共有される台帳の情報を参照可能であるものとする。また、情報取得ノードグループ２０により構成される分散台帳システムは、台帳に情報が記録された時刻が推測可能であるように構成されるものとする。
【０１３５】
例えば、ＰｏＷを利用してブロックチェーンが管理、共有される分散台帳システムであれば、ＰｏＷにおいて抽選が成功する平均時刻を基に、ブロックおよびブロック内の情報の記録時刻を推測可能である。情報取得ノード２の各々は、そのような分散台帳システムにおける台帳管理ノードでもよいし、単に台帳を共有、参照する機能のみを持つノードであってもよい。また、図９には図示省略しているが、情報取得ノード２以外のノードが台帳管理ノードとして存在してもよい。
【０１３６】
また、図１０は、第２の実施形態の情報取得ノード２の構成例を示すブロック図である。図１０に示すように、情報取得ノード２は、情報要求部２０１と、検証情報生成部２０２と、情報検証部２０３と、情報記憶部２０４と、分散台帳処理部２０５とを含んでいてもよい。以下では、第１の実施形態と異なる部分を中心に説明する。
【０１３７】
情報要求部２０１は、概ね第１の実施形態と同様である。ただし、第１の実施形態とは異なり、情報取得要求を送信する際に、情報記憶部２０４に送信時刻情報を格納する処理は省略される。
【０１３８】
検証情報生成部２０２は、第１の実施形態と同様、情報取得要求に含ませる検証情報の生成を行う。本実施形態の検証情報生成部２０２は、分散台帳システムが管理する台帳（以下、分散台帳という）の情報に基づいて検証情報を生成する。詳細は後述するが、分散台帳の情報は、各々の情報取得ノード２の情報記憶部２０４に格納されているか、他の情報取得ノード２と共有され、自由に参照が可能な所定の記憶装置に格納されているものとする。以下、分散台帳といった場合、より具体的には、そのような台帳分散システムが管理する情報を実際に記憶する記憶部（例えば、情報記憶部２０４や上記の所定の記憶装置等）を表す。
【０１３９】
検証情報生成部２０２は、分散台帳に記録され、全ての情報取得ノード２に共有されている、時刻が推測可能な情報を基に検証情報を生成し、情報要求部２０１に通知する。一例として、検証情報生成部２０２は、分散台帳システムが管理するブロックチェーンの最新のブロックから予め決められた数であるＮ１だけ遡った位置のブロックのダイジェストを検証情報として生成することができる。なお、Ｎ１＝０とし、最新のブロックのダイジェストを検証情報としてもよい。
【０１４０】
検証情報は、分散台帳に記録された情報に基づいていればよく、上述した例には限られない。例えば、最新のブロックから遡った数Ｎ１を固定とせず、情報取得要求を送るたびに決定してもよい。その場合には、最新のブロックからＮ１ブロック遡ったブロックのダイジェストとＮ１のペアを検証情報とする。また、複数のブロックを組み合わせてダイジェストを計算した結果を、検証情報とすることもできる。なお、検証情報生成部２０２は、第１の実施形態とは異なり、必ずしも生成した検証情報を情報記憶部２０４に格納する必要はない。
【０１４１】
情報検証部２０３は、自ノードが応答ブロックを受信した場合に加えて、他の情報取得ノード２から応答ブロックが転送された場合にも、当該ブロック内の所望情報の検証を行う。このとき、情報検証部２０３は、所望情報の検証を、分散台帳の情報に基づいて行う。第２の実施形態における情報検証部２０３は、より具体的には、以下に示す判定条件に基づいて、応答ブロックの検証を行う。
【０１４２】
・（Ｃ１）ブロック内に、情報取得要求で指定した所望情報が存在していること
・（Ｃ２）ブロックが、検証ノードグループ１０と情報取得ノードグループ２０との間で共通に定められている所定の規則を満たすこと
・（Ｃ３）ブロック内に含まれる検証情報が、分散台帳内の予め決められた基準よりも新しい情報を基に生成された情報であること
【０１４３】
情報検証部２０３は、上記の項目（Ｃ１）〜（Ｃ３）をそれぞれ確認し、これらの全ての項目が満たされている場合に受信した所望情報が、高信頼情報であると判断してもよい。ここで、項目（Ｃ１）および項目（Ｃ２）は、第１の実施形態の項目（Ａ１）および項目（Ａ３）と同様であることから、項目（Ｃ３）についてのみ説明する。
【０１４４】
本実施形態では、情報取得ノード２の各々は、分散台帳の情報を参照可能に構成されている。また、台帳に記録される情報は、記録された時刻を推測可能な情報である。そのため、情報取得ノード２の各々は、検証情報が当該分散台帳内の予め決められた基準よりも新しい情報から生成されたか否かを判断することが可能となる。
【０１４５】
以下では、さらに分散台帳システムがブロックチェーンを管理するようなシステムである場合であって、情報取得ノード２の各々が台帳管理ノードとして構成される場合に、項目（Ｃ３）の条件のより具体的な判断方法を説明する。項目（Ｃ３）で示した条件「ブロック内に含まれる検証情報が、分散台帳内の予め決められた基準よりも新しい情報を基に生成された情報であること」は、ブロックチェーンを管理するような分散台帳システムにおける台帳管理ノードにおいては、「ブロック内に含まれる検証情報が、情報記憶部２０４にて保持されるブロックチェーンの最新のブロックからＮ３ブロック以内のブロックを基に生成された情報であること」とすることができる。なお、台帳管理ノードでない場合であっても、情報取得ノードの各々が、該ブロックチェーンを参照可能であればよく、ブロックチェーンの格納先は情報記憶部２０４に限定されない。
【０１４６】
図１１は、情報取得ノードグループ２０が管理するブロックチェーンと検証情報との関係を示す説明図である。各時点における、情報取得ノードグループ２０が属する分散台帳システムが管理するブロックチェーンと検証情報との関係を整理すると、図１１のようになる。図１１に示す例では、ＧＷ情報取得ノード２’が、情報取得要求を送信する時点におけるブロックチェーンの最新ブロック（図中のブロックｂｊ）からＮ１ブロック遡ったブロック（図中のブロックｂｉ）のダイジェストを含む検証情報を生成して、該情報取得要求に含ませる。ここで、当該情報取得要求を送信したのち、ある情報取得ノード２の情報検証部２０３において所望情報の検証が行われるまでの時間で、ブロックチェーンに数ブロック（図中のＮ２）のブロックが追加されたとする。その場合、当該情報取得ノード２の情報検証部２０３は、所望情報の検証を行う際に、その時点でのブロックチェーンの最新ブロック（図中のブロックｂｋ）から、応答ブロックに含まれる検証情報とダイジェストが一致するブロック（図中のブロックｂｉ）を探索し、その間の追加ブロック数（Ｎ１＋Ｎ２）を数える。すると、情報取得要求を送信した後、情報取得ノード２が応答ブロックを得るまでにかかったおおよその時間を推定できる。なお、上記の追加ブロック数（Ｎ１＋Ｎ２）からＮ１を引いたＮ２が、情報取得要求を送信した後、応答ブロックを得るまでにブロックチェーンに追加されたブロック数（以下、実追加ブロック数という）に相当する。
【０１４７】
情報検証部２０３は、この追加ブロック数に当該ブロックチェーンにおけるブロックの平均追加時間Ｔを乗算した値を、情報取得要求を送信してから所望情報が得られるまでに要した大まかな時間とみなして、所望情報の信頼性を判断する。
【０１４８】
そのことから、上記の項目（Ａ４）の一定時間に対応する追加ブロック数の上限Ｎ３を規定することにより、応答ブロックの受信が、検証情報により特定されるブロックが最新ブロックであった時点で送信された情報取得要求信号にかかるものであり、かつ該情報取得要求を送信してから一定時間以内に行われたことを確認できる。したがって、情報検証部２０３は、上記の項目（Ｃ３）の判断方法の具体例として、所望情報の検証を行う時点での最新ブロックから遡って、検証情報とダイジェストが一致するブロックが予め決められた数Ｎ３以内にあることを確認してもよい。当該ブロックがＮ３以内にある場合には、ＧＷ情報取得ノード２’が情報取得要求を送信してから自ノードで所望情報が得られるまでの時間が、（Ｎ３−Ｎ１）×Ｔ以内であると推測することができる。よって、第１の実施形態で示したような「一定時間以内に抽選が成功しているため多くの検証ノードが承認した」という判断が、第２の実施形態においても可能となる。Ｎ３は、Ｎ１とＴに基づいて決めることができる。
【０１４９】
なお、情報取得ノードグループ２０のブロックの平均追加時間Ｔが、検証ノードグループ１０の抽選成功にかかる平均時間に比べて圧倒的に大きいケースでは、Ｎ２が常に０となる可能性がある。このような場合には、各グループのノード数に合わせて規則を設定（場合によっては動的に変更）することで、そのようなケースを回避することができる。なお、本実施形態では、情報取得ノードが属する分散台帳システムの台帳管理ノード数（もしくは総計算量）と検証ノード群の抽選成功にかかる平均時間とに基づいて規則が適切に設定されているものとする。以下に、設定方法の一例を示す。例えば、検証ノード群の抽選成功にかかる平均時間の目標値Ｔ１ｏｂｊと、情報取得ノードが属する分散台帳システムの台帳管理ノード群の抽選成功にかかる平均時間の目標値Ｔ２ｏｂｊを定めておく。このとき、情報取得ノードグループ２０のブロックの平均追加時間Ｔが、検証ノードグループ１０の抽選成功にかかる平均時間に比べて圧倒的に大きい状況とならないように、Ｔ２ｏｂｊ＜Ｋ＊Ｔ１ｏｂｊとなるような定数Ｋを定める。その上で、検証ノード群の平均抽選成功時間の実測値がＴ１ｏｂｊを超えるならば、検証ノード群で使用される規則を緩め、台帳管理ノード群の平均抽選成功時間の実測値がＴ２ｏｂｊを超えるならば、台帳管理ノード群で使用される規則を緩めるといった調整を行う。このようにすることで、上記のようなケースを回避することができる。
【０１５０】
さらに、本実施形態の情報検証部２０３は、自身が取得した所望情報やブロックを他の情報取得ノード２に転送することができる。情報検証部２０３は、例えば、第１の実施形態の検証ノード間の情報共有方法と同様の方法を用いて、情報取得ノード間での情報共有を行うことができる。また、上記方法以外に、例えば、分散台帳システムのブロックチェーン共有アルゴリズムに従って、ブロックチェーンに参加する全てのノード間で情報を共有することが可能である。例えば、検証ノード１からブロックを受信した情報取得ノード２の情報検証部２０３が、ブロックチェーンへの当該ブロックの追加を宣言することにより、ＰｏＷを経て他の情報取得ノード２との間で情報共有を行うことができる。各々の情報取得ノード２の情報検証部２０３は、追加対象とされるブロックを受信すると、分散台帳システムにおけるＰｏＷを用いた検証とともにまたは該検証とは独立して、上述した方法により当該ブロック内の所望情報の検証を行ってもよい。このとき、情報検証部２０３は、検証を行う時点での最新のブロックからではなく、所望情報を含むブロックから探索を開始して、Ｎ３を得ればよい。なお、分散台帳システムにおけるＰｏＷを用いた検証は、後述する分散台帳処理部２０５により行われる。
【０１５１】
情報記憶部２０４は、例えば、分散台帳部によって記録される分散台帳の情報を保持する。既に説明したように、分散台帳の情報は、検証情報生成部２０２において検証情報を生成する際、および情報検証部２０３において所望情報を検証する際に参照される。なお、分散台帳の情報を自ノードで保持しない場合には、情報記憶部２０４は省略されてもよい。
【０１５２】
分散台帳処理部２０５は、自ノードを分散台帳システムの一部として構成するための機能を提供する。すなわち、分散台帳処理部２０５は、少なくとも分散台帳システムが管理する台帳を、他のノードから取得する機能を持つ。ここで、他のノードには、当該分散台帳システムの他のノード（他の情報取得ノード２を含む）や、他の分散台帳システムを構成しているノードが含まれ得る。また、分散台帳処理部２０５は、取得した台帳を他のノードに転送する機能を持っていてもよい。さらに、分散台帳処理部２０５は、分散台帳システムの台帳管理ノードとしての機能を有していてもよい。
【０１５３】
ここで、本実施形態の情報取得ノード２が備える分散台帳システムの機能について、より具体的に説明する。情報取得ノード２は、分散台帳システムの台帳管理ノードとして、以下の機能を備えることが好ましい。
・１）分散台帳を基に生成される検証情報が正しいかを検証できる
・２）上記１）の検証情報が正しいかを検証するための情報を、時刻（絶対時刻でも相対時刻でもよい）と対応づけることができる
【０１５４】
なお、分散台帳システムがブロックチェーンを用いて台帳を管理するシステムである場合、典型的には、台帳管理ノードとしての情報取得ノード２は、以下のような性質をもつ。
・ａ）全ての台帳管理ノードが同じ情報（台帳）を保持する
・ｂ）保持する情報はブロックと呼ばれるデータ構造の集合である
・ｃ）各ブロックは他の１つ以上のブロックのハッシュ値を持つ
・ｄ）ブロックを頂点とし、各ブロックについてそのブロックがハッシュ値を持つブロックに対して有向辺を置いた時Directed acyclic graphを形成する
・ｅ）各ブロックはノンスと呼ばれる一方向性関数の性質を用いた抽選作業によって設定される領域を持つ
・ｆ）時間経過に伴いブロックは順次追加される
なお、上記ｃ）およびｄ）のハッシュ値は、一方向性関数により得られるハッシュ値相当の値であればよい。
【０１５５】
上記ａ）の性質を有することにより、各ノードが同じ検証情報を生成可能となるため、上記１）の条件が満たされる。また、上記ｆ）の性質を有することにより、時間経過に伴いブロックが追加されるため、ブロックの数に基づいて相対時刻を計算可能となり、上記２）の条件が満たされる。
【０１５６】
本実施形態において、分散台帳処理部２０５は、例えば、情報取得ノード２として動作するコンピュータが備えるＣＰＵ等のプログラムに従って動作する情報処理装置により実現される。
【０１５７】
次に、本実施形態の動作を説明する。図１２は、ＧＷ情報取得ノード２’の動作の一例を示すフローチャートである。また、図１３は、ＧＷ情報取得ノード２’以外の情報取得ノード２の動作の一例を示すフローチャートである。なお、検証ノード１の動作は第１の実施形態と同様であるため、説明を省略する。
【０１５８】
まず、図１２を参照して、ＧＷ情報取得ノード２’の動作を説明する。図１２のステップＳ１１１〜Ｓ１１３は、第１の実施形態のステップＳ１０１〜Ｓ１０３と基本的に同様である。すなわち、ＧＷ情報取得ノード２’の動作は、第１の実施形態の情報取得ノード２の動作と比べて、ステップＳ１１４の情報の共有処理が追加されている点が大きく異なる。なお、他の点については各ステップの動作の説明において都度説明する。
【０１５９】
本例では、ＧＷ情報取得ノード２’が、まず情報取得要求送信処理（ステップＳ１１１）を行う。この処理において、まずＧＷ情報取得ノード２’の検証情報生成部２０２が、分散台帳の情報を基に、検証情報を生成する。次いで、ＧＷ情報取得ノード２’の情報要求部２０１が、生成された検証情報と、所望情報を特定可能な情報とを含む情報取得要求Ｍ１１を生成し、検証ノードグループ１０に含まれるいずれかの検証ノード１に送信する。当該処理では、分散台帳の情報を基に、検証情報を生成する点および送信時刻情報を記憶しない点が第１の実施形態の情報取得要求送信処理（ステップＳ１０１）と異なる。
【０１６０】
その後、ＧＷ情報取得ノード２’は、応答待ち処理（ステップＳ１１２）を行う。当該処理は、第１の実施形態の応答待ち処理（ステップＳ１０２）と同様である。
【０１６１】
検証ノードグループ１０に含まれるいずれかの検証ノード１から、ステップＳ１０１で送信した情報取得要求の応答とされるブロックＭ１２を受信すると、ＧＷ情報取得ノード２’の情報検証部２０３が、所望情報の検証処理（ステップＳ１１３）を行う。当該処理では、情報検証部２０３が、分散台帳の情報に基づいて、受信したブロックに含まれる所望情報の検証を行う。なお、検証方法の詳細は上述したとおりであるが、分散台帳の情報を基に検証を行う点が、第１の実施形態の所望情報の検証処理（ステップＳ１０３）と異なる。
【０１６２】
最後に、ＧＷ情報取得ノード２’は、情報の共有処理（ステップＳ１１４）を行う。当該処理では、情報検証部２０３または分散台帳処理部２０５が、検証ノード１から受信したブロックを、他の情報取得ノード２に転送する。なお、ＧＷ情報取得ノード２’は、所望情報の検証処理（ステップＳ１１３）の検証の結果、所望情報が高信頼情報と判断されなかった場合には、情報の共有処理を行わないようにしてもよい。
【０１６３】
次に、図１３を参照して、他の情報取得ノード２の動作を説明する。図１３に示すように、本実施形態のＧＷ情報取得ノード２’以外の情報取得ノード２は、ＧＷ情報取得ノード２’や他の情報取得ノード２から、所望情報を含むブロックＭ１２（応答ブロック）を受信すると、情報の共有処理（ステップＳ４１１）を行う。この処理は、図１２に示したＧＷ情報取得ノード２’における情報の共有処理（ステップＳ１１４）と同様でよい。
【０１６４】
その後、情報取得ノード２は、所望情報の検証処理（ステップＳ４１２）を行う。この処理は、図１２に示したＧＷ情報取得ノード２’における所望情報の検証処理（ステップＳ１１３）と同様でよい。
【０１６５】
なお、図１２および図１３では図示省略しているが、情報取得ノード２の各々（ＧＷ情報取得ノード２’を含む）は、これらの動作とは独立して分散台帳システムの一部としての動作を行う。
【０１６６】
以上のように、本実施形態によれば、単一の情報取得ノード２が検証ノード１から所望情報を得て、他の情報取得ノード２と共有する場合であっても、全ての情報取得ノード２において、他の情報取得ノード２に対して事前に認証に用いる情報の対応づけなしに、当該所望情報の信頼性を評価することが可能となる。仮にＧＷ情報取得ノード２’が悪意あるノードであったとしても、他の情報取得ノード２で所望情報の信頼性を評価できることから、所望情報を検知されないように改ざんすることが困難となる。
【０１６７】
また、第１の実施形態の変形例として示した通り、検証ノード１の各々も、分散台帳システムの台帳管理ノードとして動作することが可能である。この場合、独立して動作する２つの分散台帳システムの間のデータ通信に、本実施形態の情報検証方法を利用することができる。すなわち、第１の分散台帳システムの情報を、第２の分散台帳システムの台帳管理ノードが取得する際に、第２の分散台帳システムの台帳管理ノードが、取得された情報が第１の分散台帳システムの多くの台帳管理ノードに承認された情報であるか、すなわち高信頼情報であるかを、他のノードとの間で認証情報のやりとりを要せずに、また分散台帳システム間の通信負荷を増加させずに、確認できる。
【０１６８】
なお、第２の実施形態にもさまざまな変形例が存在する。以下ではその一部を示す。
【０１６９】
［変形例１］
第２の実施形態では、検証情報に、分散台帳システムが管理するブロックチェーンの一部のブロックのハッシュ値を用いることができることを述べた。検証情報は、このようなハッシュ値に限定されない。ＧＷ情報取得ノード２’以外の情報取得ノード２が、検証ノード１から送られたブロックに基づいて所望情報を検証するためには、検証情報が、全ての情報取得ノード２が参照可能であり、時刻と対応づけることが可能な情報であればよい。例えば、ブロックチェーン内に記録された情報を検証情報とすることができる。
【０１７０】
一例として、検証情報は、第１の実施形態と同様、情報取得要求を送信するノードが生成した乱数であってもよい。その場合、情報取得要求を送信する情報取得ノード２は、生成した検証情報を、分散台帳システムを用いて共有する。例えば、当該情報取得ノード２は、自ノードが属する分散台帳システムが管理するブロックチェーンに該検証情報を記録したブロックを追加した後に、情報取得要求を送信する。なお、本例において、情報取得要求の送信は、検証情報を生成した情報取得ノード２が行ってもよいし、ＧＷ情報取得ノード２’として特に定めた情報取得ノード２が、ブロックチェーンに検証情報が記録されたブロックが追加されたことを受けて、行ってもよい。
【０１７１】
ブロックチェーンの性質より、ブロックチェーンに記録された情報は、全ての台帳管理ノード（情報取得ノード２）に共有され、かつ、改ざんすることが困難である。その性質を利用して、全ての台帳管理ノードが、所望情報を検証する際に、ブロックチェーンに記録された検証情報を含むブロック以後、応答ブロックを受信するまでの間の追加ブロック数に応じて、所望情報が高信頼情報であるか否かを判定できる。
【０１７２】
なお、当該検証情報（乱数等）を含む情報取得要求が、ブロックチェーンに記録された後に送信されたものであることを示すために、検証情報にさらに、ＰｏＷ後に得られる情報（該当ブロックのノンスの値等）を含めてもよい。
【０１７３】
［変形例２］
第２の実施形態では、情報取得ノード２の各々を、ブロックチェーンを管理するような分散台帳システムの一部として構成できることを述べた。ここで、当該分散台帳システムにおけるコンセンサスアルゴリズムは、ＰｏＷに限られない。例えば、情報取得ノード２が属する分散台帳システムは、ＰＢＦＴ（Practical Byzantine Fault Tolerance）などの他のコンセンサスアルゴリズムを用いたシステムであってもよい。
【０１７４】
次に、本発明の各実施形態にかかるコンピュータの構成例を示す。図１４は、本発明の各実施形態にかかるコンピュータの構成例を示す概略ブロック図である。コンピュータ１０００は、ＣＰＵ１００１と、主記憶装置１００２と、補助記憶装置１００３と、インタフェース１００４と、ディスプレイ装置１００５とを備える。
【０１７５】
上述の各実施形態の情報検証システムの各ノードは、コンピュータ１０００に実装されてもよい。その場合、各ノードの動作は、プログラムの形式で補助記憶装置１００３に記憶されていてもよい。ＣＰＵ１００１は、プログラムを補助記憶装置１００３から読み出して主記憶装置１００２に展開し、そのプログラムに従って各実施形態における所定の処理を実施する。
【０１７６】
補助記憶装置１００３は、一時的でない有形の媒体の一例である。一時的でない有形の媒体の他の例として、インタフェース１００４を介して接続される磁気ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、半導体メモリ等が挙げられる。また、このプログラムが通信回線によってコンピュータ１０００に配信される場合、配信を受けたコンピュータは１０００がそのプログラムを主記憶装置１００２に展開し、各実施形態における所定の処理を実行してもよい。
【０１７７】
また、プログラムは、各実施形態における所定の処理の一部を実現するためのものであってもよい。さらに、プログラムは、補助記憶装置１００３に既に記憶されている他のプログラムとの組み合わせで各実施形態における所定の処理を実現する差分プログラムであってもよい。
【０１７８】
また、実施形態における処理内容によっては、コンピュータ１０００の一部の要素は省略可能である。例えば、ノードがユーザに情報を提示しないのであれば、ディスプレイ装置１００５は省略可能である。また、図１４には図示省略しているが、実施形態における処理内容によっては、コンピュータ１０００は、入力デバイスを備えていてもよい。例えば、情報取得指示や所望情報の属性情報を入力するための入力デバイスを備えていてもよい。
【０１７９】
また、各装置の各構成要素の一部または全部は、汎用または専用の回路（Circuitry）、プロセッサ等やこれらの組み合わせによって実施される。これらは単一のチップによって構成されてもよいし、バスを介して接続される複数のチップによって構成されてもよい。また、各装置の各構成要素の一部又は全部は、上述した回路等とプログラムとの組み合わせによって実現されてもよい。
【０１８０】
各装置の各構成要素の一部又は全部が複数の情報処理装置や回路等により実現される場合には、複数の情報処理装置や回路等は、集中配置されてもよいし、分散配置されてもよい。例えば、情報処理装置や回路等は、クライアントアンドサーバシステム、クラウドコンピューティングシステム等、各々が通信ネットワークを介して接続される形態として実現されてもよい。
【０１８１】
次に、本発明の概要を説明する。図１５は、本発明の情報検証システムの概要を示すブロック図である。図１５に示す情報検証システム５００は、複数のノード５１を含む第１のノード群５１０と、少なくとも１つのノード５２を含む第２のノード群５２０とを備える。また、ノード５２の少なくとも１つが、要求手段５２１と、検証手段５２２とを含む。
【０１８２】
要求手段５２１（例えば、情報要求部２０１）は、第１のノード群５１０に含まれるノード５１の少なくともいずれかに、情報を要求する要求信号であって、要求信号を送信するごとに生成される検証用の情報である検証情報を含む要求信号を送信する。
【０１８３】
検証手段５２２（例えば、情報検証部２０３）は、要求信号に対して第１のノード群５１０に含まれるノード５１のいずれかから送られてきた情報である応答情報を検証する。このとき、検証手段５２２は、応答情報に関し、要求信号で要求した情報である所望情報もしくはそのダイジェストが含まれているか否か、正しい検証情報が含まれているか否か、当該応答情報に対して一方向性関数を適用して得られる値が、第１のノード群５１０と第２のノード群５２０との間で共通に定められる所定の規則を満たすか否か、および、要求信号を送信してから所望情報を得るまでにかかった時間である応答時間を判定し、それらの判定結果に基づいて、所望情報の信頼性の有無または信頼度を判断する。
【０１８４】
このような構成により、応答情報の送信元のノード自体を特に認証しなくても、所望情報の信頼性を評価できる。
【０１８５】
ここで、応答時間の判定は、応答時間の実測値に基づく判定だけでなく、例えば、検証情報に対応づけられておりかつ応答時間が推定可能な情報に基づいて推定される応答時間に基づく判定も含まれる。また、応答情報の返信が一定時間経過後に行われる場合は、応答時間により示される、所望情報が第１のノード群に含まれるいずれかのノードに承認された以降に該ノードにおいて所定の方法により処理された情報量に基づいて、判定することも可能である。この場合、より具体的には、応答時間およびその間における第１のノード群での共有情報の増加量に基づく判定といえるが、広義には、応答時間に基づく判定といえる。
【０１８６】
また、図１６は、本発明の情報検証システムの他の例を示すブロック図である。図１６に示すように、情報検証システム５００において、第２のノード群５２０は、複数のノード５２を含んでいてもよく、そのような場合、ノード５２の各々は、分散台帳システムにおける台帳管理ノードまたは台帳管理ノードが管理する分散台帳を参照可能なノードとして実装されていてもよい。なお、図１６では、１つのノード５２が要求手段５２１と検証手段５２２とを含む例が示されているが、あるノード５２が要求手段５２１を含み、他のノード５２が検証手段５２２を含んでいてもよい。
【０１８７】
また、図１６に示すように、情報検証システム５００において、ノード５１の少なくとも１つは、応答手段５１１と、探索手段５１２とを含んでいてもよい。なお、図１６では、１つのノード５１が応答手段５１１と探索手段５１２とを含む例が示されているが、あるノード５１が応答手段５１１を含み、他のノード５１が探索手段５１２を含んでいてもよい。
【０１８８】
応答手段５１１（例えば、外部向け情報共有部１０１）は、第２のノード群５２０に含まれるノード５２のいずれかから送信された要求信号に対する応答情報として、当該応答情報が規則を満たすように設定されるノンスと、所望情報またはそのダイジェストと、要求信号に含まれていた検証情報とを含む情報を、要求元のノード５２に送信する。
【０１８９】
探索手段５１２（例えば、抽選実行部１０４）は、一方向性関数を用いて規則を満たすノンスの値を探索する。
【０１９０】
なお、上記の各実施形態は以下の付記のようにも記載できる。
【０１９１】
（付記１）複数のノードを含む第１のノード群が管理する情報の信頼性を判断するための情報検証装置であって、第１のノード群に含まれるノードの少なくともいずれかに送信された、情報を要求する要求信号であって、要求信号を送信するごとに生成される検証用の情報である検証情報を含む要求信号に対して、第１のノード群に含まれるノードのいずれかから送られてきた情報である応答情報を検証する検証手段を有し、検証手段は、応答情報に関し、要求信号で要求した情報である所望情報もしくはそのダイジェストが含まれているか否か、正しい検証情報が含まれているか否か、当該応答情報に対して一方向性関数を適用して得られる値が、第１のノード群と少なくとも情報検証装置との間で共通に定められる所定の規則を満たすか否か、および、要求信号を送信してから所望情報を得るまでにかかった時間である応答時間を判定し、それらの判定結果に基づいて、所望情報の信頼性の有無または信頼度を判断することを特徴とする情報検証装置。
【０１９２】
（付記２）要求手段は、同じ情報を要求する要求信号を複数回、第１のノード群に含まれるノードの少なくともいずれかに送信し、検証手段は、複数回分の判定結果に基づいて、所望情報の信頼性の有無または信頼度を判断する付記１に記載の情報検証装置。
【０１９３】
（付記３）分散台帳システムにおける台帳管理ノードまたは台帳管理ノードが管理する分散台帳を参照可能なノードの１つとして実装され、要求手段は、分散台帳に含まれる情報に基づいて生成される検証情報を含む要求信号を送信し、検証手段は、第１のノード群に含まれるノードから直接または第２のノード群に含まれる他のノードを介して間接的に得られる応答情報に関し、当該応答情報に含まれる検証情報の正しさを、当該検証情報が分散台帳に含まれる情報に基づいて生成されているか否かにより判定し、応答時間を、当該応答情報に含まれる検証情報が分散台帳のどの時点の情報に基づいて生成されているかおよびその時点から少なくとも当該応答情報を得た時点までの間に分散台帳に追加された台帳の数に基づいて判定する付記１または付記２に記載の情報検証装置。
【０１９４】
（付記４）複数のノードを含む第１のノード群が管理する情報の信頼性を、第１のノード群とは異なる第２のノード群に含まれるノードが判断するための情報検証方法であって、第２のノード群に含まれるノードが、第１のノード群に含まれるノードの少なくともいずれかに送信された、情報を要求する要求信号であって、要求信号を送信するごとに生成される検証用の情報である検証情報を含む要求信号に対して、第１のノード群に含まれるノードのいずれかから送られてきた情報である応答情報を検証し、応答情報を検証する処理で、応答情報に関し、要求信号で要求した情報である所望情報もしくはそのダイジェストが含まれているか否か、正しい検証情報が含まれているか否か、当該応答情報に対して一方向性関数を適用して得られる値が、第１のノード群と第２のノード群との間で共通に定められる所定の規則を満たすか否か、および、要求信号を送信してから所望情報を得るまでにかかった時間である応答時間を判定し、それらの判定結果に基づいて、所望情報の信頼性の有無または信頼度を判断することを特徴とする情報検証方法。
【０１９５】
（付記５）第２のノード群に含まれるノードが、同じ情報を要求する要求信号を複数回、第１のノード群に含まれるノードの少なくともいずれかに送信し、複数回分の判定結果に基づいて、所望情報の信頼性の有無または信頼度を判断する付記４に記載の情報検証方法。
【０１９６】
（付記６）分散台帳システムにおける台帳管理ノードまたは台帳管理ノードが管理する分散台帳を参照可能なノードとして実装される複数のノードを含む第２のノード群に含まれるノードが、分散台帳に含まれる情報に基づいて生成される検証情報を含む要求信号を送信し、第１のノード群に含まれるノードから直接または第２のノード群に含まれる他のノードを介して間接的に得られる応答情報に関し、当該応答情報に含まれる検証情報の正しさを、当該検証情報が分散台帳に含まれる情報に基づいて生成されているか否かにより判定し、応答時間を、当該応答情報に含まれる検証情報が分散台帳のどの時点の情報に基づいて生成されているかおよびその時点から少なくとも当該応答情報を得た時点までの間に分散台帳に追加された台帳の数に基づいて判定する付記４または付記５に記載の情報検証方法。
【０１９７】
（付記７）複数のノードを含む第１のノード群が管理する情報の信頼性を、第１のノード群とは異なる第２のノード群に含まれるノードが判断するための情報検証プログラムであって、第２のノード群に含まれるノードが備えるコンピュータに、第１のノード群に含まれるノードの少なくともいずれかに送信された、情報を要求する要求信号であって、要求信号を送信するごとに生成される検証用の情報である検証情報を含む要求信号に対して、第１のノード群に含まれるノードのいずれかから送られてきた情報である応答情報を検証する検証処理を実行させ、検証処理で、応答情報に関し、要求信号で要求した情報である所望情報もしくはそのダイジェストが含まれているか否か、正しい検証情報が含まれているか否か、当該応答情報に対して一方向性関数を適用して得られる値が、第１のノード群と第２のノード群との間で共通に定められる所定の規則を満たすか否か、および、要求信号を送信してから所望情報を得るまでにかかった時間である応答時間を判定させ、それらの判定結果に基づいて、所望情報の信頼性の有無または信頼度を判断させるための情報検証プログラム。
【０１９８】
（付記８）コンピュータに、第１のノード群に含まれるノードの少なくともいずれかに、要求信号を送信する要求処理を実行させる付記７に記載の情報検証プログラム。
【０１９９】
（付記９）コンピュータに、要求処理で、同じ情報を要求する要求信号を複数回、第１のノード群に含まれるノードの少なくともいずれかに送信させ、検証処理で、複数回分の判定結果に基づいて、所望情報の信頼性の有無または信頼度を判断させる付記８に記載の情報検証プログラム。
【０２００】
（付記１０）分散台帳システムにおける台帳管理ノードまたは台帳管理ノードが管理する分散台帳を参照可能なノードとして実装される複数のノードを含む第２のノード群に含まれるノードが備えるコンピュータに、要求処理で、分散台帳に含まれる情報に基づいて生成される検証情報を含む要求信号を送信させ、判定処理で、第１のノード群に含まれるノードから直接または第２のノード群に含まれる他のノードを介して間接的に得られる応答情報に関し、当該応答情報に含まれる検証情報の正しさを、当該検証情報が分散台帳に含まれる情報に基づいて生成されているか否かにより判定させ、応答時間を、当該応答情報に含まれる検証情報が分散台帳のどの時点の情報に基づいて生成されているかおよびその時点から少なくとも当該応答情報を得た時点までの間に分散台帳に追加された台帳の数に基づいて判定させる付記８または付記９に記載の情報検証プログラム。
【０２０１】
以上、本実施形態および実施例を参照して本願発明を説明したが、本願発明は上記実施形態および実施例に限定されるものではない。本願発明の構成や詳細には、本願発明のスコープ内で当業者が理解し得る様々な変更をすることができる。
【産業上の利用可能性】
【０２０２】
本発明は、あるノード群が持つ情報を当該ノード群に属さないノードが取得する場合に、その情報の信頼性を評価する用途に好適に適用可能である。
【符号の説明】
【０２０３】
１００、２００、５００  情報検証システム
１０  検証ノードグループ
１  検証ノード
１’  ＧＷ検証ノード
１０１  外部向け情報共有部
１０２  検証ノード間情報共有部
１０３  ブロック生成部
１０４  抽選実行部
１０５  情報検証部
１０６  情報記憶部
２  情報取得ノード
２’  ＧＷ情報取得ノード
２０１  情報要求部
２０２  検証情報生成部
２０３  情報検証部
２０４  情報記憶部
２０５  分散台帳処理部
２０  情報取得ノードグループ
５１０  第１のノード群
５１１  応答手段
５１２  探索手段
５２０  第２のノード群
５２１  要求手段
５２２  検証手段
５１、５２  ノード
１０００  コンピュータ
１００１  ＣＰＵ
１００２  主記憶装置
１００３  補助記憶装置
１００４  インタフェース
１００５  ディスプレイ装置
【図１】
0006798604.tif 000002
【図２】
0006798604.tif 000003
【図３】
0006798604.tif 000004
【図４】
0006798604.tif 000005
【図５】
0006798604.tif 000006
【図６】
0006798604.tif 000007
【図７】
0006798604.tif 000008
【図８】
0006798604.tif 000009
【図９】
0006798604.tif 000010
【図１０】
0006798604.tif 000011
【図１１】
0006798604.tif 000012
【図１２】
0006798604.tif 000013
【図１３】
0006798604.tif 000014
【図１４】
0006798604.tif 000015
【図１５】
0006798604.tif 000016
【図１６】
0006798604.tif 000017