JPH113307A

JPH113307A - 情報処理装置および方法

Info

Publication number: JPH113307A
Application number: JP9156938A
Authority: JP
Inventors: Akiya Nakai; 晶也中井; Takeshi Baba; 健馬場; Hideji Yamoto; 秀治八本; Masahiko Shirai; 昌彦白井; Tokuko Kanda; 都孔子神田
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 1997-06-13
Filing date: 1997-06-13
Publication date: 1999-01-06
Also published as: US6253248B1

Abstract

(57)【要約】【課題】多くの種類のプロトコルをクライアントに対し
て中継することを可能とし、クライアントが簡単な操作
で複数箇所に存在する情報を取得可能とする。【解決手段】クライアントとサーバの経路中に存在し、
両者の通信を仲介するプロクシサーバの機能を備えた情
報処理装置において、クライアントよりHTTPにてリクエ
ストを受信すると（ステップS301）、そのリクエストに
基づいてサーバが特定され、特定されたサーバとの間で
採用すべき通信形態が決定される。ここでCMプロトコル
に決定されると、当該リクエストが要求する処理種類が
判別され（ステップS302、S306）、前記リクエストに含
まれる要求内容を実現するために、必要な情報を付加し
て、CMプロトコルに適応したリクエストデータが生成さ
れてサーバへ送信される（ステップS306〜S309）。そし
て、当該リクエストによる処理の結果をHTTPでクライア
ントへ返信する（ステップS310）。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、コンピュータネッ
トワーク上でクライアント・サーバ形式で稼働するシス
テムの、クライアントとサーバのデータ経路中に介在
し、クライアントからのリクエストをサーバに仲介する
プロクシサーバとして機能する情報処理装置およびその
方法に関するものである。

【０００２】

【従来の技術】一般に、クライアントとサーバのデータ
経路に介在するプロクシサーバとして、佐藤豊氏作のde
legatedが知られている。delegatedは、一般の匿名ＦＴ
Ｐサイトから ftp://etlport.etl.go.jp/pub/DeleGate/ というＵＲＬで誰でも入手可能なプログラムである（Ｕ
ＲＬとは、Uniformity Resource Locatorsのことで、そ
の詳細はＲＦＣ−１７３８の資料に記述されている。ま
た、ＲＦＣ−番号の資料とは、Internet Architecture
Boardにて公開されている資料のことである）。

【０００３】このようなプロクシサーバは、近年広く使
用されるようになったネットワーク上のシステム、Worl
d Wide Webシステムの登場により、ＷｅｂブラウザとＷ
ｅｂサーバとのやり取りを中継するための有効な手段と
なっている（なお、Ｗｅｂブラウザとは、World Wide W
ebシステムのクライアントプログラム、Ｗｅｂサーバ
とは同システムのサーバプログラムのことを指す）。

【０００４】このような既存のプロクシサーバは、その
主な目的が、直接エンドユーザのコンピュータからのフ
ァイウォールアクセスを制限し、セキュリティ管理を容
易にするためのものであった。そのため、その主な機能
は、純粋にクライアントからのリクエストを最終的なサ
ーバに中継するだけのものであり、プロクシサーバ自身
はデータの内容を変更しないのが普通である。

【０００５】しかしながら、ある種のプロクシサーバで
は、単にクライアント、サーバ間のデータのやり取りを
中継するだけでなく、ある種のデータ変換も行ってい
る。

【０００６】そのような変換に、例えば、漢字コードの
変換がある。現在各種のコンピュータ上で用いられてい
る漢字コードには数種類のものがあり、複数のサーバ上
に散在している資源（ファイル）に用いられている漢字
コードが全て同じ種類のコードで書かれているとは限ら
ない。そこで、ある種のプロクシサーバでは、自身が仲
介しているサーバから取得したファイル中の漢字コード
を認識し、これをクライアントに返送する際には（クラ
イアントにとって都合の良い）どれか一つの漢字コード
に変換して返送することなどが行われている。

【０００７】また、プロトコル変換を行うプロクシサー
バもある。例えば前述のdelegatedは、クライアントと
のやり取りはＨＴＴＰプロトコル（Hypertext Transfer
Protcol、Internet Engineering Task ForceのInterne
t Draftにその詳細が記述されている）にて行うが、ク
ライアントからのリクエストに含まれるＵＲＬ中のデー
タを元に、対象となるサーバが使用しているプロトコル
を判定し、そのサーバのプロトコルを用いてクライアン
トからのリクエストを満たすアクセスを行う。実際の例
として、delegatedは、ＨＴＴＰプロトコルからＦＴＰ
プロトコル（File Transfer Protocol、ＲＦＣ−９５９
に詳細が記述されている）へのプロトコル変換を行って
いる。

【０００８】このようにクライアントに接続されている
プロクシサーバがプロトコル変換を行ってサーバとの通
信を行うので、クライアント側としては実際のサーバの
プロトコルによらず統一的な処理ができ、ひいてはユー
ザに対しても統一的使用感を与えることができる。これ
はプロクシサーバを使用することの利点である。

【０００９】

【発明が解決しようとする課題】しかし、上述のデータ
変換、プロトコル変換においては、ともにクライアント
・サーバ間でのデータのやり取りの間におけるデータの
形式上の変換があるだけであり、新たな情報の付加など
は行なわれない。すなわち情報的には単にクライアント
・サーバ間の中継をしているのみである。

【００１０】そのため、ある種のサーバがサポートする
プロトコルに対して、クライアントからのリクエストだ
けではサーバに対するリクエストを発するための情報が
不足する場合があり、データ変換・プロトコル変換が不
可能となり、そのようなプロトコルを持つサーバを統一
的にクライアント側からアクセス可能なようにすること
はできなかった。

【００１１】また、従来のプロクシサーバは、クライア
ントからのリクエストを満たすためにどのサーバと接続
するかを決定するための特別なロジックを持っていなか
った。すなわち、プロクシサーバは、単にクライアント
からのリクエストに記述されているサーバに対してアク
セスするのみであった。

【００１２】このため、クライアントからのリクエスト
に対して、そのリクエストを満たす情報がそのサーバの
みにあるような場合はそれで問題はないが、リクエスト
に対する情報が複数の箇所に分散、あるいは複数の箇所
のうちのどこかにある、という場合には、クライアント
を操作しているユーザ自身が、それら複数の場所にアク
セスして最も望む情報を得なくてはならなかった。

【００１３】本発明は、上記問題に鑑みてなされたもの
であり、プロトコル変換に際して必要な情報がクライア
ントよりのリクエストに含まれていない場合でも、適切
な情報付加を行ってプロトコル変換を行うことを可能と
するプロクシサーバ機能を有する情報処理装置および方
法を提供することを目的とする。

【００１４】また、本発明の他の目的は、クライアント
からのリクエストを満たす情報がどのサーバ（またはシ
ステム）にあるかを、ユーザの操作無しに、自動的に決
定可能とすることにある。

【００１５】

【課題を解決するための手段】上記の目的を達成するた
めの本発明の情報処理装置は以下の構成を備えている。
すなわち、クライアントとサーバの経路中に存在し、両
者の通信を仲介するプロクシサーバの機能を備えた情報
処理装置であって、クライアントより第１の通信形態で
受信したリクエストに基づいてサーバを特定する特定手
段と、前記特定手段で特定されたサーバとの間で採用す
べき通信形態を第２の通信形態として決定する決定手段
と、前記リクエストに含まれる要求内容を実現するため
に、必要な情報を付加して前記第２の通信形態に適応し
たリクエストデータを生成する生成手段と、前記生成手
段で生成されたリクエストデータ前記特定手段で特定し
たサーバへ送信する送信手段とを備える。

【００１６】また、上記の目的を達成する本発明の情報
処理方法は、クライアントとサーバの経路中に存在し、
両者の通信を仲介するプロクシサーバの機能を実現する
情報処理方法であって、クライアントより第１の通信形
態で受信したリクエストに基づいてサーバを特定する特
定工程と、前記特定工程で特定されたサーバとの間で採
用すべき通信形態を第２の通信形態として決定する決定
工程と、前記リクエストに含まれる要求内容を実現する
ために、必要な情報を付加して前記第２の通信形態に適
応したリクエストデータを生成する生成工程と、前記生
成工程で生成されたリクエストデータ前記特定工程で特
定したサーバへ送信する送信工程とを備える。

