(57)【要約】      （修正有）【課題】計算システムがインターネットに接続された資源をトランスパレントにアクセスする。【解決手段】計算システムの共有ライブラリは、ファイルについてのシステム呼に応答して、ファイルについてのパス名がメモリ中の個人名の下に位置づけられているかどうかを決定し、ファイルがキャッシュに格納されておらず個人名スペースの下に位置づけられたパス名を有しているときに、個人名スペースの下に位置づけられたパス名に基づいてインターネットからファイルを検索するための要求を発行する。アクセスサーバは、共有ライブラリからの要求に応答してインターネット資源からファイルを検索するための適当なアクセスプロトコルを選択し、インターネット資源からファイルを検索する。アクセスサーバは、アプリケーションがファイルを閉じるときにインターネット資源にファイルを再格納する。【選択図】図１
2007115244.tif 000002
【特許請求の範囲】
【請求項１】
プロセッサ及び該プロセッサに結合されるメモリを含む計算シ
ステムであって、
該メモリは、
操作システムと、
該操作システムと関連するキャッシュと、
ファイルに対するシステム呼に応答して、該ファイルに関するパス名が該メモリ中の個人名の下に位置づけられているかどうかを決定し、及び
該ファイルが該キャッシュに記憶されておらず該個人名スペースの下に位置づけられたパス名を有するときに、該個人名スペースの下に位置づけられた該パス名に基づいてインターネット資源から該ファイルを検索するための要求を発行する共有ライブラリと、
該共有ライブラリからの要求に応答して該インターネットからのファイルを検索するアクセスサーバとを含み、
該アクセスサーバが該インターネットからの該ファイルを検索するときに、該共有ライブラリは操作システムに該システム呼を発呼するようになっている計算システム。
【請求項２】
請求の範囲第１項に記載の計算システムにおいて、
該アクセスサーバが、各々が所定のインターネットプロトコルを実施する複数のエージェントを含み、及び
該アクセスサーバが、該インターネットからのファイルを検索するための適当なアクセスプロトコルを選択するようになっている計算システム。
【請求項３】
請求の範囲第２項に記載の計算システムにおいて、
該共有ライブラリ及び該アクセスサーバが該システム呼に応答しトランスパレントに動作する計算システム。
【請求項４】
請求の範囲第３項に記載の計算システムにおいて、
該共有ライブラリが、該メモリで走行しているアプリケーションからの該システム呼を受信するものである計算システム。
【請求項５】
請求の範囲第４項に記載の計算システムにおいて、
該アプリケーションが該ファイルを閉じるときに、該アクセスサーバが、該インターネット資源に対して該ファイルを再格納する計算システム。
【請求項６】
請求の範囲第４項に記載の計算システムにおいて、
該アクセスサーバが、ユーザのパスワード情報を用いて該インターネット資源から該ファイルをアクセスする計算システム。
【請求項７】
請求の範囲第６項に記載の計算システムにおいて、
該アクセスサーバが、該ユーザのパスワード情報を用いて該インターネット資源から該ファイルをアクセスするときに、該共有ライブラリがそれ自身の正当性を該アクセスサーバに対して証明する計算システム。
【請求項８】
請求の範囲第２項に記載の計算システムにおいて、
該アクセスサーバが、該インターネット資源と関連する遠隔サーバと直接接触することにより、該インターネット資源から該ファイルを検索する計算システム。
【請求項９】
請求の範囲第２項に記載の計算システムにおいて、
該アクセスサーバが、該インターネット資源と関連する遠隔サーバと、代理サーバを通して接触することによって該インターネット資源から該ファイルを検索する計算システム。
【請求項１０】
インターネットに接続される資源をアクセスする方法であって、
共有ライブラリにてファイルについてのシステム呼を受信するステップと、
該ファイルが局部的にキャッシュ化されているかどうかを決定するステップと、
該ファイルについてのパス名が個人名スペースの下に位置づけられているかどうかを決定するステップと、
該ファイルが該キャッシュに格納されておらず該個人名スペースの下に位置づけられているパス名を有しているときに、該個人名スペースの下に位置づけられている該パス名に基づいてインターネットから該ファイルを検索するステップと、
該ファイルが該インターネット資源から検索されるときに計算システムの操作システムに対して該システム呼を発行するステップとを含む方法。
【請求項１１】
請求の範囲第１０項に記載の方法において、さらに
該ファイルが閉じられるときに該インターネット資源に対して該ファイルを再格納するステップを含む方法。
【請求項１２】
請求の範囲第１１項に記載の方法において、
該インターネット資源から該ファイルを検索するステップが、ユーザのパスワード情報を用いて該インターネット資源から該ファイルをアクセスするステップを含む方法。
【請求項１３】
請求の範囲第１０項に記載の方法において、さらに
該ファイルがキャッシュ化された最後の時間及び有効ファイルキャッシュ時間に局部的に基づいて、該ファイルがキャッシュ化されるときに該ファイルが有効であるかどうかを決定するステップを含む方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本願は、C.H.Raoの１９９６年６月７日付け米国特許仮出願第60/019,303号「インターネットのファイルシステムへの統合」についての優先権を主張するものである。
【背景技術】
【０００２】
１．発明の分野
本願発明は、コンピュータ分野に関するものである。より詳細には、本願発明は、インターネットを経由することが可能なリソースへのアクセスのための方法及びシステムに関する。
【０００３】
２．従来技術の記述
より多くのリソースがインターネットを介して利用できるようになり、ウエブ・ページ、ゴーファ情報、ネットワーク・ニュース、出版された文書や技術レポート、パブリック・ドメイン・ソフトウエア、共同研究リソースや草案のようなリソースを位置付け、管理し統合することがますます困難になってきている。事実上の業界標準（de facto standard）であるユニフォーム・リソース・ロケータ（Uniform Resource Locator：ＵＲＬ）プロトコルによって定義された命名（naming）スキームを用いて、インターネットに接続されたリソースにアクセスする。他の標準的なアクセス・プロトコル、例えば、ファイル・サーバへのファイル・トランスファ・プロトコル（file transfer protocol：ＦＴＰ）、ウエブ・サーバへのハイパ・テキスト・トランスポート・プロトコル（hyper transport protocol：ＨＴＴＰ）、ゴーファ・サーバに対するゴーファ・プロトコル（ＧＯＰＨＥＲ）、ニュースサーバに対するネットワーク・ニュース・トランスファ・プロトコル（network news transfer protocol：ＮＮＴＰ）及びファイル・サーバに対するリモート・シェル（remote shell：ＲＳＨ）を用いても、インターネット・リソースにアクセスする。これら特定のアクセスプロトコルの各々は、インターネットに接続されるサーバからリソースを引き出すアクセス機構を規定する。モザイク（Mosaic）やネットスケープ（Netscape）のようなインターネットブラウザが、ネットワークを便利に検索し、情報を引き出すために紹介されているが、この様な伝統的なブラウザは、リソースを検索し引き出すためには完璧に適切ではあるものの、制限的であり、より大きなツールセット（toolset）にそれ自身を統合することには適していない。
【０００４】
インターネットのファイルへより簡単にそしてより効率的にアクセスするために、いくつかのシステムが開発されている。例えば、Andrew File Systemは、ファイルシステムの範囲をローカル・エリア・ネットワーク（local area network：ＬＡＮ）からインターネットへ拡大することによって、広域ファイルサービスを提供する。しかしながら、Andrew File Systemはそれ独自のプロトコルを用いており、上述した標準のインターネットプロトコルを用いていない。その結果として、Andrewのためのファイルサーバが必要となる。
【０００５】
インターネットを介してファイルにアクセスするために開発された別のシステムには、新しいオペレーティング・システムを導入することによってインターネット・ファイル・サーバをローカル・ネーム・スペースへマウントすることができるBell laboratory Plan９がある。Plan ９は、パープロセス・ネーム・スペース（per-process name space）とメッセージ指向ファイル・システム・プロトコル（message-oriented file system protocol）をサポートし、ファイル・システムに類似するインターフェースが実行される。異なるアクセス・プロトコルが推奨されるが、Plan９オペレーティング・システムは現存するアプリケーション・ツールとは透過（transparent）ではなく、Plan９で使うためにはカーネルとそのカーネル上で動作するアプリケーションの変更が必要となる。
【０００６】
Alex File Systemは、現存するネットワーク・ファイル・システム（Network File System：ＮＦＳ）の上位で設計したことによって、仮想ファイル・システム（Vertual File System：ＶＦＳ）として追加されたAlex サーバにより、インターネット・リソースへ透過な読み出しアクセス（transparent read accesss）を提供する。ＬＡＮ上のホストはＮＦＳプロトコルを用いてコール（call）をAlexサーバへ送信する。コールは、Alexサーバが動作するＮＦＳサーバカーネルへの位置であるカーネル上のＮＦＳクライアントを介して通る。次に、コールがＮＦＳサーバカーネルからAlexサーバへアップコール（upcall）される。それにも関わらず、ＮＦＳプロトコルはAlexシステムを制限してしまう。なぜなら、ＮＦＳプロトコルはファイル・サービスを実行しているが、認証アクセスを実行するのに重要な要求の初期化プロセスに関して、いかなる情報をも提供しないからである。その結果として、Alexシステムは、匿名ＦＴＰアクセス（anonymous FTP access）等の制限されたファイル指向ファイルアクセス（file-oriented file access）しかサポートしない。
【０００７】
Jade File Systemは、自主的（autonomy）故に変更されない下位の現存するファイルシステムの異種収集（heterogeneous collection）を統合する新しいパーソナル・ネーム・サーバ（personal name server）を用いて、インターネット環境にあるファイルを命名（naming）し、アクセスする均一の方法を提供する。以下の２つの要素をサポートするプライベート・ネーム・スペースを、各ユーザが定義することができる。即ち、１つのディレクトリにマウントすることができる多重ファイル・システム（multiple file system）、そして、他の論理的ネームスペース（logical name space）をマウントすることができる１つの論理的ネームスペースである。しかしながら、Jade File SystemはＵＲＬ命名を利用することができない。その代わりとして、別個のネーム・サーバがパス名に対して提供される。さらに、別個のアクセス・サーバをマウントしなければならず、ユーザがファイルシステムにアクセスする前に、ホストで動作するプログラムを再度コンパイルしなければならない。
【０００８】
Multiple Dimensional file System（ｎ−ＤＦＳ）は、アプリケーションやオペレーティング・システム・カーネルの変更を必要とせず、下位にあるファイル・システムに新しいサービスを追加することができる論理的ファイルシステムである。ｎ−ＤＦＳが現存する物理的なファイル・システムの上位層にあるが、現存するプロトコルを用いた伝統的なインターネット・アクセスは提供しない。
【０００９】
インターネット・リソースにアクセスするための現存するオペレーティング・システム・カーネル、アプリケーション及びファイルサーバとの関係で、現存するプロトコルを透過的に用いるインターネット・ファイル・システムが望まれている。
【００１０】
発明の概要
本願発明は、インターネット・リソースへアクセスするための現存するオペレーティング・システム・カーネル、アプリケーション及びファイルサーバとの関係で現存するプロトコルを透過的に用いるインターネット・ファイル・システムを提供する。従って、アプリケーション・プログラマは、ローカルに保存されていたり、インターネット・リソースにある取り扱っているファイルと同じシステム・コールを用いることができる。本願発明の有利な点が、インターネットへ接続されたリソースに透過的にアクセスするプロセッサとメモリを有するコンピュータ・システムである方法及びシステムによって提供される。コンピュータシステムのメモリは、オペレーティング・システムと、オペレーティング・システムに関するキャッシュと、共用ライブラリと、アクセス・サーバとを含んでいる。共用ライブラリはファイルに対するシステム・コールに応動して、メモリのパーソナル・ネームスペースの下で、ファイルに対するパス名が位置しているかどうかを決定し、ファイルがキャッシュに記憶されておらず、パーソナル・ネーム・スペースの下に位置するパス名を有しているときには、パーソナル・ネーム・スペースの下に位置するパス名に基づいてインターネット・リソースからファイルを引き出す要求を発する。共用ライブラリからの要求に応動して、アクセス・サーバはインターネット・リソースからのファイルを引き出すのに適切なアクセス・プロトコルを選択し、インターネット・リソースからファイルを引き出す。アクセス・サーバがファイルを引き出したときには、次に共用ライブラリは、システム・コールをオペレーティング・システムに発する。アクセスサーバは、アプリケーションがファイルを閉じたときには、インターネットリソースへファイルを元に戻す。
【００１１】
詳細な記述
本願発明は、現存するプロトコルを透過的に統合することによって、ソフトウエアの変更や遠隔サーバの管理の変更を必要としない、パーソナル・ネーム・スペース（Ｐersonal Ｎame Ｓpace：ＰＮＳ）のインターネット・ファイルをユーザが管理することができる、インターネット・ファイル・システム（Ｉnternet Ｆile Ｓystem：ＩＦＳ）に関する。本願発明は、オペレーティング・システムと、下位のオペレーティングシステムが提供するシステム・コール・インタフェースと全く同じものをアプリケーションに与えるオペレーティングシステム上で動作するアプリケーションとの間で論理的な層（layer）を導入する。本願発明の論理層は、オペレーティング・システムの変更を必要とすることなくアプリケーションと同じアドレス・スペースで動作する。
【００１２】
本願発明に従うと、各ユーザはＰＮＳ内のファイルを組織化することによってアクセスするインターネットファイルを選択し、これにより、システム・ワイドなグローバル・ネーム・スペースを維持する複雑さを回避する。本願発明に従うと、ＰＳＮは自己負担であり、他の全てのユーザに対して無定義（undefined）を維持する。ＰＳＮの所有者だけがＰＳＮへアクセスする。ＰＮＳを「マウントする」即ち、共通のネーム・スペースやＵＲＬ命名をサポートする他のネーム・スペースへアタッチ（attach）することができる。ＵＲＬ名をパス名として用いることでインターネットファイルへ直接アクセスすることができる。例えば、
http://www.att.com/reserch.html
によって識別されるホームページを
〜/IFS/http://www.att.com/reserch.html
と命名する。ここで、「〜/IFS」はＰＮＳに対するローカル・ファイル・システム上のマウント・ポイントである。さらに、ＰＮＳは、インターネット・ファイル・サーバのネーム・スペースを、例えばファイル・トランスポート・プロトコル（file transport protocol：ＦＴＰ）のようなアクセス・プロトコルを用いてＰＳＮのノードへアタッチするマウント動作をサポートする。即ち、ＰＮＳは、ファイルシステムに対し、命名及びファイルへのアクセス、及び位置に依存しない命名をサポートするマウント動作を実行させることができる。
【００１３】
図１は、本発明によるシステムの構成のブロック線図である。システム１０は、メモリ１２に結合されたプロセッサ１１を含む。メモリ１２は、ブラウザー、共有ライブラリ１６及びアクセスサーバ１７のような、動作のためのシステムカーネル （システム中心部） １３、カーネル１３のためのキャッシュ（貯蔵所）１４、少なくとも１つのアプリケーション１５を蓄えるためのメモリスペースを含む。プロセッサ１１及びメモリ１２は、物理的にシングルデバイスの中に配置されうるか、又は、よく知られたＬＡＮの技術を使用して分配される複数のプロセッサ及びメモリデバイスとして形成され得る。複数のアプリケーションも、よく知られた技術を使用してシステム１０により処理されうる。
【００１４】
アプリケーション１５が、例えば、ファイルを開き、読み込み、書き込み、閉じるために、要求又はシステムコールをカーネル１３へと送るとき、要求は、共有ライブラリ１６及びアクセスサーバ１７を含む論理層２２により受信される。好ましくは、共有ライブラリ１６は、アプリケーションに完全なＰＯＳＩＸシステムインターフェイスを与える。共有ライブラリ１６は、アプリケーション１５によりリンクされ、アプリケーション１５のアドレススペースにおいて動作する。システムコールを取り扱うために必要な機能性の全ては、共有ライブラリ１６により提供される。本発明によれば、共有ライブラリ１６は、ＰＮＳを取り扱う能力を備える、すなわち、共有ライブラリ１６は、システムコールにおいて特定されるファイルのためのパスネイムがアプリケーションのユーザーのためにＰＮＳのもとに配置されているかどうかを決定する能力がある。決定は、マウントポイント（ｉｒｏｏｔ）を検査することにより為される。特定されたファイルが、ＰＮＳのもとに配置されている場合、共有ライブラリ１６は、要求されるファイルがインターネットファイルであるか又は近くに蓄えられているかを決定する。ファイルがインターネットファイルである場合、共有ライブラリ１６は、よく知られた方法で、要求を内部処理通信（インタープロセスコミュニケイション：ＩＰＣ）を通してアプリケーション１５からアクセスサーバ１７へと伝達する。ダイナミックな共有ライブラリを提供する計算システムについては、アプリケーション１５は、共有ライブラリ１６を含むライブラリーサーチパスを単に再調査することにより、共有ライブラリ１６を呼び出し得る。ダイナミックな共有ライブラリを持たない計算システムについては、アプリケーションは、共有ライブラリ１６と再リンクされねばならない。
【００１５】
アクセスサーバ１７は、特定されるファイルに適するアクセスプロトコルを選択し、インターネット１８経由で遠隔サーバ１９へと接続し、遠隔サーバ１９からメモリ２０に蓄えられる特定されるファイルを得る。アクセスサーバ１７は、アプリケーション１５を処理しているユーザーに代わって、インターネットサーバの認証されるアクセスを実行する能力がある。すなわち、アクセスサーバ１７は、ユーザーのパスワード情報を使用して、遠隔ファイルサーバへとアクセス可能である。このアクセスを実行するために、共有ライブラリ１６は、アクセスサーバ１７に対して自分自身を認証する能力を持つ。
【００１６】
一度特定されるファイルが得られれば、アクセスサーバ１７は、ファイルを近くにキャッシュ１４中に貯蔵する。アクセスサーバ１７は、特定のアクセスプロトコルを実行する各々のエージェントを持つ、複数のエージェントを含む。図１は、例示的なエージェント１７ａ、１７ｂ及び１７ｃを示す。エージェントは、直接に或いは代理サーバ２１のような代理サーバを通して遠隔サーバに接続し得る。アクセスサーバ１７は、ローカルネイムスペイス上での遠隔ファイルシステムのマウント、遠隔ファイルの検索及びファイルをその最初のサーバへと戻すことという３つの基本的な機能を実行する。検索及び戻す機能は、特定のプロトコルにより確認される対応するコマンドへと写像され、一方、マウントの機能は、ローカルな処理である。
【００１７】
アクセスサーバ１７は、システム１０において限定される各々のＰＮＳのためにマウントのためのデータベースを支える。アクセスプロトコル、ホスト、認証情報、遠隔パス情報等のようなインターネットファイルにアクセスするために必要とされる情報は、データベースに蓄えられる。ＰＮＳのための各々のエントリーは、ＰＮＳのためのマウントポイントも含む。アクセスサーバ１７は、ファイルを配置し、検索し及び処理のためのシステムカーネル１３のキャッシュ１４中に蓄えるために、マウントのためのデータベースにおいてマウントのための情報を参照する。特定されたファイルが既に貯蔵されているとき、アクセスサーバ１７は、ＩＰＣメッセージを共有ライブラリへと送る。共有ライブラリ１６は、それから、特定されたファイルをキャッシュ１４から取り出す。ファイルがアプリケーション１５により閉じられているとき、アクセスサーバ１７は、ファイルを遠隔サーバ１９へと戻す。特定されたファイルがローカルファイルである、すなわち、システム１０中のどこかほかの近くの場所に蓄えられているとき、共有ライブラリ１６は、直接的にファイルにアクセスする。
【００１８】
遠隔ファイルサーバは、個々のファイルの読み込み及び書き込みのためではなくシステムファイルを開く及び閉じるためのみに接続されるので、好ましくは、インターネットファイルは、開いているとき、ローカルファイルシステム上でそっくりそのまま貯蔵される。この方法において、むしろ個々のページに対する一連のシステムの要求及び応答として手付かずのファイルが取り出されるとき、ファイルを伝送することにより上に背負い込まれた全体のネットワークは、降ろされる。インターネットを介してのファイルへのアクセスは、包括的なシステム資源の消費に関して無駄が多いので、ファイルの貯蔵されたコピーがアクセスを受けたとき、本発明は、貯蔵されたコピーのデータが遠隔サーバに蓄えられたマスターコピーデータと矛盾しないかどうかを決定する。
【００１９】
単一のアクセスサーバ１７が図１中の層２２に示されているが、複数のアクセスサーバが使用され得る。例えば、本発明の基本的な構成は、各々のシステムユーザーのためのアクセスサーバ１７及び各々のユーザーのアクセスサーバの配置のためのシステムワイドネイムサーバを含み得る。
【００２０】
二者択一的に、ユーザーのグループは、特定のアクセスサーバ１７を共有し得る。本発明は、インターネット上に配置されたファイルサーバが、伝統的なシステムにおけるようにカーネルの実行としてよりもむしろ図２に示されるようにユーザー・レベルの実行としてマウントされることを可能とする。図２において、プロセス２３と関連する各々の共有ライブラリ１６は、従来技術において現在為されているように、関連するカーネル、（示されていない）ＮＦＳプロトコル及び（示されていない）アクセスサーバを通して処理されつつあるアプリケーションよりむしろアクセスサーバ１７に直接的にアクセスする。
【００２１】
図３は、ローカルシステム３０中のＰＮＳの概念を示す。第一のＰＮＳ３１は、／ｈｏｍｅ／ｂｏｂ／ＩＦＳにおいてローカルファイルシステム３０へとマウントされ、ユーザーＢｏｂにより所有されるということが示される。第二のＰＮＳ３２は、／ｈｏｍｅ／ｓｔｅｐｈａｎｉｅ／ｔｍｐ／ＩＦＳにおいてマウントされ、ユーザーＳｔｅｐｈａｎｉｅにより所有されるということが示される。ＰＮＳは、ディレクトリの組（マウントポイント、キャッシュディレクトリ）により意味を明らかにされ、ここでマウントポイントは、ＰＮＳがマウントされる或いはつながれるファイルシステムにおけるローカルパスネイムであり、キャッシュディレクトリは、遠隔ファイル及びディレクトリが貯蔵されるローカルディレクトリである。本質的に、マウントポイントは、マウントがどこに向いているかを表示する。図３において、ＰＮＳ３１のためのマウントポイントは、／ｈｏｍｅ／ｂｏｂ／ＩＦＳであり、ＰＮＳ３２のためのマウントポイントは、／ｈｏｍｅ／ｓｔｅｐｈａｎｉｅ／ＩＦＳである。キャッシュディレクトリは、ファイルシステムの構造においてキャッシュファイルを入れる場所として必要となる。多数のＰＮＳを支えるというタスクを簡単にするために、本発明は、マウントポイント及びキャッシュディレクトリのためにＩＲｏｏｔと呼ばれる単一のディレクトリを使用する。ＩＲｏｏｔは、遠隔ファイル及びディレクトリが貯蔵される遠隔ファイルシステム上でのＰＮＳ及び物理的なディレクトリのためのマウントポイントである。即ち、ＩＲｏｏｔはマウントポイント及びキャッシュディレクトリを含む。ユーザーは、コマンドｉｒｏｏｔ：＄ｉｒｏｏｔ  ｐａｔｈｎａｍｅをしようしてＩＲｏｏｔを簡単にすることによりＰＮＳの意味を明らかにする。
【００２２】
図３に示されるように、ＰＮＳ３１のためのＩＲｏｏｔは、／ｈｏｍｅ／ｂｏｂ／ＩＦＳであることが明らかにされ、一方ＰＮＳ３２のためのＩＲｏｏｔは、／ｈｏｍｅ／ｓｔｅｐｈａｎｉｅ／ｔｍｐ／ＩＦＳであることが明らかにされる。ＰＮＳ３１及び３２は、ローカルネイムスペイス３０上で各々マウントされる。ＰＮＳ３１（／ｈｏｍｅ／ｂｏｂ／ＩＦＳ）のもとに配置されたファイル及びディレクトリは、ＰＮＳ３１の意味を明らかにする特定のユーザーの対してのみアクセス可能である。ＰＮＳ１２の意味を明らかにしたユーザーのような他のユーザーに対しては、／ｈｏｍｅ／ｂｏｂ／ＩＦＳのもとにあるファイル及びディレクトリは、不確定にされる。
【００２３】
機構を名付けるユニバーサルリソースロケイター（ＵＲＬ）は、本発明のシステム中に埋め込まれる。機構を名付けるＵＲＬは、形式：
protocol://user:password@host/path
を有し、ここで、“protocol”は、アクセスプロトコルであり、
“user”は、オプショナルユーザーネイムであり、“password”は、オプショナルパスワードであり、“host”は、ネットワークホスト又はそのＩＰアドレスの完全に資格を与えられたドメインネイムであり、“port”は、接続されるオプショナルポートナンバーであり、及び“path”は、要求されるリソースにアクセスするために遠隔サーバにより使用されるパスである。アクセスプロトコルは、遠隔サーバに配置されるインターネットリソースへのアクセスに対するキーを提供するばかりでなく、アクセスサーバが配置されるシステムの異質性を隠しもする。すなわち、一度アクセスプロトコルが利用可能になれば、マシンタイプ又はサーバの動作システムに関係なく、プロトコルをしようしてサーバにより提供されるリソースにアクセスすることが可能である。結果的に、本発明は、アクセスプロトコルの異質な集合を支える。
【００２４】
表Ｉは、マウントポイント及びキャッシュディレクトリを含むＩＲｏｏｔを示す“〜ＩＦＳ”を持つ例示的なパスネイム及び対応するＵＲＬネイムを示す。
【表１】
2007115244.tif 000003
【００２５】
次の典型的な仮コードは、
システムコールopen0を用いて、ホームページを開き、システムコールread0を用いてＵＲＬ名に位置するファイルを読み込み、生データとして同じくファイルのコンテンツを処理しシステムコールclose0を用いて、ファイルを閉じる。
システム・コールclose0：
【数１】
2007115244.tif 000004
【００２６】
本発明は、さらに、
インターネット・リソースが、設置管理及び現在コマンド及びリールを用いて相互に対話出来ることを可能なサービスを提供する。
例えば、コマンド・ラインは、
$ls-/IFSnntp;/ulysses/comp.os.research/*
ニュース・サーバ“ulysses”上に格納されたニュース・グループ“comp.os.research”の中の記事を列挙する。更に、コマンドラインは、
$grep thread 〜 /IFS/nntp:/ulysses/comp.os.research/*
ニュース・グループ“comp.os.research”の中で、キーワード“thread”を検索する。
【００２７】
マウントは、遠隔サーバに接続することに対して間接的ネーミングを提供することでファイルをネーミングし、又、証明情報を維持する場合に生成されるべきショートカットを割り当てる。さらに、マウントは、代理サーバに本件発明を所望されたファイルサーバにアクセスする経路を特定することを許可する。ＰＮＳの範囲内でＰＮＳ及びマウント地点の両方は、ユーザ単位を基本に定義される。本発明によれば、マウント操作は、グローバル名空間のトップにＰＮＳを結びつけることが可能で、遠隔ファイルシステムをＰＮＳに接続することが可能である。
マウントポイントは、コマンドマウントによって特定される：
$mount URLName MountPoint[Boxy Server : Port]
【００２８】
［有効期間］
“URLName”は、インターネットを越えてアクセス可能なファイル／階層のＵＲＬ名であり、“Mount Point”は、ＰＮＳ（例えば、ＩＦＳ、図３）の中の定義されたマウントポイントで“Proxy Server”は、任意の代理サーバパラメータであり、そして“Port”は、代理サーバのトップポートを特定するための任意のパラメータである。
【００２９】
代理サーバとポートパラメータが、特定された場合、本件発明は、特定された代理サーバを通って特定遠隔サーバにアクセスする。そのパラメータ有効期間（秒）は、有効であると考えられるマウント地点のもとにキャッシュされたファイルを一定期間中、特定する。特に、ファイルがアクセスされた場合、キャッシュされたファイルは、その保持時間が、特定された有効期間での範囲内まで利用することが出来る。有効期間が終了すると、そのファイルは、ネットワークから獲得しなければならない。ＵＲＬ名は、ユーザ名及びパスワードを含み、そして、表れた場合、本件発明は、パスワードを用いて、ユーザに代わって遠隔サーバにアクセスを証明する。もし、パスワードの値が“−”であるならば、マウントコマンドは、願わくば次のプロントでパスワードを入力する様、ユーザに要求する。
【００３０】
図４は、遠隔ファイルシステムは、本件発明に従ってどの様にマウントされるかを描いている。図４では、異なるプロトコルを用いる遠隔ファイルシステムは、IRoot/home/bob/IFS(PNS31, 図３上にマウントされる。gryphon.att.comのファイルサーバ４０は、以下の様に/home/bob/IFSにマウントされる。
$mount ftp://bob:-@gryphon.att.com.home/bob
/home/bob/IFS/research
password:******
このコマンドは、ｆｔｐプロトコルを用いて、ノード/home/bob/IFS/reseachのＰＮＳ３１上のgryphon.att.com.上のファイルサーバ４０に位置する階層ボブにマウントさせる。この実施例の中で、そのマウントコマンドは“−”がパスワード領域で特定されたとして、パスワードを入力するようにＢｏｂに入力を促す。ユーザＢｏｂが、/home/bob/IFS/researchの下のファイルをいつアクセスしようとも、本発明は、ユーザＢｏｂの入力したパスワードを用いて、Ｂｏｂに代わってgryphon.att.com.から一致しているファイルを回復させる。マウントコマンドの他の実施例は：
$mount rsh://king/home/rao/project/home/bob/IFS/project
この実施例に対して、
rsh protocolを経て、ノード-/home/bob/IFS/projectの所でＰＮＳ３１上のking（階層）でファイルサーバ４１に位置する階層“project”は、確証されたアクセスを提供する。ユーザーは、ＵＲＬ名の内側で、ユーザ名とパスワードを指定する。そのシステムは、ユーザのホームディレクトリ中の.rhostファイルから証明情報を得る。この事は、ネットワークを経て、許可パスワード情報を無効にする。マウント・コマンドの以下の実施例の中で、マウント地点は匿名のｆｔｐアクセスを用いて生成される。：
$ mount ftp://tsx-ll.mit.edu/pub/linux
/home/bob/IFS/src/linux
radish:8000
ポート８０００上のradish上の代理サーバはtsx-ll.mit.eduにアクセスするために促される。この実施例に対して、tsx-ll.mit.edu上のファイル・サーバ４２の中の遠隔ディレクトリ'linux'は、ＰＮＳ３１の中のノード'linux'上にマウントされる。
【００３１】
本件発明は、キャッシュ確認プロセスを制御する２つの方法を提供している。まず、マウント・コマンドを用いて割り当てられた属性有効期間は、各ディレクトリに割り当てられる。各ディレクトリは、その親ディレクトリから有効期間を継承する。生成されたディレクトリの元で、コピーが有効期間中に回復されるならば、ファイルのキャッシュされたコピーは、その初期のコピーをチェックすることなく、有効であるとして取り扱われる。例えば、キャッシュされたファイルに対して有効期間が７２００秒に設定されるならば、キャッシュされたコピーは、７２００秒に対して有効であると考慮される。有効期間が、“−１”の場合は、キャッシュされたコピーは、常に有効であるとされる。有効期間が“０”の場合は、キャッシュされたコピーは、常に無効であるとされる。有効期間は、ディレクトリに関連されて多くの他の属性の用に動的に変更可能である。
【００３２】
第２の有効制御方法に対して、有効マスクとして述べられるプロセス単位でのマスクは、ディレクトリの有効期間を上書きする構成要件を提供する。子プロセスは、その親プロセスから有効マスクを継承し、ビルト−イン  シェルコマンド‘vmask’は、プロセス有効マスクを定義し、更新するために使用される。プロセス毎の有効マスクは、ディレクトリ毎の有効期間より高い優先順位を持っている。つまり、ファイルの特殊なタイプを扱う場合は、その有効時間は、例えば、アクセスに所望されるファイル・マウントに従って決定される。ファイルを使用することに対して目的を考慮する場合は、その有効期間は、例えばファイルを使用するアプリケーションの時間、アプリケーションに従って、プロセスの時間である。このように、有効期間を使って、キャッシュ有効プロセスは共通著作文書対ネットワークニュースの様なインターネットのファイルタイプに従って、制御可能である。一方では、有効マスクはリフレッシュキャッシュ１４の様な特定の環境の中のプロセスレベル上の有効期間の上書きを許可する。
【００３３】
図５は、本件発明に従って、有効プロセス５０に対する流れ図を示す。ステップ５１で、キャッシュの中に要求された情報が存在するかどうか決定される。要求された情報が、そのキャッシュに存在するならば、処理の流れは、ステップ５２に引き継がれ、キャッシュが、有効期間又は有効マスクの下で有効かどうか決定される。有効であるならば、処理の流れは、ステップ５３に引き継がれ、キャッシュの中の情報は、システムコールに対して回復される。又、情報がキャッシュ（ステップ５１）の中に存在しない、又は、キャッシュが有効ではない（ステップ５２）であるならば、処理の流れはステップ５４に引き継がれ、メッセージは、共有ライブラリからアクセスサーバに送られる。処理の流れは、ステップ５５に引き継がれ、ここで、インターネットにアクセスし、その情報は回復され、そしてその後キャッシュに格納される。
【００３４】
図６は、図５に示されたプロセス５０のステップ５２の詳細な流れ図６０を示している。ステップ５２Ａでは、キャッシュが最後に、更新された時を決定する。次に、ステップ５２Ｂで、最後の更新時刻は、キャッシュされたコピーが有効であるかいなかを決定するための有効期間又は有効マスクと比較する。
本件発明は、サーバへ使用者を確認するためにそれ自身を確認する。その結果、共有ライブラリ１６及びアクセスサーバ１７は、好ましくは、分離実在としてシステム１０の内部に設定される。この方法で、共有ライブラリ１６は、ユーザの確認を認識する。アクセスサーバ１７は、アクセスサーバ１７が、システムコール要求をさせるユーザの確認を決定させるために設定されないという理由で、インターネットに接続されたサーバに通知するために共有ライブラリ１６から情報を得る。次に、共有ライブラリ１６は、アクセスサーバが、ユーザ確認面実施が可能になる前にそれ自身は、アクセスサーバ１７を確認する。
【００３５】
本件発明は、又、匿名及び確認されたインターネットへの直接的アクセス又は代理サーバ経由の両方をサポートする。本件発明に従えば、ユーザは、ファイルアクセスのための適切なログイン名及びパスワード情報を用いて、サーバに遠隔操作するために、彼ら自身確認できる。確認されたアクセスは、要求が許可されるべきアクセスサーバ１７と最初に通信する共有ライブラリ１６のハンドシェイクプロセスを含んでいる。アクセスサーバ１７は、その時、時刻刻印を得るために生成されるべきファイルでのある共有ライブラリ１６に通信する。共有ライブラリ１６は、一度生成されたアクセスサーバ１７にファイルを確認する。アクセスサーバ１７は、その時、情報を確かめるために共有ライブラリ１６によって生成されたファイルにアクセスする。
【００３６】
本件発明が、描かれた実施例と関連して記載された一方で、本件の本質及び範囲からそれることなしに改良されることは、評価され、理解されるであろう。
【図面の簡単な説明】
【００３７】
本願発明は、いくつかの例によって説明されているが、同じ引用数字が同じ要素を示す添付図面に限定されるものではない。
【図１】本願発明に従ったシステムのアーキテクチャのブロック図である。
【図２】本願発明に従った異なるアプリケーションに対する矛盾のない共有をサポートするアーキテクチャを有するシステムのブロック図である。
【図３】本願発明に従ったパーソナル・ネーム・スペース（ＰＮＳ）の概念を示す図である。
【図４】本願発明に従った遠隔ファイルシステムのマウントを説明する図である。
【図５】本願発明に従った認証プロセスを示す流れ図である。
【図６】第５図の認証プロセスの段階の詳細を示す流れ図である。
【図１】
2007115244.tif 000005
【図２】
2007115244.tif 000006
【図３】
2007115244.tif 000007
【図４】
2007115244.tif 000008
【図５】
2007115244.tif 000009
【図６】
2007115244.tif 000010
【手続補正書】
【提出日】平成18年11月2日(2006.11.2)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
計算システムであって、
プロセッサと、
該プロセッサに接続されたメモリとを含み、該メモリは、
アプリケーションと、
オペレーティングシステムと、
該オペレーティングシステムと関連するキャッシュと、
該アプリケーションと該オペレーティングシステムとの間に存在すると共に、アクセスサーバと共有ライブラリとを含む論理層とを含み、該共有ライブラリは、ＵＲＬ命名をサポートする共有ライブラリに統合されたパーソナルネイムスペースを有し、該統合されたパーソナルネイムスペースは、パーソナルネイムスペースに対するローカルファイルシステム上のマウント・ポイントとしてURLネイムと共に用いられるパーソナルパスネイムのプレフィックスを有し、
該共有ライブラリは、 (ａ)該アプリケーションから該オペレーティングシステムへのファイルの要求としてのシステムコールを傍受して、 (ｂ)該ファイルのパスネイムとしてのＵＲＬネイムが該メモリ内のパーソナルネイムスペースに位置しているか否かを、該パスネイム内の該パーソナルパスネイムのプレフィックスの存在に基づいて判定し、 (ｃ) 該パスネームが該パーソナルネイムスペースに位置し、且つ、該ファイルが該キャッシュに記憶されていない場合に、インターネット資源から該ファイルを検索するための要求を発行し、
該アクセスサーバは、該共有ライブラリからの該要求に応答して、該インターネット資源から該ファイルを検索し、そして、パスネイムとしてのURLネイムとともに用いられる該パーソナルパスネイムのプレフィックスのもとに、該検索されたファイルを該キャッシュ内に配置し、
該アクセスサーバが該インターネットリソースからファイルを検索する場合に、該共有ライブラリは、該オペレーティングシステムに、前記共有ライブラリが当初傍受したファイルの要求としての該システムコールを発呼する計算システム。
【請求項２】
請求項１に記載の計算システムにおいて、
該アクセスサーバは、複数のエージェントを含み、各エージェントは、所定のインターネットアクセスプロトコルを実行し、
該アクセスサーバは、適切なアクセスプロトコルを選択して、該インターネット資源からファイルを検索する計算システム。
【請求項３】
請求項２に記載の計算システムにおいて、該共有ライブラリと該アクセスサーバは、該システムコールに応答して、既存のプロトコルを使用して透過的に動作する計算システム。
【請求項４】
請求項３に記載の計算システムにおいて、該共有ライブラリは、該メモリ内で動作しているアプリケーションからの該システムコールを受信する計算システム。
【請求項５】
請求項４に記載の計算システムにおいて、該アプリケーションがファイルを閉じるときに、該アクセスサーバは、該インターネット資源にファイルを再格納する計算システム。
【請求項６】
請求項４に記載の計算システムにおいて、該アクセスサーバは、ユーザーのパスワード情報を使用して該インターネット資源からのファイルにアクセスする計算システム。
【請求項７】
請求項６に記載の計算システムにおいて、該アクセスサーバが該ユーザーのパスワード情報を使用して該インターネット資源からのファイルにアクセスする場合に、該共有ライブラリは、該共有ライブラリを該アクセスサーバに認証する計算システム。
【請求項８】
請求項２に記載の計算システムにおいて、該アクセスサーバは、該インターネットリソースと関連する遠隔サーバと直接交信することにより、該インターネット資源からファイルを検索する計算システム。
【請求項９】
請求項２に記載の計算システムにおいて、該アクセスサーバは、該インターネット資源と関連する遠隔サーバと代理サーバを介して交信することにより、該インターネット資源からファイルを検索する計算システム。
【請求項１０】
インターネットに接続されている資源にアクセスする方法であって、
共有ライブラリにおいてファイルの要求としてのシステムコールを受信するステップと、
該ファイルがローカル的に貯蔵されているか否かを前記共有ライブラリが判定するステップと、
パスネイムの中の、パーソナルネイムスペースに対するローカルファイルシステム上のマウント・ポイントとしてURLネイムと共に用いられるパーソナルパスネイムのプレフィックスの存在に基づいて、該ファイルについての該パスネイムとしてのURLネイムがパーソナルネイムスペースに配置されているか否かを前記共有ライブラリが判定するステップとを含み、該パーソナルネイムスペースは、ＵＲＬ命名をサポートする前記共有ライブラリに統合されており、該方法は、さらに、
該ファイルがキャッシュの中に記憶されておらず、且つ、該ファイルが該パーソナルネイムスペースに配置されているパスネイムを有している場合に、該パーソナルネイムスペースに配置されている該パスネイムとしてのURLネイムに基づいて、アクセスサーバがインターネット資源から該ファイルを検索するステップと、
該インターネット資源から該ファイルを検索する場合に、計算システムのオペレーティングシステムに、前記共有ライブラリが当初傍受したファイルの要求としてのシステムコールを発呼するステップと、
前記アクセスサーバが、該パーソナルパスネイムのプレフィックスのもとに、該検索されたファイルを、該キャッシュ内に配置するステップとを含む方法。
【請求項１１】
請求項１０に記載の方法において、該ファイルを閉じるときに、前記アクセスサーバが、該インターネット資源に該ファイルを再格納するステップをさらに含む方法。
【請求項１２】
請求項１１に記載の方法において、該インターネットリソースから該ファイルを検索するステップは、ユーザーのパスワード情報を使用して前記アクセスサーバが該インターネットリソースからの該ファイルにアクセスするステップを含む方法。
【請求項１３】
請求項１０に記載の方法において、該ファイルがローカル的に貯蔵されている場合に、該ファイルがキャッシュされた最新の時間と有効ファイルキャッシュ時間とに基づいて、該ファイルが有効であるか否かを判定するステップをさらに含む方法。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【発明の詳細な説明】
【技術分野】
【０００１】
本願は、C.H.Raoの１９９６年６月７日付け米国特許仮出願第60/019,303号「インターネットのファイルシステムへの統合」についての優先権を主張するものである。
【背景技術】
【０００２】
１．発明の分野
本願発明は、コンピュータ分野に関するものである。より詳細には、本願発明は、インターネットを経由することが可能なリソースへのアクセスのための方法及びシステムに関する。
【０００３】
２．従来技術の記述
より多くのリソースがインターネットを介して利用できるようになり、ウエブ・ページ、ゴーファ情報、ネットワーク・ニュース、出版された文書や技術レポート、パブリック・ドメイン・ソフトウエア、共同研究リソースや草案のようなリソースを位置付け、管理し統合することがますます困難になってきている。事実上の業界標準（de facto standard）であるユニフォーム・リソース・ロケータ（Uniform Resource Locator：ＵＲＬ）プロトコルによって定義された命名（naming）スキームを用いて、インターネットに接続されたリソースにアクセスする。他の標準的なアクセス・プロトコル、例えば、ファイル・サーバへのファイル・トランスファ・プロトコル（file transfer protocol：ＦＴＰ）、ウエブ・サーバへのハイパ・テキスト・トランスポート・プロトコル（hyper transport protocol：ＨＴＴＰ）、ゴーファ・サーバに対するゴーファ・プロトコル（ＧＯＰＨＥＲ）、ニュースサーバに対するネットワーク・ニュース・トランスファ・プロトコル（network news transfer protocol：ＮＮＴＰ）及びファイル・サーバに対するリモート・シェル（remote shell：ＲＳＨ）を用いても、インターネット・リソースにアクセスする。これら特定のアクセスプロトコルの各々は、インターネットに接続されるサーバからリソースを引き出すアクセス機構を規定する。モザイク（Mosaic）やネットスケープ（Netscape）のようなインターネットブラウザが、ネットワークを便利に検索し、情報を引き出すために紹介されているが、この様な伝統的なブラウザは、リソースを検索し引き出すためには完璧に適切ではあるものの、制限的であり、より大きなツールセット（toolset）にそれ自身を統合することには適していない。
【０００４】
インターネットのファイルへより簡単にそしてより効率的にアクセスするために、いくつかのシステムが開発されている。例えば、Andrew File Systemは、ファイルシステムの範囲をローカル・エリア・ネットワーク（local area network：ＬＡＮ）からインターネットへ拡大することによって、広域ファイルサービスを提供する。Andrew File Systemはそれ独自のプロトコルを用いてはいるが、上述した標準のインターネットプロトコルを用いていない。その結果として、Andrewのためのファイルサーバが必要となる。
【０００５】
インターネットを介してファイルにアクセスするために開発された別のシステムには、新しいオペレーティング・システムを導入することによってインターネット・ファイル・サーバをローカル・ネーム・スペースへマウントすることができるBell laboratory Plan９がある。Plan ９は、パープロセス・ネーム・スペース（per-process name space）とメッセージ指向ファイル・システム・プロトコル（message-oriented file system protocol）をサポートし、ファイル・システムに類似するインターフェースが実行される。異なるアクセス・プロトコルが提供されるが、Plan９オペレーティング・システムは現存するアプリケーション・ツールとカーネルとに対して透過（transparent）ではなく、Plan９で使うためには、カーネル上で動作するアプリケーションの変更が必要となる。
【０００６】
Alex File Systemは、現存するネットワーク・ファイル・システム（Network File System：ＮＦＳ）の上位で設計したことによって、仮想ファイル・システム（Vertual File System：ＶＦＳ）として追加されたAlex サーバにより、インターネット・リソースへ透過な読み出しアクセス（transparent read accesss）を提供する。ＬＡＮ上のホストはＮＦＳプロトコルを用いてコール（call）をAlexサーバへ送信する。コールは、Alexサーバが動作するＮＦＳサーバカーネルへの位置であるカーネル上のＮＦＳクライアントを介して通る。次に、コールがＮＦＳサーバカーネルからAlexサーバへアップコール（upcall）される。それにも関わらず、ＮＦＳプロトコルはAlexシステムを制限してしまう。なぜなら、ＮＦＳプロトコルはファイル・サービスを実行しているが、認証アクセスを実行するのに重要な要求の初期化プロセスに関して、いかなる情報をも提供しないからである。その結果として、Alexシステムは、匿名ＦＴＰアクセス（anonymous FTP access）等の制限されたファイル指向ファイルアクセス（file-oriented file access）しかサポートしない。
【０００７】
Jade File Systemは、自主的（autonomy）故に変更されない下位の現存するファイルシステムの異種収集（heterogeneous collection）を統合する新しいパーソナル・ネーム・サーバ（personal name server）を用いて、インターネット環境にあるファイルを命名（naming）し、アクセスする均一の方法を提供する。以下の２つの要素をサポートするプライベート・ネーム・スペースを、各ユーザが定義することができる。即ち、１つのディレクトリにマウントすることができる多重ファイル・システム（multiple file system）、そして、他の論理的ネームスペース（logical name space）をマウントすることができる１つの論理的ネームスペースである。しかしながら、Jade File SystemはＵＲＬ命名を利用することができない。その代わりとして、別個のネーム・サーバがパス名に対して提供される。さらに、別個のアクセス・サーバをマウントしなければならず、ユーザがファイルシステムにアクセスする前に、ホストで動作するプログラムを再度コンパイルしなければならない。
【０００８】
Multiple Dimensional file System（ｎ−ＤＦＳ）は、アプリケーションやオペレーティング・システム・カーネルの変更を必要とせず、下位にあるファイル・システムに新しいサービスを追加することができる論理的ファイルシステムである。ｎ−ＤＦＳが現存する物理的なファイル・システムの上位層にあるが、現存するプロトコルを用いた伝統的なインターネット・アクセスは提供しない。
【０００９】
インターネット・リソースにアクセスするための現存するオペレーティング・システム・カーネル、アプリケーション及びファイルサーバとの関係で、現存するプロトコルを透過的に用いるインターネット・ファイル・システムが望まれている。
【００１０】
発明の概要
本願発明は、インターネット・リソースへアクセスするための現存するオペレーティング・システム・カーネル、アプリケーション及びファイルサーバとの関係で現存するプロトコルを透過的に用いるインターネット・ファイル・システムを提供する。従って、アプリケーション・プログラマは、ローカルに保存されていたり、インターネット・リソースにある取り扱っているファイルと同じシステム・コールを用いることができる。本願発明の有利な点が、インターネットへ接続されたリソースに透過的にアクセスするプロセッサとメモリを有するコンピュータ・システムである方法及びシステムによって提供される。コンピュータシステムのメモリは、オペレーティング・システムと、オペレーティング・システムに関するキャッシュと、共用ライブラリと、アクセス・サーバとを含んでいる。共用ライブラリはファイルに対するシステム・コールに応動して、メモリのパーソナル・ネームスペースの下で、ファイルに対するパス名が位置しているかどうかを決定し、ファイルがキャッシュに記憶されておらず、パーソナル・ネーム・スペースの下に位置するパス名を有しているときには、パーソナル・ネーム・スペースの下に位置するパス名に基づいてインターネット・リソースからファイルを引き出す要求を発する。共用ライブラリからの要求に応動して、アクセス・サーバはインターネット・リソースからのファイルを引き出すのに適切なアクセス・プロトコルを選択し、インターネット・リソースからファイルを引き出す。アクセス・サーバがファイルを引き出したときには、次に共用ライブラリは、システム・コールをオペレーティング・システムに発する。アクセスサーバは、アプリケーションがファイルを閉じたときには、インターネットリソースへファイルを元に戻す。
【００１１】
詳細な記述
本願発明は、現存するプロトコルを透過的に統合することによって、ソフトウエアの変更や遠隔サーバの管理の変更を必要としない、パーソナル・ネーム・スペース（Ｐersonal Ｎame Ｓpace：ＰＮＳ）のインターネット・ファイルをユーザが管理することができる、インターネット・ファイル・システム（Ｉnternet Ｆile Ｓystem：ＩＦＳ）に関する。本願発明は、オペレーティング・システムと、下位のオペレーティングシステムが提供するシステム・コール・インタフェースと全く同じものをアプリケーションに与えるオペレーティングシステム上で動作するアプリケーションとの間で論理的な層（layer）を導入する。本願発明の論理層は、オペレーティング・システムの変更を必要とすることなくアプリケーションと同じアドレス・スペースで動作する。
【００１２】
本願発明に従うと、各ユーザはＰＮＳ内のファイルを組織化することによってアクセスするインターネットファイルを選択し、これにより、システム・ワイドなグローバル・ネーム・スペースを維持する複雑さを回避する。本願発明に従うと、ＰＳＮは自己負担であり、他の全てのユーザに対して無定義（undefined）を維持する。ＰＳＮの所有者だけがＰＳＮへアクセスする。ＰＮＳを「マウントする」即ち、共通のネーム・スペースやＵＲＬ命名をサポートする他のネーム・スペースへアタッチ（attach）することができる。ＵＲＬ名をパス名として用いることでインターネットファイルへ直接アクセスすることができる。例えば、
http://www.att.com/reserch.html
によって識別されるホームページを
〜/IFS/http://www.att.com/reserch.html
と命名する。ここで、「〜/IFS」はＰＮＳに対するローカル・ファイル・システム上のマウント・ポイントである。さらに、ＰＮＳは、インターネット・ファイル・サーバのネーム・スペースを、例えばファイル・トランスポート・プロトコル（file transport protocol：ＦＴＰ）のようなアクセス・プロトコルを用いてＰＳＮのノードへアタッチするマウント動作をサポートする。即ち、ＰＮＳは、ファイルシステムに対し、命名及びファイルへのアクセス、及び位置に依存しない命名をサポートするマウント動作を実行させることができる。
【００１３】
図１は、本発明によるシステム１０の構成のブロック線図である。システム１０は、メモリ１２に結合されたプロセッサ１１を含む。メモリ１２は、共有ライブラリ１６及びアクセスサーバ１７、動作のためのシステムカーネル （システム中心部） １３、カーネル１３のためのキャッシュ（貯蔵所）１４、ブラウザーのような少なくとも１つのアプリケーション１５を蓄えるためのメモリスペースを含む。プロセッサ１１及びメモリ１２は、物理的にシングルデバイスの中に配置されうるか、又は、よく知られたＬＡＮの技術を使用して分配される複数のプロセッサ及びメモリデバイスとして形成され得る。複数のアプリケーションも、よく知られた技術を使用してシステム１０により処理されうる。
【００１４】
アプリケーション１５が、例えば、ファイルを開き、読み込み、書き込み、閉じるために、要求又はシステムコールをカーネル１３へと送るとき、要求は、共有ライブラリ１６及びアクセスサーバ１７を含む論理層２２により受信される。好ましくは、共有ライブラリ１６は、アプリケーションに完全なＰＯＳＩＸシステムインターフェイスを与える。共有ライブラリ１６は、アプリケーション１５によりリンクされ、アプリケーション１５のアドレススペースにおいて動作する。システムコールを取り扱うために必要な機能性の全ては、共有ライブラリ１６により提供される。本発明によれば、共有ライブラリ１６は、ＰＮＳを取り扱う能力を備える、すなわち、共有ライブラリ１６は、システムコールにおいて特定されるファイルのためのパスネイムがアプリケーションのユーザーのためにＰＮＳのもとに配置されているかどうかを決定する能力がある。決定は、マウントポイント（ｉｒｏｏｔ）を検査することにより為される。特定されたファイルが、ＰＮＳのもとに配置されている場合、共有ライブラリ１６は、要求されるファイルがインターネットファイルであるか又は近くに蓄えられているかを決定する。ファイルがインターネットファイルである場合、共有ライブラリ１６は、よく知られた方法で、要求を内部処理通信（インタープロセスコミュニケイション：ＩＰＣ）を通してアプリケーション１５からアクセスサーバ１７へと伝達する。ダイナミックな共有ライブラリを提供する計算システムについては、アプリケーション１５は、共有ライブラリ１６を含むライブラリーサーチパスを単に再定義することにより、共有ライブラリ１６を呼び出し得る。ダイナミックな共有ライブラリを持たない計算システムについては、アプリケーションは、共有ライブラリ１６と再リンクされねばならない。
【００１５】
アクセスサーバ１７は、特定されるファイルに適するアクセスプロトコルを選択し、インターネット１８経由で遠隔サーバ１９へと接続し、遠隔サーバ１９からメモリ２０に蓄えられる特定されるファイルを得る。アクセスサーバ１７は、アプリケーション１５を処理しているユーザーに代わって、インターネットサーバの認証されるアクセスを実行する能力がある。すなわち、アクセスサーバ１７は、ユーザーのパスワード情報を使用して、遠隔ファイルサーバへとアクセス可能である。このアクセスを実行するために、共有ライブラリ１６は、アクセスサーバ１７に対して自分自身を認証する能力を持つ。
【００１６】
一度特定されるファイルが得られれば、アクセスサーバ１７は、ファイルを近くにキャッシュ１４中に貯蔵する。アクセスサーバ１７は、特定のアクセスプロトコルを実行する各々のエージェントを持つ、複数のエージェントを含む。図１は、例示的なエージェント１７ａ、１７ｂ及び１７ｃを示す。エージェントは、直接に或いは代理サーバ２１のような代理サーバを通して遠隔サーバに接続し得る。アクセスサーバ１７は、ローカルネイムスペイス上での遠隔ファイルシステムのマウント、遠隔ファイルの検索及びファイルをその最初のサーバへと戻すことという３つの基本的な機能を実行する。検索及び戻す機能は、特定のプロトコルにより確認される対応するコマンドへと写像され、一方、マウントの機能は、ローカルな処理である。
【００１７】
アクセスサーバ１７は、システム１０において規定される各々のＰＮＳのためにマウントのためのデータベースを支える。アクセスプロトコル、ホスト、認証情報、遠隔パス情報等のようなインターネットファイルにアクセスするために必要とされる情報は、データベースに蓄えられる。ＰＮＳのための各々のエントリーは、ＰＮＳのためのマウントポイントも含む。アクセスサーバ１７は、ファイルを配置し、検索し及び処理のためのシステムカーネル１３のキャッシュ１４中に蓄えるために、マウントのためのデータベースにおいてマウントのための情報を参照する。特定されたファイルが既に貯蔵されているとき、アクセスサーバ１７は、ＩＰＣメッセージを共有ライブラリへと送る。共有ライブラリ１６は、それから、特定されたファイルをキャッシュ１４から取り出す。ファイルがアプリケーション１５により閉じられているとき、アクセスサーバ１７は、ファイルを遠隔サーバ１９へと戻す。特定されたファイルがローカルファイルである、すなわち、システム１０中のどこかほかの近くの場所に蓄えられているとき、共有ライブラリ１６は、直接的にファイルにアクセスする。
【００１８】
遠隔ファイルサーバは、個々のファイルの読み込み及び書き込みのためではなくシステムファイルを開く及び閉じるためのみに接続されるので、好ましくは、インターネットファイルは、開いているとき、ローカルファイルシステム上でそっくりそのまま貯蔵される。この方法によると、個々のページに対する一連のシステム要求と応答としてではなく、そのファイル全体が取得される場合、ファイルを伝送することにより生じる全ネットワークオーバーヘッドは、より低い。インターネットを介してのファイルへのアクセスは、包括的なシステム資源の消費に関して無駄が多いので、ファイルの貯蔵されたコピーがアクセスを受けたとき、本発明は、キャッシュのデータが遠隔サーバに蓄えられたマスターコピーデータと矛盾しないかどうかを決定する。
【００１９】
単一のアクセスサーバ１７が図１中の層２２に示されているが、複数のアクセスサーバが使用され得る。例えば、本発明の基本的な構成は、各々のシステムユーザーのためのアクセスサーバ１７及び各々のユーザーのアクセスサーバの配置のためのシステムワイドネイムサーバを含み得る。
【００２０】
二者択一的に、ユーザーのグループは、特定のアクセスサーバ１７を共有し得る。本発明は、インターネット上に配置されたファイルサーバが、伝統的なシステムにおけるようにカーネルの実行としてよりもむしろ図２に示されるようにユーザー・レベルの実行としてマウントされることを可能とする。図２において、プロセス２３と関連する各々の共有ライブラリ１６は、従来技術において現在為されているように、関連するカーネル、（示されていない）ＮＦＳプロトコル及び（示されていない）アクセスサーバを通して処理されつつあるアプリケーションよりむしろアクセスサーバ１７に直接的にアクセスする。
【００２１】
図３は、ローカルシステム３０中のＰＮＳの概念を示す。第一のＰＮＳ３１は、／ｈｏｍｅ／ｂｏｂ／ＩＦＳにおいてローカルファイルシステム３０へとマウントされ、ユーザーＢｏｂにより所有されるということが示される。第二のＰＮＳ３２は、／ｈｏｍｅ／ｓｔｅｐｈａｎｉｅ／ｔｍｐ／ＩＦＳにおいてマウントされ、ユーザーＳｔｅｐｈａｎｉｅにより所有されるということが示される。ＰＮＳは、ディレクトリの組（マウントポイント、キャッシュディレクトリ）により定義され、ここでマウントポイントは、ＰＮＳがマウントされる或いはつながれるファイルシステムにおけるローカルパスネイムであり、キャッシュディレクトリは、遠隔ファイル及びディレクトリが貯蔵されるローカルディレクトリである。本質的に、マウントポイントは、マウントがどこに向いているかを表示する。図３において、ＰＮＳ３１のためのマウントポイントは、／ｈｏｍｅ／ｂｏｂ／ＩＦＳであり、ＰＮＳ３２のためのマウントポイントは、／ｈｏｍｅ／ｓｔｅｐｈａｎｉｅ／ＩＦＳである。キャッシュディレクトリは、ファイルシステムの構造においてキャッシュファイルを入れる場所として必要となる。多数のＰＮＳを支えるというタスクを簡単にするために、本発明は、マウントポイント及びキャッシュディレクトリのためにＩＲｏｏｔと呼ばれる単一のディレクトリを使用する。ＩＲｏｏｔは、遠隔ファイル及びディレクトリが貯蔵される遠隔ファイルシステム上でのＰＮＳ及び物理的なディレクトリのためのマウントポイントである。即ち、ＩＲｏｏｔはマウントポイント及びキャッシュディレクトリを含む。ユーザーは、コマンドiroot:$root pathnameを使用して、IRootを指定することにより、PNSを定義する。
【００２２】
図３に示されるように、ＰＮＳ３１のためのＩＲｏｏｔは、／ｈｏｍｅ／ｂｏｂ／ＩＦＳと定義され、一方ＰＮＳ３２のためのＩＲｏｏｔは、／ｈｏｍｅ／ｓｔｅｐｈａｎｉｅ／ｔｍｐ／ＩＦＳと定義される。ＰＮＳ３１及び３２は、ローカルネイムスペイス３０上で各々マウントされる。ＰＮＳ３１（／ｈｏｍｅ／ｂｏｂ／ＩＦＳ）のもとに配置されたファイル及びディレクトリは、ＰＮＳ３１を定義する特定のユーザーに対してのみアクセス可能である。ＰＮＳ１２を定義するユーザのような他のユーザーに対しては、／ｈｏｍｅ／ｂｏｂ／ＩＦＳのもとにあるファイル及びディレクトリは、不確定にされる。
【００２３】
ユニバーサルリソースロケイター（ＵＲＬ）命名方式は、本発明のシステム中に埋め込まれる。ＵＲＬ命名方式は、形式：
protocol://user:password@host/path
を有し、ここで、“protocol”は、アクセスプロトコルであり、
“user”は、オプショナルユーザーネイムであり、“password”は、オプショナルパスワードであり、“host”は、ネットワークホスト又はそのＩＰアドレスの完全に資格を与えられたドメインネイムであり、“port”は、接続されるオプショナルポートナンバーであり、及び“path”は、要求されるリソースにアクセスするために遠隔サーバにより使用されるパスである。アクセスプロトコルは、遠隔サーバに配置されるインターネットリソースへのアクセスに対するキーを提供するばかりでなく、アクセスサーバが配置されるシステムの異質性を隠しもする。すなわち、一度アクセスプロトコルが利用可能になれば、マシンタイプ又はサーバの動作システムに関係なく、プロトコルを使用してサーバにより提供されるリソースにアクセスすることが可能である。結果的に、本発明は、アクセスプロトコルの異質な集合を支える。
【００２４】
表Ｉは、マウントポイント及びキャッシュディレクトリを含むＩＲｏｏｔを示す“〜ＩＦＳ”を持つ例示的なパスネイム及び対応するＵＲＬネイムを示す。
【表１】
2007115244.tif 000011
【００２５】
次の典型的な仮コードは、
システムコールopen0を用いて、ホームページを開き、システムコールread0を用いてＵＲＬ名に位置するファイルを読み込み、生データとして同じくファイルのコンテンツを処理しシステムコールclose0を用いて、ファイルを閉じる。
システム・コールclose0：
【数１】
2007115244.tif 000012
【００２６】
本発明は、さらに、
インターネット・リソースが、既存のコマンド及びツールを用いて、検索され、管理され及び相互作用されることを可能とするサービスを提供する。
例えば、コマンド・ラインは、
$ls-/IFSnntp;/ulysses/comp.os.research/*
ニュース・サーバ“ulysses”上に格納されたニュース・グループ“comp.os.research”の中の記事を列挙する。更に、コマンドラインは、
$grep thread 〜 /IFS/nntp:/ulysses/comp.os.research/*
ニュース・グループ“ｃｏｍｐ．ｏｓ．ｒｅｓｅｒｃｈ”の中で、キーワード “thread”を検索する。
【００２７】
マウントは、間接的ネーミングを提供することでファイルをネーミングする場合にショートカットを生成し、又、遠隔サーバに接続するための認証情報を維持する。さらに、マウントは、それを介して本件発明が所望されたファイルサーバにアクセスする、代理サーバを特定することを許可する。ＰＮＳ及びＰＮＳ内のマウント地点の両方は、ユーザ単位を基本に定義される。本発明によれば、マウント操作は、ユーザをして、例えばPNSなどのネームスペースを、別のネームスペースへ取り付けることを可能にする。マウント操作は、グローバル名空間のトップにＰＮＳを結びつけることが可能で、遠隔ファイルシステムをＰＮＳに接続することが可能である。
マウントポイントは、コマンドマウントによって特定される：
$mount URLName MountPoint[Boxy Server : Port]
【００２８】
［有効期間］
“URLName”は、インターネットを越えてアクセス可能なファイル／階層のＵＲＬ名であり、“Mount Point”は、ＰＮＳ（例えば、ＩＦＳ、図３）の中の定義されたマウントポイントで“Proxy Server”は、任意の代理サーバパラメータであり、そして“Port”は、代理サーバのトップポートを特定するための任意のパラメータである。
【００２９】
代理サーバとポートパラメータが、特定された場合、本件発明は、特定された代理サーバを通って特定遠隔サーバにアクセスする。そのパラメータ有効期間（秒）は、マウント地点のもとにキャッシュされたファイルが有効であると考えられる一定期間を特定する。特に、ファイルがアクセスされた場合、キャッシュされたファイルは、その保持時間が、特定された有効期間での範囲内まで利用することが出来る。有効期間が終了すると、そのファイルは、ネットワークから獲得しなければならない。ＵＲＬ名は、ユーザ名及びパスワードを含み、そして、それらが存在する場合、本件発明は、パスワードを用いて、ユーザに代わって遠隔サーバへのアクセスを認証する。もし、パスワードの値が“−”であるならば、マウントコマンドは、願わくば次のプロントでパスワードを入力する様、ユーザに要求する。
【００３０】
図４は、遠隔ファイルシステムは、本件発明に従ってどの様にマウントされるかを描いている。図４では、異なるプロトコルを用いる遠隔ファイルシステムは、IRoot/home/bob/IFS(PNS31, 図３)上にマウントされる。gryphon.att.comのファイルサーバ４０は、以下の様に/home/bob/IFSにマウントされる。
$mount ftp://bob:-@gryphon.att.com.home/bob
/home/bob/IFS/research
password:******
このコマンドは、ｆｔｐプロトコルを用いて、gryphon.att.com.上のファイルサーバ４０に位置する階層ボブを、ノード／ｈｏｍｅ／ｂｏｂ／ＩＦＳ/ｒｅｓｅａｒｃｈにおいてＰＮＳ３１上にマウントさせる。この実施例の中で、そのマウントコマンドは“−”がパスワード領域で特定されたとして、パスワードを入力するようにＢｏｂに入力を促す。ユーザＢｏｂが、/home/bob/IFS/researchの下のファイルをいつアクセスしようとも、本発明は、ユーザＢｏｂの入力したログイン及びパスワードを用いて、Ｂｏｂに代わってgryphon.att.com.から対応するファイルを検索する。マウントコマンドの他の実施例は：
$mount rsh://king/home/rao/project/home/bob/IFS/project
この実施例に対して、
Ｋｉｎｇ（階層）でファイルサーバ４１に位置する階層 “project”は、認証されたアクセスを提供するrsh protocolを経て、ノード-/home/bob/IFS/projectの所でＰＮＳ３１上にマウントされる。ユーザーは、ＵＲＬ名の内側で、ユーザ名とパスワードを指定する。そのシステムは、ユーザのホームディレクトリ中の.rhostファイルから認証情報を得る。この事は、ネットワークを経て、許可パスワード情報が流出することを回避する。マウント・コマンドの以下の実施例の中で、マウント地点は匿名のｆｔｐアクセスを用いて生成される。：
$ mount ftp://tsx-ll.mit.edu/pub/linux
/home/bob/IFS/src/linux
radish:8000
ポート８０００上のradish上の代理サーバはtsx-ll.mit.eduにアクセスするために用いられる。この実施例に対して、tsx-ll.mit.edu上のファイル・サーバ４２の中の遠隔ディレクトリ'linux'は、ＰＮＳ３１の中のノード'linux'上にマウントされる。
【００３１】
本件発明は、キャッシュ検証プロセスを制御する２つの方法を提供している。まず、マウント・コマンドを用いて割り当てられた属性有効期間は、各ディレクトリに割り当てられる。各ディレクトリは、その親ディレクトリから有効期間を継承する。生成されたディレクトリの元で、コピーが有効期間中に検索されるならば、ファイルのキャッシュされたコピーは、その初期のコピーをチェックすることなく、有効であるとして取り扱われる。例えば、キャッシュされたファイルに対して有効期間が７２００秒に設定されるならば、キャッシュされたコピーは、７２００秒に対して有効であると考慮される。有効期間が、“−１”の場合は、キャッシュされたコピーは、常に有効であるとされる。有効期間が“０”の場合は、キャッシュされたコピーは、常に無効であるとされる。有効期間は、ディレクトリに関連されて多くの他の属性の用に動的に変更可能である。
【００３２】
第２の有効制御方法に対して、有効マスクとして述べられるプロセス単位でのマスクは、ディレクトリの有効期間を上書きするために提供される。子プロセスは、その親プロセスから有効マスクを継承し、ビルト−イン  シェルコマンド‘vmask’は、プロセス有効マスクを定義し、更新するために使用される。プロセス毎の有効マスクは、ディレクトリ毎の有効期間より高い優先順位を持っている。つまり、特定のタイプのファイルを扱う場合は、その有効時間は、マウント、例えば、アクセスされるファイルに従って決定される。ファイルを使用する目的を考慮する場合、その有効期間は、アプリケーションに従ったプロセスの時間、例えばアプリケーションがファイルを使用する時間、である。このように、有効期間を使って、キャッシュ検証プロセスは、共通著作文書対ネットワークニュースの様なインターネットのファイルタイプに従って、制御可能である。一方では、有効マスクはリフレッシュキャッシュ１４の様な特定の環境の中のプロセスレベル上の有効期間の上書きを許可する。
【００３３】
図５は、本件発明に従って、有効プロセス５０に対する流れ図を示す。ステップ５１で、キャッシュの中に要求された情報が存在するかどうか決定される。要求された情報が、そのキャッシュに存在するならば、処理の流れは、ステップ５２に引き継がれ、キャッシュが、有効期間又は有効マスクの下で有効かどうか決定される。有効であるならば、処理の流れは、ステップ５３に引き継がれ、キャッシュの中の情報は、システムコールに対して検索される。又、情報がキャッシュ（ステップ５１）の中に存在しない、又は、キャッシュが有効ではない（ステップ５２）であるならば、処理の流れはステップ５４に引き継がれ、メッセージは、共有ライブラリからアクセスサーバに送られる。処理の流れは、ステップ５５に引き継がれ、ここで、インターネットにアクセスし、その情報は検索され、そしてその後キャッシュに格納される。
【００３４】
図６は、図５に示されたプロセス５０のステップ５２の詳細な流れ図６０を示している。ステップ５２Ａでは、キャッシュが最後に、更新された時を決定する。次に、ステップ５２Ｂで、最後の更新時刻は、キャッシュされたコピーが有効であるか否かを決定するための有効期間又は有効マスクと比較される。
本件発明は、使用者を認証するために、サーバに対してそれ自身を確認する。その結果、共有ライブラリ１６及びアクセスサーバ１７は、好ましくは、分離実在としてシステム１０の内部に設定される。この方法で、共有ライブラリ１６は、ユーザの識別を認識する。アクセスサーバ１７は、システムコール要求をするユーザの識別を決定できるように設定されないため、アクセスサーバ１７は、共有ライブラリ１６から、インターネットに接続されたサーバに通知する情報を得る。次に、アクセスサーバが、ユーザ認証を実施可能になる前に、共有ライブラリ１６はそれ自身をアクセスサーバ１７に確認する。
【００３５】
本件発明は、又、匿名及び認証されたインターネットへの直接的アクセス又は代理サーバ経由の両方をサポートする。本件発明に従えば、ユーザは、ファイルアクセスのための適切なログイン名及びパスワード情報を用いて、遠隔サーバに、彼ら自身を認証できる。認証されたアクセスは、最初に共有ライブラリ１６が、要求が認証されるべきことを、アクセスサーバ１７と通信する、ハンドシェイクプロセスを含んでいる。アクセスサーバ１７は、その後、時刻刻印を得るためにファイルが生成されるべきであることを、共有ライブラリ１６に通信する。共有ライブラリ１６は、生成されたファイルを、アクセスサーバ１７に確認する。アクセスサーバ１７は、その後、情報を確かめるために、共有ライブラリ１６によって生成されたファイルにアクセスする。
【００３６】
本件発明が、描かれた実施例と関連して記載された一方で、本件の本質及び範囲からそれることなしに改良されることは、評価され、理解されるであろう。
【図面の簡単な説明】
【００３７】
本願発明は、いくつかの例によって説明されているが、同じ引用数字が同じ要素を示す添付図面に限定されるものではない。
【図１】本願発明に従ったシステムのアーキテクチャのブロック図である。
【図２】本願発明に従った異なるアプリケーションに対する矛盾のない共有をサポートするアーキテクチャを有するシステムのブロック図である。
【図３】本願発明に従ったパーソナル・ネーム・スペース（ＰＮＳ）の概念を示す図である。
【図４】本願発明に従った遠隔ファイルシステムのマウントを説明する図である。
【図５】本願発明に従った認証プロセスを示す流れ図である。
【図６】第５図の認証プロセスの段階の詳細を示す流れ図である。