JP2008225573A - 代理サーバ、代理サーバのためのプログラム及び代理アクセス方法 - Google Patents

Abstract

【課題】複数のｗｅｂサーバの認証を代行する代理サーバを提供する。
【解決手段】代理サーバにユーザを特定する機能と、当該ユーザが目的とするアクセスしたいサーバにおいて認証を済ませたか否かを記録する機能と、ユーザ認証を代行する機能と、受信したｈｔｍｌ文書にＵＲＬの絶対位置を変換するタグを挿入する機能を追加した。
【選択図】図２

Description

本発明は、ｗｅｂサーバに適用して好適な技術に関する。
より詳細には、医業ＳＮＳサービスの実現に適した、代理サーバに関する。

医業全体に過渡の市場競争原理が持ち込まれてしまった結果、大病院と開業医との格差が生じ、地域医療の効率が阻害される実態を招いてしまった。
これを是正し、地域医療行政の効率化を図り、以ってわが国全体の医療費の低減に結びつけるためには、近隣地域における医療法人同士の連携と情報交換が求められる。
そこで発明者は、医療法人同士が互助の精神に基づき、医業専門のポータルサイトを構築することを考えた。
なお、本発明の先行技術を特許文献１及び２に記す。
特開２００２−１３５３３５号公報 特開２０００−３２２３８３号公報

多くの病院は自前のｗｅｂサイトを持っている。そこには医師等の医業関係者にのみアクセスを許可するコンテンツ（以下「制限付コンテンツ」）が含まれている。
医業関係者がこれら制限付コンテンツの閲覧をする際には、閲覧したい病院のｗｅｂサイトにおいてユーザ登録を行い、ユーザＩＤとパスワードを取得する必要がある。
このように取得する必要があるユーザＩＤとパスワードの組は、制限付コンテンツを閲覧したい病院のｗｅｂサイトの数だけ増える。したがって、医業関係者はそれらユーザＩＤとパスワードの組を管理しなければならない。
これは極めて多忙な業務に従事する医業関係者にとって大きな負担である。

本発明はかかる点に鑑みてなされたものであり、単一のユーザ認証のみで複数のｗｅｂサイトの認証と透過的なアクセスを実現する代理サーバ、代理サーバのためのプログラム及び代理アクセス方法を提供することを目的とする。

上記課題を解決するための本発明は、クライアントから発せられる、外部サーバのＵＲＬと第１のユーザ認証情報を含む第１のアクセス要求を受信し、第１のユーザ認証情報に基づいて前記ユーザを特定すると共に、ユーザが外部サーバにおいてユーザ認証を行ったか否かを確認する。
もし、ユーザ認証が行われていなければユーザ認証を実行し、外部サーバのアクセス要求に用いる第２のユーザ認証情報を生成する。
そして、外部サーバのＵＲＬに基づいて第２のアクセス要求を前記外部サーバに送信する。
更に、外部サーバから受信したデータを書き換えるものである。

従来より代理サーバはあったが、ユーザ認証を代行する機能は提供されていなかった。そこで、代理サーバにユーザを特定する機能と、当該ユーザがアクセスしたいサーバにおいて認証を済ませたか否かを記録する機能と、ユーザ認証を代行する機能を追加した。

本発明により、単一のユーザ認証のみで複数のｗｅｂサイトの認証と透過的なアクセスを実現する代理サーバ、代理サーバのためのプログラム及び代理アクセス方法を提供できる。

以下、本発明の実施の形態を、図１〜図１９を参照して説明する。

本実施形態を図示を伴って説明する前に、本実施形態にかかるシステムの概略を説明する。
本実施形態は、医業に特化したソーシャル・ネットワーキング・サービス（Social Networking Service：ＳＮＳ：人と人とのつながりを促進する、コミュニティ型のｗｅｂサイト。）であり、これを実現するためのｗｅｂサーバが中心となって構成される。

医業全体に過渡の市場競争原理が持ち込まれてしまった結果、大病院と開業医との格差が生じ、地域医療の効率が阻害される実態を招いてしまった。
これを是正し、地域医療行政の効率化を図り、以ってわが国全体の医療費の低減に結びつけるためには、近隣地域における医療法人同士の連携と情報交換が求められる。
そこで発明者は、互助の精神に基づき、医療法人同士が医業専門のポータルサイトを構築することを考えた。

本実施形態のｗｅｂサーバが提供するＳＮＳサービスは、患者のプライバシー等に配慮し、一般人からのアクセスを遮断するために、ユーザ認証の仕組みを採り入れている。また、医師、看護師、事務担当者等、ユーザの属性を考慮したコンテンツ表示制御やアクセス制御を行うようにしている。
更に、本実施形態のｗｅｂサーバは、検査予約等で病院ｗｅｂサイトにログインする際に必要なユーザ認証を代行する仕組みを採り入れている。

［全体構成］
図１は、本実施の形態の例である、医業ＳＮＳサービスシステムの全体を示す概略図である。
総合病院１０２の院内ＬＡＮ１０３には、医師１０４、看護師１０５、事務担当者１０６毎に割り当てられているクライアントＰＣ１０７、１０８及び１０９が接続されている。
開業医１１０は、単一のクライアントＰＣ１１１を、医師１１２と看護師１１３がそれぞれ利用している。
医療器具の卸業者１１４は、総合病院１０２と同様に図示しない社内ＬＡＮを通じてクライアントＰＣ１１５が接続されている。営業担当者１１６はこのクライアントＰＣ１１５を操作する。
これらクライアントＰＣはインターネット１１７に接続されている。
そして、医業ＳＮＳサーバを構成するｗｅｂサーバ１１８も、インターネット１１７に接続されている。

［ｗｅｂサーバ］
図２は、ｗｅｂサーバ１１８の機能的な構成を示すブロック図である。
ｗｅｂサーバ１１８は、概略的にはＨＴＴＰ（Hyper Text Transfer Protocol）を用いて、クライアントの図示しないｗｅｂブラウザの要求に応じて、クライアントにｈｔｍｌ文書を送信する、周知のｗｅｂサーバである。
ｗｅｂサーバ１１８は、一般的なネットワークＯＳが稼動するコンピュータである。ネットワークＯＳは、一例として、ＦｒｅｅＢＳＤ等のＢＳＤ系、或はＬｉｎｕｘ（登録商標）等のＰＯＳＩＸ（Portable Operating System Interface for UNIX）（ＵＮＩＸは登録商標）系ＯＳ等が挙げられる。

