(57)【要約】  【課題】特定のトラフィックパターンを有する通信トラフィックの発生を確実に制限すること。  【解決手段】通信処理手段５は、通信ネットワークやサーバとの間でのデータ通信処理を実行する。通信制御手段６は、アプリケーション４−１〜４−ｎからデータの送信要求を受付け、送信要求されたデータを前記通信処理手段に引き渡す。制御条件管理手段７は、通信制御手段６が使用する制御パラメータを管理する。通信制御手段６は、アプリケーション４−１〜４−ｎが送出したデータの量から次のデータの送信遅延時間を決定し、決定された送信遅延時間後に次のデータの送信を実行可能にする。  【選択図】図１
2005277541.tif 000002
【特許請求の範囲】
【請求項１】
特定のトラフィックパターンを有する通信トラフィックの発生を制限するための通信トラフィック制限方法であって、
アプリケーションが送出したデータの量から次のデータの送信遅延時間を決定する第１のステップと、
前記第１のステップで決定された送信遅延時間後に次のデータの送信を実行可能とする第２のステップとを有することを特徴とする通信トラフィック制限方法。
【請求項２】
前記第１のステップは、アプリケーションが送出したデータの量の大小に反するように次のデータの送信遅延時間の長短を決定することを特徴とする請求項１に記載の通信トラフィック制限方法。
【請求項３】
前記第１のステップは、アプリケーションが送出したデータの量の大小に合わせて次のデータの送信遅延時間の長短を決定することを特徴とする請求項１に記載の通信トラフィック制限方法。
【請求項４】
特定のトラフィックパターンを有する通信トラフィックの発生を制限するための通信トラフィック制限用プログラムであって、請求項１ないし請求項３のいずれかに記載の通信トラフィック制限方法における第１のステップおよび第２のステップをコンピュータに実行させるための通信トラフィック制限用プログラム。
【請求項５】
特定の通信トラフィックパターンを発生させるアプリケーションの通信を制限する機能を有する通信装置であって、
通信ネットワークやサーバとの間でのデータ通信処理を実行する通信処理手段と、
アプリケーションからデータの送信要求を受付け、送信要求されたデータを前記通信処理手段に引き渡す通信制御手段と、
前記通信制御手段が使用する制御パラメータを管理する制御条件管理手段を具備し、
前記通信制御手段は、アプリケーションからデータの送信要求を受け、送信要求されたデータを前記通信処理手段に引き渡し、また、前記制御条件管理手段が管理する制御パラメータに基づき、前記通信処理手段より通知されたデータの量から次のデータの送信遅延時間を決定するとともに、該決定した送信遅延時間後にアプリケーションにデータ通信が可能となったことを通知し、前記通信処理手段は、前記通信制御手段から引き渡されたデータを送信し、送信完了したデータの量を前記通信制御手段に通知することを特徴とする通信装置。
【請求項６】
前記通信制御手段は、前記通信処理手段より通知されたデータの量の大小に反するように次のデータの送信遅延時間の長短を決定することを特徴とする請求項５に記載の通信装置。
【請求項７】
前記通信制御手段は、前記通信処理手段より通知されたデータの量の大小に合わせて次のデータの送信遅延時間の長短を決定することを特徴とする請求項５に記載の通信装置。
【請求項８】
前記制御条件管理手段が管理する制御パラメータは、通信ネットワークを介して他の通信端末から更新可能であることを特徴とする請求項５ないし請求項７のいずれかに記載の通信装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信トラフィック制限方法、通信トラフィック制限用プログラムおよび通信装置に関し、特に、特定のトラフィックパターンを有する通信トラフィックの発生を制限する通信トラフィック制限方法、それを実現するための通信トラフィック制限用プログラムおよび通信トラフィック制限の機能を有する通信装置に関する。
【背景技術】
【０００２】
これまで、特定のアプリケーションからの通信トラフィックを制御する方法がいくつか提案されている。例えば、下記特許文献１では、TCP/UDPで使用されるポート番号や、アプリケーション毎に定義されるサービスタイプ、あるいはトラフィックタイプを用いて通信制御を行う方法が提案されている。
【０００３】
また、下記特許文献２では、各アプリケーションが指定するトラフィックタイプがリアルタイム形式である場合に優先的に通信リソースを割り当てる方法が提案されている。
【０００４】
これらの従来技術を利用すれば、アプリケーションが実行する、特定のポート番号、特定のサービスタイプ、あるいは特定のトラフィックタイプの通信を制限することが可能である。
【特許文献１】特開２００１−２９８４８１号公報
【特許文献２】特開２００３−１６９３６３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、上記特許文献１，２で提案されている方法では、制限対象とするトラフィックを確実に制限できないという課題がある。すなわち、TCP/UDPで使用されるポート番号はRFC1700においてWell Known Port Numberとして定義されているが、実システムの運用上、同規定値と異なる値を使用する場合があり、Well Known Port Number以外の任意のポート番号を使用して通信を行うことが可能である。このため、アプリケーションが指定するポート番号の情報のみでは、その通信がどのようなトラフィックを発生させるかを確実に知ることはできず、結局、上記特許文献１で提案されている方法ではトラフィックを確実に制限できないという課題がある。
【０００６】
また、サービスタイプやトラフィックタイプはIPヘッダのTOS（Type Of Service）フィールドに定義される情報であり、IPパケットの優先度や要求する通信サービスの特性（遅延、スループット、信頼性等）が設定可能である。しかしながら、パーソナルコンピュータや携帯電話端末などの一般的な通信端末では、アプリケーションから同フィールドの情報を設定する手段がなく、個々のアプリケーションが発生させるトラフィックの情報を確実に反映させることができない。
【０００７】
また、同フィールドに設定可能な情報は、トラフィックにリアルタイム性が要求されるか否か、あるいは高いスループットが必要か否か、遅延が許容されるか否か等、個々のアプリケーションが実行する通信のトラフィックを詳細に分類して制限をかけるには不十分な内容である。
【０００８】
さらに、アプリケーションから指定される設定値を利用する場合、アプリケーションから虚偽の内容の設定や間違った内容の設定が行われた場合、制限を回避できる可能性がある。このため、上記特許文献２で提案されている方法でもトラフィックを確実に制限できないという課題がある。
【０００９】
本発明の目的は、特定のトラフィックパターンを有する通信トラフィックの発生を確実に制限する通信トラフィック制限方法、それを実現するための通信トラフィック制限用プログラムおよび通信トラフィック制限の機能を有する通信装置を提供することにある。
【課題を解決するための手段】
【００１０】
上記課題を解決するために、本発明は、特定のトラフィックパターンを有する通信トラフィックの発生を制限するための通信トラフィック制限方法であって、アプリケーションが送出したデータの量から次のデータの送信遅延時間を決定する第１のステップと、前記第１のステップで決定された送信遅延時間後に次のデータの送信を実行可能とする第２のステップとを有する点に第１の特徴がある。
【００１１】
また、本発明は、前記第１のステップが、アプリケーションが送出したデータの量の大小に反するように次のデータの送信遅延時間の長短を決定する点に第２の特徴がある。
【００１２】
さらに、本発明は、前記第１のステップが、アプリケーションが送出したデータの量の大小に合わせて次のデータの送信遅延時間の長短を決定する点に第３の特徴がある。
【００１３】
本発明は、上記各ステップをコンピュータに実行させるための通信トラフィック制限用プログラムとして実現でき、また、特定の通信トラフィックパターンを発生させるアプリケーションの通信を制限する機能を有する通信装置としても実現できる。
【００１４】
特定の通信トラフィックパターンを発生させるアプリケーションの通信を制限する機能を有する通信装置として実現する場合には、通信制御手段が使用する制御パラメータを管理する制御条件管理手段を設け、該制御条件管理手段が管理する制御パラメータを通信ネットワークを介して他の通信端末から更新可能にすることもできる。
【発明の効果】
【００１５】
本発明の第１の特徴によれば、データの送信間隔が実際に送信されたデータ量のみに基づき制御される。このため、アプリケーションの種類や通信内容によらず、特定のトラフィックパターンを有する通信トラフィックの発生を確実に制限することができる。
【００１６】
また、第２の特徴によれば、ファイルアップロードのような大容量のデータ送信に関する通信トラフィックへの影響を与えず、VoIP(voice over internet protocol)のような小さいサイズのデータが連続的に送信されるようなトラフィックの発生を確実に制限することができる。
【００１７】
さらに、第３の特徴によれば、VoIPのような小さいサイズのデータが連続的に送信されるようなアプリケーションの通信トラフィックへの影響を与えずに、ファイルアップロードのような大容量のデータ送信に関する通信トラフィックを確実に制限することができる。
【００１８】
本発明を通信トラフィック制限用プログラムとして実現すれば、様々な通信機器から通信ネットワーク内に流入する通信トラフィックを、特定の条件で確実に制限することが可能となる。
【００１９】
また、本発明を通信装置として実現すれば、様々な通信機器から通信ネットワーク内に流入する通信トラフィックを、特定の条件で確実に制限することが可能となり、その場合、制御条件管理手段が管理する制御パラメータを通信ネットワークを介して他の通信端末から更新可能にすることにより、通信装置内の制御パラメータを外部から自由に変更でき、通信ネットワーク内に流入する通信トラフィックを、より柔軟にかつ適切に制限可能となる。
【発明を実施するための最良の形態】
【００２０】
本発明は、通信装置（通信端末）上のアプリケーションからのデータ送信プロセスに、当該アプリケーションから行われる個々の通信要求毎に送出されたデータの量（送信データ量）を計測し、計測された送信データ量に基づき次のデータを送信するまでの送信遅延時間を決定する処理を付加することを基本としている。従って、本発明は、通信ネットワークに接続された如何なる通信装置にも適用可能である。
【００２１】
一般的に、通信装置上のアプリケーションから１回の通信処理で送出されるデータの量と許容されるデータ送信間隔（データ送信遅延時間）は、そのアプリケーションによって異なる。例えば、通信装置からサーバへ文書ファイルをアップロードするアプリケーションでは、1回の通信処理で数十キロバイト以上のデータサイズを有するファイルを送信する必要があるが、１ユーザあたりのファイルアップロード処理の発生頻度は一般的に低い。
【００２２】
一方、VoIPのような音声データをリアルタイムに伝送するアプリケーションでは、そのアプリケーションが使用されている間、数十から数百バイトの小さいサイズのデータではあるが、短い時間間隔（例えば数十ミリ秒以下）で繰り返し送信する必要がある。
【００２３】
このように、１回のデータ送信で送信されるデータの量とその送信時間間隔は、各通信アプリケーションが必要とするトラフィックパターンを表している。従って、アプリケーションからのデータ送信に関して、通信装置内でこの２つのパラメータを制御することにより、期待しない通信トラフィック特性のデータが通信ネットワーク内へ流入することを阻止することが可能となる。
【００２４】
以下、図面を参照して本発明を説明する。図１は、本発明が適用された通信装置（通信端末）の実施形態を示すブロック図である。この通信装置１は通信ネットワーク２を介して、例えばサーバ３に接続可能であり、内部に複数のアプリケーション４(4-1〜4-n)、通信処理手段５、通信制御手段６、制御条件管理手段７を備える。
【００２５】
アプリケーション４は自アプリケーションで処理したデータを送出する。通信処理手段５は、通信ネットワーク２やサーバ３との間でのデータ通信処理を実行する。通信制御手段６は、複数のアプリケーション４から共有して利用され、アプリケーション４からデータの送信要求を受付け、送信要求されたデータを通信処理手段５に引き渡す。また、制御条件管理手段７は、通信制御手段６が使用する制御パラメータを管理する。通信パラメータは通信制御条件８に含まれて格納されている。
【００２６】
ここで、通信処理手段５は、上位のプログラムに対してSocketインタフェースを提供し、TCP/UDPのようなトランスポート層プロトコル以下の通信処理を提供するプログラムモジュールである。また、制御条件管理手段７が参照する通信制御条件８は、後述する送信遅延時間Td_min、Td_maxや送信データ量Dmin、Dmaxのそれぞれに関する値と送信遅延時間量決定関数にかかわる情報などから構成される。
【００２７】
次に、図１の通信装置の動作を説明する。図２は、図１の通信制御手段６が通信制御条件（制御パラメータ）８に従って行う通信制御手順の一例を示すフローチャートである。
【００２８】
アプリケーション４からデータの送信要求が発生したとき、通信制御手段６は、まず、送信遅延時間Tdが経過しているか否かを判断することで当該データ送信要求を許容するか否かを判断する（Ｓ２１，Ｓ２２）。なお、送信遅延時間Tdは、前回のデータの送信完了からの経過時間で規定される。
【００２９】
Ｓ２２で送信遅延時間Tdが経過していないと判断すれば、当該アプリケーション４からのデータの送信要求を拒否する（Ｓ２３）。また、Ｓ２２で送信遅延時間Tdが経過していると判断すれば、当該アプリケーション４からのデータの送信要求を許容し、通信処理手段５にデータ送信を実行させる（Ｓ２４）。
【００３０】
該送信要求されたデータの送信が実行された後、該送信されたデータの量を計測し、この送信されたデータの量に基づき新たな送信遅延時間Td_newを算出する（Ｓ２５）。これにより算出された送信遅延時間Td_newを新たに送信遅延時間Tdとして設定した後、Ｓ２１に戻る（Ｓ２６）。Ｓ２６で新たに設定された送信遅延時間Tdは、Ｓ２２での判断（次のデータの送信要求時の許容判断）に利用される。
【００３１】
図３は、図２のＳ２５における送信遅延時間の算出方法の例を示す図であり、この例では、送信遅延時間が送信データ量の大小に反比例するように算出される。図３において、横軸はアプリケーション４から１回の通信処理で送出されるデータの量を、縦軸は、送出されるデータサイズに対して、次のデータ送信時に課せられる送信遅延時間を表している。DminおよびDmaxはそれぞれ、送信遅延時間の算出が比例関数に基づき実行される始点と終点の送信データ量を示しており、Td_maxおよびTd_minはそれぞれ、算出される送信遅延時間の最大値と最小値である。
【００３２】
図３の例において、ＤminをVoIPに必要な送信データ量よりも大きく設定し、Td_maxをVoIPが許容する送信遅延時間よりも大きく設定することで、VoIP相当の通信トラフィック特性のデータが通信ネットワーク内へ流入することを制限することができる。
【００３３】
一方、Ｄmaxをファイルアップロードに必要な送信データ量よりも小さく設定し、Td_minをファイルアップロードが許容する送信遅延時間よりも小さく設定することで、ファイルアップロードで発生する通信トラフィックへ影響を与えないように制御することができる。
【００３４】
図４は、図２のＳ２５における送信遅延時間の算出方法の他の例を示す図であり、この例では、送信遅延時間が送信データ量の大小に順比例するように算出される。なお、同図における横軸および縦軸が表す内容と、同図内で使用されているDmin、Dmax、Td_min 、Td_maxが示す値はそれぞれ、図３と同じである。
【００３５】
図４の例において、Ｄmaxをファイルアップロードに必要な送信データ量よりも小さく設定し、Td_maxをファイルアップロードが許容する送信遅延時間よりも大きく設定することで、ファイルアップロード相当の通信トラフィック特性のデータが通信ネットワーク内へ流入することを制限することができる。
【００３６】
一方、ＤminをVoIPに必要な送信データ量よりも大きく設定し、Td_minをVoIPが許容する送信遅延時間よりも小さく設定することで、VoIPで発生する通信トラフィックへ影響を与えないように制御することができる。
【００３７】
なお、図３および図４では、ＤminからDmaxの送信データ量の範囲で、送信データ量から送信遅延時間量を算出する関数として比例関数を用いる場合を示したが、実際の制御では、制御目的に応じて２次関数などの非線形関数やステップ関数を使用することができる。本発明は、送信遅延時間量が送信データ量に応じて決定されることを特徴としているが、送信データ量と送信遅延時間量の関係を決定するために使用する関数（送信遅延時間量決定関数）を特に限定するものではない。
【００３８】
図５は、図１の実施形態における全体の処理フローを示す。アプリケーション４からデータの送信要求が発生したとき、通信制御手段６は、送信遅延時間Tdが経過しているか否かを判断することで当該データの送信要求を許容するか否かを判断する（Ｓ５１，Ｓ５２）。
【００３９】
Ｓ５２で送信遅延時間Tdが経過していない（送信遅延時間Td内でデータの送信要求が発生）と判断すれば、当該アプリケーション４に対してエラーのデータ送信結果を通知する（Ｓ５３）。また、Ｓ５２で送信遅延時間Tdが経過していると判断すれば、当該アプリケーション４からのデータの送信要求を許容し、通信処理手段５に対してデータの送信要求を行い、データを引き渡す（Ｓ５４）。データの送信要求には要求送信データ量が含まれる。データの送信要求を受けた通信処理手段５は、送信要求されたデータの送信を実行し（Ｓ５５）、データ送信結果を通信制御手段６に通知する（Ｓ５６）。データ送信結果には送信完了データ量が含まれる。
【００４０】
次に、通信制御手段６は、制御条件管理手段７が管理する通信制御条件８を参照し（Ｓ５７）、通信処理手段５から通知された送信完了データ量と通信制御条件８に基づき新たな送信遅延時間Td_newを算出する（Ｓ５８）。これにより算出された送信遅延時間Td_newを新たに送信遅延時間Tdとして設定し（Ｓ５９）、タイマによる遅延送信時間の計時を開始させる（Ｓ６０）。その後、アプリケーション４にデータ送信結果を通知する（Ｓ６１）。データ送信結果には送信完了データ量が含まれる。
【００４１】
アプリケーション４では、要求送信データ量が送信完了データ量より大きいか否かを判断し（Ｓ６２）、要求送信データ量が送信完了データ量より大きくなければ送信要求したデータは既に送信完了しているので、Ｓ５１に戻って次のデータ送信要求に移る。しかし、要求送信データ量が送信完了データ量より大きければ、さらに送信可通知を通信制御手段６に要求する（Ｓ６３）。送信可通知要求を受けた通信制御手段６は、送信遅延時間Tdの経過を待って（Ｓ６４）アプリケーション４に送信可通知を行う（Ｓ６５）。送信可通知を受領したアプリケーション４は通信制御手段６に対してデータ送信要求を実行する（Ｓ５１）。
【００４２】
なお、アプリケーション４からのデータの送信要求が送信遅延時間Td内で発生した場合、アプリケーションにはエラーのデータ送信結果が通知される（Ｓ５３）。このデータ送信結果が通知されたアプリケーション４は、通信制御手段６にデータ送信が可能となるタイミングの通知を受けるために送信可通知要求を行う（Ｓ６６）。送信可通知要求を受領した通信制御手段６は、送信遅延時間Tdの経過を待ってアプリケーション送信可通知を行う（Ｓ６７，Ｓ６８）。送信可通知を受領したアプリケーション４は通信制御手段６に対してデータ送信要求を実行する（Ｓ５１）。
【００４３】
上記フローにおけるＳ６２〜Ｓ６５のステップは、通信処理手段５が管理する送信バッファの残容量の状態により、アプリケーション４から要求されたサイズのデータを１回の通信処理では送信できない場合が想定され、このような場合には通信制御手段６からアプリケーション４に通知される送信完了データ量がデータ送信要求したデータ量より小さく報告されることに対処するために設けられたものであり、このような場合が想定されなければ不要である。
【００４４】
図６は、本発明が適用された通信装置の他の実施形態を示すブロック図であり、通信制御手段をアプリケーション毎に異なるプログラムモジュール６−１〜６−ｎとして実装した場合の例である。なお、図中の図１と同じ符号は、同一あるいは同等部分を示す。通信トラフィック制限の処理は図５で示したフローと同様のフローに従って実行することが可能である。なお、この実施形態の通信装置においては、図５のＳ５７での通信制御条件参照処理に代えて、アプリケーション４が起動されるタイミングで、対応する通信制御手段６が通信制御条件８を参照するようにしてもよい。
【００４５】
図７は、本発明を通信トラフィック制限用プログラム（以下、制御プログラムと称す）として実現した場合のフローチャートである。アプリケーション４からデータの送信要求が発生されたとき（Ｓ７１）、通信トラフィック制限用プログラム９は、送信遅延時間Tdが経過しているか否かを判断することで該データの送信要求を許容するか否かを判断する（Ｓ７２）。
【００４６】
Ｓ７２で送信遅延時間Tdが経過していない（送信遅延時間Td内でデータの送信要求が発生）と判断すれば、該アプリケーション４に対してエラーのデータ送信結果を通知する（Ｓ７３）。また、Ｓ７２で送信遅延時間Tdが経過していると判断すれば、該アプリケーション４からのデータの送信要求を許容してデータ送信を実行させる（Ｓ７４）。
【００４７】
データの送信要求が許容されて該送信要求されたデータの送信が実行された後、該送信要求により送信されたデータの量を計測し、計測された送信データ量に基づき新たな送信遅延時間Td_newを算出する（Ｓ７５）。次に、算出された送信遅延時間Td_newを新たに送信遅延時間Tdとして設定し（Ｓ７６）、タイマによる遅延送信時間の計時を開始させる（Ｓ７７）。その後、データ送信結果をアプリケーション４に通知する（Ｓ７８）。データ送信結果には送信データ量が含まれる。
【００４８】
送信遅延時間Td内でデータの送信要求を発生し、エラーのデータ送信結果が通知されたアプリケーション４は、制御プログラム９にデータの送信が可能となるタイミングの通知を受けるために送信可通知要求を行う（Ｓ７３，Ｓ７９）。送信可通知要求を受領した制御プログラム９は、送信遅延時間Tdの経過を待ってアプリケーション４に送信可通知を行う（Ｓ８０，Ｓ８１）。送信可通知を受領したアプリケーション４は制御プログラム９に対してデータ送信要求を実行する（Ｓ７１）。
【００４９】
図８は、本発明が適用された通信装置のさらに他の実施形態を示すブロック図であり、制御条件管理手段７が管理する通信制御条件８を通信ネットワーク２経由で更新可能とした場合の例である。なお、図中の図６と同じ符号は、同一あるいは同等部分を示す。
【００５０】
本実施形態では、通信ネットワーク２上に、通信制御条件８を変更するために使用する通信制御条件変更端末９と通信制御条件変更サーバ１０が設置される。通信制御条件変更サーバ１０にはユーザ認証機能が具備される。
【００５１】
図９は、図８の実施形態における全体の処理フローを示す。通信制御条件８の変更を行う変更者は、まず、通信制御条件変更端末９から通信制御条件変更サーバ１０へアクセス要求を行う（Ｓ９１，Ｓ９２）。このとき、通信制御条件変更サーバ１０のユーザ認証機能により、アクセス要求している変更者の正当性が確認される（Ｓ９３，Ｓ９４）。ユーザ認証の結果、正当な変更者でないと判断された場合アクセスは拒否される（Ｓ９５）。
【００５２】
一方、変更者の正当性が確認された場合、変更者は通信制御条件を更新可能となる。変更者から通信制御条件変更要求（変更先通信装置識別情報，変更後通信制御条件）が送出されると（Ｓ９６）、通信制御条件変更サーバ１０はこの変更後通信制御条件を保持し（Ｓ９７）、変更先通信装置識別情報で識別される通信装置１に変更発生通知を行う（Ｓ９８）。変更発生通知を受領した通信装置１は、通信制御条件変更サーバ１０に保持されている変更後通信制御条件を取得し（Ｓ９９）、通信制御条件８を更新する（Ｓ１００）。
【００５３】
以上説明したように、本発明は、通信ネットワークに接続された各種通信装置に適用可能であり、アプリケーションの種類や通信内容によらず、特定のトラフィックパターンを有する通信トラフィックの発生を確実に制限することができる。
【図面の簡単な説明】
【００５４】
【図１】本発明が適用された通信装置（通信端末）の実施形態を示すブロック図である。
【図２】通信制御手順の一例を示すフローチャートである。
【図３】送信遅延時間の算出方法の例を示す図である。
【図４】送信遅延時間の算出方法の他の例を示す図である。
【図５】図１の実施形態における処理フローを示す図である。
【図６】本発明が適用された通信装置の他の実施形態を示すブロック図である。
【図７】本発明を通信トラフィック制限用プログラムとして実現した場合のフローチャートである。
【図８】本発明が適用された通信装置のさらに他の実施形態を示すブロック図である。
【図９】図８の実施形態における処理フローを示す図である。
【符号の説明】
【００５５】
１・・・通信装置（通信端末）、２・・・通信ネットワーク、３・・・サーバ、４，４−１〜４−ｎ・・・アプリケーション、５・・・通信処理手段、６，６−１〜６−ｎ・・・通信制御手段、７・・・制御条件管理手段、８・・・通信制御条件、９・・・通信制御条件変更端末、１０・・・通信制御条件変更サーバ
【図１】
2005277541.tif 000003
【図２】
2005277541.tif 000004
【図３】
2005277541.tif 000005
【図４】
2005277541.tif 000006
【図５】
2005277541.tif 000007
【図６】
2005277541.tif 000008
【図７】
2005277541.tif 000009
【図８】
2005277541.tif 000010
【図９】
2005277541.tif 000011