JP7335511B2 - データマッチングシステム、情報処理装置およびデータマッチング方法 - Google Patents

Description

本発明は、データマッチングシステム、情報処理装置およびデータマッチング方法に関する。

近年、携帯機器やＩｏＴ（Internet of Things）機器の普及に伴って、ユーザの行動履歴など、ユーザに関する様々な情報を採取できるようになっている。そして、そのように採取された情報を用いて、特定の目的に適したユーザを抽出するようなマッチングサービスの実現が期待されている。

また、大量のデータを用いた分析や照合のために、確率的データ構造が利用されている。確率的データ構造を用いることで、分析や照合の対象データに関するクエリに対して、処理結果にはある程度の誤差が含まれ得るものの、対象データのサイズが圧縮され、処理効率を高めることができる。

このような確率的データ構造を用いた技術としては、例えば、複数のデータストリームにおけるデータ間の一致度を推定するために、ｈｙｐｅｒｌｏｇｌｏｇなどの確率的データ構造が利用された識別システムが提案されている。

また、情報を選択して出力する技術に関しては、例えば、ファイル管理システムによって管理されているファイルやデータを集積して、集積したアイテムの中から必要な情報を選択して出力する情報集積アプリケーションが提案されている。この情報集積アプリケーションによれば、スケッチ情報に指定されたアイテムに関する情報が、スケッチ情報に指定されたレイアウトにしたがって出力される。

特開２０１８－５０６１０７号公報 特開２０１０－２０４８９７号公報

ところで、上記のようなマッチングサービスでは、ユーザに関する情報がサービス側に提供されるため、個人情報が漏洩する危険性がある。これに対して、ユーザに関する情報を、確率的データ構造を有するスケッチングデータに変換してサービス側に提供する方法が考えられる。ユーザに関する情報がスケッチングデータに変換されることで、個人情報の特定が困難な状態でサービス側に情報が提供されるので、個人情報の秘匿性を高めることができる。しかし、サービス側では、スケッチングデータだけを用いてマッチングを行うと、マッチング精度が低下するという問題がある。

このように、ユーザに関する情報を用いたマッチングサービスでは、マッチング精度を維持した状態で、個人情報の秘匿性をどのようにして確保するかという点に課題がある。
１つの側面では、本発明では、ユーザに関する情報を用いたマッチングにおいて個人情報の秘匿性を確保することが可能なデータマッチングシステム、情報処理装置およびデータマッチング方法を提供することを目的とする。

１つの案では、情報処理装置と端末装置とを有する次のようなデータマッチングシステムが提供される。このデータマッチングシステムにおいて、情報処理装置は、それぞれ個別のユーザに関する複数のユーザ情報をそれぞれ変換して得られた、確率的データ構造をそれぞれ有する複数のスケッチングデータを受信して、情報処理装置が備える記憶部に格納し、複数のスケッチングデータと所定の参照データとのマッチングを実行し、複数のスケッチングデータの中からマッチング結果として一のスケッチングデータが特定されると、一のスケッチングデータに対応する一のユーザに対して、複数のユーザ情報のうち一のユーザに対応する一のユーザ情報の提供を要求する提供要求を送信し、一のユーザ情報を、一のユーザの署名データが付加された状態で受信し、受信した一のユーザ情報と参照データとのマッチングを実行することによりマッチング結果を検証する。端末装置は、提供要求に応じて、一のユーザ情報の提供に同意する同意操作を一のユーザから受け付け、同意操作に応じて、一のユーザ情報に基づいて署名データを生成し、署名データを付加した一のユーザ情報を情報処理装置に送信する。

また、１つの案では、記憶部と処理部とを有する次のような情報処理装置が提供される。この情報処理装置において、処理部は、それぞれ個別のユーザに関する複数のユーザ情報をそれぞれ変換して得られた、確率的データ構造をそれぞれ有する複数のスケッチングデータを受信して、記憶部に格納し、複数のスケッチングデータと所定の参照データとのマッチングを実行し、複数のスケッチングデータの中からマッチング結果として一のスケッチングデータが特定されると、一のスケッチングデータに対応する一のユーザに対して、複数のユーザ情報のうち一のユーザに対応する一のユーザ情報の提供を要求する提供要求を送信し、一のユーザ情報を、一のユーザ情報の提供に一のユーザが同意する同意操作に応じて生成された、一のユーザの署名データが付加された状態で受信し、受信した一のユーザ情報と参照データとのマッチングを実行することによりマッチング結果を検証する。

さらに、１つの案では、上記の情報処理装置と同様の処理をコンピュータが実行するデータマッチング方法が提供される。

１つの側面では、ユーザに関する情報を用いたマッチングにおいて個人情報の秘匿性を確保できる。

第１の実施の形態に係るデータマッチングシステムの構成例および処理例を示す図である。 第２の実施の形態に係るデータマッチングシステムの構成例を示す図である。 事業者サーバのハードウェア構成例を示す図である。 データマッチングシステムの動作の比較例を示す図である。 第２の実施の形態に係るデータマッチングシステムの動作の概要を示す図である。 属性情報に基づくスケッチングデータの算出例を示す図である。 事業者サーバに送信される送信データの例を示す図である。 データマッチングシステム内の各装置が備える処理機能の構成例を示す図である。 スケッチングデータ登録時の処理手順を示すシーケンス図の例である。 サービス登録画面の表示例を示す図である。 スケッチングデータの提供要求画面の表示例を示す図である。 ボランティアの活動を依頼する際の処理手順を示すシーケンス図の例（その１）である。 ボランティアの活動を依頼する際の処理手順を示すシーケンス図の例（その２）である。 ボランティア活動の依頼画面の表示例を示す図である。 元データ提供に対する同意操作画面の表示例を示す図である。

以下、本発明の実施の形態について図面を参照して説明する。
〔第１の実施の形態〕
図１は、第１の実施の形態に係るデータマッチングシステムの構成例および処理例を示す図である。図１に示すデータマッチングシステムは、情報処理装置１と端末装置２とを有する。

情報処理装置１は、それぞれ個別のユーザに関するユーザ情報１１，１２，１３，・・・を用いたマッチングを行うことで、特定のユーザを抽出する装置である。例えば、情報処理装置１は、ユーザ情報１１，１２，１３，・・・として各ユーザの行動履歴を取得し、それらの行動履歴を基に、特定の目的に適したユーザを抽出する。

ただし、情報処理装置１は、マッチングの対象となる各ユーザから、ユーザ情報をそのまま取得するのではなく、確率的データ構造を有するスケッチングデータの形式で取得する。情報処理装置１は、スケッチングデータを用いたマッチングの結果としてあるユーザが特定されたときに、そのユーザからスケッチングデータの元データであるユーザ情報を取得する。そして、情報処理装置１は、取得したユーザ情報を用いて再度マッチングを行うことで、スケッチングデータを用いたマッチングの結果を検証する。

図１の例では、ユーザ情報１１，１２，１３，・・・を変換することでスケッチングデータ２１，２２，２３，・・・が得られるものとする。
端末装置２は、ユーザによって操作される端末装置の１つである。図１では例として、端末装置２は、ユーザ情報１１に対応するユーザＡによって操作されるものとする。

以下、本実施の形態に係るデータマッチングシステムの処理について、順を追って説明する。
まず、情報処理装置１は、スケッチングデータ２１，２２，２３，・・・を受信する（ステップＳ１）。これらのうち、ユーザＡに対応するスケッチングデータ２１は、例えば、端末装置２から情報処理装置１に送信される。情報処理装置１は、記憶部３を備えており、受信したスケッチングデータ２１，２２，２３，・・・を記憶部３に格納する。なお、記憶部３は、情報処理装置１が備える図示しない記憶装置の記憶領域として実現される。

次に、情報処理装置１は、格納されたスケッチングデータ２１，２２，２３，・・・のそれぞれと、所定の参照データ３１とのマッチングを実行する（ステップＳ２）。参照データ３１は、特定のユーザを抽出するためのデータである。なお、実際には、参照データ３１から変換されたスケッチングデータが、記憶部３内のスケッチングデータ２１，２２，２３，・・・とマッチングされる。

ステップＳ２では、例えば、スケッチングデータ２１，２２，２３，・・・のそれぞれと、参照データ３１に基づくスケッチングデータとの類似度が算出される。そして、類似度が最も高く、かつ、類似度が所定の閾値以上であるスケッチングデータが存在する場合に、そのスケッチングデータに対応するユーザがマッチング結果として特定される。

図１では例として、マッチング結果としてユーザＡが特定されたとする。この場合、情報処理装置１は、ユーザＡに対して、ユーザＡに対応するユーザ情報１１の提供を要求する提供要求を送信する（ステップＳ３）。

端末装置２は、送信された提供要求に応じて、ユーザＡのユーザ情報１１の提供に同意する同意操作を、ユーザＡから受け付ける（ステップＳ４）。例えば、提供要求により、提供が要求された情報の内容がユーザに通知される。この通知は、例えば、ユーザＡ宛ての電子メールを送信することや、端末装置２の表示装置（図示せず）に対する情報表示によって行われる。また、この通知では、例えば、提供が要求された情報の種別、その情報の使用目的などが通知される。そして、ユーザＡは、この通知に基づいて、提供が要求された情報の内容を確認し、情報提供に同意する場合にのみ同意操作を行う。

端末装置２は、ユーザＡによる同意操作に応じて、ユーザ情報１１に基づいてユーザＡの署名データ１１ａを生成する（ステップＳ５）。署名データ１１ａは、例えば、少なくともユーザ情報１１を含む送信情報に基づくハッシュ値を、ユーザＡの秘密鍵を用いて暗号化することで生成される。そして、端末装置２は、ユーザ情報１１に署名データ１１ａを付加して情報処理装置１に送信する（ステップＳ６）。

