(57)【要約】本発明は、クライアントとアプリケーションサーバとの間の安全な通信チャネルを確立するためのシステムおよび方法を特徴とする。一実施形態では、チケットサービスは、識別子およびセッション鍵を有するチケットを生成する。通信デバイスは、チケットサービスからチケットを取得し、安全な通信チャネルを介してチケットをクライアントに伝送する。クライアントは、アプリケーション通信チャネルを介してチケットの識別子をアプリケーションサーバに伝送する。次いで、アプリケーションサーバは、チケットサービスからチケットのセッション鍵のコピーを取得する。アプリケーション通信チャネルを介するクライアントとアプリケーションサーバとの間で交換される通信は、次いで、安全な通信チャネルとしてアプリケーション通信チャネルを確立するためにセッション鍵を使用して暗号化される。
2004531914.tif 000002
【特許請求の範囲】
【請求項１】
クライアントとアプリケーションサーバとの間の安全な通信チャネルを確立するための方法であって、
識別子およびノンヌル（ｎｏｎ−ｎｕｌｌ）価値セッション鍵を有するチケットをチケットサービスによって、生成するステップと、
該チケットサービスから、該チケットを取得するステップと、
安全な通信チャネルを介して、クライアントに該チケットを伝送するステップと、
アプリケーション通信チャネルを介して、該クライアントによって該チケットの該識別子をアプリケーションサーバに伝送するステップと、
該チケットサービスからの該チケットの該ノンヌル価値セッション鍵のコピーを該アプリケーションサーバによって取得するステップと、
該アプリケーション通信チャネルを安全な通信チャネルとして、確立するために該ノンヌル価値セッション鍵を使用して、該アプリケーション通信チャネルを介して該クライアントと該アプリケーションサーバとのやりとりを行う通信を暗号化するステップと
を包含する、方法。
【請求項２】
前記チケットサービスから前記チケットを取得するステップは、該チケットをウェブサーバに伝送するステップをさらに包含する、請求項１に記載の方法。
【請求項３】
前記チケットをクライアントに伝送するステップは、前記ウェブサーバによって該チケットを伝送するステップを含む、請求項２に記載の方法。
【請求項４】
前記チケットサービスは、前記ウェブサーバ上に常駐する、請求項２に記載の方法。
【請求項５】
前記アプリケーションサーバによって、前記識別子をサーバ通信チャネルを介して前記ウェブサーバに伝送するステップをさらに包含する、請求項２に記載の方法。
【請求項６】
前記識別子を前記ウェブサーバに前記伝送するステップの応答を、アプリケーションサーバによって受け取るステップをさらに包含する請求項５に記載の方法。
【請求項７】
前記アプリケーションサーバによって伝送された前記識別子を前記ウェブサーバによって確証するステップをさらに包含する、請求項５に記載の方法。
【請求項８】
前記確証するステップは、前記識別子が、前記ウェブサーバによって前記クライアントに伝送された時間に関連する特定の時間フレーム内で受け取られることを該ウェブサーバによって確認するステップをさらに包含する、請求項７に記載の方法。
【請求項９】
クライアントとアプリケーションサーバとの間の安全な通信チャネルを確立するための方法であって、
該クライアント上で実行するウェブブラウザとウェブサーバとの間に安全なウェブ通信チャネルを確立するステップと、
該安全なウェブ通信チャネルを介し、該ウェブサーバから識別子およびノンヌル価値セッション鍵を有するチケットを受け取るステップと、
該ノンヌル価値セッション鍵のコピーを取得するために情報を該アプリケーションサーバに供給するアプリケーション通信チャネルを介して、該アプリケーションサーバに該チケットの該識別子を伝送するステップと
を包含する方法。
【請求項１０】
クライアントとアプリケーションサーバとの間の安全な通信チャネルを確立するための方法であって、
安全なウェブ通信チャネルを介して、識別子とノンヌル価値セッション鍵を有するチケットを受け取るステップと、
該ノンヌル価値セッション鍵のコピーを取得するための情報を該アプリケーションサーバに提供するために、アプリケーション通信チャネルを介して、該チケットの該識別子を該アプリケーションサーバに伝送するステップと、
該アプリケーション通信チャネルを安全な通信チャネルとして確立するために、該安全なウェブ通信チャネルを介して受け取られた該ノンナル価値セッション鍵を使用して、該アプリケーション通信チャネルを介して該アプリケーションサーバに伝送されるおよび該アプリケーションサーバから受け取られる通信を暗号化および復号化するステップと
を包含する、方法。
【請求項１１】
前記安全なウェブ通信チャネルを介して、ソフトウェアアプリケーションを要求するステップをさらに包含する、請求項１０に記載の方法。
【請求項１２】
前記識別子はナンスである、請求項１０に記載の方法。
【請求項１３】
前記安全なウェブ通信チャネルを確立するために、安全なソケット層技術を使用するステップをさらに包含する、請求項１０に記載の方法。
【請求項１４】
前記チケットは、チケットサービスによって生成される、請求項１０に記載の方法。
【請求項１５】
前記識別子は、アプリケーションサーバ電子署名である、請求項１０に記載の方法。
【請求項１６】
前記アプリケーション通信チャネルを確立するために、安全なソケットレイヤー技術を使用するステップをさらに包含する、請求項１５に記載の方法。
【請求項１７】
パスワードを前記アプリケーションサーバに伝送するステップをさらに包含する、請求項１０に記載の方法。
【請求項１８】
前記ウェブ通信チャネルを介して、前記チケットおよびリモートディスプレイプロトコルアプリケーションを受け取るステップをさらに包含する、請求項１０に記載の方法。
【請求項１９】
安全な通信チャネルを確立するための通信システムであって、
識別子およびノンヌル価値セッション鍵を有するチケットを生成するチケットサービスと、
該チケットサービスから該チケットを取得するために、該チケットサービスと通信する通信デバイスと、
該安全な通信チャネルを介して該通信デバイスから該チケットを受け取るために、安全な通信チャネルを介して該通信デバイスと通信するクライアントと、
該クライアントから該チケットの該識別子を受け取るためにアプリケーション通信チャネルを介して該クライアントと通信し、および該チケットサービスから該ノンヌル価値セッション鍵のコピーを取得するために該チケットサービスと通信するアプリケーションサーバであって、該アプリケーションサーバおよび該クライアントは、該アプリケーション通信チャネルを安全な通信チャネルとして確立するために該ノンヌル価値セッション鍵を使用して、該アプリケーション通信チャネルを介して、暗号化された通信のやり取りを行うアプリケーションサーバと
を含む、通信システム。
【請求項２０】
前記チケットサービスは、前記通信デバイス上に常駐する、請求項１９に記載のシステム。
【請求項２１】
サーバ通信チャネルを介して、前記識別子を前記通信デバイスに伝送する前記アプリケーションサーバをさらに含む、請求項２０に記載のシステム。
【請求項２２】
前記識別子に応答して、前記ノンヌル価値セッション鍵のコピーをを要求する前記アプリケーションサーバをさらに含む、請求項２１に記載のシステム。
【請求項２３】
前記アプリケーションサーバによって伝送される前記識別子を確証する前記通信デバイスをさらに含む、請求項２２に記載のシステム。
【請求項２４】
確証する前記通信デバイスは、前記識別子が以前に前記アプリケーションサーバによって伝送されてなかったことを確認する前記通信デバイスをさらに含む、請求項２３に記載のシステム。
【請求項２５】
確証する前記通信デバイスは、前記識別子が、前記通信デバイスによって前記クライアントに伝送された時間に関連する特定の時間フレーム内で前記通信デバイスによって受け取られることを確認する前記通信デバイスをさらに含む、請求項２３に記載のシステム。
【請求項２６】
前記識別子に応答して前記サーバ通信チャネルを介して前記ノンヌル価値セッション鍵を前記アプリケーションサーバに伝送する前記通信デバイスをさらに含む、請求項２４に記載のシステム。
【請求項２７】
前記サーバ通信チャネルは、安全な通信チャネルである、請求項２４に記載のシステム。
【請求項２８】
前記通信チャネルを介して、付加的な情報を前記アプリケーションサーバに伝送する前記通信デバイスをさらに含む、請求項１９に記載のシステム。
【請求項２９】
前記付加的なチケット情報は、前記クライアントのユーザのログイン情報をさらに含む、請求項２８に記載のシステム。
【請求項３０】
前記付加的なチケット情報は、アプリケーションサーバ上で実行するソフトウェアアプリケーションの名前をさらに含む、請求項２９に記載のシステム。
【請求項３１】
前記通信デバイスは、ウェブサーバをさらに含む、請求項１９に記載のシステム。
【請求項３２】
前記クライアントをオペレーティングするユーザのパスワードを前記アプリケーションサーバに伝送する該クライアントをさらに含む、請求項１９に記載の方法。
【請求項３３】
少なくとも一つの前記クライアントと該クライアントをオペレーティングするユーザに対応する情報を前記アプリケーションサーバに伝送する前記チケットサービスをさらに含む、請求項１９に記載の方法。
【発明の詳細な説明】
【０００１】
（発明の分野）
本発明は、概して、クライアント‐サーバコンピュータネットワークに関する。より具体的には、本発明は、リモート表示プロトコルを使用してソフトウェアアプリケーションに安全にアクセスするためのシステムおよび方法に関する。
【０００２】
（発明の背景）
クライアントコンピュータまたはクライアントにリモートに表示されるために要求されるソフトウェアアプリケーションは、グラフィック的またはウィンドウ方式の端末セッションで通常アクセスされる。ユーザがクライアントコンピュータ上でアプリケーションを要求する際、このアプリケーションはサーバ上で実行され、一般的には、入力情報（例えば、マウスおよびキーボード情報）および表示情報はサーバコンピュータからクライアントコンピュータに伝送される。グラフィック的またはウィンドウ方式の端末セッションはしばしば、認証されていないクライアントとサーバ間の接続を使用する。あるいは、グラフィック的またはウィンドウ方式の端末セッションは、ユーザがサーバにパスワードを提供することでクライアントとサーバ間の接続を認証し得る。
【０００３】
端末セッションによって使用される上述の技術は、種々の欠点を有する。例えば、パスワード情報のような情報を認証されていないサーバに対して伝送することは、このサーバは、情報がクライアントから信頼されていないサーバによって見られることを可能にする。その安全でない接続は、盗聴者が今後の使用のためにユーザのパスワードを傍受することを可能にする。
【０００４】
これらの問題を避けるために、クライアントおよびサーバは、従来の暗号技術を使用して一般的に認証される。ネットワークによって使用される暗号技術の一つのタイプは、チケットベースの認証スキームである。現在使用されているチケットベースの認証スキームのほとんどは、チケットを伝送する。一般的に一度のみ使用され得るチケットは、今後の通信において使用されるために暗号化鍵を含み得、および／または今後の通信を支援するために秘密パスワードを含み得る。クライアントおよびサーバの両方が暗号化鍵を有する場合、クライアントおよびサーバは、安全に通信し得る。
【０００５】
しかしながら、現在使用されているチケットベースの認証スキームは、いくつかの領域内に制限される。第一に、チケットは一般的に安全でない通信チャネルを介してクライアントに伝送される。それによって、盗聴者がチケットを傍受し、暗号化鍵を取り出すことを可能にする。暗号化鍵を使用して、盗聴者は、クライアントに対してサーバのように、またはサーバに対してクライアントのように見せかけ得る。第二に、現在使用されているスキームは、安全なウェブページをうまく利用できない。例えば、購入者のクレジットカード情報のような所有者の情報が、非安全ウェブページに伝送され得るので、現在使用されているチケットベースの認証スキームは、購入のようなインターネットを介してのトランザクションを安全でなくさせる。第三に、サーバ上で実行しているソフトウェアアプリケーションは、クライアントマシン上のリモート表示プロトコルのディスプレイに対する非安全通信チャネルを介して、一般的に、伝送される。例えば、ネットワークは、非安全通信チャネルを介してリモート表示サービスに一般的に伝送される特有のアプリケーションを実行するための特定のアプリケーションサーバ（例えば、フロリダ州、Ｆｔ．ＬａｕｄｅｒｄａｌｅのＣｉｔｒｉｘ  Ｓｙｓｔｅｍｓ，Ｉｎｃによって製造されている、Ｗｉｎｄｏｗｓ（登録商標）に対するＭｅｔａｆｒａｍｅ）からなり得る。第四に、チケットは一般的に一回に限り使用され（すなわち、それを「ワンタイム使用」チケットにさせる）、その一回目の使用の後にさらなる価値は有さないが、このワンタイム使用チケットは、チケットの一回目の伝送中に盗聴者からユーザのオペレーティングシステムまたはアプリケーションへのログインのために使用されるパスワード（パスワードは、オペレーティングシステムまたはアプリケーションにログインするために使用される）を保護しない。それゆえ、ユーザのパスワードは、いまだ傍受から完全には保護されず、そして、サーバは、結果としてクライアントに対して認証されない。
【０００６】
（発明の要旨）
本発明は、クライアントとアプリケーションサーバとの間の安全な通信チャネルを確立するためのシステムおよび方法を特徴とする。チケットサービスは、識別子およびセッション鍵を有するチケットを生成する。通信デバイスは、チケットサービスからチケットを取得し、安全な通信チャネルをかいしてチケットをクライアントに伝送する。クライアントは、アプリケーション通信チャネルをかいしてチケットの識別子をアプリケーションサーバに伝送する。次いで、アプリケーションサーバは、チケットサービスからチケットのセッション鍵のコピーを取得する。アプリケーション通信チャネルを介するクライアントとアプリケーションサーバとの間で交換される通信は、次いで、安全な通信チャネルとしてアプリケーション通信チャネルを確立するためにセッション鍵を使用して暗号化される。
【０００７】
一実施形態において、クライアント上で実行するウェブブラウザは、安全なウェブ通信チャネルを介するウェブサーバとの通信を確立する。クライアントは、安全なウェブ通信チャネルを介して、ウェブサーバから識別子およびセッション鍵を有するチケットを受け取る。クライアントは、次いで、セッション鍵のコピーを取得するための情報をアプリケーションサーバに供給するためにアプリケーション通信チャネルを介して、チケットの識別子をアプリケーションサーバに伝送する。
【０００８】
一局面において、本発明は、クライアントとアプリケーションサーバとの間の安全な通信チャネルを確立するための方法に関する。クライアントは、安全なウェブ通信チャネルを介して、ウェブサーバから識別子およびセッション鍵を有するチケットを受け取る。次いで、クライアントは、セッション鍵のコピーを取得するための情報をアプリケーションサーバに供給するためにアプリケーション通信チャネルを介してチケットの識別子をアプリケーションサーバに伝送する。クライアントは、アプリケーションサーバへおよびアプリケーションサーバからの通信を暗号化および復号化するためにセッション鍵を使用することによってアプリケーション通信チャネルを介する安全な通信チャネルを確立する。この識別子はナンスである。一実施形態において、クライアントおよびウェブサーバは、安全なウェブ通信チャネルを設立するために安全なソケットレイヤー技術を使用する。
【０００９】
他の局面において、本発明は安全な通信チャネルを確立する通信システムに関する。通信システムは、クライアント、アプリケーションサーバ、通信デバイスおよびチケットサービスを含む。チケットサービスは、識別子およびセッション鍵を有するチケットを生成する。通信デバイスは、チケットを取得するためにチケットサービスと通信する。クライアントは、通信デバイスからチケットを受け取るために、安全な通信チャネルを介して通信デバイスと通信する。アプリケーションサーバは、クライアントからチケットの識別子を受け取るためにアプリケーション通信チャネルを介してクライアントと通信し、チケットサービスから、セッション鍵のコピーを取得するためにチケットサービスと通信する。アプリケーションサーバおよびクライアントは、安全な通信チャネルとしてアプリケーション通信チャネルを介する通信を交換する。一実施形態において、チケットサービスは、通信デバイス上に常駐する。一実施形態において通信デバイスはウェブサーバである。
【００１０】
上述された本発明の局面および本発明の付随的な利点の多くは、添付の図を参照することによってより理解される。添付の図面は、本発明の好ましい実施形態に従ったシステムを示す。
【００１１】
（詳細な説明）
図１は、アプリケーション通信チャネル２５を介してアプリケーションサーバ１５と通信し、通信チャネル３０を介して通信デバイス２０と通信するクライアント１０を含む通信システム１００の一実施形態のブロック図を示す。通信チャネル３０およびアプリケーション通信チャネル２５は、ネットワーク２７を通過する。他の実施形態において、通信チャネル３０およびアプリケーションチャネル２５は、他の異なるネットワークを通過する。例えば、通信チャネル３０は、第一のネットワーク（例えば、ワールドワイドウェブ）を通過し得、アプリケーション通信チャネル３０は第二のネットワーク（例えば、直接ダイアルアップモデム接続）を通過し得る。通信チャネル３０は、通信が暗号化されるという理由で、安全な通信チャネルである。さらに、アプリケーションサーバ１５は、サーバ通信チャネル３５を介して、通信デバイス２０と通信する。アプリケーションサーバ１５および通信デバイス２０は、サーバネットワーク３３の一部である。安全な通信チャネル３０を介するクライアント１０と通信デバイス２０との間の、安全な通信のセキュリティを利用することにより、通信システム１００は、クライアント１０上に安全にデスクトップアプリケーションをリモート表示するために非安全アプリケーション通信チャネル２５を介しての安全通信リンクを確立する。
【００１２】
ネットワーク２７およびサーバネットワーク３３は、ローカルエリアネットワーク（ＬＡＮ）またはワイドエリアネットワーク（ＷＡＮ）であり得、または、インターネットまたはワールドワイドウェブすなわち、ウェブのような複数のネットワークの中のネットワークであり得る。通信チャネル３０は、任意の安全な通信チャネルであり得る。一実施形態において、通信チャネル３０（以下では、ウェブ通信チャネル３０）は、ウェブを介して通信を支援する。一実施形態において、サーバネットワーク３３は、公衆によってアクセスされ得ない保護されたネットワークである。サーバ通信チャネル３５は、サーバネットワーク３３を横切り、それゆえ、非安全通信チャネルであり得る。通信チャネル２５，３０，３５の実施形態の例は、ＬＡＮまたはＷＡＮリンク（例えば、Ｔ１，Ｔ３，５６ｋｂ，Ｘ．２５）、ブロードバンド接続（ＩＳＤＮ，Ｆｒａｍｅ  Ｒｅｌａｙ，ＡＴＭ）および無線接続を含む。通信チャネル２５，３０，３５を介する接続は、種々の通信プロトコルを使用して確立され得る（例えば、ＨＴＴＰ、ＴＣＰ／ＩＰ、ＩＰＸ、ＳＰＸ、ＮｅｔＢＩＯＳ、Ｅｔｈｅｒｎｅｔ（登録商標）、ＲＳ２３２および直接非同期接続）。
【００１３】
クライアント１０は、任意の個人用コンピュータ（例えば、２８６，３８６，４８６、Ｐｅｎｔｉｕｍ（登録商標）、Ｐｅｎｔｉｕｍ（登録商標）ＩＩ、Ｍａｃｉｎｔｏｓｈ  ｃｏｍｐｕｔｅｒ）、Ｗｉｎｄｏｗｓ（登録商標）ベースの端末、Ｎｅｔｗｏｒｋ  Ｃｏｍｐｕｔｅｒ、無線デバイス（例えば、携帯電話）、情報機器、ＲＩＳＣ  Ｐｏｗｅｒ  ＰＣ、Ｘ−ｄｅｖｉｃｅ、ワークステーション、ミニコンピュータ、メインフレームコンピュータ、パーソナルデジタルアシスタント、または、安全なウェブ通信チャネル３０を介しての通信が可能である他の通信デバイスであり得る。一実施形態において、クライアント１０は、サーバベースのコンピュータモデルに従って動作する。サーバベースのコンピュータモデルにおけるアプリケーションプログラムの実行は、アプリケーションサーバ１５上で全て起こり、そしてユーザインターフェイス、キーストロークおよびマウス動作は、アプリケーション通信チャネル２５を介してクライアント１０に伝送される。ユーザインターフェイスは、テキストドライブ型（例えば、ＤＯＳ）であり、または、グラフィックドライブ型（例えば、Ｗｉｎｄｏｗｓ（登録商標））であり得る。クライアント１０によって支援され得るプラットフォームは、ＤＯＳおよびｗｉｎｄｏｗｓ（登録商標）ベースの端末のＷｉｎｄｏｗｓ（登録商標）  ＣＥであり得る。
【００１４】
一実施形態において、クライアント１０は、ウェブに接続するために、例えばワシントン州、Ｒｅｄｍｏｎｄにある、マイクロソフト株式会社によって開発されたＩｎｔｅｒｎｅｔ  ＥｘｐｌｏｒｅｒＴＭのようなウェブブラウザ４０を含む。さらなる実施形態において、ウェブブラウザ４０は、通信デバイス２０のような通信デバイスに対する安全なウェブ通信チャネル３０を確立するためにカリフォルニア州、Ｍｏｕｎｔａｉｎ  ｖｉｅｗのＮｅｔｓｃａｐｅによって開発された、実存のＳｅｃｕｒｅ  Ｓｏｃｋｅｔ  Ｌａｙｅｒ（ＳＳＬ）サポートを使用する。ウェブブラウザ４０は、また、テキストドライブ型またはグラフィックドライブ型であり得るユーザインターフェースを有する。アプリケーションサーバ１５上で実行するアプリケーションの出力は、クライアント１０のユーザインターフェースまたはウェブブラウザ４０のユーザインターフェースを介してクライアント１０にて表示され得る。さらに、クライアント１０は、アプリケーション通信チャネル２５を介して、アプリケーションサーバ１５との通信を確立および交換するためのアプリケーションクライアント４１を含む。一実施形態において、アプリケーションクライアント４１は、フロリダ州、Ｆｏｒｔ  ＬａｕｄｅｒｄａｌｅのＣｉｔｒｉｘ  Ｓｙｓｔｅｍｓ，Ｉｎｃによって開発されたＩｎｄｅｐｅｎｄｅｎｔ  Ｃｏｍｐｕｔｉｎｇ  Ａｒｃｈｉｔｅｃｔｕｒｅ（ＩＣＡ）クライアントであり、以下でＩＣＡクライアント４１として参照される。アプリケーションクライアント４１の他の実施形態は、ワシントン州、Ｒｅｄｍｏｎｄにある、マイクロソフト株式会社によって開発されたＲｅｍｏｔｅ  Ｄｉｓｐｌａｙ  Ｐｒｏｔｏｃｏｌ（ＲＤＰ）、マサチューセッツ州、Ｃａｍｂｒｉｄｇｅのマサチューセッツ工科大学によって開発されたＸ−Ｗｉｎｄｏｗｓ（登録商標）、伝統的なクライアント／サーバアプリケーションにおけるデータエントリクライアント、およびＪａｖａ（登録商標）アプレットを含む。
【００１５】
アプリケーションサーバ１５は、クライアント１０によってアクセスされ得る一つ以上のアプリケーションプログラムのホストである。使用のためにクライアントに対して利用可能にされたアプリケーションは、公開されたアプリケーションとして参照される。このようなアプリケーションの例は、ＭＩＣＲＯＳＯＦＴ  ＷＯＲＤ（登録商標）のようなワープロプログラムおよびＭＩＣＲＯＳＯＦＴ  ＥＸＣＥＬ（登録商標）のような表計算プログラムを含む。これら両方は、ワシントン州、Ｒｅｄｍｏｎｄにある、マイクロソフト株式会社によって製造されており、財務報告プログラム、顧客登録プログラム、技術サポート情報を提供するプログラム、消費者データベースアプリケーション、または、アプリケーション設定マネージャである。別の実施形態において、アプリケーションサーバ１５は、サーバファーム（ｆａｒｍ）（示さず）の要素である。サーバファームは、単一エンティティのような管理された一つ以上の論理グループ（ｌｏｇｉｃａｌ  ｇｒｏｕｐ）である。
【００１６】
一実施形態において、通信デバイス２０（以下、ウェブサーバ２０）は、ウェブページをクライアント１０に伝送するコンピュータである。他の実施形態において、通信デバイス２０は、任意のパーソナルコンピュータ、例えば、２８６，３８６，４８６、Ｐｅｎｔｉｕｍ（登録商標），Ｐｅｎｔｉｕｍ（登録商標）ＩＩ，Ｍａｃｉｎｔｏｓｈ  ｃｏｍｐｕｔｅｒ）、Ｗｉｎｄｏｗｓ（登録商標）ベースの端末、Ｎｅｔｗｏｒｋ  Ｃｏｍｐｕｔｅｒ、無線デバイス（例えば、携帯電話）、情報機器、ＲＩＳＣ  Ｐｏｗｅｒ  ＰＣ、Ｘ−ｄｅｖｉｃｅ、ワークステーション、ミニコンピュータ、メインフレームコンピュータ、パーソナルデジタルアシスタント、または、クライアント１０との安全ウェブ通信チャネル３０を確立し得る他の通信デバイスであり得る。
【００１７】
一実施形態において、ウェブサーバ２０はまた、チケットサービス６０を含む。このチケットサービス６０は、通信セキュリティを制御する。チケットサービス６０は、暗号鍵を含むチケットを生成する。チケットは、安全なウェブ通信チャネル３０を介してクライアント１０（すなわち、ウェブブラウザ４０）に伝送される。安全なウェブ通信チャネル３０を介するクライアント１０に対するチケットの伝送は、本発明の原理に従ったクライアント１０とアプリケーションサーバ１５との間のアプリケーション通信チャネル２５を介する安全な通信の確立を容易にする。他の実施形態において、チケットサービス６０’は、別のサーバ２０’上に常駐する。サーバ２０’（および、チケットサービス６０’）は、サーバ通信チャネル３５’を介してウェブサーバ２０およびアプリケーションサーバ１５と通信する。さらに、別の実施形態において、チケットサービス６０は、サーバネットワーク３３とは別のコンポーネント（示さず）である。ウェブブラウザ４０は次いで、チケットをＩＣＡクライアント４１に送信する。クライアント１０に対する安全な接続を介してアプリケーションサーバ１５上で実行されるアプリケーションからアプリケーションデータを伝送するためにしばしば使用される技術は、アプリケーションデータをクライアント１０とウェブサーバ２０との間の安全な接続を介してウェブサーバ２０を通ってクライアント１０に伝送することである。この技術は、アプリケーションサーバ１５とクライアント１０との間の通信が付加的な「ホップ（ｈｏｐ）」（すなわち、ウェブサーバ２０）を通るという点で、非効率である。本発明は、アプリケーションサーバ１５とクライアント１０との間に直接的に安全な通信リンクを確立するためにチケットメカニズムを使用する。それにより、アプリケーションサーバ１５からウェブサーバ２０にアプリケーションデータの中間の伝送を取り除く。
【００１８】
例えば、クライアント１０上にリモート表示されるためにアプリケーションデスクトップをまたはサーバ要求するクライアントユーザは、ウェブ通信チャネル３０を介してウェブサーバ２０に対する通信リンク３２を確立し、ウェブサーバ２０に対してログインおよびパスワード情報を送る。一実施形態において、クライアントユーザは、ウェブブラウザ４０によって表示されるウェブページ上にリストアップされるウェブサーバ２０からのアプリケーションを要求するためにウェブブラウザ４０を使用する。
【００１９】
さらなる実施形態において、ウェブブラウザ４０は、安全なウェブ通信チャネル３０を確立するためにＳＳＬを使用する。安全なウェブ通信チャネル３０を確立するためにＳＳＬプロトコルを使用するために、クライアント１０上で実行するウェブブラウザ４０またはアプリケーションは、ウェブサーバ２０上の安全なウェブページに接続することを試みる。ウェブサーバ２０は、次いで、クライアント１０に対する安全なウェブサーバ電子署名を伝送することによって、ウェブサーバの身元をクライアント１０にアサートする。認証局（ＣＡ）は、ウェブサーバ２０に対して、安全なウェブサーバ電子署名を発行する。ウェブブラウザ４０は、ウェブブラウザ４０のソフトウェア内に組み込まれている信頼できるＣＡ（すなわち、ＣＡの公開鍵）のリストを有する。クライアント１０は、ウェブブラウザ４０（または、アプリケーション）内に組み込まれたＣＡの公開鍵でウェブサーバの電子署名におけるＣＡの署名を復号化することによりウェブサーバ電子署名を実証する。従って、ＳＳＬを使用して安全な通信チャネルを確立するために、ウェブブラウザ４０またはクライアント１０上で実行されたアプリケーションは、安全なウェブページに接続することを試みる前に、ソフトウェアに組み込まれているＣＡの公開鍵を有する。安全なウェブ通信チャネル３０を確立するためにＳＳＬプロトコルを使用する他に、ウェブブラウザ４０は、他のセキュリティプロトコルを使用して、ウェブ通信チャネル３０を介してウェブサーバ２０に接続する。他のセキュリティプロトコルとは、限定はしないが、例えば、カリフォルニア州のＴｅｒｉｓａ  Ｓｙｓｔｅｍｓ  ｏｆ  Ｌｏｓ  Ａｌｔｏｓによって開発された、Ｓｅｃｕｒｅ  Ｈｙｐｅｒｔｅｘｔ  Ｔｒａｓｆｅｒ  Ｐｒｏｔｃｏｌ（ＳＨＴＴＰ）と、ワシントン州レドモンドのマイクロソフト株式会社によって開発されたＳＳＬを介するＨＴＴＰ（ＨＴＴＰＳ）、Ｐｒｉｖａｔｅ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ  Ｔｅｃｈｎｏｌｏｇｙ（ＰＣＴ）、ＮＹ、パーチャス（Ｐｕｒｃｈａｓｅ）のビザインターナショナル株式会社およびマスターカードインターナショナル株式会社で開発されたＳｅｃｕｒｅ  Ｅｌｅｃｔｒｏｎｉｃ  Ｔｒａｎｓｆｅｒ（ＳＥＴ）、マサチューセッツ州、ベッドフォードのＲＳＡセキュリティで開発されたＳｅｃｕｒｅ‐ＭＩＭＥ（Ｓ／ＭＩＭＥ）およびそれと同様のものである。
【００２０】
いったん通信リンク３２が確立されると、ウェブサーバ２０は、通信セッションのためのチケットを生成する。このチケットは、第１の部分および第２の部分を含む。一実施形態において、セッション識別子（ＩＤ）またはナンスとして参照される第一の部分は、ウェブサーバ２０によって決定される特定の期間内で使用され得る暗号乱数である。第二の部分は、暗号鍵であり以下で、セッション鍵として参照される。ウェブサーバ２０は、ローカルメモリにチケットを格納し、次いでクライアント１０上のウェブブラウザ４０にチケットのコピーを伝送する（矢印３４）。
【００２１】
一実施形態において、チケットは、アプリケーションサーバ１５のネットワークアドレスのような付加的な情報を含む。別の実施形態において、ウェブサーバ２０は、アプリケーションサーバ１５のアドレスをクライアント１０に独立して伝送する。例えば、クライアント１０がウェブサーバ２０に名前でアプリケーションを要求する場合、ウェブサーバ２０は、アプリケーションの名前をネットワークアドレスに変換する。チケットに含まれる付加的な情報の例は、限定はしないが、チケットが有効である時間、クライアント１０に表示される際のアプリケーションのスクリーンサイズ、ウェブ通信チャネル３０および／またはアプリケーション通信チャネル２５の帯域幅限界、ならびに請求情報である。より完全に以下に示すように、ウェブサーバ２０はまた、ユーザのパスワードのようなユーザのログイン情報と、アプリケーションサーバ１５によって今後の検索のためにローカルメモリに格納されるチケットとを結びつける。
【００２２】
ＩＣＡクライアント４１は、ウェブブラウザ４０からチケットを取得し、その後、チケットのセッションＩＤ（すなわち、第一の部分）をアプリケーションサーバ１５に伝送する（矢印４２）。セッションＩＤは、暗号化された形式またはクリアテキスト（ｃｌｅａｒｔｅｘｔ）形式で伝送され得る。アプリケーションサーバ１５は、セッションＩＤが暗号化されている場合、これを復号化し、クライアント１０から受け取ったセッションＩＤに対応するセッション鍵を得るための要求をウェブサーバ２０に伝送する（矢印４４）。ウェブサーバ２０は、セッションＩＤを以下に示すように確認し、サーバコミュニケーションチャネル３５を介して、対応するセッション鍵をアプリケーションサーバ１５に送信する（矢印４８）。
【００２３】
アプリケーションサーバ１５およびクライアント１０（すなわち、ＩＣＡクライアント４１）の両方は、非安全アプリケーション通信チャネル２５を介してのチケットまたはセッション鍵の伝送を必要とすることなしに、セッション鍵のコピーを所有する。以前の非安全なアプリケーション通信チャネル２５を介する通信を暗号化および復号化するためにセッション鍵を使用することによって、クライアント１０およびアプリケーションサーバ２５は、アプリケーション通信チャネル２５を介する安全な通信リンクを確立する（矢印５０）。さらに、ユーザのログイン情報（例えば、パスワード）は、非安全アプリケーション通信チャネル２５を介して、クライアント１０とアプリケーションサーバ１５との間で伝送されない。従って、本発明は、非安全アプリケーション通信チャネル２５を介する通信を傍受する盗聴者に対して、ユーザのパスワードのような細心の注意を払うべき情報を見せないことによって、非安全アプリケーション通信チャネル２５を介する通信リンク５０のセキュリティ（矢印５０）を高める。さらに、アプリケーションサーバ１５およびクライアント１０は、同じセッション鍵で通信するので、アプリケーションサーバ１５およびクライアント１０は、チケットサービス６０によって伝送された秘密を共有する。そのチケットサービス６０は、アプリケーションサーバ１５およびクライアント１０を間接的に信頼し、チケットサービス６０は、それぞれに対して保証する。従って、アプリケーションサーバ１５およびクライアント１０は、相互の認証を実行する。一実施形態において、クライアント１０は、レガシーシステムとの互換性を提供するためにウェブ通信チャネル３０を介してユーザのパスワードをウェブサーバ２０に対して再び伝送する（例えば、クライアント１０にユーザのパスワードを複数回伝送するように要求するウェブサーバ２０上の変更されていないオペレーティングシステムログインシーケンス）。
【００２４】
さらなる詳細において、図２は、クライアント１０とアプリケーションサーバ１５との間のアプリケーション通信チャネル２５を介する安全な通信リンク５０を確立するために、通信システム１００によって果たされた処理の実施形態を示す。ウェブブラウザ４０は、クライアント１０のユーザが見るウェブページ上のソフトウェアアプリケーションまたは、サーバデスクトップに対するウェブリンクをリストアップする（ステップ２００）。クライアントユーザは、ウェブブラウザ４０を用いて、ウェブサーバ２０からのソフトウェアアプリケーションを要求する（ステップ２０５）。一実施形態において、ウェブブラウザ４０は、既に示されたＳＳＬプロトコルを使用して安全なウェブ通信チャネル３０を確立する。この実施形態において、クライアント１０（例えば、ウェブブラウザ４０）は、公開鍵（例えば、Ｘ５０９）電子署名を使用してウェブサーバ２０を信頼する。さらなる実施形態において、クライアント１０はまた、公開鍵電子署名を使用して、ウェブサーバ２０に認証される。
【００２５】
別の実施形態において、ユーザがウェブサーバ２０からアプリケーションを要求するためにウェブブラウザ４０を使用する際、ウェブサーバ２０は、ユーザを認証する。例えば、ウェブサーバ２０は、ユーザのログイン情報を要求する。ユーザのログイン情報は、ウェブブラウザ４０上に表示される要求と共に、ユーザのログインネームおよびパスワードを含む。ユーザは、ウェブブラウザ４０にユーザのログイン情報を提供する（ステップ２１０）。ウェブブラウザ４０は、その後、安全なウェブ通信チャネル３０を介して、ユーザのログインネームおよびパスワードをウェブサーバ２０に伝送する（ステップ２２０）。別の実施形態において、ユーザのログイン情報は、ウェブサーバ２０がウェブサーバ２０上でユーザのアカウントを識別するために受け入れる任意のコードまたは方法である。
【００２６】
ウェブサーバ２０は、ユーザログイン情報をチケットサービス６０に伝送する（ステップ２３０）。チケットサービス６０は、ユーザのログイン情報を確認し（ステップ２４０）、ユーザが要求されたアプリケーションにアクセスするために権利を与えられるかどうかを決定する。アプリケーションに対する宣言された通信セキュリティポリシーに従って、チケットサービス６０は、ユーザによるアプリケーションに対するアクセスを拒絶または認可する。チケットサービス６０がアクセスを拒否する場合、ウェブブラウザ４０は、クライアント１０上にＨＴＭＬエラーまたはエラーウェブページを表示する。チケットサービス６０が要求されたアプリケーションに対するアクセスを認可する際、チケットサービス６０は、セッション中にチケットを生成し（ステップ２４５）、ウェブサーバ２０にチケットを伝送する（ステップ２５０）。
【００２７】
上述したように、チケットは、セッションＩＤおよびセッション鍵を含む。セッションＩＤは、特定の時間内で一度、使用され得、チケットを最初の使用の後にさらなる価値を有さない「ワンタイム使用」チケットにさせる。ウェブサーバ２０は、次いでローカルメモリ内にチケットを格納する（ステップ２５３）。さらなる実施形態において、ウェブサーバ２０は、ステップ２１０においてユーザによって提供されたログイン情報およびセッションを認可するために使用される他のセキュリティ情報（例えば、要求されるアプリケーションネーム）と、アプリケーションサーバ１５によって後に検索するための格納されたチケットとを結びつける。ウェブサーバ２０は続いて、安全なウェブ通信チャネル３０を介してチケットをクライアント１０に伝送する（ステップ２５５）。
【００２８】
ウェブブラウザ４０は、チケットからセッションＩＤを抽出し（ステップ２６０）、アプリケーションサーバ１５にセッションＩＤを与える（ステップ２６５）。アプリケーションサーバ１５は、セッションＩＤがクライアント１０により以前に使用されなかったことを保証するために、セッションＩＤをチェックする。一実施形態において、アプリケーションサーバ１５は、クライアント１０がアプリケーションサーバ１５に伝送する各チケット（すなわち、セッションＩＤ）をモニタする（例えば、ローカルメモリ内に格納する）。別の実施形態において、チケットサービス６０は、セッションＩＤが以前にこのクライアント１０により使用されなかったことを確実にするためにセッションＩＤをチェックする。さらに別の実施形態において、チケットサービスは、チケットサービス６０が各セッションＩＤが一度のみチケットサービス６０に伝送されることを確実にするためにウェブサーバ２０に伝送される各チケットをモニタする。
【００２９】
アプリケーションサーバ１５は、次いで、与えられたセッションＩＤと結びつけられたセッション鍵を決定するためにそのセッションＩＤを使用する。このことを成し遂げるために、アプリケーションサーバ１５は、セッションＩＤをチケットサービス６０に伝送し、セッションＩＤに応答するウェブサーバ２０のチケットサービス６０からのセッション鍵を要求する（ステップ２７０）。チケットサービス６０はローカルメモリにアクセスし、セッションＩＤと結びついたチケット情報を検索するためのインデックスとしてセッションＩＤを使用する。チケットサービス６０は次いで、セッションＩＤと結びついているセッション鍵をアプリケーションサーバ１５に戻す（ステップ２８０）。
【００３０】
アプリケーションサーバ１５とウェブサーバ２０との間の通信の最適化を向上させるために、代わりの実施形態において、ウェブサーバ２０は、ステップ２５３において以前にチケットと結びついていた付加的な情報（例えば、要求されたアプリケーションネーム、ユーザのログイン情報）をアプリケーションサーバ１５に伝送する（ファントムステップ２６６として示す）。アプリケーションサーバ１５は、この付加的な情報から付加的なチケット情報を取り出し（ファントムステップ２６７）、通信セッションを認可する。要求されたアプリケーションのユーザのパスワードおよび／または名前のような、付加的な情報は、非安全アプリケーション通信チャネル２５を介して、クライアント１０によってアプリケーションサーバ１５に伝送されず、それによって、潜在的な攻撃者から情報を保護する。この実施形態において、アプリケーションサーバ１５は、付加的な情報を実証する（ファントムステップ２６８）。この付加的な情報が正当でない場合、アプリケーションサーバ１５は、ユーザによって要求されたアプリケーションに対するアクセスを拒絶する（ファントムステップ２６９）。この付加的な情報が正当な場合、要求されたアプリケーションへのアクセスを認可し、上記のようにチケットサービス６０からセッション鍵を要求する（ステップ２７０）。
【００３１】
別の実施形態において、チケットサービス６０は、セッションＩＤ上で付加的なチェックを行う。例えば、チケットサービス６０は、再生（すなわち、セッションＩＤがチケットサービス６０に以前に伝送したことがないことをチェックすること）および／またはサービス攻撃の拒否（ＤｏＳ）（すなわち、無認可のデータパケットでもってリモートサーバを氾濫させ、最終的に不能にすること）の早い検出のためにセッションＩＤ上でチェックを行う。さらなる実施形態において、ウェブサーバ２０は、アプリケーションサーバ１５が要求する（ステップ２７０）前に、アプリケーションサーバ１５に対するチケットの第一および第二の部分を伝送する。したがって、ステップ２７０において要求を取り除く。この実施形態において、アプリケーションサーバ１５は、そのローカルメモリ内にセッション鍵を格納し、クライアント１０がセッションＩＤをアプリケーションサーバ１５に与えた（ステップ２６５）後、セッション鍵をこのローカルメモリから取り出す。
【００３２】
アプリケーションサーバ１５がセッション鍵を取得した（ステップ２８０）後、アプリケーションサーバ１５は、クライアント１０に対して、通信を暗号化するためにおよび、アプリケーション通信チャネル２５を介して、クライアント１０からの通信を復号化するためにセッション鍵を使用する。同様に、クライアント１０は、クライアント１０がアプリケーションサーバ１５からの通信を復号化するためおよび、アプリケーションサーバ１５への通信を暗号化するために、安全なウェブ通信チャネル３０を介して、伝送されたチケットから取得したセッション鍵を使用する。クライアント１０およびアプリケーションサーバ１５は、アプリケーション通信チャネル２５を介して通信を暗号化および復号化するためにセッション鍵を使用するので、クライアント１０およびアプリケーションサーバ１５は、以前の非安全アプリケーション通信チャネル２５を介する安全な通信リンク５０を確立する（ステップ２９０）。さらに、クライアント１０およびアプリケーションサーバ１５は、非安全アプリケーション通信チャネル２５を介してのチケットの伝送なしにセッション鍵を有するので、クライアント１０およびアプリケーションサーバ１５は、以前の非安全アプリケーション通信チャネル２５を介する通信リンク５０のセキュリティを高める。
【００３３】
一実施形態において、アプリケーション通信チャネル２５は、ＳＳＬプロトコルを使用して安全にされる。この実施形態において、チケットサービス６０は、このチケット内のセッション鍵の代わりにアプリケーションサーバ電子署名を置き換える。クライアント１０は、アプリケーションサーバ１５と通信するために、アプリケーションサーバ電子署名を使用する。アプリケーションサーバ電子署名は、チケットに対する要求に応答して、ウェブ通信チャネル３０を介してクライアントにダウンロードされる。それゆえ、アプリケーションサーバ電子署名は安全なリンク（すなわち、ウェブ通信チャネル３０）を介してクライアント１０にダウンロードされるので、アプリケーションサーバ電子署名は、周知の公開ＣＡによって署名される必要はない。クライアント１０は、前もって、アプリケーションサーバ電子署名またはＣＡ鍵を有してなかったが、認証された安全な接続が、チケット内に含まれるアプリケーションサーバ電子署名を使用して、アプリケーション通信チャネル２５を介して、確立される。
【００３４】
例えば、クライアント１０が別のＳＳＬコンポーネント（例えば、要求されたソフトウェアアプリケーションの別のインスタンスまたはインプリメンテーション）を要求する場合、およびクライアント１０がそのローカルメモリ（例えば、データベース、ローカルディスク、ＲＡＭ、ＲＯＭ）内にＣＡ電子署名を有さない場合、クライアント１０は、アプリケーション通信チャネル２５を介する認証された安全な接続を確立するために、伝送されるチケット内のアプリケーションサーバ電子署名を使用し得る。さらに具体的には、クライアント１０が要求されたＳＳＬコンポーネントと結びつくローカルメモリ内に格納されるＣＡルート電子署名を有さない際（または、クライアント１０が要求されたＳＳＬコンポーネントに対するＣＡ電子署名を含まないＣＡ電子署名の不完全なリストをを有する際）および、クライアント１０は、ウェブブラウザ４０のＣＡデータベースにアクセスし得ない際クライアント１０は、伝送されるチケット内のアプリケーションサーバ電子署名を使用する。さらに、署名されたＣＡ電子署名は、ウェブサーバ２０に対しては必要であるが、アプリケーションサーバ１５（すなわち、サーバファームの要素であるそれぞれのアプリケーションサーバ１５）に対しては必要でないので、安全な通信に対する署名されたＣＡ電子署名の必要とされる数を取得する費用（および、オーバヘッド）は引き下げられる。別の実施形態において、アプリケーションサーバ１５は、対応する公開鍵で暗号化されるメッセージの復号化のための秘密鍵を格納する。チケットサービス６０は、結果としてアプリケーションサーバ１５に対応する公開鍵を、通信を暗号化するためにクライアント１０に伝送する。
【００３５】
この実施形態において、クライアント１０が要求のアプリケーションへのアクセスを得ることができ、かつチケットサービス６０（または、ウェブサーバ２０）がチケット（すなわち、セッションＩＤ）をモニタするので、一回のアクセスを得ることを確実にすることにおいて、セッションＩＤは、さらに付加的な価値を供給する。さらに、アプリケーションサーバ１５およびクライアント１０が、アプリケーション通信チャネル２５を介する通信を暗号化または復号化するために異なるセッション鍵を使用する場合、セッションＩＤおよび暗号のチェックサムが、アプリケーションサーバ１５（すなわち、完全なチェック）によって予想されるチェックサムと合わないので、盗聴者は、クライアント１０によってアプリケーションサーバ１５に伝送されたセッションＩＤを変更し得ない。それゆえ、クライアント１０およびアプリケーションサーバ１５は、異なるセッション鍵が、アプリケーション通信チャネル２５を介して暗号化および復号化するためにアプリケーションサーバ１５およびクライアント１０によって何時使用される（例えば、「争いの仲裁者」攻撃）かを、決定する。
【００３６】
さらなる実施形態において、セッション鍵は、実質的に、ヌル価値（ｎｕｌｌ  ｖａｌｕｅ）（すなわち、このチケットは、ナンスのみまたは、セッション鍵に対するナンスおよび一定の価値を含む。）に等しい。セッション鍵が実質的にヌル価値に等しい際、クライアント１０は、非安全アプリケーション通信チャネル２５を介するクライアント１０とアプリケーションサーバ１５との間のユーザのログイン情報（例えば、パスワード）を伝送しない。それゆえ、チケットが一回使用に対して有効であるのみでかつ、以前に認可されたリソース（例えば、ＩＣＡクライアント４１）に対するアクセスを認可するのみであるので、パスワードの外部露出が避けられ得、個々のセッションレベルのアクセス制御は、ヌルまたは固定されたセッション鍵の価値ではあるが、なされ得る。
【００３７】
さらに、要求されたアプリケーションがリモートに表示されるために、ウェブブラウザ４０またはクライアント１０に、前もって設定される情報はないので（すなわち、クライアント１０にはサーバ電子署名または、ＣＡ電子署名が存在される必要はないので）、本方法は、ウェブを介するデスクトップアプリケーションへの安全なアクセスに対する「ゼロインストール（ｚｅｒｏ‐ｉｎｓｔａｌｌ）」ソリューションである。さらに、ウェブブラウザ４０は、通信チャネル３０を介してウェブサーバ２０からチケットまたは、ＩＣＡクライアントを受け取る。この実施形態において、ウェブサーバ２０は、チケットおよび、上述のようなＭＩＮＥタイプドキュメントを伝送し、ＩＣＡクライアント４１（ヘルパーアプリケーションとして）に対する「ドキュメント」を含むことを特定する。ＭＩＮＥタイプドキュメントは、ＩＣＡクライアント４１を呼び出し、ウェブブラウザ４０は、ＩＣＡクライアントにチケットを伝送し、従って、クライアント１０上に、前もってインストールされた、ＩＣＡクライアント４１を有することなしに、アプリケーション通信チャネル２５を安全にするために通信チャネル３０のセキュリティの利用を可能にする。本発明の特定の実施形態を示したように、本発明の概念を援用した他の実施形態が使用され得ることは、当業者に理解される。それゆえ、本発明は、特定の実施形態に限定すべきではないが、むしろ、上掲請求範囲の意図および範囲によってのみ制限されるべきではない。
【図面の簡単な説明】
【図１】
図１は、本発明の原理に従って、クライアントとアプリケーションサーバとの安全な通信を確立するための通信システムの実施形態のブロック図である。
【図２】
図２は、クライアントとアプリケーションサーバとの間の安全な通信を確立するために図１に示された通信システムによって実行される通信の実施形態のフローチャートである。
【図１】
2004531914.tif 000003
【図２】
2004531914.tif 000004
【国際公開パンフレット】
2004531914.tif 000005
2004531914.tif 000006
2004531914.tif 000007
2004531914.tif 000008
2004531914.tif 000009
2004531914.tif 000010
2004531914.tif 000011
2004531914.tif 000012
2004531914.tif 000013
2004531914.tif 000014
2004531914.tif 000015
2004531914.tif 000016
2004531914.tif 000017
2004531914.tif 000018
2004531914.tif 000019
2004531914.tif 000020
2004531914.tif 000021
2004531914.tif 000022
2004531914.tif 000023
2004531914.tif 000024
2004531914.tif 000025
2004531914.tif 000026
2004531914.tif 000027
2004531914.tif 000028
2004531914.tif 000029
2004531914.tif 000030
【国際公開パンフレット（コレクトバージョン）】
2004531914.tif 000031
【国際調査報告】
2004531914.tif 000032
2004531914.tif 000033
2004531914.tif 000034