JP5753999B2 - 端末装置、データ処理プログラム、及びデータ管理システム - Google Patents

Description

本発明は、端末装置、データ処理プログラム、サーバ装置及びデータ管理システムに関する。

従来、例えば映像制作システムにおいて、映像・音声素材（以下、素材データという。）と、当該素材データを一意に識別する識別データと、を対応づけて保存した記録媒体を装着した光ディスク装置から、指定された識別データが識別する素材データを読み出してコンピュータへ送信する技術が開示されている（特許文献１参照）。

特許文献１の技術は、識別データに対応するアクセスパスを通じて、光ディスク装置に装着された記録媒体の素材データにアクセスすることにより、当該記録媒体から所望の素材データを入手して、前記コンピュータへ直接提供する。

また、素材データを一意に同定する識別データと、ネットワークに接続されたサイトを検索するためのアクセス情報と、を関連付けて、当該識別データを手掛かりとして当該素材データに関連する更なる付加情報を容易に検索する技術が開示されている（特許文献２参照）。

特許文献２の技術は、例えば当該素材データが人物を撮影した映像データであった場合にその人物のプロフィールや過去の活動履歴といった情報を当該付加情報として提供することで、素材データのさらなる有効活用を図っている。

特許第３６３７９１０号公報 特開２００２−２９７６２８号公報

特許文献１の技術は、識別データが同定する素材データを直接入手することができる。しかし、素材データは、容易に複製可能であると共に、様々なデータ圧縮方式や様々なファイル形式（ファイルラッパー方式）を伴って複数の素材サーバに格納可能である。このため、１つの識別データによって同定される素材データが複数の素材サーバにそれぞれ格納されている状況においては、特許文献１の技術では、複数の素材サーバから複数の素材データを一度にダウンロードしてしまう。このため、必要な素材データだけでなく余分な素材データも併せてダウンロードすることになり、システム負荷が過大になる問題がある。

特許文献２の技術は、当該識別データを手掛かりにして当該識別データが同定する素材データに関連する付加情報を取得できるものの、当該識別データが同定する素材データ自体を入手する方法は提供していない。これは、特許文献２の技術が、素材データが手元にあることを前提に、そこから当該識別データを抽出し、それを手掛かりにして当該素材データに関連する付加情報を入手する方法を提供するといった技術的思想に基づくことによる。

本発明は、このような実情を鑑みて提案されたものであり、１つ以上のデータ格納装置にビットストリームが様々な実体を伴った１つ以上の格納データとしてそれぞれ格納されている場合であっても、所望のビットストリームの格納時の実体である格納データを容易に取得できる端末装置、データ処理プログラム、サーバ装置及びデータ管理システムを提供することを目的とする。

本発明に係る端末装置は、１つ以上のデータ格納装置に一意のビットストリームの格納時の実体である１つ以上の格納データがそれぞれ異なる形態で格納されている場合に、前記一意のビットストリームを復元できる格納データのすべてを同定するための識別データをサーバ装置へ送信する送信手段と、前記送信手段により送信された前記識別データが示す一意のビットストリームの使用時の特徴を示すビットストリーム使用時特徴情報と、前記識別データが示す前記一意のビットストリームを復元できる１つ以上の格納データの各々の実体的特徴を示す格納データ実体情報と、を前記サーバ装置から受信する受信手段と、前記ビットストリーム使用時特徴情報は前記ビットストリームの使用時の品質情報を含み、前記格納データ実体情報は前記ビットストリームのデータ圧縮方式情報を含み、前記受信手段により受信された前記ビットストリーム使用時特徴情報に含まれる品質情報が所定の範囲内でない場合は、前記品質情報が前記所定の範囲内でないと判定された時点で前記識別データによって同定されるいかなる格納データも取得しないと判定し、前記受信手段により受信された前記品質情報が前記所定の範囲内である場合は、前記受信手段により受信された前記格納データ実体情報に含まれるデータ圧縮方式情報が少なくとも１つの所定のデータ圧縮方式情報に一致するときに、前記一致する所定のデータ圧縮方式情報を含む格納データ実体情報に対応する格納データを、前記データ格納装置から取得すると判定する判定手段と、を備えている。

本発明に係るデータ処理プログラムは、コンピュータを前記端末装置の各手段として機能させるためのプログラムである。

本発明に係るサーバ装置は、１つ以上のデータ格納装置に１つ以上の格納データがそれぞれ格納されている場合に、一意のビットストリームを復元できる格納データのすべてを同定するための識別データと、前記識別データが示す一意のビットストリームの使用時の特徴を示すものであって前記ビットストリームの使用時の品質情報を含むビットストリーム使用時特徴情報と、前記識別データが示す一意のビットストリームを復元できる１つ以上の格納データの各々の実体的特徴を示すものであって前記ビットストリームのデータ圧縮方式情報を含む格納データ実体情報と、を対応付けて記憶する記憶手段と、前記端末装置から送信された識別データを受信する受信手段と、前記受信手段により受信された識別データに対応するビットストリーム使用時特徴情報及び格納データ毎の格納データ実体情報を前記記憶手段から読み出し、読み出した前記ビットストリーム使用時特徴情報及び前記１つ以上の格納データ毎の格納データ実体情報を前記端末装置へ送信する送信手段と、を備えている。
本発明に係るデータ管理システムは、一意のビットストリームの格納時の実体である１つ以上の格納データがそれぞれ異なる形態で格納された１つ以上のデータ格納装置と、前記端末装置と、前記サーバ装置と、を備えている。

本発明は、１つ以上のデータ格納装置にデジタル資産の格納時の実体である１つ以上の格納データがそれぞれ格納されている場合に、所望のデジタル資産の格納時の実体である格納データを容易に取得可能にする。

本発明の第１実施形態に係る素材ファイル管理システムの構成を示す図である。 ＵＭＩＤのフォーマット構成を示す図である。 クライアント端末の構成を示すブロック図である。 ＵＭＩＤネームサーバの構成を示すブロック図である。 クライアント端末による問い合わせ処理ルーチンを示すフローチャートである。 第２実施形態に係る素材ファイル管理システムの構成を示す図である。 クライアント端末による問い合わせ処理ルーチンを示すフローチャートである。

以下、本発明を実施するための形態について詳細に説明する。
［第１実施形態］
図１は、本発明の第１実施形態に係る素材ファイル管理システム１の構成を示す図である。素材ファイル管理システム１は、素材データをファイルとして取り扱う映像制作システムから素材ファイルの生成、保存、検索、利用に関わる部分を抽出したものである。

