JPH1155645A - マルチメディア配信運用管理システム - Google Patents

Abstract

(57)【要約】 【課題】 登録データを一元管理して、クライアントか
らはシステム資源を意識せずに負荷分散したビデオファ
イル登録が行えるマルチメディア運用管理システムを得
る。 【解決手段】 ビデオ情報を大容量メモリ上に蓄積して
通信回線に接続された複数のクライアントに配信を行う
ビデオサーバを複数個接続する構成において、ビデオサ
ーバが持つ各ビデオファイルの容量と速度を含む属性情
報を記憶する管理テーブルと、クライアントからのアク
セス履歴を記憶する情報テーブルとを設けて、これら管
理テーブルと情報テーブルを参照してクライアントから
の新規ビデオファイルのビデオサーバへの登録を行うコ
ントロール・サーバを備えた。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】この発明は、映像データをビ
デオファイルに蓄積して、複数クライアントへの配信を
行うビデオサーバと、各種データの属性情報を一元管理
するコントロール・サーバで構成されたマルチメディア
・サーバシステムに関するものである。

【０００２】

【従来の技術】図１２は、例えば、ビデオサーバ２台と
クライアント３台とからなるビデオサーバシステムであ
り、図において、１，２はビデオサーバ、３，４，５は
クライアント、６はネットワークを示す。

【０００３】次に、動作について説明する。従来は、ク
ライアントが直接格納先ビデオサーバを選択して、ビデ
オファイルの登録を行っていた。このため、ビデオサー
バの負荷が上昇すると、ＣＰＵ能力に余裕がなく処理で
きない、或いは、クライアントからビデオサーバへのビ
デオファイルコピーに必要なバンド幅を確保できない、
などで登録を実行できない状態になる。例えば、ビデオ
サーバ１がクライアント３，４にビデオファイルの配信
を行っており、ビデオサーバ２は配信を行っておらず、
無負荷の状態であったとする。このとき、クライアント
５はビデオサーバ１，２の負荷状態を知らずに、負荷の
高いビデオサーバ１にビデオファイルの登録要求を送
る。すると、ビデオサーバ２には登録処理を実行する能
力の余裕があるにもかかわらず、ビデオサーバ１の能力
の限界により、クライアント５の登録が不可能となる。
このように、クライアントで各ビデオサーバの負荷を管
理していない限り、このような問題が発生し得る。

【０００４】また、クライアントが直接格納先ビデオサ
ーバを選択して、ビデオファイルの登録を行っていたた
め、ビデオサーバの空きディスク容量がビデオファイル
のサイズより小さくなると、ディスク・フルの状態を発
生し、ビデオファイルのコピーに失敗する。例えば、ク
ライアント３から、あるビデオファイルの登録を行おう
とする。このとき、ビデオサーバ１にはビデオファイル
のサイズよりも小さい空きディスク容量しかなく、ビデ
オサーバ２にはビデオファイルを最後までコピーできる
だけの空きディスク容量があるとする。このとき、クラ
イアント３が、ビデオサーバ１に対して登録要求を送る
と、コピー中にディスク・フルを発生し、ビデオファイ
ルのコピーに失敗し、ビデオサーバ２には登録可能なだ
けのディスク容量が残っていて、システム全体の空きデ
ィスク容量は限界に達していないにもかかわらず、登録
処理が不可能になる。同様にクライアント４，５から
も、同様にビデオサーバ１に対して空きディスク容量よ
りも大きいサイズのビデオファイルの登録要求を送った
場合、同様の状況に陥る。このように、クライアントで
各ビデオサーバの空きディスク容量を管理していない限
り、このような問題が発生する。更に、クライアントが
直接格納先ビデオサーバを選択してビデオファイルの登
録を行う場合、登録時にサーバ名、ボリューム名、ディ
レクトリ名、ファイル名といった格納先情報を指定する
必要があり、これらの情報をクライアントで管理してい
る必要がある。しかし、複数台のビデオサーバになると
これらの情報量が増え、ビデオサーバの追加、削除が発
生すると、これらの情報のメンテナンスも必要になり、
管理が煩雑化する。

【０００５】また、図１３は、特開平３−７００４５号
公報に掲載された従来のファイル・アロケーション位置
決定システムの構成図であり、空き領域などのディスク
容量、ファイル競合の調査、ターゲット・ディスクの選
択を、空き領域などの現在の各ディスクの状態を示した
アロケーション情報ファイル６１、現在の各ディスクの
アクセス処理状況を示したファイル・アクセス情報ファ
イル６２、ファイル・サイズなどの登録したいファイル
の情報を示した新規ファイル情報ファイル６４を作成す
ることで、自動化したことを特徴とするものである。こ
のシステムを用いて、複数台のビデオサーバのＨＤＤか
ら最適なディスクを選択してファイル登録、或いは、ミ
ラー登録する場合を考えてみる。ディジタル映像は、圧
縮されているがファイルサイズが大きく、メガバイト、
或いは、ギガバイトのサイズに及ぶものも少なくない
（例えば、ＭＰＥＧ１ １．５Ｍｂｐｓで再生時間１分
の映像ファイルのサイズは、１．５Ｍｂｐｓ×６０ｓｅ
ｃ＝９０ＭＢになる）。これらの転送は、ネットワーク
・トラフィックの増大、回線のバンド幅の占有につなが
るため、回線に必要なバンド幅を確保できるだけの空き
がない場合は、転送エラー、或いは、転送速度の低下な
どの不具合が頻発する可能性がある。よって、この問題
の解決には、空きディスク容量、アクセス競合のチェッ
クだけでは不十分であり、各ビデオサーバの最大同時配
信数、最大バンド幅数及び経由する回線のネットワーク
負荷が最小であるものを選択する機能が必要である。

【０００６】

【発明が解決しようとする課題】従来のビデオサーバシ
ステムでは、以上のように構成されているため、システ
ム全体としての資源を有効に生かせられないという問題
点があった。また、負荷分散を行おうとした場合、クラ
イアント側で行わねばならず、クライアントの負荷が大
きくなり、また、処理時間やネットワーク負荷が増大し
てしまうなどの問題があった。また、複数台のビデオサ
ーバが存在するので、クライアントで全てこれらの格納
位置属性を管理する必要があり、管理が複雑になるとい
う問題がある。また、ビデオファイルのアクセス頻度が
高い場合は、他のビデオサーバにファイルをコピーして
複数台のビデオサーバから配信するシステムが考えられ
るが、ビデオファイルをコピーして生成したミラー・フ
ァイルの格納先も管理しなくてはならず、格納位置の管
理がより複雑になるという問題がある。

【０００７】この発明は、上記のような問題を解決する
ためになされたもので、複数台のビデオサーバが接続さ
れたマルチメディア・サーバシステムにおいて、登録デ
ータを一元管理して、クライアントからはシステム資源
を意識せずに、負荷分散したビデオファイル登録が行え
るマルチメディア運用管理システムを得ることを目的と
する。更に、登録するビデオファイルに付随するキーワ
ードなどの意味属性を管理し、それらへのアクセス頻度
等からビデオファイルの格納先を選択して登録を行い、
システムの能力を最大限に引き出し、ビデオファイルの
登録操作を容易にしたシステムを得ることを目的とす
る。

【０００８】

【課題を解決するための手段】この発明に係るマルチメ
ディア配信運用管理システムは、ビデオ情報を大容量メ
モリ上に蓄積して通信回線に接続された複数のクライア
ントに配信を行うビデオサーバを複数個接続する構成に
おいて、ビデオサーバが持つ各ビデオファイルの容量と
速度を含む属性情報を記憶する管理テーブルと、クライ
アントからのアクセス履歴を記憶する情報テーブルとを
設けて、これら管理テーブルと情報テーブルを参照して
クライアントからの新規ビデオファイルのビデオサーバ
への登録を行うコントロール・サーバを備えた。

