JP5392602B2 - Ｍｘｆデータ検索装置、ｍｘｆデータの検索方法、及びｍｘｆデータ検索プログラム - Google Patents

Description

本発明は、ＭＸＦデータの検索装置、及びＭＸＦデータの検索方法に関する。

図１は、一般的なＭＸＦ（Ｍａｔｅｒｉａｌ ｅＸｃｈａｎｇｅ Ｆｏｒｍａｔ）データの構造を示す図である。図１を参照して、ＭＸＦデータは、Ｈｅａｄｅｒ Ｐａｒｔｉｔｉｏｎ、Ｂｏｄｙ Ｐａｒｔｉｔｉｏｎ、Ｆｏｏｔｅｒ Ｐａｒｔｉｔｉｏｎの３つのＰａｒｔｉｔｉｏｎから構成される。各Ｐａｒｔｉｔｉｏｎは、データ項目を有する。データ項目は、例えばＨｅａｄｅｒ Ｐａｒｔｉｔｉｏｎ Ｐａｃｋ、Ｈｅａｄｅｒ Ｍｅｔａｄａｔａ、Ｉｎｄｅｘ Ｔａｂｌｅ、Ｂｏｄｙ Ｐａｒｔｉｔｉｏｎ Ｐａｃｋ、Ｅｓｓｅｎｃｅ Ｃｏｎｔａｉｎｅｒ（Ｅｓｓｅｎｃｅ）、Ｆｏｏｔｅｒ Ｐａｒｔｉｔｉｏｎ Ｐａｃｋ、Ｒａｎｄｏｍ Ｉｎｄｅｘ Ｐａｃｋ等がある。又、Ｈｅａｄｅｒ Ｍｅｔａｄａｔａ、Ｉｎｄｅｘ Ｔａｂｌｅ、Ｅｓｓｅｎｃｅ Ｃｏｎｔａｉｎｅｒ、Ｒａｎｄｏｍ Ｉｎｄｅｘ ＰａｃｋはＯｐｔｉｏｎａｌとしてＭＸＦデータ内に任意に挿入できる。更に、Ｈｅａｄｅｒ Ｍｅｔａｄａｔａは、図２に示すようにＰｒｉｍｅｒ Ｐａｃｋというデータ項目と、Ｍｅｔａｄａｔａというデータ項目で構成される。

ＭＸＦデータを構成するデータパックは、それぞれＫＬＶ（Ｋｅｙ−Ｌｅｎｇｔｈ−Ｖａｌｕｅ）符号で符号化されたデータ群を有する。図３は、ＫＬＶ符号の構造を示す図である。図３を参照して、ＫＬＶ符号は、データ項目の識別子であるＫｅｙと、データ長を示すＬｅｎｇｔｈ、データ項目（データ本体）であるＶａｌｕｅを備える。Ｋｅｙは、ＳＭＰＴＥ３７７Ｍ、ＳＭＰＴＥ ３３５Ｍ／ＲＰ２１０に準拠した１６Ｂｙｔｅのデータである。Ｌｅｎｇｔｈは４Ｂｙｔｅで構成される。Ｖａｌｕｅは、Ｌｅｎｇｔｈで示されるデータ長のデータである。Ｖａｌｕｅには、ビデオ、オーディオデータに関するメタデータや、ディジタルビデオデータ、ディジタルオーディオデータが格納される。何を格納するかはＫｅｙによって決まる。又、図１に示すように、Ａｌｉｇｎｍｅｎｔと呼ばれるアライメント（位置補正）用のＫＬＶデータがＫＬＶデータ間に含まれても良い。

ＭＸＦデータを実行する際、Ｋｅｙを検出及び解析することで、Ｖａｌｕｅに含まれるデータの内容（データ項目）を特定することができる。例えば、特開２００４−３１０３３０には、編集装置内において、アプリケーションプログラムによる演算負荷を軽減するため、リードプログラムを実行する工程でデータの内容を特定する方法が記載されている。

特開２００４−３１０３３０

一方、ＭＸＦデータ内に存在するディジタルビデオデータ、ディジタルオーディオデータに高速にアクセスしなければ、規定時間内にそれらのデータを再生することは困難である。そのため、ＭＸＦデータ内の所望データ位置への高速、かつ効率的なアクセス、及び取得する手法が必要である。

ＭＸＦデータ内で定義されているＩｎｄｅｘ Ｔａｂｌｅには、ＭＸＦデータ内におけるＥｓｓｅｎｃｅの位置を表す情報が格納されている。このＩｎｄｅｘ Ｔａｂｌｅを使用して、ＭＸＦデータ内のＥｓｓｅｎｃｅに対し、効率的かつ高速にアクセスすることができる。しかし、ＭＸＦ規格では、Ｉｎｄｅｘ Ｔａｂｌｅを定義していないものも許されている。この場合、Ｉｎｄｅｘ Ｔａｂｌｅを使用できないため、ＭＸＦデータ内のＥｓｓｅｎｃｅに対して高速にアクセスすることができない。又、データの検索開始時は、検索対象ＭＸＦデータのインデックス情報は確保されていない。そのため、ＭＸＦデータの先頭から検索をするしかない。又、所望データへのアクセスするためには、Ｉｎｄｅｘ Ｔａｂｌｅが入力されるまで待機する必要があった。

以上のことから、本発明の目的は、ＭＸＦデータ内の所望データに対するアクセス速度を向上させることである。

又、本発明の他の目的は、Ｉｎｄｅｘ Ｔａｂｌｅを有しないＭＸＦデータ内の所望データを高速にアクセスすることにある。

上記の課題を解決するために、本発明は、以下に述べられる手段を採用する。その手段を構成する技術的事項の記述には、［特許請求の範囲］の記載と［発明を実施するための形態］の記載との対応関係を明らかにするために、［発明を実施するための形態］で使用される番号・符号が付加されている。ただし、付加された番号・符号は、［特許請求の範囲］に記載されている発明の技術的範囲を限定的に解釈するために用いてはならない。

本発明によるデータ検索装置（１０００）は、ＭＸＦ（Ｍａｔｅｒｉａｌ ｅＸｃｈａｎｇｅ Ｆｏｒｍａｔ）データ（１００）からＫｅｙを検出するＫｅｙ検出部（２１１）と、検出されたＫｅｙを用いて特定された所望データを、ＭＸＦデータ（１００）から抽出するデータ抽出部（２１４）とを具備する。

又、本発明によるＭＸＦデータの検索方法は、ＭＸＦデータ（１００）からＫｅｙを検出するステップと、検出されたＫｅｙを用いて特定された所望データを、ＭＸＦデータ（１００）から抽出するステップとを具備する。

本発明によればＫｅｙを用いてＭＸＦデータ（１００）内から所望データを特定しているため、Ｉｎｄｅｘ Ｔａｂｌｅを利用せずに所望データへのアクセスを行なうことができる。

又、本発明によるＭＸＦデータ（１００）の検索方法は、コンピュータによってプログラムを実行することで実現できる。

本発明によれば、ＭＸＦデータ内の所望データに対するアクセス速度が向上する。

又、Ｉｎｄｅｘ Ｔａｂｌｅを有しないＭＸＦデータ内の所望データを高速にアクセスすることができる。

図１は、ＭＸＦデータの構造を示す図である。 図２は、Ｈｅａｄｅｒ Ｍｅｔａｄａｔａの構造を示す図である。 図３は、ＫＬＶ符号の構造を示す図である。 図４は、本発明によるＭＸＦデータ再生装置の実施の形態における構成を示す図である。 図５は、本発明によるＭＸＦデータ検索プログラムの実施の形態における構成を示す機能ブロック図である。 図６は、状態遷移テーブルの一例を示す図である。 図７は、Ｋｅｙリストの一例を示す図である。 図８Ａは、本発明によるデータアクセス動作の一例を示すフロー図である。 図８Ｂは、本発明によるデータアクセス動作の一例を示すフロー図である。 図９は、実施例においてアクセス対象となるＭＸＦデータの構造を示す図である。

以下、添付図面を参照しながら本発明の実施の形態を説明する。図面において同一、又は類似の参照符号は、同一、類似、又は等価な構成要素を示している。本実施の形態では、ディジタルビデオデータ、ディジタルオーディオデータを内包するＭＸＦストリーミングデータから、特定のディジタルビデオデータ位置へアクセス（検索）するＭＸＦデータ再生装置を一例に説明する。

（概要）
本発明によるＭＸＦデータ再生装置（データ検索装置）１０００は、入力されたＭＸＦストリーミングデータ（以下、ＭＸＦデータと称す）を先頭から順に検索し、所望のデータにアクセスする。この際、本発明では、予め用意されたＫｅｙリスト及び状態遷移テーブルを利用して、検出されたＫｅｙが属している状態（Ｐａｒｔｉｔｉｏｎを示す情報やデータ項目を示す情報）を特定するとともに、指定されたＫｅｙの出現回数をカウントすることで、データ位置を特定する。このため、本発明では、Ｉｎｄｅｘ Ｔａｂｌｅを用いることなく、所望データにアクセスすることができる。又、本発明では、入力されたＭＸＦデータを先頭から順に（入力順に）検索し、指定されたデータ位置を検出しているため、Ｐａｒｔｉｔｉｏｎの後半部に挿入されたＩｎｄｅｘ Ｔａｂｌｅの入力を待つことなく指定されたデータにアクセスすることができる。

（構成）
図４から図７を参照して、本発明によるＭＸＦデータ再生装置１０００の構成を説明する。図４は、本発明によるＭＸＦデータ再生装置１０００の実施の形態における構成を示す図である。図５は、本発明によるＭＸＦデータ検索プログラム２１の実施の形態における構成を示す機能ブロック図である。図６は、状態遷移テーブル２２の一例を示す図である。図７は、Ｋｅｙリスト２３の一例を示す図である。

