JP2005243012A - メタデータのインデックスの提供方法 - Google Patents

Abstract

【課題】コンテンツに関する情報を迅速に検索できるメタデータのインデックス構造を提供する。
【解決手段】コンテンツに関する情報を検索するために提供されるメタデータのインデックス構造と、メタデータのインデックスを提供する方法と、前記メタデータのインデックスを利用したメタデータの検索方法と、これを利用したメタデータの検索装置に関するものであって、コンテンツに関する情報を検索するために提供されるメタデータのインデックス構造は、メタデータの所定フィールドで構成されるキーのリストを含むが、前記リストは前記メタデータにおける前記フィールドの位置情報を含み、前記位置情報の少なくとも一部は所定のコードで表現される。本発明によれば、メタデータについてさらに迅速な検索を行える。
【選択図】図１０

Description

本発明は、コンテンツに関する情報を検索するために提供されるメタデータのインデックス構造及び前記メタデータのインデックス構造を有するメタデータのインデックスを提供する方法と、前記メタデータのインデックスを用いたメタデータの検索方法とそれを用いた検索装置に係り、特にＴＶ−Ａｎｙｔｉｍｅ（以下‘ＴＶＡ’）フォーラムで定義しているデジタルコンテンツに対するＸＭＬメタデータ（以下‘ＴＶＡメタデータ’）をフラグメントという独立した単位に分けて伝送する時、コンテンツに関する情報をより効率的に検索可能とするために少なくとも一部がエンコーディングされたキー情報を含むメタデータのインデックス構造と、前記メタデータのインデックス構造を有するメタデータのインデックスを提供する方法と、前記メタデータのインデックスを用いたメタデータの検索方法とそれを用いた検索装置に関する。

ＴＶＡフォーラムは、個人用大容量保存装置を持つＰＤＲ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ｒｅｃｏｒｄｅｒ）などのユーザー環境でオーディオビジュアル関連サービス提供のための標準を開発することを目的として１９９９年９月に設立された民間標準機構であって、あらゆるユーザーが個人用保存装置に基づいて自分の所望の方法で所望の時間に多様な形態（既存の放送サービス及びオンライン対話形サービスなど）のプログラムを視聴可能にすることをその具体的なサービス目標としている。

ＴＶＡフォーラムは、ビジネスモデル、システム／伝送インターフェース／コンテンツ参照、記述、メタデータ、コンテンツ保護管理などのワーキンググループに分けて標準化を進めており、本発明と関連したメタデータについては２００２年６月に“１ｓｔ Ｄｒａｆｔ ｏｆ Ｍｅｔａｄａｔａ Ｓｐｅｃｉｆｉｃａｔｉｏｎ ＳＰ００３ｖ１．３”が発表されている。

図１を参照してＰＤＲの構成を簡略に説明すれば、ＰＤＲ １００は映像／音声信号を提供する提供者２００から空中波(sky wave)、衛星波、インターネット網などの多様なネットワークを通じて映像／音声信号及びメタデータを受信し、必要に応じて視聴者の視聴パターン、好みなどを収集して映像／音声信号を提供する提供者２００に送信する。ＰＤＲ １００は受信された映像／音声信号及びメタデータを保存する大容量保存装置、映像／音声信号の保存及び再生のためのソフトウェア及び映像／音声信号に対するメタデータを検索(retrieve)／表示(display)するためのＥＰＧ（Ｅｌｅｃｔｒｏｎｉｃ Ｐｒｏｇｒａｍ Ｇｕｉｄｅ）アプリケーションを含み、ユーザーは図２に図示されたＥＰＧアプリケーションのグリッドガイド画面などを通じて映像／音声データに関するメタデータ、すなわち、プログラムタイトル、プログラム再生時間などを確認し、所望のプログラムを選択してネットワークを通じてリアルタイムで受信するか、または既に大量保存装置に保存されている映像／音声データを再生させる。

メタデータとは、プログラムタイトル及び概要などのコンテンツに対する説明的なデータを意味し、“データに関するデータ(data about data)”と定義される。ＴＶＡフォーラムのＴＶＡメタデータ規格ではＸＭＬに関する標準機構Ｗ３Ｃの標準であるＸＭＬ Ｓｃｈｅｍａ言語（Ｗ３ＣのＸＭＬ １．０参照）を使用してその構造を定義する一方、各メタデータエレメント及び属性の意味をともに規定している。放送コンテンツに関連したＴＶＡメタデータは、図３に図示されたように“ＴＶＡＭａｉｎ”３００というルートノードを有するＸＭＬ文書で構成され、例えば、プログラムに関するメタデータは“ＰｒｏｇｒａｍＤｅｓｃｒｉｐｔｉｏｎ”ノードの下に、プログラム情報（ＰｒｏｇｒａｍＩｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅ）、グループ情報（ＧｒｏｕｐＩｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅ）、プログラム位置情報（ＰｒｏｇｒａｍＬｏｃａｔｉｏｎ Ｔａｂｌｅ）、サービス情報（ＳｅｒｖｉｃｅＩｎｆｏｍａｔｉｏｎ Ｔａｂｌｅ）などのノードで構成される。

ＴＶＡフォーラムは、ぼう大なＴＶＡメタデータをストリーム形式で伝送するためにフラグメントという独立的な単位でＴＶＡメタデータを伝送する。図４を参照してフラグメントの概念を簡略に説明すれば、フラグメントとは、図３に図示されたＸＭＬ文書で構成されたＴＶＡメタデータを所定のツリー構造別に分割したものであって、例えば、ＴＶＡメタデータ全体を、“ＴＶＡＭａｉｎ”を上位ノードとして所定の子ノードまで含むツリー構造（フラグメントＴＶＡＭａｉｎ）と、プログラム情報（ＰｒｏｇｒａｍＩｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅ）を上位ノードとして以下の子ノードまで含むツリー構造（フラグメントＰｒｏｇｒａｍＩｎｆｏｒｍａｔｉｏｎ）と、ブロードキャストイベント情報（ＢｒｏａｄｃａｓｔＥｖｅｎｔ）を上位ノードとして以下の子ノードまで含むツリー構造（フラグメントＢｒｏａｄｃａｓｔＥｖｅｎｔ）とに分割する場合、分割されたツリー構造それぞれはフラグメントになり、このフラグメントは他のフラグメントと関係なく独立的に伝送可能であり、また個別にアクセスが可能である。

フラグメントに対する個別のアクセスのために、伝送されたＴＶＡメタデータフラグメントがメタデータツリー構造全体でいかなるノードを参照するか、すなわち、ＴＶＡメタデータフラグメントの上位ノードがいかなるノードに該当するか、そして伝送されたＴＶＡメタデータフラグメント内に含まれたキー（‘キー’はインデクシングのために使われるメタデータの所定フィールドをいうが、ここではメタデータフラグメントが参照するノードの子ノードを意味し、ユーザーが入力するフィールド（検索条件のフィールド）、例えば‘チャンネル番号’または‘放送時間(Published Time)’などがキーに該当する）の前記ＴＶＡメタデータフラグメント内の相対経路を表示する必要があり、このためにＷ３Ｃで定義したＸＰａｔｈ（Ｗ３Ｃで定義したＸＭＬ文書内ノードに対する経路を記述するシンタックス（ｓｙｎｔａｘ））を使用する。

一方、フラグメントに対する効率的な検索及びアクセスを提供するためには、メタデータフラグメントに含まれたキーに対するインデックス構造が別途に必要であり、このようなインデックス構造に関する情報、すなわち、インデックス情報も前記メタデータフラグメントとは独立的に伝送される。

ＴＶＡフォーラムが提供する環境下で、所定放送時間条件(Published Time condition)に合致するプログラム情報をユーザーが検索しようとする場合、まずフラグメントとは独立的に伝送されるインデックス情報を活用して所望の放送時間条件に合致するメタデータフラグメントの位置（識別子）を把握し、この位置（識別子）に基づいて該当メタデータフラグメントにアクセスして前記放送時間条件に合致するメタデータを抽出する。

