JP2016046624A - コンテンツ配信サーバ、受信装置、及びコンテンツ配信プログラム - Google Patents

Abstract

【課題】コンテンツ配信サーバに接続された各受信装置に配信されるコンテンツの到達時間のばらつきを抑制させる。【解決手段】受信装置からの接続要求を受信し、前記受信装置それぞれとの間のセッションを確立するセッション制御手段と、前記セッション制御手段によりセッションを確立した受信装置に前記コンテンツを配信する前に、前記受信装置に対して遅延量確認要求を行い、前記遅延量確認要求に対する応答情報に基づいて前記受信装置の受信遅延量を計測する遅延量計測手段と、前記遅延量計測手段により得られた受信遅延量を用いて、所定の配信周期内で前記受信装置に対して前記コンテンツが配信されるように配信時刻を設定する配信時刻設定手段と、前記配信時刻設定手段により得られる配信時刻に基づき、前記受信装置に前記コンテンツを送信するコンテンツ送信手段とを有する。【選択図】図２

Description

本発明は、コンテンツ配信サーバ、受信装置、及びコンテンツ配信プログラムに係り、特にコンテンツ配信サーバに接続された各受信装置に配信されるコンテンツの到達時間のばらつきを抑制させるためのコンテンツ配信サーバ、受信装置、及びコンテンツ配信プログラムに関する。

従来、種々のコンテンツを受信装置に配信するサービスが存在する。このような配信サービスでは、コンテンツ配信サーバからユーザの受信装置に情報を直接送り届けるプッシュ型の情報配信技術が知られている。例えば、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）コンテンツ等の配信情報としては、例えばテレビ放送番組の関連情報や個々のユーザニーズに応じた天気の最新情報、交通の最新情報、アプリケーション、又は、ユーザが要求する種々のデータが挙げられる。

大規模なＩＰコンテンツのプッシュ型情報配信サービスでは、１つのコンテンツ配信サーバに多数の受信装置が通信セッションを確立し、ＩＰコンテンツを配信する形となる。リアルタイムに配信されるＩＰコンテンツに関しては、コンテンツ配信サーバから受信装置へ一斉に配信が実施される。しかしながら、コンテンツ配信サーバとセッションを確立している各受信装置は、同じ配信サーバに接続していても、それぞれの受信装置との通信距離が異なる。例えば、東京にコンテンツ配信サーバが配置される場合に、受信装置が東京、大阪、沖縄等にあれば、通信距離が異なる。したがって、コンテンツ配信サーバとの通信所要時間（例えば、ＲＴＴ（Ｒｏｕｎｄ Ｔｒｉｐ Ｔｉｍｅ））が、受信装置毎に異なることになり、ＩＰコンテンツが到達するタイミングも受信装置毎に異なる。また、各受信装置へデータを配信する際の所要時間は、通信経路の状況によって毎回変動するため、実際には一定とならない。

このようなことから、コンテンツ配信サーバから一斉に配信されたＩＰコンテンツが、各受信装置において、到達する時間にばらつきがあり、全受信装置に配信コンテンツをばらつきなく同時に配信することが困難であった。

そこで、従来では、配信サーバに接続する多数の受信装置に対し、データの受信時刻が同じ時刻となるように、配信サーバでＩＰコンテンツの配信時刻を調整することにより、受信装置間のＩＰコンテンツの受信時刻のばらつきを軽減する手法が開示されている（例えば、非特許文献１参照）。

また、コンテンツ配信サーバから受信装置がＩＰコンテンツを受信するシステムにおいて、受信装置の設置場所や接続環境等を考慮することで、配信遅延が小さくなるよう配信ネットワークを構築する手法が開示されている（例えば、特許文献１参照）。

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

田中壮他、「クライアントのＲＴＴを考慮したプッシュ配信サーバにおける配信制御方式の検討」、２０１３年映像情報メディア学会年次大会１８−１２

ところで、上述したプッシュ型情報配信サービスでは、一定周期で繰り返しデータ配信するサービスが想定される。例えば上述した非特許文献１に示すような技術では、目標の配信時刻を設定し、各受信装置の配信時刻を遅延させることによってＩＰコンテンツの受信時刻のばらつきを軽減しているが、受信装置のＲＴＴが大きく、目標の配信時刻に配信時刻が収まらない場合や、配信周期毎に変動する配信所要時間の大きさによっては、配信時刻を遅延させたことによって、他の受信装置への配信が配信周期内に収まらない場合等から、配信できない受信装置が発生してしまうという問題があった。

また、特許文献１に示す手法は、コンテンツ配信サーバとその配信サーバに接続された受信装置における配信遅延差を考慮しておらず、接続している配信サーバが同じ受信装置にも関わらず、受信装置間で配信コンテンツ到達時間が異なるという問題があった。

１つの側面では、本発明は、配信サーバに接続された受信装置間の配信コンテンツの到達時間のばらつきを抑制させるためのコンテンツ配信サーバ、受信装置、及びコンテンツ配信プログラムを提供することを目的とする。

上記課題を解決するために、本発明は、以下の特徴を有する課題を解決するための手段を採用している。

一つの態様として、本発明は、通信ネットワークを介して接続された１又は複数の受信装置に対し、前記受信装置に表示させるコンテンツを配信するコンテンツ配信サーバにおいて、前記受信装置からの接続要求を受信し、前記受信装置それぞれとの間のセッションを確立するセッション制御手段と、前記セッション制御手段によりセッションを確立した受信装置に前記コンテンツを配信する前に、前記受信装置に対して遅延量確認要求を行い、前記遅延量確認要求に対する応答情報に基づいて前記受信装置の受信遅延量を計測する遅延量計測手段と、前記遅延量計測手段により得られた受信遅延量を用いて、所定の配信周期内で前記受信装置に対して前記コンテンツが配信されるように配信時刻を設定する配信時刻設定手段と、前記配信時刻設定手段により得られる配信時刻に基づき、前記受信装置に前記コンテンツを送信するコンテンツ送信手段とを有する。

また、一つの態様として、本発明は、上述したコンテンツ配信サーバと通信ネットワークを介して接続された受信装置において、第１情報を取得する第１情報取得手段と、前記第１情報を取得した伝送形態とは異なる伝送形態を介して前記コンテンツ配信サーバより配信された第２情報としての前記コンテンツを取得する第２情報取得手段と、前記第１情報と前記第２情報とを表示する表示手段とを有する。

また、一つの態様として、本発明は、コンピュータを、上述したコンテンツ配信サーバが有する各手段として機能させるためのコンテンツ配信プログラムである。

本発明によれば、コンテンツ配信サーバに接続された各受信装置に配信されるコンテンツの到達時間のばらつきを抑制させることができる。

