(57)【特許請求の範囲】
【請求項１】
クライアント端末からの要求の処理において、同処理を構成する各処理工程を表すためのステートを、遷移順に記憶したステート定義ファイルを参照するステップと、
標準機能のための標準ステートに対する処理関数を記憶した標準モジュールと、拡張機能のための拡張ステートに対する処理関数を記憶した拡張モジュールとから、前記ステート定義ファイルで参照されたステートに一致するエントリを選択するステート選択ステップと、
選択されたエントリに従い、各ステートに対応した処理関数とその処理の遷移状態を記憶したステート遷移テーブルを、起動時に生成するステート遷移テーブル生成ステップと、生成された前記ステート遷移テーブルに従って、各ステート毎に定義された処理関数の処理を実行するステップと
を含むプロキシ処理方法。
【請求項２】
クライアント端末からの要求の処理状態を管理するセッション管理テーブルに、前記標準ステートの処理を実行するために必要な標準領域を確保するステップと、前記拡張ステートの環境設定関数の処理を実行することにより、各セッション対応の固有情報を保持するための、拡張ステートの処理で必要となる拡張領域を確保するステップとをさらに含む請求項１に記載のプロキシ処理方法。
【請求項３】
前記セッション管理テーブルの拡張領域に記憶された拡張ロギング情報に従い、クライアント要求及び／又はサーバ応答に関するロギング処理を実行するステップをさらに含む請求項２に記載のプロキシ処理方法。
【請求項４】
オブジェクトを示すモジュール名に対応して同モジュールで提供する処理ステートの一覧を示すステートリスト情報が記憶されたモジュールテーブルを有し、該ステートリスト情報は、ステート名に対応してステート識別子、処理関数及び初期化及びワーク領域確保のための関数、終了処理関数を記憶し、前記ステート選択ステップは、前記ステート定義ファイルに記述されたステート名に従い、前記モジュールテーブルのステートリスト情報の中から該当するステートのステートリスト情報エントリを選択することを特徴とする請求項１に記載のプロキシ処理方法。
【請求項５】
前記ステート遷移テーブルは、ステート識別子に対応して、ステート名、処理関数、作業領域の確保などを行う環境設定関数、セッション開始時のセッション初期化関数、セッション終了時のセッション終了関数、次ステートを含むことを特徴とする請求項１に記載のプロキシ処理方法。
【請求項６】
請求項１記載のプロキシ処理方法であって、
前記ステート遷移テーブル生成ステップは、
クライアント端末からの要求の処理を構成する各処理工程を表すためのステートを遷移順に記憶した前記ステート定義ファイルから、順次ステート名を読出すステップと、
ステート名に対応してステート識別子、処理関数及び作業領域の確保などを行う環境設定関数、セッション開始時のセッション初期化関数、セッション終了時のセッション終了関数を保持したステートリスト情報を記憶したモジュールテーブルから、読出されたステート名を持つステート情報リストエントリを検索するステップと、
検索されたステート情報リストエントリの情報を、前記ステート遷移テーブルに設定するステップと、
前記ステート定義ファイルの順序に従い、設定した各ステート遷移テーブルエントリの次ステート情報を該定義ファイル順の次ステート遷移テーブルエントリに設定するステップを含むプロキシ処理方法。
【請求項７】
検索されたステート情報リストエントリに、ステート識別子が定められていない場合は、一意的な識別子を生成して割当て、一方、ステート識別子が定められている場合、すでに同識別子に対応した前記ステート遷移テーブルにエントリが設定されていないか確認し、２重割当てを検出するステート識別子設定ステップをさらに含む請求項６に記載のプロキシ処理方法。
【請求項８】
ステート遷移テーブルエントリにステート初期化処理関数又は終了処理関数が設定されている場合、セッション初期化処理関数リスト又は終了処理関数リストに登録するステップをさらに含む請求項６に記載のプロキシ処理方法。
【請求項９】
請求項１記載のプロキシ処理方法であって、
１つの処理プロセスにより、複数のクライアントからの要求を同時に処理し、各要求の受付けから要求処理終了までを１つのセッションとして管理し、各セッションの処理状態をセッション管理テーブルに保持して、セッションスケジューラにより、動作可能な状態になった各クライアントのセッションをスケジューリングすると共に、
前記セッションスケジューラは、要求・応答データ受信などのレディー状態のイベントをチェックするステップと、レディ状態のイベントが発生又は到着した場合、動作可能になったセッションの中から動作可能となったセッションのセッション管理テーブルエントリを１つ選択するステップと、選択したセッション管理テーブルエントリとイベント情報をパラメータとしてステート遷移エンジンを実行するステップを含み、該ステート遷移エンジンは、クライアント端末からの要求の処理を構成する各処理工程を表すステートの遷移順を示した前記ステート遷移テーブルを参照し、前記セッション管理テーブルに保持された現行のステート情報から対応するステート遷移テーブルエントリの処理関数の処理を順次実行するステップと
を含むプロキシ処理方法。
【請求項１０】
前記セッションスケジューラが、定期的に各セッションのタイムアウトチェックを行うステップをさらに含む請求項９に記載のプロキシ処理方法。
【請求項１１】
コネクション確立時にステート遷移テーブル構築時に得られたセッション初期化関数を実行するステップと、セッションを終了する際に、セッション終了関数を実行するステップをさらに含む請求項９に記載のプロキシ処理方法。
【請求項１２】
前記セッション管理テーブルに対して、クライアント端末からの各セッションに対応して、ステート情報及び標準の各種情報に加え、さらに、前記拡張モジュールに固有の拡張情報を含む情報を保持し、該拡張モジュールの拡張ステートによる環境設定関数に従い、起動時にモジュール固有拡張情報のための領域を確保するステップをさらに含む請求項９に記載のプロキシ処理方法。
【請求項１３】
前記セッション管理テーブル中の標準情報及び拡張情報に従い、クライアント要求及び／又はサーバ応答に関するロギング処理を実行するステップをさらに含む請求項１２に記載のプロキシ処理方法。
【請求項１４】
前記ステート遷移エンジン処理は、クライアント端末からの各セッションに対応して、ステート情報、標準情報、モジュールに固有の拡張情報を含む情報を保持する前記セッション管理テーブルを参照するステップと、前記セッション管理テーブルのステート情報により、各ステートに対応した処理関数とその処理の遷移状態を記憶した前記ステート遷移テーブルを参照し、ステート遷移テーブルエントリを取得するステップと、取得したステート遷移テーブルエントリの処理関数を実行するステップと、実行した処理関数からのリターン値により次の遷移ステート求め、次ステート情報をセッション管理テーブルエントリに設定するステップとを含む請求項９に記載のプロキシ処理方法。
【請求項１５】
請求項９記載のプロキシ処理方法であって、
前記ステート遷移エンジンは、
起動されるステップと、
クライアント端末からの各セッションに対応して、ステート情報、標準情報、拡張モジュールに固有の拡張情報を含む情報を保持するテーブルである前記セッション管理テーブルを参照するステップと、
前記セッション管理テーブルのステート情報により、各ステートに対応した処理関数とその処理のデフォルトの遷移先を記憶した前記ステート遷移テーブルを参照し、ステート遷移テーブルエントリを取得するステップと、
取得したステート遷移テーブルエントリの処理関数を実行するステップと、
実行した処理関数からのリターン値により次の遷移ステート求め、次ステート情報をセッション管理テーブルエントリに設定するステップを有し、
前記リターン値が第１のリターン値でない場合は、次のステートの処理を実行し、前記第１のリターン値である場合は、前記セッションスケジューラに戻って別の動作可能なセッションのスケジュールを前記セッションスケジューラに要求するステップを含むプロキシ処理方法。
【請求項１６】
前記リターン値が第２のリターン値の場合、デフォルトの次ステートに遷移するステップと、第３のリターン値の場合、所定フィールドで指定されたステートに遷移するステップと、第４のリターン値の場合、エラー情報返信ステートに遷移するステップと、第５のリターン値の場合、セッション終了関数を実行し、セッション管理テーブルエントリを解放して現行セッションを終了して前記セッションスケジューラに戻るステップのいずれか又は複数のステップをさらに含む請求項１５に記載のプロキシ処理方法。
【請求項１７】
請求項１記載のプロキシ処理方法であって、
ロギングすべきログタイプを記憶した拡張ロギング定義ファイルに基づき、起動時に拡張ロギング定義ファイルの定義情報をローディングするステップと、
クライアント端末からの要求の処理状態を管理するセッション管理テーブルに、該定義情報に従った拡張ロギング情報を保持するステップと、
該定義情報に従って、拡張情報を含むロギングを実行するステップとを含むプロキシ処理方法。
【請求項１８】
クライアントからの要求の処理をロギングするためのアクセスロギングにおいて、該アクセスロギングの各ロギングデータを固定長標準ログ領域と可変長／拡張ログ領域で構成し、当該ロギングデータのログレコード長及び固定長標準ログ情報を、固定長標準ログ領域に記憶するステップと、可変長領域サイズ及び拡張ロギング定義ファイルの定義情報に従った各拡張ロギングデータの出力場所を示すオフセット情報と各拡張ロギングデータとを、可変長／拡張ログ領域に記憶するステップとを含み、ロギングを実行するためのアクセスログを生成し、生成されたアクセスログを参照してロギング解析・集計処理を実行する請求項１７に記載のプロキシ処理方法。
【請求項１９】
アクセスログの解析・集計処理において、固定長標準情報の解析・集計は、アクセスログの固定長標準ログ領域を参照して、解析・集計を行うステップと、可変長／拡張ログ情報の解析・集計は、アクセスログの可変長／拡張ログ領域を参照して、所望の可変長／拡張ログ情報のオフセット情報を取り出し、得られたオフセット情報により可変長／拡張ロギングデータをアクセスして可変長／拡張ログデータを解析・集計するステップとをさらに含む請求項１８に記載のプロキシ処理方法。
【請求項２０】
ログヘッダには、ｅｎｄｉａｎ情報、統計サマリー情報、拡張ログ定義情報のコピーのいずれか又は複数を記憶するステップをさらに含む請求項１８に記載のプロキシ処理方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、プロキシ処理方法に係り、特に、柔軟な機能拡張及びロギングを可能トするプロキシ処理方法に関する。ここで、プロキシ処理とは、例えば、クライアント端末からのＷｅｂアクセス要求等の要求をサーバに中継する処理、及び、認証、アクセスロギング、キャッシング、課金、付加価値サービス等の各処理をいう。
【０００２】
【従来の技術】
以下に、従来のプロキシ処理の概要について説明する。
図１９に、従来のプロキシ処理についての説明図を示す。
プロキシ装置２０は、クライアント端末１０から要求を受信する。要求には、要求ヘッダ及びコンテンツデータが含まれる。要求ヘッダには、例えば、ＵＲＬ，ブラウザ情報、固有要求情報、固有ユーザ情報等が含まれる。コンテンツデータは、例えば、ユーザ名、住所等、ＷｅｂのＰＯＳＴデータ等を含むことができる。プロキシ装置２０は、受信した要求をＷｅｂサーバ４０に送信する。Ｗｅｂサーバ４０は、要求に応じて、応答を返送する。応答には、応答ヘッダ及びコンテンツデータが含まれる。応答ヘッダは、終了情報（異常、正常）、サーバ情報、コンテキストタイプ、コンテキスト長、固有応答情報等を含む。プロキシ装置２０は、また、固定の課金処理や固定情報のアクセスログを実行する。
【０００３】
【発明が解決しようとする課題】
しかしながら、従来は、固定のプロキシ処理しか実行することができず、固有の機能を拡張することは困難であった。また、従来は、アクセスロギング情報は固定の情報（固定のヘッダフィールド）のみであり、固有の拡張情報やヘッダフィールドを選択してロギングすることは不可能であった。
【０００４】
本発明の目的のひとつは、以上の点に鑑み、ユーザ認証や課金等のように、固有の拡張処理を柔軟に追加・変更することができるプロキシ処理方法を提供することにある。また、本発明の目的の他のひとつは、固有拡張情報やヘッダフィールド等を選択することにより、柔軟なロギングを実現することを目的とする。
【０００５】
【課題を解決するための手段】
本発明の第１の解決手段によると、
クライアント端末からの要求の処理を構成する各処理工程を表すためのステートを、遷移順に記憶したステート定義ファイルを参照するステップと、
標準機能のための標準ステートに対する処理関数を記憶した標準モジュールと、拡張機能のための拡張ステートに対する処理関数を記憶した拡張モジュールとから、ステート定義ファイルで参照されたステートに一致するエントリを選択するステップと、
選択されたエントリに従い、各ステートに対応した処理関数とその処理の遷移状態を記憶したステート遷移テーブルを、起動時に生成するステップと、
生成されたステート遷移テーブルに従って、各ステート毎に定義された処理関数の処理を実行するステップと
を含むプロキシ処理方法が提供される。
【０００６】
本発明の第２の解決手段によると、
クライアント端末からの要求の処理を構成する各処理工程を表すためのステートを遷移順に記憶したステート定義ファイルから、順次ステート名を読出すステップと、
ステート名に対応してステート識別子、処理関数、作業領域の確保などを行う環境設定関数、セッション開始時のセッション初期化関数、セッション終了時のセッション終了関数を含むステート情報リストを記憶したモジュールテーブルから、読出されたステート名を持つステート情報リストエントリを検索するステップと、
検索されたステート情報リストエントリを、ステート遷移テーブルに設定するステップと、
ステート定義ファイルの順序に従い、設定した各ステート遷移テーブルエントリの次ステート情報を該定義ファイル順の次ステート遷移テーブルエントリに設定するステップ
を含むプロキシ処理方法が提供される。
【０００７】
本発明の第３の解決手段によると、
１つの処理プロセスにより複数のクライアントからの要求を同時に処理するプロキシ処理方法において、各要求の受付けから要求処理終了までを１つのセッションとして管理し、各セッションの処理状態をセッション遷移テーブルに保持して、
セッションスケジューラにより、動作可能な状態になった各クライアントのセッションのスケジューリングするプロキシ処理方法であって、
セッションスケジューラは、要求・応答データ受信などのレディー状態のイベントをチェックするステップと、
レディ状態のイベントが発生又は到着した場合、動作可能になったセッションの中から動作可能となったセッションのセッション管理テーブルエントリを１つ選択するステップと、
選択したセッション管理テーブルエントリとイベント情報をパラメータとして、ステート遷移エンジンを実行するステップを含み、該ステート遷移エンジンは、クライアント端末からの要求の処理を構成する各処理工程を表すためのステートの遷移順を示したステート遷移テーブルを参照し、セッション管理テーブルに保持された現行ステート情報から対応するステート遷移テーブルエントリの処理関数の処理を順次実行するステップと
を含むプロキシ処理方法が提供される。
【０００８】
本発明の第４の解決手段によると、
クライアント端末からの要求の処理を構成する各処理工程を表すためのステートの状態を保持して、ステートを遷移しながら、ステートに対応する処理関数の処理を順次実行するためのステート遷移エンジンによる処理を含むプロキシ処理方法であって、
ステート遷移エンジンが起動されるステップと、
ステート遷移エンジンは、クライアント端末からの各セッションに対応して、ステート情報、標準情報、拡張モジュールに固有の拡張情報を含む情報を保持するテーブルであるセッション管理テーブルを参照するステップと、
ステート遷移エンジンは、セッション管理テーブルのステート情報により、各ステートに対応した処理関数とその処理のデフォルトの遷移先を記憶したステート遷移テーブルを参照し、ステート遷移テーブルエントリを取得するステップと、
ステート遷移エンジンは、取得したステート遷移テーブルエントリの処理関数を実行するステップと、
ステート遷移エンジンは、実行した処理関数からのリターン値により次の遷移ステート求め、次ステート情報をセッション管理テーブルエントリに設定するステップと、
リターン値が予め定められた第１のリターン値でない場合は、次のステートの処理を実行し、第１のリターン値である場合は、スケジューラに戻って別の動作可能なセッションのスケジュールをスケジューラに要求するステップ
を含むプロキシ処理方法が提供される。
【０００９】
本発明の第５の解決手段によると、
クライアント端末からの要求の処理をロギングするためのアクセスロギングにおいて、該アクセスロギングの各ロギングデータを固定長標準ログ領域と、可変長／拡張ログ領域で構成し、
ロギングすべきログタイプを記憶した拡張ロギング定義ファイルに基づき、起動時に拡張ロギング定義ファイルの定義情報をローディングするステップと、
クライアント端末からの要求の処理状態を管理するセッション管理テーブルに、該定義情報に従った拡張ロギング情報を保持するステップと、
固定長標準ログを固定長標準ログ領域に出力すると共に、該定義情報に従って、拡張情報を可変長／拡張ログ領域に出力するロギングを実行するステップと
を含むプロキシ処理方法が提供される。
【００１０】
【発明の実施の形態】
１．プロシキ装置によるＨＴＴＰセッション処理
以下に、本実施の形態に関連するＨＴＴＰセッション処理（クライアントからの要求処理）の概要について説明する。
図１に、一般的なＷｅｂキャッシングプロキシ処理の流れについての説明図を示す。
このシステムは、Ｗｅｂクライアント１、Ｗｅｂキャッシングプロキシ２、キャッシュ３、Ｗｅｂサーバ４を備える。各ＷｅｂクライアントからのＷｅｂアクセス要求に対するＷｅｂキャッシングプロキシでの処理は、一般的に図示のように、以下のステップの処理となる。なお、図中丸数字は、次のかっこで示す各ステップに相当する。
【００１１】
（１）Ｗｅｂクライアント１からの要求に従い、Ｗｅｂクライアント１とＷｅｂキャッシングプロキシ２との間で要求コネクションを設定し、同クライアント端末とのＨＴＴＰセッションを開始する。
（２）Ｗｅｂキャッシングプロキシ２は、要求を受付ける。
（３）Ｗｅｂキャッシングプロキシ２は、要求を解析する。
（４）Ｗｅｂキャッシングプロキシ２は、キャッシュ３が存在するかチェックする。
【００１２】
ａ．ここで、キャッシなしの場合以下の処理を実行する。
（５）Ｗｅｂキャッシングプロキシ２からＷｅｂサーバ４へのコネクション設定。
（６）Ｗｅｂキャッシングプロキシ２からＷｅｂサーバ４への要求転送。
（７）Ｗｅｂサーバ４からＷｅｂキャッシングプロキシ２への応答受信。
（８）Ｗｅｂキャッシングプロキシ２は、Ｗｅｂサーバ４からの応答受信をチェック
（９）Ｗｅｂキャッシングプロキシ２は、コンテンツデータをキャッシュ３に格納する。
（１０）Ｗｅｂキャッシングプロキシ２は、コンテンツデータをＷｅｂクライアント１へ応答する。
（１１）以上のようにＨＴＴＰセッションが終了される。
【００１３】
ｂ．一方、キャッシありの場合以下の処理を実行する。
（１５）Ｗｅｂキャッシングプロキシ２は、キャッシュ３からコンテンツデータを読出す。
（１６）キャッシュ３から得られたコンテンツデータをＷｅｂキャッシングプロキシ２を介してＷｅｂクライアント１に返信。
（１７）以上のようにＨＴＴＰセッションが終了される。
【００１４】
以上のようなプロキシ処理を実現する方法としては、各Ｗｅｂクライアントからの要求に対応して、１つずつプロセスまたはスレッドを割り当て、各ステップ（１）〜（１７）（図中丸数字１〜１７に相当）に対応する処理を順次コールする方法がある。しかし、この方法は、各要求にプロセスやスレッドを対応付けるため、多大なリソースを必要とし、性能面でも、ＯＳのプロセスやスレッドスイッチのオーバヘッドが大きく、多数の要求を処理するには不適であった。
【００１５】
そこで、本実施の形態のプロキシ処理方法では、１つのプロセスで複数のＷｅｂクライアントからの要求を処理する方式を取る。そのため、各Ｗｅｂクライアントからの要求（ＨＴＴＰセッション）毎に、各ステップ（１）〜（１７）のどこまで処理が進んでいるかの状態をステートとして保持し、そのステートを遷移させながら処理を進める方式を取る。なお、プロキシ処理としては、たとえば、固定的でない独自の認証、要求の中継、キャッシング、固定的でない独自のアクセスロギング、課金、付加価値サービス等、多様な処理を含む。
【００１６】
２．モジュール管理
まず、プロキシ処理に関連するテーブルについて説明する。
２−１．モジュールテーブル
プロキシ処理装置の実行プログラムは、機能的な纏まりであるモジュールの集合で構成される。モジュールは、その機能を実現するためのステート処理関数群、Ｉ／Ｏ処理関数群、共用メモリ上の固有データ等で構成され、機能追加及び削除のひとつの単位とされる。プロキシ処理装置では、各モジュールが提供するステートリスト情報を保持したモジュールテーブルを用いてモジュールを管理することで、ステート遷移テーブルの起動時の構築を実現し、モジュール単位での機能の追加及び削除を可能とする。
【００１７】
図２に、モジュールテーブルの構成イメージの説明図を、また、図３に、モジュールテーブルに保持されている主な情報の説明図を示す。
モジュールテーブルは、プログラムがどのようなモジュール（機能）の集まりであるかを定義するテーブルである。モジュールテーブルには、オブジェクトを示すモジュール名及びステート一覧を示すステートリスト情報を含むエントリが記憶される（各項目の内容は図を参照）。ステートリスト情報によりステート遷移テーブルの素材となるステートリストが参照される。ステートリストには、標準モジュール、課金モジュール等の各モジュールが提供する機能を実現するためにステートのステート名と、そのステートに対応した処理関数が記憶される。これら各ステートを組み合わせてステート遷移テーブルが作成される。
【００１８】
なお、オブジェクトとしてはスタティックリンクした形のスタティックリンクモジュールにし、予めモジュールテーブルに登録する形にしても良いし、さらに、各モジュールのダイナミックローディングをサポートし、モジュールテーブルに動的に登録する形でもよい。但し、スタティックリンクモジュールの場合でも、ロードされているすべてモジュールの機能が常に使用されるわけではなく、起動時におけるステート遷移テーブルの構築により、必要なモジュールの機能のみを選択して使用することが可能である。
【００１９】
モジュールテーブルステートリスト情報は、例えば、ステート名、ステート処理関数以外に、ステート識別子（ステートＩＤ）、起動時に本ステート又はモジュールで必要な領域の確保処理等行うステートｃｏｎｆｉｇ関数、クライアントからの要求受付け時に本ステート又はモジュール固有の領域の確保や初期化処理等を行うセッション初期化関数、要求処理終了時に、不要な領域の解放や各種後処理を行うセッション終了関数などを含む。
【００２０】
２−２．ステート定義ファイル
ステート定義ファイルは、ステート遷移テーブルを構築するためのステート定義情報を記述したファイルである。
図４に、ステート定義ファイルの記述例についての説明図を示す。
ステート定義ファイルは、ステート遷移テーブルを構成するステート名をデフォルトのステート遷移順に記述する。なお、'＃'は、特別な文字で、'＃'以降行末まではコメントを表す。空行も可能である。この例では、ステート名として、順に、（i）Ａｃｃｅｐｔ＿Ｃｌｔ、（ii）Ｇｅｔ＿Ｒｅｐ＿Ｈｄｒ、（iii）Ｐａｒｓｅ＿Ｒｅｐ＿Ｈｄｒ、（iv）Ｃｈｅｃｋ＿Ａｕｔｈ、（v）Ｃｈｅｃｋ＿Ｃａｃｈｅ、が定義されている。
【００２１】
２−３．セッション管理テーブル
図５に、セッション構造体（セッション管理テーブルエントリ）が保持する主な情報の説明図を示す。
以下に、セッション管理テーブルの概要を説明する。
本発明のプロキシ処理方法では、各クライアントからの要求処理は、各要求の受付け（通信路確立）から処理終了までを１つのＨＴＴＰセッションとして管理する。セッション管理テーブルは、Ｗｅｂクライアントからのこの要求受付けから処理終了までの各ＨＴＴＰセッションに対応した情報を保持するテーブルである。セッション管理テーブルは、クライアントからの各要求の処理状態を管理するものである。各セッションテーブルエントリは、各ＨＴＴＰセッション毎に生成及び管理され、各ＨＴＴＰセッションの現在（現行）のステート情報の他に、各Ｗｅｂクライアントの要求を処理するために必要な様々な標準情報及び拡張情報を保持する。以下、各ＨＴＴＰセッションに対応した各セッション管理テーブルエントリをセッション構造体と呼ぶこととする。この例では、セッション管理テーブルは、セッションＩＤ、ステート情報、通信路情報、送受信バッファ、要求情報、返信情報、処理結果情報、モジュール固有拡張情報等の適宜の各フィールドを含む（各フィールドの説明は、図を参照）。
【００２２】
つぎに、拡張モジュール対応の領域拡張について説明する。
本セッション管理テーブルは、デフォルトのＨＴＴＰモジュールで使用する標準情報用の領域だけでなく、拡張モジュール固有の領域を各セッション構造体に確保することが可能である。この拡張モジュール固有領域にはモジュール固有の情報を保持できる。各モジュールは、必要に応じて、たとえば、後述するステートｃｏｎｆｉｇ関数等の関数の中で、特定の関数をコールすることで、モジュール固有の領域（モジュール固有拡張情報）を各セッション構造体に確保する。
【００２３】
２−４．ステート遷移テーブル
図６に、各ステート遷移テーブルエントリが保持する主な情報の説明図を示す。
ステート遷移テーブルエントリは、前述した関連するプロキシ処理の各ステップ（１）〜（１７）等の各ステート（状態）に対応するステート毎の処理関数や、ステート間のデフォルトの遷移情報等を保持する。なお、本ステート遷移テーブルは、ステート定義ファイルの情報を用いて、プロキシ処理の起動時に生成される（後述）。この例では、ステート遷移テーブルエントリは、ステートＩＤ、ステート名称、ステート処理関数、ステートｃｏｎｆｉｇ関数、セッション初期化関数、セッション終了関数、デフォルトの次ステート情報の各フィールドを含む（各フィールドの説明は、図を参照）。
【００２４】
３．プロキシ処理の概要
図７は、プロキシ処理の全体的な処理の流れを示すフローチャートである。
プロキシ処理が起動されると、プロキシ処理装置は、メモリ、Ｉ／Ｏ装置、インターフェース等の初期化を実行する（Ｓ０１）。つぎに、ステート遷移テーブルが構築される（Ｓ０３）。なお、この詳細は主に図９及びその説明箇所参照。つぎに、プロキシ処理装置は、各ステートについてステートｃｏｎｆｉｇ関数の処理を実行する（Ｓ０５）。各ステートのステートｃｏｎｆｉｇ関数の実行は、起動時に１回のみ実行され、プロキシ処理装置は、セッション毎に持つべきセッション管理テーブルが必要なサイズを確保する。つぎに、プロキシ処理装置は、セッション処理プロセスを実行する（Ｓ０７）。
以下各ステップについて詳細に説明する。
【００２５】
３−１．ステート遷移テーブルの起動時構築
プロキシ処理装置では、ステート定義ファイルの記述に従い、モジュールテーブルの中から必要なステート処理機能を選択的に選び出すことにより、ステート遷移テーブルを、プロキシ処理の起動時に動的に構築する。
図８に、ステート遷移テーブルの起動時構築についての説明図を示す。
ステート遷移テーブルは、ステート定義ファイルに記述されたステート名を持つステート遷移テーブルエントリを、モジュールテーブルのステートリストから検索し、一致したエントリを順次コピーしてくることで構築する。
【００２６】
図９に、ステート遷移テーブルの構築処理の流れについてのフローチャートを示す。なお、ステート名の検索は、予め定められた順序、例えば、後から登録されたモジュールから順に検索する。従って、この場合、同じステート名を持つ複数のモジュールがあった場合は、後で登録されたモジュールのエントリが優先して利用される。以下に、フローチャートに従い処理の流れを説明する。
・ステップＳ８０１（ステート定義ファイルのオープン）：
ステート定義情報を読出すため、ステート定義ファイルをオープンする。
・ステップＳ８０２（ステート名のリード(ｒｅａｄ)）：
ステート定義ファイルから、順次、ステート名を１つ読出す。
・ステップＳ８０３（終了チェック）：
処理すべきステート名がなければ、ステップＳ８１０へ飛ぶ。
・ステップＳ８０４（モジュールテーブル上でのエントリー検索）：
処理すべきステート名があれば、指定されたステート名を持つステート遷移テーブルエントリーをモジュールテーブルのステートリスト情報から検索する。
・ステップＳ８０５（ステート遷移テーブルへのエントリーのコピー）：
ステップＳ８０４で見つかったステートリスト情報エントリーを新たなステート遷移テーブルエントリの対応するフィルドににコピーし、登録する。
・ステップＳ８０６（デフォルト次ステート情報の設定）：
ステート定義ファイルの順序に従い、ステップＳ８０５で登録したステート遷移テーブルエントリーのデフォルトの次ステート情報を次に登録するステート遷移テーブルエントリを指すように設定する。なお、ステート定義ファイルの最終エントリで次ステートがない場合は、最後であることを示す情報（ＮＵＬＬ）を設定する。
・ステップＳ８０７（ステートＩＤ割当て＆ｓｔａｔｅ＿ｉｎｄｅｘ設定）：
ステートＩＤが０の場合は、ステートＩＤを生成し、割当てる。また、ステートＩＤからステート遷移テーブルエントリーを索引するためのステートインデックス（ｓｔａｔｅ＿ｉｎｄｅｘ）を設定する。なお、ステートＩＤが０でない場合は、すでに同じＩＤで登録されていないかチェックし、すでに登録されていればエラー表示を行う。
・ステップＳ８０８（セッション初期化処理関数リストの登録）：
初期化処理関数が設定されている場合は、セッション初期化処理関数リストに登録する。同リストは、セッション初期化時の初期化関数コールに使用する。
・ステップＳ８０９（セッション終了処理関数リストの登録）：
同様に、終了処理関数が設定されている場合は、セッション終了処理関数リストへの登録を行い、ステップＳ８０２に戻る。
・ステップＳ８１０（セッション定義ファイルのクローズ）：
セッション定義ファイルをクローズする。
・ステップＳ８１１（ステートｃｏｎｆｉｇ関数実行）：
ステップＳ８０１〜Ｓ８１０で設定された各ステート遷移テーブルエントリのステートｃｏｎｆｉｇ関数を実行する。すべてのステートｃｏｎｆｉｇ関数の実行が成功すれば、ステート遷移テーブル構築を終了する。
【００２７】
３−２．ステートｃｏｎｆｉｇ関数の処理
セッション管理テーブル中の標準情報は、全モジュールに共通の情報であり各モジュールから参照・更新する。一方、セッション管理テーブル中の拡張情報は、各オプションの拡張モジュール固有の情報であり、同拡張モジュールのみが参照・更新する。この拡張情報領域は、セッション管理テーブルの拡張領域の確保関数を実行することにより確保される。上記ステート遷移テーブル構築により取込まれたステートのステートｃｏｎｆｉｇ関数は、ステップＳ８１１でコールされ、同ステートｃｏｎｆｉｇ関数が必要に応じて、上記拡張領域の確保関数をコールすることで必要な拡張領域をセッション管理テーブルに確保する。そして、同ｃｏｎｆｉｇ関数は、拡張領域確保関数から戻ってきた、確保した拡張領域の場所を示すオフセット情報を同拡張モジュール内に（オフセット変数として）記憶し、同オフセット変数を使って同拡張領域を参照・更新する。
【００２８】
３−３．セッション処理プロセス
図１０に、セッションスケジューラの処理の流れについての説明図を示す。
セッションスケジューラは、動作可能な状態になった各クライアントのＨＴＴＰセッションのスケジューリングを行う。以下に各処理を説明する。
・ステップＳ４０１（セッション処理プロセス実行開始）：セッション処理プロセスを生成し、セッション処理プロセスの実行を開始する。
・ステップＳ４０２（ネットワークＩ／Ｏレディー(ｒｅａｄｙ)、プロセス間通信返信レディー等のイベント待ち）：セッションスケジューラは、ネットワークＩ／Ｏレディー、プロセス間通信返信レディー又はＷｅｂクライアントからのコネクション確立要求到着等のイベントをチェックし、該当するイベントがなければ、同イベントが発生するか、一定のタイムアウト時間まで待つ。
・ステップＳ４０３（イベント内容チェック）：ステップＳ４０２でレディー状態となったイベント内容をチェックし、その内容に応じて処理が分岐される。分岐される各処理としては、例えば、以下の通り。
（i）コネクション確立要求が到着した場合、ステップＳ４０４へ分岐
（ii）レディーイベント発生が到着した場合、ステップＳ４０６へ分岐
（iii）レディー待ちタイムアウトが到着した場合、ステップＳ４０８へ分岐
（iv）オペレータ指示による終了イベントが到着した場合、ステップＳ４０９へ分岐
・ステップＳ４０４（コネクション確立）：Ｗｅｂクライアントからのコネクション確立要求が到着した場合は、セッションスケジューラは、コネクションを確立し、ステップＳ４０５に進む。
・ステップＳ４０５（セッションテーブルエントリ生成＆初期化）：つぎに、セッションスケジューラは、セッションテーブルエントリを生成し、セッションテーブルエントリの初期化を行う。その際、セッションスケジューラは、前記ステート遷移テーブル構築時のステップＳ８０８で生成したセッション初期化処理関数リストを参照し、各ステートのセッション初期化関数をコールし、モジュール拡張領域の初期化等も行う。その後、ステップＳ４０２に戻り、ＷｅｂクライアントからのＨＴＴＰ要求が到着するのを待つ。
・ステップＳ４０６（動作可能ＨＴＴＰセッションの選択）：レディーイベント発生が到着した場合、セッションスケジューラは、動作可能になったＨＴＴＰセッションのセッションテーブルエントリを１つ選択し、ステップＳ４０７に進む。
・ステップＳ４０７（ステート遷移エンジン実行）：つぎに、セッションテーブルエントリとイベント情報をパラメータとして、ステート遷移エンジンをコールする（なお、ステート遷移エンジンの動作の詳細は後述）。なお、ステート遷移エンジンには、例えば、通信路の入出力がレディー（ｒｅａｄｙ）という形式のイベントとして渡される。ステート遷移エンジンから制御が戻ったら、セッションスケジューラは、ステップＳ４０２に戻り、別の動作可能なＨＴＴＰセッションをスケジュールする。
・ステップＳ４０８（タイムアウト処理）：ステップＳ４０２でレディー状態のイベントがない場合でも、定期的にタイムアウトでステップＳ４０２を抜け、各セッションのネットワークＩ／Ｏのタイムアウトチェックを行う。もし、あるＨＴＴＰセッションのタイムアウトを検出した場合は、対応するＨＴＴＰセッションに対し、タイムアウトイベントを通知し、ステップＳ４０２に戻る。このようにすることで、タイムアウトによるｒｅａｄｙイベントとして、ステップＳ４０６、Ｓ４０７により当該ＨＴＴＰセッションがスケジューリングされるようにする。
・ステップＳ４０９（セッション処理プロセス終了処理）：オペレータからの終了コマンドの投入により、セッションスケジューラは、プロキシ処理の終了通知を受け、セッション処理プロセスの終了処理を行い、ステップＳ４１０に進む。・ステップＳ４１０（セッション処理プロセス終了）：こうして、セッションスケジューラは、セッション処理プロセスを終了する。
【００２９】
３−４．ステート遷移エンジン
図１１に、プロシキ装置のＨＴＴＰセッション処理の説明図を示す。また、図１２に、ステート遷移エンジンの処理の流れ図を示す。ステート遷移エンジンは、各セッションテーブルエントリにステート状態を保持し、ステートを遷移しながら対応するステート遷移テーブルエントリの処理関数を順次実行していき、各ＨＴＴＰセッションの処理を実行する。処理の流れは以下の通りである。以下のかっこで示した番号は、図１１のかっこで示した数字に対応する。
【００３０】
（１）ステップＳ３０１：動作可能ＨＴＴＰセッションのスケジューリング及びステート遷移エンジンの起動
まず、各セッション処理プロセスにおけるセッションスケジューラは、データ到着等により、あるＨＴＴＰセッションが動作可能（レディー状態）になったことを検出すると、そのＨＴＴＰセッションのセッション構造体とイベントの詳細情報を引数として、ステート遷移エンジンを起動する。なお、ステート遷移エンジン起動までの処理は、図１０（セッション処理プロセス）及びその説明箇所参照。
（２）ステップＳ３０２（現在ステート情報参照及びステート遷移テーブルエントリ取得）：つぎに、ステート遷移エンジンは、セッション構造体のステート情報（ステートＩＤ）を参照し、対応するステート遷移テーブルエントリを取得する。この例では、ステート２（丸数字）を参照する。
（３）ステップＳ３０３（ステート処理関数実行）：つぎに、ステート遷移エンジンは、ステップＳ３０２で取得したステート遷移テーブルエントリの処理関数（ステート処理関数）を実行する（この例では、ｒｃｖ＿ｒｅｑ＿ｈｄｒという処理関数）。なお、ステート処理関数を実行する際には、セッション構造体とイベント情報を引数としてコールする（詳細は後述）。
（４）ステップＳ３０４（ステート遷移処理）：つぎに、ステート遷移エンジンは、ステート処理関数からのリターン値により次の遷移ステート求め、次ステート情報をセッション構造体に設定する。
【００３１】
図１３に、ステート処理関数からのリターン値とその動作の説明図を示す。リターン値は、例えば、’ＡＤＶ’、’ＧＯＴＯ’、’ＳＣＨＥＤ’、’ＥＲＲＯＲ’、’ＥＮＤ’等がある（各リターン値についての、ステート遷移エンジンの動作、利用目的及びステート処理関数からの利用方法は、図を参照）。例えば、リターン値が’ＡＤＶ’では、デフォルトの次ステートに遷移する。リターン値が’ＧＯＴＯ’では、ＩＤフィールドで指定されたステートに遷移する。リターン値が’ＳＣＨＥＤ’では、現在のステートのままでイベントを待ち、同一ステートから再開する。リターン値が’ＥＲＲＯＲ’では、エラー情報返信ステートに遷移する。また、リターン値が’ＥＮＤ’では、セッション処理の終了のため、セッション終了関数を実行し、対応するセッションテーブルエントリを解放し、セッションスケジューラに戻る。
【００３２】
リターン値が’ＥＮＤ’でなく、且つ’ＳＣＨＥＤ’が立っていない場合は（例えば、’ＡＤＶ’、’ＧＯＴＯ’、’ＥＲＲＯＲ’）、ステップＳ３０２に戻り、次のステートの処理を次々実行する。リターン値が’ＥＮＤ’又は'ＳＣＨＥＤ'が立っている場合は、ステップＳ３０５に戻る。
（５）ステップＳ３０５（セッションスケジューラへのリターン及び再スケジュール要求）：ネットワークからのデータ待ち等の理由により、スケジューリング要求である’ＳＣＨＥＤ’がリターン値に立っていた場合または、リターン値がセッションの終了を表す’ＥＮＤ’の場合は、スケジューラに戻り、別の動作可能なセッションのスケジュールをスケジューラに要求する。
【００３３】
図１４に、プロキシ処理の概要説明図を示す。
以上のように、本実施の形態のステートの状態を保持し、ステートを遷移させながら処理を進めるステート遷移エンジンでは、以下のような特徴がある。
【００３４】
（１）構成定義機能を用い、ステート定義ファイルからプロキシ処理手順を示すステート遷移テーブルを起動時に生成（図中、１−(１)参照）
本実施の形態では、各クライアントから要求された処理をステートに分割し、その処理手順（ステートの遷移状況）を示すステート遷移テーブルを各ステートを定義したステート定義ファイルから起動時に生成することで、柔軟なプロキシ処理が実現される。そして、拡張処理用の拡張ステートの挿入・追加・置換定義等により、課金・認証等、様々なニーズを反映した固有の処理が実現される。
【００３５】
（２）ステート遷移エンジンにより、ステート遷移テーブルに従ったプロキシ処理を実現（図中、１−(２)参照）
本実施の形態では、各ステート毎に登録定義された以下のような関数を、ステート遷移エンジンが、上記（１）で作成されたステート遷移テーブルに従って実行することで、プロキシ処理が実現される。関数としては、たとえば、（i）ステートの処理関数、（ii）起動時の初期化処理を行うｃｏｎｆｉｇ関数、（iii）セッション開始時のセッション初期化関数、（iv）セッション処理終了時のセッション後処理関数（終了関数）、等である。そして、拡張ステートについての上記のような関数群を登録することで、様々な固有処理が実現される。
【００３６】
（３）セッション管理テーブルへの拡張機能用の拡張領域の追加機能を提供（図中、１−(３)参照）
本実施の形態では、クライアントからの各要求の処理状態を管理するセッション管理テーブルに、標準情報領域に拡張領域を追加する機能を提供する。起動時に実行される各ステートのｃｏｎｆｉｇ関数（ii）で、同拡張領域の確保機能を使用し、必要に応じて拡張領域を確保し、拡張ステートの処理で必要となる、各セッション対応の固有情報の保持を実現する。なお、セッション管理テーブルは、例えば、現行ステート情報、ユーザ情報、標準情報、拡張情報を含む。また、同領域のセッション毎の初期化及び終了処理は、それぞれセッション初期化関数（iii）及びセッション後処理関数（iv）で行うことができる。
【００３７】
４．拡張ロギング
以下に、図１４を参照して通常のロギングから拡張された本実施の形態の拡張ロギングについて、説明する。
図１５に、拡張ロギング定義ファイルの説明図を示す。
【００３８】
（１）拡張ロギング定義ファイルで、ロギングする拡張ログ情報を指示（図１４中、２−(１)参照）
本実施の形態では、拡張ロギング定義ファイルに、ログタイプ、ロギングすべき要求又は応答ヘッダフィールド名、ログサイズ、タイプ番号、表示名等を記述する。そして、プロキシ処理装置の起動時に構成定義機能が同ファイルの定義情報を、拡張ロギング定義情報としてローディングし、同定義に従って、アクセスログ処理を行うことで、柔軟なロギングを実現する。
【００３９】
ログタイプは、図示の通りである。ログサイズは、例えば、ロギングサイズが固定の場合のログサイズである。タイプ番号は、ログ内容を区別するためのユニークな番号であり、特に、拡張特別処理でのロギング（ＳＰＥＣＩＡＬ）等で使用される。表示名は、ログ解析／ダンプツールで表示する際の表示名称である。
【００４０】
（２）セッション管理テーブルに、拡張ロギング定義に従った拡張ロギング情報を保持（図１４中、２−(２)参照）
要求ヘッダ、応答ヘッダ等の構文解析時に、セッション管理テーブルの拡張ログ定義情報として、拡張ログタイプ（例えば、ＲＥＱ＿ＦＬＤ，ＲＥＰ＿ＦＬＤ等）で定義された情報を記憶する。一方、セッション管理テーブルの標準ログ定義情報として、標準ログタイプ（例えば、ＣＬＴ＿ＲＥＱ＿ＵＲＬ，  ＲＥＱ＿ＦＬＤ＿ＵＳＲ，ＲＥＱ＿ＶＥＲ，ＲＥＰ＿ＶＥＲ等）で定義された情報を記憶する。
【００４１】
（３）各アクセスログは、固定長標準ログと、可変長／拡張ログに分離して分けてロギング
図１６に、アクセスログ生成処理の説明図を示す（図中２−(３)参照）。
アクセスログ生成処理について以下に説明する。
・各アクセスログは、標準で常にログ情報に出力する固定長標準ログと上記拡張ロギング定義に従って出力する可変長／拡張ログで構成する。固定長標準ログは、セッション管理テーブルの標準情報をもとに出力するのに対し、可変長／拡張ログは、セッション管理テーブルの標準情報に加え拡張情報を用いて出力する。これにより、拡張可能なアクセスロギングが実現される。
【００４２】
・各アクセスログの長さは、一定ブロックサイズの倍数でとり、固定長標準ログの先頭に記述する。これにより、可変長ログの高速なログ処理を可能とする。固定長標準ログ情報には、要求、応答サイズ、応答ステータス、ユーザ情報（＃５に対応）等を含むことができる。
【００４３】
・可変長／拡張ログ領域は、可変長領域のサイズに加え、拡張ロギング定義に従った名ログ情報が出力されている場所を示すオフセット情報（オフセット配列）と、実際の拡張ロギングデータ（拡張ログ情報）とを含む。オフセット配列を設けることで、可変長の各拡張ログの場所を１回の間接アクセスで取得可能となる。従って、各フィールドの集計処理等、ログから特定フィールドの統計処理を行う場合、高速処理が可能となる。なお、各フィールドデータのサイズは、前後のオフセットから知ることが可能であり、また、各文字列フィールドデータは、ＮＵＬＬバイトで終了しているので、（最大バッファサイズの問題を除けば）サイズ情報なくても処理可能である。
【００４４】
・ＳＰＥＣＩＡＬ部の拡張ログは、標準アクセスログ処理関数にフック関数を設け、同フック関数を拡張ステート処理関数のステートｃｏｎｆｉｇ関数で設定することで実現する。フック関数のコール先を示すフックの関数変数に０以外のコール先のアドレスが設定されているとアクセスログ出力時に、同フック関数変数に設定された拡張処理のアクセスログ出力関数がコールされ、拡張処理固有の情報のロギングが実現される。したがって、拡張処理固有ロギングが可能となる。
【００４５】
・アクセスロギングファイルの先頭には、ログヘッダを出力し、ｅｎｄｉａｎ情報、統計サマリー情報、拡張ログ定義情報のコピー等を出力する。ｅｎｄｉａｎ情報により、ｂｙｔｅ−ｅｎｄｉａｎの違う他のマシンでもログ解析が可能となる。また、統計サマリー情報により、アクセスログファイルの中に格納されたすべてのアクセスログを解析・集計しなくても簡易のサマリ処理を可能とする。また、拡張ログ定義情報のコピーにより、可変長／拡張領域の内容、アクセスの仕方、及び、シンボリックな表示が可能となる。
【００４６】
このようにアクセスログ生成手段により生成されたアクセスログに従って、ログ解析ツールにより各種解析結果が出力できる。
図１７に、セッション終了時のアクセスログ出力処理の流れの説明図を示す。・Ｓ２０１：セッション終了時に、アクセスログ出力処理がコールされると、同アクセスログ出力処理は、セッションテーブルの標準情報を参照し、予め決められた固定長標準ログを出力する。固定長標準ログは、本プロキシで固定で常に出力するログ情報である。
・Ｓ２０３：拡張ロギング定義ファイルの指示に従い、各拡張ロギングデータの出力場所を示すオフセット情報と、各拡張ロギングデータを順に拡張ログとして出力する。
【００４７】
図１８に、ステップＳ２０３の拡張ロギング定義ファイルの指示のログタイプに対応した各処理についての説明図を示す。ログタイプに従い、図示の処理を実行する。
なお、以上の説明では、セッション初期化関数の実行は、セッションスケジューラで、セッション終了関数の実行は、セッションスケジューラから呼ばれたステート遷移エンジンで行うようにしているが、これに限らず、セッション初期化関数をステート遷移エンジンで実行してもよいし、また、セッション終了関数の実行をセッションスケジューラに持ってきてもよい。
【００４８】
なお、本発明のプロキシ処理方法及びプロキシ装置は、その各処理手順をコンピュータに実行させるためのプロキシ処理プログラム、プロキシ処理プログラムを記録したコンピュータ読み取り可能な記録媒体、プロキシ処理プログラムを含みコンピュータの内部メモリにロード可能なプログラム製品、そのプログラムを含むサーバ等のコンピュータ、等により提供されることができる。
【００４９】
【発明の効果】
本発明によると、以上のように、ユーザ認証や課金等のように、固有の拡張処理を柔軟に追加・変更することができるプロキシ処理方法を提供することができる。また、本発明によると、固有拡張情報やヘッダフィールド等を選択することにより、柔軟なロギングが可能であり、且つ、高速なロギングの解析・集計処理を実現することができる。
【図面の簡単な説明】
【図１】一般的なＷｅｂキャッシングプロキシ処理の流れについての説明図。
【図２】モジュールテーブルの構成イメージの説明図。
【図３】モジュールテーブルに保持されている主な情報の説明図。
【図４】ステート定義ファイルの記述例についての説明図。
【図５】セッション構造体（セッション管理テーブルエントリ）が保持する主な情報の説明図。
【図６】各ステート遷移テーブルエントリが保持する主な情報の説明図。
【図７】プロキシ処理の全体的な処理の流れを示すフローチャート。
【図８】ステート遷移テーブルの起動時構築についての説明図。
【図９】ステート遷移テーブルの構築処理の流れについてのフローチャート。
【図１０】セッションスケジューラの処理の流れについての説明図。
【図１１】プロシキ装置のＨＴＴＰセッション処理の説明図。
【図１２】ステート遷移エンジンの処理の流れ図。
【図１３】ステート処理関数からのリターン値とその動作の説明図。
【図１４】プロキシ処理の概要説明図。
【図１５】拡張ロギング定義ファイルの説明図。
【図１６】アクセスログ生成処理の説明図。
【図１７】セッション終了時のアクセス出力処理の流れの説明図。
【図１８】ログタイプに対応した各処理についての説明図。
【図１９】従来のプロキシ処理についての説明図。
【符号の説明】
１  Ｗｅｂクライアント
２  Ｗｅｂキャッシングプロキシ
３  キャッシュ
４  Ｗｅｂサーバ
【図１】
0003950752.tif 000002
【図２】
0003950752.tif 000003
【図３】
0003950752.tif 000004
【図４】
0003950752.tif 000005
【図５】
0003950752.tif 000006
【図６】
0003950752.tif 000007
【図７】
0003950752.tif 000008
【図８】
0003950752.tif 000009
【図９】
0003950752.tif 000010
【図１０】
0003950752.tif 000011
【図１１】
0003950752.tif 000012
【図１２】
0003950752.tif 000013
【図１３】
0003950752.tif 000014
【図１４】
0003950752.tif 000015
【図１５】
0003950752.tif 000016
【図１６】
0003950752.tif 000017
【図１７】
0003950752.tif 000018
【図１８】
0003950752.tif 000019
【図１９】
0003950752.tif 000020