情報処理装置１は、署名データ１１ａが付加されたユーザ情報１１を受信すると、受信したユーザ情報１１と、ステップＳ２で使用された参照データ３１とのマッチングを行う（ステップＳ７）。このマッチングにより、ステップＳ２でのマッチングの結果が検証される。例えば、ユーザ情報１１と参照データ３１との類似度が所定の閾値以上であれば、ステップＳ２でのマッチングの結果が正しかったと判定される。

以上の処理によれば、各ユーザに関するユーザ情報１１，１２，１３，・・・が、スケッチングデータ２１，２２，２３，・・・に変換されて情報処理装置１に蓄積される。そして、スケッチングデータ２１，２２，２３，・・・を用いてマッチングが行われ、そのマッチングの結果として特定されたユーザについてのみ、ユーザ情報が情報処理装置１に提供される。

スケッチングデータは、元データであるユーザ情報と比較して、個人情報の特定が困難なデータである。各ユーザのユーザ情報１１，１２，１３，・・・がこのようなスケッチングデータ２１，２２，２３，・・・として情報処理装置１に蓄積されることで、個人情報が漏洩する危険性が低下する。また、スケッチングデータを用いたマッチングにより特定されたユーザのユーザ情報だけが提供されることで、ユーザ情報が情報処理装置１に提供され、利用される機会が限定される。

しかも、ユーザ情報は、ユーザによる明確な同意操作に応じて提供される。そして、提供されるユーザ情報には、その同意操作に応じて生成されたユーザの署名データが付加される。情報処理装置１では、ユーザ情報にユーザの署名データが付加されていることで、ユーザ情報の提供にユーザが同意したことを明確に確認した上で、そのユーザ情報をマッチングに利用できる。例えば、署名データに基づいて、受信したユーザ情報が改ざんされていないことが確認された場合にのみ、ユーザ情報を用いたマッチングが実行される。このため、個人情報の秘匿性が高まり、ユーザのプライバシー保護の強度が向上する。

また、スケッチングデータを用いたマッチングは、ある程度の誤差が生じるので、元データを用いたマッチングより精度が低い。図１の処理では、スケッチングデータを用いたマッチングの結果を、元データを用いたマッチングによって検証することで、マッチング精度を維持できるようになる。

したがって、本実施の形態によれば、ユーザに関する情報を用いた高精度なマッチングを行うのに際して、ユーザの個人情報の秘匿性を確保できる。
〔第２の実施の形態〕
図２は、第２の実施の形態に係るデータマッチングシステムの構成例を示す図である。図２に示すデータマッチングシステムは、事業者サーバ１００、ユーザ端末２００，２００ａ，２００ｂ，・・・および管理者サーバ３００を含む。事業者サーバ１００、ユーザ端末２００，２００ａ，２００ｂ，・・・および管理者サーバ３００は、ネットワーク５０を介して相互に接続されている。

事業者サーバ１００は、事業者によって運用されるサーバコンピュータである。事業者サーバ１００は、ユーザの属性情報を用いてマッチングを行うことで、特定の目的に適するユーザや、特定の条件に合致するユーザを抽出するマッチングサービスを提供する。

ユーザ端末２００，２００ａ，２００ｂ，・・・は、ユーザによって操作される端末装置である。ユーザは、ユーザ端末２００，２００ａ，２００ｂ，・・・のいずれかを操作することで、ユーザ自身に関する属性情報を事業者サーバ１００に登録し、事業者サーバ１００によるマッチングの結果を示す情報を受け取ることができる。ユーザ端末２００，２００ａ，２００ｂ，・・・を用いることで、事業者サーバ１００には多数のユーザの属性情報が登録され得る。

管理者サーバ３００は、ユーザの属性情報を管理する管理者によって運用されるサーバコンピュータである。管理者サーバ３００は、ユーザ端末２００，２００ａ，２００ｂ，・・・からの要求に応じて、ユーザの属性情報を要求元のユーザ端末を介して事業者サーバ１００に送信する。

管理者サーバ３００は、ユーザの属性情報の種別ごとに個別に設けられてもよい。例えば、ユーザの行動履歴（位置情報、購買履歴など）を管理する管理者サーバ３００と、ユーザに関する著作物（ユーザによる著書や論文、ユーザが記載された新聞記事など）を管理する管理者サーバ３００とが個別に設けられていてもよい。このように管理者サーバ３００が属性情報の種別ごとに設けられる場合、ユーザの属性情報は複数の管理者サーバ３００によって分散管理されることになる。

また、ネットワーク５０には、ブロックチェーン４００を構築するノード群４０１が接続されている。ノード群４０１には、サーバなどのコンピュータノードが複数含まれている。ブロックチェーン４００は、ＤＩＤ（Decentralized IDentifier）を用いたデジタルＩＤサービスを提供する。ＤＩＤは、非集権的に管理される分散型のＩＤである。

デジタルＩＤサービスからは、少なくとも、各ユーザ、事業者サーバ１００を運用する事業者、管理者サーバ３００を運用するデータ管理者に対してそれぞれ個別のＩＤが発行される。以下、ユーザ、事業者、データ管理者に対して発行されたＩＤを、それぞれユーザＩＤ、事業者ＩＤ、管理者ＩＤと記載する。ブロックチェーン４００では、例えば、発行された各ＩＤに対して公開鍵を対応付けて管理されている。

図３は、事業者サーバのハードウェア構成例を示す図である。事業者サーバ１００は、例えば、図３に示すようなコンピュータとして実現される。図３に示す事業者サーバ１００は、プロセッサ１０１、ＲＡＭ（Random Access Memory）１０２、ＨＤＤ（Hard Disk Drive）１０３、グラフィックインタフェース（Ｉ／Ｆ）１０４、入力インタフェース（Ｉ／Ｆ）１０５、読み取り装置１０６およびネットワークインタフェース（Ｉ／Ｆ）１０７を備える。

プロセッサ１０１は、事業者サーバ１００全体を統括的に制御する。プロセッサ１０１は、例えば、ＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）、ＤＳＰ（Digital Signal Processor）、ＡＳＩＣ（Application Specific Integrated Circuit）またはＰＬＤ（Programmable Logic Device）である。また、プロセッサ１０１は、ＣＰＵ、ＭＰＵ、ＤＳＰ、ＡＳＩＣ、ＰＬＤのうちの２以上の要素の組み合わせであってもよい。

ＲＡＭ１０２は、事業者サーバ１００の主記憶装置として使用される。ＲＡＭ１０２には、プロセッサ１０１に実行させるＯＳ（Operating System）プログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、ＲＡＭ１０２には、プロセッサ１０１による処理に必要な各種データが格納される。

ＨＤＤ１０３は、事業者サーバ１００の補助記憶装置として使用される。ＨＤＤ１０３には、ＯＳプログラム、アプリケーションプログラム、および各種データが格納される。なお、補助記憶装置としては、ＳＳＤ（Solid State Drive）などの他の種類の不揮発性記憶装置を使用することもできる。

グラフィックインタフェース１０４には、表示装置１０４ａが接続されている。グラフィックインタフェース１０４は、プロセッサ１０１からの命令にしたがって、画像を表示装置１０４ａに表示させる。表示装置としては、液晶ディスプレイや有機ＥＬ（ElectroLuminescence）ディスプレイなどがある。

入力インタフェース１０５には、入力装置１０５ａが接続されている。入力インタフェース１０５は、入力装置１０５ａから出力される信号をプロセッサ１０１に送信する。入力装置１０５ａとしては、キーボードやポインティングデバイスなどがある。ポインティングデバイスとしては、マウス、タッチパネル、タブレット、タッチパッド、トラックボールなどがある。

読み取り装置１０６には、可搬型記録媒体１０６ａが脱着される。読み取り装置１０６は、可搬型記録媒体１０６ａに記録されたデータを読み取ってプロセッサ１０１に送信する。可搬型記録媒体１０６ａとしては、光ディスク、光磁気ディスク、半導体メモリなどがある。

ネットワークインタフェース１０７は、ネットワーク５０を介して他の装置との間でデータの送受信を行う。
以上のようなハードウェア構成によって、事業者サーバ１００の処理機能を実現することができる。なお、ユーザ端末２００，２００ａ，２００ｂ，・・・および管理者サーバ３００についても、例えば、図３に示すような構成のコンピュータとして実現することができる。ユーザ端末２００，２００ａ，２００ｂ，・・・は、図３の構成の他、例えば、表示装置１０４ａが一体化されたノート型コンピュータや、タブレット型端末、スマートフォンとして実現されてもよい。

次に、データマッチングシステムにおけるマッチング処理の具体例について説明する。
前述のように、管理者サーバ３００では、ユーザの行動履歴やユーザに関する著作物といったユーザの属性情報が管理される。管理者サーバ３００は、例えば、このような属性情報を各ユーザから収集することができる。

以下の説明では、管理者サーバ３００では属性情報として、ユーザの行動履歴、特にユーザの位置情報の履歴が管理されるものとする。この場合、例えば、ユーザが携帯する端末装置においてユーザの位置情報が計測される。位置情報としては、ＧＰＳ（Global Positioning System）データが計測される。管理者サーバ３００は、計測されたユーザの位置情報をユーザの端末装置から収集し、ユーザＩＤに対応付けて記憶する。なお、ユーザの位置情報が計測される端末装置として、図２に示すユーザ端末２００，２００ａ，２００ｂ，・・・が用いられてもよい。

また、事業者サーバ１００を運用する事業者は、地域の案内を行うボランティアを派遣する派遣事業を行う。この派遣事業に関し、事業者サーバ１００は、ボランティアのマッチングサービスを提供する。マッチングサービスでは、事業者サーバ１００は、サービスに対するユーザの登録を受け付け、登録されたユーザの中から、地域ごとに適切なユーザを特定して、そのユーザに地域案内のボランティアを行うように依頼する。ユーザの特定では、ユーザの位置情報の履歴に基づき、ある地域を案内するボランティアとして、その地域で行動する頻度が高い、あるいは行動する時間が長いユーザが特定される。

