JP5238137B2 - 情報仲介システム、および、情報仲介方法 - Google Patents

Description

本発明は、情報仲介システムに係り、利用者と提供者の間でやり取りされる情報を仲介するシステムであって、個人情報やプライバシ情報を外部へ安全に公開するシステムであって、しかも、利用者が状況に応じて個人情報を容易に得るようにもできる情報仲介システムに関する。

２００５年４月から、個人情報保護法の全面施行が開始された。個人情報とは、特定の個人を識別できる情報であり、単体情報で識別できるものの他に、他の情報と組み合わせることで容易に識別できるものも対象となる。個人情報を利用するためには、個人情報取得時に本人に対して利用目的の通知・承認が必要であり、第三者へ提供には本人の同意が必要である。

ところで、近年、自動車のＩＴ化は著しく、自動車には様々な情報処理装置を組み込んで制御するようになってきた。したがって、自動車に搭載されている情報処理装置により、車両の中に流れる様々な情報、例えば、エンジン回転数、ブレーキ踏み具合、位置情報（経路情報）などを収集することが可能である。このような車両情報も個人情報にあたるとされ、現在、業界では利用方法のガイドラインの制定が進められている。そのため、個人情報や車両情報、プライバシ情報などの情報を仲介する場合には、誰にどんな情報を提供するのかに応じて、フィルタリングや加工などの制御をおこなわなければならない。

個人情報やプライバシ情報を仲介する従来技術として、提供する情報の中から個人を特定する項目を削除する方法がある。これは、例えば特許文献１に記載される。ここでは、顧客と販売店との間での決済を仲介するシステムにおいて、顧客は販売店から買い物をするために名前や住所、買いたい品物などの情報を記入して仲介システムに送る。仲介システムでは、顧客の名前や住所などの個人を特定できる項目のみを削除し、それ以外の情報を販売店に提供する。

また、別の個人情報やプライバシ情報を仲介する従来技術として、ある特定の指標値に換算して提供する方法がある。例えば、特許文献２では、ネットオークションなどを対象とした仲介システムにおいて、出品者と購入者の間で、個人情報やプライバシ情報を保護しつつ、購入者の安心を実現する。この特許文献２では、出品者の情報を購入者に開示する場合に、名前や住所をそのまま公開するのではなく、「同じ地域に住んでいる人です」や「同じ年齢の人です」といった別の指標（この場合は購入者との相対関係）に換算して提供する。これにより、出品者は個人情報やプライバシ情報を開示する必要はなくても、購入者はある程度安心感を持って購入することができる。

特開２００３−２４８７８０号公報 特開２００３−２８８５２６号公報

上述した特許文献１に開示されている項目を削除する方法では、削除して匿名化した情報を提供した後で、個人を特定しなければならなくなった場合に対処ができないという問題点がある。例えば、自動車分野では、自動車メーカは車から経路などの車両情報を収集している。収集した車両情報を損害保険会社（以下、略して「損保」ともいう）などの外部に公開する場合には、個人情報保護法などの制約により、個人を特定可能な状態では公開することができない。損保などの外部に情報を提供する場合には、名前や住所、電話番号といった個人を特定可能な項目を削除し、情報を匿名化しなければならない。

一方、損保では、車の安全性向上に伴い、従来のような全員を対象とした保険ではなく、特定の顧客のニーズを満たすきめ細かい保険メニューの品揃えが求められている。匿名化された情報を活用してマーケティング分析をおこない、新規の保険メニューを企画することは可能である。しかしながら、実際にサービス開始する場合に、個人が特定できていないため、ダイレクトメールの送付など、対象となる顧客に効率的にアピールする手段がない。また、こうしたマーケティング分析をおこなうためには莫大な数な情報が必要となるため、情報収集に多大な時間が必要となってしまう。

また、上述した特許文献２に開示された指標値に換算する方法では、上記項目を削除する方法と同様に、指標値に換算した情報だけでは個人が特定できないため、マーケティング分析としては活用できるが、サービス対象の顧客だけに特別なアピールをすることができない。ダイレクトメールなどの特別なアピールをするためには、個人の特定が必要となってしまう。また、この指標値に換算する方法では、損保などがマーケティング分析をする場合に、どのようなサービスを考えているのかが指標値から推定される恐れがあり、仲介システムを提供するカーメーカに同等サービスを先に実現されてしまう可能性がある。損保の立場で考えた場合、カーメーカを通して顧客の情報は取得したいが、どのような分析をおこなっているのかは隠蔽したい。

本発明は、上記問題点を解決するためになされたもので、その目的は、利用者と提供者の間の情報を仲介する情報仲介システムにおいて、仲介システムが定期的に提供者情報を蓄積し、提供者が蓄積済みの過去情報も含めて、利用者に提供情報を公開する範囲をきめ細かい条件に基づいて定義し、情報公開の仕方を変更できるような情報仲介システムを提供することにある。

また、初めは情報を名寄せできように加工して利用者に提供し、後から複数情報を名寄せするための関係情報を提供することで、利用者に提供済みの情報の匿名性を解除可能にすることができるような情報仲介システムを提供することを目的とする。

本発明の情報仲介システムは、情報提供者端末が仲介サーバを介して利用者端末がネットワークに接続されている。情報提供者端末は、例えば、自動車に車載される車載端末であり、利用者端末は、自動車の保険を企画する損保の利用者が利用する端末である。

仲介サーバは、情報提供者の属性を管理するサーバ、情報提供者の情報を管理するサーバ、利用者情報を管理するサーバが接続されている。

仲介サーバは、不定期あるいは定期的に情報提供者端末から情報を収集し、情報提供者の情報を管理するサーバに蓄積するために送信する。

利用者情報を管理するサーバには、利用者の会社、業種、部署などにしたがって、情報提供者の情報の各項目と情報提供者の属性の各項目を公開する条件が定義されている。

利用者端末から要求があったときには、仲介サーバは、情報提供者の属性を管理するサーバと情報提供者の情報を管理するサーバから情報を受け取り、公開が許されていない情報提供者の属性の各項目と情報提供者の情報の各項目の組合せを名寄せできなくなるようにダミー情報に置き換えて、利用者端末に対して公開する。

また、利用者端末から仲介サーバを介して情報提供者端末に公開要求を送ることができ、情報提供者が許可したときには、仲介サーバは、名寄せできなくしたダミー情報を元に戻せるような関係情報を生成して利用者端末に送信する。