図４を参照して、本発明によるＭＸＦデータ再生装置１０００は、それぞれがバスを介して接続されたＣＰＵ１１０、ＲＡＭ１２０、記憶装置１３０、入力装置１４０、出力装置１５０、Ｉ／Ｏ装置１６０を具備する。記憶装置１３０はハードディスクやメモリ等に例示される外部記憶装置である。又、入力装置１４０は、キーボードやマウス等のユーザによって操作されることで、各種データをＣＰＵ１１０や記憶装置１３０に出力する。出力装置１５０は、モニタやプリンタに例示され、ＣＰＵ１１０から出力される半導体装置のレイアウト結果をユーザに対し視認可能に出力する。Ｉ／Ｏ装置１６０は、図示しない外部装置（例示：ビデオ再生装置）に接続するための入出力インタフェースである。

記憶装置１３０は、ＭＸＦデータ検索プログラム２１、状態遷移テーブル２２、Ｋｅｙリスト２３を格納している。又、ＭＸＦデータの検索処理（アクセス処理）の際に利用される状態情報２４、位置情報２５も記憶装置１３０に記録される。又、記憶装置１３０は、入力されたＭＸＦデータを格納しても良い。ＣＰＵ１１０は、入力装置１４０からの入力に応答して、記憶装置１３０内のＭＸＦデータ検索プログラム２１を実行し、ＭＸＦデータに対する所望データの検索処理（アクセス処理）行なう。この際、記憶装置１３０からの各種データやプログラムはＲＡＭ１２０に一時格納され、ＣＰＵ１１０は、ＲＡＭ１２０内のデータを用いて各種処理を実行する。

本発明によるＭＸＦデータ再生装置１０００は、指定位置のデータを検索する際、入力されたＭＸＦデータ内のＫｅｙを先頭から順（入力順）に検索し、当該Ｋｅｙが属する状態を特定する。このとき、ＭＸＦデータ再生装置１０００は、Ｋｅｙの属する状態が、設定されたＭＸＦ規格に適合しているか否かを、状態遷移テーブル２２を利用して判定する。状態は、データ項目を示す情報とＰａｒｔｉｔｉｏｎを示す情報とを含む。詳細には、状態には、Ｈｅａｄｅｒ Ｐａｒｔｉｔｉｏｎ、Ｂｏｄｙ Ｐａｒｔｉｔｉｏｎ、Ｆｏｏｔｅｒ Ｐａｒｔｉｔｉｏｎ、Ｐｒｉｍｅｒ（Ｈｅａｄｅｒ、Ｂｏｄｙ）、Ｅｓｓｅｎｃｅ Ｃｏｎｔａｉｎｅｒ（Ｈｅａｄｅｒ、Ｂｏｄｙ）、Ｉｎｄｅｘ Ｔａｂｌｅ（Ｈｅａｄｅｒ、Ｂｏｄｙ）、Ｐｒｉｍｅｒ（Ｆｏｏｔｅｒ）、Ｉｎｄｅｘ Ｔａｂｌｅ（Ｆｏｏｔｅｒ）、Ｒａｎｄｏｍ Ｉｎｄｅｘ Ｐａｃｋ、Ｍｅｔａｄａｔａ等がある。ただし（）内はＰａｒｔｉｔｉｏｎを示す。

ＭＸＦデータの構造は、ＭＸＦ規格に基づいているため、状態の並び順はＭＸＦ規格に従ったものとなる。このため、状態遷移テーブル２２は、ＭＸＦ規格に基づいて設定されている。

図６を参照して、状態遷移テーブル２２の一例を説明する。ここでは、図１に示すＭＸＦデータに適用されたＭＸＦ規格に従った状態遷移テーブル２２を一例に説明する。状態遷移テーブル２２は、初期状態０、ＭＸＦデータが内包し得る状態１〜状態１１、及び終了状態１２と、それぞれの遷移リンク（遷移先となる次の状態）とが対応付けられて格納される。すなわち、状態遷移テーブル２２には、ＭＸＦデータの先頭（検索処理が開始されるデータ）から最後尾（検索処理が終了する）までの状態の遷移が記録される。

以下、状態遷移テーブル２２に記録される状態０〜状態１２と、それぞれの遷移先として対応付けられる状態について説明する。

初期状態０．Ｓｔａｒｔ：検索処理を開始する時の状態を示す。ＭＸＦデータの先頭は必ずＨｅａｄｅｒ Ｐａｒｔｉｔｉｏｎであるため、Ｈｅａｄｅｒ Ｐａｒｔｉｔｉｏｎ（状態１）のみが次の遷移先として対応付けられる。

状態１．Ｈｅａｄｅｒ Ｐａｒｔｉｔｉｏｎ：Ｈｅａｄｅｒ Ｐａｒｔｉｔｉｏｎに属する状態であることを示す。Ｈｅａｄｅｒ Ｐａｒｔｉｔｉｏｎには必ずＭｅｔａｄａｔａを付与する必要があるため、Ｐｒｉｍｅｒ（Ｈｅａｄｅｒ、Ｂｏｄｙ）（状態２）のみが遷移先として対応付けられる。

状態２．Ｐｒｉｍｅｒ（Ｈｅａｄｅｒ、Ｂｏｄｙ）：Ｐｒｉｍｅｒ Ｐａｃｋ（Ｈｅａｄｅｒ、Ｂｏｄｙ）に属する状態であることを示す。Ｐｒｉｍｅｒ Ｐａｃｋ（Ｈｅａｄｅｒ、Ｂｏｄｙ）の後は、ＭＸＦ規格上、必ずＭｅｔａｄａｔａ（Ｈｅａｄｅｒ、Ｂｏｄｙ）が後続する。そのため、Ｍｅｔａｄａｔａ（Ｈｅａｄｅｒ、Ｂｏｄｙ）（状態３）のみが遷移先として対応付けられる。

状態３．Ｍｅｔａｄａｔａ（Ｈｅａｄｅｒ、Ｂｏｄｙ）：Ｍｅｔａｄａｔａ（Ｈｅａｄｅｒ、Ｂｏｄｙ）に属する状態であることを示す。Ｍｅｔａｄａｔａ（Ｈｅａｄｅｒ、Ｂｏｄｙ）は繰り返されることがあるため、Ｍｅｔａｄａｔａ（Ｈｅａｄｅｒ、Ｂｏｄｙ）が遷移先となる。又、Ｍｅｔａｄａｔａ（Ｈｅａｄｅｒ、Ｂｏｄｙ）が終了すると、Ｂｏｄｙ Ｐａｒｔｉｔｉｏｎ、Ｉｎｄｅｘ Ｔａｂｌｅ、Ｅｓｓｅｎｃｅ Ｃｏｎｔａｉｎｅｒ、Ｆｏｏｔｅｒ Ｐａｒｔｉｔｉｏｎに遷移する可能性がある。このため、Ｍｅｔａｄａｔａ（Ｈｅａｄｅｒ、Ｂｏｄｙ）（状態３）、Ｂｏｄｙ Ｐａｒｔｉｔｉｏｎ（状態４）、Ｉｎｄｅｘ Ｔａｂｌｅ（Ｈｅａｄｅｒ、 Ｂｏｄｙ）（状態５）、Ｅｓｓｅｎｃｅ Ｃｏｎｔａｉｎｅｒ（状態６）、Ｆｏｏｔｅｒ Ｐａｒｔｉｔｉｏｎ（状態７）が遷移先として対応付けられる。

状態４．Ｂｏｄｙ Ｐａｒｔｉｔｉｏｎ：Ｂｏｄｙ Ｐａｒｔｉｔｉｏｎに属する状態であることを示す。Ｂｏｄｙ Ｐａｒｔｉｔｉｏｎの後には、Ｍｅｔａｄａｔａ情報を記載する可能性があるため、Ｐｒｉｍｅｒ（Ｈｅａｄｅｒ、Ｂｏｄｙ）が遷移先となる可能性がある。又、Ｉｎｄｅｘ Ｔａｂｌｅ、Ｅｓｓｅｎｃｅ、Ｃｏｎｔａｉｎｅｒ、Ｆｏｏｔｅｒ Ｐａｒｔｉｔｉｏｎに遷移する可能性もある。このため、Ｐｒｉｍｅｒ（Ｈｅａｄｅｒ、Ｂｏｄｙ）（状態２）、Ｉｎｄｅｘ Ｔａｂｌｅ（Ｈｅａｄｅｒ、Ｂｏｄｙ）（状態５）、Ｅｓｓｅｎｃｅ、Ｃｏｎｔａｉｎｅｒ（状態６）、Ｆｏｏｔｅｒ Ｐａｒｔｉｔｉｏｎ（状態７）が遷移先として対応付けられる

状態５．Ｉｎｄｅｘ Ｔａｂｌｅ（Ｈｅａｄｅｒ、Ｂｏｄｙ）：Ｉｎｄｅｘ Ｔａｂｌｅ（Ｈｅａｄｅｒ、Ｂｏｄｙ）に属する状態であることを示す。Ｉｎｄｅｘ Ｔａｂｌｅ（Ｈｅａｄｅｒ、Ｂｏｄｙ）は繰り返される可能性があるため、Ｉｎｄｅｘ Ｔａｂｌｅ（Ｈｅａｄｅｒ、Ｂｏｄｙ）が遷移先となる。又、Ｅｓｓｅｎｃｅ Ｃｏｎｔａｉｎｅｒ（Ｈｅａｄｅｒ、Ｂｏｄｙ）、Ｆｏｏｔｅｒ Ｐａｒｔｉｔｉｏｎに遷移先する可能性がある。このため、Ｉｎｄｅｘ Ｔａｂｌｅ（Ｈｅａｄｅｒ、Ｂｏｄｙ）（状態５）、Ｅｓｓｅｎｃｅ Ｃｏｎｔａｉｎｅｒ（Ｈｅａｄｅｒ、Ｂｏｄｙ）（状態６）、Ｆｏｏｔｅｒ Ｐａｒｔｉｔｉｏｎ（状態７）が遷移先として対応付けられる。

