JP2004102493A

JP2004102493A - コンテンツ配信方法及びコンテンツ配信制御装置

Info

Publication number: JP2004102493A
Application number: JP2002261261A
Authority: JP
Inventors: Hirofumi Abe; 阿部　裕文
Original assignee: Nippon Telegraph and Telephone Corp
Current assignee: Nippon Telegraph and Telephone Corp
Priority date: 2002-09-06
Filing date: 2002-09-06
Publication date: 2004-04-02

Abstract

【課題】本発明は情報を提供するサーバにかかる負荷を効率的に分散するとともに新たな設備を導入するコストや設備を管理及び運営するコストなどの増大を抑制することを目的とする。
【解決手段】更新されたコンテンツを一纏めにして書庫として管理する手順と、書庫の転送先の受信装置を決定する手順と、書庫を送信装置から決定された特定の受信装置に転送する手順と、各受信装置が送信装置の書庫を受け取った場合に、第１のイベント情報を生成し前記送信装置に通知する手順と、各受信装置が受信した書庫の内容を展開して管理する手順と、各受信装置が受信した書庫の情報の再転送先となる他の受信装置を決定する手順と、書庫の情報を受信した第１の受信装置から再転送先の第２の受信装置に対して書庫の情報を転送する手順と、各受信装置が他の受信装置から書庫を受け取った場合に第２のイベント情報を転送元と送信装置に通知する手順とを設けた。
【選択図】　　　図１

Description