【０００９】また更に、情報テーブル中のアクセス履歴
には、所定の時間単位でのアクセス実績を記憶するよう
にし、新規ビデオファイルのビデオサーバへの登録に際
して上記アクセス実績の少ないビデオサーバを選択する
ようにした。

【００１０】また更に、情報テーブルにビデオサーバの
サービス予定時間の欄を設けて、新規ビデオファイルの
ビデオサーバへの登録に際してはサービス予定時間を参
照して、負荷が少ないビデオサーバを選択するようにし
た。

【００１１】また更に、ビデオサーバのビデオ情報に対
して相対的に大容量ビデオ情報を蓄積してクライアント
に配信を行うライブラリサーバを備えて、ビデオサーバ
に登録不可のビデオファイルを登録するようにした。

【００１２】また更に、情報テーブル中のアクセス履歴
には、所定の時間単位でのアクセス実績を記憶するよう
にし、ビデオファイルの登録に際してアクセス実績の少
ない場合はライブラリサーバに登録するようにした。

【００１３】また更に、コントロール・サーバの管理テ
ーブルには、元のビデオファイルからコピーをして同じ
複数のビデオファイルを生成するミラー・ファイルの管
理の欄を設け、ミラー・ファイルの管理も行うようにし
た。

【００１４】また更に、コントロール・サーバの情報テ
ーブル中にあるアクセス記録より、負荷量が低いかまた
は空き容量が大きいビデオサーバを選択してミラー・フ
ァイルを生成するようにした。

【００１５】また更に、ビデオサーバのビデオ情報に対
して相対的に大容量ビデオ情報を蓄積してクライアント
に配信を行うライブラリサーバを備えて、バックアップ
としてミラー・ファイルを指定すると、ライブラリサー
バにミラー・ファイルを生成するようにした。

【００１６】また更に、クライアントにはビデオ信号を
圧縮するエンコーダを設けて、ビデオファイルの登録に
際してこのエンコーダでエンコードした信号を登録する
ようにした。

【００１７】また更に、ビデオサーバまたはライブラリ
サーバにはビデオ入力読み取り装置を備えて、ビデオフ
ァイルの登録を指定されると、この指定のビデオファイ
ルがビデオ入力読み取り装置の入力にあればその入力を
読みとるようにした。

【００１８】また更に、ビデオサーバまたはライブラリ
サーバにはビデオ信号を圧縮するエンコーダとビデオ入
力読み取り装置とを設けて、読み取り装置からのビデオ
ファイルの登録に際してエンコーダでエンコードした信
号を登録するようにした。

【００１９】

【発明の実施の形態】

実施の形態１．このシステムは、映像データをディジタ
ル化したビデオファイルとしてハードディスク装置上に
蓄積し、通信回線上の複数クライアントへの配信を行う
ビデオサーバと、必要により大容量二次記憶装置を接続
してビデオファイルを格納するためのライブラリサーバ
と、ビデオサーバ、ライブラリサーバ上に格納された各
種データの属性情報（実体ファイルの格納先、つまり、
ビデオサーバ名及び格納ディレクトリ名やデータの持つ
意味内容を反映したキーワード、アクセス対象者、課金
を行う場合の課金単価などの情報全般）を、データベー
ス管理システム（Database Management System、以後、
ＤＢＭＳとする）を用いてデータベース上に格納するこ
とで各種データを一元管理し、これらサーバを制御し、
複数クライアントからの要求を集中的に受け付け、属性
情報を利用して検索、データの登録／削除／変更、運用
管理を行うコントロール・サーバで構成されたマルチメ
ディア・サーバシステムである。このシステムにおいて
は、ビデオファイル登録時におけるビデオファイル格納
先サーバを所定の順位で選択すること及びミラー・ファ
イルやバックアップファイルの生成を行い、各ビデオサ
ーバの負荷、ディスク使用量を分散し、更に、管理者の
負担を軽減する。

【００２０】以下、この発明の実施の形態１を図につい
て説明する。図１は、マルチメディア・サーバにおける
ハードウェア構成の例を示す図である。図１において、
１，２はビデオサーバ、３，４，５はクライアント、６
はネットワーク、７はコントロール・サーバである。８
は大容量二次記憶装置を接続したライブラリサーバで必
須構成要素ではないが、あることが望ましい。各ビデオ
サーバ１，２、コントロール・サーバ７、ライブラリサ
ーバ８、各クライアント３，４，５からネットワーク６
につながる線は、ネットワーク用のケーブルを示す。ビ
デオファイルの登録処理は、ビデオサーバ１、ビデオサ
ーバ２のハードディスク装置、ライブラリサーバ８の二
次記憶装置上のいずれかに、登録要求ビデオファイルの
実体である物理ファイル１０がコピーされ、また、コン
トロール・サーバ７のデータベース９上にビデオファイ
ルに付随する属性情報（物理ファイル情報、論理ファイ
ル情報、その他）の格納を行う。登録するビデオファイ
ルは、ディジタル圧縮済みであることを前提とし、クラ
イアント３，４，５のいずれかのＣＤ−ＲＯＭまたはハ
ードディスク上からビデオサーバ１，２、或いは、ライ
ブラリサーバ８のいずれかに登録する。

【００２１】コントロール・サーバ７は、ビデオファイ
ルの属性情報以外にも、その他システム管理に必要な情
報をデータベース９に保持する。更に、コントロール・
サーバ７は、クライアント３，４，５からの要求を受け
付け、現在、或いは、今後の各ビデオサーバの負荷から
適切な負荷バランスを考慮して、クライアントからの登
録要求を受け付けて、そのビデオファイルをビデオサー
バ１，２のいずれに配信させるか決定する。また、この
ときに受け付けた要求に関する情報は、全てアクセス履
歴としてデータベース９、或いは、ファイルに保存可能
である。なお、この発明では、ビデオサーバ及びクライ
アントは何台接続されていてもよく、クライアント、ビ
デオサーバ、ライブラリサーバ、コントロール・サーバ
が相互に通信できれば、ネットワークはどのように接続
されていても構わない。

【００２２】図２は、ファイル登録の入力からビデオフ
ァイルの登録先の決定出力に至るまでの詳細要素と処理
の関係を示した処理構成図である。図において、１１は
クライアントからの入力情報（登録、ミラー要求）、ビ
デオサーバ情報テーブル１２は、ビデオサーバの動的な
状態情報を集めたテーブルでメモリ上に存在する。１５
はデータベース・アクセスを行うためのモジュール、１
６は一連の処理結果でビデオサーバを指定した決定情
報、１７は入力情報から最適なビデオサーバを導き出す
運用管理を行うプログラムである。運用管理プログラム
１７は、入力情報１１より得た登録ビデオファイル名等
の情報と、データベース・アクセスモジュール（データ
ベース・インタフェース）１５を介してデータベース９
内のビデオサーバ管理テーブル１３、ボリューム管理テ
ーブル１４から（ミラー登録時は、論理ファイル管理テ
ーブル１８、物理ファイル管理テーブル１９からも）取
得した各サーバ、ボリュームの登録処理に関連する最大
処理能力を規定する値を含む静的情報及びビデオサーバ
情報テーブル１２の各ビデオサーバ及びライブラリサー
バの現在の負荷状態を用いて、各ビデオサーバの現状の
処理能力を求め登録先サーバを決定し、決定情報１６を
出力する。

