情報処理システム、収集サーバ、情報処理方法及びプログラム
【課題】ユーザにとってコンテンツの検索を行いやすいシステムを提供する。
【解決手段】メディアサーバからコンテンツを受信して再生できるクライアントと、メディアサーバからコンテンツに関連するコンテンツ管理情報を受信して管理する収集サーバとで構成される情報処理システムにおいて、予め決められた条件に従って、コンテンツ管理情報をメディアサーバから取得し、取得したコンテンツ管理情報に含まれるコンテンツの格納位置に関する情報を、コンテンツのカテゴリとして記憶するようにした。また、クライアントからコンテンツの検索条件を受信した場合には、検索条件に一致するコンテンツ情報を抽出してカテゴリ一覧し、生成したカテゴリ一覧をクライアントに送信するようにした。
【解決手段】メディアサーバからコンテンツを受信して再生できるクライアントと、メディアサーバからコンテンツに関連するコンテンツ管理情報を受信して管理する収集サーバとで構成される情報処理システムにおいて、予め決められた条件に従って、コンテンツ管理情報をメディアサーバから取得し、取得したコンテンツ管理情報に含まれるコンテンツの格納位置に関する情報を、コンテンツのカテゴリとして記憶するようにした。また、クライアントからコンテンツの検索条件を受信した場合には、検索条件に一致するコンテンツ情報を抽出してカテゴリ一覧し、生成したカテゴリ一覧をクライアントに送信するようにした。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、メディアサーバからコンテンツを受信して再生できるクライアントと、前記メディアサーバから前記コンテンツに関連するコンテンツ管理情報を受信して管理する収集サーバとで構成される情報処理システム及び情報処理方法、プログラム、並びにそのシステムに適用される収集サーバに関する。
【背景技術】
【０００２】
ホームネットワーク環境でデジタルＡＶ機器同士や、パソコンを相互に接続するための技術ガイドラインとして、ＤＬＮＡ（Digital Living Network Alliance）ガイドラインが知られている。ＤＬＮＡガイドラインは、コンテンツを提供するサーバと、コンテンツを再生するクライアントとの間における接続条件を定めたものであり、このガイドラインに準拠した機器同士であれば、特別な設定をしなくても、線をつなぐだけで相互接続してコンテンツを共用できるようになる。
【０００３】
ＤＬＮＡガイドラインでは、ネットワーク上の機器同士の連携を実現するプロトコルとして、ＵＰｎＰ(Universal Plug and Play)を使用することが決められており、クライアントとサーバ間でのコンテンツ及びコンテンツ管理情報のやり取りは、ＵＰｎＰ ＡＶの仕様に基づいて行われる。ユーザは、ＵＰｎＰコントロールポイントから、ＢｒｏｗｓｅコマンドまたはＳｅａｒｃｈコマンドを使ってサーバ内のＣＤＳ（Content Directory Service）を呼び出し、コンテンツ管理情報の一覧を取得する。そして、コンテンツ管理情報一覧に含まれているコンテンツの保存場所のＵＲＬ（Uniform Resource Locator）にアクセスすることで、所望のコンテンツを得ることができる。
【０００４】
図１４に、家庭内ＬＡＮ（Local Area Network）等のネットワーク２を介して、ＤＬＮＡクライアントとＤＬＮＡサーバ（メディアサーバ）とが接続されている様子を示してある。ＤＬＮＡクライアント１０としてノート型パーソナルコンピュータ１０ａ（以下、パーソナルコンピュータはＰＣと称する）とテレビジョン受像機１０ｃがあり、ネットワークメディアレシーバ２０を介して、ＤＬＮＡサーバ２０であるノート型ＰＣ２０ａやデスクトップ型ＰＣ２０ｂ、ＤＶＤ（Digital Versatile Disc）レコーダ２０ｃが接続されている。図１４には、ノート型ＰＣ２０ａに写真Ｐ１とビデオＶ１、音楽Ｍ１が記録されており、デスクトップ型ＰＣ２０ｂには写真Ｐ２と音楽Ｍ２、ビデオＶ２が、ＤＶＤレコーダ２０ｃにはビデオＶ３が記録されている様子が示されている。
【０００５】
ＤＬＮＡクライアント１０とＤＬＮＡサーバとは、ＤＬＮＡガイドラインに準拠した接続方式で接続されているため、ＤＬＮＡサーバ２０のそれぞれの機器上に記録された写真やビデオ、音楽等のコンテンツを、ＤＬＮＡクライアント１０のぞれぞれの機器で読み出して再生させることができる。
【０００６】
例えばＤＬＮＡクライアント１０のパーソナルコンピュータ１０ａで、ＤＬＮＡサーバ２０に保存されている写真２を見る場合には、写真２を保存しているデスクトップ型ＰＣ２０ｂにアクセスすればよい。しかしこの場合、写真２が記憶されている機器が何であるのかを、ＤＬＮＡクライアント１０側で予め把握しておく必要がある。このため、特に、様々な種類のＤＬＮＡサーバ２０に大量のコンテンツが記憶されている場合などは、コンテンツを探す手間や時間がかかってしまうという問題があった。
【０００７】
この問題を解決する手法としては、収集サーバを使って、家庭内の各ＤＬＮＡサーバ中のコンテンツ管理情報を一元で管理する手法が知られている。収集サーバを用いた場合のシステム構成例を、図１５に示してある。図１５に示した構成では、ＤＬＮＡサーバ２０の各機器に記録されたコンテンツのメタデータ（属性情報）を、収集サーバ３０に一括で管理させている。
【０００８】
図１５に示した例では、収集サーバ３０がコンテンツの種類毎にコンテンツを分類した場合の例を示してある。収集サーバ３０上では、ノート型ＰＣ２０ａに記録されているビデオＶ１と、デスクトップ型ＰＣ２０ｂ上のビデオＶ２、ＤＶＤレコーダ２０ｃ上のビデオＶ３とを、「ビデオ」という分類で一覧表示している。同様に、ノート型ＰＣ２０ａ上に記録された写真Ｐ１とデスクトップ型ＰＣ２０ｂ上に記録された写真Ｐ２とが、「写真」の分類で一覧表示されており、ノート型ＰＣ２０ａ上に記録された音楽Ｍ１とデスクトップ型ＰＣ２０ｂ上に記録された音楽Ｐ２とが、「音楽」の分類で一覧表示されている。
【０００９】
このように収集サーバ３０は、ＤＬＮＡサーバ２０の各機器に点在して記録されているコンテンツの情報を、データの種類やアーティスト別等に再分類して一覧で示す機能を備えているため、ＤＬＮＡクライアント１０の各機器は、収集サーバ３０にアクセスするだけで所望のコンテンツを容易に検索することができるようになる。
【００１０】
この他にも、コンテンツ検索の効率を向上させるための様々な手法が採られている。例えば特許文献１には、デジタルカメラからＰＣに画像を取り込む際に、画像のメタデータを用いて画像を自動的に分類する手法について、開示がしてある。
【特許文献１】特開２００６−２６２２１４号公報
【発明の開示】
【発明が解決しようとする課題】
【００１１】
特許文献１にも記載があるように、特にデジタルカメラや携帯電話端末等で撮影された静止画像では、そのメタデータが、撮影日付や、機器がその静止画像に対して自動的に付与したタイトルのみである場合が多い。図１６に、収集サーバ３０上で静止画像の一覧が表示されている様子を示してある。図１６に示した画面では、画面左側に画像のサムネイルが表示されており、その隣にＤＳＣ０００５．ＪＰＧ等の画像のタイトル、２００５／９／３ 午後６：４０等の撮影日時が表示されている。
【００１２】
ところが、図１６に表示されたような情報のみをキーとして、得たい画像を検索することは難しい場合がある。撮影日時や画像のタイトル等は、ユーザにとって意味の無い分類であることが多いためである。
【００１３】
ＤＬＮＡクライアント１０の種類によっては、ＤＬＮＡサーバ２０内のＣＤＳ（Container Directory Service）と呼ばれるコンテンツの階層構造を、ユーザが操作するメニュー画面上にそのまま見せるものもある。ＣＤＳは、例えば図１７に示したような構造であり、コンテナと呼ばれるフォルダが階層状に結び付けられている。コンテナの中には、コンテナ単体で存在するものや、アイテムと呼ばれるコンテンツの実ファイルを備えるものがある。なお、コンテナ又はアイテムは、共にオブジェクトという総称でも呼称される。
【００１４】
図１７に示した例では、ルートコンテナＣ０の下に、“録画ビデオ”と名づけられたコンテナＣ１と、“アルバム一覧”と名づけられたコンテナＣ２がぶら下がっており、コンテナＣ２の下に、“アルバム１”と名づけられたコンテナＣ３と、“アルバム２”と名づけられたコンテナＣ４とが接続されている。コンテナＣ３には、更に“オマケ”と名づけられたコンテナＣ５が接続されている。そして、コンテナＣ２の中にビデオコンテンツであるアイテムＩｔ１とＩｔ２が格納されており、コンテナＣ３の中に写真コンテンツであるアイテムＩｔ３、Ｉｔ４、Ｉｔ５が、コンテンツＣ４の中に写真コンテンツであるアイテムＩｔ６が格納されている様子が示されている。つまり、ＣＤＳはユーザが作成したフォルダ名や階層をそのまま示したものであり、ＣＤＳにおけるフォルダ名は、ユーザにとっては意味のあるものである場合が多い。
【００１５】
このような階層がメニュー画面上に表示されていれば、ユーザがその階層をたどって目的の写真にたどり着くことも可能であるが、目的の写真にたどり着くまでの間に、階層間を何度も移動しなければならないことも多く、操作性が良いとは言えなかった。
【００１６】
また、撮影日付やタイトル以外のメタデータも、ＣＤＳでは有するように規定されているため、これらのメタデータを検索の条件に追加することができれば、検索の効率を向上させることができるはずである。図１８（ａ）には、５種類の必須メタデータを示してあり、図１８（ｂ）には、任意で追加可能なメタデータを示してある。
【００１７】
必須のメタデータとしては、コンテンツごとに割り振られる一意のＩＤである＠ｉｄや、コンテンツの一階層上のコンテンツのＩＤである＠ｐａｒｅｎｔＩＤ、コンテンツが変更可能かどうかを示す＠ｒｅｓｔｒｉｃｔｅｄ、タイトルを示すｄｃ：ｔｉｔｌｅ、コンテンツの種別を示すｕｐｎｐ：ｃｌａｓｓがある。任意に追加可能なメタデータとしては、日時情報を示すｄｃ：ｄａｔｅや、概要を示すｄｃ：ｄｅｓｃｒｉｐｔｉｏｎ、アーティスト情報を示すｕｐｎｐ：ａｒｔｉｓｔ、アルバム情報を示すｕｐｎｐ：ａｌｂｕｍ、ジャンル情報を示すｕｐｎｐ：ｇｅｎｒｅ、コンテンツデータの取得先ＵＲＬであるｒｅｓ等がある。
【００１８】
ところが、コンテンツ検索のキーとして使えそうな項目を、任意に追加可能なメタデータとして追加することは可能であるが、その意味をＤＬＮＡクライアント１０との間で共有し合わなければ、追加した項目を検索項目として使用することはできない。しかし、このような情報を共有するためのＤＬＮＡ共通の枠組みは存在していない。よって現状では、拡張情報として追加したメタデータを、ＤＬＮＡクライアント１０やＤＬＮＡサーバ２０を構成する様々な機器間で共有することは、不可能であると言える。
【００１９】
本発明はかかる点に鑑みてなされたものであり、ユーザにとってコンテンツの検索を行いやすいシステムを提供することを目的とする。
【課題を解決するための手段】
【００２０】
本発明は、メディアサーバからコンテンツを受信して再生できるクライアントと、メディアサーバからコンテンツに関連するコンテンツ管理情報を受信して管理する収集サーバとで構成される情報処理システムにおいて、予め決められた条件に従って、コンテンツ管理情報をメディアサーバから取得し、取得したコンテンツ管理情報に含まれるコンテンツの格納位置に関する情報を、コンテンツのカテゴリとして記憶するようにした。また、クライアントからコンテンツの検索条件を受信した場合には、検索条件に一致するコンテンツ情報を抽出してカテゴリ一覧し、生成したカテゴリ一覧をクライアントに送信するようにしたものである。
【００２１】
このようにしたことで、収集サーバからクライアントに送られるコンテンツ管理情報においては、コンテンツを格納したフォルダ（親フォルダ）の名前が、コンテンツのメタデータとして記録されるようになる。このため、クライアントがコンテンツを検索する際のキーとして、メタデータであるコンテンツのフォルダの名前を用いることができるようになる。
【発明の効果】
【００２２】
本発明によると、ユーザが意図して付与したフォルダ名を、コンテンツ検索の際のキーとして用いることができるようになるため、コンテンツ検索の効率を向上させることができる。
【発明を実施するための最良の形態】
【００２３】
以下、本発明の一実施の形態を、図１〜図１０を参照して説明する。本例では、従来例として図１５に示した構成と同様の構成としてあり、図１には、その内部構成例を示してある。なお、図１５に示した構成においては、ＤＬＮＡクライアントとしてノート型ＰＣとテレビジョン受像機、ＤＬＮＡサーバとしてデスクトップ型ＰＣとノート型ＰＣとＤＶＤレコーダ、収集サーバとしてデスクトップ型ＰＣを用いてあるが、機器構成は図１５に示した例に限定されるものではない。
【００２４】
図１に示したシステムにおいて、ＤＬＮＡクライアント１００とＤＬＮＡサーバ２００は、それぞれ収集サーバ３００に接続してある。収集サーバ３００は、ＤＬＮＡサーバ２００からのコンテンツ管理情報の収集と、収集したコンテンツ管理情報のＤＬＮＡクライアント１００への配信処理を行う。
【００２５】
ＤＬＮＡクライアント１００は、ネットワーク１との接続インターフェースである通信部１０１と、通信部１０１で行われる通信の制御や、ＤＬＮＡクライアント１００の各部の制御を行う制御部１０２と、ユーザからの操作入力を受け付ける操作部１０５と、収集サーバ３００から取得したコンテンツ管理情報や、コンテンツ管理情報の中からユーザによって選択された、写真やビデオ等のコンテンツを表示する表示部１０６と、コンテンツデータ等を記憶する記憶部１０７とで構成される。
【００２６】
また制御部１０２は、ＨＴＴＰ処理モジュール１０４と、ＵＰｎＰコントロールポイントモジュール１０３とを備える。ＨＴＴＰ処理モジュール１０４は、ＨＴＴＰクライアントの処理を行うものであり、ＧＥＴコマンド等のコマンドの生成や、コマンドに呼応して送られたレスポンスメッセージに含まれる、ＸＭＬ（Extensible Markup Language）や画像データを基に、表示画面を生成する処理を行う。ＵＰｎＰコントロールポイントモジュール１０３は、ネットワーク１に接続されたＵＰｎＰ対応デバイスの検出処理や、ＤＬＮＡサーバ２００内のＣＤＳ情報を取得するための、Ｂｒｏｗｓｅコマンドの生成等を行う。
【００２７】
ＤＬＮＡサーバ２００は、通信部２０１と、制御部２０２と、操作部２０５と、表示部３０６と、記憶部３０７とで構成される。通信部２０１、操作部２０５、表示部２０６については、ＤＬＮＡクライアント１００と同様の構成であるものとする。記憶部３０７には、写真や音楽、ビデオ等のコンテンツが記憶されている他、これらのコンテンツの属性情報及びその階層構造を有するＣＤＳ３０８が記憶されている。
【００２８】
また、制御部２０２は、ＨＴＴＰ処理モジュール２０４とＵＰｎＰデバイス処理モジュール２０３とを備える。ＨＴＴＰ処理モジュール２０４は、ＨＴＴＰサーバの処理を行うものであり、ＤＬＮＡクライアント１００から送信されたコマンドの解析及び応答処理を行う。Ｂｒｏｗｓｅコマンドを受信した場合には、記憶部３０７に記憶されているコンテンツ管理情報の送信処理等を行う。
【００２９】
収集サーバ３００は、通信部３０１と制御部３１０と記憶部３２０とで構成される。図１に示した例では、収集サーバ３００が操作部や表示部を備えていない構成としてあるが、これらを備える機器に適用してもよい。記憶部３２０には、コンテナリスト３２１（フォルダ名記憶部）と、コンテンツデータベース３２２（以下、コンテンツＤＢ３２２と称する）を記憶させてある。コンテナリスト３２１には、ＤＬＮＡサーバ２００から送信されたコンテンツ管理情報にコンテナが含まれていた場合に、そのコンテナの名前が書き込まれる。
【００３０】
コンテンツＤＢ３２２とは、ＤＬＮＡサーバ２００が有するＣＤＳ３０８の情報を基に、実コンテンツであるアイテムと、そのアイテムが格納されているコンテナ（親コンテナ）の名前とを対応付けて、アイテムのメタデータとして記録することで生成されるデータベースである。コンテンツＤＢ３２２の構成の詳細については後述する。
【００３１】
制御部３１０は、ＤＬＮＡサーバ２００からコンテンツ管理情報を取得して、コンテンツＤＢ３２２に渡す処理を行う収集モジュール３１０ａと、ＤＬＮＡクライアント１００からの要求に応じて、コンテンツＤＢ３２２に記録された情報を基にカテゴリ一覧又はコンテンツ情報一覧（オブジェクト一覧）を生成し、生成した一覧をＤＬＮＡクライアント１００に送信する処理を行う、一覧送信モジュール３１０ｂとを備える。
【００３２】
収集モジュール３１０ａは、さらにＨＴＴＰ処理モジュール３０１と、ＵＰｎＰコントロールポイントモジュール３０２と、一覧探索モジュール３０３（コンテンツ情報探索部）と、メタデータ格納処理モジュール３０４（コンテンツ情報データベース生成部）とで構成される。
【００３３】
収集モジュール３１０ａは、ＤＬＮＡサーバ２００がサーバであるのに対して、クライアントとしての位置づけで処理を行う。このため、ＨＴＴＰ処理モジュール３０１とＵＰｎＰコントロールポイントモジュール３０２では、ＤＬＮＡクライアント１００のＨＴＴＰ処理モジュール１０３、ＵＰｎＰコントロールポイントモジュール１０４と同様の処理を行う。一覧探索モジュール３０３は、ＤＬＮＡサーバ２００から受信したＣＤＳ情報を解析して、ＣＤＳ情報を構成する各オブジェクトがコンテナであるかアイテムであるかの判断を行い、判断結果に基づいて適切な処理を行う。
【００３４】
メタデータ格納処理モジュール３０４は、一覧探索モジュール３０３が検出したオブジェクトがアイテムであった場合に、検出されたアイテムとその親コンテナの名前とを対応付けて、アイテムのメタデータとしてコンテンツＤＢ３２２に記録する処理を行う。一覧探索モジュール３０３、メタデータ格納処理モジュール３０４における処理の詳細については後述する。
【００３５】
一覧送信モジュール３１０ｂは、ＨＴＴＰ処理モジュール３０５と、ＵＰｎＰデバイス処理モジュール３０６と、一覧生成処理モジュール３０７（一覧生成部）と、リクエスト解釈モジュール３０８と、データベース検索モジュール３０９とで構成される。一覧送信モジュール３１０ｂは、ＤＬＮＡクライアント１００のサーバとしての位置づけで処理を行う。このため、ＨＴＴＰ処理モジュール３０５とＵＰｎＰデバイス処理モジュール３０６では、ＤＬＮＡサーバ２００のＨＴＴＰ処理モジュール２０３、ＵＰｎＰデバイス処理モジュール２０４と同様の処理を行う。
【００３６】
リクエスト解釈モジュール３０８は、ＤＬＮＡクライアント１００から送信されたコマンドの内容を解析し、一覧に含める情報の種別を判定する。データベース検索モジュール３０９は、リクエスト解釈モジュール３０８で判定された種別のデータを、コンテンツＤＢ３２２から抽出する処理を行う。一覧生成処理モジュール３０７は、データベース検索モジュール３０９で抽出されたデータを基にカテゴリ一覧又はオブジェクト一覧を生成し、ＵＰｎＰに適合する形式に書き換える処理を行う。リクエスト解釈モジュール３０８、データベース検索モジュール３０９、一覧生成処理モジュール３０７における処理の詳細については後述する。
【００３７】
次に、図２〜図５のフローチャートを参照して、収集サーバ３００がＤＬＮＡサーバ２００からコンテンツ管理情報を取得して、ＤＬＮＡクライアント１００にカテゴリ一覧及びオブジェクト一覧を送信し、ＤＬＮＡクライアント１００が実コンテンツを取得するまでの処理の流れについて説明する。
【００３８】
図２には、収集サーバ３００がＤＬＮＡサーバ２００からコンテンツ管理情報を取得する場合の処理例を示してある。収集サーバ３００は、ユーザにより設定された、１時間等の所定の間隔毎に、ＤＬＮＡサーバ２００に対してＳｙｓｔｅｍＵｐｄａｔｅＩＤの取得要求を送信する（ステップＳ１）。ＳｙｓｔｅｍＵｐｄａｔｅＩＤとは、ＤＬＮＡサーバ２００が有する任意の正整数の値であり、ＤＬＮＡサーバ２００自身のコンテンツに追加や削除、更新等があった場合に、ＤＬＮＡサーバ２００によって変更される値である。
【００３９】
ＤＬＮＡサーバ２００は、収集サーバ３００からのＩＤ値の取得要求を受けると、収集サーバ３００にＳｙｓｔｅｍＵｐｄａｔｅＩＤを返送する（ステップＳ２）。収集サーバ３００では、ＳｙｓｔｅｍＵｐｄａｔｅＩＤを取得すると、ＤＬＮＡサーバ２００へのアクセスが１回目のアクセスであったか否かの判定を行う（ステップＳ３）。ＤＬＮＡサーバ２００へのアクセスが１回目であると判断された場合にはＹｅｓが選択され、取得したＳｙｓｔｅｍＵｐｄａｔｅＩＤ値を保存する処理が行われる（ステップＳ７）。
【００４０】
ＤＬＮＡサーバ２００へのアクセスが２回目以降であると判断された場合には、取得したＳｙｓｔｅｍＵｐｄａｔｅＩＤ値と、既に保存されているＳｙｓｔｅｍＵｐｄａｔｅＩＤ値とを比較し、両者の値に違いがあるか否かの判断が行われる（ステップＳ４）。両者の値が同じであると判断された場合には、ＤＬＮＡサーバ２００においてコンテンツの更新等が行われていないことになるため、何もせずそのまま処理は終了となる。両者の値が異なると判断された場合には、収集サーバ３００からＤＬＮＡサーバ２００に対して、コンテンツ管理情報の取得要求が送信される（ステップＳ５）。そして、ＤＬＮＡサーバ２００からコンテンツ管理情報が送信されると（ステップＳ５）、コンテンツ管理情報を取得すると共に、取得したＳｙｓｔｅｍＵｐｄａｔｅＩＤ値で前回のＳｙｓｔｅｍＵｐｄａｔｅＩＤ値を上書きする（ステップＳ７）。つまり、ＤＬＮＡサーバ２００でコンテンツの追加や削除、更新等があった場合にのみ、コンテンツ管理情報の収集が行われるようになる。
【００４１】
次に、図３のフローチャートを参照して、収集サーバ３００におけるコンテンツＤＢ３２２の生成処理の例について説明する。図３に示された処理は、図２のステップＳ６でＤＬＮＡサーバ２００から送信されたコンテンツ管理情報を取得した後に行われるものである。
【００４２】
コンテンツ管理情報を取得した後は、まずコンテナリスト３２１にルートコンテナの名前を追加する処理が行われる（ステップＳ１１）。取得したコンテンツ管理情報が、図１７に示されたような構成であった場合には、コンテナリストには“ルート”と記されることになる。次に、コンテナリスト３２１が空であるか否かの判断が行われる（ステップＳ１２）。以降に説明する処理が完了している場合には、コンテナリスト３２１は空となるため、その場合はＹｅｓが選択され、処理は終了となる。
【００４３】
コンテナリストが空でないと判断された場合には、取得したコンテンツ管理情報から、コンテナが１つ取り出される（ステップＳ１３）。そして、コンテナ直下のオブジェクトの一覧が取得される（ステップＳ１４）。図１７に示した例を用いて説明すると、ステップＳ１４では、取り出したコンテナがルートコンテナＣ０であった場合には、ルートコンテナＣ０直下のコンテナＣ１〜Ｃ４の情報が取得されることになる。また、取り出したコンテナがコンテナＣ１であった場合には、そこに格納されているアイテムＩｔ１、アイテムＩｔ２の情報が取得されることになる。コンテナの取得は、階層の上層から下層に向かって順に行われるものとする。
【００４４】
次に、オブジェクト一覧内のすべてのオブジェクトに対して、後述する処理が完了しているか否かの判断が行われる（ステップＳ１５）。処理が完了していないと判断された場合には、オブジェクト一覧から、オブジェクトが１つ取り出される（ステップＳ１６）。そして、取り出したオブジェクトがコンテナであるか否かの判定が行われる（ステップＳ１７）。
【００４５】
取り出したオブジェクトがコンテナであった場合には、コンテナリスト３２１にコンテナの名前が追加される（ステップＳ１８）。取り出したオブジェクトがコンテナではなく、アイテムであった場合には、アイテムが格納されている親コンテナの名前をアイテムと結びつけ、アイテムのメタデータとしてコンテンツＤＢ３２２に格納する処理が行われる（ステップＳ１９）。ここでいう親コンテナの名前とは、ステップＳ１６で取り出されたコンテナリストから取り出されたコンテナの名前である。
【００４６】
ステップＳ１８とステップＳ１９の処理が行われた後は、ステップＳ１５に戻り、オブジェクト一覧内のすべてのオブジェクトに対して、ステップＳ１７〜ステップＳ１８又はステップＳ１９の処理が行われたか否かの判断が行われる。すべてのオブジェクトに対して処理が行われたと判断された場合にはＹｅｓが選択され、ステップＳ１２に戻る。ステップＳ１２でコンテナリスト３２１が空であると判断された場合には、処理は終了となる。上述した各ステップのうち、ステップＳ１６とステップＳ１７の処理は一覧探索モジュール２０３で行われる処理となり、ステップＳ１９の処理が、メタデータ格納処理モジュール２０４で行われる処置となる。
【００４７】
このような処理が行われることにより、アイテムと、アイテムが格納されている親コンテナの名前とが結び付けられて、アイテムのメタデータとして記憶されるようになる。メタデータとして登録されている情報であれば、検索時のキーとして用いることも可能となる。よって、ユーザにとって意味のある場合の多い親コンテナの名前を、コンテンツ検索の際のキーとして使用できるようになる。
【００４８】
次に、図３を用いて説明した処理が行われる場合に、実際にＤＬＮＡサーバ２００からどのような情報が送信され、収集サーバ３００においてどのようなコンテナリスト３２１又はコンテンツＤＢ３２２が生成されるのかについて、図４を参照して具体例を挙げながら説明する。
【００４９】
まず、図３のステップＳ１３で取り出されたコンテナがルートコンテナであったところからの処理を説明する。図４のステップＳ２１では、コンテナリスト３２１からルートコンテナが取り出され（ステップＳ２１）、ＤＬＮＡサーバ２００に対してオブジェクト一覧の送信要求が送られる（ステップＳ２２）。ここではＢｒｏｗｓｅコマンドが使用され、コマンド内では、ルートコンテナのＩＤである０が指定されている。
【００５０】
ＤＬＮＡサーバ２００では、オブジェクト一覧送信の要求を受け付けると、図４にＯＬ１として示したようなＸＭＬの記述を、オブジェクト一覧として返信する（ステップＳ２３）。オブジェクト一覧ＯＬ１には、各コンテナのＩＤと名前が記されており、コンテナの名前は、“ｄｃ：ｔｉｔｌｅ”のプロパティ値として示されている。
【００５１】
そして、オブジェクト一覧を受信した収集サーバ３００では、ｄｃ：ｔｉｔｌｅのプロパティ値を、コンテナの名前としてコンテナリスト３２１に追加する処理を行う（ステップＳ２４）。オブジェクト一覧ＯＬ１を基に生成されたコンテナリストは、コンテナリストＣＬ１として示されたようなものとなる。つまり、ｄｃ：ｔｉｔｌｅのプロパティ値である「植物」や「動物」が、コンテナリストの「名前」として追加されるようになる。
【００５２】
そして次に、コンテナリストから「植物」のコンテナが１つ取り出され（ステップＳ２５）、取り出された「植物」のコンテナの直下にあるオブジェクトの一覧を取得したいという要求が、収集サーバ３００からＤＬＮＡサーバ２００に対して送信される（ステップＳ２６）。ステップＳ２５で「植物」のコンテナが取り出されたため、図４の左側に示されたコンテナリストＣＬ２には、ＩＤが２の「動物」のみが残されるようになる。
【００５３】
「植物」のコンテナＩＤは１であるため、ステップＳ２６でＤＬＮＡサーバ２００に対して送信されるＢｒｏｗｓｅコマンドにおいては、１が指定される。そして、１が指定されたＢｒｏｗｓｅコマンドを受け取ったＤＬＮＡサーバ２００は、ｃｏｎｔａｉｎｅｒ ｉｄが１である、「植物」という名のコンテナの直下にあるオブジェクトを抽出して図４にＯＬ２として示したようなオブジェクト一覧を生成し、生成したオブジェクト一覧を収集サーバ３００に対して送信する（ステップＳ２７）。オブジェクト一覧ＯＬ２には、“ｉｔｅｍ ｉｄ１０”の記載があるように、アイテムの情報が含まれているため、収集サーバ３００では、アイテムのｄｃ：ｔｉｔｌｅプロパティ値をアイテムのタイトルとしてコンテンツデータベースＣＤ１に書き込む。それと同時に、その親コンテナの名前、つまりステップＳ２５でコンテナリストから取り出された「名前」を、コンテンツデータベースＣＤ１に「カテゴリ」として書き込む処理を行う（ステップＳ２８）。
【００５４】
オブジェクト一覧ＯＬ２においては、アイテムの名前として“Ｗｉｎｔｅｒ Ｌｅａｖｅｓ．ｊｐｇ”や“Ｔｒｅｅ．ｊｐｇ”の記載があり、これらのアイテムを格納している親コンテナの名前は“植物”であるため、コンテンツデータベースＣＤ１においては、アイテム名がタイトルとして格納され、親コンテナの名前がカテゴリとして格納されるようになる。
【００５５】
次に、ＤＬＮＡクライアント１００からのコンテンツ検索要求に基づいて、収集サーバ３００がカテゴリ一覧を送信する処理の例について、図５のフローチャートを参照して説明する。まず、ＤＬＮＡクライアント１００で、表示部１０６（図１参照）に表示されたメニュー画面上で、コンテンツ検索のキーとして「カテゴリ」が選択されると（ステップＳ３０）、ＤＬＮＡクライアント１００から収集サーバ３００に対して、カテゴリ情報の取得要求が送信される（ステップＳ３１）。ここで送信されるのはＢｒｏｗｓｅコマンドであり、コマンド内では“ＣａｔｅｇｏｒｙＬｉｓｔ”が指定されている。
【００５６】
図６には、メニュー画面の例を示してある。図６に示した例では、コンテンツ検索のキーの種類として、上から「登録日から探す」、「カテゴリから探す」、「キーワードから探す」、「すべてのフォト」の項目が記されている。ユーザは、図６に示した画面上で、カーソルＣＳ１を上下に移動させることで、所望のキーを選択することができる。
【００５７】
収集サーバ３００は、ＤＬＮＡクライアント１００からのカテゴリ情報取得要求を受信すると、コンテンツＤＢ３２２からカテゴリを抽出し、抽出されたカテゴリに重複がある場合には、重複を削除する処理を行う（ステップＳ３２）。例えばカテゴリとして、「動物」、「植物」、「入学式」、「動物」を抽出した場合には、「動物」は１つのみを抽出するようにする。そして抽出した情報を基に、カテゴリ一覧を生成する処理を行う（ステップＳ３３）。
【００５８】
ステップＳ３３で生成されるカテゴリ一覧は、例えば図５にカテゴリ一覧ＣｔＬ１として示されたようなものとなる。コンテナのＩＤとして‘“ｋｉｎｄ＝Ｃ＆ｎａｍｅ＝“動物”’や‘“ｋｉｎｄ＝Ｃ＆ｎａｍｅ＝“植物”’が指定されており、ｄｃ：ｔｉｔｌｅプロパティの値として、“動物”や“植物”が指定されている。このようなカテゴリ一覧が、収集サーバ３００からＤＬＮＡクライアント１００に送信される（ステップＳ３４）。
【００５９】
ＤＬＮＡクライアント１００では、ステップＳ３４で収集サーバ３００から送られたメッセージを基に、カテゴリ一覧を表示する（ステップＳ３５）。そして、受信したカテゴリ一覧に含まれるｃｏｎｔａｉｎｅｒ ｉｄ値とｄｃ：ｔｉｔｌｅ値を、それぞれＩＤとカテゴリ名として記憶部１０７（図１参照）等に記憶させておく。
【００６０】
ステップＳ３５で表示されるカテゴリ一覧は、例えば図７に示したものになる。図７では、画面上の上から「風景」、「入学式」、「動物」、「植物」、「花」という項目が表示されているが、これらは、ステップＳ３５で収集サーバ３００から送信されたカテゴリ一覧に含まれている、ｄｃ：ｔｉｔｌｅプロパティ値を反映させたものである。
【００６１】
このような画面上で、ユーザからの操作に基づいて例えば「植物」が選択されると、ＤＬＮＡクライアント１００から収集サーバ３００に、特定されたカテゴリの情報が送信される（ステップＳ３６）。ここでもＢｒｏｗｓｅコマンドが使用され、コマンドの中でＩＤとして‘“ｋｉｎｄ＝ｃ＆ｎａｍｅ＝“植物”’が指定されている。このＩＤは、収集サーバ３００から送信されたカテゴリ一覧に含まれていたｃｏｎｔａｉｎｅｒ ｉｄをそのまま使用したものである。
【００６２】
収集サーバ３００は、ＤＬＮＡクライアント１００から送信された、カテゴリの特定情報を受信すると、特定された「植物」のカテゴリをキーに、コンテンツＤＢ３２２に対して検索を行う処理を行う（ステップＳ３７）。そして、特定された「植物」のカテゴリに属するオブジェクト群をコンテンツＤＢ３２２から取り出し（ステップＳ３８）、取り出したオブジェクト群を用いてオブジェクト一覧の生成を行う（ステップＳ３９）。そして、ＤＬＮＡクライアント１００に対してオブジェクト一覧を送信する処理を行う（ステップＳ４０）。
【００６３】
ステップＳ３７〜ステップＳ３９までの処理は、ＤＬＮＡクライアント１００から送信されたＢｒｏｗｓｅコマンドに含まれる‘“ｋｉｎｄ＝ｃ＆ｎａｍｅ＝“植物”’を解釈した結果、行われるものである。つまり、‘“ｋｉｎｄ＝ｃ＆ｎａｍｅ＝“植物”’が、収集サーバ３００に対するコマンドとしても機能していることになる。そのコマンドとは、カテゴリ「植物」でのコンテンツＤＢ３２２の検索と、抽出した結果を用いての一覧生成を命じるものである。
【００６４】
収集サーバ３００では、自分がＤＬＮＡクライアント１００送ったメッセージが、このような形で返信されることを見越した上で、コマンドの意味を含んだメッセージを予めｃｏｎｔａｉｎｅｒ ｉｄに含めて送信するようにしてある。
【００６５】
また、ステップＳ３８で生成されたオブジェクト一覧は、例えば図５にオブジェクト一覧ＯＬ３として示されたもののようになる。オブジェクト一覧ＯＬ３には、ｄｃ：ｔｉｔｌｅプロパティ値として“Ｗｉｎｔｅｒ Ｌｅａｖｅｓ．ｊｐｇ”や“Ｔｒｅｅ．ｊｐｇ”といった値が記されており、これらはアイテム、つまり実コンテンツの名前を意味している。そして、ＤＬＮＡクライアント１００の表示部１０６上に、図８に示したようなオブジェクト一覧が表示される（ステップＳ４１）。
【００６６】
図８に示したオブジェクト一覧では、画面の左側にコンテンツのサムネイルが表示されており、その右側に“Ｗｉｎｔｅｒ Ｌｅａｖｅｓ．ｊｐｇ”といったコンテンツの名前と、２００５／１／１７ 午前６：４３といった撮影時刻が示されている。図５に示したオブジェクト一覧ＯＬ３には、撮影時刻等の情報は図示されていないが、ステップＳ４０で収集サーバ３００からＤＬＮＡクライアント１００に送信されるメッセージの中には、撮影時刻情報や、コンテンツの保存場所情報であるＵＲＬ等の情報も含まれているものとする。そしてＤＬＮＡクライアント１００は、送られたオブジェクト一覧に記載された情報を用いて、コンテンツ情報の一覧を生成し表示する。
【００６７】
次に、図９のフローチャートを参照して、ＤＬＮＡクライアント１００が実際に実コンテンツを取得する場合の処理例について説明する。図８に示した画面上で、ユーザが“Ｔｒｅｅ．ｊｐｇ”を選択した場合を例に挙げると、まず、ＤＬＮＡクライアント１００からＤＬＮＡサーバ２００に対して、コンテンツ配信の要求が送信される（ステップＳ５１）。ここで送信されるコマンドはＧＥＴコマンドであり、コマンドの中に“Ｔｒｅｅ．ｊｐｇ”の保存されている場所を示すＵＲＬが指定されている。このＵＲＬは、図５のフローチャートのステップＳ４０で、収集サーバ３００から送信されたオブジェクト一覧に含まれていたものである。
【００６８】
ＤＬＮＡサーバ２００は、ＤＬＮＡクライアント１００から送られたコンテンツ配信要求を受信すると、リクエスト内で指定されたコンテンツを読み出し、ＤＬＮＡクライアント１００に対して送信する処理を行う（ステップＳ５２）。そして、ＤＬＮＡクライアント１００は、送られたコンテンツを表示部１０６に表示する処理を行う（ステップＳ５３）。
【００６９】
このように、収集サーバ３００において、ＤＬＮＡサーバ２００のコンテンツ管理情報を基に、アイテムとそのアイテムが格納されたコンテナの名前とを対応付け、アイテムのメタデータとして記憶するようにしたため、アイテムが格納されたコンテナの名前で、アイテムつまり実コンテナを検索できるようになる。
【００７０】
図１０には、ＤＬＮＡサーバ２００におけるＣＤＳの例と、収集サーバ３００でＤＬＮＡサーバ２００のコンテンツ管理情報を基に生成されたコンテンツＤＢ３２２の登録例を示してある。図１０においては、“運動会”として分類されたコンテナが、ＤＬＮＡサーバ２００ａ内にコンテナＣｎ１として、また、ＤＬＮＡサーバ２００ｂ内にコンテナＣｎ３として存在している様子が示されている。そして、コンテナＣｎ１には写真コンテンツであるアイテムＩｔ１０とアイテムＩｔ１１、コンテナＣｎ２には、写真コンテンツであるアイテムＩｔ１３とアイテム１４が格納されている。
【００７１】
本例ではこの場合、アイテムＩｔ１０、アイテムＩｔ１１、アイテムＩｔ１３、アイテムＩｔ１４の親コンテナ名である「運動会」を、アイテムのカテゴリとしてコンテンツＤＢ３２２に記録させる。これにより、ＤＬＮＡサーバ２００ａとＤＬＮＡサーバ２００ｂに分散して記録されているアイテムであっても、収集サーバ３００上では、同じ「運動会」のカテゴリに属するアイテムとして取り扱うことができるようになる。よって、ユーザは「運動会」というカテゴリを指定することで、このカテゴリに属するアイテムＩｔ１０、アイテムＩｔ１１、アイテムＩｔ１３、アイテムＩｔ１４を容易に探し当てることができるようになる。
【００７２】
コンテナの名前はユーザがコンテンツの分類のために作成したフォルダの名前であり、図１０に示した例において、コンテナＣ１の名前は「運動会」、コンテナＣｎ２の名前は「入学式」が、コンテナＣｎ４の名前は「誕生日」とされているように、コンテナの名前はユーザにとって意味のあるものである場合が多い。よって、このようにアイテムが格納された親コンテナの名前で、アイテム（コンテンツ）を検索できるようにすることで、ユーザによるコンテンツ検索の効率を向上させることができる。
【００７３】
また、アイテムと親コンテナの名前とを結びつけて、アイテムのメタデータとして登録するという簡単な手法を用いているため、将来的にＤＬＮＡサーバ２００が、コンテンツの分類ツリー構造を自動的に生成する仕組みができた場合であっても、仕様を変更することなく、容易に適用させることが可能となる。
【００７４】
なお、上述した実施の形態では、アイテムのメタデータとしてコンテンツＤＢ３２２に追加する情報を、アイテムを格納している親コンテナの名前とした場合の例を挙げて説明したが、親コンテナの名前だけでなく、その更に上の階層のコンテナの名前も同時にアイテムと結びつけて登録するようにしてもよい。
【００７５】
この場合のＤＬＮＡサーバ２００におけるＣＤＳの例と、収集サーバ３００でのコンテンツＤＢ３２２の登録例を、図１１に示してある。図１１に示した例では、“子供の写真”と名づけられたコンテナＣｎ１０を頂点に、その配下に“花子の記録”と名づけられたコンテナＣｎ７と、“太郎の記録”と名づけられたコンテナＣｎ１１とがぶら下がっている。そして、“花子の記録”という名のコンテナＣｎ７の直下には、“運動会”と名づけられたコンテナＣｎ３と、“誕生日”と名づけられたコンテナＣｎ４とが接続されている。“運動会”という名のコンテナＣｎ３には、写真コンテンツであるアイテムＩｔ１３とアイテムＩｔ１４とが格納されており、“誕生日”という名のコンテナＣｎ４には、写真コンテンツであるアイテムＩｔ１５が格納されている。
【００７６】
“太郎の記録”という名のコンテナＣｎ１１の下には、“入学式”と名づけられたコンテナＣｎ１２と、“運動会”と名づけられたコンテナＣｎ１３とが繋がっており、“入学式”という名のコンテナＣｎ１２には写真コンテンツであるアイテムＩｔ２０とアイテムＩｔ２１が格納されており、“運動会”という名のコンテナＣｎ１３には、写真コンテンツであるアイテムＩｔ２２が格納されている。
【００７７】
このような構成のコンテンツ管理情報からコンテンツＤＢを生成する場合に、図１１に示した例では、アイテムを格納しているコンテナ名だけでなく、その上層のコンテナの名前も一緒に登録するようにしてある。例えばアイテムＩｔ２０であれば、親コンテナＣｎ１２の名前である“入学式”のみならず、その親のコンテナＣｎ１１の名前である“太郎の記録”、そしてそのまた上のコンテナＣｎ１０の名前である“子供の写真”も、アイテムＩｔ２０に関連付けられて、アイテムＩｔ２０のメタデータとしてコンテンツＤＢ３２２に記憶される。
【００７８】
アイテムＩｔ１３においても同様に、親コンテナＣｎ３の名前である“運動会”だけでなく、その親コンテナＣｎ７の名前である“花子の記録”と、その１つ上のコンテナＣｎ１０の名前である“子供の写真”も、アイテムＩｔ１３のメタデータとして登録される。
【００７９】
このように、複数の階層のコンテナ名を取り扱うようにした場合は、アイテムとコンテナとの関係は、一対一ではなく、多対多の関係となる。よって、コンテンツＤＢ３２２では、アイテムのテーブルとカテゴリ（コンテナ名）テーブルとの関係を表す、リレーションテーブルを用いる必要がある。
【００８０】
図１２には、アイテムテーブルとカテゴリテーブル、そしてリレーションテーブルの構成例を示してある。アイテムテーブルＴ１では、項目として例えば、ＩＤ、ｄｃ：ｔｉｔｌｅ、ｒｅｓを有しており、“０１．ｊｐｇ”と“０２．ｊｐｇ”の情報を保持しているものとする。そして、カテゴリテーブルＴ２では、“太郎の記録”、“運動会”、“入学式”といったカテゴリが、ＩＤとともに記録されているものとする。
【００８１】
そして、アイテムＩＤ１の“０１．ｊｐｇ”と結び付けられているカテゴリは、カテゴリＩＤ１の“太郎の記録”とカテゴリＩＤ２の“運動会”であり、アイテムＩＤ２の“０２．ｊｐｇ”と結び付けられているカテゴリは、カテゴリＩＤ１の“太郎の記録”とカテゴリＩＤ３の“入学式”であるものとする。
【００８２】
この場合、リレーションテーブルＴ３として示したように、アイテムとカテゴリとを対応付ける間接テーブルを用いることで、アイテムとカテゴリとの多対多の関係を表現することが可能となる。
【００８３】
アイテムとカテゴリとの関係が多対多である場合の、コンテンツＤＢ生成処理例について、図１３にフローチャートとして示してある。ステップＳ６１からステップＳ６７までは、図３のフローチャートのステップＳ１１からステップＳ１７と同様であるため、説明を省略する。図１３のステップＳ６７で、オブジェクトがコンテナであると判定された場合には、親とその上の階層のコンテナ（祖先コンテナ）の名前とを結びつけて、コンテナリストにコンテナを追加する（ステップＳ６８）。オブジェクトがコンテナではなく、アイテムであると判定された場合には、アイテムの親コンテナの名前及びその祖先のコンテナの名前とをアイテムと結びつけて、アイテムのメタデータとしてコンテンツＤＢ３２２に格納する（ステップＳ６９）。
【００８４】
このような処理を行うことで、コンテンツの検索を行う際に、アイテム（コンテンツ）が格納されているコンテナの名前だけでなく、その上層のコンテナの名前も用いることができるようになる。
【００８５】
また、上述した実施の形態では、ＤＬＮＡクライアント１００でコンテンツの検索を行う場合に、アイテムの親コンテナの名前を一覧で表示させ、その中から所望のキーを選択する例を挙げたが、キーワードで検索する場合に適用させてもよい。この場合は、ユーザより入力されたキーワードをキーに、収集サーバ３００でコンテンツＤＢ３２２のカテゴリを抽出し、抽出したカテゴリに属するアイテムをＤＬＮＡクライアント１００に対して一覧で出力させるようにすればよい。
【００８６】
また、上述した実施の形態では、収集サーバ３００を、ＤＬＮＡクライアント１００やＤＬＮＡサーバ２００とは独立した機器上で稼動させる例を説明したが、ＤＬＮＡクライアント１００上に収集サーバ３００のモジュールを載せることで、ＤＬＮＡクライアントと収集サーバの機能を、１つの機器上で実現させた構成に適用することも可能である。
【００８７】
また、上述した実施の形態では、写真コンテンツを処理する場合を例に挙げて説明を行ったが、他のコンテンツにも適用可能である。メタデータの種類が少なく、検索の際のキーを多く持たないコンテンツの種類であれば、特に高い効果を得られる。
【００８８】
また、上述した実施形態例における一連の処理は、ハードウェアにより実行することができるが、ソフトウェアにより実行させることもできる。一連の処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムを、専用のハードウェアに組み込まれているコンピュータ、または、各種のプログラムをインストールすることで各種の機能を実行することが可能な例えば汎用のパーソナルコンピュータなどに所望のソフトウェアを構成するプログラムをインストールして実行させる。
【図面の簡単な説明】
【００８９】
【図１】本発明の一実施の形態によるシステムの構成例を示す構成図である。
【図２】本発明の一実施の形態による収集サーバによるコンテンツ情報取得判断処理の例を示すフローチャートである。
【図３】本発明の一実施の形態による収集サーバにおけるコンテンツデータベース生成処理の例を示すフローチャートである。
【図４】本発明の一実施の形態によるコンテンツデータベースの生成処理例を示すフローチャートである。
【図５】本発明の一実施の形態によるオブジェクト一覧生成送信処理の例を示すフローチャートである。
【図６】本発明の一実施の形態による検索画面の例を示す説明図である。
【図７】本発明の一実施の形態によるカテゴリ一覧の表示例を示す説明図である。
【図８】本発明の一実施の形態によるオブジェクト一覧の表示例を示す説明図である。
【図９】本発明の一実施の形態によるＤＬＮＡクライアントによるコンテンツの取得処理例を示すフローチャートである。
【図１０】本発明の一実施の形態によるカテゴリ分類の例を示す説明図である。
【図１１】本発明の他の実施の形態によるコンテンツデータベースの登録例を示す説明図である。
【図１２】本発明の他の実施の形態によるテーブル間のリレーションの例を示す説明図である。
【図１３】本発明の他の実施の形態によるコンテンツデータベース生成処理例を示すフローチャートである。
【図１４】従来のシステム構成例を示す構成図である。
【図１５】従来の収集サーバを用いたシステムの構成例を示す構成図である。
【図１６】従来の画面表示例を示す説明図である。
【図１７】従来のコンテンツ情報一覧の構成例を示す説明図である。
【図１８】従来のメタデータの構成例を示す説明図である。
【符号の説明】
【００９０】
１００…ＤＬＮＡクライアント、１０１…通信部、１０２…制御部、１０３…ＵＰｎＰコントロールポイントモジュール、１０４…ＨＴＴＰ処理モジュール、１０５…操作部、１０６…表示部、１０７…記憶部、２００…ＤＬＮＡサーバ、２０１…通信部、２０２…制御部、２０３…ＵＰｎＰデバイス処理モジュール、２０４…ＨＴＴＰ処理モジュール、２０５…操作部、２０６…表示部、２０７…記憶部、３００…収集サーバ、３０１…ＨＴＴＰ処理モジュール、３０２…ＵＰｎＰコントロールポイントモジュール、３０３…一覧探索モジュール、３０４…メタデータ格納処理モジュール、３０５…データベース検索モジュール、３０６…リクエスト解釈モジュール、３０７…一覧生成処理モジュール、３０８…ＵＰｎＰデバイス処理モジュール、３０９…ＨＴＴＰ処理モジュール、３１０…制御部、３２０…記憶部、３２１…コンテナリスト、３２２…コンテンツデータベース
【技術分野】
【０００１】
本発明は、メディアサーバからコンテンツを受信して再生できるクライアントと、前記メディアサーバから前記コンテンツに関連するコンテンツ管理情報を受信して管理する収集サーバとで構成される情報処理システム及び情報処理方法、プログラム、並びにそのシステムに適用される収集サーバに関する。
【背景技術】
【０００２】
ホームネットワーク環境でデジタルＡＶ機器同士や、パソコンを相互に接続するための技術ガイドラインとして、ＤＬＮＡ（Digital Living Network Alliance）ガイドラインが知られている。ＤＬＮＡガイドラインは、コンテンツを提供するサーバと、コンテンツを再生するクライアントとの間における接続条件を定めたものであり、このガイドラインに準拠した機器同士であれば、特別な設定をしなくても、線をつなぐだけで相互接続してコンテンツを共用できるようになる。
【０００３】
ＤＬＮＡガイドラインでは、ネットワーク上の機器同士の連携を実現するプロトコルとして、ＵＰｎＰ(Universal Plug and Play)を使用することが決められており、クライアントとサーバ間でのコンテンツ及びコンテンツ管理情報のやり取りは、ＵＰｎＰ ＡＶの仕様に基づいて行われる。ユーザは、ＵＰｎＰコントロールポイントから、ＢｒｏｗｓｅコマンドまたはＳｅａｒｃｈコマンドを使ってサーバ内のＣＤＳ（Content Directory Service）を呼び出し、コンテンツ管理情報の一覧を取得する。そして、コンテンツ管理情報一覧に含まれているコンテンツの保存場所のＵＲＬ（Uniform Resource Locator）にアクセスすることで、所望のコンテンツを得ることができる。
【０００４】
図１４に、家庭内ＬＡＮ（Local Area Network）等のネットワーク２を介して、ＤＬＮＡクライアントとＤＬＮＡサーバ（メディアサーバ）とが接続されている様子を示してある。ＤＬＮＡクライアント１０としてノート型パーソナルコンピュータ１０ａ（以下、パーソナルコンピュータはＰＣと称する）とテレビジョン受像機１０ｃがあり、ネットワークメディアレシーバ２０を介して、ＤＬＮＡサーバ２０であるノート型ＰＣ２０ａやデスクトップ型ＰＣ２０ｂ、ＤＶＤ（Digital Versatile Disc）レコーダ２０ｃが接続されている。図１４には、ノート型ＰＣ２０ａに写真Ｐ１とビデオＶ１、音楽Ｍ１が記録されており、デスクトップ型ＰＣ２０ｂには写真Ｐ２と音楽Ｍ２、ビデオＶ２が、ＤＶＤレコーダ２０ｃにはビデオＶ３が記録されている様子が示されている。
【０００５】
ＤＬＮＡクライアント１０とＤＬＮＡサーバとは、ＤＬＮＡガイドラインに準拠した接続方式で接続されているため、ＤＬＮＡサーバ２０のそれぞれの機器上に記録された写真やビデオ、音楽等のコンテンツを、ＤＬＮＡクライアント１０のぞれぞれの機器で読み出して再生させることができる。
【０００６】
例えばＤＬＮＡクライアント１０のパーソナルコンピュータ１０ａで、ＤＬＮＡサーバ２０に保存されている写真２を見る場合には、写真２を保存しているデスクトップ型ＰＣ２０ｂにアクセスすればよい。しかしこの場合、写真２が記憶されている機器が何であるのかを、ＤＬＮＡクライアント１０側で予め把握しておく必要がある。このため、特に、様々な種類のＤＬＮＡサーバ２０に大量のコンテンツが記憶されている場合などは、コンテンツを探す手間や時間がかかってしまうという問題があった。
【０００７】
この問題を解決する手法としては、収集サーバを使って、家庭内の各ＤＬＮＡサーバ中のコンテンツ管理情報を一元で管理する手法が知られている。収集サーバを用いた場合のシステム構成例を、図１５に示してある。図１５に示した構成では、ＤＬＮＡサーバ２０の各機器に記録されたコンテンツのメタデータ（属性情報）を、収集サーバ３０に一括で管理させている。
【０００８】
図１５に示した例では、収集サーバ３０がコンテンツの種類毎にコンテンツを分類した場合の例を示してある。収集サーバ３０上では、ノート型ＰＣ２０ａに記録されているビデオＶ１と、デスクトップ型ＰＣ２０ｂ上のビデオＶ２、ＤＶＤレコーダ２０ｃ上のビデオＶ３とを、「ビデオ」という分類で一覧表示している。同様に、ノート型ＰＣ２０ａ上に記録された写真Ｐ１とデスクトップ型ＰＣ２０ｂ上に記録された写真Ｐ２とが、「写真」の分類で一覧表示されており、ノート型ＰＣ２０ａ上に記録された音楽Ｍ１とデスクトップ型ＰＣ２０ｂ上に記録された音楽Ｐ２とが、「音楽」の分類で一覧表示されている。
【０００９】
このように収集サーバ３０は、ＤＬＮＡサーバ２０の各機器に点在して記録されているコンテンツの情報を、データの種類やアーティスト別等に再分類して一覧で示す機能を備えているため、ＤＬＮＡクライアント１０の各機器は、収集サーバ３０にアクセスするだけで所望のコンテンツを容易に検索することができるようになる。
【００１０】
この他にも、コンテンツ検索の効率を向上させるための様々な手法が採られている。例えば特許文献１には、デジタルカメラからＰＣに画像を取り込む際に、画像のメタデータを用いて画像を自動的に分類する手法について、開示がしてある。
【特許文献１】特開２００６−２６２２１４号公報
【発明の開示】
【発明が解決しようとする課題】
【００１１】
特許文献１にも記載があるように、特にデジタルカメラや携帯電話端末等で撮影された静止画像では、そのメタデータが、撮影日付や、機器がその静止画像に対して自動的に付与したタイトルのみである場合が多い。図１６に、収集サーバ３０上で静止画像の一覧が表示されている様子を示してある。図１６に示した画面では、画面左側に画像のサムネイルが表示されており、その隣にＤＳＣ０００５．ＪＰＧ等の画像のタイトル、２００５／９／３ 午後６：４０等の撮影日時が表示されている。
【００１２】
ところが、図１６に表示されたような情報のみをキーとして、得たい画像を検索することは難しい場合がある。撮影日時や画像のタイトル等は、ユーザにとって意味の無い分類であることが多いためである。
【００１３】
ＤＬＮＡクライアント１０の種類によっては、ＤＬＮＡサーバ２０内のＣＤＳ（Container Directory Service）と呼ばれるコンテンツの階層構造を、ユーザが操作するメニュー画面上にそのまま見せるものもある。ＣＤＳは、例えば図１７に示したような構造であり、コンテナと呼ばれるフォルダが階層状に結び付けられている。コンテナの中には、コンテナ単体で存在するものや、アイテムと呼ばれるコンテンツの実ファイルを備えるものがある。なお、コンテナ又はアイテムは、共にオブジェクトという総称でも呼称される。
【００１４】
図１７に示した例では、ルートコンテナＣ０の下に、“録画ビデオ”と名づけられたコンテナＣ１と、“アルバム一覧”と名づけられたコンテナＣ２がぶら下がっており、コンテナＣ２の下に、“アルバム１”と名づけられたコンテナＣ３と、“アルバム２”と名づけられたコンテナＣ４とが接続されている。コンテナＣ３には、更に“オマケ”と名づけられたコンテナＣ５が接続されている。そして、コンテナＣ２の中にビデオコンテンツであるアイテムＩｔ１とＩｔ２が格納されており、コンテナＣ３の中に写真コンテンツであるアイテムＩｔ３、Ｉｔ４、Ｉｔ５が、コンテンツＣ４の中に写真コンテンツであるアイテムＩｔ６が格納されている様子が示されている。つまり、ＣＤＳはユーザが作成したフォルダ名や階層をそのまま示したものであり、ＣＤＳにおけるフォルダ名は、ユーザにとっては意味のあるものである場合が多い。
【００１５】
このような階層がメニュー画面上に表示されていれば、ユーザがその階層をたどって目的の写真にたどり着くことも可能であるが、目的の写真にたどり着くまでの間に、階層間を何度も移動しなければならないことも多く、操作性が良いとは言えなかった。
【００１６】
また、撮影日付やタイトル以外のメタデータも、ＣＤＳでは有するように規定されているため、これらのメタデータを検索の条件に追加することができれば、検索の効率を向上させることができるはずである。図１８（ａ）には、５種類の必須メタデータを示してあり、図１８（ｂ）には、任意で追加可能なメタデータを示してある。
【００１７】
必須のメタデータとしては、コンテンツごとに割り振られる一意のＩＤである＠ｉｄや、コンテンツの一階層上のコンテンツのＩＤである＠ｐａｒｅｎｔＩＤ、コンテンツが変更可能かどうかを示す＠ｒｅｓｔｒｉｃｔｅｄ、タイトルを示すｄｃ：ｔｉｔｌｅ、コンテンツの種別を示すｕｐｎｐ：ｃｌａｓｓがある。任意に追加可能なメタデータとしては、日時情報を示すｄｃ：ｄａｔｅや、概要を示すｄｃ：ｄｅｓｃｒｉｐｔｉｏｎ、アーティスト情報を示すｕｐｎｐ：ａｒｔｉｓｔ、アルバム情報を示すｕｐｎｐ：ａｌｂｕｍ、ジャンル情報を示すｕｐｎｐ：ｇｅｎｒｅ、コンテンツデータの取得先ＵＲＬであるｒｅｓ等がある。
【００１８】
ところが、コンテンツ検索のキーとして使えそうな項目を、任意に追加可能なメタデータとして追加することは可能であるが、その意味をＤＬＮＡクライアント１０との間で共有し合わなければ、追加した項目を検索項目として使用することはできない。しかし、このような情報を共有するためのＤＬＮＡ共通の枠組みは存在していない。よって現状では、拡張情報として追加したメタデータを、ＤＬＮＡクライアント１０やＤＬＮＡサーバ２０を構成する様々な機器間で共有することは、不可能であると言える。
【００１９】
本発明はかかる点に鑑みてなされたものであり、ユーザにとってコンテンツの検索を行いやすいシステムを提供することを目的とする。
【課題を解決するための手段】
【００２０】
本発明は、メディアサーバからコンテンツを受信して再生できるクライアントと、メディアサーバからコンテンツに関連するコンテンツ管理情報を受信して管理する収集サーバとで構成される情報処理システムにおいて、予め決められた条件に従って、コンテンツ管理情報をメディアサーバから取得し、取得したコンテンツ管理情報に含まれるコンテンツの格納位置に関する情報を、コンテンツのカテゴリとして記憶するようにした。また、クライアントからコンテンツの検索条件を受信した場合には、検索条件に一致するコンテンツ情報を抽出してカテゴリ一覧し、生成したカテゴリ一覧をクライアントに送信するようにしたものである。
【００２１】
このようにしたことで、収集サーバからクライアントに送られるコンテンツ管理情報においては、コンテンツを格納したフォルダ（親フォルダ）の名前が、コンテンツのメタデータとして記録されるようになる。このため、クライアントがコンテンツを検索する際のキーとして、メタデータであるコンテンツのフォルダの名前を用いることができるようになる。
【発明の効果】
【００２２】
本発明によると、ユーザが意図して付与したフォルダ名を、コンテンツ検索の際のキーとして用いることができるようになるため、コンテンツ検索の効率を向上させることができる。
【発明を実施するための最良の形態】
【００２３】
以下、本発明の一実施の形態を、図１〜図１０を参照して説明する。本例では、従来例として図１５に示した構成と同様の構成としてあり、図１には、その内部構成例を示してある。なお、図１５に示した構成においては、ＤＬＮＡクライアントとしてノート型ＰＣとテレビジョン受像機、ＤＬＮＡサーバとしてデスクトップ型ＰＣとノート型ＰＣとＤＶＤレコーダ、収集サーバとしてデスクトップ型ＰＣを用いてあるが、機器構成は図１５に示した例に限定されるものではない。
【００２４】
図１に示したシステムにおいて、ＤＬＮＡクライアント１００とＤＬＮＡサーバ２００は、それぞれ収集サーバ３００に接続してある。収集サーバ３００は、ＤＬＮＡサーバ２００からのコンテンツ管理情報の収集と、収集したコンテンツ管理情報のＤＬＮＡクライアント１００への配信処理を行う。
【００２５】
ＤＬＮＡクライアント１００は、ネットワーク１との接続インターフェースである通信部１０１と、通信部１０１で行われる通信の制御や、ＤＬＮＡクライアント１００の各部の制御を行う制御部１０２と、ユーザからの操作入力を受け付ける操作部１０５と、収集サーバ３００から取得したコンテンツ管理情報や、コンテンツ管理情報の中からユーザによって選択された、写真やビデオ等のコンテンツを表示する表示部１０６と、コンテンツデータ等を記憶する記憶部１０７とで構成される。
【００２６】
また制御部１０２は、ＨＴＴＰ処理モジュール１０４と、ＵＰｎＰコントロールポイントモジュール１０３とを備える。ＨＴＴＰ処理モジュール１０４は、ＨＴＴＰクライアントの処理を行うものであり、ＧＥＴコマンド等のコマンドの生成や、コマンドに呼応して送られたレスポンスメッセージに含まれる、ＸＭＬ（Extensible Markup Language）や画像データを基に、表示画面を生成する処理を行う。ＵＰｎＰコントロールポイントモジュール１０３は、ネットワーク１に接続されたＵＰｎＰ対応デバイスの検出処理や、ＤＬＮＡサーバ２００内のＣＤＳ情報を取得するための、Ｂｒｏｗｓｅコマンドの生成等を行う。
【００２７】
ＤＬＮＡサーバ２００は、通信部２０１と、制御部２０２と、操作部２０５と、表示部３０６と、記憶部３０７とで構成される。通信部２０１、操作部２０５、表示部２０６については、ＤＬＮＡクライアント１００と同様の構成であるものとする。記憶部３０７には、写真や音楽、ビデオ等のコンテンツが記憶されている他、これらのコンテンツの属性情報及びその階層構造を有するＣＤＳ３０８が記憶されている。
【００２８】
また、制御部２０２は、ＨＴＴＰ処理モジュール２０４とＵＰｎＰデバイス処理モジュール２０３とを備える。ＨＴＴＰ処理モジュール２０４は、ＨＴＴＰサーバの処理を行うものであり、ＤＬＮＡクライアント１００から送信されたコマンドの解析及び応答処理を行う。Ｂｒｏｗｓｅコマンドを受信した場合には、記憶部３０７に記憶されているコンテンツ管理情報の送信処理等を行う。
【００２９】
収集サーバ３００は、通信部３０１と制御部３１０と記憶部３２０とで構成される。図１に示した例では、収集サーバ３００が操作部や表示部を備えていない構成としてあるが、これらを備える機器に適用してもよい。記憶部３２０には、コンテナリスト３２１（フォルダ名記憶部）と、コンテンツデータベース３２２（以下、コンテンツＤＢ３２２と称する）を記憶させてある。コンテナリスト３２１には、ＤＬＮＡサーバ２００から送信されたコンテンツ管理情報にコンテナが含まれていた場合に、そのコンテナの名前が書き込まれる。
【００３０】
コンテンツＤＢ３２２とは、ＤＬＮＡサーバ２００が有するＣＤＳ３０８の情報を基に、実コンテンツであるアイテムと、そのアイテムが格納されているコンテナ（親コンテナ）の名前とを対応付けて、アイテムのメタデータとして記録することで生成されるデータベースである。コンテンツＤＢ３２２の構成の詳細については後述する。
【００３１】
制御部３１０は、ＤＬＮＡサーバ２００からコンテンツ管理情報を取得して、コンテンツＤＢ３２２に渡す処理を行う収集モジュール３１０ａと、ＤＬＮＡクライアント１００からの要求に応じて、コンテンツＤＢ３２２に記録された情報を基にカテゴリ一覧又はコンテンツ情報一覧（オブジェクト一覧）を生成し、生成した一覧をＤＬＮＡクライアント１００に送信する処理を行う、一覧送信モジュール３１０ｂとを備える。
【００３２】
収集モジュール３１０ａは、さらにＨＴＴＰ処理モジュール３０１と、ＵＰｎＰコントロールポイントモジュール３０２と、一覧探索モジュール３０３（コンテンツ情報探索部）と、メタデータ格納処理モジュール３０４（コンテンツ情報データベース生成部）とで構成される。
【００３３】
収集モジュール３１０ａは、ＤＬＮＡサーバ２００がサーバであるのに対して、クライアントとしての位置づけで処理を行う。このため、ＨＴＴＰ処理モジュール３０１とＵＰｎＰコントロールポイントモジュール３０２では、ＤＬＮＡクライアント１００のＨＴＴＰ処理モジュール１０３、ＵＰｎＰコントロールポイントモジュール１０４と同様の処理を行う。一覧探索モジュール３０３は、ＤＬＮＡサーバ２００から受信したＣＤＳ情報を解析して、ＣＤＳ情報を構成する各オブジェクトがコンテナであるかアイテムであるかの判断を行い、判断結果に基づいて適切な処理を行う。
【００３４】
メタデータ格納処理モジュール３０４は、一覧探索モジュール３０３が検出したオブジェクトがアイテムであった場合に、検出されたアイテムとその親コンテナの名前とを対応付けて、アイテムのメタデータとしてコンテンツＤＢ３２２に記録する処理を行う。一覧探索モジュール３０３、メタデータ格納処理モジュール３０４における処理の詳細については後述する。
【００３５】
一覧送信モジュール３１０ｂは、ＨＴＴＰ処理モジュール３０５と、ＵＰｎＰデバイス処理モジュール３０６と、一覧生成処理モジュール３０７（一覧生成部）と、リクエスト解釈モジュール３０８と、データベース検索モジュール３０９とで構成される。一覧送信モジュール３１０ｂは、ＤＬＮＡクライアント１００のサーバとしての位置づけで処理を行う。このため、ＨＴＴＰ処理モジュール３０５とＵＰｎＰデバイス処理モジュール３０６では、ＤＬＮＡサーバ２００のＨＴＴＰ処理モジュール２０３、ＵＰｎＰデバイス処理モジュール２０４と同様の処理を行う。
【００３６】
リクエスト解釈モジュール３０８は、ＤＬＮＡクライアント１００から送信されたコマンドの内容を解析し、一覧に含める情報の種別を判定する。データベース検索モジュール３０９は、リクエスト解釈モジュール３０８で判定された種別のデータを、コンテンツＤＢ３２２から抽出する処理を行う。一覧生成処理モジュール３０７は、データベース検索モジュール３０９で抽出されたデータを基にカテゴリ一覧又はオブジェクト一覧を生成し、ＵＰｎＰに適合する形式に書き換える処理を行う。リクエスト解釈モジュール３０８、データベース検索モジュール３０９、一覧生成処理モジュール３０７における処理の詳細については後述する。
【００３７】
次に、図２〜図５のフローチャートを参照して、収集サーバ３００がＤＬＮＡサーバ２００からコンテンツ管理情報を取得して、ＤＬＮＡクライアント１００にカテゴリ一覧及びオブジェクト一覧を送信し、ＤＬＮＡクライアント１００が実コンテンツを取得するまでの処理の流れについて説明する。
【００３８】
図２には、収集サーバ３００がＤＬＮＡサーバ２００からコンテンツ管理情報を取得する場合の処理例を示してある。収集サーバ３００は、ユーザにより設定された、１時間等の所定の間隔毎に、ＤＬＮＡサーバ２００に対してＳｙｓｔｅｍＵｐｄａｔｅＩＤの取得要求を送信する（ステップＳ１）。ＳｙｓｔｅｍＵｐｄａｔｅＩＤとは、ＤＬＮＡサーバ２００が有する任意の正整数の値であり、ＤＬＮＡサーバ２００自身のコンテンツに追加や削除、更新等があった場合に、ＤＬＮＡサーバ２００によって変更される値である。
【００３９】
ＤＬＮＡサーバ２００は、収集サーバ３００からのＩＤ値の取得要求を受けると、収集サーバ３００にＳｙｓｔｅｍＵｐｄａｔｅＩＤを返送する（ステップＳ２）。収集サーバ３００では、ＳｙｓｔｅｍＵｐｄａｔｅＩＤを取得すると、ＤＬＮＡサーバ２００へのアクセスが１回目のアクセスであったか否かの判定を行う（ステップＳ３）。ＤＬＮＡサーバ２００へのアクセスが１回目であると判断された場合にはＹｅｓが選択され、取得したＳｙｓｔｅｍＵｐｄａｔｅＩＤ値を保存する処理が行われる（ステップＳ７）。
【００４０】
ＤＬＮＡサーバ２００へのアクセスが２回目以降であると判断された場合には、取得したＳｙｓｔｅｍＵｐｄａｔｅＩＤ値と、既に保存されているＳｙｓｔｅｍＵｐｄａｔｅＩＤ値とを比較し、両者の値に違いがあるか否かの判断が行われる（ステップＳ４）。両者の値が同じであると判断された場合には、ＤＬＮＡサーバ２００においてコンテンツの更新等が行われていないことになるため、何もせずそのまま処理は終了となる。両者の値が異なると判断された場合には、収集サーバ３００からＤＬＮＡサーバ２００に対して、コンテンツ管理情報の取得要求が送信される（ステップＳ５）。そして、ＤＬＮＡサーバ２００からコンテンツ管理情報が送信されると（ステップＳ５）、コンテンツ管理情報を取得すると共に、取得したＳｙｓｔｅｍＵｐｄａｔｅＩＤ値で前回のＳｙｓｔｅｍＵｐｄａｔｅＩＤ値を上書きする（ステップＳ７）。つまり、ＤＬＮＡサーバ２００でコンテンツの追加や削除、更新等があった場合にのみ、コンテンツ管理情報の収集が行われるようになる。
【００４１】
次に、図３のフローチャートを参照して、収集サーバ３００におけるコンテンツＤＢ３２２の生成処理の例について説明する。図３に示された処理は、図２のステップＳ６でＤＬＮＡサーバ２００から送信されたコンテンツ管理情報を取得した後に行われるものである。
【００４２】
コンテンツ管理情報を取得した後は、まずコンテナリスト３２１にルートコンテナの名前を追加する処理が行われる（ステップＳ１１）。取得したコンテンツ管理情報が、図１７に示されたような構成であった場合には、コンテナリストには“ルート”と記されることになる。次に、コンテナリスト３２１が空であるか否かの判断が行われる（ステップＳ１２）。以降に説明する処理が完了している場合には、コンテナリスト３２１は空となるため、その場合はＹｅｓが選択され、処理は終了となる。
【００４３】
コンテナリストが空でないと判断された場合には、取得したコンテンツ管理情報から、コンテナが１つ取り出される（ステップＳ１３）。そして、コンテナ直下のオブジェクトの一覧が取得される（ステップＳ１４）。図１７に示した例を用いて説明すると、ステップＳ１４では、取り出したコンテナがルートコンテナＣ０であった場合には、ルートコンテナＣ０直下のコンテナＣ１〜Ｃ４の情報が取得されることになる。また、取り出したコンテナがコンテナＣ１であった場合には、そこに格納されているアイテムＩｔ１、アイテムＩｔ２の情報が取得されることになる。コンテナの取得は、階層の上層から下層に向かって順に行われるものとする。
【００４４】
次に、オブジェクト一覧内のすべてのオブジェクトに対して、後述する処理が完了しているか否かの判断が行われる（ステップＳ１５）。処理が完了していないと判断された場合には、オブジェクト一覧から、オブジェクトが１つ取り出される（ステップＳ１６）。そして、取り出したオブジェクトがコンテナであるか否かの判定が行われる（ステップＳ１７）。
【００４５】
取り出したオブジェクトがコンテナであった場合には、コンテナリスト３２１にコンテナの名前が追加される（ステップＳ１８）。取り出したオブジェクトがコンテナではなく、アイテムであった場合には、アイテムが格納されている親コンテナの名前をアイテムと結びつけ、アイテムのメタデータとしてコンテンツＤＢ３２２に格納する処理が行われる（ステップＳ１９）。ここでいう親コンテナの名前とは、ステップＳ１６で取り出されたコンテナリストから取り出されたコンテナの名前である。
【００４６】
ステップＳ１８とステップＳ１９の処理が行われた後は、ステップＳ１５に戻り、オブジェクト一覧内のすべてのオブジェクトに対して、ステップＳ１７〜ステップＳ１８又はステップＳ１９の処理が行われたか否かの判断が行われる。すべてのオブジェクトに対して処理が行われたと判断された場合にはＹｅｓが選択され、ステップＳ１２に戻る。ステップＳ１２でコンテナリスト３２１が空であると判断された場合には、処理は終了となる。上述した各ステップのうち、ステップＳ１６とステップＳ１７の処理は一覧探索モジュール２０３で行われる処理となり、ステップＳ１９の処理が、メタデータ格納処理モジュール２０４で行われる処置となる。
【００４７】
このような処理が行われることにより、アイテムと、アイテムが格納されている親コンテナの名前とが結び付けられて、アイテムのメタデータとして記憶されるようになる。メタデータとして登録されている情報であれば、検索時のキーとして用いることも可能となる。よって、ユーザにとって意味のある場合の多い親コンテナの名前を、コンテンツ検索の際のキーとして使用できるようになる。
【００４８】
次に、図３を用いて説明した処理が行われる場合に、実際にＤＬＮＡサーバ２００からどのような情報が送信され、収集サーバ３００においてどのようなコンテナリスト３２１又はコンテンツＤＢ３２２が生成されるのかについて、図４を参照して具体例を挙げながら説明する。
【００４９】
まず、図３のステップＳ１３で取り出されたコンテナがルートコンテナであったところからの処理を説明する。図４のステップＳ２１では、コンテナリスト３２１からルートコンテナが取り出され（ステップＳ２１）、ＤＬＮＡサーバ２００に対してオブジェクト一覧の送信要求が送られる（ステップＳ２２）。ここではＢｒｏｗｓｅコマンドが使用され、コマンド内では、ルートコンテナのＩＤである０が指定されている。
【００５０】
ＤＬＮＡサーバ２００では、オブジェクト一覧送信の要求を受け付けると、図４にＯＬ１として示したようなＸＭＬの記述を、オブジェクト一覧として返信する（ステップＳ２３）。オブジェクト一覧ＯＬ１には、各コンテナのＩＤと名前が記されており、コンテナの名前は、“ｄｃ：ｔｉｔｌｅ”のプロパティ値として示されている。
【００５１】
そして、オブジェクト一覧を受信した収集サーバ３００では、ｄｃ：ｔｉｔｌｅのプロパティ値を、コンテナの名前としてコンテナリスト３２１に追加する処理を行う（ステップＳ２４）。オブジェクト一覧ＯＬ１を基に生成されたコンテナリストは、コンテナリストＣＬ１として示されたようなものとなる。つまり、ｄｃ：ｔｉｔｌｅのプロパティ値である「植物」や「動物」が、コンテナリストの「名前」として追加されるようになる。
【００５２】
そして次に、コンテナリストから「植物」のコンテナが１つ取り出され（ステップＳ２５）、取り出された「植物」のコンテナの直下にあるオブジェクトの一覧を取得したいという要求が、収集サーバ３００からＤＬＮＡサーバ２００に対して送信される（ステップＳ２６）。ステップＳ２５で「植物」のコンテナが取り出されたため、図４の左側に示されたコンテナリストＣＬ２には、ＩＤが２の「動物」のみが残されるようになる。
【００５３】
「植物」のコンテナＩＤは１であるため、ステップＳ２６でＤＬＮＡサーバ２００に対して送信されるＢｒｏｗｓｅコマンドにおいては、１が指定される。そして、１が指定されたＢｒｏｗｓｅコマンドを受け取ったＤＬＮＡサーバ２００は、ｃｏｎｔａｉｎｅｒ ｉｄが１である、「植物」という名のコンテナの直下にあるオブジェクトを抽出して図４にＯＬ２として示したようなオブジェクト一覧を生成し、生成したオブジェクト一覧を収集サーバ３００に対して送信する（ステップＳ２７）。オブジェクト一覧ＯＬ２には、“ｉｔｅｍ ｉｄ１０”の記載があるように、アイテムの情報が含まれているため、収集サーバ３００では、アイテムのｄｃ：ｔｉｔｌｅプロパティ値をアイテムのタイトルとしてコンテンツデータベースＣＤ１に書き込む。それと同時に、その親コンテナの名前、つまりステップＳ２５でコンテナリストから取り出された「名前」を、コンテンツデータベースＣＤ１に「カテゴリ」として書き込む処理を行う（ステップＳ２８）。
【００５４】
オブジェクト一覧ＯＬ２においては、アイテムの名前として“Ｗｉｎｔｅｒ Ｌｅａｖｅｓ．ｊｐｇ”や“Ｔｒｅｅ．ｊｐｇ”の記載があり、これらのアイテムを格納している親コンテナの名前は“植物”であるため、コンテンツデータベースＣＤ１においては、アイテム名がタイトルとして格納され、親コンテナの名前がカテゴリとして格納されるようになる。
【００５５】
次に、ＤＬＮＡクライアント１００からのコンテンツ検索要求に基づいて、収集サーバ３００がカテゴリ一覧を送信する処理の例について、図５のフローチャートを参照して説明する。まず、ＤＬＮＡクライアント１００で、表示部１０６（図１参照）に表示されたメニュー画面上で、コンテンツ検索のキーとして「カテゴリ」が選択されると（ステップＳ３０）、ＤＬＮＡクライアント１００から収集サーバ３００に対して、カテゴリ情報の取得要求が送信される（ステップＳ３１）。ここで送信されるのはＢｒｏｗｓｅコマンドであり、コマンド内では“ＣａｔｅｇｏｒｙＬｉｓｔ”が指定されている。
【００５６】
図６には、メニュー画面の例を示してある。図６に示した例では、コンテンツ検索のキーの種類として、上から「登録日から探す」、「カテゴリから探す」、「キーワードから探す」、「すべてのフォト」の項目が記されている。ユーザは、図６に示した画面上で、カーソルＣＳ１を上下に移動させることで、所望のキーを選択することができる。
【００５７】
収集サーバ３００は、ＤＬＮＡクライアント１００からのカテゴリ情報取得要求を受信すると、コンテンツＤＢ３２２からカテゴリを抽出し、抽出されたカテゴリに重複がある場合には、重複を削除する処理を行う（ステップＳ３２）。例えばカテゴリとして、「動物」、「植物」、「入学式」、「動物」を抽出した場合には、「動物」は１つのみを抽出するようにする。そして抽出した情報を基に、カテゴリ一覧を生成する処理を行う（ステップＳ３３）。
【００５８】
ステップＳ３３で生成されるカテゴリ一覧は、例えば図５にカテゴリ一覧ＣｔＬ１として示されたようなものとなる。コンテナのＩＤとして‘“ｋｉｎｄ＝Ｃ＆ｎａｍｅ＝“動物”’や‘“ｋｉｎｄ＝Ｃ＆ｎａｍｅ＝“植物”’が指定されており、ｄｃ：ｔｉｔｌｅプロパティの値として、“動物”や“植物”が指定されている。このようなカテゴリ一覧が、収集サーバ３００からＤＬＮＡクライアント１００に送信される（ステップＳ３４）。
【００５９】
ＤＬＮＡクライアント１００では、ステップＳ３４で収集サーバ３００から送られたメッセージを基に、カテゴリ一覧を表示する（ステップＳ３５）。そして、受信したカテゴリ一覧に含まれるｃｏｎｔａｉｎｅｒ ｉｄ値とｄｃ：ｔｉｔｌｅ値を、それぞれＩＤとカテゴリ名として記憶部１０７（図１参照）等に記憶させておく。
【００６０】
ステップＳ３５で表示されるカテゴリ一覧は、例えば図７に示したものになる。図７では、画面上の上から「風景」、「入学式」、「動物」、「植物」、「花」という項目が表示されているが、これらは、ステップＳ３５で収集サーバ３００から送信されたカテゴリ一覧に含まれている、ｄｃ：ｔｉｔｌｅプロパティ値を反映させたものである。
【００６１】
このような画面上で、ユーザからの操作に基づいて例えば「植物」が選択されると、ＤＬＮＡクライアント１００から収集サーバ３００に、特定されたカテゴリの情報が送信される（ステップＳ３６）。ここでもＢｒｏｗｓｅコマンドが使用され、コマンドの中でＩＤとして‘“ｋｉｎｄ＝ｃ＆ｎａｍｅ＝“植物”’が指定されている。このＩＤは、収集サーバ３００から送信されたカテゴリ一覧に含まれていたｃｏｎｔａｉｎｅｒ ｉｄをそのまま使用したものである。
【００６２】
収集サーバ３００は、ＤＬＮＡクライアント１００から送信された、カテゴリの特定情報を受信すると、特定された「植物」のカテゴリをキーに、コンテンツＤＢ３２２に対して検索を行う処理を行う（ステップＳ３７）。そして、特定された「植物」のカテゴリに属するオブジェクト群をコンテンツＤＢ３２２から取り出し（ステップＳ３８）、取り出したオブジェクト群を用いてオブジェクト一覧の生成を行う（ステップＳ３９）。そして、ＤＬＮＡクライアント１００に対してオブジェクト一覧を送信する処理を行う（ステップＳ４０）。
【００６３】
ステップＳ３７〜ステップＳ３９までの処理は、ＤＬＮＡクライアント１００から送信されたＢｒｏｗｓｅコマンドに含まれる‘“ｋｉｎｄ＝ｃ＆ｎａｍｅ＝“植物”’を解釈した結果、行われるものである。つまり、‘“ｋｉｎｄ＝ｃ＆ｎａｍｅ＝“植物”’が、収集サーバ３００に対するコマンドとしても機能していることになる。そのコマンドとは、カテゴリ「植物」でのコンテンツＤＢ３２２の検索と、抽出した結果を用いての一覧生成を命じるものである。
【００６４】
収集サーバ３００では、自分がＤＬＮＡクライアント１００送ったメッセージが、このような形で返信されることを見越した上で、コマンドの意味を含んだメッセージを予めｃｏｎｔａｉｎｅｒ ｉｄに含めて送信するようにしてある。
【００６５】
また、ステップＳ３８で生成されたオブジェクト一覧は、例えば図５にオブジェクト一覧ＯＬ３として示されたもののようになる。オブジェクト一覧ＯＬ３には、ｄｃ：ｔｉｔｌｅプロパティ値として“Ｗｉｎｔｅｒ Ｌｅａｖｅｓ．ｊｐｇ”や“Ｔｒｅｅ．ｊｐｇ”といった値が記されており、これらはアイテム、つまり実コンテンツの名前を意味している。そして、ＤＬＮＡクライアント１００の表示部１０６上に、図８に示したようなオブジェクト一覧が表示される（ステップＳ４１）。
【００６６】
図８に示したオブジェクト一覧では、画面の左側にコンテンツのサムネイルが表示されており、その右側に“Ｗｉｎｔｅｒ Ｌｅａｖｅｓ．ｊｐｇ”といったコンテンツの名前と、２００５／１／１７ 午前６：４３といった撮影時刻が示されている。図５に示したオブジェクト一覧ＯＬ３には、撮影時刻等の情報は図示されていないが、ステップＳ４０で収集サーバ３００からＤＬＮＡクライアント１００に送信されるメッセージの中には、撮影時刻情報や、コンテンツの保存場所情報であるＵＲＬ等の情報も含まれているものとする。そしてＤＬＮＡクライアント１００は、送られたオブジェクト一覧に記載された情報を用いて、コンテンツ情報の一覧を生成し表示する。
【００６７】
次に、図９のフローチャートを参照して、ＤＬＮＡクライアント１００が実際に実コンテンツを取得する場合の処理例について説明する。図８に示した画面上で、ユーザが“Ｔｒｅｅ．ｊｐｇ”を選択した場合を例に挙げると、まず、ＤＬＮＡクライアント１００からＤＬＮＡサーバ２００に対して、コンテンツ配信の要求が送信される（ステップＳ５１）。ここで送信されるコマンドはＧＥＴコマンドであり、コマンドの中に“Ｔｒｅｅ．ｊｐｇ”の保存されている場所を示すＵＲＬが指定されている。このＵＲＬは、図５のフローチャートのステップＳ４０で、収集サーバ３００から送信されたオブジェクト一覧に含まれていたものである。
【００６８】
ＤＬＮＡサーバ２００は、ＤＬＮＡクライアント１００から送られたコンテンツ配信要求を受信すると、リクエスト内で指定されたコンテンツを読み出し、ＤＬＮＡクライアント１００に対して送信する処理を行う（ステップＳ５２）。そして、ＤＬＮＡクライアント１００は、送られたコンテンツを表示部１０６に表示する処理を行う（ステップＳ５３）。
【００６９】
このように、収集サーバ３００において、ＤＬＮＡサーバ２００のコンテンツ管理情報を基に、アイテムとそのアイテムが格納されたコンテナの名前とを対応付け、アイテムのメタデータとして記憶するようにしたため、アイテムが格納されたコンテナの名前で、アイテムつまり実コンテナを検索できるようになる。
【００７０】
図１０には、ＤＬＮＡサーバ２００におけるＣＤＳの例と、収集サーバ３００でＤＬＮＡサーバ２００のコンテンツ管理情報を基に生成されたコンテンツＤＢ３２２の登録例を示してある。図１０においては、“運動会”として分類されたコンテナが、ＤＬＮＡサーバ２００ａ内にコンテナＣｎ１として、また、ＤＬＮＡサーバ２００ｂ内にコンテナＣｎ３として存在している様子が示されている。そして、コンテナＣｎ１には写真コンテンツであるアイテムＩｔ１０とアイテムＩｔ１１、コンテナＣｎ２には、写真コンテンツであるアイテムＩｔ１３とアイテム１４が格納されている。
【００７１】
本例ではこの場合、アイテムＩｔ１０、アイテムＩｔ１１、アイテムＩｔ１３、アイテムＩｔ１４の親コンテナ名である「運動会」を、アイテムのカテゴリとしてコンテンツＤＢ３２２に記録させる。これにより、ＤＬＮＡサーバ２００ａとＤＬＮＡサーバ２００ｂに分散して記録されているアイテムであっても、収集サーバ３００上では、同じ「運動会」のカテゴリに属するアイテムとして取り扱うことができるようになる。よって、ユーザは「運動会」というカテゴリを指定することで、このカテゴリに属するアイテムＩｔ１０、アイテムＩｔ１１、アイテムＩｔ１３、アイテムＩｔ１４を容易に探し当てることができるようになる。
【００７２】
コンテナの名前はユーザがコンテンツの分類のために作成したフォルダの名前であり、図１０に示した例において、コンテナＣ１の名前は「運動会」、コンテナＣｎ２の名前は「入学式」が、コンテナＣｎ４の名前は「誕生日」とされているように、コンテナの名前はユーザにとって意味のあるものである場合が多い。よって、このようにアイテムが格納された親コンテナの名前で、アイテム（コンテンツ）を検索できるようにすることで、ユーザによるコンテンツ検索の効率を向上させることができる。
【００７３】
また、アイテムと親コンテナの名前とを結びつけて、アイテムのメタデータとして登録するという簡単な手法を用いているため、将来的にＤＬＮＡサーバ２００が、コンテンツの分類ツリー構造を自動的に生成する仕組みができた場合であっても、仕様を変更することなく、容易に適用させることが可能となる。
【００７４】
なお、上述した実施の形態では、アイテムのメタデータとしてコンテンツＤＢ３２２に追加する情報を、アイテムを格納している親コンテナの名前とした場合の例を挙げて説明したが、親コンテナの名前だけでなく、その更に上の階層のコンテナの名前も同時にアイテムと結びつけて登録するようにしてもよい。
【００７５】
この場合のＤＬＮＡサーバ２００におけるＣＤＳの例と、収集サーバ３００でのコンテンツＤＢ３２２の登録例を、図１１に示してある。図１１に示した例では、“子供の写真”と名づけられたコンテナＣｎ１０を頂点に、その配下に“花子の記録”と名づけられたコンテナＣｎ７と、“太郎の記録”と名づけられたコンテナＣｎ１１とがぶら下がっている。そして、“花子の記録”という名のコンテナＣｎ７の直下には、“運動会”と名づけられたコンテナＣｎ３と、“誕生日”と名づけられたコンテナＣｎ４とが接続されている。“運動会”という名のコンテナＣｎ３には、写真コンテンツであるアイテムＩｔ１３とアイテムＩｔ１４とが格納されており、“誕生日”という名のコンテナＣｎ４には、写真コンテンツであるアイテムＩｔ１５が格納されている。
【００７６】
“太郎の記録”という名のコンテナＣｎ１１の下には、“入学式”と名づけられたコンテナＣｎ１２と、“運動会”と名づけられたコンテナＣｎ１３とが繋がっており、“入学式”という名のコンテナＣｎ１２には写真コンテンツであるアイテムＩｔ２０とアイテムＩｔ２１が格納されており、“運動会”という名のコンテナＣｎ１３には、写真コンテンツであるアイテムＩｔ２２が格納されている。
【００７７】
このような構成のコンテンツ管理情報からコンテンツＤＢを生成する場合に、図１１に示した例では、アイテムを格納しているコンテナ名だけでなく、その上層のコンテナの名前も一緒に登録するようにしてある。例えばアイテムＩｔ２０であれば、親コンテナＣｎ１２の名前である“入学式”のみならず、その親のコンテナＣｎ１１の名前である“太郎の記録”、そしてそのまた上のコンテナＣｎ１０の名前である“子供の写真”も、アイテムＩｔ２０に関連付けられて、アイテムＩｔ２０のメタデータとしてコンテンツＤＢ３２２に記憶される。
【００７８】
アイテムＩｔ１３においても同様に、親コンテナＣｎ３の名前である“運動会”だけでなく、その親コンテナＣｎ７の名前である“花子の記録”と、その１つ上のコンテナＣｎ１０の名前である“子供の写真”も、アイテムＩｔ１３のメタデータとして登録される。
【００７９】
このように、複数の階層のコンテナ名を取り扱うようにした場合は、アイテムとコンテナとの関係は、一対一ではなく、多対多の関係となる。よって、コンテンツＤＢ３２２では、アイテムのテーブルとカテゴリ（コンテナ名）テーブルとの関係を表す、リレーションテーブルを用いる必要がある。
【００８０】
図１２には、アイテムテーブルとカテゴリテーブル、そしてリレーションテーブルの構成例を示してある。アイテムテーブルＴ１では、項目として例えば、ＩＤ、ｄｃ：ｔｉｔｌｅ、ｒｅｓを有しており、“０１．ｊｐｇ”と“０２．ｊｐｇ”の情報を保持しているものとする。そして、カテゴリテーブルＴ２では、“太郎の記録”、“運動会”、“入学式”といったカテゴリが、ＩＤとともに記録されているものとする。
【００８１】
そして、アイテムＩＤ１の“０１．ｊｐｇ”と結び付けられているカテゴリは、カテゴリＩＤ１の“太郎の記録”とカテゴリＩＤ２の“運動会”であり、アイテムＩＤ２の“０２．ｊｐｇ”と結び付けられているカテゴリは、カテゴリＩＤ１の“太郎の記録”とカテゴリＩＤ３の“入学式”であるものとする。
【００８２】
この場合、リレーションテーブルＴ３として示したように、アイテムとカテゴリとを対応付ける間接テーブルを用いることで、アイテムとカテゴリとの多対多の関係を表現することが可能となる。
【００８３】
アイテムとカテゴリとの関係が多対多である場合の、コンテンツＤＢ生成処理例について、図１３にフローチャートとして示してある。ステップＳ６１からステップＳ６７までは、図３のフローチャートのステップＳ１１からステップＳ１７と同様であるため、説明を省略する。図１３のステップＳ６７で、オブジェクトがコンテナであると判定された場合には、親とその上の階層のコンテナ（祖先コンテナ）の名前とを結びつけて、コンテナリストにコンテナを追加する（ステップＳ６８）。オブジェクトがコンテナではなく、アイテムであると判定された場合には、アイテムの親コンテナの名前及びその祖先のコンテナの名前とをアイテムと結びつけて、アイテムのメタデータとしてコンテンツＤＢ３２２に格納する（ステップＳ６９）。
【００８４】
このような処理を行うことで、コンテンツの検索を行う際に、アイテム（コンテンツ）が格納されているコンテナの名前だけでなく、その上層のコンテナの名前も用いることができるようになる。
【００８５】
また、上述した実施の形態では、ＤＬＮＡクライアント１００でコンテンツの検索を行う場合に、アイテムの親コンテナの名前を一覧で表示させ、その中から所望のキーを選択する例を挙げたが、キーワードで検索する場合に適用させてもよい。この場合は、ユーザより入力されたキーワードをキーに、収集サーバ３００でコンテンツＤＢ３２２のカテゴリを抽出し、抽出したカテゴリに属するアイテムをＤＬＮＡクライアント１００に対して一覧で出力させるようにすればよい。
【００８６】
また、上述した実施の形態では、収集サーバ３００を、ＤＬＮＡクライアント１００やＤＬＮＡサーバ２００とは独立した機器上で稼動させる例を説明したが、ＤＬＮＡクライアント１００上に収集サーバ３００のモジュールを載せることで、ＤＬＮＡクライアントと収集サーバの機能を、１つの機器上で実現させた構成に適用することも可能である。
【００８７】
また、上述した実施の形態では、写真コンテンツを処理する場合を例に挙げて説明を行ったが、他のコンテンツにも適用可能である。メタデータの種類が少なく、検索の際のキーを多く持たないコンテンツの種類であれば、特に高い効果を得られる。
【００８８】
また、上述した実施形態例における一連の処理は、ハードウェアにより実行することができるが、ソフトウェアにより実行させることもできる。一連の処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムを、専用のハードウェアに組み込まれているコンピュータ、または、各種のプログラムをインストールすることで各種の機能を実行することが可能な例えば汎用のパーソナルコンピュータなどに所望のソフトウェアを構成するプログラムをインストールして実行させる。
【図面の簡単な説明】
【００８９】
【図１】本発明の一実施の形態によるシステムの構成例を示す構成図である。
【図２】本発明の一実施の形態による収集サーバによるコンテンツ情報取得判断処理の例を示すフローチャートである。
【図３】本発明の一実施の形態による収集サーバにおけるコンテンツデータベース生成処理の例を示すフローチャートである。
【図４】本発明の一実施の形態によるコンテンツデータベースの生成処理例を示すフローチャートである。
【図５】本発明の一実施の形態によるオブジェクト一覧生成送信処理の例を示すフローチャートである。
【図６】本発明の一実施の形態による検索画面の例を示す説明図である。
【図７】本発明の一実施の形態によるカテゴリ一覧の表示例を示す説明図である。
【図８】本発明の一実施の形態によるオブジェクト一覧の表示例を示す説明図である。
【図９】本発明の一実施の形態によるＤＬＮＡクライアントによるコンテンツの取得処理例を示すフローチャートである。
【図１０】本発明の一実施の形態によるカテゴリ分類の例を示す説明図である。
【図１１】本発明の他の実施の形態によるコンテンツデータベースの登録例を示す説明図である。
【図１２】本発明の他の実施の形態によるテーブル間のリレーションの例を示す説明図である。
【図１３】本発明の他の実施の形態によるコンテンツデータベース生成処理例を示すフローチャートである。
【図１４】従来のシステム構成例を示す構成図である。
【図１５】従来の収集サーバを用いたシステムの構成例を示す構成図である。
【図１６】従来の画面表示例を示す説明図である。
【図１７】従来のコンテンツ情報一覧の構成例を示す説明図である。
【図１８】従来のメタデータの構成例を示す説明図である。
【符号の説明】
【００９０】
１００…ＤＬＮＡクライアント、１０１…通信部、１０２…制御部、１０３…ＵＰｎＰコントロールポイントモジュール、１０４…ＨＴＴＰ処理モジュール、１０５…操作部、１０６…表示部、１０７…記憶部、２００…ＤＬＮＡサーバ、２０１…通信部、２０２…制御部、２０３…ＵＰｎＰデバイス処理モジュール、２０４…ＨＴＴＰ処理モジュール、２０５…操作部、２０６…表示部、２０７…記憶部、３００…収集サーバ、３０１…ＨＴＴＰ処理モジュール、３０２…ＵＰｎＰコントロールポイントモジュール、３０３…一覧探索モジュール、３０４…メタデータ格納処理モジュール、３０５…データベース検索モジュール、３０６…リクエスト解釈モジュール、３０７…一覧生成処理モジュール、３０８…ＵＰｎＰデバイス処理モジュール、３０９…ＨＴＴＰ処理モジュール、３１０…制御部、３２０…記憶部、３２１…コンテナリスト、３２２…コンテンツデータベース
【特許請求の範囲】
【請求項１】
メディアサーバからコンテンツを受信して再生できるクライアントと、前記メディアサーバから前記コンテンツに関連するコンテンツ管理情報を受信して管理する収集サーバとで構成される情報処理システムにおいて、
前記クライアントは、
前記コンテンツを検索するための検索条件を前記収集サーバに送信し、前記検索条件に対応するコンテンツ情報の一覧を受信する通信部を備え、
前記収集サーバは、
予め決められた条件に従って、前記コンテンツ管理情報を前記メディアサーバから取得する受信部と、
前記取得したコンテンツ管理情報に含まれるコンテンツの格納位置に関する情報を、前記コンテンツのカテゴリ情報として記憶してコンテンツ情報データベースを生成するコンテンツ情報データベース生成部と、
前記クライアントから送信された検索条件を受信した場合に、前記コンテンツ情報データベースから前記検索条件に一致するコンテンツ情報を、前記カテゴリ情報に基づいて抽出し、コンテンツ情報の一覧を生成するコンテンツ情報一覧生成部と、
前記コンテンツ情報一覧生成部で生成された前記コンテンツ情報の一覧を前記クライアントに送信する送信部とを備えたことを特徴とする
情報処理システム。
【請求項２】
請求項１記載の情報処理システムにおいて、
前記コンテンツ管理情報は、前記メディアサーバに格納された前記コンテンツのルート情報と、前記コンテンツを格納したフォルダの名前情報と、前記コンテンツの名前情報と、前記フォルダの階層構造情報を含むことを特徴とする
情報処理システム。
【請求項３】
請求項１記載の情報処理システムにおいて、
前記収集サーバは、前記カテゴリ情報に基づいてカテゴリ一覧を生成するカテゴリ一覧生成部を更に有し、
前記送信部は、前記カテゴリ一覧生成部で生成された前記カテゴリ一覧を前記クライアントに送信し、
前記クライアントから、前記検索条件としてカテゴリ一覧の中から特定のカテゴリを選択する選択信号を受信した場合には、前記収集サーバは、前記特定されたカテゴリに属するコンテンツ情報の一覧を送信することを特徴とする
情報処理システム。
【請求項４】
請求項３記載の情報処理システムにおいて、
前記コンテンツ情報は、前記コンテンツの名前情報と前記コンテンツの格納位置に関する情報であるカテゴリ情報を含むことを特徴とする
情報処理システム。
【請求項５】
請求項４記載の情報処理システムにおいて、
前記クライアントで、前記コンテンツ情報の一覧の中から特定のコンテンツを選択する操作があった場合には、前記メディアサーバから、前記特定されたコンテンツが送信されることを特徴とする
情報処理システム。
【請求項６】
請求項１記載の情報処理システムにおいて、
前記収集サーバは、前記メディアサーバ内において蓄積されたコンテンツの内容に変更があった場合に変更されるフラグを、所定の間隔で取得し、前記取得したフラグの値から前記コンテンツの内容に変更があったことが読み取れた場合にのみ、前記メディアサーバから前記コンテンツ管理情報を取得する処理を行うことを特徴とする
情報処理システム。
【請求項７】
請求項１記載の情報処理システムにおいて、
前記収集サーバは、前記メディアサーバ内に格納された前記コンテンツ管理情報を、前記コンテンツ管理情報が有するフォルダ階層構造の最上層から順に、下の階層の方向に向かって１つずつ取得するコンテンツ情報探索部を備えたことを特徴とする
情報処理システム。
【請求項８】
請求項７記載の情報処理システムにおいて、
前記収集サーバは、前記コンテンツ情報探索部が取得したコンテンツ管理情報にフォルダの名が含まれていた場合に、前記フォルダ名を記憶するフォルダ名記憶部を備えたことを特徴とする、
情報処理システム。
【請求項９】
請求項８記載の情報処理システムにおいて、
前記コンテンツ情報探索部は、前記フォルダ名記憶部に記憶された前記フォルダ名を１つずつ取り出して、前記取り出したフォルダ名を有するフォルダの配下に格納されたコンテンツ管理情報の取得要求を、前記通信部に出力することを特徴とする
情報処理システム。
【請求項１０】
請求項９記載の情報処理システムにおいて、
前記収集サーバのコンテンツ情報データベース生成部は、前記取得したコンテンツ管理情報にコンテンツの名前情報が含まれていた場合にのみ、前記コンテンツ情報探索部が前記フォルダ名記憶部から取り出したフォルダの名前を、前記コンテンツの属性情報として記憶することを特徴とする
情報処理システム。
【請求項１１】
メディアサーバからコンテンツを受信して再生できるクライアントと、前記メディアサーバから前記コンテンツに関連するコンテンツ管理情報を受信して管理する収集サーバとで構成される情報処理システムにおける、収集サーバにおいて、
予め決められた条件に従って、前記コンテンツ管理情報を前記メディアサーバから取得する受信部と、
前記取得したコンテンツ管理情報に含まれるコンテンツの格納位置に関する情報を、前記コンテンツのカテゴリ情報として記憶してコンテンツ情報データベースを生成するコンテンツ情報データベース生成部と、
前記クライアントから送信された検索条件を受信した場合に、前記コンテンツ情報データベースから前記検索条件に一致する前記コンテンツ情報を、前記カテゴリ情報に基づいて抽出し、コンテンツ情報の一覧を生成するコンテンツ情報一覧生成部と、
前記コンテンツ情報一覧生成部で生成された前記コンテンツ情報の一覧を前記クライアントに送信する送信部とを備えたことを特徴とする
収集サーバ。
【請求項１２】
メディアサーバからコンテンツを受信して再生できるクライアントと、前記メディアサーバから前記コンテンツに関連するコンテンツ管理情報を受信して管理する収集サーバとで構成される情報処理システムにおける、収集サーバの情報処理方法において、
予め決められた条件に従って、前記コンテンツ管理情報を前記メディアサーバから取得する手順と、
前記取得したコンテンツ管理情報に含まれるコンテンツの格納位置に関する情報を、前記コンテンツのカテゴリ情報として記憶する手順と、
前記クライアントから前記コンテンツの検索条件を受信した場合に、前記検索条件に一致する前記コンテンツ情報を、前記カテゴリ情報に基づいて抽出して、コンテンツ情報の一覧を生成する手順と、
前記生成された前記コンテンツ情報の一覧を前記クライアントに送信する手順とを備えたことを特徴とする
情報処理方法。
【請求項１３】
メディアサーバからコンテンツを受信して再生できるクライアントと、前記メディアサーバから前記コンテンツに関連するコンテンツ管理情報を受信して管理する収集サーバとで構成される情報処理システムにおける、収集サーバの情報処理をコンピュータに実装して実行させるプログラムにおいて
予め決められた条件に従って、前記コンテンツ管理情報を前記メディアサーバから取得する手順と、
前記取得したコンテンツ管理情報に含まれるコンテンツの格納位置に関する情報を、前記コンテンツのカテゴリ情報として記憶する手順と、
前記クライアントから前記コンテンツの検索条件を受信した場合に、前記検索条件に一致する前記コンテンツ情報を、前記カテゴリ情報に基づいて抽出して、コンテンツ情報の一覧を生成する手順と、
前記生成された前記コンテンツ情報の一覧を前記クライアントに送信する手順とを備えたことを特徴とする
プログラム。
【請求項１】
メディアサーバからコンテンツを受信して再生できるクライアントと、前記メディアサーバから前記コンテンツに関連するコンテンツ管理情報を受信して管理する収集サーバとで構成される情報処理システムにおいて、
前記クライアントは、
前記コンテンツを検索するための検索条件を前記収集サーバに送信し、前記検索条件に対応するコンテンツ情報の一覧を受信する通信部を備え、
前記収集サーバは、
予め決められた条件に従って、前記コンテンツ管理情報を前記メディアサーバから取得する受信部と、
前記取得したコンテンツ管理情報に含まれるコンテンツの格納位置に関する情報を、前記コンテンツのカテゴリ情報として記憶してコンテンツ情報データベースを生成するコンテンツ情報データベース生成部と、
前記クライアントから送信された検索条件を受信した場合に、前記コンテンツ情報データベースから前記検索条件に一致するコンテンツ情報を、前記カテゴリ情報に基づいて抽出し、コンテンツ情報の一覧を生成するコンテンツ情報一覧生成部と、
前記コンテンツ情報一覧生成部で生成された前記コンテンツ情報の一覧を前記クライアントに送信する送信部とを備えたことを特徴とする
情報処理システム。
【請求項２】
請求項１記載の情報処理システムにおいて、
前記コンテンツ管理情報は、前記メディアサーバに格納された前記コンテンツのルート情報と、前記コンテンツを格納したフォルダの名前情報と、前記コンテンツの名前情報と、前記フォルダの階層構造情報を含むことを特徴とする
情報処理システム。
【請求項３】
請求項１記載の情報処理システムにおいて、
前記収集サーバは、前記カテゴリ情報に基づいてカテゴリ一覧を生成するカテゴリ一覧生成部を更に有し、
前記送信部は、前記カテゴリ一覧生成部で生成された前記カテゴリ一覧を前記クライアントに送信し、
前記クライアントから、前記検索条件としてカテゴリ一覧の中から特定のカテゴリを選択する選択信号を受信した場合には、前記収集サーバは、前記特定されたカテゴリに属するコンテンツ情報の一覧を送信することを特徴とする
情報処理システム。
【請求項４】
請求項３記載の情報処理システムにおいて、
前記コンテンツ情報は、前記コンテンツの名前情報と前記コンテンツの格納位置に関する情報であるカテゴリ情報を含むことを特徴とする
情報処理システム。
【請求項５】
請求項４記載の情報処理システムにおいて、
前記クライアントで、前記コンテンツ情報の一覧の中から特定のコンテンツを選択する操作があった場合には、前記メディアサーバから、前記特定されたコンテンツが送信されることを特徴とする
情報処理システム。
【請求項６】
請求項１記載の情報処理システムにおいて、
前記収集サーバは、前記メディアサーバ内において蓄積されたコンテンツの内容に変更があった場合に変更されるフラグを、所定の間隔で取得し、前記取得したフラグの値から前記コンテンツの内容に変更があったことが読み取れた場合にのみ、前記メディアサーバから前記コンテンツ管理情報を取得する処理を行うことを特徴とする
情報処理システム。
【請求項７】
請求項１記載の情報処理システムにおいて、
前記収集サーバは、前記メディアサーバ内に格納された前記コンテンツ管理情報を、前記コンテンツ管理情報が有するフォルダ階層構造の最上層から順に、下の階層の方向に向かって１つずつ取得するコンテンツ情報探索部を備えたことを特徴とする
情報処理システム。
【請求項８】
請求項７記載の情報処理システムにおいて、
前記収集サーバは、前記コンテンツ情報探索部が取得したコンテンツ管理情報にフォルダの名が含まれていた場合に、前記フォルダ名を記憶するフォルダ名記憶部を備えたことを特徴とする、
情報処理システム。
【請求項９】
請求項８記載の情報処理システムにおいて、
前記コンテンツ情報探索部は、前記フォルダ名記憶部に記憶された前記フォルダ名を１つずつ取り出して、前記取り出したフォルダ名を有するフォルダの配下に格納されたコンテンツ管理情報の取得要求を、前記通信部に出力することを特徴とする
情報処理システム。
【請求項１０】
請求項９記載の情報処理システムにおいて、
前記収集サーバのコンテンツ情報データベース生成部は、前記取得したコンテンツ管理情報にコンテンツの名前情報が含まれていた場合にのみ、前記コンテンツ情報探索部が前記フォルダ名記憶部から取り出したフォルダの名前を、前記コンテンツの属性情報として記憶することを特徴とする
情報処理システム。
【請求項１１】
メディアサーバからコンテンツを受信して再生できるクライアントと、前記メディアサーバから前記コンテンツに関連するコンテンツ管理情報を受信して管理する収集サーバとで構成される情報処理システムにおける、収集サーバにおいて、
予め決められた条件に従って、前記コンテンツ管理情報を前記メディアサーバから取得する受信部と、
前記取得したコンテンツ管理情報に含まれるコンテンツの格納位置に関する情報を、前記コンテンツのカテゴリ情報として記憶してコンテンツ情報データベースを生成するコンテンツ情報データベース生成部と、
前記クライアントから送信された検索条件を受信した場合に、前記コンテンツ情報データベースから前記検索条件に一致する前記コンテンツ情報を、前記カテゴリ情報に基づいて抽出し、コンテンツ情報の一覧を生成するコンテンツ情報一覧生成部と、
前記コンテンツ情報一覧生成部で生成された前記コンテンツ情報の一覧を前記クライアントに送信する送信部とを備えたことを特徴とする
収集サーバ。
【請求項１２】
メディアサーバからコンテンツを受信して再生できるクライアントと、前記メディアサーバから前記コンテンツに関連するコンテンツ管理情報を受信して管理する収集サーバとで構成される情報処理システムにおける、収集サーバの情報処理方法において、
予め決められた条件に従って、前記コンテンツ管理情報を前記メディアサーバから取得する手順と、
前記取得したコンテンツ管理情報に含まれるコンテンツの格納位置に関する情報を、前記コンテンツのカテゴリ情報として記憶する手順と、
前記クライアントから前記コンテンツの検索条件を受信した場合に、前記検索条件に一致する前記コンテンツ情報を、前記カテゴリ情報に基づいて抽出して、コンテンツ情報の一覧を生成する手順と、
前記生成された前記コンテンツ情報の一覧を前記クライアントに送信する手順とを備えたことを特徴とする
情報処理方法。
【請求項１３】
メディアサーバからコンテンツを受信して再生できるクライアントと、前記メディアサーバから前記コンテンツに関連するコンテンツ管理情報を受信して管理する収集サーバとで構成される情報処理システムにおける、収集サーバの情報処理をコンピュータに実装して実行させるプログラムにおいて
予め決められた条件に従って、前記コンテンツ管理情報を前記メディアサーバから取得する手順と、
前記取得したコンテンツ管理情報に含まれるコンテンツの格納位置に関する情報を、前記コンテンツのカテゴリ情報として記憶する手順と、
前記クライアントから前記コンテンツの検索条件を受信した場合に、前記検索条件に一致する前記コンテンツ情報を、前記カテゴリ情報に基づいて抽出して、コンテンツ情報の一覧を生成する手順と、
前記生成された前記コンテンツ情報の一覧を前記クライアントに送信する手順とを備えたことを特徴とする
プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【公開番号】特開２００８−２９９８１７（Ｐ２００８−２９９８１７Ａ）
【公開日】平成２０年１２月１１日（２００８．１２．１１）
【国際特許分類】
【出願番号】特願２００７−１４８６４３（Ｐ２００７−１４８６４３）
【出願日】平成１９年６月４日（２００７．６．４）
【出願人】（０００００２１８５）ソニー株式会社 (34,172)
【Ｆターム（参考）】
【公開日】平成２０年１２月１１日（２００８．１２．１１）
【国際特許分類】
【出願日】平成１９年６月４日（２００７．６．４）
【出願人】（０００００２１８５）ソニー株式会社 (34,172)
【Ｆターム（参考）】
[ Back to top ]