WO2011013234A1

WO2011013234A1 - 受信装置

Info

Publication number: WO2011013234A1
Application number: PCT/JP2009/063605
Authority: WO
Inventors: 大介安次富; 祐司入江; 会津　宏幸; 直紀江坂; 晃治齊木
Original assignee: 株式会社東芝
Priority date: 2009-07-30
Filing date: 2009-07-30
Publication date: 2011-02-03
Also published as: JPWO2011013234A1; CN102473180B; US20120179703A1; CN102473180A; US8862607B2

Abstract

　受信装置１００は、サービス情報を記憶するサービス情報蓄積管理部２０３と、コンテンツを検索するための検索条件を表す検索クエリであって、当該受信装置１００において表現方法を統一した共通検索条件属性及び当該共通検索条件属性のとり得る値である共通検索属性値の対を少なくとも１つ以上含む共通検索クエリを生成する第１生成部１０１ａと、生成された共通検索クエリを用いて、サービス情報によって示される検索形態に応じた検索クエリを生成する第２生成部１０３と、生成された検索クエリを、サービス情報によって示される接続方法に基づいて、各サービスへ送信し、検索クエリの実行の結果得られたメタデータを通信部１０６を介して各サービスから受信する取得部１０５とを備える。

Description

受信装置

　本発明は、受信装置に関する。

　近年、インターネット上で映像などのコンテンツを配信するサービスやコンテンツを共有するサービスが多数提供されている。このようなサービスの中には、様々なジャンルのコンテンツを単一の配信事業者が提供するだけでなく、例えばスポーツ、ニュース、音楽、映画などの専門性を有するジャンルに特化したものがある。このようなサービスは今後も増加していくことが予想される。また、インターネットのみならず、ＮＧＮ（Ｎｅｘｔ　Ｇｅｎｅｒａｔｉｏｎ　Ｎｅｔｗｏｒｋ）という帯域保証された閉域ＩＰ網上においても、高品質な映像を提供するサービスが開始されており、従来型の地上波、ＢＳ、ＣＳ放送サービスを加えると、ユーザがアクセス可能なコンテンツの数は爆発的に増大している。更に、記憶デバイスの大容量化や低廉化が進み、映像を再生するＡＶ機器のローカルディスク内に蓄積可能なコンテンツの数も膨大になっている。こうしたサービスの多様化と遍在化、コンテンツの爆発的な増大に伴い、ユーザが視たいコンテンツを効率よく発見することが非常に難しくなってきている。このようなことから、選択されたコンテンツに関連するコンテンツを、コンテンツのメタデータを用いてローカルディスクやネットワークにおいて検索し、コンテンツの表示を制御する技術が開発されている（例えば特許文献１参照）。

特開２００８－２２７９４７号公報

　しかし、特許文献１の技術では、ネットワークにおいてコンテンツを検索する際に、ネットワーク上に存在するサービスによっては、コンテンツを検索することができない恐れがある。即ち、各サービスによって、例えば、許容される検索条件や、メタデータのフォーマットや、伝送プロトコルや、検索可能なコンテンツのジャンルや、コンテンツ及びメタデータを検索するための検索式などの検索形態が異なり得る。検索条件を例にとると、あるサービスでは、キーワードによる検索しか許容していないが、別のサービスでは、キーワードによる検索に加えてジャンルによる検索を許容していることがある。また、ジャンルによる検索を許容しているサービス間で、ジャンルの定義が異なることが多い。また、キーワードによる検索がメタデータの全文検索を暗黙的に指すサービスが多い一方で、タイトル、概要説明、キーワード、出演者をキーワードとの指定により検索可能なサービスもある。こうしたサービス毎の多様性を考慮すると、複数のサービス間に跨った横断的な検索をコンテンツの受信装置で実行する際に、所望のコンテンツを検索するための検索式を各サービスの検索形態に合わせる必要がある。しかし、所望のコンテンツを検索するための検索式を、各サービスの検索形態に合わせた検索式に齟齬のない形で射影することは困難であった。このため、それぞれ検索形態の異なる複数のサービスにおいては、ユーザの所望するコンテンツを正確に検索することができない恐れがあった。

　本発明は、上記に鑑みてなされたものであって、複数の異なるサービスにおいてコンテンツを検索する際に、各サービスにおける検索形態が異なったとしても、ユーザの所望するコンテンツを検索可能な受信装置を提供することを目的とする。

　上述した課題を解決し、目的を達成するために、本発明は、受信装置であって、コンテンツの属性を表す属性情報を検索可能な状態で記憶している装置であってネットワークを介して接続可能な記憶装置における検索形態と当該記憶装置に接続するための接続方法とを表すサービス情報を記憶する記憶部と、コンテンツを検索するための検索条件を表す検索クエリであって、前記属性のうちいずれかを表す検索条件属性を当該受信装置において表現方法を統一した共通検索条件属性及び当該共通検索条件属性のとり得る値である共通検索属性値の対を少なくとも１つ以上含む共通検索クエリを生成する第１生成部と、生成された前記共通検索クエリを用いて、前記サービス情報によって示される検索形態に応じた検索クエリを生成する第２生成部と、生成された前記検索クエリを、前記サービス情報によって示される接続方法に基づいて、前記記憶装置へ送信する送信部と、前記検索クエリの実行の結果得られた前記属性情報を前記記憶装置から受信する受信部とを備えることを特徴とする。

　本発明によれば、受信装置において、複数の異なるサービスにおいてコンテンツを検索する際に、各サービスにおける検索形態が異なったとしても、ユーザの所望するコンテンツを検索可能になる。

第１の実施の形態にかかる受信装置１００の機能的構成を例示する図。共通メタデータのデータ構成を例示する図。ＸＭＬ形式で表現される共通メタデータを例示する図。再生履歴情報又はスキップ履歴情報のデータ構成を例示する図。サービス情報のデータ構成を例示する図。キーワード情報のデータ構成を例示する図。実行結果情報のデータ構成を例示する図。検索条件を指定するための画面を例示する図。共通検索クエリのデータ構成を例示する図。共通検索条件リストに示される共通検索条件を例示する図。論理式で表される共通検索条件を例示する図。属性変換テーブル及び属性値変換テーブルを統合的に構成した場合の構成を例示する図。共通検索条件リストに示される共通検索条件を例示する図。検索クエリを例示する図。共通検索条件リストに示される共通検索条件を例示する図。検索クエリを例示する図。受信装置１００の行うメタデータ取得処理の手順を示すフローチャート。第２の実施の形態にかかる受信装置１００´の構成を示す図。メタデータ取得処理において、利用可能なサービスを検出するサービス検出処理の手順を示すフローチャート。メタデータ取得処理において、サービス検出処理後に検索クエリを生成する検索クエリ生成処理の手順を示すフローチャート。第３の実施の形態にかかる受信装置１００″の構成を示す図。受信装置１００″の行うメタデータ取得処理の手順を示すフローチャート。受信装置１００″の行うメタデータ取得処理の手順を示すフローチャート。フィルタ部１０７が行うフィルタ処理の詳細な手順を示すフローチャート。表示制御部１０８が行う整列処理の詳細な手順を示すフローチャート。

　以下に添付図面を参照して、この発明にかかる受信装置の実施の形態を詳細に説明する。

[第１の実施の形態]
　まず、本実施の形態にかかる受信装置のハードウェア構成について説明する。本実施の形態の受信装置は、装置全体を制御するＣＰＵ（Central　Processing　Unit）等の制御部と、各種データや各種プログラムを記憶するＲＯＭ（Read　Only　Memory）やＲＡＭ（Random　Access　Memory）等の主記憶部と、コンテンツなどの各種データや各種プログラムを記憶するＨＤＤ（Hard　Disk　Drive）やＣＤ（Compact　Disk）ドライブ装置等の補助記憶部と、これらを接続するバスとを備えており、通常のコンピュータを利用したハードウェア構成となっている。また、受信装置には、情報を表示する表示部と、ユーザの指示入力を受け付けるキーボードやマウスやリモートコントローラ（リモコン）等の操作入力部と、外部装置との通信を制御する通信Ｉ／Ｆ（interface）とが有線又は無線により各々接続される。外部装置との通信は、ネットワークを介して行う。ネットワークとは、例えば、ＬＡＮ（Local　Area　Network）、イントラネット、イーサネット（登録商標）、インターネット、ＷＡＮ（Wide　Area　Network）又は品質保証された閉域網ＮＧＮ（Next　Generation　Network）などである。受信装置は、例えば、パーソナルコンピュータ、デジタルテレビ、ハードディスクレコーダ、ＳＴＢ（Set　Top　Box）、携帯電話のようなモバイルデバイスで実現される。このような受信装置は、補助記憶部に記憶されるコンテンツやネットワークを介して外部装置からコンテンツを取得したり、コンテンツの属性を表す属性情報であるメタデータを取得してこれを用いてコンテンツを取得したりし、コンテンツを再生する。尚、本実施の形態においては、コンテンツは、映像を表すものであるとするが、これに限らず、音楽、画像、書籍などを表す他の種類のコンテンツであっても良い。

　次に、このようなハードウェア構成において、受信装置のＣＰＵが主記憶部や補助記憶部に記憶された各種プログラムを実行することにより実現される各種機能について説明する。図１は、受信装置１００の機能的構成を例示する図である。受信装置１００は、コンテンツ・メタデータ表示部１０１、選択部１０２、第２生成部１０３、実行制御部１０４、取得部１０５、通信（送信／受信）部１０６、メタデータ蓄積管理部２０１、コンテンツ視聴・スキップ履歴蓄積管理部２０２、サービス情報蓄積管理部２０３、キーワード生成・蓄積管理部２０４、検索クエリ実行履歴蓄積管理部２０５及びコンテンツ・メタデータ表示部属性情報蓄積管理部２０６を有する。コンテンツ・メタデータ表示部１０１、選択部１０２、第２生成部１０３、実行制御部１０４、取得部１０５及び通信部１０６は、ＣＰＵのプログラム実行時にＲＡＭなどの主記憶部上に生成されるものである。メタデータ蓄積管理部２０１、コンテンツ視聴・スキップ履歴蓄積管理部２０２、サービス情報蓄積管理部２０３、キーワード生成・蓄積管理部２０４及び検索クエリ実行履歴蓄積管理部２０５は、補助記憶部に構築されるデータベース管理システムである。これは、ＸＭＬデータベースであっても良いし、リレーショナルデータベースであっても良い。また、これは、単一のデータベース管理システムで構築されている必要はなく、複数のデータベース管理システム、例えば、ＳＱＬｉｔｅ３、Ｏｒａｃｌｅ、ＭｙＳＱＬなどを併用しても良い。また、１つの物理的な補助記憶部上に構築されるようにしても良いし、ＮＡＳやＳＡＮといった複数の物理的な補助記憶部をデータベース管理システムとして利用しても良い。また、これらの蓄積管理部は、データベース管理システムではなく、各蓄積管理部に各々記憶されるデータである単位情報（エントリ）を取得できる手段を備えていれば、単なるＣＳＶ形式などのファイル群で構成されていても良い。

　通信部１０６は、ネットワーク３０１と接続されており、ネットワーク３０１に接続されたコンテンツ配信サーバ４０１，４０２と通信を行なうためのネットワークインタフェースである。本実施の形態においてはこのネットワークインタフェースは１つであるとするが、これに限らず、複数であっても良い。コンテンツ配信サーバ４０１，４０２は、コンテンツやコンテンツのメタデータを検索可能な状態で記憶している記憶装置であり、ネットワーク３０１を介して受信装置１００に送信するインタフェースを有している。このインタフェースは、ＵＲＬ（Uniform　Resource　Locator）に検索クエリの文字列を含め、ＨＴＭＬ（HyperText　Markup　Language）のようなＷｅｂブラウザを介して表示することを想定したハイパーテキストでメタデータを送信するものであっても良いし、ＲＳＳのようにＸＭＬ（Extensible　Markup　Language）ドキュメントで送信するものであっても良い。また、ＳＯＡＰ（Simple　Object　Access　Protocol）のような、ＨＴＴＰのリクエストボディ、レスポンスボディを利用して検索クエリの情報と検索クエリの実行の結果である検索結果のメタデータを送信するものであっても良い。本実施の形態では、コンテンツ配信サーバ４０１，４０２が、こうしたＴＣＰ／ＨＴＴＰプロトコルをベースとしたテキスト形式のユニキャスト通信で、メタデータを送信することを想定しているが、これらに限定されるものではない。例えば、検索クエリ、および、メタデータがバイナリフォーマットであっても良い。その他、上述のようなＴＣＰ／ＨＴＴＰプロトコルをベースとした受信装置１００とコンテンツ配信サーバ４０１，４０２間のユニキャスト通信に限定されるものでもなく、コンテンツ配信サーバ４０１，４０２によって、マルチキャスト通信でメタデータが送信されるものであっても良い。この場合、受信装置１００が、ＩＧＭＰ（Internet　Group　Management　Protocol）やＭＬＤ（Multicast　Listener　Descovery）を利用して、メタデータが配信されるマルチキャストアドレスへの参加や離脱を行うシグナリング通信を行うことになる。尚、図１において、コンテンツ配信サーバとして、２台のコンテンツ配信サーバ４０１，４０２が図示されているが、この他多数のコンテンツ配信サーバがネットワーク３０１に接続され、受信装置１００と通信を行うようにしても良い。本実施の形態においては、コンテンツの検索形態が異なる例を簡便に説明するために、コンテンツ配信サーバ４０１，４０２の２台に限定して説明する。

　メタデータ蓄積管理部２０１は、サービス毎に異なるメタデータを、共通メタデータとして記憶し、当該共通メタデータの記憶やアクセスや削除を制御することにより、共通メタデータを管理する。尚、サービスとは、コンテンツやコンテンツのメタデータを検索可能な状態で記憶しているものであり、図１に示されるコンテンツ配信サーバ４０１，４０２や、メタデータを記憶する当該メタデータ蓄積管理部２０１などである。共通メタデータとは、受信装置１００内で表現形式を統一したメタデータのことである。例えば、コンテンツが映像を表すものである場合、ＴＶ－Ａｎｙｔｉｍｅなどでメタデータ記述形式の標準仕様が策定されており、これを共通メタデータとして利用しても良い。又は、受信装置１００のコンテンツ・メタデータ表示部１０１が表示及び内部的な制御に利用する最小限のメタデータのセットを定義して、これを共通メタデータとして利用しても良い。最小限のメタデータのセットとは、例えば、コンテンツを識別するためのコンテンツ識別子、タイトル、概要説明（シノプシス）、コンテンツの尺、公開・放送日時、年齢制限に関する情報、ジャンル、キーワード（タグ）、提供元のサービスを識別するためのサービス識別子などである。ジャンルについては、例えば「スポーツ」や「芸能」や「経済」などの細分についてジャンルコードが予め付与されており、そのジャンルコードを指定可能である。又は、対象とする全てのサービスに含まれるコンテンツの和集合を取り、これを共通メタデータとして用いても良い。

