JP2009140257A - 通信装置 - Google Patents

Abstract

【課題】 受信側の装置が使用するリソースを考慮したコンテンツデータのリストをネットワーク上に公開することのできる通信装置を提供する。
【解決手段】 記憶媒体が記憶する１以上のコンテンツデータを、１以上の階層を持つ第１の階層構造で管理する管理手段と、ネットワーク上の他の装置の処理能力を取得する処理能力取得手段と、管理手段が管理する記憶媒体内の第１の階層構造を維持しつつ、処理能力取得手段で取得した他の装置の処理能力に応じてコンテンツデータを第２の階層構造に分類する分類手段と、分類手段が分類した第２の階層構造に従って、コンテンツデータのリストを他の装置に公開するリスト公開手段と、リスト公開手段がリストとして公開したコンテンツデータを、他の装置からの要求に応じて記憶媒体から読み込む読込手段と、読込手段が読み込んだコンテンツデータを他の装置に送信する送信手段とを備えることを特徴とする。
【選択図】 図２

Description

本発明は、ネットワークを介して他の装置と通信する通信装置に関する。

近年、録画された番組（動画像データ）や撮影した写真（静止画像データ）、録音した音楽（音声データ）等を、家庭内ネットワークに接続された他の機器に配信することができるようになってきている。このための技術の１つとして、ＩＰネットワークの機器制御のプロトコルであるＵＰｎＰ（Ｕｎｉｖｅｒｓａｌ Ｐｌｕｇ ａｎｄ Ｐｌａｙ）があり、特にＡＶ機器向けの仕様として、ＵＰｎＰ ＡＶ Ａｒｃｈｉｔｅｃｔｕｒｅという仕様がＵＰｎＰ Ｆｏｒｕｍで定義されている。業界標準団体であるＤＬＮＡ（Ｄｉｇｉｔａｌ Ｌｉｖｉｎｇ Ｎｅｔｗｏｒｋ Ａｌｌｉａｎｃｅ）で規定された標準規格も、このＵＰｎＰをベースにしており、ＤＬＮＡ規格に則った製品も普及しつつある。

ＵＰｎＰ ＡＶ Ａｒｃｈｉｔｅｃｔｕｒｅでは、被制御機能を実装するサーバとしてＵＰｎＰ Ｍｅｄｉａ Ｓｅｒｖｅｒ Ｄｅｖｉｃｅ（以下メディアサーバとも称する）が、メディアサーバが提供／送信するコンテンツデータを再生するデバイスとしてＵＰｎＰ Ｍｅｄｉａ Ｒｅｎｄｅｒｅｒ（以下メディアレンダラとも称する）が、メディアサーバを制御する制御機能を実装するクライアントとしてＭｅｄｉａ Ｓｅｒｖｅｒ Ｃｏｎｔｒｏｌ Ｐｏｉｎｔ（以下コントロールポイントとも称する）が、其々定義されている。

特に、メディアサーバが提供可能なコンテンツデータ（音声データや静止画像データ、動画像データ等であるＡＶ（ａｕｄｉｏ／ｖｉｄｅｏ）データ）のリストを公開する要素技術としてＵＰｎＰ ＣＤＳ（Ｃｏｎｔｅｎｔ Ｄｉｒｅｃｔｏｒｙ Ｓｅｒｖｉｃｅ、例えば非特許文献１参照）が定義されている。ＣＤＳは、メディアサーバが提供可能なコンテンツデータのリストであるコンテンツリストを提供するサービスであり、ＵＰｎＰ ＣＤＳの規格では、コンテンツリストのフォーマットや、コントロールポイントがコンテンツリストを取得する方法等を取り決めている。

ＣＤＳでは、コンテンツデータを取得するためのＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｎｄｉｃａｔｏｒ）やコンテンツのタイトル、録画時間等といったコンテンツデータのメタデータを示す情報等を、階層構造を持つＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）形式で公開する。このとき、ＣＤＳが公開する階層構造は、記憶媒体内に記憶されるコンテンツデータのディレクトリ構造（階層構造）と同様の階層構造とするのが通常である。
Ａｌａｎ Ｐｒｅｓｓｅｒ、外１６名、"ＣｏｎｔｅｎｔＤｉｒｅｃｔｏｒｙ：２ Ｓｅｒｖｉｃｅ Ｔｅｍｐｌａｔｅ Ｖｅｒｓｉｏｎ １．０１"、［ｏｎｌｉｎｅ］、２００６年３月３１日、ＵＰｎＰ Ｆｏｒｕｍ、［平成１９年７月２４日検索］、インターネット（ＵＲＬ：http://www.upnp.org/specs/av/UPnP-av-ContentDirectory-v2-Service-20060531.pdf）

しかしながら、例えばデジタルカメラ等において、ユーザが一時に大量の写真を撮影したとすると、１つのディレクトリに多数の写真コンテンツデータが保存される。このとき、ディレクトリ構造と同じ階層構造で公開する装置では、該ディレクトリに対応するグループ（コンテナ：Ｃｏｎｔａｉｎｅｒと呼ぶ）に多数のコンテンツデータの情報が並べて公開されることとなる。このため、該ＣＤＳからコンテンツデータのコンテンツリストを取得するコントロールポイントを実装する装置側において、該リストを取得／処理するのに多大な時間を要すると共に、多大なメモリの一時記憶容量を確保する必要が生じる。

そこで本発明は、受信側の装置が使用するリソースを考慮したコンテンツデータのリストをネットワーク上に公開することのできる通信装置を提供することを目的とする。