【００２３】図３は、ビデオサーバ管理テーブル１３
の、図４は、ボリューム管理テーブル１４の内容を示す
表の一例である。図３のビデオサーバ管理テーブル１３
において、２１はシステム上に存在するビデオサーバを
一意に特定するユニークな符号または数値、２２はビデ
オサーバの名前、２３はビデオサーバの最大配信数、２
４はビデオサーバで使用できる最大バンド幅、２５はビ
デオサーバ物理ファイル格納に使用できるディスクの総
ディスク容量、２６はビデオサーバの同一ファイルの最
大配信数をそれぞれ示す。図４のボリューム管理テーブ
ルは、各ビデオサーバに登録されたビデオファイル等の
ボリュームを管理するテーブルであり、図において、３
１はシステム上に存在する個々のボリュームを一意に特
定するユニークな符号または数値、３２はボリュームの
接続されているサーバのサーバＩＤ、３３はボリューム
の名前、３４はボリュームの最大同時配信数、３５はボ
リュームの最大バンド幅、３６はボリュームの総ディス
ク容量、３７はビデオボリュームに割り当てられている
ドライブレターをそれぞれ示す。

【００２４】ビデオサーバ情報テーブル１２で保持する
各ビデオサーバの、各々の最大同時配信数、最大バンド
幅、最大ディスク容量といった静的情報は、初期化時に
データベースのビデオサーバ管理テーブル１３とボリュ
ーム管理テーブル１４から読み込んで値を決定し、ビデ
オサーバ情報テーブル１２に保持する。更に、ビデオサ
ーバ情報テーブル１２では、各ビデオサーバの現在の配
信数、使用バンド幅、空きディスク容量などの動的情報
を併せ持ち、それらの最大値と現在値の差分を求めるこ
とで、各ビデオサーバの現在の負荷状況、使用可能ディ
スク容量を保持している。なお、現在の配信数、使用バ
ンド幅、空きディスク容量などの動的情報は、クライア
ントからの操作要求にしたがって更新されるものであ
り、例えば、クライアントからの登録処理が開始される
と、値は更新される。

【００２５】図５は、コントロール・サーバ７上の運用
管理プログラム１７が行う登録先サーバ選択処理の動作
を示したフローチャートである。この処理は、各ビデオ
サーバの現在の配信数、使用バンド幅、使用可能ディス
ク容量の３つの条件から登録先ビデオサーバを決定する
処理であり、また、条件を満たすビデオサーバが存在し
ない場合には、ライブラリサーバを登録先サーバに選択
する処理を示している。

【００２６】まず、ステップＳ１０１（以降、ステップ
の記述を省略する）で、システムで稼動中のビデオサー
バを全てメモリ上のリストＬ１に納める。リストＬ１に
納められたビデオサーバの中からビデオサーバ情報テー
ブル１２を参照して、現在の配信数が最も少ないビデオ
サーバを選択する（Ｓ１０２）。

【００２７】選出したビデオサーバＶＳ１に関して、ビ
デオサーバ管理テーブル１３を参照し、現在の状態が要
求ビデオファイルの登録に必要な使用可能ディスク容量
がある（Ｓ１０３）、またはビデオサーバＶＳ１に対す
る現在の総配信数が最大配信数に達していない（Ｓ１０
４）、またはネットワークのバンド幅に余裕がある（Ｓ
１０５）かどうかを確認し、いずれか１つでも該当する
場合は、このＶＳ１は要求されたビデオファイルの登録
を許可できないとしてリストＬ１から除外し、ＶＳ１を
除外したリストを新たにリストＬ１とする（Ｓ１０
９）。なお、ＶＳ１の最大配信数は、そのＶＳ１の能力
の限界による最大配信数に限らない。即ち、システム設
定時にＶＳ１の能力の限界による最大配信数に満たない
数値で、論理的に最大配信数の上限をデータベース９上
のビデオサーバ管理テーブル１３、ボリューム管理テー
ブル１４に設定して、それを最大配信数と規定し、この
ＶＳ１の論理的な最大配信数を越える処理、例えば、最
大配信時にその他のビデオサーバにミラー・ファイル生
成のためのコピーなどの処理を行うようにすることによ
って、負荷分散ができる。また、ネットワークのバンド
幅に関しても、同様に論理的上限値をデータベース９上
のビデオサーバ管理テーブル１３、ボリューム管理テー
ブル１４に設定することで、負荷分散の処理ができる。
また、使用可能ディスク容量に関しても、最大配信時の
ミラー・ファイル生成にも、更に、実際の最大ディスク
容量の管理に関しても、同様のことができる。

【００２８】一方、選択したビデオサーバＶＳ１に関し
て、ＶＳ１が現在要求ビデオファイル登録に必要な使用
可能ディスク容量が十分あり（Ｓ１０３）、総配信数が
最大配信数に達しておらず（Ｓ１０４）、かつ、ネット
ワークのバンド幅も十分余裕がある（Ｓ１０５）場合、
そのビデオサーバＶＳ１に、要求ビデオファイルを登録
するよう決める（Ｓ１０６）。なお、Ｓ１０４，Ｓ１０
５の２つの条件に優先順位はない。よって、図中の実行
順序は入れ替わっても構わない。Ｓ１０３，Ｓ１０４，
Ｓ１０５において、それぞれ条件を満たさない場合は、
リストＬ１からビデオサーバＶＳ１を除き、新たにビデ
オサーバリストＬ１とする（Ｓ１０９）。

【００２９】以上の処理を、要求されたビデオファイル
の登録先のビデオサーバが決定するか（Ｓ１０６）、ま
たはビデオサーバリストＬ１が空になるまで繰り返し行
う（Ｓ１１０）。リストＬ１が空になった場合は、ライ
ブラリサーバ８への登録を行うかどうか確認する（Ｓ１
１１）。登録を行わない場合は、登録先サーバなしとい
うことで処理を終了する。登録を行う場合は、ライブラ
リサーバ８を登録先サーバとした処理を開始し、空きデ
ィスク容量などを調べてライブラリサーバ８が使用可能
かどうかを確認する（Ｓ１１２）。使用可能状態でない
場合は、登録先サーバなしということで処理を終了す
る。空き領域が十分にあるなどで使用可能状態の場合
は、ライブラリサーバ８を登録先と決定する（Ｓ１１
３）。

【００３０】次に、図６について説明する。この図は、
一連のビデオファイル登録処理のフローチャート図であ
り、図５で例としてあげた登録先サーバ決定の処理（Ｓ
２０１）を含む。図６のこの後のＳ２０２〜Ｓ２０７の
部分は、格納位置をユーザに意識させないで、ビデオフ
ァイルのコピー及び属性情報の生成、データベース９へ
の登録処理を行う動作の一例を示している。まず、ビデ
オファイルの登録要求を運用管理プログラムに入力する
と、運用管理プログラムは、先に説明した図５などの手
順により、格納先サーバを決定する（Ｓ２０１）。次
に、そのビデオファイルに対して論理ファイルＩＤを生
成する（Ｓ２０２）。論理ファイルＩＤには、システム
で連続したユニークな値を設定する。

【００３１】これに続いて、Ｓ２０２で生成した論理フ
ァイルＩＤを用いて、ビデオファイルの格納先ディレク
トリ名、ファイル名を生成する。例えば、論理ファイル
ＩＤが００００００００〜００００００９９までは００
００００００．ｄｉｒ、０００００１００〜０００００
１９９までは０００００００１．ｄｉｒといった具合
に、論理ファイルＩＤ１００単位で１つのディレクトリ
を割り当てる。これは、１ディレクトリに格納可能な最
大ファイル数には、ＯＳレベルでの制限があるためであ
る。１ディレクトリに格納する最大ファイル数は、この
制限を超えないようにディレクトリを展開するよう制御
することにより、１ディレクトリに制約以上の数のファ
イルを登録しようとしてエラーが起きることを回避す
る。なお、ディレクトリは、ルートディレクトリの下に
水平展開する方式にすると、ディレクトリ名を得るのに
階層をたどる必要がなく理解しやすい。