【００１７】

【発明の実施の形態】以下、添付の図面を参照して本発
明の好適な実施形態を説明する。

【００１８】＜実施形態の概要＞図１は本実施形態によ
るプロクシサーバの機能構成を示すブロック図である。
同図に示されるように、本実施形態のプロクシサーバ１
００は、クライアントとの直接のデータ授受を行う送受
信部１０１と、クライアントからのリクエスト満たすた
めにサーバとデータ授受を行うリクエスト解析・実行部
１０２とを備える。また、ユーザコンテキスト保持部１
０４は、ユーザが本プロクシサーバ１００に対して行っ
た情報を記憶しておく。設定ウインドウ制御部１０６
は、プロトコル変換において不足する情報をユーザに入
力してもらうための設定ウィンドウの表示や、当該ウイ
ンドからの入力等を制御する。これらユーザコンテキス
ト保持部１０４や設定ウインドウ制御部１０６、後述の
ローカルディスク１０８などは、プロトコル変換におい
て不足する情報を入手するための手段として使用され
る。

【００１９】また、図１において、クライアント１０７
は、プロクシサーバ１００へリクエストを発するクライ
アントプログラム、ローカルディスク１０８は、クライ
アントプログラムが起動、または表示されているコンピ
ュータ上のハードディスク等の外部記憶装置である。サ
ーバＡ１０９、サーバＢ１１０はプロクシサーバがリク
エストを仲介する個々のサーバである。

【００２０】図１におけるプロクシサーバの概略動作を
説明すると以下のようになる。まず、クライアント１０
７からのリクエストを送受信部１０１が受信すると、リ
クエストはリクエスト解析・実行部１０２に渡される。
リクエスト解析・実行部１０２は、当該リクエストの送
信先となるサーバがサポートしているプロトコルを判定
し、必要ならプロトコル変換を施す。

【００２１】この際、クライアントからのリクエストに
含まれる情報のみでは対象となるサーバがサポートする
プロトコルへの変換が不可能な場合がある。このような
場合には、ユーザコンテキスト保持部１０４やローカル
ディスク１０８上の情報などを読み出し、あるいは設定
ウインドウ制御部１０６がクライアント１０７のディス
プレイ上に設定ウィンドウ１０６を提示して、ユーザに
必要な情報を入力させることでプロトコル変換に必要な
情報を収集する。

【００２２】またリクエスト解析・実行部１０２は、ク
ライアントからのリクエストを直接サーバに出す前に、
そのサーバにそのリクエストを満たす能力（資源）があ
るかどうかや、その資源の状態を問い合わせ、最も良く
クライアントからのリクエストを満たせるサーバ、また
はシステムを決定する。

【００２３】以上のようにしてリクエスト解析・実行部
１０２は、必要な情報と、実際のリクエスト先を特定し
てリクエストを出し、そこからの返信を受け取る。ま
た、リクエスト解析・実行部１０２は、リクエスト先か
ら返信された情報に、さらに別の情報を付加して送受信
部１０１に送り、送受信部１０１はクライアント１０７
にデータを返信する。

【００２４】これらの過程で、後の処理に必要な情報
は、リクエスト解析・実行部１０２が、ユーザコンテキ
スト保持部１０４に記録しておく。

【００２５】＜第１の実施形態＞第１の実施形態では、
図１のプロクシサーバ１００が、クライアント１０７と
２種類のサーバ１０９，１１０の間に入り、クライアン
ト１０７側から２つのサーバにアクセスする場合を説明
する。なお、図１で説明したユーザコンテキスト保持部
１０４は第２の実施形態で用いるものであり、第１の実
施形態では使用しないので省略してもかまわない。

【００２６】また、クライアント１０７としては、一般
に市販されているＷｅｂブラウザ（例えばNetscape Com
munications Corporation社製のNetscape Navigator
（商標）など）を用いる。サーバＡ１０９としては、一
般に使用されているＷｅｂサーバ（例えばＣＥＲＮ製の
ｈｔｔｐｄサーバ（商標））を利用する。更にサーバＢ
１１０としては、ファイルの構成管理システムのサーバ
として、Hewlett Packard社製の製品SoftBench CM（商
標）のサーバを用いる。

【００２７】SoftBench CMは、クライアントサーバ形式
で稼働する、ファイルの保管・リビジョン管理システム
で、・クライアントマシンからのファイルのチェックイン
（サーバ上にファイルの保管、あるいはファイル内容の
変更の登録を行う）・サーバマシンからファイルのチェックアウト（サーバ
上に保管されているファイルをクライアントマシンに取
り出す）・サーバマシンのファイルリスト取得（どのようなファ
イルが保管されているかや、どのファイルが修正のため
にチェックアウトされているかの情報を得る）などを行うクライアント側のコマンドプログラムが用意
されている。これら各機能の詳細は、Hewlett Packard
社刊の“C/C++SoftBenchユーザーズガイド”の２−２２
ページに記述されている。

【００２８】図２は、第１の実施形態による情報処理シ
ステムの全体構成を示す図である。ネットワーク上に、
クライアントマシン２０１、ＷＷＷサーバマシン２０
６、ファイル管理サーバマシン２０７が接続され、それ
ぞれＩＰ(Internet Protocol)により通信可能である。

【００２９】上述のクライアント１０７および、プロク
シサーバ１００のプログラムは、クライアントマシン２
０１の外部記憶装置２０４中に格納され、メモリ２０３
にロードされ、ＣＰＵ２０２により実行される。なお、
図１のローカルディスク１０８が、図２の外部記憶装置
２０４に対応する。クライアント１０７の表示ウィンド
ウ等はディスプレイ２０５上に表示され、プロクシサー
バの設定ウィンドウ表示部１０６もディスプレイ２０５
上に設定ウインドウを表示する。

【００３０】なお、本例ではこのようにクライアント１
０７とプロクシサーバ１００が同一のマシン上（クライ
アントマシン２０１上）で稼働しているが、それぞれ別
のマシンであっても構わない。

【００３１】後述するように、プロクシサーバ１００自
身がクライアントマシン２０１のディスプレイ２０５や
外部記憶装置２０４にアクセスする場合があるが、その
ような場合、クライアントマシン上のX Window System
のサーバや、ＮＦＳ(NetworkFile System)サーバ、ＦＴ
Ｐ(File Transfer Protocol)サーバのような、ネットワ
ークと透過なサーバ（ネットワーク上の何処か離れたと
ころにあっても、自分のマシンの中にあっても、場所を
意識せず居同じ形態で利用できるサーバ）とのやり取り
により、外部のマシンから直接ディスプレイ２０５や外
部記憶装置２０４にアクセス可能であり、これらにより
本実施形態に記述された内容は実行可能である。

【００３２】図１のサーバＡ１０９および、サーバＢ１
１０は、ネットワーク上のコンピュータである、ＷＷＷ
サーバマシン２０６および、ファイル管理サーバマシン
２０７上でそれぞれ稼働している。ここで、これら２つ
のコンピュータのマシン名（ＩＰアドレスに変換可能な
名前、いわゆるホスト名）をそれぞれ「ＷＷＷ」，「Ｃ
Ｍ」と定めておく。これらのコンピュータはそれぞれ別
のものである必然性はなく、同一のマシンであっても構
わない。

【００３３】なお、以下の説明ではサーバＡ１０９で稼
働しているＷｅｂサーバを単にＷｅｂサーバ、サーバＢ
１１０で稼働しているSoftBench CMサーバをＣＭサー
バ、クライアントマシン２０３で稼働しているＷｅｂブ
ラウザを単にＷｅｂブラウザと略称する。

【００３４】いま、Ｗｅｂサーバ、ＣＭサーバ、Ｗｅｂ
ブラウザともに、それぞれのマシンで稼働していると
し、また、本プロクシサーバ１００は、Ｗｅｂブラウザ
を起動したユーザにより起動されているものとする。な
お、Ｗｅｂブラウザには、自身が発行するリクエストの
送り先を、直接最終的なサーバにするのではなく、プロ
クシサーバを介して送るように設定することが可能であ
る。したがって、本実施形態のｗｅｂブラウザにおいて
は、プロクシサーバ１００を介してリクエストを発行す
るよう設定しておくものとする。