これにより、仲介システムが定期的、あるいは、不定期に提供者情報を蓄積することで、提供者が蓄積済みの過去情報も含めて、日付や利用者の業種などのきめ細かい条件に基づいて情報公開の設定することができる。また、初めは情報を名寄せできないように加工して利用者に提供し、後から複数情報を名寄せするための関係情報を提供することで、利用者に提供済みの情報の匿名性を解除することができる。利用者は過去情報も含めて収集できるため、情報を集める時間を短縮することができ、マーケティング分析やサービス開始を早期に実現することができる。

本発明によれば、利用者と提供者の間の情報を仲介する情報仲介システムにおいて、仲介システムが定期的に提供者情報を蓄積し、提供者が蓄積済みの過去情報も含めて、利用者に提供情報を公開する範囲をきめ細かい条件に基づいて定義し、情報公開の仕方を変更できるような情報仲介システムを提供することができる。

また、初めは情報を名寄せできように加工して利用者に提供し、後から複数情報を名寄せするための関係情報を提供することで、利用者に提供済みの情報の匿名性を解除可能にすることができるような情報仲介システムを提供することができる。

以下、本発明に係る一実施形態を、図１ないし図２０を用いて説明する。
先ず、図１および図２を用いて本発明の一実施形態に係る情報仲介システムの構成について説明する。
図１は、本発明の一実施形態に係る情報仲介システムのシステム概要図である。
図２は、本発明の一実施形態に係る情報仲介システムの機能構成図である。

本実施形態の情報仲介システムは、図１に示されるように利用者端末１０２、仲介サーバ１０５、車両情報管理サーバ１０７、会員管理サーバ１０９、認証サーバ１１１、車両１１５から構成される。

利用者端末１０２には、ハードディスク１０３が接続されている。仲介サーバ１０５、車両情報管理サーバ１０７、会員管理サーバ１０９、認証サーバ１１１には、それぞれデータベース１０６、１０８、１１０、１１２を管理している。データベース１０６、１０８、１１０、１１２は、データを組織的に管理し、それにアクセスする方法が定義されたものであり、データベースの他に、ファイルやメモリなどでもよい。利用者端末１０２は、利用者１０１が操作する端末であり、例えば、利用者１０１が損害保険会社の商品企画部員で、利用者端末１０２が損害保険会社のパソコンとなる。利用者端末１０２と仲介サーバは、インターネット１０４を介して接続されている。インターネット１０４は、有線接続でもよいし、無線接続でもよい。また、利用者端末１０２と仲介サーバ１０５は、専用ケーブルで接続されていてもよい。例えば、仲介サーバ１０５、車両情報管理サーバ１０７、会員管理サーバ１０９、認証サーバ１１１は、カーメーカが管理しているサーバである。仲介サーバ１０５、車両情報管理サーバ１０７、会員管理サーバ１０９、認証サーバ１１１は社内ネットワーク１１３を介して接続されている。社内ネットワークは、有線接続でもよいし、無線接続でもよい。仲介サーバ１０５は顧客の車両１１５から情報を収集し、損保などの第三者に情報を提供する。

車両情報管理サーバ１０７は、車両１１５から収集した車両情報を蓄積しておくためのサーバであり、接続されているデータベース１０８に車両情報が格納される。

会員管理サーバ１０９は、氏名や住所といった顧客の情報を管理するためのサーバであり、接続されているデータベース１１０に顧客情報が格納される。

認証サーバ１１１は、利用者１０１が正規の利用者か否かを認証するためのサーバであり、接続されているデータベース１１２に認証に必要な情報が格納されている。

車両１１５は、車載端末１１７、ハードディスク１１８、 ＥＣＵ１２０，１２１から構成される。ＥＣＵ（Electric Control Unit）は、電子制御装置であり、車のエンジンや足回りなどの制御をおこなっている。車載端末１１７とＥＣＵ１２０，１２１は、車内ネットワーク１１９で接続されており、車載端末１１７は、エンジン回転数やアクセル開度といったＥＣＵ１２０，１２１が持っている情報を取得することができる。ハードディスク１１８は、ＥＣＵ１２０，１２１から収集した車両情報を蓄積するためのもので、フラッシュメモリなどでもよい。また、車載端末１１７に内蔵されているものでも、ＵＳＢなどのケーブルで接続された外部装置でもよい。車載端末１１７には携帯電話が接続されており、車載端末１１７と仲介サーバ１０５は携帯網１１４を介して接続する。ただし、常時接続されているわけではなく、運転手１１６の車載端末１１７の画面に表示されたボタン押下などのアクションにより接続され、必要なデータのやり取りが終了したら切断される。

なお、本実施形態では、車両の所有者と運転手１１６は同一人物と仮定する。情報提供者として、利用者１０１に情報を提供するのは、この運転手１１６である。

次に、図２を用いて本実施形態の情報仲介システムの機能構成を説明する。

利用者端末１０２は、情報公開要求部２０１、情報取得部２０２から構成され、データとして取得済み情報２０３を有する。取得済み情報２０３が格納される物理媒体は、ハードディスク１０３である。仲介サーバ１０５は、情報提供部２１１、提供履歴管理部２１２、車両情報収集部２１４、情報公開管理部２１５から構成され、データとして提供履歴２１３、公開パターン２１６を有する。提供履歴２１３、公開パターン２１６は、データベース１０６に格納される。会員管理サーバ１０９は、会員管理部２２１から構成され、データとして会員情報２２２を有する。会員情報２２２は、データベース１１０に格納される。

車両情報管理サーバ１０７は、関係情報生成部２３１、車両情報管理部２３２、車両情報蓄積部２３４から構成され、データとして加工履歴２３３、車両情報２３５を有する。加工履歴２３３、車両情報２３５は、データベース１０８に格納される。

認証サーバ１１１は、認証部２４１、公開条件管理部２４３から構成され、データとして利用者情報２４２、公開条件２４４を有する。利用者情報２４２、公開条件２４４は、データベース１１２に格納される。

車載端末１１７は、情報公開設定部２５１、車両状態管理部２５２、車両情報提供部２５３、車両情報蓄積部２５４、車両情報取得部２５６から構成され、データとして車両情報２５５を有する。車両情報２５５が格納される物理媒体はハードディスク１１８である。

