(57)【要約】メディア管理装置は、クライアント機器（２０）と通信する通信部（１１）と、クライアント機器（２０）と送受信するコンテンツを蓄積するためのコンテンツデータ蓄積部（１３）と、コンテンツデータ蓄積部（１３）が確保する空き容量を示す残容量を取得するための残容量取得部（１５）と、特定の文字列で構成されるキーワードを含むコンテンツに関する付加情報取得要求（Ｂｒｏｗｓｅ要求）を、クライアント機器（２０）から受信した場合に、残容量取得部（１５）により取得されたコンテンツデータ蓄積部（１３）が確保する残容量を、クライアント機器（２０）に返答するＵＰｎＰ−ＡＶプロトコル処理部（１２）とを備える。【特許請求の範囲】
【請求項１】
ネットワークを介してユーザが操作するクライアント機器と通信可能に接続され、当該クライアント機器とファイルデータを送受信するサーバ機器に用いられるメディア管理装置であって、
前記クライアント機器と通信する通信手段と、
前記クライアント機器と送受信するファイルデータを蓄積するためのファイルデータ蓄積手段と、
前記蓄積手段が確保する空き容量を示す残容量を取得するための残容量取得手段と、
特定の文字列で構成されるキーワードを含む前記ファイルデータに関する付加情報取得要求を、前記クライアント機器から受信した場合に、前記残容量取得手段により取得された前記蓄積手段が確保する残容量を、当該クライアント機器に返答するプロトコル処理手段と
を備えることを特徴とするメディア管理装置。
【請求項２】
前記クライアント機器に配信するファイル構成情報には、前記蓄積手段が確保する残容量だけを示すフォルダ又はアイテムが定義されており、
前記プロトコル処理手段は、前記キーワードが前記フォルダ又はアイテムに対するものである場合に、前記残容量だけを示すフォルダ又はアイテムを当該クライアント機器に返答する
ことを特徴とする請求項１記載のメディア管理装置。
【請求項３】
前記ファイルデータ蓄積手段には、複数のメディア毎に確保された空き容量が記述された記述情報が管理されており、
前記プロトコル処理手段は、前記キーワードが前記記述情報に対するものである場合に、前記メディア毎の残容量を当該クライアント機器に返答する
ことを特徴とする請求項１記載のメディア管理装置。
【請求項４】
前記メディア管理装置は、さらに前記通信手段を介して前記クライアント機器からファイルデータを受信し、受信したファイルデータを前記蓄積手段が確保する特定の場所に格納させるファイルデータ受信手段を備える
ことを特徴とする請求項１記載のメディア管理装置。
【請求項５】
ネットワークを介してユーザが操作するクライアント機器と通信可能に接続され、当該クライアント機器とファイルデータを送受信するサーバ機器に用いられるメディア管理方法であって、
前記クライアント機器と通信する通信ステップと、
前記クライアント機器と送受信するファイルデータを蓄積手段に蓄積するためのファイルデータ蓄積ステップと、
前記蓄積手段が確保する空き容量を示す残容量を取得するための残容量取得ステップと、
特定の文字列で構成されるキーワードを含む前記ファイルデータに関する付加情報取得要求を、前記クライアント機器から受信した場合に、前記残容量取得ステップにより取得された前記蓄積手段が確保する残容量を、当該クライアント機器に返答するプロトコル処理ステップと
を含むことを特徴とするメディア管理方法。
【請求項６】
請求項５に記載のメディア管理方法に含まれるステップをコンピュータに実行させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】  本発明は、機器間でデータファイルの転送を行う際のメディアの空き容量を管理するメディア管理装置及びメディア管理方法に関する。
【背景技術】
【０００２】  近年、ｘＤＳＬや光ファイバーなどのブロードバンド環境が整ったことにより、企業、一般家庭を問わずインターネット接続が急速に普及してきている。また、家庭内のＰＣや家電機器をＥｔｈｅｒｎｅｔ（登録商標）や無線ＬＡＮなどで接続するホームネットワーク環境も一般化してきている。このような中で、パーソナルコンピュータ（ＰＣ）だけでなく、テレビやＤＶＤレコーダ、エアコン、冷蔵庫のような家電もＩＥＴＦ（Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ）により定義されるＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）ネットワークにより相互に接続できるようになってきている。【０００３】  インターネットや、ホームネットワークにおけるアプリケーションの１つとして、家電機器、ＰＣ間で映像や音楽などのＡＶコンテンツファイルをコピー（ファイル転送又はファイル移動）するようなアプリケーションがある。例えば、リビングに設置されたＨＤＤレコーダで録画されたＴＶ番組を、別の部屋にあるＤＶＤレコーダを用いてＤＶＤメディアにコピーしたりするような例が挙げられる。【０００４】  このようなファイル転送を行うプロトコルとしては、古くはＦＴＰ（Ｆｉｌｅ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）や、最近ではＷｅｂＤＡＶ（Ｗｅｂ−ｂａｓｅｄ  Ｄｉｓｔｒｉｂｕｔｅｄ  Ａｕｔｈｏｒｉｎｇ  ａｎｄ  Ｖｅｒｓｉｏｎｉｎｇ  ｐｒｏｔｏｃｏｌ）などがある。そして、ホームネットワークにおいて映像や音楽などのＡＶコンテンツファイルを扱う場合のプロトコルとして、ＵＰｎＰ−ＡＶ（Ｕｎｉｖｅｒｓａｌ  Ｐｌｕｇ  ａｎｄ  Ｐｌａｙ  Ａｕｄｉｏ／Ｖｉｄｅｏ）規格（非特許文献１）が最近注目されている。【０００５】  ＵＰｎＰ−ＡＶでは、コンテンツファイルそのものの転送方式を規定しているわけではなく、コンテンツファイルに付随された情報（メタデータ）に関するサービスや、コネクションに関するサービスなどについて規定している。中でもコンテンツファイルに付随された情報（メタデータ）に関するサービスであるＣＤＳ（Ｃｏｎｔｅｎｔ  Ｄｉｒｅｃｔｒｙ  Ｓｅｒｖｉｃｅ）は、ＵＰｎＰ−ＡＶ規格における最も基本的なサービスであり、コンテンツの付随情報（メタデータ）取得の他に、コンテンツの付随情報（メタデータ）そのものを、作成したり、削除したり、修正したりすることもできる。一方、ＵＰｎＰ−ＡＶと併用して用いられるコンテンツファイルの転送方式としては、ＨＴＴＰ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）や、ＲＴＰ（Ｒｅａｌ−ｔｉｍｅ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ）などが一般的である。【０００６】  ユーザが操作する機器をクライアントとし、ネットワークに接続された相手の機器をサーバとすると、ＵＰｎＰ−ＡＶとＨＴＴＰを用いてサーバからクライアントにファイル転送を行う場合、まずＣＤＳ：：Ｂｒｏｗｓｅを用いてサーバからコンテンツファイルの付随情報（メタデータ）の一覧を取得し、ファイル転送したいコンテンツのファイル転送が可能なＵＲＬを取得することで、ＨＴＴＰ−ＧＥＴによりファイル転送を行う。この逆に、クライアントからサーバにファイル転送を行う場合、ＣＤＳ：：ＣｒｅａｔｅＯｂｊｅｃｔを用いてクライアントからサーバに対してファイル転送したいコンテンツの付随情報（メタデータ）の作成を依頼（作成依頼）し、作成依頼応答に含まれるＵＲＬ先に対して、ＨＴＴＰ−ＰＯＳＴによりファイル転送を行う。
【非特許文献１】ＵＰｎＰ−ＡＶ規格書
【発明の開示】
【発明が解決しようとする課題】
【０００７】  ところで、ここで問題となるのが、ファイル転送可能かどうかを判断するための、ディスク空き容量確認の方法である。【０００８】  通常、サーバからクライアントに対してファイル転送する場合は、ファイル転送を行うコンテンツのデータ量がコンテンツファイルの付随情報（メタデータ）に記載されているので、クライアント側のディスク空き容量と比較して、ファイル転送可能かどうかの判断が行うことができる。【０００９】  これに対して、クライアントからサーバに対してファイル転送する場合は、ファイル転送を行うコンテンツのデータ量は分かるものの、サーバ側のディスク空き容量を確認する仕組みが決められていない。【００１０】  例えば、サーバ側の特定ディスク又は特定フォルダにファイル転送を行う際には、その特定ディスク又は特定フォルダの付随情報（メタデータ）に空き容量を示す情報が記述されている場合があるが、必ずしも記述されているとは限らない。この理由は、ＣＤＳで記述されるディスク又はフォルダなどがあくまで概念上のものであり、バーチャルなＯｂｊｅｃｔとして表現されているからであり、実際の物理的なディスク構成又はフォルダ構成と一致する必要がないからである。【００１１】  このため、サーバ側のディスク空き容量を予め確認する技術の出現が強く望まれている。【００１２】  そこで、本発明は、上記した問題を解決し、サーバ側のディスク空き容量を予め確認することができるメディア管理装置及びメディア管理方法を提供する目的とする。
【課題を解決するための手段】
【００１３】  上記目的を達成するために、本発明に係るメディア管理装置においては、ネットワークを介してユーザが操作するクライアント機器と通信可能に接続され、当該クライアント機器とファイルデータを送受信するサーバ機器に用いられるメディア管理装置であって、前記クライアント機器と通信する通信手段と、前記クライアント機器と送受信するファイルデータを蓄積するためのファイルデータ蓄積手段と、前記蓄積手段が確保する空き容量を示す残容量を取得するための残容量取得手段と、特定の文字列で構成されるキーワードを含む前記ファイルデータに関する付加情報取得要求を、前記クライアント機器から受信した場合に、前記残容量取得手段により取得された前記蓄積手段が確保する残容量を、当該クライアント機器に返答するプロトコル処理手段とを備えることを特徴とする。【００１４】  これにより、クライアント機器は、ファイルデータを転送する前に、サーバ機器側のディスク空き容量を予め確認することができる。【００１５】  なお、本発明は、このようなメディア管理装置として実現することができるだけでなく、このようなメディア管理装置が備える特徴的な手段をステップとするメディア管理方法として実現したり、それらのステップをコンピュータに実行させるプログラムとして実現したりすることもできる。そして、そのようなプログラムは、ＣＤ−ＲＯＭ等の記録媒体やインターネット等の伝送媒体を介して配信することができるのはいうまでもない。
【発明の効果】
【００１６】  以上の説明から明らかなように、本発明に係るメディア管理装置によれば、クライアント機器は、ファイルデータを転送する前に、サーバ機器側のディスク空き容量を予め確認することができる。【００１７】  よって、本発明により、インターネットや、ホームネットワークを介して、家電機器、ＰＣ間で映像や音楽などのＡＶコンテンツファイルをコピーするようなアプリケーションが出現し、ＵＰｎＰ−ＡＶ規格が普及してきた今日における本願発明の実用的価値は極めて高い。
【図面の簡単な説明】
【００１８】
【図１】図１は、本実施の形態１におけるシステムの全体構成を示すブロック図である。
【図２】図２は、図１に示されるサーバ機器１０の主要部な機能構成を示すブロック図である。
【図３】図３は、サーバ機器１０におけるコンテンツデータの管理構成例を示す図である。
【図４】図４は、図１に示されるクライアント機器２０の主要部な機能構成を示すブロック図である。
【図５】図５は、上記パラメータでＣＤＳ：：Ｂｒｏｗｓｅアクションを送信する際のＳＯＡＰの一例を示す図である。
【図６】図６は、サーバ機器−クライアント機器間で行われる空き容量確認のシーケンスを示す図である。
【図７】図７は、応答コマンドに含まれるコンテナ情報の一例を示す図である。
【図８】図８は、クライアント機器２０−サーバ機器１０間で行われる空き容量確認の他のシーケンスを示す図である。
【図９】図９は、ＰｒｏｔｏｃｏｌＩｎｆｏ情報の記述例を示す図である。
【符号の説明】
【００１９】  ３  通信路
１０  サーバ機器
１１，２１  通信部
１２，２２  ＵＰｎＰ−ＡＶプロトコル処理部
１３，２４  コンテンツデータ蓄積部
１４  コンテンツデータ受信部
１５  残容量取得部
２０  クライアント機器
２３  コンテンツデータ送信部
２５  容量比較部
３１  ＲＯＯＴコンテナ
３２  Ｖｉｄｅｏコンテナ
３３  Ａｕｄｉｏコンテナ
３４  Ｐｈｏｔｏコンテナ
【発明を実施するための最良の形態】
【００２０】  以下、本発明の実施の形態について、図面を用いて詳細に説明する。【００２１】  （実施の形態１）
図１は、本実施の形態１におけるシステムの全体構成を示すブロック図である。【００２２】  図１に示されるように、システムは、サーバ機器１０と、クライアント機器２０と、サーバ機器１０及びクライアント機器２０を通信可能に接続する通信路３とを備える。【００２３】  通信路３は、イーサネット（登録商標）などの有線通信路や、ＩＥＥＥ８０２．１１ｂ／ｇ、Ｂｌｕｅｔｏｏｔｈなどの無線通信路によって構成される。【００２４】  サーバ機器１０は、クライアント機器２０に要求されたファイルデータ、例えば映像や、音楽、静止画などのコンテンツを送信したり、コンテンツに関する付加情報取得要求を、クライアント機器２０から受信した場合に、サーバ機器１０が確保する空き容量を示す残容量を、クライアント機器２０に返答したり、クライアント機器２０から送られてきたコンテンツを蓄積したりする。【００２５】  クライアント機器２０は、ＵＰｎＰの機器検索機能によりサーバ機器１０を認識しており、コンテンツを取得する場合、サーバ機器１０からＣＤＳ：：Ｂｒｏｗｓｅを用いてサーバからコンテンツファイルの付随情報（メタデータ）の一覧を取得し、ファイル転送したいコンテンツのファイル転送が可能なＵＲＬを取得することで、ＨＴＴＰ−ＧＥＴによりファイル転送を行う。この逆に、コンテンツを転送する場合、特定の文字列で構成されるキーワードを含むファイルデータに関する付加情報取得要求を、サーバ機器１０に送信する。そして、サーバ機器１０からサーバ機器１０が確保する残容量を、受信し、残容量を予め確認する。そして、クライアント機器２０は、残容量が転送するコンテンツより大きければ、サーバ機器１０に転送する。【００２６】  次いで、サーバ機器１０及びクライアント機器２０の詳細構成について順次説明する。
図２は、図１に示されるサーバ機器１０の主要部な機能構成を示すブロック図である。【００２７】  図２に示されるように、サーバ機器１０は、通信部１１と、ＵＰｎＰ−ＡＶ規格のプロトコル処理部（以下、「ＵＰｎＰ−ＡＶプロトコル処理部」とも記す。）１２と、コンテンツデータ蓄積部１３と、コンテンツデータ受信部１４と、残容量取得部１５とを備える。【００２８】  通信部１１は、通信路３を介してクライアント機器２０と通信する。
ＵＰｎＰ−ＡＶプロトコル処理部１２は、ＵＰｎＰ−ＡＶ規格に準拠した機器検索や能力交換などの処理を実行する。また、ＵＰｎＰ−ＡＶプロトコル処理部１２は、ＵＰｎＰ−ＡＶ規格に準拠したクライアント機器が送信したＵＰｎＰ−ＡＶコマンドを、通信部１１を介して受信し、受信したコマンドに従って動作する。【００２９】  コンテンツデータ蓄積部１３は、録画されたテレビ番組や、ＤＶＣ（Ｄｉｇｉｔａｌ  Ｖｉｄｅｏ  Ｃａｍｅｒａ）などで撮影された動画データ、ＤＳＣ（Ｄｉｇｉｔａｌ  Ｓｔｉｌｌ  Ｃａｍｅｒａ）などで撮影された静止画データ、録音されたラジオ番組や録音されたＣＤ（Ｃｏｍｐａｃｔ  Ｄｉｓｃ）楽曲などの音声データ（以下、動画、静止画、音声の各データをコンテンツデータと呼ぶ。）を蓄積する。【００３０】  クライアント機器２０では、これらのコンテンツデータのタイトル情報や、サイズ情報、録音録画日情報、ＵＲＬ（Ｕｎｉｆｏｒｍｅｄ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）等で表されるコンテンツデータの位置情報（以下、これらをまとめてメタデータと呼ぶ。）は、ＵＰｎＰ−ＡＶコマンド要求により、ＵＰｎＰ−ＡＶプロトコル処理部１２を介して取得することができる。【００３１】  残容量取得部１５は、コンテンツデータ蓄積部１３に蓄積可能なコンテンツデータの空き容量（残容量）を取得する。【００３２】  ＵＰｎＰ−ＡＶプロトコル処理部１２は、残容量取得部１５を通じてコンテンツデータ蓄積部１３の空き容量を取得し、クライアント機器からの空き容量を要求するＵＰｎＰ−ＡＶコマンドに対して応答する。【００３３】  コンテンツデータ受信部１４は、ＨＴＴＰ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ）などを用いて、クライアント機器から送信されるコンテンツデータをコンテンツデータ蓄積部１３に蓄積する。【００３４】  図３は、サーバ機器１０におけるコンテンツデータの管理構成例を示す図である。
管理構成上、これらはコンテンツデータと、仮想上のフォルダであるコンテナとで構成される。コンテナは、コンテンツデータ及びコンテナを格納するが、格納するコンテンツデータ或いはコンテナが存在しない場合もあり得る。またコンテンツデータの管理構成は、ＵＰｎＰ−ＡＶプロトコル処理部１２を通じてクライアント機器に公開する論理的な管理概念であり、実際にコンテンツデータ蓄積部１３のファイルシステム上では、必ずしも上記の構成が物理的に再現されていなくてもよい。【００３５】  図３では、構成の最上位に位置するＲＯＯＴコンテナ３１からツリー状に、映像を格納するためのＶｉｄｅｏコンテナ３２、音楽を格納するためのＡｕｄｉｏコンテナ３３、静止画を格納するためのＰｈｏｔｏコンテナ３４で構成され、それぞれ映像、音楽、静止画コンテンツデータが格納されている。【００３６】  図４は、図１に示されるクライアント機器２０の主要部な機能構成を示すブロック図である。【００３７】  図４に示されるように、クライアント機器２０は、通信部２１と、ＵＰｎＰ−ＡＶ規格のプロトコル処理部（以下、「ＵＰｎＰ−ＡＶプロトコル処理部」とも記す。）２２と、コンテンツデータ送信部２３と、コンテンツデータ蓄積部２４と、容量比較部２５とを備える。【００３８】  通信部２１は、通信路３を介してサーバ機器１０と通信する。
ＵＰｎＰ−ＡＶプロトコル処理部２２は、ＵＰｎＰ−ＡＶ規格に準拠したサーバ機器に対してＵＰｎＰ−ＡＶコマンドを送信し、サーバ機器を遠隔制御する。【００３９】  コンテンツデータ蓄積部２４は、コンテンツデータを蓄積する。
容量比較部２５は、サーバ機器側で受信可能なコンテンツデータ容量と、送信したコンテンツデータの容量とを比較し、サーバ機器がコンテンツデータを受信可能か否か判定する。【００４０】  コンテンツデータ送信部２３は、コンテンツデータ蓄積部２４に蓄積されたコンテンツデータをサーバ機器に対して送信する。【００４１】  ここで、クライアント機器２０は、ＵＰｎＰの機器検索機能によりサーバ機器１０を認識している。そして、クライアント機器２０は、コンテンツデータをサーバ機器１０に送信するに先立って、これから送信したいコンテンツデータをサーバ機器が完全に受信し、サーバ機器１０内のコンテンツデータ蓄積部１３に記憶するだけの十分な空き容量が存在するか否かの確認を予め行うために、ＣＤＳ：：Ｂｒｏｗｓｅアクションを実行する。このＣＤＳ：：Ｂｒｏｗｓｅは、コンテンツデータ蓄積部１３に記憶された情報を取得するＵＰｎＰ−ＡＶコマンドである。【００４２】  図５は、上記パラメータでＣＤＳ：：Ｂｒｏｗｓｅアクションを送信する際のＳＯＡＰ（Ｓｉｍｐｌｅ  Ｏｂｊｅｃｔ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ）の一例を示す図である。【００４３】  ここでは、“ＡｎｙＣｏｎｔａｉｎｅｒ”というキーワードを用いてコンテナを指定する。“ＡｎｙＣｏｎｔａｉｎｅｒ”とは、クライアント機器がコンテンツデータの格納先を特定せずに、サーバ機器にとって都合のよいコンテナをサーバ機器が選んでよいということを示す予約キーワードとする。【００４４】  次に情報を取得する対象として、指定コンテナ自身の情報の取得か、或いは指定コンテナの配下に存在する全てのコンテナ及びコンテンツデータの情報の取得かを選択するフラグを設定する。ここでは、コンテナ自身の情報が取得したいので、“ＢｒｏｗｓｅＭｅｔａｄａｔａ”をフラグとして設定する。【００４５】  さらに、クライアント機器が必要な属性情報を指定するが、ここではクライアント機器は空き容量の確認を行いたいので、“ｕｐｎｐ：ｓｔｏｒａｇｅＦｒｅｅ”をキーワードに指定する。また、データ取得開始位置と、取得個数に関しては、ここでは共に“０”を指定する。並び替えキーワードに関しては指定しない。【００４６】  図６は、サーバ機器−クライアント機器間で行われる空き容量確認のシーケンスを示す図である。【００４７】  クライアント機器２０は、図５に示される内容を含むＣＤＳ：：Ｂｒｏｗｓｅ要求コマンドを送信する（Ｓ６０）。【００４８】  ＣＤＳ：：Ｂｒｏｗｓｅ要求コマンドを受信したサーバ機器１０のＵＰｎＰ−ＡＶプロトコル処理部１２は、ＣＤＳ：：Ｂｒｏｗｓｅ要求コマンドを処理し（Ｓ６１）、コマンドの内容に従い、クライアント機器２０によって指定されたコンテナの空き容量を取得する（Ｓ６２、Ｓ６３、Ｓ６４、Ｓ６５）。【００４９】  ここで、クライアント機器２０が、対象コンテナとして“ＡｎｙＣｏｎｔａｉｎｅｒ”を指定したので、サーバ機器１０のＵＰｎＰ−ＡＶプロトコル処理部１２は、任意のコンテナを選択する。ここでは例えば“Ｖｉｄｅｏ”を選択したので、クライアント機器２０に対しては“Ｖｉｄｅｏ”のコンテナを特定する識別子（例えば、ｃｏｎｔａｉｎｅｒ  ｉｄ＝２）と、その空き容量とを含む��ＤＳ：：Ｂｒｏｗｓｅ応答コマンドを生成し（Ｓ６６）、クライアント機器２０に応答する（Ｓ６７）。【００５０】  図７は、応答コマンドに含まれるコンテナ情報の一例を示す図である。
クライアント機器２０のＵＰｎＰ−ＡＶプロトコル処理部２２は、通信部２１を介して受信したサーバ機器１０からの応答データを解釈し、“ＡｎｙＣｏｎｔａｉｎｅｒ”が実際には“Ｖｉｄｅｏ”が割り当てられ、残り容量が２１１６９４８９２３であることを予め知ることができる。【００５１】  容量比較部２５は、送信したいコンテンツデータのサイズと、サーバ機器１０のコンテンツデータ蓄積部１３の残容量とを比較し、この後コンテンツデータを送信するか否か決定する。【００５２】  ここで、ＵＰｎＰ−ＡＶでは、コンテナ及びコンテンツデータは、その種類に応じて様々なクラスに分類され、クラス毎に保持する属性が異なる。上記ｕｐｎｐ：ｓｔｏｒａｇｅＦｒｅｅは、ｏｂｊｅｃｔ．ｃｏｎｔａｉｎｅｒ．ｓｔｏｒａｇｅＶｏｌｕｍｅ及びｏｂｊｅｃｔ．ｃｏｎｔａｉｎｅｒ．ｓｔｏｒａｇｅＶｏｌｕｍｅの各クラスが保持する属性である。しかし、“ＡｎｙＣｏｎｔａｉｎｅｒ”に対してＣＤＳ：：Ｂｒｏｗｓｅアクションを受信した際には、サーバ機器は、全てのコンテナクラスにｕｐｎｐ：ｓｔｏｒａｇｅＦｒｅｅ属性を付与し、値を設定しなければならない。【００５３】  サーバ機器１０のコンテンツデータ蓄積部１３に十分な空き容量があることが容量比較部２５により確認されれば、クライアント機器２０のコンテンツデータ送信部２３は、コンテンツデータを送信する。そして、サーバ機器１０のコンテンツデータ受信部１４は、通信部１１を介してクライアント機器２０から送信されてきたコンテンツデータを受信し、コンテンツデータ蓄積部１３に記録する。【００５４】  したがって、ファイル受信するサーバ側において、特定のＯｂｊｅｃｔの格納先を、空き容量を示すためだけのフォルダに割り当てることで、クライアントは、ファイル転送する前に、特定Ｏｂｊｅｃｔに対して空き容量の確認を行うことができる。【００５５】  なお、上記実施の形態においては、予約キーワードとして、“ＡｎｙＣｏｎｔａｉｎｅｒ”という文字を用いたが、文字をこれに限定されるものではない。また、“ＦｒｅｅＳｐａｃｅ”などの文字を、予約キーワードとして、残容量確認のみを可能とすることでも、同様の効果が得られる。【００５６】  また、クライアント機器２０に配信するファイルのファイル構成情報には、コンテンツデータ蓄積部１３が確保する残容量だけを示すアイテムを定義し、キーワードがアイテムに対するものである場合に、残容量だけを示すアイテムをクライアント機器２０に返答するようにしてもよい。【００５７】  （実施の形態２）
次いで、本発明の実施の形態２におけるシステムについて説明する。なお、本実施の形態２におけるクライアント機器２０及びサーバ機器１０の構成は実施の形態１と同じであり、サーバ機器１０の処理内容及び送受信される情報が異なるだけであるので、異なる点を詳述する。【００５８】  図８は、クライアント機器２０−サーバ機器１０間で行われる空き容量確認の他のシーケンスを示す図である。【００５９】  クライアント機器２０は、上記したＣＤＳ：：Ｂｒｏｗｓｅ要求コマンドに代えて、図８に示されるＣＭＳ：：ＧｅｔＰｒｏｔｏｃｏｌＩｎｆｏ要求コマンドを送信する（Ｓ８０）。ここで、ＣＭＳ（Ｃｏｎｎｅｃｔｉｏｎ  Ｍａｎａｇｅｍｅｎｔ  Ｓｅｒｖｉｃｅ）は、ＵＰｎＰ−ＡＶ規格の１つであり、コネクション管理を行うためのサービスである。【００６０】  ＣＭＳ：：ＧｅｔＰｒｏｔｏｃｏｌＩｎｆｏ要求コマンドを受信したサーバ機器１０のＵＰｎＰ−ＡＶプロトコル処理部１２は、ＣＭＳ：：ＧｅｔＣｏｎｎｅｃｔｉｏｎＩｎｆｏ要求コマンドを処理し（Ｓ８１）、コマンドの内容に従い、クライアント機器２０によって指定されたコンテナの空き容量を、残容量取得部１５を介して取得する（Ｓ６２，Ｓ６３，Ｓ６４，Ｓ６５）。【００６１】  ＣＭＳ：：ＧｅｔＣｏｎｎｅｃｔｉｏｎＩｎｆｏでは、サーバ機器がサポートしているコンテンツのフォーマットや、プロトコルに応じて記述されたＰｒｏｔｏｃｏｌＩｎｆｏ情報を応答で返す。具体的には、サーバ機器１０のＵＰｎＰ−ＡＶプロトコル処理部１２は、これらコンテンツのフォーマットや、プロトコルに応じて、クライアント機器２０からファイル転送が可能で、コンテンツデータ蓄積部１３が管理する複数のメディア毎に確保された残容量が記述された記述情報に基づいて、残容量をＰｒｏｔｏｃｏｌＩｎｆｏ情報の４つめのパラメータに記述する。残容量の情報を取得した後、ＵＰｎＰ−ＡＶプロトコル処理部１２は、ＣＭＳ：：ＧｅｔＰｒｏｔｏｃｏｌＩｎｆｏ応答コマンドを生成し（Ｓ８６）、クライアント機器２０に応答する（Ｓ８７）。【００６２】  図９は、ＰｒｏｔｏｃｏｌＩｎｆｏ情報の記述例を示す図である。“：”で区切られた４つめのパラメータに、“ＦｒｅｅＳｐａｃｅ＝”を定義し、ここに容量の単位（ｂｙｔｅ又はＭｅｇａＢｙｔｅ）に応じて数値を記載する。図示例では、映像情報、音楽情報、静止画情報のそれぞれに、空き容量を個別に記載することが可能となっている。【００６３】  したがって、ファイル受信するサーバ側において、特定のＯｂｊｅｃｔの格納先を、空き容量を示すためだけのメディア又はフォルダに割り当てることで、クライアントは、ファイル転送する前に、特定Ｏｂｊｅｃｔに対して空き容量の確認を行うことができる。【００６４】  なお、上記実施の形態では、ファイルデータを映像や、音楽、静止画等のコンテンツとして説明したが、テキストデータ等のファイルデータに適用して実施してもよいのはいうまでもない。
【産業上の利用可能性】
【００６５】  本願発明に係るメディア管理装置は、ＨＤＤビデオレコーダや、セットトップボックス、パーソナルコンピュータ等、ネットワークに対応したＵＰｎＰ−ＡＶ規格のコンピュータ装置に適用することができる。
【図１】
2006106606.tif 000002
【図２】
2006106606.tif 000003
【図３】
2006106606.tif 000004
【図４】
2006106606.tif 000005
【図５】
2006106606.tif 000006
【図６】
2006106606.tif 000007
【図７】
2006106606.tif 000008
【図８】
2006106606.tif 000009
【図９】
2006106606.tif 000010
【手続補正書】
【提出日】平成19年2月7日(2007.2.7)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ネットワークを介してユーザが操作するクライアント機器と通信可能に接続され、当該クライアント機器とファイルデータを送受信するサーバ機器に用いられるメディア管理装置であって、
前記クライアント機器と通信する通信手段と、
前記クライアント機器と送受信するファイルデータを複数のフォルダごとに格納して蓄積するためのファイルデータ蓄積手段と、
前記蓄積手段が確保する空き容量を示す残容量を前記複数のフォルダごとに取得するための残容量取得手段と、
特定の文字列で構成され、前記フォルダを特定しないキーワードを含む前記残容量に関する情報取得要求を、前記クライアント機器から受信した場合に、前記残容量取得手段により取得された前記蓄積手段が確保する前記複数のフォルダの中からいずれか１つを選択し、選択された前記フォルダの残容量を含むファイルのファイル構成情報を、当該クライアント機器に配信するプロトコル処理手段と
を備えることを特徴とするメディア管理装置。
【請求項２】
前記プロトコル処理手段は、空き容量を示すためだけに割り当てられたフォルダを、前記複数のフォルダの中から選択する
ことを特徴とする請求項１記載のメディア管理装置。
【請求項３】
前記クライアント機器に配信するファイルのファイル構成情報には、前記蓄積手段が確保する残容量だけを示すフォルダ又はアイテムが定義されており、
前記プロトコル処理手段は、前記キーワードが前記フォルダ又はアイテムに対するものである場合に、前記残容量だけを示すフォルダ又はアイテムを当該クライアント機器に配信する
ことを特徴とする請求項１記載のメディア管理装置。
【請求項４】
前記ファイルデータ蓄積手段には、複数のメディア毎に確保された空き容量が記述された記述情報が管理されており、
前記プロトコル処理手段は、前記キーワードが前記記述情報に対するものである場合に、前記メディア毎の残容量を当該クライアント機器に配信する
ことを特徴とする請求項１記載のメディア管理装置。
【請求項５】
前記メディア管理装置は、さらに前記通信手段を介して前記クライアント機器からファイルデータを受信し、受信したファイルデータを前記蓄積手段が確保する特定の場所に格納させるファイルデータ受信手段を備える
ことを特徴とする請求項１記載のメディア管理装置。
【請求項６】
ネットワークを介してユーザが操作するクライアント機器と通信可能に接続され、当該クライアント機器とファイルデータを送受信するサーバ機器に用いられるメディア管理方法であって、
前記クライアント機器と通信する通信ステップと、
前記クライアント機器と送受信するファイルデータを蓄積手段の複数のフォルダごとに格納して蓄積するためのファイルデータ蓄積ステップと、
前記蓄積手段が確保する空き容量を示す残容量を前記複数のフォルダごとに取得するための残容量取得ステップと、
特定の文字列で構成され、前記フォルダを特定しないキーワードを含む前記残容量に関する情報取得要求を、前記クライアント機器から受信した場合に、前記残容量取得手段により取得された前記蓄積手段が確保する前記複数のフォルダの中からいずれか１つを選択し、選択された前記フォルダの残容量を含むファイルのファイル構成情報を、当該クライアント機器に配信するプロトコル処理ステップと
を含むことを特徴とするメディア管理方法。
【請求項７】
請求項６に記載のメディア管理方法に含まれるステップをコンピュータに実行させるプログラム。
【手続補正書】
【提出日】平成19年8月17日(2007.8.17)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ネットワークを介してユーザが操作するクライアント機器と通信可能に接続され、当該クライアント機器とファイルデータを送受信するサーバ機器に用いられるメディア管理装置であって、
前記クライアント機器と通信する通信手段と、
前記クライアント機器と送受信するファイルデータを複数のフォルダごとに格納して蓄積するためのファイルデータ蓄積手段と、
前記蓄積手段が確保する空き容量を示す残容量を前記複数のフォルダごとに取得するための残容量取得手段と、
特定の文字列で構成され、前記フォルダを特定しないキーワードを含む前記残容量に関する情報取得要求を、前記クライアント機器から受信した場合に、前記残容量取得手段により取得された前記蓄積手段が確保する前記複数のフォルダの中からいずれか１つを選択し、選択された前記フォルダの残容量を含むファイルのファイル構成情報を、当該クライアント機器に配信するプロトコル処理手段と
を備えることを特徴とするメディア管理装置。
【請求項２】
前記プロトコル処理手段は、空き容量を示すためだけに割り当てられたフォルダを、前記複数のフォルダの中から選択する
ことを特徴とする請求項１記載のメディア管理装置。
【請求項３】
前記クライアント機器に配信するファイルのファイル構成情報には、前記蓄積手段が確保する残容量だけを示すフォルダ又はアイテムが定義されており、
前記プロトコル処理手段は、前記キーワードが前記フォルダ又はアイテムに対するものである場合に、前記残容量だけを示すフォルダ又はアイテムを当該クライアント機器に配信する
ことを特徴とする請求項１記載のメディア管理装置。
【請求項４】
前記ファイルデータ蓄積手段には、複数のメディア毎に確保された空き容量が記述された記述情報が管理されており、
前記プロトコル処理手段は、前記キーワードが前記記述情報に対するものである場合に、前記メディア毎の残容量を当該クライアント機器に配信する
ことを特徴とする請求項１記載のメディア管理装置。
【請求項５】
前記メディア管理装置は、さらに前記通信手段を介して前記クライアント機器からファイルデータを受信し、受信したファイルデータを前記蓄積手段が確保する特定の場所に格納させるファイルデータ受信手段を備える
ことを特徴とする請求項１記載のメディア管理装置。
【請求項６】
ネットワークを介してユーザが操作するクライアント機器と通信可能に接続され、当該クライアント機器とファイルデータを送受信するサーバ機器に用いられるメディア管理方法であって、
前記クライアント機器と通信する通信ステップと、
前記クライアント機器と送受信するファイルデータを蓄積手段の複数のフォルダごとに格納して蓄積するためのファイルデータ蓄積ステップと、
前記蓄積手段が確保する空き容量を示す残容量を前記複数のフォルダごとに取得するための残容量取得ステップと、
特定の文字列で構成され、前記フォルダを特定しないキーワードを含む前記残容量に関する情報取得要求を、前記クライアント機器から受信した場合に、前記残容量取得手段により取得された前記蓄積手段が確保する前記複数のフォルダの中からいずれか１つを選択し、選択された前記フォルダの残容量を含むファイルのファイル構成情報を、当該クライアント機器に配信するプロトコル処理ステップと
を含むことを特徴とするメディア管理方法。
【請求項７】
請求項６に記載のメディア管理方法に含まれるステップをコンピュータに実行させるプログラム。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、機器間でデータファイルの転送を行う際のメディアの空き容量を管理するメディア管理装置及びメディア管理方法に関する。
【背景技術】
【０００２】
近年、ｘＤＳＬや光ファイバーなどのブロードバンド環境が整ったことにより、企業、一般家庭を問わずインターネット接続が急速に普及してきている。また、家庭内のＰＣや家電機器をＥｔｈｅｒｎｅｔ（登録商標）や無線ＬＡＮなどで接続するホームネットワーク環境も一般化してきている。このような中で、パーソナルコンピュータ（ＰＣ）だけでなく、テレビやＤＶＤレコーダ、エアコン、冷蔵庫のような家電もＩＥＴＦ（Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ）により定義されるＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）ネットワークにより相互に接続できるようになってきている。
【０００３】
インターネットや、ホームネットワークにおけるアプリケーションの１つとして、家電機器、ＰＣ間で映像や音楽などのＡＶコンテンツファイルをコピー（ファイル転送又はファイル移動）するようなアプリケーションがある。例えば、リビングに設置されたＨＤＤレコーダで録画されたＴＶ番組を、別の部屋にあるＤＶＤレコーダを用いてＤＶＤメディアにコピーしたりするような例が挙げられる。
【０００４】
このようなファイル転送を行うプロトコルとしては、古くはＦＴＰ（Ｆｉｌｅ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）や、最近ではＷｅｂＤＡＶ（Ｗｅｂ−ｂａｓｅｄ  Ｄｉｓｔｒｉｂｕｔｅｄ  Ａｕｔｈｏｒｉｎｇ  ａｎｄ  Ｖｅｒｓｉｏｎｉｎｇ  ｐｒｏｔｏｃｏｌ）などがある。そして、ホームネットワークにおいて映像や音楽などのＡＶコンテンツファイルを扱う場合のプロトコルとして、ＵＰｎＰ−ＡＶ（Ｕｎｉｖｅｒｓａｌ  Ｐｌｕｇ  ａｎｄ  Ｐｌａｙ  Ａｕｄｉｏ／Ｖｉｄｅｏ）規格（非特許文献１）が最近注目されている。
【０００５】
ＵＰｎＰ−ＡＶでは、コンテンツファイルそのものの転送方式を規定しているわけではなく、コンテンツファイルに付随された情報（メタデータ）に関するサービスや、コネクションに関するサービスなどについて規定している。中でもコンテンツファイルに付随された情報（メタデータ）に関するサービスであるＣＤＳ（Ｃｏｎｔｅｎｔ  Ｄｉｒｅｃｔｒｙ  Ｓｅｒｖｉｃｅ）は、ＵＰｎＰ−ＡＶ規格における最も基本的なサービスであり、コンテンツの付随情報（メタデータ）取得の他に、コンテンツの付随情報（メタデータ）そのものを、作成したり、削除したり、修正したりすることもできる。一方、ＵＰｎＰ−ＡＶと併用して用いられるコンテンツファイルの転送方式としては、ＨＴＴＰ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）や、ＲＴＰ（Ｒｅａｌ−ｔｉｍｅ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ）などが一般的である。
【０００６】
ユーザが操作する機器をクライアントとし、ネットワークに接続された相手の機器をサーバとすると、ＵＰｎＰ−ＡＶとＨＴＴＰを用いてサーバからクライアントにファイル転送を行う場合、まずＣＤＳ：：Ｂｒｏｗｓｅを用いてサーバからコンテンツファイルの付随情報（メタデータ）の一覧を取得し、ファイル転送したいコンテンツのファイル転送が可能なＵＲＬを取得することで、ＨＴＴＰ−ＧＥＴによりファイル転送を行う。この逆に、クライアントからサーバにファイル転送を行う場合、ＣＤＳ：：ＣｒｅａｔｅＯｂｊｅｃｔを用いてクライアントからサーバに対してファイル転送したいコンテンツの付随情報（メタデータ）の作成を依頼（作成依頼）し、作成依頼応答に含まれるＵＲＬ先に対して、ＨＴＴＰ−ＰＯＳＴによりファイル転送を行う。
【非特許文献１】ＵＰｎＰ−ＡＶ規格書
【発明の開示】
【発明が解決しようとする課題】
【０００７】
ところで、ここで問題となるのが、ファイル転送可能かどうかを判断するための、ディスク空き容量確認の方法である。
【０００８】
通常、サーバからクライアントに対してファイル転送する場合は、ファイル転送を行うコンテンツのデータ量がコンテンツファイルの付随情報（メタデータ）に記載されているので、クライアント側のディスク空き容量と比較して、ファイル転送可能かどうかの判断が行うことができる。
【０００９】
これに対して、クライアントからサーバに対してファイル転送する場合は、ファイル転送を行うコンテンツのデータ量は分かるものの、サーバ側のディスク空き容量を確認する仕組みが決められていない。
【００１０】
例えば、サーバ側の特定ディスク又は特定フォルダにファイル転送を行う際には、その特定ディスク又は特定フォルダの付随情報（メタデータ）に空き容量を示す情報が記述されている場合があるが、必ずしも記述されているとは限らない。この理由は、ＣＤＳで記述されるディスク又はフォルダなどがあくまで概念上のものであり、バーチャルなＯｂｊｅｃｔとして表現されているからであり、実際の物理的なディスク構成又はフォルダ構成と一致する必要がないからである。
【００１１】
このため、サーバ側のディスク空き容量を予め確認する技術の出現が強く望まれている。
【００１２】
そこで、本発明は、上記した問題を解決し、サーバ側のディスク空き容量を予め確認することができるメディア管理装置及びメディア管理方法を提供する目的とする。
【課題を解決するための手段】
【００１３】
上記目的を達成するために、本発明に係るメディア管理装置においては、ネットワークを介してユーザが操作するクライアント機器と通信可能に接続され、当該クライアント機器とファイルデータを送受信するサーバ機器に用いられるメディア管理装置であって、前記クライアント機器と通信する通信手段と、前記クライアント機器と送受信するファイルデータを蓄積するためのファイルデータ蓄積手段と、前記蓄積手段が確保する空き容量を示す残容量を取得するための残容量取得手段と、特定の文字列で構成されるキーワードを含む前記ファイルデータに関する付加情報取得要求を、前記クライアント機器から受信した場合に、前記残容量取得手段により取得された前記蓄積手段が確保する残容量を、当該クライアント機器に返答するプロトコル処理手段とを備えることを特徴とする。
【００１４】
これにより、クライアント機器は、ファイルデータを転送する前に、サーバ機器側のディスク空き容量を予め確認することができる。
【００１５】
なお、本発明は、このようなメディア管理装置として実現することができるだけでなく、このようなメディア管理装置が備える特徴的な手段をステップとするメディア管理方法として実現したり、それらのステップをコンピュータに実行させるプログラムとして実現したりすることもできる。そして、そのようなプログラムは、ＣＤ−ＲＯＭ等の記録媒体やインターネット等の伝送媒体を介して配信することができるのはいうまでもない。
【発明の効果】
【００１６】
以上の説明から明らかなように、本発明に係るメディア管理装置によれば、クライアント機器は、ファイルデータを転送する前に、サーバ機器側のディスク空き容量を予め確認することができる。
【００１７】
よって、本発明により、インターネットや、ホームネットワークを介して、家電機器、ＰＣ間で映像や音楽などのＡＶコンテンツファイルをコピーするようなアプリケーションが出現し、ＵＰｎＰ−ＡＶ規格が普及してきた今日における本願発明の実用的価値は極めて高い。
【発明を実施するための最良の形態】
【００１８】
以下、本発明の実施の形態について、図面を用いて詳細に説明する。
【００１９】
（実施の形態１）
図１は、本実施の形態１におけるシステムの全体構成を示すブロック図である。
【００２０】
図１に示されるように、システムは、サーバ機器１０と、クライアント機器２０と、サーバ機器１０及びクライアント機器２０を通信可能に接続する通信路３とを備える。
【００２１】
通信路３は、イーサネット（登録商標）などの有線通信路や、ＩＥＥＥ８０２．１１ｂ／ｇ、Ｂｌｕｅｔｏｏｔｈなどの無線通信路によって構成される。
【００２２】
サーバ機器１０は、クライアント機器２０に要求されたファイルデータ、例えば映像や、音楽、静止画などのコンテンツを送信したり、コンテンツに関する付加情報取得要求を、クライアント機器２０から受信した場合に、サーバ機器１０が確保する空き容量を示す残容量を、クライアント機器２０に返答したり、クライアント機器２０から送られてきたコンテンツを蓄積したりする。
【００２３】
クライアント機器２０は、ＵＰｎＰの機器検索機能によりサーバ機器１０を認識しており、コンテンツを取得する場合、サーバ機器１０からＣＤＳ：：Ｂｒｏｗｓｅを用いてサーバからコンテンツファイルの付随情報（メタデータ）の一覧を取得し、ファイル転送したいコンテンツのファイル転送が可能なＵＲＬを取得することで、ＨＴＴＰ−ＧＥＴによりファイル転送を行う。この逆に、コンテンツを転送する場合、特定の文字列で構成されるキーワードを含むファイルデータに関する付加情報取得要求を、サーバ機器１０に送信する。そして、サーバ機器１０からサーバ機器１０が確保する残容量を、受信し、残容量を予め確認する。そして、クライアント機器２０は、残容量が転送するコンテンツより大きければ、サーバ機器１０に転送する。
【００２４】
次いで、サーバ機器１０及びクライアント機器２０の詳細構成について順次説明する。
図２は、図１に示されるサーバ機器１０の主要部な機能構成を示すブロック図である。
【００２５】
図２に示されるように、サーバ機器１０は、通信部１１と、ＵＰｎＰ−ＡＶ規格のプロトコル処理部（以下、「ＵＰｎＰ−ＡＶプロトコル処理部」とも記す。）１２と、コンテンツデータ蓄積部１３と、コンテンツデータ受信部１４と、残容量取得部１５とを備える。
【００２６】
通信部１１は、通信路３を介してクライアント機器２０と通信する。
ＵＰｎＰ−ＡＶプロトコル処理部１２は、ＵＰｎＰ−ＡＶ規格に準拠した機器検索や能力交換などの処理を実行する。また、ＵＰｎＰ−ＡＶプロトコル処理部１２は、ＵＰｎＰ−ＡＶ規格に準拠したクライアント機器が送信したＵＰｎＰ−ＡＶコマンドを、通信部１１を介して受信し、受信したコマンドに従って動作する。
【００２７】
コンテンツデータ蓄積部１３は、録画されたテレビ番組や、ＤＶＣ（Ｄｉｇｉｔａｌ  Ｖｉｄｅｏ  Ｃａｍｅｒａ）などで撮影された動画データ、ＤＳＣ（Ｄｉｇｉｔａｌ  Ｓｔｉｌｌ  Ｃａｍｅｒａ）などで撮影された静止画データ、録音されたラジオ番組や録音されたＣＤ（Ｃｏｍｐａｃｔ  Ｄｉｓｃ）楽曲などの音声データ（以下、動画、静止画、音声の各データをコンテンツデータと呼ぶ。）を蓄積する。
【００２８】
クライアント機器２０では、これらのコンテンツデータのタイトル情報や、サイズ情報、録音録画日情報、ＵＲＬ（Ｕｎｉｆｏｒｍｅｄ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）等で表されるコンテンツデータの位置情報（以下、これらをまとめてメタデータと呼ぶ。）は、ＵＰｎＰ−ＡＶコマンド要求により、ＵＰｎＰ−ＡＶプロトコル処理部１２を介して取得することができる。
【００２９】
残容量取得部１５は、コンテンツデータ蓄積部１３に蓄積可能なコンテンツデータの空き容量（残容量）を取得する。
【００３０】
ＵＰｎＰ−ＡＶプロトコル処理部１２は、残容量取得部１５を通じてコンテンツデータ蓄積部１３の空き容量を取得し、クライアント機器からの空き容量を要求するＵＰｎＰ−ＡＶコマンドに対して応答する。
【００３１】
コンテンツデータ受信部１４は、ＨＴＴＰ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ）などを用いて、クライアント機器から送信されるコンテンツデータをコンテンツデータ蓄積部１３に蓄積する。
【００３２】
図３は、サーバ機器１０におけるコンテンツデータの管理構成例を示す図である。
管理構成上、これらはコンテンツデータと、仮想上のフォルダであるコンテナとで構成される。コンテナは、コンテンツデータ及びコンテナを格納するが、格納するコンテンツデータ或いはコンテナが存在しない場合もあり得る。またコンテンツデータの管理構成は、ＵＰｎＰ−ＡＶプロトコル処理部１２を通じてクライアント機器に公開する論理的な管理概念であり、実際にコンテンツデータ蓄積部１３のファイルシステム上では、必ずしも上記の構成が物理的に再現されていなくてもよい。
【００３３】
図３では、構成の最上位に位置するＲＯＯＴコンテナ３１からツリー状に、映像を格納するためのＶｉｄｅｏコンテナ３２、音楽を格納するためのＡｕｄｉｏコンテナ３３、静止画を格納するためのＰｈｏｔｏコンテナ３４で構成され、それぞれ映像、音楽、静止画コンテンツデータが格納されている。
【００３４】
図４は、図１に示されるクライアント機器２０の主要部な機能構成を示すブロック図である。
【００３５】
図４に示されるように、クライアント機器２０は、通信部２１と、ＵＰｎＰ−ＡＶ規格のプロトコル処理部（以下、「ＵＰｎＰ−ＡＶプロトコル処理部」とも記す。）２２と、コンテンツデータ送信部２３と、コンテンツデータ蓄積部２４と、容量比較部２５とを備える。
【００３６】
通信部２１は、通信路３を介してサーバ機器１０と通信する。
ＵＰｎＰ−ＡＶプロトコル処理部２２は、ＵＰｎＰ−ＡＶ規格に準拠したサーバ機器に対してＵＰｎＰ−ＡＶコマンドを送信し、サーバ機器を遠隔制御する。
【００３７】
コンテンツデータ蓄積部２４は、コンテンツデータを蓄積する。
容量比較部２５は、サーバ機器側で受信可能なコンテンツデータ容量と、送信したコンテンツデータの容量とを比較し、サーバ機器がコンテンツデータを受信可能か否か判定する。
【００３８】
コンテンツデータ送信部２３は、コンテンツデータ蓄積部２４に蓄積されたコンテンツデータをサーバ機器に対して送信する。
【００３９】
ここで、クライアント機器２０は、ＵＰｎＰの機器検索機能によりサーバ機器１０を認識している。そして、クライアント機器２０は、コンテンツデータをサーバ機器１０に送信するに先立って、これから送信したいコンテンツデータをサーバ機器が完全に受信し、サーバ機器１０内のコンテンツデータ蓄積部１３に記憶するだけの十分な空き容量が存在するか否かの確認を予め行うために、ＣＤＳ：：Ｂｒｏｗｓｅアクションを実行する。このＣＤＳ：：Ｂｒｏｗｓｅは、コンテンツデータ蓄積部１３に記憶された情報を取得するＵＰｎＰ−ＡＶコマンドである。
【００４０】
図５は、上記パラメータでＣＤＳ：：Ｂｒｏｗｓｅアクションを送信する際のＳＯＡＰ（Ｓｉｍｐｌｅ  Ｏｂｊｅｃｔ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ）の一例を示す図である。
【００４１】
ここでは、“ＡｎｙＣｏｎｔａｉｎｅｒ”というキーワードを用いてコンテナを指定する。“ＡｎｙＣｏｎｔａｉｎｅｒ”とは、クライアント機器がコンテンツデータの格納先を特定せずに、サーバ機器にとって都合のよいコンテナをサーバ機器が選んでよいということを示す予約キーワードとする。
【００４２】
次に情報を取得する対象として、指定コンテナ自身の情報の取得か、或いは指定コンテナの配下に存在する全てのコンテナ及びコンテンツデータの情報の取得かを選択するフラグを設定する。ここでは、コンテナ自身の情報が取得したいので、“ＢｒｏｗｓｅＭｅｔａｄａｔａ”をフラグとして設定する。
【００４３】
さらに、クライアント機器が必要な属性情報を指定するが、ここではクライアント機器は空き容量の確認を行いたいので、“ｕｐｎｐ：ｓｔｏｒａｇｅＦｒｅｅ”をキーワードに指定する。また、データ取得開始位置と、取得個数に関しては、ここでは共に“０”を指定する。並び替えキーワードに関しては指定しない。
【００４４】
図６は、サーバ機器−クライアント機器間で行われる空き容量確認のシーケンスを示す図である。
【００４５】
クライアント機器２０は、図５に示される内容を含むＣＤＳ：：Ｂｒｏｗｓｅ要求コマンドを送信する（Ｓ６０）。
【００４６】
ＣＤＳ：：Ｂｒｏｗｓｅ要求コマンドを受信したサーバ機器１０のＵＰｎＰ−ＡＶプロトコル処理部１２は、ＣＤＳ：：Ｂｒｏｗｓｅ要求コマンドを処理し（Ｓ６１）、コマンドの内容に従い、クライアント機器２０によって指定されたコンテナの空き容量を取得する（Ｓ６２、Ｓ６３、Ｓ６４、Ｓ６５）。
【００４７】
ここで、クライアント機器２０が、対象コンテナとして“ＡｎｙＣｏｎｔａｉｎｅｒ”を指定したので、サーバ機器１０のＵＰｎＰ−ＡＶプロトコル処理部１２は、任意のコンテナを選択する。ここでは例えば“Ｖｉｄｅｏ”を選択したので、クライアント機器２０に対しては“Ｖｉｄｅｏ”のコンテナを特定する識別子（例えば、ｃｏｎｔａｉｎｅｒ  ｉｄ＝２）と、その空き容量とを含むＣＤＳ：：Ｂｒｏｗｓｅ応答コマンドを生成し（Ｓ６６）、クライアント機器２０に応答する（Ｓ６７）。
【００４８】
図７は、応答コマンドに含まれるコンテナ情報の一例を示す図である。
クライアント機器２０のＵＰｎＰ−ＡＶプロトコル処理部２２は、通信部２１を介して受信したサーバ機器１０からの応答データを解釈し、“ＡｎｙＣｏｎｔａｉｎｅｒ”が実際には“Ｖｉｄｅｏ”が割り当てられ、残り容量が２１１６９４８９２３であることを予め知ることができる。
【００４９】
容量比較部２５は、送信したいコンテンツデータのサイズと、サーバ機器１０のコンテンツデータ蓄積部１３の残容量とを比較し、この後コンテンツデータを送信するか否か決定する。
【００５０】
ここで、ＵＰｎＰ−ＡＶでは、コンテナ及びコンテンツデータは、その種類に応じて様々なクラスに分類され、クラス毎に保持する属性が異なる。上記ｕｐｎｐ：ｓｔｏｒａｇｅＦｒｅｅは、ｏｂｊｅｃｔ．ｃｏｎｔａｉｎｅｒ．ｓｔｏｒａｇｅＶｏｌｕｍｅ及びｏｂｊｅｃｔ．ｃｏｎｔａｉｎｅｒ．ｓｔｏｒａｇｅＶｏｌｕｍｅの各クラスが保持する属性である。しかし、“ＡｎｙＣｏｎｔａｉｎｅｒ”に対してＣＤＳ：：Ｂｒｏｗｓｅアクションを受信した際には、サーバ機器は、全てのコンテナクラスにｕｐｎｐ：ｓｔｏｒａｇｅＦｒｅｅ属性を付与し、値を設定しなければならない。
【００５１】
サーバ機器１０のコンテンツデータ蓄積部１３に十分な空き容量があることが容量比較部２５により確認されれば、クライアント機器２０のコンテンツデータ送信部２３は、コンテンツデータを送信する。そして、サーバ機器１０のコンテンツデータ受信部１４は、通信部１１を介してクライアント機器２０から送信されてきたコンテンツデータを受信し、コンテンツデータ蓄積部１３に記録する。
【００５２】
したがって、ファイル受信するサーバ側において、特定のＯｂｊｅｃｔの格納先を、空き容量を示すためだけのフォルダに割り当てることで、クライアントは、ファイル転送する前に、特定Ｏｂｊｅｃｔに対して空き容量の確認を行うことができる。
【００５３】
なお、上記実施の形態においては、予約キーワードとして、“ＡｎｙＣｏｎｔａｉｎｅｒ”という文字を用いたが、文字をこれに限定されるものではない。また、“ＦｒｅｅＳｐａｃｅ”などの文字を、予約キーワードとして、残容量確認のみを可能とすることでも、同様の効果が得られる。
【００５４】
また、クライアント機器２０に配信するファイルのファイル構成情報には、コンテンツデータ蓄積部１３が確保する残容量だけを示すアイテムを定義し、キーワードがアイテムに対するものである場合に、残容量だけを示すアイテムをクライアント機器２０に返答するようにしてもよい。
【００５５】
（実施の形態２）
次いで、本発明の実施の形態２におけるシステムについて説明する。なお、本実施の形態２におけるクライアント機器２０及びサーバ機器１０の構成は実施の形態１と同じであり、サーバ機器１０の処理内容及び送受信される情報が異なるだけであるので、異なる点を詳述する。
【００５６】
図８は、クライアント機器２０−サーバ機器１０間で行われる空き容量確認の他のシーケンスを示す図である。
【００５７】
クライアント機器２０は、上記したＣＤＳ：：Ｂｒｏｗｓｅ要求コマンドに代えて、図８に示されるＣＭＳ：：ＧｅｔＰｒｏｔｏｃｏｌＩｎｆｏ要求コマンドを送信する（Ｓ８０）。ここで、ＣＭＳ（Ｃｏｎｎｅｃｔｉｏｎ  Ｍａｎａｇｅｍｅｎｔ  Ｓｅｒｖｉｃｅ）は、ＵＰｎＰ−ＡＶ規格の１つであり、コネクション管理を行うためのサービスである。
【００５８】
ＣＭＳ：：ＧｅｔＰｒｏｔｏｃｏｌＩｎｆｏ要求コマンドを受信したサーバ機器１０のＵＰｎＰ−ＡＶプロトコル処理部１２は、ＣＭＳ：：ＧｅｔＣｏｎｎｅｃｔｉｏｎＩｎｆｏ要求コマンドを処理し（Ｓ８１）、コマンドの内容に従い、クライアント機器２０によって指定されたコンテナの空き容量を、残容量取得部１５を介して取得する（Ｓ６２，Ｓ６３，Ｓ６４，Ｓ６５）。
【００５９】
ＣＭＳ：：ＧｅｔＣｏｎｎｅｃｔｉｏｎＩｎｆｏでは、サーバ機器がサポートしているコンテンツのフォーマットや、プロトコルに応じて記述されたＰｒｏｔｏｃｏｌＩｎｆｏ情報を応答で返す。具体的には、サーバ機器１０のＵＰｎＰ−ＡＶプロトコル処理部１２は、これらコンテンツのフォーマットや、プロトコルに応じて、クライアント機器２０からファイル転送が可能で、コンテンツデータ蓄積部１３が管理する複数のメディア毎に確保された残容量が記述された記述情報に基づいて、残容量をＰｒｏｔｏｃｏｌＩｎｆｏ情報の４つめのパラメータに記述する。残容量の情報を取得した後、ＵＰｎＰ−ＡＶプロトコル処理部１２は、ＣＭＳ：：ＧｅｔＰｒｏｔｏｃｏｌＩｎｆｏ応答コマンドを生成し（Ｓ８６）、クライアント機器２０に応答する（Ｓ８７）。
【００６０】
図９は、ＰｒｏｔｏｃｏｌＩｎｆｏ情報の記述例を示す図である。“：”で区切られた４つめのパラメータに、“ＦｒｅｅＳｐａｃｅ＝”を定義し、ここに容量の単位（ｂｙｔｅ又はＭｅｇａＢｙｔｅ）に応じて数値を記載する。図示例では、映像情報、音楽情報、静止画情報のそれぞれに、空き容量を個別に記載することが可能となっている。
【００６１】
したがって、ファイル受信するサーバ側において、特定のＯｂｊｅｃｔの格納先を、空き容量を示すためだけのメディア又はフォルダに割り当てることで、クライアントは、ファイル転送する前に、特定Ｏｂｊｅｃｔに対して空き容量の確認を行うことができる。
【００６２】
なお、上記実施の形態では、ファイルデータを映像や、音楽、静止画等のコンテンツとして説明したが、テキストデータ等のファイルデータに適用して実施してもよいのはいうまでもない。
【産業上の利用可能性】
【００６３】
本願発明に係るメディア管理装置は、ＨＤＤビデオレコーダや、セットトップボックス、パーソナルコンピュータ等、ネットワークに対応したＵＰｎＰ−ＡＶ規格のコンピュータ装置に適用することができる。
【図面の簡単な説明】
【００６４】
【図１】図１は、本実施の形態１におけるシステムの全体構成を示すブロック図である。
【図２】図２は、図１に示されるサーバ機器１０の主要部な機能構成を示すブロック図である。
【図３】図３は、サーバ機器１０におけるコンテンツデータの管理構成例を示す図である。
【図４】図４は、図１に示されるクライアント機器２０の主要部な機能構成を示すブロック図である。
【図５】図５は、上記パラメータでＣＤＳ：：Ｂｒｏｗｓｅアクションを送信する際のＳＯＡＰの一例を示す図である。
【図６】図６は、サーバ機器−クライアント機器間で行われる空き容量確認のシーケンスを示す図である。
【図７】図７は、応答コマンドに含まれるコンテナ情報の一例を示す図である。
【図８】図８は、クライアント機器２０−サーバ機器１０間で行われる空き容量確認の他のシーケンスを示す図である。
【図９】図９は、ＰｒｏｔｏｃｏｌＩｎｆｏ情報の記述例を示す図である。
【符号の説明】
【００６５】
３  通信路
１０  サーバ機器
１１，２１  通信部
１２，２２  ＵＰｎＰ−ＡＶプロトコル処理部
１３，２４  コンテンツデータ蓄積部
１４  コンテンツデータ受信部
１５  残容量取得部
２０  クライアント機器
２３  コンテンツデータ送信部
２５  容量比較部
３１  ＲＯＯＴコンテナ
３２  Ｖｉｄｅｏコンテナ
３３  Ａｕｄｉｏコンテナ
３４  Ｐｈｏｔｏコンテナ
【手続補正３】
【補正対象書類名】図面
【補正対象項目名】全図
【補正方法】変更
【補正の内容】
【図１】
2006106606.tif 000011
【図２】
2006106606.tif 000012
【図３】
2006106606.tif 000013
【図４】
2006106606.tif 000014
【図５】
2006106606.tif 000015
【図６】
2006106606.tif 000016
【図７】
2006106606.tif 000017
【図８】
2006106606.tif 000018
【図９】
2006106606.tif 000019
【国際調査報告】
2006106606.tif 000020
2006106606.tif 000021