JP2011101068A

JP2011101068A - コンテンツ配信されるネットワークにおける管理装置、受信端末

Info

Publication number: JP2011101068A
Application number: JP2008011063A
Authority: JP
Inventors: Satoru Date; 哲伊達; Hideki Kamimaki; 秀樹神牧; Nobuhiro Sekimoto; 信博関本; Hiroo Miyamoto; 啓生宮本; Takatada Yamaguchi; 宇唯山口; Hisato Mori; 久斗森; Kotaro Yusa; 幸太郎遊佐
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2008-01-22
Filing date: 2008-01-22
Publication date: 2011-05-19
Also published as: WO2009093438A1

Abstract

【課題】
従来のザッピング機能で提供する番組の順番は、ユーザのリモコン操作を記憶し、ユーザが視聴する番組の傾向からユーザ嗜好を求め、おすすめ度として優先度の高い順として提供する内容であった。単純なチャネル順の切替に対して、ユーザの視聴傾向に合わせた番組順に提供できる効果があるが、現在、多くの人が視聴している人気番組順に切替えるといった選択方法を提供できないという問題があった。
【解決手段】
視聴されている番組の情報を収集すると共に、視聴数の多い番組順にチャネルを切替える番組選択方法を提供する。コンテンツ配信システムは、コンテンツサーバと受像装置からの受信要求に基づき視聴情報を処理する手段と視聴情報を視聴率サーバへ通知する手段を有するネットワーク装置と、ネットワーク装置から受信した視聴情報から視聴率を求める手段を有する視聴率サーバとから構成される。
【選択図】図１

Description

技術分野は、コンテンツが配信されるネットワークに対応する送信装置、中継装置、受信端末、管理装置それらを含むシステム等に関する。

コンテンツをネットワークで配信することに関し、マルチキャストが注目されている。マルチキャストとは、送信側は特定のマルチキャストグループ用のアドレスにデータを送信し、マルチキャストグループに所属する端末だけがそのデータを受信できる仕組みである。ＩＰ（ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ）を利用したＩＰマルチキャストに関しては非特許文献１から３等に記載されている。

一方、特許文献１には、「放送番組などのコンテンツに対する視聴者の嗜好度を、実態に即したものとして的確に算出できるようにする」ことを課題とし、その解決手段として「嗜好度算出部７２では、番組視聴履歴データから、視聴者の当該番組に対する嗜好度Ｐｒとして、当該番組の視聴時間Ｄｗの単位時間Ｌｕに対する比率Ｒｕ（＝Ｄｗ／Ｌｕ）、および視聴時間Ｄｗの当該番組の時間長Ｌｃに対する比率Ｒｃ（＝Ｄｗ／Ｌｃ）の関数であって、かつ、比率Ｒｕが大きいほど嗜好度Ｐｒが大きくなり、比率Ｒｃが大きいほど嗜好度Ｐｒが大きくなる関数値を算出する。例えば、Ｐｒ＝Ｒｕ＋Ｒｃ＝（Ｄｗ／Ｌｕ）＋（Ｄｗ／Ｌｃ）とする。嗜好度更新部７３では、その嗜好度Ｐｒを、嗜好データベース７９に記録されている更新前の嗜好度Ｐｏに、ある比率で加算し、その加算後の嗜好度Ｐｎを、更新後の嗜好度として嗜好データベース７９に記録する。」技術が開示されている。

特開２００３−２３５８９号公報 RFC1112("Host Extensions for IP Multicasting",IETF,1989) RFC2236("Internet Group Management Protocol, Version2",IETF,1997) RFC2710("Multicast Listener Discovery (MLD) for IPv6",IETF,1999)

インターネットのブロードバンド化が進み、広帯域データ通信を利用したアプリケーションが増加しつつある。コンピュータのアプリケーションとして、インターネットを利用した映像コンテンツのストリーミング視聴が見られるようになった。一方、テレビにおいてもネットワークを利用したポータルサービスや、高品質な映像コンテンツのＶｏＤ（ＶｉｄｅｏｏｎＤｅｍａｎｄ）サービスが開始されている。さらに今後、ネットワーク利用したコンテンツサービスとして、従来の放送サービスのように、ＩＰ等の通信ネットワーク上に多くの番組が送信されることが期待される。このような通信ネットワークでの多数の宛先への同じコンテンツに送信にあたり、ネットワークの負担の上昇の程度を抑えつつ実現する技術として、上述のＩＰマルチキャストなどのマルチキャストが注目されている。

