(57)【要約】【課題】Ｐ２Ｐファイル共有ソリューションでは、ファイルとディレクトリの個数が増加するにつれ、システム・マネージャの作業量が非常に増加する。【解決手段】ピア・ツー・ピア・ファイル共有システム（１００）において、ファイル共有システムのサーバ・システム・コンポーネント（１０２）に仮想ディレクトリを提供して維持するソフトウェア・コンポーネントを含む。ファイル共有システムのクライアント・システム・コンポーネント（１０４ａ、１０４ｂ）は、サーバ・システムと協同して仮想ディレクトリへの操作を助ける。【選択図】　図１
2004005491.tif 000002
【特許請求の範囲】
【請求項１】
第１のファイルを登録する要求を表わす第１の情報を第１のクライアントから送信するステップであって、前記第１の情報には前記第１のファイルと、前記第１のクライアントと通信する第１のアドレスと、第１のディレクトリのパス名とを表わす情報を含むステップと、
サーバで前記第１の情報を受信し、これに応答して前記第１のファイルへの第１のリンクを前記第１のディレクトリのパス名で指定された前記サーバに含まれるディレクトリのロケーションに作成するステップと、
前記第１のリンクに前記第１のアドレスを関連付けるステップと、
前記第１のファイルへのファイル・リンクを作成する要求を表わす第２の情報を第２のクライアントから送信するステップであって、前記第２の情報は前記第１のファイルと、第２の識別子と、第２のディレクトリのパス名とを表わす情報を含むステップと、
前記第２の情報を前記サーバで受信し、これに応答して前記第２のディレクトリ・パス名に基づいて当該ディレクトリのロケーションに前記第１のファイルへの第２のリンクを作成するステップと、
前記第２のリンクと前記第１のアドレスを関連付けるステップと、
要求側クライアントから、前記サーバで、前記第１のファイル・リンク又は前記第２のファイル・リンクへの参照を含むアクセス要求を受信し、これに応答して前記要求側クライアントへ前記第１のアドレスを表わす情報を送信するステップとを含み、
前記要求側クライアントは前記第１のクライアントと通信して前記第１のファイルにアクセスできるようにすることを特徴とするピア・ツー・ピア・ファイル共有方法。
【請求項２】
サブディレクトリを作成する要求を表わす第３の情報を第３のクライアントから送信ステップであって、前記第３の情報は第３のディレクトリ・パス名を含むステップと、
前記サーバで前記第３の情報を受信し、これに応答して前記第３のディレクトリ・パス名で指定された当該ディレクトリのロケーションに前記サブディレクトリを作成するステップと、
をさらに含むことを特徴とする請求項１に記載のピア・ツー・ピア・ファイル共有方法。
【請求項３】
前記第１のクライアントの配布ファイル・アーカイブに前記第１のファイルのコピーを作成し、前記要求側クライアントは前記第１のファイルのコピーにアクセスしてローカル・コピーを作成するステップ
をさらに含むことを特徴とする請求項１に記載のピア・ツー・ピア・ファイル共有の方法。
【請求項４】
前記サーバで前記第１のファイルの前記コピーを削除する要求を受信するステップと、
十分な許可が存在することが決定された場合には前記第１のクライアントに削除命令を送信するステップと、
前記削除コマンドの受信に応答して前記第１のクライアントは前記第１のファイルの前記コピーを削除するステップと、
をさらに含むことを特徴とする請求項３に記載のピア・ツー・ピア・ファイル共有の方法。
【請求項５】
前記第１のクライアント・システムから前記第１のファイルの前記コピーを削除する前記要求を送信することを特徴とする請求項４に記載のピア・ツー・ピア・ファイル共有方法。
【請求項６】
前記第１のクライアント・システム以外のクライアント・システムから前記第１のファイルの前記コピーを削除する前記要求を送信することを特徴とする請求項４に記載のピア・ツー・ピア・ファイル共有方法。
【請求項７】
前記ローカル・コピーを作成するのと引き換えに通貨の形の支払いを行なうことをさらに含むことを特徴とする請求項３に記載のピア・ツー・ピア・ファイル共有方法。
【請求項８】
前記要求側クライアントのキャッシュ・ファイル・アーカイブに前記ローカル・コピーを格納するステップと、
前記要求側クライアントが他の要求側クライアントからの前記ローカル・コピーへのアクセスを提供するステップと、
前記他の要求側クライアントが前記ローカル・コピーにアクセスしたときに前記要求側クライアントが通貨の形で受け取るステップと、
をさらに含むことを特徴とする請求項３に記載のピア・ツー・ピア・ファイル共有方法。
【請求項９】
サーバ・システムにおいて、ピア・ツー・ピア・ファイル共有のための方法であって、
ファイル・リンクのディレクトリを保持するステップと、
ファイルと、前記ファイルのロケーションを表わす第１のアドレスと、前記ディレクトリ内の第１のディレクトリ・エントリとを表わす情報を含むファイル登録要求を受信するステップと、
前記第１のディレクトリ・エントリに基づいて前記ディレクトリ内のロケーションに前記ファイルへの第１のリンクを作成するステップと、
前記第１のリンクと前記第１のアドレスを関連付けるステップと、
前記ファイルと前記ディレクトリ内の第２のディレクトリ・エントリを表わす情報を含むファイル・リンク作成要求を受信するステップと、
前記第２のディレクトリ・エントリに基づいて前記ディレクトリ内のロケーションに前記ファイルへの第２のリンクを作成するステップと、
前記第２のリンクと前記第１のアドレスを関連付けるステップと、
前記第１のリンク又は前記第２のリンクを表わす情報を含むファイル・アクセス要求を受信するステップと、
ファイル・アクセス要求の受信に応答して、前記第１のアドレスを前記ファイル・アクセス要求の送信元へ送信するステップと、
を含むことを特徴とするピア・ツー・ピア・ファイル共有方法。
【請求項１０】
指定されたファイル・リンクについてファイル・リンク削除要求を受信するステップと、
前記ファイル・リンク削除要求の受信に応答して、前記指定されたファイル・リンクを前記ディレクトリから削除するステップと、
をさらに含むことを特徴とする請求項９に記載のピア・ツー・ピア・ファイル共有方法。
【請求項１１】
指定されたファイルについてファイル登録解除要求を受信するステップと、
前記ファイル登録解除要求の受信に応答して、前記指定されたファイルに関連する全てのファイル・リンクを削除するステップと、
をさらに含むことを特徴とする請求項９に記載のピア・ツー・ピア・ファイル共有方法。
【請求項１２】
指定されたファイルについて配布ファイル削除要求を受信するステップと、
十分な許可が存在する場合には前記指定されたファイルが作成されたクライアント・システムを特定するステップと、
前記クライアント・システムに対して前記クライアント・システムから前記指定されたファイルを削除する削除コマンドを送信するステップと、
をさらに含むことを特徴とする請求項９に記載のピア・ツー・ピア・ファイル共有方法。
【請求項１３】
前記ファイルへ前記送信元がアクセスするステップと、
前記ファイルへのアクセスと引き換えに前記送信元から通貨の形での支払いを受け取るステップとをさらに含むことを特徴とする請求項９に記載のピア・ツー・ピア・ファイル共有方法。
【請求項１４】
前記送信元が前記ファイルにアクセスし前記送信元のキャッシュ・ファイル・アーカイブ内にキャッシュ・ファイルとして前記ファイルのコピーを格納し、
さらに、クライアント・システムが前記キャッシュ・ファイルにアクセスできるようにするのと引き換えに前記送信元へ通貨の形の支払いを行なうことを特徴とする請求項９に記載のピア・ツー・ピア・ファイル共有方法。
【請求項１５】
クライアント・システムが前記送信元のキャッシュ・ファイルへアクセスする度に支払いが行なわれることを特徴とする請求項１４に記載のピア・ツー・ピア・ファイル共有方法。
【請求項１６】
コンピュータ・システムを含むピア・ツー・ピア・ファイル共有のサーバ・システムにおいて、
コンピュータ・プログラム・コードを含むコンピュータで読み取り可能な記憶媒体を含み、前記コンピュータ・プログラム・コードは前記コンピュータ・システムで実行されるのに適したものであって、前記コンピュータ・プログラム・コードは、
前記コンピュータ・システムを動作させてファイル・リンクのディレクトリを維持するように機能する第１のプログラム・コード、
前記コンピュータ・システムを動作させて、ファイルと、前記ファイルのロケーションを表わす第１のアドレスと、前記ディレクトリ内の第１のディレクトリ・エントリとを表わす情報を含むファイル登録要求を受信するように機能する第２のプログラム・コード、
前記コンピュータ・システムを動作させて、前記第１のディレクトリ・エントリに基づいて前記ディレクトリ内のロケーションに前記ファイルへの第１のリンクを作成するように機能する第３のプログラム・コード、
前記コンピュータ・システムを動作させて、前記第１のリンクと前記第１のアドレスを関連付ける第４のプログラム・コード、
前記コンピュータ・システムを動作させて、前記ファイルと前記ディレクトリ内の第２のディレクトリ・エントリを表わす情報を含むファイル・リンク作成要求を受信する第５のプログラム・コード、
前記コンピュータ・システムを動作させて、前記第２のディレクトリ・エントリに基づいて前記ディレクトリ内のロケーションに前記ファイルへの第２のリンクを作成する第６のプログラム・コード、
前記コンピュータ・システムを動作させて、前記第２のリンクと前記第１のアドレスを関連付ける第７のプログラム・コード、
前記コンピュータ・システムを動作させて、前記第１のリンク又は前記第２のリンクを表わす情報を含むファイル・アクセス要求を受信する第８のプログラム・コード、及び
前記コンピュータ・システムを動作させて、ファイル・アクセス要求の受信に応答して、前記第１のアドレスを前記ファイル・アクセス要求の送信元へ送信する第９のプログラム・コード、
を含むことを特徴とするコンピュータ・プログラム製品。
【請求項１７】
前記コンピュータ・システムを動作させて前記送信元が前記ファイルにアクセスしたときに前記送信元から通貨の形の支払いを受け取るように動作する第１０のプログラム・コードをさらに含むことを特徴とする請求項１６に記載のコンピュータ・プログラム製品。
【請求項１８】
前記送信元が前記ファイルにアクセスして前記送信元のキャッシュ・ファイル・アーカイブ内にキャッシュ・ファイルとして前記ファイルのコピーを格納し、
さらに、前記コンピュータ・システムを動作させてクライアント・システムが前記キャッシュ・ファイルにアクセスできるようにするのと引き換えに前記送信元へ通貨の形の支払いを行なうように動作する第１０のプログラム・コードを含むことを特徴とする請求項１６に記載のコンピュータ・プログラム製品。
【請求項１９】
クライアント・システムが前記送信元のキャッシュ・ファイルへアクセスする度に支払いが行なわれることを特徴とする請求項１８に記載のコンピュータ・プログラム製品。
【請求項２０】
ピア・ツー・ピア・ファイル共有のサーバ・システムであって、
コンピュータ・プロセッサ・コンポーネントと、
コンピュータ・メモリ・コンポーネントと、
データストレージ・コンポーネントと、
前記コンピュータ・メモリ・コンポーネントと前記データストレージ・コンポーネントの間で様々に格納されるコンピュータ・プログラム・コードを含み、前記コンピュータ・プログラム・コードは、
前記コンピュータ・プロセッサ・コンポーネントを動作させてファイル・リンクのディレクトリを維持するように機能する第１のプログラム・コード、
前記コンピュータ・プロセッサ・コンポーネントを動作させて、ファイルと、前記ファイルのロケーションを表わす第１のアドレスと、前記ディレクトリ内の第１のディレクトリ・エントリとを表わす情報を含むファイル登録要求を受信するように機能する第２のプログラム・コード、
前記コンピュータ・プロセッサ・コンポーネントを動作させて、前記第１のディレクトリ・エントリに基づいて前記ディレクトリ内のロケーションに前記ファイルへの第１のリンクを作成するように機能する第３のプログラム・コード、
前記コンピュータ・プロセッサ・コンポーネントを動作させて、前記第１のリンクと前記第１のアドレスを関連付ける第４のプログラム・コード、
前記コンピュータ・プロセッサ・コンポーネントを動作させて、前記ファイルと前記ディレクトリ内の第２のディレクトリ・エントリを表わす情報を含むファイル・リンク作成要求を受信する第５のプログラム・コード、
前記コンピュータ・プロセッサ・コンポーネントを動作させて、前記第２のディレクトリ・エントリに基づいて前記ディレクトリ内のロケーションに前記ファイルへの第２のリンクを作成する第６のプログラム・コード、
前記コンピュータ・プロセッサ・コンポーネントを動作させて、前記第２のリンクと前記第１のアドレスを関連付ける第７のプログラム・コード、
前記コンピュータ・プロセッサ・コンポーネントを動作させて、前記第１のリンク又は前記第２のリンクを表わす情報を含むファイル・アクセス要求を受信する第８のプログラム・コード、及び
前記コンピュータ・プロセッサ・コンポーネントを動作させて、ファイル・アクセス要求を受信し、これに応答して、前記第１のアドレスを前記ファイル・アクセス要求の送信元へ送信する第９のプログラム・コード、
を含むことを特徴とするシステム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明はファイル共有システムに関し、さらに詳しくはピア・ツー・ピア・ファイル共有方法及びシステムに関する。
【０００２】
【従来の技術】
従来のピア・ツー・ピア（Ｐ２Ｐ）ファイル共有ネットワークでは、ファイルはそのプロパティたとえばファイル名、ファイル形式、ファイル・サイズなどが登録される。ファイル内の検索は、注目する主題に関連するキーワードを識別してキーワードを用いたファイル・プロパティの検索を実行することによる。
なお、一般的なピア・ツー・ピア（Ｐ２Ｐ）ファイル共有ネットワークに関しては、非特許文献１等に開示されている。
【０００３】
Ｐ２Ｐファイル共有システムでは、ユーザがクライアント・ソフトウェア（ブラウザ）をローカルなコンピュータ・システムたとえばパーソナル・コンピュータに導入する。使用において、ユーザはブラウザを使用して管理サーバに登録しようとするファイルを指定する。ブラウザは指定されたファイルのファイル・プロパティを読み取り、ファイル・プロパティを管理サーバへ登録する。ブラウザは又ファイル・ロケーション情報（たとえばローカル・コンピュータのＩＰアドレスやファイルが存在するディレクトリなど）をサーバに送信する。
【０００４】
ファイル・プロパティを管理サーバに登録した後、ユーザは（ブラウザをつかって）管理サーバへ要求を送信してユーザが供給したキーワードを使用したファイル・プロパティの検索を行なうことができる。管理サーバは検索結果としてキーワードと一致するファイル・プロパティのリストを送信する。ユーザはリストからダウンロードしたいファイルを選択する。ブラウザは管理サーバへファイル・ロケーション情報の要求を送信し、管理サーバはユーザへファイル・ロケーション情報を返す。ブラウザはファイル・ロケーション情報を使用してファイルを含むコンピュータ・システム（群）へ接続し、これらのコンピュータ・システムからファイルを直接ダウンロードする。
【０００５】
Ｐ２Ｐファイル共有の利点は、物理的ファイルがユーザのローカルなコンピュータ・システムに分散している点である。その結果、管理サーバにかかるストレージ負荷はクライアント／サーバ・システムに比べて大幅に減少する。また、ファイルは一つのユーザ・コンピュータから別のコンピュータへ直接ダウンロードできるので（そのため術語「ピア・ツー・ピア」と呼ばれる）計算負荷やネットワーク帯域幅が多数のユーザコンピュータ・システム間で負荷平衡させることができる。こうした理由から、Ｐ２Ｐファイル共有の方法はクライアント／サーバ方式と比較していっそうスケーラブルなファイル・ストレージの方法を提供している。
【０００６】
【非特許文献１】
”Ｐｒｏｄｕｃｔ　Ｄｅｓｃｒｉｐｔｉｏｎ　ｏｆ　ＮｅｘｔＰａｇｅ，　Ｉｎｃ．，　ＮＸＴ　ＴＭ　３　Ｃｏｎｔｅｎｔ．　Ｃｏｎｎｅｃｔｅｄ，　２００１”
【０００７】
【発明が解決しようとする課題】
ある種のＰ２Ｐファイル共有ソリューションでは、ユーザがブラウズしてファイルを選択するようにディレクトリ・メニューを提供している。このディレクトリはシステム・マネージャ（たとえばサービス・プロバイダ）が管理サーバに作成し管理している。このディレクトリはユーザが容易に変更できないようになっているが、ディレクトリの作成と消去及びファイルの登録と消去はシステム・マネージャによって行なわれる必要があるためである。ファイルとディレクトリの個数が増加するにつれ、システム・マネージャの作業量は非常に増加する。
【０００８】
ここにＰ２Ｐファイル共有方法の改良の必要性があることが理解できよう。
【０００９】
【課題を解決するための手段】
本発明のピア・ツー・ピア・ファイル共有の方法及びシステムは、サーバ・システムと複数のクライアント・システムを含む。前記サーバ・システムには仮想ディレクトリが保持されており、クライアント・システムでユーザによるファイル管理を容易にする。ユーザがディレクトリに対する様々な操作を行ない容易に前記システム内のファイルの目録作成をできるようにすると同時に、ピア・ツー・ピア・ファイル共有システムの利点を提供する。
【００１０】
【発明の実施の形態】
図１は、本発明の一実施例によるピア・ツー・ピア・ファイル共有システムの一例を示す図である。図１の（Ａ）はピア・ツー・ピア・ファイル共有システム１００の一例を示す高レベル・システム・ブロック図であり、図１の（Ｂ）は代表的な階層構造のディレクトリ構造を示す図である。
図１の（Ａ）の資源命名サービス（ＲＮＳ）サーバ１０２は、「ファイル・リンク」のディレクトリを格納し管理している。ディレクトリは別のディレクトリへ接続するリンクを有することができる。ディレクトリの構造（すなわちディレクトリがどのように相互接続されているか）は、階層型木構造であったり、またはメッシュ構造又は何らかの他の従来の構造とすることができる。各ディレクトリの配下には複数のファイル・リンクが存在する。ファイル・リンクは物理ファイルへの参照である。後述するように、物理ファイルはシステム全体に配布されるのが普通である。ＲＮＳサーバは各々の物理ファイルに関連するファイル・プロパティも格納し管理する。ＲＮＳサーバは何らかの適当な計算プラットホームとすることができ、これには１台のＰＣ（パーソナル・コンピュータ）やワークステーション、マルチプロセッサ・システム、分散コンピューティング・システムまでが包含される。サーバで代表的なハードウェアは計算コンポーネント、メモリ・コンポーネント、データストレージ・コンポーネントを含む。コンピュータのプログラム・コードはデータストレージ・コンポーネントとメモリ・コンポーネントの両方に格納することが可能で、サーバ・システムの通常の運用中に二つのコンポーネントの間で入れ換えることができる。
【００１１】
サーバ・ソフトウェアは、図５から図１３に図示してあるフローチャートにより説明されている機能を提供する。何らかの適当なプログラミング言語や方法を使用して本発明によるサービスを提供できることが理解できよう。
【００１２】
図１の（Ｂ）は、ＲＮＳサーバ１０２で維持することができる階層型ディレクトリ構造の一例を示す。ディレクトリ１３２として図示した特定の実施態様は従来の木構造である。ルート・ディレクトリ（ノード１４２）が存在する。ルート・ディレクトリはサブディレクトリ又は実際のファイル・リンクを含むことができる。図面に示した例では、ルート・ディレクトリは３つのサブディレクトリ１４１ａ〜１４１ｃを有している。サブディレクトリ１４１ａはファイル・リンク１４３ａ〜１４３ｃを含む。
【００１３】
図１の（Ｂ）は、音楽のカテゴリーに分類されたディレクトリの特定の例を示している。つまり、各ノード（ディレクトリ）は音楽のカテゴリーを表現している。ルート・ノードはカテゴリー「音楽」（ＭＵＳＩＣ）である。サブカテゴリーは音楽の種類たとえばロック（ＲＯＣＫ）、クラシック（ＣＬＡＳＳＩＣＡＬ）、ポップ（ＰＯＰ）などを含むことができる。ＲＯＣＫのカテゴリー配下には、さらにカテゴリーおよび／またはファイル・リンクが存在できる。ファイル・リンクは物理ファイルの識別子である。一般に、ファイル・リンクはネットワーク経由でアクセス可能な何らかのオブジェクト、たとえば物理ファイル以外にもＰＣやプリンタ、ネットワーク・ノード、サービス、ユーザ、ユーザ・グループ、その他（ネットワーク資源と呼ぶこともある）への識別子である。
図１の（Ｂ）に図示した音楽の分類によるディレクトリの例では、ファイル・リンクは実際の音楽のオーディオ・ファイルや、歌詞を含むテキストファイル、ビデオ・ファイルその他のファイルへの識別子である。
【００１４】
図１の（Ａ）をまた参照すると、複数のクライアント・システム１０４ａ、１０４ｂが各々の通信リンク１１２ａ、１１２ｂを経由してＲＮＳサーバ１０２に接続されている。クライアント・システムは代表的にはＰＣやワークステーション及び同様のものを含む。クライアント・システムは一般にあらゆる適当な計算アーキテクチャで提供できることに注意する。後述するように、各々のクライアント・システムには本発明によるＲＮＳサーバと対話するのに適したソフトウェア（以下、ネットワーク資源ブラウザ、ＮＲＢソフトウェア、ＮＲＢクライアント、ＮＲＢブラウザと呼ぶ）が提供される。クライアント・システムは又通信リンク１１４経由で相互に通信する。一般に、通信リンク１１２ａ、１１２ｂ、１１４は既知の通信技術のいずれかに基づいたものとすることができる。
【００１５】
ＮＲＢソフトウェアの機能は、図５から図１３のフローチャートにより説明されている。ソフトウェアは多数のプログラミング言語や方法論のいずれかに基づいたものとすることができる。ＮＲＢソフトウェアは、ブラウジング・モードと編集モードの２つの動作モードで動作する。
【００１６】
要約すると、ブラウジング・モードでは、ユーザはＨＴＴＰ（ハイパーテキスト転送プロトコル）やＦＴＰ（ファイル転送プロトコル）ベースのウェブ・サーバをブラウズするのと同じ方法でディレクトリをブラウズすることができる。ブラウザはファイル・リンクのディレクトリとそのサブディレクトリを表示できる。ブラウザ表示の例が図１の（Ａ）の画面例１０６ａ、１０６ｂに図示してある。例にはマイクロソフト（登録商標）・エクスプローラに似たウィンドウ１２２に線形フォーマットで構成された従来のディレクトリ構造を示している。ユーザがディレクトリ上でクリックすると、ブラウザはそのディレクトリに移動する。ブラウザはウィンドウ１２４に現在のディレクトリに接続されているディレクトリやそのディレクトリに存在するファイル・リンクを表示する。マイクロソフト・エクスプローラのウィンドウは単に図示の目的で図示したものである。術語「ブラウザ」はたとえばネットスケープ・ナビゲータ・ブラウザその他の特定の一般に広く知られているブラウザに限定されるべきではない。逆に、「ブラウザ」はディレクトリを移動するための機能を提供できるあらゆるインタフェース（テキストベース、グラフィックスベース、仮想その他）を一般に表わすことを想定している。
【００１７】
編集モードでは、ユーザはサーバによって管理され格納されているサブディレクトリやファイル・リンクを編集できる。ユーザ・インタフェースは周知のウィンドウベースのインタフェースたとえばアップル社マッキントッシュのインタフェースやマイクロソフト社エクスプローラのインタフェースなどに準拠することができる。ディレクトリ構造はたとえば画面例１０６ａに示したようなもので、ウィンドウ１２２に図示されている選択したディレクトリ配下にあるウィンドウ１２４のサブディレクトリやファイル・リンクを一覧表示する。たとえば「ドラッグ・アンド・ドロップ」やコピー・アンド・ペーストなどの技術を使用することで、ユーザがディレクトリとファイル・リンクを追加したり、コピーしたり、移動したり、消去したりできる。
【００１８】
図２は、本発明によるクライアント・システム１０４の一実施例の実施態様を示す。クライアント・システムはそのコンポーネントの中でも、データストレージ・コンポーネント２０２を含む。データストレージ・コンポーネントはユーザ又はユーザ群がクライアント・システムにローカルに作成したファイルを格納するためのクライアント部分２１２を含む。ストレージ・コンポーネントは「配布ファイル」を格納するための配布ファイル・アーカイブ２１４を含む。ストレージ・コンポーネントはさらに「キャッシュ・ファイル」を格納するためのキャッシュ・ファイル・アーカイブ２１６も含む。
【００１９】
図面に図示してあるデータストレージ・コンポーネント２０２はクライアント・システムに設けたデータストレージ設備の抽象表現である。データストレージ・コンポーネントは単一のデータストレージ・ユニット、又は複数のデータストレージ・ユニット、又は他の何らかの適当な構成のデータストレージ能力とすることができる。
【００２０】
配布ファイルはユーザがＲＮＳサーバ１０２に「登録する」ローカル・ファイル２２２である（後述する）。これらのファイルはクライアント・システム１０４にローカルなもの、すなわち他のクライアント・システムからは通常はアクセスできない。ユーザがＲＮＳサーバのディレクトリの一つに（たとえば図１の（Ｂ））ローカル・ファイル２２２を登録すると、データストレージ・コンポーネント２０２のクライアント部分２１２にもともと格納されているローカル・ファイルのコピーが配布ファイル・アーカイブ２１４に配布ファイル２２４として格納される。配布ファイルは機密性を提供するように暗号化することができる。
【００２１】
キャッシュ・ファイル２３４は、データストレージ・コンポーネント２０２のキャッシュ・ファイル・アーカイブ２１６にキャッシュされるファイルのことである。ユーザが別のクライアント・システムからリモート・ファイル２３２をダウンロードした場合、ユーザのクライアント・システム１０４で動作しているブラウザがダウンロードしたファイルのコピーをキャッシュ・ファイル・アーカイブ内にキャッシュ・ファイル２３４として格納する。キャッシュ・ファイルは暗号化できる。キャッシュ・ファイル２３４を暗号化することにより、格納されているキャッシュ・ファイルをユーザが変更することができなくなる。この制限により格納されたキャッシュ・ファイルが変更されないようにし、配布ファイルとキャッシュ・ファイルの間の完全性を保証する他、ファイル内容の改竄に対しても保証できるようになる。
【００２２】
図３は、ファイル・テーブル３００の概要図であり、ＲＮＳサーバ１０２で使用されて本発明による各種機能を提供するための情報を示している。ファイル・テーブルは、ＲＮＳサーバに「登録されている」各ファイルのある種の情報（ファイル・プロパティと呼ばれる）を含む。ファイルを登録すると、ファイルを表わす「ファイル・リンク」が作成されて、ファイル・テーブル内に格納される。ＲＮＳサーバに格納されているファイル・リンク各々についてエントリ（たとえば３１２ａ、３１２ｂ）が存在する。ユーザにより提供されたユニークなファイルＩＤ３０２が各ファイルに割り当てられる。ＲＮＳサーバはユーザがファイルを登録しようとしたときにサブディレクトリ内のファイルＩＤのユニーク性を保証することができる。
【００２３】
代表的には、ファイルＩＤは、ユーザによって提供されそのユーザにとって意味のある何らかの文字列である。ファイルＩＤはサーバ・ソフトウェアによる内部処理で使用されるが、その代わりとして内部的に生成したファイルＩＤ３０１を使用する方がより効率的なことがある。このような内部ＩＤは代表的には単純な数（たとえば配列のインデックス、メモリ・ロケーションのアドレス、など）で、ソフトウェアがより効率的に処理できる。
【００２４】
プロバイダＩＤ３０４は、ＲＮＳサーバにファイルを登録した本来のユーザを識別する。ＲＮＳサーバは各ユーザに関する情報を含むユーザ・テーブル（図示していない）を保持しており、これには特に情報として「ユーザＩＤ」を含んでいる。ファイル・テーブル３００のプロバイダＩＤフィールドにはユーザ・テーブルから取得したユーザＩＤが入る。
【００２５】
キャッシュ・ユーザ・リスト３０６は、「オンライン」状態にありファイルへのアクセスを提供することができるユーザのリストである。このリストは配布ファイル（図２の２２４）の本来のユーザがオンラインならそのユーザを含み、またクライアント・システムがキャッシュ・ファイル・アーカイブ（図２の２１６）にファイルをキャッシュしているオンライン・ユーザを含む。一つの特定の実施態様において、ユーザ・テーブル（図示していない）は各ユーザについて「ログイン」フィールドを含むことがあり、このフィールドはユーザがオンライン状態か否かを表わす。キャッシュ・ユーザ・リストは単純にオンラインかどうかと関係なく対応するクライアント・システムにファイルのコピーを有している全部のユーザのリストとすることもある。ユーザ・テーブル内の「ログイン」フィールドを参照することにより、ＲＮＳサーバはどのクライアント・システムがファイルへのアクセスを提供するために利用可能かを決定できる。
【００２６】
アクセス制御リスト・フィールド３０８は、ファイルへのアクセスを制限するために提供できる。アクセス制御（たとえば読み取り、書き込み、変更、消去など）は個人に基づいたものとすることができ、この場合各個人には特定のアクセス権が付与される。アクセス制御は個人のグループに基づくものとすることができる。また、ファイルへアクセス可能な全員に単一のアクセス権を適用することができる。
【００２７】
クライアント・システム１０４ａ（図１の（Ａ））がＮＲＢソフトウェアを実行している場合、ユーザは「オンライン」であると見なされる。ユーザ・テーブル（図示していない）は「ユーザ・アクセス情報」フィールドを含み、これによりユーザは他のユーザと通信できる。ユーザ・アクセス情報の顕著な例はユーザのＩＰ（Ｉｎｔｅｒｎｅｔ　Ｐｒｏｔｏｃｏｌ）アドレスで、これはインターネット上での通信に適したものである。プライベート・ネットワーク内で本発明が提供される場合には専用のアドレシング方式を使用することもある。より一般的には、任意のユーザについてのユーザ・アクセス情報は他のユーザと通信できる何らかの適当な情報で、他のユーザが当該任意のユーザと通信できるようにする。
【００２８】
本発明の実施例の実施態様によれば、ＮＲＢソフトウェアはログイン手順を開始して、ピア・ツー・ピア・ファイル共有の目的でＲＮＳサーバ１０２へクライアント・システムが利用可能であることを通知する。ユーザがＲＮＳサーバへ「通知」されると、サーバは配布ファイルとキャッシュ・ファイルを含めそのユーザのシステムに格納されているファイル・テーブル内の各ファイルのキャッシュ・ユーザ・リスト３０６を更新する。このようにしてユーザは、そのクライアント・システムの配布ファイル・アーカイブ（図２の２１４）とキャッシュ・ファイル・アーカイブ２１６に含まれるファイルについてのもう一つのアクセス・ポイントになる。
【００２９】
ＮＲＢソフトウェアが終了する場合、ログアウト手順が開始され、ログアウトされるクライアント・システムがピア・ツー・ピア・ファイル共有でこれ以降利用できなくなることをＲＮＳサーバに通知する。別の実施態様では、ＮＲＢソフトウェアとＲＮＳサーバは「心拍」技術を使用してＮＲＢソフトウェアがいつ実行を終了したかを決定できる。これはオペレーティング・システムがクラッシュしたりロックアップし易いような、安定性の良くないオペレーティング・システムに適しており、またサーバとクライアントの間の通信が途切れてしまう他の何らかの壊滅的状況が起こり易い場合に適している。このような場合、適切なログアウト手順が不可能でありＲＮＳサーバはクライアント・システムが利用できないことを検出できなくなる。ユーザがすでにＲＮＳサーバに「ログイン」していない場合、ユーザの配布ファイル・アーカイブ２１４又はキャッシュ・ファイル・アーカイブ２１６に含まれるファイル・テーブルの各ファイルのキャッシュ・ユーザ・リスト３０６が更新されて、そのユーザからこれらの特定のファイルが利用できなくなったことを反映するようにする。
【００３０】
図４は、ファイル・リンクのディレクトリ・テーブル４００の概要図であり、ＲＮＳサーバ１０２によって使用される情報（集合的に「ディレクトリ・プロパティ」と呼ぶ）を示す。ディレクトリＩＤ４０２はディレクトリ・ノードの名前を表わし、たとえば図１の（Ｂ）でノード１４２のディレクトリＩＤは「ＭＵＳＩＣ」である。ディレクトリＩＤはサーバ・ソフトウェアが内部的に使用できるが、代わりに内部的に生成したディレクトリＩＤ４０１を使用する方がより効率的なことがある。このような内部ＩＤは、代表的には単純な数（たとえば配列のインデックス、メモリ・ロケーションのアドレス、など）で、ソフトウェアがより効率的に処理できる。
【００３１】
プロバイダＩＤ４０４は、ディレクトリ・ノードを作成したユーザを表わす。親ディレクトリ・フィールド４０６は親ノードへの逆リンクを提供する。子ディレクトリ・フィールド４０８は、このディレクトリに含まれるサブディレクトリを指す。親及び子ディレクトリ・フィールドは内部的に生成したディレクトリＩＤ４０１のリストを含むことができる。ファイル・リスト・フィールド４１０はこのディレクトリに含まれるファイルを指定する。ファイル・リスト・フィールドはファイル・テーブル３００から内部的に生成したファイルＩＤ３０１のリストを含むことができるので、物理ファイルからディレクトリ・テーブル内のサブディレクトリへのリンクを作成できる。（そのため「ファイル・リンク」と呼ぶ）。ファイルは物理的に様々なクライアント・システム上に存在しているので、サーバ・システムに含まれるディレクトリは仮想ディレクトリであると考えることができる。
【００３２】
ディレクトリ・アクセス制御リスト４１２はファイル・リンクについて前述したのと同じ方法でディレクトリに対するアクセスを制限するために提供できる。
【００３３】
ファイル・テーブルとディレクトリ・テーブルに関して通常用いられている種々の実施態様が可能であることは理解できよう。たとえば、データベース・システムはファイル・テーブルとディレクトリ・テーブルの機能を提供するように設計できる。カスタマイズされたソフトウェアを書く場合、ファイル・テーブルとディレクトリ・テーブルは様々な相関データ構造その他を用いて実施することができる。
【００３４】
本発明の実施例の特定の実施態様において、ＶＲＬ（仮想資源ロケータ）はＲＮＳディレクトリのファイル・リンクのロケーションを識別するために用いる。ＶＲＬはＵＮＩＸ（登録商標）風の命名規則を用いて、ルート・ノードの名前ではじまりファイル・リンクのディレクトリ名で終わり、中間にディレクトリの列を含み、たとえばＶＲＬ“／ｒｏｏｔ／ｄｉｒｅｃｔｏｒｙＡ／ｄｉｒｅｃｔｏｒｙＢ／ｆｉｌｅＡ”は「ｒｏｏｔ」というルート・ノードの名前で、中間のサブディレクトリとして各々「ｄｉｒｅｃｔｏｒｙＡ」と「ｄｉｒｅｃｔｏｒｙＢ」を含むディレクトリ内にあるファイル・リンク「ｆｉｌｅＡ」を識別する。
【００３５】
以下は、本発明によるクライアント及びサーバ・ソフトウェアにより集合的に提供される機能の高レベル記述である。以下のシステム手順が提供される：
ディレクトリのブラウジング
ファイルのダウンロード
ディレクトリの作成
ファイルの登録
ファイル・リンクの作成
ディレクトリの消去
ファイルの登録解除
ファイル・リンクの消去
配布ファイルの消去
【００３６】
図５は本発明の実施例の特定の実施態様によるディレクトリをブラウズするための処理の高レベル・フロー図である。ステップ５０２では、要求側ＮＲＢクライアント・システムのＮＲＢソフトウェアがブラウザＵＩ（たとえば図１の（Ａ）のウィンドウ１２２）に表示されたＲＮＳサーバ・ディレクトリからのユーザによる選択を検出する。ユーザの選択を検出したことに応答して、ディレクトリ・プロパティの要求が選択されたディレクトリのＶＲＬと一緒にステップ５０４でＲＮＳサーバへ送信される。
次に、ステップ５０６で、ＲＮＳサーバはＶＲＬに基づいてディレクトリ構造を検索してディレクトリ・プロパティを取得する。ステップ５０８とステップ５１０では、選択されたディレクトリのアクセス制御リスト４０８を検証してユーザが選択されたディレクトリへのアクセスを許可されているかどうか判定する。ユーザがアクセス権を持っていない場合、ステップ５１２でサーバは単純にＮＲＢソフトウェアへ拒絶応答を返す。ＮＲＢソフトウェアは多数の方法のいずれかでユーザに対して拒絶を表示できる。他方で、ユーザが選択されたディレクトリへのアクセス権を持っている場合、サーバはステップ５１４で選択されたディレクトリのディレクトリ・プロパティの幾つか又は全部を送信する。次にステップ５１６でブラウザは子ディレクトリやファイル・リンクなどのディレクトリ・プロパティを適当なフォーマットで表示できる。
【００３７】
図６は、本発明の実施例の特定の実施態様によるファイル共有システムからファイルをダウンロードする処理の高レベル・フロー図である。ステップ６０２では、要求側クライアント・システムにいるユーザ（ユーザＡ）がＲＮＳサーバのファイル・リンクを選択する。これがＮＲＢソフトウェアにより検出され、ユーザＡのシステムへ選択されたファイルをダウンロードする要求を開始する。ステップ６０４では、ＮＲＢソフトウェアはファイル・リンクのＶＲＬを含むファイル・ダウンロードの要求を送信する。ステップ６０６とステップ６０８では、サーバ・ソフトウェアがＶＲＬに対応する選択されたファイルのファイル・プロパティにアクセスし、選択されたファイルのアクセス制御リスト３０８を検査する。ステップ６１０とステップ６１２では、ユーザＡが要求されたダウンロード操作の許可を持っていないことを選択されたファイルのアクセス制御リストが示している場合、サーバはＮＲＢソフトウェアへ拒絶表示を送信する。
【００３８】
ダウンロード操作が許可されていることを選択されたファイルのアクセス制御リスト３０８が示している場合、ステップ６１４で、サーバ・ソフトウェアはキャッシュ・ユーザ・リスト３０６からユーザ（たとえばユーザＢ）を選択する。なお、キャッシュ・ユーザ・リストは要求されたファイルのコピーを保有しているユーザのリストである。ユーザ・テーブルの「ログイン」フィールド（図示していない）はログインしているユーザを表わしている。ユーザ・テーブルの「ユーザ・アクセス情報」はＲＮＳサーバに「ログイン」していてキャッシュ・ファイル・アーカイブ２１６に要求されたファイルを保有しているＮＲＢブラウザへのアクセスを提供する。
【００３９】
キャッシュ・ユーザ・リストからのユーザの選択は何らかの適当な基準に基づいて行なうことができる。たとえば、要求側クライアント・システムと要求されたファイルを供給することになるクライアント・システムとの地理的位置に基づいて選択を行なうことができる。各々のクライアント・システムについて追跡できるメトリックに基づいて、たとえばシステムのスループットやシステムの有効性、クライアント・システムに対するアクセス数、接続の品質などで選択を行なうことができる。選択は無作意選択とすることなども可能である。
【００４０】
ステップ６１６では、サーバはユーザＡのＮＲＢクライアントへ肯定応答を送信する。さらに、ユーザＢのＮＲＢクライアントについてユーザのアクセス情報がユーザＡのＮＲＢクライアントへ送信される。ステップ６１８で、ユーザＡとユーザＢの間に通信チャンネル／セッションが設定される。各々のＮＲＢブラウザが通信してユーザＢからユーザＡへ要求されたファイル（たとえば図２の２３２）のダウンロードを行なう。ステップ６２０では、ユーザＡがキャッシュ・ファイル・アーカイブ（図２の２１６）にダウンロードしたファイル（たとえば図２の２３４）を格納する。ステップ６２２で、ユーザＡのＮＲＢソフトウェアはＲＮＳサーバへファイル・キャッシュ完了メッセージを送信する。これに応答して、サーバはステップ６２４で選択されたファイルのキャッシュ・ユーザ・リスト３０６へユーザＡを追加する。
【００４１】
図７は、本発明の実施例の特定の実施態様によりサブディレクトリを作成する処理の高レベル・フロー図を示す。ステップ７０２では、要求側ＮＲＢクライアントのＮＲＢブラウザがユーザによるディレクトリ選択を検出する。ユーザは選択したディレクトリに追加しようとする新しいサブディレクトリの名前を提供する。ＮＲＢソフトウェアはステップ７０４でＲＮＳサーバに対して選択されたディレクトリでのディレクトリ作成要求を送信し、これには新規サブディレクトリを表わすＶＲＬを含む。ＲＮＳサーバはステップ７０６でディレクトリ構造を検索して選択されたディレクトリのディレクトリ・プロパティを取得する。サーバは次にステップ７０８で選択されたディレクトリのアクセス制御リストを検証してユーザがサブディレクトリを作成する許可を有しているか判定する。ステップ７１２で、ユーザが（ステップ７１０で）許可を持っていないと判定された場合、ＲＮＳサーバはクライアントに対して拒絶応答を送信する。ユーザがサブディレクトリを作成できる場合、サーバはサブディレクトリを作成し（ステップ７１４）、サブディレクトリの作成に成功したことを表わす肯定応答をＮＲＢブラウザに送信する（ステップ７１６）。
【００４２】
図８は、本発明の実施例の特定の実施態様によるファイルを登録する処理の高レベル・フロー図を示す。ステップ８０２で、要求側クライアント・システムのユーザはユーザのクライアント・システムにローカルなファイルを登録しようとするＲＮＳサーバでディレクトリを選択する。次に、ステップ８０４で、ブラウザ・ソフトウェアはＲＮＳサーバに対してファイル登録要求を送信する。これには宛先ディレクトリのＶＲＬが含まれる。この送信は登録しようとする各々のローカル・ファイルについてのファイル・プロパティ情報を含むことができる。ステップ８０６では、サーバはＶＲＬで指定されたディレクトリのディレクトリ・プロパティを取得し、ステップ８０８ではアクセス制御リストを検証して選択されたディレクトリにユーザがファイルを登録できるかどうか判定する。ステップ８１０でユーザがファイル登録のアクセス権を持っていないと判定された場合、サーバはステップ８１２で拒絶応答を送信する。
【００４３】
それ以外の場合、ステップ８１４で、サーバはユーザが指定した各ローカル・ファイルについてのエントリを作成し、エントリにユーザが提供したファイル・プロパティを書き込む。次に、ステップ８１６で、サーバは選択されたディレクトリにディレクトリ・テーブルにあるディレクトリ・エントリへファイルのエントリを追加し、これによりユーザが選択したローカル・ファイルへのファイル・リンクを作成する。ステップ８１８でブラウザ・クライアントへ肯定応答が送信される。これに応答して、ブラウザ・クライアントはステップ８２０でユーザの配布ファイル・アーカイブ（図２の２１４）に選択したローカル・ファイルの各々のコピーを作成する。コピー操作は暗号化ステップを含むことがある。次にステップ８２２で、ブラウザ・ソフトウェアはファイル・リンクの追加を表わすように表示を更新する。
【００４４】
図９は、本発明の実施例の特定の実施態様によるファイル・リンクを作成する処理の高レベル・フロー図を示す。この手順でユーザはすでに登録してあるファイルへ追加のファイル・リンクを作成できるようになる。ステップ９０２で、ユーザは登録してあるファイルのファイル・リンクをＮＲＢブラウザ経由で選択し、新しくファイル・リンクを配置しようとするディレクトリを選択する。ステップ９０４で、ＮＲＢブラウザはＲＮＳサーバに対してファイル・リンクを作成する要求を送信する。この要求には登録してあるファイルのファイル・リンクを表わすソースＶＲＬと新しくファイル・リンクを作成しようとするディレクトリの宛先ＶＲＬとを含む。サーバは、ステップ９０６で宛先ＶＲＬに基づいて宛先ディレクトリのディレクトリ・プロパティを取得してステップ９０８でこれのアクセス制御リストを検査する。ユーザがファイル・リンク作成許可を持っていないとステップ９１０で判定された場合、ステップ９１２でサーバは拒絶応答を送信する。それ以外の場合、ステップ９１４でサーバは宛先ディレクトリのファイル・リスト・フィールド４１０へ新しいファイル・リンクを追加する。次に、ステップ９１６でサーバは新規ファイル・リンクの追加を示す肯定応答をＮＲＢブラウザへ送信する。ＮＲＢブラウザはステップ９１８で表示を更新し、追加されたファイル・リンクを表示する。ステップ９０２で、ユーザが登録済みファイルに関連する何個かのファイル・リンクを選択できるが、これら全部が同じ物理ファイルを示すことには注意すべきである。
【００４５】
図１０は、本発明の実施例の特定の実施態様によるサブディレクトリを削除する処理の高レベル・フロー図である。ステップ１００２では、ユーザが削除しようとするサブディレクトリを選択する。ブラウザはＲＮＳサーバに対してサブディレクトリの削除要求を、ステップ１００４で送信する。ステップ１００６でサブディレクトリが空でないと判定される場合、ステップ１０１４で拒絶応答がブラウザへ返信される。拒絶応答はディレクトリが空ではないことを表わすことができる。
【００４６】
それ以外の場合、サーバはステップ１００８で選択されたサブディレクトリのディレクトリ・プロパティを取得して、アクセス制御リストを検査し、ユーザにサブディレクトリを消去する許可があるか判定する（ステップ１０１０）。ユーザが削除許可を持っていないと判定した場合（ステップ１０１２）、拒絶応答がステップ１０１４でブラウザへ送信される。それ以外の場合、サーバは指定されたサブディレクトリの削除を実行し（ステップ１０１６）、ステップ１０１８で肯定応答を送信する。ステップ１０２０でブラウザは表示を更新して削除されたサブディレクトリを反映することができる。
【００４７】
図１１は、本発明の実施例の特定の実施態様によるファイルの登録解除の処理の高レベル・フロー図である。ＮＲＢソフトウェアはステップ１１０２で登録を解除しようとするユーザ選択ファイルを検出する。これに応答して、ブラウザはＲＮＳサーバへファイルの登録解除要求を送信する。この要求には登録を解除しようとするファイルに関連するファイル・リンクのＶＲＬが含まれる（ステップ１１０４）。サーバは選択されたファイルに対応するファイル・リンクのファイル・プロパティにアクセスし（ステップ１１０６）十分な許可があるかどうかアクセス制御リストを検査する（ステップ１１０８）。ステップ１１１０でユーザが操作に対する許可を持っていないと判定される場合、拒絶応答がステップ１１１２でＮＲＢブラウザへ送信される。
【００４８】
操作が許可される場合には、サーバはステップ１１１４でファイル・リンクに関連する適当なファイル・テーブル・エントリ（群）を消去する。サーバはまた適当なディレクトリ・テーブル・エントリを更新してそのファイルがもはや登録されていないことを表わす（ステップ１１１６）。これには登録解除したファイルを参照する全部のファイル・リンク・エントリの消去が含まれる。その結果としてＲＮＳサーバからファイルがもはやアクセスできなくなる。さらに、サーバはキャッシュ・ファイル・アーカイブ２１６にファイルのコピーを含む各クライアントに対してアーカイブからファイルのコピーを消去するように指示を送信する。
【００４９】
ステップ１１１８では、ＲＮＳサーバはＮＲＢブラウザに対して肯定応答を送信する。これに応答して、ＮＲＢブラウザは配布ファイル・アーカイブ２１４に格納された物理ファイルを削除する（ステップ１１２０）。これに合わせてステップ１１２２で表示も更新されて削除を反映する。このシナリオではＮＲＢブラウザがオリジナルの物理ファイルを含むクライアント・システムであると仮定している。別のユーザにファイルの登録解除の能力を与えようとする場合、ＲＮＳサーバはどのクライアント・システムが配布ファイルを保有しているか決定する必要がある。
【００５０】
本発明の別の実施例として、システムはどのユーザにもファイルの登録解除を許可できる。このような実施例の特定の実施態様において、ファイル・テーブル３００のキャッシュ・ユーザ・リスト３０６は作成者のユーザＩＤがリストの先頭にくるような規則で構成する。作成したユーザのＮＲＢブラウザは、登録解除しようとするファイルのキャッシュ・ユーザ・リストからユーザ・テーブル（図示していない）と一緒に取り出した作成者ユーザＩＤを相互参照して「ユーザ・アクセス情報」を取得することにより簡単に特定できる。つまり、どのユーザも登録解除要求を作成できる。
【００５１】
図１２は、本発明の実施例の特定の実施態様によるファイル・リンクを削除する処理の高レベル・フロー図である。ステップ１２０２で、ＮＲＢブラウザは削除しようとするファイル・リンクのユーザによる選択を検出する。ブラウザはステップ１２０４で選択されたファイル・リンクを消去するようにＲＮＳサーバへ要求を送信する。ステップ１２０６でサーバは選択されたファイル・リンクのファイル・プロパティを取得し、ステップ１２０８でファイル・リンクのアクセス制御リストを検査して削除操作の条件を満たしているかどうか判定する。ステップ１２１０で操作を進められないと判定した場合、ステップ１２１２で拒絶応答がブラウザへ送信される。それ以外の場合、ステップ１２１４でサーバはファイル・テーブルとディレクトリ・テーブルに適当な更新を行なうことを含め指定されたファイル・リンクを削除する。ステップ１２１６でブラウザに対して肯定応答が送信され、これに応じてブラウザはステップ１２１８でＵＩディスプレイを更新してファイル・リンクの削除を反映する。
【００５２】
選択されたファイル・リンクだけが削除されることに注意すべきである。ファイルに対する他の全てのファイル・リンクはそのまま残る。しかし、そのファイル・リンクがファイルに対する最後の参照だった場合には、サーバは作成ユーザのクライアント・システムの配布ファイル・アーカイブから配布ファイルを削除する要求を送信できる。さらに、サーバはファイルがキャッシュ・ファイル・アーカイブに格納されているクライアントに対してキャッシュしているファイルを削除するように要求を送信することもできる。
【００５３】
図１３は、本発明の実施例の特定の実施態様による配布ファイルの削除をする処理の高レベル・フロー図である。この動作はＲＮＳサーバにファイルを登録し、後でそのユーザのクライアント・システムの配布ファイル・アーカイブ（図２の２１４）に格納スペースを確保したいが、システムからファイルの登録を解除したくはないユーザが行なうことがある。ステップ１３０２で、ユーザは削除しようとする配布ファイルを選択する。選択は配布ファイルに関連するＶＲＬに対応するいずれかのファイル・リンクを選択することで行なう。ブラウザは、ステップ１３０４でＶＲＬによって指定されたファイル・リンクに関連する配布ファイルを削除する要求を送信する。サーバは、ステップ１３０６で選択されたファイルのファイル・プロパティを取得して、ステップ１３０８でこれのアクセス制御リストを検査し、ユーザがその動作を実行する許可を持っているかどうか判定する。
【００５４】
ステップ１３１０で操作を実行できないと決定した場合、拒絶応答がステップ１３１２でブラウザへ送信される。それ以外の場合、ステップ１３１４でサーバはファイルに対応するファイル・テーブルのエントリを変更して配布ファイルがもはや存在しないことを表示する。たとえば、図３に関連して前述した特定の実施態様を考え、ファイル・テーブル３００のキャッシュ・ユーザ・リスト３０６が単純にファイルの物理コピーをクライアント・システムに有しているユーザ全部を列挙しているとする。このリストからファイルを作成したユーザのユーザＩＤを除去すると、ＲＮＳサーバはそれ以降のダウンロード要求に対してファイルのソースとして作成者ユーザを選択できないようになる。
【００５５】
ステップ１３１６で、配布ファイルが格納されているクライアント・システムのロケーションが決定され、ステップ１３１８でクライアント・システムから配布ファイルを消去する要求が送信される。ステップ１３１６では、ファイルのアクセス制御リストで当該動作を許容する限り、配布ファイルの作成ユーザ以外のユーザがファイルを削除できるようになる。次に、ステップ１３２０で、ファイル削除を要求したクライアント・システムへ肯定応答が送信される。サーバからの肯定応答に応答して、ステップ１３２２で、クライアント・システムはディスプレイを更新して削除されたファイルを反映する。
【００５６】
図１４は、本発明の一実施例によるコンテンツ取引サービス環境におけるピア・ツー・ピア・ファイル共有システムの高レベル・システム概略図である。
ＩＳＰ（インターネット・サービス・プロバイダ）１４１０は、資源命名サーバ（ＲＮＳ）として機能する。クライアント・システムはユーザＢ（１４０２），ユーザＣ（１４０４），ユーザＤ（１４０６）などのユーザを含む。コンテンツ取引サービスは、他の人が購入を希望するようなデジタルワーク製品をコンテンツ作成者が作成すると言う概念を前提としている。コンテンツ作者にデジタルワーク製品を作らせる動機となる要因は、当然のことながら作品を購入する人から代価を受け取ることの有益性である。ＩＳＰも同様に代価を受け取るのと引き換えにＲＮＳとして機能することが動機になっている。デジタルワーク製品のコピーをキャッシュ・ファイル・アーカイブ（図２の２１６）にキャッシュして保有するクライアント・システムも同様にキャッシュ・ファイル・アーカイブに格納された作品の潜在的購入者にアクセスを提供することが動機となり得ることが明らかになるであろう。
【００５７】
本発明によれば、デジタル・コンテンツをピア・ツー・ピア・システムで購入したいユーザは、ＩＳＰ１４１０から「ポイント」を購入する。これらのポイントはシステム内の通貨として機能する。何らかの初期時間Ｔ０で、ユーザＢとユーザＣがＲＮＳとして機能するＩＳＰからデジタル・コンテンツを購入したいと仮定する。ユーザＢとユーザＣは各々何らかの金額でＩＳＰから１０００ポイントを購入する。
【００５８】
さらに時刻Ｔ０で、ユーザＤがコンテンツ作成者であり、デジタルワーク製品をＩＳＰに登録したと仮定する。この動作は図８に概略したプロセスにしたがって実行される。これによりデジタルワーク製品がユーザＤの配布ファイル・アーカイブ（図２の２１４）にコピーされる。
【００５９】
時刻Ｔ１でユーザＣがユーザＤの作品を購入する希望があると仮定する。この動作は作品のダウンロードを実行することを含む。図６で概略したようなファイルのダウンロードのプロセスにしたがって、ユーザＣのクライアント・システムはファイル（ユーザＤのデジタルワーク製品）をどこで見付けられるかを表わすロケーション・アドレスをＩＳＰから入手する。この場合、そのロケーションはユーザＤのクライアント・システムである。ユーザＣはユーザＤからユーザＣのキャッシュ・ファイル・アーカイブへ作品をダウンロードする。
【００６０】
時刻Ｔ２で、ダウンロードが成功したと判定されると、ユーザＣはデジタルワーク製品についてユーザＤへポイントの支払を送付する。ユーザＣは又ユーザＤの作品へのアクセスを提供したサービス課金としてＩＳＰへの支払も送付する。つまり、図１４に示した例では、１００ポイントがユーザＤへ「支払われ」、５ポイントのサービス課金がＩＳＰへ「支払われる」。支払いは様々な方法のいずれかで行なうことができる。たとえば、ＩＳＰは自動的にユーザのアカウントに対してトランザクションから適当な「ポイント数」を課金して引落しを行なう会計メカニズムを提供することができる。
【００６１】
ここで、時刻Ｔ３で、ユーザＢがユーザＤのデジタルワーク製品を購入したいと仮定する。この動作は作品のダウンロードを実行することを含む。図６で概略したようなファイルのダウンロードのプロセスにしたがって、ユーザＢのクライアント・システムはファイル（ユーザＤのデジタルワーク製品）をどこで見付けられるかを表わすロケーション・アドレスをＩＳＰから入手する。今回、ファイルは二つの場所に配置されている：ユーザＤの配布ファイル・アーカイブとユーザＣのキャッシュ・ファイル・アーカイブである。ＩＳＰはクライアント・システム１４０４又は１４０６のいずれかのロケーションを返すことができる。選択は何らかの適当な基準に基づいて行なうことができる。たとえば、パフォーマンスが問題となる場合、ＩＳＰは近い方のクライアント・システムが高速なダウンロードを提供するであろうとの前提でユーザＢに近い方のクライアント・サーバのロケーションを提供することができる。本発明のこの態様を説明する目的で、ＩＳＰがユーザＣのロケーションを返すと仮定する。ユーザＢはユーザＣのキャッシュ・ファイル・アーカイブからユーザＢのキャッシュ・ファイル・アーカイブへ作品をダウンロードすることになる。
【００６２】
時刻Ｔ４で、ダウンロードが成功したと判定されると、ユーザＢはデジタルワーク製品についてユーザＤへポイントの支払を送付する。ユーザＢは又ユーザＤの作品へのアクセスを提供したサービス課金としてＩＳＰへの支払も送付する。
【００６３】
時刻Ｔ５で、ＩＳＰはたとえばユーザＢなどの第三者へユーザＣのキャッシュ・ファイル・アーカイブへのアクセスを提供したことに対してユーザＣにポイントの支払いを送付する。このユーザＣへの支払いはユーザＣがピア・ツー・ピア・ファイル共有システムにおいてコンテンツ・キャッシュ・プロバイダとして機能するための動機づけ要因となる。
【００６４】
ＩＳＰはポイントを使用しなかったユーザからポイントを回収できる。つまり、ユーザがシステムを切り離すと決定した場合、ユーザは未使用のポイントの対価を回収できる。別の例として、ユーザが何らかの閾値ポイント数を溜めた場合、ユーザはポイントの対価を回収できる。これは、作品の収入源としてコンテンツ作者には特に適しているであろう。
【００６５】
以上で説明した特定の構成は単に本発明の実施例による多くの実施態様を図示する目的であることが理解されよう。請求の範囲に記載したとおり本発明の趣旨と範囲から逸脱することなく、多くの変更が当業者によって成し得るものである。
【図面の簡単な説明】
【図１】本発明の一実施例によるによるピア・ツー・ピア・ファイル共有システムの一例を示す図であり、（Ａ）はピア・ツー・ピア・ファイル共有システム１００の一例を示す高レベル・システム・ブロック図、（Ｂ）は代表的な階層構造のディレクトリ構造を示す図である。
【図２】本発明の一実施例によるクライアント・システムのデータストレージ要素の模式図である。
【図３】本発明の一実施例によるファイル・テーブルの概要を示す図である。
【図４】本発明の一実施例によるディレクトリ・テーブルの概要を示す図である。
【図５】本発明によるファイル・リンクのディレクトリをブラウズするための基本的ステップを示す高レベル・フローチャートである。
【図６】本発明によるピア・ツー・ピア・ファイル共有システムからファイルをダウンロードするための基本的ステップを示す高レベル・フローチャートである。
【図７】本発明によるサブディレクトリを作成するための基本的ステップを示す高レベル・フローチャートである。
【図８】本発明によるファイルを登録するための基本的ステップを示す高レベル・フローチャートである。
【図９】本発明によるファイル・リンクを作成するための基本的ステップを示す高レベル・フローチャートである。
【図１０】本発明によるサブディレクトリを削除するための基本的ステップを示す高レベル・フローチャートである。
【図１１】本発明によるファイル登録を抹消するための基本的ステップを示す高レベル・フローチャートである。
【図１２】本発明によるファイル・リンクを削除するための基本的ステップを示す高レベル・フローチャートである。
【図１３】本発明による配布ファイルを削除するための基本的ステップを示す高レベル・フローチャートである。
【図１４】コンテンツ取引環境で使用される本発明の一実施例を示すシステム概略図である。
【符号の説明】
１００…ピア・ツー・ピア・ファイル共有システム、１０２…ＲＮＳサーバ、１０４ａ…クライアント・システム、１０４ｂ…クライアント・システム、１０６ａ…画面例、１０６ｂ…画面例、…、…、１１２ａ…通信リンク、１１２ｂ…通信リンク、１１４…通信リンク、１２２…ウィンドウ、１２４…ウィンドウ、１３２…ディレクトリ、１４１ａ〜１４１ｃ…サブディレクトリ、１４２…ノード、１４３ａ〜１４３ｃ…ファイル・リンク、２０２…データストレージ・コンポーネント、２１２…クライアント部分、２１４…配布ファイル・アーカイブ、２１６…キャッシュ・ファイル・アーカイブ、２２２…ローカル・ファイル、２２４…配布ファイル、２３２…リモート・ファイル、２３４…キャッシュ・ファイル、３００…ファイル・テーブル、３０１…内部ＩＤ、３０２…ファイルＩＤ、３０４…プロバイダＩＤ、３０６…キャッシュ・ユーザ・リスト、３０８…ＡＣＬ、３１２ａ…エントリ、３１２ｂ…エントリ、４００…ファイル・リンクのディレクトリ・テーブル、４０１…内部ＩＤ、４０２…ディレクトリＩＤ、４０４…プロバイダＩＤ、４０６…親、４０８…子、４１０…ファイルリスト、４１２…ＡＣＬ、１４０２…ユーザＢ、１４０４…ユーザＣ、１４０６…ユーザＤ、１４１０…ＩＳＰ（ＲＮＳ）。
【図１】
2004005491.tif 000003
【図２】
2004005491.tif 000004
【図３】
2004005491.tif 000005
【図４】
2004005491.tif 000006
【図５】
2004005491.tif 000007
【図６】
2004005491.tif 000008
【図７】
2004005491.tif 000009
【図８】
2004005491.tif 000010
【図９】
2004005491.tif 000011
【図１０】
2004005491.tif 000012
【図１１】
2004005491.tif 000013
【図１２】
2004005491.tif 000014
【図１３】
2004005491.tif 000015
【図１４】
2004005491.tif 000016