JP2008311947A - コンテンツ配信システム、コンテンツサーバ、端末、コンテンツ配信方法、プログラムおよび記録媒体 - Google Patents

Abstract

【課題】コンテンツの配信において、ユニキャスト型とマルチキャスト型とを組み合わせてコンテンツを取得する場合、サーバの配信負荷を低減し且つ端末の受信時間を短くすることが出来ない。
【解決手段】コンテンツを保持するコンテンツサーバにより、コンテンツを分割してユニキャスト型配信で端末に配信している際、そのコンテンツの配信希望端末の数が多くなり、マルチキャスト型配信が開始される場合、コンテンツをユニキャストで配信する際の順番と、コンテンツをマルチキャストで配信する際の順番とを逆として配信するコンテンツ配信方法。
【選択図】 図１２

Description

本発明は、インターネットなどで、映像や音声などのコンテンツを配信するコンテンツ配信システムなどに関する。

インターネットを用いた映像コンテンツの配信が近時行われている。そのコンテンツの受信形式としては、コンテンツの受信と同時にユーザに視聴をさせるストリーミング型の受信形式と、いったん端末にコンテンツを保管し、その後ユーザに視聴をさせるダウンロード型の受信形式とがある。

また、コンテンツの配信手法としては、各端末が独立してコンテンツをサーバに要求し、サーバがそれぞれの端末に別々にコンテンツを配信するユニキャスト型の配信形式と、サーバがコンテンツをマルチキャストパケットを用いて配信し、各端末が配信されたコンテンツを取得するマルチキャスト型の配信形式がある。

ユニキャスト型の配信形式では、複数の端末が同一コンテンツをサーバに要求した場合、サーバの負荷および通信路の必要容量が増加するという課題がある。

またマルチキャスト型の配信形式では、すべての端末が同時に受信を行うため、処理速度が遅い端末に配信速度を合わせる必要があるため、高速処理が可能な端末にとっては、ユニキャスト形式に比してダウンロードにかかる時間が増加するという課題がある。

そこで、配信する端末の数が少ないときには、各端末が同一コンテンツをサーバに要求してもそれ程サーバや通信路への負荷が大きくならないので、ユニキャスト型の配信を行い、端末の数が多くなったときには、サーバや通信路への負荷が大きくなりすぎないようにするため、マルチキャスト型の配信に切り替える方法が開示されている（特許文献１参照）。

また、時間差の少ない複数のユニキャスト型の配信が生じた場合は、それら端末グループについて、マルチキャスト型の配信に変換する方法が開示されている（特許文献２参照）。
特開２０００−１８１８３６ 特開２００４−０８０５６６

しかしながら、特許文献１の方法では、途中でマルチキャスト型に切り替えた場合、端末が、コンテンツをユニキャスト型で既に一部配信を受けていたにもかかわらず、あらためてすべてのコンテンツをマルチキャスト型で受信し直しているので、それだけ余分な時間が必要となり、例えば端末側でその間、他のコンテンツをダウンロードするなど他の作業をすることができない課題がある。

また、特許文献２の方法では、時間差の少ない端末グループでしかマルチキャスト型に切りかえできないため、すべての端末がマルチキャスト型に切換えられとしても、時間差を持った複数のマルチキャスト型の配信を行わなければならないという課題がある。

本発明は、このような従来のコンテンツ配信システムを考慮し、サーバの配信負荷が少なく、端末の受信時間が短いコンテンツ配信システムなどを提供することを目的とする。

第１の本発明は、コンテンツを保持し、複数のブロックに分割して配信するコンテンツサーバと、前記コンテンツサーバからネットワークを介して前記コンテンツを取得する複数の端末とを備えたコンテンツ配信システムにおいて、
前記端末は、前記コンテンツサーバがユニキャスト型でコンテンツを配信している時はユニキャスト型で配信を受け、マルチキャスト型でコンテンツを配信している時は、マルチキャスト型で配信を受け、
前記コンテンツサーバは、少なくとも一つの端末に関して、一つの前記コンテンツを分割配信中に配信の型が変わる場合、ユニキャスト型で配信する場合の順番と、前記マルチキャスト型で配信する場合の順番が互いに逆になるように配信する、コンテンツ配信システムである。

第２の本発明は、前記コンテンツサーバは、コンテンツ毎に単位時間当たりの要求端末数を計測し、予め決められた一定数を超えた場合、その一定数を超えたコンテンツについてマルチキャスト型の配信を開始する、第１の本発明のコンテンツ配信システムである。

第３の本発明は、前記コンテンツサーバは、前記端末からユニキャスト型でコンテンツを要求されたとき、前記コンテンツの配信に加えて前記コンテンツがマルチキャスト型で配信されているかの別も応答する、第１の本発明のコンテンツ配信システムである。

第４の本発明は、前記コンテンツサーバは、前記コンテンツがマルチキャスト型配信されていることを応答するために、マルチキャストＩＰアドレスを前記端末へ知らせる、第３の本発明のコンテンツ配信システムである。

第５の本発明は、前記端末は、前記ユニキャスト型でコンテンツ配信を要求したとき、前記コンテンツサーバから前記コンテンツがマルチキャスト配信されているとの応答があった場合、ユニキャスト型でのコンテンツ取得を中止し、マルチキャスト型での配信を受ける、第３の本発明のコンテンツ配信システムである。