状態６．Ｅｓｓｅｎｃｅ Ｃｏｎｔａｉｎｅｒ：Ｅｓｓｅｎｃｅ Ｃｏｎｔａｉｎｅｒに属する状態であることを示す。Ｅｓｓｅｎｃｅ Ｃｏｎｔａｉｎｅｒは連続する可能性があるため、Ｅｓｓｅｎｃｅ Ｃｏｎｔａｉｎｅｒが遷移先となる。又、Ｂｏｄｙ Ｐａｒｔｉｔｉｏｎ、Ｆｏｏｔｅｒ Ｐａｒｔｉｔｉｏｎに遷移する可能性がある。このため、Ｅｓｓｅｎｃｅ Ｃｏｎｔａｉｎｅｒ（Ｈｅａｄｅｒ、Ｂｏｄｙ）（状態６）、Ｂｏｄｙ Ｐａｒｔｉｔｉｏｎ（状態４）、Ｆｏｏｔｅｒ Ｐａｒｔｉｔｉｏｎ（状態７）が遷移先として対応付けられる。

状態７．Ｆｏｏｔｅｒ Ｐａｒｔｉｔｉｏｎ：Ｆｏｏｔｅｒ Ｐａｒｔｉｔｉｏｎに属する状態であることを示す。Ｆｏｏｔｅｒ ＰａｒｔｉｔｉｏｎはＭＸＦデータの最終Ｐａｒｔｉｔｉｏｎであり、そのままデータの最後となる可能性がある。又、メタデータが定義される可能性もあるため、Ｐｒｉｍｅｒに遷移する可能性がある。更にＩｎｄｅｘ Ｔａｂｌｅに遷移する可能性もある。このため、Ｅｎｄ ｏｆ Ｓｔｒｅａｍ（状態１２）、Ｐｒｉｍｅｒ（Ｆｏｏｔｅｒ）（状態８）、Ｉｎｄｅｘ Ｔａｂｌｅ（Ｆｏｏｔｅｒ）（状態１０）が遷移先として対応付けられる。

状態８．Ｐｒｉｍｅｒ（Ｆｏｏｔｅｒ）：Ｐｒｉｍｅｒ（Ｆｏｏｔｅｒ）に属する状態であることを示す。Ｆｏｏｔｅｒ Ｐａｒｔｉｔｉｏｎ後のＰｒｉｍｅｒとして定義され、Ｆｏｏｔｅｒ Ｐａｒｔｉｔｉｏｎ後のＭｅｔａｄａｔａ（Ｆｏｏｔｅｒ）に遷移する可能性がある。このため、Ｍｅｔａｄａｔａ（Ｆｏｏｔｅｒ）（状態９）が遷移先として対応付けられる。

状態９．Ｍｅｔａｄａｔａ（Ｆｏｏｔｅｒ）：Ｍｅｔａｄａｔａ（Ｆｏｏｔｅｒ）に属する状態であることを示す。Ｍｅｔａｄａｔａ（Ｈｅａｄｅｒ、ｂｏｄｙ）（状態３）とは異なり、そのままデータの終わりとなる可能性や、Ｒａｎｄｏｍ Ｉｎｄｅｘ Ｐａｃｋに遷移する可能性がある。このため、Ｅｎｄ ｏｆ Ｓｔｒｅａｍ（状態１２）、Ｒａｎｄｏｍ Ｉｎｄｅｘ Ｐａｃｋ（状態１１）が遷移先として対応付けられる。ここで、Ｍｅｔａｄａｔａ（Ｆｏｏｔｅｒ）に属するＫｅｙは、Ｍｅｔａｄａｔａ（Ｈｅａｄｅｒ、ｂｏｄｙ）（状態３）と同じであるが、遷移先が異なるため、状態３と異なる状態９として設定される。

状態１０．Ｉｎｄｅｘ Ｔａｂｌｅ（Ｆｏｏｔｅｒ）：Ｉｎｄｅｘ Ｔａｂｌｅ（Ｆｏｏｔｅｒ）に属する状態であることを示す。Ｉｎｄｅｘ Ｔａｂｌｅ（Ｆｏｏｔｅｒ）は連続する可能性があるため、Ｉｎｄｅｘ Ｔａｂｌｅ（Ｆｏｏｔｅｒ）が遷移先となる。又、Ｉｎｄｅｘ Ｔａｂｌｅ（Ｈｅａｄｅｒ、Ｂｏｄｙ）（状態５）とは異なり、そのままデータの終わりとなる可能性や、Ｒａｎｄｏｍ Ｉｎｄｅｘ Ｐａｃｋに遷移する可能性がある。このため、Ｉｎｄｅｘ Ｔａｂｌｅ（Ｆｏｏｔｅｒ）（状態１０）、Ｅｎｄ ｏｆ Ｓｔｒｅａｍ（状態１２）、Ｒａｎｄｏｍ Ｉｎｄｅｘ Ｐａｃｋ（状態１１）が遷移先として対応付けられる。ここで、Ｉｎｄｅｘ Ｔａｂｌｅ（Ｆｏｏｔｅｒ）（状態１０）に属するＫｅｙは、Ｉｎｄｅｘ Ｔａｂｌｅ（Ｈｅａｄｅｒ、 ｂｏｄｙ）（状態５）と同じであるが、遷移先が異なるため、状態５と異なる状態１０として設定される。

状態１１．Ｒａｎｄｏｍ Ｉｎｄｅｘ Ｐａｃｋ：Ｒａｎｄｏｍ Ｉｎｄｅｘ Ｐａｃｋに属する状態を示す。ＭＸＦデータの最後のＫＬＶデータになる可能性があり、この後は必ずデータが終了する。このため、Ｅｎｄ ｏｆ Ｓｔｒｅａｍ（状態１２）が遷移先として対応付けられる。

状態１２．Ｅｎｄ Ｏｆ Ｓｔｒｅａｍ：ＭＸＦデータの終了を示す。従って遷移先として対応付けられる状態はない。

以上のような状態遷移テーブル２２を用いることで、現在の状態の次に検索されるＫｅｙが属する状態を予測することができる。検索されたＫｅｙが属する状態と、予測された（遷移先の）状態とを照合することで、入力されたＭＸＦデータが設定されたＭＸＦ規格に適合しているか否かを判定することができる。又、当該Ｋｅｙのデータ位置を確認することができる。

又、本発明によるＭＸＦデータ再生装置１０００は、Ｋｅｙリスト２３と検出されたＫｅｙとを照合することで、検出されたＫｅｙが属する状態を特定する。図７に示すように、Ｋｅｙリスト２３として、Ｋｅｙを示すデータコード、Ｋｅｙが属する状態、及びＫｅｙで特定されるデータの意味（データ内容）が対応付けられて記憶装置１３０に格納される。例えば、Ｋｅｙ“０ｘ０６、０ｘ０Ｅ、０ｘ２Ｂ、０ｘ３４、０ｘ０１、０ｘ０２、０ｘ０１、０ｘ０１、０ｘ０Ｄ、０ｘ０１、０ｘ０３、０ｘ０１、０ｘ１５、０ｘ０１、０ｘ０５、０ｘ００”の属する状態は“Ｅｓｓｅｎｃｅ Ｃｏｎｔａｉｎｅｒ”であり、画像データを意味する。

ＣＰＵ１１０は、ＭＸＦデータ検索プログラム２１を実行することで、図５に示す検索処理部２１０としての機能を実現する。検索処理部２１０は、Ｋｅｙ検出部２１１、Ｋｅｙ回数判定部２１２、状態遷移部２１３、データ抽出部２１４の各機能を備える。図５を参照して、検索処理部２１０について説明する。

検索処理部２１０には、検索対象のＭＸＦデータ１００、検索対象のＫｅｙを示す検索Ｋｅｙ情報１０１、検索対象のＫｅｙの出現する順番を示す検索Ｋｅｙ回数１０２が入力される。この入力方法については、特に限定はしない。つまり、ハードディスクのような二次記憶装置からのデータを入力としてもよいし、図示しない外部装置（Ｉ／Ｏ装置１６０）からの入力でもよいし、ユーザ（入力装置１４０）からの入力でもよい。

入力データを基に、検索処理部２１０はＭＸＦデータ１００内の検索処理を行う。この検索処理は、記憶装置１３０に予め格納された状態遷移テーブル２２とＫｅｙリスト２３を用いて行なわれる。検索処理によって抽出されたデータ（Ｖａｌｕｅ２００）や当該データのＭＸＦデータ１００における位置は、出力装置１５０によって視認可能に出力される。あるいは、検索対象のデータ（Ｖａｌｕｅ２００）が見つからなかった場合、見つからなかったことを通知するエラー情報が出力装置１５０によって出力される。

Ｋｅｙ検出部２１１は、入力されたＭＸＦデータ１００を検索してＫｅｙを検出する。又、Ｋｅｙ検出部２１１は、状態遷移テーブル２２と状態情報２４とを用いて検出したＫｅｙの属する状態を特定し、当該状態がＭＸＦ規格に適合するかを判定する。

詳細には、Ｋｅｙ検出部２１１は、ＭＸＦデータ１００を先頭から順に（入力順に）検索して、Ｋｅｙを検出する。この際、Ｋｅｙ検出部２１１は、位置情報２５で示されるデータ位置からＫｅｙを取得する。そして、Ｋｅｙ検出部２１１は、Ｋｅｙリスト２３を参照して、検出したＫｅｙの属する状態を特定する。一方、Ｋｅｙ検出部２１１は、状態遷移テーブル２２及び状態情報２４を用いて予測された遷移先の状態と、検出されたＫｅｙの属する状態とを照会することでＭＸＦデータ１００がＭＸＦ規格に適合しているか否かを判定する。ここで、状態情報２４とは検出済みの最新のＫｅｙの属する状態を示す情報である。すなわち、状態情報２４によって、状態遷移テーブル２２上において現在属している状態が特定される。Ｋｅｙ検出部２１１は、現在属している状態の遷移先となる状態の候補を状態遷移テーブル２２を参照して特定し、この候補と、検出したＫｅｙの属する状態とを比較することで、規格に適合しているか否かを判定する。Ｋｅｙ検出部２１１は、検出したＫｅｙが規格に適合している場合、当該Ｋｅｙを特定する情報（例えばＫｅｙのコードやＫｅｙが属する状態）をＫｅｙ情報１０３として、Ｋｅｙ回数判定部２１２及び状態遷移部２１３に出力する。

