JP7429755B2 - 検査システム、検査方法、およびコンピュータプログラム - Google Patents

Description

本発明はデータ処理技術に関し、特に検査システム、検査方法、およびコンピュータプログラムに関する。

近年、情報セキュリティが重要視されており、多くのコンピュータにアンチウイルスソフトウェアが導入されている（例えば、特許文献１参照）。

特開２０１７－０２１７７９号公報

アンチウイルスソフトウェアの導入は進んでいるが、現実的に、１つのアンチウイルスソフトウェアで全てのマルウェア（コンピュータウイルス、トロイの木馬、スパイウェア等）を検出することはできない。また、１つのコンピュータに、ベンダーや特性が異なる複数種類のアンチウイルスソフトウェアを導入することには、多大なコストがかかる。

本発明は、上記課題に鑑みてなされたものであり、１つの目的は、電子データの検査を支援する技術を提供することにある。

上記課題を解決するために、本発明のある態様の検査システムは、検査対象データを所定領域へ記録する第１の装置と、検査対象データが不正か否かを検査するユーザにより操作される第２の装置と、検査対象データに対する検査結果を使用する第３の装置と、を備える。第２の装置は、第１の装置により記録された検査対象データを取得して、検査対象データに対する検査結果を所定領域へ記録し、第３の装置は、第２の装置により記録された検査結果を取得する。

本発明の別の態様もまた、検査システムである。この検査システムは、検査の依頼者により操作される依頼者装置と、一人以上の検査者により操作される一つ以上の検査者装置と、依頼者装置と検査者装置とがアクセス可能なブロックチェーンシステムと、を備える。依頼者装置は、検査対象データを所定領域へ記録するとともに、検査の報酬をブロックチェーンシステムへ記録し、検査者装置は、依頼者装置により記録された検査対象データを取得して、検査対象データに対する検査結果を所定領域へ記録し、依頼者装置は、検査者装置により記録された検査結果を取得し、依頼者により検査結果が正解と認定された検査者である正解者のデータをブロックチェーンシステムへ記録し、ブロックチェーンシステムは、正解者に対して検査の報酬を分配する。

本発明のさらに別の態様は、検査方法である。この方法は、第１の装置が、検査対象データを所定領域へ記録するステップと、検査対象データが不正か否かを検査するユーザにより操作される第２の装置が、第１の装置により記録された検査対象データを取得するステップと、第２の装置が、検査対象データに対する検査結果を所定領域へ記録するステップと、検査対象データに対する検査結果を使用する第３の装置が、第２の装置により記録された検査結果を取得するステップと、を備える。

本発明のさらに別の態様もまた、検査方法である。この方法は、検査の依頼者により操作される依頼者装置が、検査対象データを所定領域へ記録するとともに、検査の報酬をブロックチェーンシステムへ記録するステップと、一人以上の検査者により操作される一つ以上の検査者装置のそれぞれが、依頼者装置により記録された検査対象データを取得して、検査対象データに対する検査結果を所定領域へ記録するステップと、依頼者装置が、一つ以上の検査者装置により記録された検査結果を取得し、依頼者により検査結果が正解と認定された検査者である正解者のデータをブロックチェーンシステムへ記録するステップと、ブロックチェーンシステムが、正解者に対して検査の報酬を分配するステップと、を備える。

なお、以上の構成要素の任意の組合せ、本発明の表現を、プログラム、プログラムを格納した記録媒体などの間で変換したものもまた、本発明の態様として有効である。

本発明によれば、電子データの検査を支援することができる。

第１実施例の検査システムの構成を示す図である。 図１のファイルサーバの機能構成を示すブロック図である。 図１のユーザ装置の機能構成を示すブロック図である。 ＶＣの概念的なプログラムコードを示す図である。 ＶＣの概念的なプログラムコードを示す図である。 ＩＣの概念的なプログラムコードを示す図である。 検査Ａｐｐの概念的なプログラムコードを示す図である。 依頼者装置の動作を示すフローチャートである 検査者装置の動作を示すフローチャートである。 閲覧者装置の動作を示すフローチャートである。 変形例３の検査システムの構成を示す図である。 第２実施例の検査システムの構成を示す図である。 図１１の依頼者装置の機能ブロックを示すブロック図である。 図１１の検査者装置の機能ブロックを示すブロック図である。 図１１の閲覧者装置の機能ブロックを示すブロック図である。 図１１のブロックチェーンシステムの機能ブロックを示すブロック図である。 検査情報の例を示す図である。 検査の依頼に関する動作を示すフローチャートである。 検査の実施に関する動作を示すフローチャートである。 依頼者の結果判定に関する動作を示すフローチャートである。 検査者による最終コミットに関する動作を示すフローチャートである。 検査結果閲覧時の動作を示すフローチャートである。 変形例の検査システムの構成を示す図である。 変形例における検査情報の例を示す図である。 図２２の協賛者装置の機能ブロックを示すブロック図である。

（第１実施例）
第１実施例では、正当性が不明の電子ファイルをユーザがネットワーク上にアップロードすると、ネットワークに接続された他のユーザが当該電子ファイルの正当性を検査する情報処理システム（後述の検査システム）を実現する技術を提案する。正当性が不明の電子ファイルは、マルウェアを含みうる電子ファイルとも言える。実施例の検査システムは、データの改ざんが困難な分散型ネットワークであるブロックチェーンネットワークを含む。

図１は、第１実施例の検査システム１０の構成を示す。検査システム１０は、依頼者装置１２、検査者装置１４、閲覧者装置１６、ファイルサーバ１８を備える。図１の各装置は、ＬＡＮ・ＷＡＮ・インターネット等を含む通信網２０を介して接続される。

依頼者装置１２は、電子データ（実施例では電子ファイル）の検査を外部に依頼するユーザ（以下「依頼者」とも呼ぶ。）により操作される情報処理装置である。検査対象となる電子ファイル（以下「被験ファイル」とも呼ぶ。）は、マルウェアの存在が疑われる電子ファイル、または、安全性を確認したい電子ファイルであってもよい。

検査者装置１４は、被験ファイルの正当性（言い換えれば不正の有無、マルウェアの有無）を検査するユーザ（以下「検査者」とも呼ぶ。）により操作される情報処理装置である。検査者は、例えば、情報セキュリティ技術の専門家でもよい。閲覧者装置１６は、被験ファイルに対する検査結果を閲覧するユーザ（以下「閲覧者」とも呼ぶ。）により操作される情報処理装置であり、また、検査結果を用いたデータ処理を実行する情報処理装置である。依頼者装置１２、検査者装置１４、閲覧者装置１６は、例えばＰＣ、タブレット端末、スマートフォンであってもよい。

依頼者装置１２、検査者装置１４、閲覧者装置１６には、ブロックチェーンネットワーク２２を形成し、利用するためのライブラリおよびアプリケーション（以下「検査Ａｐｐ」とも呼ぶ。）が導入される。言い換えれば、依頼者装置１２、検査者装置１４、閲覧者装置１６は、公知のブロックチェーンの仕組みに基づいてＰ２Ｐ（Peer to Peer）通信を実行し、ブロックチェーンネットワーク２２を形成する。

なお、実際には、多くのユーザが、依頼者、検査者、閲覧者のいずれかの立場で検査システム１０に参加することができる。また、各ユーザは、依頼者、検査者、閲覧者のいずれになることもできる。例えば、被験ファイルＡの検査における依頼者装置１２は、別の被験ファイルＢの検査では、検査者装置１４になるかもしれないし、閲覧者装置１６になるかもしれない。また、被験ファイルＣの検査における検査者装置１４は、別の被験ファイルＤの検査では依頼者装置１２になるかもしれないし、閲覧者装置１６になるかもしれない。さらにまた、依頼者と閲覧者は同一でもよく、すなわち、依頼者装置１２と閲覧者装置１６は同一でもよい。以下、図１の依頼者装置１２、検査者装置１４、閲覧者装置１６を総称する場合、「ユーザ装置２４」と呼ぶ。

ファイルサーバ１８は、依頼者装置１２から被験ファイルが登録され、登録された被験ファイルを検査者装置１４へ提供する情報処理装置である。ファイルサーバ１８には、上記の検査Ａｐｐは導入されない。すなわち、ファイルサーバ１８は、ブロックチェーンネットワーク２２に参加しない装置であり、言い換えれば、ブロックチェーンネットワーク２２の外部に存在する装置である。なお、ファイルサーバ１８は、複数台のサーバで構成されてもよい。

以下、検査システム１０の構成要素をブロック図を使用して説明する。本明細書のブロック図において示される各ブロックは、ハードウェア的には、コンピュータのＣＰＵ・メモリをはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現できることは、当業者には理解されるところである。

図２は、図１のファイルサーバ１８の機能構成を示すブロック図である。ファイルサーバ１８は、被験データ保持部３０、被験データ受付部３２、被験データ提供部３４を備える。被験データ保持部３０は、被験データを、その記憶位置を示すアドレス（例えばＵＲＬ文字列でもよく、以下「被験ファイルアドレス」とも呼ぶ。）に対応付けて記憶する。

被験データ受付部３２は、被験ファイルの登録要求を依頼者装置１２から受信する。被験データ受付部３２は、登録要求に含まれる被験ファイルを被験データ保持部３０に格納する。被験データ受付部３２は、登録要求への応答として、被験ファイルアドレスを依頼者装置１２へ送信する。

被験データ提供部３４は、被験ファイルの提供要求を検査者装置１４から受信する。被験ファイルの提供要求は、特定の被験ファイルを示すアドレス（被験ファイルアドレス）の指定を含む。被験データ提供部３４は、被験データ保持部３０に格納された複数の被験ファイルのうち、指定された被験ファイルアドレスで特定される被験ファイルを検査者装置１４へ送信する。

図３は、図１のユーザ装置２４（すなわち依頼者装置１２、検査者装置１４、閲覧者装置１６）の機能構成を示すブロック図である。ユーザ装置２４は、入力部４０、表示部４２、制御部４４を備える。入力部４０は、ユーザの操作を受け付け、操作内容を制御部４４へ入力する。表示部４２は、制御部４４から出力された画像データを画面に表示する。