情報取得部２０２は、情報提供部２１１に対して要求を送り、得られた結果を取得済み情報部２０３に蓄積する。例えば、損保の商品企画部員が、新規保険メニュー検討のために、カーメーカを通して顧客の車両情報（どのように車を利用しているか）を収集する。情報提供部２１１では、認証部２４１に問い合せて利用者が正規利用者なのか否かの確認と、指定された情報に対して公開してもよいか否かを調べる。公開してもよい場合には、会員管理部２２１や車両情報管理部２３２に問い合せて情報を取得し、取得した結果情報を情報取得部２０２に対して応答する。

情報公開要求部２０１は、仲介サーバ１０５経由で運転手１１６に対して、情報公開の要求を送信する。保険会社がマーケティング分析に必要な情報を運転手１１６に公開要求するものである。仲介サーバ１０５内の情報公開管理部２１５では、車載端末１１７内の情報公開設定部２５１に送り、車載端末１１７の画面に要求を表示する。運転手１１６に許可が得られた場合、情報公開管理部２１５は、公開条件管理部２４３に許可情報を送り、公開条件を設定する。また、情報公開要求部２０１に対して、公開が許可されたか否かの結果を応答する。

車両情報収集部２１４は、車載端末１１７内の車両情報提供部２５３経由で車両情報を収集し、収集した車両情報を車両情報蓄積部２３４経由で蓄積する。車両情報は、車両情報取得部２５６から収集された車両情報が車両情報蓄積部２５４経由で車両情報２５５に格納される。車両情報取得部２５６は、車内ネットワーク１１９を介してＥＣＵ１２０，１２１から情報を取得する機能を備えている。

次に、図３ないし図１１を用いて本発明の一実施形態に係る情報仲介システムのデータ構造について説明する。

図３は、利用者情報２４２の詳細な構造を示す図である。

利用者情報２４２は、図３に示されるようにユーザＩＤ３０１、パスワード３０２、氏名３０３、会社名３０４、業種３０５、部署３０６、利用方法３０７の項目から構成される。ユーザＩＤ３０１は、利用者を一意に識別するためのものであり、情報取得部２０２から情報提供部２１１への情報取得要求にはユーザＩＤ３０１とパスワード３０２が指定されている。認証部２４１では、ユーザＩＤ３０１とパスワード３０２を用いて認証をおこなう。氏名３０３は、利用者の名前、会社名３０４は、利用者が属する会社の名前、業種３０５は、利用者が属する会社の種類、部署３０６は、利用者が会社で属する部署、利用方法３０７は、取得した車両情報の利用方法を示している。

図４は、公開条件２４４の詳細な構造を示す図である。

公開条件２４４は、図４に示されるように各利用者の属性に対応して車両情報に対して公開するときの条件を管理するものであり、車両番号４０１、データ項目４０２、公開制限４０３、公開範囲４０４の項目から構成される。車両番号４０１は車両１１５を一意に識別するためのものである。データ項目４０２は、公開の対象であるデータを示している。車両情報には様々なものがあるが、例えば、エンジン回転数、経路（複数の位置情報）、燃費、ナビ（ナビゲーション）の目的地情報、ナビの操作履歴などが挙げられる。これらのデータ項目単位に公開するための条件を設定することができる。公開制限４０３は、車両番号４０１で示される特定車両の、データ項目４０２で示される特定データ項目の利用者に対する利用許可を表すものである。公開制限４０３では、利用者の属性情報を利用して、利用者の制限をおこなう。利用者の属性情報としては、氏名３０３、会社名３０４、業種３０５、部署３０６、利用方法３０７などがあり、例えば、「利用者の業種がカーメーカまたはディーラの人にのみ公開する」という制限を設定する。もちろん、「利用者の業種がディーラ以外の人にのみ公開する」という制限も可能である。公開範囲４０４は、データ項目の一部分を公開する場合などの指定する条件を表している。公開範囲４０４では、取得日時（曜日、時刻などを含む）や位置などを指定して公開するか否かを制限することができる。例えば、「平日（月、火、水、木、金）のみ公開する」、「自宅周りの情報は公開しない」、「２００６年１月２３日以降の情報は公開する」などの指定をすることができる。公開条件管理部２４３では、情報取得部２０２からの取得要求に対して、公開条件２４４の情報を用いて提供情報を公開することが可能なのか否かを判定する。

図５は、会員情報２２２の詳細な構造を示す図である。

会員情報２２２は、図５に示されるように会員ＩＤ５０１、車両番号５０２、氏名５０３、年齢５０４、性別５０５、住所５０６、電話番号５０７の項目から構成される。

このシステムでは、車両の所有者（運転手１１６）は、カーメーカ主催のユーザ会に登録するものとする。

会員ＩＤ５０１は、会員を一意に識別するためのものである。車両番号５０２は、会員が所有している車両の番号であり、車両番号５０２は、車両を一意に識別する識別子である。氏名５０３は、会員の名前であり、年齢５０４は、会員の年齢、性別５０５は、会員の性別、住所５０６は、会員の住所であり、電話番号５０７は会員の電話番号である。個人情報保護法により、個人情報を無許可で損保などの第三者に提供することはできない。氏名や住所、電話番号といった情報は個人情報に当たるため、そのままの形で提供することはできない。情報の公開が許されていないときには、住所の番地などの詳細部分は削除してしまうなどの加工が必要である。

図６は、車両情報２３５の詳細な構造を示す図である。

車両情報２３５は、図６に示されるように車両番号６０１、取得日時６０２、データ名６０３、データ値６０４の項目から構成される。

車両番号６０１は、車両を一意に識別するためのものである。取得日時６０２は車両情報管理サーバ１０７がデータを取得した日時、データ名６０３は、データの名前、データ値６０４は、データ名６０３の値を示すものである。例えば、データ名６０３は「位置」で、それに対応するデータ値６０４は「ｘ，ｙ（ｘ：緯度、ｙ：経度）」などである。

図７は、取得済み情報２０３の詳細な構造を示す図である。

取得済み情報２０３は、図７に示されるように取得日時７０１、車両番号７０２、取得データ項目７０３、取得データ値７０４の項目から構成される。車両番号７０２は、車両を一意に識別するためのものである。この車両番号７０２は、車両情報２３５の車両番号６０１と同じである。取得データ項目７０３は、データの名前、取得データ値７０４は、取得データ項目７０３の値を示すものである。取得日時７０１は、情報取得部２０２が情報を取得した日時ではなく、取得データ値７０４が車両１１５内で取得された日時を示している。

