(57)【特許請求の範囲】
【請求項１】
予め定められた一の電子情報財の提供者に係る端末機器による前記電子情報財の提供先を表す実績情報を取得する実績情報取得手段と、
前記取得した実績情報を予め定められた基準に基づいて比較することで、複数の前記端末機器の前記電子情報財の提供実績を比較する比較手段と、
前記比較結果に基づいて前記端末機器への他の前記電子情報財の提供の方式と複数の前記端末機器の中での前記端末機器へ他の前記電子情報財の提供の優先順位とを特定する提供方式特定手段と
を備え、
前記電子情報財の提供者に係る端末機器である第１の端末機器は、
第１の通信により前記電子情報財の提供先に係る第２の端末機器の識別情報および前記第１の通信とは異なる第２の通信のアドレスを含む第２の端末機器の機器情報を前記第２の端末機器から受信する機器情報受信手段と、
前記第２の通信により前記電子情報財を前記第２の端末機器へ送信する電子情報財送信手段とを備え、
前記実績情報には、前記第１の通信を介して受信された第２の端末機器の機器情報に含まれる前記第２の端末機器のユーザの識別情報、属性情報、ユーザ認証の方式、およびユーザ認証結果に係る情報が含まれる
情報処理装置。
【請求項２】
前記比較結果に基づいて前記端末機器へ他の前記電子情報財の提供する際の対価を算出する算出手段を備える
請求項１に記載の情報処理装置。
【請求項３】
前記第１の通信により送受信された前記端末機器の機器情報には、商品またはサービスの提供者の信頼性情報および固定鍵を有するか否かの安全性情報が含まれており、
前記第１の通信により送受信された第１の端末機器の機器情報および前記第２の端末機器の機器情報に基づいて、商品またはサービスの提供者の信頼性区分、並びに、前記第１の端末機器のセキュリティ区分および前記第２の端末機器のセキュリティ区分を特定する区分特定手段と、
前記区分特定手段による区分特定結果に基づいて、前記第１の端末機器と前記第２の端末機器との間で行われる第２の通信が継続して行われていることを確認するリンク認証において、前記第１の端末機器および前記第２の端末機器の同一性をそれぞれ確認する各同一性確認処理の有無、並びに固定鍵または一時鍵の利用を決定することで、前記リンク認証の方式を特定するとともに、特定された方式で前記リンク認証に係る処理を実行するリンク認証手段とをさらに備え、
前記第２の端末機器のユーザ認証結果に係る情報には、前記リンク認証の結果が含まれる
請求項１に記載の情報処理装置。
【請求項４】
前記リンク認証手段は、前記区分特定結果に応じて、
前記第２の端末機器に、前記第１の通信および第２の通信とは異なる第３の通信を利用して送信した情報が、前記第２の通信を利用して前記第１の端末機器に送信されたか否かを表す情報を前記第１の端末機器から前記第３の通信を利用して受信することで、前記第２の端末機器の同一性を確認する評価者同一性確認処理と、
前記第１の端末機器に前記第３の通信を利用して送信した情報が、前記第２の通信を利用して前記第２の端末機器に送信されたか否かを表す情報を前記第２の端末機器から前記第３の通信を利用して受信することで、前記第１の端末機器の同一性を確認する提供者同一性確認処理とを、
実行する
請求項３に記載の情報処理装置。
【請求項５】
前記リンク認証手段は、
前記信頼性区分に基づいて、前記提供者同一性確認処理を実行するか否かを決定することで、前記リンク認証の方式を特定する
請求項４に記載の情報処理装置。
【請求項６】
前記リンク認証手段は、
前記セキュリティ区分に基づいて、前記評価者同一性確認処理または前記提供者同一性確認処理において、前記第１の端末機器若しくは前記第２の端末機器が予め記憶している固有鍵を用いるか、または、前記第１の端末機器若しくは前記第２の端末機器が予め記憶していない一時キーを用いるかを決定することで、前記リンク認証の方式を特定する
請求項４に記載の情報処理装置。
【請求項７】
実績情報取得手段が、予め定められた一の電子情報財の提供者に係る端末機器による前記電子情報財の提供先を表す実績情報を取得し、
比較手段が、前記取得した実績情報を予め定められた基準に基づいて比較することで、複数の前記端末機器の前記電子情報財の提供実績を比較し、
提供方式特定手段が、前記比較結果に基づいて前記端末機器への他の前記電子情報財の提供の方式と複数の前記端末機器の中での前記端末機器へ他の前記電子情報財の提供の優先順位とを特定し、
電子情報財の提供者に係る端末機器である第１の端末機器が、
第１の通信により前記電子情報財の提供先に係る第２の端末機器の識別情報および前記第１の通信とは異なる第２の通信のアドレスを含む情報を前記第２の端末機器から受信し、
前記第２の通信により前記電子情報財を前記第２の端末機器へ送信し、
前記実績情報には、前記第１の通信を介して受信された第２の端末機器の機器情報に含まれる前記第２の端末機器のユーザの識別情報、属性情報、ユーザ認証の方式、およびユーザ認証結果に係る情報が含まれる
情報処理方法。
【請求項８】
コンピュータを、
予め定められた一の電子情報財の提供者に係る端末機器による前記電子情報財の提供先を表す実績情報を取得する実績情報取得手段と、
前記取得した実績情報を予め定められた基準に基づいて比較することで、複数の前記端末機器の前記電子情報財の提供実績を比較する比較手段と、
前記比較結果に基づいて前記端末機器への他の前記電子情報財の提供の方式を特定する提供方式特定手段とを備える情報処理装置として機能させ、
前記電子情報財の提供者に係る端末機器である第１の端末機器は、
第１の通信により前記電子情報財の提供先に係る第２の端末機器の識別情報および前記第１の通信とは異なる第２の通信のアドレスを含む情報を前記第２の端末機器から受信する機器情報受信手段と、
前記第２の通信により前記電子情報財を前記第２の端末機器へ送信する電子情報財送信手段とを備え、
前記実績情報には、前記第１の通信を介して受信された第２の端末機器の機器情報に含まれる前記第２の端末機器のユーザの識別情報、属性情報、ユーザ認証の方式、およびユーザ認証結果に係る情報が含まれる
プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置および方法、並びにプログラムに関し、特に、コンテンツの配信サービスの付加価値をより高めることができるようにする情報処理装置および方法、並びにプログラムに関する。
【背景技術】
【０００２】
従来より、ネットワークを介したダウンロード方式によるコンテンツの配信サービスが盛んに行われている。このようなコンテンツの配信サービスにおいては、例えば、ユーザの携帯電話機などによりサーバからコンテンツをダウンロードするものの他、ユーザの携帯端末間でコンテンツの送受信を行うことができる場合もある。
【０００３】
また、インターネット上の掲示板などにおいていわゆる口コミ情報と称される情報が活用されている。口コミ情報は、例えば、店舗のサービス、商品の品質、コンテンツの面白さなどについての評価情報である。
【０００４】
口コミ情報は、雑誌記者や専門家によって記載された評価情報と異なり、実際に店舗に行った人、商品を買った人、コンテンツを視聴した人などによる生の声として有益であり、商品やサービスの購入にあたって参考にされることも多い。
【０００５】
また、視聴者の無線端末から視聴者の属性（ユーザ情報）を収集して視聴効果を測定する技術も提案されている（例えば、特許文献１参照）。このような技術により、より簡単に評価情報を収集することが可能となってきている。
【０００６】
【特許文献１】特開２０１０−４１１９４号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
ところで、コンテンツの配信サービスの普及に伴って、例えば、宣伝広告などを含んだコンテンツを無料で配信することなども行われるようになってきている。
【０００８】
このようにコンテンツの配信サービスの態様が多様化するのに伴い、単にユーザから対価の支払いを受けて所望のコンテンツをダウンロードさせるような従来のコンテンツ配信サービスとは異なる工夫が求められている。
【０００９】
例えば、配信するコンテンツの市場での評価を高めることなどに貢献したユーザなどには優先的にコンテンツを配信するなどの工夫をすれば、コンテンツの配信サービスの付加価値をより高めることも可能となる。
【００１０】
また、近年では、いわゆる口コミ情報を利用したマーケティングの手法として、例えば、バイラルマーケティングが注目されている。
【００１１】
バイラルマーティングでは、既存のユーザに自社のコンテンツやサービスなどを知人に紹介してもらえるよう働きかけ、既存のユーザを通して間接的に自社のコンテンツやサービスを宣伝する。このため、バイラルマーティングを行うにあたり、どのユーザに働きかければよいかなどの情報が極めて重要な情報とされている。
【００１２】
従来のインターネット上の掲示板などの口コミ情報では、例えば、企業が売り込もうとしているコンテンツやサービスなどをどのユーザに提供すれば効率的に紹介してもらえるかを、適確に分析することが難しかった。
【００１３】
本発明はこのような状況に鑑みてなされたものであり、コンテンツの配信サービスの付加価値をより高めることができるようにするものである。
【課題を解決するための手段】
【００１４】
本発明の一側面は、予め定められた一の電子情報財の提供者に係る端末機器による前記電子情報財の提供先を表す実績情報を取得する実績情報取得手段と、前記取得した実績情報を予め定められた基準に基づいて比較することで、複数の前記端末機器の前記電子情報財の提供実績を比較する比較手段と、前記比較結果に基づいて前記端末機器への他の前記電子情報財の提供の方式と複数の前記端末機器の中での前記端末機器へ他の前記電子情報財の提供の優先順位とを特定する提供方式特定手段とを備え、前記電子情報財の提供者に係る端末機器である第１の端末機器は、第１の通信により前記電子情報財の提供先に係る第２の端末機器の識別情報および前記第１の通信とは異なる第２の通信のアドレスを含む第２の端末機器の機器情報を前記第２の端末機器から受信する機器情報受信手段と、前記第２の通信により前記電子情報財を前記第２の端末機器へ送信する電子情報財送信手段とを備え、前記実績情報には、前記第１の通信を介して受信された第２の端末機器の機器情報に含まれる前記第２の端末機器のユーザの識別情報、属性情報、ユーザ認証の方式、およびユーザ認証結果に係る情報が含まれる情報処理装置である。
【００１５】
前記比較結果に基づいて前記端末機器へ他の前記電子情報財の提供する際の対価を算出する算出手段を備えるようにすることができる。
【００１９】
前記第１の通信により送受信された前記端末機器の機器情報には、商品またはサービスの提供者の信頼性情報および固定鍵を有するか否かの安全性情報が含まれており、前記第１の通信により送受信された第１の端末機器の機器情報および前記第２の端末機器の機器情報に基づいて、商品またはサービスの提供者の信頼性区分、並びに、前記第１の端末機器のセキュリティ区分および前記第２の端末機器のセキュリティ区分を特定する区分特定手段と、前記区分特定手段による区分特定結果に基づいて、前記第１の端末機器と前記第２の端末機器との間で行われる第２の通信が継続して行われていることを確認するリンク認証において、前記第１の端末機器および前記第２の端末機器の同一性をそれぞれ確認する各同一性確認処理の有無、並びに固定鍵または一時鍵の利用を決定することで、前記リンク認証の方式を特定するとともに、特定された方式で前記リンク認証に係る処理を実行するリンク認証手段とをさらに備え、前記第２の端末機器のユーザ認証結果に係る情報には、前記リンク認証の結果が含まれる。
【００２０】
前記リンク認証手段は、前記区分特定結果に応じて、前記第２の端末機器に、前記第１の通信および第２の通信とは異なる第３の通信を利用して送信した情報が、前記第２の通信を利用して前記第１の端末機器に送信されたか否かを表す情報を前記第１の端末機器から前記第３の通信を利用して受信することで、前記第２の端末機器の同一性を確認する評価者同一性確認処理と、前記第１の端末機器に前記第３の通信を利用して送信した情報が、前記第２の通信を利用して前記第２の端末機器に送信されたか否かを表す情報を前記第２の端末機器から前記第３の通信を利用して受信することで、前記第１の端末機器の同一性を確認する提供者同一性確認処理とを、実行することができる。
【００２１】
前記リンク認証手段は、前記信頼性区分に基づいて、前記提供者同一性確認処理を実行するか否かを決定することで、前記リンク認証の方式を特定するようにすることができる。
【００２２】
前記リンク認証手段は、前記セキュリティ区分に基づいて、前記評価者同一性確認処理または前記提供者同一性確認処理において、前記第１の端末機器若しくは前記第２の端末機器が予め記憶している固有鍵を用いるか、または、前記第１の端末機器若しくは前記第２の端末機器が予め記憶していない一時キーを用いるかを決定することで、前記リンク認証の方式を特定するようにすることができる。
【００２３】
本発明の一側面は、実績情報取得手段が、予め定められた一の電子情報財の提供者に係る端末機器による前記電子情報財の提供先を表す実績情報を取得し、比較手段が、前記取得した実績情報を予め定められた基準に基づいて比較することで、複数の前記端末機器の前記電子情報財の提供実績を比較し、提供方式特定手段が、前記比較結果に基づいて前記端末機器への他の前記電子情報財の提供の方式と複数の前記端末機器の中での前記端末機器へ他の前記電子情報財の提供の優先順位とを特定し、電子情報財の提供者に係る端末機器である第１の端末機器が、第１の通信により前記電子情報財の提供先に係る第２の端末機器の識別情報および前記第１の通信とは異なる第２の通信のアドレスを含む情報を前記第２の端末機器から受信し、前記第２の通信により前記電子情報財を前記第２の端末機器へ送信し、前記実績情報には、前記第１の通信を介して受信された第２の端末機器の機器情報に含まれる前記第２の端末機器のユーザの識別情報、属性情報、ユーザ認証の方式、およびユーザ認証結果に係る情報が含まれる情報処理方法である。
【００２４】
本発明の一側面は、コンピュータを、予め定められた一の電子情報財の提供者に係る端末機器による前記電子情報財の提供先を表す実績情報を取得する実績情報取得手段と、前記取得した実績情報を予め定められた基準に基づいて比較することで、複数の前記端末機器の前記電子情報財の提供実績を比較する比較手段と、前記比較結果に基づいて前記端末機器への他の前記電子情報財の提供の方式を特定する提供方式特定手段とを備える情報処理装置として機能させ、前記電子情報財の提供者に係る端末機器である第１の端末機器は、第１の通信により前記電子情報財の提供先に係る第２の端末機器の識別情報および前記第１の通信とは異なる第２の通信のアドレスを含む情報を前記第２の端末機器から受信する機器情報受信手段と、前記第２の通信により前記電子情報財を前記第２の端末機器へ送信する電子情報財送信手段とを備え、前記実績情報には、前記第１の通信を介して受信された第２の端末機器の機器情報に含まれる前記第２の端末機器のユーザの識別情報、属性情報、ユーザ認証の方式、およびユーザ認証結果に係る情報が含まれるプログラムである。
【００２５】
本発明の一側面においては、予め定められた一の電子情報財の提供者に係る端末機器による前記電子情報財の提供先を表す実績情報が取得され、前記取得した実績情報を予め定められた基準に基づいて比較することで、複数の前記端末機器の前記電子情報財の提供実績が比較され、前記比較結果に基づいて前記端末機器への他の前記電子情報財の提供の方式と複数の前記端末機器の中での前記端末機器へ他の前記電子情報財の提供の優先順位とが特定される。また、電子情報財の提供者に係る端末機器である第１の端末機器において、第１の通信により前記電子情報財の提供先に係る第２の端末機器の識別情報および前記第１の通信とは異なる第２の通信のアドレスを含む情報が前記第２の端末機器から受信され、前記第２の通信により前記電子情報財が前記第２の端末機器へ送信される。さらに、前記実績情報には、前記第１の通信を介して受信された第２の端末機器の機器情報に含まれる前記第２の端末機器のユーザの識別情報、属性情報、ユーザ認証の方式、およびユーザ認証結果に係る情報が含まれる。
【発明の効果】
【００２６】
本発明によれば、コンテンツの配信サービスの付加価値をより高めることができる。
【図面の簡単な説明】
【００２７】
【図１】本発明の一実施の形態に係る評価情報収集システムの構成例を示す図である。
【図２】本発明の一実施の形態に係る評価情報収集システムの別の構成例を示す図である。
【図３】携帯端末の構成例を示すブロック図である。
【図４】サーバの構成例を示すブロック図である。
【図５】端末機器情報の例を示す図である。
【図６】リンク認証を行って評価情報を収集する方式の例を説明する図である。
【図７】図６の方式における処理の流れを説明するアローチャートである。
【図８】リンク認証を行って評価情報を収集する方式の別の例を説明する図である。
【図９】図８の方式における処理の流れを説明するアローチャートである。
【図１０】リンク認証を行って評価情報を収集する方式のさらに別の例を説明する図である。
【図１１】図１０の方式における処理の流れを説明するアローチャートである。
【図１２】リンク認証を行って評価情報を収集する方式のさらに別の例を説明する図である。
【図１３】リンク認証を行って評価情報を収集する方式のさらに別の例を説明する図である。
【図１４】ハンドオーバメッセージを説明する図である。
【図１５】リンク認証の方式を特定するための情報を説明する図である。
【図１６】評価情報収集処理の例を説明するフローチャートである。
【図１７】ケース１処理の例を説明するフローチャートである。
【図１８】ケース２処理の例を説明するフローチャートである。
【図１９】ケース３処理の例を説明するフローチャートである。
【図２０】ケース３処理の例を説明するフローチャートである。
【図２１】ケース４処理の例を説明するフローチャートである。
【図２２】ケース４処理の例を説明するフローチャートである。
【図２３】ケース５処理の例を説明するフローチャートである。
【図２４】ケース５処理の例を説明するフローチャートである。
【図２５】提供者側端末機器の処理の例を説明するフローチャートである。
【図２６】コンテンツ提供処理の例を説明するフローチャートである。
【図２７】リンク認証処理の例を説明するフローチャートである。
【図２８】提供者側端末機器の処理の別の例を説明するフローチャートである。
【図２９】リンク認証処理の別の例を説明するフローチャートである。
【図３０】評価者側端末機器の処理の例を説明するフローチャートである。
【図３１】第１リンク認証処理の例を説明するフローチャートである。
【図３２】第２リンク認証処理の例を説明するフローチャートである。
【図３３】コンテンツ評価処理の例を説明するフローチャートである。
【図３４】評価者側端末機器の処理の別の例を説明するフローチャートである。
【図３５】第３リンク認証処理の例を説明するフローチャートである。
【図３６】第４リンク認証処理の例を説明するフローチャートである。
【図３７】本発明の一実施の形態に係るコンテンツ配信システムの構成例を示す図である。
【図３８】実績情報の例を示す図である。
【図３９】ハンドオーバメッセージの別の例を説明する図である。
【図４０】本発明の一実施の形態に係るコンテンツ配信システムの別の構成例を示す図である。
【図４１】実績情報における各携帯端末をノードとして作成されたネットワークマップの例を示す図である。
【図４２】コネクタとなるユーザを特定する方式を説明する図である。
【図４３】図３７の実施の形態におけるサーバの処理の例を説明するフローチャートである。
【図４４】図４０の実施の形態におけるサーバの処理の例を説明するフローチャートである。
【発明を実施するための形態】
【００２８】
以下、図面を参照して、本発明の実施の形態について説明する。
【００２９】
本発明においては、例えば、携帯端末のハンドオーバ機能を利用して評価情報を収集するようにする。
【００３０】
例えば、携帯電話機として構成される携帯端末が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）で表わした場合、このユーザの評価値は、式（１）により演算される。
【０４９５】
【数１】
0005728975.tif 000002
【０４９６】
式（１）において、変数ｉは、評価の対象となる第ｎ番目のユーザ（対象ユーザと称することにする）の携帯端末から送信された実績情報に含まれるユーザＩＤを示す変数とされ、ここでは、Ｍ個のユーザＩＤが含まれていたものとされている。すなわち、第ｎ番目の対象ユーザは、Ｍ人のユーザにコンテンツを提供していたものとされる。なお、ここでは、対象ユーザがコンテンツを提供したユーザを提供先ユーザと称することにする。
【０４９７】
また、式（１）におけるＣａｔiは、実績情報の「コンテンツＩＤ」に基づいて算出される提供先ユーザの重みを表している。Ｔｉｍｅiは、実績情報の「提供開始日時」または「提供終了日時」に基づいて算出される提供先ユーザの重みを表している。Ｅｖａｌiは、評価情報に基づいて算出される提供先ユーザの重みを表している。
【０４９８】
これ以外にも、提供先ユーザの年齢や性別による重み付けがなされるようにしてもよい。
【０４９９】
式（１）を参照して上述した評価値により特定されるユーザは、コンテンツの提供において起点となるユーザと考えることもでき、いわばハブとなるユーザである。しかしながら、コンテンツの提供において重要性の高いユーザを別の観点から特定することも可能である。
【０５００】
例えば、ユーザ同士がグループを形成している場合、コンテンツの提供もこのグループ内で行われることが多い。例えば、学生であるユーザの間でコンテンツが次々とダウンロードされていく場合を考える。この場合、例えば、同じサークルに属するユーザの間では比較的簡単にコンテンツのダウンロードが行われるが、別のサークルに属するユーザによってコンテンツがダウンロードされる機会は少ない。
【０５０１】
このような場合、中核となるユーザを特定するにあたり、どれだけ多くのユーザにコンテンツを提供しているかという観点よりも、別のサークルにコンテンツを提供しているかという観点が重要になると考えられる。つまり、個々のサークル内では簡単にコンテンツのダウンロードが行われると考えられるので、サークルとサークルをつなぐいわばコネクタとなるユーザが重要な存在となるのである。
【０５０２】
例えば、サーバ２３において実績情報を解析することにより、各携帯端末のユーザのそれぞれについて、過去のコンテンツの提供の履歴を得ることができる。例えば、各携帯端末のユーザのそれぞれについて、過去３カ月以内にコンテンツを提供したユーザの一覧を生成することで、過去のコンテンツの提供の履歴とすることができる。
【０５０３】
サーバ２３は、このようなコンテンツの提供の履歴に基づいてコネクタとなるユーザを特定することができる。図４２は、コネクタとなるユーザを特定する方式を説明する図である。同図においては、Ｕ１、Ｕ２、・・・の記号により表わされる円のノードとして各ユーザが示されている。いま、同図のＵ１と示されたノードのユーザについて、コネクタとなるユーザであるか否かを判定するものとする。
【０５０４】
サーバ２３は、既に蓄積されている実績情報に基づいて、ユーザＵ１が過去３カ月以内にコンテンツを提供したユーザの一覧を生成する。いまの場合、ユーザＵ１は、過去にユーザＵ９とユーザＵ１０にコンテンツを提供していたものとされる。
【０５０５】
サーバ２３は、既に蓄積されている実績情報に基づいて、ユーザＵ９とユーザＵ１０が過去３カ月以内にコンテンツを提供したユーザの一覧を生成する。いまの場合、ユーザＵ９は、ユーザＵ１１、ユーザＵ５、およびユーザＵ１２にコンテンツを提供していたものとされる。また、ユーザＵ１０は、ユーザＵ８、およびユーザＵ１３にコンテンツを提供していたものとされる。
【０５０６】
このようにして、ユーザＵ１についての所属グループが特定される。
【０５０７】
サーバ２３は、ユーザＵ１の携帯端末から新たに送信された実績情報に基づいて、ユーザＵ１からユーザＵ２にコンテンツが提供されたと判定する。サーバ２３は、上述した場合と同様に、既に蓄積されている実績情報に基づいて、ユーザＵ２についての所属グループ（提供先グループと称することにする）を特定する。
【０５０８】
そして、サーバ２３は、所属グループと提供先グループにおいて重複しているユーザの数をカウントする。この例では、ユーザＵ５とユーザＵ８が重複しているので、重複ユーザ数は２とされる。また、サーバ２３は、所属グループと提供先グループにおいて重複していないユーザ（ユニークユーザと称することにする）の数をカウントする。この例では、所属グループと提供先グループのそれぞれにおいて、ユニークユーザ数は５とされる。
【０５０９】
サーバ２３は、例えば、所属グループのユニークユーザ数と提供先グループのユニークユーザ数とを合計し、コネクタとなるユーザの評価値を算出する。そして、算出された評価値に基づいてコネクタとなるユーザが特定されるのである。
【０５１０】
なお、図４２の例では、所属グループおよび提供先グループのグループ深度を３とした場合の例について説明した。すなわち、ユーザＵ１とユーザＵ２のそれぞれを起点として、３階層のコンテンツの提供の履歴に基づいて所属グループおよび提供先グループが形成されている。実際にコネクタとなるユーザを特定する際のグループ深度は、任意に設定されるようにして構わない。
【０５１１】
このように、サーバ２３は、ハブとなるユーザ、またはコネクタとなるユーザを特定することができる。このようなユーザは、例えば、バイラルマーケティングを行うにあたり重要な情報とされている。サーバ２３の運用業者は、上述のように特定したハブとなるユーザ、またはコネクタとなるユーザに関する情報を、例えば、ゲームソフトメーカなどのコンテンツ事業者に有料で提供するなどのサービスを行うことも可能である。
【０５１２】
次に、図４３のフローチャートを参照してサーバ２２の処理について説明する。この処理は、例えば、実績情報に基づくコンテンツの配信が指令されたとき実行される。
【０５１３】
ステップＳ３０１１において、サーバ２２は、実績情報を受信する。このとき、例えば、図３７の携帯端末５１と携帯端末５５から送信された実績情報が受信される。
【０５１４】
ステップＳ３０１２において、サーバ２２は、ステップＳ３０１１で受信した実績情報を解析する。このとき、例えば、コンテンツの提供実績の高い携帯電端末を特定するための解析が行われる。ここでいう、提供実績が高いとは、例えば、単位時間内により多くのユーザにコンテンツを提供したことを意味するものとしてもよいし、ターゲットとなる年齢、性別、住所、趣向のユーザにコンテンツを提供したことを意味するものとしてもよい。例えば、プロモーションにおいて、若年者のファン獲得を目標としている場合、「コンテンツ提供先」に係る情報の中の「年齢」により実績情報をフィルタリングして、閾値未満の年齢のユーザにより多くコンテンツを提供した携帯端末の提供実績が高いものとされる。
【０５１５】
また、このとき、証明書に含まれる情報の内容（ユーザ認証の結果、リンク認証の結果、またはそれらの両方）とその有効性に基づいて実績情報がフィルタリングされるようにしてもよい。
【０５１６】
ステップＳ３０１３において、サーバ２２は、ステップＳ３０１２の処理の結果に基づいて各携帯端末の提供実績の高さを数値化する。
【０５１７】
ステップＳ３０１４において、サーバ２２は、ステップＳ３０１３の処理の結果に基づいて、次回の新曲のコンテンツを優先的に配信するようにする。
【０５１８】
このとき、例えば、ステップＳ３０１３の処理の結果得られた数値を各携帯端末について相互に比較、または予め設定閾値と比較することで、提供実績の高い携帯端末が特定される。そして、例えば、サーバ２２が、携帯端末５１の提供実績が高いと判断した場合、携帯端末５１に対しては次回の新曲のコンテンツを無料でダウンロードさせるようにする。あるいはまた、予め設定された基準より高い提供実績が確認された複数の携帯端末に次回の新曲のコンテンツを無料でダウンロードさせるようにしてもよいし、提供実績の高い順に、時間差を付けて新曲のコンテンツを無料でダウンロードさせるようにしてもよい。
【０５１９】
さらに、例えば、サーバ２２が、携帯端末５１の提供実績が高いと判断した場合、携帯端末５１に対しては次回の新曲のコンテンツを割引価格でダウンロードさせるようにしてもよい。例えば、提供実績の高さに応じてコンテンツの対価が算出されるようにしてもよい。
【０５２０】
あるいはまた、提供実績の高い携帯端末にコンサートのチケットなどの優待特典を付与するようにしてもよい。
【０５２１】
このようにして、サーバ２２の処理が実行される。
【０５２２】
次に、図４４のフローチャートを参照して、サーバ２３の処理について説明する。この処理は、例えば、実績情報に基づくハブユーザやコネクタユーザの特定が指令されたとき実行される。
【０５２３】
ステップＳ３０３１において、サーバ２３は、実績情報を受信する。このとき、例えば、図４０の携帯端末６２と携帯端末６７から送信された実績情報が受信される。
【０５２４】
ステップＳ３０３２において、サーバ２３は、ステップＳ３０３２で受信した実績情報を解析する。
【０５２５】
このとき、例えば、サーバ２３は、実績情報の「ユーザＩＤ」に基づいて個々の携帯端末が何人のユーザにコンテンツを提供したかを表す情報を取得する。そして、サーバ２３は、例えば、実績情報の「コンテンツＩＤ」に基づいて、提供したコンテンツの種類やジャンルなどを特定し、その特定結果に基づいてコンテンツを提供したユーザの重み付けを行う。
【０５２６】
あるいはまた、サーバ２３は、例えば、実績情報の「提供開始日時」または「提供終了日時」に基づいて、コンテンツを提供したユーザの重み付けを行うようにしてもよい。さらに、携帯端末の識別情報に基づいて、サーバ２１から評価情報を取得して、例えば、より長いコメントの評価情報が得られた携帯端末のユーザについてより大きい重みづけがなされるように重み付けがなされてもよい。
【０５２７】
このような解析結果は、後述するハブユーザ特定処理において用いられる。
【０５２８】
またこのとき、例えば、サーバ２３は、各携帯端末のユーザのそれぞれについて、過去３カ月以内にコンテンツを提供したユーザの一覧を生成することで、過去のコンテンツの提供の履歴を生成する。
【０５２９】
このような解析結果は、後述するコネクタユーザ特定処理において用いられる。
【０５３０】
ステップＳ３０３３において、サーバ２３は、ハブユーザ特定処理を実行する。ここでは、例えば、ステップＳ３０３２の処理の結果に基づいて各携帯端末のユーザの評価値が算出される。ユーザの評価値は、例えば、上述した式（１）により演算される。
【０５３１】
これにより、ハブユーザが特定されることになる。
【０５３２】
ステップＳ３０３４において、サーバ２３は、コネクタユーザ特定処理を実行する。ここでは、例えば、ステップＳ３０３２の処理の結果に基づいて、図４２を参照して上述したように、所属グループと提供先グループにおいて重複しているユーザの数がカウントされる。そして、所属グループと提供先グループにおいて重複していないユニークユーザの数がカウントされ、所属グループのユニークユーザ数と提供先グループのユニークユーザ数とを合計し、コネクタとなるユーザの評価値が算出される。
【０５３３】
これにより、コネクタユーザが特定されることになる。
【０５３４】
ステップＳ３０３５において、サーバ２３は、ステップＳ３０３３の処理で特定されたハブユーザのユーザＩＤ、ステップＳ３０３４の処理で特定されたコネクタユーザのユーザＩＤを出力する。
【０５３５】
このようにして、サーバ２３の処理が実行される。
【０５３６】
図３７乃至図４４を参照して上述した実施の形態においては、ハンドオーバ機能を有する携帯端末によるコンテンツの提供に係る実績情報に基づいてサーバ２２が、より効率的なコンテンツの配信を行う例、サーバ２３がハブユーザまたはコネクタユーザを特定する例について説明した。しかし、サーバ２２またはサーバ２３により処理される実績情報は、ハンドオーバ機能を有する携帯端末によるコンテンツの提供に係る実績情報に限られるものではない。例えば、有線の通信によりコンテンツを提供する端末によるコンテンツの提供に係る実績情報が処理されるようにしてもよい。
【０５３７】
また、図３７乃至図４４を参照して上述した実施の形態においては、コンテンツの提供に係る実績情報を取り扱う例について説明したが、例えば、コンテンツ以外の電子情報財の提供に係る実績情報を取り扱う場合にも本発明を適用することが可能である。
【０５３８】
以上においては、ハンドオーバ時に非接触通信が行われ、その後近距離無線通信が行われると説明したが、本発明を適用可能な実施の形態はこれに限られるものではない。例えば、ＮＦＣなどの非接触通信の代わりに、端子を接触させる接触型通信が用いられ、近距離無線通信の代わりに、通常の有線ＬＡＮが用いられるようにしてもよい。
【０５３９】
また、以上においては、サーバと携帯端末などとの間で行われる広域通信は、移動体通信網用無線通信が用いられると説明したが、本発明を適用可能な実施の形態はこれに限られるものではない。例えば、移動体通信網用無線通信の代わりに固定通信網通信や独自のネットワークを用いた通信が用いられるようにしてもよい。
【０５４０】
なお、上述した一連の処理は、ハードウェアにより実行させることもできるし、ソフトウェアにより実行させることもできる。上述した一連の処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが、専用のハードウェアに組み込まれているコンピュータにネットワークや記録媒体からインストールされる。また、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、汎用のパーソナルコンピュータなどに、ネットワークや記録媒体からインストールされる。
【０５４１】
上述した一連の処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが、インターネットなどのネットワークや、リムーバブルメディアなどからなる記録媒体からインストールされる。
【０５４２】
なお、本明細書において上述した一連の処理は、記載された順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理をも含むものである。
【０５４３】
また、本発明の実施の形態は、上述した実施の形態に限定されるものではなく、本発明の要旨を逸脱しない範囲において種々の変更が可能である。
【符号の説明】
【０５４４】
１０  評価情報収集システム，  ２１  サーバ，  ３１乃至３３  情報収集端末，  ４１乃至４７  携帯端末，  ５１乃至５７  携帯端末，  ６１乃至６７  携帯端末，  １１１  ＣＰＵ  １１２  ＲＯＭ  １１３  ＲＡＭ  １２３  記憶部，  １２６  リムーバブルメディア，  １３１  移動体通信網用無線通信部，  １３２  近距離無線通信部，  １３３  非接触通信部，  ２０１  ＣＰＵ  ２０２  ＲＯＭ  ２０３  ＲＡＭ  ２１３  記憶部，  ２１４  通信部，  ２１６  リムーバブルメディア，  ２２１  評価情報データベース，  ２２２  端末機器データベース
【図１】
0005728975.tif 000003
【図２】
0005728975.tif 000004
【図３】
0005728975.tif 000005
【図４】
0005728975.tif 000006
【図５】
0005728975.tif 000007
【図６】
0005728975.tif 000008
【図７】
0005728975.tif 000009
【図８】
0005728975.tif 000010
【図９】
0005728975.tif 000011
【図１０】
0005728975.tif 000012
【図１１】
0005728975.tif 000013
【図１２】
0005728975.tif 000014
【図１３】
0005728975.tif 000015
【図１４】
0005728975.tif 000016
【図１５】
0005728975.tif 000017
【図１６】
0005728975.tif 000018
【図１７】
0005728975.tif 000019
【図１８】
0005728975.tif 000020
【図１９】
0005728975.tif 000021
【図２０】
0005728975.tif 000022
【図２１】
0005728975.tif 000023
【図２２】
0005728975.tif 000024
【図２３】
0005728975.tif 000025
【図２４】
0005728975.tif 000026
【図２５】
0005728975.tif 000027
【図２６】
0005728975.tif 000028
【図２７】
0005728975.tif 000029
【図２８】
0005728975.tif 000030
【図２９】
0005728975.tif 000031
【図３０】
0005728975.tif 000032
【図３１】
0005728975.tif 000033
【図３２】
0005728975.tif 000034
【図３３】
0005728975.tif 000035
【図３４】
0005728975.tif 000036
【図３５】
0005728975.tif 000037
【図３６】
0005728975.tif 000038
【図３７】
0005728975.tif 000039
【図３８】
0005728975.tif 000040
【図３９】
0005728975.tif 000041
【図４０】
0005728975.tif 000042
【図４１】
0005728975.tif 000043
【図４２】
0005728975.tif 000044
【図４３】
0005728975.tif 000045
【図４４】
0005728975.tif 000046