従来の技術文献（ＴＶ−Ａｎｙｔｉｍｅ Ｓｐｅｃｉｆｉｃａｔｉｏｎ ＴＶ１４５，Ｊ．Ｐ．Ｅｖａｉｎ，“１ｓｔ Ｄｒａｆｔ ｏｆ Ｍｅｔａｄａｔａ Ｓｐｅｃｉｆｉｃａｔｉｏｎ ＳＰ００３ｖ１．３，”ＴＶＡフォーラム１７次会議、モントリオール、カナダ、２００２年６月、以下、“キーインデックス技術文献”）ではメタデータフラグメントインデックスのためのインデックス構造を提案している。

従来のインデックス構造を説明する前にＴＶＡフォーラムが定義するコンテナ(container)概念を先に説明する。ＴＶＡフォーラムは前述したインデックス情報とメタデータフラグメントなどのあらゆるデータが転送される最上位保存所、すなわち、コンテナという最上位転送形態を定義するが、コンテナを概略的に説明すれば、あらゆるコンテナは多数のセクションから構成され、各セクションに前記インデックス情報またはメタデータフラグメントが保存される。コンテナは運搬する情報によって、キーインデックスリスト（ｋｅｙ＿ｉｎｄｅｘ＿ｌｉｓｔ）セクション、キーインデックス（ｋｅｙ＿ｉｎｄｅｘ）セクション、サブキーインデックス（ｓｕｂ＿ｋｅｙ＿ｉｎｄｅｘ）セクション、ストリング保存所（ｓｔｒｉｎｇ＿ｒｅｐｏｓｉｔｏｒｙ）セクション、フラグメントデータ保存所（ｆｒａｇｍｅｎｔ＿ｄａｔａ＿ｒｅｐｏｓｉｔｏｒｙ）セクションなどのインデックス情報セクションを運搬するインデックスコンテナと、エレメントテーブル（ｅｌｅｍｅｎｔｓ＿ｔａｂｌｅ）セクション、ストリング保存所（ｓｔｒｉｎｇ＿ｒｅｐｏｓｉｔｏｒｙ）セクション、フラグメント保存所（ｆｒａｇｍｅｎｔ＿ｄａｔａ＿ｒｅｐｏｓｉｔｏｒｙ）セクションなどのメタデータフラグメントセクションを運搬するデータコンテナとに区分される。前記区分はコンテナに含まれた情報の内容によって区分するものであって、コンテナの構成はインデックスコンテナとデータコンテナの何れも同一である。

図５を参照してＴＶＡフォーラムで定義したコンテナを説明すれば、コンテナはコンテナ識別子情報（ｃｏｎｔａｉｎｅｒ＿ｉｄ）フィールドと多数のセクションを含み（図示せず）、各セクションは‘ｓｅｃｔｉｏｎ＿ｉｄ’のエンコーディング値によって‘ｓｅｃｔｉｏｎ＿ｂｏｄｙ’に保存された内容が識別される。例えば、‘ｓｅｃｔｉｏｎ＿ｉｄ’のエンコーディング値が‘０Ｘ０００４’であるセクション１０はキーインデックスリスト（ｋｅｙ＿ｉｎｄｅｘ＿ｌｉｓｔ）セクション、エンコーディング値が‘０Ｘ０００５’であるセクション２０はキーインデックス（ｋｅｙ−ｉｎｄｅｘ）セクション、エンコーディング値が‘０Ｘ０００６’であるセクション３０はサブキーインデックス（ｓｕｂ＿ｋｅｙ＿ｉｎｄｅｘ）セクション、エンコーディング値が‘０Ｘ０００１’であるセクション４０はエレメントテーブル（ｅｌｅｍｅｎｔ＿ｔａｂｌｅ）セクション、エンコーディング値が‘０Ｘ０００３’であるセクション５０はフラグメントデータ保存所（ｆｒａｇｍｅｎｔ＿ｄａｔａ＿ｒｅｐｏｓｉｔｏｒｙ）セクションとして各々識別される。

ＴＶＡメタデータフラグメントはデータコンテナのフラグメントデータ保存所（ｆｒａｇｍｅｎｔ＿ｄａｔａ＿ｒｅｐｏｓｉｔｏｒｙ）セクション５０内に保存されて転送されるが、前記データコンテナ内のＴＶＡメタデータフラグメントに対する識別子情報（ｈａｎｄｌｅ＿ｖａｌｕｅ）フィールドはエレメントテーブルセクション４０に含まれる。

要するに、ＴＶＡメタデータフラグメントは、ＴＶＡメタデータフラグメントが含まれたコンテナのコンテナ識別子情報（ｃｏｎｔａｉｎｅｒ＿ｉｄ）とメタデータフラグメント識別子情報（ｈａｎｄｌｅ＿ｖａｌｕｅ）とにより唯一に識別される。

前述したキーインデックス技術文献では前述したデータコンテナに保存されたＴＶＡメタデータフラグメントをインデックスするためのインデックス構造、すなわち、キーインデックスリスト（ｋｅｙ＿ｉｎｄｅｘ＿ｌｉｓｔ）セクション１０、キーインデックス（ｋｅｙ＿ｉｎｄｅｘ）セクション２０、及びサブキーインデックス（ｓｕｂ＿ｋｅｙ＿ｉｎｄｅｘ）セクション３０の構造を提案している。前記構造のシンタックスについては前述したキーインデックス技術文献に詳細に記述されているので、それに関する具体的な説明は省略し、以下では前記構造をインデックス情報のセグメントで表現した図６を参照して説明する。

従来のキーインデックス構造で定義されるキーインデックスリスト（ｋｅｙ＿ｉｎｄｅｘ＿ｌｉｓｔ）セクション１０は、転送されるあらゆるキーのリストを提供する。このリストには、各キーを定義するキー情報と、後述されるキーインデックス（ｋｅｙ＿ｉｎｄｅｘ）セクション２０に関する識別情報とが含まれる。前記キー情報には、（１）シングルキーと関連したメタデータフラグメントの位置情報（ＴＶＡではＸＰａｔｈ（ｆｒａｇｍｅｎｔ＿ｘｐａｔｈ＿ｐｔｒ）で表現される）と、（２）キーの前記メタデータフラグメント内の位置情報（ＴＶＡではキーとして使われるノードの該当フラグメント内の相対経路に対するＸＰａｔｈ（ｋｅｙ＿ｘｐａｔｈ＿ｐｔｒ）で表現される）とが含まれる。

前記メタデータフラグメントのＸＰａｔｈはＴＶＡメタデータＸＭＬ文書のルートノードに対する経路、すなわち、絶対経路である。そして、キーとして使われるノードのＸｐａｔｈ、すなわち、キーのＸＰａｔｈは関連メタデータフラグメントに対するキーの相対経路を示す。メタデータフラグメントに対するＸｐａｔｈ及びキーに対するＸｐａｔｈは各々‘ｆｒａｇｍｅｎｔ＿ｘｐａｔｈ＿ｐｔｒ’セグメント１１と‘ｋｅｙ＿ｘｐａｔｈ＿ｐｔｒ’セグメント１２に保存される。

また、キーインデックスリスト（ｋｅｙ＿ｉｎｄｅｘ＿ｌｉｓｔ）セクション１０には後述される各キーのキーインデックス（ｋｅｙ＿ｉｎｄｅｘ）セクション２０に関する識別情報（すなわち、キーインデックス（ｋｅｙ＿ｉｎｄｅｘ）セクション２０が保存されたコンテナのコンテナ識別子情報（ｃｏｎｔａｉｎｅｒ＿ｉｄ）及びキーインデックス識別子情報）が含まれるが、前記コンテナ識別子情報及びキーインデックス識別子情報は各々キーインデックスリスト（ｋｅｙ＿ｉｎｄｅｘ＿ｌｉｓｔ）セクション１０の‘ｉｎｄｅｘ＿ｃｏｎｔａｉｎｅｒ’セグメント及び‘ｋｅｙ＿ｉｎｄｅｘ＿ｉｄｅｎｔｉｆｉｅｒ’セグメントに保存されて転送される。

