(57)【要約】【課題】  ＴＣＰ／ＩＰプロトコルによるサーバ・クライアント間の通信におけるセキュリティを向上させる。【解決手段】  サーバと，サーバのアプリケーションとの間でＴＣＰ／ＩＰプロトコルにより通信を行うクライアントと，を備える通信システムにおいて，アプリケーションのいずれかを一意に特定するプログラム識別子をクライアントから受信するサーバ受信部１２０と，サーバ受信部により受信されたプログラム識別子により特定されるアプリケーションに，ポート番号を動的に付与するサーバ側ポート番号付与部１２４と，サーバ側ポート番号付与部により付与されたポート番号をクライアントに送信するサーバ送信部１２２とをサーバ１０４に設け，クライアント１０２とサーバ１０４内のアプリケーションとの間での通信を，動的に付与されたポート番号を用いて行うようにした。【選択図】    図１
2007200209.tif 000002
【特許請求の範囲】
【請求項１】
１以上のアプリケーションプログラムを備えるサーバと，前記アプリケーションプログラムとの間でＴＣＰ／ＩＰプロトコルにより通信を行うクライアントと，を備える通信システムにおいて：
前記サーバは，
前記クライアントから，前記１以上のアプリケーションプログラムのいずれかを一意に特定するプログラム識別子を受信するサーバ受信部と；
前記サーバ受信部により受信された前記プログラム識別子により特定されるアプリケーションプログラムに，ポート番号を動的に付与するサーバ側ポート番号付与部と；
前記サーバ側ポート番号付与部により付与された前記ポート番号を，サーバ側ポート番号として，前記クライアントに送信するサーバ送信部と；
を備え，
前記クライアントは，
通信を行いたい前記アプリケーションプログラムの前記プログラム識別子を前記サーバに送信するクライアント送信部と；
前記サーバから前記サーバ側ポート番号を受信するクライアント受信部と；
を備え，
前記クライアントは，前記クライアント受信部により受信された前記サーバ側ポート番号を用いて前記サーバの前記アプリケーションプログラムと通信を行うことを特徴とする，通信システム。
【請求項２】
前記サーバは，
前記ポート番号を付与したアプリケーションプログラムが前記クライアントと通信を行う際の前記クライアント側のポート番号を指定するクライアント側ポート番号指定部をさらに備え，
前記サーバ送信部は，前記クライアント側ポート番号指定部により指定された前記ポート番号を，クライアント側ポート番号として，前記クライアントに送信することを特徴とする，請求項１に記載の通信システム。
【請求項３】
１以上のアプリケーションプログラムを備えるサーバと，前記アプリケーションプログラムとの間でＴＣＰ／ＩＰプロトコルにより通信を行うクライアントと，を備える通信システムにおいて：
前記サーバは，
前記アプリケーションプログラムへのアクセスの手順を定めている手順定義テーブルと；
前記手順定義テーブルに定められている前記アクセスの手順に基づいて，前記アプリケーションプログラムと前記クライアントとの通信を許可するか否かを判断する通信可否判断部と；
前記通信可否判断部により通信を許可された場合に，前記クライアントに指定されたアプリケーションプログラムに前記クライアントとの通信を開始させる通信開始部と；
を備えることを特徴とする，通信システム。
【請求項４】
前記サーバは，
前記アプリケーションプログラムに動的にポート番号を付与するサーバ側ポート番号付与部と；
前記サーバ側ポート番号付与部により付与された前記ポート番号を，サーバ側ポート番号として，前記クライアントに送信するサーバ送信部と；
をさらに備え，
前記通信開始部は，前記通信可否判断部により通信を許可された場合に，前記サーバ側ポート番号付与部をして前記クライアントに指定されたアプリケーションプログラムにポート番号を付与せしめ，前記サーバ送信部をして該ポート番号を前記クライアントに送信せしめること
を特徴とする，請求項３に記載の通信システム。
【請求項５】
前記サーバは，前記クライアントから，前記１以上のアプリケーションプログラムのいずれかを一意に特定するプログラム識別子を受信するサーバ受信部をさらに備え，
前記通信開始部は，前記通信可否判断部により通信を許可された場合に，前記サーバ受信部をして前記クライアントから前記プログラム識別子を受信せしめ，受信した前記プログラム識別子により特定される前記アプリケーションプログラムを前記クライアントに指定されたアプリケーションプログラムとすること
を特徴とする，請求項３または４に記載の通信システム。
【請求項６】
前記手順定義テーブルには，１以上の前記アプリケーションプログラム毎に，相異なるアクセスの手順が定められており，
前記通信開始部は，前記通信可否判断部により前記アプリケーションとの通信を許可された前記クライアントによって実行された前記アクセスの手順に応じて，前記クライアントに指定された前記アプリケーションを特定することを特徴とする，請求項３または４に記載の通信システム。
【請求項７】
前記手順定義テーブルには，１以上の前記アプリケーションプログラム毎に相異なり，かつ，前記アプリケーションの利用態様毎に相異なるアクセスの手順が定められており，
前記通信開始部は，前記通信可否判断部により前記アプリケーションとの通信を許可された前記クライアントによって実行された前記アクセスの手順に応じて，前記クライアントに指定された前記アプリケーションおよび前記利用態様を特定することを特徴とする，請求項３または４に記載の通信システム。
【請求項８】
前記利用態様には，前記アプリケーションプログラムにより実行される前記クライアントの認証方式，および，前記クライアントが前記アプリケーションプログラムを介して接続できるネットワークの種類のいずれかまたは双方を含むことを特徴とする，請求項７に記載の通信システム。
【請求項９】
前記アクセスの手順は，前記サーバが前記クライアントから受信するポート番号と，前記ポート番号の受信の順序との組み合わせであることを特徴とする，請求項３〜８のいずれか１項に記載の通信システム。
【請求項１０】
前記サーバが，
前記手順定義テーブルに定められている前記アクセスの手順を，所定のタイミングで更新するアクセス手順更新部をさらに備えることを特徴とする，請求項３〜９のいずれか１項に記載の通信システム。
【請求項１１】
前記アクセスの手順を所定のタイミングで生成し，生成した前記アクセスの手順をアクセス手順記憶部に保存しているアクセス手順生成サーバを備え，
前記サーバの前記アクセス手順更新部は，前記所定のタイミングで前記アクセス手順生成サーバから前記アクセスの手順を取得し，取得した前記アクセスの手順により前記手順定義テーブルを更新すること
を特徴とする，請求項１０に記載の通信システム。
【請求項１２】
１以上のアプリケーションプログラムを備え，前記アプリケーションプログラムとクライアントとのＴＣＰ／ＩＰプロトコルによる通信を制御するサーバにおいて：
前記アプリケーションプログラムへのアクセスの手順を定めている手順定義テーブルと；
前記手順定義テーブルに定められている前記アクセスの手順に基づいて，前記アプリケーションプログラムと前記クライアントとの通信を許可するか否かを判断する通信可否判断部と；
前記通信可否判断部により通信を許可された場合に，前記クライアントに指定されたアプリケーションプログラムに前記クライアントとの通信を開始させる通信開始部と；
を備えることを特徴とするサーバ。
【請求項１３】
コンピュータをして，
１以上のアプリケーションプログラムを備え，前記アプリケーションプログラムとクライアントとのＴＣＰ／ＩＰプロトコルによる通信を制御し，
手順定義テーブルに定められている，前記アプリケーションプログラムへのアクセスの手順に基づいて，前記アプリケーションプログラムと前記クライアントとの通信を許可するか否かを判断する通信可否判断部と；
前記通信可否判断部により通信を許可された場合に，前記クライアントに指定されたアプリケーションプログラムに前記クライアントとの通信を開始させる通信開始部と；
を備えるサーバとして機能せしめることを特徴とするコンピュータプログラム。
【請求項１４】
１以上のアプリケーションプログラムを備えるサーバと，前記アプリケーションプログラムとの間でＴＣＰ／ＩＰプロトコルにより通信を行うクライアントとにより実行される通信方法において：
前記クライアントが，通信を行いたい前記アプリケーションプログラムを一意に識別するプログラム識別子を前記サーバに送信するステップと；
前記サーバが，前記クライアントから，前記プログラム識別子を受信するステップと；
前記サーバが，受信した前記プログラム識別子により特定されるアプリケーションプログラムに，ポート番号を動的に付与するステップと；
前記サーバが，付与した前記ポート番号を，前記クライアントに送信するステップと；
前記クライアントが，前記サーバから前記ポート番号を受信するステップと；
を含み，前記クライアントは，前記サーバから受信した前記ポート番号を用いて前記サーバの前記アプリケーションプログラムと通信を行うことを特徴とする，通信方法。
【請求項１５】
１以上のアプリケーションプログラムを備えるサーバと，前記アプリケーションプログラムとの間でＴＣＰ／ＩＰプロトコルにより通信を行うクライアントとにより実行される通信方法において：
前記サーバが，手順定義テーブルに定められている，前記アプリケーションプログラムへのアクセスの手順に基づいて，前記アプリケーションプログラムと前記クライアントとの通信を許可するか否かを判断するステップと；
前記サーバが，前記アプリケーションプログラムと前記クライアントとの通信を許可した場合に，前記クライアントに指定されたアプリケーションプログラムに前記クライアントとの通信を開始させるステップと；
を含むことを特徴とする，通信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は，通信システム，サーバ，通信方法，およびコンピュータプログラムに関する。詳細には，１以上のアプリケーションプログラムを備えるサーバと，サーバのアプリケーションプログラムとの間でＴＣＰ／ＩＰプロトコルにより通信を行うクライアントとを備える通信システム，その通信システムに用いられるサーバ，通信方法，およびコンピュータプログラムに関する。
【背景技術】
【０００２】
従来，ＴＣＰ／ＩＰプロトコルによるサーバ・クライアント間の通信では，サーバ内で通信を行うアプリケーションプログラム（以後，アプリケーションとも称する。）には各々固定のポート番号が付与されており，クライアントは，既知の固定のポート番号を用いてサーバ内のアプリケーションと通信接続を行っていた。特に，ＨＴＴＰサーバ，ＴＥＬＮＥＴサーバ，ＦＴＰサーバなどの広く使われているアプリケーションに付与される固定のポート番号は，ＲＦＣ（Ｒｅｑｕｅｓｔ  ｆｏｒ  Ｃｏｍｍｅｎｔｓ）１０６０に規定されており，ウェルノウン（ｗｅｌｌ  ｋｎｏｗｎ）ポート番号と呼ばれる。
【０００３】
ウェルノウンポート番号は公にされており，誰でもその情報を入手することができる。そのため，誰でも，コンピュータに対してウェルノウンポート番号を通じてポートスキャンすることにより，コンピュータ上で動作しているアプリケーションの一覧を得ることができる。また，誰でも，ＩＰアドレススイープすることにより，目的のアプリケーションが動作しているコンピュータの一覧を得ることができる。また，これらのアプリケーションは，デフォルトの設定ではバージョン番号も容易に知られてしまう。
【０００４】
従って，例えばあるアプリケーションに脆弱性が発見された場合，ポートスキャンやＩＰアドレススイープにより，そのアプリケーションが動作しているコンピュータが第三者に特定されてしまう。そして，その第三者により該コンピュータに不正にアクセス，侵入されてデータが改ざんされたり，他のコンピュータへの攻撃のための踏み台とされるなどの被害が発生していた。さらに最近では，第三者によるこのような不正行為が自動化されたワーム（Ｗｏｒｍ）と呼ばれるプログラムが大量に作成されており，膨大な数のコンピュータがワームに感染した状態でインターネットに接続されている可能性がある。
【０００５】
そこで，ウェルノウンポート番号を使用しないでサーバ・クライアント間で通信を行う方法が提供されている（例えば，特許文献１参照）。本方法では，サーバとクライアントが，予め定められた共通のポート番号決定方式により各々ポート番号を導出して使用することにより，ウェルノウンポート番号を使用しないでサーバ・クライアント間で通信接続を行うことを可能にしている。
【０００６】
【特許文献１】特開２００４−２６５１２２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
しかし，上記方法は，サーバとクライアントが互いに同じポート番号決定方式を用いて利用する方式であり，ＶＰＮの一方式である。つまり，通信を前提としたサーバとクライアントに独自方式を実装し，同期させることで初めて動作するものであるため，不特定多数のコンピュータへの適用には適さない。上記方法では，サーバ側で使用されるポート番号をクライアント側で導出することができるため，不特定多数のコンピュータに広く上記方法が適用されてしまえば，第三者はそのポート番号を用いてサーバに不正にアクセスすることが可能となり，上記方法によるセキュリティの保護が意味をなさなくなるという問題点があった。
【０００８】
そこで，本発明は，このような問題に鑑みてなされたもので，その目的とするところは，ＴＣＰ／ＩＰプロトコルによるサーバ・クライアント間の通信におけるセキュリティを向上させ，かつ，不特定多数のコンピュータに適用することの可能な，新規かつ改良された通信システム，サーバ，通信方法，およびコンピュータプログラムを提供することにある。
【課題を解決するための手段】
【０００９】
上記課題を解決するために，本発明のある観点によれば，１以上のアプリケーションプログラムを備えるサーバと，アプリケーションプログラムとの間でＴＣＰ／ＩＰプロトコルにより通信を行うクライアントと，を備える通信システムが提供される。本通信システムにおいて，サーバは，クライアントから，１以上のアプリケーションプログラムのいずれかを一意に特定するプログラム識別子を受信するサーバ受信部と；受信部により受信されたプログラム識別子により特定されるアプリケーションプログラムに，ポート番号を動的に付与するサーバ側ポート番号付与部と；サーバ側ポート番号付与部により付与されたポート番号を，サーバ側ポート番号として，クライアントに送信するサーバ送信部と；を備える。
【００１０】
クライアントは，通信を行いたいアプリケーションプログラムのプログラム識別子をサーバに送信するクライアント送信部と；サーバからサーバ側ポート番号を受信するクライアント受信部と；を備え，クライアントは，クライアント受信部により受信されたサーバ側ポート番号を用いてサーバのアプリケーションプログラムと通信を行う。
【００１１】
上記発明によれば，サーバのアプリケーションとクライアントとの間の通信が，サーバにより動的に付与されたポート番号を用いて行われる。従って，ウェルノウンポート番号を用いていないため，ウェルノウンポート番号を通じて不正にアプリケーションにアクセスされることを防止できる。また，ポート番号がサーバにより動的に決定されるため，サーバからの通知を得ない限り，クライアントはポート番号を知り得ない。従って，クライアントが既知のポート番号を通じてサーバのアプリケーションに不正にアクセスすることを防止し，通信のセキュリティを向上させることができる。
【００１２】
上記サーバは，ポート番号を付与したアプリケーションプログラムがクライアントと通信を行う際のクライアント側のポート番号を指定するクライアント側ポート番号指定部をさらに備え，サーバ送信部は，クライアント側ポート番号指定部により指定されたポート番号を，クライアント側ポート番号として，クライアントに送信するようにしてもよい。かかる構成によれば，サーバがクライアント側のポート番号も指定するため，アプリケーションとの通信相手をクライアント側のポート番号単位で制御でき，さらにセキュリティを向上させることができる。
【００１３】
上記課題を解決するために，本発明の別の観点によれば，１以上のアプリケーションプログラムを備えるサーバと，アプリケーションプログラムとの間でＴＣＰ／ＩＰプロトコルにより通信を行うクライアントと，を備える通信システムにおいて，サーバが，アプリケーションプログラムへのアクセスの手順を定めている手順定義テーブルと；手順定義テーブルに定められているアクセスの手順に基づいて，アプリケーションプログラムとクライアントとの通信を許可するか否かを判断する通信可否判断部と；通信可否判断部により通信を許可された場合に，クライアントに指定されたアプリケーションプログラムにクライアントとの通信を開始させる通信開始部と；
を備える通信システムが提供される。
【００１４】
通信可否判断部は，クライアントが，予め定められている手順に従ってサーバにアクセスした場合に，該クライアントとアプリケーションプログラムとの通信を許可するよう，通信の許可／不許可を決定するようにしてもよい。
【００１５】
上記発明によれば，サーバは，クライアントが，予め定められた手順によりサーバにアクセスした場合にのみ，そのクライアントとの通信を許可する。そのため，第三者によるサーバ内のアプリケーションへのアクセスを制限することができ，通信のセキュリティを向上させることができる。
【００１６】
上記通信システムにおいて，サーバは，アプリケーションプログラムに動的にポート番号を付与するサーバ側ポート番号付与部と；サーバ側ポート番号付与部により付与されたポート番号を，サーバ側ポート番号として，クライアントに送信するサーバ送信部と；をさらに備えてもよく，その場合，通信開始部は，通信可否判断部により通信を許可された場合に，サーバ側ポート番号付与部をしてクライアントに指定されたアプリケーションプログラムにポート番号を付与せしめ，サーバ送信部をして該ポート番号をクライアントに送信せしめるようにしてもよい。かかる構成によれば，サーバがアプリケーションのポート番号を動的に決定する。従って，ウェルノウンポート番号を用いていないため，ウェルノウンポート番号を通じて不正にアプリケーションにアクセスされることを防止できる。また，ポート番号がサーバにより動的に決定されるため，サーバからの通知を得ない限り，クライアントはポート番号を知り得ない。従って，クライアントが既知のポート番号を通じてサーバのアプリケーションに不正にアクセスすることを防止し，通信のセキュリティをさらに向上させることができる。
【００１７】
上記通信システムにおいて，サーバは，クライアントから，１以上のアプリケーションプログラムのいずれかを一意に特定するプログラム識別子を受信するサーバ受信部をさらに備えてもよく，その場合，通信開始部は，通信可否判断部により通信を許可された場合に，サーバ受信部をしてクライアントからプログラム識別子を受信せしめ，受信したプログラム識別子により特定されるアプリケーションプログラムをクライアントに指定されたアプリケーションプログラムとするようにしてもよい。かかる構成によれば，アクセス手順を，サーバの各アプリケーションプログラムに共通に定めることができる。
【００１８】
上記手順定義テーブルには，１以上のアプリケーションプログラム毎に，相異なるアクセスの手順が定められていてもよく，その場合，通信開始部は，通信可否判断部によりアプリケーションとの通信を許可されたクライアントによって実行されたアクセスの手順に応じて，クライアントに指定されたアプリケーションを特定するようにしてもよい。かかる構成によれば，アプリケーションプログラムごとに相異なる手順が定められるので，１つのアクセス手順が漏洩した場合であっても，他のアプリケーションプログラムに対する不正なアクセスを防止することができる。
【００１９】
上記手順定義テーブルには，１以上のアプリケーションプログラム毎に相異なり，かつ，アプリケーションの利用態様毎に相異なるアクセスの手順が定められていてもよく，その場合，通信開始部は，通信可否判断部によりアプリケーションとの通信を許可されたクライアントによって実行されたアクセスの手順に応じて，クライアントに指定されたアプリケーションおよび利用態様を特定するようにしてもよい。かかる構成によれば，アプリケーションごと，かつその利用態様ごとに異なる手順が定められるので，１つのアクセス手順が漏洩した場合であっても，他の利用態様によるアプリケーションプログラムや，他のアプリケーションプログラムに対する不正なアクセスを防止することができる。
【００２０】
上記利用態様には，アプリケーションプログラムにより実行されるクライアントの認証方式，および，クライアントがアプリケーションプログラムを介して接続できるネットワークの種類のいずれかまたは双方を含むようにしてもよい。
【００２１】
上記アクセスの手順は，サーバがクライアントから受信するポート番号と，ポート番号の受信の順序との組み合わせであってもよい。
【００２２】
また，上記通信システムにおいて，サーバが，手順定義テーブルに定められているアクセスの手順を，所定のタイミングで更新するアクセス手順更新部をさらに備えていてもよい。かかる構成によれば，アクセス手順が更新されるため，一度アクセス手順が漏洩した場合であっても，更新後においては，漏洩したアクセス手順でのアクセスは無効となる。
【００２３】
上記通信システムは，アクセスの手順を所定のタイミングで生成し，生成したアクセスの手順をアクセス手順記憶部に保存しているアクセス手順生成サーバを備えてもよく，その場合，サーバのアクセス手順更新部は，所定のタイミングでアクセス手順生成サーバからアクセスの手順を取得し，取得したアクセスの手順により手順定義テーブルを更新するようにしてもよい。
【００２４】
上記課題を解決するために，本発明の別の観点によれば，１以上のアプリケーションプログラムを備え，アプリケーションプログラムとクライアントとのＴＣＰ／ＩＰプロトコルによる通信を制御するサーバが提供される。本サーバは，アプリケーションプログラムへのアクセスの手順を定めている手順定義テーブルと；手順定義テーブルに定められているアクセスの手順に基づいて，アプリケーションプログラムとクライアントとの通信を許可するか否かを判断する通信可否判断部と；通信可否判断部により通信を許可された場合に，クライアントに指定されたアプリケーションプログラムにクライアントとの通信を開始させる通信開始部と；を備える。
【００２５】
上記課題を解決するために，本発明の別の観点によれば，コンピュータに上記のサーバとして機能させるコンピュータプログラムが提供される。コンピュータプログラムは，コンピュータが備える記憶装置に格納され，コンピュータが備えるＣＰＵに読み込まれて実行されることにより，そのコンピュータを上記のサーバとして機能させる。また，コンピュータプログラムが記録された，コンピュータで読み取り可能な記録媒体も提供される。記録媒体は，例えば，磁気ディスク，光ディスクなどである。
【００２６】
上記課題を解決するために，本発明の別の観点によれば，上記いずれかの通信システムにより実行される通信方法が提供される。
【発明の効果】
【００２７】
以上説明したように本発明によれば，ＴＣＰ／ＩＰプロトコルによるサーバ・クライアント間の通信におけるセキュリティを向上させ，かつ，不特定多数のコンピュータに適用することの可能な，新規かつ改良された通信システム，サーバ，通信方法，およびコンピュータプログラムを提供することができる。
【発明を実施するための最良の形態】
【００２８】
以下に添付図面を参照しながら，本発明の好適な実施の形態について詳細に説明する。なお，本明細書及び図面において，実質的に同一の機能構成を有する構成要素については，同一の符号を付することにより重複説明を省略する。
【００２９】
（第１実施形態）
まず，図１に基づいて，第１実施形態にかかる通信システムの概要について説明する。本実施形態にかかる通信システム１００は，１以上のアプリケーションプログラム（以後，アプリケーションとも称する。）を備えるサーバ１０４と，サーバ１０４が備えるアプリケーションとの間でＴＣＰ／ＩＰプロトコルにより通信を行うクライアント１０２を含んで構成される。クライアント１０２は複数であってもよい。
【００３０】
クライアント１０２およびサーバ１０４は，通信機能を備えるコンピュータである。サーバ１０４は，クライアント１０２からの要求に応じて，サーバ１０４が有するアプリケーションを起動し，そのアプリケーションとクライアント１０２との間で通信をさせて，クライアント１０２が求めるサービスを提供する。サーバ１０４のアプリケーションとクライアント１０２とが通信を行う際には，サーバ１０４がアプリケーションを識別できるように，各アプリケーションに固有のポート番号が割り当てられる。クライアント１０２は，このポート番号を用いてサーバ１０４内の特定のアプリケーションと通信を行うことができる。
【００３１】
従来は，サーバとクライアントは，ウェルノウンポート番号と称される，アプリケーション毎に固定の既知のポート番号により通信を行っていた。本実施形態では，クライアント１０２が従来のようにウェルノウンポート番号を指定してサーバ１０４にアクセスしても，サーバ１０４はアプリケーションとの通信を開始させない。本実施形態では，サーバ１０４が各アプリケーションに動的にポート番号を付与し，そのポート番号を用いてサーバ・クライアント間で通信を行うことにより，第三者にポート番号を知られることを防止して，通信のセキュリティを向上させている。以下に，通信システム１００について詳細に説明する。
【００３２】
まず，図１に基づいて，クライアント１０２とサーバ１０４の機能構成について説明する。クライアント１０２は，入力部１１０，クライアント送信部１１２，およびクライアント受信部１１４を主に備える。サーバ１０４は，サーバ受信部１２０，サーバ送信部１２２，サーバ側ポート番号付与部１２４，および通信情報記憶部１２８を主に備える。以下では，クライアント１０２とサーバ１０４の各機能について，データの流れに沿って説明する。
【００３３】
クライアント１０２の入力部１１０は，クライアント１０２が備えるマウスやキーボード等の入力手段などを介して，利用したいサービスの識別子を入力する。サービスの識別子は，サーバ１０４のアプリケーションを一意に特定する識別子と対応しており，以後，プログラム識別子と称する。入力部１１０は，入力したプログラム識別子をクライアント送信部１１２に提供する。
【００３４】
クライアント送信部１１２は，通信相手であるサーバ１０４に対し，利用したいサービスについて問い合わせる。詳細には，クライアント送信部１１２は，サービスの問い合わせを行うプロトコルにより，入力部１１０から取得したプログラム識別子によって特定されるサービスの問い合わせを行う。サービスの問い合わせを行うプロトコルとしては，例えば，ＩＣＭＰを利用することができる。その場合，クライアント送信部１１２は，入力部１１０から取得したプログラム識別子を，ＩＣＭＰによりサーバ１０４に送信する。
【００３５】
サーバ受信部１２０は，クライアント１０２から，１以上のアプリケーションプログラムのいずれかを一意に特定するプログラム識別子を受信する。詳細には，サーバ受信部１２０は，クライアント１０２から，ＩＣＭＰにより送信されるプログラム識別子を受信する。サーバ受信部１２０は，受信したプログラム識別子をサーバ側ポート番号付与部１２４に提供する。
【００３６】
サーバ側ポート番号付与部１２４は，サーバ受信部１２０から取得したプログラム識別子により特定されるアプリケーションに，ポート番号を動的に付与する。サーバ側ポート番号付与部１２４による動的なポート番号の付与方法は，例えば，使用可能な空きポート番号を小さい番号から順に付与する方法，使用可能な空きポート番号をランダムに付与する方法，付与時の日時などから所定の計算式により算出したポート番号を付与する方法などが考えられる。なお，ポート番号を動的に決定する方法は，上記には限られず，様々な公知の方法を用いることができる。サーバ側ポート番号付与部１２４は，アプリケーションに付与したポート番号と，そのアプリケーションのプログラム識別子を送信したクライアント１０２を一意に特定する識別子を関連づけて，通信情報記憶部１２８に格納する。また，サーバ側ポート番号付与部１２４は，付与したポート番号をサーバ送信部１２２に提供する。
【００３７】
通信情報記憶部１２８は，ＲＡＭやハードディスク等のメモリを含んで構成され，クライアント１０２の識別子と，サーバ１０４内のアプリケーションに付与されたポート番号とを関連づけて記憶する。図２に，通信情報記憶部１２８に記憶される情報の一例を示した。図２に示すように，通信情報記憶部１２８には，ＩＤ１２８０，クライアント識別子１２８２，およびサーバ側ポート番号１２８４が関連づけて記憶されている。
【００３８】
ＩＤ１２８０は，クライアント識別子とサーバ側ポート番号との組み合わせに各々付与される番号である。クライアント識別子１２８２は，クライアント１０２を一意に特定する識別子であり，例えば，クライアント１０２のＩＰアドレスとすることができる。サーバ側ポート番号１２８４は，サーバ１０４内のアプリケーションに付与されたポート番号である。詳細には，同一のＩＤにより関連づけられているクライアント識別子１２８２によって特定されるクライアント１０２と通信を行うアプリケーションに割り当てられたポート番号である。
【００３９】
サーバ１０４は，クライアント１０２から，そのクライアント１０２の通信相手であるアプリケーションのポート番号を含むデータを受信すると，通信情報記憶部１２８を参照し，データの送信元であるクライアント１０２のＩＰアドレスと，受信したデータに含まれるポート番号とが通信情報記憶部１２８において関連づけられている場合に，クライアント１０２と，ポート番号により特定されるアプリケーションとの通信を取り次ぐことができる。なお，通信情報記憶部１２８には，サーバ側ポート番号により特定されるアプリケーションの識別子がさらに関連づけられて記憶されていてもよい。
【００４０】
図１に戻る。サーバ送信部１２２は，サーバ側ポート番号付与部１２４から取得したポート番号を，クライアント１０２に送信する。詳細には，サーバ送信部１２２は，クライアント１０２からのサービスの問い合わせに対する応答として，ポート番号をクライアント１０２に送信する。例えば，サーバ送信部１２２は，ポート番号を，ＩＣＭＰの応答によりクライアント１０２に送信する。
【００４１】
クライアント受信部１１４は，サーバ１０４からポート番号を受信する。その後，クライアント１０２は，クライアント受信部１１４が受信したポート番号を用いてサーバ１０４にアクセスすることにより，サーバ１０４においてそのポート番号が付与されたアプリケーションと通信を行うことができる。
【００４２】
上記構成の通信システム１００により実行される通信方法について，図３を参照して説明する。
【００４３】
図３に示すように，まず，クライアント１０２が，サーバ１０４に対して，利用したいサービスの問い合わせを行う（Ｓ１００）。詳細には，クライアント１０２が，ＩＣＭＰ等の，サービスの問い合わせを行うプロトコルで，利用したいサービスの識別子をサーバ１０４に送信する。サーバ１０４は，問い合わせを受けて，該当サービスをサーバ１０４が提供していれば，そのサービスに対応するアプリケーションにポート番号を動的に割り当てる（Ｓ１０２）。詳細には，サーバ１０４は，クライアント１０２から受信したデータに含まれるプログラム識別子により特定されるアプリケーションをサーバ１０４が有していれば，そのアプリケーションにポート番号を動的に割り当てる。続いて，サーバ１０４は，アプリケーションに割り当てたポート番号と，サービスの問い合わせ元であるクライアント１０２の識別子とを関連づけて，通信情報記憶部１２８に格納する（Ｓ１０４）。そして，サーバ１０４は，Ｓ１０２で割り当てたポート番号を，クライアント１０２に送信する（Ｓ１０６）。
【００４４】
クライアント１０２は，ポート番号を受信後，受信したポート番号を用いて，サーバ１０４に接続を要求する（Ｓ１０８）。サーバ１０４は，要求を受けて，プロトコル，アプリケーション毎の接続シーケンスを実行する（Ｓ１１０）。詳細には，サーバ１０４は，通信情報記憶部１２８に基づいて，クライアント１０２から受信したデータに含まれるポート番号により識別されるアプリケーションを起動する。その後，起動したアプリケーションが，クライアント１０２との間で通信接続を行い，通信を実行する。
【００４５】
上記構成によれば，サーバ１０４は，クライアント１０２からサービスの問い合わせを受けて，そのサービスに応じたアプリケーションに動的にポート番号を割り当てる。そしてサーバ１０４は，問い合わせに対する応答として，アプリケーションに割り当てたポート番号をクライアント１０２に送信する。そのポート番号を用いることにより，クライアント１０２は，サーバ１０４内の所望のアプリケーションと通信を行うことができる。このように，ポート番号がサーバ１０４によって動的に割り当てられるため，ポート番号を第三者に知られることを防止できる。
【００４６】
また，ポートスキャンに関しては，従来は全ポートに対してパケットを送信し，各ポートの反応を見るという一括処理が可能であったが，上記構成では，逐一サービスを指定して確認するという処理が必要となる。そのため，サーバ１０４は，同じクライアント１０２からの同時アクセス数を制限することが容易であり，ポートスキャンに要する時間を引き延ばすことができる。また，一般的に，大量のサービスを順番に要求するクライアントは正常な動作ではないといえることから，容易に不正なクライアントを発見できるという利点もある。
【００４７】
また，ＩＰアドレススイープに関しては，個々のサーバ１０４にとっては正常なアクセスであるが，ＩＳＰやＩＤＳなど，サーバ１０４の上位装置では，同じ送信元からの大量のＩＣＭＰトラフィックが観測できるため，不正に気づきやすいという利点がある。
【００４８】
（変形例１）
本実施形態において，サーバ１０４がクライアント側のポート番号も指定することにより，さらにセキュリティを向上させることができる。その場合，図１に示すように，サーバ１０４に，クライアント側ポート番号指定部１２６が備えられる。クライアント側ポート番号指定部１２６は，サーバ側ポート番号付与部１２４から，クライアント識別子と，サーバ側ポート番号付与部がアプリケーションに付与したサーバ側のポート番号とを取得する。そしてクライアント側ポート番号指定部１２６は，クライアント識別子により特定されるクライアント１０２と，サーバ側ポート番号により特定されるアプリケーションとが通信を行う場合に，クライアント１０２に使用させるクライアント１０２側のポート番号を指定する。
【００４９】
クライアント側ポート番号指定部１２６は，クライアント識別子，サーバ側のポート番号，および指定したクライアント側のポート番号を関連づけて，通信情報記憶部１２８に格納する。また，クライアント側ポート番号指定部１２６は，指定したクライアント側のポート番号をサーバ送信部１２２に提供する。サーバ送信部１２２は，クライアント側ポート番号指定部１２６から取得したクライアント側のポート番号と，サーバ側ポート番号不要部１２４から取得したサーバ側のポート番号とを，クライアント１０２に送信する。
【００５０】
通信情報記憶部１２８には，図２に示すように，上述のデータに加えて，クライアント側ポート番号１２８６が記憶される。クライアント側ポート番号１２８６は，サーバ側ポート番号１２８４により特定されるサーバ１０４内のアプリケーションが，クライアント識別子１２８２により識別されるクライアントと通信を行う場合の，クライアント１０２により使用されるクライアント側のポート番号である。なお，サーバ１０４は，クライアント１０２のポート番号を「Ａｎｙ」と指定して，いずれのポート番号からの通信でも受け付けるようにすることもできる。
【００５１】
サーバ１０４は，クライアント１０２から，そのクライアント１０２の通信相手であるアプリケーションのポート番号を含むデータを受信すると，通信情報記憶部１２８を参照し，データの送信元であるクライアント１０２のＩＰアドレスと，クライアント１０２が使用しているクライアント側のポート番号と，受信したデータに含まれるサーバ側のポート番号とが通信情報記憶部１２８において関連づけられている場合に，クライアント１０２と，ポート番号により特定されるアプリケーションとの通信を取り次ぐことができる。
【００５２】
サーバ１０４がクライアント側のポート番号も指定する場合の，通信システム１００における通信方法を図４を参照して説明する。
【００５３】
図４に示すように，まず，クライアント１０２が，サーバ１０４に対して，利用したいサービスの問い合わせを行う（Ｓ２００）。サーバ１０４は，問い合わせを受けて，該当サービスをサーバ１０４が提供していれば，そのサービスに対応するアプリケーションにポート番号を動的に割り当てる（Ｓ２０２）。また，サーバ１０４は，クライアント側のポート番号を指定する（Ｓ２０４）。続いて，サーバ１０４は，アプリケーションに割り当てたポート番号と，サービスの問い合わせ元であるクライアント１０２の識別子と，指定したクライアント側のポート番号とを関連づけて，通信情報記憶部１２８に格納する（Ｓ２０６）。そして，サーバ１０４は，Ｓ２０２で割り当てたサーバ側のポート番号と，Ｓ２０４で指定したクライアント側のポート番号とを，クライアント１０２に送信する（Ｓ２０８）。
【００５４】
クライアント１０２は，サーバ側のポート番号とクライアント側のポート番号を受信後，受信した２つのポート番号を用いて，サーバ１０４に接続を要求する（Ｓ２１０）。サーバ１０４は，要求を受けて，プロトコル，アプリケーション毎の接続シーケンスを実行する（Ｓ２１２）。
【００５５】
上記構成によれば，サーバ１０４は，サーバ１０４内のアプリケーションと通信を行うクライアント１０２のポート番号も指定できる。そのため，サーバ１０４は，同一クライアント１０２からのアプリケーションへの接続要求であっても，指定したクライアント側のポート番号を用いている場合のみ，クライアント１０２とアプリケーションとの通信接続を許可することができ，サーバ・クライアント間の通信におけるセキュリティをより向上させることができる。
【００５６】
（第２実施形態）
次に，第２実施形態にかかる通信システム２００について説明する。まず，図５に基づいて，本実施形態にかかる通信システムの概要について説明する。本実施形態にかかる通信システム２００は，１以上のアプリケーションを備えるサーバ２０４と，サーバ２０４が備えるアプリケーションとの間でＴＣＰ／ＩＰプロトコルにより通信を行うクライアント２０２を含んで構成される。クライアント２０２は複数であってもよい。
【００５７】
クライアント２０２およびサーバ２０４は，通信機能を備えるコンピュータである。サーバ２０４は，クライアント２０２からの要求に応じて，サーバ２０４が有するアプリケーションを起動し，そのアプリケーションとクライアント２０２との間で通信をさせて，クライアント２０２が求めるサービスを提供する。サーバ２０４のアプリケーションとクライアント２０２とが通信を行う際には，サーバ２０４がアプリケーションを識別できるように，各アプリケーションに固有のポート番号が割り当てられる。クライアント２０２は，このポート番号を用いてサーバ２０４内の特定のアプリケーションと通信を行うことができる。
【００５８】
本実施形態でも，第１実施形態と同様に，クライアント２０２が従来のようにウェルノウンポート番号を指定してサーバ２０４にアクセスしても，サーバ２０４はアプリケーションとの通信を開始させない。第１実施形態では，サーバがクライアントからサービスの問い合わせを受けて，そのサービスに対応するアプリケーションに動的にポート番号を付与し，そのポート番号を用いてサーバ・クライアント間での通信を行った。本実施形態では，サーバ２０４が，サーバ２０４内のアプリケーションとの通信を許可するか否かを，予め定められた手順に従ってクライアント２０２がサーバ２０４にアクセスしたか否かにより判断する。クライアント２０２が，予め定められた手順に従ってサーバ２０４にアクセスした場合にのみ，クライアント２０２にサーバ２０４内のアプリケーションとの通信を可能にすることにより，第三者によるサーバ２０４内のアプリケーションへの不正なアクセスを防止し，通信のセキュリティを向上させている。以下に，通信システム２００について詳細に説明する。
【００５９】
図５に基づいて，クライアント２０２とサーバ２０４の機能構成について説明する。クライアント２０２は，入力部２１０，クライアント送信部２１２，およびクライアント手順定義テーブル記憶部２１６を主に備える。サーバ２０４は，サーバ受信部２２０，通信可否判断部２３０，サーバ定義手順テーブル記憶部２３２，および通信開始部２３４を主に備える。以下では，クライアント２０２とサーバ２０４の各機能について，データの流れに沿って説明する。
【００６０】
クライアント２０２の入力部２１０は，クライアント２０２が備えるマウスやキーボード等の入力手段などを介して，利用したいサービスの識別子を入力する。サービスの識別子は，サーバ２０４のアプリケーションを一意に特定する識別子と対応しており，以後，プログラム識別子と称する。入力部２１０は，入力したプログラム識別子をクライアント送信部２１２に提供する。
【００６１】
クライアント送信部２１２は，利用したいサービスに応じて，予め定められている手順でサーバ２０４にアクセスを行う。詳細には，クライアント送信部２１２は，クライアント手順定義テーブル記憶部２１６に記憶されているアクセスの手順を参照して，アプリケーションごとに予め定められているアクセスの手順に従って，サーバ２０４にアクセスする。クライアント手順定義テーブル記憶部２１６には，サーバ２０４内のアプリケーション毎にアクセスの手順を定めた手順定義テーブルが記憶されている。クライアント手順定義テーブル記憶部２１６に記憶される手順定義テーブルは，サーバ２０４のサーバ手順定義テーブル記憶部２３２に記憶される手順定義テーブルと同一，または一部である。ここで，図６を参照して，手順定義テーブルについて説明する。
【００６２】
図６に示すように，手順定義テーブルには，アプリケーション２３２０と，アクセス手順２３２２が関連づけられている。アプリケーション２３２０には，サーバ２０４が保有する，またはサーバ２０４が保有可能なアプリケーションの識別子であるプログラム識別子が格納される。アクセス手順２３２２には，プログラム識別子により特定されるアプリケーションとの通信接続がサーバ２０４により許可されるための，サーバ２０４へのアクセスの手順が格納されている。本実施形態では，アクセスの手順を，接続要求の接続先と，その順番とする。詳細には，プロトコルとポート番号の種類と，その順番とする。
【００６３】
具体的には，図６の例によれば，クライアント２０２がサーバ２０４内のｈｔｔｐサーバアプリケーションと通信を行うためには，クライアント２０２は，まずＴＣＰでポート番号８０を指定してサーバ２０４に接続要求をし，次にＴＣＰでポート番号８０を指定してサーバ２０４に接続要求をし，次に，ＴＣＰでポート番号８０を指定してサーバ２０４に接続要求をする。つまり，クライアント２０２がサーバ２０４内のｈｔｔｐサーバアプリケーションと通信を行うためのアクセス手順は，ＴＣＰでポート番号８０を指定した接続要求を連続して３回行うこととなる。図６に示すように，ＦＴＰ，ＴＥＬＮＥＴ等の他のアプリケーションにも，各アプリケーションに固有のアクセス手順が定められている。
【００６４】
図５に戻り，クライアント送信部２１２の説明を続ける。クライアント送信部２１２は，入力部２１０から取得したプログラム識別子を，クライアント手順定義テーブル記憶部２１６から検索し，該当するプログラム識別子に関連づけられているアクセス手順を参照する。そして，そのアクセス手順に従って，サーバ２０４に接続要求を行い，アクセスする。
【００６５】
サーバ受信部２２０は，クライアント２０２からのアクセスを受け付ける。詳細には，サーバ受信部２２０は，クライアント２０２からの接続要求を受信して，受信した接続要求を，受信した順序に従って通信可否判断部２３０に提供する。
【００６６】
通信可否判断部２３０は，手順定義テーブルに定められているアクセスの手順に基づいて，クライアント２０２がアクセスの手順に従ってサーバ２０４にアクセスした場合に，そのクライアント２０２とアプリケーションとの通信を許可するよう，アプリケーションとクライアント２０２との通信を許可するか否かを判断する。詳細には，通信可否判断部２３０は，サーバ受信部２２０が取得した接続要求の種類とその順番を，サーバ手順定義テーブル記憶部２３２に記憶される手順定義テーブルから検索する。該当するアクセス手順が手順定義テーブルに定められていた場合には，サーバ２０４は，そのアクセス手順に関連づけられているプログラム識別子により特定されるアプリケーションと，クライアント２０２との通信を許可し，そのアプリケーションのプログラム識別子を通信開始部２３４に通知する。一方，該当するアクセス手順が手順定義テーブルに定められていない場合には，サーバ２０４は，クライアント２０２がサーバ２０４内のいずれのアプリケーションとも通信を行うことを許可せず，サーバ２０４はクライアント２０２からの接続要求に対する応答を行わない。または，サーバ２０４は，通信不許可の通知をクライアント２０２に対して行うようにしてもよい。
【００６７】
通信開始部２３４は，通信可否判断部２３０により通信を許可された場合に，クライアント２０２に指定されたアプリケーションにクライアント２０２との通信を開始させる。詳細には，通信開始部２３４は，通信可否判断部２３０からプログラム識別子を取得し，そのプログラム識別子により特定されるアプリケーションを起動させる。そして，通信開始部２３４は，そのアプリケーションのウェルノウンポートを開いて，ウェルノウンポートを介したアプリケーションとクライアント２０２との通信を開始させる。以後，クライアント２０２は，ウェルノウンポートを介して，サーバ２０４内の所望のアプリケーションと通信を行い，サービスの提供を受けることができる。
【００６８】
上記構成による通信システム２００により実行される通信方法を，図７を参照して説明する。まず，クライアント２０２が，利用したいサービスのアクセス手順を手順定義テーブルから参照する（Ｓ３００）。次に，クライアント２０２は，参照した手順に従って，サーバ２０４にアクセスする（Ｓ３０２）。
【００６９】
サーバ２０４は，クライアント２０２からのアクセスを受けると，手順定義テーブルに基づいて，クライアント２０２からのアクセスの手順が，予め定められた手順であるかを照合し，通信を許可するか否かを判断する（Ｓ３０４）。サーバ２０４は，通信を許可する場合には，クライアント２０２から要求されたアプリケーションのウェルノウンポートを開いて，クライアント２０２に対して応答を行う（Ｓ３０６）。
【００７０】
上記構成によれば，サーバ２０４は，アプリケーションごとに予め定められた手順によりクライアント２０２からアクセスされた場合にのみ，クライアント２０２とアプリケーションとの通信を許可する。そのため，サーバ２０４内のアプリケーションとクライアント２０２間の通信にアプリケーションのウェルノウンポートを使用する場合でも，アクセス手順を知っているクライアント２０２しかアプリケーションにアクセスすることができない。そのため，サーバ２０４内のアプリケーションへの不正なアクセスを防止し，セキュリティを向上させることができる。また，アプリケーションごとに異なるアクセスの手順を定めることによって，１つのアクセス手順が漏洩した場合であっても，他のアプリケーションへの不正なアクセスを防止することができる。
【００７１】
また，ポートスキャンやＩＰアドレススイープに関しては，上記構成では，第三者がアクセスの手順を知っている場合であっても，サーバ２０４が提供しているサービス（サーバ２０４が有しているアプリケーション）の一覧を得るためには，各サービスについてアクセスの手順を実行してみなくてはならず，非常に多くの処理が必要となる。従って，スクリプト化し難く，また，管理者にポートスキャン等を気づかれやすいため，第三者によりポートスキャンやＩＰアドレススイープが容易に行われることを防止できるという利点がある。
【００７２】
また，ＶＰＮのような暗号化通信を行うアプリケーションを考えた場合，独自の仕様で接続要求を実行させることができ，ＶＰＮ通信を行っているサーバかどうかを外部からは分からないようにすることができるという利点がある。なお，ＶＰＮサービスへの接続には，従来どおりの認証方式が利用可能であり，セキュリティがさらに向上する。
【００７３】
（変形例１）
本実施形態において，サーバ２０４は，上記のようにアプリケーションのウェルノウンポートを用いるのではなく，第１実施形態のように動的にポート番号をアプリケーションに付与するようにしてもよい。また，サーバ２０４は，クライアント側のポート番号を指定するようにしてもよい。その場合，図５に示したように，サーバ２０４に，サーバ側ポート番号付与部２２４，クライアント側ポート番号指定部２２６，通信情報記憶部２２８，およびサーバ送信部２２２が備えられ，クライアント２０２にクライアント受信部２１４が備えられる。サーバ側ポート番号付与部２２４，クライアント側ポート番号指定部２２６，通信情報記憶部２２８，およびサーバ送信部２２２，およびクライアント受信部２１４は，第１実施形態にかかるサーバ側ポート番号付与部１２４，クライアント側ポート番号指定部１２６，通信情報記憶部１２８，およびサーバ送信部１２２，およびクライアント受信部１１４と同様の機能を有するため，説明を省略する。
【００７４】
サーバ２０４がサーバ側のポート番号を動的に付与する場合の通信方法を図８を参照して説明する。まず，クライアント２０２が，利用したいサービスのアクセス手順を手順定義テーブルから参照する（Ｓ４００）。次に，クライアント２０２は，参照した手順に従って，サーバ２０４にアクセスする（Ｓ４０２）。
【００７５】
サーバ２０４は，クライアント２０２からのアクセスを受けると，手順定義テーブルに基づいて，クライアント２０２からのアクセスの手順が，予め定められた手順であるかを照合し，通信を許可するか否かを判断する（Ｓ４０４）。サーバ２０４は，通信を許可する場合には，要求されたアプリケーションに動的にポート番号を割り当て（Ｓ４０６），クライアント２０２の識別子とポート番号とを関連づけて通信情報記憶部２２８に記憶する（Ｓ４０８）。次に，サーバ２０４は，Ｓ４０６で割り当てたポート番号をクライアント２０２に送信する（Ｓ４１０）。
【００７６】
クライアント２０２は，ポート番号を受信後，受信したポート番号を用いて，サーバ２０４に接続を要求する（Ｓ４１２）。サーバ２０４は，要求を受けて，プロトコル，アプリケーション毎の接続シーケンスを実行する（Ｓ４１４）。
【００７７】
上記通信方法によるサーバ２０４・クライアント２０２間での具体的なデータの流れを図９に示した。図９では，クライアント２０２が，図６に示した手順定義テーブルに基づいて，サーバ２０４内のｆｔｐサーバアプリケーションとの通信接続をサーバ２０４に要求する場合の，サーバ２０４・クライアント２０２間のデータの流れを示している。
【００７８】
クライアント２０２は，アクセスの手順に従って，まず，ＩＣＭＰのｅｃｈｏコマンドをサーバ２０４に送信する（Ｓ４３０）。次に，クライアント２０２は，ＴＣＰでポート番号８０を指定してサーバ２０４に接続要求を行う（Ｓ４３２）。次に，クライアント２０２は，ＵＤＰでポート番号９９９を指定してサーバ２０４に接続要求を行う（Ｓ４３４）。次に，クライアント２０２は，ＴＣＰでポート番号２を指定してサーバ２０４に接続要求を行う（Ｓ４３６）。
【００７９】
サーバ２０４は，クライアント２０２がｆｔｐサーバアプリケーションへの予め定められた手順によりアクセスを行ったため，通信を許可し，ｆｔｐアプリケーションにポート番号ｎを動的に割り当てる（Ｓ４３８）。
【００８０】
サーバ２０４は，Ｓ４３８で割り当てたポート番号ｎをクライアント２０２に送信する（Ｓ４４０）。クライアント２０２は，受信したポート番号ｎを指定して接続要求を行い（Ｓ４４２），クライアント２０２とサーバ２０４内のｆｔｐアプリケーションとの間の通信接続が確立する（Ｓ４４４）。
【００８１】
上記構成によれば，ポート番号をサーバ２０４が動的に決定するため，第三者にポート番号を知られることを防止でき，セキュリティをさらに向上させることができる。
【００８２】
（変形例２）
上記第２実施形態で，アクセス手順を，アプリケーションの利用態様ごとに設定するようにしてもよい。詳細には，例えば，同じアプリケーションへのアクセスでも，クライアント２０２とアプリケーション間で実施する認証方式ごとに，異なるアクセス手順を手順定義テーブルに設定してもよい。また，例えば，同じアプリケーションへのアクセスでも，アプリケーションが実行する処理の内容ごとに，異なるアクセス手順を手順定義テーブルに設定してもよい。
【００８３】
本変形例における手順定義テーブルの一例を図１０に示した。図１０に示すように，手順定義テーブルには，アプリケーション２３２０，アクセス手順２３２２，および利用態様２３２４が関連づけられている。アプリケーション２３２０およびアクセス手順２３２２は図６と同様である。利用態様２３２４には，アクセス手順２３２２に格納されている手順によりクライアント２０２がサーバ２０４にアクセスした場合に，該当するアプリケーションをクライアント２０２に利用させる際の利用態様が格納されている。図１０に示すように，本変形例では，１つのアプリケーションに対して複数のアクセス手順が定められている。利用態様として，認証方式の違いや，アプリケーションに実行させる処理の内容，例えば，クライアント２０２がアプリケーションを介して接続できるネットワークの種類などを挙げることができる。
【００８４】
具体的には例えば，同じｓｓｈサーバアプリケーションに対してクライアント２０２が通信接続を要求する場合であっても，ｓｓｈとクライアント２０２間でパスワード認証を行う場合には，ｓｓｈとクライアント２０２間で証明書認証を行う場合よりも，長くて複雑な手順を定めることができる。このように，認証方式によりアクセス手順を変えれば，認証方式の安全性を補うことができる。
【００８５】
また，同じｓｑｕｉｄサーバプリケーションに対してクライアント２０２が通信接続を要求する場合であっても，ｓｑｕｉｄが，クライアント２０２によるインターネットへのアクセスとイントラネットへのアクセスとの双方を中継する場合には，ｓｑｕｉｄがクライアント２０２によるインターネットへのアクセスのみを中継する場合よりも，長くて複雑な手順を定めることができる。
【００８６】
本変形例における通信方法を，図１１を参照して説明する。まず，クライアント２０２は，利用したいサービスと，その利用態様に応じて，アクセス手順を手順定義テーブルから参照する（Ｓ５００）。続いて，クライアント２０２は，参照したアクセスの手順に従って，サーバ２０４にアクセスする（Ｓ５０２）。
【００８７】
サーバ２０４は，クライアント２０２からのアクセスを受けると，手順定義テーブルに基づいて，クライアント２０２からのアクセスの手順が，予め定められた手順であるかを照合し，通信を許可するか否かを判断する（Ｓ５０４）。サーバ２０４は，クライアントからのアクセスの手順によって，通信の可否とともに，通信を要求されているアプリケーションとその利用態様を認識する（Ｓ５０６）。そして，サーバ２０４は，通信を許可する場合には，クライアント２０２から要求されたアプリケーションのウェルノウンポートを開いて，クライアント２０２に対して応答を行う（Ｓ５０８）。
【００８８】
上記通信方法によるサーバ２０４・クライアント２０２間での具体的なデータの流れを図１２に示した。図１２では，クライアント２０２が，図１０に示した手順定義テーブルに基づいて，サーバ２０４内のｓｑｕｉｄサーバアプリケーションと通信接続し，かつ，そのｓｑｕｉｄサーバアプリケーションに，インターネットへのアクセス中継を要望する場合の，サーバ２０４・クライアント２０２間のデータの流れを示している。
【００８９】
クライアント２０２は，アクセスの手順に従って，まずＵＤＰでポート番号５５を指定してサーバ２０４に接続を要求する（Ｓ５３０）。次に，クライアント２０２は，ＴＣＰでポート番号８８０を指定してサーバ２０４に接続を要求する（Ｓ５３２）。次に，クライアント２０２は，ＩＣＭＰをサーバ２０４に送信する（Ｓ５３４）。次に，クライアント２０２は，ＴＣＰでポート番号３１２８を指定してサーバ２０４に接続を要求する（Ｓ５３６）。
【００９０】
サーバ２０４は，クライアント２０２がｓｑｕｉｄサーバアプリケーションへの予め定められた手順によりアクセスを行ったため，通信を許可し，かつ，アクセスの手順によってクライアント２０２から要求されているｓｑｕｉｄの利用態様を認識する。
【００９１】
サーバ２０４は，ｓｑｕｉｄサーバアプリケーションのウェルノウンポートを開いて，クライアント２０２に通信ＯＫの応答を送信し（Ｓ５４０），クライアント２０２とサーバ２０４内のｓｑｕｉｄサーバアプリケーションとの間の通信接続が確立する（Ｓ５４２）。以後，クライアント２０２は，インターネットにアクセス可能なｓｑｕｉｄサーバアプリケーションを利用できる状態となり，クライアント２０２は，サーバ２０４内のｓｑｕｉｄサーバアプリケーションによる中継を経て，インターネットにアクセスすることができる。この場合，サーバ２０４内のｓｑｕｉｄサーバアプリケーションは，クライアント２０２によるインターネットへのアクセスのみを中継し，イントラネットへのアクセスの中継は行わない。
【００９２】
上記構成によれば，利用態様ごとに異なるアクセス手順を設定することで，サーバ２０４はより細かくアクセス制限を行うことができ，セキュリティをさらに向上させることができる。なお，本変形例において，サーバ２０４がアプリケーションに動的にポート番号を付与するようにしてもよい。
【００９３】
（変形例３）
上記実施形態では，アプリケーションごとに異なるアクセス手順を定めたが，全アプリケーションに共通のアクセス手順を定めるようにしてもよい。その場合，クライアント２０２は，まず，定められた手順に従ってサーバ２０４にアクセスし，サーバ２０４がそのクライアント２０２との通信の可否を判断する。その後，通信を許可する場合に，サーバ２０４がクライアント２０２に対して利用したいアプリケーションを問い合わせ，その問い合わせに応じてクライアント２０２がアプリケーションの識別子をサーバ２０４に送信するようにしてもよい。
【００９４】
本変形例による通信方法を，図１３を参照して説明する。まず，クライアント２０２が，全サービスに共通のアクセス手順を手順定義テーブルから参照する（Ｓ６００）。クライアント２０２は，参照したアクセス手順に従って，サーバ２０４にアクセスする（Ｓ６０２）。サーバ２０４は，クライアント２０２からのアクセスを受けて，手順定義テーブルに基づき，そのクライアント２０２との通信を許可するか否かを判断する（Ｓ６０４）。通信を許可する場合には，サーバ２０４は，クライアント２０２に，利用したいサービスを問い合わせる（Ｓ６０６）。なお，通信を許可しない場合には，サーバ２０４は応答を行わない。
【００９５】
クライアント２０２は，サーバ２０４からの問い合わせを受けて，利用したいサービスの識別子をサーバ２０４に送信する（Ｓ６０８）。サーバ２０４は，受信した識別子により特定されるアプリケーションに，動的にポート番号を割り当て（Ｓ６１０），クライアント２０２の識別子とポート番号とを関連づけて通信情報記憶部２２８に記憶する（Ｓ６１２）。次に，サーバ２０４は，Ｓ６１０で割り当てたポート番号をクライアント２０２に送信する（Ｓ６１４）。
【００９６】
クライアント２０２は，ポート番号を受信後，受信したポート番号を用いて，サーバ２０４に接続を要求する（Ｓ６１６）。サーバ２０４は，要求を受けて，プロトコル，アプリケーション毎の接続シーケンスを実行する（Ｓ６１８）。
【００９７】
上記通信方法によるサーバ２０４・クライアント２０２間での具体的なデータの流れを図１４に示した。図１４は，クライアント２０２が，サーバ２０４内のｓｑｕｉｄサーバアプリケーションとの接続を要求する場合の，サーバ２０４とクライアント２０２間でのデータの流れを示している。
【００９８】
クライアント２０２は，全サービスに共通のアクセスの手順に従って，まずＩＣＭＰのｅｃｈｏをサーバ２０４に送信する（Ｓ６３０）。次に，クライアント２０２は，ＴＣＰでポート番号８０を指定してサーバ２０４に接続を要求する（Ｓ６３２）。
【００９９】
サーバ２０４は，予め定められた手順でクライアント２０２からアクセスされたため，そのクライアント２０２との通信を許可し，サービスの問い合わせを行う（Ｓ６３４）。クライアント２０２は，問い合わせに応じて，利用したいサービスの識別子（ここでは，ｓｑｕｉｄサーバアプリケーションのウェルノウンポートとする）をサーバ２０４に送信する（Ｓ６３６）。
【０１００】
サーバ２０４は，ｓｑｕｉｄサーバアプリケーションに動的にポート番号ｎを割り当て（Ｓ６３８），割り当てたポート番号ｎをクライアント２０２に送信する（Ｓ６４０）。クライアント２０２は，受信したポート番号ｎを指定して接続要求を行い（Ｓ６４２），クライアント２０２とサーバ２０４内のｓｑｕｉｄアプリケーションとの間の通信接続が確立する（Ｓ６４４）。
【０１０１】
（第３実施形態）
次に，第３実施形態にかかる通信システム３００について説明する。本実施形態にかかる通信システム３００は，第２実施形態の通信システム２００における，アクセス手順を用いたクライアント・サーバ間の通信方法を採用し，そのアクセス手順を所定のタイミングで更新するようにした。アクセス手順を更新することにより，一度，第三者にアクセス手順が漏洩してしまっても，その後アクセス手順を更新して，該第三者によるサーバへの不正なアクセスを防止することができ，セキュリティをさらに向上させることができる。以後，第２実施形態との相違点を中心に説明する。
【０１０２】
まず，図１５に基づいて，通信システム３００の全体構成について説明する。通信システム３００は，クライアント３０２と，サーバ３０４と，アクセス手順生成サーバ３０６とを主に備える。
【０１０３】
アクセス手順生成サーバ３０６は，クライアント３０２とサーバ３０４との間で使用される，アクセスの手順を生成する。アクセス手順生成サーバ３０６は，クライアント３０２およびサーバ３０４と通信網を介して接続されており，クライアント３０２やサーバ３０４からの要求に応じて生成したアクセスの手順を提供する。なお，アクセス手順生成サーバ３０６は，１日ごと，１週間ごと等の所定の間隔や，毎日０時０分等の所定の時期，または新しいアクセス手順を生成するたびごと等に，クライアント３０２およびサーバ３０４に強制的にアクセス手順を送信してもよい。
【０１０４】
次に，図１５に基づいて，アクセス手順生成サーバ３０６，クライアント３０２，およびサーバ３０４の機能構成について説明する。なお，第２実施形態にかかるクライアント２０２およびサーバ２０４と同様の機能を有するものについては，同一の符号を付与しており，説明を省略する。
【０１０５】
アクセス手順生成サーバ３０６は，アクセス手順を生成するアクセス手順生成部３４０と，生成したアクセス手順を保存するアクセス手順記憶部３４２を主に備える。アクセス手順生成部３４０は，所定間隔ごとや，所定の時期等に，アクセス手順を生成し，生成したアクセス手順をアクセス手順記憶部３４２に格納する。アクセス手順記憶部３４２は，ＲＡＭやハードディスク等のメモリを含んで構成され，アクセス手順を記憶する。なお，アクセス手順記憶部３４２は，最新のアクセス手順のみを記憶していてもよいし，複数のバージョンのアクセス手順を，そのバージョンが分かるように記憶していてもよい。
【０１０６】
クライアント３０２のクライアント手順更新部３１８は，所定のタイミングでアクセス手順生成サーバ３０６にアクセスし，最新のアクセス手順を取得する。クライアント手順更新部３１８は，取得した最新のアクセス手順により，クライアント手順定義テーブル記憶部２１６に記憶されている手順定義テーブルを更新する。なお，クライアント手順更新部３１８は，最新のアクセス手順を手順定義テーブルに追加するようにしてもよい。その場合，クライアント手順定義テーブル記憶部２１６の手順定義テーブルには，複数のバージョンのアクセス手順が，そのバージョンがわかるように格納されることとなる。
【０１０７】
クライアント送信部３１２は，第２実施形態にかかるクライアント送信部２１２とほぼ同様の機能を有するが，アクセス手順を手順定義テーブルから参照する前に，クライアントアクセス手順更新部３１８に最新のアクセス手順を取得させて手順定義テーブルを更新させる点で，クライアント送信部２１２と相違する。この場合，クライアントアクセス手順更新部３１８がアクセス手順生成サーバ３０６からアクセス手順を取得する所定のタイミングは，クライアント送信部３１２に要求されたタイミングとなる。なお，所定のタイミングは，所定間隔毎，所定時期等，任意に設定可能である。
【０１０８】
サーバアクセス手順更新部３３６は，所定のタイミングでアクセス手順生成サーバ３０６にアクセスし，最新のアクセス手順を取得する。サーバアクセス手順更新部３３６は，取得したアクセス手順により，サーバ手順定義テーブル記憶部２３２に記憶されている手順定義テーブルを更新する。所定のタイミングは，所定間隔ごと，所定時期等，任意に設定可能である。
【０１０９】
上記構成の通信システム３００における，クライアント３０２とサーバ３０４との通信方法を，手順定義テーブルの更新を伴う部分を中心に説明する。図１６は，クライアント３０２とサーバ３０４とが有する手順定義テーブルのバージョンが同じであった場合の通信方法を示す。図１７と図１８は，クライアント３０２がサーバ３０４にアクセスした際に，クライアント３０２とサーバ３０４とが有する手順定義テーブルのバージョンが異なった場合の通信方法を示す。特に，図１７は，サーバ３０４の手順定義テーブルは最新バージョンであるが，クライアント３０２の手順定義テーブルが更新されておらず旧バージョンであった場合を示す。図１８は，クライアント３０２の手順定義テーブルは最新バージョンであるが，サーバ３０４の手順定義テーブルが更新されておらず旧バージョンであった場合を示す。
【０１１０】
まず，図１６を参照して説明する。サーバ３０４は，定期的にアクセス手順生成サーバ３０６にアクセス手順を要求する（Ｓ７００）。アクセス手順生成サーバ３０６は，サーバ３０４からの要求に応じて，アクセス手順記憶部３４２に記憶されている最新のアクセス手順をサーバ３０４に送信する（Ｓ７０２）。サーバ３０４は，アクセス手順生成サーバ３０６からアクセス手順を受信し，受信したアクセス手順により手順定義テーブルを更新する（Ｓ７０４）。
【０１１１】
一方，クライアント３０２は，サーバ３０４のアプリケーションと通信を行いたい場合，まず利用したいサービスのアクセス手順をアクセス手順生成サーバ３０６に要求する（Ｓ７０６）。アクセス手順生成サーバ３０６は，クライアント３０２からの要求に応じて，アクセス手順記憶部３４２に記憶されている最新のアクセス手順をクライアント３０２に送信する（Ｓ７０８）。クライアント３０２は，アクセス手順生成サーバ３０６からアクセス手順を受信し，受信したアクセス手順により手順定義テーブルを更新する（Ｓ７１０）。その後，クライアント３０２は，アクセス手順に従って，サーバ３０４にアクセスする（Ｓ７１２）。
【０１１２】
サーバ３０４は，手順定義テーブルに基づいて，通信可否を判断する（Ｓ７１４）。サーバ３０４は，通信を許可する場合には，要求されたアプリケーションのウェルノウンポートを開いて，クライアント３０２に応答する（Ｓ７１６）。なお，Ｓ７１４以降は，第２実施形態と同様であり，サーバ３０４は，ウェルノウンポートを開いてクライアント３０２に応答する以外に，アプリケーションに動的にポート番号を割り当てて，ポート番号をクライアント３０２に通知するようにしてもよい。
【０１１３】
次に，図１７を参照して説明する。サーバ３０４は，定期的にアクセス手順生成サーバ３０６にアクセス手順を要求する（Ｓ７３０）。アクセス手順生成サーバ３０６は，サーバ３０４からの要求に応じて，アクセス手順記憶部３４２に記憶されている最新のアクセス手順をサーバ３０４に送信する（Ｓ７３２）。サーバ３０４は，アクセス手順生成サーバ３０６からアクセス手順を受信し，受信したアクセス手順により手順定義テーブルを更新する（Ｓ７３４）。
【０１１４】
一方，クライアント３０２は，本例では，予め手順定義テーブルを更新することなく，利用したいサービスのアクセス手順を手順定義テーブルから参照し（Ｓ７３６），参照した手順に従ってサーバ３０４にアクセスを行う（Ｓ７３８）。サーバ３０４は，手順定義テーブル７１４に基づいて，通信可否を判断する（Ｓ７４０）。
【０１１５】
本例の場合，Ｓ７３６でクライアント３０２が参照する手順定義テーブルと，Ｓ７４０でサーバ３０４が参照する手順定義テーブルとは，バージョンが異なっている。そのため，クライアント３０２により実行されたアクセス手順は，サーバ３０４が参照した手順定義テーブルには定められていないため，照合に失敗し，サーバは通信不許可の判断を行う。サーバ３０４は，通信不許可の通知を行う（Ｓ７４２）。なお，サーバ３０４は，何も応答を行わなくてもよい。
【０１１６】
クライアント３０２は，通信不許可の通知を受けて，（またはサーバ３０４からの応答が無いことを認識して），利用したいサービスのアクセス手順をアクセス手順生成サーバ３０６に要求する（Ｓ７４４）。
【０１１７】
アクセス手順生成サーバ３０６は，クライアント３０２からの要求に応じて，アクセス手順記憶部３４２に記憶されている最新のアクセス手順をクライアント３０２に送信する（Ｓ７４６）。クライアント３０２は，アクセス手順生成サーバ３０６からアクセス手順を受信し，受信したアクセス手順により手順定義テーブルを更新する（Ｓ７４８）。その後，クライアント３０２は，更新されたアクセス手順に従って，再度，サーバ３０４にアクセスする（Ｓ７５０）。サーバ３０４は，手順定義テーブルに基づいて，通信可否を判断する（Ｓ７５２）。今回は，Ｓ７５０でクライアント３０２が参照する手順定義テーブルと，Ｓ７５２でサーバ３０４が参照する手順定義テーブルとは，バージョンが同じであるため，照合に成功し，サーバ３０４は通信を許可する。
【０１１８】
次に，図１８を参照して説明する。クライアント３０２は，サーバ３０４のアプリケーションと通信を行いたい場合，まず利用したいサービスのアクセス手順をアクセス手順生成サーバ３０６に要求する（Ｓ７７０）。アクセス手順生成サーバ３０６は，クライアント３０２からの要求に応じて，アクセス手順記憶部３４２に記憶されている最新のアクセス手順をクライアント３０２に送信する（Ｓ７７２）。クライアント３０２は，アクセス手順生成サーバ３０６からアクセス手順を受信し，受信したアクセス手順を手順定義テーブルに追加する（Ｓ７７４）。その後，クライアント３０２は，最新のアクセス手順に従って，サーバ３０４にアクセスする（Ｓ７７６）。サーバ３０４は，手順定義テーブルに基づいて，通信可否を判断する（Ｓ７７８）。
【０１１９】
本例では，サーバ３０４が手順定義テーブルを更新していないか，定期的に更新してはいても，更新のタイミングがクライアント３０２によるＳ７７４での更新よりも後であるため，Ｓ７７６でクライアント３０２が参照する手順定義テーブルと，Ｓ７７８でサーバ３０４が参照する手順定義テーブルとは，バージョンが異なっている。そのため，サーバ３０４は，アクセス手順の照合に失敗し，通信を不許可と判断する。サーバ３０４は，通信不許可の通知をクライアント３０２に行う（Ｓ７８０）。または，サーバ３０４は，何の応答も返さないようにしてもよい。
【０１２０】
クライアント３０２は，通信不許可の通知を受けて，（またはサーバ３０４からの応答が無いことを認識して），サーバ３０４の手順定義テーブルが最新でないことを認識する。そして，クライアント３０２は，手順定義テーブルに保存されている旧バージョンのアクセス手順を参照し，参照したアクセス手順に従って，再度，サーバ３０４にアクセスする（Ｓ７８２）。サーバ３０４は，手順定義テーブルに基づいて，通信可否を判断する（Ｓ７８４）。今回は，同バージョンのアクセス手順によりアクセスされたため，サーバ３０４は，照合に成功し，通信を許可する（Ｓ７８４）。
【０１２１】
本実施形態にかかる通信システム３００によれば，サーバ３０４がサーバ３０４内のアプリケーションとクライアント３０２との通信を許可するか否かを判断する基となるアクセス手順が，所定のタイミングで順次更新される。そのため，アクセス手順が第三者に漏洩した場合でも，アクセス手順が更新される所定のタイミング以降は，漏洩したアクセス手順によるサーバ３０４へのアクセスは無効となる。従って，第三者によるサーバ３０４内のアプリケーションへの不正なアクセスを防止することができ，セキュリティを向上させることができる。
【０１２２】
上記各実施形態および各変形例によれば，既存のＴＣＰ／ＩＰとの互換性を保ちつつ，より高いセキュリティを実現することができる。
【０１２３】
以上，添付図面を参照しながら本発明の好適な実施形態について説明したが，本発明は係る例に限定されないことは言うまでもない。当業者であれば，特許請求の範囲に記載された範疇内において，各種の変更例または修正例に想到し得ることは明らかであり，それらについても当然に本発明の技術的範囲に属するものと了解される。
【図面の簡単な説明】
【０１２４】
【図１】本発明の第１の実施形態における通信システムを示すブロック図である。
【図２】同実施の形態における通信情報記憶部の記憶内容を示す説明図である。
【図３】同実施の形態におけるサーバ・クライアント間の通信方法を示すフローチャートである。
【図４】同実施の形態の変形例におけるサーバ・クライアント間の通信方法を示すフローチャートである。
【図５】本発明の第２の実施形態における通信システムを示すブロック図である。
【図６】同実施の形態における手順定義テーブルを示す説明図である。
【図７】同実施の形態におけるサーバ・クライアント間の通信方法を示すフローチャートである。
【図８】同実施の形態の変形例１におけるサーバ・クライアント間の通信方法を示すフローチャートである。
【図９】同実施の形態の変形例１における通信方法の具体例を示すフローチャートである。
【図１０】同実施の形態の変形例２における手順定義テーブルを示す説明図である。
【図１１】同実施の形態の変形例２におけるサーバ・クライアント間の通信方法を示すフローチャートである。
【図１２】同実施の形態の変形例２における通信方法の具体例を示すフローチャートである。
【図１３】同実施の形態の変形例３におけるサーバ・クライアント間の通信方法を示すフローチャートである。
【図１４】同実施の形態の変形例３における通信方法の具体例を示すフローチャートである。
【図１５】本発明の第３の実施形態における通信システムを示すブロック図である。
【図１６】同実施の形態におけるサーバ・クライアント間の通信方法を示すフローチャートである。
【図１７】同実施の形態におけるサーバ・クライアント間の通信方法を示すフローチャートである。
【図１８】同実施の形態におけるサーバ・クライアント間の通信方法を示すフローチャートである。
【符号の説明】
【０１２５】
１００，２００，３００      通信システム
１０２，２０２，３０２      クライアント
１０４，２０４，３０４      サーバ
３０６      アクセス手順生成サーバ
１１２，２１２，３１２      クライアント送信部
１１４，２１４      クライアント受信部
１２０，２２０      サーバ受信部
１２２，２２２      サーバ送信部
１２４，２２４      サーバ側ポート番号付与部
１２６，２２６      クライアント側ポート番号指定部
１２８，２２８      通信情報記憶部
２１６      クライアント手順定義テーブル記憶部
２３０      通信可否判断部
２３２      サーバ手順定義テーブル記憶部
２３４      通信開始部
３４０      アクセス手順生成部
３４２      アクセス手順記憶部
３１８      クライアントアクセス手順更新部
３３６      サーバアクセス手順更新部
【図１】
2007200209.tif 000003
【図２】
2007200209.tif 000004
【図３】
2007200209.tif 000005
【図４】
2007200209.tif 000006
【図５】
2007200209.tif 000007
【図６】
2007200209.tif 000008
【図７】
2007200209.tif 000009
【図８】
2007200209.tif 000010
【図９】
2007200209.tif 000011
【図１０】
2007200209.tif 000012
【図１１】
2007200209.tif 000013
【図１２】
2007200209.tif 000014
【図１３】
2007200209.tif 000015
【図１４】
2007200209.tif 000016
【図１５】
2007200209.tif 000017
【図１６】
2007200209.tif 000018
【図１７】
2007200209.tif 000019
【図１８】
2007200209.tif 000020