又、Ｋｅｙ検出部２１１は、検出したＫｅｙが規格に適合している場合、Ｋｅｙの次に入力されるＬｅｎｇｔｈを抽出することでＶａｌｕｅのデータ長１０４を取得する。データ長１０４は、状態遷移部２１３及びデータ抽出部２１４に出力される。

Ｋｅｙ回数判定部２１２は、所望のＫｅｙ（検索対象のＫｅｙ）を検出した回数をカウントし、当該回数が所望の回数に至ったかどうかを判定する。詳細には、Ｋｅｙ回数判定部２１２には、検索Ｋｅｙ情報１０１と検索Ｋｅｙ回数１０２が入力される。検索Ｋｅｙ情報１０１には、検索対象のＫｅｙを特定する情報（例えばＫｅｙのコード）が含まれる。Ｋｅｙ回数判定部２１２は、検索Ｋｅｙ情報１０１とＫｅｙ情報１０３とが一致する回数をカウントする。これにより、検出対象のＫｅｙの検出回数がカウントされる。Ｋｅｙ回数判定部２１２は、カウント数が検索Ｋｅｙ回数１０２に一致するか否かを判定し判定結果１０５をデータ抽出部２１４及び状態遷移部２１３に出力する。カウント値は、初期値として０が設定される。Ｋｅｙ回数判定部２１２は、カウント数、すなわち検出対象のＫｅｙの検出回数が検索Ｋｅｙ回数１０２と一致する場合、データの抽出を行なうための判定結果１０５を出力する。Ｋｅｙ回数判定部２１２により、検索Ｋｅｙ情報１０１及び検索Ｋｅｙ回数１０２によって指定された検索対象のデータ位置までＫｅｙを検索することができる。

状態遷移部２１３は、検出されたＫｅｙに応じて現在の状態を状態情報２４に設定する。状態情報２４は、初期状態としてＳｔａｒｔに設定されている。状態遷移部２１３は、判定結果１０５を参照し、所望のＫｅｙを検出した回数が所望の回数に達していない場合、Ｋｅｙ情報１０３に応じた状態に状態情報２４を更新する。状態情報２４には、状態遷移テーブル２２上において検出された最新のＫｅｙが属している状態が設定される。又、遷移先の状態や検索対象のＫｅｙは、Ｈｅａｄｅｒ、Ｂｏｄｙ、Ｆｏｏｔｅｒ Ｐａｒｔｉｔｉｏｎのうち、どのＰａｒｔｉｔｉｏｎの状態かによって異なるものとなる。このため、状態情報２４には、Ｋｅｙが属する状態のみならず、Ｋｅｙが属するＰａｒｔｉｔｉｏｎ（Ｈｅａｄｅｒ、Ｂｏｄｙ、Ｆｏｏｔｅｒ）も含めて設定される。すなわち状態情報２４には、Ｈｅａｄｅｒ、Ｂｏｄｙ、Ｆｏｏｔｅｒいずれかを識別する情報が格納されている。ここで、Ｈｅａｄｅｒ、Ｂｏｄｙ、Ｆｏｏｔｅｒいずれかを識別する情報の初期値はＨｅａｄｅｒに設定される。

状態遷移部２１３は、Ｋｅｙ検出部２１１においてＫｅｙを検索するデータ位置を示す位置情報２５を設定、更新する。ここで、位置情報２５は、初期値として０が設定される。状態遷移部２１３は、状態情報２４を更新する際、Ｋｅｙ検出部２１１で検出されたデータ長１０４分だけデータをスキップしてＫｅｙの検出位置を変更し、位置情報２５を更新する。

データ抽出部２１４は、Ｋｅｙ回数判定部２１２における判定結果１０５に基づいて、Ｋｅｙが検出された位置からデータ長１０４分のデータ（Ｖａｌｕｅ２００）を抽出して出力する。この際、データ抽出部２１４は、Ｋｅｙが検出された位置（検出位置２５）を検出位置情報２０１として出力する。Ｖａｌｕｅ２００や検出位置情報２０１は、出力装置１５０又は記憶装置１３０に出力される。

（動作）
次に、図８Ａ及び図８Ｂを参照して、本発明によるデータ検索処理（アクセス処理）の動作の詳細を説明する。図８Ａ及び図８Ｂは、本発明によるデータ検索処理の動作を示すフロー図である。

先ず、データの検索処理を開始する前に、検索対象となるＫｅｙ（の位置）を指定する検索Ｋｅｙ情報１０１及び検索Ｋｅｙ回数１０２が入力される。

Ｋｅｙ検出部２１１は、ＭＸＦデータ１００における位置情報２５に応じた読み込み位置から、Ｋｅｙ分のデータサイズである１６Ｂｙｔｅを取得する（ステップＳ１）。これにより位置情報２５で指定されたデータ位置からＫｅｙが検出される。ここで、位置情報２５の初期値は０であるため、Ｋｅｙ検出部２１１は、ＭＸＦデータ１００の先頭データから順に（入力順に）Ｋｅｙを検出することとなる。

Ｋｅｙ検出部２１１は、状態遷移テーブル２２とＫｅｙリスト２３を参照して、検出したＫｅｙが、現在特定されている状態の遷移先の状態に属する候補Ｋｅｙに一致するかを判定する（ステップＳ２）。検出されたＫｅｙが候補Ｋｅｙのいずれにも一致しない場合、所望のデータが見つからなかった、もしくはＭＸＦデータ１００がＭＸＦ規格に適合した構造ではないとして、検索処理部２１０は、エラーを出力し処理を終了する（ステップＳ２Ｎｏ、Ｓ３）。

ステップＳ２において、検索されたＫｅｙが候補Ｋｅｙに一致する場合、すなわち、検索されたＫｅｙが遷移先の状態に属する場合、Ｋｅｙ検出部２１１は、検索されたＫｅｙに後続する４Ｂｙｔｅを取得しＬｅｎｇｔｈを抽出する（ステップＳ２Ｙｅｓ、Ｓ４）。これにより後続するＶａｌｕｅのデータ長１０４が抽出される。

次に、Ｋｅｙ回数判定部２１２は、検索されたＫｅｙが所望のＫｅｙであるか否かを判定する（ステップＳ５）。ここでは、検出されたＫｅｙが、入力された検索Ｋｅｙ情報１０１の示すＫｅｙに一致するかが判定される。検索されたＫｅｙが所望のＫｅｙと一致する場合、カウンタ値に１が加算されテップＳ７に移行する（ステップＳ５Ｙｅｓ、Ｓ６）。一方、検索されたＫｅｙが所望のＫｅｙと異なる場合、カウントアップすることなくステップＳ７に移行する（ステップＳ５Ｎｏ）。

Ｋｅｙ回数判定部２１２は、カウンタ値が所望の回数（検索Ｋｅｙ回数１０２）に達したかどうかを判定する（ステップＳ７）。

カウンタ値が検索Ｋｅｙ回数１０２に達していない場合、状態遷移部２１３は、ステップＳ４で取得したデータ長１０４分のデータをスキップし、データ位置（位置情報２５）に１６＋４＋データ長１０４を加算する（ステップＳ８、Ｓ９）。これにより、現在のＫｅｙの検出位置から１６（Ｋｅｙ分）＋４（Ｌｅｎｇｔｈ分）＋Ｌ（Ｖａｌｕｅ分）だけスキップされた位置が、次回のＫｅｙ検出位置となる。

状態遷移部２１３は、検出されたＫｅｙが属する状態に現在の状態を遷移する（ステップＳ１０）。ここでは、検出されたＫｅｙが属する状態、Ｐａｒｔｉｔｉｏｎに状態情報２４が更新される。状態遷移部２１３は、検出されたＫｅｙの属する状態及びＰａｒｔｉｔｉｏｎを、状態遷移テーブル２２及びＫｅｙリスト２３を参照して特定する。この際、状態遷移部２１３は、検出されたＫｅｙがＨｅａｄｅｒ Ｐａｒｔｉｔｉｏｎ、Ｂｏｄｙ Ｐａｒｔｉｔｉｏｎ、Ｆｏｏｔｅｒ Ｐａｒｔｉｔｉｏｎのいずれかに属するかを確認し、特定したＰａｒｔｉｔｉｏｎを現在のＰａｒｔｉｔｉｏｎとして状態情報２４を更新する（ステップＳ１１〜Ｓ１６）。

状態情報２４が更新され、引き続きＭＸＦデータ１００が入力されると、ステップＳ１に移行し、再度Ｋｅｙの検出が行なわれる（ステップＳ１７Ｎｏ）。この際、ステップＳ９で設定された検出位置におけるＫｅｙが検出される。以降、ステップＳ７においてカウンタ値が検索Ｋｅｙ回数１０２に達するまで、あるいは、ＭＸＦデータ１００の入力が終了する（状態がＥｎｄ Ｏｆ Ｓｔｒｅａｍに達する）まで、上述の動作が繰り返される。

ステップＳ７において、カウンタ値が、検索Ｋｅｙ回数１０２に一致する場合、すなわち所望するＫｅｙの出現回数が所望回数に達した場合、データ抽出部２１４は、位置情報２５にＫｅｙ（１６Ｂｙｔｅ）とＬｅｎｇｔｈ（４Ｂｙｔｅ）分を加算する（ステップＳ１８）。すなわち、データ位置をＶａｌｕｅの先頭とする。そして、その位置から抽出されたデータ長１０４分のデータ（Ｖａｌｕｅ２００）を抽出して出力する（ステップＳ１９）。この際、Ｖａｌｕｅ２００を抽出したデータ位置（位置情報２５）を検出位置情報２０１として出力しても良い。

以上のように、本発明によれば、入力されたＭＸＦデータ１００を入力順に検索して所望の位置のＫｅｙを抽出することで、検索対象となるデータ（Ｖａｌｕｅ２００）やデータ位置（検出位置情報２０１）を出力することができる。