上記目的を達成するために、本発明の通信装置は、記憶媒体が記憶する１以上のコンテンツデータを、１以上の階層を持つ第１の階層構造で管理する管理手段と、ネットワーク上の他の装置の処理能力を取得する処理能力取得手段と、前記管理手段が管理する前記記憶媒体内の前記第１の階層構造を維持しつつ、前記処理能力取得手段で取得した前記他の装置の処理能力に応じてコンテンツデータを第２の階層構造に分類する分類手段と、前記分類手段が分類した前記第２の階層構造に従って、コンテンツデータのリストを前記他の装置に公開するリスト公開手段と、前記リスト公開手段が前記リストとして公開したコンテンツデータを、前記他の装置からの要求に応じて前記記憶媒体から読み込む読込手段と、前記読込手段が読み込んだコンテンツデータを前記他の装置に送信する送信手段とを備えることを特徴とする。

本発明によれば、受信側の装置が使用するリソースを考慮したコンテンツデータのリストをネットワーク上に公開することのできる通信装置を提供することができる。

以下、本発明の通信装置について、図面を参照しながら説明する。
図１は、本発明の通信装置の実施例である記録装置が使用される通信システムの構成を示す図である。通信システム１は、静止画像データや動画像データ等のコンテンツデータをネットワーク越しに公開する記録装置１０（通信装置）と、該コンテンツデータを受信し、再生する再生装置２０及び３０とから構成される。尚、記録装置１０と再生装置２０及び３０とは、其々ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）／ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）により通信が行われるネットワーク４０により接続される。

ここで、本実施例の記録装置１０は、例えば撮像して静止画像データ及び動画像データを生成するデジタルカメラである。また、記録装置１０は、撮像した静止画像データや動画像データ等のコンテンツデータ、及び該コンテンツデータに関する情報のリスト（各コンテンツデータに関する情報を項目として有するリスト。以下、コンテンツリストとも称する）をネットワーク４０越しに公開する機能も有する。

再生装置２０及び３０は、例えば携帯型の映像再生装置や、デジタルテレビやＨＤＤプレーヤ等である。再生装置２０及び３０は、記録装置１０からコンテンツデータを受信し、再生して得られる映像信号の映像を、自身の持つ表示部や音声出力部、或いは外部の表示装置や音声出力装置に出力する機能を有する。また、記録装置１０が提供可能なコンテンツデータのリストを記録装置１０から取得する機能も有する。

記録装置１０と、再生装置２０及び３０とを接続するネットワーク４０は、例えばＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）等である。尚、本実施例では３つの装置でネットワーク４０を構成しているが、これに限られるものではなく、記録装置１０と再生装置２０のみからなる構成や、４以上の装置がネットワーク４０に接続されている構成であっても良い。以下、主に記録装置１０と再生装置２０との間について説明する。

ここで、記録装置１０及び再生装置２０は、其々ＵＰｎＰに対応したＡＶ（Ａｕｄｉｏ／Ｖｉｓｕａｌ）機器である。ＵＰｎＰでは、ＡＶ機器向けにＵＰｎＰ ＡＶ Ａｒｃｈｉｔｅｃｔｕｒｅという仕様が規定されている。このＵＰｎＰ ＡＶ Ａｒｃｈｉｔｅｃｔｕｒｅではネットワークの基本構成として、デバイス（Ｄｅｖｉｃｅ）、サービス（Ｓｅｒｖｉｃｅ）、コントロールポイント（Ｃｏｎｔｒｏｌ Ｐｏｉｎｔ）が定義されている。デバイスはＵＰｎＰ ＡＶに対応した装置であり、サービスはデバイスが提供する機能を表す最小単位である。各デバイスは、少なくとも１つのサービスを有する被制御装置である。コントロールポイントは、デバイスが有するサービスを制御し、利用するものである。１つの機器の中に複数のデバイス機能を持たせることもでき、更にコントロールポイントとデバイスとが一体となった装置も考えることができる。

ＵＰｎＰ ＡＶ Ａｒｃｈｉｔｅｃｔｕｒｅでは、被制御機能を実装し、コンテンツデータを提供するサーバデバイスとしてＵＰｎＰ Ｍｅｄｉａ Ｓｅｒｖｉｃｅ（メディアサーバ）が定義されているが、本通信システム１では、記録装置１０がメディアサーバとして機能する。メディアサーバである本実施例の記録装置１０は、コンテンツリストの公開を行うサービスであるＣＤＳ（Ｃｏｎｔｅｎｔ Ｄｉｒｅｃｔｏｒｙ Ｓｅｒｖｉｃｅ）を提供する。尚、ＣＤＳはＵＰｎＰ ＡＶで定義されている。

また、ＵＰｎＰ ＡＶ Ａｒｃｈｉｔｅｃｔｕｒｅでは、メディアサーバが送信するコンテンツデータを再生するデバイスとして、ＵＰｎＰ Ｍｅｄｉａ Ｒｅｎｄｅｒｅｒ（メディアレンダラ）が定義されているが、本通信システム１では再生装置２０がメディアレンダラとして機能する。

更に、ＵＰｎＰ ＡＶ Ａｒｃｈｉｔｅｃｔｕｒｅでは、メディアサーバが提供するサービスを制御、利用するコントロールポイントが定義されているが、本通信システム１では、再生装置２０がコントロールポイントとして機能する。つまり、再生装置２０はコントロールポイント及びメディアレンダラの２つの機能を実現している。

