(57)【要約】 プレイヤ（コンテンツ検索装置）４は、取得した第１メタデータ（通し番号100番）を、記憶手段における100番に対応する第１メタデータと比較し、不一致と判断すると（Ｓ４５，Ｓ４６：Ｎｏ）、今度は通し番号99番に対応する第１メタデータを取得する。そして、取得した第１メタデータを記憶手段における100番に対応する第１メタデータと比較し、一致と判断すると（Ｓ４５，Ｓ４６：Ｙｅｓ）、プレイヤ４はサーバ８から通し番号99番に対応するコンテンツを取得して再生を始める。
2012032711.tif 000002
【特許請求の範囲】
【請求項１】
コンテンツ毎に、通し番号とコンテンツの内容を説明する第１メタデータとを紐付けた第１データベースを備えるサーバから、通し番号を用いてコンテンツを検索するコンテンツ検索装置であって、
前記第１データベースに対応する第２データベースを記憶する記憶手段と、
同期に関するトリガ条件が満たされると、前記サーバから第１データベースの情報を受信し、受信した情報を基に前記第２データベースの内容を前記第１データベースの内容と同期させる同期手段と、
前記第２データベースの通し番号の中から、一の通し番号の指定をユーザから受け付ける受付手段と、
受け付けた通し番号を用いて、前記サーバから第１メタデータを取得するメタデータ取得手段と、
第１メタデータが取得される毎に、前記第２データベースにおける前記受け付けた通し番号に対応する第１メタデータと、の両者を比較して一致しているかどうかを判断する判断手段とを備え、
不一致と判断されると、前記メタデータ取得手段は、前記受け付けた通し番号の周辺の通し番号を用いて、前記サーバから前記第１メタデータを取得し、
さらに、前記判断手段により周辺の通し番号を用いた第１メタデータを基にした比較が一致と判断されると、当該周辺の通し番号に対応するコンテンツを前記サーバから取得するコンテンツ取得手段と、
前記コンテンツ取得手段により取得されたコンテンツを再生する再生手段と
を備えることを特徴とするコンテンツ検索装置。
【請求項２】
前記メタデータ取得手段は、前記判断手段により一致と判断されるまで、前記周辺の通し番号として、それ以前の取得に用いた通し番号とは異なる番号を用いて第１メタデータの取得を繰り返す
ことを特徴とする請求項１に記載のコンテンツ検索装置。
【請求項３】
前記受付手段が受け付けた通し番号が前記第２データベースにおいてＮ番（Ｎは２以上の整数）であるとした場合に、
前記判断手段は、前記メタデータ取得手段による第１メタデータの取得の度に、取得された第１メタデータと、前記第２データベースにおける（Ｎ−１）番、Ｎ番および（Ｎ＋１番）の第１メタデータのそれぞれとを比較して一致しているかどうかを判断し、
前記判断手段により判断の繰り返しの結果、前記判断手段が当該記憶手段に記憶されたデータベースにおけるＮ番の第１メタデータを用いた一致の判断をしていないのに、当該記憶手段に記憶されたデータベースにおける（Ｎ−１）番および（Ｎ＋１）番それぞれの第１メタデータを用いた一致の判断をしていれば、前記メタデータ取得手段による以降の取得を中止させる
ことを特徴とする請求項２記載のコンテンツ検索装置。
【請求項４】
前記受付手段が受け付けた通し番号が前記第２データベースにおいてＮ番（Ｎは２以上の整数）であるとした場合に、
前記判断手段は、前記メタデータ取得手段による第１メタデータの取得の度に、取得された第１メタデータと、前記第２データベースにおける（Ｎ−１）番、Ｎ番および（Ｎ＋１番）の第１メタデータのそれぞれとを比較して一致しているかどうかを判断し、
前記判断手段により判断の繰り返しの結果、前記判断手段が当該記憶手段に記憶されたデータベースにおけるＮ番の第１メタデータを用いた一致の判断をしていないのに、当該記憶手段に記憶されたデータベースにおける（Ｎ−１）番および（Ｎ＋１）番それぞれの第１メタデータを用いた一致の判断をしているときに、前記Ｎ番に対応するコンテンツが前記サーバには存在しない旨を前記ユーザに通知する通知手段を備える
ことを特徴とする請求項２記載のコンテンツ検索装置。
【請求項５】
前記受付手段が受け付けた通し番号が前記第２データベースにおいてＮ番（Ｎは２以上の整数）である場合に、
前記メタデータ取得手段は、Ｎ番を用いて第１メタデータを取得し、
取得された第１メタデータを基にした判断が前記判断手段により不一致と判断されると、前記メタデータ取得手段は、（Ｎ−１）番を用いて第１メタデータを取得し、
取得された第１メタデータを基にした判断が前記判断手段により不一致と判断されると、前記メタデータ取得手段は、（Ｎ−２）番を用いて第１メタデータを取得し、
以降、前記メタデータ取得手段は、前記判断手段により一致と判断されるまで、（Ｎ−３）番、（Ｎ−４）番、．．．、とひとつずつ番号を前にずらした通し番号を用いて第１メタデータの取得を繰り返す
ことを特徴とする請求項２に記載のコンテンツ検索装置。
【請求項６】
前記受付手段が受け付けた通し番号が前記第２データベースにおいてＮ番（Ｎは２以上の整数）であるとした場合に、
前記コンテンツ取得手段が用いる前記周辺の通し番号とは、（Ｎ−１）番である
ことを特徴とする請求項１に記載のコンテンツ検索装置。
【請求項７】
前記受付手段が受け付けた通し番号が前記第２データベースにおいてＮ番（Ｎは２以上の整数）であるとした場合に、
前記コンテンツ取得手段が用いる前記周辺の通し番号とは、（Ｎ−１）番および（Ｎ＋１）番である
ことを特徴とする請求項１に記載のコンテンツ検索装置。
【請求項８】
前記メタデータ取得手段は、ＤＬＮＡ（Digital Living Network Alliance）ガイドラインに準拠したブラウズ要求を前記サーバに対して送信することで前記取得を行う
ことを特徴とする請求項１に記載のコンテンツ検索装置。
【請求項９】
前記第１データベースは、前記通し番号、前記第１メタデータおよびコンテンツの再生フォーマットを示す第２メタデータを前記コンテンツ毎に紐付けたものであって、
前記第２データベースは、前記通し番号および前記第１メタデータを前記コンテンツ毎に紐付けたものであって、
前記同期手段は、前記第１データベースの内容である前記通し番号および前記第１メタデータは同期の対象とするが、前記第２メタデータは同期の対象とせず、
前記メタデータ取得手段は、前記第１メタデータに加えて前記第２メタデータをも取得し、
前記再生手段は、前記コンテンツ取得手段により取得されたコンテンツを、前記メタデータ取得手段により取得され当該コンテンツに対応する第２メタデータに示される再生フォーマットに基づいて再生する
ことを特徴とする請求項１に記載のコンテンツ検索装置。
【請求項１０】
サーバが備えるコンテンツ毎に通し番号とコンテンツの内容を説明する第１メタデータとを紐付けた第１データベース、に対応する第２データベースを記憶手段に記憶させる記憶ステップと、
同期に関するトリガ条件が満たされると、前記サーバから第１データベースの情報を受信し、受信した情報を基に前記第２データベースの内容を前記第１データベースの内容と同期させる同期ステップと、
前記第２データベースの通し番号の中から、一の通し番号の指定をユーザから受け付ける受付ステップと、
受け付けた通し番号を用いて、前記サーバから第１メタデータを取得するメタデータ取得ステップと、
取得された第１メタデータと、前記第２データベースにおける前記受け付けた通し番号に対応する第１メタデータと、の両者を比較して一致しているかどうかを判断する第１判断ステップと、
不一致と判断されると、前記受け付けた通し番号に対して周辺の通し番号を用いて、前記サーバから前記第１メタデータを取得する周辺メタデータ取得ステップと、
取得された第１メタデータと、前記記憶手段における前記受け付けた通し番号に対応する第１メタデータと、の両者を比較して一致しているかどうかを判断する第２判断ステップと、
前記第２判断ステップにより一致と判断されると、当該周辺の通し番号に対応するコンテンツを前記サーバから取得するコンテンツ取得ステップと、
前記コンテンツ取得ステップにより取得されたコンテンツを再生する再生ステップの各ステップ
を含むコンテンツ検索方法。
【請求項１１】
コンテンツを検索する検索処理をコンテンツ検索装置にて実行させるためのプログラムであって、
前記検索処理は、
サーバが備えるコンテンツ毎に通し番号とコンテンツの内容を説明する第１メタデータとを紐付けた第１データベース、に対応する第２データベースを記憶手段に記憶させる記憶ステップと、
同期に関するトリガ条件が満たされると、前記サーバから第１データベースの情報を受信し、受信した情報を基に前記第２データベースの内容を前記第１データベースの内容と同期させる同期ステップと、
前記第２データベースの通し番号の中から、一の通し番号の指定をユーザから受け付ける受付ステップと、
受け付けた通し番号を用いて、前記サーバから第１メタデータを取得するメタデータ取得ステップと、
取得された第１メタデータと、前記第２データベースにおける前記受け付けた通し番号に対応する第１メタデータと、の両者を比較して一致しているかどうかを判断する第１判断ステップと、
不一致と判断されると、前記受け付けた通し番号に対して周辺の通し番号を用いて、前記サーバから前記第１メタデータを取得する周辺メタデータ取得ステップと、
取得された第１メタデータと、前記記憶手段における前記受け付けた通し番号に対応する第１メタデータと、の両者を比較して一致しているかどうかを判断する第２判断ステップと、
前記第２判断ステップにより一致と判断されると、当該周辺の通し番号に対応するコンテンツを前記サーバから取得するコンテンツ取得ステップと、
前記コンテンツ取得ステップにより取得されたコンテンツを再生する再生ステップとを含むことを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
サーバが管理しているコンテンツの中から所望のコンテンツを、このサーバと接続されたプレイヤ（コンテンツ検索装置の一種）にて検索する技術に関する。
【背景技術】
【０００２】
近年、ＤＬＮＡ（Digital Living Network Alliance）ガイドラインが適用されたホームネットワークの利用が進んでいる（非特許文献１）。【０００３】
ＤＬＮＡガイドラインは、機器間の相互接続を規定したＵＰｎＰ（Universal Plug and Play）（非特許文献２）を核としている。このガイドラインにより、さまざまな機器からなる家庭内ネットワークの環境下において、コンテンツを機器間で（機器のメーカの垣根を越えて）共有することができる。【０００４】
例えば、あるサーバに保存されたコンテンツを、プレイヤにおいて再生することができる。
【先行技術文献】
【非特許文献】
【０００５】
【非特許文献１】”DLNA Overview and Vision Whitepaper 2007”、［online］、［平成２２年８月１０日検索］、インターネット＜URL：http://www.dlna.org/news/DLNA_white_paper.pdf＞
【非特許文献２】” ContentDirectory:2 Service Template Version 1.01For UPnPTM Version 1.0”、［online］、［平成２２年８月１０日検索］、インターネット＜URL：http://upnp.org/resources/upnpresources.zipを展開したフォルダ upnpresources/standardizeddcps/MediaServer_2 and  MediaRenderer_2内の、UPnP-av-ContentDirectory-v2-Service-20060531.pdf＞
【発明の概要】
【発明が解決しようとする課題】
【０００６】
係るＤＬＮＡガイドラインにおいては、サーバは複数のコンテンツに通し番号を紐付けて管理することを規定している。【０００７】
この通し番号に関する情報は、サーバからプレイヤへと伝えられ、プレイヤがサーバに対して再生すべきコンテンツを指定する際には、この通し番号が用いられる。【０００８】
ところが、通し番号に関する情報は、サーバとプレイヤの間でリアルタイムに同期されているわけではないことが一般的であるので、サーバ側で更新された情報が未だ伝わっていないプレイヤでは取得を試みたコンテンツに合致するコンテンツを取得できないことがある。【０００９】
このような問題は、ＤＬＮＡに依拠した環境下に限らず、コンテンツに恒常的でない通し番号を付けて管理するサーバと、このサーバと接続されコンテンツを検索するコンテンツ検索装置とを接続したネットワーク環境下において同様に生じ得る。【００１０】
本発明はこのような背景の下になされたものであって、コンテンツ毎に通し番号を紐付けて管理するサーバを対象としてコンテンツを検索するコンテンツ検索装置において、コンテンツの取得を支援することを目的とする。
【課題を解決するための手段】
【００１１】
本発明に係るコンテンツ検索装置は、コンテンツ毎に、通し番号とコンテンツの内容を説明する第１メタデータとを紐付けた第１データベースを備えるサーバから、通し番号を用いてコンテンツを検索するコンテンツ検索装置であって、前記第１データベースに対応する第２データベースを記憶する記憶手段と、同期に関するトリガ条件が満たされると、前記サーバから第１データベースの情報を受信し、受信した情報を基に前記第２データベースの内容を前記第１データベースの内容と同期させる同期手段と、前記第２データベースの通し番号の中から、一の通し番号の指定をユーザから受け付ける受付手段と、受け付けた通し番号を用いて、前記サーバから第１メタデータを取得するメタデータ取得手段と、第１メタデータが取得される毎に、前記第２データベースにおける前記受け付けた通し番号に対応する第１メタデータと、の両者を比較して一致しているかどうかを判断する判断手段とを備え、不一致と判断されると、前記メタデータ取得手段は、前記受け付けた通し番号の周辺の通し番号を用いて、前記サーバから前記第１メタデータを取得し、さらに、前記判断手段により周辺の通し番号を用いた第１メタデータを基にした比較が一致と判断されると、当該周辺の通し番号に対応するコンテンツを前記サーバから取得するコンテンツ取得手段と、前記コンテンツ取得手段により取得されたコンテンツを再生する再生手段とを備えることを特徴としている。
【発明の効果】
【００１２】
サーバが通し番号で管理する複数の第１メタデータにおいては、コンテンツの削除（第１メタデータの削除）があると、削除されたコンテンツよりも後方のコンテンツの通し番号が前にずれるし、また、コンテンツの追加（第１メタデータの追加）があると、追加されたコンテンツよりも後方のコンテンツの通し番号が後ろにずれることがある。【００１３】
このため、本発明に係るコンテンツ検索装置によれば、メタデータ取得手段が周辺の通し番号を用いて取得した第１メタデータは、通し番号のずれ度合いによっては、メタデータ取得手段が当初取得を試みたコンテンツの第１メタデータと一致したものとなり得る。このため、当初指定したコンテンツの取得を支援することができる。
【図面の簡単な説明】
【００１４】
【図１】ユーザＡの自宅１のホームネットワーク２を示す図
【図２】プレイヤ４の機能ブロック図
【図３】記憶部１４の記憶内容の例を示す図
【図４】サーバ８が保有するコンテンツをプレイヤ４において再生する動作を示すフローチャート
【図５】ひとつの第１メタデータの削除（コンテンツの削除）により、以降の第１メタデータの通し番号が前にずれるイメージを示す図
【図６】プレイヤ４、サーバ８におけるシーケンス図
【図７】プレイヤ４とサーバ８の機能ブロック図
【図８】メタデータ記憶部５６の記憶内容の例を示す図
【図９】サーバ８が保有するコンテンツをプレイヤ４において再生する動作を示すフローチャート
【図１０】ひとつの第１メタデータの削除（コンテンツの削除）により、以降の第１メタデータの通し番号が後ろにずれるイメージを示す図
【図１１】２回目以降の取得で用いる通し番号の決め方を示す図
【図１２】２回目以降の取得で用いる通し番号の決め方を示す図
【図１３】ユーザが視聴を希望するコンテンツである通し番号100番の第１メタデータが削除されるイメージを示す図
【図１４】プレイヤ４における通知に関する動作を示すフローチャート
【図１５】プレイヤ４、サーバ８におけるシーケンス図
【発明を実施するための形態】
【００１５】
以下、図面を参照しながら本実施の形態を説明する。
【００１６】
図１に示すように、ユーザＡの自宅１内には、プレイヤ４、プレイヤ６およびサーバ８が参加するホームネットワーク２が形成されている。
【００１７】
プレイヤ４，６は、ＤＬＮＡガイドラインにおいてデジタルメディアプレーヤー（ＤＭＰ:Degital Media Player）と呼ばれる。
【００１８】
サーバ８は、同じくＤＬＮＡガイドラインにおいてはデジタルメディアサーバー（ＤＭＳ：Degital Media Server）と呼ばれる。
【００１９】
各デバイスは例えば、プレイヤ４はデジタルテレビ、プレイヤ６は携帯端末、サーバ８はブルーレイディスクレコーダーにより実現される。
【００２０】
各デバイス４，６，８は、一般的なＤＬＮＡ対応機器同様、ＤＬＮＡガイドライン（およびＵＰｎＰ）に準拠して動作する。
【００２１】
すなわち、デバイスの発見と機能の把握は、ＳＳＤＰ（Simple Service Discover Protocol）を用い、コンテンツのメタ情報のやり取りには、ＳＯＡＰ（Simple Object Access Protocol）を用い、コンテンツの送受信にはＨＴＴＰ（Hypertext Transfer Protoco）を用いる。また、以下でいうコンテンツは特記しない限り動画形式のコンテンツであるとする。
【００２２】
このホームネットワーク２において、サーバ８が蓄積している大量のコンテンツの中のひとつのコンテンツを、プレイヤ４において再生する正常な流れは、次の（１）〜（７）の通りである。
（１）プレイヤ４は、サーバ８が蓄積しているコンテンツのリストを取得する。
（２）プレイヤ４は、取得したリストをディスプレイ１７ａに表示してユーザＡの閲覧に供する。
（３）プレイヤ４は、ユーザＡからリストの中からコンテンツの通し番号の指定を受け付ける。
（４）プレイヤ４は、受け付けたコンテンツの通し番号を用いて、サーバ８からこの通し番号に対応する第１メタデータ（コンテンツの内容を説明するメタデータ）を取得する。
（５）プレイヤ４は、取得した第１メタデータを、自機が記憶している通し番号に対応する第１メタデータと比較して一致しているかどうか判断する。
（６）プレイヤ４は、一致と判断すると、サーバ８に対して通し番号に対応するコンテンツのＵＲＩ（Uniform Resource Identifier）の取得を要求する。
（７）プレイヤ４は、取得したＵＲＩにより示される資源（Resource）からコンテンツを取得して、ディスプレイ１７ａ上に再生する。
【００２３】
ここで、プレイヤ４が記憶している通し番号に関する情報と、サーバ８が記憶している通し番号に関する情報とがリアルタイムに同期されていれば、上の（５）の判断は一致となるはずである。
【００２４】
もっとも、プレイヤ４は、同期に関するトリガ条件（例えば、プレイヤ４の電源投入という条件）が満たされたときにしかサーバから通し番号に関する情報を取得しないことが通常である。このため、サーバ８側でコンテンツの追加や削除があったとしても、その更新内容がプレイヤ４側に反映されるまで時間を要する（プレイヤ４が記憶している上記通し番号に関する情報はサーバ８が現に記憶している情報と比べて、更新が遅れた古い情報になり得る）。このような背景から（５）の判断は不一致となることがある。
【００２５】
本実施の形態では、このような場合においても、プレイヤ４が受け付けたコンテンツの取得の実現を図る。
【００２６】
図２は、プレイヤ４の機能ブロック図である。
【００２７】
プレイヤ４は、同期部１２、記憶部１４、Ｕ／Ｉ（ユーザインターフェイス）部１６、メタデータ取得部１８、判断部２０、コンテンツ取得部２２、コンテンツ再生部２４を備える。
【００２８】
同期部１２は、サーバ８に対してブラウズ要求を発行することにより、サーバから通し番号と第１メタデータとを受信し、受信した通し番号と第１メタデータとを記憶部１４（例えばフラッシュメモリから構成される。）に記憶させる。
【００２９】
また、記憶部１４に通し番号と第１メタデータとが既に記憶されていれば、同期部１２は、受信した通し番号および第１メタデータの情報を基に記憶部１４の記憶内容を更新する同期処理を行う。
【００３０】
図３に、記憶部１４の記憶内容の例を示す。
【００３１】
図３の例では、記憶部１４は、「通し番号」３０と、通し番号毎の第１メタデータ３２とを記憶している。
【００３２】
第１メタデータ３２は、コンテンツの内容を説明するものであり、「タイトル」３２ａ、「ジャンル」３２ｂ、「アーティスト」３２ｃの項目を含む。
【００３３】
図２に戻って機能ブロックの説明を続ける。
【００３４】
Ｕ／Ｉ部１６は、ユーザインターフェイスをつかさどるものであり、ディスプレイ１７ａに、同期部１２が受信した第１メタデータに基づいたコンテンツのリストを表示させたり、表示したリストの中から一のコンテンツの指定をリモコン１７ｂを介して受け付けたりする。なお、詳しくは後述するが、コンテンツの指定の受け付けは、コンテンツの通し番号を受け付ける形でなされる。
【００３５】
メタデータ取得部１８は、サーバ８に対してブラウズ要求を発行することにより、Ｕ／Ｉ部１６が指定を受け付けた通し番号（あるいは受け付けた通し番号に前後する通し番号）に対応する第１メタデータを前記サーバから取得する。
【００３６】
後述するように、サーバ８が管理するメタデータは多数の項目があるが、メタデータ取得部１８では、この多数の項目の中からタイトル、ジャンル、アーティストの三者のみを取得する。なお、この取得は、タイトル、ジャンル、アーティストを指定する旨の情報を、上記ブラウズ要求に含めることで実現できる。
【００３７】
判断部２０は、メタデータ取得部１８により取得された第１メタデータと、記憶部１４における通し番号に対応する第１メタデータの両者を比較して一致しているかどうかを判断する。
【００３８】
コンテンツ取得部２２は、判断部２０が一致と判断した通し番号に対応するコンテンツをサーバ８から取得する。具体的には、サーバ８に対して通し番号に対応するＵＲＩの取得を要求し、取得したＵＲＩにより示される資源（Resource）からコンテンツを取得する。
【００３９】
コンテンツ再生部２４は、コンテンツ受信部２２が受信したコンテンツをディスプレイ１７ａ上で再生する。
【００４０】
次に、図４を参照して、サーバ８が保有するコンテンツをプレイヤ４において再生する動作の流れを説明する。
【００４１】
まず、同期部１２は、サーバ８に対してブラウズ要求を発行することにより、サーバ８から通し番号と第１メタデータとを受信し、受信した通し番号と第１メタデータとを基に、記憶部１４の記憶内容を更新する同期処理を行う（Ｓ４１）。
【００４２】
次に、Ｕ／Ｉ部１６は、同期部１２が受信した第１メタデータに基づいてコンテンツのリストをディスプレイ１７ａに表示させる（Ｓ４２）。
【００４３】
そして、Ｕ／Ｉ部１６は、表示したリストの中から一の通し番号の指定をリモコン１７ｂを介して受け付ける（Ｓ４３）。
【００４４】
このステップＳ４２，Ｓ４３の処理は一般的な手法を用いることができ、例えば、タイトル、ジャンルおよびアーティスト（図３参照）からなるリストのアイテムを一覧表示して、表示した中から一のアイテムを受け付け、そして記憶部１４に参照することで受け付けたアイテムの通し番号を特定することにより行うことができる。なお、プレイヤ４側で通し番号を特定できるやり方であれば足り、ユーザが通し番号を認識できるようにすることは必須ではない。
【００４５】
次に、メタデータ取得部１８は、サーバ８に対してブラウズ要求を発行することにより、指定された通し番号に対応する第１メタデータを取得する（Ｓ４４）。
【００４６】
続いて、判断部２０は、ステップＳ４４で現に取得された第１メタデータと、記憶部１４におけるステップＳ４３で受け付けられた通し番号の第１メタデータとを比較する（Ｓ４５）。
【００４７】
一致していれば（Ｓ４６：Ｙｅｓ）、コンテンツ取得部２２は、通し番号に対応するコンテンツを取得し、コンテンツ再生部２４は取得したコンテンツを再生する（Ｓ４８）。
【００４８】
一致していなければ（Ｓ４６：Ｎｏ）、メタデータ取得部１８は、それまで取得した通し番号に前後する通し番号の第１メタデータを取得する（Ｓ４７）。
【００４９】
そして、取得された第１メタデータに基づいて、判断部２０による比較と判断のステップＳ４５，Ｓ４６が繰り返される。
【００５０】
図４で説明したフローによれば、メタデータ取得部１８による１回目の取得（Ｓ４４）でユーザが再生を希望したコンテンツを取得できなかったとしても、２回目以降の取得（Ｓ４７）でこのコンテンツを取得することを支援できる。
【００５１】
続いて図５〜図６を参照して、具体的な例を挙げてさらに説明する。
【００５２】
図５は、第１メタデータの削除（コンテンツの削除）により、通し番号に対応する第１メタデータが前にずれるイメージを示す図である。
【００５３】
この図５に示すように、ステップＳ４１で受信し記憶部１４に記憶した時からステップＳ４５の比較に至る間に、サーバ８において通し番号99番のコンテンツが削除されると、この削除に伴ってこのコンテンツの第１メタデータが削除され、元々100番以降の第１メタデータがひとつ前にずれることとなる。
【００５４】
ステップＳ４５の時点においては、このずれはプレイヤ４の記憶部１４には反映されていないため、プレイヤ４の記憶部１４の記憶内容である通し番号に関する情報と、サーバ８で現に管理している通し番号に関する情報とは食い違いが生じている。
【００５５】
例えば、プレイヤ４側では、通し番号100番のコンテンツは、タイトル「DEF」（図３参照）のコンテンツであるのに対して、サーバ８側では、通し番号100番のコンテンツは元々101番であったタイトル「ＧＨＩ」のコンテンツとなる。
【００５６】
図６は、このような齟齬が起きている状況下において、プレイヤ４が通し番号100番のコンテンツの指定を受け付けた場合のシーケンス図である。
【００５７】
図６におけるステップ番号は図４と対応しているので、重複する部分は説明を簡単にする。
【００５８】
まず、プレイヤ４の同期部１２によりサーバ８から通し番号と第１メタデータとを受信し（Ｓ４１）、受信した通し番号と第１メタデータとに基づいたリストを表示し（Ｓ４２）、表示したリストの中から通し番号100番のコンテンツであるタイトル「DEF」のコンテンツを受け付ける（Ｓ４３：100番）。
【００５９】
次に、メタデータ取得部１８は、サーバ８に対してブラウズ要求（100番）を発行することにより、通し番号100番に対応する第１メタデータを取得する（Ｓ４４）。
【００６０】
判断部２０は、取得された第１メタデータと、記憶部１４における通し番号100番に対応する第１メタデータとを比較する（Ｓ４５）。この比較は、第１メタデータの各項目どうしを比較し、すべての項目どうしが一致したときにのみ最終的に一致と判断する。
【００６１】
上に述べたように、サーバ８側では、通し番号100番のコンテンツは元々101番であったタイトル「ＧＨＩ」を含む第１メタデータなので、比較する両者の項目は次の通りである。
・取得された通し番号100番の第１メタデータ
タイトル「DEF」、ジャンル「sports」、アーティスト「bbb」
・記憶部１４に記憶された通し番号100番の第１メタデータ
タイトル「ABC」、ジャンル「drama」、アーティスト「aaa」
このように、タイトル、ジャンルおよびアーティストがいずれも異なっているので、判断部２０は不一致と判断する（Ｓ４６:Ｎｏ）。
【００６２】
続いて、メタデータ取得部１８は、それまで取得した通し番号100番のひとつ前の番号である通し番号99番に対応する第１メタデータを取得する（Ｓ４７：99番）
判断部２０は、取得された第１メタデータと、記憶部１４における通し番号100番に対応する第１メタデータとを比較する。サーバ８側では、通し番号99番の第１メタデータは元々100番であった第１メタデータなので比較する両者の項目は次の通りである。
・取得された通し番号99番の第１メタデータ
タイトル「ABC」、ジャンル「drama」、アーティスト「aaa」
・記憶部１４に記憶された通し番号100番の第１メタデータ
タイトル「ABC」、ジャンル「drama」、アーティスト「aaa」
タイトル、ジャンルおよびアーティストがすべて一致しているので、判断部２０は一致と判断する（Ｓ４６:Ｙｅｓ）。
【００６３】
続いて、コンテンツ取得部２２は、サーバ８に対してコンテンツ要求（URI）を発行することにより通し番号99番に対応するコンテンツのURIを取得する。なお、このURIには、例えば、http://example.com/contents99.mp4など、通し番号99番を示す情報が含まれていることもある。
【００６４】
URIの取得後、コンテンツ再生部２４は、取得したURIを用いてコンテンツ要求(ストリーミング)を行い、受信したストリーミングを用いて再生を開始することとなる（Ｓ４８）。
【００６５】
以上、説明したように、図６の例では、プレイヤ４とサーバ８とで通し番号に関する情報に齟齬があるにも関わらず、ユーザが希望した通りのコンテンツを取得することが実現されている。
【００６６】
なお、同期部１２が同期処理を行うトリガ条件を調整するなどして、プレイヤ４とサーバ８との間で通し番号に関する情報の同期頻度を多くすれば、このような食い違いはある程度は抑えられる。もっとも、特にサーバ８が管理するコンテンツの数が多くなると、同期に要する処理負荷の増大を招くのでこれにも限界がある。本実施の形態によれば、このような同期に要する負荷の軽減にも貢献することができる。
【００６７】
さらに、本実施の形態では、プレイヤ４とサーバ８間の情報のやりとりはＤＬＮＡガイドラインに準拠したやり方を維持することができ、特にサーバ８側の仕様変更を行うことなく、プレイヤ４のコンテンツの取得を支援できる。
【００６８】
（実施の形態２）
実施の形態２では、プレイヤが記憶すべきメタデータを絞り込むことで、プレイヤの記憶容量の節約を図る。
【００６９】
すなわち、近年サーバ側の記憶容量の飛躍的向上に伴い、サーバが管理するコンテンツの数が多くなる傾向にある。
【００７０】
個々のコンテンツのメタデータのサイズはそれほど大きくない（例えば、1ｋＢ程度）が、コンテンツの個数が数万個になると、個々のコンテンツに対応する数万個分のメタデータの総容量は無視できない大きさ（例えば、数十ＭＢ程度）となる。
【００７１】
このため、このサーバ側が管理するメタデータを、プレイヤ側でもそのまま保持すると、プレイヤ側の記憶容量を圧迫し得る。
【００７２】
そこで、実施の形態２では、プレイヤにおいて、記憶すべきメタデータを絞り込むことで記憶容量の節約を図る。
【００７３】
図７は、実施の形態２に係るプレイヤ４とサーバ８の機能ブロック図である。図７においては、図２と同様のブロックには同じ符号を付している。
【００７４】
プレイヤ４のメタデータ取得部４８は、サーバ８から第１メタデータに加えてコンテンツの再生フォーマットを示す第２メタデータを取得する。この第２メタデータの詳細については後述する。
【００７５】
コンテンツ再生部２４は、この第２メタデータに示される再生フォーマットを用いて再生を行う。
【００７６】
サーバ８は、メタデータ送信部５２、コンテンツ送信部５４、メタデータ記憶部５６、コンテンツ記憶部５８および制御部６０を備える。
【００７７】
メタデータ送信部５２は、プレイヤ４の同期部１２やメタデータ取得部４８の要求に応じて、メタデータ記憶部５６に記憶された第１メタデータまたは第２メタデータを送信する。
【００７８】
コンテンツ送信部５４は、プレイヤ４のコンテンツ取得部２２やコンテンツ再生部２４の要求に応じて、コンテンツ記憶部５８に記憶されたコンテンツのＵＲＩやコンテンツを送信する。
【００７９】
制御部６０は、各部を管理したり制御したりする機能を有する。
【００８０】
図８は、メタデータ記憶部５６の記憶内容の例を示す図である。
【００８１】
図８の例では、メタデータ記憶部５６は、「通し番号」３０と、通し番号毎の第１メタデータ３２および第２メタデータ３４を記憶している。
【００８２】
第１メタデータ３２は、コンテンツの内容を説明するものであり、「タイトル」３２ａ、「ジャンル」３２ｂ、「アーティスト」３２ｃの３項目を含む。
【００８３】
第２メタデータ３４は、コンテンツの再生フォーマットを示すものであり、コンテンツの資源を識別するための「コンテンツURI」３４ａ、コンテンツの再生リストである「プレイリストURI」３４ｂ、早送りや巻き戻しなどの特殊再生の制限の有無などの仕様を示す「特殊再生情報」３４ｃ、コーデックやビットレートなどを示す「エンコード情報」３４ｄ、コンテンツの再生を案内に係る情報である「ナビ情報」３４ｅ、前回再生を停止した位置から再生を開始するレジューム機能に関する「レジューム情報」３４ｆの６項目を含む。
【００８４】
次に、図９を参照して、サーバ８が保有するコンテンツをプレイヤ４において再生する動作の流れを説明する。なお、図９においては、図４と同様のステップは同じ番号を付し説明を省略する。
【００８５】
まず、プレイヤ４のメタデータ取得部４８はブラウズ要求を発行することにより、サーバ８のメタデータ記憶部５６から通し番号と第１メタデータとを受信し、受信した通し番号と第１メタデータとを基に、記憶部１４の記憶内容を更新する同期処理を行う（Ｓ９１）。
【００８６】
そして、Ｕ／Ｉ部１６が通し番号の指定を受け付けると（Ｓ４３）、メタデータ取得部４８はブラウズ要求を発行することにより、サーバ８のメタデータ記憶部５６から指定された通し番号に対応する第１メタデータおよび第２メタデータを取得する。
【００８７】
第１メタデータどうしの比較（Ｓ４５）後に、一致と判定されると（Ｓ４６：Ｙｅｓ）、コンテンツ取得部２２は、通し番号に対応するコンテンツを取得し、コンテンツ再生部２４は通し番号に対応する第２メタデータに示される再生フォーマットに従って再生する（Ｓ９８）。
【００８８】
本実施の形態によれば、ステップＳ９１，Ｓ９４にあるように、同期部１２が受信した第１メタデータは同期の対象とするが、第２メタデータは同期の対象としないの記憶部１４の容量を節約できる。
【００８９】
例えば、サーバ８が数万個のオーディオコンテンツを管理していると、メタデータ記憶部５６（図８参照）のメタデータの総容量は75MBにもなることがある。記憶部１４に第２メタデータは同期しないとすることでメタデータの容量をおおよそ25MB程度まで減らすことができる。
【００９０】
なお、要は記憶部１４の空き容量を確保できればよいので、ステップＳ９１においては、同期部１２により第２メタデータを含むメタデータをすべて受信し、その後、同期部１２において受信したメタデータの中から第２メタデータ部分のみをフィルタリングした後に記憶部１４に記憶するとしても構わない。
【００９１】
このフィルタリングはホワイトリスト方式やブラックリスト方式など一般的な手法を用いることができる。
【００９２】
＜補足１＞
以上、本実施の形態について説明したが、本発明は上記の内容に限定されず、本発明の目的とそれに関連又は付随する目的を達成するための各種形態においても実施可能であり、例えば、以下であっても構わない。
（１）２回目以降の取得で用いる通し番号の決め方
実施の形態１の図６の例では、サーバ８側の通し番号に対応する第１メタデータが前にずれていたものとして説明したが、反対にサーバ８においてコンテンツが追加されると、第１メタデータが後ろにずれることもある。
【００９３】
すなわち、図１０に示すように、サーバ８において通し番号99番と100番の第１メタデータの間に、新たなひとつの第１メタデータが追加されると、この追加に伴って元々100番以降の第１メタデータがひとつ後ろにずれることとなる。
【００９４】
このように、図５や図１０のような色々な通し番号のずれ方に合わせて、２回目以降の取得で用いる通し番号の決め方も様々な手法が考えられる。
【００９５】
以下、図１１を参照しながら、受け付けた通し番号が100番である場合に、これらの様々な手法について説明する。
【００９６】
（ａ）実施の形態１の図６のように、通し番号100番→99番→98番→97番と受け付けた100番より順繰りに手前の通し番号を用いて、第１メタデータの取得を繰り返す（図１１（ａ））。
【００９７】
（ｂ）（ａ）同様に通し番号100番→99番→98番→97番と順繰りに手前の通し番号を用い、通し番号が最初の１番に達した後は、101番→102番→103番と、100番より順繰りに後ろの通し番号を用いて第１メタデータの取得を繰り返す（図１１（ｂ））。
【００９８】
（ｃ）（ａ）とは反対に、通し番号100番→101番→102番→103番と受け付けた100番より順繰りに後ろの通し番号を用いて、第１メタデータの取得を繰り返す（図１１（ｃ））。
【００９９】
（ｄ）（ａ）同様に順繰りに手前の通し番号に用いるが、通し番号100番→95番〜99番→90番〜94番と、２回目以降の取得は5個単位で通し番号を指定して5個のメタデータをまとめて取得する（図１１（ｄ））。なお、5個に限らず10個など他の任意の数としてもよい。
【０１００】
（ｅ）通し番号100番→95番〜99番および101番〜105番→90番〜94番および106番〜110番と、２回目以降の取得は通し番号が前後5個のメタデータをまとめて取得する（図１２（ｅ））。
（２）第１メタデータの取得の繰り返しを打ち切る条件
図４のフローでは、ステップＳ４５〜Ｓ４７（図４）は一致と判断されるまで（Ｓ４６：Ｙｅｓ）、繰り返されるようになっているが、一致と判断されなくとも途中で打ち切るようにしても構わない。なぜならば、サーバ８側で管理している通し番号の数が多いと、繰り返しが長引きユーザを待たせてしまうこともあるし、また、受け付けた通し番号から通し番号が離れると第１メタデータが一致する可能性は低くなると考えられるからである。
【０１０１】
例えば、ステップＳ４５〜Ｓ４７で取得したメタデータが一定個数（例えば100個）に達した場合や、ステップＳ４５〜Ｓ４７の処理が開始から一定時間（例えば、5秒）に達した場合などには、打ち切るとしてもよい。
【０１０２】
また、図１３に示すように、ステップＳ４１で受信し記憶部１４に記憶した時からステップＳ４５の比較に至る間に、サーバ８において通し番号100番のコンテンツが削除されることで、このコンテンツの第１メタデータが削除されていることがある。
【０１０３】
この場合には、図４のフローに並行して、図１４に示すような処理を判断部２０において行うとしてもよい。
【０１０４】
つまり、判断部２０は、第１メタデータが取得される度に、取得された第１メタデータと、記憶部１４の（Ｎ−１）番、Ｎ番および（Ｎ＋１）番の第１メタデータとを比較して一致を判断する（Ｓ１４１）。
【０１０５】
そして、ステップＳ１４１の判断を繰り返した結果において、記憶部１４上において受け付けた通し番号（Ｎ番、Ｎは２以上の整数）を用いた比較の一致がないのに、記憶部１４上において受け付けた通し番号の前の通し番号（Ｎ−１番）および後ろの通し番号（Ｎ＋１番）を用いた比較の一致があれば（Ｓ１４２：Ｙｅｓ）、サーバ上に受け付けた通し番号に対応するコンテンツが存在しない旨を通知する（Ｓ１４３）。さらに、判断部２０はメタデータ取得部１８による取得を中止させる（Ｓ１４４）。
【０１０６】
図１５を用いて具体例を説明すると、プレイヤ４の記憶部１４における通し番号101番と99番とを用いた比較の一致があるのに、100番を用いた比較が無いため、通し番号100番に対応するコンテンツはサーバ８上には存在しないという推定が働く。このため、ユーザにその旨を直ちに通知することで、ユーザの使い勝手の向上につなげることができる。また、その時点でメタデータの取得部１８による取得を中止させることで、徒労に終わるであろう以降の取得の繰り返しを回避できる。
（３）ソート基準
サーバ８が管理するコンテンツの第１メタデータは、ソート基準（criteria）従って並べられて通し番号を付与されていることが通常である。このソート基準は、コンテンツの名前、コンテンツのレート、コンテンツの作成日時、あるいはコンテンツの追加日時などでありユーザ設定などに基づいて規定されている。
【０１０７】
このソート基準を元に上の（１）の（ａ）〜（ｅ）で説明した２回目以降の取得で用いる通し番号の決め方を最適化することもできる。
【０１０８】
例えば、ソート基準がコンテンツの追加日時で昇順に並べられているのであれば、第１メタデータの通し番号が前にずれることはあっても、後ろにずれることは考えにくい（新たに追加されたものは追加日時が最新のため末尾の通し番号になるはずだからである。）。このため、この場合には上の（１）の（ｃ）の手法を採用することが好適である。
【０１０９】
反対に、ソート基準がコンテンツの追加日時で降順に並べられているのであれば、（１）の（ａ）の手法を採用するとよい。
（４）フォルダ
実施の形態では詳しく説明しなかったが、同期部１２は、サーバ８が管理するコンテンツが保存されたフォルダに関する情報を受信するようにしてもよい。
【０１１０】
そして、受信したフォルダに関する情報をＵ／Ｉ部１６に表示したり、コンテンツ検索の絞込条件に利用するとしても構わない。
【０１１１】
また、メタデータ取得部１８は、通し番号に加えてフォルダを指定（例えば、video/my_favorites/2010/05というフォルダ内の100番と指定）してメタデータを取得するようにしてもよい。
（５）第１メタデータ
実施の形態１などでは、「タイトル」、「ジャンル」、「アーティスト」の３つを第１メタデータの例として説明したが、これに限られない。
【０１１２】
要は、ユーザによるコンテンツの検索に供するためのメタデータであればよく、非特許文献２のP125以降に記載の、俳優（actor）、作者（author）、プロデューサー（producer）、発行者（publisher）、説明（description）、エピソード番号（episodeNumber）などを用いることもできる。
【０１１３】
係る第１メタデータは、ユーザに表示してコンテンツ検索の手掛かりとなる内容であるので「検索用メタデータ」とも呼ぶことができる。
【０１１４】
また、ステップＳ４５の比較においては、必ずしも取得した第１メタデータの項目をすべて用いる必要はなく一部でも構わない。
【０１１５】
もっとも、あまりに項目が少ないと一致判断の精度が低下するため（例えば、ジャンルが同じで中身が異なるコンテンツは多いだろう。）、一致判断に用いる第１メタデータの項目はある程度数を増やす必要がある。
（６）第２メタデータ
実施の形態２では、図８の「コンテンツＵＲＩ」３４ａなどの6つを第２メタデータの例として説明したが、これに限られない。
【０１１６】
要は、コンテンツの再生に供するためのメタデータであればよく、非特許文献２のP121に記載の、再生時間の長さ（duration）、音声のサンプリング周波数(sampleFrequency)、解像度(resolution)、色深度(colorDepth)などを用いることもできる。
【０１１７】
係る第２メタデータは、コンテンツの再生フォーマットを示すものであるので「再生用メタデータ」とも呼ぶことができる。
（７）ユーザへの通知
図１５の例では、ステップＳ１４３の通知は、判断部２０がＵ／Ｉ部１６を介してディスプレイ１７ａに「コンテンツ『ＤＥＦ』はサーバから削除されたようです」メッセージを表示することにより行っている。なお、通知はユーザが認識できる方式であれば足り、表示に限らず音声による通知でもよい。
【０１１８】
また、図１４のフローにおいてステップＳ１４３，Ｓ１４４の順序は問わないし、ステップＳ１４３，Ｓ１４４のいずれか一方のステップをスキップするやり方もあり得る。
（８）コンテンツ検索装置
図２では、プレイヤ４のＵ／Ｉ部１６はリモコン１７ｂから通し番号の指定を受け付けているが、リモコンに限らずマウスや操作ボタンなどの任意の入力インターフェイスから受け付けるとしても構わない。また、図２中、プレイヤ４の要部であるコンテンツ検索装置１００を点線で囲んで示す。
（９）コンテンツの形式
実施の形態では、コンテンツは動画コンテンツであるとして説明したが、動画に限らずオーディオ（音声）のコンテンツや画像のコンテンツにも実施の形態の手法は広く適用することができる。
（１０）同期に関するトリガ条件
実施の形態では、プレイヤ４の電源投入をトリガ条件として挙げたが、これに限らず、予め定められたスケジュールの日時に到達したことをトリガ条件としてもよいし、ユーザ指示をトリガ条件としてもよい。
【０１１９】
さらには、ステップＳ４２（図４）のリスト表示の直前をトリガ条件としてもよい。この場合にも、ステップＳ４３の受付に至る間に、サーバ８で管理している通し番号に関する情報が変化する可能性がある。
（１１）プログラム
上述の実施の形態で示した動作などを各種情報処理装置のプロセッサ、及びそのプロセッサに接続された各種回路に実行させるためのプログラムコードからなる制御プログラムを、記録媒体に記録すること、又は各種通信路を介して流通させ頒布することもできる。
【０１２０】
このような記録媒体には、ＩＣカード、ハードディスク、光ディスク、フレキシブルディスク、ＲＯＭ等の非一時的な（not-transitory）記録媒体がある。
【０１２１】
流通、頒布された制御プログラムは、プロセッサに読み出され得るメモリ等に格納されることにより利用に供され、そのプロセッサがその制御プログラムを実行することにより実施の形態で示したような各種機能が実現されるようになる。
（１２）ＬＳＩ
図２などの各機能ブロックは、集積回路であるＬＳＩとしてもよい。これらは個別に１チップ化されても良いし、一部又は全てを含むように１チップ化されても良い。ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。
【０１２２】
また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサーを利用してもよい。さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。
＜補足２＞
本実施の形態は、以下の態様を含むものである。
（１）実施の形態に係るコンテンツ検索装置は、コンテンツ毎に、通し番号とコンテンツの内容を説明する第１メタデータとを紐付けた第１データベースを備えるサーバから、通し番号を用いてコンテンツを検索するコンテンツ検索装置であって、前記第１データベースに対応する第２データベースを記憶する記憶手段と、同期に関するトリガ条件が満たされると、前記サーバから第１データベースの情報を受信し、受信した情報を基に前記第２データベースの内容を前記第１データベースの内容と同期させる同期手段と、前記第２データベースの通し番号の中から、一の通し番号の指定をユーザから受け付ける受付手段と、受け付けた通し番号を用いて、前記サーバから第１メタデータを取得するメタデータ取得手段第１メタデータが取得される毎に、前記第２データベースにおける前記受け付けた通し番号に対応する第１メタデータと、の両者を比較して一致しているかどうかを判断する判断手段とを備え、不一致と判断されると、前記メタデータ取得手段は、前記受け付けた通し番号の周辺の通し番号を用いて、前記サーバから前記第１メタデータを取得し、さらに、前記判断手段により周辺の通し番号を用いた第１メタデータを基にした比較が一致と判断されると、当該周辺の通し番号に対応するコンテンツを前記サーバから取得するコンテンツ取得手段と、前記コンテンツ取得手段により取得されたコンテンツを再生する再生手段とを備えることを特徴とする。
（２）前記メタデータ取得手段は、前記判断手段により一致と判断されるまで、前記周辺の通し番号として、それ以前の取得に用いた通し番号とは異なる番号を用いて第１メタデータの取得を繰り返すとしても構わない。
（３）前記受付手段が受け付けた通し番号が前記第２データベースにおいてＮ番（Ｎは２以上の整数）であるとした場合に、
前記判断手段は、前記メタデータ取得手段による第１メタデータの取得の度に、取得された第１メタデータと、前記第２データベースにおける（Ｎ−１）番、Ｎ番および（Ｎ＋１番）の第１メタデータのそれぞれとを比較して一致しているかどうかを判断し、前記判断手段により判断の繰り返しの結果、前記判断手段が当該記憶手段に記憶されたデータベースにおけるＮ番の第１メタデータを用いた一致の判断をしていないのに、当該記憶手段に記憶されたデータベースにおける（Ｎ−１）番および（Ｎ＋１）番それぞれの第１メタデータを用いた一致の判断をしていれば、前記メタデータ取得手段による以降の取得を中止させるとしても構わない。
【０１２３】
この構成によれば、メタデータの取得に関する処理の軽減に貢献する。
（４）前記受付手段が受け付けた通し番号が前記第２データベースにおいてＮ番（Ｎは２以上の整数）であるとした場合に、前記判断手段は、前記メタデータ取得手段による第１メタデータの取得の度に、取得された第１メタデータと、前記第２データベースにおける（Ｎ−１）番、Ｎ番および（Ｎ＋１番）の第１メタデータのそれぞれとを比較して一致しているかどうかを判断し、前記判断手段により判断の繰り返しの結果、前記判断手段が当該記憶手段に記憶されたデータベースにおけるＮ番の第１メタデータを用いた一致の判断をしていないのに、当該記憶手段に記憶されたデータベースにおける（Ｎ−１）番および（Ｎ＋１）番それぞれの第１メタデータを用いた一致の判断をしているときに、前記Ｎ番に対応するコンテンツが前記サーバには存在しない旨を前記ユーザに通知する通知手段を備えるとしても構わない。
【０１２４】
この構成によれば、ユーザの使い勝手向上に資する。
（５）前記受付手段が受け付けた通し番号が前記第２データベースにおいてＮ番（Ｎは２以上の整数）である場合に、前記メタデータ取得手段は、Ｎ番を用いて第１メタデータを取得し、取得された第１メタデータを基にした判断が前記判断手段により不一致と判断されると、前記メタデータ取得手段は、（Ｎ−１）番を用いて第１メタデータを取得し、取得された第１メタデータを基にした判断が前記判断手段により不一致と判断されると、前記メタデータ取得手段は、（Ｎ−２）番を用いて第１メタデータを取得し、以降、前記メタデータ取得手段は、前記判断手段により一致と判断されるまで、（Ｎ−３）番、（Ｎ−４）番、．．．、とひとつずつ番号を前にずらした通し番号を用いて第１メタデータの取得を繰り返すとしても構わない。
（６）前記受付手段が受け付けた通し番号が前記第２データベースにおいてＮ番（Ｎは２以上の整数）であるとした場合に、前記コンテンツ取得手段が用いる前記周辺の通し番号とは、（Ｎ−１）番であるとしても構わない。
（７）前記受付手段が受け付けた通し番号が前記第２データベースにおいてＮ番（Ｎは２以上の整数）であるとした場合に、前記コンテンツ取得手段が用いる前記周辺の通し番号とは、（Ｎ−１）番および（Ｎ＋１）番であるとしても構わない。
（８）前記メタデータ取得手段は、ＤＬＮＡ（Digital Living Network Alliance）ガイドラインに準拠したブラウズ要求を前記サーバに対して送信することで前記取得を行うとしても構わない。
（９）前記第１データベースは、前記通し番号、前記第１メタデータおよびコンテンツの再生フォーマットを示す第２メタデータを前記コンテンツ毎に紐付けたものであっ前記第２データベースは、前記通し番号および前記第１メタデータを前記コンテンツ毎に紐付けたものであって、前記同期手段は、前記第１データベースの内容である前記通し番号および前記第１メタデータは同期の対象とするが、前記第２メタデータは同期の対象とせず、前記メタデータ取得手段は、前記第１メタデータに加えて前記第２メタデータをも取得し、前記再生手段は、前記コンテンツ取得手段により取得されたコンテンツを、前記メタデータ取得手段により取得され当該コンテンツに対応する第２メタデータに示される再生フォーマットに基づいて再生するとしても構わない。
（１０）実施の形態に係るコンテンツ検索方法は、サーバが備えるコンテンツ毎に通し番号とコンテンツの内容を説明する第１メタデータとを紐付けた第１データベース、に対応する第２データベースを記憶手段に記憶させる記憶ステップと、同期に関するトリガ条件が満たされると、前記サーバから第１データベースの情報を受信し、受信した情報を基に前記第２データベースの内容を前記第１データベースの内容と同期させる同期ステップと、前記第２データベースの通し番号の中から、一の通し番号の指定をユーザから受け付ける受付ステップと、受け付けた通し番号を用いて、前記サーバから第１メタデータを取得するメタデータ取得ステップと、取得された第１メタデータと、前記第２データベースにおける前記受け付けた通し番号に対応する第１メタデータと、の両者を比較して一致しているかどうかを判断する第１判断ステップと、不一致と判断されると、前記受け付けた通し番号に対して周辺の通し番号を用いて、前記サーバから前記第１メタデータを取得する周辺メタデータ取得ステップと、取得された第１メタデータと、前記記憶手段における前記受け付けた通し番号に対応する第１メタデータと、の両者を比較して一致しているかどうかを判断する第２判断ステップと、前記第２判断ステップにより一致と判断されると、当該周辺の通し番号に対応するコンテンツを前記サーバから取得するコンテンツ取得ステップと、前記コンテンツ取得ステップにより取得されたコンテンツを再生する再生ステップとを含む。
（１１）実施の形態に係るプログラムは、コンテンツを検索する検索処理をコンテンツ検索装置にて実行させるためのプログラムであって、前記検索処理は、サーバが備えるコンテンツ毎に通し番号とコンテンツの内容を説明する第１メタデータとを紐付けた第１データベース、に対応する第２データベースを記憶手段に記憶させる記憶ステップと、同期に関するトリガ条件が満たされると、前記サーバから第１データベースの情報を受信し、受信した情報を基に前記第２データベースの内容を前記第１データベースの内容と同期させる同期ステップと、前記第２データベースの通し番号の中から、一の通し番号の指定をユーザから受け付ける受付ステップと、受け付けた通し番号を用いて、前記サーバから第１メタデータを取得するメタデータ取得ステップと、取得された第１メタデータと、前記第２データベースにおける前記受け付けた通し番号に対応する第１メタデータと、の両者を比較して一致しているかどうかを判断する第１判断ステップと、不一致と判断されると、前記受け付けた通し番号に対して周辺の通し番号を用いて、前記サーバから前記第１メタデータを取得する周辺メタデータ取得ステップと、取得された第１メタデータと、前記記憶手段における前記受け付けた通し番号に対応する第１メタデータと、の両者を比較して一致しているかどうかを判断する第２判断ステップと、前記第２判断ステップにより一致と判断されると、当該周辺の通し番号に対応するコンテンツを前記サーバから取得するコンテンツ取得ステップと、前記コンテンツ取得ステップにより取得されたコンテンツを再生する再生ステップの各ステップを含むことを特徴とする。
【産業上の利用可能性】
【０１２５】
コンテンツ検索装置におけるコンテンツ検索の確度の向上に貢献でき有用である。
【符号の説明】
【０１２６】
４  プレイヤ
８  サーバ
１２  同期部
１４  記憶部
１６  Ｕ／Ｉ部
１８  メタデータ取得部
２０  判断部
２２  コンテンツ取得部
２４  コンテンツ再生部
３０  通し番号
３２  第１メタデータ
３４  第２メタデータ
４８  メタデータ取得部
５６  メタデータ記憶部
【図１】
2012032711.tif 000003
【図２】
2012032711.tif 000004
【図３】
2012032711.tif 000005
【図４】
2012032711.tif 000006
【図５】
2012032711.tif 000007
【図６】
2012032711.tif 000008
【図７】
2012032711.tif 000009
【図８】
2012032711.tif 000010
【図９】
2012032711.tif 000011
【図１０】
2012032711.tif 000012
【図１１】
2012032711.tif 000013
【図１２】
2012032711.tif 000014
【図１３】
2012032711.tif 000015
【図１４】
2012032711.tif 000016
【図１５】
2012032711.tif 000017
【国際調査報告】
2012032711.tif 000018
2012032711.tif 000019