【００３２】ファイル名生成は、例えば、論理ファイル
ＩＤとオリジナルファイルの拡張子を併せ、例えば、拡
張子が．ｍｐｇの場合は、０００００００１．ｍｐｇと
する（Ｓ２０３）。この結果、格納先に関する値（格納
先ビデオサーバ名、ボリューム名、ディレクトリ名、フ
ァイル名）を全てシステムで決めるため、登録要求側で
これらを意識する必要はない。

【００３３】次に、Ｓ２０３で決定した格納先ディレク
トリ名がＳ２０１で決定した格納先のビデオサーバに存
在するかどうかを確認する（Ｓ２０４）。存在しない場
合は、ディレクトリの生成を行う（Ｓ２１０）。Ｓ２０
３で決定したディレクトリに向けてビデオファイルのコ
ピーを実行する（Ｓ２０５）。コピー実行中は、予めＳ
２０１におけるビデオサーバの決定時に、最も負荷の低
いビデオサーバを選択しているため、登録処理が中断さ
れることはない。また、この期間中に新たな登録や配信
先のビデオサーバを選択する際にも、このビデオサーバ
が実行している登録処理の負荷を含めて処理されるた
め、登録処理が中断されることはない。

【００３４】Ｓ２０５のファイルコピーが完了すると、
格納位置情報をデータベースへ登録する。データベース
９上の物理ファイル管理テーブル１９へ論理ファイルＩ
Ｄと共に、格納先ボリュームＩＤを登録する（Ｓ２０
６）。更に、論理ファイル管理テーブル１８へ生成した
論理ファイルＩＤと共に、決定した格納先ディレクトリ
名、ファイル名などの格納位置やその他の属性を登録す
る（Ｓ２０７）。

【００３５】物理ファイル管理テーブル１９は、ビデオ
ファイル登録及びミラー・ファイル登録において、シス
テムのビデオサーバ１、或いは、ライブラリサーバ８上
にコピーされた個々の物理ファイル１０を管理するファ
イルで、図７に示すような属性、論理ファイルＩＤ４
１、格納先ボリュームＩＤ４２、フルパスファイル名４
３を持つ。フルパスファイル名４３は、ファイル・アク
セスを高速化するため、論理ファイルＩＤ４１から直接
アクセスパスを得るために追加したものである。処理速
度は落ちるが、物理ファイルテーブルにフルパスファイ
ル名４３の属性を保持しなくても、格納先ボリュームＩ
Ｄ４２からボリューム管理テーブル１４を参照して、ボ
リュームＩＤ３１とサーバＩＤ３２、更に、ビデオサー
バ管理テーブル１３を参照して、サーバＩＤ２１とサー
バ名２２からフルパスファイル名４３を知り、ファイル
・アクセスを行うことは可能である。

【００３６】なお、論理ファイルとは、システムに登録
済みの個々のビデオファイルを管理するための属性情報
を持った論理的な単位であり、個々の論理ファイルは、
論理ファイル管理テーブル１８の１レコードとして管理
している。ミラーが存在する場合でも、１つの登録済み
ビデオファイルは、１つの論理ファイルとして考え、対
応するレコードは１レコードである。論理ファイル管理
テーブル１８は、図８に示すような属性、論理ファイル
ＩＤ５１、格納先ディレクトリ名５２、格納先ファイル
名５３、ファイルサイズ５４、必要バンド幅５５、ミラ
ーカウンタ５６を持つ。この他、図中にはないが、コン
テンツ名、キーワードなどの意味属性を含めることもで
きる。論理ファイルＩＤ５１〜ファイルサイズ５４、ミ
ラーカウンタ５６は、システムで値を設定、取得し、必
要バンド幅５５、その他の意味情報は、登録要求時にユ
ーザ入力情報としてクライアントから与える。

【００３７】ミラーカウンタ５６は、このビデオファイ
ルにいくつのミラー・ファイルが存在するかを示す。通
常のビデオファイル登録を行った場合には、対応する論
理ファイルは１つ存在し、データベース上に対応する論
理ファイルテーブルのレコードが１レコード、同一論理
ＩＤを持つ物理ファイルテーブルのレコードが１レコー
ド存在する。論理ファイル管理テーブル１８のミラーカ
ウンタ５６の値は、物理ファイル（＝同一論理ＩＤを持
つ物理ファイルテーブル・レコードの件数）と一致して
おり、１となる。この実施の形態では、論理ファイル管
理テーブル１８で格納先ディレクトリ名、ファイル名
を、物理ファイル管理テーブル１９で格納先サーバを特
定するサーバＩＤを持つといった具合に、ビデオファイ
ルの格納位置属性を２つのテーブルで分割して持ってい
る。これは、ミラー・ファイルを含めたビデオファイル
の管理を容易にするためであり、ビデオサーバ間でディ
レクトリ構造を同じにすることを前提とし、ミラー・フ
ァイルは異なるサーバ上の最初に登録した物理ファイル
と同一ディレクトリ名、ファイル名で生成する。このこ
とは、オリジナルとミラー・ファイルを共通の１つの論
理ファイルとして論理ファイルＩＤを共有し、更に、論
理ファイル管理テーブルのビデオファイル格納ディレク
トリ名、ファイル名を共有することで、ミラー・ファイ
ルであっても、論理ファイルＩＤとシステムが選択した
ミラー先サーバＩＤを物理ファイル管理テーブル１９に
登録しておけば、以後、論理ファイルＩＤのみでアクセ
スに必要な格納位置を取得でき、また、格納位置管理を
容易にする。

【００３８】Ｓ２０７のデータベース９への格納位置情
報の登録が終了すると、コピーしたファイルを他のビデ
オサーバにコピーして、ミラー・ファイルを作成したい
かどうか確認する（Ｓ２０８）。ミラー・ファイルの作
成を行わない場合は、登録処理を終了する。ミラー・フ
ァイル登録を行う場合は、図１０のＳ４０１へと処理を
続ける。

【００３９】実施の形態２．クライアントからのアクセ
スが多いビデオファイルについては、同じ内容をコピー
して複数のビデオファイルを生成してミラー・ファイル
とする。こうすることで、多くのクライアントからの同
時アクセスを可能にし、サービスを向上できる。図１０
は、ミラー・ファイル登録処理の動作を示すフローチャ
ート図であり、図６のＳ２０８でミラー登録を行う場合
に続く処理を示した図である。また、図９は、ミラー登
録処理に含まれるミラー先サーバ選択処理の動作を示す
フローチャートであり、図１０中のＳ４０１で登録先ミ
ラーサーバを指定しなかった場合に実行されるＳ４０２
の詳細処理を示す。この処理は、クライアントからはビ
デオファイル登録要求と同時に、ミラー・ファイル登録
を行うよう要求を送った場合を想定しているが、ビデオ
ファイル登録終了後、改めてミラー登録要求を行う場合
には、図１０の処理を後から実行すればよい。

【００４０】図９に基づいて動作を説明する。まず、デ
ータベース９上の物理ファイル管理テーブル１９を参照
し、ミラー登録要求したビデオファイルの論理ファイル
ＩＤからオリジナルファイルを登録したビデオサーバを
特定し、このビデオサーバを除外したビデオサーバのリ
ストＬ４を作成する（Ｓ３０１）。次に、リストＬ４か
ら現在の配信数が最も少ないビデオサーバを選択し、Ｖ
Ｓ１とする（Ｓ３０２）。ＶＳ１の現在の配信数が最大
配信数に達している場合（Ｓ３０３）、または空きバン
ド幅に余裕がない場合（Ｓ３０４）は、リストＬ４から
ＶＳ１を除いたものを新たにリストＬ４とする（Ｓ３０
７）。

