(58)【調査した分野】(Int.Cl.,DB名)
【発明を実施するための形態】
【0033】
以下、図面を参照しながら、本開示を実施するための形態を説明する。
【0034】
[1.第1実施形態]
[1−1.全体構成]
図1に示す調達システム1は、利用者装置2、仲介装置3及び複数の情報銀行装置4〜6を備える。
【0035】
利用者装置2は、パーソナルデータを利用するデータ利用者2aが保有する装置である。データ利用者2aは、パーソナルデータを利用して利益を上げる企業等である。
【0036】
ここで、本実施形態でいうパーソナルデータは、個人の識別性の有無にかかわらず、個人に関する情報全般を指す。パーソナルデータには、個人を特定、識別することができる個人情報が含まれる。ここでいう個人情報は、例えば、日本国個人情報保護法第2条第1項に規定の「個人情報」である。個人情報には、その情報自体で個人を識別できる情報のほか、他の情報と照合することができ、それにより個人を識別できる情報も含まれる。個人情報以外のパーソナルデータとしては、個人の位置情報や購入情報、IPアドレス、インターネット閲覧履歴など、企業やネット上に集積されている情報等が挙げられる。また、個人情報以外のパーソナルデータとして、個人に結び付けることができないように加工された個人の行動や状態などに関するデータ等が挙げられる。
【0037】
利用者装置2は、インターネット、専用無線/有線通信回線網のようなネットワークを介して仲介装置3に接続される。
【0038】
仲介装置3は、データ利用者2aに代わって、情報銀行装置4〜6に対してパーソナルデータのリクエストを行い、データ利用者2aに適した条件でパーソナルデータを買い付けてデータ利用者2aに納品するための装置である。仲介装置3は、例えば、データ利用者2aと情報銀行4a〜6aとの間のパーソナルデータの売買の仲介を行う業者により保有される。仲介装置3は、インターネット、専用無線/有線通信回線網のようなネットワークを介して利用者装置2及び情報銀行装置4〜6に接続される。仲介装置3のハードウェア構成及び機能については後で詳述する。
【0039】
情報銀行装置4〜6は、それぞれ別々の情報銀行4a〜6aに保有されている。情報銀行4a〜6aは、個人から預託されたパーソナルデータを管理するとともに当該パーソナルデータを企業等の第三者に提供する事業を営む。
【0040】
情報銀行装置4〜6には、個人が保有するスマートフォン、タブレット端末、パーソナルコンピュータ等の情報処理端末11〜17を介して個人から預託されたパーソナルデータが記憶されている。情報銀行装置4〜6は、インターネット、専用無線/有線通信回線網のようなネットワークを介して仲介装置3及び情報処理端末11〜17に接続される。後述するとおり、情報銀行装置4〜6は仲介装置3との間で各種情報をやり取りし、仲介装置3を介してパーソナルデータをデータ利用者2aに納品する。
【0041】
なお、
図1では3つの情報銀行装置4〜6のみが図示されているが、仲介装置3は一般には3つ以外の情報銀行装置とパーソナルデータ等のデータのやり取りを行う。
【0042】
[1−2.仲介装置]
次に、仲介装置3のハードウェア構成を
図2を用いて説明する。仲介装置3は、通信部31と、記憶部32と、制御部33と、を備える。
【0043】
通信部31は、仲介装置3をネットワークに接続するための通信インタフェースである。仲介装置3は、通信部31を介して、利用者装置2及び情報銀行装置4〜6と有線又は無線にてデータ通信可能である。また、仲介装置3は、通信部31を介してインターネットに接続し、インターネットを介して外部の装置とデータ通信可能であってもよい。
【0044】
記憶部32は、各種データを記憶する。
【0045】
制御部33は、CPU33aと、RAM、ROM、フラッシュメモリ等の半導体メモリ(以下、メモリ33b)と、を有する周知のマイクロコンピュータを中心に構成される。制御部33の各種機能は、CPU33aが非遷移的実体的記憶媒体に格納されたプログラムを実行することにより実現される。この例では、メモリ33bが、プログラムを格納した非遷移的実体的記憶媒体に該当する。また、このプログラムの実行により、プログラムに対応する方法が実行される。なお、制御部33を構成するマイクロコンピュータの数は1つでも複数でもよい。
【0046】
制御部33は、CPU33aがプログラムを実行することで後述する
図4に示すデータ調達処理を実行する。制御部33はデータ調達処理を実行することで、
図3に示すように、リクエスト取得部331、メタデータ要求生成部332、メタデータ要求送信部333、メタデータ受信部334、条件整理部335、調達プラン決定部336、データ要求生成部337、データ要求送信部338、データ受信部339、形式処理部340及びデータ送信部341として機能する。制御部33を構成するこれらの要素331〜341を実現する手法はソフトウェアに限るものではなく、その一部又は全部の要素を、論理回路やアナログ回路等を組み合わせたハードウェアを用いて実現してもよい。
【0047】
以下では、まず
図3を用いて各要素331〜341の機能の概要について説明する。その後、
図4のフローチャートを用いて各要素331〜341の機能を詳細に説明する。
<リクエスト取得部>
リクエスト取得部331は、通信部31を介して利用者装置2からのリクエスト情報を受信する。リクエスト情報は、データ利用者2aが欲するパーソナルデータの条件である対象条件を含む情報である。リクエスト情報の具体例については後述する。
<メタデータ要求生成部>
メタデータ要求生成部332は、リクエスト取得部331により受信されたリクエスト情報に基づき、情報銀行装置4〜6に送信されるメタデータ要求を生成する。ここでいうメタデータ要求とは、情報銀行装置4〜6にメタデータを要求するための情報である。ここでいうメタデータは、情報銀行4a〜6aが保有するパーソナルデータのうち、リクエスト情報に含まれる対象条件に合致するパーソナルデータの属性を示す情報である。ここでいうパーソナルデータの属性とは、パーソナルデータに係る個人の属性であり、例えば個人の年齢、性別等を意味する。もちろん、パーソナルデータの属性は、年齢及び性別以外の個人の属性であってもよい。換言すれば、パーソナルデータの属性は、当該パーソナルデータに含まれる、個人の年齢、性別等の各種属性を示す各データ項目を意味する。すなわち、パーソナルデータの属性は、パーソナルデータのデータ項目を意味する。
【0048】
本実施形態では、メタデータは、その情報銀行が保有している、対象条件に合致する全部又は一部のパーソナルデータについてのデータの概要を示す。ここでいうデータの概要は、例えば、パーソナルデータの一部の属性や、パーソナルデータの各属性に関する統計情報等であってもよい。
【0049】
メタデータは、情報銀行が保有している、対象条件に合致する全部又は一部のパーソナルデータがどのような属性のパーソナルデータから構成されるかを示す情報である。具体的には、後述するとおり、メタデータには、その情報銀行が保有する、対象条件に合致する全部又は一部のパーソナルデータの統計量の情報等が含まれる。メタデータ要求及びメタデータの具体例については後述する。
【0050】
また、本実施形態では、情報銀行装置4〜6ごとに取扱い可能なデータ形式が異なる。そのため、メタデータ要求生成部332は、各情報銀行装置4〜6の取扱い可能なデータ形式に合わせて情報銀行装置4〜6ごとにメタデータ要求を生成する。
<メタデータ要求送信部>
メタデータ要求送信部333は、メタデータ要求生成部332により生成されたメタデータ要求を情報銀行装置4〜6に通信部31を介して送信する。メタデータ要求を受信した情報銀行装置4〜6は、メタデータ要求に対する応答として、メタデータを仲介装置3に送信する。
<メタデータ受信部>
メタデータ受信部334は、情報銀行装置4〜6からメタデータを通信部31を介して受信する。
<条件整理部>
条件整理部335は、情報銀行装置4〜6から受信されたメタデータから取引条件を整理する。
<調達プラン決定部>
調達プラン決定部336は、メタデータ受信部334により受信されたメタデータに基づいて、データ利用者2aに適した調達プランを決定する。ここでいう調達プランとは、情報銀行装置4〜6が保有する、対象条件に合致するパーソナルデータの中から調達するパーソナルデータに関する条件を示す。つまり、調達プランにより示される条件に合致するパーソナルデータが情報銀行装置4〜6から調達(すなわち購入)される。調達プランの決定ロジックについては後述する。
<データ要求生成部>
データ要求生成部337は、調達プラン決定部336によって決定された調達プランに従い、データ要求を生成する。データ要求は、情報銀行装置4〜6にパーソナルデータを要求するためのデータである。データ要求生成部337は、各情報銀行装置4〜6の取扱い可能なデータ形式に合わせて情報銀行装置4〜6ごとにデータ要求を生成する。データ要求の具体例については後述する。
<データ要求送信部>
データ要求送信部338は、データ要求生成部337によって生成されたデータ要求を情報銀行装置4〜6に通信部31を介して送信する。
<データ受信部>
データ受信部339は、データ要求を受信した情報銀行装置4〜6から納品データを通信部31を介して受信する。納品データは、データ要求において指定されたパーソナルデータを含む。納品データの具体例については後述する。
<形式処理部>
形式処理部340は、複数の情報銀行装置4〜6から受信された納品データのデータ形式を共通のデータ形式に合わせ、1つのデータに統合することで統合データを生成する。統合データの具体例については後述する。
<データ送信部>
データ送信部341は、形式処理部340により生成された統合データを利用者装置2に通信部31を介して送信する。これにより、情報銀行4a〜6aから調達されたパーソナルデータがデータ利用者2aに納品される。
【0051】
[1−3.処理]
次に、仲介装置3の制御部33が実行するデータ調達処理について、
図4のフローチャートを用いて説明する。なお、データ調達処理は、リクエスト情報を利用者装置2から通信部31を介して受信することにより開始される。なお、データ利用者2aからリクエスト情報が受信されると、受信されたリクエスト情報は記憶部32に記憶される。
【0052】
<S101>
S101で、リクエスト取得部331は、データ利用者2aからのリクエスト情報を記憶部32から取得する。本実施形態のリクエスト情報は、
図5に示す各項目を含む。すなわち、リクエスト情報は、タイムスタンプ、トランザクションID、文タイプ、宛先、送信元及び文内容を含む。なお、文タイプは、その情報が、リクエスト情報、メタデータ要求、メタデータ等のどのデータに該当するかを示すデータである。
【0053】
文内容には、予算、報酬、対象条件、要求項目、分布集計軸、利用組織、利用目的及び利用条件の情報が含まれる。
【0054】
予算の情報には、当該取引についてデータ利用者2aが支払い可能な予算額の情報と、データ利用者2aの費用の決済手段を示す情報と、が含まれる。
【0055】
報酬の情報は、パーソナルデータを提供した個人に対するデータ利用者2aからの報酬の情報である。報酬の情報には、報酬の形式、報酬の発行者、報酬の発行タイミング、報酬に係る特典等を使用可能な地域、報酬の発効時刻及び失効時刻等の情報が含まれる。
【0056】
対象条件は、データ利用者2aが欲するパーソナルデータの条件である。対象条件は、例えば、パーソナルデータに係る個人の属性(例えば性別、年齢、習慣等)を指定する条件である。データ利用者2aが、条件が異なる複数のパーソナルデータを欲する場合、文内容に含まれる対象条件も複数になる。また、文内容には、対象条件ごとにその対象条件に合致するパーソナルデータをデータ利用者2aがいくつ欲するかの件数の情報が含まれる。
【0057】
例えば、
図5に示す例では、1つ目の対象条件は、パーソナルデータに係る個人の性別が男性であり、レシピサイトの直近3ヶ月間の閲覧回数が3回以上である。また、データ利用者2aが欲するこの対象条件に合致するパーソナルデータの件数は1000件である。2つ目の対象条件は、パーソナルデータに係る個人の性別が女性であり、レシピサイトの直近3ヶ月間の閲覧回数が7回以上である。また、データ利用者2aが欲するこの対象条件に合致するパーソナルデータの件数は1000件である。
【0058】
要求項目は、データ利用者2aが納品を希望する、パーソナルデータの項目(例えば性別、年代、居住都道府県等)である。
【0059】
分布集計軸は、情報銀行装置4〜6から送信されるメタデータに含まれる、パーソナルデータの一部の項目を指定する。すなわち、後述するとおり、情報銀行装置4〜6から送信されるメタデータには、情報銀行4a〜6aが保有する、対象条件に合致する全部又は一部のパーソナルデータの一覧(すなわちリスト)が含まれる。当該リストには、パーソナルデータのIDごとに、当該パーソナルデータの一部の項目と、当該パーソナルデータのデータ価格と、が含まれる。ここでいうパーソナルデータの一部の項目は、換言すれば、パーソナルデータに係る個人の一部の属性であり、例えば未婚率、年代等である。分布集計軸は、当該リストに含まれるパーソナルデータの前記一部の項目を指定する。なお、本実施形態では、分布集計軸に含まれるパーソナルデータの属性は、対象条件により指定された属性以外の属性に設定される。
【0060】
利用組織、利用目的及び利用条件の情報は、パーソナルデータの利用組織、利用目的及び利用条件を示す。利用組織の情報には、例えば、利用組織の法人番号、名称、住所、国、業種等が含まれる。利用目的の情報には、例えば、利用の種別(顧客分析、ダイレクトメール送信等)や個別の利用目的が含まれる。個別の利用目的は、例えば、顧客情報拡充、統計作成、パーソナルデータの提供元の本人へのアクセス、広告配信等である。
【0061】
リクエスト取得部331は、上記のようなリクエスト情報を利用者装置2から受信する。
【0062】
<S102>
続いて、S102で、メタデータ要求生成部332は、S101で受信されたリクエスト情報に基づいて、メタデータ要求を生成する。メタデータ要求は、パーソナルデータの調達先の情報銀行4a〜6aごとに生成される。具体的には、
図6には第1情報銀行4aに対するメタデータ要求の例が示される。また、
図7には第2情報銀行5aに対するメタデータ要求の例が示されている。
図6及び
図7に示すメタデータ要求はいずれも同じ項目を含む。
【0063】
具体的には、メタデータ要求は、タイムスタンプ、トランザクションID、文タイプ、参照トランザクションID、宛先、送信元及び文内容を含む。参照トランザクションIDは、S101で受信されたリクエスト情報、換言すれば、当該メタデータ要求に関連するリクエスト情報のトランザクションIDである。
【0064】
文内容には、報酬、対象条件、要求項目、分布集計軸、利用組織、利用目的及び利用条件の情報が含まれる。文内容に含まれるこれらの情報はリクエスト情報に含まれるものと同じである。
【0065】
ここで、本実施形態では、情報銀行装置4〜6ごとに取扱い可能なデータ形式が異なる。そのため、メタデータ要求は、送信先の情報銀行装置4〜6の取扱い可能なデータ形式に合わせて生成される。
【0066】
例えば、第1情報銀行装置4が取扱い可能なデータ形式では、パーソナルデータに係る個人の性別を表す変数は「Gender」であり、当該変数に格納される値「1」に対して「個人の性別は男である」との意味が対応付く。また、変数「Gender」に格納される値「2」に対して「個人の性別は女性である」との意味が対応付く。
【0067】
一方、例えば、第2情報銀行装置5が取扱い可能なデータ形式では、パーソナルデータに係る個人の性別を表す変数は「性別」であり、当該変数に格納される値「男性」に対して「個人の性別は男である」との意味が対応付く。また、変数「性別」に格納される値「女性」に対して「個人の性別は女性である」との意味が対応付く。
【0068】
そこで、メタデータ要求生成部332は、例えば
図6に示す第1情報銀行装置4に対するメタデータ要求では、対象条件の項目において、「パーソナルデータに係る個人の性別が男性である」との条件を「Gender=1」などのようなデータ形式で指定する。
【0069】
一方、メタデータ要求生成部332は、例えば
図7に示す第2情報銀行装置5に対するメタデータ要求では、対象条件の項目において、「パーソナルデータに係る個人の性別が男性である」との条件を「性別=男性」などのようなデータ形式で指定する。
【0070】
なお、情報銀行装置4〜6ごとのメタデータ要求は、
図8A及び
図8Bに示すようなカテゴリテーブルマスタに基づいて作成される。カテゴリテーブルマスタは、メタデータ要求等に含まれる各項目を、各情報銀行装置4〜6の取扱い可能なデータ形式に変換するための情報である。或る情報銀行装置のカテゴリテーブルマスタでは、その情報銀行装置の取扱い可能なデータ形式で記述された「変数名」、「値」及び「意味」が互いに対応付けられて設定されている。本実施形態では、仲介装置3の取引先である各情報銀行装置4〜6のカテゴリテーブルマスタが、あらかじめ仲介装置3の記憶部32に記憶されている。ただし、カテゴリテーブルマスタの所在はこれに限られない。例えば、メタデータ要求を生成するに際し、仲介装置3がカテゴリテーブルマスタを要求する情報を各情報銀行装置4〜6に送信し、その応答信号として各情報銀行装置4〜6のカテゴリテーブルマスタが取得されてもよい。つまり、メタデータ要求を生成するタイミングでカテゴリテーブルマスタが取得されてもよい。
【0071】
<S103>
続いて、S103で、メタデータ要求送信部333は、S102で生成されたメタデータ要求を情報銀行装置4〜6に通信部31を介して送信する。メタデータ要求を受信した情報銀行装置4〜6は、メタデータ要求の応答情報として、メタデータを仲介装置3に送信する。
【0072】
<S104>
続いて、S104で、メタデータ受信部334は、各情報銀行装置4〜6からメタデータを通信部31を介して受信する。メタデータは、各情報銀行装置4〜6の取扱い可能なデータ形式で記述されている。
【0073】
本実施形態のメタデータは、
図9に示す各項目を含む。
図9には、第2情報銀行装置5から受信されたメタデータが示される。
【0074】
メタデータには、タイムスタンプ、トランザクションID、文タイプ、参照トランザクションID、宛先、送信元、カテゴリコードマスタ及び文内容が含まれる。参照トランザクションIDは、当該メタデータに関連するメタデータ要求、換言すれば、当該メタデータの送信元の情報銀行装置に送信されたメタデータ要求のトランザクションIDである。カテゴリコードマスタは、当該メタデータの送信元の情報銀行装置に関するカテゴリコードマスタを特定する情報である。
【0075】
文内容には、対象者の情報である対象者情報が含まれる。対象者情報は、リクエスト情報に含まれる対象条件と、当該情報銀行が保有するパーソナルデータのうち対象条件に合致する全部又は一部のパーソナルデータの件数と、を含む。また、対象者情報は、対象条件に合致する全部又は一部のパーソナルデータがどのような属性のパーソナルデータから構成されるかを示す。
【0076】
具体的には、対象者情報は、要求項目統計量を含む。要求項目統計量は、要求項目で指定される各属性に関するパーソナルデータの統計量(平均、分散、歪度、中央値等)や最大値及び最小値などである。また、対象者情報には、分散共分散行列、パーソナルデータのデータ価格分布の情報とその他多変量の統計量の情報とが含まれる。
【0077】
ここで、データ価格分布の情報は、パーソナルデータを分布集計軸により指定される属性で分類した際の各分類に含まれるパーソナルデータのデータ価格を示す。例えば、分布集計軸において「未既婚、年代、3ヶ月雑誌購買有無」の属性が指定されているとする。この場合、データ価格分布の情報には、「未既婚:未婚、年代:30、3ヶ月雑誌購買有無=無」との分類に含まれるパーソナルデータのデータ価格「260,280,290,・・・」が含まれ得る。
【0078】
本実施形態では、リクエスト情報で指定されたパーソナルデータの件数よりも多くの件数のパーソナルデータの情報がメタデータに含まれることが想定される。より詳細には、メタデータに含まれる、或る対象条件に合致するパーソナルデータの情報の件数は、リクエスト情報において指定されたその対象条件に合致するパーソナルデータの件数よりも多いことが想定される。これは、リクエスト情報で指定された件数のパーソナルデータをメタデータを基に選択する際に、複数通りのパーソナルデータの選択の仕方(すなわち調達プラン)を検討し、複数通りの調達プランの中からデータ利用者2aに適した調達プランを決定するためである。ただし、メタデータによりその属性が示されるパーソナルデータの件数はこれに限られず、当該パーソナルデータの件数は、例えば、リクエスト情報で指定されたパーソナルデータの件数と同数であってもよい。
【0079】
<S105>
続いて、S105で、条件整理部335は、各情報銀行装置4〜6のデータ形式に合わされたメタデータから取引条件を整理する。具体的には、条件整理部335は、各情報銀行装置4〜6のカテゴリテーブルマスタを利用して、各情報銀行装置4〜6のデータ形式に合わされたメタデータを共通のデータ形式に合わせ、取引条件を整理する。
【0080】
また、条件整理部335は、S104で受信された各情報銀行装置4〜6からのメタデータに基づき、
図10の破線で示すようなリスト(以下、メタデータリスト)を生成する。メタデータリストは、パーソナルデータのIDと、データソースと、分布集計軸により指定される属性と、データ価格と、が対応付けられたデータである。データソースは、そのデータがどの情報銀行からのデータであるかを識別する情報である。前述のとおり、本実施形態では、リクエスト情報で指定されたパーソナルデータの件数よりも多くの件数のデータを含むメタデータリストが生成される。なお、
図10のメタデータリストの「データソース」の列において、「第1」は第1の情報銀行4aを意味し、「第2」は第2の情報銀行5aを意味する。
【0081】
<S106>
続いて、S106で、調達プラン決定部336は、S105で生成されたメタデータリストに基づいて、データ利用者2aに適した調達プランを決定する。本実施形態では、調達プラン決定部336は、情報銀行装置4〜6が保有する個々のパーソナルデータのデータ価格と、データ利用者2aが指定した予算額と、に基づき、調達プランを決定する。さらに、調達プラン決定部336は、メタデータにより示される、分布集計軸により指定された属性に着目したときのパーソナルデータの分布(以下、元データ分布)の再現性に基づき調達プランを決定する。つまり、調達プラン決定部336は、データ利用者2aの予算額の範囲内で、調達プランにより調達されるパーソナルデータのデータ分布が元データ分布に近づくように調達プランを決定する。
【0082】
以下、調達プランの決定の仕方を
図10を用いて具体的に説明する。
図10では、簡単のため、100個のデータから成るメタデータリストを考える。この事例ではデータ利用者2aからのリクエスト情報には1つの対象条件のみが含まれているとする。例えば、
図5の対象条件1の「パーソナルデータに係る個人の性別が男性であり、レシピサイトの直近3ヶ月間の閲覧回数が3回以上である」との対象条件のみがリクエスト情報に含まれているとする。
図10の100個のデータはこの対象条件に合致するデータである。そして、データ利用者2aが欲するこの対象条件に合致するパーソナルデータの件数は40件であるとする。つまり、前記100個のデータの中から40個のデータを選択する。また、データ利用者2aの予算額は11000円であるとする。
【0083】
データ価格の総額が最も安い調達プランは、データ価格でデータを昇順でソートし、1番目から40番目までのデータを購入するプランAである。なお、
図10では、調達プランにおいて購入されるデータには「1」のフラグが立ち、購入されないデータには「0」のフラグが立つ。プランAの購入データ価格の総額は10570円である。しかしながら、例えば未婚及び未既の比は、元の100個のデータ(以下、元データ)では59:41(≒3:2)であるのに対してプランAでは12:28(≒1:2.5)であり、元データの分布とズレている。なお、
図10では、未婚に対応する値は「0」であり、既婚に対応する値は「1」である。すると、実際に調達して得られるパーソナルデータの他の項目についても元データの分布を再現しない懸念がある。そこで、購入されるデータの内訳が異なる他のパターン(例えば
図10のプランBやプランC等)も検討し、プランAと同様にデータ価格の総額と元データの分布である元データ分布からのズレとを評価する。なお、元データ分布とのズレは、例えばKL(Kullback-Leibler)-divergence(カルバック・ライブラー情報量)等の指標値を用いて評価することができる。
図10に示す例では元データ分布とのズレが最も小さい調達プランはプランCであるが、データ価格の総額が12420円で予算オーバーである。よって、予算額の範囲内で元データ分布とのズレが最小であるプランBが調達プランとして決定採用される。このように、複数の調達プランの中から予算額の範囲内で元データ分布とのズレが最小のプランを調達プランとして決定するのが本実施形態の調達プランの決定ロジックである。なお、上記ではリクエスト情報に1つの対象条件のみが含まれている場合を例示して説明したが、リクエスト情報に複数の対象条件が含まれている場合も同様である。なお、リクエスト情報に複数の対象条件が含まれている場合には、リクエスト情報で指定された各対象条件の件数を変えないように調達されるデータを変更して、複数のプランを検討する。
【0084】
<S107>
続いて、S107で、データ要求生成部337は、調達プラン決定部336により決定された調達プランに従い、パーソナルデータを要求するデータ要求を生成する。データ要求生成部337は、各情報銀行装置4〜6の取扱い可能なデータ形式に合うように情報銀行装置4〜6ごとにデータ要求を生成する。
【0085】
図11には第1情報銀行4aに対するデータ要求の例が示される。
図12には第2情報銀行5aに対するデータ要求の例が示される。これらのデータ要求はいずれも同じ項目を含む。
【0086】
具体的には、データ要求は、タイムスタンプ、トランザクションID、文タイプ、参照トランザクションID、宛先、送信元及び文内容が含まれる。参照トランザクションIDは、当該データ要求に関連するメタデータ、換言すれば、当該データ要求の送信先の情報銀行装置から受信されたメタデータのトランザクションIDである。
【0087】
文内容には、各対象条件に対応した対象者情報が含まれる。対象者情報には、条件文、件数、支払額及び購入データの情報が含まれる。
【0088】
条件文は、対応する対象条件を表す。件数及び支払額は、対応する対象条件について当該データ要求の送信先の情報銀行装置から調達するパーソナルデータの件数及び支払額を表す。
【0089】
購入データは、当該データ要求の送信先の情報銀行装置から調達するパーソナルデータを特定する。具体的には、購入データは、集計分布軸により指定された各属性とデータ価格とにより調達するパーソナルデータを指定する。
【0090】
また、文内容には、データ利用者2aが納品を希望する、パーソナルデータの項目である要求項目が含まれる。
【0091】
データ要求生成部337は、各情報銀行装置4〜6の取扱い可能なデータ形式に合うように各情報銀行装置4〜6のカテゴリコードマスタを用いて情報銀行装置4〜6ごとにデータ要求を生成する。
【0092】
<S108>
続いて、S108で、データ要求送信部338は、S107で生成されたデータ要求を情報銀行装置4〜6に通信部31を介して送信する。
【0093】
<S109>
続いて、S109で、データ受信部339は、データ要求を受信した情報銀行装置4〜6から、
図13に示すような、データ要求にて指定されたパーソナルデータを含む納品データを受信する。
【0094】
具体的には、納品データは、タイムスタンプ、トランザクションID、文タイプ、参照トランザクションID、宛先、送信元及び文内容が含まれる。参照トランザクションIDは、当該納品データに関連するデータ要求、換言すれば、当該納品データの送信先の情報銀行装置に送信されたデータ要求のトランザクションIDである。
【0095】
文内容には、各対象条件に対応した対象者情報が含まれる。対象者情報には、条件文、件数及びデータ本体の情報が含まれる。条件文及び件数は、データ要求に含まれるものと同じである。データ本体は、データ要求に含まれる購入データで指定されたパーソナルデータである。データ本体には、パーソナルデータの項目のうち要求項目により指定された項目が含まれる。また、文内容には、要求項目の情報が含まれる。
【0096】
<S110>
続いて、S110で、形式処理部340は、複数の情報銀行装置4〜6から受信された納品データのデータ形式を揃える。具体的には、形式処理部340は、各情報銀行装置4〜6から受信された納品データのデータ形式を共通のデータ形式に変換する。そして、形式処理部340は、共通のデータ形式に変換された各情報銀行装置4〜6からの納品データを1つのデータに統合する。以下、具体的に説明する。
【0097】
まず、各情報銀行装置4〜6からの納品データのデータ形式を共通のデータ形式に変換するに当たり、形式処理部340は、
図14に示すような標準辞書を使用する。標準辞書は、記憶部32に記憶されている。標準辞書は、パーソナルデータに含まれ得る各項目について仲介装置3における規定の意味、変数名及び値が互いに対応付けられて設定されたデータである。以下、規定の変数名及び値をそれぞれ「標準変数名」及び「標準値」という。この標準辞書を用いて形式処理部340は、まず各情報銀行装置4〜6のデータ変換用辞書を作成する。データ変換用辞書は、各情報銀行装置4〜6の納品データの変数名及び値を、標準辞書に規定された標準変数名及び標準値に変換するためのデータである。
【0098】
データ変換用辞書を作成するに際し、形式処理部340は、その情報銀行の
図8Aや
図8Bに示すカテゴリテーブルマスタと
図14に示す標準辞書とを「意味」の項目で突き合わせる。なお、この突き合わせ(すなわちマッチング)を行うに当たり、例えば双方のデータの「意味」の項目内のテキストを単純にマッチングされてもよく、またその他の方法でマッチングさせてもよい。
【0099】
カテゴリテーブルマスタと標準辞書とを「意味」の項目で突き合わせると、カテゴリテーブルマスタに含まれる「変数名」及び「値」と、標準辞書に含まれる「標準変数名」及び「標準値」と、そして「意味」と、が対応付けられた
図15に示すようなデータ変換辞書が生成される。なお、データ変換辞書は、各情報銀行装置4〜6からの納品データのデータ形式を共通のデータ形式に変換する際に生成されてもよく、あらかじめ生成されて記憶部32に記憶されていてもよい。
【0100】
そして、形式処理部340は、情報銀行装置から送信された納品データの変数及び値を、その情報銀行装置のデータ変換辞書を使用して標準変数及び標準値に変換する。これにより、各情報銀行装置4〜6から受信された納品データのデータ形式が共通のデータ形式に変換される。
【0101】
例えば、
図15に示す第1情報銀行装置4のデータ変換用辞書を使用して、
図16Aに示す第1情報銀行装置4からの納品データは、
図17に示す変換後の納品データに変換される。同様に、図示省略する第2情報銀行装置5のデータ変換用辞書を使用して、
図16Bに示す第2情報銀行5aからの納品データは、
図18に示す変換後の納品データに変換される。
【0102】
そして、形式処理部340は、各情報銀行装置4〜6の変換後の納品データを1つのデータに統合し、
図19に示すような統合データを生成する。なお、形式処理部340は、統合データを生成するに際し、各パーソナルデータのIDを振り直し、各情報銀行装置4〜6の納品データを順次積み上げる。また、統合データでは、或る情報銀行装置からのパーソナルデータと別の情報銀行装置からのパーソナルデータとが互いに区別可能になっている。例えば、
図19に示す統合データでは、第1情報銀行4aからのパーソナルデータのIDには「b」が付され、第2情報銀行5aからのパーソナルデータには「a」が付されている。
【0103】
形式処理部340はこのようにして複数の情報銀行装置4〜6からの納品データのデータ形式を揃え、1つのデータに統合する。
【0104】
<S111>
続いて、S111で、データ送信部341は、形式処理部340により生成された統合データをデータ利用者2aに送信する。
【0105】
制御部33は、S111を実行すると、
図4のデータ調達処理を終了する。
【0106】
[1−4.効果]
以上詳述した第1実施形態によれば、以下の効果が得られる。
【0107】
(1a)本実施形態では、調達プラン決定部336は、情報銀行装置4〜6から受信されたメタデータに基づいて、データ利用者2aに適した調達プランを決定する。そして、データ要求送信部338は、決定された調達プランに従いデータ要求を情報銀行装置4〜6に送信し、データ受信部339は情報銀行装置4〜6からパーソナルデータを受信する。そして、データ送信部341は、受信されたパーソナルデータをデータ利用者2aに送信する。
【0108】
よって、情報銀行装置4〜6が保有しているパーソナルデータを把握しづらい中でデータ利用者2aが直接情報銀行装置4〜6に問い合わせてパーソナルデータを調達する場合と比較して、パーソナルデータの調達をより容易に行うことができ、かつ、データ利用者2aが行う通信の通信量を低減できる。
【0109】
(1b)本実施形態では、仲介装置3は、情報銀行4a〜6aが保有する情報銀行装置4〜6からメタデータを取得する。
【0110】
ここで、仲介装置3が、メタデータを自身の記憶部32に記憶し、記憶部32に記憶されたメタデータを定期的に更新し、記憶部32からメタデータを取得する構成が考えられる。しかし、このような構成では、記憶部32から取得されたメタデータが最新のメタデータに更新されておらず、調達プラン決定部336が古いメタデータに基づいて調達プランを決定する場合がある。これに対し、本実施形態の構成によれば、仲介装置3は情報銀行装置4〜6からメタデータを取得するため、最新の内容のメタデータに基づき調達プランを決定することができる。
【0111】
(1c)本実施形態では、調達プラン決定部336は、情報銀行4a〜6aが管理するパーソナルデータのうち対象条件に合致するパーソナルデータの属性を示す情報であるメタデータに基づいて、調達プランを決定する。
【0112】
したがって、仲介装置3は、情報銀行4a〜6aが管理するパーソナルデータのうち対象条件に合致するパーソナルデータの属性を踏まえて調達プランを決定することができる。
【0113】
(1d)本実施形態では、メタデータ要求送信部333は、リクエスト受信部331がリクエスト情報を取得した場合にメタデータ要求を情報銀行装置4〜6に送信する。そして、メタデータ受信部334は、情報銀行装置4〜6からメタデータを受信する。
【0114】
よって、仲介装置3は、利用者装置2からリクエスト情報を取得した場合に、情報銀行装置4〜6に問合せを行い、最新のメタデータを取得する。したがって、最新のメタデータに基づき調達プランを決定することができる。
【0115】
(1e)本実施形態では、調達プラン決定部336は、情報銀行装置4〜6が保有する個々のパーソナルデータの価格と、リクエスト情報に含まれる予算額と、に基づき、調達プランを決定する。したがって、データ利用者2aの予算額に応じて適切な調達プランを決定できる。
【0116】
(1f)本実施形態では、調達プラン決定部336は、調達プランにより調達されるパーソナルデータの属性に基づく分布が、メタデータにより示される元データ分布に近づくように調達プランを決定する。
【0117】
例えば、元データ分布を無視してパーソナルデータの調達プランを決定した場合、元データ分布に対して偏った分布でパーソナルデータが調達される可能性がある。その結果、パーソナルデータの要求項目に含まれる特定の項目についてデータ利用者2aが集計等したときに元データの分布を再現せず、偏った結果が得られる場合がある。
【0118】
これに対して、本実施形態の構成によれば、元データ分布の再現性に基づき調達プランを決定するため、実際にパーソナルデータを調達した際にデータの偏りが発生することを抑制できる。
【0119】
特に、本実施形態では、データ利用者2aの予算額の範囲内で、データの偏りが発生することを出来るだけ抑制することができる。
【0120】
(1g)本実施形態では、調達プラン決定部336は、複数の情報銀行装置4〜6から受信されたメタデータに基づいて、複数の情報銀行装置4〜6が保有する対象条件に合致するパーソナルデータの中から実際に調達するパーソナルデータに関する条件を示す調達プランを決定する。データ受信部339は複数の情報銀行装置4〜6からパーソナルデータを受信し、データ送信部341は複数の情報銀行装置4〜6から受信されたパーソナルデータをデータ利用者2aに送信する。
【0121】
よって、情報銀行装置4〜6が保有しているパーソナルデータを把握しづらい中でデータ利用者2aが複数の直接情報銀行装置4〜6に問い合わせてパーソナルデータを調達する場合と比較して、複数の情報銀行装置4〜6からデータ利用者2aに適したパーソナルデータをより容易に調達することができる。
【0122】
(1h)本実施形態では、形式処理部340は、複数の情報銀行装置4〜6から受信されたパーソナルデータのデータ形式を共通のデータ形式に揃える。そして、データ送信部341は、形式処理部340によりデータ形式が合わせられた複数の情報銀行装置4〜6からのパーソナルデータを、利用者装置2に送信する。
【0123】
したがって、データ形式を共通のデータ形式に揃えることで、データ利用者2aにとって取扱いしやすいデータ形式でパーソナルデータを納品することができる。
【0124】
[2.第2実施形態]
[2−1.第1実施形態との相違点]
第2実施形態は、基本的な構成は第1実施形態と同様であるため、共通する構成については説明を省略し、相違点を中心に説明する。なお、第1実施形態と同じ符号は、同一の構成を示すものであって、先行する説明を参照する。
【0125】
前述した第1実施形態では、仲介装置3は、利用者装置2からリクエスト情報を受信するとメタデータ要求を情報銀行装置4〜6に送信し、情報銀行装置4〜6からメタデータを受信する。
【0126】
これに対し、第2実施形態では、
図2及び
図20に示す仲介装置7は、任意の対象条件に対応するメタデータを含むメタデータのセット(以下、メタデータセット)を記憶した記憶部72を備える。そして、仲介装置7は、データ利用者2aからリクエスト情報を受信すると、情報銀行装置4〜6からメタデータを取得するのではなく自身が備える記憶部72からメタデータを取得する点で、第1実施形態と相違する。以下、第2実施形態について詳細に説明する。
【0127】
第2実施形態の仲介装置7は、
図2に示すように、通信部71と、記憶部72と、制御部73と、を備える。これらの構成71〜73のハードウェア構成は、第1実施形態の仲介装置3の各構成31〜33と同一である。ただし、記憶部72に記憶されているデータが第1実施形態と異なる。具体的には、記憶部72には、各情報銀行4a〜6aに関するメタデータセットが記憶されている。
【0128】
メタデータセットは、リクエスト情報に含まれ得る任意の対象条件に対し、その対象条件に対応するメタデータを取得できるようなデータセットである。換言すれば、メタデータセットは、リクエスト情報に含まれ得る任意の対象条件に対し、その対象条件に対応するメタデータに含まれる要求項目統計量やデータ価格分布等の各情報を取得できるようなデータセットである。記憶部72には、仲介装置7がパーソナルデータを請求し得る全ての情報銀行4a〜6aに関するメタデータを含むメタデータセットが記憶されている。
【0129】
具体的には例えば、メタデータセットは、仲介装置7がパーソナルデータを請求し得る全ての情報銀行が保有するパーソナルデータの年齢、性別、未既婚、雑誌購読有無等の各属性に関する統計量や最大値、最小値等の情報を含む。また、メタデータセットは、仲介装置7がパーソナルデータを請求し得る全ての情報銀行4a〜6aについて、任意の対象条件(すなわちパーソナルデータの属性の任意の組合せ)に該当するパーソナルデータの件数の情報を含む。また、或る情報銀行のメタデータセットは、任意の対象条件について、その対象条件に該当するパーソナルデータのデータ価格分布の情報を含む。記憶部72には、このようなメタデータセットが記憶されている。
【0130】
本実施形態では、記憶部72に記憶されているメタデータセットは、所定頻度(例えば1ヶ月に1度や1週間に1度)で定期的に更新されることが想定される。なお、データセットの更新は種々の方法で行われ得るが、例えば次のようにして行われてもよい。すなわち、仲介装置7の保有者が各情報銀行4a〜6aからメタデータセットを記憶した記憶媒体を受領し、受領された記憶媒体内のメタデータセットを記憶部72に記憶することでメタデータセットの更新が行われてもよい。
【0131】
一方、制御部73は、CPU73aがプログラムを実行することで後述する
図21に示すデータ調達処理を実行する。制御部73はデータ調達処理を実行することで、
図20に示すように、リクエスト取得部331、メタデータ取得部731、更新処理部732、調達プラン決定部336、データ要求生成部337、データ要求送信部338、データ受信部339、形式処理部340及びデータ送信部341として機能する。つまり、第1実施形態の要求生成部332、メタデータ要求送信部333、メタデータ受信部334及び条件整理部335に代えてメタデータ取得部731及び更新処理部732として機能する点で、第2実施形態の制御部73は、第1実施形態の制御部33と相違する。
<メタデータ取得部>
メタデータ取得部731は、リクエスト取得部331により受信されたリクエスト情報に基づき、記憶部72からメタデータを取得する。具体的には、メタデータ取得部731は、リクエスト情報に応じた、各情報銀行4a〜6aに関するメタデータを、メタデータセットから取得する。
<更新処理部>
更新処理部732は、記憶部72に記憶されたメタデータセットを更新する。
【0132】
[2−2.処理]
次に、第2実施形態の仲介装置7の制御部73が、第1実施形態のデータ調達処理(
図4)に代えて実行するデータ調達処理について、
図21のフローチャートを用いて説明する。なお、
図21のフローチャートにおいて、S201,S203〜S208の処理(すなわちS202及びS209以外の処理)は、前述した
図4のS101,S106〜S111とそれぞれ同様である。よって、以下では、これらの処理の説明を省略し、相異点であるS202及びS209のみ説明する。
<S202>
S202で、メタデータ取得部731は、S201で取得されたリクエスト情報と、記憶部72に記憶されているメタデータセットと、に基づき、メタデータを取得する。
<S209>
S209で、更新処理部732は、記憶部72に記憶されたメタデータセットを更新する。例えば、更新処理部732は、統合データに含まれるパーソナルデータの属性の統計情報やデータ価格分布等の情報が記憶部72に記憶されているメタデータセットの情報と異なる場合、メタデータセットの情報を納品データに含まれる情報に更新する。
【0133】
[2−3.効果]
以上詳述した第2実施形態によれば、前述した第1実施形態の効果(1c),(1e)〜(1h)に加え、以下の効果が得られる。
【0134】
(2a)本実施形態では、調達プラン決定部336は、記憶部72から取得されたメタデータに基づいて、データ利用者2aに適した調達プランを決定する。そして、データ要求送信部338は、決定された調達プランに従い情報銀行装置4〜6からパーソナルデータを受信する。そして、データ送信部341は、受信されたパーソナルデータをデータ利用者2aに送信する。
【0135】
よって、データ利用者2aが、情報銀行装置4〜6が保有しているパーソナルデータを把握しづらい中で直接情報銀行装置4〜6に問い合わせてパーソナルデータを調達する場合と比較して、データ利用者2aに適したパーソナルデータの調達をより容易に行うことができる。
【0136】
特に、メタデータ取得部731は、記憶部72からメタデータを取得する。つまり、仲介装置7は、情報銀行4a〜6aとの間でデータのやり取りを行わなくてもメタデータを取得できる。したがって、情報銀行4a〜6aにメタデータ要求を送信してメタデータを取得する構成と比較して、仲介装置7の通信量を減らすことができる。また、メタデータ要求及びメタデータの送受信を行うためのAPI(Application Programming Interface)等のシステム開発費を抑えることができる。
【0137】
[3.第3実施形態]
[3−1.第1実施形態との相違点]
第3実施形態は、基本的な構成は第1実施形態と同様であるため、共通する構成については説明を省略し、相違点を中心に説明する。なお、第1実施形態と同じ符号は、同一の構成を示すものであって、先行する説明を参照する。
【0138】
前述した第1実施形態では、仲介装置3は複数の情報銀行4a〜6aからパーソナルデータを取得する。ここで、同一個人が複数の情報銀行4a〜6aにパーソナルデータを預託する状況は十分に考えられる。そして、情報銀行4a〜6aやデータ利用者2aは、情報銀行4a〜6aに預託されているどのパーソナルデータが同一人物に由来するかを知ることはできない。このため、データ利用者2aが複数の情報銀行4a〜6aにパーソナルデータを要求する場合、同一人物の同一パーソナルデータを異なる情報銀行4a〜6aから購入してしまう場合がある。つまり、パーソナルデータの二重購入が発生する場合がある。
【0139】
第3実施形態は、上記のパーソナルデータの二重購入抑制という課題を次のようにして解決する。すなわち、第3実施形態では、
図22に示すように、どの個人がどの情報銀行にパーソナルデータを預託しているかを把握している者(以下、登録管理者9a)が存在することが仮定される。そして、第3実施形態の仲介装置8は、この登録管理者9aが保有する装置である管理者装置9に問い合わせを行うことで、複数の情報銀行4a〜6aにパーソナルデータを預託した個人を検出する。そして、仲介装置8は、二重購入にならない調達プランを決定する。以下、第3実施形態の構成を詳細に説明する。
【0140】
図23に示すように、登録管理者9aの管理者装置9は、通信部91と、記憶部92と、制御部93と、を備える。
【0141】
通信部91は、管理者装置9をネットワークに接続するための通信インタフェースである。管理者装置9は、通信部91を介して、仲介装置8と有線又は無線にてデータ通信可能である。また、管理者装置9は、通信部91を介してインターネットに接続し、インターネットを介して外部の装置とデータ通信可能であってもよい。
【0142】
記憶部92は、各種データを記憶する。本実施形態では、記憶部92には、
図24に示すような重複管理テーブルが記憶されている。重複管理テーブルは、情報銀行IDと、情報銀行登録者IDと、個人IDと、が対応付けられて設定された情報である。
【0143】
情報銀行IDは、各情報銀行を識別するためのIDである。情報銀行IDは、登録管理者9aが各情報銀行に対して付与してもよい。本実施形態では、第1の情報銀行4a、第2の情報銀行5a及び第3の情報銀行6aの情報銀行IDは、それぞれ、「00001」、「00002」及び「00003」である。
【0144】
情報銀行登録者IDは、各情報銀行4a〜6aが、当該情報銀行4a〜6aにパーソナルデータを預託した個人、すなわち登録者に対して付与するIDである。情報銀行登録者IDは、各情報銀行4a〜6a内でユニークなIDである。なお、各情報銀行4a〜6aは、パーソナルデータを預託した個人の情報銀行登録者IDと、その個人が預託したパーソナルデータと、を一対一対応で対応付けて記憶する。そのため、情報銀行登録者IDは、情報銀行にパーソナルデータを預託した個人のパーソナルデータに対して付与されたIDとも考えられる。
【0145】
個人IDは、個人と一対一対応するIDであり、例えば、登録管理者9aによって個人に対して付与される。具体的には例えば、登録管理者9aが各情報銀行4a〜6aに対して、個人IDを生成するためのツールを貸与する。そして、各情報銀行4a〜6a側で、貸与された前記ツールを使用して個人IDが生成されてもよい。例えば、個人IDは、個人がデータを情報銀行4a〜6aに登録する際の本人確認情報からハッシュ関数等で生成されたIDでもよい。具体的には例えば、hash(surname_firstname_sex_birthday)などのハッシュ値が個人IDとして使用されてもよい。ここで、hashはハッシュ関数であり、surname、firstname、sex及びbirthdayには、データを預託する個人の姓、名、性別及び生年月日が入力される。
【0146】
この重複管理テーブルにおいて、個人IDの同一のパーソナルデータは同一人物のパーソナルデータであると判断できる。
【0147】
一方、制御部93は、CPU93aと、RAM、ROM、フラッシュメモリ等の半導体メモリ(以下、メモリ93b)と、を有する周知のマイクロコンピュータを中心に構成される。
【0148】
一方、第3実施形態の仲介装置8は、
図2に示すように、通信部81と、記憶部82と、制御部83と、を備える。これらの構成81〜83のハードウェア構成は、第1実施形態の仲介装置3の各構成31〜33と同一である。ただし、制御部83が実行する処理が第1実施形態と一部相違する。
【0149】
具体的には、制御部83は、CPU83aがメモリ83bに記憶されているプログラムを実行することで後述する
図26に示すデータ調達処理を実行する。制御部83はデータ調達処理を実行することで、
図25に示すように、リクエスト取得部331、ID要求生成部831、ID要求送信部832、ID受信部833、重複確認生成部834、重複確認送信部835、重複確認受信部836、メタデータ要求生成部332、メタデータ要求送信部333、メタデータ受信部334、条件整理部335、調達プラン決定部336、データ要求生成部337、データ要求送信部338、データ受信部339、形式処理部340及びデータ送信部341として機能する。つまり、第3実施形態の制御部83は、ID要求生成部831、ID要求送信部832、ID受信部833、重複確認生成部834、重複確認送信部835及び重複確認受信部836として更に機能する点で、第1実施形態の制御部33と相違する。以下では、相異点に係る各要素832〜836等の機能の概要について説明する。その後、
図26のフローチャートを用いて各要素832〜836等の機能を詳細に説明する。
<ID要求生成部>
ID要求生成部831は、リクエスト取得部331により受信された、対象条件を含むリクエスト情報に基づき、情報銀行装置4〜6に送信されるID要求を生成する。ここでいうID要求とは、対象条件に合致するパーソナルデータに係る情報銀行登録者IDを要求するための情報である。本実施形態では、ID要求生成部831は、各情報銀行装置4〜6の取扱い可能なデータ形式に合わせて情報銀行装置4〜6ごとにID要求を生成する。ID要求の具体例については後述する。
<ID要求送信部>
ID要求送信部832は、ID要求生成部831により生成されたID要求を複数の情報銀行装置4〜6に通信部81を介して送信する。ID要求を受信した情報銀行装置4〜6は、ID要求に対する応答として、ID結果情報を仲介装置3に送信する。ここでいうID結果情報とは、対象条件に合致するパーソナルデータの情報銀行登録者IDを示す情報である。本実施形態でいうID結果情報には、対象条件に合致するパーソナルデータの価格情報も含まれる。
<ID受信部>
ID受信部833は、複数の情報銀行装置4〜6からID結果情報を通信部81を介して受信する。ID結果情報の具体例については後述する。
<重複確認生成部>
重複確認生成部834は、複数の情報銀行装置4〜6から受信されたID結果情報に基づき、管理者装置9に送信される重複確認要求を生成する。ここでいう重複確認要求とは、ID結果情報に含まれる複数の情報銀行登録者IDが示す複数のパーソナルデータの中に同一個人に係るパーソナルデータがあるか否かの確認を要求するための情報である。重複確認要求の具体例については後述する。
<重複確認送信部>
重複確認送信部835は、重複確認生成部834により生成された重複確認要求を管理者装置9に通信部81を介して送信する。重複確認要求を受信した管理者装置9は、重複確認要求に対する応答として、重複確認の結果を示す重複結果情報を仲介装置8に送信する。
<重複確認受信部>
重複確認受信部836は、管理者装置9から重複結果情報を通信部81を介して受信する。重複結果情報の具体例については後述する。
<メタデータ要求生成部>
メタデータ要求生成部332は、重複確認受信部836により受信された重複結果情報とリクエスト取得部331により受信されたリクエスト情報とに基づき、情報銀行装置4〜6に送信されるメタデータ要求を生成する。本実施形態では、メタデータ要求生成部332は、同一人物のパーソナルデータを複数の情報銀行が管理している場合に、前記同一人物のデータを前記複数の情報銀行のうちの1つから要求するメタデータ要求を生成する。
【0150】
メタデータ要求送信部333以降の各要素333〜341は、基本的には第1実施形態と同様であるため、説明を省略する。
【0151】
[3−2.処理]
次に、第3実施形態の仲介装置8の制御部83が、第1実施形態のデータ調達処理(
図4)に代えて実行するデータ調達処理について、
図26のフローチャートを用いて説明する。
【0152】
<S301>
S301は、前述した
図4のS101と同様であるため、説明を省略する。
【0153】
<S302>
続いて、S302で、ID要求生成部831は、リクエスト取得部331により受信された、対象条件を含むリクエスト情報に基づき、情報銀行装置4〜6に送信されるID要求を生成する。
【0154】
ここで、ID要求は、
図27に示す各項目を含む。
図27には、第1の情報銀行4aに対するID要求の例が示されている。ID要求は、前述した
図6に示すメタデータ要求と同じ項目を含む。換言すれば、ID要求は、文タイプが「ID要求」であること以外は基本的にはメタデータ要求と同内容である。特に、ID要求は、リクエスト情報に含まれる対象条件の情報を含む。
【0155】
本実施形態では、情報銀行装置4〜6ごとに取扱い可能なデータ形式が異なる。そのため、ID要求は、送信先の情報銀行装置4〜6の取扱い可能なデータ形式に合わせて情報銀行装置4〜6ごとに生成される。
【0156】
<S303>
続いて、S303で、ID要求送信部832は、ID要求生成部831により生成されたID要求を複数の情報銀行装置4〜6に通信部81を介して送信する。ID要求を受信した情報銀行装置4〜6は、ID要求に対する応答として、ID結果情報を仲介装置3に送信する。
【0157】
<S304>
ID受信部833は、複数の情報銀行装置4〜6からID結果情報を通信部81を介して受信する。ID結果情報は、各情報銀行装置4〜6の取扱い可能なデータ形式で記述されている。
【0158】
本実施形態のID結果情報は、
図28に示す各項目を含む。
図28には、第1の情報銀行4aから受信されたID結果情報が示される。
【0159】
ID結果情報には、タイムスタンプ、トランザクションID、文タイプ、参照トランザクションID、宛先、送信元及び文内容が含まれる。参照トランザクションIDは、当該ID結果情報に関連するID要求、換言すれば、当該ID結果情報の送信元の情報銀行装置が受信したID要求のトランザクションIDである。
【0160】
文内容には、ID要求により示される対象条件に合致するパーソナルデータの情報銀行登録者IDと価格との組のリストが含まれる。例えば、
図28に示す例において、文内容に含まれる{1343482,215}の組は、第1の情報銀行4aが保有するパーソナルデータのうち対象条件に合致する或るパーソナルデータの情報銀行登録者IDが1343482であり、価格が215円であることを意味する。仲介装置8は、
図28に示すようなID結果情報を各情報銀行4a〜6aから受信する。
【0161】
<S305>
続いて、S305で、重複確認生成部834は、複数の情報銀行装置4〜6から受信されたID結果情報に基づき、管理者装置9に送信される重複確認要求を生成する。
【0162】
本実施形態の重複確認要求は、
図29に示すように、タイムスタンプ、トランザクションID、文タイプ、参照トランザクションID、宛先、送信元及び文内容の各項目を含む。
【0163】
文内容には、各情報銀行4a〜6aから受信した情報銀行登録者IDのリストと、各情報銀行の識別子(
図29中、「文内容」内の「第1の情報銀行」、「第2の情報銀行」等)と、が含まれる。
【0164】
<S306>
続いて、S306で、重複確認送信部835は、重複確認生成部834により生成された重複確認要求を管理者装置9に通信部81を介して送信する。重複確認要求を受信した管理者装置9は、重複確認要求に対する応答として、重複結果情報を仲介装置8に送信する。
【0165】
<S307>
重複確認受信部836は、管理者装置9から重複結果情報を通信部81を介して受信する。
【0166】
本実施形態の重複結果情報は、
図30に示すように、タイムスタンプ、トランザクションID、文タイプ、参照トランザクションID、宛先、送信元及び文内容の各項目を含む。
【0167】
文内容には、同一人物のそれぞれの情報銀行4a〜6aにおける情報銀行登録者IDの組が含まれる。
【0168】
例えば、
図30に示す例において、文内容に含まれる(0900838,9888100,430981213)の組は、第1の情報銀行4aの情報銀行登録者ID「0900838」と、第3の情報銀行6aの情報銀行登録者ID「9888100」と、第3の情報銀行6aの情報銀行登録者ID「430981213」と、が同一人物のIDであることを意味する。
【0169】
なお、管理者装置9は、仲介装置8から重複確認要求を受信した場合に、次のように重複結果情報を生成する。すなわち、管理者装置9は、
図24に示す重複管理テーブルを参照する。そして、管理者装置9は、重複確認要求に含まれる情報銀行登録者IDのリスト内で同一の個人IDに対応する情報銀行登録者IDが複数存在するか否かを確認する。そして、管理者装置9は、同一の個人IDに対応する情報銀行登録者IDが複数存在する場合、その複数の情報銀行登録者IDを組にしてまとめる。これにより、重複結果情報の文内容に含まれる、情報銀行登録者IDの組が生成される。管理者装置9はこのようにして重複結果情報を生成する。なお、
図24では、符号9aで示される情報銀行登録者IDは、同一の個人IDに対応する。また、符号9bで示される情報銀行登録者IDも、同一の個人IDに対応する。
【0170】
<S308>
メタデータ要求生成部332は、重複確認受信部836により受信された重複結果情報とリクエスト取得部331により受信されたリクエスト情報とに基づき、情報銀行装置4〜6に送信されるメタデータ要求を生成する。
【0171】
ここで、メタデータ要求生成部332は、複数の情報銀行の情報銀行登録者IDが同一の個人IDに対応する場合、前記複数の情報銀行のうちの1つの情報銀行を特定する。そして、メタデータ要求生成部332は、特定された情報銀行以外に対しては、前記同一の個人IDに対応する情報銀行登録者IDを除外してメタデータを送信するようにメタデータ要求を生成する。
【0172】
具体的には、本実施形態では、メタデータ要求生成部332は、S307で受信された重複結果情報とS304で受信されたID結果情報に含まれる価格情報とを突き合わせる。そして、メタデータ要求生成部332は、或る個人のパーソナルデータを最も安く提供している情報銀行を特定し、特定された情報銀行以外からは、その個人のデータを除外してメタデータを送信するようメタデータ要求内の条件で規定する。
【0173】
なお、本実施形態では、同一人物のパーソナルデータであっても情報銀行によってデータの価格が異なることが想定される。これは、情報銀行によって情報銀行が取るマージンが異なることが想定されるためである。
【0174】
図31に示すように、本実施形態のメタデータ要求は、前述した
図6に示すメタデータ要求の各項目に加え、文内容に除外IDの項目を更に含む。
【0175】
除外IDは、情報銀行から送信されるメタデータに含めない(すなわち除外される)パーソナルデータの情報銀行登録者IDを示す項目である。つまり、メタデータ要求を受信した情報銀行は、除外IDで指定された情報銀行登録者IDのデータを除外して仲介装置8にメタデータを送信する。これにより、特定の情報銀行以外の情報銀行からのメタデータからは、同一の個人IDに対応する情報銀行登録者IDのデータが除外される。
<S309>
S309は、前述した
図4のS103と同様であるため、説明を省略する。
<S310>
続いて、S310で、メタデータ受信部334は、各情報銀行装置4〜6からメタデータを通信部81を介して受信する。ここで、メタデータ受信部334は、複数の情報銀行4a〜6aの情報銀行登録者IDが或る同一の個人IDに対応する場合、その個人のパーソナルデータを最も安く提供している情報銀行からその個人のデータを含むメタデータを受信する。そして、メタデータ受信部334は、その個人のパーソナルデータを最も安く提供している情報銀行以外の情報銀行からはその個人のデータが除外されたメタデータを受信する。その結果、メタデータ受信部334が、同一人物のデータを含むメタデータを複数の情報銀行から受信することが抑制される。
<S311〜S317>
S311〜S317は、前述した
図4のS105〜S111と同様であるため、説明を省略する。
【0176】
[3−3.効果]
以上詳述した第3実施形態によれば、前述した第1実施形態の効果(1a)〜(1h)に加え、以下の効果が得られる。
【0177】
(3a)本実施形態では、調達プラン決定部336は、重複結果情報に基づきメタデータ要求を生成し、メタデータ要求の応答として得られたメタデータに基づき、調達プランを決定する。つまり、調達プラン決定部336は、重複結果情報に基づき調達プランを決定する。
【0178】
このため、重複確認情報に基づき決定された調達プランに従いパーソナルデータが調達される。したがって、同一個人が複数の情報銀行4a〜6aにデータを預託する状況下で発生するデータ利用者2aのニーズを満たすことができる。また、データ利用者2aに代わり仲介装置8が複数の情報銀行4a〜6aからデータを調達するため、データ利用者2aが欲するパーソナルデータの調達をより容易に行うことができる。
【0179】
(3b)本実施形態では、調達プラン決定部336は、重複結果情報により同一個人に係るパーソナルデータであることが示される第1のパーソナルデータ及び第2のパーソナルデータのうち、いずれか一方を調達する調達プランを決定する。
【0180】
したがって、同一個人に係る同一内容のパーソナルデータを複数の情報銀行4a,5aから重複して購入することを抑制することができる。
【0181】
(3c)本実施形態では、調達プラン決定部336は、同一個人に係る第1のパーソナルデータ及び第2のパーソナルデータのうち価格が安い方を調達する調達プランを決定する。
【0182】
したがって、同一個人に係る同一内容のパーソナルデータを重複して購入することを抑制しつつ、データ利用者2aがより安い金額でパーソナルデータを購入することができる。
【0183】
(3d)本実施形態では、重複確認受信部836は、重複結果情報を生成可能な外部装置である管理者装置9から重複結果情報を取得する。
【0184】
ここで、仲介装置8が、
図24に示す重複状況テーブルを自身の記憶部82に記憶し、記憶部82に記憶された重複状況テーブルを基に重複結果情報を取得する構成が考えられる。しかしながら、このような構成では、記憶部82に記憶された重複状況テーブルが最新の重複状況テーブルに更新されておらず、取得された重複結果情報がパーソナルデータの最新の重複状況を反映していない可能性がある。これに対し、本実施形態の構成によれば、管理者装置9から重複結果情報を取得するため、最新の重複状況を反映した重複結果情報を仲介装置8が取得しやすい。ひいては、仲介装置8が最新の重複状況に基づき調達プランを決定しやすくできる。
【0185】
(3e)本実施形態では、重複結果情報は、同一個人に係る、或る情報銀行の情報銀行登録者IDと、別の情報銀行の情報銀行登録者IDと、を対応付ける情報である。
【0186】
したがって、複数の情報銀行が同一個人に係るパーソナルデータを異なる情報銀行登録者IDで管理している場合において、仲介装置8は、複数の情報銀行に管理されたいずれのパーソナルデータが同一個人に係るパーソナルデータであるのかを把握できる。そして、仲介装置8は、把握した結果を踏まえ、調達プランを決定することができる。
【0187】
なお、本実施形態では、重複結果情報が重複確認情報に相当し、情報銀行登録者IDが登録識別情報に相当し、管理者装置9が重複確認情報を管理する又は重複確認情報を生成可能な外部装置に相当し、S301がリクエスト取得部としての処理に相当し、S307が重複確認取得部としての処理に相当し、S312が決定部としての処理に相当し、S315及びS317が取得送信部としての処理に相当する。
【0188】
[4.第4実施形態]
[4−1.第3実施形態との相違点]
第4実施形態は、基本的な構成は第3実施形態と同様であるため、共通する構成については説明を省略し、相違点を中心に説明する。なお、第3実施形態と同じ符号は、同一の構成を示すものであって、先行する説明を参照する。
【0189】
前述した第3実施形態では、仲介装置8は、複数の情報銀行4a〜6aに預託されているどのデータが同一個人のデータかを確認する重複確認を行う。そして、仲介装置8は、同一個人のパーソナルデータの重複購入を回避するよう調達プランを決定する。すなわち、仲介装置8は、同一個人のパーソナルデータを、複数の情報銀行4a〜6aのうちの特定の情報銀行のみから調達する。
【0190】
一方、情報銀行は、生活者に何らかのサービスを提供するために生活者からパーソナルデータを預託してもらうことが考えられる。この場合、情報銀行ごとに提供するサービス内容が異なると、同一個人であっても、情報銀行ごとにデータ項目が異なるパーソナルデータを預託する可能性がある。そこで、データ利用者2aは、同一個人のパーソナルデータを、複数の情報銀行4a〜6aから名寄せして取得したいと考えることが想定される。
【0191】
第4実施形態では、仲介装置8は、複数の情報銀行4a〜6aのそれぞれから同一人物のパーソナルデータを名寄せして調達する点で、第3実施形態と異なる。以下、第4実施形態について詳細に説明する。
【0192】
第4実施形態の仲介装置8は、第3実施形態とハードウェア構成及び機能的要素は同じである。特に、第4実施形態の仲介装置8は、
図25に示す各要素331〜341,831〜836を備える。各要素331〜341,831〜836の機能は基本的には第3実施形態と同様であるが、メタデータ要求生成部332及び形式統合部340の機能が第3実施形態と一部相違する。以下、これらの要素332,340について説明する。
<メタデータ要求生成部>
メタデータ要求生成部332は、重複確認受信部836により受信された重複結果情報とリクエスト取得部331により受信されたリクエスト情報とに基づき、情報銀行装置4〜6に送信されるメタデータ要求を生成する。受信された重複結果情報から複数の情報銀行にパーソナルデータを預託している個人の情報銀行登録者IDを特定できる。メタデータ受信部334は、複数の情報銀行に(すなわち他の情報銀行にも)パーソナルデータを預託している個人のデータのみを含むメタデータを要求するメタデータ要求を生成する。<形式統合部>
形式処理部340は、複数の情報銀行装置4〜6から受信された納品データのデータ形式を共通のデータ形式に合わせ、1つのデータに統合することで統合データを生成する。本実施形態では、形式処理部340は、複数の情報銀行装置4〜6から受信された同一個人のパーソナルデータを名寄せすることで前記統合データを生成する。
【0193】
[4−2.処理]
次に、第4実施形態の仲介装置8の制御部83が、第3実施形態のデータ調達処理に代えて実行するデータ調達処理について、前述した
図26のフローチャートを用いて説明する。
<S301〜S307>
S301〜S307は、前述した第3実施形態のS301〜S307と同様であるため、説明を省略する。
<S308>
続いて、S308で、メタデータ要求生成部332は、S307で受信された重複結果情報とS301で受信されたリクエスト情報とに基づき、情報銀行装置4〜6に送信されるメタデータ要求を生成する。ここで、メタデータ要求生成部332は、複数の情報銀行にパーソナルデータを預託している個人のデータのみを含むメタデータを要求するメタデータ要求を生成する。
【0194】
具体的には、メタデータ要求生成部332は、
図32及び
図33に示すようなメタデータ要求を生成する。
図32には第1の情報銀行4aに送信されるメタデータ要求の例が示される。
図33には第2の情報銀行5aに送信されるメタデータ要求の例が示される。
【0195】
本実施形態のメタデータ要求は、前述した
図6に示すメタデータ要求と基本的には同じ項目を含むが、分布集計軸の項目を含まない。また、本実施形態のメタデータ要求は、文内容に対象IDの項目を更に含む。
【0196】
ここでいう対象IDとは、情報銀行から送信されるメタデータに含める個人の情報銀行登録者IDを示す項目である。つまり、メタデータ要求を受信した情報銀行4a〜6aは、対象IDで指定された情報銀行登録者IDのデータのみを含むメタデータを仲介装置8に送信する。対象IDには、複数の情報銀行にパーソナルデータを預託している個人の情報銀行登録者IDが記述される。
【0197】
例えば、前述した
図24の例では、情報銀行IDが「00001」である第1の情報銀行4aの情報銀行登録者ID「0900838」と、情報銀行IDが「00002」である第2の情報銀行5aの情報銀行登録者ID「9888100」と、情報銀行IDが「00003」である第3の情報銀行6aの情報銀行登録者ID「430981213」と、は同一個人のIDである。また、第1の情報銀行4aの情報銀行登録者ID「2910110」と、第2の情報銀行5aの情報銀行登録者ID「7550360」と、は同一個人のIDである。
【0198】
したがって、
図32に示すように、第1の情報銀行4aに対しては、複数の情報銀行4a〜6aにデータを預託している個人を示すIDとして、対象IDに、情報銀行登録者ID「0900838」及び「2910110」が記述される。
【0199】
なお、
図32の例では、第1の情報銀行4aは、要求項目の欄から見て取れるように、性別(Gender)、年代(Age10)等の基本属性のほかに、子供の年齢(Age_minor_child)、家族の人数(Num_Family)、自炊頻度(Freq_HomeCook)、スーパーマーケットの利用頻度(Freq_GSM)、コンビニエンスストアの利用頻度(Freq_CVS)、ドラッグストアの利用頻度(Freq_DS)といったパーソナルデータの属性を保有している。
【0200】
一方、
図33に示すように、第2の情報銀行5aに対しては、複数の情報銀行4a,5aにデータを預託している個人を示すIDとして、対象IDに、情報銀行登録者ID「7550360」及び「9888100」が記述される。
【0201】
なお、
図33の例では、第2の情報銀行5aは、要求項目の欄から見て取れるように、性別、年代等の基本属性のほかに、レシピサイト月間閲覧履歴、3ヶ月雑誌購買金額といったパーソナルデータの属性を保有している。
【0202】
メタデータ要求生成部332は、上記のようなメタデータ要求を生成する。
<S309〜S315>
S309〜S315は、前述した第3実施形態のS309〜S315と同様であるため、説明を省略する。
<S316>
続いて、S316で、形式処理部340は、複数の情報銀行装置4〜6から受信された納品データのデータ形式を共通のデータ形式に合わせ、1つのデータに統合することで統合データを生成する。
【0203】
図34には、統合データの例が示されている。図中、符号10aで示すパーソナルデータの属性(すなわちデータ項目)は、第1の情報銀行4a及び第2の情報銀行5aの両方が保有している属性である。一方、符号10bで示すパーソナルデータの属性は、第1の情報銀行4aのみが保有している属性である。また、符号10cで示すパーソナルデータの属性は、第2の情報銀行5aのみが保有している属性である。形式処理部340は、このようにして、同一個人のパーソナルデータを複数の情報銀行4a〜6aから名寄せすることで統合データを生成する。
<S317>
S317は、前述した第3実施形態のS317と同様であるため、説明を省略する。
【0204】
[4−3.効果]
以上詳述した第4実施形態によれば、前述した第1実施形態の効果(1a)〜(1h)及び第3実施形態の効果(3a)、(3d)及び(3e)に加え、以下の効果が得られる。
【0205】
(4a)本実施形態では、調達プラン決定部336は、重複結果情報により同一個人に係るパーソナルデータであることが示される第1のパーソナルデータ及び第2のパーソナルデータの両方を調達する調達プランを決定する。
【0206】
したがって、例えば、同一個人が第1の情報銀行4aと第2の情報銀行5aとに異なる内容のパーソナルデータを預託している場合において、同一個人のパーソナルデータを複数の情報銀行4a,5aから名寄せすることができる。複数の情報銀行に預託されるパーソナルデータが同一であるとは限らないため、名寄せによっていずれの情報銀行4a,5aにもない情報を仲介装置8が生成することができる。
【0207】
なお、本実施形態では、第3実施形態と同様に、仲介装置8の各構成が請求項の各文言に相当する。
【0208】
[5.第5実施形態]
[5−1.第3実施形態との相違点]
第5実施形態は、基本的な構成は第3実施形態と同様であるため、共通する構成については説明を省略し、相違点を中心に説明する。なお、第3実施形態と同じ符号は、同一の構成を示すものであって、先行する説明を参照する。
【0209】
第3実施形態は、仲介装置8は外部の管理者装置9から重複結果情報を取得する。これに対し、第4実施形態では、仲介装置8の記憶部82には重複状況テーブルがあらかじめ記憶されている。そして、仲介装置8は、利用者装置2からリクエスト情報を受信した場合に、記憶部82から重複状況テーブルを基に重複結果情報を生成する点で、第3実施形態と相違する。以下、第5実施形態について詳細に説明する。
【0210】
第5実施形態の仲介装置11は、
図2に示すように、通信部111と、記憶部112と、制御部113と、を備える。これらの構成111〜113のハードウェア構成は、第3実施形態の仲介装置8の各構成81〜83と同一である。ただし、第5実施形態の仲介装置11の記憶部112に記憶されているデータが第3実施形態と異なる。具体的には、第5実施形態の記憶部112には、
図35に示す重複管理テーブルが記憶されている。
【0211】
図35の重複状況テーブルは、前述した
図24に示す、登録管理者9aが保有する重複管理テーブルと基本的には同様であるが、パーソナルデータの価格の項目を更に含む点で相違する。すなわち、
図35に示す重複状況テーブルは、情報銀行IDと、情報銀行登録者IDと、個人IDと、パーソナルデータの価格と、が対応付けられて設定された情報である。
【0212】
本実施形態では、記憶部112に記憶されている重複状況テーブルは、所定頻度(例えば1ヶ月に1度や1週間に1度)で定期的に更新されることが想定される。なお、重複状況テーブルの更新は種々の方法で行われ得るが、例えば次のようにして行われてもよい。すなわち、仲介装置11の保有者が、管理者装置9を保有する登録管理者9aから重複状況テーブルを記憶した記憶媒体を受領し、受領された記憶媒体内の重複状況テーブルを記憶部112に記憶することで重複状況テーブルの更新が行われてもよい。
【0213】
一方、制御部113は、CPU113aがメモリ113bに記憶されているプログラムを実行することで後述する
図37に示すデータ調達処理を実行する。制御部113はデータ調達処理を実行することで、
図36に示すように各要素331〜341,831〜833、931,932として機能する。つまり、第5実施形態の制御部113は、第3実施形態の
図25に示す重複確認生成部834、重複確認送信部835及び重複確認受信部836に代えて重複確認取得部931として機能し、更に、更新処理部932として機能する点で、第3実施形態と相違する。以下、相異点に係る重複確認取得部931及び更新処理部932について説明する。
<重複確認取得部>
重複確認取得部931は、記憶部112から重複状況テーブルを取得する。そして、重複確認取得部931は、ID受信部833により受信されたID結果情報と、記憶部112から取得された重複状況テーブルと、に基づき、重複結果情報を生成する。重複結果情報の生成の仕方は、前述した第3実施形態の管理者装置9が重複結果情報する仕方と同じであるため、説明を省略する。
<更新処理部>
更新処理部932は、形式処理部340により生成された統合データに基づき、記憶部112に記憶されている重複状況テーブルを更新する。
【0214】
例えば、更新処理部932は、統合データに含まれるデータと重複状況テーブルに登録されているデータとが異なる場合、重複状況テーブルに登録されているデータを納品データに含まれるデータに更新する。これにより、統合データに含まれるデータ、つまり、仲介装置11が直近で購入した最新のデータ内容に重複状況テーブルが更新される。
【0215】
[5−2.処理]
次に、第5実施形態の仲介装置11の制御部113が、第3実施形態のデータ調達処理(
図26)に代えて実行するデータ調達処理について、
図37のフローチャートを用いて説明する。
<S401〜S404>
S401〜S404は、前述した
図26のS301〜S304と同様であるため、説明を省略する。
<S405>
続いて、S405で、重複確認取得部931は、記憶部112から重複状況テーブルを取得する。そして、重複確認取得部931は、ID受信部833により受信されたID結果情報と、記憶部112から取得された重複状況テーブルと、に基づき、重複結果情報を生成することで、重複結果情報を取得する。
<S406〜S415>
S406〜S415は、前述した
図26のS308〜S317と同様であるため、説明を省略する。
<S416>
続いて、S416で、更新処理部932は、形式処理部340により生成された統合データに基づき、記憶部112に記憶されている重複状況テーブルを更新する。
【0216】
[5−3.効果]
以上詳述した第5実施形態によれば、前述した第1実施形態の効果(1a)〜(1h)及び第3実施形態の効果(3a)〜(3c)及び(3e)に加え、以下の効果が得られる。
【0217】
(5a)本実施形態では、仲介装置11は、記憶部112から重複状況テーブルを取得する。そして、重複確認取得部931は、ID受信部833により受信されたID結果情報と、取得された重複状況テーブルと、に基づき、重複結果情報を生成することで重複結果情報を取得する。つまり、仲介装置11は、管理者装置9との間でデータのやり取りを行わなくても重複結果情報を取得できる。したがって、管理者装置9に重複確認要求を送信して重複結果情報を取得する構成と比較して、管理者装置9の通信量を減らすことができる。また、重複確認要求及び重複結果情報の送受信を行うためのAPI(Application
Programming Interface)等のシステム開発費を抑えることができる。
【0218】
なお、本実施形態では、重複状況テーブルが重複確認情報に相当し、S401がリクエスト取得部としての処理に相当し、S405が重複確認取得部としての処理に相当し、S410が決定部としての処理に相当し、S413及びS415が取得送信部としての処理に相当する。
【0219】
[6.第6実施形態]
[6−1.第3実施形態との相違点]
第6実施形態は、基本的な構成は第3実施形態と同様であるため、共通する構成については説明を省略し、相違点を中心に説明する。なお、第3実施形態と同じ符号は、同一の構成を示すものであって、先行する説明を参照する。第6実施形態は、データ利用者2aの利用者装置2が、情報銀行4a〜6aから調達されたパーソナルデータを使って、情報銀行4a〜6aにパーソナルデータを預託した個人に対して広告配信を行う点で、前述した第3実施形態と相違する。
【0220】
図38に示す第6実施形態の調達システム12は、第3実施形態と同様に、利用者装置2、仲介装置3及び複数の情報銀行装置4〜6を備える。第6実施形態の仲介装置3及び複数の情報銀行装置4〜6は、第3実施形態のものと同様である。
【0221】
一方、第6実施形態の利用者装置2は、
図39に示すように、通信部21と、記憶部22と、制御部23と、を備える。通信部21は、利用者装置2をネットワークに接続するための通信インタフェースである。利用者装置2は、通信部21を介して、仲介装置8や、個人が保有する情報処理端末11〜17とデータ通信可能である。
【0222】
記憶部22は、各種データを記憶する。本実施形態では、記憶部22には、広告情報と送信先情報とが記憶されている。ここでいう広告情報は、データ利用者2aが情報銀行4a〜6aから調達したパーソナルデータに係る個人に送信される広告情報であり、調達されたパーソナルデータの属性(換言すれば、パーソナルデータに係る個人の嗜好性等の各種属性)に対応した広告情報である。
【0223】
また、ここでいう送信先情報は、広告情報が送信される送信先を指定する情報である。本実施形態では、送信先として、情報銀行4a〜6aにパーソナルデータを預託した個人が想定される。送信先情報は、例えば、IDFA(Identification For Advertisers)やADID(Advertising Identifier)、クッキーID、配信対象者の電子メールアドレスなどの、広告情報の送信先を識別する識別子であってもよい。本実施形態では、送信先情報は、情報銀行4a〜6aから取得されたパーソナルデータに含まれていることが想定される。
【0224】
制御部23は、CPU23aと、RAM、ROM、フラッシュメモリ等の半導体メモリ(以下、メモリ23b)と、を有する周知のマイクロコンピュータを中心に構成される。制御部23の各種機能は、CPU23aが非遷移的実体的記憶媒体に格納されたプログラムを実行することにより実現される。この例では、メモリ23bが、プログラムを格納した非遷移的実体的記憶媒体に該当する。また、このプログラムの実行により、プログラムに対応する方法が実行される。制御部23は、後述する
図40に示す広告配信処理を実行する。
【0225】
[6−2.処理]
次に、利用者装置2の制御部23が実行する広告配信処理について、
図40のフローチャートを用いて説明する。なお、広告配信処理は、適宜のタイミングで実行される。
【0226】
まず、S501で、制御部23は、記憶部22から広告情報と送信先情報とを取得する。
【0227】
続いて、S502で、制御部23は、広告配信を行う。具体的には、制御部23は、S501で取得された広告情報を、S501で取得された送信先情報が示す送信先に対して通信部21を介して送信する。制御部23は、S502を実行すると、
図40の広告配信処理を終了する。
【0228】
[6−3.効果]
以上詳述した第6実施形態によれば、前述した第1実施形態の効果(1a)〜(1h)及び第3実施形態の効果(3a)〜(3e)に加え、以下の効果が得られる。
【0229】
(6a)本実施形態では、利用者装置2は、情報銀行4a〜6aから取得されたパーソナルデータを使って、情報銀行4a〜6aにパーソナルデータを預託した個人に対し、広告配信を行う。具体的には、利用者装置2は、仲介装置8から取得されたパーソナルデータに係る個人に通知される広告情報と、前記広告情報の送信先を示す送信先情報と、を取得する。そして、利用者装置2は、送信先情報が示す送信先に広告情報を送信する。
【0230】
したがって、情報銀行装置4〜6から取得されたパーソナルデータを使って広告情報が送信される。よって、情報銀行4a〜6aにパーソナルデータを預託した個人に適した広告配信を行うことができる。
【0231】
なお、本実施形態では、調達システム12がシステムに相当し、広告情報が通知情報に相当し、S501が通知情報取得部としての処理に相当し、S502が通知情報送信部としての処理に相当する。
【0232】
[7.第7実施形態]
[7−1.第1実施形態との相違点]
第7実施形態は、基本的な構成は第1実施形態と同様であるため、共通する構成については説明を省略し、相違点を中心に説明する。なお、第1実施形態と同じ符号は、同一の構成を示すものであって、先行する説明を参照する。
【0233】
前述した第1実施形態では、データ利用者2aは、仲介装置3を介して情報銀行4a〜6aからパーソナルデータを取得する。ここで、データ利用者が、パーソナルデータの取扱いコストを負担したくない場合が想定される。すなわち、昨今、情報銀行4a〜6aからパーソナルデータを取得するデータ利用者に対しても、プライバシーマークの使用などの安全管理装置を求める動きがある。安全管理装置とは、事業者がパーソナルデータの漏洩、滅失又は毀損の防止その他のパーソナルデータの安全管理のために必要かつ適切な措置をいう。しかし、中小企業であるデータ利用者などにとっては、こうした安全管理装置を行うのが困難な場合もある。そこで、このようなデータ利用者は、安全管理措置を行わない代わりに匿名加工情報を取得することが考えられる。ここでいう匿名加工情報とは、パーソナルデータを基に生成される情報であり、そのパーソナルデータに係る個人が特定されないようにパーソナルデータに含まれる情報を変更又は削除して生成される情報である。
【0234】
第7実施形態では、仲介装置3は、情報銀行4a〜6aから取得したパーソナルデータを基に匿名加工情報を生成し、生成された匿名加工情報を利用者装置2に送信する点で、第1実施形態と相違する。以下、第7実施形態について詳細に説明する。
【0235】
第7実施形態の調達システム1のハードウェア構成は、第1実施形態と同様である。一方、第7実施形態の仲介装置3が実行する処理及び送受信するデータは、第1実施形態と一部相違する。
【0236】
[7−2.処理]
以下、第7実施形態の仲介装置3の制御部33が、第1実施形態のデータ調達処理(
図4)に代えて実行するデータ調達処理について、
図41のフローチャートを用いて説明する。なお、
図41のフローチャートにおいて、S501,S503〜S509,S511の処理(すなわちS502及びS510以外の処理)は、前述した
図4のS101,S103〜S109,S111とそれぞれ同様である。よって、以下では、これらの処理の説明を省略し、相異点であるS502及びS510のみ説明する。
【0237】
<S502>
S502で、メタデータ要求生成部332は、S501で受信されたリクエスト情報に基づいて、メタデータ要求を生成する。本実施形態では、メタデータ要求生成部332は、
図42に示すようなメタデータ要求を生成する。
図42に示すメタデータ要求は、基本的には
図6に示す第1実施形態のメタデータ要求と同様であるが、パーソナルデータの利用目的の種別の記述が異なる。
図42に示すメタデータ要求では、パーソナルデータの利用目的の種別は「匿名加工情報作成」と記述される。
【0238】
<S510>
S510で、形式処理部340は、各情報銀行装置4〜6から受信された納品データのデータ形式を揃えるとともにデータを変換する。そして、形式処理部340は、各情報銀行装置4〜6からの納品データを1つのデータに統合する。具体的には、形式処理部340は、第1実施形態と同様に、各情報銀行装置4〜6から受信された納品データに含まれる変数名や値を各情報銀行装置4〜6のデータ変換用辞書に従い変換することで、各情報銀行装置4〜6から受信された納品データのデータ形式を揃える。そして、形式処理部340は、納品データに含まれる変数名や値を、個人情報保護法に定められた基準を満たすように変換する。
【0239】
具体的には、形式処理部340は、例えば、第1の情報銀行4aから受信された
図16Aに示す納品データに含まれる変数名や値を、
図15に示す変換用辞書に従い変換する。そして、形式処理部340は、
図43に示すような第1の情報銀行4aの変換後の納品データを生成する。
図43に示す変換後の納品データは、匿名加工処理が施された匿名加工情報である。匿名加工処理は、パーソナルデータを、パーソナルデータに係る個人が特定できないように変更又は削除する処理である。匿名加工処理は、例えば、パーソナルデータの粒度を、パーソナルデータに係る個人が特定できない程度に粗くする処理であってもよい。
【0240】
具体的には例えば、
図43に示す匿名加工情報では、個人を特定可能な情報が削除される。個人を特定可能な情報としては、例えば、情報銀行が個人に対して付与するID(すなわち情報銀行登録者ID)や氏名などが挙げられる。そして、
図43に示すID(a3321、34acd、943dd、・・・)のように、ランダムに個人又はパーソナルデータに対してIDが付与される。
【0241】
また、匿名加工情報では、例えば、特定の地域(例えば日本)全体で見たときに特徴的又は珍しい情報であり、それゆえに個人を特定できるような情報が削除又は変更されてもよい。
【0242】
具体的には例えば、パーソナルデータに係る個人の年齢(Demographic:Age)が「115歳」であるとする。この場合、年齢が「115歳」であるという情報は日本全体で見たときに珍しく、個人を特定し得る情報である。よって、このような情報は、匿名加工情報において削除されたり、「100歳以上」などと丸められたりしてよい。
【0243】
また、匿名加工情報においては、情報銀行4a〜6aから取得されたデータセットの中で特徴的又は珍しく、個人を特定でき得る情報についても削除又は変更されてもよい。
【0244】
例えば、「未既婚」(Demographic:Marital)が「離別」や「死別」であるといった情報は、上記データセットの中で特徴的又は珍しく、個人を特定でき得る情報であるとする。この場合、或る個人の「未既婚」が「離別」又は「死別」に該当するときには、
図43に示すID「34acd」のように、その個人の「未既婚」が「離別又は死別」のように変更されてもよい。
【0245】
また例えば、3ヶ月雑誌購買金額(Aggregate:1:TotalExpense3MonthSeasonings)が5000円よりも大きいという情報は上記データセットの中で特徴的又は珍しく、個人を特定でき得る情報であるとする。この場合、匿名加工情報においては、
図43に示すID「09aba」の個人のように、5000円よりも大きい実際の金額が記されるのではなく、「5000円」のように数値が丸められてもよい。
【0246】
仲介装置3はこのようにして、各情報銀行4a〜6aから受信された納品データを匿名加工情報に変換する。そして、仲介装置3は、各情報銀行4a〜6aの匿名加工情報を1つのデータに統合し、統合データを生成する。なお、匿名加工処理及びデータの統合処理が実施される順序をこれに限らない。例えば、各情報銀行4a〜6aの納品データを1つのデータに統合した後、統合データに対して匿名加工処理が施されてもよい。
【0247】
[7−3.効果]
以上詳述した第7実施形態によれば、前述した第1実施形態の効果(1a)〜(1h)に加え、以下の効果が得られる。
【0248】
本実施形態では、仲介装置3は、情報銀行装置4〜6からパーソナルデータを通信部31を介して受信し、受信されたパーソナルデータを基に匿名加工情報を生成する。ここで、匿名加工情報は、パーソナルデータを基に生成される情報であり、そのパーソナルデータに係る個人が特定されないようにパーソナルデータに含まれる情報を変更又は削除して生成される情報(すなわちデータ)である。そして、仲介装置3は、生成された匿名加工情報を通信部31を介して利用者装置2に送信する。
【0249】
したがって、安全管理装置を行うのが困難なデータ利用者のパーソナルデータの取扱いコストを軽減できる。また、パーソナルデータの管理に関するコンピュータセキュリティを向上できる。
【0250】
[8.第8実施形態]
[8−1.第7実施形態との相違点]
第8実施形態は、基本的な構成は第1実施形態と同様であるため、共通する構成については説明を省略し、相違点を中心に説明する。なお、第1実施形態と同じ符号は、同一の構成を示すものであって、先行する説明を参照する。
【0251】
前述した第1実施形態では、データ利用者2aは、仲介装置3を介して情報銀行4a〜6aからパーソナルデータを取得する。ここで、データ利用者2aにとって、そもそも細かい粒度のパーソナルデータが不要な場合が想定される。例えば、データ利用者2aが、自社顧客が競合商品をどの程度買っているかを知りマーケティング戦略を立てる場合を考える。この場合、自社顧客のデータでなくても、自社顧客に似た属性を有する個人達の競合商品の平均購入量の統計情報が分かればデータ利用者2aが戦略を十分考えられる場合がある。この場合、細かい粒度のパーソナルデータは不要である。
【0252】
第8実施形態では、仲介装置3は、情報銀行4a〜6aから取得されたパーソナルデータを基に統計情報を生成し、生成された統計情報を利用者装置2に送信する点で、第1実施形態と相違する。以下、第8実施形態について詳細に説明する。
【0253】
第8実施形態の調達システム1のハードウェア構成は、第1実施形態と同様である。一方、第8実施形態の仲介装置3が実行する処理及び送受信するデータは、第1実施形態と一部相違する。
【0254】
[8−2.処理]
以下、第8実施形態の仲介装置3の制御部33が、第1実施形態のデータ調達処理(
図4)に代えて実行するデータ調達処理について、前述した
図41のフローチャートを用いて説明する。なお、
図41のフローチャートにおいて、S501,S503〜S509,S511の処理(すなわちS502及びS510以外の処理)は、前述した
図4のS101,S103〜S109,S111とそれぞれ同様である。よって、以下では、これらの処理の説明を省略し、相異点であるS502及びS510のみ説明する。
【0255】
<S502>
S502で、メタデータ要求生成部332は、S501で受信されたリクエスト情報に基づいて、メタデータ要求を生成する。本実施形態では、メタデータ要求生成部332は、
図44に示すようなメタデータ要求を生成する。
図44に示すメタデータ要求は、基本的には
図6に示す第1実施形態のメタデータ要求と同様であるが、パーソナルデータの利用目的の種別の記載が異なる。
図41に示すメタデータ要求では、パーソナルデータの利用目的の種別は「統計情報作成」と記述される。
【0256】
<S510>
S510で、形式処理部340は、各情報銀行装置4〜6から受信された納品データのデータ形式を揃えるとともにデータを変換する。そして、形式処理部340は、各情報銀行装置4〜6からの納品データを1つのデータに統合する。具体的には、形式処理部340は、第1実施形態と同様に、各情報銀行装置4〜6から受信された納品データに含まれる変数名や値を各情報銀行装置4〜6のデータ変換用辞書に従い変換することで、各情報銀行装置4〜6から受信された納品データのデータ形式を揃える。そして、形式処理部340は、変数名や値が変換された納品データを統計情報に変換する。ここでいう統計情報とは、情報銀行4a〜6aから取得された複数の個人に係るパーソナルデータを集計又は加工して得られた情報である。
【0257】
具体的には例えば、形式処理部340は、第1の情報銀行4aから受信された
図16Aに示す納品データに含まれる変数名や値を、
図15に示す変換用辞書に従い変換する。そして、形式処理部340は、
図45に示すような第1の情報銀行4aの変換後の納品データを生成する。
図45に示す変換後の納品データは、統計情報化された納品データである。
【0258】
図45に示す統計情報では、第1の情報銀行4aから受信された複数の個人に係るパーソナルデータが複数のグループ(例えばグループIDが1〜6までの6つのグループ)に分類される。例えば、複数の個人に係るパーソナルデータを、パーソナルデータに含まれる適当な項目(例えば3ヶ月雑誌購買金額)でマッピングし、クラスタリングすることで、パーソナルデータが複数のグループに分類されてもよい。
【0259】
そして、各グループのグループIDごとに、グループサイズと、各種のデモグラフィック属性(性別=男性、年齢=15歳等)に該当する個人の総数と、が対応付けられている。グループサイズは、そのグループに含まれる個人又はパーソナルデータの総数である。
【0260】
そして、仲介装置3は、情報銀行4a〜6aごとに生成された統計情報を1つのデータに統合し、統合データを生成する。
【0261】
なお、上記ではクラスタリングを行うことで統計情報が生成されるが、統計情報を生成する手法はこれに限られない。例えば、クロス集計等の他の統計手法により統計情報が生成されてもよい。
【0262】
また例えば、上記ではパーソナルデータを複数のグループに分類することで統計情報が生成されるが、例えばパーソナルデータを複数のグループに分類することなく、1つのグループにまとめてもよい。そして、そのグループについて、各種のデモグラフィック属性等に該当する個人又はパーソナルデータの総数、平均、中央値、分散等を示す統計情報を生成してもよい。
【0263】
また例えば、情報銀行4a〜6aごとに統計情報を生成するのではなく、複数の情報銀行4a〜6aから受信されたパーソナルデータを一旦全部集約して、集約されたパーソナルデータを基に統計情報が生成されてもよい。
【0264】
このように第8実施形態では、パーソナルデータ単位でデータが利用者装置2に送信されるのではなく、グループ単位でデータが送信される。
【0265】
なお、第8実施形態では、統計情報の生成に用いられたパーソナルデータに係る個人を、生成された統計情報から特定できないように統計情報が生成される。つまり、生成される統計情報は、匿名加工情報であってもよい。
【0266】
[8−3.効果]
以上詳述した第8実施形態によれば、前述した第1実施形態の効果(1a)〜(1h)に加え、以下の効果が得られる。
【0267】
本実施形態では、仲介装置3は、情報銀行装置4〜6から複数の個人に係るパーソナルデータを通信部31を介して受信し、受信されたパーソナルデータを基に、パーソナルデータの属性(すなわち、性別、年齢等の項目)に関する統計情報を示す統計情報を生成する。そして、仲介装置3は、生成された統計情報を通信部31を介して利用者装置2に送信する。
【0268】
したがって、細かい粒度のパーソナルデータが不要であり、統計情報があれば十分な場合において、データ利用者2aに統計情報を提供できる。また、統計情報化することで一般にデータの粒度が粗くなるため、安全管理装置を行うのが困難なデータ利用者のパーソナルデータの取扱いコストを軽減できる。また、パーソナルデータの管理に関するコンピュータセキュリティを向上できる。
【0269】
[9.第9実施形態]
[9−1.第4実施形態との相違点]
第9実施形態は、基本的な構成は第4実施形態と同様であるため、共通する構成については説明を省略し、相違点を中心に説明する。なお、第4実施形態と同じ符号は、同一の構成を示すものであって、先行する説明を参照する。
【0270】
前述した第4実施形態では、仲介装置8は、複数の情報銀行4a〜6aから同一個人のパーソナルデータを名寄せする。特に、第4実施形態では、複数の情報銀行4a〜6aが保有するパーソナルデータの中に同一個人のパーソナルデータがあるかどうかを仲介装置8が管理者装置9に問合せる。そして、管理者装置9は、
図24に示す情報銀行ID、情報銀行登録者ID及び個人IDの3つのIDを使用して、同一個人のパーソナルデータを特定する。そして、仲介装置8は、同一個人のパーソナルデータであると特定された複数のパーソナルデータを、複数の情報銀行4a〜6aから取得する。
【0271】
一方、第9実施形態は、複数の情報銀行4a〜6aから同一個人のパーソナルデータを名寄せする点は第4実施形態と同様である。しかし、第9実施形態では、仲介装置が管理者装置9に問い合わせるのではない。具体的には、第9実施形態の仲介装置は、複数の情報銀行4a〜6aから受信された複数のパーソナルデータを含むデータセット上で、年齢、性別等の属性値の組合せが類似する複数のパーソナルデータを特定する。そして、属性値の組合せが類似する複数のパーソナルデータを同一個人に係るパーソナルデータであるとして複数の情報銀行4a〜6aから名寄せする点で、第4実施形態と相違する。以下、第9実施形態について詳細に説明する。
【0272】
第9実施形態の調達システムのハードウェア構成は、前述した第4実施形態というよりは前述した第1実施形態と同様である。一方、第9実施形態の仲介装置12の機能は、第1実施形態と一部相違する。
【0273】
具体的には、第9実施形態の仲介装置12の制御部は、
図46に示すように各要素331〜341,1231として機能する。
【0274】
つまり、第9実施形態の仲介装置12の制御部は、第1実施形態の
図3に示す各要素331〜341に加え、更に、類似度判定部1231として機能する点で、第1実施形態と相違する。
<類似度判定部>
類似度判定部1231は、複数の情報銀行4a〜6aから受信された複数のパーソナルデータの中から、パーソナルデータの属性値が類似する複数のパーソナルデータを特定する。パーソナルデータが類似するか否かの判定は、パーソナルデータ間の類似度が所定のしきい値以上又は以下であるかを判定することで行われてもよい。そして、類似度判定部1231は、特定された複数のパーソナルデータを同一個人のパーソナルデータであるとして互いに紐付ける。そして、類似度判定部1231によって互いに紐付けられた複数のパーソナルデータは、同一個人のパーソナルデータであるとして、データ送信部341によってデータ利用者2aに送信される。類似度判定部1231の処理内容については以下に詳述する。
【0275】
[9−2.処理]
次に、第9実施形態の仲介装置12の制御部が、第1実施形態のデータ調達処理(
図4)に代えて実行するデータ調達処理について、
図47のフローチャートを用いて説明する。なお、
図47のフローチャートにおいて、S601〜S610,S612の処理(すなわちS611以外の処理)は、前述した
図4のS101〜S111とそれぞれ同様である。よって、以下では、これらの処理の説明を省略し、相異点であるS611のみ説明する。
<S611>
S611で、類似度判定部1231は、複数の情報銀行4a〜6aから受信された複数のパーソナルデータについて類似度判定を行う。そして、類似度判定部1231は、互いに類似していると判定した複数のパーソナルデータを互いに紐付ける。類似度判定は、複数のパーソナルデータが類似しているか否かの判定である。具体的には、類似度判定部1231は、属性値が類似する複数のパーソナルデータを次のようにして特定する。
【0276】
すなわち、形式処理部340によってデータ形式が揃えられた結果、
図48及び
図49に示すデータセットが得られたとする。
【0277】
図48は、第1の情報銀行4aから得られたパーソナルデータの変数や値を共通の形式に変換したデータセットである。
図49は、第2の情報銀行5aから得られたパーソナルデータの変数や値を共通の形式に変換したデータセットである。
図48及び
図49に示す例では、第1の情報銀行4a及び第2の情報銀行5aからそれぞれ20個ずつパーソナルデータ(IDが1〜20のパーソナルデータ)が取得されたことが想定される。
【0278】
図48及び
図49に示すデータセットにおいて、各IDにはパーソナルデータの各属性値が対応付けられる。
図48及び
図49において、値「1」はその属性に該当することを意味し、値「0」はその属性に該当しないことを意味する。例えば、
図48に示すデータセットにおいて、ID=1のパーソナルデータが「D:Gender:1」=1、「D:Age:20-34」=1であるのは、ID=1のパーソナルデータに係る個人が男性であり、年齢が20歳−34歳であることを意味する。
【0279】
なお、前述した第1実施形態では、共通のデータ形式である標準値は、
図14に示すように「男性」、「女性」等のテキストを含むが、本実施形態では、後に行う計算上の便宜で、標準値は「0」、「1」等の数値に設定されている。
【0280】
ここで重要であるのは、異なる情報銀行4a,5aから受信されたデータセットの変数や、値の意味が形式処理部340(すなわち、S610の処理)によって共通の形式に変換された結果、一致していることである。値の意味とは、例えば「D:Gender:1」は男性であることを意味する、等である。これによって、取扱い可能なデータ形式が異なる複数の情報銀行4a〜6aから取得されたパーソナルデータ間の類似度を計算することができる。
【0281】
具体的には、例えば、
図48及び
図49に示すデータセットにおいて、各IDのパーソナルデータを、各属性値を成分とするベクトルとして扱うことができる。例えば、
図48において、ID=1のパーソナルデータは、「D:Gender:1」、「D:Gender:2」、「D:Age:0-19」、「D:Age:20-34」等の属性値を成分とするベクトル(1,0,0,1,・・・)として扱うことができる。そして、ベクトル間の類似度又は距離を計算することで、パーソナルデータ同士の類似度を計算することができる。なお、ベクトル間の類似度と距離との関係については、類似度が高いほど距離は小さくなり、類似度が低いほど距離は大きくなる。
【0282】
そして、
図48に示す第1の情報銀行4aから受信されたID=1〜20のパーソナルデータと、
図49に示す第2の情報銀行5aから受信されたID=1〜20のパーソナルデータと、の類似度を計算することで、
図50に示すような類似度行列が得られる。
【0283】
図50に示す類似度行列において、行ラベルである「1 ID」は、第1の情報銀行4aのIDを意味し、列ラベルである「2 ID」は第2の情報銀行5aのIDを意味する。すなわち、1 ID=i、かつ、2 ID=jの成分は、第1の情報銀行4aのID=iのパーソナルデータと、第2の情報銀行5aのID=jのパーソナルデータと、の類似度を示す。
【0284】
なお、
図50に示す例では、2つのパーソナルデータ(すなわち、2つのベクトル)の類似度はコサイン類似度として計算されるが、2つのパーソナルデータの類似度の計算方法はこれに限られない。例えば、2つのパーソナルデータの類似度は、ユークリッド距離やマハラノビス距離等のその他の距離や類似度を用いて計算されてもよい。なお、
図50に示す類似度行列では、コサイン類似度は、0〜1の範囲内になるように規格化されていない。
【0285】
そして、類似度判定部1231は、類似度行列において、類似度が所定のしきい値(以下、類似度しきい値)以上である2つのパーソナルデータを、同一人物のパーソナルデータであるとして互いに紐付ける。
【0286】
例えば、
図50に示す例において、類似度が5以上の2つのパーソナルデータを同一人物のパーソナルデータとして特定した場合、以下の3つの組合せが同一人物のパーソナルデータの組合せとなる。
・第1の情報銀行4aのID=2のパーソナルデータ(1 ID=2)と、第2の情報銀行5aのID=10のパーソナルデータ(2 ID=10)
・第1の情報銀行4aのID=12のパーソナルデータ(1 ID=12)と、第2の情報銀行5aのID=12(2 ID=12)又は13(2 ID=13)のパーソナルデータ
・第1の情報銀行4aのID=18(1 ID=18)のパーソナルデータと、第2の情報銀行5aのID=7(2 ID=7)のパーソナルデータ
なお、上記の2番目の組合せのように1つのパーソナルデータに複数のパーソナルデータが紐付く場合がある。このような場合、例えば以下の(1)〜(3)の取扱いが考えられる。
(1)一のパーソナルデータに複数のパーソナルデータが紐づく場合は、前記一のパーソナルデータを含む組合せは除外する。すなわち、一のパーソナルデータに対して一のパーソナルデータが紐付く場合のみその2つのパーソナルデータを同一個人のパーソナルデータであると特定する。
(2)一のパーソナルデータに複数のパーソナルデータが紐付き、前記複数のパーソナルデータの前記一のパーソナルデータとの類似度が互いに異なる場合、前記複数のパーソナルデータのうち前記一のパーソナルデータとの類似度が高い方を優先する。そして、前記複数のパーソナルデータのうち優先されたパーソナルデータと前記一のパーソナルデータとを同一個人のパーソナルデータであると特定する。
(3)一のパーソナルデータに複数のパーソナルデータが紐付き、前記複数のパーソナルデータの前記一のパーソナルデータとの類似度が互いに場合、前記複数のパーソナルデータのうち、前記一のパーソナルデータよりも類似度が高いパーソナルデータがある場合、そちらで紐づけを行う。例えば、上記の例において仮に第2の情報銀行5aのID=12のパーソナルデータについて、第1の情報銀行4aのID=12のパーソナルデータよりも類似度が高い別のパーソナルデータが存在する場合、その別のパーソナルデータと第2の情報銀行5aのID=12のパーソナルデータとを紐付ける等。
【0287】
なお、上記(1)〜(3)の少なくとも2つが同時に採用されてもよい。このようにして、類似度判定部1231は、複数の情報銀行4a〜6aから受信された複数のパーソナルデータの中から、パーソナルデータの属性値が類似する複数のパーソナルデータを特定する。
【0288】
そして、続くS612の処理において、類似度判定部1231によって互いに紐付けられた複数のパーソナルデータは、同一個人のパーソナルデータであるとして、データ送信部341によってデータ利用者2aに送信される。
【0289】
[9−3.効果]
以上詳述した第9実施形態によれば、前述した第4実施形態の効果(4a)に加え、以下の効果が得られる。
【0290】
(9a)本実施形態では、仲介装置12は、複数の情報銀行4a〜6aから取得された複数のパーソナルデータ間の類似度であってパーソナルデータの属性値に基づく類似度を示す類似度行列に基づいて納品データを決定する。特に、仲介装置12は、類似度行列を重複確認情報として取得する。
【0291】
詳しくは、仲介装置12は、複数の情報銀行4a〜6aから複数のパーソナルデータを取得し、取得された複数のパーソナルデータについて、パーソナルデータの属性値に基づく類似度判定を行う(S611)。そして、仲介装置12は、類似度判定によって互いに類似していると判定された複数のパーソナルデータを互いに紐付ける(S611)。そして、仲介装置12は、紐付けられた複数のパーソナルデータに基づく納品データを利用者装置2に送信する。
【0292】
したがって、互いに紐付けられた複数のパーソナルデータを同一個人に係るパーソナルデータと見做すことで、複数の情報銀行4a〜6aから同一個人に係るパーソナルデータを名寄せすることができる。
【0293】
また、本実施形態によれば、第4実施形態のような登録管理者9aが存在しない時期、すなわち、登録管理者9aが現れる時期よりも前の時期であっても、複数の情報銀行4a〜6aから同一個人に係るパーソナルデータを名寄せできる。
【0294】
(9b)また、第1の情報銀行4aが管理するパーソナルデータの項目と、第2の情報銀行5aが管理するパーソナルデータの項目と、が異なる場合、両方の項目が補完されたパーソナルデータのサンプル数を出来るだけ多く得たいというニーズがあり得る。第4実施形態のように情報銀行ID、情報銀行登録者ID及び個人IDの3つのIDを使用して名寄せを行う場合、真に同一個人に係る複数のパーソナルデータのみ互いに紐付けられる。このため、上記サンプル数が多く得られない場合がある。この点、本実施形態によれば、パーソナルデータを紐付ける際の類似度しきい値を緩めることで、パーソナルデータの多対多の紐付けを許容することができる。その結果、前述したサンプル数を増加させることができる。
【0295】
なお、本実施形態では、
図50に示す類似度行列が類似度情報及び重複確認情報に相当し、S601がリクエスト取得部としての処理に相当し、S611が重複確認取得部としての処理に相当し、S611及びS612が決定部としての処理に相当し、S609及びS612が取得送信部としての処理に相当する。
【0296】
[10.他の実施形態]
以上、本開示を実施するための形態について説明したが、本開示は前述の実施形態に限定されることなく、種々変形して実施することができる。
【0297】
(1)上記各実施形態では、仲介装置は、複数の情報銀行装置4〜6からパーソナルデータを調達するが、仲介装置がパーソナルデータを調達する情報銀行装置の数はこれに限られない。例えば、上記第1〜第2実施形態において、仲介装置は、複数の情報銀行装置からパーソナルデータを調達せず、1つの情報銀行装置のみからパーソナルデータを調達してもよい。
【0298】
(2)上記各実施形態では、パーソナルデータ管理者として情報銀行を例示したが、パーソナルデータ管理者はこれに限られない。例えば、パーソナルデータ管理者は、通信キャリアやクレジットカード会社等、大量の顧客データを保有しているが、情報銀行を専らにしていない事業者であってもよい。このようにパーソナルデータ管理者は、個人から預託されたパーソナルデータを管理するとともに当該パーソナルデータを第三者に提供する事業を営むパーソナルデータ事業者であってもよい。
【0299】
(3)上記各実施形態では、仲介装置は、複数の情報銀行装置4〜6から受信された納品データのデータ形式を共通のデータ形式に合わせ、1つのデータに統合してデータ利用者2aに納品するが、納品の仕方はこれに限られない。例えば、仲介装置は、複数の情報銀行装置4〜6から受信された納品データを共通のデータ形式に合わせなくてもよい。また、仲介装置は、複数の情報銀行装置4〜6からの納品データを1つの納品データに統合しなくてもよい。
【0300】
(4)上記各実施形態における調達プランの決定ロジックはあくまで一例であり、他の決定ロジックで調達プランが決定されてもよい。例えば、上記各実施形態では、データ利用者2aの予算額の範囲内で元データ分布の再現性が最も高いプランが調達プランに決定される。しかし、例えば、予算額を多少(すなわち所定額)オーバーしても元データ分布の再現性が最も高い場合、そのプランが調達プランに決定されてもよい。つまり、予算額と元データ分布の再現性とに基づいて調達プランが決定される場合において、再現性の方を予算額よりも重視するように調達プランが決定されてもよい。一方、上記各実施形態のように予算額の方を再現性よりも重視するように調達プランが決定されてもよい。
【0301】
また例えば、情報銀行等のパーソナルデータ管理者がパーソナルデータを拡充するために個人に対してアンケートを実施しているような場合、そのアンケートに回答していない個人のパーソナルデータは欠測データとなる。このようにパーソナルデータ管理者が管理するパーソナルデータに欠測データが含まれている場合、欠測データが最も少なくなるように調達プランが決定されてもよい。
【0302】
また例えば、調達されるパーソナルデータの「鮮度」が最も良くなるように調達プランが決定されてもよい。具体的には、仲介装置は、パーソナルデータ管理者や自身の記憶部等からパーソナルデータの最終更新日時の情報を取得し、取得された最終更新日時の情報を基に調達プランを決定してもよい。この場合において例えば、仲介装置は、最新更新日時が新しいパーソナルデータから順に、調達されるパーソナルデータに決定するなどして調達プランを決定してもよい。
【0303】
また、或る情報銀行から受信されたメタデータに含まれるデータ価格が極端に安いあるいは極端に高い場合、換言すれば、データ価格が所定のしきい値以下あるいはしきい値以上である場合、そのデータ価格あるいはその情報銀行自体が怪しまれる。その場合、仲介装置は、その極端に安い又は高いデータを避けてパーソナルデータを調達するように調達プランを決定してもよい。また、仲介装置は、極端に安いあるいは極端に高いデータ価格を提示する情報銀行を避けて(つまりその情報銀行以外の情報銀行から)パーソナルデータを調達するように調達プランを決定してもよい。
【0304】
また例えば、仲介装置は、価格以外の要素を考慮し、同一の対象条件に合致する複数のパーソナルデータの中から最安値でないパーソナルデータを調達する調達プランを決定してもよい。
【0305】
具体的には例えば、仲介装置は、価格以外の要素として、パーソナルデータに含まれる属性のうち、対象条件で指定されていない属性(以下、非指定属性)と、データ利用者2aのパーソナルデータの利用目的等(ひいてはリクエスト情報)と、の適合度を考慮し、調達するパーソナルデータを決定してもよい。
【0306】
例えば、仲介装置が、性別が男性であり、年代が20代であるという対象条件を含むリクエスト情報を利用者装置2から受信したとする。そして、仲介装置は、上記対象条件に合致するパーソナルデータに係るメタデータを各情報銀行4a〜6aから受信する。このとき、リクエスト情報に含まれる利用組織の情報から、データ利用者2aが飲食関係の業種(例えば食品メーカ)であることが特定されるとする。そして、第1の情報銀行4aが保有するパーソナルデータには性別、年代以外の属性(すなわち、非指定属性)として、飲食に関する属性(食事ログなど)が含まれているとする。他方、第2の情報銀行5aが保有するパーソナルデータには非指定属性として飲食に関する属性が含まれていないとする。この場合、仲介装置は、第1の情報銀行4aのパーソナルデータの方がデータ利用者2aの利用組織や利用目的等との適合度が高いと判断し、価格が第2の情報銀行5aのデータより高くても、第1の情報銀行4aのデータを調達する調達プランを決定してもよい。
【0307】
また例えば、仲介装置は、データ利用者の業種と、情報銀行4a〜6aにデータを預託した個人の業種とが同じ場合には、データ利用者がその個人のデータを入手できないようにしてもよい。換言すれば、仲介装置は、その個人のパーソナルデータを除外して調達プランを決定してもよい。つまり、仲介装置は、データ利用者と、情報銀行4a〜6aにデータを預託した個人と、の関係性に基づいて調達プランを決定してもよい。また、その他の価格以外の要素を考慮し、調達プランが決定されてもよい。
【0308】
また例えば、仲介装置は、調達プランを決定するための条件(換言すれば、調達プランの決定ロジック)に関する要望をデータ利用者2aから取得し、取得された要望に基づいて調達プランを決定してもよい。
【0309】
また、仲介装置は、複数のプランの中からデータ利用者2aに適した調達プランを選択するのではなく、データ利用者2aに適した一の調達プランをいきなり出力してもよい。
【0310】
(5)
図5に例示されたリクエスト情報の具体例や
図6、
図7に例示されたメタデータ要求の具体例等はあくまで一例であり、リクエスト情報等は、
図5等に示す項目の一部のみ含んでいてもよく、
図5等に例示されていない他の項目を含んでいてもよい。
【0311】
(6)或る情報銀行からのメタデータは、その情報銀行が保有する全てのパーソナルデータの属性を示す情報であってもよく、また、一部のパーソナルデータのみの属性を示す情報であってもよい。また、メタデータは、パーソナルデータの一部の属性を示すものに限られず、パーソナルデータの全ての属性を示すデータであってもよい。
【0312】
(7)上記第2実施形態では、記憶部72にはメタデータセットが記憶されているが、記憶部72に記憶されるデータはこれに限られない。例えば、記憶部72には、各情報銀行装置4〜6の特徴を表す情報である情報銀行特徴情報が記憶されてもよい。情報銀行特徴情報は、具体的には例えば、第1情報銀行4aは20代〜40代の女性のパーソナルデータを多く管理している、第2情報銀行5aは家族持ちユーザのパーソナルデータを多く管理している、第3情報銀行3aは60歳以降のシニア層のユーザのパーソナルデータを多く管理している、等である。この場合において例えば、仲介装置が利用者装置2から家族持ちユーザのパーソナルデータを欲する旨のリクエスト情報を受信した場合に、家族持ちユーザのパーソナルデータを多く管理する第2情報銀行5aにメタデータ要求やデータ要求を送信してもよい。そして、仲介装置は、第2情報銀行5aからパーソナルデータを調達する調達プランを決定してもよい。また逆に、仲介装置は、利用者装置2から家族持ちユーザのパーソナルデータを欲する旨のリクエスト情報を受信した場合に、家族持ちユーザのパーソナルデータをあまり管理していない情報銀行を避けるように、メタデータ要求やデータ要求を送信してもよい。
【0313】
すなわち、仲介装置は、情報銀行特徴情報に基づいて、リクエスト情報に含まれる対象条件に適合する特徴を有すると判断した情報銀行(ひいてはパーソナルデータ管理者)に対してメタデータ要求及び/又はデータ要求を送信してもよい。また、仲介装置は、情報銀行特徴情報に基づいて、リクエスト情報に含まれる対象条件に適合する特徴を有しないと判断した情報銀行(ひいてはパーソナルデータ管理者)に対してメタデータ要求及び/又はデータ要求を送信しなくてもよい。
【0314】
なお、仲介装置は、情報銀行特徴情報を自身の記憶部72から取得するのではなく、各情報銀行4a〜6aに対して問い合わせることで各情報銀行4a〜6aから情報銀行特徴情報を取得してもよい。
【0315】
なお、情報銀行特徴情報は、各パーソナルデータ管理者の特徴を表す情報である管理者特徴情報の一例に相当する。また、管理者特徴情報は、パーソナルデータ管理者が管理するパーソナルデータの属性を示す情報である属性情報の一例である。
【0316】
(8)更新処理部732,932が実行する更新処理の内容は、上記第2及び第5実施形態のものに限られない。
【0317】
例えば、上記第2実施形態において、更新処理部732は、記憶部72に記憶されているメタデータセットを、情報銀行4a〜6aから調達されたパーソナルデータに基づいて更新してもよい。具体的には例えば、情報銀行4a〜6aから調達されたパーソナルデータ(すなわち購入されたパーソナルデータ)については、そのパーソナルデータの属性(すなわちデータの内容)がわかる。更新処理部732は、調達されたパーソナルデータの内容に基づき、調達先の情報銀行4a〜6aが保有しているパーソナルデータの属性に基づく分布を更新するなどして、記憶部72に記憶されているメタデータセットを更新してもよい。
【0318】
同様に、上記第5実施形態において、更新処理部932は、記憶部112に記憶されている重複状況テーブルを、情報銀行4a〜6aから調達されたパーソナルデータに基づいて更新してもよい。具体的には例えば、仲介装置が、複数の情報銀行4a〜6aから対象条件に合致するパーソナルデータを調達(すなわち購入)したとする。その際、仲介装置は、購入された複数のパーソナルデータの属性(すなわちデータの内容)を互いに比較し、購入された複数のパーソナルデータが同一個人に係るパーソナルデータであるか否かをデータの内容の類似度等から判断する。そして、仲介装置は、同一個人に係るパーソナルデータと判断した複数のパーソナルデータについては同一の個人IDを設定し、
図35に示す重複状況テーブルにデータを新たに追加してもよい。
【0319】
(9)上記第5実施形態において、仲介装置は、管理者装置9に重複確認を行わず、記憶部112に記憶された重複状況テーブルに基づき重複確認を行うが、以下のような場合に管理者装置9に対し、重複確認を行ってもよい。
【0320】
すなわち、仲介装置は、ID受信部833により受信されたID結果情報に含まれる各情報銀行登録者IDについて、記憶部112に記憶されている重複状況テーブルで重複状況を確認する。このとき、重複状況テーブルに該当する情報銀行登録者IDがない場合など、記憶部112に記憶されている重複状況テーブルでは重複状況が確認できない情報銀行登録者IDが存在する場合がある。この場合、仲介装置は、重複状況が不明な情報銀行登録者IDについてのみ、管理者装置9に重複状況を問い合わせてもよい。そして、管理者装置9から受信された重複結果情報に基づき、重複状況が不明な情報銀行登録者IDのデータを登録するなどして重複状況テーブルを更新してもよい。
【0321】
(10)上記第3〜第5実施形態では、仲介装置は、ID結果情報に含まれる情報銀行登録者IDについて管理者装置9に問い合わせることにより、又は、記憶部112に記憶された重複状況テーブルを参照することにより、前記IDについて重複確認を行う。そして、仲介装置は、重複確認の結果を踏まえて、各情報銀行4a〜6aにメタデータ要求を送信する。しかし、重複確認を行うタイミングはこれに限られない。
【0322】
例えば、第3実施形態において、仲介装置は、ID要求を各情報銀行4a〜6aに送信せず、メタデータ要求を各情報銀行4a〜6aに送信する。ここで、仲介装置は、各情報銀行4a〜6aから、同一個人のデータの重複を許容した形でメタデータを受信する。
【0323】
このとき、仲介装置は、メタデータと併せて、各情報銀行4a〜6aから、メタデータにデータが含まれている個人に係る情報銀行登録者IDのリストを受信する。
【0324】
そして、仲介装置は、受信された情報銀行登録者IDのリストについて、管理者装置9に対して重複確認要求を行う。このように、メタデータ受信後に、重複確認が行われてもよい。
【0325】
(11)上記第3〜第6実施形態では、仲介装置は、
図28に示すような情報銀行登録者ID及び価格の組のリストを含むID結果情報を受信するが、ID結果情報はこれに限られない。例えば、登録管理者9aの管理者装置9が、
図35に示すような、価格情報を含む重複状況テーブルを保有していてもよい。この場合、
図35に示すような、価格情報を含む重複状況テーブルを保有していてもよい。その場合には、
図28に示すID結果情報には情報銀行登録者IDのリストのみが含まれていてもよい。また、
図30に示す重複結果情報には({ID,価格},{ID,価格},{ID,価格}…)といった形の、各情報銀行4a〜6aについての情報銀行登録者IDと価格との組のリストが含まれていてもよい。そして、例えば仲介装置は、受信されたリストに基づき、最安値以外のIDについてはメタデータにおいて除外IDとして指定してもよい。
【0326】
(12)上記第3〜第6実施形態では、登録識別情報として、情報銀行4a〜6aにパーソナルデータを預託した個人を識別する情報である情報銀行登録者IDを例示したが、登録識別情報はこれに限られない。登録識別情報は、例えば、各情報銀行4a〜6aが当該情報銀行4a〜6aに預託されたパーソナルデータに付与する識別情報であってもよい。
【0327】
(13)上記第6実施形態では、通知情報として広告情報を例示したが、通知情報はこれに限られない。例えば、通知情報は、個人に商品やサービスをレコメンドするレコメンド情報等であってもよい。
【0328】
(14)上記第6実施形態では、広告情報の送信先情報が、情報銀行4a〜6aから取得されたパーソナルデータに含まれていることが想定される。しかし、例えば、送信先情報が情報銀行4a〜6aから取得されたパーソナルデータに含まれていない場合等において、次のように広告配信が行われてもよい。
【0329】
すなわち、利用者装置2等の広告配信装置は、配信対象者別の広告情報などの通知情報を仲介装置を介して間接的に又は仲介装置を介さず直接的に情報銀行4a〜6aに送信する。そして、情報銀行4a〜6aが、パーソナルデータを預託した個人に対し、広告配信装置から受信した通知情報を送信してもよい。つまり、利用者装置2等の広告配信装置は、情報銀行4a〜6aを通じて、パーソナルデータを預託した個人に対して広告配信を行ってもよい。
【0330】
この場合において、情報銀行4a〜6aは、自身が持つ、パーソナルデータを預託した個人との何らか接点を利用して広告配信を行ってもよい。
【0331】
具体的には例えば、情報銀行4a〜6aの情報銀行装置4〜6は、パーソナルデータを預託した個人の情報処理端末11〜17に対して電子メールで通知情報を送信してもよく、個人が閲覧するインターネットのウェブサイトに通知情報を出力させてもよい。また例えば、情報銀行装置4〜6は、個人の情報処理端末11〜17にインストールされたアプリケーションソフトウェア内で通知情報を出力させてもよく、個人が来店する店頭などのエリアに設置された端末に通知情報を出力させてもよく、その他種々の方法で通知情報を個人に対して送信してもよい。
【0332】
このような構成によれば、データ利用者2a等が取得したパーソナルデータに送信先情報が含まれていなくても、データ利用者2a等は、個人に対し、広告配信を行うことができる。
【0333】
(15)上記第6実施形態では、利用者装置2が広告配信を行うが、広告配信を行う主体はこれに限られない。例えば、広告代理店等の広告配信事業者や広告配信を行うプラットフォーマーなどの、データ利用者2aとは別の者が保有する装置が広告配信を行ってもよく、仲介装置が広告配信を行ってもよい。この場合において、広告配信事業者やプラットフォーマーが保有する装置や仲介装置などが
図40に示す広告配信処理を行ってもよい。
【0334】
(16)また例えば、前述した[7.他の実施形態]の(14)で述べたように、仲介装置等が、情報銀行4a〜6aにパーソナルデータを預託した個人に情報銀行4a〜6aを介して広告配信を行う場合などにおいて、仲介装置等は広告成果指標を計算してもよい。ここでいう広告成果指標とは、広告配信に関する成果を示す指標である。
【0335】
具体的には例えば、仲介装置は、登録管理者9aの管理者装置9から取得された重複結果情報を利用して、広告成果指標としてのユニークユーザ数を計算してもよい。ユニークユーザ数は、広告配信が行われたユーザの数である。
【0336】
すなわち、各情報銀行4a〜6aが、当該情報銀行4a〜6aにデータを預託している個人に対して広告配信を行う場合、複数の情報銀行4a〜6aにパーソナルデータを預託している個人については、複数の情報銀行4a〜6aから同一の広告情報が送信される場合がある。このような場合でも、重複結果情報を利用すれば、いずれの個人に対して広告情報が重複して配信されたかがわかるため、ユニークユーザ数を計算することができる。また、仲介装置は、重複結果情報を利用して、ユニークユーザ数以外の広告成果指標を計算してもよい。
【0337】
また例えば、仲介装置等は、情報銀行4a〜6aを介して広告配信を行う場合等において、重複結果情報に基づいて広告配信を行ってもよい。具体的には例えば、仲介装置等は、同一の広告情報が同一人物に複数の情報銀行4a〜6aから重複して送信されないように、複数の情報銀行装置4〜6のうちの一の情報銀行装置以外には配信内容と共に除外IDを送信する。ここで、情報銀行装置4〜6は、受信された除外IDで指定される情報銀行登録者IDに係る個人に対しては、広告配信を行わない。このようにすることで、前記一の情報銀行装置以外の情報銀行装置が広告配信を行わないようにしてもよい。もちろん、重複結果情報を用いたその他の方法で、同一の広告情報が同一人物に重複して送信されないようにしてもよい。
【0338】
(17)上記第9実施形態では、類似度しきい値は一定に設定されるが、類似度しきい値はこれに限られず、類似度しきい値を変動させてもよい。この場合において例えば、類似度しきい値は次のように変動してもよい。
【0339】
すなわち、
図51に示すように、類似度しきい値tを連続的に変化させると紐付け成功数が変化する。紐付け成功数とは、互いに類似していると判断され、互いに紐付けられるパーソナルデータの組合せの数である。
【0340】
図51から見て取れるように、類似度しきい値tが大きくなるほど紐付け成功数が減少する。そのため、類似度しきい値tを大きく設定しすぎると、本来同一個人のパーソナルデータの組合せと見做すべきパーソナルデータの組合せを、同一個人のパーソナルデータの組合せでないとして、取りこぼす可能性がある。また逆に、類似度しきい値tを小さく設定しすぎると、同一個人に由来しないパーソナルデータ同士の組合せが多数発生する可能性がある。このため、類似度しきい値tを大きく設定しすぎず、かつ、小さく設定しすぎないことが望ましいと考えられる。
【0341】
このような考え方の下、例えば、
図51に示すように類似度しきい値tを連続的に変化させたときに、紐付け成功数の変化が最大になる類似度しきい値tの値t
MAXを最適なしきい値として採用することが考えられる。t
MAXは、換言すれば、紐付け成功数nを類似度しきい値tの関数n=f(t)と見做したときの関数n=f(t)の接線の傾きが最小となる類似度しきい値tの値である。
【0342】
また、t
MAXの値が小さい場合など、類似度しきい値tをt
MAXに設定してパーソナルデータの紐付けを行うと、同一個人に由来しないパーソナルデータ同士の組合せが多数発生してしまう場合がある。このような場合、t
MAXの次に紐付け成功数の変化が大きい類似度しきい値tの値、換言すれば、関数n=f(t)の接線の傾きが2番目に小さくなる類似度しきい値tの値t
2MAXを最適なしきい値として採用してもよい。もちろん、接線の傾きが3番目、4番目、・・・に小さい値を最適なしきい値tとして採用してもよい。
【0343】
なお、類似度しきい値tをt
MAX、t
2MAX、・・・等のうちのいずれに設定するかはユーザによって設定されてもよく、また、システムによって自動的に設定されてもよい。
【0344】
また例えば、複数のパーソナルデータが互いに類似しているか否かを、次のように判定してもよい。すなわち、パーソナルデータの年齢や性別等の属性(換言すれば、パーソナルデータのデータ項目)ごとにパーソナルデータ同士の類似度を計算する。そして、全部又は一部の属性について類似度がしきい値以上であると判定される場合に、複数のパーソナルデータが互いに類似していると判定されてもよい。
【0345】
また例えば、以下に詳述するように、パーソナルデータのデータ項目に対応する座標軸を有し、各パーソナルデータを点やベクトルなどとして表現する座標空間において新たな座標軸を設定する。そして、設定された各座標軸についての類似度がしきい値以上である場合に、複数のパーソナルデータが互いに類似している、ひいては、同一個人に係るパーソナルデータであると判定されてもよい。そして、例えば、上記と同様に類似度しきい値を変動させ、最適な類似度しきい値を求めてもよい。具体的には以下のように類似度しきい値を求めてもよい。
【0346】
すなわち、
図52に示すように、まず、情報銀行4a〜6aから取得されたパーソナルデータのデータセットを座標空間にプロットする。
図52において各データ点はパーソナルデータを表す。また、
図52の座標空間の各座標軸はパーソナルデータの各属性(すなわち、各データ項目)に対応する。例えば「性別=男性」というデータ項目に対応する座標軸については、各パーソナルデータは、男性に該当するか否かに応じて0又は1の値を取る。また、「3ヶ月雑誌購買金額」というデータ項目に対応する座標軸については、各パーソナルデータは、該当する購入金額に値を取る。
【0347】
そして、前記データセットに対して、主成分分析や多様体学習を行うことで、データセットをより良く記述する新たな座標軸を構成する。
図52では、x
1座標軸及びx
2座標軸が新たな座標軸である。
【0348】
そして、新たな座標軸ごとに類似度しきい値t=(t
1,t
2,・・・)を設定する。ここでいう類似度しきい値tは、例えば、2つのパーソナルデータの各成分の属性値の差分に関するしきい値であってもよい。具体的には例えば、或るパーソナルデータAが前記新たな座標軸で座標x
A=(x
1A,x
2A,・・・)で表現され、別のパーソナルデータBが新たな座標軸で座標x
B=(x
1B,x
2B,・・・)で表現されるとする。この場合、2つのパーソナルデータA,Bは、以下のように、各成分の差分の絶対値が類似度しきい値以下である場合に互いに類似していると判定されてもよい。
Δx
1≡|x
1A−x
1B|≦t
1 かつ Δx
2≡|x
2A−x
2B|≦t
2・・・
そして、
図53に示すように、類似度しきい値t=(t
1,t
2,・・・)の各成分t
iを連続的に変化させたときに、紐付け成功数nの変化が最大に類似度しきい値t
MAX=(t
MAX1,t
MAX2,・・・)等を最適なしきい値として採用してもよい。
【0349】
このように類似度しきい値tを動的に変化させることで、パーソナルデータのデータセットごとに最適な類似度しきい値tを設定することができる。ひいては、同一個人のパーソナルデータの組合せと見做すべきパーソナルデータの組合せを取りこぼしたり、同一個人に由来しないパーソナルデータ同士の組合せを多数発生させたりする可能性を低減することができる。
【0350】
なお、上記のように主成分分析や多様体学習を行い新たな座標軸を設定することは必須ではない。しかし、新たな座標軸を設定することで一般に各パーソナルデータを少ない次元の座標として表現でき得る。このため、コンピュータ処理において計算量を低減でき、ひいては処理を高速化できる。
【0351】
(18)上記各実施形態では、仲介装置は、情報銀行4a〜6aから取得されたパーソナルデータに基づく納品データを直接利用者装置2に送信する。しかし、データ利用者2aに納品データを送信する仕方はこれに限られない。例えば、仲介装置が一旦納品データを仲介装置及び利用者装置のいずれでもない別の装置に送信する。そして、当該別の装置を介して納品データが利用者装置2に送信されてもよい。このように別の装置を経由して仲介装置から利用者装置2に納品データが送信される場合も、本願でいう「仲介装置が利用者装置2に納品データを送信する」に包含されるものとする。
【0352】
(19)前述した仲介装置の他、当該仲介装置を構成要素とするシステム、当該仲介装置としてコンピュータを機能させるためのプログラム、このプログラムを記憶した半導体メモリ等の非遷移的実体的記憶媒体、パーソナルデータを調達する方法など、種々の形態で本開示を実現することもできる。
【0353】
(20)上記各実施形態における1つの構成要素が有する複数の機能を、複数の構成要素によって実現したり、1つの構成要素が有する1つの機能を、複数の構成要素によって実現したりしてもよい。また、複数の構成要素が有する複数の機能を、1つの構成要素によって実現したり、複数の構成要素によって実現される1つの機能を、1つの構成要素によって実現したりしてもよい。また、上記各実施形態の構成の一部を省略してもよい。また、上記各実施形態の構成の少なくとも一部を、他の上記各実施形態の構成に対して付加又は置換してもよい。なお、請求の範囲に記載した文言によって特定される技術思想に含まれるあらゆる態様が本開示の実施形態である。