ここで、図４を用いて、ユーザの位置情報を用いたマッチングを含むシステム動作の比較例を示し、その後の図５以降において、第２の実施の形態におけるシステム動作について説明する。

図４は、データマッチングシステムの動作の比較例を示す図である。
管理者サーバ３００は、ユーザの属性情報が記憶されたユーザデータ記憶部３１０を備える。管理者サーバ３００は、前述のように属性情報をユーザから収集し、収集されたユーザデータ記憶部３１０に登録する。ユーザデータ記憶部３１０には、各ユーザのユーザＩＤに対応付けて、属性情報として位置情報（ＧＰＳデータ）が蓄積される。

ユーザは、ボランティアのマッチングサービスに対して事前に登録する。この登録では、ユーザ端末を用いてユーザ自身の属性情報が事業者サーバ１００に登録される。以下、ユーザ端末２００を操作するユーザが属性情報を登録する場合について説明する。

属性情報の登録処理では、ユーザ端末２００から管理者サーバ３００に対して、ユーザのユーザＩＤを指定して属性情報の送信が要求される。管理者サーバ３００は、この送信要求に応じて、ユーザＩＤに対応する属性情報をユーザデータ記憶部３１０から読み出し、ユーザ端末２００に送信する（ステップＳ１１）。ユーザ端末２００は、送信された属性情報を事業者サーバ１００に転送し、ユーザＩＤを指定して属性情報の登録を要求する。事業者サーバ１００は、ユーザデータ記憶部１１０を備えており、ユーザ端末２００から登録が要求された属性情報を、ユーザＩＤに対応付けてユーザデータ記憶部１１０に登録する（ステップＳ１２）。

事業者サーバ１００は、ユーザの属性情報とのマッチングの際に参照される参照データが登録された参照データ記憶部１２０を備えている。参照データは、地域ごとに登録され、対応する地域を案内するユーザを特定するための条件を示すデータである。例えば、参照データには、対応する地域において案内の対象となるランドマークの位置情報や、ランドマーク間の移動経路上のポイントを示す位置情報が記述される。

事業者サーバ１００は、ユーザデータ記憶部１１０に登録された各ユーザの属性情報と、参照データ記憶部１２０に登録された各参照データとのマッチングを行って、地域案内をするボランティアとしてふさわしいユーザを地域ごとに特定する。ただし、属性情報はデータサイズが大きく、大量の属性情報をそのまま用いてマッチングを行うと、マッチングの処理負荷が過大となる。そこで、図４の例では、属性情報のスケッチングデータが算出され、スケッチングデータを用いてマッチングが行われる。

スケッチングデータは、確率的データ構造を有するデータである。元データをスケッチングデータに変換することで、データサイズが縮小される。変換後のスケッチングデータを用いた場合のクエリに対する処理結果にはある程度の誤差が生じるものの、そのクエリに対する処理の効率を高めることができる。

スケッチングデータの算出アルゴリズムとしては、マッチングの内容に応じて選択可能である。例えば、ＭｉｎＨａｓｈは、集合間の類似度の算出に適する。Ｃｏｕｎｔ－Ｍｉｎ Ｓｋｅｔｃｈは、要素の出現頻度の一致判定に適する。ブルームフィルタは、要素が集合に含まれるかの判定に適する。

事業者サーバ１００は、次のような手順でマッチングを行う。まず、事業者サーバ１００は、ユーザデータ記憶部１１０に登録された各ユーザの属性情報を基に、ユーザごとのスケッチングデータを算出する。これとともに、事業者サーバ１００は、参照データ記憶部１２０に登録された各参照データを基に、スケッチングデータを算出する（ステップＳ１３）。なお、各スケッチングデータの算出は、各記憶部に対する登録時点で実行されてもよい。

事業者サーバ１００は、各属性情報に基づくスケッチングデータと、各参照データに基づくスケッチングデータとのマッチングを行う（ステップＳ１４）。例えば、ある１つの参照データに基づくスケッチングデータと、各属性情報に基づくスケッチングデータとのマッチングが行われたとすると、事業者サーバ１００は、このマッチングにより参照データとの類似性が高い属性情報を特定する。例えば、属性情報に基づくスケッチングデータの中から、参照データに基づくスケッチングデータとの類似度が最大であり、かつ所定の閾値以上であるスケッチングデータがある場合に、そのスケッチングデータに対応する属性情報がマッチング結果として特定される。

次に、事業者サーバ１００は、特定された属性情報をユーザデータ記憶部１１０から読み出すとともに、マッチングが行われた参照データを参照データ記憶部１２０から読み出す。そして、事業者サーバ１００は、属性情報と参照データとのマッチングを行う（ステップＳ１５）。このマッチングは、スケッチングデータを用いたマッチング（ステップＳ１４）の結果が正しいかを確認するためのものであり、例えば、類似度が所定の閾値以上である場合にマッチング結果が正しいと判断される。この場合、事業者サーバ１００は、属性情報に対応するユーザを、参照データに対応する地域を案内するボランティアとしてふさわしいと判断して、そのユーザに対してボランティアの活動を依頼する（ステップＳ１６）。

ボランティアの依頼は、例えば、電子メールなどによってユーザ端末２００に通知される。その通知を受けたユーザは、ボランティアの依頼を承諾する場合、ユーザ端末２００を介して事業者サーバ１００に対して依頼を承諾することを通知する（ステップＳ１７）。

以上の比較例では、まず、スケッチングデータを用いてマッチングが行われ、その後にスケッチングデータの元データを用いてマッチングが行われる。このような手順によれば、ユーザデータ記憶部１１０に登録された属性情報をそのまま用いたマッチングは、登録された属性情報のうち、スケッチングデータを用いたマッチングにより特定された属性情報についてのみ行われる。このため、マッチングの処理負荷を軽減できる。また、スケッチングデータを用いたマッチングの結果の正当性が、元データを用いたマッチングによって検証されるので、マッチング精度が低下することを防止できる。

ところで、ユーザの属性情報はユーザの個人情報であるので、慎重な取り扱いが必要である。図４に示す手順では、管理者サーバ３００から事業者サーバ１００に対する属性情報の提供は、少なくとも、ユーザの同意が確実に得られた状態で行われた方がよい。例えば、管理者サーバ３００からの属性情報の送信は、ユーザ端末２００に対するユーザによる明確な同意の操作に応じて実行される（ステップＳ１２ａ）。また、事業者サーバ１００に対する属性情報の転送は、ユーザが同意したことを事業者サーバ１００側が確認できる状態で行われる。

属性情報の送信は、例えば、Ｗ３Ｃ（World Wide Web Consortium）で標準化されているＶＣ（Verifiable Credential）の仕組みを用いて行うことができる。ＶＣでは、属性情報のデータ形式や転送手順などが規定されている。ＶＣでは、秘密鍵・公開鍵を用いたセキュアなデータ転送が行われる。

例えば、ユーザの操作によって属性情報の送信が管理者サーバ３００に要求されると、管理者サーバ３００は、ユーザの属性情報に、管理者ＩＤに対応付けられた秘密鍵を用いて署名し、署名された属性情報をユーザ端末２００に送信する。ユーザ端末２００は、受信したデータに対して、ユーザＩＤに対応付けられた秘密鍵を用いてさらに署名し、署名されたデータを事業者サーバ１００に送信する。

事業者サーバ１００は、ユーザＩＤに対応付けられた公開鍵をブロックチェーン４００上のレポジトリ（図示せず）から取得し、取得した公開鍵を用いてユーザの署名を復号することで、受信したデータの内容に改ざんがないかを確認する。このとき、データにユーザの署名があることで、改ざんの有無とともに、ユーザによる情報提供の同意があったことも確認できる。また、事業者サーバ１００は、管理者ＩＤに対応付けられた公開鍵を上記のレポジトリから取得し、取得した公開鍵を用いてデータ管理者の署名を復号することで、受信したデータの内容に改ざんがないかをさらに確認する。

しかしながら、個人情報の取り扱いという観点では次のような課題もある。図４に示した手順では、ユーザの属性情報がそのまま事業者サーバ１００に提供され、蓄積される。このため、ユーザにとっては、個人情報の漏洩の懸念もあり、情報提供に対する心理的抵抗が大きい。この点は、事業者サーバ１００に対する属性情報の登録数が増えない原因にもなり、事業者サーバ１００のサービス品質の低下にもつながる。

さらに、図４に示した手順では、スケッチングデータと比較してサイズの大きい属性情報が、そのまま事業者サーバ１００に送信され、蓄積される。このため、ネットワーク５０の負荷や、事業者サーバ１００側でデータを蓄積するための容量が大きくなるという問題もある。

そこで、属性情報を事業者サーバ１００にそのまま提供するのでなく、属性情報をスケッチングデータに変換した上で事業者サーバ１００に提供する方法が考えられる。この方法によれば、個人情報の特定が困難なスケッチングデータの状態で属性情報が提供されることで、データの秘匿性が高まり、情報提供の際のユーザの心理的抵抗も小さくなる。また、事業者サーバ１００に送信されるデータのサイズも縮小できる。その一方で、事業者サーバ１００ではスケッチングデータを用いたマッチングしか行われなくなるので、マッチング精度が低下するという問題がある。

そこで、第２の実施の形態では、次の図５に示すように、ユーザの属性情報ではなく、属性情報に基づくスケッチングデータが事業者サーバ１００に提供され、登録される。事業者サーバ１００では、スケッチングデータを用いたマッチングが行われ、マッチングによりユーザが暫定的に特定されると、そのユーザの属性情報が事業者サーバ１００に提供される。事業者サーバ１００では、提供された属性情報を用いたマッチングの実行により、スケッチングデータを用いたマッチング結果の正当性が確認される。このような手順により、ユーザの個人情報の秘匿性を高めつつ、かつ、マッチング精度を維持しながら、マッチングを含む一連の処理の効率を高めることを可能にする。

