JP5039226B1 - サーバ及びデータ配信システム - Google Patents

サーバ及びデータ配信システム Download PDF

Info

Publication number
JP5039226B1
JP5039226B1 JP2011164605A JP2011164605A JP5039226B1 JP 5039226 B1 JP5039226 B1 JP 5039226B1 JP 2011164605 A JP2011164605 A JP 2011164605A JP 2011164605 A JP2011164605 A JP 2011164605A JP 5039226 B1 JP5039226 B1 JP 5039226B1
Authority
JP
Japan
Prior art keywords
server
name
network
server name
data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2011164605A
Other languages
English (en)
Other versions
JP2013013040A (ja
Inventor
英輔 三由
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Toshiba Corp
Original Assignee
Toshiba Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Toshiba Corp filed Critical Toshiba Corp
Priority to JP2011164605A priority Critical patent/JP5039226B1/ja
Priority to EP20120153615 priority patent/EP2530943B1/en
Application granted granted Critical
Publication of JP5039226B1 publication Critical patent/JP5039226B1/ja
Publication of JP2013013040A publication Critical patent/JP2013013040A/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/24—Monitoring of processes or resources, e.g. monitoring of server load, available bandwidth, upstream requests
    • H04N21/2408—Monitoring of the upstream path of the transmission network, e.g. client requests
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/06—Protocols specially adapted for file transfer, e.g. file transfer protocol [FTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/21—Server components or server architectures
    • H04N21/226—Characteristics of the server or Internal components of the server
    • H04N21/2265—Server identification by a unique number or address, e.g. serial number
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/231—Content storage operation, e.g. caching movies for short term storage, replicating data over plural servers, prioritizing data for deletion
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/24—Monitoring of processes or resources, e.g. monitoring of server load, available bandwidth, upstream requests
    • H04N21/2405—Monitoring of the internal components or processes of the server, e.g. server load
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/436—Interfacing a local distribution network, e.g. communicating with another STB or one or more peripheral devices inside the home
    • H04N21/43615—Interfacing a Home Network, e.g. for connecting the client to a plurality of peripherals

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Information Transfer Between Computers (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

【課題】サーバの状態が変化した時に、その状態を既存の仕組みでクライアントに知らせることができるサーバ及びデータ配信システムを提供することである。
【解決手段】ファイルデータを蓄積する記憶部を備え、クライアントにネットワークを介して接続し、当該サーバの名前を前記ネットワークに公開するサーバであって、該サーバの状態に応じて前記ネットワークに公開する前記サーバの名前を変更したり、或いは名前を変更したものを加える。
【選択図】図１

Description

本発明の実施形態は、映像，音楽，写真等を含む様々な素材をサーバからクライアントに配信するサーバ及びデータ配信システムに関する。
近年、映像，音楽等のデータを蓄積するサーバと、再生機能を持ったクライアント(プレーヤ)とを備えたクライアントサーバシステムとして、サーバ及びクライアントをネットワーク上に配置し、クライアントに対してサーバに蓄積したデータをネットワーク配信するＤＬＮＡ(Digital Living Network Allianceの略)など、主に家庭内などの電気機器の間で、動画、音楽、写真などの素材(以下、データ)をネットワークを介して相互にやり取りできる仕組みが普及してきている。そのような仕組みにより、ファイルが保管されている場所から離れた場所でも、再生ができるようになっている。
例えばＤＬＮＡのガイドラインに従えば、家電機器やコンピュータはメーカーが異なっても、静止画や動画、音楽といったデータをネットワーク上でやり取りできるようになる。そのためのネットワークへの接続は、イーサネット(登録商標)による有線接続、若しくは無線LANによる無線接続のいずれでもよい。
ＤＬＮＡのガイドラインに沿った対象機器として、サーバとしてのＤＭＳ(Digital Media Serverの略)とクライアントとしてのＤＭＰ(Digital Media Playerの略)がある。ＤＭＳはデジタルコンテンツの保存や配信のための機能を備える機器で、パソコンなどのほか、デジタルカメラやビデオカメラ、カメラ付き携帯電話などの録画機能を有する機器である。一方のＤＭＰは、コンテンツを再生する機器のことで、デジタル放送データ等を再生するテレビや音楽プレーヤなどの再生装置である。
ところが、クライアントがサーバ上の素材(データ)を再生している最中に、サーバ側でデータの配信よりも優先順位の高い処理(例えば録画)が開始されることにより、サーバ側がクライアントからの新たなアクセスに対してデータの配信を中止する場合、クライアント側は離れた場所のサーバで起きていることが分からないために、データが配信されず操作に戸惑うという課題があった。
特開２００７−７４３５６号公報 特開２０１０−１９１７３６号公報 特開２００７−１９４９７４号公報
実施の形態は、サーバの状態が変化した時に、その状態を既存の仕組みを用いてクライアントに知らせることができるサーバ及びデータ配信システムを提供することを目的とする。
実施の形態のサーバは、記憶部に記憶された複数のファイルデータを、クライアントにネットワークを介して配信可能で、かつ自己のサーバ名を前記ネットワークに公開可能なサーバであって、前記ネットワークを介しての前記クライアントからのファイルデータの配信要求に応じて、前記ファイルデータの配信を行うデータ配信部と、前記ネットワークに前記自己のサーバ名を公開し、かつ前記ネットワークを介しての前記データ配信部からの前記ファイルデータの配信数が同時配信可能数に達すると前記自己のサーバ名とは異なるサーバ名を公開すると共に、前記ファイルデータの前記配信数が、前記同時配信可能数に達した後に、前記同時配信可能数を下回ったときは、前記異なるサーバ名を前記自己のサーバ名に変更するサーバ名公開部と、を有する。
第１の実施の形態におけるサーバの動作を説明するフローチャートである。 第１の実施の形態のデータ配信システムの図である。 第１の実施の形態のデータ配信システムの動作の一例を説明するフローチャートである。 図２及び図３で説明した動作の要部を説明する説明図である。 第２の実施の形態におけるサーバの動作を説明するフローチャートである。 第２の実施の形態のデータ配信システムの図である。 第２の実施の形態のデータ配信システムの動作の一例を説明するフローチャートである。 図６及び図７で説明した動作の要部を説明する説明図である。
以下、実施の形態について図面を参照して説明する。
以下の実施の形態のデータ配信システムは、ＤＬＮＡによるクライアントサーバシステムとし、クライアントとサーバは相互にローカルエリアネットワーク(以下、単にネットワーク)で接続されており、相互の接続は例えば無線LANによる無線式であるとして説明する。各サーバは、記憶部に記憶された複数のファイルデータ（以下、単にデータという）を、クライアントにネットワークを介して配信可能で、かつ自己のサーバ名をネットワークに公開可能なサーバである。
以下の説明で、幾つかのサーバのうちの少なくとも１つは例えば、録画機能を持ったＤＬＮＡ対応のテレビ受信機であるとし、クライアントは、サーバから取得したデータを再生し画面上に表示可能な再生装置であるとして説明する。
［第１の実施の形態］
図１は第１の実施の形態におけるサーバの動作を説明するフローチャートを示している。また、図２は本第１の実施の形態のデータ配信システムの図である。本実施の形態は、サーバとクライアント間の通信(配信)を中断することなくサーバ名を変更することが可能なサーバを備えたクライアントサーバシステムである。
先ず、図２を参照してデータ配信システムの概略構成を説明する。
図２に示すデータ配信システム１０は、データを蓄積する複数(図では３つ)のサーバとしてのＤＭＳ1，ＤＭＳ2，ＤＭＳ3と、再生機能を持った複数(図では３つ)のクライアントとしてのＤＭＰ1，ＤＭＰ2，ＤＭＰ3とを備えている。各サーバは内部にハードディスク(以下、ＨＤＤ)等の記憶部を備えている。ＨＤＤ等の記憶部はサーバの外部に接続されていてもよい。サーバであるＤＭＳ1は、本第１の実施の形態に係わるサーバであり、例えば、デジタルテレビ放送を受信し録画することが可能で且つ通信の中断なしにサーバ名を変更することが可能なＤＬＮＡ対応のテレビ受信機等の放送受信装置である。ＤＭＳ2，ＤＭＳ3については、従来と同様の機能をもったサーバであり、例えば、デジタルテレビ放送が受信可能で録画機能を持ったＤＬＮＡ対応のデジタルレコーダ等の放送受信装置である。本第１の実施の形態では、ＤＭＳ1のみが通信の中断なしにサーバ名を変更可能なサーバである。
データ配信システム１０は、サーバとクライアント間の相互のネットワーク接続は有線式または無線式のいずれであってもよい。ＤＭＳ1，ＤＭＳ2，ＤＭＳ3はいずれも各々のサーバ名をネットワーク上に公開するためのサーバ名公開部を有し、ネットワークに接続されたＤＭＰ1，ＤＭＰ2，ＤＭＰ3はいずれもＤＭＳ1，ＤＭＳ2，ＤＭＳ3を検出して各々の表示部にＤＭＳ1，ＤＭＳ2，ＤＭＳ3の一覧(Serverリストとも表記)を表示することにより、クライアント側のユーザはサーバ一覧を参照して所望のサーバを指定することができる。なお、いずれのサーバも、それぞれに蓄積したデータをＤＭＰ1，ＤＭＰ2，ＤＭＰ3のうちの要求のあったクライアントに配信することができる。図２で、ＤＭＰ1，ＤＭＰ2，ＤＭＰ3からＤＭＳ1への実線矢印は、各クライアントからサーバへのアクセスを意味している。
本実施の形態では、３つのサーバのうちのＤＭＳ1は、そのサーバの状態(配信中か、録画中かなどの状態によっての変化するサーバの状態)に応じてネットワークに公開するサーバ名を変更することが可能である。ここで、サーバの状態とは、単に配信中か録画中かのほかに、配信数の多少や、録画中の録画数などの主に負荷の状態をいう。配信数の多少は、例えば、閾値である同時配信可能数の最大数ｍを超えたか否かに相当する。ＤＭＳ1，ＤＭＳ2，ＤＭＳ3のサーバ名をそれぞれ、Server1，Server2，Server3と表記することにする。
このＤＭＳ1は、ネットワークに公開するサーバの名前を変更する際には、例えば、ＤＭＳ1の状態に応じて、その状態を表現する文字列(例えば「−Busy」)をサーバ名Server1に含めさせた代替名Server1−Busyを生成する。Busyは、忙しいのでこれ以上受け付けられない(言い換えればこれ以上配信できない)ことを意味する。単に録画中であることを表すには、録画すなわち書き込みを示すRecordingをサーバ名に含めさせて例えばServer1−Recordingとすればよい。
このような構成において、クライアントがＤＭＳ1からのデータを再生中にＤＭＳ1側で優先すべき処理(例えば録画)が開始された結果として、クライアントからの新たなアクセス(又はリクエスト)に対しては配信しない(即ち配信停止)する必要がある場合、或いは、録画していないときでも、１つのＤＭＳ1に対して複数のクライアントからアクセスが多数あり、ＤＭＳ1が配信可能な最大数を超えるアクセスに対しては配信停止する必要がある場合、ＤＭＳ1自体が自己のサーバ名を変更する(例えばサーバ名に「−Busy」を付ける)ことによって、クライアント側の画面にそのサーバ名を表示させることができクライアント側にこれ以上配信することが不可能(即ち配信不能)な状態にあることを知らせることができる。
ＤＭＳ1，ＤＭＳ2，ＤＭＳ3及びＤＭＰ1，ＤＭＰ2，ＤＭＰ3がネットワークに接続されてサーバクライアントシステムの各機器が動作可能になっている状態では、ＤＭＳ1，ＤＭＳ2，ＤＭＳ3からネットワークに対してそれぞれのサーバ名が公開されるので、ＤＭＰ1，ＤＭＰ2，ＤＭＰ3それぞれの表示部の画面ＤＳにはServerリストとしてアクセス可能なＤＭＳ1，ＤＭＳ2，ＤＭＳ3のサーバ名Server1，Server2，Server3が表示される。ＤＭＰ1，ＤＭＰ2，ＤＭＰ3の各々は、ＤＭＰ側の各ユーザの要望によりサーバ名Server1，Server2，Server3からいずれかのサーバを選びアクセスをして、アクセスしたサーバに蓄積されている動画、音楽、写真等の素材であるデータの配信を受けることができる。ＤＭＰ1，ＤＭＰ2，ＤＭＰ3の各々では、選択したサーバから所望のデータを受信して再生することになる。
ところで、ＤＭＳ1内のＨＤＤには、録画等の記録の予約時間になると、予約した映像や音楽等のデータの記録動作を開始する。この記録動作が開始されると、サーバのＨＤＤにはデータが蓄積される。その後、サーバＤＭＳ1に対して、ＤＭＰ1，ＤＭＰ2，ＤＭＰ3のうちの少なくとも１つからデータ配信要求のアクセスがあると、特に記録動作中は、全てのクライアントからのアクセスには応じられないので、サーバからクライアントへの配信数を予め決めた数を超えないように制限する。つまり、ＤＭＳ1は、録画などの記録処理の最中は、サーバの配信可能な最大数ｍを制限する。例えば、記録動作中でない場合は、サーバＤＭＳ1は、ＤＭＰ1，ＤＭＰ2，ＤＭＰ3の３台のすべてからのアクセスに対してデータ配信が同時的に可能であったのを、予約時間がきて記録動作を開始したときには、ＤＭＳ1からクライアントに対して伝送できる性能上(例えばＨＤＤが外部接続の場合にＤＭＳ1とＨＤＤ間の最大データ転送速度等の通信容量)の制限から、最大配信可能数は３台のクライアントＤＭＰ1，ＤＭＰ2，ＤＭＰ3のうちの例えば２台までに制限する。このときは、３台目のクライアントであるＤＭＰ3がサーバＤＭＳ1にアクセスしても、そのＤＭＰ3にはデータが配信されないことになる。このようなとき、従来の配信システムでは、アクセスした３台目のクライアントＤＭＰ3はどういう理由でＤＭＳ1からデータ配信がないかは視聴者であるユーザには不明のままとなっていた。つまり、従来は、サーバの状態をクライアントであるＤＭＰへ伝える手段は、ＤＬＮＡのガイドラインにはないために示されていなかった。
このような問題に対しては、本実施の形態では、ＤＭＳ1は、該ＤＭＳ1の状態(例えば録画状態とか配信不能状態とか)に応じて、ネットワークに公開するサーバ名を変更する。なお、サーバの状態に応じてサーバのサーバ名を変更する際には、そのサーバの状態を表現する文字列を元のサーバ名に含めた代替名を生成することが好ましい。つまり、その代替名を元のサーバ名の代わりに書き換えたりまたは置き換えたりする。
次に、図１のフローチャートを参照してサーバの動作を説明する。
このフローチャートは、サーバが配信数を監視し、サーバ側でデータの配信よりも優先順位の高い処理(例えば録画)が開始され、サーバからクライアントへの配信数が予め決めた最大配信可能数に制限される結果、サーバ側がクライアントからの新たなアクセスに対してデータの配信を中止するような場合(配信中止状態)には、このサーバの状態の変化をサーバ名の変更によって示し、その変更されたサーバ名をネットワークに公開することによって、クライアント側のユーザに知らせることができるようにしたものである。
サーバがクライアント側からの要求を受信し、クライアント側にデータ配信を開始したときからの動作を図１にて説明する。
まず、サーバは現時点の配信数を監視し(ステップＳ21)、配信数が最大配信可能数である最大数ｍ（Ｍａｘ）になったか否かを判定する(ステップＳ22)。ステップＳ22で配信数が最大数ｍになっていなければ、ステップＳ21にリターンする。最大数ｍは、サーバの性能上の制限に鑑みて、予め設定されている。ステップＳ21とＳ22の処理が、ファイルデータの配信数が同時配信可能数に達したか否かを判定する同時配信可能数達成判定部を構成する。
なお、配信可能な最大の制限数である最大数ｍ（Ｍａｘ）は、サーバが優先順位の高い録画処理の状態に入った場合と、サーバが録画処理の状態に入ることなくクライアントからのアクセス数のみが増加した場合とでは、異なっている。一般的には、録画処理の状態に入った場合の最大数（ｍ1）よりも、録画処理の状態に入ることがない場合の最大数（ｍ2）の方が大きい値に設定される。よって、サーバの処理状態に応じた最大数ｍが、例えば、所定のテーブルに予め設定されている。
ステップＳ22で配信数がそのときの状態の最大数ｍになっていれば、ステップＳ23へ移行し、サーバ名を変更する。例えば、サーバ名Server1を代替名Server1−Busyに変更し、ネットワークに公開する。これによって、クライアントのユーザは、サーバの負荷が最大数ｍ（Ｍａｘ）に達しており、これ以上の配信数の増加は無理な状態にあることを知ることができる。
すなわち、ステップＳ21からＳ23の処理が、ネットワークを介してのファイルデータの配信数が同時配信可能数に達すると自己のサーバ名とは異なるサーバ名を生成して公開するサーバ名公開部を構成する。
そして、サーバは上記の状態で配信数を監視し(ステップＳ24)、配信数が最大数ｍ（Ｍａｘ）を下回ったか否かを判定する(ステップＳ25)。ステップＳ25で配信数が最大数を下回っていなければ、ステップＳ24にリターンする。ステップＳ24とＳ25の処理が、ファイルデータの配信数が同時配信可能数を下回ったか否かを判定する同時配信可能数未達成状態判定部を構成する。
ステップＳ25で配信数が最大数ｍ（Ｍａｘ）を下回っていれば、ステップＳ26へ移行し、サーバ名を変更する。例えば、サーバ名Server1−Busyを元の名前Server1に変更し、ネットワークに公開する。これによって、クライアントのユーザは、サーバの負荷が最大数ｍ（Ｍａｘ）に達してなく、更なる配信数の増加が可能な状態にあることを知ることができる。すなわち、ステップＳ24からＳ26の処理が、ファイルデータの配信数が、同時配信可能数に達した後に、同時配信可能数を下回ったときは、異なるサーバ名Server1−Busyを自己のサーバ名Server1に変更するサーバ名公開部を構成する。
そして、ステップＳ26の終了後、処理は、再びステップＳ21へリターンする。
以上の説明では、同時配信可能容量の一例として同時配信可能数を説明している。また、簡単のため、全ての配信が例えば高解像度(ＨＤ)動画であった場合を想定して説明しているが、実際は音楽や写真であれば、何十本も同時配信が可能になる。ＨＤ動画、標準解像度(ＳＤ)動画、音楽、写真が混在していれば、状況により配信可能数は変動することになる。固定配信数での管理は、配信するコンテンツの種類やそれらの混合比等の混在状況によって設定される「制約」を超えないように運用する必要があるが、サーバ側がその「制約」を超える状況に至ったときはそのような状況にあることをクライアント側に知らせることが可能となる。
次に、図３及び図４を参照して、図２に示した第１の実施の形態のデータ配信システムの動作を説明する。
図３は本第１の実施の形態のデータ配信システムの動作の一例を説明するフローチャートである。
図３で動作を説明する前に、その前提を概略的に説明する。複数のＤＭＰの各々には、ネットワークに公開されている複数のＤＭＳのサーバ一覧が表示されている。ここでは、このようなサーバ一覧が図２のように各ＤＭＰに表示されているものとし、その後にサーバ名が変更されると、その都度ネットワークに公開される結果、ＤＭＳの変更されたサーバ名の一覧が各々のＤＭＰにおいて更新又はそれに相当する動作又は操作によって各ＤＭＰの表示部に表示できることになる。
次に、図３の動作について説明する。
サーバとしては複数(図では３つ)のＤＭＳ1，ＤＭＳ2，ＤＭＳ3があるが、そのうちの本第１の実施の形態に係るＤＭＳ1に対して、複数(図では３つ)のＤＭＰ1，ＤＭＰ2，ＤＭＰ3から例えば順にアクセスを行って、ＤＭＳ1に蓄積しているデータを要求したとする(ステップＳ1)。そのとき、まず１台目のＤＭＰ1からＤＭＳ1へアクセスしてデータの配信を受け、次にＤＭＰ2から同じＤＭＳ1にアクセスしてデータの配信を受けたとする(ステップＳ2)、或いは、まず１台目のＤＭＰ1からＤＭＳ1へアクセスしてデータの配信を受け、そのデータ配信中にＤＭＳ1で録画等の記録動作を開始したとする(ステップＳ2)。このステップＳ2は、ファイルデータの配信要求に応じて、ネットワークを介してファイルデータをクライアントへ配信するデータ配信部を構成する。
そのときのＤＭＳ1でのデータ配信数(ＤＭＰアクセス数とも言える)とそのときの記録動作の有無に応じて、ＤＭＳ1は、その後に他のＤＭＰ(例えばＤＭＰ3)からアクセスがあったときに幾つのＤＭＰ要求に対して配信可能であるかの最大数ｍを、予め作成済みのテーブル(対応表)を参照することによって、即ちＤＭＳ1の複数の状態それぞれに対する配信可能な最大数の関係を示すテーブルから、そのときのサーバ状態に対応する配信可能な最大数ｍを求める。最大数ｍすなわち最大配信可能数は、ＤＭＳ1の性能上の制限に鑑みて、予め設定されている。よって、ＤＭＳ１は、現在のアクセス数すなわち配信数が、その配信可能な最大数ｍに達しているか否かを判定する(ステップＳ3)。
ステップＳ3において、ＤＭＳ1のそのときの状態で配信可能な最大数ｍに達していれば、ＤＭＳ1からのこれ以上の配信は不可能であるとして、ＤＭＳ1のサーバ名Server1を代替名Server1−Busyに変更して、ネットワーク上に公開する。これにより、その後に他のクライアント (例えばＤＭＰ3)からアクセスがあった場合には、アクセスしたＤＭＰ3の表示部の画面ＤＳには、そのＤＭＰ3のアクセスに対応したＤＭＳ1のサーバ名としてServer1−Busyが表示され(ステップＳ4)、ＤＭＰ3のユーザはＤＭＳ1が他の処理で忙しくて配信が不能な状態にあることを知ることができる。そして、その後に、複数のＤＭＰからのアクセス数(配信数と言ってもよい)が最大数ｍから減少したか否かを判定し (ステップＳ5)、最大数ｍから減少していれば、ＤＭＳ1のサーバ名を元の名前Server1に戻して(ステップＳ6)、ネットワーク上に公開し、ステップＳ1にリターンする。
なお、図３の動作例は、ＤＭＳ1は性能的に余裕があるサーバであって、データ配信と同時に録画処理も行えるもの(ただし録画時には新たなデータ配信に対して配信数の制限が生じる)として説明している。一方、ＤＭＳ1が性能的に低いサーバであって、ある１つのＤＭＰからのアクセスに対してＤＭＳ1がそのＤＭＰにデータを配信中にＤＭＳ1に優先すべき録画処理の指令が入ったときはＤＭＳ1には性能的にデータ配信と録画を同時に実行することが不可能となる場合が生じ、ＤＭＳ1はそのＤＭＰに対する全てのデータ配信を中止して録画処理のみ行うことになるが、このようにＤＭＳ1による全てのデータ配信が中止になったときにも、ＤＭＳ1はそのサーバ名Server1の代替名としてServer1−Busyをネットワークに公開して現在は配信不能な状態にあることを知らせることができる。
図４は図２及び図３で説明した、ＤＭＳ1とＤＭＰ1，ＤＭＰ2，ＤＭＰ3との間で行った配信動作(例えば、録画処理が入ったときのＤＭＳ1の最大配信可能数ｍが２の場合の動作)において、３台目のＤＭＰ3からのアクセスに対応したＤＭＳ1の動作を端的に示すものであって、ＤＭＳ1の配信可能な状態(A)と配信不能に入った状態(B)とを示している。図２及び図３に示した例では、ＤＭＳ1，ＤＭＳ2，ＤＭＳ3のうちのＤＭＳ1のみがサーバ名の変更によってデータ配信の可能と不可能とを区別して通知可能であるので、ここでは図２におけるＤＭＳ1と最後にアクセスしたＤＭＰ3との関係のみを取り出して示している。
図４において、(A)はＤＭＰ3の画面上にＤＭＳ1，ＤＭＳ2，ＤＭＳ3のサーバ名Server1，Server2，Server3が表示されている状態を示している。このときは、ＤＭＳ1のサーバ名に変更がなく通常のサーバ名Server1となっているので、ＤＭＰ3のユーザは、ＤＭＰ3からのアクセスに対して、ＤＭＳ1が動画，音楽，静止画等のデータを配信可能であると知ることができる。
これに対して、(B)はＤＭＰ3の画面上にＤＭＳ1，ＤＭＳ2，ＤＭＳ3のサーバ名Server1-Busy，Server2，Server3が表示されている状態を示している。このときは、ＤＭＳ1のサーバ名がServer1-Busyのように通常のサーバ名Server1から変更されているので、ＤＭＰ3のユーザは、ＤＭＰ3からのアクセスに対してＤＭＳ1が配信不可能な状態にあると知ることができる。
ここでは、通常のサーバ名Server1とは異なるサーバ名Server1-Busyは、自己のサーバ名Server1に、所定の文字列「-Busy」を付加したものである。
なお、サーバもクライアントもそれらの機能は、ソフトウェアで実現可能であって、例えばWindows(登録商標)7はサーバとしてもクライアントとしても機能させることが可能となっている。
なお、上述したように、ＤＭＳ１が記録動作を行っているときは、通常のサーバ名Server1とは異なる例えばサーバ名Server1−Recordingが生成されて公開されている。この異なるサーバ名は、サーバが記憶部にデータの書き込みを行っていることを示す文字列「−Recording」を含んでいるので、ユーザは、ＤＭＳ１が配信不能の理由を知ることができる。
第１の実施の形態によれば、サーバは、そのサーバの状態に応じてネットワークに公開するサーバ名を変更することにより、サーバの状態が変化した時に、その状態を既サーバ名の公開という既存の仕組み(例えばここではＤＬＮＡのガイドラインに基づく仕組み内)でクライアントに知らせることが可能となる。
［第２の実施の形態］
図５は第２の実施形態におけるサーバの動作を説明するフローチャートである。また、図６は第２の実施の形態のデータ配信システムの図である。本実施の形態は、サーバとクライアント間の通信(配信)を中断することなく、サーバ名を変更したものを別のサーバ名として追加することが可能なサーバを備えたクライアントサーバシステムである。
先ず、図６を参照してデータ配信システムの概略構成を説明する。
図６は第２の実施の形態のデータ配信システムの図である。本実施の形態は、１つのハードウエア装置１１に、複数のＤＭＳを立ち上げることが可能なクライアントサーバシステムである。ＤＭＳ１を構成するハードウエア装置１１は、第１のＤＭＳ(符号ＤＭＳ1a)について、第１のＤＭＳの負荷が重くなって例えば配信数が最大数ｍを超える状態となったときにダミーサーバとして第２のＤＭＳ(符号ＤＭＳ1a-2)を立ち上げて生成する。第２のＤＭＳ(符号ＤＭＳ1a-2)はダミーでなく通常動作するＤＭＳを新たに立ち上げてもよい。第１のＤＭＳ(符号ＤＭＳ1a)のサーバ名はServer1であるのに対して、第２のＤＭＳ(符号ＤＭＳ1a-2)のサーバ名は例えばServer1_Busyと付与される。その結果、サーバ一覧(Serverリスト)には、１つのハードウエア装置１１から、サーバ名Server1と、サーバ名Server1_Busyの２つのサーバ名がネットワークに公開される。ＤＭＳ2a，ＤＭＳ3aのサーバ名Server2，Server3も加えると、サーバ一覧(Serverリスト)は４つのサーバ名を有することになる。
本第２の実施形態は、サーバの状態の変化を、サーバ名を変更したものをもう１つ追加することにより、サーバ名を変更する際に機能的に通信(配信)を一旦中断しなければならないサーバに対しても適用可能なものである。
図６において、データ配信システム１０ａは、データを蓄積する複数(図では３つ)のサーバＤＭＳ1a，ＤＭＳ2a，ＤＭＳ3aと、再生機能を持った複数(図では３つ)のクライアントＤＭＰ1，ＤＭＰ2，ＤＭＰ3とを備えている。サーバＤＭＳ1aは、本第２の実施の形態に係わるサーバであり、テレビ放送が受信可能で録画機能を有するＤＬＮＡ対応のテレビ受信機等の放送受信装置である。サーバＤＭＳ1aは、１つのハードウエア装置１１内にあるが、更に少なくとも１つのＤＭＳ(図６では例えばＤＭＳ1a-2)を立ち上げることが可能となっている。ハードウエア装置１２，１３の各装置にはそれぞれ、サーバＤＭＳ2a，サーバＤＭＳ3aを備えている。サーバＤＭＳ2a，ＤＭＳ3aについては、従来と同様の機能をもったサーバであり、例えば、通常のテレビ放送受信可能なＤＬＮＡ対応のデジタルレコーダ等の放送受信装置である。クライアントＤＭＰ1，ＤＭＰ2，ＤＭＰ3は第１の実施の形態と同様のものである。
従って、第２のＤＭＳ(ＤＭＳ1a-2)が立ち上がった状態では、データ配信システム１０ａ全体に関するサーバ一覧にはサーバ名Server1，Server1_Busy，Server2，Server3を備えることになる。
データ配信システム１０ａは、サーバとクライアント間の相互のネットワーク接続は有線式または無線式のいずれであってもよい。ＤＭＳ1aに対する負荷が軽く配信数が最大数ｍを超えない状態では、ＤＭＳ1a，ＤＭＳ2a，ＤＭＳ3aはいずれも本来の各々のサーバ名Server1，Server2，Server3をネットワークに公開し、ネットワークに接続されたＤＭＰ1，ＤＭＰ2，ＤＭＰ3はいずれもサーバ名Server1，Server2，Server3を検出して各々の表示部にサーバ一覧を表示することにより、クライアント側のユーザはサーバを指定することができる。また、いずれのＤＭＳ1a，ＤＭＳ2a，ＤＭＳ3aも、蓄積したデータをＤＭＰ1，ＤＭＰ2，ＤＭＰ3からのアクセスに応じて要求のあったクライアントに配信することができる。
さらに、ＤＭＳ1aに対する負荷が重くなって配信数が最大数ｍを超えた状態では、ＤＭＳ1a，ＤＭＳ1a-2，ＤＭＳ2a，ＤＭＳ3aの各々のサーバ名Server1，Server2，Server3がネットワークに公開され、ネットワークに接続されたＤＭＰ1，ＤＭＰ2，ＤＭＰ3はいずれもサーバ名Server1，Server1_Busy，Server2，Server3を検出して各々の表示部にサーバ一覧を表示することにより、ＤＭＳ1aに関して２つのサーバ名Server1，Server1_Busyが表示されるので、ＤＭＳ1aは忙しくて配信数を増加できない状況にあることをＤＭＰのユーザに知らせることができる。
本第２の実施の形態では、ＤＭＳ1aは、そのサーバの状態に応じてネットワークに公開するサーバ名を変更したもの(代替名)を元のサーバ名とは別に生成することが可能である。ここで、サーバの状態とは、配信数の多少や、録画中かなどの主に負荷の状態をいう。配信数の多少は、閾値である同時配信可能数の最大数ｍを超えたときを多とし、超えないときを少とすることを意味する。
このＤＭＳ1aは、ネットワークに公開するサーバ名を変更したもの(代替名)を元のサーバ名とは別に生成する際には、例えば、サーバＤＭＳ1の状態に応じて、その状態を表現する文字列(例えば「−Busy」)をサーバ名Server1に含めた代替名Server1−Busyを生成する。
このような構成において、クライアントがＤＭＳ1aからデータを再生中にＤＭＳ1a側で優先すべき処理(例えば録画)が開始された結果として、クライアントからの新たなアクセスに対しては配信停止する必要がある場合、或いは、録画していないときでも、１つのＤＭＳ1aに対して複数のクライアントからアクセスが多数あり、ＤＭＳ1aが配信可能な数を超えるアクセスに対しては配信停止する必要がある場合、第２のサーバであるＤＭＳ1a-2を立ち上げて、ＤＭＳ1aのサーバ名を変更した(例えば元のサーバ名に「−Busy」を付ける)ものを新たに設けることによって、クライアント側にサーバが配信不能な状態にあることを知らせることが可能となる。
次に、図５のフローチャートを参照してサーバの動作を説明する。
このフローチャートは、サーバが配信数を監視し、サーバ側でデータの配信よりも優先順位の高い処理(例えば録画)が開始され、サーバからクライアントへの配信数を予め決めた最大数に制限する結果、サーバ側がクライアントからの新たなアクセスに対してデータの配信を中止するような場合(配信中止状態)には、ダミーサーバの起動しそのダミーサーバの名前(サーバ名を変更して作成したもの)を元のサーバ名と共にネットワークに公開することによって、前述のサーバの状態の変化をクライアント側のユーザに知らせることができるようにしたものである。
サーバがクライアント側からの要求を受信し、クライアント側にデータ配信を開始したときからの動作を説明する。
まず、サーバは配信数を監視し(ステップＳ21)、配信数が最大数ｍ（Ｍａｘ）になったか否かを判定する(ステップＳ22)。ステップＳ22で配信数が最大数になっていなければ、ステップＳ21にリターンする。なお、同時配信可能な最大の制限数である最大数ｍ（Ｍａｘ）は、サーバが優先順位の高い録画処理の状態に入った場合と、サーバが録画処理の状態に入ることなくクライアントからのアクセス数のみが増加した場合とでは、異なっている。一般的には、録画処理の状態に入った場合の最大数（ｍ1）よりも、録画処理の状態に入ることがない場合の最大数（ｍ2）の方が大きい値に設定される。
ステップＳ22で配信数が最大数ｍになっていれば、ステップＳ23aへ移行し、ハードウエア装置１１は、ダミーサーバを起動する。よって、例えば、サーバ名Server1を代替名Server1−Busyに変更したものをダミーサーバのサーバ名として、ハードウエア装置１１は、サーバ名Server1とサーバ名Server1−Busyとをネットワークに公開する。これによって、クライアントのユーザに対して、サーバの負荷が最大数ｍ（Ｍａｘ）に達しており、これ以上の配信数の増加は無理な状態にあることを知らせることが可能となる。すなわち、自己のサーバ名Server1とは異なるサーバ名Server1−Busyは、サーバが起動している装置において、さらにもう一つのサーバを立ち上げて生成されたサーバ名である。
すなわち、ステップＳ21からＳ23aの処理が、ネットワークを介してのファイルデータの配信数が同時配信可能数に達すると自己のサーバ名とは異なるサーバ名を生成して公開するサーバ名公開部を構成する。
そして、サーバは上記の状態で配信数を監視し(ステップＳ24)、配信数が最大数ｍ（Ｍａｘ）を下回ったか否かを判定する(ステップＳ25)。ステップＳ25で配信数が最大数ｍ（Ｍａｘ）を下回っていなければ、ステップＳ24にリターンする。
ステップＳ25で配信数が最大数ｍ（Ｍａｘ）を下回っていれば、ステップＳ26aへ移行し、ダミーサーバを終了する。例えば、２つのサーバ名Server1とServer1−Busyのうちのサーバ名Server1−Busyを消去し、本来のサーバ名Server1のみに戻し、ネットワークに公開する。これによって、クライアントのユーザに対して、サーバの負荷が最大数ｍ（Ｍａｘ）に達してなく、更なる配信数の増加が可能な状態にあることを知らせることができる。すなわち、ステップＳ24からＳ26aの処理が、ファイルデータの配信数が、同時配信可能数に達した後に、同時配信可能数を下回ったときは、異なるサーバ名Server1−Busyを自己のサーバ名Server1に変更するサーバ名公開部を構成する。
そして、ステップＳ26aの終了後は、処理は、再びステップＳ21へリターンする。
次に、図６乃至図７を参照して第２の実施の形態の動作を説明する。
サーバであるＤＭＳ1a，ＤＭＳ2a，ＤＭＳ3a及びクライアントであるＤＭＰ1，ＤＭＰ2，ＤＭＰ3がネットワークに接続されてクライアントサーバシステムの各機器が動作可能で、ＤＭＳ1a，ＤＭＳ2a，ＤＭＳ3aが配信可能になっている状態では、ＤＭＰ1，ＤＭＰ2，ＤＭＰ3それぞれの表示部の画面ＤＳにはServerリストとして指定可能なＤＭＳ1a，ＤＭＳ2a，ＤＭＳ3aのサーバ名Server1，Server2，Server3が表示されている。ＤＭＰ1，ＤＭＰ2，ＤＭＰ3の各々から、各ユーザの要望によりサーバ名Server1，Server2，Server3からいずれかのサーバを選びアクセスすることによって、アクセスしたサーバに蓄積されている動画、音楽、写真等の素材であるデータを配信してもらう。ＤＭＰ1，ＤＭＰ2，ＤＭＰ3の各々では、選択したサーバから所望のデータを受信して再生する。
ところで、ＤＭＳ1aが有する記憶部としてのハードディスクＨＤＤには、記録の予約時間になると、ＨＤＤに、予約した映像や音楽等のデータを記録する動作を開始することになる。この記録動作が開始されると、ＤＭＳ1aは、蓄積してあるデータ(記録中のデータも含む)の記録動作中にＤＭＰ1，ＤＭＰ2，ＤＭＰ3の少なくとも１つからデータ配信要求のアクセスがあると、全てのクライアントからのアクセスには応じられない即ちクライアントからのアクセス数を予め決めた最大数を超えないように制限する。言い換えれば、サーバＤＭＳ1aでは、録画などの記録動作中は、クライアントに対して同時的に配信可能な最大数ｍが予め規定されている。よって、例えば、記録動作中でない場合は、ＤＭＳ1aは、ＤＭＰ1，ＤＭＰ2，ＤＭＰ3の３台のすべてからのアクセスに対して同時的に各々のクライアントにデータ配信が可能であったとしても、予約時間がきて記録動作を開始したときには、ＤＭＳ1aの性能上の制限から、配信数は３台のクライアントＤＭＰ1，ＤＭＰ2，ＤＭＰ3のうちの例えば２台までに制限する。これは、３台目のＤＭＰ3がＤＭＳ1aにアクセスしても、そのＤＭＰ3にはデータが配信されないことになる。このようなとき、従来の配信システムでは、アクセスした３台目のＤＭＰ3はどういう理由でＤＭＳ1aからデータ配信がないか不明のままとなっていた。言い換えれば、サーバの状態をクライアントであるＤＭＰへ伝える手段は、ＤＬＮＡのガイドラインには特に記載されていなかった。
このような問題に対して、本第２の実施の形態では、サーバの状態に応じてサーバのサーバ名を変えたものを追加する際には、１つの装置１１内に第１のサーバＤＭＳ1aのほかにダミーサーバとしての第２のサーバを立ち上げることによって、そのダミーサーバのサーバ名を生成する。結果として、元のサーバ名Server1に加えて、もう１つの後で立ち上げた第２のサーバのサーバ名としてServer1_Busyが生成される。
図７はサーバＤＭＳ1aの動作を説明するフローチャートである。
サーバとしては複数(図では３つ)のＤＭＳ1a，ＤＭＳ2a，ＤＭＳ3aがあるが、そのうちの本実施の形態に係る第１のＤＭＳ1aに対して、複数(図では３つ)のＤＭＰ1，ＤＭＰ2，ＤＭＰ3から例えば順にアクセスして(ステップＳ11)、第１のＤＭＳ1aに蓄積しているデータを要求したとする。そのとき、まず１台目のＤＭＰ1から第１のＤＭＳ1aにアクセスしてＤＭＰ1がデータの配信を受け、次にＤＭＰ2から第１のＤＭＳ1aにアクセスしてＤＭＰ2がデータの配信を受けたとする(ステップＳ2)、或いは、まず１台目のＤＭＰ1から第１のＤＭＳ1aにアクセスしてＤＭＰ1がデータの配信を受け、その配信中に第１のサーバＤＭＳ1aで録画等の記録動作を開始したとする(ステップＳ12)。
そのときの第１のＤＭＳ1aでのデータ配信数(ＤＳＰアクセス数とも言える)と第１のＤＭＳ1aでの記録動作の有無に応じて、第１のＤＭＳ1aは、その後に他のＤＭＰ(例えばＤＭＰ3)からアクセスがあったときに幾つのＤＭＰ要求に対して配信可能であるかの最大数ｍを、予め作成済みのテーブル(対応表)を参照することによって、即ち第１のＤＭＳ1aの複数の状態それぞれに対する配信可能な最大数の関係を示すテーブルから、そのときのサーバ状態に対する配信可能な最大数ｍを求める。最大数ｍは、第１のサーバＤＭＳ1aの性能上の制限に鑑みて、予め設定されている。よって、ＤＭＳ1aは、現在のアクセス数すなわち配信数が、その配信可能な最大数ｍに達しているか否かを判定する(ステップＳ13)。
ステップＳ13において、第１のＤＭＳ1aはそのきの状態が配信可能な最大数ｍに達していれば、これ以上の配信は不可能であるとして、第２のＤＭＳ1a-2を立ち上げそのサーバ名Server1−Busyが、ネットワーク上に公開される。これにより、元のサーバ名Server1に加えて代替名Server1−Busyが公開される。その後に他のＤＭＰ(例えばＤＭＰ3)からアクセスがあった場合には、アクセスしたＤＭＰ3の表示部の画面には、そのアクセスに対応した第１のＤＭＳ1aのサーバ名Server1のほかに、元のサーバ名Server1に関連した代替名としての第２のサーバ(例えばダミーサーバ)としてのサーバ名Server1−Busyが追加して表示され(ステップＳ14)、ＤＭＰ3のユーザは、Server1と同時にServer1−Busyを認識することができるので、ＤＭＳ1aが他の処理で忙しくて配信が不能な状態にあると知ることができる。その後に、複数のＤＭＰからのアクセス数(配信数と言ってもよい)が最大数ｍから減少したか否かを判定して(ステップＳ15)、最大数ｍから減少していれば、第２のＤＭＳ1a-2を停止してサーバ名Server1−Busyを消去し第１のＤＭＳ1aのサーバ名Server1のみに戻して(ステップＳ16)、ネットワーク上に公開し、ステップＳ11にリターンする。
図８は図６及び図７で説明した、ＤＭＳ1aとＤＭＰ1，ＤＭＰ2，ＤＭＰ3との間で行った配信動作において、３台目のＤＭＰ3のアクセスに対応したサーバＤＭＳ1aの動作を端的に示すものであって、ＤＭＳ1aの配信可能な状態であったものが配信不能に入った状態を示している。なお、図６及び図７に示した実施形態では、ＤＭＳ1a，ＤＭＳ2a，ＤＭＳ3aのうちのＤＭＳ1aに対してダミーサーバＤＭＳ1a-2が立ち上げられ、そのサーバ名としてＤＭＳ1aのサーバ名を変えた代替サーバ名が追加されることによってデータ配信の可能又は不可能を通知可能であるので、ここでは図６におけるＤＭＳ1aとＤＭＰ3との関係のみを取り出して示している。
図８においては、ＤＭＰ3の画面上にＤＭＳ1a，ＤＭＳ1a-2，ＤＭＳ2a，ＤＭＳ3aのサーバ名Server1，Server1-Busy，Server2，Server3が表示されている状態であり、ＤＭＳ1aのサーバ名Server1と追加されたダミーサーバＤＭＳ1a-2のサーバ名Server1-Busyの２つが表示されているので、ユーザは、ＤＭＰ3からのアクセスに対して、第１のＤＭＳ1aが配信不可能な状態にあると知ることができる。
第２の実施の形態によれば、サーバは、そのサーバの状態に応じてネットワークに公開するサーバ名を変更したものを元のサーバ名とは別に生成することにより、サーバ名を変更するのに通信(配信)を一旦中断しなければならないサーバであっても中断することなく、サーバの状態が変化した時に、その状態を既存の仕組み(例えばＤＬＮＡのガイドラインの範囲内)でクライアントに知らせることが可能となる。
なお、上述した実施の形態における代替名のネットワークへの公開については、サーバの状態の変化から一定時間経過するまでのみ代替名を公開したり、またはサーバの状態の変化から一定回数アクセスされるまでのみ代替名を公開したり、さらにサーバの状態の変化前に交信のあった端末にのみ代替名を公開するなどしてもよい。
さらになお、上記の例は、ＤＮＬＡの例としてＤＭＳとＤＭＰで説明したが、ＤＭＣ(Digital Media Controllerの略)とＤＭＲ(Digital Media Rendererの略)を用いた構成であってもよい。また、本実施の形態は、ＤＬＮＡに限らず、ＤＬＮＡとは別に決めたルールに従ったサーバとクライアント間での配信システムにも適用できるものである。
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれると同様に、特許請求の範囲に記載された発明とその均等の範囲に含まれるものである。
１０，１０ａ…データ配信システム、ＤＭＳ1，ＤＭＳ1a…サーバ(実施の形態に係わるサーバ)、ＤＭＳ2，ＤＭＳ3，ＤＭＳ2a，ＤＭＳ3a…サーバ(従来と同様のサーバ)、ＤＭＰ1，ＤＭＰ2，ＤＭＰ3…クライアント。

Claims (5)

  1. 記憶部に記憶された複数のファイルデータを、クライアントにネットワークを介して配信可能で、かつ自己のサーバ名を前記ネットワークに公開可能なサーバであって、
    前記ネットワークを介しての前記クライアントからのファイルデータの配信要求に応じて、前記ファイルデータの配信を行うデータ配信部と、
    前記ネットワークに前記自己のサーバ名を公開し、かつ前記ネットワークを介しての前記データ配信部からの前記ファイルデータの配信数が同時配信可能数に達すると前記自己のサーバ名とは異なるサーバ名を公開すると共に、前記ファイルデータの前記配信数が、前記同時配信可能数に達した後に、前記同時配信可能数を下回ったときは、前記異なるサーバ名を前記自己のサーバ名に変更するサーバ名公開部と、
    を有することを特徴とするサーバ。
  2. 前記同時配信可能数は、前記記憶部と前記サーバ間の最大データ転送速度に基づいて予め設定されることを特徴とする請求項１に記載のサーバ。
  3. 前記異なるサーバ名は、前記自己のサーバ名に、所定の文字列を付加したものであることを特徴とする請求項１又は２に記載のサーバ。
  4. 前記サーバは、デジタルテレビ放送を受信し、受信したデータを前記ファイルデータとして録画することが可能な放送受信装置であることを特徴とする請求項１から３のいずれか１つに記載のサーバ。
  5. 記憶部に記憶された複数のファイルデータを記憶するサーバと、このサーバとネットワークを介して接続され、該サーバから配信されたファイルデータを再生するクライアントとを備えたデータ配信システムであって、
    前記サーバは、
    前記複数のファイルデータを、前記クライアントに前記ネットワークを介して配信し、かつ自己のサーバ名を前記ネットワークに公開するサーバであって、
    前記ネットワークを介しての前記クライアントからのファイルデータの配信要求に応じて、前記ファイルデータの配信を行うデータ配信部と、
    前記ネットワークに前記自己のサーバ名を公開し、かつ前記ネットワークを介しての前記データ配信部からの前記ファイルデータの配信数が同時配信可能数に達すると前記自己のサーバ名とは異なるサーバ名を公開すると共に、前記ファイルデータの前記配信数が、前記同時配信可能数に達した後に、前記同時配信可能数を下回ったときは、前記異なるサーバ名を前記自己のサーバ名に変更するサーバ名公開部と、
    を有し、
    前記クライアントは、
    配信された前記ファイルデータを再生し、かつ前記サーバ名を表示するための表示部を有することを特徴とするデータ配信システム。
JP2011164605A 2011-05-31 2011-07-27 サーバ及びデータ配信システム Expired - Fee Related JP5039226B1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2011164605A JP5039226B1 (ja) 2011-05-31 2011-07-27 サーバ及びデータ配信システム
EP20120153615 EP2530943B1 (en) 2011-05-31 2012-02-02 Server, data distribution system and data distribution method

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2011122357 2011-05-31
JP2011122357 2011-05-31
JP2011164605A JP5039226B1 (ja) 2011-05-31 2011-07-27 サーバ及びデータ配信システム

Publications (2)

Publication Number Publication Date
JP5039226B1 true JP5039226B1 (ja) 2012-10-03
JP2013013040A JP2013013040A (ja) 2013-01-17

Family

ID=45560764

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2011164605A Expired - Fee Related JP5039226B1 (ja) 2011-05-31 2011-07-27 サーバ及びデータ配信システム

Country Status (2)

Country Link
EP (1) EP2530943B1 (ja)
JP (1) JP5039226B1 (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6519258B2 (ja) * 2015-03-23 2019-05-29 株式会社バッファロー 情報処理装置、及び情報処理方法

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2885163B2 (ja) * 1996-01-19 1999-04-19 日本電気株式会社 ビデオサーバ管理装置
JP2003296211A (ja) * 2002-04-05 2003-10-17 Nec Corp Ｗｗｗサーバ自動切替システムおよびプログラム
JP2007074356A (ja) * 2005-09-07 2007-03-22 Hitachi Ltd ホームネットワークシステム
US20070174883A1 (en) * 2006-01-20 2007-07-26 Microsoft Corporation Token Bandwidth Portioning
JP5076594B2 (ja) * 2007-03-30 2012-11-21 株式会社Ｊｖｃケンウッド サーバ装置、クライアント装置、及びコンテンツ再生方法
JP5287623B2 (ja) * 2009-09-11 2013-09-11 株式会社リコー 仮想サーバ管理システム、画像処理システム、仮想サーバ管理装置及び制御プログラム

Also Published As

Publication number Publication date
EP2530943B1 (en) 2015-03-25
EP2530943A3 (en) 2012-12-26
JP2013013040A (ja) 2013-01-17
EP2530943A2 (en) 2012-12-05

Similar Documents

Publication Publication Date Title
JP6349356B2 (ja) マルチスクリーン・インタラクション方法及びシステム
US10880408B2 (en) Streaming policy management system and method
JP5254969B2 (ja) マルチｄｖｒノード通信
US8543660B2 (en) Systems and methods for bridging and managing media content associated with separate media content networks
US8914464B2 (en) Information processing device, information processing method, and information processing system
JP2008502198A (ja) ストレージ装置間のコンテンツの転送
JPWO2008153067A1 (ja) コンテンツ配信装置、コンテンツ配信方法、プログラム、およびコンテンツ配信システム。
JP2008176644A (ja) ネットワークシステム、ダイレクトアクセス管理サーバ、イベント通知方法、ネットワーク家電機器、及びコンピュータプログラム
JP5259848B2 (ja) 再生制御装置及び再生制御方法
US9589112B2 (en) Method, device, and system for downloading contents on the basis of a rights verification
JP5314840B2 (ja) コンテンツ再生装置及びコンテンツ再生方法
US20100205615A1 (en) System and method for managing data between control point and at least one device in digital living network alliance system
US20080240670A1 (en) Picture recording system and picture recording and reproducing method
JP4880996B2 (ja) 映像タイトル再生装置および映像タイトル再生システム
CA2856518C (en) Differentiating bookmarks in content access lists shared among multiple content player devices
JP2009070184A (ja) サーバ及びサーバプログラム
JP5039226B1 (ja) サーバ及びデータ配信システム
JP2005020180A (ja) 情報処理装置、および情報処理方法、並びにコンピュータ・プログラム
EP2530945B1 (en) Server, data distribution system and data distribution method
JP5178947B2 (ja) サーバ、データ配信システム及び情報配信方法
JP2012257074A (ja) 情報処理装置、情報処理方法、プログラム及び情報処理システム
JP2014093761A (ja) 情報処理装置及びａｖコンテンツ送信方法
US10075745B2 (en) Content sending device and content sending method
JP2017079343A (ja) コンテンツ配信方法、コンテンツ配信サーバー
JP2008252199A (ja) コンテンツ配信方法及びコンテンツ受信端末

Legal Events

Date Code Title Description
TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20120706

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20150713

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20150713

Year of fee payment: 3

LAPS Cancellation because of no payment of annual fees