従来のインデックス構造で定義されるキーインデックス（ｋｅｙ＿ｉｎｄｅｘ）セクション２０は、後述されるあらゆるサブキーインデックス（ｓｕｂ＿ｋｅｙ＿ｉｎｄｅｘ）セクション３０のリストを提供するが、このリストには、各サブキーインデックス（ｓｕｂ＿ｋｅｙ＿ｉｎｄｅｘ）セクション３０に含まれたキー値の範囲を示す情報、すなわち、各サブキーインデックス（ｓｕｂ＿ｋｅｙ＿ｉｎｄｅｘ）セクション３０内のキー値のうち最大のキー値（以下‘代表キー値’）、及び各代表キー値に関連したサブキーインデックス（ｓｕｂ＿ｋｅｙ＿ｉｎｄｅｘ）セクション３０に関する識別情報（すなわち、サブキーインデックス（ｓｕｂ＿ｋｅｙ＿ｉｎｄｅｘ）セクションが保存されたコンテナのコンテナ識別子情報（ｃｏｎｔａｉｎｅｒ＿ｉｄ）及びサブキーインデックス識別子情報）が含まれる。

したがって、キーインデックス（ｋｅｙ＿ｉｎｄｅｘ）セクション２０は、キーインデックスリスト（ｋｅｙ＿ｉｎｄｅｘ＿ｌｉｓｔ）セクション１０で定義されたキーインデックス識別子情報が保存される‘ｋｅｙ＿ｉｎｄｅｘ＿ｉｄｅｎｔｉｆｉｅｒ’セグメントと、各サブキーインデックス（ｓｕｂ＿ｋｅｙ＿ｉｎｄｅｘ）セクション３０の代表キー値が保存された‘ｈｉｇｈ＿ｋｅｙ＿ｖａｌｕｅ’セグメント１３と、サブキーインデックス（ｓｕｂ＿ｋｅｙ＿ｉｎｄｅｘ）セクション３０が保存されたコンテナのコンテナ識別子情報（ｃｏｎｔａｉｎｅｒ＿ｉｄ）と、サブキーインデックス識別子情報が各々保存された‘ｓｕｂ＿ｉｎｄｅｘ＿ｃｏｎｔａｉｎｅｒ’セグメント及び‘ｓｕｂ＿ｉｎｄｅｘ＿ｉｄｅｎｔｉｆｉｅｒ’セグメントを含む。

従来のインデックス構造で定義されるサブキーインデックス（ｓｕｂ＿ｋｅｙ＿ｉｎｄｅｘ）セクション３０は、該当サブキーインデックス（ｓｕｂ＿ｋｅｙ＿ｉｎｄｅｘ）セクション３０に含まれたキー値に対するリストを提供するが、このリストには該当サブキーインデックス（ｓｕｂ＿ｋｅｙ＿ｉｎｄｅｘ）セクション３０に含まれたキー値及び前記キー値を有するメタデータフラグメントに関する識別情報（すなわち、メタデータフラグメントが保存されたコンテナのコンテナ識別子情報（ｃｏｎｔａｉｎｅｒ＿ｉｄ）と前記メタデータフラグメントの識別子情報（ｈａｎｄｌｅ＿ｖａｌｕｅ））が含まれる。

したがって、サブキーインデックス（ｓｕｂ＿ｋｅｙ＿ｉｎｄｅｘ）セクション３０はキーインデックス（ｋｅｙ＿ｉｎｄｅｘ）セクション２０で定義されたサブキーインデックス識別子情報が保存される‘ｓｕｂ＿ｉｎｄｅｘ＿ｉｄｅｎｔｉｆｉｅｒ’セグメントと、キー値が保存される‘ｋｅｙ＿ｖａｌｕｅ’セグメント１４と、前記キー値を有するメタデータフラグメントに関する識別情報としてメタデータフラグメントが保存されたコンテナのコンテナ識別子情報（ｃｏｎｔａｉｎｅｒ＿ｉｄ）が保存された‘ｔａｒｇｅｔ＿ｃｏｎｔａｉｎｅｒ’セグメントと、フラグメントデータ識別子情報（ｈａｎｄｌｅ＿ｖａｌｕｅ）が保存された‘ｔａｒｇｅｔ＿ｈａｎｄｌｅ’セグメントとを含む。

前記インデックス構造はインデックス情報を例示的に示す図７を通じてさらに容易に理解されうる。
図７は、チャンネル番号、放送時間及び放送再生時間に対するキーを含むキーインデックスリスト（ｋｅｙ＿ｉｎｄｅｘ＿ｌｉｓｔ）セクションを示しており、前記チャンネル番号、放送時間及び放送再生時間に関するキーと関連したメタデータフラグメントの上位ノードは図３に示された‘ＢｒｏａｄｃａｓｔＥｖｅｎｔ’３１０である。したがって、‘ｆｒａｇｍｅｎｔ＿ｘｐａｔｈ＿ｐｔｒ’セグメント１１には、‘ＢｒｏａｄｃａｓｔＥｖｅｎｔ’フラグメントに対するＸＰａｔｈ‘／ＴＶＡＭａｉｎ／ＰｒｏｇｒａｍＤｅｓｃｒｉｐｔｉｏｎ／ＰｒｏｇｒａｍＬｏｃａｔｉｏｎＴａｂｌｅ／ＢｒｏａｄｃａｓｔＥｖｅｎｔ’が保存され、‘ｋｅｙ＿ｘｐａｔｈ＿ｐｔｒ’セグメント１２には‘ＢｒｏａｄｃａｓｔＥｖｅｎｔ’フラグメントに対するチャンネル番号、放送時間、及び放送再生時間のキーのＸｐａｔｈである‘＠ＳｅｒｖｉｃｅＩｄ’（図３の３１１ａ）、‘ＥｖｅｎｔＤｅｓｃｒｉｐｔｉｏｎ／ＰｕｂｌｉｓｈｅｄＴｉｍｅ’（図３の３１１ｂ）及び‘ＥｖｅｎｔＤｅｓｃｒｉｐｔｉｏｎ／Ｐｕｂｌｉｓｈｅｄ Ｄｕｒａｔｉｏｎ’（図３の３１１ｃ）が各々保存される。

参考に、図７はキーインデックスリスト（ｋｅｙ＿ｉｎｄｅｘ＿ｌｉｓｔ）セクションのうちチャンネル番号（キーのＸＰａｔｈ：＠ＳｅｒｖｉｃｅＩｄ）に対するキーインデックス（ｋｅｙ＿ｉｎｄｅｘ）セクション２０及びサブキーインデックス（ｓｕｂ＿ｋｅｙ＿ｉｎｄｅｘ）セクション３０を示す。このようなインデックス構造は、メタデータ検索のために検索条件が入力され、前記入力された検索条件のフィールドに対するメタデータにおける位置情報を判断し、前記判断された位置情報を有するキーをキーインデックスリスト内で検索するために前記判断された位置情報を前記キーインデックスリスト内のキー情報と比較する時、両側のＸＰａｔｈを比較せねばならないオーバーヘッドを発生させてしまう。かかる問題はキー情報のうちフラグメントからの相対経路を示すキーの位置情報に対する比較でも同様であるが、特にキーの位置情報よりさらに複雑であるフラグメントの位置情報の比較において一層深刻である。キー情報のうちフラグメントの位置情報を示すフラグメントのＸＰａｔｈはその記述形態がＸＭＬ文書上でルートから該当ノードまでの経路を記述する方式なので、転送費用面において非効率的であり、かつ端末機でＸＰａｔｈを解釈するのにも多くの費用がかかる。例えば、ＴＶＡフラグメントのうちからプログラム位置情報を示すブロードキャストイベントフラグメントをＸＰａｔｈで表現すれば、‘／ＴＶＡＭａｉｎ／ＰｒｏｇｒａｍＤｅｓｃｒｉｐｔｉｏｎ／ＰｒｏｇｒａｍＬｏｃａｔｉｏｎＴａｂｌｅ／ＢｒｏａｄｃａｓｔＥｖｅｎｔ’と表わされる。ところで、ＸＰａｔｈはＸＭＬ文書上の１ノードを示す時に多様な方法による表現が可能となる。ブロードキャストイベントの場合、前述した正規の表現以外にも、／ＴＶＡＭａｉｎ／／ＢｒｏａｄｃａｓｔＥｖｅｎｔ、／／ＢｒｏａｄｃａｓｔＥｖｅｎｔなどのように多様に表現されうる。ここで‘／／’はＸＭＬ文書構造上、子ノードを意味する。したがって、ＸＰａｔｈを用いて同一のフラグメントの位置情報であるか否かを検査する演算は、単純なストリングを相互マッチングさせる単純な演算ではなく、特にＸＰａｔｈ経路が簡潔な形式で表現される場合には該当経路を分析／比較せねばならないためにオーバーヘッドが発生してしまう。

