JP6944070B2 - 仲介装置、システム及びコンピュータプログラム - Google Patents

Description

関連出願の相互参照

本国際出願は、２０１９年３月１１日に日本国特許庁に出願された日本国特許出願第２０１９−０４３６７４号、２０１９年１０月１５日に日本国特許庁に出願された日本国特許出願第２０１９−１８８９８５号、及び、２０１９年１０月１５日に日本国特許庁に出願された日本国特許出願第２０１９−１８８９８６号、に基づく優先権を主張するものであり、日本国特許出願第２０１９−０４３６７４号、日本国特許出願第２０１９−１８８９８５号及び日本国特許出願第２０１９−１８８９８６号の全内容を本国際出願に参照により援用する。

本開示は、データ利用者とパーソナルデータ管理者との間のパーソナルデータの取引を仲介する仲介装置及びコンピュータを仲介装置として機能させるコンピュータプログラムに関する。

パーソナルデータを管理するパーソナルデータ管理者が知られている。パーソナルデータ管理者としては例えば情報銀行が挙げられる。パーソナルデータ管理者は、パーソナルデータを預託した個人からデータ利用に関するポリシー等を通知され、通知されたポリシー等に従い第三者へのデータ提供の可否を判断する。なお、特許文献１には、データが預けられる情報銀行等が保有する情報処理装置から個人情報等が漏洩するのを防ぐことを目的とした情報処理システムが開示されている。

特許第６３４２０９４号公報

ところで、企業などのパーソナルデータの利用者（以下、データ利用者）がパーソナルデータ管理者からパーソナルデータを調達する場合、データ利用者が欲するパーソナルデータの条件である対象条件をパーソナルデータ管理者に通達することが考えられる。

しかしながら、データ利用者からは、パーソナルデータ管理者がどのようなパーソナルデータを保有しているかが把握しづらい。よって、問合せ先のパーソナルデータ管理者が対象条件に合致するパーソナルデータを十分に保有していないケースも想定される。この場合、データ利用者は、別のパーソナルデータ管理者に問い合わせるなど、再度やり取りが発生する場合がある。この場合、データ利用者がパーソナルデータを調達するに当たり作業負荷が増加し、ひいては、データ利用者が行う通信の通信量が増加する。

また、同一個人が複数のパーソナルデータ管理者にパーソナルデータを預託する場合が想定される。この場合、データ利用者やパーソナルデータ管理者は、パーソナルデータ管理者に預託されているいずれのデータが同一個人のデータであるかを把握できない。このため、データ利用者が複数のパーソナルデータ管理者からパーソナルデータを調達する場合、パーソナルデータの二重購入が発生し得る。ここでいう二重購入は、同一人物のパーソナルデータを異なる経路で２度購入することを意味する。データ利用者は、このような二重購入を避けてパーソナルデータを調達したいと考えることが想定される。

本開示の一局面は、同一個人が複数のパーソナルデータ管理者にデータを預託する状況下で発生するデータ利用者のニーズを満たしつつ、データ利用者が欲するパーソナルデータの調達をより容易に行うことを可能にし、かつ、データ利用者が行う通信の通信量を低減し得る技術を提供することにある。

本開示の一態様は、仲介装置であって、リクエスト取得部と、重複確認取得部と、決定部と、取得送信部と、を備える。リクエスト取得部は、リクエスト情報を取得する。重複確認取得部は、重複確認情報を取得する。重複確認情報は、第１のパーソナルデータ管理者により管理されている第１のパーソナルデータと、第１のパーソナルデータ管理者とは異なる第２のパーソナルデータ管理者により管理されている第２のパーソナルデータと、が同一個人に係るパーソナルデータであることを示す情報である。決定部は、重複確認情報に基づいて調達プラン及び／又は納品データを決定する。調達プランは、第１のパーソナルデータ管理者及び第２のパーソナルデータ管理者を含む複数のパーソナルデータ管理者から調達するパーソナルデータに関する条件を示す。納品データは、複数のパーソナルデータ管理者から調達されたパーソナルデータに基づくデータであってデータ利用者が保有する利用者装置に送信されるデータである。取得送信部は、決定部によって決定された調達プランに従いパーソナルデータを取得する、及び／又は、決定部によって決定された納品データを利用者装置に送信する。

このような構成によれば、重複確認情報に基づき決定された調達プランに従いパーソナルデータが調達される。及び／又は、重複確認情報に基づき決定された納品データが利用者装置に送信される。したがって、同一個人が複数のパーソナルデータ管理者にデータを預託する状況下で発生するデータ利用者のニーズを満たすことができる。また、仲介装置がデータ利用者に代わり複数のパーソナルデータ管理者からデータを調達するため、データ利用者が欲するパーソナルデータの調達をより容易に行うことができ、かつ、データ利用者が行う通信の通信量を低減できる。

本開示の一態様では、決定部は、重複確認情報に基づいて調達プランを決定してもよい。

このような構成によれば、重複確認情報に基づき決定された調達プランに従いパーソナルデータが調達される。したがって、同一個人が複数のパーソナルデータ管理者にデータを預託する状況下で発生するデータ利用者のニーズを満たすことができる。

本開示の一態様では、決定部は、重複確認情報により同一個人に係るパーソナルデータであることが示される第１のパーソナルデータ及び第２のパーソナルデータのうち、いずれか一方を調達する調達プランを決定してもよい。

このような構成によれば、同一個人に係る同一内容のパーソナルデータを複数のパーソナルデータ管理者から重複して購入することを抑制することができる。

本開示の一態様では、決定部は、第１のパーソナルデータ及び第２のパーソナルデータのうち価格が安い方を調達する調達プランを決定してもよい。

このような構成によれば、同一個人に係る同一内容のパーソナルデータを重複して購入することを抑制しつつ、データ利用者がより安い金額でパーソナルデータを購入することができる。

本開示の一態様では、決定部は、重複確認情報により同一個人に係るパーソナルデータであることが示される第１のパーソナルデータ及び第２のパーソナルデータの両方を調達する調達プランを決定してもよい。

このような構成によれば、同一個人が第１のパーソナルデータ管理者と第２のパーソナルデータ管理者とに異なる内容のパーソナルデータを預託している場合において、同一個人のパーソナルデータを複数のパーソナルデータ管理者から名寄せすることができる。

本開示の一態様では、重複確認取得部は、重複確認情報を管理する又は重複確認情報を生成可能な外部装置から重複確認情報を取得してもよい。

このような構成によれば、パーソナルデータの最新の重複状況を反映した重複確認情報を仲介装置が取得しやすい。ひいては、仲介装置が最新の重複状況に基づき調達プランを決定しやすくできる。

本開示の一態様は、仲介装置は、重複確認情報を記憶するように構成された記憶部を更に備えてもよい。重複確認取得部は、記憶部から重複確認情報を取得してもよい。

このような構成によれば、仲介装置は、重複確認情報を管理する外部装置との間でデータのやり取りを行わなくても重複確認情報を取得できる。したがって、仲介装置の通信量を減らすことができる。

本開示の一態様では、複数のパーソナルデータ管理者のそれぞれは、当該パーソナルデータ管理者にパーソナルデータを預託した個人又はそのパーソナルデータに対して所定の識別情報である登録識別情報を付与してもよい。重複確認情報は、同一個人に係る、第１のパーソナルデータ管理者の登録識別情報と、第２のパーソナルデータ管理者の登録識別情報と、を示す情報であってもよい。

このような構成によれば、複数のパーソナルデータ管理者が同一個人に係るパーソナルデータを異なる登録識別情報で管理している場合において、仲介装置は、いずれのパーソナルデータが同一個人に係るパーソナルデータであるのかを把握できる。よって、仲介装置は、把握した結果を踏まえ、調達プランを決定することができる。

本開示の一態様では、重複確認取得部は、複数の情報銀行から取得された複数のパーソナルデータ間の類似度を示す類似度情報を重複確認情報として取得してもよい。

このような構成によれば、重複確認情報を管理する外部装置との間でデータのやり取りを行わなくても重複確認情報を取得でき得る。したがって、仲介装置の通信量を減らすことができる。

本開示の一態様では、パーソナルデータ管理者は情報銀行であってもよい。

本開示の一態様は、前記仲介装置を備えるシステムであって、通知情報取得部と、通知情報送信部と、を備えるシステムであってもよい。通知情報取得部は、取得送信部によって取得されたパーソナルデータに応じた通知情報を取得するように構成される。通知情報は、パーソナルデータ管理者にパーソナルデータを預託した個人に通知される情報である。通知情報送信部は、通知情報取得部によって取得された通知情報を送信するように構成される。

このような構成によれば、パーソナルデータ管理者から取得されたパーソナルデータを使って通知情報を送信する。したがって、パーソナルデータを預託した個人に対し、その個人に適した通知情報を送信することができる。

本開示の別の態様は、コンピュータプログラムであって、コンピュータを前記仲介装置として機能させる。このような構成によれば、前述した仲介装置と同様の効果を奏する。