【００３５】この状態で、ユーザがＷｅｂブラウザ上で
操作をしてリクエストがプロクシサーバ１００に送られ
てきた場合の、プロクシサーバ１００の処理を説明す
る。図３は第１の実施形態によるプロクシサーバの制御
手順を説明するフローチャートである。以下、説明文
中、Ｓ３０１〜Ｓ３１０は図３の各処理を示す。

【００３６】プロクシサーバ１００は、ステップＳ３０
１において、送受信部１０１により、クライアント１０
７からのリクエストを受信する。次にこのリクエストを
元に、リクエスト解析実行部１０２がＷｅｂブラウザに
返送するデータを作成し（ステップＳ３０２〜Ｓ３０
４，Ｓ３０６〜Ｓ３０９の各処理）、作成されたデータ
を送受信部１０１がＷｅｂブラウザに返送する（ステッ
プＳ３０５，Ｓ３１０の処理）。

【００３７】以下、ステップＳ３０２以降の処理を詳細
に説明する。

【００３８】Ｗｅｂブラウザからの受信データはＨＴＴ
Ｐプロトコルに従った次のような形式になっている。

【００３９】［メソット名］［プロトコル名］：／／
［サーバマシン名］：［サーバポート番号］／［資源
名］［プロトコルバージョン］［付随情報］……例えばステップＳ３０１で受信したリ
クエストが GET http://WWW:80/abc/def/xxx.html HTTP/1.0 …… であれば、メソッド名 GET プロトコル名 http サーバマシン名 WWW サーバポート番号 80 資源名 /abc/def/xxx.html プロトコルバージョン HTTP/1.0 となる。

【００４０】また、本プロクシサーバは、マシン名・プ
ロトコル対応表１０３を持っている。この表は、サーバ
マシン名（あるいはＩＰアドレス）とサーバポート番号
と、そのサーバが実際にサポートしているプロトコルの
対応表である。

【００４１】図４は第１の実施形態によるマシン名・プ
ロトコル対応表の一例を示す図である。以下、図４のよ
うな対応表を持っているとして説明をする。

【００４２】ステップＳ３０２では、上記のリクエスト
中のサーバマシン名とサーバポート番号とマシン名・プ
ロトコル対応表１０３から、そのサーバが実際にサポー
トしているプロトコルを判定する。

【００４３】今回の例では、サーバマシン名 WWW サーバポート番号 80 であるが、このような組合せは図４の表には記述されて
いない。そのため、この表からプロトコルを決定するこ
とができずない。すなわち、クライアントからのリクエ
ストに記述されているプロトコルを対応表によって決定
することはできないので、クライアントからのリクエス
トに記述されているプロトコル名"http"によって、リク
エスト先のサーバとの通信に用いるプロトコルを決定す
る。従って、ここでは、プロトコルはＨＴＴＰプロトコ
ルに決定される。

【００４４】リクエスト中のプロトコル名と、実際のプ
ロトコルとの対応は、文献ＲＦＣ−１７３８(Uniformit
y Resource Locator)に記述されており、一般に知られ
ている情報であり、この情報を元に、"http"はＨＴＴＰ
プロトコルに対応すると判定される。

【００４５】さて、ＨＴＴＰプロトコルと判定された場
合はステップＳ３０３の処理へと進む。ＨＴＴＰプロト
コルは、Ｗｅｂブラウザから送られてきたプロトコルと
同一なので、本プロクシサーバは格別の処理をせずに、
ただ単にクライアントからのリクエストをサーバに取り
次ぎ、サーバからのデータをクライアントへ取り次ぐだ
けである。即ち、ステップＳ３０３で、クライアントか
らのリクエストをそのままＷｅｂサーバに送り、ステッ
プＳ３０４で、サーバからの返信データを受け取り、ス
テップＳ３０５でそれをそのままＷｅｂブラウザに送
る。このような処理は、既にある一般のプロクシサーバ
の行っている処理と何ら変わらない。

【００４６】次に、例えばステップＳ３０１で受信され
たリクエストが、 GET ftp://WWW:21/abc/def/xxx.html HTTP/1.0 …… であった場合、ステップＳ３０２の処理ではプロトコル
はＦＴＰ(File TransferProtocol)であると判定され、
本プロクシサーバはＨＴＴＰプロトコルとＦＴＰプロト
コルのプロトコル変換を行うことになるが、これも一般
のプロクシサーバが行う処理と何ら変わらないので、本
実施形態の説明からは割愛する。

【００４７】次に、ステップＳ３０１で受信されたリク
エストが、 GET http://CM:80/abc/def HTTP/1.0 …… であった場合の処理を説明する。このリクエストは、前
述の通り、メソッド名 GET プロトコル名 http サーバマシン名 CM サーバポート番号 80 資源名 /abc/def プロトコルバージョン HTTP/1.0 と解釈される。

【００４８】ステップＳ３０２では、図４に示すマシン
名・プロトコル対応表から、サーバマシン名 CM サーバポート番号 80 のサーバがサポートしているプロトコルがＣＭプロトコ
ルであると判定する。

【００４９】ＣＭプロトコルというプロトコル名は一般
的な名称ではないが、Hewlett Packard社製の製品SoftB
ench CMのクライアント・サーバ間通信で使用されるプ
ロトコルのことを指す。このプロトコルに一般的名称が
付けられていないので、ここでは説明のためにＣＭプロ
トコルと呼ぶことにする。

【００５０】ステップＳ３０２でＣＭプロトコルと判定
された場合、処理はステップＳ３０６〜３１０ヘ進み、
ＨＴＴＰとＣＭプロトコルの変換や、情報付加等を行
う、本実施形態の特徴的な処理にはいる。

【００５１】ステップＳ３０６では、リクエスト中の
「資源名」から、ＣＭサーバに実行させたい処理の種類
を判別する。このような処理の種類の判別のために、Ｃ
Ｍサーバに対するリクエストの資源名は操作対象名？処理名であることと決めておき、文字「？」の後ろの部分を処
理の種類判別に使うことにする。本例では、資源名は、
「/abc/def」であり、処理名が特に指定されていない。
このような場合は、「データ取得処理」であると判定
し、ステップＳ３０７へと進む。

【００５２】図５はデータ取得処理（ステップＳ３０
７）の詳細な制御手順を説明するフローチャートであ
る。以下、図５を参照してステップＳ３０７のデータ取
得処理を説明する。

【００５３】まず、ステップＳ５００でプロクシサーバ
１００は、ＣＭサーバに対してファイルリスト取得コマ
ンドを用いて、「/abc/def」という名前のファイル、ま
たはディレクトリがサーバ中にあるかどうかを確認す
る。このコマンドの返り値より上記の名前のものが、 ●サーバ上のディレクトリである。 ●サーバ上のファイルであり、修正目的でチェックアウ
トされていない。 ●サーバ上のファイルであり、ユーザにより既に修正目
的でチェックアウトされている。 ●サーバ上にはない。のどれであるかが判明する。そして、ステップＳ５０
１、ステップＳ５０２，Ｓ５０４の分岐処理により、上
記判定結果のそれぞれに対応して ●ステップＳ５０３ ●ステップＳ５０５ ●ステップＳ５０６ ●ステップＳ５０７へと処理が進むことになる。

【００５４】ここでは「/abc/def」がサーバ上のディレ
クトリ名であったとして、ステップＳ５０３の処理を説
明する。

【００５５】ステップＳ５０３では、ファイルリスト取
得コマンドを用いて、ＣＭサーバ上のディレクトリ「/a
bc/def」の下にあるファイル・ディレクトリ名の一覧を
得る。このコマンドにより、例えばこのディレクトリの
下には、 xxx.html， yyy.html， zzz.html の３ファイルがあることが分かったとする。すると、図
６に示すようなＨＴＭＬ言語で記述されたテキストファ
イルを作成する。図６は第１の実施形態においてプロク
シサーバで作成されるファイルリストデータの一例を示
す図である。なお、ＨＴＭＬ言語とはHypertext Markup
Languageのことで、Ｗｅｂブラウザなどに文書を表示
させるための一般的な言語であり、その詳細はＲＦＣ−
１８６６などの文献に詳述されている。

【００５６】このあと図３のステップＳ３１０の処理に
移り、図６のテキストファイルの内容は送受信部１０１
によりＷｅｂブラウザに返信されることとなる。この内
容をＷｅｂブラウザが受け取ると、Ｗｅｂブラウザの文
書表示画面上には図７のような内容が表示されることに
なる。図７は、図６のテキストファイルをＷｅｂブラウ
ザで表示した状態を示す図である。