ここで、ユーザがコントロールポイントである再生装置２０を使用してＣＤＳを提供する記録装置１０のコンテンツリストを取得する場合や、メディアレンダラである再生装置２０を使用してメディアサーバである記録装置１０からコンテンツデータを取得して再生する場合の一般的な流れについて図２を参照しながら簡単に説明する。

次に、図２を参照しながら記録装置１０の構成を説明する。図２は、記録装置１０の構成を示す図である。
記録装置１０は、制御装置１０１と、撮像部１０２と、コンテンツ記録部１０３と、記憶媒体１０４と、コンテンツ管理部１０５と、仮想分類部１０６と、コンテンツ公開部１０７と、ＲＡＭ１０８と、通信部１０９と、処理能力取得部１１０と、コンテンツ転送部１１１と、コンテンツ取得部１１２とから構成される。

制御部１０１は、記録装置１０を構成する各構成要素を統括制御する。特に、例えば通信部１０９で受信した再生装置２０からの要求（アクション）に応じてコンテンツリストの作成及び送信やコンテンツデータの伝送を行う際に、処理能力部１１０を制御して再生装置２０の処理能力を取得し、また、該処理能力に応じてコンテンツ管理部１０５、コンテンツ転送部１１１等の各構成要素に対する制御を行う。

撮像部１０２は、被写体像の光を、入射光量に応じた電気的な画素信号に変換し、この電気的な画素信号を、デジタル信号に変換して所定の符号化方式（ＪＰＥＧ、ＢＭＰ、ＭＰＥＧ−２等）の画像データを作成する。この画像データは静止画像データであっても動画像データであっても構わないが、本実施例では、主に静止画像データであるものとする。

コンテンツ記録部１０３は、撮像部１０２が被写体の撮像により作成した画像データを、記憶媒体１０４に記録する。
記憶媒体１０４には、撮像部１０２で撮像して作成された複数の画像データ等の、複数のコンテンツデータが記憶される。該コンテンツデータは、撮像部１０２で撮像された静止画像データ、動画像データ等の他、音声データ等も含まれる。尚、記憶媒体１０４は、例えばＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）やメモリカード等であり、内蔵型の記憶媒体であっても、取り外し可能な可搬性の記憶媒体であってもよい。

コンテンツ管理部１０５は、記憶媒体１０４内に記憶される各コンテンツデータの管理を行う。特に、各コンテンツデータのファイル名、記録時刻、記録時間、その他ジャンル情報等のメタデータの管理も行い、必要に応じて仮想分類部１０６に渡す。このとき、記憶媒体１０４内の各コンテンツデータはディレクトリ（フォルダと称呼することもある）と呼ばれる階層構造を持つグループで管理される。この階層構造では、各ディレクトリは、０以上のファイル（つまりコンテンツデータ）及びディレクトリを子供として持つグループとなる。本実施例のコンテンツ管理部１０５が管理するディレクトリ構造については、図４を参照しながら後述する。

仮想分類部１０６は、コンテンツ管理部１０５が管理するディレクトリ構造を元に、コンテンツリストの階層構造を作成する。ＣＤＳとして機能するコンテンツ公開部１０７は、仮想分類部１０６が分類した階層構造に従って、このコンテンツリストを公開することとなる。

ＣＤＳでは、コンテンツリストをコンテナ（ｃｏｎｔａｉｎｅｒ）とアイテム（ｉｔｅｍ）とによってコンテンツデータの情報を管理する。１つのアイテムは１つのコンテンツデータに対応し、ＸＭＬ要素として定義される。一方コンテナは、アイテム及びコンテナを子供として持つことのできるＸＭＬ要素として定義されている。即ち、一般的なファイルシステム（ディレクトリ構造）に喩えれば、コンテナはディレクトリに相当し、アイテムはファイルに相当する。

本実施例の仮想分類部１０６は、後述する処理能力取得部１１０が取得した再生装置２０の処理能力に応じて、１つのコンテナ内の子供（コンテナ及びアイテム）の数が一定数以下となるように分類を行って、コンテンツリストの階層構造（コンテナ構造）を作成する。特に、１つのコンテナのコンテンツ数が多数になる場合（再生装置２０の処理能力に比べ過大だと判断される場合）には、これを複数のコンテナに分割する。尚、分割する方法としては、１つのコンテナが所定数以下のなるようにしても良いし、記録時間の範囲の指定や、ジャンル情報を利用可能であれば、これらの情報を用いてコンテンツ数を絞り込むようにしても良い。本実施例では、撮影日時情報で絞り込んだ後、再生装置２０の処理能力に応じた所定数以下となるように分類を行うものとする。

尚、１つのディレクトリとして格納されるコンテンツデータを仮想分類部１０６が複数のコンテナに分類した場合であっても、コンテンツ管理部１０５が管理する記憶媒体１０４内の階層構造は維持される。つまり、コンテンツデータのディレクトリ構造は、コンテンツリストの階層構造から独立して管理される。仮想分類部１０６が作成するコンテナ構造の詳細については、図５を参照しながら後述する。

コンテンツ公開部１０７は、ＣＤＳとしてコンテンツリストを公開する機能を有し、再生装置２０からＢｒｏｗｓｅアクション（後述する図３（ａ）のＳ２０１）等の要求に応じて、階層構造でコンテンツリストを送信する（後述する図３（ａ）のＳ２０９）。尚、コンテンツ公開部１０７が公開するコンテンツリストの詳細については、図６を参照しながら後述する。

ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１０８は、読込み及び書込みが可能な、一時的にデータを保存するための揮発性の記憶媒体である。特にＲＡＭ１０８は、コンテンツ公開部１０７がコンテンツリストを公開する際に、該コンテンツリストを一時的に記憶する機能を持つ。