前述した問題点を解決するために提案された本発明は、コンテンツに関する情報を迅速に検索可能にエンコーディングされたキー情報を含むメタデータのインデックス構造を提供することにその目的がある。
また本発明は、コンテンツに関する情報を迅速に検索できるメタデータのインデックスを提供する方法と、前記メタデータのインデックスを用いたメタデータを検索する方法と、これを用いた検索装置を提供することにその目的がある。

前述した目的を達成するための本発明の一実施例に係るメタデータのインデックス構造は、メタデータの所定フィールドで構成されるキーのリストを含むが、前記リストは前記メタデータにおける前記フィールドの位置情報を含み、前記位置情報の少なくとも一部は所定のコードで表現される。
前記実施例において、前記キー値及び前記キー値に対応するメタデータの識別情報をさらに含むことが望ましい。

一方、前記実施例で、前記メタデータはツリー構造のデータ構造を有し、前記ツリー構造の所定範囲別に分割されたフラグメントで構成され、前記キーを構成するフィールドは前記フラグメントを構成する情報のうち何れか１つであることが望ましい。
また、前記実施例において、前記メタデータの識別情報は前記フラグメントの識別情報であることが望ましい。

また、前記実施例において、前記位置情報は、前記キーを構成するフィールドが属するフラグメントの前記データ構造内の位置情報、及び前記フィールドの前記フラグメント内の位置情報を含むことが望ましい。
また、前記実施例において、前記前記データ構造内の位置情報または前記フラグメント内の位置情報が所定のコードで表現されることが望ましい。
また、前記実施例において、前記位置情報の少なくとも一部はＸＰａｔｈで表現されることが望ましい。

また、前記実施例において、前記コードは使用頻度の相対的に高い位置情報に対してあらかじめ与えられたコードであることが望ましい。
また、前記実施例において、前記キー値の所定範囲を代表する代表キー値をさらに含むことが望ましい。
また、前記実施例において、前記代表キー値は該当する範囲の値のうち、最大値、最小値または中間値であることが望ましい。
また、前記実施例において、前記メタデータはＴＶＡで定義するメタデータの構造を有することが望ましい。

前述した目的を達成するための本発明の一実施例に係るメタデータのインデックスを提供する方法は、メタデータの所定フィールドで構成されるキーのリストを含むメタデータのインデックスを提供するが、前記リストは前記メタデータにおける前記フィールドの位置情報を含み、前記位置情報の少なくとも一部は所定のコードで表現される。
前記実施例において、前記メタデータのインデックスは前記キー値及び前記キー値に対応するメタデータの識別情報をさらに含むことが望ましい。

前記実施例で、前記メタデータはツリー構造のデータ構造を有し、前記ツリー構造の所定範囲別に分割されたフラグメントで構成され、前記キーを構成するフィールドは前記フラグメントを構成する情報のうち何れか１つであることが望ましい。
また、前記実施例において、前記メタデータの識別情報は前記フラグメントの識別情報であることが望ましい。

また、前記実施例において、前記位置情報は、前記キーを構成するフィールドが属するフラグメントの前記データ構造内の位置情報、及び前記フィールドの前記フラグメント内の位置情報を含むことが望ましい。
また、前記実施例において、前記前記データ構造内の位置情報または前記フラグメント内の位置情報が所定のコードで表現されることが望ましい。
また、前記実施例において、前記位置情報の少なくとも一部はＸＰａｔｈで表現されることが望ましい。

また、前記実施例において、前記コードは使用頻度の相対的に高い位置情報に対してあらかじめ与えられたコードであることが望ましい。
また、前記実施例において、 前記メタデータのインデックスは前記キー値の所定範囲を代表する代表キー値をさらに含むことが望ましい。
また、前記実施例において、前記代表キー値は該当する範囲の値のうち、最大値、最小値または中間値であることが望ましい。
また、前記実施例において、前記メタデータはＴＶＡで定義するメタデータの構造を有することが望ましい。

前述した目的を達成するための本発明の一実施例に係るメタデータの検索方法は、入力された検索条件のフィールドに対するメタデータにおける位置情報を判断する段階、前記位置情報の少なくとも一部が所定のコードで定義されている場合、前記定義されたコードを位置情報として含むキーをメタデータのインデックスから検索する段階、及び前記検索されたキーを用いて該当メタデータを抽出する段階を含む。

前記実施例において、 前記メタデータのインデックスは前記キー値及び前記キー値に対応するメタデータの識別情報をさらに含むことが望ましい。
前記実施例で、前記メタデータはツリー構造のデータ構造を有し、前記ツリー構造の所定範囲別に分割されたフラグメントで構成され、前記キーを構成するフィールドは前記フラグメントを構成する情報のうち何れか１つであることが望ましい。

また、前記実施例において、前記メタデータの識別情報は前記フラグメントの識別情報であることが望ましい。
また、前記実施例において、前記位置情報は、前記キーを構成するフィールドが属するフラグメントの前記データ構造内の位置情報、及び前記フィールドの前記フラグメント内の位置情報を含むことが望ましい。

また、前記実施例において、前記前記データ構造内の位置情報または前記フラグメント内の位置情報が所定のコードで表現されることが望ましい。
また、前記実施例において、前記位置情報の少なくとも一部はＸＰａｔｈで表現されることが望ましい。
また、前記実施例において、前記コードは使用頻度の相対的に高い位置情報に対してあらかじめ与えられたコードであることが望ましい。

また、前記実施例において、 前記メタデータのインデックスはキーのリストをさらに含むことが望ましい
また、前記実施例において、 前記メタデータのインデックスは前記キー値の所定範囲を代表する代表キー値をさらに含むことが望ましい。
また、前記実施例において、前記代表キー値は該当する範囲の値のうち最大値、最小値または中間値であることが望ましい。

また、前記実施例において、前記メタデータはＴＶＡで定義するメタデータの構造を有することが望ましい。
また、前記実施例において、前記キーを検索する段階は、前記前記データ構造内の位置情報または前記フラグメント内の位置情報が所定のコードで定義されている場合、前記定義されたコードを位置情報として含むキーをキーのリストから検索する段階であることが望ましい。

また、前記実施例において、前記メタデータを抽出する段階は、前記検索されたキーがインデクシングするキー値から前記入力された検索条件に符合するキー値を検索する段階、及び前記検索されたキー値を用いて該当メタデータを抽出する段階を含むことが望ましい。
また、前記実施例において、前記検索されたキーがインデクシングするキー値から前記入力された検索条件に符合するキー値を検索する段階は、前記入力された検索条件に符合する代表キー値を検索する段階、及び前記代表キー値が代表する範囲のキー値から前記入力された検索条件に符合するキー値を検索する段階を含むことが望ましい。

