以下、図面を参照して、本発明の実施の形態について説明する。
本発明においては、例えば、携帯端末のハンドオーバ機能を利用して評価情報を収集するようにする。
例えば、携帯電話機として構成される携帯端末が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からユーザのプロフィールなどの情報やゲームの操作情報などが携帯端末45に送信される。
図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は、アンテナを経由して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は、それぞれ、図3の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で受信した一時キーをBT132−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において、コンテンツの評価が終了したと判定された場合、処理は終了する。
このようにして、評価者側端末機器の処理が実行される。
以上においては、ハンドオーバ時に非接触通信が行われ、その後近距離無線通信が行われると説明したが、本発明を適用可能な実施の形態はこれに限られるものではない。例えば、NFCなどの非接触通信の代わりに、端子を接触させる接触型通信が用いられ、近距離無線通信の代わりに、通常の有線LANが用いられるようにしてもよい。
また、以上においては、サーバと携帯端末などとの間で行われる広域通信は、移動体通信網用無線通信が用いられると説明したが、本発明を適用可能な実施の形態はこれに限られるものではない。例えば、移動体通信網用無線通信の代わりに固定通信網通信や独自のネットワークを用いた通信が用いられるようにしてもよい。
なお、上述した一連の処理は、ハードウェアにより実行させることもできるし、ソフトウェアにより実行させることもできる。上述した一連の処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが、専用のハードウェアに組み込まれているコンピュータにネットワークや記録媒体からインストールされる。また、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、汎用のパーソナルコンピュータなどに、ネットワークや記録媒体からインストールされる。
上述した一連の処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが、インターネットなどのネットワークや、リムーバブルメディアなどからなる記録媒体からインストールされる。
なお、本明細書において上述した一連の処理は、記載された順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理をも含むものである。
また、本発明の実施の形態は、上述した実施の形態に限定されるものではなく、本発明の要旨を逸脱しない範囲において種々の変更が可能である。