制御部４４は、各種データ処理を実行し、依頼処理部４６、検査処理部４８、閲覧処理部５０を備える。これらのブロックの機能は、ユーザ装置２４のＣＰＵが、ユーザ装置２４のメモリに格納された検査Ａｐｐ５２を実行することにより実現されてもよい。依頼処理部４６、検査処理部４８、閲覧処理部５０のそれぞれは、後説するように、複数のモジュールからなるものの、その全部又は一部のモジュールについてはファイルサーバ１８又はファイルサーバ１８とは異なる新たなサーバに実装する構成であってもよい。

以降の説明におけるブロックチェーンネットワーク２２からのデータの取得、および、ブロックチェーンネットワーク２２上のデータの更新は、ユーザ装置２４にインストールされたブロックチェーンネットワーク２２のライブラリが備えるＡＰＩ（Application Programming Interface）を呼び出すことにより実現される。実際には、ブロックチェーンネットワーク２２のデータは、依頼者装置１２、検査者装置１４、閲覧者装置１６で分散管理され、ブロックチェーンネットワーク２２の基盤アプリケーションにより、装置間でのデータ同期が実現される。

依頼処理部４６は、主に依頼者装置１２における処理を実行する。依頼処理部４６は、被験データ登録部５４、ＳＣ生成部５６、インデックス更新部５８を含む。

被験データ登録部５４は、被験ファイルをファイルサーバ１８へ送信することにより、被験ファイルをファイルサーバ１８に登録する。被験データ登録部５４は、被験ファイルの登録時に、ファイルサーバ１８における記憶位置を示す被験ファイルアドレス（例えばＵＲＬ文字列）をファイルサーバ１８から取得する。

ＳＣ生成部５６は、被験データ登録部５４によりファイルサーバ１８に登録された被験ファイルに関する属性情報を含むスマートコントラクトを生成する。スマートコントラクトは、ブロックチェーン上で動作するエージェントプログラムとも言える。このスマートコントラクトは、例えば後述の「VirusContract」クラスのインスタンスであり、ウイルスコントラクトの意味で以下「ＶＣ」と呼ぶ。被験ファイルに関する属性情報は、ファイルサーバ１８における被験ファイルアドレスを含む。ＳＣ生成部５６は、生成したＶＣをブロックチェーンネットワーク２２に登録する。言い換えれば、ブロックチェーンネットワーク２２のデータ（台帳データとも言える）に、生成したＶＣを追加する。

インデックス更新部５８は、複数のＶＣのアドレス（すなわちブロックチェーンネットワーク２２上での位置情報）を含むスマートコントラクトをブロックチェーンネットワーク２２から取得する。このスマートコントラクトは、例えば後述の「IndexContract」クラスのインスタンスであり、インデックスコントラクトの意味で以下「ＩＣ」と呼ぶ。インデックス更新部５８は、取得したＩＣに、ＳＣ生成部５６により生成されたＶＣのアドレスと、被験ファイルの識別情報（実施例ではハッシュ値）とを追加する。

検査処理部４８は、主に検査者装置１４における処理を実行する。検査処理部４８は、インデックス取得部６０、ＳＣ取得部６２、被験データ取得部６４、ＳＣ更新部６６を含む。

インデックス取得部６０は、ブロックチェーンネットワーク２２からＩＣを取得する。ＳＣ取得部６２は、検査者により指定された被験ファイルの識別情報（実施例では被験ファイルのハッシュ値）に対応付けられたＶＣのアドレスをＩＣから取得する。ＳＣ取得部６２は、アドレスにより特定されるＶＣをブロックチェーンネットワーク２２から取得する。被験データ取得部６４は、ＶＣから被験ファイルアドレスを取得する。被験データ取得部６４は、ファイルサーバ１８にアクセスし、被験ファイルアドレスにより特定される被験ファイルをファイルサーバ１８からダウンロードする。

ＳＣ更新部６６は、検査者による被験ファイルの検査後に、その検査結果を被験ファイルのＶＣに記録する。ＳＣ更新部６６は、検査結果記録後の被験ファイルのＶＣをブロックチェーンネットワーク２２に登録する。言い換えれば、ＳＣ更新部６６は、ブロックチェーンネットワーク２２上に保存された、被験ファイルのＶＣに、検査者による検査結果を反映する。

閲覧処理部５０は、インデックス取得部６８、ＳＣ取得部７０、検査結果取得部７２、送金部７４、検査結果出力部７６を含む。

インデックス取得部６８は、ブロックチェーンネットワーク２２からＩＣを取得する。ＳＣ取得部７０は、閲覧者により指定された被験ファイルの識別情報（実施例では被験ファイルのハッシュ値）に対応付けられたＶＣのアドレスをＩＣから取得する。ＳＣ取得部７０は、アドレスにより特定されるＶＣをブロックチェーンネットワーク２２から取得する。検査結果取得部７２は、ＳＣ取得部７０により取得されたＶＣから被験ファイルの検査結果を取得する。言い換えれば、検査結果取得部７２は、ブロックチェーンネットワーク２２上に保存された、被験ファイルの検査結果を取得する。

送金部７４は、検査結果が取得されるタイミングと同期して、検査者と依頼者の両方への報酬支払を実行する。例えば、送金部７４は、閲覧者の口座から検査者の口座への送金（振込）処理を実行するとともに、閲覧者の口座から依頼者の口座への送金処理を実行してもよい。なお、検査結果取得部７２は、送金部７４による送金処理が成功したことを条件として、被験ファイルの検査結果を取得してもよい。

また、送金部７４は、閲覧者から依頼者への送金、および、閲覧者から検査者への送金に関する情報をブロックチェーンネットワーク２２（もしくは金銭交換用の他のブロックチェーン）の台帳データに記録してもよい。これにより、報酬支払の確実性を高め、また、支払金額の改ざんを防止することができる。

検査結果出力部７６は、検査結果取得部７２により取得された検査結果のデータを表示部４２へ出力し、その検査結果を表示部４２に表示させる。なお、実施例では、依頼処理部４６、検査処理部４８、閲覧処理部５０を含む検査Ａｐｐ５２が、依頼者装置１２、検査者装置１４、閲覧者装置１６に導入される。変形例として、依頼処理部４６の機能のみを含む検査Ａｐｐが依頼者装置１２に導入されてもよい。また、検査処理部４８の機能のみを含む検査Ａｐｐが検査者装置１４に導入され、また、閲覧処理部５０の機能のみを含む検査Ａｐｐが閲覧者装置１６に導入されてもよい。

図４（ａ）と図４（ｂ）は、ＶＣの概念的なプログラムコード（VirusContract.java）（「java」は登録商標）を示す。図４（ｂ）は、図４（ａ）の続きを示している。図５は、ＩＣの概念的なプログラムコード（IndexContract.java）を示す。図６は、ＶＣおよびＩＣを利用する検査Ａｐｐ５２の概念的なプログラムコード（FlowTest.java）を示す。これらのプログラムコードは、後述のフローチャートの説明で適宜参照する。

以上の構成による検査システム１０の動作を説明する。
図７は、依頼者装置１２の動作を示すフローチャートである。検査Ａｐｐ５２のＧＵＩにおいて検査対象となる被験ファイルを依頼者が指定した場合（Ｓ１０のＹ）、依頼者装置１２の被験データ登録部５４は、被験ファイルをファイルサーバ１８へ登録する。それとともに被験データ登録部５４は、ファイルサーバ１８における被験ファイルアドレスをファイルサーバ１８から取得する（Ｓ１２）。被験データ登録部５４は、被験ファイルと、被験ファイルアドレスとをＳＣ生成部５６に渡す。

ＳＣ生成部５６は、図６のコード８０に示すように、ブロックチェーンネットワーク２２上での依頼者装置１２のアドレス、被験ファイルアドレス、被験ファイルのハッシュ値をパラメータとして、被験ファイル用のスマートコントラクト（以下「ＶＣ」）を生成する（Ｓ１４）。ハッシュ値の生成に使用するハッシュ関数は、例えばＭＤ５でもよい。コード８０では不図示だが、ＳＣ生成部５６はさらに、生成したＶＣインスタンスをブロックチェーンネットワーク２２に登録するとともに、ＶＣインスタンスのブロックチェーンネットワーク２２上でのアドレスを取得する。

インデックス更新部５８は、図６のコード８２に示すように、インデックス用のスマートコントラクト（以下「ＩＣ」）を取得する。実際には、インデックス更新部５８は、ブロックチェーンネットワーク２２のＡＰＩをコールして、ブロックチェーンネットワーク２２に登録されたＩＣを取得する。インデックス更新部５８は、取得したＩＣが持つアドレスマップ（図５のaddressMap）に、被験ファイルのハッシュ値（キー）と、ＶＣのアドレス（値）を追加する（Ｓ１６）。被験ファイルを指定する操作が入力されなければ（Ｓ１０のＮ）、Ｓ１２～Ｓ１６をスキップして本図のフローを終了する。

図８は、検査者装置１４の動作を示すフローチャートである。検査Ａｐｐ５２のＧＵＩにおいて特定の被験ファイルの取得を検査者が要求した場合（Ｓ２０のＹ）、検査者装置１４のインデックス取得部６０は、ブロックチェーンネットワーク２２に登録されたＩＣを取得する（Ｓ２２）。実施例では、検査者は取得すべき被験ファイルのハッシュ値を指定する。ＳＣ取得部６２は、図６のコード８４に示すように、被験ファイルのハッシュ値をキーとして、被験ファイルのＶＣのアドレスをＩＣから取得する。そしてＳＣ取得部６２は、ＶＣのアドレスをキーとして、ブロックチェーンネットワーク２２に登録された被験ファイルのＶＣを取得する（Ｓ２４）。

被験データ取得部６４は、図６のコード８６に示すように、ファイルサーバ１８における被験ファイルアドレスをＶＣから取得する。そして被験データ取得部６４は、被験ファイルアドレスをキーとして、ファイルサーバ１８から被験ファイルを取得する（Ｓ２６）。被験ファイルの取得を要求する操作が入力されなければ（Ｓ２０のＮ）、Ｓ２２～Ｓ２６をスキップする。被験ファイルを取得した検査者は、検査者装置１４または他の装置を使用して、被験ファイルが不正か否か（例えばマルウェアが含まれるか否か）を検査する。例えば、検査者は、既存のアンチウイルスソフトウェアを使用して検査を実行してもよい。また、検査者は、被験ファイルのバイナリを手動で解析してもよい。