前述した目的を達成するための本発明の一実施例に係るメタデータの検索装置は、検索条件を入力される入力部、及び前記入力された検索条件のフィールドに対応するメタデータにおける位置情報を判断し、前記位置情報の少なくとも一部が所定のコードで定義されている場合、前記定義されたコードを位置情報として含むキーをメタデータのインデックスから検索し、そして前記検索されたキーを用いて該当メタデータを抽出する制御部を含む。

前記実施例において、 前記メタデータのインデックスは前記キー値及び前記キー値に対応するメタデータの識別情報をさらに含むことが望ましい。
前記実施例で、前記メタデータはツリー構造のデータ構造を有し、前記ツリー構造の所定範囲別に分割されたフラグメントで構成され、前記キーを構成するフィールドは前記フラグメントを構成する情報のうち何れか１つであることが望ましい。

また、前記実施例において、前記メタデータの識別情報は前記フラグメントの識別情報であることが望ましい。
また、前記実施例において、前記位置情報は、前記キーを構成するフィールドが属するフラグメントの前記データ構造内の位置情報、及び前記フィールドの前記フラグメント内の位置情報を含むことが望ましい。
また、前記実施例において、前記前記データ構造内の位置情報または前記フラグメント内の位置情報が所定のコードで表現されることが望ましい。

また、前記実施例において、前記位置情報の少なくとも一部はＸＰａｔｈで表現されることが望ましい。
また、前記実施例において、前記コードは使用頻度の相対的に高い位置情報に対してあらかじめ与えられたコードであることが望ましい。
また、前記実施例において、 前記メタデータのインデックスはキーのリストをさらに含むことが望ましい。

また、前記実施例において、 前記メタデータのインデックスは前記キー値の所定範囲を代表する代表キー値をさらに含むことが望ましい。
また、前記実施例において、前記代表キー値は該当する範囲の値のうち最大値、最小値または中間値であることが望ましい。
また、前記実施例において、前記メタデータはＴＶＡで定義するメタデータの構造を有することが望ましい。

また、前記実施例においてメタデータを受信する受信部、受信されたメタデータを保存する保存部、及び前記制御部による検索結果を出力する出力部をさらに含むことが望ましい。
したがって、メタデータに対する検索をエンコーディングされたキー情報を用いてより効率的に行える。

このような特徴を有するコンテンツに関する情報を検索するために提供されるメタデータのインデックス構造と、前記メタデータのインデックス構造を有するメタデータのインデックスを提供する方法と、前記メタデータのインデックスを用いたメタデータの検索方法とそれを利用した検索装置の実施例を添付した図面を参照して説明すれば次の通りである。

以下で前記実施例はＴＶＡメタデータに基づいて説明するが、本発明がこれに限定されると解釈すべきではない。
まず、コンテンツに関する情報、すなわち、メタデータを検索するためのメタデータのインデックス構造として、前述したデータコンテナに保存されているＴＶＡメタデータフラグメントをインデックスするために、エンコーディングされたキー情報を含むインデックス構造、すなわちキーインデックスリスト（ｋｅｙ＿ｉｎｄｅｘ＿ｌｉｓｔ）セクション１１０、キーインデックス（ｋｅｙ＿ｉｎｄｅｘ）セクション１２０、及びサブキーインデックス（ｓｕｂ＿ｋｅｙ＿ｉｎｄｅｘ）セクション１３０の構造を定義するシンタックスを説明し、以後前記シンタックスにより定義されるエンコーディングされたキー情報を含むインデックス構造について説明する。

本発明の一実施例に係るメタデータのインデックス構造、特にエンコーディングされたキー情報を含むインデックス構造を定義するシンタックスは、従来のキーインデックス技術文献に定義されたシンタックスとは違ってｆｒａｇｍｅｎｔ＿ｄｅｓｃｒｉｐｔｏｒ（）、ｋｅｙ＿ｄｅｓｃｒｉｐｔｏｒ（）のようなキー情報のエンコーディング概念のために新しく導入された構造を含み、キーインデックスリスト（ｋｅｙ＿ｉｎｄｅｘ＿ｌｉｓｔ）セクション、キーインデックス（ｋｅｙ＿ｉｎｄｅｘ）セクション、及びサブキーインデックス（ｓｕｂ＿ｋｅｙ＿ｉｎｄｅｘ）セクションの構造を再編成する。

参考に、前述したようにキーインデックスリスト（ｋｅｙ＿ｉｎｄｅｘ＿ｌｉｓｔ）セクション１１０には各キーを定義するキー情報と、後述するキーインデックス（ｋｅｙ＿ｉｎｄｅｘ）セクション１２０に関する識別情報とが含まれる。

キー情報はキーを定義するための情報であって、キーを構成するメタデータの所定フィールドが有する前記メタデータにおける位置情報を意味するが、前記キー情報はキーを構成するフィールドが属するメタデータフラグメントが前記メタデータ内で有する位置情報（以下‘フラグメントの位置情報’、ＴＶＡではフラグメントＸＰａｔｈ（ｆｒａｇｍｅｎｔ＿ｘｐａｔｈ＿ｐｔｒ）と表現される）と、前記キーを構成するフィールドが前記メタデータフラグメント内で有する位置情報（以下、‘キーの位置情報’、即ちＴＶＡにおいてキーとして使われるノードの関連メタデータフラグメント内のＸＰａｔｈ位置での相対経路に対するＸＰａｔｈであり、キーのＸＰａｔｈ（ｋｅｙ＿ｘｐａｔｈ＿ｐｔｒ）で表現される）とを含む。

１．キーインデックスリスト（ｋｅｙ＿ｉｎｄｅｘ＿ｌｉｓｔ）セクション
キーインデックスリスト（ｋｅｙ＿ｉｎｄｅｘ＿ｌｉｓｔ）セクションは転送されるあらゆるキーのリストを提供する。従来技術のキーインデックスリスト（ｋｅｙ＿ｉｎｄｅｘ＿ｌｉｓｔ）セクション内のフラグメントの位置情報（ＴＶＡではフラグメントのＸＰａｔｈで表現される）を示すｆｒａｇｍｅｎｔ＿ｘｐａｔｈ＿ｐｔｒは、ｆｒａｇｍｅｎｔ＿ｄｅｓｃｒｉｐｔｏｒ（）に置き換えられる。

ｋｅｙ＿ｉｎｄｅｘ＿ｃｏｕｎｔ： 転送されるあらゆるキーの数、すなわち、全体ＸＭＬ文書に対するインデックス数を定める。
ｆｒａｇｍｅｎｔ＿ｄｅｓｃｒｉｐｔｏｒ（）： インデクシングされる目標フラグメントのＸＰａｔｈ位置、すなわちフラグメントの位置情報が所定のコードで表現される場合、表３の標準フラグメントタイプと同じフラグメントのタイプを定める。参考に、前記フラグメントのタイプは表３の標準フラグメントタイプに限定されるものではなく、キーを定義するためのフラグメントのＸＰａｔｈを示しうる任意の形態（例えば、一部はＸＰａｔｈ、残りはエンコーディングされたコード値）でありうる。

ｋｅｙ＿ｄｅｓｃｒｉｐｔｏｒ（）： インデクシングされる目標フラグメントグループのＸＰａｔｈ位置内でキーのＸＰａｔｈ、すなわち、キーの位置情報が所定のコードで表現される場合、標準キーのタイプと同じキーのタイプを定める。前記キーのタイプが標準キータイプに限定されないことはｆｒａｇｍｅｎｔ＿ｄｅｓｃｒｉｐｔｏｒ（）に対する説明部分で言及した通りである。