図１は第１実施形態の調達システムの構成を示す図である。 図２は第１〜第５実施形態の仲介装置のハードウェア構成を示すブロック図である。 図３は第１実施形態の仲介装置の機能的構成を示すブロック図である。 図４は第１実施形態のデータ調達処理のフローチャートである。 図５はリクエスト情報を説明するための図である。 図６は第１情報銀行に対する第１実施形態のメタデータ要求を説明するための図である。 図７は第２情報銀行に対する第１実施形態のメタデータ要求を説明するための図である。 図８Ａは第１情報銀行のカテゴリテーブルマスタを示す図、図８Ｂは第２情報銀行のカテゴリテーブルマスタを示す図である。 図９は第１実施形態のメタデータを説明するための図である。 図１０はパーソナルデータの調達プランを決定するロジックの一例を説明するための図である。 図１１は第１情報銀行に対するデータ要求を説明するための図である。 図１２は第２情報銀行に対するデータ要求を説明するための図である。 図１３は情報銀行からの納品データを説明するための図である。 図１４は標準辞書を説明するための図である。 図１５は第１情報銀行のデータ変換用辞書を説明するための図である。 図１６Ａは第１情報銀行からの納品データを示す図、図１６Ｂは第２情報銀行からの納品データを示す図である。 図１７は第１情報銀行からの変換後の納品データを示す図である。 図１８は第２情報銀行からの変換後の納品データを示す図である。 図１９は各情報銀行装置からの納品データを統合することで生成された統合データを説明するための図である。 図２０は第２実施形態の仲介装置の機能的構成を示すブロック図である。 図２１は第２実施形態のデータ調達処理のフローチャートである。 図２２は第３実施形態の調達システムの構成を示す図である。 図２３は管理者装置のハードウェア構成を示すブロック図である。 図２４は管理者装置９が保有する重複管理テーブルを説明するための図である。 図２５は第３及び第４実施形態の仲介装置の機能的構成を示すブロック図である。 図２６は第３及び第４実施形態のデータ調達処理のフローチャートである。 図２７はＩＤ要求を説明するための図である。 図２８はＩＤ結果情報を説明するための図である。 図２９は重複確認要求を説明するための図である。 図３０は重複結果情報を説明するための図である。 図３１は第３実施形態のメタデータ要求を説明するための図である。 図３２は第１の情報銀行に対する第４実施形態のメタデータ要求を説明するための図である。 図３３は第２の情報銀行に対する第４実施形態のメタデータ要求を説明するための図である。 図３４は、同一個人のパーソナルデータが名寄せされた統合データを示す図である。 図３５はパーソナルデータの価格情報を含む重複状況テーブルを示す図である。 図３６は第５実施形態の仲介装置の機能的構成を示すブロック図である。 図３７は第５実施形態のデータ調達処理のフローチャートである。 図３８は第６実施形態の調達システムの構成を示す図である。 図３９は広告配信を行う装置のハードウェア構成を示すブロック図である。 図４０は広告配信処理のフローチャートである。 図４１は第７及び第８実施形態のデータ調達処理のフローチャートである。 図４２は第７実施形態のメタデータ要求を説明するための図である。 図４３は匿名加工処理が施された、第１の情報銀行からの納品データを示す図である。 図４４は第８実施形態のメタデータ要求を説明するための図である。 図４５は統計情報化が施された、第１の情報銀行からの納品データを示す図である。 図４６は第９実施形態の仲介装置の機能的構成を示すブロック図である。 図４７は第９実施形態のデータ調達処理のフローチャートである。 図４８は第９実施形態における第１情報銀行からの変換後の納品データを示す図である。 図４９は第９実施形態における第２情報銀行からの変換後の納品データを示す図である。 図５０は複数のパーソナルデータ同士の類似度を示す類似度行列を示す図である。 図５１は類似度しきい値と紐付け成功数との関係を示すグラフである。 図５２はパーソナルデータをデータ点として表現する座標空間を示す図である。 図５３は多次元に拡張された、類似度しきい値と紐付け成功数との関係を示すグラフである。

１…調達システム、２…利用者装置、２ａ…データ利用者、
３，７，８，１１，１２…仲介装置、４〜６…情報銀行装置、４ａ〜６ａ…情報銀行、
９…管理者装置、９ａ…登録管理者、３３，７３，８３，１１３…制御部、
３３１…リクエスト取得部、３３２…メタデータ要求生成部、
３３３…メタデータ要求送信部、３３４…メタデータ受信部、３３５…条件整理部、
３３６…調達プラン決定部、３３７…データ要求生成部、３３８…データ要求送信部、
３３９…データ受信部、３４０…形式処理部、３４１…データ送信部、
７３１…メタデータ取得部、７３２…更新処理部、８３１…ＩＤ要求生成部、
８３２…ＩＤ要求送信部、８３３…ＩＤ受信部、８３４…重複確認生成部、
８３５…重複確認送信部、８３６…重複確認受信部、９３１…重複確認取得部、
９３２…更新処理部、１２３１…類似度判定部

以下、図面を参照しながら、本開示を実施するための形態を説明する。

［１．第１実施形態］
［１−１．全体構成］
図１に示す調達システム１は、利用者装置２、仲介装置３及び複数の情報銀行装置４〜６を備える。

利用者装置２は、パーソナルデータを利用するデータ利用者２ａが保有する装置である。データ利用者２ａは、パーソナルデータを利用して利益を上げる企業等である。

ここで、本実施形態でいうパーソナルデータは、個人の識別性の有無にかかわらず、個人に関する情報全般を指す。パーソナルデータには、個人を特定、識別することができる個人情報が含まれる。ここでいう個人情報は、例えば、日本国個人情報保護法第２条第１項に規定の「個人情報」である。個人情報には、その情報自体で個人を識別できる情報のほか、他の情報と照合することができ、それにより個人を識別できる情報も含まれる。個人情報以外のパーソナルデータとしては、個人の位置情報や購入情報、ＩＰアドレス、インターネット閲覧履歴など、企業やネット上に集積されている情報等が挙げられる。また、個人情報以外のパーソナルデータとして、個人に結び付けることができないように加工された個人の行動や状態などに関するデータ等が挙げられる。

利用者装置２は、インターネット、専用無線／有線通信回線網のようなネットワークを介して仲介装置３に接続される。

仲介装置３は、データ利用者２ａに代わって、情報銀行装置４〜６に対してパーソナルデータのリクエストを行い、データ利用者２ａに適した条件でパーソナルデータを買い付けてデータ利用者２ａに納品するための装置である。仲介装置３は、例えば、データ利用者２ａと情報銀行４ａ〜６ａとの間のパーソナルデータの売買の仲介を行う業者により保有される。仲介装置３は、インターネット、専用無線／有線通信回線網のようなネットワークを介して利用者装置２及び情報銀行装置４〜６に接続される。仲介装置３のハードウェア構成及び機能については後で詳述する。

情報銀行装置４〜６は、それぞれ別々の情報銀行４ａ〜６ａに保有されている。情報銀行４ａ〜６ａは、個人から預託されたパーソナルデータを管理するとともに当該パーソナルデータを企業等の第三者に提供する事業を営む。

情報銀行装置４〜６には、個人が保有するスマートフォン、タブレット端末、パーソナルコンピュータ等の情報処理端末１１〜１７を介して個人から預託されたパーソナルデータが記憶されている。情報銀行装置４〜６は、インターネット、専用無線／有線通信回線網のようなネットワークを介して仲介装置３及び情報処理端末１１〜１７に接続される。後述するとおり、情報銀行装置４〜６は仲介装置３との間で各種情報をやり取りし、仲介装置３を介してパーソナルデータをデータ利用者２ａに納品する。

なお、図１では３つの情報銀行装置４〜６のみが図示されているが、仲介装置３は一般には３つ以外の情報銀行装置とパーソナルデータ等のデータのやり取りを行う。

［１−２．仲介装置］
次に、仲介装置３のハードウェア構成を図２を用いて説明する。仲介装置３は、通信部３１と、記憶部３２と、制御部３３と、を備える。

通信部３１は、仲介装置３をネットワークに接続するための通信インタフェースである。仲介装置３は、通信部３１を介して、利用者装置２及び情報銀行装置４〜６と有線又は無線にてデータ通信可能である。また、仲介装置３は、通信部３１を介してインターネットに接続し、インターネットを介して外部の装置とデータ通信可能であってもよい。

記憶部３２は、各種データを記憶する。

制御部３３は、ＣＰＵ３３ａと、ＲＡＭ、ＲＯＭ、フラッシュメモリ等の半導体メモリ（以下、メモリ３３ｂ）と、を有する周知のマイクロコンピュータを中心に構成される。制御部３３の各種機能は、ＣＰＵ３３ａが非遷移的実体的記憶媒体に格納されたプログラムを実行することにより実現される。この例では、メモリ３３ｂが、プログラムを格納した非遷移的実体的記憶媒体に該当する。また、このプログラムの実行により、プログラムに対応する方法が実行される。なお、制御部３３を構成するマイクロコンピュータの数は１つでも複数でもよい。

制御部３３は、ＣＰＵ３３ａがプログラムを実行することで後述する図４に示すデータ調達処理を実行する。制御部３３はデータ調達処理を実行することで、図３に示すように、リクエスト取得部３３１、メタデータ要求生成部３３２、メタデータ要求送信部３３３、メタデータ受信部３３４、条件整理部３３５、調達プラン決定部３３６、データ要求生成部３３７、データ要求送信部３３８、データ受信部３３９、形式処理部３４０及びデータ送信部３４１として機能する。制御部３３を構成するこれらの要素３３１〜３４１を実現する手法はソフトウェアに限るものではなく、その一部又は全部の要素を、論理回路やアナログ回路等を組み合わせたハードウェアを用いて実現してもよい。

以下では、まず図３を用いて各要素３３１〜３４１の機能の概要について説明する。その後、図４のフローチャートを用いて各要素３３１〜３４１の機能を詳細に説明する。
＜リクエスト取得部＞
リクエスト取得部３３１は、通信部３１を介して利用者装置２からのリクエスト情報を受信する。リクエスト情報は、データ利用者２ａが欲するパーソナルデータの条件である対象条件を含む情報である。リクエスト情報の具体例については後述する。
＜メタデータ要求生成部＞
メタデータ要求生成部３３２は、リクエスト取得部３３１により受信されたリクエスト情報に基づき、情報銀行装置４〜６に送信されるメタデータ要求を生成する。ここでいうメタデータ要求とは、情報銀行装置４〜６にメタデータを要求するための情報である。ここでいうメタデータは、情報銀行４ａ〜６ａが保有するパーソナルデータのうち、リクエスト情報に含まれる対象条件に合致するパーソナルデータの属性を示す情報である。ここでいうパーソナルデータの属性とは、パーソナルデータに係る個人の属性であり、例えば個人の年齢、性別等を意味する。もちろん、パーソナルデータの属性は、年齢及び性別以外の個人の属性であってもよい。換言すれば、パーソナルデータの属性は、当該パーソナルデータに含まれる、個人の年齢、性別等の各種属性を示す各データ項目を意味する。すなわち、パーソナルデータの属性は、パーソナルデータのデータ項目を意味する。

本実施形態では、メタデータは、その情報銀行が保有している、対象条件に合致する全部又は一部のパーソナルデータについてのデータの概要を示す。ここでいうデータの概要は、例えば、パーソナルデータの一部の属性や、パーソナルデータの各属性に関する統計情報等であってもよい。

メタデータは、情報銀行が保有している、対象条件に合致する全部又は一部のパーソナルデータがどのような属性のパーソナルデータから構成されるかを示す情報である。具体的には、後述するとおり、メタデータには、その情報銀行が保有する、対象条件に合致する全部又は一部のパーソナルデータの統計量の情報等が含まれる。メタデータ要求及びメタデータの具体例については後述する。