図５は、第２の実施の形態に係るデータマッチングシステムの動作の概要を示す図である。
図５に示すように、管理者サーバ３００は、図４と同様のユーザデータ記憶部３１０を備える。一方、事業者サーバ１００は、図４と同様の参照データ記憶部１２０を備えるが、図４のユーザデータ記憶部１１０の代わりに、属性情報に基づくスケッチングデータを蓄積するためのスケッチングデータ記憶部１１１を備える。

マッチングサービスに対する登録の際には、まず、管理者サーバ３００において、ユーザデータ記憶部３１０からユーザの属性情報が読み出され、その属性情報に基づいてスケッチングデータが算出される（ステップＳ２１）。算出されたスケッチングデータはユーザ端末２００に送信され、ユーザ端末２００から事業者サーバ１００に転送されて、スケッチングデータ記憶部１１１に登録される（ステップＳ２２）。このような管理者サーバ３００から事業者サーバ１００に対するスケッチングデータの提供は、ユーザの同意が得られた状態で行われる。

事業者サーバ１００は、スケッチングデータ記憶部１１１に登録された各ユーザのスケッチングデータを用いて、マッチングを行う（ステップＳ２３）。このマッチングでは、参照データ記憶部１２０に登録された参照データに基づくスケッチングデータと、スケッチングデータ記憶部１１１に登録されたスケッチングデータとの類似度が計算される。

ここで、マッチングにより、ユーザ端末２００を操作するユーザに対応するスケッチングデータが特定されたとする。この場合、参照データに対応する地域を案内するボランティアとして、ユーザが暫定的に特定されたことになる。すると、事業者サーバ１００は、そのボランティアとして活動することをユーザに依頼する（ステップＳ２４）。この依頼の際には、スケッチングデータを用いたマッチングの結果を検証するために、スケッチングデータに対応する元データ、すなわち属性情報の提供を要求することが、ユーザに対して明確に通知される。

ユーザにより依頼を承諾する操作が行われると（ステップＳ２５）、ユーザ端末２００から管理者サーバ３００に対して属性情報の提供が要求される。この承諾操作は、属性情報の提供にユーザが同意したことを示す。管理者サーバ３００からは、この要求に応じてユーザの属性情報（元データ）が送信され、ユーザ端末２００を介して事業者サーバ１００に転送される（ステップＳ２６）。このような手順により、属性情報の提供はユーザの同意が得られた状態で行われることになる。

事業者サーバ１００は、提供された属性情報と、ステップＳ２３で用いられた参照データとのマッチングを実行して、ステップＳ２３のマッチングの結果を確認する（ステップＳ２７）。マッチングの結果が正しいと判定された場合、ユーザに対するボランティア活動の依頼処理が完了し、ユーザがそのボランティア活動を承諾したことが確定される（ステップＳ２８）。

以上の手順によれば、各ユーザの属性情報は、データサイズが小さく、かつ個人情報の特定が困難なスケッチングデータに変換されて事業者サーバ１００に提供され、登録される。そして、スケッチングデータを用いたマッチングにより特定されたユーザについてのみ、スケッチングデータの元データである属性情報が事業者サーバ１００に提供される。

これにより、各ユーザの属性情報を事業者サーバ１００に提供する場合と比較して、事業者サーバ１００に送信されるデータ量を低減でき、事業者サーバ１００側で情報を蓄積するための容量を縮小できる。また、属性情報自体を用いたマッチングの実行回数が減少するので、マッチングの処理負荷を軽減できる。さらに、スケッチングデータを用いたマッチングの結果の正当性が元データを用いたマッチングによって検証されるので、マッチング精度の低下を防止できる。

また、事業者サーバ１００側で属性情報が蓄積されないので、属性情報が漏洩する可能性を低減できる。また、マッチングに基づく特定のユーザについてのみ属性情報が提供されるので、全体として属性情報の秘匿性を向上させることができる。また、提供された属性情報は特定の参照データとの１回のマッチング時のみ使用される。このため、属性情報の使用目的や使用機会が限定されることから、この点でも属性情報の秘匿性を向上させることができ、個人情報のセキュリティを強化できる。

また、ユーザによる情報登録時には、属性情報はスケッチングデータの状態で事業者サーバ１００に登録されるので、情報登録に対するユーザの心理的抵抗を軽減できる。このため、事業者サーバ１００に対する情報登録が促進され、事業者サーバ１００のサービス品質を向上させることができる。

また、ユーザは、上記のように属性情報の使用機会が限定され、しかもその使用目的を認識した状態で、属性情報の提供に同意することができる。このため、情報提供に対するユーザの心理的抵抗を軽減できる。また、この点については、このような同意の下で、属性情報が限定的な目的および機会で使用されることから、属性情報の秘匿性が向上し、個人情報のセキュリティが強化される、ということもできる。

図６は、属性情報に基づくスケッチングデータの算出例を示す図である。図６では、ＭｉｎＨａｓｈ法によりスケッチングデータが算出される場合を例示する。
ＭｉｎＨａｓｈ法では、２つの集合の各要素に対してあるハッシュ関数を適用することで、各集合について複数のハッシュ値が算出され、各集合について、複数のハッシュ値の中から最小値が抽出される。このとき、両者の最小値が一致する確率は集合間の類似度に等しい、という考え方が用いられる。

実際には、例えば、複数のハッシュ関数（ｋ個のハッシュ関数とする）をそれぞれ用いて上記のようにハッシュ値が算出される。その結果、集合ごとにハッシュ値の最小値がｋ個抽出される。そして、一方の集合についてのｋ個の最小値と、他方の集合についてのｋ個の最小値とが比較され、値が一致した数が類似度の近似値として算出される。

図６では、管理者サーバ３００において属性情報に基づいてスケッチングデータが算出される場合を例示している。図６の例では、ユーザの属性情報として行動履歴３２１が収集される。行動履歴３２１には、ユーザの移動軌跡を示す位置情報（例えば、経度・緯度を示すＧＰＳデータ）の集合が含まれる。そして、この行動履歴３２１から、特徴量を示す数値配列３２２が算出される（ステップＳ３１）。例えば、行動履歴３２１に基づき、ユーザの移動軌跡に近接する所定のランドマークの位置情報が、数値配列３２２として算出される。図６では、ｎ箇所のランドマークの位置情報が数値配列３２２に記述されている。なお、数値配列３２２には、例えば、ランドマークの位置情報の代わりに、ランドマークの識別番号が記述されてもよい。

なお、ユーザデータ記憶部３１０に登録される属性情報としては、行動履歴３２１の情報が登録されてもよいし、数値配列３２２のように、行動履歴３２１を基に算出された特徴量を示す情報が登録されてもよい。前者の場合には、属性情報が管理者サーバ３００から事業者サーバ１００に提供される際、行動履歴３２１から再度算出された特徴量を示す情報が、事業者サーバ１００に提供されてもよい。

一方、事業者の事業者ＩＤと属性情報に対応するユーザのユーザＩＤとをシード値として、要素数ｋのハッシュ関数列３２３が生成される（ステップＳ３２）。すなわち、ハッシュ関数列３２３には、ｋ個のハッシュ関数ｈ１（），ｈ２（），・・・，ｈｋ（）が含まれる。そして、数値配列３２２に含まれる要素（位置情報）のそれぞれに対応するハッシュ値が、ｋ個のハッシュ関数ｈ１（），ｈ２（），・・・，ｈｋ（）をそれぞれ用いて計算される（ステップＳ３３）。これにより、それぞれｎ個のハッシュ値を含むｋ個の数値配列３２４＿１，３２４＿２，・・・，３２４＿ｋが算出される。

なお、事業者ＩＤとユーザＩＤとがシード値として用いられることで、事業者とユーザとの間でのみ共有されるハッシュ関数が生成される。これにより、スケッチングデータから元データを類推することの難度が高まり、データの秘匿性が向上する。

次に、ｋ個の数値配列３２４＿１，３２４＿２，・・・，３２４＿ｋのそれぞれからハッシュ値の最小値が抽出され、抽出された最小値の配列３２５が生成される（ステップＳ３４）。この配列３２５が属性情報に基づくスケッチングデータとなる。

ところで、本実施の形態に係るデータマッチングシステムでは、ＶＣで規定された手順で情報が伝送される。この情報伝送では、ＩＤに対応付けられた暗号鍵を用いて、伝送される情報に対して段階的に署名データが付加される。これにより、伝送される情報の正当性が保証されるとともに、伝送経路上の装置ごとに、正当性を示す情報を段階的に付加することができる。

図７は、事業者サーバに送信される送信データの例を示す図である。図７では、スケッチングデータの送信の際にＶＣ方式で生成される送信データ２１０を例示している。
管理者サーバ３００では、送信データ２１０のうち領域２１１の「ｃｌａｉｍ」の情報が生成される。「ｃｌａｉｍ」においては、「ｉｄ」にユーザのユーザＩＤが記述される。また、「ｃｌａｉｍ」内の「ｓｋｅｔｃｈ」には、送信対象データを示す「ｖａｌｕｅｓ」、送信対象データのタイプを示す「ｔｙｐｅ」、送信対象データのサイズを示す「ｌｅｎｇｔｈ」が記述される。スケッチングデータの提供の際には、「ｖａｌｕｅｓ」の項目に、提供が要求されたスケッチングデータ（ハッシュ値の最小値の配列）が記述される。

さらに本実施の形態では、スケッチングデータの提供の際には、「ｓｋｅｔｃｈ」の中に「ｈａｓｈ」が記述される。「ｈａｓｈ」には、スケッチングデータの元データ（すなわち、対応する属性情報）のハッシュ値が記述される。後述するように、このハッシュ値は、元データを用いたマッチングが行われる前に、スケッチングデータと元データとの対応関係の正当性を確認するために利用される。

