(57)【要約】　　【課題】　　　データベースからコンポーネント化されたマルチメディアデータ処理部を取り出すとき、マルチメディアデータ処理部を一旦データベースから取り出し、そのマルチメディアデータ処理部と他のマルチメディアデータ処理部との条件判定を行う必要があり、マルチメディアデータ処理部の検索に時間がかかる。　　【解決手段】　データベースへマルチメディアデータ処理部本体だけではなく、マルチメディアデータ処理部の条件判定を行う関数の関数エントリも登録しておき、マルチメディアデータ処理部の検索時には、まず関数エントリのみ取り出し条件判定を行い、目的のものであった場合のみマルチメディアデータ処理部本体を取り出す。これによって、マルチメディアデータ処理部の検索の時間が短縮される。　【選択図】　　　図１
2004139563.tif 000002
【特許請求の範囲】
【請求項１】
　１以上のコンポーネントを保持するデータベースを有しており、前記コンポーネントを読み込んだファイルに適用して処理を施すデータ処理装置であって、前記データベース内には前記ファイルのファイル情報に基づいて処理に適したコンポーネントを判定するタイプ判定関数を有することを特徴とするデータ処理装置。
【請求項２】
　前記タイプ判定関数は、前記コンポーネント各々の内部に保持されていることを特徴とする請求項１記載のデータ処理装置。
【請求項３】
　前記データベースは、前記タイプ判定関数の参照先を示す判定関数エントリを保持することを特徴とする請求項１または請求項２記載のデータ処理装置。
【請求項４】
　前記判定関数エントリは、各コンポーネントと１対１に対応して保持されることを特徴とする請求項３記載のデータ処理装置。
【請求項５】
　前記データベースに保持されるコンポーネントの中から処理に適したコンポーネントを検索するための判定手段をさらに有し、
　前記判定手段は、前記判定関数エントリを前記データベースから読み込み、さらに前記判定関数エントリが参照先として示す前記タイプ判定関数を前記データベースより読み込み、処理対象であるファイルのファイル情報を前記判定関数に適用して判定することより、処理に適したコンポーネントを検索することを特徴とする請求項３または請求項４記載のデータ処理装置。
【請求項６】
　前記判定手段により検索されたコンポーネントを読み込んで組合せることにより、目的とする処理を実行する処理部をさらに備え、
　前記処理部内に存する制御手段は、コンポーネントの出力ファイルのファイル情報を読み込んで前記判定手段に伝えることにより、前記出力ファイルに対する次の処理に適したコンポーネントを選択することを可能とすることを特徴とする請求項５記載のデータ処理装置。
【請求項７】
　過去に構成したコンポーネントの構成パターンを記憶するコンポーネント構成データベースと、読み込んだファイルの情報に基づいて、記憶された構成パターンの中から処理に適した構成パターンを検索する構成パターン検索手段とを有することを特徴とする請求項１記載のデータ処理装置。
【請求項８】
　コンポーネントを格納したデータベースサーバにネットワークを介して接続可能なダウンロード手段を備え、検索された構成パターンに含まれるコンポーネントが前記データベースに存在しない場合は、前記ダウンロード手段が前記データベースサーバから必要なコンポーネントを取得することを特徴とする請求項７記載のデータ処理装置。
【請求項９】
　前記ダウンロード手段は、データ処理装置に接続されたコンポーネントを格納した記録媒体から必要なコンポーネントを取得することを特徴とする請求項８記載のデータ処理装置。
【請求項１０】
　前記ダウンロード手段が新たなコンポーネントを取得したとき、取得したコンポーネントは前記データベースに格納され、当該コンポーネントの格納先を示す情報は前記コンポーネント構成データベースに保持されることを特徴とする請求項８記載のデータ処理装置。
【請求項１１】
　対象とするデータの処理に適したコンポーネントであるか否かを判定するタイプ判定関数と前記タイプ判定関数を参照先として出力する判定関数エントリとを保持するデータベースを備えたデータ処理装置のデータ処理方法であって、
　前記判定関数エントリを前記データベースから読み込む第１のステップと、
　前記判定関数エントリが参照先として示す前記タイプ判定関数を前記データベースより読み込む第２のステップと、
　前記タイプ判定関数に処理対象であるデータの情報を適用し、適用可否の結果を得る第３のステップと、
　を有し、処理に適したコンポーネントが選択されるまで前記第１のステップから第３のステップを繰り返すことを特徴とするデータ処理方法。
【請求項１２】
　対象とするデータの処理に適したコンポーネントをデータベースから選択するためのデータ処理プログラムであって、コンピュータに、
　対象とするデータの処理に適しているコンポーネントか否かを判定するタイプ判定関数の参照先を出力する判定関数エントリを読み込むステップと、
　前記判定関数エントリが参照先として示すタイプ判定関数を読み込むステップと、
　前記タイプ判定関数に処理対象であるデータの情報を適用し、適用可否の結果を得るステップと、
　を実行させるためのデータ処理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
　本発明は、ある機能を実現するために組み合わされたソフトウェア部品から構成されるコンポーネントを読み込んで処理を実行するデータ処理装置、およびコンポーネントデータベースに関し、特にメディアデータ処理コンポーネントの保持方法および高速な読み出し方法に関する。
【背景技術】
【０００２】
　従来のデータ処理装置は、データベースにコンポーネントの名前および属性が保持されており、データ処理制御部は目的のコンポーネントを名前や属性より探し出し、また名前や属性の情報では不足している場合、実際にコンポーネント全体を読み出すように構成されているものがある（例えば、特許文献１の図１参照）。
【０００３】
　特許文献１に記載されているデータ処理装置（文献中では、資源管理装置と呼ばれている）の全体構成を図２０に示す。
【０００４】
　同図に示すデータ処理装置８００は、コンテキスト保持部８０１−１〜Ｎ、属性保持部８０２−１〜Ｎ、名前解析部８０３−１〜Ｎ、名前変換部８０４−１〜Ｎ、名前解決部８０５、資源実現部８０６、資源保持部８０７−１〜Ｍ、資源管理部８０８、通信部８０９、コンテキストデータベース部８１０、コンテキストデータベース検索部８１１、コンテキスト選択部８１２、及びコンテキスト抽出部８１３から構成されている。
【０００５】
　コンテキスト保持部８０１−１〜８０１−Ｎには、属性保持部８０２−１〜８０２−Ｎ、名前解析部８０３−１〜８０３−Ｎ、名前変換部８０４−１〜８０４−Ｎがそれぞれ設けられている。属性保持部８０２−１〜８０２−Ｎには、それぞれコンテキスト保持部８０１−１〜８０１−Ｎに付けられた任意の個数の属性が、その属性名と属性値のペアのリストとして保持されている。
【０００６】
　名前解析部８０３−１〜８０３−Ｎは、それぞれ入力される資源の名前を解析する。名前変換部８０４−１〜８０４−Ｎは、それぞれ名前解析部８０３−１〜８０３−Ｎで解析された結果を受け、解析結果を資源実現表現に変換する。この資源実現表現は、資源検索式を要素とする資源要素列と、その資源要素列を処理するための手続き情報との組から構成される。ここで、資源検索式は、計算機システム内にあらかじめ実現されている実資源を指定するための検索式である。
【０００７】
　名前解決部８０５は、コンテキスト保持部８０１−１〜８０１−Ｎが出力した資源実現表現を受け取り、その資源実現表現のすべてあるいはいずれかに対応する名前解決結果が資源実現部８０６に対して出力される。
【０００８】
　資源実現部８０６は、名前解決部８０５から出力された名前解決結果を入力し、その名前解決結果に対応する資源のハンドルを出力する。
【０００９】
　資源保持部８０７−１〜Ｍは、それぞれあらかじめ実現されている資源を保持するとともに、その資源を識別するための識別子を保持している。
【００１０】
　資源管理部８０８は、資源保持部８０７−１〜Ｍが保持している資源を管理するとともに、前記資源検索式に従って資源を特定する。
【００１１】
　通信部８０９は、名前解決部８０５、資源実現部８０６、資源管理部８０８、及びコンテキストデータベース部８１０間の通信を行う。
【００１２】
　コンテキストデータベース部８１０は、Ｎ個のコンテキスト保持部８０１−１〜Ｎをコンテキスト集合として管理しており、コンテキストデータベース検索部８１１、コンテキスト選択部８１２、コンテキスト抽出部８１３を有している。
【００１３】
　コンテキストデータベース検索部８１１は、属性を用いて記述されているコンテキスト検索式を受け取り、そのコンテキスト検索式を満足する属性を有しているコンテキスト保持部８０１−ｉ（ｉは１〜Ｎの整数）をコンテキスト集合から探し出す。検索結果は、例えばコンテキスト保持部８０１−ｉに対するリファレンスの集合として出力することができる。
【００１４】
　コンテキスト選択部８１２は、コンテキストデータベース間等の通信を行う通信部８０９にコンテキスト集合の抽出を行うためのコンテキスト検索式が入力されたとき、このコンテキスト検索式をコンテキストデータベース検索部８１１に渡して、コンテキスト検索式を満足するコンテキスト保持部８０１−ｉの集合を得て、コンテキスト抽出部８１３に出力する。
【００１５】
　コンテキスト抽出部８１３は、コンテキスト保持部８０１−ｉに対するリファレンスの集合を入力とし、そのリファレンスによって示されるコンテキスト保持部８０１−ｉと等価なコンテキスト保持部を合成するために必要な情報をコンテキスト表現として出力する。
【００１６】
　例えば、データ処理装置８００において、属性保持部８０２−１〜Ｎには、所有者を表わす属性“ｏｗｎｅｒ”、変更日時を表わす“ｍｄａｔｅ”、及びカテゴリを表わす“ｃａｔｅｇｏｒｙ”の３つの属性が、属性名と属性値のペアのリストとして保持されているものとする。ここでは、属性保持部８０２−１の“ｏｗｎｅｒ”の値は“Ｓｍｉｔｈ”、“ｍｄａｔｅ”の値は９５．３．１８、及び“ｃａｔｅｇｏｒｙ”の値は“ｐｉｃｔｕｒｅ”であり、属性保持部８０２−２の“ｏｗｎｅｒ”の値は“Ｓｍｉｔｈ”、“ｍｄａｔｅ”の値は９５．１１．１４、及び“ｃａｔｅｇｏｒｙ”の値は“ｐｉｃｔｕｒｅ”であり、属性保持部８０２−３〜Ｎの全ての“ｏｗｎｅｒ”の値は“Ｂｉｌｌ”、“ｍｄａｔｅ”の値は９５．３．３、及び“ｃａｔｅｇｏｒｙ”の値は“ｓｏｕｎｄ”であるとして、コンテキストの抽出を行う動作を中心に説明する。
【００１７】
　まず、例えば所有者を表わす属性“ｏｗｎｅｒ”の値が“Ｓｍｉｔｈ”に等しく、かつ、変更日時を表わす属性“ｍｄａｔｅ”の値が９５．３．１６よりも大きく、かつ、カテゴリ属性“ｃａｔｅｇｏｒｙ“の値が“ｐｉｃｔｕｒｅ”に等しいコンテキスト保持部８０１を検索する場合を考える。
【００１８】
　コンテキスト選択部８１２は、コンテキストデータベース検索部８１１に上記検索を実現するための検索式を渡し、この検索式を満足する属性を属性保持部８０２に有するコンテキスト保持部８０１を検索する。検索式は例えば、Ｃ＋＋　ＯｂｊｅｃｔＱｕｅｒｙＬａｎｇｕａｇｅに準拠した場合は図２１に示すような記載となる。この検索式をコンテキスト保持部８０１−１およびコンテキスト保持部８０１−２のみが満たすので、検索結果としてコンテキストデータベース検索部８１１は、コンテキスト保持部８０１−１のリファレンスと、コンテキスト保持部８０１−２のリファレンスとからなる集合をコンテキスト選択部８１２に返す。
【００１９】
　コンテキスト保持部８０１−１のリファレンスと、コンテキスト保持部８０１−２のリファレンスとからなる集合を受け取ったコンテキスト選択部８１２は、受け取った集合をコンテキスト抽出部８１３に入力し、リファレンスに該当するコンテキスト保持部８０１−１及びコンテキスト保持部８０１−２を取り出すよう要求することにより、該当するコンテキストを取得することができる。
【特許文献１】特開平９−１７１５０１号公報
【発明の開示】
【発明が解決しようとする課題】
【００２０】
　しかしながら、従来のデータ処理装置では、従来の名前や属性では識別できないような新規の属性が付加されたコンテキストが追加された場合、それに合わせて従前のコンテキスト保持部も再構築しなければならないという問題があった。
【００２１】
　具体的には、例えば、ファイルサイズを示す属性“ｓｉｚｅ”が追加された場合は、全てのコンテキスト保持部を更新する必要があり、コンテキスト保持部の数が多い場合や、頻繁に新しい属性が追加されている場合は、コンテキスト保持部のメンテナンスの負荷が大きくなってしまうという問題が発生する。
【００２２】
　本発明は、このような問題を解決するためになされたもので、新規コンポーネントが追加された場合でもデータベースの再構築を不必要とするデータ処理装置、データ処理方法及びデータ処理プログラムを提供することを目的とする。
【課題を解決するための手段】
【００２３】
　上記課題を解決するために本発明においては、コンポーネント内にコンポーネント本体とは別に、対象とするデータの処理に適するコンポーネントであるか否かを判定するタイプ判定関数を有し、データ処理装置には、読み込んだファイルまたは前段のコンポーネントにより処理され出力されたデータの情報を前記タイプ判定関数に適用する判定手段を備え、各コンポーネントと対応するタイプ判定を実施することで、判定のための属性が変更または追加となったとしても、タイプ判定関数のみを変更すれば足り、コンポーネント本体（従来のコンテキスト保持部全体に相当）を更新する必要はないため、効率的にデータベースを更新することが可能となる。
【発明の効果】
【００２４】
　以上説明したように、本発明によれば、新規コンポーネントが追加された場合でもデータベースの再構築を不必要とすることができる。
【発明を実施するための最良の形態】
【００２５】
　以下、本発明の実施の形態について図１から図１９を用いて説明する。なお、本発明は本実施の形態に何ら限定されるものではなく、その要旨を逸脱しない範囲において、様々なる態様で実施し得る。
【００２６】
　（実施の形態１）
　図１は、本発明の実施の形態１におけるデータ処理装置１００を示したブロック図である。図１において、メディアコンポーネントデータベース１０１は、メディアを処理するためのコンポーネントであるメディアコンポーネントを保持している。メディア判定部１０２は、メディアコンポーネントを比較して判別する。操作入力部１０３は、ユーザからの入力を受け付ける。ファイルシステム１０４は、マルチメディアデータを保持している。メディア処理部１０５は、メディアの処理を行う。映像表示部１１１は、映像を表示する。音声出力部１１２は、音声を出力する。
【００２７】
　図２は、メディアコンポーネントデータベース１０１が保持するコンポーネントの保持形態を示した図である。
【００２８】
　メディアコンポーネントデータベース１０１には、メディアコンポーネント３０−１〜Ｎが保持されており、各メディアコンポーネントの中にはそのコンポーネントがどのような種類のデータに適用されるべきコンポーネントであるかを判定するためのメディアタイプ判定関数４０−１〜Ｎが含まれている。また、メディアコンポーネントデータベース１０１には、メディアタイプ判定関数４０−１〜Ｎの各々への参照先アドレスを返す関数であるメディアコンポーネントメディアタイプ判定関数エントリ２０−１〜Ｎが保持されている。
【００２９】
　以上のように構成されたデータ処理装置１００について、図３、図４を用いてその動作を説明する。
【００３０】
　図３は、データ処理装置１００がマルチメディアファイルを再生する手順を示したフロー図である。
【００３１】
　データ処理装置１００のユーザからファイルの再生要求が操作入力部１０３に入力され、ファイル名と再生要求がメディア処理部１０５内のメディア制御部１０６に送られる（Ｓ１０１０）。
【００３２】
　メディア制御部１０６は、指定されたファイルを読み込むためのコンポーネント（ファイル読込コンポーネント）をメディア判定部１０２へ要求する（Ｓ１０２０）。
【００３３】
　メディア判定部１０２は、指定されたファイル名をもとにファイルを読み込むためのコンポーネント（ファイル読込コンポーネント）をメディアコンポーネントデータベース１０１より検索する（Ｓ１０３０）。
【００３４】
　この検索を行う際は、図４に示すフロー図に従った処理を行う。
【００３５】
　すなわち、まず、メディア判定部１０２は、メディアコンポーネントデータベース１０１よりメディアタイプ判定関数エントリ２０−１を読み込む（Ｓ２０１０）。なお、図４において、ｘの初期値は１であるものとする。次に、読み出したメディアタイプ判定関数エントリ２０−１からの参照先であるメディアコンポーネント３０−１のメディアタイプ判定関数４０−１と、ユーザが操作入力部１０３を介して指定したファイル名に対するファイル名とを用いて、このメディアコンポーネント３０−１が要求されたファイルの読み込みに適しているか否かが判定される（Ｓ２０２０）。
【００３６】
　メディアタイプ判定関数４０−１の判定の結果、メディアコンポーネント３０−１が、ユーザが指定したファイル名に対応するデータの処理コンポーネントとして適していなかった場合は、ｘの値を１だけ増加させ（Ｓ２０４０）、次のメディアタイプ判定関数エントリ２０−２を読み込む（Ｓ２０１０）。一方、処理コンポーネントとして適していた場合は、メディア判定部１０２は、メディアコンポーネントデータベース１０１よりメディアコンポーネント３０−１を読み出し、メディア制御部１０６へ返す（Ｓ２０３０）。
【００３７】
　メディア判定部１０２にてこのような処理を行うことによって、メディアコンポーネント全体を読み出すことなく、ユーザ指定のデータの処理コンポーネントとして適しているか否かの判定を行うことができ、メディアコンポーネントの検索の高速化を図ることができる。
【００３８】
　また、メディア判定のための方法が追加や変更された場合でも、コンポーネント内のメディアタイプ判定関数４０−１〜Ｎのみの変更で済み、データベース自体の再構築が不要となる。すなわち、例えば、新しいタイプのメディアデータを処理するコンポーネントが追加された場合、従来の技術ではコンテキスト保持部を再構築することが必要となるが、本願発明のデータ処理装置は、各コンポーネント本体は再構築する必要がなく、メディアタイプ判定関数４０−１〜Ｎのみを変更することによって、新しいタイプのメディアデータの処理が可能であるか否かを判別することが可能となる。
【００３９】
　図３のフロー図を参照して、メディア制御部１０６は、読み込んだファイル読込コンポーネント１０７を用い、ファイルシステム１０４よりファイルを読み込む（Ｓ１０４０）。
【００４０】
　メディア制御部１０６は、読み込んだファイルの情報から多重化情報を取得し、その逆多重化を行うためのコンポーネント（逆多重化コンポーネント１０８）をメディア判定部１０２へ要求する（Ｓ１０５０）。
【００４１】
　なお、多重化情報とは、ファイルシステム１０４に保持されているファイルに付加されている情報であって、そのファイルに多重化されている複数のデータタイプが記載されている情報である。以下、多重化情報について具体的に説明する。
【００４２】
　図５は、多重化されたファイルの状態を概念的に示した図である。多重化ファイル（ＭＰ４　Ｆｉｌｅ）には、大きく分けてファイルの書誌的な情報を記載している領域（Ｍｏｖｉｅ　Ａｔｏｍ）と、メディアの実体を格納している領域（Ｍｅｄｉａ　Ａｔｏｍ）とに分かれる。
【００４３】
　なお、“Ｍｏｖｉｅ　Ａｔｏｍ”領域の構造は、いわゆる入れ子構造となっており、“Ｍｏｖｉｅ　Ａｔｏｍ”領域の中は、さらに“Ｍｏｖｉｅ　Ｈｅａｄｅｒ　Ａｔｏｍ”と“Ｔｒａｃｋ　Ａｔｏｍ”といった複数の領域に区分けされて情報が保持されている。
【００４４】
　メディア制御部１０６は、上記“Ｍｏｖｉｅ　Ａｔｏｍ”の中からメディアタイプ判定関数４０−１〜Ｎの引数として必要な書誌的情報を、上記多重化ファイルの記載箇所を特定した情報として取得する。この情報を多重化情報と呼ぶ。
【００４５】
　図６は、メディア制御部１０６が取得する多重化情報の例を示したものである。図６において、例えば「メディアタイプ」は、多重化ファイル中の“Ｍｏｖｉｅ　Ａｔｏｍ”の中の“Ｔｒａｃｋ　Ａｔｏｍ”の中の“Ｍｅｄｉａ　Ａｔｏｍ”の中の“Ｈａｎｄｌｅｒ　Ｒｅｆｅｒｅｎｃｅ”に記載されていることを示している。
【００４６】
　なお、ここでは指定されたファイルが、メディアデータを多重化しているマルチメディアデータであることにするが、本発明は、このデータに限定されるものではない。
【００４７】
　再度、図３のフロー図を参照して、メディア判定部１０２は、メディア制御部１０６から入力された多重化情報をもとに、逆多重化を行うためのコンポーネント（逆多重化コンポーネント１０８）をメディアコンポーネントデータベース１０１から検索する（Ｓ１０６０）。ここでもＳ１０３０での処理と同様に図４の処理を行い、対象とするデータを逆多重化するのに適したコンポーネントを選択する。
【００４８】
　メディア制御部１０６は、読み込んだ逆多重化コンポーネント１０８を用い、ファイル読込コンポーネント１０７からマルチメディアデータを読み込み、逆多重化を行う（Ｓ１０７０）。
【００４９】
　メディア制御部１０６は、逆多重化されたメディアデータに付随するメディア情報（映像）を取得し、その映像を表示するためのコンポーネント（映像出力コンポーネント１０９）をメディア判定部１０２へ要求する（Ｓ１０８０）。
【００５０】
　ここでいうメディア情報は、具体的には例えば図７に示すような形式のものである。メディア情報には、図７に示すようにメディアタイプ、メディアサブタイプ等のアイテムとそれに対応する値や文字列とが記載されている。図７において、“Ｎｏｎｅ”は該当するアイテムについて記載がないことを示している。
【００５１】
　メディア判定部１０２は、メディア制御部１０６から入力されたメディア情報をもとに、映像を表示するためのコンポーネント（映像出力コンポーネント１０９）をメディアコンポーネントデータベース１０１から検索する（Ｓ１０９０）。ここでもＳ１０３０での処理と同様に図４の処理を行い、対象とするデータを映像出力するのに適したコンポーネントを選択する。
【００５２】
　この場合のメディアタイプ判定関数４０−１〜Ｎの動作を示すフロー図を図８に示す。
【００５３】
　まず、メディアタイプ判定関数４０−１〜Ｎは、上流のコンポーネントの出力から図７に示すメディア情報を取得する（Ｓ３０１０）。ここで、上流のコンポーネントとは、１つ前の処理が行われたコンポーネントを指す。したがって、ここでは、逆多重化コンポーネント１０８が上流のコンポーネントに該当する。処理は、メディアタイプ判定関数４０−１〜Ｎに対して適用され、適したコンポーネントが見つかるまで繰り返される。以下、メディアタイプ判定関数４０−１についての動作について説明する。
【００５４】
　メディアタイプ判定関数４０−１は、読み込んだメディア情報のアイテムと、予め保持しているテーブルとを比較し、各アイテムがメディアタイプ判定関数の保持するテーブルの範囲内にあるか否かを判定する（Ｓ３０２０）。
【００５５】
　図９は、メディアタイプ判定関数４０−１が保持しているテーブルの一例を示したものである。メディアタイプ判定関数４０−１は、各アイテムについて、順番に比較していくが、メディアタイプ判定関数４０−１の保持しているテーブルの値の範囲内に無い場合は、その時点で判定は“ＮＧ”となる（Ｓ３０５０）。逆に範囲内に入っている場合は、まだメディアタイプ判定関数４０−１が判定していないアイテムがあるか否かを判断する（Ｓ３０３０）。まだ全てのアイテムを判断していない場合は、Ｓ３０２０に戻る。全てのアイテムについて判定した場合は、判定は“ＯＫ”となる（Ｓ３０４０）。
【００５６】
　なお、図９中の幾つかのアイテムについては“ｕｎｓｐｅｃｉｆｉｅｄ”（不特定の任意の値で良い）となっているが、このようなアイテムについては比較する必要がないので、範囲内に入っているか否かの判定を行わないようにすることもできる。
【００５７】
　以上がメディアタイプ判定関数４０−１の動作である。同様の動作を各メディアタイプ判定関数４０−２〜Ｎが行うことにより、処理に適したコンポーネントを選択することができる。
【００５８】
　図３のフロー図を参照して、メディア制御部１０６は、読み込んだ映像出力コンポーネント１０９の出力先を映像表示部１１１へ接続する（Ｓ１１００）。
【００５９】
　そして、メディア制御部１０６は、逆多重化されたメディアデータのメディア情報（音声）を取得し、その音声を出力するためのコンポーネント（音声出力コンポーネント１１０）をメディア判定部１０２へ要求する（Ｓ１１１０）。
【００６０】
　メディア判定部１０２は、メディア制御部１０６から入力されたメディア情報をもとに、音声を出力するためのコンポーネント（音声出力コンポーネント１１０）をメディアコンポーネントデータベース１０１から検索する（Ｓ１１２０）。ここでもＳ１０３０での処理と同様に図４の処理を行い、対象とするデータを音声出力するのに適したコンポーネントを選択する。
【００６１】
　メディア制御部１０６は、読み込んだ音声出力コンポーネント１１０の出力先を音声出力部１１２へ接続する（Ｓ１１３０）。
【００６２】
　メディア制御部１０６は、各コンポーネントへ再生開始を要求する（Ｓ１１４０）。
【００６３】
　映像表示部１１１、音声出力部１１２において、映像、音声が出力される（Ｓ１１５０）。
【００６４】
　以上のように、メディアコンポーネントを検索する際、メディアタイプ関数４０−１〜Ｎを用いることによって、メディアコンポーネント全体を読み出すことなく、そのコンポーネントが処理に適しているか否かの判定を行うことができ、メディアコンポーネントの検索の高速化を図ることができる。
【００６５】
　また、メディアの判定のための方法が追加や変更された場合でも、コンポーネント内のメディアタイプ判定関数４０−１〜Ｎのみの変更で済み、データベース自体の再構築が不要となる。
【００６６】
　以上のように、本実施の形態によれば、コンポーネント内にコンポーネント本体とは別に、対象とするデータの処理に適するコンポーネントであるか否かを判定するタイプ判定関数を有し、データ処理装置には、読み込んだファイルまたは前段のコンポーネントにより処理され出力されたデータの情報を前記タイプ判定関数に適用する判定手段を備え、各コンポーネントと対応するタイプ判定を実施することで、判定のための属性が変更または追加となったとしても、タイプ判定関数のみを変更すれば足り、コンポーネント本体（従来のコンテキスト保持部全体に相当）を更新する必要はないため、効率的にデータベースを更新することが可能となる。
【００６７】
　また、メディアタイプ判定関数エントリを利用することによって、データベースよりコンポーネント全てを取得することなく、メディアタイプ判定関数エントリの参照先であるタイプ判定関数のみを読み込めばコンポーネントの評価を行うことができ、目的のコンポーネントを取得するまでの時間を短縮することができる。
【００６８】
　（実施の形態２）
　図１０は、本発明の実施の形態２におけるデータ処理装置２００の構成を示すブロック図である。なお、本実施の形態のデータ処理装置２００は、実施の形態１で説明したデータ処理装置と同様の基本的構成を有しており、同一の構成要素には同一の参照符号を付し、その詳細な説明を省略する。
【００６９】
　データ処理装置２００におけるデータ処理装置１００との相違点は、過去にこのデータ処理装置２００で組み立てたメディアコンポーネントの構成パターンを格納するためのコンポーネント構成データベース２０１と、ファイルシステム１０４から読み出されたデータに適用可能なメディアコンポーネントの構成パターンをコンポーネント構成データベース２０１から検索する構成パターン検索部２０２と、必要なメディアコンポーネントがデータ処理装置２００の内部に保持されていない場合に、ネットワーク２１０を介して接続されるメディアコンポーネントデータベースサーバ２２０から必要なメディアコンポーネントをダウンロードするダウンロード部２０３と、メディアコンポーネントの配置に成功した構成パターンをコンポーネント構成データベース２０１に登録する構成パターン登録部２０４と、が追加された点、並びに、メディア判定部１０２、操作入力部１０３及びメディア処理部１０５の代わりにメディア判定部２０５、入力部２０６及びメディア処理部２０７を有する点である。また、メディア処理部２０７は、メディア処理部１０５におけるメディア制御部１０６の代わりにメディア制御部２０８を有する。
【００７０】
　本実施の形態の主な特徴は、過去に組み立てたメディアコンポーネントの構成パターンをコンポーネント構成データベース２０１に格納しておき、処理対象のファイル（データ）の情報に基づいて、格納された構成パターンの中から処理に適した構成パターンを検索することである。
【００７１】
　図１１は、コンポーネント構成データベース２０１にて構成パターンを保持するための保持テーブルの一例を示す図である。
【００７２】
　この保持テーブルにおいて、「構成パターン」は、構成パターン名を示す。「判定関数」は、メディア情報に対応する構成パターンを検索するときに利用される判定関数を示す。「コンポーネント数」は、処理に必要なコンポーネント数を示す（この例では、５個）。「コンポーネントＩＤ」は、構成パターンに含まれる各コンポーネントの識別子を示し、各コンポーネントを一意に特定するために用いられる。「コンポーネント格納先」は、各コンポーネントの実体が、メディアコンポーネントデータベース１０１のどの位置（アドレス）に格納されているかを示す。「コンポーネント所在」は、そのコンポーネントの実体が格納されているメディアコンポーネントデータベースサーバ２２０のアドレスを示している。「コンポーネント接続数」は、各コンポーネント間を接続する配線の数を示している。「接続方法」は、各コンポーネントの接続方法を示している。例えば｛０、１｝は、構成パターン中の０番目のコンポーネント（図１１のコンポーネント構成例ではＩＤ［０］と記載）及び１番目のコンポーネント（図１１のコンポーネント構成例ではＩＤ［１］と記載）が接続されることを示している。
【００７３】
　以下、上記構成を有するデータ処理装置２００における動作について説明する。まず、メディアコンポーネントの構成パターンの登録について説明する。図１２は、構成パターンの登録動作手順を説明するためのフローチャートである。
【００７４】
　まず、メディア制御部２０８は、メディアコンポーネントの配置に成功したとき（つまり、読み込んだファイルを適切に処理することができたとき）、そのメディアコンポーネントの構成パターンを構成パターン登録部２０４に通知する（Ｓ４０００）。
【００７５】
　そして、構成パターン登録部２０４は、通知された構成パターンが既にコンポーネント構成データベース２０１に登録されているか否かを調べ（Ｓ４１００）、既に登録されている場合は何も行わず、登録されていない場合はその構成パターンを保持するための保持テーブルを作成し、コンポーネント構成データベース２０１に登録する（Ｓ４２００）。
【００７６】
　次いで、データ処理装置２００でのマルチメディアファイルの再生について説明する。図１３は、データ処理装置２００でのマルチメディアファイルの再生動作手順を説明するためのフローチャートである。
【００７７】
　まず、構成パターン検索部２０２は、今回の処理に適した構成パターンがコンポーネント構成データベース２０１に存在しているか否かを検索し（Ｓ５０００）、その構成パターンがコンポーネント構成データベース２０１に存在している場合は（Ｓ５１００：ＹＥＳ）ステップＳ５２００に進み、その構成パターンがコンポーネント構成データベース２０１に存在していない場合は（Ｓ５１００：ＮＯ）ステップＳ５３００に進む。
【００７８】
　ステップＳ５２００において、メディア判定部２０５は、構成パターンに含まれるメディアコンポーネントの実体をメディアコンポーネントデータベース１０１から読み出す。一方、ステップＳ５３００においては、メディア判定部２０５は、必要なコンポーネントの実体を上流側から順にメディアコンポーネントデータベース１０１から読み出す、すなわち、実施の形態１と同様の動作を行うこととなる。
【００７９】
　そして、メディア制御部２０８は、読み出されたメディアコンポーネントを接続する（Ｓ５４００）。
【００８０】
　ここで、上記のステップＳ５０００の詳細な動作について説明する。ここでは図１４及び図１５を参照し二つの動作例を挙げる。図１４に示す動作例では、入力部２０６が構成パターンを指定し（Ｓ５０１０）、構成パターン検索部２０２が、指定された構成パターンに対応する構成パターン（つまり指定された構成パターンと同一のもの）を検索する（Ｓ５０２０）。また、図１５に示す動作例では、メディアタイプ判定関数が上流のコンポーネントのメディア情報を取得し（Ｓ５０３０）、構成パターン検索部２０２が、取得されたメディア情報に対応する構成パターンを、コンポーネント構成データベース２０１の判定関数を利用して検索する（Ｓ５０４０）。図１５に示す動作は、例えば、図１４について説明した構成パターン指定がなかったときに行われる。
【００８１】
　上記のステップＳ５０１０での構成パターン指定方法の例としては、ユーザから入力部２０６への入力によりアプリケーションが起動されたときに、そのアプリケーションに対応する構成パターンを構成パターン検索部２０２に通知する方法が挙げられる。
【００８２】
　また、起動されるアプリケーションの例としては、カメラアプリが挙げられる。図１６は、カメラアプリ起動中の操作と、その操作に応じて映像表示部１１１に表示される画面との例を説明するための図である。
【００８３】
　まず、カメラアプリが起動されると、入力部２０６は、カメラアプリに適したメディアコンポーネントの構成パターンを構成パターン検索部２０２に通知する。そして、構成パターン検索部２０２が通知された構成パターンに対応する構成パターン（例えば、図１１の構成パターン「Camera_Record」）を検索する。そして、この構成パターンに含まれるメディアコンポーネントが入力部２０６によって読み出されメディア制御部２０８によって接続される。これにより、内蔵のカメラ（不図示）から入力される映像が映像表示部１１１に表示される。その後、記録開始／停止用のボタン２０６ａが押下されると、カメラからの映像の記録が開始される。さらに、ボタン２０６ａが再度押下されると、入力部２０６がこれを検出し、映像の記録が停止される。
【００８４】
　また、機能ボタン２０６ｃを押下すると、入力部２０６がこれを検出し、機能メニューが映像表示部１１１に表示され、例えば、色調切替、外部出力設定、画面サイズ変更及び記録形式変更等の設定機能を実行することが可能になる。例えば色調切替は、設定用のボタン２０６ｂの右側部を押下することにより映像の色調を明るくし、ボタン２０６ｂの左側部を押下することにより映像の色調を暗くする機能である。また、例えば画面サイズ変更は、ボタン２０６ｂの上側部を押下することにより画面サイズを拡大し、ボタン２０６ｂの下側部を押下することにより画面サイズを縮小する機能である。
【００８５】
　上記の各設定機能を実現するために、各設定機能に適したメディアコンポーネントの構成パターンが予め決められている。いずれかの設定機能の実行がユーザによって指示されたときは、指示された設定機能に対応する構成パターンの検索、当該構成パターンに含まれるメディアコンポーネントの読み出し及び読み出されたメディアコンポーネントの接続が行われ、指示された設定機能が実行される。そして、設定が完了したとき及び設定がキャンセルされたとき、機能メニューの表示が終了する。また、終了ボタン２０６ｄを押下すると、入力部２０６がこれを検出し、カメラアプリが終了する。
【００８６】
　次いで、図１３のステップＳ５２００の動作の詳細について説明する。図１７は、構成パターンに含まれるメディアコンポーネントを読み出す手順を説明するためのフローチャートである。
【００８７】
　まず、メディア判定部２０５は、該当する構成パターンの保持テーブルに記載されたコンポーネント格納先のアドレスを参照する（Ｓ６０００）。そして、コンポーネント格納先が“Ｎｏｎｅ”ではない（例えば、図１１のアドレス｛０ｘ０２００｝）場合（Ｓ６１００：ＮＯ）、メディアコンポーネントデータベース１０１内の上記アドレスからコンポーネントを読み出す（Ｓ６２００）。一方、コンポーネント格納先が“Ｎｏｎｅ”の場合（Ｓ６１００：ＹＥＳ）、メディア判定部２０５は、保持テーブルに記載されたコンポーネント所在（例えば、図１１のアドレス｛http://hogehoge.hoge/cam_cap｝）を参照してダウンロード部２０３に通知し、ダウンロード部２０３がネットワーク２１０を介して接続されるメディアコンポーネントデータベースサーバ２２０の上記コンポーネント所在から該当するメディアコンポーネントをダウンロードし、メディア判定部２０５がダウンロード部２０３からメディアコンポーネントを読み出す（Ｓ６３００）。
【００８８】
　なお、コンポーネント格納先を“Ｎｏｎｅ”にするか否かは、例えばメディアコンポーネントの利用頻度に応じて決定される。
【００８９】
　そして、読み出したメディアコンポーネントの数が、保持テーブルに記載されたコンポーネント数に達したか否かを判定し（Ｓ６４００）、コンポーネント数に達した場合は手順を終了し、コンポーネント数に達していない場合はステップＳ６０００に戻り上記の手順を繰り返す。
【００９０】
　図１８は、図１７のステップＳ６２００の動作、つまりメディアコンポーネントデータベース２０１からのメディアコンポーネント読み出しを詳細に示したフローチャートである。
【００９１】
　まず、保持テーブルに記載されたコンポーネント格納先に基づいて、メディアコンポーネントデータベース１０１から該当するメディアコンポーネントを読み出す（Ｓ６２１０）。そして、読み出しに成功した場合（Ｓ６２２０：ＹＥＳ）、処理を終了する。一方、読み出しに失敗した場合は（Ｓ６２２０：ＮＯ）、メディア判定部２０５は、ダウンロード部２０３にネットワーク２１０を介したメディアコンポーネントベータベースサーバ２２０から該当するメディアコンポーネントをダウンロードする（Ｓ６２３０）。
【００９２】
　図１９は、図１７のステップＳ６３００の動作、つまりダウンロード部２０３からのメディアコンポーネント読み出しを詳細に示したフローチャートである。
【００９３】
　まず、メディア判定部２０５は、ネットワーク２１０を介しメディアコンポーネントデータベースサーバ２２０からメディアコンポーネントをダウンロード部２０３にダウンロードし、ダウンロードされたメディアコンポーネントをダウンロード部２０３から読み出す（Ｓ６３１０）。そして、読み出しに成功した場合（Ｓ６３２０：ＹＥＳ）、メディア判定部２０５は、ダウンロードしたメディアコンポーネントをメディアコンポーネントデータベースに登録し（Ｓ６３３０）、構成パターン検索部２０２は、保持テーブルに記載されたコンポーネント格納先を更新する（Ｓ６３４０）。一方、読み出しに失敗した場合は（Ｓ６３２０：ＮＯ）、メディアコンポーネントの読み出しが行えない旨のエラー処理を行う（Ｓ６３５０）。
【００９４】
　このように、本実施の形態によれば、過去に成功した構成パターンをコンポーネント構成データベース２０１に格納しておき、当該構成パターンと同一の処理が必要になったときに当該構成パターンをコンポーネント構成データベース２０１から検索し、検索された構成パターンに含まれるメディアコンポーネントのみを読み出すため、目的のメディアコンポーネントを取得するまでの時間を従来より大幅に短縮することができる。
【００９５】
　また、データ処理装置２００の外部と接続可能なダウンロード部２０３を備えることで、ある処理を実現するために必要なメディアコンポーネントがデータ処理装置２００の内部に記憶されていないときに、外部のメディアコンポーネントデータベースサーバ２２０からネットワーク２１０を介して当該メディアコンポーネントをダウンロードするため、例えば新規のメディアコンポーネントを取得する必要がある場合でもメディアコンポーネントデータベースサーバ２２０から即座にダウンロードすることが可能になるだけでなく、例えば利用頻度の低いメディアコンポーネントをメディアコンポーネントデータベース１０１に格納しておく必要がなくなり、メディアコンポーネントデータベース１０１のメモリを効率的に使用することが可能になる。
【００９６】
　なお、本実施の形態では、ダウンロード部２０３は、メディアコンポーネントデータベースサーバ２２０からメディアコンポーネントを取得しているが、外部からのメディアコンポーネント取得の方法はこれに限定されない。例えば、コンポーネントを格納した記録媒体をデータ処理装置２００に直接接続することができる場合は、その記録媒体から必要なコンポーネントをダウンロードしても良い。
【００９７】
　また、本発明は上記の実施の形態に限定されず、様々な実施の形態を採ることが可能である。例えば、上記のデータ処理方法をコンピュータ上でソフトウェアとして実行しても良い。すなわち、上記の実施の形態で説明したデータ処理方法を実行するプログラムを予め例えばＲＯＭ（Read Only Memory）等の記録媒体に記録しておき、そのプログラムをＣＰＵ（Central Processor Unit）によって動作させるようにしても良い。
【産業上の利用可能性】
【００９８】
　本発明に係るデータ処理装置、データ処理方法及びデータ処理プログラムは、新規コンポーネントが追加された場合でもデータベースの再構築を不要にする効果を有し、ある機能を実現するために組み合わされたソフトウェア部品から構成されるコンポーネントを読み込んで処理を実行するのに有用である。
【図面の簡単な説明】
【００９９】
【図１】本発明の実施の形態１におけるデータ処理装置の構成を示すブロック図
【図２】本発明の実施の形態１におけるメディアコンポーネントデータベースの構成を示す図
【図３】本発明の実施の形態１におけるマルチメディアファイル再生手順を示すフロー図
【図４】本発明の実施の形態１におけるメディア判定部の処理手順を示すフロー図
【図５】本発明の実施の形態１における多重化ファイルの構成を示す図
【図６】本発明の実施の形態１における多重化情報の一例を示す図
【図７】本発明の実施の形態１におけるメディア情報の一例を示す図
【図８】本発明の実施の形態１におけるメディアタイプ判定関数の動作を示すフロー図
【図９】本発明の実施の形態１におけるメディアタイプ判定関数が保持するテーブルの一例を示す図
【図１０】本発明の実施の形態２におけるデータ処理装置の構成を示すブロック図
【図１１】本発明の実施の形態２における保持テーブルの一例を示す図
【図１２】本発明の実施の形態２における構成パターンの登録動作手順を説明するためのフロー図
【図１３】本発明の実施の形態２におけるマルチメディアファイル再生動作手順を説明するためのフロー図
【図１４】本発明の実施の形態２における構成パターン検索動作の第１の例を説明するためのフロー図
【図１５】本発明の実施の形態２における構成パターン検索動作の第２の例を説明するためのフロー図
【図１６】本発明の実施の形態２における表示画面の例を説明するための図
【図１７】本発明の実施の形態２における構成パターンに含まれるメディアコンポーネントの読み出し手順を説明するためのフロー図
【図１８】本発明の実施の形態２におけるメディアコンポーネントデータベースからのメディアコンポーネント読み出し動作を説明するためのフロー図
【図１９】本発明の実施の形態２におけるダウンロード部からのメディアコンポーネント読み出し動作を説明するためのフロー図
【図２０】従来のデータ処理装置の構成を示すブロック図
【図２１】従来のデータ処理装置における検索式の一例を示す図
【符号の説明】
【０１００】
　１００、２００　データ処理装置
　１０１　メディアコンポーネントデータベース
　１０２、２０５　メディア判定部
　１０３　操作入力部
　１０４　ファイルシステム
　１０５、２０７　メディア処理部
　１０６、２０８　メディア制御部
　１０７　ファイル読込コンポーネント
　１０８　逆多重化コンポーネント
　１０９　映像出力コンポーネント
　１１０　音声出力コンポーネント
　１１１　映像表示部
　１１２　音声出力部
　２０−１〜Ｎ　メディアタイプ判定関数エントリ
　３０−１〜Ｎ　メディアコンポーネント
　４０−１〜Ｎ　メディアタイプ判定関数
　２０１　コンポーネント構成データベース
　２０２　構成パターン検索部
　２０３　ダウンロード部
　２０４　構成パターン登録部
　２０６　入力部
　２０６ａ、２０６ｂ　ボタン
　２０６ｃ　機能ボタン
　２０６ｄ　終了ボタン
　２１０　ネットワーク
　２２０　メディアコンポーネントデータベースサーバ
【図１】
2004139563.tif 000003
【図２】
2004139563.tif 000004
【図３】
2004139563.tif 000005
【図４】
2004139563.tif 000006
【図５】
2004139563.tif 000007
【図６】
2004139563.tif 000008
【図７】
2004139563.tif 000009
【図８】
2004139563.tif 000010
【図９】
2004139563.tif 000011
【図１０】
2004139563.tif 000012
【図１１】
2004139563.tif 000013
【図１２】
2004139563.tif 000014
【図１３】
2004139563.tif 000015
【図１４】
2004139563.tif 000016
【図１５】
2004139563.tif 000017
【図１６】
2004139563.tif 000018
【図１７】
2004139563.tif 000019
【図１８】
2004139563.tif 000020
【図１９】
2004139563.tif 000021
【図２０】
2004139563.tif 000022
【図２１】
2004139563.tif 000023