放送番組の視聴率をＰ２Ｐネットワークを使用して集計するシステム
【課題】 ユーザにとってより有用な視聴情報の推薦を可能にすべく、放送番組の視聴率をP2Pネットワークを使用して集計するシステムを提供する。
【解決手段】 複数の視聴者に対応したノードを接続したネットワークを利用した視聴率を集計するシステムにおいて、各ノードから、他のノードに対して受信リンクを張る手段と、ネットワークを構成する各ノードが、受信リンクを張られたノードに対して定期的にリンクを介して視聴率に関するデータを送信する手段と、各ノードにおいて、視聴率に関するデータを収集し、集計する手段と、集計された視聴率に関するデータが、一定期間受信されないノードとの受信リンクを切断し、他のノードとのリンクを張りなおす手段とを有する。
【解決手段】 複数の視聴者に対応したノードを接続したネットワークを利用した視聴率を集計するシステムにおいて、各ノードから、他のノードに対して受信リンクを張る手段と、ネットワークを構成する各ノードが、受信リンクを張られたノードに対して定期的にリンクを介して視聴率に関するデータを送信する手段と、各ノードにおいて、視聴率に関するデータを収集し、集計する手段と、集計された視聴率に関するデータが、一定期間受信されないノードとの受信リンクを切断し、他のノードとのリンクを張りなおす手段とを有する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、放送番組の視聴率をP2Pネットワークを使用して集計するシステムに関するものである。
【背景技術】
【０００２】
社会の情報化が進むにつれて、我々が触れることのできる情報は爆発的に増えてきた。情報の増加は、ユーザの柔軟な選択を可能とし、より豊かな生活をもたらすものである。しかし膨大すぎる情報は、ユーザの情報処理能力をはるかに超え、逆にユーザの生活を妨げるものとなっている。
例えば、近年放送のデジタル化が進み、TVコンテンツも急速に増加して、ユーザはよりニーズにあった番組を視聴できるようになった。しかし、従来はチャンネル数が少なくザッピングによってどんな番組が放送されているのか気軽に確認することができていたが、チャンネル数が増加した現在では、どんな番組が放送されているのかを確認するだけで多くの時間を費やしてしまう。
また、情報雑誌から見たい番組を探すという方法もよく行われている方法ではあるが、そういった雑誌は万人向けの番組を紹介することが多く、ユーザのニッチな要望に応えるものではない。2011年には地上アナログ放送から完全に地上デジタル放送へ移行することも予定されており、今後このような問題はより顕著になっていくものと考えられる。
【０００３】
このような問題を解決する従来技術として、情報検索技術がある。これは、膨大な情報の中から効率的に必要な情報を見つけることを目的としている。代表的なものには検索エンジンが挙げられる。検索エンジンは、インターネット上に散らばる膨大な情報の中から希望した情報を検索して返してくれる。しかしユーザが適切な検索式を入力しないと、望みどおりの情報を得ることはできない。また、検索結果が膨大な量になることもしばしばあり、その場合、膨大な検索結果の中からさらに望みの情報を絞り込まなければならない。情報検索はユーザの能力にも大きく依存するのである。
【０００４】
そこで、情報検索のこのような問題を解決する手法として情報推薦がある。情報推薦とは、ユーザの好みや要求をシステムが推測し、それに合致する情報を自動的に探してユーザに提示する、という技術である。情報推薦は情報検索のようにユーザの能力に依存することはなく、そのためユーザは何も意識することなく望みの情報を手に入れることができる。ユーザの負担が少ない情報推薦技術は、情報過多社会において非常に重要視されているのである。
しかし、従来の情報推薦手法は主にユーザの好みを重要視しており、情報の質を深く考慮していない。そのため良い推薦結果が得られないことも多々ある。ここでの情報の質とは、ユーザにとってその情報がどれだけ価値のあるものかという意味である。どれだけその情報が貴重であろうが、ユーザにとって全く役に立たない情報に価値はない。また、ユーザによって価値観は異なるため、あるユーザにとって価値がある情報でも他のユーザにとって価値があるとは限らない。すなわち、情報の質はユーザ１人１人によって決定されると言うこともできる。
【０００５】
以上のような背景を踏まえ、本発明では情報推薦手法について扱う。特に、従来の推薦手法で軽視されている情報の質を取り上げて、推薦結果向上の実現方法を探る。なお、情報推薦の対象の好ましい一例としては、今後のデジタル放送社会を考えTV番組とする。
従来のTV番組の推薦システムは、ユーザの好みに合う番組を推測することが目標であった。しかし、情報の質すなわち番組コンテンツの価値という観点から見ると、ユーザが望む推薦システムは、自分の好みに合う番組で且つ自分にとって見る価値がある番組を推薦するものであると言える。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
本発明は上記従来事情に鑑みてなされたものであり、その課題とする処は、ユーザにとってより有用な視聴情報の推薦を可能にすべく、放送番組の視聴率をP2Pネットワークを使用して集計するシステムを提供することにある。
【課題を解決するための手段】
【０００７】
上記課題を解決するために本発明は、複数の視聴者に対応したノードを接続したネットワークを利用した視聴率を集計するシステムにおいて、各ノードから、他のノードに対して受信リンクを張る手段と、ネットワークを構成する各ノードが、受信リンクを張られたノードに対して定期的にリンクを介して視聴率に関するデータを送信する手段と、各ノードにおいて、視聴率に関するデータを収集し、集計する手段と、集計された視聴率に関するデータが、一定期間受信されないノードとの受信リンクを切断し、他のノードとのリンクを張りなおす手段とを
有することを特徴とする。
【０００８】
更に好ましくは、視聴率データを収集し、集計する手段は、各ノードが、各ノード自身の情報（0次情報）、他の1つのノードが得た情報（1次情報）、さらに他の1つのノードを介して得た情報（2次情報）・・・毎に集計することを特徴とする。
【発明を実施するための最良の形態】
【０００９】
本発明に係る実施の形態では、番組の質を考慮した上で、番組推薦の精度の向上を目指す。そこで先ずは、従来の典型的な推薦手法を分析し、次に情報の質を決定する上で重要な要素となる個々のユーザの情報を効果的に利用することについて説明する。そして、従来の推薦手法が番組の質を考慮していないために現れる問題を述べる。
【００１０】
（従来の情報推薦手法）
情報推薦の研究は数多く行われており[1]、代表的な手法にコンテンツベース推薦[2]とコラボレーティブ推薦[3]がある。
（参考文献）
[1] Adomavicius, G and Tuzhilin A.: Toward the next generation of recommender systems: A survey of the state-of-the-art and possible extensions; IEEE Trans. KDE, Vol.17, No.6, pp.734-749, 2005.
[2] M. Balabanovic and Y. Shoham: Fab: Content-Based, Collaborative Recommendation; Comm. ACM, Vol.40, No.3, pp.66-72, 1997.
[3] P.Resnick, N. Iakovou, M. Sushak, P. Bergstorm, and J. Riedl: GroupLens: An Open Architecture for Collaborative Filtering of Netnews; Proc. of 1994 ACM Conference on Computer Supported Cooperative Work pp.175-186., 1994.
【００１１】
コンテンツベース推薦は、ユーザの視聴履歴情報に基づいて推薦する手法である。システムは、ユーザの視聴履歴からどんなものを好んで視聴しているかを学習し、その好みと合致するものをユーザに提示する。そのため、この手法では比較的ユーザの希望通りの情報推薦が期待できる。しかし、ユーザの視聴履歴からはずれる情報が推薦されることはなく、例えば、ユーザ自身がまだ気づいてない自分の好みを発見する、という体験をすることは出来ない。図１は、番組推薦におけるコンテンツベース推薦を模式的に表したものである。大きな円は視聴者Aの視聴履歴から求められる視聴者Aの嗜好を表している。視聴者Aには、この嗜好の中に含まれる番組が推薦されることになり、比較的精度の高い推薦結果が得られる。
【００１２】
一方コラボレーティブ推薦は、自分と嗜好が似ているユーザの履歴情報を参考にして推薦を行う手法である。自分と嗜好が似ているユーザの好みに合うもので、まだ自分にとって未視聴である情報を推薦する、というものである。図２はこれを模式的に表したものである。視聴者Aと視聴者Bは嗜好が重なっており、お互いの好みが似ている。そこで、視聴者Aの嗜好に含まれない番組でも、視聴者Bの嗜好に含まれていれば視聴者Aもきっと好きであろうと推測し、その番組を視聴者Aに推薦するわけである。この手法では他のユーザの視聴履歴を利用するため、各ユーザの嗜好情報が豊富でかつ多様なユーザが存在すれば、情報推薦は効果的に行われる。また、コンテンツベース推薦の欠点である、新しい好みの発見という問題も解決できる。
【００１３】
しかし、コラボレーティブ推薦には情報伝播の境界”コラボレーティブホライズン”が存在することも指摘されている[4]。コラボレーティブ推薦では、人から人へと推薦を行うことによって情報推薦の伝播が発生する。しかし、嗜好の似ているユーザ同士で閉じたグループを形成してしまう可能性があり、そのグループには他のユーザからの推薦が行われない(図３参照)。これを解決するために、Forced Social Filtering[4]が提案されている。これは、閉じたグループに対して、グループの嗜好は考えず、とりあえず試しに推薦してみる、という方法をとっている。これによって情報伝播の境界は解消され、ユーザ全体で見れば効率的なコラボレーティブ推薦が行われる。しかし個々のユーザから見ると、試しに行った推薦が成功するとは限らず課題も残る。
（参考文献）
[4] 田野 俊一, 木根 智也, 石谷 規彦: 広域的強化学習によるデジタル情報推薦の活性化手法; 電気学会論文誌 C, Vol. 121-C, No.7, pp.1237-1245, 2001.
【００１４】
（個々のユーザの情報の利用）
近年、インターネット技術の普及によって多数のユーザが自分の情報をインターネット上に頻繁に発信するようになってきた。そこで、これらのユーザが発信した情報を利用して有益な成果を得ようとする新しい試みが出てきている。その1つに、様々なユーザによって投稿されたインターネット掲示板上のメッセージを利用し、それを番組コンテンツへのアノテーションに役立てようとする研究がある[5]。
（参考文献）
[5] 岡本 直之, 竹之内 隆夫, 川村 隆浩, 大須賀 昭彦, 前川 守: 放送番組に対してパブリックオピニオン・メタデータを生成する視聴支援エージェントの開発〜ネットコミュニティからの雰囲気成分の抽出とユーザ間での流通による洗練化〜; 電子情報通信学会, Vol. J88-D-I, No.9, pp.1477-1486, 2005.
【００１５】
このインターネット掲示板は放送中の番組と連動しており、番組を視聴しているユーザがリアルタイムにメッセージを投稿する。そこでこの研究では、投稿された特定のメッセージの出現頻度を計算することで、そのときの掲示板での話題と盛り上がりを番組と関連付けて検出している(図４参照)。こうして得られたデータは番組のメタデータとして利用できる。
個々のユーザが自由に発信する情報は、役に立たないゴミの情報が大部分を占めるが、中には非常に価値のある情報も含まれている。この研究は、そのような情報の中から価値のある情報を抽出して効果的に利用している。
【００１６】
（従来の情報推薦手法の問題点）
従来の情報推薦システムは、コンテンツベース推薦とコラボレーティブ推薦を組み合わせて両方の利点を利用するものなどが多い。しかしどの推薦手法も、目的はユーザの好みの情報を推測することである。テレビ番組の推薦ならば、番組のEPG(電子番組ガイド)データとユーザの視聴履歴、及び他のユーザの視聴履歴を用いて、出来る限りユーザの好みに合う番組を推測することが目標であった。
しかし、ユーザの好みを利用した番組推薦は番組の表面的な概要しか見ていない。実際に番組を見て本当にユーザが見たいと思う内容か判断しているわけではないため、ユーザは推薦された番組を見て落胆することが多い。たとえ好みの番組で毎週見ている番組でも、毎回面白い回とは限らず、時にはつまらなく感じる回もあり、このような場合は実際に番組を見て判断するしかない。
【００１７】
ユーザが見たいと思う番組を推測するためには、さらにユーザの視聴行動を知る必要がある。ユーザは必ずしも自分の好みに合う番組を見るわけではない。世間の動向を把握するために話題の番組を見ることもあれば、友人との話しのネタに普段は見ないような番組を見ることある。その結果自分の新しい好みを発見することもあるだろう。このようなユーザには、好みに合う番組を推測しても意味がない。そもそも、ユーザが求める番組と推薦システムが推測しようとする番組がずれているのである。これが従来の推薦手法の限界である。本発明に係る実施の形態ではこのような状況にも対応できる番組推薦を目指す。そのためには、各ユーザの要求を考慮した上で番組推薦を行う。
【００１８】
（本実施の形態のアプローチ）
本実施の形態では、従来の番組推薦と、番組の質を考慮した新しい番組推薦を同時に行うことで、ユーザが本当に見たいと思う番組を推測する。
この２つの推薦手法はタイプが違うため利用する情報も異なる。情報は、その性質が異なれば扱い方も異なるため、まずはこれらの推薦手法において情報の分類を行う。その上でそれぞれの推薦手法に適した情報の利用方法を検討する。
本実施の形態では、推薦手法としてコンテンツベース推薦を用いる。その他の手法も有用ではあるが、それらはどれも本質的な目的はコンテンツベース推薦と同一であるため、本実施の形態では利用しない。
番組の質を考慮した番組推薦手法に関しては、上記したように、２つの要求事項が存在する。１つ目は、ユーザの細かい要求に対応できなければならないことである。これは、必要に応じてユーザに推薦して欲しい番組の方向性を決定してもらうことで対応できる。２つ目は、正確な番組の価値を知るために実際にその番組を視聴する必要があるということである。これについても、多数のユーザが協力し合うことで解決できる。自分以外の多数のユーザが様々な価値観で番組を視聴し、その価値を決定していれば、それは自分にとっても非常に参考になる情報だからである。特に自分と価値観が似ているユーザの評価は、自分の評価と似た結果になり信頼できるものとなる。したがって、番組の質を考慮した番組推薦には、多数のユーザによる番組評価を集計して得られる集計結果を利用する。
【００１９】
以上をまとめると以下のようになる。
・従来の推薦手法と番組の質を考慮した推薦手法で、どのような情報を扱うか明確にする
・推薦手法としてコンテンツベース推薦を用いる
・必要に応じて、ユーザが番組推薦の方向性を決定する
・多数のユーザに番組の評価をしてもらい、その評価の集計結果を番組推薦に利用する
【００２０】
［情報の分類と利用］
次に、従来の推薦手法および番組の質を考慮した新しい推薦手法で利用する情報の分析について説明する。
（番組推薦で利用する情報）
（従来の番組推薦手法）
従来の番組推薦手法はユーザの嗜好を用いて番組推薦を行う。ユーザが好んで視聴する番組の概要データをEPG(電子番組ガイド)データから取得し蓄積することで、その蓄積されたデータがユーザの嗜好を表すデータとなる。よって、従来の番組推薦手法はEPGデータに頼った推薦手法と言える。
このEPGデータは特定の機関が提供しており、正確で信頼できる情報である。個々のユーザが自由に発信できる類の情報ではない。このような情報のことをフォーマル情報と呼ぶ。
【００２１】
（新しい番組推薦手法）
新しい番組推薦手法では、番組の質を評価するために番組に対する多数のユーザの評価という情報を利用する。これは、EPGと異なりユーザが自由に発信することができる。ただし、ユーザが自由に発信できてしまうためにいいかげんで嘘の情報が含まれることもある。このような情報のことを一般にインフォーマル情報と呼ぶ。
【００２２】
番組推薦に利用する情報に関して、従来の推薦手法ではフォーマル情報を利用し、新しい推薦手法ではインフォーマル情報を利用するという明確な違いが明らかになった。すなわち、従来の推薦手法では番組コンテンツをフォーマル情報で評価し、新しい推薦手法では番組コンテンツをインフォーマル情報で評価している。そこで本実施の形態では、これら２つの手法で番組コンテンツを定量的に評価するため、ユーザの好みや番組の概要を表す「ジャンル」と、番組の質や価値を表す「バリュー」を定義し、この２つを番組コンテンツの評価軸として導入する。ただし、番組の質や価値はユーザの価値観の違いによって複数の指標が存在する。よって、バリューも複数存在し得る。
ところで、インフォーマル情報は従来の推薦手法では扱われず、番組の質を考慮した新しい番組推薦手法で初めて積極的に導入されるものである。そこで、次の節ではインフォーマル情報の分析を行う。
【００２３】
（インフォーマル情報）
インフォーマル情報とは、雑談やうわさ、口コミなどで伝えられる非公式な情報のことである。その特徴として、”いいかげん”、”本音”、”うそ”といった性質を持つ。
一方、インフォーマル情報と対照的なものにフォーマル情報がある。フォーマル情報は、TVや新聞、雑誌などの権威あるメディアを通して伝えられる公式な情報のことである。その特徴として、“正確”、”建前”、”信憑性がある”といった性質を持つ。
従来より、正確で定型的であるという性質から様々なシステムで利用されてきたのはフォーマル情報である。一方、インフォーマル情報は、不定型でいいかげんであるという理由のため敬遠されてきた。しかし、インフォーマル情報にはユーザの本音の情報が含まれておりその利用価値は高い。インフォーマル情報はその扱い方さえ間違えなければ価値を引き出すことが出来る。
【００２４】
例えば、書籍”Wisdom of Crowds”では、一定の条件の下で多数のユーザの主観的な意見の集約が案外正しいことを示す事例を多く紹介している[6]。また、インターネット上の百科事典であるWikipedia[7]は、ユーザが自由に加筆、修正を行えるにもかかわらず、掲載されている情報は大部分が正しい情報であるという。このように、多数のユーザのインフォーマル情報は集約することでその価値を抽出することが可能になる。
（参考文献及び参考ＵＲＬ）
[6] ジェームズ・スロウィッキー, 小高: 「みんなの意見は案外正しい」, 角川書店, 2006.
[7] “ウィキペディア”, http://ja.wikipedia.org/
【００２５】
従来からフォーマル情報ばかりが利用されてきた理由に、多数のインフォーマル情報を気軽に共有できる場が存在しなかったことも挙げられる。そこで次に、メディアの発展とともにインフォーマル情報の共有について考察する。そして、TV番組に関して多数のインフォーマル情報が共有され得るのか分析する。
【００２６】
メディアは言葉やジェスチャー、文字といったものから、印刷、ラジオ、電話、TVへと発展し、さらに現在のPC、携帯電話、インターネットへと発展を遂げた。このようなメディアの発展により、フォーマル情報、インフォーマル情報の共有は共に大きく向上した。しかし、印刷〜TVといったメディア、特にラジオやTVについては、権威ある者が発信する情報が大部分を占める。すなわちラジオやTVの登場は、フォーマル情報の共有だけを飛躍的に増加させた。この時点で、インフォーマル情報の共有はそれほど飛躍的には向上しなかった。その後インターネットが普及し、誰でも自分のWebページを不特定多数に公開できるようになり、フォーマル情報以上にインフォーマル情報の共有が急増した。その流れを後押しするように、自由な情報発信を保護する目的でP2P(Peer-to-Peer)技術を利用したネットワークも登場した。さらにインターネットは、手紙、電話、ラジオ、TVなどの機能(メールやインターネットTVなど)も内包し、これまで主に一部の者だけが情報発信してきた既存メディアすらも、個人の情報発信の手段へと変化させた。インターネットは、既存のメディアも巻き込んでインフォーマル情報の爆発を引き起こしたのである[11][12]。
その結果、現在インターネット上には無数のインフォーマル情報が存在する。ここで、特にTV番組に関するインフォーマル情報の共有について調べる。図５は、インターネット上のある匿名掲示板群における、2005年のTV番組に対するメッセージ投稿数の順位を番組ジャンルごとに集計したものである。前記匿名掲示板群には、主要放送キー局ごとに掲示板が用意されおり、放送番組に対してリアルタイムに多くのメッセージが投稿されている。図５はそれらの掲示板のメッセージ数を集計したものである。
（参考文献）
[11] 田野 俊一, 岩田 満, 橋山 智訓:インフォーマル情報爆発とそれを活用するユーザインタフェースの事例; ヒューマンインタフェースシンポジウム, pp.1175-1180, 2006.
[12] 小井土 祐三, 田野 俊一, 岩田 満, 橋山 智訓:新たな視聴支援方法の提案とインフォーマル視聴情報のP2P集計アルゴリズムの実現; ヒューマンインタフェースシンポジウム, 2006.
【００２７】
図５から、TV番組に対して多いもので毎分数百ものメッセージが投稿されていることがわかる。また、どの番組ジャンルに対しても投稿数は多く、TV番組に関するインフォーマル情報は溢れているということが確認できる。よって、番組推薦においてもインフォーマル情報を活用できる可能性は十分にあると考えられる。ただし、本実施の形態では、インターネット掲示板上のインフォーマル情報を利用するというわけではない。
【００２８】
（インフォーマル情報の発信の活性化）
ユーザの発信するインフォーマル情報を利用する場合は、いかにユーザのインフォーマル情報の発信を活性化させるかが重要な問題となる。特に、すでに情報発信の活性化に成功している従来システムを情報源として利用しない場合は、この問題はやっかいである。本実施の形態では情報源にそのような既存のシステムは利用しない。そのようなシステムがこれからも存在するとは言い切れないからである。そこで本実施の形態では、一般的な視聴行動からインフォーマル情報を取得することを前提とする。
【００２９】
インフォーマル情報発生の活性化に関連する研究としては、インフォーマルコミュニケーションの支援がある。インフォーマル情報は特にインフォーマルコミュニケーションから大量に発生しやすい。このインフォーマルコミュニケーションは、情報の獲得や共有、知的創造活動の促進といった役割を果たすため従来から重要視されているものである。そのため、インフォーマルコミュニケーションを促す研究は数多くなされており、特に、相手との親近感とコミュニケーションのきっかけが重要な要素であると考えて、仮想的な対面環境を構築したり、対面環境でのインフォーマルコミュニケーションのきっかけを与える研究が多い。一方で、対面環境も支援せず、やりとりする情報もテキストデータのみという匿名掲示板で、対面環境以上に本音であると思われるやりとりが頻繁に行われているという事実もある。
本来は、これらを詳細に分析し、TV視聴という環境においてインフォーマル情報の発生を活発にする手法を検討すべきであるが、本実施の形態ではそこまでは扱わず、この問題に関しては今後の重要な課題とする。
【００３０】
（番組推薦におけるバリュー）
以上までで、番組の質を考慮した番組推薦手法に、ユーザの番組に対する評価、すなわちインフォーマル情報が利用できることが分かった。しかし、ユーザのインフォーマル情報が具体的にどのような情報なのかはまだ分からない。そこで次に、ユーザの視聴行動から得られる具体的なインフォーマル情報を示し、それらの情報から得られるバリューについて説明する。
【００３１】
ユーザの番組視聴行動から取得できる情報には以下のようなものが考えられる。
・どの番組を視聴しているか
・番組の視聴時間
・ブックマークしたかどうか
・録画、予約録画したかどうか
・録画番組の視聴回数
・番組に対する感想
・番組に対する感情
・番組に対するアノテーション
【００３２】
すなわち、これらの情報から番組の質を評価することになる。例えば、視聴回数が多ければその番組はそれだけ面白く質が高いと評価できる。よって、番組の質を考慮した番組推薦を実現するためには、多数のユーザからこれらの情報を収集することになる。そして収集した情報を集約することで、ユーザは様々なバリューを得ることができる。その中でも番組推薦に利用しやすいバリューを以下に示す。
・番組の人気度
・番組の性質
・番組に対する期待度
・番組に対する満足度
・番組に対する感情
【００３３】
番組の人気度は、どれだけ多くのユーザが好んで番組を視聴しているかを表すものである。これは、番組の視聴率や番組の視聴回数などから計算できる。世間で話題の番組を見ておきたい、といった場合などに番組の人気度は有効である。
次の番組の性質は、ユーザからみてその番組がどのような特徴を持っているか、を表す。例えば、保守的な番組や急進的な番組、子供には相応しくない番組、といったものがここで言う番組の性質である。これらはユーザにその旨の情報を直接入力してもらうことになる。
【００３４】
番組に対する期待度は、まだ放送されていない番組に対してユーザがどれだけ期待を寄せているかを表すものである。例えば、今夜から放送が開始される新番組は世間からどれだけ注目を浴びているのか、ということが番組の期待度から分かる。これはユーザの番組に対する直接入力以外に、その番組を予約録画したかどうかといった情報からも計算することができる。
【００３５】
番組に対する満足度は、ユーザが番組に対して満足したか、あるいは面白いと思ったかを表すものである。これは、番組に対してユーザが直接入力した、”満足した”または”不満であった”という情報から計算できる。
【００３６】
最後の、番組に対する感情は、番組を視聴してユーザがどのような感情を抱いたかを表すものである。例えば、映画を見ていて感動のシーンであれば”感動した”という情報を入力し、恐怖を感じるシーンであれば”怖い”といった情報を入力する。表情認識技術を使えば、これらをシステムが自動的に取得することも可能である。取得した情報は、感動できる番組を見たいというユーザや、怖いシーンは苦手だから見たくないといったユーザに対して効果的に利用できる。
これらの具体的な利用方法については後述する。
【００３７】
（情報の集計方式）
以上では、ユーザの視聴行動から得られる具体的なインフォーマル情報と、それを集計することで得られるバリューの例を示した。
そこで次に、ユーザの感情といったインフォーマル情報を集計する際に問題となる、情報の集計方式について述べる。
従来から、情報の集計にはクライアント・サーバ方式が多く用いられてきた。それは、簡単に全ユーザの情報を集計できるからである。しかし、今回集計する情報はインフォーマル情報である。インフォーマル情報の、途中で中央管理機構が介在するとインフォーマル度が低下する恐れがあるという特徴は、クライアント・サーバ方式とインフォーマル情報の相性が悪いことを示している。また、クライアント・サーバ方式は正確な情報集計に適している方式であるが、そもそも”いいかげん”なインフォーマル情報を正確に集計する必要はない。
中央管理機構を介在させずに済む方法としてはP2P方式がある。P2P方式はユーザ同士が直接接続するブローカレスモデルである。途中に中央管理機構を介さないため、インフォーマル情報を扱う場合でもそのインフォーマル度の低下を防ぐことができる。また、分散的な性質も持ち合わせており、各ノードに負荷を分散させることができるというメリットもある。さらに、P2Pでは各ノードが連携しながら情報を集計することになるので、ある程度いいかげんな情報集計になることが多い。このことからも、P2Pとインフォーマル情報の相性が良いことがわかる。ただし、P2Pにも一部にクライアント・サーバ方式を取り入れたハイブリッドP2Pモデルが存在し、純粋なP2Pモデル(ピュアP2P)とは区別されている。
【００３８】
このような理由から、本実施の形態ではインフォーマル情報と相性がいいP2P方式(ピュアP2P)を用いて情報の集計を行うことにする。
ここで、従来の推薦手法と本実施の形態で目指す新しい推薦手法の特徴を表１にまとめる。なお、新しい推薦手法は従来の推薦手法を内包するものである。
【００３９】
【表１】
【００４０】
（プライバシーの問題）
ユーザの視聴情報を扱う場合に問題となるのがプライバシーの問題である。一般的にユーザは自分の視聴履歴が誰かの手に渡ることを嫌がる傾向にある。すなわち、自分の視聴履歴が自動的に集計されることに不安を抱いているユーザもいる。
しかし、本実施の形態ではP2P通信でユーザ同士が協力して視聴情報を集計するため、特定の機関に自分の視聴履歴を把握されるということはない。もちろん、個人を特定できるような情報はそもそも送信しない。また、視聴情報を暗号化して集計を行えばセキュリティを高めることもできる。
【００４１】
（情報集計アルゴリズム）
次に、インフォーマル情報の集計に適したアルゴリズムを提案し、その性能を分析する。
【００４２】
（集計可能な情報）
インフォーマル情報の集計アルゴリズムを考案するために、まずはどのようなインフォーマル情報を集計するのか明らかにする。
例えば、各ユーザから取得する情報は例えば以下のようなものになる。
・どの番組を視聴しているか
・子供に見せたくないか
・満足したか(面白かったか)
・どんな感情を抱いたか
これらの情報はすべて数値で入力することができる。例えば、”どの番組を視聴しているか”ならば、視聴している番組には1、視聴していない番組には0を入力し、”子供に見せたくないか”や”満足したかどうか”ならば、番組に対してそれらの度合いを数値で入力する。”感情”についても、どんな感情をどの程度抱いたかを数値で入力すればよい。感情の種類には例えば”喜び”、”怒り”、”悲しみ”、”楽しみ”といったものが考えられる。
【００４３】
このように情報を数値で表すことによって、情報の集計はこれらの値を単純に加算するだけでよいことになる。ここで提案する情報集計アルゴリズムは、このような数値で表されたインフォーマル情報の集計を行うものとする。
なお、番組推薦で利用しやすいように、集計結果は比率として計算することにする。すなわち、番組Aを見ているのは全体の何%か(視聴率)、何%のユーザが番組Aに満足しているか、何%のユーザが番組に対して感動したか、といった情報を得ることを目的とする。そのため、ユーザの人数(サンプル数)も一緒に集計できるようにする。
【００４４】
（要件）
次に、番組推薦システムで求められる情報集計アルゴリズムの機能と性能における要件をまとめる。
まず必要最低限の機能は、上述したように、数値で表されたインフォーマル情報を番組ごとに常時集計できることである。ただし、集計結果である視聴率などは、数秒間隔でその値が分かるようにする。すなわち、番組の平均視聴率だけでなく視聴率の変遷も分かるように集計する。また、リアルタイムに変化する視聴率などの様子も番組推薦に利用できるため、リアルタイム集計も実現する。
【００４５】
次に想定するネットワークの規模であるが、現在日本でTVを所有している世帯数は数千万にも及ぶ。そこで、本実施の形態でも大規模なネットワークを想定しておく必要がある。よって、ここではノード数が数十万〜数百万程度の大規模ネットワークを想定することにする。もちろん、ネットワークの規模が小さくても機能しなくてはならない。また、常時安定して稼動するためにはネットワーク障害にも強くなければならない。
【００４６】
視聴率などの精度もできる限り確保しなければならない。現在の日本でのある世帯視聴率調査では、例えば調査地域によって標本数を200または600に設定している。標本の抽出は国勢調査のデータをもとにランダムサンプリングで行っているが、TV局関係者のいる世帯や病院、事務所などの施設は除外して視聴率の正当性も考慮している。これによって得られる視聴率の誤差は、視聴率が50%のときに±7%または±4%程度(信頼度95%)である。そこで、本実施の形態で考案する情報集計アルゴリズムも、集計結果の誤差を少なくとも±4%以下に抑えられる方式とする。
また、本実施の形態では各ユーザのTVがP2Pネットワークでつながることを考えており、その場合、ユーザからTV局関係者などを除外して情報を集めることは困難である。そのため正確なサンプリングを行うことはあきらめ、代わりに標本数を現行の調査よりも増やすことで集計結果の正当性低下を補う。そこで、考案する情報集計アルゴリズムは、ある程度多数のユーザの情報を集計できるようにする。
【００４７】
以上をまとめると、以下のような機能及び性能が必要となる。
・番組ごとに視聴率のような比率が計算できる
・リアルタイムに集計できる
・ユーザ数が数十万〜数百万の大規模なネットワークでも機能する
・ネットワーク障害に強い
・視聴率などの誤差を±4%以下に抑えられる
・多数のユーザの情報を集計できる
【００４８】
（P2P情報集計アルゴリズム）
次に、以上で明らかにした要求をできる限り満たす情報集計アルゴリズムを提案する。
（単純な情報集計方法）
P2Pで多数のユーザの情報を集計する最も単純で基本的な方法は、1つのノード(ユーザ)が全ての集計を引き受けるという方法である（図６参照）。集計したいデータの数だけノードを選択し、後は選択したノードからデータをもらい集計すればよい。集計結果はブロードキャストすることで、全てのノードが集計結果を得ることができる。
しかし現実にこのような方法は利用できない。集計しているノードの負荷が大きすぎ、さらにそのノードが故障したらその時点で集計は失敗する。
そこで以下に、安定性や負荷の分散も考慮し、全てのノードが集計を行い且つお互いに協力する方法を提供する。
【００４９】
（P2P情報集計アルゴリズムの概要）
提案する情報集計アルゴリズムの仕組みを図７に簡単に示す。ノード間の矢印は情報の流れを表している。
【００５０】
基本的な考え方は次の通りである。各ユーザは定期的に自分の周りのノードから情報を集めてそれを集計している。すると、自分の周りのノードは、さらにその周りのノードから情報を集めて集計していることになる。そこで、自分の周りのノードからそれらの集計結果も一緒に取得する。例えば、図７ではノード1はノード2〜7から情報を集めている。同様にノード6はノード11〜12の情報を、ノード7はノード8〜10の情報を集めている。よってノード1は、ノード2〜7の情報に加えて、ノード6とノード7が集めたノード8〜12の情報(の集計結果)も同時に得ることができる。さらに言えば、ノード8がノード13〜16の情報を集めているので、ノード13〜16の情報(の集計結果)も同時に集めることができる。このとき、ノード1から見て自分自身の情報を0次情報、ノード2〜7の情報を1次情報、ノード8〜12の情報を2次情報、ノード13〜16の情報を3次情報と呼ぶことにする。もちろん、それ以上の4次情報、5次情報といったものもあり得る。なお、ここで言っているノードの情報とは、上述したような、各ユーザのインフォーマル情報を数値で表したもののことである。
【００５１】
この方法によって、ネットワーク上の膨大な量の情報を効率的に集計することができる。ただし、他のノードからもらう集計結果がその時点ですでに集計されているデータであるため、集めたデータには時間的なずれが生じている。よって、1次情報よりも2次情報の方が古く、2次情報よりも3次情報の方が古い情報となってしまい、言い換えると、遠くのノードから集めた情報ほど古い情報になっている。
【００５２】
また、集めたデータに重複が生じることも考えられる。例えばノード6がノード8の情報も集めていたと仮定する。するとノード1は、ノード6が集めたノード8の情報と、ノード7が集めたノード8の情報を重複して受け取ることになる。この問題については後に述べる。
【００５３】
（送信リンクと受信リンク）
各ノードは、他のノードと送信リンク及び受信リンクを張ることができる(図７におけるノード間の矢印がそれに当たる)。送信リンクとは、あるノードが他のノードにデータを送信するときの伝送路である。受信リンクは、逆に他のノードからデータをもらうときに使用する伝送路のことである。よって、例えばノードAがノードBとの間に張った受信リンクは、ノードBにとってはノードAに対する送信リンクである。
【００５４】
各ノードは、送信リンク及び受信リンクをあらかじめ決められた数だけ他のノードとの間に張ることができる。ただし自分から他の1つのノードに対して張れるリンクは1本のみとし、さらに、自分から他のノードに張ることができるのは受信リンクのみとする。送信リンクについては、他のノードが自分に対して受信リンクを張ることによって持つことができる。よって、他のノードが自分に対して受信リンクを張ろうとしなければ、全く送信リンクを持たないこともある。なお、どのノードと受信リンクを張るかは完全にランダムとする。また、すでに決められた数だけ送信リンクが張られているノードに対しては、受信リンクを張ることはできないとする。
各ノードは、定期的に自分が持っているデータを送信リンク先の全てのノードに送信する。逆に受信リンク先のノードにデータを要求することはせず、他のノードから受信リンクを通してデータが送られてくるのを待ち続けるのみとする。ただし、一定時間待ってもデータが送られてこない受信リンクは切断し、他のノードとの間に新たに受信リンクを張りなおす。
【００５５】
（データの集計）
周りのノードから集めたデータの集計計算の様子を図８に示す。
図８では、4つの領域に分かれた長方形は各ノードが持つデータを表し、それぞれの領域に0次情報〜3次情報が格納されている。集計計算は、集めたデータのn次情報同士を集計して集計結果のn+1次情報の領域へ格納することによって行う。集計結果の0次情報には最新の自分の情報を格納しておく。他のノードにデータを送信するときは、この集計結果のデータを送ることになる。もちろん、最初にネットワークに参加した時点では、まだ他のノードからデータを集めていないので、データを送信する際は0次情報(自分の情報)のみが格納されたデータを送信することになる。
なお、本実施の形態では0次情報〜n次情報を持つデータのことを”次数n+1のデータ”と呼ぶことにする。
【００５６】
（データの遅延）
データの集計方法から明らかなように、集計したデータにはデータの遅延が生じている。基本的には、n次情報よりもn+1次情報の方が古いデータになっている。例えば、各ノードが1分ごとにデータを送信しているとすると、集計結果の0次情報には現在の情報(自分の情報)、1次情報には1分前の情報、2次情報には2分前の情報、3次情報には3分前の情報が含まれていることになる。すなわち、データの送信間隔をt [sec]とすれば、d次情報が得られるのはt×d [sec]後となる。
データ量はn次情報よりもn+1次情報の方が大きくなっているので、より多くのデータを使って精度の良い結果を得るには、より古いデータを使うことになる。よって提案した情報集計アルゴリズムでは、完全にリアルタイムな集計はできない。しかし、各ノードのデータ送信間隔を短くすれば、よりリアルタイム集計に近づけることは可能である。ただし、送信間隔が短くなればその分ネットワークトラフィックも増加することに注意する必要がある。
【００５７】
（精度）
次に、提案した情報集計アルゴリズムを利用した場合に得られる結果の精度について考察する。
（収集データ量）
集計結果である視聴率などの精度は、収集したデータ量で決まる。より多くのデータを用いて計算すれば、その分誤差も小さくなる。よって、まず最初に提案したアルゴリズムで収集できるデータの量を見積もることにする。
収集できるデータ量はリンク数と次数で決定される。各ノードの送信リンク数及び受信リンク数を共にL、データの次数をdとすれば、集計結果の1次情報としてLノード分のデータが、集計結果の2次情報としてL2ノード分のデータが、集計結果のd次情報としてLdノード分のデータが収集できることになる。すなわち、収集できる全データ量は式(5・1)のようになる。
【００５８】
【数１】
【００５９】
例えば、L=4、d=3とすれば、集計結果の3次情報として、4096ノード分の情報の集計結果を得られることになる。ただしこれは、全てのノードが受信リンクを4つ張っている状態での結果である。実際には、各ノードの受信リンク数および送信リンク数の最大値を共に4としてしまうと、受信リンクを全て張れないノードも出現する可能性がある。各ノードが受信リンクを張れば張るほど送信リンクに余裕のあるノードが減少するからである。よって、各ノードの送信リンク数の最大値を受信リンク数の最大値よりも大きな値に設定するなどの対策が必要である。
【００６０】
次に、視聴率の精度は収集データの量によってどの程度変化するか調査する。視聴率のような標本比率の誤差(信頼度95%)は式(5・2)から得られることが知られている。
【００６１】
【数２】
【００６２】
式(5・2)を用いると、標本比率の誤差は表２のようになる。
【００６３】
【表２】
【００６４】
現行の視聴率調査では標本数は600程度であるが、この表からそのときの視聴率の誤差は比較的大きいことが分かる。一方、標本数が4096であれば視聴率の誤差は現行の誤差の半分以下となることが分かる。
提案した情報集計アルゴリズムでは、パラメータdを大きくすれば収集できるデータの量も急激に増加するので、視聴率の誤差は十分小さく抑えることが可能である。
【００６５】
（重複データ）
上記したように、この情報集計アルゴリズムではデータを重複して集計してしまう可能性がある。特に、ネットワークの規模が小さいとデータの重複も生じやすい。しかし、データが重複するからといって必ずしも集計結果がでたらめな値になるわけではない。例えばノードの総数を集計する場合はおかしな集計結果になってしまい、この情報集計アルゴリズムは役に立たないが、本実施の形態で求めたいデータは「何人中何人が番組を見ているか」や「何人中何人が番組に満足したか」といった”比率”のデータである。その場合、ランダムなネットワークを構築することで、提案した情報集計アルゴリズムでも正しい結果が得られると考えられる。これは、各ノードのデータが同程度に重複して集計されても、視聴率などの比率はほとんど変わらないためである。例えば100人中10人が番組を視聴している場合(視聴率10%)、重複して1000人分のデータを集めたとしても、結局そのうちの約100人が視聴していることになって視聴率はほぼ同じ10%となる。
【００６６】
しかし、それでも多少は本来の視聴率よりも誤差が大きくなってしまうことは避けられない。そこで、式(5・2)にデータの重複率を導入して、データに重複がある場合の誤差を導く。
まず、重複を含めてS人分のデータを収集し、そのうちs人が番組を視聴していたと仮定する。次に、データSの内、重複して収集したデータをM、その残りをNと仮定する。さらに、N人の内のn人と、M人の内のm人が番組を視聴していたとすると、視聴率は式(5・3)のように表せる。
【００６７】
【数３】
【００６８】
ここで、Rは重複データがない場合の視聴率、R’は重複データの視聴率、αは収集データの重複率である。以下、本論文ではデータの重複率をα＝M/N として説明する。重複率＝M/(N+M)でないことに注意する。
【００６９】
よって視聴率の誤差Eは、式(5 2)及び式(5 3)から
【数４】
と導くことができる。この式(5・4)を用いて具体的に誤差を計算すると表３のようになる。なお、図９はN=4096において式(5・4)をグラフ化したものである。重複率が0.1前後のときに最も誤差が大きくなっていることが分かる。
【００７０】
【表３】
【００７１】
表３を見ると、データに重複があっても誤差はほとんど増えないことがわかる。よって、提案した情報集計アルゴリズムにおいて、データの重複率はさほど問題ではないことが分かる。
【００７２】
（トラフィック）
本システムは大規模なP2Pネットワーク上で動作させることを前提としている。そのため、情報を集計する際にネットワークを流れるメッセージ数がどの程度になるか、事前に見積もることが重要になる。
提案した情報集計アルゴリズムの場合、受信リンクの数をL、やり取りするデータのサイズをm [bit]、時間T [sec]後にd次情報を得られるとすると、各ノードのネットワークトラフィックは(5・5)式のようになる。
【００７３】
【数５】
【００７４】
次に、このトラフィックを小さく抑えられるようなLとdの値を求める。
まず式(5・4)から、視聴率の誤差は視聴率が50%のときに最も大きくなることが分かる。ここで、そのときの誤差を1%以下程度に抑えることを考える。現行の視聴率調査での誤差が約4%であるので、誤差が1%以下ならば十分な精度と言える。そこで、式(5・4)から重複率が0.1で視聴率(50%)の誤差が1%になるサンプル数Nを求めてみると約14000になる。よって、重複データも考慮して約15000人分のデータを集められれば、誤差を1%以下に抑えられることになる。ただし、実際のネットワークでは、ノードの離脱などによって収集できるデータ量は理論値よりも小さくなるので、そのことも考慮して最大約30000人のデータを集められるようなパラメータを設定しておけば十分だと考えられる。
表４はd次情報として30000以上のデータを集められるような受信リンク数Lと次数dの組を示したものである。
【００７５】
【表４】
【００７６】
表４から、トラフィックが最も小さくなる受信リンク数Lの値は2または３である。しかし、受信リンク数Lが小さすぎると、受信リンクを1本張れないだけで収集データ量が急激に減少してしまう恐れがある。そこでそのようなリスクを分散させることができ、かつトラフィックも小さい、受信リンク数L=4、次数d=8の組を本情報集計アルゴリズムでは採用する。その場合、もし時間T=60 [sec]ならば、トラフィックは0.53m [bps]ということになる。
【００７７】
（耐障害性）
本実施の形態に係る情報集計アルゴリズムは、基本的には常時ネットワークに繋がっているシステムを想定している。そのため、頻繁にネットワークから離脱したりするノードはそれほど多くないが、大規模なネットワークで常に安定して動作するためには、耐障害性に優れていることが求められる。
本実施の形態に係るアルゴリズムは、ピュアP2Pネットワークで動作する。そのため、ネットワーク障害には比較的強いものになっている。例えば、突然受信リンク先のノードがネットワークから離脱したとする。その場合、単に代わりのノードを探して受信リンクを張りなおせばよい。各ノードの送信リンク数の最大値を大きく設定すれば、受け付けられる受信リンクの数にも余裕ができて、代わりのノードは見つかりやすくなるはずである。仮に、代わりのノードを見つけるまでに時間がかかってしまった場合でも、集計したデータには古いデータも含まれているので(どれだけ古いかはデータの次数による)、現在得られた集計結果からある程度昔のデータを補間することも可能である。
【００７８】
（P2P番組推薦システム）
次に、ジャンルとバリューを利用した番組推薦システムの実現方法について述べる。なお、推薦対象の番組は、放送中の番組、過去の番組、未放送の番組とする。
【００７９】
（ジャンルによる番組推薦）
本実施の形態では、ジャンルを利用した番組推薦に従来の推薦手法であるコンテンツベース推薦を用いる。コンテンツベース推薦は、ユーザの視聴履歴からユーザの嗜好を抽出して、その嗜好にあった番組を推薦するというものである。
【００８０】
（ユーザの嗜好）
各ユーザは番組視聴に関して自分の嗜好を持っている。例えば、スポーツ番組を好んで視聴するユーザもいれば、ドキュメンタリー番組を好んで視聴するユーザもいる。コンテンツベース推薦では、このようなユーザの嗜好を利用して番組推薦をする。
本システムでは、ユーザの嗜好をワードリストで表現する(表５)。ワードリストは単語とその出現頻度の組から成り、これは番組のEPGを利用して作成する。具体的には、リモコンに”Goodボタン”と”No-Goodボタン”を用意し、Good/No-Goodボタンが押された番組のEPG情報のワード列を単語に分解して抜き出し、ワードリストに登録する。ワードリストは各単語の出現頻度の情報も持っており、GoodボタンによってEPGから抽出された単語は出現頻度を1増やし、No-Goodボタンによって抽出された単語は出現頻度を1減らす。このようにして作られるワードリストはユーザの嗜好そのものとなる。なお、Goodボタンはバリューの満足度の入力としても利用する。
【００８１】
【表５】
【００８２】
ユーザの好きなジャンルの番組を推測するために、ユーザのワードリストと番組のEPG情報のワード列(をワードリストに変換したもの)との類似度を計算する。この類似度計算は、まず各単語間で類似度を計算し、その次にワードリスト間で類似度を計算するという2段階の手続きを踏む。
単語間の類似度の計算には、例えば株式会社日本電子化辞書研究所のEDR電子化辞書の概念辞書と英語単語辞書を利用する。概念辞書には概念の上下関係がツリー構造で記述されている。英語単語辞書には、英単語と概念の対応関係が記述されている。
単語間の類似度計算は、まず英語単語辞書で2つの単語の概念を引き、次に概念辞書のツリーにおけるそれら概念間の距離を計算する。この距離をNp、ツリーの高さをDとするとき、次の式(6・1)で単語間の類似度を計算できることが知られている。
【００８３】
【数６】
【００８４】
次にワードリスト間の類似度の計算のために、まず長い方のワードリスト内の単語から、短い方のワードリスト内の各単語と類似度の高いものを抽出して、新たなワードリストを作成する。この新しいワードリストは短い方のワードリストと同じ長さである。そして、新しいワードリスト(各単語の出現回数の値と類似度をかけた値)と短い方のワードリスト(各単語の出現回数の値)をベクトルとしてその内積を計算し、そのなす角を求める。この角度が小さければ、その番組はユーザの嗜好に合っていることになる。
【００８５】
（バリューによる番組推薦）
次に、番組推薦に利用するバリューについて詳細な説明を行う。
（バリューの種類）
以下のバリューが番組推薦に利用できる。
・番組の人気度(視聴率)
・番組の性質
・番組に対する期待度
・番組に対する満足度
・番組に対する感情
【００８６】
このうち、人気度、期待度、満足度は1つの値として算出できるが、性質と感情は、複数の値を持ち得る。そこで、本論文では性質と感情の種類を以下のように定義する。
「性質」
・子供に見せたくない
「感情」
・嬉しい
・楽しい
・悲しい
・苛立ち
・恐怖
性質と感情については、これら1つ1つに対してその度合いを算出する。なお、人気度は番組視聴人数をサンプル数で割ることで算出し、それ以外の期待度、満足度、性質、感情は、集計した値を番組視聴人数で割ることで算出する。すなわち、番組を視聴していたユーザのうち何%が満足したかといった値が得られる。
【００８７】
（情報の入力）
バリューを求めるためには、通常の視聴履歴から得られる情報のほかに、各ユーザが番組に対してどの程度満足したか、番組に対してどんな感情を抱いたかといった情報を集計する必要がある。
このような情報の取得方法には、キーボードによるテキスト入力、あるいは笑い声などの音声や表情から感情を取得するといった方法が考えられる。しかし、表情認識は今の段階では技術的に難しく、音声入力はTVの音声とかぶってしまう。また、キーボードは誰もが使いこなせるわけではなく、そもそも受動的なメディアであるTVに対して積極性が求められるキーボードは向いていない。TVに向いている入力手段は、リモコンのようにだれでも気軽に入力できるものである。例えば、”Goodボタン”があれば番組に対する満足度を簡単に入力でき、”嬉しいボタン”や”悲しいボタン”をリモコンに用意すれば、番組に対する満足度や感情を簡単に入力することができる。どのボタンが何回押されたかという情報から、簡単にユーザのインフォーマル情報を数値化することもできる。よって、本実施の形態では情報の入力手段としてリモコンを想定する。情報入力の対象は、番組全体あるいは番組の一部分(ピンポイント)が考えられるが、本実施の形態では”この番組のこの瞬間”という風にピンポイントに情報を入力することにする。
ところで、近年TVの高機能が進み、リモコンのボタンも非常に複雑になってきている。通常のリモコンのほかに、必要最低限のボタンのみのリモコンを用意するケースもある。よって単純にボタンを増やすことは望ましくない。
【００８８】
（ユーザのプロフィール）
多数のユーザが番組を評価することによって得られるバリューは、全ユーザの総意を知るのに良い指標となるが、さらにユーザのプロフィールも同時に考慮するとより効果的な推薦が可能になる。例えば男性ユーザに関して、好みの異なる女性ユーザのデータを除外したほうが有効な結果を得られることがあるだろう。あるいは、同世代のユーザに人気のある番組を知りたいといった場合や、地元のユーザに人気のある番組を知りたいといった場合も、ユーザのプロフィールを利用することで知ることができる。
番組推薦に効果的に利用できるユーザプロフィールは以下のようなものである。
・年齢
・性別
・地域
情報集計では、10代の人気度・満足度・感情、20代の人気度・満足度・感情、・・・のように、プロフィールごとに情報を集計すればよい。ただし、集計データのサイズはプロフィールの長さ(次元数)がnならばn倍となる。
ここに挙げたプロフィール以外にも多数のプロフィールが考えられるが、これはユーザのプライバシーに深く関わる問題であり、特に個人を特定できるような情報は避けなければならない。
【００８９】
（データレベルのクラスタリング）
上記では、年齢別、性別、地域別のバリューにも利用価値があることを述べた。ここではそれらに加え、ユーザの嗜好別バリューを算出する方法を説明する。
バリューによる番組推薦において、自分と嗜好が似ているユーザの情報を利用することは非常に有効である。なぜなら、ユーザにとって自分と嗜好が似ているユーザによる番組評価は、多様な嗜好のユーザによる番組評価よりも自分と似ており信頼できるからである。以下ではそのような情報の集計方法を検討する。
【００９０】
従来のP2Pファイル共有ソフトでは、ファイル共有の効率を高めるために、ネットワークレベルで嗜好のクラスタリングを行っているものがある。すなわち、嗜好の似た者同士をネットワーク的に近い位置に配置している。このようなクラスタリングを行えば、嗜好が似ているユーザから情報を集めることが可能である。
しかし、提案した情報集計アルゴリズムでは、このようなクラスタリングを行っても意味がない。なぜなら、この情報集計アルゴリズムはランダムなネットワークを前提としているからである。クラスタリングをしてもネットワークに偏りが生じてしまえば正しい集計結果は得られない。そこで本実施の形態では”共通ジャンルリスト”を導入する。共通ジャンルリストとは、あらかじめ決められた全ユーザに共通の嗜好ワードとその値の列である(表６参照)。例えば、”SF”や”サッカー”といった単語を共通ジャンルとして設定する。
【００９１】
【表６】
【００９２】
各ユーザは共通ジャンルリストを以下のように作成する。
まず各ユーザは、自分の嗜好ワードリストから共通ジャンルに対する嗜好の度合いを0〜1の値に変換し、共通ジャンルリストの値として設定する。これを一時共通ジャンルリストと呼ぶことにする。次に、その値が大きいものは1、それ以外は0とする共通ジャンルリストを作成する(図１０参照)。すなわち、各ユーザは自分の好きな共通ジャンルの値を1に設定する。値を0か1に変換するのは、ユーザの共通ジャンルに対する嗜好をよりはっきりと区別させるためである。
【００９３】
情報の集計はこの共通ジャンルリストの値を加算していくことで行う(図１１参照)。集計の方法はユーザプロフィールを利用する場合と同様である。各バリューの集計を、さらに共通ジャンルごとの集計に細かく分けて行う。例えば共通ジャンル1に関する視聴率、共通ジャンル2に関する視聴率、共通ジャンル1に関する満足度、・・・のように集計を行う。
【００９４】
こうして得られた集計結果からは、番組Aを視聴しているユーザのうち、共通ジャンル1が好きなユーザは何人、共通ジャンル2が好きなユーザは何人、・・・といった情報を得ることができる。これはすなわち専門家によるバリューが得られるということでもある。例えば、ある映画についてSF映画好きなユーザはこの映画をどのように評価しているか、ということが分かる。
さらにこの集計結果を用いて、各ユーザの嗜好に即したバリューを得ることもできる。それには、ユーザの一時共通ジャンルリストを利用する。一時共通ジャンルリストはユーザの共通ジャンルに対する嗜好を表しているので、共通ジャンルリストの集計結果と一時共通ジャンルリストの内積をとることで、ユーザの嗜好を考慮したバリューが得られる。すなわち、自分と嗜好が似ているユーザの情報から算出するバリューを、このような方法で近似できる。
共通ジャンルリストの長さ(次元数)を増やせば、より精度の高いバリューが得られることになるが、その場合は集計データのサイズも増加することに注意する必要がある。共通ジャンルリストの次元数をmとすればデータサイズは元のデータ(ユーザプロフィールを除く)のm倍、ユーザプロフィールの次元数nも考慮すれば、データサイズはn+m倍になる。
【００９５】
（集計データ）
以下のデータは、情報集計の際にやり取りする、放送中番組に関する集計データの一部である。ユーザプロフィール、共通ジャンルは考慮していない。各ユーザは自分の視聴履歴を15秒おきに記録するものとする。よって1分間に4つのデータが作られる。また、データ送信間隔を60秒、次数を3とすれば、3分前までのデータを集計することになるので、合計12個のデータを持つ。
【００９６】
＜番組ID＞ ABC
＜サンプル数＞ 1,2,3,4,5,6,7,8,9,10,11,12
＜視聴人数＞ 1,2,3,4,5,6,7,8,9,10,11,12
＜満足度＞ 1,2,3,4,5,6,7,8,9,10,11,12
＜期待度＞ 1,2,3,4,5,6,7,8,9,10,11,12
＜嬉しい＞ 1,2,3,4,5,6,7,8,9,10,11,12
＜楽しい＞ 1,2,3,4,5,6,7,8,9,10,11,12
＜悲しい＞ 1,2,3,4,5,6,7,8,9,10,11,12
＜苛立ち＞ 1,2,3,4,5,6,7,8,9,10,11,12
＜恐怖＞ 1,2,3,4,5,6,7,8,9,10,11,12
＜子供に見せたくない＞ 1,2,3,4,5,6,7,8,9,10,11,12
【００９７】
12個の数字のデータが集計中のデータである(ここで示した数字に意味はない)。一番左のデータが3分前、一番右のデータが現在のデータである。次数を3としているので、3分以上前のデータは切り捨てている。集計データには、このようなデータが放送中の番組の数だけ含まれることになる。
受信リンク数を4に設定すれば、60秒間にこのような集計データを4つ受け取る。受け取った集計データは、同じ番組同士でデータを加算することによって集計を行う。この集計結果から番組の人気度、満足度、感情、性質の値を算出することになる。
放送中の番組ではなく録画番組に関するデータの場合は、3分間のデータではなく、番組の開始から終了までのデータを集計する必要がある。なぜなら、録画番組はバラバラに視聴されるからである。録画番組Aを30分前から視聴しているユーザもいれば、録画番組Aを視聴し始めたばかりのユーザもいるかもしれない。その場合、3分間のデータだけ集計しても意味がない。
なお、録画番組に関しては、その番組が放送中のときに視聴データをすでに集計しているはずである。よって、録画番組として集計して得たデータは、すでに持っている放送中に集計された集計結果に足し合わせていくことになる。これによって、例えば放送中のときは満足度が低かったが、数ヶ月経ってみたら満足度がとても高くなっていた、ということも起こり得る。
一方未放送の番組に関しては、そもそも期待度しか計算できないので、集計するデータは<サンプル数>と<期待度>のデータのみになる。
上に示したデータにユーザプロフィールと共通ジャンルを導入すると集計データは以下のようになる。
【００９８】
＜番組ID＞ ABC
＜サンプル数＞ 1,2,3,4,5,6,7,8,9,10,11,12
＜視聴人数＞ 1,2,3,4,5,6,7,8,9,10,11,12
＜男性＞ 1,2,3,4,5,6,7,8,9,10,11,12
＜女性＞ 1,2,3,4,5,6,7,8,9,10,11,12
＜１０代＞ 1,2,3,4,5,6,7,8,9,10,11,12
＜２０代＞ 1,2,3,4,5,6,7,8,9,10,11,12
＜共通ジャンル1：SF＞ 1,2,3,4,5,6,7,8,9,10,11,12
＜共通ジャンル2：サッカー＞ 1,2,3,4,5,6,7,8,9,10,11,12
：
＜満足度＞ 1,2,3,4,5,6,7,8,9,10,11,12
＜男性＞ 1,2,3,4,5,6,7,8,9,10,11,12
＜女性＞ 1,2,3,4,5,6,7,8,9,10,11,12
：
【００９９】
導入するプロフィール、共通ジャンルの数は、データのサイズ(トラフィック)がどれだけ増えるかを考慮して決める必要がある。録画番組のデータを集計する場合は、番組数が決まっている放送中の番組と違って番組数が無数になるため、特にデータのサイズに注意する必要がある。
そもそも無数に存在する録画番組をすべて集計することは不可能である。例えば、1万人分のデータを集めた場合、最悪1万個の録画番組データを集計することになる。このような場合は、データ集計中に番組数が一定の数に達したら番組データを切り詰める、という処理を行う。ユーザにとって必要な番組のデータは残し、必要でない番組のデータは捨ててしまうようにする。ユーザにとって必要な番組とは、何らかの理由でその番組が放送中のときに十分な視聴データを集められなかったものである。逆に必要でない番組は、すでに十分な視聴データを集められている番組である。
録画番組の集計データは、たとえ番組数を切り詰めても放送中番組の集計データに比べるとかなり大きくなってしまう。しかし放送中番組と違って、録画番組にはリアルタイム性は必要ない。よって、放送中番組と録画番組で同じデータ送信間隔を設定する必要はなく、放送中番組のデータ送信間隔は短く設定し、録画番組のデータ送信間隔は長く設定することで、トラフィックが抑えられ効率的な情報集計が可能になる。
【０１００】
（画面インタフェース）
次に、実際のTV視聴シーンにおける番組推薦インタフェースについて説明する。
（ブラウジング）
ブラウジングとはユーザが情報の一覧を眺めながら欲しい情報を取り出すというものである。ブラウジングを効率的に行うには、情報の視覚化が有効である。
本システムでは、各番組ごとにその番組のジャンルとバリューをグラフで表示することで、ユーザはどの番組が自分の好みと合っていて、どの番組がどんなユーザから高い評価を得ているかということが一目で分かるようにする。その結果ユーザは簡単に見たい番組を探せるようになる。このようなブラウジング主体の表示は、本システムでは主に3つのシーンに分かれる。1つ目は番組視聴中の表示、2つ目は録画番組一覧での表示、3つ目は番組表閲覧時の表示である。
【０１０１】
1つ目の番組視聴中の表示例を図１２に示す。また、現在試作中のプロトタイプシステムの画面を図１３に示す。番組放送画面では図１２のように、画面の右隅に視聴中の番組および他チャンネルの番組のジャンルとその瞬間のバリュー(ここでは人気度)を表示する。ユーザは現在の番組を視聴しながら、他チャンネルの番組のバリューが刻々と変化する様子を確認できる。さらに画面下には視聴中番組の人気度(視聴率)の変遷やその他のバリュー(満足度や感情など)を表示する。他のユーザが満足ボタンや感情ボタンなどを押せばその結果がほぼリアルタイムに画面下のグラフに反映され、他のユーザが今の番組に対してどのように思っているのかが確認できる。特にスポーツ番組などは、盛り上がったシーンでボタン入力することで他のユーザと一体感を感じることができる。また、もし今の番組に満足できないようであれば、他チャンネルのジャンルとバリューを確認して、自分の好みの番組でかつ他のユーザからの評価も高い番組を見つければよい。
【０１０２】
2つ目の録画番組一覧での表示と3つ目の番組表閲覧時の表示は、番組視聴中に表示した情報を各番組に対して表示するだけである。すなわち、一覧の各番組の横にその番組のジャンルとバリューの棒グラフを表示し、一目で各番組のジャンルとバリューの値が分かるようにする。さらにどれかの番組を選択した場合には、その番組のバリューの変遷を画面下に表示することによって、ユーザはどの番組のどのシーンが面白いのかを簡単に見つけることができる。これによってユーザは本当に面白いシーンだけを”つまみ食い”することが可能になる。
【０１０３】
（番組推薦インタフェース）
ブラウジングは番組一覧の中から見たい番組を探すというものであった。しかし、ユーザに”こんな番組が見たい”という曖昧な要求がある場合は、それに即した番組推薦を行うべきである。そこで本実施の形態では図１４のような番組推薦インタフェースを提案する。
【０１０４】
ユーザは周囲に配置されたそれぞれのチェックボックスをチェックすることで、どんな番組を推薦して欲しいか指定する。図１４の例では、20代の男性の中で人気度、満足度、好み(ジャンル)、感情(楽しい)の度合いが高い番組を推薦してもらおうとしている。推薦結果の番組は中央にその評価の高い順に表示される。このようにしてユーザは単純なブラウジングよりも効率的に自分の見たい番組を見つけることができる。また、ここで設定した条件をブラウジングの画面表示に適用することも有効である。例えば、番組視聴中 (図１２)、録画番組一覧、番組表閲覧時におけるバリューとして、”20代の男性の中での人気度、満足度、感情(楽しい)の総合値”を表示すると、ブラウジング中でもユーザは効率的に自分の見たい番組を見つけることが出来るようになる。
【０１０５】
（シミュレーション実験）
次に、以上に提案した情報集計アルゴリズムのシミュレーション実験を行い、その性能について評価する。
【０１０６】
（実験の目的）
提案した情報集計アルゴリズムの評価をするために何十万人ものユーザで実験することは不可能である。そこで本実験では、シミュレーションによってトラフィックや各ノードにおける集計結果取得の様子および集計結果の精度などを調べることで情報集計アルゴリズムの評価を行う。そのために作成したシミュレータの概要を以下に示す。
・多数の仮想ノード間で提案した情報集計アルゴリズムと同等の処理を行う
・その際、各ノードは接続相手(受信リンク先ノード)を全ノードの中からランダムに選択する
・最大リンク数、次数、データ送信間隔は全ノードで共通である
・データの送信は全ノードが同期して一斉に行う
・データ送信間隔をシミュレーションの1ステップとする
・1ステップごとに決められた接続試行回数だけ他のノードに接続を試みる
・1ステップごとにノードの離脱率および参加率を設定できる
・1ステップごとにユーザの視聴行動を操作できる
(例えば番組Aを100人が視聴し、番組Bを200人が視聴している、という風に設定する)
・各ノードにおいて、1ステップごとに集計したデータから番組の各種バリューを算出することができる
このシミュレータは、情報集計の際のネットワークの分析と、各ノードにおけるバリューの算出可能性を確認できるように設計した。
【０１０７】
（接続リンク数）
上記したように、最大受信リンク数は4に設定した方が良いことが分かったが、最大送信リンク数は未定であった。最大受信リンク数と最大送信リンク数を共に4と設定すれば、理論的には全てのノードが受信リンクおよび送信リンクを4つずつ張れることになる。しかし実際には送信リンクに余裕があるノードをなかなか見つけられないノードが出てきてしまい、そういったノードは4つ全ての受信リンクを張ることは難しい。そうなると、それらのノードでは収集データ量が減少し、視聴率の精度の低下を招く。
この問題は、最大送信リンク数を最大受信リンク数よりも大きな値に設定することで解決できる。しかし逆に最大送信リンク数が大きすぎると、多数の送信リンクを保持するノードとほとんど送信リンクを保持しないノードが出てきて、ネットワークに偏りが生じる。このような偏りがあると、特定のノードのデータばかり多く重複して集計するといった事態が起きてしまう。これも視聴率の精度を低下させる要因である。よって、最大送信リンク数は最大受信リンク数よりも大きく、且つ出来るだけ小さい値が良いと考えられる。
以上のことを踏まえ、各ノードの受信リンク数が最大送信リンク数によってどのように変化するかを実験によって確かめた。図１５〜図１９は、ノード数を100000、各ノードの最大受信リンク数を4、他のノードへの接続試行回数を12(すなわち1ステップごとに12個のノードへ受信リンクを張ることを試みる)、としたときの各ノードの受信リンク数を調べたものである。値はシミュレーションを10ステップ行ったときの平均値として算出している。なお、1ステップごとに約1%のノードがネットワークから離脱およびネットワークへ参加する設定とした。
【０１０８】
図１５〜図１９のグラフを見ると、最大送信リンク数を最大受信リンク数よりも1増やすだけで、受信リンクを4つ保持しているノードは急激に増加し、逆に受信リンクが3つ以下のノードは急激に減少していることが分かる。また、最大送信リンク数を6以上に設定してもそれほど大きな変化は見られなかった。この事から、最大送信リンク数は最大受信リンク数よりも1だけ多い5と設定するのが良いと考えられる。あるいは、通常は最大送信リンク数＝最大受信リンク数としておき、各ノードの接続失敗回数に応じて動的に最大送信リンク数を変化させることも考えられる。これは例えば、接続試行回数12回の中で10回他のノードに接続を試みても受信リンクが1しか張れなかったノードに対しては、通常最大送信リンク数4のところを5に増やして特別に接続を許可する、というものである。
【０１０９】
（データ収集量）
次に、ノードのネットワークからの離脱やネットワークへの参加を考慮したときの各ノードの収集データ量を調べる。
図２０は、ノード数を100000、最大受信リンク数を4、最大送信リンク数を5、次数を8、他のノードへの接続試行回数を12としたときのシミュレーション結果である。縦軸が収集データ量、横軸がノード離脱率およびノード参加率を表している。ノード離脱率および参加率は、全ノードのうち何%のノードがネットワークから離脱または参加するかを表したものである。ここではシミュレーションを1ステップ進める度にノードの離脱および参加が起こるものとした。なお、ノード離脱率とノード参加率は同じ値に設定した。
図２０は、シミュレーションを10ステップ実行したときの、任意のノードの第8次データ量の平均を示している。このときの理想の収集データ量は48 ＝65536であるが、ノード離脱率1%で60000以上、ノード離脱率5%でも収集データ量が40000以上と、相当数のデータを収集できていることが分かる。
【０１１０】
（ネットワークトラフィック）
図２１に示したグラフは、上記と同じ条件でシミュレーションを行ったときの、1ステップ当たりの各ノードの平均データ送信回数である。
最大受信リンク数を4としているので各ノードは平均して4つの送信リンクを持つことになり、理論的には、各ノードは1ステップ当たり4回データを送信することになる。離脱率変えた場合の結果が図２１であるが、離脱率が増えてもデータ送信回数はそれほど減少していないため、安定してデータ集計が行われているということでもある。
シミュレーションの1ステップをs [sec]とし、データのサイズをm [bit]とすれば、各ノードに要求される通信帯域幅は約4m/s [bps]と見積もることができる。例えば、s=10 [sec]、m=100K [byte]ならば、通信量は320K [bps]となる。よって、データサイズが大きいとネットワーク回線を圧迫してしまう恐れがあるため、データを圧縮したり、必要な情報のみ集計するような工夫が必要である。
【０１１１】
（データ重複率）
続いて、ノード数によってデータの重複率がどのように変化するか調べる。
シミュレーションは、受信リンク数4、送信リンク数5、次数8、接続試行回数12、ノード離脱率(=ノード参加率)1%という条件で行う。重複率は第8次データに関する重複率を調べるものとする。集計結果の第8次データは8ホップ先のノードの情報を集めたものである。よって、特定のノードから受信リンクを辿って8ホップ先のノードがどれだけ重複しているかを調べれば、その特定ノードの第8次データのだいたいの重複率を見積もることができる。もしノードの離脱、参加がなくネットワークのリンク構造が変化しなければ、求めた重複率は正確なデータ重複率となる。図２２はノード数を変化させてシミュレーションを行ったときの重複率である。
【０１１２】
この結果から、ノード数がn倍になるとデータ重複率は約1/n倍になっていることが分かる。よって、大規模なネットワークでは重複率はほとんど無視できることが分かった。本実施の形態では、集計結果としてデータ重複の影響をほとんど受けない比率のデータを求めていたが、大規模なネットワークではデータ重複がほとんど生じないことが確認できたため、そのようなネットワークでは比率以外のデータも取得できる可能性がある。
【０１１３】
（精度）
ここでは集計で得られた視聴率の精度を調べる。
まずは、各ノードで得られる視聴率の精度が、時間の経過によってどのように変化するかを確かめる。シミュレーションの条件は7.5節と同じである。ただしノード数は10万とし、ユーザの視聴状況も以下のように設定した。カッコ内の数値はその番組の真の視聴率である。
・番組A：5000人（視聴率5%）
・番組B：10000人（視聴率10%）
・番組C：20000人（視聴率20%）
・番組D：50000人（視聴率50%）
・未視聴：15000人
なお、ユーザはシミュレーションの途中で視聴番組を変更しないものとした。
このシミュレーション結果を表７、表８と図２３に示す。表７は、シミュレーションの任意のステップにおいて、ランダムに抽出した100ノードの各次数データによる視聴率の平均をまとめたものである。表８は、そのうちの第8次データについての基本的な統計量を計算したものである。また図２３は、100ノードの各次数のデータによる視聴率の標準偏差をグラフにしたものである。
【０１１４】
【表７】
【表８】
【０１１５】
表７及び８から、ノードの離脱があっても第8次データを用いて計算すれば十分な精度の視聴率が得られることを確認できる。図２３では、次数の増加によって視聴率の精度が向上している様子が分かる。また、第6次データや第7次データでも良い精度の視聴率が得られているため、8ステップかけて第8次データを得なくても、6ステップまたは7ステップで視聴率を求めることもできる。
【０１１６】
（集計結果取得の様子）
本実施の形態で提案した情報集計アルゴリズムは、時間の経過とともに集計結果の精度が上がっていくという特長がある。ここでは、時間軸に沿ってユーザの視聴行動を制御し、そのような集計結果の変化を確認する。
シミュレーションの条件は、ノード数10000、最大受信リンク数4、最大送信リンク数5、次数8、接続試行回数12、ノード離脱率およびノード参加率1%、データ送信間隔10[sec]とする。また、ユーザの視聴行動は以下に示すように設定する。
【０１１７】
＜1〜3ステップの番組視聴状況＞
・番組A：500人（視聴率5%）
・番組B：1000人（視聴率10%）
・番組C：2000人（視聴率20%）
・番組D：5000人（視聴率50%）
・未視聴：1500人
【０１１８】
＜4〜5ステップの番組視聴状況＞
・番組A：1500人（視聴率15%）
・番組B：800人（視聴率8%）
・番組C：2500人（視聴率25%）
・番組D：4000人（視聴率40%）
・未視聴：1200人
【０１１９】
＜6〜ステップの番組視聴状況＞
・番組A：2000人（視聴率20%）
・番組B：900人（視聴率9%）
・番組C：2200人（視聴率22%）
・番組D：3800人（視聴率38%）
・未視聴：1100人
【０１２０】
上記において、カッコ内に示したのは、その時点での真の視聴率である。このシミュレーションの結果を図２４〜図２７に示す。図はシミュレーションの8ステップ目、10ステップ目、12ステップ目、14ステップ目に得られる任意のノードの集計結果をグラフで表したものである。横軸は時刻を表しており、右端が現在の時刻となる。また、グラフ中の黒い縦線は現在から6ステップ前の時刻、赤い縦線は現在から8ステップ前の時刻を示している。なお、紫で表示された”E”のグラフはTVを視聴していないユーザの割合である。
【０１２１】
番組Dのグラフに注目する。番組Dの真の視聴率は、tを時間とすると、0≦t＜30のとき50%、30≦t＜50のとき40%、50≦tのとき38%である。
図２４〜図２７の各図において、現在から6ステップ前の黒い縦線よりも右側のデータは、サンプル数が少なく信頼できるデータではない。
図２４は、8ステップ古いt=0での視聴率は精度よく求められているが、6ステップ古いt=20の視聴率は誤差が1.5%以上と大きくなってしまっている。しかし、その2ステップ後の図２５では、誤差が0.2%程度と小さくなっていることが確認できる。同様に、図２５のt=40における視聴率も誤差が約2.7%と大きいが、その2ステップ後の図２６では、誤差はほとんど0である。図２６においては、図２４で30≦t＜70の視聴率がでたらめであったものが、誤差も小さくきれいなグラフになっている。これらの結果から、時間が経過するにつれて視聴率の精度が上昇するという本情報集計アルゴリズムの特徴が確認できる。
【０１２２】
さらに今回のシミュレーションでは、4ステップ目で一部のユーザがGoodボタンを押すように設定した。Goodボタンを押したユーザの人数は以下の通りである。
＜4ステップ目にGoodボタンを押したユーザ＞
・番組A：200人（13.3%）
・番組B：300人（37.5%）
・番組C：400人（16%）
・番組D：500人（12.5%）
【０１２３】
上記において、カッコ内の数値は、各番組の視聴人数に対するGoodボタンを押したユーザの割合である。これらの数値が各番組に対する真の満足度になる。
シミュレーションによって得た集計結果を図２８〜図３１に示す。図は8ステップ目、10ステップ目、12ステップ目、14ステップ目に得られる任意のノードの集計結果をグラフにしたものである。横軸と赤、黒の縦線は上の視聴率のグラフと同様である。
【０１２４】
番組Bに注目すると、ステップを重ねるにつれて真の満足度である37.5%に近づいていることが分かる。しかし、最終的に得られた結果が36.430%と誤差1%ほどになってしまった。シミュレーション中は、1ステップごとに全ノードのうち1%のノードがネットワークからの離脱およびネットワークへの参加を繰り返しているため、たまたま自分の近くのノードが離脱してしまったと考えられる。しかし、それでも1%の誤差であれば十分な精度といえる。
【０１２５】
（実験のまとめ）
シミュレーション実験では、まず受信リンク数を出来る限りだけ多く保持できるような最大送信リンク数の値を調べた。その結果、最大送信リンク数は最大受信リンク数よりも1だけ大きい値が適していることが確認できた（図１５〜１９参照）。
次に、ノード離脱率を変化させたときのデータ収集量を調べた。その結果、ノード離脱率を高い値に設定しても十分な量のデータを集計できていることが確認できた。これは、常に安定してデータの集計が行えているということである。
次に、ノード離脱率を変化させたときの1ステップ当たりのデータ送信回数を調べた。結果は、ノード離脱率を高い値に設定してもデータ送信回数に大きな変化は見られなかった（図２１参照）。したがって、上記実験結果（図２０参照）と同じく、本情報集計アルゴリズムは耐障害性に優れており、安定した集計ができていると言える。
次に、ノード数を変化させたときのデータ重複率を見積もった。結果、大規模なネットワークではほとんど集計データの重複が生じないことが確認できた（図２２参照）。
次に、ノードの離脱を組み入れたときに実際にどの程度の精度で視聴率を求められるか確認した。結果、かなり高い精度で視聴率を求められることが確認できた（表７〜８、及び図２３参照）。
次に、シミュレーションを実行したときの集計の経過を確認し、集計結果の精度が時間の経過とともに変化する様子を確認した。シミュレーションではあるが、短いステップ数で十分な精度の視聴率を算出することに成功しており、大規模分散環境においても短時間で高い精度の視聴率を計算できる可能性を示せた（図２４〜３１参照）。
【０１２６】
次に、本実施の形態のまとめと今後の課題について述べる。
（まとめ）
本実施の形態では、従来の番組推薦手法で扱いきれていなかった「番組の質」も取り入れて、ユーザにより有益な番組を提示できるような新しい番組推薦手法の実現を目的とした。
最初に、番組推薦に利用する情報の分析を行った。その結果、従来から番組推薦に利用されてきたEPGがフォーマル情報であるのに対して、番組の質はユーザの正直な情報を集めたインフォーマル情報であることがわかった。そこで、コンテンツの評価軸としてフォーマル情報に対応する「ジャンル」と、インフォーマル情報に対応する「バリュー」を定義した。ジャンルはコンテンツの表面的な概要を表し、バリューは内面の質を表すものである。
バリューを算出するには、多数のユーザからインフォーマルな情報を集計しなければならない。そこで本実施の形態では、インフォーマル情報の集計に適したP2Pを利用して効率的に多数のユーザのインフォーマル情報を集計できる情報集計アルゴリズムを提案した。このアルゴリズムは大規模な分散環境において効率的に情報を集計できる。小、中規模なネットワーク環境においては集計データに重複が発生するが、集計結果を比率として得る場合には誤差がほとんど生じないことが分かった。
次に、バリューを用いたP2P番組推薦システムの実現方法を示し、TVの新しい視聴スタイルとなり得る画面インタフェースを提案した。
最後のシミュレーション実験では、情報集計アルゴリズムの性能を評価すると共に、視聴率などの集計結果の算出過程を観察し、実際の番組推薦システムにおける実現可能性を示した。
【０１２７】
（今後の課題）
提案したP2P番組推薦システムには、情報の入力に関していくつか課題が残る。まず１つ目は、情報の入力を全てリモコンのボタンに頼っていることである。瞬時に、且つ気軽で簡単に情報を入力する手段として、リモコンによるボタン入力は非常に優れている。しかし、単純に入力する情報の種類だけボタンを用意すれば、ボタンの数が増えすぎてしまい、ユーザは戸惑ってしまう。この問題を解決する１つの方法として、システムがユーザを観察して自動的に情報を入力することが考えられる。ユーザの感情をユーザの声や表情から取得する研究は多く行われている。このような技術が発展すれば、システムがユーザの気持ちを自動的に入力してくれるようになる。
2つ目の問題は、ユーザがTV視聴時にGoodボタンや感情ボタンを頻繁に入力するかという問題である。受動的なTVに対してユーザに情報を入力させるには、ユーザの情報入力に対するモチベーションを高めるような工夫が必要になる。例えば、情報入力をすることによって他のユーザとインタラクションができれば、ユーザのモチベーションも上がるかもしれない。この点に関してはさらに分析を行う必要がある。
3つ目の問題は、1台のTVを複数人で視聴する場合である。本実施の形態で提案したような情報推薦システムは、基本的に個人のユーザを対象とする。複数のユーザが同時に使用すると、ユーザの正確な嗜好が取得できなくなってしまうからである。また、他のユーザに自分の嗜好を知られてしまうというプライバシーの問題も生じる。これを解決する妥当な方法は、情報入力装置(リモコン)にユーザ機能を設けることだろう。これによってシステムは誰が情報を入力したか知ることができ、個々のユーザに対して処理を切り替えることができる。現在は、携帯端末で家電を操作できるようになりつつあるが、携帯端末は主に個人で携帯しているので、これを入力装置として利用することも考えられる。
【０１２８】
次に、本発明に係る情報集計アルゴリズムの他例について説明する。
ここではP2P による情報集計の具体的なアルゴリズムを説明する。目的は、周囲数千人程度のユーザからいい加減に、かつ効率的に情報を集めることである。なお、ここでは集計する情報を「各ユーザが1 分間の間何チャンネルを見ていたか」というものとする。すなわち集計結果として得られる情報は、各チャンネルの1 分ごとの視聴人数である。
【０１２９】
まず、各ノードが持つ情報は図３２に示すようなものである。（図３２中の丸付き数字については、以下、(1),(2)…と表す）
やり取りするデータの(1)、(2)、…には、各チャンネルごとに視聴人数をカウントしたものが入る。
ここで、d 次情報を持つデータを「次数d+1 のデータ」
と呼ぶことにする。
データ集計のアルゴリズムは以下のようになる。
“起動時”
・ サーバにつなぎ、自分のノートアドレスをサーバに登録する。
・ サーバから、すでに登録済みのノードアドレスをランダムにX 個教えてもらう。
・ そのうちK 個のノードアドレスを受信リンクに登録する。逆に、自分のノードアドレスを相手ノードの送信リンクに登録してもらう。（すなわち、他ノードから要求があるまで送信リンクは
張らない。）
“送信”
・ 1 分ごとに“集計”で作成したデータを送信リンク先のノードへ送信する。
・ このときデータのTTL を1 にセットする。
“転送”
受信リンク先のノードから受信したデータについて
・ 1 ホップ隣から来たデータ(TTL=1 のデータ)は、
TTL を1 増やして送信リンク先ノードに転送す
る。
・ 2 ホップ隣から来たデータ(TTL=2 のデータ)は、“集計”へ。
“集計”
・ 自分の情報を、送信するデータの(1)にセットする。
・ 受信したデータの(1)を全て加算して、送信するデータの(2)へセットする。
・ 受信したデータの(2)を全て加算して、送信するデータの(3)へセットする。
：
・ 受信したデータのd 次情報を加算したものが、得られる集計結果である（図３３参照）。
ただし、d 次情報は1 分前のd-1 次情報を使って計算しているので、集計結果には最大d 分前の情報が含まれる。
【０１３０】
このアルゴリズムではK(d+1)・TTL人分の情報を効率的に集めることができる。また、やり取りするデータのサイズは、基本的にデータの次数のみに依存する。
“転送”にて1 ホップ隣のノードから来たデータを素通りさせるのは、データを重複して集計することを防ぐためである。しかし、それでもデータの重複を完全に防げないことは容易に想像がつく。この重複率については後に述べる。
【０１３１】
（トラフィック）
本システムは大規模なP2P ネットワーク上で動作させることを前提としている。そのため、情報を集計する際にネットワークを流れるメッセージ数がどの程度になるか、事前に見積もることが重要である。
上のアルゴリズムの場合、全ノード数をN、受信リンク数をK とし、p ホップ先までデータを送信することにすると(TTL = p)、1 タイムステップ(1 分間)に流れるメッセージ数は、
【数７】
と見積もることが出来る。と見積もることが出来る。上のアルゴリズムはp を小さく取っても多くの情報を集められるので、パラメータの適切な設定によりトラフィックはある程度小さく抑えられる。
【０１３２】
（シミュレーション）
次に、上のアルゴリズムにおいて、重複して集計されたデータの数をシミュレーションにより調べる。
図３４は、受信リンク数及び送信リンク数を4、TTL を2、データの次数を3 としたときのシミュレーション結果である。ノード数が5000〜12000 のときのデータ重複率を示している。なお、このとき集められたデータ数はど
のノード数の場合でもほぼ4000 程度であった。
本システムはノード数が数十万、数百万といった大規模ネットワークを想定している。シミュレーション結果を見る限り、そのような大規模ネットワークでは重複はほとんど生じないことが予想される。そもそも、いい加減なインフォーマル情報の集計を目的としているので、重複を完全に無くすことにあまり意味はない。
もちろん、初期のノード数が少ないネットワークでは重複率が無視できない問題となるので、これについては今後の課題とする。
【０１３３】
（効率化）
上のアルゴリズムは、全てのノードが平等に仕事をしている。しかし、ノードの性能によって役割を分けた方が明らかに効率は良い。そこで、n 次情報の集計計算をさぼるノードを考える。この場合、受け取ったデータにn+1 次情報が存在するはずなので、それをそのままコピーし、n 次情報の集計結果とすればよい。ただし、古い情報を流用しているので、当然、最終的に得られる集計結果にもその分古い情報が含まれることになる。計算をさぼるノードが増えると、ネットワークを流れる情報は古い情報ばかりになってしまうのである。そのため、さぼるノードの数を確率的に制御するか、さぼるノードの送信リンク数を減らし古い情報の流通を抑えるかするなどの対策が必要になる。これについては今後分析を行っていく。
【０１３４】
（P2P 情報推薦システム）
本実施の形態では、デジタル放送に対応したセットトップボックス(STB)上にシステムの実装を進めている。
以下に、本システムの具体的な実現方法について説明する。
【０１３５】
（ジャンルによる番組推薦）
ユーザの好みの番組を推測するためには、ユーザの番組に対する嗜好を知る必要がある。そのため本システムでは、STB のリモコンに「Good ボタン」と「No-Goodボタン」を割り当て、番組を視聴中のユーザに、その番組が気に入ったか、気に入らないかを入力してもらうことにした。
これらのボタンが押されると、システムはその番組のEPG 情報のワード列を単語に分解して抜き出し、ワードリストに登録する。すでに登録されている単語については、その出現回数を更新する。(Good ボタンの場合は出現回数を1 増やし、No-Good ボタンの場合は1 減らす。)
なお、ワードリストとは、単語とその出現回数のリストであり、そのサイズは最大6000 ワードとした。この方法によって、ワードリストはユーザの嗜好そのものとなる。すなわち、出現回数の多い単語が、ユーザの好きな番組
の特徴を表すのである。
【０１３６】
ユーザの嗜好と番組のマッチングユーザの好きなジャンルの番組を推測するために、ユーザのワードリストと番組のEPG 情報のワード列(をワードリストに変換したもの)との類似度を計算する。この類似度計算は、まず各単語間で類似度を計算し、その次にワードリスト間で類似度を計算するという2 段階の手続きを踏む。
単語間の類似度の計算には、EDR 電子化辞書の概念辞書と英語単語辞書を利用する。概念辞書には概念の上下関係がツリー構造で記述されている。そして英語単語辞書には、英単語と概念の対応関係が記述されている。
ただし、実際に使用する英単語はSTB 上にのるように高頻度の6000 語程度に限定する。
単語間の類似度計算は、まず英語単語辞書で2 つの単語の概念を引き、次に概念辞書のツリーにおけるそれら概念間の距離を計算する。この距離をNp、ツリーの最大の高さをD とするとき、上記した（６・１）式［数６］で単語間の類似度を計算する。
次にワードリスト間の類似度の計算のために、まず、長い方のワードリスト内の単語から、短い方のワードリスト内の各単語と類似度の高いものを抽出して、新たなワードリストを作成する。この新しいワードリストは短い方のワードリストと同じ長さである。そして、新しいワードリスト(各単語の出現回数と類似度をかけた値)と短い方のワードリスト(各単語の出現回数の値)をベクトルとしてその内積を計算し、その成す角を求める。この角度が小さければ、その番組はユーザの嗜好に合っていることになる。
【０１３７】
（バリューによる番組推薦）
バリューには、ユーザから集める情報によって様々な
ものが考えられる。例えば、本システムでは
・視聴率
・視聴時間
・視聴回数
・Good ボタン、No-Good ボタンが押された回数
・録画したかどうか
・ブックマークしたかどうか
などがバリューとして考えられる。これらは4 章の情報集計アルゴリズムを使って容易に得ることができる。
これらのバリュー及びその変遷を番組毎に提示してやることで、ユーザは様々な角度から番組を知ることができ、これまでとは違った視点で番組を選ぶことができるようになる。
【０１３８】
（クラスタリング）
クラスタリングとは、嗜好の似た者同士を近くにまとめる技術である。これを導入することによって、ユーザはさらに多くの有用な情報を得ることができる。それはすなわち、世間一般の人によるバリュー以外にも、自分と嗜好が似ている人によるバリューも得ることが出来る、ということである。これは、自分と趣味が似ている友人が非常に有用な情報を提供してくれることと同じである。
また、自分が属すクラスタ以外のクラスタから情報を得ることも非常に有用である。なぜなら、クラスタとはその分野に深く通じた者の集団だからである。自分が詳しくない分野について、その分野の専門家の意見を参考にすることは賢い方法である。
本システムでクラスタリングを導入することはさほど難しくない。各ノードは自分の嗜好をワードリストとして保持しているので、それを用いて各ノードと嗜好の類似度を計算し、類似度の高い相手と選択的に接続すればよいからである。
しかし問題もある。クラスタリングをしてしまうと、周りには自分と似ている人しかいないため、自分と似ている人からしか情報を集められなくなってしまうのである。すなわち、世間一般の人によるバリューが得られくなってしまう。そこで、例えば以下の2 つの方法が考えられる。
方法１：接続先ノードを、嗜好ノードリストとランダムノードリストの2 つのノードリストで管理する。
方法2：周囲のノード群の中から、自分と似ているノードの情報を抽出する。
【０１３９】
（方法1）
方法１は、クラスタリングしたネットワークとクラスタリングしていないネットワークが同時に存在するとした方法である。嗜好ノードリストには、自分と嗜好類似度の高いノードアドレスを登録し、ランダムノードリストには、ランダムなノードのアドレスを登録する。そして、これら2 つのノードリストで独立平行に情報集計アルゴリズムを実行する。
この方法では、柔軟で正確なクラスタリングが可能である。そして、世間一般の人の情報も、自分と嗜好が似ている人の情報も集めることが出来る。しかし、情報集計アルゴリズムを2 つ平行して実行させることになり、トラフィックと計算コストが2 倍になってしまう。また、他のクラスタの情報を得ることは出来ない。
【０１４０】
（方法2）
方法２では、全ユーザで共通のジャンルを導入する必要がある。各ユーザは自分の嗜好ワードリストから、共通のジャンルに対する嗜好の度合いを計算し、0〜1 の値に変換する。(= 一時共通ジャンルリスト) そしてその値が高いものは1、それ以外は0 とする共通ジャンルリストを作成する（図３５参照）。すなわち、好きな共通ジャンルを1 とする。なお、共通のジャンルは数十個程度とする。
【０１４１】
共通ジャンルリストは、同じ番組を見ていたユーザ同士で足し合わせながら集計する。そうすれば、その番組を見ていたユーザの中で、共通genre1 が好きなユーザ数、共通genre2 が好きなユーザ数、・・・を知ることができる。すなわち、共通genreX の専門家の情報を得られるということである。これは、ユーザを共通ジャンルでクラスタリングしたことと同じである。
また、自分と似ている人の情報は、集計した共通ジャンルリストと自分の一時共通ジャンルリストの値をかけて足し合わせることで、擬似的に求めることができる。
この方法２では、あらかじめ共通のジャンルを決めてしまうので、新しいジャンルが出てきたときに対応できないなど、柔軟で精度の高いクラスタリングが不可能となってしまう。
【図面の簡単な説明】
【０１４２】
【図１】コンテンツベース推薦の概念を示す模式図である。
【図２】コラボレーティブ推薦の概念を示す模式図である。
【図３】コラボレーティブホライズンの概念を示す模式図である。
【図４】放送番組と同期した掲示板の話題について、時間経過と盛り上がりの関係を示すグラフである。
【図５】ＴＶ番組に対する掲示板へのメッセージ投稿数の順位を番組ジャンルごとに集計したグラフである。
【図６】情報集計方法の一例を示す模式図である。
【図７】情報集計アルゴリズムの仕組みを示す模式図である。
【図８】データの集計方法の一例を示す模式図である。
【図９】重複データを考慮し視聴率の誤差を可視化したグラフである。
【図１０】共通ジャンルリストの作成例を示す模式図である。
【図１１】共通ジャンルリストの集計の概念を示す模式図である。
【図１２】番組表示中の画面の一例を模式的に示す図である。
【図１３】実際の番組表示中の画面の一例を示す図である。
【図１４】番組推薦インタフェースの一例を示す図である。
【図１５】受信リンク数が０の場合について、最大送信リンク数とノード数の関係を示すグラフである。
【図１６】受信リンク数が１の場合について、最大送信リンク数とノード数の関係を示すグラフである。
【図１７】受信リンク数が２の場合について、最大送信リンク数とノード数の関係を示すグラフである。
【図１８】受信リンク数が３の場合について、最大送信リンク数とノード数の関係を示すグラフである。
【図１９】受信リンク数が４の場合について、最大送信リンク数とノード数の関係を示すグラフである。
【図２０】ノード離脱率と収集データ量の関係の一例を示すグラフである。
【図２１】ノード離脱率とデータ送信回数の関係の一例を示すグラフである。
【図２２】ノード数とデータ重複率の関係の一例を示すグラフである。
【図２３】100ノードの各次数のデータによる視聴率の標準偏差を示すグラフである。
【図２４】視聴率について８ステップ後の集計結果の一例を示すグラフである。
【図２５】視聴率について１０ステップ後の集計結果の一例を示すグラフである。
【図２６】視聴率について１２ステップ後の集計結果の一例を示すグラフである。
【図２７】視聴率について１４ステップ後の集計結果の一例を示すグラフである。
【図２８】満足度について８ステップ後の集計結果の一例を示すグラフである。
【図２９】満足度について１０ステップ後の集計結果の一例を示すグラフである。
【図３０】満足度について１２ステップ後の集計結果の一例を示すグラフである。
【図３１】満足度について１４ステップ後の集計結果の一例を示すグラフである。
【図３２】やり取りするデータの一例を示す模式図である。
【図３３】データの集計方法の一例を示す模式図である。
【図３４】ノード数とデータ重複率の関係の一例を示すグラフである。
【図３５】共通ジャンルリストの作成例を示す模式図である。
【技術分野】
【０００１】
本発明は、放送番組の視聴率をP2Pネットワークを使用して集計するシステムに関するものである。
【背景技術】
【０００２】
社会の情報化が進むにつれて、我々が触れることのできる情報は爆発的に増えてきた。情報の増加は、ユーザの柔軟な選択を可能とし、より豊かな生活をもたらすものである。しかし膨大すぎる情報は、ユーザの情報処理能力をはるかに超え、逆にユーザの生活を妨げるものとなっている。
例えば、近年放送のデジタル化が進み、TVコンテンツも急速に増加して、ユーザはよりニーズにあった番組を視聴できるようになった。しかし、従来はチャンネル数が少なくザッピングによってどんな番組が放送されているのか気軽に確認することができていたが、チャンネル数が増加した現在では、どんな番組が放送されているのかを確認するだけで多くの時間を費やしてしまう。
また、情報雑誌から見たい番組を探すという方法もよく行われている方法ではあるが、そういった雑誌は万人向けの番組を紹介することが多く、ユーザのニッチな要望に応えるものではない。2011年には地上アナログ放送から完全に地上デジタル放送へ移行することも予定されており、今後このような問題はより顕著になっていくものと考えられる。
【０００３】
このような問題を解決する従来技術として、情報検索技術がある。これは、膨大な情報の中から効率的に必要な情報を見つけることを目的としている。代表的なものには検索エンジンが挙げられる。検索エンジンは、インターネット上に散らばる膨大な情報の中から希望した情報を検索して返してくれる。しかしユーザが適切な検索式を入力しないと、望みどおりの情報を得ることはできない。また、検索結果が膨大な量になることもしばしばあり、その場合、膨大な検索結果の中からさらに望みの情報を絞り込まなければならない。情報検索はユーザの能力にも大きく依存するのである。
【０００４】
そこで、情報検索のこのような問題を解決する手法として情報推薦がある。情報推薦とは、ユーザの好みや要求をシステムが推測し、それに合致する情報を自動的に探してユーザに提示する、という技術である。情報推薦は情報検索のようにユーザの能力に依存することはなく、そのためユーザは何も意識することなく望みの情報を手に入れることができる。ユーザの負担が少ない情報推薦技術は、情報過多社会において非常に重要視されているのである。
しかし、従来の情報推薦手法は主にユーザの好みを重要視しており、情報の質を深く考慮していない。そのため良い推薦結果が得られないことも多々ある。ここでの情報の質とは、ユーザにとってその情報がどれだけ価値のあるものかという意味である。どれだけその情報が貴重であろうが、ユーザにとって全く役に立たない情報に価値はない。また、ユーザによって価値観は異なるため、あるユーザにとって価値がある情報でも他のユーザにとって価値があるとは限らない。すなわち、情報の質はユーザ１人１人によって決定されると言うこともできる。
【０００５】
以上のような背景を踏まえ、本発明では情報推薦手法について扱う。特に、従来の推薦手法で軽視されている情報の質を取り上げて、推薦結果向上の実現方法を探る。なお、情報推薦の対象の好ましい一例としては、今後のデジタル放送社会を考えTV番組とする。
従来のTV番組の推薦システムは、ユーザの好みに合う番組を推測することが目標であった。しかし、情報の質すなわち番組コンテンツの価値という観点から見ると、ユーザが望む推薦システムは、自分の好みに合う番組で且つ自分にとって見る価値がある番組を推薦するものであると言える。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
本発明は上記従来事情に鑑みてなされたものであり、その課題とする処は、ユーザにとってより有用な視聴情報の推薦を可能にすべく、放送番組の視聴率をP2Pネットワークを使用して集計するシステムを提供することにある。
【課題を解決するための手段】
【０００７】
上記課題を解決するために本発明は、複数の視聴者に対応したノードを接続したネットワークを利用した視聴率を集計するシステムにおいて、各ノードから、他のノードに対して受信リンクを張る手段と、ネットワークを構成する各ノードが、受信リンクを張られたノードに対して定期的にリンクを介して視聴率に関するデータを送信する手段と、各ノードにおいて、視聴率に関するデータを収集し、集計する手段と、集計された視聴率に関するデータが、一定期間受信されないノードとの受信リンクを切断し、他のノードとのリンクを張りなおす手段とを
有することを特徴とする。
【０００８】
更に好ましくは、視聴率データを収集し、集計する手段は、各ノードが、各ノード自身の情報（0次情報）、他の1つのノードが得た情報（1次情報）、さらに他の1つのノードを介して得た情報（2次情報）・・・毎に集計することを特徴とする。
【発明を実施するための最良の形態】
【０００９】
本発明に係る実施の形態では、番組の質を考慮した上で、番組推薦の精度の向上を目指す。そこで先ずは、従来の典型的な推薦手法を分析し、次に情報の質を決定する上で重要な要素となる個々のユーザの情報を効果的に利用することについて説明する。そして、従来の推薦手法が番組の質を考慮していないために現れる問題を述べる。
【００１０】
（従来の情報推薦手法）
情報推薦の研究は数多く行われており[1]、代表的な手法にコンテンツベース推薦[2]とコラボレーティブ推薦[3]がある。
（参考文献）
[1] Adomavicius, G and Tuzhilin A.: Toward the next generation of recommender systems: A survey of the state-of-the-art and possible extensions; IEEE Trans. KDE, Vol.17, No.6, pp.734-749, 2005.
[2] M. Balabanovic and Y. Shoham: Fab: Content-Based, Collaborative Recommendation; Comm. ACM, Vol.40, No.3, pp.66-72, 1997.
[3] P.Resnick, N. Iakovou, M. Sushak, P. Bergstorm, and J. Riedl: GroupLens: An Open Architecture for Collaborative Filtering of Netnews; Proc. of 1994 ACM Conference on Computer Supported Cooperative Work pp.175-186., 1994.
【００１１】
コンテンツベース推薦は、ユーザの視聴履歴情報に基づいて推薦する手法である。システムは、ユーザの視聴履歴からどんなものを好んで視聴しているかを学習し、その好みと合致するものをユーザに提示する。そのため、この手法では比較的ユーザの希望通りの情報推薦が期待できる。しかし、ユーザの視聴履歴からはずれる情報が推薦されることはなく、例えば、ユーザ自身がまだ気づいてない自分の好みを発見する、という体験をすることは出来ない。図１は、番組推薦におけるコンテンツベース推薦を模式的に表したものである。大きな円は視聴者Aの視聴履歴から求められる視聴者Aの嗜好を表している。視聴者Aには、この嗜好の中に含まれる番組が推薦されることになり、比較的精度の高い推薦結果が得られる。
【００１２】
一方コラボレーティブ推薦は、自分と嗜好が似ているユーザの履歴情報を参考にして推薦を行う手法である。自分と嗜好が似ているユーザの好みに合うもので、まだ自分にとって未視聴である情報を推薦する、というものである。図２はこれを模式的に表したものである。視聴者Aと視聴者Bは嗜好が重なっており、お互いの好みが似ている。そこで、視聴者Aの嗜好に含まれない番組でも、視聴者Bの嗜好に含まれていれば視聴者Aもきっと好きであろうと推測し、その番組を視聴者Aに推薦するわけである。この手法では他のユーザの視聴履歴を利用するため、各ユーザの嗜好情報が豊富でかつ多様なユーザが存在すれば、情報推薦は効果的に行われる。また、コンテンツベース推薦の欠点である、新しい好みの発見という問題も解決できる。
【００１３】
しかし、コラボレーティブ推薦には情報伝播の境界”コラボレーティブホライズン”が存在することも指摘されている[4]。コラボレーティブ推薦では、人から人へと推薦を行うことによって情報推薦の伝播が発生する。しかし、嗜好の似ているユーザ同士で閉じたグループを形成してしまう可能性があり、そのグループには他のユーザからの推薦が行われない(図３参照)。これを解決するために、Forced Social Filtering[4]が提案されている。これは、閉じたグループに対して、グループの嗜好は考えず、とりあえず試しに推薦してみる、という方法をとっている。これによって情報伝播の境界は解消され、ユーザ全体で見れば効率的なコラボレーティブ推薦が行われる。しかし個々のユーザから見ると、試しに行った推薦が成功するとは限らず課題も残る。
（参考文献）
[4] 田野 俊一, 木根 智也, 石谷 規彦: 広域的強化学習によるデジタル情報推薦の活性化手法; 電気学会論文誌 C, Vol. 121-C, No.7, pp.1237-1245, 2001.
【００１４】
（個々のユーザの情報の利用）
近年、インターネット技術の普及によって多数のユーザが自分の情報をインターネット上に頻繁に発信するようになってきた。そこで、これらのユーザが発信した情報を利用して有益な成果を得ようとする新しい試みが出てきている。その1つに、様々なユーザによって投稿されたインターネット掲示板上のメッセージを利用し、それを番組コンテンツへのアノテーションに役立てようとする研究がある[5]。
（参考文献）
[5] 岡本 直之, 竹之内 隆夫, 川村 隆浩, 大須賀 昭彦, 前川 守: 放送番組に対してパブリックオピニオン・メタデータを生成する視聴支援エージェントの開発〜ネットコミュニティからの雰囲気成分の抽出とユーザ間での流通による洗練化〜; 電子情報通信学会, Vol. J88-D-I, No.9, pp.1477-1486, 2005.
【００１５】
このインターネット掲示板は放送中の番組と連動しており、番組を視聴しているユーザがリアルタイムにメッセージを投稿する。そこでこの研究では、投稿された特定のメッセージの出現頻度を計算することで、そのときの掲示板での話題と盛り上がりを番組と関連付けて検出している(図４参照)。こうして得られたデータは番組のメタデータとして利用できる。
個々のユーザが自由に発信する情報は、役に立たないゴミの情報が大部分を占めるが、中には非常に価値のある情報も含まれている。この研究は、そのような情報の中から価値のある情報を抽出して効果的に利用している。
【００１６】
（従来の情報推薦手法の問題点）
従来の情報推薦システムは、コンテンツベース推薦とコラボレーティブ推薦を組み合わせて両方の利点を利用するものなどが多い。しかしどの推薦手法も、目的はユーザの好みの情報を推測することである。テレビ番組の推薦ならば、番組のEPG(電子番組ガイド)データとユーザの視聴履歴、及び他のユーザの視聴履歴を用いて、出来る限りユーザの好みに合う番組を推測することが目標であった。
しかし、ユーザの好みを利用した番組推薦は番組の表面的な概要しか見ていない。実際に番組を見て本当にユーザが見たいと思う内容か判断しているわけではないため、ユーザは推薦された番組を見て落胆することが多い。たとえ好みの番組で毎週見ている番組でも、毎回面白い回とは限らず、時にはつまらなく感じる回もあり、このような場合は実際に番組を見て判断するしかない。
【００１７】
ユーザが見たいと思う番組を推測するためには、さらにユーザの視聴行動を知る必要がある。ユーザは必ずしも自分の好みに合う番組を見るわけではない。世間の動向を把握するために話題の番組を見ることもあれば、友人との話しのネタに普段は見ないような番組を見ることある。その結果自分の新しい好みを発見することもあるだろう。このようなユーザには、好みに合う番組を推測しても意味がない。そもそも、ユーザが求める番組と推薦システムが推測しようとする番組がずれているのである。これが従来の推薦手法の限界である。本発明に係る実施の形態ではこのような状況にも対応できる番組推薦を目指す。そのためには、各ユーザの要求を考慮した上で番組推薦を行う。
【００１８】
（本実施の形態のアプローチ）
本実施の形態では、従来の番組推薦と、番組の質を考慮した新しい番組推薦を同時に行うことで、ユーザが本当に見たいと思う番組を推測する。
この２つの推薦手法はタイプが違うため利用する情報も異なる。情報は、その性質が異なれば扱い方も異なるため、まずはこれらの推薦手法において情報の分類を行う。その上でそれぞれの推薦手法に適した情報の利用方法を検討する。
本実施の形態では、推薦手法としてコンテンツベース推薦を用いる。その他の手法も有用ではあるが、それらはどれも本質的な目的はコンテンツベース推薦と同一であるため、本実施の形態では利用しない。
番組の質を考慮した番組推薦手法に関しては、上記したように、２つの要求事項が存在する。１つ目は、ユーザの細かい要求に対応できなければならないことである。これは、必要に応じてユーザに推薦して欲しい番組の方向性を決定してもらうことで対応できる。２つ目は、正確な番組の価値を知るために実際にその番組を視聴する必要があるということである。これについても、多数のユーザが協力し合うことで解決できる。自分以外の多数のユーザが様々な価値観で番組を視聴し、その価値を決定していれば、それは自分にとっても非常に参考になる情報だからである。特に自分と価値観が似ているユーザの評価は、自分の評価と似た結果になり信頼できるものとなる。したがって、番組の質を考慮した番組推薦には、多数のユーザによる番組評価を集計して得られる集計結果を利用する。
【００１９】
以上をまとめると以下のようになる。
・従来の推薦手法と番組の質を考慮した推薦手法で、どのような情報を扱うか明確にする
・推薦手法としてコンテンツベース推薦を用いる
・必要に応じて、ユーザが番組推薦の方向性を決定する
・多数のユーザに番組の評価をしてもらい、その評価の集計結果を番組推薦に利用する
【００２０】
［情報の分類と利用］
次に、従来の推薦手法および番組の質を考慮した新しい推薦手法で利用する情報の分析について説明する。
（番組推薦で利用する情報）
（従来の番組推薦手法）
従来の番組推薦手法はユーザの嗜好を用いて番組推薦を行う。ユーザが好んで視聴する番組の概要データをEPG(電子番組ガイド)データから取得し蓄積することで、その蓄積されたデータがユーザの嗜好を表すデータとなる。よって、従来の番組推薦手法はEPGデータに頼った推薦手法と言える。
このEPGデータは特定の機関が提供しており、正確で信頼できる情報である。個々のユーザが自由に発信できる類の情報ではない。このような情報のことをフォーマル情報と呼ぶ。
【００２１】
（新しい番組推薦手法）
新しい番組推薦手法では、番組の質を評価するために番組に対する多数のユーザの評価という情報を利用する。これは、EPGと異なりユーザが自由に発信することができる。ただし、ユーザが自由に発信できてしまうためにいいかげんで嘘の情報が含まれることもある。このような情報のことを一般にインフォーマル情報と呼ぶ。
【００２２】
番組推薦に利用する情報に関して、従来の推薦手法ではフォーマル情報を利用し、新しい推薦手法ではインフォーマル情報を利用するという明確な違いが明らかになった。すなわち、従来の推薦手法では番組コンテンツをフォーマル情報で評価し、新しい推薦手法では番組コンテンツをインフォーマル情報で評価している。そこで本実施の形態では、これら２つの手法で番組コンテンツを定量的に評価するため、ユーザの好みや番組の概要を表す「ジャンル」と、番組の質や価値を表す「バリュー」を定義し、この２つを番組コンテンツの評価軸として導入する。ただし、番組の質や価値はユーザの価値観の違いによって複数の指標が存在する。よって、バリューも複数存在し得る。
ところで、インフォーマル情報は従来の推薦手法では扱われず、番組の質を考慮した新しい番組推薦手法で初めて積極的に導入されるものである。そこで、次の節ではインフォーマル情報の分析を行う。
【００２３】
（インフォーマル情報）
インフォーマル情報とは、雑談やうわさ、口コミなどで伝えられる非公式な情報のことである。その特徴として、”いいかげん”、”本音”、”うそ”といった性質を持つ。
一方、インフォーマル情報と対照的なものにフォーマル情報がある。フォーマル情報は、TVや新聞、雑誌などの権威あるメディアを通して伝えられる公式な情報のことである。その特徴として、“正確”、”建前”、”信憑性がある”といった性質を持つ。
従来より、正確で定型的であるという性質から様々なシステムで利用されてきたのはフォーマル情報である。一方、インフォーマル情報は、不定型でいいかげんであるという理由のため敬遠されてきた。しかし、インフォーマル情報にはユーザの本音の情報が含まれておりその利用価値は高い。インフォーマル情報はその扱い方さえ間違えなければ価値を引き出すことが出来る。
【００２４】
例えば、書籍”Wisdom of Crowds”では、一定の条件の下で多数のユーザの主観的な意見の集約が案外正しいことを示す事例を多く紹介している[6]。また、インターネット上の百科事典であるWikipedia[7]は、ユーザが自由に加筆、修正を行えるにもかかわらず、掲載されている情報は大部分が正しい情報であるという。このように、多数のユーザのインフォーマル情報は集約することでその価値を抽出することが可能になる。
（参考文献及び参考ＵＲＬ）
[6] ジェームズ・スロウィッキー, 小高: 「みんなの意見は案外正しい」, 角川書店, 2006.
[7] “ウィキペディア”, http://ja.wikipedia.org/
【００２５】
従来からフォーマル情報ばかりが利用されてきた理由に、多数のインフォーマル情報を気軽に共有できる場が存在しなかったことも挙げられる。そこで次に、メディアの発展とともにインフォーマル情報の共有について考察する。そして、TV番組に関して多数のインフォーマル情報が共有され得るのか分析する。
【００２６】
メディアは言葉やジェスチャー、文字といったものから、印刷、ラジオ、電話、TVへと発展し、さらに現在のPC、携帯電話、インターネットへと発展を遂げた。このようなメディアの発展により、フォーマル情報、インフォーマル情報の共有は共に大きく向上した。しかし、印刷〜TVといったメディア、特にラジオやTVについては、権威ある者が発信する情報が大部分を占める。すなわちラジオやTVの登場は、フォーマル情報の共有だけを飛躍的に増加させた。この時点で、インフォーマル情報の共有はそれほど飛躍的には向上しなかった。その後インターネットが普及し、誰でも自分のWebページを不特定多数に公開できるようになり、フォーマル情報以上にインフォーマル情報の共有が急増した。その流れを後押しするように、自由な情報発信を保護する目的でP2P(Peer-to-Peer)技術を利用したネットワークも登場した。さらにインターネットは、手紙、電話、ラジオ、TVなどの機能(メールやインターネットTVなど)も内包し、これまで主に一部の者だけが情報発信してきた既存メディアすらも、個人の情報発信の手段へと変化させた。インターネットは、既存のメディアも巻き込んでインフォーマル情報の爆発を引き起こしたのである[11][12]。
その結果、現在インターネット上には無数のインフォーマル情報が存在する。ここで、特にTV番組に関するインフォーマル情報の共有について調べる。図５は、インターネット上のある匿名掲示板群における、2005年のTV番組に対するメッセージ投稿数の順位を番組ジャンルごとに集計したものである。前記匿名掲示板群には、主要放送キー局ごとに掲示板が用意されおり、放送番組に対してリアルタイムに多くのメッセージが投稿されている。図５はそれらの掲示板のメッセージ数を集計したものである。
（参考文献）
[11] 田野 俊一, 岩田 満, 橋山 智訓:インフォーマル情報爆発とそれを活用するユーザインタフェースの事例; ヒューマンインタフェースシンポジウム, pp.1175-1180, 2006.
[12] 小井土 祐三, 田野 俊一, 岩田 満, 橋山 智訓:新たな視聴支援方法の提案とインフォーマル視聴情報のP2P集計アルゴリズムの実現; ヒューマンインタフェースシンポジウム, 2006.
【００２７】
図５から、TV番組に対して多いもので毎分数百ものメッセージが投稿されていることがわかる。また、どの番組ジャンルに対しても投稿数は多く、TV番組に関するインフォーマル情報は溢れているということが確認できる。よって、番組推薦においてもインフォーマル情報を活用できる可能性は十分にあると考えられる。ただし、本実施の形態では、インターネット掲示板上のインフォーマル情報を利用するというわけではない。
【００２８】
（インフォーマル情報の発信の活性化）
ユーザの発信するインフォーマル情報を利用する場合は、いかにユーザのインフォーマル情報の発信を活性化させるかが重要な問題となる。特に、すでに情報発信の活性化に成功している従来システムを情報源として利用しない場合は、この問題はやっかいである。本実施の形態では情報源にそのような既存のシステムは利用しない。そのようなシステムがこれからも存在するとは言い切れないからである。そこで本実施の形態では、一般的な視聴行動からインフォーマル情報を取得することを前提とする。
【００２９】
インフォーマル情報発生の活性化に関連する研究としては、インフォーマルコミュニケーションの支援がある。インフォーマル情報は特にインフォーマルコミュニケーションから大量に発生しやすい。このインフォーマルコミュニケーションは、情報の獲得や共有、知的創造活動の促進といった役割を果たすため従来から重要視されているものである。そのため、インフォーマルコミュニケーションを促す研究は数多くなされており、特に、相手との親近感とコミュニケーションのきっかけが重要な要素であると考えて、仮想的な対面環境を構築したり、対面環境でのインフォーマルコミュニケーションのきっかけを与える研究が多い。一方で、対面環境も支援せず、やりとりする情報もテキストデータのみという匿名掲示板で、対面環境以上に本音であると思われるやりとりが頻繁に行われているという事実もある。
本来は、これらを詳細に分析し、TV視聴という環境においてインフォーマル情報の発生を活発にする手法を検討すべきであるが、本実施の形態ではそこまでは扱わず、この問題に関しては今後の重要な課題とする。
【００３０】
（番組推薦におけるバリュー）
以上までで、番組の質を考慮した番組推薦手法に、ユーザの番組に対する評価、すなわちインフォーマル情報が利用できることが分かった。しかし、ユーザのインフォーマル情報が具体的にどのような情報なのかはまだ分からない。そこで次に、ユーザの視聴行動から得られる具体的なインフォーマル情報を示し、それらの情報から得られるバリューについて説明する。
【００３１】
ユーザの番組視聴行動から取得できる情報には以下のようなものが考えられる。
・どの番組を視聴しているか
・番組の視聴時間
・ブックマークしたかどうか
・録画、予約録画したかどうか
・録画番組の視聴回数
・番組に対する感想
・番組に対する感情
・番組に対するアノテーション
【００３２】
すなわち、これらの情報から番組の質を評価することになる。例えば、視聴回数が多ければその番組はそれだけ面白く質が高いと評価できる。よって、番組の質を考慮した番組推薦を実現するためには、多数のユーザからこれらの情報を収集することになる。そして収集した情報を集約することで、ユーザは様々なバリューを得ることができる。その中でも番組推薦に利用しやすいバリューを以下に示す。
・番組の人気度
・番組の性質
・番組に対する期待度
・番組に対する満足度
・番組に対する感情
【００３３】
番組の人気度は、どれだけ多くのユーザが好んで番組を視聴しているかを表すものである。これは、番組の視聴率や番組の視聴回数などから計算できる。世間で話題の番組を見ておきたい、といった場合などに番組の人気度は有効である。
次の番組の性質は、ユーザからみてその番組がどのような特徴を持っているか、を表す。例えば、保守的な番組や急進的な番組、子供には相応しくない番組、といったものがここで言う番組の性質である。これらはユーザにその旨の情報を直接入力してもらうことになる。
【００３４】
番組に対する期待度は、まだ放送されていない番組に対してユーザがどれだけ期待を寄せているかを表すものである。例えば、今夜から放送が開始される新番組は世間からどれだけ注目を浴びているのか、ということが番組の期待度から分かる。これはユーザの番組に対する直接入力以外に、その番組を予約録画したかどうかといった情報からも計算することができる。
【００３５】
番組に対する満足度は、ユーザが番組に対して満足したか、あるいは面白いと思ったかを表すものである。これは、番組に対してユーザが直接入力した、”満足した”または”不満であった”という情報から計算できる。
【００３６】
最後の、番組に対する感情は、番組を視聴してユーザがどのような感情を抱いたかを表すものである。例えば、映画を見ていて感動のシーンであれば”感動した”という情報を入力し、恐怖を感じるシーンであれば”怖い”といった情報を入力する。表情認識技術を使えば、これらをシステムが自動的に取得することも可能である。取得した情報は、感動できる番組を見たいというユーザや、怖いシーンは苦手だから見たくないといったユーザに対して効果的に利用できる。
これらの具体的な利用方法については後述する。
【００３７】
（情報の集計方式）
以上では、ユーザの視聴行動から得られる具体的なインフォーマル情報と、それを集計することで得られるバリューの例を示した。
そこで次に、ユーザの感情といったインフォーマル情報を集計する際に問題となる、情報の集計方式について述べる。
従来から、情報の集計にはクライアント・サーバ方式が多く用いられてきた。それは、簡単に全ユーザの情報を集計できるからである。しかし、今回集計する情報はインフォーマル情報である。インフォーマル情報の、途中で中央管理機構が介在するとインフォーマル度が低下する恐れがあるという特徴は、クライアント・サーバ方式とインフォーマル情報の相性が悪いことを示している。また、クライアント・サーバ方式は正確な情報集計に適している方式であるが、そもそも”いいかげん”なインフォーマル情報を正確に集計する必要はない。
中央管理機構を介在させずに済む方法としてはP2P方式がある。P2P方式はユーザ同士が直接接続するブローカレスモデルである。途中に中央管理機構を介さないため、インフォーマル情報を扱う場合でもそのインフォーマル度の低下を防ぐことができる。また、分散的な性質も持ち合わせており、各ノードに負荷を分散させることができるというメリットもある。さらに、P2Pでは各ノードが連携しながら情報を集計することになるので、ある程度いいかげんな情報集計になることが多い。このことからも、P2Pとインフォーマル情報の相性が良いことがわかる。ただし、P2Pにも一部にクライアント・サーバ方式を取り入れたハイブリッドP2Pモデルが存在し、純粋なP2Pモデル(ピュアP2P)とは区別されている。
【００３８】
このような理由から、本実施の形態ではインフォーマル情報と相性がいいP2P方式(ピュアP2P)を用いて情報の集計を行うことにする。
ここで、従来の推薦手法と本実施の形態で目指す新しい推薦手法の特徴を表１にまとめる。なお、新しい推薦手法は従来の推薦手法を内包するものである。
【００３９】
【表１】
【００４０】
（プライバシーの問題）
ユーザの視聴情報を扱う場合に問題となるのがプライバシーの問題である。一般的にユーザは自分の視聴履歴が誰かの手に渡ることを嫌がる傾向にある。すなわち、自分の視聴履歴が自動的に集計されることに不安を抱いているユーザもいる。
しかし、本実施の形態ではP2P通信でユーザ同士が協力して視聴情報を集計するため、特定の機関に自分の視聴履歴を把握されるということはない。もちろん、個人を特定できるような情報はそもそも送信しない。また、視聴情報を暗号化して集計を行えばセキュリティを高めることもできる。
【００４１】
（情報集計アルゴリズム）
次に、インフォーマル情報の集計に適したアルゴリズムを提案し、その性能を分析する。
【００４２】
（集計可能な情報）
インフォーマル情報の集計アルゴリズムを考案するために、まずはどのようなインフォーマル情報を集計するのか明らかにする。
例えば、各ユーザから取得する情報は例えば以下のようなものになる。
・どの番組を視聴しているか
・子供に見せたくないか
・満足したか(面白かったか)
・どんな感情を抱いたか
これらの情報はすべて数値で入力することができる。例えば、”どの番組を視聴しているか”ならば、視聴している番組には1、視聴していない番組には0を入力し、”子供に見せたくないか”や”満足したかどうか”ならば、番組に対してそれらの度合いを数値で入力する。”感情”についても、どんな感情をどの程度抱いたかを数値で入力すればよい。感情の種類には例えば”喜び”、”怒り”、”悲しみ”、”楽しみ”といったものが考えられる。
【００４３】
このように情報を数値で表すことによって、情報の集計はこれらの値を単純に加算するだけでよいことになる。ここで提案する情報集計アルゴリズムは、このような数値で表されたインフォーマル情報の集計を行うものとする。
なお、番組推薦で利用しやすいように、集計結果は比率として計算することにする。すなわち、番組Aを見ているのは全体の何%か(視聴率)、何%のユーザが番組Aに満足しているか、何%のユーザが番組に対して感動したか、といった情報を得ることを目的とする。そのため、ユーザの人数(サンプル数)も一緒に集計できるようにする。
【００４４】
（要件）
次に、番組推薦システムで求められる情報集計アルゴリズムの機能と性能における要件をまとめる。
まず必要最低限の機能は、上述したように、数値で表されたインフォーマル情報を番組ごとに常時集計できることである。ただし、集計結果である視聴率などは、数秒間隔でその値が分かるようにする。すなわち、番組の平均視聴率だけでなく視聴率の変遷も分かるように集計する。また、リアルタイムに変化する視聴率などの様子も番組推薦に利用できるため、リアルタイム集計も実現する。
【００４５】
次に想定するネットワークの規模であるが、現在日本でTVを所有している世帯数は数千万にも及ぶ。そこで、本実施の形態でも大規模なネットワークを想定しておく必要がある。よって、ここではノード数が数十万〜数百万程度の大規模ネットワークを想定することにする。もちろん、ネットワークの規模が小さくても機能しなくてはならない。また、常時安定して稼動するためにはネットワーク障害にも強くなければならない。
【００４６】
視聴率などの精度もできる限り確保しなければならない。現在の日本でのある世帯視聴率調査では、例えば調査地域によって標本数を200または600に設定している。標本の抽出は国勢調査のデータをもとにランダムサンプリングで行っているが、TV局関係者のいる世帯や病院、事務所などの施設は除外して視聴率の正当性も考慮している。これによって得られる視聴率の誤差は、視聴率が50%のときに±7%または±4%程度(信頼度95%)である。そこで、本実施の形態で考案する情報集計アルゴリズムも、集計結果の誤差を少なくとも±4%以下に抑えられる方式とする。
また、本実施の形態では各ユーザのTVがP2Pネットワークでつながることを考えており、その場合、ユーザからTV局関係者などを除外して情報を集めることは困難である。そのため正確なサンプリングを行うことはあきらめ、代わりに標本数を現行の調査よりも増やすことで集計結果の正当性低下を補う。そこで、考案する情報集計アルゴリズムは、ある程度多数のユーザの情報を集計できるようにする。
【００４７】
以上をまとめると、以下のような機能及び性能が必要となる。
・番組ごとに視聴率のような比率が計算できる
・リアルタイムに集計できる
・ユーザ数が数十万〜数百万の大規模なネットワークでも機能する
・ネットワーク障害に強い
・視聴率などの誤差を±4%以下に抑えられる
・多数のユーザの情報を集計できる
【００４８】
（P2P情報集計アルゴリズム）
次に、以上で明らかにした要求をできる限り満たす情報集計アルゴリズムを提案する。
（単純な情報集計方法）
P2Pで多数のユーザの情報を集計する最も単純で基本的な方法は、1つのノード(ユーザ)が全ての集計を引き受けるという方法である（図６参照）。集計したいデータの数だけノードを選択し、後は選択したノードからデータをもらい集計すればよい。集計結果はブロードキャストすることで、全てのノードが集計結果を得ることができる。
しかし現実にこのような方法は利用できない。集計しているノードの負荷が大きすぎ、さらにそのノードが故障したらその時点で集計は失敗する。
そこで以下に、安定性や負荷の分散も考慮し、全てのノードが集計を行い且つお互いに協力する方法を提供する。
【００４９】
（P2P情報集計アルゴリズムの概要）
提案する情報集計アルゴリズムの仕組みを図７に簡単に示す。ノード間の矢印は情報の流れを表している。
【００５０】
基本的な考え方は次の通りである。各ユーザは定期的に自分の周りのノードから情報を集めてそれを集計している。すると、自分の周りのノードは、さらにその周りのノードから情報を集めて集計していることになる。そこで、自分の周りのノードからそれらの集計結果も一緒に取得する。例えば、図７ではノード1はノード2〜7から情報を集めている。同様にノード6はノード11〜12の情報を、ノード7はノード8〜10の情報を集めている。よってノード1は、ノード2〜7の情報に加えて、ノード6とノード7が集めたノード8〜12の情報(の集計結果)も同時に得ることができる。さらに言えば、ノード8がノード13〜16の情報を集めているので、ノード13〜16の情報(の集計結果)も同時に集めることができる。このとき、ノード1から見て自分自身の情報を0次情報、ノード2〜7の情報を1次情報、ノード8〜12の情報を2次情報、ノード13〜16の情報を3次情報と呼ぶことにする。もちろん、それ以上の4次情報、5次情報といったものもあり得る。なお、ここで言っているノードの情報とは、上述したような、各ユーザのインフォーマル情報を数値で表したもののことである。
【００５１】
この方法によって、ネットワーク上の膨大な量の情報を効率的に集計することができる。ただし、他のノードからもらう集計結果がその時点ですでに集計されているデータであるため、集めたデータには時間的なずれが生じている。よって、1次情報よりも2次情報の方が古く、2次情報よりも3次情報の方が古い情報となってしまい、言い換えると、遠くのノードから集めた情報ほど古い情報になっている。
【００５２】
また、集めたデータに重複が生じることも考えられる。例えばノード6がノード8の情報も集めていたと仮定する。するとノード1は、ノード6が集めたノード8の情報と、ノード7が集めたノード8の情報を重複して受け取ることになる。この問題については後に述べる。
【００５３】
（送信リンクと受信リンク）
各ノードは、他のノードと送信リンク及び受信リンクを張ることができる(図７におけるノード間の矢印がそれに当たる)。送信リンクとは、あるノードが他のノードにデータを送信するときの伝送路である。受信リンクは、逆に他のノードからデータをもらうときに使用する伝送路のことである。よって、例えばノードAがノードBとの間に張った受信リンクは、ノードBにとってはノードAに対する送信リンクである。
【００５４】
各ノードは、送信リンク及び受信リンクをあらかじめ決められた数だけ他のノードとの間に張ることができる。ただし自分から他の1つのノードに対して張れるリンクは1本のみとし、さらに、自分から他のノードに張ることができるのは受信リンクのみとする。送信リンクについては、他のノードが自分に対して受信リンクを張ることによって持つことができる。よって、他のノードが自分に対して受信リンクを張ろうとしなければ、全く送信リンクを持たないこともある。なお、どのノードと受信リンクを張るかは完全にランダムとする。また、すでに決められた数だけ送信リンクが張られているノードに対しては、受信リンクを張ることはできないとする。
各ノードは、定期的に自分が持っているデータを送信リンク先の全てのノードに送信する。逆に受信リンク先のノードにデータを要求することはせず、他のノードから受信リンクを通してデータが送られてくるのを待ち続けるのみとする。ただし、一定時間待ってもデータが送られてこない受信リンクは切断し、他のノードとの間に新たに受信リンクを張りなおす。
【００５５】
（データの集計）
周りのノードから集めたデータの集計計算の様子を図８に示す。
図８では、4つの領域に分かれた長方形は各ノードが持つデータを表し、それぞれの領域に0次情報〜3次情報が格納されている。集計計算は、集めたデータのn次情報同士を集計して集計結果のn+1次情報の領域へ格納することによって行う。集計結果の0次情報には最新の自分の情報を格納しておく。他のノードにデータを送信するときは、この集計結果のデータを送ることになる。もちろん、最初にネットワークに参加した時点では、まだ他のノードからデータを集めていないので、データを送信する際は0次情報(自分の情報)のみが格納されたデータを送信することになる。
なお、本実施の形態では0次情報〜n次情報を持つデータのことを”次数n+1のデータ”と呼ぶことにする。
【００５６】
（データの遅延）
データの集計方法から明らかなように、集計したデータにはデータの遅延が生じている。基本的には、n次情報よりもn+1次情報の方が古いデータになっている。例えば、各ノードが1分ごとにデータを送信しているとすると、集計結果の0次情報には現在の情報(自分の情報)、1次情報には1分前の情報、2次情報には2分前の情報、3次情報には3分前の情報が含まれていることになる。すなわち、データの送信間隔をt [sec]とすれば、d次情報が得られるのはt×d [sec]後となる。
データ量はn次情報よりもn+1次情報の方が大きくなっているので、より多くのデータを使って精度の良い結果を得るには、より古いデータを使うことになる。よって提案した情報集計アルゴリズムでは、完全にリアルタイムな集計はできない。しかし、各ノードのデータ送信間隔を短くすれば、よりリアルタイム集計に近づけることは可能である。ただし、送信間隔が短くなればその分ネットワークトラフィックも増加することに注意する必要がある。
【００５７】
（精度）
次に、提案した情報集計アルゴリズムを利用した場合に得られる結果の精度について考察する。
（収集データ量）
集計結果である視聴率などの精度は、収集したデータ量で決まる。より多くのデータを用いて計算すれば、その分誤差も小さくなる。よって、まず最初に提案したアルゴリズムで収集できるデータの量を見積もることにする。
収集できるデータ量はリンク数と次数で決定される。各ノードの送信リンク数及び受信リンク数を共にL、データの次数をdとすれば、集計結果の1次情報としてLノード分のデータが、集計結果の2次情報としてL2ノード分のデータが、集計結果のd次情報としてLdノード分のデータが収集できることになる。すなわち、収集できる全データ量は式(5・1)のようになる。
【００５８】
【数１】
【００５９】
例えば、L=4、d=3とすれば、集計結果の3次情報として、4096ノード分の情報の集計結果を得られることになる。ただしこれは、全てのノードが受信リンクを4つ張っている状態での結果である。実際には、各ノードの受信リンク数および送信リンク数の最大値を共に4としてしまうと、受信リンクを全て張れないノードも出現する可能性がある。各ノードが受信リンクを張れば張るほど送信リンクに余裕のあるノードが減少するからである。よって、各ノードの送信リンク数の最大値を受信リンク数の最大値よりも大きな値に設定するなどの対策が必要である。
【００６０】
次に、視聴率の精度は収集データの量によってどの程度変化するか調査する。視聴率のような標本比率の誤差(信頼度95%)は式(5・2)から得られることが知られている。
【００６１】
【数２】
【００６２】
式(5・2)を用いると、標本比率の誤差は表２のようになる。
【００６３】
【表２】
【００６４】
現行の視聴率調査では標本数は600程度であるが、この表からそのときの視聴率の誤差は比較的大きいことが分かる。一方、標本数が4096であれば視聴率の誤差は現行の誤差の半分以下となることが分かる。
提案した情報集計アルゴリズムでは、パラメータdを大きくすれば収集できるデータの量も急激に増加するので、視聴率の誤差は十分小さく抑えることが可能である。
【００６５】
（重複データ）
上記したように、この情報集計アルゴリズムではデータを重複して集計してしまう可能性がある。特に、ネットワークの規模が小さいとデータの重複も生じやすい。しかし、データが重複するからといって必ずしも集計結果がでたらめな値になるわけではない。例えばノードの総数を集計する場合はおかしな集計結果になってしまい、この情報集計アルゴリズムは役に立たないが、本実施の形態で求めたいデータは「何人中何人が番組を見ているか」や「何人中何人が番組に満足したか」といった”比率”のデータである。その場合、ランダムなネットワークを構築することで、提案した情報集計アルゴリズムでも正しい結果が得られると考えられる。これは、各ノードのデータが同程度に重複して集計されても、視聴率などの比率はほとんど変わらないためである。例えば100人中10人が番組を視聴している場合(視聴率10%)、重複して1000人分のデータを集めたとしても、結局そのうちの約100人が視聴していることになって視聴率はほぼ同じ10%となる。
【００６６】
しかし、それでも多少は本来の視聴率よりも誤差が大きくなってしまうことは避けられない。そこで、式(5・2)にデータの重複率を導入して、データに重複がある場合の誤差を導く。
まず、重複を含めてS人分のデータを収集し、そのうちs人が番組を視聴していたと仮定する。次に、データSの内、重複して収集したデータをM、その残りをNと仮定する。さらに、N人の内のn人と、M人の内のm人が番組を視聴していたとすると、視聴率は式(5・3)のように表せる。
【００６７】
【数３】
【００６８】
ここで、Rは重複データがない場合の視聴率、R’は重複データの視聴率、αは収集データの重複率である。以下、本論文ではデータの重複率をα＝M/N として説明する。重複率＝M/(N+M)でないことに注意する。
【００６９】
よって視聴率の誤差Eは、式(5 2)及び式(5 3)から
【数４】
と導くことができる。この式(5・4)を用いて具体的に誤差を計算すると表３のようになる。なお、図９はN=4096において式(5・4)をグラフ化したものである。重複率が0.1前後のときに最も誤差が大きくなっていることが分かる。
【００７０】
【表３】
【００７１】
表３を見ると、データに重複があっても誤差はほとんど増えないことがわかる。よって、提案した情報集計アルゴリズムにおいて、データの重複率はさほど問題ではないことが分かる。
【００７２】
（トラフィック）
本システムは大規模なP2Pネットワーク上で動作させることを前提としている。そのため、情報を集計する際にネットワークを流れるメッセージ数がどの程度になるか、事前に見積もることが重要になる。
提案した情報集計アルゴリズムの場合、受信リンクの数をL、やり取りするデータのサイズをm [bit]、時間T [sec]後にd次情報を得られるとすると、各ノードのネットワークトラフィックは(5・5)式のようになる。
【００７３】
【数５】
【００７４】
次に、このトラフィックを小さく抑えられるようなLとdの値を求める。
まず式(5・4)から、視聴率の誤差は視聴率が50%のときに最も大きくなることが分かる。ここで、そのときの誤差を1%以下程度に抑えることを考える。現行の視聴率調査での誤差が約4%であるので、誤差が1%以下ならば十分な精度と言える。そこで、式(5・4)から重複率が0.1で視聴率(50%)の誤差が1%になるサンプル数Nを求めてみると約14000になる。よって、重複データも考慮して約15000人分のデータを集められれば、誤差を1%以下に抑えられることになる。ただし、実際のネットワークでは、ノードの離脱などによって収集できるデータ量は理論値よりも小さくなるので、そのことも考慮して最大約30000人のデータを集められるようなパラメータを設定しておけば十分だと考えられる。
表４はd次情報として30000以上のデータを集められるような受信リンク数Lと次数dの組を示したものである。
【００７５】
【表４】
【００７６】
表４から、トラフィックが最も小さくなる受信リンク数Lの値は2または３である。しかし、受信リンク数Lが小さすぎると、受信リンクを1本張れないだけで収集データ量が急激に減少してしまう恐れがある。そこでそのようなリスクを分散させることができ、かつトラフィックも小さい、受信リンク数L=4、次数d=8の組を本情報集計アルゴリズムでは採用する。その場合、もし時間T=60 [sec]ならば、トラフィックは0.53m [bps]ということになる。
【００７７】
（耐障害性）
本実施の形態に係る情報集計アルゴリズムは、基本的には常時ネットワークに繋がっているシステムを想定している。そのため、頻繁にネットワークから離脱したりするノードはそれほど多くないが、大規模なネットワークで常に安定して動作するためには、耐障害性に優れていることが求められる。
本実施の形態に係るアルゴリズムは、ピュアP2Pネットワークで動作する。そのため、ネットワーク障害には比較的強いものになっている。例えば、突然受信リンク先のノードがネットワークから離脱したとする。その場合、単に代わりのノードを探して受信リンクを張りなおせばよい。各ノードの送信リンク数の最大値を大きく設定すれば、受け付けられる受信リンクの数にも余裕ができて、代わりのノードは見つかりやすくなるはずである。仮に、代わりのノードを見つけるまでに時間がかかってしまった場合でも、集計したデータには古いデータも含まれているので(どれだけ古いかはデータの次数による)、現在得られた集計結果からある程度昔のデータを補間することも可能である。
【００７８】
（P2P番組推薦システム）
次に、ジャンルとバリューを利用した番組推薦システムの実現方法について述べる。なお、推薦対象の番組は、放送中の番組、過去の番組、未放送の番組とする。
【００７９】
（ジャンルによる番組推薦）
本実施の形態では、ジャンルを利用した番組推薦に従来の推薦手法であるコンテンツベース推薦を用いる。コンテンツベース推薦は、ユーザの視聴履歴からユーザの嗜好を抽出して、その嗜好にあった番組を推薦するというものである。
【００８０】
（ユーザの嗜好）
各ユーザは番組視聴に関して自分の嗜好を持っている。例えば、スポーツ番組を好んで視聴するユーザもいれば、ドキュメンタリー番組を好んで視聴するユーザもいる。コンテンツベース推薦では、このようなユーザの嗜好を利用して番組推薦をする。
本システムでは、ユーザの嗜好をワードリストで表現する(表５)。ワードリストは単語とその出現頻度の組から成り、これは番組のEPGを利用して作成する。具体的には、リモコンに”Goodボタン”と”No-Goodボタン”を用意し、Good/No-Goodボタンが押された番組のEPG情報のワード列を単語に分解して抜き出し、ワードリストに登録する。ワードリストは各単語の出現頻度の情報も持っており、GoodボタンによってEPGから抽出された単語は出現頻度を1増やし、No-Goodボタンによって抽出された単語は出現頻度を1減らす。このようにして作られるワードリストはユーザの嗜好そのものとなる。なお、Goodボタンはバリューの満足度の入力としても利用する。
【００８１】
【表５】
【００８２】
ユーザの好きなジャンルの番組を推測するために、ユーザのワードリストと番組のEPG情報のワード列(をワードリストに変換したもの)との類似度を計算する。この類似度計算は、まず各単語間で類似度を計算し、その次にワードリスト間で類似度を計算するという2段階の手続きを踏む。
単語間の類似度の計算には、例えば株式会社日本電子化辞書研究所のEDR電子化辞書の概念辞書と英語単語辞書を利用する。概念辞書には概念の上下関係がツリー構造で記述されている。英語単語辞書には、英単語と概念の対応関係が記述されている。
単語間の類似度計算は、まず英語単語辞書で2つの単語の概念を引き、次に概念辞書のツリーにおけるそれら概念間の距離を計算する。この距離をNp、ツリーの高さをDとするとき、次の式(6・1)で単語間の類似度を計算できることが知られている。
【００８３】
【数６】
【００８４】
次にワードリスト間の類似度の計算のために、まず長い方のワードリスト内の単語から、短い方のワードリスト内の各単語と類似度の高いものを抽出して、新たなワードリストを作成する。この新しいワードリストは短い方のワードリストと同じ長さである。そして、新しいワードリスト(各単語の出現回数の値と類似度をかけた値)と短い方のワードリスト(各単語の出現回数の値)をベクトルとしてその内積を計算し、そのなす角を求める。この角度が小さければ、その番組はユーザの嗜好に合っていることになる。
【００８５】
（バリューによる番組推薦）
次に、番組推薦に利用するバリューについて詳細な説明を行う。
（バリューの種類）
以下のバリューが番組推薦に利用できる。
・番組の人気度(視聴率)
・番組の性質
・番組に対する期待度
・番組に対する満足度
・番組に対する感情
【００８６】
このうち、人気度、期待度、満足度は1つの値として算出できるが、性質と感情は、複数の値を持ち得る。そこで、本論文では性質と感情の種類を以下のように定義する。
「性質」
・子供に見せたくない
「感情」
・嬉しい
・楽しい
・悲しい
・苛立ち
・恐怖
性質と感情については、これら1つ1つに対してその度合いを算出する。なお、人気度は番組視聴人数をサンプル数で割ることで算出し、それ以外の期待度、満足度、性質、感情は、集計した値を番組視聴人数で割ることで算出する。すなわち、番組を視聴していたユーザのうち何%が満足したかといった値が得られる。
【００８７】
（情報の入力）
バリューを求めるためには、通常の視聴履歴から得られる情報のほかに、各ユーザが番組に対してどの程度満足したか、番組に対してどんな感情を抱いたかといった情報を集計する必要がある。
このような情報の取得方法には、キーボードによるテキスト入力、あるいは笑い声などの音声や表情から感情を取得するといった方法が考えられる。しかし、表情認識は今の段階では技術的に難しく、音声入力はTVの音声とかぶってしまう。また、キーボードは誰もが使いこなせるわけではなく、そもそも受動的なメディアであるTVに対して積極性が求められるキーボードは向いていない。TVに向いている入力手段は、リモコンのようにだれでも気軽に入力できるものである。例えば、”Goodボタン”があれば番組に対する満足度を簡単に入力でき、”嬉しいボタン”や”悲しいボタン”をリモコンに用意すれば、番組に対する満足度や感情を簡単に入力することができる。どのボタンが何回押されたかという情報から、簡単にユーザのインフォーマル情報を数値化することもできる。よって、本実施の形態では情報の入力手段としてリモコンを想定する。情報入力の対象は、番組全体あるいは番組の一部分(ピンポイント)が考えられるが、本実施の形態では”この番組のこの瞬間”という風にピンポイントに情報を入力することにする。
ところで、近年TVの高機能が進み、リモコンのボタンも非常に複雑になってきている。通常のリモコンのほかに、必要最低限のボタンのみのリモコンを用意するケースもある。よって単純にボタンを増やすことは望ましくない。
【００８８】
（ユーザのプロフィール）
多数のユーザが番組を評価することによって得られるバリューは、全ユーザの総意を知るのに良い指標となるが、さらにユーザのプロフィールも同時に考慮するとより効果的な推薦が可能になる。例えば男性ユーザに関して、好みの異なる女性ユーザのデータを除外したほうが有効な結果を得られることがあるだろう。あるいは、同世代のユーザに人気のある番組を知りたいといった場合や、地元のユーザに人気のある番組を知りたいといった場合も、ユーザのプロフィールを利用することで知ることができる。
番組推薦に効果的に利用できるユーザプロフィールは以下のようなものである。
・年齢
・性別
・地域
情報集計では、10代の人気度・満足度・感情、20代の人気度・満足度・感情、・・・のように、プロフィールごとに情報を集計すればよい。ただし、集計データのサイズはプロフィールの長さ(次元数)がnならばn倍となる。
ここに挙げたプロフィール以外にも多数のプロフィールが考えられるが、これはユーザのプライバシーに深く関わる問題であり、特に個人を特定できるような情報は避けなければならない。
【００８９】
（データレベルのクラスタリング）
上記では、年齢別、性別、地域別のバリューにも利用価値があることを述べた。ここではそれらに加え、ユーザの嗜好別バリューを算出する方法を説明する。
バリューによる番組推薦において、自分と嗜好が似ているユーザの情報を利用することは非常に有効である。なぜなら、ユーザにとって自分と嗜好が似ているユーザによる番組評価は、多様な嗜好のユーザによる番組評価よりも自分と似ており信頼できるからである。以下ではそのような情報の集計方法を検討する。
【００９０】
従来のP2Pファイル共有ソフトでは、ファイル共有の効率を高めるために、ネットワークレベルで嗜好のクラスタリングを行っているものがある。すなわち、嗜好の似た者同士をネットワーク的に近い位置に配置している。このようなクラスタリングを行えば、嗜好が似ているユーザから情報を集めることが可能である。
しかし、提案した情報集計アルゴリズムでは、このようなクラスタリングを行っても意味がない。なぜなら、この情報集計アルゴリズムはランダムなネットワークを前提としているからである。クラスタリングをしてもネットワークに偏りが生じてしまえば正しい集計結果は得られない。そこで本実施の形態では”共通ジャンルリスト”を導入する。共通ジャンルリストとは、あらかじめ決められた全ユーザに共通の嗜好ワードとその値の列である(表６参照)。例えば、”SF”や”サッカー”といった単語を共通ジャンルとして設定する。
【００９１】
【表６】
【００９２】
各ユーザは共通ジャンルリストを以下のように作成する。
まず各ユーザは、自分の嗜好ワードリストから共通ジャンルに対する嗜好の度合いを0〜1の値に変換し、共通ジャンルリストの値として設定する。これを一時共通ジャンルリストと呼ぶことにする。次に、その値が大きいものは1、それ以外は0とする共通ジャンルリストを作成する(図１０参照)。すなわち、各ユーザは自分の好きな共通ジャンルの値を1に設定する。値を0か1に変換するのは、ユーザの共通ジャンルに対する嗜好をよりはっきりと区別させるためである。
【００９３】
情報の集計はこの共通ジャンルリストの値を加算していくことで行う(図１１参照)。集計の方法はユーザプロフィールを利用する場合と同様である。各バリューの集計を、さらに共通ジャンルごとの集計に細かく分けて行う。例えば共通ジャンル1に関する視聴率、共通ジャンル2に関する視聴率、共通ジャンル1に関する満足度、・・・のように集計を行う。
【００９４】
こうして得られた集計結果からは、番組Aを視聴しているユーザのうち、共通ジャンル1が好きなユーザは何人、共通ジャンル2が好きなユーザは何人、・・・といった情報を得ることができる。これはすなわち専門家によるバリューが得られるということでもある。例えば、ある映画についてSF映画好きなユーザはこの映画をどのように評価しているか、ということが分かる。
さらにこの集計結果を用いて、各ユーザの嗜好に即したバリューを得ることもできる。それには、ユーザの一時共通ジャンルリストを利用する。一時共通ジャンルリストはユーザの共通ジャンルに対する嗜好を表しているので、共通ジャンルリストの集計結果と一時共通ジャンルリストの内積をとることで、ユーザの嗜好を考慮したバリューが得られる。すなわち、自分と嗜好が似ているユーザの情報から算出するバリューを、このような方法で近似できる。
共通ジャンルリストの長さ(次元数)を増やせば、より精度の高いバリューが得られることになるが、その場合は集計データのサイズも増加することに注意する必要がある。共通ジャンルリストの次元数をmとすればデータサイズは元のデータ(ユーザプロフィールを除く)のm倍、ユーザプロフィールの次元数nも考慮すれば、データサイズはn+m倍になる。
【００９５】
（集計データ）
以下のデータは、情報集計の際にやり取りする、放送中番組に関する集計データの一部である。ユーザプロフィール、共通ジャンルは考慮していない。各ユーザは自分の視聴履歴を15秒おきに記録するものとする。よって1分間に4つのデータが作られる。また、データ送信間隔を60秒、次数を3とすれば、3分前までのデータを集計することになるので、合計12個のデータを持つ。
【００９６】
＜番組ID＞ ABC
＜サンプル数＞ 1,2,3,4,5,6,7,8,9,10,11,12
＜視聴人数＞ 1,2,3,4,5,6,7,8,9,10,11,12
＜満足度＞ 1,2,3,4,5,6,7,8,9,10,11,12
＜期待度＞ 1,2,3,4,5,6,7,8,9,10,11,12
＜嬉しい＞ 1,2,3,4,5,6,7,8,9,10,11,12
＜楽しい＞ 1,2,3,4,5,6,7,8,9,10,11,12
＜悲しい＞ 1,2,3,4,5,6,7,8,9,10,11,12
＜苛立ち＞ 1,2,3,4,5,6,7,8,9,10,11,12
＜恐怖＞ 1,2,3,4,5,6,7,8,9,10,11,12
＜子供に見せたくない＞ 1,2,3,4,5,6,7,8,9,10,11,12
【００９７】
12個の数字のデータが集計中のデータである(ここで示した数字に意味はない)。一番左のデータが3分前、一番右のデータが現在のデータである。次数を3としているので、3分以上前のデータは切り捨てている。集計データには、このようなデータが放送中の番組の数だけ含まれることになる。
受信リンク数を4に設定すれば、60秒間にこのような集計データを4つ受け取る。受け取った集計データは、同じ番組同士でデータを加算することによって集計を行う。この集計結果から番組の人気度、満足度、感情、性質の値を算出することになる。
放送中の番組ではなく録画番組に関するデータの場合は、3分間のデータではなく、番組の開始から終了までのデータを集計する必要がある。なぜなら、録画番組はバラバラに視聴されるからである。録画番組Aを30分前から視聴しているユーザもいれば、録画番組Aを視聴し始めたばかりのユーザもいるかもしれない。その場合、3分間のデータだけ集計しても意味がない。
なお、録画番組に関しては、その番組が放送中のときに視聴データをすでに集計しているはずである。よって、録画番組として集計して得たデータは、すでに持っている放送中に集計された集計結果に足し合わせていくことになる。これによって、例えば放送中のときは満足度が低かったが、数ヶ月経ってみたら満足度がとても高くなっていた、ということも起こり得る。
一方未放送の番組に関しては、そもそも期待度しか計算できないので、集計するデータは<サンプル数>と<期待度>のデータのみになる。
上に示したデータにユーザプロフィールと共通ジャンルを導入すると集計データは以下のようになる。
【００９８】
＜番組ID＞ ABC
＜サンプル数＞ 1,2,3,4,5,6,7,8,9,10,11,12
＜視聴人数＞ 1,2,3,4,5,6,7,8,9,10,11,12
＜男性＞ 1,2,3,4,5,6,7,8,9,10,11,12
＜女性＞ 1,2,3,4,5,6,7,8,9,10,11,12
＜１０代＞ 1,2,3,4,5,6,7,8,9,10,11,12
＜２０代＞ 1,2,3,4,5,6,7,8,9,10,11,12
＜共通ジャンル1：SF＞ 1,2,3,4,5,6,7,8,9,10,11,12
＜共通ジャンル2：サッカー＞ 1,2,3,4,5,6,7,8,9,10,11,12
：
＜満足度＞ 1,2,3,4,5,6,7,8,9,10,11,12
＜男性＞ 1,2,3,4,5,6,7,8,9,10,11,12
＜女性＞ 1,2,3,4,5,6,7,8,9,10,11,12
：
【００９９】
導入するプロフィール、共通ジャンルの数は、データのサイズ(トラフィック)がどれだけ増えるかを考慮して決める必要がある。録画番組のデータを集計する場合は、番組数が決まっている放送中の番組と違って番組数が無数になるため、特にデータのサイズに注意する必要がある。
そもそも無数に存在する録画番組をすべて集計することは不可能である。例えば、1万人分のデータを集めた場合、最悪1万個の録画番組データを集計することになる。このような場合は、データ集計中に番組数が一定の数に達したら番組データを切り詰める、という処理を行う。ユーザにとって必要な番組のデータは残し、必要でない番組のデータは捨ててしまうようにする。ユーザにとって必要な番組とは、何らかの理由でその番組が放送中のときに十分な視聴データを集められなかったものである。逆に必要でない番組は、すでに十分な視聴データを集められている番組である。
録画番組の集計データは、たとえ番組数を切り詰めても放送中番組の集計データに比べるとかなり大きくなってしまう。しかし放送中番組と違って、録画番組にはリアルタイム性は必要ない。よって、放送中番組と録画番組で同じデータ送信間隔を設定する必要はなく、放送中番組のデータ送信間隔は短く設定し、録画番組のデータ送信間隔は長く設定することで、トラフィックが抑えられ効率的な情報集計が可能になる。
【０１００】
（画面インタフェース）
次に、実際のTV視聴シーンにおける番組推薦インタフェースについて説明する。
（ブラウジング）
ブラウジングとはユーザが情報の一覧を眺めながら欲しい情報を取り出すというものである。ブラウジングを効率的に行うには、情報の視覚化が有効である。
本システムでは、各番組ごとにその番組のジャンルとバリューをグラフで表示することで、ユーザはどの番組が自分の好みと合っていて、どの番組がどんなユーザから高い評価を得ているかということが一目で分かるようにする。その結果ユーザは簡単に見たい番組を探せるようになる。このようなブラウジング主体の表示は、本システムでは主に3つのシーンに分かれる。1つ目は番組視聴中の表示、2つ目は録画番組一覧での表示、3つ目は番組表閲覧時の表示である。
【０１０１】
1つ目の番組視聴中の表示例を図１２に示す。また、現在試作中のプロトタイプシステムの画面を図１３に示す。番組放送画面では図１２のように、画面の右隅に視聴中の番組および他チャンネルの番組のジャンルとその瞬間のバリュー(ここでは人気度)を表示する。ユーザは現在の番組を視聴しながら、他チャンネルの番組のバリューが刻々と変化する様子を確認できる。さらに画面下には視聴中番組の人気度(視聴率)の変遷やその他のバリュー(満足度や感情など)を表示する。他のユーザが満足ボタンや感情ボタンなどを押せばその結果がほぼリアルタイムに画面下のグラフに反映され、他のユーザが今の番組に対してどのように思っているのかが確認できる。特にスポーツ番組などは、盛り上がったシーンでボタン入力することで他のユーザと一体感を感じることができる。また、もし今の番組に満足できないようであれば、他チャンネルのジャンルとバリューを確認して、自分の好みの番組でかつ他のユーザからの評価も高い番組を見つければよい。
【０１０２】
2つ目の録画番組一覧での表示と3つ目の番組表閲覧時の表示は、番組視聴中に表示した情報を各番組に対して表示するだけである。すなわち、一覧の各番組の横にその番組のジャンルとバリューの棒グラフを表示し、一目で各番組のジャンルとバリューの値が分かるようにする。さらにどれかの番組を選択した場合には、その番組のバリューの変遷を画面下に表示することによって、ユーザはどの番組のどのシーンが面白いのかを簡単に見つけることができる。これによってユーザは本当に面白いシーンだけを”つまみ食い”することが可能になる。
【０１０３】
（番組推薦インタフェース）
ブラウジングは番組一覧の中から見たい番組を探すというものであった。しかし、ユーザに”こんな番組が見たい”という曖昧な要求がある場合は、それに即した番組推薦を行うべきである。そこで本実施の形態では図１４のような番組推薦インタフェースを提案する。
【０１０４】
ユーザは周囲に配置されたそれぞれのチェックボックスをチェックすることで、どんな番組を推薦して欲しいか指定する。図１４の例では、20代の男性の中で人気度、満足度、好み(ジャンル)、感情(楽しい)の度合いが高い番組を推薦してもらおうとしている。推薦結果の番組は中央にその評価の高い順に表示される。このようにしてユーザは単純なブラウジングよりも効率的に自分の見たい番組を見つけることができる。また、ここで設定した条件をブラウジングの画面表示に適用することも有効である。例えば、番組視聴中 (図１２)、録画番組一覧、番組表閲覧時におけるバリューとして、”20代の男性の中での人気度、満足度、感情(楽しい)の総合値”を表示すると、ブラウジング中でもユーザは効率的に自分の見たい番組を見つけることが出来るようになる。
【０１０５】
（シミュレーション実験）
次に、以上に提案した情報集計アルゴリズムのシミュレーション実験を行い、その性能について評価する。
【０１０６】
（実験の目的）
提案した情報集計アルゴリズムの評価をするために何十万人ものユーザで実験することは不可能である。そこで本実験では、シミュレーションによってトラフィックや各ノードにおける集計結果取得の様子および集計結果の精度などを調べることで情報集計アルゴリズムの評価を行う。そのために作成したシミュレータの概要を以下に示す。
・多数の仮想ノード間で提案した情報集計アルゴリズムと同等の処理を行う
・その際、各ノードは接続相手(受信リンク先ノード)を全ノードの中からランダムに選択する
・最大リンク数、次数、データ送信間隔は全ノードで共通である
・データの送信は全ノードが同期して一斉に行う
・データ送信間隔をシミュレーションの1ステップとする
・1ステップごとに決められた接続試行回数だけ他のノードに接続を試みる
・1ステップごとにノードの離脱率および参加率を設定できる
・1ステップごとにユーザの視聴行動を操作できる
(例えば番組Aを100人が視聴し、番組Bを200人が視聴している、という風に設定する)
・各ノードにおいて、1ステップごとに集計したデータから番組の各種バリューを算出することができる
このシミュレータは、情報集計の際のネットワークの分析と、各ノードにおけるバリューの算出可能性を確認できるように設計した。
【０１０７】
（接続リンク数）
上記したように、最大受信リンク数は4に設定した方が良いことが分かったが、最大送信リンク数は未定であった。最大受信リンク数と最大送信リンク数を共に4と設定すれば、理論的には全てのノードが受信リンクおよび送信リンクを4つずつ張れることになる。しかし実際には送信リンクに余裕があるノードをなかなか見つけられないノードが出てきてしまい、そういったノードは4つ全ての受信リンクを張ることは難しい。そうなると、それらのノードでは収集データ量が減少し、視聴率の精度の低下を招く。
この問題は、最大送信リンク数を最大受信リンク数よりも大きな値に設定することで解決できる。しかし逆に最大送信リンク数が大きすぎると、多数の送信リンクを保持するノードとほとんど送信リンクを保持しないノードが出てきて、ネットワークに偏りが生じる。このような偏りがあると、特定のノードのデータばかり多く重複して集計するといった事態が起きてしまう。これも視聴率の精度を低下させる要因である。よって、最大送信リンク数は最大受信リンク数よりも大きく、且つ出来るだけ小さい値が良いと考えられる。
以上のことを踏まえ、各ノードの受信リンク数が最大送信リンク数によってどのように変化するかを実験によって確かめた。図１５〜図１９は、ノード数を100000、各ノードの最大受信リンク数を4、他のノードへの接続試行回数を12(すなわち1ステップごとに12個のノードへ受信リンクを張ることを試みる)、としたときの各ノードの受信リンク数を調べたものである。値はシミュレーションを10ステップ行ったときの平均値として算出している。なお、1ステップごとに約1%のノードがネットワークから離脱およびネットワークへ参加する設定とした。
【０１０８】
図１５〜図１９のグラフを見ると、最大送信リンク数を最大受信リンク数よりも1増やすだけで、受信リンクを4つ保持しているノードは急激に増加し、逆に受信リンクが3つ以下のノードは急激に減少していることが分かる。また、最大送信リンク数を6以上に設定してもそれほど大きな変化は見られなかった。この事から、最大送信リンク数は最大受信リンク数よりも1だけ多い5と設定するのが良いと考えられる。あるいは、通常は最大送信リンク数＝最大受信リンク数としておき、各ノードの接続失敗回数に応じて動的に最大送信リンク数を変化させることも考えられる。これは例えば、接続試行回数12回の中で10回他のノードに接続を試みても受信リンクが1しか張れなかったノードに対しては、通常最大送信リンク数4のところを5に増やして特別に接続を許可する、というものである。
【０１０９】
（データ収集量）
次に、ノードのネットワークからの離脱やネットワークへの参加を考慮したときの各ノードの収集データ量を調べる。
図２０は、ノード数を100000、最大受信リンク数を4、最大送信リンク数を5、次数を8、他のノードへの接続試行回数を12としたときのシミュレーション結果である。縦軸が収集データ量、横軸がノード離脱率およびノード参加率を表している。ノード離脱率および参加率は、全ノードのうち何%のノードがネットワークから離脱または参加するかを表したものである。ここではシミュレーションを1ステップ進める度にノードの離脱および参加が起こるものとした。なお、ノード離脱率とノード参加率は同じ値に設定した。
図２０は、シミュレーションを10ステップ実行したときの、任意のノードの第8次データ量の平均を示している。このときの理想の収集データ量は48 ＝65536であるが、ノード離脱率1%で60000以上、ノード離脱率5%でも収集データ量が40000以上と、相当数のデータを収集できていることが分かる。
【０１１０】
（ネットワークトラフィック）
図２１に示したグラフは、上記と同じ条件でシミュレーションを行ったときの、1ステップ当たりの各ノードの平均データ送信回数である。
最大受信リンク数を4としているので各ノードは平均して4つの送信リンクを持つことになり、理論的には、各ノードは1ステップ当たり4回データを送信することになる。離脱率変えた場合の結果が図２１であるが、離脱率が増えてもデータ送信回数はそれほど減少していないため、安定してデータ集計が行われているということでもある。
シミュレーションの1ステップをs [sec]とし、データのサイズをm [bit]とすれば、各ノードに要求される通信帯域幅は約4m/s [bps]と見積もることができる。例えば、s=10 [sec]、m=100K [byte]ならば、通信量は320K [bps]となる。よって、データサイズが大きいとネットワーク回線を圧迫してしまう恐れがあるため、データを圧縮したり、必要な情報のみ集計するような工夫が必要である。
【０１１１】
（データ重複率）
続いて、ノード数によってデータの重複率がどのように変化するか調べる。
シミュレーションは、受信リンク数4、送信リンク数5、次数8、接続試行回数12、ノード離脱率(=ノード参加率)1%という条件で行う。重複率は第8次データに関する重複率を調べるものとする。集計結果の第8次データは8ホップ先のノードの情報を集めたものである。よって、特定のノードから受信リンクを辿って8ホップ先のノードがどれだけ重複しているかを調べれば、その特定ノードの第8次データのだいたいの重複率を見積もることができる。もしノードの離脱、参加がなくネットワークのリンク構造が変化しなければ、求めた重複率は正確なデータ重複率となる。図２２はノード数を変化させてシミュレーションを行ったときの重複率である。
【０１１２】
この結果から、ノード数がn倍になるとデータ重複率は約1/n倍になっていることが分かる。よって、大規模なネットワークでは重複率はほとんど無視できることが分かった。本実施の形態では、集計結果としてデータ重複の影響をほとんど受けない比率のデータを求めていたが、大規模なネットワークではデータ重複がほとんど生じないことが確認できたため、そのようなネットワークでは比率以外のデータも取得できる可能性がある。
【０１１３】
（精度）
ここでは集計で得られた視聴率の精度を調べる。
まずは、各ノードで得られる視聴率の精度が、時間の経過によってどのように変化するかを確かめる。シミュレーションの条件は7.5節と同じである。ただしノード数は10万とし、ユーザの視聴状況も以下のように設定した。カッコ内の数値はその番組の真の視聴率である。
・番組A：5000人（視聴率5%）
・番組B：10000人（視聴率10%）
・番組C：20000人（視聴率20%）
・番組D：50000人（視聴率50%）
・未視聴：15000人
なお、ユーザはシミュレーションの途中で視聴番組を変更しないものとした。
このシミュレーション結果を表７、表８と図２３に示す。表７は、シミュレーションの任意のステップにおいて、ランダムに抽出した100ノードの各次数データによる視聴率の平均をまとめたものである。表８は、そのうちの第8次データについての基本的な統計量を計算したものである。また図２３は、100ノードの各次数のデータによる視聴率の標準偏差をグラフにしたものである。
【０１１４】
【表７】
【表８】
【０１１５】
表７及び８から、ノードの離脱があっても第8次データを用いて計算すれば十分な精度の視聴率が得られることを確認できる。図２３では、次数の増加によって視聴率の精度が向上している様子が分かる。また、第6次データや第7次データでも良い精度の視聴率が得られているため、8ステップかけて第8次データを得なくても、6ステップまたは7ステップで視聴率を求めることもできる。
【０１１６】
（集計結果取得の様子）
本実施の形態で提案した情報集計アルゴリズムは、時間の経過とともに集計結果の精度が上がっていくという特長がある。ここでは、時間軸に沿ってユーザの視聴行動を制御し、そのような集計結果の変化を確認する。
シミュレーションの条件は、ノード数10000、最大受信リンク数4、最大送信リンク数5、次数8、接続試行回数12、ノード離脱率およびノード参加率1%、データ送信間隔10[sec]とする。また、ユーザの視聴行動は以下に示すように設定する。
【０１１７】
＜1〜3ステップの番組視聴状況＞
・番組A：500人（視聴率5%）
・番組B：1000人（視聴率10%）
・番組C：2000人（視聴率20%）
・番組D：5000人（視聴率50%）
・未視聴：1500人
【０１１８】
＜4〜5ステップの番組視聴状況＞
・番組A：1500人（視聴率15%）
・番組B：800人（視聴率8%）
・番組C：2500人（視聴率25%）
・番組D：4000人（視聴率40%）
・未視聴：1200人
【０１１９】
＜6〜ステップの番組視聴状況＞
・番組A：2000人（視聴率20%）
・番組B：900人（視聴率9%）
・番組C：2200人（視聴率22%）
・番組D：3800人（視聴率38%）
・未視聴：1100人
【０１２０】
上記において、カッコ内に示したのは、その時点での真の視聴率である。このシミュレーションの結果を図２４〜図２７に示す。図はシミュレーションの8ステップ目、10ステップ目、12ステップ目、14ステップ目に得られる任意のノードの集計結果をグラフで表したものである。横軸は時刻を表しており、右端が現在の時刻となる。また、グラフ中の黒い縦線は現在から6ステップ前の時刻、赤い縦線は現在から8ステップ前の時刻を示している。なお、紫で表示された”E”のグラフはTVを視聴していないユーザの割合である。
【０１２１】
番組Dのグラフに注目する。番組Dの真の視聴率は、tを時間とすると、0≦t＜30のとき50%、30≦t＜50のとき40%、50≦tのとき38%である。
図２４〜図２７の各図において、現在から6ステップ前の黒い縦線よりも右側のデータは、サンプル数が少なく信頼できるデータではない。
図２４は、8ステップ古いt=0での視聴率は精度よく求められているが、6ステップ古いt=20の視聴率は誤差が1.5%以上と大きくなってしまっている。しかし、その2ステップ後の図２５では、誤差が0.2%程度と小さくなっていることが確認できる。同様に、図２５のt=40における視聴率も誤差が約2.7%と大きいが、その2ステップ後の図２６では、誤差はほとんど0である。図２６においては、図２４で30≦t＜70の視聴率がでたらめであったものが、誤差も小さくきれいなグラフになっている。これらの結果から、時間が経過するにつれて視聴率の精度が上昇するという本情報集計アルゴリズムの特徴が確認できる。
【０１２２】
さらに今回のシミュレーションでは、4ステップ目で一部のユーザがGoodボタンを押すように設定した。Goodボタンを押したユーザの人数は以下の通りである。
＜4ステップ目にGoodボタンを押したユーザ＞
・番組A：200人（13.3%）
・番組B：300人（37.5%）
・番組C：400人（16%）
・番組D：500人（12.5%）
【０１２３】
上記において、カッコ内の数値は、各番組の視聴人数に対するGoodボタンを押したユーザの割合である。これらの数値が各番組に対する真の満足度になる。
シミュレーションによって得た集計結果を図２８〜図３１に示す。図は8ステップ目、10ステップ目、12ステップ目、14ステップ目に得られる任意のノードの集計結果をグラフにしたものである。横軸と赤、黒の縦線は上の視聴率のグラフと同様である。
【０１２４】
番組Bに注目すると、ステップを重ねるにつれて真の満足度である37.5%に近づいていることが分かる。しかし、最終的に得られた結果が36.430%と誤差1%ほどになってしまった。シミュレーション中は、1ステップごとに全ノードのうち1%のノードがネットワークからの離脱およびネットワークへの参加を繰り返しているため、たまたま自分の近くのノードが離脱してしまったと考えられる。しかし、それでも1%の誤差であれば十分な精度といえる。
【０１２５】
（実験のまとめ）
シミュレーション実験では、まず受信リンク数を出来る限りだけ多く保持できるような最大送信リンク数の値を調べた。その結果、最大送信リンク数は最大受信リンク数よりも1だけ大きい値が適していることが確認できた（図１５〜１９参照）。
次に、ノード離脱率を変化させたときのデータ収集量を調べた。その結果、ノード離脱率を高い値に設定しても十分な量のデータを集計できていることが確認できた。これは、常に安定してデータの集計が行えているということである。
次に、ノード離脱率を変化させたときの1ステップ当たりのデータ送信回数を調べた。結果は、ノード離脱率を高い値に設定してもデータ送信回数に大きな変化は見られなかった（図２１参照）。したがって、上記実験結果（図２０参照）と同じく、本情報集計アルゴリズムは耐障害性に優れており、安定した集計ができていると言える。
次に、ノード数を変化させたときのデータ重複率を見積もった。結果、大規模なネットワークではほとんど集計データの重複が生じないことが確認できた（図２２参照）。
次に、ノードの離脱を組み入れたときに実際にどの程度の精度で視聴率を求められるか確認した。結果、かなり高い精度で視聴率を求められることが確認できた（表７〜８、及び図２３参照）。
次に、シミュレーションを実行したときの集計の経過を確認し、集計結果の精度が時間の経過とともに変化する様子を確認した。シミュレーションではあるが、短いステップ数で十分な精度の視聴率を算出することに成功しており、大規模分散環境においても短時間で高い精度の視聴率を計算できる可能性を示せた（図２４〜３１参照）。
【０１２６】
次に、本実施の形態のまとめと今後の課題について述べる。
（まとめ）
本実施の形態では、従来の番組推薦手法で扱いきれていなかった「番組の質」も取り入れて、ユーザにより有益な番組を提示できるような新しい番組推薦手法の実現を目的とした。
最初に、番組推薦に利用する情報の分析を行った。その結果、従来から番組推薦に利用されてきたEPGがフォーマル情報であるのに対して、番組の質はユーザの正直な情報を集めたインフォーマル情報であることがわかった。そこで、コンテンツの評価軸としてフォーマル情報に対応する「ジャンル」と、インフォーマル情報に対応する「バリュー」を定義した。ジャンルはコンテンツの表面的な概要を表し、バリューは内面の質を表すものである。
バリューを算出するには、多数のユーザからインフォーマルな情報を集計しなければならない。そこで本実施の形態では、インフォーマル情報の集計に適したP2Pを利用して効率的に多数のユーザのインフォーマル情報を集計できる情報集計アルゴリズムを提案した。このアルゴリズムは大規模な分散環境において効率的に情報を集計できる。小、中規模なネットワーク環境においては集計データに重複が発生するが、集計結果を比率として得る場合には誤差がほとんど生じないことが分かった。
次に、バリューを用いたP2P番組推薦システムの実現方法を示し、TVの新しい視聴スタイルとなり得る画面インタフェースを提案した。
最後のシミュレーション実験では、情報集計アルゴリズムの性能を評価すると共に、視聴率などの集計結果の算出過程を観察し、実際の番組推薦システムにおける実現可能性を示した。
【０１２７】
（今後の課題）
提案したP2P番組推薦システムには、情報の入力に関していくつか課題が残る。まず１つ目は、情報の入力を全てリモコンのボタンに頼っていることである。瞬時に、且つ気軽で簡単に情報を入力する手段として、リモコンによるボタン入力は非常に優れている。しかし、単純に入力する情報の種類だけボタンを用意すれば、ボタンの数が増えすぎてしまい、ユーザは戸惑ってしまう。この問題を解決する１つの方法として、システムがユーザを観察して自動的に情報を入力することが考えられる。ユーザの感情をユーザの声や表情から取得する研究は多く行われている。このような技術が発展すれば、システムがユーザの気持ちを自動的に入力してくれるようになる。
2つ目の問題は、ユーザがTV視聴時にGoodボタンや感情ボタンを頻繁に入力するかという問題である。受動的なTVに対してユーザに情報を入力させるには、ユーザの情報入力に対するモチベーションを高めるような工夫が必要になる。例えば、情報入力をすることによって他のユーザとインタラクションができれば、ユーザのモチベーションも上がるかもしれない。この点に関してはさらに分析を行う必要がある。
3つ目の問題は、1台のTVを複数人で視聴する場合である。本実施の形態で提案したような情報推薦システムは、基本的に個人のユーザを対象とする。複数のユーザが同時に使用すると、ユーザの正確な嗜好が取得できなくなってしまうからである。また、他のユーザに自分の嗜好を知られてしまうというプライバシーの問題も生じる。これを解決する妥当な方法は、情報入力装置(リモコン)にユーザ機能を設けることだろう。これによってシステムは誰が情報を入力したか知ることができ、個々のユーザに対して処理を切り替えることができる。現在は、携帯端末で家電を操作できるようになりつつあるが、携帯端末は主に個人で携帯しているので、これを入力装置として利用することも考えられる。
【０１２８】
次に、本発明に係る情報集計アルゴリズムの他例について説明する。
ここではP2P による情報集計の具体的なアルゴリズムを説明する。目的は、周囲数千人程度のユーザからいい加減に、かつ効率的に情報を集めることである。なお、ここでは集計する情報を「各ユーザが1 分間の間何チャンネルを見ていたか」というものとする。すなわち集計結果として得られる情報は、各チャンネルの1 分ごとの視聴人数である。
【０１２９】
まず、各ノードが持つ情報は図３２に示すようなものである。（図３２中の丸付き数字については、以下、(1),(2)…と表す）
やり取りするデータの(1)、(2)、…には、各チャンネルごとに視聴人数をカウントしたものが入る。
ここで、d 次情報を持つデータを「次数d+1 のデータ」
と呼ぶことにする。
データ集計のアルゴリズムは以下のようになる。
“起動時”
・ サーバにつなぎ、自分のノートアドレスをサーバに登録する。
・ サーバから、すでに登録済みのノードアドレスをランダムにX 個教えてもらう。
・ そのうちK 個のノードアドレスを受信リンクに登録する。逆に、自分のノードアドレスを相手ノードの送信リンクに登録してもらう。（すなわち、他ノードから要求があるまで送信リンクは
張らない。）
“送信”
・ 1 分ごとに“集計”で作成したデータを送信リンク先のノードへ送信する。
・ このときデータのTTL を1 にセットする。
“転送”
受信リンク先のノードから受信したデータについて
・ 1 ホップ隣から来たデータ(TTL=1 のデータ)は、
TTL を1 増やして送信リンク先ノードに転送す
る。
・ 2 ホップ隣から来たデータ(TTL=2 のデータ)は、“集計”へ。
“集計”
・ 自分の情報を、送信するデータの(1)にセットする。
・ 受信したデータの(1)を全て加算して、送信するデータの(2)へセットする。
・ 受信したデータの(2)を全て加算して、送信するデータの(3)へセットする。
：
・ 受信したデータのd 次情報を加算したものが、得られる集計結果である（図３３参照）。
ただし、d 次情報は1 分前のd-1 次情報を使って計算しているので、集計結果には最大d 分前の情報が含まれる。
【０１３０】
このアルゴリズムではK(d+1)・TTL人分の情報を効率的に集めることができる。また、やり取りするデータのサイズは、基本的にデータの次数のみに依存する。
“転送”にて1 ホップ隣のノードから来たデータを素通りさせるのは、データを重複して集計することを防ぐためである。しかし、それでもデータの重複を完全に防げないことは容易に想像がつく。この重複率については後に述べる。
【０１３１】
（トラフィック）
本システムは大規模なP2P ネットワーク上で動作させることを前提としている。そのため、情報を集計する際にネットワークを流れるメッセージ数がどの程度になるか、事前に見積もることが重要である。
上のアルゴリズムの場合、全ノード数をN、受信リンク数をK とし、p ホップ先までデータを送信することにすると(TTL = p)、1 タイムステップ(1 分間)に流れるメッセージ数は、
【数７】
と見積もることが出来る。と見積もることが出来る。上のアルゴリズムはp を小さく取っても多くの情報を集められるので、パラメータの適切な設定によりトラフィックはある程度小さく抑えられる。
【０１３２】
（シミュレーション）
次に、上のアルゴリズムにおいて、重複して集計されたデータの数をシミュレーションにより調べる。
図３４は、受信リンク数及び送信リンク数を4、TTL を2、データの次数を3 としたときのシミュレーション結果である。ノード数が5000〜12000 のときのデータ重複率を示している。なお、このとき集められたデータ数はど
のノード数の場合でもほぼ4000 程度であった。
本システムはノード数が数十万、数百万といった大規模ネットワークを想定している。シミュレーション結果を見る限り、そのような大規模ネットワークでは重複はほとんど生じないことが予想される。そもそも、いい加減なインフォーマル情報の集計を目的としているので、重複を完全に無くすことにあまり意味はない。
もちろん、初期のノード数が少ないネットワークでは重複率が無視できない問題となるので、これについては今後の課題とする。
【０１３３】
（効率化）
上のアルゴリズムは、全てのノードが平等に仕事をしている。しかし、ノードの性能によって役割を分けた方が明らかに効率は良い。そこで、n 次情報の集計計算をさぼるノードを考える。この場合、受け取ったデータにn+1 次情報が存在するはずなので、それをそのままコピーし、n 次情報の集計結果とすればよい。ただし、古い情報を流用しているので、当然、最終的に得られる集計結果にもその分古い情報が含まれることになる。計算をさぼるノードが増えると、ネットワークを流れる情報は古い情報ばかりになってしまうのである。そのため、さぼるノードの数を確率的に制御するか、さぼるノードの送信リンク数を減らし古い情報の流通を抑えるかするなどの対策が必要になる。これについては今後分析を行っていく。
【０１３４】
（P2P 情報推薦システム）
本実施の形態では、デジタル放送に対応したセットトップボックス(STB)上にシステムの実装を進めている。
以下に、本システムの具体的な実現方法について説明する。
【０１３５】
（ジャンルによる番組推薦）
ユーザの好みの番組を推測するためには、ユーザの番組に対する嗜好を知る必要がある。そのため本システムでは、STB のリモコンに「Good ボタン」と「No-Goodボタン」を割り当て、番組を視聴中のユーザに、その番組が気に入ったか、気に入らないかを入力してもらうことにした。
これらのボタンが押されると、システムはその番組のEPG 情報のワード列を単語に分解して抜き出し、ワードリストに登録する。すでに登録されている単語については、その出現回数を更新する。(Good ボタンの場合は出現回数を1 増やし、No-Good ボタンの場合は1 減らす。)
なお、ワードリストとは、単語とその出現回数のリストであり、そのサイズは最大6000 ワードとした。この方法によって、ワードリストはユーザの嗜好そのものとなる。すなわち、出現回数の多い単語が、ユーザの好きな番組
の特徴を表すのである。
【０１３６】
ユーザの嗜好と番組のマッチングユーザの好きなジャンルの番組を推測するために、ユーザのワードリストと番組のEPG 情報のワード列(をワードリストに変換したもの)との類似度を計算する。この類似度計算は、まず各単語間で類似度を計算し、その次にワードリスト間で類似度を計算するという2 段階の手続きを踏む。
単語間の類似度の計算には、EDR 電子化辞書の概念辞書と英語単語辞書を利用する。概念辞書には概念の上下関係がツリー構造で記述されている。そして英語単語辞書には、英単語と概念の対応関係が記述されている。
ただし、実際に使用する英単語はSTB 上にのるように高頻度の6000 語程度に限定する。
単語間の類似度計算は、まず英語単語辞書で2 つの単語の概念を引き、次に概念辞書のツリーにおけるそれら概念間の距離を計算する。この距離をNp、ツリーの最大の高さをD とするとき、上記した（６・１）式［数６］で単語間の類似度を計算する。
次にワードリスト間の類似度の計算のために、まず、長い方のワードリスト内の単語から、短い方のワードリスト内の各単語と類似度の高いものを抽出して、新たなワードリストを作成する。この新しいワードリストは短い方のワードリストと同じ長さである。そして、新しいワードリスト(各単語の出現回数と類似度をかけた値)と短い方のワードリスト(各単語の出現回数の値)をベクトルとしてその内積を計算し、その成す角を求める。この角度が小さければ、その番組はユーザの嗜好に合っていることになる。
【０１３７】
（バリューによる番組推薦）
バリューには、ユーザから集める情報によって様々な
ものが考えられる。例えば、本システムでは
・視聴率
・視聴時間
・視聴回数
・Good ボタン、No-Good ボタンが押された回数
・録画したかどうか
・ブックマークしたかどうか
などがバリューとして考えられる。これらは4 章の情報集計アルゴリズムを使って容易に得ることができる。
これらのバリュー及びその変遷を番組毎に提示してやることで、ユーザは様々な角度から番組を知ることができ、これまでとは違った視点で番組を選ぶことができるようになる。
【０１３８】
（クラスタリング）
クラスタリングとは、嗜好の似た者同士を近くにまとめる技術である。これを導入することによって、ユーザはさらに多くの有用な情報を得ることができる。それはすなわち、世間一般の人によるバリュー以外にも、自分と嗜好が似ている人によるバリューも得ることが出来る、ということである。これは、自分と趣味が似ている友人が非常に有用な情報を提供してくれることと同じである。
また、自分が属すクラスタ以外のクラスタから情報を得ることも非常に有用である。なぜなら、クラスタとはその分野に深く通じた者の集団だからである。自分が詳しくない分野について、その分野の専門家の意見を参考にすることは賢い方法である。
本システムでクラスタリングを導入することはさほど難しくない。各ノードは自分の嗜好をワードリストとして保持しているので、それを用いて各ノードと嗜好の類似度を計算し、類似度の高い相手と選択的に接続すればよいからである。
しかし問題もある。クラスタリングをしてしまうと、周りには自分と似ている人しかいないため、自分と似ている人からしか情報を集められなくなってしまうのである。すなわち、世間一般の人によるバリューが得られくなってしまう。そこで、例えば以下の2 つの方法が考えられる。
方法１：接続先ノードを、嗜好ノードリストとランダムノードリストの2 つのノードリストで管理する。
方法2：周囲のノード群の中から、自分と似ているノードの情報を抽出する。
【０１３９】
（方法1）
方法１は、クラスタリングしたネットワークとクラスタリングしていないネットワークが同時に存在するとした方法である。嗜好ノードリストには、自分と嗜好類似度の高いノードアドレスを登録し、ランダムノードリストには、ランダムなノードのアドレスを登録する。そして、これら2 つのノードリストで独立平行に情報集計アルゴリズムを実行する。
この方法では、柔軟で正確なクラスタリングが可能である。そして、世間一般の人の情報も、自分と嗜好が似ている人の情報も集めることが出来る。しかし、情報集計アルゴリズムを2 つ平行して実行させることになり、トラフィックと計算コストが2 倍になってしまう。また、他のクラスタの情報を得ることは出来ない。
【０１４０】
（方法2）
方法２では、全ユーザで共通のジャンルを導入する必要がある。各ユーザは自分の嗜好ワードリストから、共通のジャンルに対する嗜好の度合いを計算し、0〜1 の値に変換する。(= 一時共通ジャンルリスト) そしてその値が高いものは1、それ以外は0 とする共通ジャンルリストを作成する（図３５参照）。すなわち、好きな共通ジャンルを1 とする。なお、共通のジャンルは数十個程度とする。
【０１４１】
共通ジャンルリストは、同じ番組を見ていたユーザ同士で足し合わせながら集計する。そうすれば、その番組を見ていたユーザの中で、共通genre1 が好きなユーザ数、共通genre2 が好きなユーザ数、・・・を知ることができる。すなわち、共通genreX の専門家の情報を得られるということである。これは、ユーザを共通ジャンルでクラスタリングしたことと同じである。
また、自分と似ている人の情報は、集計した共通ジャンルリストと自分の一時共通ジャンルリストの値をかけて足し合わせることで、擬似的に求めることができる。
この方法２では、あらかじめ共通のジャンルを決めてしまうので、新しいジャンルが出てきたときに対応できないなど、柔軟で精度の高いクラスタリングが不可能となってしまう。
【図面の簡単な説明】
【０１４２】
【図１】コンテンツベース推薦の概念を示す模式図である。
【図２】コラボレーティブ推薦の概念を示す模式図である。
【図３】コラボレーティブホライズンの概念を示す模式図である。
【図４】放送番組と同期した掲示板の話題について、時間経過と盛り上がりの関係を示すグラフである。
【図５】ＴＶ番組に対する掲示板へのメッセージ投稿数の順位を番組ジャンルごとに集計したグラフである。
【図６】情報集計方法の一例を示す模式図である。
【図７】情報集計アルゴリズムの仕組みを示す模式図である。
【図８】データの集計方法の一例を示す模式図である。
【図９】重複データを考慮し視聴率の誤差を可視化したグラフである。
【図１０】共通ジャンルリストの作成例を示す模式図である。
【図１１】共通ジャンルリストの集計の概念を示す模式図である。
【図１２】番組表示中の画面の一例を模式的に示す図である。
【図１３】実際の番組表示中の画面の一例を示す図である。
【図１４】番組推薦インタフェースの一例を示す図である。
【図１５】受信リンク数が０の場合について、最大送信リンク数とノード数の関係を示すグラフである。
【図１６】受信リンク数が１の場合について、最大送信リンク数とノード数の関係を示すグラフである。
【図１７】受信リンク数が２の場合について、最大送信リンク数とノード数の関係を示すグラフである。
【図１８】受信リンク数が３の場合について、最大送信リンク数とノード数の関係を示すグラフである。
【図１９】受信リンク数が４の場合について、最大送信リンク数とノード数の関係を示すグラフである。
【図２０】ノード離脱率と収集データ量の関係の一例を示すグラフである。
【図２１】ノード離脱率とデータ送信回数の関係の一例を示すグラフである。
【図２２】ノード数とデータ重複率の関係の一例を示すグラフである。
【図２３】100ノードの各次数のデータによる視聴率の標準偏差を示すグラフである。
【図２４】視聴率について８ステップ後の集計結果の一例を示すグラフである。
【図２５】視聴率について１０ステップ後の集計結果の一例を示すグラフである。
【図２６】視聴率について１２ステップ後の集計結果の一例を示すグラフである。
【図２７】視聴率について１４ステップ後の集計結果の一例を示すグラフである。
【図２８】満足度について８ステップ後の集計結果の一例を示すグラフである。
【図２９】満足度について１０ステップ後の集計結果の一例を示すグラフである。
【図３０】満足度について１２ステップ後の集計結果の一例を示すグラフである。
【図３１】満足度について１４ステップ後の集計結果の一例を示すグラフである。
【図３２】やり取りするデータの一例を示す模式図である。
【図３３】データの集計方法の一例を示す模式図である。
【図３４】ノード数とデータ重複率の関係の一例を示すグラフである。
【図３５】共通ジャンルリストの作成例を示す模式図である。
【特許請求の範囲】
【請求項１】
複数の視聴者に対応したノードを接続したネットワークを利用した視聴率を集計するシステムにおいて、
各ノードから、他のノードに対して受信リンクを張る手段と、
ネットワークを構成する各ノードが、受信リンクを張られたノードに対して定期的にリンクを介して視聴率に関するデータを送信する手段と、
各ノードにおいて、視聴率に関するデータを収集し、集計する手段と、
集計された視聴率に関するデータが、一定期間受信されないノードとの受信リンクを切断し、他のノードとのリンクを張りなおす手段とを
有することを特徴とする、放送番組の視聴率をP2Pネットワークを使用して集計するシステム。
【請求項２】
視聴率データを収集し、集計する手段は、各ノードが、各ノード自身の情報（0次情報）、他の1つのノードが得た情報（1次情報）、さらに他の1つのノードを介して得た情報（2次情報）・・・毎に集計することを特徴とする、請求項1記載の放送番組の視聴率をP2Pネットワークを使用して集計するシステム。
【請求項１】
複数の視聴者に対応したノードを接続したネットワークを利用した視聴率を集計するシステムにおいて、
各ノードから、他のノードに対して受信リンクを張る手段と、
ネットワークを構成する各ノードが、受信リンクを張られたノードに対して定期的にリンクを介して視聴率に関するデータを送信する手段と、
各ノードにおいて、視聴率に関するデータを収集し、集計する手段と、
集計された視聴率に関するデータが、一定期間受信されないノードとの受信リンクを切断し、他のノードとのリンクを張りなおす手段とを
有することを特徴とする、放送番組の視聴率をP2Pネットワークを使用して集計するシステム。
【請求項２】
視聴率データを収集し、集計する手段は、各ノードが、各ノード自身の情報（0次情報）、他の1つのノードが得た情報（1次情報）、さらに他の1つのノードを介して得た情報（2次情報）・・・毎に集計することを特徴とする、請求項1記載の放送番組の視聴率をP2Pネットワークを使用して集計するシステム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図３５】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図３５】
【公開番号】特開２００８−２４４６０１（Ｐ２００８−２４４６０１Ａ）
【公開日】平成２０年１０月９日（２００８．１０．９）
【国際特許分類】
【出願番号】特願２００７−７９３５０（Ｐ２００７−７９３５０）
【出願日】平成１９年３月２６日（２００７．３．２６）
【新規性喪失の例外の表示】特許法第３０条第１項適用申請有り ２００６年９月２５日 特定非営利活動法人 ヒューマンインタフェース学会発行の「ヒューマンインタフェースシンポジウム２００６ 論文集」に発表
【出願人】（５０４１３３１１０）国立大学法人 電気通信大学 (383)
【出願人】（０００２０１１１３）船井電機株式会社 (7,855)
【Ｆターム（参考）】
【公開日】平成２０年１０月９日（２００８．１０．９）
【国際特許分類】
【出願日】平成１９年３月２６日（２００７．３．２６）
【新規性喪失の例外の表示】特許法第３０条第１項適用申請有り ２００６年９月２５日 特定非営利活動法人 ヒューマンインタフェース学会発行の「ヒューマンインタフェースシンポジウム２００６ 論文集」に発表
【出願人】（５０４１３３１１０）国立大学法人 電気通信大学 (383)
【出願人】（０００２０１１１３）船井電機株式会社 (7,855)
【Ｆターム（参考）】
[ Back to top ]