(57)【特許請求の範囲】
【請求項１】
複数の情報要素と、各情報要素からの参照先となる情報要素を特定する情報とを関連づけて保持するデータベースと、クライアント装置とに接続され、
前記データベース内に保持されている情報要素に係るアクセスの要求を、前記クライアント装置から受け入れる手段と、
当該クライアント装置から、当該クライアント装置を操作する利用者が過去にアクセスした前記情報要素のリストを特定する情報を取得する手段と、
前記取得した情報に基づいて、前記クライアント装置を操作する利用者が過去にアクセスした前記情報要素のリストを特定し、前記要求に係る情報要素が当該リストに含まれるか否か、及び参照先を辿って前記要求に係る情報要素に到達可能な情報要素が当該リストに含まれるか否かを調べ、前記要求に係る情報要素が前記リストに含まれる場合または参照先を辿って前記要求に係る情報要素に到達可能な情報要素が前記リストに含まれる場合には、前記クライアント装置からの前記要求に係る情報要素へのアクセスができると判断し、前記要求に係る情報要素が前記リストに含まれず、かつ参照先を辿って当該要求に係る情報要素に到達可能である情報要素が前記リストに含まれていない場合には、前記クライアント装置からの前記要求に係る情報要素へのアクセスができないと判断するアクセス可否判断手段と、
を含むことを特徴とするサーバ装置。
【請求項２】
請求項１に記載のサーバ装置において、
前記データベースは、前記情報要素に対する編集又は閲覧を含む各アクセスの種別ごとに、各種別のアクセスを行う際にアクセスされる情報要素を、アクセスの種別に関連した情報要素として保持し、
前記アクセス可否判断手段は、前記クライアント装置を操作する利用者が過去にアクセスした前記情報要素のリストを特定し、前記アクセスの種別に関連した情報要素が当該リストに含まれるか否かを調べ、前記アクセスの種別に関連した情報要素が当該リストに含まれる場合には、当該情報要素に関連する種別のアクセスができると判断し、前記アクセスの種別に関連した情報要素が当該リストに含まれない場合には、当該情報要素に関連する種別のアクセスができないと判断することを特徴とするサーバ装置。
【請求項３】
複数の情報要素と、各情報要素からの参照先となる情報要素を特定する情報とを関連づけて情報要素ネットワークとして保持するデータベースと、クライアント装置とに接続され、
前記情報要素の少なくとも一部について、当該情報要素への編集又は閲覧を含む要求名ごとに、要求名に関するアクセス権を規定する情報要素が、当該情報要素に関連づけられて前記データベース内に保持され、
前記データベース内に保持されている情報要素に係るアクセスの要求を、要求名とともに前記クライアント装置から受け入れる手段と、
当該クライアント装置から、当該クライアント装置を操作する利用者が過去にアクセスした前記情報要素のリストを特定する情報を取得する手段と、
前記取得した情報に基づいて、前記クライアント装置を操作する利用者が過去にアクセスした前記情報要素のリストを特定し、前記データベース内に保持されているいずれかの情報要素であって、前記リストに含まれる情報要素から参照先を辿って前記要求に係る情報要素に到達可能で、かつ、前記要求に係る前記要求名に関するアクセス権を規定する情報要素が、前記リストに含まれる場合には、前記クライアント装置からの前記要求に係る情報要素へのアクセスができると判断し、前記データベース内に保持されているいずれかの情報要素であって、前記リストに含まれる情報要素から参照先を辿って前記要求に係る情報要素に到達可能でないか、または、前記要求に係る前記要求名に関するアクセス権を規定する情報要素が、前記リストに含まれない場合には、前記クライアント装置からの前記要求に係る情報要素へのアクセスができないと判断する手段と、
を含むことを特徴とするサーバ装置。
【請求項４】
請求項１から３のいずれか一項に記載のサーバ装置において、
前記クライアント装置に対して、当該クライアント装置からの要求に係る情報要素へのアクセスを行わせたときに、当該要求に係る情報要素のハッシュ値またはハッシュ値のリストのハッシュ値を、当該アクセスを行わせた情報要素への前記アクセス履歴に関連する情報として、前記クライアント装置側に対して送信する手段と、
を含むことを特徴とするサーバ装置。
【請求項５】
複数のリソースと、各リソースからの参照先となる他のリソースを特定する情報とを関連づけて保持するデータベースを管理するサーバ装置において、
前記リソースに対するアクセス要求をクライアント装置から受け入れる受入手段と、
前記クライアント装置から取得した、前記データベースに対するアクセス履歴を示すユーザコンテキスト情報に基づいて、前記アクセス要求に係るリソースが前記クライアント装置によって過去にアクセスされたか否かにより当該リソースに対するアクセス権を判断する判断手段と、
を具備し、
前記ユーザコンテキスト情報は、少なくとも前記クライアント装置が過去にアクセスしたリソースのうち、当該リソースから参照先を辿って前記過去にアクセスした他のリソースに到達できるリソースを保持したものであり、
前記判断手段は、前記ユーザコンテキスト情報に基づいて、前記アクセス要求に係るリソースが過去にアクセスされたか、または前記データベースに含まれ、前記クライアント装置が過去にアクセスしたリソースから参照先を辿って前記アクセス要求に係るリソースに到達できる場合には、前記アクセス要求に係るリソースに対するアクセス権があると判断し、前記アクセス要求に係るリソースが過去にアクセスされておらず、かつ前記データベースに含まれ、前記クライアント装置が過去にアクセスしたリソースから参照先を辿って前記アクセス要求に係るリソースに到達できない場合には、前記アクセス要求に係るリソースに対するアクセス権がないと判断するサーバ装置。
【請求項６】
サーバ装置は、ウエブサーバであり、前記リソースを特定するリソース名をURLとしてクライアント装置から受信すると共に、前記ユーザコンテキスト情報をクッキー領域の情報としてクライアント装置から受信するものであることを特徴とする請求項５記載のサーバ装置。
【請求項７】
前記ユーザコンテキスト情報は、リソースを特定するリソース名に基づいて算出されたハッシュ値を含むものであることを特徴とする請求項５または６に記載のサーバ装置。
【請求項８】
前記ユーザコンテキスト情報は、リソースを特定するリソース名及びリソースの内容に基づいて算出されたハッシュ値を含むものであることを特徴とする請求項５または６に記載のサーバ装置。
【請求項９】
複数の情報要素と、各情報要素からの参照先となる情報要素を特定する情報とを関連づけて保持するデータベースと、クライアント装置とに接続されたサーバ装置を用い、
前記データベース内に保持されている情報要素に係るアクセスの要求を、前記クライアント装置から受け入れる工程と、
当該クライアント装置から、当該クライアント装置を操作する利用者が過去にアクセスした前記情報要素のリストを特定する情報を取得する工程と、
前記取得した情報に基づいて、前記クライアント装置を操作する利用者が過去にアクセスした前記情報要素のリストを特定し、前記要求に係る情報要素が当該リストに含まれるか否か、及び参照先を辿って前記要求に係る情報要素に到達可能な情報要素が当該リストに含まれるか否かを調べ、前記要求に係る情報要素が前記リストに含まれる場合または参照先を辿って前記要求に係る情報要素に到達可能な情報要素が前記リストに含まれる場合には、前記クライアント装置からの前記要求に係る情報要素へのアクセスができると判断し、前記要求に係る情報要素が前記リストに含まれず、かつ参照先を辿って当該要求に係る情報要素に到達可能である情報要素が前記リストに含まれていない場合には、前記クライアント装置からの前記要求に係る情報要素へのアクセスができないと判断する工程と、
を実行することを特徴とする情報の提供方法。
【請求項１０】
複数の情報要素と、各情報要素からの参照先となる情報要素を特定する情報とを関連づけて保持するデータベースと、クライアント装置とに接続されたコンピュータを、
前記データベース内に保持されている情報要素に係るアクセスの要求を、前記クライアント装置から受け入れる手段と、
当該クライアント装置から、当該クライアント装置を操作する利用者が過去にアクセスした前記情報要素のリストを特定する情報を取得する手段と、
前記取得した情報に基づいて、前記クライアント装置を操作する利用者が過去にアクセスした前記情報要素のリストを特定し、前記要求に係る情報要素が当該リストに含まれるか否か、及び参照先を辿って前記要求に係る情報要素に到達可能な情報要素が当該リストに含まれるか否かを調べ、前記要求に係る情報要素が前記リストに含まれる場合または参照先を辿って前記要求に係る情報要素に到達可能な情報要素が前記リストに含まれる場合には、前記クライアント装置からの前記要求に係る情報要素へのアクセスができると判断し、前記要求に係る情報要素が前記リストに含まれず、かつ参照先を辿って当該要求に係る情報要素に到達可能である情報要素が前記リストに含まれていない場合には、前記クライアント装置からの前記要求に係る情報要素へのアクセスができないと判断するアクセス可否判断手段と、
として機能させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ドキュメント等の情報要素をクライアント側に提供するサーバ装置、及びそれにおける情報の提供方法、及びプログラムに関する。
【背景技術】
【０００２】
近年、コンピュータネットワークの発展に伴い、種々の情報がネットワークを介して提供されるようになってきている。こうしたネットワーク上における情報へのアクセス例について、従来のウエブサーバを例にとって、図１２を参照しながら説明する。
【０００３】
図１２は、一般的なコンピュータネットワークシステムを例示する構成ブロック図である。従来一般的なコンピュータネットワークシステムには、図１２に示すように、ウエブサーバ装置１と、クライアント装置２と、これらを相互に接続するネットワーク３とを含む。ここでネットワーク３は、一般的なイーサネット（登録商標）で形成されたものでよい。最も簡単な例としては、ハブ装置を設けて、より対線（ツイストペア）ケーブルによってウエブサーバ装置１のネットワークインタフェースカードとハブ装置との間、並びにクライアント装置２のネットワークインタフェースカードと上記ハブ装置との間を結線した電気的通信経路とすることである。
【０００４】
また、ウエブサーバ装置１及びクライアント装置２は、例えば非特許文献１の第８０ページから第２５８ページに開示されているような、一般的なコンピュータ装置を用いて実現できる。
【０００５】
ウエブサーバ装置１は、ウエブサーバプログラムを記憶しており、このウエブサーバプログラムに従って次のように動作している。
【０００６】
［ウエブサーバプログラムの動作］
次の説明にあたり、各用語を先に規定しておく。なお、以下のウエブサーバプログラムの説明は、インターネットにおける技術標準の提案文書であるＲＦＣ（Request for comments）２６１６番に記述された内容に則して行うこととする。
【０００７】
［用語］
「接続する」とは、通信を行うため、二つのプログラムの間で確立されるトランスポート層の仮想的な通信路を形成することである。具体的にこの接続は、ＴＣＰ／ＩＰ等のプロトコルを介して行われる。ＴＣＰ／ＩＰに関する説明は、例えば非特許文献２等に開示されている。
【０００８】
「メッセージ」とは、所定の規則で配列されたオクテット列であり、ウエブサービスにおける通信の単位となるものである。
【０００９】
「リクエスト」とは、アクセス要求を表現するメッセージである。
【００１０】
「レスポンス」とは、アクセス要求に対する応答を表現するメッセージである。
【００１１】
「リソース」とは、通信網上のデータやサービスである。
【００１２】
「エンティティ」とは、リクエストやレスポンスとともに転送される情報の実体をいう。このエンティティは、エンティティヘッダフィールド形式のメタ情報と、エンティティボディ形式のコンテントを含む。
【００１３】
「ＵＲＩ（Uniform Resource Identifier）」とは、リソースごとに固有の識別子である。その一例は、ＵＲＬ（Uniform Resource Locator）と呼ばれ、一般にプロトコル名（スキームと呼ばれる）と、文字「:」（コロン）と、ネットパス（文字「//」（２つのスラッシュ）で始る文字列であって、サーバを特定する文字列と、当該特定されたサーバにおけるリソースを特定させるための文字列とを含んでなる文字列）とを含む。また、ＵＲＬには、リソースに対して提供されるべきパラメータ情報（クエリとも呼ばれる）が文字「?」（疑問符）に引続いて含められてもよい。このＵＲＬ構文や意味については、インターネットにおける技術標準の提案文書であるＲＦＣ２３９６番等に詳細な記載があるので、ここでのこれ以上の説明は省略する。
【００１４】
［ウエブサーバとクライアントとの間の通信例］
ウエブサーバ装置１は、クライアント装置２からネットワーク３を介してリクエストの列（Request chain）を受信し、このリクエストの列に応答してレスポンスの列（Response chain）を、クライアント装置２に対して送出する。ここでリクエストの列には、リクエストメソッド、ＵＲＩ、プロトコルバージョン、リクエスト修飾子、クライアント情報等を含む。
【００１５】
レスポンスの列には、メッセージのプロトコルバージョンと、応答の成功又はエラーコードを含むステータス行、及びサーバ情報、エンティティに関する情報、そして応答に成功する際には、エンティティボディを含む。
【００１６】
ある例では、リクエスト列に含まれる行は、
メソッド  ＳＰ  ＵＲＩ  ＳＰ  プロトコルバージョン CRLF
との構造を有する。ここでＳＰは、半角のスペース、CRLFは、キャリッジリターン及びラインフィードを表す制御文字である。
【００１７】
メソッドは、ウエブサーバ装置１上のリソースに対してのアクセス種別を表現したもので、主として、「GET」（リソースの取得要求）等がある。このGETメソッドは、引き続くＵＲＩによって識別されるリソースからの情報を取得するための要求であり、当該リソースがドキュメントであればその内容を取得する要求であり、当該リソースが何らかのデータを出力するプログラムであれば、当該出力されるデータの内容を取得する要求となる。
【００１８】
またプロトコルバージョンは、「HTTP/1.1」のようにプロトコルを表す文字列とバージョンを表す文字列との連結からなる。従って、ある例によると、リクエスト列に含まれる行は、
GET http://168.0.0.1/index.html HTTP/1.1
というようになる。
【００１９】
この場合、ウエブサーバ装置１のネットワークインタフェースカードに168.0.0.1なるＩＰアドレスが割当てられていれば、この要求の文字列がウエブサーバ装置１によって受信され、ウエブサーバ装置１は、ドキュメント・ルートとして予め指定されているレポジトリ（例えばディスク上のディレクトリ）から「index.html」という名称で識別されるドキュメント（この場合はＨＴＭＬファイル）を読み出して、レスポンスの列として、ネットワーク３を介して送出する。
【００２０】
レスポンス列の具体的な例を示すと、次のようになる。ウエブサーバ装置１は、レスポンス列の先頭にステータス行を含み、このステータス行は、例えば「HTTP/1.1 200 OK」といった文字列となる。この後にCRLFが続いて送出され、付加的な情報（レスポンスヘッダ）とさらにCRLFが送出され、続いてメッセージ本体が送出される。ここでメッセージ本体は、例えばエンティティボディを含み、例えば上記の例で、index.htmlなるドキュメント内に、「ABC」なる文字列が含められていれば、エンティティヘッダフィールド形式のメタ情報として、「Content-Type:
text/html」等の文字列に続いて、文字列「ABC」が送出される。
【００２１】
また、クライアント装置２が要求したＵＲＩが、ウエブサーバ装置１側のプログラムを示している場合は、ウエブサーバ装置１は、当該プログラムの実行を開始し、当該プログラムの実行結果として得られる文字列をエンティティとして、上記レスポンス列を生成し、クライアント装置２に対してネットワークを介して送出することになる。
【００２２】
この送出したレスポンス列に含まれる文字列は、ネットワークインタフェースカードによって電気信号に変換される。そしてこの電気信号が、ネットワーク３を構成するツイストペアケーブルとハブとを介してクライアント装置２側に到来する。
【００２３】
［クライアント装置２の動作］
クライアント装置２は、ウエブサーバ装置１からネットワーク３を介して到来した電気信号を受けて、この電気信号をレスポンス列に含まれる文字列に変換する。そしてこのレスポンス列に含まれる文字列に基づいてウエブクライアント（いわゆるブラウザ）としての所定の処理を行う。この所定の処理は、例えば当該文字列を画面上に表示するといったものでもよい。
【００２４】
なお、近年では、こうしたレスポンス列に含むエンティティボディ内の文字列にプログラム記述を含めておき、クライアント装置２側で当該プログラム記述に従った動作を行うようにすることもできるようになっている。例えばJavaScriptといった、スクリプト言語と呼ばれる言語規則で記述されたプログラム記述が一般的である。
【００２５】
［従来の情報提供処理の例］
ここまででは、ウエブサーバ装置１とクライアント装置２との間で電気的信号を利用して文字列の情報を送受し、当該文字列の情報によってウエブサーバ装置１側に指示（メソッド）や指示の対象となるリソース（ドキュメントやプログラム等）の指定を伝達して、当該対象となったリソースの提供や実行といった処理をウエブサーバ装置１に行わせる技術や、クライアント装置２側で受け取った文字列に基づいて、当該文字列を表示したり、当該文字列をプログラム記述として、当該記述に従って処理を行ったりといった技術が存在していることを示してきた。
【００２６】
次に、こうした技術を利用して、特定の利用者に対してのみ情報提供を行う場合の従来の処理について、その一例を挙げながら説明する。
【００２７】
この例ではウエブサーバ装置１が備える磁気ディスク内には情報提供の対象となるドキュメント（ここでは対象リソースと呼ぶ）が少なくとも一つ記録されているものとする。またこの例では、クライアント装置２の利用者以外の利用者に対しては当該ドキュメントの提供が行われないような処理が実現される。
【００２８】
ウエブサーバ装置１の磁気ディスク内には、クライアント装置２の利用者の名称（ユーザ名）と、当該利用者が選択したパスワード文字列とが関連づけて記録されている。この関連づけは、例えばデータベースを用いて行うことができる。データベースを実現するため、これらユーザ名やパスワードを関連づけて記録するための基本的なデータ構造等については、例えば二分木（B--Tree）を利用した方法など広く知られた方法があり、その例が［非特許文献３］等に開示されている通りであるから、ここでの詳細な説明を省略する。
【００２９】
これら複数の情報を互いに関連づけたデータベース構造は、概念的には図１３に示すごときテーブルとして表現可能であるので、以下、かかるデータベース構造については、テーブルを用いて説明することとする。
【００３０】
さて、このテーブルを用いた表現によると、ユーザ名とパスワードとを関連づけて記録するデータベースは、図１３のように概念的に示すことができる。
【００３１】
また、ウエブサーバ装置１では、クライアント装置２からユーザ名とパスワードとが送信されてきたときに、図１３に示したテーブルを参照し、当該送信されてきたユーザ名をキーとして、当該キーとなったユーザ名に関連づけられたパスワードを検索し、検索の結果得られたパスワードと、クライアント装置２から送信されてきたパスワードとを照合して、一致しているときに、対象リソースの内容を送信するプログラム（パスワード照合プログラム）を磁気ディスク内に保持している。
【００３２】
ウエブサーバ装置１は、クライアント装置２から対象リソースの取得要求（GETメソッドと対象リソースを識別するＵＲＩとを含むリクエスト列）を受け入れると、クライアント装置２に対してユーザ名とパスワードとを入力させるためのレスポンス列を送信する。
【００３３】
クライアント装置２では、当該レスポンス列を受信して、ユーザ名とパスワードとを入力させる画面を表示する。ここでＨＴＴＰ認証が要求された場合には、それに対する処理を行う。あるいは、ＨＴＭＬ（Hyper Text Markup Language）を用いた記述に従い、例えばマイクロソフト（商号）社のインターネット・エクスプローラ（商標）をウエブクライアントとして用いて表示させることができるものである。なお、ＨＴＭＬは、Ｗ３Ｃ（World Wide Web Consortium）と呼ばれる非営利団体によりその仕様が策定されている言語であり、この言語の一部として、文字のみならず、文字列の入力欄（フィールド）を表示する指示や、当該入力された文字列をウエブサーバ装置１側にＵＲＩと同様の記述方法で送信するための指示などが含まれている。これらの指示やＵＲＩと同様の記述方法での送信（GETやPOSTなどのメソッドを用いた方法）などについては、非特許文献４や非特許文献５等に詳細に説明されているので、ここではこれ以上の説明をしないこととする。
【００３４】
クライアント装置２は、利用者がキーボードやマウス等を操作して、ユーザ名やパスワードを入力し、その入力した文字列の送信指示を行うと、パスワード照合プログラムのリソースの取得要求とともに、当該入力されたユーザ名やパスワードをウエブサーバ装置１側に送信する。
【００３５】
すると、ウエブサーバ装置１が指定されたリソースであるパスワード照合プログラムの処理を開始し、当該送信されたユーザ名をキーとして、ユーザ名とパスワードとを関連づけて記録するデータベースを参照して、当該キーとなったユーザ名に対応づけて、当該データベースに記録されているパスワードを取り出して、クライアント装置２側から送信されてきたパスワードと、当該取り出したパスワードとを照合する。そして、これらのパスワードが一致したときに、当該クライアント装置２に対して、先に要求されていた対象リソースの内容を磁気ディスクから読み出して送信する。
【００３６】
一方、パスワードが一致しなかった場合は、「パスワードが一致しません」等の文字列をクライアント装置２に送出する。なお、データベースを参照したときに、キーとなったユーザ名が当該データベース内に記録されていない場合も、「パスワードが一致しません」等の文字列をクライアント装置２に送出することとしてもよい。この文字列は、「ユーザ名が登録されていません」のようなものでもよい。
【００３７】
このような処理が行われる結果、利用者がキー操作を誤ってユーザ名やパスワードの文字列として誤った文字列を送信した場合や、又は当該利用者以外の者が、例えばランダムに選択したユーザ名やパスワードを入力した場合などには、ユーザ名やパスワードがデータベース内に記録されているものに一致しないので、「パスワードが一致しません」などの表示が現れ、指定したリソースの内容が提供されることがない。
【００３８】
また、リソースごとに設定されたアクセスキーの情報を事前にクライアント装置２側に記録させ、リソースへのアクセス要求を行う際に、当該記録されているアクセスキーを送信させて、当該アクセスキーをウエブサーバ装置１側で受信し、正当性を検証するというような、いわばケーパビリティベースのアクセス制御を行うシステムの例も考えられている。
【非特許文献１】馬場敬信著，「コンピュータアーキテクチャ」，改訂２版，オーム社，平成１２年２月２５日
【非特許文献２】トランジスタ技術，２００２年１２月号，ＣＱ出版社，第１３４ページから第１３７ページ
【非特許文献３】情報処理学会編，「エンサイクロペディア情報処理２０００／２００１」，第１版，オーム社，平成１２年３月２５日，第３０２ページから第３０３ページ
【非特許文献４】アンク著，「ホームページ辞典」，初版，株式会社翔泳社，２０００年５月１０日
【非特許文献５】秋本祥一、古川剛著，「ＣＧＩプログラミング入門」，初版，株式会社翔泳社，１９９７年２月２０日
【非特許文献６】E.Goto "Monocopy and Associate Algorithms in an ExtendedLisp", Technical Report TR 74-3, May1974, University of Tokyo
【特許文献１】USP5,978,792
【発明の開示】
【発明が解決しようとする課題】
【００３９】
しかしながら、上記従来例で説明したような情報提供のシステムなどでは、事前にユーザを登録する必要があったり、利用者側にアクセスキーとなる情報を提供しておく必要があるため、アクセス制御のために利用者ごとの情報を管理するデータベース等が不可欠となって、そのメンテナンスに係る負荷がかかるなど、利便性が低い。
【００４０】
また、ユーザ登録やアクセスキーの配付等、システム運用のポリシー設定がサービス管理側に集中してしまい、この負荷を分散させることが困難であるので、総体として複雑なポリシーが適用しにくいという問題点があった。
【００４１】
本発明は上記実情に鑑みて為されたもので、利用者ごとの管理を行うことなく、アクセス制御を実現でき、またポリシー設定も分散させることができ、利便性を向上できるサーバ装置、情報の提供方法、及びプログラムを提供することを、その目的の一つとする。
【課題を解決するための手段】
【００４２】
上記従来例の問題点を解決するための本発明は、情報要素をノードとして含んでなる情報要素ネットワークを保持するデータベースと、クライアント装置とに接続されるサーバ装置であって、前記データベース内に保持されている情報要素ネットワーク上の情報要素に係るアクセスの要求を、前記クライアント装置から受け入れる手段と、当該クライアント装置から、前記情報要素ネットワークに含まれる情報要素への過去のアクセス履歴に関連する情報を取得する手段と、前記取得した情報に基づいて、前記要求に係る情報要素よりも前記情報要素ネットワーク上で上位の情報要素のいずれか一つが前記クライアント装置によって過去にアクセスされたか否かを判断し、当該判断の結果により、前記クライアント装置からの前記要求に係る情報要素へのアクセスの可否を決定する手段と、を含むことを特徴としている。
【００４３】
ここで、受け入れるアクセスの種別に関連した情報要素であって、当該情報要素に対して前記クライアント装置が過去にアクセスをしたか否かにより、当該情報要素に関連する種別のアクセスの可否が定められる情報要素が、前記データベース内の情報要素ネットワーク内に含められていることとしてもよい。
【００４４】
また上記従来例の問題点を解決するための本発明は、情報要素をノードとして含んでなる情報要素ネットワークを保持するデータベースと、クライアント装置とに接続されるサーバ装置であって、前記情報要素の少なくとも一部について、当該情報要素へのアクセス種別ごとのアクセスキーとなる少なくとも一つの情報要素を関連づけて保持するアクセスキー保持手段と、前記データベース内に保持されている情報要素ネットワーク上の情報要素に係るアクセスの要求を、前記クライアント装置から受け入れる手段と、当該クライアント装置から、前記情報要素ネットワークに含まれる情報要素への過去のアクセス履歴に関連する情報を取得する手段と、前記取得した情報に基づいて、前記要求に係る情報要素について当該要求されたアクセス種別にアクセスキーとして関連づけられた情報要素のいずれか一つが、前記クライアント装置によって過去にアクセスされたか否かを判断し、当該判断の結果により、前記クライアント装置からの前記要求に係る情報要素へのアクセスの可否を決定する手段と、を含むことを特徴としている。
【００４５】
これらのように、クライアント装置の過去のアクセス履歴によってリソースへのアクセス可否が定められるので、事前の利用者登録など、利用者ごとの情報管理の手間なく、アクセス制御が実現される。
【００４６】
またここで情報要素に関連した所定特徴量を演算する特徴量演算手段をさらに含み、前記クライアント装置に対して、当該クライアント装置からの要求に係る情報要素へのアクセスを行わせたときに、当該要求に係る情報要素に関連する関連情報を、前記クライアント装置側に対して送信する手段と、を含み、前記クライアント装置側に保持されている前記関連情報が、前記過去のアクセス履歴に関連する情報としての所定処理に供されることとしてもよい。
【００４７】
これにより、クライアント装置の過去のアクセス履歴によってリソースへのアクセス可否が定められ、事前の利用者登録など、利用者ごとの情報管理の手間なく、アクセス制御が実現される。
【００４８】
さらに、前記特徴量演算手段は、前記過去にアクセスされたノードのリストに関する、別の所定特徴量を演算し、当該演算された所定特徴量が、前記関連情報に関する情報として用いられることとしてもよい。これにより、関連情報をより短いデータで表現可能となる。
【００４９】
この場合に、前記特徴量の演算方法は、当該特徴量がとりうる量全体からなる空間内で、当該とりうる量のうち前記情報要素のいずれかに対応する特徴量の分布確率が所定量以下となるよう定められていることしてもよい。これにより特徴量を推定してアクセス権を獲得する攻撃に対する耐性が向上する。
【００５０】
また、上記従来例の問題点を解決するための本発明は、サーバ装置であって、1以上のリソースを含む構造を持つデータベースを管理するサーバ装置において、前記リソースに対するアクセス要求時に受信したリソース名と、前記データベースに対するアクセス履歴を示すユーザコンテクスト情報とに基づいて、当該リソースに対するアクセス権を判断する判断手段を具備することを特徴とすることとしてもよい。これにより、アカウント登録などの煩雑な事前準備が不要となる。
【００５１】
さらに前記判断手段は、当該リソース名が当該ユーザコンテクスト情報に含まれるかどうかを判断することにより、当該リソースに対するアクセス権を判断することとしてもよい。これによって判断処理が容易となる。
【００５２】
さらに、前記データベースの構造は、前記1以上のリソースが関係付けられる構造であって、前記リソースをノードとするネットワーク構造、前記リソースをノードとする木構造のうち、いずれかを含むものであることとしてもよい。これにより、広範囲のデータベースに適用可能となる。
【００５３】
さらに前記データベースの構造は、複数のノードを有し、各ノードには、ノード間の参照関係情報を持ち、前記ユーザコンテクスト情報は、少なくとも過去にアクセスした参照元ノードとして最上位のノードのリソース名に対応するものを含むものであることとしてもよい。これによって少なくとも最上位のノードのリソースが分かれば、その参照先のアクセスを許可するとすれば、簡単にアクセス権の判断ができる。
【００５４】
さらに、サーバ装置は、ウエブサーバであり、前記リソース名をURLとして受信すると共に、前記コンテキスト情報をクッキー領域の情報として受信するものであることとしてもよい。HTMLなどのマークアップ言語を使用するウエブサーバに対して使用される一般的なメッセージの形式が利用でき、特殊な形式を用いないので、本発明をウエブサーバに容易に適用できる。
【００５５】
また、前記ユーザコンテクスト情報は、リソース名に基づいて算出されたハッシュ値を含むものであることとしてもよい。これによると、リソース名に対応しているので、判断処理が容易となる。
【００５６】
さらに前記ユーザコンテクスト情報は、リソース名及びリソースの内容に基づいて算出されたハッシュ値を含むものであることとしてもよい。リソースの内容も含まれるので、リソース名等に比べて、類推が困難となり、真にリソースに対して閲覧等のアクセスをしたものしかアクセスが出来なくなり、安全性の高いアクセス制御が可能となる。
【００５７】
また、データベースに対する最初のアクセス時には、特殊形のリソース名を受信し、当該リソースに対応する通常のリソース名及びユーザコンテクスト情報を返信し、返信した通常のリソース名及びユーザコンテクスト情報とによる再度のアクセス要求を受信することとしてもよい。特殊形態のリソース名をアクセス権者から受け取れば、初回のアクセスが導入でき、特殊形態のリソース名のリソースに対応する通常のリソース名及びコンテキスト情報返信することにより、2回目以降のアクセス権の判断と同様にできるので、判断処理が簡単となる。
【００５８】
また、特殊形のリソース名を指定したリクエストに対するレスポンスが実体を直接返信しないことにより、特殊形のリソース名の露出が抑制され、安全性が増す。
【００５９】
この場合に、前記データベースは、リソース名と、リソース名に対応したリソースの内容に基づくハッシュ値とを持ち、前記特殊形のリソース名には、当該リソース名に対応するリソースの内容に基づいたハッシュ値を含むものであることとしてもよい。データベースには、リソース名と、リソース名に対応したリソースの内容に基づくハッシュ値とを持つので、特殊形のリソース名に対して、通常のリソース名の対を特別に持つことなく、特殊形のリソース名から通常のリソース名に変換できて、クライアント装置に通常のリソース名として返信できる(リソースの内容が変わっても前のバージョンへのリンクを持つリンクリストを持つことによりリソース名にたどり着くことは可能)。
【００６０】
本発明の一態様に係る情報の提供方法は、情報要素をノードとして含んでなる情報要素ネットワークを保持するデータベースと、クライアント装置とに接続されたサーバ装置を用いて実行され、前記データベース内に保持されている情報要素ネットワーク上の情報要素に係るアクセスの要求を、前記クライアント装置から受け入れる工程と、当該クライアント装置から、前記情報要素ネットワークに含まれる情報要素への過去のアクセス履歴に関連する情報を取得する工程と、前記取得した情報に基づいて、前記要求に係る情報要素よりも前記情報要素ネットワーク上で上位の情報要素のいずれか一つが前記クライアント装置によって過去にアクセスされたか否かを判断し、当該判断の結果により、前記クライアント装置からの前記要求に係る情報要素へのアクセスの可否を決定する工程と、を含む。
【００６１】
また、本発明の別の態様に係るプログラムは、情報要素をノードとして含んでなる情報要素ネットワークを保持するデータベースと、クライアント装置とに接続されたコンピュータによって実行されるもので、前記データベース内に保持されている情報要素ネットワーク上の情報要素に係るアクセスの要求を、前記クライアント装置から受け入れる手順と、当該クライアント装置から、前記情報要素ネットワークに含まれる情報要素への過去のアクセス履歴に関連する情報を取得する手順と、前記取得した情報に基づいて、前記要求に係る情報要素よりも前記情報要素ネットワーク上で、上位の情報要素のいずれか一つが前記クライアント装置によって過去にアクセスされたか否かを判断し、当該判断の結果により、前記クライアント装置からの前記要求に係る情報要素へのアクセスの可否を決定する手順と、を上記コンピュータ実行させることを特徴としている。
【発明の効果】
【００６２】
これらによれば、クライアント装置の過去のアクセス履歴によってリソースへのアクセス可否が定められるので、事前の利用者登録など、利用者ごとの情報管理の手間なく、アクセス制御が実現され、利便性を向上できる。
【発明を実施するための最良の形態】
【００６３】
［第１実施形態］
本発明の第１の実施の形態について図面を参照しながら説明する。本実施の形態に係るウエブサーバ装置１００は、図１に示すように、ＣＰＵ１１と、システムコントローラ１２と、スイッチ１３と、メモリ１４と、バスインタフェース１５と、マウス１６と、キーボード１７と、バス１８と、磁気ディスク１９と、ネットワークインタフェース（Ｉ／Ｆ）２０と、表示制御部２１とを含み、ディスプレイ３０に接続されている。なお、この構成は、非特許文献１に記載された構成を簡略に示したものである。このウエブサーバ装置１００のネットワークＩ／Ｆ２０は、ネットワーク３を介してクライアント装置２に接続されている。
【００６４】
ＣＰＵ１１は、磁気ディスク１９に格納されているプログラムを読出して、当該読出したプログラムに従ってウエブサーバとしての処理を実行する。このＣＰＵ１１によって実行されるウエブサーバとしての処理については、後に詳しく述べる。
【００６５】
システムコントローラ１２は、ＣＰＵ１１から入力される指示に従ってＣＰＵ１１との間で情報を入出力する先を指定する信号をスイッチ１３に出力する。スイッチ１３は、システムコントローラ１２から入力される信号に従って、ＣＰＵ１１との間で情報を入出力するための配線を、メモリ１４、バスインタフェース１５、表示制御部２１といった各部のいずれかに接続する。
【００６６】
メモリ１４は、基本的にＲＡＭ（Random Access Memory）からなり、ＣＰＵ１１から書込み指示と書込み対象となるデータとの入力を受けて、当該データを記憶する。なお、ここで書込み指示には、メモリ上の書込み位置を表すアドレス情報が含まれている。また、このメモリ１４は、ＣＰＵ１４から読出しの指示の入力を受けると、当該読出し指示に含まれているアドレス情報に書込まれているデータを読み出して、ＣＰＵ１１に対して出力する。
【００６７】
バスインタフェース１５は、バス１８を制御しており、このバス１８を介してキーボード１７や磁気ディスク１９、ネットワークＩ／Ｆ２０といった各部との間で信号を授受している。バスインタフェース１５は、ＣＰＵ１１から信号が入力されると、当該信号をバス１８を介して送出する。また、このバスインタフェース１５は、キーボード１７や磁気ディスク１９、ネットワークＩ／Ｆ２０といった各部から信号が入力されると、当該信号をＣＰＵ１１に送出する。
【００６８】
マウス１６は、キーボード１７を介してバス１８に接続される。このマウス１６は、いわゆるポインティングデバイスであり、利用者がマウス本体を机上で移動させると、当該移動量に関する情報をキーボード１７を介してバス１８に出力する。なお、ここではキーボード１７を介してバス１８に接続する例を示したが、直接接続する構成となっている装置であっても構わない。
【００６９】
キーボード１７は、文字列を入力するためのデバイスであり、利用者の操作によって入力された文字列を表す情報をバス１８に出力する。
【００７０】
磁気ディスク１９は、ハードディスク等であり、ＣＰＵ１１から書込み命令及び書込みの対象となるデータを、バス１８を介して受け入れて、磁気的信号に変換し、磁気ディスク面に記録する。また、この磁気ディスク１９は、ＣＰＵ１１からの読出し命令を、バス１８を介して受け入れて、磁気ディスク面に記録された情報を磁気ヘッドにて読取って、電気的信号に変換し、バス１８に出力する。
【００７１】
ネットワークＩ／Ｆ２０は、ＣＰＵ１１から、送信先のアドレス情報を含む送信対象データの入力を受けて、送信対象データをネットワーク３側に適合した電気的信号に変換してネットワーク３に対して送出する。また、このネットワークＩ／Ｆ２０は、ネットワーク３側から到来する電気的信号からデータを復調して得て、当該データがネットワークＩ／Ｆ２０に対して予め割当てられているアドレスに対応する宛先へのデータであるか否かを調べ、そうでなければ当該データを破棄する。また、当該データがネットワークＩ／Ｆ２０に対して予め割当てられているアドレスに対応する宛先へのデータであれば、当該データをバス１８に出力する。
【００７２】
すなわち、本実施の形態のウエブサーバ装置１００においては、ＣＰＵ１１が磁気ディスク１９との間で情報の書込み／読出しを行うときには、次のように動作することになる。まずＣＰＵ１１はシステムコントローラ１２に対してスイッチ１３をバスインタフェース１５に接続するよう指示する。するとシステムコントローラ１２がスイッチ１３にＣＰＵ１１からの信号線をバスインタフェース１５に接続するよう指示し、スイッチ１３がＣＰＵ１１からの信号線をバスインタフェース１５に接続する。
【００７３】
このようにしてから、ＣＰＵ１１が、信号線を介してバスインタフェース１５に対し、磁気ディスク１９に信号の書込み命令と書込みの対象となるデータを出力すると、当該データが磁気ディスク１９に記録されることとなり、ＣＰＵ１１が、信号線を介してバスインタフェース１５に対し、磁気ディスク１９に信号の読出し命令を出力すると、当該命令に従ってデータが磁気ディスク１９から読出されてバスインタフェース１５を介してＣＰＵ１１に出力されることになる。以下、この動作については、「ＣＰＵ１１が磁気ディスク１９にデータを書込む」又は「ＣＰＵ１１が磁気ディスク１９からデータを読み出す」といったように略記することとする。
【００７４】
また、ネットワークＩ／Ｆ２０についても同様の動作となっており、この動作については、「ＣＰＵ１１がネットワーク３を介してデータを送信する」又は「ＣＰＵ１１がネットワーク３を介してデータを受信する」といったように略記することとする。
【００７５】
磁気ディスク１９内にはリソースが保持されている。この磁気ディスク１９内には、ドキュメント等の情報要素（リソース）を保持するデータベースが構成されている。以下の説明では、簡単のため、情報要素がドキュメントであるものとして説明する。
【００７６】
本実施の形態において特徴的なことの一つは、ここでの情報要素間で参照関係が規定されており、この参照関係が、情報要素をノードとしたときに非循環有向グラフ状の情報要素ネットワークとなっていることである。ここで非循環有向グラフとは図２（ａ）のような関係にあるものであり、図２において各ノードは丸印で示され、参照関係が矢印で示されている。例えば「ルート」となっているノードが参照している先は、ノードＰ０及びＰ１であり、ノードＰ０の参照元のノードは「ルート」であるということになる。このように、参照関係は方向性を持っており、ルートから、その参照先であるＰ０へは参照関係を辿ることができるが、Ｐ０から、その参照元であるルートへは参照関係を辿ることができないとして規定されている。なお、この非循環有向グラフには、概念的に図２（ｂ）に示すような有向ツリーが含まれるので、本実施の形態における情報要素の格納状態は、この有向ツリー状の情報要素ネットワークとなっているものも含む。
【００７７】
また、図２（ａ）では２つのルート以下の情報要素ネットワークを示しているが、このように情報要素ネットワーク全体としては、複数のルートを含んでもよい。また図２（ａ）に示すように、複数のルートには、同一のノードが、下位に属するノードとしてリンクづけされていてもよい（図２（ａ）でのノードＰ０等）。
【００７８】
また、以下では説明のために、いずれかのノードを注目ノードとして、当該注目ノードから参照関係を辿って到達できる別の（注目ノードではない別の）ノードを注目ノードの「下位ノード」と呼び、また、参照関係を辿って注目ノードへ到達できる別の（注目ノードではない別の）ノードを注目ノードの「上位ノード」と呼ぶ。例えば、図２の例でいえば、ノードＰ２を注目ノードとすると、ノードＰ５，Ｐ７，Ｐ８，…が、Ｐ２の下位ノードであり、ノードＰ１と、ルートとがＰ２の上位ノードである。
【００７９】
具体的にドキュメントがＨＴＭＬである場合、参照関係は「Ａタグ」を用いて記述することができる。例えばノードＰ０への参照関係は「<a href="P0">P0</a>」として記述できる（図３）。
【００８０】
また、磁気ディスク１９内には、図４に示すように、各ノードであるドキュメントの名称（ノード名）と、当該ドキュメントの内容から演算された特徴量としてのハッシュ値と、当該ドキュメントからの参照先（ＨＴＭＬのリンク先）となっているノードのリストと、当該ドキュメントへの参照元（ＨＴＭＬのリンク元）となっているノードのリストとを相互に関連づけて保持している。なお、この図４に示したテーブルも、データベースとして一般的な手法で実際に格納できるものである。なお図４において、リンク先やリンク元がない場合には、理解しやすいように「（なし）」と記している。
【００８１】
ここでハッシュ値は、ドキュメントに含まれる文字列に基づき、所定一方向関数によって演算できる値である。ハッシュ値の演算方法は、広く知られているので、ここでの詳細な説明を省略する。なお、ここでのハッシュ値は２０バイト程度の列として表現できるが、これに限られるものではなく、６４バイト程度としてもよい。このハッシュ値の長さによって、特徴量がとりうる量全体からなる空間内で、当該とりうる量のうち情報要素のいずれかに対応する特徴量の分布確率が所定量以下となるよう定めることができる。
【００８２】
［ＣＰＵ１１の動作］
次に、ＣＰＵ１１によって行われる処理について説明する。本実施の形態では、従来と同様のウエブサーバとして動作するほか、情報提供のためのプログラムがリソース（以下、このリソースのリソース名が「wiki.cgi」であるものとして説明を続ける）として磁気ディスク１９に格納されている。つまり、クライアント装置２からGETメソッドとともに、ＵＲＩの一種としてＵＲＬとして「http://server/wiki.cgi」が指定されると、この情報提供のためのプログラムが起動される。なお、ウエブサーバ装置１００のネットワークＩ／Ｆ２０に割当てられているＩＰアドレスに対して、ネットワーク３上に接続されているＤＮＳ（ドメインネームシステム）サーバが名称「server」を関連づけて保持しているものとし、クライアント装置２からは、名称「server」により、ウエブサーバ装置１００との間の情報通信が可能となっているものとする。
【００８３】
また、本実施の形態では、この情報提供のためのプログラムに対する処理のパラメータとして、要求名と、当該要求名に係る要求の対象となるリソース（上記非循環有向グラフ状の情報要素ネットワーク内のリソース）とが指定されることとなる。ここで本実施の形態の情報提供のためのプログラムは、指定したリソースの閲覧（ビュー：view）、指定したリソースの編集（ある場合には、指定したリソースからの参照先となる新たなリソースの生成も伴う、以下エディット：editと表す）、指定したリソースへの参照元となる新たなリソースの生成（クリエイト：create）、指定したリソースへの初回アクセスの許可（インフォーム：inform）の要求に応答するためのプログラムモジュールを含んでなる。
【００８４】
クライアント装置２は、この要求名と要求名に係る要求の対象となるリソースの指定とを、次の態様（要求文と呼ぶ）で送出するものとする。
【００８５】
ｈｔｔｐ://server/wiki.cgi/resource?edit
【００８６】
ここで、「resource」がリソースの指定に相当し、「?」の次からの文字列は処理パラメータ（クエリ）を示す。ここでは、処理パラメータとして要求名「edit」がそのまま記述されている。なお、基本的な処理である閲覧の処理については、クエリとして「view」と記述しなくても、
ｈｔｔｐ://server/wiki.cgi/resource
とすれば、閲覧が指定されたものとして扱ってもよい。
【００８７】
ＣＰＵ１１は、クライアント装置２からネットワーク３を介して要求文を受信し、処理パラメータが付されているか否かを調べ、付されていなければ閲覧の要求として、閲覧要求に応答する処理を開始する。また、処理パラメータが付されている場合、それが「view」であれば閲覧の要求として、閲覧要求に応答する処理を開始し、「edit」であれば編集の要求として、閲覧要求に応答する処理を開始し、「create」であればクリエイトの要求として、クリエイトの要求に応答する処理を開始し、「inform」であればインフォームの要求として、インフォームの要求に応答する処理を開始する。以下、これらの各要求に応答する処理について説明する。
【００８８】
［要求名viewに対する処理］
まず、要求名viewに対する処理について、図６を参照しながら説明する。ＣＰＵ１１は、まず、指定されたリソースの表現が予め定められた条件に合致する表現（以下、「特殊形の表現」と呼ぶ）であるか否かを調べ（Ｓ１１）、特殊形の表現でなければ（「Ｎ」であれば）、指定されたリソースが予め定められた公開リソースであるか否かを調べる（Ｓ１２）。
【００８９】
ここで公開リソースは、「index.html」や、「search.html」といったように、公開された（つまりどの利用者からもアクセス可能な）リソースであり、これらのリストが予め設定されて、メモリ１４に保持されており、ＣＰＵ１１は、指定されたリソースがこれら設定されたリストに含まれているか否かを調べることになる。
【００９０】
なお、公開リソースには、利用者が過去に参照したリソースの一覧を提供するもの（例えば「index.html」となる）や、利用者が過去に参照したリソース内での情報検索インタフェースを提供するもの（例えば「search.html」となる）などを含んでもよい。また、この公開リソースからのリンク先のリソース（下位ノード）もまた、公開リソースとなる。
【００９１】
処理Ｓ１２において、指定されたリソースが公開リソースでない場合、ＣＰＵ１１は、クライアント装置２に対してクライアント装置２側に保持されているアクセス履歴を取得する（Ｓ１３）。ここでクライアント装置２側に保持されているアクセス履歴は、クッキー（cookie）として保持しておくことができ、クッキーは、ＨＴＴＰリクエストのCookieフィールド等に含められてサーバ装置側に提供される。ここでクッキーにセキュア（secure）属性を付することで、ＨＴＴＰリクエストが、暗号化されて送信されることが望ましい。
【００９２】
また、アクセス履歴は、具体的にはリソース名のリストそのものであってもよいし、当該利用者が過去にアクセスしたリソースのリストを特定する情報であってもよい。これが本発明のクライアントコンテクストの一例でもある。例えば、利用者が過去にアクセスしたリソースに対応するノード名をキーとし、リソースの内容に基づいて演算されるハッシュ値を「値」としたエントリーを含む連想配列と、当該連想配列のハッシュ値とを、図５に示すように関連づけて格納しておく。
【００９３】
ＣＰＵ１１は、取得したアクセス履歴に基づいて、指定されたリソースへのアクセスが可能か否かを判断する（Ｓ１４）。ここでの判断は次のようにして行われる。すなわち、ＣＰＵ１１は、アクセス履歴に基づいて、利用者が過去にアクセスしたリソースのリストを特定し、当該リストに指定されたリソースが含まれるか、又は当該リストに含まれるリソースから参照関係を辿って指定されたリソースに到達可能か否か、つまり当該リストに含まれるリソースの少なくとも一つの下位ノードとして指定されたリソースが含まれるか否かを調べる。
【００９４】
具体的に指定されたリソースが図２に示したノードＰ５に相当するものである場合、当該リソースを要求した利用者が過去にノードＰ１に相当するリソースにアクセス（この場合は、view、edit等の要求を行って、当該リソースの内容の提供を受けることをアクセスと呼んでいる）したことがあれば、当該利用者のアクセス履歴としてのリソースのリストにはノードＰ１に対応するリソースが含まれている。
【００９５】
一例として、ノードＰ０に対応するハッシュ値をＨ０、ノードＰ１に対応するハッシュ値をＨ１…として表記することとするとき、過去にノードＰ１に対応するリソースにアクセスした利用者のアクセス履歴には、図５に示したように、ノード名「Ｐ１」をキーとし、そのハッシュ値「Ｈ１」を値としてこれらキーと値とを関連づけるエントリーを含んだ連想配列を特定するためのハッシュ値が設定されていることになる。
【００９６】
そしてＣＰＵ１１は、クライアント装置２からアクセス履歴として受け入れたハッシュ値に基づいて図５に示したテーブルを参照して連想配列を取得し、当該連想配列に基づいて、クライアント装置２の利用者が過去にアクセスしたノード名のリストを、当該連想配列のキーのリストとして取得し、連想配列に含まれる各ノード名で特定されるノードを起点として、図４に示したテーブルを参照しながら、その下位ノードを参照するリストを用いて再帰的に到達可能なノードを列挙し、指定されたリソースに相当するノードに一致するものがあるか、又はリーフ（末端のノード）まで辿っても、指定されたリソースに相当するノードに一致するものがなかったかを調べることになる。
【００９７】
この探索の結果、指定されたリソースに相当するノードに一致するものが見いだされなければ、指定されたリソースへのアクセスができないと判断することになる。また、探索の結果、指定されたリソースに相当するノードに一致するものが見いだされたならば、指定されたリソースへのアクセスができると判断されることになる。
【００９８】
以上に例示した処理によって、処理Ｓ１４で指定されたリソースへのアクセスが可能であると判断されると（「Ｙ」であると）、ＣＰＵ１１は、磁気ディスク１９から当該指定されたリソースであるドキュメントの内容を読出して、それをエンティティボディとして含むレスポンス列を、ネットワーク３を介してクライアント装置２へ送信する（Ｓ１５）。なお、当該ドキュメントの内容やアクセス履歴に基づいてエンティティボディを生成してもよい。例えば、指定されたリソースに関連づけられているリンク元のノードのリストに含まれるノード名のうち、アクセス履歴に基づいて取得された連想配列に含まれるノード名へのリンクをバックリンクとして含めてもよい。
【００９９】
そしてＣＰＵ１１は、当該アクセスされたリソースであるノード名と、アクセスされたリソースの内容に基づいて生成されたハッシュ値とからなるエントリーを、利用者のアクセス履歴に基づいて取得された連想配列に含めて、アクセス履歴の情報を新たに生成する（Ｓ１６）。また、その含めた後の連想配列に基づくハッシュ値を演算して、図５に示したテーブルに格納する。
【０１００】
例えば、ここでアクセスされたリソースがノードＰ５に相当するものである場合、それに対応するハッシュ値Ｈ５を、ノードＰ５とハッシュ値Ｈ５とを含むエントリーを連想配列に追加して、新たな連想配列を生成し、この連想配列に基づいてハッシュ値を演算し、演算されたハッシュ値と、上記生成した連想配列とを関連づけて、磁気ディスク１９内に保持されている、図５に示したテーブルを実現しているデータベースに登録する。
【０１０１】
尤も、ドキュメントの内容が変更された場合にはノードに対応するハッシュ値が変わることがある。例えば、ハッシュ値Ｈ２がＨ′２となることがあり、その場合には、図４に示したテーブルを実現するデータベースの内容は更新されるが、連想配列中の情報は変更する必要は必ずしもない。この情報を利用者が過去に見た状態を表す情報として利用することもできるからである。
【０１０２】
ＣＰＵ１１は、処理Ｓ１５で生成したアクセス履歴の情報を、クライアント装置２へ送信してクライアント装置２に保持させる（Ｓ１７）。この処理Ｓ１７における処理は、ＨＴＴＰレスポンスヘッダのSet-Cookie/Set-Cookie2フィールドで指定することで行うことができる。なお、この際、セキュア（Secure）属性を付して、クッキーを暗号化して送信する。ＣＰＵ１１は、これによりクライアント装置２側のアクセス履歴の情報を更新して処理を終了する。
【０１０３】
一方、処理Ｓ１４において、指定したリソースへのアクセスができないと判断された場合は、ＣＰＵ１１は、クライアント装置２に対してリソースの提供ができないことを報知して（Ｓ１８）、処理を終了する。この報知は、例えばレスポンス列のステータスコードとしてエラーのコードを送信することによって行うことができる。この場合、クライアント装置２がそのウエブクライアントの画面に「401 Unauthorised」のような表示を行うことになる。なお、エラーコードは４０１だけでなく４０４であってもよいし、またエラーとせず、エンティティボディを空として送信することとしてもよい。
【０１０４】
さらに、処理Ｓ１１において、指定されたリソースの表現が特殊形である場合、又は処理Ｓ１２において指定されたリソースが特定リソースである場合、処理Ｓ１５に移行して処理を続け、当該指定されたリソースに対応するドキュメントの内容が提供されることになる。このときには、新たに生成したアクセス履歴の情報をクッキーとして指定し、ロケーション（Location）フィールドとして通常のノード名に変換したものを指定して、エンティティボディを空などとしたものをＨＴＴＰレスポンスとして送信し、クライアント装置２に対して当該ロケーションフィールドで指定したリソースへとアクセスさせる。
【０１０５】
［要求名editに対する処理］
次に、要求名editに対する処理について図７を参照しながら説明する。ＣＰＵ１１は、まず、クライアント装置２側に保持されているアクセス履歴を取得する（Ｓ２３）。そして、ＣＰＵ１１は、取得したアクセス履歴に基づいて、指定されたリソースへのアクセスが可能か否かを判断する（Ｓ２４）。
【０１０６】
ここで処理Ｓ２３からＳ２４までの処理は、図６の処理１１から処理Ｓ１４におけるものと同様であるので、繰返しての説明は省略する。
【０１０７】
この処理Ｓ２４で指定されたリソースへのアクセスが可能であると判断されると（「Ｙ」であると）、ＣＰＵ１１は、磁気ディスク１９から当該指定されたリソースであるドキュメントの内容を読出して、それをエンティティボディとして含むレスポンス列を、ネットワーク３を介してクライアント装置２へ送信して編集させる（Ｓ２５）。すなわち、ここでの送信は、編集可能な態様で送信されることとなる。例えば、ＨＴＭＬを利用してドキュメントの内容をフォーム（formタグ内の）のテキストエリア（<textarea>）の内容として含めて送信することになる。
【０１０８】
クライアント装置２側からフォームの内容が送信（submit）されると、当該フォームの内容を含むＨＴＴＰリクエストが受信され、ＣＰＵ１１は、当該編集内容のコミット処理（編集の内容を確定させる処理）を開始する（Ｓ２６）。このコミット処理の内容は後に説明する。コミット処理によって、編集の内容が確定される。
【０１０９】
一方、処理Ｓ２４において、指定したリソースへのアクセスができないと判断された場合は、ＣＰＵ１１は、クライアント装置２に対してリソースの提供ができないことを報知して（Ｓ２８）、処理を終了する。この報知は、例えばレスポンス列のステータスコードとしてエラーのコードを送信することによって行うことができる。この場合、既に述べた例と同様にクライアント装置２がそのウエブクライアントの画面に「401 Unauthorised」のような表示を行うことになる。
【０１１０】
次に、コミット処理について説明する。ＣＰＵ１１は、編集後のフォームの内容を含むＨＴＴＰリクエストを受信すると、クライアント装置２側に保持されているアクセス履歴を取得し、取得したアクセス履歴に基づいて、指定されたリソースへのアクセスが可能か否かを判断する処理（上記処理Ｓ２３，２４と同様の処理）を行い、アクセスが可能でなければ、ＣＰＵ１１は、クライアント装置２に対してリソースへのアクセスができないことを報知して（上記処理Ｓ２８と同じ）、処理を終了する。
【０１１１】
また、アクセスが可能であれば、図８に示すような処理を開始する。すなわち、ＣＰＵ１１は、そのリソースの編集前の内容と編集後の内容とを比較する（Ｓ３１）。この比較は、一般的な文書の差分を抽出する処理（例えばUNIX（登録商標）で一般的に用いられているコマンド「diff」を用いて実現できる）でよい。そして編集の結果、新たなリンクが含められたか否かを調べる（Ｓ３２）。これは「diff」の処理の結果、Ａタグが新たに記述されたか否かを調べる。ここで新たなリンクが入った場合は（「Ｙ」の場合は）、編集を行った利用者が、当該新たなリンク先（参照先）にアクセス可能か否かを調べる（Ｓ３３）。
【０１１２】
ここでアクセス可能か否かを調べる処理は、図６における処理Ｓ１４と同様の処理で実現できる。すなわち、利用者が過去に当該新たなリンク先となったリソースに対して上位のリソースにアクセスしたことがあるか否かを調べる処理で実現できる。
【０１１３】
次にＣＰＵ１１は、情報要素ネットワークの非循環性を維持するため、当該新たに記述されたリンク先から参照関係を辿って（Ｓ３４）、処理Ｓ２５で編集の対象となったリソースまで辿ることができるか否か、つまり参照関係が循環参照の関係になっているか否かを調べる（Ｓ３５）。ここで、循環参照の関係になっていない場合（「Ｎ」の場合）、図７の処理Ｓ２５で行われた編集後の状態でのリソースを磁気ディスク１９に格納する（Ｓ３６）。そしてＣＰＵ１１は、そのリソースが新たに生成されたものであるか否かを判断して、新たに生成されたものである場合は、リンク先となったリソースを、磁気ディスク１９内の情報要素ネットワーク上に保持させる。
【０１１４】
また、処理Ｓ３３において、新規のリンク先にアクセスできないと判断される場合（「Ｎ」の場合）や、処理Ｓ３５において循環参照の関係になっている場合（「Ｙ」の場合）は、当該リンクの記述を削除して（Ｓ３７）、処理を終了する。ここでリンクの記述の削除は、Ａタグのみを削除してもよいし、記述全体を削除してもよい。すなわち、「<a href="Pn">Pn</a>」なるリンク先Ｐｎに利用者がアクセスできない場合、又はリンク先Ｐｎが、編集中のリソースの上位に位置してしまう場合には、「<a href="Pn">」と「</a>」とを削除して、「Pn」のみを残してもよいし、「<a href="Pn">Pn</a>」全体を削除してもよい。
【０１１５】
また、処理Ｓ３２において、リンクが入っていない場合（「Ｎ」の場合）、ＣＰＵ１１は、そのまま処理Ｓ３６に移行する。
【０１１６】
［要求名createに対する処理］
次に、要求名createに対する処理について図９を参照しながら説明する。ＣＰＵ１１はまず、指定されたリソースに対して利用者がアクセス可能か否かを調べる（Ｓ４１）。この処理もまた、図６に示した処理Ｓ１４における判断と同様の処理で実現できる。そしてこの処理Ｓ４１において、アクセス可能と判断されると（「Ｙ」であると）、ノード名の入力欄のフォームを含むＨＴＭＬ記述をエンティティボディとするＨＴＴＰレスポンスをクライアント装置２側に送信する（Ｓ４２）。ここでノード名の入力欄には、予め指定されたリソースに対応する入力名を含めておいてもよい。また、ここではこの入力欄は、編集可能としておき、利用者が任意に記述できるようにしておく。
【０１１７】
そしてクライアント装置２側でノード名を含むＨＴＴＰリクエスト（createに対するコミットの指示）が行われると、当該ＨＴＴＰリクエストに含まれるノード名に対して利用者がアクセス可能か否かが調べられる（Ｓ４３）。この処理Ｓ４３における処理は、コミット処理におけるアクセス権の確認処理であるが、ここでは処理Ｓ４１におけるものと同様である。
【０１１８】
またここで指定したノード名が既に利用されており、かつ、利用者が当該ノード名で特定されるリソースへのアクセス権がない場合は、別のリソース名を指定させる処理を行ってもよい。またここで指定したノード名が既に利用されており、かつ、利用者が当該ノード名で特定されるリソースへのアクセス権がある場合は、当該既存のノード名で特定されるリソースを利用者に閲覧させる。
【０１１９】
そして、アクセス権があると判断されれば、指定されたノード名で特定されるノードへのリンクを含むリソースを作成して（Ｓ４４）、当該作成したリソースを磁気ディスク１９内の情報要素ネットワークに格納する。すなわちこの処理は、指定されたリソースの直近の上位に位置する新たなリソースを生成する処理である。
【０１２０】
ＣＰＵ４１は、そして当該作成したリソースであるノードに対応するハッシュ値を演算して図４に示したデータベースに新たに追記するとともに、処理Ｓ４１の過程で取得したクライアント側のアクセス履歴に対し、当該生成したリソースのノード名と当該生成したリソースの内容に基づくハッシュ値とを関連づけたエントリーを追記して、新たなアクセス履歴の情報を生成する（Ｓ４５）。そしてＣＰＵ１１は、処理Ｓ４５で生成したアクセス履歴の情報を、クライアント装置２へ送信してクライアント装置２に保持させる（Ｓ４６）。この処理Ｓ４６における処理も、ＨＴＴＰレスポンスヘッダのSet-Cookie/Set-Cookie2フィールドで指定することで行うことができる。このときも、セキュアの指定が行われ、クッキーは暗号化されて送信される。
【０１２１】
また、このＨＴＴＰレスポンスにおいては、新たに生成したリソースの閲覧を指定するLocationフィールドが設定され、エンティティボディは空としておく。
【０１２２】
ＣＰＵ１１は、これによりクライアント装置２側のアクセス履歴の情報を更新して処理を終了する。または、新たに生成されたリソースの閲覧へリダイレクトしてもよい。
【０１２３】
また処理Ｓ４１、Ｓ４３において利用者が指定されたリソースにアクセス可能でないと判断された場合（「Ｎ」の場合）、要求に応じられない旨の情報をクライアント装置２に送信して利用者に報知する（Ｓ４７）。この報知は、例えばレスポンス列のステータスコードとしてエラーのコードを送信することによって行うことができる。この場合、クライアント装置２がそのウエブクライアントの画面に「401 Unauthorised」のような表示を行うことになる。
【０１２４】
なお、処理Ｓ４３においては、再度新しいノード名を入力させるフォームを送信するようにしてもよい。
【０１２５】
［要求名informに対する処理］
ここまでに説明した通り、本実施の形態のウエブサーバ装置１００は、クライアント装置２が過去にアクセスをしたリソースの情報に基づいて、要求されたリソースへのアクセス可否を判断するものである。ここでは、リソースである情報要素をノードとして、非循環有向グラフ状の情報要素ネットワークを形成して磁気ディスク１９に保持しておき、リソースを指定して、当該指定したリソースへのアクセスが要求されたときに、当該指定されたリソースに対して上記情報要素ネットワークの上位に位置するリソースのいずれかに、利用者が過去にアクセスしたか否かによって指定されたリソースへのアクセス可否が判断されることになる。
【０１２６】
従って、このウエブサーバ装置１００に対して初めてアクセスする利用者は、過去にアクセスしたリソースはないので、それより下位のリソースも存在せず、どのリソースにもアクセスできないという状況が生じてしまう（但、公開リソースの下位にはアクセス可能ではある）。
【０１２７】
このためリソースへのアクセスを可能とするため、いずれかのリソースに対して初回にアクセスする際に、上位へのアクセスの有無などを判断しないような例外的処理を実装しておかなければならない。
【０１２８】
本実施の形態においては、このために要求名「inform」なる処理を実装している。以下、この要求名informに対する処理について、図１０を参照しながら説明する。
【０１２９】
この処理ではＣＰＵ１１は、まず、指定されたリソース（informの対象となるリソース）に対して要求を行った利用者がアクセス可能か否かを調べる（Ｓ５１）。この処理もまた、図６に示した処理Ｓ１４における処理と同様の処理として実現できる。
【０１３０】
この処理Ｓ５１において、アクセス可能と判断されたときには（「Ｙ」のときには）、指定したリソースに対する特殊形の表現を生成する（Ｓ５２）。ここで特殊形の表現とは、予め定められた条件に合致する表現であり、例えば乱数発生された特定バイト列であって、かつメモリ１４に格納されているバイト列であるとの条件とすることができる。
【０１３１】
つまり、処理Ｓ５２では、バイト列を乱数発生させ、指定したリソース名と当該乱数発生させたバイト列とを関連づけてメモリ１４に格納する。そして、ＣＰＵ１１は、予め指定された送信先となっている利用者のクライアント装置２に対してこの生成した表現を含む文字列を送信して（Ｓ５３）、処理を終了する。この送信は、電子メールによる送信（ＳＭＴＰサーバを用いた送信）であってよい。ＳＭＴＰサーバによる送信については、広く知られているので、ここで改めて説明することはしない。
【０１３２】
また、処理Ｓ５１において、アクセスが可能でないと判断されたときには（「Ｎ」のときには）、そのまま処理を終了する。
【０１３３】
例えばリソース「Ｐ５」に対して、乱数発生させたバイト列が「86d49110ad48a5dfc650445897309ac1609e8056」であるとするとき、「http://server/86d49110ad48a5dfc650445897309ac1609e8056」といった文字列が送信先の利用者に送信され、乱数発生させたバイト列「86d49110ad48a5dfc650445897309ac1609e8056」と、リソース名「Ｐ５」とを関連づけてメモリ１４に格納する。
【０１３４】
そして、この文字列「http://server/86d49110ad48a5dfc650445897309ac1609e8056」がクライアント装置２から受け入れられたときに、ＣＰＵ１１は（クエリが付加されていないので）、参照の要求として扱い、図６に示した処理を開始し、処理Ｓ１１において、指定されたリソースの表現「http://server/86d49110ad48a5dfc650445897309ac1609e8056」が特殊形の表現か否かを調べるため、ＣＰＵ１１は、メモリ１４にこのリソースの指定の文字列部分、「86d49110ad48a5dfc650445897309ac1609e8056」がメモリ１４に格納されているか否かを調べる。ここでは、メモリ１４にバイト列「86d49110ad48a5dfc650445897309ac1609e8056」と、リソース名「Ｐ５」とが関連づけて格納されているので、ＣＰＵ１１は、これが特殊形の表現であると判断して、処理Ｓ１５に移行し、対応するリソース「Ｐ５」の内容が当該「http://server/86d49110ad48a5dfc650445897309ac1609e8056」への要求を行ったクライアント装置２に対して提供される。このとき、メモリ１４に格納されている、「86d49110ad48a5dfc650445897309ac1609e8056」とそれに対応するリソース名とは削除しておくこととしてもよい。この処理によって、上記特殊形の表現を受取った利用者は、当該表現に関連づけられたリソースへアクセスを行ったとのアクセス履歴を取得することになる。
【０１３５】
なお、ここでは乱数生成を利用しているが、リソースの内容のハッシュ値を乱数の代りに利用してもよい。この場合、内容のハッシュ値にはリンク元を関連づけておき、リンク元を辿ってルートを特定できるようにしておき、このルートのヘッダ情報にリソース名を含めるようにしておくことで、内容のハッシュ値からリソース名を取り出すことができるようにしておけばよい。
【０１３６】
［他の利用者にリソースをアクセスさせるための他の方法］
ここで他の利用者にリソースへのアクセスをさせるためにインフォーム（inform）の要求を行う例について述べたが、本実施の形態の参照関係を利用しても、他の利用者へ、当該利用者が過去にアクセスしたことのあるリソースから下位のネットワークに属していない、リソースへアクセスをさせることができる場合がある。
【０１３７】
これは例えば、図２に示したネットワークにおいて、ある利用者Ａが、他の利用者Ｂに対してノードＰ６に対応するリソースへアクセスさせたいと考えたとき、「当該他の利用者ＢがリソースＰ２にアクセス可能であること」を利用者Ａが知っていれば、このリソースＰ２に対してエディット（edit）を要求して、リソースＰ６へのリンクを追記してしまえばよい。
【０１３８】
これにより、リソースＰ２にアクセスしたことのある利用者Ｂは、リソースＰ６へのアクセス権を獲得できることになる。
【０１３９】
［変形例］
また、本実施の形態においては、各要求名に係る処理において、当該各要求の対象として指定されたリソースへのアクセスの可否を略同一の処理によって判断していたので、例えば閲覧は可能であるが、編集は不可能である、といったようなアクセス権を設定することができなかった。そこで、受け入れるアクセスの種別ごとに、それぞれに関連した情報要素を磁気ディスク１９内に格納しておき、これらの情報要素に対して利用者が過去にアクセスしたことがあるか否かによって、当該情報要素に関連した種別のアクセスを許可するようにしてもよい。
【０１４０】
例えば、生成（create）に関する情報要素として、リソース「create.html」をディスク装置１９内に格納しておくとともに、編集（edit）に関する情報要素として、リソース「edit.html」をディスク装置１９内に格納しておく。そしてある利用者Ａには、リソース「create.html」と、リソース「edit.html」との双方に（例えば上記特殊形の表現を用いて）アクセスさせておく。すると、当該利用者Ａが利用しているクライアント装置２には、当該リソース「create.html」と、リソース「edit.html」との双方に関連するアクセス履歴が記録されることになる。
【０１４１】
一方、利用者Ｂには、リソース「edit.html」のみに（例えば上記特殊形の表現を用いて）アクセスさせておく。すると、この利用者Ｂの利用しているクライアント装置２には、当該リソース「edit.html」を含み、リソース「create.html」を含まない連想配列に関連づけられたハッシュ値がアクセス履歴として記録されることになる。
【０１４２】
そしてＣＰＵ１１は、要求名「edit」に対応する処理においては、図７に示したその処理Ｓ２４において、利用者のアクセス履歴に、指定したリソースの上位に属するリソースが含まれ（この判断処理は図６に示した処理Ｓ１４と同じである）、かつリソース「edit.html」へのアクセス履歴が含まれるときに、指定したリソースへのアクセス（この場合は編集のためのアクセス）が可能であると判断して、処理Ｓ２５以下の処理に移行する。
【０１４３】
同様に、要求名「create」に対応する処理においても、図９に示したその処理Ｓ４１において、利用者のアクセス履歴に、指定したリソースの上位に属するリソースが含まれ（この判断処理は図６に示した処理Ｓ１４と同じである）、かつリソース「create.html」へのアクセス履歴が含まれるときに、指定したリソースへのアクセス（この場合は編集のためのアクセス）が可能であると判断して、処理Ｓ４２以下の処理に移行する。
【０１４４】
従って、上記の例でいう利用者Ａ，Ｂについては、要求名「edit」に対応する処理では、双方の利用者にそのアクセス履歴が含まれているので、どちらの利用者も指定したリソースを編集することができる。しかし、要求名「create」に対応する処理では、利用者Ａについては、その利用するクライアント装置２が、「create.html」へのアクセス履歴を保持しているので、指定したリソースの直接上位に新たなリソースを生成できる。しかし、利用者Ｂについては、その利用するクライアント装置２が保持しているアクセス履歴に、「create.html」へのアクセスが含まれていないので、指定したリソースの直接上位に新たなリソースを生成することができず、要求に応じられない旨が報知されることになる（処理Ｓ４７）。
【０１４５】
これにより、アクセスの制御を要求の内容ごとに行うことができるようになる。またこの場合は、例えば、要求名editに対するアクセスができない場合であっても、要求名viewに対するアクセスが可能であるときには、要求名editによるアクセス要求があった場合、その要求に係るリソースについて、要求名viewによるアクセス要求を行わせるようにしてもよい。これは例えば、ロケーションフィールドにおいて要求名を変更した後のＵＲＩを記述し、エンティティボディを空などとした文書を提供し、クライアント装置２に対して要求名viewによるアクセスを行わせるよう案内してもよい。この場合、例えば各要求名に選択順位を付しておき、特定の要求名に対するアクセスができない場合、選択順位順にアクセスの可能性を調べ、アクセスが可能な要求名があれば、当該選択順位順に最初に見いだされた要求名でアクセスさせるようにしてもよい。
【０１４６】
なお、このようにした場合は、例えば編集の要求（edit）等の処理において、当初のアクセス権確認は要求名viewに対する処理と同じとしておき、コミット処理におけるアクセス権の確認において対応する要求名へのアクセス権の確認を行うようにしてもよい。
【０１４７】
例えば、編集の要求があったときに、閲覧（view）のアクセス権があれば編集用のフォームが提供され、当該フォームが送信されたコミットの段階で編集（edit）のアクセス権が確認される。
【０１４８】
［第２実施形態］
さらに、リソースごとに要求名ごとのアクセス権設定を可能とする、本発明の第２の実施の形態に係るウエブサーバ装置について説明する。本実施の形態に係るウエブサーバ装置は、第１の実施形態に係るウエブサーバ装置と同様の構成を採るものであるが、ＣＰＵ１１の処理の内容が異なり、磁気ディスク１９にさらに別のテーブルが格納されることとなるので、以下、この相違点について説明する。
【０１４９】
本実施の形態では磁気ディスク１９に、図１１に示すように、リソースごとに、各要求名に関するアクセス権を規定するリソースを定義したテーブルを格納している。なお、ここではアクセス許可条件の変更のための要求名「qualify」が新たに付加されている。この要求名に対する処理については後に説明する。
【０１５０】
ＣＰＵ１１は、閲覧（view）、編集（edit）、生成（create）、インフォーム（inform）の各要求名に関する処理としてそれぞれ、図６、図７、図９、図１０に示した処理を基本的に行うのであるが、図７における処理Ｓ２４、図９における処理Ｓ４１、図１０における処理Ｓ５１の内容が異なる。
【０１５１】
すなわちＣＰＵ１１は、例えばリソースＰ１に対して要求名「edit」のリクエストを受けたときに、editに対する処理を開始し、図７に示した処理Ｓ２４において、リソースＰ１と要求名「edit」とに対応して図１１に示したテーブルに定義されたリソース名「Ｐｘ」を取得し、利用者のアクセス履歴に含まれるノード名のリストに、指定したリソースの上位に属するリソースが含まれ（この判断処理は図６に示した処理Ｓ１４と同じである）、かつここで取得したリソース名「Ｐｘ」にアクセス可能であるとき（この判断処理は、リソース名「Ｐｘ」を指定されたリソースとした場合の処理Ｓ１４と同様の処理であるので、リソース名「Ｐｘ」より上位のリソースについてのノード名がアクセス履歴に含まれる場合）、指定したリソースへのアクセス（この場合は編集のためのアクセス）が可能であると判断して、処理Ｓ２５以下の処理に移行する。生成（create）、インフォーム（inform）についても同様に、アクセスの可否の判断の際に図１１に示したテーブルが参照され、当該テーブル上で、指示されたリソースと要求名とに関連づけられているリソースが、「利用者が過去にアクセスしたことがあるか、又は過去にアクセスした別のリソースの下位に属している場合」であって、かつ、「指定されたリソースに過去にアクセスしたことがあるか又は過去にアクセスしたことのあるリソースの下位に当該指定されたリソースが属している場合」に、指定されたリソースに対する、指定された要求名のアクセスが可能であると判断されることになる。
【０１５２】
［edit、createにより、新たなリソースが生成される場合の処理］
要求名editや、createにより、指定されたリソースからリンクされる新たなリソース（直接下位のリソース）や、指定されたリソースへのリンクを含む新たなリソース（直接上位のリソース）が生成される場合には、図１１に、当該リソースに対するエントリーが追加されることになる。
【０１５３】
この追加されるエントリーは、要求名editにより指定されたリソースの直接下位のリソースが生成される場合には、当該指定されたリソースと同じ設定となる。例えば図１１に示しているリソースＰ１に対して直接下位のリソースを生成した場合、当該生成したリソースに対するエントリーでは、editに対して「Ｐｘ」、createに対して「Ｐｙ」、informに対して「Ｐｚ」、qualifyに対して「Ｐｗ」が設定されているようになる。
【０１５４】
また、この追加されるエントリーは、要求名createにより指定されたリソースの直接上位のリソースが生成される場合には、「qualify」を除く要求名に対応するものについては、当該指定されたリソースと同じ設定となる。例えば図１１に示しているリソースＰ１に対して直接上位のリソース「Ｐｑ」を生成した場合、当該生成したリソースに対するエントリーでは、editに対して「Ｐｘ」、createに対して「Ｐｙ」、informに対して「Ｐｚ」、qualifyに対して「Ｐｑ」，つまり自分自身，が設定されているようになる。
【０１５５】
［要求名qualifyに対する処理］
この図１１に示したアクセスコントロールのリストを編集する要求がクオリファイ（qualify）として定められる。
【０１５６】
そこで次に、この要求名qualifyに対する処理について説明する。ＣＰＵ１１はまず、利用者が、指定されたリソースについて、要求名qualifyのアクセスを行うことができるか否かを調べる。具体的に図１１に示した設定のときに、リソースＰ１に関するエントリーを変更する場合、Ｐ１と、要求名qualifyとに関連づけられているリソース名「Ｐｗ」を取得し、要求をした利用者が「上記取得したリソース名「Ｐｗ」自体、又は当該「Ｐｗ」より上位のリソースにアクセスしたことがある」場合に、リソースＰ１に対する各要求名に関連づける値を変更できるようになる。なお、ここではリソース名を関連づけているが、リソース名に代えて当該リソース名から演算されるハッシュ値を関連づけてもよい。
【０１５７】
［その他の変形例］
なお、本発明はここまでの第１、第２の実施の形態で説明した態様に限られるものではない。例えば、ここでは磁気ディスク１９内に、各テーブルを実現するデータベースや情報要素ネットワークを形成していたが、これらはネットワーク３を介して通信可能となっている他のサーバ装置内のディスク装置等に形成されてもよい。
【０１５９】
また、これら第１、第２の実施の形態で説明した処理の内容を用いれば、上述のようにウエブサーバ装置として構成するだけでなく、ファイルシステムとしての適用も可能である。
【図面の簡単な説明】
【０１６０】
【図１】本発明の実施の形態に係るウエブサーバ装置と、そのネットワークへの接続状態の例を表す構成ブロック図である。
【図２】非循環有向グラフ状の情報要素ネットワークの例を表す説明図である。
【図３】非循環有向グラフ状の情報要素ネットワークをＨＴＭＬの記述により実現する例を表す説明図である。
【図４】情報要素へのアクセス可否を判断する際に参照されるテーブルの例を表す説明図である。
【図５】情報要素へのアクセス可否を判断する際に参照される、もう一つのテーブルの例を表す説明図である。
【図６】本発明の実施の形態に係るウエブサーバ装置による閲覧の処理の例を表すフローチャート図である。
【図７】本発明の実施の形態に係るウエブサーバ装置による編集の処理の例を表すフローチャート図である。
【図８】本発明の実施の形態に係るウエブサーバ装置によるコミットの処理の例を表すフローチャート図である。
【図９】本発明の実施の形態に係るウエブサーバ装置による生成の処理の例を表すフローチャート図である。
【図１０】本発明の実施の形態に係るウエブサーバ装置によるインフォームの処理の例を表すフローチャート図である。
【図１１】情報要素へのアクセス可否を判断する際に参照される、さらに別のテーブルの例を表す説明図である。
【図１２】ウエブサーバ装置を含む従来一般的なネットワークシステムの例を表す説明図である。
【図１３】従来一般的なアクセス管理のテーブル例を表す説明図である。
【符号の説明】
【０１６１】
１，１００  ウエブサーバ装置、２  クライアント装置、３  ネットワーク、１１  ＣＰＵ、１２  システムコントローラ、１３  スイッチ、１４  メモリ、１５  バスインタフェース、１６  マウス、１７  キーボード、１８  バス、１９  磁気ディスク、２０  ネットワークインタフェース、２１  表示制御部、３０  ディスプレイ。
【図１】
0004729844.tif 000002
【図２】
0004729844.tif 000003
【図３】
0004729844.tif 000004
【図４】
0004729844.tif 000005
【図５】
0004729844.tif 000006
【図６】
0004729844.tif 000007
【図７】
0004729844.tif 000008
【図８】
0004729844.tif 000009
【図９】
0004729844.tif 000010
【図１０】
0004729844.tif 000011
【図１１】
0004729844.tif 000012
【図１２】
0004729844.tif 000013
【図１３】
0004729844.tif 000014