【０００１】
【発明の属する技術分野】
本発明は、様々なコンテンツのデータを不特定多数に配信する場合に利用可能なコンテンツ配信方法及びコンテンツ配信制御装置に関する。
【０００２】
【従来の技術】
コンテンツ配信方法や配信時のサーバにかかる負荷を効率的に削減する従来技術として、マルチキャストを用いてファイルを配信する方法（特許文献１）、オリジナルサーバに蓄積するコンテンツのうち人気のあるものだけを配信するシステム（特許文献２）、オリジナルサーバで更新され続けるコンテンツのうち、最新の差分だけを配信する方法（特許文献３）などがある。
【特許文献１】特願２００２−０２４３８９号
【特許文献２】特開２００１−２７９６５号公報
【特許文献３】特開２００１−９２６９９号公報
インターネット上のようにアクセスが集中する可能性のある環境で様々なコンテンツの情報を提供しようとする場合には、サーバに対する負荷を分散するために複数のサーバをネットワークに接続し、それぞれのサーバにコンテンツの情報を蓄積しておく場合が多い。
【０００３】
このような通信システムにおいては、最初にコンテンツを保持する１つのサーバはオリジナルサーバと呼ばれ、オリジナルサーバからコンテンツの転送を受ける他のサーバはミラーサーバと呼ばれる。
オリジナルサーバから不特定多数のミラーサーバに対してコンテンツを配信する場合の配信方式としては、ＰＵＳＨ型，ＰＵＬＬ型，ＩＰマルチキャストプロトコルを用いる方式などが考えられる。
【０００４】
ＰＵＳＨ型の場合には、オリジナルサーバからミラーサーバに対してコンテンツを送りつける。ＰＵＬＬ型の場合には、ミラーサーバが定期的にオリジナルサーバに問い合わせを行い、更新されたコンテンツをミラーサーバがオリジナルサーバからダウンロードする。ＩＰマルチキャストプロトコルを用いる場合には、オリジナルサーバから全てのミラーサーバに対して一斉にコンテンツを配信する。
【０００５】
また、ＰＵＳＨ型は更に一定間隔方式，スケジュール方式，オンデマンド方式などに区分することができる。
一定間隔方式の場合には、コンテンツを送信する契機として、１分おき、１時間おきなどの一定時間間隔を用いる。スケジュール方式の場合には、例えば毎朝６時など予めスケジュールで定めた時刻に配布を開始する。オンデマンド方式の場合には、コンテンツ提供者が送りたいときに配布を開始する。
【０００６】
また、配信宛先が大量になる場合には、同時に配信する宛先数を制限して配信セッションを分けたり、分けることができない場合にはオリジナルサーバの数を宛先数に応じて増やしたりして対処するのが一般的である。
配信セッションを分ける方法では、オリジナルサーバを増やすことなく多数の宛先に配信することが可能であり、低コストであるという長所があるが、宛先数が増えるに従って配信所要時間が長くなるという問題もある。
【０００７】
このため、一定間隔方式やスケジュール方式を採用している場合には、オリジナルサーバにおいて、最初に起動された配信処理中に、次に起動された配信処理が重ならないように配信処理間隔を定める必要がある。また、オリジナルサーバが故障すると全ての配信処理が停止するので、オリジナルサーバのクラスター化のような信頼性向上施策が不可欠である。
【０００８】
ＰＵＬＬ型についても、ＰＵＳＨ型と同様に一定間隔方式，スケジュール方式，オンデマンド方式などの配信契機を持たせることができる。
ＰＵＬＬ型の場合には、オリジナルサーバにおけるファイルリストとミラーサーバにおけるファイルリストとを比較して、足りないファイルをダウンロードすることができるので、ミラーサーバにおいて欠損ファイルが生じたり、何らかの理由で更新間隔が長くなってしまった場合には、容易にミラーサーバのコンテンツの内容をオリジナルサーバと同一の内容までキャッチアップすることができる。
【０００９】
しかしながら、ＰＵＬＬ型の場合にはミラーサーバがオリジナルサーバにいつアクセスするかや、オリジナルサーバからミラーサーバへのファイルの転送がいつ終了するかが分からないので、配信宛先数が増えた場合に負荷を分散するのが困難になる。
【００１０】
すなわち、ＰＵＬＬ型の場合にはミラーサーバがオリジナルサーバにいつアクセスするかをオリジナルサーバ上で把握できないので、ＰＵＳＨ型の場合のようにオリジナルサーバからの同時配信処理数を制限するようにサーバ毎の配信処理時間を定めることができない。
従って、大量のミラーサーバからのアクセス負荷を分散するために、オリジナルサーバを複数台用意しておき、ミラーサーバ群はいくつかの台数毎にグループに分け、グループ毎に異なるオリジナルサーバを割り当てるような構成をとる必要がある。
【００１１】
また、ミラーサーバをグループ分けしない場合にはオリジナルサーバとミラーサーバ群との間に負荷分散装置を配置し、ミラーサーバ群からのアクセスを負荷分散装置で振り分ける処理を行う必要がある。
また、ＰＵＳＨ型、ＰＵＬＬ型のいずれの場合についても、データセンタを構成する場合には高信頼なオリジナルサーバを設置し、大容量配信のためにネットワーク帯域を増強する必要がある。
【００１２】
ミラーサーバが増えた場合の負荷の集中を防止するのに最も適した方法は、ＩＰマルチキャストを用いてファイルを配信することである。
ＩＰマルチキャストを用いると、最も理想的な場合には一度の配信処理だけで、全てのミラーサーバヘのファイル配信を完了することができる。しかし、実際のインターネットではＩＰパケットの消失の無い理想的な配信は困難なのでＩＰパケットの再送によるエラー回復が必要になる。
【００１３】
エラー回復の技術については、連送配信と逐次回復の２つに分けることができる。連送配信の場合には、最初から同じデータを複数回重複させて配信する。逐次回復の場合には、受信に失敗したミラーサーバに対して回復データをＴＣＰコネクションで受け渡す。
しかし、受信側のミラーサーバの数が増大すると、連送配信の場合には確率的には連送回数を増やす必要があるし、逐次回復の場合には確率的にエラーを起こす受信側が増えるので、エラー回復のためのオリジナルサーバの負荷が増大するのは避けられない。
【００１４】
一方、ＩＰマルチキャストプロトコルは、公共のネットワークであるインターネット上では実質的に伝搬不可能であるし、イントラネット内であっても、ネットワーク機器やサイトポリシーの都合により伝搬不可能な場合が多い。
そのため、ＩＰマルチキャストプロトコルを用いたファイル配信は実際には採用できない場合がほとんどである。
【００１５】
【発明が解決しようとする課題】
大量のファイルを大量のミラーサーバに配信するような場合には、前述のＰＵＳＨ型配信、ＰＵＬＬ型配信のいずれであっても、受信先のミラーサーバの数の増大に伴って、オリジナルサーバ側のサーバ端末やネットワークの負荷が増大することは避けられない。
【００１６】
このような負荷を分散する手法としては、オリジナルサーバからミラーサーバヘの配信時間をずらし、時間軸に沿って負荷を分散する方式や、オリジナルサーバの台数を増強するとともにネットワークの帯域幅も増やし、設備増強により負荷を分散する方式とがある。
しかし、前者の負荷分散方式では、ファイルサイズが大きくなったり、宛先ミラーサーバの数が著しく増大した場合には、許容された時間内で配信が終了できない可能性がある。
【００１７】
また、後者の負荷分散方式では、設備を導入するコストや設備を管理及び運営するコストなどがかさんでしまい、ファイルを分散させるメリットが薄れてしまう。
このように、オリジナルサーバにかかる負荷が大きく、またその負荷を分散させることが難しい一方で、ミラーサーバ側はオリジナルサーバからのファイルを受信する以外の負荷はほとんどかかっておらず、サーバ能力及びネットワーク帯域幅には共に余力がある。
【００１８】
なお、このような状況はオリジナルサーバと多数のミラーサーバとで構成される特定の通信システムに限ったことではなく、サーバと多数のクライアント端末とで構成される一般的な通信システムにおいても想定される問題である。
本発明は、情報を提供するサーバにかかる負荷を効率的に分散するとともに、新たな設備を導入するコストや設備を管理及び運営するコストなどの増大を抑制することを目的とする。
【００１９】
【課題を解決するための手段】
請求項１は、送信装置と複数の受信装置とが所定の通信網を介して互いに接続された通信システムを用いて、前記送信装置の保持しているコンテンツの情報を各々の受信装置に配信するためのコンテンツ配信方法において、前記送信装置上で新規に登録されたコンテンツ及び内容の更新されたコンテンツを一纏めにして圧縮し書庫として管理するコンテンツ書庫化手順と、前記書庫で管理されている情報の転送先の受信装置を決定する転送宛先決定手順と、前記書庫で管理されている情報を送信装置から決定された特定の受信装置に転送する書庫転送手順と、各受信装置が前記送信装置の書庫で管理されている情報を受け取った場合に、第１のイベント情報を生成する第１のイベント情報生成手順と、生成された第１のイベント情報を前記送信装置に通知する第１のイベント情報通知手順と、各受信装置が前記書庫で管理されている情報を受け取った場合に、受信した書庫の内容を展開して管理する書庫情報展開手順と、各受信装置が前記書庫で管理されている情報を受け取った場合に、受信した書庫の情報の再転送先となる他の受信装置を決定する再転送先決定手順と、書庫の情報を受信した第１の受信装置から再転送先の第２の受信装置に対して書庫の情報を転送する書庫再転送手順と、各受信装置が他の受信装置から書庫の情報を受け取った場合に、第２のイベント情報を転送元の受信装置及び送信装置の少なくとも一方に通知する第２のイベント情報通知手順とを設けたことを特徴とする。
【００２０】
請求項１においては、送信装置から受信装置に配信すべき情報は、コンテンツ書庫化手順によって最小化される。すなわち、前回の配信時と比べて新たに追加登録されたコンテンツ及び内容の更新されたコンテンツの全てが一纏めにされ、圧縮されて書庫として管理される。従って、配信するファイルのサイズが低減される。
【００２１】
送信装置は配下の全ての受信装置に対してコンテンツを配信する必要はない。すなわち、転送宛先決定手順で決定された特定の転送先の受信装置に対して書庫の情報が書庫転送手順で転送される。
各受信装置が送信装置から書庫の情報を受け取った場合には、第１のイベント情報が生成され、これが送信装置に通知されるので、送信装置は各受信装置に対するコンテンツの配信状況を把握することができる。このようなコンテンツの配信状況は、配信履歴として所定のデータベースに記録される。
【００２２】
コンテンツの配信状況を参照することにより、書庫の情報を取得済みの受信装置と未配信の受信装置とを区別することができる。
請求項１においては、書庫の情報を取得した受信装置は未配信の他の受信装置の有無を識別し、未配信の他の受信装置に対して送信装置の代わりに受信情報を再配信する。
【００２３】
このように、書庫の情報を取得した受信装置が他の受信装置に対して受信情報を再配信するので、送信装置（例えば前述のオリジナルサーバ）は一部分の受信装置（例えば前述のミラーサーバ）だけにコンテンツを配信すればよく、配信先の増大に伴う送信装置側の負荷の増大を受信装置が肩代わりすることになる。従って、配信にかかるコストの低減，時間の短縮，信頼性の向上などが実現する。
【００２４】
請求項２は、請求項１のコンテンツ配信方法において、前記コンテンツ書庫化手順では、書庫化日時と、コンテンツの更新回数を表すバージョンと、書庫に含まれる元のファイルの情報とを属性情報として書庫の情報に含めて管理することを特徴とする。
【００２５】
請求項２においては、属性情報を参照することにより、様々な状況の把握が可能になる。すなわち、書庫化日時及びバージョンの情報を参照することにより、該当するファイルが受信装置の既に受け取った書庫化ファイルと同じか否か、あるいは該当するファイルが受信装置の既に受信して展開したファイルよりも古いか否かを検査することができる。
【００２６】
例えば、受信した書庫化ファイルと同一バージョンのファイル、もしくは受信した書庫化ファイルよりも新しいバージョンのファイルを展開し終えている場合には、受信した書庫化ファイルを展開しないように制御することができる。
なお、書庫に含まれる元のファイルの情報としては、ファイル名，タイムスタンプ，サイズなどが考えられる。これらの情報は、書庫化ファイルを展開した後で、展開したファイルの情報を属性情報に合わせて書き換えるために用いることができる。また、オリジナルコンテンツの全ファイルのファイル名，タイムスタンプ，サイズなどの情報を書庫に含めてもよい。
【００２７】
例えば、送信装置にあるファイルと受信装置にあるファイルのタイムスタンプが両者で一致するように処理することにより、受信装置は自分の保持するファイルが、送信装置にあるファイルと同一かどうかを容易に検査できる。
請求項３は、請求項１のコンテンツ配信方法において、前記転送宛先決定手順では、複数の受信装置を複数のグループに区分して管理するとともに、各グループに含まれる複数の受信装置の各々をグループ内の順位を付けて管理し、最初はグループ内の最上位の受信装置を転送先として選択し、最上位の受信装置が応答しない場合には降順で次の受信装置を選択し、最上位の受信装置についてコンテンツが配信済みの場合には、最下位の受信装置から昇順で受信装置を選択することを特徴とする。
【００２８】
請求項３においては、複数の受信装置を複数のグループに区分して管理するので、グループ毎に転送先の受信装置を決定することができる。このため、全てのグループに均等に転送が配分されるように負荷を分散することも容易である。
また、最初は各グループの最上位の受信装置だけを選択するが、最上位の受信装置が故障などの原因で応答しない場合には、次順位の受信装置を選択する。次順位の受信装置が故障している場合には、更にその次の受信装置というように、降順で受信装置を選択する。
【００２９】
また、一通りのグループに配信が行き渡り、更に各グループ内においてはまだ未配信の受信装置がある場合には、今度は各グループの最下位から昇順で配信先の受信装置を選択する。
請求項４は、請求項１のコンテンツ配信方法において、前記再転送先決定手順では、複数の受信装置を複数のグループに区分して管理するとともに、各グループに含まれる複数の受信装置の各々をグループ内の順位を付けて管理し、第１の受信装置が書庫の情報を受信した場合には、第１の受信装置が属するグループの中で、コンテンツが未配信の受信装置について、順位が上位の受信装置から降順で再転送先の第２の受信装置を選択することを特徴とする。
【００３０】
請求項４においては、既に書庫の情報を受信した第１の受信装置と同一のグループに属する他の受信装置の中から、再転送先となる第２の受信装置が選択されるので、受信装置同士の間で実施される情報の再転送は同一グループ内に限定される。このため、第２の受信装置の選択が容易になる。また、ネットワーク上の通信経路が複雑化するのを避けることもできる。
【００３１】
請求項５は、請求項１のコンテンツ配信方法において、各受信装置が前記書庫で管理されている情報を受信している時には、書庫の情報を受信中であることを表すロックファイルを作成するロックファイル作成手順と、各受信装置が前記書庫で管理されている情報を受信している時には、少なくとも受信中のファイル名称と、受信対象の書庫全体のサイズと、受信の進捗状態を表す進捗情報とを、一定時間おきに受信装置内のログファイルに出力する受信ログ生成手順とをさらに設けたことを特徴とする。
【００３２】
請求項５においては、ロックファイルの有無を調べることにより、各受信装置が書庫の情報を受信中か否かを識別できる。従って、例えばロックファイルが存在する場合には、たとえ同一コンテンツの書庫化ファイルの配信要求があっても、その要求を受け付けないように制御できる。
なお、ログファイルに出力される進捗情報としては、受信中書庫化ファイルの名称，書庫化ファイル全体のサイズ，現在までに受信が終了したファイル量などが考えられる。
【００３３】
出力されるログ情報については、例えばオペレーターから受信装置に閲覧要求が届いた場合にオペレーターに通知すればよい。従って、オペレータは配信状況をログ情報により確認できる。
請求項６は、請求項５のコンテンツ配信方法において、前記書庫情報展開手順では、各受信装置が受信した書庫の情報を展開処理している時には、展開処理中であることを表すロックファイルを作成するとともに、１ファイルの展開が終了する毎に、展開処理の進捗状態を表す進捗情報を受信装置内のログファイルに出力することを特徴とする。
【００３４】
請求項６においては、ロックファイルの有無を調べることにより、各受信装置が書庫の情報を展開処理中であるか否かを識別できる。従って、例えばロックファイルが存在する場合には、たとえ同一コンテンツの書庫化ファイルが複数存在する場合であっても、他の書庫化ファイルの展開処理を開始しないように制御できる。
【００３５】
ログファイルに出力される進捗情報については、書庫化ファイルに含まれる全ファイル数や現在までに展開が終了したファイル数などが考えられる。
出力されるログ情報については、例えばオペレーターから受信装置に閲覧要求が届いた場合にオペレーターに通知すればよい。従って、オペレータは配信状況をログ情報により確認できる。
【００３６】
なお、受信装置において書庫化ファイルの展開が終了すると、書庫化ファイル展開終了のイベントデータを作成し、それを送信装置にを通知する。通知されたイベントデータは送信装置のデータベースに記録され、転送宛先を決定する際に参照される。
請求項７は、請求項１のコンテンツ配信方法において、前記書庫情報展開手順では、受信した書庫内に含まれているファイルの展開に失敗した場合には、該当するファイルと同じ情報を既に保持している他の受信装置の検索を行い、他の受信装置から該当する書庫のファイルをダウンロードすることを特徴とする。
【００３７】
請求項７においては、受信した書庫内に含まれているファイルの展開に失敗した場合であっても、受信装置における自律的な制御により該当するファイルを他の受信装置からダウンロードしてエラーを回避することができる。
該当するファイルと同じ情報を既に保持している他の受信装置を検索する場合には、最初は同一バージョンのファイルを保持している受信装置を検索する。該当する受信装置が存在しない場合には、同じコンテンツ名の、最も新しいバージョンの書庫化ファイルを保持し、かつネットワーク上で最も近い受信装置を検索する。
【００３８】
なお、エラーの発生したバージョンとは異なる最新バージョンの書庫化ファイルを受信装置が受け取った場合には、バージョンの相違によりコンテンツ内容の不備が生じる可能性がある。
オリジナルコンテンツのファイルリストが書庫化ファイルに付加されている場合には、その内容からコンテンツ内容の不備を検出することが可能である。不足するファイルが存在する場合には、そのファイルを個別に前記最新の書庫化ファイルを保持する受信装置からダウンロードすればよい。
【００３９】
請求項８のコンテンツ配信制御装置は、送信装置と複数の受信装置とが所定の通信網を介して互いに接続された通信システムを用いて、前記送信装置の保持しているコンテンツの情報を各々の受信装置に配信するためのコンテンツ配信制御装置であって、前記送信装置上で新規に登録されたコンテンツ及び内容の更新されたコンテンツを一纏めにして圧縮し書庫として管理するコンテンツ書庫化手段と、前記書庫で管理されている情報の転送先の受信装置を決定する転送宛先決定手段と、前記書庫で管理されている情報を送信装置から決定された特定の受信装置に転送する書庫転送手段と、各々の受信装置について、書庫の情報を受け取ったか否かを表す情報を管理し、その結果を前記転送宛先決定手段の制御に反映する受信状況管理手段とを設けたことを特徴とする。
【００４０】
請求項８においては、請求項１の方法と同様に、送信装置は全ての受信装置に対してコンテンツを配信する必要がないので、送信装置にかかる負荷を分散することができる。
請求項９のコンテンツ配信制御装置は、送信装置と複数の受信装置とが所定の通信網を介して互いに接続された通信システムを用いて、前記送信装置の保持しているコンテンツの情報を各々の受信装置に配信するためのコンテンツ配信制御装置であって、前記送信装置が、新規に登録されたコンテンツ及び内容の更新されたコンテンツを一纏めにして圧縮し書庫として管理するとともに、前記書庫で管理されている情報を特定の受信装置に配信する場合に、各受信装置が前記送信装置の書庫で管理されている情報を受け取った場合に、第１のイベント情報を生成する第１のイベント情報生成手段と、生成された第１のイベント情報を前記送信装置に通知する第１のイベント情報通知手段と、各受信装置が前記書庫で管理されている情報を受け取った場合に、受信した書庫の内容を展開して管理する書庫情報展開手段と、各受信装置が前記書庫で管理されている情報を受け取った場合に、受信した書庫の情報の再転送先となる他の受信装置を決定する再転送先決定手段と、書庫の情報を受信した第１の受信装置から再転送先の第２の受信装置に対して書庫の情報を転送する書庫再転送手段と、各受信装置が他の受信装置から書庫の情報を受け取った場合に、第２のイベント情報を転送元の受信装置及び送信装置の少なくとも一方に通知する第２のイベント情報通知手段とを設けたことを特徴とする。
【００４１】
請求項９においては、請求項１の方法と同様に、各受信装置が書庫の情報を受け取ったか否かを把握することができるので、送信装置から情報を受け取った受信装置は他の受信装置に対して情報を再転送することができる。
受信装置同士の間で情報の再転送が実施されるので、送信装置がコンテンツを配信すべき受信装置の数を減らすことができ、送信装置にかかる負荷を分散することができる。
【００４２】
請求項１０は、請求項８のコンテンツ配信制御装置において、前記コンテンツ書庫化手段は、書庫化日時と、コンテンツの更新回数を表すバージョンと、書庫に含まれる元のファイルの情報とを属性情報として書庫の情報に含めて管理することを特徴とする。
請求項１０においては、請求項２の方法と同様の結果が得られる。
【００４３】
請求項１１は、請求項８のコンテンツ配信制御装置において、前記転送宛先決定手段は、複数の受信装置を複数のグループに区分して管理するとともに、各グループに含まれる複数の受信装置の各々をグループ内の順位を付けて管理し、最初はグループ内の最上位の受信装置を転送先として選択し、最上位の受信装置が応答しない場合には降順で次の受信装置を選択し、最上位の受信装置についてコンテンツが配信済みの場合には、最下位の受信装置から昇順で受信装置を選択することを特徴とする。
【００４４】
請求項１１においては、請求項３の方法と同様の結果が得られる。
請求項１２は、請求項９のコンテンツ配信制御装置において、前記再転送先決定手段は、複数の受信装置を複数のグループに区分して管理するとともに、各グループに含まれる複数の受信装置の各々をグループ内の順位を付けて管理し、第１の受信装置が書庫の情報を受信した場合には、第１の受信装置が属するグループの中で、コンテンツが未配信の受信装置について、順位が上位の受信装置から降順で再転送先の第２の受信装置を選択することを特徴とする。
【００４５】
請求項１２においては、請求項４の方法と同様の結果が得られる。
請求項１３は、請求項９のコンテンツ配信制御装置において、各受信装置が前記書庫で管理されている情報を受信している時には、書庫の情報を受信中であることを表すロックファイルを作成するロックファイル作成手段と、各受信装置が前記書庫で管理されている情報を受信している時には、少なくとも受信中のファイル名称と、受信対象の書庫全体のサイズと、受信の進捗状態を表す進捗情報とを、一定時間おきに受信装置内のログファイルに出力する受信ログ生成手段とをさらに設けたことを特徴とする。
【００４６】
請求項１３においては、請求項５の方法と同様の結果が得られる。
請求項１４は、請求項１３のコンテンツ配信制御装置において、前記書庫情報展開手段は、各受信装置が受信した書庫の情報を展開処理している時には、展開処理中であることを表すロックファイルを作成するとともに、１ファイルの展開が終了する毎に、展開処理の進捗状態を表す進捗情報を受信装置内のログファイルに出力することを特徴とする。
【００４７】
請求項１４においては、請求項６の方法と同様の結果が得られる。
請求項１５は、請求項９のコンテンツ配信制御装置において、前記書庫情報展開手段は、受信した書庫内に含まれているファイルの展開に失敗した場合には、該当するファイルと同じ情報を既に保持している他の受信装置の検索を行い、他の受信装置から該当する書庫のファイルをダウンロードすることを特徴とする。
【００４８】
請求項１５においては、請求項７の方法と同様の結果が得られる。
【００４９】
【発明の実施の形態】
本発明のコンテンツ配信方法及びコンテンツ配信制御装置の１つの実施の形態について、図１〜図１１を参照して説明する。この形態は全ての請求項に対応する。
【００５０】
図１は通信システムの構成例を示すブロック図である。図２は送信装置の動作を示すフローチャートである。図３は受信装置の動作を示すフローチャートである。図４は転送宛先決定部の動作（１）を示すフローチャートである。図５は転送宛先決定部の動作（２）を示すフローチャートである。
図６は通信システム全体の動作例を示すシーケンス図である。図７は送信装置及び受信装置のコンテンツ記憶部における記憶領域の階層構造を示す模式図である。図８はＭｉｒｒｏｒＣｏｎｔｒｏｌファイルの構成を示す模式図である。図９はＣｏｍｍｏｎＣｏｎｆｉｇファイルの構成を示す模式図である。図１０は配信制御テーブルの構成例を示す模式図である。図１１は装置間通信メッセージの構成例を示す模式図である。
【００５１】
この形態では、請求項８の送信装置，受信装置，コンテンツ書庫化手段，転送宛先決定手段，書庫転送手段及び受信状況管理手段は、それぞれ送信装置１０，受信装置２０，書庫化ファイル生成部１１，転送宛先決定部３０，書庫化ファイル送信部１２及び配信制御用ＤＢ（データベース）１４に対応する。
また、請求項９の第１のイベント情報生成手段，第１のイベント情報通知手段，書庫情報展開手段，再転送先決定手段，書庫再転送手段及び第２のイベント情報通知手段は、それぞれステップＳ８６，書庫化ファイル送受信部２２，書庫化ファイル展開部２１，転送宛先決定部３０，書庫化ファイル送受信部２２及びステップＳ９１に対応する。
【００５２】
また、請求項１３のロックファイル作成手段及び受信ログ生成手段は書庫化ファイル送受信部２２に対応する。
この形態では、図１に示すような構成の通信システムを用いて、送信装置１０から複数の受信装置２０に対してコンテンツを配信する場合を想定している。例えば、オリジナルサーバとミラーサーバとの間でコンテンツの転送を行う場合には、送信装置１０がオリジナルサーバに相当し、受信装置２０がミラーサーバに相当する。また、サーバとクライアント端末との間でコンテンツの転送を行う場合には、送信装置１０がサーバに相当し、受信装置２０がクライアント端末に相当する。
【００５３】
図１に示す通信システムにおいては、送信装置１０，転送宛先決定部３０及び複数の受信装置２０がＩＰネットワーク３５を介して互いに接続されている。なお、転送宛先決定部３０については送信装置１０と一体に構成することもできるし、いずれかの受信装置２０に配置することもできる。
送信装置１０は、書庫化ファイル生成部１１，書庫化ファイル送信部１２，コンテンツ記憶部１３及び配信制御用ＤＢ１４を備えている。
【００５４】
コンテンツ記憶部１３には配信すべきコンテンツの情報が保持され、その情報はコンテンツ提供者からの要求などに応じて追加及び更新される。配信制御用ＤＢ１４には、配信制御に必要な様々な情報が保持される。配信制御用ＤＢ１４上の情報は必要に応じて更新される。
コンテンツ記憶部１３については、実際には送信装置１０の本体にＳＣＳＩインタフェースやＡＴＡインタフェースで直接接続してもよいし、外部装置である記憶装置サーバ（ＮＡＳ：Ｎｅｔｗｏｒｋ　Ａｔｔａｃｈｅｄ　Ｓｔｒａｇｅ）をＮＦＳで送信装置１０に接続してもよい。
【００５５】
送信装置１０から受信装置２０へのコンテンツ配信を開始する条件（図２に示す動作を開始する条件）は、前回配信時のコンテンツと比べて新しいファイルがコンテンツ記憶部１３に追加された場合、又はファイルのタイムスタンプやファイルサイズが更新されたことを発見した場合である。
この検査は、送信装置１０上のコンテンツ記憶部１３を走査することによって行われる。
【００５６】
コンテンツ記憶部１３を走査する契機については、送信装置１０上にコンテンツ毎に用意されているＭｉｒｒｏｒＣｏｎｔｒｏｌファイルと呼ばれる定義ファイルの内容に応じて、Ｅｖｅｎｔ型，Ｓｃｈｅｄｕｌｅｄ型，ＯｎＤｅｍａｎｄ型のいずれかに切り替えることができる。
【００５７】
Ｅｖｅｎｔ型の場合には、例えば１分おき、１時間おきなどの一定時間周期で走査を行う。Ｓｃｈｅｄｕｌｅｄ型の場合には、例えば毎日午前８時、毎週月曜〜金曜の午前８時などのように特定の時間に走査を行う。ＯｎＤｅｍａｎｄ型の場合には、コンテンツを追加した任意の時間にコンテンツの配信を行う。
書庫化ファイル生成部１１は、コンテンツ記憶部１３上に新たなコンテンツが追加された場合や、既に登録されているコンテンツのバージョンが更新された場合に、追加又は更新された全てのコンテンツのファイルを一纏めにして書庫として管理する。書庫内に格納される各々のファイルは、圧縮された状態で保持される。また、書庫にはそれに格納されているファイルを管理するための情報が含まれている。
【００５８】
書庫化ファイル送信部１２は、書庫化ファイル生成部１１が生成した書庫の内容、すなわち前回配信時の内容とは異なる追加又は変更されたコンテンツの情報を受信装置２０に対して送信する。この場合の宛先は、転送宛先決定部３０が決定する。
転送宛先決定部３０は、送信装置１０又はいずれかの受信装置２０から問い合わせを受けた場合に、送信装置１０上の配信制御用ＤＢ１４で管理されている情報に基づいて特定の受信装置２０を宛先として決定する。
【００５９】
各受信装置２０に備わった書庫化ファイル送受信部２２は、送信装置１０又は他の受信装置２０から送信されるコンテンツの情報を受信するとともに、受信した情報を他の未受信の受信装置２０に対して再転送する。
また、受信したコンテンツの情報は書庫として纏められ圧縮されているので、その情報を書庫化ファイル展開部２１が展開する。展開した受信情報はコンテンツ記憶部２３に蓄積される。
【００６０】
ところで、コンテンツ記憶部１３及び２３上の記憶領域は、図７に示すような階層構造により、領域毎にディレクトリとして区分されて管理されている。また、この形態ではディレクトリ毎にコンテンツの配信を制御することができる。そのため、ＭｉｒｒｏｒＣｏｎｔｒｏｌファイルはディレクトリ毎にそれぞれ用意される。
図７に示す階層構造においては、ＳｅｒｖｉｃｅＤｉｒｅｃｔｏｒｙＲｏｏｔで示されたディレクトリが最上位の階層の記憶領域を表している。このディレクトリの下の階層にはＳｅｒｖｅｒのディレクトリが作成され、更にその下の階層に、Ｃｏｎｔｅｎｔｓディレクトリと、Ｒｅｓｏｕｒｃｅｓディレクトリと、Ｓｙｓｔｅｍディレクトリとが配置されている。
【００６１】
また、ＴｒｅｅＭａｎａｇｅｒの下の階層にはＲｅｓｏｕｒｃｅｓディレクトリだけが配置されている。
この例では、Ｓｅｒｖｅｒのディレクトリの下の階層に配置されるファイルは、主に送信装置１０自身が参照し、ＴｒｅｅＭａｎａｇｅｒディレクトリ以下の階層に配置されるファイルは、主に転送宛先決定部３０によって参照される。
【００６２】
また、Ｓｅｒｖｅｒのディレクトリの下の階層のＣｏｎｔｅｎｔｓディレクトリの下には、コンテンツ配信単位で独立したディレクトリが配置され、それらのディレクトリの配下に、コンテンツ提供者から送信される実際のコンテンツが配置される。
Ｃｏｎｔｅｎｔｓディレクトリ配下のディレクトリをここではコンテンツ名と呼ぶ。このコンテンツ名に対応したディレクトリが、ＳｅｒｖｉｃｅＤｉｒｅｃｔｏｒｙＲｏｏｔ／Ｓｅｒｖｅｒ／Ｒｅｓｏｕｒｃｅｓの配下にも作られる。これらのディレクトリには、コンテンツ毎の定義ファイルが配置される。
【００６３】
このコンテンツ名毎のディレクトリの各々を、ここではリソースディレクトリと呼ぶ。ＭｉｒｒｏｒＣｏｎｔｒｏｌファイルは、リソースディレクトリに配置される。
各々のＭｉｒｒｏｒＣｏｎｔｒｏｌファイルには、図８に示すような様々なパラメータが含まれている。図８に示すように、インターバルを決定するパラメータＶｅｒｓｉｏｎＣｈｅｃｋＩｎｔｅｒｖａｌ，ＥｖｅｎｔＤｒｉｖｅｎＰｕｓｈＩｎｔｅｒｖａｌ，ＳｃｈｅｄｕｌｅｄＰｕｓｈＩｎｔｅｒｖａｌは、ＭｉｒｒｏｒＣｏｎｔｒｏｌファイルの中で独立に指定することができる。すなわち、コンテンツのバージョンの走査周期と配信の周期とは独立に定めることができる。
【００６４】
また、ＥｖｅｎｔＤｒｉｖｅｎＰｕｓｈＩｎｔｅｒｖａｌによって制御されるイベントドリブン型プッシュ制御とＳｃｈｅｄｕｌｅｄＰｕｓｈＩｎｔｅｒｖａｌによって制御されるスケジュール型プッシュ制御とは同時に動作させることができる。
例えば、イベントドリブン型プッシュ制御により配信処理が行われた後でスケジュール型プッシュ制御により配信処理が行われる場合を想定すると、イベントドリブン型プッシュ制御とスケジュール型プッシュ制御との間でバージョンチェックが実施されるが、この時に新規コンテンツが検出されない場合には、コンテンツの書庫化及びファイルの配信は行われない。
【００６５】
オンデマンド型の配信制御を行う場合には、任意のタイミングでバージョンチェック及びコンテンツの配信処理を起動することができる。
書庫化ファイルの作成は、バージョンチェックが行われた後で、イベントドリブン型プッシュ制御又はスケジュール型プッシュ制御が起動するか、もしくはオンデマンド配信コマンドが呼ばれることによって実施される。
【００６６】
書庫化ファイルの作成時には、ロックファイルＤａｒＬｏｃｋが作成される。このロックファイルＤａｒＬｏｃｋの有無は、制御の中で参照される。例えば、書庫化ファイルの作成に時間がかかり、作成が終了する前に次の書庫化ファイル作成タイミングが到来したような場合には、ロックファイルＤａｒＬｏｃｋが存在するので、次のプロセスの起動を中止する。
【００６７】
これにより、書庫化ファイルの作成プロセスが２重に起動するのを防止できるので、先に起動された書庫化プロセスと、後から起動された書庫化プロセスの両方に格納されるファイルが出てきたり、そのどちらにも格納されないファイルが出てくるのを避けることができる。
書庫化ファイルの作成が無事終了した場合には、ロックファイルＤａｒＬｏｃｋは削除される。この後で、次のイベントドリブン型プッシュ制御又はスケジュール型プッシュ制御が起動されると、書庫化ファイルの作成が可能になる。
【００６８】
書庫化ファイルの作成が終了すると、次は配信宛先となる受信装置２０に対して配信通知を行う。
ところで、ＳｅｒｖｉｃｅＤｉｒｅｃｔｏｒｙＲｏｏｔ／Ｓｅｒｖｅｒ／Ｓｙｓｔｅｍの配下には定義ファイルＣｏｍｍｏｎＣｏｎｆｉｇが存在する。書庫化ファイルの配信は、送信装置１０の性能的な許容負荷を超えない範囲で行う必要がある。そのために、定義ファイルＣｏｍｍｏｎＣｏｎｆｉｇの中には、図９に示すようにパラメータＭａｘＰａｒａｒｅｌＴｒａｎｓｆｅｒを設けてある。
【００６９】
この例では、ＳｅｒｖｉｃｅＤｉｒｅｃｔｏｒｙＲｏｏｔ／Ｓｅｒｖｅｒ／Ｒｅｓｏｕｒｃｅｓの配下とＳｅｒｖｉｃｅＤｉｒｅｃｔｏｒｙＲｏｏｔ／Ｓｅｒｖｅｒ／Ｓｙｓｔｅｍの配下とにそれぞれ定義ファイルが配置される。Ｒｅｓｏｕｒｃｅｓの配下に配置される定義ファイルはコンテンツ毎に独立しており、Ｓｙｓｔｅｍの配下の定義ファイルはシステム全体で共通のパラメータとして利用される。
送信装置１０の配信能力は、コンテンツ毎に決定されるものではなく、送信装置１０全体で決定される。そのため、Ｓｙｓｔｅｍの配下に配置される定義ファイルＣｏｍｍｏｎＣｏｎｆｉｇの中で、最大並行配信数（ＭａｘＰａｒａｒｅｌＴｒａｎｓｆｅｒ）のパラメータを定義してある。
【００７０】
送信装置１０の書庫化ファイル送信部１２は、転送宛先決定部３０を用いて配信先の受信装置２０を決定する。この場合、書庫化ファイル送信部１２はそれ自身の定義ファイルＣｏｍｍｏｎＣｏｎｆｉｇにおけるパラメータ（ＭａｘＰａｒａｒｅｌＴｒａｎｓｆｅｒ）と、現在コンテンツを送信中の受信装置２０の数を配信制御用ＤＢ１４の内容に基づいて計算し、これからコンテンツの送信を行う受信装置２０の数が（ＭａｘＰａｒａｒｅｌＴｒａｎｓｆｅｒ）を超えない数の分だけ、転送宛先決定部３０に対して転送先の受信装置名を要求（問い合わせ）する。
【００７１】
転送宛先決定部３０は、送信装置１０から問い合わせを受けると、送信装置１０上の配信制御用ＤＢ１４の内容を参照して、転送先の受信装置２０を決定する。
配信制御用ＤＢ１４には、図１０に示すような構成の配信制御テーブルが保持されている。この配信制御テーブルは、コンテンツ毎にそれぞれ用意されている。各配信制御テーブルには、それぞれの受信装置２０について、受信装置名，コンテンツバージョン，配信開始日時，配信終了日時及び装置状態の情報が記録されている。
【００７２】
また、送信装置１０から転送宛先決定部３０への問い合わせのメッセージは、図１１に示すように送信装置名と、コンテンツ名と、コンテンツバージョンの情報とを含んでいる。また、この問い合わせに対する転送宛先決定部３０から送信装置１０への返信メッセージには、受信装置名とそのＵＲＬ又はＩＰアドレスとが含まれている。
【００７３】
ところで、転送宛先決定部３０は、配信制御用ＤＢ１４に記述されている多数の受信装置２０を複数グループに区分し、目印を付けて管理している。各々のグループにはｎ個の受信装置２０が割り当てられる。ｎの値については、オペレータが任意に決定すればよい。また、各グループ内のｎ個の受信装置２０は、例えば並び順などによりグループ内の順位を付けて管理されている。
【００７４】
そして、転送宛先決定部３０は送信装置１０からの転送宛先の問い合わせが届くと、まず、各々のグループにおける１番目の順位の受信装置２０を代表受信装置として選択し、その情報を順番に送信装置１０に返す。
もしも１番目の順位の受信装置２０の状態が異常である場合には、２番目の順位の受信装置２０を代表受信装置として選択する。
【００７５】
また、各グループの代表受信装置が全て配信済みになった場合には、転送宛先決定部３０は各グループの最下位の順位の受信装置２０を配信宛先として選択する。
このように、選択する順番を順位の降順と昇順とで切り替えるのは、配信の重複が生じるのをなるべく避けるためである。すなわち、転送宛先決定部３０に対する問い合わせ及びコンテンツの転送をするのは送信装置１０だけでなく、複数の受信装置２０も問い合わせをするので、問い合わせに対する回答の内容及びタイミングによっては同じ受信装置２０に対して重複してコンテンツの配信が行われる可能性がある。
【００７６】
転送宛先決定部３０が転送宛先の受信装置２０を選択する順番を順位の降順と昇順とで切り替えることにより、コンテンツの重複配信が生じる可能性を減らすことができる。
転送宛先決定部３０が送信装置１０から転送宛先の問い合わせを受けた場合の転送宛先決定部３０における動作は以上に説明した通りであり、動作手順の概略を図で示すと図４のようになる。
【００７７】
コンテンツの配信を実行する場合、送信装置１０の書庫化ファイル送信部１２は転送宛先決定部３０に対して問い合わせを行い、書庫化ファイル送信部１２は転送宛先決定部３０からの応答として転送宛先の受信装置名を取得する（図２のＳ３９）。
この後、書庫化ファイル送信部１２は、コンテンツを送信するが、その前に転送宛先決定部３０で決定された特定の受信装置２０に対して、コンテンツの更新通知を送信する（図２のＳ４１）。
【００７８】
このコンテンツの更新通知には、図１１に示すように受信装置２０が取得すべき書庫化ファイル名とコンテンツのバージョンとが含まれている。
受信装置２０は、送信装置１０又は他の受信装置２０からのコンテンツ更新通知を受信すると、図３に示すような処理を実行し、送信装置１０からのコンテンツの受信及び他の受信装置２０へのコンテンツの再転送を行う。
【００７９】
但し、コンテンツの更新通知を受けた受信装置２０が既に該当するバージョンのコンテンツをダウンロードしている最中であるか、もしくは既に取得済みである場合には、コンテンツの更新通知に対する処理をキャンセルする。その場合、受信装置２０は送信装置１０に対して、当該コンテンツをダウンロードしている最中か、取得済みであるかのどちらかの情報を通知する（図３のＳ６５）。
【００８０】
この通知を受信すると、送信装置１０はそれ自身が保持している配信制御用ＤＢ１４上の配信制御テーブルの内容を、受信装置２０からのメッセージに従って書き換える。
受信装置２０は、更新通知として送信装置１０から通知されたコンテンツをまだ取得していなければ、該当するコンテンツの書庫化ファイルを、通知を発した送信装置１０もしくは他の受信装置２０からダウンロードする（図３のＳ５２）。
【００８１】
書庫化ファイルのダウンロードが始まると、送信装置１０は配信制御用ＤＢ１４上の配信制御テーブルにおける該当する受信装置２０の状態を「送信装置より受信中」に書き換える。
また、書庫化ファイルのダウンロードが終了すると、受信装置２０はダウンロードを結果を送信装置１０に通知する。この場合も、送信装置１０は配信制御用ＤＢ１４上の配信制御テーブルにおける該当する受信装置２０の状態を通知に従って書き換える。
【００８２】
但し、通知の内容が「異常終了」であった場合には、再び送信装置１０から受信装置２０にコンテンツの更新通知が送信され、書庫化ファイルのダウンロードがやり直される。
通知の内容が「正常終了」であった場合には、送信装置１０は配信制御用ＤＢ１４上の配信制御テーブルにおける該当する受信装置２０の状態を「正常終了」に書き換える。そして、次の転送宛先となる受信装置２０を転送宛先決定部３０に問い合わせる。
【００８３】
一方、書庫化ファイルを受信した受信装置２０においては、受信した書庫の内容を書庫化ファイル展開部２１が展開するのと並行して、他の受信装置２０に対する書庫化ファイルの再転送のための処理を開始する。すなわち、コンテンツの受信を完了した受信装置２０は送信装置１０の代わりに、未受信の受信装置２０に対するコンテンツの転送を行う。
【００８４】
この場合、書庫化ファイルを既に受信した受信装置２０は、転送宛先決定部３０に対して書庫化ファイルを再転送すべき宛先の他の受信装置２０の名称を問い合わせる（図３のＳ５３）。
受信装置２０から転送先の問い合わせを受けると、転送宛先決定部３０は図５に示すような動作を行う。
【００８５】
すなわち、転送宛先決定部３０は配信制御用ＤＢ１４上の配信制御テーブルを参照し、問い合わせ元の受信装置２０が属するグループ内の受信状況を検査し（Ｓ２１）、未配信の受信装置２０を該当するグループの上位から順に転送先として選択する（Ｓ２３）。
未配信の受信装置２０が存在しない場合には、転送宛先決定部３０は無し（ＮＵＬＬ）を問い合わせ元の受信装置２０に応答する（Ｓ２６）。
【００８６】
受信装置２０は、問い合わせの結果として転送宛先決定部３０から無し（ＮＵＬＬ）を受信した場合には、配信処理を終了する。
なお、転送宛先決定部３０は問い合わせを受けた場合に、未配信でかつ、可能であればネットワーク的に近い距離にある受信装置２０を計算して転送先として選択するのが望ましい。
【００８７】
また、転送宛先決定部３０は、求めるバージョンのコンテンツが未配信の受信装置２０を配信制御用ＤＢ１４から検索した結果、該当する受信装置２０が見つかった場合には、その受信装置２０の名前（ＩＰアドレス又はＵＲＬ）を転送先として返す。
一方、書庫化ファイルを受信した受信装置２０においては、書庫の展開が無事に終了すると、「展開終了」のステータス情報を送信装置１０に対して通知する（図３のＳ６４）。
【００８８】
この通知を受けた送信装置１０は、通知に従って配信制御用ＤＢ１４の状態を書き換える。一方、受信装置２０から他の受信装置２０の名前が返ってきた場合には、返ってきた名前の受信装置２０に対して送信装置１０はコンテンツの更新通知を送信する。
なお、受信装置２０が他の受信装置２０に対して書庫化ファイルを送信する場合にも、最大並行配信数については送信装置１０の場合と同様に、ＳｅｒｖｉｃｅＤｉｒｅｃｔｏｒｙＲｏｏｔ／Ｓｅｒｖｅｒ／Ｓｙｓｔｅｍ／ＣｏｍｍｏｎＣｏｎｆｉｇに記述されているパラメータＭａｘＰａｒａｒｅｌＴｒａｎｓｆｅｒの値に従う。
【００８９】
すなわち、受信装置２０はパラメータＭａｘＰａｒａｒｅｌＴｒａｎｓｆｅｒの値によって許される数だけ、転送宛先決定部３０に対して再転送先となる未配信の受信装置２０を問い合わせ、その結果として転送宛先決定部３０から通知された未配信の受信装置２０に対してコンテンツの更新通知を送信する（Ｓ５５）。
一方、受信装置２０は他の受信装置２０からコンテンツの更新通知を受け取ると、更新通知を送信した受信装置２０から該当する書庫化ファイルをダウンロードする（Ｓ５２）。
【００９０】
但し、他の書庫化ファイルを受信している途中であったり、受信した書庫化ファイルを展開している途中であると、送信装置１０に拒否が通知される（Ｓ６５）。これらの条件に適合するときには、ロックファイルが作成されているので、図３のステップＳ５１ではロックファイルの有無を調べる。
他の受信装置２０からの書庫化ファイルのダウンロードが正常に終了した場合には、受信装置２０は「正常終了」のメッセージを送信側の受信装置２０及び送信装置１０に対して通知する。
【００９１】
受信装置２０からの通知を受けると、送信装置１０は配信制御用ＤＢ１４の状態を書き換える。
受信装置２０においては、他の受信装置２０に対する書庫化ファイルの再転送処理と並行して、書庫の内容の展開が書庫化ファイル展開部２１によって実施される。
【００９２】
展開された書庫には属性ファイルが含まれている。この属性ファイルには、書庫化ファイルのバージョン，書庫化ファイルに含まれていたファイルの名前，サイズ，タイムスタンプなどの情報が書き込まれている。
書庫化ファイル展開部２１は、属性ファイルに書き込まれた情報に基づいて、書庫化ファイルに含まれていたファイルが正しいファイルかどうかを検証する。また、展開したコンテンツのタイムスタンプをオリジナルのコンテンツに合わせる。
【００９３】
また、属性ファイルには、オリジナルのコンテンツに含まれる全てのファイルの名前，サイズ，タイムスタンプなどの情報も記述されているので、それらの情報に基づいて、書庫化ファイル展開部２１は自身が管理しているコンテンツが正しく、オリジナルコンテンツと同一かどうかを検査する。
もしも、欠損したコンテンツや一致しないコンテンツなどがあった場合には、受信装置２０の書庫化ファイル送受信部２２はオリジナルコンテンツを保持する送信装置１０から直接オリジナルコンテンツをダウンロードする。
【００９４】
書庫化ファイル展開部２１は、その受信装置２０が管理しているコンテンツが全て正しくオリジナルコンテンツを把握したものであることを確認すると、属性ファイルに含まれていたバージョン番号を読み出し、ＳｅｒｖｉｃｅＤｉｒｅｃｔｏｒｙＲｏｏｔ／Ｓｅｒｖｅｒ／Ｒｅｓｏｕｒｃｅｓ／＜コンテンツ名＞／配下にあるＶｅｒｓｉｏｎ状態ファイルの内容を更新する。
【００９５】
もしも、書庫化ファイルが正常にダウンロードできなかった場合や、ダウンロードした書庫化ファイルに異常があり正常に展開できなかったような場合、すなわち書庫化ファイルの取得に異常が生じた場合には、受信装置２０は転送宛先決定部３０に対して、ダウンロードした書庫化ファイルと同一のバージョンの書庫化ファイルを保持する別の受信装置２０を問い合わせる。
【００９６】
この場合、問合せを受けた転送宛先決定部３０は、まず問い合わせ元の受信装置２０と同一のグループの中で同じバージョンの書庫化ファイルを保持する受信装置２０を検索する。存在しなければ、同一コンテンツを保持する全ての受信装置２０及び送信装置１０の中から、同じバージョンの書庫化ファイルを持つ受信装置２０又は送信装置１０を検索してその結果を問い合わせ元に返す。
【００９７】
もしも、同じバージョンの書庫化ファイルを持つ受信装置２０及び送信装置１０が存在しなかった場合には、同一グループ内で最も新しいバージョンの書庫化ファイルを保持する受信装置２０が紹介される。
異なるバージョンの書庫化ファイルをダウンロードした受信装置２０においては、オリジナルコンテンツとの間で欠損するコンテンツが生じる可能性がある。この欠損については、書庫化ファイルに付属しているオリジナルサーバ（送信装置１０）のファイルリスト情報に基づいて検出することができる。
【００９８】
欠損を検出した場合、受信装置２０は足りないファイルについて、最新の書庫化ファイルが「展開終了」状態の受信装置２０を転送宛先決定部３０に対して問い合わせ、転送宛先決定部３０から通知された受信装置２０から個別に欠損ファイルをダウンロードする。
このように受信装置２０が処理するので、エラー回復時であっても大元の送信装置１０に対して負荷がかかるのを抑制するので、配信にかかるコストを低減することができる。
【００９９】
すなわち、コンテンツの配信を行う際に、大元の送信装置１０だけでなく、コンテンツを受信した受信装置２０までもが次々に送信装置１０に代わって未配信の他の受信装置２０にコンテンツを配信していくことが最大の特徴である。
図１に示す通信システムにおける基本的な動作例について、図６を参照しながら説明する。
【０１００】
送信装置１０上のコンテンツ記憶部１３に保持されているコンテンツに追加や更新が発生すると、送信装置１０はステップＳ７１で追加及び更新されたコンテンツを一纏めにした書庫、すなわち書庫化ファイルを作成する。
次に、送信装置１０は配信すべきコンテンツの転送先をステップＳ７２で転送宛先決定部３０に問い合わせる。図６の例では、転送宛先決定部３０はステップＳ７３で１つの受信装置２０（Ｒ１）を転送先の情報として含む応答を送信装置１０に返す。
【０１０１】
この応答を受信すると、送信装置１０は指定された受信装置２０（Ｒ１）に対してステップＳ７４でコンテンツ更新通知を送信する。
この通知により、受信装置２０（Ｒ１）は送信装置１０上のコンテンツが更新されたことを把握し、ステップＳ７５で応答メッセージを返信し、更に次のステップＳ７６で、コンテンツダウンロードの要求を送信装置１０に送信する。
【０１０２】
この要求に従って、送信装置１０は更新されたコンテンツを書庫化ファイルとしてステップＳ７７で受信装置２０（Ｒ１）に送信する。
受信装置２０（Ｒ１）は、書庫化ファイルを受信すると、書庫化ファイル展開部２１を用いて受信した書庫化ファイルの展開（書庫解凍）を開始する（Ｓ８０）。また、この動作と並行して受信装置２０（Ｒ１）から他の受信装置２０に対して受信した書庫化ファイルを再転送する。
【０１０３】
再転送を行う場合の宛先を調べるために、受信装置２０（Ｒ１）はステップＳ７８で転送宛先決定部３０に対して転送先を問い合わせる。図６の例では、この問い合わせに対して、該当するコンテンツを未受信の受信装置２０（Ｒ２）を検索し、その結果を含む応答をステップＳ７９で受信装置２０（Ｒ１）に返す。
従って、受信装置２０（Ｒ１）はステップＳ８２で受信装置２０（Ｒ２）に対してコンテンツの更新通知を送信する。
【０１０４】
受信装置２０（Ｒ２）は、この更新通知を受信すると、ステップＳ８３で応答メッセージを受信装置２０（Ｒ１）に返し、更に次のステップＳ８４で受信装置２０（Ｒ１）に対してコンテンツダウンロードの要求を送信する。
この要求に従って、受信装置２０（Ｒ１）はステップＳ８５で既に受信したコンテンツの書庫化ファイルを受信装置２０（Ｒ２）に対して再転送する。
【０１０５】
受信装置２０（Ｒ１）は、送信装置１０から受信した書庫化ファイルの展開が完了すると、ステップＳ８６で送信装置１０に対して配信終了通知を送信し、送信装置１０はステップＳ８７で応答メッセージを受信装置２０（Ｒ１）に返す。この後、受信装置２０（Ｒ１）はステップＳ８８で処理の結果をログファイルに出力する。
【０１０６】
同様に、受信装置２０（Ｒ２）は受信装置２０（Ｒ１）から受信した書庫化ファイルの展開が完了すると、ステップＳ９１で送信装置１０に対して配信終了通知を送信し、送信装置１０はステップＳ９２で応答メッセージを受信装置２０（Ｒ２）に返す。この後、受信装置２０（Ｒ２）はステップＳ９３で処理の結果をログファイルに出力する。
【０１０７】
図６の例では、受信装置２０（Ｒ１）が送信装置１０から受信した書庫化ファイルを受信装置２０（Ｒ２）に対して再転送するので、送信装置１０は受信装置２０（Ｒ２）に対して書庫化ファイルを配信する必要がない。従って、送信装置１０の負荷を軽減できる。
【０１０８】
【発明の効果】
本発明によれば、前回配信時より更新のあったファイルや新規に追加されたファイルのみを検索して書庫化ファイルを生成するので、配信するコンテンツの情報量を必要最低限に抑えることができる。
【０１０９】
また、書庫化ファイル中に属性情報として何回目の配信かを表わす書庫化バージョン、書庫に含まれるファイルの名前、タイムスタンプ、サイズなどの情報を含むことにより、書庫化ファイルを展開する際に、書庫化ファイルの中に正しくファイルが全て含まれているかを確認できる。
【０１１０】
また、書庫化ファイルの中にオリジナルのコンテンツの全てのファイル情報を含めることにより、受信装置内にあるコンテンツが、全て正しくオリジナルコンテンツを反映しているかどうかを確認できる。
また、本発明では、受信装置群を複数のグループに分け、それぞれのグループから代表受信装置を選び出し、まずそれらの受信装置に書庫化ファイルの配信を行い、次に代表受信装置が属する各グループ内の受信装置に書庫化ファイルの配信を行い、またそれと並行して送信装置も各グループにまんべんなくコンテンツ配信を行うことにより、大量の受信装置へのコンテンツの配信を効率よく高速に行うことができる。
【０１１１】
また、転送宛先を選択する際に、代表受信装置への配信の終了した送信装置から転送先の問い合わせがあった場合には各グループの最下位の受信装置のうち未配信のものを指定し、グループ内の受信装置から転送先の問い合わせがあった場合にはグループの上位のうち未配信のものから転送先を指定することにより、転送先となる受信装置の検索を効率的に行うことができる。
【０１１２】
また、本発明では受信装置が書庫化ファイルを受信中もしくは展開中に進捗状況をログファイルに出力することにより、オペレータが受信装置への配信の進捗状況を詳細に把握することが可能になる。
また本発明では、書庫化ファイルの展開終了を送信装置に通知することにより、送信装置では自身が管理する配信データベースで、コンテンツの配信状況を一括管理することができる。
【０１１３】
以上のような特徴により、本発明では大量のコンテンツを大量の受信装置に配信しようとする場合に、データセンタヘの設備投資を最小限に抑え低コストに、かつ高速かつ効率的に行うことができる。
【図面の簡単な説明】
【図１】通信システムの構成例を示すブロック図である。
【図２】送信装置の動作を示すフローチャートである。
【図３】受信装置の動作を示すフローチャートである。
【図４】転送宛先決定部の動作（１）を示すフローチャートである。
【図５】転送宛先決定部の動作（２）を示すフローチャートである。
【図６】通信システム全体の動作例を示すシーケンス図である。
【図７】送信装置及び受信装置のコンテンツ記憶部における記憶領域の階層構造を示す模式図である。
【図８】ＭｉｒｒｏｒＣｏｎｔｒｏｌファイルの構成を示す模式図である。
【図９】ＣｏｍｍｏｎＣｏｎｆｉｇファイルの構成を示す模式図である。
【図１０】配信制御テーブルの構成例を示す模式図である。
【図１１】装置間通信メッセージの構成例を示す模式図である。
【符号の説明】
１０　送信装置
１１　書庫化ファイル生成部
１２　書庫化ファイル送信部
１３　コンテンツ記憶部
１４　配信制御用ＤＢ
２０　受信装置
２１　書庫化ファイル展開部
２２　書庫化ファイル送受信部
２３　コンテンツ記憶部
３０　転送宛先決定部
３５　ＩＰネットワーク