このようなマルチキャストによるコンテンツの送信が実現されると、ユーザはより多数のチャンネルから番組を選んでを楽しめる一方で、チャンネル数が多いためにそれら多数のチャンネルの中から、ザッピング等により所望の番組を見つける迄に時間がかかることが懸念される。なお、ザッピングとは視聴したい番組を探すためにチャンネルを次々と切り換えることをいう。

特許文献１では、ユーザのリモコン操作を記憶し、ユーザが視聴する番組の傾向からユーザ嗜好を求め、おすすめ度として優先度の高い順として提供することを示唆しているが、ユーザの嗜好に基づくものであって、そのユーザ以外の人々に人気の番組を把握することはできない。

また、そもそも特許文献１は、従来の放送に対応した技術であってマルチキャスト配信について考慮がない。

そこで本出願では例えば、マルチキャスト配信に対応したシステム、受信機、中継器、送信機において、多数の視聴者に人気のあるコンテンツを検出する技術を提供する。また、その検出に応じてチャンネル切り替えの順序を制御する受信機等を提供する。

上記手段によれば例えば、ユーザはそのユーザ以外が現在よく観ているコンテンツを知ることができる。また、その順にザッピングすることができる。

本発明に好適な実施形態の例（実施例）を説明する。ただし、本発明は本実施例に限定されない。

図１は、システムの構成例を示す。システムは、配信サーバ1０１、視聴率サーバ１０２、ルータ１０３、受信機１０４を含む。

図２から４はそれぞれ、受信機１０４、ルータ１０３、視聴率サーバ１０２の構成例を示す。各部は、ハードウェアで実現されてもよいし、ソフトウェアをＣＰＵ等で実行させることで実現してもよい。構成の組合せには自由度があり、例えば図２ではディスプレイ２１１とスピーカ２１２を内蔵したテレビジョン装置のように示しているが、これらを別体としたセットトップボックスであってもよい。

図５は、チャネル番号、マルチキャストアドレス、それに対応する視聴端末数を含む視聴情報データのデータテーブル例を示す。視聴情報データは、図３のワークメモリ２２１（視聴情報データ記憶部）に記憶されている。メインメモリ２１５やＨＤＤ等に記憶されていてもよい。以下のワークメモリに関する記載についても同様である。

図６は、チャネル番号、マルチキャストアドレス、視聴率を含む視聴率データのデータテーブル例を示す。視聴率データは、図４のワークメモリ２２７（視聴率データ記憶部）に記憶されている。

図７は、配信サーバ（コンテンツサーバ）1０１、視聴率サーバ（管理サーバ）１０２、ルータ（中継装置）１０３、受信機（受信端末）１０４による処理例のフローチャートである。なお、ルータはスイッチや中継サーバ等であってもよいが、マルチキャストグループの管理は通常ルータによるのでルータで説明する。

まず、受信機１０４が映像を受信するまでの流れを、図７を用いて説明する。配信サーバ１０１は、マルチキャストグループ(マルチキャストアドレス)へ映像データの配信を行う（Ｓ４０１）。なお、もしルータ１０３が所望の映像データを受信していない場合は、ルータ１０３がマルチキャスト配信の基点となるルータ（ランデブーポイント）へ、映像データの送信要求を行う。その後、基点となるルータ（ランデブーポイント）から所望の映像データを受信すると、ルータ１０３は受信機１０４へ映像データを送信する。