コンテンツ配信システムの概略構成例を示す図である。 コンテンツ配信サーバの機能構成例を示す図である。 受信装置の機能構成例を示す図である。 コンテンツ配信処理の概要を説明するための図（その１）である。 コンテンツ配信処理の概要を説明するための図（その２）である。 更新されたコンテンツ配信例を示す図である。 本実施形態におけるデータ例を示す図である。 コンテンツ配信処理の第１実施例を示すフローチャートである。 コンテンツ配信処理の第２実施例を示すフローチャートである。

＜本実施形態について＞
本実施形態では、例えばコンテンツ配信サーバから複数の受信装置へコンテンツを配信する場合に、全受信装置における配信コンテンツ到達時間を一致させ、全受信装置へコンテンツを同期配信させる。例えば、コンテンツ配信サーバからコンテンツを受信装置にプッシュ配信する際に、それぞれの受信装置におけるＲＴＴをコンテンツ配信サーバへフィードバックし、各受信装置との受信遅延量をコンテンツ配信サーバ内で管理する。また、この受信遅延量に基づき、配信コンテンツの到達時間が最も遅い受信装置、例えばＲＴＴの最も大きい受信装置の配信コンテンツ到達時間又は任意の配信目標時刻を算出し、その到達時間に合わせて、その他の受信装置へのコンテンツ配信時に時間調整を行って配信する。

また、本実施形態は、目標の配信時刻よりも早い配信時刻となってしまう受信装置や配信時刻の調整によって配信周期に収まらない受信装置が存在する場合に、その時間分だけ、配信時刻を再調整し、全ての受信装置への配信を行う。これにより、各受信装置における配信コンテンツの到達時間のばらつきを抑制させ、より多くの各受信装置への同期したコンテンツのプッシュ配信が可能となる。以下に、コンテンツ配信サーバ、受信装置、及びコンテンツ配信プログラムを好適に実施した形態について、図面等を用いて詳細に説明する。

＜コンテンツ配信システムの概略構成例＞
図１は、コンテンツ配信システムの概略構成例を示す図である。図１に示すコンテンツ配信システム１０は、コンテンツ配信サーバ１１と、１又は複数の受信装置１２−１〜１２−ｎ（以下、必要に応じて「受信装置１２」を総称する）とを有している。コンテンツ配信サーバ１１と、受信装置１２とは、インターネットやＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）等に代表される通信ネットワーク１３によりデータの送受信が可能な状態で接続されている。

コンテンツ配信サーバ１１は、通信ネットワーク１３を介して各受信装置１２に同一のコンテンツを配信する。また、コンテンツ配信サーバ１１は、配信するコンテンツ（例えば、通信ネットワーク１３の一例であるＩＰ網を介して送信されるＩＰパケット）を時系列に多重化して送信する。

本実施形態におけるコンテンツ配信サーバ１１は、例えば汎用のサーバやＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）でもよい。また、コンテンツ配信サーバ１１は、１台に限定されるものではなく、複数台が異なる地点に設けられていてもよい。また、コンテンツ配信サーバ１１は、例えば１以上の情報処理装置を有するクラウドコンピューティングにより構成されたクラウドサーバであってもよい。

受信装置１２は、例えばコンテンツ配信サーバ１１から通信ネットワーク１３を介して受信したコンテンツ（配信情報）を、例えば通信ネットワーク１３とは異なる伝送形態（例えば、放送波）でリアルタイムに受信した放送番組等と共に画面表示する。受信装置１２は、例えばスポーツ中継番組において、放送波により画面上に表示されている野球選手やサッカー選手に対し、選手名や成績等の選手に関する情報（コンテンツ）を同期させて表示したり、番組と連動したクイズの質問や回答、情報番組において画面上に表示されている店舗や商品情報、ドラマの１シーンや登場人物が話す内容に応じた情報（字幕）等のコンテンツを放送波と同期して表示したり、株のトレード情報等を他の受信装置１２間で同期させて表示したりするが、これに限定されるものではない。

上述したような情報は、例えばテレビ放送番組の画面に、できる限りリンク（同期）して配信することが望ましく、例えばその画面が表示される前に、前もって関連する配信情報が表示されたり、すでにその配信情報に関する画面（シーン）が終了しているのに配信情報がそのまま残っていたりすると、視聴者にとっては、非常に違和感がある。

また、受信装置１２は、コンテンツを受信する通信位置（設置場所）がそれぞれ異なるため、コンテンツ配信サーバ１１と各受信装置１２との間の受信遅延量（例えば、往復遅延時間（ＲＴＴ）を１／２にした値）は、図１に示すように各受信装置１２のＲＴＴをＴ_１秒，Ｔ_２秒，…，Ｔ_Ｎ秒とすると、Ｔ_１／２秒，Ｔ_２／２秒，…，Ｔ_Ｎ／２秒のように、それぞれ異なるものとなる。したがって、コンテンツ配信サーバ１１から配信されたコンテンツの各受信装置１２への到達時刻は、各受信装置１２において、ばらつきが生じてしまう。そこで、本実施形態では、例えばテレビ放送番組の画面と同期して配信情報（ＩＰコンテンツ）が表示されるようにすると共に、各受信装置１２間においてもばらつきが生じないように制御を行う。

本実施形態における受信装置１２は、例えばＰＣ、ノート型ＰＣ、携帯電話、スマートフォン、タブレット端末、テレビ、ゲーム機器等であり、一例としては放送波を受信し表示させる機能と、通信ネットワーク１３に接続し情報の送受信を行う機能とを備える。

＜コンテンツ配信サーバ１１の機能構成例＞
次に、本実施形態におけるコンテンツ配信サーバ１１の機能構成例について図を用いて説明する。図２は、コンテンツ配信サーバの機能構成例を示す図である。図２の例において、コンテンツ配信サーバ１１は、制御手段２０と、通信手段３０と、記憶手段４０とを有する。制御手段２０は、セッション制御手段２１と、遅延量計測手段２２と、コンテンツ生成手段２３と、配信時刻設定手段２４と、コンテンツ送信手段２５とを有する。また、記憶手段４０は、セッション管理情報４１と、配信時刻情報４２とを有する。

セッション制御手段２１は、受信装置１２からの接続要求や切断要求に応じて、コンテンツ配信サーバ１１と受信装置１２のセッション確立や切断を制御する。例えば、セッション制御手段２１は、セッション確立時には記憶手段４０のセッション管理情報４１に、セッション毎に付与するセッションＩＤを記憶する。また、セッション制御手段２１は、セッション切断時に、セッション管理情報４１に記憶されている切断対象のセッションＩＤと、セッションＩＤに対応付けられている各種情報、配信時刻情報４２の当該レコード等を削除する。