また、本実施形態では、情報銀行装置４〜６ごとに取扱い可能なデータ形式が異なる。そのため、メタデータ要求生成部３３２は、各情報銀行装置４〜６の取扱い可能なデータ形式に合わせて情報銀行装置４〜６ごとにメタデータ要求を生成する。
＜メタデータ要求送信部＞
メタデータ要求送信部３３３は、メタデータ要求生成部３３２により生成されたメタデータ要求を情報銀行装置４〜６に通信部３１を介して送信する。メタデータ要求を受信した情報銀行装置４〜６は、メタデータ要求に対する応答として、メタデータを仲介装置３に送信する。
＜メタデータ受信部＞
メタデータ受信部３３４は、情報銀行装置４〜６からメタデータを通信部３１を介して受信する。
＜条件整理部＞
条件整理部３３５は、情報銀行装置４〜６から受信されたメタデータから取引条件を整理する。
＜調達プラン決定部＞
調達プラン決定部３３６は、メタデータ受信部３３４により受信されたメタデータに基づいて、データ利用者２ａに適した調達プランを決定する。ここでいう調達プランとは、情報銀行装置４〜６が保有する、対象条件に合致するパーソナルデータの中から調達するパーソナルデータに関する条件を示す。つまり、調達プランにより示される条件に合致するパーソナルデータが情報銀行装置４〜６から調達（すなわち購入）される。調達プランの決定ロジックについては後述する。
＜データ要求生成部＞
データ要求生成部３３７は、調達プラン決定部３３６によって決定された調達プランに従い、データ要求を生成する。データ要求は、情報銀行装置４〜６にパーソナルデータを要求するためのデータである。データ要求生成部３３７は、各情報銀行装置４〜６の取扱い可能なデータ形式に合わせて情報銀行装置４〜６ごとにデータ要求を生成する。データ要求の具体例については後述する。
＜データ要求送信部＞
データ要求送信部３３８は、データ要求生成部３３７によって生成されたデータ要求を情報銀行装置４〜６に通信部３１を介して送信する。
＜データ受信部＞
データ受信部３３９は、データ要求を受信した情報銀行装置４〜６から納品データを通信部３１を介して受信する。納品データは、データ要求において指定されたパーソナルデータを含む。納品データの具体例については後述する。
＜形式処理部＞
形式処理部３４０は、複数の情報銀行装置４〜６から受信された納品データのデータ形式を共通のデータ形式に合わせ、１つのデータに統合することで統合データを生成する。統合データの具体例については後述する。
＜データ送信部＞
データ送信部３４１は、形式処理部３４０により生成された統合データを利用者装置２に通信部３１を介して送信する。これにより、情報銀行４ａ〜６ａから調達されたパーソナルデータがデータ利用者２ａに納品される。

［１−３．処理］
次に、仲介装置３の制御部３３が実行するデータ調達処理について、図４のフローチャートを用いて説明する。なお、データ調達処理は、リクエスト情報を利用者装置２から通信部３１を介して受信することにより開始される。なお、データ利用者２ａからリクエスト情報が受信されると、受信されたリクエスト情報は記憶部３２に記憶される。

＜Ｓ１０１＞
Ｓ１０１で、リクエスト取得部３３１は、データ利用者２ａからのリクエスト情報を記憶部３２から取得する。本実施形態のリクエスト情報は、図５に示す各項目を含む。すなわち、リクエスト情報は、タイムスタンプ、トランザクションＩＤ、文タイプ、宛先、送信元及び文内容を含む。なお、文タイプは、その情報が、リクエスト情報、メタデータ要求、メタデータ等のどのデータに該当するかを示すデータである。

文内容には、予算、報酬、対象条件、要求項目、分布集計軸、利用組織、利用目的及び利用条件の情報が含まれる。

予算の情報には、当該取引についてデータ利用者２ａが支払い可能な予算額の情報と、データ利用者２ａの費用の決済手段を示す情報と、が含まれる。

報酬の情報は、パーソナルデータを提供した個人に対するデータ利用者２ａからの報酬の情報である。報酬の情報には、報酬の形式、報酬の発行者、報酬の発行タイミング、報酬に係る特典等を使用可能な地域、報酬の発効時刻及び失効時刻等の情報が含まれる。

対象条件は、データ利用者２ａが欲するパーソナルデータの条件である。対象条件は、例えば、パーソナルデータに係る個人の属性（例えば性別、年齢、習慣等）を指定する条件である。データ利用者２ａが、条件が異なる複数のパーソナルデータを欲する場合、文内容に含まれる対象条件も複数になる。また、文内容には、対象条件ごとにその対象条件に合致するパーソナルデータをデータ利用者２ａがいくつ欲するかの件数の情報が含まれる。

例えば、図５に示す例では、１つ目の対象条件は、パーソナルデータに係る個人の性別が男性であり、レシピサイトの直近３ヶ月間の閲覧回数が３回以上である。また、データ利用者２ａが欲するこの対象条件に合致するパーソナルデータの件数は１０００件である。２つ目の対象条件は、パーソナルデータに係る個人の性別が女性であり、レシピサイトの直近３ヶ月間の閲覧回数が７回以上である。また、データ利用者２ａが欲するこの対象条件に合致するパーソナルデータの件数は１０００件である。

要求項目は、データ利用者２ａが納品を希望する、パーソナルデータの項目（例えば性別、年代、居住都道府県等）である。

分布集計軸は、情報銀行装置４〜６から送信されるメタデータに含まれる、パーソナルデータの一部の項目を指定する。すなわち、後述するとおり、情報銀行装置４〜６から送信されるメタデータには、情報銀行４ａ〜６ａが保有する、対象条件に合致する全部又は一部のパーソナルデータの一覧（すなわちリスト）が含まれる。当該リストには、パーソナルデータのＩＤごとに、当該パーソナルデータの一部の項目と、当該パーソナルデータのデータ価格と、が含まれる。ここでいうパーソナルデータの一部の項目は、換言すれば、パーソナルデータに係る個人の一部の属性であり、例えば未婚率、年代等である。分布集計軸は、当該リストに含まれるパーソナルデータの前記一部の項目を指定する。なお、本実施形態では、分布集計軸に含まれるパーソナルデータの属性は、対象条件により指定された属性以外の属性に設定される。

利用組織、利用目的及び利用条件の情報は、パーソナルデータの利用組織、利用目的及び利用条件を示す。利用組織の情報には、例えば、利用組織の法人番号、名称、住所、国、業種等が含まれる。利用目的の情報には、例えば、利用の種別（顧客分析、ダイレクトメール送信等）や個別の利用目的が含まれる。個別の利用目的は、例えば、顧客情報拡充、統計作成、パーソナルデータの提供元の本人へのアクセス、広告配信等である。

リクエスト取得部３３１は、上記のようなリクエスト情報を利用者装置２から受信する。

＜Ｓ１０２＞
続いて、Ｓ１０２で、メタデータ要求生成部３３２は、Ｓ１０１で受信されたリクエスト情報に基づいて、メタデータ要求を生成する。メタデータ要求は、パーソナルデータの調達先の情報銀行４ａ〜６ａごとに生成される。具体的には、図６には第１情報銀行４ａに対するメタデータ要求の例が示される。また、図７には第２情報銀行５ａに対するメタデータ要求の例が示されている。図６及び図７に示すメタデータ要求はいずれも同じ項目を含む。

具体的には、メタデータ要求は、タイムスタンプ、トランザクションＩＤ、文タイプ、参照トランザクションＩＤ、宛先、送信元及び文内容を含む。参照トランザクションＩＤは、Ｓ１０１で受信されたリクエスト情報、換言すれば、当該メタデータ要求に関連するリクエスト情報のトランザクションＩＤである。

文内容には、報酬、対象条件、要求項目、分布集計軸、利用組織、利用目的及び利用条件の情報が含まれる。文内容に含まれるこれらの情報はリクエスト情報に含まれるものと同じである。

ここで、本実施形態では、情報銀行装置４〜６ごとに取扱い可能なデータ形式が異なる。そのため、メタデータ要求は、送信先の情報銀行装置４〜６の取扱い可能なデータ形式に合わせて生成される。

例えば、第１情報銀行装置４が取扱い可能なデータ形式では、パーソナルデータに係る個人の性別を表す変数は「Ｇｅｎｄｅｒ」であり、当該変数に格納される値「１」に対して「個人の性別は男である」との意味が対応付く。また、変数「Ｇｅｎｄｅｒ」に格納される値「２」に対して「個人の性別は女性である」との意味が対応付く。

一方、例えば、第２情報銀行装置５が取扱い可能なデータ形式では、パーソナルデータに係る個人の性別を表す変数は「性別」であり、当該変数に格納される値「男性」に対して「個人の性別は男である」との意味が対応付く。また、変数「性別」に格納される値「女性」に対して「個人の性別は女性である」との意味が対応付く。

そこで、メタデータ要求生成部３３２は、例えば図６に示す第１情報銀行装置４に対するメタデータ要求では、対象条件の項目において、「パーソナルデータに係る個人の性別が男性である」との条件を「Ｇｅｎｄｅｒ＝１」などのようなデータ形式で指定する。

一方、メタデータ要求生成部３３２は、例えば図７に示す第２情報銀行装置５に対するメタデータ要求では、対象条件の項目において、「パーソナルデータに係る個人の性別が男性である」との条件を「性別＝男性」などのようなデータ形式で指定する。

なお、情報銀行装置４〜６ごとのメタデータ要求は、図８Ａ及び図８Ｂに示すようなカテゴリテーブルマスタに基づいて作成される。カテゴリテーブルマスタは、メタデータ要求等に含まれる各項目を、各情報銀行装置４〜６の取扱い可能なデータ形式に変換するための情報である。或る情報銀行装置のカテゴリテーブルマスタでは、その情報銀行装置の取扱い可能なデータ形式で記述された「変数名」、「値」及び「意味」が互いに対応付けられて設定されている。本実施形態では、仲介装置３の取引先である各情報銀行装置４〜６のカテゴリテーブルマスタが、あらかじめ仲介装置３の記憶部３２に記憶されている。ただし、カテゴリテーブルマスタの所在はこれに限られない。例えば、メタデータ要求を生成するに際し、仲介装置３がカテゴリテーブルマスタを要求する情報を各情報銀行装置４〜６に送信し、その応答信号として各情報銀行装置４〜６のカテゴリテーブルマスタが取得されてもよい。つまり、メタデータ要求を生成するタイミングでカテゴリテーブルマスタが取得されてもよい。

＜Ｓ１０３＞
続いて、Ｓ１０３で、メタデータ要求送信部３３３は、Ｓ１０２で生成されたメタデータ要求を情報銀行装置４〜６に通信部３１を介して送信する。メタデータ要求を受信した情報銀行装置４〜６は、メタデータ要求の応答情報として、メタデータを仲介装置３に送信する。

＜Ｓ１０４＞
続いて、Ｓ１０４で、メタデータ受信部３３４は、各情報銀行装置４〜６からメタデータを通信部３１を介して受信する。メタデータは、各情報銀行装置４〜６の取扱い可能なデータ形式で記述されている。

