(57)【特許請求の範囲】
【請求項１】
データ利用者が欲するパーソナルデータの条件である対象条件を含むリクエスト情報を取得するように構成されたリクエスト取得部と、
パーソナルデータ管理者が管理するパーソナルデータの属性を示す情報である属性情報を取得するように構成された属性情報取得部と、
前記属性情報に基づいて、前記データ利用者に適した調達プランを決定するように構成された調達プラン決定部であって、前記調達プランは、前記パーソナルデータ管理者が保有する前記対象条件に合致するパーソナルデータの中から調達するパーソナルデータに関する条件を示す、調達プラン決定部と、
前記調達プラン決定部によって決定された前記調達プランに従い、パーソナルデータを取得するように構成されたパーソナルデータ取得部と、
を備える仲介装置。
【請求項２】
請求項１に記載の仲介装置であって、
前記属性情報取得部は、前記パーソナルデータ管理者が保有する管理者装置から前記属性情報を取得する、仲介装置。
【請求項３】
請求項１又は請求項２に記載の仲介装置であって、
前記属性情報を記憶するように構成された記憶部を更に備え、
前記属性情報取得部は、前記記憶部から前記属性情報を取得する、仲介装置。
【請求項４】
請求項３に記載の仲介装置であって、
前記記憶部に記憶された前記属性情報を更新するように構成された更新処理部を更に備える、仲介装置。
【請求項５】
請求項１から請求項４までのいずれか１項に記載の仲介装置であって、
前記属性情報は、前記パーソナルデータ管理者が管理するパーソナルデータのうち前記対象条件に合致するパーソナルデータの属性を示す情報である、仲介装置。
【請求項６】
請求項１から請求項５までのいずれか１項に記載の仲介装置であって、
前記リクエスト取得部が前記リクエスト情報を取得した場合に、前記属性情報を要求する属性情報要求を、前記パーソナルデータ管理者が保有する管理者装置に送信するように構成された属性要求送信部を更に備え、
前記属性情報取得部は、前記属性情報要求に対する応答として、前記管理者装置から前記属性情報を受信する、仲介装置。
【請求項７】
請求項１から請求項６までのいずれか１項に記載の仲介装置であって、
前記リクエスト情報には、前記データ利用者の予算額を示す情報が含まれ、
前記調達プラン決定部は、前記パーソナルデータ管理者が保有する個々のパーソナルデータの価格と、前記予算額と、に基づき、前記調達プランを決定する、仲介装置。
【請求項８】
請求項１から請求項７までのいずれか１項に記載の仲介装置であって、
前記調達プラン決定部は、前記調達プランにより調達されるパーソナルデータの属性に基づく分布が、前記属性情報により示される、パーソナルデータの属性に基づくパーソナルデータの分布である元データ分布に近づくように前記調達プランを決定する、仲介装置。
【請求項９】
請求項８に記載の仲介装置であって、
前記リクエスト情報には、前記データ利用者の予算額を示す情報が含まれ、
前記調達プラン決定部は、前記予算額の範囲内で、前記調達プランにより調達されるパーソナルデータの属性に基づく分布が前記元データ分布に近づくように前記調達プランを決定する、仲介装置。
【請求項１０】
請求項１から請求項９までのいずれか１項に記載の仲介装置であって、
前記属性情報取得部は、複数の前記パーソナルデータ管理者が管理するパーソナルデータの属性を示す前記属性情報を取得し、
前記調達プラン決定部は、取得された前記属性情報に基づいて、前記複数のパーソナルデータ管理者が保有する前記対象条件に合致するパーソナルデータの中から調達するパーソナルデータに関する条件を示す前記調達プランを決定し、
前記パーソナルデータ取得部は、前記調達プランに基づいて、前記複数のパーソナルデータ管理者が保有する複数の管理者装置からパーソナルデータを取得する、仲介装置。
【請求項１１】
請求項１０に記載の仲介装置であって、
前記複数の管理者装置から受信されたパーソナルデータのデータ形式を共通のデータ形式に合わせるように構成された形式処理部と、
前記形式処理部によりデータ形式が合わせられた前記複数の管理者装置からのパーソナルデータを、前記データ利用者が保有する装置である利用者装置に送信するデータ送信部と、
を更に備える仲介装置。
【請求項１２】
請求項１から請求項１１までのいずれか１項に記載の仲介装置であって、
前記パーソナルデータ管理者は情報銀行である、仲介装置。
【請求項１３】
請求項１から請求項１２までのいずれか１項に記載の仲介装置を備えるシステムであって、
前記パーソナルデータ取得部によって取得されたパーソナルデータに応じた通知情報を取得するように構成された通知情報取得部であって、前記通知情報は、前記パーソナルデータ管理者にパーソナルデータを預託した個人に通知される情報である、通知情報取得部と、
前記通知情報取得部によって取得された前記通知情報を送信するように構成された通知情報送信部と、
を備えるシステム。
【請求項１４】
コンピュータを、
データ利用者が欲するパーソナルデータの条件である対象条件を含むリクエスト情報を取得するように構成されたリクエスト取得部と、
パーソナルデータ管理者が管理するパーソナルデータの属性を示す情報である属性情報を取得するように構成された属性情報取得部と、
前記属性情報に基づいて、前記データ利用者に適した調達プランを決定するように構成された調達プラン決定部であって、前記調達プランは、前記パーソナルデータ管理者が保有する前記対象条件に合致するパーソナルデータの中から調達するパーソナルデータに関する条件を示す、調達プラン決定部と、
前記調達プラン決定部によって決定された前記調達プランに従い、パーソナルデータを取得するように構成されたパーソナルデータ取得部と、
を備える仲介装置として機能させるコンピュータプログラム。
【発明の詳細な説明】
【関連出願の相互参照】
【０００１】
本国際出願は、２０１９年３月１１日に日本国特許庁に出願された日本国特許出願第２０１９−０４３６７４号、２０１９年１０月１５日に日本国特許庁に出願された日本国特許出願第２０１９−１８８９８５号、及び、２０１９年１０月１５日に日本国特許庁に出願された日本国特許出願第２０１９−１８８９８６号、に基づく優先権を主張するものであり、日本国特許出願第２０１９−０４３６７４号、日本国特許出願第２０１９−１８８９８５号及び日本国特許出願第２０１９−１８８９８６号の全内容を本国際出願に参照により援用する。
【技術分野】
【０００２】
本開示は、データ利用者とパーソナルデータ管理者との間のパーソナルデータの取引を仲介する仲介装置及びコンピュータを仲介装置として機能させるコンピュータプログラムに関する。
【背景技術】
【０００３】
パーソナルデータを管理するパーソナルデータ管理者が知られている。パーソナルデータ管理者としては例えば情報銀行が挙げられる。パーソナルデータ管理者は、パーソナルデータを預託した個人からデータ利用に関するポリシー等を通知され、通知されたポリシー等に従い第三者へのデータ提供の可否を判断する。なお、特許文献１には、データが預けられる情報銀行等が保有する情報処理装置から個人情報等が漏洩するのを防ぐことを目的とした情報処理システムが開示されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特許第６３４２０９４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ところで、企業などのパーソナルデータの利用者（以下、データ利用者）がパーソナルデータ管理者からパーソナルデータを調達する場合、データ利用者が欲するパーソナルデータの条件である対象条件をパーソナルデータ管理者に通達することが考えられる。【０００６】
しかしながら、データ利用者からは、パーソナルデータ管理者がどのようなパーソナルデータを保有しているかが把握しづらい。よって、問合せ先のパーソナルデータ管理者が対象条件に合致するパーソナルデータを十分に保有していないケースも想定される。この場合、データ利用者は、別のパーソナルデータ管理者に問い合わせるなど、再度やり取りが発生する場合がある。この場合、データ利用者がパーソナルデータを調達するに当たり作業負荷が増加し、ひいては、データ利用者が行う通信の通信量が増加する。【０００７】
本開示は、データ利用者に適したパーソナルデータの調達をより容易に行うことを可能にし、かつ、データ利用者が行う通信の通信量を低減し得る技術を提供することにある。
【課題を解決するための手段】
【０００８】
本開示の一態様は、仲介装置であって、リクエスト取得部と、属性情報取得部と、調達プラン決定部と、パーソナルデータ取得部と、を備える。リクエスト取得部は、データ利用者が欲するパーソナルデータの条件である対象条件を含むリクエスト情報を取得するように構成される。属性情報取得部は、パーソナルデータ管理者が管理するパーソナルデータの属性を示す情報である属性情報を取得するように構成される。調達プラン決定部は、属性情報に基づいて、データ利用者に適した調達プランを決定するように構成される。調達プランは、パーソナルデータ管理者が保有する対象条件に合致するパーソナルデータの中から調達するパーソナルデータに関する条件を示す。パーソナルデータ取得部は、調達プラン決定部によって決定された調達プランに従い、パーソナルデータを取得するように構成される。【０００９】
このような構成によれば、仲介装置は、データ利用者に適した調達プランを決定し、決定された調達プランに従いパーソナルデータをパーソナルデータ管理者から取得する。よって、データ利用者が、パーソナルデータ管理者が保有しているパーソナルデータが把握しづらい中でパーソナルデータ管理者に直接問い合わせてパーソナルデータを調達する場合と比較して、データ利用者に適したパーソナルデータの調達をより容易に行うことができ、かつ、データ利用者が行う通信の通信量を低減できる。【００１０】
本開示の一態様では、属性情報取得部は、パーソナルデータ管理者が保有する管理者装置から属性情報を取得してもよい。【００１１】
このような構成によれば、最新の内容の属性情報に基づき調達プランを決定することができる。【００１２】
本開示の一態様では、仲介装置は、属性情報を記憶するように構成された記憶部を更に備えてもよい。属性情報取得部は、記憶部から属性情報を取得してもよい。【００１３】
このような構成によれば、仲介装置は、パーソナルデータ管理者との間でデータのやり取りを行わなくても属性情報を取得できる。したがって、仲介装置の通信量を減らすことができる。【００１４】
本開示の一態様では、仲介装置は、記憶部に記憶された属性情報を更新するように構成された更新処理部を更に備えてもよい。【００１５】
このような構成によれば、更新された属性情報に基づき調達プランを決定することができる。【００１６】
本開示の一態様では、属性情報は、パーソナルデータ管理者が管理するパーソナルデータのうち対象条件に合致するパーソナルデータの属性を示す情報であってもよい。【００１７】
このような構成によれば、仲介装置は、パーソナルデータ管理者が管理するパーソナルデータのうち対象条件に合致するパーソナルデータの属性を踏まえて調達プランを決定することができる。【００１８】
本開示の一態様では、仲介装置は、属性要求送信部を更に備えてもよい。属性要求送信部は、リクエスト取得部がリクエスト情報を取得した場合に、属性情報を要求する属性情報要求を、パーソナルデータ管理者が保有する管理者装置に送信するように構成される。属性情報取得部は、属性情報要求に対する応答として、管理者装置から属性情報を受信する。【００１９】
このような構成によれば、リクエスト取得部がリクエスト情報を取得した場合に、パーソナルデータ管理者に問合せを行い、属性情報を取得する。したがって、最新の属性情報を取得でき、取得された属性情報に基づき調達プランを決定することができる。【００２０】
本開示の一態様では、リクエスト情報には、データ利用者の予算額を示す情報が含まれてもよい。調達プラン決定部は、パーソナルデータ管理者が保有する個々のパーソナルデータの価格と、予算額と、に基づき、調達プランを決定してもよい。【００２１】
このような構成によれば、データ利用者の予算額に応じて適切な調達プランを決定できる。【００２２】
本開示の一態様では、調達プラン決定部は、調達プランにより調達されるパーソナルデータの属性に基づく分布が、属性情報により示される、パーソナルデータの属性に基づくパーソナルデータの分布である元データ分布に近づくように調達プランを決定してもよい。【００２３】
このような構成によれば、パーソナルデータ管理者からパーソナルデータが調達された際にデータの偏りが発生することを抑制できる。【００２４】
本開示の一態様では、リクエスト情報には、データ利用者の予算額を示す情報が含まれてもよい。調達プラン決定部は、予算額の範囲内で、調達プランにより調達されるパーソナルデータの属性に基づく分布が元データ分布に近づくように調達プランを決定してもよい。【００２５】
このような構成によれば、データ利用者の予算額の範囲内で、データの偏りが発生することを出来るだけ抑制することができる。【００２６】
本開示の一態様では、属性情報取得部は、複数のパーソナルデータ管理者が管理するパーソナルデータの属性を示す属性情報を取得してもよい。調達プラン決定部は、取得された属性情報に基づいて、複数のパーソナルデータ管理者が保有する対象条件に合致するパーソナルデータの中から調達するパーソナルデータに関する条件を示す調達プランを決定してもよい。パーソナルデータ取得部は、調達プランに基づいて、複数の管理者装置からパーソナルデータを取得してもよい。【００２７】
このような構成によれば、データ利用者が、複数の情報銀行装置が保有しているパーソナルデータを把握しづらい中で複数の情報銀行装置に直接問い合わせてパーソナルデータを調達する場合と比較して、複数の情報銀行装置からデータ利用者に適したパーソナルデータをより容易に調達することができる。【００２８】
本開示の一態様は、形式処理部と、データ送信部と、を更に備えてもよい。形式処理部は、複数の管理者装置から受信されたパーソナルデータのデータ形式を共通のデータ形式に合わせるように構成される。データ送信部は、形式処理部によりデータ形式が合わせられた複数の管理者装置からのパーソナルデータを、データ利用者が保有する装置である利用者装置に送信する。【００２９】
このような構成によれば、データ利用者にとって取扱いしやすいデータ形式でパーソナルデータを納品することができる。【００３０】
本開示の一態様では、パーソナルデータ管理者は情報銀行であってもよい。【００３１】
本開示の一態様は、前記仲介装置を備えるシステムであって、通知情報取得部と、通知情報送信部と、を備えるシステムであってもよい。通知情報取得部は、パーソナルデータ取得部によって取得されたパーソナルデータに応じた通知情報を取得するように構成される。通知情報は、パーソナルデータ管理者にパーソナルデータを預託した個人に通知される情報である。通知情報送信部は、通知情報取得部によって取得された通知情報を送信するように構成される。【００３２】
このような構成によれば、パーソナルデータ管理者から取得されたパーソナルデータを使って通知情報を送信する。したがって、パーソナルデータを預託した個人に対し、その個人に適した通知情報を送信することができる。【００３３】
本開示の別の態様は、コンピュータプログラムであって、コンピュータを前記仲介装置として機能させる。このような構成によれば、前述した仲介装置と同様の効果を奏する。【００３４】
本開示の別の態様は、仲介装置であって、前記リクエスト取得部と、メタデータ要求送信部と、メタデータ受信部と、調達プラン決定部と、データ要求送信部と、データ受信部と、データ送信部と、を備える。メタデータ要求送信部は、パーソナルデータ管理者が保有する、メタデータを要求するメタデータ要求を、パーソナルデータ管理者が保有する装置である管理者装置に送信するように構成される。メタデータは、対象条件に合致するパーソナルデータの属性を示すデータである。メタデータ受信部は、管理者装置からメタデータを受信するように構成される。調達プラン決定部は、管理者装置から受信したメタデータに基づいて、データ利用者に適した調達プランを決定するように構成される。調達プランは、パーソナルデータ管理者が保有する対象条件に合致するパーソナルデータの中から調達するパーソナルデータに関する条件を示す。データ要求送信部は、調達プラン決定部によって決定された調達プランに従い、パーソナルデータを要求するデータ要求を管理者装置に送信するように構成される。データ受信部は、管理者装置からパーソナルデータを受信するように構成される。データ送信部は、パーソナルデータ管理者から受信したパーソナルデータをデータ利用者が保有する装置である利用者装置に送信するように構成される。【００３５】
このような構成によれば、仲介装置は、データ利用者に適した調達プランを決定し、決定された調達プランに従いパーソナルデータをパーソナルデータ管理者から取得し、取得されたパーソナルデータをデータ利用者に提供する。よって、データ利用者が、パーソナルデータ管理者が保有しているパーソナルデータが把握しづらい中でパーソナルデータ管理者に直接問い合わせてパーソナルデータを調達する場合と比較して、データ利用者に適したパーソナルデータの調達をより容易に行うことができる。
【図面の簡単な説明】
【００３６】
【図１】図１は第１実施形態の調達システムの構成を示す図である。
【図２】図２は第１〜第５実施形態の仲介装置のハードウェア構成を示すブロック図である。
【図３】図３は第１実施形態の仲介装置の機能的構成を示すブロック図である。
【図４】図４は第１実施形態のデータ調達処理のフローチャートである。
【図５】図５はリクエスト情報を説明するための図である。
【図６】図６は第１情報銀行に対する第１実施形態のメタデータ要求を説明するための図である。
【図７】図７は第２情報銀行に対する第１実施形態のメタデータ要求を説明するための図である。
【図８】図８Ａは第１情報銀行のカテゴリテーブルマスタを示す図、図８Ｂは第２情報銀行のカテゴリテーブルマスタを示す図である。
【図９】図９は第１実施形態のメタデータを説明するための図である。
【図１０】図１０はパーソナルデータの調達プランを決定するロジックの一例を説明するための図である。
【図１１】図１１は第１情報銀行に対するデータ要求を説明するための図である。
【図１２】図１２は第２情報銀行に対するデータ要求を説明するための図である。
【図１３】図１３は情報銀行からの納品データを説明するための図である。
【図１４】図１４は標準辞書を説明するための図である。
【図１５】図１５は第１情報銀行のデータ変換用辞書を説明するための図である。
【図１６】図１６Ａは第１情報銀行からの納品データを示す図、図１６Ｂは第２情報銀行からの納品データを示す図である。
【図１７】図１７は第１情報銀行からの変換後の納品データを示す図である。
【図１８】図１８は第２情報銀行からの変換後の納品データを示す図である。
【図１９】図１９は各情報銀行装置からの納品データを統合することで生成された統合データを説明するための図である。
【図２０】図２０は第２実施形態の仲介装置の機能的構成を示すブロック図である。
【図２１】図２１は第２実施形態のデータ調達処理のフローチャートである。
【図２２】図２２は第３実施形態の調達システムの構成を示す図である。
【図２３】図２３は管理者装置のハードウェア構成を示すブロック図である。
【図２４】図２４は管理者装置９が保有する重複管理テーブルを説明するための図である。
【図２５】図２５は第３及び第４実施形態の仲介装置の機能的構成を示すブロック図である。
【図２６】図２６は第３及び第４実施形態のデータ調達処理のフローチャートである。
【図２７】図２７はＩＤ要求を説明するための図である。
【図２８】図２８はＩＤ結果情報を説明するための図である。
【図２９】図２９は重複確認要求を説明するための図である。
【図３０】図３０は重複結果情報を説明するための図である。
【図３１】図３１は第３実施形態のメタデータ要求を説明するための図である。
【図３２】図３２は第１の情報銀行に対する第４実施形態のメタデータ要求を説明するための図である。
【図３３】図３３は第２の情報銀行に対する第４実施形態のメタデータ要求を説明するための図である。
【図３４】図３４は、同一個人のパーソナルデータが名寄せされた統合データを示す図である。
【図３５】図３５はパーソナルデータの価格情報を含む重複状況テーブルを示す図である。
【図３６】図３６は第５実施形態の仲介装置の機能的構成を示すブロック図である。
【図３７】図３７は第５実施形態のデータ調達処理のフローチャートである。
【図３８】図３８は第６実施形態の調達システムの構成を示す図である。
【図３９】図３９は広告配信を行う装置のハードウェア構成を示すブロック図である。
【図４０】図４０は広告配信処理のフローチャートである。
【図４１】図４１は第７及び第８実施形態のデータ調達処理のフローチャートである。
【図４２】図４２は第７実施形態のメタデータ要求を説明するための図である。
【図４３】図４３は匿名加工処理が施された、第１の情報銀行からの納品データを示す図である。
【図４４】図４４は第８実施形態のメタデータ要求を説明するための図である。
【図４５】図４５は統計情報化が施された、第１の情報銀行からの納品データを示す図である。
【図４６】図４６は第９実施形態の仲介装置の機能的構成を示すブロック図である。
【図４７】図４７は第９実施形態のデータ調達処理のフローチャートである。
【図４８】図４８は第９実施形態における第１情報銀行からの変換後の納品データを示す図である。
【図４９】図４９は第９実施形態における第２情報銀行からの変換後の納品データを示す図である。
【図５０】図５０は複数のパーソナルデータ同士の類似度を示す類似度行列を示す図である。
【図５１】図５１は類似度しきい値と紐付け成功数との関係を示すグラフである。
【図５２】図５２はパーソナルデータをデータ点として表現する座標空間を示す図である。
【図５３】図５３は多次元に拡張された、類似度しきい値と紐付け成功数との関係を示すグラフである。
【符号の説明】
【００３７】
１…調達システム、２…利用者装置、２ａ…データ利用者、
３，７，８，１１，１２…仲介装置、４〜６…情報銀行装置、４ａ〜６ａ…情報銀行、
９…管理者装置、９ａ…登録管理者、３３，７３，８３，１１３…制御部、
３３１…リクエスト取得部、３３２…メタデータ要求生成部、
３３３…メタデータ要求送信部、３３４…メタデータ受信部、３３５…条件整理部、
３３６…調達プラン決定部、３３７…データ要求生成部、３３８…データ要求送信部、
３３９…データ受信部、３４０…形式処理部、３４１…データ送信部、
７３１…メタデータ取得部、７３２…更新処理部、８３１…ＩＤ要求生成部、
８３２…ＩＤ要求送信部、８３３…ＩＤ受信部、８３４…重複確認生成部、
８３５…重複確認送信部、８３６…重複確認受信部、９３１…重複確認取得部、
９３２…更新処理部、１２３１…類似度判定部。
【発明を実施するための形態】
【００３８】
以下、図面を参照しながら、本開示を実施するための形態を説明する。
【００３９】
［１．第１実施形態］
［１−１．全体構成］
図１に示す調達システム１は、利用者装置２、仲介装置３及び複数の情報銀行装置４〜６を備える。
【００４０】
利用者装置２は、パーソナルデータを利用するデータ利用者２ａが保有する装置である。データ利用者２ａは、パーソナルデータを利用して利益を上げる企業等である。
【００４１】
ここで、本実施形態でいうパーソナルデータは、個人の識別性の有無にかかわらず、個人に関する情報全般を指す。パーソナルデータには、個人を特定、識別することができる個人情報が含まれる。ここでいう個人情報は、例えば、日本国個人情報保護法第２条第１項に規定の「個人情報」である。個人情報には、その情報自体で個人を識別できる情報のほか、他の情報と照合することができ、それにより個人を識別できる情報も含まれる。個人情報以外のパーソナルデータとしては、個人の位置情報や購入情報、ＩＰアドレス、インターネット閲覧履歴など、企業やネット上に集積されている情報等が挙げられる。また、個人情報以外のパーソナルデータとして、個人に結び付けることができないように加工された個人の行動や状態などに関するデータ等が挙げられる。
【００４２】
利用者装置２は、インターネット、専用無線／有線通信回線網のようなネットワークを介して仲介装置３に接続される。
【００４３】
仲介装置３は、データ利用者２ａに代わって、情報銀行装置４〜６に対してパーソナルデータのリクエストを行い、データ利用者２ａに適した条件でパーソナルデータを買い付けてデータ利用者２ａに納品するための装置である。仲介装置３は、例えば、データ利用者２ａと情報銀行４ａ〜６ａとの間のパーソナルデータの売買の仲介を行う業者により保有される。仲介装置３は、インターネット、専用無線／有線通信回線網のようなネットワークを介して利用者装置２及び情報銀行装置４〜６に接続される。仲介装置３のハードウェア構成及び機能については後で詳述する。
【００４４】
情報銀行装置４〜６は、それぞれ別々の情報銀行４ａ〜６ａに保有されている。情報銀行４ａ〜６ａは、個人から預託されたパーソナルデータを管理するとともに当該パーソナルデータを企業等の第三者に提供する事業を営む。
【００４５】
情報銀行装置４〜６には、個人が保有するスマートフォン、タブレット端末、パーソナルコンピュータ等の情報処理端末１１〜１７を介して個人から預託されたパーソナルデータが記憶されている。情報銀行装置４〜６は、インターネット、専用無線／有線通信回線網のようなネットワークを介して仲介装置３及び情報処理端末１１〜１７に接続される。後述するとおり、情報銀行装置４〜６は仲介装置３との間で各種情報をやり取りし、仲介装置３を介してパーソナルデータをデータ利用者２ａに納品する。
【００４６】
なお、図１では３つの情報銀行装置４〜６のみが図示されているが、仲介装置３は一般には３つ以外の情報銀行装置とパーソナルデータ等のデータのやり取りを行う。
【００４７】
［１−２．仲介装置］
次に、仲介装置３のハードウェア構成を図２を用いて説明する。仲介装置３は、通信部３１と、記憶部３２と、制御部３３と、を備える。
【００４８】
通信部３１は、仲介装置３をネットワークに接続するための通信インタフェースである。仲介装置３は、通信部３１を介して、利用者装置２及び情報銀行装置４〜６と有線又は無線にてデータ通信可能である。また、仲介装置３は、通信部３１を介してインターネットに接続し、インターネットを介して外部の装置とデータ通信可能であってもよい。
【００４９】
記憶部３２は、各種データを記憶する。
【００５０】
制御部３３は、ＣＰＵ３３ａと、ＲＡＭ、ＲＯＭ、フラッシュメモリ等の半導体メモリ（以下、メモリ３３ｂ）と、を有する周知のマイクロコンピュータを中心に構成される。制御部３３の各種機能は、ＣＰＵ３３ａが非遷移的実体的記憶媒体に格納されたプログラムを実行することにより実現される。この例では、メモリ３３ｂが、プログラムを格納した非遷移的実体的記憶媒体に該当する。また、このプログラムの実行により、プログラムに対応する方法が実行される。なお、制御部３３を構成するマイクロコンピュータの数は１つでも複数でもよい。
【００５１】
制御部３３は、ＣＰＵ３３ａがプログラムを実行することで後述する図４に示すデータ調達処理を実行する。制御部３３はデータ調達処理を実行することで、図３に示すように、リクエスト取得部３３１、メタデータ要求生成部３３２、メタデータ要求送信部３３３、メタデータ受信部３３４、条件整理部３３５、調達プラン決定部３３６、データ要求生成部３３７、データ要求送信部３３８、データ受信部３３９、形式処理部３４０及びデータ送信部３４１として機能する。制御部３３を構成するこれらの要素３３１〜３４１を実現する手法はソフトウェアに限るものではなく、その一部又は全部の要素を、論理回路やアナログ回路等を組み合わせたハードウェアを用いて実現してもよい。
【００５２】
以下では、まず図３を用いて各要素３３１〜３４１の機能の概要について説明する。その後、図４のフローチャートを用いて各要素３３１〜３４１の機能を詳細に説明する。
＜リクエスト取得部＞
リクエスト取得部３３１は、通信部３１を介して利用者装置２からのリクエスト情報を受信する。リクエスト情報は、データ利用者２ａが欲するパーソナルデータの条件である対象条件を含む情報である。リクエスト情報の具体例については後述する。
＜メタデータ要求生成部＞
メタデータ要求生成部３３２は、リクエスト取得部３３１により受信されたリクエスト情報に基づき、情報銀行装置４〜６に送信されるメタデータ要求を生成する。ここでいうメタデータ要求とは、情報銀行装置４〜６にメタデータを要求するための情報である。ここでいうメタデータは、情報銀行４ａ〜６ａが保有するパーソナルデータのうち、リクエスト情報に含まれる対象条件に合致するパーソナルデータの属性を示す情報である。ここでいうパーソナルデータの属性とは、パーソナルデータに係る個人の属性であり、例えば個人の年齢、性別等を意味する。もちろん、パーソナルデータの属性は、年齢及び性別以外の個人の属性であってもよい。換言すれば、パーソナルデータの属性は、当該パーソナルデータに含まれる、個人の年齢、性別等の各種属性を示す各データ項目を意味する。すなわち、パーソナルデータの属性は、パーソナルデータのデータ項目を意味する。
【００５３】
本実施形態では、メタデータは、その情報銀行が保有している、対象条件に合致する全部又は一部のパーソナルデータについてのデータの概要を示す。ここでいうデータの概要は、例えば、パーソナルデータの一部の属性や、パーソナルデータの各属性に関する統計情報等であってもよい。
【００５４】
メタデータは、情報銀行が保有している、対象条件に合致する全部又は一部のパーソナルデータがどのような属性のパーソナルデータから構成されるかを示す情報である。具体的には、後述するとおり、メタデータには、その情報銀行が保有する、対象条件に合致する全部又は一部のパーソナルデータの統計量の情報等が含まれる。メタデータ要求及びメタデータの具体例については後述する。
【００５５】
また、本実施形態では、情報銀行装置４〜６ごとに取扱い可能なデータ形式が異なる。そのため、メタデータ要求生成部３３２は、各情報銀行装置４〜６の取扱い可能なデータ形式に合わせて情報銀行装置４〜６ごとにメタデータ要求を生成する。
＜メタデータ要求送信部＞
メタデータ要求送信部３３３は、メタデータ要求生成部３３２により生成されたメタデータ要求を情報銀行装置４〜６に通信部３１を介して送信する。メタデータ要求を受信した情報銀行装置４〜６は、メタデータ要求に対する応答として、メタデータを仲介装置３に送信する。
＜メタデータ受信部＞
メタデータ受信部３３４は、情報銀行装置４〜６からメタデータを通信部３１を介して受信する。
＜条件整理部＞
条件整理部３３５は、情報銀行装置４〜６から受信されたメタデータから取引条件を整理する。
＜調達プラン決定部＞
調達プラン決定部３３６は、メタデータ受信部３３４により受信されたメタデータに基づいて、データ利用者２ａに適した調達プランを決定する。ここでいう調達プランとは、情報銀行装置４〜６が保有する、対象条件に合致するパーソナルデータの中から調達するパーソナルデータに関する条件を示す。つまり、調達プランにより示される条件に合致するパーソナルデータが情報銀行装置４〜６から調達（すなわち購入）される。調達プランの決定ロジックについては後述する。
＜データ要求生成部＞
データ要求生成部３３７は、調達プラン決定部３３６によって決定された調達プランに従い、データ要求を生成する。データ要求は、情報銀行装置４〜６にパーソナルデータを要求するためのデータである。データ要求生成部３３７は、各情報銀行装置４〜６の取扱い可能なデータ形式に合わせて情報銀行装置４〜６ごとにデータ要求を生成する。データ要求の具体例については後述する。
＜データ要求送信部＞
データ要求送信部３３８は、データ要求生成部３３７によって生成されたデータ要求を情報銀行装置４〜６に通信部３１を介して送信する。
＜データ受信部＞
データ受信部３３９は、データ要求を受信した情報銀行装置４〜６から納品データを通信部３１を介して受信する。納品データは、データ要求において指定されたパーソナルデータを含む。納品データの具体例については後述する。
＜形式処理部＞
形式処理部３４０は、複数の情報銀行装置４〜６から受信された納品データのデータ形式を共通のデータ形式に合わせ、１つのデータに統合することで統合データを生成する。統合データの具体例については後述する。
＜データ送信部＞
データ送信部３４１は、形式処理部３４０により生成された統合データを利用者装置２に通信部３１を介して送信する。これにより、情報銀行４ａ〜６ａから調達されたパーソナルデータがデータ利用者２ａに納品される。
【００５６】
［１−３．処理］
次に、仲介装置３の制御部３３が実行するデータ調達処理について、図４のフローチャートを用いて説明する。なお、データ調達処理は、リクエスト情報を利用者装置２から通信部３１を介して受信することにより開始される。なお、データ利用者２ａからリクエスト情報が受信されると、受信されたリクエスト情報は記憶部３２に記憶される。
【００５７】
＜Ｓ１０１＞
Ｓ１０１で、リクエスト取得部３３１は、データ利用者２ａからのリクエスト情報を記憶部３２から取得する。本実施形態のリクエスト情報は、図５に示す各項目を含む。すなわち、リクエスト情報は、タイムスタンプ、トランザクションＩＤ、文タイプ、宛先、送信元及び文内容を含む。なお、文タイプは、その情報が、リクエスト情報、メタデータ要求、メタデータ等のどのデータに該当するかを示すデータである。
【００５８】
文内容には、予算、報酬、対象条件、要求項目、分布集計軸、利用組織、利用目的及び利用条件の情報が含まれる。
【００５９】
予算の情報には、当該取引についてデータ利用者２ａが支払い可能な予算額の情報と、データ利用者２ａの費用の決済手段を示す情報と、が含まれる。
【００６０】
報酬の情報は、パーソナルデータを提供した個人に対するデータ利用者２ａからの報酬の情報である。報酬の情報には、報酬の形式、報酬の発行者、報酬の発行タイミング、報酬に係る特典等を使用可能な地域、報酬の発効時刻及び失効時刻等の情報が含まれる。
【００６１】
対象条件は、データ利用者２ａが欲するパーソナルデータの条件である。対象条件は、例えば、パーソナルデータに係る個人の属性（例えば性別、年齢、習慣等）を指定する条件である。データ利用者２ａが、条件が異なる複数のパーソナルデータを欲する場合、文内容に含まれる対象条件も複数になる。また、文内容には、対象条件ごとにその対象条件に合致するパーソナルデータをデータ利用者２ａがいくつ欲するかの件数の情報が含まれる。
【００６２】
例えば、図５に示す例では、１つ目の対象条件は、パーソナルデータに係る個人の性別が男性であり、レシピサイトの直近３ヶ月間の閲覧回数が３回以上である。また、データ利用者２ａが欲するこの対象条件に合致するパーソナルデータの件数は１０００件である。２つ目の対象条件は、パーソナルデータに係る個人の性別が女性であり、レシピサイトの直近３ヶ月間の閲覧回数が７回以上である。また、データ利用者２ａが欲するこの対象
条件に合致するパーソナルデータの件数は１０００件である。
【００６３】
要求項目は、データ利用者２ａが納品を希望する、パーソナルデータの項目（例えば性別、年代、居住都道府県等）である。
【００６４】
分布集計軸は、情報銀行装置４〜６から送信されるメタデータに含まれる、パーソナルデータの一部の項目を指定する。すなわち、後述するとおり、情報銀行装置４〜６から送信されるメタデータには、情報銀行４ａ〜６ａが保有する、対象条件に合致する全部又は一部のパーソナルデータの一覧（すなわちリスト）が含まれる。当該リストには、パーソナルデータのＩＤごとに、当該パーソナルデータの一部の項目と、当該パーソナルデータのデータ価格と、が含まれる。ここでいうパーソナルデータの一部の項目は、換言すれば、パーソナルデータに係る個人の一部の属性であり、例えば未婚率、年代等である。分布集計軸は、当該リストに含まれるパーソナルデータの前記一部の項目を指定する。なお、本実施形態では、分布集計軸に含まれるパーソナルデータの属性は、対象条件により指定された属性以外の属性に設定される。
【００６５】
利用組織、利用目的及び利用条件の情報は、パーソナルデータの利用組織、利用目的及び利用条件を示す。利用組織の情報には、例えば、利用組織の法人番号、名称、住所、国、業種等が含まれる。利用目的の情報には、例えば、利用の種別（顧客分析、ダイレクトメール送信等）や個別の利用目的が含まれる。個別の利用目的は、例えば、顧客情報拡充、統計作成、パーソナルデータの提供元の本人へのアクセス、広告配信等である。
【００６６】
リクエスト取得部３３１は、上記のようなリクエスト情報を利用者装置２から受信する。
【００６７】
＜Ｓ１０２＞
続いて、Ｓ１０２で、メタデータ要求生成部３３２は、Ｓ１０１で受信されたリクエスト情報に基づいて、メタデータ要求を生成する。メタデータ要求は、パーソナルデータの調達先の情報銀行４ａ〜６ａごとに生成される。具体的には、図６には第１情報銀行４ａに対するメタデータ要求の例が示される。また、図７には第２情報銀行５ａに対するメタデータ要求の例が示されている。図６及び図７に示すメタデータ要求はいずれも同じ項目を含む。
【００６８】
具体的には、メタデータ要求は、タイムスタンプ、トランザクションＩＤ、文タイプ、参照トランザクションＩＤ、宛先、送信元及び文内容を含む。参照トランザクションＩＤは、Ｓ１０１で受信されたリクエスト情報、換言すれば、当該メタデータ要求に関連するリクエスト情報のトランザクションＩＤである。
【００６９】
文内容には、報酬、対象条件、要求項目、分布集計軸、利用組織、利用目的及び利用条件の情報が含まれる。文内容に含まれるこれらの情報はリクエスト情報に含まれるものと同じである。
【００７０】
ここで、本実施形態では、情報銀行装置４〜６ごとに取扱い可能なデータ形式が異なる。そのため、メタデータ要求は、送信先の情報銀行装置４〜６の取扱い可能なデータ形式に合わせて生成される。
【００７１】
例えば、第１情報銀行装置４が取扱い可能なデータ形式では、パーソナルデータに係る個人の性別を表す変数は「Ｇｅｎｄｅｒ」であり、当該変数に格納される値「１」に対して「個人の性別は男である」との意味が対応付く。また、変数「Ｇｅｎｄｅｒ」に格納される値「２」に対して「個人の性別は女性である」との意味が対応付く。
【００７２】
一方、例えば、第２情報銀行装置５が取扱い可能なデータ形式では、パーソナルデータに係る個人の性別を表す変数は「性別」であり、当該変数に格納される値「男性」に対して「個人の性別は男である」との意味が対応付く。また、変数「性別」に格納される値「女性」に対して「個人の性別は女性である」との意味が対応付く。
【００７３】
そこで、メタデータ要求生成部３３２は、例えば図６に示す第１情報銀行装置４に対するメタデータ要求では、対象条件の項目において、「パーソナルデータに係る個人の性別が男性である」との条件を「Ｇｅｎｄｅｒ＝１」などのようなデータ形式で指定する。
【００７４】
一方、メタデータ要求生成部３３２は、例えば図７に示す第２情報銀行装置５に対するメタデータ要求では、対象条件の項目において、「パーソナルデータに係る個人の性別が男性である」との条件を「性別＝男性」などのようなデータ形式で指定する。
【００７５】
なお、情報銀行装置４〜６ごとのメタデータ要求は、図８Ａ及び図８Ｂに示すようなカテゴリテーブルマスタに基づいて作成される。カテゴリテーブルマスタは、メタデータ要求等に含まれる各項目を、各情報銀行装置４〜６の取扱い可能なデータ形式に変換するための情報である。或る情報銀行装置のカテゴリテーブルマスタでは、その情報銀行装置の取扱い可能なデータ形式で記述された「変数名」、「値」及び「意味」が互いに対応付けられて設定されている。本実施形態では、仲介装置３の取引先である各情報銀行装置４〜６のカテゴリテーブルマスタが、あらかじめ仲介装置３の記憶部３２に記憶されている。ただし、カテゴリテーブルマスタの所在はこれに限られない。例えば、メタデータ要求を生成するに際し、仲介装置３がカテゴリテーブルマスタを要求する情報を各情報銀行装置４〜６に送信し、その応答信号として各情報銀行装置４〜６のカテゴリテーブルマスタが取得されてもよい。つまり、メタデータ要求を生成するタイミングでカテゴリテーブルマスタが取得されてもよい。
【００７６】
＜Ｓ１０３＞
続いて、Ｓ１０３で、メタデータ要求送信部３３３は、Ｓ１０２で生成されたメタデータ要求を情報銀行装置４〜６に通信部３１を介して送信する。メタデータ要求を受信した情報銀行装置４〜６は、メタデータ要求の応答情報として、メタデータを仲介装置３に送信する。
【００７７】
＜Ｓ１０４＞
続いて、Ｓ１０４で、メタデータ受信部３３４は、各情報銀行装置４〜６からメタデータを通信部３１を介して受信する。メタデータは、各情報銀行装置４〜６の取扱い可能なデータ形式で記述されている。
【００７８】
本実施形態のメタデータは、図９に示す各項目を含む。図９には、第２情報銀行装置５から受信されたメタデータが示される。
【００７９】
メタデータには、タイムスタンプ、トランザクションＩＤ、文タイプ、参照トランザクションＩＤ、宛先、送信元、カテゴリコードマスタ及び文内容が含まれる。参照トランザクションＩＤは、当該メタデータに関連するメタデータ要求、換言すれば、当該メタデータの送信元の情報銀行装置に送信されたメタデータ要求のトランザクションＩＤである。カテゴリコードマスタは、当該メタデータの送信元の情報銀行装置に関するカテゴリコードマスタを特定する情報である。
【００８０】
文内容には、対象者の情報である対象者情報が含まれる。対象者情報は、リクエスト情報に含まれる対象条件と、当該情報銀行が保有するパーソナルデータのうち対象条件に合致する全部又は一部のパーソナルデータの件数と、を含む。また、対象者情報は、対象条件に合致する全部又は一部のパーソナルデータがどのような属性のパーソナルデータから構成されるかを示す。
【００８１】
具体的には、対象者情報は、要求項目統計量を含む。要求項目統計量は、要求項目で指定される各属性に関するパーソナルデータの統計量（平均、分散、歪度、中央値等）や最大値及び最小値などである。また、対象者情報には、分散共分散行列、パーソナルデータのデータ価格分布の情報とその他多変量の統計量の情報とが含まれる。
【００８２】
ここで、データ価格分布の情報は、パーソナルデータを分布集計軸により指定される属性で分類した際の各分類に含まれるパーソナルデータのデータ価格を示す。例えば、分布集計軸において「未既婚、年代、３ヶ月雑誌購買有無」の属性が指定されているとする。この場合、データ価格分布の情報には、「未既婚：未婚、年代：３０、３ヶ月雑誌購買有無＝無」との分類に含まれるパーソナルデータのデータ価格「２６０，２８０，２９０，・・・」が含まれ得る。
【００８３】
本実施形態では、リクエスト情報で指定されたパーソナルデータの件数よりも多くの件数のパーソナルデータの情報がメタデータに含まれることが想定される。より詳細には、メタデータに含まれる、或る対象条件に合致するパーソナルデータの情報の件数は、リクエスト情報において指定されたその対象条件に合致するパーソナルデータの件数よりも多いことが想定される。これは、リクエスト情報で指定された件数のパーソナルデータをメタデータを基に選択する際に、複数通りのパーソナルデータの選択の仕方（すなわち調達プラン）を検討し、複数通りの調達プランの中からデータ利用者２ａに適した調達プランを決定するためである。ただし、メタデータによりその属性が示されるパーソナルデータの件数はこれに限られず、当該パーソナルデータの件数は、例えば、リクエスト情報で指定されたパーソナルデータの件数と同数であってもよい。
【００８４】
＜Ｓ１０５＞
続いて、Ｓ１０５で、条件整理部３３５は、各情報銀行装置４〜６のデータ形式に合わされたメタデータから取引条件を整理する。具体的には、条件整理部３３５は、各情報銀行装置４〜６のカテゴリテーブルマスタを利用して、各情報銀行装置４〜６のデータ形式に合わされたメタデータを共通のデータ形式に合わせ、取引条件を整理する。
【００８５】
また、条件整理部３３５は、Ｓ１０４で受信された各情報銀行装置４〜６からのメタデータに基づき、図１０の破線で示すようなリスト（以下、メタデータリスト）を生成する。メタデータリストは、パーソナルデータのＩＤと、データソースと、分布集計軸により指定される属性と、データ価格と、が対応付けられたデータである。データソースは、そのデータがどの情報銀行からのデータであるかを識別する情報である。前述のとおり、本実施形態では、リクエスト情報で指定されたパーソナルデータの件数よりも多くの件数のデータを含むメタデータリストが生成される。なお、図１０のメタデータリストの「データソース」の列において、「第１」は第１の情報銀行４ａを意味し、「第２」は第２の情報銀行５ａを意味する。
【００８６】
＜Ｓ１０６＞
続いて、Ｓ１０６で、調達プラン決定部３３６は、Ｓ１０５で生成されたメタデータリストに基づいて、データ利用者２ａに適した調達プランを決定する。本実施形態では、調達プラン決定部３３６は、情報銀行装置４〜６が保有する個々のパーソナルデータのデータ価格と、データ利用者２ａが指定した予算額と、に基づき、調達プランを決定する。さらに、調達プラン決定部３３６は、メタデータにより示される、分布集計軸により指定された属性に着目したときのパーソナルデータの分布（以下、元データ分布）の再現性に基づき調達プランを決定する。つまり、調達プラン決定部３３６は、データ利用者２ａの予算額の範囲内で、調達プランにより調達されるパーソナルデータのデータ分布が元データ分布に近づくように調達プランを決定する。
【００８７】
以下、調達プランの決定の仕方を図１０を用いて具体的に説明する。図１０では、簡単のため、１００個のデータから成るメタデータリストを考える。この事例ではデータ利用者２ａからのリクエスト情報には１つの対象条件のみが含まれているとする。例えば、図５の対象条件１の「パーソナルデータに係る個人の性別が男性であり、レシピサイトの直近３ヶ月間の閲覧回数が３回以上である」との対象条件のみがリクエスト情報に含まれているとする。図１０の１００個のデータはこの対象条件に合致するデータである。そして、データ利用者２ａが欲するこの対象条件に合致するパーソナルデータの件数は４０件であるとする。つまり、前記１００個のデータの中から４０個のデータを選択する。また、データ利用者２ａの予算額は１１０００円であるとする。
【００８８】
データ価格の総額が最も安い調達プランは、データ価格でデータを昇順でソートし、１番目から４０番目までのデータを購入するプランＡである。なお、図１０では、調達プランにおいて購入されるデータには「１」のフラグが立ち、購入されないデータには「０」のフラグが立つ。プランＡの購入データ価格の総額は１０５７０円である。しかしながら、例えば未婚及び未既の比は、元の１００個のデータ（以下、元データ）では５９：４１（≒３：２）であるのに対してプランＡでは１２：２８（≒１：２．５）であり、元データの分布とズレている。なお、図１０では、未婚に対応する値は「０」であり、既婚に対応する値は「１」である。すると、実際に調達して得られるパーソナルデータの他の項目についても元データの分布を再現しない懸念がある。そこで、購入されるデータの内訳が異なる他のパターン（例えば図１０のプランＢやプランＣ等）も検討し、プランＡと同様にデータ価格の総額と元データの分布である元データ分布からのズレとを評価する。なお、元データ分布とのズレは、例えばKL（Kullback-Leibler)-divergence（カルバック・ライブラー情報量）等の指標値を用いて評価することができる。図１０に示す例では元データ分布とのズレが最も小さい調達プランはプランＣであるが、データ価格の総額が１２４２０円で予算オーバーである。よって、予算額の範囲内で元データ分布とのズレが最小であるプランＢが調達プランとして決定採用される。このように、複数の調達プランの中から予算額の範囲内で元データ分布とのズレが最小のプランを調達プランとして決定するのが本実施形態の調達プランの決定ロジックである。なお、上記ではリクエスト情報に１つの対象条件のみが含まれている場合を例示して説明したが、リクエスト情報に複数の対象条件が含まれている場合も同様である。なお、リクエスト情報に複数の対象条件が含まれている場合には、リクエスト情報で指定された各対象条件の件数を変えないように調達されるデータを変更して、複数のプランを検討する。
【００８９】
＜Ｓ１０７＞
続いて、Ｓ１０７で、データ要求生成部３３７は、調達プラン決定部３３６により決定された調達プランに従い、パーソナルデータを要求するデータ要求を生成する。データ要求生成部３３７は、各情報銀行装置４〜６の取扱い可能なデータ形式に合うように情報銀行装置４〜６ごとにデータ要求を生成する。
【００９０】
図１１には第１情報銀行４ａに対するデータ要求の例が示される。図１２には第２情報銀行５ａに対するデータ要求の例が示される。これらのデータ要求はいずれも同じ項目を含む。
【００９１】
具体的には、データ要求は、タイムスタンプ、トランザクションＩＤ、文タイプ、参照トランザクションＩＤ、宛先、送信元及び文内容が含まれる。参照トランザクションＩＤは、当該データ要求に関連するメタデータ、換言すれば、当該データ要求の送信先の情報銀行装置から受信されたメタデータのトランザクションＩＤである。
【００９２】
文内容には、各対象条件に対応した対象者情報が含まれる。対象者情報には、条件文、件数、支払額及び購入データの情報が含まれる。
【００９３】
条件文は、対応する対象条件を表す。件数及び支払額は、対応する対象条件について当該データ要求の送信先の情報銀行装置から調達するパーソナルデータの件数及び支払額を表す。
【００９４】
購入データは、当該データ要求の送信先の情報銀行装置から調達するパーソナルデータを特定する。具体的には、購入データは、集計分布軸により指定された各属性とデータ価格とにより調達するパーソナルデータを指定する。
【００９５】
また、文内容には、データ利用者２ａが納品を希望する、パーソナルデータの項目である要求項目が含まれる。
【００９６】
データ要求生成部３３７は、各情報銀行装置４〜６の取扱い可能なデータ形式に合うように各情報銀行装置４〜６のカテゴリコードマスタを用いて情報銀行装置４〜６ごとにデータ要求を生成する。
【００９７】
＜Ｓ１０８＞
続いて、Ｓ１０８で、データ要求送信部３３８は、Ｓ１０７で生成されたデータ要求を情報銀行装置４〜６に通信部３１を介して送信する。
【００９８】
＜Ｓ１０９＞
続いて、Ｓ１０９で、データ受信部３３９は、データ要求を受信した情報銀行装置４〜６から、図１３に示すような、データ要求にて指定されたパーソナルデータを含む納品データを受信する。
【００９９】
具体的には、納品データは、タイムスタンプ、トランザクションＩＤ、文タイプ、参照トランザクションＩＤ、宛先、送信元及び文内容が含まれる。参照トランザクションＩＤは、当該納品データに関連するデータ要求、換言すれば、当該納品データの送信先の情報銀行装置に送信されたデータ要求のトランザクションＩＤである。
【０１００】
文内容には、各対象条件に対応した対象者情報が含まれる。対象者情報には、条件文、件数及びデータ本体の情報が含まれる。条件文及び件数は、データ要求に含まれるものと同じである。データ本体は、データ要求に含まれる購入データで指定されたパーソナルデータである。データ本体には、パーソナルデータの項目のうち要求項目により指定された項目が含まれる。また、文内容には、要求項目の情報が含まれる。
【０１０１】
＜Ｓ１１０＞
続いて、Ｓ１１０で、形式処理部３４０は、複数の情報銀行装置４〜６から受信された納品データのデータ形式を揃える。具体的には、形式処理部３４０は、各情報銀行装置４〜６から受信された納品データのデータ形式を共通のデータ形式に変換する。そして、形式処理部３４０は、共通のデータ形式に変換された各情報銀行装置４〜６からの納品データを１つのデータに統合する。以下、具体的に説明する。
【０１０２】
まず、各情報銀行装置４〜６からの納品データのデータ形式を共通のデータ形式に変換するに当たり、形式処理部３４０は、図１４に示すような標準辞書を使用する。標準辞書は、記憶部３２に記憶されている。標準辞書は、パーソナルデータに含まれ得る各項目について仲介装置３における規定の意味、変数名及び値が互いに対応付けられて設定されたデータである。以下、規定の変数名及び値をそれぞれ「標準変数名」及び「標準値」という。この標準辞書を用いて形式処理部３４０は、まず各情報銀行装置４〜６のデータ変換用辞書を作成する。データ変換用辞書は、各情報銀行装置４〜６の納品データの変数名及び値を、標準辞書に規定された標準変数名及び標準値に変換するためのデータである。
【０１０３】
データ変換用辞書を作成するに際し、形式処理部３４０は、その情報銀行の図８Ａや図８Ｂに示すカテゴリテーブルマスタと図１４に示す標準辞書とを「意味」の項目で突き合わせる。なお、この突き合わせ（すなわちマッチング）を行うに当たり、例えば双方のデータの「意味」の項目内のテキストを単純にマッチングされてもよく、またその他の方法でマッチングさせてもよい。
【０１０４】
カテゴリテーブルマスタと標準辞書とを「意味」の項目で突き合わせると、カテゴリテーブルマスタに含まれる「変数名」及び「値」と、標準辞書に含まれる「標準変数名」及び「標準値」と、そして「意味」と、が対応付けられた図１５に示すようなデータ変換辞書が生成される。なお、データ変換辞書は、各情報銀行装置４〜６からの納品データのデータ形式を共通のデータ形式に変換する際に生成されてもよく、あらかじめ生成されて記憶部３２に記憶されていてもよい。
【０１０５】
そして、形式処理部３４０は、情報銀行装置から送信された納品データの変数及び値を、その情報銀行装置のデータ変換辞書を使用して標準変数及び標準値に変換する。これにより、各情報銀行装置４〜６から受信された納品データのデータ形式が共通のデータ形式に変換される。
【０１０６】
例えば、図１５に示す第１情報銀行装置４のデータ変換用辞書を使用して、図１６Ａに示す第１情報銀行装置４からの納品データは、図１７に示す変換後の納品データに変換される。同様に、図示省略する第２情報銀行装置５のデータ変換用辞書を使用して、図１６Ｂに示す第２情報銀行５ａからの納品データは、図１８に示す変換後の納品データに変換される。
【０１０７】
そして、形式処理部３４０は、各情報銀行装置４〜６の変換後の納品データを１つのデータに統合し、図１９に示すような統合データを生成する。なお、形式処理部３４０は、統合データを生成するに際し、各パーソナルデータのＩＤを振り直し、各情報銀行装置４〜６の納品データを順次積み上げる。また、統合データでは、或る情報銀行装置からのパーソナルデータと別の情報銀行装置からのパーソナルデータとが互いに区別可能になっている。例えば、図１９に示す統合データでは、第１情報銀行４ａからのパーソナルデータのＩＤには「ｂ」が付され、第２情報銀行５ａからのパーソナルデータには「ａ」が付されている。
【０１０８】
形式処理部３４０はこのようにして複数の情報銀行装置４〜６からの納品データのデータ形式を揃え、１つのデータに統合する。
【０１０９】
＜Ｓ１１１＞
続いて、Ｓ１１１で、データ送信部３４１は、形式処理部３４０により生成された統合データをデータ利用者２ａに送信する。
【０１１０】
制御部３３は、Ｓ１１１を実行すると、図４のデータ調達処理を終了する。
【０１１１】
［１−４．効果］
以上詳述した第１実施形態によれば、以下の効果が得られる。
【０１１２】
（１ａ）本実施形態では、調達プラン決定部３３６は、情報銀行装置４〜６から受信されたメタデータに基づいて、データ利用者２ａに適した調達プランを決定する。そして、データ要求送信部３３８は、決定された調達プランに従いデータ要求を情報銀行装置４〜６に送信し、データ受信部３３９は情報銀行装置４〜６からパーソナルデータを受信する。そして、データ送信部３４１は、受信されたパーソナルデータをデータ利用者２ａに送信する。
【０１１３】
よって、情報銀行装置４〜６が保有しているパーソナルデータを把握しづらい中でデータ利用者２ａが直接情報銀行装置４〜６に問い合わせてパーソナルデータを調達する場合と比較して、パーソナルデータの調達をより容易に行うことができ、かつ、データ利用者２ａが行う通信の通信量を低減できる。
【０１１４】
（１ｂ）本実施形態では、仲介装置３は、情報銀行４ａ〜６ａが保有する情報銀行装置４〜６からメタデータを取得する。
【０１１５】
ここで、仲介装置３が、メタデータを自身の記憶部３２に記憶し、記憶部３２に記憶されたメタデータを定期的に更新し、記憶部３２からメタデータを取得する構成が考えられる。しかし、このような構成では、記憶部３２から取得されたメタデータが最新のメタデータに更新されておらず、調達プラン決定部３３６が古いメタデータに基づいて調達プランを決定する場合がある。これに対し、本実施形態の構成によれば、仲介装置３は情報銀行装置４〜６からメタデータを取得するため、最新の内容のメタデータに基づき調達プランを決定することができる。
【０１１６】
（１ｃ）本実施形態では、調達プラン決定部３３６は、情報銀行４ａ〜６ａが管理するパーソナルデータのうち対象条件に合致するパーソナルデータの属性を示す情報であるメタデータに基づいて、調達プランを決定する。
【０１１７】
したがって、仲介装置３は、情報銀行４ａ〜６ａが管理するパーソナルデータのうち対象条件に合致するパーソナルデータの属性を踏まえて調達プランを決定することができる。
【０１１８】
（１ｄ）本実施形態では、メタデータ要求送信部３３３は、リクエスト受信部３３１がリクエスト情報を取得した場合にメタデータ要求を情報銀行装置４〜６に送信する。そして、メタデータ受信部３３４は、情報銀行装置４〜６からメタデータを受信する。
【０１１９】
よって、仲介装置３は、利用者装置２からリクエスト情報を取得した場合に、情報銀行装置４〜６に問合せを行い、最新のメタデータを取得する。したがって、最新のメタデータに基づき調達プランを決定することができる。
【０１２０】
（１ｅ）本実施形態では、調達プラン決定部３３６は、情報銀行装置４〜６が保有する個々のパーソナルデータの価格と、リクエスト情報に含まれる予算額と、に基づき、調達プランを決定する。したがって、データ利用者２ａの予算額に応じて適切な調達プランを決定できる。
【０１２１】
（１ｆ）本実施形態では、調達プラン決定部３３６は、調達プランにより調達されるパーソナルデータの属性に基づく分布が、メタデータにより示される元データ分布に近づくように調達プランを決定する。
【０１２２】
例えば、元データ分布を無視してパーソナルデータの調達プランを決定した場合、元データ分布に対して偏った分布でパーソナルデータが調達される可能性がある。その結果、パーソナルデータの要求項目に含まれる特定の項目についてデータ利用者２ａが集計等したときに元データの分布を再現せず、偏った結果が得られる場合がある。
【０１２３】
これに対して、本実施形態の構成によれば、元データ分布の再現性に基づき調達プランを決定するため、実際にパーソナルデータを調達した際にデータの偏りが発生することを抑制できる。
【０１２４】
特に、本実施形態では、データ利用者２ａの予算額の範囲内で、データの偏りが発生することを出来るだけ抑制することができる。
【０１２５】
（１ｇ）本実施形態では、調達プラン決定部３３６は、複数の情報銀行装置４〜６から受信されたメタデータに基づいて、複数の情報銀行装置４〜６が保有する対象条件に合致するパーソナルデータの中から実際に調達するパーソナルデータに関する条件を示す調達プランを決定する。データ受信部３３９は複数の情報銀行装置４〜６からパーソナルデータを受信し、データ送信部３４１は複数の情報銀行装置４〜６から受信されたパーソナルデータをデータ利用者２ａに送信する。
【０１２６】
よって、情報銀行装置４〜６が保有しているパーソナルデータを把握しづらい中でデータ利用者２ａが複数の直接情報銀行装置４〜６に問い合わせてパーソナルデータを調達する場合と比較して、複数の情報銀行装置４〜６からデータ利用者２ａに適したパーソナルデータをより容易に調達することができる。
【０１２７】
（１ｈ）本実施形態では、形式処理部３４０は、複数の情報銀行装置４〜６から受信されたパーソナルデータのデータ形式を共通のデータ形式に揃える。そして、データ送信部３４１は、形式処理部３４０によりデータ形式が合わせられた複数の情報銀行装置４〜６からのパーソナルデータを、利用者装置２に送信する。
【０１２８】
したがって、データ形式を共通のデータ形式に揃えることで、データ利用者２ａにとって取扱いしやすいデータ形式でパーソナルデータを納品することができる。
【０１２９】
なお、本実施形態では、情報銀行４ａ〜６ａがパーソナルデータ管理者に相当し、情報銀行装置４〜６が管理者装置に相当し、メタデータが属性情報に相当し、メタデータ要求が属性情報要求に相当し、Ｓ１０１がリクエスト取得部としての処理に相当し、Ｓ１０３が属性要求送信部としての処理に相当し、Ｓ１０４が属性情報取得部としての処理に相当し、Ｓ１０６が調達プラン決定部としての処理に相当し、Ｓ１０９がパーソナルデータ取得部としての処理に相当し、Ｓ１１０が形式処理部としての処理に相当し、Ｓ１１１がデータ送信部としての処理に相当する。
【０１３０】
［２．第２実施形態］
［２−１．第１実施形態との相違点］
第２実施形態は、基本的な構成は第１実施形態と同様であるため、共通する構成については説明を省略し、相違点を中心に説明する。なお、第１実施形態と同じ符号は、同一の構成を示すものであって、先行する説明を参照する。
【０１３１】
前述した第１実施形態では、仲介装置３は、利用者装置２からリクエスト情報を受信するとメタデータ要求を情報銀行装置４〜６に送信し、情報銀行装置４〜６からメタデータを受信する。
【０１３２】
これに対し、第２実施形態では、図２及び図２０に示す仲介装置７は、任意の対象条件に対応するメタデータを含むメタデータのセット（以下、メタデータセット）を記憶した記憶部７２を備える。そして、仲介装置７は、データ利用者２ａからリクエスト情報を受信すると、情報銀行装置４〜６からメタデータを取得するのではなく自身が備える記憶部７２からメタデータを取得する点で、第１実施形態と相違する。以下、第２実施形態について詳細に説明する。
【０１３３】
第２実施形態の仲介装置７は、図２に示すように、通信部７１と、記憶部７２と、制御部７３と、を備える。これらの構成７１〜７３のハードウェア構成は、第１実施形態の仲介装置３の各構成３１〜３３と同一である。ただし、記憶部７２に記憶されているデータが第１実施形態と異なる。具体的には、記憶部７２には、各情報銀行４ａ〜６ａに関するメタデータセットが記憶されている。
【０１３４】
メタデータセットは、リクエスト情報に含まれ得る任意の対象条件に対し、その対象条件に対応するメタデータを取得できるようなデータセットである。換言すれば、メタデータセットは、リクエスト情報に含まれ得る任意の対象条件に対し、その対象条件に対応するメタデータに含まれる要求項目統計量やデータ価格分布等の各情報を取得できるようなデータセットである。記憶部７２には、仲介装置７がパーソナルデータを請求し得る全ての情報銀行４ａ〜６ａに関するメタデータを含むメタデータセットが記憶されている。
【０１３５】
具体的には例えば、メタデータセットは、仲介装置７がパーソナルデータを請求し得る全ての情報銀行が保有するパーソナルデータの年齢、性別、未既婚、雑誌購読有無等の各属性に関する統計量や最大値、最小値等の情報を含む。また、メタデータセットは、仲介装置７がパーソナルデータを請求し得る全ての情報銀行４ａ〜６ａについて、任意の対象条件（すなわちパーソナルデータの属性の任意の組合せ）に該当するパーソナルデータの件数の情報を含む。また、或る情報銀行のメタデータセットは、任意の対象条件について、その対象条件に該当するパーソナルデータのデータ価格分布の情報を含む。記憶部７２には、このようなメタデータセットが記憶されている。
【０１３６】
本実施形態では、記憶部７２に記憶されているメタデータセットは、所定頻度（例えば１ヶ月に１度や１週間に１度）で定期的に更新されることが想定される。なお、データセットの更新は種々の方法で行われ得るが、例えば次のようにして行われてもよい。すなわち、仲介装置７の保有者が各情報銀行４ａ〜６ａからメタデータセットを記憶した記憶媒体を受領し、受領された記憶媒体内のメタデータセットを記憶部７２に記憶することでメタデータセットの更新が行われてもよい。
【０１３７】
一方、制御部７３は、ＣＰＵ７３ａがプログラムを実行することで後述する図２１に示すデータ調達処理を実行する。制御部７３はデータ調達処理を実行することで、図２０に示すように、リクエスト取得部３３１、メタデータ取得部７３１、更新処理部７３２、調達プラン決定部３３６、データ要求生成部３３７、データ要求送信部３３８、データ受信部３３９、形式処理部３４０及びデータ送信部３４１として機能する。つまり、第１実施形態の要求生成部３３２、メタデータ要求送信部３３３、メタデータ受信部３３４及び条件整理部３３５に代えてメタデータ取得部７３１及び更新処理部７３２として機能する点で、第２実施形態の制御部７３は、第１実施形態の制御部３３と相違する。
＜メタデータ取得部＞
メタデータ取得部７３１は、リクエスト取得部３３１により受信されたリクエスト情報に基づき、記憶部７２からメタデータを取得する。具体的には、メタデータ取得部７３１は、リクエスト情報に応じた、各情報銀行４ａ〜６ａに関するメタデータを、メタデータセットから取得する。
＜更新処理部＞
更新処理部７３２は、記憶部７２に記憶されたメタデータセットを更新する。
【０１３８】
［２−２．処理］
次に、第２実施形態の仲介装置７の制御部７３が、第１実施形態のデータ調達処理（図４）に代えて実行するデータ調達処理について、図２１のフローチャートを用いて説明する。なお、図２１のフローチャートにおいて、Ｓ２０１，Ｓ２０３〜Ｓ２０８の処理（すなわちＳ２０２及びＳ２０９以外の処理）は、前述した図４のＳ１０１，Ｓ１０６〜Ｓ１１１とそれぞれ同様である。よって、以下では、これらの処理の説明を省略し、相異点であるＳ２０２及びＳ２０９のみ説明する。
＜Ｓ２０２＞
Ｓ２０２で、メタデータ取得部７３１は、Ｓ２０１で取得されたリクエスト情報と、記憶部７２に記憶されているメタデータセットと、に基づき、メタデータを取得する。
＜Ｓ２０９＞
Ｓ２０９で、更新処理部７３２は、記憶部７２に記憶されたメタデータセットを更新する。例えば、更新処理部７３２は、統合データに含まれるパーソナルデータの属性の統計情報やデータ価格分布等の情報が記憶部７２に記憶されているメタデータセットの情報と異なる場合、メタデータセットの情報を納品データに含まれる情報に更新する。
【０１３９】
［２−３．効果］
以上詳述した第２実施形態によれば、前述した第１実施形態の効果（１ｃ），（１ｅ）〜（１ｈ）に加え、以下の効果が得られる。
【０１４０】
（２ａ）本実施形態では、調達プラン決定部３３６は、記憶部７２から取得されたメタデータに基づいて、データ利用者２ａに適した調達プランを決定する。そして、データ要求送信部３３８は、決定された調達プランに従い情報銀行装置４〜６からパーソナルデータを受信する。そして、データ送信部３４１は、受信されたパーソナルデータをデータ利用者２ａに送信する。
【０１４１】
よって、データ利用者２ａが、情報銀行装置４〜６が保有しているパーソナルデータを把握しづらい中で直接情報銀行装置４〜６に問い合わせてパーソナルデータを調達する場合と比較して、データ利用者２ａに適したパーソナルデータの調達をより容易に行うことができる。
【０１４２】
特に、メタデータ取得部７３１は、記憶部７２からメタデータを取得する。つまり、仲介装置７は、情報銀行４ａ〜６ａとの間でデータのやり取りを行わなくてもメタデータを取得できる。したがって、情報銀行４ａ〜６ａにメタデータ要求を送信してメタデータを取得する構成と比較して、仲介装置７の通信量を減らすことができる。また、メタデータ要求及びメタデータの送受信を行うためのＡＰＩ（Application Programming Interface）等のシステム開発費を抑えることができる。
【０１４３】
なお、本実施形態では、メタデータが属性情報に相当し、Ｓ２０１がリクエスト取得部としての処理に相当し、Ｓ２０２が属性情報取得部としての処理に相当し、Ｓ２０３が調達プラン決定部としての処理に相当し、Ｓ２０６がパーソナルデータ取得部としての処理に相当し、Ｓ２０７が形式処理部としての処理に相当し、Ｓ２０８がデータ送信部としての処理に相当し、Ｓ２０９が更新処理部としての処理に相当する。
【０１４４】
［３．第３実施形態］
［３−１．第１実施形態との相違点］
第３実施形態は、基本的な構成は第１実施形態と同様であるため、共通する構成については説明を省略し、相違点を中心に説明する。なお、第１実施形態と同じ符号は、同一の構成を示すものであって、先行する説明を参照する。
【０１４５】
前述した第１実施形態では、仲介装置３は複数の情報銀行４ａ〜６ａからパーソナルデータを取得する。ここで、同一個人が複数の情報銀行４ａ〜６ａにパーソナルデータを預託する状況は十分に考えられる。そして、情報銀行４ａ〜６ａやデータ利用者２ａは、情報銀行４ａ〜６ａに預託されているどのパーソナルデータが同一人物に由来するかを知ることはできない。このため、データ利用者２ａが複数の情報銀行４ａ〜６ａにパーソナルデータを要求する場合、同一人物の同一パーソナルデータを異なる情報銀行４ａ〜６ａから購入してしまう場合がある。つまり、パーソナルデータの二重購入が発生する場合がある。
【０１４６】
第３実施形態は、上記のパーソナルデータの二重購入抑制という課題を次のようにして解決する。すなわち、第３実施形態では、図２２に示すように、どの個人がどの情報銀行にパーソナルデータを預託しているかを把握している者（以下、登録管理者９ａ）が存在することが仮定される。そして、第３実施形態の仲介装置８は、この登録管理者９ａが保有する装置である管理者装置９に問い合わせを行うことで、複数の情報銀行４ａ〜６ａにパーソナルデータを預託した個人を検出する。そして、仲介装置８は、二重購入にならない調達プランを決定する。以下、第３実施形態の構成を詳細に説明する。
【０１４７】
図２３に示すように、登録管理者９ａの管理者装置９は、通信部９１と、記憶部９２と、制御部９３と、を備える。
【０１４８】
通信部９１は、管理者装置９をネットワークに接続するための通信インタフェースである。管理者装置９は、通信部９１を介して、仲介装置８と有線又は無線にてデータ通信可能である。また、管理者装置９は、通信部９１を介してインターネットに接続し、インターネットを介して外部の装置とデータ通信可能であってもよい。
【０１４９】
記憶部９２は、各種データを記憶する。本実施形態では、記憶部９２には、図２４に示すような重複管理テーブルが記憶されている。重複管理テーブルは、情報銀行ＩＤと、情報銀行登録者ＩＤと、個人ＩＤと、が対応付けられて設定された情報である。
【０１５０】
情報銀行ＩＤは、各情報銀行を識別するためのＩＤである。情報銀行ＩＤは、登録管理者９ａが各情報銀行に対して付与してもよい。本実施形態では、第１の情報銀行４ａ、第２の情報銀行５ａ及び第３の情報銀行６ａの情報銀行ＩＤは、それぞれ、「００００１」、「００００２」及び「００００３」である。
【０１５１】
情報銀行登録者ＩＤは、各情報銀行４ａ〜６ａが、当該情報銀行４ａ〜６ａにパーソナルデータを預託した個人、すなわち登録者に対して付与するＩＤである。情報銀行登録者ＩＤは、各情報銀行４ａ〜６ａ内でユニークなＩＤである。なお、各情報銀行４ａ〜６ａは、パーソナルデータを預託した個人の情報銀行登録者ＩＤと、その個人が預託したパーソナルデータと、を一対一対応で対応付けて記憶する。そのため、情報銀行登録者ＩＤは、情報銀行にパーソナルデータを預託した個人のパーソナルデータに対して付与されたＩＤとも考えられる。
【０１５２】
個人ＩＤは、個人と一対一対応するＩＤであり、例えば、登録管理者９ａによって個人に対して付与される。具体的には例えば、登録管理者９ａが各情報銀行４ａ〜６ａに対して、個人ＩＤを生成するためのツールを貸与する。そして、各情報銀行４ａ〜６ａ側で、貸与された前記ツールを使用して個人ＩＤが生成されてもよい。例えば、個人ＩＤは、個人がデータを情報銀行４ａ〜６ａに登録する際の本人確認情報からハッシュ関数等で生成されたＩＤでもよい。具体的には例えば、ｈａｓｈ（ｓｕｒｎａｍｅ＿ｆｉｒｓｔｎａｍｅ＿ｓｅｘ＿ｂｉｒｔｈｄａｙ）などのハッシュ値が個人ＩＤとして使用されてもよい。ここで、ｈａｓｈはハッシュ関数であり、ｓｕｒｎａｍｅ、ｆｉｒｓｔｎａｍｅ、ｓｅｘ及びｂｉｒｔｈｄａｙには、データを預託する個人の姓、名、性別及び生年月日が入力される。
【０１５３】
この重複管理テーブルにおいて、個人ＩＤの同一のパーソナルデータは同一人物のパーソナルデータであると判断できる。
【０１５４】
一方、制御部９３は、ＣＰＵ９３ａと、ＲＡＭ、ＲＯＭ、フラッシュメモリ等の半導体メモリ（以下、メモリ９３ｂ）と、を有する周知のマイクロコンピュータを中心に構成される。
【０１５５】
一方、第３実施形態の仲介装置８は、図２に示すように、通信部８１と、記憶部８２と、制御部８３と、を備える。これらの構成８１〜８３のハードウェア構成は、第１実施形態の仲介装置３の各構成３１〜３３と同一である。ただし、制御部８３が実行する処理が第１実施形態と一部相違する。
【０１５６】
具体的には、制御部８３は、ＣＰＵ８３ａがメモリ８３ｂに記憶されているプログラムを実行することで後述する図２６に示すデータ調達処理を実行する。制御部８３はデータ調達処理を実行することで、図２５に示すように、リクエスト取得部３３１、ＩＤ要求生成部８３１、ＩＤ要求送信部８３２、ＩＤ受信部８３３、重複確認生成部８３４、重複確認送信部８３５、重複確認受信部８３６、メタデータ要求生成部３３２、メタデータ要求送信部３３３、メタデータ受信部３３４、条件整理部３３５、調達プラン決定部３３６、データ要求生成部３３７、データ要求送信部３３８、データ受信部３３９、形式処理部３４０及びデータ送信部３４１として機能する。つまり、第３実施形態の制御部８３は、ＩＤ要求生成部８３１、ＩＤ要求送信部８３２、ＩＤ受信部８３３、重複確認生成部８３４、重複確認送信部８３５及び重複確認受信部８３６として更に機能する点で、第１実施形態の制御部３３と相違する。以下では、相異点に係る各要素８３２〜８３６等の機能の概要について説明する。その後、図２６のフローチャートを用いて各要素８３２〜８３６等の機能を詳細に説明する。
＜ＩＤ要求生成部＞
ＩＤ要求生成部８３１は、リクエスト取得部３３１により受信された、対象条件を含むリクエスト情報に基づき、情報銀行装置４〜６に送信されるＩＤ要求を生成する。ここでいうＩＤ要求とは、対象条件に合致するパーソナルデータに係る情報銀行登録者ＩＤを要求するための情報である。本実施形態では、ＩＤ要求生成部８３１は、各情報銀行装置４〜６の取扱い可能なデータ形式に合わせて情報銀行装置４〜６ごとにＩＤ要求を生成する。ＩＤ要求の具体例については後述する。
＜ＩＤ要求送信部＞
ＩＤ要求送信部８３２は、ＩＤ要求生成部８３１により生成されたＩＤ要求を複数の情報銀行装置４〜６に通信部８１を介して送信する。ＩＤ要求を受信した情報銀行装置４〜６は、ＩＤ要求に対する応答として、ＩＤ結果情報を仲介装置３に送信する。ここでいうＩＤ結果情報とは、対象条件に合致するパーソナルデータの情報銀行登録者ＩＤを示す情報である。本実施形態でいうＩＤ結果情報には、対象条件に合致するパーソナルデータの価格情報も含まれる。
＜ＩＤ受信部＞
ＩＤ受信部８３３は、複数の情報銀行装置４〜６からＩＤ結果情報を通信部８１を介して受信する。ＩＤ結果情報の具体例については後述する。
＜重複確認生成部＞
重複確認生成部８３４は、複数の情報銀行装置４〜６から受信されたＩＤ結果情報に基づき、管理者装置９に送信される重複確認要求を生成する。ここでいう重複確認要求とは、ＩＤ結果情報に含まれる複数の情報銀行登録者ＩＤが示す複数のパーソナルデータの中に同一個人に係るパーソナルデータがあるか否かの確認を要求するための情報である。重複確認要求の具体例については後述する。
＜重複確認送信部＞
重複確認送信部８３５は、重複確認生成部８３４により生成された重複確認要求を管理者装置９に通信部８１を介して送信する。重複確認要求を受信した管理者装置９は、重複確認要求に対する応答として、重複確認の結果を示す重複結果情報を仲介装置８に送信する。
＜重複確認受信部＞
重複確認受信部８３６は、管理者装置９から重複結果情報を通信部８１を介して受信する。重複結果情報の具体例については後述する。
＜メタデータ要求生成部＞
メタデータ要求生成部３３２は、重複確認受信部８３６により受信された重複結果情報とリクエスト取得部３３１により受信されたリクエスト情報とに基づき、情報銀行装置４〜６に送信されるメタデータ要求を生成する。本実施形態では、メタデータ要求生成部３３２は、同一人物のパーソナルデータを複数の情報銀行が管理している場合に、前記同一人物のデータを前記複数の情報銀行のうちの１つから要求するメタデータ要求を生成する。
【０１５７】
メタデータ要求送信部３３３以降の各要素３３３〜３４１は、基本的には第１実施形態と同様であるため、説明を省略する。
【０１５８】
［３−２．処理］
次に、第３実施形態の仲介装置８の制御部８３が、第１実施形態のデータ調達処理（図４）に代えて実行するデータ調達処理について、図２６のフローチャートを用いて説明する。
【０１５９】
＜Ｓ３０１＞
Ｓ３０１は、前述した図４のＳ１０１と同様であるため、説明を省略する。
【０１６０】
＜Ｓ３０２＞
続いて、Ｓ３０２で、ＩＤ要求生成部８３１は、リクエスト取得部３３１により受信された、対象条件を含むリクエスト情報に基づき、情報銀行装置４〜６に送信されるＩＤ要求を生成する。
【０１６１】
ここで、ＩＤ要求は、図２７に示す各項目を含む。図２７には、第１の情報銀行４ａに対するＩＤ要求の例が示されている。ＩＤ要求は、前述した図６に示すメタデータ要求と同じ項目を含む。換言すれば、ＩＤ要求は、文タイプが「ＩＤ要求」であること以外は基本的にはメタデータ要求と同内容である。特に、ＩＤ要求は、リクエスト情報に含まれる対象条件の情報を含む。
【０１６２】
本実施形態では、情報銀行装置４〜６ごとに取扱い可能なデータ形式が異なる。そのため、ＩＤ要求は、送信先の情報銀行装置４〜６の取扱い可能なデータ形式に合わせて情報銀行装置４〜６ごとに生成される。
【０１６３】
＜Ｓ３０３＞
続いて、Ｓ３０３で、ＩＤ要求送信部８３２は、ＩＤ要求生成部８３１により生成されたＩＤ要求を複数の情報銀行装置４〜６に通信部８１を介して送信する。ＩＤ要求を受信した情報銀行装置４〜６は、ＩＤ要求に対する応答として、ＩＤ結果情報を仲介装置３に送信する。
【０１６４】
＜Ｓ３０４＞
ＩＤ受信部８３３は、複数の情報銀行装置４〜６からＩＤ結果情報を通信部８１を介して受信する。ＩＤ結果情報は、各情報銀行装置４〜６の取扱い可能なデータ形式で記述されている。
【０１６５】
本実施形態のＩＤ結果情報は、図２８に示す各項目を含む。図２８には、第１の情報銀行４ａから受信されたＩＤ結果情報が示される。
【０１６６】
ＩＤ結果情報には、タイムスタンプ、トランザクションＩＤ、文タイプ、参照トランザクションＩＤ、宛先、送信元及び文内容が含まれる。参照トランザクションＩＤは、当該ＩＤ結果情報に関連するＩＤ要求、換言すれば、当該ＩＤ結果情報の送信元の情報銀行装置が受信したＩＤ要求のトランザクションＩＤである。
【０１６７】
文内容には、ＩＤ要求により示される対象条件に合致するパーソナルデータの情報銀行登録者ＩＤと価格との組のリストが含まれる。例えば、図２８に示す例において、文内容に含まれる｛１３４３４８２，２１５｝の組は、第１の情報銀行４ａが保有するパーソナルデータのうち対象条件に合致する或るパーソナルデータの情報銀行登録者ＩＤが１３４３４８２であり、価格が２１５円であることを意味する。仲介装置８は、図２８に示すようなＩＤ結果情報を各情報銀行４ａ〜６ａから受信する。
【０１６８】
＜Ｓ３０５＞
続いて、Ｓ３０５で、重複確認生成部８３４は、複数の情報銀行装置４〜６から受信されたＩＤ結果情報に基づき、管理者装置９に送信される重複確認要求を生成する。
【０１６９】
本実施形態の重複確認要求は、図２９に示すように、タイムスタンプ、トランザクションＩＤ、文タイプ、参照トランザクションＩＤ、宛先、送信元及び文内容の各項目を含む。
【０１７０】
文内容には、各情報銀行４ａ〜６ａから受信した情報銀行登録者ＩＤのリストと、各情報銀行の識別子（図２９中、「文内容」内の「第１の情報銀行」、「第２の情報銀行」等）と、が含まれる。
【０１７１】
＜Ｓ３０６＞
続いて、Ｓ３０６で、重複確認送信部８３５は、重複確認生成部８３４により生成された重複確認要求を管理者装置９に通信部８１を介して送信する。重複確認要求を受信した管理者装置９は、重複確認要求に対する応答として、重複結果情報を仲介装置８に送信する。
【０１７２】
＜Ｓ３０７＞
重複確認受信部８３６は、管理者装置９から重複結果情報を通信部８１を介して受信する。
【０１７３】
本実施形態の重複結果情報は、図３０に示すように、タイムスタンプ、トランザクションＩＤ、文タイプ、参照トランザクションＩＤ、宛先、送信元及び文内容の各項目を含む。
【０１７４】
文内容には、同一人物のそれぞれの情報銀行４ａ〜６ａにおける情報銀行登録者ＩＤの組が含まれる。
【０１７５】
例えば、図３０に示す例において、文内容に含まれる（０９００８３８，９８８８１００，４３０９８１２１３）の組は、第１の情報銀行４ａの情報銀行登録者ＩＤ「０９００８３８」と、第３の情報銀行６ａの情報銀行登録者ＩＤ「９８８８１００」と、第３の情報銀行６ａの情報銀行登録者ＩＤ「４３０９８１２１３」と、が同一人物のＩＤであることを意味する。
【０１７６】
なお、管理者装置９は、仲介装置８から重複確認要求を受信した場合に、次のように重複結果情報を生成する。すなわち、管理者装置９は、図２４に示す重複管理テーブルを参照する。そして、管理者装置９は、重複確認要求に含まれる情報銀行登録者ＩＤのリスト内で同一の個人ＩＤに対応する情報銀行登録者ＩＤが複数存在するか否かを確認する。そして、管理者装置９は、同一の個人ＩＤに対応する情報銀行登録者ＩＤが複数存在する場合、その複数の情報銀行登録者ＩＤを組にしてまとめる。これにより、重複結果情報の文内容に含まれる、情報銀行登録者ＩＤの組が生成される。管理者装置９はこのようにして重複結果情報を生成する。なお、図２４では、符号９ａで示される情報銀行登録者ＩＤは、同一の個人ＩＤに対応する。また、符号９ｂで示される情報銀行登録者ＩＤも、同一の個人ＩＤに対応する。
【０１７７】
＜Ｓ３０８＞
メタデータ要求生成部３３２は、重複確認受信部８３６により受信された重複結果情報とリクエスト取得部３３１により受信されたリクエスト情報とに基づき、情報銀行装置４〜６に送信されるメタデータ要求を生成する。
【０１７８】
ここで、メタデータ要求生成部３３２は、複数の情報銀行の情報銀行登録者ＩＤが同一の個人ＩＤに対応する場合、前記複数の情報銀行のうちの１つの情報銀行を特定する。そして、メタデータ要求生成部３３２は、特定された情報銀行以外に対しては、前記同一の個人ＩＤに対応する情報銀行登録者ＩＤを除外してメタデータを送信するようにメタデータ要求を生成する。
【０１７９】
具体的には、本実施形態では、メタデータ要求生成部３３２は、Ｓ３０７で受信された重複結果情報とＳ３０４で受信されたＩＤ結果情報に含まれる価格情報とを突き合わせる。そして、メタデータ要求生成部３３２は、或る個人のパーソナルデータを最も安く提供している情報銀行を特定し、特定された情報銀行以外からは、その個人のデータを除外してメタデータを送信するようメタデータ要求内の条件で規定する。
【０１８０】
なお、本実施形態では、同一人物のパーソナルデータであっても情報銀行によってデータの価格が異なることが想定される。これは、情報銀行によって情報銀行が取るマージンが異なることが想定されるためである。
【０１８１】
図３１に示すように、本実施形態のメタデータ要求は、前述した図６に示すメタデータ要求の各項目に加え、文内容に除外ＩＤの項目を更に含む。
【０１８２】
除外ＩＤは、情報銀行から送信されるメタデータに含めない（すなわち除外される）パーソナルデータの情報銀行登録者ＩＤを示す項目である。つまり、メタデータ要求を受信した情報銀行は、除外ＩＤで指定された情報銀行登録者ＩＤのデータを除外して仲介装置８にメタデータを送信する。これにより、特定の情報銀行以外の情報銀行からのメタデータからは、同一の個人ＩＤに対応する情報銀行登録者ＩＤのデータが除外される。
＜Ｓ３０９＞
Ｓ３０９は、前述した図４のＳ１０３と同様であるため、説明を省略する。
＜Ｓ３１０＞
続いて、Ｓ３１０で、メタデータ受信部３３４は、各情報銀行装置４〜６からメタデータを通信部８１を介して受信する。ここで、メタデータ受信部３３４は、複数の情報銀行４ａ〜６ａの情報銀行登録者ＩＤが或る同一の個人ＩＤに対応する場合、その個人のパーソナルデータを最も安く提供している情報銀行からその個人のデータを含むメタデータを受信する。そして、メタデータ受信部３３４は、その個人のパーソナルデータを最も安く提供している情報銀行以外の情報銀行からはその個人のデータが除外されたメタデータを受信する。その結果、メタデータ受信部３３４が、同一人物のデータを含むメタデータを複数の情報銀行から受信することが抑制される。
＜Ｓ３１１〜Ｓ３１７＞
Ｓ３１１〜Ｓ３１７は、前述した図４のＳ１０５〜Ｓ１１１と同様であるため、説明を省略する。
【０１８３】
［３−３．効果］
以上詳述した第３実施形態によれば、前述した第１実施形態の効果（１ａ）〜（１ｈ）に加え、以下の効果が得られる。
【０１８４】
（３ａ）本実施形態では、調達プラン決定部３３６は、重複結果情報に基づきメタデータ要求を生成し、メタデータ要求の応答として得られたメタデータに基づき、調達プランを決定する。つまり、調達プラン決定部３３６は、重複結果情報に基づき調達プランを決定する。
【０１８５】
このため、重複確認情報に基づき決定された調達プランに従いパーソナルデータが調達される。したがって、同一個人が複数の情報銀行４ａ〜６ａにデータを預託する状況下で発生するデータ利用者２ａのニーズを満たすことができる。また、データ利用者２ａに代わり仲介装置８が複数の情報銀行４ａ〜６ａからデータを調達するため、データ利用者２ａが欲するパーソナルデータの調達をより容易に行うことができる。
【０１８６】
（３ｂ）本実施形態では、調達プラン決定部３３６は、重複結果情報により同一個人に係るパーソナルデータであることが示される第１のパーソナルデータ及び第２のパーソナルデータのうち、いずれか一方を調達する調達プランを決定する。
【０１８７】
したがって、同一個人に係る同一内容のパーソナルデータを複数の情報銀行４ａ，５ａから重複して購入することを抑制することができる。
【０１８８】
（３ｃ）本実施形態では、調達プラン決定部３３６は、同一個人に係る第１のパーソナルデータ及び第２のパーソナルデータのうち価格が安い方を調達する調達プランを決定する。
【０１８９】
したがって、同一個人に係る同一内容のパーソナルデータを重複して購入することを抑制しつつ、データ利用者２ａがより安い金額でパーソナルデータを購入することができる。
【０１９０】
（３ｄ）本実施形態では、重複確認受信部８３６は、重複結果情報を生成可能な外部装置である管理者装置９から重複結果情報を取得する。
【０１９１】
ここで、仲介装置８が、図２４に示す重複状況テーブルを自身の記憶部８２に記憶し、記憶部８２に記憶された重複状況テーブルを基に重複結果情報を取得する構成が考えられる。しかしながら、このような構成では、記憶部８２に記憶された重複状況テーブルが最新の重複状況テーブルに更新されておらず、取得された重複結果情報がパーソナルデータの最新の重複状況を反映していない可能性がある。これに対し、本実施形態の構成によれば、管理者装置９から重複結果情報を取得するため、最新の重複状況を反映した重複結果情報を仲介装置８が取得しやすい。ひいては、仲介装置８が最新の重複状況に基づき調達プランを決定しやすくできる。
【０１９２】
（３ｅ）本実施形態では、重複結果情報は、同一個人に係る、或る情報銀行の情報銀行登録者ＩＤと、別の情報銀行の情報銀行登録者ＩＤと、を対応付ける情報である。
【０１９３】
したがって、複数の情報銀行が同一個人に係るパーソナルデータを異なる情報銀行登録者ＩＤで管理している場合において、仲介装置８は、複数の情報銀行に管理されたいずれのパーソナルデータが同一個人に係るパーソナルデータであるのかを把握できる。そして、仲介装置８は、把握した結果を踏まえ、調達プランを決定することができる。
【０１９４】
なお、本実施形態では、Ｓ３０１がリクエスト取得部としての処理に相当し、Ｓ３０９が属性要求送信部としての処理に相当し、Ｓ３１０が属性情報取得部としての処理に相当し、Ｓ３１２が調達プラン決定部としての処理に相当し、Ｓ３１５がパーソナルデータ取得部としての処理に相当し、Ｓ３１６が形式処理部としての処理に相当し、Ｓ３１７がデータ送信部としての処理に相当する。
【０１９５】
［４．第４実施形態］
［４−１．第３実施形態との相違点］
第４実施形態は、基本的な構成は第３実施形態と同様であるため、共通する構成については説明を省略し、相違点を中心に説明する。なお、第３実施形態と同じ符号は、同一の構成を示すものであって、先行する説明を参照する。
【０１９６】
前述した第３実施形態では、仲介装置８は、複数の情報銀行４ａ〜６ａに預託されているどのデータが同一個人のデータかを確認する重複確認を行う。そして、仲介装置８は、同一個人のパーソナルデータの重複購入を回避するよう調達プランを決定する。すなわち、仲介装置８は、同一個人のパーソナルデータを、複数の情報銀行４ａ〜６ａのうちの特定の情報銀行のみから調達する。
【０１９７】
一方、情報銀行は、生活者に何らかのサービスを提供するために生活者からパーソナルデータを預託してもらうことが考えられる。この場合、情報銀行ごとに提供するサービス内容が異なると、同一個人であっても、情報銀行ごとにデータ項目が異なるパーソナルデータを預託する可能性がある。そこで、データ利用者２ａは、同一個人のパーソナルデータを、複数の情報銀行４ａ〜６ａから名寄せして取得したいと考えることが想定される。
【０１９８】
第４実施形態では、仲介装置８は、複数の情報銀行４ａ〜６ａのそれぞれから同一人物のパーソナルデータを名寄せして調達する点で、第３実施形態と異なる。以下、第４実施形態について詳細に説明する。
【０１９９】
第４実施形態の仲介装置８は、第３実施形態とハードウェア構成及び機能的要素は同じである。特に、第４実施形態の仲介装置８は、図２５に示す各要素３３１〜３４１，８３１〜８３６を備える。各要素３３１〜３４１，８３１〜８３６の機能は基本的には第３実施形態と同様であるが、メタデータ要求生成部３３２及び形式統合部３４０の機能が第３実施形態と一部相違する。以下、これらの要素３３２，３４０について説明する。
＜メタデータ要求生成部＞
メタデータ要求生成部３３２は、重複確認受信部８３６により受信された重複結果情報とリクエスト取得部３３１により受信されたリクエスト情報とに基づき、情報銀行装置４〜６に送信されるメタデータ要求を生成する。受信された重複結果情報から複数の情報銀行にパーソナルデータを預託している個人の情報銀行登録者ＩＤを特定できる。メタデータ受信部３３４は、複数の情報銀行に（すなわち他の情報銀行にも）パーソナルデータを預託している個人のデータのみを含むメタデータを要求するメタデータ要求を生成する。
＜形式統合部＞
形式処理部３４０は、複数の情報銀行装置４〜６から受信された納品データのデータ形式を共通のデータ形式に合わせ、１つのデータに統合することで統合データを生成する。本実施形態では、形式処理部３４０は、複数の情報銀行装置４〜６から受信された同一個人のパーソナルデータを名寄せすることで前記統合データを生成する。
【０２００】
［４−２．処理］
次に、第４実施形態の仲介装置８の制御部８３が、第３実施形態のデータ調達処理に代えて実行するデータ調達処理について、前述した図２６のフローチャートを用いて説明する。
＜Ｓ３０１〜Ｓ３０７＞
Ｓ３０１〜Ｓ３０７は、前述した第３実施形態のＳ３０１〜Ｓ３０７と同様であるため、説明を省略する。
＜Ｓ３０８＞
続いて、Ｓ３０８で、メタデータ要求生成部３３２は、Ｓ３０７で受信された重複結果情報とＳ３０１で受信されたリクエスト情報とに基づき、情報銀行装置４〜６に送信されるメタデータ要求を生成する。ここで、メタデータ要求生成部３３２は、複数の情報銀行にパーソナルデータを預託している個人のデータのみを含むメタデータを要求するメタデータ要求を生成する。
【０２０１】
具体的には、メタデータ要求生成部３３２は、図３２及び図３３に示すようなメタデータ要求を生成する。図３２には第１の情報銀行４ａに送信されるメタデータ要求の例が示される。図３３には第２の情報銀行５ａに送信されるメタデータ要求の例が示される。
【０２０２】
本実施形態のメタデータ要求は、前述した図６に示すメタデータ要求と基本的には同じ項目を含むが、分布集計軸の項目を含まない。また、本実施形態のメタデータ要求は、文内容に対象ＩＤの項目を更に含む。
【０２０３】
ここでいう対象ＩＤとは、情報銀行から送信されるメタデータに含める個人の情報銀行登録者ＩＤを示す項目である。つまり、メタデータ要求を受信した情報銀行４ａ〜６ａは、対象ＩＤで指定された情報銀行登録者ＩＤのデータのみを含むメタデータを仲介装置８に送信する。対象ＩＤには、複数の情報銀行にパーソナルデータを預託している個人の情報銀行登録者ＩＤが記述される。
【０２０４】
例えば、前述した図２４の例では、情報銀行ＩＤが「００００１」である第１の情報銀行４ａの情報銀行登録者ＩＤ「０９００８３８」と、情報銀行ＩＤが「００００２」である第２の情報銀行５ａの情報銀行登録者ＩＤ「９８８８１００」と、情報銀行ＩＤが「００００３」である第３の情報銀行６ａの情報銀行登録者ＩＤ「４３０９８１２１３」と、は同一個人のＩＤである。また、第１の情報銀行４ａの情報銀行登録者ＩＤ「２９１０１１０」と、第２の情報銀行５ａの情報銀行登録者ＩＤ「７５５０３６０」と、は同一個人のＩＤである。
【０２０５】
したがって、図３２に示すように、第１の情報銀行４ａに対しては、複数の情報銀行４ａ〜６ａにデータを預託している個人を示すＩＤとして、対象ＩＤに、情報銀行登録者ＩＤ「０９００８３８」及び「２９１０１１０」が記述される。
【０２０６】
なお、図３２の例では、第１の情報銀行４ａは、要求項目の欄から見て取れるように、性別（Ｇｅｎｄｅｒ）、年代（Ａｇｅ１０）等の基本属性のほかに、子供の年齢（Ａｇｅ＿ｍｉｎｏｒ＿ｃｈｉｌｄ）、家族の人数（Ｎｕｍ＿Ｆａｍｉｌｙ）、自炊頻度（Ｆｒｅｑ＿ＨｏｍｅＣｏｏｋ）、スーパーマーケットの利用頻度（Ｆｒｅｑ＿ＧＳＭ）、コンビニエンスストアの利用頻度（Ｆｒｅｑ＿ＣＶＳ）、ドラッグストアの利用頻度（Ｆｒｅｑ＿ＤＳ）といったパーソナルデータの属性を保有している。
【０２０７】
一方、図３３に示すように、第２の情報銀行５ａに対しては、複数の情報銀行４ａ，５ａにデータを預託している個人を示すＩＤとして、対象ＩＤに、情報銀行登録者ＩＤ「７５５０３６０」及び「９８８８１００」が記述される。
【０２０８】
なお、図３３の例では、第２の情報銀行５ａは、要求項目の欄から見て取れるように、性別、年代等の基本属性のほかに、レシピサイト月間閲覧履歴、３ヶ月雑誌購買金額といったパーソナルデータの属性を保有している。
【０２０９】
メタデータ要求生成部３３２は、上記のようなメタデータ要求を生成する。
＜Ｓ３０９〜Ｓ３１５＞
Ｓ３０９〜Ｓ３１５は、前述した第３実施形態のＳ３０９〜Ｓ３１５と同様であるため、説明を省略する。
＜Ｓ３１６＞
続いて、Ｓ３１６で、形式処理部３４０は、複数の情報銀行装置４〜６から受信された納品データのデータ形式を共通のデータ形式に合わせ、１つのデータに統合することで統合データを生成する。
【０２１０】
図３４には、統合データの例が示されている。図中、符号１０ａで示すパーソナルデータの属性（すなわちデータ項目）は、第１の情報銀行４ａ及び第２の情報銀行５ａの両方が保有している属性である。一方、符号１０ｂで示すパーソナルデータの属性は、第１の情報銀行４ａのみが保有している属性である。また、符号１０ｃで示すパーソナルデータの属性は、第２の情報銀行５ａのみが保有している属性である。形式処理部３４０は、このようにして、同一個人のパーソナルデータを複数の情報銀行４ａ〜６ａから名寄せすることで統合データを生成する。
＜Ｓ３１７＞
Ｓ３１７は、前述した第３実施形態のＳ３１７と同様であるため、説明を省略する。
【０２１１】
［４−３．効果］
以上詳述した第４実施形態によれば、前述した第１実施形態の効果（１ａ）〜（１ｈ）及び第３実施形態の効果（３ａ）、（３ｄ）及び（３ｅ）に加え、以下の効果が得られる。
【０２１２】
（４ａ）本実施形態では、調達プラン決定部３３６は、重複結果情報により同一個人に係るパーソナルデータであることが示される第１のパーソナルデータ及び第２のパーソナルデータの両方を調達する調達プランを決定する。
【０２１３】
したがって、例えば、同一個人が第１の情報銀行４ａと第２の情報銀行５ａとに異なる内容のパーソナルデータを預託している場合において、同一個人のパーソナルデータを複数の情報銀行４ａ，５ａから名寄せすることができる。複数の情報銀行に預託されるパーソナルデータが同一であるとは限らないため、名寄せによっていずれの情報銀行４ａ，５ａにもない情報を仲介装置８が生成することができる。
【０２１４】
なお、本実施形態では、第３実施形態と同様に、仲介装置８の各構成が請求項の各文言に相当する。
【０２１５】
［５．第５実施形態］
［５−１．第３実施形態との相違点］
第５実施形態は、基本的な構成は第３実施形態と同様であるため、共通する構成については説明を省略し、相違点を中心に説明する。なお、第３実施形態と同じ符号は、同一の構成を示すものであって、先行する説明を参照する。
【０２１６】
第３実施形態は、仲介装置８は外部の管理者装置９から重複結果情報を取得する。これに対し、第５実施形態では、仲介装置８の記憶部８２には重複状況テーブルがあらかじめ記憶されている。そして、仲介装置８は、利用者装置２からリクエスト情報を受信した場合に、記憶部８２から重複状況テーブルを基に重複結果情報を生成する点で、第３実施形態と相違する。以下、第５実施形態について詳細に説明する。
【０２１７】
第５実施形態の仲介装置１１は、図２に示すように、通信部１１１と、記憶部１１２と、制御部１１３と、を備える。これらの構成１１１〜１１３のハードウェア構成は、第３実施形態の仲介装置８の各構成８１〜８３と同一である。ただし、第５実施形態の仲介装置１１の記憶部１１２に記憶されているデータが第３実施形態と異なる。具体的には、第５実施形態の記憶部１１２には、図３５に示す重複管理テーブルが記憶されている。
【０２１８】
図３５の重複状況テーブルは、前述した図２４に示す、登録管理者９ａが保有する重複管理テーブルと基本的には同様であるが、パーソナルデータの価格の項目を更に含む点で相違する。すなわち、図３５に示す重複状況テーブルは、情報銀行ＩＤと、情報銀行登録者ＩＤと、個人ＩＤと、パーソナルデータの価格と、が対応付けられて設定された情報である。
【０２１９】
本実施形態では、記憶部１１２に記憶されている重複状況テーブルは、所定頻度（例えば１ヶ月に１度や１週間に１度）で定期的に更新されることが想定される。なお、重複状況テーブルの更新は種々の方法で行われ得るが、例えば次のようにして行われてもよい。すなわち、仲介装置１１の保有者が、管理者装置９を保有する登録管理者９ａから重複状況テーブルを記憶した記憶媒体を受領し、受領された記憶媒体内の重複状況テーブルを記憶部１１２に記憶することで重複状況テーブルの更新が行われてもよい。
【０２２０】
一方、制御部１１３は、ＣＰＵ１１３ａがメモリ１１３ｂに記憶されているプログラムを実行することで後述する図３７に示すデータ調達処理を実行する。制御部１１３はデータ調達処理を実行することで、図３６に示すように各要素３３１〜３４１，８３１〜８３３、９３１，９３２として機能する。つまり、第５実施形態の制御部１１３は、第３実施形態の図２５に示す重複確認生成部８３４、重複確認送信部８３５及び重複確認受信部８３６に代えて重複確認取得部９３１として機能し、更に、更新処理部９３２として機能する点で、第３実施形態と相違する。以下、相異点に係る重複確認取得部９３１及び更新処理部９３２について説明する。
＜重複確認取得部＞
重複確認取得部９３１は、記憶部１１２から重複状況テーブルを取得する。そして、重複確認取得部９３１は、ＩＤ受信部８３３により受信されたＩＤ結果情報と、記憶部１１２から取得された重複状況テーブルと、に基づき、重複結果情報を生成する。重複結果情報の生成の仕方は、前述した第３実施形態の管理者装置９が重複結果情報する仕方と同じであるため、説明を省略する。
＜更新処理部＞
更新処理部９３２は、形式処理部３４０により生成された統合データに基づき、記憶部１１２に記憶されている重複状況テーブルを更新する。
【０２２１】
例えば、更新処理部９３２は、統合データに含まれるデータと重複状況テーブルに登録されているデータとが異なる場合、重複状況テーブルに登録されているデータを納品データに含まれるデータに更新する。これにより、統合データに含まれるデータ、つまり、仲介装置１１が直近で購入した最新のデータ内容に重複状況テーブルが更新される。
【０２２２】
［５−２．処理］
次に、第５実施形態の仲介装置１１の制御部１１３が、第３実施形態のデータ調達処理（図２６）に代えて実行するデータ調達処理について、図３７のフローチャートを用いて説明する。
＜Ｓ４０１〜Ｓ４０４＞
Ｓ４０１〜Ｓ４０４は、前述した図２６のＳ３０１〜Ｓ３０４と同様であるため、説明を省略する。
＜Ｓ４０５＞
続いて、Ｓ４０５で、重複確認取得部９３１は、記憶部１１２から重複状況テーブルを取得する。そして、重複確認取得部９３１は、ＩＤ受信部８３３により受信されたＩＤ結果情報と、記憶部１１２から取得された重複状況テーブルと、に基づき、重複結果情報を生成することで、重複結果情報を取得する。
＜Ｓ４０６〜Ｓ４１５＞
Ｓ４０６〜Ｓ４１５は、前述した図２６のＳ３０８〜Ｓ３１７と同様であるため、説明を省略する。
＜Ｓ４１６＞
続いて、Ｓ４１６で、更新処理部９３２は、形式処理部３４０により生成された統合データに基づき、記憶部１１２に記憶されている重複状況テーブルを更新する。
【０２２３】
［５−３．効果］
以上詳述した第５実施形態によれば、前述した第１実施形態の効果（１ａ）〜（１ｈ）及び第３実施形態の効果（３ａ）〜（３ｃ）及び（３ｅ）に加え、以下の効果が得られる。
【０２２４】
（５ａ）本実施形態では、仲介装置１１は、記憶部１１２から重複状況テーブルを取得する。そして、重複確認取得部９３１は、ＩＤ受信部８３３により受信されたＩＤ結果情報と、取得された重複状況テーブルと、に基づき、重複結果情報を生成することで重複結果情報を取得する。つまり、仲介装置１１は、管理者装置９との間でデータのやり取りを行わなくても重複結果情報を取得できる。したがって、管理者装置９に重複確認要求を送信して重複結果情報を取得する構成と比較して、管理者装置９の通信量を減らすことができる。また、重複確認要求及び重複結果情報の送受信を行うためのＡＰＩ（Application  Programming  Interface）等のシステム開発費を抑えることができる。
【０２２５】
なお、本実施形態では、Ｓ４０１がリクエスト取得部としての処理に相当し、Ｓ４０７が属性要求送信部としての処理に相当し、Ｓ４０８が属性情報取得部としての処理に相当し、Ｓ４１０が調達プラン決定部としての処理に相当し、Ｓ４１３がパーソナルデータ取得部としての処理に相当し、Ｓ４１４が形式処理部としての処理に相当し、Ｓ４１６がデータ送信部としての処理に相当する。
【０２２６】
［６．第６実施形態］
［６−１．第３実施形態との相違点］
第６実施形態は、基本的な構成は第３実施形態と同様であるため、共通する構成については説明を省略し、相違点を中心に説明する。なお、第３実施形態と同じ符号は、同一の構成を示すものであって、先行する説明を参照する。第６実施形態は、データ利用者２ａの利用者装置２が、情報銀行４ａ〜６ａから調達されたパーソナルデータを使って、情報銀行４ａ〜６ａにパーソナルデータを預託した個人に対して広告配信を行う点で、前述した第３実施形態と相違する。
【０２２７】
図３８に示す第６実施形態の調達システム１２は、第３実施形態と同様に、利用者装置２、仲介装置３及び複数の情報銀行装置４〜６を備える。第６実施形態の仲介装置３及び複数の情報銀行装置４〜６は、第３実施形態のものと同様である。
【０２２８】
一方、第６実施形態の利用者装置２は、図３９に示すように、通信部２１と、記憶部２２と、制御部２３と、を備える。通信部２１は、利用者装置２をネットワークに接続するための通信インタフェースである。利用者装置２は、通信部２１を介して、仲介装置８や、個人が保有する情報処理端末１１〜１７とデータ通信可能である。
【０２２９】
記憶部２２は、各種データを記憶する。本実施形態では、記憶部２２には、広告情報と送信先情報とが記憶されている。ここでいう広告情報は、データ利用者２ａが情報銀行４ａ〜６ａから調達したパーソナルデータに係る個人に送信される広告情報であり、調達されたパーソナルデータの属性（換言すれば、パーソナルデータに係る個人の嗜好性等の各種属性）に対応した広告情報である。
【０２３０】
また、ここでいう送信先情報は、広告情報が送信される送信先を指定する情報である。本実施形態では、送信先として、情報銀行４ａ〜６ａにパーソナルデータを預託した個人が想定される。送信先情報は、例えば、ＩＤＦＡ（Identification For Advertisers）やＡＤＩＤ（Advertising Identifier）、クッキーＩＤ、配信対象者の電子メールアドレスなどの、広告情報の送信先を識別する識別子であってもよい。本実施形態では、送信先情報は、情報銀行４ａ〜６ａから取得されたパーソナルデータに含まれていることが想定される。
【０２３１】
制御部２３は、ＣＰＵ２３ａと、ＲＡＭ、ＲＯＭ、フラッシュメモリ等の半導体メモリ（以下、メモリ２３ｂ）と、を有する周知のマイクロコンピュータを中心に構成される。制御部２３の各種機能は、ＣＰＵ２３ａが非遷移的実体的記憶媒体に格納されたプログラムを実行することにより実現される。この例では、メモリ２３ｂが、プログラムを格納した非遷移的実体的記憶媒体に該当する。また、このプログラムの実行により、プログラムに対応する方法が実行される。制御部２３は、後述する図４０に示す広告配信処理を実行する。
【０２３２】
［６−２．処理］
次に、利用者装置２の制御部２３が実行する広告配信処理について、図４０のフローチャートを用いて説明する。なお、広告配信処理は、適宜のタイミングで実行される。
【０２３３】
まず、Ｓ５０１で、制御部２３は、記憶部２２から広告情報と送信先情報とを取得する。
【０２３４】
続いて、Ｓ５０２で、制御部２３は、広告配信を行う。具体的には、制御部２３は、Ｓ５０１で取得された広告情報を、Ｓ５０１で取得された送信先情報が示す送信先に対して通信部２１を介して送信する。制御部２３は、Ｓ５０２を実行すると、図４０の広告配信処理を終了する。
【０２３５】
［６−３．効果］
以上詳述した第６実施形態によれば、前述した第１実施形態の効果（１ａ）〜（１ｈ）及び第３実施形態の効果（３ａ）〜（３ｅ）に加え、以下の効果が得られる。
【０２３６】
（６ａ）本実施形態では、利用者装置２は、情報銀行４ａ〜６ａから取得されたパーソナルデータを使って、情報銀行４ａ〜６ａにパーソナルデータを預託した個人に対し、広告配信を行う。具体的には、利用者装置２は、仲介装置８から取得されたパーソナルデータに係る個人に通知される広告情報と、前記広告情報の送信先を示す送信先情報と、を取得する。そして、利用者装置２は、送信先情報が示す送信先に広告情報を送信する。
【０２３７】
したがって、情報銀行装置４〜６から取得されたパーソナルデータを使って広告情報が送信される。よって、情報銀行４ａ〜６ａにパーソナルデータを預託した個人に適した広告配信を行うことができる。
【０２３８】
なお、本実施形態では、調達システム１２がシステムに相当し、広告情報が通知情報に相当し、Ｓ５０１が通知情報取得部としての処理に相当し、Ｓ５０２が通知情報送信部としての処理に相当する。
【０２３９】
［７．第７実施形態］
［７−１．第１実施形態との相違点］
第７実施形態は、基本的な構成は第１実施形態と同様であるため、共通する構成については説明を省略し、相違点を中心に説明する。なお、第１実施形態と同じ符号は、同一の構成を示すものであって、先行する説明を参照する。
【０２４０】
前述した第１実施形態では、データ利用者２ａは、仲介装置３を介して情報銀行４ａ〜６ａからパーソナルデータを取得する。ここで、データ利用者が、パーソナルデータの取扱いコストを負担したくない場合が想定される。すなわち、昨今、情報銀行４ａ〜６ａからパーソナルデータを取得するデータ利用者に対しても、プライバシーマークの使用などの安全管理装置を求める動きがある。安全管理装置とは、事業者がパーソナルデータの漏洩、滅失又は毀損の防止その他のパーソナルデータの安全管理のために必要かつ適切な措置をいう。しかし、中小企業であるデータ利用者などにとっては、こうした安全管理装置を行うのが困難な場合もある。そこで、このようなデータ利用者は、安全管理措置を行わない代わりに匿名加工情報を取得することが考えられる。ここでいう匿名加工情報とは、パーソナルデータを基に生成される情報であり、そのパーソナルデータに係る個人が特定されないようにパーソナルデータに含まれる情報を変更又は削除して生成される情報である。
【０２４１】
第７実施形態では、仲介装置３は、情報銀行４ａ〜６ａから取得したパーソナルデータを基に匿名加工情報を生成し、生成された匿名加工情報を利用者装置２に送信する点で、第１実施形態と相違する。以下、第７実施形態について詳細に説明する。
【０２４２】
第７実施形態の調達システム１のハードウェア構成は、第１実施形態と同様である。一方、第７実施形態の仲介装置３が実行する処理及び送受信するデータは、第１実施形態と一部相違する。
【０２４３】
［７−２．処理］
以下、第７実施形態の仲介装置３の制御部３３が、第１実施形態のデータ調達処理（図４）に代えて実行するデータ調達処理について、図４１のフローチャートを用いて説明する。なお、図４１のフローチャートにおいて、Ｓ５０１，Ｓ５０３〜Ｓ５０９，Ｓ５１１の処理（すなわちＳ５０２及びＳ５１０以外の処理）は、前述した図４のＳ１０１，Ｓ１０３〜Ｓ１０９，Ｓ１１１とそれぞれ同様である。よって、以下では、これらの処理の説明を省略し、相異点であるＳ５０２及びＳ５１０のみ説明する。
【０２４４】
＜Ｓ５０２＞
Ｓ５０２で、メタデータ要求生成部３３２は、Ｓ５０１で受信されたリクエスト情報に基づいて、メタデータ要求を生成する。本実施形態では、メタデータ要求生成部３３２は、図４２に示すようなメタデータ要求を生成する。図４２に示すメタデータ要求は、基本的には図６に示す第１実施形態のメタデータ要求と同様であるが、パーソナルデータの利用目的の種別の記述が異なる。図４２に示すメタデータ要求では、パーソナルデータの利用目的の種別は「匿名加工情報作成」と記述される。
【０２４５】
＜Ｓ５１０＞
Ｓ５１０で、形式処理部３４０は、各情報銀行装置４〜６から受信された納品データのデータ形式を揃えるとともにデータを変換する。そして、形式処理部３４０は、各情報銀行装置４〜６からの納品データを１つのデータに統合する。具体的には、形式処理部３４０は、第１実施形態と同様に、各情報銀行装置４〜６から受信された納品データに含まれる変数名や値を各情報銀行装置４〜６のデータ変換用辞書に従い変換することで、各情報銀行装置４〜６から受信された納品データのデータ形式を揃える。そして、形式処理部３４０は、納品データに含まれる変数名や値を、個人情報保護法に定められた基準を満たすように変換する。
【０２４６】
具体的には、形式処理部３４０は、例えば、第１の情報銀行４ａから受信された図１６Ａに示す納品データに含まれる変数名や値を、図１５に示す変換用辞書に従い変換する。そして、形式処理部３４０は、図４３に示すような第１の情報銀行４ａの変換後の納品データを生成する。図４３に示す変換後の納品データは、匿名加工処理が施された匿名加工情報である。匿名加工処理は、パーソナルデータを、パーソナルデータに係る個人が特定できないように変更又は削除する処理である。匿名加工処理は、例えば、パーソナルデータの粒度を、パーソナルデータに係る個人が特定できない程度に粗くする処理であってもよい。
【０２４７】
具体的には例えば、図４３に示す匿名加工情報では、個人を特定可能な情報が削除される。個人を特定可能な情報としては、例えば、情報銀行が個人に対して付与するＩＤ（すなわち情報銀行登録者ＩＤ）や氏名などが挙げられる。そして、図４３に示すＩＤ（ａ３３２１、３４ａｃｄ、９４３ｄｄ、・・・）のように、ランダムに個人又はパーソナルデータに対してＩＤが付与される。
【０２４８】
また、匿名加工情報では、例えば、特定の地域（例えば日本）全体で見たときに特徴的又は珍しい情報であり、それゆえに個人を特定できるような情報が削除又は変更されてもよい。
【０２４９】
具体的には例えば、パーソナルデータに係る個人の年齢（Ｄｅｍｏｇｒａｐｈｉｃ：Ａｇｅ）が「１１５歳」であるとする。この場合、年齢が「１１５歳」であるという情報は日本全体で見たときに珍しく、個人を特定し得る情報である。よって、このような情報は、匿名加工情報において削除されたり、「１００歳以上」などと丸められたりしてよい。
【０２５０】
また、匿名加工情報においては、情報銀行４ａ〜６ａから取得されたデータセットの中で特徴的又は珍しく、個人を特定でき得る情報についても削除又は変更されてもよい。
【０２５１】
例えば、「未既婚」（Ｄｅｍｏｇｒａｐｈｉｃ：Ｍａｒｉｔａｌ）が「離別」や「死別」であるといった情報は、上記データセットの中で特徴的又は珍しく、個人を特定でき得る情報であるとする。この場合、或る個人の「未既婚」が「離別」又は「死別」に該当するときには、図４３に示すＩＤ「３４ａｃｄ」のように、その個人の「未既婚」が「離別又は死別」のように変更されてもよい。
【０２５２】
また例えば、３ヶ月雑誌購買金額（Ａｇｇｒｅｇａｔｅ：１：ＴｏｔａｌＥｘｐｅｎｓｅ３ＭｏｎｔｈＳｅａｓｏｎｉｎｇｓ）が５０００円よりも大きいという情報は上記データセットの中で特徴的又は珍しく、個人を特定でき得る情報であるとする。この場合、匿名加工情報においては、図４３に示すＩＤ「０９ａｂａ」の個人のように、５０００円よりも大きい実際の金額が記されるのではなく、「５０００円」のように数値が丸められてもよい。
【０２５３】
仲介装置３はこのようにして、各情報銀行４ａ〜６ａから受信された納品データを匿名加工情報に変換する。そして、仲介装置３は、各情報銀行４ａ〜６ａの匿名加工情報を１つのデータに統合し、統合データを生成する。なお、匿名加工処理及びデータの統合処理が実施される順序をこれに限らない。例えば、各情報銀行４ａ〜６ａの納品データを１つのデータに統合した後、統合データに対して匿名加工処理が施されてもよい。
【０２５４】
［７−３．効果］
以上詳述した第７実施形態によれば、前述した第１実施形態の効果（１ａ）〜（１ｈ）に加え、以下の効果が得られる。
【０２５５】
本実施形態では、仲介装置３は、情報銀行装置４〜６からパーソナルデータを通信部３１を介して受信し、受信されたパーソナルデータを基に匿名加工情報を生成する。ここで、匿名加工情報は、パーソナルデータを基に生成される情報であり、そのパーソナルデータに係る個人が特定されないようにパーソナルデータに含まれる情報を変更又は削除して生成される情報（すなわちデータ）である。そして、仲介装置３は、生成された匿名加工情報を通信部３１を介して利用者装置２に送信する。
【０２５６】
したがって、安全管理装置を行うのが困難なデータ利用者のパーソナルデータの取扱いコストを軽減できる。また、パーソナルデータの管理に関するコンピュータセキュリティを向上できる。
【０２５７】
なお、本実施形態では、Ｓ５０１がリクエスト取得部としての処理に相当し、Ｓ５０３が属性要求送信部としての処理に相当し、Ｓ５０４が属性情報取得部としての処理に相当し、Ｓ５０６が調達プラン決定部としての処理に相当し、Ｓ５０９がパーソナルデータ取得部としての処理に相当し、Ｓ５１０が形式処理部としての処理に相当し、Ｓ５１１がデータ送信部としての処理に相当する。
【０２５８】
［８．第８実施形態］
［８−１．第７実施形態との相違点］
第８実施形態は、基本的な構成は第１実施形態と同様であるため、共通する構成については説明を省略し、相違点を中心に説明する。なお、第１実施形態と同じ符号は、同一の構成を示すものであって、先行する説明を参照する。
【０２５９】
前述した第１実施形態では、データ利用者２ａは、仲介装置３を介して情報銀行４ａ〜６ａからパーソナルデータを取得する。ここで、データ利用者２ａにとって、そもそも細かい粒度のパーソナルデータが不要な場合が想定される。例えば、データ利用者２ａが、自社顧客が競合商品をどの程度買っているかを知りマーケティング戦略を立てる場合を考える。この場合、自社顧客のデータでなくても、自社顧客に似た属性を有する個人達の競合商品の平均購入量の統計情報が分かればデータ利用者２ａが戦略を十分考えられる場合がある。この場合、細かい粒度のパーソナルデータは不要である。
【０２６０】
第８実施形態では、仲介装置３は、情報銀行４ａ〜６ａから取得されたパーソナルデータを基に統計情報を生成し、生成された統計情報を利用者装置２に送信する点で、第１実施形態と相違する。以下、第８実施形態について詳細に説明する。
【０２６１】
第８実施形態の調達システム１のハードウェア構成は、第１実施形態と同様である。一方、第８実施形態の仲介装置３が実行する処理及び送受信するデータは、第１実施形態と一部相違する。
【０２６２】
［８−２．処理］
以下、第８実施形態の仲介装置３の制御部３３が、第１実施形態のデータ調達処理（図４）に代えて実行するデータ調達処理について、前述した図４１のフローチャートを用いて説明する。なお、図４１のフローチャートにおいて、Ｓ５０１，Ｓ５０３〜Ｓ５０９，Ｓ５１１の処理（すなわちＳ５０２及びＳ５１０以外の処理）は、前述した図４のＳ１０１，Ｓ１０３〜Ｓ１０９，Ｓ１１１とそれぞれ同様である。よって、以下では、これらの処理の説明を省略し、相異点であるＳ５０２及びＳ５１０のみ説明する。
【０２６３】
＜Ｓ５０２＞
Ｓ５０２で、メタデータ要求生成部３３２は、Ｓ５０１で受信されたリクエスト情報に基づいて、メタデータ要求を生成する。本実施形態では、メタデータ要求生成部３３２は、図４４に示すようなメタデータ要求を生成する。図４４に示すメタデータ要求は、基本的には図６に示す第１実施形態のメタデータ要求と同様であるが、パーソナルデータの利用目的の種別の記載が異なる。図４１に示すメタデータ要求では、パーソナルデータの利用目的の種別は「統計情報作成」と記述される。
【０２６４】
＜Ｓ５１０＞
Ｓ５１０で、形式処理部３４０は、各情報銀行装置４〜６から受信された納品データのデータ形式を揃えるとともにデータを変換する。そして、形式処理部３４０は、各情報銀行装置４〜６からの納品データを１つのデータに統合する。具体的には、形式処理部３４０は、第１実施形態と同様に、各情報銀行装置４〜６から受信された納品データに含まれる変数名や値を各情報銀行装置４〜６のデータ変換用辞書に従い変換することで、各情報銀行装置４〜６から受信された納品データのデータ形式を揃える。そして、形式処理部３４０は、変数名や値が変換された納品データを統計情報に変換する。ここでいう統計情報とは、情報銀行４ａ〜６ａから取得された複数の個人に係るパーソナルデータを集計又は加工して得られた情報である。
【０２６５】
具体的には例えば、形式処理部３４０は、第１の情報銀行４ａから受信された図１６Ａに示す納品データに含まれる変数名や値を、図１５に示す変換用辞書に従い変換する。そして、形式処理部３４０は、図４５に示すような第１の情報銀行４ａの変換後の納品データを生成する。図４５に示す変換後の納品データは、統計情報化された納品データである。
【０２６６】
図４５に示す統計情報では、第１の情報銀行４ａから受信された複数の個人に係るパーソナルデータが複数のグループ（例えばグループＩＤが１〜６までの６つのグループ）に分類される。例えば、複数の個人に係るパーソナルデータを、パーソナルデータに含まれる適当な項目（例えば３ヶ月雑誌購買金額）でマッピングし、クラスタリングすることで、パーソナルデータが複数のグループに分類されてもよい。
【０２６７】
そして、各グループのグループＩＤごとに、グループサイズと、各種のデモグラフィック属性（性別＝男性、年齢＝１５歳等）に該当する個人の総数と、が対応付けられている。グループサイズは、そのグループに含まれる個人又はパーソナルデータの総数である。
【０２６８】
そして、仲介装置３は、情報銀行４ａ〜６ａごとに生成された統計情報を１つのデータに統合し、統合データを生成する。
【０２６９】
なお、上記ではクラスタリングを行うことで統計情報が生成されるが、統計情報を生成する手法はこれに限られない。例えば、クロス集計等の他の統計手法により統計情報が生成されてもよい。
【０２７０】
また例えば、上記ではパーソナルデータを複数のグループに分類することで統計情報が生成されるが、例えばパーソナルデータを複数のグループに分類することなく、１つのグループにまとめてもよい。そして、そのグループについて、各種のデモグラフィック属性等に該当する個人又はパーソナルデータの総数、平均、中央値、分散等を示す統計情報を生成してもよい。
【０２７１】
また例えば、情報銀行４ａ〜６ａごとに統計情報を生成するのではなく、複数の情報銀行４ａ〜６ａから受信されたパーソナルデータを一旦全部集約して、集約されたパーソナルデータを基に統計情報が生成されてもよい。
【０２７２】
このように第８実施形態では、パーソナルデータ単位でデータが利用者装置２に送信されるのではなく、グループ単位でデータが送信される。
【０２７３】
なお、第８実施形態では、統計情報の生成に用いられたパーソナルデータに係る個人を、生成された統計情報から特定できないように統計情報が生成される。つまり、生成される統計情報は、匿名加工情報であってもよい。
【０２７４】
［８−３．効果］
以上詳述した第８実施形態によれば、前述した第１実施形態の効果（１ａ）〜（１ｈ）に加え、以下の効果が得られる。
【０２７５】
本実施形態では、仲介装置３は、情報銀行装置４〜６から複数の個人に係るパーソナルデータを通信部３１を介して受信し、受信されたパーソナルデータを基に、パーソナルデータの属性（すなわち、性別、年齢等の項目）に関する統計情報を示す統計情報を生成する。そして、仲介装置３は、生成された統計情報を通信部３１を介して利用者装置２に送信する。
【０２７６】
したがって、細かい粒度のパーソナルデータが不要であり、統計情報があれば十分な場合において、データ利用者２ａに統計情報を提供できる。また、統計情報化することで一般にデータの粒度が粗くなるため、安全管理装置を行うのが困難なデータ利用者のパーソナルデータの取扱いコストを軽減できる。また、パーソナルデータの管理に関するコンピュータセキュリティを向上できる。
【０２７７】
［９．第９実施形態］
［９−１．第４実施形態との相違点］
第９実施形態は、基本的な構成は第４実施形態と同様であるため、共通する構成については説明を省略し、相違点を中心に説明する。なお、第４実施形態と同じ符号は、同一の構成を示すものであって、先行する説明を参照する。
【０２７８】
前述した第４実施形態では、仲介装置８は、複数の情報銀行４ａ〜６ａから同一個人のパーソナルデータを名寄せする。特に、第４実施形態では、複数の情報銀行４ａ〜６ａが保有するパーソナルデータの中に同一個人のパーソナルデータがあるかどうかを仲介装置８が管理者装置９に問合せる。そして、管理者装置９は、図２４に示す情報銀行ＩＤ、情報銀行登録者ＩＤ及び個人ＩＤの３つのＩＤを使用して、同一個人のパーソナルデータを特定する。そして、仲介装置８は、同一個人のパーソナルデータであると特定された複数のパーソナルデータを、複数の情報銀行４ａ〜６ａから取得する。
【０２７９】
一方、第９実施形態は、複数の情報銀行４ａ〜６ａから同一個人のパーソナルデータを名寄せする点は第４実施形態と同様である。しかし、第９実施形態では、仲介装置が管理者装置９に問い合わせるのではない。具体的には、第９実施形態の仲介装置は、複数の情報銀行４ａ〜６ａから受信された複数のパーソナルデータを含むデータセット上で、年齢、性別等の属性値の組合せが類似する複数のパーソナルデータを特定する。そして、属性値の組合せが類似する複数のパーソナルデータを同一個人に係るパーソナルデータであるとして複数の情報銀行４ａ〜６ａから名寄せする点で、第４実施形態と相違する。以下、第９実施形態について詳細に説明する。
【０２８０】
第９実施形態の調達システムのハードウェア構成は、前述した第４実施形態というよりは前述した第１実施形態と同様である。一方、第９実施形態の仲介装置１２の機能は、第１実施形態と一部相違する。
【０２８１】
具体的には、第９実施形態の仲介装置１２の制御部は、図４６に示すように各要素３３１〜３４１，１２３１として機能する。
【０２８２】
つまり、第９実施形態の仲介装置１２の制御部は、第１実施形態の図３に示す各要素３３１〜３４１に加え、更に、類似度判定部１２３１として機能する点で、第１実施形態と相違する。
＜類似度判定部＞
類似度判定部１２３１は、複数の情報銀行４ａ〜６ａから受信された複数のパーソナルデータの中から、パーソナルデータの属性値が類似する複数のパーソナルデータを特定する。パーソナルデータが類似するか否かの判定は、パーソナルデータ間の類似度が所定のしきい値以上又は以下であるかを判定することで行われてもよい。そして、類似度判定部１２３１は、特定された複数のパーソナルデータを同一個人のパーソナルデータであるとして互いに紐付ける。そして、類似度判定部１２３１によって互いに紐付けられた複数のパーソナルデータは、同一個人のパーソナルデータであるとして、データ送信部３４１によってデータ利用者２ａに送信される。類似度判定部１２３１の処理内容については以下に詳述する。
【０２８３】
［９−２．処理］
次に、第９実施形態の仲介装置１２の制御部が、第１実施形態のデータ調達処理（図４）に代えて実行するデータ調達処理について、図４７のフローチャートを用いて説明する。なお、図４７のフローチャートにおいて、Ｓ６０１〜Ｓ６１０，Ｓ６１２の処理（すなわちＳ６１１以外の処理）は、前述した図４のＳ１０１〜Ｓ１１１とそれぞれ同様である。よって、以下では、これらの処理の説明を省略し、相異点であるＳ６１１のみ説明する。
＜Ｓ６１１＞
Ｓ６１１で、類似度判定部１２３１は、複数の情報銀行４ａ〜６ａから受信された複数のパーソナルデータについて類似度判定を行う。そして、類似度判定部１２３１は、互いに類似していると判定した複数のパーソナルデータを互いに紐付ける。類似度判定は、複数のパーソナルデータが類似しているか否かの判定である。具体的には、類似度判定部１２３１は、属性値が類似する複数のパーソナルデータを次のようにして特定する。
【０２８４】
すなわち、形式処理部３４０によってデータ形式が揃えられた結果、図４８及び図４９に示すデータセットが得られたとする。
【０２８５】
図４８は、第１の情報銀行４ａから得られたパーソナルデータの変数や値を共通の形式に変換したデータセットである。図４９は、第２の情報銀行５ａから得られたパーソナルデータの変数や値を共通の形式に変換したデータセットである。図４８及び図４９に示す例では、第１の情報銀行４ａ及び第２の情報銀行５ａからそれぞれ２０個ずつパーソナルデータ（ＩＤが１〜２０のパーソナルデータ）が取得されたことが想定される。
【０２８６】
図４８及び図４９に示すデータセットにおいて、各ＩＤにはパーソナルデータの各属性値が対応付けられる。図４８及び図４９において、値「１」はその属性に該当することを意味し、値「０」はその属性に該当しないことを意味する。例えば、図４８に示すデータセットにおいて、ＩＤ＝１のパーソナルデータが「D:Gender:1」＝１、「D:Age:20-34」＝１であるのは、ＩＤ＝１のパーソナルデータに係る個人が男性であり、年齢が２０歳−３４歳であることを意味する。
【０２８７】
なお、前述した第１実施形態では、共通のデータ形式である標準値は、図１４に示すように「男性」、「女性」等のテキストを含むが、本実施形態では、後に行う計算上の便宜で、標準値は「０」、「１」等の数値に設定されている。
【０２８８】
ここで重要であるのは、異なる情報銀行４ａ，５ａから受信されたデータセットの変数や、値の意味が形式処理部３４０（すなわち、Ｓ６１０の処理）によって共通の形式に変換された結果、一致していることである。値の意味とは、例えば「D:Gender:1」は男性であることを意味する、等である。これによって、取扱い可能なデータ形式が異なる複数の情報銀行４ａ〜６ａから取得されたパーソナルデータ間の類似度を計算することができる。
【０２８９】
具体的には、例えば、図４８及び図４９に示すデータセットにおいて、各ＩＤのパーソナルデータを、各属性値を成分とするベクトルとして扱うことができる。例えば、図４８において、ＩＤ＝１のパーソナルデータは、「D:Gender:1」、「D:Gender:2」、「D:Age:0-19」、「D:Age:20-34」等の属性値を成分とするベクトル（１，０，０，１，・・・）として扱うことができる。そして、ベクトル間の類似度又は距離を計算することで、パーソナルデータ同士の類似度を計算することができる。なお、ベクトル間の類似度と距離との関係については、類似度が高いほど距離は小さくなり、類似度が低いほど距離は大きくなる。
【０２９０】
そして、図４８に示す第１の情報銀行４ａから受信されたＩＤ＝１〜２０のパーソナルデータと、図４９に示す第２の情報銀行５ａから受信されたＩＤ＝１〜２０のパーソナルデータと、の類似度を計算することで、図５０に示すような類似度行列が得られる。
【０２９１】
図５０に示す類似度行列において、行ラベルである「１  ＩＤ」は、第１の情報銀行４ａのＩＤを意味し、列ラベルである「２  ＩＤ」は第２の情報銀行５ａのＩＤを意味する。すなわち、１  ＩＤ＝ｉ、かつ、２  ＩＤ＝ｊの成分は、第１の情報銀行４ａのＩＤ＝ｉのパーソナルデータと、第２の情報銀行５ａのＩＤ＝ｊのパーソナルデータと、の類似度を示す。
【０２９２】
なお、図５０に示す例では、２つのパーソナルデータ（すなわち、２つのベクトル）の類似度はコサイン類似度として計算されるが、２つのパーソナルデータの類似度の計算方法はこれに限られない。例えば、２つのパーソナルデータの類似度は、ユークリッド距離やマハラノビス距離等のその他の距離や類似度を用いて計算されてもよい。なお、図５０に示す類似度行列では、コサイン類似度は、０〜１の範囲内になるように規格化されていない。
【０２９３】
そして、類似度判定部１２３１は、類似度行列において、類似度が所定のしきい値（以下、類似度しきい値）以上である２つのパーソナルデータを、同一人物のパーソナルデータであるとして互いに紐付ける。
【０２９４】
例えば、図５０に示す例において、類似度が５以上の２つのパーソナルデータを同一人物のパーソナルデータとして特定した場合、以下の３つの組合せが同一人物のパーソナルデータの組合せとなる。
・第１の情報銀行４ａのＩＤ＝２のパーソナルデータ（１  ＩＤ＝２）と、第２の情報銀行５ａのＩＤ＝１０のパーソナルデータ（２  ＩＤ＝１０）
・第１の情報銀行４ａのＩＤ＝１２のパーソナルデータ（１  ＩＤ＝１２）と、第２の情報銀行５ａのＩＤ＝１２（２  ＩＤ＝１２）又は１３（２  ＩＤ＝１３）のパーソナルデータ
・第１の情報銀行４ａのＩＤ＝１８（１  ＩＤ＝１８）のパーソナルデータと、第２の情報銀行５ａのＩＤ＝７（２  ＩＤ＝７）のパーソナルデータ
なお、上記の２番目の組合せのように１つのパーソナルデータに複数のパーソナルデータが紐付く場合がある。このような場合、例えば以下の（１）〜（３）の取扱いが考えられる。
（１）一のパーソナルデータに複数のパーソナルデータが紐づく場合は、前記一のパーソナルデータを含む組合せは除外する。すなわち、一のパーソナルデータに対して一のパーソナルデータが紐付く場合のみその２つのパーソナルデータを同一個人のパーソナルデータであると特定する。
（２）一のパーソナルデータに複数のパーソナルデータが紐付き、前記複数のパーソナルデータの前記一のパーソナルデータとの類似度が互いに異なる場合、前記複数のパーソナルデータのうち前記一のパーソナルデータとの類似度が高い方を優先する。そして、前記複数のパーソナルデータのうち優先されたパーソナルデータと前記一のパーソナルデータとを同一個人のパーソナルデータであると特定する。
（３）一のパーソナルデータに複数のパーソナルデータが紐付き、前記複数のパーソナルデータの前記一のパーソナルデータとの類似度が互いに場合、前記複数のパーソナルデータのうち、前記一のパーソナルデータよりも類似度が高いパーソナルデータがある場合、そちらで紐づけを行う。例えば、上記の例において仮に第２の情報銀行５ａのＩＤ＝１２のパーソナルデータについて、第１の情報銀行４ａのＩＤ＝１２のパーソナルデータよりも類似度が高い別のパーソナルデータが存在する場合、その別のパーソナルデータと第２の情報銀行５ａのＩＤ＝１２のパーソナルデータとを紐付ける等。
【０２９５】
なお、上記（１）〜（３）の少なくとも２つが同時に採用されてもよい。このようにして、類似度判定部１２３１は、複数の情報銀行４ａ〜６ａから受信された複数のパーソナルデータの中から、パーソナルデータの属性値が類似する複数のパーソナルデータを特定する。
【０２９６】
そして、続くＳ６１２の処理において、類似度判定部１２３１によって互いに紐付けられた複数のパーソナルデータは、同一個人のパーソナルデータであるとして、データ送信部３４１によってデータ利用者２ａに送信される。
【０２９７】
［９−３．効果］
以上詳述した第９実施形態によれば、前述した第４実施形態の効果（４ａ）に加え、以下の効果が得られる。
【０２９８】
（９ａ）本実施形態では、仲介装置１２は、複数の情報銀行４ａ〜６ａから取得された複数のパーソナルデータ間の類似度であってパーソナルデータの属性値に基づく類似度を示す類似度行列に基づいて納品データを決定する。特に、仲介装置１２は、類似度行列を重複確認情報として取得する。
【０２９９】
詳しくは、仲介装置１２は、複数の情報銀行４ａ〜６ａから複数のパーソナルデータを取得し、取得された複数のパーソナルデータについて、パーソナルデータの属性値に基づく類似度判定を行う（Ｓ６１１）。そして、仲介装置１２は、類似度判定によって互いに類似していると判定された複数のパーソナルデータを互いに紐付ける（Ｓ６１１）。そして、仲介装置１２は、紐付けられた複数のパーソナルデータに基づく納品データを利用者装置２に送信する。
【０３００】
したがって、互いに紐付けられた複数のパーソナルデータを同一個人に係るパーソナルデータと見做すことで、複数の情報銀行４ａ〜６ａから同一個人に係るパーソナルデータを名寄せすることができる。
【０３０１】
また、本実施形態によれば、第４実施形態のような登録管理者９ａが存在しない時期、すなわち、登録管理者９ａが現れる時期よりも前の時期であっても、複数の情報銀行４ａ〜６ａから同一個人に係るパーソナルデータを名寄せできる。
【０３０２】
（９ｂ）また、第１の情報銀行４ａが管理するパーソナルデータの項目と、第２の情報銀行５ａが管理するパーソナルデータの項目と、が異なる場合、両方の項目が補完されたパーソナルデータのサンプル数を出来るだけ多く得たいというニーズがあり得る。第４実施形態のように情報銀行ＩＤ、情報銀行登録者ＩＤ及び個人ＩＤの３つのＩＤを使用して名寄せを行う場合、真に同一個人に係る複数のパーソナルデータのみ互いに紐付けられる。このため、上記サンプル数が多く得られない場合がある。この点、本実施形態によれば、パーソナルデータを紐付ける際の類似度しきい値を緩めることで、パーソナルデータの多対多の紐付けを許容することができる。その結果、前述したサンプル数を増加させることができる。
【０３０３】
なお、本実施形態では、Ｓ６０１がリクエスト取得部としての処理に相当し、Ｓ６０３が属性要求送信部としての処理に相当し、Ｓ６０４が属性情報取得部としての処理に相当し、Ｓ６０６が調達プラン決定部としての処理に相当し、Ｓ６０９がパーソナルデータ取得部としての処理に相当し、Ｓ６１０が形式処理部としての処理に相当し、Ｓ６１２がデータ送信部としての処理に相当する。
【０３０４】
［１０．他の実施形態］
以上、本開示を実施するための形態について説明したが、本開示は前述の実施形態に限定されることなく、種々変形して実施することができる。
【０３０５】
（１）上記各実施形態では、仲介装置は、複数の情報銀行装置４〜６からパーソナルデータを調達するが、仲介装置がパーソナルデータを調達する情報銀行装置の数はこれに限られない。例えば、上記第１〜第２実施形態において、仲介装置は、複数の情報銀行装置からパーソナルデータを調達せず、１つの情報銀行装置のみからパーソナルデータを調達してもよい。
【０３０６】
（２）上記各実施形態では、パーソナルデータ管理者として情報銀行を例示したが、パーソナルデータ管理者はこれに限られない。例えば、パーソナルデータ管理者は、通信キャリアやクレジットカード会社等、大量の顧客データを保有しているが、情報銀行を専らにしていない事業者であってもよい。このようにパーソナルデータ管理者は、個人から預託されたパーソナルデータを管理するとともに当該パーソナルデータを第三者に提供する事業を営むパーソナルデータ事業者であってもよい。
【０３０７】
（３）上記各実施形態では、仲介装置は、複数の情報銀行装置４〜６から受信された納品データのデータ形式を共通のデータ形式に合わせ、１つのデータに統合してデータ利用者２ａに納品するが、納品の仕方はこれに限られない。例えば、仲介装置は、複数の情報銀行装置４〜６から受信された納品データを共通のデータ形式に合わせなくてもよい。また、仲介装置は、複数の情報銀行装置４〜６からの納品データを１つの納品データに統合しなくてもよい。
【０３０８】
（４）上記各実施形態における調達プランの決定ロジックはあくまで一例であり、他の決定ロジックで調達プランが決定されてもよい。例えば、上記各実施形態では、データ利用者２ａの予算額の範囲内で元データ分布の再現性が最も高いプランが調達プランに決定される。しかし、例えば、予算額を多少（すなわち所定額）オーバーしても元データ分布の再現性が最も高い場合、そのプランが調達プランに決定されてもよい。つまり、予算額と元データ分布の再現性とに基づいて調達プランが決定される場合において、再現性の方を予算額よりも重視するように調達プランが決定されてもよい。一方、上記各実施形態のように予算額の方を再現性よりも重視するように調達プランが決定されてもよい。
【０３０９】
また例えば、情報銀行等のパーソナルデータ管理者がパーソナルデータを拡充するために個人に対してアンケートを実施しているような場合、そのアンケートに回答していない個人のパーソナルデータは欠測データとなる。このようにパーソナルデータ管理者が管理するパーソナルデータに欠測データが含まれている場合、欠測データが最も少なくなるように調達プランが決定されてもよい。
【０３１０】
また例えば、調達されるパーソナルデータの「鮮度」が最も良くなるように調達プランが決定されてもよい。具体的には、仲介装置は、パーソナルデータ管理者や自身の記憶部等からパーソナルデータの最終更新日時の情報を取得し、取得された最終更新日時の情報を基に調達プランを決定してもよい。この場合において例えば、仲介装置は、最新更新日時が新しいパーソナルデータから順に、調達されるパーソナルデータに決定するなどして調達プランを決定してもよい。
【０３１１】
また、或る情報銀行から受信されたメタデータに含まれるデータ価格が極端に安いあるいは極端に高い場合、換言すれば、データ価格が所定のしきい値以下あるいはしきい値以上である場合、そのデータ価格あるいはその情報銀行自体が怪しまれる。その場合、仲介装置は、その極端に安い又は高いデータを避けてパーソナルデータを調達するように調達プランを決定してもよい。また、仲介装置は、極端に安いあるいは極端に高いデータ価格を提示する情報銀行を避けて（つまりその情報銀行以外の情報銀行から）パーソナルデータを調達するように調達プランを決定してもよい。
【０３１２】
また例えば、仲介装置は、価格以外の要素を考慮し、同一の対象条件に合致する複数のパーソナルデータの中から最安値でないパーソナルデータを調達する調達プランを決定してもよい。
【０３１３】
具体的には例えば、仲介装置は、価格以外の要素として、パーソナルデータに含まれる属性のうち、対象条件で指定されていない属性（以下、非指定属性）と、データ利用者２ａのパーソナルデータの利用目的等（ひいてはリクエスト情報）と、の適合度を考慮し、調達するパーソナルデータを決定してもよい。
【０３１４】
例えば、仲介装置が、性別が男性であり、年代が２０代であるという対象条件を含むリクエスト情報を利用者装置２から受信したとする。そして、仲介装置は、上記対象条件に合致するパーソナルデータに係るメタデータを各情報銀行４ａ〜６ａから受信する。このとき、リクエスト情報に含まれる利用組織の情報から、データ利用者２ａが飲食関係の業種（例えば食品メーカ）であることが特定されるとする。そして、第１の情報銀行４ａが保有するパーソナルデータには性別、年代以外の属性（すなわち、非指定属性）として、飲食に関する属性（食事ログなど）が含まれているとする。他方、第２の情報銀行５ａが保有するパーソナルデータには非指定属性として飲食に関する属性が含まれていないとする。この場合、仲介装置は、第１の情報銀行４ａのパーソナルデータの方がデータ利用者２ａの利用組織や利用目的等との適合度が高いと判断し、価格が第２の情報銀行５ａのデータより高くても、第１の情報銀行４ａのデータを調達する調達プランを決定してもよい。
【０３１５】
また例えば、仲介装置は、データ利用者の業種と、情報銀行４ａ〜６ａにデータを預託した個人の業種とが同じ場合には、データ利用者がその個人のデータを入手できないようにしてもよい。換言すれば、仲介装置は、その個人のパーソナルデータを除外して調達プランを決定してもよい。つまり、仲介装置は、データ利用者と、情報銀行４ａ〜６ａにデータを預託した個人と、の関係性に基づいて調達プランを決定してもよい。また、その他の価格以外の要素を考慮し、調達プランが決定されてもよい。
【０３１６】
また例えば、仲介装置は、調達プランを決定するための条件（換言すれば、調達プランの決定ロジック）に関する要望をデータ利用者２ａから取得し、取得された要望に基づいて調達プランを決定してもよい。
【０３１７】
また、仲介装置は、複数のプランの中からデータ利用者２ａに適した調達プランを選択するのではなく、データ利用者２ａに適した一の調達プランをいきなり出力してもよい。
【０３１８】
（５）図５に例示されたリクエスト情報の具体例や図６、図７に例示されたメタデータ要求の具体例等はあくまで一例であり、リクエスト情報等は、図５等に示す項目の一部のみ含んでいてもよく、図５等に例示されていない他の項目を含んでいてもよい。
【０３１９】
（６）或る情報銀行からのメタデータは、その情報銀行が保有する全てのパーソナルデータの属性を示す情報であってもよく、また、一部のパーソナルデータのみの属性を示す情報であってもよい。また、メタデータは、パーソナルデータの一部の属性を示すものに限られず、パーソナルデータの全ての属性を示すデータであってもよい。
【０３２０】
（７）上記第２実施形態では、記憶部７２にはメタデータセットが記憶されているが、記憶部７２に記憶されるデータはこれに限られない。例えば、記憶部７２には、各情報銀行装置４〜６の特徴を表す情報である情報銀行特徴情報が記憶されてもよい。情報銀行特徴情報は、具体的には例えば、第１情報銀行４ａは２０代〜４０代の女性のパーソナルデータを多く管理している、第２情報銀行５ａは家族持ちユーザのパーソナルデータを多く管理している、第３情報銀行３ａは６０歳以降のシニア層のユーザのパーソナルデータを多く管理している、等である。この場合において例えば、仲介装置が利用者装置２から家族持ちユーザのパーソナルデータを欲する旨のリクエスト情報を受信した場合に、家族持ちユーザのパーソナルデータを多く管理する第２情報銀行５ａにメタデータ要求やデータ要求を送信してもよい。そして、仲介装置は、第２情報銀行５ａからパーソナルデータを調達する調達プランを決定してもよい。また逆に、仲介装置は、利用者装置２から家族持ちユーザのパーソナルデータを欲する旨のリクエスト情報を受信した場合に、家族持ちユーザのパーソナルデータをあまり管理していない情報銀行を避けるように、メタデータ要求やデータ要求を送信してもよい。
【０３２１】
すなわち、仲介装置は、情報銀行特徴情報に基づいて、リクエスト情報に含まれる対象条件に適合する特徴を有すると判断した情報銀行（ひいてはパーソナルデータ管理者）に対してメタデータ要求及び／又はデータ要求を送信してもよい。また、仲介装置は、情報銀行特徴情報に基づいて、リクエスト情報に含まれる対象条件に適合する特徴を有しないと判断した情報銀行（ひいてはパーソナルデータ管理者）に対してメタデータ要求及び／又はデータ要求を送信しなくてもよい。
【０３２２】
なお、仲介装置は、情報銀行特徴情報を自身の記憶部７２から取得するのではなく、各情報銀行４ａ〜６ａに対して問い合わせることで各情報銀行４ａ〜６ａから情報銀行特徴情報を取得してもよい。
【０３２３】
なお、情報銀行特徴情報は、各パーソナルデータ管理者の特徴を表す情報である管理者特徴情報に相当する。また、管理者特徴情報は、パーソナルデータ管理者が管理するパーソナルデータの属性を示す情報である属性情報である。
【０３２４】
（８）更新処理部７３２，９３２が実行する更新処理の内容は、上記第２及び第５実施形態のものに限られない。
【０３２５】
例えば、上記第２実施形態において、更新処理部７３２は、記憶部７２に記憶されているメタデータセットを、情報銀行４ａ〜６ａから調達されたパーソナルデータに基づいて更新してもよい。具体的には例えば、情報銀行４ａ〜６ａから調達されたパーソナルデータ（すなわち購入されたパーソナルデータ）については、そのパーソナルデータの属性（すなわちデータの内容）がわかる。更新処理部７３２は、調達されたパーソナルデータの内容に基づき、調達先の情報銀行４ａ〜６ａが保有しているパーソナルデータの属性に基づく分布を更新するなどして、記憶部７２に記憶されているメタデータセットを更新してもよい。
【０３２６】
同様に、上記第５実施形態において、更新処理部９３２は、記憶部１１２に記憶されている重複状況テーブルを、情報銀行４ａ〜６ａから調達されたパーソナルデータに基づいて更新してもよい。具体的には例えば、仲介装置が、複数の情報銀行４ａ〜６ａから対象条件に合致するパーソナルデータを調達（すなわち購入）したとする。その際、仲介装置は、購入された複数のパーソナルデータの属性（すなわちデータの内容）を互いに比較し、購入された複数のパーソナルデータが同一個人に係るパーソナルデータであるか否かをデータの内容の類似度等から判断する。そして、仲介装置は、同一個人に係るパーソナルデータと判断した複数のパーソナルデータについては同一の個人ＩＤを設定し、図３５に示す重複状況テーブルにデータを新たに追加してもよい。
【０３２７】
（９）上記第５実施形態において、仲介装置は、管理者装置９に重複確認を行わず、記憶部１１２に記憶された重複状況テーブルに基づき重複確認を行うが、以下のような場合に管理者装置９に対し、重複確認を行ってもよい。
【０３２８】
すなわち、仲介装置は、ＩＤ受信部８３３により受信されたＩＤ結果情報に含まれる各情報銀行登録者ＩＤについて、記憶部１１２に記憶されている重複状況テーブルで重複状況を確認する。このとき、重複状況テーブルに該当する情報銀行登録者ＩＤがない場合など、記憶部１１２に記憶されている重複状況テーブルでは重複状況が確認できない情報銀行登録者ＩＤが存在する場合がある。この場合、仲介装置は、重複状況が不明な情報銀行登録者ＩＤについてのみ、管理者装置９に重複状況を問い合わせてもよい。そして、管理者装置９から受信された重複結果情報に基づき、重複状況が不明な情報銀行登録者ＩＤのデータを登録するなどして重複状況テーブルを更新してもよい。
【０３２９】
（１０）上記第３〜第５実施形態では、仲介装置は、ＩＤ結果情報に含まれる情報銀行登録者ＩＤについて管理者装置９に問い合わせることにより、又は、記憶部１１２に記憶された重複状況テーブルを参照することにより、前記ＩＤについて重複確認を行う。そして、仲介装置は、重複確認の結果を踏まえて、各情報銀行４ａ〜６ａにメタデータ要求を送信する。しかし、重複確認を行うタイミングはこれに限られない。
【０３３０】
例えば、第３実施形態において、仲介装置は、ＩＤ要求を各情報銀行４ａ〜６ａに送信せず、メタデータ要求を各情報銀行４ａ〜６ａに送信する。ここで、仲介装置は、各情報銀行４ａ〜６ａから、同一個人のデータの重複を許容した形でメタデータを受信する。
【０３３１】
このとき、仲介装置は、メタデータと併せて、各情報銀行４ａ〜６ａから、メタデータにデータが含まれている個人に係る情報銀行登録者ＩＤのリストを受信する。
【０３３２】
そして、仲介装置は、受信された情報銀行登録者ＩＤのリストについて、管理者装置９に対して重複確認要求を行う。このように、メタデータ受信後に、重複確認が行われてもよい。
【０３３３】
（１１）上記第３〜第６実施形態では、仲介装置は、図２８に示すような情報銀行登録者ＩＤ及び価格の組のリストを含むＩＤ結果情報を受信するが、ＩＤ結果情報はこれに限られない。例えば、登録管理者９ａの管理者装置９が、図３５に示すような、価格情報を含む重複状況テーブルを保有していてもよい。この場合、図３５に示すような、価格情報を含む重複状況テーブルを保有していてもよい。その場合には、図２８に示すＩＤ結果情報には情報銀行登録者ＩＤのリストのみが含まれていてもよい。また、図３０に示す重複結果情報には（｛ＩＤ，価格｝，｛ＩＤ，価格｝，｛ＩＤ，価格｝…）といった形の、各情報銀行４ａ〜６ａについての情報銀行登録者ＩＤと価格との組のリストが含まれていてもよい。そして、例えば仲介装置は、受信されたリストに基づき、最安値以外のＩＤについてはメタデータにおいて除外ＩＤとして指定してもよい。
【０３３４】
（１２）上記第３〜第６実施形態では、登録識別情報として、情報銀行４ａ〜６ａにパーソナルデータを預託した個人を識別する情報である情報銀行登録者ＩＤを例示したが、登録識別情報はこれに限られない。登録識別情報は、例えば、各情報銀行４ａ〜６ａが当該情報銀行４ａ〜６ａに預託されたパーソナルデータに付与する識別情報であってもよい。
【０３３５】
（１３）上記第６実施形態では、通知情報として広告情報を例示したが、通知情報はこれに限られない。例えば、通知情報は、個人に商品やサービスをレコメンドするレコメンド情報等であってもよい。
【０３３６】
（１４）上記第６実施形態では、広告情報の送信先情報が、情報銀行４ａ〜６ａから取得されたパーソナルデータに含まれていることが想定される。しかし、例えば、送信先情報が情報銀行４ａ〜６ａから取得されたパーソナルデータに含まれていない場合等において、次のように広告配信が行われてもよい。
【０３３７】
すなわち、利用者装置２等の広告配信装置は、配信対象者別の広告情報などの通知情報を仲介装置を介して間接的に又は仲介装置を介さず直接的に情報銀行４ａ〜６ａに送信する。そして、情報銀行４ａ〜６ａが、パーソナルデータを預託した個人に対し、広告配信装置から受信した通知情報を送信してもよい。つまり、利用者装置２等の広告配信装置は、情報銀行４ａ〜６ａを通じて、パーソナルデータを預託した個人に対して広告配信を行ってもよい。
【０３３８】
この場合において、情報銀行４ａ〜６ａは、自身が持つ、パーソナルデータを預託した個人との何らか接点を利用して広告配信を行ってもよい。
【０３３９】
具体的には例えば、情報銀行４ａ〜６ａの情報銀行装置４〜６は、パーソナルデータを預託した個人の情報処理端末１１〜１７に対して電子メールで通知情報を送信してもよく、個人が閲覧するインターネットのウェブサイトに通知情報を出力させてもよい。また例えば、情報銀行装置４〜６は、個人の情報処理端末１１〜１７にインストールされたアプリケーションソフトウェア内で通知情報を出力させてもよく、個人が来店する店頭などのエリアに設置された端末に通知情報を出力させてもよく、その他種々の方法で通知情報を個人に対して送信してもよい。
【０３４０】
このような構成によれば、データ利用者２ａ等が取得したパーソナルデータに送信先情報が含まれていなくても、データ利用者２ａ等は、個人に対し、広告配信を行うことができる。
【０３４１】
（１５）上記第６実施形態では、利用者装置２が広告配信を行うが、広告配信を行う主体はこれに限られない。例えば、広告代理店等の広告配信事業者や広告配信を行うプラットフォーマーなどの、データ利用者２ａとは別の者が保有する装置が広告配信を行ってもよく、仲介装置が広告配信を行ってもよい。この場合において、広告配信事業者やプラットフォーマーが保有する装置や仲介装置などが図４０に示す広告配信処理を行ってもよい。
【０３４２】
（１６）また例えば、前述した［７．他の実施形態］の（１４）で述べたように、仲介装置等が、情報銀行４ａ〜６ａにパーソナルデータを預託した個人に情報銀行４ａ〜６ａを介して広告配信を行う場合などにおいて、仲介装置等は広告成果指標を計算してもよい。ここでいう広告成果指標とは、広告配信に関する成果を示す指標である。
【０３４３】
具体的には例えば、仲介装置は、登録管理者９ａの管理者装置９から取得された重複結果情報を利用して、広告成果指標としてのユニークユーザ数を計算してもよい。ユニークユーザ数は、広告配信が行われたユーザの数である。
【０３４４】
すなわち、各情報銀行４ａ〜６ａが、当該情報銀行４ａ〜６ａにデータを預託している個人に対して広告配信を行う場合、複数の情報銀行４ａ〜６ａにパーソナルデータを預託している個人については、複数の情報銀行４ａ〜６ａから同一の広告情報が送信される場合がある。このような場合でも、重複結果情報を利用すれば、いずれの個人に対して広告情報が重複して配信されたかがわかるため、ユニークユーザ数を計算することができる。また、仲介装置は、重複結果情報を利用して、ユニークユーザ数以外の広告成果指標を計算してもよい。
【０３４５】
また例えば、仲介装置等は、情報銀行４ａ〜６ａを介して広告配信を行う場合等において、重複結果情報に基づいて広告配信を行ってもよい。具体的には例えば、仲介装置等は、同一の広告情報が同一人物に複数の情報銀行４ａ〜６ａから重複して送信されないように、複数の情報銀行装置４〜６のうちの一の情報銀行装置以外には配信内容と共に除外ＩＤを送信する。ここで、情報銀行装置４〜６は、受信された除外ＩＤで指定される情報銀行登録者ＩＤに係る個人に対しては、広告配信を行わない。このようにすることで、前記一の情報銀行装置以外の情報銀行装置が広告配信を行わないようにしてもよい。もちろん、重複結果情報を用いたその他の方法で、同一の広告情報が同一人物に重複して送信されないようにしてもよい。
【０３４６】
（１７）上記第９実施形態では、類似度しきい値は一定に設定されるが、類似度しきい値はこれに限られず、類似度しきい値を変動させてもよい。この場合において例えば、類似度しきい値は次のように変動してもよい。
【０３４７】
すなわち、図５１に示すように、類似度しきい値ｔを連続的に変化させると紐付け成功数が変化する。紐付け成功数とは、互いに類似していると判断され、互いに紐付けられるパーソナルデータの組合せの数である。
【０３４８】
図５１から見て取れるように、類似度しきい値ｔが大きくなるほど紐付け成功数が減少する。そのため、類似度しきい値ｔを大きく設定しすぎると、本来同一個人のパーソナルデータの組合せと見做すべきパーソナルデータの組合せを、同一個人のパーソナルデータの組合せでないとして、取りこぼす可能性がある。また逆に、類似度しきい値ｔを小さく設定しすぎると、同一個人に由来しないパーソナルデータ同士の組合せが多数発生する可能性がある。このため、類似度しきい値ｔを大きく設定しすぎず、かつ、小さく設定しすぎないことが望ましいと考えられる。
【０３４９】
このような考え方の下、例えば、図５１に示すように類似度しきい値ｔを連続的に変化させたときに、紐付け成功数の変化が最大になる類似度しきい値ｔの値ｔＭＡＸを最適なしきい値として採用することが考えられる。ｔＭＡＸは、換言すれば、紐付け成功数ｎを類似度しきい値ｔの関数ｎ＝ｆ（ｔ）と見做したときの関数ｎ＝ｆ（ｔ）の接線の傾きが最小となる類似度しきい値ｔの値である。
【０３５０】
また、ｔＭＡＸの値が小さい場合など、類似度しきい値ｔをｔＭＡＸに設定してパーソナルデータの紐付けを行うと、同一個人に由来しないパーソナルデータ同士の組合せが多数発生してしまう場合がある。このような場合、ｔＭＡＸの次に紐付け成功数の変化が大きい類似度しきい値ｔの値、換言すれば、関数ｎ＝ｆ（ｔ）の接線の傾きが２番目に小さくなる類似度しきい値ｔの値ｔ２ＭＡＸを最適なしきい値として採用してもよい。もちろん、接線の傾きが３番目、４番目、・・・に小さい値を最適なしきい値ｔとして採用してもよい。
【０３５１】
なお、類似度しきい値ｔをｔＭＡＸ、ｔ２ＭＡＸ、・・・等のうちのいずれに設定するかはユーザによって設定されてもよく、また、システムによって自動的に設定されてもよい。
【０３５２】
また例えば、複数のパーソナルデータが互いに類似しているか否かを、次のように判定してもよい。すなわち、パーソナルデータの年齢や性別等の属性（換言すれば、パーソナルデータのデータ項目）ごとにパーソナルデータ同士の類似度を計算する。そして、全部又は一部の属性について類似度がしきい値以上であると判定される場合に、複数のパーソナルデータが互いに類似していると判定されてもよい。
【０３５３】
また例えば、以下に詳述するように、パーソナルデータのデータ項目に対応する座標軸を有し、各パーソナルデータを点やベクトルなどとして表現する座標空間において新たな座標軸を設定する。そして、設定された各座標軸についての類似度がしきい値以上である場合に、複数のパーソナルデータが互いに類似している、ひいては、同一個人に係るパーソナルデータであると判定されてもよい。そして、例えば、上記と同様に類似度しきい値を変動させ、最適な類似度しきい値を求めてもよい。具体的には以下のように類似度しきい値を求めてもよい。
【０３５４】
すなわち、図５２に示すように、まず、情報銀行４ａ〜６ａから取得されたパーソナルデータのデータセットを座標空間にプロットする。図５２において各データ点はパーソナルデータを表す。また、図５２の座標空間の各座標軸はパーソナルデータの各属性（すなわち、各データ項目）に対応する。例えば「性別＝男性」というデータ項目に対応する座標軸については、各パーソナルデータは、男性に該当するか否かに応じて０又は１の値を取る。また、「３ヶ月雑誌購買金額」というデータ項目に対応する座標軸については、各パーソナルデータは、該当する購入金額に値を取る。
【０３５５】
そして、前記データセットに対して、主成分分析や多様体学習を行うことで、データセットをより良く記述する新たな座標軸を構成する。図５２では、ｘ１座標軸及びｘ２座標軸が新たな座標軸である。
【０３５６】
そして、新たな座標軸ごとに類似度しきい値ｔ＝（ｔ１，ｔ２，・・・）を設定する。ここでいう類似度しきい値ｔは、例えば、２つのパーソナルデータの各成分の属性値の差分に関するしきい値であってもよい。具体的には例えば、或るパーソナルデータＡが前記新たな座標軸で座標ｘＡ＝（ｘ１Ａ，ｘ２Ａ，・・・）で表現され、別のパーソナルデータＢが新たな座標軸で座標ｘＢ＝（ｘ１Ｂ，ｘ２Ｂ，・・・）で表現されるとする。この場合、２つのパーソナルデータＡ，Ｂは、以下のように、各成分の差分の絶対値が類似度しきい値以下である場合に互いに類似していると判定されてもよい。
Δｘ１≡｜ｘ１Ａ−ｘ１Ｂ｜≦ｔ１  かつ  Δｘ２≡｜ｘ２Ａ−ｘ２Ｂ｜≦ｔ２・・・
そして、図５３に示すように、類似度しきい値ｔ＝（ｔ１，ｔ２，・・・）の各成分ｔｉを連続的に変化させたときに、紐付け成功数ｎの変化が最大に類似度しきい値ｔＭＡＸ＝（ｔＭＡＸ１，ｔＭＡＸ２，・・・）等を最適なしきい値として採用してもよい。
【０３５７】
このように類似度しきい値ｔを動的に変化させることで、パーソナルデータのデータセットごとに最適な類似度しきい値ｔを設定することができる。ひいては、同一個人のパーソナルデータの組合せと見做すべきパーソナルデータの組合せを取りこぼしたり、同一個人に由来しないパーソナルデータ同士の組合せを多数発生させたりする可能性を低減することができる。
【０３５８】
なお、上記のように主成分分析や多様体学習を行い新たな座標軸を設定することは必須ではない。しかし、新たな座標軸を設定することで一般に各パーソナルデータを少ない次元の座標として表現でき得る。このため、コンピュータ処理において計算量を低減でき、ひいては処理を高速化できる。
【０３５９】
（１８）上記各実施形態では、仲介装置は、情報銀行４ａ〜６ａから取得されたパーソナルデータに基づく納品データを直接利用者装置２に送信する。しかし、データ利用者２ａに納品データを送信する仕方はこれに限られない。例えば、仲介装置が一旦納品データを仲介装置及び利用者装置のいずれでもない別の装置に送信する。そして、当該別の装置を介して納品データが利用者装置２に送信されてもよい。このように別の装置を経由して仲介装置から利用者装置２に納品データが送信される場合も、本願でいう「仲介装置が利用者装置２に納品データを送信する」に包含されるものとする。
【０３６０】
（１９）前述した仲介装置の他、当該仲介装置を構成要素とするシステム、当該仲介装置としてコンピュータを機能させるためのプログラム、このプログラムを記憶した半導体メモリ等の非遷移的実体的記憶媒体、パーソナルデータを調達する方法など、種々の形態で本開示を実現することもできる。
【０３６１】
（２０）上記各実施形態における１つの構成要素が有する複数の機能を、複数の構成要素によって実現したり、１つの構成要素が有する１つの機能を、複数の構成要素によって実現したりしてもよい。また、複数の構成要素が有する複数の機能を、１つの構成要素によって実現したり、複数の構成要素によって実現される１つの機能を、１つの構成要素によって実現したりしてもよい。また、上記各実施形態の構成の一部を省略してもよい。また、上記各実施形態の構成の少なくとも一部を、他の上記各実施形態の構成に対して付加又は置換してもよい。なお、請求の範囲に記載した文言によって特定される技術思想に含まれるあらゆる態様が本開示の実施形態である。
【図１】
0006944068.tif 000002
【図２】
0006944068.tif 000003
【図３】
0006944068.tif 000004
【図４】
0006944068.tif 000005
【図５】
0006944068.tif 000006
【図６】
0006944068.tif 000007
【図７】
0006944068.tif 000008
【図８】
0006944068.tif 000009
【図９】
0006944068.tif 000010
【図１０】
0006944068.tif 000011
【図１１】
0006944068.tif 000012
【図１２】
0006944068.tif 000013
【図１３】
0006944068.tif 000014
【図１４】
0006944068.tif 000015
【図１５】
0006944068.tif 000016
【図１６】
0006944068.tif 000017
【図１７】
0006944068.tif 000018
【図１８】
0006944068.tif 000019
【図１９】
0006944068.tif 000020
【図２０】
0006944068.tif 000021
【図２１】
0006944068.tif 000022
【図２２】
0006944068.tif 000023
【図２３】
0006944068.tif 000024
【図２４】
0006944068.tif 000025
【図２５】
0006944068.tif 000026
【図２６】
0006944068.tif 000027
【図２７】
0006944068.tif 000028
【図２８】
0006944068.tif 000029
【図２９】
0006944068.tif 000030
【図３０】
0006944068.tif 000031
【図３１】
0006944068.tif 000032
【図３２】
0006944068.tif 000033
【図３３】
0006944068.tif 000034
【図３４】
0006944068.tif 000035
【図３５】
0006944068.tif 000036
【図３６】
0006944068.tif 000037
【図３７】
0006944068.tif 000038
【図３８】
0006944068.tif 000039
【図３９】
0006944068.tif 000040
【図４０】
0006944068.tif 000041
【図４１】
0006944068.tif 000042
【図４２】
0006944068.tif 000043
【図４３】
0006944068.tif 000044
【図４４】
0006944068.tif 000045
【図４５】
0006944068.tif 000046
【図４６】
0006944068.tif 000047
【図４７】
0006944068.tif 000048
【図４８】
0006944068.tif 000049
【図４９】
0006944068.tif 000050
【図５０】
0006944068.tif 000051
【図５１】
0006944068.tif 000052
【図５２】
0006944068.tif 000053
【図５３】
0006944068.tif 000054