遅延量計測手段２２は、受信装置１２の受信遅延量を計測し、計測結果をセッションＩＤに対応付けて記憶手段４０のセッション管理情報４１に記憶する。例えば、遅延量計測手段２２は、遅延量確認要求の一例として各受信装置１２からｐｉｎｇコマンドを実行し、その応答情報からＲＴＴを計測することで、受信遅延量を計測する。また、遅延量計測手段２２は、例えばコンテンツ配信サーバ１１と受信装置１２との間の送受信をＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）で行っている場合には、コンテンツ配信サーバ１１からの要求メッセージ（遅延量確認要求の一例）に対する受信装置１２からのＡＣＫメッセージ（応答情報）を受信し、要求メッセージを送信した時刻と、ＡＣＫメッセージを受信した時刻との差によって、ＲＴＴを取得して受信遅延量を計測してもよい。なお、各受信装置１２における受信遅延量は、往復時間を示すＲＴＴを１／２とすることで求めることができるが、これに限定されるものではなく、例えば上りと下りで通信速度が異なる場合には、その比率に基づいて値を調整してもよい。

また、遅延量計測手段２２は、例えば所定の配信周期でＩＰパケットを時分割送信する場合に、配信周期毎に受信遅延量を計測してもよく、また受信装置１２とセッションを確立した直後、ＩＰパケットを最初に送信するタイミング、所定時間間隔等の所定のタイミング等で受信遅延量を計測してもよい。また、遅延量計測手段２２は、過去数回の受信遅延量の統計から平均値を算出し、算出した平均値をセッション管理情報４１に記憶してもよい。平均値を使用することで、一時的な回線状態の不具合等による影響を軽減することができる。

コンテンツ生成手段２３は、受信装置１２に配信するコンテンツを生成し、生成したコンテンツをコンテンツ送信手段２５に出力する。なお、コンテンツとしては、例えば別の伝送形態で受信装置１２に送信される放送波に関連付けられた情報（例えば、番組関連情報、表示されている人物、お店、洋服等の情報等）であるが、これに限定されるものではない。

配信時刻設定手段２４は、所定の配信周期におけるセッションＩＤ毎の配信順序及び配信時刻を設定する。例えば、配信時刻設定手段２４は、記憶手段４０のセッション管理情報４１を参照し、セッション管理情報４１に含まれる受信遅延量に基づいて、各セッションＩＤ（各受信装置１２）に対する配信順序を設定する。配信順序は、例えば受信遅延量の大きい順（降順）に設定されるが、これに限定されるものではなく、例えば各受信装置１２の処理性能等を取得している場合には、その性能に応じて処理の遅い受信装置のＩＰパケットを早めに送信するように配信順序の調整を行ってもよい。

また、配信時刻設定手段２４は、設定した配信順序に基づき、任意の配信目標時刻の配信コンテンツ到達時間に合わせた配信時刻をセッションＩＤ毎に算出し、配信時刻情報４２に記憶させる。例えば、配信時刻設定手段２４は、受信遅延量が最も大きい受信装置１２にＩＰパケット（コンテンツ）を送信し、そのコンテンツが到達するまでの時間（目的の時刻に番組を出力するために受信装置１２に到達していなければならない時刻）を配信目標時刻とし、その時刻に合わせて他の受信装置１２にもＩＰパケットが到達するように配信時刻を設定する。また、配信時刻設定手段２４は、連続したコンテンツを途切れることなく、リアルタイムで各受信装置１２の画面に表示させるために必要な配信間隔を配信目標時刻として１配信周期内における配信時刻を設定してもよいが、設定手法は、これらに限定されるものではない。

本実施形態において、例えば配信するコンテンツが、外部（例えば、放送局）から放送波等により受信装置１２に提供される番組に関連付けられている場合には、その番組の放送時刻のタイミングに合わせて（同期して）コンテンツが表示できるように、配信時刻が設定される。

なお、配信時刻設定手段２４は、配信時刻が配信周期からはみ出してしまうセッションＩＤ（受信装置１２）が存在する場合に、配信時刻の再調整を行い、再調整した結果に基づいて全セッションＩＤに対し、ＩＰパケットが配信周期内に配信されるように配信時刻を更新する。更新した配信時刻は、配信時刻情報４２に記憶される。具体的な更新例については後述する。

コンテンツ送信手段２５は、セッション管理情報４１からセッションが確立されている受信装置１２を取得し、取得した各受信装置１２（セッションＩＤ）に対し、配信時刻設定手段２４に算出され、配信時刻情報４２に記憶された配信時刻に基づいて、コンテンツ生成手段２３で生成されたコンテンツのＩＰパケットを通信手段３０から送信する。なお、コンテンツ送信手段２５は、コンテンツ配信サーバ１１から切り離し、外部からＩＰコンテンツデータを入力するような構成としてもよい。

通信手段３０は、受信装置１２等とデータの送受信等を行う通信インターフェースである。例えば、通信手段３０は、受信装置１２に対する所定のアドレス情報やセッションＩＤ等に基づいて、受信装置１２から接続要求やコンテンツの配信要求を受信したり、受信装置１２のＲＴＴを計測したり、コンテンツ生成手段２３で生成されたコンテンツ等を送信する。

記憶手段４０は、上述したセッション管理情報４１と配信時刻情報４２とを格納する。なお、記憶手段４０が記憶する情報は、これに限定されるものではなく、例えば、コンテンツの内容、コンテンツ配信結果（ログ情報）やエラー情報、受信装置１２の識別情報や配信アドレス等、各種設定情報等を記憶していてもよい。

＜受信装置１２の機能構成例＞
次に、本実施形態における受信装置１２の機能構成例について図を用いて説明する。図３は、受信装置の機能構成例を示す図である。図３に示す受信装置１２は、制御手段５０と、通信手段６０とを有する。制御手段５０は、セッション制御手段５１と、番組取得手段５２と、コンテンツ取得手段５３と、表示手段５４とを有する。

セッション制御手段５１は、コンテンツ配信サーバ１１にセッション要求を行い、セッションを確立する。また、セッション制御手段５１は、コンテンツ配信サーバ１１からのｐｉｎｇコマンドの実行に応じて応答したり、コンテンツ配信サーバ１１からの要求メッセージに対してＡＣＫメッセージを返信する。また、セッション制御手段５１は、ユーザからの指示等により確立したセッションの切断等を制御する。

番組取得手段５２は、表示手段５４に表示する第１情報の一例として放送波により番組等を取得する第１情報取得手段である。なお、放送波は、提供側（例えば、放送局等）からプッシュ配信されてもよく、番組取得手段５２から提供側に要求することで受信してもよい。

番組の一例としては、例えばスポーツやニュース、バラエティ、ドラマ等があるが、これに限定されるものではない。上述したような番組の放送波は、例えば放送局等にある他の装置から配信されてもよく、コンテンツ配信サーバ１１より配信されてもよい。

コンテンツ取得手段５３は、表示手段５４に表示する第２情報の一例として、第１情報を取得した伝送形態とは異なる伝送形態（例えば、通信ネットワーク１３）を介してコンテンツ配信サーバ１１より配信された放送波の番組に対応付けられたコンテンツを取得する第２情報取得手段である。なお、コンテンツは、提供側（例えば、コンテンツ配信サーバ１１等）からプッシュ配信されてもよく、番組取得手段５２から提供側に要求することで受信してもよい。