本実施形態のメタデータは、図９に示す各項目を含む。図９には、第２情報銀行装置５から受信されたメタデータが示される。

メタデータには、タイムスタンプ、トランザクションＩＤ、文タイプ、参照トランザクションＩＤ、宛先、送信元、カテゴリコードマスタ及び文内容が含まれる。参照トランザクションＩＤは、当該メタデータに関連するメタデータ要求、換言すれば、当該メタデータの送信元の情報銀行装置に送信されたメタデータ要求のトランザクションＩＤである。カテゴリコードマスタは、当該メタデータの送信元の情報銀行装置に関するカテゴリコードマスタを特定する情報である。

文内容には、対象者の情報である対象者情報が含まれる。対象者情報は、リクエスト情報に含まれる対象条件と、当該情報銀行が保有するパーソナルデータのうち対象条件に合致する全部又は一部のパーソナルデータの件数と、を含む。また、対象者情報は、対象条件に合致する全部又は一部のパーソナルデータがどのような属性のパーソナルデータから構成されるかを示す。

具体的には、対象者情報は、要求項目統計量を含む。要求項目統計量は、要求項目で指定される各属性に関するパーソナルデータの統計量（平均、分散、歪度、中央値等）や最大値及び最小値などである。また、対象者情報には、分散共分散行列、パーソナルデータのデータ価格分布の情報とその他多変量の統計量の情報とが含まれる。

ここで、データ価格分布の情報は、パーソナルデータを分布集計軸により指定される属性で分類した際の各分類に含まれるパーソナルデータのデータ価格を示す。例えば、分布集計軸において「未既婚、年代、３ヶ月雑誌購買有無」の属性が指定されているとする。この場合、データ価格分布の情報には、「未既婚：未婚、年代：３０、３ヶ月雑誌購買有無＝無」との分類に含まれるパーソナルデータのデータ価格「２６０，２８０，２９０，・・・」が含まれ得る。

本実施形態では、リクエスト情報で指定されたパーソナルデータの件数よりも多くの件数のパーソナルデータの情報がメタデータに含まれることが想定される。より詳細には、メタデータに含まれる、或る対象条件に合致するパーソナルデータの情報の件数は、リクエスト情報において指定されたその対象条件に合致するパーソナルデータの件数よりも多いことが想定される。これは、リクエスト情報で指定された件数のパーソナルデータをメタデータを基に選択する際に、複数通りのパーソナルデータの選択の仕方（すなわち調達プラン）を検討し、複数通りの調達プランの中からデータ利用者２ａに適した調達プランを決定するためである。ただし、メタデータによりその属性が示されるパーソナルデータの件数はこれに限られず、当該パーソナルデータの件数は、例えば、リクエスト情報で指定されたパーソナルデータの件数と同数であってもよい。

＜Ｓ１０５＞
続いて、Ｓ１０５で、条件整理部３３５は、各情報銀行装置４〜６のデータ形式に合わされたメタデータから取引条件を整理する。具体的には、条件整理部３３５は、各情報銀行装置４〜６のカテゴリテーブルマスタを利用して、各情報銀行装置４〜６のデータ形式に合わされたメタデータを共通のデータ形式に合わせ、取引条件を整理する。

また、条件整理部３３５は、Ｓ１０４で受信された各情報銀行装置４〜６からのメタデータに基づき、図１０の破線で示すようなリスト（以下、メタデータリスト）を生成する。メタデータリストは、パーソナルデータのＩＤと、データソースと、分布集計軸により指定される属性と、データ価格と、が対応付けられたデータである。データソースは、そのデータがどの情報銀行からのデータであるかを識別する情報である。前述のとおり、本実施形態では、リクエスト情報で指定されたパーソナルデータの件数よりも多くの件数のデータを含むメタデータリストが生成される。なお、図１０のメタデータリストの「データソース」の列において、「第１」は第１の情報銀行４ａを意味し、「第２」は第２の情報銀行５ａを意味する。

＜Ｓ１０６＞
続いて、Ｓ１０６で、調達プラン決定部３３６は、Ｓ１０５で生成されたメタデータリストに基づいて、データ利用者２ａに適した調達プランを決定する。本実施形態では、調達プラン決定部３３６は、情報銀行装置４〜６が保有する個々のパーソナルデータのデータ価格と、データ利用者２ａが指定した予算額と、に基づき、調達プランを決定する。さらに、調達プラン決定部３３６は、メタデータにより示される、分布集計軸により指定された属性に着目したときのパーソナルデータの分布（以下、元データ分布）の再現性に基づき調達プランを決定する。つまり、調達プラン決定部３３６は、データ利用者２ａの予算額の範囲内で、調達プランにより調達されるパーソナルデータのデータ分布が元データ分布に近づくように調達プランを決定する。

以下、調達プランの決定の仕方を図１０を用いて具体的に説明する。図１０では、簡単のため、１００個のデータから成るメタデータリストを考える。この事例ではデータ利用者２ａからのリクエスト情報には１つの対象条件のみが含まれているとする。例えば、図５の対象条件１の「パーソナルデータに係る個人の性別が男性であり、レシピサイトの直近３ヶ月間の閲覧回数が３回以上である」との対象条件のみがリクエスト情報に含まれているとする。図１０の１００個のデータはこの対象条件に合致するデータである。そして、データ利用者２ａが欲するこの対象条件に合致するパーソナルデータの件数は４０件であるとする。つまり、前記１００個のデータの中から４０個のデータを選択する。また、データ利用者２ａの予算額は１１０００円であるとする。

データ価格の総額が最も安い調達プランは、データ価格でデータを昇順でソートし、１番目から４０番目までのデータを購入するプランＡである。なお、図１０では、調達プランにおいて購入されるデータには「１」のフラグが立ち、購入されないデータには「０」のフラグが立つ。プランＡの購入データ価格の総額は１０５７０円である。しかしながら、例えば未婚及び未既の比は、元の１００個のデータ（以下、元データ）では５９：４１（≒３：２）であるのに対してプランＡでは１２：２８（≒１：２．５）であり、元データの分布とズレている。なお、図１０では、未婚に対応する値は「０」であり、既婚に対応する値は「１」である。すると、実際に調達して得られるパーソナルデータの他の項目についても元データの分布を再現しない懸念がある。そこで、購入されるデータの内訳が異なる他のパターン（例えば図１０のプランＢやプランＣ等）も検討し、プランＡと同様にデータ価格の総額と元データの分布である元データ分布からのズレとを評価する。なお、元データ分布とのズレは、例えば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」等の属性値を成分とするベクトル（１，０，０，１，・・・）として扱うことができる。そして、ベクトル間の類似度又は距離を計算することで、パーソナルデータ同士の類似度を計算することができる。なお、ベクトル間の類似度と距離との関係については、類似度が高いほど距離は小さくなり、類似度が低いほど距離は大きくなる。

そして、図４８に示す第１の情報銀行４ａから受信されたＩＤ＝１〜２０のパーソナルデータと、図４９に示す第２の情報銀行５ａから受信されたＩＤ＝１〜２０のパーソナルデータと、の類似度を計算することで、図５０に示すような類似度行列が得られる。

図５０に示す類似度行列において、行ラベルである「１ ＩＤ」は、第１の情報銀行４ａのＩＤを意味し、列ラベルである「２ ＩＤ」は第２の情報銀行５ａのＩＤを意味する。すなわち、１ ＩＤ＝ｉ、かつ、２ ＩＤ＝ｊの成分は、第１の情報銀行４ａのＩＤ＝ｉのパーソナルデータと、第２の情報銀行５ａのＩＤ＝ｊのパーソナルデータと、の類似度を示す。

なお、図５０に示す例では、２つのパーソナルデータ（すなわち、２つのベクトル）の類似度はコサイン類似度として計算されるが、２つのパーソナルデータの類似度の計算方法はこれに限られない。例えば、２つのパーソナルデータの類似度は、ユークリッド距離やマハラノビス距離等のその他の距離や類似度を用いて計算されてもよい。なお、図５０に示す類似度行列では、コサイン類似度は、０〜１の範囲内になるように規格化されていない。

そして、類似度判定部１２３１は、類似度行列において、類似度が所定のしきい値（以下、類似度しきい値）以上である２つのパーソナルデータを、同一人物のパーソナルデータであるとして互いに紐付ける。

例えば、図５０に示す例において、類似度が５以上の２つのパーソナルデータを同一人物のパーソナルデータとして特定した場合、以下の３つの組合せが同一人物のパーソナルデータの組合せとなる。
・第１の情報銀行４ａのＩＤ＝２のパーソナルデータ（１ ＩＤ＝２）と、第２の情報銀行５ａのＩＤ＝１０のパーソナルデータ（２ ＩＤ＝１０）
・第１の情報銀行４ａのＩＤ＝１２のパーソナルデータ（１ ＩＤ＝１２）と、第２の情報銀行５ａのＩＤ＝１２（２ ＩＤ＝１２）又は１３（２ ＩＤ＝１３）のパーソナルデータ
・第１の情報銀行４ａのＩＤ＝１８（１ ＩＤ＝１８）のパーソナルデータと、第２の情報銀行５ａのＩＤ＝７（２ ＩＤ＝７）のパーソナルデータ
なお、上記の２番目の組合せのように１つのパーソナルデータに複数のパーソナルデータが紐付く場合がある。このような場合、例えば以下の（１）〜（３）の取扱いが考えられる。
（１）一のパーソナルデータに複数のパーソナルデータが紐づく場合は、前記一のパーソナルデータを含む組合せは除外する。すなわち、一のパーソナルデータに対して一のパーソナルデータが紐付く場合のみその２つのパーソナルデータを同一個人のパーソナルデータであると特定する。
（２）一のパーソナルデータに複数のパーソナルデータが紐付き、前記複数のパーソナルデータの前記一のパーソナルデータとの類似度が互いに異なる場合、前記複数のパーソナルデータのうち前記一のパーソナルデータとの類似度が高い方を優先する。そして、前記複数のパーソナルデータのうち優先されたパーソナルデータと前記一のパーソナルデータとを同一個人のパーソナルデータであると特定する。
（３）一のパーソナルデータに複数のパーソナルデータが紐付き、前記複数のパーソナルデータの前記一のパーソナルデータとの類似度が互いに場合、前記複数のパーソナルデータのうち、前記一のパーソナルデータよりも類似度が高いパーソナルデータがある場合、そちらで紐づけを行う。例えば、上記の例において仮に第２の情報銀行５ａのＩＤ＝１２のパーソナルデータについて、第１の情報銀行４ａのＩＤ＝１２のパーソナルデータよりも類似度が高い別のパーソナルデータが存在する場合、その別のパーソナルデータと第２の情報銀行５ａのＩＤ＝１２のパーソナルデータとを紐付ける等。