ｗｅｂサーバプログラム２０２は、クライアントＰＣから来る要求（コマンド）を受信し、これに応じて、ＨＴＴＰにてｈｔｍｌ文書をクライアントへ送信する機能を提供する。端的にいえばｗｅｂサーバソフトウェアであり、一例としてはＡｐａｃｈｅ(http://www.apache.org/)等である。
ｗｅｂサーバプログラム２０２はクライアントＰＣの要求に応じ、ｃｇｉ（Common Gateway Interface）の実行をも行う。
特に、本実施形態のｗｅｂサーバ１１８が所定の機密性を必要とする性格上、ｗｅｂサーバプログラム２０２は暗号化モジュール２０３を含んでいる。
暗号化モジュール２０３はＨＴＴＰＳ（Hypertext Transfer Protocol Security：ｗｅｂサーバとクライアントＰＣがデータを送受信するのに使われるプロトコルであるＨＴＴＰに、ＳＳＬによるデータの暗号化機能を付加したプロトコル。ポート番号４４３番が主に用いられる。）の機能を提供する。

ｃｇｉの実体は標準出力にテキストを出力するプログラムである。ｃｇｉが生成するテキストが、ｗｅｂサーバプログラム２０２によってＨＴＴＰ或はＨＴＴＰＳにてクライアントＰＣへ送信される。
ｃｇｉを構成する要素としては、どのようなプログラミング言語であってもよい。ｐｅｒｌ（http://www.perl.org/）やＰＨＰ（http://php.net/）、ｐｙｔｈｏｎ（http://www.python.org/）、ｒｕｂｙ（http://www.ruby-lang.org/ja/）等のインタプリタ言語に留まらず、ＣやＪａｖａ（登録商標）等のコンパイルを要する言語であってもよい。簡単な内容であればシェルスクリプトであってもよい。

各々のｃｇｉは主にｗｅｂブラウザに表示する画面を作るためのｈｔｍｌ文書を作成する。つまり、ｈｔｍｌ文書はｗｅｂブラウザを通じてＧＵＩ（Graphical User Interface）を作成する手段である。
なお、図２ではｗｅｂブラウザに表示させる画面毎にｃｇｉが個別に設けられているが、単一のｃｇｉで構成することも可能である。但し、その場合は単一のｃｇｉの中に複数の表示画面を作成する機能が含まれることとなる。

認証ｃｇｉ２０４は、クライアントＰＣから来るアクセス要求に応じて、ｗｅｂサーバプログラム２０２によって実行される。
認証ｃｇｉ２０４は、クライアントＰＣから得られたパラメータであるユーザＩＤとパスワードをユーザテーブルから検索して照合する。
ユーザテーブル２０５には、登録ユーザが重複のないユーザＩＤにて記録されている。ユーザテーブル２０５は、各登録ユーザのユーザＩＤをパスワードと共に管理する。
認証ｃｇｉ２０４による照合の結果、ユーザＩＤとパスワードが合致していれば、認証ｃｇｉ２０４は、正常にログインが完了したことを示すＣｏｏｋｉｅ（クッキー：ｗｅｂサイトの提供者が、ｗｅｂブラウザを通じて訪問者のコンピュータに一時的にデータを書き込んで保存させるしくみ。殆どの場合、アルファベット及び数字の１バイト文字列にて構成される。）を作成すると共に、自動的に表示ｃｇｉ２０６に移行するＨＴＴＰメッセージを作成する。これらはｗｅｂサーバプログラム２０２を通じてクライアントＰＣに送信される。
一方、照合の結果、ユーザＩＤとパスワードが合致していなければ、ログインが失敗したことを示すエラーメッセージを付して、自動的に図示しないエラー画面ｈｔｍｌ文書に移行するＨＴＴＰメッセージを作成する。これらはｗｅｂサーバプログラム２０２を通じてクライアントＰＣに送信される。

自動的に表示ｃｇｉ２０６に移行するＨＴＴＰメッセージとは、ＨＴＴＰのステータスコードの一種である転送機能を用いている。この転送機能のステータスコードは、ＨＴＴＰのバージョンによって異なる。
http ver.1.1の場合は「303 See Other」というステータスコードと、表示ｃｇｉ２０６のＵＲＩを、ＨＴＴＰ応答ヘッダに記す。
http ver.1.0の場合は「302 Found」というステータスコードと、表示ｃｇｉ２０６のＵＲＩを、ＨＴＴＰ応答ヘッダに記す。
認証ｃｇｉ２０４は、このように構成したＨＴＴＰ応答ヘッダを作成し、クライアントＰＣへ送信する。
クライアントＰＣのｗｅｂブラウザは、このＨＴＴＰ応答ヘッダを解釈し、直ちに記されているＵＲＩに基づいて表示ｃｇｉ２０６の表示（実行）をｗｅｂサーバ１１８に要求する。
すなわち、認証ｃｇｉ２０４はｗｅｂブラウザによって表示画面に表示されるｈｔｍｌ文書を作成しない。或は、認証ｃｇｉ２０４がｈｔｍｌ文書（ＨＴＴＰメッセージの本文）を作成しても、ｗｅｂブラウザの機能により、ｗｅｂブラウザがＨＴＴＰ応答ヘッダ中の転送ステータスコードを検出して転送を実行するので、当該作成されたｈｔｍｌ文書はｗｅｂブラウザには表示されない。
ログイン失敗時に自動的にエラー画面ｈｔｍｌ文書に移行するＨＴＴＰメッセージも、同様である。

表示ｃｇｉ２０６は、後述するトップメニューをディスプレイに表示するｈｔｍｌ文書を生成する。なお、表示ｃｇｉ２０６の表示画面は後述する。
ユーザ登録ｃｇｉ２０７は、新規にユーザを登録する際に用いられる。
法人登録ｃｇｉ２０８は、新規に医療法人や卸業者を登録する際に用いられる。
これら以外にも多くのｃｇｉがあるが、詳細は省略する。

プロキシｃｇｉ２０９は、本実施形態において重要な機能を提供するものであり、各病院が保有するｗｅｂサーバのユーザ認証を代行する機能を新たに追加した、プロキシサーバの機能を提供するｃｇｉである。
プロキシｃｇｉ２０９は、各病院が保有するｗｅｂサーバにアクセスするために、非対話型のｗｅｂクライアント２１０を稼動させる。
また、各病院が保有するｗｅｂサーバにアクセスする際に必要な情報をセッション情報ファイル２１１に記録する。
そして、各病院が保有するｗｅｂサーバから受信したｈｔｍｌ文書や画像データ等は、スプールディレクトリ２１２に一時的に保存する。
このプロキシｃｇｉ２０９については後に詳述する。

ｗｅｂサーバ１１８には各種テーブルが存在する。
図３は、ｗｅｂサーバ１１８の各テーブルのフィールドを記す。
ユーザテーブル２０５は前述の通り、ユーザＩＤとパスワードの他に、当該ユーザの氏名、当該ユーザが所属する医療法人や業者を表す法人ＩＤが格納されている。ユーザテーブル２０５はユーザＩＤにおいて重複がない状態で各レコードが格納されている。以下、このようにあるフィールドにおいて「重複がない状態」を「ユニーク（unique）である」と呼ぶ。
ユーザ属性テーブル２１３は、ユーザＩＤとユーザ属性コードが格納されている。ユーザ属性テーブル２１３はユーザＩＤにおいて重複するレコードが存在し得るので、ユニークではない。
ユーザ属性マスタ２１４は、ユーザ属性コードとその詳細情報が格納されている。

例として、看護師Ａが助産婦の免許を取得した場合、看護師Ａは看護師のユーザ属性コード「２」に加えて、助産婦のユーザ属性コード「３」を持つ。看護師ＡのユーザＩＤが「ＡＢＣ９８７６５」というコードであるなら、ユーザ属性テーブル２１３には、
「ユーザＩＤ，ユーザ属性コード」のフィールド順に、
「ＡＢＣ９８７６５，２」というレコードと、
「ＡＢＣ９８７６５，３」というレコードを格納することとなる。
すなわち、ユーザは複数の属性を取り得る。属性はシステムの運用に伴い、増える可能性が考えられる。そこで、ユーザ属性マスタ２１４とユーザ属性テーブル２１３で管理する。

法人テーブル２１５は、法人ＩＤ、法人名、法人種別コードが格納されている。法人テーブル２１５は法人ＩＤにおいてユニークである。
法人種別マスタ２１６は、法人種別コードとその詳細情報が格納されている。法人の場合は複数の種別を持つことはないので、ユーザ属性テーブル２１３のような、法人ＩＤと法人種別コードとの関係を格納するテーブルは設けていない。
法人リンクテーブル２１７は、法人ＩＤと、リンクＵＲＬ（Uniform Resource Locator：ＴＣＰ／ＩＰネットワーク上に存在する情報源の場所を指し示す記述方式。）、そしてこれらに付随する情報が格納されている。

ここで、図１１を参照して、法人リンクテーブル２１７の詳細を説明する。
図１１は、表示ｃｇｉ２０６が生成するｈｔｍｌ文書を、クライアントＰＣのｗｅｂブラウザによって表示した、表示画面の一例を示す。ここでは表示画面のうち、医療法人リンク欄１００３のみ説明し、その他の欄の説明は後述する。
医療法人リンク欄１００３に、「紹介状」「セミナー情報」「検査予約」「セミナー視聴」という項目がある。これらはｈｔｍｌの「Ａタグ」と呼ばれるリンクである。すなわち、マウス等のポインティングデバイスでこれら項目をクリックすると、項目に埋め込まれているＵＲＬが読み出され、ＵＲＬのスキームに従った動作が起動される。
例えば、「紹介状」の項目は、「<a href="http://www.abchospital.xxxx/shoukaijou.pdf">紹介状</a>」というｈｔｍｌタグで記述されている。
説明の都合上、「<a href="...">...</a>」を「Ａタグ」と呼ぶ。
なお、ＵＲＬのスキームについては後述する。

各項目は法人リンクテーブル２１７のレコードによって構成される。
具体的には、「リンク名」が項目名であり、「リンクＵＲＬ」がＡタグを構成するＵＲＬである。
前述の「<a href="http://www.abchospital.xxxx/shoukaijou.pdf">紹介状</a>」の場合は、「紹介状」がリンク名に、「http://www.abchospital.xxxx/shoukaijou.pdf」がリンクＵＲＬに記録されているレコードを読み出して、上述のＡタグを構成する。
「表示順」は、医療法人リンク欄１００３内における項目の表示順を示す。
「シリアルナンバー」は、各レコードにユニークに付される番号である。これは後述するリンクアクセス許可属性テーブル２１８とプロキシ認証テーブル２１９において用いられる。

プロキシ（Ｙ／Ｎ）フィールドはフラグフィールドであり、これが「Ｙ」であると、後述するプロキシｃｇｉ２０９のＵＲＬにリンクＵＲＬを連結して、ＵＲＬ文字列を構成する。

再び図２及び図３に戻って説明する。
リンクアクセス許可属性テーブル２１８には、シリアルナンバーとユーザ属性コードが格納されている。リンクアクセス許可属性テーブル２１８はシリアルナンバーにおいてユニークではなく、シリアルナンバー毎に重複するレコードが存在し得る。
ここで、図１１を参照して、リンクアクセス許可属性テーブル２１８の詳細を説明する。
図１１は、医療法人リンク欄の表示例を示す。
図１１（ａ）において、医師（ユーザ属性コードは１）及び看護師（ユーザ属性コードは２）がｗｅｂサーバ１１８にアクセスすると、医療法人リンク欄には「紹介状」「セミナー情報」「検査予約」「セミナー視聴」と、４つの項目が表示される。これらはリンクアクセス許可属性テーブル２１８に、各々のリンク毎に表示を許可されるユーザ属性コードが記されているからである。
Ａタグが前述の「<a href="http://www.abchospital.xxxx/shoukaijou.pdf">紹介状</a>」の場合は、「紹介状」がリンク名に、「http://www.abchospital.xxxx/shoukaijou.pdf」がリンクＵＲＬに記録されているレコードのシリアルナンバーについて、ユーザ属性コードが１のレコードと、ユーザ属性コードが２のレコードが、リンクアクセス許可属性テーブル２１８に存在する。

一方、事務員（事務担当：ユーザ属性コードは４）がｗｅｂサーバ１１８にアクセスすると、図１１（ｂ）のように、「検査予約」の項目のみ表示される。これは、「検査予約」の項目にのみユーザ属性コードが４のレコードが存在し、他のリンク情報のレコードにはユーザ属性コードが４のものが存在しないからである。
このように、本実施形態のｗｅｂサーバ１１８は、アクセスするユーザの属性コードに基づいて、表示する項目、表示しない項目を決定することができる。

プロキシ認証テーブル２１９は、後述するプロキシｃｇｉ２０９の認証動作において、病院のｗｅｂサイトにアクセスする際に必要なユーザ認証に用いる各種情報が保持されている。
プロキシ認証テーブル２１９は、シリアルナンバーにおいてユニークではなく、シリアルナンバー毎に重複するレコードが存在し得る。プロキシ認証テーブル２１９の詳細な内容については後述する。

ユーザページ構成テーブル２２０は、ユーザＩＤと法人ＩＤと表示順が格納されている。
ユーザページ構成テーブル２２０はユーザＩＤにおいてユニークではなく、ユーザＩＤ毎に重複するレコードが存在し得る。
ユーザページ構成テーブル２２０は、法人リンクテーブル２１７、リンクアクセス許可属性テーブル２１８と共に、トップメニューの医療法人リンク欄１００３及び１００４等の表示内容を構成する際に用いられる。
各ユーザはユーザ登録ｃｇｉ２０７を実行して、表示ｃｇｉ２０６によって表示されるトップメニューに表示したい項目を設定する。すると、その設定内容は、ユーザページ構成テーブル２２０に格納される。
なお、ユーザページ構成テーブル２２０に示しているフィールドは、図１１及び図１１に示す医療法人リンク欄１００３を表現するに最低限必要なフィールドのみ記している。これ以外にもフィールドは存在するが、詳細は略す。

［クライアントＰＣ］
図４は、クライアントＰＣの機能ブロック図である。
典型的なパソコンであるクライアントＰＣ４０２は、例えばマイクロソフト社のＷｉｎｄｏｗｓ（登録商標）が稼動する。図示しない所定のインターフェースを通じてインターネット１１７に接続される。
クライアントＰＣ４０２には、ｗｅｂブラウザ４０３が稼動し、インターネット１１７を通じてｗｅｂサーバ１１８から受信するｈｔｍｌ文書を解釈し、ディスプレイ４０４に表示する。
また、クライアントＰＣ４０２にはＩＣカードリーダ４０５が接続されている。ＩＣカードリーダ４０５は電波を発してＩＣカード４０６から非接触にて所定の情報を読み取り、当該情報に記述されている内容に従って、所定のプログラムを起動する。例として、Ｆｅｌｉｃａ（登録商標）が挙げられる。

ＯＳから見ると、ＩＣカード４０６はＩＣカードリーダ４０５と共に、半導体ディスク装置として見える。ＩＣカード４０６は、ファイルシステムを備える、論理的に小さなディスク装置として扱われる。
ＩＣカード４０６には、ユーザのＩＤとパスワード、そして自動実行用ｈｔｍｌ文書、或はそのＵＲＬがファイルの形で記録されている。特に、自動実行用ｈｔｍｌ文書のＵＲＬは、Ｗｉｎｄｏｗｓ（登録商標）における「ショートカット」の形式で記述されている。
ＩＣカードリーダ４０５からこれらＩＣカード４０６の情報を読み取ると、ＯＳに標準的に備わっている「ＭＩＭＥ」（Multipurpose Internet Mail Extension：ＴＣＰ／ＩＰネットワーク上でやりとりされる電子メールにおいて、各国語や画像、音声、動画などを扱うための規格。）の機能に則り、連想的にｗｅｂブラウザ４０３が起動される。
このような機能は、特許文献２に開示されている。

自動実行用ｈｔｍｌ文書がＩＣカード４０６或はｗｅｂサーバ１１８からｗｅｂブラウザ４０３に読み込まれると、ｗｅｂブラウザ４０３はｈｔｍｌ文書に埋め込まれている、ＪａｖａＳｃｒｉｐｔ（登録商標）等で記述されているプログラムを実行する。そして、ＩＣカード４０６内に記録されているユーザＩＤとパスワードを読み取り、ｗｅｂサーバ１１８の認証ｃｇｉ２０４に送信する。
また、ｗｅｂブラウザ４０３はｗｅｂサーバ１１８とのＨＴＴＰＳによる通信を行うために、暗号化モジュール４０９を備える。

ｗｅｂブラウザ４０３の起動と共に、ＩＣカード４０６内に記録されているユーザＩＤとパスワードを認証ｃｇｉ２０４に送信するための仕組みは、様々な形態が考えられる。
標準的なｗｅｂブラウザは、このような「起動と共に特定の記録媒体から予め定められた情報を読み取って、所定のＵＲＬに向けて送信する」機能を持たない。そこで、そのような機能を提供するプログラムを埋め込んだｈｔｍｌ文書をｗｅｂブラウザの起動時に読み込ませる方法が考えられる。
ＪａｖａＳｃｒｉｐｔ（登録商標）でそのようなプログラムを埋め込んだｈｔｍｌ文書をＩＣカード４０６に格納するか、或はｗｅｂサーバに置いて、ＩＣカード４０６にはそのＵＲＬを記述しておく、等の実施形態が考えられる。
また、ｗｅｂブラウザにプラグインソフトウェアを追加するか、専用のｗｅｂブラウザを作成すれば、ｗｅｂブラウザにＩＣカードからユーザＩＤとパスワードを読み出す仕組みを組み込めるので、ＩＣカードにはｗｅｂサーバ１１８の認証ｃｇｉ２０４のＵＲＬを記録するだけでよい。

また、ｗｅｂブラウザ４０３にはセキュリティを担保する機能として、セキュリティ担保機能部４０８を設けることができる。これは、
・ｗｅｂブラウザ４０３が稼動している最中にはキャッシュディレクトリ内のファイルを他のプロセスから読み出されないようにロックを掛け、
・ｗｅｂブラウザ４０３が終了する際には、キャッシュディレクトリ内のファイルを、不用意に読み出されないように全部削除する
ためのものであり、ｗｅｂブラウザ４０３のプラグインとして提供されるか、専用のｗｅｂブラウザの一機能として組み込まれる。

ＩＣカードリーダドライバ４０７はＩＣカード４０６が載置されているか否かを常にポーリングしており、一度ｗｅｂブラウザ４０３を起動しても、ＩＣカードリーダ４０５に載置されていたＩＣカード４０６が、ＩＣカードリーダ４０５から取り外されると、ＩＣカードリーダドライバ４０７はこれを検出して、稼働中のｗｅｂブラウザ４０３を終了させる。

［ログインからトップメニュー表示まで］
図５は、上述のｗｅｂサーバ１１８とクライアントＰＣ４０２との間で行われる、ユーザ認証から表示ｃｇｉ２０６によるトップページを表示するまでの動作の流れを示すフロー図である。
ユーザがＩＣカード４０６をＩＣカードリーダ４０５に載置すると（Ｓ５０１）、ｗｅｂブラウザ４０３が起動される（Ｓ５０２）。
そして、認証ｃｇｉ２０４にユーザＩＤとパスワードを送信する（Ｓ５０３）。
ｗｅｂサーバ１１８はクライアントＰＣ４０２のアクセスに呼応して認証ｃｇｉ２０４を実行し、受信したユーザＩＤとパスワードをユーザテーブル２０５と突き合わせる。その結果、ユーザＩＤとパスワードの組が正しければ、ユーザを認証する（Ｓ５０４）。

次に、正規ユーザであることに呼応して、表示ｃｇｉ２０６にリダイレクト（redirect：転送）するための転送ＨＴＴＰメッセージを、Ｃｏｏｋｉｅと共に送信する（Ｓ５０５）。つまり、これがステータスコード「302」或は「303」の転送ステータスコードのＨＴＴＰメッセージである。
クライアントＰＣ４０２のｗｅｂブラウザ４０３は、転送ＨＴＴＰメッセージを受けると、メッセージヘッダ中のＣｏｏｋｉｅを保存し、以降のｗｅｂサーバ１１８へのアクセスの際にはこのＣｏｏｋｉｅを伴ってアクセスする。そして、メッセージヘッダ中のＵＲＬ、すなわち表示ｃｇｉ２０６にリダイレクトアクセスする（Ｓ５０６）。これがトップページの要求となる。

表示ｃｇｉ２０６は、クライアントＰＣ４０２のｗｅｂブラウザ４０３のアクセスを受けて実行される（Ｓ５０７）。要求に含まれるＣｏｏｋｉｅの存在を検証し、正規にログインされたユーザであることを確認した後、図１０に示すトップページを構成するｈｔｍｌ文書を作成し、これをクライアントＰＣ４０２に送信する（Ｓ５０８）。
クライアントＰＣ４０２のｗｅｂブラウザ４０３は、受信したｈｔｍｌ文書を表示する（Ｓ５０９）。この結果、図１０のような表示内容がディスプレイ４０４に表示される。

図６は、クライアントＰＣ４０２の、ユーザ認証から表示ｃｇｉ２０６によるトップページを表示するまでの動作の流れを示すフローチャートである。
処理を開始すると（Ｓ６０１）、ＩＣカードリーダドライバ４０７はＩＣカード４０６がＩＣカードリーダ４０５に置かれたか、常にポーリングする（Ｓ６０２）。
ＩＣカード４０６がＩＣカードリーダ４０５に置かれたことを検出すると、ＩＣカード４０６内に格納されている自動実行用ｈｔｍｌ文書或はそのＵＲＬを読み取り、ｗｅｂブラウザ１１８を起動する（Ｓ６０３）。
ｗｅｂブラウザ４０３はｈｔｍｌ文書に埋め込まれているＪａｖａＳｃｒｉｐｔ（登録商標）等で記述されているプログラムを実行し、ＩＣカード４０６内に記録されているユーザＩＤとパスワードを読み取り（Ｓ６０４）、ｗｅｂサーバ１１８の認証ｃｇｉ２０４に送信する（Ｓ６０５）。その後は、ｗｅｂサーバ１１８からＨＴＴＰメッセージが来るのを待つ（Ｓ６０６）。

ｗｅｂサーバ１１８からＨＴＴＰメッセージが来たら、ＨＴＴＰメッセージ中のヘッダを解釈し、Ｃｏｏｋｉｅを保存し、以降のアクセスに用いると共に、ヘッダに記されている転送先ＵＲＬにアクセスする（Ｓ６０７）。この時点で、ｗｅｂブラウザ４０３は表示ｃｇｉ２０６へアクセスすることとなる。
その後は、ｗｅｂサーバ１１８からＨＴＴＰメッセージに含まれるｈｔｍｌ文書が来るのを待ち（Ｓ６０８）、表示ｃｇｉ２０６が生成したｈｔｍｌ文書を受信したら、これを表示し（Ｓ６０９）、終了する（Ｓ６１０）。

図７は、ｗｅｂサーバの、認証ｃｇｉ２０４の動作の流れを示すフローチャートである。
ｗｅｂサーバプログラム２０２によって起動されると（Ｓ７０１）、クライアントＰＣ４０２から受信したＩＤとパスワードをユーザテーブル２０５と照合する（Ｓ７０２）。
照合の結果、ＩＤとパスワードの組み合わせが正しいものと確認したら、認証ｃｇｉ２０４は、Ｃｏｏｋｉｅを含む、トップページ（表示ｃｇｉ２０６）へリダイレクトするためのＨＴＴＰメッセージを作成して送信する（Ｓ７０３）。このとき、ｗｅｂサーバ１１８は、Ｃｏｏｋｉｅと対応するユーザＩＤをセッション情報ファイル２１１に記録しておき、クライアントから来るメッセージ要求に含まれているＣｏｏｋｉｅから正常に認証を済ませたユーザであるのか、またそのユーザＩＤを取得できるようにする。
照合の結果、ＩＤとパスワードの組み合わせが誤っているものと確認したら、認証ｃｇｉ２０４はエラー画面へリダイレクトするためのＨＴＴＰメッセージを作成して送信する（Ｓ７０３）。
ＨＴＴＰメッセージの送信完了を以って、認証ｃｇｉ２０４は終了する（Ｓ７０５）。

図８は、ｗｅｂサーバの、表示ｃｇｉ２０６の動作の流れを示すフローチャートである。
ｗｅｂサーバプログラム２０２によって起動されると（Ｓ８０１）、クライアントＰＣ４０２に送信するためのｈｔｍｌ文書を作成する（Ｓ８０２）。
ｈｔｍｌ文書を作成したら、所定のＨＴＴＰメッセージヘッダを付して、クライアントＰＣ４０２に送信し（Ｓ８０３）、終了する（Ｓ８０４）。

図９は、表示ｃｇｉ２０６におけるｈｔｍｌ文書を作成する動作の流れを示すフローチャートである。図８のステップＳ８０２に該当する。
処理を開始すると（Ｓ９０１）、クライアントＰＣ４０２から受信したメッセージ要求に含まれているＣｏｏｋｉｅを基にセッション情報ファイル２１１を検索し、ユーザＩＤを取得する。そして、そのユーザＩＤをキーとして、ユーザページ構成テーブル２２０を検索し、法人ＩＤを取得する（Ｓ９０２）。ここで図９のステップＳ９０２中、「（複数）」と括弧を付しているのは、ユーザが表示を望む医療法人は必ずしも複数とは限らないことに起因する。要するに、図１１の医療法人リンク欄１００４がない場合もありうる、ということである。

検索の結果、法人ＩＤを一つ以上得ると、この法人ＩＤを検索のキーとする。検索の結果得られた法人ＩＤについて順番に処理するために、最初に得られた法人ＩＤを検索のキーに設定する（Ｓ９０３）。
これ以降はループ処理である。
検索キーに設定された法人ＩＤを用いて、法人リンクテーブル２１７を検索し、シリアルナンバーを複数取得する（Ｓ９０４）。
そして、検索の結果得られたシリアルナンバーについて順番に処理するために、最初に得られたシリアルナンバーを検索のキーに設定する（Ｓ９０５）。

これ以降はループ処理である。
検索キーに設定されたシリアルナンバーを用いて、リンクアクセス許可属性テーブル２１８を検索し、ユーザ属性コードを複数取得する（Ｓ９０６）。
得られたユーザ属性コードの中に、現在アクセスしているユーザのユーザ属性はあるか否かを検証する（Ｓ９０７）。もしあれば、それは医療法人リンク欄１００３等に表示すべき項目である。そこで、このステップで得られたシリアルナンバーに基づき、法人リンクテーブル２１７の該当するレコードを読み取り、ＲＡＭ等に一時保存する（Ｓ９０８）。なければその項目（法人リンクテーブル２１７の該当するレコード）は表示対象外であるので何もしない（Ｓ９０７のＮ）。

次に、ステップＳ９０４における検索の結果得られたシリアルナンバーについて、次に処理するべきシリアルナンバーがあるか否かを確認する（Ｓ９０９）。
もしあれば（Ｓ９０９のＮ）、検索キーを次のシリアルナンバーに設定し（Ｓ９１３）、再度リンクアクセス許可属性テーブル２１８を検索する処理（Ｓ９０６）を、検索対象のシリアルナンバーがなくなるまで続ける。
そして、もしなければ（Ｓ９０９のＹ）、ＲＡＭ等に一時保存していた、法人リンクテーブル２１７の該当レコードの情報を、表示順のフィールドの値に基づいてソートし、表示する（Ｓ９１０）。
以上で、ユーザページ構成テーブル２２０における、一つの法人ＩＤについての検索及び表示処理が完結する。

一つの法人ＩＤについての検索及び表示処理が終わったら、次に処理すべき法人ＩＤが、ステップＳ９０３にて得られた法人ＩＤのリスト中にあるか否か検証する（Ｓ９１１）。
もしあれば（Ｓ９１１のＮ）、次の法人ＩＤを検索キーに設定し（Ｓ９１４）、再度当該法人ＩＤについての検索及び表示処理を繰り返す。
もしなければ（Ｓ９１１のＹ）、全ての法人ＩＤについて検索及び表示処理が終了したこととなる（Ｓ９１２）。

［表示画面（トップメニュー）］
図１０は表示画面である。クライアントＰＣ４０２のディスプレイ４０４に、ｗｅｂブラウザ４０３によって表示される内容である。
表示画面（トップメニュー）１００１には、
・法人表示欄１００２、
・医療法人リンク欄１００３及び１００４、
・卸業者リンク欄１００５、
・全体情報リンク欄１００６、
・法人向け情報表示欄１００７、
・ＳＮＳリンクボタン１００８
が設けられている。
また、医療法人リンク欄１００３及び１００４の左右には、スクロールボタン１００９及び１０１０が設けられている。
このスクロールボタン１００９及び１０１０を操作することにより、医療法人リンク欄１００３及び１００４の表示内容が医療法人毎に切り替わる。
なお、動的なｈｔｍｌ文書の書き換えを実現するために、Ａｊａｘ（「エイジャックス」と読む。AsychronousJavaScript + XML の略。ｗｅｂブラウザに実装されているＪａｖａＳｃｒｉｐｔ（登録商標）のＨＴＴＰ通信機能を使って、ｗｅｂページのリロードを伴わずに、ｗｅｂサーバとＸＭＬ形式のデータのやり取りを行って処理を進めていく、対話型ｗｅｂアプリケーションの実装形態。）を用いることができる。

図１１（ａ）及び（ｂ）は、医療法人リンク欄の表示例である。
図１１（ａ）は医師（ユーザ属性コードは１）及び看護師（ユーザ属性コードは２）における表示例である。
医療法人リンク欄１００３に表示されている「紹介状」「セミナー情報」「検査予約」「セミナー視聴」の４つの項目は、リンクアクセス許可属性テーブル２１８に、各々のリンク毎に表示を許可されるユーザ属性コードである１と２が記されている。

図１１（ｂ）は事務員（事務担当：ユーザ属性コードは４）における表示例である。
医療法人リンク欄１００４に表示されている「検査予約」の項目は、リンクアクセス許可属性テーブル２１８に、各々のリンク毎に表示を許可されるユーザ属性コードである４が記されている。

［プロキシサーバ機能］
図１２は、本実施形態によるｗｅｂサーバ１１８の特徴的な機能の一つである、プロキシサーバ機能を説明する全体概略図である。
医師１２０２等のユーザがクライアントＰＣ４０２を操作してｗｅｂサーバ１１８にログインし、医療法人リンク欄１００３或は１００４の中の所定のリンクをマウス等のポインティングデバイスでクリックする。
そのリンクには、本実施形態によるプロキシサーバ機能を提供するプロキシｃｇｉ２０９へのリンクが埋め込まれている。
ｗｅｂブラウザ４０３がこれをアクセスすると、ｗｅｂサーバ１１８内のプロキシｃｇｉ２０９は、ＵＲＬにプロキシｃｇｉ２０９のパラメータとして記述されている、病院１２０４のｗｅｂサーバ（以下、「病院ｗｅｂサーバ」）１２０３へアクセスを行う。
このとき、プロキシｃｇｉ２０９は、病院ｗｅｂサーバ１２０３にアクセスする際に、病院ｗｅｂサーバ１２０３が要求するユーザ認証を行う。

プロキシ（proxy）サーバは代理サーバともいう。その意味である「代理」の通り、直接アクセスができないクライアントに代わって、アクセスを代行するサーバを指す。多くは企業内ＬＡＮと外部のインターネットとの間に設けられたり、インターネット接続プロバイダのサービスの一環として設けられることが多い。

図１３は、プロキシｃｇｉ２０９によるＵＲＬの変換処理の仕組みを説明する概略図である。
プロキシｃｇｉ２０９は、パラメータとして渡される、病院ｗｅｂサーバ１２０３のＵＲＬを読み取り、これに向かってアクセスを行う。
病院ｗｅｂサーバ１２０３から受信したデータは、プロキシｃｇｉ２０９によって、クライアントＰＣ４０２に対する応答として返信される。

クライアントＰＣ４０２は、ＵＲＬ文字列１３０２に従ってｗｅｂサーバ１１８にアクセスする。
ｗｅｂサーバ１１８内のプロキシｃｇｉ２０９は、ＵＲＬ文字列１３０２からパラメータを抜粋し、新たなＵＲＬ文字列１３０３を生成し、これに従って病院ｗｅｂサーバ１２０３にアクセスする。

ＵＲＬのフォーマットは、「（スキーム名）:（スキーム毎に定められた表現形式）」という形式である。
スキームは情報源に対するアクセス方法を指し、プロトコル名が用いられていることが多い。
ＦＱＤＮは「Fully Qualified Domain Name」の略で、「完全修飾ドメイン名」とも訳される。ＴＣＰ／ＩＰネットワーク上で、ドメイン名・サブドメイン名・ホスト名を省略せずにすべて指定した記述形式を指す。
パスは、ホストに要求する情報源の在り処を示す。

ＵＲＬ文字列１３０２のうち、「?」を挟んで右側の文字列は、プロキシｃｇｉ２０９のパスである「proxy.cgi」に渡されるパラメータである。
つまり、プロキシｃｇｉ２０９は、パラメータとして渡されたＵＲＬ文字列１３０３を用いて、ｗｅｂクライアント２１０にて病院ｗｅｂサーバ１２０３にアクセスする。

改めて図２を参照して説明する。
プロキシｃｇｉ２０９は、上述のようにＵＲＬ文字列１３０２のうち、アクセス要求として渡されるパス名と、それ以降の文字列を受けて、ｗｅｂクライアント２１０を実行し、病院ｗｅｂサーバ等にアクセスする。
このとき、セッション情報ファイル２１１には、アクセスをしてきたユーザが目的となる病院ｗｅｂサーバにおいてユーザ認証を済ませているか否か等の情報が記録されている。
スプールディレクトリ２１２は、ｗｅｂクライアントが病院ｗｅｂサーバ等から受信したデータを一時的に保存するディスク領域である。

以上に説明したプロキシｃｇｉ２０９の動作を、機能のブロック図にて説明する。なお、ＨＴＴＰにおけるユーザ認証には多種多様なものが存在するが、ここでは代表的なユーザ認証技術として、Ｃｏｏｋｉｅ認証とＢＡＳＩＣ認証について、プロキシｃｇｉ２０９の機能を説明する。
図１４はプロキシｃｇｉ２０９の機能を示すブロック図である。また、クライアントＰＣ４０２からｗｅｂサーバ１１８に向けて発されるアクセス要求（リクエスト）の内容と、ｗｅｂクライアント２１０から病院ｗｅｂサーバ１２０３に向けて発されるアクセス要求の内容をも例示する。

クライアントＰＣ４０２からｗｅｂサーバ１１８に向けて、リクエスト１４０６が発される。
リクエスト１４０６の一行目は
「GET /proxy.cgi?http://www.abchospital.xxxx/yoyaku.cgi」
という文字列である。ＨＴＴＰのメソッドと、パラメータの組である。
二行目は
「Host: www.medicalsns.xxxx」
である。つまり、
「https://www.medicalsns.xxxx/proxy.cgi?http://www.abchospital.xxxx/yoyaku.cgi」
というＵＲＬ文字列１３０２の、ＦＱＤＮが二行目に、それ以降のｃｇｉのパスとｃｇｉに渡されるパラメータが一行目に配される。そして、所定の文字列が何行か続き、最後に
「Cookie: SESSIONID=qawsedrftgyhujikolp」
という行と、改行二つ（図示せず)が続く。最後の「Cookie: 」の行が、クライアントＰＣ４０２を使用するユーザをｗｅｂサーバ１１８が認証した際に、ｗｅｂブラウザ４０３が保存したＣｏｏｋｉｅである。
つまり、リクエスト１４０６は、クライアントＰＣ４０２のユーザの認証情報を含んでいる。
リクエスト１４０６の最後は、改行コードが二つ連続して終了する。改行コード二つで、リクエストを受け取る側は、リクエストの終端を認識する。