【００４１】一方、ＶＳ１の現在の使用可能ディスク容
量が十分か（Ｓ３０３）、配信数が最大配信数に達して
いないか（Ｓ３０４）、空きバンド幅に余裕があるか
（Ｓ３０５）を確認し、いずれの条件も満たす場合は、
ビデオサーバＶＳ１をミラー登録先サーバに決定し（Ｓ
３０６）、ミラー登録処理を行うためＳ４０３に進む。
なお、Ｓ３０４，Ｓ３０５の２つの条件に優先順位はな
い。よって、図中の順序は、入れ替わっても構わない。
ステップＳ３０７の処理でリストＬ４の更新を行った場
合、リストＬ４が空になったかどうか確認し、空になっ
ていない場合は、ステップＳ３０３に戻り、ミラー登録
先ビデオサーバＶＳ１が決定するか（Ｓ３０６）、リス
トＬ４が空になるまで処理を繰り返す。ステップＳ３０
８で、リストＬ４が空になった場合、ライブラリサーバ
をミラー先に使用するかどうかを確認する（Ｓ３０
９）。使用しない場合は、ミラー先サーバなしとして一
連のビデオファイル登録、ミラー登録を終了する。

【００４２】ビデオサーバに備えられた物理ファイル１
０に比べて、相対的に大容量の二次記憶装置（例えば、
ＭＯ等の物理ファイル）１０ｂを備えたライブラリサー
バがアクセス頻度の少ないビデオファイルを収容する
と、システムのバランスがよくなる。一般に、低速の二
次記憶装置は、価格が安く、限られた資源を用いてクラ
イアントからのアクセスを各サーバに分担する際に、ラ
イブラリサーバが有効になる。このライブラリサーバを
使用する場合は、ライブラリサーバが使用可能かどうか
を確認する（Ｓ３１０）。使用可能でない場合は、ミラ
ー先サーバなしとして一連のビデオファイル登録、ミラ
ー登録を終了する。使用可能な場合は、ミラー登録先サ
ーバをライブラリサーバに決定し（Ｓ３１１）、ミラー
登録処理を行うためＳ４０３に進む。

【００４３】次に、図１０について説明する。この図
は、図９のミラー登録先決定処理を含むビデオファイル
登録時に、同時にミラー登録を行う処理全体のフローチ
ャート図である。まず、ビデオファイル登録要求時に、
ミラー登録を同時に行うよう運用管理プログラムに入力
すると、運用管理プログラムは、ミラー登録先サーバが
指定されているかどうかを確認する（Ｓ４０１）。指定
されていない場合は、ミラー登録先サーバを決定する
（Ｓ４０２）。これは先に説明した図９で示される処理
により決定される。

【００４４】次に、データベース上の論理ファイル管理
テーブルを参照して、ミラー要求ビデオファイルの論理
ファイルＩＤからコピー元になるビデオファイルの格納
先ディレクトリ名とファイル名を取得する（Ｓ４０
３）。これにより、ミラー登録を指定するのに必要な物
理的な位置情報は全て揃ったことになる。次に、Ｓ４０
１で決定したミラー先ビデオサーバに、Ｓ４０２で得た
ディレクトリが存在するか確認し（Ｓ４０４）、なけれ
ば生成する（Ｓ４１１）。Ｓ４０３で得たディレクトリ
・ファイル名でミラー・ファイルをコピーするため、ス
テップＳ４０４で、ミラー元ビデオファイルの格納位置
を論理ファイルテーブルを参照して、ミラー元ファイル
の論理ファイルＩＤから格納先のフルパスファイル名を
取得する（Ｓ４０５）。Ｓ４０２、或いは、入力情報、
Ｓ４０３で得たミラー元ファイル及びミラー先ファイル
の位置情報を元に、ビデオファイルのコピーを行い、ミ
ラー・ファイルの生成を行う（Ｓ４０６）。

【００４５】次に、登録したミラー・ファイルの格納位
置をデータベースに登録するための手続きを行う。ま
ず、物理ファイル管理テーブル１９に論理ファイルＩＤ
と格納先ボリュームＩＤを指定して、新規レコードを登
録する（Ｓ４０７）。次に、ミラー元ビデオファイルの
論理ファイルＩＤを持つ論理ファイルテーブル・レコー
ドのミラーカウンタ５６を＋１した値に更新する（Ｓ４
０８）。以上により、以後、論理ファイルＩＤを指定す
れば、データベースから論理ファイル管理テーブル、物
理ファイルテーブルを参照して、ミラー・ファイルの有
無や格納位置を取得し、ファイルへのアクセスを行うこ
とが可能になる。

【００４６】一方、Ｓ４０１でミラー先サーバの指定が
ある場合は、図９のＳ３０３，Ｓ３０４，Ｓ３０５と同
様の負荷状態チェックを行い（Ｓ４１０）、実行可能な
状態であると判定された場合のみ、Ｓ４０３からのミラ
ー登録処理を続ける。それ以外の場合は、ミラー登録実
行不可能として処理を終了する。

【００４７】本実施の形態には明示していないが、運用
管理プログラムによって導き出されたビデオサーバへの
ファイル登録には２通りの方法が考えられる。１つは、
決定したビデオサーバに対して登録を要求する方法、も
う一方は、クライアントに対して決定したビデオサーバ
を通知し、クライアントからビデオサーバに直接アクセ
スする方法である。これは原則としては、どちらの方法
を利用しても構わない。

【００４８】実施の形態３．本実施の形態では、図５の
Ｓ１０３，Ｓ１０４，Ｓ１０５のチェックで、複数のビ
デオサーバが選択肢として残った場合に、アクセス履歴
による各ビデオサーバの負荷予測を判定基準に追加し
て、新規ビデオファイルの登録に際して、より適切なビ
デオサーバの選択を行う場合を説明する。例えば、各ビ
デオサーバのアクセス履歴によってビデオサーバ毎に、
一日のサービス予定時間のアクセス実績である負荷分布
のデータを取り、そのビデオサーバについて今後の時間
帯の負荷が増加するか減少するか、いずれの傾向にある
かを予測して、これを１つの判定基準とする。もちろ
ん、このサービス予定時間のアクセス実績は、時間単位
でなく、日単位、週単位、月単位とすることもできる。
アクセス履歴は、クライアントからの操作要求時に全て
データベース上のテーブルなどに記憶され、その内容と
して、例えば、登録要求時には要求クライアント名、実
行日時、ファイル名、サーバ名、操作内容、実行結果な
どを持つ。これにより、データベース・アクセスモジュ
ール１５を介して、ビデオファイルのアクセス履歴やサ
ーバの負荷分布等を得ることができる。例えば、Ｓ１０
３〜Ｓ１０５の後にこの処理を追加することで、負荷が
増加傾向にあるビデオサーバは除外し、現在及び今後最
も負荷の少ないビデオサーバを選択することが可能にな
る。なお、アクセス履歴から得た一日の負荷分布による
負荷予測は、ビデオファイル登録用ビデオサーバの負荷
分散のみならず、ミラー・ファイル登録の際に対象とな
るビデオサーバの選択時にも適応することにより、ミラ
ー登録時の負荷分散効果が得られる。

【００４９】同様に、図５のＳ１０３，Ｓ１０４，Ｓ１
０５のチェックで、複数のビデオサーバ選択肢として残
った場合に、登録要求ビデオファイルの登録処理終了時
までの各ビデオサーバの負荷状態を判定基準に追加し
て、より適切なビデオサーバの選択を行う場合を説明す
る。例えば、ビデオサーバ情報テーブル１２上に、現在
配信中の各ビデオサーバのサービス予定時間としての配
信開始時間、ファイルサイズの項目を設け、各配信ファ
イルの配信残り時間を計算して負荷予測を行って、今後
の配信数、或いは、配信使用数バンド幅に最も余裕のあ
るビデオサーバを判断する。この処理を、例えば、Ｓ１
０３〜Ｓ１０５の後に追加することで、負荷が増加傾向
にあるビデオサーバは除外し、現在及び今後最も負荷が
少ないと考えられるビデオサーバを選択することができ
る。なお、アクセス履歴による負荷予測及びそのビデオ
サーバにおける残りの配信時間による負荷予測は、同時
に用いても別々に用いてもよい。