なお、上記（１）〜（３）の少なくとも２つが同時に採用されてもよい。このようにして、類似度判定部１２３１は、複数の情報銀行４ａ〜６ａから受信された複数のパーソナルデータの中から、パーソナルデータの属性値が類似する複数のパーソナルデータを特定する。

そして、続くＳ６１２の処理において、類似度判定部１２３１によって互いに紐付けられた複数のパーソナルデータは、同一個人のパーソナルデータであるとして、データ送信部３４１によってデータ利用者２ａに送信される。

［９−３．効果］
以上詳述した第９実施形態によれば、前述した第４実施形態の効果（４ａ）に加え、以下の効果が得られる。

（９ａ）本実施形態では、仲介装置１２は、複数の情報銀行４ａ〜６ａから取得された複数のパーソナルデータ間の類似度であってパーソナルデータの属性値に基づく類似度を示す類似度行列に基づいて納品データを決定する。特に、仲介装置１２は、類似度行列を重複確認情報として取得する。

詳しくは、仲介装置１２は、複数の情報銀行４ａ〜６ａから複数のパーソナルデータを取得し、取得された複数のパーソナルデータについて、パーソナルデータの属性値に基づく類似度判定を行う（Ｓ６１１）。そして、仲介装置１２は、類似度判定によって互いに類似していると判定された複数のパーソナルデータを互いに紐付ける（Ｓ６１１）。そして、仲介装置１２は、紐付けられた複数のパーソナルデータに基づく納品データを利用者装置２に送信する。

したがって、互いに紐付けられた複数のパーソナルデータを同一個人に係るパーソナルデータと見做すことで、複数の情報銀行４ａ〜６ａから同一個人に係るパーソナルデータを名寄せすることができる。

また、本実施形態によれば、第４実施形態のような登録管理者９ａが存在しない時期、すなわち、登録管理者９ａが現れる時期よりも前の時期であっても、複数の情報銀行４ａ〜６ａから同一個人に係るパーソナルデータを名寄せできる。

（９ｂ）また、第１の情報銀行４ａが管理するパーソナルデータの項目と、第２の情報銀行５ａが管理するパーソナルデータの項目と、が異なる場合、両方の項目が補完されたパーソナルデータのサンプル数を出来るだけ多く得たいというニーズがあり得る。第４実施形態のように情報銀行ＩＤ、情報銀行登録者ＩＤ及び個人ＩＤの３つのＩＤを使用して名寄せを行う場合、真に同一個人に係る複数のパーソナルデータのみ互いに紐付けられる。このため、上記サンプル数が多く得られない場合がある。この点、本実施形態によれば、パーソナルデータを紐付ける際の類似度しきい値を緩めることで、パーソナルデータの多対多の紐付けを許容することができる。その結果、前述したサンプル数を増加させることができる。

なお、本実施形態では、図５０に示す類似度行列が類似度情報及び重複確認情報に相当し、Ｓ６０１がリクエスト取得部としての処理に相当し、Ｓ６１１が重複確認取得部としての処理に相当し、Ｓ６１１及びＳ６１２が決定部としての処理に相当し、Ｓ６０９及びＳ６１２が取得送信部としての処理に相当する。

［１０．他の実施形態］
以上、本開示を実施するための形態について説明したが、本開示は前述の実施形態に限定されることなく、種々変形して実施することができる。

（１）上記各実施形態では、仲介装置は、複数の情報銀行装置４〜６からパーソナルデータを調達するが、仲介装置がパーソナルデータを調達する情報銀行装置の数はこれに限られない。例えば、上記第１〜第２実施形態において、仲介装置は、複数の情報銀行装置からパーソナルデータを調達せず、１つの情報銀行装置のみからパーソナルデータを調達してもよい。

（２）上記各実施形態では、パーソナルデータ管理者として情報銀行を例示したが、パーソナルデータ管理者はこれに限られない。例えば、パーソナルデータ管理者は、通信キャリアやクレジットカード会社等、大量の顧客データを保有しているが、情報銀行を専らにしていない事業者であってもよい。このようにパーソナルデータ管理者は、個人から預託されたパーソナルデータを管理するとともに当該パーソナルデータを第三者に提供する事業を営むパーソナルデータ事業者であってもよい。

（３）上記各実施形態では、仲介装置は、複数の情報銀行装置４〜６から受信された納品データのデータ形式を共通のデータ形式に合わせ、１つのデータに統合してデータ利用者２ａに納品するが、納品の仕方はこれに限られない。例えば、仲介装置は、複数の情報銀行装置４〜６から受信された納品データを共通のデータ形式に合わせなくてもよい。また、仲介装置は、複数の情報銀行装置４〜６からの納品データを１つの納品データに統合しなくてもよい。

（４）上記各実施形態における調達プランの決定ロジックはあくまで一例であり、他の決定ロジックで調達プランが決定されてもよい。例えば、上記各実施形態では、データ利用者２ａの予算額の範囲内で元データ分布の再現性が最も高いプランが調達プランに決定される。しかし、例えば、予算額を多少（すなわち所定額）オーバーしても元データ分布の再現性が最も高い場合、そのプランが調達プランに決定されてもよい。つまり、予算額と元データ分布の再現性とに基づいて調達プランが決定される場合において、再現性の方を予算額よりも重視するように調達プランが決定されてもよい。一方、上記各実施形態のように予算額の方を再現性よりも重視するように調達プランが決定されてもよい。

また例えば、情報銀行等のパーソナルデータ管理者がパーソナルデータを拡充するために個人に対してアンケートを実施しているような場合、そのアンケートに回答していない個人のパーソナルデータは欠測データとなる。このようにパーソナルデータ管理者が管理するパーソナルデータに欠測データが含まれている場合、欠測データが最も少なくなるように調達プランが決定されてもよい。

また例えば、調達されるパーソナルデータの「鮮度」が最も良くなるように調達プランが決定されてもよい。具体的には、仲介装置は、パーソナルデータ管理者や自身の記憶部等からパーソナルデータの最終更新日時の情報を取得し、取得された最終更新日時の情報を基に調達プランを決定してもよい。この場合において例えば、仲介装置は、最新更新日時が新しいパーソナルデータから順に、調達されるパーソナルデータに決定するなどして調達プランを決定してもよい。

また、或る情報銀行から受信されたメタデータに含まれるデータ価格が極端に安いあるいは極端に高い場合、換言すれば、データ価格が所定のしきい値以下あるいはしきい値以上である場合、そのデータ価格あるいはその情報銀行自体が怪しまれる。その場合、仲介装置は、その極端に安い又は高いデータを避けてパーソナルデータを調達するように調達プランを決定してもよい。また、仲介装置は、極端に安いあるいは極端に高いデータ価格を提示する情報銀行を避けて（つまりその情報銀行以外の情報銀行から）パーソナルデータを調達するように調達プランを決定してもよい。

また例えば、仲介装置は、価格以外の要素を考慮し、同一の対象条件に合致する複数のパーソナルデータの中から最安値でないパーソナルデータを調達する調達プランを決定してもよい。

具体的には例えば、仲介装置は、価格以外の要素として、パーソナルデータに含まれる属性のうち、対象条件で指定されていない属性（以下、非指定属性）と、データ利用者２ａのパーソナルデータの利用目的等（ひいてはリクエスト情報）と、の適合度を考慮し、調達するパーソナルデータを決定してもよい。

例えば、仲介装置が、性別が男性であり、年代が２０代であるという対象条件を含むリクエスト情報を利用者装置２から受信したとする。そして、仲介装置は、上記対象条件に合致するパーソナルデータに係るメタデータを各情報銀行４ａ〜６ａから受信する。このとき、リクエスト情報に含まれる利用組織の情報から、データ利用者２ａが飲食関係の業種（例えば食品メーカ）であることが特定されるとする。そして、第１の情報銀行４ａが保有するパーソナルデータには性別、年代以外の属性（すなわち、非指定属性）として、飲食に関する属性（食事ログなど）が含まれているとする。他方、第２の情報銀行５ａが保有するパーソナルデータには非指定属性として飲食に関する属性が含まれていないとする。この場合、仲介装置は、第１の情報銀行４ａのパーソナルデータの方がデータ利用者２ａの利用組織や利用目的等との適合度が高いと判断し、価格が第２の情報銀行５ａのデータより高くても、第１の情報銀行４ａのデータを調達する調達プランを決定してもよい。

また例えば、仲介装置は、データ利用者の業種と、情報銀行４ａ〜６ａにデータを預託した個人の業種とが同じ場合には、データ利用者がその個人のデータを入手できないようにしてもよい。換言すれば、仲介装置は、その個人のパーソナルデータを除外して調達プランを決定してもよい。つまり、仲介装置は、データ利用者と、情報銀行４ａ〜６ａにデータを預託した個人と、の関係性に基づいて調達プランを決定してもよい。また、その他の価格以外の要素を考慮し、調達プランが決定されてもよい。

また例えば、仲介装置は、調達プランを決定するための条件（換言すれば、調達プランの決定ロジック）に関する要望をデータ利用者２ａから取得し、取得された要望に基づいて調達プランを決定してもよい。

また、仲介装置は、複数のプランの中からデータ利用者２ａに適した調達プランを選択するのではなく、データ利用者２ａに適した一の調達プランをいきなり出力してもよい。

（５）図５に例示されたリクエスト情報の具体例や図６、図７に例示されたメタデータ要求の具体例等はあくまで一例であり、リクエスト情報等は、図５等に示す項目の一部のみ含んでいてもよく、図５等に例示されていない他の項目を含んでいてもよい。

（６）或る情報銀行からのメタデータは、その情報銀行が保有する全てのパーソナルデータの属性を示す情報であってもよく、また、一部のパーソナルデータのみの属性を示す情報であってもよい。また、メタデータは、パーソナルデータの一部の属性を示すものに限られず、パーソナルデータの全ての属性を示すデータであってもよい。

（７）上記第２実施形態では、記憶部７２にはメタデータセットが記憶されているが、記憶部７２に記憶されるデータはこれに限られない。例えば、記憶部７２には、各情報銀行装置４〜６の特徴を表す情報である情報銀行特徴情報が記憶されてもよい。情報銀行特徴情報は、具体的には例えば、第１情報銀行４ａは２０代〜４０代の女性のパーソナルデータを多く管理している、第２情報銀行５ａは家族持ちユーザのパーソナルデータを多く管理している、第３情報銀行３ａは６０歳以降のシニア層のユーザのパーソナルデータを多く管理している、等である。この場合において例えば、仲介装置が利用者装置２から家族持ちユーザのパーソナルデータを欲する旨のリクエスト情報を受信した場合に、家族持ちユーザのパーソナルデータを多く管理する第２情報銀行５ａにメタデータ要求やデータ要求を送信してもよい。そして、仲介装置は、第２情報銀行５ａからパーソナルデータを調達する調達プランを決定してもよい。また逆に、仲介装置は、利用者装置２から家族持ちユーザのパーソナルデータを欲する旨のリクエスト情報を受信した場合に、家族持ちユーザのパーソナルデータをあまり管理していない情報銀行を避けるように、メタデータ要求やデータ要求を送信してもよい。