第６の本発明は、コンテンツを保持し、複数のブロックに分割して、ネットワークを介して複数の端末に配信するコンテンツサーバにおいて、
少なくとも一つの前記端末に関して、一つの前記コンテンツを分割配信中に配信の型が変わる場合、ユニキャスト型で配信する場合の順番と、前記マルチキャスト型で配信する場合の順番が互いに逆になるように配信する、コンテンツサーバである。

第７の本発明は、コンテンツを保持するコンテンツサーバから、前記コンテンツを複数のブロックに分割して、ネットワークを介して受信する端末において、
ユニキャスト型配信でコンテンツを受信している際に、そのコンテンツとは別にそのコンテンツがマルチキャスト型で配信されている旨知らされた場合、前記ユニキャスト型配信でのコンテンツ取得を中止し、マルチキャスト型での配信で、前記ユニキャスト型配信の順番とは逆順で前記コンテンツを受信する、端末である。

第８の本発明は、コンテンツを保持するコンテンツサーバにより、前記コンテンツを分割して複数の端末に配信するコンテンツ配信方法において、
前記所定のコンテンツの分割配信中に配信の型が変わる場合、前記コンテンツをユニキャストで配信する際の順番と、前記コンテンツを前記マルチキャストで配信する際の順番とを逆として配信する、コンテンツ配信方法である。

第９の本発明は、第１の本発明のコンテンツ配信システムの、前記コンテンツサーバがユニキャスト型でコンテンツを配信している時はユニキャスト型で配信を受け、マルチキャスト型でコンテンツを配信している時は、マルチキャスト型で配信を受ける前記端末、少なくとも一つの端末に関して、一つの前記コンテンツを分割配信中に配信の型が変わる場合、ユニキャスト型で配信する場合の順番と、前記マルチキャスト型で配信する場合の順番が互いに逆になるように配信する前記コンテンツサーバ、としてコンピュータを機能させるためのプログラムである。

第１０の本発明は、第９の本発明のプログラムを記録した記録媒体であって、コンピュータにより処理可能な記録媒体である。

本発明では、ユニキャスト型のコンテンツ配信をマルチキャスト型のコンテンツ配信に切り替える際、あるいは逆にマルチキャスト型のコンテンツ配信をユニキャスト型のコンテンツ配信に切り替える際、コンテンツの配信順番をそれまでの配信順番とは逆順で配信することにより、サーバの配信負荷を低減し、かつ端末の受信時間を短くすることが可能となる。

本発明により、サーバの配信負荷を低減し、端末の受信時間を短くすることが可能となる。

以下に、本発明の実施の形態について、図面を参照しながら説明する。

図１は本発明の実施の形態についての概要を示す図である。図１において、１はコンテンツサーバ、２はネットワーク、３は端末、４は映像表示装置である。端末３とコンテンツサーバ１はネットワーク２を介して接続されている。ネットワーク２はインターネット網でありＩＰパケットを伝送するネットワークである。コンテンツ配信機器であるコンテンツサーバ１は、コンテンツを保持し、端末３からの要求にしたがってコンテンツをユニキャスト型で応答配信するほか、状況に応じてコンテンツをマルチキャスト型を用いて配信する。

端末３は、ユニキャスト通信を用いてコンテンツサーバ１にコンテンツを要求しコンテンツを取得するほか、マルチキャスト配信に参加してコンテンツサーバ１が配信するコンテンツを取得する。また、端末３は、取得したコンテンツを映像表示装置４に表示させる。

コンテンツサーバ１のブロック図を図２に示す。１０はコンテンツ記録部、１１はネットワークインタフェース、１２はユニキャスト応答部、１３はマルチキャスト配信部、１４は計測部である。ネットワークインタフェース１１はネットワーク２から到達可能なＩＰアドレスを持っており、ネットワーク２から当該ＩＰアドレス宛のＨＴＴＰ（Hyper Text Transfer Protocol）リクエストが到達した場合ユニキャスト応答部１２に中継し、またユニキャスト応答部１２が生成する応答配信をＨＴＴＰリクエストの送信元にネットワーク２に通じて返送する。

すなわち、ユニキャスト応答部１２は、ＨＴＴＰリクエストに応じてコンテンツ記録部１０から、指定されたコンテンツの指定された部分を読み出し、ＨＴＴＰレスポンスとして応答配信するようネットワークインタフェース１１に要求する。このとき、ユニキャスト応答部１２は、後述のようにマルチキャスト配信部１３が既に他の端末グループに対して当該コンテンツをマルチキャスト型配信している場合には、そのマルチキャストＩＰアドレスをＨＴＴＰレスポンスヘッダに含めて返信する。

さらに、ネットワークインタフェース１１は、マルチキャスト配信部１３からマルチキャスト配信の要求があった場合、マルチキャスト配信部１３から通知されるマルチキャストＩＰアドレスに対して、マルチキャスト配信部１３が配信するコンテンツを配信する。