リクエスト１４０６は暗号化モジュール２０３を含むｗｅｂサーバプログラム２０２を通じてプロキシｃｇｉ２０９に渡される。
プロキシｃｇｉ２０９の内部では、受信したリクエスト１４０６はアクセス要求受信部１４０２に供給される。ここでリクエスト１４０６に含まれているＣｏｏｋｉｅを取り出し、ユーザ特定及び認証確認部１４０３に渡される。

ユーザ特定及び認証確認部１４０３は、Ｃｏｏｋｉｅからセッション情報ファイル２１１を読み取り、アクセスしてきているユーザのユーザＩＤを特定する。
次に、ユーザ特定及び認証確認部１４０３は、アクセス要求受信部１４０２から、リクエスト１４０６の一行目にある、プロキシｃｇｉ２０９に渡されるパラメータ文字列を取得する。そして、この文字列から病院ｗｅｂサーバ１２０３のＦＱＤＮを取り出す。
そして、セッション情報ファイル２１１を病院ｗｅｂサーバ１２０３のＦＱＤＮについて検索し、病院ｗｅｂサーバ１２０３において認証を行ったか否かを確認する。
認証が済んでいれば、ユーザ特定及び認証確認部１４０３は、認証部１４０４を通じてアクセス要求変換部１４０５にｗｅｂクライアント２１０を実行させるべく命ずる。

