JP2011091681A - コンテンツ配信システムおよびコンテンツ配信方法 - Google Patents

Abstract

【課題】視聴者の利便性を損なうことなく、アクセスの集中に対応することができるコンテンツ配信システムを提供する。
【解決手段】コンテンツまたは該コンテンツに関連する関連コンテンツが過去に配信された際の実績を示す実績情報に基づき、コンテンツを配信した場合の視聴者数の予測値を算出する視聴者数予測装置と、算出された視聴者数の予測値に基づき、コンテンツの配信方法を決定する配信サーバー管理装置と、通信網を介して接続された端末装置に、決定された配信方法を用いて、前記コンテンツを配信する配信サーバーとを有すること。
【選択図】図２

Description

本発明は、コンテンツ配信システムおよびコンテンツ配信方法に関する。

近年、政府による放送と通信の融合政策などにより、インターネットで映画等のコンテンツを配信するＩＰＴＶ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ Ｔｅｌｅｖｉｓｉｏｎ）サービスが普及している。それに伴い、従来のテレビジョン番組を放送電波に乗せて配信していた放送局が、インターネット回線や携帯電話の回線を通じて、過去に放送した番組をコンテンツとして、視聴者が見たい時に見られるように、ビデオ・オン・デマンド（Ｖｉｄｅｏ ｏｎ Ｄｅｍａｎｄ；ＶｏＤ）方式で提供する見逃し視聴サービスを提供している。代表的な例では英国のＢＢＣ（登録商標）（Ｂｒｉｔｉｓｈ Ｂｒｏａｄｃａｓｔｉｎｇ Ｃｏｒｐｏｒａｔｉｏｎ；英国放送協会）が提供するｉＰｌａｙｅｒや日本のＮＨＫ（登録商標）（日本放送協会）が提供するＮＨＫ（登録商標）オンデマンドが挙げられる。

これらの見逃し視聴サービスは、一般的に本放送の契約者や、月極めや番組毎の料金を支払った契約者を対象に提供されていて、人気を集めている。一方で、特に人気のある番組や、夜間や休日等の特定の時間帯に、アクセスが集中する傾向がある。配信サーバーの配信能力には限界があるため、アクセス集中する番組や時間帯には、サービスに繋がりにくくなるという問題がある。
係る問題に対して、あらかじめネットワークのトラヒック量を監視し、過去のトラヒック量から予測して、配信帯域に余裕がある時間帯に配信するように、配信日時を決定することで解決を試みる技術がある（例えば、特許文献１）。

特開２００６−２３９５６号公報

しかしながら、上述の技術のように、配信帯域に余裕がある時間帯を予約する方式では、本来視聴者が視聴したい時間に視聴できない可能性があり、視聴者の利便性を損なう問題がある。
また、過去のトラヒック量から予測すると、特に人気が高い番組が放送された場合等、突発的なアクセスの集中を予測できず、アクセスの集中に対応できないことがあるという問題がある。

本発明は、このような事情に鑑みてなされたもので、その目的は、視聴者の利便性を損なうことなく、アクセスの集中に対応することができるコンテンツ配信システムおよびコンテンツ配信方法を提供することにある。

（１）この発明は上述した課題を解決するためになされたもので、本発明のコンテンツ配信システムは、コンテンツまたは該コンテンツに関連する関連コンテンツが過去に配信された際の実績を示す実績情報に基づき、前記コンテンツを配信した場合の視聴者数の予測値を算出する視聴者数予測装置と、前記算出された視聴者数の予測値に基づき、前記コンテンツの配信方法を決定する配信サーバー管理装置と、通信網を介して接続された端末装置に、前記決定された配信方法を用いて、前記コンテンツを配信する配信サーバーとを有することを特徴とする。

（２）また、本発明のコンテンツ配信システムは、上述のコンテンツ配信システムであって、前記実績情報は、当該システムとは視聴者の構成が異なる他のシステムにより事前に前記コンテンツを配信した際の視聴率であることを特徴とする。

（３）また、本発明のコンテンツ配信システムは、上述のコンテンツ配信システムであって、前記視聴率は、視聴者の属性区分毎の視聴率であることを特徴とする。

（４）また、本発明のコンテンツ配信システムは、上述のコンテンツ配信システムであって、前記属性は、年齢、性別のうち、少なくとも１つを含むことを特徴とする。

（５）また、本発明のコンテンツ配信システムは、上述のいずれかのコンテンツ配信システムであって、前記視聴者数予測装置は、前記視聴率と、当該システムの全視聴者数と、前記コンテンツの配信期間中の当該システムにおける配信時間帯毎の視聴者数の分布傾向とに基づき、各時間帯における前記コンテンツの視聴者数の予測値を算出することを特徴とする

（６）また、本発明のコンテンツ配信システムは、上述のコンテンツ配信システムであって、前記実績情報は、前記コンテンツまたは該コンテンツに関連する関連コンテンツが配信された際の、当該システムの視聴者の視聴実績を示す情報であることを特徴とする。

（７）また、本発明のコンテンツ配信方法は、視聴者数予測装置と、配信サーバー管理装置と、配信サーバーとを有するコンテンツ配信システムにおけるコンテンツ配信方法であって、前記視聴者数予測装置が、コンテンツまたは該コンテンツに関連する関連コンテンツが過去に配信された際の実績を示す実績情報に基づき、前記コンテンツを配信した場合の視聴者数の予測値を算出する第１の過程と、前記配信サーバー管理装置が、前記算出された視聴者数の予測値に基づき、前記コンテンツの配信方法を決定する第２の過程と、前記配信サーバーが、通信網を介して接続された端末装置に、前記決定された配信方法を用いて、前記コンテンツを配信する第３の過程とを有することを特徴とする。

この発明によれば、コンテンツまたは該コンテンツに関連する関連コンテンツが過去に配信された際の実績を示す実績情報に基づき、コンテンツを配信した場合の視聴者数の予測値を算出し、該予測値に基づき、コンテンツの配信方法を決定するので、視聴者の利便性を損なうことなく、アクセスの集中に対応することができる。

この発明の第１の実施形態における見逃し視聴サービスの構成図である。 同実施形態におけるコンテンツ提供システムの構成を示す概略ブロック図である。 同実施形態における見逃し視聴サービスを利用する際の受信装置１００の動作を説明するフローチャートである。 同実施形態における負荷分散方式決定部１０７による配信方式および配信サーバー数の決定処理を説明するフローチャートである。 同実施形態におけるＨＴＭＬブラウザ１１０が生成するコンテンツの一覧表画面の例を示す図である。 同実施形態における配信負荷計測部１０８の配信許容値の算出処理を説明するフローチャートである。 この発明の第２の実施形態におけるコンテンツ提供システムの構成を示す概略ブロック図である。 同実施形態における視聴者数の予測値算出方法を説明する図である。 同実施形態における視聴率情報蓄積部１０２ａ、契約者情報ＤＢ１０３ａ、視聴履歴蓄積部３０１、視聴者数予測部１０５のデータ構造を説明する図である。 同実施形態における視聴者数予測部１０５ａによる視聴者数予測処理を説明するフローチャートである。 同実施形態の変形例における視聴者数予測部１０５ａの契約者の嗜好情報を用いた視聴者数の予測処理を説明するフローチャートである。 この発明の第３の実施形態におけるコンテンツ配信システムの構成を示す概略ブロック図である。 この発明の第４の実施形態におけるコンテンツ配信システムの構成を示す概略ブロック図である。 この発明の第５の実施形態におけるコンテンツ配信システムの構成を示す概略ブロック図である。

［第１の実施形態］
以下、図面を参照して、本発明の第１の実施形態について説明する。図１は、本実施形態における見逃し視聴サービスの構成図である。コンテンツ提供事業者Ａは、放送用コンテンツを放送局Ｂに提供する。提供方法は、オリジナルのコンテンツをテープ等の媒体に蓄積して提供してもよいし、あらかじめ放送に最適なフォーマットでエンコードされたコンテンツを、インターネット回線を通して提供しても良い。
放送局Ｂは、このコンテンツを番組として、地上デジタル等の放送電波に載せて、カバーエリア内の放送番組視聴者Ｅが所有する放送受信機に配信する。
視聴率調査事業者Ｃは、放送番組視聴者Ｅ内の調査協力者から、視聴中の番組をリアルタイムに検出して、視聴率を集計する。また、視聴率調査事業者は、調査協力者に関する年齢、性別、好んで視聴する番組のジャンル等の属性情報を保有しており、視聴率情報と合わせて、契約者に提供するサービスを行っている。本実施形態では、見逃し視聴サービス提供事業者Ｄが、視聴率情報の提供を受けている。