また、ユニキャスト応答部１２は、当該コンテンツの単位時間当たりのユニークな接続数を計測部１４から取得する。ユニキャスト応答部１２は、マルチキャスト配信部１３がマルチキャスト配信していない場合で、単位時間当たりのユニークな接続数が一定数αより大きい場合には、当該コンテンツのマルチキャスト配信をマルチキャスト配信部１３に依頼する。逆に、マルチキャスト配信部１３がマルチキャスト配信している場合で、単位時間当たりのユニークな接続数が一定数βより小さい場合には、当該コンテンツのマルチキャスト配信の中止をマルチキャスト配信部１３に依頼する。

このことによって、接続数が多い場合はマルチキャスト配信を、少ない場合はユニキャスト通信を行うことで、通信路のリソースを有効につかうことができる。

マルチキャスト配信部１３は、ユニキャスト応答部１２からコンテンツのマルチキャスト配信の依頼があれば、当該コンテンツをコンテンツ記録部１０から逆順に取り出しマルチキャスト配信をネットワークインタフェース１１を通じて行う。そしてマルチキャスト配信の有無とマルチキャストＩＰアドレスを管理し、ユニキャスト応答部１２から問い合わせがあれば応答する。逆順とはコンテンツをブロックに分割し配信する際に、後ろのブロックから配信することをいう。各ブロックを配信する際のマルチキャストパケット内のデータ並びは正順である。

計測部１４は、コンテンツごとに単位時間当たりのユニークな接続数を計測する。

図３は、端末３のブロック図である。２０はネットワークインタフェース、２１はユニキャスト要求部、２２はマルチキャスト受信部、２３は再生部、２４は記録部である。

再生部２３は、ユニキャスト要求部２１に対して、コンテンツを取得するよう要求する。コンテンツの特定はＵＲＬ（Uniform Resource Locator）で行う。ユニキャスト要求部２１は当該ＵＲＬのコンテンツの要求をＨＴＴＰプロトコルに従ってネットワークインタフェース２０にリクエストする。このとき、リクエストはコンテンツのすべてのデータではなく、コンテンツを分割したブロックを順に取得するよう複数のリクエストを順に行う。ネットワークインタフェース２０はリクエストをネットワーク２を通じてコンテンツサーバ１に出力する。また、コンテンツサーバ１からＨＴＴＰレスポンスがあればＨＴＴＰレスポンスをユニキャスト要求部２１に出力する。ユニキャスト要求部２１はＨＴＴＰレスポンスからコンテンツを取り出し記録部２４に保管する。

また、ユニキャスト要求部２１は記録部２４にコンテンツのすべてのデータが記録されると再生部２３にコンテンツ取得の終了を通知する。ユニキャスト要求部２１は記録部２４へのコンテンツの記録に不足があれば、再度不足分の先頭から一定サイズのデータを順番に取得する。再生部２３はコンテンツ取得の終了を通知された場合、コンテンツを記録部２４から取り出し映像信号に変換し映像表示装置４に表示する。

またユニキャスト要求部２１は、応答されたＨＴＴＰレスポンスのＨＴＴＰレスポンスヘッダにマルチキャストＩＰアドレスが付加されている場合は、当該コンテンツが当該マルチキャストＩＰアドレスでマルチキャスト型で配信されているとみなし、マルチキャスト受信部２２に当該マルチキャストＩＰアドレスのマルチキャスト型配信を受信するよう要求するとともに、ＨＴＴＰプロトコルを用いたコンテンツのリクエストを中止する。

マルチキャスト受信部２２は、ユニキャスト要求部２１からマルチキャスト配信の受信を要求された場合、通知されたマルチキャストＩＰアドレスの購読（ＪＯＩＮ）をネットワークインタフェース２０に要求する。ネットワークインタフェース２０は、ネットワーク２にたいして当該マルチキャストＩＰアドレスの購読（ＪＯＩＮ）を行う。以降、ネットワーク２は、当該マルチキャストＩＰアドレスで配信されるパケットを購読した端末３に出力する。ネットワークインタフェース２０は、当該マルチキャストＩＰアドレス宛てに配信されたパケットを受信した場合、そのパケットをマルチキャスト受信部２２に出力する。

マルチキャスト受信部２２は受信したパケットのコンテンツヘッダからコンテンツの位置を識別し、パケット中のコンテンツを記録部２４に記録する。このとき、コンテンツのすべてのデータがそろった場合は、再生部２３にコンテンツの取得の完了を通知するとともに当該マルチキャストＩＰアドレスの購読の中止をネットワークインタフェース２０に通知する。そして、ネットワークインタフェース２０は当該マルチキャストＩＰアドレスの購読の中止をネットワーク２に要求する。

マルチキャスト受信部２２は、マルチキャスト配信の購読中で、一定時間マルチキャスト配信の受信がない場合はマルチキャスト配信の購読の中止をネットワークインタフェース２０に要求するとともにユニキャスト要求部２１にマルチキャスト配信の購読の中止を通知する。ユニキャスト要求部２１は、マルチキャスト配信の購読の中止が通知された場合、記録部２４に蓄積されているコンテンツのデータの不足分をＨＴＴＰプロトコルを用いてコンテンツサーバ１から取得する。

記録部２４は、ユニキャスト要求部２１およびマルチキャスト受信部２２から、コンテンツを記録されるほか、記録部２４に記録されているコンテンツについて、取得が完了しているかどうか、また未取得の領域の情報に関する問い合わせに応答する。また再生部２３からコンテンツの要求があったときにコンテンツを出力する。

