JP2007323115A - ローカル・プロキシにより通信情報を共有する方法 - Google Patents

Abstract

【課題】端末で動作するブラウザと同じプロセスで動作するローカル・プロキシを使用した通信情報を共有する方法を提供する。
【解決手段】端末２０で動作するローカル・プロキシ２２２が、端末２０で動作するアプリケーションとサーバ１０との間の通信を代理するものとして、端末２０で動作するブラウザ２２１と同じプロセス２２０で動作するステップと、アプリケーション２３１が、ローカル・プロキシ２２２とは異なるプロセス２３０で動作するステップと、ローカル・プロキシ２２２が、アプリケーション２３１が送信したデータを受信し、データをブラウザ２２１を経由してサーバ１０に送信するステップと、ローカル・プロキシ２２２が、サーバ１０からの処理済データをブラウザ２２１を経由して受信し、処理済データをアプリケーション２３１に送信するステップと、を含む方法。
【選択図】図２

Description

本発明は、ネットワーク・アプリケーションが動作するクライアント・サーバ・システムにおけるクライアント端末（以下、端末ともいう）で動作するブラウザと同じプロセスで動作するローカル・プロキシを使用した通信情報を共有する方法、当該システム、およびプログラムに関する。

従来、インターネットを介してＷｅｂサーバにアクセスするユーザ端末と、Ｗｅｂサーバとの間に、Ｗｅｂサイトにおけるユーザ認証を代行するユーザ認証プロキシを配置したシングルサインオン・システムが開示されている（例えば、特許文献１）。このシステムは、ユーザ端末の種類を問わず、ユーザがＵＲＬで指定したＷｅｂサイトに対するユーザ認証を、ユーザ認証プロキシに代行させるようにしたものである。
特開２００２−３２３４０号公報

一方、ローカル・プロキシという、自端末内でプロキシ機能を持ったソフトウェアが存在する。ローカル・プロキシは、現状においては、以下のような使い方をしている。つまり、ブラウザから当該ローカル・プロキシにデータの要求を送信すると、ローカル・プロキシがブラウザの代わりにＷｅｂサーバに対してデータの要求を行う。また、当該Ｗｅｂサーバから送信されたデータを当該ローカル・プロキシが受信し、ブラウザに当該データを送信する。このような使い方により、Ｗｅｂサーバから送信されてくるデータをユーザの好みに変更してブラウザに送信することができる。例えば、広告除去、ＪａｖａＳｃｒｉｐｔ（登録商標）無効、オートリロード無効などを実現することができる。

ところで、ビジネス・アプリケーションをＷｅｂシステムとして開発する場合、企業内では認証情報の統合を行っている場合が多く存在する。当該Ｗｅｂシステムでは、端末の処理としてブラウザの利用が前提となっている。Ｗｅｂシステムは、サーバ・サイドでのロジック処理が基本であり、ブラウザは、基本的な処理としてＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）によりＷＷＷ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ）サーバからの処理結果を受け取り表示する。ブラウザとＨＴＴＰによる通信を前提とすることで、複数のアプリケーションを跨る全社的な統合認証の実装が可能となる。より具体的には、ブラウザと認証サーバとの間で、Ｃｏｏｋｉｅ等のブラウザが処理可能な形式で認証情報を付加することにより、各アプリケーションの通信にブラウザが自動的に認証情報を付加することが可能である。そのため、各アプリケーションは認証に関して特別な配慮を行う必要が無くなる。

しかしながら、ブラウザを使う場合には、ユーザ・インターフェイスとしての入力処理における表現が乏しく、ファンクション・キーやリターン・キーの割り当てが難しいなど、操作性においてクライアント・サーバ・システムのような複雑な操作ができない等の問題点がある。このような理由から、ブラウザによる実装が適さない業務分野も存在する。

一方で、リッチ・クライアントと呼ばれる技術が使用されることも多くなっている。リッチ・クライアントとは、例えば、Ｗｅｂブラウザのプラグインなど、他の技術を用いることによりユーザ・インターフェイスの表現力や操作性を向上し、「リッチ」なクライアントを実現するものをいう。リッチ・クライアントは、独自の実行環境を提供し、各技術固有のアプリケーションで動作する。このため、ブラウザによる実装が適さない業務分野では、リッチ・クライアント技術により対応しようとする流れが存在する。