すなわち、仲介装置は、情報銀行特徴情報に基づいて、リクエスト情報に含まれる対象条件に適合する特徴を有すると判断した情報銀行（ひいてはパーソナルデータ管理者）に対してメタデータ要求及び／又はデータ要求を送信してもよい。また、仲介装置は、情報銀行特徴情報に基づいて、リクエスト情報に含まれる対象条件に適合する特徴を有しないと判断した情報銀行（ひいてはパーソナルデータ管理者）に対してメタデータ要求及び／又はデータ要求を送信しなくてもよい。

なお、仲介装置は、情報銀行特徴情報を自身の記憶部７２から取得するのではなく、各情報銀行４ａ〜６ａに対して問い合わせることで各情報銀行４ａ〜６ａから情報銀行特徴情報を取得してもよい。

なお、情報銀行特徴情報は、各パーソナルデータ管理者の特徴を表す情報である管理者特徴情報の一例に相当する。また、管理者特徴情報は、パーソナルデータ管理者が管理するパーソナルデータの属性を示す情報である属性情報の一例である。

（８）更新処理部７３２，９３２が実行する更新処理の内容は、上記第２及び第５実施形態のものに限られない。

例えば、上記第２実施形態において、更新処理部７３２は、記憶部７２に記憶されているメタデータセットを、情報銀行４ａ〜６ａから調達されたパーソナルデータに基づいて更新してもよい。具体的には例えば、情報銀行４ａ〜６ａから調達されたパーソナルデータ（すなわち購入されたパーソナルデータ）については、そのパーソナルデータの属性（すなわちデータの内容）がわかる。更新処理部７３２は、調達されたパーソナルデータの内容に基づき、調達先の情報銀行４ａ〜６ａが保有しているパーソナルデータの属性に基づく分布を更新するなどして、記憶部７２に記憶されているメタデータセットを更新してもよい。

同様に、上記第５実施形態において、更新処理部９３２は、記憶部１１２に記憶されている重複状況テーブルを、情報銀行４ａ〜６ａから調達されたパーソナルデータに基づいて更新してもよい。具体的には例えば、仲介装置が、複数の情報銀行４ａ〜６ａから対象条件に合致するパーソナルデータを調達（すなわち購入）したとする。その際、仲介装置は、購入された複数のパーソナルデータの属性（すなわちデータの内容）を互いに比較し、購入された複数のパーソナルデータが同一個人に係るパーソナルデータであるか否かをデータの内容の類似度等から判断する。そして、仲介装置は、同一個人に係るパーソナルデータと判断した複数のパーソナルデータについては同一の個人ＩＤを設定し、図３５に示す重複状況テーブルにデータを新たに追加してもよい。

（９）上記第５実施形態において、仲介装置は、管理者装置９に重複確認を行わず、記憶部１１２に記憶された重複状況テーブルに基づき重複確認を行うが、以下のような場合に管理者装置９に対し、重複確認を行ってもよい。

すなわち、仲介装置は、ＩＤ受信部８３３により受信されたＩＤ結果情報に含まれる各情報銀行登録者ＩＤについて、記憶部１１２に記憶されている重複状況テーブルで重複状況を確認する。このとき、重複状況テーブルに該当する情報銀行登録者ＩＤがない場合など、記憶部１１２に記憶されている重複状況テーブルでは重複状況が確認できない情報銀行登録者ＩＤが存在する場合がある。この場合、仲介装置は、重複状況が不明な情報銀行登録者ＩＤについてのみ、管理者装置９に重複状況を問い合わせてもよい。そして、管理者装置９から受信された重複結果情報に基づき、重複状況が不明な情報銀行登録者ＩＤのデータを登録するなどして重複状況テーブルを更新してもよい。

（１０）上記第３〜第５実施形態では、仲介装置は、ＩＤ結果情報に含まれる情報銀行登録者ＩＤについて管理者装置９に問い合わせることにより、又は、記憶部１１２に記憶された重複状況テーブルを参照することにより、前記ＩＤについて重複確認を行う。そして、仲介装置は、重複確認の結果を踏まえて、各情報銀行４ａ〜６ａにメタデータ要求を送信する。しかし、重複確認を行うタイミングはこれに限られない。

例えば、第３実施形態において、仲介装置は、ＩＤ要求を各情報銀行４ａ〜６ａに送信せず、メタデータ要求を各情報銀行４ａ〜６ａに送信する。ここで、仲介装置は、各情報銀行４ａ〜６ａから、同一個人のデータの重複を許容した形でメタデータを受信する。

このとき、仲介装置は、メタデータと併せて、各情報銀行４ａ〜６ａから、メタデータにデータが含まれている個人に係る情報銀行登録者ＩＤのリストを受信する。

そして、仲介装置は、受信された情報銀行登録者ＩＤのリストについて、管理者装置９に対して重複確認要求を行う。このように、メタデータ受信後に、重複確認が行われてもよい。

（１１）上記第３〜第６実施形態では、仲介装置は、図２８に示すような情報銀行登録者ＩＤ及び価格の組のリストを含むＩＤ結果情報を受信するが、ＩＤ結果情報はこれに限られない。例えば、登録管理者９ａの管理者装置９が、図３５に示すような、価格情報を含む重複状況テーブルを保有していてもよい。この場合、図３５に示すような、価格情報を含む重複状況テーブルを保有していてもよい。その場合には、図２８に示すＩＤ結果情報には情報銀行登録者ＩＤのリストのみが含まれていてもよい。また、図３０に示す重複結果情報には（｛ＩＤ，価格｝，｛ＩＤ，価格｝，｛ＩＤ，価格｝…）といった形の、各情報銀行４ａ〜６ａについての情報銀行登録者ＩＤと価格との組のリストが含まれていてもよい。そして、例えば仲介装置は、受信されたリストに基づき、最安値以外のＩＤについてはメタデータにおいて除外ＩＤとして指定してもよい。

（１２）上記第３〜第６実施形態では、登録識別情報として、情報銀行４ａ〜６ａにパーソナルデータを預託した個人を識別する情報である情報銀行登録者ＩＤを例示したが、登録識別情報はこれに限られない。登録識別情報は、例えば、各情報銀行４ａ〜６ａが当該情報銀行４ａ〜６ａに預託されたパーソナルデータに付与する識別情報であってもよい。

（１３）上記第６実施形態では、通知情報として広告情報を例示したが、通知情報はこれに限られない。例えば、通知情報は、個人に商品やサービスをレコメンドするレコメンド情報等であってもよい。

（１４）上記第６実施形態では、広告情報の送信先情報が、情報銀行４ａ〜６ａから取得されたパーソナルデータに含まれていることが想定される。しかし、例えば、送信先情報が情報銀行４ａ〜６ａから取得されたパーソナルデータに含まれていない場合等において、次のように広告配信が行われてもよい。

すなわち、利用者装置２等の広告配信装置は、配信対象者別の広告情報などの通知情報を仲介装置を介して間接的に又は仲介装置を介さず直接的に情報銀行４ａ〜６ａに送信する。そして、情報銀行４ａ〜６ａが、パーソナルデータを預託した個人に対し、広告配信装置から受信した通知情報を送信してもよい。つまり、利用者装置２等の広告配信装置は、情報銀行４ａ〜６ａを通じて、パーソナルデータを預託した個人に対して広告配信を行ってもよい。

この場合において、情報銀行４ａ〜６ａは、自身が持つ、パーソナルデータを預託した個人との何らか接点を利用して広告配信を行ってもよい。

具体的には例えば、情報銀行４ａ〜６ａの情報銀行装置４〜６は、パーソナルデータを預託した個人の情報処理端末１１〜１７に対して電子メールで通知情報を送信してもよく、個人が閲覧するインターネットのウェブサイトに通知情報を出力させてもよい。また例えば、情報銀行装置４〜６は、個人の情報処理端末１１〜１７にインストールされたアプリケーションソフトウェア内で通知情報を出力させてもよく、個人が来店する店頭などのエリアに設置された端末に通知情報を出力させてもよく、その他種々の方法で通知情報を個人に対して送信してもよい。

このような構成によれば、データ利用者２ａ等が取得したパーソナルデータに送信先情報が含まれていなくても、データ利用者２ａ等は、個人に対し、広告配信を行うことができる。

（１５）上記第６実施形態では、利用者装置２が広告配信を行うが、広告配信を行う主体はこれに限られない。例えば、広告代理店等の広告配信事業者や広告配信を行うプラットフォーマーなどの、データ利用者２ａとは別の者が保有する装置が広告配信を行ってもよく、仲介装置が広告配信を行ってもよい。この場合において、広告配信事業者やプラットフォーマーが保有する装置や仲介装置などが図４０に示す広告配信処理を行ってもよい。

（１６）また例えば、前述した［７．他の実施形態］の（１４）で述べたように、仲介装置等が、情報銀行４ａ〜６ａにパーソナルデータを預託した個人に情報銀行４ａ〜６ａを介して広告配信を行う場合などにおいて、仲介装置等は広告成果指標を計算してもよい。ここでいう広告成果指標とは、広告配信に関する成果を示す指標である。

具体的には例えば、仲介装置は、登録管理者９ａの管理者装置９から取得された重複結果情報を利用して、広告成果指標としてのユニークユーザ数を計算してもよい。ユニークユーザ数は、広告配信が行われたユーザの数である。

すなわち、各情報銀行４ａ〜６ａが、当該情報銀行４ａ〜６ａにデータを預託している個人に対して広告配信を行う場合、複数の情報銀行４ａ〜６ａにパーソナルデータを預託している個人については、複数の情報銀行４ａ〜６ａから同一の広告情報が送信される場合がある。このような場合でも、重複結果情報を利用すれば、いずれの個人に対して広告情報が重複して配信されたかがわかるため、ユニークユーザ数を計算することができる。また、仲介装置は、重複結果情報を利用して、ユニークユーザ数以外の広告成果指標を計算してもよい。