コンテンツの一例としては、上述した番組に関連する各種情報（番組内容、表示されている人物やお店、洋服等の情報）であるが、これに限定されるものではない。

表示手段５４は、番組取得手段５２により取得した番組及びコンテンツ取得手段５３により取得したコンテンツを表示する。表示手段５４は、例えばディスプレイやモニタ、タッチパネル等であるが、これに限定されるものではない。

通信手段６０は、コンテンツ配信サーバ１１等とデータの送受信等を行う通信インターフェースである。例えば、通信手段６０は、コンテンツ配信サーバ１１にセッション確立要求や切断要求をしたり、放送波を受信したり、コンテンツを受信したりすることができる。

本実施形態では、表示される番組とコンテンツとが同期して表示することが可能なタイミングで配信され、同一のコンテンツ配信サーバ１１に接続された各受信装置１２間においても同期して配信されるため、受信装置１２側で特別な調整処理を行うことなく、番組及びコンテンツを同期させた視聴が可能となる。

本実施形態により、コンテンツ配信サーバ１１に接続された受信装置１２間の配信コンテンツの到達時間のばらつきを抑制させ、配信できない受信装置１２を発生させないプッシュ配信を可能にする。

＜コンテンツ配信処理の概要例＞
次に、本実施形態におけるコンテンツ配信処理の概要例について図を用いて説明する。図４、図５は、コンテンツ配信処理の概要を説明するための図（その１，その２）である。図４、図５は、従来手法（例えば、非特許文献１に示すような手法）において配信できない２つの例（例１，例２）と、それに対する本実施形態における配信例を示している。

また、図４、図５に示す丸印（○）は、各受信装置１２の識別情報（番号）に対応する１配信データ（１ＩＰパケット）を表し、その大きさ（直径）は、コンテンツ配信サーバ１１が各受信装置１２に対してＩＰパケットを出す所要時間を示している。また、配信順序において、図４、図５の例において、同一配信周期における各受信装置１２における同一ＩＰパケットの配信時間差（空き間隔）を、それぞれｄ_１、ｄ_２・・・ｄ_ｎ＋１等で表している。

丸印（○）が接している部分は、空き間隔がないことを示しｄ＝０である。また、ｄ_１は、配信周期の開始時刻から、最初の受信装置１２（識別番号１）に配信を開始するまでの間隔（時間）であり、ｄ_ｎ＋１は、最後の受信装置１２（識別番号ｎ）に対する配信が終了してから、配信周期の終了時刻までの間隔（時間）である。

コンテンツは、例えば図４、図５に示すように、コンテンツ配信サーバ１１とセッションが確立されている１〜ｎ番目の受信装置１２に対し、所定の配信周期でコンテンツの配信データ（ＩＰパケット）を所定の配信順序で時分割配信している。この場合、各受信装置１２における受信遅延量を計測し、その計測結果に基づいて、各受信装置１２のデータ到着時間が目標時刻に合うように各ＩＰパケットの配信時刻が調整される。このとき、配信周期によっては、計測された受信遅延量により図４に示すように配信周期よりも早く出さなければならないＩＰパケットが存在する場合がある。この場合には、１配信周期で全てを配信することができない（配信できない例１）。具体的には、図４に示すように、ＩＰパケットを配信するタイミングが配信周期の開始時刻よりも前に時間ｓ_ｆだけはみ出してしまう。

また、配信周期によっては、計測された受信遅延量により図５に示すように配信周期に収まらずに後ろにずれるＩＰパケットが存在する場合があり、この場合には、１配信周期で全てを配信することができない（配信できない例２）。具体的には、図５に示すように、ＩＰパケットを配信するタイミングが配信周期の終了時刻よりも後に時間ｓ_ｂだけはみ出してしまう。

そこで、本実施形態では、例えば図４に示すように、全体的な配信タイミングをｓ_ｆだけ後ろにスライドさせることで、１配信周期で全てのＩＰパケットを配信可能とする。また、図５に示すように、全体的な配信タイミングにｓ_ｂだけ前にスライドさせることで、１配信周期で全てのＩＰパケットを配信可能とする。なお、上述したスライドにより、他のＩＰパケットがはみ出ることがないように、本実施形態では、配信時間差（空き間隔）ｄを利用して再調整を行う。

例えば、配信時刻設定手段２４は、上述した空き間隔の総和を（１）式により求め、その総和とｓ_ｆやｓ_ｂ等とを比較し、「ｄ_１＋ｄ_２＋・・・＋ｄ_ｎ＋１＞ｓ_ｆ」、「ｄ_１＋ｄ_２＋・・・＋ｄ_ｎ＋１＞ｓ_ｂ」等である場合に配信時刻を再調整し、配信時刻を設定する。そして、コンテンツ送信手段２５は、再調整により更新された配信時刻でＩＰパケットを配信することで、配信周期内で全ての受信装置１２への配信が可能となる。

なお、空き間隔の総和の計算において、配信周期からはみ出している部分（図４の例ではｄ_１，ｄ_２、図５の例では、ｄ_ｎ−１，ｄ_ｎ，ｄ_ｎ＋１）については、総和の計算に含めなくてもよい。つまり、一例としては、配信周期内における空き間隔の総和（配信周期内においてＩＰパケットを配信していない時間）を計算する。また、本実施形態においては、上述したｓ_ｆ及びｓ_ｂの両方を含む場合もある。

次に、配信時刻の再調整による更新例について説明する。なお、以下の説明では、任意の配信目標時刻をｔ_ｄｅｆ、１配信周期で配信する受信装置の配信順序を１〜ｎ（例えば、ＲＴＴ値に基づき降順に設定した順序）とし、それぞれの配信時刻をｔ_１〜ｔ_ｎ、各受信装置１２に対してＩＰパケットを出す所要時間をＬ、配信周期をｔ_ｃ、上述したｓ_ｆ及びｓ_ｂに該当する受信装置数をそれぞれｍ_ｆ、ｍ_ｂとする。また、ｓ_ｆ及びｓ_ｂに該当する受信装置に対するパケット配信時の空き間隔がない場合（ｄ＝０）、ｓ_ｆ、ｓ_ｂはそれぞれ「ｓ_ｆ＝ｍ_ｆ×Ｌ」、「ｓ_ｂ＝ｍ_ｂ×Ｌ」等で表される。

＜配信時刻の更新例１＞
更新例１では、全体的に配信時刻をスライドさせる。例えば、上述した（１）式と、ｓ_ｆ、ｓ_ｂとの関係が、「（１）式≧ｓ_ｆ＋ｓ_ｂ」の場合には、例えば以下に示す（２）式により、更新後のｔ'_ｎを算出する。