ここで素材ファイルは、当該素材ファイルを再生した時のビットストリームの格納時の実体である格納データであり、再生時ビットストリームを所定のデータ圧縮方式で圧縮して格納したファイルでもよいし、再生時ビットストリームをそのまま格納したファイルでもよい。本実施形態では、素材ファイルとして、放送・映像メディア業界に特有の要求仕様を満足する統一フォーマット規格であるＭＸＦ（Ｍａｔｅｒｉａｌ ｅＸｃｈａｎｇｅ Ｆｏｒｍａｔ）に基づいた素材ファイルを例に挙げて説明する。

素材ファイル管理システム１は、具体的には、映像編集時などにおいてユーザの操作に応じて所望の素材ファイルの有無を問い合わせ入手する等を行うクライアント端末１０と、所望の素材ファイルを検索するための当該素材ファイルの内容に関するメタデータなどを記憶するメタデータ記憶装置２０と、本システム１内の各素材ファイルに対する識別データと、当該素材ファイルに関する基本技術属性とを一元管理するＵＭＩＤネームサーバ３０と、を備えている。

基本技術属性は、素材ファイルを再生した時のビットストリームの特徴を示す情報であるファイル再生時情報（ビットストリーム使用時特徴情報）と、再生時ビットストリームの格納時の実体である素材ファイルの実体的特徴を示すファイル実体情報（格納データ実体情報）と、を有する。

ファイル再生時情報は、素材ファイルの実体如何に関わらずそれを再生した時のビットストリームの特徴を示す情報であって、例えば、再生時間長、表示画角、フレームレート、フレームアスペクト比、ピクセルサンプル深さ、ピクセルレイアウト、色サブサンプリング、オーディオチャネル数などが該当する。本実施形態では、主に、“ｄｕｒ”（再生時間長）、“ｄｅｐｔｈ”（ピクセルサンプル深さ）、“ｓａｍｐｌｅ”（色サブサンプリング比）を使用する。

ファイル実体情報は、再生時ビットストリームの格納時の実体である素材ファイルの実体的特徴を示す情報であって、データ圧縮方式、ファイルラッパー方式（ファイル形式）、ファイルサイズ、素材ファイルの格納場所などが該当する。本実施形態では、主に、“ｕｒｌ”（素材ファイルの格納場所）、“ｃｏｄｅｃ”（データ圧縮方式）、“ｗｒａｐｐｅｒ”（ファイルラッパー方式）を使用する。

さらに、図１に示すように、素材ファイル管理システム１は、外部から提供される映像信号を受けて素材ファイルを生成する収録サーバ４０と、映像編集などのために必要とされる素材ファイルを一時的に記憶するニアライン素材サーバ５０と、送出用（オンエア用）の素材ファイルを記憶して映像送出をおこなう送出サーバ６０と、長期保存用の素材ファイルを記憶するアーカイブ装置７０と、を備えている。

収録サーバ４０、ニアライン素材サーバ５０、送出サーバ６０、及びアーカイブ装置７０は、素材ファイルを記憶するという点では共通しており、いわゆる素材サーバと呼ばれるものである。

メタデータ記憶装置２０に含まれる、素材ファイルの内容などに関するメタデータには、当該映像素材ファイルの撮影日時や場所などに加え、タイトルや概要などその内容に関する情報も含んでいる。特に、内容に関する情報は、例えば野球映像のホームランシーンなどある特定内容を撮影した部分に対して、「ホームランシーン」であることを示すテキストデータとフレームのタイムコード（素材ファイルの各フレームに付与されたｈｈ：ｍｍ：ｓｓ：ｆｆ形式のラベル情報）との組み合わせ情報なども含んでいる。

すべての素材ファイルには、再生した時のビットストリームを一意に同定するために、放送・映像メディア業界の標準固有素材識別子であるＵＭＩＤ（Ｕｎｉｑｕｅ Ｍａｔｅｒｉａｌ ＩＤｅｎｔｉｆｉｅｒ）が付与されている。なお、ＵＭＩＤはＭＸＦの必須項目として規定されている。

図２は、ＵＭＩＤのフォーマットの構成を示す図である。ＵＭＩＤは、４つのフィールドで構成されたデータであり、「ユニバーサルラベル」、「長さ」、「インスタンス番号」、「素材番号」を有している。

「ユニバーサルラベル」は、このバイト列がＵＭＩＤであることを示す識別情報である。「ユニバーサルラベル」の先頭１０バイトは固定値、続く１１バイト目及び１２バイト目は当該ＵＭＩＤが同定する素材ファイルの種類、当該ＵＭＩＤの生成方法に依存する値である。
「長さ」は、当該フィールドに続くフィールドの総バイト長を示し、１３ｈなる固定値である。「インスタンス番号」は、当該ＵＭＩＤが同定する素材ファイルが大域的一意に同定すべきオリジナル素材か、オリジナル素材から二次的に生成された派生素材かを区別するフィールドであって、前者の場合はゼロ、後者の場合は非ゼロとなる。

「素材番号」は、大域的な一意性が保証された１６バイトの値である。ＵＭＩＤは、この「素材番号」によって大域的に一意な固有素材識別子として成立する。「素材番号」は、例えば、当該ＵＭＩＤが同定する素材ファイルが生成された時刻と当該素材ファイルを生成した映像制作機器のＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）アドレスとの組み合わせにより構成される。「素材番号」は、上述の構成に限定されるものではなく、大域的な一意性が保証されていれば他の構成方法でもよい。

ここで、再生時のビットストリームが同一になる素材ファイルに対しては、同一のＵＭＩＤが付与される。このため、再生時のビットストリームが同一であれば、データ圧縮方式がそれぞれ異なる複数の素材ファイルに対しても、同一のＵＭＩＤが付与される。

一方、素材ファイルの再生時のビットストリーム（例えば、ビットレート、ピクセル数、アスペクト比など）が異なる場合には、仮にデータ圧縮方式が同一であったとしても、それぞれの素材ファイルには異なるＵＭＩＤが付与される。つまり厳密には、ＵＭＩＤは、それらのデータ圧縮方式などに関係なく、再生時のビットストリームを大域的一意に同定するといった役割をもつ。

図３は、クライアント端末１０の構成を示すブロック図である。クライアント端末１０は、ユーザの操作情報を入力する入力部１１、データを一時的に記憶するＲＡＭ１２、コンピュータプログラムが予め記憶されたＲＯＭ１３、前記コンピュータプログラムに従って当該クライアント端末１０のすべての処理を実行するＣＰＵ１４、データを記憶するハードディスクドライブ（ＨＤＤ）１５、入力・処理された情報をユーザに表示する表示部１６、データの送受信を行う通信部１７を有する。