図８は、提供履歴２１３の詳細な構造を示す図である。

提供履歴２１３は、図８に示されるように提供日時８０１、利用者８０２、提供データ８０３、データ範囲８０４の項目から構成される。提供日時８０１は、情報提供部２１１が情報取得部２０２に対してデータを提供した日時を示している。利用者８０２は、情報を提供した人、提供データ８０３は、提供したデータ項目を示している。データ範囲８０４は、データの一部分を提供する場合に使用した条件を示している。例えば、提供データ８０３は、会員情報の年齢と性別、データ範囲は会員ＩＤが１から５まで（５人分）などである。

図９は、公開パターン２１６の詳細な構造を示す図である。

公開パターン２１６は、図９に示されるようにパターン名９０１、公開データ項目９０２、公開範囲９０３の項目から構成される。パターン名９０１は、パターンの名前であり、公開データ項目９０２と公開範囲９０３の組合せのパターンを明示する名称である。また、運転手１１６に対して公開要求を表示する場合に、車載端末１１７の画面にパターン名９０１が表示される。公開データ項目９０２は、公開するデータ項目を示しており、「全項目」や「位置」などが指定されている。公開範囲９０３は、データを公開する対象の範囲を示すものである。例えば、「取得日時の曜日が土日」、「自宅から１０ｋｍ以内」などが指定されている。この公開パターンは、予めパターンを定義しておくことによって、利用者が公開する際に、一つ一つの項目に対して公開を設定する必要がなく、簡単に公開を可能にするために用いる。

図１０は、車両情報２５５の詳細な構造を示す図である。

車両情報２５５は、図１０に示されるように取得日時１００１、データ名１００２、データ値１００３の項目から構成される。車両情報２３５と同様で、取得日時１００１は、データを取得した日時、データ名１００２は、データの名前、データ値１００３は、データ名１００２の値を示すものである。車内ネットワーク１１９を介してＥＣＵ１２０，１２１から車両情報を取得して蓄積される。

図１１は、加工履歴２３３の詳細な構造を示す図である。

加工履歴２３３は、図１１に示されるようにダミー車両番号１２０１とオリジナル車両番号１２０２、取得日時１２０３、データ名１２０４の項目から構成される。ダミー車両番号１２０１は、名寄せできないように車両番号をダミーに加工した値であり、オリジナル車両番号１２０２は、加工する前の元の車両番号を示している。取得日時１２０３は、車両情報を取得した日時で、データ名１２０４は、車両情報の項目を示している。車両番号１２０２、取得日時１２０３、データ名１２０４によりデータを一意に特定することが可能である。

次に、図１２ないし図２０を用いて本発明に係る情報仲介システムの動作について説明する。
先ず、図１２を用いて情報取得部２０２からの情報取得要求に対して、情報提供部２１１が応答を返す処理について説明する。
図１２は、情報取得部２０２からの情報取得要求に対して、情報提供部２１１が応答を返す処理のフローチャートである。

先ず、仲介サーバ１０５の情報提供部２１１は、利用者端末１０２の情報取得部２０２からの情報取得要求を受信する（ステップ１１０１）。ここでは、情報取得部２０２から情報提供部２１１に対して、ユーザＩＤとパスワード、取得したいデータ項目（車両番号などの条件指定も含む）が指定される。次に、利用者が正規の利用者か否かを確認するための認証をおこなう（ステップ１１０２）。認証処理では、先ず、情報提供部２１１から認証部２４１に対して、ユーザＩＤとパスワードを送信する。認証部２４１では、利用者情報２４２を参照し、指定されたユーザＩＤとパスワードの組合せが登録されているか否かを確認する。登録されていれば認証成功を、登録されていなければ認証失敗の結果を情報提供部２１１に応答する。認証成功の場合にはステップ１１０３に、認証失敗の場合には情報取得部２０２に対して失敗を通知して終了する。

次に、指定されたデータ項目の公開条件を確認する（ステップ１１０３）。情報提供部２１１は、認証部２４１を介して、公開条件管理部２４３に取得要求のデータ項目を送信する。公開条件管理部２４３では、図４に示した公開条件２４４を参照して該当するデータ項目を検索し、公開制限４０３の条件を利用者が満たしているか否かを判別する。なお、利用者の属性情報は、利用者情報２４２を参照する。公開制限を満たしているか否かの結果と、データ項目毎に設定されている公開範囲を情報提供部２１１に送信する。公開が許可されている場合には、ステップ１１０４に進む。

次に、公開が許可されている場合には、情報提供部２１１は、指定された情報を収集する（ステップ１１０４）。すなわち、会員管理部２２１を介して会員情報２２２を収集し、車両情報管理部２３２を介して車両情報部２３５を収集する。

一方、公開条件に合致しないときにはステップ１１０６に進む。本実施形態では、利用者が公開条件に合致せず、その利用者に公開してはいけないときには、個人が特定できる形では情報提供はできないが、情報を匿名化した形では情報提供ができるものとする。すなわち、車両情報２３５の場合なら、ほとんどの場合は車両情報単体では個人を特定することはできないため、公開条件に合致しなくても提供できるものとする。ただし、会員情報２２２と車両情報２３５で名寄せすることによって個人を特定可能になってしまうため、会員情報２２２と車両情報２３５の組合せは、そのままでは提供することができない。すなわち、その利用者に対して公開していけないときには、名寄せができないように情報を加工しなければならない。

このような理由から、公開条件に合致しないときには、名寄せするためのキーの判別をおこなう（ステップ１１０６）。例えば、会員情報２２２と車両情報２３５の場合には、車両番号で名寄せが可能である。

次に、車両情報管理部２３２における車両情報２３５の加工方法を決定する（ステップ１１０７）。すなわち、ステップ１１０６で求めた名寄せキーの値をダミー情報に書き換えることで、会員情報２２２と車両情報２３５の名寄せを不可能にする。例えば、図５に示す会員情報２２２では会員ＩＤが「１」の車両番号は「１０１」になっている。そのため、車両情報２３５の車両番号の値である「１０１」を「Ｇ７Ｅ８Ｊ１Ｏ６」という形に変換することで、会員情報２２２との名寄せはできなくなる。また、ダミー情報は利用者には意味のない値であるため、利用者がダミー車両番号から元の車両番号に戻すことはできない。車両番号をダミー車両情報に書き換えるルールは、ランダムな変数を用いて変換してもよいし、時刻情報を用いて変換してもよいし、内部的な通し番号を用いて変換してもよいし、データ項目を用いて変換してもよい。また、ダミー情報に書き換えるルールを、日付毎、曜日毎または一定時間毎に変更してもよい。