なお、上述した（２）式においてｓ_ｆ＞０の場合には、ｔ_１＝ｔ_ｄｅｆ、ｓ_ｂ＞０の場合には、ｔ_ｎ＝ｔ_ｃ−Ｌとする。つまり、「（１）式≧ｓ_ｆ＋ｓ_ｂ」の場合には、例えば以下に示す（３）式で得られる値だけｄ_ｎを小さくし、全体的に配信時刻を短縮させることとなる。

また、「（１）式＜ｓ_ｆ＋ｓ_ｂ」となる場合には、配信周期に全ての配信データを配信しきれない状態となる。そのため、上述の条件を満たす場合には、例えば配信周期に収まらない配信データの一部又は全部を破棄する。例えば、ｔ_１＝ｔ_ｄｅｆとし、その他の配信時刻は配信順序１番目から昇順にｔ_ｃに収まる配信データ分だけｔ_ｎ＝ｔ_ｎ−１＋Ｌで更新する。また、別の例としては、例えばｔ_ｎ＝ｔ_ｄｅｆ＋ｔ_ｃ−Ｌとし、その他の配信時刻は配信順序ｎ番目から降順にｔ_ｃに収まる配信データ分だけｔ_ｎ＝ｔ_ｎ−１＋Ｌに更新する。つまり、何れの場合にも配信周期に収まらない前方又は後方の配信データの一部又は全部を破棄する。

＜配信時刻の更新例２＞
次に、配信時刻の更新例２について説明する。更新例２では、部分的に配信時刻をスライドさせる。例えば「（１）式≧ｓ_ｆ」の場合には、「ｓ_ｆ≧ｄ_１＋ｄ_２＋・・・ｄ_ｆ」となるｆを算出し（そのときの時刻をｔ_ｆとする）、ｔ_１＝ｔ_ｄｅｆとし、ｔ_２〜ｔ_ｆの配信時刻をｔ_ｎ＝ｔ_ｎ−１＋Ｌで更新する。また、「（１）式≧ｓ_ｂ」の場合には、「ｓ_ｂ≧ｄ_ｎ＋ｄ_ｎ−１＋・・・ｄ_ｂ」となるｂを算出し（そのときの時刻をｔ_ｂとする）、ｔ_ｎ＝ｔ_ｄｅｆ＋ｔ_ｃ−Ｌとし、その時刻ｔ_ｂ〜ｔ_ｎ−１の配信時刻をｔ_ｎ＝ｔ_ｎ−１＋Ｌで更新する。

なお、「（１）式≧ｓ_ｆｂ」及び「（１）式≧ｓ_ｂ」の場合には、ｔ_１＝ｔ_ｄｅｆとし、ｔ_２〜ｔ_ｆに更新後、再度（１）式を求め、「（１）式≧ｓ_ｂ」の場合には、ｔ_ｎ＝ｔ_ｄｅｆ＋ｔ_ｃ−Ｌとし、「ｓ_ｂ≧ｄ_ｎ＋ｄ_ｎ−１＋・・・ｄ_ｂ」となるｂを算出し（そのときの時刻をｔ_ｂとする）、ｔ_ｂ〜ｔ_ｎ−１の配信時刻をｔ_ｎ＝ｔ_ｎ−１＋Ｌで更新する。

また、更新例２では、ｔ_ｂ〜ｔ_ｎ−１に更新後、ｔ_２〜ｔ_ｆの順で更新してもよい。また、「（１）式＜ｓ_ｆ＋ｓ_ｂ」となる場合には、配信周期に全ての配信データを配信しきれない状態となる。そのため、上述の条件を満たす場合には、配信周期に収まらない配信データの一部又は全部を破棄する。例えば、ｔ_１＝ｔ_ｄｅｆとし、その他の配信時刻は配信順序１番目から昇順にｔ_ｃに収まる配信データ分だけｔ_ｎ＝ｔ_ｎ−１＋Ｌに更新する。また、別の例としては、例えばｔ_ｎ＝ｔ_ｄｅｆ＋ｔ_ｃ−Ｌとし、その他の配信時刻は配信順序ｎ番目から降順にｔ_ｃに収まる配信データ分だけｔ_ｎ＝ｔ_ｎ−１＋Ｌに更新する。つまり、何れの場合にも、配信周期に収まらない前方又は後方の配信データの一部又は全部を破棄する。

なお、上述した任意の配信目標時刻ｔ_ｄｅｆは、各ＩＰパケットが受信装置に到達されるべき時刻（例えば、番組が始まる時刻）であるため、厳密には、その時刻は配信周期毎に変化する。例えば、１周期目（１パケット目）に対する配信目標時刻がｔ_ｄｅｆであれば、２週期目（２パケット目）に対する配信目標時刻はｔ_ｄｅｆ＋ｔ_ｃである（ｔ_ｃは配信周期）。また、３周期目に対する配信目標時刻はｔ_ｄｅｆ＋ｔ_ｃ×２となり、それ以降も同様に変化する。したがって、本実施形態の説明で用いられる配信目標時刻ｔ_ｄｅｆは、上述したように配信周期の回数に対応して値が変化しているものとする。

図６は、更新されたコンテンツ配信例を示す図である。まず、従来の配信例では、コンテンツ配信サーバ１１において予め設定された時分割で各受信装置１２に対応する複数のパケットを配信するため、図６（Ａ）に示すように配信周期の前後で配信できないデータが発生してしまうことがあった（周期前は、受信装置１、２に対する配信データ、周期後は受信装置ｎ−１、ｎに対する配信データ）。そこで、上述した各更新例１，２により配信時刻を調整する制御機能を設ける。

上述した更新例１では、図６（Ｂ）に示すように、全ての受信装置１２（１〜ｎ）に対する配信データの配信時刻を調整する。これにより、個々の配信データ（ＩＰパケット）は若干ずれるが、その大きさは微小であるため、違和感なく端末間で同期させることができる。

また、上述した更新例２では、図６（Ｃ）に示すように一部分の配信データの配信時刻を調整する。図６（Ｃ）の例では、受信装置１，２，ｎ−１，ｎに対する配信時刻を調整する。これにより、配信時刻を調整しなくて済む配信データは調整する必要がないため再調整処理時間を短縮でき、更に配信周期の開始と終了に近い受信装置以外は、適切に同期を取ることができる。

＜データ例＞
ここで、本実施形態におけるデータ例（例えば、セッション管理情報、配信時刻情報）について図を用いて説明する。図７は、本実施形態におけるデータ例を示す図である。図７（Ａ）は、セッション管理情報４１の一例を示している。図７（Ｂ）〜（Ｄ）は、配信時刻情報４２の一例を示しており、図７（Ｃ）、（Ｄ）は、上述した各更新例に基づいて、図７（Ｂ）に示す配信時間を再調整して更新したものである。

図７（Ａ）に示すセッション管理情報４１の項目としては、例えば「セッションＩＤ」、「セッション情報」、そのセッションに対応した「受信遅延量（ｍｓ）」等があるが、これに限定されるものではない。