入力部１１は、例えばキーボード、ポインティングデバイスなどが該当し、ユーザの操作情報を入力する。例えば、入力部１１は、表示部１６に表示された情報の中から所望の情報を選択・指示するための情報を入力する。ＣＰＵ１４は、ＲＯＭ１３に記憶されたコンピュータプログラムに従って、後述する図５の各ステップを実行する。

表示部１６には、ＣＰＵ１４の処理状況に応じた画面が表示される。また、表示部１６には、ユーザに選択・指示を促すための画面も表示される。このとき、ユーザは、入力部１１を操作することで、表示部１６に表示されたものの中から所望のものを選択できる。通信部１７は、素材ファイル管理システム１内の各デバイスと通信可能になっており、ＣＰＵ１４の実行指示に従って、データの送受信を実行する。

クライアント端末１０には、所定のアプリケーションがインストールされている。クライアント端末１０は、ユーザの操作・指示に応じた処理を実行する。例えば、クライアント端末１０は、ＵＭＩＤネームサーバ３０に対して所望の再生時ビットストリームを取得するために必要な素材ファイルの問い合わせを行い、ＵＭＩＤネームサーバ３０から問い合わせに対する回答を受信する。そして、クライアント端末１０は、受信した回答に基づいて素材ファイルを実際に入手すべきと判断した場合には、当該回答に含まれる素材ファイルの格納場所（ＵＲＬ）にアクセスして素材ファイルを入手する。

メタデータ記憶装置２０は、所望の素材ファイルを検索するための素材ファイルの内容などに関するメタデータを記憶している。当該メタデータは、例えば、素材ファイルに付与され当該素材ファイルを大域的一意に同定するＵＭＩＤと、素材の内容に関するテキスト注釈（例えば「ホームランシーン」など）と、当該ＵＭＩＤが同定する素材ファイル内において、当該テキスト注釈が関連付けられたフレームの位置情報（タイムコード）と、を有するデータである。各メタデータはＵＭＩＤを含んでいるため、当該メタデータは、当該ＵＭＩＤによって、それが同定する素材ファイルに一意に関連付けられる。

素材ファイルは、例えば、収録サーバ４０、ニアライン素材サーバ５０、送出サーバ６０、アーカイブ装置７０にそれぞれ格納されている場合でも、再生時ビットストリームが同一であれば同一のＵＭＩＤが付与され、再生時ビットストリームが同一でなければ異なるＵＭＩＤが付与されている。

ＵＭＩＤネームサーバ３０は、素材ファイル管理システム１の各素材サーバに記憶されているすべての素材ファイルに関する情報を記憶する。ＵＭＩＤネームサーバ３０は、具体的には、本システム１内に存在するすべての素材ファイルに関して、当該素材ファイルのＵＭＩＤと当該素材ファイルの基本技術属性を記憶する。

図４は、ＵＭＩＤネームサーバ３０の構成を示すブロック図である。ＵＭＩＤネームサーバ３０は、ユーザの操作情報を入力する入力部３１、データを一時的に記憶するＲＡＭ３２、コンピュータプログラムが予め記憶されたＲＯＭ３３、前記コンピュータプログラムに従って当該ＵＭＩＤネームサーバ３０のすべての処理を実行するＣＰＵ３４、データを記憶するＨＤＤ３５、データの送受信を行う通信部３６を有する。

また、ＵＭＩＤネームサーバ３０は、いわゆるＤＮＳネームサーバと同じ機能を有しており、ダイナミックＤＮＳ機能による新たな情報の登録や、ＤＮＳクエリ機能による問い合わせが可能である。このため、ＨＤＤ３５には、ダイナミックＤＮＳ機能により登録された情報が記憶されている。

そしてクライアント端末１０から、通信部３６を介して、任意のＵＭＩＤに関する問い合わせを受けると、ＣＰＵ３４は、クライアント端末１０に対する回答として、そのＵＭＩＤに対応するＵＲＬを含む基本技術属性をＤＮＳレスポンスとして返信する。

ここで、問い合わせのあったＵＭＩＤに対応する素材ファイルが複数存在した場合、各素材ファイルのファイル再生時情報は共通するものの、ＵＲＬを含むそれらのファイル実体情報は異なる。このため、ＣＰＵ３４は、クライアント端末１０への回答として、再生時のビットストリームの特徴を示すと共に各素材ファイルに共通する情報であるファイル再生時情報と、各素材ファイルの実体的特徴を示すファイル実体情報と、を分離して送信する。

これにより、クライアント端末１０は、問い合わせをしたＵＭＩＤが一意に同定する再生時ビットストリームが再生時にはどのような特徴を有するのかに加え、当該再生時ビットストリームの格納時の実体である各素材ファイルがどの場所にどのような状態（データ圧縮方式、ファイル形式など）でそれぞれ保存されているかを把握できる。

［素材ファイルの登録］
以上のように構成された素材ファイル管理システム１では、ビデオカメラによって新たな映像信号が生成された場合、当該映像信号は素材ファイルとして次のように保存、登録される。

いま、素材ファイル管理システム１全体がｅｘａｍｐｌｅ．ｏｒｇなるドメインに属すると仮定する。収録サーバ４０（ｉｎｇＳｒｖ）は、ビデオカメラから映像信号を受信すると、それを大域的一意に同定するためのＵＭＩＤ（例えば“０６０Ａ２Ｂ３４・・・０Ｄ２０・・・ＢＦＤＦ”）を生成する。そして、収録サーバ４０は、当該映像信号を、“ｆｉｌｅ５．ｍｘｆ”なるファイル名を有するＭＸＦファイルとして、当該ＵＭＩＤを付与した上で所定のディレクトリ（／２０１３０８３１／ｓｐｏｒｔｓ）に保存する。

収録サーバ４０は、当該素材ファイルの新規生成を検出すると、その旨をＵＭＩＤネームサーバ３０に登録する。具体的には、収録サーバ４０は、当該素材ファイルに付与されたＵＭＩＤと同素材ファイルに関するファイル再生時情報とを組み合わせたもの、及び当該ＵＭＩＤと同素材ファイルに関するファイル実体情報とを組み合わせたものを、順に、ダイナミックＤＮＳ機能を用いて、ＵＭＩＤネームサーバ３０へ登録する。

ここでは最初に、収録サーバ４０は、ＵＭＩＤの固定値部分を省略したものにサービス種（＿ｕｍｉｄ．＿ｕｄｐ）及び当該収録サーバが属するドメイン名（ｅｘａｍｐｌｅ．ｏｒｇ）を付与することによって、ＵＭＩＤをドメイン表記ＵＭＩＤ（０Ｄ２０…ＢＦＤＦ．＿ｕｍｉｄ．＿ｕｄｐ．ｅｘａｍｐｌｅ．ｏｒｇ）に変換する。さらに、収録サーバ４０は、当該ドメイン表記ＵＭＩＤと、これに対応したファイル再生時情報としてのｄｕｒ＝６０（６０秒），ｄｅｐｔｈ＝１０（１０ｂｉｔ／ピクセル），ｓａｍｐｌｅ＝４２２（ＹＵＶ４２２）などとを関連付けたテキストレコードを生成し、ダイナミックＤＮＳ機能を用いてこれらをＵＭＩＤネームサーバ３０に登録する。