アクセス要求変換部１４０５は、アクセス要求受信部１４０２が受信したリクエスト１４０６からＵＲＬ文字列１３０３を生成し、セッション情報ファイル２１１に記録されているユーザ認証のための情報を用いて、ｗｅｂクライアント２１０を実行する。
もし、病院ｗｅｂサーバ１２０３がＣｏｏｋｉｅ認証の場合は、病院ｗｅｂサーバ１２０３にアクセスするためのＣｏｏｋｉｅを含むリクエスト１４０７を生成する。
もし、病院ｗｅｂサーバ１２０３がＢＡＳＩＣ認証の場合は、病院ｗｅｂサーバ１２０３にアクセスするためのＩＤとパスワードをＢａｓｅ６４エンコードした「Authorization: Basic 」文字列を含むリクエスト１４０８を生成する。

病院ｗｅｂサーバ１２０３からｗｅｂクライアント２１０へデータが送られると、その際に得られるＨＴＴＰメッセージヘッダをヘッダ解析部１４１０が解析する。
解析の結果、ＭＩＭＥ宣言が「text/html」であれば、ヘッダ解析部１４１０はｈｔｍｌ文書書換部１４０９に命じて、受信したｈｔｍｌ文書にＢＡＳＥタグ１６０３を挿入させる。なお、ＢＡＳＥタグ１６０３については後述する。
解析の結果、ＭＩＭＥ宣言が「text/html」以外のものであれば、ヘッダ解析部１４１０はｈｔｍｌ文書書換部１４０９に命じて、受信したデータをそのまま素通りさせる。
そして、一旦受信したデータをスプールディレクトリ２１２に貯めた後、ｗｅｂサーバプログラム２０２を通じてクライアントＰＣ４０２に送信する。