ランデブーポイントについて補足説明する。マルチキャスト配信は、ネットワークの大容量データの効率的な伝送を実現するプロトコルで、配信サーバが１個のマルチキャストパケットを送ると、必要とする端末までのネットワーク（ディストリビューションツリー）に対してパケットを配送する。配信サーバがそれぞれの端末に対してパケットを送信するユニキャスト配信に対してネットワークの負荷を軽減することができる。１つ以上の複数の配信サーバから構成されるネットワークにおいてディストリビューションツリーを共有すると、配信サーバごとにディストリビューションツリーを構成する場合と比較し、ネットワークの負荷を軽減できる。受信機がマルチキャストによる映像データを受信するためには、マルチキャストグループ（マルチキャストアドレス）に参加する必要がある。ディストリビューションツリーを共有しない場合は、受信機が所望のデータを配信するマルチキャストグループに参加のメッセージをネットワークに送信、ルータが該当するデータを受信していれば、要求した受信機に対してパケットを配信する。データを受信していない場合、ルータは隣接ルータに対してマルチキャスト参加メッセージを送信しながら配信サーバに隣接するルータまでメッセージを伝達する。ディストリビューションツリーを共有する場合は、受信機がマルチキャストグループに参加のメッセージをネットワークに送信し、ルータは要求のあった受信機の情報をランデブーポイントに伝達する。ランデブーポイントは、受信した情報を基にディストリビューションツリーを構築する。配信サーバはデータパケット１個をランデブーポイントに送信すれば、ディストリビューションツリーのルータが必要なパケットをコピーしながら受信機へ配信する。

受信機１０４は、ユーザの所望する映像コンテンツに対応したマルチキャストアドレスでルータ１０３に参加要求（ＪｏｉｎＭｅｓｓａｇｅ）を送信する（Ｓ４０２）。マルチキャストプロトコルは、前述したように配信サーバから送信される映像パケットを受信しない受信機へのネットワークに配信せず、受信する受信機のみへ配信するプロトコルであり、受信するときには、ネットワークへ受信を要求する必要がある。受信機はネットワークへの要求として、ルータへの参加要求メッセージを送信する。

ルータ１０３は参加要求を受信すると、受信している映像データの中から、参加要求に対応する映像データを受信機１０４へ送信する（Ｓ４０３）。

これらＳ４０２とＳ４０３について、図２と図３も用いて追加説明する。受信機１０４のリモコン受信部２０２は、リモコン２０１からの入力情報を受信し、ＣＰＵ２０３に接続されたバス２２８に制御コマンドとして出力する。ＣＰＵ２０３は、メインメモリ２０４にプログラムを有し、リモコン受信部２０２からバス２２８に出力された制御コマンド情報を解析するプログラムを実行し、ユーザの所望する映像コンテンツに対応したマルチキャストアドレスでルータ１０３に参加要求を送出するよう、マルチキャスト制御部２０５に指示する。指示を受けたマルチキャスト制御部２０５はルータ１０３に参加要求を送信する。参加要求を受信したルータ１０３は、マルチキャスト制御部２１６において、受信した参加要求を解析し、映像データ受信部２１７へ参加要求に対応する映像を受信機１０４へ転送するよう指示を行う。ルータ１０３から送出される映像データを受信機１０４の映像データ受信部２０６が受信すると、メディア処理／表示制御部２０９へ映像データを供給する。メディア処理／表示制御部２０９は、ワークメモリ２１０を活用し、映像フォーマット、音声フォーマットのデコードを行い、デコードした映像データをディスプレイ２１１に、デコードした音声データをスピーカ２１２から出力することで映像コンテンツの再生を行う。

次に受信機１０４が視聴率データを取得する処理例を、図７を用いて説明する。

ルータ１０３では、受信機からの参加要求４０２を受信すると、図５の視聴情報データの更新を行う（Ｓ４０８）。視聴情報データの更新が行われるとルータ１０３は視聴率サーバ１０２へ視聴情報データの送信を行う（Ｓ４０４）。視聴情報データを受信した視聴率サーバ１０２は、図６の視聴率データの更新を行う（Ｓ４０９）。視聴率は例えば以下のように算出する。

従来の放送で言うところの視聴率は世帯視聴率を示すが、ここでは番組の人気指標としてとらえ、例えば、契約受信機数における視聴率と、現在視聴中の受信機における番組の視聴率を算出する方法を示す。契約受信機数におけるｎチャネルの視聴率をＶ＿ｎ、契約受信機数をＲ＿ａ、ｎチャネルを受信している受信機数をＲｏ＿ｎとすると、
Ｖ＿ｎ＝Ｒｏ＿ｎ／Ｒａ・・・（１）
として算出する。また、現在視聴中受信機におけるｎチャネルの視聴率をＶ＿ｎ、マルチキャスト受信中の受信機数をＲ＿ｒ、ｎチャネルを受信している受信機数をＲｏ＿ｎとすると、
Ｖ＿ｎ＝Ｒｏ＿ｎ／Ｒｒ・・・（２）
として算出する。