見逃し視聴サービス提供事業者Ｄは、コンテンツ提供者事業者Ａより、放送局Ｂに提供されたコンテンツと同内容の配信用コンテンツの提供を受ける。コンテンツのフォーマットは、放送用と同等のオリジナルを、見逃し視聴サービス提供事業者Ｄが、配信に最適な形式にエンコードしても良いし、あらかじめエンコードされたコンテンツがコンテンツ提供事業者Ａより提供されても良い。
見逃し視聴サービス提供事業者Ｄは、コンテンツを、サービスの契約者Ｆに、ユニキャストによるビデオ・オン・デマンド（ＶｏＤ）方式、もしくは、マルチキャストによるＩＰ放送方式により、インターネット回線を通して配信する。図１では、放送番組視聴者の一部が、見逃し視聴サービス契約をしているが、必ずしも、包含関係にある必要は無く、放送視聴エリア外に契約者がいても良い。

図２は、本実施形態におけるコンテンツ提供システムの構成を示す概略ブロック図である。以下、図２に従い、詳細に説明する。本実施形態におけるコンテンツ提供システムは、視聴者数予測装置２０と配信サーバー管理装置３０とマルチキャスト配信サーバー群４０とユニキャスト配信サーバー群５０とコンテンツサーバー６０とポータルサーバー７０とを備える。視聴率調査装置１０は、調査対象者宅のテレビジョン受像機８０に接続された視聴番組検出機９０に接続されている。また、受信装置１００は、インターネット２００により、マルチキャスト配信サーバー群４０、ユニキャストサーバー群５０、ポータルサーバー７０と通信可能に接続している。

視聴率調査装置１０は、図１の視聴率調査事業者Ｃ内に設置されている。視聴者数予測装置２０と配信サーバー管理装置３０とマルチキャスト配信サーバー群４０とユニキャスト配信サーバー群５０とコンテンツサーバー６０とポータルサーバー７０は、図１の見逃し視聴サービス提供事業者Ｄが設置している。テレビジョン受像機８０と視聴番組検出機９０は、放送番組視聴者Ｅの宅内に設置されている。受信装置１００は、見逃し視聴サービス契約者Ｆの宅内に設置されている据え置き型のテレビジョン受像機や、見逃し視聴サービス契約者Ｆが所有する携帯型のテレビジョン受信端末である。受信装置１００は、ストリーミング受信制御部１０９、ＨＴＭＬブラウザ１１０、受信品質計測部１１１、デコーダー１１２、ディスプレイ１１３を備える。

視聴率調査装置１０は、コンテンツ配信システムとは視聴者の構成が異なる他のシステムにより事前にコンテンツを配信した際の視聴率を算出する。本実施形態では、視聴者の構成が異なる他のシステムの例として、地上デジタル放送を対象とする。本実施形態における視聴率調査装置１０は、視聴率集計部１０１を備え、地上デジタル放送の放送番組の視聴者宅（調査対象者宅）から現在視聴中のチャンネルを示すチャンネル情報を収集する。このチャンネル情報は、本実施形態では、図２のテレビジョン受像機８０と接続された視聴番組検出機９０によって、検出する。視聴番組検出機９０は、テレビジョン受像機８０のリモコン信号や、テレビジョン受像機８０が出力する番組の音声情報から、選局されているチャンネルを特定する。チャンネル情報はインターネット回線や電話回線を通して、視聴率調査装置１０の視聴率集計部１０１に送られる。視聴率集計部１０１は、調査対象世帯数とチャンネル毎の視聴者数の比率から、時間帯毎の視聴率を計測し、各番組の平均視聴率を算出し、視聴者数予測装置２０に提供する。なお、本実施形態では、視聴率調査装置１０は、視聴率の情報を、番組として放送されたコンテンツの識別情報および時刻と対応付けて、視聴者数予測装置２０に提供する。
以上、図２の視聴率調査装置１０について説明したが、このような視聴率調査装置１０および視聴番組検出機９０を用いず、アンケート等の事後回収方式で、視聴者の属性別の視聴率を算出するようにしても良い。

次に、見逃し視聴サービスを提供するコンテンツ提供システムの構成について、図２を用いて説明する。視聴者数予測装置２０は、コンテンツが過去に配信された際の実績を示す実績情報に基づき、そのコンテンツを、このコンテンツ提供システムで配信した場合の視聴者数の予測値を算出する。なお、本実施形態では、実績情報として、視聴率調査装置１０から受けた視聴率情報を用いる。視聴者数予測装置２０は、視聴率情報蓄積部１０２、契約者情報ＤＢ１０３、コンテンツ情報ＤＢ１０４、視聴者数予測部１０５を備える。
配信サーバー管理装置３０は、視聴者数予測装置２０により算出された視聴者数の予測値に基づき、コンテンツの配信方法を決定する。さらに、配信サーバー管理装置３０は、配信に用いる配信サーバー数も決定する。配信サーバー管理装置３０は、受信状況計測部１０６、負荷分散方式決定部１０７、配信負荷計測部１０８を備える。
コンテンツサーバー６０は、コンテンツ提供事業者Ａから提供を受けた見逃し視聴用のコンテンツを記憶している。見逃し視聴サービスという特性上、地上デジタル等の本放送が終了してから、サービスの契約者を対象にコンテンツが配信される。

マルチキャスト配信サーバー群４０は、マルチキャストプロトコルを用いて、コンテンツのＩＰ放送を行う複数の配信サーバーを有する。ユニキャスト配信サーバー群５０は、ユニキャストプロトコルを用いて、コンテンツのビデオ・オン・デマンド配信を行う複数の配信サーバーを有する。なお、コンテンツは、インターネット回線を通して、マルチキャスト配信サーバー群４０のうちのいずれかの配信サーバーから、ＩＰ放送方式で、同時刻に一斉に複数の受信装置１００に配信されるか、もしくは、契約者から要求されたタイミングで、ユニキャスト配信サーバー群５０のうちのいずれかの配信サーバーから、ビデオ・オン・デマンド方式で、特定の受信装置１００に向けて配信される。なお、個々の配信サーバーは、配信サーバー管理装置３０が決定したコンテンツの配信方法に従い、時間帯によって、マルチキャスト配信サーバー群４０に属したり、ユニキャスト配信サーバー群５０に属したりする。
ポータルサーバー７０は、受信装置１００からの要求に応じて、ビデオ・オン・デマンド方式で提供されるコンテンツのコンテンツリストや、ＩＰ放送で配信されているコンテンツの放送スケジュールを示す番組表を表示するためのＨＴＭＬファイルを送信する。

図３は、見逃し視聴サービスを利用する際の受信装置１００の動作を説明するフローチャートである。まず、ステップＳ３０１では、契約者が受信装置１００のリモコンまたは操作ボタン等を操作して、ＨＴＭＬブラウザ１１０の起動を指示すると、受信装置１００は、この指示を受けて、ＨＴＭＬブラウザ１１０を起動する。次に、ステップＳ３０２で、契約者が受信装置１００のリモコンまたは操作ボタン等を操作し、ＨＴＭＬブラウザ１１０のブックマーク機能等を利用して、見逃し視聴サービスを提供するポータルサイトへの通信接続を指示すると、受信装置１００は、この指示を受けて、指示されたポータルサイトに通信接続する。なお、リモコンの特定のボタンまたは受信装置１００の特定の操作ボタンに見逃し視聴サービスが割り当てられていて、ステップS３０１にて契約者が該ボタンを操作し、該操作を受けて、受信装置１００が、ＨＴＭＬブラウザ１１０を起動すると同時にポータルサイトに接続するものとしても良い。図２のコンテンツ提供システムでは、受信装置１００は、ポータルサイトを提供しているポータルサーバー７０に接続する。

次に、ステップＳ３０３で、契約者が受信装置１００のリモコンまたは操作ボタン等を操作して、ビデオ・オン・デマンド方式で提供されるコンテンツのコンテンツリストや、ＩＰ放送で配信されているコンテンツの放送スケジュールを示す番組表の表示を指示すると、受信装置１００のＨＴＭＬブラウザ１１０は、この指示を受けて、コンテンツリストや番組表の情報をポータルサーバー７０から取得してディスプレイ１３０に表示する。なお、ポータルサーバー７０は、コンテンツリストや番組表の要求を受信装置１００から受けると、コンテンツ情報ＤＢ１０４からコンテンツのタイトルや配信方法の情報を取得して、コンテンツリストおよび番組表の情報を生成する。