又、本発明では、検出されたＫｅｙの属する状態がＭＸＦ規格に適合するか否かを、状態遷移テーブル２２を用いて判定している。このため、所望のデータを検索するのと同時に、入力データが正しいＭＸＦデータであるかどうかを確認することができる。

更に、本発明では、Ｋｅｙを利用してアクセス処理が行なわれるため、Ｉｎｄｅｘ Ｔａｂｌｅを持たないフォーマットのＭＸＦデータに対しても、所望のデータにアクセスすることができる。又、入力順に所望のデータか否かを判定できるため、Ｉｎｄｅｘ Ｔａｂｌｅの入力を待たずに、効率的かつ高速に所望データにアクセスすることができる。これにより、例えば、ＭＸＦデータのストリーミング中（受信中）でも、所望のデータにアクセスすることが可能となる。

ＭＸＦデータにはＥｓｓｅｎｃｅだけではなく、素材の長さやタイトル等が記述されたメタデータ情報という重要なデータも格納されている。このメタデータ情報の位置を示す情報は、ＭＸＦデータ内には定義されていないため、効率的な検索方法は確立されていない。このようなデータを検索する場合、本発明のようにＫｅｙを用いることは有効である。一方、各状態に属するＫｅｙとしては、規格上、図７に示すＫｅｙリスト２３のように分類される。Ｋｅｙの種類は、Ｐａｒｔｉｔｉｏｎが異なっていても同じものとなる。例えば、ＭｅｔａｄａｔａにはＭｅｔａｄａｔａ（Ｈｅａｄｅｒ、Ｂｏｄｙ）とＭｅｔａｄａｔａ（Ｆｏｏｔｅｒ）が存在するが、属するＫｅｙは、どのＰａｒｔｉｔｉｏｎのＭｅｔａｄａｔａでも同じＫｅｙが対応づけられている。このため、データ項目によっては、Ｋｅｙのみによって、所望のデータの位置を特定することはできない。しかし、本発明では、所望のＫｅｙの属する状態（Ｐａｒｔｉｔｉｏｎを含む）を用いているため、Ｐａｒｔｉｔｉｏｎが異なるデータをも区別して特定することができる。このため、Ｍｅｔａｄａｔａを含む全てのデータ項目に対しても効率的に検索（アクセス）することができる。

又、予め用意された状態遷移テーブル２２によって遷移先となる状態の候補を絞りこんでいるため、Ｋｅｙの属する状態の特定が容易となる。ＭＸＦデータにおけるＫｅｙが属する状態の数は、数多く存在するため、本発明のように、状態遷移テーブル２２を用意してＫｅｙの特定を行なうことは、検索処理の負荷量や処理時間の面で有効である。

（実施例）
次に、本発明によるデータ検索処理の具体例を説明する。以下では、図９に示すフォーマットのＭＸＦデータ１００から３０１フレーム目に出現するデジタルビデオデータへの検索（アクセス）処理を一例に説明する。図９に示すＭＸＦデータ１００は、Ｉｎｄｅｘ Ｔａｂｌｅの存在しないＭＸＦストリーミングデータである。ここで、図９に示される各ブロックの１６という値はＫｅｙのデータ長を示し、４という値はＬｅｎｇｔｈのデータ長を示す。又、Ｌ１、Ｌ２、Ｌ３．…は各Ｖａｌｕｅのデータ長を示す。

ここで、検索処理部２１０には、検索Ｋｅｙ情報１０１として、ビデオデータをデータ項目とするＫｅｙ“０ｘ０６、０ｘ０Ｅ、０ｘ２Ｂ、０ｘ３４、０ｘ０１、０ｘ０２、０ｘ０１、０ｘ０１、０ｘ０Ｄ、０ｘ０１、０ｘ０３、０ｘ０１、０ｘ１５、０ｘ０１、０ｘ０５、０ｘ００”が入力され、検索Ｋｅｙ情報１０１としてカウント値“３０１”が入力される。又、状態遷移テーブル２２として図６に示す遷移テーブルが用意され、Ｋｅｙリスト２３として図７に示すリストが用意される。検索処理部２１０は、Ｋｅｙリスト２３を参照して、Ｋｅｙ情報１０１で指定されたＫｅｙ（所望のＫｅｙ）が属する状態が、Ｅｓｓｅｎｃｅ ＣｏｎｔａｉｎｅｒのＶｉｄｅｏデータであることを確認する。

以下では、Ｋｅｙ回数判定部２１２においてカウントされる所望Ｋｅｙの出現回数をカウントＣ、状態情報２４として設定される現在の状態及びＰａｒｔｉｔｉｏｎの遷移先となる候補をそれぞれ状態Ｓ及びＰａｔｉｔｉｏｎ Ｐ、位置情報２５として設定される検索位置をデータ位置Ｄとして説明する。

検索処理の開始時、初期設定値としてカウントＣ“０”、データ位置Ｄ“０”、現在の状態“Ｓｔａｒｔ”が設定され、遷移先との候補となる状態ＳはＨｅａｄｅｒ Ｐａｒｔｉｔｉｏｎ、Ｐａｒｔｉｔｉｏｎ ＰはＨｅａｄｅｒとなる。

１巡目
検索処理部２１０にＭＸＦデータ１００が入力されると、Ｋｅｙがデータの先頭から１６Ｂｙｔｅとして取得される。検索処理部２１０は、取得したＫｅｙがＭＸＦ規格に正当であるかをチェックする。ここでは、取得したＫｅｙがＨｅａｄｅｒ Ｐａｒｔｉｔｉｏｎに属するか否かが判定される。

取得したＫｅｙがＨｅａｄｅｒ Ｐａｒｔｉｔｉｏｎに属しているため、検索処理部２１０は、後続の４Ｂｙｔｅ（Ｌｅｎｇｔｈ）を取得する。ここでＬｅｎｇｔｈが示すデータ長１０４は、“Ｌ１”である。

次に、検索処理部２１０は、取得したＫｅｙが所望のＫｅｙであるかをチェックする。取得したＫｅｙの状態は、所望のＫｅｙの属するＥｓｓｅｎｃｅ ＣｏｎｔａｉｎｅｒのＶｉｄｅｏと異なるため、カウントＣは加算されない。

カウントが所望回数（３０１）に達していないため、１ＫＬＶ分（１６＋４＋Ｌ１）分、検出対象となるデータ位置をスキップする。又、データ位置Ｄを１ＫＬＶ分加算する（Ｄ＝１６＋４＋Ｌ１）。

検出されたＫｅｙの状態がＨｅａｄｅｒ Ｐａｒｔｉｔｉｏｎであるため、現在の状態（状態情報２４）は、ＳｔａｒｔからＨｅａｄｅｒ Ｐａｒｔｉｔｉｏｎに変更される。これにより、遷移先の候補となる状態ＳはＰｒｉｍｅｒ、遷移先の候補となるＰａｒｔｉｔｉｏｎ ＰはＨｅａｄｅｒ、Ｂｏｄｙとなる（図６参照）。

以上の処理により、カウントＣ“０”、データ位置Ｄ“１６＋４＋Ｌ１”、現在の状態“Ｈｅａｄｅｒ Ｐａｒｔｉｔｉｏｎ”、遷移先の候補となる状態Ｓ“Ｐｒｉｍｅｒ”、遷移先の候補となるＰａｒｔｉｔｉｏｎ Ｐ“Ｈｅａｄｅｒ、Ｂｏｄｙ”となる。

２巡目
次に、Ｋｅｙが、データ位置Ｄ“１６＋４＋Ｌ１”から１６Ｂｙｔｅとして取得される。検索処理部２１０は、取得したＫｅｙがＭＸＦ規格に正当であるかをチェックする。ここでは、取得したＫｅｙがＰｒｉｍｅｒ（Ｈｅａｄｅｒ、Ｂｏｄｙ）に属するか否かが判定される。

取得したＫｅｙがＰｒｉｍｅｒ（Ｈｅａｄｅｒ）に属しているため、検索処理部２１０は、後続の４Ｂｙｔｅ（Ｌｅｎｇｔｈ）を取得する。ここでＬｅｎｇｔｈが示すデータ長１０４は、“Ｌ２”である。

次に、検索処理部２１０は、取得したＫｅｙが所望のＫｅｙであるかをチェックする。取得したＫｅｙの状態“Ｐｒｉｍｅｒ（Ｈｅａｄｅｒ）”は、所望のＫｅｙの属するＥｓｓｅｎｃｅ ＣｏｎｔａｉｎｅｒのＶｉｄｅｏと異なるため、カウントＣは加算されない。

カウントが所望回数（３０１）に達していないため、１ＫＬＶ分（１６＋４＋Ｌ２）分、検出対象となるデータ位置をスキップする。又、データ位置Ｄを１ＫＬＶ分加算する（Ｄ＝１６＋４＋Ｌ１＋１６＋４＋Ｌ２）。

検出されたＫｅｙの状態がＰｒｉｍｅｒ（Ｈｅａｄｅｒ）であるため、現在の状態（状態情報２４）は、Ｈｅａｄｅｒ ＰａｒｔｉｔｉｏｎからＰｒｉｍｅｒ（Ｈｅａｄｅｒ）に変更される。これにより、遷移先の候補となる状態ＳはＰｒｉｍｅｒ、遷移先の候補となるＰａｒｔｉｔｉｏｎ ＰはＨｅａｄｅｒ、Ｂｏｄｙとなる（図６参照）。

以上の処理により、カウントＣ“０”、データ位置Ｄ“１６＋４＋Ｌ１＋１６＋４＋Ｌ２”、現在の状態“Ｐｒｉｍｅｒ（Ｈｅａｄｅｒ、Ｂｏｄｙ）”、遷移先の候補となる状態Ｓ“Ｍｅｔａｄａｔａ”、遷移先の候補となるＰａｒｔｉｔｉｏｎ Ｐ“Ｈｅａｄｅｒ、Ｂｏｄｙ”となる。