また、「ｃｌａｉｍ」には、「ｓｉｇｎａｔｕｒｅＶａｌｕｅ」が記述される。「ｓｉｇｎａｔｕｒｅＶａｌｕｅ」には、「ｓｋｅｔｃｈ」に記述されたデータに基づくハッシュ値を、管理者ＩＤに対応する秘密鍵で暗号化することで算出されたデータ管理者の署名データが記述される。

ユーザ端末２００は、上記の「ｃｌａｉｍ」の情報を管理者サーバ３００から受信すると、この情報に生成日時などの所定のヘッダ情報を付加するとともに、「ｓｉｇｎａｔｕｒｅ」を付加する（図７の領域２１２）。「ｓｉｇｎａｔｕｒｅ」には、ユーザの署名データが記述される。ユーザの署名データは、「ｃｌａｉｍ」に記述されたデータに基づくハッシュ値を、ユーザＩＤに対応する秘密鍵で暗号化することで算出される。

以上のようにして生成された送信データ２１０は、ユーザ端末２００から事業者サーバ１００に送信される。事業者サーバ１００は、ユーザの署名データに基づいて、受信した送信データ２１０のうち、「ｃｌａｉｍ」の領域における改ざんの有無を確認できる。また、事業者サーバ１００は、データ管理者の署名データに基づいて、「ｓｋｅｔｃｈ」の領域における改ざんの有無を確認できる。

また、元データ（すなわち、属性情報）が提供される際には、「ｖａｌｕｅｓ」に元データが記述され、「ｓｉｇｎａｔｕｒｅＶａｌｕｅ」にデータ管理者の署名データが記述された「ｃｌａｉｍ」が管理者サーバ３００で生成される。ただし、「ｃｌａｉｍ」には「ｈａｓｈ」は含まれない。このような「ｃｌａｉｍ」がユーザ端末２００に送信されると、この情報に所定のヘッダ情報が付加されるとともに、ユーザの署名データが記述された「ｓｉｇｎａｔｕｒｅ」が付加されて、事業者サーバ１００に送信される。

このように、ＶＣの規定にしたがって送信データが生成されて伝送されることで、提供が要求されたユーザに関する情報は、段階的に適切なデータ形式で流通されるようになる。例えば、ユーザは、ユーザ自身に関する情報を、提供元であるデータ管理者の署名が付加された状態で受け取る。これによりユーザは、情報の提供者やその内容が保証された状態でユーザの情報を確実に受け取ることができる。そして、ユーザは、ユーザ自身による明確な同意の操作に応じて、受け取った情報に対してユーザ自身の署名を付加し、情報の利用者である事業者に提供することができる。事業者は、データ管理者およびユーザの署名に基づいて、提供された情報の内容の正当性を確認できるとともに、ユーザの署名からユーザから提供の同意が得られたことを明確に確認できる。ユーザにとっては、ユーザ自身が提供に同意している情報のみを情報の利用者である事業者に確実に受け渡すことができる。

また、本実施の形態では、スケッチングデータの提供の際に、元データに基づくハッシュ値も事業者サーバ１００に提供される。事業者サーバ１００は、提供されたハッシュ値を、スケッチングデータとともにユーザＩＤに対応付けてスケッチングデータ記憶部１１１に登録する。そして、事業者サーバ１００は、このスケッチングデータを用いたマッチング結果に基づいてユーザから属性情報を受信したときに、対応するハッシュ値を用いることで、受信した属性情報がスケッチングデータの元データであることを検証できる。これにより、属性情報を用いたマッチング処理の確実性を高めることができる。

以下、第２の実施の形態に係るデータマッチングシステムの動作について、さらに詳しく説明する。
図８は、データマッチングシステム内の各装置が備える処理機能の構成例を示す図である。

まず、図８に示すリポジトリサーバ４１０は、図２に示したノード群４０１に含まれるノードの１つとして実現されるサーバコンピュータである。リポジトリサーバ４１０は、公開鍵記憶部４１１と鍵管理部４１２とを備える。

公開鍵記憶部４１１は、例えば、リポジトリサーバ４１０が備える図示しない記憶装置の記憶領域として実現される。公開鍵記憶部４１１には、前述のデジタルＩＤサービスから発行されたＩＤに対応付けて、公開鍵が記憶されている。鍵管理部４１２の処理は、例えば、リポジトリサーバ４１０が備える図示しないプロセッサが所定のプログラムを実行することで実現される。鍵管理部４１２は、ＩＤが発行された場合に、ＩＤの保有者側で生成された非対称鍵方式の鍵ペア（秘密鍵と公開鍵）のうち、公開鍵の登録を受け付け、ＩＤに対応付けて公開鍵記憶部４１１に登録する。本実施の形態では、少なくとも、ユーザＩＤ、事業者ＩＤおよび管理者ＩＤに対応する公開鍵が公開鍵記憶部４１１に登録される。また、鍵管理部４１２は、ＩＤを指定した要求に応じて、そのＩＤに対応する公開鍵を提供する。

管理者サーバ３００は、前述のユーザデータ記憶部３１０に加えて、秘密鍵記憶部３３０、データ提供部３４１、スケッチングデータ算出部３４２および署名エンジン３４３を備える。

ユーザデータ記憶部３１０および秘密鍵記憶部３３０は、例えば、管理者サーバ３００が備える図示しない記憶装置の記憶領域として実現される。ユーザデータ記憶部３１０には、ユーザＩＤに対応付けて、ユーザに関して収集された属性情報が登録される。秘密鍵記憶部３３０には、データ管理者の管理者ＩＤに対応する秘密鍵が記憶される。

データ提供部３４１、スケッチングデータ算出部３４２および署名エンジン３４３の処理は、例えば、管理者サーバ３００が備える図示しないプロセッサが所定のプログラムを実行することで実現される。

データ提供部３４１は、ユーザ端末２００からの要求に応じて、指定されたユーザＩＤに対応する属性情報やスケッチングデータを提供するための処理を実行する。スケッチングデータ算出部３４２は、ユーザデータ記憶部３１０から読み出した属性情報に基づいてスケッチングデータを算出する。署名エンジン３４３は、データ管理者の秘密鍵を用いてデータ管理者の署名データを生成する。

ユーザ端末２００は、秘密鍵記憶部２２０、データ登録部２３１、元データ送信部２３２および署名エンジン２３３を備える。
秘密鍵記憶部２２０は、例えば、ユーザ端末２００が備える図示しない記憶装置の記憶領域として実現される。秘密鍵記憶部２２０には、ユーザ端末２００を操作するユーザのユーザＩＤに対応する秘密鍵が記憶される。

データ登録部２３１、元データ送信部２３２および署名エンジン２３３の処理は、例えば、ユーザ端末２００が備える図示しないプロセッサが所定のプログラムを実現することで実現される。データ登録部２３１は、マッチングサービスにユーザを登録するために、ユーザの属性情報に基づくスケッチングデータを事業者サーバ１００に登録する処理を実行する。元データ送信部２３２は、事業者サーバ１００からの依頼に応じて、スケッチングデータの元データ（属性情報）を管理者サーバ３００から取得し、事業者サーバ１００に提供する処理を実行する。署名エンジン２３３は、ユーザの秘密鍵を用いてユーザの署名データを生成する。

なお、図示しないが、他のユーザ端末２００ａ，２００ｂ，・・・も、ユーザ端末２００と同様の処理機能を備える。
事業者サーバ１００は、前述のスケッチングデータ記憶部１１１および参照データ記憶部１２０に加えて、登録受付部１３１、マッチング部１３２、依頼処理部１３３および署名検証部１３４を備える。

スケッチングデータ記憶部１１１および参照データ記憶部１２０は、例えば、ＲＡＭ１０２やＨＤＤ１０３など、事業者サーバ１００が備える記憶装置の記憶領域として実現される。

スケッチングデータ記憶部１１１には、ユーザ端末２００，２００ａ，２００ｂ，・・・から登録されたユーザに関する情報が登録される。スケッチングデータ記憶部１１１には、各ユーザのユーザＩＤに対応付けて、少なくとも、スケッチングデータと、元データに基づくハッシュ値とが記憶される。

参照データ記憶部１２０には、マッチング処理においてユーザの属性情報と照合される参照データが、ボランティアに案内させる地域ごとに登録される。例えば、参照データとしては、地域ごとに、その地域において案内の対象となるランドマークの位置情報や、ランドマーク間の移動経路上のポイントを示す位置情報が記述される。また、参照データには、ランドマークや移動経路上のポイントを示す識別情報が記述されていてもよい。

登録受付部１３１は、ユーザ端末２００，２００ａ，２００ｂ，・・・からユーザのスケッチングデータの登録を受け付ける処理を実行する。マッチング部１３２は、スケッチングデータ記憶部１１１に登録されたスケッチングデータ、またはその元データと、参照データ記憶部１２０に登録された参照データとのマッチング処理を実行する。

依頼処理部１３３は、スケッチングデータを用いたマッチングによりボランティアを依頼するユーザが暫定的に特定された場合に、そのユーザに対してボランティアの活動を依頼するとともに、元データの提供を依頼する。依頼処理部１３３は、ユーザから元データが提供された場合には、元データを用いたマッチングをマッチング部１３２に実行させ、マッチングの結果をユーザに通知する。署名検証部１３４は、ユーザ端末２００，２００ａ，２００ｂ，・・・から受信したデータに付加された署名データに基づいて、データの正当性（改ざんの有無）を検証する。

図９は、スケッチングデータ登録時の処理手順を示すシーケンス図の例である。
［ステップＳ４１］ユーザ端末２００において、ボランティアのマッチングサービスを受けるためのアプリケーションが実行される。これによりデータ登録部２３１、元データ送信部２３２および署名エンジン２３３が起動し、まず、データ登録部２３１によってマッチングサービスに対する登録処理が実行される。

データ登録部２３１は、例えば、事業者サーバ１００のＷｅｂサーバにアクセスし、ボランティアの依頼を受けるためのサービスに対する登録画面の情報を取得する。これにより、ユーザ端末２００の表示装置にブラウザが表示され、ブラウザ内に登録画面が表示される。