そして、ステップ１１０７の加工ルールに従って名寄せキーを加工する（ステップ１１０８）。最後に、図１１に示したような加工履歴２３３を蓄積し(ステップ１１０９)、収集した情報を情報取得部２０２に応答して終了する(ステップ１１０５)。

上記の処理では名寄せできないように加工して提供するとしたが、図８に示した提供履歴２１３から名寄せできる可能性のある情報の場合には、提供しないようにする方法も考えうる。

すなわち、ある利用者が過去、ある会員の車両番号５０２を含む会員情報２２２を取得したことが、提供履歴２１３に記録されており、その利用者に対してその会員の車両情報２３５を公開していけないときには、車両番号は、ダミー情報に置き換えて提供される。

次に、図１３を用いて名寄せ防止のための加工処理について説明する。
図１３は、名寄せ防止のための加工処理のフローチャートである。

名寄せのパターンは２種類に大別される。カラムで名寄せする場合と、レコードで名寄せする場合である。

カラムで名寄せする場合は、Ａテーブルの項目ＸとＢテーブルの項目Ｘを名寄せするパターンである。例えば、会員情報と車両情報を車両番号で名寄せする場合がこれに当たる。

一方、レコードで名寄せする場合は、Ａテーブルのレコード１とＡテーブルのレコード２を名寄せするパターンである。例えば、経路情報の出発地点情報、中間地点情報、到着地点情報を名寄せして一つの経路情報にするのがこれに当たる。加工処理の入力としては、二つのテーブルのレコード群が与えられる。先ず初めに、カラムでの名寄せが可能か否かを確認する(ステップ１９０１)。すなわち、指定された二つのテーブルの中に同一名のカラムがあるか否かを探す。もしある場合には、カラムでの名寄せが可能であり、ステップ１９０２に進む。ない場合には、カラムでの名寄せが不可能であり、ステップ１９０３に進む。ここで、カラム名変換辞書を用いて、異なるカラム名でも同一のものであると判断してもよい。同義語辞書を用いて、表現の異なるカラム名を同一のものであると判断してもよい。例えば、同義語としては「コンピューター」、「コンピュータ」、「計算機」などが挙げられる。そして、それぞれのテーブルの名寄せ項目を加工して(ステップ１９０２)、終了する。

カラムでの名寄せが不可能なときには、レコードの名寄せが可能か否かを確認する(ステップ１９０３)。レコードで名寄せできるデータ項目は別途定義されているものとする。例えば、経路情報の場合では、「位置」が対象となる。なお、詳細な経路情報の加工例については次に説明する。ここでは、指定されたレコード群を探索し、同一車両の同一データ項目の中で、レコードの名寄せ対象となるものがあるか否かを調べる。ある場合には、レコードでの名寄せが可能であり、ステップ１９０４に進む。ない場合には、レコードでの名寄せが不可能であり、加工をする必要がない（もともと名寄せできない）ため、加工処理を終了する。

レコードでの名寄せが可能なときには、レコードでの名寄せができなように、それぞれのレコードの名寄せ項目を別々の値に加工して終了する(ステップ１９０４)。

次に、図１４を用いてレコードでの名寄せが可能なときの加工処理の一例として、経路情報の加工処理について説明する。
図１４は、経路情報の加工処理を示す図である。

通常は、車両情報は単体では個人を特定することはできない。しかし、物流トラックの場合、物流トラックは毎日同じ経路を通ることがあるため、複数日の経路情報を組合せることで個人が特定される危険性がある。そのため、経路情報の場合には、経路を３分割（出発部分、中間部分、到着部分）し、別々のルールを用いてダミー車両番号に変換するものとする。例えば、図１４に示されるように、同じ日の経路情報でも、出発部分は車両番号１００をダミー車両番号Ａ１に加工し、中間部分をダミー車両番号Ａ２に加工し、到着部分をダミー車両番号Ａ３に加工する。こうすることで、利用者にはＡ１、Ａ２、Ａ３の車両が同一のものであるという判別はできない。また、日付毎でも別々のルールを用いてダミー車両番号に変換することで個人の特定を防ぐ。例えば、ある日の経路情報の出発部分、中間部分、到着部分をダミー車両番号Ａ１、Ａ２、Ａ３に加工し、次の日の経路情報はＢ１、Ｂ２、Ｂ３に加工するなどである。

次に、図１５を用いて情報取得部２０２からの要求に対して、情報提供部２１１が関係情報を返す処理について説明する。
図１５は、情報取得部２０２からの要求に対して、情報提供部２１１が関係情報を返す処理のフローチャートである。

先ず、仲介サーバ１０５の情報提供部２１１は、利用者端末１０２の情報取得部２０２からの関係情報の取得要求を受信する(ステップ１３０１)。このとき、情報取得部２０２からは、ユーザＩＤとパスワード、ダミー車両番号が指定される。情報提供部２１１は、指定されたダミー車両番号の関係情報を応答する。

次に、利用者が正規の利用者か否かを確認するために認証をおこなう(ステップ１３０２)。認証処理としては、先ず、情報提供部２１１から認証部２４１に対して、ユーザＩＤとパスワードを送信する。認証部２４１では、利用者情報２４２を参照し、指定されたユーザＩＤとパスワードの組合せが登録されているか否かを確認する。登録されていれば認証成功を、登録されていなければ認証失敗の結果を情報提供部２１１に応答する。認証成功の場合にはステップ１３０３に、認証失敗の場合には情報取得部２０２に対して失敗を通知して終了する。

次に、車両情報管理サーバ１０７の車両情報管理部２３２経由で、通知されたダミー車両番号からオリジナルの車両番号、取得日時、データ名を検索する(ステップ１３０３)。次に、車両番号、取得日時、データ名を公開条件管理部２４３に送信し、対象となる利用者に対して指定されたデータの公開が許可されているか否かを確認する(ステップ１３０４)。公開が許可されている場合にはステップ１３０５に進み、公開が許可されていない場合には情報取得部２０２に対して失敗を通知して終了する。

公開が許可されている場合には提供済みの情報を名寄せ可能にする関係情報を生成する(ステップ１３０５)。