受信機１０４は、視聴率サーバ１０２に視聴率データ取得要求４０５を行うことで、視聴率データを取得する（Ｓ４０６）。ただし、視聴率に限定されず量であてもよいし、順番であってもよい。総称して視聴指標、人気指標、注目指標とも言う。

受信機１０４がルータ１０３へ離脱要求を送信した場合（Ｓ４０７）には、ルータ１０３では視聴情報データを更新し（Ｓ４０８）、視聴率サーバ１０２では視聴率データを更新する（Ｓ４０９）。また、ルータ１０３から受信機への参加問い合わせ（クエリー）の応答が所定時間（例えば２５５秒）以上ない場合（Ｓ４１０）にも、Ｓ４０８とＳ４０９を実行する。例えば、受信機１０４が離脱要求せずに電源断などされる場合も考えられ、電源断されているにも関わらず視聴中と判断させないためである。

これらＳ４０８、Ｓ４０９について、図３と図４も用いて追加説明する。ルータ１０３は、参加要求を受信すると視聴情報データ制御部２２０の指示でワークメモリ２２１に図５の視聴情報データを展開する。視聴情報データ制御部２２０は、所望のマルチキャストアドレスに対応する視聴端末数３０１を「１」増加させる。ワークメモリ２２１に展開されている視聴情報データが更新されると、視聴情報データ制御部２２０は視聴情報データを視聴情報データ送信部２１８に転送する。視聴情報データ送信部２１８では、コンフィグ２１９として設定されている視聴率サーバ１０２のアドレスを取得することで転送されてきた視聴情報データを視聴率サーバ１０２にユニキャストで送信する。視聴率サーバ１０２では、ルータ１０３より送信されてきた視聴情報データを視聴情報データ受信部２２２で受信する。受信した視聴情報データは視聴率データ制御部２２６へ転送され、ワークメモリに展開されていた図６の視聴率データを更新する。受信機１０４がルータ１０３へ離脱要求を送信した場合、またはルータ１０３から受信機への参加問い合わせの応答が所定時間以上ない場合は、ルータ１０３の視聴情報データ制御部２２０がワークメモリ２２１に展開された視聴情報データの視聴端末数３０１を「1」減算する処理を行う。

次に、受信機１０４にて取得した視聴率データを基に番組切り替え順番を設定する処理例について図２、図８、図９を用いて説明する。

図９は、ザッピング設定データのデータテーブル例を示している。視聴率の降順にチャネルを一覧している。図２のワークメモリ２１０（ザッピング設定データ記憶部）に記憶されている。

図８は、画面におけるザッピングモードの表示５０１〜５０４の切り替え表示を模式的に示している。

図２において、受信機１０４は、例えばリモコン２０１からの指示入力に応じて、ザッピングモード制御部２１３が、メディア処理/表示制御部２０９を経由し、ディスプレイ２１１にザッピングモード（５０１）を表示させる。更なら指示入力に応じて、５０２、５０３、５０４に例示する複数のザッピングモードに変更することが可能となる。また、「視聴率順」のザッピングモードを選択した状態において、リモコン２０１の数字チャネルボタンの「１」キーを押下すれば一番視聴率の高いチャネルが、「２」キーを押下すれば二番目に視聴率の高いチャネルが選択される。上下チャネルボタンを押下しても同様に視聴率の順でソートされたチャネル切り替えを行うことが出来る。

以上受信機が番組を選択してから視聴率を求める過程を説明したが、ユーザが頻繁に番組を切替える（ザッピング）ときに実際には番組を見ていないと判定したい場合がある。以下、特定の時間同じ番組を見ていない場合は、視聴率の算出に組込まない方法について説明する。