ユーザは、登録画面に対して、ユーザのユーザＩＤと、ユーザに関する補助情報（例えば、名前、メールアドレスなど）とを入力し、登録操作を行う。これにより、データ登録部２３１は、入力された情報とともにサービスに対する登録要求を事業者サーバ１００に送信する。

［ステップＳ４２］事業者サーバ１００の登録受付部１３１は、受信したユーザＩＤと補助情報とをスケッチングデータ記憶部１１１に登録し、スケッチングデータの提供を要求する提供要求をユーザ端末２００に送信する。この処理では、例えば、事業者ＩＤ、提供を要求するデータ（マッチングに必要なデータ）の種別を示すデータ種別（位置情報、時刻など）、データ種別ごとに使用されるアルゴリズム名、要求データ数（図６のｎに対応）、その他の補助情報（データ取得期間、スケッチングデータの算出に必要なパラメータなど）が、提供要求とともに送信される。

［ステップＳ４３］ユーザ端末２００のデータ登録部２３１は、少なくとも、受信したデータ種別が示す、提供が要求されたデータの内容を、ブラウザ内に表示して、ユーザに確認させる。ユーザは、表示内容を確認し、情報提供に同意する場合には同意の操作を行う。その場合、処理はステップＳ４４に進められる。

［ステップＳ４４］データ登録部２３１は、事業者サーバ１００から受信した情報を、ユーザのユーザＩＤとともに管理者サーバ３００に送信して、スケッチングデータの提供を要求する。

ここで、図１０は、サービス登録画面の表示例を示す図である。図１０に示す画面２４０は、図９のステップＳ４１においてユーザ端末２００のブラウザに表示される。
画面２４０には、ユーザの名前、ユーザのメールアドレスをそれぞれ入力するための入力欄２４１，２４２と、登録を要求するための登録ボタン２４３とが表示されている。入力欄２４１，２４２にそれぞれ情報が入力され、登録ボタン２４３に対する選択操作が行われると、入力された名前およびメールアドレスとともに、名前に対応するユーザＩＤが事業者サーバ１００に送信される。

図１１は、スケッチングデータの提供要求画面の表示例を示す図である。図１１に示す画面２５０は、図９のステップＳ４３においてユーザ端末２００のブラウザに表示される。

画面２５０の領域２５１には、事業者から提供が要求された情報の内容を説明する文章が表示される。図９の例では、ユーザのアクティビティ情報が、統計的に処理された形式に加工され、個人の特定が不可能な状態で提供されること、提供された情報がマッチングの目的のみで利用されること、提供される情報として時刻情報とＧＰＳ情報が含まれることが、表示される。

また、画面２５０には同意ボタン２５２と不同意ボタン２５３とが表示されている。ユーザが領域２５１の表示内容を確認した上で情報提供に同意する場合、同意ボタン２５２に対する選択操作が行われる。この場合、図９のステップＳ４４の処理が実行される。すなわち、提供される情報の内容を確認したユーザによる明確な同意を示す操作に応じて、スケッチングデータの提供処理が実行されることになる。一方、情報提供に同意しない場合には、不同意ボタン２５３に対する選択操作が行われることで、登録処理は終了する。

以下、図９を用いて説明を続ける。
［ステップＳ４５］管理者サーバ３００のデータ提供部３４１は、ユーザ端末２００から受信した情報をスケッチングデータ算出部３４２に渡して、スケッチングデータの算出を依頼する。図６に示したようにＭｉｎＨａｓｈ法が用いられる場合、スケッチングデータ算出部３４２は、ユーザＩＤに対応する属性情報をユーザデータ記憶部３１０から要求データ数分（ｎ個）取得する。図６の例によれば、ｎ個のランドマークの位置情報が取得される。このとき、事業者サーバ１００から指定されたデータ取得期間に含まれるｎ個の位置情報が取得される。

スケッチングデータ算出部３４２は、ユーザＩＤと管理者ＩＤをシード値として用いてｋ個のハッシュ関数を生成し、ハッシュ関数をそれぞれ用いてｎ個の属性情報のハッシュ値を計算して、ハッシュ関数ごとにハッシュ値の最小値を抽出する。これにより、ｎ個の最小値を含む数値配列が、スケッチングデータとして算出される。

［ステップＳ４６］データ提供部３４１は、ステップＳ４５でユーザデータ記憶部３１０から取得されたｎ個の属性情報を用いてハッシュ計算を行い、元データのハッシュ値を算出する。

［ステップＳ４７］データ提供部３４１は、ステップＳ４５で算出されたスケッチングデータと、ステップＳ４６で算出された元データのハッシュ値とを含む「ｓｋｅｔｃｈ」のデータ（図７参照）を生成する。また、データ提供部３４１は、生成された「ｓｋｅｔｃｈ」のデータを署名エンジン３４３に通知し、データ管理者の署名データの生成を依頼する。

署名エンジン３４３は、データ管理者の秘密鍵を秘密鍵記憶部３３０から取得する。データ提供部３４１は、所定のハッシュ関数を用いて「ｓｋｅｔｃｈ」のデータのハッシュ値を算出し、算出されたハッシュ値をデータ管理者の秘密鍵で暗号化することで、データ管理者の署名データ（「ｓｉｇｎａｔｕｒｅＶａｌｕｅ」、図７参照）を生成する。

データ提供部３４１は、「ｓｋｅｔｃｈ」のデータと、署名データとを含む「ｃｌａｉｍ」のデータを生成して、ユーザ端末２００に送信する。なお、送信されるデータは、データ管理者の秘密鍵を用いて暗号化されていてもよい。

［ステップＳ４８］ユーザ端末２００のデータ登録部２３１は、「ｃｌａｉｍ」のデータを受信する。受信データが暗号化されていた場合、データ管理者の公開鍵を用いて受信データを復号し、「ｃｌａｉｍ」のデータを取得する。データ管理者の公開鍵は、リポジトリサーバ４１０の鍵管理部４１２から取得される。

データ登録部２３１は、「ｃｌａｉｍ」のデータを署名エンジン２３３に通知して、ユーザの署名データの生成を依頼する。署名エンジン２３３は、ユーザの秘密鍵を秘密鍵記憶部２２０から取得する。署名エンジン２３３は、所定のハッシュ関数を用いて「ｃｌａｉｍ」のデータのハッシュ値を算出し、算出されたハッシュ値をユーザの秘密鍵で暗号化することで、ユーザの署名データ（「ｓｉｇｎａｔｕｒｅ」、図７参照）を生成する。

データ登録部２３１は、「ｃｌａｉｍ」のデータに生成日時などの所定のヘッダ情報を付加し、ユーザの署名データとともに事業者サーバ１００に送信する。なお、送信されるデータは、ユーザの秘密鍵を用いて暗号化されていてもよい。

［ステップＳ４９］事業者サーバ１００の登録受付部１３１は、ユーザ端末２００からのデータを受信すると、署名データを用いて受信データを検証する。
まず、登録受付部１３１は、ユーザのユーザＩＤを指定してユーザの公開鍵をリポジトリサーバ４１０に要求する。この要求に応じて、リポジトリサーバ４１０の鍵管理部４１２からユーザＩＤに対応する公開鍵が送信され、事業者サーバ１００の登録受付部１３１がこの公開鍵を受信する。

登録受付部１３１は、ユーザ端末２００からの受信データが暗号化されていた場合、ユーザの公開鍵を用いて受信データを復号する。登録受付部１３１は、受信データからユーザの署名データを抽出し、ユーザの公開鍵を用いて復号する。登録受付部１３１は、受信データ内の「ｃｌａｉｍ」のデータのハッシュ値を算出し、算出されたハッシュ値と署名データを復号して得られたハッシュ値とを比較する。

これらのハッシュ値が一致した場合、「ｃｌａｉｍ」のデータが改ざんされていないことが確認されるとともに、ユーザからスケッチングデータの提供の同意が得られたことが確認される。すると、登録受付部１３１は次に、管理者ＩＤを指定してデータ管理者の公開鍵をリポジトリサーバ４１０に要求する。この要求に応じて、リポジトリサーバ４１０の鍵管理部４１２から管理者ＩＤに対応する公開鍵が送信され、事業者サーバ１００の登録受付部１３１がこの公開鍵を受信する。

登録受付部１３１は、「ｃｌａｉｍ」のデータからデータ管理者の署名データを抽出し、データ管理者の公開鍵を用いて復号する。登録受付部１３１は、受信データ内の「ｓｋｅｔｃｈ」のデータのハッシュ値を算出し、算出されたハッシュ値と署名データを復号して得られたハッシュ値とを比較する。これらのハッシュ値が一致した場合、「ｓｋｅｔｃｈ」のデータが改ざんされていないことが確認される。すると、処理がステップＳ５０に進められる。

なお、ユーザの署名またはデータ管理者の署名のいずれかを用いた検証でデータの改ざんが認められた場合、ユーザ端末２００に対して登録のエラーが通知され、登録処理は終了する。

［ステップＳ５０］登録受付部１３１は、受信データに含まれるスケッチングデータと元データのハッシュ値とを、ユーザＩＤに対応付けてスケッチングデータ記憶部１１１に登録する。

［ステップＳ５１］登録受付部１３１は、登録が正常に完了したことをユーザ端末２００に通知する。この通知に応じて、登録が正常に完了したことがユーザ端末２００のブラウザに表示される。

次に、図１２、図１３は、ボランティアの活動を依頼する際の処理手順を示すシーケンス図の例である。
［ステップＳ６１］事業者サーバ１００のマッチング部１３２は、スケッチングデータ記憶部１１１に登録されたユーザのスケッチングデータと、参照データ記憶部１２０に登録された参照データに基づくスケッチングデータとの間でマッチング処理を実行する。ここで、参照データを基にスケッチングデータを算出するためのハッシュ関数は、照合対象のスケッチングデータに対応するユーザごとに生成される。すなわち、ハッシュ関数は、照合対象のスケッチングデータに対応するユーザＩＤと、事業者ＩＤとをシードとして算出される。