検査Ａｐｐ５２のＧＵＩにおいて、検査者は、判定結果、付加情報、検査方法を含む検査結果情報を入力する。被験ファイルに対する検査結果の登録を検査者が要求した場合（Ｓ２８のＹ）、ＳＣ更新部６６は、図６のコード８８、図４（ｂ）のコード９０に示すように、ブロックチェーンネットワーク２２上での検査者のアドレスと、検査結果情報とを被験ファイルのＶＣに追加する（Ｓ３０）。コード８８では不図示だが、ＳＣ更新部６６はさらに、検査結果情報を追加したＶＣをブロックチェーンネットワーク２２に登録する。検査結果の登録を要求する操作が入力されなければ（Ｓ２８のＮ）、Ｓ３０をスキップして本図のフローを終了する。

図９は、閲覧者装置１６の動作を示すフローチャートである。検査Ａｐｐ５２のＧＵＩにおいて検査結果を閲覧する対象の被験ファイルを閲覧者が選択した場合（Ｓ４０のＹ）、閲覧者装置１６のインデックス取得部６８は、ブロックチェーンネットワーク２２に登録されたＩＣを取得する（Ｓ４２）。実施例では、検査者は、検査結果閲覧対象の被験ファイルのハッシュ値を指定する。ＳＣ取得部６２は、図６のコード９２に示すように、被験ファイルのハッシュ値をキーとして、被験ファイルのＶＣのアドレスをＩＣから取得する。そしてＳＣ取得部６２は、ＶＣのアドレスをキーとして、ブロックチェーンネットワーク２２に登録された被験ファイルのＶＣを取得する（Ｓ４４）。

図６のコード９４に示すように、検査結果取得部７２は、被験ファイルに対する検査結果を登録した検査者の一覧を取得し、検査結果出力部７６は、検査者の一覧を表示部４２に表示させる（Ｓ４６）。検査結果を表示すべき特定の検査者を閲覧者が選択するまで待機する（Ｓ４８のＮ）。特定の検査者を閲覧者が選択した場合（Ｓ４８のＹ）、検査結果取得部７２は、選択された検査者による検査結果を取得する（Ｓ５０）。具体的には、図６のコード９６、図４（ａ）のコード９８に示すように、検査結果取得部７２は、閲覧者のアドレスと、選択された検査者のアドレスをパラメータとして指定し、その検査者のアドレスに対応付けられた検査結果を取得する。

送金部７４は、図４（ａ）のコード９８に示すように、閲覧者から依頼者への送金処理を実行するとともに、閲覧者から検査者への送金処理を実行する。さらに実施例では、送金部７４は、閲覧者から検査システム１０の管理者への送金処理を実行する（Ｓ５２）。すなわち、閲覧者が検査結果を閲覧することを契機として、依頼者・検査者・管理者の３者へ報酬が支払われる。検査結果出力部７６は、図６のコード１００に示すように、検査結果取得部７２により取得された検査結果を表示部４２に表示させる（Ｓ５４）。検査結果を閲覧する対象の被験ファイルが未選択であれば（Ｓ４０のＮ）、Ｓ４２～Ｓ５４をスキップして本図のフローを終了する。

１つの被験ファイルの検査に関する検査システム１０の動作は、被験ファイルの登録、被験ファイルの検査、検査結果の閲覧という流れになる。したがって、１つの被験ファイルの検査では、依頼者装置１２による図７の処理、検査者装置１４による図８の処理、閲覧者装置１６による図９の処理が順次実行される。実際の検査システム１０では、複数の被験ファイルに対する処理が並行して実行される。なお、依頼者装置１２、検査者装置１４、閲覧者装置１６は、ブロックチェーンネットワーク２２におけるデータ（ＶＣ、ＩＣ等）の同期処理を常時実行する。

実施例の検査システム１０によると、依頼者がアップロードした電子データの正当性を、ネットワーク上の１人以上の検査者が検査し、その検査結果を閲覧者（依頼者を含む）が確認可能になる。これにより、アンチウイルスソフトウェアだけでは万全とは言い難いマルウェアの検出について、他のユーザの協力によりマルウェアの検出精度を向上することができる。

また、検査システム１０では、被験ファイルの属性情報および検査結果は、ブロックチェーンネットワーク２２を介して送受信される。これにより、被験ファイルの属性情報および検査結果を改ざんすることが困難となり、セキュリティの強度を一層高めることができる。また、比較的データサイズが大きい被験ファイル自体は、ブロックチェーンネットワーク２２の外で送受信することにより、ブロックチェーンネットワーク２２の負荷を抑制できる。

また、検査システム１０では、閲覧者が検査結果を閲覧するときに、依頼者および検査者へ報酬が支払われる。これにより、検査システム１０に対する被験ファイルのアップロードと、被験ファイルの検査に対するインセンティブを提供できる。また、閲覧者は、閲覧する検査結果を検査者の単位で指定可能である。すなわち、閲覧者は、検査結果の正確性が高い検査者、信頼する検査者等、所望の検査者による検査結果を選択的に閲覧できる。これにより、報酬の支払先が閲覧者により選択された検査者に限定され、また、正確な検査結果を登録するインセンティブを検査者へ提供できる。

以上、本発明を第１実施例をもとに説明した。この第１実施例は例示であり、各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。

（変形例１）
上記実施例では、被験ファイルをファイルサーバ１８で管理する一方、被験ファイルに関する様々な属性情報（アドレスや検査結果等）を依頼者装置１２、検査者装置１４、閲覧者装置１６により形成されるブロックチェーンネットワーク２２で管理した。変形例として、被験ファイルと、被験ファイルに関する属性情報の両方を１つの装置（ここでは「検査支援装置」と呼ぶ。）が集中的に管理してもよい。

検査支援装置は、実施例のファイルサーバ１８の機能と、実施例のブロックチェーンネットワーク２２の機能の両方を備えてもよい。具体的には、検査支援装置は、実施例のファイルサーバ１８における被験データ保持部３０、被験データ受付部３２、被験データ提供部３４に加えて、検査結果保持部、検査結果受付部、検査結果提供部を備えてもよい。検査結果保持部は、被験データ（例えば被験データアドレス）と対応付けて検査結果を記憶してもよい。検査結果受付部は、検査者装置１４から送信された、被験ファイルに対する検査結果を示す情報を受信して検査結果保持部へ格納してもよい。検査結果提供部は、検査結果保持部に記憶された検査結果のうち、閲覧者装置１６により指定された被験ファイルに対応する検査結果を閲覧者装置１６へ提供してもよい。

（変形例２）
依頼者装置１２、検査者装置１４、閲覧者装置１６は、被験ファイルの検査のための処理を、人の操作に依存せず、自動実行する装置であってもよい。例えば、依頼者装置１２は、正当性の判別が困難な電子ファイルの存在を検出すると、その電子ファイルを被験ファイルとしてファイルサーバ１８へアップロードし、その被験ファイルのＳＣを生成し、さらにＩＣを更新する処理を自動的に実行してもよい。

変形例２の依頼者装置１２は、電子メールサーバでもよく、被験ファイルは、電子メールへの添付ファイルであってもよい。電子メールサーバは、ローカルのアンチウイルスソフトウェアでは異常が検出されない添付ファイルを被験ファイルとしてファイルサーバ１８へアップロードしてもよい。また、電子メールサーバは、ローカルのアンチウイルスソフトウェアでは異常が検出されないが、ファイルの種類・サイズ・名称等が所定の基準（ホワイトリスト等）を逸脱する添付ファイルを被験ファイルとしてファイルサーバ１８へアップロードしてもよい。

また、変形例２の閲覧者装置１６は、被験ファイルの検査結果を表示することに代えて、検査結果に応じて被験ファイルを削除してもよい。また、検査結果が被験ファイルの不正を示す場合、閲覧者装置１６は、被験ファイルに基づく所定のデータ処理を中止してもよい。例えば、閲覧者装置１６は、電子メールサーバでもよい。この電子メールサーバは、被験ファイルが不正と判定された場合、被験ファイルが添付された電子メールの転送を中止してもよく、当該電子メールを破棄してもよい。

（変形例３）
図１０は、変形例３の検査システムの構成を示す。上記実施例の検査システム１０では、被験ファイルは、ファイルサーバ１８に登録された。変形例３では、検査システム１０は、ファイルサーバ１８を備えず、被験ファイルは、ブロックチェーンネットワーク２２（図１０の破線）とは異なるＰ２Ｐネットワーク２６（図１０の一点鎖線）に登録される。

変形例３のユーザ装置２４のそれぞれには、被験ファイルをＰ２Ｐ通信で交換するための公知ライブラリおよびアプリケーション（以下「Ｐ２Ｐモジュール」とも呼ぶ。）が導入されてもよい。ユーザ装置２４（言い換えれば依頼者装置１２）の被験データ登録部５４は、Ｐ２Ｐモジュールを利用して、Ｐ２Ｐネットワーク２６に被験ファイル（もしくは被験ファイルおよびそのハッシュ値）を登録してもよい（図７のＳ１２）。例えば、被験データ登録部５４は、他の複数のユーザ装置２４のそれぞれへ被験ファイルを送信してもよい。

また、ユーザ装置２４（言い換えれば検査者装置１４）の被験データ取得部６４は、Ｐ２Ｐモジュールを利用して、Ｐ２Ｐネットワーク２６に登録された被験ファイルを取得してもよい（図８のＳ２６）。例えば、被験データ取得部６４は、ブロックチェーンネットワーク２２から取得した被験ファイルのハッシュ値をキーとして、Ｐ２Ｐネットワーク２６内のストレージからそのハッシュ値に対応する被験ファイルを取得してもよい。

変形例３の別態様として、あるユーザ装置２４（依頼者装置１２）のローカルストレージに登録された被験ファイルを、別のユーザ装置２４（検査者装置１４）が取得もしくは参照する構成でもよい。変形例３の構成によると、ファイルサーバ１８を設けることなく、異なるユーザ装置２４間で被験ファイルを交換することができる。

（第２実施例）
第２実施例においても、ブロックチェーン技術を活用して、電子データ（以下「検体」とも呼ぶ。）の検査を支援する検査システムを提案する。第２実施例の検体は、第１実施例の被験ファイルに相当する。典型的には、検体は、マルウェアの存在が疑われる電子ファイル、または、安全性を確認したい電子ファイルであるが、検査対象となる様々な電子データであってもよい。以下、第１実施例で説明した要素と同じ要素には同じ符号を付して説明する。また、第１実施例で説明済みの内容は再度の説明を適宜省略する。