このリッチ・クライアント技術は、ブラウザに組み込まれる形式のものが多く、ブラウザを使用して実行することが可能であるが、これは、ブラウザのプロセス空間内で実行されることを意味する。この形態の場合、ブラウザの持つ通信情報の共有が可能であり、統合認証の利用も可能である。

しかしながら、ブラウザという単一プロセス内で、リッチ・クライアントの実行環境の複数のバージョンを並列で動作可能にすることは困難である。業務アプリケーションにおいては、開発が終了したアプリケーションを、開発当時の実行環境のバージョンで使用し続けることを顧客が望むことが多く存在する。しかし、同じリッチ・クライアント技術を使用し、異なる時期に開発されたアプリケーションが存在する場合、現状であれば、いずれかのバージョンに統一しないとブラウザという単一プロセス内で動かすことができない。

別の方法として、アプリケーションをブラウザという単一のプロセスに組み込ませるのではなく、アプリケーションごとに異なるプロセス空間を用意すれば、複数バージョンのアプリケーションを動かすことができる。しかし、この場合、起動したアプリケーションでは、ブラウザと、認証などに使用する情報（Ｃｏｏｋｉｅ等）と、を共用することができない。そのため、起動したアプリケーションで、再度ユーザ認証を求められる事態が発生する。よって、この場合には、特許文献１に記載されているような方法を用いても、一度認証を得ると、その権限内でアプリケーションを利用可能であるという共通認証のメリットを得ることができなくなる。その結果として、共通認証を当然の前提と考える顧客にとって、この提案は受け入れられず、ビジネスチャンスを逃すことになりかねない。それでも共通認証を実現しようとする場合には、アプリケーションとしての認証の開発が必要になり、本来不必要な使い勝手を悪くする開発にコストをかけることにもなる。

ブラウザから、何らかの手段でリッチ・クライアントの起動時に認証情報を引き継ぐことを可能とする実装を検討することも考えられるが、この場合、認証情報の引継ぎは、汎用的な方式ではなく非常に特殊な方式になってしまうため、実装へのコストがかかるという問題がある。それに加えて、例えば、起動後に一定時間で認証情報を更新するシステムなどへの対応ができなくなる。

そこで、本発明者は、ブラウザで動作するローカル・プロキシに着目し、他のアプリケーションの通信を中継するローカル・プロキシを実装することを考えた。このことにより、端末内の別プロセスで実行するアプリケーションの通信をブラウザに集約し、サーバとの通信を１つの通信経路とすることを目的とする。

本発明の第１の形態によると、ネットワーク・アプリケーションが動作するクライアント・サーバ・システムにおける通信情報を共有する方法を提供する。当該方法は、クライアント端末で動作するローカル・プロキシが、クライアント端末で動作するアプリケーションとサーバとの間の通信を代理するものとして、クライアント端末で動作するブラウザと同じプロセスで動作するステップと、アプリケーションが、ローカル・プロキシとは異なるプロセスで動作するステップと、ローカル・プロキシが、アプリケーションが送信したデータを受信し、データをブラウザを経由してサーバに送信するステップと、ローカル・プロキシが、サーバからの処理済データを、ブラウザを経由して受信し、処理済データをアプリケーションに送信するステップと、を含むことを特徴としている。

ここで、ローカル・プロキシは、ブラウザと同一のプロセスで動作しながら各プロセスのＴＣＰ／ＩＰソケット通信ができる実装方法で実現されればよい。例えば、ＨＴＴＰにより通信を行うことができる。また、ローカル・プロキシの実装としては、ＡｃｔｉｖｅＸ（登録商標）や、Ｊａｖａ（登録商標） Ｒｕｎｔｉｍｅ Ｅｎｖｉｒｏｎｍｅｎｔ（以下、Ｊａｖａ Ｒｕｎｔｉｍｅ Ｅｎｖ．と呼ぶ）等の実行環境を用いて実現してもよいし、独自に実現してもよい。

また、プロセスとは、ＯＳからメモリ領域などの割り当てを受けて処理を実行しているプログラムのことをいう。