次に、ステップＳ３０４で、契約者が受信装置１００のリモコンまたは操作ボタン等を操作して、コンテンツリストや番組表から、所望のコンテンツおよび配信方法（ビデオ・オン・デマンドまたはＩＰ放送）を選択する。この選択を受けると、ＨＴＭＬブラウザ１１０は、選択されたコンテンツおよび配信方法に応じたＵＲＬ（Ｕｎｉｖｅｒｓａｌ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｅｒ）をポータルサーバー７０から取得する。続いて、ステップＳ３０５で、図２のストリーミング受信制御部１０９は、マルチキャスト配信サーバー群４０およびユニキャスト配信サーバー群５０のうち、そのＵＲＬが示す配信サーバーに接続し、コンテンツの配信開始を要求する。なお、課金やＤＲＭ（Ｄｉｇｉｔａｌ Ｒｉｇｈｔｓ Ｍａｎａｇｅｍｅｎｔ；デジタル著作権管理）保護が必要なコンテンツの場合は、コンテンツが選択されたタイミングでそのための処理が別途必要となるが、本発明とは直接関係しないため説明は省略する。

次に、ステップＳ３０６で、マルチキャスト配信サーバー群４０またはユニキャスト配信サーバー群５０の配信サーバーからのコンテンツの配信が開始されると、ストリーミング受信制御部１０９は、コンテンツを受信する。さらに、デコーダー１１２は、受信したコンテンツを再生し、ディスプレイ１１３に再生結果の映像を表示する。ステップＳ３０７で、コンテンツ再生中に、ＨＴＭＬブラウザ１１０は、リモコンまたは受信装置１００の停止ボタンが操作されて、視聴停止が要求されたか否かを判定し、視聴停止を要求されていると判定したときは（Ｓ３０７−Ｙｅｓ）、ストリーミング受信制御部１０９にコンテンツ受信の停止を指示し、さらに、デコーダー１１２にコンテンツ再生の停止を指示して、ステップＳ３０３のコンテンツのリスト表示に戻る。また、ステップＳ３０７にて、コンテンツ再生中に視聴停止を要求されていない判定したときは（Ｓ３０７−Ｎｏ）、ＨＴＭＬブラウザ１１０は、ステップＳ３０８にて、コンテンツが最後まで再生されたか否かを判定し、最後まで再生されたと判定したときは（Ｓ３０８−Ｙｅｓ）、ステップＳ３０３に戻り、コンテンツリストやコンテンツの番組表をディスプレイ１３０に表示する。ステップＳ３０８にて、コンテンツが最後まで再生されていないと判定したときは（Ｓ３０８−Ｎｏ）、ＨＴＭＬブラウザ１１０は、ステップＳ３０７に戻って、視聴停止が要求されたか否かを再び判定する。

コンテンツの配信方式として、ＩＰ放送方式を用いる場合は、マルチキャストプロトコルを使用する。マルチキャスト配信サーバー群４０は、コンテンツサーバー６０に蓄積されているコンテンツを読みだして、１チャンネルにつき、１本のマルチキャストストリームを配信する。受信装置１００のストリーミング受信制御部１０９は、特定のチャンネルを受信するためのＩＰプロトコルであるＭＬＤ（Ｍｕｌｔｉｃａｓｔ Ｌｉｓｔｅｎｅｒ Ｄｉｓｃｏｖｅｒｙ）ｖ２やＩＧＭＰ（Ｉｎｔｅｒｎｅｔ Ｇｒｏｕｐ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）ｖ３のＪＯＩＮコマンドが、インターネット２００を構成するマルチキャストルーターに送信する。マルチキャストルーターは、このＪＯＩＮコマンドを受けると、特定のチャンネルのマルチキャストストリームを分配して、受信装置１００に配信する。なお、マルチキャストストリームの配信プロトコルとしては、一般的にＵＤＰ（Ｕｓｅｒ Ｄａｔａ Ｐｒｏｔｏｃｏｌ）が使用される。

ストリーミング受信制御部１０９は、ＩＰパケットに分割され、マルチキャストストリームとして配信されたコンテンツを受信する。ストリーミング受信制御部１０９は、これらのＩＰパケットのペイロードを連結して、１本のメディアストリームとして再構成し、デコーダー１１２へ出力する。なお、コンテンツは、ＭＰＥＧ（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ）２やＨ．２６４等の方式で圧縮されている。デコーダー１１２は、圧縮されているコンテンツを復号して、１フレーム単位の画面データを生成し、ディスプレイ１１３に出力する。ディスプレイ１１３は、入力された１フレーム単位の画面データを、順次表示する。

一方、コンテンツの配信方式として、ビデオ・オン・デマンド方式を用いる場合は、ユニキャストプロトコルを使用する。ストリーミング受信制御部１０９は、ＲＴＳＰ（Ｒｅａｌ Ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ）等のコンテンツ再生制御のためのプロトコルを使用して、ユニキャスト配信サーバー群５０の配信サーバーとセッションを確立し、再生コマンドを送信する。
ユニキャスト配信サーバー群５０の配信サーバーは、契約者の受信装置１００から再生コマンドを受信すると、再生コマンドを用いて要求されたＵＲＬに対応するコンテンツをコンテンツサーバー６０から取得し、要求元の受信装置１００に配信する。コンテンツは、ユニキャスト配信サーバー群５０の配信サーバーにより、ＵＤＰパケットもしくはＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）パケットに分割されて送信される。受信装置１００の受信制御部１０９は、これらのパケットを受信する。受信したパケットにより伝送されたコンテンツを、ＩＰ放送と同様に、デコーダー１１２が復号する。この復号結果を、ディスプレイ１１３が表示する。

なお、図２のマルチキャスト配信サーバー群４０とユニキャスト配信サーバー群５０は、便宜的に分割して示しているが、これらのサーバー群に属する配信サーバーの各々は、双方いずれの方式でも配信可能であり、視聴者数の予測値に応じて、どちらの方式にどれだけの数のサーバーを割り当てるかによって、配信サーバー毎の配信方式が決まる。

次に本放送の視聴率に基づく、見逃し視聴サービスの配信負荷の予測方法について説明する。図２の視聴者数予測装置２０の視聴率情報蓄積部１０２は、視聴率調査装置１０の視聴率情報集計部１０１より、見逃し視聴サービスで配信される番組毎の視聴率情報を、インターネット回線等を通じて受信し、蓄積する。契約者情報ＤＢ１０３は、契約者の総数や、契約者毎の個人情報を予め蓄積している。コンテンツ情報ＤＢ１０４は、配信対象の番組コンテンツに関する、本放送での放送時刻やタイトル、映画、スポーツ等のジャンル、出演者の情報等を予め蓄積している。

視聴者数予測部１０５は、コンテンツ情報ＤＢ１０４から、見逃し視聴配信予定のコンテンツ情報を順番に読みだす。読みだしたコンテンツに対応する視聴率情報を、コンテンツの識別情報、または、タイトルや放送時刻、チャンネルを参照して、視聴率情報蓄積部１０２から読みだす。
ここで、ｉ番目の配信対象コンテンツの全配信期間に渡っての総視聴者数の予測値Ｅ（ｉ）は、以下の式（１）で表される。なお、契約者の総数（全視聴者数）をＮ、ｉ番目の配信対象コンテンツの視聴率をＲ（ｉ）とする。また、式（１）は、サービスの契約者に対する配信においても、本放送と同様の視聴率が期待されるものとしたときの、予測値である。

また、マルチキャスト配信サーバー群４０とユニキャスト配信サーバー群５０とを合わせた配信サーバー群全体にかかる負荷は、特定の時間帯に配信される全コンテンツのアクセス数によって決まるため、配信時間帯毎の視聴者数を予測する必要がある。配信時間帯としては、例えば１時間単位を用いる。視聴者数予測部１０５は、下記の式（２）のように、視聴率と、コンテンツ配信システムの全視聴者数と、コンテンツの配信期間中のコンテンツ配信システムにおける配信時間帯毎の視聴者数の分布傾向とに基づき、各時間帯ｔにおける前記コンテンツの視聴者数の予測値Ｅｔを算出する。