図１１は、第２実施例の検査システム１０１の構成を示す。検査システム１０１は、依頼者装置１２、検査者装置１４ａ、検査者装置１４ｂ、検査者装置１４ｃ、閲覧者装置１６、ファイルサーバ１８、ポータルサーバ１０２を備える。これらの装置は、通信網２０を介して接続される。

検査者装置１４ａ、検査者装置１４ｂ、検査者装置１４ｃは、異なる検査者により操作される情報処理装置である。検査者装置１４ａ、検査者装置１４ｂ、検査者装置１４ｃを総称する場合、検査者装置１４と呼ぶ。ポータルサーバ１０２は、検査システム１０１に関する各種情報を依頼者装置１２、検査者装置１４、および閲覧者装置１６へ提供するウェブアプリケーションサーバである。

また、検査システム１０１は、第１実施例のブロックチェーンネットワーク２２に相当するブロックチェーンシステム１０４を備える。依頼者装置１２、検査者装置１４、閲覧者装置１６には、ブロックチェーンシステム１０４を形成し、利用するためのライブラリおよびアプリケーションが導入される。

ブロックチェーンシステム１０４は、分散型データベースシステム（分散型台帳システム）とも言え、ブロックチェーンのプラットフォームの１つであるイーサリアム上に構築される。ブロックチェーンシステム１０４は、３つのスマートコントラクトのプログラムであるウイルスＳＣ１０６、トークンＳＣ１０８、アクターＳＣ１１０を含む。これらのスマートコントラクトは、依頼者装置１２、検査者装置１４、閲覧者装置１６、ポータルサーバ１０２のそれぞれからアクセス可能であり、これらの装置間で同期される。

ウイルスＳＣ１０６は、検体の検査に関するデータ保存およびデータ処理を実行するスマートコントラクトである。トークンＳＣ１０８は、検査システム１０１内での仮想通貨であるトークンに関するデータ保存およびデータ処理を実行するスマートコントラクトである。アクターＳＣ１１０は、検査システム１０１のアクター（主に依頼者および検査者）に関するデータ保存およびデータ処理を実行するスマートコントラクトである。

図１１では、依頼者装置１２および閲覧者装置１６を１つ描いたが、検査システム１０１は、異なる依頼者の複数の依頼者装置１２、異なる閲覧者の複数の閲覧者装置１６を備えてもよい。また、第１実施例でも説明したが、１人のユーザは、依頼者、検査者、閲覧者のいずれの立場でも検査システム１０１に参加できる。例えば、１つの情報処理装置が、依頼者装置１２、検査者装置１４、および閲覧者装置１６として機能してもよい。

以下、依頼者装置１２、検査者装置１４、閲覧者装置１６の機能ブロックを別個に説明するが、各装置の機能は、第１実施例（図３）で説明したように１つのアプリケーションプログラムにより提供されてもよい。また、各装置の機能は、所定のウェブサーバ（例えばポータルサーバ１０２）が提供するウェブアプリケーションプログラムを各装置が実行することにより発揮されてもよい。

図１２は、図１１の依頼者装置１２の機能ブロックを示すブロック図である。依頼者装置１２は、入力部４０、表示部４２、制御部４４、通信部１１２を備える。通信部１１２は、所定の通信プロトコルにしたがって外部装置と通信する。制御部４４は、通信部１１２を介して、ファイルサーバ１８とポータルサーバ１０２とデータを送受信する。

制御部４４は、検体検索部１２０、検体登録部１２２、検査依頼部１２４、レポート取得部１２６、ノンス登録部１２８、結果コミット部１３０を備える。検体検索部１２０は、検査中および検査完了済の１つ以上の検体に関する情報をポータルサーバ１０２から取得する。検体登録部１２２は、検査対象の検体をファイルサーバ１８に登録する。検査依頼部１２４は、検体の検査依頼をブロックチェーンシステム１０４に登録する。例えば、検査依頼部１２４は、検査の報酬をブロックチェーンシステム１０４へ記録する。

レポート取得部１２６は、検査者による検体の評価結果を示す評価レポートをファイルサーバ１８から取得する。依頼者が登録した検体の検査に複数の検査者が参加している場合、レポート取得部１２６は、それら複数の検査者が作成した複数の評価レポートをファイルサーバ１８から取得する。検査者による評価結果は、少なくとも、検体が正当なものであること（例えばマルウェアではないこと）を示す「白」と、検体が不正なものであること（例えばマルウェアであること）を示す「黒」のいずれかを含む。

なお、検査者が作成した評価レポートには、検査者による評価結果に加えて、評価結果に対する検査者の自信の度合いを示す段階的なスコア（評価結果が正解である確度に関して検査者自らが評価した値）が含まれるようにしてもよい。例えば、「白；80％」であれば、検査者が検体を正当なものであると判断し、その確度は80％であると検査者が考えていることを示す。評価結果に対する検査者の自信の度合いは、前述の段階的なスコアであってもよいし、「自信あり」「やや自信あり」「自信なし」のような段階的な評価であってもよい。

ノンス登録部１２８は、所定の乱数発生器が生成したノンス（言い換えれば乱数）（以下「結果ノンス」とも呼ぶ。）をポータルサーバ１０２に登録する。結果コミット部１３０は、ウイルスＳＣ１０６と連携して、結果コミット処理を実行する。例えば、結果コミット部１３０は、ウイルスＳＣ１０６に実装された結果コミット処理用のメソッドを呼び出してもよい。なお、本実施例において、スマートコントラクトのメソッドを呼び出すことは、他の公知の方法によりスマートコントラクトに対してトランザクションを発行することに置き換えてもよい。

図１３は、図１１の検査者装置１４の機能ブロックを示すブロック図である。検査者装置１４の制御部４４は、依頼検索部１４０、検体取得部１４２、検体照合部１４４、レポート登録部１４６、評価コミット部１４８、ノンス取得部１５０、結果確認部１５２、最終コミット部１５４を備える。

依頼検索部１４０は、登録された１つ以上の検査依頼に関する情報をポータルサーバ１０２から取得する。検体取得部１４２は、検査者により選択された検体をファイルサーバ１８から取得する。検体照合部１４４は、ハッシュ値を照合することにより、検体取得部１４２が取得した検体の正当性（言い換えれば改ざんがないこと）を確認する。レポート登録部１４６は、検査者が検体を検査して作成した評価レポートをファイルサーバ１８へ登録する。

評価コミット部１４８は、ウイルスＳＣ１０６と連携して、評価コミット処理を実行する。例えば、結果コミット部１３０は、ウイルスＳＣ１０６に実装された評価コミット用のメソッドを呼び出してもよい。

ノンス取得部１５０は、ポータルサーバ１０２に登録された結果ノンスを取得する。結果確認部１５２は、依頼者が最終的に検体を正当なもの（「白」）と判定したか、不正なもの（「黒」）と判定したか（以下「白黒判定結果」とも呼ぶ。）を確認する処理を実行する。最終コミット部１５４は、ウイルスＳＣ１０６と連携して、最終コミット処理を実行する。例えば、最終コミット部１５４は、ウイルスＳＣ１０６に実装された最終コミット用のメソッドを呼び出してもよい。

図１４は、図１１の閲覧者装置１６の機能ブロックを示すブロック図である。閲覧者装置１６の制御部４４は、検体検索部１６０、閲覧実行部１６２、依頼者評価部１６４を備える。

検体検索部１６０は、検査中および検査完了済の１つ以上の検体に関する情報をポータルサーバ１０２から取得する。閲覧実行部１６２は、ウイルスＳＣ１０６と連携して、閲覧者により選択された検体の検査結果を閲覧するための処理を実行する。依頼者評価部１６４は、ウイルスＳＣ１０６と連携して依頼者を評価するための処理を実行する。例えば、依頼者評価部１６４は、ウイルスＳＣ１０６に実装された閲覧処理用のメソッドを呼び出してもよい。

図１５は、図１１のブロックチェーンシステム１０４の機能ブロックを示すブロック図である。既述したように、ブロックチェーンシステム１０４は、ウイルスＳＣ１０６、トークンＳＣ１０８、アクターＳＣ１１０を備える。

トークンＳＣ１０８は、ユーザ口座保持部１７０、依頼口座保持部１７２、主催者口座保持部１７４、閲覧口座保持部１７５を含む。ユーザ口座保持部１７０は、依頼者が保有する口座（依頼者口座）の情報、複数の検査者が保有する複数の口座（検査者口座）の情報、閲覧者が保有する口座（閲覧者口座）の情報を記憶する。第２実施例では、各ユーザは、検査システム１０１で定められた仮想通貨であるトークンを保有する。各ユーザの口座情報には、各ユーザが保有するトークンの残高が記録される。各ユーザの口座は、各ユーザのアドレスにより識別される。

依頼口座保持部１７２は、複数の検査依頼に対応する複数の口座（検査依頼口座）の情報を記憶する。検査依頼口座は、検査対象となる検体のハッシュ値により識別される。検査システム１０１では、新たな検査依頼が登録されるたびに新たな検査依頼口座が開設される。主催者口座保持部１７４は、検査システム１０１の主催者が保有する口座の情報を記憶する。例えば、主催者は、ファイルサーバ１８、ポータルサーバ１０２、ブロックチェーンシステム１０４を提供する企業である。閲覧口座保持部１７５は、閲覧ごとに開設される口座（閲覧口座）の情報を記憶する。閲覧口座は、閲覧者アドレスにより識別される。

アクターＳＣ１１０は、スコア保持部１７６を含む。スコア保持部１７６は、依頼者のスコアと、複数の検査者それぞれのスコアを記憶する。依頼者スコアは、後述するように、閲覧者による依頼者の評価結果に応じて変更され、検査依頼登録時に支払う主催者への手数料の額に影響する。具体的には、依頼者のスコアが低いほど、手数料は高額になる。検査者スコアは、検査者の評価結果が正解か否か（実施例では依頼者により正解とされたか否か）に応じて変更され、報酬の分配率に影響する。具体的には、相対的にスコアが高い検査者は、相対的に高い分配率となる。

