(57)【特許請求の範囲】
【請求項１】
オートマトンを用いてＸＰａｔｈを処理するＸＰａｔｈ処理装置におけるＸＰａｔｈ処理方法であって、
前記ＸＰａｔｈ処理装置が、
個々のＸＰａｔｈから非決定性オートマトンを生成するステップ、
前記生成した非決定性オートマトンを統合して結合非決定性オートマトンを生成し記憶装置に登録するステップ、
入力されたＸＭＬデータからＳＡＸイベントを生成するステップ、
前記生成したＳＡＸイベントに応じて、前記結合非決定性オートマトンを用いて決定性オートマトンを生成し記憶装置に登録するステップ、を備えると共に、
ＸＰａｔｈの追加がある場合に、前記追加されるＸＰａｔｈを非決定性オートマトンに変換し、前記ＸＰａｔｈの追加による非決定性オートマトンの更新を行った後、予め保持しておいたＸＭＬのルートのタグから現在処理中のタグまでの全ての開始タグを順に前記決定性オートマトンに入力することにより、ＸＰａｔｈの情報を差分追加すること、
を特徴とするＸＰａｔｈ処理方法。
【請求項２】
前記決定性オートマトンにおける各状態において、その状態が何件目のＸＰａｔｈまでの情報を元に更新されたかを示す状態フラグに基づいて、前記追加されるＸＰａｔｈの情報を差分追加すること、
を特徴とする請求項１に記載のＸＰａｔｈ処理方法。
【請求項３】
前記決定性オートマトンにおける状態推移を行う際、現在の決定性オートマトンにおける各状態の状態フラグをチェックし、
その状態が、最新のＸＰａｔｈを元に更新されていない場合は、前記状態フラグを用いてその状態が更新された後に追加されたＸＰａｔｈを特定し、該特定したＸＰａｔｈに対応する非決定性オートマトンの状態を用いて決定性オートマトンを更新すること、
を特徴とする請求項１又は請求項２に記載のＸＰａｔｈ処理方法。
【請求項４】
入力されたＸＭＬデータからＳＡＸイベントを生成する手段と、
利用者の検索条件に基づいた個々のＸＰａｔｈを非決定性オートマトンに変換し、該生成した非決定性オートマトンを統合して結合非決定性オートマトンを生成すると共に記憶装置に登録する手段と、
前記ＳＡＸイベントに応じて、前記登録した結合非決定性オートマトンを用いて決定性オートマトンを生成し、記憶装置に登録する手段と、
ＸＰａｔｈの追加要求があると、追加対象のＸｐａｔｈから非決定性オートマトンを生成し、前記ＸＰａｔｈの追加による非決定性オートマトンの更新を行った後、予め保持しておいたＸＭＬのルートのタグから現在処理中のタグまでの全ての開始タグを順に前記決定性オートマトンに入力することにより、ＸＰａｔｈの情報を差分追加する手段と、
を備えたことを特徴とするＸＰａｔｈ処理装置。
【請求項５】
オートマトンを用いてＸＰａｔｈを処理するため、コンピュータであるＸＰａｔｈ処理装置に、請求項１ないし請求項３のいずれか１項に記載のＸＰａｔｈ処理方法を実行させることを特徴とするＸＰａｔｈ処理プログラム。
【請求項６】
請求項５に記載のＸＰａｔｈ処理プログラムを記憶した記憶媒体。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、オートマトンを用いたＸＰａｔｈの処理に関し、殊にＸＰａｔｈの差分追加を行う、ＸＰａｔｈ処理方法、ＸＰａｔｈ処理装置、ＸＰａｔｈ処理プログラム、及びそのプログラムを記憶した記憶媒体に関する。
【０００２】
【従来の技術】
例えば、ＸＭＬ（eXtensible Markup Language）をベースにした新しいニュース配信フォーマットにＮｅｗｓＭＬ（ニューズエムエル）がある。ＮｅｗｓＭＬは、ニュース記事、画像、動画、音声等のニュース素材を自由に組み合わせ、ウェブサイトや携帯電話、テレビ（テレビのデータ放送）等、さまざまな機器を対象に情報を送ることができる。ＮｅｗｓＭＬの受け側（利用者）は、フィルタエンジンに検索条件を登録しておくことで、必要な情報を得ることができる。検索条件はＸＭＬ問い合わせ言語で記述されるため、フィルタエンジンはＸＰａｔｈ群（個々のＸＰａｔｈ）を処理すると共に、ＸＰａｔｈの追加を処理することになる。
【０００３】
【発明が解決しようとする課題】
ところで、従来のＸＰａｔｈの追加方式では、ＸＰａｔｈを処理するための決定性オートマトンが、ＸＰａｔｈの追加の度に別途生成されていた。このため、ＸＰａｔｈの追加の度に決定性オートマトンの数が増えてしまい、その結果フィルタエンジンを構成するコンピュータのメモリ空間を圧迫するという問題があった。殊に、ＸＰａｔｈの追加が多く行われるとその問題が顕著になる。
【０００４】
そこで、本発明は、ＸＰａｔｈの追加に対して、メモリ空間を有効に活用することのできるＸＰａｔｈ処理方法、ＸＰａｔｈ処理装置、ＸＰａｔｈ処理プログラム、及びそのプログラムを記憶した記憶媒体を提供することを主たる目的とする。
【０００５】
【課題を解決するための手段】
前記課題に鑑み本発明者らは鋭意研究を行い、既にあるＤＦＡに対して、ＸＰａｔｈの情報の差分追加を行うことによりメモリ空間の有効活用を図れることに着目し、本発明を完成するに至った。
【０００６】
〔ＸＰａｔｈ処理方法〕
即ち、前記課題を解決した本発明（請求項１）は、オートマトンを用いてＸＰａｔｈを処理するＸＰａｔｈ処理装置におけるＸＰａｔｈ処理方法であって、前記ＸＰａｔｈ処理装置が、個々のＸＰａｔｈから非決定性オートマトン（以下、「ＮＦＡ」という）を生成するステップ、前記生成した非決定性オートマトンを統合して結合非決定性オートマトンを生成し記憶装置に登録するステップ、入力されたＸＭＬデータからＳＡＸイベントを生成するステップ、前記生成したＳＡＸイベントに応じて、前記結合非決定性オートマトンを用いて決定性オートマトン（以下、「ＤＦＡ」という）を生成し記憶装置に登録するステップ、を備えると共に、ＸＰａｔｈの追加がある場合に、前記追加されるＸＰａｔｈを非決定性オートマトンに変換し、前記ＸＰａｔｈの追加による非決定性オートマトンの更新を行った後、予め保持しておいたＸＭＬのルートのタグから現在処理中のタグまでの全ての開始タグを順に前記決定性オートマトンに入力することにより、ＸＰａｔｈの情報を差分追加すること、を特徴とする。
【０００７】
この構成によれば、これまでに生成されているＤＦＡ（既存のＤＦＡ）に追加対象のＸＰａｔｈの情報を差分追加するだけなので、新たなＤＦＡを別に生成する必要がない。このため、メモリ空間の有効活用を図ることができる。なお、後述する発明の実施形態では、ＸＰａｔｈ（個々のＸＰａｔｈ，ＸＰａｔｈ群）は、図２の問い合わせパースモジュールが生成する。ＮＦＡ、結合ＮＦＡ、ＤＦＡは図２のオートマトン管理部（データ抽出モジュール）が生成する。ＸＰａｔｈの追加要求の判断は、図６のフローのステップＳ１４で行う。ＤＦＡに対するＸＰａｔｈの情報の差分追加は、図６のフローのステップＳ１６（ＤＦＡ更新１）とステップＳ２２（ＤＦＡ更新２）で行う処理が該当する。この構成においては、例えば後述する実施形態の図６・図７に示すフロー（ＤＦＡ更新１）のようにして、追加対象のＸＰａｔｈの情報が既存のＤＦＡに差分追加される。なお、後述する実施形態では、ｌａｂｅｌＳｔａｃｋが現状入力したＳＡＸイベントまでに完了していない（処理中の）要素名リストを保有する（タグは要素の位置を明示する）。また、ｒｏｏｔがＤＦＡのルート状態を表現する。また、ｃｕｒｒｅｎｔがＤＦＡにおける現状の状態を表現する。ちなみに、「開始タグを順に」における「順」とは、昇順、降順、ランダム順（順序を特定しない）等がある。
【００１０】
また、本発明（請求項２）は、請求項１の構成において、前記ＤＦＡにおける各状態において、その状態が何件目のＸＰａｔｈまでの情報を元に更新されたかを示す状態フラグに基づいて、前記追加されるＸＰａｔｈの情報を差分追加すること、を特徴とする。
【００１１】
この構成によれば、状態フラグにより、更新すべき部分に対してムダなく確実に更新を行うことができる。なお、後述する実施形態では、状態フラグはｖａｒＩｄが相当する。
【００１４】
また、本発明（請求項３）は、請求項１又は請求項２の構成において、前記ＤＦＡにおける状態推移を行う際、現在のＤＦＡにおける各状態の状態フラグをチェックし、その状態が、最新のＸＰａｔｈを元に更新されていない場合は、前記状態フラグを用いてその状態が更新された後に追加されたＸＰａｔｈを特定し、該特定したＸＰａｔｈに対応するＮＦＡの状態を用いて決定性オートマトンを更新すること、を特徴とする。
【００１５】
この構成においては、例えば後述する実施形態の図１３のように、ＸＰａｔｈが追加される。
【００１６】
〔ＸＰａｔｈ処理装置〕
また、本発明のＸＰａｔｈ処理装置（請求項４）は、入力されたＸＭＬデータからＳＡＸイベントを生成する手段と、利用者の検索条件に基づいた個々のＸＰａｔｈをＮＦＡに変換し、該生成したＮＦＡを統合して結合ＮＦＡを生成すると共に記憶装置に登録する手段と、前記ＳＡＸイベントに応じて、前記登録した結合ＮＦＡを用いてＤＦＡを生成し、記憶装置に登録する手段と、ＸＰａｔｈの追加要求があると、前記ＸＰａｔｈの追加によるＮＦＡの更新を行った後、予め保持しておいたＸＭＬのルートのタグから現在処理中のタグまでの全ての開始タグを順に前記ＮＦＡに入力することにより、ＸＰａｔｈの情報を差分追加する手段と、を備えたことを特徴とする。
【００１７】
この構成によれば、ＸＰａｔｈの情報が既存のＤＦＡに差分追加されるだけですむので、複数のＤＦＡを生成する必要がない。よって、メモリ空間の有効活用が図れる。なお、後述する実施形態では、フィルタエンジンがＸＰａｔｈ処理装置に相当する。また、ＸＭＬパースモジュールがＳＡＸイベントを生成する手段に相当する。また、問い合わせパースモジュールが、個々のＸＰａｔｈの生成、追加されるＸＰａｔｈの生成を行う手段に相当する。また、オートマトン管理部が、ＸＰａｔｈのＮＦＡへの変換、結合ＮＦＡの生成、ＤＦＡの生成、ＤＦＡに対するＸＰａｔｈの情報の差分追加を行う手段に相当する。また、この構成においては、例えば後述する実施形態の図６・図７に示すフロー（ＤＦＡ更新１）のようにして、追加対象のＸＰａｔｈの情報が既存のＤＦＡに差分追加される。
【００２０】
〔ＸＰａｔｈ処理プログラム〕
また、本発明のＸＰａｔｈ処理プログラム（請求項５）は、オートマトンを用いてＸＰａｔｈを処理するため、コンピュータであるＸＰａｔｈ処理装置に、請求項１ないし請求項３のいずれか１項に記載のＸＰａｔｈ処理方法を実行させることを特徴とする。
【００２１】
この構成によれば、このプログラムをインストールされたコンピュータに、プログラムに基づいた各ステップを実行させ、ＸＰａｔｈの処理（ＤＦＡの差分更新）を行う。
【００２２】
〔ＸＰａｔｈ処理プログラムを記憶した記憶媒体〕
また、本発明のＸＰａｔｈ処理プログラムを記憶した記憶媒体（請求項６）は、請求項５に記載のＸＰａｔｈ処理プログラムを記憶する構成とした。
【００２３】
このＸＰａｔｈ処理プログラムは、例えばＣＤ−ＲＯＭ等の記録媒体に複写・記録されて市場を流通されたり、例えばネットワーク上を伝送されたりする。そして、このプログラムをインストールされたコンピュータにＸＰａｔｈの処理（ＤＦＡの差分更新）を実行させる。
【００２４】
【発明の実施の形態】
以下、本発明のＸＰａｔｈ処理方法の実施の形態（実施形態）を、図面を参照して詳細に説明する。なお、以下説明するＸＰａｔｈ処理方法は、ＸＰａｔｈ処理装置、ＸＰａｔｈ処理プログラムを具現化したものでもある。
【００２５】
図１は、ＸＰａｔｈ処理方法が適用されるフィルタエンジンの概要を示す図である。
図示しないデータ提供者によりＸＭＬ形式に従って生成されたＸＭＬデータが、ＸＰａｔｈ処理方法を実行するフィルタエンジン１０にイントラネット等のネットワークを経由して送信される。フィルタエンジン１０には、ＸＭＬデータ受け取る個々の利用者が、自分の欲しいデータの条件（個人プロファイル）を、従来例のごとく、ＸＭＬ問い合わせという形式でフィルタエンジン１０に予め登録している。
【００２６】
フィルタエンジン１０は、登録されている個人プロファイルに応じて送られてくるニュースソース等のＸＭＬデータをフィルタ・変換して個々の利用者にＸＭＬデータとして配信する。ニュースソース等のＸＭＬデータの具体例としては、ＮｅｗｓＭＬがある。ＮｅｗｓＭＬは前記のとおり、ＸＭＬをベースにした新しいニュース配信フォーマットであり、ニュース記事、画像、動画、音声等のニュース素材を自由に組み合わせ、ウェブサイトや携帯電話等さまざまな機器を対象に情報を送ることができる。また、ニュース記事、画像、動画、音声等のさまざまなニュース素材を構造化して一元管理するのに適する。
【００２７】
なお、フィルタエンジン１０は、ＸＰａｔｈ処理装置及びＸＰａｔｈ処理プログラムを内包するものでもある。ちなみに、ＸＭＬは、インターネットの標準としてＷ３Ｃ（World Wide Web Consortium）により勧告されたメタ言語である。メタ言語は、言語を作る言語という意味である。ＸＭＬデータ（ＸＭＬ文書[XML Document]ともいう）は、ＸＭＬによって作られた言語を用いて作成された文書やデータである。
【００２８】
図２は、図１のフィルタエンジン１０の内部構成を示すブロック図である。この図２に示すように、フィルタエンジン１０は、ＸＭＬパースモジュール１１、問い合わせパースモジュール１２、データ抽出モジュール１３、記憶装置１４、オートマトン管理部１５、データ変換モジュール１６を含んで構成される。なお、データ抽出モジュール１３と記憶装置１４を含んでオートマトン管理部１５が構成されるものとする。ちなみに、フィルタエンジン１０は、ＣＰＵ及びＲＡＭから構成される主制御装置、ハードディスク等から構成される外部記憶装置、通信を行うためのＮＩＣ（Network Interface Card）を有するコンピュータと、ルータ（Router）を含んで構成される。
【００２９】
ＸＭＬパースモジュール（ＸＭＬパーサ）１１は、入力されるＸＭＬデータをパースして内部形式ＸＭＬデータ（ＳＡＸイベント）に変換し、データ抽出モジュール１３ヘ出力する。なお、パースとは、テキスト形式で記述されたＸＭＬデータを読み込んで、ＸＭＬのタグで指定された文書要素や属性等を解析する解析処理である（本発明においてはパースの手順等は特に限定するものではない）。ちなみに、ＸＭＬパースモジュール１１を通してＸＭＬデータを操作するためのＡＰＩ（Application Programming Interface）には、ＤＯＭ（Document Object Mode）とＳＡＸ（Simple API for XML）という２種類の標準インターフェースがある。本実施形態では、ＸＭＬパースモジュール１１は、後者のＳＡＸに対応している。なお、ＳＡＸに対応したＸＭＬパースモジュール１１は、ＸＭＬデータを順次シーケンシャルに読み込みつつ、ＸＭＬのタグ（開始タグ、終了タグ、空要素タグ）を検出するごとにアドインされた各種ハンドラを起動する。ここでハンドラとは、ＳＡＸインターフェースに基づいてＸＭＬデータの各要素を処理するためのメソッドを定義したプログラムである。また、タグとは、ＸＭＬデータにおいて、要素の位置を明示し、属性を収納するために記述される文字列である。
【００３０】
問い合わせパースモジュール１２は、追加される個人プロファイル（ＸＭＬ問い合わせ言語で記述される検索条件）をパース（解析処理）し、「データ変換操作」とデータ抽出操作である「ＸＰａｔｈ（ＸＰａｔｈ群・個々のＸＰａｔｈ）」とに分離する。ＸＰａｔｈはデータ抽出モジュール１３ヘ出力され、データ変換操作はデータ変換モジュール１６ヘ出力される。なお、ＸＰａｔｈ（XML Path Language）は、ＸＭＬデータの特定の部分を指し示す言語である。ＸＰａｔｈを利用すれば、ＸＭＬデータ中にアンカ等が埋め込まれていなくとも、データ中の任意の位置を指し示すことができる。
【００３１】
データ抽出モジュール１３は、問い合わせパースモジュール１２から入力される個々のＸＰａｔｈをＮＦＡに変換（ＮＦＡを生成）し、記憶装置１４に登録／追加する。更にデータ抽出モジュール１３は、ＸＭＬパースモジュール１１から入力されるＳＡＸイベントに応じて、ＮＦＡを用いて順次ＤＦＡを生成／更新する。そして、データ抽出モジュール１３は、ＤＦＡを用いて、入力されたＸＭＬデータから抽出された部分ＸＭＬを内部形式ＸＭＬデータ（フィルタされた後の内部形式ＸＭＬデータ）としてデータ変換モジュール１６ヘ出力する。
【００３２】
ちなみに、オートマトン（Automaton）とは、コンピュータ等の計算機構を数学的に表すモデルの総称であり、入力、出力、状態をもつ。このうち、ＤＦＡ（決定性オートマトン）は、入力に対する推移先（遷移先）が１つに決まるオートマトンである。一方、ＮＦＡ（非決定性オートマトン）は、ある状態において入力に対する推移先（遷移先）が複数存在するオートマトンである。
【００３３】
なお、データ抽出モジュール１３と記憶装置１４を含んで構成されるオートマトン管理部１５の詳細な機能は、図面を参照して後で詳細に説明する。
【００３４】
データ変換モジュール１６は、データ変換操作と抽出された内部形式のＸＭＬデータとから所定の変換を実行し、その結果をフィルタされたＸＭＬデータ（変換後ＸＭＬデータ）として出力する。なお、所定の変換は本発明においては特に限定するものではない。
【００３５】
次に、オートマトン管理部１５を詳細に説明する。
図３は、図２におけるオートマトン管理部１５のメモリ上でのデータ構成を示した図である。なお、ＤＦＡの詳細は図５に示す。
【００３６】
図３に示すように、個々のＸＰａｔｈごとにＮＦＡが生成される。こうして生成された複数のＮＦＡは１つのノードにより結合され、そのルートからイプシロンエッジにより個々のＮＦＡに接続される（結合ＮＦＡ）。なお、イブシロンエッジとは、例えばオートマトンにおいて通常定義される”空文字列”のことである。
ＤＦＡは、結合（統合）されたＮＦＡを用い、ＸＭＬデータの入力に応じて必要な状態を順次生成／更新する。
【００３７】
図４は、図３の具体的なプログラム上でのデータ構造を示す図である。この図４において、Ｖａｒｉａｂｌｅクラス（class Variable）は、個々のＸＰａｔｈごとにインスタンスを生成するクラスであり、次のような属性を有する。
＊そのインスタンスごとに異なる内部識別子である”ｉｄ”
＊個々のＸＰａｔｈ表現である”ｘｐａｔｈ”
＊Ｖａｒｉａｂｌｅを利用者が区別するための名称である”ｖａｒＮａｍｅ”なお、インスタンス（Instance）とは、例えばオブジェクト指向プログラミングにおいて、あるクラスの定義をひな型として実際に作られたオブジェクトのことをいう。
【００３８】
Ｓｔａｔｅクラス（class State）は、ＮＦＡの状態を表現するクラスであり、次のような属性を有する。
＊自身の状態から他の状態への推移を表現するエッジの集合”ｅｄｇｅｓ”
＊自身の状態が終端か非終端かを示す”ｔｙｐｅ”
なお、ＸＰａｔｈの表現をＮＦＡに変換した場合、最後尾の状態は終端であり、それ以外の状態は非終端であるとする。
＊自身の状態がどのＶａｒｉａｂｌｅインスタンスから（つまりそのｘｐａｔｈから）生成されたかを示す”ｖａｒ”
【００３９】
ＤＦＡＳｔａｔｅクラス（class DFAState）はＤＦＡの状態を表現し、Ｓｔａｔｅクラスをオブジェクト指向的な継承を用いて定義され、次のような属性を有する。
＊ＮＦＡを用いてＤＦＡを生成する際に必要になる、ＮＦＡの状態群を表現する”ｓｔａｔｅｓ”
＊ＸＰａｔｈの追加処理を高速化するため、自状態がどのＶａｒｉａｂｌｅインスタンスに相当するＸＰａｔｈまでを考慮して生成されたかを示すＶａｒｉａｂｌｅの最大ｉｄである”ｖａｒＩｄ”
このｖａｒＩｄが請求項の「状態フラグ」に相当し、ＤＦＡにおける各状態において、それが何件目のＸＰａｔｈまでの情報を元に更新されたかを表現する。
なお、ｅｄｇｅｓはＳｔａｔｅクラスのものを継承しているが、処理の高速化を図るため、ｌｉｓｔではなくｈａｓｈやｍａｐ構造を用いて再定義することも可能である。
【００４０】
Ｅｄｇｅクラス（class Edge）はＮＦＡの状態Ｓｔａｔｅ間のエッジ、もしくはＤＦＡの状態間のエッジを表現し、次のような属性を有する。
＊自身のエッジのエッジ先である状態”ｔｏ”
＊自身のエッジのエッジ元である状態”ｆｒｏｍ”
【００４１】
その他、大域的な変数として次の変数を利用する。
＊Ｖａｒｉａｂｌｅインスタンスのｉｄの払い出しをするため、最新に生成されたＶａｒｉａｂｌｅインスタンスのｉｄを表す”ｇＭａｘＶａｒＩｄ”
＊ＳＡＸイベントであるｅｎｄＥｌｅｍｅｎｔイベントを処理する際には、オートマトンの状態推移を戻す必要があり、結果としてオートマトンのルート状態から現状の状態までのパスを管理する必要がある。この状態リストを表す”ｓｔａｔｅＳｔａｃｋ”
＊本実施形態ではＸＰａｔｈの差分追加のため、現状入力したＳＡＸイベントまでに完了していない（つまりｓｔａｒｔＥｌｅｍｅｎｔを入力したがｅｎｄＥｌｅｍｅｎｔが未入力である）要素名リストを保有する。この要素名リストを表す”ｌａｂｅｌＳｔａｃｋ”
＊ＤＦＡのルート状態を表現する”ｒｏｏｔ”
＊ＤＦＡで現状の状態を表現する”ｃｕｒｒｅｎｔ”
【００４２】
図５は、図４のＤＦＡのメモリ上でのデータ構造を図示した図である。但し、この図５では図４と異なり、”ｅｄｇｅｓ”を実現するためにｌｉｓｔではなくｍａｐ構造を利用している。
【００４３】
この図５の左に位置するＤＦＡＳｔａｔｅはＤＦＡＳｔａｔｅクラスのインスタンスであり、ＤＦＡの１状態を表現している。この図５の状態ではその属性値であるｓｔａｔｅｓ，ｅｄｇｅｓ，ｔｙｐｅ，ｖａｒ，ｖａｒＩｄの値がそれぞれ設定されている。
ここで、ｓｔａｔｅｓはＮＦＡの状態群を表す。ｅｄｇｅｓはエッジのラベルとエッジインスタンスヘの参照の組を表現している。ｔｙｐｅは非終端であるので”ｎｏｎ−ｔｅｒｍｉｎａｌ”になっている。ｖａｒはＶａｒｉａｂｌｅインスタンスヘの参照である。この例では、ｖａｒＩｄは３であり、３番目のＶａｒｉａｂｌｅ（ＸＰａｔｈ）までの状態をこのＤＦＡＳｔａｔｅが反映していることを意味している。
【００４４】
図５の中間（左中間）に位置するのがＥｄｇｅのインスタンス群である。
また、図５の右中間に位置するのがＥｄｇｅの稚移先に相当するＤＦＡＳｔａｔｅインスタンス群である。なお、図５に示すように、Ｅｄｇｅの推移先はＮｕｌｌ（ＤＦＡＳｔａｔｅが未生成）であることも許されている。
【００４５】
〔処理フロー〕
図６〜図９は、本実施形態における処理フローの説明である。以下フローを参照して、本発明をより具体的に説明する。
【００４６】
図６はＸＰａｔｈ処理方法の全体の処理フローである。
一番上位のステップＳ１１の処理では、ｇＭａｘＶａｒＩｄ，ｓｔａｔｅＳｔａｃｋ，ｌａｂｅｌＳｔａｃｋを初期化する。なお、ｇＭａｘＶａｒＩｄにはＸＰａｔｈの件数が設定される。その次のステップＳ１２の処理では、初期登録された個々のＸＰａｔｈ（ＸＰａｔｈ群）からＮＦＡを生成し、オートマトン管理部１５（記憶装置１４）へ登録（更新）する。
【００４７】
その次のステップＳ１３の処理では、生成したＮＦＡ群を統合して結合ＮＦＡを生成する（図３の中段図参照）。また、ＤＦＡのルート状態も生成し、ｒｏｏｔＳｔａｔｅ，ｃｕｒｒｅｎｔに設定する。これらの設定はオートマトン管理部１５の記憶装置１４に記憶される。
【００４８】
その次の選択条件処理では、ＸＰａｔｈの追加要求の有無を判定している。具体的には、ステップＳ１４でＸＰａｔｈの追加要求がある場合は、ステップＳ１５でＸＰａｔｈの追加を受け付け、ステップＳ１６で”ＤＦＡ更新１”のサブルーチン処理を行う。”ＤＦＡ更新１”は図７に示される処理であるが、説明は後で行う。一方、ステップＳ１４でＸＰａｔｈの追加要求がない場合は、ステップＳ１７に移行する。
【００４９】
ステップＳ１７の選択条件処理では、入力ＸＭＬデータからのＳＡＸイベントを待っている。ステップＳ１８では、ＳＡＸイベントがある場合に、該ＳＡＸイベントがｅｎｄＥｖｅｎｔかｓｔａｒｔＥｖｅｎｔかを判断する。ＳＡＸイベントがｓｔａｒｔＥｖｅｎｔ（ｓｔａｒｔＥｌｅｍｅｎｔ，ｓｔａｒｔＤｏｃｕｍｅｎｔ）の場合は、該ＳＡＸイベントに対応する推移先の状態がＤＦＡにあるか否かを判断する（ステップＳ１９）。移動先の状態が未生成（Ｎｕｌｌ）の場合（ない場合、No）は、ステップＳ２０でＮＦＡを参照してＤＦＡの推移先の状態を生成する。さらにステップＳ２０では、状態フラグであるｖａｒＩｄに、ｇＭａｘＶａｒＩｄを設定する。これによりｖａｒＩｄは、ＤＦＡにおける各状態において、それが何件目のＸＰａｔｈまでの情報を元に更新されたかを表現する。これらは、オートマトン管理部１５の更新に反映される。そして、ステップＳ２３に移行する。
【００５０】
一方、ステップＳ１９で、ＳＡＸイベントに対応する推移先の状態がＤＦＡにある場合（生成済み、Yes）は、推移後のｓｔａｔｅのｖａｒＩｄがｇＭａｘＶａｒＩｄに等しいかを判断する（ステップＳ２１）。
【００５１】
また、ステップＳ２１で判断して等しくない場合（No）は、ステップＳ２２で”ＤＦＡ更新２”の処理を行ってからステップＳ２３に移行する。なお、”ＤＦＡ更新２”は図８に示される処理であるが、説明は後で行う。また、ステップＳ２１で判断して、ｖａｒＩｄとｇＭａｘＶａｒＩｄが等しい場合（Yes）は、そのままステップＳ２３に移行する。
【００５２】
ステップＳ２３では、ｃｕｒｒｅｎｔをｓｔａｔｅＳｔａｃｋにスタック（１件追加）し、ＳｔａｒｔＥｖｅｎｔのタグ名をｌａｂｅｌＳｔａｃｋにスタック（１件追加）し、ｃｕｒｒｅｎｔを推移後のＳｔａｔｅに設定する。また、必要に応じてＳＡＸイベントを出力する。そして、ステップＳ２５に移行して結果を出力する（内部形式ＸＭＬデータを出力）。
【００５３】
ところで、ステップＳ１８でＳＡＸイベントがｅｎｄＥｖｅｎｔ（ｅｎｄＥｌｅｍｅｎｔ，ｅｎｄＤｏｃｕｍｅｎｔ）の場合は、ステップＳ２４でｓｔａｃｋＳｔａｔｅをポップし、結果をｃｕｒｒｅｎｔに設定し、ｌａｂｅｌＳｔａｃｋをポップする。また、必要に応じてＳＡＸイベントを出力する。なお、ポップとは最後に追加したものを抽出することである。ステップＳ２４を処理した後は、ステップＳ２５に移行して結果を出力する（内部形式ＸＭＬデータを出力）。
【００５４】
そして、ステップＳ２６で終了か否かを判断して、終了でない場合（No）は、ステップＳ１４に移行して処理を継続する。終了である場合（Yes）は、Ｅｎｄに移行して処理を終了する。
【００５５】
図７は、前記した図６のステップＳ１６におけるサブルーチン”ＤＦＡ更新１”の処理フローである。
最初のステップＳ１６１の処理は、図６のフローチャートに示すように、ＸＰａｔｈの１件追加（新規ＸＰａｔｈの追加）であることからｇＭａｘＶａｒＩｄに１を追加してインクリメントする。次のステップＳ１６２の処理では、追加された新規ＸＰａｔｈ（追加されるＸＰａｔｈ）からＮＦＡを生成し、オートマトン管理部１５の結合ＮＦＡに追加（挿入）する。
【００５６】
次のステップＳ１６３の処理では、以降で用いるループ変数Ｉを初期化（Ｉ＝０）する。また、生成されたＮＦＡのルート状態を一時変数ｕｓｔａｔｅｓに設定し、ｒｏｏｔＳｔａｔｅのｓｔａｔｅｓにｕｓｔａｔｅｓを追加し、ｕｓｔａｔｅＳから発するエッジ（群）をｒｏｏｔＳｔａｔｅのｅｄｇｅｓに追加し、ｒｏｏｔＳｔａｔｅのｖａｒＩｄにｇＭａｘＶａｒＩｄを設定し、ｃｕｒｒｅｎｔにｒｏｏｔＳｔａｔｅを設定する。
【００５７】
次のステップＳ１６４の判定処理では、ループ変数ＩがｌａｂｅｌＳｔａｃｋ．ｓｉｚｅより小さいかどうか（未満かどうか）を判定する。小さい場合（Yes）は、ステップＳ１６５で該Ｉ番目の要素をｌａｂｅｌＳｔａｃｋから取り出し、ｓｔａｒｔイベント（ｓｔａｒｔＥｌｅｍｅｎｔ，ｓｔａｒｔＤｏｃｕｍｅｎｔ）を発生させる。
【００５８】
次のステップＳ１６６の判定処理では、発生したＳＡＸイベントにより推移する推移先の状態のｖａｒＩｄとｇＭａｘＶａｒＩｄの等価性を判断する。具体的には、両者が等しい場合は、ステップＳ１６８の処理に進む。等しくない場合は、ステップＳ１６７で、推移先の状態（ｓｔａｔｅｓ，ｅｄｇｅｓ，ＶａｒＩｄ）を下記のように更新する。
【００５９】
即ち、ステップＳ１６７では、一時変数ｎｅｗＳｔａｔｅｓにｔｒａｎｓｉｔ（ｓｔａｔｅｓ，推移先ｖａｒＩｄ，入力ＳＡＸイベント）の結果を設定する。ｔｒａｎｓｉｔの処理については図９を参照して説明する。このＳ１６７では、結果として、現状のＤＦＡの状態が更新される。
【００６０】
具体的には、推移先のｓｔａｔｅｓにｎｅｗＳｔａｔｅｓを追加する。推移先のｅｄｇｅｓにｇｅｔＥｄｇｅｓ（ｎｅｗＳｔａｔｅｓ）の結果を追加する。推移先のｖａｒＩｄにｇＭａｘＶａｒＩｄを設定する。これは推移先の状態が更新完了であることを意味する。ちなみに、ｇｅｔＥｄｇｅｓは、パラメータｎｅｗＳｔａｔｅｓに接続される全てのエッジ群を抽出する関数である。
【００６１】
次のステップＳ１６８の処理では、ｃｕｒｒｅｎｔをｓｔａｔｅＳｔａｃｋにスタックし、タグ名をｌａｂｅｌＳｔａｃｋにスタックし、ｃｕｒｒｅｎｔを推移後の状態に設定する。
【００６２】
次のステップＳ１６９の処理では、ループ変数Ｉをインクリメントし、ステップＳ１６４のループ判定の判定処理に戻る。ステップＳ１６４で、ループ変数ＩがｌａｂｅｌＳｔａｃｋ．ｓｉｚｅ以上の場合（No）は、処理を柊了し図６のステップＳ１６に戻る（Return，ステップＳ１７０）。
【００６３】
図８は、前記した図６のステップＳ２２におけるサブルーチン”ＤＦＡ更新２”の処理を示したフローである。
図８の処理では、推移先の状態のｓｔａｅｓ、ｅｄｇｅｓ，ｖａｒＩｄを更新する。即ち、一時変数ｎｅｗＳｔａｔｅｓにｔｒａｎｓｉｔ（ｓｔａｔｅｓ，推移先ｖａｒＩｄ，入力ＳＡＸイベント）の結果を設定する。ｔｒａｎｓｉｔの処理については図９を参照して説明する。この”ＤＦＡ更新２”では、結果として現状のＤＦＡの状態を更新する。
【００６４】
具体的には、”ＤＦＡ更新２”では、推移先のｓｔａｔｅｓにｎｅｗＳｔａｔｅｓを追加する。推移先のｓｔａｔｅｓのエントリの重複排除をする。推移先のｅｄｇｅｓにｇｅｔＥｄｇｅｓ（ｎｅｗＳｔａｔｅｓ）の結果を追加する。推移先のｖａｒＩｄにｇＭａｘＶａｒＩｄを設定する。これは推移先の状態が更新完了であることを意味する。ちなみに、ｇｅｔＥｄｇｅｓは、パラメータｎｅｗＳｔａｔｅｓに接続される全てのエッジ群を抽出する関数である。
【００６５】
図９は、図７及び図８に用いられている関数ｔｒａｎｓｉｔの処理を示したフローを示す図である。
図９のフローにおけるステップＳ４１での入力（パラメータ）は、ｓｔａｔｅｓ（ＮＦＡの状態群），ＶａｒＩｄ（Ｖａｒｉａｂｌｅインスタンスの属性ｉｄ値），入力ＳＡＸイベントの３つである。
【００６６】
次のステップＳ４２では、ループ変数Ｉを初期化（Ｉ＝０）し、演算結果格納領域ｒｓｔａｔｅｓを初期化する。次のステップＳ４３の判定処理では、ループ変数Ｉがｓｔａｔｅｓ．ｓｉｚｅより小さいかどうかを判定する。Ｉがｓｔａｔｅ．ｓｉｚｅより小さい場合（Yes）は、ステップＳ４４でＩ番目の要素をｓｔａｔｅｓから取り出して一時変数ｓｔａｔｅに設定し、その属性ｖａｒを一時変数ｖｖａｒに設定する。
【００６７】
次のステップＳ４５の判定処理では、ｖｖａｒのｉｄが推移先ｖａｒＩｄより大きいかどうか判定する。ｖｖａｒのｉｄが推移先ｖａｒＩｄを超える場合（Yes）は、ステップＳ４６のように、入力ＳＡＸイベントによりｓｔａｔｅから推移できるＮＦＡの状態を全てｒｓｔａｔｅｓに追加し、ステップＳ４７の処理に進む。一方、ｖｖａｒのｉｄが推移先ｖａｒＩｄ以下の場合（No）は、そのままステップＳ４７の処理に進む。
【００６８】
次のステップＳ４７の処理では、ループ変数Ｉをインクリメントし、ステップＳ４３に移行してループの判定条件に戻る。ステップＳ４３では、ループ変数Ｉがｓｔａｔｅｓ．ｓｉｚｅより小さくない場合（No）は、ｔｒａｎｓｉｔ関数を終了し、ｒｅｓｔａｔｅｓを返却する。つまり、図７及び図８のＮｅｗＳｔａｔｅｓに代入される。
【００６９】
〔動作に対応したオートマトン管理部の状態〕
次に、本実施形態のＸＰａｔｈ処理方法の動作例をより具体的に説明する。
図１０〜図１４は、ＸＰａｔｈ処理方法の動作例を説明するために引用した図である。このうち、図１０はＸＰａｔｈ処理方法の動作の時点を示す図である。図１１〜図１４はそれぞれの時点において変化するオートマトン管理部の内部の様子を例示する。
【００７０】
まず図１０では、本実施形態でのＸＰａｔｈ処理方法における次の１．〜４．の４つの動作の時点を示している。
１．２つのＸＰａｔｈ”／ａ／ｂ”，”／ａ／／ｃ”が登録された時点
２．その後ＸＭＬを途中（＜ａ＞＜ｂ＞＜ｃ／＞＜ｄ＞）まで入力した時点
３．ＸＰａｔｈ”／ａ／／ｄ”を追加した時点
４．その後ＸＭＬの入力を継続（ｔｅｓｔ＜／ｄ＞＜／ｂ＞＜ｄ／＞＜／ａ＞）した時点
【００７１】
図１１は、図１０の１．の時点におけるオートマトン管理部の内部の様子を例示した図である。この図１１の上段図に示すように、ＸＰａｔｈは、”／ａ／ｂ”と”／ａ／／ｃ”の２件が登録されている。ＸＰａｔｈは、前記したとおり、問い合わせパースモジュール１２により個人プロファイルから分離・生成される（図２参照）。
【００７２】
図１１の中段図のＮＦＡは、ルートノードに上段図の２件のＸＰａｔｈが変換されて接続されたＮＦＡ（結合ＮＦＡ）が図示されている。この中段図では７個の状態とそれらを接続する６個のエッジが図示されている。ここで二重の円は終端の状態を示し、一重の円は非終端の状態を示している。矢印はエッジであり、それぞれ受理するタグを示している。また、εはイブシロン推移を示し、＊は任意のタグであり、それ以外の（ａ，ｂ，ｃ）はタグ名自身を示している。
【００７３】
図１１の下段図のＤＦＡは、ルートノードが生成されており、ＮＦＡの状態群として｛０，１，４｝が設定されている。これはＮＦＡのルート状態０からイブシロン推移により推移可能なＮＦＡの状態群に相当する。また｛０，１，４｝に接続されるエッジはａのみであるため、エッジとしてａが生成され、推移先はｎｕｌｌになっている。なお、ＤＦＡにおける状態の上部に”２”とあるが、これは状態フラグであるｖａｒＩｄを示している。ここでは、上段図に示すようにＸＰａｔｈの件数が２なので、ｖａｒＩｄは２と設定されている。
【００７４】
図１２は、図１０の２．の時点におけるオートマトン管理部の内部の様子を例示している。図１１との違いは下段図のＤＦＡの部分であり、図１０の２．に示すようにＸＭＬの入力＜ａ＞＜ｂ＞＜ｃ／＞＜ｄ＞により必要なＤＦＡの状態とエッジが生成されている。
【００７５】
ＤＦＡのルート状態におけるＮＦＡの状態群｛０，１，４｝からＸＭＬの入力＜ａ＞により稚移可能なＮＦＡの状態群は｛２，５｝であるので、ＤＦＡの状態を生成する。また、この｛２，５｝に接続するエッジ群は｛ｂ，ｃ，＊｝であることからエッジとして｛ｂ，ｃ，ｏｔｈｅｒ｝を生成し、ＤＦＡの状態に接続する。推移先は、最初はｎｕｌｌとしておく。
【００７６】
同様にＸＭＬの入力＜ｂ＞＜ｃ／＞＜ｄ＞により適宜ＤＦＡの状態とエッジを生成する。具体的には、入力＜ｂ＞により推移可能なＮＦＡの状態は｛３，５｝であるので、ＤＦＡの状態を生成する。また、この｛３，５｝に接続するエッジ群は｛ｃ，＊｝であることからエッジとして｛ｃ，ｏｔｈｅｒ｝を生成し、ＤＦＡの状態に接続する。推移先は、最初はｎｕｌｌとしておく。次に、入力＜ｃ／＞、入力＜ｄ＞と順々に処理してゆく。
【００７７】
図１３は、図１０の３．の時点におけるオートマトン管理部の内部の様子を例示している。図１３の上段図では、図１０の３．に示すように、ＸＰａｔｈとして”／ａ／／ｄ”が１件追加されている。図１３の中段図では、この追加されるＸＰａｔｈ”／ａ／／ｄ”に対応するＮＦＡが追加されている。具体的には、状態７，８，９とそれらに関するエッジ群である。
【００７８】
図１３の下段図のＤＦＡでは、図６〜図９の処理フローに従い更新、つまりこれまでに生成されているＤＦＡに対して、追加されるＸＰａｔｈの情報を差分追加する処理が実行される。
【００７９】
まず、ＤＦＡのルート状態のｓｔａｔｅｓに、追加されたＸＰａｔｈのＮＦＡのルート状態７が追加される。また、処理されるＸＰａｔｈが３件目であることから、状態フラグであるｖａｒＩｄを３にインクリメントする。
【００８０】
この時点でｌａｂｅｌＳｔａｃｋに｛ａ，ｂ，ｄ｝がスタックされているため、ＤＦＡのルート状態からａ，ｂ，ｄの順にＳＡＸイベントを生成して推移させる。まず、ａにより次の状態を更新し推移する。こうしてｓｔａｔｅｓに８が追加され｛２，５，８｝になり、エッジとしてｄが追加されている。
次にｂにより次の状態を更新し准移する。こうしてｓｔａｔｅｓに８が追加され｛３，５，８｝になり、エッジとしてｄが追加されている。
【００８１】
次に、ｄにより次の状態を更新し推移する。こうして、図１３の下段図に示すように、ｓｔａｔｅｓに５，８，９が追加され｛５，８，９｝になる。これら更新されたＤＦＡにおける状態のｖａｒＩｄは、全て３にインクリメントされる。
【００８２】
図１４は、図１０の４．の時点のオートマトン管理部の内部の様子を例示している。この図１４では、前の状態を示す図１３に対して、ＤＦＡにはエッジｄが１つ追加されている。
【００８３】
以上説明したＸＰａｔｈ処理方法では、ＸＰａｔｈが追加された際に、それを変換してＮＦＡを生成し、そのルートノードヘ、既存のＮＦＡのルートノードからイプシロンエッジを設定する。そして、予め保持しておいたＸＭＬのルートタグから現在処理中のタグまでの全ての開始タグを順にＤＦＡに入力することによって、順次、ＤＦＡの状態を更新する。つまり、追加されるＸＰａｔｈの情報を既存のＤＦＡに差分追加する。従って、１つのＤＦＡを更新することにより、複数のＤＦＡが生成されてしまう既存技術と比較して、メモリ空間を効率的に使用することが可能となる。ちなみに従来は、図１２を例にすると、ＸＰａｔｈの追加があると、追加されたＸＰａｔｈ”／ａ／／ｄ”に対応する新たなＤＦＡが、既にあるＤＦＡとは別に生成され、メモリ空間を圧迫したが、本発明ではそのように重複してＤＦＡが生成されることはない。
【００８４】
この際、ＤＦＡにおける各状態において、それが何件目のＸＰａｔｈまでの情報を元に更新されたかを表現する状態フラグｖａｒＩｄを用いて処理を行うので、ＸＰａｔｈの追加処理（既存のＤＦＡに対して追加されるＸＰａｔｈの情報の差分追加）を、確実かつ高速に行うことができる。
【００８５】
また、図６、図７、図１３、図１４等に示すように、ＤＦＡにおける状態推移を行う際、現在のＤＦＡにおける各状態の状態フラグｖａｒＩｄをチェックし、その状態が、最新のＸＰａｔｈを元に更新されていない場合は、状態フラグｖａｒＩｄを用いてその状態が更新された後に追加されたＸＰａｔｈを特定し、該特定したＸＰａｔｈに対応するＮＦＡの状態を用いてＤＦＡを更新するので、メモリ空間の有効活用を図れると共に、ＸＰａｔｈの追加処理を、確実かつ高速に行うことができる。
【００８６】
また、本実施形態では、現状入力したＳＡＸイベントまでに完了していない（ｓｔａｒｔＥｌｅｍｅｎｔを入力したがｅｎｄＥｌｅｍｅｎｔが未入力の）要素名リストであるｌａｂｅｌＳｔａｃｋを保有する。このため、ＸＰａｔｈの追加処理を、確実かつ高速に行うことができる。
【００８７】
なお、本発明は上記した実施形態に限定されることなく、幅広く変形実施することができる。例えば、ＮｅｗｓＭＬは一例でありＸＭＬデータがＮｅｗｓＭＬに限定されることはない。例えば、ＸＭＬデータがＮＩＴＦ（News Industry Text Format）データ等でもよい。また、フィルタエンジン１０は、例えばＡＳＰ（Application Service Provider）が企業や個人ユーザのために設置したり、企業や団体等が自社の社員や構成員等のために設置したりする。また、上記実施形態で示したＤＦＡに対するＸＰａｔｈの情報の差分追加の手段・手法は一例であり、本発明が前記実施形態で示した差分追加の手段・手法に限定されることはない。また、前記したフローなどは、ＸＰａｔｈ処理プログラムとしてネットワーク上を伝送されたり、ＣＤ−ＲＯＭ等の記憶媒体に記憶されて流通されたりする。
【００８８】
【発明の効果】
以上説明した本発明によれば、以下に例示するような優れた効果を奏する。
即ち、本発明によれば、既存のＤＦＡを利用するのでコンピュータのメモリ空間を効率的に使用することができる。また、確実にＤＦＡに対するＸＰａｔｈの情報の差分追加を行え、また、さらに効率的にメモリ空間を使用することができる。また、追加（更新）すべき部分を特定してムダなく確実に差分追加を行うことができる。よって、さらに効率的にメモリ空間を使用することができる。また、より確実に差分追加を行うことができる。よって、さらに効率的にメモリ空間を使用することができる。また、追加すべき部分（更新すべき部分）を、さらにムダなく確実に差分追加を行うことができる。よって、さらに効率的にメモリ空間を使用することができる。
【００８９】
また、本発明によれば、追加のＸＰａｔｈの情報が既存のＤＦＡに差分追加されるだけですむので、複数のＤＦＡを生成する必要がない。よって、コンピュータのメモリ空間の有効活用が図れる。また、本発明によれば、より確実に差分追加を行うことができる。よって、さらに効率的にメモリ空間を活用することができる。
【００９０】
また、本発明のＸＰａｔｈ処理プログラム及びそのプログラムを記憶した記憶媒体は、このプログラムをインストールされたコンピュータにプログラムに基づいた各ステップを実行させ、ＸＰａｔｈの情報の差分追加を行う。よって、コンピュータのメモリ空間の有効活用を行うことができる。
【図面の簡単な説明】
【図１】    本発明の実施形態に係るＸＰａｔｈ処理方法が適用されるフィルタエンジンの概要を示す図である。
【図２】    図１のフィルタエンジンの内部構成を示すブロック図である。
【図３】    図２におけるオートマトン管理部のメモリ上でのデータ構成を示した図である。
【図４】    図３の具体的なプログラム上でのデータの構造を示す図である。
【図５】    図４のＤＦＡのメモリ上でのデータ構成を示した図である。
【図６】    ＸＰａｔｈ処理方法の全体の処理フローである。
【図７】    図６のサブルーチンＤＦＡ更新１の処理フローである。
【図８】    図６のサブルーチンＤＦＡ更新２の処理フローである。
【図９】    図７及び図８に用いられている関数ｔｒａｎｓｉｔの処理を示したフローである。
【図１０】  本発明の実施形態に係るＸＰａｔｈ処理方法の動作の時点を示す図である。
【図１１】  図１０の１．の時点におけるオートマトン管理部の内部の様子を例示した図である。
【図１２】  図１０の２．の時点におけるオートマトン管理部の内部の様子を例示した図である。
【図１３】  図１０の３．の時点におけるオートマトン管理部の内部の様子を例示した図である。
【図１４】  図１０の４．の時点におけるオートマトン管理部の内部の様子を提示した図である。
【符号の説明】
１０…  フィルタエンジン（ＸＰａｔｈ処理装置）
１１…  ＸＭＬパースモジュール
１２…  問い合わせパースモジュール
１３…  データ抽出モジュール
１４…  記憶装置
１５…  オートマトン管理部
１６…  データ変換モジュール
【図１】
0003968749.tif 000002
【図２】
0003968749.tif 000003
【図３】
0003968749.tif 000004
【図４】
0003968749.tif 000005
【図５】
0003968749.tif 000006
【図６】
0003968749.tif 000007
【図７】
0003968749.tif 000008
【図８】
0003968749.tif 000009
【図９】
0003968749.tif 000010
【図１０】
0003968749.tif 000011
【図１１】
0003968749.tif 000012
【図１２】
0003968749.tif 000013
【図１３】
0003968749.tif 000014
【図１４】
0003968749.tif 000015