本発明の第２の形態によると、ネットワーク・アプリケーションが動作するクライアント・サーバ・システムにおける通信情報を共有するシステムを提供する。当該システムでは、クライアント端末で動作するブラウザと、クライアント端末で動作するローカル・プロキシであって、クライアント端末で動作するアプリケーションとサーバとの間の通信を代理するものとして、クライアント端末で動作するブラウザと同じプロセスで動作する、ローカル・プロキシと、を備え、アプリケーションは、ローカル・プロキシとは異なるプロセスで動作し、ローカル・プロキシは、アプリケーションが送信したデータを受信するデータ受信部と、データをサーバに送信するデータ送信部と、サーバからの処理済データを受信する処理済データ受信部と、処理済データをアプリケーションに送信する処理済データ送信部と、を備えることを特徴とする。

本発明の第３の形態によると、ネットワーク・アプリケーションが動作するクライアント・サーバ・システムにおける通信情報を共有するコンピュータに実行させるコンピュータ・プログラムを提供する。当該コンピュータ・プログラムは、クライアント端末で動作するローカル・プロキシに、クライアント端末で動作するアプリケーションとサーバとの間の通信を代理するものとして、クライアント端末で動作するブラウザと同じプロセスで動作するステップと、アプリケーションが送信したデータを受信し、データをサーバに送信するステップと、サーバからの処理済データを受信し、処理済データをアプリケーションに送信するステップと、を実行させ、アプリケーションに、ローカル・プロキシとは異なるプロセスで動作するステップを実行させる。

さらに別プロセスのアプリケーションがサーバと通信する際にも同様に、当該ローカル・プロキシに対しデータを送信することで、同様の作用効果を実現できる。

本発明によれば、別プロセスのアプリケーションの通信を中継するローカル・プロキシを実装することにより、端末内での通信をブラウザに集約し、サーバとの通信を１つの通信経路とすることが可能となる。そのため、複数のアプリケーションにおいてブラウザを用いた認証情報を共有することができ、結果として、シングルサインオンの実現と、リッチ・クライアントによる操作性の向上の両方の機能を享受し得る。

さらに、本発明によれば、汎用的な使用が可能なブラウザと同一のプロセスで動作するローカル・プロキシを提供することにより、様々なプラグイン・ソフトウェアや技術を用いたシステムにおいて当該方法を使用することができ、さらに、ローカル・プロキシによる通信を同一端末内での通信に限定することで、セキュリティを確保することができる。

さらに、本発明によれば、既存のアプリケーションで、サーバとの接続時に再認証を行っているアプリケーションであっても、ブラウザと同一のプロセスで動作するローカル・プロキシが中継するリクエストの発生源を、ローカル・ホストに限定することで望みのバージョンの実行環境に移行可能である。このため、この方式に集約する為に必要な変更点を非常に小さく抑えることができ、容易に望みのバージョンの実行環境に移行することができる可能性がある。

以下、本発明に係る好適な実施形態の一例について、図面に基づいて以下に説明する。図１は、従来の認証方法の一例である。図２は、本発明における認証方法の一例である。図３は、本発明での端末の機能ブロック図である。図４は、端末のハードウェア構成を示すものである。図５は、端末での処理フローの一例である。図６から図８は、本発明を使用した実装例である。図９は、本発明の実施形態におけるネットワーク・アプリケーションが動作するクライアント・サーバ・システムである。

図１は、従来の認証方法の一例を示したものである。図１の（ａ）は、端末２０内のブラウザと認証サーバ４０との間でＣｏｏｋｉｅによる認証情報を付加することにより、アプリケーション・サーバであるサーバ１０との通信を行うものである。このように、ブラウザの利用により、ブラウザがサーバ１０との通信に自動的にＣｏｏｋｉｅによる認証情報を付加することで、ブラウザ・ベースのアプリケーション・システムでは、シングルサインオン・システムが実現できる。

一方、図１の（ｂ）は、複数バージョンのアプリケーションを端末２０で使用する場合の認証方法の一例を示したものである。ブラウザからの操作によってアプリケーションを起動すると、アプリケーション・サーバであるサーバ１０に記憶されているアプリケーションを、ブラウザと同一のプロセス内でブラウザのプラグインを使用して端末２０にロードし、当該クライアントで起動する。このような技術を用いることにより、インターフェイスの表現力や操作性を向上する技術を用いた、「リッチ」なクライアントを実現することができる。そして、端末２０とサーバ１０との間の通信は、端末２０内のブラウザを介して認証サーバ４０により認証されている（図１の（ｂ）（ｉ）参照）。