関係情報生成部２３１では、加工履歴２３３を参照し、指定されたダミー車両番号に対応するオリジナル車両番号を検索する。「ダミー車両番号＝オリジナル車両番号」という関係情報を生成し、情報提供部２１１に送信する。例えば、ダミー車両番号「Ａ１Ｂ１Ｃ１Ｄ１」を検索すると、オリジナル車両番号は１００になるので、「Ａ１Ｂ１Ｃ１Ｄ１＝１００」という関係情報を生成して送信する。最後に、生成した関係情報を情報取得部２０２に応答する(ステップ１３０５)。

関係情報を利用する例は、後に詳細に具体例を示して説明する。

次に、図１６を用いて車載端末１１７と仲介サーバ１０５の間での車両情報収集の際にやり取りされるシーケンスについて説明する。
図１６は、車載端末１１７と仲介サーバ１０５の間での車両情報収集の処理のシーケンス図である。

車載端末１１７と仲介サーバ１０５は、常時接続しているわけではなく、運転手１１６のアクションによって、必要な時に接続される。そのため、車載端末では、車両情報を一定時間蓄積しておき、接続された際にまとめてアップロードする。先ず、車載端末１１７は、車両情報取得部２５６経由でＥＣＵの情報を取得する(ステップ１４１１)。車両情報収集の方法には、ＥＣＵからＰＵＳＨ配信で流れてくる情報を取得する方法と、ＥＣＵに問合せて取得する方法の二種類がある。

次に、車載端末１１７は、ステップ１４１１で取得した車両情報を車両情報蓄積部２５４経由で車両情報２５５に蓄積する(ステップ１４１２)。車載端末１１７内では、ステップ１４１１とステップ１４１２が繰り返し実行されている。

ここで、運転手１１６が接続ボタン押下などのアクションにより、仲介サーバ１０５との接続が開始される(ステップ１４１３)。この際に車載端末１１７を一意に識別可能なＩＤとパスワードを送信する。仲介サーバ１０５側では、ステップ１４０１にて、車載端末ＩＤとパスワードを基にして認証をおこない、認証成功の場合には成功を車載端末に応答し、認証失敗の場合には接続を切断する。

車載端末１１７側では、車載端末内に蓄積した車両情報をまとめてアップロードする（ステップ１４１４）。仲介サーバ１０５側では、ステップ１４０２で、車両情報収集部２１４にてアップロードされた車両情報を取得する。

そして、仲介サーバ１０５は、アップロードされた車両情報に車両番号を付加することで車両と特定できるようにしたうえで、車両情報蓄積部２３４経由で車両情報２３５に蓄積する（ステップ１４０３）。

次に、仲介サーバ１０５は、車載端末１１７に対して新しい車両情報収集設定を送信する（ステップ１４０４）。ここで、車両情報収集設定とは、車載端末内で収集する車両情報２３５の収集方法に関する設定情報である。どのデータをどういう周期で取得するのかが定義されている。車載端末１１７側では、送信された車両情報収集設定を設定し（ステップ１４１５）、仲介サーバ１０５との接続を完了する（ステップ１４１６）。車載端末内では、この新しい車両情報収集設定に基づいて車両情報２３５が蓄積される。

次に、図１７および図１８を用いて利用者１０１が運転手１１６に情報公開要求をおこなう処理について説明する。
図１７は、利用者１０１が運転手１１６に情報公開をおこなう処理のシーケンス図である。
図１８は、車載端末１１７の画面に表示する情報公開要求の画面例を示す図である。

先ず、利用者端末１０２から仲介サーバ１０５に対して接続要求を送信する（ステップ１５０１）。このとき、ユーザＩＤとパスワードが送られる。仲介サーバ１０５側では、送られたユーザＩＤとパスワードを基にして認証をおこなう（ステップ１５１１）。認証成功の場合には成功の応答を返し、認証失敗の場合には接続を切断する。

利用者端末１０２側では、情報公開要求部２０１から公開要求を送信する（ステップ１５０２）。このとき、利用者１０１は、既に車両情報管理サーバ１０７に蓄積されている過去情報の公開も要求することができる。そのため、情報公開要求では、公開を求める車両、データ項目、取得日時などを指定して公開要求を送る。車両の特定には、位置などの車両の属性に基づいた指定が可能である。例えば、神奈川県にいる車両などである。損保などのマーケティング分析をおこなう場合には、特定の顧客をターゲットにする必要があるため、こうした車両の特定が必須となる。車両、データ項目、取得日時などを指定する他に、取得済み情報２０３内のダミー車両番号を指定して、対応する車両情報を公開するよう要求を送ることも可能である。仲介サーバ１０５側では、公開要求を受信して接続を切断する（ステップ１５１２）。そして、車両情報公開管理部２１５にて、受信した公開要求に適した公開パターン２１６を選択する（ステップ１５１３）。例えば、経路情報の公開を要求している場合には、公開パターンとして、公開データ項目９０２が一致する「経路情報」、「経路情報（過去を含む）」、「経路情報（平日のみ）」、「経路情報（休日のみ）」などを選択する。これらの選択した公開パターンを車載端末１１７に送って利用する。一方、車載端末１１７側では、運転手１１６が接続ボタン押下などのアクションにより、仲介サーバ１０５との接続が開始される（ステップ１５２１）。この際に車載端末を一意に識別可能なＩＤとパスワードを送信する。仲介サーバ１０５側では、車載機ＩＤとパスワードをもとにして認証をおこない（ステップ１５１４）、認証成功の場合には成功を車載端末に応答し、認証失敗の場合には接続を切断する。ステップ１５０２で情報公開要求部２０１から受信した要求を車載端末１１７の情報公開設定部２５１に送る（ステップ１５１５）。車載端末１１７側では、車両状態管理部２５２で車両の状態を確認する。車両状態管理部２５２は、車両情報取得部２５６経由でＥＣＵの情報を取得することで車両の状態を判別できる。例えば、ＥＣＵから車速情報を取得することで、車が走っているのか、止まっているのかを判別することができる。車の走行中に画面に情報を表示することは安全上よくないため、車が走行状態の場合には、停車するまで処理を中断する。車が停車中の場合には車載端末１１７の画面に情報公開要求の情報を表示する（ステップ１５２３）。なお、車の状態としては走行中／停止中のほかに、エンジン始動、直進／カーブを走行中、前後の車との車間距離、同乗者が乗っているか否か、スピード、位置情報などを活用して定義することができる。