また、アクターＳＣ１１０は、図示しない取引履歴保持部を含むようにしてもよい。取引履歴保持部は、依頼者の依頼登録回数、報酬の支払い回数、報酬の未払い回数、登録報酬の累計額等と、検査者の評価レポート登録回数、正解回数、不正解回数、評価結果に対する検査者の自信の度合いを示す段階的なスコアの平均値、獲得した報酬の累計額、閲覧された回数等を記憶し、本検査システムでの処理に応じて更新される。依頼者のスコアと、検査者のスコアは、取引履歴保持部に記憶される値に基づいて計算・更新されるようにしてもよい。

ウイルスＳＣ１０６は、検査情報保持部１７８、依頼処理部１８０、評価コミット処理部１８２、結果コミット処理部１８４、最終コミット処理部１８６、閲覧処理部１９２、依頼者評価処理部１９４を含む。検査情報保持部１７８は、依頼者からの検査依頼ごとに生成される検査情報を記憶する。検査情報は、検査依頼または検体に関する複数の項目を含む。

図１６は、検査情報の例を示す。検体のハッシュ値は、各検査情報のキーである。依頼者設定項目２００および依頼者設定項目２０２は、検体αの検査依頼を登録した依頼者装置１２により設定される情報項目である。検査者設定項目２０４および検査者設定項目２０６は、検体αを評価した複数の検査者装置１４により設定される項目である。ユーザのアドレスは、当該ユーザが検査システム１０１にアカウントを登録した際に払い出されるユーザごとにユニークなデータ（ＩＤ）である。

図１５に戻り、依頼処理部１８０は、依頼者装置１２からの呼び出しに応じて、検査依頼時の処理を実行する。評価コミット処理部１８２は、検査者装置１４からの呼び出しに応じて、評価コミット時の処理を実行する。結果コミット処理部１８４は、依頼者装置１２からの呼び出しに応じて、結果コミット時の処理を実行する。

最終コミット処理部１８６は、検査者装置１４からの呼び出しに応じて、最終コミット時の処理を実行する。最終コミット処理部１８６は、検査者評価部１８８とトークン振替部１９０を含む。検査者評価部１８８は、アクターＳＣ１１０のスコア保持部１７６に記憶された検査者のスコアを調整する。トークン振替部１９０は、トークンＳＣ１０８に記憶された口座間でのトークンの振替を実行する。

閲覧処理部１９２は、閲覧者装置１６からの呼び出しに応じて、閲覧時の処理を実行する。依頼者評価処理部１９４は、閲覧者装置１６からの呼び出しに応じて、依頼者評価時の処理を実行する。

以上の構成による検査システム１０１の動作を説明する。
図１７は、検査の依頼に関する動作を示すフローチャートである。依頼者装置１２の検体検索部１２０は、依頼者により指定された検査候補の検体のハッシュ値をキーとする検体検索の要求をポータルサーバ１０２へ送信する（Ｓ１００）。ポータルサーバ１０２は、検索要求で指定されたハッシュ値をキーとして、ウイルスＳＣ１０６に記憶された検査情報を検索する。ポータルサーバ１０２は、ハッシュ値に該当する検体が存在するか（すなわち検査中または検査完了済）、存在しないか（すなわち未検査）を示す検索結果を検査者装置１４へ送信する（Ｓ１０２）。依頼者装置１２は、検索結果を画面に表示させる。

依頼者は、検査候補の検体が未検査であれば、当該検体の検査依頼を指示する操作を依頼者装置１２へ入力する。依頼者装置１２の検体登録部１２２は、検体そのもののデータを含む登録要求をファイルサーバ１８へ送信する（Ｓ１０４）。ファイルサーバ１８は、依頼者装置１２から送信された検体のデータを所定の記憶領域に保存する（Ｓ１０６）。ファイルサーバ１８は、保存した検体に対してファイルサーバ１８におけるユニークなＩＤである検体ＵＲＩ（Uniform Resource Identifier）を発行し、検体ＵＲＩを依頼者装置１２へ送信する（Ｓ１０８）。依頼者装置１２の検体登録部１２２は、ファイルサーバ１８から送信された検体ＵＲＩを取得する。

依頼者装置１２の検査依頼部１２４は、検体に関する複数の属性データをパラメータとして、ウイルスＳＣ１０６の検査依頼メソッドを呼び出す（Ｓ１１０）。検体に関する複数の属性データは、検体のハッシュ値、依頼者アドレス、検体ＵＲＩ、検査期限、報酬額（すなわちトークン量）を含む。検査期限および報酬額は、依頼者が任意に決定する。ウイルスＳＣ１０６の依頼処理部１８０は、上記複数の属性データを含む検査情報（依頼者設定項目２００）を検査情報保持部１７８に記録する（Ｓ１１２）。この際、検査情報のステータスは、検査中に設定される。

また、ウイルスＳＣ１０６の依頼処理部１８０は、トークンＳＣ１０８の依頼口座保持部１７２に今回の検査依頼に対応する口座情報（検査依頼口座）を記録する。依頼処理部１８０は、報酬額のトークンと、主催者への手数料のトークンと、依頼者のデポジットのトークンを、トークンＳＣ１０８の依頼者口座から検査依頼口座へ振り替える（Ｓ１１４）。ウイルスＳＣ１０６は、エクスターナルコールにより、トークンの振替処理をトークンＳＣ１０８に実行させてもよい。また、トークンＳＣ１０８は、主催者への手数料の額を、アクターＳＣ１１０に記憶された依頼者スコアに応じて決定する。実施例では、依頼者スコアが高いほど手数料を低額にし、依頼者スコアが低いほど手数料を高額にする。これにより、依頼者スコアを高めようというインセンティブを依頼者に与える。

図１８は、検査の実施に関する動作を示すフローチャートである。図１８の処理は、複数の検査者装置１４のそれぞれで実行される。検査者装置１４の依頼検索部１４０は、検査依頼の検索要求をポータルサーバ１０２へ送信する（Ｓ１２０）。ポータルサーバ１０２は、ウイルスＳＣ１０６の検査情報を参照して、ステータスが検査中の検査依頼に関する情報を検索結果として検査者装置１４へ送信する（Ｓ１２２）。検査依頼に関する情報は、ウイルスＳＣ１０６の検査情報に含まれる検体ハッシュ値、期限、報酬、評価完了検査者数（検査情報に記録された検査者数）、検体ＵＲＩを含み、さらに、アクターＳＣ１１０に記録された依頼者スコアと評価完了検査者のスコアを含む。検査者装置１４は検索結果を画面に表示させる。

検査者は、検索結果を確認し、自分が検査する検体（以下「対象検体」と呼ぶ。）を決定する。検査者装置１４の検体取得部１４２は、対象検体の検体ＵＲＩをもとに、対象検体をファイルサーバ１８からダウンロードする（Ｓ１２４）。ファイルサーバ１８は、対象検体のデータを検査者装置１４へ送信する（Ｓ１２６）。検査者装置１４の検体照合部１４４は、ファイルサーバ１８から取得した対象検体のデータのハッシュ値を取得し、ポータルサーバ１０２から取得した対象検体のハッシュ値との同一性を確認する（Ｓ１２８）。これにより、ファイルサーバ１８から取得した対象検体のデータが改ざんされていないこと、すなわち、オリジナルのデータであることを確認する。

検査者は、対象検体がマルウェアか否かを検査し、対象検体がマルウェアか（「黒」）否か（「白」）を示すデータを少なくとも含む評価レポートを作成する。検査者が評価コミットを指示する操作を検査者装置１４へ入力すると、検査者装置１４のレポート登録部１４６は、評価レポートを依頼者の公開鍵で暗号化する（Ｓ１３０）。レポート登録部１４６は、評価レポートをファイルサーバ１８へアップロードする（Ｓ１３２）。ファイルサーバ１８は、検査者装置１４から送信された評価レポートのデータを所定の記憶領域に保存する（Ｓ１３４）。ファイルサーバ１８は、保存した評価レポートに対してファイルサーバ１８におけるユニークなＩＤであるレポートＵＲＩを発行し、レポートＵＲＩを検査者装置１４へ送信する（Ｓ１３６）。検査者装置１４のレポート登録部１４６は、レポートＵＲＩを取得する。

検査者装置１４の評価コミット部１４８は、所定の乱数発生器が生成したノンスを取得する（Ｓ１３８）。評価コミット部１４８は、評価に関する複数の属性データをパラメータとして、ウイルスＳＣ１０６の評価コミットメソッドを呼び出す（Ｓ１４０）。評価に関する複数の属性データは、評価レポートのハッシュ値、対象検体が「白」か「黒」を示す値とノンスとを結合したデータのハッシュ値（「評価ハッシュ値」とも呼ぶ。）、レポートＵＲＩを含む。評価レポートのハッシュ値を含めることにより、将来、検査者が、当該評価レポートを作成していないと否認することができないようにする。

ウイルスＳＣ１０６の評価コミット処理部１８２は、上記複数の属性データをもとに検査情報を更新し、例えば、検査者設定項目２０４または検査者設定項目２０６を記録する（Ｓ１４２）。この際、検査者設定項目の最終コミットフラグは、「未コミット」に設定される。また、ウイルスＳＣ１０６の評価コミット処理部１８２は、検査者のデポジットとして、所定量のトークンを、トークンＳＣ１０８の検査者口座から検査依頼口座へ振り替える（Ｓ１４４）。

図１９は、依頼者の結果判定に関する動作を示すフローチャートである。検査依頼において指定した期限に達すると、依頼者装置１２のレポート取得部１２６は、ウイルスＳＣ１０６の検査情報を参照して、検査依頼した検体（検体ハッシュ値）に対応付けられたレポートＵＲＩを取得する。レポート取得部１２６は、レポートＵＲＩにより特定される評価レポートをファイルサーバ１８に要求する（Ｓ１５０）。ファイルサーバ１８は、依頼者装置１２から要求された評価レポートのデータを依頼者装置１２へ送信する（Ｓ１５２）。依頼者装置１２のレポート取得部１２６は、評価レポートを依頼者の秘密鍵で復号する（Ｓ１５４）。

レポート取得部１２６は、復号した評価レポートのデータをハッシュ関数へ入力してハッシュ値を取得するとともに、ウイルスＳＣ１０６の検査情報に記録された当該評価レポートのハッシュ値を取得する。レポート取得部１２６は、両者のハッシュ値の同一性を確認する（Ｓ１５６）。これにより、評価レポートが改ざんされていないことを確認する。依頼者装置１２は、Ｓ１５０～Ｓ１５６の処理を、検体を評価した検査者の数、言い換えれば、当該検体に対する評価レポートの数だけ繰り返す。依頼者は、１人以上の検査者による１つ以上の評価レポートの内容を確認して、検査依頼対象の検体がマルウェアか否か（すなわち黒か白か）を総合的に判定する。以下、この判定を「白黒判定」とも呼ぶ。