しかし、端末２０内のブラウザと同一プロセス内でバージョンの異なるアプリケーションを同時に使用することは、互換性の問題があり難しい（図１の（ｂ）（ｉｉ）参照）。また、端末２０内のブラウザとは別プロセスでアプリケーションを起動すると、端末２０内のブラウザを介して認証サーバ４０により認証されている認証情報を使用することができず、端末２０内の当該アプリケーションとサーバ１０との通信では、再認証をする必要が生じる（図１の（ｂ）（ｉｉｉ）参照）。

図２は、上記図１の（ｂ）における問題点を解決した本発明における認証方法の一例を示したものである。端末２０内のブラウザ２２１を含むプロセス２２０内に実行環境２２３を用いてローカル・プロキシ２２２を実装する。プロセス２２０とは別プロセスであるプロセス２３０で起動するアプリケーション２３１には、送信先としてローカル・プロキシ２２２をあらかじめ指定しておく。アプリケーション２３１を起動すると、アプリケーション２３１は、データの送信をローカル・プロキシ２２２に対して行う。ローカル・プロキシ２２２は、ブラウザ２２１を介してサーバ１０と通信を行う。そして、ローカル・プロキシ２２２は、サーバ１０からの送信済データをブラウザ２２１を介して受信し、アプリケーション２３１に送信する。その結果、端末２０とサーバ１０との通信は、アプリケーション２３１を使用した場合であってもブラウザ２２１を経由して通信をすることができ、認証サーバ４０により既に認証されている認証情報を使用することができる。したがって、端末２０がサーバ１０と通信する際には、アプリケーション２３１は、データの送信先を、ブラウザ２２１と同一のプロセス２２０内にあるローカル・プロキシ２２２とすることで、端末２０とサーバ１０との間の認証情報を共有することができる。

ここで、ローカル・プロキシ２２２の実装は、サーバ１０からローカル・プロキシ２２２をダウンロードすることにより実現できる。この方法を用いれば、ブラウザ２２１を含むプロセス２２０内の実行環境２２３がバージョン・アップ等により変わる場合であっても、ユーザの面倒な操作を行うことなくその都度サーバ１０から提供されるため、比較的配布・実行が容易な形でローカル・プロキシ２２２を実装することができる。

なお、別プロセス２３０でアプリケーション２３１を起動する方法としては、既存の技術として確立されており、例えば、「Ｂｏｏｔｓｔｒａｐ Ａｐｐｌｅｔ」のような技術が存在する。ここで、「Ｂｏｏｔｓｔｒａｐ Ａｐｐｌｅｔ」とは、インターネット上で簡単に配布できるアプレットをブートストラップとして使用し、そのブラウザが動作しているＯＳ上で直接稼動するアプリケーションを起動するものである。具体的には、クライアント端末でのアプリケーション起動要求に対し、サーバからロードされた実行環境を確認する実行環境確認アプレットを実行し、その結果に基づきさらにサーバからアプリケーションとともにロードされた起動コマンドを、クライアント端末で実行することにより実現できる。

図３は、本発明における端末２０の機能ブロック図を示す。端末２０には、ブラウザ２２１とローカル・プロキシ２２２を含むプロセス２２０と、それとは別プロセスでアプリケーション２３１を含むプロセス２３０とを有している。なお、ブラウザ２２１とサーバ１０（図示せず）との間の認証は既に成立しているものとして説明する。

アプリケーション２３１は、サーバ１０との通信の際にローカル・プロキシ２２２にデータ９１を送信する。

ローカル・プロキシ２２２のデータ受信部８１はデータ９１を受信し、データ送信部８２にデータ９１を引き渡す。

データ送信部８２は、データ受信部８１からデータ９１を引き受け、ブラウザ２２１に対しデータ９１を送信する。

ブラウザ２２１は、通常の通信に基づいてデータ９１と、サーバ１０との認証情報９２とを、通信回線３０を介してサーバ１０に送信する。

一方、サーバ１０から処理済データ９３が認証情報９２とともに通信回線３０を介してブラウザ２２１に送信されると、ブラウザ２２１は、ローカル・プロキシ２２２に処理済データ９３を送信する。