　尚、複数のサービスから取得したメタデータを共通メタデータとしてメタデータ蓄積管理部２０１が記憶する場合には、サービス識別子を少なくとも含む必要がある。また、共通メタデータは、コンテンツ配信サーバ４０１，４０２から取得されたものであっても良いし、コンテンツ配信サーバ４０１，４０２から取得されたメタデータを用いてメタデータ蓄積管理部２０１が生成したものであっても良い。例えば、メタデータに概要説明が含まれる場合、メタデータ蓄積管理部２０１が、概要説明の文章を形態素解析して、キーワードや人物の名称などの情報を抽出し、抽出した情報を含むように共通メタデータを生成してこれを記憶するようにしても良い。

　図２は、共通メタデータのデータ構成を例示する図である。同図に示されるように、共通メタデータは、取得開始インデックス（from）,取得件数（count）及び総件数（total）の３値と、count数の共通コンテンツ・メタデータとから構成されている。さらに、各共通コンテンツ・メタデータは、後述するメディアタイプ／メディアサブタイプに依存しない共通メタデータ属性と、メディアタイプ／メディアサブタイプに依存する共通メタデータ属性との２種類から構成されている。取得開始インデックス（from）、取得件数（count）、総件数（total）は、後述する共通検索クエリに該当するコンテンツの総数（total）のうち、何件目（from）から何件（count）のメタデータであるかを表している。以下、共通コンテンツ・メタデータを構成する各共通メタデータ属性について述べる。共通コンテンツ・メタデータは、メディアタイプ（mediaType）、メディアサブタイプ（mediaSubType）、コンテンツ識別子（contentId）、コンテンツ名（name）、コンテンツ説明（synopsis）及びコンテンツキーワード（keyword）を含む。

　メディアタイプ（mediaType）は、例えばビデオ、音楽、書籍、写真などのコンテンツの種別を表す情報である。共通メタデータにおいては、特定の１つのメディアタイプのみを含むようにしても良いし、複数のメディアタイプをＯＲ連結した値を含むようにしても良い。図２の例では、ビデオ（video）がメディアタイプとして表されている。メディアサブタイプ（mediaSubType）は、メディアタイプ毎に定義される、より粒度の細かいコンテンツの種別を表す情報である。メディアタイプがビデオの場合は、プログラム情報、プログラムの集合を表すグループ情報、チャプター情報（プログラム内の時間軸上の１点を表す情報）、セグメンテーション情報（プログラム内の時間軸上の１区間を表す情報）、ライセンス情報などがメディアサブタイプとして挙げられる。図２の例では、プログラム情報（programInfo）がメディアサブタイプとして表されている。

　コンテンツ識別子（contentId）、コンテンツ名（name）、コンテンツ説明（synopsis）及びコンテンツキーワード（keyword）は、メディアタイプ（mediaType）及びメディアサブタイプ（mediaSubType）と共に、メディアタイプ／メディアサブタイプに依存しない共通メタデータ属性として定義されている。コンテンツ識別子（contentId）は、コンテンツを識別するための識別子である。コンテンツ名（name）は、コンテンツに付与された名称を表す。コンテンツ説明（synopsis）は、コンテンツについての概要や特徴などを表す。コンテンツキーワード（keyword）は、コンテンツに含まれるキーワードを表す。以降で説明する共通メタデータ属性は、メディアタイプがvideoであり、メディアサブタイプがprogramInfoである場合の属性であり、図２の例では、プログラム情報として、ビデオ・フォーマット（format）、年齢制限（parentalRate）、ジャンル（genre）、コンテンツ尺（duration）、公開／放送開始日時（startDate）、公開／放送終了日時（endDate）及びサムネイル画像（imagePath）が含まれる例が示されている。

　尚、共通メタデータは、ソフトウェアプログラム上の構造体やクラスといったオブジェクトであっても良いし、例えば、図３に示されるようなＸＭＬ（eXtensible　Markup　Language）形式で表現されても良い。

　また、メディアタイプがビデオの場合のプログラム情報は、上述したビデオ・フォーマット（format）、年齢制限（parentalRate）、ジャンル（genre）、コンテンツ尺（duration）、公開／放送開始日時（startDate）、公開／放送終了日時（endDate）及びサムネイル画像（imagePath）を含むものに限定されず、より多くの共通メタデータ属性で構成されていても良い。例えば、図３に示されるように、共通メタデータがＸＭＬ形式で表現される場合、当該共通メタデータを表すＸＭＬスキーマを編集することで、共通コンテンツ・メタデータを構成する共通メタデータ属性を動的に変更可能な構成となっていても良い。また、本実施の形態では、共通コンテンツ・メタデータに含まれる共通メタデータ属性をメディアタイプ／サブメディアタイプの２値によって定義する構成を採っているが、これが２値であることは必須ではなく、１値で定義しても良いし、利用するメディアタイプが、ビデオに係るプログラム情報に限定されるのであれば、メディアタイプ／サブメディアタイプによって定義されない構成もあり得る。

　図１の説明に戻る。コンテンツ視聴・スキップ履歴蓄積管理部２０２は、コンテンツ・メタデータ表示部１０１が再生したコンテンツの履歴を表す再生履歴情報や再生をスキップした履歴を表すスキップ履歴情報を記憶し、これらの情報の記憶やアクセスや削除を制御することにより、これらの情報を管理する。スキップとは、コンテンツの再生後、定義した一定時間以内にコンテンツの再生が中断された場合のことを表す。再生履歴情報及びスキップ履歴情報は、再生の対象であるコンテンツのコンテンツ識別子を含む。尚、再生履歴情報及びスキップ履歴情報を共に同一のテーブルで管理する場合には、再生履歴情報及びスキップ履歴情報は、再生履歴情報かスキップ履歴情報かを表す種別情報を更に含む。これらを別々のテーブルで管理する場合には、再生履歴情報及びスキップ履歴情報は、種別情報を含まなくても良い。また、再生履歴情報及びスキップ履歴情報は、再生対象のコンテンツを取得した先のサービスを識別するためのサービス識別子を含む。但し、メタデータ蓄積管理部２０１に記憶されたメタデータがサービス識別子を含む場合には、再生履歴情報及びスキップ履歴情報は、サービス識別子を含まなくても良い。

　図４は、再生履歴情報又はスキップ履歴情報のデータ構成を例表する図である。同図に示される視聴・スキップフラグは、再生履歴情報かスキップ履歴情報かを表す種別情報であり、イベント発生日時は、コンテンツの再生又はコンテンツ再生中のスキップが行なわれた日時を表す。

　サービス情報蓄積管理部２０３は、受信装置１００がコンテンツの検索対象とするサービスにおける検索形態と当該サービスへ接続するための接続方法（通信プロトコル、アクセスパス等）とを表すサービス情報をサービス毎に記憶し、当該サービス情報の記憶やアクセスや削除を制御することにより、当該サービス情報を管理する。検索形態を表すものとして、サービス情報は、サービスが提供する、コンテンツを検索する際にメタデータを取得するためのインタフェースの情報を含む。具体的には、サービス情報は、サービス毎に定義され、検索クエリに検索条件として指定可能なメタデータ属性を表す属性（検索条件属性）及び当該検索条件属性のとり得る値（検索条件属性値）（単位情報や、ジャンル、年齢制限、評価値等の有効値のリストなど）と、検索クエリの実行の結果としてサービスが提供可能なメタデータの記述形式であるメタデータフォーマット、メタデータの属性を表すメタデータ属性及び当該メタデータ属性値のとり得る値（メタデータ属性値）（検索条件属性と同様に、単位情報や、ジャンル、年齢制限、評価値等の有効値のリストなど）と、サービスが処理可能な検索クエリの記述形式である検索クエリフォーマットなどとを含む。検索クエリフォーマットとしては、検索条件の連結方法などの検索ルールを含んでも良い。メタデータフォーマットは、共通メタデータ属性に対応するメタデータ属性名及びメタデータ属性値を変換テーブルの形式をとっていても良いし、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔ、Ｐｙｔｈｏｎ、Ｐｅｒｌ、Ｒｕｂｙ等のスクリプト言語で解析処理自体も提供する形式をとっていても良い。また、サービス情報は、共通検索条件属性、各サービスの検索条件属性及びメタデータ属性を共通メタデータ属性へ変換するための属性変換テーブルや、サービス毎に定義された検索条件属性から共通検索条件属性へ変換するための属性値変換テーブルを含み得る。共通検索条件属性とは、受信装置１００内で表現方法を統一した検索条件属性である。このように「共通」としているのは、サービスによって異なる検索条件属性や検索条件属性値の表現を統合的に扱うためである。属性変換テーブルは、共通検索条件属性と、各サービスの検索条件属性及びメタデータ属性と、共通メタデータ属性との対応関係を表す対応テーブルであっても良いし、スクリプト言語等で記述されたプログラムであっても良い。属性値変換テーブルも同様に、サービス毎に定義された検索条件属性と共通検索条件属性との対応関係を表す対応テーブルであっても良いし、スクリプト言語等で記述されたプログラムであっても良い。これらの属性変換テーブル及び属性値変換テーブルをどのように用いるかについては後述する。

　更に、サービス情報は、各サービスを識別するためのサービス識別子、サービスの名称、サービスを表象するアイコンといった表示用の属性、受信装置１００のユーザがサービスを利用する上で入力したユーザＩＤやパスワードといった認証用の属性、サービスがサポートするコンテンツのジャンルの細分（対応ジャンル）、コンテンツの品質などの各種情報を含んでも良い。尚、サービスがコンテンツをサポートするとは、当該コンテンツ及びそのメタデータをサービスが記憶し、当該コンテンツを受信装置１００に提供可能であるということである。また、対応ジャンルの代わりに、サービスがサポートしないコンテンツのジャンルの細分をサービス情報は含んでも良い。また、サービス情報は、共通検索条件属性の一共通検索条件属性値が、当該サービス情報によってその接続方法が表されるサービスに記憶されているメタデータがその属性が表されるコンテンツの全てに該当する場合に、この共通検索条件属性及び共通検索条件属性値の対も含んでも良い。例えば、ニュースに関するコンテンツのメタデータを記憶しているサービスについては、ジャンルとして「ニュース」が暗黙的に適用できるとして、ジャンル及び「ニュース」を表すジャンルコードをサービス情報に含める。また、公開しているポータルサイトのＵＲＬといったアドレス情報や、使用するＩＰアドレスファミリ、プロトコル、プロトコルに依存する情報（使用するＨＴＴＰメソッド、ＨＴＴＰ拡張ヘッダ）もサービス情報は含み得る。また後述する検索クエリ実行履歴蓄積管理部２０５に記憶された情報から統計的に得られる、レスポンス時間の平均を表す平均レスポンス時間情報、メタデータのサイズの平均を表す平均サイズ情報、ジャンルなどの特定の検索条件を指定した際に得られるメタデータの数の平均を表す平均総数情報などの情報をサービス情報は含んでも良い。

　図５は、サービス情報のデータ構成を例示する図である。同図に示されるサービス情報は、サービスへ接続するための接続方法として、サービスパスを含む。また、複数のサービスが階層関係を有するように構成されている場合、サービス情報は、その階層関係を識別するための階層関係情報を含む。例えば親子関係のあるサービスについては、子のサービス（従属サービスという）のサービス情報は、親のサービス（親サービスという）のサービス識別子を含む。これが階層関係情報に相当する。これは、後述の第２の実施の形態で詳しく説明するように受信装置１００´が検出可能なローカルデータベースサービスが複数存在し得る場合や、同じコンテンツ配信サーバから提供されるメタデータであっても、そのメタデータフォーマットがコンテンツ配信サーバ内で統一されていないことがあり得るため、このような際にも、階層的な構成が適用可能である。具体的には、ポータルサイトのＨＴＭＬ文書としてのみメタデータを提供するサービスにおいて、カテゴリ（ジャンル）毎にレイアウトが異なる場合に、従属サービスをジャンル毎に定義することが考えられる。サービス情報蓄積管理部２０３は、実際に検索クエリを生成する際に、従属サービスを親サービスにマッピングする際に必要となる情報も付加的に管理しても良い。例えば、データベース管理システムであれば、例えば、メインのデータベースへＡｔｔａｃｈするためのデータベース名が該当する。ＷｅｂＡＰＩであれば、例えば、メインのサービス情報に含まれるルートＵＲＬ情報からの相対パス情報などが想定される。また、サービス情報は、サービス情報蓄積管理部２０３に予め記憶されるようにしても良い。又は、受信装置１００が検索対象とできるサービスのサービス情報を一元管理するサーバがネットワーク３０１上に存在し、このサーバから受信装置１００がサービス情報を適宜取得してサービス情報蓄積管理部２０３に記憶するようにしても良い。又は、取得部１０５が、各サービスに対応するコンテンツ配信サーバ４０１，４０２からサービス情報を取得してサービス情報蓄積管理部２０３に記憶するようにしても良い。

　キーワード生成・蓄積管理部２０４は、取得部１０５が取得したメタデータから抽出したキーワードを表すキーワード情報を記憶し、当該キーワード情報の記憶やアクセスや削除を制御することにより、当該キーワード情報を管理する。又は、統計情報や重み情報を付加したキーワードを受信装置１００に対して提供するインタフェースを有するサーバ（図示せず）をネットワーク３０１上に備え、当該サーバからキーワード生成・蓄積管理部２０４は、当該キーワードを表すキーワード情報を取得してこれを管理するようにしても良い。また、キーワード情報は、キーワードの抽出された日時（抽出日時）や、キーワードの含まれるコンテンツの属するジャンルを表すジャンルコードを含んでも良い。この場合、例えば、コンテンツのジャンル毎に話題のキーワードを出力したり、ある期間（たとえば最近１週間）に関心の高かったキーワードを出力したりできるようにキーワード情報を構成しても良い。例えば、ジャンル毎の話題に出現するキーワードの出現頻度を表すものが統計情報であり、関心が高いほど大きくなる重みを表すものが重み情報である。このような統計情報や重み情報と共にキーワード情報を管理することで、後述する第２生成部１０３は、ジャンルを検索条件属性に持たないサービスに対して、ジャンルによる検索を擬似的に行う場合に、該当のジャンルを含むキーワード情報をキーワード生成・蓄積管理部２０４から取得することができる。

　図６は、キーワード情報のデータ構成を例示する図である。同図に示されるように、キーワード情報は、キーワードと、当該キーワードが抽出されたコンテンツを記憶するサービスのサービス名称と、共通検索条件属性と、共通検索条件属性値とを含む。同図においては、共通検索条件属性として、例えば、「ジャンル」を含み、共通検索条件属性値として、ジャンルコードとして「スポーツ」を表すものが含まれている。

　検索クエリ実行履歴蓄積管理部２０５は、取得部１０５が検索クエリを実行した結果を表す実行結果情報を記憶し、当該実行結果情報の記憶やアクセスや削除を制御することにより、当該実行結果情報を管理する。実行結果情報とは、例えば、検索クエリを実行してからメタデータをレスポンスとして受信するまでのレイテンシ（レスポンス時間）や、受信されるメタデータの件数などの情報を含む。さらに、検索クエリ実行履歴蓄積管理部２０５は、実行履歴情報から統計情報を取得し、当該統計情報を用いて、検索クエリを実行した対象のサービスの属性情報を抽出し、これをサービス情報としてサービス情報蓄積管理部２０３に記憶させる。統計情報とは、例えば、検索クエリを実行してからメタデータをレスポンスとして受信するまでの平均応答時間や、検索クエリによって表される検索条件に合致するコンテンツのサービス毎の保有件数などである。サービスの属性情報とは、例えば、あるサービスが、特定のジャンルに属するコンテンツのみを保有している又は特定のジャンルに属するコンテンツを保有していないといった情報である。