ここで、Ｍは、コンテンツの総数であり、視聴者分布係数αｔ（ｉ）は、コンテンツの配信期間中の、ｔ番目の配信時間帯に依存して決まるｉ番目のコンテンツの視聴者数の分布傾向を示す係数であり、サービス利用者数が多い配信時間帯程、大きい値となる。αｔ（ｉ）の値の時間方向の分布は、過去の実測値や、インターネットサービス利用者の統計情報を基に決定され、視聴者数予測部１０５により予め記憶されている。例えば、視聴者数予測部１０５が予め記憶しているのは、図９（Ｄ）に示すように、時刻「０：００〜０：５９」はアクセス数「４００」、時刻「１：００〜１：５９」はアクセス数「２００」…時刻「２２：００〜２２：５９」はアクセス数「９００」、時刻「２３：００〜２３：５９」はアクセス数「５００」というような分布になる。なお、一般に、平日の夜間や、休日に大きい値になる。コンテンツのカテゴリーによっても、アクセスが集中する時間帯は異なるので、視聴者分布係数αｔ（ｉ）の値を、コンテンツのカテゴリー毎に記憶していてもよい。なお、本放送が特定の時間帯に１回限り放送されるのに対し、見逃し視聴サービスは通常一週間等の期間に渡って配信されるため、契約者が視聴する時間帯は分散する。ｉ番目のコンテンツの全配信期間の長さをＴ（ｉ）で表すと、視聴者分布係数αｔ（ｉ）は以下の式（３）を満たす。

ここで、式（３）のεは、本放送での平均視聴率に対する、見逃し視聴サービスでの平均視聴率の比率であり、過去の実績値から求められる定数である。例えば、見逃し視聴サービスの契約者のうち、ｉ番目のコンテンツを視聴する視聴者数の全契約者に対する割合が、本放送の視聴率と同等のときは、ε＝１である。特に、本放送視聴後に話題になり、見逃し視聴サービスでの利用者数が多いと見込まれるときは、εの値を１より大きい値である。視聴者数予測部１０５は、εの値に応じた視聴者分布係数αｔ（ｉ）の値を予め記憶していてもよい。また、視聴者数予測部１０５が、カテゴリー毎に加えて、εの値に応じた視聴者分布係数αｔ（ｉ）の値を予め記憶しているようにしてもよい。または、例えば、カテゴリーによる変動、曜日による変動、時刻による変動、配信開始からの経過時間による変動、εによる変動などの各変動を表す系列を予め記憶しておき、これらの系列の要素を乗算することで、視聴者数予測部１０５が、条件にあった視聴者分布係数αｔ（ｉ）を算出するようにしてもよい。

負荷分散方式決定部１０７は、コンテンツの配信方式及び配信サーバー数を、上述のようにして算出された予測視聴者数に基づき、決定する。図４は、負荷分散方式決定部１０７による配信方式および配信サーバー数の決定処理を説明するフローチャートである。
決定処理を開始すると、ステップＳ２０１において、負荷分散方式決定部１０７は、配信方式を決定する特定の配信期間ｔを選択する。例えば、配信するコンテンツが追加されたときは、追加されたコンテンツの配信を開始する時刻を、開始時刻とする配信期間ｔを選択する。次に、ステップＳ２０２において、負荷分散方式決定部１０７は、図２の視聴者数予測部１０５より、式（２）で求められる配信期間ｔにおける予測視聴者数Ｅｔを取得する。

次に、負荷分散方式決定部１０７は、ステップＳ２０３において、予測視聴者数Ｅｔが、図２のマルチキャスト配信サーバー群４０とユニキャスト配信サーバー群５０の配信能力を超えているか否かを判定する。例えば、配信サーバー群の配信能力は、全配信サーバーの最大配信可能数の合計値とする。予測視聴者数が配信能力を超えていないと判定したときは（Ｓ２０３−Ｎｏ）、ステップＳ２０４にて、負荷分散方式決定部１０７は、ユニキャスト配信に必要なサーバー数を割り当てて、ステップＳ２０６に遷移する。一方、ステップＳ２０３にて予測視聴者数が配信能力を超えていないと判定したときは（Ｓ２０３−Ｙｅｓ）、ステップＳ２０５にて、負荷分散方式決定部１０７は、不足分をマルチキャスト配信サーバーに割り当てて、ステップＳ２０６に遷移する。

例えば、配信サーバーの総数をＬ、各配信サーバー毎の最大配信可能数をＭとすると、ステップＳ２０３で、予測視聴者数が配信能力を超えていない、すなわちＥｔ ≦ Ｌ・Ｍを満たしていると判定したときは、負荷分散方式決定部１０７は、ステップＳ２０４にて、ユニキャスト配信サーバー群５０に、Ｅｔ／Ｍ＋１台の配信サーバーを割り当てる。ユニキャスト配信サーバー群５０に割り当てられた配信サーバーは、ユニキャストによるコンテンツの配信に用いられる。また、ステップＳ２０３で、予測視聴者数が配信能力を超えている、すなわちＥｔ ＞ Ｌ・Ｍを満たしていると判定したときは、負荷分散方式決定部１０７は、Ｓ２０５で、マルチキャスト配信サーバー群４０に、（Ｅｔ − Ｌ・Ｍ）／Ｍ＋１台の配信サーバーを割り当て、残りをユニキャスト配信サーバー群５０に割り当てる。マルチキャスト配信サーバー群４０に割り当てられた配信サーバーは、マルチキャストによるコンテンツの配信に用いられ、ユニキャスト配信サーバー群５０に割り当てられた配信サーバーは、ユニキャストによるコンテンツの配信に用いられる。

次に、ステップＳ２０６において、他の配信期間に対して配信方式決定処理を行うかどうかを判定し、行わない場合は処理を終了する。行う場合は、ステップＳ２０１に戻り他の配信期間を選択して同様の処理を繰り返す。
各配信サーバーがユニキャストもしくはマルチキャストどちらか一方の方式で配信することを前提に説明を行ったが、両方の方式を混在して配信できるものとしても良い。その場合は、マルチキャストに割り当てた配信サーバーの配信能力に空きがある場合、その分をユニキャスト配信に割り当てることができるものとする。
また、あらかじめ必要なユニキャスト配信サーバー数が予測できることから、配信期間が始まる日時までに、必要なサーバー数を導入する対策も可能である。

各コンテンツがユニキャストのビデオ・オン・デマンドのみで配信されているか、マルチキャストのＩＰ放送でも配信されているかは、契約者は受信装置１００のＨＴＭＬブラウザ１１０からポータルサーバー７０にアクセスしてコンテンツの一覧を閲覧することで知ることができる。ポータルサーバー７０は、負荷分散方式決定部１０７による配信方式の決定結果に基づき、各コンテンツの配信を要求するためのＵＲＬを取得して、コンテンツの一覧表画面のデータを生成する。図５に、ＨＴＭＬブラウザ１１０が、ポータルサーバー７０が生成したコンテンツの一覧表画面のデータに基づき生成するコンテンツの一覧表画面の例を示す。一覧表画面Ｇには、各行にコンテンツのタイトル名と、そのコンテンツに対応付けられた「ＶｏＤ」ボタンと「放送」ボタンとが配置されている。図５の一覧表画面Ｇの例では、１行目には、コンテンツのタイトル名「番組Ａ」の表示領域Ｔ１と、「ＶｏＤ」ボタンＢａ１と、「放送」ボタンＢｂ１とが配置され、２行目に、コンテンツのタイトル名「番組Ｂ」の表示領域Ｔ２と、「ＶｏＤ」ボタンＢａ２と、「放送」ボタンＢｂ２とが配置され、３行目に、コンテンツのタイトル名「番組Ｃ」の表示領域Ｔ３と、「ＶｏＤ」ボタンＢａ３と、「放送」ボタンＢｂ３とが配置され、というように、５行目まで配置されている。

契約者が、表示されている「ＶｏＤ」ボタンＢａ１〜Ｂａ５のうちのいずれかを選択すると、ＨＴＭＬブラウザ１１０は、選択された「ＶｏＤ」ボタンに対応付けられたＵＲＬを用いて、選択されたボタンに対応するタイトル名のコンテンツの配信を要求する。「ＶｏＤ」ボタンに対応付けられたＵＲＬは、ポータルサーバー７０が取得したコンテンツの配信を要求するためのＵＲＬであって、ユニキャスト配信サーバー群５０にコンテンツの配信を要求するためのＵＲＬである。このＵＲＬに従った要求を受けると、ユニキャスト配信サーバー群５０の配信サーバーは、このＵＲＬに対応するタイトルのコンテンツをビデオ・オン・デマンドで即時に配信する。

契約者が、「放送」ボタンを選択すると、ＨＴＭＬブラウザ１１０は、「放送」ボタンに対応付けられたＵＲＬに従い、そのタイトル名のコンテンツの配信を要求する。タイトルのコンテンツがＩＰ放送されている場合は、即時に選局されて視聴できるものとしても良いし、コンテンツの冒頭からの視聴を希望する視聴者のために、次の配信予定時刻を表示するものとしても良い。配信されていない時間帯であれば、例えば配信時刻に視聴予約することができたり、配信予定時刻を画面に表示されたりする。受信装置１００が録画機能を有している場合は、録画予約ができるようにしても良い。