通信部１０９は、ネットワーク４０でＴＣＰ／ＩＰにより通信するための通信インタフェースであり、再生装置２０から送信される、コンテンツリストの閲覧を要求するＢｒｏｗｓｅアクション（後述する図３（ａ）のＳ２０１）や、コンテンツデータの取得要求（後述する図３（ｂ）のＳ２２１）は、通信部１０９で受信する。また同様に、コンテンツリストを含むＢｒｏｗｓｅ Ｒｅｓｐｏｎｓｅ（後述する図３（ａ）のＳ２０９）や、送信するコンテンツデータ（後述する図３（ｂ）のＳ２２３）は、通信部１０９から再生装置２０へ送信される。更に、処理能力取得部１１０が再生装置２０へ送信する処理能力取得要求（後述する図３（ａ）Ｓ２０３）やそれに対するレスポンスである処理能力（後述する図３（ａ）のＳ２０５）も、通信部１０９で送受信される。

処理能力取得部１１０は、コントロールポイントとして機能する再生装置２０がコンテンツリストを処理／表示する際に必要とする処理能力を取得する機能を有する。より具体的には、再生装置２０に対して、処理能力取得要求（後述する図３（ａ）Ｓ２０３）を送信し、その応答として、メモリ容量やＣＰＵ速度、負荷等の情報を取得する。或いは、メモリ容量等のハードウェア能力ではなく、再生装置２０が一度に処理可能なコンテンツリストの項目数（アイテム／コンテンナ数）を取得するようにしても良い。ここで取得した再生装置２０の処理能力は制御部１０１に伝え、仮想分類部１０６はこの処理能力に応じて、コンテナの分割処理等を行う。

コンテンツ転送部１１１は、通信部１０９で受信したコンテンツデータの取得要求（後述する図３（ｂ）のＳ２２３）に応じて、要求されたコンテンツデータを伝送する処理を行う。このとき伝送するコンテンツデータは、コンテンツ取得部１１２が記憶媒体１０４から読み込む。

続いて、本実施例の記録装置１０による処理の流れについて、図３を参照しながら説明する。図２（ａ）は、再生装置２０がＣＤＳを提供するメディアサーバである記録装置１０からコンテンツリストを取得する際の処理の流れを示す図である。

まず、コントロールポイントである再生装置２０はＣＤＳを提供する記録装置１０に対し、コンテンツリストの取得を要求するＢｒｏｗｓｅアクション（閲覧要求）を送信する（Ｓ２０１）。

これに対し、記録装置１０は、まず処理能力取得部１１０で再生装置２０の処理能力を取得する（Ｓ２０３）。より具体的には、処理能力取得部１１０は処理能力取得要求を通信部１０９から再生装置２０に対して送信し（Ｓ２０３）、その応答として、再生装置２０の処理能力を通信部１０９で受信する（Ｓ２０５）。先述の通り、このとき取得する処理能力は、再生装置２０のハードウェア等の能力でも良いし、実際に処理可能なコンテンツリストの項目数の値であっても良い。

記録装置１０は、ここで取得した再生装置２０の処理能力に応じて、１つのコンテナ内の項目数が一定数以内となるように、仮想分類部１０６を制御する（Ｓ２０７）。より具体的には、仮想分類部１０６は、記憶媒体１０４に格納されているコンテンツデータの情報（ファイル名、記録時刻、記録時間、ジャンル情報などのメタデータ）などの必要な情報をコンテンツ管理部１０５から取得し、１つのコンテナの子供の項目数（アイテム／コンテナに対応）が再生装置２０の処理可能項目数以内となるように、複数のコンテナに分割する。

その後、Ｓ２０１で再生装置２０から受信したＢｒｏｗｓｅアクションへの応答として、コンテンツリストをＳ２０７で分類したコンテナ構造に従ってＢｒｏｗｓｅ Ｒｅｓｐｏｎｓｅとして送信する（Ｓ２０９）。これにより再生装置２０は、記録装置１０が提供可能なコンテンツデータの情報（例えば、タイトル、クラス、ＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｃｅ Ｉｄｅｎｔｉｆｉｅｒ）を取得することができる。

ここで、ＣＤＳは階層構造でコンテンツリストを提供し、通常、一度の応答の中では、１つの階層内に含まれる子階層（ディレクトリに相当、コンテナ）やコンテンツデータの情報（アイテム）のみを記録装置１０は送信する。本実施例では、１つのグループ（コンテナ）内に含まれる項目（アイテム）の数を、再生装置２０の処理能力により定められた一定数に押さえるようにしており、これにより、再生装置２０がコンテンツリストの処理に要するメモリや処理負荷等のリソースを軽減することができる。

尚、図３（ａ）の例ではコンテンツリストを取得する方法としてＢｒｏｗｓｅアクションを使用したが、再生装置２０はＳｅａｒｃｈアクションでもコンテンツリストを記録装置１０から取得することが可能である。本実施例では再生装置２０がコンテンツリストを取得するアクション（要求）としてＢｒｏｗｓｅアクションを使用するものとして説明するが、Ｓｅａｒｃｈアクションを使用しても良い。

また、処理能力取得手段１０９は、再生装置２０からのＢｒｏｗｓｅアクション受信時に処理能力を取得しているがこれに限られるものではなく、例えば、予め処理能力を取得しておくようにしてもよい。これにより、Ｂｒｏｗｓｅアクションに対する応答速度を上げることができる。