ｉｎｄｅｘ＿ｃｏｎｔａｉｎｅｒ： 指定されたキーインデックス（ｋｅｙ＿ｉｎｄｅｘ）セクションが存在するコンテナを識別する。
ｋｅｙ＿ｉｎｄｅｘ＿ｉｄｅｎｔｉｆｉｅｒ： ｉｎｄｅｘ＿ｃｏｎｔａｉｎｅｒにより詳述されたコンテナ内のキーインデックス（ｋｅｙ＿ｉｎｄｅｘ）セクションを識別する。ｉｎｄｅｘ＿ｃｏｎｔａｉｎｅｒとｋｅｙ＿ｉｎｄｅｘ＿ｉｄｅｎｔｉｆｉｅｒとの組合わせによって該当するインデックス（ｋｅｙ＿ｉｎｄｅｘ）セクションが唯一に識別されうる。

２．フラグメントデスクリプタ(ｆｒａｇｍｅｎｔ＿ｄｅｓｃｒｉｐｔｏｒ)
ｆｒａｇｍｅｎｔ＿ｄｅｓｃｒｉｐｔｏｒは頻繁に使われる標準フラグメントタイプに対して所定ビット（８ビット、１６ビットなど任意のビットでエンコーディング可能）、所定コードでエンコーディングする構造を提供すると同時に、ユーザーが定義するメタデータフラグメントタイプに対しては追加情報としてＸＰａｔｈを記述しうる構造を提供する。すなわち、ｆｒａｇｍｅｎｔ＿ｄｅｓｃｒｉｐｔｏｒが‘０ｘＦＦ’である場合にはユーザー定義フラグメントを示すので、即座に該当ユーザー定義フラグメントに対するＸＰａｔｈが記述される。

ｆｒａｇｍｅｎｔ＿ｔｙｐｅ： インデクシングされるフラグメントのタイプを示す。頻繁に使われる標準フラグメントタイプに対してエンコーディング値が与えられる。もし、ｆｒａｇｍｅｎｔ＿ｔｙｐｅが０ｘＦＦのエンコーディング値を有する場合には追加情報としてｆｒａｇｍｅｎｔ＿ｘｐａｔｈ＿ｐｔｒが付加される。表３はＴＶＡで検索時、使用頻度の高いフラグメント（以下、標準フラグメント）の位置情報に対する例示的なエンコーディング値を示しているが、本発明において標準フラグメントタイプ及びエンコーディング値が表３に限定されるものではなく、応用例によってさらに拡張されうる。

３．キーデスクリプタ
ｋｅｙ＿ｄｅｓｃｒｉｐｔｏｒは、検索時使用頻度の高いキー（以下‘標準キー’）の位置情報に対して所定ビットでエンコーディングする構造を提供すると同時に、ユーザーが定義するキータイプに対してＸＰａｔｈでも記述できる構造を提供する。例えば、ｋｅｙ＿ｄｅｓｃｒｉｐｔｏｒが‘０ｘＦＦ’である場合にはユーザー定義キーを示すので、ユーザーが定義するキーに対してはＸＰａｔｈが追加情報として記述される。

ｋｅｙ＿ｔｙｐｅ： インデクシングされるキーのタイプを示す。検索時に使用頻度の高い標準キーの位置情報に対してエンコーディング値が与えられる。もし、ｋｅｙ＿ｔｙｐｅが‘０ｘ０Ｆ’のエンコーディング値を有する場合には追加情報としてｋｅｙ＿ｘｐａｔｈ＿ｐｔｒが付加される。
ｋｅｙ＿ｘｐａｔｈ＿ｐｔｒ： キーとして使われるノードのフラグメントＸＰａｔｈに関連した相対経路である。

本明細書では標準キータイプに対するエンコーディング値を明示していないが、標準キータイプに対するエンコーディング値は表３のフラグメントタイプエンコーディングと類似した構造を有すると理解されうる。

４．キーインデックス（ｋｅｙ＿ｉｎｄｅｘ）セクション
キーインデックス（ｋｅｙ＿ｉｎｄｅｘ）セクション及びサブキーインデックス（ｓｕｂ＿ｋｅｙ＿ｉｎｄｅｘ）セクションの定義は従来のキーインデックス記述文献と同一なので、その詳細な説明は省略する。

５．サブキーインデックス（ｓｕｂ＿ｋｅｙ＿ｉｎｄｅｘ）セクション
以下、前述したシンタックスにより定義されるメタデータ構造をインデックス情報のセグメントで表現した図８を参照して説明する。インデックス構造で定義されるキーインデックスリスト（ｋｅｙ＿ｉｎｄｅｘ＿ｌｉｓｔ）セクション１１０は、転送されるあらゆるキーのリストを提供する。このリストには各キーを定義するキー情報と、後述されるキーインデックス（ｋｅｙ＿ｉｎｄｅｘ）セクション１２０に関する識別情報とが含まれる。前記キー情報には、（１）フラグメントの位置情報（ｆｒａｇｍｅｎｔ＿ｄｅｓｃｒｉｐｔｏｒ）、及び／または（２）キーの位置情報（ｋｅｙ＿ｄｅｓｃｒｉｐｔｏｒ）とが含まれる。実施例によって、前記フラグメントの位置情報または前記キーの位置情報は選択的にエンコーディングされるか、同時にエンコーディングされうる。参考に、従来のインデックス構造と同様に、前記メタデータフラグメントのＸＰａｔｈはＴＶＡメタデータＸＭＬ文書のルートノードに対する経路であって絶対経路であり、キーとして使われるノードのＸｐａｔｈ、すなわち、キーのＸＰａｔｈは前記メタデータフラグメントに対するキーの相対経路を示し、前記メタデータフラグメントのＸＰａｔｈ及びキーのＸＰａｔｈは相互結合して全体ＸＭＬ文書に対するキーの位置情報を示す。

本発明でメタデータフラグメントに対するＸＰａｔｈ（すなわち、フラグメントグループの位置情報）をエンコーディングしたエンコーディング値とキーのＸＰａｔｈ（すなわち、キーの位置情報）をエンコーディングしたエンコーディング値は各々‘ｆｒａｇｍｅｎｔ＿ｄｅｓｃｒｉｐｔｏｒ’セグメント１１１と‘ｋｅｙ＿ｄｅｓｃｒｉｐｔｏｒ’セグメント１１２に保存される。

前述したように、本発明ではキー情報のうちフラグメントの位置情報が頻繁に使用される標準フラグメントタイプである場合、メタデータフラグメントに対するＸＰａｔｈ（ｆｒａｇｍｅｎｔ＿ｘｐａｔｈ＿ｐｔｒ）を所定のコードで表現したエンコーディング値（ｆｒａｇｍｅｎｔ＿ｄｅｓｃｒｉｐｔｏｒ）として提供する。頻繁に使われる標準フラグメントタイプとしては、例えば、プログラム情報、プログラムグループ情報、クレジット情報、プログラムレビュー、セグメント情報、ブロードキャストイベント、サービス情報などがある。このようなフラグメントタイプに対するメタデータフラグメントのＸＰａｔｈを簡単にエンコーディングされた値で表すことができるならば、メタデータ検索によるオーバーヘッドを減少させうる。

したがって、本発明に係るインデックス構造では標準メタデータフラグメントのＸＰａｔｈを所定のエンコーディング値にエンコーディングして保存する。また、ユーザーが追加的にメタデータフラグメントに関する位置情報をＸＰａｔｈとして定義できるようにあらゆるエンコーディング値をフラグメントに割り当てず、一部のエンコーディング値（例えば、‘０ＸＦＦ’）をユーザーが定義するメタデータフラグメントに割り当てる。この場合、例えば、メタデータフラグメントに対するＸＰａｔｈを指定できる追加領域（表２の‘ｆｒａｇｍｅｎｔ＿ｘｐａｔｈ＿ｐｔｒ’）が提供される。

表３のようにエンコーディングされた実施例で、キー情報のうちメタデータフラグメントの位置情報は、‘０ｘ０１’、‘０ｘ０２’、‘０ｘ０３’などのエンコーディングされた値であり、‘０ｘ０１’にエンコーディングされたメタデータフラグメントの位置情報は‘プログラム情報フラグメント’のＸＰａｔｈを示す。またメタデータフラグメントの位置情報が‘０ｘＦＦ’である場合にはユーザーが定義するメタデータフラグメントを意味するので、追加的にメタデータフラグメントのＸＰａｔｈを指定できる追加領域が提供される。