以上のように、本実施形態では、本放送から視聴率から予測される視聴者数に基づき、ユニキャスト配信に必要な配信サーバー数を割り当てることができるが、さらに、実際の配信中のサーバーに係る負荷や、ネットワークに係る負荷を測定し、特定のサーバーにアクセスが集中しないようにする。
図２の配信サーバー管理装置３０の配信負荷計測部１０８は、ユニキャスト配信サーバー群５０から、配信サーバー毎の接続者数、ＣＰＵ使用率等の負荷情報を取得する。ユニキャスト配信サーバー群５０に対して受信装置１００から新たな視聴要求があると、配信負荷計測部１０８は、各配信サーバーの負荷情報を取得し、取得した負荷情報に基づき配信許容値を算出し、負荷分散方式決定部１０７に通知する。

図６は、配信負荷計測部１０８の配信許容値の算出処理を説明するフローチャートである。配信許容値の算出処理を開始すると、ステップＳ４０１において、配信負荷計測部１０８は、０番目のサーバーから処理するために、変数ｉに「０」を代入して初期化する。次に、Ｓ４０２において、配信負荷計測部１０８は、ｉ番目のユニキャスト配信サーバーに関して、最大配信可能数Ｍ（ｉ）と、現在の配信数ｍ（ｉ）とを比較する。この比較の結果、ｍ（ｉ）＜Ｍ（ｉ）が成り立たない、すなわちｍ（ｉ）＝Ｍ（ｉ）であれば、ｉ番目のサーバーは最大配信可能数の配信を行っており、新たな配信を追加することができないので、ステップＳ４０６に遷移し、配信負荷計測部１０８は、配信許容値ｃ（ｉ）を「０」とし、後述するステップＳ４０４に遷移する。なお、現在の配信数ｍ（ｉ）については、ポータルサーバー７０で、ＶｏＤの配信手続きを進めているユーザー数の情報を取得し、配信が予定されているものとして、配信している数に加算しても良い。その場合は、配信本数の少ないサーバー順から、平均的に加算するものとする。

一方、ステップＳ４０２における比較の結果、ｍ（ｉ） ＜ Ｍ（ｉ）が成り立つときは、ステップＳ４０３に進み、配信負荷計測部１０８は、追加可能な配信本数と、現在のＣＰＵ負荷から、配信許容値を算出する。現在のＣＰＵ負荷の空きをｄ（ｉ）とし、係数γ（ｉ）を用いて、配信許容値ｃ（ｉ）は下記の式（４）を用いて算出する。

係数γ（ｉ）は、配信サーバーのＣＰＵの能力に応じて決められる値であり、ＣＰＵの能力が高い配信サーバー程、大きい値を有するものとする。式（４）に従うと、ＣＰＵの能力が高く、ＣＰＵ負荷の空きが多く、現在の配信本数が少ない配信サーバー程、配信許容値は大きい値になる。
次に、ステップＳ４０４にて、配信負荷計測部１０８は、次の配信サーバーに対して、同様の処理を繰り返すものとし、変数ｉの値を一つ増加させる。次に、Ｓ４０５にて、配信負荷計測部１０８は、変数ｉの値がユニキャスト配信サーバー総数Ｎより小さいか否かを判定し、小さいときはステップＳ４０２に戻って、次の配信サーバーについて配信許容値を算出し、小さくないときは処理を終了する。

次に、図２の負荷分散方式決定部１０７の処理内容について説明する。負荷分散方式決定部１０７は、配信負荷計測部１０８より通知される、各配信サーバー毎の配信許容値に基づき、特定の配信サーバーに負荷がかかっている場合は、ビデオ・オン・デマンドでの新たな配信の要求があったときに、負荷の低い配信サーバーを使用する等して、負荷分散を図る。
具体的には、コンテンツ毎に異なるビットレートを有するものとすると、ビットレートが大きいコンテンツほど、大きい配信能力を配信サーバーに対して要求する。配信の要求があったコンテンツが配信サーバーに要求する配信能力をｋとすると、負荷分散方式決定部１０７は、ｋ ＜ ｃ（ｉ）を満たす、全ての配信サーバーの中から、ｃ（ｉ）の値が最も大きい配信サーバーが要求されたコンテンツを配信するように、配信の要求を割り当てる。なお、負荷分散方式決定部１０７は、ビットレートと、該ビットレートのコンテンツが廃止信サーバーに要求する配信能力ｋとを対応付けて、予め記憶している。

ｋ ＜ ｃ（ｉ）を満たす配信サーバーが見つからなかった場合は、ユニキャストでの配信は不可能であると判断し、ポータルサーバー７０を介して、受信装置１００に対してエラーを返すか、マルチキャスト配信サーバーでの配信予定等の情報を通知する。受信装置１００はそれらの情報を、視聴者に提示し、マルチキャストで視聴するか否かや、視聴時刻を視聴者に選択させて、視聴予約を行う。受信装置１００が録画機能を備えている場合は、予約録画ができるようにしてもよい。

さらに、ネットワークにかかる負荷を考慮して、ユニキャスト配信数を調整できるようにしても良い。具体的には、受信装置１００のストリーミング受信制御部１０９は、ＲＴＰパケットのシーケンス番号でパケットロス率を計測したり、ＲＴＣＰプロトコルを用いてパケットの遅延時間を計測したりして、受信品質に関する情報を得る。受信品質計測部１１１は、それらの受信品質に関する情報を、ストリーミング受信制御部１０９から受信して、配信サーバーのＩＰアドレス等のサーバーを特定できる情報と共に、配信サーバー管理装置３０の受信状況計測部１０６に通知する。

受信状況計測部１０６は、各受信装置１００から受信した、上記の受信品質に関する情報を、コンテンツ毎のネットワーク負荷情報として数値化して、負荷分散方式決定部１０７に通知する。例えば、パケットの遅延時間から、配信サーバー毎にかかる負荷を推定することができる。受信品質計測部１１１から取得した、ＲＴＣＰパケットの往復遅延時間を、配信サーバー毎に集計し、平均遅延時間を求める。配信サーバー毎の平均遅延時間を正規化することによって、ネットワーク負荷を評価する負荷パラメーターとして使用することができる。同様にパケットロス率を用いても、ネットワーク負荷を評価する負荷パラメーターとして使用することができる。
パケットロス率、遅延時間等の、ネットワーク負荷から推定される、ｉ番目のサーバー毎の負荷パラメーターをｕ（ｉ）とすると、式（４）にｕ（ｉ）を加えることによって、配信許容値ｃ（ｉ）は下記の式で算出される。

このように、見逃し視聴サービスにおいて、アクセスが集中するコンテンツであっても、該コンテンツが過去に配信された際の実績を示す実績情報に基づき、コンテンツを配信した場合の視聴者数の予測値を算出し、該予測値に基づき、コンテンツの配信方法を決定するので、ビデオ・オン・デマンド方式で配信するユニキャスト配信サーバーの数をアクセスの集中に対応した台数とすることができ、視聴者の利便性を損なうことなく、アクセスの集中に対応することができる。例えば、ビデオ・オン・デマンドで視聴を希望する視聴者は、あらかじめ視聴予約等の操作をしなくても、アクセスの集中に対応した台数の配信サーバーがユニキャスト配信サーバーとして稼動しているので、即時に高品質に視聴することができる。
また、見逃し視聴サービスを提供するサービス事業者は、視聴者数の予測値に基づき、配信サーバーを用意すればよいので、余分な配信サーバーを稼動させること無く、最小限の配信サーバー数で運営できる。

［第２の実施形態］
以下、図面を参照して、本発明の第２の実施形態について説明する。第１実施形態では、視聴者を予測するための指標として、本放送での番組コンテンツの平均視聴率情報のみを用いたが、本実施形態では、さらに、視聴者の年齢、性別毎の視聴率や、契約者の嗜好情報等を用いて、より精度良く、視聴者数を予測する。
図７は、本実施形態におけるコンテンツ提供システムの構成を示す概略ブロック図である。本実施形態におけるコンテンツ提供システムは、視聴率調査装置１０ａ、視聴者数予測装置２０ａ、配信サーバー管理装置３０、マルチキャスト配信サーバー群４０、ユニキャスト配信サーバー群５０、コンテンツサーバー６０、ポータルサーバー７０、テレビジョン受像機８０、視聴番組検出機９０、受信装置１００を有する。同図において、図２の各部に対応する部分には同一の符号（３０〜１００、１０４、１０６〜１１３、２００）を付け、その説明を省略する。