以上のように、コンテンツサーバ１と端末３は協調して、同一コンテンツを要求する端末数が少ない場合にＨＴＴＰプロトコルを用いたユニキャスト型の配信、受信でコンテンツを通信し、多い場合にはコンテンツをマルチキャスト型で配信、受信し、また端末数が少なくなった場合にはユニキャスト型の通信に戻る。

図４にＨＴＴＰプロトコルを用いたユニキャスト型配信を行う場合のデータ構造を示す。

３１はＨＴＴＰリクエストである。行４１に、リクエストはＧＥＴメソッドで行われ、取得するコンテンツをＵＲＬで指定することが示される。このときの取得するコンテンツの範囲を行４２に指定する。Ｒａｎｇｅヘッダは取得したいデータの範囲を示す。０−９９９は最初のデータを０番目としたときにバイト単位で０番目〜９９９番目のデータを取得したいと要求することを示す。

３２は、ＨＴＴＰレスポンスである。行５１では、ＨＴＴＰレスポンスの中身がコンテンツのすべてのデータではなく、分割されたブロック部分のみであることが示される。これは、２番目のパラメータが”２０６”であることで判別する。行５２は、レスポンスを作成した日時を示す。行５３はＨＴＴＰレスポンスに含まれるコンテンツの範囲を示す。これはＨＴＴＰリクエストで要求された範囲と一致する。行５４は空行である。行５２，行５３はＨＴＴＰレスポンスヘッダである。ＨＴＴＰレスポンスヘッダは、レスポンスされたデータではなく、データの属性やレスポンスの条件などを示し、ＨＴＴＰレスポンスの２行目から始まり、空行の前の行で終わる。行５５以降はレスポンスされたデータすなわちコンテンツ本体である。

３３は、Ｘ−ｍｕｌｔｉｃａｓｔヘッダが含まれる場合のＨＴＴＰレスポンスである。前記ＨＴＴＰレスポンス３２との違いはＨＴＴＰレスポンスヘッダのいずれかの場所に行５６に示すＸ−ｍｕｌｔｉｃａｓｔヘッダが含まれていることである。このヘッダが含まれている場合は、当該コンテンツがマルチキャスト型で配信されており、またそのマルチキャストＩＰアドレスがＸ−ｍｕｌｔｉｃａｓｔヘッダのパラメータ、ここでは２３３．４４．６７．３３であることを示す。

図５にマルチキャスト型配信で用いるマルチキャストパケット１００の構造を示す。

マルチキャストパケット１００はＵＤＰで伝送される。そのため先頭にＵＤＰヘッダ１０１が付加される。ＵＤＰペイロードとしてコンテンツヘッダ１０２とコンテンツ本体１０３が伝送される。コンテンツヘッダ１０２はコンテンツ本体１０３の属性を示し、コンテンツ本体１０３はマルチキャストパケット１００であるコンテンツの一部である。コンテンツヘッダ１０２には少なくともオフセット１０４とレングス１０５が含まれる。オフセット１０４はコンテンツ本体１０３の先頭データが、マルチキャストパケット１００のどの部分であるかをバイト単位で示したデータである。コンテンツ本体１０３のデータがコンテンツの１０００バイト目からのデータである場合、オフセット１０４は１０００となる。レングス１０５は、コンテンツ本体１０４の長さをバイト単位で表したものである。

図６は、コンテンツサーバ１のユニキャスト応答部１２で実行するフローチャートである。このフローはコンテンツごとに実行される。

ステップ６０はＨＴＴＰリクエスト待ちループである。当該コンテンツに対するＨＴＴＰリクエストがあればステップ６１に遷移する。またステップ６０ではタイマーを実行し、タイムアウトした場合にはステップ６４に遷移する。

ステップ６１は当該コンテンツがマルチキャスト配信されているかどうかをマルチキャスト配信部１３に問い合わせる。マルチキャスト配信を行っている場合にはステップ６３へ、行っていない場合にはステップ６２へ遷移する。

ステップ６２では、ＨＴＴＰリクエストのＵＲＬで指定されたコンテンツのＲａｎｇｅヘッダで指定されたデータをｘ−ｍｕｌｔｉｃａｓｔヘッダなしで返信を行い、ステップ６０に戻る。

ステップ６３では、ＨＴＴＰリクエストのＵＲＬで指定されたコンテンツのＲａｎｇｅヘッダで指定されたデータを返信する。このときＨＴＴＰレスポンスヘッダにｘ−ｍｕｌｔｉｃａｓｔヘッダを付加して返信する。パラメータとしてマルチキャストＩＰアドレスが用いられる。マルチキャストＩＰアドレスは、マルチキャスト配信部１３から取得する。そして、ステップ６０に戻る。

ユニキャスト応答部１２は、ステップ６０でＨＴＴＰリクエストが来ずタイムアウトした場合、ステップ６４でマルチキャスト配信を行っているかどうかをマルチキャスト配信部１３に問い合わせる。マルチキャスト配信を行っている場合にはステップ６７へ、行っていない場合にはステップ６５へ遷移する。

ステップ６５では、当該コンテンツの単位時間当たりのユニークな接続数を計測部１４に問い合わせる。当該コンテンツの単位時間当たりのユニークな接続数がα以上であればステップ６６に遷移し、そうでなければステップ６０のＨＴＴＰリクエスト待ちに戻る。

