(57)【要約】各コンテンツに関する特徴記述を行ったメタデータが格納されている。検索サーバは、クライアントからのメタデータの検索要求に対して、該当するメタデータ各々について、そのメタデータ全体を返信するのではなく、一部を返信することで、検索サーバークライアント間の通信量を削減する。また、メタデータを順次少しずつ取得していくブラウジングも行える。
2004023341.tif 000002
【特許請求の範囲】
【請求項１】
コンテンツサーバが有する各コンテンツに関する特徴記述を行った各メタデータを格納するデータベースと、
任意のクライアントからの検索要求に応じて、該検索要求に含まれる検索条件に合致するメタデータを前記データベースから取得し、前記検索要求に含まれる制約条件に従って前記取得したメタデータの一部を抽出し、該メタデータの一部を検索結果として前記クライアントに送信する検索サーバと、
を有することを特徴とする検索処理システム。
【請求項２】
前記クライアントは、前記検索サーバに対してメタデータの構造に関する制約条件を検索要求に付加する制約条件生成処理部を有することを特徴とするクレーム１記載の検索処理システム。
【請求項３】
前記特徴記述は、時間軸に沿った階層構造として表され、
前記クライアントの前記制約条件生成処理部は、検索対象となるスキーマ種別及び該スキーマ種別の論理条件を含むスコープ指定，スキーマのトップレベルからの階層を指定する階層構造指定，スコープ指定したスキーマの時間軸に関連する時間構造指定を行う制約条件を生成する構成を有することを特徴とするクレーム１記載の検索処理システム。
【請求項４】
前記クライアントは、前記検索サーバからの検索結果のメタデータについて論理的な部分木を結合するメタデータ再構成処理部を有することを特徴とするクレーム１又は２記載の検索処理システム。
【請求項５】
前記クライアントの前記メタデータ再構成処理部は、前記検索サーバからのメタデータの論理的な部分木と、既に受信しているメタデータの部分木とを結合して再構成する構成を有することを特徴とするクレーム１〜４の何れかに記載の検索処理システム。
【請求項６】
前記検索サーバは、前記クライアントに送信するメタデータのスキーマ種別毎に、スキーマの表示形式を定義する表示テンプレートデータを選択して送信する表示テンプレート選択処理部を有することを特徴とするクレーム１〜５の何れかに記載の検索処理システム。
【請求項７】
クライアントからの検索要求に従ってデータベースを検索サーバにより検索し、検索結果を前記クライアントに送信する検索処理方法に於いて、前記クライアントは、メタデータの構造に関する制約条件を付加して前記検索サーバに検索要求を送信し、前記検索サーバは、前記クライアントからの検索要求に従って前記データベースを検索し、検索結果のメタデータについて前記制約条件に基づいてフィルタリング処理を行った結果を前記クライアントに検索結果データとして送信する過程を含むことを特徴とする検索処理方法。
【請求項８】
前記クライアントから前記検索要求に付加する前記制約条件は、論理条件指定、スキーマ種別を指定するスコープ指定、階層構造のスキーマの階層指定、該スキーマの時間間隔指定の何れか又は複数を含むことを特徴とするクレーム７記載の検索処理方法。
【請求項９】
前記クライアントから前記検索要求に付加する前記制約条件は、階層構造のスキーマの部分木として親ノードへのパス情報と子ノードとに関する部分木指定、前記部分木の階層構造指定、前記部分木の時間構造指定、取得済み以外の残りのメタデータの取得を示す残データ指定の何れか又は複数を含むことを特徴とするクレーム７又は８記載の検索処理方法。
【請求項１０】
前記検索サーバは、前記クライアントの制約条件に従ったメタデータの構造が部分木となった時に、該部分木のメタデータに、該部分木の位置情報と、該部分木からの子ノードの情報とを付加して送信する過程を含むことを特徴とするクレーム７〜９の何れかに記載の検索処理方法。
【請求項１１】
前記クライアントは、前記検索サーバからの部分木に対応する複数のメタデータを、前記部分木の位置情報を基に再構成する過程を含むことを特徴とするクレーム７〜１０の何れかに記載の検索処理方法。
【請求項１２】
前記検索サーバは、前記クライアントの制約条件に従ってフィルタリング処理されたメタデータのスキーマ種別対応の表示テンプレートデータを検索結果に付加して前記クライアントに送信する過程を含むことを特徴とするクレーム７〜１１の何れかに記載の検索処理方法。
【請求項１３】
検索条件と制約条件とから成る、クライアントからの検索要求に応じて、各コンテンツ毎にそのコンテンツの特徴記述を行ったメタデータの中から、前記検索条件に合致するメタデータが検索されると、該検索された各メタデータ毎に前記制約条件に従ってそのメタデータの一部を抽出するフィルタリング処理部と、
該フィルタリング処理部により抽出された前記部分メタデータを検索結果として前記クライアントに送信する検索結果データ生成処理部と、
を有することを特徴とする検索サーバ。
【請求項１４】
前記制約条件は、前記メタデータの構造に関する条件を有し、
前記フィルタリング処理部は、前記メタデータにおいて該メタデータの構造に関する条件を満たす部分を抽出することを特徴とするクレーム１３記載の検索サーバ。
【請求項１５】
前記特徴記述は、時間軸に沿った階層構造として表され、
前記制約条件は、スキーマ種別を指定するスコープ指定、前記階層構造の任意の階層を指定する階層構造指定、前記時間軸の任意の時間帯を指定する時間構造指定の何れか１つ又は複数を含むことを特徴とするクレーム１３または１４記載の検索サーバ。
【請求項１６】
前記フィルタリング処理部は、前記部分的なメタデータに、架空の部分木の存在を示す情報を含めてクライアントに送信させ、
前記クライアントから、メタデータ内の前記架空の部分木の位置を示すパス情報と、制約条件とを含む取得依頼が送られてくると、該取得依頼に応じて前記メタデータの残データの一部または全部を抽出することを特徴とするクレーム１３〜１５の何れかに記載の検索サーバ。
【請求項１７】
前記クライアントに送信するメタデータのスキーマ種別毎に、スキーマの表示形式を定義する表示テンプレートデータを選択して送信する表示テンプレート選択処理部を更に有することを特徴とするクレーム１３〜１６の何れかに記載の検索サーバ。
【請求項１８】
コンテンツサーバが有する各コンテンツに関する特徴記述を行ったメタデータの中から所望のメタデータを検索させる為に送信する検索要求に、メタデータの構造に関する制約条件を付加する制約条件生成処理部を有することを特徴とするクライアント。
【請求項１９】
前記制約条件生成処理部は、前記制約条件として、スキーマ種別を指定するスコープ指定，スキーマのトップレベルからの階層を指定する階層構造指定、時間範囲を指定する時間構造指定の何れか１つ以上を生成することを特徴とするクレーム１８記載のクライアント。
【請求項２０】
前記検索要求に応じて検索サーバから返信される部分的なメタデータを格納するメタデータ管理部を更に備え、
前記制約条件生成処理部は、前記部分的なメタデータに基づいて、残りのメタデータにおいて取得すべき任意の部分木と制約条件を指定させ、該取得すべき部分木の位置と制約条件を含む取得依頼命令を前記検索サーバに送信することを特徴とするクレーム１８又は１９記載のクライアント。
【請求項２１】
前記取得依頼命令に応じて検索サーバから返信される部分木を、前記メタデータ管理部に格納されている取得済みの部分メタデータに結合して再構成するメタデータ再構成処理部を更に有することを特徴クレーム１８〜２０の何れかに記載のクライアント。
【請求項２２】
コンピュータに、
検索条件と制約条件とから成るクライアントからの検索要求に応じて、各コンテンツ毎にそのコンテンツの特徴記述を行ったメタデータの中から、前記検索条件に合致するメタデータが検索されると、該検索された各メタデータ毎に前記制約条件に従ってそのメタデータの一部を抽出する機能と、
該抽出された前記部分的なメタデータを検索結果として前記クライアントに送信する機能と、
を実現させるプログラムを記録した前記コンピュータ読取り可能な記録媒体。
【請求項２３】
前記制約条件は、前記メタデータの構造に関する条件を有し、
前記メタデータの一部を抽出する機能は、前記メタデータにおいて該メタデータの構造に関する条件を満たす部分を抽出することを特徴とするクレーム２２記載の記録媒体。
【請求項２４】
前記部分的なメタデータをクライアントに送信後、前記クライアントからパス情報と制約条件とを含む取得依頼が送られてくると、該取得依頼に応じて前記メタデータの残データの一部または全部を抽出する機能を更に有することを特徴とするクレーム２２または２３記載の記録媒体。
【請求項２５】
コンピュータに、
検索条件と制約条件とから成るクライアントからの検索要求に応じて、各コンテンツ毎にそのコンテンツの特徴記述を行ったメタデータの中から、前記検索条件に合致するメタデータが検索されると、該検索された各メタデータ毎に前記制約条件に従ってそのメタデータの一部を抽出する機能と、
該抽出された前記部分的なメタデータを検索結果として前記クライアントに送信する機能と、
を実現させる為のプログラム。
【請求項２６】
クライアントからの検索要求に従ってデータベースを検索する検索サーバを有する検索処理システムに於いて、
前記データベースは、コンテンツサーバのデータを階層的に分割したセグメントの特徴記述を行ったメタデータをキーワードと共に格納した構成を有し、
前記検索サーバは、前記クライアントからの制約条件を付加した検索要求に従って前記データベースを検索し、前記制約条件に従ってフィルタリング処理を行った検索結果を前記クライアントに送信する為のフィルタリング処理部を有することを特徴とする検索処理システム。
【発明の詳細な説明】
【技術分野】  本発明は、クライアントからネットワークを介して検索サーバに検索要求を行い、この検索要求に従った検索結果をネットワークを介してクライアントに送出する検索処理システム、その検索サーバ、クライアント、検索処理方法、プログラム、記録媒体等に関する。
【背景技術】  インターネットに接続されたコンテンツサーバによる文書データや画像データ等は莫大な数となり、このようなデータに対してキーワード検索を可能とする例えば図３３に示すようなシステムが知られている。図３３に於いて、１０１はデータベース（ＤＢ）、１０２は検索サーバ、１０３はコンテンツサーバ、１０４はネットワーク、１０５はクライアント、１０６−１〜１０６−ｎはデータベースに格納されたメタデータ、１０７−１〜１０７−ｍはデータベースに格納されたコンテンツデータ又は当該リンク、１０８は検索サーバからクライアントに対する応答内容の一例を示す。
複数の検索サーバ１０２と複数のコンテンツサーバ１０３とを、ネットワーク１０４を介して任意のクライアント１０５が選択的にアクセスを可能としたシステム構成を有し、クライアント１０５からキーワードによる検索要求を検索サーバ１０２に送出すると、検索サーバ１０２はデータベース１０１を検索し、キーワードに対応したメタデータ，コンテンツデータ又はリンク情報を、例えば、ＨＴＭＬ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）による応答１０８としてクライアント１０５に送出する。クライアント１０５は、この応答１０８に含まれるコンテンツデータへのリンクを示すＵＲＬ（Ｕｎｉｆｏｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）等によりコンテンツサーバ１０３にアクセスして所望のデータをダウンロードし、閲覧可能とすることになる。
例えば、動画像データの検索システムに於いては、動画像データの特徴を記述した付加情報（ｍｅｔａｄａｔａ；タイトル名，製作日，出演者，概要等）と、その動画像データへのリンク情報とを、データベース１０１に格納するものである。また、リンク情報として、例えば、プロトコル名：／／ホスト名／ファイル名等によるＵＲＬ（Ｕｎｉｆｏｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）が用いられる。
また、動画像データの特徴を記述する為の自動認識処理技術が確立されていないことから、検索対象となる動画像データに対して付加情報（＝メタデータ）を併用することになる。この為の表記方法として、ＩＳＯ（Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｏｒｇａｎｉｚａｔｉｏｎ  ｆｏｒ  Ｓｔａｎｄａｒｄｉｚａｔｉｏｎ）／ＩＥＣ（Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｅｌｅｃｔｒｏｔｅｃｈｎｉｃａｌ  Ｃｏｍｍｉｓｓｉｏｎ）に於いて、ＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）を基本としたＭＰＥＧ−７（Ｍｏｖｉｎｇ  Ｐｉｃｔｕｒｅ  Ｅｘｐｅｒｔｓ  Ｇｒｏｕｐ−７）（正式名称＝マルチメディアコンテントの記述インタフェース）の標準化が進められている。
このＭＰＥＧ−７により表記されるメタデータは、ＸＭＬの表記方法に準ずる為に、記述子（タグ；ｔａｇ）と記述データとから構成される。また、記述データとしては、記述子と記述データとを含む入れ子形式の場合もあり、メタデータは論理的な木構造となる。また、或る意味を有する論理構造は、スキーマ（Ｓｃｈｅｍａ）と称される。
また、動画像の管理として、動画像全体をフレーム列として階層的に分割し、フレーム列の属性データと代表フレームの静止画像とを関連付けたデータファイルを作成し、属性データや階層木を検索キーとして、フレーム列を抽出し、その代表フレームの静止画像により、動画像の内容を推測する手段が知られている（例えば、特開平５−２８２３７９号公報参照）。
また、動画像のシーンチェンジ等の複数のポイントの簡略画像をユーザの要求によって選択して送出し、動画像のブラウジングを行う手段も知られている（例えば、特開平９−２４４８４９号公報参照）。また、動画像の時間的に離れている複数のフレームを最初に伝送することにより、ユーザに対して動画像の内容の概要が判るようにした方法も知られている（例えば、特開平１０−２９４９３１号公報参照）。また、動画像のハイライトシーンやキーフレームについて抽出し、ユーザの要求によって全体の動画像を送出することなく、ハイライトシーンやキーフレームを送出することにより、ブラウジングを可能とした手段も知られている（例えば、特開平１１−２３９３２２号公報参照）。
従来例の動画像検索システムに於いて、メタデータの記述に前述のＭＰＥＧ−７を適用すると、複数種類の記述が可能であり、また、複雑な論理構造であるから、各種のクライアント・アプリケーションの利便性の向上を図る観点からの付加情報の記述が可能となる。しかし、特定のクライアント・アプリケーションに必要な記述子のみを選択して返信する機構を従来例の動画像検索システムは備えていないものであるから、或るクライアントにとっては無用な記述子の記述データについても送信することになり、ブラウジングを繰り返すと、クライアントと検索サーバとの間の通信量が大幅に増大する問題がある。
例えば、ＭＰＥＧ−７のＳｅｇｍｅｎｔＤＳ（Ｄｉｓｃｒｉｐｔｉｏｎ  Ｓｃｈｅｍａ）という記述子を用いて、約１時間のビデオデータに関する階層構造を記述すると、数１００ｋＢ程度のデータ量となり、また、タグ数も数１００個、階層も数１０階層となる場合が多くなる。従って、ユーザの検索要求に対する検索サーバとクライアントとの間の通信量が増大する問題がある。
また、前述の公開公報等により提案された従来の検索手段に於いても、動画像を分割して代表的な画像のブラウジングを可能としているが、階層構造として記述したとしても、検索サーバとクライアントとの間の通信量の増大が発生する問題がある。
【発明の開示】
本発明は、クライアントが検索サーバからメタデータを取得する際に、全種類の記述子の記述データを一度に送信することなく、クライアントが必要とする記述子の記述データのみを選択的に送信することにより通信量を削減し、且つクライアントに対しても検索要求を満足させることができ、通信量を削減したブラウジングを可能とするシステム、方法、プログラム記録媒体等を提供することを目的とする。
本発明の検索処理システムは、コンテンツサーバが有する各コンテンツに関する特徴記述を行った各メタデータを格納するデータベースと、任意のクライアントからの検索要求に応じて、該検索要求に含まれる検索条件に合致するメタデータを前記データベースから取得し、前記検索要求に含まれる制約条件に従って前記取得したメタデータの一部を抽出し、該メタデータの一部を検索結果として前記クライアントに送信する検索サーバとを有するように構成する。
また、本発明は、上記検索サーバ自体、クライアント自体として構成することもできる。
上記本発明の構成によれば、検索サーバは、メタデータ全てを返信するのではなく、メタデータの一部を返信する（不要な／余分なデータは送信しない）ので、検索サーバとクライアントとの間の通信量を削減できる利点がある。
また、本発明の検索処理システムでは、上記メタデータの一部を抽出する為に、例えば、メタデータの構造（特に、時間構造、階層構造等）に関する制約条件を用いる。これにより、そのクライアント側で本当に必要とする部分のみを取得し易くなる。
また、例えば、前記検索サーバは、前記クライアントからパス情報と制約条件とを含む取得依頼が送られてくると、該取得依頼に応じて前記メタデータの残データの一部または全部を抽出して、クライアントに返信する。
このように、クライアントは、メタデータの中で必要なデータを順次取得していくことができ、特に上記階層構造に従って順次詳細な内容に向かった検索が可能となる。
一方、本発明によるクライアントは、検索サーバに対して送信すべき検索要求に、メタデータの構造に関する制約条件を付加する制約条件生成処理部を有する。
また、例えば、クライアントは、上記の通り、検索サーバから返信されるメタデータ（部分木）の構造から延長して取得可能な残りの部分木を指定して、これを取得できるものであって、この取得した部分木を、それまでに取得して部分木と結合するメタデータ再構成処理部を有する。
【図面の簡単な説明】  本発明は、後述する詳細な説明を、下記の添付図面と共に参照すればより明らかになるであろう。
図１は、本発明の基本システムの構成説明図である。
図２は、本発明の実施の形態の検索サーバ側の説明図である。
図３は、本発明の実施の形態のクライアントの説明図である。
図４は、クライアントから送信する要求パケットのデータ構成例を示す図である。
図５は、検索依頼命令に応じたサーバ側の処理フローチャート図である。
図６は、取得依頼命令に応じたサーバ側の処理フローチャート図である。
図７は、メタデータフィルタリング処理部の処理フローチャート図である。
図８は、図７のステップＳ３６の詳細フローチャート図である。
図９は、クライアント側における検索依頼時の処理フローチャート図である。
図１０は、クライアント側における検索結果データ受信時の処理フローチャート図である。
図１１は、クライアント側における架空の子ノード取得依頼時の処理フローチャート図である。
図１２は、クライアント側におけるブラウズデータ受信時の処理フローチャート図である。
図１３は、メタデータの一例の説明図である。
図１４は、階層構造指定時の説明図である。
図１５は、時間構造指定時の説明図である。
図１６は、部分木指定時の説明図である。
図１７は、部分木の階層構造指定時の説明図である。
図１８は、部分木の時間構造指定時の説明図である。
図１９は、残データ指定時の説明図である。
図２０は、ＸＭＬスキーマ定義の具体例を示す図（その１）である。
図２１は、ＸＭＬスキーマ定義の具体例を示す図（その２）である。
図２２は、ＸＭＬスキーマ定義の具体例を示す図（その３）である。
図２３は、メタデータの説明図である。
図２４は、メタデータの木構造の概要説明図である。
図２５は、フィルタリング処理されたメタデータの一例を示す図である。
図２６は、架空の子ノードの要求命令に含まれるデータの一例を示す図である。
図２７は、図２６の要求に対して検索サーバから返信されるデータの一例を示す図である。
図２８は、時間軸に関連した構造の説明図である。
図２９は、クライアントのＧＵＩの説明図である。
図３０は、表示テンプレートデータの説明図である。
図３１は、コンピュータハードウェア構成図である。
図３２は、プログラムを記録した記憶媒体／ダウンロードの説明図である。
図３３は、従来例のシステム構成説明図である。
【発明を実施するための最良の形態】  以下、図面を参照して本発明の実施の形態について説明する。
尚、ここで言う「メタデータ」とは、上記従来技術における、動画像データの特徴を記述した付加情報（ｍｅｔａｄａｔａ；タイトル名，製作日，出演者，概要等）としてのメタデータではなく、比較的データ量が大きいメタデータを意味し、例えばＭＰＥＧ−７、２１により表記されるメタデータを意味するものとする。
図１は本発明の基本システム構成説明図であり、１はデータベース、２は検索サーバ、３−１〜３−ｎはコンテンツサーバ、４はネットワーク、５−１〜５−ｍはクライアント、７はフィルタリング処理部、８は制約条件生成処理部を示す。
コンテンツ識別子とメタデータ識別子とにより特定されるコンテンツデータの実体及びメタデータの実体は、コンテンツサーバ３−１〜３−ｎに格納されている。また、メタデータは、記述子と記述データとから構成され、記述データは、記述子を含む入れ子形式とすることができる。また、ＸＭＬやＭＰＥＧ−７による記述形式を適用することができる。
データベース１は、コンテンツサーバ３−１〜３−ｎが保持している検索対象のコンテンツのコンテンツ識別子とメタデータ識別子とをキーワードと共に格納した構成を有するものである。なお、キーワードは、ネットワーク４を介してコンテンツサーバ３−１〜３−ｎから取得したメタデータ中の記述子及び記述データから、キーワード抽出処理によって得ることができる。このキーワード抽出処理としては、記述データが文字データの場合、形態要素解析（品詞分解）等の処理を適用して抽出することができる。また、数値データの場合、そのままキーワードとすることができる。また、メタデータの記述子の場合、メタデータの構造解析処理時に、記述子名を取得してキーワードとすることができる。
尚、コンテンツ識別子やメタデータ識別子としては、そのデータ（コンテンツ／メタデータ）の所在を示すＵＲＬ等を用いることができる。また、尚、上述した構成は一例であり、これに限るわけではない。例えば、データベース１にもメタデータの実体やコンテンツの実体を更に格納する構成であってもよいし、検索サーバ２がデータベース１を有する構成や、検索サーバ２がデータベース１とコンテンツサーバ３を有する等であってもよい。
尚、「検索処理システム」とは、広義にはクライアント５、データベース１、検索サーバ２を有するシステムであり、狭義にはデータベース１、検索サーバ２を有するシステムである。
図２は、本発明の実施の形態の検索サーバ側の説明図であり、図３は本発明の実施の形態のクライアントの説明図であって、図１に於けるネットワーク４に相当する機能部分は図示を省略している。
図２に於いて、１はデータベース、２は検索サーバ、３はコンテンツサーバ、６はメタデータ表示テンプレートデータベース、１１はキーワード抽出処理部、１２は記録部、１３は検索処理部、２１は検索結果データ生成処理部、２２は図１のフィルタリング処理部７に対応するメタデータフィルタリング処理部、２３は表示テンプレート選択処理部を示す。
また、３ａはコンテンツサーバ３のＣ＃１等の識別子を含むコンテンツデータ、３ｂはコンテンツサーバ３の識別子Ｍ＃１等を含むメタデータを示す。
データベース１は、キーワード抽出処理部１１と記録部１２と検索処理部１３とを含む構成を有する。
キーワード抽出処理部１１は、前述のように、ネットワークを介して各コンテンツサーバ３にアクセスして、そのコンテンツサーバ３に格納されているコンテンツデータ３ａとメタデータ３ｂとから、キーワードを抽出する。そして、例えば、“ｋｅｙ＃１コンテンツ識別子＃ａメタデータ識別子＃ａ”，“ｋｅｙ＃２コンテンツ識別子＃ｂメタデータ識別子＃ｂ”，“ｋｅｙ＃３コンテンツ識別子＃ｃメタデータ識別子＃ｃ”のように、キーワードｋｅｙ＃ｉと共にコンテンツ識別子、メタデータ識別子を、記録部１２に格納する。
ここで、後述するように、クライアント５は、検索条件と制約条件とを有する検索要求を、検索サーバ２に送信する。検索サーバ２は、検索条件を検索処理部１３に渡す。
検索処理部１３は、検索サーバ２から渡される検索条件（キーワード等）に従って記録部１２を検索し、検索条件に合致したもの（そのコンテンツ識別子、メタデータ識別子）を検索サーバ２に送出する。
検索サーバ２は、検索結果データ生成処理部２１とメタデータフィルタリング処理部２２と、表示テンプレート選択処理部２３とを有する。
ここで、メタデータ表示用テンプレートデータベース６は、各スキーマ種別毎に、そのスキーマの表示形式を定義する表示テンプレートデータを格納している。
表示テンプレート選択処理部２３は、クライアント５に送信するメタデータのスキーマに対応する表示テンプレートを、メタデータ表示用テンプレートデータベース６から選択して取得する。後述するように、検索結果データ生成処理部２１は、この表示テンプレートデータを、フィルタリング処理された検索結果データに付加して、図示を省略したネットワークを介して、検索要求元のクライアントに送出する。
メタデータフィルタリング処理部２２は、上記検索処理部１３が送出した検索結果としてのメタデータ識別子を用いて、コンテンツサーバ３から、そのメタデータ識別子に該当するメタデータ（メタデータの実体）を取得して、このメタデータに対して（複数ある場合には各々について）、上記制約条件に従ってフィルタリング処理を実行する。
検索結果データ生成処理部２１は、上記フィルタリング処理されたメタデータ（メタデータの一部；部分メタデータ又は部分木と呼ぶ）と表示テンプレートデータとを含む検索結果データを、検索要求元のクライアントに送出する。例えば、Ｎｏ．１コンテンツ識別子＃ｘと｛（記述子，記述データ）＝（Ｔ＃ｘ１，Ｄ＃ｘ＿１），・・・｝と表示テンプレートデータを対応付けて示す構成として、検索要求元のクライアントに送出する。尚、部分メタデータ（部分木）は、部分的なデータと部分的な構造とから成り、更に、この部分メタデータから見て、その下に存在する部分木（クライアント側から見れば架空の部分木となる）の存在を、クライアント側で判別させる為の情報（この部分メタデータの子ノードの記述子等）を付与してもよい。
図３において、５はクライアント、５１は図１に於ける制約条件生成処理部８に対応する制約条件生成処理部、５２はメタデータ再構成処理部、５３はメタデータ管理部、５４は表示テンプレートデータ管理部、５５は表示データ生成処理部、５６は表示処理部、５７は入力処理部を示す。
クライアント５は、図示を省略したネットワークを介して、検索サーバ２に対して、入力処理部５７から入力された条件（検索条件、制約条件等）に従った検索依頼命令、または取得依頼命令を、制約条件生成処理部５１に於いて生成して送出する。
そして、クライアント５は、検索サーバ２が検索依頼命令に応じてネットワークを介して返信してきたメタデータ（初期の部分メタデータ）は、そのままメタデータ管理部５３に転送して格納させる。また、検索サーバ２が取得依頼命令に応じて返信してきたメタデータ（追加の部分メタデータ）は、メタデータ再構成処理部５２に転送して再構成処理を行わせる。また、表示テンプレートデータは、表示テンプレートデータ管理部５４に転送する。
表示データ生成処理部５５は、メタデータ管理部５３に格納されたメタデータと、表示テンプレートデータ管理部５４に格納された表示テンプレートデータとを基に表示データを生成して、表示処理部５６と制約条件生成処理部５１とに転送する。表示処理部５６は、表示データに従った画像等を図示を省略した表示部に表示する制御を行う。
また、本例では特に関係ないが、検索サーバ２からの返信データに含まれるコンテンツ識別子を用いて、コンテンツサーバ等からコンテンツデータ（動画像等）を取得して、表示することもできる。
以下、上述した図２に示す検索サーバ２側の処理、図３に示すクライアント５側の処理について、図５〜図１２のフローチャート図を参照して説明する。
ここで、この説明の前に、クライアント５から検索サーバ２に対して検索要求する際に送信する依頼命令のデータ構成の一例を、図４に示す。図４に示す例では、依頼命令は、命令種別、制約条件と、検索条件または取得条件より成る。
命令種別は、“検索依頼”、“架空の部分木（子ノード）の取得依頼”の何れかである。以下の説明では、命令種別が“検索依頼”である依頼命令を検索依頼命令、命令種別が“架空の部分木（子ノード）の取得依頼”である依頼命令を取得依頼命令と呼ぶものとする。
検索依頼命令の場合は、制約条件と検索条件とが付加される。取得依頼命令の場合には、制約条件と取得条件とが付加される。取得条件は、架空の部分木の位置情報（例えば、後述するＸｐａｔｈ）等である。検索条件は、例えばキーワード等である。制約条件は、例えばメタデータの構造（時間構造、階層構造等）に関する条件であり、詳しくは、後に説明する。
図５は、図２に示す検索サーバ２側全体の処理手順を説明する為のフローチャート図である。
図５において、検索サーバ２は、クライアント５からの検索依頼命令を受信すると（ステップＳ１１）、まず、上記図４に示す制約条件と検索条件とを分離する（ステップＳ１２）。そして、検索条件（キーワード等）はデータベース１に渡す。検索処理部１３は、この検索条件（キーワード等）に従って記録部１２を検索し、検索条件に合致するメタデータ識別子、コンテンツ識別子を検索サーバ２に返信する（ステップＳ１３）。尚、上記の通り、データベース１にメタデータ（実体）を格納した構成であってもよく、この場合は、検索条件（キーワード等）に従って各メタデータを検索し、検索条件に合致する内容を有するメタデータを、検索サーバ２側に返信することになる。但し、本説明では、記録部１２を検索する例を対象にして説明する。
検索サーバ２は、検索処理部１３から返信されたメタデータ識別子を用いて、コンテンツサーバ３からメタデータを取得し、この各メタデータ毎に、上記ステップＳ１２で分離した制約条件を用いて、ステップＳ１４、Ｓ１５の処理を繰り返し実行する。
まず、メタデータフィルタリング処理部２２が、メタデータに対してフィルタリング処理を実行する（ステップＳ１４）。ステップＳ１４の処理の詳細については、図７、図８に示してあり、後に説明する。
次に、表示テンプレート選択処理部２３は、このメタデータに適した表示テンプレートデータを、メタデータ表示用テンプレートデータベース６から選択・取得する（ステップＳ１５）。
以上のステップＳ１４，Ｓ１５の処理を、取得した全てのメタデータについて実行したら、検索結果データ生成処理部２１が、フィルタリング処理された結果として得られる部分メタデータ（部分木）を検索結果として、そのコンテンツ識別子及び表示テンプレートデータを付加して、クライアントに返信する（ステップＳ１６）。
また、上記の通り、フィルタリング処理により、メタデータの一部がクライアント５に返信されることになるが、残りのメタデータ（残データ）の一部または全てについて後にクライアント５が取得要求する場合があるので、この残データは検索サーバ２に保持しておく。そして、クライアント５側から、上記残データに関して取得依頼命令があった場合には、検索サーバ２は図６に示す処理を実行する。
すなわち、検索サーバ２は、クライアント５からの取得依頼命令を受信すると（ステップＳ２１）、上記の通り保持しておいたメタデータ（残データ）の中から該当するメタデータ（残データ）を取得して（ステップＳ２２）、このメタデータに対してフィルタリング処理を実行し（ステップＳ２３）、処理結果（残データの一部または全部）をクライアント５に返信する（ステップＳ２４）。
このように、クライアント５側では、必要に応じて、メタデータの一部を少しずつ取得して、表示させることができる。つまり、クライアント５側のユーザは、メタデータを、必要な部分のみを段階的に目視確認できる（ブラウジングできる）ようになる。
次に、以下、メタデータフィルタリング処理部２２によるステップＳ１４の処理の詳細について、図７の処理フローチャート図を参照して説明する。また、図８には、図７のステップＳ３６の処理の詳細フローチャートを示す。
図７の処理は、上記検索処理部１３から返信されたメタデータ識別子を用いてコンテンツサーバ３から取得した各メタデータ毎に、上記制約条件に基づいて実行する。
メタデータフィルタリング処理部２２は、まず、上記制約条件を参照し、この制約条件にスキーマ指定があるか否かを判定し（ステップＳ３１）、スキーマ指定がある場合には（ステップＳ３１，ＹＥＳ）、メタデータから、指定されたスキーマのみを抽出する（ステップＳ３２）。次に、制約条件に時間指定があるか否かを判定し（ステップＳ３３）、時間指定がある場合には（ステップＳ３３，ＹＥＳ）、メタデータから、指定された時間（時間範囲）に該当するデータのみを抽出する（ステップＳ３４）。次に、階層指定があるか否か（ステップＳ３５）を判定し、階層指定がある場合には（ステップＳ３５，ＹＥＳ）、メタデータから、指定された階層に関するデータのみを抽出する（ステップＳ３６）。
ここで、制約条件には、上記スキーマ指定、時間指定、階層指定の何れか１つ以上の条件が指定される。よって、何れか１つだけでなく、２つ、あるいは３つとも指定される場合もある。もし、３つとも指定された場合には、ステップＳ３２で抽出されたスキーマの中から、更に、指定された時間に該当するデータのみを抽出し（ステップＳ３４）、更にこのステップＳ３４で抽出されたデータの中から、指定された階層のデータのみを抽出する（ステップＳ３６）。
そして、メタデータ全体と、以上のステップＳ３６までの処理により抽出された部分メタデータとを比較して、その差分（残データ）を記録しておく（ステップＳ３７）。そして、上記フィルタリング処理結果（部分メタデータ）を、検索結果として出力する（ステップＳ３８）。
以下、図８を参照して、上記ステップＳ３６の処理の詳細を説明する。
まず、メタデータのスキーマ定義ファイルを参照して、スキーマ定義内容を分析して、再帰的な階層の単位の抽出を試みる（ステップＳ４１）。そして、再帰的な階層の単位がある場合には（ステップＳ４２，ＹＥＳ）、その階層単位で、メタデータから、制約条件の階層指定数だけデータを抽出する（ステップＳ４３）。尚、図８の処理については、後に図２０〜図２３に示す具体例を参照して詳細に説明する。
図９〜図１２は、図３に示すクライアント５における処理手順を説明する為のフローチャート図である。
図９、図１１は、クライアント５の制約条件生成処理部５１の処理フローチャート図であり、図９は検索依頼命令、図１１は取得依頼命令に係わる処理フローチャート図である。
図９において、まず、ユーザ等が、入力処理部５７（例えばキーボード、マウス等）を介して、所望の検索条件と制約条件を入力する（ステップＳ５１）。制約条件生成処理部５１は、この入力内容に応じて、図４で説明した検索依頼命令を生成し、これを検索サーバ２に送信する（ステップＳ５２）。
図１０は、上記検索依頼命令に応じて検索サーバ２から返信される検索結果データ受信時のクライアント５全体の処理フローチャート図である。尚、図１０の処理全体の制御は、不図示の（図３には示していない）全体制御部が行うものとする。
図１０において、クライアント５は、検索結果データを受信したら（ステップＳ６１）、まず、当該検索結果データを構成する表示テンプレートデータとメタデータ（初期の部分メタデータ）とを分離し（ステップＳ６２）、表示テンプレートデータは、表示テンプレートデータ管理部５４に格納する（ステップＳ６３）。
そして、各メタデータ毎に、ステップＳ６４〜Ｓ６７の処理を実行する。
すなわち、まず、メタデータのスキーマ定義ファイルを取得する（ステップＳ６４）。このメタデータのスキーマ定義は、後に具体例を示すが、よく知られている“ＸＭＬ  Ｓｃｈｅｍｅ”によって記述できるものである（ＸＭＬスキーマ定義）。ここではメタデータのスキーマ定義ファイルを、検索サーバ２から取得するが、クライアント５が予め保持していてもよい。尚、よく知られているように、“ＸＭＬ  Ｓｃｈｅｍｅ”は、最近になって、ＤＴＤ（Ｄｏｃｕｍｅｎｔ  Ｔｙｐｅ  Ｄｅｆｉｎｉｔｉｏｎ）の代わりに、ＸＭＬ文書の構造定義に用いられるようになったものである。
そして、取得したスキーマ定義に基づいて、メタデータを検証し、架空の部分木が存在するか否かを判定する。上記の通り、検索サーバ２から返信される部分メタデータには、架空の部分木の存在を判別させる為の情報（この部分メタデータの子ノードの記述子等）が付与されており、この情報と例えばＸＭＬスキーマ定義ファイルを参照することで、架空の部分木が存在する可能性があるか否かを判定し、存在する場合にはその位置情報／ノード種別情報等を抽出する（ステップＳ６５）。そして、当該メタデータを、抽出した架空の部分木の位置情報／ノード種別情報と共に、メタデータ管理部５３に格納する（ステップＳ６６）。尚、位置情報とは、例えば、当該メタデータ全体のトップのタグ（ルートノード）から架空の部分木に至るまでのパス情報であり、ノード種別情報とは、架空の部分木のノード（タグ）の種別情報である。
そして、このメタデータを表示する場合には、表示テンプレートデータを取得して（ステップＳ６７）、表示用データを生成し（ステップＳ６８）、表示処理を行う（ステップＳ６９）。
図１１は、上記の通り、取得依頼命令に係わる処理フローチャート図である。
図１１において、まず、クライアント５のユーザ等が、表示処理部５６の表示（例えば後に説明する図３０に示す表示）を参照しつつ、入力処理部５７を介して、要求すべき架空の部分木（子ノード）の選択を行い、更に所望の制約条件の入力を行う（ステップＳ７１）。
この入力に応じて、クライアント５は、上記選択された架空の部分木の位置情報を、メタデータ管理部５３から取得し（ステップＳ７２）、また、この架空の部分木に対する制約条件を生成する（ステップＳ７３）。そして、これら位置情報／制約条件を用いて取得依頼命令を生成し、検索サーバ２へ送信する（ステップＳ７４）。
尚、上記位置情報は、例えば、後に説明するパス情報（図２６に示す“Ｘｐａｔｈ”等）である。
図１２は、上記図１１の取得依頼命令に応じて検索サーバ２から返信されるブラウズデータをクライアント５が受信した際の全体処理フローチャート図である。尚、図１２の処理全体の制御は、不図示の（図３には示していない）全体制御部が行うものとする。
図１２において、クライアント５は、上記ブラウズデータを受信したら（ステップＳ８１）、この受信データからメタデータ（残データの一部；部分メタデータ）を抽出する（ステップＳ８２）。
次に、メタデータ再構成処理部５２によりステップＳ８３〜Ｓ８５の処理を実行する。まず、上記受信した部分メタデータは、既にメタデータ管理部５３に格納されている部分メタデータ（以下、既存メタデータと呼ぶ）に結合すべき存在であるので、この既存メタデータをメタデータ管理部５３から取得する（ステップＳ８３）。そして、架空の部分木の位置情報／ノード種別情報を抽出することで（ステップ８４）、受信した部分メタデータを、既存メタデータのどの位置に追加すべきかを判別できるので、その位置に、受信した部分メタデータを追加することで、既存メタデータを再構成する（ステップＳ８５）。
次に、再構成した既存メタデータについて、上記ステップＳ６５と同様に、スキーマ定義ファイルを参照して、架空の部分木の位置情報／ノード種別情報を抽出する（ステップＳ８６）。つまり、上記受信した部分メタデータの下の階層に更に架空の部分木が存在するか否かを判別し、存在する場合にはこの架空の部分木の位置情報／ノード種別情報を抽出する。そして、再構成した既存メタデータと、抽出した架空の部分木の位置情報／ノード種別情報とを、メタデータ管理部５３に格納する（ステップＳ８７）。
後は、図１０のステップＳ６７〜Ｓ６９と同様、上記メタデータに適した表示テンプレートデータを、表示テンプレートデータ管理部５４から読み出して（ステップＳ８８）、表示データを生成し（ステップＳ８９）、これを表示する処理を実行する（ステップＳ９０）。
以下、更に具体的・詳細な説明を行う。
メタデータは、記述子と記述データとから構成され、ＸＭＬに準拠し、記述子は、例えば、図１３（Ａ）に示す＜ｔａｇ＿ＭｅｔａＤａｔａ＞，＜ｔａｇ  Ｓｃｈｅｍａ１＞のようにタグで表現することができ、この場合に、図１３（Ｂ）に示す木構造を構成することになる。この木構造のノードは、図１３（Ａ）に示すタグに対応し、ｒｏｏｔノードはメタデータのトップレベルのタグを意味する。枝は、入れ子になっているタグの存在を意味し、子ノードは入れ子になっているタグを意味する。末端のＬｅａｆノードのみが入れ子のタグを有しないもので、記述データのみを含むことを意味する。通常は、ｒｏｏｔノードから始まるメタデータを一つ若しくは複数のファイルに格納する。複数のファイルに分割する場合、ファイルの存在関係を記述するタグによって依存関係が記述され、一つのファイルに格納した場合と等価となる。
検索対象は、コンテンツの識別子（ＵＲＬ等）、ｒｏｏｔノードを含むメタデータファイルの識別子（ＵＲＬ等）の他に、メタデータ中のタグの名前を構成する文字列及び記述データを解析処理（自然言語処理等）して得られる文字データや数値データ（キーワード）が対象となる。図１３（Ａ）に示す例の場合は、ｔａｇ＿ＭｅｔａＤａｔａ，ｔａｇ＿Ｓｃｈｅｍａ１，ｔａｇ＿Ｓｃｈｅｍａ２，ｔａｇ＿Ｓｃｈｅｍａ３，ｔａｇ＿ｓｃ１の文字列と、ｄａｔａ＿ｓｃ１＿Ｌ１，ｄａｔａ＿ｓｃ１＿Ｌ２，ｄａｔａ＿ｓｃ１＿Ｌ３，ｄａｔａ＿ｓｃ２，ｄａｔａ＿ｓｃ３を解析して得られる文字データ若しくは数値データが、キーワードとなる。
クライアント５の制約条件生成処理部５１は、命令種別と検索条件と制約条件とを含む検索依頼命令を生成し、または命令種別と制約条件と取得すべき部分木の位置情報（後述するＸｐａｔｈ等）とを含む取得依頼命令を生成し、これら何れかの命令をネットワークを介して検索サーバ２に送出する。
検索サーバ２のメタデータフィルタリング処理部２２は、前述のように、クライアント５が要求する検索条件に合致したメタデータ若しくは取得依頼に合致したメタデータから、制約条件に従ったデータを選択するものである。
検索条件として、検索語を指定することができる。この検索語が複数の場合、論理条件（ＡＮＤ，ＯＲ，ＮＯＴとそれらの組合せ）を指定することができる。例えば、（種別（検索），検索語（論理条件，検索語））として、（ｓｅａｒｃｈ，（ｋｅｙ１  ＡＮＤ  ｋｅｙ２）ＯＲ  ｋｅｙ３）とすることができる。即ち、キーワードｋｅｙ１，ｋｅｙ２のアンド条件と、更にキーワードｋｅｙ３のオア条件とを指定することができる。
制約条件は、制約種別と、時間範囲や階層の深さ等の制約値を含むものである。
検索依頼用の構造に関する制約条件として、制約種別には、スコープ指定，階層構造指定，時間構造指定がある。
上記スコープ指定として、検索対象のスキーマ種別を指定することができる。スキーマ種別は論理条件（ＡＮＤ，ＯＲ，ＮＯＴとそれらの組合せ）によって複数指定することができる。例えば、（制約種別，スキーマ種別（論理条件  スキーマ種別）として、（ｓｃｏｐｅ，ｔａｇ＿Ｓｃｈｅｍａ１  ＡＮＤ  ｔａｇ  Ｓｃｈｅｍａ２）とすることができる。
また、階層構造指定として、スコープ指定したスキーマの定義が、再帰的定義されている場合、スキーマのトップレベルノードから階層を指定することができる。
例えば、（制約種別，（スキーマ種別，階層数））として、（ｌｅｂｅｌ，（ｔａｇ＿Ｓｃｈｅｍａ１，２））とすることができる。この場合の再帰的定義のスキーマのｔａｇ＿Ｓｃｈｅｍａ１について、図１４（Ａ）の木構造の階層の二つ目までの太線で示す範囲が検索対象となり、検索条件に合致した場合は、ｒｏｏｔノードからｔａｇ＿Ｓｃｈｅｍａ１までの部分木と、ｔａｇ＿Ｓｃｈｅｍａ１の階層に関して二つ目までの構造、即ち、図１４（Ｂ）に示すデータをクライアントに送信することになる。
また、時間構造指定として、スコープ指定したスキーマが再生時間軸と関連した構造記述がされている場合に、構造制限を与える為に時間間隔情報を指定することができる。例えば、（制約種別，（スキーマ種別，時間間隔，内側／包含），・・・）として、（ｔｉｍｅ，（ｔａｇ＿Ｓｃｈｅｍａ１，４００−４５０，包含））とすることができる。
この場合、動画像全体の再生時間が５００（例えば、単位＝秒）であり、ｔａｇ＿Ｓｃｈｅｍａ１が時間構造を記述し、且つ全体の０−５００の特徴記述が上位階層のｔａｇ＿Ｓｃｈｅｍａ１によって行われ、動画像データの前半０−２５０及び後半２５０−５００の特徴記述が、二つの下位階層のｔａｇ＿Ｓｃｈｅｍａ１によって行われており、更に“包含”が指定されている場合、例えば、図１５（Ｃ）に示す０−５００（秒）の時間長のコンテンツデータについて、ｔａｇ＿Ｓｃｈｅｍａ１（１）の前半０−２５０をｔａｇ＿Ｓｃｈｅｍａ１（２１）、後半の２５０−５００をｔａｇ＿Ｓｃｈｅｍａ１（２２）として、図１５（Ａ）に示す木構造で表すと、４００−４５０の再生時間を含む総ての特徴記述に関するデータ構造の太線で示すｔａｇ＿Ｓｃｈｅｍａ１（１）とｔａｇ＿Ｓｃｈｅｍａ１（２２）とが検索対象となり、合致した場合にｒｏｏｔノードからそのデータ構造までの部分木と同データ構造の部分木、即ち、図１５（Ｂ）に示すｔａｇ＿Ｓｃｈｅｍａ１１（１）までの部分木と、ｔａｇ＿Ｓｃｈｅｍａ１（１）の一部とｔａｇ＿Ｓｃｈｅｍａ１（２２）とから構成される部分木とを含むデータがクライアントに送信される。
また、（ｔｉｍｅ，（ｔａｇ＿Ｓｃｈｅｍａ１，２００−５００，内側））により“内側”が指定されている場合は、再生時間が２００−５００の内側にある特徴記述に関するデータ構造、この場合、ｔａｇ＿Ｓｃｈｅｍａ１（２２）のみが検索対象となり、合致した場合は、ｒｏｏｔノードから同データ構造までの部分木と同データ構造の部分木がクライアントに送信される。なお、この場合、ｔａｇ＿Ｓｃｈｅｍａ１（１）のｔａｇ＿ｓｃ１は送信されない。
また、取得依頼用の構造に関する制約条件として、部分木指定，部分木の階層構造指定，部分木の時間構造指定，残データ指定がある。
部分木指定は、取得したい記述子の記述データに関して、その記述子の親ノードへのパスに関する情報と、取得したい子ノードに関する記述子の情報を指定することができる。例えば、（制約種別，（パス情報，（記述子，・・・））若しくは（制約種別，（パス情報，ＡＬＬ））として、（ｓｅｌｅｃｔ，（ｔａｇ＿ＭｅｔａＤａｔａｔａｇ＿Ｓｃｈｅｍａ１，（ｔａｇ＿Ｓｃｈｅｍａ１）））とすることができる。この場合、図１６（Ａ）に於いて、ｔａｇ＿ＭｅｔａＤａｔａの次にｔａｇ＿Ｓｃｈｅｍａ１を辿って到達できるノードに関して、その子ノードのタグがｔａｇ＿Ｓｃｈｅｍａ１の部分木を総て取得する。また、図１６（Ａ）の太線の部分を取得済みとすると、細線の部分が取得対象となり、図１６（Ｂ）の実線で示す部分木についてクライアントに送信する。
また、部分木の階層構造指定は、取得要求した記述子のスキーマが再帰的定義されている場合、スキーマの部分木のトップレベルノードから階層を指定することができる（相対又は絶対の位置で階層を指定）。
例えば、（制約種別，（パス情報，（（記述子，階層数），・・）））として、（ｓｅｌｅｃｔ＿ｌｅｖｅｌ，（ｔａｇ＿ＭｅｔａＤａｔａｔａｇ＿Ｓｃｈｅｍａ１，（ｔａｇ＿Ｓｃｈｅｍａ１，１）））とすることができる。この場合、図１７（Ａ）に示すように、ｔａｇ＿ＭｅｔａＤａｔａの次に、ｔａｇ＿Ｓｃｈｅｍａ１を辿って到達できるノードに関して、子ノードの内、タグがｔａｇ＿Ｓｃｈｅｍａ１の部分木について階層が一つまでの部分木を取得し、この部分木までのパス情報と、部分木のデータと、取得可能な記述データの記述子に関する情報とをクライアントに送信する。なお、図１７（Ａ）の太線で示す部分を取得済みとすると、細線で示す部分が取得対象となり、その結果、図１７（Ｂ）に示す取得可能な記述データがクライアントに送信されることになる。
また、部分木の時間構造指定は、取得したい記述子のスキーマが再生時間軸と関連した構造記述する為のものである場合は、構造制限を与える為に時間間隔情報を指定することができる。例えば、（制約種別，（パス情報，（（記述子，時間間隔情報，包含／内側），・・・）））として、（ｓｅｌｅｃｔ＿ｔｉｍｅ，ｔａｇ＿ＭｅｔａＤａｔａｔａｇ＿Ｓｃｈｅｍａ１，（ｔａｇ＿Ｓｃｈｅｍａ１，１００−３００，内側）））とすることができる。
この場合、図１８（Ｃ）に示す０−５００の再生時間のコンテンツデータの特徴記述として、前半のｔａｇ＿Ｓｃｈｅｍａ１（２１）と後半のｔａｇ＿Ｓｃｈｅｍａ１（２２）と共に、前半の０−１２５をｔａｇ＿Ｓｃｈｅｍａ１（３２１）、後半の１２５−２５０をｔａｇ＿Ｓｃｈｅｍａ１（３２２）とし、木構造として図１８（Ａ）に示すことができる。そして、太線の部分を取得済みとし、細線の部分を未取得部分とすると、図１８（Ｂ）に示す細線の部分のデータをクライアントに送信することになる。なお、“内側”が指定されている場合、再生時間の内側にある特徴記述に関するデータ構造のｔａｇ＿Ｓｃｈｅｍａ１（３２２）のみを抽出し、ｒｏｏｔノードからそのデータ構造までの位置情報と同データ構造の部分木とがクライアントに送信される。また、“包含”が指定された場合は、検索依頼用の構造に関する制約条件と同様に、１００−３００に係わる総てのデータ構造のｔａｇ＿Ｓｃｈｅｍａ１（２２）以外の総てを抽出し、ｒｏｏｔノードから同データ構造までの部分木と同データ構造の部分木とがクライアントに送信される。
また、残データ指定は、取得したい記述子のスキーマについて、現在取得済み以外の残りの記述データについて取得依頼することを示す。例えば、（制約種別，パス情報）として、（ｒｅｓｔ，ｔａｇ＿ＭｅｔａＤａｔａ）とすることができる。例えば、図１９（Ａ）に示すデータ構造に於いて、太線部分が取得済みの場合に、図１９（Ｂ）に示すｒｏｏｔノードのｔａｇ＿ＭｅｔａＤａｔａから点線部分を除き、実線部分が残データとしてクライアントに送信される。
前述のように、クライアント５からの検索依頼命令及び取得依頼命令に、それぞれメタデータの構造に関する制約条件を付与できるもので、クライアント５の制約条件生成処理部５１（図３参照）に於いて、制約条件を生成し、これを検索依頼命令または取得依頼命令に付加するものである。検索サーバ２は、そのメタデータフィルタリング処理部２２に於いて検索対象のメタデータから制約条件に合致するデータ構造を抽出して、クライアント５に送信するものである。
クライアント５に於いては、検索サーバ２からネットワークを介して送信されたメタデータを、メタデータ再構成処理部５２により再構成する。最初に部分木として検索サーバ２から受信したメタデータをメタデータ管理部５３に転送し、それ以後の部分木として検索サーバ２から受信したメタデータは、メタデータ再構成処理部５２に於いて追加，更新され、メタデータ管理部５３に於いて管理される。また、残データ指定の場合は、検索サーバ２の検索結果データ生成処理部２１が、クライアント５に送信したメタデータについて、どの部分木を送信し、どの部分木が残っているかを管理する機能を有し、この機能によって、残データを送信することができる。
従来の検索システムと対比すると、従来は、クライアントから検索サーバに対する上り方向の検索依頼命令は、検索語が複数の場合の論理条件（検索条件）と、検索カテゴリー（スキーマ種別）指定の制約条件のみであり、メタデータ構造に関する制約条件を付与することができないものであった。また、構造の制約条件に基づいて、部分的なメタデータを抽出するフィルタリング処理機能と、部分的なメタデータと取得可能のメタデータとに関する情報を送信する機能とを備えていないものであった。更に、取得依頼命令に関して、構造の制約条件に基づいて抽出された部分的なデータを取得することができないものであり、また、クライアント側にメタデータの部分木の再構成する機能を備えていないものであった。
以下、具体的なプログラム例を挙げて説明する。
まず、図２０〜図２２は、メタデータに関するＸＭＬスキーマ定義の一例を示す図である。尚、図２０〜図２２は、都合により、ある１つのＸＭＬスキーマ定義を３つの図に分けて示しているだけである。
上述してあるように、例えばステップＳ６５，Ｓ８６や、ステップＳ４１，Ｓ４２の処理においては、このようなＸＭＬスキーマ定義を参照することで、架空の部分木（取得済みの部分木の下に存在する、未取得の部分木）の存在や、再帰的な階層の単位が存在するか否か等を知ることができる。
例えば、図２０〜図２２に示すＸＭＬスキーマ定義の例によれば、まず、図２０に示す＜Ｍｐｅｇ７Ｍａｉｎ＞タグの定義から、動画像データの特徴記述を行う＜Ｖｉｄｅｏ  Ｄｅｓｃｒｉｐｔｉｏｎ＞タグが存在することを知ることができる。また、図２１に示す“Ｖｉｄｅｏ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｔｙｐｅ”型の定義から、“Ｖｉｄｅｏ  Ｓｅｇｍｅｎｔ  Ｔｙｐｅ”型で定義される＜Ｖｉｄｅｏ＞タグが存在することを知ることができる。
また、図２１に示す“Ｖｉｄｅｏ  Ｓｅｇｍｅｎｔ  Ｔｙｐｅ”型の定義から、“Ｓｅｇｍｅｎｔ  Ｄｅｃｏｍｐｏｓｉｔｉｏｎ  Ｔｙｐｅ”型で定義される＜Ｓｅｇｍｅｎｔ  Ｄｅｃｏｍｐｏｓｉｔｉｏｎ＞タグが存在することを知ることができ、更に、図２２に示す“Ｓｅｇｍｅｎｔ  Ｄｅｃｏｍｐｏｓｉｔｉｏｎ  Ｔｙｐｅ”型の定義から、“Ｖｉｄｅｏ  Ｓｅｇｍｅｎｔ  Ｔｙｐｅ”型で定義される＜Ｖｉｄｅｏ  Ｓｅｇｍｅｎｔ＞タグの存在を知ることができる。これより、“Ｓｅｇｍｅｎｔ  Ｄｅｃｏｍｐｏｓｉｔｉｏｎ  Ｔｙｐｅ”型のタグと“Ｖｉｄｅｏ  Ｓｅｇｍｅｎｔ  Ｔｙｐｅ”型のタグとが交互に再帰的に定義されていることが判定できる。
このとき、“Ｖｉｄｅｏ  Ｓｅｇｍｅｎｔ  Ｔｙｐｅ”型のタグから“Ｓｅｇｍｅｎｔ  Ｄｅｃｏｍｐｏｓｉｔｉｏｎ  Ｔｙｐｅ”型のタグまでを１つの階層の単位として取り扱うことができる。図２３の例で言うと、最初の“Ｖｉｄｅｏ  Ｓｅｇｍｅｎｔ  Ｔｙｐｅ”型のタグは＜Ｖｉｄｅｏ＞タグであり、この＜Ｖｉｄｅｏ＞タグから“Ｓｅｇｍｅｎｔ  Ｄｅｃｏｍｐｏｓｉｔｉｏｎ  Ｔｙｐｅ”型のタグである＜Ｓｅｇｍｅｎｔ  Ｄｅｃｏｍｐｏｓｉｔｉｏｎ＞タグまでが１つの階層（第１層）となる。同様に、次の“Ｖｉｄｅｏ  Ｓｅｇｍｅｎｔ  Ｔｙｐｅ”型のタグである＜Ｖｉｄｅｏ  Ｓｅｇｍｅｎｔ＞タグから、これに入れ子になっている＜Ｓｅｇｍｅｎｔ  Ｄｅｃｏｍｐｏｓｉｔｉｏｎ＞タグまでが１つの階層（第２層）となる。特に図示しないが、第３層以下についても同様である。
よって、あるメタデータのスキーマ定義が、図２０〜図２２に示す例のような定義であった場合には、ステップＳ４１，Ｓ４２の処理において、再帰的な階層の単位が存在するものと判定されることになる。
図２３は約１０分の動画像データの特徴記述としてのメタデータの説明図であり、図２４はこのメタデータを木構造としての概要を示すものである。
図２３に示す各記述子（タグ）は、上記図２０〜図２２で定義している通りである。すなわち、図２３に於いて、＜Ｍｐｅｇ７Ｍａｉｎ＞は、この動画像データに関して、ＭＰＥＧ７のスキーマによって特徴記述を行うことを宣言する為の記述子（タグ）であり、次の階層の＜ＶｉｄｅｏＤｅｓｃｒｉｐｔｉｏｎ＞は、ＭＰＥＧ７のスキーマの中で、メディア種別が動画像データのコンテンツに関する特徴記述を行うことを宣言する記述子である。
また、この＜ＶｉｄｅｏＤｅｓｃｒｉｐｔｉｏｎ＞の下位層に、動画像全体に対する特徴記述を行う記述＜Ｖｉｄｅｏ＞が宣言されている。
この＜Ｖｉｄｅｏ＞は、ｉｄ＝“ＲｏｏｔＳｅｇｍｅｎｔ”  ｌａｙｅｒ＝“１”を含む場合を一列として図示しており、
・動画像データの実体の所在に関する情報等を記述する＜ＭｅｄｉａＩｎｆｏｒｍａｔｉｏｎ＞と、
・タイトル文字，出演者名，ジャンル名，代表サムネイル，概要文，メタデータの作成日等を記述する＜ＣｒｅａｔｅＭｅｔａＩｎｆｏｒｍａｔｉｏｎ＞と、
・動画像の再生時間を記述する＜ＭｅｄｉａＴｉｍｅ＞と、
・動画像に関するコメント文を記述する＜ＴｅｘｔＡｎｎｏｔａｔｉｏｎ＞と、
・動画像データを時間軸に沿って構造化して記述する為の＜ＳｅｇｍｅｎｔＤｅｃｏｍｐｏｓｉｔｉｏｎ＞と、
を含む場合を示している。
また、この＜ＳｅｇｍｅｎｔＤｅｃｏｍｐｏｓｉｔｉｏｎ＞は、＜ＭｅｄｉａＩｎｆｏｒｍａｔｉｏｎ＞を除き、＜Ｖｉｄｅｏ＞と同じ記述が可能な＜ＶｉｄｅｏＳｅｇｍｅｎｔ＞を時間軸に従って複数記述することにより、動画像データを複数のセグメント単位で特徴記述が可能となる。従って、＜ＶｉｄｅｏＳｅｇｍｅｎｔ＞は再帰的定義されており、その下位の階層に＜ＳｅｇｍｅｎｔＤｅｃｏｍｐｏｓｉｔｉｏｎ＞を含むものである（上述してある通り、図２０〜図２２のスキーマ定義による）。
図２５は、図２３に示すメタデータを、検索依頼命令に応じてフィルタリング処理してクライアント５に返信した部分メタデータ（初期の部分メタデータ）の一例を示す図である。
図２５には、制約条件として、階層指定において１階層目（ｌａｙｅｒ＝“１”）までが指定された場合の部分メタデータを示す。
この場合、２階層目（ｌａｙｅｒ＝“２”）以下のデータが削除されたメタデータがクライアントに送信されるが、２階層目についてはタグ（記述子）のみ送信する。すなわち、図２３に示す＜ＶｉｄｅｏＳｅｇｍｅｎｔ  ｉｄ＝“ｓｅｇ１”  ｌａｙｅｒ＝“２”＞・・・＜ＶｉｄｅｏＳｅｇｍｅｎｔ  ｉｄ＝“ｓｅｇ４”  ｌａｙｅｒ＝“２”＞について、各々のタグのみ送信する。
これより、図２５に示すメタデータをクライアント５側で受信すると、＜ＳｅｇｍｅｎｔＤｅｃｏｍｐｏｓｉｔｉｏｎ＞に子ノード（入れ子になっているタグ）が４つ存在し、その種別が＜ＶｉｄｅｏＳｅｇｍｅｎｔ＞であることを知ることができる。また、上記図２０〜図２２のスキーマ定義を参照することで、上記の通り“Ｓｅｇｍｅｎｔ  Ｄｅｃｏｍｐｏｓｉｔｉｏｎ  Ｔｙｐｅ”型のタグと“Ｖｉｄｅｏ  Ｓｅｇｍｅｎｔ  Ｔｙｐｅ”型のタグとが交互に再帰的に定義されていることが分かるので、架空の部分木が存在する可能性があることが分かる。
これより、上記図１１の処理において、例えば、図２６に示すように、上記架空の部分木の位置情報及び種別情報をＸｐａｔｈで表現して、これを検索サーバ２に送信することで、架空の部分木を取得することができる（この例では４つの子ノード全て指定しているが、当然、１、２または３つの子ノードを指定してもよい）。
図２６に示すＸｐａｔｈは、例えば
＜Ｒｅｑｕｅｓｔ＝”／Ｍｐｅｇ７Ｍａｉｎ／ＶｉｄｅｏＤｅｓｃｒｉｐｔｉｏｎ／Ｖｉｄｅｏ／ＳｅｇｍｅｎｔＤｅｃｏｍｐｏｓｉｔｉｏｎ／ＶｉｄｅｏＳｅｇｍｅｎｔ”Ｎｕｍ＝“１”＞
等である。尚、Ｎｕｍ＝“１”は、４つの＜ＶｉｄｅｏＳｅｇｍｅｎｔ＞タグの中で１番目のタグを指定することを意味する。
図２７には、図２６の要求に応じて検索サーバ２から返信されるデータを示す。図示の通り、返信データには、図２６に示すＸｐａｔｈと、これに応じて取得した部分木のデータとが含まれる。図１２のステップＳ８４の処理では、このＸｐａｔｈと、メタデータ管理部５３に格納されている既存メタデータとを比較することで、取得した部分木を、既存メタデータのどこに結合すべきかを知ることができる。
更に、図示していないが、取得した部分木の中に３階層目のタグのみが含まれていた場合には、図１２のステップＳ８６、Ｓ８７の処理により、この架空の子ノードの位置情報、ノード種別を抽出し、記録することになる。
前述の動画像データに関する特徴記述は、例えば図２８に示すような、時間軸に沿った階層構造として表すことができる。即ち、前述の＜ＭｅｄｉａＴｉｍｅ＞により記述された再生時間０−１０（ｍｉｎ）について、複数のセグメントに分割し、各セグメントを更に分割することを繰り返した階層構造とした場合の階層Ｌａｙｅｒ１〜Ｌａｙｅｒ４とした場合を示し、＜ＶｉｄｅｏＳｅｇｍｅｎｔ  ｉｄ＝“Ｓｅｇ１”  Ｌａｙｅｒ＝“２”＞〜＜ＶｉｄｅｏＳｅｇｍｅｎｔ  ｉｄ＝“Ｓｅｇ１”  Ｌａｙｅｒ＝“４”＞によりＬａｙｅｒ２に於ける０−２（ｍｉｎ）のセグメント６１〜８−１０（ｍｉｎ）のセグメント６４を示し、また、＜ＶｉｄｅｏＳｅｇｍｅｎｔ  ｉｄ＝“Ｓｅｇ１１”  Ｌａｙｅｒ＝“３”＞によりＬａｙｅｒ３の０−１（ｍｉｎ）のセグメント６５を示す。
また、＜ＶｉｄｅｏＳｅｇｍｅｎｔ  ｉｄ＝“Ｓｅｇ３１１”  Ｌａｙｅｒ＝“４”＞により、Ｌａｙｅｒ４のセグメント６６を示すものである。
前述の０−１０分の動画像データについてのメタデータは、大凡５０ｋＢ程度となり、更に前述の制約条件を付加した検索要求に従って、検索サーバ２からクライアント５に送信するデータ量は大幅に削減され、且つ検索結果をクライアントに於いて迅速に表示できることになり、動画像データを階層的にブラウジングすることが容易となる。また、更に長時間の動画像データについても、導入部と複数の中間部と結末部とのセグメントの特徴記述とし、更に階層構造化することにより、クライアントは所望の制約条件に従って検索することが可能となる。また、出演者名とその出演が予定される時間構造指定とを含む検索要求等が可能となる。また、動画像データの特定のシーンの特徴記述のメタデータを指定して検索し、その検索結果に基づいた動画像データを保持するコンテンツサーバを識別することも可能である。また、セグメントの特徴記述に、動画像の代表画像（静止画またはダイジェスト動画）を含めることもできる。
図２９はクライアントのＧＵＩ（Ｇｒａｐｈｉｃａｌ  Ｕｓｅｒ  Ｉｎｔｅｒｆａｃｅ）の説明図であり、動画像データが、ジャンルとしてドラマ又は映画であり、始めの５分間位に、出演者の富士通太郎が出演しているような動画像データを取得したいとし、また、取得した動画像データに関して、一つ深い階層レベルで詳細を知りたい場合についての入力画面を示し、これに基づいて、前述の構造に関する制約条件の内、検索条件として、スコープ指定：（ｓｃｏｐｅ，Ｖｉｄｅｏ  ＯＲ  ＶｉｄｅｏＳｅｇｍｅｎｔ  ＯＲ  ジャンル  ＯＲ  出演者）と、時間構造指定：（ｔｉｍｅ，（Ｖｉｄｅｏ，０−５ｍｉｎ，包含），（ＶｉｄｅｏＳｅｇｍｅｎｔ，０−５ｍｉｎ，内側））の制約条件が付加された取得依頼命令が制約条件生成処理部５１（図３参照）から検索サーバに送出される。
検索サーバ２に於いては、例えば、図２８のメタデータの０−５（ｍｉｎ）の時間による構造の制約条件の＜Ｖｉｄｅｏ＞及び＜ＶｉｄｅｏＳｅｇｍｅｎｔ＞の構造に関して、＜ＣｒｅａｔｅＭｅｔａＩｎｆｏｒｍａｔｉｏｎ＞のジャンル及び出演者に関するキーワードによる検索を実行する。そして、ジャンルの“Ｄｒａｍａ／Ｍｏｖｉｅ”及び出演者の“富士通太郎”に、セグメントｓｅｇ１１が合致した場合、検索サーバ２は、＜Ｖｉｄｅｏ＞の階層までの部分木のみをクライアント５に送信する。
この部分木に継続して追加できる他の記述子若しくは記述データは、クライアント５からの要求とブラウジング行為によって、検索条件に合致した階層の＜ＶｉｄｅｏＳｅｇｍｅｎｔ＞のノードまで到達する検索が可能である。この場合、全＜Ｖｉｄｅｏ＞及び＜ＶｉｄｅｏＳｅｇｍｅｎｔ＞のノード数が１９とすると、１ノード当たり約２．５ｋＢ程度となり、この約２．５ｋＢのデータ転送によって、トップレベルの概要画像をユーザに提示できることになる。
また、検索サーバ２の表示テンプレート選択処理部２３（図２参照）により、クライアント５に送信するメタデータのスキーマ毎に、そのスキーマを表示するのに適切な表示テンプレートデータを、メタデータ表示用テンプレートデータベース６から選択して、メタデータと共に、検索結果データとして送信する。これにより、クライアント５のアプリケーションが、特定のスキーマが解釈できる専用のブラウザではなく、ＸＳＬ（Ｅｘｔｅｎｓｉｂｌｅ  Ｓｔｙｌｅ  Ｌａｎｇｕａｇｅ）のような表示テンプレートデータを用いて表示形式を決定するＷＥＢブラウザに対して有効である。この場合、クライアント５の表示テンプレートデータ管理部５４（図３参照）により表示テンプレートデータを管理し、表示データ生成処理部５５に於いてブラウザ用表示データを生成する際に、メタデータ管理部５３で管理しているメタデータと共に使用して、表示データを生成することができる。
図３０は表示テンプレートデータの説明図であり、７１〜７３は表示画面の一例を示す。メタデータ取得要求（検索依頼命令）により、検索サーバ２から、メタデータ７４と、動画像階層選択表示用の表示テンプレートデータ７５とが返信されてくるので、これをクライアント５が受信することにより、全体サマリと前半サマリと後半サマリとを含む表示画面７１を構成することができる。そして、前半サマリを選択して検索サーバ２にメタデータ取得要求（取得依頼命令）を行うと、検索サーバ２はメタデータ７６を返信してくる。これにより、クライアント５は、１／２サマリ（前半サマリ）の下位の階層の１／４サマリと２／４サマリとを含む表示画面７２を構成することができる。尚、図示のメタデータ７６において実際に返信されてくるデータは、部分木７６ａの部分である。
更に１／４サマリを選択してメタデータ取得要求を行うと、検索サーバ２からキーフレームのカラーヒストグラムデータ７７ｂを含むメタデータ７７と、グラフ表示用の表示テンプレートデータ７８とが返信されてくるので、クライアント５はこれを受信し、キーフレームのカラーヒストグラム７３ａを表示する表示画面７３を構成することができる。尚、図示のメタデータ７７において実際に返信されてくるデータは、部分木７７ａの部分である。
また、クライアント５のメタデータ再構成処理部５２は、例えば、制約条件を付加した検索要求に対して、検索サーバ２から１画面を分割した部分画像についてのメタデータとして受信し、更に、その後の制約条件を付加した検索要求に従って、その周辺の部分画像についてのメタデータを受信した場合に、各部分画像の位置情報等を基に１画面又は複数部分画像を連結した部分画像として再構成する機能も備えており、中央部分画像のみでは、所望の動画像データであることを識別できない場合に、その周辺部分画像を順次取得することによるブラウジングにも適用することができる。
図３１は、上述した各種処理を実現するコンピュータ（検索サーバ２またはクライアント５）のハードウェア構成の一例を示す図である。
図３１に示すコンピュータ８０は、ＣＰＵ８１、メモリ８２、入力装置８３、出力装置８４、外部記憶装置８５、媒体駆動装置８６、ネットワーク接続装置８７等を有し、これらがバス８８に接続された構成となっている。同図に示す構成は一例であり、これに限るものではない。
ＣＰＵ８１は、当該コンピュータ８０全体を制御する中央処理装置である。
メモリ８２は、プログラム実行、データ更新等の際に、外部記憶装置８５（あるいは可搬記録媒体８９）に記憶されているプログラムあるいはデータを一時的に格納するＲＡＭ等のメモリである。ＣＰＵ８１は、メモリ８２に読み出したプログラム／データを用いて、上述した各種処理を実行する。
入力装置８３は、例えばキーボード、マウス、タッチパネル等である。
出力装置８４は、例えばディスプレイ、プリンタ等である。
尚、コンピュータ８０が検索サーバ２である場合には、入力装置８３、出力装置８４は、無くても良い。
外部記憶装置８５は、例えばハードディスク装置等であり、上記各種機能を実現させる為のプログラム／データ等（例えば図５〜図１２に示す各処理をコンピュータに実行させるプログラム等）が格納されている。また、当該プログラム／データ等は、可搬記録媒体８９に記憶されており、媒体駆動装置８６が、可搬記録媒体８９に記憶されているプログラム／データ等を読み出して、上記各種処理をコンピュータ８０に実行させるようにしてもよい。可搬記録媒体８９は、例えば、ＦＤ（フレキシブルディスク）、ＣＤ−ＲＯＭ、その他、ＤＶＤ、光磁気ディスク等である。
ネットワーク接続装置８７は、ネットワーク（インターネット等）に接続して、外部の情報処理装置とプログラム／データ等の送受信を可能にする構成である。
図３２は、上記プログラムを記録した記録媒体又はプログラムのダウンロードの一例を示す図である。
図示のように、上記本発明の機能を実現するプログラム／データが記憶されている可搬記録媒体８９を情報処理装置８０の本体に挿入する等して、当該プログラム／データを読み出してメモリ８２に格納し実行するものであってもよいし、また、上記プログラム／データは、ネットワーク接続装置８７により接続しているネットワーク９２（インターネット等）を介して、外部のプログラム／データ提供者側のサーバ９０に記憶されているプログラム／データ９１をダウンロードするものであってもよい。
また、本発明は、装置／方法に限らず、上記プログラム／データを格納した記録媒体（可搬記録媒体８９等）自体として構成することもできるし、これらプログラム自体として構成することもできる。あるいは、上記ネットワークを介してダウンロードされるプログラム（伝送信号）自体として構成することもできる。
【産業上の利用の可能性】
以上説明したように、本発明は、クライアントから検索サーバに対して各種の制約条件を付加して検索要求を送信し、検索サーバは、この検索要求に対してデータベースを検索し、検索結果に対して制約条件に対応したフィルタリング処理を行った検索結果データをクライアントに送信するもので、不要な記述子や記述データ等を送信しないことにより、検索サーバとクライアントとの間の通信量を削減できる利点がある。特に、制約条件として、メタデータの構造（特に、時間構造、階層構造等）に関する条件を用いることにより、そのクライアント側で本当に必要とする部分のみを取得し易くなる。
また、データベースには、コンテンツサーバが保持するコンテンツに対して、階層的に分割したセグメントの特徴記述を行ったメタデータをキーワードと共に格納した構成を有し、各種の動画像データの検索時に、検索サーバに於いて制約条件に従ってフィルタリング処理することで、必要最小限度のデータ量をクライアントに送信することができ、クライアントは順次詳細な内容に向かった検索が可能となる利点がある。従って、動画像データの検索に適用して、クライアントの迅速なブラウジングを可能とすると共に、システム負荷の軽減が可能となる。
【図１】
2004023341.tif 000003
【図２】
2004023341.tif 000004
【図３】
2004023341.tif 000005
【図４】
2004023341.tif 000006
【図５】
2004023341.tif 000007
【図６】
2004023341.tif 000008
【図７】
2004023341.tif 000009
【図８】
2004023341.tif 000010
【図９】
2004023341.tif 000011
【図１０】
2004023341.tif 000012
【図１１】
2004023341.tif 000013
【図１２】
2004023341.tif 000014
【図１３】
2004023341.tif 000015
【図１４】
2004023341.tif 000016
【図１５】
2004023341.tif 000017
【図１６】
2004023341.tif 000018
【図１７】
2004023341.tif 000019
【図１８】
2004023341.tif 000020
【図１９】
2004023341.tif 000021
【図２０】
2004023341.tif 000022
【図２１】
2004023341.tif 000023
【図２２】
2004023341.tif 000024
【図２３】
2004023341.tif 000025
【図２４】
2004023341.tif 000026
【図２５】
2004023341.tif 000027
【図２６】
2004023341.tif 000028
【図２７】
2004023341.tif 000029
【図２８】
2004023341.tif 000030
【図２９】
2004023341.tif 000031
【図３０】
2004023341.tif 000032
【図３１】
2004023341.tif 000033
【図３２】
2004023341.tif 000034
【図３３】
2004023341.tif 000035
【国際調査報告】
2004023341.tif 000036
2004023341.tif 000037