視聴率調査装置１０ａは、視聴率集計部１０１ａ、視聴者属性記憶部２０１、属性別視聴率情報集計部２０２を備える。視聴者数予測装置２０ａは、視聴率情報蓄積部１０２ａ、契約者情報ＤＢ（Ｄａｔａ Ｂａｓｅ；データベース）１０３ａ、コンテンツ情報ＤＢ１０４、視聴者数予測部１０５ａを備える。

視聴者属性記憶部２０１は、あらかじめアンケート等で調査したり、オンラインで視聴率調査対象者に入力させたりすることで取得した調査対象者の年齢、性別等の調査対象者の属性情報を蓄積している。これらの属性情報は、調査対象者のＩＤと紐付けて蓄積されている。第１の実施形態と同様に、視聴番組検出機９０は、テレビジョン受像機８０のリモコン信号や番組の音声情報から、選局されたチャンネルを特定し、インターネット回線や電話回線を通して、視聴率集計部１０１に送る。このとき、特定されたチャンネルを示す情報は、調査対象者を識別するＩＤ（Identifier；識別情報）と紐付けて送られ、視聴率調査装置１０ａにより集計される。複数人の家族がいて、そのうちの誰が実際に見ているかを特定するために、例えば、視聴番組検出機９０に、視聴中の人物が、自分のＩＤを入力するようにしてもよいし、携帯電話にリモコン機能を搭載し、携帯電話からリモコン信号と同時に、視聴者の情報を送信することで、選局操作を行った個人を特定できるようにしても良い。

属性別視聴率情報集計部２０２は、視聴率集計部１０１が受信したチャンネルを示す情報およびＩＤと、視聴者属性記憶部２０１が蓄積している属性情報とを合わせて、属性毎の視聴率を算出する。例えば、年齢毎の視聴率を算出すると、図８の年齢別視聴率のグラフＧ１のようになる。
視聴者数予測装置２０ａの視聴率情報蓄積部１０２ａは、視聴率調査装置１０ａの視聴率情報集計部２０１より、年齢別視聴率の情報を受け取り、記憶する。年齢別視聴率の情報は、図９（Ａ）の例のように、特定の番組Ａの年齢層及び性別で区分された視聴率を百分率で示したデータ構造を有している。例えば、区分「０」は、年齢層「０〜９」、男「０」％、女「０」％であり、区分「１」は、年齢層「１０〜１９」、男「２」％、女「１」％であり、区分「２」は、年齢層「２０〜２９」、男「３」％、女「２」％である。例えば、上述の年齢層「１０〜１９」の男「２」％は、１０歳〜１９歳の男性の視聴率調査対象者のうち２％が視聴したことを示している。視聴率情報蓄積部２０４は、このコンテンツ配信システムにて提供中のコンテンツの年齢別視聴率の情報を蓄積している。

契約者情報ＤＢ１０３ａは、見逃し視聴サービス契約者のユーザーＩＤに紐付けられて、年齢、性別、好んで視聴するコンテンツのジャンル等の属性情報が蓄積されている。例えば図９の（Ｂ）のように、ユーザーＩＤ「Ｕｓｅｒ０００００」に紐付けられて、年齢「２５」、性別「男」、ジャンル「スポーツ」が蓄積され、ユーザーＩＤ「Ｕｓｅｒ００００１」に紐付けられて、年齢「３３」、性別「男」、ジャンル「ドラマ」が蓄積されている。
視聴者数予測部１０５ａは、視聴率情報蓄積部１０２ａから上記の番組毎の視聴率情報と視聴者の属性情報を取得し、契約者情報ＤＢ１０３ａから上記の契約者の属性情報を取得する。それらの情報から、見逃し視聴サービスで提供する番組各々の視聴者数の期待値を算出する。

図１０は、視聴者数予測部１０５ａによる視聴者数予測処理を説明するフローチャートである。処理を開始すると、まず、視聴者数予測部１０５ａは、配信対象コンテンツの中から未処理のものを一つ選択する（Ｓ５０１）。次のステップＳ５０２、Ｓ５０３の視聴率情報に関する処理と、Ｓ５０４、Ｓ５０５の契約者情報に関する処理を並行して行う。なお、本実施形態では、これらの処理を並行して行うとして説明したが、順次行うようにしてもよい。

ステップＳ５０２では、視聴者数予測部１０５ａは、ステップＳ５０１にて選択した配信対象コンテンツに対応する番組の視聴率情報を、視聴率情報蓄積部１０２ａから取得する。ここで取得する視聴率情報は、例えば、図８のグラフＧ１のような視聴者の年齢層（属性区分）毎の視聴率の分布データである。この分布データは、各年齢層に該当する視聴率調査対象者のうち、対象コンテンツを視聴した視聴した人の割合を示している。次に、視聴者数予測部１０５ａは、属性区分毎の視聴期待値を算出する（Ｓ５０３）。視聴期待値は、契約者を特定の属性に従って分類し、各属性毎の予測される視聴率である。視聴率情報が、図８の例のように年齢層毎の視聴率であり、その年齢層の区分そのまま用いて契約者を属性毎に分類する場合は、視聴率情報をそのまま視聴期待値として用いる。例えば、視聴率調査事業者Ｃにより提供される視聴率情報が１歳毎の視聴率であり、１０歳毎の年齢層を属性区分として用いる場合は、１０歳毎の視聴率の平均値を算出して、視聴期待値とする。

一方、ステップＳ５０４では、視聴者数予測部１０５ａは、契約者情報蓄積部１０２ａから、契約者に関する情報を取得する。本実施形態では、契約者の属性として年齢情報のみを用いているので、各契約者の年齢情報を取得する。次に、視聴者数予測部１０５ａは、取得した契約者に関する情報に基づき、属性区分毎の契約者数を算出する（Ｓ５０５）。すなわち、本実施形態では、各契約者の年齢情報に基づき、年齢層毎の契約者数を算出する。このとき、属性区分である年齢層はステップＳ５０３で使用したものと同一の区分を用いる。すなわち、本実施形態では、図８のグラフＧ２のように、１０歳毎の区分で、契約者数を算出する。

ステップＳ５０３およびＳ５０５の処理を行った後、視聴者数予測部１０５ａは、ステップＳ５０３で求めた属性区分毎の視聴率と、ステップＳ５０５で求めた属性区分毎の契約者数とについて、属性区分毎に両データの対応する値を掛け合わせて、属性区分毎の視聴者数を算出する。本実施形態では、図８のグラフＧ３のように、年齢層毎の視聴者数を算出する。次に、視聴者数予測部１０５ａは、図８の欄Ｇ４のように、全属性区分の視聴者数の総和を算出することによって、該当コンテンツの見逃し視聴サービスにおける視聴者数の予測値を算出する。図８のＧ４のように予測値を求めることができる。以上の処理を式で表すと、ｉ番目の配信対象コンテンツの予測視聴者数は、以下の式（６）のようにして算出する。

Ｒ（ｉ，ｊ）は、ｉ番目のコンテンツのｊ番目の属性区分における視聴率である。Ｓ（ｊ）はｊ番目の属性区分における契約者数、Ｃは総区分数である。ステップＳ５０１で選択した配信対象コンテンツについて予測視聴者数を算出したら、ステップＳ５０７にて、視聴者数予測部１０５ａは、他に未処理の配信対象のコンテンツがあるか否かを判定する。ある場合は（Ｓ５０７−Ｙｅｓ）、ステップＳ５０１に戻り、未処理のコンテンツを選択して、同様の処理を繰り返す。無い場合は（ｓ５０７−Ｎｏ）、処理を終了する。

なお、本実施形態においても、第１の実施形態と同様に、視聴者数予測部１０５ａは、特定配信時間帯ｔにおける係数αｔ（ｉ）を用いて、期間ｔにおける予測される総視聴者数Ｅｔを、期間ｔにおける配信対象コンテンツの総数をＭとして、以下の式（７）で算出する。

本実施形態では、属性区分として年齢層のみを用いて説明したが、性別のみを用いてもよいし、年齢層と性別等、複数の属性を組み合わせた属性区分を用いても、同様に属性区分毎の視聴者数の予測値を算出し、それらの合計を求めることで、総視聴者数を予測することができる。
また、別の算出方法として、以下の式（８）を用いて、各契約者の属性区分から視聴率を求め、契約者分の視聴率の総和を計算しても同一の予測値を得ることができる。

Ｉ（ｉ，ｊ）は契約者ｊの、コンテンツｉに対する属性区分に該当する視聴率、Ｎは総契約者数である。