ステップ６６では、ユニキャスト応答部１２は、マルチキャスト配信部１３に当該コンテンツのマルチキャスト配信を要求する。

ステップ６７では、当該コンテンツの単位時間当たりのユニークな接続数を計測部１４に問い合わせる。当該コンテンツの単位時間当たりのユニークな接続数がβより少なければステップ６８に遷移し、そうでなければステップ６０に戻る。

ステップ６８では、ユニキャスト応答部１２は、マルチキャスト配信部１３に当該コンテンツのマルチキャスト配信の中止を要求する。

図７は、前記コンテンツの単位時間当たりのユニークな接続数とマルチキャスト配信の関係を示している。図７に従えば、接続数がαを超えるとコンテンツ９２−１についてマルチキャスト型配信を開始する。そのコンテンツ９２−１の配信が終了すれば、再度同じコンテンツ９２−２についてマルチキャスト型配信を行う。

さらに、次の再度同じコンテンツ９２−３をマルチキャスト型配信しているときに、接続数がβを下回ると、マルチキャスト型配信を中止するが、そのとき配信していたコンテンツ９２−３については、そのコンテンツの終了までマルチキャスト型配信を継続する。

図８は、端末３におけるユニキャスト要求部２１の動作である。再生部２３からコンテンツの取得が要求された場合、ステップ７１に遷移する。

ステップ７１ではユニキャスト型配信のコンテンツの一部の取得要求を行う。図４に示すように、使用するプロトコルはＨＴＴＰであり、ＧＥＴメソッド３１を用いる。コンテンツの特定はＵＲＬで指定する。ユニキャスト要求部２１は、記録部２４に未取得部分の確認を行い、未取得のデータの先頭から１ＫＢごとに取得要求を行う。そのためＨＴＴＰリクエストヘッダでＲａｎｇｅ指定を行う。ステップ７１のＨＴＴＰリクエスト後ステップ７２に遷移する。

ステップ７２では、コンテンツサーバ１からのＨＴＴＰレスポンス３２，３３を待つ。ＨＴＴＰレスポンス３２，３３が到着した場合はステップ７３に遷移する。

ステップ７３では、ＨＴＴＰレスポンス３２，３３のコンテンツ本体５５を記録部２４に記録する。このとき、ＨＴＴＰレスポンスヘッダのＣｏｎｔｅｎｔ−Ｒａｎｇｅヘッダ５３の次行５６欄のパラメータを参照する。その後ステップ７４に遷移する。

ステップ７４では、ＨＴＴＰレスポンスヘッダにｘ−ｍｕｌｔｉｃａｓｔヘッダが含まれているかどうかをチェックする。含まれている場合にはステップ７５へ遷移し、含まれていない場合はステップ７６に遷移する。

ステップ７５では、マルチキャストＩＰアドレスとしてｘ−ｍｕｌｔｉｃａｓｔヘッダのパラメータを抜き出し、マルチキャスト受信部２２に通知し、当該コンテンツのマルチキャスト配信の受信を要求し、その後に動作を終了する。

ステップ７６では、当該コンテンツの取得が完了したかどうかを記録部２４に問い合わせる。完了した場合にはステップ７７に遷移し、完了していない場合はステップ７１に遷移する。

ステップ７７では、再生部２３にコンテンツ取得の完了を通知した後動作を終了する。

なお、ユニキャスト要求部２１の動作の開始は、上述のように再生部２３から要求される場合と、マルチキャスト受信部２２から要求される場合があるが、動作は同じである。ここにマルチキャスト受信部２２が要求する場合の例とは、後述する図９のステップ８６である。

図９は、マルチキャスト受信部２２の動作である。ユニキャスト要求部２１がマルチキャストＩＰアドレスを通知したときに動作を開始しステップ８０に遷移する。

ステップ８０では、マルチキャスト配信に参加を行う。ＩＧＭＰ（Internet Group Management Protocol）を用いて当該マルチキャストＩＰアドレスの送信をネットワーク２に依頼した後にステップ８１に遷移する。依頼はＪＯＩＮのコマンドを用いて行う。

ステップ８１は受信待ちループである。当該マルチキャストＩＰアドレス宛のパケットを受信した場合ステップ８２に遷移する。またタイマーがタイムアウトした場合はステップ８６に遷移する。

ステップ８２では受信したパケットのコンテンツヘッダ１０２のオフセット１０４とレングス１０５を取り出し（図５参照）、コンテンツ本体１０３を記録部２４に記録する。このとき記録する場所を決定するため、パケットのコンテンツヘッダ１０２のオフセット１０４とレングス１０５を取り出してそれを利用する。その後ステップ８３に遷移する。

ステップ８３では当該コンテンツの取得が完了したかどうかを記録部２４に問い合わせる。完了した場合にはステップ８４に遷移し、完了していない場合はステップ８０に遷移する。

ステップ８４では、当該コンテンツの取得の完了を再生部２３に通知した後ステップ８５に遷移する。

ステップ８５では、マルチキャスト配信の受信を中止する。すなわちＩＧＭＰを用いて当該マルチキャストＩＰアドレスの配送の中止をネットワーク２に依頼した後に動作を終了する。配送の中止はＬＥＡＶＥコマンドで行う。