３巡目
Ｋｅｙが、データ位置Ｄ“１６＋４＋Ｌ１＋１６＋４＋Ｌ２”から１６Ｂｙｔｅとして取得される。検索処理部２１０は、取得したＫｅｙがＭＸＦ規格に正当であるかをチェックする。ここでは、取得したＫｅｙがＭｅｔａｄａｔａ（Ｈｅａｄｅｒ、Ｂｏｄｙ）に属するか否かが判定される。

取得したＫｅｙがＭｅｔａｄａｔａ（Ｈｅａｄｅｒ）に属しているため、検索処理部２１０は、後続の４Ｂｙｔｅ（Ｌｅｎｇｔｈ）を取得する。ここでＬｅｎｇｔｈが示すデータ長１０４は、“Ｌ３”である。

次に、検索処理部２１０は、取得したＫｅｙが所望のＫｅｙであるかをチェックする。取得したＫｅｙの状態“Ｍｅｔａｄａｔａ（Ｈｅａｄｅｒ）”は、所望のＫｅｙの属するＥｓｓｅｎｃｅ ＣｏｎｔａｉｎｅｒのＶｉｄｅｏと異なるため、カウントＣは加算されない。

カウントが所望回数（３０１）に達していないため、１ＫＬＶ分（１６＋４＋Ｌ３）分、検出対象となるデータ位置をスキップする。又、データ位置Ｄを１ＫＬＶ分加算する（Ｄ＝１６＋４＋Ｌ１＋１６＋４＋Ｌ２＋１６＋４＋Ｌ３）。

検出されたＫｅｙの状態がＭｅｔａｄａｔａ（Ｈｅａｄｅｒ）であるため、現在の状態（状態情報２４）は、Ｐｒｉｍｅｒ（Ｈｅａｄｅｒ）からＭｅｔａｄａｔａ（Ｈｅａｄｅｒ）に変更される。これにより、遷移先の候補となる状態ＳはＭｅｔａｄａｔａ、Ｂｏｄｙ Ｐａｒｔｉｔｉｏｎ、Ｉｎｄｅｘ Ｔａｂｌｅ、Ｅｓｓｅｎｃｅ Ｃｏｎｔａｉｎｅｒ、Ｆｏｏｔｅｒ Ｐａｒｔｉｔｉｏｎとなり、遷移先の候補となるＰａｒｔｉｔｉｏｎ ＰはＨｅａｄｅｒ、Ｂｏｄｙとなる（図６参照）。

以上の処理により、カウントＣ“０”、データ位置Ｄ“１６＋４＋Ｌ１＋１６＋４＋Ｌ２＋１６＋４＋Ｌ３”、現在の状態“Ｍｅｔａｄａｔａ（Ｈｅａｄｅｒ）”、遷移先の候補となる状態Ｓ“Ｍｅｔａｄａｔａ、Ｂｏｄｙ Ｐａｒｔｉｔｉｏｎ、Ｉｎｄｅｘ Ｔａｂｌｅ、Ｅｓｓｅｎｃｅ Ｃｏｎｔａｉｎｅｒ、Ｆｏｏｔｅｒ Ｐａｒｔｉｔｉｏｎ”、遷移先の候補となるＰａｒｔｉｔｉｏｎ Ｐ“Ｈｅａｄｅｒ、Ｂｏｄｙ”となる。

４巡目
Ｋｅｙが、データ位置Ｄ“１６＋４＋Ｌ１＋１６＋４＋Ｌ２＋１６＋４＋Ｌ３”から１６Ｂｙｔｅとして取得される。検索処理部２１０は、取得したＫｅｙがＭＸＦ規格に正当であるかをチェックする。ここでは、取得したＫｅｙがＭｅｔａｄａｔａ（Ｈｅａｄｅｒ、Ｂｏｄｙ）、Ｂｏｄｙ Ｐａｒｔｉｔｉｏｎ、Ｉｎｄｅｘ Ｔａｂｌｅ（Ｈｅａｄｅｒ、Ｂｏｄｙ）、Ｅｓｓｅｎｃｅ Ｃｏｎｔａｉｎｅｒ、Ｆｏｏｔｅｒ Ｐａｒｔｉｔｉｏｎのいずれかに属するか否かが判定される。

取得したＫｅｙがＭｅｔａｄａｔａ（Ｈｅａｄｅｒ）に属しているため、検索処理部２１０は、後続の４Ｂｙｔｅ（Ｌｅｎｇｔｈ）を取得する。ここでＬｅｎｇｔｈが示すデータ長１０４は、“Ｌ４”である。

次に、検索処理部２１０は、取得したＫｅｙが所望のＫｅｙであるかをチェックする。取得したＫｅｙの状態“Ｍｅｔａｄａｔａ（Ｈｅａｄｅｒ）”は、所望のＫｅｙの属するＥｓｓｅｎｃｅ ＣｏｎｔａｉｎｅｒのＶｉｄｅｏと異なるため、カウントＣは加算されない。

カウントが所望回数（３０１）に達していないため、１ＫＬＶ分（１６＋４＋Ｌ４）分、検出対象となるデータ位置をスキップする。又、データ位置Ｄを１ＫＬＶ分加算する（Ｄ＝１６＋４＋Ｌ１＋１６＋４＋Ｌ２＋１６＋４＋Ｌ３＋１６＋４＋Ｌ４）。

検出されたＫｅｙの状態がＭｅｔａｄａｔａ（Ｈｅａｄｅｒ）であるため、現在の状態（状態情報２４）はＭｅｔａｄａｔａ（Ｈｅａｄｅｒ、Ｂｏｄｙ）を維持する。これにより、遷移先の候補となる状態ＳはＭｅｔａｄａｔａ、Ｂｏｄｙ Ｐａｒｔｉｔｉｏｎ、Ｉｎｄｅｘ Ｔａｂｌｅ、Ｅｓｓｅｎｃｅ Ｃｏｎｔａｉｎｅｒ、Ｆｏｏｔｅｒ Ｐａｒｔｉｔｉｏｎとなり、遷移先の候補となるＰａｒｔｉｔｉｏｎ ＰはＨｅａｄｅｒ、Ｂｏｄｙとなる（図６参照）。

以上の処理により、カウントＣ“０”、データ位置Ｄ“１６＋４＋Ｌ１＋１６＋４＋Ｌ２＋１６＋４＋Ｌ３＋１６＋４＋Ｌ４”、現在の状態“Ｍｅｔａｄａｔａ（Ｈｅａｄｅｒ、Ｂｏｄｙ）”、遷移先の候補となる状態Ｓ“Ｍｅｔａｄａｔａ（Ｈｅａｄｅｒ、Ｂｏｄｙ）、Ｂｏｄｙ Ｐａｒｔｉｔｉｏｎ、Ｉｎｄｅｘ Ｔａｂｌｅ（Ｈｅａｄｅｒ、Ｂｏｄｙ）、Ｅｓｓｅｎｃｅ Ｃｏｎｔａｉｎｅｒ、Ｆｏｏｔｅｒ Ｐａｒｔｉｔｉｏｎ”、遷移先の候補となるＰａｒｔｉｔｉｏｎ Ｐ“Ｈｅａｄｅｒ”となる。

５順目
Ｋｅｙが、データ位置Ｄ“１６＋４＋Ｌ１＋１６＋４＋Ｌ２＋１６＋４＋Ｌ３＋１６＋４＋Ｌ４”から１６Ｂｙｔｅとして取得される。検索処理部２１０は、取得したＫｅｙがＭＸＦ規格に正当であるかをチェックする。ここでは、取得したＫｅｙがＭｅｔａｄａｔａ（Ｈｅａｄｅｒ、Ｂｏｄｙ）、Ｂｏｄｙ Ｐａｒｔｉｔｉｏｎ、Ｉｎｄｅｘ Ｔａｂｌｅ（Ｈｅａｄｅｒ、Ｂｏｄｙ）、Ｅｓｓｅｎｃｅ Ｃｏｎｔａｉｎｅｒ、Ｆｏｏｔｅｒ Ｐａｒｔｉｔｉｏｎのいずれかに属するか否かが判定される。

取得したＫｅｙがＥｓｓｅｎｃｅ Ｃｏｎｔａｉｎｅｒ（Ｈｅａｄｅｒ）に属しているため、検索処理部２１０は、後続の４Ｂｙｔｅ（Ｌｅｎｇｔｈ）を取得する。ここでＬｅｎｇｔｈが示すデータ長１０４は、“Ｌ５”である。

次に、検索処理部２１０は、取得したＫｅｙが所望のＫｅｙであるかをチェックする。取得したＫｅｙの状態は、Ｅｓｓｅｎｃｅ Ｃｏｎｔａｉｎｅｒ（Ｖｉｄｅｏ １Ｆｒａｍｅ）であり、所望のＫｅｙの属するＥｓｓｅｎｃｅ ＣｏｎｔａｉｎｅｒのＶｉｄｅｏと一致する。このため、カウントＣに１が加算される。

カウントＣ＝１は、所望回数（３０１）に達していないため、１ＫＬＶ分（１６＋４＋Ｌ５）分、検出対象となるデータ位置をスキップする。又、データ位置Ｄを１ＫＬＶ分加算する（Ｄ＝１６＋４＋Ｌ１＋１６＋４＋Ｌ２＋…＋１６＋４＋Ｌ５）。

検出されたＫｅｙの状態がＥｓｓｅｎｃｅ Ｃｏｎｔａｉｎｅｒ（Ｈｅａｄｅｒ）であるため、現在の状態（状態情報２４）は、Ｍｅｔａｄａｔａ（Ｈｅａｄｅｒ）からＥｓｓｅｎｃｅ Ｃｏｎｔａｉｎｅｒ（Ｈｅａｄｅｒ）に変更される。これにより、遷移先の候補となる状態Ｓは、Ｅｓｓｅｎｃｅ Ｃｏｎｔａｉｎｅｒ、Ｂｏｄｙ Ｐａｒｔｉｔｉｏｎ、Ｆｏｏｔｅｒ Ｐａｒｔｉｔｉｏｎとなり、遷移先の候補となるＰａｒｔｉｔｉｏｎ ＰはＨｅａｄｅｒ、Ｂｏｄｙとなる（図６参照）。