【００５７】図中下線のある部分はハイパーリンクのあ
る部分を示しており、Ｗｅｂブラウザ画面上でその部分
を指示した場合には、新たなリクエストがプロクシサー
バ１００に送られることになる。これについては後述す
る。以上のようにして、ステップＳ３１０が終わると処
理は再びステップＳ３０１に戻り、クライアントからの
次のリクエストを待つことになる。

【００５８】なお、ステップＳ５０３でＣＭサーバに対
して用いたファイルリストコマンドは、そのコマンド内
でＣＭサーバと特定のプロトコル（本文でいうところの
ＣＭプロトコル）でデータ通信を行っている。従って、
上述のステップＳ３０６〜Ｓ３１０の処理はＨＴＴＰと
ＣＭプロトコルのプロトコル変換を行ったことになる。

【００５９】次に、図７の如く表示がなされているＷｅ
ｂブラウザで、ユーザがxxx.htmlの内容を読みたくなっ
た場合の処理を説明する。このような場合、ユーザは画
面上のxxx.htmlと表示されている部分を、通常マウスな
どのポインタデバイスを用いて指示する。

【００６０】通常のＷｅｂブラウザはこのようにハイパ
ーリンクとなっている部分を指示されると、新たなリク
エストをサーバに対して発行する。この例の場合である
と、xxx.htmlと表示されている部分はＨＴＭＬ言語の <
A HREF="//CM:80/abc/def/xxx.html"> なる記述によ
り、//CM:80/abc/def/xxx.htmlというサーバ名、ポート
番号、資源名にリンクされている。すなわち、上記操作
によってＷｅｂブラウザが発行してくるリクエストは、 GET http://CM:80/abc/def/xxx.html HTTP/1.0 となり、これがステップＳ３０１で受信されることにな
る。

【００６１】ここから先、ステップＳ３０２，Ｓ３０６
を経てステップＳ５０１に至るまでは上述の例と同じで
ある。ステップＳ５０１では、資源名/abc/def/xxx.htm
lがＣＭサーバ上にあるかどうかなどの情報を判定する
が、今回の例では、/abc/def/xxx.htmlは、「サーバ上
のファイルであり、修正目的でチェックアウトされてい
ない」であったとする。

【００６２】すると、処理はステップＳ５０５に進む。
ステップＳ５０５ではＣＭサーバに対して、チェックア
ウトコマンドを用いて、ＣＭサーバ上の「/abc/def/xx
x.html」ファイルを取得する。取得したファイルをステ
ップＳ３１０でＷｅｂブラウザに返信すると、Ｗｅｂブ
ラウザ上には「/abc/def/xxx.html」の内容が表示さ
れ、ユーザの目的が達せられる。

【００６３】一方、上述の「/abc/def/xxx.html」が、
「サーバ上のファイルであり、ユーザにより既に修正目
的でチェックアウトされている」となっていた場合の処
理を説明する。この場合、処理はステップＳ５０６に進
むことになる。

【００６４】以上のように「/abc/def/xxx.html」とい
うファイルが既にユーザによって修正目的でチェックア
ウトされている場合、本プロクシは、修正が入っている
かも知れない取り出し先のファイルをＷｅｂブラウザに
返す。

【００６５】このようなファイルの取り出し先はローカ
ルディスク１０８中のどこかであるが、「/abc/def/xx
x.html」などのファイル名から一意にその場所が分かる
ようにしておく。例えば、ファイルの取り出し先は、ユ
ーザのホームディレクトリの下の「サーバマシン名／資
源名」にあること、というようなルールを持たせておけ
ば良い。このようにしておけば、今回の例では、「/abc
/def/xxx.html」の取り出し先は、ユーザのホームディ
レクトリの下の「CM/abc/def/xxx.html」である（CMが
サーバマシン名であり、abc/def/xxx.htmlが資源名であ
る）ことが一意に分かる。

【００６６】このように取り出した資源の名前と、ロー
カルディスク上でのファイル名の対応の取り方は、上例
のように固定的であることもできるし、あるいは対応の
取り方を記述したファイルを外部に保存しておき、それ
を参照して対応を取るということもできる。例えば図１
６に示す表をユーザホームディレクトリの下の特定の名
前のファイルとして持ち、これを元に次のように対応を
取ることもできる。資源名を図１６の左の欄に上から順
々に当てはめていって最初に当てはまる行を探す。ここ
で＊は全ての文字列に当てはまるワイルドカード文字を
表すものとする。そして、ローカルディスク上でのファ
イル名は、当てはまった行の右欄の＊部分を、左欄の＊
にマッチした文字列に置き換えて生成する。例えば、資
源名が、「/xyz2/pqr/sss.html」ならば、表の２行目に
当てはまり、＊にマッチする文字列は「pqr/sss.html」
ということになる。従って、対応するローカルディスク
上でのファイル名は「/disk2/pqr/sss.html」と決定で
きる。

【００６７】以上のようにして、取り出し先のファイル
名を得て、そのファイルの内容を本プロクシサーバ１０
０が読めるようにする。すなわち、プロクシサーバ１０
０がローカルディスク１０８に直接アクセス可能ならそ
のままリードする。あるいはＦＴＰサーバのような、他
のマシン上のファイルへのアクセスを可能とするような
サーバを介してアクセスが可能なら、それを介してファ
イルのコピーをプロクシサーバ１００が稼働しているマ
シンにコピーする。

【００６８】次にすてっぷＳ５１２において、このファ
イルがクライアントから指示されたサーバ中のファイル
ではなく、取り出し先のファイルであることをクライア
ントのユーザに示すために、このファイルの先頭または
最後の部分に、「このファイルはあなたがチェックアウトしたファイル
です」という文章を挿入する。この文章を挿入するか否か、お
よび挿入する場合にはその位置は、対象となるファイル
のデータ形式による。

【００６９】たとえば、対象となるファイルが単なるテ
キストファイルであれば、そのファイルの先頭（または
最後）にそのまま上記文章データを挿入する。また、対
象となるファイルがＨＴＭＬ言語で書かれていると判定
される場合は、ＨＴＭＬのタグを解釈しつつ、Ｗｅｂブ
ラウザの表示上で先頭（または最後）になるように上記
文章データを挿入する。すなわち、ＨＴＭＬの </BODY>
タグの直後（または</BODY> タグの直前）に挿入す
る。なお、対象となるファイルが上記のどちらでもない
と判定される場合は挿入は行わないこととする。

【００７０】そして、ステップＳ３１０にて、上記の文
章データの挿入された（あるいは挿入されなかった）フ
ァイルの内容をＷｅｂブラウザに返信することで、Ｗｅ
ｂブラウザ上にはユーザがチェックアウトしたファイル
の内容が表示されることになる。

【００７１】なお、ここでローカルディスク１０８への
アクセスは、換言すればコンピュータ上に搭載されてい
るファイルシステムに対してリクエストを行い、返信デ
ータを受け取るものであるから、一種のプロトコル変
換、あるいはリクエスト先の変更ということになる。

【００７２】次にＣＭサーバ上にない資源をリクエスト
された場合の処理を説明する。ステップＳ３０１で受信
したリクエストが、 GET http//CM:80/abc/def/www.html HTTP/1.0 …… であったとする。そして、上述の処理に従ってステップ
Ｓ５０１に至り、ここでＣＭサーバ上には/abc/def/ww
w.htmlはなかったと判定されたとする。

【００７３】このような場合、そのままリクエストをＣ
Ｍサーバに対して行っても、対応する資源がないためリ
クエストが失敗するのは予め判っており、このような場
合ローカルディスク中の対応するファイルが存在する場
合はそれをクライアントに返信するようにする。

【００７４】この場合の処理は、ステップＳ５０１から
ステップＳ５０７に進み、当該資源名に対応するローカ
ルディスク中のファイル、またはディレクトリがあるか
どうかを判定する。この対応の取り方はステップＳ５０
６の説明で述べたものと同じである。

【００７５】ステップＳ５０７で対応するファイルが存
在しないと判定された場合は、ステップＳ５０８へ進
み、ここで「/abc/def/www.html」がないというメッセ
ージを含むエラーデータを作成し、ステップＳ３１０に
て返信する。