依頼者は、白黒判定の結果を登録するための結果コミットを指示する操作を検査者装置１４へ入力する。検査者装置１４のノンス登録部１２８は、白黒判定の結果に付加する結果ノンスを生成し（Ｓ１５８）、検体ハッシュ値と結果ノンスとをポータルサーバ１０２へ送信する（Ｓ１６０）。ポータルサーバ１０２は、検体ハッシュ値と結果ノンスとを対応付けて保存する（Ｓ１６２）。

依頼者装置１２の結果コミット部１３０は、白黒判定結果に関する複数の属性データをパラメータとして、ウイルスＳＣ１０６の結果コミットメソッドを呼び出す（Ｓ１６４）。白黒判定結果に関する複数の属性データは、検体が「白」か「黒」かを示す値と結果ノンスとを結合したデータのハッシュ値（以下「結果ハッシュ値」とも呼ぶ。）、正解者のアドレスの配列、白黒判定結果を閲覧するための閲覧料を含む。正解者は、依頼者により評価結果が正解と認定された検査者であり、言い換えれば、依頼者の白黒判定と同じ評価を下した検査者である。また、閲覧料は、依頼者が任意に決定する。ウイルスＳＣ１０６の結果コミット処理部１８４は、上記複数の属性データをもとに検査情報を更新し、例えば、図１６の依頼者設定項目２０２を記録する（Ｓ１６６）。

図２０は、検査者による最終コミットに関する動作を示すフローチャートである。最終コミットは、依頼者の白黒判定結果の承認とも言える。検査者装置１４のノンス取得部１５０は、検査者が評価した検体のハッシュ値をキーとしてポータルサーバ１０２に結果ノンスを要求する（Ｓ１７０）。ポータルサーバ１０２は、結果ノンス要求元の検査者が、上記検体ハッシュ値をキーとするウイルスＳＣ１０６の検査情報に記録されている場合、すなわち正当な検査者である場合、結果ノンスの提供を許可する（Ｓ１７２）。ポータルサーバ１０２は、正当な検査者の検査者装置１４へ結果ノンスを送信する（Ｓ１７４）。検査者装置１４のノンス取得部１５０は、結果ノンスを取得する。

検査者装置１４の結果確認部１５２は、ウイルスＳＣ１０６の検査情報から、結果ハッシュ値を取得する。結果確認部１５２は、予め定められた「白」の値に結果ノンスを結合したデータのハッシュ値と、予め定められた「黒」の値に結果ノンスを結合したデータのハッシュ値と、結果ハッシュ値とを比較することにより、依頼者の白黒判定結果が「白」か「黒」かを判定する（Ｓ１７６）。すなわち、結果確認部１５２は、予め定められた「白」の値に結果ノンスを結合したデータのハッシュ値が結果ハッシュ値に一致する場合、依頼者が「白」と判定したことを識別する。また、結果確認部１５２は、予め定められた「黒」の値に結果ノンスを結合したデータのハッシュ値が結果ハッシュ値に一致する場合、依頼者が「黒」と判定したことを識別する。

結果確認部１５２は、依頼者が検体を正当なもの（「白」）と判定したか、マルウェア（「黒」）と判定したかを画面に表示させてもよい。またＳ１７６において、結果確認部１５２は、ウイルスＳＣ１０６の検査情報から、正解者アドレスの配列を取得し、画面に表示させる。結果確認部１５２は、検査者装置１４の検査者のアドレスが正解者アドレスの配列に含まれるか否かを画面に表示させてもよい。

検査者は、依頼者の白黒判定結果が自分の評価結果と同じである場合、すなわち自分が正解者である場合、自分のアドレスが正解者アドレスの配列に含まれていることを確認する。依頼者の白黒判定結果および正解者の認定を承認する場合、検査者は、最終コミットを指示する操作を検査者装置１４へ入力する。検査者装置１４の最終コミット部１５４は、検体ハッシュ値および検査者アドレスを含むパラメータを用いて、ウイルスＳＣ１０６の最終コミットメソッドを呼び出す（Ｓ１７８）。

ウイルスＳＣ１０６の最終コミット処理部１８６は、検査者装置１４から送信されたパラメータをもとに検査情報を更新する（Ｓ１８０）。例えば、最終コミット処理部１８６は、検査者設定項目の最終コミットフラグを「コミット済」に変更する。

最終コミット処理部１８６の検査者評価部１８８は、検査情報の正解者アドレスを参照し、最終コミットを行った検査者（「対象検査者」とも呼ぶ。）が正解者か否かに応じて、対象検査者のスコアを調整する（Ｓ１８２）。例えば、対象検査者が正解者である場合、検査者評価部１８８は、アクターＳＣ１１０に記録された対象検査者のスコアをそれまでより大きい値に変更する。また、対象検査者が正解者でない場合、検査者評価部１８８は、対象検査者のスコアをそれまでより小さい値に変更する。ウイルスＳＣ１０６は、エクスターナルコールにより、アクターＳＣ１１０に記録されたスコアを更新してもよい。

最終コミット処理部１８６のトークン振替部１９０は、検査者装置１４から送信された検査者アドレスをもとに、検査依頼口座に記録された当該検査者のデポジットを当該検査者の口座へ振り替える（Ｓ１８４）。言い換えれば、トークン振替部１９０は、評価レポート登録時に検査者から預かったトークンを、最終コミット時に当該検査者の口座へ返還する。

なお、１つの検体に対して複数の検査者がいる場合の最後の検査者による最終コミット時、検査者が１人であればその１人の検査者による最終コミット時、トークン振替部１９０は、さらに以下の処理を実行する。（１）トークン振替部１９０は、正解者と認定された検査者に報酬を分配する。この場合、トークン振替部１９０は、アクターＳＣ１１０を参照して、各正解者のスコアを参照し、相対的にスコアが高い検査者に対して、相対的に大きい報酬を割り当てる。また、（２）トークン振替部１９０は、検査依頼口座に記録された手数料を主催者の口座へ振り替える。

また、（３）トークン振替部１９０は、検査依頼口座に記録された依頼者のデポジットを依頼者の口座へ振り替える。言い換えれば、トークン振替部１９０は、検査依頼時に依頼者から預かったトークンを、依頼者の口座へ返還する。また、最終コミット処理部１８６は、依頼者設定項目におけるステータスを「検査完了済」に更新する。なお、最終コミット処理部１８６は、或る検体の検査情報に記録された１つ以上の検査者設定項目における最終コミットフラグが全てコミット済になった場合に、その検体の全ての検査者が最終コミットを行ったことを検出してもよい。

図２１は、検査結果閲覧時の動作を示すフローチャートである。閲覧者装置１６の検体検索部１６０は、閲覧候補となる検体の検索要求をポータルサーバ１０２へ送信する（Ｓ１９０）。ポータルサーバ１０２は、ステータスが検査完了済の検体情報を含む検索結果を閲覧者装置１６へ送信する（Ｓ１９２）。上記の検体情報は、ウイルスＳＣ１０６の検査情報に含まれる検体ハッシュ値、ステータス、閲覧料、依頼者アドレス、１つ以上の検査者アドレス、１つ以上の正解者アドレスを含む。さらに、アクターＳＣ１１０に記録された依頼者スコアと検査者スコアを含む。

閲覧者装置１６の閲覧実行部１６２は、検体アドレスおよび閲覧者アドレスを含むパラメータを用いて、ウイルスＳＣ１０６の閲覧処理メソッドを呼び出す（Ｓ１９４）。ウイルスＳＣ１０６の閲覧処理部１９２は、トークンＳＣ１０８において、閲覧料分のトークンを閲覧者口座から依頼者口座へ振り替える。また、閲覧処理部１９２は、予め定められた手数料分のトークンを閲覧者口座から主催者口座へ振り替える。また、閲覧処理部１９２は、今回の閲覧用の口座をトークンＳＣ１０８に記録し、閲覧者のデポジットとして、予め定められた量のトークンを、閲覧者口座から今回の閲覧用口座へ振り替える（Ｓ１９６）。

また、Ｓ１９４において、閲覧者装置１６の閲覧実行部１６２は、検体アドレスおよび閲覧者アドレスを含む閲覧要求をポータルサーバ１０２へ送信する。ポータルサーバ１０２は、閲覧者アドレスを用いて、閲覧者が閲覧料を支払い済みであることを確認する（Ｓ１９８）。閲覧者が閲覧料を支払い済みであれば、ポータルサーバ１０２は、検体アドレスに対応付けられた結果ノンス（Ｓ１６２で保存した結果ノンス）を閲覧者装置１６へ送信する（Ｓ２００）。閲覧者装置１６の閲覧実行部１６２は、結果ノンスを取得する。

閲覧者装置１６の閲覧実行部１６２は、ウイルスＳＣ１０６の検査情報から、閲覧対象検体の結果ハッシュ値を取得する。閲覧実行部１６２は、予め定められた「白」の値に結果ノンスを結合したデータのハッシュ値と、予め定められた「黒」の値に結果ノンスを結合したデータのハッシュ値と、結果ハッシュ値とを比較することにより、閲覧対象検体に対する白黒判定結果が「白」か「黒」かを判定する（Ｓ２０２）。ここでの白黒判定結果は、閲覧対象検体の依頼者による最終的な判定結果である。閲覧実行部１６２は、閲覧対象検体の白黒判定結果が「白」か「黒」かを画面に表示させてもよい。

閲覧者は、白黒判定結果を確認後、依頼者を評価し、評価結果を閲覧者装置１６へ入力する。典型的には、閲覧者は、依頼者の白黒判定結果が正しい場合、高い評価値を設定する一方、依頼者の白黒判定結果が誤っている場合、低い評価値を設定する。依頼者の白黒判定結果が誤っているとは、例えば、依頼者が閲覧対象検体を正当なもの（「白」）と判定しながら、実際には閲覧対象検体がマルウェア（「黒」）だった場合や、逆に、依頼者が閲覧対象検体をマルウェア（「黒」）と判定しながら、実際には閲覧対象検体が正当なもの（「白」）だった場合である。閲覧者装置１６の依頼者評価部１６４は、閲覧者アドレスおよび依頼者の評価値をパラメータとして、ウイルスＳＣ１０６の依頼者評価メソッドを呼び出す（Ｓ２０４）。