Claims

送信装置と複数の受信装置とが所定の通信網を介して互いに接続された通信システムを用いて、前記送信装置の保持しているコンテンツの情報を各々の受信装置に配信するためのコンテンツ配信方法において、
前記送信装置上で新規に登録されたコンテンツ及び内容の更新されたコンテンツを一纏めにして圧縮し書庫として管理するコンテンツ書庫化手順と、
前記書庫で管理されている情報の転送先の受信装置を決定する転送宛先決定手順と、
前記書庫で管理されている情報を送信装置から決定された特定の受信装置に転送する書庫転送手順と、
各受信装置が前記送信装置の書庫で管理されている情報を受け取った場合に、第１のイベント情報を生成する第１のイベント情報生成手順と、
生成された第１のイベント情報を前記送信装置に通知する第１のイベント情報通知手順と、
各受信装置が前記書庫で管理されている情報を受け取った場合に、受信した書庫の内容を展開して管理する書庫情報展開手順と、
各受信装置が前記書庫で管理されている情報を受け取った場合に、受信した書庫の情報の再転送先となる他の受信装置を決定する再転送先決定手順と、
書庫の情報を受信した第１の受信装置から再転送先の第２の受信装置に対して書庫の情報を転送する書庫再転送手順と、
各受信装置が他の受信装置から書庫の情報を受け取った場合に、第２のイベント情報を転送元の受信装置及び送信装置の少なくとも一方に通知する第２のイベント情報通知手順と
を設けたことを特徴とするコンテンツ配信方法。
請求項１のコンテンツ配信方法において、前記コンテンツ書庫化手順では、
書庫化日時と、コンテンツの更新回数を表すバージョンと、書庫に含まれる元のファイルの情報とを属性情報として書庫の情報に含めて管理する
ことを特徴とするコンテンツ配信方法。
請求項１のコンテンツ配信方法において、前記転送宛先決定手順では、
複数の受信装置を複数のグループに区分して管理するとともに、各グループに含まれる複数の受信装置の各々をグループ内の順位を付けて管理し、
最初はグループ内の最上位の受信装置を転送先として選択し、最上位の受信装置が応答しない場合には降順で次の受信装置を選択し、
最上位の受信装置についてコンテンツが配信済みの場合には、最下位の受信装置から昇順で受信装置を選択する
ことを特徴とするコンテンツ配信方法。
請求項１のコンテンツ配信方法において、前記再転送先決定手順では、
複数の受信装置を複数のグループに区分して管理するとともに、各グループに含まれる複数の受信装置の各々をグループ内の順位を付けて管理し、
第１の受信装置が書庫の情報を受信した場合には、第１の受信装置が属するグループの中で、コンテンツが未配信の受信装置について、順位が上位の受信装置から降順で再転送先の第２の受信装置を選択する
ことを特徴とするコンテンツ配信方法。
請求項１のコンテンツ配信方法において、
各受信装置が前記書庫で管理されている情報を受信している時には、書庫の情報を受信中であることを表すロックファイルを作成するロックファイル作成手順と、
各受信装置が前記書庫で管理されている情報を受信している時には、少なくとも受信中のファイル名称と、受信対象の書庫全体のサイズと、受信の進捗状態を表す進捗情報とを、一定時間おきに受信装置内のログファイルに出力する受信ログ生成手順と
をさらに設けたことを特徴とするコンテンツ配信方法。
請求項５のコンテンツ配信方法において、前記書庫情報展開手順では、各受信装置が受信した書庫の情報を展開処理している時には、展開処理中であることを表すロックファイルを作成するとともに、１ファイルの展開が終了する毎に、展開処理の進捗状態を表す進捗情報を受信装置内のログファイルに出力することを特徴とするコンテンツ配信方法。
請求項１のコンテンツ配信方法において、前記書庫情報展開手順では、受信した書庫内に含まれているファイルの展開に失敗した場合には、該当するファイルと同じ情報を既に保持している他の受信装置の検索を行い、他の受信装置から該当する書庫のファイルをダウンロードすることを特徴とするコンテンツ配信方法。
送信装置と複数の受信装置とが所定の通信網を介して互いに接続された通信システムを用いて、前記送信装置の保持しているコンテンツの情報を各々の受信装置に配信するためのコンテンツ配信制御装置であって、
前記送信装置上で新規に登録されたコンテンツ及び内容の更新されたコンテンツを一纏めにして圧縮し書庫として管理するコンテンツ書庫化手段と、
前記書庫で管理されている情報の転送先の受信装置を決定する転送宛先決定手段と、
前記書庫で管理されている情報を送信装置から決定された特定の受信装置に転送する書庫転送手段と、
各々の受信装置について、書庫の情報を受け取ったか否かを表す情報を管理し、その結果を前記転送宛先決定手段の制御に反映する受信状況管理手段と
を設けたことを特徴とするコンテンツ配信制御装置。
送信装置と複数の受信装置とが所定の通信網を介して互いに接続された通信システムを用いて、前記送信装置の保持しているコンテンツの情報を各々の受信装置に配信するためのコンテンツ配信制御装置であって、
前記送信装置が、新規に登録されたコンテンツ及び内容の更新されたコンテンツを一纏めにして圧縮し書庫として管理するとともに、前記書庫で管理されている情報を特定の受信装置に配信する場合に、
各受信装置が前記送信装置の書庫で管理されている情報を受け取った場合に、第１のイベント情報を生成する第１のイベント情報生成手段と、
生成された第１のイベント情報を前記送信装置に通知する第１のイベント情報通知手段と、
各受信装置が前記書庫で管理されている情報を受け取った場合に、受信した書庫の内容を展開して管理する書庫情報展開手段と、
各受信装置が前記書庫で管理されている情報を受け取った場合に、受信した書庫の情報の再転送先となる他の受信装置を決定する再転送先決定手段と、
書庫の情報を受信した第１の受信装置から再転送先の第２の受信装置に対して書庫の情報を転送する書庫再転送手段と、
各受信装置が他の受信装置から書庫の情報を受け取った場合に、第２のイベント情報を転送元の受信装置及び送信装置の少なくとも一方に通知する第２のイベント情報通知手段と
を設けたことを特徴とするコンテンツ配信制御装置。
請求項８のコンテンツ配信制御装置において、前記コンテンツ書庫化手段は、書庫化日時と、コンテンツの更新回数を表すバージョンと、書庫に含まれる元のファイルの情報とを属性情報として書庫の情報に含めて管理することを特徴とするコンテンツ配信制御装置。
請求項８のコンテンツ配信制御装置において、前記転送宛先決定手段は、
複数の受信装置を複数のグループに区分して管理するとともに、各グループに含まれる複数の受信装置の各々をグループ内の順位を付けて管理し、
最初はグループ内の最上位の受信装置を転送先として選択し、最上位の受信装置が応答しない場合には降順で次の受信装置を選択し、
最上位の受信装置についてコンテンツが配信済みの場合には、最下位の受信装置から昇順で受信装置を選択する
ことを特徴とするコンテンツ配信制御装置。
請求項９のコンテンツ配信制御装置において、前記再転送先決定手段は、
複数の受信装置を複数のグループに区分して管理するとともに、各グループに含まれる複数の受信装置の各々をグループ内の順位を付けて管理し、
第１の受信装置が書庫の情報を受信した場合には、第１の受信装置が属するグループの中で、コンテンツが未配信の受信装置について、順位が上位の受信装置から降順で再転送先の第２の受信装置を選択する
ことを特徴とするコンテンツ配信制御装置。
請求項９のコンテンツ配信制御装置において、
各受信装置が前記書庫で管理されている情報を受信している時には、書庫の情報を受信中であることを表すロックファイルを作成するロックファイル作成手段と、
各受信装置が前記書庫で管理されている情報を受信している時には、少なくとも受信中のファイル名称と、受信対象の書庫全体のサイズと、受信の進捗状態を表す進捗情報とを、一定時間おきに受信装置内のログファイルに出力する受信ログ生成手段と
をさらに設けたことを特徴とするコンテンツ配信制御装置。
請求項１３のコンテンツ配信制御装置において、前記書庫情報展開手段は、各受信装置が受信した書庫の情報を展開処理している時には、展開処理中であることを表すロックファイルを作成するとともに、１ファイルの展開が終了する毎に、展開処理の進捗状態を表す進捗情報を受信装置内のログファイルに出力することを特徴とするコンテンツ配信制御装置。
請求項９のコンテンツ配信制御装置において、前記書庫情報展開手段は、受信した書庫内に含まれているファイルの展開に失敗した場合には、該当するファイルと同じ情報を既に保持している他の受信装置の検索を行い、他の受信装置から該当する書庫のファイルをダウンロードすることを特徴とするコンテンツ配信制御装置。