また例えば、仲介装置等は、情報銀行４ａ〜６ａを介して広告配信を行う場合等において、重複結果情報に基づいて広告配信を行ってもよい。具体的には例えば、仲介装置等は、同一の広告情報が同一人物に複数の情報銀行４ａ〜６ａから重複して送信されないように、複数の情報銀行装置４〜６のうちの一の情報銀行装置以外には配信内容と共に除外ＩＤを送信する。ここで、情報銀行装置４〜６は、受信された除外ＩＤで指定される情報銀行登録者ＩＤに係る個人に対しては、広告配信を行わない。このようにすることで、前記一の情報銀行装置以外の情報銀行装置が広告配信を行わないようにしてもよい。もちろん、重複結果情報を用いたその他の方法で、同一の広告情報が同一人物に重複して送信されないようにしてもよい。

（１７）上記第９実施形態では、類似度しきい値は一定に設定されるが、類似度しきい値はこれに限られず、類似度しきい値を変動させてもよい。この場合において例えば、類似度しきい値は次のように変動してもよい。

すなわち、図５１に示すように、類似度しきい値ｔを連続的に変化させると紐付け成功数が変化する。紐付け成功数とは、互いに類似していると判断され、互いに紐付けられるパーソナルデータの組合せの数である。

図５１から見て取れるように、類似度しきい値ｔが大きくなるほど紐付け成功数が減少する。そのため、類似度しきい値ｔを大きく設定しすぎると、本来同一個人のパーソナルデータの組合せと見做すべきパーソナルデータの組合せを、同一個人のパーソナルデータの組合せでないとして、取りこぼす可能性がある。また逆に、類似度しきい値ｔを小さく設定しすぎると、同一個人に由来しないパーソナルデータ同士の組合せが多数発生する可能性がある。このため、類似度しきい値ｔを大きく設定しすぎず、かつ、小さく設定しすぎないことが望ましいと考えられる。

このような考え方の下、例えば、図５１に示すように類似度しきい値ｔを連続的に変化させたときに、紐付け成功数の変化が最大になる類似度しきい値ｔの値ｔ_ＭＡＸを最適なしきい値として採用することが考えられる。ｔ_ＭＡＸは、換言すれば、紐付け成功数ｎを類似度しきい値ｔの関数ｎ＝ｆ（ｔ）と見做したときの関数ｎ＝ｆ（ｔ）の接線の傾きが最小となる類似度しきい値ｔの値である。

また、ｔ_ＭＡＸの値が小さい場合など、類似度しきい値ｔをｔ_ＭＡＸに設定してパーソナルデータの紐付けを行うと、同一個人に由来しないパーソナルデータ同士の組合せが多数発生してしまう場合がある。このような場合、ｔ_ＭＡＸの次に紐付け成功数の変化が大きい類似度しきい値ｔの値、換言すれば、関数ｎ＝ｆ（ｔ）の接線の傾きが２番目に小さくなる類似度しきい値ｔの値ｔ_２ＭＡＸを最適なしきい値として採用してもよい。もちろん、接線の傾きが３番目、４番目、・・・に小さい値を最適なしきい値ｔとして採用してもよい。

なお、類似度しきい値ｔをｔ_ＭＡＸ、ｔ_２ＭＡＸ、・・・等のうちのいずれに設定するかはユーザによって設定されてもよく、また、システムによって自動的に設定されてもよい。

また例えば、複数のパーソナルデータが互いに類似しているか否かを、次のように判定してもよい。すなわち、パーソナルデータの年齢や性別等の属性（換言すれば、パーソナルデータのデータ項目）ごとにパーソナルデータ同士の類似度を計算する。そして、全部又は一部の属性について類似度がしきい値以上であると判定される場合に、複数のパーソナルデータが互いに類似していると判定されてもよい。

また例えば、以下に詳述するように、パーソナルデータのデータ項目に対応する座標軸を有し、各パーソナルデータを点やベクトルなどとして表現する座標空間において新たな座標軸を設定する。そして、設定された各座標軸についての類似度がしきい値以上である場合に、複数のパーソナルデータが互いに類似している、ひいては、同一個人に係るパーソナルデータであると判定されてもよい。そして、例えば、上記と同様に類似度しきい値を変動させ、最適な類似度しきい値を求めてもよい。具体的には以下のように類似度しきい値を求めてもよい。

すなわち、図５２に示すように、まず、情報銀行４ａ〜６ａから取得されたパーソナルデータのデータセットを座標空間にプロットする。図５２において各データ点はパーソナルデータを表す。また、図５２の座標空間の各座標軸はパーソナルデータの各属性（すなわち、各データ項目）に対応する。例えば「性別＝男性」というデータ項目に対応する座標軸については、各パーソナルデータは、男性に該当するか否かに応じて０又は１の値を取る。また、「３ヶ月雑誌購買金額」というデータ項目に対応する座標軸については、各パーソナルデータは、該当する購入金額に値を取る。

そして、前記データセットに対して、主成分分析や多様体学習を行うことで、データセットをより良く記述する新たな座標軸を構成する。図５２では、ｘ_１座標軸及びｘ_２座標軸が新たな座標軸である。

そして、新たな座標軸ごとに類似度しきい値ｔ＝（ｔ_１，ｔ_２，・・・）を設定する。ここでいう類似度しきい値ｔは、例えば、２つのパーソナルデータの各成分の属性値の差分に関するしきい値であってもよい。具体的には例えば、或るパーソナルデータＡが前記新たな座標軸で座標ｘ_Ａ＝（ｘ_１Ａ，ｘ_２Ａ，・・・）で表現され、別のパーソナルデータＢが新たな座標軸で座標ｘ_Ｂ＝（ｘ_１Ｂ，ｘ_２Ｂ，・・・）で表現されるとする。この場合、２つのパーソナルデータＡ，Ｂは、以下のように、各成分の差分の絶対値が類似度しきい値以下である場合に互いに類似していると判定されてもよい。
Δｘ_１≡｜ｘ_１Ａ−ｘ_１Ｂ｜≦ｔ_１ かつ Δｘ_２≡｜ｘ_２Ａ−ｘ_２Ｂ｜≦ｔ_２・・・
そして、図５３に示すように、類似度しきい値ｔ＝（ｔ_１，ｔ_２，・・・）の各成分ｔ_ｉを連続的に変化させたときに、紐付け成功数ｎの変化が最大に類似度しきい値ｔ_ＭＡＸ＝（ｔ_ＭＡＸ１，ｔ_ＭＡＸ２，・・・）等を最適なしきい値として採用してもよい。

このように類似度しきい値ｔを動的に変化させることで、パーソナルデータのデータセットごとに最適な類似度しきい値ｔを設定することができる。ひいては、同一個人のパーソナルデータの組合せと見做すべきパーソナルデータの組合せを取りこぼしたり、同一個人に由来しないパーソナルデータ同士の組合せを多数発生させたりする可能性を低減することができる。

なお、上記のように主成分分析や多様体学習を行い新たな座標軸を設定することは必須ではない。しかし、新たな座標軸を設定することで一般に各パーソナルデータを少ない次元の座標として表現でき得る。このため、コンピュータ処理において計算量を低減でき、ひいては処理を高速化できる。

（１８）上記各実施形態では、仲介装置は、情報銀行４ａ〜６ａから取得されたパーソナルデータに基づく納品データを直接利用者装置２に送信する。しかし、データ利用者２ａに納品データを送信する仕方はこれに限られない。例えば、仲介装置が一旦納品データを仲介装置及び利用者装置のいずれでもない別の装置に送信する。そして、当該別の装置を介して納品データが利用者装置２に送信されてもよい。このように別の装置を経由して仲介装置から利用者装置２に納品データが送信される場合も、本願でいう「仲介装置が利用者装置２に納品データを送信する」に包含されるものとする。

（１９）前述した仲介装置の他、当該仲介装置を構成要素とするシステム、当該仲介装置としてコンピュータを機能させるためのプログラム、このプログラムを記憶した半導体メモリ等の非遷移的実体的記憶媒体、パーソナルデータを調達する方法など、種々の形態で本開示を実現することもできる。

（２０）上記各実施形態における１つの構成要素が有する複数の機能を、複数の構成要素によって実現したり、１つの構成要素が有する１つの機能を、複数の構成要素によって実現したりしてもよい。また、複数の構成要素が有する複数の機能を、１つの構成要素によって実現したり、複数の構成要素によって実現される１つの機能を、１つの構成要素によって実現したりしてもよい。また、上記各実施形態の構成の一部を省略してもよい。また、上記各実施形態の構成の少なくとも一部を、他の上記各実施形態の構成に対して付加又は置換してもよい。なお、請求の範囲に記載した文言によって特定される技術思想に含まれるあらゆる態様が本開示の実施形態である。

Claims (15)

1. データ利用者が欲するパーソナルデータの条件である対象条件を含むリクエスト情報を取得するように構成されたリクエスト取得部と、
   重複確認情報を取得するように構成された重複確認取得部であって、前記重複確認情報は、第１のパーソナルデータ管理者により管理されている第１のパーソナルデータと、前記第１のパーソナルデータ管理者とは異なる第２のパーソナルデータ管理者により管理されている第２のパーソナルデータと、が同一個人に係るパーソナルデータであることを示す情報である、重複確認取得部と、
   前記重複確認情報に基づいて調達プランを決定するように構成された決定部であって、前記調達プランは、前記第１のパーソナルデータ管理者及び前記第２のパーソナルデータ管理者を含む複数のパーソナルデータ管理者から調達するパーソナルデータに関する条件を示す、決定部と、
   前記決定部によって決定された前記調達プランに従いパーソナルデータを取得するように構成された取得送信部と、
   を備え、
   前記決定部は、前記重複確認情報により同一個人に係るパーソナルデータであることが示される前記第１のパーソナルデータ及び前記第２のパーソナルデータのうち、いずれか一方を調達する前記調達プランを決定する、仲介装置。
2. 請求項１に記載の仲介装置であって、
   前記決定部は、前記第１のパーソナルデータ及び前記第２のパーソナルデータのうち価格が安い方を調達する前記調達プランを決定する、仲介装置。
3. 請求項１又は請求項２に記載の仲介装置であって、
   前記複数のパーソナルデータ管理者のそれぞれは、当該パーソナルデータ管理者にパーソナルデータを預託した個人又はそのパーソナルデータに対して所定の識別情報である登録識別情報を付与し、
   前記重複確認情報は、同一個人に係る、前記第１のパーソナルデータ管理者の前記登録識別情報と、前記第２のパーソナルデータ管理者の前記登録識別情報と、を示す情報である、仲介装置。
4. 請求項１又は請求項２に記載の仲介装置であって、
   前記重複確認取得部は、前記複数のパーソナルデータ管理者から取得された複数のパーソナルデータ間の類似度を示す類似度情報を前記重複確認情報として取得する、仲介装置。