次に、収録サーバ４０は、上記のドメイン表記ＵＭＩＤと、それに対応したファイル実体情報としてのｃｏｄｅｃ＝ｊ２ｋ（ＪＰＥＧ２０００） ｗｒａｐｐｅｒ＝ｍｘｆ、そしてＵＲＬ＝ｈｔｔｐ：／／ｉｎｇＳｒｖ．ｅｘａｍｐｌｅ．ｏｒｇ／２０１３０８３１／ｓｐｏｒｔｓ／ｆｉｌｅ５．ｍｘｆなどと、を関連付けたテキストレコードを生成し、ダイナミックＤＮＳ機能を用いてこれらをＵＭＩＤネームサーバ３０に登録する。

この後、収録サーバ４０のユーザは、収録サーバ４０の素材ファイルの内容を確認し、その結果をメタデータとして準備する。ユーザは、例えば、当該素材ファイルが野球中継を収録したものであって、ホームランシーンを撮影したものであることを確認の上、その素材ファイルのタイトルや内容概要を、当該素材ファイルの撮影場所や撮影時刻などと併せてメタデータとして準備する。

さらに、ユーザは、当該素材ファイルのタイトル、内容概要に加え、ホームランシーンを捉えたフレームに関し、それを示すテキスト注釈とそのフレームのタイムコードと、をペアにしたものなどをメタデータとして準備する。そして、収録サーバ４０は、ユーザの指示に従って、当該メタデータと、メタデータの記述対象となる素材ファイルのＵＭＩＤとを関連付けた上で、メタデータ記録装置２０に登録する。

他方、収録サーバ４０は、素材ファイル“ｆｉｌｅ５．ｍｘｆ”が近々編集される予定の場合は、さらにバックアップを兼ねて、当該素材ファイルの完全コピー素材を、ニアライン素材サーバ５０（ｍａｔＳｒｖ）の所定のディレクトリ（／ｐｒｏｇｒａｍ１／ｍａｔｅｒｉａｌｓ）に、“ｍａｔ５．ｍｘｆ”なるファイル名を付けて記憶させる。この方法は例えばサーバをまたいだファイルコピー（及びその後のリネーム）あるいはＦＴＰなどによって実施可能である。

ニアライン素材サーバ５０は、当該素材ファイルの新規生成を検出すると、その旨をＵＭＩＤネームサーバ３０に登録する。具体的には、ニアライン素材サーバ５０は、当該素材ファイルに付与されたＵＭＩＤと同素材ファイルに関するファイル再生時情報とを組み合わせたもの、及び当該ＵＭＩＤと同素材ファイルに関するファイル実体情報（素材ファイルのＵＲＬを含む。）とを組み合わせたものを、順に、ダイナミックＤＮＳ機能を用いて、ＵＭＩＤネームサーバ３０へ登録する。

但し、ここで生成された素材ファイル（ｍａｔ５．ｍｘｆ）は元の素材ファイル（ｆｉｌｅ５．ｍｘｆ）の完全コピー素材であり、再生時のビットストリームは完全に一致する。このため、当該素材ファイル（ｍａｔ５．ｍｘｆ）に付与されたＵＭＩＤは、元の素材ファイル（ｆｉｌｅ５．ｍｘｆ）のＵＭＩＤと同じである。

ここでは最初に、ニアライン素材サーバ５０は、ＵＭＩＤをドメイン表記ＵＭＩＤ（０Ｄ２０…ＢＦＤＦ．＿ｕｍｉｄ．＿ｕｄｐ．ｅｘａｍｐｌｅ．ｏｒｇ）に変換する。さらに、ニアライン素材サーバ５０は、当該ドメイン表記ＵＭＩＤと、これに対応したファイル再生時情報としてのｄｕｒ＝６０，ｄｅｐｔｈ＝１０，ｓａｍｐｌｅ＝４２２などとを関連付けたテキストレコードを生成し、ダイナミックＤＮＳ機能を用いてこれらをＵＭＩＤネームサーバ３０に登録する。ここで当該素材ファイルが完全コピー素材であることから、当該ファイル再生時情報は収録サーバ４０の時に登録したものと全く同じである。

次に、ニアライン素材サーバ５０は、上記のドメイン表記ＵＭＩＤと、それに対応したファイル実体情報としてのｃｏｄｅｃ＝ｊ２ｋ ｗｒａｐｐｅｒ＝ｍｘｆ、そしてＵＲＬ＝ｈｔｔｐ：／／ｍａｔＳｒｖ．ｅｘａｍｐｌｅ．ｏｒｇ／ｐｒｏｇｒａｍ１／ｍａｔｅｒｉａｌｓ／ｍａｔ５．ｍｘｆなどと、を関連付けたテキストレコードを生成し、ダイナミックＤＮＳ機能を用いてこれらをＵＭＩＤネームサーバ３０に登録する。ここで、当該素材ファイルは、収録サーバ４０に保存された元の素材ファイルの完全コピー素材である。しかし、各ファイル名及びそれぞれの保存先の素材サーバ（ディレクトリを含む。）が異なることから、各々のファイル実体情報はＵＲＬのみが異なる。

なお、各素材サーバ（収録サーバ４０、ニアライン素材サーバ５０、送出サーバ６０及びアーカイブ装置７０）は、素材ファイルのファイル名、または、素材ファイルの格納場所が変わってそのＵＲＬが変更された場合などでも、ダイナミックＤＮＳ機能により、変更された内容に基づいてＵＭＩＤネームサーバ３０への登録情報を更新する。同様に、各素材サーバは、素材ファイルが削除された場合には、ダイナミックＤＮＳ機能により、当該素材ファイルに対応する登録情報をＵＭＩＤネームサーバ３０から削除する。

この結果、ＵＭＩＤネームサーバ３０は、素材ファイル管理システム１内（ｅｘａｍｐｌｅ．ｏｒｇドメイン下）にあるすべての素材サーバがもつ全ての素材ファイルについて、当該素材ファイルのＵＭＩＤ、格納場所、その他の基本技術属性の最新の状態を常に把握している。

［素材ファイルの検索・入手］
最初に、クライアント端末１０は、メタデータ記憶装置２０に対して、所望の素材ファイル（例えばイチローのホームランシーンを撮影したもの）について問い合わせを行う。クライアント端末１０は、メタデータ記憶装置２０から、上記問い合わせに対する回答として、イチローのホームランシーンを撮影した素材ファイルを一意に同定するＵＭＩＤを入手する。