ここで、ある参照データとの類似度が最も高く、かつ類似度が閾値以上であるユーザのスケッチングデータとして、ユーザ端末２００を操作するあるユーザが特定されたとする。この場合、その参照データに対応する地域を案内するボランティアとして、そのユーザがふさわしいと暫定的に判定されたことになる。

［ステップＳ６２］事業者サーバ１００の依頼処理部１３３は、マッチングにより特定されたユーザに対して、ボランティアとして活動することを依頼する活動依頼を通知する。ここでは例として、依頼処理部１３３は、特定されたユーザのメールアドレスをスケッチングデータ記憶部１１１から取得し、取得したメールアドレス宛てに、活動依頼を通知するためのメールを送信する。また、活動依頼を通知する情報には、依頼されるボランティアの活動内容や、その依頼に対して申し込むための案内情報が含まれる。

［ステップＳ６３］送信されたメールがユーザ端末２００に受信され、メールの内容をユーザが閲覧する。ユーザは、ボランティアの依頼内容を確認し、その依頼を承諾してボランティアに申し込みたいと考えた場合には、メールで案内された内容にしたがって申込操作を行う。

［ステップＳ６４］事業者サーバ１００の依頼処理部１３３は、スケッチングデータの元データ、すなわちユーザの属性情報の提供を要求する情報を送信する。送信される情報には、属性情報の要求情報として、事業者ＩＤ、提供を要求するデータのデータ種別、使用されるアルゴリズム名、要求データ数ｎ、その他の補助情報（データ取得期間など）が含まれる。さらに、送信される情報には、提供を要求する属性情報の内容をユーザに確認させるための情報や、提供の同意を求めるための情報が含まれる。

［ステップＳ６５］ユーザ端末２００の元データ送信部２３２は、受信した情報に基づいて、元データの提供に対する同意操作画面をブラウザに表示する。この同意操作画面には、提供が要求された属性情報の内容を示す情報や、提供の同意操作を行うための操作ボタンなどが含まれる。表示された情報をユーザが確認し、提供を同意する操作を行うと、処理がステップＳ６６に進む。

［ステップＳ６６］元データ送信部２３２は、ステップＳ６４での送信情報に含まれる、属性情報の要求情報を、管理者サーバ３００に送信する。
ここで、図１４は、ボランティア活動の依頼画面の表示例を示す図である。図１４に示す画面２６０は、図１２のステップＳ６２において事業者サーバ１００からユーザに通知される情報の一例を示す。図１２の画面２６０は、ユーザ宛ての電子メールによって活動依頼が通知された場合における、電子メールの表示例を例示している。

画面２６０には、ボランティアの依頼内容が表示される領域２６１と、依頼されたボランティアに申し込むためのボタン２６２と、ボランティアに申し込まないことを通知するためのボタン２６３とが含まれる。ユーザは、領域２６１に表示された内容を確認して、ボランティアに申し込むかを決める。

ボタン２６２に対する選択操作が行われると、このボタン２６２に対応付けられていたＵＲＬ（Uniform Resource Locator）に対してリンクされ、事業者サーバ１００から元データ（属性情報）の提供に対する同意操作画面を表示するための表示情報が送信される。一方、ボタン２６３に対する選択操作が行われると、ボランティアに申し込まないことが事業者サーバ１００に通知されて、処理が終了する。

図１４の画面２６０において依頼された内容は、属性情報に基づくスケッチングデータを用いたマッチングにより依頼されたものである。このため、必ずしも依頼内容がユーザにマッチしているとは限らない。例えば、ユーザがほとんど行ったことのない地域を案内するボランティアの活動が依頼される可能性がある。

依頼内容が不適切な場合には、ユーザは、ボタン２６３に対する選択操作を行うことで、ボランティアに申し込まないことを事業者サーバ１００に通知することができる。これにより、ユーザは、ユーザ自身の個人情報が事業者側に不必要に提供されることを抑止できる。

図１５は、元データ提供に対する同意操作画面の表示例を示す図である。図１４のボタン２６２に対する選択操作が行われると、事業者サーバ１００の依頼処理部１３３から、スケッチングデータの元データの提供依頼が送信される（図１２のステップＳ６４）。ユーザ端末２００の元データ送信部２３２は、提供依頼を受信すると、例えば、図１５に示すような画面２７０をブラウザに表示する。すなわち、画面２７０は、図１２のステップＳ６５で表示される同意操作画面の一例である。

画面２７０には、提供が要求された属性情報の内容を示す領域２７１と、提供された属性情報の使用目的を示す領域２７２と、情報提供に同意するためのボタン２７３と、情報提供に同意せず、ボランティアの申込をキャンセルするためのボタン２７４とが含まれる。ユーザは、領域２７１を視認して提供が要求された情報の内容を確認し、さらに領域２７２を視認して情報の使用目的を確認した上で、情報提供に同意するか否かを決めることができる。また、例えば、領域２７１に含まれるボタン２７５の選択操作を行うことで、提供が要求された情報についてのさらに詳細な内容を表示させて確認することもできる。

ボタン２７３に対する選択操作が行われると、属性情報の要求情報がユーザ端末２００から管理者サーバ３００に送信される（図１２のステップＳ６６）。一方、ボタン２７４に対する選択操作が行われると、情報提供に同意せず、ボランティアの申込をキャンセルすることが事業者サーバ１００に通知される。

このように、ユーザは、スケッチングデータの元データ、すなわち属性情報そのものの提供が要求された場合には、提供された情報の内容や使用目的を確実に確認した上で、属性情報を事業者に提供することができる。これにより、提供が要求された情報の内容やその使用目的に応じて、ユーザの意思により属性情報の提供機会を制限でき、属性情報の秘匿性を向上させることができる。

以下、図１３を用いて説明を続ける。
［ステップＳ６７］管理者サーバ３００のデータ提供部３４１は、管理者サーバ３００から受信した、属性情報の要求情報に基づき、ユーザデータ記憶部３１０からユーザの属性情報を要求データ数分（ｎ個）取得する。これにより、スケッチングデータに対応する元データが取得される。

［ステップＳ６８］データ提供部３４１は、取得された元データを含む「ｓｋｅｔｃｈ」のデータ（図７参照）を生成する。なお、例えば、元データのデータ量が過大な場合には、元データを取得するための、一時的に使用可能なＵＲＬが生成されて、元データの代わりにそのＵＲＬが「ｓｋｅｔｃｈ」に記述されてもよい。また、データ提供部３４１は、生成された「ｓｋｅｔｃｈ」のデータを署名エンジン３４３に通知し、データ管理者の署名データの生成を依頼する。

署名エンジン３４３は、図９のステップＳ４７と同様の手順で、「ｓｋｅｔｃｈ」のデータとデータ管理者の秘密鍵とに基づいてデータ管理者の署名データ（「ｓｉｇｎａｔｕｒｅＶａｌｕｅ」、図７参照）を生成する。データ提供部３４１は、「ｓｋｅｔｃｈ」のデータと、署名データとを含む「ｃｌａｉｍ」のデータを生成して、ユーザ端末２００に送信する。なお、送信されるデータは、データ管理者の秘密鍵を用いて暗号化されていてもよい。

［ステップＳ６９］ユーザ端末２００の元データ送信部２３２は、「ｃｌａｉｍ」のデータを受信する。受信データが暗号化されていた場合、データ管理者の公開鍵を用いて受信データを復号し、「ｃｌａｉｍ」のデータを取得する。元データ送信部２３２は、「ｃｌａｉｍ」の内容に基づいて、提供される情報の内容を示す情報をブラウザに表示する。ユーザは、この表示内容を確認することで、提供を同意した情報内容が正しく提供されるかを確認できる。

［ステップＳ７０］ステップＳ６９での表示情報には処理を続行するか否かを通知するためのボタンが含まれ、ユーザが情報の提供に同意し、処理を続行するためのボタンに対する選択操作が行われると、処理がステップＳ７１に進められる。

［ステップＳ７１］元データ送信部２３２は、「ｃｌａｉｍ」のデータを署名エンジン２３３に通知して、ユーザの署名データの生成を依頼する。署名エンジン２３３は、図９のステップＳ４８と同様の手順で、「ｃｌａｉｍ」のデータとユーザの秘密鍵とに基づいて、ユーザの署名データ（「ｓｉｇｎａｔｕｒｅ」、図７参照）を生成する。元データ送信部２３２は、「ｃｌａｉｍ」のデータに生成日時などの所定のヘッダ情報を付加し、ユーザの署名データとともに事業者サーバ１００に送信する。なお、送信されるデータは、ユーザの秘密鍵を用いて暗号化されていてもよい。

［ステップＳ７２］事業者サーバ１００の依頼処理部１３３は、ユーザ端末２００からのデータを受信すると、署名データを用いて受信データを検証する。
まず、依頼処理部１３３は、ユーザのユーザＩＤを指定してユーザの公開鍵をリポジトリサーバ４１０に要求する。この要求に応じて、リポジトリサーバ４１０の鍵管理部４１２からユーザＩＤに対応する公開鍵が送信され、事業者サーバ１００の依頼処理部１３３がこの公開鍵を受信する。

依頼処理部１３３は、ユーザ端末２００からの受信データが暗号化されていた場合、ユーザの公開鍵を用いて受信データを復号する。依頼処理部１３３は、受信データからユーザの署名データを抽出し、ユーザの公開鍵を用いて復号する。依頼処理部１３３は、受信データ内の「ｃｌａｉｍ」のデータのハッシュ値を算出し、算出されたハッシュ値と署名データを復号して得られたハッシュ値とを比較する。

