(57)【特許請求の範囲】
【請求項１】
ネットワークを介して複数のユーザーマシンに接続された電子ファイルシステムに格納された複数のファイルを管理する方法であって、
前記ネットワークと前記電子ファイルシステムとの間に設けられたコマンドユーティリティによって、該電子ファイルシステム内の各ファイルに、固有の識別番号としてのハンドルを割り当てるステップと、
前記電子ファイルシステム内の任意のファイルへのアクセス権を持つ前記ユーザーマシンの各々に、前記コマンドユーティリティによって、固有の識別番号を割り当てるステップと、
前記コマンドユーティリティと前記電子ファイルシステムの間に設けられたオブジェクトデータベースに、前記コマンドユーティリティによって、前記ファイルシステム内の各ファイルに対応づけられたオブジェクトが、前記ファイルのハンドルとファイルへのアクセス権を持つ前記ユーザーマシンの識別番号とを含むように生成されるステップと、
前記ファイルに割り当てられた各ハンドルを、前記コマンドユーティリティによって、該ハンドルに基づくＵＲＬに対応づけるステップと、
前記ユーザーマシンから前記ネットワークを通して所望のファイルについてのＵＲＬを入力すると、前記コマンドユーティリティが、該所望のファイルのハンドルを決定し、前記ユーザーマシンの識別番号を決定し、そして前記所望のファイルに対応づけられたオブジェクトを調べて、該ユーザーマシンが当該ファイルへのアクセス権を持つかどうかを決定するステップとから成る、
ことを特徴とする方法。
【請求項２】
請求項１に記載の方法において、各ユーザーマシンは、ＵＲＬを保存する、ユーザーに対応づけられたメモリを備えており、さらに、ユーザーマシンに、該ユーザーマシンが所望したファイルのための前記ハンドルに基づくＵＲＬをメモリに保存させるステップを含んでいることを特徴とする方法。
【発明の詳細な説明】
【０００１】
【産業上の利用分野】
本発明は、複数のユーザーがドキュメントまたはファイルのセットを作成し、共用することができるソフトウェア環境に関し、特に、各ファイルが独立の機密保護特性(Security Property) を有する共用データ環境における電子ファイルシステムの複数のファイルの管理方法に関する。
【０００２】
【従来の技術】
多数のユーザーがデータをドキュメント、ファイル、その他のエンティティの形で互いに交換する作業環境においては、全員に利用できる「公共スペース」内にある個々のドキュメントへユーザーのだれもがアクセス可能な共用資源を提供する必要がある。同様に、ドキュメントまたはファイルを作成したユーザーが自分の作品を他の人が見れるように、もし望むならば他の人が編集できるように、この公共スペースの中に置くことができる機構が必要である。同時に、共用ファイルシステムでは、ドキュメントの内容について一定の整理と管理ができるように、公に利用できるドキュメントに関して機密保護のための一定の機構をもっていることが望ましい。
【０００３】
先行技術では、上記の共用ファイルまたは共用ドキュメント環境を支援するいろいろな手法が知られている。あるタイプのマルチユーザー・ソフトウェア（一例は Xerox GlobalView ( 登録商標) ソフトウェア) は「共用ファイル・ドロワ（shared file drawer) 」の概念を提供している。共用ファイルドロワは、一組のユーザーの画面に提示されるアイコンであり、（一定のドキュメントは「読出し専用」ドキュメントとしてロックすることができるが、）ドロワへのアクセス権を有する誰もがその内容を変更することができる。しかし、前記 GlobalView ソフトウェアの場合、ドロワへの基本的アクセスはシステム管理責任者によってドロワのアイコンが与えられたユーザーに限られる。さらに、特定のドロワへのアクセス権を持つ人は少なくともそのドロワ内のすべてのドキュメントへの読出し専用アクセス権を有するであろう。
【０００４】
「共用ドロワ」の概念の変形は、Novell (登録商標) ネットワークドライブによってよく知られた「共用ドライブ」システムである。もう一度繰り返すと、一組のユーザーにはシステム管理責任者によって特定のドロワへのアクセス権が与えられなければならないし、またたいていは共用ドライブへのアクセス権を有する人はドライブ内のすべてのファイルへの完全なアクセス権を有する。ネットワークドライブシステムのもう１つの欠点は、各ユーザーとの関連において見ると、ドライブの構成がローカルエリアネットワーク（ＬＡＮ）のハードウェア構造と密接に関係していることである。
【０００５】
ファイルまたはドキュメントの共用を可能にするもう１つの機構は、「インターネット」または「ウェブサイト（website)」モデルに頼っている。このモデルの場合、ドキュメントはハイパーテキスト（hypertext)か、ホームページからの他のリンクによって存在することができる。個々のウェブサイトにリンクされた一定のドキュメントは、ドキュメントに対応づけられた機密保護特性（たとえばパスワードが必要である）を持つことができるが、このモデルは、もう一度繰り返すと、「ウェブマスター（web master) 」が上述のシステムのシステム管理責任者のやり方で全機密保護装置をうまく管理する必要があるという欠点を持つ。新しいドキュメントをウェブマスターの許可なしに利用することはできないことが多いので、ウェブマスターまたはシステム管理責任者の存在はシステムの活用性の障害であることを示す。さらにまた、ウェブマスターは積極的に中断せずに、ウェブサイトの管理に専念しなければならず、またウェブサイト内のハイパーテキスト・リンクは陳腐になることがある。すなわち、ウェブマスターはウェブサイトにリンクされた個々のドキュメントの所有権を持っていないことがあるので、もはや存在しないドキュメントになることがある。
【０００６】
【発明が解決しようとする課題】
以上のことから、上に述べた実用上の欠点を克服する共用データ環境が要望されている。
【０００７】
【課題を解決するための手段】
本発明は、電子ファイルシステムに格納された複数のファイルを管理する方法を提供する。本方法は、電子ファイルシステム内の各ファイルに固有の識別番号を割り当てるステップと、電子ファイルシステム内の任意のファイルへのアクセス権を持つユーザーに固有の識別番号を割り当てるステップと、ファイルの識別番号とファイルへのアクセス権を持つユーザーの識別番号とを含み、ファイルシステム内の各ファイルに対応づけられたオブジェクトを内部に有するオブジェクトデータベースを提供するステップと、ファイルに割り当てられた各識別番号をロケーション独立ＵＲＬへ対応づけるソフトウェア機構を提供するステップと、ユーザーが所望したファイルのＵＲＬを入力すると、所望したファイルの識別番号を決定し、ユーザーの識別番号を決定し、そして所望したファイルに対応づけられたオブジェクトを調べて、ユーザーが前記ファイルへのアクセス権を有するかどうかを決定するステップとから成る。
【０００８】
【発明の実施の形態】
システムの概略
最初に、以下の説明において使用する３つの特殊な用語を定義する。「ファイル」は、たとえばワードプロセッシング、グラフィックス、または表計算の書式で見るまたは編集するため検索することができるデータのファイルである。「オブジェクト」は、ファイルの一定の永続的な属性を記述するより小さい１個のメタデータである。「ハンドル」は、ファイルシステム内のファイル（または他のデータエンティティ）を、ファイルを記述するオブジェクトに対応づける単なる識別番号である。
【０００９】
図１は、本発明に係る環境の実施例の基本的な要素を示す略図である。本発明の環境の総合的な目的の１つは、ファイルシステム１２（たとえば、ハードドライブまたはネットワークサーバーの形であってもよい）に格納された種々のファイル（たとえば、ワードプロセッシングドキュメントまたは表計算ドキュメント）へ多数のユーザー１０がアクセスできるようにすることである。
【００１０】
本発明に従って、ファイルシステム１２内の個々のファイルはそれぞれ、ここで「オブジェクト」と呼ぶものに対応づけられている。この文脈において、ファイルシステム１２内のファイルに対応づけられた「オブジェクト」は、一組のメタデータ、別な言葉で言えば、アクセス特性（読出しおよび（または）書込み許可）、階層関係、およびファイルのその他の特性を記述するデータのフィールドまたはストリングである。本発明に従って、各ファイルに対応づけられた「オブジェクト」は、たとえばファイルが編集されたか、改名されたか、さもなければ変更されたかに関係なく、ファイルがファイルシステム１２内に存在する限り、実質上そのファイルに永久に対応づけられる。
【００１１】
図１を詳しく説明すると、複数のユーザー１０（各ユーザーはたとえばパーソナルコンピュータを制御する）は、ネットワーク１４を介してサーバー１６に接続されている。本発明の好ましい実施例に従って、サーバー１６は、各ユーザー１０のパーソナルコンピュータ上の標準インターネット・ブラウザーによってネットワーク１４を通してアクセスされる http サーバーである。ユーザー１０は標準ＵＲＬ（“universal resource locators ”の略) を通して、ネットワークまたはインターネット通信の場合によく知られたやり方でサーバー１６にアクセスする。
【００１２】
http サーバー１６は、ここで「コマンドユーティリティ」１８と呼んでいるものと通信する。コマンドユーティリティ１８は一組のプログラムすなわちサブルーチンであり、各プログラムは上に定義した「オブジェクト」に影響を及ぼす１つのコマンドに対応している。これらのオブジェクト（各オブジェクトはファイルシステム１２内の１つ又はそれ以上のファイルに対応づけられている）は、オブジェクトデータベース２０の中に保存されている。オブジェクトデータベース２０内の各オブジェクトはファイルシステム１２内の識別されたファイルにリンクされている。代わりに、各オブジェクトはリンクで（たとえば、別のネットワークを通して）ファイルの他のソースに対応づけることができる。
【００１３】
ユーザー１０がファイル、たとえばユーザーがネットワーク１４上のユーザーのサブセットへだけアクセスできることを望んでいるドキュメントを作成したい時は、ユーザーはネットワーク１４と http サーバー１６を介してそのドキュメントを“add file”または“create file ”などのコマンドと共にコマンドユーティリティ１８へ提出する。このユーザー１０からの要求に応じて、コマンドユーティリティ１８はユーザー１０の画面に現れている書式を特定のユーザー１０へ送り返す。ユーザー１０はファイルシステム１２へ提出しているファイルに関して所要の書き込みをする。
【００１４】
コマンドユーティリティ１８が要求する情報（以下に詳述する）の中に、ファイルを提出しているユーザー（そのファイルの「オーナーになる者」の名前、オーナーがそのファイルへの読出しおよび（または）書込みアクセスを許可した他のユーザーの名前のリスト、およびドキュメントの階層的「親」と「子」のリスト（すなわち、新しいファイルがファイルのより大きなコレクションの一部であることが意図されているかどうか、たとえば、１１月のファイルはコレクション「月例報告書」の中に置かれる）がある。ユーザーが提出するフィールド内のこのメタデータはすべて「オブジェクト」の一部になり、そのオブジェクトの一部はその後コマンドユーティリティ１８によってオブジェクトデータベース２０の中に置かれる。さらに、このファイルの提出と、コマンドユーティリティ１８によるオブジェクトの作成の後、コマンドユーティリティ１８はさらに、この文脈において「ハンドル」と呼ぶ固有の識別番号を生成し、このハンドルをオブジェクトおよびそのオブジェクトに対応づけられたファイルに永久に対応づける。従って、処理が終わると、ユーザー１０によって作成されたファイルはファイルシステム１２に格納され、オブジェクトはデータベース２０に格納される。ファイルとオブジェクトはそれらの共通ハンドルによって互いに対応づけられている。データベース２０内のオブジェクトは、ハンドルによって識別されたファイルの許可、階層、所有権、等を記述するデータのすべてを含んでいる。
【００１５】
以下に詳しく説明するように、ファイルシステム１２の中にファイル（またはコレクションまたはその他のエンティティ）が作成され、そのファイルにハンドルが割り当てられた後、コマンドユーティリティ１８はファイルに割り当てられたハンドルを指定する新しいＵＲＬを作成する。この新しいハンドルベースＵＲＬは、ファイルが最初に持っていたかもしれない最初のネットワークベースＵＲＬに事実上取って代わる。この新しいＵＲＬはその後ユーザー１０のブラウザー（browser)へ送られる。将来、ユーザー１０のブラウザー（たとえば、ブックマーク）は、その最初のＵＲＬでなく、もっぱらそのハンドルベースＵＲＬでファイルを参照するであろう。この特徴は、ＵＲＬがその最初のロケーションからのアーチファクトを含んでいる場合に生じる「陳腐リンク」を回避する見地から重要である。
【００１６】
後で、別のユーザー１０がファイルシステム１２内のファイルを読みたいと思ったとき、そのユーザーは http サーバー１６を介してファイルを要求する。一般に、ユーザーが読みたいと思ったファイルは、ユーザーがその通称をタイプするか、ハンドルをタイプするか、あるいは所望のファイルの通称がメニューまたは探索エンジンリポートに表示された時にファイルの名前の上でクリックすることによって、ファイルの通称、たとえば「１１月販売報告書」によって参照される。その後、所望したファイルの通称は http また他のプロトコルによってサーバー１６に通される。この要求は、その後コマンドユーティリティ１８へ送られる。コマンドユーティリティ１８はオブジェクトデータベース２０内の所望したファイルのオブジェクトを捜し出す。データベース２０はファイルシステム１２内の対応する１つまたは複数のファイル（ファイルのコレクションの場合）を捜し出し、検索のためユーザーへ戻す。本発明の好ましい実施例に従ってオブジェクトをファイルに対応づけるハンドルは、ネットワーク１４上のユーザーには完全に見えなくすることができる。さらにまた、本発明の好ましい実施例に従って、たとえファイルがその後リネームされても、特定のファイルのためのハンドルは存続する。すなわち、コマンドユーティリティ１８は単にそのハンドルに対応づけられたファイルの通称を修正するだけであり、ファイルの共通の表題はちょうどファイルに対応づけられたオブジェクト内の定義された幾つかの変数の１つである。
【００１７】
また、意義深いことに、ファイルシステム１２内に置かれたファイルは、特定の順序でなく、またファイルシステム１２内の特定のロケーションにある必要がなく、また他のファイルとのどんな階層関係も指定しないことが好ましい。ファイルシステム１２内のファイル間のすべての相互関係はデータベース２０内のオブジェクトの中にだけ指定されることが好ましい。ファイルシステム１２の中にフォルダ、サブファイル、等の固有の階層は不要である。
【００１８】
以下に詳しく説明するように、各オブジェクトがファイルシステム１２内に保存された特殊タイプのファイルを記述している多数の別タイプのオブジェクトが存在することがある。たとえば、「ファイル」として知られるものは、ワードプロセッシングまたは表計算の書式で現れるであろう単なるドキュメントである。「コレクション」は、たとえば「１月」、「２月」、等の個別ファイルを含んでいるコレクション「月例報告書」のような「ファイル」のコレクションを指す。コレクションに関するオブジェクトはその中に、他のメタデータのほかに、ファイルのハンドルのリスト、またはそのコレクションの「子」である他のコレクションを含んでいる。従って、「月例報告書」の場合のハンドルは月例報告書に対応づけられたファイルのハンドルのリストを含んでいるであろう。意義深いことに、本発明のシステムの一属性は、ファイル間の階層関係が個々のファイルに対応づけられたオブジェクトの中に保存され、データの階層構造に固有でないことである。たとえば、「ニューヨーク事務所からの１１月会計報告書」と記述できるような１つのファイルは、「月例報告書」、「ニューヨーク事務所からの報告書、および「会計部門からの報告書」等、２つ又はそれ以上の個別コレクションに現れることができる。たとえ同じファイルが３つの個別コレクションに現れても、ファイルそのものはファイルシステム１２内の１つの物理的ロケーションだけに保存されており、ファイルのコレクションはそのコレクションを見たいと思っている特定のユーザーによって要求された時だけ、臨時に集められる。
【００１９】
本発明の実施例によって作成するすることができる別タイプのオブジェクトと関連するファイルは、日に対応し、その中にイベントを入れることができるスペースを含むカレンダを有している。イベントそのものはオブジェクトの形式で記述され、それぞれそれ自身のファイルと一致することがある。従って、もしイベントを記述するファイルのオーナーがイベントの記述を変更したい思ったならば、そのイベントの記述に対する改訂は、そのイベントが現れているすべてのユーザーのカレンダに現れるであろう。もう一度繰り返すと、各ユーザーは自分自身のカレンダを持つことができるが、カレンダ内のイベントは、オブジェクトで記述されたファイルであるので、カレンダとは独立に存在する。
【００２０】
ファイルを記述するさらに別タイプのオブジェクトは、「告示(Bulletin)」と「告示板(Bulletin Board)」を含んでいる。一般に、「告示」は、「告示板」と呼ばれるコレクションの中に集められた短いＡＳＣＩＩメッセージである。「告示板」は、一般に、読出し／書込み／告知追加／告知除去アクセス権をもつ多くのユーザーに関する単なるコレクションである。さらにまた、オブジェクトは事実上別のネットワークロケーションへのＵＲＬであるファイルを記述することができる。これの考えられる１つの利点は、コレクション内の他のファイルに関係のある有用なウェブサイトをそのコレクションの中に置くことである。
【００２１】
オブジェクトとハンドル
本発明のシステムの一般的機能について説明したので、次にコマンドユーティリティ１８によって生成されたハンドルと、オブジェクトデータベース２０の中に保存されたオブジェクトの詳細な実施について説明する。上に述べたように、一般に、ファイルシステム１２の中に保存され、それぞれがオブジェクトデータベース２０内の「オブジェクト」によって記述されたファイルには、１）ワードプロセッシングドキュメントのように単なる多数のデータである「ファイル」と、２）複数のファイルを指すオブジェクトである「コレクション」の２つのタイプがある。
【００２２】
オブジェクトはオブジェクトデータベース２０とファイルシステム１２の中に置かれるので、コマンドユーティリティ１８は固有の識別番号すなわち「ハンドル」を生成する。ハンドルは永久にオブジェクトと同一であると扱われ、オブジェクトをファイルシステム１２内の１つまたは複数のファイルに対応づけることができる。簡単なファイル、すなわちワードプロセッシングドキュメントのように単なるデータのコレクションの場合、典型的なハンドルは FILE-2523  であろう。以下に詳しく説明するように、重要なことは、例における簡単なスカラー数のように、ハンドルはたとえばサーバー内のファイルの特定のロケーションのことを指していないので、ロケーションをベースとしていないこと（以下、非ロケーションベースと呼ぶ）である（以下の説明では、４けたの乱数を使用して異なるハンドルを示す。乱数そのものは特定のオブジェクトとファイルとを識別する以上の意味を持たない）。オブジェクトデータベース２０の中で、ハンドルはオブジェクトのタイプ（このケースでは、ファイル）を示す少数の文字または数字と、後に続く事実上の識別番号を有する。一般に、ハンドルのための識別番号は、新しいファイル、コレクション、等を作成する時に数値順に発行される。
【００２３】
コレクションのためのハンドルは、いくぶん  COLLECTION-5811 のように見えるであろう（すなわち、次に続く数字がコレクションを参照することを示すコードと、その後の数字）。このコレクションに対応するオブジェクトはその中に、コレクション（たとえば、COLLECTION-5811 ）に編入されたファイルのリスト、すなわちユーザーによってコレクションのためのハンドルが要求された時に、これらの特定のハンドルによって識別されるファイルが指し示されることを示す｛ FILE-0871  FILE-7737  FILE-4391｝を含んでいるであろう。もう１つのハンドルによって指し示されるそのようなハンドルのコレクションは「ハンドルリスト」として知られている。もう一度繰り返すと、ファイルはファイルシステム１２内の１つのロケーションだけに存在するのに、そのハンドルはそのファイルが現れることが所望された多数のコレクションのハンドルの中に現れることができる。ユーザーが特定のコレクションを調べるよう要求した時だけ、そのコレクションの中のファイルが「集められ」、その特定の時間にユーザーに対し表示されるであろう。個々のファイルはファイルシステム１２の中に階層的な仕方で格納されていない。すなわち「月例報告書」のような階層（hierarchies)は、ユーザーによってそのような階層を記述するコレクションオブジェクトが呼び出された時に臨時に作り出される。
【００２４】
たとえば階層「販売報告書／月例報告書／１１月」など、コレクションの中のコレクションの場合、コレクションオブジェクト「販売報告書」は、かなりのコレクションオブジェクトのためのハンドルを含むことがある（その「月例報告書」は１つだけである）。同様に、コレクション「月例報告書」はその中に各月例報告書ごとにファイルへのハンドルを含んでいる。
【００２５】
本発明の一実施例の場合、データベース２０はファイルシステム１２を構成する電子メモリとは別個の比較的小形の電子メモリである。ファイルシステム１２はネットワークを介して相互に対話する幾つかの電子メモリで構成することができるであろう。データベース２０は、ファイルシステム１２を含んでいるより大きな電子メモリの個別領域の中に形成することができるであろう。
【００２６】
次の表１は、オブジェクトデータベース２０の中に保存された各オブジェクトに含めることができる「属性」すなわち詳細な情報の説明である。すべてのケースにおいて、各属性は一種の変数であり、また一緒に配列されたこれらの変数のコレクションは完全なオブジェクトを作る。
【００２７】
【表１】
0004008089.tif 000002
【００２８】
オブジェクトコマンド
図１について述べたように、種々のファイルおよびコレクションを記述するオブジェクトは、結局ネットワーク１４上のユーザー１０が出したコマンドによって役が演じられる。ユーザー１０からの通常の言語またはインターネットコマンドをコマンドユーティリティ１８が実行できるコマンドへ変換することは、サーバー１６の機能である。ファイルまたはコレクションを追加する（add)（すなわち、作成する(create) )、ファイルまたはコレクションを見る(view)などの一定のコマンドは前に簡単に説明したが、以下は本発明の好ましい実施例におけるコマンドの後の動作の一連の詳細な説明である。
【００２９】
（ａ） Vieｗ：  これはユーザーがファイルシステム１２内のファイルまたはファイルのコレクションを見たいときのコマンドである。要求されたファイルまたはコレクションがその題名（title)によって呼び出される場合には、コマンドユーティリティ１８はデータベース２０内のオブジェクトの中の「題名」変数を走査して、要求されたファイルまたはコレクションに対応するオブジェクトを見つけることができる。コレクションのケースでは、コマンドユーティリティ１８は、ユーザーが見るのに適した画面、たとえばコレクション内の各ファイルについて（オブジェクトから得た）題名のリストを生成する。従って、本発明のこの特定の実施例において、もしユーザーが「月例報告書」を要求したならば、結局はユーザーが選択できる月例報告書の題名のリストが画面に現れるであろう。一般に、簡単な“ Vieｗ”機能の場合、ファイルはファイルシステム１２から検索されない。
【００３０】
（ｂ） Get:   これは“View”コマンドに似ているが、ファイルにだけ適用され、要求したユーザーはファイルそのものを、たとえばワードプロセッシング、グラフィックス、または表計算のドキュメントの形で見ることができる。コマンドユーティリティ１８は題名によってオブジェクトを捜し出し、オブジェクトのハンドルを見て、次にそのハンドルを使用してファイルシステム１２からファイルを検索する。ファイルの場合、ファイルを記述するオブジェクトの一部分は、ファイルが入っているドキュメントフォーマットのタイプを示す、「パントマイムタイプ」である。コマンドユーティリティ１８はファイルシステム１２からファイルを検索させ、その後パントマイム形式に従ってファイルをユーザーへ送る。
【００３１】
（ｃ） Add:   このコマンドは、ファイルを作成またはファイルシステム１２へ提出する時に、あるいは新しいオブジェクトによって識別しなければならない新しいファイルのコレクションを作成または提出する時に使用される。ユーザーからの上記コマンドに応答して、コマンドユーティリティ１８はカレンダすなわち空コレクションなど、所望されたオブジェクトのプロトタイプを作成する。その後、コマンドユーティリティ１８は画面をユーザーへ送り戻す。画面は、たとえばカレンダすなわちコレクションのケースではユーザーが所要の書き込みをする入力書式であり、その場合、ユーザーは空のプロトタイプに書き入れたいと思っているファイルを書式のスペースに書き入れる。書式画面に書き込んだ後、ユーザーは“submit”ボタンをクリックする。この“submit”コマンドに応答して、コマンドユーティリティ１８は、画面に書式を書き込んだ時ユーザーが提出したデータを用いて、所望したハンドルのオブジェクトを作成し、次にハンドル（たとえばコマンドユーティリティ１８内のカウンタから）を生成し、オブジェクトのためのハンドルを形成する固有の識別番号を割り当てる。そこで、新しいハンドルを持つ新しいオブジェクトがオブジェクトデータベース２０に入力される。ファイルを追加するケースでは、コマンドユーティリティ１８は、さらに、生成されたばかりのハンドルによってのみ識別されるファイルを、ファイルシステム１２へ送り続ける。ファイルの最初の通称、たとえば「１１月報告書」は、前記表１のように、属性として、単なるオブジェクト内のストリング変数として保存される。
【００３２】
（ｄ）View properties and edit properties ：  これは、オブジェクトの中に具体化された特性（ properties ）を見る、もし所望ならば、編集するための、一般に問題のオブジェクトのオーナーであるユーザーに対するコマンドである。後で「パーミッション（permission) 」に関して説明するように、オーナーにだけ属性を変更することが許される。ユーザーによって特性に関するコマンドがコマンドユーティリティ１８へ提出されると、コマンドユーティリティ１８はオブジェクト内のデータを使用可能な書式でユーザーの画面に表示する。もしユーザーがそのように許可されれば、ユーザーは実際に「親」または「子」フィールドを変更することによって、あるコレクションから別のコレクションへオブジェクトを動かしたり、コピーしたりすることができるし、さらにオブジェクトとその基礎をなすファイルに関して読出しおよび（または）書込み許可を持つユーザーのリストを変更することもできる。そのほかに、オブジェクトのオーナーだけが、オブジェクトデータベース２０からオブジェクトを完全に削除し、同様にファイルシステム１２からファイルを削除する権限を有する。
【００３３】
（ｅ）バージョン番号：  ワードプロセッシングドキュメントの編集されたバージョン、あるいは表計算の更新されたバージョンのケースなど、「同一」ドキュメンと見なされる幾つかのバージョンが存在する状況において、コマンドユーティリティ１８は同一ファイルとみなされる異なるバージョン間の関係を維持しながら、「改訂した」ハンドルを生成することができる。たとえば、もしドキュメントのある草稿に番号 FILE-3672  が与えられていれば、時間的に後にファイルシステム１２に追加される草稿の編集されたバージョンに、ハンドル FILE-3672-2  を与えることができる。同一ハンドルを持つオブジェクトの複数のバージョンを収容するための設備をオブジェクトデータベース２０の中に作ることができる。（代わりに、オブジェクトの中に「バージョン番号」フィールドを作ることができる。）  従って、ファイルシステム１２からファイルの「すべてのバージョン」すなわち「最新のバージョン」または「最初のバージョン」を検索するためのコマンドは容易に存在することができる。それで、コマンドユーティリティ１８はファイルの特定の所望したバージョンに対応する適当なハンドルをオブジェクトデータベース２０から選択することができる。
【００３４】
パーミッション (permission) 
上に述べたように、従来のほとんどの共用データシステムの実際の制限は、種々のコレクションに格納された個々のドキュメントに関する機密保護が「全部か零か」であることである。すなわち、共用ドロワ（shared drawer)システムまたは共用ドライブシステムにおいては、システム管理責任者はドロワそのものへのアクセスを制限できるのに、いったん人がドロワまたはドライブへのアクセス権を持ちさえすれば、彼はその中のすべてのドキュメントをアクセスできる。異なるユーザーのサブセットに異なるドキュメントのサブセットへのアクセスが許されている場合に、もし異なるタイプのドキュメントに対し異なるレベルの機密保護が要望されれば、唯一の解決策はそれぞれが異なるユーザーのサブセットを有する多数のドロワを準備することであろう。
【００３５】
しかし、本発明のシステムによって、オブジェクトの機密保護特性はオブジェクトそのものにリストされた「リーダー（readers)」と「ライター (writers)」のリストの中に具体化されている。従って、特定のオブジェクトの基礎をなすファイルの場合（そのオブジェクトがファイルそのものを記述していてもいなくても、あるいはそのファイルがオブジェクトによって記述されたオブジェクトの一部であってもなくても）、機密保護特性はオブジェクトに存続する。たとえファイルが異なる時間に異なるコレクションの中に置かれていても、ファイルそのものは対応づけられたリーダーとライターのリストを持つオブジェクトを有するので、機密保護特性はファイルに残るであろう。
【００３６】
本発明の好ましい実施例に従って、ファイル、コレクション、あるいはカレンダなどの別のオブジェクトを記述するオブジェクトは、そのオブジェクトデータの中に、そのオーナー、そのリーダー、およびそのライター（そのほかに、オーナーと同じ特権を持つが、オーナーではない「管理者」と呼ばれるユーザーのクラスが存在することがある）のハンドルを有している。「リーダー」はファイルまたはコレクションへの読出しアクセス権だけを持つユーザーであり、「ライター」は書込みアクセス権を持つユーザーであり、オーナーはオブジェクトそのものを変更し、基礎をなすファイルまたはその一部分を削除することができるユーザーである。
【００３７】
本発明の好ましい実施例に従って、オブジェクトとその基礎をなすファイルに対する「オーナー」権を複数のユーザーに与えることができる。この「オーナー」権は他のユーザーがオブジェクトへの読出しおよび（または）書込みアクセス権を持つことのパーミッションを編集する能力を含んでいる。
【００３８】
本発明の好ましい実施例に従って、ファイルシステム１２内の機密保護されたファイルへのどれかのタイプのアクセス権を望んでいるすべてのユーザー（図１）は一定の時点にコマンドユーティリティ１８にアカウント（account)」を作らなければならない。オブジェクト内の属性の前記表１においてそれとなく言及したように、登録時にまるでユーザーがコレクション内のファイルであるかのように、コマンドユーティリティ１８によってユーザー自身にハンドルが割り当てられる。すなわち、特定のユーザーの名前またはインターネットまたは電子メールの住所とは無関係に、ユーザーに対しアカウントが作られると、コマンドユーティリティ１８はユーザーの名前または住所を、新しく生成したハンドル（繰り返すと、これはユーザーと共に永久に存続する単なる識別番号である）に対応づける。オブジェクトの中のオーナー、リーダー、およびライターの属性の場合、ユーザーは名前または住所でなく、彼らのハンドルによって識別される。
【００３９】
ユーザーのアカウントが作られると、コマンドユーティリティ１８内の共同レジストリ（community registry) 」と呼ばれるユーティリティがユーザーを記述するデータを含む新しいオブジェクトを作成する。登録プロセスは電子書式への所要の書込みを含んでおり、そこからのデータがユーザーオブジェクトの中に使用される。そのようなユーザー情報は、たとえばユーザーの法律上の名前、ハードコピーや電子メールの住所、ウェブサイトのＵＲＬ、およびユーザーが提携することを望んでいるユーザーグループの名前を含むことができる（これは、ユーザーグループがハンドルとそれに対応づけられたオブジェクトを有し、かつ機密保護の考慮を受けることができると仮定して、「親」コレクションにユーザーの名前を付けることと同じである）。また、この時点に、新しいユーザーにシステムへ将来ログインするときに使用するパスワードにタイプするように求めることが好ましい。そのパスワードは、ユーザーがシステムへログインする将来のあらゆる時点にコマンドユーティリティ１８によって検査されるであろう。
【００４０】
ユーザーが登録したくない、すなわちシステムに関してユーザーオブジェクトを作成したくない場合には、ユーザーがログインすることを希望すると、コマンドユーティリティ１８は彼を「客」として識別するであろう。客はパスワードに加入しなくてもよいのであるが、無制限の読出しパーミッションにより、それらのオブジェクトと基礎をなすファイルだけへのアクセス権を持つであろう、もちろんファイルへの書込みアクセス権または所有者アクセス権を持たないであろう。一般に、登録されたユーザーだけは、ユーザーオブジェクトで、オブジェクトデータベース２０へのオブジェクトを作成したり、あるいはファイルシステム１２へファイルを追加することができるであろう。
【００４１】
add, view  等の上記コマンドのどれかを活動化する前に、コマンドユーティリティ１８はコマンドを出したユーザーに対しパーミッション検査を行う。従って、ユーザーからコマンドが出されると、コマンドユーティリティ１８は、オーナー、リーダー、およびライタースペース内のユーザーハンドルのリストと対比してユーザーのハンドルを検査し、次にそのユーザーがその特定のコマンドを要求することができるかどうかを決定する。（もちろん、機密保護されていないファイルやコレクションの場合は、オブジェクト内の「リーダー」または「ライター」スペースの中に、ワイルドカード変数または同等なものを置くことができる。）
【００４２】
ハンドルをユーザーオブジェクトとしてユーザーへ割り当て、その後割り当てたハンドルを使用して一定のコマンドを実行するためパーミッションを検査することは、ユーザーをインターネットプロトコルで識別する既知の「クッキー（cookie) 」システムの変形で実施される。ユーザーのための新しいオブジェクトがコマンドユーティリティ１８によって生成されると、そのハンドルがネットワーク１４上のユーザーを識別するのに使用した「クッキー」に付加される。この「クッキー」はすべての将来のログインのためにユーザーと共にあるであろう。従って、特定のユーザーが特定のオブジェクトを所望すると、コマンドユーティリティ１８はまずユーザーのクッキー内のハンドルと「読出し」フィールド内のユーザーハンドルのリストとを比較する。クッキー内のハンドルが読出しフィールド内のハンドルと一致する場合だけ、そのユーザーはアクセスが許されるであろう。
【００４３】
パーミッションはファイルおよびファイルのコレクションと関係があるので、継承可能性の原理が援用されることは、パーミッションの全体的な構造が暗示している。すなわち、たとえ特定のファイルがコレクションの一部から作られていても、それぞれの個別ファイルはそのオブジェクト内のリーダーおよびライターパーミッションの形で対応づけられた機密保護を有するので、たとえより大きなコレクションがより広範囲のパーミッション（すなわち、より多くの人達が全体としてそのコレクションにアクセスすることが許される。）を持つことができても、機密保護特性はファイルに残るであろう。本発明の一実施例に従って、もし所望ならば、コレクションに対応づけられたパーミッションが絶対にそのコレクション内のどのファイルのパーミッションよりも広くないソフトウェア機構を提供することは可能である。これは、たとえばコレクションに対応づけられたパーミッションとそのコレクション内のファイルのパーミッションを一致させるコマンドユーティリティ１８内のプログラムによって実行することができる。この一致はファイルシステム１２内のファイルに対応づけられたオブジェクトを自動的に変更することによって行うことができるので、パーミッションを一致させるためにファイルそのものを呼び出す必要はない。
【００４４】
図２は、オブジェクトのパーミッションを編集するため要求されたとき、ユーザー（一般にオブジェクトのオーナーまたは管理者）に提示することができる画面の例である。第１列に潜在的なユーザーおよび（または）現在少なくとも読出しアクセス権を持つ人のリスト（オブジェクトオーナーで始まる）と、列を横切って延びている異なるタイプのパーミッション（アクセスリストから前に記載されていた人を削除するオプションを含む）と持つマトリックスが表示される。オーナーまたは他の管理者はマトリックス内の適当な枠をクリックすることによってパーミッションを編集することができる。
【００４５】
ダイナミックコンテンツをもつドキュメントの作成
図３は、かなりの数のユーザーが出席する、かつ先行読取りするファイルのコレクションが存在するかもしれないイベントの例の場合に、オブジェクトがオブジェクトデータベース２０の中に存在していた時のオブジェクト間の相互関係を示す図である。図の上部から始めると、自分自身のカレンダを持つ３人のユーザーはそれぞれ自分のカレンダについて適当な日に記載された「イベント」を持つことがわかるであろう。イベントを記述するオブジェクトはオブジェクトデータベース２０内の１つの場所だけに存在するが、図の上部にある各ユーザーのカレンダはすべて彼らのカレンダオブジェクトの中にこのイベントに対するハンドルを含んでいる。そのほか、カレンダを記述する各オブジェクトは、そのカレンダのユーザーまたはオーナーを記述するオブジェクトを指し示すハンドルを含んでいる。
【００４６】
イベントを記述するハンドルの中に、イベントオブジェクトが指し示す幾つかの異なるタイプのオブジェクトが存在することがある。たとえば、もしイベントについて先行読出しする一定のファイルがあれば、イベントオブジェクトは図示のように、先行読出しするファイルを指し示すハンドルを含むコレクションオブジェクトを記述することができる。イベントオブジェクトは、そのほかに、イベントに招待すべきユーザーを指し示すハンドルを含んでいる。これらのユーザーのためのハンドルは、ユーザーのグループのためのハンドルを含むオブジェクトの形をしていることがある。たとえば、「プログラムＺ内のエンジニアと呼ばれるユーザーグループオブジェクトは、そのクラス内のすべての人のためのハンドルを含むコレクションオブジェクトであろう。任意のユーザーによって、ユーザーオブジェクト内のパーミッションの範囲内で、無数の臨時のユーザーグループを作り出すことができる。ユーザーグループを作り出すことは、単にグループ内にあることが意図されたユーザーのハンドルリストを持つ「コレクション」オブジェクトを作り出すことである。もちろん、「イベント」コレクションオブジェクトは、そのほかに、図示のようにグループ内にいないユーザーに対するハンドルを含むことができるであろう。ユーザーグループは図示のようにイベントオブジェクトへの慣習的なアクセス権を持たないユーザーに対するハンドルを含むことができる。
【００４７】
「イベント」オブジェクト内に集めることができるもう１つの考えられるオブジェクトは告示（bulletin) オブジェクトである。告示オブジェクトは、図示のように、イベントを記述する告示のほかに他の告示を有する告示板の一部のことがある。一般に、告示板は広いアクセスパーミッションを持つことが意図されているので、イベントへの他のアクセス権を持たないユーザーはイベントを記述する告示を見ることができるであろう。
【００４８】
「イベント」コレクションオブジェクトに現れることがあるもう１つのオブジェクトは、たとえば図示のような広告機構のホームページのＵＲＬである。そのほかに、イベントコレクションはそのオブジェクト内のテキストを格納するプロビジョンを含むことがあり、このテキストは外部ウェブサイトへのホットリンクを含むことができる。
【００４９】
オブジェクトによって記述される基礎をなすファイルが階層的に格納されないという事実に関係がある本発明の重要な特徴は、あるタイプのオブジェクトが他のタイプのオブジェクトの「内側」と「外側」に同時にいることができることと関連がある。たとえば、図３に示したイベントの場合、イベントはユーザーの数のカレンダの中にあるのに、イベントへ招待すべきユーザーを記述するユーザーグループコレクションオブジェクトはイベントオブジェクトの中にある。図３に点線で示すように、自分のカレンダにイベントを有するが、イベントへ招待すべき者としてリストされているユーザーは、イベントの「子」であるが、イベントの「親」であるカレンダオブジェクトのオーナーでもあるオブジェクトによって記述される。問題は、ファイルがコレクションの中にあるかどうかの階層は、特定のユーザーによって見られる特定のファイルの見方に依存して、常にその場限りのものであり、そして最も重要なことはファイルシステム１２に格納されたオブジェクトの基礎をなすファイルとは独立に作り出すことができることである。この例においては、イベントへ招待すべき人（およびイベントオブジェクト内に集められたハンドルをもつ人）のリストにユーザーが追加されるか、削除されるかに関係なく、それらの変更はオブジェクトデータベース２０内のオブジェクトにだけ影響を及ぼし、ファイルシステム１２内の基礎をなすファイルには絶対に影響を及ぼさない。同様に、コレクション内のファイルの先行読出しの場合、たとえファイルが絶えず更新されていても、ファイルそのものは１つの場所のみ存在するので、更新はファイルシステム１２内の１つの場所にあるファイルに対してだけ起こり、その最新情報はオブジェクトデータベースに影響を及ぼさない。全体的な効果は、ちょうど招待者のリストが絶えず変更される時に、あるいは先行読出しファイルの内容が絶えず変更される時に、多数のファイルを更新するという非常に低いオーバーヘッドを本発明が支援することである。
【００５０】
本発明のシステムが大きな有用性を持つもう１つの環境は、一連の論文（各論文は独立したファイルをもつ）としてファイルシステム１２に格納できるディジタル化された教育課程資料へのアクセス権をもつ大学の環境である。もし教育課程を準備する教授Ａが論文ＸＹＺのコレクションを作成したいと思っており、教授Ｂが論文ＷＸＺのコースパケットを作成したいと思っているならば、各論文ＷＸＹＺはファイルシステム１２内の１つの場所にありさえすればよい。それなら、教授Ａと教授Ｂはそれぞれ望んでいる論文のオブジェクトを参照して、アクセスおよび（または）印刷するコレクションを作ることができる。各論文ＷＸＹＺをファイルサーバー内の１つのロケーションに保存する実際上の利点は、著作権使用料を支払う目的で、誰が論文を要求したかに関係なく、どれか特定の論文ＷＸＹＺの印刷要求の総数を容易に主張できることである。そのほか、たとえば論文Ｚが毎月更新される場合には、その最新情報をファイルシステム１２内の１つの場所に送りさえすれば、２人の教授に役立つであろう。
【００５１】
実施例
本発明のシステムの「心臓部」はコマンドユーティリティ１８である。コマンドユーティリティ１８の総合機能は、データベース２０内のオブジェクトに対し作用する前述の get, view, add 等の基本コマンドを実施することである。本発明の１つの実際の実施例では、これらのコマンドは HTTP 1.0 基準に定義されている Common Gateway Interface ( ＣＧＩ）を通して自動的に呼び出される“Python”スクリプティング言語の命令のセットとしてコマンドユーティリティ18の中に存在する。ＣＧＩまたは任意のウェブサーバー特定インタフェースを通して任意のプログラミング言語を使用して、コマンドをウェブサーバーたとえば http サーバー１６に組み込むことができる。
【００５２】
一般にコマンドユーティリティ１８に関連するもう１つの重要なユーティリティは、「セッション」マネージャーとして知られているものである。これは、オブジェクトを作り出すとき、ハンドルが必要なときに識別番号を発行する短いプログラムである。各タイプのオブジェクトについてカウントアップする、または乱数を生成するなど、いろいろなタイプのオブジェクトに対する新しいハンドルを発行する種々の方法は明らかであろう。
【００５３】
一般にコマンドユーティリティ１８に関連する別タイプの命令は、「オブジェクトデータベース・ルーチン」として知られるものである。これらのルーチンは、実際に格納する時オブジェクトである変数の簡単なストリングと、編集の時などにユーザーの画面でオブジェクトと特性を見ることができる「ウィンドウ」との間で橋の役を努める。
【００５４】
コマンドユーティリティ１８に関連するもう１つのユーティリティは、「ドキュメント管理プログラム」である。ドキュメント管理プログラムの全般的な機能は、ファイルシステム１２にしまった「同一」ファイルまたはドキュメントの複数のバージョンについて管理を維持することである。ドキュメント管理プログラムは、ユーザーが前ファイルの新しいバージョンであると宣言した新しいファイルに付けるバージョン番号を発行する。ドキュメント管理プログラムは、新しいバージョンに対し前バージョンと同一のハンドルとその後に続くバージョン番号を発行する。
【００５５】
最後に、本発明はファイルシステム１２内のファイル、および（または）データベース２０内のオブジェクトの中の変数に対し作用する探索エンジンへ接続して容易に使用することができる。もし探索エンジンを使用してファイルシステム１２内の或る重要なファイルを捜し出せば、それらのファイルに対応づけられたオブジェクトを使用して捜し出したファイルの「親」を介して関連ファイルを見つけ出すことができるので、本発明は探索エンジンの有用性を強化する。そのほかに、捜し出したファイルのオブジェクトを使用して同じ著者によって書かれた、または修正された別のファイルを見つけることもでるし、あるいは同じ日に起きたイベントまたは作成されたファイルを見つけることもできる。従って、本発明はテキスト探索の限界に打ち勝つことによって刊行物を研究する人を支援することができる。
【００５６】
陳腐ウェブリンクを避ける持続性ハンドル
特に http ( すなわちインターネット) サーバー１６に着目すると、本発明の実用的な実施例の重要な属性は、共用データ環境がウェブ上に存在すること、すなわちインターネットプロトコルを通してアクセス可能なことである。しかし、 http サーバー１６とコマンドユーティリティ１８との関係に見られるように、共用データ環境の「境界」はインターネットスタイルのＵＲＬから共用データ環境に専用のハンドルへの変換によって特徴づけられる。言い換えると、コマンドユーティリティ１８の重要な機能は、インターネット上の一般に理解できないＵＲＬをファイルシステム１２に永久に対応づけられたハンドルへ変換することである。このＵＲＬからハンドルへの変換は、本発明の重要な実用的な利点、すなわち、たとえばインターネット・ウェブサイトの保守において普通である「陳腐リンク」の回避を特色づけるものである。
【００５７】
インターネットを通してアクセス可能な特定のページを識別する典型的なＵＲＬは、特定のページにアクセスするためにユーザーがクリックスルーしなければならない階層順序を明示する。たとえば、ゼロックス社の１９９５年１月現在の価格表を記載しているページのＵＲＬは、ＵＲＬ：www.xerox.com/pr/news/1995/january/prices/index.html  をもつことができる。ＵＲＬそのものが（ウェブ上では、ファイルの名前になる）、ユーザーが所望した価格表に達するようにファイルの中のファイルの階層を順番に明示することは気づかれるであろう。ウェブサイトが変更または再編成されると実用上の問題が起きて、特定のページに達するために必要な「クリック」の順序動作はもはや存在しない。その時は、ユーザーが所望した特定のページにアクセスするのが非常に難しくなる、すなわちより直観的に理解できなくなるであろう。これは、ここでは一般に「陳腐リンク」と呼んでいる。
【００５８】
本発明のシステムは、ファイルシステム１２に格納されたファイルに関する「陳腐リンク」の問題を解決することができる。たとえば、もし上に述べた価格表を含んでいる Xerox website  をゼロックスシステム管理責任者またはウェブマスターが再編成すれば、上記ＵＲＬによって前に達した同じ価格表を異なる場所にあるように再編成することができるであろう。もし、たとえばウェブマスターが日付でなく、製品によって Xerox website  を再編成すれば、元の１９９５年１月現在の価格表の新しいＵＲＬは、たぶん www.xerox.com/products/prices/index.html のようになるであろう。典型的なインターネットブラウジング・ソフトウェアは「ブックマーク」のシステムを提供し、それによって共通に使用される（すなわちアクセスされる）ファイルは迅速参照のためのＵＲＬを保有する。所望した特定のページのＵＲＬすなわちロケーションベースアドレスが変更されると、問題が起きる。いったんファイルのＵＲＬが変更されると、最初のＵＲＬは即座に無用になる。さらに、ユーザーがインターネットブラウザを使用して、再編成されたウェブサイト内の所望のページを見つけることは必ずしも可能とは限らない。
【００５９】
図１を再び参照すると、コマンドユーティリティ１８は、ファイルシステム１２内に置かれたハンドル（ウェブリンクを含むことができるファイルに対する識別番号）を割り当てるばかりでなく、ファイルの最初のＵＲＬを事実上リネームして、最初のロケーションベース「階層的」ＵＲＬを新しいＵＲＬ（非ロケーションべース非階層的ＵＲＬ、すなわち、言い換えるとロケーション独立ＵＲＬ）で置き換える。たとえば、上に述べた最初のＵＲＬはファイルシステム１２内にファイルされた後、 http://www.xerox.com/get/file-0039 に事実上リネームされるであろう。ここで、この例の“file-0039 ”はまったく任意のハンドル番号である。この新しいＵＲＬの場合、最初の部分は単に世界的なウェブサーバーの名前であり、第２の部分は上に詳しく説明したコマンドであり、最後の部分はファイルシステム１２内に置かれたファイルのハンドルであることに気がつかれるであろう。この新しいＵＲＬは、たとえばネットワーク１４上のユーザー１０のブラウザまたは他のメモリの中の（ウェブリンクなど、ブックマークファイルまたは同等なシステムの中に）に置かれる。従って、次回にユーザー１０がその特定のファイルにアクセスしたいと思った時、ユーザーのブラウザは、ウェブページの再編成によって最終的にもはや役に立たない、すなわち陳腐になるかもしれない最初のＵＲＬでなく、新しい非階層的ＵＲＬによってファイルを参照するであろう。簡単に述べると、ファイルシステム１２内のファイルにアクセス中のユーザーは、もはや役に立たない、すなわち陳腐になるかもしれないロケーションベース階層的ＵＲＬではなく、所望したファイルのハンドルだけを組み入れたロケーション独立ＵＲＬによってファイルを参照する。このハンドルベースＵＲＬは、ロケーションベースでなく、消滅するかもしれないより高いレベルのフォルダを参照しないので、データファイルの原始ソースのその後の再編成の後も生き残るであろう。
【００６０】
もちろん、もしユーザーがインターネットフォルダの最初の階層を保存し、そして１つまたはそれ以上のフォルダをファイルシステム１２内に保存することを選択すれば、より高いレベルのフォルダ（上のケースでは、“pre ”, “news”, “1995”，“January ”) をコレクションとしてファイルシステム１２の中に保存することができる。ここで、階層内のその後の各フォルダは前のフォルダの子である。重要なことは、本発明のシステムが、階層的ロケーションベースＵＲＬを、ファイルまたはコレクションのハンドルだけを含む非階層的ロケーション独立ＵＲＬでリネームする基本的なステップを提供することである。この特徴によって、本発明のシステムは「陳腐リンク」の問題を解決することができる。
【００６１】
コマンドユーティリティ１８はＵＲＬを各ファイルに永久に対応づけられたハンドルへ変換するので、「クリック」の階層の変化（それによってユーザーはページとウェブサイトにアクセスする) は依然としてアクセス可能であろう。一般的なＵＲＬの場合は、上に指摘したように、ファイルの名前は階層を通る通路（そこを通ってファイルに達する）と区別できない。本発明のハンドルシステムの場合は、ファイルはどんな階層とも独立に存在することができる。実際に、上に指摘したように、個々のユーザーは自分自身の階層を作り出すことができる、すなわちファイルはまったく階層なしで存在することができる。
【００６２】
共同保守（comunity maintenance）
本発明のもう１つの重要な特徴は、共同保守することが可能であるという事実である。実際に、「共同保守すること」の本質は、システム全体を「監督する」ために、システム管理責任者、ウェブマスター、あるいは通常以上のユーザー特権を持つ他の人など、スーパーユーザーは必要ないということである。一般に、ウェブサイトの場合など、「ウェブマスター」に指名された一定の人または人達は、一定の他のユーザーにウェブサイトの全部または部分にアクセスさせることに関して特別な権利を持っているであろう。本発明の場合、個々のファイルはそれ自身のアクセス許可を規定するので、機密保護は１ファイルづつ行われ、そのようなスーパーユーザーは不要である。
【００６３】
以前に本発明の共用データ環境と接触を持たない人が最初にインターネットを通して http サーバー１６にアクセスすると、コマンドユーティリティ１８はそのユーザーを非登録であると識別する。もしユーザーがシステムに登録することを選ばなければ、コマンドユーティリティ１８はこの見知らぬ人を単なる「客」と識別するであろう。前に言及したように、ファイルシステム１２内の制限されたファイルへのアクセス権を持つために、客はコマンドユーティリティ１８にアカウントを作らなければならない。「共同保守」の見地から、ここで重要なことは、システムに加入する客は彼自身の動機でアカウントを作ることと、ウェブマスターまたはシステム管理責任者など、どんな種類の人のスーパーユーザーからも（全体としてシステムに加入するために）特別な許可を受けなくてもよいことである。本発明は、以前にシステムと接触を持たないユーザーがたとえばアカウントを作ることによって簡単にユーザーの地位を要求することができる自動的機構を提供し、このアカウントの作成はシステムによって自動的に行われる。本発明の場合、個々のファイルはその自身のシステム管理責任者として行動し、どんな人がそのファイルへのアクセス権を有するかを管理する。全システムのレベルでなく、個々のファイルのレベルでなされる機密保護は、本発明のシステムの「共同保守」特性のもう１つの重要な特徴である。
【００６４】
システムの概要
上に説明したシステムは、他の共用データシステムにおいてたぶん個別に利用することもできるが、本発明のシステムの中で一緒に行動して、そのユーザーに対し通常より融通性のあるサービスを生み出す多くの特徴を備えている。本発明の多くの特徴の中でも最も重要な３つの特徴は、１）ネットワークＵＲＬのロケーション独立ハンドルへの変換；２）データベース内の各オブジェクト、従ってファイルシステム内の各ファイルへの固有のアクセス権の付与；および３）システムのどれか特定の部分へのアクセスを希望するユーザーへ許可を与えるために単一スーパーユーザーは必要ないという「共同保守」の概念、である。
【００６５】
本発明のこれら３つの特徴は共働する。システム内の各ファイルがそれ自身のアクセス権を保有することは、各個々のファイルがそれ自身を保護すること、従ってスーパーユーザーが全システムへの門番として行動する必要がないことを意味する。従って、各ファイルへの固有のアクセス権の付与は、目立った機密保護違反をせずに、ユーザーに自分自身を登録させるという「共同保守」の特徴を支援する。さらに、ファイルシステム内のファイルのためのネットワーク・ロケーションベースＵＲＬを非ロケーションベースＵＲＬへ変換する概念は、個々のユーザーがファイルシステム内のファイルのための自分自身の階層を作り出すことを可能にする。従って、もしファイル（ファイルシステム１２の中にあっても、その外の場所にあっても）の原著者がフォルダまたはファイルの階層をセットアップすれば、いったんこれらのファイルがファイルシステム１２の中に置かれると、各ファイルに対応づけられた非ロケーションベースハンドルはそのファイルを解放するので、他のユーザーはそのファイルを彼ら自身が案出した階層に置くことができる。本発明のロケーション独立ＵＲＬの特徴は、各ファイルに固有のアクセス権の特性と共働して、ユーザーがアクセスできるどんなデータでも自分の好みに合わせて編成できるシステムを作り出す。このやり方で、本発明のシステムの３つの本質的な属性は、共働して大量の情報をユーザーが要求する通りに仕立てることができるシステムを作り出す。
【００６６】
以上、開示した構造を参照して発明を説明したが、発明は記載した細部に限定されるものではなく、特許請求の範囲に入るかもしれないすべての修正物または変更物を包含しているものとする。
【図面の簡単な説明】
【図１】本発明に係る環境の基本的な機能を示すブロック図である。
【図２】ユーザーがウィンドウを介して許可を自分が作成したオブジェクトに記入することができるウィンドウの例である。
【図３】本発明の環境の中のデータオブジェクト間の関係の例を示す図である。
【符号の説明】
１０  ユーザー
１２  ファイルシステム
１４  インターネット
１６  http  サーバー
１８  コマンドユーティリティ
２０  オブジェクトデータベース
【図１】
0004008089.tif 000003
【図２】
0004008089.tif 000004
【図３】
0004008089.tif 000005