前記実施例は、メタデータフラグメントについてのみ叙述したが、前記メタデータフラグメントに対するキーについても同一である。頻繁に使われるキーに対しては従来のキーＸＰａｔｈではないエンコーディングされた値を指定して使用でき、またエンコーディングされた値のうち所定の値である場合には、ユーザーが追加的にキーに関するＸＰａｔｈを指定できる。前述したメタデータフラグメントＸＰａｔｈのエンコーディングとキーＸＰａｔｈのエンコーディングは同時に使われるか、または相互独立的に使用されうる。

また、キーインデックスリスト（ｋｅｙ＿ｉｎｄｅｘ＿ｌｉｓｔ）セクション１１０には後述する各キーのキーインデックス（ｋｅｙ＿ｉｎｄｅｘ）セクション１２０に関する識別情報（すなわち、キーインデックス（ｋｅｙ＿ｉｎｄｅｘ）セクション１２０が保存されたコンテナのコンテナ識別子情報（ｃｏｎｔａｉｎｅｒ＿ｉｄ）及びキーインデックス識別子情報）が含まれるが、前記コンテナ識別子情報及びキーインデックス識別子情報は各々キーインデックスリスト（ｋｅｙ＿ｉｎｄｅｘ＿ｌｉｓｔ）セクション１１０の‘ｉｎｄｅｘ＿ｃｏｎｔａｉｎｅｒ’セグメント及び‘ｋｅｙ＿ｉｎｄｅｘ＿ｉｄｅｎｔｉｆｉｅｒ’セグメントに保存される。

キーインデックス（ｋｅｙ＿ｉｎｄｅｘ）セクション１２０及びサブキーインデックス（ｓｕｂ＿ｋｅｙ＿ｉｎｄｅｘ）セクション１３０は、従来のキーインデックス文献と同一なので、これについての説明は省略する。

前記エンコーディングされたキー情報を含むインデックス構造は、前記インデックス情報を例示的に示す図９を参照して詳細に説明する。
図９は、チャンネル番号に対する‘ブロードキャストイベント’フラグメントのＸＰａｔｈが‘０ｘ０７’にエンコーディングされたキーインデックスリストセクション１１０を示しており、キーインデックス（ｋｅｙ＿ｉｎｄｅｘ）セクション１２０及びサブキーインデックス（ｋｅｙ＿ｉｎｄｅｘ）セクション１３０は図７の説明と同一である。

このようなインデックス構造は頻繁に使われるフラグメントタイプ、例えば、プログラム情報、グループ情報、ブロードキャストイベントなどのフラグメントに関連したキーを使用する時に非常に効果的であり、受信装置における全体的なオーバーヘッドを減少させうる。

図１０は、前述した本発明の一実施例に係る構造を有するメタデータのインデックスを提供する方法を示す。
本発明の一実施例に係るメタデータのインデックスは、例えば映像／音声信号を提供する提供者２００により生成されうる。

まず、コンテンツに関する情報、すなわち、メタデータを前述したフラグメント単位で加工する（Ｓ１００）。次いで、メタデータのインデックスに含められるフィールドに対する情報、すなわち、キーに関する情報（例えば、フラグメントの位置情報及びキーの位置情報）の少なくとも一部（フラグメントの位置情報またはキーの位置情報）をエンコーディングする（Ｓ２００）。すなわち、キーを構成するフィールドが属するメタデータフラグメントの位置情報またはキーの位置情報が、エンコーディングされうる標準フラグメントタイプまたは標準キータイプである場合、前記メタデータフラグメントの位置情報またはキーの位置情報、すなわち、ＴＶＡでのメタデータフラグメントのＸＰａｔｈまたはキーＸＰａｔｈは、所定のコード値にエンコーディングされる（例えば、図９で‘ブロードキャストイベント’フラグメントは‘０Ｘ０７’にエンコーディングされる）。もし、メタデータフラグメントの位置情報またはキーの位置情報がエンコーディング値により識別できない場合には従来のようにＸＰａｔｈで表現されたキー情報を指定する。

前記フラグメントを構成する情報、例えば‘チャンネル番号’に関する情報を用いてキーを提供する（Ｓ３００）。次いで、前記提供されたキー別にサブキーインデックス（ｓｕｂ＿ｋｅｙ＿ｉｎｄｅｘ）セクション１１４が提供されるが（Ｓ４００）、前記サブキーインデックス（ｓｕｂ＿ｋｅｙ＿ｉｎｄｅｘ）セクション１１４には所定範囲別に分割された前記キー値が含まれ、前記サブキーインデックス（ｓｕｂ＿ｋｅｙ＿ｉｎｄｅｘ）セクション１１４には、前記キー値に該当するメタデータフラグメント識別情報（すなわち、図８の‘ｔａｒｇｅｔ＿ｃｏｎｔａｉｎｅｒ’セグメント及び‘ｔａｒｇｅｔ＿ｈａｎｄｌｅ’セグメントに各々保存されたコンテナ識別子情報（ｃｏｎｔａｉｎｅｒ＿ｉｄ）とフラグメントデータ識別子情報（ｈａｎｄｌｅ＿ｖａｌｕｅ））が含まれる。

次いで、前記所定範囲別に分割されたキー値を代表する代表キー値を含むキーインデックス（ｋｅｙ＿ｉｎｄｅｘ）セクション１２０を提供するが（Ｓ５００）、例えば前記チャンネル番号の所定範囲（例えば、５００〜５０９）を示す代表キー値（例えば、５０９）が含まれる。前記キーインデックス（ｋｅｙ＿ｉｎｄｅｘ）セクション１２０には、前記所定範囲別に分割されたキー値が保存されたサブキーインデックス（ｓｕｂ＿ｋｅｙ＿ｉｎｄｅｘ）セクション１１４ａ、１１４ｂに関する識別情報（すなわち、図８のサブキーインデックス（ｓｕｂ＿ｋｅｙ＿ｉｎｄｅｘ）セクションが保存されたコンテナのコンテナ識別子情報（ｃｏｎｔａｉｎｅｒ＿ｉｄ）及びサブキーインデックス識別子情報）が含まれる。

一方、前記提供されたキーの情報、すなわちフラグメントの位置情報及びキーの位置情報をキー別に配列するキーインデックスリスト（ｋｅｙ＿ｉｎｄｅｘ＿ｌｉｓｔ）セクション１１０を提供する（Ｓ６００）。この際、段階Ｓ２００でエンコーディングされたフラグメントの位置情報またはキーの位置情報が存在するならば、キーインデックスリスト（ｋｅｙ＿ｉｎｄｅｘ＿ｌｉｓｔ）セクション１１０を提供する時、前記位置情報はエンコーディングされたコードで表現される。例えば、図９で‘ブロードキャストイベント’フラグメントは‘０Ｘ０７’で表現され、もしエンコーディング値により識別できないフラグメントの位置情報またはキーの位置情報である場合には従来のようにＸＰａｔｈで表現されたキー情報として挿入される。一方、キーインデックスリスト（ｋｅｙ＿ｉｎｄｅｘ＿ｌｉｓｔ）セクション１１０は前記キー情報以外に、キーインデックス（ｋｅｙ＿ｉｎｄｅｘ）セクション１２０に関する識別情報が含まれる。参考に、前述した段階は他の実施例で逆順に行われることもあり、代表キー値を含むキーインデックス（ｋｅｙ＿ｉｎｄｅｘ）セクション１２０を提供する段階（Ｓ５００）は実施例によって省略されることもある。