セッションＩＤは、アクセス中の受信装置１２を識別するための情報である。セッション情報は、セッションＩＤが付与された受信装置の行動や操作内容、アクセス条件の管理（セッション管理）の情報である。受信遅延量は、遅延量計測手段２２により計測される遅延量が格納される。

図７（Ｂ）〜（Ｄ）に示す配信時刻情報４２の項目としては、例えば「配信順序」、「セッションＩＤ」、「セッション情報」、「配信時刻」等があるが、これに限定されるものではない。セッションＩＤ、セッション情報は、セッション管理情報４１に記憶されている情報が記憶される。配信順序は、セッション管理情報４１に基づいて設定されるコンテンツの配信順序であり、例えば受信遅延量の大きい順に設定されるが、これに限定されるものではない。また、配信時刻は、配信周期の開始時刻を０．０ｍｓとしたときの配信時刻である。

以下に、図７のデータ例を用いて上述した更新例１，２の具体例を説明する。なお、図７（Ｂ）〜（Ｄ）では、一例として、コンテンツ配信サーバ１１が各受信装置１２に対してＩＰパケットを出す所要時間Ｌ＝１ｍｓ、配信周期ｔ_ｃ＝３３ｍｓとする。また、一例として、配信周期内における空き間隔の総和（（１）式に相当）＝２０ｍｓとし、ｓ_ｆ＋ｓ_ｂ＝２ｍｓとする。

また、配信順序は、上述したセッション管理情報４１の受信遅延量に基づいて、「ＩＤ５」→「ＩＤ２」→「ＩＤ３」→「ＩＤ１」→「ＩＤ４」→「ＩＤ０」の順にＩＰパケットを配信するものとする。

図７（Ｂ）は、従来手法による配信時刻の設定例を示しており、参考までに、各受信装置１２に対するＩＰパケットの送信間隔（空き間隔ｄ（ｍｓ））も示している。まず、図７（Ａ）より、各セッションに対する理想的な配信時刻を算出する。具体的には、例えば配信目標時刻ｔ_ｄｅｆ＝５０ｍｓに対して、それぞれのセッションにおける受信遅延量の差分を算出すればよい。そのため、例えばセッション０は、ｔ_０＝ｔ_ｄｅｆ−６＝４４ｍｓとなる。その他のセッションについても、同様に配信時刻を求めることができる。

ここで、配信周期の開始時刻（例えば、９時００分００秒）に対する配信目標時刻ｔ_ｄｅｆ＝５０ｍｓ後だとすると、図７（Ａ）の受信遅延量により、セッションＩＤ５は上述したｓ_ｆ対象となり配信周期内で配信することができない（図７（Ｂ））。また、配信周期ｔ_ｃ＝３３ｍｓであるため、図７（Ａ）の受信遅延量により、セッションＩＤ０は、上述したｓ_ｂ対象となり配信周期内で配信することができない（図７（Ｂ））。その結果、配信は、セッションＩＤ１〜４のみ配信が可能となる。セッションＩＤ１〜４を降順にすると、セッションＩＤ２、ＩＤ３、ＩＤ１、ＩＤ４の順となる。配信順序が１番目のセッションＩＤ２は、受信遅延量が４８．０ｍｓであるため、空き間隔ｄ_１はｔ_ｄｅｆ−４８．０ｍｓ＝２ｍｓと求めることができる。

次に、配信順序２番目のセッションＩＤ３は、受信遅延量が４４．０ｍｓであり、セッションＩＤ２の配信終了時刻がｔ_１＋Ｌ＝３ｍｓとなるため、空き間隔ｄ_２はｔ_２−３ｍｓ＝３ｍｓと求めることができる。その他のｄについても同様に求めることができる。

図７（Ｃ）の例は、上述した更新例１により更新された配信時刻情報４２を示している。図７（Ｂ）の例では、セッションＩＤ５、セッションＩＤ０が配信できなくなってしまうため、ｓ_ｆに該当する受信装置数ｍ_ｆ＝１、ｓ_ｂに該当する受信装置数ｍ_ｂ＝１となり、ｓ_ｆ＋ｓ_ｂ＝２ｍｓとなる。

そこで、更新例１では、上述した（２）式を適用してセッションＩＤ０〜ＩＤ５の全ての配信時刻の再調整を行い、図７（Ｃ）に示す配信時刻に更新される。これにより、配信周期内で、全ての受信装置１２にＩＰパケットの配信が可能となる。

図７（Ｄ）の例は、上述した更新例２により更新された配信時刻情報４２を示している。上述したように、図７（Ｂ）の例では、セッションＩＤ５、セッションＩＤ０が配信不可となっているため、ｍ_ｆ＝１、ｍ_ｂ＝１となり、ｓ_ｆ＋ｓ_ｂ＝２ｍｓとなる。

そこで、上述した更新例２を適用してセッションＩＤ５、セッションＩＤ０のみの配信時刻の再調整を行い、図７（Ｄ）に示す配信時刻に更新される。これにより、配信周期内で、全ての受信装置１２にＩＰパケットの配信が可能となる。なお、上述した更新例１及び更新例２のどちらを用いるかについては、例えば予めユーザが設定してもよく、配信されるコンテンツの内容、受信装置１２間における優先度に応じて設定してもよい。

＜実行プログラム＞
ここで、上述したコンテンツ配信サーバ１１及び受信装置１２は、例えばＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）等の揮発性の記憶装置、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）等の不揮発性の記憶装置、マウスやキーボード、ポインティングデバイス等の入力装置、画像やデータ等を表示する表示装置、並びに外部と通信するためのインターフェース装置を備えたコンピュータによって構成することができる。

したがって、コンテンツ配信サーバ１１及び受信装置１２が有する上述した各機能は、これらの機能を記述したプログラムをＣＰＵに実行させることによりそれぞれ実現可能となる。また、これらのプログラムは、磁気ディスク（フロッピー（登録商標）ディスク、ハードディスク等）、光ディスク（ＣＤ−ＲＯＭ、ＤＶＤ等）、半導体メモリ等の記録媒体に格納して頒布することもできる。

つまり、上述した各構成における処理をコンピュータに実行させるための実行プログラム（コンテンツ配信プログラム）を生成し、例えば汎用のＰＣやサーバ等にそのプログラムをインストールすることにより、コンテンツ配信処理を実現することができる。

＜コンテンツ配信処理（第１実施例：更新例１）＞
図８は、コンテンツ配信処理の第１実施例を示すフローチャートである。第１実施例では、上述した更新例１に対応する処理を示している。図８の例において、コンテンツ配信サーバ１１は、１又は複数の受信装置１２からの接続要求を受信し（Ｓ０１）、受信装置１２とセッションを確立する（Ｓ０２）。