これらのハッシュ値が一致した場合、「ｃｌａｉｍ」のデータが改ざんされていないことが確認されるとともに、ユーザから元データの提供の同意が得られたことが確認される。すると、依頼処理部１３３は次に、管理者ＩＤを指定してデータ管理者の公開鍵をリポジトリサーバ４１０に要求する。この要求に応じて、リポジトリサーバ４１０の鍵管理部４１２から管理者ＩＤに対応する公開鍵が送信され、事業者サーバ１００の依頼処理部１３３がこの公開鍵を受信する。

依頼処理部１３３は、「ｃｌａｉｍ」のデータからデータ管理者の署名データを抽出し、データ管理者の公開鍵を用いて復号する。依頼処理部１３３は、受信データ内の「ｓｋｅｔｃｈ」のデータのハッシュ値を算出し、算出されたハッシュ値と署名データを復号して得られたハッシュ値とを比較する。これらのハッシュ値が一致した場合、「ｓｋｅｔｃｈ」のデータが改ざんされていないことが確認される。すると、処理がステップＳ７３に進められる。

なお、ユーザの署名またはデータ管理者の署名のいずれかを用いた検証でデータの改ざんが認められた場合、ユーザ端末２００に対して情報提供のエラーが通知され、処理は終了する。

［ステップＳ７３］依頼処理部１３３は、スケッチングデータ記憶部１１１から、ユーザＩＤに対応付けられた、元データに基づくハッシュ値を取得する。また、依頼処理部１３３は、受信した「ｃｌａｉｍ」に含まれる元データのハッシュ値を算出する。依頼処理部１３３は、これらのハッシュ値を比較することで、受信した元データが、マッチングの際に使用された同じユーザのスケッチングデータの元データであるかを検証する。ハッシュ値が一致した場合、受信した元データの正当性が確認され、処理がステップＳ７４に進められる。一方、ハッシュ値が一致しなかった場合、ユーザ端末２００に対して情報提供のエラーが通知され、処理は終了する。

［ステップＳ７４］依頼処理部１３３は、受信した元データをマッチング部１３２に通知して、ステップＳ６１でのマッチングの正当性を確認するための再マッチングの実行を依頼する。マッチング部１３２は、ステップＳ６１で同じユーザのスケッチングデータとの間でマッチングを行った参照データを、参照データ記憶部１２０から取得し、取得した参照データと、依頼処理部１３３から通知された元データとのマッチング処理を実行する。

例えば、これらの類似度が所定の閾値以上である場合、ステップＳ６１でのマッチングの結果が正しかったと判定され、処理がステップＳ７５に進められる。一方、図示しないが、類似度が上記の閾値未満であり、ステップＳ６１でのマッチングの結果が正しくなかったと判定された場合には、ユーザの申込が受領されなかったことがユーザ端末２００に通知される。

［ステップＳ７５］依頼処理部１３３は、ユーザに対するボランティアの依頼が確定し、依頼処理が完了したことをユーザ端末２００に通知する。ユーザ端末２００の元データ送信部２３２は、通知された内容をブラウザに表示する。これにより、依頼処理が完了する。

なお、以上の第２の実施の形態では、マッチングサービスの例として、ある地域を案内するボランティアとして適切なユーザをマッチングにより特定するサービスを示したが、マッチングサービスとしてはこの例に限定されるものではない。例えば、適切な職歴を持つユーザに派遣社員としての業務を紹介または依頼するためのサービスを適用することができる。この場合、例えば、各ユーザの職歴やスキルの情報が管理者サーバ３００に収集される。事業者サーバ１００は、求める派遣社員の職歴やスキルの情報を参照データとして保持し、各ユーザの情報と参照データとのマッチングを行うことで、派遣社員として適切なユーザを特定し、そのユーザに対して派遣社員としての業務を紹介または依頼する。

また、例えば、自動車を運転する運転者の中から安全な運転を行っている運転者を特定するサービスを適用することもできる。この場合、例えば、車載器によって検出された各運転者の運転データ（スピードや経路の履歴など）が管理者サーバ３００に収集される。事業者サーバ１００は、参照データとして模範運転者の運転データを保持し、各運転者の運転データと模範運転者の運転データとの類似度を算出する。そして、事業者サーバ１００は、模範運転者との間で運転データの類似度が高い運転者を、安全な運転を行っている運転者として特定する。

なお、上記の各実施の形態に示した装置（例えば、情報処理装置１、端末装置２、事業者サーバ１００、ユーザ端末２００，２００ａ，２００ｂ，・・・、管理者サーバ３００）の処理機能は、コンピュータによって実現することができる。その場合、各装置が有すべき機能の処理内容を記述したプログラムが提供され、そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。コンピュータで読み取り可能な記録媒体としては、磁気記憶装置、光ディスク、光磁気記録媒体、半導体メモリなどがある。磁気記憶装置には、ハードディスク装置（ＨＤＤ）、磁気テープなどがある。光ディスクには、ＣＤ（Compact Disc）、ＤＶＤ（Digital Versatile Disc）、ブルーレイディスク（Blu-ray Disc：ＢＤ、登録商標）などがある。光磁気記録媒体には、ＭＯ（Magneto-Optical disk）などがある。

プログラムを流通させる場合には、例えば、そのプログラムが記録されたＤＶＤ、ＣＤなどの可搬型記録媒体が販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。

プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラムまたはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムにしたがった処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムにしたがった処理を実行することもできる。また、コンピュータは、ネットワークを介して接続されたサーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムにしたがった処理を実行することもできる。

１ 情報処理装置
２ 端末装置
３ 記憶部
１１，１２，１３，・・・ ユーザ情報
１１ａ 署名データ
２１，２２，２３，・・・ スケッチングデータ
３１ 参照データ

Claims (6)

1. 情報処理装置と端末装置とを有するデータマッチングシステムであって、
   前記情報処理装置は、
   それぞれ個別のユーザに関する複数のユーザ情報をそれぞれ変換して得られた、確率的データ構造をそれぞれ有する複数のスケッチングデータを受信して、前記情報処理装置が備える記憶部に格納し、
   前記複数のスケッチングデータと所定の参照データとのマッチングを実行し、
   前記複数のスケッチングデータの中からマッチング結果として一のスケッチングデータが特定されると、前記一のスケッチングデータに対応する一のユーザに対して、前記複数のユーザ情報のうち前記一のユーザに対応する一のユーザ情報の提供を要求する提供要求を送信し、
   前記一のユーザ情報を、前記一のユーザの署名データが付加された状態で受信し、受信した前記一のユーザ情報と前記参照データとのマッチングを実行することにより前記マッチング結果を検証し、
   前記端末装置は、
   前記提供要求に応じて、前記一のユーザ情報の提供に同意する同意操作を前記一のユーザから受け付け、
   前記同意操作に応じて、前記一のユーザ情報に基づいて前記署名データを生成し、前記署名データを付加した前記一のユーザ情報を前記情報処理装置に送信する、
   データマッチングシステム。
2. 前記情報処理装置は、受信した前記一のユーザ情報の正当性を前記署名データを用いて検証し、正当性が確認された場合に、受信した前記一のユーザ情報と前記参照データとのマッチングを実行する、
   請求項１記載のデータマッチングシステム。
3. 前記情報処理装置は、前記提供要求の送信の際、提供を要求する情報の種別とその使用目的とを示す通知情報を前記提供要求とともに送信し、
   前記端末装置は、前記提供要求を前記通知情報とともに受信すると、前記通知情報の内容を表示装置に表示して、前記同意操作を受け付ける、
   請求項１または２記載のデータマッチングシステム。
4. 前記情報処理装置は、
   前記複数のスケッチングデータの受信の際、前記複数のユーザ情報を基にそれぞれ算出された複数のハッシュ値を、前記複数のスケッチングデータとともに受信し、前記複数のスケッチングデータと前記複数のハッシュ値とを対応するユーザごとに前記記憶部に格納し、
   前記一のユーザ情報を受信したとき、前記一のユーザ情報に基づくハッシュ値を算出し、算出されたハッシュ値と、前記複数のハッシュ値のうち前記一のユーザに対応するハッシュ値とが同一の場合に、前記一のユーザ情報と前記参照データとのマッチングを実行する、
   請求項１乃至３のいずれか１項に記載のデータマッチングシステム。
5. 記憶部と処理部とを有する情報処理装置であって、
   前記処理部は、
   それぞれ個別のユーザに関する複数のユーザ情報をそれぞれ変換して得られた、確率的データ構造をそれぞれ有する複数のスケッチングデータを受信して、前記記憶部に格納し、
   前記複数のスケッチングデータと所定の参照データとのマッチングを実行し、
   前記複数のスケッチングデータの中からマッチング結果として一のスケッチングデータが特定されると、前記一のスケッチングデータに対応する一のユーザに対して、前記複数のユーザ情報のうち前記一のユーザに対応する一のユーザ情報の提供を要求する提供要求を送信し、
   前記一のユーザ情報を、前記一のユーザ情報の提供に前記一のユーザが同意する同意操作に応じて生成された、前記一のユーザの署名データが付加された状態で受信し、受信した前記一のユーザ情報と前記参照データとのマッチングを実行することにより前記マッチング結果を検証する、
   情報処理装置。
6. コンピュータが、
   それぞれ個別のユーザに関する複数のユーザ情報をそれぞれ変換して得られた、確率的データ構造をそれぞれ有する複数のスケッチングデータを受信して、前記コンピュータが備える記憶部に格納し、
   前記複数のスケッチングデータと所定の参照データとのマッチングを実行し、
   前記複数のスケッチングデータの中からマッチング結果として一のスケッチングデータが特定されると、前記一のスケッチングデータに対応する一のユーザに対して、前記複数のユーザ情報のうち前記一のユーザに対応する一のユーザ情報の提供を要求する提供要求を送信し、
   前記一のユーザ情報を、前記一のユーザ情報の提供に前記一のユーザが同意する同意操作に応じて生成された、前記一のユーザの署名データが付加された状態で受信し、受信した前記一のユーザ情報と前記参照データとのマッチングを実行することにより前記マッチング結果を検証する、
   データマッチング方法。

Images