ウイルスＳＣ１０６の依頼者評価処理部１９４は、閲覧者装置１６から送信された依頼者の評価値をもとに、依頼者のスコアを調整する（Ｓ２０６）。例えば、依頼者の評価値が高い場合、依頼者評価処理部１９４は、アクターＳＣ１１０に記録された依頼者スコアをそれまでより大きい値に変更してもよい。逆に、依頼者の評価値が低い場合、依頼者評価処理部１９４は、アクターＳＣ１１０に記録された依頼者スコアをそれまでより小さい値に変更してもよい。また、依頼者評価処理部１９４は、閲覧用口座に記録された閲覧者のデポジットを閲覧者の口座へ振り替える（Ｓ２０８）。言い換えれば、依頼者評価処理部１９４は、閲覧実行時に閲覧者から預かったトークンを、依頼者評価時に閲覧者口座へ返還する。

以上、本発明を第２実施例をもとに説明した。この第２実施例は例示であり、各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。

変形例を説明する。第２実施例では言及していないが、検査システム１０１は、ある依頼者が登録した検査依頼に対して、他者が協賛可能な仕組みを備えてもよい。図２２は、変形例の検査システム１０１の構成を示す。検査システム１０１は、第２実施例の構成に加えて、協賛者装置２１０を備える。協賛者装置２１０は、協賛者により操作される情報処理装置である。協賛者は、依頼者が登録した検体の検査に協賛するユーザであり、言い換えれば、依頼者とともに同じ検体の検査を依頼するユーザである。なお、或る検体の検査に対する協賛者は、他の検体の検査では依頼者、検査者、または閲覧者になることもある。

図２３は、変形例における検査情報の例を示す。本変形例では、依頼者装置１２およびウイルスＳＣ１０６は、検査依頼登録時に、協賛可否フラグと報酬上限額をさらに設定する。協賛可否フラグは、他者の協賛を許可すること（「協賛可」）、または、他者の協賛を禁止すること（「協賛不可」）のいずれかに設定される。報酬上限額は、協賛可否フラグが協賛可の場合に設定される。報酬上限額には、協賛者により加算後の報酬額の上限である。

協賛者が検体の検査に協賛する目的は、報酬額を上げることによって検査者の意欲を向上させ、活発な評価を促すことと、閲覧料の分配を受けることである。全ての検査者が最終コミットを行った際、ウイルスＳＣ１０６のトークン振替部１９０は、依頼者の報酬額と協賛者の加算額の合計を、１人以上の正解者に対して分配する。また、トークン振替部１９０は、閲覧者が支払った閲覧料を、依頼者と協賛者との間で報酬の分担率に応じて分配する。例えば、依頼者の報酬額が８０トークン、協賛者の加算額が２０トークン、閲覧料が１０トークンの場合、トークン振替部１９０は、８トークンを閲覧者の口座から依頼者の口座へ振り替え、２トークンを閲覧者の口座から協賛者の口座へ振り替えてもよい。

上記の例において、協賛者がいなければ、依頼者は１回の閲覧あたり１０トークンを得ることができたが、協賛者がいるため、１回の閲覧あたりの収益は８トークンとなる。また、閲覧者が１回の閲覧あたり１０トークンを得るためには、閲覧料を約１３トークンにする必要があるが、そうすると閲覧者が減少する可能性がある。このような収益の減少を調整するための設定項目が、協賛可否フラグと報酬上限額である。例えば、依頼者は、報酬額、報酬上限額、および閲覧料を調整することで、１回の閲覧あたりの収益を任意に調整することができる。依頼者は、検査の活発化と、自身の収益とを比較衡量して、協賛可否フラグおよび報酬上限額を設定する。

図２４は、図２２の協賛者装置２１０の機能ブロックを示すブロック図である。協賛者装置２１０は、依頼者装置１２、表示部４２、通信部１１２、制御部４４を備える。制御部４４は、依頼検索部２１２と協賛部２１４を含む。

依頼検索部２１２は、登録された１つ以上の検査依頼に関する情報をポータルサーバ１０２から取得する。例えば、依頼検索部２１２は、検査依頼の検索要求をポータルサーバ１０２へ送信する。ポータルサーバ１０２は、ウイルスＳＣ１０６の検査情報を参照して、ステータスが検査中の検査依頼に関する情報を検索結果として協賛者装置２１０へ送信する。検査依頼に関する情報は、ウイルスＳＣ１０６の検査情報に含まれる検体ハッシュ値、期限、報酬、評価完了検査者数（検査情報に記録された検査者数）、検体ＵＲＩを含む。さらに、アクターＳＣ１１０に記録された依頼者スコアと評価完了検査者のスコアを含む。なお、ポータルサーバ１０２は、協賛可否フラグが協賛可に設定された検査依頼の情報のみを協賛者装置２１０へ送信してもよい。協賛者装置２１０は、検索結果を画面に表示させる。

協賛部２１４は、協賛者により協賛対象として選択された検査依頼を指定するパラメータを用いて、ウイルスＳＣ１０６の協賛処理メソッドを呼び出す。上記パラメータは、協賛対象の検査依頼のキーである検体ハッシュ値と、報酬加算額（すなわち既定の報酬への上乗せ額）を含む。ウイルスＳＣ１０６の協賛処理部（不図示）は、検体ハッシュ値により特定される検査情報を、上記パラメータを用いて更新する。例えば、ウイルスＳＣ１０６の協賛処理部は、図２３の協賛者設定項目２２０を検査情報に設定する。なお、協賛者は、結果コミットが不要であるため、結果コミットのインセンティブとなるデポジットも不要である。

第２実施例および変形例に記載の検査システム１０１の構成と動作は次のように表現することができる。
［項目１］
依頼者装置１２は、検査対象データを所定領域へ記録するとともに、検査の報酬をブロックチェーンシステム１０４へ記録する。一つ以上の検査者装置１４のそれぞれは、依頼者装置１２により記録された検査対象データを取得して、検査対象データに対する検査結果（例えば評価レポート）を所定領域へ記録する。依頼者装置１２は、一つ以上の検査者装置１４により記録された一つ以上の検査結果を取得し、依頼者により検査結果が正解と認定された検査者である正解者のデータ（例えば正解者アドレスの配列）をブロックチェーンシステム１０４へ記録する。ブロックチェーンシステム１０４（例えばウイルスＳＣ１０６）は、正解者に対して検査の報酬を分配する。
この構成によると、依頼者は、一人以上の検査者による電子データの検査結果を得ることができ、一人以上の検査者のうち正解者は、報酬を得ることができるビジネスモデルを実現できる。また、報酬の支払いにブロックチェーンシステムを利用することで、依頼者は、個々の検査者への信用を持たない場合でも簡単に送金（言い換えれば価値の移転）を行うことができる。また、少額の送金の繰り返しも容易に実現できる。また、報酬の支払いに関する改ざんも防止することができる。

［項目２］
ブロックチェーンシステム１０４（例えばアクターＳＣ１１０）は、一人以上の検査者それぞれのスコアを記憶する。各検査者のスコアは、検査結果（例えば白または黒の評価結果）が正解か否かに応じて変更される。ブロックチェーンシステム１０４は、検査結果が正解となった一人以上の検査者の中で、スコアが相対的に高い検査者に対して相対的に高い報酬を分配する。
この構成によると、検査者に対して、正しい評価結果を作成すること、言い換えれば、誠実に評価することへのインセンティブを提供できる。

［項目３］
一つ以上の検査者装置１４のそれぞれは、正解者のデータをブロックチェーンシステム１０４から取得し、正解者のデータが検査者により承認（例えば最終コミット）された場合、正解者承認の旨をブロックチェーンシステム１０４へ記録する。ブロックチェーンシステム１０４は、全ての検査者装置１４から正解者承認の旨が記録された場合、正解者に対して検査の報酬を分配する。
この構成によると、依頼者による正解者の認定を、当該依頼者による検査依頼に対応した全ての検査者が承認したことを条件として、正解者へ報酬を分配する。これにより、各検査者にとって納得のいく報酬分配を実現できる。

［項目４］
依頼者装置１２は、検査対象データを記録する際（例えば検査依頼時）、依頼者が保有する通貨（例えばトークン）の少なくとも一部を預り金としてブロックチェーンシステム１０４（例えばトークンＳＣ１０８）へ記録する。ブロックチェーンシステム１０４は、全ての検査者装置１４から正解者承認の旨が記録された場合、預り金を依頼者へ返還する。
この構成によると、依頼者による検査依頼に対応した全ての検査者の承認を条件として依頼者へデポジットを返還することにより、検査者からの異議申立に対して真摯に対応することへのインセンティブを依頼者に提供できる。例えば、或る検査者の評価結果が正解（依頼者の白黒判定結果と同じ）であったにも関わらず、依頼者が認定した正解者の中に当該検査者が含まれなかった場合、当該検査者は依頼者へ異議申し立てを行う。これを受けた依頼者は、当該検査者を正解者アドレスの配列に含める等の作業を行う。

［項目５］
一つ以上の検査者装置１４のそれぞれは、検査結果を記録する際（例えば評価コミット時）、検査者が保有する通貨の少なくとも一部を預り金としてブロックチェーンシステム１０４（例えばトークンＳＣ１０８）へ記録する。ブロックチェーンシステム１０４は、或る検査者装置１４から正解者承認の旨が記録された場合、その検査者装置１４に対応する検査者へ預り金を返還する。
不正解となった検査者は、依頼者による正解者の認定に対する承認を怠ることが考えられるが、その承認をデポジット返還の条件とすることで、依頼者による正解者の認定に対して承認を行うことへのインセンティブを検査者に提供できる。これにより、全ての検査者の納得の下、検査者のスコアを調整し、また、報酬を分配することができる。

［項目６］
一つ以上の検査者装置１４のそれぞれは、検査結果（例えば白黒判定結果）を記録する際に、検査結果と乱数値とを結合したデータのハッシュ値（例えば図１６の評価ハッシュ値）をブロックチェーンシステム１０４へ記録する。
この構成によると、一つ以上の検査者装置１４は、各々の乱数値を保存しておくことで自身の評価結果を事後に証明でき、また、上記ハッシュ値をブロックチェーンシステム１０４へ記録することにより検査結果の改ざんを防止することができる。