【００７６】一方、ステップＳ５０７で対応するファイ
ルが存在すると判定された場合は、さらにステップＳ５
０９でそれがファイルかディレクトリかを判定する。そ
して、ファイルであると判定された場合はステップＳ５
１０に進む。ここで、ローカルディスク中の対応するフ
ァイルを取得し、そのファイルをステップＳ３１０にて
返信する。

【００７７】この際、ステップＳ５１３において、返信
するファイルの先頭または最後に、「このファイルはロ
ーカルファイルです」という文章データを挿入する。そ
の方法はステップＳ５１２と同様である。

【００７８】また、ステップＳ５０９でディレクトリで
あると判定された場合、処理はステップＳ５１１に進
む。ここで、ローカルディスク中の当該ディレクトリ下
のファイルリストを作成し、それをステップＳ３１０に
て返信する。なお、この時作成するローカルファイルの
リストは、図６と同様の内容である。

【００７９】以上の、ステップＳ５１０，Ｓ５１１で行
った、ローカルファイルシステムへのアクセスは、ステ
ップＳ５０６の説明でも述べたように、ファイルシステ
ムへのリクエストという一種のプロトコル変換、あるい
はリクエスト先の変更といえる。

【００８０】次に、図７のように表示がされているＷｅ
ｂブラウザ上で、ユーザが、xxx.htmlの後ろの[CheckI
n]の部分を指示した場合の処理を説明する。

【００８１】前述したように、このような操作ではＷｅ
ｂブラウザは本プロクシサーバに対して、 GET http:CM80/abc/def/xxx.html?ci HTTP/1.0 …… というリクエストを送ってくる。

【００８２】これに対して、プロクシサーバ１００は図
３のステップＳ３０１，Ｓ３０２，Ｓ３０６と上述と同
じ処理をしていく。

【００８３】ステップＳ３０６では、リクエストの資源
名から、処理名を取り出すが、この場合は資源名の中に
？の文字があり、これに続く「ｃｉ」によって処理が指
定されていると判別される。ここで「ｃｉ」はチェック
イン処理を示しており、従って処理はステップＳ３０８
に進む。

【００８４】図８はチェックイン処理（ステップＳ３０
８）の詳細な制御手順を示すフローチャートである。以
下、図８のフローチャートを用いて説明する。

【００８５】ステップＳ７０１では、指定された資源名
「/abc/def/xxx.html（以後の処理ではリクエストの資
源名に含まれていた処理名の部分（?+文字列）を抜いた
部分を資源名として扱う）」がＣＭサーバ上にあるかど
うかを調べる。調べる方法はステップＳ５００の処理と
同じである。ここでその資源名のファイルがＣＭサーバ
上にないと判定された場合はステップＳ７０２へ進み、
新規ファイルのＣＭサーバへのチェックインを行う。

【００８６】ＣＭサーバへの新規ファイルチェックイン
には・資源名・チェックインするべきローカルディスク１０８中のフ
ァイル名・チェックインするファイルの内容説明文章・チェックインとともに、必要ならサーバ上に新規ディ
レクトリを作成するかの指定などの情報が必要であるが、この内リクエストの中に記
述されているのは資源名だけである。

【００８７】ただし、チェックインするべきローカルデ
ィスク１０８中のファイル名は、ステップＳ５０６の説
明で記述した方法で資源名から生成することが出来るた
め、「チェックインするファイルの内容説明文章」、
「チェックインと共に、必要ならサーバ上に新規ディレ
クトリを作成するかの指定」がチェックインに際して不
足する情報である。

【００８８】そこで、これら不足している情報をユーザ
に指定してもらうために、ステップＳ７０２では、設定
ウインドウ制御部１０６が図９のような新規チェックイ
ン用ウィンドウを、クライアントマシンのディスプレイ
２０５上に表示する。ユーザはこのウィンドウに対して
必要な情報を入力し、実行ボタンを押す。これにより、
処理はステップＳ７０３に進む。

【００８９】ステップＳ７０３では、新規チェックイン
ウィンドウで指定された内容に従ってＣＭサーバに対し
て、ファイルのチェックインコマンドを発行し、新規フ
ァイルのチェックイン処理（ＣＭサーバ上にファイル保
管）を行う。

【００９０】ステップＳ７０４では、ステップＳ７０３
で発行したチェックインコマンドの終了状態をもとに、
チェックインの成功・失敗の別を表すメッセージを含ん
だテキストファイルを作成する。そして、ステップＳ３
１０にこのテキストファイルをて返信し、Ｗｅｂブラウ
ザ上に表示させる。

【００９１】一方、先のステップＳ７０１で、資源がＣ
Ｍサーバ上にあると判定された場合はステップＳ７０
５，Ｓ７０６の処理へ進む。

【００９２】ステップＳ７０５では、更新のためのチェ
ックインに必要な、・資源名・チェックインするべきローカルディスク（１０８）中
のファイル・チェックインするファイルの変更内容説明文章の情報のうち、リクエストから得られる「資源名」及
び、資源名からステップＳ５０６の説明で記述した方法
で得られる「チェックインすべきローカルディスク（１
０８）中のファイル名以外で必要な情報をユーザに入力
させる。図１０に設定ウインドウ制御部１０６によって
ディスプレイ２０５上に表示される更新チェックイン用
ウィンドウを示す。

【００９３】ステップＳ７０６では、図１０の更新チェ
ックイン用ウィンドウを介して入力された情報に従い、
ＣＭサーバに対して、ファイルのチェックインコマンド
を発行し、チェックイン（ＣＭサーバ上に変更されたフ
ァイルの登録）を行う。その後のステップＳ７０４，Ｓ
３１０の処理は同様である。

【００９４】次に、図７の表示がされているＷｅｂブラ
ウザ上で、ユーザがxxx.htmlの後ろの[CheckOut]の部分
を指示した場合の処理を説明する。

【００９５】この操作ではＷｅｂブラウザはプロクシサ
ーバ１００に対して、 GET http://CM:80/abc/def/xxx.html?co HTTP/1.0 …… というリクエストが送られる。そして、プロクシサーバ
１００はステップＳ３０１，Ｓ３０２，Ｓ３０６と上述
と同じ処理をしていく。

【００９６】ステップＳ３０６では、リクエストの資源
名から、処理名を取り出すが、この場合は資源名の中に
？の文字があるため、「ｃｏ」によって処理が指定され
ており、チェックアウト処理であると判別される。従っ
て、処理はステップＳ３０９に進む。

【００９７】図１１はチェックアウト処理（ステップＳ
３０９）の詳細な制御手順を示すフローチャートであ
る。以下、図９のフローチャートを用いてチェックアウ
ト処理を説明する。ＣＭサーバからのファイルチェック
アウト処理には、・資源名・チェックアウトするべき取り出し先のファイル・修正目的のためのチェックアウトかどうかなどの情報が必要であるが、この内リクエストの中に記
述されているのは資源名だけである。

【００９８】そこでこれら不足している情報をユーザに
指定してもらうために、ステップＳ９０１において、設
定ウインドウ制御部１０６が図１２に示すようなチェッ
クアウト用ウィンドウを、クアイアンとマシンのディス
プレイ２０５上に表示する。ユーザはこれらのウィンド
ウに対し、必要な情報を入力し、実行ボタンを押す。こ
れにより、処理はステップＳ９０２に進む。

【００９９】ステップＳ９０２では、チェックアウトウ
ィンドウで指定された内容に従ってＣＭサーバに対し
て、ファイルのチェックアウトコマンドを発行し、チェ
ックアウト（ＣＭサーバ上のファイルをローカルディス
ク中の取り出し先に取り出す）を行う。

【０１００】なお、チェックアウトウィンドウでローカ
ルファイル名が指定されなかった場合は、ステップＳ５
０６の説明にあった、資源名とローカルディスク上での
ファイル名の対応に基づいてローカルファイル名を決定
する。

【０１０１】ステップＳ９０３では、ステップＳ９０２
で発行したチェックインコマンドの終了状態を元に、チ
ェックインの成功・失敗の別を表すメッセージを含んだ
テキストファイルを作成し、ステップＳ３１０にて返信
しＷｅｂブラウザ上に表示させる。

【０１０２】＜第２の実施形態＞第１の実施形態では、
プロクシサーバ１００は、クライアント１０７を起動し
たユーザと同じマシンの同じユーザによって起動されて
いたため、プロクシサーバ１００は、自身のプロセス
（コンピュータシステム中でのプログラム実行環境）の
情報から起動したユーザの情報（クライアント１０７）
を得ることができた。