　図７は、実行結果情報のデータ構成を例示する図である。同図に示されるように、実行結果情報は、メタデータの取得件数と、共通検索条件属性と、共通検索条件属性値と、レスポンス時間と、検索クエリが実行された日時（実行日時）とを含む。同図においては、検索クエリの実行の際に、共通検索条件属性として、例えば、「ジャンル」が指定され、共通検索条件属性値として、ジャンルの細分として「スポーツ」を表すジャンルコードが指定されたことが示されている。

　コンテンツ・メタデータ表示部属性情報蓄積管理部２０６は、コンテンツ・メタデータ表示部１０１がコンテンツやメタデータを表示部に表示させる際の表示に関する属性情報（表示属性情報という）を記憶し、当該表示属性情報の記憶やアクセスや削除を制御することにより、当該表示属性情報を管理する。表示属性情報は、画面のサイズを表す画面サイズ情報、アスペクト比を表すアスペクト比情報及び表示部に表示可能なコンテンツのフォーマットを表すフォーマット情報を含む。また、コンテンツ・メタデータ表示部１０１がユーザ毎に表示を制御する機能を有する場合には、表示属性情報は、年齢制限を表す年齢制限情報など、ユーザ毎の表示制御に関する情報を含んでも良い。

　コンテンツ・メタデータ表示部１０１は、第１生成部１０１ａを有し、表示部における情報の表示を制御したり、操作入力部を介してユーザから入力される操作入力を制御信号として処理したりするＧＵＩ（Graphical　User　Interface）を提供する。具体的には、コンテンツ・メタデータ表示部１０１は、メタデータを表示部に表示させたり、操作入力部を介してユーザからの操作入力を受け付け、当該操作入力に応じて選択したコンテンツを同定し、当該コンテンツを表示部に表示させることにより当該コンテンツを再生したりする。更に、コンテンツ・メタデータ表示部１０１は、再生したコンテンツの履歴を表す再生履歴情報又は再生をスキップした履歴を表すスキップ履歴情報を、その操作履歴と共にコンテンツ視聴・スキップ履歴蓄積管理部２０２に記憶させる。また、コンテンツ・メタデータ表示部１０１は、ユーザが共通検索クエリを明示的に生成するための画面を生成してこれを表示部に表示させる。共通検索クエリとは、ユーザが所望するコンテンツを検索するための１つ以上の共通検索条件を表すものであり、受信装置１００内で表現方法を統一した検索クエリである。「共通」としているのは、上述したように、サービスによって異なる検索条件属性や検索条件属性値の表現を、統合的に扱うためである。

　図８は、検索条件を指定するための画面を例示する図である。同図に示される画面においては、ユーザは操作入力部を介して、検索条件として、検索対象のサービスや、検索対象のコンテンツのジャンルを表すジャンルコードや、キーワードや、公開日時（公開／放送開始日時又は公開／放送終了日時）や、コンテンツの長さ（コンテンツ尺）や、並び換え（整列条件）を指定可能である。整列条件とは、検索の結果得られるメタデータを整列させるための処理条件であり、共通メタデータ属性全てに対して、昇順及び降順で指定できるものであって良い。例えば、タイトル、ジャンル、終了日時、コンテンツ尺、視聴回数、評価値などにより整列させることができる。このように、指定される検索条件には、整列条件など各種処理条件が含まれ得る。

　コンテンツ・メタデータ表示部１０１の有する第１生成部１０１ａは、ユーザの操作入力に応じて、再生中のコンテンツに関係するコンテンツを検索するための検索条件や、図８に示される画面において、ユーザが明示的に指定した検索条件を含む共通検索クエリを生成してこれを選択部１０２又は第２生成部１０３に対して出力する。

　ここで、共通検索クエリのデータ構成について図９を用いて説明する。同図に示されるように、共通検索クエリは、メディアタイプ（mediaType）、メディアサブタイプ（mediaSubType）、取得対象の共通メタデータ属性の名称（取得対象メタデータ属性名）（requestField）、取得範囲（取得開始インデックス（index）及び取得件数（count））、ソートキー（sortKey）、ソート順序（sortOrder）、及び共通検索条件リスト（predicateBag）を含む。取得対象メタデータ属性名（requestField）は、リスト形式で表され、例えば、図９の例では、name、synopsis、genre及びimagePathの４値がリストアップされている。これは、メディアタイプがvideoである場合のプログラム情報（video.programInfo）のメタデータ属性として、コンテンツ名（タイトル）、概要説明、ジャンル及びサムネイル画像のみを取得することを意味する。ソートキー（sortKey）は、整列条件として、整列に利用する共通メタデータ属性名である。ソート順序（sortOrder）は、整列条件として、どの順に整列するのかを表す。図９の例では、ソート順序が降順（DESC）、即ち、新着順であり、ソートキーは、共通メタデータ属性の公開／放送開始日時（startDate）であることが指定されていることが示されている。共通検索条件リスト（predicateBag）は、図９の例では、共通検索条件のＯＲ集合のリストという形式で表現され、複数の共通検索条件の関係が論理式で表現されている。この共通検索条件リスト（predicateBag）を構成する共通検索条件（predicate）は、共通検索条件属性名（key）、オペレーション（operation）及び共通検索条件属性値（value）の３値で構成される。共通検索条件属性名には、共通メタデータ属性名が指定される。オペレーションは、“＝”、“！＝”、“＜”、“＜＝”、“＞”、“＞＝”などの不等号によって共通検索条件属性名と共通検索条件属性値との関係を表すものである。オペレーションには、不等号だけでなくＳＱＬのように部分一致を表す“ＬＩＫＥ”のような予約語を定義しても良い。

　例えば、共通検索条件リスト（predicateBag）と、共通検索条件リスト（predicateBag）に含まれる共通検索条件（predicate）に、図１０に示されるような値が設定されているとする。この例では、共通検索条件属性名(key)として、ジャンルである“genre”が指定され、この共通検索条件属性値（value）として、ニュース／報道を表す共通ジャンルコード(“0x01010222”)が指定されている。尚、受信装置１００内で表現方法を統一したジャンルコードを共通ジャンルコードという。また、共通検索条件属性名(key)として、キーワードである“keyword”が指定され、この共通検索条件属性値（value）として、“大リーグ”及び“日本人選手”が指定されている。このような共通検索条件の意味するところは、以下の通りである。ジャンルがニュースかスポーツであり、かつ、キーワードに“大リーグ”かつ“日本人選手”を含むコンテンツを検索するという意味である。このような共通検索条件を論理式で表すと、例えば、図１１のように表される。

　尚、本実施の形態では、共通検索条件リスト（predicateBag）を、共通検索条件のＯＲ集合のリストという形式で表現し、各ＯＲ集合間をＡＮＤ連結する構成を採っているが、共通検索クエリの構成としては、この構成に限定されるものではなく、ＳＱＬのように、ＡＮＤ集合やＯＲ集合を多段に組み合わせることが可能な、つまり、より柔軟な論理表現可能な構成を採っても良い。また、上述のジャンルコードのように、列挙体として表現可能な一定数のデータセットを値として採り得る共通検索条件属性については、共通のコードセットを定義しても良い。

　図１の説明に戻る。選択部１０２は、コンテンツ・メタデータ表示部１０１が提供するＧＵＩ（例えば図８に示される画面）を介して生成した共通検索クエリを取得し、サービス情報蓄積管理部２０３に記憶されるサービス情報を参照して、当該共通検索クエリによって表される共通検索条件属性としてジャンルが含まれる場合、当該共通検索条件属性値（ここでは共通ジャンルコードである）に相当する対応ジャンルを含むサービス情報を有するサービスを選択する。例えば、共通検索クエリに、共通検索条件属性として「Genre」が含まれ、当該共通検索条件属性の共通検索条件属性値として「ニュース／報道」が含まれている場合、選択部１０２は、図３に示されるサービス情報に含まれる対応ジャンルを参照して、当該対応ジャンルの１つに当該共通検索条件属性値に相当するジャンルの細分が含まれていれば、このサービス情報のサービスを検索対象として選択し、当該対応ジャンルの１つに当該共通検索条件属性値に相当するジャンルの細分が含まれていなければ、このサービス情報のサービスを検索対象として選択しない。また、選択部１０２は、当該共通検索クエリによって表される共通検索条件属性としてジャンルが含まれない場合、検索対象のサービスを選択しない。このように、選択部１０２が、検索対象のサービスを１つも選択できない場合も有り得る。

　また、選択部１０２は、コンテンツ・メタデータ表示部１０１が表示部に表示させているコンテンツについて、当該コンテンツのメタデータからキーワードを抽出して当該キーワードやジャンル等の共通検索条件属性を組み合わせて共通検索クエリを生成し、サービス情報蓄積管理部２０３に記憶されるサービス情報を参照して、共通検索条件属性のうち「Genre」に対する共通検索条件属性値である共通ジャンルコードのうち少なくも１つに相当する、ジャンルの細分を対応ジャンルとして含むサービス情報を有するサービスを選択する。共通検索クエリの生成は、操作入力部を介したユーザからの操作入力を契機としても良いし、なんらかのタイミングを契機としても良い。尚、選択部１０２が選択するサービスは、複数であっても良く、共通検索条件属性値との合致度やサービスの利用頻度から、選択したサービスに重み付けを行い、優先度情報を付与しても良い。ここでいう合致度とは、例えば、共通検索条件属性値として含まれる共通ジャンルコード、ビデオ・フォーマット、平均コンテンツ尺情報、あるいは有料サービスの場合には価格帯情報など、複数の共通条件属性値の単純な合致数で決定されるものであっても良いし、あるいは、合致の程度を算出（単純には上述した平均コンテンツ尺情報や、価格帯情報との差分を算出）することで決定されるものであっても良い。サービスの利用頻度の算出には、コンテンツ視聴・スキップ履歴蓄積管理部２０２に記憶された再生履歴情報やスキップ履歴情報を利用する。また、選択されるサービス数に上限を設け、この上限の数以上が選択されないようにしても良い。この場合、サービスの選択を、上述の優先度情報に基づいて行っても良い。選択したサービスのサービス情報は、共通検索クエリに一検索条件として追加しても良いし、共通検索クエリとは別に扱っても良い。

　第２生成部１０３は、コンテンツ・メタデータ表示部１０１が出力した共通検索クエリを、選択部１０２を介して取得し、これを用いて、検索対象のサービス毎の検索クエリを生成する。このとき、第２生成部１０３は、共通検索クエリを、共通検索条件の和積による論理式で表現し、データベース管理システムに関連付けられたサービスに対して検索クエリを生成する場合には、この論理式表現をそのままＳＱＬ文の制約句として利用しても良い。また、サービスとして、コンテンツ配信サーバ４０１，４０２がＷｅｂＡＰＩなどで一般的な簡易検索機能を提供している場合、第２生成部１０３は、上述の和積による論理式を積和系に展開し、各積項に検索クエリを生成するようにしても良い。尚、検索対象のサービスとしては、選択部１０２がサービスを選択できた場合には、選択されたサービスが検索対象のサービスとなる。しかし、選択部１０２がサービスを選択できなかった場合や、共通検索クエリをコンテンツ・メタデータ表示部１０１から直接取得した場合は、第２生成部１０３は、サービス情報蓄積管理部２０３にそのサービス情報が記憶されている全てのサービスに対して検索クエリを生成しても良いし、ランダムに所定の数のサービスを選択し、選択した各サービスに対して検索クエリを生成しても良いし、コンテンツ視聴・スキップ履歴蓄積管理部２０２に記憶された再生履歴情報やスキップ履歴情報を用いて求められる、サービスの利用頻度を用いてサービスを選択し、選択した各サービスに対して検索クエリを生成しても良いし、操作入力部を介してユーザが検索対象として選択する操作入力を行なったサービスを選択し、選択した各サービスに対して検索クエリを生成しても良い。第２生成部１０３は、検索クエリの生成の際に、共通検索条件属性と検索条件属性との対応関係を表す属性変換テーブル及び共通検索条件属性値と検索条件属性値との対応関係を表す検索条件属性値属性値変換テーブルを用いて、サービス情報に含まれる検索クエリフォーマットに応じた検索クエリを共通検索クエリから生成することにより、共通検索クエリを、サービスの検索形態に応じた検索クエリに変換する。

　ここで属性変換テーブル及び属性値変換テーブルを用いた変換の方法について説明する。図１２は、属性変換テーブル及び属性値変換テーブルを統合的に構成した場合の構成を例示する図である。同図においては、(a)が属性変換テーブルを表し、(b)が属性値変換テーブルを表している。尚、共通メタデータのデータ構成は図２に示されるものであり、共通検索クエリのデータ構成は図９に例示したものであり、サービス情報のデータ構成は図５に例示したものであるとする。図１３は、共通検索条件リスト（predicateBag）に示される共通検索条件を例示する図である。第２生成部１０３は、図１３に示される共通検索条件について、サービス情報に含まれる検索条件属性及び図１２の(a)に表される属性変換テーブルに基づいて、“genre”を“Category”に変換し、“keyword”を“VQ”に変換する。また、第２生成部１０３は、サービス情報に含まれる検索条件属性値及び図１２の(b)に表される属性値変換テーブルに基づいて、ニュース／報道を表す共通ジャンルコード(“0x01010222”)を“News”という文字列に変換する。そして、第２生成部１０３は、図１４に示されるような検索クエリを生成する。

　尚、共通検索条件として指定された共通ジャンルコードに対応する検索条件属性値が当該サービスにおいて存在しない場合、当該共通ジャンルコードを検索条件として含めないようにしたり、共通ジャンルコードに相当する文字列を表すキーワードにより代替したりする方法が考えられる。例えば、ジャンルにより検索を行なう例として、図１５に示されるような共通検索条件があり、スポーツ／野球を表す共通ジャンルコード(“0x0102333”)　に対応する検索条件属性値が存在しないものとする。この場合、第２生成部１０３は、図１２の(b)に表される属性値変換テーブルに基づいて、スポーツ／野球を表す共通ジャンルコード(“0x0102333”)に対応する検索属性名及び検索属性値を取得して、この例では、”VQ”及び“野球　OR　baseball”に変換する。つまり、共通ジャンルコードによる検索をキーワードによる検索へと代替して、第２生成部１０３は、図１６に示されるような検索クエリを生成する。

　また、共通ジャンルコードに対応する検索条件属性名及び検索条件属性値が存在しない場合も有り得る。例えば、音楽を表す共通ジャンルコード(“0x01030222”)については、代替するキーワードが存在しないため、図１２の(b)に示される属性値変換テーブルでは、対応する検索条件属性名及び検索条件属性値が存在しないことを表す空値で表現されている。この場合は、第２生成部１０３は、当該共通ジャンルコードを用いて検索クエリが生成できない旨を表すメッセージを表示部に表示させることによりユーザに報知するようにしても良いし、上述したキーワード生成・蓄積管理部２０４が記憶しているキーワード情報によって示されるキーワードのうち、当該検索条件属性と合致するキーワードを検索して、該当のキーワードがあれば、当該キーワードを用いてキーワードによる一般的な検索を行うようにしても良い。また、共通検索クエリに含まれる共通検索条件属性に該当する検索条件属性が、複数の検索クエリに分割することで、指定された元の共通検索条件を満たすことができるならば、第２生成部１０３は、共通検索クエリから複数の検索クエリを生成しても良い。

