JP5178947B2 - サーバ、データ配信システム及び情報配信方法 - Google Patents

Description

本発明の実施形態は、映像，音楽，写真等を含む様々な素材をサーバからクライアントに配信するサーバ、データ配信システム及び情報配信方法に関する。

近年、映像，音楽等のデータを蓄積するサーバと、再生機能を持ったクライアント(プレーヤ)とを備えたクライアントサーバシステムとして、サーバ及びクライアントをネットワーク上に配置し、クライアントに対してサーバに蓄積したデータをネットワーク配信するＤＬＮＡ(Digital Living Network Allianceの略)など、主に家庭内などの電気機器の間で、動画、音楽、写真などの素材(以下、データ)をネットワークを介して相互にやり取りできる仕組みが普及してきている。そのような仕組みにより、ファイルが保管されている場所から離れた場所でも、再生ができるようになっている。

例えばＤＬＮＡのガイドラインに従えば、家電機器やコンピュータはメーカーが異なっても、静止画や動画、音楽といったデータをネットワーク上でやり取りできるようになる。そのためのネットワークへの接続は、イーサネット(登録商標)による有線接続、若しくは無線LANによる無線接続のいずれでもよい。

ＤＬＮＡのガイドラインに沿った対象機器として、サーバとしてのＤＭＳ(Digital Media Serverの略)とクライアントとしてのＤＭＰ(Digital Media Playerの略)がある。ＤＭＳはデジタルコンテンツの保存や配信のための機能を備える機器で、パソコンなどのほか、デジタルカメラやビデオカメラ、カメラ付き携帯電話などの録画機能を有する機器である。一方のＤＭＰは、コンテンツを再生する機器のことで、デジタル放送データ等を再生するテレビや音楽プレーヤなどの再生装置である。

ＤＬＮＡでは、クライアントでサーバ一覧を表示させ１つのサーバ名を選ぶと、ファイル一覧が表示され、その中からユーザが所望の１つのファイル名を指定することによって、指定されたファイルデータが再生されることになる。

ところが、ファイルデータの再生中は再生中であることがＤＭＰの画面に表示され、ファイルデータの再生が終了すると、例えば、ＤＭＰの画面はデータ指定時のファイル一覧の表示に戻る。ファイル一覧に戻ってきた後に、ＤＭＳが自身の記憶容量が一杯であるから旧いファイルから消去しなければならないとして先ほどの再生したファイルデータを自動的に消去してしまったとする。ＤＭＰはファイル一覧を取得してしまっているので、ファイルデータが消去されていることは分からず、元のファイル一覧を表示し続ける。そこで、もう一度、同じファイルデータを再生しようとして、ユーザがそのファイルデータをファイル一覧から選択すると、そのファイルデータは既に削除されているから、ＤＭＰはエラーと判定して画面に、エラー表示を出す。そのとき、ユーザは先ほど再生できたのに何故今度は再生できないのかと戸惑うという課題があった。

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

本実施形態は、ファイルの状態が変化した時に、その状態を既存の仕組みを用いてクライアントに知らせることができるサーバ、データ配信システム及び情報配信方法を提供することを目的とする。

実施形態のサーバは、データを蓄積する記憶部に記憶された複数のファイルについての、クライアントからのファイル一覧の取得要求に対して、前記ファイル一覧の情報を配信するサーバであって、前記取得要求を受信すると、受信した取得要求が前記クライアントから前回受信した取得要求に係るファイル一覧と同じファイル一覧に対しての所定時間内の取得要求であるかを判定し、前記受信した取得要求が前記同じファイル一覧に対して前記所定時間内にあった場合に前記受信した取得要求に係るファイル一覧に含まれるファイルの追加、削除及び変更のいずれかの状態の変化があったか否かを判定する状態変化判定部と、前記受信した取得要求が前記所定時間内になかった場合、前記受信した取得要求に係るファイル一覧を作成して前記クライアントへ送信し、前記状態変化判定部において前記ファイルの前記状態の変化があると判定された場合、前記ファイルの前記状態の変化があったこと示す文字列をファイル名に付加して変更したファイル名を含むファイル一覧を、前記取得要求を送信した前記クライアントへ送信する送信部と、を有する。