以上説明したように、ユーザ認証を要するｗｅｂサーバに対するアクセスのリクエストには、ユーザ認証の証拠となる文字列が含まれている。
Ｃｏｏｋｉｅ認証であれば、「Cookie: 」で始まる文字列であり、ＢＡＳＩＣ認証であれば「Authorization: Basic 」で始まる文字列である。

［Ｃｏｏｋｉｅ認証］
図１５は、病院ｗｅｂサーバ１２０３においてアクセスしたい対象となるｗｅｂページがＣｏｏｋｉｅ認証を必要とする場合における、クライアントＰＣ４０２と、プロキシｃｇｉ２０９と、病院ｗｅｂサーバ１２０３の動作の流れを示すフロー図である。
クライアントＰＣ４０２がＵＲＬ文字列１３０２を用いてｗｅｂサーバ（プロキシサーバ）１１８のプロキシｃｇｉ２０９にアクセスする（Ｓ１５０１）。
プロキシｃｇｉ２０９はクライアントＰＣ４０２のアクセス要求に含まれているＣｏｏｋｉｅを読み取り、アクセスしてきたユーザのユーザＩＤをセッション情報ファイル２１１から特定する。
次に、ＵＲＬ文字列１３０２からパラメータ（ＵＲＬ文字列１３０３）を抜き出す。
そして、セッション情報ファイル２１１を読み取り、当該ユーザが目的とする病院ｗｅｂサーバ１２０３において認証を済ませているか否かを見る。

ここで、未だに認証が行われていない状態であることを確認すると、ｗｅｂサーバ１１８のプロキシｃｇｉ２０９は、認証処理を開始する。
先に取得したユーザＩＤと、病院ｗｅｂサーバ１２０３のＵＲＬ文字列１３０３をキーにして、プロキシ認証テーブル２１９を検索し、該当するレコードを得る。そして、サーバ用ＩＤ、サーバ用パスワード、認証ｃｇｉのＵＲＬ、認証方式、メソッド、認証成功時のＵＲＬを取得する（Ｓ１５０２）。