次に、コンテンツ配信サーバ１１は、確立したセッション毎にセッションＩＤを付与し、記憶手段４０のセッション管理情報に記憶する（Ｓ０３）。次に、コンテンツ配信サーバ１１は、受信装置１２へ遅延量確認要求を送信し（Ｓ０４）、その受信結果からＲＴＴを計測し、計測結果から受信装置１２との受信遅延量を取得して、セッション管理情報４１に記憶する（Ｓ０５）。

次に、コンテンツ配信サーバ１１は、セッション管理情報４１を参照し、受信遅延量に基づく配信順序と、配信順序に基づく配信時刻とを算出し、配信時刻情報４２に記憶する（Ｓ０６）。ここで、コンテンツ配信サーバ１１は、配信周期の開始時刻よりも前にはみ出した時間ｓ_ｆと、配信周期の終了時刻よりも後にはみ出した時間ｓ_ｂとの関係から、「ｓ_ｆ＋ｓ_ｂ＞０」となるか否かを判断し（Ｓ０７）、「ｓ_ｆ＋ｓ_ｂ＞０」となる場合（Ｓ０７において、ＹＥＳ）、上述した（１）式に示すような配信周期内における空き間隔の総和（ここでは「Σｄ」と表記する）との関係から、「Σｄ≧ｓ_ｆ＋ｓ_ｂ」の条件を満たすか否かを判断する（Ｓ０８）。

コンテンツ配信サーバ１１は、「Σｄ≧ｓ_ｆ＋ｓ_ｂ」の条件を満たさない場合（Ｓ０８において、ＮＯ）、配信時刻情報４２のｔ_ｎを、最初に配信する時刻ｔ_１＝ｔ_ｄｅｆとし、その他の配信時刻は配信順序１番目から昇順にｔ_ｃに収まる配信データ分だけｔ_ｎ＝ｔ_ｎ−１＋Ｌに更新する。または、ｔ_ｎ＝ｔ_ｄｅｆ＋ｔ_ｃ−Ｌとし、その他の配信時刻は配信順序ｎ番目から降順にｔ_ｃに収まる配信データ分だけｔ_ｎ＝ｔ_ｎ−１＋Ｌに更新する（Ｓ０９）。Ｓ０９の処理では、配信周期に収まらない前方又は後方の配信データに対して収まる配信データ分だけ更新が行われる。なお、上述した「ｔ_１＝ｔ_ｄｅｆ」とは、ｔ_１がｔ_ｄｅｆに基づいて設定されることを意味する。したがって、例えば、図７（Ｃ）等に示すように、最初のセッションＩＤに対応する受信装置１２の配信時刻ｔ_１は、配信開始時刻を基準にｔ_ｄｅｆに基づいて設定される。

また、コンテンツ配信サーバ１１は、「Σｄ≧ｓ_ｆ＋ｓ_ｂ」の条件を満たす場合（Ｓ０８において、ＹＥＳ）、「ｓ_ｆ＞０」の条件を満たすか否かを判断する（Ｓ１０）。コンテンツ配信サーバ１１は、「ｓ_ｆ＞０」の条件を満たす場合（Ｓ１０において、ＹＥＳ）、最初に配信する時刻ｔ_１をｔ_１＝ｔ_ｄｅｆとし（Ｓ１１）、その他の受信装置１２に対する配信時刻ｔ_ｎを上述した（２）式を用いて更新する（Ｓ１２）。また、コンテンツ配信サーバ１１は、「ｓ_ｆ＞０」の条件を満たさない場合（Ｓ１０において、ＮＯ）、全てｔ_ｎ＝ｔ_ｄｅｆ＋ｔ_ｃ−Ｌに更新する（Ｓ１３）。

コンテンツ配信サーバ１１は、Ｓ０７の処理において、「ｓ_ｆ＋ｓ_ｂ＞０」の条件を満たさない場合（Ｓ０７において、ＮＯ）、Ｓ０９、Ｓ１２、又はＳ１３の処理後、配信時刻情報４２を参照し、設定された配信順序及び配信時刻でコンテンツ（その配信周期に対応するＩＰパケット）を配信する（Ｓ１４）。

次に、コンテンツ配信サーバ１１は、配信を終了するか否かを判断し（Ｓ１５）、配信を終了しない場合（Ｓ１５において、ＮＯ）、Ｓ０４の処理に戻る。なお、Ｓ０４の処理は、接続開始直後は必ず実施し、その後のループ処理では必ずしも毎回行わなくてもよく、例えば任意のタイミングで実施したり、定期的に実施してもよい。

また、コンテンツ配信サーバ１１は、配信を終了する場合（Ｓ１５において、ＹＥＳ）、例えば受信装置１２からの切断要求を受信して配信を終了する（Ｓ１６）。また、コンテンツ配信サーバ１１は、切断要求を受信したセッションのセッション管理情報４１及び配信時刻情報４２の当該レコードを削除し（Ｓ１７）、処理を終了する。

なお、上述したＳ１５〜Ｓ１７の処理においては、例えば、複数の受信装置１２でセッションが確立している状態で、そのうちの１つの受信装置１２からの切断要求があった場合、全ての受信装置１２に対する配信が終了していないため、Ｓ０４の処理に戻るが、その場合に、Ｓ１７の処理に示すように、切断要求を受信したセッションのセッション管理情報４１及び配信時刻情報４２における当該レコードは削除される。

＜コンテンツ配信処理（第２実施例：更新例２）＞
図９は、コンテンツ配信処理の第２実施例を示すフローチャートである。第２実施例では、上述した更新例２に対応する処理を示している。図９の例において、コンテンツ配信サーバ１１は、１又は複数の受信装置１２からの接続要求を受信し（Ｓ２１）、受信装置１２とセッションを確立する（Ｓ２２）。次に、コンテンツ配信サーバ１１は、確立したセッション毎にセッションＩＤを付与し、記憶手段４０のセッション管理情報４１に記憶する（Ｓ２３）。

次に、コンテンツ配信サーバ１１は、受信装置１２へ遅延量確認要求を送信し（Ｓ２４）、その受信結果からＲＴＴを計測し、計測結果から受信装置１２との受信遅延量を取得して、セッション管理情報４１に記憶する（Ｓ２５）。

次に、コンテンツ配信サーバ１１は、セッション管理情報４１を参照し、受信遅延量に基づく配信順序と、配信順序に基づく配信時刻とを算出して配信時刻情報４２に記憶する（Ｓ２６）。ここで、コンテンツ配信サーバ１１は、「ｓ_ｆ＞０」の条件を満たすか否かを判断し（Ｓ２７）、「ｓ_ｆ＞０」の条件を満たす場合（Ｓ２７において、ＹＥＳ）、次に上述した（１）式に示すような配信周期内における空き間隔の総和（ここでは「Σｄ」と表記する）との関係から、「Σｄ≧ｓ_ｆ」の条件を満たすか否かを判断する（Ｓ２８）。