5. 請求項１から請求項４までのいずれか１項に記載の仲介装置であって、
   前記複数のパーソナルデータ管理者のそれぞれは情報銀行である、仲介装置。
6. データ利用者が欲するパーソナルデータの条件である対象条件を含むリクエスト情報を取得するように構成されたリクエスト取得部と、
   重複確認情報を取得するように構成された重複確認取得部であって、前記重複確認情報は、第１のパーソナルデータ管理者により管理されている第１のパーソナルデータと、前記第１のパーソナルデータ管理者とは異なる第２のパーソナルデータ管理者により管理されている第２のパーソナルデータと、が同一個人に係るパーソナルデータであることを示す情報である、重複確認取得部と、
   前記重複確認情報に基づいて調達プラン及び／又は納品データを決定するように構成された決定部であって、前記調達プランは、前記第１のパーソナルデータ管理者及び前記第２のパーソナルデータ管理者を含む複数のパーソナルデータ管理者から調達するパーソナルデータに関する条件を示し、前記納品データは、前記複数のパーソナルデータ管理者から調達されたパーソナルデータに基づくデータであって前記データ利用者が保有する利用者装置に送信されるデータである、決定部と、
   前記決定部によって決定された前記調達プランに従いパーソナルデータを取得する、及び／又は、前記決定部によって決定された納品データを前記利用者装置に送信する、ように構成された取得送信部と、
   を備え、
   前記複数のパーソナルデータ管理者のそれぞれは、当該パーソナルデータ管理者にパーソナルデータを預託した個人又はそのパーソナルデータに対して所定の識別情報である登録識別情報を付与し、
   同一個人に係る、前記第１のパーソナルデータ管理者の前記登録識別情報と、前記第２のパーソナルデータ管理者の前記登録識別情報と、は互いに異なり、
   前記重複確認情報は、同一個人に係る、前記第１のパーソナルデータ管理者の前記登録識別情報と、前記第２のパーソナルデータ管理者の前記登録識別情報と、を示す情報であり、
   前記複数のパーソナルデータ管理者のそれぞれは情報銀行である、仲介装置。
7. 請求項１から請求項６までのいずれか１項に記載の仲介装置であって、
   前記重複確認取得部は、前記重複確認情報を管理する又は前記重複確認情報を生成可能な外部装置から前記重複確認情報を取得する、仲介装置。
8. 請求項１から請求項６までのいずれか１項に記載の仲介装置であって、
   前記重複確認情報を記憶するように構成された記憶部を更に備え、
   前記重複確認取得部は、前記記憶部から前記重複確認情報を取得する、仲介装置。
9. データ利用者が欲するパーソナルデータの条件である対象条件を含むリクエスト情報を取得するように構成されたリクエスト取得部と、
   重複確認情報を取得するように構成された重複確認取得部であって、前記重複確認情報は、第１のパーソナルデータ管理者により管理されている第１のパーソナルデータと、前記第１のパーソナルデータ管理者とは異なる第２のパーソナルデータ管理者により管理されている第２のパーソナルデータと、が同一個人に係るパーソナルデータであることを示す情報である、重複確認取得部と、
   前記重複確認情報に基づいて調達プラン及び／又は納品データを決定するように構成された決定部であって、前記調達プランは、前記第１のパーソナルデータ管理者及び前記第２のパーソナルデータ管理者を含む複数のパーソナルデータ管理者から調達するパーソナルデータに関する条件を示し、前記納品データは、前記複数のパーソナルデータ管理者から調達されたパーソナルデータに基づくデータであって前記データ利用者が保有する利用者装置に送信されるデータである、決定部と、
   前記決定部によって決定された前記調達プランに従いパーソナルデータを取得する、及び／又は、前記決定部によって決定された納品データを前記利用者装置に送信する、ように構成された取得送信部と、
   を備え、
   前記複数のパーソナルデータ管理者のそれぞれは、当該パーソナルデータ管理者にパーソナルデータを預託した個人又はそのパーソナルデータに対して所定の識別情報である登録識別情報を付与し、
   同一個人に係る、前記第１のパーソナルデータ管理者の前記登録識別情報と、前記第２のパーソナルデータ管理者の前記登録識別情報と、は互いに異なり、
   前記重複確認情報は、同一個人に係る、前記第１のパーソナルデータ管理者の前記登録識別情報と、前記第２のパーソナルデータ管理者の前記登録識別情報と、を示す情報であり、
   前記重複確認取得部は、前記重複確認情報を管理する又は前記重複確認情報を生成可能な外部装置から前記重複確認情報を取得する、仲介装置。
10. 請求項６又は請求項９に記載の仲介装置であって、
    前記決定部は、前記重複確認情報に基づいて前記調達プランを決定する、仲介装置。
11. 請求項１から請求項１０までのいずれか１項に記載の仲介装置であって、
    前記決定部は、前記重複確認情報により同一個人に係るパーソナルデータであることが示される前記第１のパーソナルデータ及び前記第２のパーソナルデータの両方を調達する前記調達プランを決定する、仲介装置。
12. 請求項１から請求項１１までのいずれか１項に記載の仲介装置を備えるシステムであって、
    前記取得送信部によって取得されたパーソナルデータに応じた通知情報を取得するように構成された通知情報取得部であって、前記通知情報は、前記パーソナルデータ管理者にパーソナルデータを預託した個人に通知される情報である、通知情報取得部と、
    前記通知情報取得部によって取得された前記通知情報を送信するように構成された通知情報送信部と、
    を備えるシステム。
13. コンピュータを、
    データ利用者が欲するパーソナルデータの条件である対象条件を含むリクエスト情報を取得するように構成されたリクエスト取得部と、
    重複確認情報を取得するように構成された重複確認取得部であって、前記重複確認情報は、第１のパーソナルデータ管理者により管理されている第１のパーソナルデータと、前記第１のパーソナルデータ管理者とは異なる第２のパーソナルデータ管理者により管理されている第２のパーソナルデータと、が同一個人に係るパーソナルデータであることを示す情報である、重複確認取得部と、
    前記重複確認情報に基づいて調達プランを決定するように構成された決定部であって、前記調達プランは、前記第１のパーソナルデータ管理者及び前記第２のパーソナルデータ管理者を含む複数のパーソナルデータ管理者から調達するパーソナルデータに関する条件を示す、決定部と、
    前記決定部によって決定された前記調達プランに従いパーソナルデータを取得するように構成された取得送信部と、
    を備え、
    前記決定部は、前記重複確認情報により同一個人に係るパーソナルデータであることが示される前記第１のパーソナルデータ及び前記第２のパーソナルデータのうち、いずれか一方を調達する前記調達プランを決定する、仲介装置として機能させるコンピュータプログラム。
14. コンピュータを、
    データ利用者が欲するパーソナルデータの条件である対象条件を含むリクエスト情報を取得するように構成されたリクエスト取得部と、
    重複確認情報を取得するように構成された重複確認取得部であって、前記重複確認情報は、第１のパーソナルデータ管理者により管理されている第１のパーソナルデータと、前記第１のパーソナルデータ管理者とは異なる第２のパーソナルデータ管理者により管理されている第２のパーソナルデータと、が同一個人に係るパーソナルデータであることを示す情報である、重複確認取得部と、
    前記重複確認情報に基づいて調達プラン及び／又は納品データを決定するように構成された決定部であって、前記調達プランは、前記第１のパーソナルデータ管理者及び前記第２のパーソナルデータ管理者を含む複数のパーソナルデータ管理者から調達するパーソナルデータに関する条件を示し、前記納品データは、前記複数のパーソナルデータ管理者から調達されたパーソナルデータに基づくデータであって前記データ利用者が保有する利用者装置に送信されるデータである、決定部と、
    前記決定部によって決定された前記調達プランに従いパーソナルデータを取得する、及び／又は、前記決定部によって決定された納品データを前記利用者装置に送信する、ように構成された取得送信部と、
    を備え、
    前記複数のパーソナルデータ管理者のそれぞれは、当該パーソナルデータ管理者にパーソナルデータを預託した個人又はそのパーソナルデータに対して所定の識別情報である登録識別情報を付与し、
    同一個人に係る、前記第１のパーソナルデータ管理者の前記登録識別情報と、前記第２のパーソナルデータ管理者の前記登録識別情報と、は互いに異なり、
    前記重複確認情報は、同一個人に係る、前記第１のパーソナルデータ管理者の前記登録識別情報と、前記第２のパーソナルデータ管理者の前記登録識別情報と、を示す情報であり、
    前記複数のパーソナルデータ管理者のそれぞれは情報銀行である、仲介装置として機能させるコンピュータプログラム。
15. コンピュータを、
    データ利用者が欲するパーソナルデータの条件である対象条件を含むリクエスト情報を取得するように構成されたリクエスト取得部と、
    重複確認情報を取得するように構成された重複確認取得部であって、前記重複確認情報は、第１のパーソナルデータ管理者により管理されている第１のパーソナルデータと、前記第１のパーソナルデータ管理者とは異なる第２のパーソナルデータ管理者により管理されている第２のパーソナルデータと、が同一個人に係るパーソナルデータであることを示す情報である、重複確認取得部と、
    前記重複確認情報に基づいて調達プラン及び／又は納品データを決定するように構成された決定部であって、前記調達プランは、前記第１のパーソナルデータ管理者及び前記第２のパーソナルデータ管理者を含む複数のパーソナルデータ管理者から調達するパーソナルデータに関する条件を示し、前記納品データは、前記複数のパーソナルデータ管理者から調達されたパーソナルデータに基づくデータであって前記データ利用者が保有する利用者装置に送信されるデータである、決定部と、
    前記決定部によって決定された前記調達プランに従いパーソナルデータを取得する、及び／又は、前記決定部によって決定された納品データを前記利用者装置に送信する、ように構成された取得送信部と、
    を備え、
    前記複数のパーソナルデータ管理者のそれぞれは、当該パーソナルデータ管理者にパーソナルデータを預託した個人又はそのパーソナルデータに対して所定の識別情報である登録識別情報を付与し、
    同一個人に係る、前記第１のパーソナルデータ管理者の前記登録識別情報と、前記第２のパーソナルデータ管理者の前記登録識別情報と、は互いに異なり、
    前記重複確認情報は、同一個人に係る、前記第１のパーソナルデータ管理者の前記登録識別情報と、前記第２のパーソナルデータ管理者の前記登録識別情報と、を示す情報であり、
    前記重複確認取得部は、前記重複確認情報を管理する又は前記重複確認情報を生成可能な外部装置から前記重複確認情報を取得する、仲介装置として機能させるコンピュータプログラム。

Images