【００５０】実施の形態４．本実施の形態では、ビデオ
ファイル登録時の登録先サーバとして、ビデオサーバか
ライブラリサーバのいずれを選択するかの方法として、
ビデオファイルに付随する意味属性の値に着目して、ア
クセス履歴中の同一意味属性値を持つビデオファイルの
過去のアクセス頻度を選択基準とする場合を示す。即
ち、調べたアクセス頻度から登録要求ビデオファイルの
アクセス頻度予測を行い、頻度が高いと判断した場合
は、最も負荷の低いビデオサーバを実施の形態１，２で
述べた処理で選択し、より高速にアクセス可能なハード
ディスク上にビデオファイルを登録する。また、アクセ
ス頻度が低いと判断した場合は、ライブラリサーバを選
択し、アクセス速度がハードディスクより劣るが、より
安価で大容量のデータを格納できる二次記憶装置の媒体
上にビデオファイルをコピーする。この結果、アクセス
頻度の高いビデオファイルを選択して、ビデオサーバの
ハードディスクに格納するので、対応してこれらのビデ
オファイルへの配信要求に、迅速なサービスを実施でき
る。また、ハードディスク装置は高価であるため、アク
セス頻度の低いビデオファイルはハードディスクより安
価な二次記憶媒体上に格納して、ディスク資源の有効利
用を図ることができる。

【００５１】実施の形態５．実施の形態１では、ビデオ
ファイル登録とミラー・ファイル登録の同時登録を行う
かどうかを、登録要求の入力時にクライアントから入力
していた。これ以外に、入力時にビデオファイルに付随
する意味属性を一緒に入力し、アクセス履歴からこの値
と同じ意味属性値を持つ登録済みビデオファイルを探
し、存在する場合は、このビデオファイルのこれまでの
過去のアクセス頻度を確認することで、同時ミラー登録
の自動実行を行う。自動実行のやり方は、図９のＳ３０
３〜Ｓ３０５のところで、アクセス頻度が少ないとミラ
ー・ファイルとしてライブラリサーバを選ぶようにす
る。この処理は、アプリケーションで意味属性を検索キ
ーとして使用している場合などに使用すると効果的であ
る。

【００５２】この処理を行うためには、システムでデー
タベース９上にアクセス頻度の閾値情報を専用テーブル
を設けるなどして設定しておき、登録要求のあったビデ
オファイルの意味属性からアクセス頻度が閾値を上回る
場合は、ミラー・ファイル登録を実行するようにし、ア
クセス頻度が閾値を下回る場合は、ミラー登録を実施し
ないようにする。この結果、人間が行っていたミラー登
録実施の判断を自動化し、アクセス要求の高いビデオフ
ァイルから優先的にミラー登録することができ、配信要
求集中時の負荷の分散、ディスク資源の有効利用を図る
ことができる。

【００５３】実施の形態６．実施の形態１，５では、配
信要求集中時の負荷分散を目的としたミラー登録につい
て述べたが、これ以外にも、登録済みビデオファイルの
物理ファイル１０のバックアップメディア生成を目的と
したミラー登録を説明する。実施の形態１で行っていた
図１０のＳ４０２のミラー先サーバ決定処理、詳細は図
９のＳ３０１〜Ｓ３１１の処理を、ターゲットとなるミ
ラー先サーバとしてライブラリサーバを指定するように
すると、Ｓ３１０，Ｓ３１１の処理のみ行えばミラー登
録ができる。但し、バックアップメディア生成のみが目
的で、配信要求集中時の負荷分散は目的としないミラー
登録処理であれば、更に、図１０のＳ４０７，Ｓ４０８
のデータベースへの属性登録は行わないようにすればよ
い。

【００５４】また、物理ファイルだけでなく、それらに
付随するデータベースに登録済みの属性レコード（論理
ファイル管理テーブル１８及び物理ファイル管理テーブ
ル１９の該当レコード）を、システムで使用しているＤ
ＢＭＳ製品が提供するデータファイルによるレコード投
入プログラムで使用可能なファイル形式で別ファイルと
して同じＭＯメディアに出力すれば、より完全なバック
アップデータを取得できる。

【００５５】実施の形態７．実施の形態１では、登録要
求ビデオファイルとしてディジタル圧縮（即ち、エンコ
ード）済みファイルを使用する場合を説明したが、図１
のシステムで、クライアント３，４，５のいずれかに２
７のエンコーダを接続して、ビデオデッキで録画したエ
ンコード済みでないアナログ映像などもリアルタイムに
エンコードしながら、そのクライアントから回線経由で
ビデオサーバ、或いは、ライブラリサーバにファイル登
録を行える。この場合、図５のファイル登録処理の一
部、つまり、図５のＳ２０４またはＳ２１０とＳ２０６
の間に、図１１の処理を行うように変更して実現でき
る。

【００５６】図１１は、本実施の形態で行うファイルコ
ピーに関する処理フローを示した図である。この処理
は、運用管理プログラム１７で行うＳ５０１，Ｓ５０２
及びＳ５０４〜Ｓ５０９の処理の部分と、エンコーダ２
７によって実行するＳ５０３の処理の部分から構成され
る。まず、エンコーダ２７から登録する場合、実施の形
態１で説明した図５に示すファイル登録処理のＳ２０４
またはＳ２１０までを、運用管理プログラム１７により
実行する。続いて、エンコーダの生成したディジタル圧
縮したビデオファイルのコピー先とするコピー用一時デ
ィレクトリを生成する。このディレクトリは、例えば、
Ｓ２０３で決定したディレクトリの一階層下に、適当な
名称で生成する（Ｓ５０１）。このとき、コピー先ディ
レクトリをクライアントからアクセスできるように、ネ
ットワーク接続を行い、クライアントに接続に割り当て
たドライブレターを通知して、運用管理プログラムは処
理を終了する（Ｓ５０２）。

【００５７】通知を受けたユーザは、エンコーダ装置に
付属する操作プログラムから登録要求ビデオファイルの
出力先に、通知されたドライブ名、その直下のディレク
トリに所定のファイル名を指定し、エンコード処理を開
始する（Ｓ５０３）。その結果、出力ファイルが回線を
経由して、登録先サーバ上のコピー用一時ディレクトリ
上に所定のファイル名で生成される。このとき、使用す
るファイル名は、システムで予めエンコーダ登録用に固
有のファイル名を設定しておき、これを使用する。運用
管理プログラムがＳ２０３で決定したファイル名を通知
して、それを使用するようにしても構わないが、固定名
の方が、ユーザはエンコーダ登録時に毎回同じ名称を使
用できるので操作しやすい。

【００５８】Ｓ５０２にエンコードが終了したら、再び
運用管理プログラム１７から残りのファイル登録処理を
行う。まず、コピー用一時ディレクトリに、所定名称の
ファイルが存在するかどうかをチェックする（Ｓ５０
４）。存在しない場合は、コピー用の一時ディレクトリ
を削除し（Ｓ５０７）、ネットワーク接続を解除して
（Ｓ５１０）、プログラムを終了する（Ｓ５０７）。存
在する場合は、Ｓ２０３で決定した本来の格納ディレク
トリにコピーしたファイルを移動し（Ｓ５０５）、成否
を確認する（Ｓ５０６）。ファイルが移動されていない
場合は、コピー用一時ディレクトリを削除し（Ｓ５０
７）、ネットワーク接続を解除して（Ｓ５１０）、プロ
グラムを終了する。このとき、エンコーダでコピーした
ファイルも一緒に削除される。移動に成功した場合は、
コピー用一時ディレクトリの削除（Ｓ５０８）、ネット
ワーク接続の解除（Ｓ５０９）を行い、図５のＳ２０６
以下の処理を続け、実施の形態１と同様の残りのビデオ
ファイル登録処理を行う。