次に、再生装置２０が再生のためにコンテンツデータを取得する際の処理の流れについて、図３（ｂ）を参照しながら説明する。図３（ｂ）は、再生装置２０が記録装置１０からコンテンツデータを取得する際の処理の流れを示す図である。

再生装置２０は、図３（ａ）を参照して説明した処理により取得したコンテンツリストから、１つのコンテンツデータを選択する。メディアレンダラ且つコントロールポイントである再生装置２０は、コンテンツリストのうち、選択されたコンテンツデータの項目に記載されたＵＲＩに向けて、所定の通信プロトコル（図３（ｂ）の例ではＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ） ＧＥＴ）によりコンテンツデータの取得要求を送信する（Ｓ２２１）。この応答として、メディアサーバである記録装置１０は、コンテンツ転送部１１１から要求されたコンテンツデータの送信を行う（Ｓ２２３）。これにより、再生装置２０は取得したコンテンツデータを再生することができる。尚、この通信プロトコルはＨＴＴＰに限られるものではなく、例えばＲＴＰ（Ｒｅａｌｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）等を使用することもできる。

続いて、本実施例の再生装置２０における、記憶媒体１０４内のコンテンツデータが管理されるディレクトリ構造と、コンテンツリストの階層構造との関係について、図４及び図５を参照しながら説明する。

図４は、コンテンツ管理部１０５が記憶媒体１０４内のコンテンツデータを管理する際のディレクトリ構造の例を示す図である。図４のディレクトリ構造４００の例では、ＲＯＯＴディレクトリ４０１（根）は、“ＤＣＩＭ”という名前のディレクトリ４０２を子供として持つ。更に、ＤＣＩＭディレクトリ４０２は、“１００ＴＳＢ”という名前のディレクトリ４０３、及び“１０１ＴＳＢ”という名前のディレクトリ４０４を子供に持つ。

“１００ＴＳＢ”という名前のディレクトリ４０３は、静止画像のコンテンツデータである“写真００１．ｊｐｇ”という名前の画像ファイル４０３Ａ、“写真００２．ｊｐｇ”という名前の画像ファイル４０３Ｂ、“写真ｘｘｘ．ｊｐｇ”という名前の画像ファイル４０３Ｍを子供に持つ。このとき、ディレクトリ４０３が子供に持つことのできる画像ファイル数には制限はなく、多いときには数千以上になることもある。

同様に、“１０１ＴＳＢ”という名前のディレクトリ４０４は、静止画像のコンテンツデータである“写真ｙｙｙ．ｊｐｇ”という名前の画像ファイル４０４Ａ、“写真ｚｚｚ．ｊｐｇ”という名前の画像ファイル４０４Ｎを子供に持つ。ディレクトリ４０４についても同様に、子供に持つことのできる画像ファイル数には特に制限は無い。

仮想分類部１０６は、ディレクトリ構造４００で管理されるファイル／ディレクトリに対して、各グループ（ディレクトリ）の子供の数が再生装置２０の処理能力数以下となるように分類してコンテンツリストのコンテナ構造を作成する。以下、仮想分類部１０６は、各グループの子供が１０以下となるように分類するものとして説明を行う。

図５は、仮想分類部１０６が分類するコンテンツリストのコンテナ構造の例を示す図である。図５のコンテンツリスト５００では、コンテナ５０１をルートコンテナとしている。このコンテナ５０１は、図４に示したディレクトリ構造４００内のディレクトリ４０２（名前：“ＤＣＩＭ”）に対応する。

コンテナ５０１は、“１０１ＴＳＢ”という名前のコンテナ５０２、及び“１０１ＴＳＢ”という名前のコンテナ５０３を子供に持つ。コンテナ５０２は図４に示したディレクトリ構造４００内のディレクトリ４０３（名前：１００ＴＳＢ）に、コンテナ５０３は図４に示したディレクトリ構造４００内のディレクトリ４０４（名前：１０１ＴＳＢ）に、其々対応する。

仮想分類部１０６は、ディレクトリ４０３内に格納されていたファイル４０３Ａ乃至４０３Ｍが、再生装置２０の処理能力数（たとえば１０）を超えている場合には、これらのファイルに対応するアイテムを其々子供として持つと共に、子供の数が該所定数以下となるように、コンテナ５０２−１乃至５０２−Ｍを作成する。写真等の静止画像データの場合には、各コンテンツデータ（ファイル）は撮像日時（作成日時）の情報をメタデータとして持っていることが多い。本実施例の仮想分類部１０６は、撮像日で一時分類すると共に、撮像日時で分類した後にも再生装置２０の処理能力数を超えている場合には、これが処理能力数以下となるように分類している。

より具体的には、“２００７０１０１−１”という名前のコンテナ５０２−１、及び“２００７０１０１−２”という名前のコンテナ５０２−２は、撮像日２００７年１月１日のコンテンツデータに対応するアイテムを子供として持つものであり、其々のコンテナが子供として持つアイテム数が、再生装置２０の処理能力数である１０以下となるように分類されたものである。

図５の例では、コンテナ５０２−１は、コンテンツデータ４０３Ａ（“写真００１．ｊｐｇ”）に対応するアイテム５０２−１ａ、コンテンツデータ４０３Ｂ（“写真００２．ｊｐｇ”）に対応するアイテム５０２−１ｂ、図４に図示しないコンテンツデータ（“写真０１０．ｊｐｇ”）に対応するアイテム５０２−１ｍを子供として持ち、これら子供の数は１０以下となる。同様に、コンテナ５０２−２は、図４に図示しないコンテンツデータ（“写真０１１．ｊｐｇ”）に対応するアイテム５０２−２ａ、図４に図示しないコンテンツデータ（“写真０１ｘ．ｊｐｇ”）に対応するアイテム５０２−２ｎを子供として持ち、これらの子供の数は１０以下となる。