コンテンツ配信サーバ１１は、「Σｄ≧ｓ_ｆ」の条件を満たさない場合（Ｓ２８において、ＮＯ）、配信時刻情報４２のｔ_ｎを、最初に配信する時刻ｔ_１＝ｔ_ｄｅｆとし、その他の配信時刻は配信順序１番目から昇順にｔ_ｃに収まる配信データ分だけｔ_ｎ＝ｔ_ｎ−１＋Ｌに更新する（Ｓ２９）。つまり、配信しきれない後ろのパケットは切り捨てることになる。また、コンテンツ配信サーバ１１は、「Σｄ≧ｓ_ｆ」の条件を満たす場合（Ｓ２８において、ＹＥＳ）、配信時刻情報４２のｔ_ｎを、ｔ_１＝ｔ_ｄｅｆとし、ｔ_２〜ｔ_ｆをｔ_ｎ＝ｔ_ｎ−１＋Ｌで更新する（Ｓ３０）。

ここで、Ｓ２７の処理において、「ｓ_ｆ＞０」の条件を満たさない場合（Ｓ２７において、ＮＯ）、Ｓ２９又はＳ３０の処理後、コンテンツ配信サーバ１１は、「ｓ_ｂ＞０」の条件を満たすか否かを判断する（Ｓ３１）。「ｓ_ｂ＞０」の条件を満たす場合（Ｓ３１において、ＹＥＳ）、次に「Σｄ≧ｓ_ｂ」の条件を満たすか否かを判断する（Ｓ３２）。「Σｄ≧ｓ_ｂ」の条件を満たさない場合（Ｓ３２において、ＮＯ）、配信時刻情報４２のｔ_ｎを、最後に配信する時刻ｔ_ｎ＝ｔ_ｄｅｆ＋ｔ_ｃ−Ｌとし、その他の配信時刻は配信順序ｎ番目から降順にｔ_ｃに収まる配信データ分だけｔ_ｎ＝ｔ_ｎ−１＋Ｌに更新する（Ｓ３３）。つまり、配信しきれない前のパケットは切り捨てることになる。また、コンテンツ配信サーバ１１は、「Σｄ≧ｓ_ｂ」の条件を満たす場合（Ｓ３２において、ＹＥＳ）、配信時刻情報４２のｔ_ｂ〜ｔ_ｎ−１をｔ_ｎ＝ｔ_ｎ−１＋Ｌで更新する（Ｓ３４）。

次に、コンテンツ配信サーバ１１は、配信時刻情報４２を参照し、設定された配信順序及び配信時刻でコンテンツ（その配信周期に対応するＩＰパケット）を配信する（Ｓ３５）。

次に、コンテンツ配信サーバ１１は、配信を終了するか否かを判断し（Ｓ３６）、配信を終了しない場合（Ｓ３６において、ＮＯ）、Ｓ２４の処理に戻る。なお、Ｓ２４の処理は、接続開始直後は必ず実施し、その後のループ処理では必ずしも毎回行わなくてもよく、例えば任意のタイミングで実施したり、定期的に実施してもよい。

また、コンテンツ配信サーバ１１は、配信を終了する場合（Ｓ３６において、ＹＥＳ）、例えば受信装置１２より切断要求を受信して配信を終了する（Ｓ３７）。また、コンテンツ配信サーバ１１は、切断要求を受信したセッションのセッション管理情報４１及び配信時刻情報４２の当該レコードを削除し（Ｓ３８）、処理を終了する。

上述したように本実施形態によれば、コンテンツ配信サーバ１１に接続された各受信装置１２に配信されるコンテンツの到達時間のばらつきを抑制させることができる。また、配信できない受信装置１２を発生させないプッシュ配信を可能とする。

以上、本発明の好ましい実施形態について詳述したが、本発明は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形、変更が可能である。

１０ コンテンツ配信システム
１１ コンテンツ配信サーバ
１２ 受信装置
１３ 通信ネットワーク
２０，５０ 制御手段
２１，５１ セッション制御手段
２２ 遅延量計測手段
２３ コンテンツ生成手段
２４ 配信時刻設定手段
２５ コンテンツ送信手段
３０，６０ 通信手段
４０ 記憶手段
４１ セッション管理情報
４２ 配信時刻情報
５２ 番組取得手段（第１情報取得手段）
５３ コンテンツ取得手段（第２情報取得手段）
５４ 表示手段

Claims (6)

1. 通信ネットワークを介して接続された１又は複数の受信装置に対し、前記受信装置に表示させるコンテンツを配信するコンテンツ配信サーバにおいて、
   前記受信装置からの接続要求を受信し、前記受信装置それぞれとの間のセッションを確立するセッション制御手段と、
   前記セッション制御手段によりセッションを確立した受信装置に前記コンテンツを配信する前に、前記受信装置に対して遅延量確認要求を行い、前記遅延量確認要求に対する応答情報に基づいて前記受信装置の受信遅延量を計測する遅延量計測手段と、
   前記遅延量計測手段により得られた受信遅延量を用いて、所定の配信周期内で前記受信装置に対して前記コンテンツが配信されるように配信時刻を設定する配信時刻設定手段と、
   前記配信時刻設定手段により得られる配信時刻に基づき、前記受信装置に前記コンテンツを送信するコンテンツ送信手段とを有することを特徴とするコンテンツ配信サーバ。
2. 前記配信時刻設定手段は、
   前記受信遅延量を用いて得られた前記受信装置の配信時刻が、前記所定の配信周期の開始時刻よりも前、又は、前記所定の配信周期の終了時刻よりも後の場合に、配信する全ての受信装置の配信時刻を更新することを特徴とする請求項１に記載のコンテンツ配信サーバ。
3. 前記配信時刻設定手段は、
   前記受信遅延量を用いて得られた前記受信装置の配信時刻が、前記所定の配信周期の開始時刻よりも前、又は、前記所定の配信周期の終了時刻よりも後の場合に、前記開始時刻よりも前、又は、前記終了時刻よりも後の配信時刻となる受信装置に対する配信時刻のみを更新することを特徴とする請求項１に記載のコンテンツ配信サーバ。
4. 前記配信時刻設定手段は、
   前記受信遅延量が最も大きい受信装置に前記コンテンツが到達する時間に合わせて他の受信装置にも前記コンテンツが到達するように配信時刻を設定することを特徴とする請求項１乃至３の何れか１項に記載のコンテンツ配信サーバ。
5. 請求項１乃至４の何れか１項に記載のコンテンツ配信サーバと通信ネットワークを介して接続された受信装置において、
   第１情報を取得する第１情報取得手段と、
   前記第１情報を取得した伝送形態とは異なる伝送形態を介して前記コンテンツ配信サーバより配信された第２情報としての前記コンテンツを取得する第２情報取得手段と、
   前記第１情報と前記第２情報とを表示する表示手段とを有することを特徴とする受信装置。
6. コンピュータを、請求項１乃至４の何れか１項に記載のコンテンツ配信サーバが有する各手段として機能させるためのコンテンツ配信プログラム。

Images