図１０に、ルータ１０３において受信機からの操作内容と時刻を保持するテーブルの一例を示す。図７において、ルータ１０３が受信機からの参加要求４０２を受信し、図５の視聴情報データの更新を行う（Ｓ４０８）と共に、通知された端末情報と操作時刻情報を図７、図１０、及び図１１に示す操作管理情報６０１として更新する（Ｓ４２０）。ここで端末識別は、端末を識別するための識別子で、例えば受信機のアドレス、受信機ＩＤ、ネットワーク接続の接続に利用するためのＩＤ等である。その後所定時間（例えば３０秒）（Ｓ４２１）後に図５の視聴情報データの更新を行う（Ｓ４０８）。所定時間内に受信機から参加要求（Ｓ４０２）があった場合、要求元の受信機について操作管理情報６０１に記録されている前の操作時刻６０２を検索し、現在時刻と比較し所定時間以内であれば、視聴情報データ更新（Ｓ４０８）を行わず、受信機からの参加要求を待機する。ただし、このとき視聴情報データの最終更新時刻６０３が所定の時間（例えば１分）過ぎてきれば、受信機からの最後の操作内容を視聴情報データの更新を行う。このようにすれば、受信機が頻繁に番組を切替えても、ある所定の時刻まで視聴率情報を保持しつつ、視聴率情報データの更新が確実に行われる。

また、リモコン２０１の或るボタン（例えばザッピングボタン）を長押し等することで、現在選択されているザッピングモードの設定データ（図８）を表示させることができる。

システムの構成例を示す。受信装置１０４の構成例を示す。ルータ１０３の構成例を示す。視聴率サーバ１０２の構成例を示す。視聴情報データの内容例を示す。視聴率データの内容例を示す。システムにおける処理例を示す。画面表示の例を示した図画面表示の例を示した図操作内容と時刻データの内容例を示す。システムにおける処理例を示す。

符号の説明

101・・・配信サーバ、102・・・視聴率サーバ、103・・・ルータ、104・・・受信機、201・・・リモコン、203、214・・・ＣＰＵ、205、216・・・マルチキャスト制御部、207、218、226・・・視聴率データ受信部、209・・・メディア処理／表示制御部、211・・・ディスプレイ、212・・・スピーカ、213・・・ザッピングモード制御部、301・・・視聴端末数、401、403・・・映像データ、402・・・参加要求メッセージ、404・・・視聴情報データ、405・・・視聴率データ取得要求メッセージ、406・・・視聴率データ、407・・・離脱要求メッセージ、501・・・ザッピングモード状態、505・・・数字チャネルボタン、506・・・上下チャネルボタン、507・・・ザッピングボタン、508・・・ザッピング設定状況表示画面

Claims

マルチキャスト配信されるコンテンツを受信する複数の受信端末を含むネットワークにおける管理装置が実行する管理方法であって、
複数の受信端末からのマルチキャストグループへの参加要求を集計し、
受信端末へ前記集計に基づくデータを送信する管理方法。
請求項１の管理方法であって、
前記受信端末から参加要求を受信した中継装置から前記参加要求を取得する管理方法。
請求項１の管理方法であって、
所定のマルチキャストグループへの参加要求から所定時間、当該マルチキャストグループへ参加していた場合に、当該参加要求を前記集計に反映する管理方法。
請求項１の管理方法であって、さらに、
複数の受信端末からのマルチキャストグループからの離脱要求を前記集計に反映する管理方法。
請求項１の管理方法であって、
前記受信端末と定期的に通信し、当該通信が途絶えたときマルチキャストグループから離脱したと判断して前記集計に反映する管理方法。
請求項１の管理方法であって、
前記集計に基づくデータは、複数のマルチキャストグループそれぞれへの参加要求の量または率を示すデータである管理方法。
請求項１の管理方法であって、
前記集計に基づくデータは、複数のマルチキャストグループの順を示すデータである管理方法。
マルチキャスト配信されるコンテンツを受信する受信端末であって、
マルチキャストグループへの参加要求及び離脱要求を中継装置へ送信する送信部と、
視聴率又は量又は順のデータを受信する受信部と、
前記受信部で受信したデータに基づいて視聴するコンテンツの切り替え順を制御する制御部とを有する受信端末。
請求項８の受信端末であって、
前記受信部で受信するデータは前記送信部で送信した参加要求及び離脱要求に基づくデータである受信端末。
請求項８の受信端末であって、
前記制御部は、前記コンテンツの切り替え順を前記データに基づくモードと基づかないモードとに切り替え可能な受信端末。