情報処理装置および方法、並びにプログラム

【課題】バイラルマーティングを行うにあたり、有益な情報を簡単に取得することができるようにする
【解決手段】サーバは、既に蓄積されている実績情報に基づいて、ユーザＵ１が過去３カ月以内にコンテンツを提供したユーザの一覧を生成して、ユーザＵ１についての所属グループが特定される。同様に、既に蓄積されている実績情報に基づいて、ユーザＵ２についての所属グループ（配信先グループと称することにする）を特定する。所属グループのユニークユーザ数と配信先グループのユニークユーザ数とを合計し、コネクタとなるユーザの評価値が算出される。

【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置および方法、並びにプログラムに関し、特に、コンテンツの配信サービスの付加価値をより高めることができるようにする情報処理装置および方法、並びにプログラムに関する。
【背景技術】
【０００２】
従来より、ネットワークを介したダウンロード方式によるコンテンツの配信サービスが盛んに行われている。このようなコンテンツの配信サービスにおいては、例えば、ユーザの携帯電話機などによりサーバからコンテンツをダウンロードするものの他、ユーザの携帯端末間でコンテンツの送受信を行うことができる場合もある。
【０００３】
また、インターネット上の掲示板などにおいていわゆる口コミ情報と称される情報が活用されている。口コミ情報は、例えば、店舗のサービス、商品の品質、コンテンツの面白さなどについての評価情報である。
【０００４】
口コミ情報は、雑誌記者や専門家によって記載された評価情報と異なり、実際に店舗に行った人、商品を買った人、コンテンツを視聴した人などによる生の声として有益であり、商品やサービスの購入にあたって参考にされることも多い。
【０００５】
また、視聴者の無線端末から視聴者の属性（ユーザ情報）を収集して視聴効果を測定する技術も提案されている（例えば、特許文献１参照）。このような技術により、より簡単に評価情報を収集することが可能となってきている。
【０００６】
【特許文献１】特開２０１０−４１１９４号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
ところで、コンテンツの配信サービスの普及に伴って、例えば、宣伝広告などを含んだコンテンツを無料で配信することなども行われるようになってきている。
【０００８】
このようにコンテンツの配信サービスの態様が多様化するのに伴い、単にユーザから対価の支払いを受けて所望のコンテンツをダウンロードさせるような従来のコンテンツ配信サービスとは異なる工夫が求められている。
【０００９】
例えば、配信するコンテンツの市場での評価を高めることなどに貢献したユーザなどには優先的にコンテンツを配信するなどの工夫をすれば、コンテンツの配信サービスの付加価値をより高めることも可能となる。
【００１０】
また、近年では、いわゆる口コミ情報を利用したマーケティングの手法として、例えば、バイラルマーケティングが注目されている。
【００１１】
バイラルマーティングでは、既存のユーザに自社のコンテンツやサービスなどを知人に紹介してもらえるよう働きかけ、既存のユーザを通して間接的に自社のコンテンツやサービスを宣伝する。このため、バイラルマーティングを行うにあたり、どのユーザに働きかければよいかなどの情報が極めて重要な情報とされている。
【００１２】
従来のインターネット上の掲示板などの口コミ情報では、例えば、企業が売り込もうとしているコンテンツやサービスなどをどのユーザに提供すれば効率的に紹介してもらえるかを、適確に分析することが難しかった。
【００１３】
本発明はこのような状況に鑑みてなされたものであり、バイラルマーティングを行うにあたり、有益な情報を簡単に取得することができるようにするものである。
【課題を解決するための手段】
【００１４】
本発明の一側面は、予め定められた一の電子情報財の提供者に係る端末機器による前記電子情報財の提供先を表す実績情報を取得する実績情報取得手段と、前記取得した実績情報に含まれる前記提供先を抽出し、前記抽出された提供先に対して前記提供先の属性に応じて予め定められた基準で重み付けする重み付け手段と、前記重み付けされた値に基づいて前記提供者の評価値を算出する評価値算出手段とを備える情報処理装置である。
【００１５】
前記電子情報財の提供者に係る端末機器である第１の端末機器は、第１の通信により前記電子情報財の提供先に係る第２の端末機器の識別情報および第２の通信のアドレスを含む情報を前記第２の端末機器から受信する機器情報受信手段と、前記第２の端末機器へ前記第２の通信を利用して前記電子情報財の送信を行う電子情報財送信手段とを備え、前記実績情報には、前記第１の通信を介して受信された情報に含まれる前記第２の端末機器のユーザの識別情報および属性情報が含まれるようにすることができる。
【００１６】
前記重み付け手段は、前記第２の端末機器が前記第２の通信を利用して受信した前記電子情報財に対する評価情報に基づいて、前記提供先に対する重み付けを行うようにすることができる。
【００１７】
前記重み付け手段は、前記提供先に提供された前記電子情報財の種類および前記電子情報財が提供された時刻の少なくとも一方に基づいて、前記提供先に対する重み付けを行うようにすることができる。
【００１８】
複数の前記実績情報に基づいて、前記評価値の演算の対象となる提供者に対して前記電子情報財を提供した前記端末機器のユーザを特定することで、前記提供者が属する所属グループを特定する所属グループ特定手段と、複数の前記実績情報に基づいて、前記評価値の演算の対象となる提供者が新たに前記電子情報財を提供した前記端末機器のユーザを特定することで、提供先グループを特定する提供先グループ特定手段とをさらに備え、前記所属グループ特定手段は、前記評価値の演算の対象となる提供者を第１次提供元ユーザとし、前記特定されたユーザを、第２次提供元ユーザとし、前記第２次提供元ユーザが過去に前記電子情報財の提供を受けたユーザを第３次提供元ユーザとして第１次乃至第ｎ次の提供元ユーザを特定し、提供先グループ特定手段は、前記特定されたユーザを、第１次提供先ユーザとし、前記第１次提供先ユーザが過去に前記電子情報財を提供したユーザを第２次提供先ユーザとして第１次乃至第ｎ次の提供先ユーザを特定するようにすることができる。
【００１９】
前記評価値演算手段は、前記特定された所属グループおよび前記提供先グループに属するユーザの中で重複しないユーザの数に基づいて前記評価値を演算するようにすることができる。
【００２０】
前記実績情報には、前記第１の通信を介して受信された情報に含まれる前記第２の端末のユーザ認証の方式および前記第２の端末のユーザ認証結果に係る情報がさらに含まれるようにすることができる。
【００２１】
前記第１の端末機器の識別情報および前記第２の端末機器の識別情報に基づいて、前記商品またはサービスの提供者の信頼性を表す信頼性区分、前記第１の端末機器のセキュリティ区分および前記第２の端末機器のセキュリティ区分を特定する区分特定手段と、前記特定結果に基づいて、前記第１の端末機器と前記第２の端末機器との間で行われる第２の通信が継続して行われていることを確認するリンク認証の方式を特定するとともに、その方式で前記リンク認証に係る処理を実行するリンク認証手段とをさらに備え、前記第２の端末のユーザ認証結果に係る情報には、前記リンク認証の結果が含まれるようにすることができる。
【００２２】
前記リンク認証手段は、前記特定結果に応じて、前記第２の端末に前記第３の通信を利用して送信した情報が、前記第２の通信を利用して前記第１の端末機器に送信されたか否かを表す情報を前記第１の端末機器から前記第３の通信を利用して受信することで、前記第２の端末機器の同一性を確認する評価者同一性確認処理と、前記第１の端末に前記第３の通信を利用して送信した情報が、前記第２の通信を利用して前記第２の端末機器に送信されたか否かを表す情報を前記第２の端末機器から前記第３の通信を利用して受信することで、前記第１の端末機器の同一性を確認する提供者同一性確認処理とを、それぞれ定期的に実行するようにすることができる。
【００２３】
前記リンク認証手段は、前記信頼性区分に基づいて、前記提供者同一性確認処理を実行するか否かを決定することで、前記リンク認証の方式を特定するようにすることができる。
【００２４】
前記リンク認証手段は、前記セキュリティ区分に基づいて、前記評価者同一性確認処理または前記提供者同一性確認処理において、前記第１の端末機器若しくは前記第２の端末機器が予め記憶している固有鍵を用いるか、または、前記第１の端末機器若しくは前記第２の端末機器が予め記憶していない一時キーを用いるかを決定することで、前記リンク認証の方式を特定するようにすることができる。
【００２５】
本発明の一側面は、実績情報取得手段が、予め定められた一の電子情報財の提供者に係る端末機器による前記電子情報財の提供先を表す実績情報を取得し、重み付け手段が、前記取得した実績情報に含まれる前記提供先を抽出し、前記抽出された提供先に対して前記提供先の属性に応じて予め定められた基準で重み付けし、評価値算出手段が、前記重み付けされた値に基づいて前記提供者の評価値を算出するステップを含む情報処理方法である。
【００２６】
本発明の一側面は、コンピュータを、予め定められた一の電子情報財の提供者に係る端末機器による前記電子情報財の提供先を表す実績情報を取得する実績情報取得手段と、前記取得した実績情報に含まれる前記提供先を抽出し、前記抽出された提供先に対して前記提供先の属性に応じて予め定められた基準で重み付けする重み付け手段と、前記重み付けされた値に基づいて前記提供者の評価値を算出する評価値算出手段とを備える情報処理装置として機能させるプログラムである。
【００２７】
本発明の一側面においては、予め定められた一の電子情報財の提供者に係る端末機器による前記電子情報財の提供先を表す実績情報が取得され、前記取得した実績情報に含まれる前記提供先が抽出され、前記抽出された提供先に対して前記提供先の属性に応じて予め定められた基準で重み付けされ、前記重み付けされた値に基づいて前記提供者の評価値が算出される。
【発明の効果】
【００２８】
本発明によれば、コンテンツの配信サービスの付加価値をより高めることができる。
【図面の簡単な説明】
【００２９】
【図１】本発明の一実施の形態に係る評価情報収集システムの構成例を示す図である。
【図２】本発明の一実施の形態に係る評価情報収集システムの別の構成例を示す図である。
【図３】携帯端末の構成例を示すブロック図である。
【図４】サーバの構成例を示すブロック図である。
【図５】端末機器情報の例を示す図である。
【図６】リンク認証を行って評価情報を収集する方式の例を説明する図である。
【図７】図６の方式における処理の流れを説明するアローチャートである。
【図８】リンク認証を行って評価情報を収集する方式の別の例を説明する図である。
【図９】図８の方式における処理の流れを説明するアローチャートである。
【図１０】リンク認証を行って評価情報を収集する方式のさらに別の例を説明する図である。
【図１１】図１０の方式における処理の流れを説明するアローチャートである。
【図１２】リンク認証を行って評価情報を収集する方式のさらに別の例を説明する図である。
【図１３】リンク認証を行って評価情報を収集する方式のさらに別の例を説明する図である。
【図１４】ハンドオーバメッセージを説明する図である。
【図１５】リンク認証の方式を特定するための情報を説明する図である。
【図１６】評価情報収集処理の例を説明するフローチャートである。
【図１７】ケース１処理の例を説明するフローチャートである。
【図１８】ケース２処理の例を説明するフローチャートである。
【図１９】ケース３処理の例を説明するフローチャートである。
【図２０】ケース３処理の例を説明するフローチャートである。
【図２１】ケース４処理の例を説明するフローチャートである。
【図２２】ケース４処理の例を説明するフローチャートである。
【図２３】ケース５処理の例を説明するフローチャートである。
【図２４】ケース５処理の例を説明するフローチャートである。
【図２５】提供者側端末機器の処理の例を説明するフローチャートである。
【図２６】コンテンツ提供処理の例を説明するフローチャートである。
【図２７】リンク認証処理の例を説明するフローチャートである。
【図２８】提供者側端末機器の処理の別の例を説明するフローチャートである。
【図２９】リンク認証処理の別の例を説明するフローチャートである。
【図３０】評価者側端末機器の処理の例を説明するフローチャートである。
【図３１】第１リンク認証処理の例を説明するフローチャートである。
【図３２】第２リンク認証処理の例を説明するフローチャートである。
【図３３】コンテンツ評価処理の例を説明するフローチャートである。
【図３４】評価者側端末機器の処理の別の例を説明するフローチャートである。
【図３５】第３リンク認証処理の例を説明するフローチャートである。
【図３６】第４リンク認証処理の例を説明するフローチャートである。
【図３７】本発明の一実施の形態に係るコンテンツ配信システムの構成例を示す図である。
【図３８】実績情報の例を示す図である。
【図３９】ハンドオーバメッセージの別の例を説明する図である。
【図４０】本発明の一実施の形態に係るコンテンツ配信システムの別の構成例を示す図である。
【図４１】実績情報における各携帯端末をノードとして作成されたネットワークマップの例を示す図である。
【図４２】コネクタとなるユーザを特定する方式を説明する図である。
【図４３】図３７の実施の形態におけるサーバの処理の例を説明するフローチャートである。
【図４４】図４０の実施の形態におけるサーバの処理の例を説明するフローチャートである。
【発明を実施するための形態】
【００３０】
以下、図面を参照して、本発明の実施の形態について説明する。
【００３１】
本発明においては、例えば、携帯端末のハンドオーバ機能を利用して評価情報を収集するようにする。
【００３２】
例えば、携帯電話機として構成される携帯端末がBluetooth（登録商標）やWiFi（登録商標）等の近距離無線通信手段を有する場合がある。その場合携帯電話同士が直接（ローカルで）通信可能することができる。さらに、携帯電話機が、非接触通信（ＮＦＣ（Near Field Communication））デバイスを有する場合、ユーザが携帯電話機同士を近接（または接触）させることにより、非接触通信デバイスによって接続認証が行われ、近距離無線通信が可能となるようにすることができる。このように、非接触通信デバイスによって接続認証が行われ、近距離無線通信が行われるようにする機能がハンドオーバと称される。
【００３３】
このようなハンドオーバ機能を利用することにより、ユーザは、携帯電話機同士をタッチするだけで、サービスの提供を受けたり、商品を購入したりすることが可能となる。例えば、商品としてコンテンツを購入する際に、ユーザは、携帯電話機同士をタッチするだけで、近距離無線通信によってコンテンツのデータを携帯端末にダウンロードすることが可能となる。
【００３４】
図１は、本発明の一実施の形態に係る評価情報収集システムの構成例を示す図である。同図の例では、評価情報収集システム１０がサーバ２１、情報収集端末３１乃至情報収集端末３３、および、携帯端末４１乃至携帯端末４３により構成されている。
【００３５】
サーバ２１は、例えば、評価情報収集事業者のデータセンタに設置され、情報収集端末３１乃至情報収集端末３３から送信される評価情報を取得し、取得した評価情報の保存、加工などの処理を行うようになされている。サーバ２１は、例えば、取得した評価情報を、評価の対象となった商品やサービスの種類毎に分類し、ネットワークを介してアクセスしてくるユーザに提供するなどの処理を行う。
【００３６】
情報収集端末３１乃至情報収集端末３３は、それぞれ携帯端末４１乃至携帯端末４３のハンドオーバ機能により通信する端末とされ、近距離無線通信手段と非接触通信デバイスを有する構成とされる。
【００３７】
例えば、情報収集端末３１は、楽曲のコンテンツの試聴サービスを提供する機器として構成される。情報収集端末３１は、例えば、ユーザが携帯端末４１を所定の領域にタッチさせるなどした場合、非接触通信の後、近距離無線通信によってコンテンツのデータの一部を送信して携帯端末４１にコンテンツをストリーミング再生させる。これにより、ユーザは、携帯端末４１に接続されたヘッドフォンなどを装着してコンテンツを試聴することが可能となる。
【００３８】
また、情報収集端末３２は、例えば、飲食店で利用されるＰＯＳ端末などの機器として構成される。情報収集端末３２は、例えば、ユーザが携帯端末４２を所定の領域にタッチさせるなどした場合、非接触通信の後、近距離無線通信によってメニューや注文フォーマットのＧＵＩデータなどを送信して携帯端末４２に表示させる。これにより、ユーザは、携帯端末４２から所望のメニューを注文したり、またアンケートに回答して優待ポイントを取得したりすることができる。
【００３９】
情報収集端末３３は、例えば、ショッピングモールやテーマパークなどの所定のエリアに設置された無線通信ハブなどの機器として構成される。情報収集端末３３は、例えば、ユーザが携帯端末４３を所定の領域にタッチさせるなどした場合、非接触通信の後、近距離無線通信によってゲームのコンテンツのデータを送信する。これにより、ユーザは、携帯端末４３においてゲームを楽しむことが可能となる。
【００４０】
情報収集端末３１乃至情報収集端末３３のそれぞれは、近距離無線通信手段と非接触通信デバイスとは別に、サーバ２１との通信を行うための広域通信手段を有している。広域通信手段としては、例えば、最寄りの無線基地局と無線通信を行い、移動体通信網を介した通信を行う無線通信デバイスなどとされる。あるいはまた、専用線によってサーバ２１と接続される構成としてもよい。
【００４１】
携帯端末４１と携帯端末４２は、例えば、携帯電話機として構成され、携帯端末４３は、例えば、ゲーム機として構成される。携帯端末４１乃至携帯端末４３は、それぞれハンドオーバ機能により通信する端末とされ、近距離無線通信手段と非接触通信デバイスを有する構成とされる。また、これらとは別に、例えば、最寄りの無線基地局と無線通信を行い、移動体通信網を介した通信を行う無線通信デバイスを有している。
【００４２】
図１の例では、例えば、情報収集端末３１に蓄積された情報であって、各コンテンツの再生指令の回数、非接触通信によって取得された携帯端末４１のユーザの属性情報などが評価情報としてサーバ２１に送信される。
【００４３】
また、例えば、情報収集端末３２に蓄積された情報であって、メニュー毎の注文回数、アンケートの回答などが評価情報としてサーバ２１に送信される。
【００４４】
さらに、例えば、情報収集端末３３に蓄積された情報であって、ゲームの操作情報などが評価情報としてサーバ２１に送信される。
【００４５】
なお上述したように、情報収集端末３１乃至情報収集端末３３からサーバ２１への評価情報の送信には、広域通信手段が用いられる。
【００４６】
図２は、本発明の一実施の形態に係る評価情報収集システムの別の構成例を示す図である。同図の例では、評価情報収集システム１０がサーバ２１、および、携帯端末４４乃至携帯端末４７により構成されている。
【００４７】
携帯端末４４乃至携帯端末４７は、それぞれ図１の携帯端末４１と携帯端末４２と同様に、携帯電話機として構成される。図２の例の場合、携帯端末４５のユーザと携帯端末４７のユーザがそれぞれコンテンツの提供者となり、携帯端末４４のユーザと携帯端末４６のユーザがそれぞれコンテンツの評価者となる。
【００４８】
図２の例において、サーバ２１は、やはり評価情報収集事業者のデータセンタなどに設置され、携帯端末４５と携帯端末４７から送信される評価情報を取得し、取得した評価情報の保存、加工などの処理を行うようになされている。
【００４９】
例えば、携帯端末４５のユーザが、友人に薦めたい楽曲のコンテンツのデータを携帯端末４５にダウンロードしたものとする。携帯端末４４と携帯端末４５をタッチさせるなどした場合、非接触通信の後、近距離無線通信によって携帯端末４５からコンテンツのデータを送信して携帯端末４４にコンテンツをストリーミング再生させる。これにより、携帯端末４４のユーザはヘッドフォンなどを装着してコンテンツを試聴することが可能となる。そして、携帯端末４４のユーザは、近距離無線通信によって楽曲の評価（例えば、簡単なコメントなど）を携帯端末４５に送信する。
【００５０】
また、例えば、携帯端末４７のユーザが、ネットワークゲームを楽しんでおり、携帯端末４６のユーザである友人もこのネットワークゲームに参加させたいと考えていたとする。携帯端末４６と携帯端末４７をタッチさせるなどした場合、非接触通信の後、近距離無線通信によって携帯端末４７からゲームのデータを送信して携帯端末４６にゲームの画面などを表示させる。
【００５１】
これにより、携帯端末４６のユーザは、携帯端末４７のユーザが楽しんでいるネットワークゲームに参加することが可能となる。そして、近距離無線通信によって携帯端末４６からユーザのプロフィールなどの情報やゲームの操作情報などが携帯端末４７に送信される。
【００５２】
図２の例の場合、例えば、携帯端末４５に蓄積された情報であって、楽曲に対するコメントなどが評価情報としてサーバ２１に送信される。
【００５３】
また、例えば、携帯端末４７に蓄積された情報であって、ゲームの操作情報などが評価情報としてサーバ２１に送信される。
【００５４】
なお、携帯端末４５および携帯端末４７からサーバ２１への評価情報の送信には、広域通信手段が用いられる。
【００５５】
このように、本発明の評価情報収集システム１０においては、収集される評価情報がユーザコメント方式などに偏ったものとならず、例えば、各コンテンツについてのユーザの視聴実績などの情報も評価情報として収集することができる。
【００５６】
図３は、図１または図２の携帯端末の構成例を示すブロック図である。同図は、携帯端末４１の構成とされているが、同図の構成を携帯端末４２乃至携帯端末４７に適用することも可能である。
【００５７】
図３において、携帯端末４１のＣＰＵ（Central Processing Unit）１１１は、ＲＯＭ（Read Only Memory）１１２に記憶されているプログラム、または記憶部１２３からＲＡＭ（Random Access Memory）１１３にロードされたプログラムに従って各種の処理を実行する。ＲＡＭ１１３にはまた、ＣＰＵ１１１が各種の処理を実行する上において必要なデータなども適宜記憶される。
【００５８】
ＣＰＵ１１１、ＲＯＭ１１２、およびＲＡＭ１１３は、バス１１４を介して相互に接続されている。このバス１１４にはまた、入出力インタフェース１２０も接続されている。
【００５９】
入出力インタフェース１２０には、キーボード、マウスなどよりなる入力部１２１、ＬＣＤ（Liquid Crystal Display）などよりなるディスプレイ、並びにスピーカなどよりなる出力部１２２、および、ハードディスクやフラッシュメモリなどより構成される記憶部１２３が接続されている。
【００６０】
入出力インタフェース１２０にはまた、必要に応じてドライブ１２５が接続され、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリなどのリムーバブルメディア１２６が適宜装着され、それらから読み出されたコンピュータプログラムが、必要に応じて記憶部１２３にインストールされる。
【００６１】
入出力インタフェース１２０にはさらに、移動体通信網用無線通信部１３１、近距離無線通信部１３２、および非接触通信部１３３が接続されている。
【００６２】
移動体通信網用無線通信部１３１は、図示せぬ無線基地局と無線通信を行い、移動体通信網を介した通信を行う無線通信デバイスである。移動体通信網用無線通信部１３１は、例えば２GHzの周波数帯を使い、通話アプリケーションだけでなく、最大２Mbpsのデータ通信を用いてインターネット接続など各種通信アプリケーションに利用される。例えば、移動体通信網用無線通信部１３１による無線通信は、コンテンツデータのダウンロードやサーバ２１との通信等に用いられる。なお、移動体通信網用無線通信部１３１は、例えば、いわゆる第３世代携帯電話の通信方式による通信が可能なデバイスなどとして構成されることが想定されている。
【００６３】
近距離無線通信部１３２は、例えば、Bluetooth（登録商標、ＢＴとも称する）やIEEE（Institute of Electrical and Electronic Engineers）802.11x等の近距離無線通信デバイスである。ここで、近距離無線通信とは、通信可能最大距離が数メートル乃至数十メートル程度のローカルな（狭域の）無線通信を意味する。通信規格は任意である。例えば、近距離無線通信部１３２がＢＴの通信を行うものである場合は、アンテナを経由して2.4GHz帯にて最大通信速度３Ｍビット／秒（バージョン2.0＋EDR以降）の通信を行う。
【００６４】
非接触通信部１３３は、NFC（Near Field Communication）デバイスである。ここで非接触通信とは、通信可能最大距離が数十センチ程度のローカルな（狭域の）無線通信を示す。通信規格は任意である。例えば、非接触通信部１３３は、アンテナを経由して13.56MHz帯の周波数を使い、10cm程度の極近距離で最大424Kビット／秒の通信レートにて通信を行う。
【００６５】
非接触通信部１３３による非接触通信は、筐体を接触若しくは近接された携帯端末に対して、近距離無線通信部１３２による近距離無線通信接続の確立に必要な情報や、送信可能なコンテンツのリスト等が記述されたメッセージの授受に利用される。
【００６６】
携帯端末４１の各部は、ＣＰＵ１１１により制御される。制御プログラムの実行バイナリコードはＲＯＭ１１２や記憶部１２３に保存されており、各種演算処理のためスタック、ヒープ領域はＲＡＭ１１３上に展開される。
【００６７】
なお、情報収集端末３１乃至情報収集端末３３も、図３の例と同様に構成されるので、詳細な説明は省略する。
【００６８】
図４は、図１または図２のサーバの構成例を示すブロック図である。
【００６９】
同図に示されるように、サーバ２１は、携帯端末４１の場合と同様に、バス２０４を介して互いに接続されるＣＰＵ２０１、ＲＯＭ２０２、およびＲＡＭ２０３を有する。また、バス２０４には、入出力インタフェース２１０が接続される。
【００７０】
この入出力インタフェース２１０には、携帯端末４１の場合と同様に、入力部２１１、出力部２１２、記憶部２１３、およびリムーバブルメディア２１６用のドライブ２１５が接続される。
【００７１】
図４のＣＰＵ２０１、ＲＯＭ２０２、ＲＡＭ２０３、バス２０４、入出力インタフェース２１０、入力部２１１、出力部２１２、記憶部２１３、ドライブ２１５、およびリムーバブルメディア２１６は、それぞれ、図２のＣＰＵ１１１、ＲＯＭ１１２、ＲＡＭ１１３、バス１１４、入出力インタフェース１２０、入力部１２１、出力部１２２、記憶部１２３、ドライブ１２５、およびリムーバブルメディア１２６に対応する。
【００７２】
サーバ２１は、また、入出力インタフェース２１０に接続される通信部２１４を有する。この通信部２１４は、ネットワークを介して他の装置と通信を行う通信デバイスである。例えば、通信部２１４は、有線のネットワークを介して移動体通信網に接続され、携帯端末や情報収集端末との通信に利用される。
【００７３】
入出力インタフェース２１０には、さらに、評価情報データベース２２１および端末機器データベース２２２が接続される。
【００７４】
評価情報データベース２２１は、携帯端末や情報収集端末から送信された評価情報を記憶するようになされている。評価情報データベース２２１は、例えば、評価情報を、評価の対象となった商品やサービスの種類毎に分類し、必要に応じて商品などの識別情報、評価者の識別情報、評価日時などをキーとして検索できるようにデータベース化する。
【００７５】
端末機器データベース２２２は、携帯端末や情報収集端末（適宜端末機器と称する）の通信機能に係る情報（端末機器情報）を、端末毎に記憶するようになされている。
【００７６】
図５は、端末機器データベース２２２に記憶される情報の例を示す図である。同図は、例えば、所定の識別番号を有する携帯端末の端末機器情報の例とされる。
【００７７】
図５に示される「広域通信種別」は、当該携帯端末の広域通信手段の種別を特定する情報とされ、例えば、３Ｇ（IMT-2000）、ＷｉＭＡＸ（Worldwide Interoperability for Microwave Access）などの情報が記述される。
【００７８】
「広域通信アドレス」には、上述の広域通信手段を用いて通信する際のアドレスを特定する情報が記述される。
【００７９】
「近距離無線通信種別」は、当該携帯端末の近距離無線通信手段の種別を特定する情報とされ、例えば、Bluetooth（登録商標）、Ｗｉ−Ｆｉなどの情報が記述される。
【００８０】
「近距離無線通信アドレス」には、上述の近距離無線通信手段を用いて通信する際のアドレスを特定する情報が記述される。
【００８１】
「非接触通信方式」は、当該携帯端末の非接触通信により可能となる通信の方式を特定する情報とされ、例えば、「データ応答のみ」、「データ取得のみ」、「データ送受信可能」といった情報が記述される。
【００８２】
「固有鍵」は、当該携帯端末に予め記憶されている秘密鍵を表す情報とされる。なお、当該携帯端末がセキュリティモジュールを有する場合、セキュリティモジュールへのアクセスに必要な鍵の情報が記述される。
【００８３】
「提供者区分」は、当該携帯端末が商品やサービスの提供者の携帯端末であるか否かを特定する情報、または、商品やサービスの提供の方式などを特定する情報とされ、それを表す情報が記述される。
【００８４】
このように、サーバ２１の端末機器データベース２２２には、情報収集端末３１の端末機器情報、情報収集端末３２の端末機器情報、・・・、携帯端末４１の端末機器情報、携帯端末４２の端末機器情報、・・・が記憶されている。すなわち、端末機器データベース２２２には、評価情報収集システム１０に参加し得る端末機器の端末機器情報が、それぞれの識別情報に対応付けられて記憶されている。
【００８５】
このように、本発明の評価情報収集システム１０においては、携帯端末のハンドオーバ機能を利用して評価情報を収集するようになされている。ハンドオーバ機能を利用して収集された評価情報は、商品やサービスの提供者と評価者が極めて接近して得られた評価情報である。ハンドオーバ機能は、近接された携帯端末の非接触通信デバイスによって接続認証が行われ、近距離無線通信が行われるからである。
【００８６】
このようにして収集された評価情報は、実際に商品やサービスの提供を受けたユーザの生の声として有益であり、商品やサービスの購入にあたって参考になると考えられる。例えば、ハンドオーバ機能を利用して収集された評価情報は、雑誌に掲載される商品やサービスの紹介記事とは異なり、実際にその商品やサービスの提供を受けたユーザがそのまま評価したものと考えられるからである。また、ハンドオーバ機能を利用して収集された評価情報は、インターネット上の掲示板に書き込まれる情報と異なり、実際にその商品やサービスの提供を受けていない者からは収集されないからである。
【００８７】
しかしながら、ハンドオーバ機能を利用して評価情報を収集する場合、その評価情報が本当にハンドオーバ機能を利用して収集されたものなのかを証明することは難しい。すなわち、上述のように近距離無線通信によって商品やサービスの提供を受けた直後に収集された評価情報であるからこそ、ハンドオーバ機能を利用して収集された評価情報が有益であると解される。例えば、サーバ２１が携帯端末や情報収集端末からバッチ方式で評価情報を収集するとした場合、商品やサービスの提供者が自分にとって都合のよい評価情報だけ送信したり、または評価情報を偽造したりしているのではないかという疑念を払拭し難い。
【００８８】
勿論、評価情報収集事業者は、公正な情報収集に努めると考えられるが、例えば、特定の商品の評価が他の商品と比較して極めて高いものであった場合、評価情報を参照した者は、何らかの不正があったのではないかと勘ぐってしまう。さらに、商品やサービスの提供者に悪意がなかったとしても、ソフトウェアのトラブルなどによって、評価情報の送信に失敗したり、送信済の評価情報が繰り返し送信されたりした場合、結果として偏った評価が形成されることになる。このような事態が発生すると、その後、サーバ２１が提供する評価情報の信頼性に係る評価は著しく低下すると考えられる。
【００８９】
そこで、本発明では、サーバ２１が評価情報を収集する際に、提供者の携帯端末または情報収集端末と評価者の携帯端末との間で近距離無線通信が継続して行われていることを確認できるようにする。これにより、商品やサービスの提供を受けた直後に収集された評価情報であることが証明される。
【００９０】
詳細は後述するが、本発明では、提供者の携帯端末または情報収集端末と評価者の携帯端末との間でのハンドオーバが、直ちにサーバ２１に通知されるようになされている。そして、サーバ２１は、例えば、提供者の携帯端末または情報収集端末に広域通信手段を利用してアクセスし、同一の評価者の携帯端末との間で近距離無線通信が継続して行われていることを確認するようになされている。
【００９１】
同一の評価者の携帯端末との間で近距離無線通信が継続して行われていることの確認は、例えば、次のようにして行うことができる。ハンドオーバの通知があった場合、サーバ２１から評価者の携帯端末に所定の認証情報を送信し、ハンドオーバ後の近距離無線通信において評価者の携帯端末から認証情報が送信されていること確認する。なお、同一の評価者の携帯端末との間で近距離無線通信が継続して行われていることの確認を、リンク認証と称することにする。
【００９２】
図６は、評価情報収集システム１０において、リンク認証を行って評価情報を収集する方式の例を説明する図である。同図の例では、情報収集端末３１と携帯端末４１との間でハンドオーバが行われ、非接触通信（ＮＦＣ通信）の後、近距離無線通信（ＢＴ）によってコンテンツのデータの一部が送信されてストリーミング再生が行われる場合の例を示している。
【００９３】
同図の例において、情報収集端末３１と携帯端末４１との間でハンドオーバが情報収集端末３１からサーバ２１に広域通信を用いて通知される。このとき、情報収集端末３１の識別番号と携帯端末４１の識別番号も、サーバ２１に送信される。するとサーバ２１は、乱数を発生させ、その乱数を携帯端末４１の固有鍵を用いて暗号化する。なお、携帯端末４１の固有鍵は、端末機器データベース２２２を、携帯端末４１の識別番号を用いて検索することにより、取得することができる。
【００９４】
サーバ２１は、暗号化した乱数（暗号化乱数と称する）を情報収集端末３１の広域通信アドレス宛に送信する。なお、情報収集端末３１の広域通信アドレスは、端末機器データベース２２２を、情報収集端末３１の識別番号を用いて検索することにより、取得することができる。
【００９５】
情報収集端末３１は、サーバ２１から送信された暗号化乱数を近距離無線通信によって携帯端末４１に送信する。
【００９６】
携帯端末４１は、暗号化乱数を自分の固有鍵で復号し、乱数を得る。そして、携帯端末４１は、その乱数を近距離無線通信によって情報収集端末３１に送信する。
【００９７】
情報収集端末３１は、携帯端末４１から送信された乱数を広域通信によってサーバ２１に送信する。
【００９８】
サーバ２１は、情報収集端末３１から送信された乱数を、自分が発生した乱数と比較し、両者が一致する場合、ハンドオーバ時の評価者との近距離無線通信が行われていると確認する。すなわち、評価者の同一性を確認することができる。
【００９９】
その後、情報収集端末３１から近距離無線通信によってコンテンツのデータの一部が送信されて、携帯端末４１によりコンテンツのストリーミング再生が行われる。携帯端末４１は、この際、評価情報を情報収集端末３１に送信する。
【０１００】
このように、情報収集端末３１と携帯端末４１との間で、近距離無線通信によってコンテンツのデータの送信、評価情報の送信が行われている間、サーバ２１は、例えば、一定の周期で継続して（定期的に）上述したように評価者の同一性を確認する。
【０１０１】
そして、情報収集端末３１に蓄積された評価情報が広域通信によりサーバ２１に送信される。
【０１０２】
このようにすることで、評価情報収集システム１０において、リンク認証を行って評価情報を収集する。
【０１０３】
図７は、図６を参照して上述したリンク認証を行って評価情報を収集する処理の流れを説明するアローチャートである。
【０１０４】
同図においては、情報収集端末３１の移動体通信網用無線通信部１３１が、３Ｇ１３１−１と記載されており、携帯端末４１の移動体通信網用無線通信部１３１が、３Ｇ１３１−２と記載されている。また、情報収集端末３１の近距離無線通信部１３２が、ＢＴ１３２−１と記載されており、携帯端末４１の近距離無線通信部１３２が、ＢＴ１３２−２と記載されている。さらに、情報収集端末３１の非接触通信部１３３が、ＮＦＣ１３３−１と記載されており、携帯端末４１の非接触通信部１３３が、ＮＦＣ１３３−２と記載されている。
【０１０５】
なお、ここでの３Ｇは、Ｗ-ＣＤＭＡ方式やＣＤＭＡ２０００方式などのデジタル携帯電話の通信方式であって、いわゆる第３世代携帯電話（３Ｇ）を意味している。
【０１０６】
ステップＳ１１において、情報収集端末３１のＮＦＣ１３３−１は、ハンドオーバメッセージを送信し、ステップＳ１０１において、携帯端末４１のＮＦＣ１３３−２によりこれが受信される。
【０１０７】
ステップＳ１０２において、ＮＦＣ１３３−２は、ハンドオーバメッセージを送信し、ステップＳ１２において、ＮＦＣ１３３−１によりこれが受信される。
【０１０８】
ここまでの処理により、情報収集端末３１と携帯端末４１により対向機器情報の交換が行われることになる。なお、対向機器情報とは、ハンドオーバの相手の機器の識別番号、近距離無線通信アドレスなどの情報とされる。
【０１０９】
ステップＳ１３において、ＮＦＣ１３３−１からＢＴ１３２−１に対向機器情報が通知され、ステップＳ３１でＢＴ１３２−１によりこれが取得される。また、ステップＳ１０３において、ＮＦＣ１３３−２からＢＴ１３２−２に対向機器情報が通知され、ステップＳ１２１でＢＴ１３２−２によりこれが取得される。なお、実際には、ＣＰＵ１１１を介して対向機器情報、その他の情報の通知が行われる。以下においても同様である。
【０１１０】
ステップＳ１４において、ＮＦＣ１３３−１は、３Ｇ１３１−１に対向機器情報を通知し、ステップＳ５１で、３Ｇ１３１−１によりこれが取得される。
【０１１１】
ステップＳ５２において、３Ｇ１３１−１は、対向機器情報を含む情報をサーバ２１に送信することで、ハンドオーバの通知を行い、ステップＳ７１でサーバ２１によりこれが取得される。なお、サーバ２１にハンドオーバの通知を行う際には、ハンドオーバの相手の対向機器情報だけでなく、自分（いまの場合、情報収集端末３１）の対向機器情報もともに送信されるものとする。
【０１１２】
ステップＳ３２において、ＢＴ１３２−１からＢＴ１３２−２へＢＴ接続要求が送信され、ステップＳ１２２でこれが受信される。
【０１１３】
ステップＳ７２において、サーバ２１は、乱数を発生させ、ステップＳ７３でこれを暗号化する。ステップＳ７４において、サーバ２１は、ステップＳ７３の処理により得られた暗号化乱数を確認要求として送信し、ステップＳ５３で３Ｇ１３１−１によりこれが受信される。
【０１１４】
ステップＳ５４において、３Ｇ１３１−１は、ステップＳ５３で受信した確認要求をＢＴ１３２−１に通知し、ステップＳ３３でこれが取得される。
【０１１５】
ステップＳ３４において、ＢＴ１３２−１は、ステップＳ３３で取得した確認要求を送信し、ステップＳ１２３においてＢＴ１３２−２によりこれが受信される。
【０１１６】
ステップＳ１２４において、ＢＴ１３２−２は、ステップＳ１２３で受信した確認要求の暗号化乱数を復号して乱数を得る。なお、暗号化乱数の復号は、実際には、ＣＰＵ１１１により行われる。
【０１１７】
ステップＳ１２５において、ＢＴ１３２−２は、ステップＳ１２４の処理で得た乱数を確認応答として送信し、ステップＳ３５でＢＴ１３２−１によりこれが受信される。
【０１１８】
ステップＳ３６において、ＢＴ１３２−１は、ステップＳ３５で受信した確認応答を３Ｇ１３１−１に通知し、ステップＳ５５でこれが取得される。
【０１１９】
ステップＳ５６において、３Ｇ１３１−１は、ステップＳ５５で取得した確認応答を送信し、ステップＳ７５でサーバ２１によりこれが受信される。
【０１２０】
ステップＳ３７とステップＳ１２６では、コンテンツデータの送受信が行われ、ステップＳ１２７とステップＳ３８では、評価情報としての操作情報の送受信が行われる。
【０１２１】
ステップＳ３９において、ＢＴ１３２−１は、評価情報を３Ｇ１３１−１に通知し、ステップＳ５７でこれが取得される。
【０１２２】
ステップＳ５８において、３Ｇ１３１−１は、ステップＳ５７で取得した評価情報を送信し、ステップＳ７６でサーバ２１によりこれが受信される。
【０１２３】
なお、図中点線で囲まれた部分の処理が評価者の同一性の確認のための処理として定期的に実行されることになる。
【０１２４】
このようにして、リンク認証を行って評価情報を収集する処理が実行される。
【０１２５】
なお、図７の説明において適宜記載した通り、この例では、アローチャートの各ステップを実行する主体が、３Ｇ１３１−１、ＢＴ１３２−１、・・・などのように記載されているが、これは便宜上のものである。すなわち、本発明においては、非接触通信、近距離無線通信、広域通信の３種類の通信方式が用いられるために、各ステップにおいて送信、受信などされる情報がどの通信方式であるのか分かりやすくするために、このように記載している。従って、実際には、各ステップに係る処理の実行はＣＰＵ１１１などにより行われる。以下のアローチャートについても同様である。
【０１２６】
ところで、図６を参照して上述した例においては、携帯端末４１が固有鍵を保持している場合の例について説明したが、携帯端末４１が固有鍵を保持していない場合もある。そのような場合、例えば、図８に示されるようにして評価者の同一性を確認することができる。
【０１２７】
図８は、評価情報収集システム１０において、リンク認証を行って評価情報を収集する方式の別の例を説明する図である。同図の例では、情報収集端末３１と携帯端末４１との間でハンドオーバが行われ、非接触通信（ＮＦＣ通信）の後、近距離無線通信（ＢＴ）によってコンテンツのデータの一部が送信されてストリーミング再生が行われる場合の例を示している。図８の例の場合、図６の場合と異なり、携帯端末４１が固有鍵を保持していない。
【０１２８】
図８の例の場合、情報収集端末３１と携帯端末４１との間でハンドオーバが情報収集端末３１からサーバ２１に広域通信を用いて通知される。このとき、情報収集端末３１の識別番号と携帯端末４１の識別番号も、サーバ２１に送信される。するとサーバ２１は、乱数を発生させるが、携帯端末４１が固有鍵を保持していないことを確認する。なお、携帯端末４１が固有鍵を保持していないことは、端末機器データベース２２２を、携帯端末４１の識別番号を用いて検索することにより確認できる。
【０１２９】
サーバ２１は、乱数を一時キーとして携帯端末４１の広域通信アドレス宛に送信する。なお、携帯端末４１の広域通信アドレスは、端末機器データベース２２２を、携帯端末４１の識別番号を用いて検索することにより、取得することができる。
【０１３０】
サーバ２１は、情報収集端末３１の広域アドレスに確認要求を送信し、近距離無線通信によって情報収集端末３１から携帯端末４１に確認要求が伝送される。
【０１３１】
携帯端末４１は、確認要求に対する応答として一時キーを近距離無線通信によって情報収集端末３１に送信し、情報収集端末３１は、広域通信によってその応答をサーバ２１に伝送する。
【０１３２】
サーバ２１は、情報収集端末３１から送信された一時キーを、自分が発生した乱数と比較し、両者が一致する場合、ハンドオーバ時の評価者との近距離無線通信が行われていると確認する。すなわち、評価者の同一性を確認することができる。
【０１３３】
その後、情報収集端末３１から近距離無線通信によってコンテンツのデータの一部が送信されて、携帯端末４１によりコンテンツのストリーミング再生が行われる。携帯端末４１は、この際、評価情報を情報収集端末３１に送信する。
【０１３４】
このように、情報収集端末３１と携帯端末４１との間で、近距離無線通信によってコンテンツのデータの送信、評価情報の送信が行われている間、サーバ２１は、例えば、一定の周期で継続して（定期的に）上述したように評価者の同一性を確認する。
【０１３５】
そして、情報収集端末３１に蓄積された評価情報が広域通信によりサーバ２１に送信される。
【０１３６】
このようにすることで、携帯端末４１が固有鍵を保持していない場合でも、評価情報収集システム１０において、リンク認証を行って評価情報を収集する。
【０１３７】
図９は、図８を参照して上述したリンク認証を行って評価情報を収集する処理の流れを説明するアローチャートである。
【０１３８】
ステップＳ１１において、情報収集端末３１のＮＦＣ１３３−１は、ハンドオーバメッセージを送信し、ステップＳ１０１において、携帯端末４１のＮＦＣ１３３−２によりこれが受信される。
【０１３９】
ステップＳ１０２において、ＮＦＣ１３３−２は、ハンドオーバメッセージを送信し、ステップＳ１２において、ＮＦＣ１３３−１によりこれが受信される。
【０１４０】
ここまでの処理により、情報収集端末３１と携帯端末４１により対向機器情報の交換が行われることになる。なお、対向機器情報とは、ハンドオーバの相手の機器の識別番号、近距離無線通信アドレスなどの情報とされる。また、対向機器情報には、必要に応じてサーバ２１の広域通信のアドレスが含まれるものとする。
【０１４１】
ステップＳ１３において、ＮＦＣ１３３−１からＢＴ１３２−１に対向機器情報が通知され、ステップＳ３１でＢＴ１３２−１によりこれが取得される。また、ステップＳ１０３において、ＮＦＣ１３３−２からＢＴ１３２−２に対向機器情報が通知され、ステップＳ１２１でＢＴ１３２−２によりこれが取得される。
【０１４２】
ステップＳ１２２において、ＢＴ１３２−２は、ステップＳ１２１で取得した対向機器情報を３Ｇ１３１−２に通知し、ステップＳ１４１でこれが取得される。なお、ステップＳ１２２とステップＳ１４１の処理は省略されるようにしてもよい。
【０１４３】
ステップＳ１４において、ＮＦＣ１３３−１は、３Ｇ１３１−１に対向機器情報を通知し、ステップＳ５１で、３Ｇ１３１−１によりこれが取得される。
【０１４４】
ステップＳ５２において、３Ｇ１３１−１は、対向機器情報を含む情報をサーバ２１に送信することで、ハンドオーバの通知を行い、ステップＳ７１でサーバ２１によりこれが取得される。なお、サーバ２１にハンドオーバの通知を行う際には、ハンドオーバの相手の対向機器情報だけでなく、自分（いまの場合、情報収集端末３１）の対向機器情報もともに送信されるものとする。
【０１４５】
ステップＳ３２において、ＢＴ１３２−１からＢＴ１３２−２へＢＴ接続要求が送信され、ステップＳ１２３でこれが受信される。
【０１４６】
ステップＳ７２とステップＳ７３において、サーバ２１は、乱数を発生させ、これを一時キーとする。ステップＳ７４において、サーバ２１は、ステップＳ７３の処理により得られた一時キーを送信し、ステップＳ１４２で３Ｇ１３１−２によりこれが受信される。
【０１４７】
ステップＳ１４３において、３Ｇ１３１−２は、ステップＳ１４２で受信した一時キーをＢＴ３１２−２に通知し、ステップＳ１２４でこれが取得される。
【０１４８】
ステップＳ７５において、サーバ２１は、確認要求を送信し、ステップＳ５３において、３Ｇ１３１−１によりこれが受信される。
【０１４９】
ステップＳ５４において、３Ｇ１３１−１は、ステップＳ５３で受信した確認要求をＢＴ１３２−１に通知し、ステップＳ３３でこれが取得される。
【０１５０】
ステップＳ３４において、ＢＴ１３２−１は、ステップＳ３３で取得した確認要求を送信し、ステップＳ１２５においてＢＴ１３２−２によりこれが受信される。
【０１５１】
ステップＳ１２６において、ＢＴ１３２−２は、ステップＳ１２５で受信した確認要求に対する応答として、ステップＳ１２４で得られた一時キーを送信し、ステップＳ３５でＢＴ１３２−１によりこれが受信される。
【０１５２】
ステップＳ３６において、ＢＴ１３２−１は、ステップＳ３５で受信した確認応答を３Ｇ１３１−１に通知し、ステップＳ５５でこれが取得される。
【０１５３】
ステップＳ５６において、３Ｇ１３１−１は、ステップＳ５５で取得した確認応答を送信し、ステップＳ７６でサーバ２１によりこれが受信される。
【０１５４】
その後、コンテンツデータの送受信、評価情報としての操作情報の送受信などが行われることになるが、これらの処理は、図７を参照して説明した場合と同様なので詳細な説明は省略する。
【０１５５】
なお、図中点線で囲まれた部分の処理が評価者の同一性の確認のための処理として定期的に実行されることになる。
【０１５６】
このようにして、リンク認証を行って評価情報を収集する処理が実行される。
【０１５７】
ところで、図６を参照して上述した例と図８を参照して上述した例においては、情報収集端末３１のみから取得した情報に基づいてリンク認証が行われることになる。しかしながら、この方式は、サーバ２１を運用する評価情報収集事業者などと、情報収集端末３１を運用するコンテンツの提供者との間に十分な信頼関係がない場合、有効に機能しないことがある。なお、情報収集端末３１を運用するコンテンツの提供者が信頼できるものであることを表すために、図６と図８においては、情報収集端末３１に「Ｔｒｕｓｔｅｄ」と記されている。
【０１５８】
例えば、コンテンツの提供者が信頼できない者である場合、携帯端末４１によって復号されて得られた乱数、携帯端末４１が広域通信により受信した一時キーがそのままサーバ２１に送信されているという確証はもてない。すなわち、図７のステップＳ５６、図９のステップＳ５６で送信される確認応答が情報収集端末３１によって偽造されたものである可能性を否定することができない。
【０１５９】
このため、評価情報収集事業者などとコンテンツの提供者との間に十分な信頼関係がない場合、提供者側から送信される情報に基づいて評価者の同一性を確認するだけでは足りず、さらに評価者側から送信される情報に基づいて提供者の同一性を確認する必要がある。すなわち、例えば、提供者が評価者になりすますなどの可能性を否定できないから、ハンドオーバ時の提供者と評価者が継続して近距離無線通信を行っていることを、提供者側と評価者側のそれぞれから確認する必要がある。
【０１６０】
図１０は、評価情報収集システム１０において、リンク認証を行って評価情報を収集する方式のさらに別の例を説明する図である。同図の例では、携帯端末４７と携帯端末４６との間でハンドオーバが行われ、非接触通信（ＮＦＣ通信）の後、近距離無線通信（ＢＴ）によってコンテンツ（例えば、ゲーム）のデータが送信される場合の例を示している。
【０１６１】
図１０の例の場合、図６または図８の場合と異なり、コンテンツの提供者である携帯端末４７に「Ｔｒｕｓｔｅｄ」と記されていない。すなわち、図１０の例の場合、評価情報収集事業者などとコンテンツの提供者との間に十分な信頼関係がないのである。なお、同図の例では、携帯端末４６と携帯端末４７はともに固有鍵を保持しているものとする。
【０１６２】
図１０の例において、携帯端末４７と携帯端末４６との間でのハンドオーバが携帯端末４７からサーバ２１に広域通信を用いて通知される。このとき、携帯端末４７と携帯端末４６の識別番号も、サーバ２１に送信される。するとサーバ２１は、乱数を発生させ、その乱数を携帯端末４６の固有鍵を用いて暗号化する。なお、携帯端末４６の固有鍵は、端末機器データベース２２２を、携帯端末４６の識別番号を用いて検索することにより、取得することができる。
【０１６３】
サーバ２１は、暗号化した乱数（暗号化乱数と称する）を携帯端末４７の広域通信アドレス宛に送信する。なお、携帯端末４７の広域通信アドレスは、端末機器データベース２２２を、携帯端末４７の識別番号を用いて検索することにより、取得することができる。
【０１６４】
携帯端末４７は、サーバ２１から送信された暗号化乱数を近距離無線通信によって携帯端末４６に送信する。
【０１６５】
携帯端末４６は、暗号化乱数を自分の固有鍵で復号し、乱数を得る。そして、携帯端末４６は、その乱数を近距離無線通信によって携帯端末４７に送信する。
【０１６６】
携帯端末４７は、携帯端末４６から送信された乱数を広域通信によってサーバ２１に送信する。
【０１６７】
サーバ２１は、携帯端末４７から送信された乱数を、自分が発生した乱数と比較し、両者が一致する場合、ハンドオーバ時の評価者との近距離無線通信が行われていると確認する。すなわち、提供者側から送信される情報に基づいて評価者の同一性を確認することができる。
【０１６８】
また、サーバ２１は、別の乱数を発生させ、その乱数を携帯端末４７の固有鍵を用いて暗号化する。なお、携帯端末４７の固有鍵は、端末機器データベース２２２を、携帯端末４７の識別番号を用いて検索することにより、取得することができる。
【０１６９】
サーバ２１は、暗号化した乱数（暗号化乱数と称する）を携帯端末４６の広域通信アドレス宛に送信する。なお、携帯端末４６の広域通信アドレスは、端末機器データベース２２２を、携帯端末４６の識別番号を用いて検索することにより、取得することができる。
【０１７０】
携帯端末４６は、サーバ２１から送信された暗号化乱数を近距離無線通信によって携帯端末４７に送信する。
【０１７１】
携帯端末４７は、暗号化乱数を自分の固有鍵で復号し、乱数を得る。そして、携帯端末４７は、その乱数を近距離無線通信によって携帯端末４６に送信する。
【０１７２】
携帯端末４６は、携帯端末４７から送信された乱数を広域通信によってサーバ２１に送信する。
【０１７３】
サーバ２１は、携帯端末４６から送信された乱数を、自分が発生した乱数と比較し、両者が一致する場合、ハンドオーバ時の提供者との近距離無線通信が行われていると確認する。すなわち、評価者側から送信される情報に基づいて提供者の同一性を確認することができる。
【０１７４】
その後、携帯端末４７から近距離無線通信によってコンテンツのデータが送信されて、携帯端末４６によりゲームの画面などが表示される。携帯端末４６は、この際、評価情報を携帯端末４７に送信する。
【０１７５】
このように、携帯端末４７と携帯端末４６との間で、近距離無線通信によってコンテンツのデータの送信、評価情報の送信が行われている間、サーバ２１は、例えば、一定の周期で継続して（定期的に）上述したように評価者の同一性と提供者の同一性を確認する。
【０１７６】
そして、携帯端末４７に蓄積された評価情報が広域通信によりサーバ２１に送信される。
【０１７７】
このようにすることで、評価情報収集事業者などとコンテンツの提供者との間に十分な信頼関係がない場合でも、評価情報収集システム１０において、リンク認証を行って評価情報を収集する。
【０１７８】
図１１は、図１０を参照して上述したリンク認証を行って評価情報を収集する処理の流れを説明するアローチャートである。
【０１７９】
同図においては、携帯端末４７の移動体通信網用無線通信部１３１が、３Ｇ１３１−３と記載されており、携帯端末４６の移動体通信網用無線通信部１３１が、３Ｇ１３１−４と記載されている。また、携帯端末４７の近距離無線通信部１３２が、ＢＴ１３２−３と記載されており、携帯端末４６の近距離無線通信部１３２が、ＢＴ１３２−４と記載されている。さらに、携帯端末４７の非接触通信部１３３が、ＮＦＣ１３３−３と記載されており、携帯端末４６の非接触通信部１３３が、ＮＦＣ１３３−４と記載されている。
【０１８０】
ステップＳ２１１において、携帯端末４７のＮＦＣ１３３−３は、ハンドオーバメッセージを送信し、ステップＳ３０１において、携帯端末４６のＮＦＣ１３３−４によりこれが受信される。
【０１８１】
ステップＳ３０２において、ＮＦＣ１３３−４は、ハンドオーバメッセージを送信し、ステップＳ２１２において、ＮＦＣ１３３−３によりこれが受信される。
【０１８２】
ここまでの処理により、携帯端末４７と携帯端末４６により対向機器情報の交換が行われることになる。なお、対向機器情報とは、ハンドオーバの相手の機器の識別番号、近距離無線通信アドレスなどの情報とされる。また、対向機器情報には、必要に応じてサーバ２１の広域通信のアドレスが含まれるものとする。
【０１８３】
ステップＳ２１３において、ＮＦＣ１３３−３からＢＴ１３２−３に対向機器情報が通知され、ステップＳ２３１でＢＴ１３２−３によりこれが取得される。また、ステップＳ３０３において、ＮＦＣ１３３−４からＢＴ１３２−４に対向機器情報が通知され、ステップＳ３２１でＢＴ１３２−４によりこれが取得される。ステップＳ３２２において、ＢＴ１３２−４は、ステップＳ３２１で取得した対向機器情報を３Ｇ１３１−４に通知し、ステップＳ３４１でこれが取得される。なお、実際には、ＣＰＵ１１１を介して対向機器情報、その他の情報の通知が行われる。以下においても同様である。
【０１８４】
ステップＳ３４２において、３Ｇ１３１−４は、対向機器情報を含む情報をサーバ２１に送信することで、ハンドオーバの通知を行い、ステップＳ２７１でサーバ２１によりこれが受信される。なお、ステップＳ３２１、ステップＳ３４１、ステップＳ３４２の処理は、省略されるようにしてもよい。
【０１８５】
ステップＳ２１４において、ＮＦＣ１３３−３は、３Ｇ１３１−３に対向機器情報を通知し、ステップＳ２５１で、３Ｇ１３１−３によりこれが取得される。
【０１８６】
ステップＳ２５２において、３Ｇ１３１−３は、対向機器情報を含む情報をサーバ２１に送信することで、ハンドオーバの通知を行い、ステップＳ２７２でサーバ２１によりこれが受信される。なお、サーバ２１にハンドオーバの通知を行う際には、ハンドオーバの相手の対向機器情報だけでなく、自分（いまの場合、携帯端末４７）の対向機器情報もともに送信されるものとする。
【０１８７】
ステップＳ２３２において、ＢＴ１３２−３からＢＴ１３２−４へＢＴ接続要求が送信され、ステップＳ３２３でこれが受信される。
【０１８８】
ステップＳ２７３において、サーバ２１は、乱数を発生させ、ステップＳ２７４でこれを暗号化する。ステップＳ２７５において、サーバ２１は、ステップＳ２７４の処理により得られた暗号化乱数を確認要求として送信し、ステップＳ２５３で３Ｇ１３１−３によりこれが受信される。
【０１８９】
ステップＳ２５４において、３Ｇ１３１−３は、ステップＳ２５３で受信した確認要求をＢＴ１３２−３に通知し、ステップＳ２３３でこれが取得される。
【０１９０】
ステップＳ２３４において、ＢＴ１３２−３は、ステップＳ２３３で取得した確認要求を送信し、ステップＳ３２４でＢＴ１３２−４によりこれが受信される。
【０１９１】
ステップＳ３２５において、ＢＴ１３２−４は、ステップＳ３２４で受信した確認要求の暗号化乱数を復号して乱数を得る。なお、暗号化乱数の復号は、実際には、ＣＰＵ１１１により行われる。
【０１９２】
ステップＳ３２６において、ＢＴ１３２−４は、ステップＳ３２５の処理で得た乱数を確認応答として送信し、ステップＳ２３５でＢＴ１３２−３によりこれが受信される。
【０１９３】
ステップＳ２３６において、ＢＴ１３２−３は、ステップＳ３５で受信した確認応答を３Ｇ１３１−３に通知し、ステップＳ２５５でこれが取得される。
【０１９４】
ステップＳ２５６において、３Ｇ１３１−３は、ステップＳ２５５で取得した確認応答を送信し、ステップＳ２７６でサーバ２１によりこれが受信される。
【０１９５】
また、ステップＳ２７７において、サーバ２１は、別の乱数を発生させ、ステップＳ２７８でこれを暗号化する。ステップＳ２７９において、サーバ２１は、ステップＳ２７８の処理により得られた暗号化乱数を確認要求として送信し、ステップＳ３４３で３Ｇ１３１−４によりこれが受信される。
【０１９６】
ステップＳ３４４において、３Ｇ１３１−４は、ステップＳ３４３で受信した確認要求をＢＴ１３２−４に通知し、ステップＳ３２８でこれが取得される。
【０１９７】
ステップＳ３２９において、ＢＴ１３２−４は、ステップＳ３２８で取得した確認要求を送信し、ステップＳ２３７でＢＴ１３２−３によりこれが受信される。
【０１９８】
ステップＳ２３８において、ＢＴ１３２−３は、ステップＳ２３７で受信した確認要求の暗号化乱数を復号して乱数を得る。
【０１９９】
ステップＳ２３９において、ＢＴ１３２−３は、ステップＳ２３８の処理で得た乱数を確認応答として送信し、ステップＳ３３０でＢＴ１３２−４によりこれが受信される。
【０２００】
ステップＳ３３１において、ＢＴ１３２−４は、ステップＳ３３０で受信した確認応答を３Ｇ１３１−３に通知し、ステップＳ３４５でこれが取得される。
【０２０１】
ステップＳ３４６において、３Ｇ１３１−４は、ステップＳ３４５で取得した確認応答を送信し、ステップＳ２８０でサーバ２１によりこれが受信される。
【０２０２】
その後、コンテンツデータの送受信、評価情報としての操作情報の送受信などが行われることになるが、これらの処理は、図７を参照して説明した場合と同様なので詳細な説明は省略する。
【０２０３】
なお、図中点線で囲まれた部分の処理が評価者の同一性と提供者の同一性の確認のための処理として定期的に実行されることになる。
【０２０４】
このようにして、リンク認証を行って評価情報を収集する処理が実行される。
【０２０５】
ところで、図１０を参照して上述した例においては、携帯端末４６が固有鍵を保持している場合の例について説明したが、携帯端末４６が固有鍵を保持していない場合もある。そのような場合、例えば、図１２に示されるようにして評価者の同一性と提供者の同一性を確認することができる。
【０２０６】
図１２は、評価情報収集システム１０において、リンク認証を行って評価情報を収集する方式のさらに別の例を説明する図である。同図の例では、携帯端末４７と携帯端末４６との間でハンドオーバが行われ、非接触通信（ＮＦＣ通信）の後、近距離無線通信（ＢＴ）によってコンテンツ（例えば、ゲーム）のデータが送信される場合の例を示している。
【０２０７】
図１２の例の場合、図１０の場合と同様に、コンテンツの提供者である携帯端末４７に「Ｔｒｕｓｔｅｄ」と記されておらず、評価情報収集事業者などとコンテンツの提供者との間に十分な信頼関係がない。また、同図の例では、図１０の場合と異なり、携帯端末４７は固有鍵を保持しているが、携帯端末４６が固有鍵を保持していないものとする。
【０２０８】
図１２において、携帯端末４７と携帯端末４６との間でのハンドオーバが携帯端末４７からサーバ２１に広域通信を用いて通知される。このとき、携帯端末４７と携帯端末４６の識別番号も、サーバ２１に送信される。するとサーバ２１は、乱数を発生させるが、携帯端末４６が固有鍵を保持していないことを確認する。なお、携帯端末４６が固有鍵を保持していないことは、端末機器データベース２２２を、携帯端末４６の識別番号を用いて検索することにより確認できる。
【０２０９】
サーバ２１は、乱数を一時キーとして携帯端末４６の広域通信アドレス宛に送信する。なお、携帯端末４６の広域通信アドレスは、端末機器データベース２２２を、携帯端末４６の識別番号を用いて検索することにより、取得することができる。
【０２１０】
サーバ２１は、携帯端末４７の広域アドレスに確認要求を送信し、近距離無線通信によって携帯端末４７から携帯端末４６に確認要求が伝送される。なお、携帯端末４７の広域通信アドレスは、端末機器データベース２２２を、携帯端末４７の識別番号を用いて検索することにより、取得することができる。
【０２１１】
携帯端末４６は、確認要求に対する応答として一時キーを近距離無線通信によって携帯端末４７に送信し、携帯端末４７は、広域通信によってその応答をサーバ２１に伝送する。
【０２１２】
サーバ２１は、携帯端末４７から送信された一時キーを、自分が発生した乱数と比較し、両者が一致する場合、ハンドオーバ時の評価者との近距離無線通信が行われていると確認する。すなわち、提供者側から送信される情報に基づいて評価者の同一性を確認することができる。
【０２１３】
また、サーバ２１は、別の乱数を発生させ、その乱数を携帯端末４７の固有鍵を用いて暗号化する。なお、携帯端末４７の固有鍵は、端末機器データベース２２２を、携帯端末４７の識別番号を用いて検索することにより、取得することができる。
【０２１４】
サーバ２１は、暗号化した乱数（暗号化乱数と称する）を携帯端末４６の広域通信アドレス宛に送信する。なお、携帯端末４６の広域通信アドレスは、端末機器データベース２２２を、携帯端末４６の識別番号を用いて検索することにより、取得することができる。
【０２１５】
携帯端末４６は、サーバ２１から送信された暗号化乱数を近距離無線通信によって携帯端末４７に送信する。
【０２１６】
携帯端末４７は、暗号化乱数を自分の固有鍵で復号し、乱数を得る。そして、携帯端末４７は、その乱数を近距離無線通信によって携帯端末４６に送信する。
【０２１７】
携帯端末４６は、携帯端末４７から送信された乱数を広域通信によってサーバ２１に送信する。
【０２１８】
サーバ２１は、携帯端末４６から送信された乱数を、自分が発生した乱数と比較し、両者が一致する場合、ハンドオーバ時の提供者との近距離無線通信が行われていると確認する。すなわち、評価者側から送信される情報に基づいて提供者の同一性を確認することができる。
【０２１９】
その後、携帯端末４７から近距離無線通信によってコンテンツのデータが送信されて、携帯端末４６によりゲームの画面などが表示される。携帯端末４６は、この際、評価情報を携帯端末４７に送信する。
【０２２０】
このように、携帯端末４７と携帯端末４６との間で、近距離無線通信によってコンテンツのデータの送信、評価情報の送信が行われている間、サーバ２１は、例えば、一定の周期で継続して（定期的に）上述したように評価者の同一性と提供者の同一性を確認する。
【０２２１】
そして、携帯端末４７に蓄積された評価情報が広域通信によりサーバ２１に送信される。
【０２２２】
このようにすることで、評価情報収集事業者などとコンテンツの提供者との間に十分な信頼関係がない場合、評価者側に固有鍵がないときでも、評価情報収集システム１０において、リンク認証を行って評価情報を収集する。
【０２２３】
図１２を参照して上述した処理は、既に図１０を参照して上述した処理と、図８を参照して上述した処理を組み合わせたものであるから、アローチャートを用いた詳細な説明は省略する。
【０２２４】
さらに、携帯端末４６と携帯端末４７の双方が固有鍵を保持していない場合もある。そのような場合、例えば、図１３に示されるようにして評価者の同一性と提供者の同一性を確認することができる。
【０２２５】
図１３は、評価情報収集システム１０において、リンク認証を行って評価情報を収集する方式のさらに別の例を説明する図である。同図の例では、携帯端末４７と携帯端末４６との間でハンドオーバが行われ、非接触通信（ＮＦＣ通信）の後、近距離無線通信（ＢＴ）によってコンテンツ（例えば、ゲーム）のデータが送信される場合の例を示している。
【０２２６】
図１３の例の場合、図１０の場合と同様に、コンテンツの提供者である携帯端末４７に「Ｔｒｕｓｔｅｄ」と記されておらず、評価情報収集事業者などとコンテンツの提供者との間に十分な信頼関係がない。また、同図の例では、図１２の場合と異なり、携帯端末４７と携帯端末４６の双方が固有鍵を保持していないものとする。
【０２２７】
図１３において、携帯端末４７と携帯端末４６との間でのハンドオーバが携帯端末４７からサーバ２１に広域通信を用いて通知される。このとき、携帯端末４７と携帯端末４６の識別番号も、サーバ２１に送信される。するとサーバ２１は、乱数を発生させるが、携帯端末４６が固有鍵を保持していないことを確認する。なお、携帯端末４６が固有鍵を保持していないことは、端末機器データベース２２２を、携帯端末４６の識別番号を用いて検索することにより確認できる。
【０２２８】
サーバ２１は、乱数を一時キーとして携帯端末４６の広域通信アドレス宛に送信する。なお、携帯端末４６の広域通信アドレスは、端末機器データベース２２２を、携帯端末４６の識別番号を用いて検索することにより、取得することができる。
【０２２９】
サーバ２１は、携帯端末４７の広域アドレスに確認要求を送信し、近距離無線通信によって携帯端末４７から携帯端末４６に確認要求が伝送される。なお、携帯端末４７の広域通信アドレスは、端末機器データベース２２２を、携帯端末４７の識別番号を用いて検索することにより、取得することができる。
【０２３０】
携帯端末４６は、確認要求に対する応答として一時キーを近距離無線通信によって携帯端末４７に送信し、携帯端末４７は、広域通信によってその応答をサーバ２１に伝送する。
【０２３１】
サーバ２１は、携帯端末４７から送信された一時キーを、自分が発生した乱数と比較し、両者が一致する場合、ハンドオーバ時の評価者との近距離無線通信が行われていると確認する。すなわち、提供者側から送信される情報に基づいて評価者の同一性を確認することができる。
【０２３２】
また、サーバ２１は、別の乱数を発生させるが、携帯端末４７が固有鍵を保持していないことを確認する。なお、携帯端末４７が固有鍵を保持していないことは、端末機器データベース２２２を、携帯端末４７の識別番号を用いて検索することにより確認できる。
【０２３３】
サーバ２１は、乱数を一時キーとして携帯端末４７の広域通信アドレス宛に送信する。
【０２３４】
サーバ２１は、携帯端末４６の広域アドレスに確認要求を送信し、近距離無線通信によって携帯端末４６から携帯端末４７に確認要求が伝送される。
【０２３５】
携帯端末４７は、確認要求に対する応答として一時キーを近距離無線通信によって携帯端末４６に送信し、携帯端末４６は、広域通信によってその応答をサーバ２１に伝送する。
【０２３６】
サーバ２１は、携帯端末４６から送信された一時キーを、自分が発生した乱数と比較し、両者が一致する場合、ハンドオーバ時の提供者との近距離無線通信が行われていると確認する。すなわち、評価者側から送信される情報に基づいて提供者の同一性を確認することができる。
【０２３７】
その後、携帯端末４７から近距離無線通信によってコンテンツのデータが送信されて、携帯端末４６によりゲームの画面などが表示される。携帯端末４６は、この際、評価情報を携帯端末４７に送信する。
【０２３８】
このように、携帯端末４７と携帯端末４６との間で、近距離無線通信によってコンテンツのデータの送信、評価情報の送信が行われている間、サーバ２１は、例えば、一定の周期で継続して（定期的に）上述したように評価者の同一性と提供者の同一性を確認する。
【０２３９】
そして、携帯端末４７に蓄積された評価情報が広域通信によりサーバ２１に送信される。
【０２４０】
このようにすることで、評価情報収集事業者などとコンテンツの提供者との間に十分な信頼関係がない場合、評価者側および提供者側ともに固有鍵がないときでも、評価情報収集システム１０において、リンク認証を行って評価情報を収集する。
【０２４１】
なお、図１３を参照して上述した処理も、既に説明した処理を組み合わせたものであるから、アローチャートを用いた詳細な説明は省略する。
【０２４２】
このように、本発明によれば、リンク認証を行って、評価情報を収集することができ、この際、例えば、コンテンツ提供者と評価者が動的に変わるＰ２Ｐネットワーク上での評価情報の取得にも対応できる。
【０２４３】
また、本発明によれば、評価対象の商品やコンテンツなどが提示されてから評価情報が収集されるまで時間を従来と比較して短縮することができ、タイムリーな評価情報を提供することも可能となる。
【０２４４】
さらに、例えば、評価者が実在することを確認できるようにカメラ等の専用の装置を設置する必要もなく、簡単な構成で信頼性の高い評価情報収集システムを実現することができる。
【０２４５】
図６乃至図１３を参照して上述した例についてまとめると、評価情報収集システム１０において、リンク認証を行って評価情報を収集する場合、次の２点を考慮する必要があると考えられる。第１点目は、評価情報収集事業者などとコンテンツの提供者との間に十分な信頼関係があるか否かであり、第２点目は、評価者側および提供者側の固有鍵の有無である。
【０２４６】
すなわち、評価情報収集事業者などとコンテンツの提供者との間に十分な信頼関係がある場合、提供者側から送信される情報に基づいて評価者の同一性を定期的に確認することによってリンク認証を実現することができる。一方、評価情報収集事業者などとコンテンツの提供者との間に十分な信頼関係がない場合、提供者側から送信される情報に基づいて評価者の同一性を定期的に確認するとともに、評価者側から送信される情報に基づいて提供者の同一性を確認することによってリンク認証を実現することができる。
【０２４７】
また、評価者の携帯端末が固有鍵を保持している場合、固有鍵を用いて暗号化した乱数を提供者側の携帯端末などに送信すれば、提供者側から送信される情報に基づいて評価者の同一性を確認することが可能となる。一方、評価者の携帯端末が固有鍵を保持していない場合、一時キーを評価者側の携帯端末などに送信しておき、その後、提供者の携帯端末などに確認要求を送信すれば、提供者側から送信される情報に基づいて評価者の同一性を確認することが可能となる。
【０２４８】
同様に、提供者の携帯端末などが固有鍵を保持している場合、固有鍵を用いて暗号化した乱数を評価者側の携帯端末に送信すれば、評価者側から送信される情報に基づいて提供者の同一性を確認することが可能となる。一方、提供者の携帯端末などが固有鍵を保持していない場合、一時キーを提供者側の携帯端末などに送信しておき、その後、評価者の携帯端末などに確認要求を送信すれば、評価者側から送信される情報に基づいて提供者の同一性を確認することが可能となる。
【０２４９】
このように、合計５通りの方式で、リンク認証を行った評価情報の収集が実現されることになる。
【０２５０】
本発明においては、評価情報収集事業者などとコンテンツの提供者との間の信頼関係の有無、評価者側および提供者側の固有鍵の有無にかかわらず、リンク認証を行った評価情報の収集ができるようにする。そのために、ハンドオーバメッセージに次のような情報を含めるようにする。
【０２５１】
図１４は、ハンドオーバメッセージのフォーマットを説明する図である。ハンドオーバメッセージは、例えば、携帯端末や情報収集端末が非接触通信（ＮＦＣ通信）を行うときに送受信される情報とされる。ハンドオーバメッセージのフォーマットについては、ＮＦＣＦｏｒｕｍによる標準化が行われており、図示されるフォーマットがＮＦＣＦｏｒｕｍの規格によって規定されている。
【０２５２】
同図に示されるように、ハンドオーバメッセージは、複数（この例では４）のレコードに分割されて構成されている。
【０２５３】
「Ｒｅｃｏｒｄ１」は、ハンドオーバのリクエストおよびセレクトなどの情報が格納されるレコードとされる。「Ｒｅｃｏｒｄ２」は、セカンドキャリア候補を格納するレコードであり、ヘッダ部分のＲｅｃｏｒｄＴｙｐｅに「ac(Alternative Carrier)」が格納され、ペイロード部には各セカンドキャリアのポインタ（Ｒｅｃｏｒｄ3の識別子）が格納される。
【０２５４】
「Ｒｅｃｏｒｄ３」は、近距離無線通信手段に関する情報が格納されるレコードとされる。同図に示されるように、「Ｒｅｃｏｒｄ３」には、ヘッダとペイロードからなるパケットが格納されることがBluetoothSIGの規格によって規定されている。なお、「Ｒｅｃｏｒｄ３」のパケットとして図示されているパケットは、近距離無線通信手段がBluetoothの通信を行う場合のものである。
【０２５５】
「Ｒｅｃｏｒｄ４」は、携帯端末などの製造事業者によって定義された情報が格納されるレコードとされる。本発明では、「Ｒｅｃｏｒｄ４」に含まれる情報として図示されるようなパケットの情報を定義する。
【０２５６】
同図に示されるように、「Ｒｅｃｏｒｄ４」には、ヘッダとペイロードからなるパケットが格納される。
【０２５７】
ヘッダには、「ＲｅｃｏｒｄＴｙｐｅ」の情報が記述され、いまの場合、レコード４が評価情報収集のために用いられる情報が格納されるレコードであることを表す情報が記述される。
【０２５８】
ペイロードは、「サーバ承認区分」、「リンク認証方式」、および「広域通信アドレス」によって構成されている。
【０２５９】
「サーバ承認区分」には、当該端末機器が、サーバ２１により承認された端末機器であるか否かを表す情報（例えば、Ｙｅｓ／Ｎｏ）が記述される。当該端末機器が、サーバ２１により承認された端末機器である場合、評価情報収集事業者などとの間に十分な信頼関係があることを意味する。
【０２６０】
「リンク認証方式」は、上述した評価者の同一性の確認または提供者の同一性の確認を行うための方式を表す情報が記述される。具体的には、例えば、固有鍵を用いて乱数を暗号化する方式であるか、予めサーバ２１から一時キーを送信する方式であるかを表す情報が記述される。
【０２６１】
「広域通信アドレス」には、必要に応じて当該機器の広域通信のアドレス、サーバ２１の広域通信のアドレスが記述される。
【０２６２】
本発明の評価情報収集システム１０では、ハンドオーバ時に、図１４に示されるようなハンドオーバメッセージが送受信される。図１４に示される情報は、対向機器情報として、ハンドオーバの通知とともに、サーバ２１にも送信される。
【０２６３】
サーバ２１は、情報収集端末または携帯端末からハンドオーバの通知を受けたとき、図１４の「Ｒｅｃｏｒｄ４」に含まれる情報を解析して、リンク認証を行うようになされている。上述したように、本発明の評価情報収集システム１０では、合計５通りの方式で、リンク認証を行った評価情報の収集が実現される。
【０２６４】
第１の方式は、図６を参照して上述したように、評価情報収集事業者などと提供者との間に十分な信頼関係があり、かつ評価者の携帯端末が固有鍵を保持している場合である。これをケース１と称することにする。
【０２６５】
第２の方式は、図８を参照して上述したように、評価情報収集事業者などと提供者との間に十分な信頼関係があり、かつ評価者の携帯端末が固有鍵を保持していない場合である。これをケース２と称することにする。
【０２６６】
第３の方式は、図１０を参照して上述したように、評価情報収集事業者などと提供者との間に十分な信頼関係がなく、かつ評価者の携帯端末および提供者の携帯端末がともに固有鍵を保持している場合である。これをケース３と称することにする。
【０２６７】
第４の方式は、図１２を参照して上述したように、評価情報収集事業者などと提供者との間に十分な信頼関係がなく、かつ評価者の携帯端末は固有鍵を保持しておらず、提供者の携帯端末は固有鍵を保持している場合である。これをケース４と称することにする。
【０２６８】
第５の方式は、図１３を参照して上述したように、評価情報収集事業者などと提供者との間に十分な信頼関係がなく、かつ評価者の携帯端末および提供者の携帯端末がともに固有鍵を保持していない場合である。これをケース５と称することにする。
【０２６９】
サーバ２１は、情報収集端末または携帯端末からハンドオーバの通知を受けたとき、図１４の「Ｒｅｃｏｒｄ４」に含まれる情報を解析して、提供者側の属性と、評価者側の属性を特定し、図１５に示されるようにリンク認証の方式を特定する。
【０２７０】
すなわち、図１５に示されるように、提供者側および評価者側のハンドオーバメッセージの「サーバ承認区分」に基づいて評価情報収集事業者などとの間に十分な信頼関係があるか否かが判定される。この例では、評価情報収集事業者などとの間に十分な信頼関係があるもの（「サーバ承認区分」がＹｅｓ）は「Ｔｒｕｓｔｅｄ」と記載されており、信頼関係がないもの（「サーバ承認区分」がＮｏ）は「ＮｏＴｒｕｓｔｅｄ」と記載されている。
【０２７１】
また、提供者側および評価者側のハンドオーバメッセージの「サーバ承認区分」に基づいて評価者の同一性の確認または提供者の同一性の確認を行うための方式が特定される。この例では、固有鍵を用いて乱数を暗号化する方式であるものは「固有鍵」と記載されており、予めサーバ２１から一時キーを送信する方式であるものは「一時キー」と記載されている。
【０２７２】
このようにしてサーバ２１は、リンク認証の方式を特定し、評価情報の収集の際のリンク認証を行うのである。
【０２７３】
次に、図１６のフローチャートを参照してサーバ２１により実行される評価情報収集処理の例について説明する。
【０２７４】
ステップＳ７０１においてサーバ２１のＣＰＵ２０１は、情報収集端末または携帯端末からのハンドオーバの通知を受けたか否かを判定し、ハンドオーバの通知を受けたと判定されるまで待機する。
【０２７５】
ステップＳ７０１において、ハンドオーバの通知を受けたと判定された場合、処理は、ステップＳ７０２に進む。
【０２７６】
ステップＳ７０２において、ＣＰＵ２０１は、ハンドオーバの通知とともに送信された提供者側の機器情報を取得して解析し、提供者側の属性を特定する。このとき、例えば、図１４の「Ｒｅｃｏｒｄ４」に含まれる情報が解析されて提供者側（例えば、情報収集端末３１、携帯端末４７など）の属性が特定される。すなわち、評価情報収集事業者などとの間に十分な信頼関係があるか否か、固有鍵を用いて乱数を暗号化する方式であるか、予めサーバ２１から一時キーを送信する方式であるかが特定される。
【０２７７】
ステップＳ７０３において、ＣＰＵ２０１は、ステップＳ７０２の処理と同様にして、ハンドオーバの通知とともに送信された評価者側の機器情報を取得して解析し、評価者側の属性を特定する。
【０２７８】
ステップＳ７０４において、ＣＰＵ２０１は、ステップＳ７０２とステップＳ７０３で特定された属性に基づいて、リンク認証の方式を特定する。すなわち、図１５を参照して上述したように、ケース１乃至ケース５の方式が特定される。
【０２７９】
ステップＳ７０５において、ＣＰＵ２０１は、ステップＳ７０４で特定されたリンク認証の方式に基づいて方式別リンク認証処理を実行する。これにより、ケース１乃至ケース５のそれぞれに対応したリンク認証が行われることになる。
【０２８０】
図１７は、ステップＳ７０４において、リンク認証の方式がケース１であると特定された場合、ステップＳ７０５の処理として実行されるケース１処理の例を説明するフローチャートである。
【０２８１】
ステップＳ７２１において、ＣＰＵ２０１は、乱数を生成（発生）する。
【０２８２】
ステップＳ７２２において、ＣＰＵ２０１は、端末機器データベース２２２を、評価者側（例えば、携帯端末４１）の識別番号を用いて検索することにより、評価者側の固有鍵を取得する。
【０２８３】
ステップＳ７２３において、ＣＰＵ２０１は、ステップＳ７２２で取得した固有鍵を用いて、ステップＳ７２１で生成した乱数を暗号化する。
【０２８４】
ステップＳ７２４において、ＣＰＵ２０１は、端末機器データベース２２２を、提供者側（例えば、情報収集端末３１）の識別番号を用いて検索することにより、提供者側の広域通信アドレスを取得する。
【０２８５】
ステップＳ７２５において、ＣＰＵ２０１は、ステップＳ７２３で生成した暗号化乱数を確認要求として、ステップＳ７２４で取得した広域アドレスに送信する。
【０２８６】
ステップＳ７２６において、ＣＰＵ２０１は、ステップＳ７２５で送信した確認要求に対する応答であって、適正な確認応答を受信したか否かを判定する。このとき、確認応答に、ステップＳ７２１で生成した乱数が含まれているか否かが判定され、上記の乱数が含まれている場合、適正な確認応答を受信したと判定される。
【０２８７】
ステップＳ７２６において、適正な確認応答を受信したと判定された場合、処理は、ステップＳ７２７に進む。一方、適正な確認応答を受信しなかったと判定された場合、処理は、ステップＳ７３０に進み、エラー処理が実行される。
【０２８８】
ステップＳ７２７において、ＣＰＵ２０１は、適正な確認応答を受信した時刻を、リンク認証の認証時刻として記録する。
【０２８９】
ステップＳ７２８において、ＣＰＵ２０１は、提供者側から評価情報が送信されたか否かを判定し、まだ送信されていないと判定された場合、ステップＳ７２９に進む。
【０２９０】
ステップＳ７２９において、ＣＰＵ２０１は、ステップＳ７２７で認証時刻が記録されてから、所定の時間が経過したか否かを判定し、所定の時間が経過したと判定されるまで待機する。ステップＳ７２９において、所定の時間が経過したと判定された場合、処理は、ステップＳ７２１に戻る。このようにすることで、一定の周期で継続して（定期的に）評価者の同一性が確認される。
【０２９１】
一方、ステップＳ７２８において、提供者側から評価情報が送信されたと判定された場合、ケース１処理は終了する。
【０２９２】
このようにして、ケース１の場合の方式別リンク認証処理が実行される。
【０２９３】
図１８は、ステップＳ７０４において、リンク認証の方式がケース２であると特定された場合、ステップＳ７０５の処理として実行されるケース２処理の例を説明するフローチャートである。
【０２９４】
ステップＳ７５１において、ＣＰＵ２０１は、一時キーを生成する。
【０２９５】
ステップＳ７５２において、ＣＰＵ２０１は、端末機器データベース２２２を、評価者側（例えば、携帯端末４１）の識別番号を用いて検索することにより、評価者側の広域通信アドレスを取得する。
【０２９６】
ステップＳ７５３において、ＣＰＵ２０１は、ステップＳ７５１で生成した一時キーを、ステップＳ７５２で取得した広域アドレスに送信する。
【０２９７】
ステップＳ７５４において、ＣＰＵ２０１は、端末機器データベース２２２を、提供者側（例えば、情報収集端末３１）の識別番号を用いて検索することにより、提供者側の広域通信アドレスを取得する。
【０２９８】
ステップＳ７５５において、ＣＰＵ２０１は、確認要求をステップＳ７５４で取得した広域アドレスに送信する。
【０２９９】
ステップＳ７５６において、ＣＰＵ２０１は、ステップＳ７５５で送信した確認要求に対する応答であって、適正な確認応答を受信したか否かを判定する。このとき、確認応答に、ステップＳ７５１で生成した一時キーが含まれているか否かが判定され、上記の一時キーが含まれている場合、適正な確認応答を受信したと判定される。
【０３００】
ステップＳ７５６において、適正な確認応答を受信したと判定された場合、処理は、ステップＳ７５７に進む。一方、適正な確認応答を受信しなかったと判定された場合、処理は、ステップＳ７６０に進み、エラー処理が実行される。
【０３０１】
ステップＳ７５７において、ＣＰＵ２０１は、適正な確認応答を受信した時刻を、リンク認証の認証時刻として記録する。
【０３０２】
ステップＳ７５８において、ＣＰＵ２０１は、提供者側から評価情報が送信されたか否かを判定し、まだ送信されていないと判定された場合、ステップＳ７５９に進む。
【０３０３】
ステップＳ７５９において、ＣＰＵ２０１は、ステップＳ７５７で認証時刻が記録されてから、所定の時間が経過したか否かを判定し、所定の時間が経過したと判定されるまで待機する。ステップＳ７５９において、所定の時間が経過したと判定された場合、処理は、ステップＳ７５１に戻る。このようにすることで、一定の周期で継続して（定期的に）評価者の同一性が確認される。
【０３０４】
一方、ステップＳ７５８において、提供者側から評価情報が送信されたと判定された場合、ケース２処理は終了する。
【０３０５】
このようにして、ケース２の場合の方式別リンク認証処理が実行される。
【０３０６】
図１９と図２０は、ステップＳ７０４において、リンク認証の方式がケース３であると特定された場合、ステップＳ７０５の処理として実行されるケース３処理の例を説明するフローチャートである。
【０３０７】
ステップＳ７８１乃至ステップＳ７８８の処理は、図１７のステップＳ７２１乃至ステップＳ７２７およびステップＳ７３０と同様の処理なので、詳細な説明は省略する。
【０３０８】
ステップＳ７８９において、ＣＰＵ２０１は、乱数を生成（発生）する。
【０３０９】
ステップＳ７９０において、ＣＰＵ２０１は、端末機器データベース２２２を、提供者側（例えば、携帯端末４７）の識別番号を用いて検索することにより、提供者側の固有鍵を取得する。
【０３１０】
ステップＳ７９１において、ＣＰＵ２０１は、ステップＳ７９０で取得した固有鍵を用いて、ステップＳ７８９で生成した乱数を暗号化する。
【０３１１】
ステップＳ７９２において、ＣＰＵ２０１は、端末機器データベース２２２を、評価者側（例えば、携帯端末４６）の識別番号を用いて検索することにより、評価者側の広域通信アドレスを取得する。
【０３１２】
ステップＳ７９３において、ＣＰＵ２０１は、ステップＳ７９１で生成した暗号化乱数を確認要求として、ステップＳ７９２で取得した広域アドレスに送信する。
【０３１３】
ステップＳ７９４において、ＣＰＵ２０１は、ステップＳ７９３で送信した確認要求に対する応答であって、適正な確認応答を受信したか否かを判定する。このとき、確認応答に、ステップＳ７８９で生成した乱数が含まれているか否かが判定され、上記の乱数が含まれている場合、適正な確認応答を受信したと判定される。
【０３１４】
ステップＳ７９４において、適正な確認応答を受信したと判定された場合、処理は、ステップＳ７９５に進む。一方、適正な確認応答を受信しなかったと判定された場合、処理は、ステップＳ７９８に進み、エラー処理が実行される。
【０３１５】
ステップＳ７９５において、ＣＰＵ２０１は、適正な確認応答を受信した時刻を、リンク認証の認証時刻として記録する。
【０３１６】
ステップＳ７９６において、ＣＰＵ２０１は、提供者側から評価情報が送信されたか否かを判定し、まだ送信されていないと判定された場合、ステップＳ７９７に進む。
【０３１７】
ステップＳ７９７において、ＣＰＵ２０１は、ステップＳ７９５で認証時刻が記録されてから、所定の時間が経過したか否かを判定し、所定の時間が経過したと判定されるまで待機する。ステップＳ７９５において、所定の時間が経過したと判定された場合、処理は、ステップＳ７８１に戻る。このようにすることで、定期的に評価者の同一性と提供者の同一性が確認される。
【０３１８】
一方、ステップＳ７９６において、提供者側から評価情報が送信されたと判定された場合、ケース３処理は終了する。
【０３１９】
このようにして、ケース３の場合の方式別リンク認証処理が実行される。
【０３２０】
図２１と図２２は、ステップＳ７０４において、リンク認証の方式がケース４であると特定された場合、ステップＳ７０５の処理として実行されるケース４処理の例を説明するフローチャートである。
【０３２１】
ステップＳ８１１乃至ステップＳ８１８の処理は、図１８のステップＳ７５１乃至ステップＳ７５７およびステップＳ７６０の処理と同様の処理なので詳細な説明は省略する。
【０３２２】
ステップＳ８１９乃至ステップＳ８２８の処理は、図２０のステップＳ７８９乃至ステップＳ７９８の処理と同様の処理なので詳細な説明は省略する。
【０３２３】
このようにして、ケース４の場合の方式別リンク認証処理が実行される。
【０３２４】
図２３と図２４は、ステップＳ７０４において、リンク認証の方式がケース５であると特定された場合、ステップＳ７０５の処理として実行されるケース５処理の例を説明するフローチャートである。
【０３２５】
ステップＳ８３１乃至ステップＳ８３８の処理は、図２１のステップＳ８１１乃至ステップＳ８１８の処理と同様の処理なので詳細な説明は省略する。
【０３２６】
ステップＳ８３９において、ＣＰＵ２０１は、一時キーを生成する。
【０３２７】
ステップＳ８４０において、ＣＰＵ２０１は、端末機器データベース２２２を、提供者側（例えば、携帯端末４７）の識別番号を用いて検索することにより、提供者側の広域通信アドレスを取得する。
【０３２８】
ステップＳ８４１において、ＣＰＵ２０１は、ステップＳ８３９で生成した一時キーを、ステップＳ８４０で取得した広域アドレスに送信する。
【０３２９】
ステップＳ８４２において、ＣＰＵ２０１は、端末機器データベース２２２を、評価者側（例えば、携帯端末４６）の識別番号を用いて検索することにより、評価者側の広域通信アドレスを取得する。
【０３３０】
ステップＳ８４３において、ＣＰＵ２０１は、確認要求をステップＳ８４２で取得した広域アドレスに送信する。
【０３３１】
ステップＳ８４４において、ＣＰＵ２０１は、ステップＳ８４３で送信した確認要求に対する応答であって、適正な確認応答を受信したか否かを判定する。このとき、確認応答に、ステップＳ８３９で生成した一時キーが含まれているか否かが判定され、上記の一時キーが含まれている場合、適正な確認応答を受信したと判定される。
【０３３２】
ステップＳ８４４において、適正な確認応答を受信したと判定された場合、処理は、ステップＳ８４５に進む。一方、適正な確認応答を受信しなかったと判定された場合、処理は、ステップＳ８４８に進み、エラー処理が実行される。
【０３３３】
ステップＳ８４５において、ＣＰＵ２０１は、適正な確認応答を受信した時刻を、リンク認証の認証時刻として記録する。
【０３３４】
ステップＳ８４６において、ＣＰＵ２０１は、提供者側から評価情報が送信されたか否かを判定し、まだ送信されていないと判定された場合、ステップＳ８４７に進む。
【０３３５】
ステップＳ８４７において、ＣＰＵ２０１は、ステップＳ８４５で認証時刻が記録されてから、所定の時間が経過したか否かを判定し、所定の時間が経過したと判定されるまで待機する。ステップＳ８４７において、所定の時間が経過したと判定された場合、処理は、ステップＳ８３１に戻る。このようにすることで、定期的に評価者の同一性と提供者の同一性が確認される。
【０３３６】
一方、ステップＳ８４６において、提供者側から評価情報が送信されたと判定された場合、ケース５処理は終了する。
【０３３７】
このようにして、ケース５の場合の方式別リンク認証処理が実行される。
【０３３８】
このような方式別リンク認証処理を含む評価情報収集処理が実行される。
【０３３９】
次に、図２５のフローチャートを参照して、提供者側の端末機器（例えば、情報収集端末３１または携帯端末４７など）の処理の例について説明する。なお、この処理は、固有鍵を保持している提供者側の端末機器において実行される処理であり、この例では、提供者側端末機器は、楽曲などのコンテンツを提供するものとする。
【０３４０】
ステップＳ９０１において、情報収集端末または携帯端末のＣＰＵ１１１は、ハンドオーバがあったか否かを判定し、ハンドオーバがあったと判定されるまで待機する。
【０３４１】
ステップＳ９０２において、ＣＰＵ１１１は、広域通信によりサーバ２１にハンドオーバを通知する。このとき、ハンドオーバの通知とともに対向機器情報が送信される。
【０３４２】
ステップＳ９０３において、ＣＰＵ１１１は、広域通信による確認要求を受信したか否かを判定する。ステップＳ９０３において、確認要求を受信したと判定された場合、処理は、ステップＳ９０５に進み、確認要求を受信していないと判定された場合、処理は、ステップＳ９０４に進む。
【０３４３】
ここで、図２６のフローチャートを参照して、図２５のステップＳ９０４のコンテンツ提供処理の例について説明する。
【０３４４】
ステップＳ９２１において、ＣＰＵ１１１は、近距離無線通信により評価者側にコンテンツのデータを送信する。
【０３４５】
ステップＳ９２２において、ＣＰＵ１１１は、近距離無線通信により評価者側から評価情報を受信する。
【０３４６】
ステップＳ９２３において、ＣＰＵ１１１は、ステップＳ９２１の処理によって所定のデータ量を送信したか否かを判定し、まだ、所定のデータ量を送信していないと判定された場合、処理は、ステップＳ９２１に戻る。一方、所定のデータ量を送信したと判定された場合、処理は、図２６のステップＳ９０６に進む。
【０３４７】
ここで、図２７のフローチャートを参照して、図２５のステップＳ９０５のリンク認証確認処理の例について説明する。
【０３４８】
ステップＳ９４１において、ＣＰＵ１１１は、ステップＳ９０３において受信したと判定された確認要求を、近距離無線通信により評価者側に送信する。
【０３４９】
ステップＳ９４２において、ＣＰＵ１１１は、ステップＳ９４１で送信した確認要求に対する確認応答を、近距離無線通信により受信したか否かを判定し、確認応答を受信したと判定されるまで待機する。ステップＳ９４２において、確認応答を受信したと判定された場合、処理は、ステップＳ９４３に進む。
【０３５０】
ステップＳ９４３において、ＣＰＵ１１１は、ステップＳ９４２で受信したと判定された確認応答を、広域通信によりサーバ２１に送信する。
【０３５１】
ステップＳ９４４において、ＣＰＵ１１１は、近距離無線通信により確認要求を受信したか否かを判定し、確認要求を受信したと判定されるまで待機する。ステップＳ９４４において、確認要求を受信したと判定された場合、処理は、ステップＳ９４５に進む。
【０３５２】
ステップＳ９４５において、ＣＰＵ１１１は、ステップＳ９４４で受信したと判定された確認要求に含まれる暗号化乱数を、自分の固有鍵を用いて復号する。
【０３５３】
ステップＳ９４６において、ＣＰＵ１１１は、ステップＳ９４５で復号して得られた乱数を確認応答として近距離無線通信により評価者側に送信する。
【０３５４】
このようにして、リンク確認処理が実行される。
【０３５５】
図２５に戻って、ステップＳ９０４またはステップＳ９０５の処理の後、処理は、ステップＳ９０６に進み、ＣＰＵ１１１は、コンテンツの提供が終了したか否かを判定する。例えば、評価者によりコンテンツの再生の停止が指令された場合、ステップＳ９０６では、コンテンツの提供が終了したと判定される。ステップＳ９０６において、まだ終了していないと判定された場合、処理は、ステップＳ９０３に戻る。
【０３５６】
ステップＳ９０６において、コンテンツの提供が終了したと判定された場合、処理は、ステップＳ９０７に進む。
【０３５７】
ステップＳ９０７において、ＣＰＵ１１１は、ステップＳ９０４の処理において受信した評価情報を、広域通信によりサーバ２１に送信する。
【０３５８】
このようにして、提供者側端末機器の処理が実行される。
【０３５９】
次に、図２８のフローチャートを参照して、提供者側の端末機器の処理の別の例について説明する。なお、この処理は、固有鍵を保持していない提供者側の端末機器において実行される処理であり、この例では、提供者側端末機器は、楽曲などのコンテンツを提供するものとする。
【０３６０】
ステップＳ９６１において、情報収集端末または携帯端末のＣＰＵ１１１は、ハンドオーバがあったか否かを判定し、ハンドオーバがあったと判定されるまで待機する。
【０３６１】
ステップＳ９６２において、ＣＰＵ１１１は、広域通信によりサーバ２１にハンドオーバを通知する。このとき、ハンドオーバの通知とともに対向機器情報が送信される。
【０３６２】
ステップＳ９６３において、ＣＰＵ１１１は、広域通信による確認要求または一時キーを受信したか否かを判定する。ステップＳ９６３において、確認要求または一時キーを受信したと判定された場合、処理は、ステップＳ９６５に進み、確認要求を受信していないと判定された場合、処理は、ステップＳ９６４に進む。
【０３６３】
ここで、図２９のフローチャートを参照して、図２８のステップＳ９６５のリンク認証確認処理の例について説明する。
【０３６４】
ステップＳ９８１において、ＣＰＵ１１１は、ステップＳ９６３で受信したと判定されたのは、確認要求であるか否かを判定する。確認要求であると判定された場合、処理は、ステップＳ９８２に進む。
【０３６５】
ステップＳ９８２において、ＣＰＵ１１１は、ステップＳ９６３において受信したと判定された確認要求を、近距離無線通信により評価者側に送信する。
【０３６６】
ステップＳ９８３において、ＣＰＵ１１１は、ステップＳ９８２で送信した確認要求に対する確認応答を、近距離無線通信により受信したか否かを判定し、確認応答を受信したと判定されるまで待機する。ステップＳ９８３において、確認応答を受信したと判定された場合、処理は、ステップＳ９８４に進む。
【０３６７】
ステップＳ９８４において、ＣＰＵ１１１は、ステップＳ９８３で受信したと判定された確認応答を、広域通信によりサーバ２１に送信する。
【０３６８】
一方、ステップＳ９８１において、ステップＳ９６３で受信したと判定されたのは、確認要求ではないと判定された場合、処理は、ステップＳ９８８に進む。なお、この場合、一時キーが受信されたことになる。
【０３６９】
ステップＳ９８８において、ＣＰＵ１１１は、ステップＳ９６３で受信したと判定された一時キーを記憶する。
【０３７０】
ステップＳ９８４またはステップＳ９８８の処理の後、処理は、ステップＳ９８５に進む。
【０３７１】
ステップＳ９８５において、ＣＰＵ１１１は、近距離無線通信により確認要求を受信したか否かを判定し、確認要求を受信したと判定されるまで待機する。ステップＳ９８５において、確認要求を受信したと判定された場合、処理は、ステップＳ９８６に進む。
【０３７２】
ステップＳ９８６において、ＣＰＵ１１１は、ステップＳ９８８で記憶した一時キーを読み出す。
【０３７３】
ステップＳ９８７において、ＣＰＵ１１１は、ステップＳ９８６で読み出した一時キーを確認応答として近距離無線通信により評価者側に送信する。
【０３７４】
このようにして、リンク認証確認処理が実行される。
【０３７５】
なお、図２８のステップＳ９６４のコンテンツ提供処理は、図２６を参照して上述した処理と同様の処理なので詳細な説明は省略する。また、図２８のステップＳ９６６とステップＳ９６７の処理は、それぞれ図２５のステップＳ９０６とステップＳ９０７の処理と同様の処理なので詳細な説明は省略する。
【０３７６】
このようにして、提供者側端末機器の処理が実行される。
【０３７７】
次に、図３０のフローチャートを参照して、評価者側の端末機器（例えば、携帯端末４１または携帯端末４６など）の処理の例について説明する。なお、この処理は、固有鍵を保持している評価者側の端末機器において実行される処理であり、この例では、提供者側端末機器により、楽曲などのコンテンツの提供を受けて、そのコンテンツを評価するものとする。
【０３７８】
ステップＳ１００１において、携帯端末のＣＰＵ１１１は、ハンドオーバがあったか否かを判定し、ハンドオーバがあったと判定されるまで待機する。
【０３７９】
ステップＳ１００２において、ＣＰＵ１１１は、広域通信によりサーバ２１にハンドオーバを通知する。このとき、ハンドオーバの通知とともに対向機器情報が送信される。なお、ステップＳ１００２の処理は、省略されるようにしてもよい。
【０３８０】
ステップＳ１００３において、ＣＰＵ１１１は、広域通信による確認要求を受信したか否かを判定する。ステップＳ１００３において、確認要求を受信したと判定された場合、処理は、ステップＳ１００４に進む。
【０３８１】
ここで、図３１のフローチャートを参照して、図３０のステップＳ１００４の第１リンク認証処理の例について説明する。
【０３８２】
ステップＳ１０２１において、ＣＰＵ１１１は、ステップＳ１００３において受信したと判定された確認要求を、近距離無線通信により提供者側に送信する。
【０３８３】
ステップＳ１０２２において、ＣＰＵ１１１は、ステップＳ１０２１で送信した確認要求に対する確認応答を、近距離無線通信により受信したか否かを判定し、確認応答を受信したと判定されるまで待機する。ステップＳ１０２２において、確認応答を受信したと判定された場合、処理は、ステップＳ１０２３に進む。
【０３８４】
ステップＳ１０２３において、ＣＰＵ１１１は、ステップＳ１０２２で受信したと判定された確認応答を、広域通信によりサーバ２１に送信する。
【０３８５】
このようにして、第１リンク認証処理が実行される。
【０３８６】
図３０に戻って、ステップＳ１００４の処理の後、または、ステップＳ１００３において、確認要求を受信していないと判定された場合、処理は、ステップＳ１００５に進む。
【０３８７】
ステップＳ１００５において、ＣＰＵ１１１は、近距離無線通信による確認要求を受信したか否かを判定する。ステップＳ１００５において、確認要求を受信したと判定された場合、処理は、ステップＳ１００７に進む。
【０３８８】
ここで、図３２のフローチャートを参照して、図３０のステップＳ１００７の第２リンク認証処理の例について説明する。
【０３８９】
ステップＳ１０４１において、ＣＰＵ１１１は、ステップＳ１００５で受信したと判定された確認要求に含まれる暗号化乱数を、自分の固有鍵を用いて復号する。
【０３９０】
ステップＳ１０４２において、ＣＰＵ１１１は、ステップＳ１０４１で復号して得られた乱数を確認応答として近距離無線通信により提供者側に送信する。
【０３９１】
このようにして、第２リンク確認処理が実行される。
【０３９２】
図３０に戻って、一方、ステップＳ１００５において、確認要求を受信していないと判定された場合、処理は、ステップＳ１００６に進む。
【０３９３】
ここで、図３３のフローチャートを参照して、図３０のステップＳ１００６のコンテンツ評価処理の例について説明する。
【０３９４】
ステップＳ１０６１において、ＣＰＵ１１１は、提供者側から近距離無線通信によりデータを受信する。
【０３９５】
ステップＳ１０６２において、ＣＰＵ１１１は、近距離無線通信により評価情報を提供者側に送信する。
【０３９６】
ステップＳ１０６３において、ＣＰＵ１１１は、ステップＳ１０６１の処理によって所定のデータ量を送信したか否かを判定し、まだ、所定のデータ量を送信していないと判定された場合、処理は、ステップＳ１０６１に戻る。一方、所定のデータ量を送信したと判定された場合、処理は、図３０のステップＳ１００８に進む。
【０３９７】
このようにして、コンテンツ評価処理が実行される。
【０３９８】
図３０に戻って、ステップＳ１００６またはステップＳ１００７の処理の後、処理は、ステップＳ１００８に進む。
【０３９９】
ステップＳ１００８において、ＣＰＵ１１１は、提供者側から提供を受けているコンテンツの評価が終了したか否かを判定し、まだ終了していないと判定された場合、処理は、ステップＳ１００３に戻る。
【０４００】
一方、ステップＳ１００８において、コンテンツの評価が終了したと判定された場合、処理は終了する。
【０４０１】
このようにして、評価者側端末機器の処理が実行される。
【０４０２】
次に、図３４のフローチャートを参照して、評価者側の端末機器の処理の別の例について説明する。なお、この処理は、固有鍵を保持していない評価者側の端末機器において実行される処理であり、この例では、提供者側端末機器により、楽曲などのコンテンツの提供を受けて、そのコンテンツを評価するものとする。
【０４０３】
ステップＳ１０８１において、携帯端末のＣＰＵ１１１は、ハンドオーバがあったか否かを判定し、ハンドオーバがあったと判定されるまで待機する。
【０４０４】
ステップＳ１０８２において、ＣＰＵ１１１は、広域通信によりサーバ２１にハンドオーバを通知する。このとき、ハンドオーバの通知とともに対向機器情報が送信される。なお、ステップＳ１０８２の処理は、省略されるようにしてもよい。
【０４０５】
ステップＳ１０８３において、ＣＰＵ１１１は、広域通信による確認要求を受信したか否かを判定する。ステップＳ１０８３において、確認要求を受信したと判定された場合、処理は、ステップＳ１０８４に進む。
【０４０６】
ここで、図３５のフローチャートを参照して、図３４のステップＳ１０８４の第３リンク認証処理の例について説明する。
【０４０７】
ステップＳ２００１において、ＣＰＵ１１１は、ステップＳ１０８３で受信したと判定されたのは、確認要求であるか否かを判定する。確認要求であると判定された場合、処理は、ステップＳ２００２に進む。
【０４０８】
ステップＳ２００２において、ＣＰＵ１１１は、ステップＳ１０８３において受信したと判定された確認要求を、近距離無線通信により提供者側に送信する。
【０４０９】
ステップＳ２００３において、ＣＰＵ１１１は、ステップＳ２００２で送信した確認要求に対する確認応答を、近距離無線通信により受信したか否かを判定し、確認応答を受信したと判定されるまで待機する。ステップＳ２００３において、確認応答を受信したと判定された場合、処理は、ステップＳ２００４に進む。
【０４１０】
ステップＳ２００４において、ＣＰＵ１１１は、ステップＳ２００３で受信したと判定された確認応答を、広域通信によりサーバ２１に送信する。
【０４１１】
一方、ステップ２００１において、ステップＳ１０８３で受信したと判定されたのは、確認要求ではないと判定された場合、処理は、ステップＳ２００５に進む。なお、この場合、一時キーが受信されたことになる。
【０４１２】
ステップＳ２００５において、ＣＰＵ１１１は、ステップＳ１０８３で受信したと判定された一時キーを記憶する。
【０４１３】
このようにして、第３リンク認証処理が実行される。
【０４１４】
図３４に戻って、ステップＳ１０８４の処理の後、または、ステップＳ１０８３において、広域通信による確認要求を受信していないと判定された場合、処理は、ステップＳ１０８５に進む。
【０４１５】
ステップＳ１０８５において、ＣＰＵ１１１は、近距離無線通信による確認要求を受信したか否かを判定する。ステップＳ１０８５において、確認要求を受信したと判定された場合、処理は、ステップＳ１０８７に進む。
【０４１６】
ここで、図３６のフローチャートを参照して、図３４のステップＳ１０８７の第４リンク認証処理の例について説明する。
【０４１７】
ステップＳ２０２１において、ＣＰＵ１１１は、ステップＳ２００５で記憶した一時キーを読み出す。
【０４１８】
ステップＳ２０２２において、ＣＰＵ１１１は、ステップＳ２０２１で読み出した一時キーを確認応答として近距離無線通信により評価者側に送信する。
【０４１９】
このようにして、第４リンク認証確認処理が実行される。
【０４２０】
図３４に戻って、一方、ステップＳ１０８５において、確認要求を受信していないと判定された場合、処理は、ステップＳ１０８６に進む。ステップＳ１０８６のコンテンツ評価処理は、図３３のフローチャートを参照して上述した処理と同様の処理なので詳細な説明は省略する。
【０４２１】
ステップＳ１０８６またはステップＳ１０８７の処理の後、処理は、ステップＳ１０８８に進む。
【０４２２】
ステップＳ１０８８において、ＣＰＵ１１１は、提供者側から提供を受けているコンテンツの評価が終了したか否かを判定し、まだ終了していないと判定された場合、処理は、ステップＳ１０８３に戻る。
【０４２３】
一方、ステップＳ１０８８において、コンテンツの評価が終了したと判定された場合、処理は終了する。
【０４２４】
このようにして、評価者側端末機器の処理が実行される。
【０４２５】
ところで、以上においては主に、いわゆる口コミ情報のように商品やサービスの利用の際に参考にすべき情報として、評価情報を収集する例について説明したが、これとは異なる観点で情報を収集するようにしてもよい。
【０４２６】
図３７は、本発明の別の実施の形態を説明する図である。同図の例は、各端末機器のコンテンツの提供に係る実績に基づいてコンテンツを配信するためのコンテンツ配信システム１１の構成例を示している。
【０４２７】
この例では、コンテンツ配信システム１１がサーバ２２、携帯端末５１乃至携帯端末５３、および、携帯端末５５乃至携帯端末５７により構成されている。この例では、携帯端末５１と携帯端末５５に対してコンテンツが送信（配信）されている。
【０４２８】
そして、携帯端末５１から携帯端末５２と携帯端末５３に対してコンテンツの提供が行われている。また、携帯端末５５から携帯端末５６と携帯端末５７に対してコンテンツの提供が行われている。なお、携帯端末５２、携帯端末５３、携帯端末５６、携帯端末５７のそれぞれが、楽曲のコンテンツなどをストリーミング再生することにより、それらの携帯端末に対するコンテンツの提供が行われることになる。
【０４２９】
サーバ２２は、例えば、実績情報収集事業者のデータセンタに設置され、携帯端末５１、または携帯端末５５から送信される実績情報を取得し、取得した実績情報の保存、加工などの処理を行うようになされている。サーバ２２は、例えば、取得した実績情報に基づいて、携帯端末５１、または携帯端末５５にコンテンツの配信を行うようになされている。
【０４３０】
なお、サーバ２２についても図４を参照して上述した構成が適用される。
【０４３１】
ここでは、携帯電話機のハンドオーバを利用してコンテンツを次々に提供する方式を想定する。例えば、あるアーティストのプロモーションとしてリリース直後の新曲を、ファンクラブの会員の携帯電話機に配信する場合などを想定する。
【０４３２】
リリース直後の新曲のコンテンツは、ファンクラブの会員である携帯端末５１のユーザと携帯端末５５のユーザに配信される。このとき、例えば、携帯端末５１と携帯端末５５は、それぞれコンテンツのデータをサーバ２２からダウンロードし、記憶部１２３などに記憶する。
【０４３３】
そして、携帯端末５１のユーザは、友人の携帯端末５２と携帯端末５１との間でハンドオーバを行い、近距離無線通信を利用して携帯端末５２によるコンテンツのストリーミング再生を行わせる。また、別の友人の携帯端末５３と携帯端末５１との間でハンドオーバを行い、近距離無線通信を利用して携帯端末５３によるコンテンツのストリーミング再生を行わせる。
【０４３４】
携帯端末５５のユーザも同様にして、友人の携帯端末５６と携帯端末５７によるコンテンツのストリーミング再生を行わせる。
【０４３５】
なお、携帯端末５２または携帯端末５３が、携帯端末５１からコンテンツをダウンロードするようにしてもよいが、ここでは、コンテンツのストリーミング再生のみが行われるものとする。
【０４３６】
また、ここでは、ファンクラブの会員であるユーザの携帯端末として携帯端末５１と携帯端末５５のみが記載されているが、実際にはもっと多くの会員がそれぞれ携帯端末を保有している。さらに、ここでは、各会員がそれぞれ２人の友人にコンテンツを提供する例について説明したが、会員毎にコンテンツを提供する相手の人数が異なる。
【０４３７】
このように、コンテンツ配信システム１１においては、ファンクラブの会員から次々とコンテンツが提供されていくようになされている。また、このようにしてコンテンツの提供を受けたユーザのうち幾人かは、実際にその楽曲のコンテンツを購入してダウンロードしたり、新たにファンクラブの会員になったりする。
【０４３８】
また、コンテンツ配信システム１１においては、携帯端末５１と携帯端末５５から実績情報が送信されるようになされている。実績情報は、例えば、携帯端末５１と携帯端末５５がそれぞれ誰にコンテンツを提供したかを表す情報とされる。
【０４３９】
図３８は、実績情報の例を示す図である。同図は、例えば、携帯端末５１からサーバ２２へ送信される実績情報とされ、この例では、「コンテンツ提供先」に係る情報と「詳細」に係る情報により実績情報が構成されている。
【０４４０】
「コンテンツ提供先」に係る情報には、「ユーザＩＤ」と「ユーザ属性」が含まれている。「ユーザＩＤ」はユーザを特定する識別情報とされる。この例では、「Ａ０１０００１」と「Ｂ０２０００３」とが記述されており、これらが、携帯端末５２と携帯端末５３のユーザの識別情報とされる。なお、ユーザＩＤは、コンテンツ配信システム１１内において各ユーザを一意に特定できるように、予め定められた採番ルールなどに即して各ユーザに割り当てられているものとする。
【０４４１】
図３８の「ユーザ属性」は、「年齢」、「性別」、「住所」、および「趣向」により構成されており、これらは、それぞれ「ユーザＩＤ」により特定されるユーザの「年齢」、「性別」、「住所」、および「趣向」を表す情報が記述される。なお、「趣向」としては、例えば、「スポーツ観戦」、「読書」、・・・などそのユーザの趣味を表す情報が記述されるようにしてもよいし、例えば、「ロック」、「ジャズ」、・・・など楽曲のコンテンツに特化した嗜好を表す情報が記述されるようにしてもよい。
【０４４２】
また、実績情報における「ユーザＩＤ」および「ユーザ属性」に記述される情報は、後述するようにハンドオーバメッセージに含められるようになされており、例えば、携帯端末５１と、携帯端末５２または携帯端末５３との間でハンドオーバが行われるとき取得される。
【０４４３】
「詳細」に係る情報には、「提供開始日時」、「提供終了日時」、「コンテンツＩＤ」、および「証明書」が含まれている。「提供開始日時」および「提供終了日時」は、それぞれ「ユーザＩＤ」により特定されるユーザに対してコンテンツの提供を開始した時刻、およびコンテンツの提供を終了した時刻を表す情報とされる。
【０４４４】
「コンテンツＩＤ」は、提供したコンテンツを特定する情報とされる。
【０４４５】
「証明書」は、例えば、携帯端末５２または携帯端末５３に実装されるアプリケーションプログラムによりユーザＩＤ「Ａ０１０００１」とユーザＩＤ「Ｂ０２０００３」のユーザを認証した結果発行される証明書とされる。なお、後述するように、リンク認証の結果を「証明書」に含めるようにしてもよい。
【０４４６】
携帯端末５２または携帯端末５３において、コンテンツをストリーミング再生する際には、予めコンテンツ再生用のアプリケーションプログラムにログオンする必要があり、例えば、ログオン時にパスワードを入力することにより、ユーザが認証されるようになされている。例えば、当該アプリケーションプログラムの開発を行うソフトウェア会社は、秘密鍵と公開鍵を保有しており、秘密鍵は、アプリケーションプログラムとともに携帯端末に実装されている。
【０４４７】
コンテンツ再生用のアプリケーションプログラムは、予め登録されたパスワードと一致するパスワードの入力を受け付けた場合、当該ユーザのユーザＩＤに所定の演算を施して得られた値を自分の秘密鍵で暗号化した証明書を生成するようになされている。
【０４４８】
携帯端末５１から当該実績情報が送信された場合、サーバ２２において、公開鍵を用いて証明書を復号することにより、結果としてサーバ２２は、ユーザを認証することが可能になる。例えば、アーティストのプロモーションとしてリリース直後の新曲のコンテンツを配信する場合、コンテンツの提供は携帯端末を通じてユーザに視聴してもらうことに意味がある。このため、各携帯端末におけるユーザの認証結果を証明書として付加することにより、より信頼性の高い実績情報を生成することができる。
【０４４９】
なお、上述した証明書の生成は一例であり、別の方式により証明書が生成されるようにしても構わない。また、実績情報には、必ずしも証明書が必要であるわけではなく、例えば、携帯端末５２または携帯端末５３においてユーザの認証を行うことができない場合、実績情報における「証明書」には、ユーザ認証がなされていない旨の情報が記述されるようにしてもよい。
【０４５０】
実績情報の「証明書」には、当該証明書の種類を特定する情報が、その証明書を構成する数値などからなる情報とともに格納されるものとする。従って、実績情報を受信したサーバ２２は、当該実績情報に、アプリケーションプログラムによるユーザ認証の結果が含まれているのか否か、または後述のようにリンク認証の結果が含まれているのか否かを認識することができるようになされている。
【０４５１】
サーバ２２では、このように構成される実績情報を携帯端末５１と携帯端末５５から受信する。そして、サーバ２２は、実績情報を解析して、携帯端末５１と携帯端末５５とがいつ誰にコンテンツを提供したかを特定し、例えば、単位時間内により多くのユーザにコンテンツを提供した携帯端末を特定する。
【０４５２】
このように、サーバ２２は、実績情報を解析して、例えば、コンテンツの提供実績の高い携帯電端末を特定するのである。ここでいう、提供実績が高いとは、例えば、単位時間内により多くのユーザにコンテンツを提供したことを意味するものとしてもよいし、プロモーションのターゲットとなる年齢、性別、住所、趣向のユーザにコンテンツを提供したことを意味するものとしてもよい。例えば、プロモーションにおいて、若年者のファン獲得を目標としている場合、「コンテンツ提供先」に係る情報の中の「年齢」により実績情報をフィルタリングして、閾値未満の年齢のユーザにより多くコンテンツを提供した携帯端末の提供実績が高いものとされる。
【０４５３】
さらに、実績情報の解析においては、実績情報の「証明書」に、アプリケーションプログラムによるユーザ認証の結果が含まれているのか否か、またはリンク認証の結果が含まれているのか否かが判定されるとともに、その証明書の有効性が判定されるようにしてもよい。ここで、証明書の有効性は、例えば、ユーザ認証の結果とともにリンク認証の結果が含まれている場合に有効と判定したり、証明書の作成日時などが所定の基準を満たすものである場合に有効と判定するなどして得られるものとする。
【０４５４】
そして、証明書に含まれる情報の内容（ユーザ認証の結果、リンク認証の結果、またはそれらの両方）とその有効性に基づいて実績情報がフィルタリングされるようにしてもよい。このようにすることで、実績情報にどの程度の信頼性を求めるべきかを考慮してコンテンツの提供実績の高い携帯電端末を特定することが可能となる。
【０４５５】
サーバ２２は、このようにして特定された提供実績の高い携帯端末に対して、例えば、次回の新曲のコンテンツを優先的に配信するようにする。例えば、サーバ２２が、携帯端末５１の提供実績が高いと判断した場合、携帯端末５１に対しては次回の新曲のコンテンツを無料でダウンロードさせるようにする。あるいはまた、予め設定された基準より高い提供実績が確認された複数の携帯端末に次回の新曲のコンテンツを無料でダウンロードさせるようにしてもよいし、提供実績の高い順に、時間差を付けて新曲のコンテンツを無料でダウンロードさせるようにしてもよい。
【０４５６】
あるいはまた、提供実績の高い携帯端末にコンサートのチケットなどの優待特典を付与するようにしてもよい。
【０４５７】
このようにすることで、例えば、コンテンツの販売促進を図ることが可能となり、コンテンツを提供するレコード会社などにとって、より効率的なコンテンツの配信を実現することが可能となるのである。
【０４５８】
本発明のコンテンツ配信システム１１においては、上述した実績情報の収集ができるようにする。そのために、ハンドオーバメッセージに次のような情報を含めるようにする。
【０４５９】
図３９は、ハンドオーバメッセージのフォーマットを説明する図である。図１４を参照して上述した通り、ハンドオーバメッセージは、例えば、携帯端末や情報収集端末が非接触通信（ＮＦＣ通信）を行うときに送受信される情報とされる。ハンドオーバメッセージのフォーファットについては、ＮＦＣＦｏｒｕｍによる標準化が行われており、図示されるフォーマットがＮＦＣＦｏｒｕｍの規格によって規定されている。
【０４６０】
同図の「Ｒｅｃｏｒｄ１」乃至「Ｒｅｃｏｒｄ４」は、図１４を参照して上述したものと同様なので、詳細な説明は省略する。
【０４６１】
「Ｒｅｃｏｒｄ５」は、「Ｒｅｃｏｒｄ４」と同様に、携帯端末などの製造事業者によって定義された情報が格納されるレコードとされる。本発明では、「Ｒｅｃｏｒｄ５」に含まれる情報として図示されるようなパケットの情報を定義する。
【０４６２】
同図に示されるように、「Ｒｅｃｏｒｄ５」には、ヘッダとペイロードからなるパケットが格納される。
【０４６３】
ヘッダには、「ＲｅｃｏｒｄＴｙｐｅ」の情報が記述され、いまの場合、レコード５が実績情報収集のために用いられる情報が格納されるレコードであることを表す情報が記述される。
【０４６４】
ペイロードは、「ユーザＩＤ」、「ユーザ属性」、「ユーザ認証方式」および「ユーザ認証情報」によって構成されている。
【０４６５】
「ユーザＩＤ」および「ユーザ属性」は、図３８を参照して上述した実績情報における「ユーザＩＤ」および「ユーザ属性」と同様のものである。
【０４６６】
「ユーザ認証方式」は、「ユーザ認証情報」に係る認証方式を特定するための情報とされる。
【０４６７】
上述したように、携帯端末５２または携帯端末５３において、ユーザ認証がなされる場合を考える。例えば、携帯端末５２などでコンテンツをストリーミング再生する際には、予めコンテンツ再生用のアプリケーションプログラムにログオンする必要があり、ログオン時にパスワードを入力することにより、ユーザが認証されるものとする。この場合、ユーザＩＤに所定の演算を施して得られた値を当該アプリケーションプログラムの開発を行うソフトウェア会社の秘密鍵で暗号化して証明書が生成される。
【０４６８】
このような場合、例えば、「ユーザ認証方式」には、上述のユーザＩＤに施す所定の演算を表す情報、および当該ソフトウェア会社を特定する情報などが格納され、「ユーザ認証情報」には、上述の証明書が格納されることになる。
【０４６９】
また、例えば、携帯端末５２または携帯端末５３においてユーザの認証を行うことができない場合、「ユーザ認証方式」には、ユーザ認証がなされていない旨を表す情報などが格納され、「ユーザ認証情報」には空の情報が格納されることになる。
【０４７０】
携帯端末５１は、このようにハンドオーバメッセージの「Ｒｅｃｏｒｄ５」に記述された情報に基づいて、上述の実績情報を生成し、サーバ２２に送信するのである。
【０４７１】
ここで、実績情報の信頼性をさらに高めたい場合、上述したリンク認証を行い、リンク認証の結果を証明書に含めるようにすることが可能である。すなわち、実績情報が偽造されたものではないことを証明するための情報としてリンク認証の結果を付加することが可能である。
【０４７２】
例えば、図３７のサーバ２２が、図１のサーバ２１と同様にリンク認証を行うことが可能である場合、サーバ２２がリンク認証の証明書を生成する。この場合、サーバ２２は、提供者側（例えば、携帯端末５１）と利用者側（例えば、携帯端末５２または携帯端末５３）との間で行われる通信について図１６を参照して上述した処理と同様にしてリンク認証を行う。
【０４７３】
そして、サーバ２２は、携帯端末５１から携帯端末５２または携帯端末５３に対するコンテンツの提供が完了するまでの間リンク認証が行われたことを表す情報を暗号化するなどして証明書を生成する。例えば、携帯端末５２または携帯端末５３のユーザのユーザＩＤとリンク認証の時刻を組み合わせて得られる値などを、サーバ２２の固有鍵で暗号して得られた情報が証明書とされる。サーバ２２は、コンテンツの提供の終了時に携帯端末５１に暗号化された証明書を送信する。
【０４７４】
サーバ２２は、携帯端末５１から送信される実績情報の「証明書」に格納された情報を自分の固有鍵で復号する。これにより、サーバ２２は、携帯端末５２または携帯端末５３のユーザのユーザＩＤ、およびリンク認証の時刻を得て、実績情報の内容と突合することで、実績情報が偽造などされていないことを確認することができる。
【０４７５】
あるいはまた、図３７のサーバ２２が、図１のサーバ２１と同様にリンク認証を行うことができない場合、サーバ２１が上述のようにリンク認証の証明書を生成する。この際、サーバ２１が、秘密鍵と公開鍵を保有しているものとする。
【０４７６】
いまの場合、例えば、携帯端末５２または携帯端末５３のユーザのユーザＩＤとリンク認証の時刻を組み合わせて得られる値などを、サーバ２１の秘密鍵で暗号して得られた情報が証明書とされる。サーバ２１は、コンテンツの提供の終了時に携帯端末５１に暗号化された証明書を送信する。
【０４７７】
サーバ２２は、携帯端末５１から送信される実績情報の「証明書」に格納された情報をサーバ２１の公開鍵で復号する。これにより、サーバ２２は、携帯端末５２または携帯端末５３のユーザのユーザＩＤ、およびリンク認証の時刻を得て、実績情報の内容と突合することで、実績情報が偽造などされていないことを確認することができる。
【０４７８】
上述された証明書そのものを暗号化する方法以外にも、その内容文と秘密鍵（または固有鍵）をハッシュ関数に入力し、その出力値をデジタル署名として証明書に付加する方法も選択し得る。その場合、サーバ２２は、その携帯端末などに対応する公開鍵（または固有鍵）を用いて署名を検証することで、証明書内に偽造があった場合には検出することができる。
【０４７９】
このように、リンク認証の結果を証明書に含めることで、実績情報の信頼性をさらに高めることができる。
【０４８０】
また、上述のようにして得られた実績情報は、コンテンツの効率的な配信に用いられるのみでなく、様々な活用が可能である。
【０４８１】
例えば、図４０に示されるように、あるユーザの携帯端末から他のユーザの携帯端末にコンテンツが次々とダウンロードされていくコンテンツ配信システム１２を想定する。図４０の例では、携帯端末６１と携帯端末６５がサーバ２３からコンテンツのデータをダウンロードしている。
【０４８２】
なお、サーバ２３にも図４を参照して上述した構成が適用される。
【０４８３】
また、携帯端末６２と携帯端末６６は、それぞれ携帯端末６１と携帯端末６５からコンテンツをダウンロードしている。さらに、携帯端末６３と携帯端末６７は、それぞれ携帯端末６２と携帯端末６６からコンテンツをダウンロードしている。
【０４８４】
そして、携帯端末６１、携帯端末６２、携帯端末６５、および携帯端末６６がサーバ２３に実績情報を送信している。
【０４８５】
このようなコンテンツ配信システム１２において、コンテンツを提供する際に中核となるユーザを実績情報に基づいて特定することも可能である。
【０４８６】
サーバ２３では、実績情報に基づいて各携帯端末がどの携帯端末にコンテンツを提供したのかを認識することができる。図４１は、実績情報における各携帯端末をノードとして作成されたネットワークマップの例を示す図である。同図に円で示されるものがノードを表しており、より多数のノードと接続されているノードがより径の大きい円として示されている。
【０４８７】
多数の携帯端末にコンテンツを提供した携帯端末は、コンテンツ配信システム１２において重要度の高い携帯端末であり、例えば、その携帯端末のユーザによるコンテンツの評価は、コンテンツの販売に多大な影響があると考えられる。そこで、サーバ２３では、実績情報に基づいて中核となるユーザを特定する。
【０４８８】
サーバ２３は、単に最も多くの携帯端末にコンテンツを提供した携帯端末のユーザを中核となるユーザとして決定するようにしてもよいが、実績情報に基づいてより実効的に中核となるユーザを特定することも可能となる。
【０４８９】
例えば、サーバ２３は、当該ユーザがコンテンツを提供したユーザの人数に応じた評価値を演算し、評価値を比較することにより、中核となるユーザを特定する。この際、次に示すような重み付けを行って評価値を演算するようする。
【０４９０】
例えば、サーバ２３は、実績情報の「ユーザＩＤ」に基づいて個々の携帯端末が何人のユーザにコンテンツを提供したかを表す情報を取得する。そして、サーバ２３は、例えば、実績情報の「コンテンツＩＤ」に基づいて、提供したコンテンツの種類やジャンルなどを特定し、その特定結果に基づいてコンテンツを提供したユーザの重み付けを行う。
【０４９１】
これにより、例えば、楽曲のコンテンツについて中核となるユーザを特定したり、ゲームのコンテンツについて中核となるユーザを特定したりすることが可能となる。
【０４９２】
また、サーバ２３は、例えば、実績情報の「提供開始日時」または「提供終了日時」に基づいて、コンテンツを提供したユーザの重み付けを行う。例えば、より最近にコンテンツを提供したユーザについてより大きい重みづけがなされるようにする。
【０４９３】
このようにすることで、実績情報の鮮度を考慮して中核となるユーザを特定することが可能となる。
【０４９４】
サーバ２３は、例えば、サーバ２１から評価情報の提供を受けてさらにユーザの重み付けを行うようにしてもよい。例えば、サーバ２３は、実績情報のユーザＩＤに基づいて、そのユーザの携帯端末の識別情報を取得できるものとする。サーバ２３は、携帯端末の識別情報に基づいて、サーバ２１から評価情報を取得する。そして、例えば、より長いコメントの評価情報が得られた携帯端末のユーザについてより大きい重みづけがなされるようにする。
【０４９５】
このようにすることで、例えば、そのコンテンツに興味をもったユーザにコンテンツを提供しているか否かを考慮して、中核となるユーザを特定することが可能となる。
【０４９６】
サーバ２３は、例えば、このようにして各携帯端末のユーザの評価値を算出する。第ｎ番目のユーザＵｓｅｒ_nの評価値をＶ（Ｕｓｅｒ_n）で表わした場合、このユーザの評価値は、式（１）により演算される。
【０４９７】
【数１】