つぎに、クライアント端末１０は、入手したＵＭＩＤを手掛かりにして、本システム１の各素材サーバに記憶されている様々な素材ファイルの中から、当該ＵＭＩＤが同定する素材ファイルを探し出す。具体的には、クライアント端末１０は、次のステップＳ１以降の処理を実行する。

図５は、クライアント端末１０による問い合わせ処理ルーチンを示すフローチャートである。
ステップＳ１では、クライアント端末１０は、ＵＭＩＤをドメイン表記ＵＭＩＤへ変換する。ここでは、クライアント端末１０は、ＵＭＩＤから先頭の固定値を削除し、ＵＭＩＤの終点に（．＿ｕｍｉｄ．＿ｕｄｐ．ｅｘａｍｐｌｅ．ｏｒｇ）を付加する。なお、（ｅｘａｍｐｌｅ．ｏｒｇ）は、本システム１が属するドメインである。

ステップＳ２では、クライアント端末１０は、ＵＭＩＤネームサーバ３０に対して、ステップＳ１で変換されたドメイン表記ＵＭＩＤを用いて、本システム１に存在する素材ファイルの問い合わせを、ＤＮＳクエリ機能を用いて行う。

一方、ＵＭＩＤネームサーバ３０は、クライアント端末１０からの上記の問い合わせを受けると、その問い合わせに対する回答として、問い合わせのあったＵＭＩＤに対応するファイル再生時情報及びファイル実体情報を、ＤＮＳレスポンス機能を用いてクライアント端末１０へ送信する。

ステップＳ３では、クライアント端末１０は、ＵＭＩＤネームサーバ３０からの回答であるファイル再生時情報及びファイル実体情報をＤＮＳレスポンスとして受信する。
ステップＳ４では、クライアント端末１０は、ＵＭＩＤネームサーバ３０からＤＮＳレスポンスとして受信したファイル再生時情報を参照し、上記ＵＭＩＤが同定する再生時ビットストリームを必要とするか否かを判定する。

例えば、クライアント端末１０は、ｄｅｐｔｈ＝１０、ｓａｍｐｌｅ＝４２２の高画質の再生時ビットストリームを必要とする場合においては、ファイル再生時情報がｄｅｐｔｈ＝８、又は、ｓａｍｐｌｅ＝４２０であるときは、上記ＵＭＩＤが同定する再生時ビットストリームは必要でないと判定する。一方、クライアント端末１０は、ファイル再生時情報がｄｅｐｔｈ＝１０、かつ、ｓａｍｐｌｅ＝４２２であるときは、上記ＵＭＩＤが同定する再生時ビットストリームを必要とすると判定する。
そして、クライアント端末１０は、上記ＵＭＩＤが同定する再生時ビットストリームを必要とすると判定したときはステップＳ５に進み、必要としないと判定したときは処理を終了する。

ステップＳ５では、クライアント端末１０は、ＵＭＩＤネームサーバ３０からＤＮＳレスポンスとして受信したすべてのファイル実体情報を参照し、上記ＵＭＩＤが同定する再生時ビットストリームの格納時の実体であるすべての素材ファイルのうちの少なくとも１つについて、再生可能か否かを判定する。

例えば、クライアント端末１０は、ｃｏｄｅｃ＝ｊ２ｋであってｗｒａｐｐｅｒ＝ｍｘｆの素材ファイルのみ再生可能である場合においては、受信したファイル実体情報がｃｏｄｅｃ＝ｊ２ｋかつｗｒａｐｐｅｒ＝ｍｘｆの条件を満たすときは、当該ファイル実体情報に対応する素材ファイルについて「再生可能」と判定する。一方、クライアント端末１０は、上記条件を満たさないときは、当該ファイル実体情報に対応する素材ファイルについて「再生可能でない」と判定する。
そして、クライアント端末１０は、少なくとも１つの素材ファイルについて再生可能と判定したときはステップＳ６に進み、再生可能な素材ファイルがないと判定したときは処理を終了する。

ステップＳ６では、クライアント端末１０は、再生可能であると判定した素材ファイルについて、当該素材ファイルに対応するファイル実体情報に含まれるＵＲＬを参照して、当該素材ファイルを格納先からダウンロードする。

また、クライアント端末１０は、ステップＳ５において複数の素材ファイルを再生可能であると判定した場合は、再生可能である素材ファイルに対応するファイル実体情報を表示部１６（図３参照）に表示して、ユーザの指示があるまで待機する。
クライアント端末１０は、表示部１６に表示されたファイル実体情報のうち、入力部１１を介してユーザに指示されたファイル実体情報のＵＲＬを参照して、素材サーバから当該素材ファイルをダウンロードする。

以上のように、第１実施形態に係る素材ファイル管理システム１において、ＵＭＩＤによって一意に同定される再生時ビットストリームの格納時の実体である1つ以上の素材ファイルがそれぞれ異なる場所に格納されている場合に、クライアント端末１０は、ＵＭＩＤネームサーバ３０に対してＵＭＩＤが一意に同定する再生時ビットストリームの格納時の素材ファイルの問い合わせを行い、ＵＭＩＤネームサーバ３０からファイル再生時情報及びファイル実体情報を受信する。これにより、クライアント端末１０は、ファイル再生時情報及びファイル実体情報に基づいて、当該クライアント端末１０が必要とする再生時ビットストリームであって、かつ、当該再生時ビットストリームを実際に再生可能な素材ファイルを見つけることができる。

また、素材ファイル管理システム１において、クライアント端末１０は、上述のように見つけた素材ファイルが複数存在する場合には、当該複数の素材ファイルのそれぞれに対応するファイル実体情報をユーザに提示し、ユーザから指示のあったファイル実体情報に対応する素材ファイルだけをダウンロードする。このため、ユーザは、所望の素材ファイルのみを入手することができる。

［第１実施形態の変形例］
素材ファイル管理システム１は、本実施形態では１つのＵＭＩＤネームサーバ３０を備えているが、負荷分散を図るために複数のＵＭＩＤネームサーバ３０を備えてもよい。
また、クライアント端末１０は、自身が必要とする素材ファイルの条件をルール化することで、ファイル再生時情報の詳細パラメータと照合することにより、その要不要を自動的に判断しても良い。例えば、クライアント端末１０は、ｄｅｐｔｈ＝１０、ｓａｍｐｌｅ＝４２２の高画質の映像編集を行っている場合、必要とする素材ファイルの条件としては、ファイル再生時情報として、ｄｅｐｔｈ＝１０かつｓａｍｐｌｅ＝４２２なる値をもった素材ファイルのみを自動的に選択してもよい。