サーバがクライアントからの要求を受信したときの処理の流れの例を示すフローチャート。 図１のステップＳ24での画面表示例を示す図。 図１のステップＳ26での画面表示例を示す図。 図１のステップＳ30での判定のために、ＤＭＳに記録されるログ内容の例を示す図。 実施形態のデータ配信システムの全体図。 実施形態のデータ配信システムの動作を説明する図。 実施形態のデータ配信システムの動作の一例を説明するフローチャート。

以下、実施の形態について図面を参照して説明する。
以下の実施の形態のデータ配信システムは、ＤＬＮＡによるクライアントサーバシステムとし、クライアントとサーバは相互にローカルエリアネットワーク(以下、単にネットワーク)で接続されており、相互の接続は例えば無線LANによる無線式であるとして説明する。

以下の説明で、幾つかのサーバのうちの少なくとも１つは例えば、録画機能を持ったＤＬＮＡ対応のテレビ受信機であるとし、クライアントは、サーバから取得したデータを再生し画面上に表示可能なＤＬＮＡ対応の再生装置であるとして説明する。

図１乃至図４は実施の形態におけるサーバの動作を説明するフローチャート及びその説明図を示している。また、図５乃至図７は実施の形態のデータ配信システムの全体図及び動作を説明するフローチャートを示している。

先ず、図５を参照してデータ配信システムの概略構成を説明する。
図５は実施の形態のデータ配信システムの全体図である。
図５に示すデータ配信システム１０は、サーバとしてのデータを蓄積する複数(図では３つ)のＤＭＳ1，ＤＭＳ2，ＤＭＳ3と、クライアントとしての再生機能を持った複数(図では３つ)のＤＭＰ1，ＤＭＰ2，ＤＭＰ3とを備えている。各サーバは内部にハードディスク(以下、ＨＤＤ)等の記憶部を備えている。サーバであるＤＭＳ1，ＤＭＳ2，ＤＭＳ3は、例えば、デジタルテレビ放送を受信し録画することが可能なＤＬＮＡ対応のテレビ受信機やデジタルレコーダ等の放送受信装置である。クライアントであるＤＭＰ1，ＤＭＰ2，ＤＭＰ3は表示部を備えたＤＬＮＡ対応の再生装置であり、映像のほか音楽の再生も可能であることが好ましい。

データ配信システム１０は、サーバとクライアント間の相互のネットワーク接続は無線式に限らず、有線式であってもよい。ＤＭＳ1，ＤＭＳ2，ＤＭＳ3はいずれも各々のサーバ名をネットワークに公開し、ネットワークに接続されたＤＭＰ1，ＤＭＰ2，ＤＭＰ3はいずれもＤＭＳ1，ＤＭＳ2，ＤＭＳ3を検出して各々の表示部にＤＭＳ1，ＤＭＳ2，ＤＭＳ3のサーバ一覧(Serverリストとも表記)を表示することにより、クライアント側のユーザはサーバ一覧を参照して所望のサーバを選択することができる。

クライアント側のユーザはサーバ一覧を参照してその中から所望のサーバのサーバ名を選択すると、クライアントからサーバにファイル一覧要求が送信され、クライアントはサーバからファイル一覧(Fileリストとも表記)を取得してファイル一覧を表示することができる。すなわち、サーバは、ファイル一覧送信部を有する。そして、ユーザがファイル一覧から所望のファイルを選択すると、クライアントからサーバにその選択したファイルの再生要求が送信され、サーバからクライアントにそのファイルデータが配信され、クライアントは所望のファイルを再生して表示し、クライアント側のユーザに提供することができる。すなわち、クライアントは、配信されたデータを再生し、かつファイル一覧を表示するための表示部を有する。なお、いずれのＤＭＳ1，ＤＭＳ2，ＤＭＳ3も、それぞれのサーバに蓄積したファイルデータをファイル再生要求のあったいずれかのクライアントに配信することができる。

