以下、図面を参照して、本発明の実施の形態について説明する。
本発明においては、例えば、携帯端末のハンドオーバ機能を利用して評価情報を収集するようにする。
例えば、携帯電話機として構成される携帯端末がBluetooth(登録商標)やWiFi(登録商標)等の近距離無線通信手段を有する場合がある。その場合携帯電話同士が直接(ローカルで)通信可能することができる。さらに、携帯電話機が、非接触通信(NFC(Near Field Communication))デバイスを有する場合、ユーザが携帯電話機同士を近接(または接触)させることにより、非接触通信デバイスによって接続認証が行われ、近距離無線通信が可能となるようにすることができる。このように、非接触通信デバイスによって接続認証が行われ、近距離無線通信が行われるようにする機能がハンドオーバと称される。
このようなハンドオーバ機能を利用することにより、ユーザは、携帯電話機同士をタッチするだけで、サービスの提供を受けたり、商品を購入したりすることが可能となる。例えば、商品としてコンテンツを購入する際に、ユーザは、携帯電話機同士をタッチするだけで、近距離無線通信によってコンテンツのデータを携帯端末にダウンロードすることが可能となる。
図1は、本発明の一実施の形態に係る評価情報収集システムの構成例を示す図である。同図の例では、評価情報収集システム10がサーバ21、情報収集端末31乃至情報収集端末33、および、携帯端末41乃至携帯端末43により構成されている。
サーバ21は、例えば、評価情報収集事業者のデータセンタに設置され、情報収集端末31乃至情報収集端末33から送信される評価情報を取得し、取得した評価情報の保存、加工などの処理を行うようになされている。サーバ21は、例えば、取得した評価情報を、評価の対象となった商品やサービスの種類毎に分類し、ネットワークを介してアクセスしてくるユーザに提供するなどの処理を行う。
情報収集端末31乃至情報収集端末33は、それぞれ携帯端末41乃至携帯端末43のハンドオーバ機能により通信する端末とされ、近距離無線通信手段と非接触通信デバイスを有する構成とされる。
例えば、情報収集端末31は、楽曲のコンテンツの試聴サービスを提供する機器として構成される。情報収集端末31は、例えば、ユーザが携帯端末41を所定の領域にタッチさせるなどした場合、非接触通信の後、近距離無線通信によってコンテンツのデータの一部を送信して携帯端末41にコンテンツをストリーミング再生させる。これにより、ユーザは、携帯端末41に接続されたヘッドフォンなどを装着してコンテンツを試聴することが可能となる。
また、情報収集端末32は、例えば、飲食店で利用されるPOS端末などの機器として構成される。情報収集端末32は、例えば、ユーザが携帯端末42を所定の領域にタッチさせるなどした場合、非接触通信の後、近距離無線通信によってメニューや注文フォーマットのGUIデータなどを送信して携帯端末42に表示させる。これにより、ユーザは、携帯端末42から所望のメニューを注文したり、またアンケートに回答して優待ポイントを取得したりすることができる。
情報収集端末33は、例えば、ショッピングモールやテーマパークなどの所定のエリアに設置された無線通信ハブなどの機器として構成される。情報収集端末33は、例えば、ユーザが携帯端末43を所定の領域にタッチさせるなどした場合、非接触通信の後、近距離無線通信によってゲームのコンテンツのデータを送信する。これにより、ユーザは、携帯端末43においてゲームを楽しむことが可能となる。
情報収集端末31乃至情報収集端末33のそれぞれは、近距離無線通信手段と非接触通信デバイスとは別に、サーバ21との通信を行うための広域通信手段を有している。広域通信手段としては、例えば、最寄りの無線基地局と無線通信を行い、移動体通信網を介した通信を行う無線通信デバイスなどとされる。あるいはまた、専用線によってサーバ21と接続される構成としてもよい。
携帯端末41と携帯端末42は、例えば、携帯電話機として構成され、携帯端末43は、例えば、ゲーム機として構成される。携帯端末41乃至携帯端末43は、それぞれハンドオーバ機能により通信する端末とされ、近距離無線通信手段と非接触通信デバイスを有する構成とされる。また、これらとは別に、例えば、最寄りの無線基地局と無線通信を行い、移動体通信網を介した通信を行う無線通信デバイスを有している。
図1の例では、例えば、情報収集端末31に蓄積された情報であって、各コンテンツの再生指令の回数、非接触通信によって取得された携帯端末41のユーザの属性情報などが評価情報としてサーバ21に送信される。
また、例えば、情報収集端末32に蓄積された情報であって、メニュー毎の注文回数、アンケートの回答などが評価情報としてサーバ21に送信される。
さらに、例えば、情報収集端末33に蓄積された情報であって、ゲームの操作情報などが評価情報としてサーバ21に送信される。
なお上述したように、情報収集端末31乃至情報収集端末33からサーバ21への評価情報の送信には、広域通信手段が用いられる。
図2は、本発明の一実施の形態に係る評価情報収集システムの別の構成例を示す図である。同図の例では、評価情報収集システム10がサーバ21、および、携帯端末44乃至携帯端末47により構成されている。
携帯端末44乃至携帯端末47は、それぞれ図1の携帯端末41と携帯端末42と同様に、携帯電話機として構成される。図2の例の場合、携帯端末45のユーザと携帯端末47のユーザがそれぞれコンテンツの提供者となり、携帯端末44のユーザと携帯端末46のユーザがそれぞれコンテンツの評価者となる。
図2の例において、サーバ21は、やはり評価情報収集事業者のデータセンタなどに設置され、携帯端末45と携帯端末47から送信される評価情報を取得し、取得した評価情報の保存、加工などの処理を行うようになされている。
例えば、携帯端末45のユーザが、友人に薦めたい楽曲のコンテンツのデータを携帯端末45にダウンロードしたものとする。携帯端末44と携帯端末45をタッチさせるなどした場合、非接触通信の後、近距離無線通信によって携帯端末45からコンテンツのデータを送信して携帯端末44にコンテンツをストリーミング再生させる。これにより、携帯端末44のユーザはヘッドフォンなどを装着してコンテンツを試聴することが可能となる。そして、携帯端末44のユーザは、近距離無線通信によって楽曲の評価(例えば、簡単なコメントなど)を携帯端末45に送信する。
また、例えば、携帯端末47のユーザが、ネットワークゲームを楽しんでおり、携帯端末46のユーザである友人もこのネットワークゲームに参加させたいと考えていたとする。携帯端末46と携帯端末47をタッチさせるなどした場合、非接触通信の後、近距離無線通信によって携帯端末47からゲームのデータを送信して携帯端末46にゲームの画面などを表示させる。
これにより、携帯端末46のユーザは、携帯端末47のユーザが楽しんでいるネットワークゲームに参加することが可能となる。そして、近距離無線通信によって携帯端末46からユーザのプロフィールなどの情報やゲームの操作情報などが携帯端末47に送信される。
図2の例の場合、例えば、携帯端末45に蓄積された情報であって、楽曲に対するコメントなどが評価情報としてサーバ21に送信される。
また、例えば、携帯端末47に蓄積された情報であって、ゲームの操作情報などが評価情報としてサーバ21に送信される。
なお、携帯端末45および携帯端末47からサーバ21への評価情報の送信には、広域通信手段が用いられる。
このように、本発明の評価情報収集システム10においては、収集される評価情報がユーザコメント方式などに偏ったものとならず、例えば、各コンテンツについてのユーザの視聴実績などの情報も評価情報として収集することができる。
図3は、図1または図2の携帯端末の構成例を示すブロック図である。同図は、携帯端末41の構成とされているが、同図の構成を携帯端末42乃至携帯端末47に適用することも可能である。
図3において、携帯端末41のCPU(Central Processing Unit)111は、ROM(Read Only Memory)112に記憶されているプログラム、または記憶部123からRAM(Random Access Memory)113にロードされたプログラムに従って各種の処理を実行する。RAM113にはまた、CPU111が各種の処理を実行する上において必要なデータなども適宜記憶される。
CPU111、ROM112、およびRAM113は、バス114を介して相互に接続されている。このバス114にはまた、入出力インタフェース120も接続されている。
入出力インタフェース120には、キーボード、マウスなどよりなる入力部121、LCD(Liquid Crystal Display)などよりなるディスプレイ、並びにスピーカなどよりなる出力部122、および、ハードディスクやフラッシュメモリなどより構成される記憶部123が接続されている。
入出力インタフェース120にはまた、必要に応じてドライブ125が接続され、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリなどのリムーバブルメディア126が適宜装着され、それらから読み出されたコンピュータプログラムが、必要に応じて記憶部123にインストールされる。
入出力インタフェース120にはさらに、移動体通信網用無線通信部131、近距離無線通信部132、および非接触通信部133が接続されている。
移動体通信網用無線通信部131は、図示せぬ無線基地局と無線通信を行い、移動体通信網を介した通信を行う無線通信デバイスである。移動体通信網用無線通信部131は、例えば2GHzの周波数帯を使い、通話アプリケーションだけでなく、最大2Mbpsのデータ通信を用いてインターネット接続など各種通信アプリケーションに利用される。例えば、移動体通信網用無線通信部131による無線通信は、コンテンツデータのダウンロードやサーバ21との通信等に用いられる。なお、移動体通信網用無線通信部131は、例えば、いわゆる第3世代携帯電話の通信方式による通信が可能なデバイスなどとして構成されることが想定されている。
近距離無線通信部132は、例えば、Bluetooth(登録商標、BTとも称する)やIEEE(Institute of Electrical and Electronic Engineers)802.11x等の近距離無線通信デバイスである。ここで、近距離無線通信とは、通信可能最大距離が数メートル乃至数十メートル程度のローカルな(狭域の)無線通信を意味する。通信規格は任意である。例えば、近距離無線通信部132がBTの通信を行うものである場合は、アンテナを経由して2.4GHz帯にて最大通信速度3Mビット/秒(バージョン2.0+EDR以降)の通信を行う。
非接触通信部133は、NFC(Near Field Communication)デバイスである。ここで非接触通信とは、通信可能最大距離が数十センチ程度のローカルな(狭域の)無線通信を示す。通信規格は任意である。例えば、非接触通信部133は、アンテナを経由して13.56MHz帯の周波数を使い、10cm程度の極近距離で最大424Kビット/秒の通信レートにて通信を行う。
非接触通信部133による非接触通信は、筐体を接触若しくは近接された携帯端末に対して、近距離無線通信部132による近距離無線通信接続の確立に必要な情報や、送信可能なコンテンツのリスト等が記述されたメッセージの授受に利用される。
携帯端末41の各部は、CPU111により制御される。制御プログラムの実行バイナリコードはROM112や記憶部123に保存されており、各種演算処理のためスタック、ヒープ領域はRAM113上に展開される。
なお、情報収集端末31乃至情報収集端末33も、図3の例と同様に構成されるので、詳細な説明は省略する。
図4は、図1または図2のサーバの構成例を示すブロック図である。
同図に示されるように、サーバ21は、携帯端末41の場合と同様に、バス204を介して互いに接続されるCPU201、ROM202、およびRAM203を有する。また、バス204には、入出力インタフェース210が接続される。
この入出力インタフェース210には、携帯端末41の場合と同様に、入力部211、出力部212、記憶部213、およびリムーバブルメディア216用のドライブ215が接続される。
図4のCPU201、ROM202、RAM203、バス204、入出力インタフェース210、入力部211、出力部212、記憶部213、ドライブ215、およびリムーバブルメディア216は、それぞれ、図2のCPU111、ROM112、RAM113、バス114、入出力インタフェース120、入力部121、出力部122、記憶部123、ドライブ125、およびリムーバブルメディア126に対応する。
サーバ21は、また、入出力インタフェース210に接続される通信部214を有する。この通信部214は、ネットワークを介して他の装置と通信を行う通信デバイスである。例えば、通信部214は、有線のネットワークを介して移動体通信網に接続され、携帯端末や情報収集端末との通信に利用される。
入出力インタフェース210には、さらに、評価情報データベース221および端末機器データベース222が接続される。
評価情報データベース221は、携帯端末や情報収集端末から送信された評価情報を記憶するようになされている。評価情報データベース221は、例えば、評価情報を、評価の対象となった商品やサービスの種類毎に分類し、必要に応じて商品などの識別情報、評価者の識別情報、評価日時などをキーとして検索できるようにデータベース化する。
端末機器データベース222は、携帯端末や情報収集端末(適宜端末機器と称する)の通信機能に係る情報(端末機器情報)を、端末毎に記憶するようになされている。
図5は、端末機器データベース222に記憶される情報の例を示す図である。同図は、例えば、所定の識別番号を有する携帯端末の端末機器情報の例とされる。
図5に示される「広域通信種別」は、当該携帯端末の広域通信手段の種別を特定する情報とされ、例えば、3G(IMT-2000)、WiMAX(Worldwide Interoperability for Microwave Access)などの情報が記述される。
「広域通信アドレス」には、上述の広域通信手段を用いて通信する際のアドレスを特定する情報が記述される。
「近距離無線通信種別」は、当該携帯端末の近距離無線通信手段の種別を特定する情報とされ、例えば、Bluetooth(登録商標)、Wi−Fiなどの情報が記述される。
「近距離無線通信アドレス」には、上述の近距離無線通信手段を用いて通信する際のアドレスを特定する情報が記述される。
「非接触通信方式」は、当該携帯端末の非接触通信により可能となる通信の方式を特定する情報とされ、例えば、「データ応答のみ」、「データ取得のみ」、「データ送受信可能」といった情報が記述される。
「固有鍵」は、当該携帯端末に予め記憶されている秘密鍵を表す情報とされる。なお、当該携帯端末がセキュリティモジュールを有する場合、セキュリティモジュールへのアクセスに必要な鍵の情報が記述される。
「提供者区分」は、当該携帯端末が商品やサービスの提供者の携帯端末であるか否かを特定する情報、または、商品やサービスの提供の方式などを特定する情報とされ、それを表す情報が記述される。
このように、サーバ21の端末機器データベース222には、情報収集端末31の端末機器情報、情報収集端末32の端末機器情報、・・・、携帯端末41の端末機器情報、携帯端末42の端末機器情報、・・・が記憶されている。すなわち、端末機器データベース222には、評価情報収集システム10に参加し得る端末機器の端末機器情報が、それぞれの識別情報に対応付けられて記憶されている。
このように、本発明の評価情報収集システム10においては、携帯端末のハンドオーバ機能を利用して評価情報を収集するようになされている。ハンドオーバ機能を利用して収集された評価情報は、商品やサービスの提供者と評価者が極めて接近して得られた評価情報である。ハンドオーバ機能は、近接された携帯端末の非接触通信デバイスによって接続認証が行われ、近距離無線通信が行われるからである。
このようにして収集された評価情報は、実際に商品やサービスの提供を受けたユーザの生の声として有益であり、商品やサービスの購入にあたって参考になると考えられる。例えば、ハンドオーバ機能を利用して収集された評価情報は、雑誌に掲載される商品やサービスの紹介記事とは異なり、実際にその商品やサービスの提供を受けたユーザがそのまま評価したものと考えられるからである。また、ハンドオーバ機能を利用して収集された評価情報は、インターネット上の掲示板に書き込まれる情報と異なり、実際にその商品やサービスの提供を受けていない者からは収集されないからである。
しかしながら、ハンドオーバ機能を利用して評価情報を収集する場合、その評価情報が本当にハンドオーバ機能を利用して収集されたものなのかを証明することは難しい。すなわち、上述のように近距離無線通信によって商品やサービスの提供を受けた直後に収集された評価情報であるからこそ、ハンドオーバ機能を利用して収集された評価情報が有益であると解される。例えば、サーバ21が携帯端末や情報収集端末からバッチ方式で評価情報を収集するとした場合、商品やサービスの提供者が自分にとって都合のよい評価情報だけ送信したり、または評価情報を偽造したりしているのではないかという疑念を払拭し難い。
勿論、評価情報収集事業者は、公正な情報収集に努めると考えられるが、例えば、特定の商品の評価が他の商品と比較して極めて高いものであった場合、評価情報を参照した者は、何らかの不正があったのではないかと勘ぐってしまう。さらに、商品やサービスの提供者に悪意がなかったとしても、ソフトウェアのトラブルなどによって、評価情報の送信に失敗したり、送信済の評価情報が繰り返し送信されたりした場合、結果として偏った評価が形成されることになる。このような事態が発生すると、その後、サーバ21が提供する評価情報の信頼性に係る評価は著しく低下すると考えられる。
そこで、本発明では、サーバ21が評価情報を収集する際に、提供者の携帯端末または情報収集端末と評価者の携帯端末との間で近距離無線通信が継続して行われていることを確認できるようにする。これにより、商品やサービスの提供を受けた直後に収集された評価情報であることが証明される。
詳細は後述するが、本発明では、提供者の携帯端末または情報収集端末と評価者の携帯端末との間でのハンドオーバが、直ちにサーバ21に通知されるようになされている。そして、サーバ21は、例えば、提供者の携帯端末または情報収集端末に広域通信手段を利用してアクセスし、同一の評価者の携帯端末との間で近距離無線通信が継続して行われていることを確認するようになされている。
同一の評価者の携帯端末との間で近距離無線通信が継続して行われていることの確認は、例えば、次のようにして行うことができる。ハンドオーバの通知があった場合、サーバ21から評価者の携帯端末に所定の認証情報を送信し、ハンドオーバ後の近距離無線通信において評価者の携帯端末から認証情報が送信されていること確認する。なお、同一の評価者の携帯端末との間で近距離無線通信が継続して行われていることの確認を、リンク認証と称することにする。
図6は、評価情報収集システム10において、リンク認証を行って評価情報を収集する方式の例を説明する図である。同図の例では、情報収集端末31と携帯端末41との間でハンドオーバが行われ、非接触通信(NFC通信)の後、近距離無線通信(BT)によってコンテンツのデータの一部が送信されてストリーミング再生が行われる場合の例を示している。
同図の例において、情報収集端末31と携帯端末41との間でハンドオーバが情報収集端末31からサーバ21に広域通信を用いて通知される。このとき、情報収集端末31の識別番号と携帯端末41の識別番号も、サーバ21に送信される。するとサーバ21は、乱数を発生させ、その乱数を携帯端末41の固有鍵を用いて暗号化する。なお、携帯端末41の固有鍵は、端末機器データベース222を、携帯端末41の識別番号を用いて検索することにより、取得することができる。
サーバ21は、暗号化した乱数(暗号化乱数と称する)を情報収集端末31の広域通信アドレス宛に送信する。なお、情報収集端末31の広域通信アドレスは、端末機器データベース222を、情報収集端末31の識別番号を用いて検索することにより、取得することができる。
情報収集端末31は、サーバ21から送信された暗号化乱数を近距離無線通信によって携帯端末41に送信する。
携帯端末41は、暗号化乱数を自分の固有鍵で復号し、乱数を得る。そして、携帯端末41は、その乱数を近距離無線通信によって情報収集端末31に送信する。
情報収集端末31は、携帯端末41から送信された乱数を広域通信によってサーバ21に送信する。
サーバ21は、情報収集端末31から送信された乱数を、自分が発生した乱数と比較し、両者が一致する場合、ハンドオーバ時の評価者との近距離無線通信が行われていると確認する。すなわち、評価者の同一性を確認することができる。
その後、情報収集端末31から近距離無線通信によってコンテンツのデータの一部が送信されて、携帯端末41によりコンテンツのストリーミング再生が行われる。携帯端末41は、この際、評価情報を情報収集端末31に送信する。
このように、情報収集端末31と携帯端末41との間で、近距離無線通信によってコンテンツのデータの送信、評価情報の送信が行われている間、サーバ21は、例えば、一定の周期で継続して(定期的に)上述したように評価者の同一性を確認する。
そして、情報収集端末31に蓄積された評価情報が広域通信によりサーバ21に送信される。
このようにすることで、評価情報収集システム10において、リンク認証を行って評価情報を収集する。
図7は、図6を参照して上述したリンク認証を行って評価情報を収集する処理の流れを説明するアローチャートである。
同図においては、情報収集端末31の移動体通信網用無線通信部131が、3G131−1と記載されており、携帯端末41の移動体通信網用無線通信部131が、3G131−2と記載されている。また、情報収集端末31の近距離無線通信部132が、BT132−1と記載されており、携帯端末41の近距離無線通信部132が、BT132−2と記載されている。さらに、情報収集端末31の非接触通信部133が、NFC133−1と記載されており、携帯端末41の非接触通信部133が、NFC133−2と記載されている。
なお、ここでの3Gは、W-CDMA方式やCDMA2000方式などのデジタル携帯電話の通信方式であって、いわゆる第3世代携帯電話(3G)を意味している。
ステップS11において、情報収集端末31のNFC133−1は、ハンドオーバメッセージを送信し、ステップS101において、携帯端末41のNFC133−2によりこれが受信される。
ステップS102において、NFC133−2は、ハンドオーバメッセージを送信し、ステップS12において、NFC133−1によりこれが受信される。
ここまでの処理により、情報収集端末31と携帯端末41により対向機器情報の交換が行われることになる。なお、対向機器情報とは、ハンドオーバの相手の機器の識別番号、近距離無線通信アドレスなどの情報とされる。
ステップS13において、NFC133−1からBT132−1に対向機器情報が通知され、ステップS31でBT132−1によりこれが取得される。また、ステップS103において、NFC133−2からBT132−2に対向機器情報が通知され、ステップS121でBT132−2によりこれが取得される。なお、実際には、CPU111を介して対向機器情報、その他の情報の通知が行われる。以下においても同様である。
ステップS14において、NFC133−1は、3G131−1に対向機器情報を通知し、ステップS51で、3G131−1によりこれが取得される。
ステップS52において、3G131−1は、対向機器情報を含む情報をサーバ21に送信することで、ハンドオーバの通知を行い、ステップS71でサーバ21によりこれが取得される。なお、サーバ21にハンドオーバの通知を行う際には、ハンドオーバの相手の対向機器情報だけでなく、自分(いまの場合、情報収集端末31)の対向機器情報もともに送信されるものとする。
ステップS32において、BT132−1からBT132−2へBT接続要求が送信され、ステップS122でこれが受信される。
ステップS72において、サーバ21は、乱数を発生させ、ステップS73でこれを暗号化する。ステップS74において、サーバ21は、ステップS73の処理により得られた暗号化乱数を確認要求として送信し、ステップS53で3G131−1によりこれが受信される。
ステップS54において、3G131−1は、ステップS53で受信した確認要求をBT132−1に通知し、ステップS33でこれが取得される。
ステップS34において、BT132−1は、ステップS33で取得した確認要求を送信し、ステップS123においてBT132−2によりこれが受信される。
ステップS124において、BT132−2は、ステップS123で受信した確認要求の暗号化乱数を復号して乱数を得る。なお、暗号化乱数の復号は、実際には、CPU111により行われる。
ステップS125において、BT132−2は、ステップS124の処理で得た乱数を確認応答として送信し、ステップS35でBT132−1によりこれが受信される。
ステップS36において、BT132−1は、ステップS35で受信した確認応答を3G131−1に通知し、ステップS55でこれが取得される。
ステップS56において、3G131−1は、ステップS55で取得した確認応答を送信し、ステップS75でサーバ21によりこれが受信される。
ステップS37とステップS126では、コンテンツデータの送受信が行われ、ステップS127とステップS38では、評価情報としての操作情報の送受信が行われる。
ステップS39において、BT132−1は、評価情報を3G131−1に通知し、ステップS57でこれが取得される。
ステップS58において、3G131−1は、ステップS57で取得した評価情報を送信し、ステップS76でサーバ21によりこれが受信される。
なお、図中点線で囲まれた部分の処理が評価者の同一性の確認のための処理として定期的に実行されることになる。
このようにして、リンク認証を行って評価情報を収集する処理が実行される。
なお、図7の説明において適宜記載した通り、この例では、アローチャートの各ステップを実行する主体が、3G131−1、BT132−1、・・・などのように記載されているが、これは便宜上のものである。すなわち、本発明においては、非接触通信、近距離無線通信、広域通信の3種類の通信方式が用いられるために、各ステップにおいて送信、受信などされる情報がどの通信方式であるのか分かりやすくするために、このように記載している。従って、実際には、各ステップに係る処理の実行はCPU111などにより行われる。以下のアローチャートについても同様である。
ところで、図6を参照して上述した例においては、携帯端末41が固有鍵を保持している場合の例について説明したが、携帯端末41が固有鍵を保持していない場合もある。そのような場合、例えば、図8に示されるようにして評価者の同一性を確認することができる。
図8は、評価情報収集システム10において、リンク認証を行って評価情報を収集する方式の別の例を説明する図である。同図の例では、情報収集端末31と携帯端末41との間でハンドオーバが行われ、非接触通信(NFC通信)の後、近距離無線通信(BT)によってコンテンツのデータの一部が送信されてストリーミング再生が行われる場合の例を示している。図8の例の場合、図6の場合と異なり、携帯端末41が固有鍵を保持していない。
図8の例の場合、情報収集端末31と携帯端末41との間でハンドオーバが情報収集端末31からサーバ21に広域通信を用いて通知される。このとき、情報収集端末31の識別番号と携帯端末41の識別番号も、サーバ21に送信される。するとサーバ21は、乱数を発生させるが、携帯端末41が固有鍵を保持していないことを確認する。なお、携帯端末41が固有鍵を保持していないことは、端末機器データベース222を、携帯端末41の識別番号を用いて検索することにより確認できる。
サーバ21は、乱数を一時キーとして携帯端末41の広域通信アドレス宛に送信する。なお、携帯端末41の広域通信アドレスは、端末機器データベース222を、携帯端末41の識別番号を用いて検索することにより、取得することができる。
サーバ21は、情報収集端末31の広域アドレスに確認要求を送信し、近距離無線通信によって情報収集端末31から携帯端末41に確認要求が伝送される。
携帯端末41は、確認要求に対する応答として一時キーを近距離無線通信によって情報収集端末31に送信し、情報収集端末31は、広域通信によってその応答をサーバ21に伝送する。
サーバ21は、情報収集端末31から送信された一時キーを、自分が発生した乱数と比較し、両者が一致する場合、ハンドオーバ時の評価者との近距離無線通信が行われていると確認する。すなわち、評価者の同一性を確認することができる。
その後、情報収集端末31から近距離無線通信によってコンテンツのデータの一部が送信されて、携帯端末41によりコンテンツのストリーミング再生が行われる。携帯端末41は、この際、評価情報を情報収集端末31に送信する。
このように、情報収集端末31と携帯端末41との間で、近距離無線通信によってコンテンツのデータの送信、評価情報の送信が行われている間、サーバ21は、例えば、一定の周期で継続して(定期的に)上述したように評価者の同一性を確認する。
そして、情報収集端末31に蓄積された評価情報が広域通信によりサーバ21に送信される。
このようにすることで、携帯端末41が固有鍵を保持していない場合でも、評価情報収集システム10において、リンク認証を行って評価情報を収集する。
図9は、図8を参照して上述したリンク認証を行って評価情報を収集する処理の流れを説明するアローチャートである。
ステップS11において、情報収集端末31のNFC133−1は、ハンドオーバメッセージを送信し、ステップS101において、携帯端末41のNFC133−2によりこれが受信される。
ステップS102において、NFC133−2は、ハンドオーバメッセージを送信し、ステップS12において、NFC133−1によりこれが受信される。
ここまでの処理により、情報収集端末31と携帯端末41により対向機器情報の交換が行われることになる。なお、対向機器情報とは、ハンドオーバの相手の機器の識別番号、近距離無線通信アドレスなどの情報とされる。また、対向機器情報には、必要に応じてサーバ21の広域通信のアドレスが含まれるものとする。
ステップS13において、NFC133−1からBT132−1に対向機器情報が通知され、ステップS31でBT132−1によりこれが取得される。また、ステップS103において、NFC133−2からBT132−2に対向機器情報が通知され、ステップS121でBT132−2によりこれが取得される。
ステップS122において、BT132−2は、ステップS121で取得した対向機器情報を3G131−2に通知し、ステップS141でこれが取得される。なお、ステップS122とステップS141の処理は省略されるようにしてもよい。
ステップS14において、NFC133−1は、3G131−1に対向機器情報を通知し、ステップS51で、3G131−1によりこれが取得される。
ステップS52において、3G131−1は、対向機器情報を含む情報をサーバ21に送信することで、ハンドオーバの通知を行い、ステップS71でサーバ21によりこれが取得される。なお、サーバ21にハンドオーバの通知を行う際には、ハンドオーバの相手の対向機器情報だけでなく、自分(いまの場合、情報収集端末31)の対向機器情報もともに送信されるものとする。
ステップS32において、BT132−1からBT132−2へBT接続要求が送信され、ステップS123でこれが受信される。
ステップS72とステップS73において、サーバ21は、乱数を発生させ、これを一時キーとする。ステップS74において、サーバ21は、ステップS73の処理により得られた一時キーを送信し、ステップS142で3G131−2によりこれが受信される。
ステップS143において、3G131−2は、ステップS142で受信した一時キーをBT312−2に通知し、ステップS124でこれが取得される。
ステップS75において、サーバ21は、確認要求を送信し、ステップS53において、3G131−1によりこれが受信される。
ステップS54において、3G131−1は、ステップS53で受信した確認要求をBT132−1に通知し、ステップS33でこれが取得される。
ステップS34において、BT132−1は、ステップS33で取得した確認要求を送信し、ステップS125においてBT132−2によりこれが受信される。
ステップS126において、BT132−2は、ステップS125で受信した確認要求に対する応答として、ステップS124で得られた一時キーを送信し、ステップS35でBT132−1によりこれが受信される。
ステップS36において、BT132−1は、ステップS35で受信した確認応答を3G131−1に通知し、ステップS55でこれが取得される。
ステップS56において、3G131−1は、ステップS55で取得した確認応答を送信し、ステップS76でサーバ21によりこれが受信される。
その後、コンテンツデータの送受信、評価情報としての操作情報の送受信などが行われることになるが、これらの処理は、図7を参照して説明した場合と同様なので詳細な説明は省略する。
なお、図中点線で囲まれた部分の処理が評価者の同一性の確認のための処理として定期的に実行されることになる。
このようにして、リンク認証を行って評価情報を収集する処理が実行される。
ところで、図6を参照して上述した例と図8を参照して上述した例においては、情報収集端末31のみから取得した情報に基づいてリンク認証が行われることになる。しかしながら、この方式は、サーバ21を運用する評価情報収集事業者などと、情報収集端末31を運用するコンテンツの提供者との間に十分な信頼関係がない場合、有効に機能しないことがある。なお、情報収集端末31を運用するコンテンツの提供者が信頼できるものであることを表すために、図6と図8においては、情報収集端末31に「Trusted」と記されている。
例えば、コンテンツの提供者が信頼できない者である場合、携帯端末41によって復号されて得られた乱数、携帯端末41が広域通信により受信した一時キーがそのままサーバ21に送信されているという確証はもてない。すなわち、図7のステップS56、図9のステップS56で送信される確認応答が情報収集端末31によって偽造されたものである可能性を否定することができない。
このため、評価情報収集事業者などとコンテンツの提供者との間に十分な信頼関係がない場合、提供者側から送信される情報に基づいて評価者の同一性を確認するだけでは足りず、さらに評価者側から送信される情報に基づいて提供者の同一性を確認する必要がある。すなわち、例えば、提供者が評価者になりすますなどの可能性を否定できないから、ハンドオーバ時の提供者と評価者が継続して近距離無線通信を行っていることを、提供者側と評価者側のそれぞれから確認する必要がある。
図10は、評価情報収集システム10において、リンク認証を行って評価情報を収集する方式のさらに別の例を説明する図である。同図の例では、携帯端末47と携帯端末46との間でハンドオーバが行われ、非接触通信(NFC通信)の後、近距離無線通信(BT)によってコンテンツ(例えば、ゲーム)のデータが送信される場合の例を示している。
図10の例の場合、図6または図8の場合と異なり、コンテンツの提供者である携帯端末47に「Trusted」と記されていない。すなわち、図10の例の場合、評価情報収集事業者などとコンテンツの提供者との間に十分な信頼関係がないのである。なお、同図の例では、携帯端末46と携帯端末47はともに固有鍵を保持しているものとする。
図10の例において、携帯端末47と携帯端末46との間でのハンドオーバが携帯端末47からサーバ21に広域通信を用いて通知される。このとき、携帯端末47と携帯端末46の識別番号も、サーバ21に送信される。するとサーバ21は、乱数を発生させ、その乱数を携帯端末46の固有鍵を用いて暗号化する。なお、携帯端末46の固有鍵は、端末機器データベース222を、携帯端末46の識別番号を用いて検索することにより、取得することができる。
サーバ21は、暗号化した乱数(暗号化乱数と称する)を携帯端末47の広域通信アドレス宛に送信する。なお、携帯端末47の広域通信アドレスは、端末機器データベース222を、携帯端末47の識別番号を用いて検索することにより、取得することができる。
携帯端末47は、サーバ21から送信された暗号化乱数を近距離無線通信によって携帯端末46に送信する。
携帯端末46は、暗号化乱数を自分の固有鍵で復号し、乱数を得る。そして、携帯端末46は、その乱数を近距離無線通信によって携帯端末47に送信する。
携帯端末47は、携帯端末46から送信された乱数を広域通信によってサーバ21に送信する。
サーバ21は、携帯端末47から送信された乱数を、自分が発生した乱数と比較し、両者が一致する場合、ハンドオーバ時の評価者との近距離無線通信が行われていると確認する。すなわち、提供者側から送信される情報に基づいて評価者の同一性を確認することができる。
また、サーバ21は、別の乱数を発生させ、その乱数を携帯端末47の固有鍵を用いて暗号化する。なお、携帯端末47の固有鍵は、端末機器データベース222を、携帯端末47の識別番号を用いて検索することにより、取得することができる。
サーバ21は、暗号化した乱数(暗号化乱数と称する)を携帯端末46の広域通信アドレス宛に送信する。なお、携帯端末46の広域通信アドレスは、端末機器データベース222を、携帯端末46の識別番号を用いて検索することにより、取得することができる。
携帯端末46は、サーバ21から送信された暗号化乱数を近距離無線通信によって携帯端末47に送信する。
携帯端末47は、暗号化乱数を自分の固有鍵で復号し、乱数を得る。そして、携帯端末47は、その乱数を近距離無線通信によって携帯端末46に送信する。
携帯端末46は、携帯端末47から送信された乱数を広域通信によってサーバ21に送信する。
サーバ21は、携帯端末46から送信された乱数を、自分が発生した乱数と比較し、両者が一致する場合、ハンドオーバ時の提供者との近距離無線通信が行われていると確認する。すなわち、評価者側から送信される情報に基づいて提供者の同一性を確認することができる。
その後、携帯端末47から近距離無線通信によってコンテンツのデータが送信されて、携帯端末46によりゲームの画面などが表示される。携帯端末46は、この際、評価情報を携帯端末47に送信する。
このように、携帯端末47と携帯端末46との間で、近距離無線通信によってコンテンツのデータの送信、評価情報の送信が行われている間、サーバ21は、例えば、一定の周期で継続して(定期的に)上述したように評価者の同一性と提供者の同一性を確認する。
そして、携帯端末47に蓄積された評価情報が広域通信によりサーバ21に送信される。
このようにすることで、評価情報収集事業者などとコンテンツの提供者との間に十分な信頼関係がない場合でも、評価情報収集システム10において、リンク認証を行って評価情報を収集する。
図11は、図10を参照して上述したリンク認証を行って評価情報を収集する処理の流れを説明するアローチャートである。
同図においては、携帯端末47の移動体通信網用無線通信部131が、3G131−3と記載されており、携帯端末46の移動体通信網用無線通信部131が、3G131−4と記載されている。また、携帯端末47の近距離無線通信部132が、BT132−3と記載されており、携帯端末46の近距離無線通信部132が、BT132−4と記載されている。さらに、携帯端末47の非接触通信部133が、NFC133−3と記載されており、携帯端末46の非接触通信部133が、NFC133−4と記載されている。
ステップS211において、携帯端末47のNFC133−3は、ハンドオーバメッセージを送信し、ステップS301において、携帯端末46のNFC133−4によりこれが受信される。
ステップS302において、NFC133−4は、ハンドオーバメッセージを送信し、ステップS212において、NFC133−3によりこれが受信される。
ここまでの処理により、携帯端末47と携帯端末46により対向機器情報の交換が行われることになる。なお、対向機器情報とは、ハンドオーバの相手の機器の識別番号、近距離無線通信アドレスなどの情報とされる。また、対向機器情報には、必要に応じてサーバ21の広域通信のアドレスが含まれるものとする。
ステップS213において、NFC133−3からBT132−3に対向機器情報が通知され、ステップS231でBT132−3によりこれが取得される。また、ステップS303において、NFC133−4からBT132−4に対向機器情報が通知され、ステップS321でBT132−4によりこれが取得される。ステップS322において、BT132−4は、ステップS321で取得した対向機器情報を3G131−4に通知し、ステップS341でこれが取得される。なお、実際には、CPU111を介して対向機器情報、その他の情報の通知が行われる。以下においても同様である。
ステップS342において、3G131−4は、対向機器情報を含む情報をサーバ21に送信することで、ハンドオーバの通知を行い、ステップS271でサーバ21によりこれが受信される。なお、ステップS321、ステップS341、ステップS342の処理は、省略されるようにしてもよい。
ステップS214において、NFC133−3は、3G131−3に対向機器情報を通知し、ステップS251で、3G131−3によりこれが取得される。
ステップS252において、3G131−3は、対向機器情報を含む情報をサーバ21に送信することで、ハンドオーバの通知を行い、ステップS272でサーバ21によりこれが受信される。なお、サーバ21にハンドオーバの通知を行う際には、ハンドオーバの相手の対向機器情報だけでなく、自分(いまの場合、携帯端末47)の対向機器情報もともに送信されるものとする。
ステップS232において、BT132−3からBT132−4へBT接続要求が送信され、ステップS323でこれが受信される。
ステップS273において、サーバ21は、乱数を発生させ、ステップS274でこれを暗号化する。ステップS275において、サーバ21は、ステップS274の処理により得られた暗号化乱数を確認要求として送信し、ステップS253で3G131−3によりこれが受信される。
ステップS254において、3G131−3は、ステップS253で受信した確認要求をBT132−3に通知し、ステップS233でこれが取得される。
ステップS234において、BT132−3は、ステップS233で取得した確認要求を送信し、ステップS324でBT132−4によりこれが受信される。
ステップS325において、BT132−4は、ステップS324で受信した確認要求の暗号化乱数を復号して乱数を得る。なお、暗号化乱数の復号は、実際には、CPU111により行われる。
ステップS326において、BT132−4は、ステップS325の処理で得た乱数を確認応答として送信し、ステップS235でBT132−3によりこれが受信される。
ステップS236において、BT132−3は、ステップS35で受信した確認応答を3G131−3に通知し、ステップS255でこれが取得される。
ステップS256において、3G131−3は、ステップS255で取得した確認応答を送信し、ステップS276でサーバ21によりこれが受信される。
また、ステップS277において、サーバ21は、別の乱数を発生させ、ステップS278でこれを暗号化する。ステップS279において、サーバ21は、ステップS278の処理により得られた暗号化乱数を確認要求として送信し、ステップS343で3G131−4によりこれが受信される。
ステップS344において、3G131−4は、ステップS343で受信した確認要求をBT132−4に通知し、ステップS328でこれが取得される。
ステップS329において、BT132−4は、ステップS328で取得した確認要求を送信し、ステップS237でBT132−3によりこれが受信される。
ステップS238において、BT132−3は、ステップS237で受信した確認要求の暗号化乱数を復号して乱数を得る。
ステップS239において、BT132−3は、ステップS238の処理で得た乱数を確認応答として送信し、ステップS330でBT132−4によりこれが受信される。
ステップS331において、BT132−4は、ステップS330で受信した確認応答を3G131−3に通知し、ステップS345でこれが取得される。
ステップS346において、3G131−4は、ステップS345で取得した確認応答を送信し、ステップS280でサーバ21によりこれが受信される。
その後、コンテンツデータの送受信、評価情報としての操作情報の送受信などが行われることになるが、これらの処理は、図7を参照して説明した場合と同様なので詳細な説明は省略する。
なお、図中点線で囲まれた部分の処理が評価者の同一性と提供者の同一性の確認のための処理として定期的に実行されることになる。
このようにして、リンク認証を行って評価情報を収集する処理が実行される。
ところで、図10を参照して上述した例においては、携帯端末46が固有鍵を保持している場合の例について説明したが、携帯端末46が固有鍵を保持していない場合もある。そのような場合、例えば、図12に示されるようにして評価者の同一性と提供者の同一性を確認することができる。
図12は、評価情報収集システム10において、リンク認証を行って評価情報を収集する方式のさらに別の例を説明する図である。同図の例では、携帯端末47と携帯端末46との間でハンドオーバが行われ、非接触通信(NFC通信)の後、近距離無線通信(BT)によってコンテンツ(例えば、ゲーム)のデータが送信される場合の例を示している。
図12の例の場合、図10の場合と同様に、コンテンツの提供者である携帯端末47に「Trusted」と記されておらず、評価情報収集事業者などとコンテンツの提供者との間に十分な信頼関係がない。また、同図の例では、図10の場合と異なり、携帯端末47は固有鍵を保持しているが、携帯端末46が固有鍵を保持していないものとする。
図12において、携帯端末47と携帯端末46との間でのハンドオーバが携帯端末47からサーバ21に広域通信を用いて通知される。このとき、携帯端末47と携帯端末46の識別番号も、サーバ21に送信される。するとサーバ21は、乱数を発生させるが、携帯端末46が固有鍵を保持していないことを確認する。なお、携帯端末46が固有鍵を保持していないことは、端末機器データベース222を、携帯端末46の識別番号を用いて検索することにより確認できる。
サーバ21は、乱数を一時キーとして携帯端末46の広域通信アドレス宛に送信する。なお、携帯端末46の広域通信アドレスは、端末機器データベース222を、携帯端末46の識別番号を用いて検索することにより、取得することができる。
サーバ21は、携帯端末47の広域アドレスに確認要求を送信し、近距離無線通信によって携帯端末47から携帯端末46に確認要求が伝送される。なお、携帯端末47の広域通信アドレスは、端末機器データベース222を、携帯端末47の識別番号を用いて検索することにより、取得することができる。
携帯端末46は、確認要求に対する応答として一時キーを近距離無線通信によって携帯端末47に送信し、携帯端末47は、広域通信によってその応答をサーバ21に伝送する。
サーバ21は、携帯端末47から送信された一時キーを、自分が発生した乱数と比較し、両者が一致する場合、ハンドオーバ時の評価者との近距離無線通信が行われていると確認する。すなわち、提供者側から送信される情報に基づいて評価者の同一性を確認することができる。
また、サーバ21は、別の乱数を発生させ、その乱数を携帯端末47の固有鍵を用いて暗号化する。なお、携帯端末47の固有鍵は、端末機器データベース222を、携帯端末47の識別番号を用いて検索することにより、取得することができる。
サーバ21は、暗号化した乱数(暗号化乱数と称する)を携帯端末46の広域通信アドレス宛に送信する。なお、携帯端末46の広域通信アドレスは、端末機器データベース222を、携帯端末46の識別番号を用いて検索することにより、取得することができる。
携帯端末46は、サーバ21から送信された暗号化乱数を近距離無線通信によって携帯端末47に送信する。
携帯端末47は、暗号化乱数を自分の固有鍵で復号し、乱数を得る。そして、携帯端末47は、その乱数を近距離無線通信によって携帯端末46に送信する。
携帯端末46は、携帯端末47から送信された乱数を広域通信によってサーバ21に送信する。
サーバ21は、携帯端末46から送信された乱数を、自分が発生した乱数と比較し、両者が一致する場合、ハンドオーバ時の提供者との近距離無線通信が行われていると確認する。すなわち、評価者側から送信される情報に基づいて提供者の同一性を確認することができる。
その後、携帯端末47から近距離無線通信によってコンテンツのデータが送信されて、携帯端末46によりゲームの画面などが表示される。携帯端末46は、この際、評価情報を携帯端末47に送信する。
このように、携帯端末47と携帯端末46との間で、近距離無線通信によってコンテンツのデータの送信、評価情報の送信が行われている間、サーバ21は、例えば、一定の周期で継続して(定期的に)上述したように評価者の同一性と提供者の同一性を確認する。
そして、携帯端末47に蓄積された評価情報が広域通信によりサーバ21に送信される。
このようにすることで、評価情報収集事業者などとコンテンツの提供者との間に十分な信頼関係がない場合、評価者側に固有鍵がないときでも、評価情報収集システム10において、リンク認証を行って評価情報を収集する。
図12を参照して上述した処理は、既に図10を参照して上述した処理と、図8を参照して上述した処理を組み合わせたものであるから、アローチャートを用いた詳細な説明は省略する。
さらに、携帯端末46と携帯端末47の双方が固有鍵を保持していない場合もある。そのような場合、例えば、図13に示されるようにして評価者の同一性と提供者の同一性を確認することができる。
図13は、評価情報収集システム10において、リンク認証を行って評価情報を収集する方式のさらに別の例を説明する図である。同図の例では、携帯端末47と携帯端末46との間でハンドオーバが行われ、非接触通信(NFC通信)の後、近距離無線通信(BT)によってコンテンツ(例えば、ゲーム)のデータが送信される場合の例を示している。
図13の例の場合、図10の場合と同様に、コンテンツの提供者である携帯端末47に「Trusted」と記されておらず、評価情報収集事業者などとコンテンツの提供者との間に十分な信頼関係がない。また、同図の例では、図12の場合と異なり、携帯端末47と携帯端末46の双方が固有鍵を保持していないものとする。
図13において、携帯端末47と携帯端末46との間でのハンドオーバが携帯端末47からサーバ21に広域通信を用いて通知される。このとき、携帯端末47と携帯端末46の識別番号も、サーバ21に送信される。するとサーバ21は、乱数を発生させるが、携帯端末46が固有鍵を保持していないことを確認する。なお、携帯端末46が固有鍵を保持していないことは、端末機器データベース222を、携帯端末46の識別番号を用いて検索することにより確認できる。
サーバ21は、乱数を一時キーとして携帯端末46の広域通信アドレス宛に送信する。なお、携帯端末46の広域通信アドレスは、端末機器データベース222を、携帯端末46の識別番号を用いて検索することにより、取得することができる。
サーバ21は、携帯端末47の広域アドレスに確認要求を送信し、近距離無線通信によって携帯端末47から携帯端末46に確認要求が伝送される。なお、携帯端末47の広域通信アドレスは、端末機器データベース222を、携帯端末47の識別番号を用いて検索することにより、取得することができる。
携帯端末46は、確認要求に対する応答として一時キーを近距離無線通信によって携帯端末47に送信し、携帯端末47は、広域通信によってその応答をサーバ21に伝送する。
サーバ21は、携帯端末47から送信された一時キーを、自分が発生した乱数と比較し、両者が一致する場合、ハンドオーバ時の評価者との近距離無線通信が行われていると確認する。すなわち、提供者側から送信される情報に基づいて評価者の同一性を確認することができる。
また、サーバ21は、別の乱数を発生させるが、携帯端末47が固有鍵を保持していないことを確認する。なお、携帯端末47が固有鍵を保持していないことは、端末機器データベース222を、携帯端末47の識別番号を用いて検索することにより確認できる。
サーバ21は、乱数を一時キーとして携帯端末47の広域通信アドレス宛に送信する。
サーバ21は、携帯端末46の広域アドレスに確認要求を送信し、近距離無線通信によって携帯端末46から携帯端末47に確認要求が伝送される。
携帯端末47は、確認要求に対する応答として一時キーを近距離無線通信によって携帯端末46に送信し、携帯端末46は、広域通信によってその応答をサーバ21に伝送する。
サーバ21は、携帯端末46から送信された一時キーを、自分が発生した乱数と比較し、両者が一致する場合、ハンドオーバ時の提供者との近距離無線通信が行われていると確認する。すなわち、評価者側から送信される情報に基づいて提供者の同一性を確認することができる。
その後、携帯端末47から近距離無線通信によってコンテンツのデータが送信されて、携帯端末46によりゲームの画面などが表示される。携帯端末46は、この際、評価情報を携帯端末47に送信する。
このように、携帯端末47と携帯端末46との間で、近距離無線通信によってコンテンツのデータの送信、評価情報の送信が行われている間、サーバ21は、例えば、一定の周期で継続して(定期的に)上述したように評価者の同一性と提供者の同一性を確認する。
そして、携帯端末47に蓄積された評価情報が広域通信によりサーバ21に送信される。
このようにすることで、評価情報収集事業者などとコンテンツの提供者との間に十分な信頼関係がない場合、評価者側および提供者側ともに固有鍵がないときでも、評価情報収集システム10において、リンク認証を行って評価情報を収集する。
なお、図13を参照して上述した処理も、既に説明した処理を組み合わせたものであるから、アローチャートを用いた詳細な説明は省略する。
このように、本発明によれば、リンク認証を行って、評価情報を収集することができ、この際、例えば、コンテンツ提供者と評価者が動的に変わるP2Pネットワーク上での評価情報の取得にも対応できる。
また、本発明によれば、評価対象の商品やコンテンツなどが提示されてから評価情報が収集されるまで時間を従来と比較して短縮することができ、タイムリーな評価情報を提供することも可能となる。
さらに、例えば、評価者が実在することを確認できるようにカメラ等の専用の装置を設置する必要もなく、簡単な構成で信頼性の高い評価情報収集システムを実現することができる。
図6乃至図13を参照して上述した例についてまとめると、評価情報収集システム10において、リンク認証を行って評価情報を収集する場合、次の2点を考慮する必要があると考えられる。第1点目は、評価情報収集事業者などとコンテンツの提供者との間に十分な信頼関係があるか否かであり、第2点目は、評価者側および提供者側の固有鍵の有無である。
すなわち、評価情報収集事業者などとコンテンツの提供者との間に十分な信頼関係がある場合、提供者側から送信される情報に基づいて評価者の同一性を定期的に確認することによってリンク認証を実現することができる。一方、評価情報収集事業者などとコンテンツの提供者との間に十分な信頼関係がない場合、提供者側から送信される情報に基づいて評価者の同一性を定期的に確認するとともに、評価者側から送信される情報に基づいて提供者の同一性を確認することによってリンク認証を実現することができる。
また、評価者の携帯端末が固有鍵を保持している場合、固有鍵を用いて暗号化した乱数を提供者側の携帯端末などに送信すれば、提供者側から送信される情報に基づいて評価者の同一性を確認することが可能となる。一方、評価者の携帯端末が固有鍵を保持していない場合、一時キーを評価者側の携帯端末などに送信しておき、その後、提供者の携帯端末などに確認要求を送信すれば、提供者側から送信される情報に基づいて評価者の同一性を確認することが可能となる。
同様に、提供者の携帯端末などが固有鍵を保持している場合、固有鍵を用いて暗号化した乱数を評価者側の携帯端末に送信すれば、評価者側から送信される情報に基づいて提供者の同一性を確認することが可能となる。一方、提供者の携帯端末などが固有鍵を保持していない場合、一時キーを提供者側の携帯端末などに送信しておき、その後、評価者の携帯端末などに確認要求を送信すれば、評価者側から送信される情報に基づいて提供者の同一性を確認することが可能となる。
このように、合計5通りの方式で、リンク認証を行った評価情報の収集が実現されることになる。
本発明においては、評価情報収集事業者などとコンテンツの提供者との間の信頼関係の有無、評価者側および提供者側の固有鍵の有無にかかわらず、リンク認証を行った評価情報の収集ができるようにする。そのために、ハンドオーバメッセージに次のような情報を含めるようにする。
図14は、ハンドオーバメッセージのフォーマットを説明する図である。ハンドオーバメッセージは、例えば、携帯端末や情報収集端末が非接触通信(NFC通信)を行うときに送受信される情報とされる。ハンドオーバメッセージのフォーマットについては、NFC Forumによる標準化が行われており、図示されるフォーマットがNFC Forumの規格によって規定されている。
同図に示されるように、ハンドオーバメッセージは、複数(この例では4)のレコードに分割されて構成されている。
「Record1」は、ハンドオーバのリクエストおよびセレクトなどの情報が格納されるレコードとされる。「Record2」は、セカンドキャリア候補を格納するレコードであり、ヘッダ部分のRecordTypeに「ac(Alternative Carrier)」が格納され、ペイロード部には各セカンドキャリアのポインタ(Record3の識別子)が格納される。
「Record3」は、近距離無線通信手段に関する情報が格納されるレコードとされる。同図に示されるように、「Record3」には、ヘッダとペイロードからなるパケットが格納されることがBluetoothSIGの規格によって規定されている。なお、「Record3」のパケットとして図示されているパケットは、近距離無線通信手段がBluetoothの通信を行う場合のものである。
「Record4」は、携帯端末などの製造事業者によって定義された情報が格納されるレコードとされる。本発明では、「Record4」に含まれる情報として図示されるようなパケットの情報を定義する。
同図に示されるように、「Record4」には、ヘッダとペイロードからなるパケットが格納される。
ヘッダには、「Record Type」の情報が記述され、いまの場合、レコード4が評価情報収集のために用いられる情報が格納されるレコードであることを表す情報が記述される。
ペイロードは、「サーバ承認区分」、「リンク認証方式」、および「広域通信アドレス」によって構成されている。
「サーバ承認区分」には、当該端末機器が、サーバ21により承認された端末機器であるか否かを表す情報(例えば、Yes/No)が記述される。当該端末機器が、サーバ21により承認された端末機器である場合、評価情報収集事業者などとの間に十分な信頼関係があることを意味する。
「リンク認証方式」は、上述した評価者の同一性の確認または提供者の同一性の確認を行うための方式を表す情報が記述される。具体的には、例えば、固有鍵を用いて乱数を暗号化する方式であるか、予めサーバ21から一時キーを送信する方式であるかを表す情報が記述される。
「広域通信アドレス」には、必要に応じて当該機器の広域通信のアドレス、サーバ21の広域通信のアドレスが記述される。
本発明の評価情報収集システム10では、ハンドオーバ時に、図14に示されるようなハンドオーバメッセージが送受信される。図14に示される情報は、対向機器情報として、ハンドオーバの通知とともに、サーバ21にも送信される。
サーバ21は、情報収集端末または携帯端末からハンドオーバの通知を受けたとき、図14の「Record4」に含まれる情報を解析して、リンク認証を行うようになされている。上述したように、本発明の評価情報収集システム10では、合計5通りの方式で、リンク認証を行った評価情報の収集が実現される。
第1の方式は、図6を参照して上述したように、評価情報収集事業者などと提供者との間に十分な信頼関係があり、かつ評価者の携帯端末が固有鍵を保持している場合である。これをケース1と称することにする。
第2の方式は、図8を参照して上述したように、評価情報収集事業者などと提供者との間に十分な信頼関係があり、かつ評価者の携帯端末が固有鍵を保持していない場合である。これをケース2と称することにする。
第3の方式は、図10を参照して上述したように、評価情報収集事業者などと提供者との間に十分な信頼関係がなく、かつ評価者の携帯端末および提供者の携帯端末がともに固有鍵を保持している場合である。これをケース3と称することにする。
第4の方式は、図12を参照して上述したように、評価情報収集事業者などと提供者との間に十分な信頼関係がなく、かつ評価者の携帯端末は固有鍵を保持しておらず、提供者の携帯端末は固有鍵を保持している場合である。これをケース4と称することにする。
第5の方式は、図13を参照して上述したように、評価情報収集事業者などと提供者との間に十分な信頼関係がなく、かつ評価者の携帯端末および提供者の携帯端末がともに固有鍵を保持していない場合である。これをケース5と称することにする。
サーバ21は、情報収集端末または携帯端末からハンドオーバの通知を受けたとき、図14の「Record4」に含まれる情報を解析して、提供者側の属性と、評価者側の属性を特定し、図15に示されるようにリンク認証の方式を特定する。
すなわち、図15に示されるように、提供者側および評価者側のハンドオーバメッセージの「サーバ承認区分」に基づいて評価情報収集事業者などとの間に十分な信頼関係があるか否かが判定される。この例では、評価情報収集事業者などとの間に十分な信頼関係があるもの(「サーバ承認区分」がYes)は「Trusted」と記載されており、信頼関係がないもの(「サーバ承認区分」がNo)は「NoTrusted」と記載されている。
また、提供者側および評価者側のハンドオーバメッセージの「サーバ承認区分」に基づいて評価者の同一性の確認または提供者の同一性の確認を行うための方式が特定される。この例では、固有鍵を用いて乱数を暗号化する方式であるものは「固有鍵」と記載されており、予めサーバ21から一時キーを送信する方式であるものは「一時キー」と記載されている。
このようにしてサーバ21は、リンク認証の方式を特定し、評価情報の収集の際のリンク認証を行うのである。
次に、図16のフローチャートを参照してサーバ21により実行される評価情報収集処理の例について説明する。
ステップS701においてサーバ21のCPU201は、情報収集端末または携帯端末からのハンドオーバの通知を受けたか否かを判定し、ハンドオーバの通知を受けたと判定されるまで待機する。
ステップS701において、ハンドオーバの通知を受けたと判定された場合、処理は、ステップS702に進む。
ステップS702において、CPU201は、ハンドオーバの通知とともに送信された提供者側の機器情報を取得して解析し、提供者側の属性を特定する。このとき、例えば、図14の「Record4」に含まれる情報が解析されて提供者側(例えば、情報収集端末31、携帯端末47など)の属性が特定される。すなわち、評価情報収集事業者などとの間に十分な信頼関係があるか否か、固有鍵を用いて乱数を暗号化する方式であるか、予めサーバ21から一時キーを送信する方式であるかが特定される。
ステップS703において、CPU201は、ステップS702の処理と同様にして、ハンドオーバの通知とともに送信された評価者側の機器情報を取得して解析し、評価者側の属性を特定する。
ステップS704において、CPU201は、ステップS702とステップS703で特定された属性に基づいて、リンク認証の方式を特定する。すなわち、図15を参照して上述したように、ケース1乃至ケース5の方式が特定される。
ステップS705において、CPU201は、ステップS704で特定されたリンク認証の方式に基づいて方式別リンク認証処理を実行する。これにより、ケース1乃至ケース5のそれぞれに対応したリンク認証が行われることになる。
図17は、ステップS704において、リンク認証の方式がケース1であると特定された場合、ステップS705の処理として実行されるケース1処理の例を説明するフローチャートである。
ステップS721において、CPU201は、乱数を生成(発生)する。
ステップS722において、CPU201は、端末機器データベース222を、評価者側(例えば、携帯端末41)の識別番号を用いて検索することにより、評価者側の固有鍵を取得する。
ステップS723において、CPU201は、ステップS722で取得した固有鍵を用いて、ステップS721で生成した乱数を暗号化する。
ステップS724において、CPU201は、端末機器データベース222を、提供者側(例えば、情報収集端末31)の識別番号を用いて検索することにより、提供者側の広域通信アドレスを取得する。
ステップS725において、CPU201は、ステップS723で生成した暗号化乱数を確認要求として、ステップS724で取得した広域アドレスに送信する。
ステップS726において、CPU201は、ステップS725で送信した確認要求に対する応答であって、適正な確認応答を受信したか否かを判定する。このとき、確認応答に、ステップS721で生成した乱数が含まれているか否かが判定され、上記の乱数が含まれている場合、適正な確認応答を受信したと判定される。
ステップS726において、適正な確認応答を受信したと判定された場合、処理は、ステップS727に進む。一方、適正な確認応答を受信しなかったと判定された場合、処理は、ステップS730に進み、エラー処理が実行される。
ステップS727において、CPU201は、適正な確認応答を受信した時刻を、リンク認証の認証時刻として記録する。
ステップS728において、CPU201は、提供者側から評価情報が送信されたか否かを判定し、まだ送信されていないと判定された場合、ステップS729に進む。
ステップS729において、CPU201は、ステップS727で認証時刻が記録されてから、所定の時間が経過したか否かを判定し、所定の時間が経過したと判定されるまで待機する。ステップS729において、所定の時間が経過したと判定された場合、処理は、ステップS721に戻る。このようにすることで、一定の周期で継続して(定期的に)評価者の同一性が確認される。
一方、ステップS728において、提供者側から評価情報が送信されたと判定された場合、ケース1処理は終了する。
このようにして、ケース1の場合の方式別リンク認証処理が実行される。
図18は、ステップS704において、リンク認証の方式がケース2であると特定された場合、ステップS705の処理として実行されるケース2処理の例を説明するフローチャートである。
ステップS751において、CPU201は、一時キーを生成する。
ステップS752において、CPU201は、端末機器データベース222を、評価者側(例えば、携帯端末41)の識別番号を用いて検索することにより、評価者側の広域通信アドレスを取得する。
ステップS753において、CPU201は、ステップS751で生成した一時キーを、ステップS752で取得した広域アドレスに送信する。
ステップS754において、CPU201は、端末機器データベース222を、提供者側(例えば、情報収集端末31)の識別番号を用いて検索することにより、提供者側の広域通信アドレスを取得する。
ステップS755において、CPU201は、確認要求をステップS754で取得した広域アドレスに送信する。
ステップS756において、CPU201は、ステップS755で送信した確認要求に対する応答であって、適正な確認応答を受信したか否かを判定する。このとき、確認応答に、ステップS751で生成した一時キーが含まれているか否かが判定され、上記の一時キーが含まれている場合、適正な確認応答を受信したと判定される。
ステップS756において、適正な確認応答を受信したと判定された場合、処理は、ステップS757に進む。一方、適正な確認応答を受信しなかったと判定された場合、処理は、ステップS760に進み、エラー処理が実行される。
ステップS757において、CPU201は、適正な確認応答を受信した時刻を、リンク認証の認証時刻として記録する。
ステップS758において、CPU201は、提供者側から評価情報が送信されたか否かを判定し、まだ送信されていないと判定された場合、ステップS759に進む。
ステップS759において、CPU201は、ステップS757で認証時刻が記録されてから、所定の時間が経過したか否かを判定し、所定の時間が経過したと判定されるまで待機する。ステップS759において、所定の時間が経過したと判定された場合、処理は、ステップS751に戻る。このようにすることで、一定の周期で継続して(定期的に)評価者の同一性が確認される。
一方、ステップS758において、提供者側から評価情報が送信されたと判定された場合、ケース2処理は終了する。
このようにして、ケース2の場合の方式別リンク認証処理が実行される。
図19と図20は、ステップS704において、リンク認証の方式がケース3であると特定された場合、ステップS705の処理として実行されるケース3処理の例を説明するフローチャートである。
ステップS781乃至ステップS788の処理は、図17のステップS721乃至ステップS727およびステップS730と同様の処理なので、詳細な説明は省略する。
ステップS789において、CPU201は、乱数を生成(発生)する。
ステップS790において、CPU201は、端末機器データベース222を、提供者側(例えば、携帯端末47)の識別番号を用いて検索することにより、提供者側の固有鍵を取得する。
ステップS791において、CPU201は、ステップS790で取得した固有鍵を用いて、ステップS789で生成した乱数を暗号化する。
ステップS792において、CPU201は、端末機器データベース222を、評価者側(例えば、携帯端末46)の識別番号を用いて検索することにより、評価者側の広域通信アドレスを取得する。
ステップS793において、CPU201は、ステップS791で生成した暗号化乱数を確認要求として、ステップS792で取得した広域アドレスに送信する。
ステップS794において、CPU201は、ステップS793で送信した確認要求に対する応答であって、適正な確認応答を受信したか否かを判定する。このとき、確認応答に、ステップS789で生成した乱数が含まれているか否かが判定され、上記の乱数が含まれている場合、適正な確認応答を受信したと判定される。
ステップS794において、適正な確認応答を受信したと判定された場合、処理は、ステップS795に進む。一方、適正な確認応答を受信しなかったと判定された場合、処理は、ステップS798に進み、エラー処理が実行される。
ステップS795において、CPU201は、適正な確認応答を受信した時刻を、リンク認証の認証時刻として記録する。
ステップS796において、CPU201は、提供者側から評価情報が送信されたか否かを判定し、まだ送信されていないと判定された場合、ステップS797に進む。
ステップS797において、CPU201は、ステップS795で認証時刻が記録されてから、所定の時間が経過したか否かを判定し、所定の時間が経過したと判定されるまで待機する。ステップS795において、所定の時間が経過したと判定された場合、処理は、ステップS781に戻る。このようにすることで、定期的に評価者の同一性と提供者の同一性が確認される。
一方、ステップS796において、提供者側から評価情報が送信されたと判定された場合、ケース3処理は終了する。
このようにして、ケース3の場合の方式別リンク認証処理が実行される。
図21と図22は、ステップS704において、リンク認証の方式がケース4であると特定された場合、ステップS705の処理として実行されるケース4処理の例を説明するフローチャートである。
ステップS811乃至ステップS818の処理は、図18のステップS751乃至ステップS757およびステップS760の処理と同様の処理なので詳細な説明は省略する。
ステップS819乃至ステップS828の処理は、図20のステップS789乃至ステップS798の処理と同様の処理なので詳細な説明は省略する。
このようにして、ケース4の場合の方式別リンク認証処理が実行される。
図23と図24は、ステップS704において、リンク認証の方式がケース5であると特定された場合、ステップS705の処理として実行されるケース5処理の例を説明するフローチャートである。
ステップS831乃至ステップS838の処理は、図21のステップS811乃至ステップS818の処理と同様の処理なので詳細な説明は省略する。
ステップS839において、CPU201は、一時キーを生成する。
ステップS840において、CPU201は、端末機器データベース222を、提供者側(例えば、携帯端末47)の識別番号を用いて検索することにより、提供者側の広域通信アドレスを取得する。
ステップS841において、CPU201は、ステップS839で生成した一時キーを、ステップS840で取得した広域アドレスに送信する。
ステップS842において、CPU201は、端末機器データベース222を、評価者側(例えば、携帯端末46)の識別番号を用いて検索することにより、評価者側の広域通信アドレスを取得する。
ステップS843において、CPU201は、確認要求をステップS842で取得した広域アドレスに送信する。
ステップS844において、CPU201は、ステップS843で送信した確認要求に対する応答であって、適正な確認応答を受信したか否かを判定する。このとき、確認応答に、ステップS839で生成した一時キーが含まれているか否かが判定され、上記の一時キーが含まれている場合、適正な確認応答を受信したと判定される。
ステップS844において、適正な確認応答を受信したと判定された場合、処理は、ステップS845に進む。一方、適正な確認応答を受信しなかったと判定された場合、処理は、ステップS848に進み、エラー処理が実行される。
ステップS845において、CPU201は、適正な確認応答を受信した時刻を、リンク認証の認証時刻として記録する。
ステップS846において、CPU201は、提供者側から評価情報が送信されたか否かを判定し、まだ送信されていないと判定された場合、ステップS847に進む。
ステップS847において、CPU201は、ステップS845で認証時刻が記録されてから、所定の時間が経過したか否かを判定し、所定の時間が経過したと判定されるまで待機する。ステップS847において、所定の時間が経過したと判定された場合、処理は、ステップS831に戻る。このようにすることで、定期的に評価者の同一性と提供者の同一性が確認される。
一方、ステップS846において、提供者側から評価情報が送信されたと判定された場合、ケース5処理は終了する。
このようにして、ケース5の場合の方式別リンク認証処理が実行される。
このような方式別リンク認証処理を含む評価情報収集処理が実行される。
次に、図25のフローチャートを参照して、提供者側の端末機器(例えば、情報収集端末31または携帯端末47など)の処理の例について説明する。なお、この処理は、固有鍵を保持している提供者側の端末機器において実行される処理であり、この例では、提供者側端末機器は、楽曲などのコンテンツを提供するものとする。
ステップS901において、情報収集端末または携帯端末のCPU111は、ハンドオーバがあったか否かを判定し、ハンドオーバがあったと判定されるまで待機する。
ステップS902において、CPU111は、広域通信によりサーバ21にハンドオーバを通知する。このとき、ハンドオーバの通知とともに対向機器情報が送信される。
ステップS903において、CPU111は、広域通信による確認要求を受信したか否かを判定する。ステップS903において、確認要求を受信したと判定された場合、処理は、ステップS905に進み、確認要求を受信していないと判定された場合、処理は、ステップS904に進む。
ここで、図26のフローチャートを参照して、図25のステップS904のコンテンツ提供処理の例について説明する。
ステップS921において、CPU111は、近距離無線通信により評価者側にコンテンツのデータを送信する。
ステップS922において、CPU111は、近距離無線通信により評価者側から評価情報を受信する。
ステップS923において、CPU111は、ステップS921の処理によって所定のデータ量を送信したか否かを判定し、まだ、所定のデータ量を送信していないと判定された場合、処理は、ステップS921に戻る。一方、所定のデータ量を送信したと判定された場合、処理は、図26のステップS906に進む。
ここで、図27のフローチャートを参照して、図25のステップS905のリンク認証確認処理の例について説明する。
ステップS941において、CPU111は、ステップS903において受信したと判定された確認要求を、近距離無線通信により評価者側に送信する。
ステップS942において、CPU111は、ステップS941で送信した確認要求に対する確認応答を、近距離無線通信により受信したか否かを判定し、確認応答を受信したと判定されるまで待機する。ステップS942において、確認応答を受信したと判定された場合、処理は、ステップS943に進む。
ステップS943において、CPU111は、ステップS942で受信したと判定された確認応答を、広域通信によりサーバ21に送信する。
ステップS944において、CPU111は、近距離無線通信により確認要求を受信したか否かを判定し、確認要求を受信したと判定されるまで待機する。ステップS944において、確認要求を受信したと判定された場合、処理は、ステップS945に進む。
ステップS945において、CPU111は、ステップS944で受信したと判定された確認要求に含まれる暗号化乱数を、自分の固有鍵を用いて復号する。
ステップS946において、CPU111は、ステップS945で復号して得られた乱数を確認応答として近距離無線通信により評価者側に送信する。
このようにして、リンク確認処理が実行される。
図25に戻って、ステップS904またはステップS905の処理の後、処理は、ステップS906に進み、CPU111は、コンテンツの提供が終了したか否かを判定する。例えば、評価者によりコンテンツの再生の停止が指令された場合、ステップS906では、コンテンツの提供が終了したと判定される。ステップS906において、まだ終了していないと判定された場合、処理は、ステップS903に戻る。
ステップS906において、コンテンツの提供が終了したと判定された場合、処理は、ステップS907に進む。
ステップS907において、CPU111は、ステップS904の処理において受信した評価情報を、広域通信によりサーバ21に送信する。
このようにして、提供者側端末機器の処理が実行される。
次に、図28のフローチャートを参照して、提供者側の端末機器の処理の別の例について説明する。なお、この処理は、固有鍵を保持していない提供者側の端末機器において実行される処理であり、この例では、提供者側端末機器は、楽曲などのコンテンツを提供するものとする。
ステップS961において、情報収集端末または携帯端末のCPU111は、ハンドオーバがあったか否かを判定し、ハンドオーバがあったと判定されるまで待機する。
ステップS962において、CPU111は、広域通信によりサーバ21にハンドオーバを通知する。このとき、ハンドオーバの通知とともに対向機器情報が送信される。
ステップS963において、CPU111は、広域通信による確認要求または一時キーを受信したか否かを判定する。ステップS963において、確認要求または一時キーを受信したと判定された場合、処理は、ステップS965に進み、確認要求を受信していないと判定された場合、処理は、ステップS964に進む。
ここで、図29のフローチャートを参照して、図28のステップS965のリンク認証確認処理の例について説明する。
ステップS981において、CPU111は、ステップS963で受信したと判定されたのは、確認要求であるか否かを判定する。確認要求であると判定された場合、処理は、ステップS982に進む。
ステップS982において、CPU111は、ステップS963において受信したと判定された確認要求を、近距離無線通信により評価者側に送信する。
ステップS983において、CPU111は、ステップS982で送信した確認要求に対する確認応答を、近距離無線通信により受信したか否かを判定し、確認応答を受信したと判定されるまで待機する。ステップS983において、確認応答を受信したと判定された場合、処理は、ステップS984に進む。
ステップS984において、CPU111は、ステップS983で受信したと判定された確認応答を、広域通信によりサーバ21に送信する。
一方、ステップS981において、ステップS963で受信したと判定されたのは、確認要求ではないと判定された場合、処理は、ステップS988に進む。なお、この場合、一時キーが受信されたことになる。
ステップS988において、CPU111は、ステップS963で受信したと判定された一時キーを記憶する。
ステップS984またはステップS988の処理の後、処理は、ステップS985に進む。
ステップS985において、CPU111は、近距離無線通信により確認要求を受信したか否かを判定し、確認要求を受信したと判定されるまで待機する。ステップS985において、確認要求を受信したと判定された場合、処理は、ステップS986に進む。
ステップS986において、CPU111は、ステップS988で記憶した一時キーを読み出す。
ステップS987において、CPU111は、ステップS986で読み出した一時キーを確認応答として近距離無線通信により評価者側に送信する。
このようにして、リンク認証確認処理が実行される。
なお、図28のステップS964のコンテンツ提供処理は、図26を参照して上述した処理と同様の処理なので詳細な説明は省略する。また、図28のステップS966とステップS967の処理は、それぞれ図25のステップS906とステップS907の処理と同様の処理なので詳細な説明は省略する。
このようにして、提供者側端末機器の処理が実行される。
次に、図30のフローチャートを参照して、評価者側の端末機器(例えば、携帯端末41または携帯端末46など)の処理の例について説明する。なお、この処理は、固有鍵を保持している評価者側の端末機器において実行される処理であり、この例では、提供者側端末機器により、楽曲などのコンテンツの提供を受けて、そのコンテンツを評価するものとする。
ステップS1001において、携帯端末のCPU111は、ハンドオーバがあったか否かを判定し、ハンドオーバがあったと判定されるまで待機する。
ステップS1002において、CPU111は、広域通信によりサーバ21にハンドオーバを通知する。このとき、ハンドオーバの通知とともに対向機器情報が送信される。なお、ステップS1002の処理は、省略されるようにしてもよい。
ステップS1003において、CPU111は、広域通信による確認要求を受信したか否かを判定する。ステップS1003において、確認要求を受信したと判定された場合、処理は、ステップS1004に進む。
ここで、図31のフローチャートを参照して、図30のステップS1004の第1リンク認証処理の例について説明する。
ステップS1021において、CPU111は、ステップS1003において受信したと判定された確認要求を、近距離無線通信により提供者側に送信する。
ステップS1022において、CPU111は、ステップS1021で送信した確認要求に対する確認応答を、近距離無線通信により受信したか否かを判定し、確認応答を受信したと判定されるまで待機する。ステップS1022において、確認応答を受信したと判定された場合、処理は、ステップS1023に進む。
ステップS1023において、CPU111は、ステップS1022で受信したと判定された確認応答を、広域通信によりサーバ21に送信する。
このようにして、第1リンク認証処理が実行される。
図30に戻って、ステップS1004の処理の後、または、ステップS1003において、確認要求を受信していないと判定された場合、処理は、ステップS1005に進む。
ステップS1005において、CPU111は、近距離無線通信による確認要求を受信したか否かを判定する。ステップS1005において、確認要求を受信したと判定された場合、処理は、ステップS1007に進む。
ここで、図32のフローチャートを参照して、図30のステップS1007の第2リンク認証処理の例について説明する。
ステップS1041において、CPU111は、ステップS1005で受信したと判定された確認要求に含まれる暗号化乱数を、自分の固有鍵を用いて復号する。
ステップS1042において、CPU111は、ステップS1041で復号して得られた乱数を確認応答として近距離無線通信により提供者側に送信する。
このようにして、第2リンク確認処理が実行される。
図30に戻って、一方、ステップS1005において、確認要求を受信していないと判定された場合、処理は、ステップS1006に進む。
ここで、図33のフローチャートを参照して、図30のステップS1006のコンテンツ評価処理の例について説明する。
ステップS1061において、CPU111は、提供者側から近距離無線通信によりデータを受信する。
ステップS1062において、CPU111は、近距離無線通信により評価情報を提供者側に送信する。
ステップS1063において、CPU111は、ステップS1061の処理によって所定のデータ量を送信したか否かを判定し、まだ、所定のデータ量を送信していないと判定された場合、処理は、ステップS1061に戻る。一方、所定のデータ量を送信したと判定された場合、処理は、図30のステップS1008に進む。
このようにして、コンテンツ評価処理が実行される。
図30に戻って、ステップS1006またはステップS1007の処理の後、処理は、ステップS1008に進む。
ステップS1008において、CPU111は、提供者側から提供を受けているコンテンツの評価が終了したか否かを判定し、まだ終了していないと判定された場合、処理は、ステップS1003に戻る。
一方、ステップS1008において、コンテンツの評価が終了したと判定された場合、処理は終了する。
このようにして、評価者側端末機器の処理が実行される。
次に、図34のフローチャートを参照して、評価者側の端末機器の処理の別の例について説明する。なお、この処理は、固有鍵を保持していない評価者側の端末機器において実行される処理であり、この例では、提供者側端末機器により、楽曲などのコンテンツの提供を受けて、そのコンテンツを評価するものとする。
ステップS1081において、携帯端末のCPU111は、ハンドオーバがあったか否かを判定し、ハンドオーバがあったと判定されるまで待機する。
ステップS1082において、CPU111は、広域通信によりサーバ21にハンドオーバを通知する。このとき、ハンドオーバの通知とともに対向機器情報が送信される。なお、ステップS1082の処理は、省略されるようにしてもよい。
ステップS1083において、CPU111は、広域通信による確認要求を受信したか否かを判定する。ステップS1083において、確認要求を受信したと判定された場合、処理は、ステップS1084に進む。
ここで、図35のフローチャートを参照して、図34のステップS1084の第3リンク認証処理の例について説明する。
ステップS2001において、CPU111は、ステップS1083で受信したと判定されたのは、確認要求であるか否かを判定する。確認要求であると判定された場合、処理は、ステップS2002に進む。
ステップS2002において、CPU111は、ステップS1083において受信したと判定された確認要求を、近距離無線通信により提供者側に送信する。
ステップS2003において、CPU111は、ステップS2002で送信した確認要求に対する確認応答を、近距離無線通信により受信したか否かを判定し、確認応答を受信したと判定されるまで待機する。ステップS2003において、確認応答を受信したと判定された場合、処理は、ステップS2004に進む。
ステップS2004において、CPU111は、ステップS2003で受信したと判定された確認応答を、広域通信によりサーバ21に送信する。
一方、ステップ2001において、ステップS1083で受信したと判定されたのは、確認要求ではないと判定された場合、処理は、ステップS2005に進む。なお、この場合、一時キーが受信されたことになる。
ステップS2005において、CPU111は、ステップS1083で受信したと判定された一時キーを記憶する。
このようにして、第3リンク認証処理が実行される。
図34に戻って、ステップS1084の処理の後、または、ステップS1083において、広域通信による確認要求を受信していないと判定された場合、処理は、ステップS1085に進む。
ステップS1085において、CPU111は、近距離無線通信による確認要求を受信したか否かを判定する。ステップS1085において、確認要求を受信したと判定された場合、処理は、ステップS1087に進む。
ここで、図36のフローチャートを参照して、図34のステップS1087の第4リンク認証処理の例について説明する。
ステップS2021において、CPU111は、ステップS2005で記憶した一時キーを読み出す。
ステップS2022において、CPU111は、ステップS2021で読み出した一時キーを確認応答として近距離無線通信により評価者側に送信する。
このようにして、第4リンク認証確認処理が実行される。
図34に戻って、一方、ステップS1085において、確認要求を受信していないと判定された場合、処理は、ステップS1086に進む。ステップS1086のコンテンツ評価処理は、図33のフローチャートを参照して上述した処理と同様の処理なので詳細な説明は省略する。
ステップS1086またはステップS1087の処理の後、処理は、ステップS1088に進む。
ステップS1088において、CPU111は、提供者側から提供を受けているコンテンツの評価が終了したか否かを判定し、まだ終了していないと判定された場合、処理は、ステップS1083に戻る。
一方、ステップS1088において、コンテンツの評価が終了したと判定された場合、処理は終了する。
このようにして、評価者側端末機器の処理が実行される。
ところで、以上においては主に、いわゆる口コミ情報のように商品やサービスの利用の際に参考にすべき情報として、評価情報を収集する例について説明したが、これとは異なる観点で情報を収集するようにしてもよい。
図37は、本発明の別の実施の形態を説明する図である。同図の例は、各端末機器のコンテンツの提供に係る実績に基づいてコンテンツを配信するためのコンテンツ配信システム11の構成例を示している。
この例では、コンテンツ配信システム11がサーバ22、携帯端末51乃至携帯端末53、および、携帯端末55乃至携帯端末57により構成されている。この例では、携帯端末51と携帯端末55に対してコンテンツが送信(配信)されている。
そして、携帯端末51から携帯端末52と携帯端末53に対してコンテンツの提供が行われている。また、携帯端末55から携帯端末56と携帯端末57に対してコンテンツの提供が行われている。なお、携帯端末52、携帯端末53、携帯端末56、携帯端末57のそれぞれが、楽曲のコンテンツなどをストリーミング再生することにより、それらの携帯端末に対するコンテンツの提供が行われることになる。
サーバ22は、例えば、実績情報収集事業者のデータセンタに設置され、携帯端末51、または携帯端末55から送信される実績情報を取得し、取得した実績情報の保存、加工などの処理を行うようになされている。サーバ22は、例えば、取得した実績情報に基づいて、携帯端末51、または携帯端末55にコンテンツの配信を行うようになされている。
なお、サーバ22についても図4を参照して上述した構成が適用される。
ここでは、携帯電話機のハンドオーバを利用してコンテンツを次々に提供する方式を想定する。例えば、あるアーティストのプロモーションとしてリリース直後の新曲を、ファンクラブの会員の携帯電話機に配信する場合などを想定する。
リリース直後の新曲のコンテンツは、ファンクラブの会員である携帯端末51のユーザと携帯端末55のユーザに配信される。このとき、例えば、携帯端末51と携帯端末55は、それぞれコンテンツのデータをサーバ22からダウンロードし、記憶部123などに記憶する。
そして、携帯端末51のユーザは、友人の携帯端末52と携帯端末51との間でハンドオーバを行い、近距離無線通信を利用して携帯端末52によるコンテンツのストリーミング再生を行わせる。また、別の友人の携帯端末53と携帯端末51との間でハンドオーバを行い、近距離無線通信を利用して携帯端末53によるコンテンツのストリーミング再生を行わせる。
携帯端末55のユーザも同様にして、友人の携帯端末56と携帯端末57によるコンテンツのストリーミング再生を行わせる。
なお、携帯端末52または携帯端末53が、携帯端末51からコンテンツをダウンロードするようにしてもよいが、ここでは、コンテンツのストリーミング再生のみが行われるものとする。
また、ここでは、ファンクラブの会員であるユーザの携帯端末として携帯端末51と携帯端末55のみが記載されているが、実際にはもっと多くの会員がそれぞれ携帯端末を保有している。さらに、ここでは、各会員がそれぞれ2人の友人にコンテンツを提供する例について説明したが、会員毎にコンテンツを提供する相手の人数が異なる。
このように、コンテンツ配信システム11においては、ファンクラブの会員から次々とコンテンツが提供されていくようになされている。また、このようにしてコンテンツの提供を受けたユーザのうち幾人かは、実際にその楽曲のコンテンツを購入してダウンロードしたり、新たにファンクラブの会員になったりする。
また、コンテンツ配信システム11においては、携帯端末51と携帯端末55から実績情報が送信されるようになされている。実績情報は、例えば、携帯端末51と携帯端末55がそれぞれ誰にコンテンツを提供したかを表す情報とされる。
図38は、実績情報の例を示す図である。同図は、例えば、携帯端末51からサーバ22へ送信される実績情報とされ、この例では、「コンテンツ提供先」に係る情報と「詳細」に係る情報により実績情報が構成されている。
「コンテンツ提供先」に係る情報には、「ユーザID」と「ユーザ属性」が含まれている。「ユーザID」はユーザを特定する識別情報とされる。この例では、「A010001」と「B020003」とが記述されており、これらが、携帯端末52と携帯端末53のユーザの識別情報とされる。なお、ユーザIDは、コンテンツ配信システム11内において各ユーザを一意に特定できるように、予め定められた採番ルールなどに即して各ユーザに割り当てられているものとする。
図38の「ユーザ属性」は、「年齢」、「性別」、「住所」、および「趣向」により構成されており、これらは、それぞれ「ユーザID」により特定されるユーザの「年齢」、「性別」、「住所」、および「趣向」を表す情報が記述される。なお、「趣向」としては、例えば、「スポーツ観戦」、「読書」、・・・などそのユーザの趣味を表す情報が記述されるようにしてもよいし、例えば、「ロック」、「ジャズ」、・・・など楽曲のコンテンツに特化した嗜好を表す情報が記述されるようにしてもよい。
また、実績情報における「ユーザID」および「ユーザ属性」に記述される情報は、後述するようにハンドオーバメッセージに含められるようになされており、例えば、携帯端末51と、携帯端末52または携帯端末53との間でハンドオーバが行われるとき取得される。
「詳細」に係る情報には、「提供開始日時」、「提供終了日時」、「コンテンツID」、および「証明書」が含まれている。「提供開始日時」および「提供終了日時」は、それぞれ「ユーザID」により特定されるユーザに対してコンテンツの提供を開始した時刻、およびコンテンツの提供を終了した時刻を表す情報とされる。
「コンテンツID」は、提供したコンテンツを特定する情報とされる。
「証明書」は、例えば、携帯端末52または携帯端末53に実装されるアプリケーションプログラムによりユーザID「A010001」とユーザID「B020003」のユーザを認証した結果発行される証明書とされる。なお、後述するように、リンク認証の結果を「証明書」に含めるようにしてもよい。
携帯端末52または携帯端末53において、コンテンツをストリーミング再生する際には、予めコンテンツ再生用のアプリケーションプログラムにログオンする必要があり、例えば、ログオン時にパスワードを入力することにより、ユーザが認証されるようになされている。例えば、当該アプリケーションプログラムの開発を行うソフトウェア会社は、秘密鍵と公開鍵を保有しており、秘密鍵は、アプリケーションプログラムとともに携帯端末に実装されている。
コンテンツ再生用のアプリケーションプログラムは、予め登録されたパスワードと一致するパスワードの入力を受け付けた場合、当該ユーザのユーザIDに所定の演算を施して得られた値を自分の秘密鍵で暗号化した証明書を生成するようになされている。
携帯端末51から当該実績情報が送信された場合、サーバ22において、公開鍵を用いて証明書を復号することにより、結果としてサーバ22は、ユーザを認証することが可能になる。例えば、アーティストのプロモーションとしてリリース直後の新曲のコンテンツを配信する場合、コンテンツの提供は携帯端末を通じてユーザに視聴してもらうことに意味がある。このため、各携帯端末におけるユーザの認証結果を証明書として付加することにより、より信頼性の高い実績情報を生成することができる。
なお、上述した証明書の生成は一例であり、別の方式により証明書が生成されるようにしても構わない。また、実績情報には、必ずしも証明書が必要であるわけではなく、例えば、携帯端末52または携帯端末53においてユーザの認証を行うことができない場合、実績情報における「証明書」には、ユーザ認証がなされていない旨の情報が記述されるようにしてもよい。
実績情報の「証明書」には、当該証明書の種類を特定する情報が、その証明書を構成する数値などからなる情報とともに格納されるものとする。従って、実績情報を受信したサーバ22は、当該実績情報に、アプリケーションプログラムによるユーザ認証の結果が含まれているのか否か、または後述のようにリンク認証の結果が含まれているのか否かを認識することができるようになされている。
サーバ22では、このように構成される実績情報を携帯端末51と携帯端末55から受信する。そして、サーバ22は、実績情報を解析して、携帯端末51と携帯端末55とがいつ誰にコンテンツを提供したかを特定し、例えば、単位時間内により多くのユーザにコンテンツを提供した携帯端末を特定する。
このように、サーバ22は、実績情報を解析して、例えば、コンテンツの提供実績の高い携帯電端末を特定するのである。ここでいう、提供実績が高いとは、例えば、単位時間内により多くのユーザにコンテンツを提供したことを意味するものとしてもよいし、プロモーションのターゲットとなる年齢、性別、住所、趣向のユーザにコンテンツを提供したことを意味するものとしてもよい。例えば、プロモーションにおいて、若年者のファン獲得を目標としている場合、「コンテンツ提供先」に係る情報の中の「年齢」により実績情報をフィルタリングして、閾値未満の年齢のユーザにより多くコンテンツを提供した携帯端末の提供実績が高いものとされる。
さらに、実績情報の解析においては、実績情報の「証明書」に、アプリケーションプログラムによるユーザ認証の結果が含まれているのか否か、またはリンク認証の結果が含まれているのか否かが判定されるとともに、その証明書の有効性が判定されるようにしてもよい。ここで、証明書の有効性は、例えば、ユーザ認証の結果とともにリンク認証の結果が含まれている場合に有効と判定したり、証明書の作成日時などが所定の基準を満たすものである場合に有効と判定するなどして得られるものとする。
そして、証明書に含まれる情報の内容(ユーザ認証の結果、リンク認証の結果、またはそれらの両方)とその有効性に基づいて実績情報がフィルタリングされるようにしてもよい。このようにすることで、実績情報にどの程度の信頼性を求めるべきかを考慮してコンテンツの提供実績の高い携帯電端末を特定することが可能となる。
サーバ22は、このようにして特定された提供実績の高い携帯端末に対して、例えば、次回の新曲のコンテンツを優先的に配信するようにする。例えば、サーバ22が、携帯端末51の提供実績が高いと判断した場合、携帯端末51に対しては次回の新曲のコンテンツを無料でダウンロードさせるようにする。あるいはまた、予め設定された基準より高い提供実績が確認された複数の携帯端末に次回の新曲のコンテンツを無料でダウンロードさせるようにしてもよいし、提供実績の高い順に、時間差を付けて新曲のコンテンツを無料でダウンロードさせるようにしてもよい。
あるいはまた、提供実績の高い携帯端末にコンサートのチケットなどの優待特典を付与するようにしてもよい。
このようにすることで、例えば、コンテンツの販売促進を図ることが可能となり、コンテンツを提供するレコード会社などにとって、より効率的なコンテンツの配信を実現することが可能となるのである。
本発明のコンテンツ配信システム11においては、上述した実績情報の収集ができるようにする。そのために、ハンドオーバメッセージに次のような情報を含めるようにする。
図39は、ハンドオーバメッセージのフォーマットを説明する図である。図14を参照して上述した通り、ハンドオーバメッセージは、例えば、携帯端末や情報収集端末が非接触通信(NFC通信)を行うときに送受信される情報とされる。ハンドオーバメッセージのフォーファットについては、NFC Forumによる標準化が行われており、図示されるフォーマットがNFC Forumの規格によって規定されている。
同図の「Record1」乃至「Record4」は、図14を参照して上述したものと同様なので、詳細な説明は省略する。
「Record5」は、「Record4」と同様に、携帯端末などの製造事業者によって定義された情報が格納されるレコードとされる。本発明では、「Record5」に含まれる情報として図示されるようなパケットの情報を定義する。
同図に示されるように、「Record5」には、ヘッダとペイロードからなるパケットが格納される。
ヘッダには、「Record Type」の情報が記述され、いまの場合、レコード5が実績情報収集のために用いられる情報が格納されるレコードであることを表す情報が記述される。
ペイロードは、「ユーザID」、「ユーザ属性」、「ユーザ認証方式」および「ユーザ認証情報」によって構成されている。
「ユーザID」および「ユーザ属性」は、図38を参照して上述した実績情報における「ユーザID」および「ユーザ属性」と同様のものである。
「ユーザ認証方式」は、「ユーザ認証情報」に係る認証方式を特定するための情報とされる。
上述したように、携帯端末52または携帯端末53において、ユーザ認証がなされる場合を考える。例えば、携帯端末52などでコンテンツをストリーミング再生する際には、予めコンテンツ再生用のアプリケーションプログラムにログオンする必要があり、ログオン時にパスワードを入力することにより、ユーザが認証されるものとする。この場合、ユーザIDに所定の演算を施して得られた値を当該アプリケーションプログラムの開発を行うソフトウェア会社の秘密鍵で暗号化して証明書が生成される。
このような場合、例えば、「ユーザ認証方式」には、上述のユーザIDに施す所定の演算を表す情報、および当該ソフトウェア会社を特定する情報などが格納され、「ユーザ認証情報」には、上述の証明書が格納されることになる。
また、例えば、携帯端末52または携帯端末53においてユーザの認証を行うことができない場合、「ユーザ認証方式」には、ユーザ認証がなされていない旨を表す情報などが格納され、「ユーザ認証情報」には空の情報が格納されることになる。
携帯端末51は、このようにハンドオーバメッセージの「Record5」に記述された情報に基づいて、上述の実績情報を生成し、サーバ22に送信するのである。
ここで、実績情報の信頼性をさらに高めたい場合、上述したリンク認証を行い、リンク認証の結果を証明書に含めるようにすることが可能である。すなわち、実績情報が偽造されたものではないことを証明するための情報としてリンク認証の結果を付加することが可能である。
例えば、図37のサーバ22が、図1のサーバ21と同様にリンク認証を行うことが可能である場合、サーバ22がリンク認証の証明書を生成する。この場合、サーバ22は、提供者側(例えば、携帯端末51)と利用者側(例えば、携帯端末52または携帯端末53)との間で行われる通信について図16を参照して上述した処理と同様にしてリンク認証を行う。
そして、サーバ22は、携帯端末51から携帯端末52または携帯端末53に対するコンテンツの提供が完了するまでの間リンク認証が行われたことを表す情報を暗号化するなどして証明書を生成する。例えば、携帯端末52または携帯端末53のユーザのユーザIDとリンク認証の時刻を組み合わせて得られる値などを、サーバ22の固有鍵で暗号して得られた情報が証明書とされる。サーバ22は、コンテンツの提供の終了時に携帯端末51に暗号化された証明書を送信する。
サーバ22は、携帯端末51から送信される実績情報の「証明書」に格納された情報を自分の固有鍵で復号する。これにより、サーバ22は、携帯端末52または携帯端末53のユーザのユーザID、およびリンク認証の時刻を得て、実績情報の内容と突合することで、実績情報が偽造などされていないことを確認することができる。
あるいはまた、図37のサーバ22が、図1のサーバ21と同様にリンク認証を行うことができない場合、サーバ21が上述のようにリンク認証の証明書を生成する。この際、サーバ21が、秘密鍵と公開鍵を保有しているものとする。
いまの場合、例えば、携帯端末52または携帯端末53のユーザのユーザIDとリンク認証の時刻を組み合わせて得られる値などを、サーバ21の秘密鍵で暗号して得られた情報が証明書とされる。サーバ21は、コンテンツの提供の終了時に携帯端末51に暗号化された証明書を送信する。
サーバ22は、携帯端末51から送信される実績情報の「証明書」に格納された情報をサーバ21の公開鍵で復号する。これにより、サーバ22は、携帯端末52または携帯端末53のユーザのユーザID、およびリンク認証の時刻を得て、実績情報の内容と突合することで、実績情報が偽造などされていないことを確認することができる。
上述された証明書そのものを暗号化する方法以外にも、その内容文と秘密鍵(または固有鍵)をハッシュ関数に入力し、その出力値をデジタル署名として証明書に付加する方法も選択し得る。その場合、サーバ22は、その携帯端末などに対応する公開鍵(または固有鍵)を用いて署名を検証することで、証明書内に偽造があった場合には検出することができる。
このように、リンク認証の結果を証明書に含めることで、実績情報の信頼性をさらに高めることができる。
また、上述のようにして得られた実績情報は、コンテンツの効率的な配信に用いられるのみでなく、様々な活用が可能である。
例えば、図40に示されるように、あるユーザの携帯端末から他のユーザの携帯端末にコンテンツが次々とダウンロードされていくコンテンツ配信システム12を想定する。図40の例では、携帯端末61と携帯端末65がサーバ23からコンテンツのデータをダウンロードしている。
なお、サーバ23にも図4を参照して上述した構成が適用される。
また、携帯端末62と携帯端末66は、それぞれ携帯端末61と携帯端末65からコンテンツをダウンロードしている。さらに、携帯端末63と携帯端末67は、それぞれ携帯端末62と携帯端末66からコンテンツをダウンロードしている。
そして、携帯端末61、携帯端末62、携帯端末65、および携帯端末66がサーバ23に実績情報を送信している。
このようなコンテンツ配信システム12において、コンテンツを提供する際に中核となるユーザを実績情報に基づいて特定することも可能である。
サーバ23では、実績情報に基づいて各携帯端末がどの携帯端末にコンテンツを提供したのかを認識することができる。図41は、実績情報における各携帯端末をノードとして作成されたネットワークマップの例を示す図である。同図に円で示されるものがノードを表しており、より多数のノードと接続されているノードがより径の大きい円として示されている。
多数の携帯端末にコンテンツを提供した携帯端末は、コンテンツ配信システム12において重要度の高い携帯端末であり、例えば、その携帯端末のユーザによるコンテンツの評価は、コンテンツの販売に多大な影響があると考えられる。そこで、サーバ23では、実績情報に基づいて中核となるユーザを特定する。
サーバ23は、単に最も多くの携帯端末にコンテンツを提供した携帯端末のユーザを中核となるユーザとして決定するようにしてもよいが、実績情報に基づいてより実効的に中核となるユーザを特定することも可能となる。
例えば、サーバ23は、当該ユーザがコンテンツを提供したユーザの人数に応じた評価値を演算し、評価値を比較することにより、中核となるユーザを特定する。この際、次に示すような重み付けを行って評価値を演算するようする。
例えば、サーバ23は、実績情報の「ユーザID」に基づいて個々の携帯端末が何人のユーザにコンテンツを提供したかを表す情報を取得する。そして、サーバ23は、例えば、実績情報の「コンテンツID」に基づいて、提供したコンテンツの種類やジャンルなどを特定し、その特定結果に基づいてコンテンツを提供したユーザの重み付けを行う。
これにより、例えば、楽曲のコンテンツについて中核となるユーザを特定したり、ゲームのコンテンツについて中核となるユーザを特定したりすることが可能となる。
また、サーバ23は、例えば、実績情報の「提供開始日時」または「提供終了日時」に基づいて、コンテンツを提供したユーザの重み付けを行う。例えば、より最近にコンテンツを提供したユーザについてより大きい重みづけがなされるようにする。
このようにすることで、実績情報の鮮度を考慮して中核となるユーザを特定することが可能となる。
サーバ23は、例えば、サーバ21から評価情報の提供を受けてさらにユーザの重み付けを行うようにしてもよい。例えば、サーバ23は、実績情報のユーザIDに基づいて、そのユーザの携帯端末の識別情報を取得できるものとする。サーバ23は、携帯端末の識別情報に基づいて、サーバ21から評価情報を取得する。そして、例えば、より長いコメントの評価情報が得られた携帯端末のユーザについてより大きい重みづけがなされるようにする。
このようにすることで、例えば、そのコンテンツに興味をもったユーザにコンテンツを提供しているか否かを考慮して、中核となるユーザを特定することが可能となる。
サーバ23は、例えば、このようにして各携帯端末のユーザの評価値を算出する。第n番目のユーザUsernの評価値をV(Usern)で表わした場合、このユーザの評価値は、式(1)により演算される。
式(1)において、変数iは、評価の対象となる第n番目のユーザ(対象ユーザと称することにする)の携帯端末から送信された実績情報に含まれるユーザIDを示す変数とされ、ここでは、M個のユーザIDが含まれていたものとされている。すなわち、第n番目の対象ユーザは、M人のユーザにコンテンツを提供していたものとされる。なお、ここでは、対象ユーザがコンテンツを提供したユーザを提供先ユーザと称することにする。
また、式(1)におけるCatiは、実績情報の「コンテンツID」に基づいて算出される提供先ユーザの重みを表している。Timeiは、実績情報の「提供開始日時」または「提供終了日時」に基づいて算出される提供先ユーザの重みを表している。Evaliは、評価情報に基づいて算出される提供先ユーザの重みを表している。
これ以外にも、提供先ユーザの年齢や性別による重み付けがなされるようにしてもよい。
式(1)を参照して上述した評価値により特定されるユーザは、コンテンツの提供において起点となるユーザと考えることもでき、いわばハブとなるユーザである。しかしながら、コンテンツの提供において重要性の高いユーザを別の観点から特定することも可能である。
例えば、ユーザ同士がグループを形成している場合、コンテンツの提供もこのグループ内で行われることが多い。例えば、学生であるユーザの間でコンテンツが次々とダウンロードされていく場合を考える。この場合、例えば、同じサークルに属するユーザの間では比較的簡単にコンテンツのダウンロードが行われるが、別のサークルに属するユーザによってコンテンツがダウンロードされる機会は少ない。
このような場合、中核となるユーザを特定するにあたり、どれだけ多くのユーザにコンテンツを提供しているかという観点よりも、別のサークルにコンテンツを提供しているかという観点が重要になると考えられる。つまり、個々のサークル内では簡単にコンテンツのダウンロードが行われると考えられるので、サークルとサークルをつなぐいわばコネクタとなるユーザが重要な存在となるのである。
例えば、サーバ23において実績情報を解析することにより、各携帯端末のユーザのそれぞれについて、過去のコンテンツの提供の履歴を得ることができる。例えば、各携帯端末のユーザのそれぞれについて、過去3カ月以内にコンテンツを提供したユーザの一覧を生成することで、過去のコンテンツの提供の履歴とすることができる。
サーバ23は、このようなコンテンツの提供の履歴に基づいてコネクタとなるユーザを特定することができる。図42は、コネクタとなるユーザを特定する方式を説明する図である。同図においては、U1、U2、・・・の記号により表わされる円のノードとして各ユーザが示されている。いま、同図のU1と示されたノードのユーザについて、コネクタとなるユーザであるか否かを判定するものとする。
サーバ23は、既に蓄積されている実績情報に基づいて、ユーザU1が過去3カ月以内にコンテンツを提供したユーザの一覧を生成する。いまの場合、ユーザU1は、過去にユーザU9とユーザU10にコンテンツを提供していたものとされる。
サーバ23は、既に蓄積されている実績情報に基づいて、ユーザU9とユーザU10が過去3カ月以内にコンテンツを提供したユーザの一覧を生成する。いまの場合、ユーザU9は、ユーザU11、ユーザU5、およびユーザU12にコンテンツを提供していたものとされる。また、ユーザU10は、ユーザU8、およびユーザU13にコンテンツを提供していたものとされる。
このようにして、ユーザU1についての所属グループが特定される。
サーバ23は、ユーザU1の携帯端末から新たに送信された実績情報に基づいて、ユーザU1からユーザU2にコンテンツが提供されたと判定する。サーバ23は、上述した場合と同様に、既に蓄積されている実績情報に基づいて、ユーザU2についての所属グループ(提供先グループと称することにする)を特定する。
そして、サーバ23は、所属グループと提供先グループにおいて重複しているユーザの数をカウントする。この例では、ユーザU5とユーザU8が重複しているので、重複ユーザ数は2とされる。また、サーバ23は、所属グループと提供先グループにおいて重複していないユーザ(ユニークユーザと称することにする)の数をカウントする。この例では、所属グループと提供先グループのそれぞれにおいて、ユニークユーザ数は5とされる。
サーバ23は、例えば、所属グループのユニークユーザ数と提供先グループのユニークユーザ数とを合計し、コネクタとなるユーザの評価値を算出する。そして、算出された評価値に基づいてコネクタとなるユーザが特定されるのである。
なお、図42の例では、所属グループおよび提供先グループのグループ深度を3とした場合の例について説明した。すなわち、ユーザU1とユーザU2のそれぞれを起点として、3階層のコンテンツの提供の履歴に基づいて所属グループおよび提供先グループが形成されている。実際にコネクタとなるユーザを特定する際のグループ深度は、任意に設定されるようにして構わない。
このように、サーバ23は、ハブとなるユーザ、またはコネクタとなるユーザを特定することができる。このようなユーザは、例えば、バイラルマーケティングを行うにあたり重要な情報とされている。サーバ23の運用業者は、上述のように特定したハブとなるユーザ、またはコネクタとなるユーザに関する情報を、例えば、ゲームソフトメーカなどのコンテンツ事業者に有料で提供するなどのサービスを行うことも可能である。
次に、図43のフローチャートを参照してサーバ22の処理について説明する。この処理は、例えば、実績情報に基づくコンテンツの配信が指令されたとき実行される。
ステップS3011において、サーバ22は、実績情報を受信する。このとき、例えば、図37の携帯端末51と携帯端末55から送信された実績情報が受信される。
ステップS3012において、サーバ22は、ステップS3011で受信した実績情報を解析する。このとき、例えば、コンテンツの提供実績の高い携帯電端末を特定するための解析が行われる。ここでいう、提供実績が高いとは、例えば、単位時間内により多くのユーザにコンテンツを提供したことを意味するものとしてもよいし、ターゲットとなる年齢、性別、住所、趣向のユーザにコンテンツを提供したことを意味するものとしてもよい。例えば、プロモーションにおいて、若年者のファン獲得を目標としている場合、「コンテンツ提供先」に係る情報の中の「年齢」により実績情報をフィルタリングして、閾値未満の年齢のユーザにより多くコンテンツを提供した携帯端末の提供実績が高いものとされる。
また、このとき、証明書に含まれる情報の内容(ユーザ認証の結果、リンク認証の結果、またはそれらの両方)とその有効性に基づいて実績情報がフィルタリングされるようにしてもよい。
ステップS3013において、サーバ22は、ステップS3012の処理の結果に基づいて各携帯端末の提供実績の高さを数値化する。
ステップS3014において、サーバ22は、ステップS3013の処理の結果に基づいて、次回の新曲のコンテンツを優先的に配信するようにする。
このとき、例えば、ステップS3013の処理の結果得られた数値を各携帯端末について相互に比較、または予め設定閾値と比較することで、提供実績の高い携帯端末が特定される。そして、例えば、サーバ22が、携帯端末51の提供実績が高いと判断した場合、携帯端末51に対しては次回の新曲のコンテンツを無料でダウンロードさせるようにする。あるいはまた、予め設定された基準より高い提供実績が確認された複数の携帯端末に次回の新曲のコンテンツを無料でダウンロードさせるようにしてもよいし、提供実績の高い順に、時間差を付けて新曲のコンテンツを無料でダウンロードさせるようにしてもよい。
あるいはまた、提供実績の高い携帯端末にコンサートのチケットなどの優待特典を付与するようにしてもよい。
このようにして、サーバ22の処理が実行される。
次に、図44のフローチャートを参照して、サーバ23の処理について説明する。この処理は、例えば、実績情報に基づくハブユーザやコネクタユーザの特定が指令されたとき実行される。
ステップS3031において、サーバ23は、実績情報を受信する。このとき、例えば、図40の携帯端末62と携帯端末67から送信された実績情報が受信される。
ステップS3032において、サーバ23は、ステップS3032で受信した実績情報を解析する。
このとき、例えば、サーバ23は、実績情報の「ユーザID」に基づいて個々の携帯端末が何人のユーザにコンテンツを提供したかを表す情報を取得する。そして、サーバ23は、例えば、実績情報の「コンテンツID」に基づいて、提供したコンテンツの種類やジャンルなどを特定し、その特定結果に基づいてコンテンツを提供したユーザの重み付けを行う。
あるいはまた、サーバ23は、例えば、実績情報の「提供開始日時」または「提供終了日時」に基づいて、コンテンツを提供したユーザの重み付けを行うようにしてもよい。さらに、携帯端末の識別情報に基づいて、サーバ21から評価情報を取得して、例えば、より長いコメントの評価情報が得られた携帯端末のユーザについてより大きい重みづけがなされるように重み付けがなされてもよい。
このような解析結果は、後述するハブユーザ特定処理において用いられる。
またこのとき、例えば、サーバ23は、各携帯端末のユーザのそれぞれについて、過去3カ月以内にコンテンツを提供したユーザの一覧を生成することで、過去のコンテンツの提供の履歴を生成する。
このような解析結果は、後述するコネクタユーザ特定処理において用いられる。
ステップS3033において、サーバ23は、ハブユーザ特定処理を実行する。ここでは、例えば、ステップS3032の処理の結果に基づいて各携帯端末のユーザの評価値が算出される。ユーザの評価値は、例えば、上述した式(1)により演算される。
これにより、ハブユーザが特定されることになる。
ステップS3034において、サーバ23は、コネクタユーザ特定処理を実行する。ここでは、例えば、ステップS3032の処理の結果に基づいて、図42を参照して上述したように、所属グループと提供先グループにおいて重複しているユーザの数がカウントされる。そして、所属グループと提供先グループにおいて重複していないユニークユーザの数がカウントされ、所属グループのユニークユーザ数と提供先グループのユニークユーザ数とを合計し、コネクタとなるユーザの評価値が算出される。
これにより、コネクタユーザが特定されることになる。
ステップS3035において、サーバ23は、ステップS3033の処理で特定されたハブユーザのユーザID、ステップS3034の処理で特定されたコネクタユーザのユーザIDを出力する。
このようにして、サーバ23の処理が実行される。
図37乃至図44を参照して上述した実施の形態においては、ハンドオーバ機能を有する携帯端末によるコンテンツの提供に係る実績情報に基づいてサーバ22が、より効率的なコンテンツの配信を行う例、サーバ23がハブユーザまたはコネクタユーザを特定する例について説明した。しかし、サーバ22またはサーバ23により処理される実績情報は、ハンドオーバ機能を有する携帯端末によるコンテンツの提供に係る実績情報に限られるものではない。例えば、有線の通信によりコンテンツを提供する端末によるコンテンツの提供に係る実績情報が処理されるようにしてもよい。
また、図37乃至図44を参照して上述した実施の形態においては、コンテンツの提供に係る実績情報を取り扱う例について説明したが、例えば、コンテンツ以外の電子情報財の提供に係る実績情報を取り扱う場合にも本発明を適用することが可能である。
以上においては、ハンドオーバ時に非接触通信が行われ、その後近距離無線通信が行われると説明したが、本発明を適用可能な実施の形態はこれに限られるものではない。例えば、NFCなどの非接触通信の代わりに、端子を接触させる接触型通信が用いられ、近距離無線通信の代わりに、通常の有線LANが用いられるようにしてもよい。
また、以上においては、サーバと携帯端末などとの間で行われる広域通信は、移動体通信網用無線通信が用いられると説明したが、本発明を適用可能な実施の形態はこれに限られるものではない。例えば、移動体通信網用無線通信の代わりに固定通信網通信や独自のネットワークを用いた通信が用いられるようにしてもよい。
なお、上述した一連の処理は、ハードウェアにより実行させることもできるし、ソフトウェアにより実行させることもできる。上述した一連の処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが、専用のハードウェアに組み込まれているコンピュータにネットワークや記録媒体からインストールされる。また、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、汎用のパーソナルコンピュータなどに、ネットワークや記録媒体からインストールされる。
上述した一連の処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが、インターネットなどのネットワークや、リムーバブルメディアなどからなる記録媒体からインストールされる。
なお、本明細書において上述した一連の処理は、記載された順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理をも含むものである。
また、本発明の実施の形態は、上述した実施の形態に限定されるものではなく、本発明の要旨を逸脱しない範囲において種々の変更が可能である。