コンテナ５０２−３（名前は“２００７０１１５−１”）、５０２−Ｍ（名前は“ｘｘｘｘｘｘｘｘ−ｘ”）、及びコンテナ５０３（先述の通りディレクトリ４０４に対応、名前は“１０１ＴＳＢ”）の子供であるコンテナ５０３−１（名前は“２００７０２０２−１”）についても、コンテナ５０２−１及び５０２−２と同様、これら子供の数が再生装置２０の処理能力数以下となるように、仮想分類部１０６が分類する。

図６は、仮想分類部１０６が作成したコンテナ構造に従って、コンテンツ公開部１０７が公開するコンテンツリストの例を示す図である。尚、図６の例では、コンテンツリスト全体を示しているが、再生装置２０から受信したＢｒｏｗｓｅ要求で指定されたコンテナやアイテムだけをＢｒｏｗｓｅ Ｒｅｓｐｏｎｓｅとして送信することができる。

先述したように、ＣＤＳとして動作するコンテンツ公開部１０７は、コンテンツリスト５００をＸＭＬ形式で公開する。ＸＭＬの各要素（Ｅｌｅｍｅｎｔ）がコンテナ（ディレクトリに対応）及びアイテム（コンテンツデータに対応）に対応する。コンテナ構造は、ＸＭＬ要素間の親子関係として反映される。

図６の例では、ｃｏｎｔａｉｎｅｒ要素として記載されるコンテナ５０１は、ｉｄ（ｉｄ属性（Ａｔｔｒｉｂｕｔｅ）として記載）として“０”を値として持ち、クラス（子要素であるｕｐｎｐ：ｃｌａｓｓ要素として記載）はｏｂｊｅｃｔ．ｃｏｎｔａｉｎｅｒとなっている。更に、コンテナ５０１に対応するｃｏｎｔａｉｎｅｒ要素は、コンテナ５０２及び５０３に対応するｃｏｎｔａｉｎｅｒ要素２を子要素として持っており、これによりコンテナ５０１がコンテナ５０２及び５０３を子供として持っていることがわかる。

ｃｏｎｔｅｉｎｅｒ要素として表現されるコンテナ５０２は、ｉｄ（ｉｄ属性として記載）として“１”を値として持ち、親のＩＤ（ｐａｒｅｎｔＩＤ属性として記載）が“０”であること、及び子供の数（ｃｈｉｌｄＣｏｕｎｔ属性として記載）が１０であることがわかる。また、該コンテナ５０２の名前が“１００ＴＳＢ”であること（子要素であるｄｃ：ｔｉｔｌｅ要素で記載）、及びクラス（子要素であるｕｐｎｐ：ｃｌａｓｓ要素で記載）がｏｂｊｅｃｔ．ｃｏｎｔａｉｎｅｒであることもわかる。

更に、コンテナ５０２を示すｃｏｎｔａｉｎｅｒ要素は、コンテナ５０２−１に対応するｃｏｎｔａｉｎｅｒ要素及びコンテナ５０２−２に対応するｃｏｎｔａｉｎｅｒ要素を其々子要素として有している。これにより、コンテナ５０２はコンテナ５０２−１及び５０２−２を子供としていることがわかる。

ｃｏｎｔａｉｎｅｒ要素として表現されるコンテナ５０２−１は、ｉｄ（ｉｄ属性として記載）として“２”を値として持ち、親のＩＤの値（ｐｒｅｎｔＩＤ属性として記載）が“１”であり、子供の数（ｃｈｉｌｄＣｏｕｎｔ属性として記載）が１０であることを示している。更に、該コンテナ５０２−１の名前（子要素であるｄｃ：ｔｉｔｌｅ要素で記載）が“２００７０１０１−１”であること、及びクラス（子要素であるｕｐｎｐ：ｃｌａｓｓ要素で記載）がｏｂｊｅｃｔ．ｃｏｎｔａｉｎｅｒであることも示している。

更に、コンテナ５０２−１を示すｃｏｎｔａｉｎｅｒ要素は、アイテム５０２−１ａに対応するｉｔｅｍ要素、アイテム５０２−１ｂに対応するｉｔｅｍ要素、アイテム５０２−１ｍに対応するｉｔｅｍ要素を子要素としてもっており、これにより、コンテナ５０２−１がアイテム５０２−１ａ、５０２−１ｂ、５０２−１ｍを其々子供として持つことがわかる。

アイテム５０２−１ａを示すｉｔｅｍ要素５０２−１ａは、ｉｄ（ｉｄ属性として記載）として“２−１”を値として持ち、親のＩＤの値（ｐｒｅｎｔＩＤ属性として記載）が“２”であることを示している。更に、該アイテム５０２−１ａの名前（子要素であるｄｃ：ｔｉｔｌｅ要素として記載）が“写真００１”であること、撮像日時（同じく子要素であるｄｃ：ｄａｔｅ要素として記載）が２００７−０１−０１Ｔ０７３０２０であること、クラス（子要素であるｕｐｎｐ：ｃｌａｓｓ要素として記載）がｏｂｊｅｃｔ．ｉｔｅｍ．ｉｍａｇｅＩｔｅｍであること、対応するコンテンツデータ取得のための通信プロトコル情報（子要素であるｒｅｓ要素内ｐｒｏｔｏｃｏｌＩｎｆｏ属性として記載）が“ｈｔｔｐ−ｇｅｔ：＊：ｉｍａｇｅ／ｊｐｇ：＊”であること、対応するコンテンツデータを取得するためのＵＲＩ（同じくｒｅｓ要素内の子テキストとして記載）が“ｈｔｔｐ：／／１９２．１６８．０．１：５８８４９／写真００１．ｊｐｇ”であること、がわかる。