以上のように、サーバは、データを蓄積する記憶部が接続され、その記憶部に記憶された複数のファイルについての、クライアントからのファイル一覧の取得要求に対して、ファイル一覧の情報を配信し、かつ配信要求のあったファイルデータを配信する。

本実施形態では、３つのＤＭＳ1，ＤＭＳ2，ＤＭＳ3はいずれも、そのサーバ名をネットワークに公開することが可能である。ＤＭＳ1，ＤＭＳ2，ＤＭＳ3のそれぞれのサーバ名を、Server1，Server2，Server3と表記することにする。

図５の実施形態には、３つのサーバ（ＤＭＳ1，ＤＭＳ2，ＤＭＳ3）と、これらとネットワークを介して接続される３つのクライアント（ＤＭＰ1，ＤＭＰ2，ＤＭＰ3）とを図示しているが、以降の説明では、主として、ＤＭＰ1に表示されている３つのサーバ名Server1，Server2，Server3の中から、ＤＭＰ１のユーザが例えばＤＭＳ1のサーバ名Server1を選択した場合を例として説明する。従って、ＤＭＳ1とＤＭＰ1とを実線で示してある。

次に、図１のフローチャートを参照してサーバの動作を説明する。図１は、サーバがクライアントからの要求を受信したときの処理の流れの例を示すフローチャートである。
このフローチャートは、クライアント側がファイル一覧を取得し、その後に、その中の一部のファイルがサーバ側で削除されて消去されたときに、サーバがクライアント側からそのサーバ上で削除されたファイルの再生要求を受けた場合にどのように処理するかということと、もう一度ファイル一覧の要求がきた場合にどうするかということの処理を含むものである。

図１の処理は、ＤＭＳ１がＤＭＰ１側からの要求を受信したときからスタートする。
まず、ＤＭＳ１は、受信した要求がファイルの再生要求であるか否かの判定を行う(ステップＳ21)。ファイルの再生要求であれば、ＤＭＳ１の記憶部にアクセスし(ステップＳ22)、要求されたファイルの有無を判定する(ステップＳ23)。要求されたファイルが無ければ、一覧から削除されているので、ＤＭＳ１は、予め用意された映像をＤＭＰ１へ出力する(ステップＳ24)。このときＤＭＰ１の表示部の画面ＤＳには、例えば図２に示すように「削除されています」の映像文字が表示される。
このステップＳ23及びＳ24は、ファイルの削除がされているときは、削除されていることを示す画像を出力する画像出力部を構成する。

ステップＳ23で、要求されたファイルが有れば、ＤＭＳ１は、そのＤＭＰ１へのそのファイルの送信後（すなわち再生後に）要求したファイルの内容に変更があったか否を判定する(ステップＳ25)。この判定は、ＤＭＳ１のファイルの送信履歴情報と、ファイル管理システムの情報のそれぞれの時刻情報に基づいて行うことができる。

ステップＳ25で、要求されたファイルに変更があった場合は、ＤＭＳ１は、変更されている旨の映像をＤＭＰ１へ出力する(ステップＳ26)。このときＤＭＰ１の表示部の画面ＤＳには、例えば図３に示すように「変更されています ６/８： 10：05変更」の映像文字が再生表示される。図３に示すように、ファイルの変更時刻が表示されるので、ユーザは、いつ変更されたかを認識することができる。ステップＳ26の後、処理は、ステップＳ27へ移行する。

このステップＳ25及びＳ26は、ファイルについてのデータ配信要求があったときに、ファイルの変更がされているときは、変更されていることを示す画像を出力する画像出力部を構成する。