　実行制御部１０４は、第２生成部１０３が生成した１つ以上の検索クエリの実行順序を決定する。このとき、実行制御部１０４は、検索クエリに適用されている検索条件の数によって実行順序を決定しても良いし、コンテンツ視聴・スキップ履歴蓄積管理部２０２に記憶された再生履歴情報やスキップ履歴情報を用いて求められる、サービスの利用頻度を用いて実行順序を決定しても良い。又は、実行制御部１０４は、検索クエリ実行履歴蓄積管理部２０５に記憶された実行履歴情報を用いて求められるレスポンス時間で実行順序を決定しても良いし、キーワード生成・蓄積管理部２０４に記憶されるキーワード情報に付加された重み情報や統計情報を用いて実行順序を決定しても良い。その他、受信装置１００の内蔵のデータベース管理システムに関連付けられたサービスを最優先で検索するなど、より静的に定めた実行順序ポリシーに基づいて、実行制御部１０４は、実際の実行順序を決定しても良い。

　取得部１０５は、実行制御部１０４が実行順序を決定した検索クエリをコンテンツ配信サーバ４０１，４０２に送信して検索クエリを実行させ、当該検索クエリの実行結果取得されたメタデータをコンテンツ配信サーバ４０１，４０２から受信し、当該メタデータに対して解析処理を適宜行って、共通メタデータを取得する。このとき、取得部１０５は、検索クエリに含まれる全部又は一部の情報と、受信したメタデータの件数（取得件数）とを含む上述の実行結果情報を検索クエリ実行履歴蓄積管理部２０５に記憶させる。また、取得部１０５は、受信したメタデータを形態素解析などにより解析して、キーワードを抽出し、当該キーワードを表すと共に、メタデータの取得時に指定された検索条件や、サービス情報を参照するために必要な検索対象のサービスのサービス識別子を含むキーワード情報をキーワード生成・蓄積管理部２０４に記憶させる。

　以上のようにして取得されたメタデータによってその属性が表されるコンテンツが、検索条件に合致するコンテンツである。即ち、各サービスにおいて検索クエリが実行されてメタデータが取得されることにより、検索条件に合致するコンテンツが検索されたことになる。

　次に、本実施の形態にかかる受信装置１００の行うメタデータ取得処理の手順について図１７を用いて説明する。受信装置１００は既に起動されており、通信部１０６を介してネットワーク３０１上のコンテンツ配信サーバ４０１，４０２と通信可能な状態になっていることを前提とする。まず、受信装置１００のコンテンツ・メタデータ表示部１０１が、何らかのコンテンツを表示部に表示させており、コンテンツを再生しているものとする。ここで、例えば、ユーザが操作入力部を介してコンテンツを検索する操作入力を行うと、当該操作入力に応じたコンテンツ検索要求メッセージが、受信装置１００に対して送信される（ステップＳ１０１）。このとき、コンテンツ検索要求メッセージは、具体的な検索条件を含まず、単に「再生中のコンテンツに関係するコンテンツを検索することを要求する」ことのみを表すものであっても良いし、キーワードやジャンルコード等の検索条件を指定する操作入力が行われた場合、当該検索条件を含むものであっても良い。また、図８に示す画面が受信装置１００の表示部に表示されており、ユーザは、この画面で操作入力部を介して検索条件を指定する操作入力を行うようにしても良い。

　受信装置１００のコンテンツ・メタデータ表示部１０１は、コンテンツ検索要求メッセージを受信すると、当該コンテンツ検索要求メッセージが「再生中のコンテンツに関係するコンテンツを検索することを要求する」ことのみを表す場合、メタデータ蓄積管理部２０１から、再生中のコンテンツに対応するメタデータを取得し（ステップＳ１０２）、これを用いて共通検索クエリを生成する（ステップＳ１０３）。なお、コンテンツ検索要求メッセージに検索条件が明示的に含まれる場合には、受信装置１００は、当該検索条件を用いて共通検索クエリを生成する。

　続いて、コンテンツ・メタデータ表示部１０１は、ステップＳ１０３で生成した共通検索クエリを選択部１０２へ出力する（ステップＳ１０４）。このときの共通検索クエリは、例えば、２つのジャンル（Ｇ１、Ｇ２）、２つのキーワード（Ｋ１、Ｋ２）及び２つのクレジット（Ｃ１、Ｃ２）が検索条件として、以下の式１のように論理式として表現されているものとする。共通検索クエリの論理式を検索式という。なお、クレジットは、ここでは出演者、監督、スタッフなど関係者情報を意味するものである。
検索式：＝（Ｇ１＋Ｇ２）＊（Ｋ１＋Ｋ２）＊（Ｃ１＋Ｃ２）…式１

　この検索式は、メタデータ属性が同じものを暗黙的にＯＲ連結し、メタデータ属性が異なるＯＲ集合間を、ＡＮＤ連結することで生成している。しかし、検索式の生成方法は、これに限るものではない。例えば、全ての検索条件属性をＡＮＤ連結しても良いし、全ての検索条件属性をＯＲ連結しても良い。さらに言えば、これら複数の検索式のバリエーションを含んでも構わない。例えば、全ての検索条件をＡＮＤ連結する場合、検索式は、再生中のコンテンツと非常に類似度の高いコンテンツを検索の対象とした厳しい検索条件であり、ヒットする件数が少ないことが予想される。一方、全ての検索条件をＯＲ連結する場合は、１つの検索条件が合致しさえすれば良いので、検索条件としては緩く、このため多くのコンテンツがヒットする可能性が高い。上述の検索式が採っている生成方法は、これらの中間的な位置づけのものである。

　次に、選択部１０２は、ステップＳ１０４で出力された共通検索クエリを入力として、検索対象となるサービスを選択する。具体的には、例えば検索条件として指定されているジャンル（Ｇ１）が、ジャンルコードによって「ニュース／報道」が指定されている場合、選択部１０２は、ニュースに係るコンテンツを提供するサービスを選択する処理を行う。これは、選択部１０２が、サービス情報蓄積管理部２０３から、サービス属性としてジャンルコード：Ｇ１を含むサービス情報を取得することで実現される。また、選択部１０２は、コンテンツ視聴・スキップ履歴蓄積管理部２０２に記憶された再生履歴情報やスキップ履歴情報を用いて、検索対象となるサービスを選択しても良い。例えば、選択部１０２は、利用頻度の高いサービス、即ち、再生されたことが再生履歴情報やスキップ履歴情報によって示されるコンテンツを提供したサービスのうち、提供したコンテンツの数が所定の数以上であるサービスを、検索対象となるサービスとして選択する。

　ここでは、選択部１０２は、サービス属性としてジャンルコード：Ｇ１を含むサービス情報をサービス情報蓄積管理部２０３から取得し（ステップＳ１０５）、当該サービス情報によって特定されるサービスとしてコンテンツ配信サーバ４０１（以下、サービスＳ１とする）を検索対象のサービスとして選択し、コンテンツ視聴・スキップ履歴蓄積管理部２０２に記憶された再生履歴情報やスキップ履歴情報を用いて、検索対象のサービスとしてコンテンツ配信サーバ４０２（以下、サービスＳ２とする）を選択し（図１７においては省略）、更に、ローカルデータベースサービスであるメタデータ蓄積管理部２０１（以下、サービスＳ３とする）を検索対象のサービスとして選択する。このとき、ローカルデータベースサービスの選択は、暗黙的に必ず指定されるものとしても良いし、メタデータのキャッシュ状況を鑑みて、受信装置１００によって自動選択されるものであっても良い。そして、選択部１０２は、選択したサービスをサービス条件として上述の式１の検索式に追加して以下の式２のように更新する（ステップＳ１０６）。この検索式が共通検索クエリに相当する。
検索式：＝（Ｓ１＋Ｓ２＋Ｓ３）＊（Ｇ１＋Ｇ２）＊（Ｋ１＋Ｋ２）＊（Ｃ１＋Ｃ２）…式２

　次に、選択部１０２は、第２生成部１０３へ、検索対象として選択したサービスのサービス情報と共に共通検索クエリを出力する（ステップＳ１０７）。第２生成部１０３は、ステップＳ１０７で出力された、式２の検索式で表される共通検索クエリとサービス情報とを用いて、サービス毎の検索クエリへ展開する。ここでは、第２生成部１０３は、サービス情報によって表される検索クエリフォーマットが、論理式での記述が可能であることを表す場合、式２の検索式である論理式で表現される検索クエリを共通検索クエリから生成し、検索クエリフォーマットが、論理式での記述が可能でないことを表す場合、論理式を積項展開し、各積項を用いて、複数の検索クエリを共通検索クエリから生成する。例えば、コンテンツ配信サーバ４０１がＲＥＳＴ形式のＷｅｂＡＰＩをベースとしたＵＲＬを利用した検索条件の指定のみを許容しており、コンテンツ配信サーバ４０２がＳＯＡＰ形式のＷｅｂＡＰＩをベースとしたＨＴＴＰリクエストボディへの論理表現を許容しない検索条件の指定のみを許容している場合、サービスＳ１，Ｓ２については、選択部１０２は、式２の検索式を積項展開して検索クエリの生成に利用する。一方、サービスＳ３については、選択部１０２は、式２の検索式をそのまま制約句として利用しての検索クエリの生成を試みる。共通検索クエリからのサービス毎の展開結果の例は以下の通りである。
ＷｅｂＡＰＩベースのコンテンツ配信サーバ４０１に対する検索クエリ（Ｓ１）
（Ｓ１＊Ｇ１＊Ｋ１＊Ｃ１）
（Ｓ１＊Ｇ１＊Ｋ１＊Ｃ２）
（Ｓ１＊Ｇ１＊Ｋ２＊Ｃ１）
（Ｓ１＊Ｇ１＊Ｋ２＊Ｃ２）
・・・
ＷｅｂＡＰＩベースのコンテンツ配信サーバ４０２に対する検索クエリ（Ｓ２）
（Ｓ２＊Ｇ１＊Ｋ１＊Ｃ１）
（Ｓ２＊Ｇ１＊Ｋ１＊Ｃ２）
（Ｓ２＊Ｇ１＊Ｋ２＊Ｃ１）
（Ｓ２＊Ｇ１＊Ｋ２＊Ｃ２）
・・・
ＳＱＬベースのローカルデータベースサービス（メタデータ蓄積管理部２０１）に対する検索クエリ（Ｓ３）
（Ｓ３）＊（Ｇ１＋Ｇ２）＊（Ｋ１＋Ｋ２）＊（Ｃ１＋Ｃ２）

　続いて、第２生成部１０３は、積項展開したサービスＳ１，Ｓ２それぞれに対応するサービス情報をサービス情報蓄積管理部２０３から取得して（ステップＳ１０８）、サービスＳ１，Ｓ２に係る共通検索条件を、サービス毎の検索クエリへ変換する。このとき、サービスＳ１は、ジャンルコード：Ｇ１を暗黙的にサービス属性として有しているので、実際に検索クエリに適用する検索条件は、上記の先頭の例では（Ｋ１＊Ｃ１）となる。第２生成部１０３は、この２つの検索条件を利用して、対応するコンテンツ配信サーバ４０１へ送信する検索クエリを生成する（ステップＳ１０９）。サービスＳ１であるコンテンツ配信サーバ４０１がクレジット情報(Ｃ１)を検索条件として指定できる場合には、第２生成部１０３は、上述の展開結果から、例えば、以下のような検索クエリを生成する。
http://s1.example.com/search_api?keyword=キーワード１&credit=人物１

　コンテンツ配信サーバ４０１がクレジット情報(Ｃ１)を検索条件として指定できない場合には、クレジット情報をキーワードとみなして、第２生成部１０３は、上述の展開結果から、例えば、以下のような検索クエリを生成する。
http://s1.example.com/search_api?keyword=”キーワード１　人物１”

　又は、コンテンツ配信サーバ４０１がＡＮＤ検索をサポートしていない場合には、第２生成部１０３は、上述の展開結果から、例えば、以下のような２つの検索クエリに分割して生成するようにしても良い。
http://s1.example.com/search_api?keyword=”キーワード１”
http://s1.example.com/search_api?keyword=”人物名１”

　本実施の形態では検索条件としてジャンル、キーワード、クレジットに絞って説明しているが、検索クエリの実行結果であるメタデータの取得件数を含める場合にも、上例と同様に検索クエリを分割した展開を実施する必要がある。具体的には、検索クエリの実行結果であるメタデータの取得件数が５０件に暗黙的に設定されている場合に、サービスによっては、５０件より少ない件数での取得しかサポートしていない場合がある。このとき、例えば、サービスＳ１が、取得件数の上限を２５件と規定していて、検索クエリの実行の結果取得したメタデータのオフセットをfromで指定し、件数をcountで指定するインタフェースを提供している場合には、第２生成部１０３は、以下のような２つの検索クエリに分割して生成することになる。
http://s1.example.com/search_api?keyword=”キーワード１　人物１”&from=1&count=25
http://s1.example.com/search_api?keyword=”キーワード１　人物１”&from=26&count=25

サービスＳ１に対して検索クエリを生成する方法として、ここでは３通りの方法を記載したが、これらの方法に限定されるものではない。こうした共通検索条件に該当する検索条件を持たない場合に検索クエリを展開する方法についても、サービス情報に含まれていても良い。一方、利用頻度によって選択されたサービスＳ２については、ジャンルが検索条件として暗黙的に適用されず、前述した共通検索クエリの展開結果の、サービスＳ２に係る先頭の例では、（Ｇ１＊Ｋ１＊Ｃ１）が、実際に検索クエリに適用される検索条件となる。サービスＳ２が、検索条件属性としてジャンルを有している場合、第２生成部１０３は、共通検索クエリを、例えば以下のようなＳＯＡＰメッセージに展開する。
<soap:Envelope　xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
　　<soap:Header>
　　
　　</soap:Header>
　　<soap:Body>
　　　　<m:getContentMetadata　xmlns:m="http://s2.example.com/searchAPI/">
　　　　　　<m:genre>G1</m:genre>
　　　　　　<m:keyword>キーワード１</m:keyword>
　　　　　　<m:credit>人物１</m:credit>
　　　　</m:ContentMetadata>
　　</soap:Body>
</soap:Envelope>