上述したステップＳ４では、クライアント端末１０は、ｄｅｐｔｈ＝１０、ｓａｍｐｌｅ＝４２２の高画質の再生時ビットストリームを必要としている。しかし、クライアント端末１０は、そのような条件を満たす再生時ビットストリームが存在しない場合は、上記条件よりも品質の低い再生時ビットストリームを必要と判定してもよい。例えば、クライアント端末１０は、ファイル再生時情報がｄｅｐｔｈ＝８（８ｂｉｔ／ピクセル）、ｓａｍｐｌｅ＝４２０（ＹＵＶ４２０）となる再生時ビットストリームしか存在しない場合、当該再生時ビットストリームを必要と判定してもよい。

また、上述したステップＳ４では、クライアント端末１０は、所定の品質条件を満たす再生時ビットストリームを必要とする場合であって、当該所定の品質条件を満たす再生時ビットストリームが存在しないときは、上記品質条件よりも品質の高い再生時ビットストリームを必要と判定してもよい。

例えば、クライアント端末１０は、ｄｅｐｔｈ＝８、ｓａｍｐｌｅ＝４２０の再生時ビットストリームを必要とする場合であって、当該品質条件を満たす再生時ビットストリームが存在せず、ファイル再生時情報がｄｅｐｔｈ＝１０、ｓａｍｐｌｅ＝４２２となる再生時ビットストリームしか存在しない場合、当該ビットストリームを必要と判定してもよい。この場合、クライアント端末１０は、ｄｅｐｔｈ＝１０、ｓａｍｐｌｅ＝４２２となる再生時ビットストリームを取得し、当該ビットストリームをｄｅｐｔｈ＝８、ｓａｍｐｌｅ＝４２０となるビットストリームに変換すればよい。

クライアント端末１０は、自身が必要とし、かつ、実際に再生可能な素材ファイルが複数存在する場合には、ファイル実体情報の詳細パラメータ（ｃｏｄｅｃ，ｗｒａｐｐｅｒなど）のうち、優先順位の最も高い詳細パラメータに合致する素材ファイルを自動的に選択し、その格納場所にアクセスして、当該素材ファイルを自動的にダウンロードしてもよい。例えば、いまクライアント端末１０が、そのデータ圧縮方式としてＭＰＥＧとＪＰＥＧ２０００の両方をサポートしているものの、処理能力的に後者の利用がより好適な場合、ｃｏｄｅｃ＝ｊ２ｋなる値をもった素材ファイルのみを自動的に選択してもよい。

ＵＭＩＤネームサーバ３０は、所定のドメイン（本実施形態ではｅｘａｍｐｌｅ．ｏｒｇ）下に配置されている。このため、ユーザは、世界中のどこにいても、通常のＤＮＳのドメイン解決機能を用いて当該ＵＭＩＤネームサーバ３０にアクセスすることが可能である。換言すれば、ファイアウォールなどのセキュリティ技術による制限を設けない限り、ユーザは、所定のドメイン下の任意の素材を、インターネットを通じて世界中のどこからでも取得することが可能である。

なお、本実施形態では、ＵＭＩＤネームサーバ３０はｅｘａｍｐｌｅ．ｏｒｇドメイン直下に配置され、ｅｘａｍｐｌｅ．ｏｒｇのＤＮＳネームサーバと共有されることを前提としている。これに対して、当該ドメインの下に＿ｕｍｉｄ．＿ｕｄｐなるサブドメインを設定して、当該サブドメインにＵＭＩＤと基本技術属性との対応管理を委譲してもよい。換言すれば、＿ｕｍｉｄ．＿ｕｄｐ．ｅｘａｍｐｌｅ．ｏｒｇドメインの元、ＵＭＩＤ解決に専念したＵＭＩＤネームサーバを別途準備してもよい。これによって、ネットワークのインフラを司るＤＮＳと、ＵＭＩＤに基づく素材データの管理を完全に分離し、互いの影響を最小限に抑制することが可能となる。

あるいは、素材ファイル管理システム１は、所定のドメイン下にサブドメイン（例えばｎｅｗｓ．ｅｘａｍｐｌｅ．ｏｒｇ，ｓｐｏｒｔｓ．ｅｘａｍｐｌｅ．ｏｒｇなど）を設定し、サブドメイン毎にＵＭＩＤネームサーバ３０を備えてもよい。これにより、素材ファイル管理システム１は、より現場に即した範囲での素材ファイル管理が可能となる他、ＤＮＳドメイン解決機能を用いることにより、複数のサブドメインにまたがった素材ファイルでも容易に管理可能になる。

ＵＭＩＤネームサーバ３０は、クライアント端末１０からの問い合わせがあった場合には、ファイル再生時情報及びファイル実体情報をまとめて返信するのではなく、ファイル再生時情報及びファイル実体情報を任意の順序で逐次返信してもよい。
クライアント端末１０は、図５に示すステップＳ４及びステップＳ５の順序を入れ替えて、各ステップを実行してもよい。

なお、本実施形態では、ＵＭＩＤネームサーバ３０とメタデータ記憶装置２０とは独立して設定されているが、両者は一体化しても良い。その場合は、メタデータ記憶装置２０（ＵＭＩＤネームサーバ３０を含む。）は、クライアント１０からの内容に基づく所望の素材ファイルの問い合わせ（例えばイチローのホームランシーンを撮影した素材ファイルの問い合わせ）に対して、その問い合わせに該当する素材ファイルのファイル再生時情報やファイル実体情報をクライアント１０に直接回答する。これにより、クライアント１０は、ＵＭＩＤを取り扱うことなく、ダイレクトに、所望の再生時ビットストリームを再生するための素材ファイルを入手することができる。

ＵＭＩＤネームサーバ３０は、本実施形態ではＤＮＳ機能を用いて実現しているが、特にそれに限定されない。つまり、ＵＭＩＤネームサーバ３０は、ＵＭＩＤとファイル再生時情報及び、ＵＭＩＤとファイル実体情報をそれぞれ対応させて登録可能であり、ＵＭＩＤを指定した問い合わせに対して、当該ＵＭＩＤに対応したファイル再生時情報とファイル実体情報と、を回答できるデータベースであればよく、ＤＮＳ機能自体は必須ではない。

［第２実施形態］
図６は、第２実施形態に係る素材ファイル管理システム１Ａの構成を示す図である。なお、第１実施形態と同一のものには同一の符号を付し、主に第１実施形態と異なる点について説明する。
素材ファイル管理システム１Ａは、例えば放送局内ネットワークなど論理的に閉じられたローカルなネットワークで構成され、第１実施形態（図１）と異なり、ＵＭＩＤネームサーバ３０を有していない。その代わり、各素材サーバ（収録サーバ４０、ニアライン素材サーバ５０、送出サーバ６０及びアーカイブ装置７０）が、各々の内部にＵＭＩＤネームサーバ３０相当の機能を有している。