ローカル・プロキシ２２２の処理済データ受信部８３は処理済データ９３を受信し、処理済データ送信部８４に処理済データ９３を引き渡す。

処理済データ送信部８４は、処理済データ受信部８３から処理済データ９３を引き受け、アプリケーション２３１に対し処理済データ９３を送信する。

以上、ローカル・プロキシ２２２の各機能を用いることにより、ブラウザ２２１を含むプロセス２２０とは異なるプロセス２３０内のアプリケーション２３１であっても、ブラウザ２２１の通信機能を用いて、サーバ１０との通信を行うことが可能となる。

図４は、端末２０のハードウェア構成の一例を示す。端末２０は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）２０１０、バス２００５、通信Ｉ／Ｆ２０４０、メインメモリ２０５０、ＢＩＯＳ（Ｂａｓｉｃ Ｉｎｐｕｔ Ｏｕｔｐｕｔ Ｓｙｓｔｅｍ）２０６０、パラレルポート２０８０、ＵＳＢポート２０９０、グラフィック・コントローラ２０２０、音声プロセッサ２０３０、Ｉ／Ｏコントローラ２０７０、ならびにキーボードおよびマウス・アダプタ等２１００を備える。Ｉ／Ｏコントローラ２０７０には、ＦＤ（フレキシブル・ディスク）ドライブ２０７２、ハード・ディスク２０７４、光ディスクドライブ２０７６、半導体メモリ２０７８、等の記憶手段を接続することができる。

音声プロセッサ２０３０には、増幅回路２０３２およびスピーカ２０３４が接続される。また、グラフィック・コントローラ２０２０には、ＶＲＡＭ２０２４および表示装置２０２２が接続されている。

ＢＩＯＳ２０６０は、端末２０の起動時にＣＰＵ２０１０が実行するブートプログラムや、端末２０のハードウェアに依存するプログラム等を格納する。ＦＤドライブ２０７２は、フレキシブル・ディスク２０７１からデータを読み取り、Ｉ／Ｏコントローラ２０７０を介してハード・ディスク２０７４に提供する。

光ディスクドライブ２０７６としては、例えば、ＤＶＤ−ＲＯＭドライブ、ＣＤ−ＲＯＭドライブ、ＤＶＤ−ＲＡＭドライブ、ＣＤ−ＲＡＭドライブを使用することができる。この際には、各ドライブに対応した光ディスク２０７７を使用する必要がある。光ディスク２０７７から光ディスクドライブ２０７６によりプログラムまたはデータを読み取り、Ｉ／Ｏコントローラ２０７０を介してメインメモリ２０５０またはハード・ディスク２０７４に提供することもできる。

端末２０に提供されるコンピュータ・プログラムは、光ディスク２０７７、またはメモリーカード（図示せず）等の記録媒体に格納されて利用者によって提供される。その場合、コンピュータ・プログラムは、Ｉ／Ｏコントローラ２０７０を介して、記録媒体から読み出されることによって、端末２０にインストールされ実行される。その他、通信Ｉ／Ｆ２０４０を介してダウンロードされることによって、端末２０にインストールされ実行される。

上記の端末２０のハードウェア構成は一例にすぎず、上述の構成要素が必須であるとは限らない。

図５は、端末２０での処理を示すフローチャートであり、ローカル・プロキシ２２２を使用する場合の起動・終了処理の一例を示すものである。

まず、ステップＳ１０では、端末２０でブラウザ２２１を立上げ、ブラウザ２２１からサーバ１０の情報資源のあるＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）を指定することで、端末２０のＣＰＵ２０１０は、サーバ１０へ接続要求を送信する。サーバ１０は、端末２０が接続を許可する端末であることを確認するため、認証サーバ４０に処理を移し、認証サーバ４０により認証処理が行われる。認証サーバ４０により正しく認証されたことに応じて、サーバ１０と端末２０との間の通信が確立する（ステップＳ１０）。

ユーザが、例えば、ブラウザ２２１上のページのボタンをクリックすることでアプリケーション２３１の起動を要求すると、端末２０のＣＰＵ２０１０は、アプリケーション２３１の起動要求を受け付ける（ステップＳ１１）。その後、ＣＰＵ２０１０は、処理をステップＳ１２に移す。