　上の例では、ジャンルコードの付与体系がサービスＳ１と共通検索クエリとで共用できていることを前提としていたが、サービスＳ２が独自のジャンルコードの体系を有する場合、サービスＳ２のサービス情報には、ジャンルコード：Ｇ１、Ｇ２といった共通ジャンルコードを、サービスＳ２の体系におけるジャンルコードへ変換するための変換テーブル情報が含まれている。第２生成部１０３は、サービス情報蓄積管理部２０３に記憶されたサービス情報に含まれる変換テーブル情報を用いて、共通の体系におけるジャンルコードをサービスＳ２独自の体系のジャンルコードへ変換し、これを用いて検索クエリを生成する。たとえば、Ｇ１（ニュース／報道）に対応するサービスＳ２のジャンルコードが「Ｎｅｗｓ」という文字列で表現されるものである場合、第２生成部１０３が展開する検索クエリは以下のようになる（ＳＯＡＰのＢｏｄｙエレメントのみ抜粋）。
　　　　<m:getContentMetadata　xmlns:m="http://s2.example.com/searchAPI/">
　　　　　　<m:genre>News</m:genre>
　　　　　　<m:keyword>キーワード１</m:keyword>
　　　　　　<m:credit>人物１</m:credit>
　　　　</m:ContentMetadata>

　更に別のバリエーションとして、サービスＳ２がジャンルを検索条件属性に持たない場合には、第２生成部１０３は、キーワード生成・蓄積管理部２０４に記憶されているキーワード情報を利用して、ジャンルコードをキーワード群に展開する。具体的には、キーワード生成・蓄積管理部２０４は、取得部１０５が取得したメタデータから形態素解析などで抽出したキーワードを表すと共に、メタデータの取得時に指定された検索条件や、サービス情報を参照するために必要な検索対象のサービスのサービス識別子を含むキーワード情報を記憶する。これにより、ジャンルを検索条件属性にもつキーワード情報を求めることができ、かつ、ある期間における出現頻度も併せて求めることができる。具体的には、「ニュース／報道」のジャンルに含まれる最近の出現頻度の高いキーワード（たとえば、最近注目されている政治家の名前や、最近起こった事件の名前、容疑者の名前など）を抽出できる。第２生成部１０３は、サービスＳ２が、検索条件としてジャンルを指定できない場合に、ジャンルコードをキーとして、キーワード生成・蓄積管理部２０４に記憶されたキーワード情報及びサービス情報蓄積管理部２０３に記憶されたサービス情報を用いて、ジャンルの代替となるキーワードのリストである代替キーワードリストを生成する。たとえば、ここでは、ジャンルの代替となるキーワードとして“ニュースキーワードＡ”、“ニュースキーワードＢ”、“ニュースキーワードＣ”が取得できたとすると、第２生成部１０３は、これを用いて以下のＳＯＡＰメッセージを生成する（ＳＯＡＰのＢｏｄｙエレメントのみ抜粋）。
　　　　<m:getContentMetadata　xmlns:m="http://s2.example.com/searchAPI/">
　　　　　　<m:keyword>ニュースキーワードＡ　OR　ニュースキーワードＢ　OR　ニュースキーワードＣ</m:keyword>
　　　　　　<m:credit>人物名</m:credit>
　　　　</m:getContentMetadata>

　なお、この例では、サービスＳ２のＯＲ検索が“ＯＲ”文字列を明示的にキーワード間に指定することで実現できるものとしている。こうした検索ルールは検索クエリのフォーマットとしてサービス情報の一部に含まれている。

　また、本実施の形態においては、サービスＳ１を一般的なＲＥＳＴ形式のＷｅｂＡＰＩとし、サービスＳ２を一般的なＳＯＡＰ形式のＷｅｂＡＰＩとして、ＵＲＬに検索クエリ情報を含める場合の具体例を記しているが、例えば、ＷｅｂＡＰＩとしてもＳＱＬ形式での検索インタフェースを提供するものが存在する。本実施の形態においては、このようなサービスについても、ローカルデータベースサービスに対する検索クエリの生成と同様にして、サポートすることができる。

　ローカルデータベースサービスであるサービスＳ３に対する検索クエリについては、第２生成部１０３は、上述の共通検索クエリの展開結果（（Ｓ３）＊（Ｇ１＋Ｇ２）＊（Ｋ１＋Ｋ２）＊（Ｃ１＋Ｃ２））と、選択されたサービス情報とを用いて、「Ｓ３」を「Ｓ１＋Ｓ２」に置換し、結果として得られた（（Ｓ１＋Ｓ２）＊（Ｇ１＋Ｇ２）＊（Ｋ１＋Ｋ２）＊（Ｃ１＋Ｃ２））から、ＳＱＬ文を生成する。最も単純には、以下のようなＳＱＬ文が生成される。
select　*　from　content_metadata_table　
where　(service=’S1’　or　service=’S2’)　and　
　　　　　　(genre=’G1’　or　genre=’G2’)　and
　　　　　　(keyword=’K1’　or　keyword=’K2’)　and
(credit=’C1’　or　credit=’C2’)

　上のＳＱＬ文では、keyword,　creditが完全一致する制約句になっているが、これを部分一致に変更したり、タイトルや概要説明のカラムをキーワードによる検索の範囲に加えたりしても構わない。これは、形態素解析などの処理をメタデータに対して施していない場合には、コンテンツ配信サーバから提供されているキーワードが不十分である場合が多いために必要となる展開方法である。この場合、例えば、以下のようなＳＱＬ文となる。
select　*　from　content_metadata_table　
where　(service=’S1’　or　service=’S2’)　and　
　　　　　　(genre=’G1’　or　genre=’G2’)　and
　　　　　　(keyword=’K1’　or　keyword=’K2’　or　title　like　‘%K1%’　or　title　like　‘%K2%’
or　synopsis　like　‘%K1%’　or　synopsis　like　‘%K2%’)　and
(credit=’C1’　or　credit=’C2’)

　上述したように、共通検索クエリが、全ての検索条件をＡＮＤ連結した検索式などの複数のバリエーションを含む場合、第２生成部１０３は、それぞれを同様に、サービス毎の検索クエリに展開する。

　続いて、第２生成部１０３は、生成した検索クエリのリストを実行制御部１０４へ出力する（ステップＳ１１０）。実行制御部１０４は、ステップＳ１１０で出力された複数の検索クエリの実行順序を決定する（ステップＳ１１１）。実行順序の決定には、例えば、適用される検索条件数の多いものを優先して実行順序を上げる方法が適用できる。全ての検索条件をＡＮＤ連結した場合、「再生中のコンテンツに関連するもの」を検索する際には、検索結果が少ないが、類似度が最も高いメタデータが得られることになる。又は、コンテンツ視聴・スキップ履歴蓄積管理部２０２に記憶された再生履歴情報やスキップ履歴情報を用いて、利用頻度の高いサービス対する検索を優先して実行順序を上げる方法を適用しても良い。又は、検索クエリ実行履歴蓄積管理部２０５に記憶された実行結果情報から、平均レスポンス時間や、取得できるメタデータの平均数を取得し、これを優先度として利用し、優先度が高いほど実行順序が上がるように、実行順序を決定する方法を適用するようにしても良い。本実施の形態では、実行制御部１０４は、適用される検索条件数に基づき、実行順序を決定する。そして、実行制御部１０４は、決定した実行順序に従い、検索クエリを取得部１０５に逐次出力していく（ステップＳ１１２）。又は、実行制御部１０４は、決定した実行順序を表す実行順序情報を付与した検索クエリのリストを一括で出力するようにしても良い。

　取得部１０５は、ステップＳ１１２で出力された検索クエリを逐次実行していく。具体的には、サービスＳ３に対応するローカルデータベース（メタデータ蓄積管理部２０１）、サービスＳ１に対応するコンテンツ配信サーバ４０１、サービスＳ２に対応するコンテンツ配信サーバ４０２へ各々検索クエリを送信する。サービスＳ３に対する検索は、メタデータ蓄積管理部２０１におけるデータベース管理システムへの接続と、検索クエリとして生成されたＳＱＬ文の発行とによって実現される（ステップＳ１１３）。ステップＳ１に対する検索は、ＵＲＬに検索クエリを含めたＨＴＴＰリクエストを、通信部１０６及びネットワーク３０１を介してコンテンツ配信サーバ４０１に送信することによって実現される（ステップＳ１１５）。ステップＳ２に対する検索は、ＵＲＬに検索クエリを含めたＨＴＴＰリクエストを、通信部１０６及びネットワーク３０１を介してコンテンツ配信サーバ４０２に送信することによって実現される（ステップＳ１１６）。

　メタデータ蓄積管理部２０１は、ＳＱＬ文を実行して、該当するメタデータを取得すると、これを取得部１０５に返す（ステップＳ１１４）。コンテンツ配信サーバ４０１は、ネットワーク３０１を介して検索クエリを受信するとこれを実行して該当するメタデータを取得し、当該メタデータを受信装置１００に対して送信する（ステップＳ１１７）。同様にコンテンツ配信サーバ４０２も、ネットワーク３０１を介して検索クエリを受信するとこれを実行して該当するメタデータを取得し、当該メタデータを受信装置１００に対して送信する（ステップＳ１１８）。

　取得部１０５は、それぞれのサービスＳ１，Ｓ２，Ｓ３からメタデータを受信すると、当該メタデータに対して、必要に応じて解析処理を行う。サービスＳ３であるメタデータ蓄積管理部２０１が共通メタデータフォーマットでメタデータを取得部１０５に返すように構成されている場合には、サービスＳ３から取得したメタデータに対する解析処理は必要ない。しかし、サービスＳ１，Ｓ２については、各サービス独自のＸＭＬ形式のメタデータフォーマットを採用しているため、これらのサービスから取得したメタデータに対しては解析処理が必要となる。取得部１０５は、サービスＳ１，Ｓ２についてそれぞれ、サービス情報蓄積管理部２０３に記憶されたサービス情報を取得し（ステップＳ１１９）、当該サービス情報に含まれるメタデータフォーマットに基づいて、受信したメタデータの解析処理を行い、当該メタデータを共通メタデータフォーマットのメタデータへ変換することにより、共通メタデータを生成する（ステップＳ１２０）。また、取得部１０５は、受信したメタデータを解析すると同時に、メタデータの特定の属性（タイトルや番組説明）を形態素解析などにより解析して、キーワードを抽出し、当該キーワードを表すと共に、メタデータの取得時に指定された検索条件や、サービス情報を参照するために必要な検索対象のサービスのサービス識別子を含むキーワード情報をキーワード生成・蓄積管理部２０４に記憶させる。そして、取得部１０５は、生成した共通メタデータを、コンテンツ・メタデータ表示部１０１へ出力する（ステップＳ１２１）。

　コンテンツ・メタデータ表示部１０１は、ステップＳ１２１で出力されたメタデータを、例えばその出力順序に従って、表示可能な件数に限定して表示部に表示させる（ステップＳ１２２）。このとき、コンテンツ・メタデータ表示部１０１は、コンテンツ・メタデータ表示部属性情報蓄積管理部２０６に記憶された表示属性情報を用いて、メタデータを表示部に表示させる。尚、メタデータの表示形式が、ティッカーの形式（たとえば右から左へ、検索結果のリストを自動スクロールさせて表示される形式）を取っている場合には、件数を限定する必要はなく、コンテンツ・メタデータ表示部１０１は、取得部１０５が出力したメタデータを逐次表示していけば良い。この結果、再生中のコンテンツに関連するメタデータや、明示的な検索指示に応じて検索されたメタデータが表示部の画面に表示されることになる。

　以上のように、本実施の形態によれば、検索対象のサービス自体が膨大に存在する環境において、コンテンツを受信する受信装置側で、ユーザからの指示を契機として、コンテンツの検索を実行する場合に生じ得る幾つかの問題を解決することができる。第１に、複数のサービス間に跨った横断的な検索をリアルタイムで受信装置が実行する際に、検索対象のサービスが多いために、発行しなければならない検索クエリの数や、受信して処理しなければならないメタデータの総数が膨大になり、横断的な検索自体の実行が実際上困難であるという問題があった。尚、受信装置側ではなくコンテンツ配信サーバ側が複数のサービスの横断的な検索を実行する場合には、各サービスが提供するＷｅｂページを巡回取得し、データベースに一旦蓄積した上で、ＳＱＬ（Ｓｔｒｕｃｔｕｒｅｄ　Ｑｕｅｒｙ　Ｌａｎｇｕａｇｅ）で統一的にメタデータを利用することが一般的である。しかし、このような構成を受信装置側に適用することは非常に困難である。巡回取得した多数のサービスの全てのメタデータを蓄積するための記憶領域を受信装置上に確保することが現実的ではないからである。これに対し、本実施の形態においては、選択部１０２が、検索を実現可能な妥当な検索範囲に検索対象のサービスを絞り込むことにより、第１の問題を解決可能にしている。即ち、今後のコンテンツを配信するサービスの多様化、遍在化を考慮すると、本実施の形態のように受信装置でサービス自体の絞り込みを行なうことで、受信装置の処理能力の範囲内で、複数のサービス間に跨った横断的な検索を実行することが可能になる。

　第２に、検索クエリのフォーマットや、許容される検索条件などの検索形態が異なる複数のサービスに対して、所望のコンテンツを検索するための検索条件を表す元の検索式を正確に射影することが困難であり、元の検索式における検索意図を維持することが困難であったという問題があった。これに対し、共通検索クエリを用いて第２生成部１０３が可能な限り元の検索式に近い形でサービス毎の検索クエリに展開することで、第２の問題を解決可能にしている。即ち、従来では、各サービスが許容する検索形態における検索クエリへ変換する際に、元の検索式における検索意図が縮退してしまい、意図したコンテンツが発見し難くなる恐れがあったが、このような事態を低減することができる。

　第３に、受信装置から複数のサービスに対して検索クエリを発行する場合に、単一のサービスからメタデータを受信してこれを表示する場合と比較して、コンテンツを提示するために要する時間が非常に大きくなるという問題があった。これに対し、元検索式から展開したサービス毎の検索クエリの実行順序を制御することで、ユーザが所望するコンテンツをより効率的に提示することができ、第３の問題を解決可能にしている。

[第２の実施の形態]
　次に、受信装置の第２の実施の形態について説明する。なお、上述の第１の実施の形態と共通する部分については、同一の符号を使用して説明したり、説明を省略したりする。

（１）構成
　図１８は、本実施の形態にかかる受信装置１００´の構成を示す図である。本実施の形態にかかる１００´は、コンテンツ・メタデータ表示部１０１、選択部１０２、第２生成部１０３、実行制御部１０４、取得部１０５、通信部１０６、メタデータ蓄積管理部２０１、コンテンツ視聴・スキップ履歴蓄積管理部２０２、サービス情報蓄積管理部２０３、キーワード生成・蓄積管理部２０４、検索クエリ実行履歴蓄積管理部２０５及びコンテンツ・メタデータ表示部属性情報蓄積管理部２０６に加え、検出部１０９を有する。また、受信装置１００´の通信部１０６には、メタデータ蓄積管理部２０１ｂが接続され、ネットワーク３０２を介してメタデータ蓄積管理部２０１ｃが接続され、ネットワーク３０１を介してコンテンツ配信サーバ４０１，４０２の他コンテンツ配信サーバ４０３と接続される。メタデータ蓄積管理部２０１ｂは、何らかの通信ケーブルで受信装置１００´と接続された外部記憶装置上に構築されるものであり、例えば、ＵＳＢケーブルで接続された外付けハードディスクドライブなどである。メタデータ蓄積管理部２０１ｃは、ネットワーク３０２上に存在する別デバイス上に構築されるものであり、例えば、ＮＡＳ（Ｎｅｔｗｏｒｋ　Ａｃｃｅｓｓ　Ｓｔｏｒａｇｅ）デバイスである。ネットワーク３０２は、例えば、ホームネットワークを構成するＬＡＮ（Ｌｏｃａｌ　Ａｒｅａ　Ｎｅｔｗｏｒｋ）である。但し、メタデータ蓄積管理部２０１ｂ，２０１ｃは、受信装置１００からデータベース管理システムとしてアクセス可能であればどのような形態をとっていても良い。これらは、メタデータ蓄積管理部２０１と同様に、メタデータを管理するものであり、各々サービスの１つであるローカルデータベースサービスである。