（プロキシ認証テーブル）
ここでプロキシ認証テーブル２１９の各フィールドを説明する。
プロキシ認証テーブル２１９には、病院ｗｅｂサーバ１２０３にアクセスする際に行うユーザ認証に必要な情報が格納されている。
シリアルナンバーは、法人リンクテーブル２１７のシリアルナンバーである。
全体認証はフラグフィールドであり、このフィールドが「Ｙ」のときには、ユーザＩＤの欄は空欄で、全てのアクセス可能なユーザが共通のサーバ用ＩＤとサーバ用パスワードを用いて認証を行う。
ユーザＩＤはユーザテーブル２０５のユーザＩＤと等しい。
サーバ用ＩＤとサーバ用パスワード（サーバ用ＰＷ）は、病院ｗｅｂサーバにアクセスする際に必要となるＩＤとパスワードである。

認証ｃｇｉのＵＲＬは、病院ｗｅｂサーバに設けられている認証ｃｇｉのＵＲＬである。（本実施形態のｗｅｂサーバ１１８の認証ｃｇｉ２０４とは別であることに注意されたい。）このように記載を分けている理由は、法人リンクテーブル２１７に記載されるリンクＵＲＬにはログイン画面のＵＲＬが記載されるのに対し、認証ｃｇｉのＵＲＬはログイン画面のログインボタン等を押すことによりアクセスが行われ、実質的な認証処理が行われることに起因する。

認証方式は、認証の方法が記入される。本実施形態ではＣｏｏｋｉｅ認証とＢＡＳＩＣ認証のいずれかの値が記入される。勿論、これらと認証の方法が異なる方式に対応する場合には、このフィールドに新たな値が追加されることとなる。
メソッドは、認証方式がＣｏｏｋｉｅ認証の場合における、ＩＤとパスワードの送信方法である。ＰＯＳＴメソッドとＧＥＴメソッドのいずれかである。
認証成功時のＵＲＬは、Ｃｏｏｋｉｅ認証の場合において、認証が成功した時にリダイレクトアクセスされるＵＲＬが記入される。これは認証の成功或は失敗の判断処理に用いられる。

以上説明したように、プロキシ認証テーブル２１９の各フィールドの内容は、ＨＴＴＰのアクセスの詳細な内容に深く立ち入る内容である。したがって、システム管理者等がこのフィールドの中身を記述することとなる。

再び図１５の説明に戻る。
認証方式がＣｏｏｋｉｅ認証であると判ると、ｗｅｂサーバ１１８のプロキシｃｇｉ２０９は、必要な情報を取得した後、ＵＲＬ文字列１３０３、つまり病院ｗｅｂサーバ１２０３のログインページにアクセスする（Ｓ１５０３）。
病院ｗｅｂサーバ１２０３はこれに呼応して、ログインページのｈｔｍｌ文書を送信する（Ｓ１５０４）。

次に、ｗｅｂサーバ１１８のプロキシｃｇｉ２０９は、ログインページのｈｔｍｌ文書の受信に呼応して、先にステップＳ１５０２においてプロキシ認証テーブル２１９の該当レコードから取得した（指定された）、病院ｗｅｂサーバ１２０３の認証ｃｇｉのＵＲＬに対し、サーバ用ＩＤとサーバ用パスワードを、指定されたメソッドで、認証ｃｇｉに送信する（Ｓ１５０５）。
病院ｗｅｂサーバ１２０３の認証ｃｇｉはこれを受けて認証処理を行う（Ｓ１５０６）。
認証が正常に行われると、病院ｗｅｂサーバ１２０３はＣｏｏｋｉｅと共にＨＴＴＰ転送メッセージを送信する（Ｓ１５０７）。

ｗｅｂサーバ１１８のプロキシｃｇｉ２０９はこのＨＴＴＰ転送メッセージを見る。
ＨＴＴＰメッセージヘッダ中にあるＵＲＬを見て、これがプロキシ認証テーブル２１９の該当レコードにおける、認証成功時のＵＲＬであるか否かを比較する。ＨＴＴＰメッセージヘッダ中にあるＵＲＬと認証成功時のＵＲＬが一致していれば、認証が成功したといえる。そこで、セッション情報ファイルに、プロキシ認証テーブル２１９の該当レコードのシリアルナンバーと、認証を行った旨のフラグと、ＨＴＴＰメッセージ中に含まれているＣｏｏｋｉｅを保存する（Ｓ１５０８）。

この時点で認証がなされたので、ｈｔｍｌ変換処理を開始する（Ｔ１５１０）。
そして、認証がＯＫであれば、受信したＨＴＴＰメッセージのヘッダに含まれている転送ＵＲＬにアクセスする（Ｓ１５０９）。

転送ＵＲＬのアクセスに病院ｗｅｂサーバ１２０３が呼応した結果、認証を正常に済ませた際に表示されるトップページのｈｔｍｌ文書が病院ｗｅｂサーバ１２０３から送信される（Ｓ１５１１）。
ｗｅｂサーバ１１８のｗｅｂクライアント２１０はこれを受信し、プロキシｃｇｉ２０９を通じてスプールディレクトリ２１２に蓄積する。
なお、このとき、ＨＴＴＰメッセージヘッダに含まれているＭＩＭＥ宣言を見て、「text/html」であれば、「<head>」タグ中に「<base href="...">」を埋め込む（Ｓ１５１２）。

ここで、図１６を参照して、ステップＳ１５１２の処理の内容を説明する。
図１６（ａ）及び（ｂ）は、プロキシｃｇｉ２０９によって変換処理が行われるｈｔｍｌ文書の内容を示す。ステップＳ１５１２及びＳ１５１８においてなされる処理である。
図１６（ａ）は、変換処理前のｈｔｍｌ文書である。つまり、病院ｗｅｂサーバ１２０３から受信した状態のｈｔｍｌ文書である。
図１６（ｂ）は、プロキシｃｇｉ２０９によって変換処理が行われた後のｈｔｍｌ文書である。図１６（ａ）の「<head>〜</head>」（以下「ＨＥＡＤタグ」）１６０１と比べると、ＨＥＡＤタグ１６０２内に「<base href="...">」（以下「ＢＡＳＥタグ」）１６０３が埋め込まれている。
この処理を行うと、相対的に記述されているＵＲＬの絶対位置が、追加したＢＡＳＥタグ１６０３によって変更される。つまり、画像データ等もｗｅｂサーバ１１８のプロキシｃｇｉ２０９を通じて取得することとなる。

図１６（ｂ）では、画像データのＵＲＬが相対的に記述されているタグが二つある。
ＢＯＤＹタグ１６０４はｈｔｍｌ文書の本文の始まりの宣言であり、この中の「background=」文字列以降に、背景画像を指定することができる。
ＩＭＧタグ１６０５はｈｔｍｌ文書中に画像を表示するタグである。
これらのデータの取得は、ＢＡＳＥタグ１６０３の存在により、ｗｅｂサーバ１１８のプロキシｃｇｉ２０９を通じて取得することとなる。

再び図１５に戻る。
変換処理が行われたｈｔｍｌ文書は、スプールディレクトリ２１２に一旦保存された後、クライアントＰＣ４０２に送信される（Ｓ１５１３）。

ステップＳ１５１４以降は、ユーザ認証が行われた以降の、プロキシｃｇｉ２０９の普遍的な動作を説明する。
ｈｔｍｌ文書の内容次第では、図１６にて示したように、画像データのＵＲＬが含まれている場合がある。その場合は、ｗｅｂブラウザ４０３が自動的にその取得を行う。或は、ユーザが自発的に表示されたｈｔｍｌ文書中のリンクをクリックする等で、アクセス要求を発する（Ｓ１５１４）。

ｗｅｂサーバ１１８のプロキシｃｇｉ２０９がクライアントＰＣ４０２からアクセス要求を受けると、アクセス要求の中に含まれているＣｏｏｋｉｅからセッション情報ファイル２１１を検索し、当該ユーザが目的とする病院ｗｅｂサーバ１２０３において認証処理を正常に済ませていることを知る。そこで、セッション情報ファイル２１１に保存されている、病院ｗｅｂサーバ１２０３のためのＣｏｏｋｉｅを用いて、病院ｗｅｂサーバ１２０３へのアクセス要求を行う（Ｓ１５１６）。
病院ｗｅｂサーバ１２０３はその要求を受け、ｈｔｍｌ文書或は画像データ等をｗｅｂサーバ１１８に送信する（Ｓ１５１７）。

ｗｅｂサーバ１１８のｗｅｂクライアント２１０はこれを受信し、プロキシｃｇｉ２０９に渡す。プロキシｃｇｉはＨＴＴＰメッセージヘッダのＭＩＭＥ宣言を確認し、ｈｔｍｌ文書であれば先に述べたＢＡＳＥタグ挿入処理を施し、ｈｔｍｌ文書でなければ何もせずにスプールディレクトリ２１２に一旦蓄積する（Ｓ１５１８）。
蓄積を完了したら、当該データファイルの中身をクライアントＰＣ４０２に送信する（Ｓ１５１９）。

図１７は、プロキシｃｇｉ２０９の全体動作のフローチャートである。
クライアントＰＣ４０２からの要求に呼応して、ｗｅｂサーバプログラム２０２からプロキシｃｇｉ２０９が起動されると（Ｓ１７０１）、最初にクライアントＰＣ４０２のリクエスト文字列から、病院ｗｅｂサーバ１２０３等にアクセスするＵＲＬを取得する（Ｓ１７０２）。
次に、このＵＲＬとユーザＩＤで検索を行い、当該ｗｅｂサーバにおいて既にユーザ認証は済んでいるか否かを確認する（Ｓ１７０３）。

もし、既に認証済みであれば、アクセスのメソッドがＰＯＳＴメソッドであれば（Ｓ１７０４）、ＰＯＳＴメソッドにてアクセスし、またこの時にクライアントＰＣ４０２から受信した文字列をそのまま指定ＵＲＬへ送信する（Ｓ１７０５）。或はＧＥＴメソッドであれば、ＧＥＴメソッドでアクセスする（Ｓ１７０６）。いずれの場合にも、病院ｗｅｂサーバ１２０３から所定のデータを受信する（Ｓ１７０７）。