【０１０３】例えば第１の実施形態のステップＳ５０６
の説明で、資源の名前と、ローカルディスク上でのファ
イル名の対応の取り方の例を述べているが、このように
クライアント１０７を起動しているユーザのホームディ
レクトリがどこにあるかを判定できるのは、プロクシサ
ーバ１００自身がクライアント１０７を起動したユーザ
の情報をプロセスの情報として持っているからである。

【０１０４】以下に説明する第２の実施形態は、クライ
アントを起動したユーザとプロクシサーバ１００を起動
するユーザが一致している必要がない例である。

【０１０５】図１３は、本実施形態のコンピュータ構成
を示す図である。１１０１，１１０３，１１０５，１１
０６，１１０７はそれぞれコンピュータシステムで、内
部にＣＰＵ、メモリ（不図示）を備えている。また、そ
れぞれ外部記憶装置１１０８，１１０９を備えている。

【０１０６】図１のクライアント１０７と同じプログラ
ムが、クライアントマシンＡ１１０１上およびクライア
ントマシンＢ１１０３上で、それぞれ「ユーザ１」「ユ
ーザ２」というユーザにより起動されているものとす
る。それぞれのマシンのクライアント１０７は、それぞ
れのマシンのディスプレイ１１０２，１１０４にクライ
アント１０７の表示ウィンドウを表示している。ここ
で、プロクシサーバ１００は、プロクシサーバマシン１
１０５上で、「ユーザＰ」により起動されているものと
する。

【０１０７】ＷＷＷサーバマシン１１０６、ファイル管
理サーバマシン１１０７で起動されているサーバプログ
ラムは、それぞれ第１の実施形態で説明した、ＷＷＷサ
ーバマシン２０６、ファイル管理サーバマシン２０７で
起動されているサーバプログラムと同一のものである。

【０１０８】図１４は第２の実施形態によるプロクシサ
ーバの制御手順を説明するフローチャートである。以下
に、図１４を用いて、第２の実施形態の動作を説明す
る。

【０１０９】図１４は、図３とほぼ同じ処理を行ってお
り、図３のステップＳ３０１〜Ｓ３１０がそれぞれ、図
１４のステップＳ１２０１〜Ｓ１２１０に対応してい
る。違いは、ステップＳ１２０１とＳ１２０２の間にス
テップＳ１２１１〜Ｓ１２１４が追加されたことと、ス
テップＳ１２０７〜Ｓ２２０９の処理の一部がステップ
Ｓ３０７〜Ｓ３０９と異なる点である。なお、ステップ
Ｓ１２１５は第３の実施形態に係る処理であり本実施形
態では省略されてもかまわない。

【０１１０】まずクライアントマシンＡ１１０１のクラ
イアント１０７から、 GET http://CM:80/abc/def/www.html HTTP/1.0 付随情報……なるリクエストが、プロクシサーバマシン
１１０５のプロクシサーバに受信された場合の処理を説
明する。

【０１１１】まず、ステップＳ１２０１でそのリクエス
トを受信する。次に、ステップＳ１２１１では、そのリ
クエストの付随情報中に、ユーザ認証情報が含まれてい
るかを調べる。これは、ＨＴＴＰプロトコルに規定され
ている、"Proxy-Authorization"ヘッダ情報を元に行
う。付随情報中にこの情報が含まれていなければ、ステ
ップＳ１２１１よりステップＳ１２１２へ進む。ステッ
プＳ１２１２では、上記のリクエストに対し、クライア
ントマシンＡ１１０１のクライアント１０７に、ＨＴＴ
Ｐで規定されている、「エラーステータス４０７」を返
す。「エラーステータス４０７」を受け取ったクライア
ントは、同じリクエストに"Proxy-Authorization"ヘッ
ダ情報をつけて再度リクエストを出し直すことになって
いる（ＨＴＴＰプロトコルに規定されている）。

【０１１２】クライアントマシンＡ１１０１のクライア
ント１０７は、"Proxy-Authorization"ヘッダ情報を付
加するのに必要なユーザ名およびパスワードの入力を促
すウィンドウをユーザに提示するのが普通で、これによ
り入力されたユーザ名とパスワードの情報を含む"Proxy
-Authorization"ヘッダ情報を付加した形で再度リクエ
ストが出される。

【０１１３】ここでは、ユーザが、ユーザ名として「ユ
ーザ１」と入力したとして説明する。再びステップＳ１
２０１ではリクエストが受信され、ステップＳ１２１１
へ進む。今度はリクエスト中に"Proxy-Authorization"
があるため、ユーザ承認情報ありと判定されステップＳ
１２１３へ進む。ステップＳ１２１３ではリクエスト中
の"Proxy-Authorization"の情報からユーザ名とパスワ
ードを抽出し、ユーザの認証（ユーザ名とパスワードの
照合）を行う。認証に失敗した場合（ユーザ名とパスワ
ードが合致しない場合）は再びステップＳ１２１２に戻
り、再度リクエストをクライアントマシンＡ１１０１の
クライアント１０７に送り返させる。その場合、通常ク
ライアント１０７では、ユーザに対してユーザ名とパス
ワードを再度入力するように促し、再入力された情報を
リクエストにつけてくるのが普通である。

【０１１４】一方、ユーザ認証が成功した場合はステッ
プＳ１２１４に進む。ステップＳ１２１４では、まず、
リクエスト中の"Proxy-Authorization"の情報からユー
ザ名を取り出す。この例ではユーザ名は「ユーザ１」と
なる。次に、このユーザ名のデータが、ユーザコンテキ
スト保持部１０４に存在するかを調べる。

【０１１５】ユーザコンテキスト保持部１０４のデータ
は、図１５に例を示すようなテーブルで、ユーザ名をエ
ントリとして、そのユーザが以前このプロクシサーバ１
００にアクセスしたときの情報を残している。本実施形
態では図１５のように、１ユーザにつき以下の３つのデ
ータを記録している。

【０１１６】チェックイン変更内容：ステップＳ７０
５で提示するチェックイン用ウィンドウで設定された変
更内容のテキスト、ディレクトリ作成許可フラグ：ステップＳ７０５で提
示するチェックイン用ウィンドウで設定されたディレク
トリ作成許可の状態、修正目的チェックアウトフラグ：ステップＳ９０３で
提示するチェックアウト用ウィンドウで設定された修正
目的チェックアウト指定の状態。

【０１１７】ここで、図１５に示されている「ローカル
ファイルの返信」、「説明文章の挿入」に関しては、第
３の実施形態で用いられるものであり、ここでは省略可
能である。

【０１１８】以上のようなユーザコンテキスト保持部１
０４の中に、「ユーザ１」のデータが含まれているかど
うかを調べ、含まれていなければ、ユーザコンテキスト
保持部１０４にそのユーザのエントリを作成し、そのユ
ーザの各コンテキストデータを初期値に設定する。ま
た、既にユーザコンテキスト保持部１０４に「ユーザ
１」のデータがあれば、ステップＳ１２１４では特に何
も処理をせずにステップＳ１２０２へ進む。

【０１１９】ここから先のステップＳ１２０２〜Ｓ１２
０６および、Ｓ１２１０の処理は、第１の実施形態で説
明した図３のステップＳ３０２〜Ｓ３０６およびＳ３１
０と同じなので、説明を省略する。以下に、第１の実施
形態と違いのある、ステップＳ１２０７〜Ｓ１２０９の
処理を説明する。

【０１２０】まず、データ取得処理であるステップＳ１
２０７に処理が来た場合の説明をする。ここでの処理は
第１の実施形態で図５を用いて説明した処理内容とほぼ
同じで、違いがあるのはステップＳ５０６，Ｓ５０９〜
Ｓ５１１の処理である。

【０１２１】第１の実施形態ではこれらのステップでク
ライアントマシン２０１に接続された外部記憶装置２０
４のファイルまたはディレクトリをアクセスしていた
が、ここではリクエストが送られてきたマシン、すなわ
ちクライアントマシンＡ１１０１の外部記憶装置１１０
８へアクセスを行うことになる。この際、リクエスト中
に含まれた資源名から、それに対応するクライアントマ
シンＡ１１０１の外部記憶装置１１０８でのファイルま
たはディレクトリ名を決定する際に、ステップＳ１２１
３のユーザ認証において抽出したユーザ名を用いる。