　検出部１０９は、サービスの利用可否を表す利用可否フラグをサービス情報と対応付けてサービス情報蓄積管理部２０３に記憶させる。サービスの利用可否については、検出部１０９は、例えば、通信部１０６を介して、サービスへの定期的な接続によって検出したり、又は、サービスからの利用可否を表す利用可否情報の非同期通知によって検出したりする。なお、本実施の形態では、サービスの利用が「不可」である状況を検出する手順については触れないが、以下に記す、サービスの接続検知からサービス情報蓄積管理部２０３への反映までの処理手順と同等の処理手順を踏むことで実現可能である。但し、サービスの利用が「不可」であることの判断については、通信のタイムアウトや失敗時の試行回数などを判断材料として、これに何らかの閾値を設けて行なう方法を取ることになる。

　サービス情報蓄積管理部２０３は、上述のサービス情報を利用可否フラグと対応付けて記憶し、これらを管理する。尚、メタデータ蓄積管理部２０１のサービス情報と、メタデータ蓄積管理部２０１ｂ，２０１ｃの各サービス情報とは親子関係を有しており、後者の各サービス情報の親サービス識別子には、メタデータ蓄積管理部２０１のサービス識別子がセットされている。

　次に、本実施の形態にかかる受信装置１００´の行うメタデータ取得処理の手順について説明する。図１９は、メタデータ取得処理において、利用可能なサービスを検出するサービス検出処理の手順を示すフローチャートである。受信装置１００´は既に起動されており、通信部１０６を介してネットワーク３０１上のコンテンツ配信サーバ４０１～４０３と通信可能な状態になっていることを前提とする。ただし、本実施の形態の初期状態として、コンテンツ配信サーバ４０１～４０３は、受信装置１００´からアクセス可能な状態になっているが、ＵＳＢケーブルで受信装置１００´に接続された外部記憶装置上のメタデータ蓄積管理部２０１ｂ及びＮＡＳデバイス上のメタデータ蓄積管理部２０１ｃは、受信装置１００´にまだ接続されていないものとする。

　まず、メタデータ蓄積管理部２０１ｂが構築されている外部記憶装置が、受信装置１００´に接続されると（ステップＳ２０１）、通信部１０６が、ＵＳＢケーブルの接続を検出し、新たな外部デバイスが接続されたことを検出部１０９へ通知する（ステップＳ２０２）。検出部１０９は、接続された外部記憶装置上に、メタデータ蓄積管理部２０１ｂが存在する否かを確認する（ステップＳ２０３）。これは、メタデータ蓄積管理部２０１ｂが外部記憶装置上の特定のパスに常に構築されることを前提とした上で、データベース管理システムとしてのメタデータ蓄積管理部２０１ｂの存在有無を確認することで実現しても良いし、パスを固定化せずに、新たに構築したメタデータ蓄積管理部２０１ｂを識別するためのデバイス識別子と、その際に生成したデータベースパスとをサービス情報蓄積管理部２０３に記憶しておき、この情報を参照することで実現しても良い。本実施の形態においては、検出部１０９は、メタデータ蓄積管理部２０１ｂが存在することを検出すると、メタデータ蓄積管理部２０１ｂのサービス情報と対応付けられてサービス情報蓄積管理部２０３に記憶されている利用可否フラグがサービスの利用が可能であることを表すよう更新する（ステップＳ２０４）。これにより、受信装置１００´において、メタデータ蓄積管理部２０１ｂは利用可能なサービスとして有効化される。同様に、検出部１０９は、ＮＡＳデバイスがネットワーク３０２に接続され、メタデータ蓄積管理部２０１ｃが利用可能になったことも、同様の手順で検出する（ステップＳ２０５～Ｓ２０８）。尚、上述したように、サービス情報蓄積管理部２０３に記憶されている、メタデータ蓄積管理部２０１ｂ、２０１ｃに各々対応するサービス情報は、メタデータ蓄積管理部２０１ａのサービス識別子を、親サービス識別子として各々含んでいる。

　続いて、上述の第１の実施の形態で説明した図１７のステップＳ１０１～Ｓ１０３と同様にして、ユーザが操作入力部を介してコンテンツを検索する操作入力を行い、受信装置１００のコンテンツ・メタデータ表示部１０１が、コンテンツ検索要求メッセージを受信すると、共通検索クエリを生成する。ここで生成される共通検索クエリは、第１の実施形態と同様に、２つのジャンル（Ｇ１、Ｇ２）、２つのキーワード（Ｋ１、Ｋ２）及び２つのクレジット（Ｃ１、Ｃ２）が検索条件として、上述の式１の論理式で表される検索式で表現されているとする。

　続いて、図１７のステップＳ１０４と同様にして、選択部１０２は、共通検索クエリを入力として、検索対象となるサービスを選択するが、ここでは、ローカルデータベースサービス（メタデータ蓄積管理部２０１であり、第１の実施の形態と同様にサービスＳ３とする）のみを選択するものとする。そして、選択部１０２は、サービス情報蓄積管理部２０３から、メタデータ蓄積管理部２０１のサービス情報を取得すると共に、メタデータ蓄積管理部２０１のサービス識別子が親サービス識別子としてセットされているサービス情報を取得する。ここでは、メタデータ蓄積管理部２０１を親サービスとする従属サービスであるメタデータ蓄積管理部２０１ｂ，２０１ｃの各サービス情報が取得される。そして、選択部１０２は、図１７のステップＳ１０６と同様にして、選択したサービスをサービス条件として式１の検索式に追加して以下の式３のように更新する。この検索式が共通検索クエリに相当する。
検索式：＝Ｓ３＊（Ｇ１＋Ｇ２）＊（Ｋ１＋Ｋ２）＊（Ｃ１＋Ｃ２）…式３
また、選択部１０２は、従属サービスのサービス情報を共通検索クエリに付加して、このサービス情報を共通検索クエリに付加して第２生成部１０３へ出力する。

　図２０は、メタデータ取得処理において、サービス検出処理後に検索クエリを生成する検索クエリ生成処理の手順を示す図である。第２生成部１０３は、共通検索クエリに含まれるサービスＳ３に対応する検索クエリを生成する際に、親サービスであるメタデータ蓄積管理部２０１のサービス情報を取得し（ステップＳ２１１）、共通検索クエリに付加された、従属サービス（ここでは、メタデータ蓄積管理部２０１ｂ，２０１ｃ）のサービス情報を各々取得する（ステップＳ２１２～Ｓ２１３）。具体的には、第２生成部１０３は、まず、メタデータ蓄積管理部２０１ｂ，２０１ｃの各データベース管理システムを、メタデータ蓄積管理部２０１のデータベース管理システムにアタッチし、統合的にアクセス可能な状態にする（ステップＳ２１４～Ｓ２１５）。続いて、第２生成部１０３は、例えば、以下のように、各データベース管理システムがＵＮＩＯＮで連結された統合検索用のＳＱＬ文を生成する（ステップＳ２１６）。この例では、メタデータ蓄積管理部２０１ｂ，２０１ｃが、従属サービスのサービス情報として、それぞれデータベース名‘ＳＵＢ＿Ｂ’、‘ＳＵＢ＿Ｃ’を有し、この情報を利用してアタッチされている。
select　*　from　content_metadata_table　
where　(service=’S1’　or　service=’S2’)　and　
　　　　　　(genre=’G1’　or　genre=’G2’)　and
　　　　　　(keyword=’K1’　or　keyword=’K2’)　and
(credit=’C1’　or　credit=’C2’)
union
select　*　from　‘SUB_B’.content_metadata_table　
where　(service=’S1’　or　service=’S2’)　and　
　　　　　　(genre=’G1’　or　genre=’G2’)　and
　　　　　　(keyword=’K1’　or　keyword=’K2’)　and
(credit=’C1’　or　credit=’C2’)
union
select　*　from　‘SUB_C’.content_metadata_table　
where　(service=’S1’　or　service=’S2’)　and　
　　　　　　(genre=’G1’　or　genre=’G2’)　and
　　　　　　(keyword=’K1’　or　keyword=’K2’)　and
(credit=’C1’　or　credit=’C2’)

　なお、上述のステップＳ２１３は、第２生成部１０３ではなく、検出部１０９が、ＮＡＳデバイスがネットワーク３０２に接続され、メタデータ蓄積管理部２０１ｃが利用可能になったことを検出した際に、メタデータ蓄積管理部２０１ｃのサービス情報と対応付けられてサービス情報蓄積管理部２０３に記憶されている利用可否フラグを更新するときと同時に行なうようにしても良い。

　第２生成部１０３は、以上のようにして検索クエリとしてＳＱＬ文を生成する。その後、第２生成部１０３は、生成したＳＱＬ文を実行制御部１０４へ出力する（ステップＳ２１７）。実行制御部１０４は、複数のＳＱＬ文があった場合には、図１７のステップＳ１１１～Ｓ１１２と同様にして、複数のＳＱＬ文の実行順序を決定して、決定した実行順序に従い、ＳＱＬ文を取得部１０５に逐次出力していく。ここでは、ＳＱＬ文は１であるとして、これが取得部１０５に出力される。取得部１０５は、第２生成部１０３から出力されたＳＱＬ文を実行して、メタデータ蓄積管理部２０１，２０１ｂ，２０１ｃからメタデータを適宜受信し、図１７のステップＳ１２０と同様にして、当該メタデータに対して必要に応じて解析処理を行って、共通メタデータを生成する。そして、取得部１０５は、図１７のステップＳ１２１と同様にして、生成した共通メタデータを、コンテンツ・メタデータ表示部１０１へ出力する。コンテンツ・メタデータ表示部１０１は、図１７のステップＳ１２２と同様にして、出力されたメタデータを、例えばその出力順序に従って、表示部に表示させる。

　以上のように、検索対象の複数のサービスが階層関係を有している場合においても、検出部１０９が、検索対象となるサービスの追加及び有効化を動的に行い、かつ、第２生成部１０３が、サービス間の階層関係に応じた検索クエリを生成することで、利用可能なサービスに限定して複数のサービス間に跨った横断的な検索を実現することができている。

[第３の実施の形態]
　次に、受信装置の第３の実施の形態について説明する。なお、上述の第１の実施の形態又は第２の実施の形態と共通する部分については、同一の符号を使用して説明したり、説明を省略したりする。

　図２１は、本実施の形態にかかる受信装置１００″の構成を示す図である。本実施の形態にかかる１００″は、コンテンツ・メタデータ表示部１０１、選択部１０２、第２生成部１０３、実行制御部１０４、取得部１０５、通信部１０６、メタデータ蓄積管理部２０１、コンテンツ視聴・スキップ履歴蓄積管理部２０２、サービス情報蓄積管理部２０３、キーワード生成・蓄積管理部２０４、検索クエリ実行履歴蓄積管理部２０５及びコンテンツ・メタデータ表示部属性情報蓄積管理部２０６に加え、フィルタ部１０７及び表示制御部１０８を有する。また、受信装置１００″の通信部１０６には、ネットワーク３０１を介してコンテンツ配信サーバ４０１，４０２の他コンテンツ配信サーバ４０３,４０４と接続される。

　第２生成部１０３は、上述の第１の実施の形態と同様にして、検索対象の各サービスに対して検索クエリを生成してこれを実行制御部１０４に出力する。更に、本実施の形態では、第２生成部１０３は、検索対象のサービスに対して検索クエリに適用できなかった検索条件を表す未適用検索条件リストを取得部１０５に出力する。あるサービスが、共通検索条件に合致する検索条件属性は備えないが、共通検索条件に合致するメタデータ属性は備える場合、この共通検索条件が、検索クエリでは適用できなかった検索条件に該当する。この検索条件を表す情報が未適用検索条件リストとなる。

　取得部１０５は、上述の第１の実施の形態と同様にして、実行制御部１０４から出力される検索クエリを逐次実行して、メタデータを取得し、当該メタデータに対して解析処理を適宜行って、共通メタデータを取得する。また、取得部１０５は、第２生成部１０３から出力された未適用検索条件リストをフィルタ部１０７に出力する。

　フィルタ部１０７は、取得部１０５が出力した共通メタデータに対して、取得部１０５が出力した未適用検索条件リストによって示される、検索クエリでは適用できなかった検索条件を適用させて、共通メタデータをフィルタリングする。即ち、フィルタ部１０７は、取得部１０５が出力した共通メタデータから、検索クエリでは適用できなかった検索条件に合致するメタデータを検索し、当該検索条件に合致しないメタデータを削除することにより、共通メタデータをフィルタリングする。この結果、該当のコンテンツが絞り込まれる。

　具体例を挙げると、あるサービスにおいて、検索クエリとして年齢制限情報を指定できないが、受信したメタデータには年齢制限情報が含まれ、共通検索条件に年齢制限情報が含まれる場合、取得部１０５は、年齢制限情報を除いた検索クエリを当該サービスに対して実行し、適宜解析処理を行って得た共通メタデータと、適用できなかった検索条件として年齢制限情報を表す未適用検索条件リストとをフィルタ部１０７に出力する。フィルタ部１０７は、未適用検索条件リストによって示される年齢制限情報と、出力された共通メタデータに属性として含まれる年齢制限情報とを参照して、該当の共通メタデータを検索して検索の結果得られた共通メタデータがフィルタリングの結果となる。このようにして、フィルタ部１０７は、取得部１０５から出力されたメタデータをフィルタリングする。そして、フィルタ部１０７は、フィルタリングした結果得られた共通メタデータを表示制御部１０８に出力する。

　表示制御部１０８は、フィルタ部１０７から出力される共通メタデータであり、複数のサービスから各々受信した共通メタデータの集合をマージして、共通検索クエリに含まれる共通検索条件のうち、マージした共通メタデータの集合にのみ適用可能な検索条件を用いて、コンテンツ・メタデータ表示部１０１に表示させるメタデータを選択する。例えば、共通検索条件に整列条件が含まれている場合には、表示制御部１０８は、当該整列条件に従って、マージしたメタデータを整列する整列処理を行い、整列処理後のメタデータを表示部に表示させる。ここで、例えば、表示制御部１０８は、一定数毎に整列処理を一括して行い、このとき、整列処理の対象となる一定数のメタデータをメタデータ蓄積管理部２０１にキャッシュする。例えば、表示制御部１０８は、メタデータ蓄積管理部２０１と同じテーブル構成を持つオンメモリデータベース（図示せず）を有し、このオンメモリデータベースに、フィルタ部１０７から出力されるメタデータを逐次記憶させる。