［項目７］
依頼者装置１２は、検査結果（例えば白黒判定結果）と、検査結果の閲覧料とをブロックチェーンシステム１０４（例えばウイルスＳＣ１０６）へ記録する。閲覧者装置１６は、閲覧者が保有する通貨から閲覧料を依頼者に支払う処理をブロックチェーンシステム１０４に実行させる。
依頼者は、検査結果の閲覧により収益を上げることができるため、検査を依頼することへのインセンティブを依頼者に提供できる。また、閲覧料の支払いに関する改ざんも防止することができる。

［項目８］
依頼者装置１２は、検査結果と乱数とを結合したデータのハッシュ値（例えば図１６の結果ハッシュ値）をブロックチェーンシステム１０４（例えばウイルスＳＣ１０６）へ記録するとともに、上記乱数をポータルサーバ１０２へ通知する。ポータルサーバ１０２は、閲覧者から依頼者へ閲覧料が支払われた場合、上記乱数を閲覧者装置１６へ通知することにより、閲覧者装置１６において検査結果を識別可能にする。
ブロックチェーンシステム１０４のスマートコントラクトは、検査システム１０１の各装置で共有されるため、検査システム１０１の各装置は、スマートコントラクトから検査結果のデータを得ることができる。しかし、上記構成とすることで、閲覧料を支払わずに検査結果（すなわち検体が白か黒か）が確認されてしまうことを防止できる。

［項目９］
依頼者装置１２は、検査対象データを記録する際、依頼者が保有する通貨の少なくとも一部を手数料としてブロックチェーンシステム１０４へ記録する。ブロックチェーンシステム１０４は、依頼者のスコアを記憶し、上記手数料を依頼者のスコアに応じて決定する。閲覧者装置１６は、閲覧者により入力された依頼者の評価をブロックチェーンシステム１０４へ記録することにより、ブロックチェーンシステム１０４に記憶された依頼者のスコアを調整させる。
この構成によると、手数料を低額にするために自身のスコアを良くしようとするインセンティブを依頼者に与え、すなわち、検体の白黒を適切に判定することへのインセンティブを依頼者に与えることができる。

［項目１０］
閲覧者装置１６は、検査結果を取得する際、閲覧者が保有する通貨の少なくとも一部を預り金としてブロックチェーンシステム１０４へ記録する。ブロックチェーンシステム１０４は、検査者装置１４から依頼者の評価が記録された場合、預り金を閲覧者へ返還する。
この構成によると、依頼者の評価を行うことへのインセンティブを閲覧者に与えることができる。

［項目１１］
協賛者装置２１０は、検査の報酬の上乗せ額をブロックチェーンシステム１０４（例えばウイルスＳＣ１０６）へ記録する。ブロックチェーンシステム１０４は、上乗せ後の報酬を、当該検査を行った検査者のうち正解者に対して分配する。
この構成によると、報酬額を加算する仕組みを設けることにより、検査者の意欲を喚起し、検査の活発化を実現することができる。

［項目１２］
依頼者装置１２は、検査対象データを記録する際、報酬の上限額をブロックチェーンシステム１０４へ記録する。協賛者装置２１０による報酬の上乗せ額は、上記の上限額により制限される。ブロックチェーンシステム１０４は、閲覧者が支払った閲覧料を、依頼者と協賛者との間で報酬の分担率に応じて分配する。
この構成によると、依頼者は、報酬の上限額を設定することにより、閲覧料の取り分、言い換えれば、協賛者との閲覧料の分配率を任意に調整することができる。

［項目１３］
検査システム１０１は、依頼者装置１２を含まない構成、すなわち複数の検査者装置１４と閲覧者装置１６のみで構成してもよい。この構成では、検査者は、日常的あるいは定期的に通信データ（例えばパケット等のデータ）等の検査対象を監視してもよい。検査者は、例えば、不正なデータ通信や不正なアクセス、すなわち所定のパターンやポリシーとは異なるパターンを抽出してルール化してもよく、言い換えれば、異常パターンを定義してもよい。検査者装置１４は、上記ルール（言い換えれば上記異常パターン）をシグネチャとして評価レポートに記録し、評価レポートとその閲覧に必要な報酬額を含む情報共有オファーをブロックチェーンシステム１０４に登録してもよい。すなわち、検査者は依頼を受けなくても、自発的に検索を実施して検査結果や対策方法等を含む評価レポートをブロックチェーンシステム１０４に登録してもよい。閲覧者は、上記第２実施例と同様の仕組みにより、情報共有オファーを閲覧して検査者が設定した報酬額を支払う。閲覧したシグネチャの内容が有効であれば、閲覧者は、検査者に良い評価を付与し、または、追加の報酬を支払ってもよい。閲覧したシグネチャが有効でない場合、閲覧者は検査者に悪い評価を付与してもよく、または、閲覧者が支払った閲覧料が主催者に回収されるようにしてもよい。なお、この構成に、協賛者装置２１０が備わるようにしてもよい。

項目１３の構成によると、依頼者の検査依頼がなくても、検査者が主体的に不正な検体やセキュリティ上の欠陥等を検査して有償で情報公開したり、あるいは上記のように不正アクセスを検知するためのシグネチャを作成して有償で情報提供したりすることが可能になる。閲覧者（例えばセキュリティソフトウェア提供企業等）は、効率的にセキュリティ対策することが可能になる。また、検査者は、報酬を得られることで、より意欲的に不正なデータや情報アクセスの検知を監視するようになることが期待される。

上述した実施の形態および変形例の任意の組み合わせもまた本発明の実施の形態として有用である。組み合わせによって生じる新たな実施の形態は、組み合わされる実施の形態および変形例それぞれの効果をあわせもつ。また、請求項に記載の各構成要件が果たすべき機能は、実施の形態および変形例において示された各構成要素の単体もしくはそれらの連携によって実現されることも当業者には理解されるところである。

本発明は、電子データを検査するシステムに適用できる。

１０ 検査システム、 １２ 依頼者装置、 １４ 検査者装置、 １６ 閲覧者装置、 １８ ファイルサーバ、 ２２ ブロックチェーンネットワーク、 ５４ 被験データ登録部、 ６４ 被験データ取得部、 ７２ 検査結果取得部、 ７４ 送金部、 ７６ 検査結果出力部、 １０１ 検査システム、 １０２ ポータルサーバ、 １０４ ブロックチェーンシステム、 ２１０ 協賛者装置。

Claims (11)

1. 検査対象データを所定領域へ記録する第１の装置と、
   前記検査対象データが不正か否かを検査する第２の装置と、
   前記検査対象データに対する検査結果を使用する第３の装置と、
   を備え、
   前記第１の装置は、前記検査対象データに該当するデータが検査対象として登録済か否かに関する検索結果を受領し、
   前記第２の装置は、前記第１の装置により記録された検査対象データを取得して、前記検査対象データに対する検査結果を所定領域へ記録し、
   前記第３の装置は、前記第２の装置により記録された検査結果を取得することを特徴とする検査システム。
2. 検査対象データを所定領域へ記録する第１の装置と、
   前記検査対象データが不正か否かを検査する第２の装置と、
   を備え、
   前記第１の装置は、前記検査対象データに該当するデータが検査対象として登録済か否かに関する検索結果を受領し、
   前記第２の装置は、前記第１の装置により記録された検査対象データを取得して、前記検査対象データに対する検査結果を所定領域へ記録し、
   前記第１の装置は、前記第２の装置により記録された検査結果を取得することを特徴とする検査システム。
3. 前記第２の装置は、検査する対象を決定するための検索結果であって、かつ、前記第１の装置により記録された検査対象データに関する検索結果を受領することを特徴とする請求項１または２に記載の検査システム。
4. 前記第３の装置は、前記第２の装置により記録された検査結果に関する検索結果を受領することを特徴とする請求項１に記載の検査システム。
5. 前記第１の装置は、所定のブロックチェーンネットワークに対する検索結果であって、
   前記検査対象データに該当するデータが検査対象として登録済か否かに関する検索結果を
   受領することを特徴とする請求項１から４のいずれかに記載の検査システム。
6. 前記第１の装置は、前記検査対象データに関する属性情報を前記ブロックチェーンネットワークへ記録し、
   前記第２の装置は、前記ブロックチェーンネットワークから前記属性情報を取得し、取得した属性情報に基づいて前記検査対象データを取得することを特徴とする請求項５に記載の検査システム。
7. 前記第１の装置は、前記検査対象データを前記ブロックチェーンネットワークの外部の装置に記録し、
   前記第２の装置は、前記属性情報が示すアドレスに基づいて、前記外部の装置から前記検査対象データを取得することを特徴とする請求項６に記載の検査システム。
8. 前記第２の装置は、前記検査結果を所定のブロックチェーンネットワークへ記録し、
   前記第３の装置は、前記ブロックチェーンネットワークから前記検査結果を取得することを特徴とする請求項１に記載の検査システム。
9. 前記第３の装置は、前記検査結果を取得する場合に、前記第１の装置のユーザと、前記第２の装置のユーザへの報酬支払処理を実行することを特徴とする請求項１に記載の検査システム。
10. 第１の装置が、検査対象データに該当するデータが検査対象として登録済か否かに関する検索結果を受領するステップと、
    ファイルサーバが、前記検査対象データに該当するデータが検査対象として未登録である場合に、前記検査対象データを所定領域へ記録するステップと、
    前記検査対象データが不正か否かを検査する第２の装置が、前記ファイルサーバにより記録された検査対象データを取得するステップと、
    前記第２の装置が、前記検査対象データに対する検査結果を所定領域へ記録するステップと、
    前記検査対象データに対する検査結果を使用する第３の装置が、前記第２の装置により記録された検査結果を取得するステップと、
    を備えることを特徴とする検査方法。
11. 第１の装置が、検査対象データに該当するデータが検査対象として登録済か否かに関する検索結果を受領するステップと、
    ファイルサーバが、前記検査対象データに該当するデータが検査対象として未登録である場合に、前記検査対象データを所定領域へ記録するステップと、
    前記検査対象データが不正か否かを検査する第２の装置が、前記ファイルサーバにより記録された検査対象データを取得するステップと、
    前記第２の装置が、前記検査対象データに対する検査結果を所定領域へ記録するステップと、
    前記第１の装置が、前記第２の装置により記録された検査結果を取得するステップと、
    を備えることを特徴とする検査方法。

Images