ステップ８６では、マルチキャスト配信が中止されたと判断し、ユニキャストでの受信の再開をユニキャスト要求部２１に行いステップ８４に遷移する。

次に、本実施の形態における配信のさらなる具体例を説明する。

図１０に、すべてユニキャスト型の配信でコンテンツの取得を行った場合のパケットの取得方法および取得順番について示す。１１１はパケットの取得順番を示す番号であり、１１２は取得方法を示す。”ユニキャスト”はＨＴＴＰリクエストを用いて取得した場合、”マルチキャスト”はマルチキャスト型配信の受信を行った場合である。１１３は、取得したパケットのブロック番号であり、１１４は、ユニキャスト型配信で取得を行った場合、ＨＴＴＰレスポンスのヘッダにｘ−ｍｕｌｔｉｃａｓｔヘッダが存在するか否かを示す。１１５はマルチキャスト型配信で取得した場合にその後タイムアウトがあったかどうかを示す（図９のステップ８１参照）。

ここではマルチキャスト型の配信では１０ＫＢのコンテンツを１０個のブロックに分割し後ろから順に配信し、ユニキャスト型の配信でのコンテンツ取得では１ＫＢごとに前から順にコンテンツを取得するものとする。すなわち、双方の配信では逆の順番でコンテンツのブロックを取得するようにしている。パケットの番号は先頭から１ＫＢごとに１，２、３、・・・・、９、１０と付与したものである。

最初にユニキャスト型配信で先頭の１ブロック分に相当する範囲のコンテンツのデータを取得する。ここで、ＨＴＴＰレスポンスのヘッダにｘ−ｍｕｌｔｉｃａｓｔヘッダがなしなので、順次ブロック２に相当するデータ、ブロック３に相当するデータと順次取得し、１０回取得を繰り返すことでコンテンツの取得を完了する。ここでは、すべてのユニキャスト型配信でのデータ取得のさいｘ−ｍｕｌｔｉｃａｓｔヘッダがなかった例である。

次に、図１１は、コンテンツサーバ１が所定の端末グループに対して所定のコンテンツのマルチキャスト型配信を行っているときに、新たな端末３がそのコンテンツを取得する際のパケットの取得方法および取得順番について示す。

その新たな端末３が先ずユニキャスト型配信で先頭の１ブロック分に相当する範囲のコンテンツのデータを取得する。このときにＨＴＴＰレスポンスヘッダにｘ−ｍｕｌｔｉｃａｓｔヘッダがあるので、ユニキャスト型配信での取得を中止し、マルチキャスト型配信の受信を開始するが、既にマルチキャスト型配信を他の端末グループへ行っているので、その開始の際最初に取得するブロックの番号は不定であるが（図１１の例では５番を取得している）、全部のブロックが逆順に循環して配信されるので１周すればすべてのデータを取得できる（５＞４＞３＞２＞１＞１０＞９＞８＞７＞６）。循環して１周したときにすべてのブロックの受信が終了する。ここではマルチキャスト型配信で全てのブロックの受信がなされ、途中でタイムアウトがなかった、すなわち、マルチキャスト型配信に参加している端末の数がαを上回ったままで、順次マルチキャスト型配信でブロックが受信出来たものとする。

なお、最初のブロックについて、多くの場合、ユニキャストとマルチキャストでの取得が重複するが、この時間および通信量が問題であれば、最初に取得するユニキャストのデータ量を１バイトなど小さくすれば問題ない。

次に、図１２に、ある端末３がユニキャスト型での配信を取得中にマルチキャスト型の配信が始まった場合のパケットの取得方法および取得順番について示す。まず、その端末３が先頭の１ブロック分に相当する範囲のコンテンツのデータを取得する。このときにｘ−ｍｕｌｔｉｃａｓｔヘッダがないので、以後順次次のブロックの取得をユニキャスト型で行う。そして５番目のブロックの取得の際にそのＨＴＴＰレスポンスヘッダ中に、マルチキャスト型の配信に切り替わったことを示すｘ−ｍｕｌｔｉｃａｓｔヘッダが「ある」ので、ユニキャスト型での取得を中止し、マルチキャスト型配信の受信を行う。なお、コンテンツサーバ１はマルチキャスト配信の開始時（切替時）にはブロックの後ろから配信を開始するので、受信されるブロックは最後の１０から始まって逆順に受信することになる。

したがって端末３は、ブロック６の受信によってコンテンツのデータをすべて受信できる。このようにコンテンツサーバ１が逆順にマルチキャスト型の配信することによって、端末３にとって時間の無駄のないコンテンツデータの取得が可能となる。

図１３は、既に他の端末３に対してマルチキャスト型配信中に、新たに当端末３がユニキャスト型の配信を要求し、マルチキャスト型の配信に切り替えられ、その後さらにマルチキャスト型の配信が中止された時のパケットの取得方法および取得順番について示す。
端末３は、先頭の１ブロック分に相当する範囲のコンテンツのデータを取得する。このときにそのＨＴＴＰレスポンスヘッダ中に、ｘ−ｍｕｌｔｉｃａｓｔヘッダが「ある」ので、ユニキャスト型での取得を中止し、マルチキャスト型の配信の受信を開始する。最初に取得するブロックは既に他の端末３に対してマルチキャスト型配信中であるので不定であるが、ここではブロック５が受信されたとする。