【０４９８】
式（１）において、変数ｉは、評価の対象となる第ｎ番目のユーザ（対象ユーザと称することにする）の携帯端末から送信された実績情報に含まれるユーザＩＤを示す変数とされ、ここでは、Ｍ個のユーザＩＤが含まれていたものとされている。すなわち、第ｎ番目の対象ユーザは、Ｍ人のユーザにコンテンツを提供していたものとされる。なお、ここでは、対象ユーザがコンテンツを提供したユーザを提供先ユーザと称することにする。
【０４９９】
また、式（１）におけるＣａｔ_iは、実績情報の「コンテンツＩＤ」に基づいて算出される提供先ユーザの重みを表している。Ｔｉｍｅ_iは、実績情報の「提供開始日時」または「提供終了日時」に基づいて算出される提供先ユーザの重みを表している。Ｅｖａｌ_iは、評価情報に基づいて算出される提供先ユーザの重みを表している。
【０５００】
これ以外にも、提供先ユーザの年齢や性別による重み付けがなされるようにしてもよい。
【０５０１】
式（１）を参照して上述した評価値により特定されるユーザは、コンテンツの提供において起点となるユーザと考えることもでき、いわばハブとなるユーザである。しかしながら、コンテンツの提供において重要性の高いユーザを別の観点から特定することも可能である。
【０５０２】
例えば、ユーザ同士がグループを形成している場合、コンテンツの提供もこのグループ内で行われることが多い。例えば、学生であるユーザの間でコンテンツが次々とダウンロードされていく場合を考える。この場合、例えば、同じサークルに属するユーザの間では比較的簡単にコンテンツのダウンロードが行われるが、別のサークルに属するユーザによってコンテンツがダウンロードされる機会は少ない。
【０５０３】
このような場合、中核となるユーザを特定するにあたり、どれだけ多くのユーザにコンテンツを提供しているかという観点よりも、別のサークルにコンテンツを提供しているかという観点が重要になると考えられる。つまり、個々のサークル内では簡単にコンテンツのダウンロードが行われると考えられるので、サークルとサークルをつなぐいわばコネクタとなるユーザが重要な存在となるのである。
【０５０４】
例えば、サーバ２３において実績情報を解析することにより、各携帯端末のユーザのそれぞれについて、過去のコンテンツの提供の履歴を得ることができる。例えば、各携帯端末のユーザのそれぞれについて、過去３カ月以内にコンテンツを提供したユーザの一覧を生成することで、過去のコンテンツの提供の履歴とすることができる。
【０５０５】
サーバ２３は、このようなコンテンツの提供の履歴に基づいてコネクタとなるユーザを特定することができる。図４２は、コネクタとなるユーザを特定する方式を説明する図である。同図においては、Ｕ１、Ｕ２、・・・の記号により表わされる円のノードとして各ユーザが示されている。いま、同図のＵ１と示されたノードのユーザについて、コネクタとなるユーザであるか否かを判定するものとする。
【０５０６】
サーバ２３は、既に蓄積されている実績情報に基づいて、ユーザＵ１が過去３カ月以内にコンテンツを提供したユーザの一覧を生成する。いまの場合、ユーザＵ１は、過去にユーザＵ９とユーザＵ１０にコンテンツを提供していたものとされる。
【０５０７】
サーバ２３は、既に蓄積されている実績情報に基づいて、ユーザＵ９とユーザＵ１０が過去３カ月以内にコンテンツを提供したユーザの一覧を生成する。いまの場合、ユーザＵ９は、ユーザＵ１１、ユーザＵ５、およびユーザＵ１２にコンテンツを提供していたものとされる。また、ユーザＵ１０は、ユーザＵ８、およびユーザＵ１３にコンテンツを提供していたものとされる。
【０５０８】
このようにして、ユーザＵ１についての所属グループが特定される。
【０５０９】
サーバ２３は、ユーザＵ１の携帯端末から新たに送信された実績情報に基づいて、ユーザＵ１からユーザＵ２にコンテンツが提供されたと判定する。サーバ２３は、上述した場合と同様に、既に蓄積されている実績情報に基づいて、ユーザＵ２についての所属グループ（提供先グループと称することにする）を特定する。
【０５１０】
そして、サーバ２３は、所属グループと提供先グループにおいて重複しているユーザの数をカウントする。この例では、ユーザＵ５とユーザＵ８が重複しているので、重複ユーザ数は２とされる。また、サーバ２３は、所属グループと提供先グループにおいて重複していないユーザ（ユニークユーザと称することにする）の数をカウントする。この例では、所属グループと提供先グループのそれぞれにおいて、ユニークユーザ数は５とされる。
【０５１１】
サーバ２３は、例えば、所属グループのユニークユーザ数と提供先グループのユニークユーザ数とを合計し、コネクタとなるユーザの評価値を算出する。そして、算出された評価値に基づいてコネクタとなるユーザが特定されるのである。
【０５１２】
なお、図４２の例では、所属グループおよび提供先グループのグループ深度を３とした場合の例について説明した。すなわち、ユーザＵ１とユーザＵ２のそれぞれを起点として、３階層のコンテンツの提供の履歴に基づいて所属グループおよび提供先グループが形成されている。実際にコネクタとなるユーザを特定する際のグループ深度は、任意に設定されるようにして構わない。
【０５１３】
このように、サーバ２３は、ハブとなるユーザ、またはコネクタとなるユーザを特定することができる。このようなユーザは、例えば、バイラルマーケティングを行うにあたり重要な情報とされている。サーバ２３の運用業者は、上述のように特定したハブとなるユーザ、またはコネクタとなるユーザに関する情報を、例えば、ゲームソフトメーカなどのコンテンツ事業者に有料で提供するなどのサービスを行うことも可能である。
【０５１４】
次に、図４３のフローチャートを参照してサーバ２２の処理について説明する。この処理は、例えば、実績情報に基づくコンテンツの配信が指令されたとき実行される。
【０５１５】
ステップＳ３０１１において、サーバ２２は、実績情報を受信する。このとき、例えば、図３７の携帯端末５１と携帯端末５５から送信された実績情報が受信される。
【０５１６】
ステップＳ３０１２において、サーバ２２は、ステップＳ３０１１で受信した実績情報を解析する。このとき、例えば、コンテンツの提供実績の高い携帯電端末を特定するための解析が行われる。ここでいう、提供実績が高いとは、例えば、単位時間内により多くのユーザにコンテンツを提供したことを意味するものとしてもよいし、ターゲットとなる年齢、性別、住所、趣向のユーザにコンテンツを提供したことを意味するものとしてもよい。例えば、プロモーションにおいて、若年者のファン獲得を目標としている場合、「コンテンツ提供先」に係る情報の中の「年齢」により実績情報をフィルタリングして、閾値未満の年齢のユーザにより多くコンテンツを提供した携帯端末の提供実績が高いものとされる。
【０５１７】
また、このとき、証明書に含まれる情報の内容（ユーザ認証の結果、リンク認証の結果、またはそれらの両方）とその有効性に基づいて実績情報がフィルタリングされるようにしてもよい。
【０５１８】
ステップＳ３０１３において、サーバ２２は、ステップＳ３０１２の処理の結果に基づいて各携帯端末の提供実績の高さを数値化する。
【０５１９】
ステップＳ３０１４において、サーバ２２は、ステップＳ３０１３の処理の結果に基づいて、次回の新曲のコンテンツを優先的に配信するようにする。
【０５２０】
このとき、例えば、ステップＳ３０１３の処理の結果得られた数値を各携帯端末について相互に比較、または予め設定閾値と比較することで、提供実績の高い携帯端末が特定される。そして、例えば、サーバ２２が、携帯端末５１の提供実績が高いと判断した場合、携帯端末５１に対しては次回の新曲のコンテンツを無料でダウンロードさせるようにする。あるいはまた、予め設定された基準より高い提供実績が確認された複数の携帯端末に次回の新曲のコンテンツを無料でダウンロードさせるようにしてもよいし、提供実績の高い順に、時間差を付けて新曲のコンテンツを無料でダウンロードさせるようにしてもよい。
【０５２１】
あるいはまた、提供実績の高い携帯端末にコンサートのチケットなどの優待特典を付与するようにしてもよい。
【０５２２】
このようにして、サーバ２２の処理が実行される。
【０５２３】
次に、図４４のフローチャートを参照して、サーバ２３の処理について説明する。この処理は、例えば、実績情報に基づくハブユーザやコネクタユーザの特定が指令されたとき実行される。
【０５２４】
ステップＳ３０３１において、サーバ２３は、実績情報を受信する。このとき、例えば、図４０の携帯端末６２と携帯端末６７から送信された実績情報が受信される。
【０５２５】
ステップＳ３０３２において、サーバ２３は、ステップＳ３０３２で受信した実績情報を解析する。
【０５２６】
このとき、例えば、サーバ２３は、実績情報の「ユーザＩＤ」に基づいて個々の携帯端末が何人のユーザにコンテンツを提供したかを表す情報を取得する。そして、サーバ２３は、例えば、実績情報の「コンテンツＩＤ」に基づいて、提供したコンテンツの種類やジャンルなどを特定し、その特定結果に基づいてコンテンツを提供したユーザの重み付けを行う。
【０５２７】
あるいはまた、サーバ２３は、例えば、実績情報の「提供開始日時」または「提供終了日時」に基づいて、コンテンツを提供したユーザの重み付けを行うようにしてもよい。さらに、携帯端末の識別情報に基づいて、サーバ２１から評価情報を取得して、例えば、より長いコメントの評価情報が得られた携帯端末のユーザについてより大きい重みづけがなされるように重み付けがなされてもよい。
【０５２８】
このような解析結果は、後述するハブユーザ特定処理において用いられる。
【０５２９】
またこのとき、例えば、サーバ２３は、各携帯端末のユーザのそれぞれについて、過去３カ月以内にコンテンツを提供したユーザの一覧を生成することで、過去のコンテンツの提供の履歴を生成する。
【０５３０】
このような解析結果は、後述するコネクタユーザ特定処理において用いられる。
【０５３１】
ステップＳ３０３３において、サーバ２３は、ハブユーザ特定処理を実行する。ここでは、例えば、ステップＳ３０３２の処理の結果に基づいて各携帯端末のユーザの評価値が算出される。ユーザの評価値は、例えば、上述した式（１）により演算される。
【０５３２】
これにより、ハブユーザが特定されることになる。
【０５３３】
ステップＳ３０３４において、サーバ２３は、コネクタユーザ特定処理を実行する。ここでは、例えば、ステップＳ３０３２の処理の結果に基づいて、図４２を参照して上述したように、所属グループと提供先グループにおいて重複しているユーザの数がカウントされる。そして、所属グループと提供先グループにおいて重複していないユニークユーザの数がカウントされ、所属グループのユニークユーザ数と提供先グループのユニークユーザ数とを合計し、コネクタとなるユーザの評価値が算出される。
【０５３４】
これにより、コネクタユーザが特定されることになる。
【０５３５】
ステップＳ３０３５において、サーバ２３は、ステップＳ３０３３の処理で特定されたハブユーザのユーザＩＤ、ステップＳ３０３４の処理で特定されたコネクタユーザのユーザＩＤを出力する。
【０５３６】
このようにして、サーバ２３の処理が実行される。
【０５３７】
図３７乃至図４４を参照して上述した実施の形態においては、ハンドオーバ機能を有する携帯端末によるコンテンツの提供に係る実績情報に基づいてサーバ２２が、より効率的なコンテンツの配信を行う例、サーバ２３がハブユーザまたはコネクタユーザを特定する例について説明した。しかし、サーバ２２またはサーバ２３により処理される実績情報は、ハンドオーバ機能を有する携帯端末によるコンテンツの提供に係る実績情報に限られるものではない。例えば、有線の通信によりコンテンツを提供する端末によるコンテンツの提供に係る実績情報が処理されるようにしてもよい。
【０５３８】
また、図３７乃至図４４を参照して上述した実施の形態においては、コンテンツの提供に係る実績情報を取り扱う例について説明したが、例えば、コンテンツ以外の電子情報財の提供に係る実績情報を取り扱う場合にも本発明を適用することが可能である。
【０５３９】
以上においては、ハンドオーバ時に非接触通信が行われ、その後近距離無線通信が行われると説明したが、本発明を適用可能な実施の形態はこれに限られるものではない。例えば、ＮＦＣなどの非接触通信の代わりに、端子を接触させる接触型通信が用いられ、近距離無線通信の代わりに、通常の有線ＬＡＮが用いられるようにしてもよい。
【０５４０】
また、以上においては、サーバと携帯端末などとの間で行われる広域通信は、移動体通信網用無線通信が用いられると説明したが、本発明を適用可能な実施の形態はこれに限られるものではない。例えば、移動体通信網用無線通信の代わりに固定通信網通信や独自のネットワークを用いた通信が用いられるようにしてもよい。
【０５４１】
なお、上述した一連の処理は、ハードウェアにより実行させることもできるし、ソフトウェアにより実行させることもできる。上述した一連の処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが、専用のハードウェアに組み込まれているコンピュータにネットワークや記録媒体からインストールされる。また、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、汎用のパーソナルコンピュータなどに、ネットワークや記録媒体からインストールされる。
【０５４２】
上述した一連の処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが、インターネットなどのネットワークや、リムーバブルメディアなどからなる記録媒体からインストールされる。
【０５４３】
なお、本明細書において上述した一連の処理は、記載された順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理をも含むものである。
【０５４４】
また、本発明の実施の形態は、上述した実施の形態に限定されるものではなく、本発明の要旨を逸脱しない範囲において種々の変更が可能である。
【符号の説明】
【０５４５】
１０評価情報収集システム，２１サーバ，３１乃至３３情報収集端末，４１乃至４７携帯端末，５１乃至５７携帯端末，６１乃至６７携帯端末，１１１ＣＰＵ１１２ＲＯＭ１１３ＲＡＭ１２３記憶部，１２６リムーバブルメディア，１３１移動体通信網用無線通信部，１３２近距離無線通信部，１３３非接触通信部，２０１ＣＰＵ２０２ＲＯＭ２０３ＲＡＭ２１３記憶部，２１４通信部，２１６リムーバブルメディア，２２１評価情報データベース，２２２端末機器データベース