なお、ステップＳ１７０５及びＳ１７０６は、認証方式によって病院ｗｅｂサーバ１２０３に出すアクセス要求の形式が異なる。
ＢＡＳＩＣ認証であれば、ＩＤとパスワードをＢａｓｅ６４エンコードした文字列を、アクセス要求（リクエスト）のヘッダに含める。
Ｃｏｏｋｉｅ認証であれば、Ｃｏｏｋｉｅをアクセス要求（リクエスト）のヘッダに含める。

受信の際に、ＨＴＴＰメッセージのヘッダを見て（Ｓ１７０８）、受信したデータがｈｔｍｌ文書であるか否かを、ＨＴＴＰメッセージヘッダ中の「Content-Type:」フィールドに記載されている、ＭＩＭＥ宣言で確認する（Ｓ１７０９）。

ＭＩＭＥ宣言が「text/html」であれば、受信したデータはｈｔｍｌ文書である。そこで、ｈｔｍｌ文書の「<head>〜</head>」タグ内に「<base href="...">」を埋め込む（Ｓ１７１０）。
なお、ＭＩＭＥ宣言が「text/html」でない場合は、このような処理をする必要はない（Ｓ１７０９のＮ）。
いずれにしろ、受信したデータはスプールディレクトリ２１２に一旦蓄積する（Ｓ１７１１）。そして、蓄積が完了したら、クライアントＰＣ４０２に送信して（Ｓ１７１２）、処理を終了する（Ｓ１７１３）。

ステップＳ１７０３で、ユーザ認証が済んでいないと判った場合は、ユーザ認証処理を行う（Ｓ１７１４）。
図１８は、そのユーザ認証処理の動作の流れを示すフローチャートである。
処理を開始すると（Ｓ１８０１）、プロキシｃｇｉ２０９は、先にＣｏｏｋｉｅからセッション情報ファイル２１１を通じて取得したユーザＩＤと、病院ｗｅｂサーバ１２０３のＵＲＬ文字列１３０３をキーにして、プロキシ認証テーブル２１９を検索し、該当するレコードを得る。そして、サーバ用ＩＤ、サーバ用パスワード、認証ｃｇｉのＵＲＬ、認証方式、メソッド、認証成功時のＵＲＬを取得する（Ｓ１８０２）。
次に、プロキシ認証テーブル２１９から取得した認証方式がＢＡＳＩＣ認証であるか否かを見る（Ｓ１８０３）。
ＢＡＳＩＣ認証であれば、ＢＡＳＩＣ認証用ログイン処理を行う（Ｓ１８０４）。
Ｃｏｏｋｉｅ認証であれば、Ｃｏｏｋｉｅ認証用ログイン処理を行う（Ｓ１８０５）。
いずれかのログイン処理が完了すると、処理を終了する（Ｓ１８０６）。

図１９は、Ｃｏｏｋｉｅ認証の動作の流れを示すフローチャートである。図１８のステップＳ１８０５の中身であり、図１５のステップＳ１５０２からＳ１５０９までの処理に該当する。
図１８のステップＳ１８０３にて、Ｃｏｏｋｉｅ認証と判断されると（Ｓ１９０１）、プロキシｃｇｉ２０９のパラメータとして記述されている、ＵＲＬ−ＰＡＴＨにて指定されたＵＲＬ（病院ｗｅｂサーバ１２０３のＵＲＬ）にアクセスする（Ｓ１９０２）。
程なくして、病院ｗｅｂサーバ１２０３からログイン用ｗｅｂページ（ｈｔｍｌ文書）が受信される（Ｓ１９０３）。
受信に呼応して、ステップＳ１８０２にて予め取得していた
・指定メソッド（ＧＥＴかＰＯＳＴか）、
・病院ｗｅｂサーバ１２０３にアクセスするためのユーザＩＤ、
・病院ｗｅｂサーバ１２０３にアクセスするためのパスワード、
・病院ｗｅｂサーバ１２０３の認証ｃｇｉ２０４のＵＲＬ
を用いて、病院ｗｅｂサーバ１２０３の認証ｃｇｉ２０４にアクセスし、指定メソッドにてユーザＩＤとパスワードを送信する（Ｓ１９０４）。
程なくして、病院ｗｅｂサーバ１２０３から転送メッセージ、つまりステータスコードが「３０２」或は「３０３」のＨＴＴＰメッセージを受信する（Ｓ１９０５）。
この転送メッセージのヘッダから、転送先ＵＲＬを取得して、それが認証成功時のＵＲＬであるか否かを判断する（Ｓ１９０６）。つまり、病院ｗｅｂサーバ１２０３の認証ｃｇｉ２０４における分岐処理である、認証結果を検証するのである。
もし、正常認証におけるＵＲＬであれば、そのＨＴＴＰメッセージのヘッダには必ずＣｏｏｋｉｅが含まれている。そこで、これをセッション情報ファイル２１１に記録する。また、認証が正常に行われた旨のフラグ情報も、セッション情報ファイル２１１に記録する（Ｓ１９０７）。そして、転送先ＵＲＬにアクセスして（Ｓ１９０８）、このサブルーチンの処理を終了する（Ｓ１９０９）。
もし、認証失敗におけるＵＲＬであれば、エラーメッセージをクライアントＰＣ４０２に送信し（Ｓ１９１０）、異常終了とする（Ｓ１９１１）。

図２０は、ＢＡＳＩＣ認証の動作の流れを示すフロー図である。
ＢＡＳＩＣ認証は正しいＩＤとパスワードをアクセス要求の一部であるリクエストヘッダに含めればよいので、Ｃｏｏｋｉｅ認証と比べると認証処理は単純になる。

クライアントＰＣ４０２がＵＲＬ文字列１３０２を用いてｗｅｂサーバ（プロキシサーバ）１１８のプロキシｃｇｉ２０９にアクセスする（Ｓ２００１）。
プロキシｃｇｉ２０９はクライアントＰＣ４０２のアクセス要求に含まれているＣｏｏｋｉｅを読み取り、アクセスしてきたユーザのユーザＩＤをセッション情報ファイル２１１から特定する。
次に、ＵＲＬ文字列１３０２からパラメータ（ＵＲＬ文字列１３０３）を抜き出す。
そして、セッション情報ファイル２１１を読み取り、当該ユーザが目的とする病院ｗｅｂサーバ１２０３において認証を済ませているか否かを見る。

ここで、未だに認証が行われていない状態であることを確認すると、ｗｅｂサーバ１１８のプロキシｃｇｉ２０９は、認証処理を開始する。
先に取得したユーザＩＤと、病院ｗｅｂサーバ１２０３のＵＲＬ文字列１３０３をキーにして、プロキシ認証テーブル２１９を検索し、該当するレコードを得る。そして、サーバ用ＩＤ、サーバ用パスワード、認証ｃｇｉのＵＲＬ、認証方式、メソッド、認証成功時のＵＲＬを取得する（Ｓ２００２）。
なお、認証方式がＢＡＳＩＣ認証の場合は、メソッドと認証成功時のＵＲＬの各フィールドは空である。

ステップＳ２００３以降は、プロキシｃｇｉ２０９の普遍的な動作を説明する。
ＩＤとパスワードをＢａｓｅ６４エンコードした文字列を、アクセス要求（リクエスト）のヘッダに含める（Ｓ２００３）。そして、病院ｗｅｂサーバ１２０３に送信する（Ｓ２００４）。
病院ｗｅｂサーバ１２０３はこれに呼応して、要求されたｗｅｂページのｈｔｍｌ文書を送信する（Ｓ２００５）。

ｗｅｂサーバ１１８のｗｅｂクライアント２１０はこれを受信し、プロキシｃｇｉ２０９に渡す。プロキシｃｇｉ２０９はＨＴＴＰメッセージヘッダのＭＩＭＥ宣言を確認し、ｈｔｍｌ文書であれば先に述べたＢＡＳＥタグ挿入処理を施し、ｈｔｍｌ文書でなければ何もせずにスプールディレクトリ２１２に一旦蓄積する（Ｓ２００６）。
蓄積を完了したら、当該データファイルの中身をクライアントＰＣ４０２に送信する（Ｓ２００７）。

これ以降は、上記と同様の処理が続く。
クライアントＰＣ４０２からｗｅｂサーバ１１８のプロキシｃｇｉ２０９へのアクセスは（Ｓ２００８）、ＩＤとパスワードをＢａｓｅ６４エンコードした文字列を、アクセス要求（リクエスト）のヘッダに含めて（Ｓ２００９）、病院ｗｅｂサーバ１２０３に送信する（Ｓ２０１０）。
病院ｗｅｂサーバ１２０３はその要求を受け、ｈｔｍｌ文書或は画像データ等をｗｅｂサーバ１１８に送信する（Ｓ２０１１）。
ｗｅｂサーバ１１８のｗｅｂクライアント２１０はこれを受信し、プロキシｃｇｉ２０９に渡す。プロキシｃｇｉはＨＴＴＰメッセージヘッダのＭＩＭＥ宣言を確認し、ｈｔｍｌ文書であれば先に述べたＢＡＳＥタグ挿入処理を施し、ｈｔｍｌ文書でなければ何もせずにスプールディレクトリ２１２に一旦蓄積する（Ｓ２０１２）。
蓄積を完了したら、当該データファイルの中身をクライアントＰＣ４０２に送信する（Ｓ２０１３）。