ステップＳ１２に移行すると、ＣＰＵ２０１０は、ローカル・プロキシ２２２が起動済か否かを判定する（ステップＳ１２）。当該判定処理は、アプリケーション２３１起動時に使用する技術によって実装されるものであり、例えばＨＴＭＬの場合はＪａｖａＳｃｒｉｐｔ（登録商標）を使用することにより判定処理を実装することができる。

ステップＳ１２では、ローカル・プロキシ２２２が未起動であった場合（ステップＳ１２でＮＯが選択された場合）は、ＣＰＵ２０１０は、ローカル・プロキシ２２２を起動するため、処理をステップＳ１３に移す。また、ステップＳ１２で、ローカル・プロキシ２２２が起動済であった場合（ステップＳ１２でＹＥＳが選択された場合）は、ＣＰＵ２０１０は、処理をステップＳ１４へ移す。

ステップＳ１３に移行すると、ＣＰＵ２０１０は、ローカル・プロキシ２２２を起動する（ステップＳ１３）。具体的には、ローカル・プロキシ２２２が端末２０のハード・ディスク２０７４にあるか否かを確認する。ハード・ディスク２０７４にない場合や、若しくは当該ローカル・プロキシ２２２のバージョンが古い場合には、ＣＰＵ２０１０は、サーバ１０に対してローカル・プロキシ２２２のダウンロードを要求し、通信Ｉ／Ｆ２０４０を介してダウンロードされたローカル・プロキシ２２２を、ハード・ディスク２０７４に格納すると同時に、メインメモリ２０５０に展開する。ＣＰＵ２０１０は、当該メインメモリ２０５０に展開されたローカル・プロキシ２２２を起動する。ハード・ディスク２０７４に該当のローカル・プロキシ２２２が格納されている場合には、ＣＰＵ２０１０は、当該ローカル・プロキシ２２２をメインメモリ２０５０に展開し、当該メインメモリ２０５０に展開されたローカル・プロキシ２２２を起動する。その後、ＣＰＵ２０１０は、処理をステップＳ１４に移す。

ステップＳ１４に移行すると、ＣＰＵ２０１０は、アプリケーション２３１をブラウザ２２１とは別プロセス２３０で起動する（ステップＳ１４）。その後、ＣＰＵ２０１０は、処理をステップＳ１５に移す。

ステップＳ１５に移行すると、アプリケーション２３１は、ローカル・プロキシ２２２を使用して、サーバ１０との通信を行う（ステップＳ１５）。具体的には、上述の図４のとおりである。これらの一連の処理により、ブラウザ２２１とは別プロセス内のアプリケーション２３１が、ブラウザ２２１の認証機能を利用してサーバ１０と通信することを可能としている。

ユーザが、アプリケーション２３１を終了する際には（ステップＳ１６でＹＥＳが選択された場合）、ＣＰＵ２０１０は、ローカル・プロキシ２２２を使用している最後のプロセスか否かを判定する（ステップＳ１７）。他のアプリケーションがローカル・プロキシ２２２を使用している場合（ステップＳ１７でＮＯが選択された場合）には、ＣＰＵ２０１０は、処理をステップＳ１５に移す。他方、他のアプリケーションが存在しない場合（ステップＳ１７でＹＥＳが選択された場合）には、ＣＰＵ２０１０は、ステップＳ１８に移行する。

ステップＳ１８に移行すると、ＣＰＵ２０１０は、ブラウザ２２１を閉じると同時に、ローカル・プロキシ２２２を終了する（ステップＳ１８）。

なお、実装例としては、以下のような例が挙げられる。
図６は、ブラウザ２２１のプロセス２２０で起動するローカル・プロキシ２２２をＪａｖａ（登録商標）により実装した場合についての本発明を使用した概念図である。端末２０には、ブラウザ２２１およびローカル・プロキシ２２２の動作するプロセス２２０とは別プロセスである、プロセス２３０が存在している。ローカル・プロキシ２２２は、実行環境２２３のＪａｖａ Ｒｕｎｔｉｍｅ Ｅｎｖ． −Ｖｅｒｓｉｏｎ１．３．１を用いて実装する。プロセス２３０では、実行環境２２３とは別のバージョンの実行環境２３３を用いたアプリケーション２３１（図示せず）の動作が可能である。