［第２の実施形態の変形例］
以上、視聴率の属性情報に対応した契約者の属性情報を用いて、期待される視聴者数を求める一例について説明したが、第２の実施形態の変形例として、ジャンルや出演者などコンテンツの嗜好に関する属性情報を用いて、より精度良く、視聴者数を予測する例を説明する。図９（Ｂ）のジャンル列は、契約者が好んで視聴するコンテンツのジャンルを示す属性値である。ジャンルについては、例えば、アンケートの回答から取得したり、過去の視聴履歴から推測したりできる。

また、該当コンテンツのジャンルと、契約者のジャンル属性を比較することにより、各契約者が該当コンテンツを視聴する確率を推定することができる。該当コンテンツのジャンルと、契約者のジャンル属性が一致している場合は、期待値を１以上の値、例えば１．５と設定し、一致していない場合は１より低い値、例えば０．５と設定する。また、図９（Ｂ）の例では、契約者情報ＤＢ１０３ａが記憶するジャンルとして、各契約者につき一つのみを示しているが、複数であってもよい。また、契約者情報ＤＢ１０３ａが、過去の視聴履歴から算出された各々のジャンルの視聴の期待値を示す情報を保持するようにしてもよい。

図１１は、本変形例における視聴者数予測部１０５ａの契約者の嗜好情報を用いた視聴者数の予測処理を説明するフローチャートである。処理を開始すると、視聴者数予測部１０５ａは、視聴者数の予測値を０にリセットする（Ｓ１０１）。次に、視聴者数予測部１０５ａは、例えばユーザーＩＤの順番などに従い、未処理の契約者情報のなかから、ひとつのユーザーＩＤを選択する（Ｓ１０２）。次に、視聴者数予測部１０５ａは、選択したユーザーＩＤを持つ契約者の属性情報を、契約者情報ＤＢ１０５ａから抽出し、対象としているコンテンツと、該契約者の抽出された属性情報に対応する視聴率を、視聴率情報蓄積部１０２ａから取得する（Ｓ１０３）。

次に、視聴者数予測部１０５ａは、該契約者のジャンル属性に対応する視聴期待値を上記の例のようにして求める（Ｓ１０４）。次に、視聴者数予測部１０５ａは、ステップＳ１０３で取得した視聴率と、ステップＳ１０４で取得した期待値の積算値を計算し、求めた値を、視聴者数予測値に加算する（Ｓ１０５）。次に、視聴者数予測部１０５ａは、未処理の契約者情報があるか否かを判定し（Ｓ１０６）、未処理の契約者情報があると判定したときは（Ｓ１０６−Ｙｅｓ）、ステップＳ１０２に戻り、次に同様の処理を行う契約者情報のユーザーＩＤを選択する。一方、ステップＳ１０６にて、最後のユーザーＩＤに到達しており、未処理の契約者情報がないと判定したときは（Ｓ１０６−Ｎｏ）、最終的にステップＳ１０５で得られた加算値を視聴者数の予測値とする。上記の視聴者の予測処理を式で表すと、ｉ番目のコンテンツの予測視聴者数Ｅ（ｉ）の算出は、下記の式（９）により表される。

Ｉ（ｉ，ｊ）は契約者ｊの属性区分に該当する視聴率、Ｇ（ｊ，ｉ）は契約者ｊのジャンル属性に対応する視聴期待値、Ｎは総契約者数である。
第１の実施形態と同様に、特定配信時間帯ｔにおける係数αｔ（ｉ）を用いて視聴者数予測部１０５は、特定配信時間帯ｔ各々における、予測される視聴者数Ｅｔを、コンテンツの総数をＭとして、下記の式（１０）により算出する。

なお、Ｍは期間ｔにおける配信対象コンテンツの総数である。
以上の例では、属性値として契約者の年齢と性別、コンテンツの嗜好ジャンルを用いたが、属性値はこれらに限定するわけではなく、例えば、契約者がよく視聴する時間帯と該当番組の放送時間帯の一致度で視聴期待値を設定することもできる。

［第３の実施形態］
第３の実施形態におけるコンテンツ配信システムでは、コンテンツまたは該コンテンツに関連する関連コンテンツが配信された際の、当該システムの視聴者の視聴実績を示す情報を実績情報として用いる。すなわち、コンテンツ配信システムの視聴者である契約者が既に地上デジタル等で対象の番組を見ていたり、見逃し視聴サービスで視聴済みであったりした場合は、対象のコンテンツを再度視聴する確率が低いものとして、アクセス数の予測値に反映する。また、連続ドラマ等のシリーズコンテンツであれば、次の回を視聴する確率が高いものとして、予測値に反映する。

図１２は、本実施形態におけるコンテンツ配信システムの構成を示す概略ブロック図である。同図において、図２の各部に対応する部分には、同じ符号を付し、説明を省略する。本実施形態におけるコンテンツ配信システムは、図２に示すコンテンツ配信システムとは、視聴者数予測装置２０に替えて視聴者数予測装置２０ｂを備え、受信装置１００に替えて受信装置１００ｂを備える点が異なる。視聴者数予測装置２０ｂは、視聴率情報蓄積部１０２、契約者情報ＤＢ１０３、コンテンツ情報ＤＢ１０４、視聴者数予測部１０５ｂ、視聴履歴蓄積部３０１を備える。受信装置１００ｂは、本放送視聴番組検出部３１０、デジタルチューナー３１１、ＩＰ放送視聴コンテンツ検出部３１２、ストリーミング受信制御部１０９、ＨＴＭＬブラウザ１１０、受信品質測定部１１１、デコーダー１１２ｂ、ディスプレイ１１３を備える。

受信装置１００ｂの本放送視聴番組検出部３１０は、契約者が地上デジタル等の本放送で視聴中の番組情報を、デジタルチューナー３１１からの信号を受けて検出し、視聴者数予測装置２０ｂの視聴履歴蓄積部３０１に、該契約者のユーザーＩＤとともに通知して、視聴履歴に関する情報として記憶させる。通知する番組情報として、チャンネルの番号や番組名に加えて、視聴開始時刻、連続視聴時間や視聴者情報を同時に送るものとしても良い。同様に、ＩＰ放送視聴コンテンツ検出部３１２は、契約者がＩＰ放送で視聴中のコンテンツを識別する情報を、ストリーミング受信制御部３１３からの情報を受けて検出し、視聴履歴蓄積部３０１に該契約者のユーザーＩＤとともに通知して、視聴履歴に関する情報として記憶させる。例えば、視聴履歴蓄積部３０１は、図９（Ｃ）に示すように、コンテンツを識別する番組名と、そのコンテンツをＩＰ放送で視聴したユーザーＩＤの一覧（番組名「Ａ」とＩＰ放送での視聴者「Ｕｓｅｒ００００３、Ｕｓｅｒ００００５…Ｕｓｅｒ１３４５７」）を記憶する。

視聴履歴蓄積部３０１では、通知された契約者のユーザーＩＤとそれらの視聴履歴に関する情報を紐付けて管理する。また、ＩＰ放送視聴コンテンツ検出部３１２が検出するコンテンツは、マルチキャスト配信のＩＰ放送のコンテンツに特に限定するものではなく、ユニキャスト配信によるビデオ・オン・デマンドのコンテンツを含めても良い。

視聴履歴蓄積部３０１に蓄積された、契約者毎の視聴履歴に関する情報から、視聴者数予測部１０５ｂは、契約者毎に、対象コンテンツの視聴確率を予測する。例えば、過去に視聴している場合は、見逃し視聴サービスでの視聴確率を０もしくは、０．５以下の低い値に設定し、連続回の番組の過去の回を視聴している場合は、視聴確率を１もしくは、０．５以上の高い値に設定する。過去の視聴履歴情報が無い場合の視聴確率は、視聴率情報蓄積部１０２から、第１の実施形態における視聴者数予測部１０５と同様にして、本放送の対象コンテンツの平均視聴率を取得し、その値を視聴確率とする。

契約者ｊのコンテンツｉの視聴確率をＫ（ｉ，ｊ）とすると、視聴者数予測部１０５ｂは、式（２）の配信時間帯によって決まる係数αｔ（ｉ）及びＭ、Ｎを用いて、配信時間帯ｔにおける予測視聴者数Ｅｔを、以下の式（１１）で算出する。

［第４の実施形態］
第４の実施形態は、第１の実施形態に対する第３の実施形態と同様に、第２の実施形態に対して第３の実施形態の構成を追加した構成である。図１３は、第４の実施形態におけるコンテンツ配信システムの構成を示す概略ブロック図である。図７に示した第２の実施形態におけるコンテンツ配信システムに対して、視聴履歴蓄積部３０１、放送視聴番組検出部３１０と、デジタルチューナー３１１と、ＩＰ放送視聴コンテンツ検出部３１２が追加されているが、これらは、第３の実施形態の図１２で示した各部に該当するものと同等である。