ここで、例えば、図１８に示されるような画面１６０１が表示される。画面１６０１には情報公開を要求している人の概略情報が表示されている。ここで、「詳細」ボタンを押下すると、より詳細な情報を閲覧することが可能である。「次へ」ボタンを押下すると、画面１６０２に遷移する。画面１６０２は公開する情報を選択する画面であり、画面には公開パターン名がボタン形式で表示されている。運転手１１６はこの中の一つを選択するだけで、複数項目の複雑な公開設定も簡単に設定することが可能である。もちろん、項目を一つ一つ詳細設定することも可能である。しかし、運転者１１６の多くは車に関しては素人の人が多く、複雑な情報設定をすることは困難であり、運転者１１６にも分かる言葉で公開パターンを設定し、その公開パターンで運転手１１６に公開の可否を選択させる方法が効率的である。

このように、運転手１１６は、表示された情報を見て公開するか否かの判断をし、ボタン押下などのアクションにより結果を選択する。そして、運転手１１６によって選択された結果が仲介サーバ１０５に送信される（ステップ１５２４）。

仲介サーバ１０５側では、結果を受信して接続を切断する（ステップ１５１６）。そして、仲介サーバ１０５側では、結果に基づいて公開条件２４４を設定／修正し（ステップ１５１７）、結果を利用者１０１に応答する（ステップ１５１８）。

次に、図１９および図２０を用いて損保がマーケティング分析および顧客に対してサービス開始をするときの処理について説明する。
図１９は、損保がマーケティング分析および顧客に対してサービス開始をするときの処理を示すフローチャートである。
図２０は、利用者端末１０２に表示される顧客から情報提供された情報を表示する例を示す図である。

先ず初めに、新規の保険メニュー作成のために、カーメーカに対して車両情報および会員情報の提供を要求する（ステップ１８０１）。ここで、既にカーメーカと損保の間では、情報提供の契約が結ばれているものとする。しかし、個人情報保護法のため、個人が特定できる形では情報提供ができないため、情報を加工して名寄せできないように匿名化してから損保に提供する。損保では匿名化された情報から新しい保険を企画する（ステップ１８０２）。例えば、収集した情報を分析し、年齢や性別の割合を調べ、走行距離はどれぐらいが多いのか、目的地や経由地はどこを設定している人が多いのか、エンジンの状態、アクセルの開け方、ブレーキの踏み方などを統計して分析する。匿名化された情報を分析することで、マーケットニーズがあるか否かが判別でき、新規保険メニューが企画できたら、対象となる顧客に情報公開をお願いする（ステップ１８０３）。このとき、損保は個人を特定できているわけではなく、「この車両情報が得られた車両に乗っているお客様」という形でしか知ることはできていない。特定の車両情報を指定し、それに対応する会員情報の公開を要求することになる。ここで、従来手法の場合だと、全員で公開要求を出すしか方法がなく、非常に非効率である。新規サービスの対象者であることが分かっていれば、情報公開に対する謝礼金を上げるなど、より効果的な情報公開の行動をすることが可能となる。顧客の許可が得られた場合、カーメーカから関係情報が送信される。損保では送られてきた関係情報を活用して、すぐに個人を特定することができる。従来手法の場合、車両情報は日々変化してしまっているため、１８０２で分析した時の車両情報との対応付けを取ることができず、結局の所、一から分析をし直さなければならなくなってしまう。しかし、本発明では、分析した時の情報の匿名化を解除できるため、素早く業務を進めることが可能となる。そのため、すぐにサービスの勧誘をおこなうことができ（ステップ１８０４）、サービス開始（ステップ１８０５）につなげることが可能となる。また、従来は、顧客に許可を得てから、分析に必要な情報を収集し始めるため、情報を集めるのに時間がかかってしまうという問題があった。しかしながら、本発明では、カーメーカが定期的に車両情報を収集し、既に収集済みの車両情報も含めて収集することができるため、分析のための情報収集の時間短縮をおこなうことが可能である。

利用者端末１０２には、利用者１０１への車両情報の公開が制限されているときには、図２０（ａ）に示されているように、車両番号がダミー情報として表示され名寄せできないようにして表示される。そして、公開が許されてときには、関係情報により、名寄せして、利用者端末１０２には、図２０（ｂ）のような形式で表示することができる。

本発明の一実施形態に係る情報仲介システムのシステム概要図である。 本発明の一実施形態に係る情報仲介システムの機能構成図である。 利用者情報２４２の詳細な構造を示す図である。 公開条件２４４の詳細な構造を示す図である。 会員情報２２２の詳細な構造を示す図である。 車両情報２３５の詳細な構造を示す図である。 取得済み情報２０３の詳細な構造を示す図である。 提供履歴２１３の詳細な構造を示す図である。 公開パターン２１６の詳細な構造を示す図である。 車両情報２５５の詳細な構造を示す図である。 加工履歴２３３の詳細な構造を示す図である。 情報取得部２０２からの情報取得要求に対して、情報提供部２１１が応答を返す処理のフローチャートである。 名寄せ防止のための加工処理のフローチャートである。 経路情報の加工処理を示す図である。 情報取得部２０２からの要求に対して、情報提供部２１１が関係情報を返す処理のフローチャートである。 車載端末１１７と仲介サーバ１０５の間での車両情報収集の処理のシーケンス図である。 利用者１０１が運転手１１６に情報公開をおこなう処理のシーケンス図である。 車載端末１１７の画面に表示する情報公開要求の画面例を示す図である。 損保がマーケティング分析および顧客に対してサービス開始をするときの処理を示すフローチャートである。 利用者端末１０２に表示される顧客から情報提供された情報を表示する例を示す図である。

符号の説明

利用者端末１０２、情報公開要求部２０１、情報取得部２０２、取得済み情報２０３、仲介サーバ１０５、情報提供部２１１、提供履歴管理部２１２、提供履歴２１３、車両情報収集部２１４、情報公開管理部２１５、公開パターン２１６、会員管理サーバ１０９、会員管理部２２１、会員情報２２２、車両情報管理サーバ１０７、関係情報生成部２３１、車両情報管理部２３２、加工履歴２３３、車両情報蓄積部２３４、車両情報２３５、認証サーバ１１１、認証部２４１、利用者情報２４２、公開条件管理部２４３、公開条件２４４、車載端末１１７、情報公開設定部２５１、車両状態管理部２５２、車両情報提供部２５３、車両情報蓄積部２５４、車両情報２５５、車両情報取得部２５６。