【００５９】実施の形態８．実施の形態１のシステムに
おいて、図１中のライブラリサーバ８に接続されたＭＯ
などの二次記憶装置（物理ファイル）１０ｂ上に格納さ
れたオリジナルビデオファイルの登録について述べる。
予め利用頻度が低いことが予想されるなどの理由で、ラ
イブラリサーバに直接ビデオファイルを登録したい場合
や、ビデオファイルがＭＯに格納した状態で供給される
場合などに有効である。実施の形態１では、ファイルコ
ピーは、クライアント上のＣＤ−ＲＯＭ、ハードディス
ク装置などのメディアから登録することを想定した例で
あり、クライアントとビデオサーバまたはライブラリサ
ーバを接続する回線を経由して、コピーする必要があ
る。しかし、例えば、ファイルの利用頻度が低いと想定
できるビデオファイルは、ハードディスクよりもアクセ
スが低速だが大容量のファイルを安価に格納でき、ビデ
オ入力読み取り可能な二次記憶装置を持つライブラリサ
ーバに登録すれば、資源の有効利用が図れる。登録要求
ビデオファイルの入ったＭＯをクライアントから別途ラ
イブラリサーバのある場所に送って、この送られたＭＯ
をライブラリサーバにセットして読み取る。運用管理プ
ログラム１７で管理するための図６のＳ２０３で決定す
る所定のディレクトリに、ライブラリサーバ内でコピ
ー、或いは、移動する処理を行うようにするれば、クラ
イアントと登録先サーバ間のネットワークを介さずに、
この処理が行える。

【００６０】この処理を実現するためには、図６のビデ
オファイル登録処理のＳ２０１の登録先サーバ選択部分
を、ユーザが指定したサーバを登録先に設定する処理に
変更する。或いは、登録先を特定しないビデオファイル
登録でライブラリサーバと決定した場合に、実施の形態
７のエンコーダを起動させる代わりに、登録要求ビデオ
ファイルの入ったＭＯまたはライブラリサーバ上のハー
ドディスクのボリュームと、一時ディレクトリに対応す
るＭＯの存在するボリューム双方にアクセスできるよう
にネットワーク接続を行い、ライブラリサーバ内でのコ
ピー実行とし、以後、同様の処理を行う。実施の形態１
に示すようなクライアントのＣＤ−ＲＯＭ、或いは、ハ
ードディスク装置からのビデオファイル登録の場合は、
回線を使用したファイル転送のため、ネットワーク負荷
が発生し、また、バンド幅の管理が必要で処理に時間が
かかる。本実施の形態に示すような登録手順とすること
で、同一マシン内での移動、コピー処理になるので回線
は使用せず、バンド幅管理の必要がないファイル操作と
して処理できる。ネットワークのトラフィックを発生さ
せずに、より高速なファイル操作により、処理速度の向
上を図ることができる。

【００６１】実施の形態９．実施の形態１のシステムに
おいて、図１中のビデオサーバ１または２のハードディ
スク装置上に格納されたビデオファイルの登録について
述べる。実施の形態１では、ファイルコピーはクライア
ント上のＣＤ−ＲＯＭ、ハードディスク装置などのメデ
ィアから登録することを想定しており、クライアントと
ビデオサーバまたはライブラリサーバを接続する回線を
経由して、コピーする必要がある。しかし、例えば、ビ
デオファイルを特定のビデオサーバに登録したい場合
で、オリジナルのメディアもビデオファイルを収容する
ビデオサーバと同じサーバ上にあり、それを同じサーバ
である登録先ビデオサーバのハードディスク上にコピー
する場合、登録先ビデオサーバ上のファイルコピーとし
て処理した方がよい。こうすれば、クライアントと登録
先サーバ間のネットワークを介さずに処理をするので、
ネットワーク負荷が発生せず、コピー処理もバンド幅管
理が必要なく、ファイル操作として処理するので高速化
できる。登録要求ビデオファイルを登録先としたいビデ
オサーバのハードディスク上の適当なディレクトリにコ
ピーし、運用管理プログラム１７で管理するためのＳ２
０３で決定する所定のディレクトリにライブラリサーバ
内でコピー、或いは、移動する処理を行うようにすれ
ば、クライアントと登録先サーバ間のネットワークを介
さずに処理が行える。

【００６２】これを実現するためには、図５のビデオフ
ァイル登録処理のＳ２０１の登録先サーバ選択部分を、
ユーザが指定したサーバを登録先に設定する処理に変更
する。つまり、図６の処理は行わない。そして、実施の
形態６のエンコーダを起動させる代わりに、登録要求ビ
デオファイルを格納するビデオサーバのハードディスク
装置のボリュームと、一時ディレクトリに対応する同一
ビデオサーバの登録先ディレクトリの存在するボリュー
ム双方にアクセスできるようにネットワーク接続を行
い、そのビデオサーバ内でのコピー実行とし、以後、同
様の処理を行う。

【００６３】実施の形態１に示すようなクライアントの
ＣＤ−ＲＯＭ、或いは、ハードディスク装置からのビデ
オファイルの登録の場合は、回線を使用したファイルの
転送のため、ネットワーク負荷が発生し、また、バンド
幅の管理が必要で処理に時間がかかる。実施の形態８と
同様に、本実施の形態における登録手順を採用すれば、
同一マシン内での移動、コピー処理になるので、回線を
使用せず、バンド幅管理を必要としないファイル操作と
して処理できる。ネットワークのトラフィックを発生さ
せず、より高速なファイル操作で処理速度の向上を図る
ことができる。また更に、上記において、オリジナルの
メディアがエンコードされていない情報の場合、同一の
サーバにエンコーダ２７を接続してエンコード後のビデ
オファイルをビデオサーバに登録してもよい。図１で
は、同一のビデオサーバとして、ライブラリサーバ８を
用いた場合のシステム構成を示している。

【００６４】

【発明の効果】以上のように、この発明によれば、管理
テーブルと情報テーブルを持つコントロール・サーバを
備えて集中管理するようにしたので、マルチメディア・
サーバシステムに接続されたビデオサーバの配信負荷を
平均化し、特定のビデオファイルに配信、登録要求が集
中することを抑制して、マルチメディア・サーバシステ
ムの能力を最大限に活かし、かつ、システム資源を有効
に利用できる効果がある。

【００６５】また更に、所定時間単位のアクセス実績で
ビデオサーバを選ぶようにしたので、平均化できる効果
がある。

【００６６】また更に、アクセス履歴を用いるようにし
たので、その頻度によりファイル・アクセス処理速度が
高速なビデオサーバへと、またはファイル・アクセス処
理速度が低速なライブラリサーバの二次記憶媒体へと、
登録先サーバを選択して、より円滑なサービスが得られ
て資源の有効利用ができる効果がある。

【００６７】また更に、ミラー・ファイルを設けて登録
を行うようにしたので、作業効率を向上できると共に、
クライアントからのアクセスのサービスも向上できる効
果もある。

【００６８】また更に、ビデオサーバの台数に関係な
く、ユーザにビデオファイル登録及びミラー・ファイル
の物理ファイルの格納位置を意識せずに、登録配信がで
きるようにしたので、登録時の負担を軽減する効果があ
る。

【００６９】また更に、エンコーダを設けたので、エン
コード処理を事前に行わない場合でも最適なビデオサー
バを選択して登録でき、作業を効率化できる効果があ
る。