同様に、アイテム５０２−１ｂを示すｉｔｅｍ要素５０２−１ｂは、ｉｄ（ｉｄ属性として記載）として“２−２”を値として持ち、親のＩＤの値（ｐｒｅｎｔＩＤ属性として記載）が“２”であることを示している。更に、該アイテム５０２−１ｂの名前（子要素であるｄｃ：ｔｉｔｌｅ要素として記載）が“写真００２”であること、撮像日時（同じく子要素であるｄｃ：ｄａｔｅ要素として記載）が２００７−０１−０１Ｔ０７３０２５であること、クラス（子要素であるｕｐｎｐ：ｃｌａｓｓ要素として記載）がｏｂｊｅｃｔ．ｉｔｅｍ．ｉｍａｇｅＩｔｅｍであること、対応するコンテンツデータ取得のための通信プロトコル情報（子要素であるｒｅｓ要素内ｐｒｏｔｏｃｏｌＩｎｆｏ属性として記載）が“ｈｔｔｐ−ｇｅｔ：＊：ｉｍａｇｅ／ｊｐｇ：＊”であること、対応するコンテンツデータを取得するためのＵＲＩ（同じくｒｅｓ要素内の子テキストとして記載）が“ｈｔｔｐ：／／１９２．１６８．０．１：５８８４９／写真００２．ｊｐｇ”であること、がわかる。

記載を省略している他のコンテナ、アイテムについても、コンテンツリスト５００内には同様の方法でコンテンツデータの情報が記載される。
図６を見ても明らかなように、ＣＤＳでは１つのアイテムやコンテナに係る記載量が多いため、記憶媒体１０４内に記憶される全コンテンツデータについてのコンテンツリストを一度に送信しようとすると、ＲＡＭ１０８に多大な一時記憶容量が必要となると共に、ＣＰＵ等でも多くの計算処理等が必要となり、記憶装置１０に大きなリソースを持たせる必要がある。しかしながら、本実施例では、１つのコンテナ（グループ）に含まれる子供の数を所定数以下になるように仮想分類部１０６で分類し、各コンテナ（グループ）毎に公開することができるため、比較的小さなリソースでも、コンテンツリストをＣＤＳとして公開することができるようになる。

続いて、図７を参照しながら本実施形態にかかる記録装置１０のコンテンツリスト５００の作成及び送信の処理の流れについて説明する。
通信部１０９で再生装置３０からの閲覧要求（Ｂｒｏｗｓｅアクション）を受信すると（Ｓ７０１）、制御部１０１による制御の下、処理能力取得部１１０は、再生装置２０に対して処理能力取得要求を送信する（Ｓ７０２）。続いて、処理能力取得部１１０がこの処理能力取得要求に対する応答として処理能力を再生装置２０から受信したか否かを判断する（Ｓ７０３）。処理能力取得部１１０が処理能力を受信した場合には（Ｓ７０３のＹｅｓ）、制御部１０１による制御の下、コンテンツ管理部１０５が管理するディレクトリ構造４００に対して、仮想分類部１０５で各コンテナ内の子供（アイテム及びコンテナ）の数が、再生装置２０が処理可能な項目数以下となるように分類し、階層構造を持つコンテナ構造を作成する（Ｓ７０４。例えば、図５参照）。

処理能力取得部１１０が処理能力を受信できなかった場合には（Ｓ７０３のＮｏ）、制御部１０１による制御の下、コンテンツ管理部１０５が管理するディレクトリ構造４００に対して、仮想分類部１０５で作成する各コンテナ内の子供（アイテム及びコンテナ）の数が予め定められた一定数以下となるように分類し、階層構造を持つコンテナ構造を作成する（Ｓ７０５）。ここで、処理能力取得部１１０が処理能力を受信できなかった場合とは、例えば再生装置２０からエラーメッセージを受信した場合や、一定時間以上応答を受信しなかった場合等である。

尚、Ｓ７０４及びＳ７０５で階層構造を持つコンテナ構造を作成した際にも、コンテンツ管理部１０５が管理する記憶媒体１０４内のディレクトリ構造４００は維持されたままであり、ディレクトリ構造４００で１つのグループであったものがコンテンツリスト５００のコンテナ構造で複数に分割されていたとしても、ディレクトリ構造４００は変化させない。

コンテンツ公開部１０７は、仮想分類部１０６が作成したコンテナ構造に従って、図６に例を示したＸＭＬの記載によりコンテンツリスト５００を階層構造で公開する（Ｓ７０６）。このとき、先述したように、１つのコンテナ下の子供（コンテナ／アイテム）だけを送信でき、この子供の数を、再生装置２０の処理能力に応じた数とすることができるので、たとえ再生装置２０が比較的小さなリソースしか持たない場合であっても、再生装置２０でコンテンツリストを処理できるようになり、また、コンテンツリスト５００の取得時間等を軽減することもできる。