Claims (10)

1. 利用者端末と情報提供者端末と仲介サーバとを有し、前記利用者端末と前記情報提供者端末とが前記仲介サーバにネットワークにより接続され、前記情報提供者端末から前記利用者端末に前記仲介サーバを介して情報提供者の提供情報を送信する情報仲介システムにおいて、
   前記仲介サーバは、
   前記情報提供者端末から情報提供者の提供情報を収集して蓄積する手段と、
   前記情報提供者の属性情報を蓄積する手段と、
   前記情報提供者の提供情報の各項目と前記情報提供者の属性情報の各項目との組合せに対し、前記利用者への公開条件の定義情報を保持する手段と、
   前記公開条件の定義情報に基づき、前記情報提供者の提供情報と属性情報の組合せを公開できない場合に、前記提供情報と属性情報を名寄せするためのデータをダミー情報に書き換えてから前記利用者端末に送信する手段と、
   前記公開条件が前記情報提供者端末からの操作によって公開許可の設定に変更された場合に、前記ダミー情報に書き換えて送信した利用者端末に対して、前記提供情報と属性情報を名寄せするための関係情報のみを提供することを特徴とする情報仲介システム。
2. 前記仲介サーバによる、情報提供者の提供情報と前記情報提供者の属性情報とを名寄せするためのデータをダミー情報に書き換える手段を、日付毎、曜日毎または一定時間毎に、変更することを特徴とする請求項１記載の情報仲介システム。
3. 前記仲介サーバは、少なくとも、利用者が所属する会社、業種、部署や情報の利用方法を含む利用者属性に対応付けて、前記利用者への公開条件の定義情報を管理することを特徴とする請求項１記載の情報仲介システム。
4. 前記仲介サーバは、利用者端末に提供した情報の情報提供履歴を保持し、
   前記情報提供履歴に基づき、
   情報提供者の提供情報と属性情報とを名寄せするためのデータをダミー情報に置き換えるか否かを決定することを特徴とする請求項１記載の情報仲介システム。
5. 前記情報提供者端末が車載端末であって、車両の経路情報の提供に関して、経路情報を出発部分、中間部分、到着部分に分割し、それぞれ異なるダミー情報に書き換えることを特徴とする請求項１記載の情報仲介システム。
6. 前記情報提供者端末が車載端末であって、
   前記利用者端末から前記仲介サーバを介して前記情報提供者端末に、前記情報提供者の提供情報と前記情報提供者の属性情報との公開を要求する手段とを有し、
   前記利用者端末から前記仲介サーバを介して前記情報提供者端末に、前記情報提供者の提供情報と前記情報提供者の属性情報との公開を要求されたときに、
   蓄積された情報提供者の提供情報、既に利用者に提供済みの提供情報、今後に発生する提供情報のいずれか、または、それらを組合せて提供情報を公開するか否かの別、
   日付・曜日・時刻を含む時間属性、
   エンジン回転数、経路、位置情報を含む車載端末を載せる自動車の情報項目に対応付けて、前記仲介サーバが、前記利用者への公開条件を管理できることを特徴とする請求項１記載の情報仲介システム。
7. 前記仲介サーバが、前記利用者に公開する範囲を予めパターンとして登録しておき、前記利用者端末から指定されたパターン名に基づいて、公開する範囲を設定することを特徴とする請求項６記載の情報仲介システム。
8. 前記車載端末を載せる自動車の走行中/アイドリング/エンジン停止や位置を含む車両状態に応じて、前記利用者端末から前記仲介サーバを介して前記情報提供者端末に、前記情報提供者の提供情報と前記情報提供者の属性情報との公開を要求されたときに、前記車載端末の画面に前記利用者からの情報公開要求を表示するか否かを変更することを特徴とする請求項６記載の情報仲介システム。
9. 利用者端末と情報提供者端末とを有し、前記情報提供者端末から前記利用者端末に情報提供者の提供情報を提供する情報仲介システムの仲介サーバにおいて、
   前記利用者端末と前記情報提供者端末とにネットワークにより接続され、
   前記情報提供者端末から情報提供者の提供情報を収集する手段と、
   前記情報提供者の提供情報を提供情報管理サーバに送信する手段と、
   前記情報提供者の提供情報を前記提供情報管理サーバから受信する手段と、
   情報提供者管理サーバから前記情報提供者の属性情報を受信する手段と、
   利用者管理サーバから前記情報提供者の提供情報の各項目と前記情報提供者の属性情報の各項目との組合せに対して定義された前記利用者への公開条件の定義情報を受信する手段と、
   前記公開条件の定義情報に基づき、前記情報提供者の提供情報と属性情報の組合せを公開できない場合に、前記提供情報と属性情報を名寄せするためのデータをダミー情報に書き換えてから前記利用者端末に送信する手段とを有し、
   前記公開条件が前記情報提供者端末からの操作によって公開許可の設定に変更された場合に、前記ダミー情報に書き換えて送信した利用者端末に対して、前記提供情報と属性情報を名寄せするための関係情報のみを提供することを特徴とする仲介サーバ。
10. 利用者端末と情報提供者端末と仲介サーバとを有し、前記利用者端末と前記情報提供者端末とが前記仲介サーバにネットワークにより接続され、前記情報提供者端末から前記利用者端末に前記仲介サーバを介して情報提供者の提供情報を送信する情報仲介システムの情報仲介方法であって、
    前記仲介サーバが、前記情報提供者端末から情報提供者の提供情報を収集するステップと、
    前記仲介サーバが、前記情報提供者端末から情報提供者の提供情報を蓄積するステップと、
    前記仲介サーバが、前記情報提供者の属性情報を蓄積するステップと、
    前記仲介サーバが、前記情報提供者の提供情報の各項目と前記情報提供者の属性情報の各項目との組合せに対し、前記利用者への公開条件の定義情報を保持するステップと、
    前記仲介サーバが、前記公開条件の定義情報に基づき、前記情報提供者の提供情報と属性情報の組合せを公開できない場合に、前記提供情報と属性情報を名寄せするためのデータをダミー情報に書き換えてから前記利用者端末に送信するステップと、
    前記仲介サーバが、前記公開条件が前記情報提供者端末からの操作によって公開許可の設定に変更された場合に、前記ダミー情報に書き換えて送信した利用者端末に対して、前記提供情報と属性情報を名寄せするための関係情報のみを提供するステップとを有することを特徴とする情報仲介方法。

Images