【０１２２】例えば、第１の実施形態で示したように、
ユーザのホームディレクトリ下に対応づけをするのであ
れば、当該リクエスト元のユーザのホームディレクトリ
がどこにあるかを特定しなければならず、そのためにこ
のユーザ名を使用する。あるいは、ユーザのホームディ
レクトリに置かれた特定の対応づけを記述したファイル
を参照して対応を取るなどの方法もある。

【０１２３】いずれにしろ、このようにしてクライアン
ト側のファイルあるいはディレクトリとの対応が取れれ
ばそのあとの処理は第１の実施形態で行った処理と同じ
で同様の結果が得られる。

【０１２４】次に、チェックイン処理（ステップＳ１２
８０）またはチェックアウト処理（ステップＳ１２０
９）に処理が来た場合を説明する。ここでの処理は第１
の実施形態で図７および図９を用いて説明した処理内容
とほぼ同じで、違いがあるのはステップＳ７０２，Ｓ７
０３，Ｓ７０５，Ｓ７０６，およびＳ９０１，Ｓ９０２
の各処理である。

【０１２５】以下、違いのある部分のみ説明する。

【０１２６】ステップＳ７０５で更新チェックイン用の
ウィンドウを表示する際、第１の実施形態ではそのウィ
ンドウの変更内容の初期値を設けていなかった。そのた
めユーザはチェックインの度に変更内容を入力する必要
があったが、ここではこの項目の初期値として、ユーザ
コンテキスト保持部１０４のデータ中から、ステップＳ
１２１３で抽出したユーザ名のデータを取り出し、その
中の「チェックイン変更内容」の値を初期値として使用
する。このとき、設定した初期値は更新チェックイン用
ウィンドウでユーザが見ることができ、必要であればユ
ーザが書き換えることも可能である。

【０１２７】ステップＳ７０６では、ファイルのチェッ
クインを行うが、ＣＭサーバに対してチェックインする
際に、チェックインするユーザが、ステップＳ１２１３
で抽出したユーザ名のユーザであるとしてチェックイン
を行う。プロクシサーバ１００を起動したのがユーザＰ
であったため、このような操作をしないとユーザＰがチ
ェックインしたとＣＭサーバに認識されてしまうためで
ある。

【０１２８】次に、更新用チェックインウィンドウで指
定された変更内容の文字列をユーザコンテキスト保持部
１０４の該ユーザ名のデータ「チェックイン変更内容」
に保存する。以降、ステップＳ７０４〜Ｓ１２１０へと
続く処理は第１の実施形態と同じである。

【０１２９】他に違いのあるステップＳ７０２，Ｓ７０
３およびＳ９０１，Ｓ９０２の各処理も同様に、ユーザ
に設定ウィンドウ制御部１０６が表示する設定用ウイン
ドウに提示する際の初期値として、ユーザコンテキスト
保持部１０４のデータを用いる。また、ＣＭサーバへの
アクセス後、実際に設定用ウィンドウで設定された設定
値をユーザコンテキスト保持部１０４に書き込んでお
く。

【０１３０】なお、第１の実施形態のように、１ユーザ
からのアクセスしか管理していない場合であっても、コ
ンテキストのエントリが、複数ユーザ分ないだけで、第
２の実施形態と全く同様にそのユーザのコンテキストを
管理・利用することは可能である。

【０１３１】＜第３の実施形態＞以下に説明する第３の
実施形態は、第２の実施形態で説明した、ユーザコンテ
キスト保持部１０４の中の、「ローカルファイルの返
信」、「説明文章の挿入」のコンテキストデータ項目を
利用するものである。これら２つの項目は、それぞれ、・ローカルディスク中のファイルを返信するかどうか。・ローカルファイルを返信した場合の説明文章をファイ
ルの先頭または最後に挿入するか。の機能のＯＮ／ＯＦＦを意味する。

【０１３２】実施形態の大部分は第２の実施形態と同様
であるので、図１４を使用して、異なる部分のみ説明を
する。ステップＳ１２０１〜Ｓ１２０２までの処理は第
２の実施形態と同じである。ステップＳ１２０６では、
リクエスト中から、処理名を取り出すが、その処理名が local-on local-off dscrpt-on dscrpt-off の４種類のいずれかであった場合の処理を説明する。こ
の場合、処理はステップＳ１２０６からステップＳ１２
１５へ進む。ステップＳ１２１５では以下の処理が実行
される。

【０１３３】処理名がlocal-onまたはlocal-offであっ
た場合、ユーザコンテキスト保持部１０４の、当該リク
エストを発したユーザ名をエントリとするデータの、
「ローカルファイルの返信」のコンテキストデータ項目
の値をＯＮまたは、ＯＦＦに設定する。同様に、処理名
がdscrpt-onまたはdscrpt-oｆｆであった場合、当該リ
クエストの発行元のユーザ名をエントリとするデータ
の、「説明文章の挿入」のコンテキストデータ項目の値
をＯＮまたは、ＯＦＦに設定する。

【０１３４】いずれの場合も、他サーバへのアクセスは
行わず、ステップＳ１２１０で返信するデータは、プロ
クシサーバ１００自身が生成するメッセージで、「ロー
カルファイルの返信がＯＦＦに設定されました」など、
各処理に従って実行された内容が示される。

【０１３５】次に、ステップＳ１２０６で、リクエスト
がデータ取得処理であったと判定され、ステップＳ１２
０７へ進んだ場合の処理を図５を用いて説明する。これ
も、第２の実施形態と異なる部分のみ説明する。

【０１３６】処理が、ステップＳ５０４に進んだ場合、
第２の実施形態では、修正目的でチェックアウトしてい
た場合には、ステップＳ５０６に進んでいた。これに対
して、第３の実施形態では、ユーザコンテキスト保持部
１０４に保持されている当該リクエスト発行元ユーザに
対応するコンテキストデータの「ローカルファイルの返
信」項目がＯＮであり、かつ、修正目的でチェックアウ
トをしていた場合にステップＳ５０６へ進むことにな
る。

【０１３７】また、ステップＳ５０７の判定も、コンテ
キストデータの「ローカルファイルの返信」項目がＯＮ
であり、かつ、資源がローカルディスクにある場合に、
ステップＳ５０９へ進むことになる。

【０１３８】このように、コンテキストデータの「ロー
カルファイルの返信」項目がＯＮでないと、ローカルデ
ィスクへのアクセスは行われず、リクエストで直接指示
されたサーバの情報以外を返さないようにする。また、
コンテキストデータの「説明文章の挿入」項目がＯＮで
ないと、ステップＳ５１２，Ｓ５１３で返信データに挿
入していた、「このファイルはあなたがチェックアウト
したファイルです」や「このファイルはローカルファイ
ルです」等の説明文章のデータは挿入されない。

【０１３９】上記以外の処理は第２の実施形態と同じで
ある。

【０１４０】なお、第２の実施形態と第３の実施形態で
は、ユーザコンテキスト保持部１０４のデータを、ユー
ザ名をエントリとして管理していたが、ある項目に関し
ては、全ユーザに反映されるデータとして使用すること
も可能である。例えば、上述の「ローカルファイルの返
信」や「説明文章の挿入」の２項目に関しては、各ユー
ザ毎に持つのではなく、プロクシサーバ１００中で１つ
ずつしか設定値を持たないようにすることもできる。こ
のようにすることにより、プロクシサーバ１００にアク
セスした全てのユーザに対して同じ設定値を反映でき
る。

【０１４１】また、このような設定項目に対して、実際
に設定を変更できるのはある特定のユーザのみである、
というようにプロテクトをかけることもできることは明
らかである。

【０１４２】なお、本発明は、複数の機器（例えばホス
トコンピュータ，インタフェイス機器，リーダ，プリン
タなど）から構成されるシステムに適用しても、一つの
機器からなる装置（例えば、複写機，ファクシミリ装置
など）に適用してもよい。

【０１４３】また、本発明の目的は、前述した実施形態
の機能を実現するソフトウェアのプログラムコードを記
録した記憶媒体を、システムあるいは装置に供給し、そ
のシステムあるいは装置のコンピュータ（またはＣＰＵ
やＭＰＵ）が記憶媒体に格納されたプログラムコードを
読出し実行することによっても、達成されることは言う
までもない。