加えて、記録装置１０側においても、コンテンツリスト５００を送信する際に要するメモリ等のリソース量を減らすことができる。
また、図７に示したように、Ｂｒｏｗｓｅアクション受信時にコンテナ構造の仮想分類を行うことにより、例えばコンテンツデータが新たに追加になっていた場合等であっても柔軟に対応することができるようになる。

更に、本実施例のコンテンツ公開部１０７は撮像部１０２で撮像した静止画像データ等をコンテンツデータとして公開している。特に静止画像はデータ量も比較的少なく、数千の数のデータを記憶媒体１０４に記憶できることも少なくない。このような場合には、コンテンツ公開部１０７が公開するコンテンツリストの項目（アイテム）も同じ数だけ必要となるため、本実施例のように１つのグループに含まれるアイテム／コンテナの数を再生装置２０の処理能力数以下とする効果は顕著となる。

更に、音楽データ等であれば、アルバム名、アーティスト名、ジャンル等の各種情報を利用して多段階に分類して１つのグループ内の項目数を少なくすることも可能ではあるが、静止画像データの場合には撮像日時以外には分類に適した情報が特にないため、このように属性情報だけを使って分類してもグループ内の項目数を飛躍的に減らすのは困難である。本実施例では、撮像日時で分類したグループ（コンテナ）内の項目数が再生装置２０の処理能力を超えた場合には、強制的に別のグループ（コンテナ）を作成するようにしているため、一度に公開するコンテンツリスト５００の項目数を確実に減らすことができる。

尚、図７の例ではＢｒｏｗｓｅ要求受信時に仮想分類部１０６がコンテナ構造の仮想分類を行っていたが、これに限られるものではなく、例えば予め分類を行うようにしていても良い。その場合、Ｂｒｏｗｓｅアクション受信時に処理能力取得処理（図７のＳ７０３〜７０５）を行わずに済むため、再生装置２０に対する応答性を向上させることができるようになる。

本発明の実施例１に係る記録装置が使用される通信システムの例。 本発明の実施例１に係る記録装置の構成を示す図。 本発明の実施例１に係る記録装置が他の通信装置と通信する際の処理の流れを示す図。 本発明の実施例１に係る記録装置の記憶媒体内に記憶されるコンテンツデータのディレクトリ構造の例を示す図。 本発明の実施例１に係る記録装置が公開するコンテンツリストのコンテナ構造の例を示す図。 本発明の実施例１に係る記録装置が公開するコンテンツリストの例を示す図。 本発明の実施例１に係る記録装置のコンテンツリスト公開に係る処理の流れを示す図。

符号の説明

１・・・通信システム
１０・・・記録装置
２０、３０・・・再生装置
４０・・・ネットワーク
１０１・・・制御部
１０２・・・撮像部
１０３・・・コンテンツ記録部
１０４・・・記憶媒体
１０５・・・コンテンツ管理部
１０６・・・仮想分類部
１０７・・・コンテンツ公開部
１０８・・・ＲＡＭ
１０９・・・通信部
１１０・・・処理能力取得部
１１１・・・コンテンツ転送部
１１２・・・コンテンツ取得部
４００・・・ディレクトリ構造
４０１、４０２、４０３、４０４・・・ディレクトリ
４０３Ａ、４０３Ｂ、４０３Ｍ、４０４Ａ、４０４Ｎ・・・ファイル（コンテンツデータ）
５０１、５０２、５０２−１、５０２−２、５０２−３、５０２−Ｍ・・・コンテナ
５０２−１ａ、５０２−１ｂ、５０２−１ｍ、５０２−２ａ、５０２−２ｎ・・・アイテム

Claims (5)

1. 記憶媒体が記憶する１以上のコンテンツデータを、１以上の階層を持つ第１の階層構造で管理する管理手段と、
   ネットワーク上の他の装置の処理能力を取得する処理能力取得手段と、
   前記管理手段が管理する前記記憶媒体内の前記第１の階層構造を維持しつつ、前記処理能力取得手段で取得した前記他の装置の処理能力に応じてコンテンツデータを第２の階層構造に分類する分類手段と、
   前記分類手段が分類した前記第２の階層構造に従って、コンテンツデータのリストを前記他の装置に公開するリスト公開手段と、
   前記リスト公開手段が前記リストとして公開したコンテンツデータを、前記他の装置からの要求に応じて前記記憶媒体から読み込む読込手段と、
   前記読込手段が読み込んだコンテンツデータを前記他の装置に送信する送信手段と
   を備えることを特徴とする通信装置。
2. 前記分類手段は、前記リスト公開手段が前記リストとして一度に送信するコンテンツデータ数が一定数以下となるように、前記第２の階層構造に分類すること
   を特徴とする請求項１記載の通信装置。
3. 前記分類手段は、前記第１の階層構造で１のグループとして管理される１以上のコンテンツデータを、各グループ内のコンテンツデータ数が一定数以下となるように前記第２の階層構造で複数のグループとして分類すること
   を特徴とする請求項２記載の通信装置。
4. 前記他の装置から、前記リストの閲覧を要求する閲覧要求を受信する受信手段
   を更に備え、
   前記処理能力取得手段は、前記受信手段が前記閲覧要求を前記他の装置から受信した際、前記他の装置の処理能力を取得すること
   を特徴とする請求項２記載の通信装置。
5. 撮像により画像データを生成する撮像手段
   を更に備え、
   前記記憶媒体が記憶するコンテンツデータは、少なくとも前記撮像手段が撮像する画像データを含むこと
   を特徴とする請求項２記載の通信装置。

Images