そして逆順に受信を続け、たまたまブロック１の受信後に、マルチキャスト型配信を受信している端末の数がβを下回ったため、コンテンツサーバ１がマルチキャスト型配信を中止し（図６のステップ６８参照）、タイムアウトが起きたとする（図９のステップ８１参照）。この場合、マルチキャスト型配信の受信を中止し、ユニキャスト型での取得を行う。このときは、記録部２４に記録されていないブロック（この場合は６，７，８，９，１０）を順にユニキャスト型配信で取得する（図９のステップ８６参照）。このようにしてコンテンツ全体の取得を行う。

以上のようにして本実施の形態のシステムでコンテンツデータの取得を行う。

なお、上述した本実施の形態では、まずユニキャスト型配信でコンテンツの一部を取得し、その際にマルチキャスト配信を行っているかどうかの情報をＨＴＴＰレスポンスヘッダを利用して同時に取得したが、別途マルチキャスト型配信を行っているかどうかを応答する問い合わせサーバを用意し、コンテンツの取得に先立って端末がマルチキャスト型配信の有無を問い合わせ、マルチキャスト型配信している場合には、最初から、ユニキャスト型でのコンテンツ取得を行わずマルチキャスト型配信の受信を行ってもよい。

また、本実施の形態では単位時間当たりのユニーク接続数がβを下回ったときに、そのとき配信しているコンテンツがすべて配信された時にマルチキャスト配信を中止したが、単位時間当たりのユニーク接続数がβを下回ったときに、直ちにマルチキャスト配信を中止してもよい。

また、本実施の形態では、マルチキャスト型配信の受信の中止を、マルチキャストパケットの受信タイムアウトで判別したが、問い合わせサーバにマルチキャスト配信の有無を問い合わせ、マルチキャスト配信していない場合に、マルチキャスト配信の受信の中止を行うようにしてもよい。

また、本実施の形態では、マルチキャスト配信の受信の中止を、マルチキャストパケットの受信タイムアウトで判別したが、マルチキャスト配信時のコンテンツヘッダに、マルチキャスト配信の中止の予告情報を含ませて配信し、端末は、コンテンツヘッダにマルチキャスト配信の中止の予告情報が含まれている場合、当該コンテンツのその回の配信終了を持ってマルチキャスト受信の中止を行い、コンテンツの不足分をユニキャスト通信で要求してもよい。

また、本実施の形態では、マルチキャスト配信の実施の閾値として、単位時間当たりのユニーク接続数を判断基準としたが、別の基準でマルチキャスト配信の有無を決めてもよい。たとえば、マルチキャスト型配信のｎ本可能なサーバおよび通信路を用意し、閾値を上回る、下回るを問わず、閾値とは関係なく、単位時間あたりのユニーク接続数の多い順にｎ個のコンテンツに関してマルチキャスト型配信することとしてもよい。

また、本実施の形態では、端末３がユニキャスト型配信でデータを取得するときは、コンテンツの先頭からもしくは未取得領域を順に取得し、コンテンツサーバ１がマルチキャスト型で配信する場合は、コンテンツを逆順に配信するとしたが、端末３がユニキャスト型配信で逆順に取得し、コンテンツサーバ１がマルチキャスト型配信で順方向に配信しても同様の効果が得られるのはいうまでもない。要するに、両者の型の配信の順番が逆になっていればよい。

さらにまた、本発明において、ユニキャスト型配信とマルチキャスト型配信との両者の配信の順番が逆になる必要性は、一つの端末への一つのコンテンツの配信中での必要性であって、他の端末へのユニキャスト型配信の順番との比較や、あるいは別の内容のコンテンツの配信順番に対する比較はまた別個の問題であり、要するに、少なくとも一つの端末への一つのコンテンツの配信中での必要性である。

また、本発明のプログラムは、上述した本発明のコンテンツ配信システムの全部又は一部をコンピュータにより実行させるためのプログラムであって、コンピュータと協働して動作するプログラムである。

また、本発明の記録媒体は、上述した本発明のコンテンツ配信システムの全部又は一部をコンピュータにより実行させるためのプログラムを記録した記録媒体であり、コンピュータにより読み取り可能且つ、読み取られた前記プログラムが前記コンピュータと協動して前記動作を実行する記録媒体である。

また、本発明のプログラムの一利用形態は、コンピュータにより読み取り可能な、ＲＯＭ等の記録媒体に記録され、コンピュータと協働して動作する態様であっても良い。

また、本発明のプログラムの一利用形態は、インターネット等の伝送媒体、光・電波・音波等の伝送媒体中を伝送し、コンピュータにより読みとられ、コンピュータと協働して動作する態様であっても良い。

また、上述した本発明のコンピュータは、ＣＰＵ等の純然たるハードウェアに限らず、ファームウェアや、ＯＳ、更に周辺機器を含むものであっても良い。

なお、以上説明した様に、本発明の構成は、ソフトウェア的に実現しても良いし、ハードウェア的に実現しても良い。

本発明にかかる コンテンツ配信システム、コンテンツサーバ、端末、コンテンツ配信方法、プログラムおよび記録媒体は、サーバの配信負荷を低減し、端末の受信時間を短くすることが可能であり、インターネットなどで、映像や音声などのコンテンツを配信するコンテンツ配信システムなどとして有用である。