以上の処理により、カウントＣ“１”、データ位置Ｄ“１６＋４＋Ｌ１＋１６＋４＋Ｌ２＋…＋１６＋４＋Ｌ５”、現在の状態“Ｅｓｓｅｎｃｅ Ｃｏｎｔａｉｎｅｒ（Ｈｅａｄｅｒ）”、遷移先の候補となる状態Ｓ“Ｅｓｓｅｎｃｅ Ｃｏｎｔａｉｎｅｒ、Ｂｏｄｙ Ｐａｒｔｉｔｉｏｎ、Ｆｏｏｔｅｒ Ｐａｒｔｉｔｉｏｎ”、遷移先の候補となるＰａｒｔｉｔｉｏｎ Ｐ“Ｈｅａｄｅｒ、Ｂｏｄｙ”となる。

６順目
Ｋｅｙが、データ位置Ｄ“１６＋４＋Ｌ１＋１６＋４＋Ｌ２＋…＋１６＋４＋Ｌ５”から１６Ｂｙｔｅとして取得される。検索処理部２１０は、取得したＫｅｙがＭＸＦ規格に正当であるかをチェックする。ここでは、取得したＫｅｙがＥｓｓｅｎｃｅ Ｃｏｎｔａｉｎｅｒ（Ｈｅａｄｅｒ、Ｂｏｄｙ）、Ｂｏｄｙ Ｐａｒｔｉｔｉｏｎ、Ｆｏｏｔｅｒ Ｐａｒｔｉｔｉｏｎのいずれかに属するか否かが判定される。

取得したＫｅｙがＥｓｓｅｎｃｅ Ｃｏｎｔａｉｎｅｒ（Ｈｅａｄｅｒ）に属しているため、検索処理部２１０は、後続の４Ｂｙｔｅ（Ｌｅｎｇｔｈ）を取得する。ここでＬｅｎｇｔｈが示すデータ長１０４は、“Ｌ６”である。

次に、検索処理部２１０は、取得したＫｅｙが所望のＫｅｙであるかをチェックする。取得したＫｅｙの状態はＥｓｓｅｎｃｅ Ｃｏｎｔａｉｎｅｒ（Ａｕｄｉｏ １Ｆｒａｍｅ）であり、所望のＫｅｙの属するＥｓｓｅｎｃｅ ＣｏｎｔａｉｎｅｒのＶｉｄｅｏと異なるため、カウントＣは加算されない。

カウントＣ＝１は、所望回数（３０１）に達していないため、１ＫＬＶ分（１６＋４＋Ｌ６）分、検出対象となるデータ位置をスキップする。又、データ位置Ｄを１ＫＬＶ分加算する（Ｄ＝１６＋４＋Ｌ１＋１６＋４＋Ｌ２＋…＋１６＋４＋Ｌ６）。

検出されたＫｅｙの状態がＥｓｓｅｎｃｅ Ｃｏｎｔａｉｎｅｒ（Ｈｅａｄｅｒ）であるため、現在の状態（状態情報２４）はＥｓｓｅｎｃｅ Ｃｏｎｔａｉｎｅｒ（Ｈｅａｄｅｒ）を維持する。これにより、遷移先の候補となる状態Ｓは、Ｅｓｓｅｎｃｅ Ｃｏｎｔａｉｎｅｒ 、Ｂｏｄｙ Ｐａｒｔｉｔｉｏｎ、Ｆｏｏｔｅｒ Ｐａｒｔｉｔｉｏｎとなり、遷移先の候補となるＰａｒｔｉｔｉｏｎ ＰはＨｅａｄｅｒ、Ｂｏｄｙとなる（図６参照）。

以上の処理により、カウントＣ“１”、データ位置Ｄ“１６＋４＋Ｌ１＋１６＋４＋Ｌ２＋…＋１６＋４＋Ｌ６”、現在の状態“Ｅｓｓｅｎｃｅ Ｃｏｎｔａｉｎｅｒ（Ｈｅａｄｅｒ、Ｂｏｄｙ）”、遷移先の候補となる状態Ｓ“Ｅｓｓｅｎｃｅ Ｃｏｎｔａｉｎｅｒ、Ｂｏｄｙ Ｐａｒｔｉｔｉｏｎ、Ｆｏｏｔｅｒ Ｐａｒｔｉｔｉｏｎ”、遷移先の候補となるＰａｒｔｉｔｉｏｎ Ｐ“Ｈｅａｄｅｒ、Ｂｏｄｙ”となる。

以降、同様の処理が行なわれ、６０４巡目の処理までに、Ｅｓｓｅｎｃｅ Ｃｏｎｔａｉｎｅｒ（Ｈｅａｄｅｒ、Ｂｏｄｙ）のＶｉｄｅｏデータに属するＫｅｙが３００回カウントされる。この間、Ｅｓｓｅｎｃｅ Ｃｏｎｔａｉｎｅｒのみが取得されていたため、状態ＳはＥｓｓｅｎｃｅ Ｃｏｎｔａｉｎｅｒを維持し、Ｐａｒｔｉｔｉｏｎ ＰはＨｅａｄｅｒを維持する。すなわち、６０４巡目の処理によって、カウントＣ“３００”、データ位置Ｄ“１６＋４＋Ｌ１＋１６＋４＋Ｌ２＋…＋１６＋４＋Ｌ６０４”、現在の状態“Ｅｓｓｅｎｃｅ Ｃｏｎｔａｉｎｅｒ（Ｈｅａｄｅｒ）”、遷移先の候補となる状態Ｓ“Ｅｓｓｅｎｃｅ Ｃｏｎｔａｉｎｅｒ、Ｂｏｄｙ Ｐａｒｔｉｔｉｏｎ、Ｆｏｏｔｅｒ Ｐａｒｔｉｔｉｏｎ”、遷移先の候補となるＰａｒｔｉｔｉｏｎ Ｐ“Ｈｅａｄｅｒ、Ｂｏｄｙ”となる。

６０５順目
Ｋｅｙが、データ位置Ｄ“１６＋４＋Ｌ１＋１６＋４＋Ｌ２＋…＋１６＋４＋Ｌ６０４”から１６Ｂｙｔｅとして取得される。検索処理部２１０は、取得したＫｅｙがＭＸＦ規格に正当であるかをチェックする。ここでは、取得したＫｅｙがＥｓｓｅｎｃｅ Ｃｏｎｔａｉｎｅｒ（Ｈｅａｄｅｒ、Ｂｏｄｙ）、Ｂｏｄｙ Ｐａｒｔｉｔｉｏｎ、Ｆｏｏｔｅｒ Ｐａｒｔｉｔｉｏｎのいずれかに属するか否かが判定される。

取得したＫｅｙがＢｏｄｙ Ｐａｒｔｉｔｉｏｎに属しているため、検索処理部２１０は、後続の４Ｂｙｔｅ（Ｌｅｎｇｔｈ）を取得する。ここでＬｅｎｇｔｈが示すデータ長１０４は、“Ｌ６０５”である。

次に、検索処理部２１０は、取得したＫｅｙが所望のＫｅｙであるかをチェックする。取得したＫｅｙの状態“Ｂｏｄｙ Ｐａｒｔｉｔｉｏｎ”は所望のＫｅｙの属するＥｓｓｅｎｃｅ ＣｏｎｔａｉｎｅｒのＶｉｄｅｏ（映像データ）と異なるため、カウントＣは加算されない。

カウントＣ＝３００は、所望回数（３０１）に達していないため、１ＫＬＶ分（１６＋４＋Ｌ６０５）分、検出対象となるデータ位置をスキップする。又、データ位置Ｄを１ＫＬＶ分加算する（Ｄ＝１６＋４＋Ｌ１＋１６＋４＋Ｌ２＋…＋１６＋４＋Ｌ６０５）。

検出されたＫｅｙの状態がＢｏｄｙ Ｐａｒｔｉｔｉｏｎであるため、現在の状態（状態情報２４）は、Ｅｓｓｅｎｃｅ Ｃｏｎｔａｉｎｅｒ（Ｈｅａｄｅｒ）からＢｏｄｙ Ｐａｒｔｉｔｉｏｎに変更される。これにより、遷移先の候補となる状態Ｓは、Ｐｒｉｍｅｒ、Ｉｎｄｅｘ Ｔａｂｌｅ、Ｅｓｓｅｎｃｅ、Ｃｏｎｔａｉｎｅｒ、Ｆｏｏｔｅｒ Ｐａｒｔｉｔｉｏｎとなり、遷移先の候補となるＰａｒｔｉｔｉｏｎ ＰはＨｅａｄｅｒ、Ｂｏｄｙとなる（図６参照）。

以上の処理により、カウントＣ“３００”、データ位置Ｄ“１６＋４＋Ｌ１＋１６＋４＋Ｌ２＋…＋１６＋４＋Ｌ６０５”、現在の状態“Ｂｏｄｙ Ｐａｒｔｉｔｉｏｎ”、遷移先の候補となる状態Ｓ“Ｐｒｉｍｅｒ、Ｉｎｄｅｘ Ｔａｂｌｅ、Ｅｓｓｅｎｃｅ、Ｃｏｎｔａｉｎｅｒ、Ｆｏｏｔｅｒ Ｐａｒｔｉｔｉｏｎ”、遷移先の候補となるＰａｒｔｉｔｉｏｎ Ｐ“Ｈｅａｄｅｒ、Ｐａｒｔｉｔｉｏｎ”となる。

６０６順目
Ｋｅｙが、データ位置Ｄ“１６＋４＋Ｌ１＋１６＋４＋Ｌ２＋…＋１６＋４＋Ｌ６０４”から１６Ｂｙｔｅとして取得される。検索処理部２１０は、取得したＫｅｙがＭＸＦ規格に正当であるかをチェックする。ここでは、取得したＫｅｙがＰｒｉｍｅｒ（Ｈｅａｄｅｒ、Ｂｏｄｙ）、Ｉｎｄｅｘ Ｔａｂｌｅ（Ｈｅａｄｅｒ、Ｂｏｄｙ）、Ｅｓｓｅｎｃｅ Ｃｏｎｔａｉｎｅｒ（Ｈｅａｄｅｒ、Ｂｏｄｙ）、Ｆｏｏｔｅｒ Ｐａｒｔｉｔｉｏｎのいずれかに属するか否かが判定される。