　次に、本実施の形態にかかる受信装置１００″の行うメタデータ取得処理の手順について図２２～２３を用いて説明する。ステップＳ１０１，Ｓ１０３～Ｓ１０４は上述の第１の実施の形態と略同様である。尚、ステップＳ１０４では、共通検索クエリは、１つのジャンル（Ｇ１）、１つのタイトル（Ｔ１）、１つのコンテンツ尺（Ｄ１）、１つの公開日時（公開／放送開始日時又は公開／放送終了日時）による整列条件（Ｏ１）が検索条件として、式４の論理式で表わされる検索式で表現されているとする。
検索式：＝（Ｇ１）＊（Ｔ１）＊（Ｄ１）＊（Ｏ１）…式４

　具体的には、Ｇ１は、ジャンルコード＝「映画」を表し、Ｔ１は、映画のタイトルに含まれる何らかのキーワード（例えば「ＡＢＣ」）を表しているものとする。Ｄ１は、「６０分以内」といったコンテンツ尺の上限を規定しているものとする。コンテンツ尺は、その他「６０分から１２０分」といった範囲を規定するものであっても良いし、「３０分以上」といった下限を規定するものであっても良い。共通検索条件は、このような不等号による検索条件をも内包できるものであって良い。Ｏ１は、例えば「新着順」などが一般的であり、ここでも「新着順」が整列条件で指定されているものとする。

　次に、選択部１０２は、ステップＳ１０４で出力された共通検索クエリを入力として、上述の第１の実施の形態と同様にステップＳ１０５～Ｓ１０６の処理を行って、検索対象となるサービスを選択する。具体的には、本実施の形態では、ジャンルコード＝「映画」であるから、映画のコンテンツ及びそのメタデータのみを検索可能に記憶しているサービスを選択しても良いし、映画のコンテンツ及びそのメタデータを多く記憶しているサービスであっても良い。この選択基準については、サービスが対象とするジャンルなどの検索条件属性を、サービス情報として、サービス情報蓄積管理部２０３が管理することで実現されるが、これは第１の実施の形態と説明が重複するので割愛する。ここでは、結果として、コンテンツ配信サーバ４０３（サービスＳ４とする）、コンテンツ配信サーバ４０４（サービスＳ５）が検索対象となるサービスとして選択されたものとする。この結果、式４の検索は、以下の式５のように更新される。これを共通検索クエリとして、ステップＳ１０７では、選択部１０２は、検索対象として選択したサービスのサービス情報と共に第２生成部１０３に出力する。
（Ｓ４＋Ｓ５）＊（Ｇ１）＊（Ｔ１）＊（Ｄ１）＊（Ｏ１）…式５

　第２生成部１０３は、ステップＳ１０７で出力された、式５の検索式で表される共通検索クエリとサービス情報とを用いて、サービス毎の検索クエリへ展開する。ここでは、コンテンツ配信サーバ４０３，４０４共に、ＲＥＳＴ形式のＷｅｂＡＰＩをベースとしたＵＲＬを利用した検索条件指定のみを許容しているものとし、ＳＱＬのような構造的な（論理表現を許容する）検索条件の記述には対応していないものとする。この場合、第２生成部１０３は、式５の検索式を積項展開し以下の式６，７を得る。
（Ｓ４）＊（Ｇ１）＊（Ｔ１）＊（Ｄ１）＊（Ｏ１）…式６
（Ｓ５）＊（Ｇ１）＊（Ｔ１）＊（Ｄ１）＊（Ｏ１）…式７

　そして、第２生成部１０３は、それぞれの式から、サービスＳ４であるコンテンツ配信サーバ４０３のサービス情報及びサービスＳ５であるコンテンツ配信サーバ４０３、４０５のサービス情報をサービス情報蓄積管理部２０３から取得して（ステップＳ１０８）、実際の検索クエリ（ＵＲＬ）を各々生成する（ステップＳ１０９）。尚、コンテンツ配信サーバ４０３では、タイトル、ジャンルは検索条件として指定可能であるが、コンテンツ尺、公開日時による整列条件は検索条件として指定できないものとする。第２生成部１０３は、サービス情報蓄積管理部２０３に記憶されたサービス情報を用いて、サポートされている検索条件属性を判断する。同時に、第２生成部１０３は、当該サービス情報から、サポートされているメタデータ属性を参照して、検索クエリの実行結果として得られるメタデータには、コンテンツ尺、及び公開日時の各情報が含まれていることを認識する。ここで、第２生成部１０３は、検索条件として指定可能なジャンル：Ｇ１とタイトル：Ｔ１を利用して、以下の検索クエリを生成する。このとき、Ｇ１のジャンル＝「映画」を、コンテンツ配信サーバ４０３のジャンルの表記形式に則って「Ｍｏｖｉｅ」に変換している。
http://s4.example.com/search_api?genre=Movie&title　=ＡＢＣ&from=1&count=50

　一方、コンテンツ配信サーバ４０４は、ジャンルによる整列条件は指定可能であるが、タイトル、コンテンツ尺、公開日時による整列条件は検索条件として指定できないものとする。第２生成部１０３は、サービス情報蓄積管理部２０３上の当該サービス情報から、キーワードは検索条件として指定可能であること、検索クエリの実行結果として得られるメタデータには、コンテンツ尺、タイトル及び公開日時の各情報が含まれていることを認識する。ここで、第２生成部１０３は、検索条件としてタイトルをキーワードで代替し、Ｇ１とＴ１とを用いて以下の検索クエリを生成する。
http://s4.example.com/search_api?genre=MOVIE&keyword=ＡＢＣ
&from=1&count=50

　続いて、第２生成部１０３は、ステップＳ１０９で生成した検索クエリのリストを実行制御部１０４に出力する（ステップＳ１１０）。また、更に、第２生成部１０３は、検索対象のサービスに対して検索クエリに適用できなかった検索条件を表す未適用検索条件リストを取得部１０５へ出力する。尚、検索対象のサービスに対して検索クエリに適用できなかった検索条件がなかった場合には、第２生成部１０３は、未適用検索条件リストを取得部１０５へ出力しなくても良いし、空値をセットした未適用検索条件リストを取得部１０５へ出力するようにしても良い。実行制御部１０４は、上述の第１の実施の形態と同様にステップＳ１１１～Ｓ１１２の処理を行い、検索クエリの実行順序を決定し、決定した実行順序に従い、検索クエリを取得部１０５に逐次出力していく。

　取得部１０５は、出力された検索クエリを逐次実行していく。ここでは、取得部１０５は、サービスＳ４に対応するコンテンツ配信サーバ４０３及びサービスＳ５に対応するコンテンツ配信サーバ４０４へ各々検索クエリを送信する（ステップＳ１３０～Ｓ１３１）。これは、ＵＲＬに検索クエリを含めたＨＴＴＰリクエストを、通信部１０６を介して送信することによって実現される。

　コンテンツ配信サーバ４０３は、ネットワーク３０１を介して検索クエリを受信すると、当該検索クエリを実行して、該当するメタデータを取得し、当該メタデータを受信装置１００″に送信する（ステップＳ１３２）。同様にコンテンツ配信サーバ４０４も、ネットワーク３０１を介して検索クエリを受信すると、当該検索クエリを実行して、該当するメタデータを取得し、当該メタデータを受信装置１００″に送信する（ステップＳ１３３）。

　図２３の説明に移る。取得部１０５は、サービスＳ４であるコンテンツ配信サーバ４０３，サービスＳ５であるコンテンツ配信サーバ４０４のそれぞれからメタデータを受信すると、当該メタデータに対して解析処理を適宜行い、それぞれから共通メタデータの集合を得て、これらをフィルタ部１０７へ逐次出力すると共に、第２生成部１０３から出力された未適用検索条件リストをフィルタ部１０７へ出力する（ステップＳ３０１）。

　フィルタ部１０７は、ステップＳ３０１で出力された共通メタデータの集合を取得すると共に、未適用検索条件リストを適宜取得すると、これらを用いてフィルタ処理を行う（ステップＳ３０２～Ｓ３１１）。図２４は、フィルタ部１０７が行うフィルタ処理の詳細な手順を示すフローチャートである。図２３のステップＳ３０１に続き、フィルタ部１０７には、取得部１０５が出力したメタデータが入力され、未適用検索条件リストが入力され得る（ステップＳ１１）。ここでフィルタ部１０７は、ステップＳ１１で入力された情報を解析して（ステップＳ１２）、未適用検索条件リストが入力されたか否かを判断する（ステップＳ１３）。上述したように、検索対象のサービスに対して検索クエリに適用できなかった検索条件がなかった場合には、未適用検索条件リストが第２生成部１０３から出力されない場合もあれば、第２生成部１０３から未適用検索条件リストは出力されるがこれには空値がセットされている場合もある。これらの場合には、フィルタ部１０７は、未適用検索条件リストが入力されないものと判断する。この場合（ステップＳ１３：ＮＯ）、フィルタ部１０７は、フィルタ処理を行わずに、ステップＳ１１で入力されたメタデータを表示制御部１０８へ出力する（ステップＳ１７）。一方、未適用検索条件リストが入力された場合（ステップＳ１３：ＹＥＳ）、フィルタ部１０７は、ステップＳ１１で入力されたメタデータに対して、未適用検索条件リストによって示される検索条件を適用して、当該メタデータをフィルタリングする（ステップＳ１４）。具体的には例えば、コンテンツ配信サーバ４０３については、適用できなかった検索条件は、コンテンツ尺及び公開日時による整列条件である。コンテンツ配信サーバ４０４については、適用できなかった検索条件は、タイトル、コンテンツ尺及び公開日時による整列条件である。

　フィルタ部１０７は、適用できなかったこれらの検索条件のうち、整列条件を除いた検索条件に合致する共通メタデータを共通メタデータの集合から検索することにより、フィルタリングする（ステップＳ１４）。整列条件を除くのは、個別に入力された共通メタデータの集合をマージさせた上でしか適用できないためである。ここでの検索の例としては、例えば、コンテンツ配信サーバ４０４については、検索条件としてタイトルをキーワードで代替して検索したため、コンテンツ配信サーバ４０４上は、暗黙的に全文検索した結果を検索クエリの実行結果として返している。このため、受信装置１００″が受信したメタデータの集合には、指定したキーワード「ＡＢＣ」が、メタデータ属性“タイトル”に含まれるものだけでなく、メタデータ属性“概要説明”や“キーワード”にも、指定したキーワード「ＡＢＣ」含まれるものも混在している。フィルタ部１０７は、この中から“タイトル”にのみ「ＡＢＣ」が含まれるものを抽出する。更に、この中でコンテンツ尺が「６０分以内」のものに絞り込むことにより、フィルタリングする。このようにしてフィルタ部１０７は、共通メタデータに含まれる各共通メタデータ属性の値を参照して、検索条件に合致する共通メタデータを検索する。

　そして、フィルタ部１０７は、検索の結果得られた共通メタデータの件数が所定の件数に達しているか否かを判断する（ステップＳ１５）。所定の件数に満たない場合は、フィルタ部１０７は、取得部１０５に対して、メタデータの更なる取得を要求する（ステップＳ１６）。例えば、取得部１０５が、コンテンツ配信サーバ４０４から５０件のメタデータを取得したとしても、フィルタリングした結果、例えば１０件未満に絞り込まれる場合がある。後段の表示制御部１０８での整列処理や、コンテンツ・メタデータ表示部１０１での表示処理に所定数のメタデータが必要である場合、ステップＳ１６では、フィルタ部１０７は、取得部１０５へ、フィルタリングした結果をフィードバックし、メタデータの更なる取得を要求するのである。上述の検索クエリの具体例では、１件目から５０件のメタデータの取得を要求しているが、取得部１０５は、フィードバックを受けて５１件目から５０件を指定しての検索クエリの再度の送信を行う。総数１００件のメタデータが要求されている場合に、例えば、５０件を取得してフィルタリングした結果が１０件であったとすると、取得部は件数が２０％に絞り込まれることを想定し、合計が２５０件になるように検索クエリを複数同時に発行しても良い。尚、コンテンツ配信サーバ４０３においても、検索クエリに適用できなかった検索条件を、フィルタ部１０７でのフィルタリングに利用するが、コンテンツ配信サーバ４０４の場合と同様であるため、説明は割愛する。そして、フィルタ部１０７は、ステップＳ１４の検索の結果得られた共通メタデータ、又はステップＳ１４及びステップＳ１６の検索の結果得られた共通メタデータを表示制御部１０８へ出力する（ステップＳ１７）。

　図２３の説明に戻る。ステップＳ３０３は、上述したステップＳ１４に該当し、ステップＳ３０４は、上述のＳ１７に該当し、ステップＳ３０５～Ｓ３０６は、上述したステップＳ１６に該当する。ステップＳ３０８～Ｓ３１１は、ステップＳ３０２～Ｓ３０５と略同様である。尚、上述したように公開日時による整列条件については、この段階まで適用されていない。

　一方、表示制御部１０８は、フィルタ部１０７から個別に出力される共通メタデータをマージして（ステップＳ３１２）、上述の整列条件に従って、マージしたメタデータを整列する整列処理を行う（ステップＳ３１３）。具体的には例えば、表示制御部１０８は、フィルタ部１０７から逐次出力されるメタデータを一定時間で区切って、その間にフィルタ部１０７から出力されたメタデータが、公開日時によって降順、即ち、新着順で整列するよう整列処理を一括して行う（一括処理）。

　ここで表示制御部１０８が行う整列処理の詳細な手順について図２５を用いて説明する。表示制御部１０８は、コンテンツを検索することを要求する操作入力が操作入力部を介して行われたことを検出すると（ステップＳ２１）、メタデータの一括処理を行うトリガ（検索開始トリガ）のタイマーをリセットし、タイマーをカウントさせる（ステップＳ２２）。タイマーのカウントが、予め設定された閾値に達するまでの間（ステップＳ２３：ＹＥＳ）、表示制御部１０８は、フィルタ部１０７から出力されるメタデータを、一括処理用のキャッシュ領域へ逐次記憶させていく（ステップＳ２５）。尚、一括処理用のキャッシュ領域の実体は、オンメモリデータベースであることを想定しているが、この限りではない。そしてタイマーのカウントが閾値に達すると、表示制御部１０８は、一括処理用のキャッシュ領域へ記憶されたメタデータが、公開日時によって降順、即ち、新着順で整列するよう整列処理を一括して行う。

　図２３の説明に戻る。ステップＳ３１３の後、表示制御部１０８は、この結果得られるメタデータのうち上位の所定数のメタデータを選択してこれをコンテンツ・メタデータ表示部１０１に対して出力する（ステップＳ３１４）。

　以上のようにして、複数のサービスから各々受信した、一部の検索条件が除外された検索クエリの実行結果であるメタデータに対して、除外された検索条件による検索をフィルタ部１０７が行ってフィルタリングを行い、表示制御部１０８が整列処理を行う。このような構成によれば、検索対象となるサービスが複数あって各サービスが有する検索インタフェースが多様である場合、所望のコンテンツを検索するための検索クエリが、各サービスの検索インタフェースに対応させることができない場合であっても、所望のコンテンツを検索するための元の検索式における検索意図を可能な限り維持した検索を実現することができる。

[変形例]
　なお、本発明は前記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、前記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除しても良い。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。また、以下に例示するような種々の変形が可能である。