本発明の実施の形態を示すブロック図 本発明の実施の形態におけるコンテンツサーバのブロック図 本発明の実施の形態における端末のブロック図 本発明の実施の形態における、ＨＴＴＰを用いたユニキャスト型配信を行う場合のデータ構造図 本発明の実施の形態におけるマルチキャストパケットの構造図 本発明の実施の形態におけるユニキャスト配信部のフローチャート 本発明の実施の形態における、端末の接続数とマルチキャスト型配信との関係を示すグラフ 本発明の実施の形態におけるユニキャスト要求部のフローチャート 本発明の実施の形態におけるマルチキャスト受信部のフローチャート 本発明の実施の形態における、コンテンツブロックの配信の具体例を示す図 本発明の実施の形態における、コンテンツブロックの配信の具体例を示す図 本発明の実施の形態における、コンテンツブロックの配信の具体例を示す図 本発明の実施の形態における、コンテンツブロックの配信の具体例を示す図

符号の説明

１ コンテンツサーバ
２ ネットワーク
３ 端末
４ 映像表示装置
１０ コンテンツ記録部
１１ ネットワークインターフェース
１２ ユニキャスト応答部
１３ マルチキャスト配信部
１４ 計測部
２０ ネットワークインターフェース
２１ ユニキャスト要求部
２２ マルチキャスト受信部
２３ 再生部
２４ 記録部
１００ マルチキャストパケット

Claims (10)

1. コンテンツを保持し、複数のブロックに分割して配信するコンテンツサーバと、前記コンテンツサーバからネットワークを介して前記コンテンツを取得する複数の端末とを備えたコンテンツ配信システムにおいて、
   前記端末は、前記コンテンツサーバがユニキャスト型でコンテンツを配信している時はユニキャスト型で配信を受け、マルチキャスト型でコンテンツを配信している時は、マルチキャスト型で配信を受け、
   前記コンテンツサーバは、少なくとも一つの端末に関して、一つの前記コンテンツを分割配信中に配信の型が変わる場合、ユニキャスト型で配信する場合の順番と、前記マルチキャスト型で配信する場合の順番が互いに逆になるように配信する、コンテンツ配信システム。
2. 前記コンテンツサーバは、コンテンツ毎に単位時間当たりの要求端末数を計測し、予め決められた一定数を超えた場合、その一定数を超えたコンテンツについてマルチキャスト型の配信を開始する、請求項１記載のコンテンツ配信システム。
3. 前記コンテンツサーバは、前記端末からユニキャスト型でコンテンツを要求されたとき、前記コンテンツの配信に加えて前記コンテンツがマルチキャスト型で配信されているかの別も応答する、請求項１記載のコンテンツ配信システム。
4. 前記コンテンツサーバは、前記コンテンツがマルチキャスト型配信されていることを応答するために、マルチキャストＩＰアドレスを前記端末へ知らせる、請求項３記載のコンテンツ配信システム。
5. 前記端末は、前記ユニキャスト型でコンテンツ配信を要求したとき、前記コンテンツサーバから前記コンテンツがマルチキャスト配信されているとの応答があった場合、ユニキャスト型でのコンテンツ取得を中止し、マルチキャスト型での配信を受ける、請求項３記載のコンテンツ配信システム。
6. コンテンツを保持し、複数のブロックに分割して、ネットワークを介して複数の端末に配信するコンテンツサーバにおいて、
   少なくとも一つの前記端末に関して、一つの前記コンテンツを分割配信中に配信の型が変わる場合、ユニキャスト型で配信する場合の順番と、前記マルチキャスト型で配信する場合の順番が互いに逆になるように配信する、コンテンツサーバ。
7. コンテンツを保持するコンテンツサーバから、前記コンテンツを複数のブロックに分割して、ネットワークを介して受信する端末において、
   ユニキャスト型配信でコンテンツを受信している際に、そのコンテンツとは別にそのコンテンツがマルチキャスト型で配信されている旨知らされた場合、前記ユニキャスト型配信でのコンテンツ取得を中止し、マルチキャスト型での配信で、前記ユニキャスト型配信の順番とは逆順で前記コンテンツを受信する、端末。
8. コンテンツを保持するコンテンツサーバにより、前記コンテンツを分割して複数の端末に配信するコンテンツ配信方法において、
   前記所定のコンテンツの分割配信中に配信の型が変わる場合、前記コンテンツをユニキャストで配信する際の順番と、前記コンテンツを前記マルチキャストで配信する際の順番とを逆として配信する、コンテンツ配信方法。
9. 請求項１記載のコンテンツ配信システムの、前記コンテンツサーバがユニキャスト型でコンテンツを配信している時はユニキャスト型で配信を受け、マルチキャスト型でコンテンツを配信している時は、マルチキャスト型で配信を受ける前記端末、少なくとも一つの端末に関して、一つの前記コンテンツを分割配信中に配信の型が変わる場合、ユニキャスト型で配信する場合の順番と、前記マルチキャスト型で配信する場合の順番が互いに逆になるように配信する前記コンテンツサーバ、としてコンピュータを機能させるためのプログラム。
10. 請求項９記載のプログラムを記録した記録媒体であって、コンピュータにより処理可能な記録媒体。

Images