ステップＳ25で、要求されたファイルに変更がなければ、そのファイルの再生処理を行う（ステップＳ27）。

一方、ステップＳ21において、受信した要求がファイルの再生要求でなければ、ＤＭＳ１は、ステップＳ28で、受信した要求がクライアント側からのファイル一覧の要求であるか否かを判定する。ステップＳ28で、受信した要求がファイル一覧の要求でなければ、ＤＭＳ１は、対応する処理(例えばクライアント側からの要求に対応した各種処理を実行する(ステップＳ29)。ステップＳ28で、受信した要求がファイル一覧の要求であるとき、ＤＭＳ１は、同じクライアントからの前回と同じファイル一覧に対しての所定時間(例えば１０分)内のアクセスであるか否かを判定する(ステップＳ30)。なお、ＤＭＳ１の記憶部には、例えば図４に示すように、所定時間内のクライアント側からの要求のあった各ＤＭＰに関する記録(ログ)が記憶されている。すなわち、各ＤＭＳは、以前に自己のサーバにどのＤＭＰからどのファイル一覧に対してアクセスがあったかを各々の記憶部に記憶する機能を備えている。アクセスの有無をＤＭＰごとに記録するために、例えばＤＭＰのＩＰアドレスなどのＤＭＰ固有の番号が記憶される。ここでは、例えば、何れかのＤＭＰでサーバ名Server1，Server2，Server3の何れかを選択したときに、選択されたサーバ名Server1，Server2，Server3それぞれに対応してFileリストＡ，Ｂ，Ｃが各ＤＭＳに一覧要求されるものとしている。

具体的には、図４に示すように、例えば１０分間以内にファイル一覧要求のあったＤＭＰ(ＤＭＰ1，ＤＭＰ2，ＤＭＰ3)ごとの時刻やファイル一覧名についての記録(ログ)を行っている。図４は、同じファイル一覧Ａ(＝FileリストA)に対してＤＭＰ1から時刻１０：００と時刻１０：１０の１０分間以内に二度のアクセス(要求)があった場合を示している。後述するように、ＤＭＳ１は、そのような場合に、ファイルの状態の変化(追加，削除，変更)に応じて生成されたファイル名を生成してＤＭＰへ出力する。よって、ＤＭＰでは、ファイル一覧にそのファイルの状態の変化が反映され、ＤＭＰの表示部に表示される。

図１に戻って、ステップＳ30で、ファイル一覧の要求が、前回と同じファイル一覧に対しての所定時間(例えば１０分)内のファイル一覧要求であった場合は、ＤＭＳ１は、そのファイル一覧内のファイルに変化があったか否かの判定を行う(ステップＳ31)。ステップＳ30で、ファイル一覧の要求が、前回と同じファイル一覧に対して所定時間(例えば１０分)内のファイル一覧要求でなかった場合は、処理は、ステップＳ36へ移行し、ＤＭＳ１は、その要求に係るファイル一覧を作成してＤＭＰ１へ送信する。

ステップＳ31で、その要求に係るファイル一覧内のファイルに変化があった場合は、処理は、ステップＳ32に移行する。ステップＳ31で、そのファイル一覧内のファイルに変化がなかった場合は、ＤＭＳ１は、そのときのファイル一覧内のファイル名のままでファイル一覧を作成してＤＭＰ１へ送信する(ステップＳ36)。

ステップＳ30及び31は、クライアントからのファイル一覧の取得要求を受信すると、ファイル一覧に含まれるファイルの状態の変化の有無を判定する状態変化判定部を構成する。

ステップＳ32では、ＤＭＳ１は、その要求に係るファイル一覧内のファイルの状態の変化の内容を判定し、その判定結果は、３つの場合に分けられる。その３つの変化の内容は、ファイルの追加，削除，変更である。
ステップＳ32でファイルの状態の変化がファイルの追加であった場合は、ＤＭＳ１は、ファイルの追加を示す代替ファイル名(例えば、削除されたファイル名に-Addedを付ける)を生成する(ステップＳ33)。また、ステップＳ32でファイルの状態の変化がファイルの削除であった場合は、ＤＭＳ１は、ファイルの削除を示す代替ファイル名(例えば、削除されたファイル名に-Deletedを付ける)を生成する(ステップＳ34)。ステップＳ32でファイルの状態の変化がファイルの変更であった場合は、ＤＭＳ１は、ファイルの変更を示す代替ファイル名(例えば、変更されたファイル名に-Modifiedを付ける)を生成する。以上のように、ここでは、状態の変化を示す文字列を、ファイル名に付加することによって、ファイル名の変更が行われる。

そして、ＤＭＳ１は、ステップＳ33から35の後、そのときの要求に係るファイル一覧内のファイル名中、ステップＳ33から35において生成された代替ファイル名が生成されたファイル名については、ファイル名を代替ファイル名で置き換えてファイル一覧を作成して送信する(ステップＳ36)。

以上のように、ステップＳ33から36は、ファイルの状態の変化が有りとされたファイルのファイル名の変更を行ったファイル一覧を、ファイル一覧の取得要求を送信したクライアントへ送信するファイル一覧送信部を構成する。特に、ステップＳ33から36では、ファイル一覧に含まれるファイルが、クライアントが所定時間内に送信要求したファイルを含む場合に、ファイル名の変更が行われる。

図６は本実施形態のデータ配信システムの動作を説明する図である。
図６はＤＭＰ1の表示部の画面ＤＳに表示されるサーバ一覧(Serverリスト)ａから、ユーザがサーバ名Server1を選択した場合に、ＤＭＰ1からＤＭＳ1に対してファイル一覧要求が出されてＤＭＰ1の画面ＤＳに、符号ｂで示すファイル一覧(Fileリスト)Ａが表示されることを示している。これらの状態はＤＭＰ1の表示部の画面ＤＳに、符号ａ，ｂで示すように表示される。このようにサーバ名Server1の選択に対して、４つのFile1，2，3，4を含むFileリストＡが表示され、ユーザがこのFileリストＡからさらにFile1(例えば音楽データ)を選択すると、そのFile1のデータがＤＭＳ１からクライアントＤＭＰ1へ送信され、音楽がＤＭＰ1の再生回路(図示せず)によって再生され、スピーカ又はイヤホン(図示せず)から音声出力される。これらの状態は符号ｂ，ｆによって示されている。File1の音楽再生中は楽曲に応じた音符印などの画面ｆが表示され、File1の音楽が終了すると、ＤＭＰ1の画面ＤＳは音楽選択時のファイル一覧(Fileリスト)Ａの表示に戻る。戻ってきた後に、ＤＭＳ1が自身の記憶容量が一杯になったため旧いファイルから消去しなければならないとして例えばFile1を消去したとする。ＤＭＰ1は図示のファイル一覧を取得してしまっているので、File1が消去されていることは分からず、元のファイル一覧Ａ(符号ｂの画面)を表示し続ける。そこで、もう一度、File1の音楽を聴こうとして、ユーザがFile1を選択すると、File1は既に削除されているから、ＤＭＰ1はエラーと判定してその画面に、エラー表示(Error)を出す。この状態は符号ｃの画面に示されている。

このように、ファイルデータが削除されたことがわからないために、従来は、ファイル一覧が表示されているにも関わらず何故再生できないのかとユーザが戸惑うようなことが起きるという課題があった。

このような問題に対して、本実施の形態では、ファイルの状態の変化(例えばファイルデータの追加、削除、変更)に対して、代替ファイル名を作成してファイルの名前を変えることによってファイルの状態(データが追加、削除、変更された状態)にあることをユーザに伝えるようにする。なお、ファイルの状態に応じてファイル名を変更する際には、上述したように、そのファイルの状態を表現する文字列を元のファイル名に含めた代替名を生成することが好ましい。例えば、元のファイル名File1に対して、例えば代替名File1_Deletedを生成する。つまり、その代替名をファイル一覧の元のファイル名の代わりに書き換えたりまたは置き換えたりすることによって、ユーザにFile1が例えば削除されたことを伝える。

次に、図７を参照して本実施形態のクライアントサーバシステムの全体の動作を説明する。
サーバであるＤＭＳ1，ＤＭＳ2，ＤＭＳ3及びクライアントであるＤＭＰ1，ＤＭＰ2，ＤＭＰ3がネットワークに接続されてサーバクライアントシステムの各機器が動作可能になっている状態では、ＤＭＰ1，ＤＭＰ2，ＤＭＰ3のそれぞれは、表示部に、ネットワークに公開されている複数のＤＭＳ1，ＤＭＳ2，ＤＭＳ3のサーバ名Server1，Server2，Server3がサーバ一覧(Serverリスト)として表示することができる。ＤＭＰ1，ＤＭＰ2，ＤＭＰ3の各々からは、各ユーザの要望によりサーバ名Server1，Server2，Server3の中からいずれかのサーバ名を選択することによって所望のサーバに対してファイル一覧要求を出し、各クライアントは、ファイル一覧を表示部に表示することができる。そして、ユーザは、その結果得られたファイル一覧の中から所望のファイル(動画、音楽、写真等の素材であるデータ)を選択することによってそのサーバに対してファイルの再生要求を送信してサーバにファイルデータを配信させることができる。ＤＭＰ1，ＤＭＰ2，ＤＭＰ3の各々では、選択したサーバから所望のファイルデータを受信して再生し表示が行われることになる。

図７は本実施の形態のデータ配信システムの全体動作の一例を説明するフローチャートである。図７は、ファイルが削除されている場合と削除されていない場合における、同じクライアントからのファイル選択があった場合の動作を示す。図７のフローチャートを、図６を参照しながら説明する。
図６の符号ａに示すように、まず、ＤＭＰ1は、ＤＭＰ1の表示部に、ネットワークに公開されている複数のＤＭＳ1，ＤＭＳ2，ＤＭＳ3のサーバ一覧(Serverリスト)を表示する(ステップＳ1)。

次に、ＤＭＰ1のユーザは、ＤＭＰ1に表示されたサーバ一覧から例えばサーバ名Server1を選択する(ステップＳ2)。これによって、ＤＭＰ1からＤＭＳ1に対してファイル一覧要求が出されたことになる。
その結果、図６の符号ｂに示すように、ＤＭＰ1の表示部には、選択したＤＭＳ1内のファイル一覧(Fileリスト)Ａが表示される(ステップＳ3)。
ここで、ＤＭＳ1で、File1の削除が自動的又は人為的に発生したとする(ステップＳ4)。

その後にＤＭＰ1のユーザは、ＤＭＰ1に表示されたファイル一覧から例えばそのFile1
を選択する(ステップＳ5)。これによって、ＤＭＰ1からＤＭＳ1に対してファイル再生要
求が出されたことになる。

そして、ＤＭＳ1は、ステップＳ5で選択されたファイルFile1が既に削除されていたか否かの判定をする(ステップＳ6)。
ステップＳ6で、図６の符号ｃに示すように、選択されたファイルFile1の削除が既に行われていれば、エラー(Error)を表示する(ステップＳ7)。

そして、ＤＭＳ1は、その後に、ＤＭＰ１から所定時間内のファイル一覧要求があったときは、図１で示した処理を実行して、図６の符号ｄで示す画面に示すように、削除されたファイルFile1のファイル名をそれに関連したファイル名File1_Deletedに変更して新たなファイル一覧Ａを生成してＤＭＰ1に送信し、ＤＭＰ1がこれを表示する(ステップＳ8)。すなわち、ステップＳ７のエラー表示後、ＤＭＰ1からＤＭＳ1に対してファイル一覧要求が所定時間内に出されたとき、ＤＭＳ1で生成された変更されたファイル名を含むファイル一覧をＤＭＰ1が取得して表示することになる。

また、ＤＭＰ１からの所定時間内のファイル一覧要求でないときは、図１で示した処理
を実行して、図６の符号ｅで示す画面に示すように、削除されたファイルを含まないファ
イル一覧Ａを生成してＤＭＰ1に送信する。

ステップＳ6で、選択されたファイルFile1の削除が行われていなければ、ＤＭＳ1は選択されたFile1を再生して送信し(ステップＳ9)、再生が終了すると、ＤＭＳ1は、図６の符号ｆ，ｂに示すように、ファイル一覧を元のファイル一覧に戻す(ステップＳ10)。

以上のように、サーバは、選択したファイルが状態変化したファイルであった場合にはそのファイルの状態変化に応じてファイルの名前を変更することで、ファイルの状態変化を知らせることが可能となる。このように、サーバはファイルの状態変化に応じてファイルの名前を変更して公開しファイル一覧として生成し、クライアントはこれを取得して表示することができる。これにより、サーバの状態が変化した時に、その状態を既存の仕組み(例えばＤＬＮＡのガイドラインに基づく仕組み内)でクライアントに知らせることができる。

以上のように、上述したサーバは、ファイルの状態が変化した時に、その状態を既存の仕組み(例えばここではＤＬＮＡのガイドラインに基づく仕組み内)でクライアントに知らせることができる。

なお、上記の例は、ＤＮＬＡの例としてＤＭＳとＤＭＰで説明したが、ＤＭＣ(Digital Media Controllerの略)とＤＭＲ(Digital Media Rendererの略)を用いた構成であってもよい。また、本実施形態は、ＤＬＮＡに限らず、ＤＬＮＡとは別に決めたルールに従ったサーバとクライアント間での配信システムにも適用できるものである。

なお、本実施形態における代替名のネットワークへの公開については、サーバの状態の変化から一定回数アクセスされるまでのみ代替名を公開するようにしてもよい。

上述した実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれると同様に、特許請求の範囲に記載された発明とその均等の範囲に含まれるものである。

１０…データ配信システム、ＤＭＳ1，ＤＭＳ2，ＤＭＳ3…サーバ、ＤＭＰ1，ＤＭＰ2，ＤＭＰ3…クライアント。

Claims (9)

1. データを蓄積する記憶部に記憶された複数のファイルについての、クライアントからのファイル一覧の取得要求に対して、前記ファイル一覧の情報を配信するサーバであって、
   前記取得要求を受信すると、受信した取得要求が前記クライアントから前回受信した取得要求に係るファイル一覧と同じファイル一覧に対しての所定時間内の取得要求であるかを判定し、前記受信した取得要求が前記同じファイル一覧に対して前記所定時間内にあった場合に前記受信した取得要求に係るファイル一覧に含まれるファイルの追加、削除及び変更のいずれかの状態の変化があったか否かを判定する状態変化判定部と、
   前記受信した取得要求が前記所定時間内になかった場合、前記受信した取得要求に係るファイル一覧を作成して前記クライアントへ送信し、前記状態変化判定部において前記ファイルの前記状態の変化があると判定された場合、前記ファイルの前記状態の変化があったこと示す文字列をファイル名に付加して変更したファイル名を含むファイル一覧を、前記取得要求を送信した前記クライアントへ送信する送信部と、
   を有することを特徴とするサーバ。
2. さらに、ファイルについてのデータ配信要求があったときに、前記データ配信要求に係るファイルが削除されているときは、削除されていることを示す画像を送信する第１の画像送信部を有することを特徴とする請求項１に記載のサーバ。
3. さらに、ファイルについてのデータ配信要求があったときに、前記データ配信要求に係るファイルの変更がされているときは、変更されていることを示す画像を送信する第２の画像送信部を有することを特徴とする請求項１に記載のサーバ。
4. 前記サーバは、放送受信装置であることを特徴とする請求項１から３のいずれか１つに記載のサーバ。
5. クライアント毎の前記取得要求を記録する記憶部を有し、
   前記状態変化判定部は、前記記憶部に記録された前記クライアント毎の前記取得要求を参照して、前記受信した取得要求が前記クライアントから前記前回受信した取得要求に係るファイル一覧と前記同じファイル一覧に対する取得要求であることを判定することを特徴とする請求項１から４のいずれか１つに記載のサーバ。
6. データを蓄積するサーバと、このサーバとネットワークを介して接続され、該サーバから配信されたデータを再生するクライアントとを備えたデータ配信システムであって、
   前記サーバは、
   前記データを蓄積する記憶部に記憶された複数のファイルについての、前記クライアントからのファイル一覧の取得要求に対して、前記ファイル一覧の情報を配信するサーバであって、
   前記クライアントからの前記取得要求を受信すると、受信した取得要求が前記クライアントから前回受信した取得要求に係るファイル一覧と同じファイル一覧に対しての所定時間内の取得要求であるかを判定し、前記受信した取得要求が前記同じファイル一覧に対して前記所定時間内にあった場合に前記受信した取得要求に係るファイル一覧に含まれるファイルの追加、削除及び変更のいずれかの状態の変化があったか否かを判定する状態変化判定部と、
   前記受信した取得要求が前記所定時間内になかった場合、前記受信した取得要求に係るファイル一覧を作成して前記クライアントへ送信し、前記状態変化判定部において前記ファイルの前記状態の変化があると判定された場合、前記ファイルの前記状態の変化があったこと示す文字列をファイル名に付加して変更したファイル名を含むファイル一覧を、前記取得要求を送信した前記クライアントへ送信する送信部と、
   を有し、
   前記クライアントは、
   配信された前記データを再生し、かつ前記ファイル一覧を表示するための表示部を有することを特徴とするデータ配信システム。
7. 前記サーバは、クライアント毎の前記取得要求を記録する記憶部を有し、
   前記状態変化判定部は、前記記憶部に記録された前記クライアント毎の前記取得要求を参照して、前記受信した取得要求が前記クライアントから前記前回受信した取得要求に係るファイル一覧と前記同じファイル一覧に対する取得要求であることを判定することを特徴とする請求項６に記載のデータ配信システム。
8. 前記クライアントは、前記表示部に表示された前記ファイル一覧の中から所望のファイルを選択することによって、前記サーバへ前記データの配信要求を送信することを特徴とする請求項６又は７に記載のデータ配信システム。
9. データを蓄積する記憶部に記憶された複数のファイルについての、クライアントからのファイル一覧の取得要求に対して、サーバから前記ファイル一覧の情報を配信する方法であって、
   前記サーバは、
   前記取得要求を受信すると、受信した取得要求が前記クライアントから前回受信した取得要求に係るファイル一覧と同じファイル一覧に対しての所定時間内の取得要求であるかを判定し、
   前記取得要求が前記所定時間内になかった場合、前記受信した取得要求に係るファイル一覧を作成して前記クライアントへ送信し、
   前記取得要求が前記所定時間内にあった場合、前記受信した取得要求に係るファイル一覧に含まれるファイルの追加、削除及び変更のいずれかの状態の変化があったか否かを判定し、
   前記ファイルの前記状態の変化があると判定された場合、前記ファイルの前記状態の変化があったこと示す文字列をファイル名に付加して変更したファイル名を含むファイル一覧を前記クライアントへ送信する、
   ことを特徴とするファイル一覧情報配信方法。

Images