取得したＫｅｙがＥｓｓｅｎｃｅ Ｃｏｎｔａｉｎｅｒ（Ｂｏｄｙ）に属しているため、検索処理部２１０は、後続の４Ｂｙｔｅ（Ｌｅｎｇｔｈ）を取得する。ここでＬｅｎｇｔｈが示すデータ長１０４は、“Ｌ６０６”である。

次に、検索処理部２１０は、取得したＫｅｙが所望のＫｅｙであるかをチェックする。取得したＫｅｙの状態はＥｓｓｅｎｃｅ Ｃｏｎｔａｉｎｅｒ（Ｖｉｄｅｏ ３０１Ｆｒａｍｅ）であり、所望のＫｅｙの属するＥｓｓｅｎｃｅ ＣｏｎｔａｉｎｅｒのＶｉｄｅｏに一致し、カウントＣに１が加算され、カウントＣ“３０１”となる。

カウントＣ＝３０１は、所望回数（３０１）に一致するため、検索処理部２１０は、データ位置ＤにＫｅｙとＬｅｎｇｔｈのデータ長分（１６＋４）だけ加算する（Ｄ＝１６＋４＋Ｌ１＋１６＋４＋Ｌ２＋…＋１６＋４＋Ｌ６０５＋１６＋４）。そして検索処理部２１０は、データ位置ＤからＬｅｎｇｔｈで指定されたデータ長（Ｌ６０６）分のデータ（Ｖａｌｕｅ２００）を抽出して出力する。この際、データ位置“１６＋４＋Ｌ１＋１６＋４＋Ｌ２＋…＋１６＋４＋Ｌ６０５＋１６＋４”が検出位置情報２０１として出力されても良い。

出力されたＶａｌｕｅ２００（ここでは、３０１Ｆｒａｍｅ目のビデオデータ）や検出位置情報２０１は、出力装置１５０によって視認可能に出力される。

以上のように、本発明によるＭＸＦデータ再生装置１０００によれば、Ｉｎｄｅｘ Ｔａｂｌｅを有していないフォーマットのＭＸＦデータでも、所望のデータを高速に読み出し再生することができる。又、Ｉｎｄｅｘ Ｔａｂｌｅの入力を待たずにＭＸＦデータ内の所望のデータを読み出して再生することができるため、ＭＸＦデータへのアクセス効率が向上する。

ＭＸＦデータの中にはディジタルビデオデータ、オーディオデータが格納されており、システム間でそれらのデータを交換、授受する際に用いられる放送データフォーマットとして利用される。このためＭＸＦデータは、ネットワークを介して交換することが多い。

従来のデータの再生方法では、Ｉｎｄｅｘ Ｔａｂｌｅを用いてデータ位置を特定しているため、ネットワークを介してＭＸＦデータを取得している間は、Ｉｎｄｅｘ Ｔａｂｌｅが受信されるまで所望データ位置を特定することはできなかった。一方、本発明では、Ｉｎｄｅｘ Ｔａｂｌｅを用いずＫｅｙを利用して所望データへのアクセスを実現している。このため、データの転送中においても、ＭＸＦデータ内の所望のデータ位置を効率的に検索することができる。すなわち、データの受信中においても所望するディジタルビデオデータ位置を容易に特定でき、取得したデータ位置を利用して当該ビデオデータの再生、記録、加工等の処理を行うことができる。

又、通常、Ｉｎｄｅｘ ＴａｂｌｅはＥｓｓｅｎｃｅのみの検索に利用するものであり、そのほかのデータの位置については、Ｉｎｄｅｘ Ｔａｂｌｅの情報は活用できない。しかし、本発明では、Ｋｅｙを用いて所望データの検索を行なうため、Ｅｓｓｅｎｃｅ Ｃｏｎｔａｅｉｎｅｒのみならず他のデータも高速にアクセスし、抽出することができる。

更に、本発明では、Ｋｅｙの属する状態が、ＭＸＦ規格に適合しているかを判定しながら、アクセス対象のデータを検索している。このため、本発明によるＭＸＦデータ再生装置１０００を用いれば、再生するデータ構造（ＫＬＶデータの並び）が、予め設定されたＭＸＦ規格に適合しているかどうかを判定することができる。

更に、本発明では、ＭＸＦデータ規格特性を利用して、データの検索を行なう前に、次に出てくる検索対象Ｋｅｙを事前に絞込み、検索時間の減少、効率的な検索を行うことができる。

以上、本発明の実施の形態を詳述してきたが、具体的な構成は上記実施の形態に限られるものではなく、本発明の要旨を逸脱しない範囲の変更があっても本発明に含まれる。例えば、状態遷移テーブル２２やＫｅｙリスト２３は上述の仕様に限らず、状態の分類方法や、規格に応じた遷移ルールに基づいて適宜変更され得る。

２１：ＭＸＦデータ検索プログラム
２２：状態遷移テーブル
２３：Ｋｅｙリスト
２４：状態情報
２５：位置情報
２１０：検索処理部
２１１：Ｋｅｙ検出部
２１２：Ｋｅｙ回数判定部
２１３：状態遷移部
２１４：データ抽出部
１００：ＭＸＦデータ
１０１：検索Ｋｅｙ情報
１０２：検索Ｋｅｙ回数
１０３：Ｋｅｙ情報
１０４：データ長
１０５：判定結果
２００：Ｖａｌｕｅ
２０１：検出位置情報
１１０：ＣＰＵ
１２０：ＲＡＭ
１３０：記憶装置
１４０：入力装置
１５０：出力装置
１６０：Ｉ／Ｏ装置
１０００：ＭＸＦデータ再生装置

Claims (9)

1. ＭＸＦ（Ｍａｔｅｒｉａｌ ｅＸｃｈａｎｇｅ Ｆｏｒｍａｔ）データからＫｅｙを検出するＫｅｙ検出部と、
   検出されたＫｅｙを用いて特定された所望データを、前記ＭＸＦデータから抽出するデータ抽出部と、
   前記検出されたＫｅｙの属する状態が、所望のＫｅｙの属する状態と一致する回数をカウントするＫｅｙ回数判定部と、
   ＭＸＦ規格に応じたデータ構造に基づいて、前記ＭＸＦデータにおける状態の並び順が設定された状態遷移テーブルと
   を具備し、
   前記データ抽出部は、前記Ｋｅｙ回数判定部におけるカウント数が所望の回数に達した時に検出されたＫｅｙに後続するデータを、前記所望データとして抽出し、
   前記Ｋｅｙ検出部は、次に検出されるＫｅｙが属する状態の遷移先を、前記状態遷移テーブルを用いて予測し、前記検出されたＫｅｙの次に検出したＫｅｙの状態が、予測された遷移先の状態に含まれている場合、前記ＭＸＦデータは前記ＭＸＦ規格に適合していると判定する
   ＭＸＦデータ検索装置。
2. 請求項１に記載のＭＸＦデータ検索装置において、
   ＫｅｙとＫｅｙの属する状態とが対応付けられて設定されたＫｅｙリストを更に具備し、
   前記Ｋｅｙ検出部は、前記Ｋｅｙリストを参照して前記検出されたＫｅｙの状態を特定する
   ＭＸＦデータ検索装置。
3. 請求項１又は２に記載のＭＸＦデータ検索装置において、
   前記状態は、データのＰａｒｔｉｔｉｏｎを示す情報を含む
   ＭＸＦデータ検索装置。
4. 請求項１から３のいずれか１項に記載のＭＸＦデータ検索装置において、
   前記状態は、データ項目を示す情報を含む
   ＭＸＦデータ検索装置。
5. 記憶装置内のＭＸＦ（Ｍａｔｅｒｉａｌ ｅＸｃｈａｎｇｅ Ｆｏｒｍａｔ）データ検索プログラムを実行するＣＰＵによって実現されるＭＸＦデータの検索方法であって、
   前記ＣＰＵが、ＭＸＦデータからＫｅｙを検出するステップと、
   前記ＣＰＵが、検出されたＫｅｙを用いて特定された所望データを、前記ＭＸＦデータから抽出するステップと、
   前記ＣＰＵが、前記検出されたＫｅｙの属する状態が、所望のＫｅｙの属する状態と一致する回数をカウントするステップと、
   前記Ｋｅｙを検出するステップにおいて検出されたＫｅｙが属する状態の遷移先を、状態遷移テーブルを用いて予測するステップと、
   前記検出されたＫｅｙの次に検出されたＫｅｙの状態が、予測された遷移先の状態に含まれている場合、前記ＭＸＦデータはＭＸＦ規格に適合していると判定するステップと
   を具備し、
   前記状態遷移テーブルには、前記ＭＸＦ規格に応じたデータ構造に基づいて、前記ＭＸＦデータにおける状態の並び順が設定され、
   前記所望のデータを抽出するステップは、
   前記ＣＰＵが、カウント数が所望の回数に達した時に検出されたＫｅｙに後続するデータを、前記ＭＸＦデータから抽出するステップを備える
   ＭＸＦデータの検索方法。
6. 請求項５に記載のＭＸＦデータの検索方法において、
   前記ＣＰＵが、ＫｅｙとＫｅｙの属する状態とが対応付けられて設定されたＫｅｙリストを参照して前記検出されたＫｅｙの状態を特定するステップと
   を更に具備する
   ＭＸＦデータの検索方法。
7. 請求項５又は６に記載のＭＸＦデータの検索方法において、
   前記状態は、データのＰａｒｔｉｔｉｏｎを示す情報を含む
   ＭＸＦデータの検索方法。
8. 請求項５から７のいずれか１項に記載のＭＸＦデータの検索方法において、
   前記状態は、データ項目を示す情報を含む
   ＭＸＦデータの検索方法。
9. 請求項５から８のいずれか１項に記載のＭＸＦデータの検索方法をコンピュータに実行させる
   ＭＸＦデータ検索プログラム。

Images