以下では図１１を参照して前述した本発明の一実施例に係る構造を有するメタデータのインデックスを用いて検索条件に符合するメタデータを得るための検索方法を説明する。
まず、ユーザーから検索条件が入力され（Ｓ１１００）、入力された検索条件のフィールドに対するメタデータにおける位置情報を判断し（Ｓ１２００）、前記位置情報の少なくとも一部（例えば、フラグメントの位置情報またはキーの位置情報）が所定のコードで定義されている場合、前記定義されたコードを含むキーをキーインデックスリスト（ｋｅｙ＿ｉｎｄｅｘ＿ｌｉｓｔ）セクション１１０で検索し（Ｓ１３００）、前記検索されたキーを用いて該当メタデータを抽出する（Ｓ１４００）。

該当メタデータを抽出する段階（Ｓ１４００）は、前記キーインデックス（ｋｅｙ＿ｉｎｄｅｘ）セクション１２０で代表キー値と検索条件のキー値との範囲を比較して検索条件に符合する代表キー値を検索し、前記検索された代表キー値が代表する範囲のキー値を含むサブキーインデックス（ｓｕｂ＿ｋｅｙ＿ｉｎｄｅｘ）セクション１１４を検索する段階（Ｓ１４１０）と、前記検索されたサブキーインデックス（ｓｕｂ＿ｋｅｙ＿ｉｎｄｅｘ）セクション１１４で検索条件に符合するキー値を検索する段階（Ｓ１４２０）と、検索されたキー値を用いて前記キー値に対応するメタデータフラグメントの識別情報を用いて該当メタデータフラグメントを抽出する段階（Ｓ１４３０）とを含むことによって、検索条件に該当するメタデータを抽出する。ここで、フラグメントの位置情報は、前述したように、キーがインデクシングするメタデータフラグメントの絶対経路情報、すなわち、前記メタデータフラグメントのＸＰａｔｈ（ｆｒａｇｍｅｎｔ＿ｘｐａｔｈ＿ｐｔｒ）であり、キーの位置情報は、前記メタデータフラグメントに対するキーの相対経路情報（前記フラグメントのＸＰａｔｈ位置での関連経路）、すなわち、キーとして使われるノードのＸＰａｔｈ（ｋｅｙ＿ｄｅｓｃｒｉｐｔｏｒ）をいう。

前記段階Ｓ１４１０、Ｓ１１４２０及びＳ１４３０では、該当インデックス（ｋｅｙ＿ｉｎｄｅｘ）セクション１２０及びサブキーインデックス（ｓｕｂ＿ｋｅｙ＿ｉｎｄｅｘ）セクション１１４を検索する段階、及び該当フラグメントを抽出する段階は、各々、キーインデックス（ｋｅｙ＿ｉｎｄｅｘ）セクション１２０の識別情報、サブキーインデックス（ｓｕｂ＿ｋｅｙ＿ｉｎｄｅｘ）セクション１１４の識別情報、及びメタデータフラグメントの識別情報を用いて行われる。

図１２は、本発明の一実施例に係るメタデータを検索する装置を示す。本実施例に係る装置は図１１を参照して説明した本発明の一実施例に係るメタデータを検索する方法が行われる装置である。

前記装置は、ユーザーから検索条件が入力される入力部１１００と、コンテンツ、コンテンツに対するメタデータまたはメタデータのインデックスを受信する受信部１２００と、受信されたコンテンツ、コンテンツに対するメタデータまたはメタデータのインデックスを保存する保存部１３００と、前記入力部１１００から入力された検索条件のフィールドに対応するメタデータにおける位置情報を判断し、前記位置情報の少なくとも一部が所定のコードで定義されている場合、前記定義されたコードを位置情報として含むキーをメタデータのインデックスから検索し、そして前記検索されたキーを用いて該当メタデータを抽出する制御部１４００と、前記制御部１４００の検索結果を出力する出力部１５００とを含む。
前記制御部１４００は入力部１１００を通じて入力された検索条件を前記保存部１３００に保存されたメタデータのインデックスに含まれたキー値と比較する。

前述した本発明の一実施例に係る検索方法のうち入力された検索条件のフィールドに対するメタデータにおける位置情報を判断する段階（Ｓ１２００）と、前記位置情報の少なくとも一部が所定のコードで定義されている場合、前記定義されたコードを含むキーを検索する段階（Ｓ１３００）と、前記検索されたキーを用いて該当メタデータを抽出する段階（Ｓ１４００）とは制御部（１４００）で行われ、前記段階に関する説明は図１２と関連した説明部分を参照すれば良い。

本発明は図面に示された一実施例に基づいて説明されたが、これは例示的なものに過ぎず、当業者ならばこれより多様な変形及び均等な他実施例が可能であるという点を理解できるであろう。したがって、本発明の真の技術的保護範囲は請求範囲の技術的思想により決まるべきである。

本発明は、メタデータがフラグメント単位で構成される環境において、メタデータフラグメントを速かに検索するためにメタデータフラグメントに対して単純化されたインデクシングを提供するインデックス構造、インデックス情報に対する検索方法及びインデックス情報を受信する受信装置を提示した。本発明を通じて、メタデータに対する迅速な検索が可能なって受信装置のオーバーヘッドが減少し、かつ検索時間が短縮されて受信装置の効率が向上する。

一般のＰＤＲの概念図である。 一般のＥＰＧアプリケーションでのグリッドガイド画面を図示する。 ＴＶＡフォーラムで定義する一般のメタデータ構造を図示する。 ＴＶＡフォーラムで定義する一般のフラグメント概念図である。 ＴＶＡフォーラムで定義する一般のコンテナ概念図である。 従来のメタデータのインデックス構造を図示する。 従来のメタデータのインデックス構造及び検索過程を図示する。 本発明に係るメタデータのインデックス構造を図示する。 本発明に係るメタデータのインデックス構造及び検索過程を図示する。 本発明に係るメタデータのインデックスを提供する方法を図示する。 本発明に係るメタデータの検索方法を図示する。 本発明に係るメタデータを検索する装置の構造図である。

Claims (11)

1. メタデータの所定フィールドで構成されるキーのリストを含むメタデータのインデックスを提供する方法であって、前記リストは前記メタデータにおける前記フィールドの位置情報を含み、前記位置情報の少なくとも一部は所定のコードで表現されるメタデータのインデックス提供方法。
2. 前記メタデータのインデックスは、前記キー値及び前記キー値に対応するメタデータの識別情報をさらに含む請求項１に記載のメタデータのインデックス提供方法。
3. 前記メタデータは、ツリー構造のデータ構造を有し、前記ツリー構造の所定範囲別に分割されたフラグメントで構成され、
   前記キーを構成するフィールドは、前記フラグメントを構成する情報のうち何れか１つである請求項２に記載のメタデータのインデックス提供方法。
4. 前記メタデータの識別情報は、前記フラグメントの識別情報である請求項３に記載のメタデータのインデックス提供方法。
5. 前記位置情報は、
   （ａ）前記キーを構成するフィールドが属するフラグメントの前記データ構造内の位置情報、及び（ｂ）前記フィールドの前記フラグメント内の位置情報を含む請求項３に記載のメタデータのインデックス提供方法。
6. 前記（ａ）前記データ構造内位置情報または（ｂ）前記フラグメント内位置情報が所定のコードで表現される請求項５に記載のメタデータのインデックス提供方法。
7. 前記位置情報の少なくとも一部はＸＰａｔｈで表現される請求項５に記載のメタデータのインデックス提供方法。
8. 前記コードは、使用頻度の相対的に高い位置情報に対してあらかじめ与えられたコードである請求項１に記載のメタデータのインデックス提供方法。
9. 前記メタデータのインデックスは、前記キー値の所定範囲を代表する代表キー値をさらに含む請求項２に記載のメタデータのインデックス提供方法。
10. 前記代表キー値は、該当する範囲の値のうち最大値、最小値または中間値である請求項９に記載のメタデータのインデックス提供方法。
11. 前記メタデータは、ＴＶＡで定義するメタデータの構造を有する請求項１に記載のメタデータのインデックス提供方法。

Images