【０１４４】この場合、記憶媒体から読出されたプログ
ラムコード自体が前述した実施形態の機能を実現するこ
とになり、そのプログラムコードを記憶した記憶媒体は
本発明を構成することになる。

【０１４５】プログラムコードを供給するための記憶媒
体としては、例えば、フロッピディスク，ハードディス
ク，光ディスク，光磁気ディスク，ＣＤ−ＲＯＭ，ＣＤ
−Ｒ，磁気テープ，不揮発性のメモリカード，ＲＯＭな
どを用いることができる。

【０１４６】また、コンピュータが読出したプログラム
コードを実行することにより、前述した実施形態の機能
が実現されるだけでなく、そのプログラムコードの指示
に基づき、コンピュータ上で稼働しているＯＳ（オペレ
ーティングシステム）などが実際の処理の一部または全
部を行い、その処理によって前述した実施形態の機能が
実現される場合も含まれることは言うまでもない。

【０１４７】さらに、記憶媒体から読出されたプログラ
ムコードが、コンピュータに挿入された機能拡張ボード
やコンピュータに接続された機能拡張ユニットに備わる
メモリに書込まれた後、そのプログラムコードの指示に
基づき、その機能拡張ボードや機能拡張ユニットに備わ
るＣＰＵなどが実際の処理の一部または全部を行い、そ
の処理によって前述した実施形態の機能が実現される場
合も含まれることは言うまでもない。

【０１４８】

【発明の効果】以上説明したように、本発明によれば、
多くの種類のプロトコルをクライアントに対して中継す
ることが可能になり、また、クライアントのユーザが直
接複数の操作することなしに、複数箇所に存在する情報
を取得することができる。

【０１４９】

【図面の簡単な説明】

【図１】本実施形態によるプロクシサーバの機能構成を
示すブロック図である。

【図２】第１の実施形態による情報処理システムの全体
構成を示す図である。

【図３】第１の実施形態によるプロクシサーバの制御手
順を説明するフローチャートである。

【図４】第１の実施形態によるマシン名・プロトコル対
応表の一例を示す図である。

【図５】データ取得処理（ステップＳ３０７）の詳細な
制御手順を説明するフローチャートである。

【図６】第１の実施形態においてプロクシサーバで作成
されるファイルリストデータの一例を示す図である。

【図７】図６のテキストファイルをＷｅｂブラウザで表
示した状態を示す図である。

【図８】チェックイン処理（ステップＳ３０８）の詳細
な制御手順を示すフローチャートである。

【図９】新規チェックイン用ウィンドウの表示例を示す
図である。

【図１０】更新チェックイン用ウィンドウの表示例を示
す図である。

【図１１】チェックアウト処理（ステップＳ３０９）の
詳細な制御手順を示すフローチャートである。

【図１２】チェックアウト用ウインドウの表示例を示す
図である。

【図１３】本実施形態のコンピュータ構成を示す図であ
る。

【図１４】第２の実施形態によるプロクシサーバの制御
手順を説明するフローチャートである。

【図１５】ユーザコンテキスト保持部のデータ構成例を
示す図である。

【図１６】第１の実施形態による、ファイル名の「対応
の取り方」を記述したファイルの一例を示す図である。

フロントページの続き (72)発明者白井昌彦東京都大田区下丸子３丁目30番２号キヤノン株式会社内 (72)発明者神田都孔子東京都大田区下丸子３丁目30番２号キヤノン株式会社内

Claims

【特許請求の範囲】

【請求項１】クライアントとサーバの経路中に存在
し、両者の通信を仲介するプロクシサーバの機能を備え
た情報処理装置であって、クライアントより第１の通信形態で受信したリクエスト
に基づいてサーバを特定する特定手段と、前記特定手段で特定されたサーバとの間で採用すべき通
信形態を第２の通信形態として決定する決定手段と、前記リクエストに含まれる要求内容を実現するために、
必要な情報を付加して前記第２の通信形態に適応したリ
クエストデータを生成する生成手段と、前記生成手段で生成されたリクエストデータ前記特定手
段で特定したサーバへ送信する送信手段とを備えること
を特徴とする情報処理装置。
【請求項２】前記生成手段は、前記受信したリクエストに基づいて前記第２の通信形態
に適応したリクエストデータを生成するに際して不足し
ている情報を検出する検出手段と、少なくとも前記検出手段で検出された不足している情報
を入力可能なユーザインターフェースを提示する提示手
段とを備え、前記提示手段を介して入力された情報を前記リクエスト
に付加して前記第２の通信形態に適応したリクエストデ
ータを生成することを特徴とする請求項１に記載の情報
処理装置。
【請求項３】前記提示手段は、前記ユーザインターフ
ェースの提示を前記リクエストの発行元のクライアント
装置上にて行わせることを特徴とする請求項２に記載の
情報処理装置。
【請求項４】前記特定されたサーバが前記生成手段で
生成したリクエストデータの要求内容を満足するか否か
を判定する判定手段と、前記判定手段で前記サーバが前記要求内容を満足しない
と判定された場合、別のサーバあるいはシステムに、前
記リクエストデータを対応する通信形態に変換して送信
する第２送信手段とを更に備えることを特徴とする請求
項１に記載の情報処理装置。
【請求項５】前記判定手段は、前記特定手段で特定さ
れたサーバに前記リクエストデータが要求する資源が存
在するか否かを判定することを特徴とする請求項４に記
載の情報処理装置。
【請求項６】前記別のサーバあるいはシステムがファ
イルシステムであることを特徴とする請求項４に記載の
情報処理装置。
【請求項７】前記第２送信手段における前記別のサー
バあるいはシステムよりの返信情報を前記クライアント
に返送する場合、該返信情報に所定の情報を付加して返
送データを形成し、これを前記クライアントに前記第１
の通信形態で送信する返送手段を更に備えることを特徴
とする請求項４に記載の情報処理装置。
【請求項８】前記特定されたサーバに対して前記リク
エストデータに基づく処理を完了した場合、その旨を示
すデータを生成し、これを前記クライアントに前記第１
の送信形態で送信する第３送信手段を更にそなることを
特徴とする請求項１に記載の情報処理装置。
【請求項９】前記決定手段は、各サーバの識別情報と
そのサーバが実装する通信形態の対応テーブルを有し、
前記特定手段で特定されたサーバとの間で採用すべき通
信形態を該対応テーブルを参照して決定することを特徴
とする請求項１に記載の情報処理装置。
【請求項１０】前記第１の通信形態で受信したリクエ
ストに基づいて各クライアント毎の個別情報を保持する
保持手段を更に備え、前記生成手段は、前記リクエストに含まれる要求内容を
実現するために付加する付加情報を、、該リクエストの
識別情報に基づいてクライアントを識別し、該識別され
たクライアントの個別情報を前記保持手段より獲得し、
獲得した個別情報に基づいて生成することを特徴とする
請求項１に記載の情報処理装置。
【請求項１１】クライアントとサーバの経路中に存在
し、両者の通信を仲介するプロクシサーバの機能を実現
する情報処理方法であって、クライアントより第１の通信形態で受信したリクエスト
に基づいてサーバを特定する特定工程と、前記特定工程で特定されたサーバとの間で採用すべき通
信形態を第２の通信形態として決定する決定工程と、前記リクエストに含まれる要求内容を実現するために、
必要な情報を付加して前記第２の通信形態に適応したリ
クエストデータを生成する生成工程と、前記生成工程で生成されたリクエストデータ前記特定工
程で特定したサーバへ送信する送信工程とを備えること
を特徴とする情報処理方法。
【請求項１２】クライアントとサーバの経路中に存在
し、両者の通信を仲介するプロクシサーバの機能を実現
するための制御プログラムを格納するコンピュータ可読
メモリであって、該制御プログラムがクライアントより
第１の通信形態で受信したリクエストに基づいてサーバ
を特定する特定工程のコードと、前記特定工程で特定されたサーバとの間で採用すべき通
信形態を第２の通信形態として決定する決定工程のコー
ドと、前記リクエストに含まれる要求内容を実現するために、
必要な情報を付加して前記第２の通信形態に適応したリ
クエストデータを生成する生成工程のコードと、前記生成工程で生成されたリクエストデータ前記特定工
程で特定したサーバへ送信する送信工程のコードとを備
えることを特徴とするコンピュータ可読メモリ。