この場合、別プロセスであるプロセス２３０で起動するアプリケーション２３１は、ローカル・プロキシ２２２と通信できる技術であれば、どのような実装であっても構わない。他の技術を用いてローカル・プロキシ２２２を実装した場合も同様である。また、ブラウザ２２１の動作するプロセス２２０と、プロセス２２０と別プロセスであるプロセス２３０とは、同一のバージョンの実行環境を有する場合であってもよいのは勿論である。

図７は、ブラウザ２２１のプロセス２２０で起動するローカル・プロキシ２２２がマイクロソフトのツールであるＡｃｔｉｖｅＸ（登録商標）により実装した場合についての概念図である。

さらに、図８は、ブラウザ２２１のプロセス２２０で起動するローカル・プロキシ２２２がブラウザ２２１のプラグインを開発するツールを使用して実装した場合についての概念図である。

図９は、本発明の実施の一例に係るクライアント・サーバ・システムの概略図である。図９において、サーバ１０はアプリケーション・サーバであり、通信回線３０に接続するための接続部１１とプログラムを格納する記憶部１２とを備えている。また、記憶部１２にＷｅｂファイル１３を記憶している。Ｗｅｂファイル１３には、ＷＷＷに対応したコンテンツやアプリケーション・ファイルが記憶されている。サーバ１０と端末２０とにおける認証は、通信回線３０を介して接続された認証サーバ４０によって認証機能を有してもよいし、サーバ１０に認証部（図示せず）を設けて認証機能を有してもよい。

端末２０は、例えば、サーバ１０からＷｅｂファイル１３内の情報をダウンロードし、ブラウザを用いてその内容を表示することができる。

通信回線３０は、インターネットやイントラネット等のネットワークであり、サーバ１０と端末２０とを接続している。通信回線３０は、広域ネットワークＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）であってもよいし、構内ネットワークＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）であってもよい。

また、サーバ１０に登録されたＷｅｂファイル１３内の情報は、ブラウザによりＷｅｂページとして表示されるページデータと、アプリケーション等により構成される。ページデータは、例えばＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ Ｍａｋｅｕｐ Ｌａｎｇｕａｇｅ）で記述される。アプリケーションは、具体的には、ＪＳＰ（ＪａｖａＳｅｒｖｅｒ（登録商標） Ｐａｇｅｓ）、Ｊａｖａ（登録商標）サーブレット、ＡＳＰ（Ａｃｔｉｖｅ Ｓｅｒｖｅｒ Ｐａｇｅｓ）などのサーバ・サイドのプログラムや、Ｊａｖａ（登録商標）アプレット、ＡｃｔｉｖｅＸ（登録商標）コントロール、ブラウザのプラグインが含まれる。

以上、実施例について説明したが、ローカル・プロキシによる通信では、ローカル・プロキシがソケットによる通信において接続先が自端末からのもののみを許容することにより、同一端末内でのアプリケーションからの通信のみとすることができ、セキュリティを確保することが可能となる。

さらに、既存のシステムのアプリケーションを本発明を用いたシステムへ移行する場合は、ローカル・プロキシをブラウザと同一のプロセス内で起動し、既存アプリケーションの通信の送信先を当該ローカル・プロキシに変更することにより、実装が可能となる。

以上は、クライアントのブラウザで動作するローカル・プロキシを使用した通信情報を共有する方法およびシステムついて主に説明したが、コンピュータに、アプリケーションの通信情報の共有方法で説明した機能を有するプログラムをインストールして、そのコンピュータを動作させることにより上記で説明したアプリケーションの通信情報の共有方法と同様な機能を実現することができる。したがって、本発明において１つの実施形態として説明したアプリケーションの通信情報の共有方法は、コンピュータ・プログラムによっても実現可能である。もちろん、本発明は、そのようなプログラム自体のみならず、プログラムを記録した媒体を含むプログラム製品もその範囲に含むものである。本発明の機能を実行するためのプログラムは、フレキシブル・ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＤＶＤ、ハード・ディスク装置、ＲＯＭ、ＭＲＡＭ、ＲＡＭ等の任意のコンピュータ可読媒体に格納することができる。かかるプログラムは、コンピュータ可読媒体への格納のために、通信回線で接続する他のコンピュータ・システムからダウンロードしたり、他の媒体から複製したりすることができる。また、かかるプログラムは、圧縮し、または複数に分割して、単一または複数の記録媒体に格納することもできる。

