(57)【要約】【課題】アプリケーション脆弱性などのセキュリティー上の問題を回避しつつ、コネクションの確立及びタスクの有無の確認を可能にするサーバ装置を提供すること。【解決手段】サーバ計算機１とクライアント計算機２とは、互いの間でユーザ識別情報を接続要求パケットに格納する方法を取り決めておく。クライアント計算機２は、サーバ計算機１とコネクションを張るとき、サーバアプリケーションにおける自身のユーザ識別情報を接続要求パケットに格納して送信する。サーバ計算機１は、変換されたユーザ識別情報を取り出し、そのユーザ識別情報に基づいてアプリケーションのタスク格納テーブルを参照し、タスクが存在する場合には、接続要求確認パケットを送信しコネクションの確立を行う。【選択図】      図１
2006185194.tif 000002
【特許請求の範囲】
【請求項１】
クライアント装置へネットワーク上に確立したコネクションを介してサービスを提供するためのタスクを実行するタスク実行手段と、
前記クライアント装置に係るユーザ識別情報と、該ユーザ識別情報について前記タスク実行手段により実行すべきタスクの有無を示すタスク情報とを対応付けて記憶する記憶手段と、
前記クライアント装置から1又は複数の接続要求パケットを受信する受信手段と、
受信した1又は複数の前記接続要求パケットから、前記ユーザ識別情報を取得する第１の取得手段と、
取得した前記ユーザ識別情報に対応付けて前記記憶手段に記憶されている前記タスク情報を取得する第２の取得手段と、
少なくとも取得した前記タスク情報に基づいて、前記接続要求パケットによる接続要求を許可するか否か決定する決定手段と、
前記接続要求を許可すると決定された場合に、前記コネクションを確立させるためパケットを送信する送信手段とを備えたことを特徴とするサーバ装置。
【請求項２】
1又は複数の接続要求パケットへのユーザ識別情報の格納方法に関する情報を記憶する手段を更に備え、
前記第１の取得手段は、前記格納方法に関する情報に基づいて、受信した1又は複数の前記接続要求パケットから、前記クライアント装置に係るユーザ識別情報を取得することを特徴とする請求項１に記載のサーバ装置。
【請求項３】
前記送信手段は、前記接続要求を許可すると決定された場合に、前記コネクションを確立させるためパケットとして、前記接続要求パケットに対する接続要求確認パケットを、該接続要求パケットの送信元となる前記クライアント装置へ送信する送信手段とを備えたことを特徴とする請求項１に記載のサーバ装置。
【請求項４】
前記決定手段は、前記タスク情報により前記タスクが有ることが示されている場合に、前記コネクションを確立させると決定することを特徴とすることを特徴とする請求項１に記載のサーバ装置。
【請求項５】
前記ユーザ識別情報を含む前記接続要求パケットを受信した場合に、前記接続要求パケットによる接続要求を許可するための条件を、前記タスク情報以外の情報を基準として定義したポリシー情報を記憶する手段を更に備え、
前記決定手段は、
前記タスク情報により前記タスクが有ることが示されている場合に、前記接続要求を許可すると判断する第１の判断手段と、
前記タスク情報以外の情報が、取得された前記ユーザ識別情報に対応する前記ポリシー情報に係る前記条件を満たす場合に、前記接続要求を許可すると判断する第２の判断手段とを含み、
前記第１の判断手段及び前記第２の判断手段の両方において前記接続要求を許可すると判断された場合に、前記接続要求を許可すると決定することを特徴とする請求項１に記載のサーバ装置。
【請求項６】
前記ポリシー情報は、前記サーバ装置に応じて決定されるサーバポリシー情報と、前記クライアント装置に応じて決定されるクライアントポリシー情報との一方又は両方を含むものであることを特徴とする請求項５に記載のサーバ装置。
【請求項７】
前記ユーザ識別情報を含む前記接続要求パケットを受信した場合に、前記接続要求パケットによる接続要求を許可するための条件を、前記タスク情報以外の情報及び該ユーザ識別情報に係るクライアント装置又は該クライアント装置上で動作するクライアントアプリケーションの動作状態を示す動作モード情報を基準として定義したポリシー情報を記憶する手段と、
受信した1又は複数の前記接続要求パケットから、前記クライアント装置に係る動作モード情報を取得する第３の取得手段とを更に備え、
前記クライアント装置から1又は複数の接続要求パケットを受信する受信手段と、
前記決定手段は、
前記タスク情報により前記タスクが有ることが示されている場合に、前記接続要求を許可すると判断する第１の判断手段と、
前記タスク情報以外の情報及び前記動作モード情報が、取得された前記ユーザ識別情報に対応する前記ポリシー情報に係る前記条件を満たす場合に、前記接続要求を許可すると判断する第２の判断手段とを含み、
前記第１の判断手段及び前記第２の判断手段の両方において前記接続要求を許可すると判断された場合に、前記接続要求を許可すると決定することを特徴とする請求項１に記載のサーバ装置。
【請求項８】
1又は複数の接続要求パケットへの前記ユーザ動作モード情報の格納方法に関する情報を記憶する手段を更に備え、
前記第３の取得手段は、前記格納方法に関する情報に基づいて、受信した1又は複数の前記接続要求パケットから、前記クライアント装置に係るユーザ動作モード情報を取得することを特徴とする請求項７に記載のサーバ装置。
【請求項９】
クライアント装置へネットワーク上に確立したコネクションを介してサービスを提供するためのタスクを実行するタスク実行手段、及び前記クライアント装置に係るユーザ識別情報と、該ユーザ識別情報について前記タスク実行手段により実行すべきタスクの有無を示すタスク情報とを対応付けて記憶する記憶手段とを備えたサーバ装置における通信制御方法であって、
前記クライアント装置から1又は複数の接続要求パケットを受信する受信ステップと、
受信した1又は複数の前記接続要求パケットから、前記ユーザ識別情報を取得する第１の取得ステップと、
取得した前記ユーザ識別情報に対応付けて前記記憶手段に記憶されている前記タスク情報を取得する第２の取得ステップと、
少なくとも取得した前記タスク情報に基づいて、前記コネクションを確立させるか否かを決定する決定ステップと、
前記コネクションを確立させると決定された場合に、前記コネクションを確立させるためパケットを送信する送信ステップとを有することを特徴とする通信制御方法。
【請求項１０】
クライアント装置へネットワーク上に確立したコネクションを介してサービスを提供するためのタスクを実行するタスク実行手段、及び前記クライアント装置に係るユーザ識別情報と、該ユーザ識別情報について前記タスク実行手段により実行すべきタスクの有無を示すタスク情報とを対応付けて記憶する記憶手段とを備えたサーバ装置としてコンピュータを機能させるためのプログラムにおいて、
前記プログラムは、
前記クライアント装置から1又は複数の接続要求パケットを受信する受信ステップと、
受信した1又は複数の前記接続要求パケットから、前記ユーザ識別情報を取得する第１の取得ステップと、
取得した前記ユーザ識別情報に対応付けて前記記憶手段に記憶されている前記タスク情報を取得する第２の取得ステップと、
少なくとも取得した前記タスク情報に基づいて、前記コネクションを確立させるか否かを決定する決定ステップと、
前記コネクションを確立させると決定された場合に、前記コネクションを確立させるためパケットを送信する送信ステップとをコンピュータに実行させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、クライアント装置へコネクションを介してサービスを提供するサーバ装置、このコネクションの確立に対する通信制御方法及びプログラムに関する。
【背景技術】
【０００２】
近年、インターネット等を利用し、不特定多数又は特定多数のクライアント計算機をパケット交換ネットワーク経由でサーバ計算機に接続し、クライアント計算機からの要求に応じてサーバ計算機からデータを供給することを目的とするクライアントサーバシステムが広く使われている。ここで、パケットとは、ネットワーク上を流れるひとかたまりのデータを言い、大まかに分けると、始点ＩＰ(Internet Protocol)アドレス、終点ＩＰアドレス等を含むヘッダと、データ本体とで構成されている。
【０００３】
クライアントサーバシステムにおいては、サーバ計算機上で動作しているサーバアプリケーションプログラム（以下、サーバアプリケーション）がアクセスしてきたクライアント計算機上で動作しているクライアントアプリケーションプログラム（以下、クライアントアプリケーション）に対してサービスを提供するが、その際に、サーバアプリケーションが接続要求元（要求を送出したクライアント計算機上で動作しているクライアントアプリケーションのユーザ）の識別を行い（すなわち、ユーザ識別情報を取得し）、識別した相手に対してサーバアプリケーションが行うべき処理（以下、タスク）の有無を確認して、タスクが有ることが確認された場合にサービスを提供する方式がある。
【０００４】
この方式では、サーバ計算機とクライアント計算機との間でコネクションを確立した上で、ユーザ識別情報を取得し、タスクの有無の確認を行うので、アプリケーション脆弱性や、ＤｏＳ攻撃(Denial of Service attack)又はＤＤｏＳ攻撃(Distributed Denial of Service attack)などが大きな問題になる。
【０００５】
特許文献１には、ユーザからのアクセスに対するユーザＩＤ及びパスワードの認証の迅速化を図る技術が開示されているが、この技術で上記のセキュリティー上の問題を解決することはできない。
【特許文献１】特開２００３−９１５０４公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
従来のクライアントサーバシステムにおいては、接続要求元に対応するタスクの有無の確認に伴うセキュリティー上の問題を回避することができなかった。
【０００７】
本発明は、上記事情を考慮してなされたもので、クライアントサーバシステムにおいて、アプリケーション脆弱性、ＤｏＳ攻撃、ＤＤｏＳ攻撃などのセキュリティー上の問題を回避しつつ、コネクションの確立及びタスクの有無の確認を可能にするサーバ装置、通信制御方法及びプログラムを提供することを目的とする。
【課題を解決するための手段】
【０００８】
本発明に係るサーバ装置は、クライアント装置へネットワーク上に確立したコネクションを介してサービスを提供するためのタスクを実行するタスク実行手段と、前記クライアント装置に係るユーザ識別情報と、該ユーザ識別情報について前記タスク実行手段により実行すべきタスクの有無を示すタスク情報とを対応付けて記憶する記憶手段と、前記クライアント装置から1又は複数の接続要求パケットを受信する受信手段と、受信した1又は複数の前記接続要求パケットから、前記ユーザ識別情報を取得する第１の取得手段と、取得した前記ユーザ識別情報に対応付けて前記記憶手段に記憶されている前記タスク情報を取得する第２の取得手段と、少なくとも取得した前記タスク情報に基づいて、前記接続要求パケットによる接続要求を許可するか否か決定する決定手段と、前記接続要求を許可すると決定された場合に、前記コネクションを確立させるためパケットを送信する送信手段とを備えたことを特徴とする。
【０００９】
本発明によれば、クライアントサーバシステムにおいて、セキュリティー上の問題を回避しつつ、コネクションの確立及びタスクの有無の確認を可能にする。また、正当なユーザ識別情報を送信し且つユーザ識別情報に関連するタスクが存在している接続要求元に対してのみコネクションの確立を許可することができるため、無条件にコネクションを確立することによる問題を防止することができ、これにより当該サーバ装置のセキュリティーをより一層向上させることができる。
【００１０】
なお、装置に係る本発明は方法に係る発明としても成立し、方法に係る本発明は装置に係る発明としても成立する。  
また、装置または方法に係る本発明は、コンピュータに当該発明に相当する手順を実行させるための（あるいはコンピュータを当該発明に相当する手段として機能させるための、あるいはコンピュータに当該発明に相当する機能を実現させるための）プログラムとしても成立し、該プログラムを記録したコンピュータ読み取り可能な記録媒体としても成立する。
【発明の効果】
【００１１】
本発明によれば、クライアントサーバシステムにおいて、セキュリティー上の問題を回避しつつ、コネクションの確立及びタスクの有無の確認を可能にする。
【発明を実施するための最良の形態】
【００１２】
以下、図面を参照しながら本発明の実施形態について説明する。
【００１３】
本実施形態では、サーバ計算機上で動作しているサーバアプリケーションがアクセスしてきたクライアント計算機上で動作しているクライアントアプリケーションに対してサービスを提供する際に、サーバアプリケーションが接続要求元（要求を送出したクライアント計算機上で動作しているクライアントアプリケーションのユーザ）のユーザ識別情報を取得し、識別した相手に対してサーバアプリケーションが行うべき処理（タスク）の有無を確認して、タスクが有ることが確認された場合にサービスを提供するクライアントサーバシステムを想定して説明する。
【００１４】
接続要求元は、前述したように、要求を送出したクライアント計算機上で動作しているクライアントアプリケーションのユーザを意味するものとしている。また、ユーザ識別情報は、サーバアプリケーションがその接続要求元すなわちユーザの識別のために利用している情報であり、ユーザを一意に識別する情報である。
【００１５】
このようなユーザ識別情報に基づくタスクの確認作業は、電子メールの配信（到着済み電子メールのクライアントの電子メールアプリケーションへの配信タスクにおける電子メールの到着を確認するケース）や、ネットワーク対応家庭電化製品において行われている中継サーバを利用した遠隔制御方式（例えば、ネットワーク対応のＤＶＤレコーダにおいて、ＤＶＤレコーダに対する録画予約等のタスクを、携帯電話等を用いてインターネット上の中継サーバに登録し、ＤＶＤレコーダがその中継サーバに対して録画すべき番組の有無を定期的に問い合わせるケース）などにおいて広く利用されている。この方式により、クライアントアプリケーションを実行するクライアント計算機のユーザ（すなわち、接続要求元）は、サーバアプリケーションにおける自身に関連するタスクの有無の変化に応じて、サービスを享受できる。
【００１６】
また、本実施形態では、サーバ計算機とクライアント計算機との間の通信はＴＣＰ／ＩＰ(Transmission Control Protocol/IP)で行われる場合を例にとって説明する。
【００１７】
ここで、従来のクライアントサーバシステムにおける問題点について詳しく説明する。
【００１８】
従来、タスクの有無の確認作業は以下のように行われている。  
（１）クライアントアプリケーションからのタスク確認要求に応じて、サーバ計算機とクライアント計算機との間でコネクションを確立する。これによりクライアントアプリケーションの要求に応じた形で、サーバアプリケーションの処理が開始する。
【００１９】
（２）クライアントアプリケーションは確立したコネクションを利用してサーバアプリケーションに対して、ユーザ識別情報（サーバアプリケーションが接続要求元の識別のために利用している情報）を送信する。   
（３）サーバアプリケーションでは（１）で確立したコネクションで受信したユーザ識別情報を検索キーとして用いて、ユーザ識別情報とその主体に関連したタスクの有無が記載されたデータベース（以下、タスク格納テーブル）を検索する。  
（４）タスクが存在する場合にはそのタスクを実行し、タスクが存在しない場合にはコネクションを切断する。
【００２０】
サーバアプリケーションとクライアントアプリケーションとの間で、クライアントアプリケーションがユーザ識別情報とタスク格納テーブルを利用してタスクの有無を確認することで、サーバアプリケーションがクライアントアプリケーションへタスクの状況変化のつど通知する必要がなく、また、サーバ計算機からクライアント計算機へ送信される接続要求パケットが途中のネットワーク装置により破棄され届かないような状況においても、接続要求元が必要なときにタスクの有無を確認することができる。
【００２１】
しかし、上記の（１）〜（４）のような従来の方式においては、サーバ計算機とクライアント計算機との間でコネクションを確立した上で、ユーザ識別情報を取得し、タスクの有無の確認を行う（つまり、タスクの確認とコネクションの確立が一体となっている）ので、サーバ計算機は、処理すべきタスクを持たない接続要求元に係るクライアント計算機からの接続要求に対してもコネクションを確立した上で、ユーザ識別情報を取得し、その情報を利用してタスクが存在しないことを確認し、接続要求元に係るクライアント計算機に通知するようなことになる。この結果、次のようなアプリケーション脆弱性や、ＤｏＳ攻撃(Denial of Service attack)又はＤＤｏＳ攻撃(Distributed Denial of Service attack)などのセキュリティー上の問題が生じる。
【００２２】
（１）サーバアプリケーションのアプリケーション脆弱性を攻撃可能
アプリケーション脆弱性とは、アプリケーションソフトウェアに潜在するバグのことであり、攻撃者はバグを利用することで、攻撃対象の計算機の特権を得たりすることが可能となる。攻撃者は、まず、コネクションを確立し、その確立したコネクションでアプリケーション脆弱性を攻撃するデータを送信する。かりにサーバアプリケーションに認証機能が存在し、認証が行われていないクライアントとはやりとりされるデータ・状況が限られているとしても、その認証部分自体にアプリケーション脆弱性が存在する可能性がある。例えば、インターネット越しに計算機の安全な遠隔操作を実現するプロトコルであるＳＳＨ(Secure Shell)やＷｅｂ閲覧や情報送信を安全にするプロトコルであるＳＳＬ(Secure Sockets Layer)に関しても認証部分にアプリケーション脆弱性がみつかることもしばしばである。以上の攻撃は、ＴＣＰ上で動作するサーバアプリケーションに対してはＴＣＰコネクションを確立しなければ行うことはできない。
【００２３】
（２）無差別なコネクション確立により、サーバのリソースに対する攻撃が可能
不正なクライアントがコネクションを大量に確立することでサーバ計算機のコネクション処理用リソースを使い切るようなＤｏＳ攻撃(Denial of Service attack)及びＤＤｏＳ攻撃(Distributed Denial of Service attack)が起こりえる。ここで、ＤｏＳ攻撃とは、正当なクライアントが使用するはずのリソースを、不正なクライアントが使い切る、もしくはリソースを使えない状態にすることで、正当な使用者によるリソース使用を妨げるハッキング行為である。そして、ＤＤｏＳ攻撃は複数のクライアント計算機によって行われるＤｏＳ攻撃を指す。このようなコネクションを確立することによる攻撃は、ＳＳＬ，ＳＳＨなど暗号処理を含み高い計算機負荷を必要とするアプリケーションを利用している状況では大きな問題となる。
【００２４】
以上のように、無差別にコネクションの確立を許すことはセキュリティー上の問題点を引き起こすため、タスクの有無の確認においても不必要なコネクションは確立しないことが望ましい。一般に、このようなセキュリティー上の問題は、ＴＣＰ／ＩＰのＴＣＰ層、ＩＰ層でクライアント計算機に対するＴＣＰコネクション確立制御を行うことで解決することができる。そして、これによってサーバアプリケーションのセキュリティーをより一層向上させることが可能である。
【００２５】
図１に、本発明の一実施形態に係る通信システムの構成例を示す。
【００２６】
図１では、１台のサーバ計算機（サーバ装置）１と、複数台のクライアント計算機（クライアント装置）２とが存在し、それらが、インターネットなどのオープンなネットワーク及びこれに接続された専用線などを含む各種通信ネットワーク３で接続される例を示している。なお、図１では、サーバ計算機１を１台のみ示したが、もちろん、サーバ計算機１は２以上の任意の台数存在して構わない。また、サーバ計算機は、サーバ機能を有する汎用計算機以外の装置であってもよいし、クライアント計算機は、クライアント機能を有する汎用計算機以外の装置（例えば、携帯電話、ネットワーク家電など）であってもよいが、以下では、サーバ計算機と、クライアント計算機の語句を使用して説明する。
【００２７】
前述のように、サーバ計算機１とクライアント計算機２との間の通信は、ＴＣＰ／ＩＰで行われる場合を例にとる。ＴＣＰ／ＩＰは、下位層から上位層へ順に、ネットワークアクセス層、ネットワーク層、トランスポート層、アプリケーション層に分離される。
【００２８】
ネットワークアクセス層は、ＯＳＩ(Open Systems Interconnection)参照モデルの物理層、データリンク層を合わせたものに相当し、電気信号や光信号によるデータの送受信と、隣接ノードとの間で情報のフローを調整するために必要な制御を可能とする処理層である。
【００２９】
ネットワーク（インターネット）層は、ＯＳＩ参照モデルのネットワーク層に相当し、ネットワーク間でのデータのルーティングと通信目的の計算機へのデータ配信を担当する処理層である。
【００３０】
トランスポート層は、ＯＳＩ参照モデルのトランスポート層にほぼ相当し、指定されたアプリケーション層ポートへの配信サービスとデータのエラーチェック機能を提供する処理層である。トランスポート層では、ＴＣＰ(Transmission Control Protocol)とＵＤＰ(User Datagram Protocol)の２つのプロトコルが利用可能である。後述するようにＴＣＰではコネクション型環境を提供し、データの到達性を保証する。それに対して、ＵＤＰはコネクションレス型環境を提供し、データの到達性を保証しない。
【００３１】
アプリケーション層は、ＯＳＩ参照モデルのアプリケーション層に相当し、アプリケーションがデータ送受信を行うための通信処理制御や、アプリケーション固有の処理を行う処理層である。
【００３２】
ネットワーク層より上位層での通信は、ＩＰパケットで行われる。
【００３３】
図２に、一般的なＩＰパケットの構成を示す。
【００３４】
（ａ）に示されるように、ＩＰパケットは、ＩＰヘッダ部とデータ部とから構成される。
【００３５】
（ｂ）に示されるように、ＩＰヘッダ部は、ＩＰのバージョン（ＩＰｖ４、ＩＰｖ６等）を示す「バージョン」、ＩＰヘッダ部のヘッダ長を示す「ヘッダ長」、通信サービスの品質をルータに指示するための「サービスタイプ」、ＩＰパケット全体の長さ（パケット長）を示す「パケット長」、フラグメントを復元する際の識別子である「識別子」、分割処理を制御するための「フラグ」、分割された場合の位置を示すための「フラグメントオフセット」、通過できるルータの個数を示す「生存時間」、上位層のプロトコルを示す「プロトコル番号」（例えば、ＩＣＭＰは１、ＴＣＰは６、ＵＤＰは１７）、データが破損していないことを保証するための「ヘッダチェックサム」、送信元のアドレスを示す「始点ＩＰアドレス」、送信先のアドレスを示す「終点ＩＰアドレス」、種々のオプション機能に利用するための「オプション」、ＩＰヘッダのヘッダ長が３２ビットの整数倍になるよう調整する「パディング」の各情報からなる。
【００３６】
他方、データ部には、ＴＣＰ、ＵＤＰ又はＩＣＭＰのセグメントが含まれる。
【００３７】
図３に、一般的なＴＣＰセグメントの構成を示す。
【００３８】
図３に示されるように、ＴＣＰセグメントは、ＴＣＰヘッダとデータ部分とから構成される。
【００３９】
ＴＣＰヘッダは、送信元のポート番号を示す「始点ポート番号」、送信先のポート番号を示す「終点ポート番号」、送信したデータの位置を示す「シーケンス番号」、受信したデータの位置を示す「確認応答番号」、ＴＣＰが運んでいるデータの開始位置を示す「データオフセット」、拡張用の「予約ビット」、ＴＣＰセグメントの処理方法や種別を示す「コントロールフラグ」、フロー制御に用いられ、受信可能なデータ長を示す「ウィンドウサイズ」、ＴＣＰのヘッダ、データが損傷していないことを保証するための「チェックサム」、緊急に処理すべきデータの位置を示す「緊急ポインタ」、ＴＣＰによる通信性能の向上に用いる「オプション」、「パディング」の各情報からなる。
【００４０】
図４に、一般的なＵＤＰセグメントの構成を示す。
【００４１】
図４に示されるように、ＵＤＰセグメントは、ＵＤＰヘッダとデータ部分とから構成される。
【００４２】
ＵＤＰヘッダは、送信元のポート番号を示す「始点ポート番号」、送信先のポート番号を示す「終点ポート番号」、このＵＤＰセグメントの長さを示す「パケット長」、ＵＤＰのヘッダ、ＩＰアドレス、プロトコル番号が損傷していないことを保証するための「チェックサム」の各情報からなる。
【００４３】
ＴＣＰ／ＩＰプロトコルにおける正当なアクセス要求の一例としては、  
（１）クライアント計算機がサーバ計算機へ接続要求パケット（ＳＹＮ(SYNchronize)パケット）を送信し、  
（２）サーバ計算機がクライアント計算機へ接続要求確認パケット（ＳＹＮ＋ＡＣＫ(ACKnowledgement)パケット）を送信し、  
（３）クライアント計算機がサーバ計算機へ確認応答パケット（ＡＣＫ）パケットを送る、  
という手順により、
計算機間で論理的な通信路（コネクション）を確立し、そのコネクション確立(Established)状態で、上位アプリケーションでのデータの送受信を行う。このアクセス要求の方式を、3 way handshake方式と呼ぶ。
【００４４】
論理的なポートは、６５５３５番まで利用することが許可されている。また、ＴＣＰにおけるコネクション制御に関係するその他の種類のパケットとして、ＵＲＧパケット（緊急情報であることを示す）、ＰＳＨパケット（受信者が早急にアプリケーションにこのパケットのデータを渡す必要があることを示す）、ＲＳＴパケット（コネクションをリセットする）、ＦＩＮパケット（送り手がデータの送信を終了したことを通知する）などが存在する。
【００４５】
なお、ＵＤＰ、ＩＣＭＰは、コネクションレスの通信であるため、このようなコネクション確立の処理は行われず、データの送受信が行われる。
【００４６】
図５に、本実施形態のクライアント計算機２の構成例を示す。なお、図５では、確認手続きを含むコネクション制御に関する部分の機能ブロックを中心に示している。
【００４７】
図５に示されるように、本クライアント計算機２は、接続要求パケット生成部２１、送信部２２、受信部２３、接続要求確認パケット判定部２４、クライアントアプリケーション処理部２５、格納規則テーブル２６、確認応答パケット生成部２７を備えている。
【００４８】
クライアントアプリケーション処理部２５は、サーバアプリケーションに対するクライアント機能をもつ処理部である。サーバアプリケーションに接続する際には、サーバアプリケーションと共有したユーザ識別情報を、接続要求パケット生成部２１に通知する。このユーザ識別情報は、クライアントアプリケーションに格納したユーザ識別情報を利用してもよいし、接続の都度、クライアントアプリケーションを実行しているユーザに対して入力を求めるようにしてもよいし、他の方法によってもよい。
【００４９】
接続要求パケット生成部２１は、クライアントアプリケーションからサーバ計算機１へタスクの有無を確認するための接続要求を行う旨の指示を受けた際に、接続要求パケットを生成する。接続要求パケット生成部２１は、クライアントアプリケーション処理部２５から通知されたユーザ識別情報を格納する接続要求パケットを、格納規則テーブル２６に基づいて生成する。
【００５０】
送信部２２は、ＩＰパケットをネットワーク３へ送出するものであり、接続要求パケット生成部２１によって生成された各接続要求パケットをネットワーク３へ順次送出し、また、その他のパケットを送出する。
【００５１】
受信部２３は、ネットワーク３からの自計算機宛てのＩＰパケットを受信する。受信されたＩＰパケットは、接続要求確認パケット判定部２４へ送られる。
【００５２】
接続要求確認パケット判定部２４は、このＩＰパケットが、送信部２２より送信した各接続要求パケットの何れかに対してサーバ計算機１から応答された接続要求確認パケットであるか否かを判定する。この判定処理により、接続要求確認パケットとされた場合には、接続要求元に関連するタスクがサーバ計算機１のサーバアプリケーションに存在することを意味する。接続要求確認パケットは、確認応答パケット生成部２７へ渡され、それ以外のパケットは適切な処理部へ渡される。
【００５３】
確認応答パケット生成部２７は、上記判定処理において接続要求確認パケットとされた場合には、サーバ計算機１とのコネクションを確立するためのコネクション制御を行なう。具体的には、確認応答パケットを生成し、これを送信部２２を介してサーバ計算機１へ送出する。
【００５４】
ここで、格納規則テーブル２６について詳しく説明する。
【００５５】
格納規則テーブル２６は、接続要求元に係るクライアント計算機２とサーバ計算機１との間で予め共有された、接続要求パケットへのユーザ識別情報の格納規則を記述したテーブルである。
【００５６】
この格納規則としては、一つの接続要求パケットを生成し、その特定のフィールドを利用して値を埋め込んだり（オプションフィールドやシーケンス番号フィールドなど）、そのペイロード部分に埋め込んだり、複数の接続要求パケットを生成し、その特定のフィールドにユーザ識別情報を分割して埋め込む（長い情報を埋め込むことができ、ペイロードを利用する方法に比較して通信に悪影響を与えにくい）などして、直接ユーザ識別情報を格納した接続要求パケットを利用する方法がある。その他に、複数の接続要求パケットを利用し、その個数や時間間隔などによってユーザ識別情報を表現する方法なども考えられる。なお、接続要求パケットに格納するユーザ識別情報は、単にユーザ識別情報をそのまま利用することも、特定の符号化処理を施すことも可能である。ようするに、サーバ計算機１とクライアント計算機２との間で予め共有された変換規則を用いて、接続要求パケットにユーザ識別情報の埋め込みが可能となるように変換すればよく、この識別情報の変換ルール自体は、サーバ計算機１と共有されていれば、各アプリケーションに固有であったり、１又は複数のアプリケーションを含む各アプリケーション・グループに固有であったり、各クライアントに固有であったり、１又は複数のクライアントを含む各クライアント・グループに固有であったり、各ユーザ識別情報に固有であったり、１又は複数のユーザ識別情報を含む各ユーザ識別情報グループに固有であったりしてもよい。
【００５７】
また、ユーザ識別情報に加えてパスワードを送信したり、予め共有した暗号鍵を利用したなんらかの暗号処理によりユーザ識別情報を変換・送信することも可能である。このようにすることで、接続要求パケットを送信してきたのが正当な接続要求元に係るクライアント計算機であることを確認したり、接続要求パケットに格納されたユーザ識別情報の機密性を保ったりすることが可能となる。
【００５８】
なお、このユーザ識別情報の格納・取得の規則（およびユーザ識別情報の変換を行う場合には変換規則やパスワードや暗号化を行う場合には暗号鍵も）は、クライアント計算機２とサーバ計算機１との間で秘密に共有されていることが望ましい。これは、暗号プロトコルを用いて確保されたセキュアチャネル（このような既存技術としてはＳＳＬ(Secure Socket Layer)などがある）を利用してオンラインで行ったり、郵送などのオフラインで行ったりすることで可能である。
【００５９】
また、接続要求元に係るクライアント計算機２は、複数のサーバアプリケーション等に応じて異なる格納規則を保持していてもよい。
【００６０】
また、予め接続要求パケットへのユーザ識別情報の格納方法を唯一のものに固定する場合には、この格納規則テーブルを省略することができる。
【００６１】
図６に、本実施形態のサーバ計算機１の構成例を示す。なお、図６では、確認手続きを含むコネクション制御に関する部分の機能ブロックを中心に示している。
【００６２】
図６に示されるように、本サーバ計算機１は、受信部１１、判断部１２、識別情報取得部１３、タスク情報取得部１４、結果判定部１５、接続要求確認パケット生成部１６、送信部１７、サーバアプリケーション処理部１８、取得規則テーブル１９、タスク格納テーブル２０を備えている。
【００６３】
タスク格納テーブル２０は、少なくとも、サーバアプリケーションにおけるユーザの識別情報（ユーザ識別情報）と、そのユーザ識別情報に対するタスクの有無とを対応付けて記載した情報を含む。タスク格納テーブル２０は、タスク情報取得部１４とアプリケーション処理部１８とからアクセスされ、アプリケーション処理部１８における各時点でのタスクの有無を示すタスク情報を記録している。
【００６４】
サーバアプリケーション処理部１８は、ユーザ識別情報に応じた処理を実行しており、そのユーザ識別情報に関するタスクの情報の変化を、タスク格納テーブル２０に格納する。想定するサーバアプリケーションはさまざまであるが、それぞれ、ユーザ識別情報に関連したタスクの管理をおこなっており、タスク変化の様子をタスク格納テーブル２０に随時記録している。例えば、サーバアプリケーションが電子メール蓄積サーバであるとすると、あるユーザの前回のメールの有無の問い合わせ時刻からの、各ユーザの電子メールの増加の有無についてタスク格納テーブル２０に格納している。かりに電子メールが到着していた場合には、サーバアプリケーションがタスク無からタスク有にタスク格納テーブル２０の記述を更新する。
【００６５】
受信部１１は、ネットワーク３からの自計算機宛てのＩＰパケットを受信する。受信されたＩＰパケットは、判断部１２へ送られる。
【００６６】
判断部１２は、受信部１１で受信したＩＰパケットの内容に基づいて、その送り先を判断する。受信したＩＰパケットが、接続要求パケットであり、宛先ポート番号がサーバアプリケーションプログラムのものである場合には、これを識別情報取得部１３へ渡す。それ以外のパケットは適切な処理部へ渡される。
【００６７】
識別情報取得部１３は、接続要求元に係るクライアント計算機２と予め共有したユーザ識別情報の格納規則が記述された格納規則テーブル１９を利用して、受信した接続要求パケットからユーザ識別情報を取得する。
【００６８】
タスク情報取得部１４は、ユーザ識別情報をもとにしてタスク格納テーブル２０を検索し、ユーザ識別情報に対応するタスク情報を取得する。
【００６９】
結果判定部１５は、取得されたユーザ識別情報に対応するタスク情報が示すタスクの有無を確認し、接続を許可するか拒否するかの判断（すなわち、接続要求元に係るクライアント計算機２との間のコネクションを確立させるか否かの判断）を行い、その結果に応じて指示を出す処理を行う。タスクが存在することが確認された場合には、接続を許可すると判断し（すなわち、コネクションを確立させると判断し）、接続要求確認パケット生成部１６に、受信した接続要求パケットに対して返答を返すように指示し、それ以外の場合には、接続を許可しないと判断し（すなわち、コネクションを確立させないと判断し）、何もしない（後述するように、明示的に応答パケットを返す方法も可能である）。なお、後述するバリエーションでは、ポリシーに基づいた接続可否の判断をも併用する。
【００７０】
接続要求確認パケット生成部１６は、結果判定部１５からの指示に応じて、コネクションを確立させるためのパケットとして、受信した接続要求パケットに対する接続要求確認パケットを生成する。
【００７１】
送信部１７は、ＩＰパケットをネットワーク３へ送出するものであり、接続要求確認パケット生成部１６によって生成された接続要求確認をネットワーク３へ送出し、また、その他のパケットを送出する。
【００７２】
なお、上記では、結果判定部１５は、タスクが存在することが確認された場合にのみ、接続要求確認パケット生成部１６に指示を行ったが、その代わりに、タスクが存在することが確認された場合には、接続要求確認パケット生成部１６に、接続要求確認パケットを返すように指示し、それ以外の場合には、タスクが無い旨の応答パケットを返すように指示し、接続要求確認パケット生成部１６は、結果判定部１５からの指示に応じて、接続要求確認パケット又はタスクが無い旨の応答パケットを生成し、送信部１７から送出するようにしてもよい。
【００７３】
取得規則テーブル１９は、識別情報取得部１３が参照して、受信した接続要求パケットに格納されたユーザ識別情報を取得する。このテーブルには、接続要求パケットへのユーザ識別情報の格納規則が記述されている。この格納規則は、前述したとおりである（暗号を利用する場合についても前述した通りである）。ようするに、サーバ計算機１とクライアント計算機２との間で予め共有された変換規則を用いて、接続要求パケットからのユーザ識別情報の抽出が可能となるようにすればよく、この識別情報の変換ルール自体は、クライアント計算機２と共有されていれば、前述のように、各アプリケーションや各クライアントや各ユーザ識別情報等に固有であったりしてもよい。
【００７４】
なお、予め接続要求パケットへのユーザ識別情報の格納方法を唯一のものに固定する場合には、この格納規則テーブルを省略することができる。
【００７５】
ただし、格納規則は、クライアント計算機２とサーバ計算機１で同一になる場合と、対応するものになる場合とがある。例えば、一つの接続要求パケットの特定のフィールドに値を埋め込む場合に、その特定のフィールドを示す情報を共有してもよい。また、例えば、複数の接続要求パケットの特定のフィールドに値を分散して埋め込む場合には、クライアント計算機２では、ユーザ識別情報の複数のパケットへの分散のさせ方（例えば、ユーザ識別情報を上位ビットと下位ビットの２つに分割し、上位ビットを第１のパケットの特定フィールドに埋め込み、下位ビットを第２のパケットの特定フィールドに埋め込む）を保持し、サーバ計算機１では、複数のパケットからのユーザ識別情報の復元のさせ方（例えば、第１のパケットの特定フィールドから値を抽出して、これをユーザ識別情報の上位ビットとし、第２のパケットの特定フィールドから値を抽出して、これをユーザ識別情報の下位ビットとし、それら抽出した値を順番に接続してユーザ識別情報を復元する）を保持するようにしてもよい。
【００７６】
サーバ計算機１がクライアント計算機２のユーザ識別情報を確認する方法やユーザ識別情報を構成する方法については、様々な方法を用いることが可能である。
【００７７】
以下では、これまで説明してきた構成をもとにして、各コネクション確立制御方法を例示し、その際の、クライアント計算機２とサーバ計算機１との動作について説明する。
【００７８】
（第１のシステム構成例）
まず、ユーザ識別情報のみを用いてタスクを検索し、コネクション制御処理を行う例について説明する。
【００７９】
図７に、本構成例の場合のタスク格納テーブル２０の構成例を示す。
【００８０】
このタスク格納テーブル２０には、ユーザ識別情報と、そのユーザ識別情報に対するタスクの有無に関する現在情報とが記載されている。このタスクの有無の情報は、アプリケーション処理部１８によって随時更新される。
【００８１】
図７の例においては、ユーザ識別情報として数値を利用しているが、ユーザ名のような文字列であっても構わない。この場合、接続要求パケットには、符号化されたデータを格納すればよい。
【００８２】
図８に、本構成例の場合のクライアント計算機２の処理手順の一例を示し、図９に、本構成例の場合のサーバ計算機１の処理手順の一例を示す。
【００８３】
まず、図８を参照しながら、本構成例のクライアント計算機２の処理手順例について説明する。
【００８４】
クライアント計算機２は、サーバ計算機１のあるサーバアプリケーションに接続する場合、まず、クライアントアプリケーション処理部２５により接続要求元のユーザ識別情報を取得する（ステップＳ１）。
【００８５】
次に、クライアント計算機２は、接続要求パケット生成部２１により格納規則テーブル２６を参照して入手したユーザ識別情報を格納した接続要求パケットを生成する（ステップＳ２）。
【００８６】
この場合に格納規則テーブル２６に記述されている格納規則としては、前述のようにさまざまな方法が考えられるが、ようするに、サーバ計算機１とクライアント計算機２との間で予め共有された格納規則があり、その規則に基づいてユーザ識別情報を接続要求パケットに格納すればよい。そして、前述のように、この格納規則自体は、サーバ計算機１と共有されていれば、各アプリケーションや各クライアントや各ユーザ識別情報等に固有であったりしてもよい。また、必ずしもユーザ識別情報そのものを接続要求パケットに格納して送信する必要はなく、ユーザ識別情報の意図する情報が損なわれない範囲であれば、クライアント計算機２とサーバ計算機１とで共有した変換規則にもとづいてユーザ識別情報を別の情報に変換し、その情報を接続要求パケットに格納してもよい。これにより、接続要求パケット生成部２１および識別情報取得部１３において利用しやすく、既存のネットワークインフラと整合性がよい形で接続要求パケットを用いたユーザ識別情報の伝達が可能となる。
【００８７】
次に、クライアント計算機２は、作成したユーザ識別情報を格納した接続要求パケットを、送信部２２によりサーバ計算機１に送信する（ステップＳ３）。ここで、接続要求パケットへのユーザ識別情報の格納方法によっては、複数の接続要求パケットが送信される場合もある。
【００８８】
クライアント計算機２は、全ての接続要求パケットを送信したことを確認すると、サーバ計算機１からの接続要求確認パケットを待ち受ける（ステップＳ４）。
【００８９】
クライアント計算機２は、サーバ計算機１からの応答があったかを判断し（ステップＳ５）、応答がない場合には、タスクが存在せずコネクション確立の必要がないものと判断して処理を終了する。
【００９０】
他方、クライアント計算機２は、サーバ計算機１から送信した接続要求パケットに対する接続要求確認パケットを受信した場合には、それに対して応答確認パケットを送信する（ステップＳ６）。このことは、サーバ計算機１のアプリケーションにおいて、接続要求元に対するタスクが存在していることを意味する。このことにより、無駄なＴＣＰコネクションが確立されることを防止し、タスクが存在する場合にのみコネクションを確立させることができる。
【００９１】
なお、ステップＳ３において複数の接続要求パケットが送信されている場合には、複数の接続要求パケットのいずれかに対する接続要求確認パケットが送信されたかどうかを確認して、その確認後、コネクションを確立すればよい。
【００９２】
また、上記においては、クライアント計算機２は、接続要求パケットに対する返答を待ち受けて、それがない場合にはコネクション確立をあきらめるとしたが、タスクが無い旨の応答パケットとして、例えば、ＲＳＴパケット、ＦＩＮパケットの受信などによってタスクが存在しないと判断してもよい。こうすることで、クライアント計算機２はタスクが存在しない場合に、接続要求パケットはきちんとサーバに受信されていることを確認できる。
【００９３】
次に、図９を参照しながら、本構成例のサーバ計算機１の処理手順の一例について説明する。
【００９４】
サーバ計算機１は、受信部１１でパケットを受信すると、判定部１２を利用して受信したパケットの判別を行い、受信パケットが接続要求パケットであり、その宛先ポート番号がアプリケーション処理部２５において実行されているサーバアプリケーションのものであることを確認する（ステップＳ１１）。
【００９５】
次に、サーバ計算機１は、識別情報取得部１３を用いて、取得規則テーブル１９を参照して、受信した接続要求パケットから、ユーザ識別情報を取得する（ステップＳ１２）。この取得に際しては、クライアント計算機２と共有し取得規則テーブル１９に記述された規則をもとに、受信した接続要求パケットから取得する。ここで、取得規則テーブル１９のユーザ識別情報の格納規則は前述のように共有されている。
【００９６】
なお、例えば、複数の接続要求パケットにユーザ識別情報を格納するという格納規則が利用されている場合には、すべての接続要求パケットを受信するまで待つ。この場合、複数の接続要求パケットが同一の接続要求元からのものであることは、例えば、それらの接続要求パケットの共通のフィールド値（たとえばＩＰアドレスやポート番号など）を用いるなどして判定する。
【００９７】
次に、サーバ計算機１は、ステップＳ１２で取得したユーザ識別情報に対するタスクの有無を、タスク情報取得部１４によりタスク格納テーブル２０を検索して取得した後に、確認する（ステップＳ１３）。このタスク格納テーブル２０には、ユーザ識別情報に対応したアプリケーション処理部１８における現在のタスクの有無が格納されている。ここで、タスク格納テーブル２０の情報は、アプリケーション処理部１８によって不定期に書き換えられる。
【００９８】
さて、ユーザ識別情報で識別される接続要求元に対するタスクの存在の有無を判断して（ステップＳ１４）、タスクが存在しない場合には、接続要求パケットを破棄し（ステップＳ１６）、次の要求を待ち受ける。
【００９９】
タスクが存在する場合には、受信した接続要求パケットに対して接続要求確認パケットを送信する（ステップＳ１５）。
【０１００】
なお、ユーザ識別情報が複数の接続要求パケットに格納されている場合には、そのうちの一つ以上の接続要求パケットに対する応答として接続要求確認パケットを生成して送信する。
【０１０１】
また、タスクが存在しない場合には、接続要求パケットを破棄するとしたが、その代わりに、タスクが無い旨の応答パケットとして、ＦＩＮパケット、ＲＳＴパケットを送信することによってタスクが存在しなかったことをクライアント計算機２に明示的に伝えてもよい。こうすることで、クライアント計算機２がサーバ計算機１におけるタスクの有無をより確実に知ることができるようになる。
【０１０２】
また、ユーザ識別情報に対するタスクの存在が確認できなかった場合でも、一定時間の間、ステップＳ１４の判断を保留し、その間のタスク格納テーブルの変化を監視し変化があった（タスクが登録された）場合には、タスク有りとして返答するようにしてもよい。こうすることで、クライアント計算機２からの問い合わせ頻度を減らすことができる。
【０１０３】
以上のように、本構成例によればタスク格納テーブル２０におけるタスクの有無に応じてコネクション確立を行うことができ、不必要なＴＣＰコネクションの確立を防ぐことができる。これによって、サーバ計算機１のセキュリティーを向上させることができる。
【０１０４】
（第２のシステム構成例）
次に、接続要求パケットに対する応答方法を決定する際に、サーバ計算機１に格納されたサーバ計算機１のコネクション確立ポリシーも併せて参照する構成例について説明する。
【０１０５】
本構成例では、図６の構成に、結果判定部１５により参照される、サーバポリシー格納テーブル（図示せず）が追加されるものとする。
【０１０６】
図１０に、このサーバポリシー格納テーブルの構成例を示す。
【０１０７】
サーバポリシー格納テーブルは、ユーザ識別情報と、サーバ計算機１のそのユーザに対する接続許可判断にかかわるポリシー（以下、サーバポリシー）とが記載されている。サーバポリシーは、サーバ側で例えば管理者等が適宜設定するものとする。
【０１０８】
図１０の例では、サーバポリシー格納テーブルには、サーバポリシーとして、各ユーザ識別情報による最終アクセス時刻（前回接続時刻情報）と、そのユーザ識別情報を含む接続要求パケットによって再コネクションを確立することができるようになるまでに必要とされる最低時間（最低接続間隔情報）が保持されている。
【０１０９】
他の接続許可ポリシーの例としては、そのユーザ識別情報の接続要求元からの最高コネクション本数、接続要求を行う時間帯、サーバ計算機１の負荷状況等に応じたコネクション確立の可否の決定などがある。
【０１１０】
なお、ユーザ識別情報ごとに、全く異なるサーバポリシーをとり得るようにしてもよいし、サーバポリシーは特定のもの（例えば、図１０の方法）のみに固定しておいて、ユーザ識別情報ごとに、当該サーバポリシーにおける所定のパラメータ（例えば、図１０の例の場合、最低接続間隔）を設定するようにしてもよい。
【０１１１】
また、サーバポリシーは、各アプリケーションに固有であったり、１又は複数のアプリケーションを含む各アプリケーション・グループに固有であったり、各クライアントに固有であったり、１又は複数のクライアントを含む各クライアント・グループに固有であったり、各ユーザ識別情報に固有であったり、１又は複数のユーザ識別情報を含む各ユーザ識別情報グループに固有であったりしてもよい。
【０１１２】
例えば、複数のユーザ識別情報が一つのグループとしてまとめられており、そのグループに対するポリシーを用いることも可能である。この場合には、サーバ計算機１には、ユーザ識別情報とグループ識別情報との対応が示されたテーブルをも設ければよい。ユーザ識別情報からその所属するグループ識別情報を取得し、それをもとにそのグループに適用されるサーバの接続許可ポリシーを参照すればよい。
【０１１３】
図１１に、本構成例の場合のサーバ計算機１の処理手順の一例を示す。
【０１１４】
サーバ計算機１は、受信部１１でパケットを受け付けると、判定部１２を利用して受信したパケットの判別を行い、受信パケットが接続要求パケットであり、その宛先ポート番号がアプリケーション処理部１８において実行されているサーバアプリケーションのものであることを確認する（ステップＳ２１）。
【０１１５】
次に、サーバ計算機１は、識別情報取得部１３を用いて、取得規則テーブル１９を参照して受信した接続要求パケットから、そのユーザ識別情報を取得する（ステップＳ２２）。この取得は、第１のシステム構成例のようにして行えばよい。
【０１１６】
次に、サーバ計算機１は、ステップＳ２２で取得したユーザ識別情報に対するタスクの有無を、タスク情報取得部１４によりタスク格納テーブル２０を検索して取得した後に、確認する（ステップＳ２３）。このタスク格納テーブル２０には、ユーザ識別情報に対応したアプリケーション処理部１８における現在のタスクの有無が格納されている。
【０１１７】
ユーザ識別情報で識別される接続要求元に対するタスクの存在の有無を判断して（ステップＳ２４）、タスクが存在しない場合には、接続要求パケットを破棄し（ステップＳ２８）、次の要求を待ち受ける。
【０１１８】
ステップＳ２４においてタスクが存在する場合には、結果判定部１５により、接続要求パケットから取得したユーザ識別情報に基づいて、サーバポリシー格納テーブルからサーバポリシーを取得する（ステップＳ２５）。
【０１１９】
そして、結果判定部１５により、サーバポリシーに適合しているか否かの判断を行う（ステップＳ２６）。
【０１２０】
ここでは、一例として、取得したユーザ識別情報に対応するサーバポリシーが「同一の接続要求元がコネクションを確立するためには、前回の接続から一定時間（例えば、３０秒）以上経過していることが必要である。」というポリシーであるものとする。この場合、サーバ計算機１は、ユーザ識別情報が確認できたコネクション確立要求があると、ユーザ識別情報と対応付けて接続要求時刻をサーバポリシー格納テーブルに記録しておく。そして、新たにコネクション要求があった際には、以前に記載した接続時刻と現在時刻とから、一定時間が経過しているかどうかを判断する。
【０１２１】
なお、ここで、ユーザ識別情報と前回接続時刻との対応は、必ずしもサーバポリシー格納テーブルに記載される必要はなく、その他の任意のテーブルに対応が記録されていればよい。
【０１２２】
さて、サーバポリシーに適合していると判断された場合（上記の例では、一定時間が経過している場合）には、受信した接続要求パケットに対して接続要求確認パケットを送信する（ステップＳ２７）。
【０１２３】
他方、タスクが存在しない場合には、接続要求パケットを破棄し（ステップＳ２８）、次の要求を待ち受ける。
【０１２４】
なお、上記の手順例では、まず、タスクの有無で接続可否を判断し、次に、ポリシーに基づいて接続可否を判断したが、先に、ポリシーに基づいて接続可否を判断し、次いで、タスクの有無で接続可否を判断するようにしてもよいし、両方の判断を並列的に行うようにしてもよい。
【０１２５】
また、接続要求パケットを破棄した場合には、タスクが無い旨の応答パケットとして、ＦＩＮパケット、ＲＳＴパケットを送信することによってタスクが存在しなかったことをクライアント計算機２に明示的に伝えてもよい。また、接続要求パケットを破棄した理由（例えば、タスク無し、ポリシー不適合）をそれらパケットに記述するようにしてもよい。
【０１２６】
また、上記の例では、サーバ計算機１のポリシーとして、前回接続時刻からの経過時間を利用したが、単位時間当たりの可能接続本数、同時に確立可能なコネクションの最大数、あるいはコネクション確立時のサーバ計算機１の処理負荷（例えばＣＰＵ利用率、メモリ使用率等）による制限などのポリシーであってもよい。ようするに、アプリケーション処理部１８におけるタスクの有無だけではなく、そのコネクション接続要求がアプリケーション処理部１８におけるユーザ識別情報に応じて規定されたサーバ計算機１自体の接続許可ポリシーと適合するかどうかに応じたコネクション確立制御を行えばよい。
【０１２７】
本構成例により、タスクが存在する正規ユーザに対してもサーバ計算機１自体のポリシーに応じてコネクション確立の制御を行うことができ、一部の正規ユーザによるサーバ計算機１のリソース乱用といった問題を防止することができる。このことにより、サーバ計算機１の安全性をよりいっそう向上させることができる。
【０１２８】
（第３のシステム構成例）
次に、接続要求パケットに対する応答方法を決定する際に、クライアント計算機２の接続要求元がサーバ計算機１へ予め登録したコネクション確立ポリシーも併せて参照する構成例について説明する。
【０１２９】
本構成例では、結果判定部１５により参照される、クライアントポリシー格納テーブル（図示せず）が追加されるものとする。
【０１３０】
このクライアントポリシー格納テーブルの構成例は、図１０のサーバポリシー格納テーブルと同様であるものとする。
【０１３１】
クライアントポリシー格納テーブルは、ユーザ識別情報に対応して、各ユーザ識別情報で識別される接続要求元のコネクション確立ポリシー（以下、クライアントポリシー）が記載されている。
【０１３２】
クライアントポリシーの内容は、サーバ計算機１に事前に通知されており、クライアントポリシー格納テーブルは、サーバ計算機１は保持しているものとする。例えば、各ユーザ識別情報に係るクライアント計算機２からネットワーク３を介してサーバ計算機１へ通知されて自動的に設定されるようにしてもよいし、あるいは、各ユーザからサーバ計算機１への管理者へ通知し、これを管理者が設定するようにしてもよい。
【０１３３】
図１０の例では、クライアントポリシー格納テーブルには、クライアントポリシーとして、各ユーザ識別情報による最終アクセス時刻（前回接続時刻情報）と、そのユーザ識別情報を含む接続要求パケットによって再コネクションを確立することができるようになるまでに必要とされる最低時間（最低接続間隔情報）が保持されている。
【０１３４】
他のクライアントポリシーの例としては、同時に行うコネクション要求の最大数や、接続要求を行う時間帯などの情報等に応じた、コネクション確立の可否の決定などがある。これらの情報により、かりに攻撃者が接続要求元のユーザ識別情報を偽造したり、盗聴して大量に送りつけてくるなどしてサーバ計算機１を攻撃してきた場合にも、その攻撃の影響を軽減したり、防御したりすることができる。
【０１３５】
なお、ユーザ識別情報ごとに、全く異なるクライアントポリシーをとり得るようにしてもよいし、クライアントポリシーは特定のもの（例えば、図１０の方法）のみに固定しておいて、ユーザ識別情報ごとに、当該クライアントポリシーにおける所定のパラメータ（例えば、図１０の例の場合、最低接続間隔）を設定するようにしてもよい。
【０１３６】
また、クライアントポリシーは、各アプリケーションに固有であったり、１又は複数のアプリケーションを含む各アプリケーション・グループに固有であったり、各クライアントに固有であったり、１又は複数のクライアントを含む各クライアント・グループに固有であったり、各ユーザ識別情報に固有であったり、１又は複数のユーザ識別情報を含む各ユーザ識別情報グループに固有であったりしてもよい。
【０１３７】
例えば、前述と同様に、複数のユーザ識別情報が一つのグループとしてまとめられており、そのグループに対するポリシーを用いることも可能である。
【０１３８】
図１２に、本構成例の場合のサーバ計算機１の処理手順の一例を示す。
【０１３９】
サーバ計算機１は、受信部１１でパケットを受け付けると、判定部１２を利用して受信したパケットの判別を行い、受信パケットが接続要求パケットであり、その宛先ポート番号がアプリケーション処理部１８において実行されているサーバアプリケーションのものであることを確認する（ステップＳ３１）。
【０１４０】
次に、サーバ計算機１は、識別情報取得部１３を用いて、取得規則テーブル１９を参照して受信した接続要求パケットから、そのユーザ識別情報を取得する（ステップＳ３２）。この取得は、第１のシステム構成例のようにして行えばよい。
【０１４１】
次に、サーバ計算機１は、ステップＳ３２で取得したユーザ識別情報に対するタスクの有無を、タスク情報取得部１４によりタスク格納テーブル２０を検索して取得した後に、確認する（ステップＳ３３）。このタスク格納テーブル２０には、ユーザ識別情報に対応したアプリケーション処理部１８における現在のタスクの有無が格納されている。
【０１４２】
ユーザ識別情報で識別される接続要求元に対するタスクの存在の有無を判断して（ステップＳ３４）、タスクが存在しない場合には、接続要求パケットを破棄し（ステップＳ３８）、次の要求を待ち受ける。
【０１４３】
ステップＳ３４においてタスクが存在する場合には、結果判定部１５により、接続要求パケットに含まれたユーザ識別情報に基づいて、クライアントポリシー格納テーブルからクライアントポリシーを取得する（ステップＳ３５）。
【０１４４】
そして、結果判定部１５により、結果判定部１５により、サーバポリシーに適合しているか否かの判断を行う（ステップＳ３６）。
【０１４５】
ここでは、一例として、取得したユーザ識別情報に対応するクライアントポリシーが「当該ユーザ識別情報を含む接続要求元がコネクションを確立するためには、前回の接続から一定時間（例えば、３０秒）以上経過していることが必要である。」というポリシーとする。
【０１４６】
この場合、サーバ計算機１は、ユーザ識別情報が確認できたコネクション確立要求があると、ユーザ識別情報と対応付けて接続要求時刻をクライアントポリシー格納テーブルに記録しておく。そして、新たにコネクション要求があった際には、以前に記載した接続時刻と現在時刻とから、一定時間が経過しているかどうかを判断する。
【０１４７】
なお、ここで、ユーザ識別情報と前回接続時刻の対応は、必ずしもクライアントポリシー格納テーブルに記載される必要はなく、その他の任意のテーブルに対応が記録されていればよい。
【０１４８】
さて、クライアントポリシーに適合していると判断された場合（上記の例では、一定時間が経過している場合）には、受信した接続要求パケットに対して接続要求確認パケットを送信する（ステップＳ３７）。
【０１４９】
他方、タスクが存在しない場合には、接続要求パケットを破棄し（ステップＳ３８）、次の要求を待ち受ける。
【０１５０】
なお、上記の手順例では、まず、タスクの有無で接続可否を判断し、次に、ポリシーに基づいて接続可否を判断したが、先に、ポリシーに基づいて接続可否を判断し、次いで、タスクの有無で接続可否を判断するようにしてもよいし、両方の判断を並列的に行うようにしてもよい。
【０１５１】
また、接続要求パケットを破棄した場合には、タスクが無い旨の応答パケットとして、ＦＩＮパケット、ＲＳＴパケットを送信することによってタスクが存在しなかったことをクライアント計算機２に明示的に伝えてもよい。また、接続要求パケットを破棄した理由（例えば、タスク無し、ポリシー不適合）をそれらパケットに記述するようにしてもよい。
【０１５２】
また、上記の例では、サーバ計算機１に保持されたクライアント計算機２の接続にかかわるポリシーとして、前回接続時刻からの経過時間を利用したが、単位時間当たりの可能接続本数、同時確立可能なコネクションの最大数、あるいはコネクション確立時のサーバ計算機１の処理負荷（例えばＣＰＵ利用率、メモリ使用率等）による制限などのポリシーであってもよい。ようするに、アプリケーション処理部１８におけるタスクの有無だけではなく、そのコネクション接続要求がアプリケーション処理部１８におけるユーザ識別情報に対応する接続要求元が予め定めてサーバ計算機１に通知したクライアントポリシーと適合するかどうかに応じたコネクション確立制御を行えばよい。
【０１５３】
本構成例により、攻撃者がユーザ識別情報を偽造して送信することでコネクションを確立する可能性を低くすることができ、サーバ計算機１のセキュリティーをよりいっそう向上させることができる。
【０１５４】
また、本システム構成例と、第２の実施形態を組み合わせることにより、サーバ計算機１のサーバポリシーとクライアント計算機２のクライアントポリシーの両方を満たす場合にのみコネクション確立を可能とすることができる。ここで、サーバポリシーとクライアントポリシーが衝突する場合には、予め定められた方法（例えば、サーバ計算機１のサーバポリシーを優先させる方法、クライアント計算機２のクライアントポリシーを優先させる方法など）でどちらかのポリシーを有効とするなどしてもよいし、サーバポリシーとクライアントポリシーが衝突した場合には、常に接続を不許可とするようにしてもよいし、その他にも種々のバリエーションが可能である。
【０１５５】
（第４のシステム構成例）
次に、接続要求パケットに対する応答方法を決定する際に、クライアント計算機２の接続要求元が「ユーザ識別情報」と「ユーザ動作モード情報」とを接続要求パケットに格納して送信し、ユーザ動作モード情報に応じたコネクション確立ポリシーを併せて参照する構成例について説明する。
【０１５６】
本構成例では、結果判定部１５により参照される、ユーザ動作モードポリシー格納テーブル（図示せず）が追加されるものとする。
【０１５７】
図１３の（ａ）に、ユーザ動作モードポリシー格納テーブルの構成例を示し、図１３の（ｂ）に、本システム構成例におけるタスク格納テーブル２０の構成の一例を示す。
【０１５８】
ユーザ動作モードポリシー格納テーブルは、ユーザ動作モード情報と、それに対する接続要求元の現在の動作状況に関する情報（以下、タスク確認動作情報）が記載されている。ユーザ動作モード情報とは、接続要求元に係るクライアント計算機２又はクライアント計算機２上で動作するクライアントアプリケーションの実行状態を示す情報であり、例えば、「通常モード」、「録画優先モード」、「省電力動作モード」、「休止状態」といった情報である。これらのユーザ動作モードは、接続要求元のコネクション確立要求における振る舞いを変化させる。
【０１５９】
ユーザ動作モードによる振る舞いの変化としては、例えば、コネクション要求の時間間隔を変化させる構成が可能である。例えば、省電力状態で動作している接続要求元からのコネクション要求の時間間隔は広くなりコネクション要求の頻度は下がるといった具合である。図１３の（ａ）では、「通常モード」と「録画再生モード」と「省電力動作モード」でタスク確認動作情報（最低接続間隔）を異ならせた例を示している。なお、その他にも、同時コネクション要求の最大数、接続要求を行う時間帯など、種々のバリエーションが可能である。
【０１６０】
これらの情報により、サーバ計算機１は、接続要求元の状態に応じたリソースの配分やスケジュールが可能となる。
【０１６１】
なお、ユーザ動作モード情報とそのタスク確認動作情報は、サーバ計算機１に事前に通知されて、サーバ計算機１に保持されているものとする。例えば、ユーザ動作モード情報とそのタスク確認動作情報は、各ユーザ識別情報に係るクライアント計算機２からネットワーク３を介してサーバ計算機１へ通知されて自動的に設定されるようにしてもよいし、あるいは、各ユーザからサーバ計算機１への管理者へ通知し、これを管理者が設定するようにしてもよい。
【０１６２】
なお、ユーザ識別情報ごとに、全く異なるユーザ動作モードポリシーをとり得るようにしてもよいし、ユーザ動作モードポリシーは特定のもの（例えば、図１３の方法）のみに固定しておいて、ユーザ識別情報ごとに、当該ユーザ動作モードポリシーにおける所定のパラメータ（例えば、図１３の例の場合、最低接続間隔）を設定するようにしてもよい。
【０１６３】
また、前述と同様に、ユーザ動作モード情報とそのタスク確認動作情報は、クライアントポリシーは、各アプリケーションに固有であったり、１又は複数のアプリケーションを含む各アプリケーション・グループに固有であったり、各クライアントに固有であったり、１又は複数のクライアントを含む各クライアント・グループに固有であったり、各ユーザ識別情報に固有であったり、１又は複数のユーザ識別情報を含む各ユーザ識別情報グループに固有であったりしてもよい。
【０１６４】
タスク格納テーブル２０には、ユーザ識別情報と、タスクの有無と、最終接続時刻が記載されている。なお、図１３の（ｂ）では、タスクの有無の図示を省略している。
【０１６５】
図１４に、本構成例の場合のクライアント計算機２の処理手順の一例を示し、図１５に、本構成例の場合のサーバ計算機１の処理手順の一例を示す。
【０１６６】
まず、図１４を参照しながら、本構成例のクライアント計算機２の処理手順例について説明する。
【０１６７】
クライアント計算機２は、サーバ計算機１のあるサーバアプリケーションに接続する場合、まず、クライアントアプリケーション処理部２５により接続要求元のユーザ識別情報を取得する（ステップＳ４１）。
【０１６８】
次に、クライアント計算機２は、クライアントアプリケーション処理部２５から、そのアプリケーションの動作モードを示すユーザ動作モード情報を入手する（ステップＳ４２）。
【０１６９】
次に、クライアント計算機２は、接続要求パケット生成部２１により格納規則テーブル２６を参照して入手したユーザ識別情報とユーザ動作モード情報を格納した接続要求パケットを生成する（ステップＳ４３）。
【０１７０】
ここで、格納規則テーブル２６には、ユーザ識別情報だけではなく、ユーザ動作モード情報の格納規則も記されている。ユーザ動作モード情報の格納規則は、基本的には、前述したユーザ識別情報の格納規則と同等である。
【０１７１】
次に、クライアント計算機２は、作成したユーザ識別情報とユーザ動作モード情報を格納した接続要求パケットを、送信部２２によりサーバ計算機１に送信する（ステップＳ４４）。ここで、接続要求パケットへのユーザ識別情報の格納方法によっては、複数の接続要求パケットが送信される場合もある。
【０１７２】
クライアント計算機２は、全ての接続要求パケットを送信したことを確認すると、サーバ計算機１からの接続要求確認パケットを待ち受ける（ステップＳ４５）。
【０１７３】
クライアント計算機２は、サーバ計算機１からの応答があったかを判断し（ステップＳ４６）、応答がない場合には、タスクが存在せずコネクション確立の必要がないものと判断して処理を終了する。
【０１７４】
他方、クライアント計算機２は、サーバ計算機１から送信した接続要求パケットに対する接続要求確認パケットを受信した場合には、それに対して応答確認パケットを送信する（ステップＳ４７）。
【０１７５】
なお、ステップＳ４４において複数の接続要求パケットが送信されている場合には、複数の接続要求パケットのいずれかに対する接続要求確認パケットが送信されたかどうかを確認して、その確認後、コネクションを確立すればよい。
【０１７６】
また、上記においては、クライアント計算機２は、接続要求パケットに対する返答を待ち受けて、それがない場合にはコネクション確立をあきらめるとしたが、タスクが無い旨の応答パケットとして、例えば、ＲＳＴパケット、ＦＩＮパケットの受信などによってタスクが存在しないと判断してもよい。
【０１７７】
次に、図１５を参照しながら、本構成例のサーバ計算機１の処理手順例について説明する。
【０１７８】
サーバ計算機１は、受信部１１でパケットを受け付けると、判定部１２を利用して受信したパケットの判別を行い、受信パケットが接続要求パケットであり、その宛先ポート番号がアプリケーション処理部２５において実行されているサーバアプリケーションのものであることを確認する（ステップＳ５１）。
【０１７９】
次に、サーバ計算機１は、識別情報取得部１３を用いて、取得規則テーブル１９を参照して、受信した接続要求パケットから、そのユーザ識別情報とユーザ動作モード情報を取得する（ステップＳ５２）。
【０１８０】
ここで、取得規則テーブル１９には、ユーザ識別情報の格納規則だけでなく、ユーザ動作モード情報の格納規則も記述されている。ユーザ動作モード情報の格納規則は、基本的には、前述したユーザ識別情報の格納規則と同等である。
【０１８１】
この取得に際しては、クライアント計算機２と共有した規則をもとに、受信したパケットから復元を行う。ここで、複数の接続要求パケットにユーザ識別情報とユーザ動作モード情報を格納するという設定になっている場合には、前述と同様に、全てのパケットが受信できるのを待ち受ける。
【０１８２】
次に、サーバ計算機１は、ステップＳ５２で取得したユーザ識別情報に対するタスクの有無を、タスク情報取得部１４によりタスク格納テーブル２０を検索して取得した後に、確認する（ステップＳ５３）。このタスク格納テーブル２０には、ユーザ識別情報に対する現在のタスクの有無が格納されている。
【０１８３】
さて、ユーザ識別情報で識別される接続要求元に対するタスクの存在の有無を判断して（ステップＳ５４）、タスクが存在しない場合には、接続要求パケットを破棄し（ステップＳ５８）、次の要求を待ち受ける。
【０１８４】
タスクが存在する場合には、受信した接続要求パケットに含まれているユーザ動作モード情報に基づいて、ユーザ動作モードポリシー格納テーブルからユーザ動作モードポリシーを取得する（ステップＳ５５）。
【０１８５】
そして、結果判定部１５により、結果判定部１５により、サーバポリシーに適合しているか否かの判断を行う（ステップＳ５６）。
【０１８６】
ここで、一例として、クライアント計算機２の動作モード情報から、接続要求元が省電力状態（動作モード情報：３）であり、コネクション確立要求を送信するのは通常モード（動作モード情報：１）の２倍の６０秒間隔であるというタスク確認動作情報を得たとする（図１３（ａ）参照）。
【０１８７】
この場合、サーバ計算機１は、ユーザ識別情報が確認できたコネクション確立要求があると、ユーザ識別情報と対応付けて最終接続要求時刻をタスク格納テーブル２０に記録しておく。そして、新たにコネクション要求があった際には、以前に記載した接続時刻と現在時刻とから、６０秒が経過しているかどうかを判断する。
【０１８８】
なお、ここで、ユーザ識別情報と前回接続時刻の対応は、必ずしもタスク格納テーブルに記載される必要はなく、その他の任意のテーブルに対応が記録されていればよい。
【０１８９】
また、ここでは、省電力モードを例としたため、コネクション確立の要求間隔を増加させたが、逆にエンハンストなモードのような処理速度優先の動作モードとすることで、コネクション確立の要求間隔を短くするような場合もあり得る。
【０１９０】
さて、タスク確認動作情報を満たすアクセスであると判断された場合（上記の例では、一定時間が経過している場合）には、受信した接続要求パケットに対して接続要求確認パケットを送信する（ステップＳ５７）。
【０１９１】
他方、タスクが存在しない場合には、接続要求パケットを破棄し（ステップＳ５８）、次の要求を待ち受ける。
【０１９２】
なお、上記の手順例では、まず、タスクの有無で接続可否を判断し、次に、ポリシーに基づいて接続可否を判断したが、先に、ポリシーに基づいて接続可否を判断し、次いで、タスクの有無で接続可否を判断するようにしてもよいし、両方の判断を並列的に行うようにしてもよい。
【０１９３】
また、接続要求パケットを破棄した場合には、タスクが無い旨の応答パケットとして、ＦＩＮパケット、ＲＳＴパケットを送信することによってタスクが存在しなかったことをクライアント計算機２に明示的に伝えてもよい。また、接続要求パケットを破棄した理由（例えば、タスク無し、ポリシー不適合）をそれらパケットに記述するようにしてもよい。
【０１９４】
また、上記ン例では、サーバ計算機１に保持されたクライアント計算機２のタスク確認動作情報として、前回接続時刻からのある間隔での接続としたが、単位時間当たりの可能接続本数、同時確立可能なコネクションの最大数、あるいはコネクション確立時のサーバ計算機１の処理負荷（例えばＣＰＵ利用率、メモリ使用率等）による制限などであってもよい。ようするに、アプリケーション処理部１８におけるタスクの有無だけではなく、そのコネクション接続要求がクライアント計算機２から通知されたそのときのクライアント計算機２のユーザ動作モード情報と対応づけられたタスク確認動作情報に適合するかどうかに応じたコネクション確立制御を行えばよい。
【０１９５】
また、予め接続要求パケットへのユーザ識別情報の格納方法を唯一のものに固定する場合には、ユーザ識別情報に対応する格納規則テーブルを省略することができるのと同様に、接続要求パケットへのタスク確認動作情報の格納方法を唯一のものに固定する場合には、タスク確認動作情報に対応する格納規則テーブルを省略することができる。
【０１９６】
本構成例により、タスクの有無だけではなくクライアント計算機２の動作状態に応じてコネクション確立の判断ができるようになり、クライアント計算機２とサーバ計算機１との間で効率的なタスクの有無の確認作業を実行することが可能となる。このことにより、不必要なコネクション確立がよりいっそう減少させることができ、サーバ計算機１のセキュリティーをより向上させることが可能となる。
【０１９７】
なお、本システム構成例と、第２の実施形態、第３の実施形態、又は第２の実施形態と第３の実施形態の両方を組み合わせることも可能である。
【０１９８】
なお、以上の各機能は、ソフトウェアとして記述し適当な機構をもったコンピュータに処理させても実現可能である。  
また、本実施形態は、コンピュータに所定の手順を実行させるための、あるいはコンピュータを所定の手段として機能させるための、あるいはコンピュータに所定の機能を実現させるためのプログラムとして実施することもできる。加えて該プログラムを記録したコンピュータ読取り可能な記録媒体として実施することもできる。
【０１９９】
なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。
【図面の簡単な説明】
【０２００】
【図１】本発明の一実施形態に係る通信システムの一例を示す図
【図２】ＩＰパケットについて説明するための図
【図３】ＴＣＰセグメントについて説明するための図
【図４】ＵＤＰセグメントについて説明するための図
【図５】同実施形態に係るクライアント計算機の構成例を示す図
【図６】同実施形態に係るサーバ計算機の構成例を示す図
【図７】同実施形態に係るタスク格納テーブルの一例を示す図
【図８】第１のシステム構成例に係るクライアント計算機の処理手順の一例を示すフローチャート
【図９】第１のシステム構成例に係るサーバ計算機の処理手順の一例を示すフローチャート
【図１０】第２のシステム構成例（及び第３のシステム構成例）のサーバポリシー格納テーブルの一例を示す図
【図１１】第２のシステム構成例のサーバ計算機の処理手順の一例を示すフローチャート
【図１２】第３のシステム構成例のサーバ計算機の処理手順の一例を示すフローチャート
【図１３】第４のシステム構成例のユーザ動作モードポリシー格納テーブルの一例を示す図
【図１４】第４のシステム構成例のクライアント計算機の処理手順の一例を示すフローチャート
【図１５】第４のシステム構成例のサーバ計算機の処理手順の一例を示すフローチャート
【符号の説明】
【０２０１】
１…サーバ計算機、２…クライアント計算機、３…ネットワーク、１１，２３…受信部、１２…判断部、１３…識別情報取得部、１４…タスク情報取得部、１５…結果判定部、１６…接続要求確認パケット生成部、１７，２２…送信部、１８…サーバアプリケーション処理部、１９…取得規則テーブル、２０…タスク格納テーブル、２１…接続要求パケット生成部、２４…接続要求確認パケット判定部、２５…クライアントアプリケーション処理部、２６…格納規則テーブル、２７…確認応答パケット生成部
【図１】
2006185194.tif 000003
【図２】
2006185194.tif 000004
【図３】
2006185194.tif 000005
【図４】
2006185194.tif 000006
【図５】
2006185194.tif 000007
【図６】
2006185194.tif 000008
【図７】
2006185194.tif 000009
【図８】
2006185194.tif 000010
【図９】
2006185194.tif 000011
【図１０】
2006185194.tif 000012
【図１１】
2006185194.tif 000013
【図１２】
2006185194.tif 000014
【図１３】
2006185194.tif 000015
【図１４】
2006185194.tif 000016
【図１５】
2006185194.tif 000017