　上述した各実施の形態において、受信装置１００，１００´，１００″で各々実行される各種プログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成しても良い。また当該各種プログラムを、インストール可能な形式又は実行可能な形式のファイルでＣＤ－ＲＯＭ、フレキシブルディスク（ＦＤ）、ＣＤ－Ｒ、ＤＶＤ（Digital　Versatile　Disk）等のコンピュータで読み取り可能な記録媒体に記録してコンピュータプログラムプロダクトとして提供するように構成しても良い。

　上述した各実施の形態においては、サービス情報は、サービス情報蓄積管理部２０３にプリセットとして予め記憶されるようにしても良いし、該当するコンテンツ配信サーバ４０１，４０２から提供されてサービス情報蓄積管理部２０３に適宜記憶されるようにしても良い。また、後述するように検索クエリ実行履歴蓄積管理部２０５に記憶された実行結果情報に基づき、サービス情報蓄積管理部２０３が自動的に生成するようにしても良い。これは、例えば、あるコンテンツ配信サーバ４０１，４０２から取得するメタデータに含まれるジャンルを表すメタデータ属性が、検索条件としてジャンルコードを指定していないにも関わらず、例えば、ジャンルの細分である「ニュース」に係るコンテンツのみが得られる場合に、経験則的に得られたこの情報をサービス情報に反映させることで実現される。

　上述した各実施の形態においては、図１７及び図２２のステップＳ１０６では、検索対象として選択したサービスを、共通検索条件として検索式に追加したが、これに限らない。例えば、選択したサービス情報を後段の第２生成部１０３へ別途入力しても構わない。

　また、上述した各実施の形態においては、選択部１０２を介さずに、コンテンツ・メタデータ表示部１０１が生成した、もしくは、ユーザによって指定された検索条件が、直接、後段の第２生成部１０３に出力されても良い。この場合、検索対象となるサービスは固定的に、例えば、サービス情報蓄積管理部２０３にサービス情報が記憶されている全てのサービスであっても良い。また、検索対象とするサービスをユーザが選択するインタフェースをコンテンツ・メタデータ表示部１０１が備えていて、このインタフェースを介して選択されたサービスを検索対象のサービスとするようにしても良い。

　また、上述した各実施の形態においては、検索対象として選択されるサービスの上限を設けても良いし、設けなくても良い。上限を設ける場合、その上限の値として内部的に固定値を定義しても良いし、上限の値をユーザに設定させるインタフェースを受信装置１００が備えていてもよい。

　上述した各実施の形態においては、受信装置は、検索クエリを実行することにより、コンテンツやコンテンツのメタデータを検索可能な状態で記憶しているコンテンツ配信サーバからメタデータを取得するようにしたが、これに限らず、少なくともコンテンツのメタデータを検索可能な状態で記憶している情報処理装置を介してメタデータを取得するようにしても良い。

　また、上述した各実施の形態においては、受信装置は、サービスからメタデータを取得した後、当該メタデータによってその属性が表されるコンテンツを、当該サービスから別途取得するようにしても良い。

　上述した第１の実施の形態においては、第２生成部１０３が生成した検索クエリの実行順序を実行制御部１０４が決定し、当該実行順序に従って取得部１０５が検索クエリを実行した。しかし、受信装置１００は、実行制御部１０４を備えず、第２生成部１０３が生成した検索クエリをその生成順に取得部１０５が実行するようにしても良い。

　上述した第１の実施の形態においては、サービスＳ１，Ｓ２が共にネットワーク３０１上に存在しているが、これらが異なるネットワーク上に存在するようにしても良い。例えば、一方がインターネット上に存在し、もう一方がＮＧＮ（Ｎｅｘｔ　Ｇｅｎｅｒａｔｉｏｎ　Ｎｅｔｗｏｒｋ）上に存在していても構わないし、Ｈｏｍｅ　Ｎｅｔｗｏｒｋ上に存在していても構わない。このように、検索対象のサービスが異なるネットワーク上に遍在していても、通信部１０６が各ネットワークへのアクセシビリティを有していれば、各サービスを検索対象とすることができる。上述の第２，第３の実施の形態においても同様である。

　上述した第２の実施の形態においては、受信装置１００´は、階層関係を有するサービスについて、サービス情報に含まれる検索クエリフォーマットに基づいて、階層関係情報を検索条件属性として含む１つの検索クエリ（上述の例では単一のＳＱＬ文）を生成するか、又は、階層関係情報によって階層関係が識別されるサービス毎に検索クエリを生成するかを決定する決定部を更に備えるようにしても良い。この場合、第２生成部１０３は、決定部の決定に従って、コンテンツ・メタデータ表示部１０１が生成した共通検索クエリを用いて、検索クエリを生成すれば良い。

　上述した第３の実施の形態においては、取得部１０５は、メタデータを解析した結果を、フィルタ部１０７に出力するようにしたが、フィルタ部１０７を介さず、表示制御部１０８に出力するようにしても良い。

　又は、第２生成部１０３は、該当するサービスにおいてメタデータ属性には含まれる共通検索条件属性であれば、受信したメタデータに対してならばフィルタとして適用できる検索条件属性であると判断し、フィルタ部１０７に、この共通検索条件属性を出力しても良い。

　また、上述の第３の実施の形態においては、表示制御部１０８が、整列処理の対象として一括処理する共通メタデータの集合を定める方法（一括処理）は、一定時間で区切るようにしているが、この方法以外にも、所定の件数で区切るようにしても良いし、検索対象としたサービス毎に所定の件数ずつ区切るようにしても良い。このように一括処理する単位の決定には、様々な方法が適用可能である。更に、表示制御部１０８は、コンテンツ・メタデータ表示部１０１へ表示するメタデータを絞り込むために、整列処理後の共通メタデータのうち上位の所定数の共通メタデータを選択するのではなく、例えば、コンテンツ視聴・スキップ履歴蓄積管理部２０２に記憶された再生履歴情報及びスキップ履歴情報や、キーワード生成・蓄積管理部２０４に記憶されたキーワード情報に基づいて、再生の頻度の高いサービスのコンテンツを優先し、当該コンテンツに対応する共通メタデータから順に選択するようにしても良い。又は、コンテンツ視聴・スキップ履歴蓄積管理部２０２に記憶された再生履歴情報及びスキップ履歴情報を用いて、ユーザの嗜好を解析する機能を受信装置１００″が更に有し、表示制御部１０８は、当該ユーザの嗜好を用いて、ユーザの嗜好の度の高いコンテンツを優先し、当該コンテンツに対応する共通メタデータから順に選択するようにしても良い。又は、再生中のコンテンツに関連するコンテンツを検索する場合に、再生中のコンテンツのメタデータのメタデータ属性と、メタデータ蓄積管理部２０１に記憶されたメタデータのメタデータ属性との合致度からこれらの類似度を算出する機能を受信装置１００″が更に有し、この類似度の高いコンテンツを優先し、当該コンテンツに対応する共通メタデータから順に選択するようにしても良い。

　また、上述の第３の実施の形態においては、表示制御部１０８は、例えば２０件を表示部に表示させると同時に、続いて参照され得る２１件目からの所定の件数の共通メタデータをメタデータ蓄積管理部２０１、もしくは、表示制御部１０８自体が有するオンメモリデータベース上にキャッシュしても良い。この場合、上述した表示するメタデータの選択と同様に、表示制御部１０８は、コンテンツ視聴・スキップ履歴蓄積管理部２０２に記憶された再生履歴情報及びスキップ履歴情報を用いて、ユーザが辿り得るメタデータの件数を記憶しておき、この件数を用いて、キャッシュする件数を定めるようにしても良い。

　また、上述の第３の実施の形態においては、表示制御部１０８は、フィルタ部１０７から出力された共通メタデータに対して、公開日時などによる整列条件などの指定された整列条件に従って、整列処理を行った。しかし、これに限らず、例えば、再生中のコンテンツとの類似度や、コンテンツ視聴・スキップ履歴蓄積管理部２０２に記憶された再生履歴情報及びスキップ履歴情報を用いて解析されたユーザの嗜好を用いて、フィルタ部１０７から出力された共通メタデータに対して整列処理を行うようにしても良い。

　また、上述の第３の実施の形態においては、未適用検索条件リストは、取得部１０５を介してフィルタ部１０７に入力されるようにしたが、第２生成部１０３からフィルタ部１０７に直接入力されるようにしても良い。

１００，１００´,１００″　受信装置
１０１　コンテンツ・メタデータ表示部
１０１ａ　第１生成部
１０２　選択部
１０３　第２生成部
１０４　実行制御部
１０５　取得部
１０６　通信部
１０７　フィルタ部
１０８　表示制御部
１０９　検出部
２０１，２０１ｂ，２０１ｃ　メタデータ蓄積管理部
２０２　コンテンツ視聴・スキップ履歴蓄積管理部
２０３　サービス情報蓄積管理部
２０４　キーワード生成・蓄積管理部
２０５　検索クエリ実行履歴蓄積管理部
２０６　コンテンツ・メタデータ表示部属性情報蓄積管理部
３０１，３０２　ネットワーク
４０１，４０２，４０３，４０４　コンテンツ配信サーバ

Claims

　コンテンツの属性を表す属性情報を検索可能な状態で記憶している装置であってネットワークを介して接続可能な記憶装置における検索形態と当該記憶装置に接続するための接続方法とを表すサービス情報を記憶する記憶部と、
　コンテンツを検索するための検索条件を表す検索クエリであって、前記属性のうちいずれかを表す検索条件属性を当該受信装置において表現方法を統一した共通検索条件属性及び当該共通検索条件属性のとり得る値である共通検索属性値の対を少なくとも１つ以上含む共通検索クエリを生成する第１生成部と、
　生成された前記共通検索クエリを用いて、前記サービス情報によって示される検索形態に応じた検索クエリを生成する第２生成部と、
　生成された前記検索クエリを、前記サービス情報によって示される接続方法に基づいて、前記記憶装置へ送信する送信部と、
　前記検索クエリの実行の結果得られた前記属性情報を前記記憶装置から受信する受信部とを備える
ことを特徴とする受信装置。
　前記属性情報は、メタデータであり、
　前記サービス情報は、前記検索クエリの実行の結果として提供可能な前記メタデータによって表される属性であるメタデータ属性及び当該メタデータの記述形式であるメタデータ記述形式と、前記検索クエリに検索条件として指定可能な前記メタデータ属性を表す検索条件属性と、前記記憶装置が処理可能な前記検索クエリの記述形式である検索クエリ記述形式と、前記メタデータ属性と、前記検索条件属性と前記共通検索条件属性との対応関係を表すメタデータ属性変換テーブルとを更に表し、
　前記第２生成部は、前記メタデータ属性変換テーブルを用いて、前記共通検索クエリに含まれる前記共通検索条件属性を変換した前記検索条件属性を含み前記検索クエリ記述形式で記述された前記検索クエリを生成する
ことを特徴とする請求項１に記載の受信装置。
　前記サービス情報は、前記記憶装置毎に定義された前記検索条件属性が取り得る値である検索条件属性値と前記共通検索条件属性値との対応関係を表す属性値変換テーブル情報とを更に表し、
　前記第２生成部は、前記メタデータ属性変換テーブルを用いて、前記共通検索クエリに含まれる前記共通検索条件属性を変換した前記検索条件属性を含むと共に、前記メタデータ属性値変換テーブルを用いて、前記共通検索クエリに含まれる前記共通検索条件属性値を変換した前記検索条件属性値を含み前記検索クエリ記述形式で記述された前記検索クエリを生成する
ことを特徴とする請求項２に記載の受信装置。
　前記サービス情報は、前記共通検索条件属性のとり得る値である共通検索条件属性値が、当該サービス情報によってその接続方法が表される前記記憶装置に記憶されている前記メタデータがその属性が表されるコンテンツの全てに該当する場合に、当該共通検索条件属性及び当該共通検索条件属性値の対を更に表す
ことを特徴とする請求項２に記載の受信装置。
　前記共通検索クエリは、複数の検索条件の関係が論理式で表現され、
　前記サービス情報は、前記記憶装置が処理可能な前記検索クエリの記述形式である検索クエリ記述形式を更に表し、
　前記第２生成部は、前記サービス情報によって表される前記検索クエリ記述形式が、論理式での記述が可能であることを示す場合、前記論理式で表現される前記検索クエリを前記共通検索クエリから生成し、前記検索クエリ記述形式が、論理式での記述が可能でないことを示す場合、前記論理式を積項展開し、各積項を用いて、複数の前記検索クエリを前記共通検索クエリから生成する
ことを特徴とする請求項１に記載の受信装置。
　前記共通検索クエリは、前記サービス情報を識別するサービス識別子を共通検索条件属性に含み、複数の前記記憶装置が階層関係を有する場合、前記階層関係を識別するための階層関係情報を前記共通検索条件属性に含み、
　前記サービス情報によって表される前記検索クエリ記述形式に基づいて、前記階層関係情報を前記検索条件属性として含む１つの前記検索クエリを生成するか、又は、前記階層関係情報によって階層関係が識別される前記記憶装置毎に前記検索クエリを生成するかを決定する決定部を更に備え、
　前記第２生成部は、前記決定部の決定に従って、生成された前記共通検索クエリを用いて、前記検索クエリを生成する
ことを特徴とする請求項２に記載の受信装置。
　前記共通検索クエリに含まれる前記共通検索条件属性と前記サービス情報によって前記対応関係が示される前記共通検索条件属性との合致度に基づいて、前記サービス情報を選択し、当該サービス情報によってその接続方法が表される前記記憶装置を検索対象として選択する選択部を更に備え、
　前記第２生成部は、生成された前記共通検索クエリを用いて、選択された前記記憶装置の前記サービス情報によって表される検索形態に応じた前記検索クエリを生成する
ことを特徴とする請求項２に記載の受信装置。
　生成された複数の前記検索クエリの実行順序を制御する実行制御部を更に備える
ことを特徴とする請求項１に記載の受信装置。
　前記第２生成部は、前記サービス情報において前記検索条件属性には含まれないが提供可能な前記メタデータ属性には含まれる第１の前記共通検索条件属性が、前記共通検索クエリに含まれる場合、前記第１の共通検索条件属性及び当該第１の共通検索条件属性がとり得る値である第１の共通検索条件属性値を除いた前記共通検索クエリから前記検索クエリを生成し、
　前記第１の共通検索属性及び前記第１の共通検索属性値を用いて、受信された前記メタデータをフィルタリングするフィルタ部を更に備える
ことを特徴とする請求項２に記載の受信装置。
　受信された前記メタデータを表示部に表示させる表示制御部であって、前記サービス情報において前記検索条件属性には含まれないが提供可能な前記メタデータ属性には含まれる第１の前記共通検索条件属性が、前記共通検索クエリに含まれる場合且つ当該検索条件属性が、前記メタデータを表示させる前に、複数の前記記憶装置から各々取得した複数の前記メタデータを統合した後に適用可能な処理条件を表す場合に、受信された前記メタデータの全部又は一部を統合し、統合した前記メタデータに対して前記検索条件属性によって表される前記処理条件を適用して、当該メタデータを表示部に表示させる表示制御部を更に備える
ことを特徴とする請求項２に記載の受信装置。