例えば、収録サーバ４０は、それが保有する素材ファイルに関する基本技術属性を登録するための記憶領域を有している。収録サーバ４０は、その内部において、素材ファイルの新規生成を検出すると、新たなＵＭＩＤを生成し当該素材ファイルに付与した上で、当該ＵＭＩＤと同素材ファイルに関するファイル再生時情報とを組み合わせたもの及び、当該ＵＭＩＤと同素材ファイルに関するファイル実体情報とを組み合わせたものを、上述の記憶領域に記憶する。なお、当該記憶領域に記憶される情報は、少なくとも第１実施形態と同等である他、収録サーバ４０固有の機能を実現する上で必要とされる新たな情報を追加してもよい。

そして、収録サーバ４０は、クライアント端末１０からＤＮＳクエリ機能を用いた所定のＵＭＩＤについての問い合わせがあると、次のように回答する。収録サーバ４０は、そのＵＭＩＤに対応するファイル再生時情報及びファイル実体情報を記憶している場合は、当該ファイル再生時情報及びファイル実体情報を、ＤＮＳレスポンス機能を用いてクライアント端末１０に送信し、ＵＭＩＤに対応するファイル再生時情報及びファイル実体情報を記憶していない場合は、それらの情報を記憶していない旨を、ＤＮＳレスポンス機能を用いてクライアント端末１０に送信する。

図７は、クライアント端末１０による問い合わせ処理ルーチンを示すフローチャートである。
ステップＳ１１では、クライアント端末１０は、第１実施形態と同様に、ＵＭＩＤをドメイン表記ＵＭＩＤへ変換する。

ステップＳ１２では、クライアント端末１０は、素材ファイル管理システム１Ａ内の各素材サーバに対して、ステップＳ１１で変換されたドメイン表記ＵＭＩＤを用いて、本システム１Ａに存在する素材ファイルの問い合わせを、ＤＮＳクエリ機能を用いて行う。
ここでクライアント端末１０は、各素材サーバに対して、通常のＤＮＳに基づくＤＮＳクエリ機能を用いて一対一の対応を逐次的におこなってもよいし、マルチキャストＤＮＳに基づくＤＮＳクエリ機能を用いて全ての素材サーバに対して一度にＤＮＳクエリを送信してもよい。

一方、各素材サーバは、ＤＮＳクエリ機能を用いたクライアント端末１０からの上記の問い合わせを受けると、その問い合わせに対する回答として、問い合わせのあったＵＭＩＤに対応するファイル再生時情報及びファイル実体情報を、ＤＮＳレスポンス機能を用いてクライアント端末１０へ送信する。また、各素材サーバは、問い合わせのあったＵＭＩＤに対応するファイル再生時情報及びファイル実体情報を記憶していない場合は、それらの情報を記憶していない旨を、ＤＮＳレスポンス機能を用いてクライアント端末１０へ送信する。

ステップＳ１３では、クライアント端末１０は、各素材サーバからの回答（ファイル再生時情報及びファイル実体情報、またはこれらの情報がない旨）をＤＮＳレスポンスとして受信する。
ステップＳ１４では、クライアント端末１０は、ステップＳ１３で受信したファイル再生時情報を参照し、上記ＵＭＩＤが同定する再生時ビットストリームの格納時の実体である各素材ファイルを必要とするか否かを判定する。素材ファイルを必要とするか否かの判定方法は、第１実施形態と同様である。

ここでは、クライアント端末１０は、第１実施形態と異なって、当該ファイル再生時情報を各々の素材サーバから受け取る。ファイル再生時情報とＵＭＩＤは一対一に対応していることから、クライアント端末１０が全ての素材サーバから受け取るファイル再生時情報は同一である。従って、クライアント端末１０は、最初のファイル再生時情報を受信した段階で、本ステップを実行すればよい。
そして、クライアント端末１０は、上記ＵＭＩＤが同定する再生時ビットストリームの格納時の実体である各素材ファイルを必要とすると判定したときはステップＳ１５に進み、必要としないと判定したときは処理を終了する。

ステップＳ１５では、クライアント端末１０は、各素材サーバからＤＮＳレスポンスとして受信したすべてのファイル実体情報を参照し、上記ＵＭＩＤが同定する再生時ビットストリームの格納時の実体であるすべての素材ファイルのうちの少なくとも１つについて、再生可能か否かを判定する。再生可能か否かの判定方法については、第１実施形態と同様である。

クライアント端末１０は、少なくとも１つの素材ファイルについて再生可能と判定したときはステップＳ１６に進み、再生可能な素材ファイルがないと判定したときは処理を終了する。

ステップＳ１６では、クライアント端末１０は、再生可能であると判定した素材ファイルについて、当該素材ファイルに対応するファイル実体情報に含まれるＵＲＬを参照して、当該素材ファイルを格納先からダウンロードする。
また、クライアント端末１０は、ステップＳ１５において複数の素材ファイルを再生可能であると判定した場合は、再生可能である素材ファイルに対応するファイル実体情報を表示部１６（図３参照）に表示して、ユーザの指示があるまで待機する。
クライアント端末１０は、表示部１６に表示されたファイル実体情報のうち、入力部１１を介してユーザに指示されたファイル実体情報のＵＲＬを参照して、素材サーバから素材ファイルをダウンロードする。

以上のように、第２実施形態に係る素材ファイル管理システム１Ａがローカルネットワークにある場合には、クライアント端末１０が、本システム内のすべての素材サーバに対してＵＭＩＤが一意に同定する再生時ビットストリームの格納時の実体である素材ファイルの問い合わせを行い、素材サーバからファイル再生時情報及びファイル実体情報を直接受信する。これにより、クライアント端末１０は、ファイル再生時情報及びファイル実体情報に基づいて、当該クライアント端末１０が必要とする再生時ビットストリームであって、かつ、当該再生時ビットストリームを実際に再生可能な素材ファイルを見つけることができる。

［第２実施形態の変形例］
クライアント端末１０は、通常のＤＮＳクエリを用いて各素材サーバに逐次的に問い合わせをした場合、所望の素材ファイルを入手した段階で、その後の処理を終了してもよい。
なお、クライアント端末１０がマルチキャストＤＮＳで全ての素材サーバに一度に問い合わせを行った場合、当該素材ファイルのない素材サーバは、クライアント端末１０に対して、素材ファイルがない旨のレスポンスをしてもよいし、当該レスポンスをしなくてもよい。後者の場合、例えば問い合わせの実施後から所定の時間内で何もレスポンスが戻ってこない場合は、クライアント端末１０は、素材ファイル管理システム１Ａ内に所望の素材ファイルが存在しないと判定する。

