(57)【特許請求の範囲】
【請求項１】
複数の要素を含む文書構造を有する複数の構造化文書を記憶するとともに、ルートノードに、１または複数のノードを介して、各構造化文書に含まれる各要素の記憶エリアを当該構造化文書の文書構造に従ってリンクした論理構造により、前記複数の構造化文書を管理する構造化文書データベースを、前記論理構造中の検索位置を示すパス情報と、当該検索位置から検索された要素を検索結果文書中の要素として出力するための要素を含む当該検索結果文書の文書構造を定めた記述部とを含む検索要求文を基に検索する第１の検索ステップと、
検索した結果得られる前記検索結果文書を、当該検索結果文書中の要素を表示用文書中の表示要素として出力するための出力命令と、当該出力命令の処理対象となる前記検索結果文書中の要素の位置情報とを含むスタイル文書を用いて、前記表示用文書に変換する変換ステップと、
前記スタイル文書中の各出力命令と、当該出力命令により生成された前記表示用文書中の表示要素との対応関係を示すテーブルを記憶手段に記憶するステップと、
前記表示用文書を表示画面に表示するステップと、
前記表示画面に表示された前記表示用文書中の表示要素の表示領域が指定されたとき、前記テーブルを参照して、当該表示要素に対応付けられている出力命令を検出する第１の検出ステップと、
前記検索結果文書から、検出された出力命令の処理対象である第１の要素を検出する第２の検出ステップと、
前記検索要求文中の前記パス情報により特定される前記論理構造中の検索位置から、前記第１の要素の要素値を値としてもつ第２の要素の位置を示すパス情報を検索する第２の検索ステップと、
検索した結果得られたパス情報により特定される前記論理構造上の前記第２の要素に対して、アクセス可能なユーザの範囲を定めたアクセス権限を設定する第１の設定ステップと、
を含むアクセス権限設定方法。
【請求項２】
前記第２の検出ステップで検出された前記スタイル文書中の出力命令に対し、アクセス可能なユーザの範囲を定めたアクセス権限を設定する第２の設定ステップをさらに含む請求項１記載のアクセス権限設定方法。
【請求項３】
前記検索要求文から、前記検索結果文書中の前記第１の要素を出力する第３の要素を検出する第３の検出ステップと、
前記検索要求文中の前記第３の要素に対し、アクセス可能なユーザの範囲を定めたアクセス権限を設定する第３の設定ステップと、
をさらに含む請求項１記載のアクセス権限設定方法。
【請求項４】
前記構造化文書データベースに記憶されている構造化文書のうち、前記第２の要素を含む構造化文書と同じ文書構造を持つ構造化文書中の前記第２の要素と同じ要素名の要素に対して、アクセス可能なユーザの範囲を定めたアクセス権限を設定する第４の設定ステップをさらに含む請求項１記載のアクセス権限設定方法。
【請求項５】
前記第４の設定ステップは、前記第２の要素を含む構造化文書と同じ文書構造を持つ複数の構造化文書が記憶されている前記論理構造上の記憶エリアに、当該記憶エリア内に格納される構造化文書が従うべき文書構造を定義した文書構造定義文書が存在するときは、当該文書構造定義文書中の前記第２の要素と同じ要素名の要素に、前記アクセス権限を設定することを特徴とする請求項４記載のアクセス権限設定方法。
【請求項６】
複数の要素を含む文書構造を有する複数の構造化文書を記憶するとともに、ルートノードに、１または複数のノードを介して、各構造化文書に含まれる各要素の記憶エリアを当該構造化文書の文書構造に従ってリンクした論理構造により、前記複数の構造化文書を管理する構造化文書データベースと、
前記論理構造中の検索位置を示すパス情報と、当該検索位置から検索された要素を検索結果文書中の要素として出力するための要素を含む当該検索結果文書の文書構造を定めた記述部とを含む検索要求文を基に、構造化文書データベースを検索する第１の検索手段と
前記第１の検索手段で検索した結果得られる前記検索結果文書を、当該検索結果文書中の要素を表示用文書中の表示要素として出力するための出力命令と、当該出力命令の処理対象となる前記検索結果文書中の要素の位置情報とを含むスタイル文書を用いて、前記表示用文書に変換する変換手段と、
前記スタイル文書中の各出力命令と、当該出力命令により生成された前記表示用文書中の表示要素との対応関係を示すテーブルを記憶する記憶手段と、
前記表示用文書を表示画面に表示する表示手段と、
前記表示画面に表示された前記表示用文書中の表示要素の表示領域が指定されたとき、前記テーブルを参照して、当該表示要素に対応付けられている出力命令を検出する第１の検出手段と、
前記検索結果文書から、検出された出力命令の処理対象である第１の要素を検出する第２の検出手段と、
前記検索要求文中の前記パス情報により特定される前記論理構造中の検索位置から、前記第１の要素の要素値を値としてもつ第２の要素の位置を示すパス情報を検索する第２の検索手段と、
検索した結果得られたパス情報により特定される前記論理構造上の前記第２の要素に対して、アクセス可能なユーザの範囲を定めたアクセス権限を設定する第１のアクセス権限設定手段と、
を含む構造化文書管理システム。
【請求項７】
前記第１の検出手段で検出された前記スタイル文書中の出力命令に対し、アクセス可能なユーザの範囲を定めたアクセス権限を設定する第２のアクセス権限設定手段をさらに含む請求項６記載の構造化文書管理システム。
【請求項８】
前記検索要求文から、前記検索結果文書中の前記第１の要素を出力する第３の要素を検出する第３の検出手段と、
前記検索要求文中の前記第３の要素に対し、アクセス可能なユーザの範囲を定めたアクセス権限を設定する第３のアクセス権限設定手段と、
をさらに含む請求項６記載の構造化文書管理システム。
【請求項９】
前記構造化文書データベースに記憶されている構造化文書のうち、前記第２の要素を含む構造化文書と同じ文書構造を持つ構造化文書中の前記第２の要素と同じ要素名の要素に対して、アクセス可能なユーザの範囲を定めたアクセス権限を設定する第４のアクセス権限設定手段をさらに含む請求項６記載の構造化文書管理システム。
【請求項１０】
前記第４のアクセス権限設定手段は、前記第２の要素を含む構造化文書と同じ文書構造を持つ複数の構造化文書が記憶されている前記論理構造上の記憶エリアに、当該記憶エリア内に格納される構造化文書が従うべき文書構造を定義した文書構造定義文書が存在するときは、当該文書構造定義文書中の前記第２の要素と同じ要素名の要素に、前記アクセス権限を設定することを特徴とする請求項９記載の構造化文書管理システム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、異なる文書構造の複数の構造化文書を、階層化された論理構造を持つ構造化文書データベースに対するアクセス権限の設定方法に関する。
【０００２】
【従来の技術】
ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）は、組織内データや、企業間の交換フォーマットの世界標準として現在注目を浴びている。これらＸＭＬで記述された文書（以下、ＸＭＬ文書と呼ぶ）に構造情報を付加することが可能であり、構造化文書と呼ばれる。これら構造化文書を格納、検索を行うためのデータベースの開発が現在進んでいる。構造化文書をデータベース化することで、データ問合せ言語（以後、クエリと呼ぶ）によって、データベースから所望の構造化文書を検索して、それらを合成した新たな構造化文書（加工された構造化文書）を生成することが可能となる。例えば、クエリによって、論文データベースと従業員データベースの内容から、１つの加工された構造化文書を作成する、といったことが可能となる。
【０００３】
構造化文書をブラウザ等に表示するためものが、ＸＳＬ（ｅＸｔｅｎｓｉｂｌｅ  Ｓｔｙｌｅｓｈｅｅｔ  Ｌａｎｇｕａｇｅ）に代表されるスタイルシートである。ＸＳＬはＷ３Ｃによって勧告になっているもので、これ自体がＸＭＬで記述されている。これは、表示を規定する言語から成り、主にパターンマッチングにより表示形式を決定するものである。
【０００４】
アプリケーションからデータベースを利用する形式としては以下の手順が一般的である。
【０００５】
▲１▼  構造化文書をデータベースに格納する
▲２▼  クエリによりこれらデータベースから所望のデータを取得する
▲３▼  スタイルによりブラウザなどの画面にこれらデータを表示させる
ここで、クエリとは格納したデータを取得する、という操作も含む。よって、データベースに格納した文書をそのまま表示させたい場合もクエリが発行されていることになる。
【０００６】
アプリケーションによっては、構造化文書の階層構造に応じてアクセス権限を設定できるようにしたいといった要求が多く発生してくる。例えば、ある構造化文書中のある１つの要素に対するアクセス権限はユーザＡ，ユーザＢで、他の１つの要素に対してはユーザＡだけである、といった文書構造に応じた指定を行いたいといったことである。
【０００７】
このようなアクセス権限の設定は、ＲＤＢのようなテーブルとレコード単位でのアクセス権限の設定でなく、木構造に対するアクセス権限の設定となり、そのための手法が幾つか提案されている。
【０００８】
例えば、階層構造に応じたアクセス権限の設定方法として、ＰＨ０７−４４５７９がある。これは、構造化文書の階層構造ごとにアクセス権限を設定可能とするもので、アクセス権限の継承等も可能とするものである。いわばオブジェクト指向型データに対するアクセス権限に近い実現方法を示している。アクセス権限の設定は文書に対して行うことから、格納されている文書全てに対してアクセス権限を設定しなければならない。ＸＭＬはスキーマがない場合も許容されるので、スキーマに対してアクセス権限を設定するという場合だけでは不十分である。よって、膨大な数の文書それぞれにアクセス権限を設定するのは非常に手間が掛かる作業である。また、これは、ＸＭＬ文書に対して直接アクセス権限を設定するものであるが、ＸＭＬ文書はあくまでデータであり、このデータをどのように使うかはアプリケーション側に依存する場合が多い。
【０００９】
アプリケーションによっては、同じアクセス権限を持つユーザでも、ある画面ではある要素に対する表示を認めず、ある画面では表示を許す、などといった設定を行いたいという要求がある。また、アクセス権限は同じでも、ＸＭＬ文書そのものの表示は認めないが、クエリによる集計結果として加工された場合には表示は可能とするといった設定を行いたい場合もあるであろう。つまり、格納されているＸＭＬ文書というよりは、前者は表示に対するアクセス権限、後者はクエリに対するアクセス権限の設定である。
【００１０】
このように、アプリケーション側にとっては、表示形式（スタイル）によって表示されたデータに対する権限をアクセス権限とする場合が多い。スタイルごとにアクセス権限を設定しようとしているものとして、Ｐ２００１−２２７４９がある。これは、単に、ユーザＩＤとスタイルＩＤを関連付けて管理し、ユーザ毎にアクセス可能なスタイルを指定するものであり、ＸＭＬ文書そのものが持つ文書構造は全く考慮していない。
【００１１】
また、ＰＨ１１−２５０７６においては、構造化文書のアクセス権限設定において、表示部とデータ管理部を別に管理し、ユーザに対してアクセス権限のある情報だけを提示し、更新を行いたい場合にはその部分だけの更新を許す構成をとっている。しかし、これも文書毎にアクセス権限を設定しなければならず、やはり設定に対する負荷に関する問題が残る。
【００１２】
ＲＤＢのようにスキーマが必須の場合は、そのスキーマにアクセス権限を設定することなども考えられるが、ＸＭＬはスキーマはあっても良いし、なくても良い、などといった特徴や、同じ名前を持つ要素が同一レベルに複数存在しても良い、などといった特徴があり、構造が曖昧になる場合が多い。これらを考えると、構造化文書の構成要素毎にアクセス権限を設定する必要性がある。
【００１３】
また、実際にアクセス権限を設定するのは、アプリケーションレベルになってからであり、データを作成した段階ではない場合が多い。例えば、同じデータを用いたとしても、ある用途（検索条件）あるいはスタイル（表示形式）では、ユーザＡにはある要素ｘに対してアクセス権限を与えるが、別のある用途あるいはスタイル（表示形式）ではアクセス権限を無くすといった柔軟な処理を行うことも十分考えられる。つまり、アプリケーション作成の段階になってアクセス権限を設定することが多く、その段階でアクセス権限の設定が容易に行えるような機能が必要となってくる。
【００１４】
さらに、アプリケーション面から捕らえた場合、スタイルごと、或いは、用途ごとにアクセス権限を設定できる機能が望まれる。例えば、スタイルに関していえば、ユーザＡに対しては、ある要素ｘのグラフを見せるが、ユーザＢに対しては、グラフ表示は不可能で、例えばモザイクをかけて表示する、などといった制限などである。ただ、ユーザＢはグラフとしての表示は不可能であるが、ＸＭＬデータとしてその値を取得することは可能、などといった場合もある。また、クエリによって集計された結果はアクセスできるが、それ以外の個々の文書にはアクセスできない、といったアクセス権限を設定する場合も考えられる。これらは、データベースに格納されている文書に対してのみアクセス権限を持たせる方法では実現できない。
【００１５】
【発明が解決しようとする課題】
以上説明したように、従来からある構造化文書へのアクセス権限の設定方法は、アクセス権限を構造化文書の構成要素毎に設定することは可能であるが、その設定に手間がかかるという問題点があった。特に、論理空間を有する構造化文書データベースにおける膨大な量の構造化文書に対して、その個々の構成要素に対してアクセス権限を設定する手間とコストは相当大きなものとなる。
【００１６】
また、構造化文書データベースに格納されている構造化文書の構成要素にアクセス権限を設定するだけでなく、表示形式や用途に応じて（すなわち、スタイルシートやクエリに応じて）、構造化文書の構成要素に対し、異なるアクセス権限を設定するといったきめ細かなアクセス権限の設定が行えないという問題点があった。
【００１７】
そこで、本発明は、上記問題点に鑑み、アクセス権限を構造化文書の構成要素毎にきめ細かく設定することが容易に行えるアクセス権限設定方法および構造化文書管理装置を提供することを目的とする。
【００１８】
また、構造化文書データベースに格納されている構造化文書の構成要素の用途や表示形式（検索結果として表示する際の表示形式）に応じて、異なる内容のアクセス権限を設定することが容易に行えるアクセス権限設定方法および構造化文書管理装置を提供することを目的とする。
【００１９】
【課題を解決するための手段】
本発明は、複数の構造化文書を格納した階層化された論理構造を持つ構造化文書データベースの前記論理構造を構成する前記構造化文書の構成要素に対し、アクセス権限を設定するためのものであって、前記構造化文書データベースから前記論理構造に基づき所望の構成要素を検索するための検索要求文（クエリ）を用いて検索した結果得られた複数の構成要素からなる検索結果文書を表示した表示画面上の任意の表示領域が指定されたとき、その指定された表示領域に表示されているデータに対応する前記検索結果文書中の第１の構成要素を特定し、この第１の構成要素に関連付けられた前記検索要求文中の第２の記述部分の記述に基づき、前記構造化文書データベース中の前記第１の構成要素に対応する第２の構成要素を検索して、この第２の構成要素に対し、少なくとも該第２の構成要素にアクセスが制限されるユーザの範囲を定めてアクセス権限を設定することを特徴とする。
【００２０】
本発明によれば、ユーザは、検索結果の表示画面上で、少なくとも所望の表示領域を指定するだけで、当該指定された表示領域に表示されているデータに対応する構造化文書データベース中の所望の構成要素にアクセス権限の設定が容易に行える。
【００２１】
また、本発明は、複数の構造化文書を格納した階層化された論理構造を持つ構造化文書データベースの前記論理構造を構成する前記構造化文書の構成要素に対し、アクセス権限を設定するものであって、前記構造化文書データベースから前記論理構造に基づき所望の構成要素を検索するための検索要求文（クエリ）を用いて検索した結果得られた複数の構成要素からなる検索結果文書を表示した表示画面上の任意の表示領域が指定されたとき、この指定された表示領域に表示されているデータに関連付けられた、前記検索結果文書を所定の表示形式で表示するために用いた前記検索結果文書の文書構造の変換規則（スタイルシート）中の第１の記述部分と、この第１の記述部分に関連付けられた前記検索結果文書中の第１の構成要素を抽出し、少なくとも、前記変換規則中の前記第１の記述部分にアクセス権限を設定する第１のレベル（スタイルレベル）と、前記検索要求文中の、前記第１の構成要素に対応する第２の記述部分にアクセス権限を設定する第２のレベルと（クエリレベル）、前記第２の記述部分に関連付けられた前記検索要求文中の第３の記述部分の記述に基づき特定される前記構造化文書データベース中の前記第１の構成要素に対応する第２の構成要素にアクセス権限を設定する第３のレベル（データレベル）を含む複数のレベルのうち、ユーザにより指定されたレベルに、少なくとも、そのレベルについてアクセスが制限されるユーザの範囲を定めてアクセス権限を設定することを特徴とする。
【００２２】
本発明によれば、ユーザにより所望の表示領域が指定されると、ユーザにより指定されたレベルに応じて、該指定された表示領域に対応するスタイルシートの記述部分、さらに、それに関連付けられた検索結果文書中の構成要素、さらに、それに対応するクエリ中の記述部分、さらにそれに関連付けられた構造化文書データベース中の要素と、順次特定していくことにより、指定されたレベルにアクセス権限を設定することが容易に行える。ユーザは、検索結果の表示画面上で、少なくとも所望の表示領域と、アクセスレベルを指定するだけで、構造化文書データベース中の構成要素にアクセス権限の設定が行える。
【００２３】
アクセス権限をスタイルシート、クエリといったレベルに設定することにより、あるスタイルシートを用いていたときには表示されなかったデータが他の異なるスタイルシートを用いれば表示される、あるクエリを用いた検索結果では表示されなかったデータが他の異なるクエリを用いたときには表示されるといった、柔軟なアクセス権限の設定が可能になる。また、アクセス権限をあるクエリレベルで設定すると、このクエリに用いた結果得られた検索結果文書を表示するためにどのスタイルシートに利用しても、このアクセス権限が適用される。また、アクセス権限をデータレベルで設定すると、このアクセス権限の設定された構成要素を利用するためにどのクエリ、どのスタイルシートを用いても、このアクセス権限が適用される。
【００２４】
クエリレベルでアクセス権限を設定すると、構造化文書データベース中の構成要素に対し、その用途に応じてアクセス権限を設定することができる。また、スタイルレベルでアクセス権限を設定すると、構造化文書データベース中の構成要素に対し、その表示形式に応じてアクセス権限を設定することができる。
【００２５】
さらに、前記複数のレベルは、前記構造化文書データベースに格納されている前記第２の構成要素を含む構造化文書と同じ文書構造を持つ他の構造化文書に含まれる前記第２の構成要素の要素名と同じである全ての構成要素にアクセス権限を設定する第４のレベルを含むことにより、スタイルシートの記述部分、クエリ中の記述部分、構造化文書データベース中の前記第２の構成要素の他に、さらに、当該第２の構成要素を含む構造化文書と同じ文書構造を持つ他の構造化文書中の当該第２の構成要素と同じ要素名の要素に対しても、それ対応のレベル（第４のレベル）を指定するだけで一括してアクセス権限を容易に設定することができる。
【００２６】
特に、ユーザにより前記第４のレベルが指定されたとき、前記第２の構成要素を含む構造化文書と同じ文書構造を持つ複数の構造化文書が格納されている前記論理構造に従って指定される前記構造化データベースの論理的なエリアに、そのエリア内に格納される構造化文書が従うべき文書構造を定義した文書構造定義文書（スキーマ）が存在するときは、当該文書構造定義文書中の前記第２の構成要素と同じ要素名の構成要素に関する記述部分に、前記第２の構成要素と同じ要素名の構成要素に対する前記アクセス権限を設定するようにしてもよい。
【００２７】
さらに、前記変換規則（スタイルシート）は、前記検索結果文書を該検索結果文書の各構成要素の少なくとも要素値をそれぞれ１つの表示領域で表示する表示用文書（ＨＴＭＬ文書）に変換するためのものであって、前記変換規則を用いて前記検索結果文書を表示用文書に変換する際には、該表示用文書の記述部分と、該記述部分に関連する前記変換規則中の記述部分との対応関係を抽出し、前記表示画面上の任意の表示領域が指定されたとき、該指定された表示領域に表示されているデータに対応する前記表示用文書中の第４の記述部分に対応する前記変換規則中の前記第１の記述部分を前記対応関係に基づき抽出することにより、指定された表示領域に表示されているデータに関連付けられた変換規則中の第１の記述部分が容易に抽出できる。
【００２８】
【発明の実施形態】
以下、本発明の実施形態について図面を参照して説明する。
【００２９】
構造化文書として、ＸＭＬやＳＧＭＬなどで記述した文書が挙げられる。ＳＧＭＬ（Ｓｔａｎｄａｒｄ  Ｇｅｎｅｒａｌｉｚｅｄ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）とは、ＩＳＯ（国際標準化機構）で定められた規格である。ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）とは、Ｗ３Ｃ（Ｗｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂ  Ｃｏｎｓｏｒｔｉｕｍ）にて定められた規格である。それぞれ文書を構造化することを可能とする構造化文書規約である。
【００３０】
以下、構造化文書として、ＸＭＬにて記述された文書を例に説明を進める。構造化文書の文書構造を定義したデータ（文書構造定義データ）をスキーマと呼ぶ。ＸＭＬではそのスキーマを定義するためにＸＭＬ−ＳｃｈｅｍａやＸＤＲ（ＸＭＬ  Ｄａｔａ  Ｒｅｄｕｃｅｄ）などのスキーマ言語が提案されている。ここでは、例えば、ＸＤＲでのスキーマを記述する場合を例にとり説明する。
【００３１】
スキーマも、本発明の構造化文書管理システムの管理対象の構造化文書であり、従って、スキーマ文書と呼ぶことがある。スキーマ文書と区別するために、特許明細書やメール、週報、広告などの種々雑多な内容を有す文書をコンテンツ文書と呼ぶこともある。
【００３２】
本発明の構造化文書管理システムでは、上記スキーマ文書、上記コンテンツ文書、さらに、後述するようなユーザからの検索要求内容を記述したクエリ、すなわち、クエリ文書も管理対象とし、これらを総称して「文書」と呼ぶ。
【００３３】
以下、特にことわりがない場合、「文書」と呼ぶときは、コンテンツ文書、スキーマ文書、クエリ文書を全て指すものとする。
【００３４】
まず、実施形態の説明を前に、ＸＭＬについて簡単に説明する。
【００３５】
図３は、ＸＭＬで記述された構造化文書の一例として、「特許」情報の例を示したものである。ＸＭＬやＳＧＭＬは、文書の構造の表現にタグが用いられる。タグには、開始タグと終了タグがあり、文書構造情報の構成要素を開始タグと終了タグで囲むことにより、文書中の文字列（テキスト）区切りと、そのテキストが構造上どの構成要素に属するのかを明確に記述することができる。
【００３６】
ここで開始タグとは要素名称を記号「＜」、「＞」で閉じたものであり、終了タグとは要素名称を記号「＜／」と「＞」で閉じたものである。タグに続く構成要素の内容が、テキスト（文字列）または子供の構成要素の繰り返しである。また開始タグには「＜要素名称  属性＝“属性値”＞」などのように属性情報を設定することができる。「＜特許ＤＢ＞＜／特許ＤＢ＞」のようにテキストを含まない構成要素は、簡易記法として「＜特許ＤＢ／＞」のように表わすこともできる。
【００３７】
図３に示した文書は、「特許」タグから始まる要素をルート(根)とし、その子要素として「タイトル」、「出願日」、「出願者」、「要約」タグから始まる要素集合が存在する。また、例えば、「タイトル」タグから始まる要素には「ＸＭＬデータベース」といった、１つのテキスト（文字列）が存在する。
【００３８】
ＸＭＬなどの構造化文書は、任意の構成要素を繰り返し含んでいたり、さらには文書構造があらかじめ決まっていない（ＲＤＢ（リレーショナルデータベース）やＯＯＤＢ（オブジェクト指向データベース）のスキーマでは定義できない）のが普通である。
【００３９】
図３に示したような構造化文書を論理的に表現するために、図４に示すようなツリー表現が用いられる。ツリーは、ノード（番号が付され、円形で示されたもの）とアーク（ノードを表す円形間をつなぐデータ付き線）と四角形で囲まれたテキストから構成されている。
【００４０】
ノードは文書オブジェクトに対応し、ノードからタグ名や属性名に相当するラベルが付与された複数のアークが出てきている。そのアークの先は、ノードまたは要素値としての文字列（テキスト）である。ノードの中に記載されている英数字（＃０、＃４９）などはオブジェクトＩＤである。
【００４１】
図４に示したツリー構造を図３に示した構造化文書の文書オブジェクトツリーと呼ぶ。
【００４２】
図１は、本実施形態に係る構造化文書管理システムの構成例を示したものである。図１において、構造化文書管理システムは、大きく分けて、要求制御部１、アクセス要求処理部２、検索要求処理部３、データアクセス部４、文書記憶部５、インデックス記憶部６、アクセス権限設定管理部２０１から構成されている。文書記憶部５、インデックス記憶部６は例えば、外部記憶装置を用いて構成される。
【００４３】
図１のシステム構成は、ソフトウエアを用いて実現可能である。
【００４４】
なお、アクセス権限設定管理部２０１については、後述する（「アクセス権限の設定」参照）。
【００４５】
要求制御部１は、要求受付部１１と結果処理部１２から構成されている。要求受付部１１は、ユーザからの文書格納や文書取得、文書検索などの要求を受け付けて、アクセス要求処理部２を呼び出す。結果処理部１２は、アクセス要求処理部２が処理した結果を要求元のユーザに返す処理を行う。
【００４６】
アクセス要求処理部２は、ユーザからの文書格納や文書取得などの要求に対応した複数の処理部から構成されている。つまり、文書格納部２１、文書取得部２２、文書削除部２３から構成されている。
【００４７】
文書格納部２１は、文書記憶部５中の論理的な指定エリアに文書を格納する処理を行う。
【００４８】
文書取得部２２は、文書記憶部５中の論理的なエリアが指定されたときに、その指定エリアに存在する文書を取得する処理を行う。
【００４９】
文書削除部２３は、文書記憶部５中の論理的な指定エリアに存在する文書を削除する処理を行う。
【００５０】
文書記憶部５は、構造化文書データベースであり、例えば、図８に示すように、文書をＵＮＩＸのディレクトリ構造のように階層的にツリー構造状に格納している。
【００５１】
図８に示すように、構造化文書データベースは、図４に示したような１つの構造化文書のツリー構造と同様に表現できる。すなわち、任意のノード以下の部分階層木（部分ツリー）は、構造化文書データベースから切り出された構造化文書であり、ここでは、これを文書オブジェクトツリーと呼ぶ。各ノードにはオブジェクトＩＤが割り当てられている。オブジェクトＩＤは、構造化文書データベース内ではユニークな数値を持つものとする。
【００５２】
階層木のルートとなるノードには、それがルートノードであることを特定するためのオブジェクトＩＤ「＃０」が割り当てられるものとする。
【００５３】
ルートノード、すなわち、「＃０」のノードからは「ｒｏｏｔ」タグを先頭に持つ「＃１」のノードへリンクが張られている。「＃１」のノードからは、「特許ＤＢ」タグを先頭にもつ「＃２」ノードへのリンクが張られている。「＃２」ノードからは、「特許」タグを先頭に持つ「＃４２」ノード、「＃５２」ノード、「＃６２」ノードへのリンクがそれぞれ張られている。
【００５４】
図３に示した「特許」情報は、「＃４２」ノード以下の部分ツリーに対応している。このノードからは「タイトル」タグ、「出願者」タグ、「要約」タグなどを先頭にもつノードへリンクが張られ、末端のノードからは、「ＸＭＬデータベース」、「Ｔ社」。「ＸＭＬを統一的に管理するデータベースを提供する…」などの文字列（要素値）へのリンクが張られている。
【００５５】
「＃５２」ノード以下の部分ツリー、「＃６２」ノード以下の部分ノードも１つの「特許」情報に対応する部分である。
【００５６】
ところで、例えば、「＃４３」ノードにリンクされた「ＸＭＬデータベース」という要素値は、「＃４３」ノードと「＃ｖａｌｕｅ」という特殊なタグ名で接続されている。このタグ名は、「＃」で始まるためＸＭＬ規格においては標準的なタグ名として利用することはできない。
【００５７】
このような構造化文書データベースの特定ノードを指定するために構造化文書パスを用いる。構造化文書パスは「ｕｉｘ：／／ｒｏｏｔ」から始まる文字列である。ｕｉｘ（Ｕｎｉｖｅｒｓａｌ  Ｉｄｅｎｔｉｆｉｅｒ  ｆｏｒ  ＸＭＬ）は構造化文書パスであることを示す前置文字列である。
【００５８】
例えば、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ」は、「＃１」ノードから「特許ＤＢ」が付与されたアークが指し示すノード、つまり「＃２」ノードに対応する。このように「ｒｏｏｔ」から「／」で区切られた部分文字列をタグ名とみなすことで「＃０」ノードからタグ名の並びに沿って対応するアークを下っていき、その最後のアークが指すノードが、パスの場所を指し示す。
【００５９】
例えば、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許」は、「＃４２」ノード、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／出願日／年」は、「＃４５」ノードを指し示す。
【００６０】
「＃２」ノード以下に、すなわち、「特許ＤＢ」に、複数の「特許」情報を格納する場合には、個々の「特許」情報を識別するために、構造化文書パスにインデックス表現が可能である。
【００６１】
「特許ＤＢ」の最初の「特許」情報であれば、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［０］」となるが、これは「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許」と同じとみなす。
【００６２】
「特許ＤＢ」の２番目の「特許」情報であれば、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［１］ＤＢ」の５番目の「特許」情報であれば、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［４］」となる。
【００６３】
インデックス記憶部６には検索時に用いる、要素名称生起インデックスとデータ生起インデックスが記憶されている。
【００６４】
要素名生起インデックスとは構造化文書データベースに格納されている要素名称のリストと、各要素名称が先頭にある構造化文書（文書オブジェクトツリー）の位置とを関連付けてインデックスファイル化したものである。例えば、図８の構造化文書データベースのように、（「特許」情報に対応する）「特許」という要素名称が「＃４２」ノード以下の構造化文書、「＃５２」ノード以下の構造化文書、「＃６２」ノード以下の構造化文書に存在する場合、これらをインデックス化すると、図９に示すように、それらの親ノード、「＃２」ノードが、要素名称生起インデックスファイルに「特許」キーからのチェーンで格納される。
【００６５】
このように、親ノードでインデックス化すると、インデックスファイルを圧縮することができる。すなわち、親ノードでインデックス化すれば、子ノードが増大しようとも、親ノードで代用しているので、チェーンサイズは増大しない。これに対し、実ノードをインデックス化すれば「特許」情報の格納数の増大とともにチェーンサイズはそれに比例して増加してしまう。
【００６６】
データ生起インデックスとは、構造化文書データベースに格納されている文字列データのリストと各文字列データがある構造化文書（文書オブジェクトツリー）の位置とを関連付けてインデックスファイル化したものである。例えば、図８の構造化文書データベースのように、「ＸＭＬ」という文字列データ（および、「ＸＭＬ」という文字列を含む文字列）が「＃４３」ノード以下の構造化文書、「＃４９」ノード以下の構造化文書に存在する場合、これらをインデックス化すると、図１０に示すように、「＃４３」ノード、「＃４９」ノードが、データ生起インデックスファイルに「ＸＭＬ」キーからのチェーンで格納される。
【００６７】
なお、逆階層インデックスなど、その他のインデックスファイルを用いてもよい。逆階層インデックスとは、あるノードとその親ノードとの対応を格納したものである（あるノードからその親ノードを求めることができる）。
【００６８】
文書記憶部５中の論理的な指定エリアとは、ユーザにより構造化文書パスを用いて指定された文書の格納場所を指す。構造化文書パス（簡単にパスと呼ぶことがある）は、ユーザにとって認識可能な表現である。
【００６９】
図１の説明に戻る。
【００７０】
データアクセス部４は、文書記憶部５をアクセスする基本インターフェイスの集合である。データアクセス部４は、文書オブジェクトツリー格納部４７、文書オブジェクトツリー削除部４８、文書オブジェクトツリー取得部４９、文書文字列取得部４４、パスから文書オブジェクトツリー取得部４５、文書パーサ部４６、合成文書作成部４７、インデックス更新部４８から構成される。
【００７１】
文書オブジェクトツリー格納部４１は、文書記憶部５中の物理的な指定エリアに文書オブジェクトツリーを格納する処理を行う。
【００７２】
文書オブジェクトツリー削除部４２は、文書記憶部５中の物理的な指定エリアに存在する文書オブジェクトツリーを削除する処理を行う。
【００７３】
文書オブジェクトツリー取得部４３は、文書記憶部５中の物理的な指定エリアに存在する文書オブジェクトツリーを取得する処理を行う。
【００７４】
文書文字列取得部４４は、文書オブジェクトツリーを構造化文書（ＸＭＬ文書）に変換する処理を行う。
【００７５】
パスから文書オブジェクトツリー取得部４５は、構造化文書パスを解析して文書記憶部５中の物理的なエリアを特定して、そのエリアに存在する文書オブジェクトツリーを取り出す処理を行う。
【００７６】
文書パーサ部４６は、ユーザにより入力された構造化文書を読み込んで構文解析して整合性の検査を行い、さらに文書構造定義データであるスキーマが存在すれば構造的に妥当かどうかの検証を行う。出力結果は文書オブジェクトツリーとなる。文書パーサは、通常、ｌｅｘ（ｌｅｘｉｃａｌ  ａｎａｌｙｚｅｒ  ｇｅｎｅｒａｔｏｒ）といったレキシカルアナライザ（字句解析を行い，トークンに分解する）とｙａｃｃ（ｙｅｔ  ａｎｏｔｈｅｒ  ｃｏｍｐｉｌｅｒ  ｃｏｍｐｉｌｅｒ）といったパーサジェネレータを組み合わせて構築することができる。
【００７７】
合成文書作成部４７は、文書格納や文書削除などをする際に、スキーマに合致しているかどうか検査しなければならないが、この検査時に必要となるデータを作成して出力する。
【００７８】
インデックス更新部４８は、文書格納や文書削除などにより、構造化文書データベースの格納内容が更新されるたびに、図９、図１０に示した要素名称生起インデックスとデータ生起インデックスを更新する。
【００７９】
文書記憶部５中の物理的な指定エリアとは、ファイルオフセットやオブジェクトＩＤなどの構造化文書データベース内ではユニークな文書データの存在場所を指し示す内部データである。ユーザにとっては認識不能なデータである。
【００８０】
文書記憶部５中に格納された文書を検索する処理を行う。要求制御部１の要求受付部１１でユーザからの文書検索の要求が受け付けられると、検索要求処理部３には、要求受付部１１からクエリ言語で記述されたクエリ文書が入力する。そしてデータアクセス部４を通してインデックス記憶部６，文書記憶部５にアクセスし、検索要求に合致する文書集合を取得して、その結果を結果処理部１２を介して出力する。
【００８１】
図２は、図１に示した構造化文書管理システムの一利用形態を示したもので、図２では、ＷＷＷ（Ｗｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂ）のバックエンドで、図１に示した構成の構造化文書管理システム１００が動作している場合を示している。
【００８２】
複数（ここでは、例えば３つ）のクライアント端末（例えばパーソナルコンピュータ、携帯通信端末など）１０２のそれぞれでＷＷＷブラウザ１０３が動作している。ユーザは、各クライアント端末からＷＷＷサーバ１０１にアクセスすることにより、構造化文書管理システム１００にアクセスすることができる。ＷＷＷブラウザ１０３とＷＷＷサーバ１０１とは、ＨＴＴＰ（Ｈｙｐｅｒ  ＴｅｘｔＴｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）で通信している。また、ＷＷＷサーバ１０１と構造化文書管理システム１００とは、ＣＧＩ（Ｃｏｍｍｏｎ  Ｇａｔｅｗａｙ  Ｉｎｔｅｒｆａｃｅ）またはＣＯＭ（Ｃｏｍｐｏｎｅｎｔ  Ｏｂｊｅｃｔ  Ｍｏｄｅｌ）などで通信している。
【００８３】
ユーザからの文書格納、文書取得、文書検索などの要求は、ＷＷＷブラウザ１０３から送信されて、ＷＷＷサーバ１０１を通して構造化文書管理システム１００にて受け付けられ、処理された結果は、ＷＷＷサーバ１０１を通して要求元のＷＷＷブラウザ１０３へ返信される。
【００８４】
以下、図１の構造化文書管理システムの（１）格納機能、（２）検索機能について詳細に説明する。そして、（３）適用例では、概念検索を用いた特許調査の場合を例にとり説明する。
【００８５】
（１）       格納機能
図１の構造化文書管理システムにおける格納系のコマンドには以下のものがある。
【００８６】
ｉｎｓｅｒｔＸＭＬ（パス、Ｎ番目、ＸＭＬ）：文書格納
ａｐｐｅｎｄＸＭＬ（パス、ＸＭＬ）        ：文書格納
ｇｅｔＸＭＬ（パス）                      ：文書取得
ｒｅｍｏｖｅＸＭＬ（パス）                ：文書削除
ｓｅｔＳｃｈｅｍａ（パス、スキーマ）      ：スキーマ格納
ｇｅｔＳｃｈｅｍａ（パス）      ：スキーマ取得
「ｉｎｓｅｒｔＸＭＬ」は、（  ）内に指定した構造化文書パス以下のＮ番目に文書を挿入するコマンド（以下、簡単に挿入コマンドと呼ぶ）である。
【００８７】
「ａｐｐｅｎｄＸＭＬ」は、（  ）内に指定した構造化文書パス以下の最後に文書を挿入するコマンド（以下、簡単に追加コマンドと呼ぶ）である。
【００８８】
「ｇｅｔＸＭＬ」は、（  ）内に指定した構造化文書パス以下の文書を取り出すコマンド（以下、簡単に取得コマンドと呼ぶ）である。
【００８９】
「ｒｅｍｏｖｅＸＭＬ」は、（  ）内に指定した構造化文書パス以下の文書（スキーマ文書以外の文書で、主に、コンテンツ文書）を削除するコマンド（以下、簡単に削除コマンドと呼ぶ）である。
【００９０】
「ｓｅｔＳｃｈｅｍａ」は、（  ）内に指定した構造化文書パスにスキーマを設定するコマンド（以下、簡単にスキーマ格納コマンドと呼ぶ）である。
【００９１】
「ｇｅｔＳｃｈｅｍａ」は、（  ）内に指定した構造化文書パスに設定されているスキーマを取り出すコマンド（以下、簡単にスキーマ取得コマンドと呼ぶ）である。
【００９２】
上記コマンドのうち、挿入コマンド、追加コマンド、スキーマ格納コマンドについての処理はアクセス要求処理部２の文書格納部２１で実行され、取得コマンド、スキーマ取得コマンドについての処理は文書取得部２２で実行され、削除コマンドについての処理は文書削除部２３で実行される。
【００９３】
図５を参照して、構造化文書データベースの初期状態（図５（ａ）参照）において、追加コマンドを実行する場合について説明する。
【００９４】
図５（ａ）に示すように、「＃０」ノードと「＃１」ノードが「ｒｏｏｔ」アークで接続されている初期状態に対して、
「ａｐｐｅｎｄＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ”，“＜特許ＤＢ／＞”）」
を実行した結果、図５（ｂ）に示すように、「＃２」ノードと「特許ＤＢ」アークが作成される。
【００９５】
図５（ｂ）に示した状態の構造化文書データベースに対して、取得コマンドを実行する場合について説明する。
【００９６】
例えば、「ｇｅｔＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ”）」を実行すると、図５（ｂ）の「ｒｏｏｔ」アークが示す「＃０」ノード以下の文書オブジェクトツリーが取り出され、それをＸＭＬの文字列表現に変換する。その結果、図６に示すように、「＜ｒｏｏｔ＞＜特許ＤＢ／＞＜／ｒｏｏｔ＞」なる文字列が取り出される。取得コマンドの処理は、アクセス要求処理部２の文書取得部２２にて実行される。
【００９７】
次に、図５（ｂ）に示した状態の構造化文書データベースに対して、図３に示すようなコンテンツ文書（ＸＭＬ文書）としての「特許」情報を格納するための追加コマンドを実行する場合について説明する。すなわち、この場合、「ａｐｐｅｎｄＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ”，“＜特許＞…＜／特許＞”）」を実行する。このコマンド中「“＜特許＞…＜／特許＞”」が、図３に示した「特許」情報に対応する。
【００９８】
上記追加コマンドの処理が実行されると、図７に示すように、「＃２」ノード以下に「＃４２」ノードをトップとする文書オブジェクトツリー（図４に対応）が追加される。
【００９９】
図５（ｂ）に示した状態の構造化文書データベースに対して、次に示すような追加コマンドを３回繰り返して実行したとする。
【０１００】
「ａｐｐｅｎｄＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ”，“＜特許＞…＜／特許＞”）」
上記コマンド中、「＜特許＞…＜／特許＞」は、図３に示した文書構造のコンテンツ文書に対応する。
【０１０１】
すると、図８に示すように、「＃２」ノード以下に「＃４２」ノード、「＃５２」ノード、「＃６２」ノードをトップとする文書オブジェクトツリーが追加される。
【０１０２】
次に、図８に示した状態の構造化文書データベースに対して、３つの「特許」情報を取り出すための取得コマンドを実行した場合について説明する。この場合、「ｇｅｔＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ”）」を実行する。すると、「特許ＤＢ」アークが示す「＃２」ノード以下の文書オブジェクトツリーが取り出され、それをＸＭＬの文字列表現（ＸＭＬ文書）に変換する。その結果、図１１に示すように、「＜特許ＤＢ＞＜特許＞…＜／特許＞＜特許＞…＜／特許＞＜特許＞…＜／特許＞＜／特許ＤＢ＞」なる文字列が取り出される。
【０１０３】
構造化文書データベースでは、上記の「特許」情報などのコンテンツ文書（ＸＭＬ文書）の文書構造を定義したデータ、すなわち、スキーマも管理対象とする。
【０１０４】
図１２は、ＸＭＬ文書の文書構造を定義するスキーマの一例を示したものである。ここでは、ＸＭＬの文書構造定義言語の一つであるＸＤＲ（ＸＭＬ−Ｄａｔａ  Ｒｅｄｕｃｅｄ）を取り上げる。もちろん、ＸＭＬ−Ｓｃｈｅｍａなど他の文書構造定義言語を用いてもかまわない。
【０１０５】
図１２に示したスキーマは、図３に示した「特許」情報の文書構造をＸＤＲで定義したものである。図１２からも容易に分かるとおり、スキーマもＸＭＬ形式の構造化文書である。「Ｓｃｈｅｍａ」タグから始まる構成要素から始まり、その子要素として、「ＥｌｅｍｅｎｔＴｙｐｅ」タグから始まる要素集合が存在する。
【０１０６】
図１２に示したスキーマにおいて、例えば、最初の「ＥｌｅｍｅｎｔＴｙｐｅ」タグから始まる子要素は以下の情報を意味している。
【０１０７】
・「特許」タグを持つ要素の文書構造定義（「ＥｌｅｍｅｎｔＴｙｐｅ  ｎａｍｅ＝”特許”」）である。
【０１０８】
・子要素は要素だけ（「ｃｏｎｔｅｎｔ＝”ｅｌｔＯｎｌｙ”」）である。
【０１０９】
・「タイトル」、「出願日」、「要約」タグから始まる子要素から構成される（「ｅｌｅｍｅｎｔ  ｔｙｐｅ＝”タイトル”、…」）。さらに、その順番は一意に決まっている（「ｏｒｄｅｒ＝”ｓｅｑ”」）。
【０１１０】
・上記「特許」タグから始まる要素の文書構造定義の他に、「タイトル」「出願者」「要約」「年」「月」「日」「出願日」の文書構造定義を記述している。すなわち、「出願日」を除く、「タイトル」「出願者」「要約」「年」「月」「日」タグから始まる構成要素の子要素はテキストだけと定義されている（「ｃｏｎｔｅｎｔ＝”ｔｅｘｔＯｎｌｙ”」）。
【０１１１】
・「出願日」タグから始まる構成要素の子要素は、「年」、「月」、「日」の並びである。
【０１１２】
図８に示した状態の構造化文書データベースに対して、図１２に示したスキーマ文書を格納するためのスキーマ格納コマンドを実行する場合について説明する。この場合、「ｓｅｔＳｃｈｅｍａ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ”，“＜Ｓｃｈｅｍａ＞…＜／Ｓｃｈｅｍａ＞”）」を実行する。このコマンド中、「“＜Ｓｃｈｅｍａ＞…＜／Ｓｃｈｅｍａ＞”」」が図１２に示したスキーマ文書に対応する。
【０１１３】
上記コマンドの実行により、図１３に示すように、「＃２」ノード以下に「＃ｓｃｈｅｍａ」アークが追加され、その先には、「＃３」ノードをトップノードとする文書オブジェクトツリーが追加される。スキーマ自身がＸＭＬ文書表現になっているため、前述した「特許」情報のようなコンテンツ文書格納のケースと同様にツリー展開可能である。
【０１１４】
図１３において、「＠ｎａｍｅ」など「＠」で始まるアークは属性に対応する。タグ名「＃ｓｃｈｅｍａ」も「＃」、「＠」で始まるためＸＭＬ規格においては標準的なタグ名として利用することはできない。
【０１１５】
「＃２」ノード下に図１２に示したスキーマ文書が格納されたことにより、以後、「＃２」ノード以下にこれから格納される文書の文書構造は、図１２に示したスキーマ文書により定義された文書構造に適合することが要求される。すなわち、「＃２」ノード以下に図１２に示したスキーマが設定されることになる。
【０１１６】
「＃２」ノード以下に図１２に示したスキーマが設定されると、図１４に示すように、「＃２」ノードの文書オブジェクトのファイルには、「＃２」ノード以下の文書オブジェクトツリーには、当該スキーマが存在する旨の属性値がセットされる。
【０１１７】
「＃２」ノード以下に図１２に示したスキーマが設定された後に、このスキーマで定義された文書構造に一致する図３に示したような「特許」情報を、図１４に示したように、文書オブジェクトツリーとして構造化文書データベースに格納したとき、この文書の文書構造には図１２に示したスキーマが存在する旨の属性値が、当該文書オブジェクトツリーを構成する各文書オブジェクトにセットされる。例えば、当該文書オブジェクトツリーを構成する各文書オブジェクトのファイルに対して、スキーマが存在している旨の属性値（（例えば、「スキーマ適合有無」）に「１」がセットされる。図１４では、スキーマに適合している各文書オブジェクト（ノード）は２重丸で示している。２重丸で示した各文書オブジェクトには、その文書オブジェクトに対応した文書構造定義が存在することになる。
【０１１８】
図１５は、各文書オブジェクトのファイルの内容を概念的に示したもので、例えば、オブジェクトＩＤが「＃４２」の文書オブジェクトのファイルには、その文書オブジェクトにリンクされている他の文書オブジェクトに関する情報（例えば、アークや、リンク先の文書オブジェクトへのポインタ値など）とともに、上記属性値が記述されている。なお、当該文書オブジェクトに適用するスキーマが存在しないときは、「スキーマ適合有無」の値は「０」となる。
【０１１９】
図１６、図１７は、図１の構造化文書管理システムで、必要に応じて検索で使用される概念階層を構造化文書で表現した例を示す。図１６、図１７に示す「概念」情報はＸＭＬで記述したコンテンツ文書である。
【０１２０】
図１６に示した「概念」情報の例は、いわゆる特許調査における特許文書の内容を分類するための１つの分類軸として用いる「情報モデル」を概念階層で表現している。「概念」タグで囲まれた「概念」情報は、入れ子構造を持った文書構造をもっている。つまり、図１６の例では、概念「情報モデル」の子供概念として、概念「ドキュメント」、概念「リレーション」、概念「オブジェクト」が存在している。また、概念「ドキュメント」の子供概念として、概念「構造化訴求メント」、概念「非構造化ドキュメント」が存在し、さらに、概念「構造化ドキュメント」の子供概念として、概念「ＸＭＬ」、概念「ＳＧＭＬ」が存在している。
【０１２１】
図１７に示す「概念」情報の記述例は、図１６とは異なる分類軸「情報操作」を概念階層で表現している。図１７の例では、概念「情報操作」の子供概念として、概念「検索」、概念「格納」、概念「加工」、概念「流通」が存在している。
【０１２２】
図１６，図１７に示したような「概念」情報も、前述の「特許」情報と同様にして、構造化文書データベース内に格納することができる。すなわち、例えば、まず、図８に示した状態の構造化文書データベースに対して、「ａｐｐｅｎｄＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ”，“＜概念ＤＢ／＞”）」を実行して、図１８に示すように、「＃２０１」ノードと「概念ＤＢ」アークが作成される。この状態において、図１６に示した「概念」情報を格納する場合には、「ａｐｐｅｎｄＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／概念ＤＢ”，“＜概念名前＞…＜／概念＞”）」を実行する。このコマンド中「“＜概念名前＞…＜／概念＞”」が、図１６に示した「概念」情報に対応する。
【０１２３】
上記追加コマンドの処理が実行されると、図１９に示すように、「＃２０１」ノード以下に「＃２０２」ノードをトップとする文書オブジェクトツリーが追加される。
【０１２４】
以上説明したように、図１の構造化文書管理システムでは、構造化文書データベース上に登録される文書構造が異なる膨大な数のＸＭＬ文書群（コンテンツ文書、スキーマ文書、クエリ文書など）を、図１８，図１９に示すように、「ｒｏｏｔ」タグを先頭に持つツリー状の１つの巨大なＸＭＬ文書として取り扱う。そのため、部分的なＸＭＬ文書をアクセスするには巨大なＸＭＬ文書に対するパスという文書構造に依存しない統一的なアクセス手段を用いることにより、幅広くＸＭＬ文書を検索したり加工したりすることが可能になる。
【０１２５】
また、構造化文書データベース上の一部にスキーマを設定することで、格納しようとする文書の文書構造がそのスキーマにより定義されている文書構造に一致するか否かの妥当性のチェックが自動的に行なえる（後述）。
【０１２６】
（１−１）文書格納処理
次に、図１の構造化文書管理システムの文書格納処理動作について、図２０に示すフローチャートを参照して説明する。
【０１２７】
クライアント端末から構造化文書管理システムに対し、文書格納要求として、挿入コマンド、追加コマンド、スキーマ格納コマンドのうちのいずれかが送信されて、要求受付部１１にて受け付けられたとき、図２０に示した処理動作を行う。
【０１２８】
クライアント端末の所定の表示装置には、構造化文書管理システム１００（の例えば、要求制御部１）から提供された、例えば、図３１に示すようなユーザインターフェイスとしての画面が表示されている。
【０１２９】
図３１に示す画面には、構造化文書管理システム１００への操作項目の一覧（メニュー）が表示されている。操作項目として、「ＸＭＬ登録／削除」、「スキーマ設定」、「ＸＭＬ検索」とがある。
【０１３０】
ユーザが例えば、この画面上で「ＸＭＬ登録／削除」をマウス等のポインティングデバイスなどを用いて選択すると、図３２に示したような文書の格納／削除を行うためのユーザインタフェースとしての画面が表示される。
【０１３１】
図３２において、領域Ｗ１には、文書構造化文書データベースの現在のツリー構造の要素名（タグ名）がユーザが理解可能なように簡略的に表示されている。なお、図３２では、上位階層の要素名のみを表示しているが、末端の要素名まで表示可能である。また、領域Ｗ２は、構造化文書パスの入力領域であり、領域Ｗ１の表示内容に従って、構造化文書パスを入力するようになっている。また、領域Ｗ３は、格納する文書を入力したり、取得した文書を表示するようになっている。
【０１３２】
例えば、構造化文書パスとして「ｒｏｏｔ」を入力する場合には、領域Ｗ１の「ｒｏｏｔ」をマウス等で選択すればよい。すると、図３２に示すように、領域Ｗ２の構造化文書パスの入力領域に「ｕｉｘ：／／ｒｏｏｔ」と表示される。また、新たに、「特許ＤＢ」という要素を追加する場合は、図３２に示すように、領域Ｗ３に、「特許ＤＢ」を入力する。そして、「登録」ボタンＢ１を選択すると、クライアント端末からａｐｐｅｎｄＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ”，“＜特許ＤＢ／＞”）」なる追加コマンドが構造化文書管理システムへ送信される。構造化文書管理システムでは、上記追加コマンドを受け、後述するような処理を実行した結果、例えば、図５（ｂ）に示すように、「＃２」ノードと「特許ＤＢ」アークが作成される。また、領域Ｗ１には、図３３に示すように、「ｒｏｏｔ」の下に「特許ＤＢ」が追加表示される。
【０１３３】
さて、ユーザが図３４に示したような文書の格納／削除画面上の領域Ｗ３に、例えば、文書「＜Ａ＞データ＜／Ａ＞」を入力し（あるいはＣＤ−ＲＯＭ等の所定の記録媒体等から読み込むことにより入力し）、領域Ｗ１の「特許［０］」をマウス等で選択すると、構造化文書パスの入力領域Ｗ２に、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［０］」と表示される。そして、「登録」ボタンＢ１を選択すると、クライアント端末からａｐｐｅｎｄＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ”，“＜特許ＤＢ／＞”）」なる追加コマンドが構造化文書管理システムへ送信される。
【０１３４】
ここでは、例えば、構造化文書データベースが、図１４に示した状態のときに、「ａｐｐｅｎｄＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［０］”，“＜Ａ＞データ＜／Ａ＞”）」なる追加コマンドを受け付けた場合を例にとり説明する。
【０１３５】
要求受付部１１は、上記追加コマンドを受け付けると、上記追加コマンド中の２つのパラメータである構造化文書パス「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［０］」と文書「＜Ａ＞データ＜／Ａ＞」（以下、格納文書と呼ぶ）とを文書格納部２１へ渡す（ステップＳ１）。
【０１３６】
まず、文書格納部２１は、文書パーサ部４６に格納文書を渡す。文書パーサ部４６は、格納文書を読み込んで、構文解析を行い、当該格納文書の文書構造がＸＭＬにて規定された正しい形式であるか否かの整合性の検査を行う（ステップＳ２）。
【０１３７】
この整合性の検査でエラーが見つかれば（ステップＳ３）、文書格納部２１，結果処理部１２を介して、クライアント端末に「文書格納失敗」の旨のメッセージを返す（ステップＳ４）。
【０１３８】
整合性の検査でエラーが見つからなければ、次に、文書格納部２１は、パスから文書オブジェクトツリー取得部４５へ構造化文書パスを渡す。パスから文書オブジェクトツリー取得部４５は、構造化文書パスから文書記憶部５中の物理的なエリアを特定することにより、そのエリアに存在する構造化文書パスにて表されたノード（文書オブジェクトＯｘ０）を含む文書オブジェクトツリーを取り出す（ステップＳ５）。構造化文書パスの指定が正しければ、文書オブジェクトＯｘ０のオブジェクトＩＤを取得することができるので（ステップＳ６）、その場合は、ステップＳ８へ進む。
【０１３９】
例えば、上記追加コマンドの場合、「＃４２」ノードが文書オブジェクトＯｘ０となるので、そのオブジェクトＩＤとして、「＃４２」を取得するとともに、この「＃４２」ノードを含む文書オブジェクトツリー（例えば、「＃４２」ノードの全ての子孫ノードと「＃４２」ノードと同じ階層にある全ての（兄弟）ノードと、「＃４２」ノードの親ノードである「＃２」ノードとからなる文書オブジェクトツリー）を取得する。
【０１４０】
指定された構造化文書パスからそれに対応する文書オブジェクトＯｘ０が見つからなければ、エラーとなり（ステップＳ６）、文書格納部２１，結果処理部１２を介して、クライアント端末に「文書格納失敗」の旨のメッセージを返す（ステップＳ７）。
【０１４１】
例えば、構造化文書データベースが、図１８に示した状態のときに、追加コマンドのパラメータとして、構造化文書パスが「ｕｉｘ：／／ｒｏｏｔ／その他」と表されていたとき、これに対応する文書オブジェクトは存在しないので、ステップＳ６でエラーとなり、ステップＳ７へ進む。
【０１４２】
次に、ステップＳ８では、文書オブジェクトＯｘ０にスキーマが存在するか否かを検査する。この検査は、前述したように、各文書オブジェクトのファイルに属性値が記述されているので、この値をチェックすればよい。文書オブジェクトＯｘ０のもつ「スキーマ適合有無」の値が「１」のときは、ステップＳ９へ進む。
【０１４３】
以下、図２０のステップＳ９の処理（合成文書作成部４７の処理）について、図２１に示すフローチャートを参照して詳細に説明する。
【０１４４】
文書格納部２１は、ステップＳ５で取得した文書オブジェクトツリーを合成文書作成部４７へ渡す。
【０１４５】
合成文書作成部４７は、この文書オブジェクトツリーを文書オブジェクトＯｘ０から遡り、「Ｓｃｈｅｍａ」タグを子要素として持つ文書オブジェクトＯｘ１を検索する（ステップＳ２１）。
【０１４６】
例えば、図１４に示した構造化文書データベースでは、文書オブジェクトＯｘ０としての「＃４２」ノードの親ノードである「＃２」ノードから「Ｓｃｈｅｍａ」タグをトップ（先頭）にもつノード（「＃３」ノード）へのリンクが張られているので（「Ｓｃｈｅｍａ」タグを子要素として持つので）、この「＃２」ノードが文書オブジェクトＯｘ１となる。よって、ステップＳ２２をスキップして、ステップＳ２３へ進む。
【０１４７】
この文書オブジェクトＯｘ１から文書オブジェクトＯｘ０、さらに文書オブジェクトＯｘ０からアークを辿って、その下流にある、文書オブジェクトの属性値の値が「１」である全ての子ノードからなる文書オブジェクトツリーＯｔ１を取り出す（ステップＳ２３）。
【０１４８】
例えば、上記追加コマンド中のパラメータの構造化文書パスが「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［０］」と指定されているとき、文書オブジェクトツリーＯｔ１は、「＃４２」ノード〜「＃４９」ノードから構成されたものとなる（図１４参照）。
【０１４９】
次に、ステップＳ２５へ進む。
【０１５０】
ステップＳ２５では、文書オブジェクトツリーＯｔ１に格納文書の文書オブジェクトツリーを文書オブジェクトＯｘ０の子ノードとして挿入する。その結果得られた新たな文書オブジェクトツリーを文書オブジェクトツリーＯｔ２とする。
【０１５１】
この文書オブジェクトツリーＯｔ２をＸＭＬ文書に変換し、それをテンポラリファイルＡに出力する（ステップＳ２７）。
【０１５２】
例えば、上記追加コマンド中のパラメータの格納文書「＜Ａ＞データ＜／Ａ＞」の文書オブジェクトツリー（この場合は、１つの文書オブジェクト）を「＃４２」ノード〜「＃４９」ノードで構成された文書オブジェクトツリーＯｔ１に「＃４２」ノードの子ノードとして挿入して得られた合成文書の文書オブジェクトツリーＯｔ２をＸＭＬ文書に変換した結果を図２２に示す。この合成文書は、もともとある「特許」情報に「＜Ａ＞データ＜／Ａ＞」というデータを追加したものとなっている。
【０１５３】
図２２に示したＸＭＬ文書、すなわち、合成文書がテンポラリファイルＡに出力され、テンポラリファイルＡに一時格納される。
【０１５４】
一方、スキーマタグ以下の文書オブジェクトツリーＯｔ３をＸＭＬ文書に変換して、それをテンポラリファイルＢに出力する（ステップＳ２８）。すなわち、テンポラリファイルＢには、スキーマ文書が一時格納されることになる。
【０１５５】
例えば、文書オブジェクトツリーＯｔ３である「＃３」ノードをトップノードとする文書オブジェクトツリーをＸＭＬ文書に変換した結果を図２３に示す。図２３に示したＸＭＬ文書がテンポラリファイルＢに出力され、テンポラリファイルＢに一時格納される。
【０１５６】
図２２に示すように、テンポラリファイルＡ（「ｔｍｐ０００．ｘｍｌ」）には、もともとある「特許」情報の要素の他に、格納文書、すなわち、ここでは、例えば、「＜Ａ＞データ＜／Ａ＞」が挿入されている。また、「ｘｍｌｎｓ＝”ｘ−ｓｃｈｅｍａ：ｔｍｐ００１．ｘｍｌ”」という、テンポラリファイルＢ（「ｔｍｐ００１．ｘｍｌ」）へのリンク情報の記述がある。この記述は、「特許」情報に適用されるスキーマが出力されているテンポラリファイルＢを指定している。
【０１５７】
次に、図２０の説明に戻る。
【０１５８】
ステップＳ１０では、文書格納部２１は文書パーサ部４６に、合成文書のテンポラリファイルＡとスキーマのテンポラリファイルＢとを与えて、合成文書の文書構造の妥当性をチェックする。すなわち、文書パーサ部４６は、合成文書のテンポラリファイルＡとスキーマのテンポラリファイルＢとを読み込み、合成文書の文書構造が、スキーマにより定義されている文書構造に一致するか否かをチェックする。
【０１５９】
例えば、図２２に示した合成文書と、図２３に示したスキーマとで妥当性のチェックを行った場合、合成文書には、スキーマにより定義されていない「Ａ」という要素が存在するため、図２３の合成文書は、妥当性のチェックでエラーとなる（ステップＳ１１）。この場合、文書格納部２１，結果処理部１２を介して、クライアント端末に「文書格納失敗」の旨のメッセージを返す（ステップＳ１２）。
【０１６０】
例えば、クライアント端末の所定の表示装置には、図３５に示すようなメッセージが表示される。
【０１６１】
次に、構造化文書データベースが、図１４に示した状態のときに、「ａｐｐｅｎｄＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ”，“＜特許＞…＜／特許＞”）」なる追加コマンドを受け付けた場合について、図２０を参照して説明する。前述同様にして、文書オブジェクトＯｘ０のオブジェクトＩＤ「＃２」を取得する（ステップＳ５）、この文書オブジェクトには、スキーマが存在するので（ステップＳ８）、ステップＳ９において合成文書を作成する。
【０１６２】
この場合、文書オブジェクトＯｘ０である「＃２」ノード自体から「Ｓｃｈｅｍａ」タグをトップ（先頭）にもつノード（「＃３」ノード）へのリンクが張られているので、この「＃２」ノードが文書オブジェクトＯｘ１となる（図２１のステップＳ２１）。すなわち、文書オブジェクトＯｘ０と文書オブジェクトＯｘ１が同じなので（ステップＳ２２）、ステップＳ２９へ進み、格納文書「＜特許＞…＜／特許＞」の文書オブジェクトツリーをＸＭＬ文書に変換し、テンポラリファイルＡに出力する（ステップＳ２９）。
【０１６３】
例えば、図２４に示すように、テンポラリファイルＡ（「ｔｍｐ０００．ｘｍｌ」）には、格納文書である「特許」情報、すなわち、ここでは、「＜特許＞…＜／特許＞」が出力されている。また、「ｘｍｌｎｓ＝”ｘ−ｓｃｈｅｍａ：ｔｍｐ００１．ｘｍｌ”」という、テンポラリファイルＢ（「ｔｍｐ００１．ｘｍｌ」）へのリンク情報の記述がある。
【０１６４】
次に、ステップＳ２８へ進む。図２５に示すように、テンポラリファイルＢには、「＃３」ノードをトップノードとするスキーマの文書オブジェクトツリーをＸＭＬ文書に変換した結果が出力されている。
【０１６５】
図２０のステップＳ１０で、図２４に示した合成文書と、図２５に示したスキーマとで妥当性のチェックを行ったとき、合成文書の文書構造と、スキーマにより定義されている文書構造とは一致する、この場合、ステップＳ１１からステップＳ１３へ進む。
【０１６６】
ステップＳ１３では、格納文書の文書オブジェクトツリーが、文書オブジェクトＯｘ０下に追加される。すなわち、文書格納部２１により、格納文書の文書オブジェクトツリーを構成する各文書オブジェクト（のファイル）にオブジェクトＩＤが与えられ、文書オブジェクトＯｘ０から格納文書の文書オブジェクトツリーの先頭の文書オブジェクトへリンクが張られる。そして、文書オブジェクトツリー格納部４１により、格納文書の文書オブジェクトツリーを構成する各文書オブジェクト（のファイル）が文書記憶部５に格納される。
【０１６７】
次に、ステップＳ１４へ進み、インデックス記憶部６のインデックスを更新する。
【０１６８】
なお、ステップＳ８で、文書オブジェクトＯｘ０のもつ属性値の値が「０」のときは、上述したスキーマを用いた合成文書の文書構造の妥当性のチェックを行わずに、そのままマステップＳ１３へ進み、格納文書の文書オブジェクトツリーを、文書オブジェクトＯｘ０下に追加し（ステップＳ１３）、それに伴い、インデックス記憶部６のインデックスを更新する（ステップＳ１４）。
【０１６９】
（１−２）文書取得処理
次に、図１の構造化文書管理システムの文書取得処理動作について、図２６に示すフローチャートを参照して説明する。
【０１７０】
クライアント端末から構造化文書管理システムに対し、文書取得要求として、取得コマンド、スキーマ取得コマンドのうちのいずれかが送信されて、要求受付部１１にて受け付けられたとき、図２６に示した処理動作を行う。
【０１７１】
例えば、ユーザが図３６に示したような文書の格納／削除画面上の領域Ｗ１の「特許ＤＢ」をマウス等で選択すると（クリックすると）、構造化文書パスの入力領域Ｗ２に、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ」と表示されとともに、「ｇｅｔＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ”）」なる取得コマンドが構造化文書管理システムへ送信される。
【０１７２】
ここでは、例えば、構造化文書データベースが、図８に示した状態のときに、「ｇｅｔＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ”）」なる取得コマンドを受け付けた場合を例にとり説明する。
【０１７３】
要求受付部１１は、上記取得コマンドを受け付けると、上記取得コマンド中のパラメータである構造化文書パス「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ」を文書取得部２２へ渡す（ステップＳ３１）。
【０１７４】
文書取得部２２は、パスから文書オブジェクトツリー取得部４５へ構造化文書パスを渡す。パスから文書オブジェクトツリー取得部４５は、構造化文書パスから文書記憶部５中の物理的なエリアを特定することにより、そのエリアに存在する構造化文書パスにて表されたノード（文書オブジェクトＯｘ５）を取り出す（ステップＳ３２）。構造化文書パスの指定が正しければ、文書オブジェクトＯｘ５のオブジェクトＩＤを取得することができるので（ステップＳ３３）、その場合は、ステップＳ３５へ進む。
【０１７５】
例えば、上記取得コマンドの場合、「＃２」ノードが文書オブジェクトＯｘ５となるので、そのオブジェクトＩＤとして、「＃２」を取得するとともに、この「＃２」ノード以下の文書オブジェクトツリーＯｔ５（「＃２」ノード、「＃４２」ノード〜「＃４９」ノード、「＃５２」ノード以下、「＃６２」ノード以下）を取得する（ステップＳ３５）。
【０１７６】
ステップＳ３２において、指定された構造化文書パスからそれに対応する文書オブジェクトＯｘ５が見つからなければ、エラーとなり（ステップＳ３３）、文書取得部２２，結果処理部１２を介して、クライアント端末に「文書取得失敗」の旨のメッセージを返す（ステップＳ３４）。
【０１７７】
ステップＳ３５で取得した文書オブジェクトツリーＯｔ５は、文書文字列取得部４４でＸＭＬ文書に変換される。例えば、上記取得コマンドの場合、取得したＸＭＬ文書は、図１１に示すような３つの「特許」情報のＸＭＬ文書となる。
【０１７８】
文書取得部２２は、結果処理部１２を介して、図１１に示したようなＸＭＬ文書を（例えば、ＸＳＬ（ｅＸｔｅｎｓｉｂｌｅ  Ｓｔｙｌｅ  Ｌａｎｇｕａｇｅ）といった所定のスタイルシートとともに）、クライアント端末へ返す（ステップＳ３７）。
【０１７９】
クライアント端末では、図１１に示したＸＭＬ文書を、スタイルシートを用いてＨＴＭＬデータに変換して、例えば、図３６に示すように、領域Ｗ２に表示する。
【０１８０】
ＸＳＬを利用すると、ＸＭＬ文書を様々な形に変換することが出来る。違う構文書造のＸＭＬ文書に変換することも出来るし、ＸＭＬ文書からＨＴＭＬページを生成することも出来る。
【０１８１】
（１−３）文書削除処理
次に、図１の構造化文書管理システムの文書削除処理動作について、図２７に示すフローチャートを参照して説明する。
【０１８２】
クライアント端末から構造化文書管理システムに対し、文書削除要求として、削除コマンドが送信されて、要求受付部１１にて受け付けられたとき、図２７に示した処理動作を行う。
【０１８３】
例えば、ユーザが図３６に示したような文書の格納／削除画面上の領域Ｗ１の「特許ＤＢ」をマウス等で選択すると（クリックすると）、構造化文書パスの入力領域Ｗ２に、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ」と表示され、さらに、「削除」ボタンＢ２を選択すると「ｒｅｍｏｖｅＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ”）」なる削除コマンドが構造化文書管理システムへ送信される。
【０１８４】
ここでは、例えば、構造化文書データベースが、図１４に示した状態のときに、「ｒｅｍｏｖｅＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［０］／出願日”）」なる削除コマンドを受け付けた場合を例にとり説明する。
【０１８５】
要求受付部１１は、上記削除コマンドを受け付けると、上記削除コマンド中のパラメータである構造化文書パス「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［０］／出願日」を文書削除部２３へ渡す（ステップＳ４１）。
【０１８６】
次に、文書削除部２３は、パスから文書オブジェクトツリー取得部４５へ構造化文書パスを渡す。パスから文書オブジェクトツリー取得部４５は、構造化文書パスから文書記憶部５中の物理的なエリアを特定することにより、そのエリアに存在する構造化文書パスにて表されたノード（文書オブジェクトＯｘ０）を含む文書オブジェクトツリーを取り出す（ステップＳ４２）。構造化文書パスの指定が正しければ、文書オブジェクトＯｘ０のオブジェクトＩＤを取得することができるので（ステップＳ４３）、その場合は、ステップＳ４５へ進む。
【０１８７】
例えば、上記削除コマンドの場合、「＃４４」ノードが文書オブジェクトＯｘ０となるので、そのオブジェクトＩＤとして、「＃４４」を取得するとともに、この「＃４４」ノードを含む文書オブジェクトツリー（例えば、「＃４４」ノードの全ての子孫ノードと「＃４４」ノードと同じ階層にある全ての（兄弟）ノードと、「＃４４」ノードの親ノードである「＃４２」ノード、その親ノードである「＃２」ノードとからなる文書オブジェクトツリー）を取得する。
【０１８８】
指定された構造化文書パスからそれに対応する文書オブジェクトＯｘ０が見つからなければ、エラーとなり（ステップＳ４３）、文書格納部２１，結果処理部１２を介して、クライアント端末に「文書削除失敗」の旨のメッセージを返す（ステップＳ４４）。
【０１８９】
次に、ステップＳ４５では、文書オブジェクトＯｘ０にスキーマが存在するか否かを検査する。この検査は、前述したように、各文書オブジェクトのファイルに属性値が記述されているので、この値をチェックすればよい。文書オブジェクトＯｘ０のもつ属性値の値が「１」のときは、ステップＳ４６へ進む。
【０１９０】
以下、図２７のステップＳ４６の処理（合成文書作成部４７の処理（削除コマンド用））について、図２８に示すフローチャートを参照して詳細に説明する。
【０１９１】
なお、図２８において、図２１と同一部分は同一符号を付している。
【０１９２】
文書格納部２１は、ステップＳ４２で取得した文書オブジェクトツリーを合成文書作成部４７へ渡す。
【０１９３】
合成文書作成部４７は、この文書オブジェクトツリーを文書オブジェクトＯｘ０から遡り、「Ｓｃｈｅｍａ」タグを子要素として持つ文書オブジェクトＯｘ１を検索する（ステップＳ２１）。
【０１９４】
例えば、図１４に示した構造化文書データベースでは、文書オブジェクトＯｘ０としての「＃４４」ノードの上流にある「＃２」ノードから「Ｓｃｈｅｍａ」タグをトップ（先頭）にもつノード（「＃３」ノード）へのリンクが張られているので（「Ｓｃｈｅｍａ」タグを子要素として持つので）、この「＃２」ノードが文書オブジェクトＯｘ１となる。
【０１９５】
この文書オブジェクトＯｘ１から文書オブジェクトＯｘ０、さらに文書オブジェクトＯｘ０からアークを辿って、その下流にある、文書オブジェクトの属性値の値が「１」である全ての子ノードからなる文書オブジェクトツリーＯｔ１を取り出す（ステップＳ２３）。
【０１９６】
例えば、上記追加コマンド中のパラメータの構造化文書パスが「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［０］／出願日」と指定されているとき、文書オブジェクトツリーＯｔ１は、「＃４２」ノード〜「＃４９」ノードから構成されたものとなる（図１４参照）。
【０１９７】
次に、ステップＳ２６ヘ進み、文書オブジェクトツリーＯｔ１から文書オブジェクトＯｘ０以下の文書オブジェクトツリーを削除する。その結果得られた新たな文書オブジェクトツリーを文書オブジェクトツリーＯｔ２とする。
【０１９８】
この文書オブジェクトツリーＯｔ２をＸＭＬ文書に変換し、それをテンポラリファイルＡに出力する（ステップＳ２７）。
【０１９９】
例えば、上記削除コマンド中のパラメータの構造化文書パス「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［０］／出願日」が指し示す「＃４４」ノード以下の文書オブジェクトツリーを「＃４２」ノード〜「＃４９」ノードで構成された文書オブジェクトツリーＯｔ１から削除することにより得られた合成文書の文書オブジェクトツリーＯｔ２をＸＭＬ文書に変換した結果を図２９に示す。この合成文書は、もともとある「特許」情報から「＜出願日＞…＜／出願日＞」というデータを削除したものとなっている。
【０２００】
図２９に示したＸＭＬ文書、すなわち、合成文書がテンポラリファイルＡに出力され、テンポラリファイルＡに一時格納される。
【０２０１】
一方、スキーマタグ以下の文書オブジェクトツリーＯｔ３をＸＭＬ文書に変換して、それをテンポラリファイルＢに出力する（ステップＳ２８）。すなわち、テンポラリファイルＢには、スキーマ文書が一時格納されることになる。
【０２０２】
例えば、文書オブジェクトツリーＯｔ３である「＃３」ノードをトップノードとする文書オブジェクトツリーをＸＭＬ文書に変換した結果を図３０に示す。図３０に示したＸＭＬ文書がテンポラリファイルＢに出力され、テンポラリファイルＢに一時格納される。
【０２０３】
次に、図２７の説明に戻る。
【０２０４】
ステップＳ４７では、文書削除部２１は文書パーサ部４６に、合成文書のテンポラリファイルＡとスキーマのテンポラリファイルＢとを与えて、文書格納処理の場合と同様にして、合成文書の文書構造の妥当性をチェックする。
【０２０５】
例えば、図２９に示した合成文書と、図３０に示したスキーマとで妥当性のチェックを行った場合、合成文書には、スキーマにより定義されている「出願日」という要素が存在しないため、図２９の合成文書は、妥当性のチェックでエラーとなる（ステップＳ４８）。この場合、文書削除部２１，結果処理部１２を介して、クライアント端末に「文書削除失敗」の旨のメッセージを返す（ステップＳ４９）。
【０２０６】
なお、構造化文書データベースが、図１４に示した状態のときに、「ｒｅｍｏｖｅＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［０］”）」なる削除コマンドを、図２７に従って処理を行うと、図２８のステップＳ２７において、図２４に示したような合成文書がテンポラリファイルＡに出力される。テンポラリファイルＢは、図３０と同様である。
【０２０７】
このとき、図２４に示した合成文書と、図３０に示したスキーマとで妥当性のチェックを行った場合、合成文書の文書構造と、スキーマにより定義されている文書構造とは一致するので、ステップＳ４８からステップＳ５０へ進む。
【０２０８】
ステップＳ５０では、文書オブジェクトＯｘ０以下の文書オブジェクトツリーを削除する。すなわち、文書オブジェクトツリー削除部４２により、文書オブジェクトＯｘ０以下の文書オブジェクトツリーを構成する各文書オブジェクト（のファイル）が文書記憶部５から削除される。例えば、「＃２」ノードから「＃４２」ノード以下の文書オブジェクトのファイルが削除される。
【０２０９】
次に、ステップＳ５１へ進み、インデックス記憶部６のインデックスを更新する。また、クライアント端末の図３６に示したような表示画面の領域Ｗ１には、「特許［０］」が表示さなくなる。
【０２１０】
なお、ステップＳ４５で、文書オブジェクトＯｘ０のもつ属性値の値が「０」のときは、上述したスキーマを用いた合成文書の文書構造の妥当性のチェックを行わずに、そのままマステップＳ５０へ進み、文書オブジェクトＯｘ０以下の文書オブジェクトツリーを削除し（ステップＳ５０）、それに伴う、インデックス記憶部６のインデックスを更新する（ステップＳ５１）。
【０２１１】
（１−４）スキーマの設定、スキーマを用いた文書格納
図３１に示した画面上で、ユーザが「Ｓｃｈｅｍａ設定Ｗｉｎ」をマウス等のポインティングデバイスなどを用いて選択すると、図３７に示したようなスキーマの設定を行うためのユーザインタフェースとしての画面が表示される。
【０２１２】
ユーザが、領域Ｗ３に、例えば、図１２に示したような「特許」情報のスキーマを入力し、この入力したスキーマを「特許ＤＢ」以下のノードに設定する場合には、領域Ｗ１から「特許ＤＢ」をマウス等でクリックして選択した後（領域Ｗ２には、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ」が表示される）、「スキーマ設定」ボタンＢ３を選択する。すると、「ｓｅｔＳｃｈｅｍａ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ”，“＜Ｓｃｈｅｍａ＞…＜／Ｓｃｈｅｍａ＞”）」なるスキーマ格納コマンドが構造化文書管理システムへ送信される。このコマンドの処理は前述した文書格納処理動作と同様である。
【０２１３】
次に、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ」の下に「特許」情報を格納しようとするとき、「特許ＤＢ」以下のノードに既に設定されているスキーマを用いて「特許」情報を入力する場合について説明する。
【０２１４】
まず、スキーマを取得する。例えば、図３８に示すような文書の格納／削除を行うための画面の領域Ｗ１から「スキーマ」をマウス等を用いて選択すると、文書パスの入力領域Ｗ２に、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／＃Ｓｃｈｅｍａ」と表示されとともに、「ｇｅｔＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／Ｓｃｈｅｍａ”）」なるスキーマ取得コマンドが構造化文書管理システムへ送信される。
【０２１５】
このコマンドの処理は、前述した文書取得処理と同様である。構造化文書管理システムから返されるＸＭＬ文書は、図３８の画面の領域Ｗ３に表示される。
【０２１６】
図３８に示すように、領域Ｒ３には、「特許」情報のデータ入力領域が各要素毎に設定されて表示されている。この表示に従って、ユーザは、データを入力すればよい。例えば、「タイトル」、「年」などのデータ入力領域が階層的に配置され、表示されている。ユーザは、このデータ入力領域にデータを入力することで、スキーマにより定義された文書構造の格納文書が容易に作成することができる。
【０２１７】
また、領域Ｗ３に入力した「特許」情報の格納先として、領域Ｗ１で「特許ＤＢ」をマウス等を用いて選択すると、領域Ｗ２に構造化文書パスとして、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ」が表示される。その後、「登録」ボタンＢ１を選択すると、「ａｐｐｅｎｄＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ”，“＜特許＞…＜／特許＞”）」なる追加コマンドが構造化文書管理システムへ送信される。
【０２１８】
この場合、格納文書は、予めスキーマに従って入力されたものなので、図２０のステップＳ１０の妥当性チェックでエラーとなることはない。
【０２１９】
（２）検索機能
図１の構造化文書管理システムにおける検索系のコマンドには以下のものがある。
【０２２０】
ｑｕｅｒｙ（ｑｌ）
「ｑｕｅｒｙ」は、パラメータとして（  ）内のクエリｑｌを実行し、その結果のＸＭＬ文書を取得するコマンド（以下、検索コマンドと呼ぶ）である。
【０２２１】
クエリは、図３９に示すように、ＳＱＬ（Ｓｔｒｕｃｔｕｒｅｄ  ＱｕｅｒｙＬａｎｇｕａｇｅ）に似た形式の言語により、検索位置、検索条件、情報抽出部分などを記述した、構造化されたＸＭＬ文書である。クエリ文書も本発明の構造化文書管理システムの管理対象である。
【０２２２】
「ｋｆ：ｆｒｏｍ」タグから始まる要素には、検索位置の指定と文書要素の値に変数を対応付ける記述があり、「ｋｆ：ｗｈｅｒｅ」タグのから始める要素には、変数に関する条件づけの記述があり、「ｋｆ：ｓｅｌｅｃｔ」タグから始まる要素には、検索結果の出力形式が記述される。
【０２２３】
検索には、単純検索と概念検索とがある。単純検索とは、クエリ中に指定された検索条件を満たす情報を検索・抽出するものであり、概念検索とは、クエリ中に指定された概念情報を利用して、クエリ中に指定された検索条件を満たす情報を検索・抽出するものである。
【０２２４】
図４０は、単純検索のクエリの例を示したものである。図４０のクエリは、例えば、図１４に示したような状態の構造化文書データベースに対し、「特許ＤＢ」アークが示すノード以下に格納されている「特許」情報の文書群において、「１９９９年でかつ、「ＰＣ」のような内容の「要約」という要素をもつ文書（「特許」情報）の「タイトル」を列挙せよ」という検索要求を意味している。
【０２２５】
「ｋｆ：ｆｒｏｍ」タグから始まる要素の記述により、変数「＄ｔ」、「＄ｙ」、「＄ｓ」に、それぞれ「特許」情報の「タイトル」、「年」、「要約」という文書要素の値が代入される。
【０２２６】
「ｋｆ：ｗｈｅｒｅ」タグから始める要素の記述により、変数「＄ｙ」＝「１９９９」という比較がなされる。また、コンポーネント「ＭｙＬｉｋｅ」は変数「＄ｓ」と「ＰＣ」を引数として、「ＰＣ」と類似する値の変数「＄ｓ」を検知するための関数である。
【０２２７】
「ｋｆ：ｆｒｏｍ」タグから始まる要素の記述により、変数「＄ｔ」が出力値として利用される。
【０２２８】
なお、「ｋｆ：ｓｔａｒ」タグは構造の曖昧表現であり、例えば「＜特許＞＜ｋｆ：ｓｔａｒ＞＜年＞」は「タグ名が「特許」である要素の子孫の要素としていずれかに存在し、タグ名が「年」である要素」を意味する。
【０２２９】
図４１に図４０の単純検索のクエリを用いた検索結果を示す。この検索結果（検索結果文書）もＸＭＬ文書である。この検索結果文書は、「ｋｆ：ｓｅｌｅｃｔ」タグから始まる要素に記述されている、検索結果の出力形式に従った文書構造の文書であり、クエリ中に指定された検索条件を満たす構造化文書データベース中の構成要素を合成して生成される場合もある。
【０２３０】
図４２は、概念検索のクエリの例を示したものである。図４２のクエリは、例えば図１８，図１９に示すような状態の構造化文書データベースに対し、「特許ＤＢ」アークが示すノード以下に格納されている「特許」情報の文書群に対し、「概念ＤＢ」アークが示すノード以下に格納されている「概念」情報を利用して検索するための検索要求である。ここで、概念「周辺装置」の値をもつタグの子要素の値には、概念「ＳＣＳＩ」、「メモリ」、「ＨＤＤ」などがあるものとする。また、図１８には示していないが、各「特許」情報の構成要素には、「キーワード」タグから始める要素も存在するものとする。
【０２３１】
すなわち、図４２のクエリは、「概念「周辺装置」以下の概念のいずれかを「キーワード」という要素の値にもつ文書（「特許」情報）の「タイトル」を列挙せよ」という検索要求を意味している。
【０２３２】
「ｋｆ：ｆｒｏｍ」タグから始まる要素の記述により、変数「＄ｔ」、変数「＄ｋ」に、それぞれ、「特許」情報の「タイトル」、「キーワード」という要素の値が代入される。また、変数「＄ｘ」は「概念」情報として「周辺装置」の値をもつタグの子要素の値（「ＳＣＳＩ」、「メモリ」、「ＨＤＤ」など）が代入される。
【０２３３】
「ｋｆ：ｗｈｅｒｅ」タグから始める要素の記述により、「＄ｋ」＝「周辺装置」もしくは「＄ｋ」＝「＄ｘ」という比較がなされる。
【０２３４】
次に、図１の構造化文書管理システムの文書検索処理動作について、図４３に示すフローチャートを参照して説明する。
【０２３５】
図３１に示した画面上で、ユーザが「ＸＭＬ検索Ｗｉｎ」をマウス等のポインティングデバイスなどを用いて選択すると、図４４に示すような文書検索を行うためのユーザインタフェースとしての画面が表示される。
【０２３６】
図４４の検索画面において、領域Ｗ１には、前述同様、構造化文書データベースの現在のツリー構造の要素名（タグ名）がユーザが理解可能なように簡略的に表示されている。
【０２３７】
領域Ｗ２は、検索対象の範囲（ツリー構造上の検索範囲）や、検索条件などを入力するための領域である。領域Ｗ３には、検索結果が表示される。
【０２３８】
例えば、「「ｕｉｘ：／／ｒｏｏｔ」以下の「特許」を先頭タグに持つ文書の中から、「タイトル」タグに「文書」という文字列を含み、「１９９８」年以降に作成された文書を検索せよ」という検索要求の場合には、領域Ｗ１から「ｒｏｏｔ」をマウス等で選択して検索対象の範囲として、構造化文書パスを入力する。そして、トップノードとして、「特許」を入力する（この場合、領域Ｗ１から「特許」をマウス等で選択することにより入力してもよい）。また、検索条件として、「「タイトル」という要素の値に「文書」という文字列を含む」「「年」という要素の値が「１９９８」以上である」という内容を予め設定されたデータ入力領域に入力すればよい。
【０２３９】
その後、「検索」ボタンＢ２１を選択することにより、例えば、図４５に示すようなクエリが、当該クエリを構造化文書データベース上に格納するための追加コマンドとともに構造化文書管理システムへ送信される。クエリの格納場所は、予め定められており、システム側が自動的に、この追加コマンドのパラメータを設定することとなる。例えば、構造化文書データベースが図１８に示した状態のとき、当該クエリの格納場所を表すパラメータとしての構造化文書パスは、「ｕｉｘ：／／ｒｏｏｔ／クエリＤＢ」となる。また、追加コマンドのもう一方のパラメータは、当該クエリ文書である。
【０２４０】
要求受付部１１は、上記クエリを受け付けると（ステップＳ１０１）、当該クエリを検索要求処理部３へ渡す。そして、当該クエリ文書を格納するための追加コマンドのパラメータを文書格納部２１へ渡す。この追加コマンドの処理を、前述同様に行って、当該クエリは、文書記憶部５に格納される。
【０２４１】
例えば、図４２に示すようなクエリの場合、構造化文書データベースには、図４６に示すように展開されて、構造化文書パス「ｕｉｘ：／／ｒｏｏｔ／クエリＤＢ」の示す「＃３０１」ノード以下にリンクされる。
【０２４２】
一方、検索要求処理部３では、受け取ったクエリを基に、データアクセス部４を通してインデックス記憶部６，文書記憶部５にアクセスし、検索要求に合致する文書集合などを取得して、クエリの中で要求された情報を抽出して結果処理部１２を介して出力する。
【０２４３】
例えば、上記クエリの場合、まず、「「タイトル」タグに「文書」という文字列を含む」という条件に合致するものを検索することが検索対象を絞り込む上で効率がよい。そこで、図１０に示したようなデータ生起インデックスを用いて、「文書」という文字列にリンクされているノード（文書オブジェクト）のオブジェクトＩＤを得る。そして、そのそれぞれについて、文書オブジェクトツリーを上流側に１つ遡り、「タイトル」というタグ名にたどり着いたときは、更に上流に辿っていき、「特許」というタグ名にたどり着いたときは、そのノード以下の文書オブジェクトツリーＯｔ１１を抽出する。
【０２４４】
次に、この抽出された複数の文書オブジェクトツリーＯｔ１１の中から、さらに、「年」という要素の値が「１９９８」年以上の文書オブジェクトツリーＯｔ１２を抽出する。
【０２４５】
この文書オブジェクトツリーＯｔ１２が上記クエリの内容に適合する文書となる。さらに上記クエリの要求内容に従えば、各文書オブジェクトツリーＯｔ１２のトップノードへの構造化文書パスを求める（ステップＳ１０２）。
【０２４６】
なお、上記検索処理は、上記した方法に限るものではなく、インデックス情報を用いた様々な効率のよい検索方法が可能である。
【０２４７】
検索要求処理部３は、ステップＳ１０２で得られた結果を統合して、検索結果としてのＸＭＬ文書を作成する（ステップＳ１０３）。
【０２４８】
例えば、検索結果のＸＭＬ文書は、
0003914081.tif 000002
となる。
【０２４９】
検索要求処理部３は、検索結果処理部１２を介して、上記ＸＭＬ文書をスタイルシートとともに、要求元のクライアント端末に返す（ステップＳ１０４）。
【０２５０】
クライアント端末では、図１１に示したＸＭＬ文書を、スタイルシートを用いてＨＴＭＬデータに変換して、例えば、図４４に示すように、領域Ｗ１２に表示する。
【０２５１】
同様にして、スキーマの検索も行える。
【０２５２】
例えば、「「ｕｉｘ：／／ｒｏｏｔ」以下の「ｓｃｈｅｍａ」を先頭タグに持つ文書の中から、「特許」と「要約」というタグ名を持つスキーマを検索せよ」という検索要求の場合には、図４７に示すように、領域Ｗ１から「ｒｏｏｔ」をマウス等で選択して検索対象の範囲として、構造化文書パスを入力する。そして、トップノードとして、「＃ｓｃｈｅｍａ」を入力する。また、検索条件として、「要素の属性名に「特許」という文字列を含む」「要素の属性名に「要約」という文字列を含む」という内容を予め設定されたデータ入力領域に入力すればよい。
【０２５３】
その後、「検索」ボタンＢ２１を選択することにより、上記検索要求を記述したクエリ（図４８参照）が、当該クエリを構造化文書データベース上に格納するための追加コマンドとともに構造化文書管理システムへ送信される。
【０２５４】
さて、上記クエリの場合、例えば、「「＃ｓｃｈｅｍａ」を先頭タグに持つ」という条件に合致するものを検索する。そこで、図９に示したような要素名称生起インデックスを用いて、「＃ｓｃｈｅｍａ」という要素にリンクされているノードの（文書オブジェクト）のオブジェクトＩＤを得る。そして、そのそれぞれについて、文書オブジェクトツリーを下流側にアークを辿っていき、属性名が「特許」と「要約」という要素にたどり着いたときは、当該「＃ｓｃｈｅｍａ」を先頭タグにもつ文書オブジェクトツリーＯｔ２１を抽出する。この文書オブジェクトツリーＯｔ２１が上記クエリの内容に適合する文書となる。さらに、図４８に示したクエリの要求内容に従えば、各文書オブジェクトツリーＯｔ２１のトップノードへの構造化文書パスを求める。
【０２５５】
検索要求処理部３は、文書オブジェクトツリーＯｔ２１が複数あれば、それぞれのトップノードへの構造化文書パスをまとめて、検索結果としてのＸＭＬ文書を作成し、検索結果処理部１２を介して、上記ＸＭＬ文書をスタイルシートとともに、要求元のクライアント端末に返す。
【０２５６】
クライアント端末では、検索結果として受け取ったＸＭＬ文書を、スタイルシートを用いてＨＴＭＬデータに変換して、例えば、図４４に示すように、領域Ｗ１２に表示する。
【０２５７】
クライアント端末では、検索結果の中の１つのスキーマを選択して、表示させると、例えば、図３８に示すような文書の格納／削除を行うための画面とともに、その領域Ｗ３に、「特許」情報のデータ入力領域が各要素毎に設定されて表示される。
【０２５８】
ユーザは、このデータ入力領域にデータを入力することで、スキーマにより定義された文書構造の格納文書が容易に作成することができる。
【０２５９】
例えば、図３８の領域Ｗ３に入力した「特許」情報の格納先として、領域Ｗ１で「特許ＤＢ」をマウス等を用いて選択すると、領域Ｗ２に構造化文書パスとして、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ」が表示される。その後、「登録」ボタンＢ１を選択すると、「ａｐｐｅｎｄＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ”，“＜特許＞…＜／特許＞”）」なる追加コマンドが構造化文書管理システムへ送信される。
【０２６０】
この場合、格納文書は、予めスキーマに従って入力されたものなので、図２０のステップＳ１０の妥当性チェックでエラーとなることはない。
【０２６１】
同様にして、クエリの検索も行える。クエリを検索して、検索結果として得られた既存のクエリを加工して、再利用することもできる（クエリの再利用）。
【０２６２】
クエリの検索は、前述したような構造化文書の検索と同様にして行われ、その検索範囲は、クエリ群の格納されている構造化データベース上の一部の文書オブジェクトツリーとなる。
【０２６３】
例えば、図１８に示したような状態の構造化文書データベースから、「ｋｆ：ｆｒｏｍ」タグに「特許ＤＢ」を含むクエリを検索する場合について説明する。そのような検索要求を記述したクエリを図４９に示す。
【０２６４】
図４９に示すクエリは、「「ｕｉｘ：／／ｒｏｏｔ／クエリＤＢ」の示す「＃３０１」ノード以下に存在するクエリの中から「ｋｆ：ｆｒｏｍ」タグに「特許ＤＢ」を含むクエリを検索し、その内容（タグ名が「ｑｕｅｒｙ」である要素以下の文書オブジェクトツリーの文書）を列挙せよ」を意味するものである。
【０２６５】
なお、「ｋｆ：ａｓ」タグの内容で変数「＄ｅｌｔ」に、「ｋｆ：ｆｒｏｍ」タグに「特許ＤＢ」を含むクエリのタグ名が「ｑｕｅｒｙ」である要素以下の文書オブジェクトツリーが代入される。
【０２６６】
このクエリを検索要求処理部３が処理する際には、前述同様にして、例えば、図９に示したような要素名称生起インデックスを用いて、「ｋｆ：ｆｒｏｍ」という要素にリンクされているノードの（文書オブジェクト）のオブジェクトＩＤを得る。そして、そのそれぞれについて、文書オブジェクトツリーを下流側にアークを辿っていき、「特許」というタグ名にたどり着いたときは、さらに、上流側にアークを辿って「ｑｕｅｒｙ」というタグ名に辿りついたとき、当該「ｑｕｅｒｙ」を先頭タグにもつ文書オブジェクトツリーＯｔ３１を抽出する。この文書オブジェクトツリーＯｔ３１が上記クエリの内容に適合する文書となる。
【０２６７】
複数の文書オブジェクトツリーＯｔ３１が検索されたら、それらを統合して、ＸＭＬ文書を作成して、それをスタイルシートとともにクライアント端末へ返す。
【０２６８】
クライアント端末では、検索結果の中の１つのクエリを選択して、表示させると、例えば、図４４に示した検索画面の領域Ｗ１１に、各データ入力領域にデータの入力された状態で、当該クエリに記述された検索要求の内容が表示される。
【０２６９】
ユーザは、この状態から、「「ｕｉｘ：／／ｒｏｏｔ」以下の「特許」を先頭タグに持つ文書の中から、「タイトル」タグに「文書」という文字列を含み、「１９９８」年以降に作成された文書を検索せよ」という当該クエリに記述された検索要求中の「文書」を「ＸＭＬ」に変更して、「検索」ボタンＢ２１を選択すれば、「「ｕｉｘ：／／ｒｏｏｔ」以下の「特許」を先頭タグに持つ文書の中から、「タイトル」タグに「ＸＭＬ」という文字列を含み、「１９９８」年以降に作成された文書を検索せよ」という意味のクエリが構造化文書管理システムへ送信される。
【０２７０】
以上説明したように、図１の構造化文書管理システムでは、構造化文書データベース上に登録される文書構造が異なる膨大な数のＸＭＬ文書群（コンテンツ文書、スキーマ文書、クエリ文書など）を、図１８，図１９に示すように、「ｒｏｏｔ」タグを先頭に持つツリー状の１つの巨大なＸＭＬ文書として取り扱う。従って、文書構造が異なる、様々なスキーマを持つ膨大な数の文書の中から検索条件に合致する文書を容易に検索できる。
【０２７１】
また、検索に用いるクエリも構造化文書であるので、構造化文書データベースにログとして格納することにより、過去のクエリを再利用するようなアプリケーションも容易に構築することができる。
【０２７２】
（３）適用例
次に、上記概念検索の特許調査への適用例について説明する。
【０２７３】
図５０は、特許調査における構造化文書データベースの一例であり、「特許」情報の他に、「概念」情報も格納している。
【０２７４】
特許調査において、最も重要となってくる作業は、関連する「特許」情報を収集し、「特許」情報を様々な観点から分析し、特許マップ（図５４参照）を作成することである。特許マップを作成するために、従来、特許マップにおける縦軸、横軸を予め決定し、それに従い、縦軸に並ぶ任意の項目と横軸に並ぶ任意の項目とを検索条件とした検索を逐次行うという方法がとられ、この部分に非常に莫大なコストがかかっていた。しかし、本発明の構造化文書管理システムを用いることで、この部分のコストを大幅に減少させることが可能となる。
【０２７５】
なお、ここで、マップとは、縦軸（ｙ軸）に並ぶ任意の項目と横軸（ｘ軸）に並ぶ任意の項目とを検索条件とした検索結果をｘ軸とｙ軸とを分類軸として分類整理するものである。
【０２７６】
本発明の構造化文書管理システムで、クライアント端末のユーザが図５４に示すような特許マップを作成しようとする場合、ユーザは、クライアント端末上の表示装置に表示される図５０に示すような構造化文書データベースの現在のツリー構造を参照して、図５１に示すような検索画面上に、分析対象の範囲とする「特許」情報のパスと、分析の軸（例えば、ｘ軸、ｙ軸）となる要素を、それぞれ領域Ｗ２１、Ｗ２２に入力する。分析の軸となる要素は、構造化文書データベース内の「特許」情報の要素、「概念」情報の要素のいずれであってもよい。
【０２７７】
例えば、図５１では、ｘ軸に「機能」、ｙ軸に「技術」という「概念」情報の要素を入力している。
【０２７８】
その後、ユーザは、「実行」ボタンＢ３１を選択すると、クライアント端末から図１の構造化文書管理システムへ、図５２に示したようなクエリが送出される。
【０２７９】
この場合のクエリには、「「特許ＤＢ」アークが示すノード以下に格納されている「特許」情報の文書群の中から、「概念ＤＢ」アークが示すノード以下に格納されている、概念「機能」の子要素のいずれかと概念「技術」の子要素のいずれかとを、「キーワード」や「要約」などの要素の値に含む「特許」情報を検索せよ。検索結果として、「機能」の子要素と「技術」の子要素と、それらに対応する「特許」情報の「公開番号」との組を列挙せよ。」という意味の検索要求である。
【０２８０】
概念「機能」には、「検索」「格納」…「分析支援」という子要素があり、概念「技術」には、「実装データベース」「反構造データベース」「自然言語処理」…という子要素があるものとする。
【０２８１】
上記クエリを受けた構造化文書検索システムの検索要求処理部３では、例えば、図１０に示したようなデータ生起インデックスを用いて、概念「機能」の各子要素（文字列）にリンクされているノード（文書オブジェクト）のオブジェクトＩＤを得る。そして、そのそれぞれについて、文書オブジェクトツリーを上流側に遡り、「特許」というタグにたどり着いたときは、さらに、そのノード以下の文書オブジェクトツリーを下流側に辿って概念「技術」の子要素（文字列）のいずれかにリンクされているタグ名にたどり着いたときは、当該文書オブジェクトツリーと、その「公開番号」タグにリンクされている文字列（要素値）を抽出する。このようにして、抽出された「特許」情報のそれぞれについて、対応の「機能」の子要素と「技術」の子要素と「公開番号」との組を統合して、図５３に示すような検索結果としてのＸＭＬ文書を作成、要求元のクライアント端末へ、所定のスタイルシートとともに返す。
【０２８２】
これらを受け取ったクライアント端末の表示装置には、図５４に示したような表形式の特許マップが表示されることになる。
【０２８３】
このように、所望の概念を「軸」として指定するだけで、構造化文書データベースに蓄積された情報を「軸」として指定された概念に基づき集計・分類して、マップ表示することが容易に行える。すなわち、構造化文書データベースに蓄積された情報を、「概念」情報を用いて様々な観点で集計・分類することが容易に行える。
【０２８４】
（アクセス権限の設定）
ここでは、図２に示した利用形態（ＷＷＷのバックエンドで、図１に示した構成の構造化文書管理システム１００が動作する利用形態）の場合を例にとり説明する。すなわち、図２に示すように、複数（ここでは、例えば３つ）のクライアント端末１０２のそれぞれでＷＷＷブラウザ１０３が動作しており、ユーザは、各クライアント端末からＷＷＷサーバ１０１にアクセスすることにより、構造化文書管理システム１００にアクセスすることができる。
【０２８５】
ユーザからの文書格納、文書取得、文書検索などの要求は、ＷＷＷブラウザ１０３から送信されて、ＷＷＷサーバ１０１を通して構造化文書管理システム１００にて受け付けられ、処理された結果は、ＷＷＷサーバ１０１を通して要求元のＷＷＷブラウザ１０３へ返信される。
【０２８６】
クライアント端末装置１０２の要部の構成例を図５５に示す。
【０２８７】
クエリの実行結果としてのＸＭＬ文書は、スタイルシートとともに、構造化文書管理システム１００からクライアント端末装置１０２に送られてくるものとする。以下、図５６、図５７に示すフローチャートを参照して、図５５の各構成部の処理動作について説明する。
【０２８８】
クエリは、前述したように、検索位置、検索条件、情報抽出部分などを記述した、構造化されたＸＭＬ文書である。クエリ文書も本発明の構造化文書管理システムの管理対象である。ここで、構造化文書データベースに対しその論理構造に基づき所望の構成要素を検索するクエリを例にとり説明する。
【０２８９】
ＸＭＬ文書受信部１１１で、構造化文書管理システム１００から送られてきた検索結果文書である表示対象のＸＭＬ文書と、スタイルシートとを受信すると（図５６のステップＳ２０１）、ＸＭＬ／ＨＴＭＬ変換部１１２では、受信したスタイルシートを用いて、受信した表示対象のＸＭＬ文書をＨＴＭＬ文書に変換する（ステップＳ２０２）。その変換処理中、テーブル作成部１１３は、ＨＴＭＬ文書中の記述部分と、その記述部分を生成したスタイルシート中の記述部分との対応関係を示したテーブル、すなわち、対応テーブル１１４を作成する（ステップＳ２０３、ステップＳ２０４）。
【０２９０】
構造化文書管理システム１００から送られてくるスタイルシートの各記述部分には予め識別子ＳＩＤが与えられているものとする。例えば、この識別子ＳＩＤは、コメント文（コメント文でなくとも、ブラウザでは表示されない記述形式の文）として、予めスタイルシートに書き込まれていてもよい。
【０２９１】
テーブル作成部１１３は、まず、ＸＭＬ／ＨＴＭＬ変換部１１２での変換作業中に、得られたＨＴＭＬ文書の各記述部分のそれぞれに識別子ＨＩＤを与える。そして、ＨＴＭＬ文書中の記述部分と、その記述部分を生成したスタイルシート中の記述部分との対応関係をＳＩＤとＨＩＤを用いて表した対応テーブル１１４を作成する。
【０２９２】
描画部１１５では、ＸＭＬ／ＨＴＭＬ変換部１１２で生成されたＨＴＭＬ文書を基に表示データを作成し、その表示データは、ディスプレイ装置１２１に表示される（ステップＳ２０５）。その際、描画部１１５は、ＨＴＭＬ文書中の記述部分とその記述部分に与えられた識別子ＨＩＤとの対応を記憶しておいてもよい。
【０２９３】
アクセス権限の設定は、ディスプレイ装置１２１の表示画面を基に行う。
【０２９４】
例えば、ユーザがアクセス権限の設定開始の所定の指示操作を入力部１１６で行うと、アクセス権限設定部１１７が起動される。まず、表示画面上でアクセス権限を設定する領域の選択が行われる（ステップＳ１１１）。すなわち、マウス等の入力装置１２２を用いて、表示対象の文書が表示されたディスプレイ装置１２１の表示画面上で、アクセス権限を設定したい文字列（テキスト）や画像などの表示領域の選択を行う。
【０２９５】
アクセス権限を設定したい表示領域がマウス等で選択されれば、描画部１１５でその指定された領域に文字列や画像などを表示するＨＴＭＬ文書中の記述部分を検知することができる。この検知されたＨＴＭＬ文書中の記述部分に対応する識別子ＨＩＤがアクセス権限設定部１１６に渡される（ステップＳ１１２）。
【０２９６】
アクセス権限設定部１１６は、描画部１１５で検知されたＨＴＭＬ文書中の記述部分の識別子ＨＩＤから、対応テーブル１１４を参照して、当該識別子ＨＩＤに対応するスタイルシートの記述部分の識別子ＳＩＤを得る（ステップＳ１１３）。
【０２９７】
さらに、クライアント端末装置１０２のアクセス権限設定部１１７では、アクセス権限の設定されるユーザの範囲や、アクセスレベルや、アクセスタイプなどをユーザに入力してもらうための入力画面を表示して、アクセス権限の設定のために必要な上記各情報を収集する（ステップＳ１１４〜ステップＳ１１６）。上記各情報の入力が終了すると、それらは、識別子ＳＩＤとともに、送信部１１８を介して構造化文書管理システム１００へ送信される（ステップＳ１１７）。
【０２９８】
なお、図５５に示した構成部のうち、テーブル作成部１１３，対応テーブル１１４，アクセス権限設定部１１６以外は、ほぼ従来技術に属するものである。
【０２９９】
次に、図１のアクセス権限設定管理部２０１について、図５８を参照して説明する。図５８は、アクセス権限設定管理部２０１の機能ブロック図である。
【０３００】
アクセス権限設定管理部２０１は、アクセス権限設定部２０２とアクセス権限管理部２０１とから構成され、アクセス権限設定管理部２０１は、スキーマアクセス権限管理部２１１と、データアクセス権限管理部２１２と、クエリアクセス権限管理部２１３と、スタイルアクセス権限管理部２１４と、パスアクセス権限管理部２１５とから構成されている。
【０３０１】
アクセス権限設定部２０２は、クライアント端末装置１０２から送信されてきた、上記ＳＩＤや、アクセス権限の設定されるユーザの範囲や、アクセスレベルや、アクセスタイプなどの情報を基に、実際に、アクセス権限の設定を行うようになっている。
【０３０２】
アクセス権限管理部２０１では、上記アクセス権限設定部２０２で設定された、各レベル（スキーマ、データ、クエリ、スタイル、パス）のアクセス権限の管理を行うためのものである。
【０３０３】
図５９は、構造化文書データベースの論理構造の一部を模式的に示したものである。構造化文書データベースに新たにＸＭＬ文書を登録していくと、それら各ＸＭＬ文書は、「ｒｏｏｔ」という１つの大きなＸＭＬ文書の部分文書として参照できる構成になっている。図５９に示した構造化文書データベースでは、ＸＭＬ文書としての「報告書」情報は、「報告書ＤＢ」ノード以下に格納され、同じくＸＭＬ文書としての「従業員」情報は、「従業員ＤＢ」ノード以下に格納され、同じくＸＭＬ文書としての「特許」情報は、「特許ＤＢ」ノード以下に格納されている。
【０３０４】
図６０は、ＸＭＬで記述された構造化文書の一例として、「報告書ＤＢ」ノード以下の上記「報告書」情報に対応する１つの部分文書を示したものであり、図６１は、「従業員ＤＢ」ノード以下の上記「従業員」情報に対応する３つの部分文書を示したものである。
【０３０５】
図６２は、クライアント端末装置１０２のディスプレイ装置１２１の画面表示例を示したもので、クライアント端末装置１０２から入力されたクエリを実行した結果得られたＸＭＬ文書（検索結果文書）の表示例を示している。
【０３０６】
前述したように、クエリの「ｋｆ：ｆｒｏｍ」タグから始まる要素には、検索位置の指定と文書要素の値に変数を対応付ける記述があり、「ｋｆ：ｗｈｅｒｅ」タグから始める要素には、変数に関する条件づけの記述があり、「ｋｆ：ｓｅｌｅｃｔ」タグから始まる要素には、検索結果の出力形式が記述される。クエリを実行することより、単純検索の場合には、クエリ中に指定された検索条件を満たす情報を検索・抽出し、概念検索の場合には、クエリ中に指定された概念情報を利用して、クエリ中に指定された検索条件を満たす情報を検索・抽出する。そして、検索要求処理部３では、抽出された情報（構成要素）を、「ｋｆ：ｓｅｌｅｃｔ」タグから始まる要素の記述に従った形式の情報に合成・加工し、その結果得られたＸＭＬ文書を結果処理部１２を介して、要求元のクライアント端末装置１０２に所定のスタイルシートとともに送信する。要求元のクライアント端末装置１０２では、構造化文書管理システム１００から送られてきたクエリの実行結果としてのＸＭＬ文書（検索結果文書）を図５６のフローチャートに従って、図６２に示すように表示する。なお、検索結果文書は、クエリ中の検索条件の記述によっては、上記のように、構造化文書データベース中の複数の構造化文書から生成された加工された文書である場合も、構造化文書データベース中の構造化文書そのものである場合もあり得る。
【０３０７】
この状態において、クライアント端末装置１０２では、アクセス権限の設定が行える。
【０３０８】
クライアント端末装置１０２上でのアクセス権限の設定を行うための操作手順の概略を説明する。
【０３０９】
（ａ）表示画面からアクセス権限の設定を行いたい文字列や画像などの表示されている領域を指定（選択）する。ここで、指定される文字列や画像などは、構造化文書データベース中のＸＭＬ文書を構成する要素の要素名や要素値に対応するものである。
【０３１０】
（ｂ）アクセス権限を設定するユーザの範囲を指定（選択）する。アクセス権限は、ユーザ１人１人に対し設定することも、複数のユーザからなる特定のグループ単位に（例えば、会社組織上の所属部署単位に）設定することも可能であるとする。前者を個人に対するアクセス権限の設定と呼び、後者をグループに対するアクセス権限の設定と呼ぶ。
【０３１１】
（ｃ）アクセスレベルを指定（選択）する。アクセスレベルには、ここでは、スタイル、クエリ、データ、スキーマ、パスがある。スタイルレベルは、スタイルシート毎にアクセス権限を設定するもので、表示形式が異なれば、同じ構成要素であっても表示されたりされなかったりすることがあり得る。また、クエリレベルは、クエリ文書毎にアクセス権限を設定するもので、クエリレベルでアクセス権限を設定すると、このレベルでアクセスが制限されたユーザに対しては、同じ構成要素であっても、その構成要素を得るために用いたクエリに応じて（すなわち、当該構成要素の用途が異なれば）、表示されたりされなかったりすることがあり得る。また、データレベルは、構造化文書データベースに格納されている検索対象のＸＭＬ文書中の構成要素に対しアクセス権限を設定するもので、このレベルでアクセスが制限されたユーザからは、その構成要素に対しては、たとえ、クエリやスタイルが異なっても、アクセス不可能である（見ることはできない）。さらに、スキーマレベル、パスレベルは、構造化文書データベース中の同じ文書構造を持つ構造化文書中の同じ要素名の構成要素に対しアクセス権限を設定するもので、このレベルでアクセスが制限されたユーザからは、そのような構成要素に対しては、たとえ、クエリやスタイルが異なっても、アクセス不可能である（見ることはできない）。
【０３１２】
（ｄ）上記（ａ）で指定した領域に表示されるデータの表示方法（ここでは、アクセス態様あるいはアクセスタイプと呼ぶ）を指定（選択）する。アクセスタイプとして、大きく分けると、その表示領域に何も表示しなかったり、黒く塗り潰して表示したりと、そこに表示されているデータがあるのかないのかもわからないようにする非表示にする場合と、特殊な表示を行う場合（特殊表示）とが設定可能である。特殊表示とは、その表示領域には、何らかのデータが表示されているが、それが何であるかが判別できないように表示を行うもので、例えば、上記（ａ）で指定した領域に表示される文字列や画像などを伏せ字で表示したり、モザイクをかけて表示したりすることである。伏せ字で表示するのか、モザイクなどをかけて表示するのかなどは選択可能であり、また、伏せ字を選択した場合は、どのような伏せ字を用いるかも（例えば「○」「×」など）選択可能である。
【０３１３】
さて、図６２に示すように、クライアント端末装置１０２の表示画面には、上記のようにして、表示対象のＸＭＬ文書が表示されている。すなわち、「報告書」情報の構成要素である「報告番号」、「タイトル」、「報告者」、「報告日」、「要約」、「代表図」と、本文へのリンクが表示され、さらに、「従業員」情報の構成要素である「報告者プロフィール」などの情報が表示されている。このように、ここで表示されているＸＭＬ文書は、構造化文書データベースに格納されている検索対象の複数のＸＭＬ文書のそれぞれに含まれる構成要素を合成したものである。
【０３１４】
表示画面に表示されているデータは、あくまでも表示データであって（例えば、上記の例の場合、複数のＸＭＬ文書から抽出された構成要素を合成したもの）、構造化文書データベースには、表示画面通りの構造のＸＭＬ文書が存在しているわけではない。そこで、構造化文書管理システム１００のアクセス権限設定管理部２０１では、ユーザにより、アクセスレベルとして、例えば、「データ」が指定されたときには、表示形式を基に逆に遡り構造化文書データベース中の元のデータを特定し、アクセス権限の設定を行うようになっている。
【０３１５】
では、実際に、図６２の表示からアクセス権限を設定する方法について述べる。図６２の表示は、構造化文書データベース中の複数のＸＭＬ文書の構成要素をクエリにより合成した（加工した）結果得られたＸＭＬ文書を、スタイルシートを通して、ＨＴＭＬ形式に変換したものをブラウザで表示したものである。表示対象のＸＭＬ文書を図６３に示す。また、適用しているスタイルシートを図６４に示す。
【０３１６】
図６３に示したＸＭＬ文書をＨＴＭＬ文書に変換する際には、前述したように、ＨＴＭＬ文書の各記述部分（例えば、表示対象の文字列などを所定のタグで囲んだもの）のそれぞれに識別子ＨＩＤが与えられるが、図６５に、その様子を示す。図６５には、ＨＴＭＬ文書そのものではなく、説明の簡単のため、ＨＴＭＬ文書中のどのような記述部分にどのような識別子ＨＩＤが与えられたかを、そのＨＴＭＬ文書を表示した図６２と同じ表示画面上で示したものであって、各記述部分に対し識別子ＨＩＤ（ここでは、例えば、ＨＩＤ１〜ＨＩＤ１８）を符号として示している。ここでは、識別子ＨＩＤの与えられたＨＴＭＬ文書中の１つの記述部分は、１つの表示領域に対応する。すなわち、図６５に示すように、１つの表示窓（テキストボックス）に対し１つの記述部分が対応し、ＨＩＤが与えられているものとする。
【０３１７】
クライアント端末装置１０２のＸＭＬ／ＨＴＭＬ変換部１１２では、図５６のステップＳ１０２において、図６３に示したＸＭＬ文書に、図６４に示したスタイルシートを適用して、図６５に示したように表示されるＨＴＭＬ文書を作成するようになっている。その際、図５６のステップＳ２０３に示したように、テーブル作成部１１３は、図６６に示すような対応テーブル１１４を作成する。
【０３１８】
例えば、図６５において、識別子「ＨＩＤ６」の与えられているＨＴＭＬ文書中の記述部分は、「報告者」という文字列を表示領域３０６（図６２参照）に表示するものであって、識別子「ＨＩＤ７」の与えられているＨＴＭＬ文書中の記述部分は、「山田太郎」という文字列を表示領域３０７（図６２参照）に表示するものである。この２つの記述部分は、図６４に示したスタイルシートの識別子「ＳＩＤ４」の与えられている記述部分の記述に従って図６３のＸＭＬ文書の６行目に記述されている要素から生成されたものである。従って、クライアント端末装置１０２のテーブル作成部１１３は、図６６に示したように、ＨＩＤ６，ＨＩＤ７には、それぞれＳＩＤ４が対応付けられている。なお、図６６の対応テーブルでは、ＨＩＤのそれぞれに対し、「ｔｙｐｅ」という項目によって、その要素は、変換前のＸＭＬ文書中では、要素名であったものか、要素値であったものかを区別している。
【０３１９】
図８８は、図６５に示した表示画面に対応するＨＴＭＬ文書の一部を示したものである。例えば、図６５に示した、識別子「ＨＩＤ１」「ＨＩＤ２」「ＨＩＤ３」「ＨＩＤ６」「ＨＩＤ７」の与えらた記述部分の一例を示している。これら記述部分には、それらの符号として識別子「ＨＩＤ１」「ＨＩＤ２」「ＨＩＤ３」「ＨＩＤ６」「ＨＩＤ７」を示している。
【０３２０】
例えば、表示領域３０７に「山田太郎」という文字列を表示するための、図８８に示したＨＴＭＬ文書の記述部分（識別子「ＨＩＤ７」の与えられている記述部分）のように、「報告書」「報告番号」「報告者」などの項目名（要素名である場合もある）以外のＸＭＬ文書の要素値が表示される表示領域（例えば、表示領域３０７など）に対応する記述部分には、そのような記述部分がマウス等により指示（選択）されたとき、描画部１１５に、当該表示領域が指示された旨を通知するためのイベント関数「ｆｕｎｃ（）」が埋め込まれているものとする。
【０３２１】
このような関数の埋め込みは、図６４に示したスタイルシートにて指示することができる。すなわち、例えば、識別子「ＨＩＤ７」の与えられているＨＴＭＬ文書の記述部分に上記関数を埋め込むための指示は、図６４に示したスタイルシートの記述部分４０１には記述されている。
【０３２２】
このように、公知のスタイルシートを用いることにより、表示対象のＸＭＬ文書をＨＴＭＬ文書に変換する際に、識別子ＨＩＤの与えられたＨＴＭＬ文書中の１つの記述部分に、１つの表示領域を対応させ、その表示領域がマウス等で指示されたとき、描画部１１５に、当該表示領域が指示（選択）された旨を通知するためのイベント関数「ｆｕｎｃ（）」を埋め込むことができる。
【０３２３】
描画部１１５は、イベント関数により、ユーザにより指示（選択）された表示領域がどれであるか、また、その表示領域のＨＩＤは何であるかを検知することができる。
【０３２４】
さて、図６２に示したような表示が行われている状態で、ユーザが、アクセス権限の設定開始の所定の指示操作を入力部１１６を介して行うと、アクセス権限設定部１１７が起動される。まず、図５７のステップＳ１１１に示したように、アクセス権限を設定する領域の選択を行う。
【０３２５】
例えば、図６２の表示画面上の、「山田太郎」という文字列の表示されている、その文字列を表示するために予め定められた表示領域（テキストボックス）３０７が、マウス等を用いて選択されたとする。この選択されたテキストボックスを表示するためのＨＴＭＬ文書中の記述部分の識別子は、「ＨＩＤ７」である。描画部１１５は、これを検知すると、当該識別子「ＨＩＤ７」をアクセス権限設定部１１６へ渡す（図５７のステップＳ１１２）。
【０３２６】
アクセス権限設定部１１６は、対応テーブル１１４を参照して、「ＨＩＤ７」に対応するスタイルシート中の記述部分の識別子を取得する（図５７のステップＳ１１３）。この場合、図６６から「ＳＩＤ４」が得られる。
【０３２７】
次に、アクセス権限を設定するユーザの範囲の選択を行う（図５７のステップＳ１１４）が、その際、アクセス権限設定部１１６は、図６７に示したようなウインドウを表示してもよい。このウインドウ上で、ユーザは、個人あるいはグループを選択し、個人を選択した場合には、さらに、その個人を特定するユーザ名を選択すればよい。ここでは、ユーザの範囲として、例えば「山田太郎」という個人が選択されたとする。
【０３２８】
次に、アクセスレベルの選択を行う（図５７のステップＳ１１５）が、その際、アクセス権限設定部１１６は、図６８に示したようなウインドウを表示してもよい。このウインドウ上で、ユーザは、スタイル、クエリ、データ、スキーマ、パスのいずれかを選択すればよい。
【０３２９】
さらにアクセスタイプの選択を行う（図５７のステップＳ１１６）が、その際、アクセス権限設定部１１６は、図６９に示したようなウインドウを表示してもよい。このウインドウ上で、ユーザは、「非表示」か「特殊表示」のいずれかを選択すればよい。「特殊表示」を選択した場合には、さらに、伏せ字、モザイクのうちのいずれかを選択すればよい。
【０３３０】
最後に、ユーザによりアクセス権限設定完了を指示する所定の操作が行われると、上記のようにして収集された情報は、アクセス権限設定要求とともに、クライアント端末装置１０２から、構造化文書管理システムへ送信される（図５７のステップＳ１１７）。構造化文書管理システムでは、要求制御部１で上記アクセス権限設定要求を受け取ると、それをアクセス権限設定管理部２０１に出力する。
【０３３１】
アクセス権限設定要求には、例えば、クライアント端末装置１０２でアクセス権限の設定対象となった（表示対象の）ＸＭＬ文書、そのＸＭＬ文書を画面表示する際に用いたスタイルシート、さらに、そのＸＭＬ文書を得るために用いたクエリを特定するための情報が含まれていることが望ましい。
【０３３２】
次に、図７０〜図７１に示すフローチャートを参照して、アクセス権限設定管理部２０１の処理動作について説明する。
【０３３３】
アクセス権限設定管理部２０１に、アクセス権限設定要求とともに、クライアント端末装置１０２から送られてきた、ＳＩＤ、ユーザの範囲、アクセスレベル、アクセスタイプが入力されると（ステップＳ１２１）、まず、アクセス権限設定要求を基に、そのアクセス権限設定要求にて特定しているスタイルシート中の当該ＳＩＤ対応の記述部分に関連付けられた、表示対象のＸＭＬ文書中の要素のパスを取得する（ステップＳ１２２）。例えば、図５７のステップＳ１１１において、識別子「ＨＩＤ７」の付されたＨＴＭＬ文書中の記述部分に対応する表示領域が選択されて、識別子「ＨＩＤ７」に対応する図６４に示したスタイルシート中の記述部分の識別子「ＳＩＤ４」が、図７０のステップＳ１２１で入力したとする。このとき、図６４に示したスタイルシート中の識別子「ＳＩＤ４」の付された記述部分は、「＜ｘｓｌ：ｖａｌｕｅ−ｏｆ  ｓｅｌｅｃｔ＝“／報告者／名前”／＞」である。この記述部分において、「“／報告者／名前”／」は、表示対象のＸＭＬ文書（検索結果文書）中の当該要素のパスの一部を表したものである。また、当該スタイルシートを「ＳＩＤ４」の付された記述部分から上の行に辿っていくと、「ＳＩＤ１」の付された記述部分には、「“／報告者／名前”／」の上流のパスとして、「”／報告書リスト／報告書／“」が記述されている。従って、当該スタイルシートの「ＳＩＤ４」対応の記述部分に関連付けられた、表示対象のＸＭＬ文書中の当該要素の全体としてのパスは「”／報告書リスト／報告書／報告者／名前”」であることがわかる。また、上記例の場合、識別子「ＨＩＤ７」の付されたＨＴＭＬ文書中の記述部分に対応する表示領域には、「山田太郎」が表示されていた。従って、「”／報告書リスト／報告書／報告者／名前”」というパスにて特定される要素であって、その要素値が「山田太郎」である要素が、検索結果文書中のアクセス権限を設定する箇所（構成要素）である。これをもとに、以後、指定されたアクセスレベルに応じて、構造化文書データベースを探索していく。
【０３３４】
アクセスレベルがスタイルと指定されていた場合（ステップＳ１２３）、アクセス権限設定部２０２は、アクセス権限設定管理部２０３のスタイルアクセス権限管理部２１４に格納されている、図７２に示すようなスタイルアクセス権限テーブルに、指定されたアクセス権限を登録する（ステップＳ１２４）。スタイルアクセス権限テーブルは、図７２に示すように、複数種類あるスタイルシートのうちのどれであるかを識別するためのスタイルシートの識別子毎に、そのスタイルシート中のアクセス権限の設定された記述部分を示すＳＩＤとユーザ範囲とアクセスタイプとが登録されるようになっている。例えば、アクセス権限を設定しようとしているスタイルシートの識別子が「ＳＳＩＤ１」であるとすると、スタイルシート中の識別子「ＳＩＤ４」の付された記述部分に対し、ユーザ範囲として「グループＢ」というグループに、アクセスタイプとして「非表示」がアクセス権限として設定されたことになる。
【０３３５】
アクセスレベルがスタイルでないときは、次に、ステップＳ１２５へ進む。
【０３３６】
上記ステップＳ１２２において、表示対象のＸＭＬ文書（検索結果文書）中の「”／報告書リスト／報告書／報告者／名前”」というパスで特定され、しかも要素値が「山田太郎」である要素が取得された。すなわち、これは、図６３に示した表示対象のＸＭＬ文書中において、第６行目に記述されている要素が特定されたことになる（ステップＳ１２５）。
【０３３７】
図６３に示したＸＭＬ文書は、図７７に示すようなクエリを実行することにより得られたＸＭＬ文書である。なお、図７７に示したクエリの識別子を「ＱＲＹ１」であるとする。そこで、このクエリを基に、構造化文書データベース中のリソースを検索する。
【０３３８】
次に、クエリを解析して、当該クエリから上記ステップＳ１２５で得た要素のパスに対応する記述部分を取得する（ステップＳ１２６）。例えば、図７７に示したクエリと、このクエリを実行することにより得られた図６３に示したＸＭＬ文書とを参照して、クエリの解析方法について説明する。なお、構造化文書データベースに格納されている全てのクエリの各記述部分には予め識別子ＱＩＤが与えられているものとする。
【０３３９】
まず、図６３の６行目に記述されている要素「＜名前＞山田太郎＜／名前＞」の当該ＸＭＬ文書中でのパスは、「報告書／報告者／名前」であることがわかっているので、クエリにおいて、この要素を作り出している部分に着目する。これはクエリの出力形式の記述部、すなわち、＜ｋｆ：ｓｅｌｅｃｔ＞タグで囲まれた記述部を調べることでわかる。この場合、図７７において、当該＜ｋｆ：ｓｅｌｅｃｔ＞タグで囲まれた記述部で定めた記述形式（文書構造）から、先ほどの「＜名前＞山田太郎＜／名前＞」という要素を作り出した記述部分は、識別子「ＱＩＤ５」の付された「＜名前＞＄ｎａｍｅ＜／名前＞」であることが容易に判別できる。
【０３４０】
アクセスレベルがクエリと指定されていた場合（ステップＳ１２７）、アクセス権限設定部２０２は、アクセス権限設定管理部２０３のクエリアクセス権限管理部２１３に格納されている、図７３に示すようなクエリアクセス権限テーブルに、指定されたアクセス権限を登録する（ステップＳ１２８）。クエリアクセス権限テーブルは、図７３に示すように、複数種類あるクエリのうちのどれであるかを識別するためのクエリの識別子毎に、そのクエリ中のアクセス権限の設定された記述部分を示すＱＩＤとユーザ範囲とアクセスタイプとが登録されるようになっている。例えば、上記例の場合、アクセス権限を設定しようとしているクエリの識別子が「ＱＲＹ１」であるとすると、当該クエリ中の識別子「ＱＩＤ５」の付された記述部分に対し、ユーザ範囲として「グループＢ」というグループに、アクセスタイプとして「非表示」がアクセス権限として設定されたことになる。
【０３４１】
さて、次に、当該クエリの記述に基づき、構造化文書データベース中から、ステップＳ１２５で得られた要素、すなわち、「＜名前＞山田太郎＜／名前＞」の格納されている箇所（パス）を探索する（ステップＳ１２９）。ここでは、まず、当該クエリ中の＜ｋｆ：ｆｒｏｍ＞タグで囲まれた記述部から、変数「＄ｎａｍｅ」が要素の値として関連付けられている記述部分を探索する。この場合、１６行目と２２行目の記述部分において、変数「＄ｎａｍｅ」が要素「報告者」「名前」のそれぞれの要素値に関連付けられている。すなわち、「ＱＩＤ５」の付された記述部分「＜名前＞＄ｎａｍｅ＜／名前＞」は、＜ｋｆ：ｆｒｏｍ＞タグで囲まれた記述部において、「”ｕｉｘ：／／ｒｏｏｔ／報告書ＤＢ”」以下にある「＜報告者＞＄ｎａｍｅ＜／報告者＞」および「”ｕｉｘ：／／ｒｏｏｔ／従業員ＤＢ”」以下にある「＜名前＞＄ｎａｍｅ＜／名前＞」を出力結果として出力するための記述であることがわかる。また、変数「＄ｎａｍｅ」はテキストであり、「山田太郎」が指定されているので、これを条件として更にデータベース中のパスを検索する。
【０３４２】
そこで、アクセス権限設定部２０２は、図７８に示すような、構造化文書データベースの「”ｕｉｘ：／／ｒｏｏｔ／報告書ＤＢ”」以下から、「山田太郎」という値を持つ「報告者」という構成要素のパスを検索するためのクエリと、図７９に示すような、構造化文書データベースの「”ｕｉｘ：／／ｒｏｏｔ／従業員ＤＢ”」以下から、「山田太郎」という値を持つ「名前」という要素名の構成要素へのパスを検索するためのクエリとを生成して（発行して）、それを検索要求処理部３へ送る。
【０３４３】
なお、上記例の場合、図６５の表示画面上の、ＨＩＤ７の「山田太郎」という文字列の表示されているテキストボックスがアクセス権限を設定する領域として指定されたので、これに対応するように、図７８，図７９に示したクエリでは要素値「山田太郎」をもつ構成要素を検索条件としているが、もし、ＨＩＤ６の「報告者」という文字列の表示されているテキストボックスが指定されているのであれば、要素値「山田太郎」をもつ構成要素を検索条件とする必要がない。すなわち、＜ｋｆ：ｗｈｅｒｅ＞タグで囲まれた記述部は必要ない。
【０３４４】
検索要求処理部３では、前述したようにして、各クエリに記述された検索条件に基づき、構造化文書データベースを検索する。すると、図８０に示すように、「”ｕｉｘ：／／ｒｏｏｔ／報告書ＤＢ”」以下にある「山田太郎」という値を持つ「報告者」という要素名の構成要素３０１へのパスと、「”ｕｉｘ：／／ｒｏｏｔ／従業員ＤＢ”」以下から、「山田太郎」という値を持つ「名前」という要素名の構成要素３０２へのパスを取得することができる。
【０３４５】
例えば、構成要素３０１のパスが、「ｕｉｘ：／／ｒｏｏｔ／報告書ＤＢ／報告書［０］／報告者」であり、構成要素３０２のパスが、「ｕｉｘ：／／ｒｏｏｔ／従業員ＤＢ／従業員［３］／名前」であるとする。パスは必ずしも１つだけ検索されるのでなく、場合によっては複数検索される場合がある。
【０３４６】
アクセスレベルがデータと指定されていた場合（図７１のステップＳ１３１）、アクセス権限設定部２０２は、アクセス権限設定管理部２０３のデータアクセス権限管理部２１２に格納されている、図７４に示すようなデータアクセス権限テーブルに、指定されたアクセス権限を登録する（ステップＳ１３２）。データアクセス権限テーブルは、図７４に示すように、ステップＳ１３０で取得したパスとユーザ範囲とアクセスタイプとが登録されるようになっている。例えば、上記例の場合、アクセス権限を設定しようとしているパスが「ｕｉｘ：／／ｒｏｏｔ／報告書ＤＢ／報告書［０］／報告者」であり、このパスにより表された格納エリアに格納されている要素（要素値が「山田太郎」で要素名「報告者」の構成要素）に対し、ユーザ範囲として「グループＢ」というグループに、アクセスタイプとして「伏せ字（○）」がアクセス権限として設定されたことになる。
【０３４７】
一方、アクセスレベルがスキーマと指定されていた場合（ステップＳ１３３）、ステップＳ１３４へ進み、ステップＳ１３０で取得したパスにスキーマが設定されているかをチェックする。例えば、ステップＳ１３０で、「ｕｉｘ：／／ｒｏｏｔ／報告書ＤＢ／報告書［０］／報告者」というパスを取得したとき、このパスにて特定される「報告者」という構成要素（ノード）３０１に、スキーマが存在する旨の属性値がセットされているときは（ステップＳ１３４）、当該スキーマ文書の「報告者」という構成要素に対応する記述部分に対し、アクセス権限を設定する。すなわち、アクセス権限設定部２０２は、アクセス権限設定管理部２０３のスキーマ権限管理部２１１に格納されている、図７５に示すようなスキーマアクセス権限テーブルに、指定されたアクセス権限を登録する（ステップＳ１３５）。
【０３４８】
例えば、上記の例の場合、「報告者」という構成要素（ノード）３０１を含む、「報告書ＤＢ」ノード以下に、図８１に示すスキーマ文書が格納されているとする。図８１に示すスキーマ文書において、構成要素３０１に対応する記述部分は、実線で囲まれた部分である。構造化文書データベース中で、この記述部分を特定するパスは、例えば、「ｕｉｘ：／／ｒｏｏｔ／ｓｃｈｅｍａ／ｅｌｅｍｅｎｔＴｙｐｅ［４］／ｎａｍｅ」であるとする。この場合、スキーマアクセス権限テーブルには、図７５に示すように、スキーマ文書の「報告者」という構成要素に対応する記述部分を特定するパス、すなわち、「ｕｉｘ：／／ｒｏｏｔ／ｓｃｈｅｍａ／ｅｌｅｍｅｎｔＴｙｐｅ［４］／ｎａｍｅ」とユーザ範囲とアクセスタイプとが登録されるようになっている。例えば、上記例の場合、アクセス権限を設定しようとしているスキーマ文書の記述部分（構成要素）のパスは「ｕｉｘ：／／ｒｏｏｔ／ｓｃｈｅｍａ／ｅｌｅｍｅｎｔＴｙｐｅ［４］／ｎａｍｅ」であり、このパスにより特定された記述部分に対し、ユーザ範囲として「グループＡ」というグループに、アクセスタイプとして「モザイク」がアクセス権限として設定されたことになる。
【０３４９】
このように、スキーマにアクセス権限を設定することにより、以後、このスキーマの設定された構造化文書データベース中の格納領域（例えば、上記例の場合、「報告書ＤＢ」ノード以下の格納領域）に格納された、このスキーマが適用される全ての構造化文書に対して、スキーマアクセス権限テーブルに登録されたのと同一のアクセス権限が適用される。
【０３５０】
さて、アクセスレベルがパスに対しても設定可能である。例えば、図８２に示すように、「報告書ＤＢ」ノード以下には、複数の「報告書」情報（構造化文書）が格納されている。この複数の「報告書」情報のそれぞれは、「報告者」という要素名の構成要素（ノード）を持つ。そこで、この複数の「報告書」情報中の１つに含まれる「報告者」ノードが図７０のステップＳ１３０で特定されたとき、他の全ての「報告書」情報中の「報告者」ノードについても、アクセス権限を設定することも可能である。アクセスレベルがパスと指定されたときは、この他の全ての「報告書」情報中の「報告者」ノードに対し、同一のアクセス権限を設定する。この効果は、「報告書ＤＢ」ノード以下にスキーマが設定されている場合に、スキーマに対しアクセス権限を設定する場合（図７１のステップＳ１３５）と同じである。従って、ステップＳ１３３でアクセスレベルがスキーマと設定されている場合に、ステップＳ１３４で、当該スキーマが存在しないときは、ステップＳ１３７へ進むようにしてもよい。また、図７１には示していないが、ステップＳ１３６でアクセスレベルがパスと設定されている場合に、例えば、「ｕｉｘ：／／ｒｏｏｔ／報告書ＤＢ／報告書［０］／報告者」というパスにて特定される「報告者」という構成要素（ノード）３０１にスキーマが設定されているときは、ステップＳ１３５に進みようにしてもよい。
【０３５１】
アクセスレベルがパスと指定されていた場合（ステップＳ１３６）、ステップＳ１３７へ進み、アクセス権限設定部２０２は、構造化文書データベースの「”ｕｉｘ：／／ｒｏｏｔ／報告書ＤＢ”」以下から、「報告者」という構成要素のパスを検索するためのクエリ生成して（発行して）、それを検索要求処理部３へ送る。
【０３５２】
検索要求処理部３では、前述したようにして、クエリに記述された検索条件に基づき、構造化文書データベースを検索する。すると、「”ｕｉｘ：／／ｒｏｏｔ／報告書ＤＢ”」以下にある全ての「報告者」という要素名の構成要素へのパスを取得することができる。このときのクエリ中の要素値を検索条件とする「記述はない。
【０３５３】
アクセス権限設定部２０２は、アクセス権限設定管理部２０３のパスアクセス権限管理部２１５に格納されている、図７６に示すようなパスアクセス権限テーブルに、指定されたアクセス権限を登録する（ステップＳ１３８）。パスアクセス権限テーブルは、図７６に示すように、ステップＳ１３７で取得したパスとユーザ範囲とアクセスタイプとが登録されるようになっている。例えば、上記例の場合、アクセス権限を設定しようとしているパスが「ｕｉｘ：／／ｒｏｏｔ／報告書ＤＢ／報告書［１］／報告者」、「ｕｉｘ：／／ｒｏｏｔ／報告書ＤＢ／報告書［２］／報告者」、…であり、これらパスにより特定された格納エリアに格納されている要素（要素名「報告者」の構成要素）に対し、ユーザ範囲として「グループＢ」というグループに、アクセスタイプとして「伏せ字（○）」がアクセス権限として設定されたことになる。
【０３５４】
このように、上記実施形態では、構造化文書データベースを検索した結果得られた表示対象のＸＭＬ文書（検索結果文書）は、クライアント端末装置１０２で所定のスタイルシート（検索結果文書を所定の表示形式で表示するために用いた検索結果文書の文書構造の変換規則）を適用してＨＴＭＬ文書に変換された後、表示画面上に表示される。変換の際には、ＨＴＭＬ文書の１つの記述部分を１つの表示領域（テキストボックス）で表示するようなスタイルシートをＸＭＬ文書に適用する。この表示画面上で、所望の表示領域（テキストボックス）を指定することにより、クライアント端末装置１０２の描画部１１５は、（ａ）このテキストボックスに表示されているＨＴＭＬ文書の記述部分を特定することができるので、さらに、クライアント端末装置１０２のアクセス権限設定部１１６は、対応テーブル１１４を参照して、当該ＨＴＭＬ文書の記述部分に対応するスタイルシート中の記述部分を特定する。次に、（ｂ）スタイルシート中の当該記述部分に関連付けられた検索結果文書中の要素のパスを特定した後、（ｃ）当該検索結果文書を得るために用いたクエリ中の出力形式の記述部から当該パスに対応する記述部分を特定する。そして、（ｄ）構造化文書データベースにアクセスして（クエリを発行して）、当該記述部分に関連付けられた構造化文書データベース中の要素のパス（パスリスト）を取得する。以上のように、ユーザにより所望の表示領域が指定されると、ユーザにより指定されたレベルに応じて、該指定された表示領域に対応するスタイルシートの記述部分、さらに、それに対応するクエリ中の記述部分、さらにそれに関連付けられた構造化文書データベース中の要素を順次特定していくことにより、指定されたレベルにアクセス権限を設定することが容易に行える。ユーザは、検索結果の表示画面上で、少なくとも所望の表示領域と、アクセスレベルを指定するだけで、構造化文書データベース中の構成要素にアクセス権限の設定が行える。さらに、スタイルシートの記述部分、クエリ中の記述部分、当該要素を含む構造化文書と同じ文書構造を持つ他の構造化文書中の当該要素と同じ要素名の要素に対しても、それ対応のレベルを指定するだけでアクセス権限を設定することができるので、各種アプリケーションに柔軟に対処できる。
【０３５５】
なお、上記アクセス権限の設定は、１つの表示領域を選択して、その表示領域に対応する、スタイルシート、クエリ、構造化文書データベース中の要素（データ）、スキーマ、パスのうちの１つレベルにアクセス権限を設定する場合について説明したが、一度に複数の表示領域を選択して、それらに対応する上記複数のレベルのうちの１つのレベルに一括して（ユーザ範囲、アクセスタイプを同じくした）アクセス権限を設定することも上記同様にして容易に行える。
【０３５６】
また、スタイルに対しアクセス権限を設定した場合、スタイル権限テーブルに登録された内容に基づき、スタイルシート自体に、指定されたユーザ範囲やアクセスタイプを登録するようにしてもよい。この場合、例えば、図８３の実線で囲まれた部分に示すように、スタイルシート中のアクセス権限を設定する記述部分（ＳＩＤにて特定される記述部分）に、ユーザ範囲とアクセスタイプを書き込み、クライアント端末装置１０２が、当該スタイルシートを適用する段階で、このアクセス権限の記述を解釈できる機能があればよい。
【０３５７】
また、クエリに対しアクセス権限を設定した場合、クエリ権限テーブルに登録された内容に基づき、クエリ文書自体に、指定されたユーザ範囲やアクセスタイプを登録するようにしてもよい。この場合も例えば、図８４の実線で囲まれた部分に示すように、クエリ文書中のアクセス権限を設定する記述部分（ＱＩＤにて特定される記述部分）に、ユーザ範囲とアクセスタイプを書き込み、検索要求処理部３が、当該クエリを実行する際に、このアクセス権限の記述を解釈できる機能があればよい。
【０３５８】
次に、上記のようにしてアクセス権限が設定された後、クエリを用いた検索実行結果の表示例について説明する。
【０３５９】
ここでは、例えば、図６２の中、「ＨＩＤ７」という識別子を持つ記述部分に対応する表示領域３０７と、「ＨＩＤ１１」という識別子を持つ記述部分に対応する表示領域３１１と、「ＨＩＤ１３」という識別子を持つ記述部分に対応する表示領域３１３とが指定されて、「山田太郎」という個人をユーザ範囲としたアクセス権限が設定されたとする。表示領域３０７、３１１には、アクセスタイプとして「伏せ字」が指定され、表示領域３１３にはアクセスタイプとして「モザイク」が指定されたとする。
【０３６０】
さらに、上記３つの表示領域に、アクセスレベルが「データ」と指定されてアクセス権限が設定されたとする。この場合、「山田太郎」というユーザが、クライアント端末装置１０２から、所定の操作を行って、図１に示した構造化文書管理システムにアクセスして、図７７に示したクエリを用いて検索を行ったとする。なお、ユーザ名「山田太郎」は、構造化文書管理システムにアクセスする際に、クライアント端末装置１０２を介して、構造化文書管理システムの要求制御部１，アクセス権限設定管理部２０１にも入力するようになっている。
【０３６１】
すると、検索結果として得られた検索結果文書（ＸＭＬ文書）は、クライアント端末装置１０２の表示画面には、図８５に示すように表示される。すなわち、表示領域３０７、３１１に表示されるデータは、伏せ字「×」や「○」で表示されている。また、表示領域３１３は、モザイクがかけられて表示されている。さらに、表示領域３０７に表示されるデータと同じデータを表示している表示領域３１５にも、表示領域３０７と同様の伏せ字「×」が表示されている。これは、表示領域３０７に表示されているデータ（この場合、テキスト）は、そのデータを要素値とする構造化文書データベース中の構成要素、すなわち、例えば、「ｕｉｘ：／／ｒｏｏｔ／報告書ＤＢ／報告書［０］／報告者」というパスにて表現される論理的な格納エリアに格納されている構成要素と、「ｕｉｘ：／／ｒｏｏｔ／従業員ＤＢ／従業員［３］／名前」というパスにて表現される論理的な格納エリアに格納されている構成要素とに対しアクセス権限が設定されているからである。
【０３６２】
検索要求処理部３では、例えば、図７７に示したクエリを実行して、検索条件を満たす構成要素を構造化文書データベースから取り出す際に、アクセス権限設定管理部２０１と通信を行い、アクセス権限設定管理部２０１にて管理されている図７４に示したようなアクセス権限テーブルに基づき、「ｕｉｘ：／／ｒｏｏｔ／報告書ＤＢ／報告書［０］／報告者」というパスにて特定される構成要素と、「ｕｉｘ：／／ｒｏｏｔ／従業員ＤＢ／従業員［３］／名前」というパスにて特定される構成要素とに、アクセス権限が設定されていることを知る。
【０３６３】
このアクセス権限の設定された、「ｕｉｘ：／／ｒｏｏｔ／報告書ＤＢ／報告書［０］／報告者」というパスにて特定される構成要素と、「ｕｉｘ：／／ｒｏｏｔ／従業員ＤＢ／従業員［３］／名前」というパスにて特定される構成要素は、図７７に示したクエリにより、検索結果文書中の「報告書／報告者／名前」というパスで特定される検索結果文書の構成要素として用いられる（バインドされている）。この段階で、当該検索結果文書中に当該構成要素のアクセスタイプなどをクライアント端末装置１０２の所定の機能により解釈可能なように書き込むようにしてもよい。
【０３６４】
あるいは、検索要求処理部３で検索結果文書を作成した段階で、アクセス権限設定管理部２０１が、この検索結果文書中の構成要素にアクセス権限が設定されているか否かをアクセス権限テーブルを参照することによりチェックして、当該検索結果文書中のアクセス権限の設定された構成要素にアクセスタイプなどをクライアント端末装置１０２の所定の機能により解釈可能なように書き込むようにしてもよい。
【０３６５】
この検索結果文書は、図６４に示すようなスタイルシートとともに、検索要求元のクライアント端末装置１０２に送信される。
【０３６６】
図６４に示すようなスタイルシートにより、「報告書／報告者／名前」というパスで特定される検索結果文書の構成要素は、図８５に示すように、表示領域３０７と３１５の両方に表示されるように、当該検索結果文書としてのＸＭＬ文書をＨＴＭＬ文書に変換するようになっている。なお、図６４に図示していないが、図６４のスタイルシートには、「報告書／報告者／名前」というパスで特定される検索結果文書の構成要素を、図８５に示すように、表示領域３０７と３１５の両方に表示するようなＨＴＭＬ文書に変換するための変換規則が記述されている。
【０３６７】
表示領域３０７にアクセスレベルが「スタイル」と指定されてアクセス権限が設定されたとする。この場合、スタイルシートには、図８３に示すように、アクセス権限が書き込まれているものとする。また、クライアント端末装置１０２で検索結果文書をＨＴＭＬ文書に変換する際に、当該スタイルシート中のアクセス権限に関する記述を解釈する機能が必要である。スタイルシートには、「報告書／報告者／名前」というパスで特定される検索結果文書の構成要素を表示領域３０７に表示するようなＨＴＭＬ文書に変換するための記述部分には、例えばユーザ範囲とアクセスタイプとが書き込まれているが、表示領域３１５に表示するようなＨＴＭＬ文書に変換するための記述部分には、そのようなアクセス権限に関する記述は書き込まれていない。従って、図８６に示すように、表示領域３１５には、伏せ字ではなく、実際のデータが表示される。
【０３６８】
「山田太郎」というユーザが、クライアント端末装置１０２から、所定の操作を行って、図１に示した構造化文書管理システムにアクセスして、図７７に示したクエリとは異なるクエリを用いて検索を行ったとする。このクエリは、例えば、構造化文書データベース中の「従業員ＤＢ」ノード以下に格納されている情報から所定の条件を満たす「従業員」情報を検索するものであるとする。この検索の結果得られる検索結果文書は、上記所定の条件を満たす複数の「従業員」情報を合成したものであるとする。
【０３６９】
この検索結果文書には、上記のようにしてアクセス権限の設定された「ｕｉｘ：／／ｒｏｏｔ／従業員ＤＢ／従業員［３］／名前」というパスにて特定される構成要素が含まれているとする。すると、上記同様にして、図８７に示すように、この構成要素を表示する表示領域３２１には伏せ字「ｘ」による表示がなされている。
【０３７０】
しかし、表示領域３０７にアクセスレベルが「クエリ」と指定されてアクセス権限が設定されたとする。すなわち、表示領域３０７に表示されるデータに対応する検索結果文書中の構成要素に対応する図７７に示したクエリ中の記述部分に、（検索結果文書中の構成要素に対する）アクセス権限が設定されていた場合には、今回のクエリは図７７に示したクエリとは異なるものであるから、図８７に示した表示領域３２１には伏せ字「ｘ」ではなく、実際のデータ、すなわち、「山田太郎」が表示される。
【０３７１】
このように、アクセス権限をスタイルシート、クエリといったレベルに設定することにより、あるスタイルシートを用いていたときには表示されなかったデータが他の異なるスタイルシートを用いれば表示される、あるクエリを用いた検索結果では表示されなかったデータが他の異なるクエリを用いたときには表示されるといった、柔軟なアクセス権限の設定が可能になる。
【０３７２】
以上説明したように、上記実施形態は、１つの表示領域（テキストボックス）には、１つの構成要素の要素名あるいは要素値が表示されていて、クエリによって検索した結果得られた検索結果文書を表示した表示画面上の複数の表示領域のうちの１つが選択されたら、その選択された表示領域に表示されているデータ（要素名あるいは要素値）を起点にして、スタイルシート、検索結果文書、クエリ、構造化文書データベース中の構造化文書とレベルを掘り下げていく過程に存在する、ユーザにより指定されたレベルのアクセス権限の設定対象にアクセス権限を設定するものであり、ユーザは、検索結果の表示画面上で、少なくとも所望の表示領域と、アクセスレベルを指定するだけで、構造化文書データベース中の構成要素にアクセス権限の設定が行える。さらに、スタイルシートの記述部分、クエリ中の記述部分、当該要素を含む構造化文書と同じ文書構造を持つ他の構造化文書中の当該要素と同じ要素名の要素に対しても、それ対応のレベルを指定するだけでアクセス権限を設定することができるので、構造化文書データベースに格納されている構造化文書の構成要素の用途や表示形式（検索結果として表示する際の表示形式）に応じて、異なる内容のアクセス権限を容易に設定することができる。
【０３７３】
なお、上記実施形態では、アクセス権限の設定は、クエリを用いて、構造化文書データベースを検索した結果得られた文書を表示した表示画面上で行ったが、この場合に限らず、例えば、前述した取得コマンド「ｇｅｔＸＭＬ」を実行する際においても、そのコマンドにて指定されたパス以下の文書（を構成する全ての構成要素）に、あるいは、当該指定されたパス以下の文書の一部の構成要素に、上記したようなアクセス権限が設定されている場合には、当該指定されたパス以下の文書を表示する際には、そのアクセス権限の設定された構成要素を非表示にしたり、特殊表示にしたりすればよい。
【０３７４】
また、上記実施形態では、アクセスタイプとして、非表示にするか、特殊表示にするかのいずれかを選択するようになっているが、アクセスタイプとしては、これ以外に、削除禁止、編集禁止などがあってもよい。削除禁止、編集禁止といいた構造化文書データベース中の構成要素自体に対する操作を制限するようなアクセスタイプを設定するときは、このアクセスタイプととともに設定されるアクセスレベルはデータレベルである。
【０３７５】
例えば、アクセスタイプとして削除禁止が構造化文書データベース中のある構成要素に設定されると、当該構成要素あるいは、そのような構成要素を含む構造化文書データベース中の論理的なエリア（パス）を指定した領域削除コマンドが実行されても、少なくとも当該アクセス権限の設定された構成要素は削除されることはない。また、アクセスタイプとして編集禁止が構造化文書データベース中のある構成要素に設定されると、当該構成要素の要素値を書き換えることはできない。
【０３７６】
なお、本発明の実施の形態に記載した本発明の手法は、コンピュータに実行させることのできるプログラムとして、磁気ディスク（フロッピーディスク、ハードディスクなど）、光ディスク（ＣＤ−ＲＯＭ、ＤＶＤなど）、半導体メモリなどの記録媒体に格納して頒布することもできる。
【０３７７】
また、本発明は、上記実施形態に限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で種々に変形することが可能である。さらに、上記実施形態には種々の段階の発明は含まれており、開示される複数の構成用件における適宜な組み合わせにより、種々の発明が抽出され得る。例えば、実施形態に示される全構成要件から幾つかの構成要件が削除されても、発明が解決しようとする課題の欄で述べた課題（の少なくとも１つ）が解決でき、発明の効果の欄で述べられている効果（のなくとも１つ）が得られる場合には、この構成要件が削除された構成が発明として抽出され得る。
【０３７８】
【発明の効果】
以上説明したように、本発明によれば、検索結果の表示画面上で、少なくとも所望の表示領域とアクセスレベルを指定するだけで、構造化文書データベース中の所望の構成要素に、用途や表示形式などに応じた所望のアクセス権限を容易にしかもきめ細かく設定することができる。
【図面の簡単な説明】
【図１】本発明の実施形態に係る構造化文書管理システムの構成例を示した図。
【図２】図１に示した構造化文書管理システムの一利用形態を示したもので、ＷＷＷのバックエンドで、構造化文書管理システムが動作している場合を示した図。
【図３】ＸＭＬで記述された構造化文書の一例を示した図。
【図４】図３の構造化文書の文書構造を模式的に示した図。
【図５】追加コマンドの機能を説明するための図で、構造化文書データベースの初期状態に追加コマンドを実行した場合について示している。
【図６】図５（ｂ）に示した状態の構造化文書データベースに対し、取得コマンドを実行した場合の処理結果を示した図。
【図７】図５（ｂ）に示した状態の構造化文書データベースに対し、追加コマンドを実行して１つの「特許」情報の文書オブジェクトツリーを追加した場合を示している。
【図８】図５（ｂ）に示した状態の構造化文書データベースに対し、追加コマンドを実行して３つの「特許」情報の文書オブジェクトツリーを追加した場合を示している。
【図９】要素名生起インデックスの格納例を示した図。
【図１０】データ生起インデックスの格納例を示した図。
【図１１】図８に示した状態の構造化文書データベースに対して、３つの「特許」情報を取り出すための取得コマンドを実行した場合の実行結果を示した図。
【図１２】ＸＭＬ文書の文書構造を定義するスキーマの一例を示した図。
【図１３】図８に示した状態の構造化文書データベースに、スキーマ格納コマンドを実行して、図１２に示したスキーマを追加格納（設定）した場合を示した図。
【図１４】スキーマが設定されて、スキーマが存在している旨の属性値のセットされた文書オブジェクトツリーを示した図。
【図１５】各オブジェクトファイルに、スキーマが存在している旨の属性値が格納されている様子を概念的に示した図。
【図１６】必要に応じて検索で使用される概念階層を構造化文書で表現した例を示した図。
【図１７】必要に応じて検索で使用される概念階層を構造化文書で表現した例を示した図。
【図１８】図８に示した状態の構造化文書データベースに対し、追加コマンドを実行して、図１６，図１７に示した「概念」情報の文書オブジェクトツリーを追加した場合を示した図。
【図１９】図８に示した状態の構造化文書データベースに対し、追加コマンドを実行して、図１６，図１７に示した「概念」情報の文書オブジェクトツリーを追加した場合を示した図。
【図２０】図１の構造化文書管理システムの文書格納処理動作について説明するためのフローチャート。
【図２１】図２０のステップＳ９の処理（合成文書作成部の処理）について説明するためのフローチャート
【図２２】追加コマンド中のパラメータの格納文書の文書オブジェクトツリーを構造化文書データベースから取得した文書オブジェクトツリーに挿入して得られた合成文書の文書オブジェクトツリーをＸＭＬ文書に変換した結果であって、テンポラリファイルＡに格納される合成文書の一例を示した図。
【図２３】テンポラリファイルＢに格納される、構造化文書データベースから取得されたスキーマ文書の一例を示した図。
【図２４】テンポラリファイルＡに格納される合成文書の他の例を示した図。
【図２５】テンポラリファイルＢに格納される、構造化文書データベースから取得されたスキーマ文書の一例を示した図。
【図２６】図１の構造化文書管理システムの文書取得処理動作について説明するためのフローチャート。
【図２７】図１の構造化文書管理システムの文書削除処理動作について説明するためのフローチャート。
【図２８】図２７のステップＳ４６の処理（合成文書作成部の処理（削除コマンド用））について説明するためのフローチャート。
【図２９】テンポラリファイルＡに格納される合成文書のさらに他の例であって、削除コマンドの実行時に作成される合成文書の一例を示した図。
【図３０】テンポラリファイルＢに格納される、構造化文書データベースから取得されたスキーマ文書の一例を示した図。
【図３１】ユーザインタフェースとしての画面の表示例を示した図。
【図３２】文書の格納／削除を行うためのユーザインタフェースとしての画面の表示例を示した図。
【図３３】文書の格納／削除を行うためのユーザインタフェースとしての画面の表示例を示した図。
【図３４】文書の格納／削除を行うためのユーザインタフェースとしての画面の表示例を示した図。
【図３５】妥当性のチェックでエラーとなっときにクライアント端末へ返すメッセージの表示例を表示例を示した図。
【図３６】文書の格納／削除を行うためのユーザインタフェースとしての画面の表示例を示したもので、文書取得動作を説明するための図。
【図３７】スキーマの設定を行うためのユーザインタフェースとしての画面の表示例を示したもので、スキーマの設定動作を説明するための図。
【図３８】スキーマの取得するためのユーザインタフェースとしての画面の表示例を示したもので、取得されたスキーマの表示例を示している。
【図３９】クエリ（ＸＭＬ文書）の一例を示した図。
【図４０】単純検索のクエリ（ＸＭＬ文書）の一例を示した図。
【図４１】図４０の単純検索のクエリを用いた検索結果（ＸＭＬ文書）を示した図。
【図４２】概念検索のクエリ（ＸＭＬ文書）の一例を示した図。
【図４３】図１の構造化文書管理システムの文書検索処理動作について説明するためのフローチャート。
【図４４】文書検索を行うためのユーザインタフェースとしての画面の表示例を示した図。
【図４５】図４４に示した画面上から入力された情報に基づき作成されるクエリを示した図。
【図４６】図４２に示したクエリの構造化文書データベース内における格納例を示した図。
【図４７】文書検索を行うためのユーザインタフェースとしての画面の表示例であって、スキーマの検索処理動作を説明するための図。
【図４８】スキーマ検索のクエリの一例を示した図。
【図４９】クエリを検索するためのクエリの一例を示した図。
【図５０】特許調査における構造化文書データベースの一例を示した図。
【図５１】概念検索のための入力画面の表示例を示した図。
【図５２】図５１に示した入力画面上の入力情報に対応するクエリを示した図。
【図５３】図５２に示したクエリに対応する検索結果としてのＸＭＬ文書を示した図。
【図５４】特許マップの一例を示した図。
【図５５】クライアント端末装置の要部の構成例を示した図。
【図５６】クライアント端末装置で構造化文書管理システムから送信されてきたＸＭＬ文書を表示する際の処理動作を説明するためのフローチャート。
【図５７】アクセス権限の設定のためのクライアント端末装置における処理動作を説明するためのフローチャート。
【図５８】アクセス権限設定管理部の機能ブロック図。
【図５９】構造化文書データベースの論理構造の一部を模式的に示した図。
【図６０】ＸＭＬで記述された構造化文書の一例として、「報告書ＤＢ」ノード以下の論理的な格納エリアに格納されている「報告書」情報を示した図。
【図６１】ＸＭＬで記述された構造化文書の一例として、「従業員ＤＢ」ノード以下の論理的な格納エリアに格納されている複数の「報告書」情報を示した図。
【図６２】クライアント端末装置のディスプレイ装置の画面表示例を示したもので、クライアント端末装置から入力されたクエリを実行した結果得られたＸＭＬ文書（検索結果文書）の表示例を示した図。
【図６３】図６２に対応する検索結果文書を示した図。
【図６４】図６３に示した検索結果文書を図６２に示したような表示形式で表示するためのＨＴＭＬ文書に変換するためのスタイルシートの一例を示した図。
【図６５】ＨＴＭＬ文書の各記述部分と各記述部分に与えられている識別子ＨＩＤとの対応を説明するための図。
【図６６】ＨＴＭＬ文書中の記述部分と、スタイルシート中の記述部分との対応関係を示した対応テーブルの一例を示した図。
【図６７】ユーザの範囲を入力するためのＧＵＩ画面の一例を示した図。
【図６８】アクセスレベルを入力するためのＧＵＩ画面の一例を示した図。
【図６９】アクセスタイプを入力するためのＧＵＩ画面の一例を示した図。
【図７０】アクセス権限設定管理部で、アクセス権限を設定するための処理動作を説明するためのフローチャート。
【図７１】アクセス権限設定管理部で、アクセス権限を設定するための処理動作を説明するためのフローチャート。
【図７２】スタイルアクセス権限管理部に格納されているスタイルアクセス権限テーブルの一例を示した図。
【図７３】クエリアクセス権限管理部に格納されているクエリアクセス権限テーブルの一例を示した図。
【図７４】データアクセス権限管理部に格納されているデータアクセス権限テーブルの一例を示した図。
【図７５】スキーマアクセス権限管理部に格納されているスキーマアクセス権限テーブルの一例を示した図。
【図７６】パスアクセス権限管理部に格納されているパスアクセス権限テーブルの一例を示した図。
【図７７】図６３に示したＸＭＬ文書を得るために用いたクエリ文書を示した図。
【図７８】図７７に示したクエリの記述を基に、アクセス権限の設定対象の構成要素を構造化文書データベースから検索するために発行するクエリの一例を示した図。
【図７９】図７７に示したクエリの記述を基に、アクセス権限の設定対象の構成要素を構造化文書データベースから検索するために発行するクエリの一例を示した図。
【図８０】図７８、７９に示したクエリを実行したことにより得られた構造化文書データベース中の構成要素の論理的な格納位置（パス）を示した図。
【図８１】図６２の表示領域３０７が指定され、しかもアクセスレベルがスキーマと指定されたときに、アクセス権限が設定されるスキーマ中の記述部分を示した図。
【図８２】図６２の表示領域３０７が指定され、しかもアクセスレベルがパスと指定されたときに、アクセス権限が設定される構成要素を示した図。
【図８３】アクセス権限の内容が書き込まれたスタイルシートの一例を示した図。
【図８４】アクセス権限の内容が書き込まれたクエリの一例を示した図。
【図８５】データレベルでアクセス権限が設定された後に、図７７に示したクエリを実行した際に得られた検索結果文書の表示例を示した図。
【図８６】スタイルレベルでアクセス権限が設定された後に、図７７に示したクエリを実行した際に得られた検索結果文書の表示例を示した図。
【図８７】データレベルでアクセス権限が設定された後に、図７７に示したクエリとは異なるクエリを実行した際に得られた検索結果文書の表示例を示した図。
【図８８】図６５に示した表示画面に対応するＨＴＭＬ文書の一部を示した図。
【符号の説明】
１…要求制御部
２…アクセス要求処理部
３…検索要求処理部
４…データアクセス部
５…文書記憶部
６…インデックス記憶部
１１…受付要求部
１２…結果処理部
２１…文書格納部
２２…文書取得部
２３…文書削除部
４１…文書オブジェクトツリー格納部
４２…文書オブジェクトツリー削除部
４３…文書オブジェクトツリー取得部
４４…文書文字列取得部
４５…パスから文書オブジェクトツリー取得部
４６…文書パーサ
４７…合成文書作成部
４８…インデックス更新部
１００…構造化文書管理システム
１０１…ＷＷＷサーバ
１０２…クライアント端末
１０３…ＷＷＷブラウザ
１１１…ＸＭＬ文書受信部
１１２…ＸＭＬ／ＨＴＭＬ変換部
１１３…テーブル作成部
１１４…対応テーブル
１１５…描画部
１１６…アクセス権限設定部
１１７…送信部
１２１…ディスプレイ装置
１２２…入力装置
２０１…アクセス権限設定管理部
２０２…アクセス権限設定部
２０３…アクセス権限管理部
２１１…スキーマアクセス権限管理部
２１２…データアクセス権限管理部
２１３…クエリアクセス権限管理部
２１４…スタイルアクセス権限管理部
２１５…パスアクセス権限管理部
【図１】
0003914081.tif 000003
【図２】
0003914081.tif 000004
【図３】
0003914081.tif 000005
【図４】
0003914081.tif 000006
【図５】
0003914081.tif 000007
【図６】
0003914081.tif 000008
【図７】
0003914081.tif 000009
【図８】
0003914081.tif 000010
【図９】
0003914081.tif 000011
【図１０】
0003914081.tif 000012
【図１１】
0003914081.tif 000013
【図１２】
0003914081.tif 000014
【図１３】
0003914081.tif 000015
【図１４】
0003914081.tif 000016
【図１５】
0003914081.tif 000017
【図１６】
0003914081.tif 000018
【図１７】
0003914081.tif 000019
【図１８】
0003914081.tif 000020
【図１９】
0003914081.tif 000021
【図２０】
0003914081.tif 000022
【図２１】
0003914081.tif 000023
【図２２】
0003914081.tif 000024
【図２３】
0003914081.tif 000025
【図２４】
0003914081.tif 000026
【図２５】
0003914081.tif 000027
【図２６】
0003914081.tif 000028
【図２７】
0003914081.tif 000029
【図２８】
0003914081.tif 000030
【図２９】
0003914081.tif 000031
【図３０】
0003914081.tif 000032
【図３１】
0003914081.tif 000033
【図３２】
0003914081.tif 000034
【図３３】
0003914081.tif 000035
【図３４】
0003914081.tif 000036
【図３５】
0003914081.tif 000037
【図３６】
0003914081.tif 000038
【図３７】
0003914081.tif 000039
【図３８】
0003914081.tif 000040
【図３９】
0003914081.tif 000041
【図４０】
0003914081.tif 000042
【図４１】
0003914081.tif 000043
【図４２】
0003914081.tif 000044
【図４３】
0003914081.tif 000045
【図４４】
0003914081.tif 000046
【図４５】
0003914081.tif 000047
【図４６】
0003914081.tif 000048
【図４７】
0003914081.tif 000049
【図４８】
0003914081.tif 000050
【図４９】
0003914081.tif 000051
【図５０】
0003914081.tif 000052
【図５１】
0003914081.tif 000053
【図５２】
0003914081.tif 000054
【図５３】
0003914081.tif 000055
【図５４】
0003914081.tif 000056
【図５５】
0003914081.tif 000057
【図５６】
0003914081.tif 000058
【図５７】
0003914081.tif 000059
【図５８】
0003914081.tif 000060
【図５９】
0003914081.tif 000061
【図６０】
0003914081.tif 000062
【図６１】
0003914081.tif 000063
【図６２】
0003914081.tif 000064
【図６３】
0003914081.tif 000065
【図６４】
0003914081.tif 000066
【図６５】
0003914081.tif 000067
【図６６】
0003914081.tif 000068
【図６７】
0003914081.tif 000069
【図６８】
0003914081.tif 000070
【図６９】
0003914081.tif 000071
【図７０】
0003914081.tif 000072
【図７１】
0003914081.tif 000073
【図７２】
0003914081.tif 000074
【図７３】
0003914081.tif 000075
【図７４】
0003914081.tif 000076
【図７５】
0003914081.tif 000077
【図７６】
0003914081.tif 000078
【図７７】
0003914081.tif 000079
【図７８】
0003914081.tif 000080
【図７９】
0003914081.tif 000081
【図８０】
0003914081.tif 000082
【図８１】
0003914081.tif 000083
【図８２】
0003914081.tif 000084
【図８３】
0003914081.tif 000085
【図８４】
0003914081.tif 000086
【図８５】
0003914081.tif 000087
【図８６】
0003914081.tif 000088
【図８７】
0003914081.tif 000089
【図８８】
0003914081.tif 000090