【特許請求の範囲】
【請求項１】
予め定められた一の電子情報財の提供者に係る端末機器による前記電子情報財の提供先を表す実績情報を取得する実績情報取得手段と、
前記取得した実績情報に含まれる前記提供先を抽出し、前記抽出された提供先に対して前記提供先の属性に応じて予め定められた基準で重み付けする重み付け手段と、
前記重み付けされた値に基づいて前記提供者の評価値を算出する評価値算出手段と
を備える情報処理装置。
【請求項２】
前記電子情報財の提供者に係る端末機器である第１の端末機器は、
第１の通信により前記電子情報財の提供先に係る第２の端末機器の識別情報および第２の通信のアドレスを含む情報を前記第２の端末機器から受信する機器情報受信手段と、
前記第２の端末機器へ前記第２の通信を利用して前記電子情報財の送信を行う電子情報財送信手段とを備え、
前記実績情報には、前記第１の通信を介して受信された情報に含まれる前記第２の端末機器のユーザの識別情報および属性情報が含まれる
請求項１に記載の情報処理装置。
【請求項３】
前記重み付け手段は、
前記第２の端末機器が前記第２の通信を利用して受信した前記電子情報財に対する評価情報に基づいて、前記提供先に対する重み付けを行う
請求項２に記載の情報処理装置
【請求項４】
前記重み付け手段は、
前記提供先に提供された前記電子情報財の種類および前記電子情報財が提供された時刻の少なくとも一方に基づいて、前記提供先に対する重み付けを行う
請求項２に記載の情報処理装置。
【請求項５】
複数の前記実績情報に基づいて、前記評価値の演算の対象となる提供者に対して前記電子情報財を提供した前記端末機器のユーザを特定することで、前記提供者が属する所属グループを特定する所属グループ特定手段と、
複数の前記実績情報に基づいて、前記評価値の演算の対象となる提供者が新たに前記電子情報財を提供した前記端末機器のユーザを特定することで、提供先グループを特定する提供先グループ特定手段とをさらに備え、
前記所属グループ特定手段は、
前記評価値の演算の対象となる提供者を第１次提供元ユーザとし、前記特定されたユーザを、第２次提供元ユーザとし、前記第２次提供元ユーザが過去に前記電子情報財の提供を受けたユーザを第３次提供元ユーザとして第１次乃至第ｎ次の提供元ユーザを特定し、
提供先グループ特定手段は、
前記特定されたユーザを、第１次提供先ユーザとし、前記第１次提供先ユーザが過去に前記電子情報財を提供したユーザを第２次提供先ユーザとして第１次乃至第ｎ次の提供先ユーザを特定する
請求項２に記載の情報処理装置。
【請求項６】
前記評価値演算手段は、
前記特定された所属グループおよび前記提供先グループに属するユーザの中で重複しないユーザの数に基づいて前記評価値を演算する
請求項５に記載の情報処理装置
【請求項７】
前記実績情報には、前記第１の通信を介して受信された情報に含まれる前記第２の端末のユーザ認証の方式および前記第２の端末のユーザ認証結果に係る情報がさらに含まれる
請求項２に記載の情報処理装置。
【請求項８】
前記第１の端末機器の識別情報および前記第２の端末機器の識別情報に基づいて、前記商品またはサービスの提供者の信頼性を表す信頼性区分、前記第１の端末機器のセキュリティ区分および前記第２の端末機器のセキュリティ区分を特定する区分特定手段と、
前記特定結果に基づいて、前記第１の端末機器と前記第２の端末機器との間で行われる第２の通信が継続して行われていることを確認するリンク認証の方式を特定するとともに、その方式で前記リンク認証に係る処理を実行するリンク認証手段とをさらに備え、
前記第２の端末のユーザ認証結果に係る情報には、前記リンク認証の結果が含まれる
請求項７に記載の情報処理装置。
【請求項９】
前記リンク認証手段は、前記特定結果に応じて、
前記第２の端末に前記第３の通信を利用して送信した情報が、前記第２の通信を利用して前記第１の端末機器に送信されたか否かを表す情報を前記第１の端末機器から前記第３の通信を利用して受信することで、前記第２の端末機器の同一性を確認する評価者同一性確認処理と、
前記第１の端末に前記第３の通信を利用して送信した情報が、前記第２の通信を利用して前記第２の端末機器に送信されたか否かを表す情報を前記第２の端末機器から前記第３の通信を利用して受信することで、前記第１の端末機器の同一性を確認する提供者同一性確認処理とを、
それぞれ定期的に実行する
請求項８に記載の情報処理装置。
【請求項１０】
前記リンク認証手段は、
前記信頼性区分に基づいて、前記提供者同一性確認処理を実行するか否かを決定することで、前記リンク認証の方式を特定する
請求項９に記載の情報処理装置。
【請求項１１】
前記リンク認証手段は、
前記セキュリティ区分に基づいて、前記評価者同一性確認処理または前記提供者同一性確認処理において、前記第１の端末機器若しくは前記第２の端末機器が予め記憶している固有鍵を用いるか、または、前記第１の端末機器若しくは前記第２の端末機器が予め記憶していない一時キーを用いるかを決定することで、前記リンク認証の方式を特定する
請求項９に記載の情報処理装置。
【請求項１２】
実績情報取得手段が、予め定められた一の電子情報財の提供者に係る端末機器による前記電子情報財の提供先を表す実績情報を取得し、
重み付け手段が、前記取得した実績情報に含まれる前記提供先を抽出し、前記抽出された提供先に対して前記提供先の属性に応じて予め定められた基準で重み付けし、
評価値算出手段が、前記重み付けされた値に基づいて前記提供者の評価値を算出するステップ
を含む情報処理方法。
【請求項１３】
コンピュータを、
予め定められた一の電子情報財の提供者に係る端末機器による前記電子情報財の提供先を表す実績情報を取得する実績情報取得手段と、
前記取得した実績情報に含まれる前記提供先を抽出し、前記抽出された提供先に対して前記提供先の属性に応じて予め定められた基準で重み付けする重み付け手段と、
前記重み付けされた値に基づいて前記提供者の評価値を算出する評価値算出手段とを備える情報処理装置として機能させる
プログラム。

【図１】