クライアントＰＣ４０２のＩＣカードリーダ４０５に載置してあったＩＣカード４０６が取り除かれると、ｗｅｂブラウザ４０３はｗｅｂサーバ１１８に対し、ログオフ処理を行う。
ログオフがなされると、セッション情報ファイル２１１と、これに付随して、病院ｗｅｂサーバ１２０３からダウンロードして、一時的にスプールディレクトリに蓄積されていたファイル群が削除される。
なお、必要に応じて、病院ｗｅｂサーバ１２０３に対するログオフ処理を実行するとよい。

本実施形態には、以下のような応用例が考えられる。
（１）クライアントＰＣ４０２のｗｅｂブラウザ４０３に代えて、Ｍａｃｒｏｍｅｄｉａ社のＳｈｏｃｋｗａｖｅ（登録商標）やＦｌａｓｈ（登録商標）、或はＪａｖａ（登録商標）アプレット等の技術が利用可能である。

（２）プロキシｃｇｉ２０９に代えて、ＡｐａｃｈｅのモジュールやＳｑｕｉｄ（http://www.squid-cache.org/）等、専用のプロキシサーバソフトウェアに本実施形態の認証機能を組み込むこともできる。

（３）図１７のステップＳ１７０４では、メソッドをＰＯＳＴとＧＥＴしか記述していないが、ＨＴＴＰのメソッドはこれ以外にも多々ある。他のメソッドは、その用途等に応じて、ＰＯＳＴ或はＧＥＴに準じた処理を施すこととなる。

病院ｗｅｂサーバ１２０３の認証方法は、Ｃｏｏｋｉｅ認証とＢＡＳＩＣ認証に限られない。ダイジェスト認証、ＨＴＴＰネゴシエーション等、認証方式に応じて多種多様な対応が考えられる。
同様に、本実施形態のｗｅｂサーバ１１８の認証方法も、多種多様なバリエーションが考えられる。

本実施形態においては、認証代行機能付プロキシサーバを開示した。
本実施形態によるプロキシサーバを用いることにより、多数のユーザ認証を要するｗｅｂサーバへのユーザ認証処理を、プロキシサーバが全て代行することができる。
ユーザはプロキシサーバにログインさえすれば、他のｗｅｂサーバに透過的にアクセスできるので、他のｗｅｂサーバのＩＤ及びパスワードの維持管理をせずに済む。
更に、プロキシサーバがユーザのアクセス権限を制御することにより、ユーザに他のｗｅｂサーバのアクセスを許可するか否かを制御できる。

以上、本発明の実施形態例について説明したが、本発明は上記実施形態例に限定されるものではなく、特許請求の範囲に記載した本発明の要旨を逸脱しない限りにおいて、他の変形例、応用例を含むことは言うまでもない。

本発明の一実施の形態による医業ＳＮＳサービスシステムの全体を示す概略図である。 ｗｅｂサーバの機能的な構成を示すブロック図である。 ｗｅｂサーバの各テーブルのフィールドを示す図である。 クライアントＰＣの機能ブロック図である。 ｗｅｂサーバとクライアントＰＣとの間で行われる、ユーザ認証から表示ｃｇｉによるトップページを表示するまでの動作の流れを示すフロー図である。 クライアントＰＣの、ユーザ認証から表示ｃｇｉによるトップページを表示するまでの動作の流れを示すフローチャートである。 ｗｅｂサーバの、認証ｃｇｉの動作の流れを示すフローチャートである。 ｗｅｂサーバの、表示ｃｇｉの動作の流れを示すフローチャートである。 表示ｃｇｉにおけるｈｔｍｌ文書を作成する動作の流れを示すフローチャートである。 表示ｃｇｉが生成するｈｔｍｌ文書を、クライアントＰＣのｗｅｂブラウザによって表示した、表示画面を示す。 医療法人リンク欄の表示例を示す。 本実施形態によるｗｅｂサーバの特徴的な機能の一つである、プロキシサーバ機能を説明する全体概略図である。 プロキシｃｇｉによるＵＲＬの変換処理の仕組みを説明する概略図である。 プロキシｃｇｉの機能を示すブロック図である。 病院ｗｅｂサーバにおいてアクセスしたい対象となるｗｅｂページがＣｏｏｋｉｅ認証を必要とする場合における、クライアントＰＣと、プロキシｃｇｉと、病院ｗｅｂサーバの動作の流れを示すフロー図である。 プロキシｃｇｉによって変換処理が行われるｈｔｍｌ文書の内容を示す。 プロキシｃｇｉの全体動作のフローチャートである。 ユーザ認証処理の動作の流れを示すフローチャートである。 Ｃｏｏｋｉｅ認証の動作の流れを示すフローチャートである。 ＢＡＳＩＣ認証の動作の流れを示すフロー図である。

符号の説明

１０１…医業ＳＮＳサービスシステム、１０２…総合病院、１０３…院内ＬＡＮ、１０４、１１２、１２０２…医師、１０５、１１３…看護師、１０６…事務担当者、１０７、１０８、１０９、１１１、１１５、４０２…クライアントＰＣ、１１０…開業医、１１４…卸業者、１１６…営業担当者、１１７…インターネット、１１８…ｗｅｂサーバ、２０２…ｗｅｂサーバプログラム、２０３…暗号化モジュール、２０４…認証ｃｇｉ、２０５…ユーザテーブル、２０６…表示ｃｇｉ、２０７…ユーザ登録ｃｇｉ、２０８…法人登録ｃｇｉ、２０９…プロキシｃｇｉ、２１０…ｗｅｂクライアント、２１１…セッション情報ファイル、２１２…スプールディレクトリ、２１３…ユーザ属性テーブル、２１４…ユーザ属性マスタ、２１５…法人テーブル、２１６…法人種別マスタ、２１７…法人リンクテーブル、２１８…リンクアクセス許可属性テーブル、２１９…プロキシ認証テーブル、２２０…ユーザページ構成テーブル、４０３…ｗｅｂブラウザ、４０４…ディスプレイ、４０５…ＩＣカードリーダ、４０６…ＩＣカード、４０７…ＩＣカードリーダドライバ、４０８…セキュリティ担保機能部、４０９…暗号化モジュール、１００１…表示画面、１００２…法人表示欄、１００３、１００４…医療法人リンク欄、１００５…卸業者リンク欄、１００６…全体情報リンク欄、１００７…法人向け情報表示欄、１００８…ＳＮＳリンクボタン、１００９、１０１０…スクロールボタン、１２０３…病院ｗｅｂサーバ、１３０２…ＵＲＬ文字列、１３０３…ＵＲＬ文字列、１４０２…アクセス要求受信部、１４０３…ユーザ特定及び認証確認部、１４０４…認証部、１４０５…アクセス要求変換部、１４０６、１４０７、１４０８…リクエスト、１４０９…ｈｔｍｌ文書書換部、１４１０…ヘッダ解析部、１６０２…ＨＥＡＤタグ、１６０３…ＢＡＳＥタグ、１６０４…ＢＯＤＹタグ、１６０５…ＩＭＧタグ

Claims (4)

1. クライアントから発せられる、外部サーバのＵＲＬと第１のユーザ認証情報を含む第１のアクセス要求を受信するアクセス要求受信部と、
   前記第１のユーザ認証情報に基づいて前記ユーザを特定すると共に、前記ユーザが前記外部サーバにおいてユーザ認証を行ったか否かを確認するユーザ特定及び認証確認部と、
   前記ユーザ特定及び認証確認部の確認結果に基づいてユーザ認証を実行し、前記外部サーバのアクセス要求に用いる第２のユーザ認証情報を生成する認証部と、
   前記外部サーバのＵＲＬに基づいて前記第２のユーザ認証情報を含む第２のアクセス要求を前記外部サーバに送信するクライアント部と、
   前記クライアント部が前記外部サーバから受信したデータを書き換える書換部と
   を具備することを特徴とする代理サーバ。
2. 前記外部サーバはｗｅｂサーバであり、
   前記クライアント部は前記ｗｅｂサーバからｈｔｍｌ文書を受信するｗｅｂクライアントであり、
   前記書換部は前記クライアント部が受信したｈｔｍｌ文書に所定のタグを挿入して前記クライアントに送信することを特徴とする、請求項１記載の代理サーバ。
3. コンピュータを、
   クライアントから発せられる、外部サーバのＵＲＬと第１のユーザ認証情報を含む第１のアクセス要求を受信するアクセス要求受信部と、
   前記第１のユーザ認証情報に基づいて前記ユーザを特定すると共に、前記ユーザが前記外部サーバにおいてユーザ認証を行ったか否かを確認するユーザ特定及び認証確認部と、
   前記ユーザ特定及び認証確認部の確認結果に基づいてユーザ認証を実行し、前記外部サーバのアクセス要求に用いる第２のユーザ認証情報を生成する認証部と、
   前記外部サーバのＵＲＬに基づいて前記第２のユーザ認証情報を含む第２のアクセス要求を前記外部サーバに送信するクライアント部と、
   前記クライアント部が前記外部サーバから受信したデータを書き換える書換部
   を有する代理サーバとして機能させるためのプログラム。
4. クライアントから発せられる、外部サーバのＵＲＬと第１のユーザ認証情報を含む第１のアクセス要求を受信するステップと、
   前記第１のユーザ認証情報に基づいて前記ユーザを特定すると共に、前記ユーザが前記外部サーバにおいてユーザ認証を行ったか否かを確認するステップと、
   前記ユーザ認証を行ったか否かを確認するステップの確認結果に基づいてユーザ認証を実行し、前記外部サーバのアクセス要求に用いる第２のユーザ認証情報を生成するステップと、
   前記外部サーバのＵＲＬに基づいて前記第２のユーザ認証情報を含む第２のアクセス要求を前記外部サーバに送信するステップと、
   前記外部サーバから受信したデータを書き換えるステップと
   を含むことを特徴とする代理アクセス方法。

Images