(57)【要約】【課題】  取得要求のあったコンテンツ属性情報を確実に提供できるようにする。【解決手段】  メタデータ提供装置２０は、コンテンツ提供装置５０から提供されるコンテンツについて、コンテンツメタデータ取得アドレスと、親ディレクトリコンテンツ情報メタデータ取得アドレスとをレコードとする変換テーブルに記憶する。ＤＬＮＡ機器３０からコンテンツメタデータの取得要求があると、メタデータ提供装置２０は、変換テーブルに記憶されているコンテンツメタデータ取得アドレスを用いて、コンテンツ提供装置５０からコンテンツメタデータを取得し、ＤＬＮＡ機器３０が処理できる形式に変換し、ＤＬＮＡ機器３０に送信する。この際、コンテンツ識別子として、該当するコンテンツメタデータ取得アドレスを、親ディレクトリコンテンツ識別子として、該当する親ディレクトリコンテンツ情報メタデータ取得アドレスを夫々用いる。【選択図】  図１
2010282374.tif 000002
【特許請求の範囲】
【請求項１】
コンテンツ提供装置が管理している記憶領域の中のコンテンツに関するコンテンツ属性情報を前記コンテンツ提供装置から取得する取得手段と、
前記取得手段により取得されたコンテンツ属性情報に基づいて、前記コンテンツが記憶された記憶領域を示す識別子と、前記コンテンツを示す識別子とを記憶媒体に記憶する記憶手段と、
コンテンツに関する所定の形式のコンテンツ属性情報を受信する受信装置から前記コンテンツ属性情報の取得要求を受信した場合に、前記記憶手段により記憶されたコンテンツ属性情報と、前記コンテンツを示す識別子と、前記コンテンツが記憶された記憶領域を示す識別子とを、前記所定の形式で前記受信装置に送信する送信手段と、
を備えることを特徴とするコンテンツ属性情報提供装置。
【請求項２】
前記記憶手段は、
前記受信装置から、前記記憶領域の中のコンテンツに関するコンテンツ属性情報の取得要求を受信した場合に、前記記憶領域を示す識別子と、前記コンテンツを示す識別子とを記憶媒体に記憶することを特徴とする請求項１に記載のコンテンツ属性情報提供装置。
【請求項３】
前記記憶手段は、
前記コンテンツ提供装置から、前記取得要求のあったコンテンツ属性情報に係るコンテンツが属する１つ又は複数の記憶領域を示す識別子と、当該コンテンツを示す識別子とを取得して記憶媒体に記憶することを特徴とする請求項１又は２に記載のコンテンツ属性情報提供装置。
【請求項４】
前記コンテンツ属性情報を示す識別子、及び前記記憶領域を示す識別子は、
前記コンテンツ提供装置から、当該識別子に対応する前記コンテンツ属性情報を取得するためのアドレスであること、
を特徴とする請求項１〜３の何れか１項に記載のコンテンツ属性情報提供装置。
【請求項５】
コンテンツ提供装置が管理している記憶領域の中のコンテンツに関するコンテンツ属性情報を前記コンテンツ提供装置から取得する取得ステップと、
前記取得ステップにより取得されたコンテンツ属性情報に基づいて、前記コンテンツが記憶された記憶領域を示す識別子と、前記コンテンツを示す識別子とを記憶媒体に記憶する記憶ステップと、
コンテンツに関する所定の形式のコンテンツ属性情報を受信する受信装置から前記コンテンツ属性情報の取得要求を受信した場合に、前記記憶されたコンテンツ属性情報と、前記コンテンツを示す識別子と、前記コンテンツが記憶された記憶領域を示す識別子とを、前記所定の形式で前記受信装置に送信する送信ステップと、
を備えることを特徴とするコンテンツ属性情報提供方法。
【請求項６】
前記記憶ステップは、
前記受信装置から、前記記憶領域の中のコンテンツに関するコンテンツ属性情報の取得要求を受信した場合に、前記記憶領域を示す識別子と、前記コンテンツを示す識別子とを記憶媒体に記憶することを特徴とする請求項５に記載のコンテンツ属性情報提供方法。
【請求項７】
前記記憶ステップは、
前記コンテンツ提供装置から、前記取得要求のあったコンテンツ属性情報に係るコンテンツが属する１つ又は複数の記憶領域を示す識別子と、当該コンテンツを示す識別子とを取得して記憶媒体に記憶することを特徴とする請求項５又は６に記載のコンテンツ属性情報提供方法。
【請求項８】
前記コンテンツ属性情報を示す識別子、及び前記記憶領域を示す識別子は、
前記コンテンツ提供装置から、当該識別子に対応する前記コンテンツ属性情報を取得するためのアドレスであること、
を特徴とする請求項５〜７の何れか１項に記載のコンテンツ属性情報提供方法。
【請求項９】
コンテンツ提供装置が管理している記憶領域の中のコンテンツに関するコンテンツ属性情報を前記コンテンツ提供装置から取得する取得ステップと、
前記取得ステップにより取得されたコンテンツ属性情報に基づいて、前記コンテンツが記憶された記憶領域を示す識別子と、前記コンテンツを示す識別子とを記憶媒体に記憶する記憶ステップと、
コンテンツに関する所定の形式のコンテンツ属性情報を受信する受信装置から前記コンテンツ属性情報の取得要求を受信した場合に、前記記憶されたコンテンツ属性情報と、前記コンテンツを示す識別子と、前記コンテンツが記憶された記憶領域を示す識別子とを、前記所定の形式で前記受信装置に送信する処理を行う送信ステップと、
をコンピュータに実行させることを特徴とするコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンテンツ属性情報提供装置、コンテンツ属性情報提供方法、及びコンピュータプログラムに関し、特に、ネットワーク上にコンテンツに関するコンテンツ属性情報を提供するために用いて好適なものである。
【背景技術】
【０００２】
ＵＰｎＰ（Universal Plug and Play）を利用したＤＬＮＡ（Digital Living Network Alliance）では、次のような仕組みが規定されている。すなわち、デジタルメディアサーバ（ＤＭＳ：Digital Media Server）を用いて、コンテンツを蓄積し、ホームネットワーク内の他の機器に対してコンテンツや、コンテンツに付随するメタデータを提供する仕組みが規定されている。ＤＭＳの例としては、撮影したコンテンツを蓄積するカメラ装置や、放送コンテンツを蓄積する放送コンテンツ記録再生装置等が挙げられる。
一方、インターネット上の写真共有サイトやビデオ共有サイト等のＷｅｂサービスが注目されている。これもインターネット上のコンテンツ提供装置にコンテンツを蓄積し、当該コンテンツやコンテンツメタデータ（コンテンツ属性情報）を提供するサービスである。
【０００３】
しかし、ＵＰｎＰ／ＤＬＮＡにおいて規定されているコンテンツメタデータと、インターネット上のコンテンツ提供装置で利用されるコンテンツメタデータとでは、形式、及び提供方法が異なる。そのため、コンテンツ提供装置は、ホームネットワーク内の機器に対して、インターネット上のコンテンツ提供装置で利用されるコンテンツメタデータをホームネットワーク内の機器に提供することができなかった。
そこで、コンテンツ提供装置に代わり、メタデータ提供装置がコンテンツ提供装置からコンテンツメタデータをホームネットワーク内の機器が解釈できる形式に変換した上で事前に収集し、ホームネットワーク内の機器に提供する技術がある（特許文献１を参照）。このメタデータ提供装置は、コンテンツ提供装置からコンテンツメタデータを収集、変換した後、ディレクトリ構造に展開した上でメタデータ提供装置の内部に保持する。そして、ホームネットワーク内の機器からのコンテンツメタデータの取得要求に対して、メタデータ提供装置はメタデータ提供装置の内部に保持した変換済みのコンテンツメタデータをホームネットワーク内の機器に提供する。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００４−１０２７６７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、前述した従来技術でも、メタデータ提供装置は、コンテンツ提供装置から取得できないコンテンツメタデータについてはホームネットワーク内の機器に提供することはできないという問題点があった。
本発明は、このような問題点に鑑みてなされたものであり、取得要求のあったコンテンツ属性情報を確実に提供できるようにすることを目的とする。
【課題を解決するための手段】
【０００６】
本発明のコンテンツ属性情報提供装置は、コンテンツ提供装置が管理している記憶領域の中のコンテンツに関するコンテンツ属性情報を前記コンテンツ提供装置から取得する取得手段と、前記取得手段により取得されたコンテンツ属性情報に基づいて、前記コンテンツが記憶された記憶領域を示す識別子と、前記コンテンツを示す識別子とを記憶媒体に記憶する記憶手段と、コンテンツに関する所定の形式のコンテンツ属性情報を受信する受信装置から前記コンテンツ属性情報の取得要求を受信した場合に、前記記憶手段により記憶されたコンテンツ属性情報と、前記コンテンツを示す識別子と、前記コンテンツが記憶された記憶領域を示す識別子とを、前記所定の形式で前記受信装置に送信する送信手段と、を備えることを特徴とする。
【発明の効果】
【０００７】
本発明によれば、取得要求のあったコンテンツ属性情報を従来よりも確実に提供することができる。
【図面の簡単な説明】
【０００８】
【図１】メタデータ提供システムの構成例を示す図である。
【図２】メタデータ提供装置のハードウェア構成例を示すブロック図である。
【図３】メタデータ提供装置のモジュール構成例を示すブロック図である。
【図４】コンテンツ提供装置内のディレクトリ構造を示す図である。
【図５】変換テーブルを示す図である。
【図６】初期動作を行う際の処理を説明するフローチャートである。
【図７】コンテンツメタデータの取得要求を受信した際の処理を説明するフローチャートである。
【図８】図７に続くフローチャートである。
【図９】図７に続くフローチャートである。
【図１０】コンテンツリストメタデータの取得要求メッセージを示す図である。
【図１１】コンテンツリストメタデータを示す図である。
【図１２】コンテンツリストメタデータの取得要求メッセージを示す図である。
【図１３】コンテンツリストメタデータを示す図である。
【図１４】コンテンツ情報メタデータの取得要求メッセージを示す図である。
【図１５】コンテンツ情報メタデータの一例を示す図である。
【発明を実施するための形態】
【０００９】
以下、図面を参照して、本発明に関わる一実施形態を説明する。
図１は、本実施形態によるメタデータ提供システムの構成例を示す図である。
ＬＡＮ１０は、ホームネットワークとしての有線ＬＡＮ（Local Area Network）又は無線ＬＡＮ（Wireless LAN）である。尚、本実施形態では、ホームネットワークとして有線ＬＡＮ又は無線ＬＡＮを利用しているが、ホームネットワークはこれらに限られない。ホームネットワークは、例えば、ＷＡＮ（Wide Area Network）、アドホックネットワーク、Bluetooth（登録商標）、Zigbee、ＵＷＢ等でもよい。
メタデータ提供装置２０は、ＬＡＮ１０上のＤＬＮＡ機器３０からのコンテンツメタデータの取得要求に対して、コンテンツ提供装置５０のコンテンツメタデータを取得し、所定のDIDL-Lite形式に変換して、ＤＬＮＡ機器３０に提供する。本実施形態において、メタデータ提供装置２０は、ＤＬＮＡにおけるＤＭＳとしての機能を有する。メタデータ提供装置２０が有するメタデータ提供サービスは、ＤＭＳにおけるＣＤＳ（Content Directory Service）が挙げられる。メタデータ提供装置２０の具体的な例としては、ステーション装置、クレードル装置、ネットワーク中継装置、ＰＣ装置が挙げられる。尚、本実施形態では、メタデータ提供装置２０としてＤＬＮＡにおけるＤＭＳの機能を有する装置を挙げた。しかし、メタデータ提供装置は、メタデータ提供装置２０と同様にホームネットワーク内にコンテンツメタデータを提供する機能等を有する装置であればどのような装置であってもよい。
【００１０】
ＤＬＮＡ機器３０は、ホームネットワーク内の機器である。ＤＬＮＡ機器３０は、メタデータ提供装置２０が提供するコンテンツメタデータを閲覧する。ＤＬＮＡ機器３０の具体的な例としては、ＤＭＣ（Digital Media Controller）、ＤＭＰ（Digital Media Player）が挙げられる。尚、本実施形態では、受信装置の一例としてＤＬＮＡ機器を挙げた。しかし、受信装置は、ＤＬＮＡ機器３０と同様に、ホームネットワーク内でコンテンツメタデータを取得する機能等を有していればどのような装置であってもよい。
インターネット４０は、インターネットとしてのＷＡＮである。尚、本実施形態では、インターネットとしてＷＡＮを利用しているが、ＷＡＮの代わりに、ＬＡＮ、アドホックネットワーク、公衆回線、ＮＧＮ（Next Generation Network）等を用いてもよい。
コンテンツ提供装置５０は、インターネット４０上において、コンテンツ及びコンテンツメタデータを提供する。尚、本実施形態では、コンテンツ提供装置５０が提供するコンテンツメタデータの形式及び提供方法は、メタデータ提供装置２０がＤＬＮＡ機器３０に提供するコンテンツメタデータの形式及び提供方法と異なるものとする。コンテンツ提供装置５０の具体的な例としては、ＰＣ装置、サーバ装置が挙げられる。
尚、図１では、メタデータ提供装置２０、ＤＬＮＡ機器３０、及びコンテンツ提供装置５０が夫々１つずつ配置された場合を例に挙げて説明した。しかしながら、メタデータ提供装置２０、ＤＬＮＡ機器３０、及びコンテンツ提供装置５０の少なくとも何れか１つが複数あってもよい。
【００１１】
図２は、メタデータ提供装置２０のハードウェア構成例を示すブロック図である。尚、メタデータ提供装置２０は、ＰＣ等のコンピュータシステム以外の装置であっても実現することができる。すなわち、メタデータ提供装置２０は、他のネットワーク制御装置と通信するための通信機能を有する各種端末、又は、これらの組合せによっても実施可能である。端末としては、例えば、ワークステーション、ノートブックＰＣ、パームトップＰＣ、コンピュータを内蔵したテレビ等の各種家電製品、通信機能を有するゲーム機、携帯電話、ＰＨＳ等が挙げられる。
図２において、ＣＰＵ（Central Processing Unit）２０１は、メタデータ提供装置２０全体を制御する。ＲＯＭ（Read Only Memory）２０２は、変更を必要としないプログラムやパラメータを格納する。ＲＡＭ（Random Access Memory）２０３は、外部装置等から供給されるプログラムやデータを一時的に記憶する。外部記憶装置２０４は、メタデータ提供装置２０に固定して設置されたハードディスクやメモリカード、或いはメタデータ提供装置２０から着脱可能なフレキシブルディスク（ＦＤ）、コンパクトディスク（ＣＤ）等の光ディスク等である。また、外部記憶装置２０４として、磁気カードや光カード、ＩＣカード、メモリカード等を用いてもよい。ＬＡＮインタフェース２０５は、ＬＡＮ１０に接続するための通信制御を行う。システムバス２０６は、２０１〜２０５の各ユニットを通信可能に接続する。
【００１２】
図３は、メタデータ提供装置２０のモジュール構成例を示すブロック図である。
ＬＡＮ通信制御部３０１は、ＬＡＮ１０に接続するための通信制御を行う。
ＳＳＤＰ処理部３０２は、ＬＡＮ通信制御部３０１から、対応するパケットを受信し、ＵＰｎＰのＳＳＤＰ（Simple Service Discovery Protocol）処理を行う。ＳＳＤＰ処理は、メタデータ提供装置２０がＤＭＳとしてＬＡＮ１０上に存在することをＬＡＮ１０上のＤＬＮＡ機器３０を含む他のＤＬＮＡ機器に広告する。これは、ＳＳＤＰにおけるaliveメッセージと呼ばれる。また、ＳＳＤＰ処理は、ＬＡＮ１０上の他のＵＰｎＰサービスを発見したり、他のＤＬＮＡ機器からのＵＰｎＰサービスの発見に関する応答を行ったりする。尚、本実施形態ではＳＳＤＰ処理を利用しているが、ＳＳＤＰ処理の代わりに、WS-DiscoveryやＭＡＣ（Media Access Control）アドレス等を用いた別の手段を利用してもよい。
【００１３】
ＳＯＡＰ処理部３０３は、ＬＡＮ通信制御部３０１から、対応するパケットを受信し、ＵＰｎＰのＳＯＡＰ（Simple Access Object Protocol）処理を行う。ＳＯＡＰ処理は、他のＵＰｎＰサービスへの要求を行ったり、他のＤＬＮＡ機器からのＵＰｎＰサービスの要求を受け付けたり、その要求に対する応答を行ったりする。特に、ＳＯＡＰ処理部３０３は、ＬＡＮ１０上のＤＬＮＡ機器３０から、コンテンツ属性情報の一例であるコンテンツメタデータの取得要求を受け付ける。さらに、ＳＯＡＰ処理部３０３は、コンテンツメタデータの取得要求に対する応答をＤＬＮＡ機器３０に送信する。尚、本実施形態ではＳＯＡＰ処理を利用しているが、ＳＯＡＰ処理の代わりに、リモートプロシージャコール等、遠隔のオブジェクトを実行する別の手段を利用してもよい。
ＧＥＮＡ処理部３０４は、ＬＡＮ通信制御部３０１から、対応するパケットを受信し、ＵＰｎＰのＧＥＮＡ（General Event Notification Architecture）処理を行う。ＧＥＮＡ処理は、ＬＡＮ１０上の他のＤＬＮＡ機器へイベントの通知を行ったり、他のＤＬＮＡ機器が有するＵＰｎＰサービスのイベントの購読を行ったりする。尚、本実施形態ではＧＥＮＡ処理を利用しているが、ＧＥＮＡ処理の代わりに、WS-Eventing、WS-Notification等を用いた別の手段を利用してもよい。
制御部３０５は、メタデータ提供装置２０の全体の制御を行う。制御部３０５は、３０１〜３１４の各モジュールを管理、制御する。
【００１４】
要求メタデータ判別部３０６は、ＳＯＡＰ処理部３０３で受け付けた"ＬＡＮ１０上のＤＬＮＡ機器３０からのコンテンツメタデータの取得要求"に対して、要求対象のコンテンツ識別子と、要求メタデータ種別を判別する。本実施形態では、判別する要求メタデータ種別として、ＣＤＳのBrowseアクションにおいてメタデータ種別を示すBrowseFlagパラメータを用いる。
具体的に、BrowseFlagパラメータは、BrowseMetadataと、BrowseDirectChildren、の２種類から構成される。BrowseMetadataは、対象コンテンツ自身に関するコンテンツメタデータの取得要求を示す。一方、BrowseDirectChildrenは、対象コンテンツのクラスがDIDL-Liteにおけるコンテナ（Container）の場合、そのコンテナに含まれるコンテンツのリストの取得要求を示す。コンテナはいわばディレクトリである。また、BrowseDirectChildrenは、ディレクトリ内のコンテンツのリスト（コンテンツリスト）のコンテンツメタデータの取得要求を意味する。
【００１５】
前述したように、コンテンツメタデータには２種類存在する。以後、本実施形態では、コンテンツ自身に関するコンテンツメタデータを、コンテンツ情報メタデータと称する。一方、コンテンツリストに関するコンテンツメタデータを、コンテンツリストメタデータと称する。
メタデータ取得アドレス決定部３０７は、要求メタデータ判別部３０６の要求メタデータ種別の判別結果に基づき、コンテンツ提供装置５０から取得するコンテンツメタデータのアドレスを決定する。本実施形態におけるコンテンツメタデータのアドレスとは、ＵＲＩ（Uniform Resource Identifier）である。より具体的に、要求メタデータ判別部３０６の要求メタデータ種別の判別結果がBrowseMetadataである場合、メタデータ取得アドレス決定部３０７は、コンテンツ情報メタデータ取得アドレスをコンテンツメタデータのアドレスとして決定する。一方、要求メタデータ判別部３０６の要求メタデータ種別の判別結果がBrowseDirectChildrenである場合、メタデータ取得アドレス決定部３０７は、コンテンツリストメタデータ取得アドレスをコンテンツメタデータのアドレスとして決定する。
【００１６】
メタデータ取得部３０８は、メタデータ取得アドレス決定部３０７で決定したアドレスに基づき、コンテンツ提供装置５０からコンテンツメタデータを取得する。
変換テーブル作成部３０９は、メタデータ取得部３０８で取得したコンテンツメタデータから、DIDL-Liteに変換する際に必要となる情報を抽出し、変換レコードを作成する。変換テーブル作成部３０９は、作成した変換レコードを、記憶部３１４を介して、図２に示したメタデータ提供装置２０の外部記憶装置２０４内に用意した変換テーブル内に記憶する。変換テーブルの内容については後述する。
メタデータ変換部３１０は、メタデータ取得部３０８で取得したコンテンツメタデータを、変換テーブル作成部３０９で作成した変換テーブルを用いて、所定のDIDL-Lite形式のコンテンツメタデータに変換する。
メタデータ提供部３１１は、メタデータ変換部３１０で変換したコンテンツメタデータを、ＳＯＡＰ処理部３０３を介して、ＣＤＳのBrowseアクションの応答として、ＬＡＮ１０上のＤＬＮＡ機器３０に返す。
ユーザ情報管理部３１２は、記憶部３１４を介して、図２に示したメタデータ提供装置２０の外部記憶装置２０４内に記憶したユーザ情報テーブルの管理を行う。ユーザ情報テーブルは、コンテンツ提供装置５０を利用する際のユーザアカウント情報から構成される。
コンテンツ提供装置管理部３１３は、コンテンツ提供装置５０へのログインを行う。
記憶部３１４は、対象となる情報を、図２に示したメタデータ提供装置２０の外部記憶装置２０４内の記憶領域に記憶する。記憶部３１４は、例えば、変換テーブル作成部３０９が作成した変換テーブルや、ユーザ情報管理部３１２が作成したユーザ情報テーブルを外部記憶装置２０４内の記憶領域に記憶する。
【００１７】
ここで、図３に示したメタデータ提供装置２０のユーザ情報管理部３１２が管理するユーザ情報テーブルの例を説明する。本実施形態では、ユーザ情報テーブルは、ユーザＩＤ、パスワード、及びルートコンテンツ情報メタデータ取得アドレスをレコードとするテーブルにより構成される。
ユーザＩＤ及びパスワードは、コンテンツ提供装置５０を利用するために必要なユーザ単位の認証情報である。尚、本実施形態では、ユーザ情報テーブルに記憶されている"ユーザＩＤ及びパスワード"をユーザ認証に利用する場合を例に挙げて説明したが、認証トークン等の別の手段を利用してユーザ認証を行うようにしてもよい。
ルートコンテンツ情報メタデータ取得アドレスは、現在のコンテンツ提供装置５０の利用ユーザについて、ルートディレクトリにおけるコンテンツ情報メタデータを取得するためのアドレスである。これは、コンテンツ提供装置５０の利用ユーザ毎に異なる。通常、ユーザがコンテンツ提供装置５０にアカウントを開設する際、コンテンツ提供装置５０がこのルートコンテンツ情報メタデータ取得アドレスを決定する。よって、このルートコンテンツ情報メタデータ取得アドレスは静的に一意なアドレスとなる。本実施形態では、ルートコンテンツ情報メタデータ取得アドレスは、コンテンツ提供装置５０が規定する方式に基づき、ベースアドレスとユーザＩＤとの組合せから事前に決定されるものとする。
尚、本実施形態では、ユーザ情報テーブルに保持されているルートコンテンツ情報メタデータ取得アドレスを利用するが、必ずしもこのようにする必要はない。例えば、ユーザ情報テーブルにルートコンテンツ情報メタデータ取得アドレスを保持せず、コンテンツ提供装置５０が規定するベースアドレスとユーザＩＤの組合せからルートコンテンツ情報メタデータ取得アドレスを動的に決定する等の別の手段を利用してもよい。
【００１８】
図４は、コンテンツ提供装置５０内のディレクトリ構造の一例を示す図である。具体的に図４は、ユーザ情報テーブルにおけるユーザＩＤ"User1"のディレクトリ構造の一例を示す図である。
図４におけるルートディレクトリ内の"User1"は、コンテンツ提供装置５０内の"User1"に対するルートディレクトリである。"［diretory］"はこのコンテンツがディレクトリであることを示す。上段の"User1RootInfoURI"は、ルートディレクトリ"User1"に対するコンテンツ情報メタデータ取得アドレスである。"User1"のルートディレクトリに対するコンテンツ情報メタデータ取得アドレスは、ユーザ情報管理部３１２が管理するユーザ情報テーブルのルートコンテンツ情報メタデータ取得アドレスである。下段の"User1RootContentListURI"は、ルートディレクトリ"User1"に対するコンテンツリストメタデータ取得アドレスである。
【００１９】
図４の１階層目のディレクトリ１内の"Album1"は、ルートディレクトリ"User1"内に含まれるディレクトリ（サブディレクトリ）である。上段の"User1Album1InfoURI"は、ディレクトリ"Album1"に対するコンテンツ情報メタデータ取得アドレスである。下段の"User1Album1ContentListURI"は、ディレクトリ"Album1"に対するコンテンツリストメタデータ取得アドレスである。
図４の２階層目のディレクトリ２内の"Photo1"は、ディレクトリ"Album1"内に含まれるメディアである。"［media］"はこのコンテンツがメディアであることを示す。上段の"User1Photo1InfoURI"は、メディア"Photo1"に対するコンテンツ情報メタデータ取得アドレスである。なお、メディア"Photo1"はディレクトリではないため、コンテンツリストメタデータ取得アドレスは存在しない。
図４のその他の欄も以上と同様の内容であるため、その詳細な説明を省略する。
尚、本実施形態では、２階層のディレクトリ構造の場合を例に挙げたが、ディレクトリ構造は２層に限らず、３階層以上のディレクトリ構造や、同一ディレクトリ内にディレクトリコンテンツとメディアコンテンツとが混在していてもよい。
【００２０】
図５は、図３に示したメタデータ提供装置２０の変換テーブル作成部３０９において作成された変換テーブルの一例を示す図である。具体的に図５は、図４に示したコンテンツ提供装置５０内のディレクトリ構造に対する変換テーブルの一例を示す図である。本実施形態では、変換テーブルは、コンテンツ情報メタデータ取得アドレス、親ディレクトリコンテンツ情報メタデータ取得アドレス、及びコンテンツリストメタデータ取得アドレスをレコードとするテーブルである。
図５のコンテンツ情報メタデータ取得アドレスは、コンテンツ提供装置５０内からコンテンツ情報メタデータ（コンテンツ自身に関するコンテンツメタデータ）を取得するためのアドレスである。コンテンツ情報メタデータ取得アドレスは、コンテンツ提供装置５０から提供されたコンテンツメタデータをDIDL-Liteに変換される際、DIDL-Liteの各コンテンツにおけるコンテンツ識別子（ＩＤ）として利用される。
ただし、ＤＬＮＡの仕様において、DIDL-Liteのルートコンテナ（ルートディレクトリ）におけるコンテンツ識別子は、"０"で固定されている。そのため、本実施形態では、図５に示した変換テーブルの最初のレコードにおいて、ルートディレクトリ"User1"に対するコンテンツ情報メタデータ取得アドレスを"０"とする。ルートディレクトリ"User1"におけるコンテンツ情報メタデータ取得アドレスは、ユーザ情報テーブル内のユーザＩＤ"User1"におけるルートコンテンツ情報メタデータ取得アドレスを用いる。
【００２１】
親ディレクトリコンテンツ情報メタデータ取得アドレスは、同一レコード中におけるコンテンツ情報メタデータ取得アドレスが示すコンテンツの親ディレクトリ（上の階層のディレクトリ）に関するコンテンツ情報メタデータ取得アドレスである。親ディレクトリコンテンツ情報メタデータ取得アドレスは、コンテンツ提供装置５０から提供されたDIDL-Liteに変換される際、DIDL-Liteの各コンテンツにおける親ディレクトリコンテンツ識別子（ParentID）として利用される。コンテンツの親ディレクトリコンテンツ情報メタデータ取得アドレスは、そのコンテンツが記憶された記憶領域を示す識別子である。
ディレクトリである"Album1"（"User1Album1InfoURI"）の親ディレクトリコンテンツ情報メタデータ取得アドレスは、親ディレクトリであるルートディレクトリのコンテンツ情報メタデータ取得アドレス"０"である。
ただし、ＤＬＮＡの仕様において、DIDL-Liteのルートコンテナ（ルートディレクトリ）における親コンテンツ識別子は、"−１"で固定されている。そのため、本実施形態では、図５に示した変換テーブルの最初のレコードにおいて、ルートディレクトリに対応する親ディレクトリコンテンツ情報メタデータ取得アドレスは"−１"となる。
コンテンツリストメタデータ取得アドレスは、同一レコード中におけるコンテンツ情報メタデータ取得アドレスが示すコンテンツが所属するリストに関するコンテンツリストメタデータを取得するためのアドレスである。つまり、コンテンツリストメタデータ取得アドレスは、同一レコード中におけるコンテンツ情報メタデータ取得アドレスが示すコンテンツがコンテナ（ディレクトリ）の場合にのみ有効となる。そのため、図５に示した変換テーブルの４レコード目において、メディア"Photo1"に対するコンテンツリストメタデータ取得アドレスは存在しない。変換テーブルの４レコード目と同様に、変換テーブルの５レコード目以降についてもコンテンツリストメタデータ取得アドレスは存在しない。
【００２２】
図６は、コンテンツ提供装置５０のコンテンツメタデータを、ＬＡＮ１０上のＤＬＮＡ機器３０に提供するために必要な初期動作を行う際のメタデータ提供装置２０の処理の一例を説明するフローチャートである。
ステップＳ６０１において、ユーザ情報管理部３１２は、コンテンツ提供装置５０を利用する利用ユーザを決定する。この利用ユーザは、ユーザ情報テーブルのユーザＩＤ内から決定する。利用ユーザの決定は、メタデータ提供装置２０に対してユーザが行った設定に基づいて事前に行う方法等によって行われる。
次に、ステップＳ６０２において、コンテンツ提供装置管理部３１３は、ステップＳ６０１で決定した利用ユーザの情報に基づいて、コンテンツ提供装置５０にログインする。このとき、コンテンツ提供装置管理部３１３は、ユーザ情報テーブル中の当該利用ユーザに対応する"ユーザＩＤとパスワード"を用いて、コンテンツ提供装置５０に対して認証処理を依頼する。
【００２３】
次に、ステップＳ６０３において、コンテンツ提供装置管理部３１３は、ユーザ情報テーブル中の当該利用ユーザに対応するルートコンテンツ情報メタデータ取得アドレスを取得する。
次に、ステップＳ６０４において、メタデータ取得部３０８は、ステップＳ６０３で取得したルートコンテンツ情報メタデータ取得アドレスを用いて、コンテンツ提供装置５０からルートディレクトリのコンテンツ情報メタデータを取得する。
次に、ステップＳ６０５において、変換テーブル作成部３０９は、ルートディレクトリのコンテンツリストメタデータ取得アドレスを決定する。コンテンツリストメタデータ取得アドレスの決定方法には、次の２つの方法がある。１つ目は、ステップＳ６０４で取得したコンテンツ情報メタデータ内にコンテンツリストメタデータ取得アドレスが直接記載されている場合である。２つ目は、コンテンツ提供装置５０が規定する方式に基づき、コンテンツリストメタデータ取得アドレスに関するベースアドレスと、ルートコンテンツに関する情報との組合せから一意に決定可能な場合である。ルートコンテンツに関する情報とは、例えばコンテンツ識別子等であり、ステップＳ６０４で取得したコンテンツ情報メタデータ内に記載されている。これらの決定方法は、コンテンツ提供装置５０によって異なるが、本実施形態では以後、前者の場合を仮定する。当然、後者の場合でも実施できる。
【００２４】
次に、ステップＳ６０６において、変換テーブル作成部３０９は、ステップＳ６０５で決定したコンテンツリストメタデータ取得アドレスを用いて、ルートディレクトリに対する変換レコードを作成する。そして、変換テーブル作成部３０９は、作成した変換レコードを、記憶部３１４を介して、図２に示したメタデータ提供装置２０の外部記憶装置２０４内に用意した変換テーブル内に記憶する。
このステップＳ６０６で作成される"ルートディレクトリに対する変換レコード"とは、具体的に、図５に示した変換テーブルの最初のレコードである。前述したように、ルートディレクトリにおけるコンテンツ情報メタデータ取得アドレスは"０"、親ディレクトリコンテンツ情報メタデータ取得アドレスは"−１"である。また、コンテンツリストメタデータ取得アドレスは、ステップＳ６０５で決定したものであり、この例では"User1RootContentListURI"である。
【００２５】
図７は、ＬＡＮ１０上のＤＬＮＡ機器３０からコンテンツメタデータの取得要求を受信した際のメタデータ提供装置２０におけるメタデータ提供動作の一例を説明するフローチャートである。
ステップＳ７０１において、制御部３０５は、ＬＡＮ１０上のＤＬＮＡ機器３０からコンテンツメタデータの取得要求を受信したか否かを判定する。具体的には、制御部３０５は、ＳＯＡＰ処理部３０３がＣＤＳのBrowseアクションを受信したかどうかを判定する。この判定の結果、コンテンツメタデータの取得要求を受信していなければ、制御部３０５は再びステップＳ７０１の処理を繰り返す。一方、コンテンツメタデータの取得要求を受信したならば、ステップＳ７０２に進む。
ステップＳ７０２において、要求メタデータ判別部３０６は、ステップＳ７０１で受信したコンテンツメタデータの取得要求から、要求対象のコンテンツの識別子（要求対象コンテンツ識別子）を取得する。具体的には、要求メタデータ判別部３０６は、ステップＳ７０１においてＳＯＡＰ処理部３０３が取得したＣＤＳのBrowseアクションの第１パラメータであるObjectIDを取得する。
【００２６】
次に、ステップＳ７０３において、要求メタデータ判別部３０６は、ステップＳ７０２で取得した要求対象コンテンツ識別子が、変換テーブルに存在するか否かを判定する。具体的には、要求メタデータ判別部３０６は、ステップＳ７０２で取得したObjectIDが、図５に示した変換テーブルのコンテンツ情報メタデータ取得アドレスのフィールドに存在するか否かを判定する。この判定の結果、ステップＳ７０２で取得したObjectIDが、変換テーブルのコンテンツ情報メタデータ取得アドレスのフィールドに存在するならば、ステップＳ７０４に進む。一方、ステップＳ７０２で取得したObjectIDが、変換テーブルのコンテンツ情報メタデータ取得アドレスのフィールドに存在しなければ、後述するステップＳ７０７に進む。
通常、図６に示した初期動作のフローチャートの直後の場合、変換テーブル中にはルートディレクトリに対する変換レコードのみが存在する。つまり、図５に示した変換テーブルの最初のレコードのみが、変換テーブル中に存在する。一方、ＬＡＮ１０上のＤＬＮＡ機器３０が、メタデータ提供装置２０に対して、最初のコンテンツメタデータの取得要求を行う際には、通常、ルートディレクトリに対するコンテンツメタデータの取得要求を行う。よって、ステップＳ７０３の判定結果は"存在する"となるのが通常である。
【００２７】
ステップＳ７０４において、要求メタデータ判別部３０６は、変換テーブル中からステップＳ７０２で取得した要求対象コンテンツ識別子が含まれるレコード（変換レコード）を取得する。
次に、ステップＳ７０５において、要求メタデータ判別部３０６は、ステップＳ７０１で受信したコンテンツメタデータの取得要求に含まれる要求メタデータ種別がBrowseDirectChildrenであるか否かを判定する。具体的には、要求メタデータ判別部３０６は、ステップＳ７０１でＳＯＡＰ処理部３０３が取得したＣＤＳのBrowseアクションの第２パラメータが、BrowseDirectChildrenであるか否かを判定する。この判定の結果、要求メタデータ種別がBrowseDirectChildrenであるならば、後述する図８のステップＳ８０１に進む。一方、要求メタデータ種別がBrowseDirectChildrenと異なるならば、ステップＳ７０６に進む。
ステップＳ７０６において、要求メタデータ判別部３０６は、ステップＳ７０１で受信したコンテンツメタデータの取得要求に含まれる要求メタデータ種別がBrowseMetadataであるか否かを判定する。具体的には、要求メタデータ判別部３０６は、ステップＳ７０１でＳＯＡＰ処理部３０３が取得したＣＤＳのBrowseアクションの第２パラメータが、BrowseMetadataであるか否かを判定する。この判定の結果、要求メタデータ種別がBrowseMetadataであるならば、後述する図９のステップＳ９０１に進む。一方、要求メタデータ種別がBrowseMetadataと異なるならば、後述するステップＳ７０７に進む。
【００２８】
図８は、図７に続くフローチャートである。具体的に図８は、図７のステップＳ７０５において、要求メタデータ判別部３０６によって、要求メタデータ種別がBrowseDirectChildrenであると判定された場合の処理を説明するフローチャートである。
ステップＳ８０１において、メタデータ取得アドレス決定部３０７は、図７のステップＳ７０４において要求メタデータ判別部３０６が取得した変換レコードから、コンテンツリストメタデータ取得アドレスを取得する。
次に、ステップＳ８０２において、メタデータ取得アドレス決定部３０７は、ステップＳ８０１で取得したコンテンツリストメタデータ取得アドレスが有効であるか否かを判定する。この判定の結果、コンテンツリストメタデータ取得アドレスが有効であれば、ステップＳ８０３に進む。一方、コンテンツリストメタデータ取得アドレスが無効でなければ、後述する図７のステップＳ７０７に進む。ここで、コンテンツリストメタデータ取得アドレスが無効となる場合の典型的な例としては、要求対象コンテンツがディレクトリ（コンテナ）ではなくメディア（アイテム）である場合である。
【００２９】
ステップＳ８０３において、メタデータ取得部３０８は、ステップＳ８０１で取得したコンテンツリストメタデータ取得アドレスを用いて、コンテンツ提供装置５０から、コンテンツリストメタデータを取得する。
次に、ステップＳ８０４において、変換テーブル作成部３０９は、ステップＳ８０３で取得したコンテンツリストメタデータから、各コンテンツに関するメタデータを抽出する。以降、対象となる１つのコンテンツのメタデータに対してステップＳ８０５〜ステップＳ８０９の処理を行う。
次に、ステップＳ８０５において、変換テーブル作成部３０９は、ステップＳ８０４で抽出したコンテンツのメタデータに基づき、コンテンツ情報メタデータ取得アドレスを決定する。これは、図６のステップＳ６０５の説明において述べたコンテンツリストメタデータ取得アドレスの決定方法と同様に、次の２つの方法がある。１つ目は、ステップＳ８０４で抽出したコンテンツに関するメタデータ内にコンテンツ情報メタデータ取得アドレスが直接記載されている場合である。２つ目は、コンテンツ提供装置５０が規定する方式に基づき、コンテンツ情報メタデータ取得アドレスに関するベースアドレスと、該当する（取得要求のあった）コンテンツに関する情報との組み合せから一意に決定可能な場合である。該当するコンテンツに関する情報とは、例えばコンテンツ識別子等であり、ステップＳ８０４で抽出したコンテンツのメタデータ内に記載されている。これらの決定方法は、コンテンツ提供装置５０によって異なるが、本実施形態では図６のステップＳ６０５と同様に、前者の場合を仮定する。
【００３０】
次に、ステップＳ８０６において、変換テーブル作成部３０９は、ステップＳ８０５で決定したコンテンツ情報メタデータ取得アドレスが、変換テーブルに存在するか否かを判定する。具体的には、変換テーブル作成部３０９は、ステップＳ８０５で決定したコンテンツ情報メタデータ取得アドレスが、図５に示した変換テーブルのコンテンツ情報メタデータ取得アドレスのフィールドに存在するか否かを判定する。この判定の結果、コンテンツ情報メタデータ取得アドレスが、変換テーブルのコンテンツ情報メタデータ取得アドレスのフィールドに存在すれば、変換テーブル作成部３０９は、該当するコンテンツが変換テーブルに登録済みと判断する。そして、ステップＳ８０７〜Ｓ８０９を省略してステップＳ８１０に進む。一方、コンテンツ情報メタデータ取得アドレスが、変換テーブルのコンテンツ情報メタデータ取得アドレスのフィールドに存在しなければ、変換テーブル作成部３０９は、該当するコンテンツが変換テーブルに未登録と判断して、ステップＳ８０７に進む。
【００３１】
ステップＳ８０７において、変換テーブル作成部３０９は、該当するコンテンツがディレクトリであるか否かを判定する。具体的には、変換テーブル作成部３０９は、ステップＳ８０４で抽出したコンテンツのメタデータの属性情報を基に、当該コンテンツがディレクトリであるか否かを判定する。この判定の結果、該当するコンテンツがディレクトリであるならば、ステップＳ８０８に進む。一方、該当するコンテンツがディレクトリでなければ、ステップＳ８０８を省略してステップＳ８０９に進む。
ステップＳ８０８において、変換テーブル作成部３０９は、ディレクトリであると判断した当該コンテンツの、コンテンツリストメタデータ取得アドレスを決定する。ここでのコンテンツリストメタデータ取得アドレスの決定方法は、図６のステップＳ６０５の説明において述べたコンテンツリストメタデータ取得アドレスの決定方法と同様であるので、その詳細な説明を省略する。
【００３２】
次に、ステップＳ８０９において、変換テーブル作成部３０９は、ステップＳ８０５で決定したコンテンツ情報メタデータ取得アドレスを用いて、該当するコンテンツの変換レコードを作成する。ステップＳ８０８からステップＳ８０９に進んだ場合、変換テーブル作成部３０９は、ステップＳ８０８で決定したコンテンツリストメタデータ取得アドレスを更に用いて、該当するコンテンツの変換レコードを作成する。尚、親ディレクトリコンテンツ情報メタデータ取得アドレスは、図７のステップＳ７０２で取得した要求対象コンテンツ識別子（ObjectID）である。そして、変換テーブル作成部３０９は、作成した変換レコードを、記憶部３１４を介して、図２に示したメタデータ提供装置２０の外部記憶装置２０４内に用意した変換テーブル内に追加する。
次に、ステップＳ８１０において、変換テーブル作成部３０９は、ステップＳ８０４で抽出した各コンテンツに関するメタデータを全て処理対象としたか否かを判定する。この判定の結果、各コンテンツに関するメタデータを全て処理対象としていなければ、ステップＳ８０４に戻る。一方、各コンテンツに関するメタデータを全て処理対象としたならば、ステップＳ８１１に進む。
【００３３】
ステップＳ８１１において、メタデータ変換部３１０は、図８のステップＳ８０３で取得したコンテンツリストメタデータを、所定のDIDL−Lite形式のメタデータに変換する。変換の際、コンテンツリスト中に含まれる各コンテンツに対して、コンテンツ識別子（ＩＤ）として、図８のステップＳ８０５で決定したコンテンツ情報メタデータ取得アドレスを用いる。更に、親ディレクトリコンテンツ識別子（ParentID）として、図７のステップＳ７０２で取得した要求対象コンテンツ識別子（ObjectID）を用いる。
次に、ステップＳ８１２において、メタデータ提供部３１１は、ステップＳ８１１で変換されたコンテンツリストメタデータを、ＬＡＮ１０上のＤＬＮＡ機器３０に送信する。具体的には、メタデータ提供部３１１は、ステップＳ８１１で変換された変換したコンテンツリストメタデータを、ＳＯＡＰ処理部３０３を介して、ＣＤＳのBrowseアクションの応答として、ＬＡＮ１０上のＤＬＮＡ機器３０に返す。
そして、制御部３０５は、図７に示したメタデータ提供動作を終了する。尚、メタデータ提供動作を繰り返すために、制御部３０５は図７の開始へ処理を戻しても良い。
【００３４】
図９は、図７に続くフローチャートである。具体的に図９は、図７のステップＳ７０６において、要求メタデータ判別部３０６によって、要求メタデータ種別がBrowseMetadataであると判定された場合の処理を説明するフローチャートである。
ステップＳ９０１において、要求メタデータ判別部３０６は、図７のステップＳ７０２で取得した要求対象コンテンツ識別子が"０"、つまり要求対象のコンテンツがルートディレクトリであるか否かを判定する。この判定の結果、要求対象コンテンツ識別子が"０"でないならば、ステップＳ９０２に進む。一方、要求対象コンテンツ識別子が"０"ならば、ステップＳ９０３に進む。
ステップＳ９０２において、メタデータ取得アドレス決定部３０７は、図７のステップＳ７０４で要求メタデータ判別部３０６が取得した変換レコードから、コンテンツ情報メタデータ取得アドレスを取得する。そして、ステップＳ９０４に進む。
ステップＳ９０３において、メタデータ取得アドレス決定部３０７は、当該利用ユーザのユーザ情報テーブルからルートコンテンツ情報メタデータ取得アドレスを取得する。そして、ステップＳ９０４に進む。
【００３５】
ステップＳ９０４において、メタデータ取得部３０８は、ステップＳ９０２、Ｓ９０３で取得したコンテンツ情報メタデータ取得アドレスを用いて、コンテンツ提供装置５０から、コンテンツ情報メタデータを取得する。
次に、ステップＳ９０５において、メタデータ変換部３１０は、ステップＳ９０４で取得したコンテンツ情報メタデータを、所定のDIDL-Lite形式のメタデータに変換する。変換の際、コンテンツ識別子（ＩＤ）として、ステップＳ９０２、Ｓ９０３で取得したコンテンツ情報メタデータ取得アドレスを用いる。更に、親ディレクトリコンテンツ識別子（ParentID）として、図７のステップＳ７０４において要求メタデータ判別部３０６が取得した変換レコード中の、親ディレクトリコンテンツ情報メタデータ取得アドレスを用いる。
次に、ステップＳ９０６において、メタデータ提供部３１１は、ステップＳ９０５で変換されたコンテンツ情報メタデータを、ＬＡＮ１０上のＤＬＮＡ機器３０に送信する。具体的には、メタデータ提供部３１１は、ステップＳ９０５で変換されたコンテンツ情報メタデータを、ＳＯＡＰ処理部３０３を介して、ＣＤＳのBrowseアクションの応答として、ＬＡＮ１０上のＤＬＮＡ機器３０に返す。
そして、制御部３０５は、図７に示したメタデータ提供動作を終了する。尚、メタデータ提供動作を繰り返すために、制御部３０５は図７の開始へ処理を戻しても良い。
【００３６】
図７のステップＳ７０３、Ｓ７０６、図８のステップＳ８０２からステップＳ７０７に進むと、メタデータ提供部３１１は、要求パラメータが不正であることを旨とするエラー応答を、ＬＡＮ１０上のＤＬＮＡ機器３０に送信する。具体的には、メタデータ提供部３１１は、要求パラメータが不正であることを旨とするエラー応答を、ＳＯＡＰ処理部３０３を介して、ＣＤＳのBrowseアクションの応答として、ＬＡＮ１０上のＤＬＮＡ機器３０に返す。
そして、制御部３０５は、図７に示したメタデータ提供動作を終了する。尚、メタデータ提供動作を繰り返すために、制御部３０５は図７の開始へ処理を戻しても良い。
【００３７】
図１０は、ＬＡＮ１０上のＤＬＮＡ機器３０が、メタデータ提供装置２０に送信した、ルートディレクトリに対するコンテンツリストメタデータの取得要求メッセージの一例を示す図である。これは、ＣＤＳのBrowseアクションのＳＯＡＰ要求メッセージである。ＣＤＳのBrowseアクションの第１パラメータである要求対象コンテンツ識別子は、ルートディレクトリを示す"０"である。そして、その第２パラメータである要求メタデータ種別は、コンテンツリストメタデータを示す"BrowseDirectChildren"である。
【００３８】
図１１（Ａ）は、図１０に示したルートディレクトリに対するコンテンツリストメタデータの取得要求に対して、メタデータ提供装置２０がコンテンツ提供装置５０から取得したコンテンツリストメタデータの一例を示す図である。この例では、コンテンツ提供装置５０のメタデータ形式が、The Atom Publishing Protocolであるとする。尚、本実施形態では、コンテンツ提供装置５０のメタデータ形式がThe Atom Publishing Protocolである場合を例に挙げている。しかしながら、コンテンツ提供装置５０のメタデータ形式はこれに限らず、例えば、ＲＥＳＴ（Representational State Transfer）形式メタデータや独自形式メタデータ等でも良い。
この例では、ルートディレクトリ"User1"に２つのディレクトリ"Album1"、"Album2"が含まれている。また、コンテンツがディレクトリであることは、category要素の属性情報等から判断することができる。
【００３９】
図１１（Ｂ）は、図１１（Ａ）に示したコンテンツ提供装置５０から取得したコンテンツリストメタデータを、図５に示した変換テーブルを用いて所定のDIDL-Lite形式のメタデータに変換した結果の一例を示す図である。この例では、ディレクトリ"Album1"のコンテンツ識別子（ＩＤ）は"User1Album1InfoURI"、親ディレクトリコンテンツ識別子（ParentID）は"０"である。同様に、ディレクトリ"Album2"のコンテンツ識別子（ＩＤ）は"User1Album2InfoURI"、親ディレクトリコンテンツ識別子（ParentID）は"０"である。
【００４０】
図１２は、ＬＡＮ１０上のＤＬＮＡ機器３０が、メタデータ提供装置２０に送信した、ディレクトリ"Album1"に対するコンテンツリストメタデータの取得要求メッセージの一例を示す図である。これは、ＣＤＳのBrowseアクションのＳＯＡＰ要求メッセージである。ＣＤＳのBrowseアクションの第１パラメータである要求対象コンテンツ識別子は、ディレクトリ"Album1"を示す"User1Album1InfoURI"である。そして、その第２パラメータである要求メタデータ種別は、コンテンツリストメタデータを示す"BrowseDirectChildren"である。
【００４１】
図１３（Ａ）は、図１２に示したディレクトリ"Album1"に対するコンテンツリストメタデータ取得要求に対して、メタデータ提供装置２０がコンテンツ提供装置５０から取得したコンテンツリストメタデータの一例を示す図である。この例も、図１１と同様に、コンテンツ提供装置５０のメタデータ形式が、The Atom Publishing Protocolであるとする。また、この例では、ディレクトリ"Album1"に２つのメディア"Photo1"、"Photo2"が含まれている。また、コンテンツがメディアであることは、category要素の属性情報や、content要素の属性情報等から判断することができる。
【００４２】
図１３（Ｂ）は、図１３（Ａ）に示したコンテンツ提供装置５０から取得したコンテンツリストメタデータを、図５に示した変換テーブルを用いて所定のDIDL-Lite形式のメタデータに変換した結果の一例を示す図である。この例では、メディア"Photo1"のコンテンツ識別子（ＩＤ）は"User1Photo1InfoURI"、親ディレクトリコンテンツ識別子（ParentID）は"User1Album1InfoURI"である。同様に、メディア"Photo2"のコンテンツ識別子（ＩＤ）は"User1Photo2InfoURI"、親ディレクトリコンテンツ識別子（ParentID）は"User1Album1InfoURI"である。
【００４３】
図１４は、ＬＡＮ１０上のＤＬＮＡ機器３０が、メタデータ提供装置２０に送信した、メディア"Photo1"に対するコンテンツ情報メタデータの取得要求メッセージの一例を示す図である。これは、ＣＤＳのBrowseアクションのＳＯＡＰ要求メッセージである。ＣＤＳのBrowseアクションの第１パラメータである要求対象コンテンツ識別子は、メディア"Photo1"を示す"User1Photo1InfoURI"である。そして、その第２パラメータである要求メタデータ種別は、コンテンツ情報メタデータを示す"BrowseMetadata"である。
【００４４】
図１５（Ａ）は、図１４に示したメディア"Photo1"に対するコンテンツ情報メタデータの取得要求に対して、メタデータ提供装置２０がコンテンツ提供装置５０から取得したコンテンツ情報メタデータの一例を示す図である。この例も、図１１、図１３と同様に、コンテンツ提供装置５０のメタデータ形式が、The Atom Publishing Protocolであるとする。この場合、メディア"Photo1"のコンテンツ情報メタデータ中に親ディレクトリである"Album1"に関する情報は含まれていない。
【００４５】
図１５（Ｂ）は、図１５（Ａ）に示したコンテンツ提供装置５０から取得したコンテンツ情報メタデータを、図５に示した変換テーブルを用いて所定のDIDL-Lite形式のメタデータに変換した結果の一例を示す図である。この例では、メディア"Photo1"のコンテンツ識別子（ＩＤ）は"User1Photo1InfoURI"、親ディレクトリコンテンツ識別子（ParentID）は"User1Album1InfoURI"である。
【００４６】
以上のように本実施形態では、ＤＬＮＡ機器３０からコンテンツリストメタデータの取得要求があると、メタデータ提供装置２０は、該当するコンテンツについて、変換テーブルのレコードを追加する。この変換テーブルのレコードには、コンテンツメタデータ取得アドレス（コンテンツ情報（コンテンツリスト）メタデータ取得アドレス）と、親ディレクトリコンテンツ情報メタデータ取得アドレスとが含まれている。ＤＬＮＡ機器３０からコンテンツメタデータの取得要求があると、メタデータ提供装置２０は、変換テーブルに記憶されているコンテンツ情報（コンテンツリスト）メタデータ取得アドレスを用いて、コンテンツ提供装置５０からコンテンツメタデータを取得する。そして、メタデータ提供装置２０は、取得したコンテンツメタデータをＤＬＮＡ機器３０が処理できる所定の形式に変換する。この際、コンテンツ識別子として、該当するコンテンツ情報メタデータ取得アドレスを用いると共に、親ディレクトリコンテンツ識別子として、該当する親ディレクトリコンテンツ情報メタデータ取得アドレスを用いる。そして、メタデータ提供装置２０は、変換したコンテンツメタデータをＤＬＮＡ機器３０に送信する。
【００４７】
したがって、メタデータ提供装置２０は、コンテンツ提供装置５０のコンテンツメタデータを、正しいディレクトリ情報を付加して動的に変換し、ＬＡＮ１０上のＤＬＮＡ機器３０に提供することができる。したがって、コンテンツ提供装置５０のコンテンツの内容がリアルタイムに更新されても、メタデータ提供装置２０は更新内容が反映されたメタデータを直ちにＬＡＮ１０上のＤＬＮＡ機器３０に提供することができる。これにより、ユーザの利便性が向上する。
また、ＬＡＮ１０上のＤＬＮＡ機器３０からのコンテンツリストメタデータの取得要求があった場合に限り、メタデータ提供装置２０は変換テーブルを作成する。一方、ＬＡＮ１０上のＤＬＮＡ機器３０からのコンテンツ情報メタデータの取得要求があった場合には、メタデータ提供装置２０は変換テーブルを作成しない。これにより、メタデータ提供装置２０は、変換テーブルの作成に伴う処理コストを削減することできる。
【００４８】
また、メタデータ提供装置２０は、コンテンツ提供装置５０から取得したコンテンツメタデータをDIDL-Liteに変換する際、コンテンツ識別子（ＩＤ）としてコンテンツ情報メタデータ取得アドレスを用いる。これにより、メタデータ提供装置２０は、ＬＡＮ１０上のＤＬＮＡ機器３０からのコンテンツ情報メタデータの取得要求に対して、直ちにコンテンツ提供装置５０からコンテンツ情報メタデータを取得することできる。本来ならば、メタデータ提供装置２０は、コンテンツ識別子からコンテンツ情報メタデータを取得するためのアドレスを解決する必要がある。しかし、本実施形態では、この必要がないため、ＬＡＮ１０上のＤＬＮＡ機器３０からのコンテンツ情報メタデータの取得要求に対する応答速度が向上し、ユーザの利便性を向上することができる。
また、メタデータ提供装置２０は、変換テーブルにコンテンツリストメタデータ取得アドレスを保持している。これにより、メタデータ提供装置２０は、ＬＡＮ１０上のＤＬＮＡ機器３０からのコンテンツリストメタデータ取得要求に対して、直ちにコンテンツ提供装置５０からコンテンツリストメタデータを取得することできる。本来ならば、メタデータ提供装置２０は、コンテンツ識別子からコンテンツリストメタデータを取得するためのアドレスを解決する必要がある。しかし、本実施形態では、この必要がないため、ＬＡＮ１０上のＤＬＮＡ機器３０からのコンテンツリストメタデータの取得要求に対する応答速度が向上し、ユーザの利便性を向上することができる。
尚、コンテンツ提供装置が管理している階層型の記憶領域がディレクトリである場合を例に挙げて説明したが、例えば、ディレクトリに相当するフォルダを当該記憶領域としてもよい。
【００４９】
（本発明の他の実施形態）
本発明は、実施形態の機能を実現するソフトウエアのプログラムコードを記録した記録媒体を、システム或いは装置に供給し、そのコンピュータが記録媒体に格納されたプログラムコードを読み出し実行することによっても達成される。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することとなり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。すなわち、前述した本発明の実施形態におけるコンテンツ属性情報提供装置を構成する各手段、並びにコンテンツ属性情報提供方法の各ステップは、コンピュータのＲＡＭやＲＯＭ等に記憶されたコンピュータプログラムが動作することによって実現できる。また、このコンピュータプログラムプログラム及びコンピュータプログラムプログラムを記録したコンピュータ読み取り可能な記録媒体も本発明に含まれる。
【００５０】
尚、前述した各実施形態は、何れも本発明を実施するにあたっての具体化の例を示したものに過ぎず、これらによって本発明の技術的範囲が限定的に解釈されてはならないものである。すなわち、本発明はその技術思想、又はその主要な特徴から逸脱することなく、様々な形で実施することができる。
【符号の説明】
【００５１】
２０  メタデータ提供装置、３０  ＤＬＮＡ機器、５０  コンテンツ提供装置
【図１】
2010282374.tif 000003
【図２】
2010282374.tif 000004
【図３】
2010282374.tif 000005
【図４】
2010282374.tif 000006
【図５】
2010282374.tif 000007
【図６】
2010282374.tif 000008
【図７】
2010282374.tif 000009
【図８】
2010282374.tif 000010
【図９】
2010282374.tif 000011
【図１０】
2010282374.tif 000012
【図１１】
2010282374.tif 000013
【図１２】
2010282374.tif 000014
【図１３】
2010282374.tif 000015
【図１４】
2010282374.tif 000016
【図１５】
2010282374.tif 000017