第２の実施形態の式（８）の、契約者ｊの、コンテンツｉに対する属性区分に該当する視聴率Ｉ（ｉ，ｊ）を、第３の実施形態と同様の過去の視聴履歴に基づく視聴確率Ｋ（ｉ，ｊ）に置き換える。すなわち、契約者がコンテンツｉを既に視聴していたり、コンテンツｉに関連するコンテンツを過去に視聴していたりする場合は、第３の実施形態で記載した視聴確率Ｋ（ｉ，ｊ）を使用し、それらに該当しない場合は、Ｋ（ｉ，ｊ）を第２の実施形態で記載した視聴率Ｉ（ｉ，ｊ）の値に設定する。式（２）の配信時間帯によって決まる係数αｔ（ｉ）及びＭ、Ｎを用いて、視聴者数予測部１０５ｃは、配信時間帯ｔにおける予測視聴者数Ｅｔを、以下の式（１２）で算出する。

［第５の実施形態］
また、第５の実施形態として、視聴率調査装置を用いずに、契約者の視聴履歴情報のみを用いてアクセス数を予測するものとしても良い。その場合の構成図を、図１４に示す。図１４に示すように、本実施形態におけるコンテンツ配信システムは、図１３に示した第４の実施形態におけるコンテンツ配信システムに対して、視聴者数予測装置２０ｄが、視聴率情報蓄積部１０２ａを備えず、視聴率調査装置１０ａから視聴率情報の提供を受けない点が異なる。視聴者数予測装置２０ｄの視聴履歴蓄積部３０１には、第３及び第４の実施形態と同様に、契約者の本放送及びＩＰ放送での視聴履歴情報が蓄積されている。同時に、契約者の視聴率情報も集計するものとする。すなわち、視聴者数予測部１０５ｃは、第１〜第４の実施形態で用いた視聴率調査会社からの視聴率情報の代用として、契約者内での視聴率情報を用いて、同様の方法で、視聴者数を予測する。
また、受信装置１００ｂがデジタルチューナー３１１及び本放送視聴番組検出部３１０を備えず、ネットワーク配信されるコンテンツの視聴率及び視聴履歴情報のみに基づき、視聴者数を予測するものとしても良い。あるいは、ＩＰ放送視聴コンテンツ検出部３１２を備えず、本放送の視聴率及び視聴履歴情報のみに基づき予測するものとしても良い。

以上、本発明のコンテンツ配信システムの５つの実施形態について説明したが、本発明の各処理部の構成はこれに限定されるものではなく、物理的に複数の装置が分担して機能するものとしても良いし、複数の機能を兼用する機能部で構成されていても良い。また、本発明の、視聴者数予測装置と配信サーバー管理部が一体となったシステム構成としても良い。

また、図２における視聴者数予測部１０５、受信状況計測部１０６、負荷分散方式決定部１０７、配信負荷計測部１０８、ストリーミング受信制御部１０９、HTMLブラウザ１１０、受信品質計測部１１１、および図７における視聴者数予測部１０５ａ、受信状況計測部１０６、負荷分散方式決定部１０７、配信負荷計測部１０８、ストリーミング受信制御部１０９、HTMLブラウザ１１０、受信品質計測部１１１、および図１２における視聴者数予測部１０５ｂ、受信状況計測部１０６、負荷分散方式決定部１０７、配信負荷計測部１０８、ストリーミング受信制御部１０９、HTMLブラウザ１１０、受信品質計測部１１１、本放送視聴番組検出部３１０、ＩＰ放送視聴コンテンツ検出部３１２、および図１３における視聴者数予測部１０５ｃ、受信状況計測部１０６、負荷分散方式決定部１０７、配信負荷計測部１０８、ストリーミング受信制御部１０９、HTMLブラウザ１１０、受信品質計測部１１１、本放送視聴番組検出部３１０、ＩＰ放送視聴コンテンツ検出部３１２、および図１４における視聴者数予測部１０５ｃ、受信状況計測部１０６、負荷分散方式決定部１０７、配信負荷計測部１０８、ストリーミング受信制御部１０９、HTMLブラウザ１１０、受信品質計測部１１１、本放送視聴番組検出部３１０、ＩＰ放送視聴コンテンツ検出部３１２、の機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することにより各部の処理を行ってもよい。なお、ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものとする。

また、「コンピュータシステム」は、ＷＷＷシステムを利用している場合であれば、ホームページ提供環境（あるいは表示環境）も含むものとする。
また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の通信線のように、短時間の間、動的にプログラムを保持するもの、その場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリのように、一定時間プログラムを保持しているものも含むものとする。また上記プログラムは、前述した機能の一部を実現するためのものであっても良く、さらに前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるものであっても良い。

以上、この発明の実施形態を図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計変更等も含まれる。

１０、１０ａ…視聴率調査装置
２０、２０ａ、２０ｂ、２０ｃ、２０ｄ…視聴者数予測装置
３０…配信サーバー管理装置
４０…マルチキャスト配信サーバー群
５０…ユニキャスト配信サーバー群
６０…コンテンツ配信サーバー
７０…ポータルサーバー
８０…テレビジョン受像機
９０…視聴番組検出機
１００、１００ｂ…受信装置
１０１…視聴率集計部
１０２、１０２ａ…視聴率情報蓄積部
１０３、１０３ａ…契約者情報ＤＢ
１０４…コンテンツ情報ＤＢ
１０５、１０５ｂ、１０５ｃ…視聴者数予測部
１０６、１０５ａ…受信状況計測部
１０７…負荷分散方式決定部
１０８…配信負荷計測部
１０９…ストリーミング受信制御部
１１０…ＨＴＭＬブラウザ
１１１…受信品質計測部
１１２、１１２ｂ…デコーダー
１１３…ディスプレイ
２００…インターネット
２０１…視聴者属性記憶部
２０２…属性別視聴率情報集計部
３０１…視聴履歴蓄積部
３１０…本放送視聴番組検出部
３１１…デジタルチューナー
３１２…ＩＰ放送視聴コンテンツ検出部

Claims (7)

1. コンテンツまたは該コンテンツに関連する関連コンテンツが過去に配信された際の実績を示す実績情報に基づき、前記コンテンツを配信した場合の視聴者数の予測値を算出する視聴者数予測装置と、
   前記算出された視聴者数の予測値に基づき、前記コンテンツの配信方法を決定する配信サーバー管理装置と、
   通信網を介して接続された端末装置に、前記決定された配信方法を用いて、前記コンテンツを配信する配信サーバーと
   を有することを特徴とするコンテンツ配信システム。
2. 前記実績情報は、当該システムとは視聴者の構成が異なる他のシステムにより事前に前記コンテンツを配信した際の視聴率であることを特徴とする請求項１に記載のコンテンツ配信システム。
3. 前記視聴率は、視聴者の属性区分毎の視聴率であることを特徴とする請求項２に記載のコンテンツ配信システム。
4. 前記属性は、年齢、性別のうち、少なくとも１つを含むことを特徴とする請求項３に記載のコンテンツ配信システム。
5. 前記視聴者数予測装置は、前記視聴率と、当該システムの全視聴者数と、前記コンテンツの配信期間中の当該システムにおける配信時間帯毎の視聴者数の分布傾向とに基づき、各時間帯における前記コンテンツの視聴者数の予測値を算出することを特徴とする請求項２から請求項４のいずれかの項に記載のコンテンツ配信システム。
6. 前記実績情報は、前記コンテンツまたは該コンテンツに関連する関連コンテンツが配信された際の、当該システムの視聴者の視聴実績を示す情報であることを特徴とする請求項１に記載のコンテンツ配信システム。
7. 視聴者数予測装置と、配信サーバー管理装置と、配信サーバーとを有するコンテンツ配信システムにおけるコンテンツ配信方法であって、
   前記視聴者数予測装置が、コンテンツまたは該コンテンツに関連する関連コンテンツが過去に配信された際の実績を示す実績情報に基づき、前記コンテンツを配信した場合の視聴者数の予測値を算出する第１の過程と、
   前記配信サーバー管理装置が、前記算出された視聴者数の予測値に基づき、前記コンテンツの配信方法を決定する第２の過程と、
   前記配信サーバーが、通信網を介して接続された端末装置に、前記決定された配信方法を用いて、前記コンテンツを配信する第３の過程と
   を有することを特徴とするコンテンツ配信方法。

Images