一方、素材ファイル管理システム１Ａ内に所望の素材ファイルが複数存在する場合、クライアント端末１０は、各素材サーバからＤＮＳレスポンスとしての回答を五月雨的に受け取る。このときクライアント端末１０は、各素材サーバからの回答を逐次吟味して所望の素材ファイルを入手した段階で、それ以降に受信した回答を無視してもよい。

また、本実施形態の素材ファイル管理システム１Ａは、複数の素材サーバが保有する素材ファイルをまとめて管理する代理ＵＭＩＤネームサーバを備え、各素材サーバが内部の素材ファイルの管理状況を当該代理ＵＭＩＤネームサーバに逐一報告するようにしてもよい。これにより、当該代理ＵＭＩＤネームサーバは、クライアント端末１０に対する応答としては、複数の素材サーバをまとめた大きな素材サーバのように機能することができる。

上述した第１及び第２実施形態では、ＵＭＩＤで同定される再生時ビットストリーム及びその格納時の実体である素材ファイルをベースに議論したが、本発明はこれに限定されるものではない。

例えば、本発明は素材ファイルの代わりに一般の文書ファイルなどにも適用できる。例えばワードやエクセルなどの文書データがＺＩＰやＬＺＨといったデータ圧縮方式に基づいてデータ圧縮された格納データとして格納されている場合、元の非圧縮状態での文書データであるデジタル資産を一意に同定するＩＤを導入することで、上記の議論はそのまま適用できる。ここで文書データを一意に同定するＩＤとしては、ＵＵＩＤ（Ｕｎｉｖｅｒｓａｒｙ Ｕｎｉｑｕｅ Ｉｄｅｎｔｉｆｉｅｒ）やＵＲＮ（Ｕｎｉｑｕｅ Ｒｅｓｏｕｒｃｅ Ｎａｍｅ）などが利用可能である。

１ 素材ファイル管理システム
１０ クライアント端末
１１ 入力部
１４ ＣＰＵ
１６ 表示部
１７ 通信部
３０ ＵＭＩＤネームサーバ
４０ 収録サーバ
５０ ニアライン素材サーバ
６０ 送出サーバ
７０ アーカイブ装置

Claims (9)

1. １つ以上のデータ格納装置に一意のビットストリームの格納時の実体である１つ以上の格納データがそれぞれ異なる形態で格納されている場合に、前記一意のビットストリームを復元できる格納データのすべてを同定するための識別データをサーバ装置へ送信する送信手段と、
   前記送信手段により送信された前記識別データが示す一意のビットストリームの使用時の特徴を示すビットストリーム使用時特徴情報と、前記識別データが示す一意のビットストリームを復元できる１つ以上の格納データの各々の実体的特徴を示す格納データ実体情報と、を前記サーバ装置から受信する受信手段と、
   前記ビットストリーム使用時特徴情報は前記ビットストリームの使用時の品質情報を含み、前記格納データ実体情報は前記ビットストリームのデータ圧縮方式情報を含み、前記受信手段により受信された前記ビットストリーム使用時特徴情報に含まれる品質情報が所定の範囲内でない場合は、前記品質情報が前記所定の範囲内でないと判定された時点で前記識別データによって同定されるいかなる格納データも取得しないと判定し、前記受信手段により受信された前記品質情報が前記所定の範囲内である場合は、前記受信手段により受信された前記格納データ実体情報に含まれるデータ圧縮方式情報が少なくとも１つの所定のデータ圧縮方式情報に一致するときに、前記一致する所定のデータ圧縮方式情報を含む格納データ実体情報に対応する格納データを、前記データ格納装置から取得すると判定する判定手段と、
   を備えた端末装置。
2. 前記判定手段により取得すると判定された格納データを前記データ格納装置から取得する取得手段を更に備えた
   請求項１に記載の端末装置。
3. 前記受信手段により受信された前記ビットストリーム使用時特徴情報に含まれる品質情報が前記所定の範囲内であり、前記受信手段により受信された前記格納データ実体情報に含まれるデータ圧縮方式情報が少なくとも１つの所定のデータ圧縮方式情報に一致する場合に、前記一致する所定のデータ圧縮方式情報を含む１つ以上の格納データ実体情報をユーザに提示するデータ提示手段を更に備え、
   前記判定手段は、前記データ提示手段により提示された前記１つ以上の格納データ実体情報のうち、前記ユーザによって選択される前記格納データ実体情報に対応する格納データを、前記データ格納装置から取得すると判定する
   請求項１又は請求項２に記載の端末装置。
4. 前記格納データ実体情報は、前記格納データの格納場所情報を含み、
   前記取得手段は、前記格納データ実体情報に含まれる前記格納場所情報に基づいて、前記格納データを取得する
   請求項２又は請求項３に記載の端末装置。
5. 前記データ格納装置は前記サーバ装置である
   請求項１から請求項４のいずれか１項に記載の端末装置。
6. コンピュータを請求項１から請求項５のいずれか１項に記載の端末装置の各手段として機能させるためのデータ処理プログラム。
7. １つ以上のデータ格納装置に１つ以上の格納データがそれぞれ格納されている場合に、一意のビットストリームを復元できる格納データのすべてを同定するための識別データと、前記識別データが示す一意のビットストリームの使用時の特徴を示すものであって前記ビットストリームの使用時の品質情報を含むビットストリーム使用時特徴情報と、前記識別データが示す一意のビットストリームを復元できる１つ以上の格納データの各々の実体的特徴を示すものであって前記ビットストリームのデータ圧縮方式情報を含む格納データ実体情報と、を対応付けて記憶する記憶手段と、
   前記端末装置から送信された識別データを受信する受信手段と、
   前記受信手段により受信された識別データに対応するビットストリーム使用時特徴情報及び格納データ毎の格納データ実体情報を前記記憶手段から読み出し、読み出した前記ビットストリーム使用時特徴情報及び前記１つ以上の格納データ毎の格納データ実体情報を前記端末装置へ送信する送信手段と、
   を備えたサーバ装置。
8. 前記格納データを記憶する格納データ記憶手段を更に備え、
   前記格納データ記憶手段は、前記データ格納装置である
   請求項７に記載のサーバ装置。
9. 一意のビットストリームの格納時の実体である１つ以上の格納データがそれぞれ異なる形態で格納された１つ以上のデータ格納装置と、
   請求項１から請求項５のいずれか１項に記載の端末装置と、
   請求項７又は請求項８に記載のサーバ装置と、
   を備えたデータ管理システム。