以上、本発明を実施形態、および実施例を用いて説明したが、本発明の技術的範囲は上記実施形態に記載の範囲に限定されない。上記実施形態に、多様な変更または改良を加えることが可能である。また、そのような変更または改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。

従来の認証方法を示す図である。 本発明を使用した認証方法を示す図である。 端末の機能ブロック図である。 端末のハードウェア構成を示す図である。 端末の処理を示すフローチャートである。 本発明を使用した実装例の図である。 本発明を使用した実装例の図である。 本発明を使用した実装例の図である。 本発明のクライアント・サーバ・システムを示す図である。

符号の説明

１０ サーバ、アプリケーション・サーバ
２０ 端末
３０ 通信回線
４０ 認証サーバ
８１ データ受信部
８２ データ送信部
８３ 処理済データ受信部
８４ 処理済データ送信部
９１ データ
９２ 認証情報
９３ 処理済データ
２２０ プロセス
２２１ ブラウザ
２２２ ローカル・プロキシ
２３０ プロセス
２３１ アプリケーション

Claims (8)

1. ネットワーク・アプリケーションが動作するクライアント・サーバ・システムにおける通信情報を共有する方法であって、
   クライアント端末で動作するローカル・プロキシが、前記クライアント端末で動作するアプリケーションとサーバとの間の通信を代理するものとして、前記クライアント端末で動作するブラウザと同じプロセスで動作するステップと、
   前記アプリケーションが、前記ローカル・プロキシとは異なるプロセスで動作するステップと、
   前記ローカル・プロキシが、前記アプリケーションが送信したデータを受信し、当該データを、前記ブラウザを経由してサーバに送信するステップと、
   前記ローカル・プロキシが、前記サーバからの処理済データを、前記ブラウザを経由して受信し、当該処理済データを前記アプリケーションに送信するステップと、
   を含む方法。
2. 前記アプリケーションを起動する要求をユーザから受け付けたことに応じて、前記ローカル・プロキシが起動するステップを更に含む、請求項１に記載の方法。
3. 前記アプリケーションを起動する要求をユーザから受け付けたことに応じて、前記ローカル・プロキシが前記サーバからロードされ起動するステップを更に含む、請求項１に記載の方法。
4. 前記ローカル・プロキシは、前記ブラウザにおいて動作するアプリケーションに関連したソフトウェアを用いて実装する請求項１に記載の方法。
5. 前記ローカル・プロキシによる通信は、ハイパーテキスト転送プロトコル（ＨＴＴＰ）により行われる請求項１に記載の方法。
6. 前記ローカル・プロキシは、通信先として前記クライアント端末の前記アプリケーションとのみ通信する請求項１に記載の方法。
7. ネットワーク・アプリケーションが動作するクライアント・サーバ・システムにおける通信情報を共有するシステムであって、
   クライアント端末で動作するブラウザと、
   前記クライアント端末で動作するローカル・プロキシであって、前記クライアント端末で動作するアプリケーションとサーバとの間の通信を代理するものとして、前記クライアント端末で動作する前記ブラウザと同じプロセスで動作する、ローカル・プロキシと、
   を備え、
   前記アプリケーションは、前記ローカル・プロキシとは異なるプロセスで動作し、
   前記ローカル・プロキシは、
   前記アプリケーションが送信したデータを受信するデータ受信部と、
   前記データをサーバに送信するデータ送信部と、
   前記サーバからの処理済データを受信する処理済データ受信部と、
   前記処理済データを前記アプリケーションに送信する処理済データ送信部と、
   を備える、システム。
8. ネットワーク・アプリケーションが動作するクライアント・サーバ・システムにおける通信情報を共有するコンピュータ・プログラムであって、
   クライアント端末で動作するローカル・プロキシに、
   前記クライアント端末で動作するアプリケーションとサーバとの間の通信を代理するものとして、前記クライアント端末で動作するブラウザと同じプロセスで動作するステップと、
   前記アプリケーションが送信したデータを受信し、当該データをサーバに送信するステップと、
   前記サーバからの処理済データを受信し、当該処理済データを前記アプリケーションに送信するステップと、
   を実行させ、前記アプリケーションに、
   前記ローカル・プロキシとは異なるプロセスで動作するステップ
   を実行させる、コンピュータ・プログラム。

Images