【００７０】また更に、ビデオサーバまたはライブラリ
サーバにビデオ読み取り装置を備えて、ビデオファイル
登録を同一サーバ内でのローカルなファイルコピーで行
えるようにしたので、ネットワークのトラフィックの低
減、登録処理の高速化ができる効果がある。

【図面の簡単な説明】

【図１】 この発明によるマルチメディア配信運用管理
システムの例を示した構成図である。

【図２】 この発明のシステムにおけるビデオファイル
登録決定までの要素と処理の関係を示した図である。

【図３】 図２のビデオサーバ管理テーブルの例を示す
図である。

【図４】 図２のボリューム管理テーブルの例を示す図
である。

【図５】 図２の運用管理プログラムが行う登録先サー
バ選択処理の動作フローチャート図である。

【図６】 図２の運用管理プログラムが行うビデオファ
イル登録処理のフローチャート図である。

【図７】 図２の物理ファイル管理テーブルの例を示す
図である。

【図８】 図２の論理ファイル管理テーブルの例を示す
図である。

【図９】 この発明の実施の形態２におけるミラー・フ
ァイル登録処理の一部であるミラー先サーバ選択処理の
フローチャート図である。

【図１０】 実施の形態２におけるミラー・ファイル登
録処理のフローチャート図である。

【図１１】 この発明の実施の形態７におけるエンコー
ダからのビデオファイル登録処理のフローチャート図で
ある。

【図１２】 従来のビデオサーバシステムのハードウェ
ア構成図である。

【図１３】 他の従来例であるファイル・アロケーショ
ン位置決定システムの構成図である。

【符号の説明】

１ ビデオサーバ、２ ビデオサーバ、３ クライアン
ト、４ クライアント、５ クライアント、６ ネット
ワーク、７ コントロール・サーバ、８ ライブラリサ
ーバ、９ データベース、１０ 物理ファイル、１０ｂ
二次記憶装置（物理ファイル）、１１ 入力情報（例
えば、クライアントからの登録要求またはミラー同時実
行登録要求）、１２ ビデオサーバ情報テーブル、１３
ビデオサーバ管理テーブル、１４ ボリューム管理テ
ーブル、１５ データベース・アクセスモジュール、１
６ 決定情報（ビデオサーバを一意に決定）、１７ 運
用管理プログラム、１８ 論理ファイル管理テーブル、
１９ 物理ファイル管理テーブル、２１ サーバＩＤ、
２２ サーバ名、２３ ビデオサーバの最大配信数、２
４ ビデオサーバの最大バンド幅、２５ ビデオサーバ
の総ディスク容量、２６ ビデオサーバの同一ファイル
最大配信数、２７ エンコーダ、２８ ビデオ読み取り
装置、３１ ボリュームＩＤ、３２ ボリュームを接続
しているサーバのサーバＩＤ、３３ ボリューム名、３
４ ボリュームの最大同時配信数、３５ ボリュームの
最大バンド幅、３６ ボリュームの最大ディスク容量、
３７ボリュームに割り当てられているドライブレター、
４１ 論理ファイルＩＤ、４２ ビデオファイルの格納
先ボリュームＩＤ、４３ ビデオファイルの格納先フル
パスファイル名、５１ 論理ファイルＩＤ、５２ 論理
ファイルの格納先ディレクトリ名、５３ 論理ファイル
の格納先ファイル名、５４ 論理ファイルのファイルサ
イズ、５５ 論理ファイルの必要バンド幅、５６ 論理
ファイルが有するファイル数、６１ アロケーション情
報ファイル、６２ ファイル・アクセス情報ファイル、
６３ システム本体、６４ 新規ファイル情報ファイ
ル、６５新規ファイル・アロケーション・ディスク決定
情報出力手段。

Claims (11)

【特許請求の範囲】
1. 【請求項１】 ビデオ情報を大容量メモリ上に蓄積して
   通信回線に接続された複数のクライアントに配信を行う
   ビデオサーバを複数個接続するシステム構成において、 上記ビデオサーバが持つ各ビデオファイルの容量と速度
   を含む属性情報を記憶する管理テーブルと、クライアン
   トからのアクセス履歴を記憶する情報テーブルとを設け
   て、上記管理テーブルと情報テーブルを参照してクライ
   アントからの新規ビデオファイルの上記ビデオサーバへ
   の登録を行うコントロール・サーバを備えたことを特徴
   とするマルチメディア配信運用管理システム。
2. 【請求項２】 情報テーブル中のアクセス履歴には、所
   定の時間単位でのアクセス実績を記憶するようにし、新
   規ビデオファイルのビデオサーバへの登録に際して上記
   アクセス実績の少ないビデオサーバを選択するようにし
   たことを特徴とする請求項１記載のマルチメディア配信
   運用管理システム。
3. 【請求項３】 情報テーブルにビデオサーバのサービス
   予定時間の欄を設けて、新規ビデオファイルのビデオサ
   ーバへの登録に際して上記サービス予定時間を参照し
   て、負荷が少ないビデオサーバを選択するようにしたこ
   とを特徴とする請求項２記載のマルチメディア配信運用
   管理システム。
4. 【請求項４】 ビデオサーバのビデオ情報に対して相対
   的に大容量ビデオ情報を蓄積してクライアントに配信を
   行うライブラリサーバを備えて、 ビデオサーバに登録不可のビデオファイルを登録するよ
   うにしたことを特徴とする請求項１記載のマルチメディ
   ア配信運用管理システム。
5. 【請求項５】 情報テーブル中のアクセス履歴には、所
   定の時間単位でのアクセス実績を記憶するようにし、ビ
   デオファイルの登録に際して上記アクセス実績の少ない
   場合はライブラリサーバに登録するようにしたことを特
   徴とする請求項４記載のマルチメディア配信運用管理シ
   ステム。
6. 【請求項６】 コントロール・サーバの管理テーブルに
   は、元のビデオファイルからコピーをして同じ複数のビ
   デオファイルを生成するミラー・ファイルの管理の欄を
   設け、ミラー・ファイルの管理も行うようにしたことを
   特徴とする請求項１記載のマルチメディア配信運用管理
   システム。
7. 【請求項７】 コントロール・サーバの情報テーブル中
   にあるアクセス記録より、負荷量が低いかまたは空き容
   量が大きいビデオサーバを選択してミラー・ファイルを
   生成するようにしたことを特徴とする請求項６記載のマ
   ルチメディア配信運用管理システム。
8. 【請求項８】 ビデオサーバのビデオ情報に対して相対
   的に大容量ビデオ情報を蓄積してクライアントに配信を
   行うライブラリサーバを備えて、 バックアップとしてミラー・ファイルを指定すると、上
   記ライブラリサーバにミラー・ファイルを生成するよう
   にしたことを特徴とする請求項６記載のマルチメディア
   配信運用管理システム。
9. 【請求項９】 クライアントにはビデオ信号を圧縮する
   エンコーダを設けて、ビデオファイルの登録に際して上
   記エンコーダでエンコードした信号を登録するようにし
   たことを特徴とする請求項１記載のマルチメディア配信
   運用管理システム。
10. 【請求項１０】 ビデオサーバまたはライブラリサーバ
    にはビデオ入力読み取り装置を備えて、 ビデオファイルの登録を指定されると、該指定のビデオ
    ファイルが上記ビデオ入力読み取り装置の入力にあると
    該入力を読みとるようにしたことを特徴とする請求項１
    または請求項４記載のマルチメディア配信運用管理シス
    テム。
11. 【請求項１１】 ビデオサーバまたはライブラリサーバ
    にはビデオ信号を圧縮するエンコーダを設けて、読み取
    り装置からのビデオファイルの登録に際して上記エンコ
    ーダでエンコードした信号を登録するようにしたことを
    特徴とする請求項１０記載のマルチメディア配信運用管
    理システム。