JP5169505B2 - 文書合成システム及びプログラム - Google Patents

Description

本発明は、文書合成システム及びプログラムに関する。

複数人が独立的かつ分散的に一つの文書を構成し編集する共同編集を支援する方法は従来知られている (特許文献１及び２参照）。

この場合、全体の構成に責任を持つ文書構成編集者（以下、構成編集者）は、各内容部分（「文書部品」と呼ぶ）の編集に責任を持つ文書内容編集者（以下、内容編集者）の作業を特定の時点で中断させ、作成・編集した文書部品を集約し、発行のための文書を作成する作業を行うのが一般的である。

特開２００３−０６７４０２号公報 特開２００７−１１５１３１号公報 特開平６−２９５２９９号公報 特開平１０−１４３５０７号公報 特開２００３−２４８６７９号公報

従来技術では、文書の一貫性を保つために、文書データベースには、内容編集者が、構成編集者が作成した章立て構造の中で自分の担当箇所として指定された文書部品を指定し、排他的に編集する機構が必要であった。そうでなければ、内容編集者は、編集後の文書部品を文書データベースに書き戻す際に、その文書がその章立て構造のどの部分に相当するかを指定する必要があった。そのような指定の操作は、面倒であり間違いが発生する可能性がある。特に文書部品が紙文書のスキャン画像や写真である場合に、元の章立て構造の位置との対応付けを知ることが困難であり、より顕著な課題となる。

また、従来技術では、構成編集者が所定の章立てを変更し、または、章立て見出しを編集するタイミングは、一般に内容編集者が文書部品の作成または編集を完了し、構成編集者がそれを収集して構成を編集するときに制限される。すなわち、内容編集者による文書部品の作成・編集と構成編集者による構成の編集が並行的に実行できないので効率が悪い。

また、内容編集者が文書部品を作成した後に構成編集者が文書部品を集約し構成を編集して章立て順序や構造、章見出しなどを変更すると、その後内容編集者が自分の担当する文書部品の内容を変更した場合に、章立て構造が変更されたあとなので、正しい場所に変更後の内容を反映することが困難となる。このような場合、従来技術では、構成編集者が編集を完了した文書から、内容編集者が該当箇所を特定し、文書部品を独占的に取り出して編集し、書き戻すなどの手順が必要であり、効率が悪い。

本発明は、情報処理装置から、第１の構造化文書に対して行われた操作の種類と、当該操作の結果である第２の構造化文書と、を受信した場合に、前記操作の種類と前記第２の構造化文書とを対応づけて記憶装置に登録すると共に、前記第２の構造化文書が前記第１の構造化文書の子であることを示す派生関係を前記記憶装置に登録する登録手段と、前記記憶装置に記憶された派生関係群がなす木構造のうちユーザから指定された構造化文書を含む木に属する構造化文書であって、対応する操作の種類が文書内容の更新に該当する構造化文書を特定する特定手段と、前記指定された構造化文書に含まれる各文書部品の部品識別子を特定し、それら各部品識別子を持つ構造化文書を前記特定手段が特定した構造化文書群の中から検索する検索手段であって、前記特定手段が特定した構造化文書群の中に同じ部品識別子を持つ構造化文書が複数あった場合はそれら複数のうち前記木において最も葉に近いものを検索することを特徴とする検索手段と、前記検索手段が検索した前記各部品識別子を持つ構造化文書を、前記指定された構造化文書における前記各部品識別子に対応する要素に組み込むことで、合成文書を生成する生成手段と、を備える文書合成システムを提供する。

本発明によれば、文書の構成の編集と、その文書を構成する各文書部品の内容の編集とを並行的に実行した場合でも、それら各文書部品を合成した文書を生成することができる。

図１は、文書管理システムの概略構成の一例を示すブロック図である。このシステムは、インターネットやローカル・エリア・ネットワーク等のネットワーク３０を介して接続された文書管理サーバ１０とクライアント端末２０−１，２０−２，・・・（以下、クライアント端末２０と総称する）から構成される。

クライアント端末２０の例について図２を用いて説明する。クライアント端末は、ユーザが文書を操作するために用いる端末であり、パーソナルコンピュータ、デジタル複写機などがその一例である。クライアント端末２０は、図２に示すように、文書操作部２００及び登録処理部２１０を備える。

文書操作部２００は、文書に対する操作を実行する手段である。文書に対する操作には、例えば、文書の表示（ユーザから見れば「閲覧」）、編集、印刷出力、紙文書の読み取り、紙文書の複写、等がある。図では、文書操作部２００を１つだけ示したが、それら個々の操作を別々の操作部（例えば、編集用のアプリケーション、読取制御用のアプリケーションなど）が担当してもよい。例えば、文書操作部２００がワードプロセッサ等の電子文書を作成・編集するためのソフトウエアであれば、文書操作部２００は、ユーザの指示に応じて電子文書を表示したり、電子文書に編集を加えたりする。文書操作部２００は、文書に対して操作を行った場合、その操作の結果を表す識別子（ＩＤ）付き文書３００を出力する。

ＩＤ付き文書３００は、図３に示すように、メタ情報３１０と文書内容３２０を含んだ電子文書である。文書内容３２０は、文書操作部２００の操作の結果生成された文書の内容データである。文書操作部２００が電子文書を作成・編集するためのソフトウエアであれば、文書内容３２０はそのソフトウエアによる編集の結果生成される文書ファイルである。また、文書操作部２００が電子文書を印刷する装置であれば、文書内容３２０は、例えば、印刷される電子文書の内容データとすればよい。また、文書操作部２００が紙文書をスキャンする装置又は紙文書を複写する装置であれば、文書内容３２０は、例えば、その紙文書を読み取って得られる画像データとすればよい。

メタ情報３１０は、文書管理のための情報であり、操作ＩＤ３１２，親ＩＤ３１４，及びログ情報３１６を含む。

操作ＩＤ３１２は、当該ＩＤ付き文書３００自体の一意な識別情報である。親ＩＤ３１４は、当該ＩＤ付き文書３００の親のＩＤ付き文書の操作ＩＤである。すなわち、本実施形態では、あるＩＤ付き文書と、このＩＤ付き文書に対して操作を加えた結果得られる新たなＩＤ付き文書とを、親と子の関係として取り扱う。第１のＩＤ付き文書を操作して第２のＩＤ付き文書が得られた場合、第１のＩＤ付き文書は第２のＩＤ付き文書の親であり、第２のＩＤ付き文書は第１のＩＤ付き文書の子である。したがって、例えば、操作ＩＤ「Ａ」のＩＤ付き文書を文書操作部２００で操作して、その結果得られた新たなＩＤ付き文書の操作ＩＤが「Ｂ」である場合、後者のメタ情報３１０における操作ＩＤ３１２は「Ｂ」であり、親ＩＤ３１４は「Ａ」である。このような親子の関係を、以下では「（操作ＩＤの）派生関係」という。

なお、本システムに未登録の電子文書を新たに登録する操作を実行した場合や、未登録の紙文書をスキャン又は複写する操作を実行した場合（この場合、紙文書を読み取った画像を文書内容とするＩＤ付き文書が生成され、本システムに登録される）に生成されるＩＤ付き文書３００では、親ＩＤ３１４は空（すなわち、親は存在しない）となる。

ログ情報３１６は、当該ＩＤ付き文書が生成された際の操作についての、各種のログ項目の情報である。ログ項目には、例えばその操作が行われた時刻、その操作の種別、その操作を指示したユーザ（操作者）などがあるが、もちろんこれに限るものではない。操作の種別には、例えば新規登録（本システムに新規の文書を登録すること）、閲覧、内容更新（文書の内容を変更する操作）、改訂、印刷、スキャン、紙文書の複写、等がある。例えば、ユーザが文書操作部２００を用いて第１のＩＤ付き文書に対して編集を加え、編集完了の指示を行った場合、その結果生成される第２のＩＤ付き文書のログ情報３１６は、編集完了の時刻と、その編集を指示したユーザの識別情報と、操作の種別として「内容更新」と、を含んだものとなる。また、「改訂」は、この例では、文書構成を更新する場合の操作を指している。なお、「内容更新」と「改訂」とは、構造化文書の内容記述を編集する点では共通である。これら両者の区別は様々な方法で実現できる。例えば、内容更新と改訂とを別のコマンドで呼び出すようにすれば両者の区別は当然に実現できる。また、両者を同じ編集プログラムで実現した場合でも、編集を行ったのが構成編集者であれば操作種別は「改訂」とし、内容編集者であれば「内容変更」とするように、ユーザ種別に応じて区別してもよい。

なお、文書操作部２００が、操作した文書を暗号化してもよい。この暗号化は、本システムに準拠した文書操作部２００ならば、復号できるようなものとする。この場合、文書操作部２００が出力するＩＤ付き文書３００の文書内容３２０は、暗号化されることにより、本システムに準拠した文書操作部２００でないと復号できなくなる。したがって、ＩＤ付き文書３００が操作される場合には文書操作部２００が用いられるので、文書操作部２００がその操作を検知し、その操作の内容が文書操作部２００から文書管理サーバ１０に通知される。なお、文書内容３２０だけでなく、後述するメタ情報３１０（またはその一部）に対しても暗号化を施してもよい。

図２の説明に戻り、文書操作部２００は、操作結果として上述のようなＩＤ付き文書３００を作成するために、ＩＤ割り当て部２０２及びメタ情報組込部２０４を備える。ＩＤ割り当て部２０２は、操作結果のＩＤ付き文書３００に一意な操作ＩＤを付与する手段である。操作ＩＤは、少なくとも本システム内で一意な識別情報である必要がある。例えば、操作の結果生成するＩＤ付き文書３００（ただし操作ＩＤ３１２を除いたもの）のハッシュ値を求め、このハッシュ値をその文書３００のＩＤ付き文書とすればよい。ハッシュ関数としてSHA-256（SHA-256はNISTがFIPS180-2で定めた256ビットのハッシュ値を持つ暗号学的ハッシュ関数である）などのような耐衝突性を持つ暗号学的ハッシュ関数を用いれば、実用上十分な一意性を持つ操作ＩＤを生成することができる。もちろん、システム内で一意な操作ＩＤを各クライアント端末２０で生成する方法は、これに限らない。操作ＩＤを、クライアント端末２０固有の識別情報を含むものとすれば、システム内で一意な操作ＩＤを各クライアント端末２０で生成することができる。

メタ情報組込部２０４は、操作結果の文書に対しＩＤ割り当て部２０２が割り当てた新たな操作ＩＤ３１２と、その操作の元になった親文書の操作ＩＤである親ＩＤ３１４（新規登録の場合は、親ＩＤは無し）と、その操作についての履歴を表すログ情報３１６と、を含むメタ情報３１０を生成する。そして、メタ情報組込部２０４は、そのメタ情報３１０を操作結果の文書内容に付加することにより、操作後のＩＤ付き文書３００を生成して出力する。

登録処理部２１０は、文書操作部２００が出力したＩＤ付き文書３００を文書管理サーバ１０に登録するための処理を実行する。このように各クライアント端末２０が、自ら実行した操作の結果であるＩＤ付き文書３００を文書管理サーバ１０に登録することにより、文書管理サーバ１０は各ＩＤ付き文書３００間の派生関係を把握することができる。

文書操作部２００が操作の結果出力するＩＤ付き文書３００は、通常の文書ファイルと同様、電子的にコピーしたり、電子メールに添付するなどの方法で他の人宛に送信したりすることができる。他の人からＩＤ付き文書３００を受け取った人が、自分のクライアント端末２０の文書操作部２００を用いてそのＩＤ付き文書３００を操作すると、その操作に応じて新たな操作ＩＤを付与されたＩＤ付き文書が生成されることになる。

また、文書操作部２００が電子文書を印刷する場合、操作ＩＤを生成し、その電子文書の印刷結果にその操作ＩＤを埋め込んでもよい。操作ＩＤの埋め込みは、例えば電子文書の印刷画像に、操作ＩＤを示すコード画像を重畳する等の方法で行うことができる。この場合、文書操作部２００は、その操作ＩＤや操作種別「印刷」等のメタ情報を含んだＩＤ付き文書を文書管理サーバ１０に登録する。なお、ＩＤ付き文書を印刷した場合には、そのＩＤ付き文書の操作ＩＤを親ＩＤ３１４として含んだＩＤ付き文書が生成される。印刷操作に対応するＩＤ付き文書には、印刷された画像を示すページ記述言語データやビットマップ画像データなどの印刷データを、文書内容３２０として組み込んでもよい。

また、操作ＩＤが埋め込まれた紙文書を文書操作部２００が読み取った場合、文書操作部２００は、その読み取り操作に対して新たな操作ＩＤを付与し、読み取り結果の画像を文書内容３２０として含んだＩＤ付き文書を生成して文書管理サーバ１０に登録する。このＩＤ付き文書の親ＩＤ３１４には、紙文書から読み取った操作ＩＤがセットされる。操作ＩＤが埋め込まれた紙文書の複写の際には、上述した読み取り時と印刷時の処理が実行される。

次に、文書管理サーバ１０の例について説明する。文書管理サーバ１０は、システム内の複数のクライアント端末２０から送られてくるＩＤ付き文書３００を蓄積し、蓄積した情報に基づきユーザに各種のサービスを提供する。図４に示すように、文書管理サーバ１０は、文書実体ＤＢ１００，文書属性ＤＢ１０５，派生関係ＤＢ１１０，文書登録部１３０，要求処理部１４０を備える。

文書実体ＤＢ１００は、クライアント端末２０から送られてきたＩＤ付き文書３００のうちの文書内容３２０を格納するデータベース（ＤＢ）である。文書実体ＤＢ１００に格納された各文書内容３２０は、一意な内容ＩＤにより管理される。内容ＩＤとしては、例えば当該文書内容の暗号学的ハッシュ関数によるハッシュ値を用いてもよいが、これに限定されるものではない。クライアント端末２０が内容ＩＤを付与してもよく、この場合、内容ＩＤをメタ情報３１０に組み込んでもよい。

文書登録部１３０は、クライアント端末２０から受信したＩＤ付き文書の中の文書内容３２０を文書実体ＤＢ１００に登録する。また文書登録部１３０は、そのＩＤ付き文書の中のメタ情報３１０のうち、文書属性に関するログ情報３１６を文書属性ＤＢ１０５に、派生関係の情報（操作ＩＤ３１２及び親ＩＤ３１４）を派生関係ＤＢ１１０に、それぞれ登録する。そのうち、メタ情報の登録を担当するのがメタ情報登録部１３２である。

文書属性ＤＢ１０５は、ＩＤ付き文書３００のうち、文書属性を表すログ情報３１６を蓄積するデータベースである。図５に、文書属性ＤＢ１０５のデータ内容の一例を示す。図５に示した表における１行の情報が、１つのＩＤ付き文書３００に対応する文書属性レコードである。この例では、各ＩＤ付き文書３００の操作ＩＤに対応づけて、操作種別、操作者のユーザＩＤ、操作日時、部品ＩＤ、ユーザ種別の各項目が登録されている。また、図示は省略しているが、文書実体ＤＢ１００で各文書内容のデータを内容ＩＤで管理している場合には、文書属性レコードには、当該ＩＤ付き文書の文書内容の内容ＩＤも含まれる。

部品ＩＤは、当該ＩＤ付き文書の文書内容に含まれる各文書部品の識別情報である。すなわち、この実施形態では、文書管理サーバ１０が管理する電子文書は、複数の文書部品（すなわち文書要素）が木構造の階層関係をなす構造化文書である。文書部品自体が構造化されていてももちろんよい。構造化文書は、例えば、ＸＭＬ(eXtensible Markup Language)やＨＴＭＬ(Hypertext Markup Language)等の構造記述言語で記述される。ユーザは、クライアント端末２０で、個々の文書部品に部品ＩＤを付した構造化文書を作成し、文書管理サーバ１０に登録する。例えば、図６に例示する構造化文書の例（ｂ）は、ＸＭＬで記述されており（ただし、説明を簡素化するために省略を行っている）、文書部品<CONTENT>に対し部品ＩＤがＩＤ属性(partID)として組み込まれている。ちなみに、例（ｂ）は、表題<TITLE>と内容<CONTENT>という部品ペアを含んだ部品<H1>を２つ含んだ構造化文書である。表題<TITLE>には、表題の文字列がテキスト属性(TEXT)の値として含まれている。この例（ｂ）には、内容部品<CONTENT>の文字列は含まれていない。仮に例（ｂ）の構造化文書を表示すると、図６の表示例（ａ）のようなものとなる。表示例（ａ）には、表題の文字列は示されているが、内容は空欄となっている。

ＩＤ付き文書の文書属性レコードのうちの部品ＩＤフィールドには、その文書の文書内容３２０に含まれる全ての部品ＩＤが列挙される。

ＩＤ付き文書の文書属性レコードのユーザ種別フィールドには、ユーザＩＤフィールド内のユーザＩＤを持つユーザの、文書作成業務上の種別が示される。図５の例では、ユーザ種別には「構成編集者」と「内容編集者」がある。構成編集者は文書全体の構造又は構成（例えば論理構成、あるいは論理構成を含む章立て構成）の編集を担当する者であり、内容編集者はその文書に含まれる文書部品の内容（例えば文字列、グラフィックス、スプレッドシート、写真画像など）の編集を担当する者である。この実施形態では、構成編集者がＸＭＬ等で文書の構成を記述したＩＤ付き文書を作成し、各内容編集者がそのＩＤ付き文書を取得し、そのＩＤ付き文書のうち各自の担当する文書部品の内容を作成する、という枠組みで１つの文書を作成する。

以上に例示した文書属性レコードの項目は、あくまで一例に過ぎない。文書属性レコードは例示した項目を全て含んでいなくてもよいし、また例示した以外の項目を含んでいてもよい。

なお、図５は文書属性ＤＢ１０５が管理するデータを内容の観点から表現したものにすぎず、具体的な表現形式或いはデータベース形式を規定するものではない。例えば、文書属性ＤＢ１０５は、一般的なリレーショナルデータベースとして構築することもできるし、操作ＩＤを除くメタ情報を記述したＸＭＬ文書を、操作ＩＤをキーとして登録したデータベースとして構築することもできる。

以上、文書属性ＤＢ１０５について説明した。メタ情報登録部１３２は、クライアント端末２０からＩＤ付き文書３００を受信した場合、文書属性ＤＢ１０５にその文書３００のためのレコードを作成し、そのレコードの各項目にその文書３００中のログ情報３１６に含まれる各項目の値を登録する。

派生関係ＤＢ１１０は、ＩＤ付き文書間の派生関係（親子関係）の情報を記憶するデータベースである。派生関係ＤＢ１１０に登録されたデータ内容の一例を図７に示す。図７の例では、ＩＤ付き文書の操作ＩＤに対応づけて、その文書から派生した子のＩＤ付き文書の操作ＩＤ（図では「子ＩＤ」と表記）のリストが登録されている。例えば、操作ＩＤ３１２が“ＩＤ２”で親ＩＤ３１４が“ＩＤ１”であるＩＤ付き文書３００が入力された場合、メタ情報組込部２０４は、派生関係ＤＢ１１０の操作ＩＤ“ＩＤ１”のレコードの子ＩＤのリストに、その文書３００内の操作ＩＤ３１２の値“ＩＤ２”を追加する。図７に例示したデータ内容は、図５に例示した文書属性レコード群に対応している。なお、図７のようなデータ構造は一例に過ぎない。例えばこの代わりに、ＩＤ付き文書の操作ＩＤに対応づけてその文書の親文書の操作ＩＤ（親は必ず１つである）を保持するデータ構造を用いてもよい。また、それら両方を派生関係ＤＢ１１０に記憶するようにしてもよい。

図７に示した派生関係ＤＢ１１０のデータ内容は、図８のような木構造を成す。これは、操作ＩＤをノードとし、操作ＩＤ間の親子関係をエッジとする木構造である。

図５，図７及び図８の例が示す文書の履歴を時系列順に説明すると、以下のようになる。この例は、複数の文書部品を含む１つの文書を複数人が共同編集する作業を文書管理サーバ１０により実現する例である。

この例では、まず構成編集者であるユーザ１が、自分のクライアント端末２０で、これから内容編集者達と共に共同編集しようとする文書の構成を例えばＸＭＬで記述した電子文書を作成する。作成された電子文書は、操作ＩＤ“ＩＤ１”を付与され、文書管理サーバ１０に登録される（図５の最初のレコード参照）。ここでは、この文書“ＩＤ１”が図６に例示した構造化文書であるとする。この場合文書属性レコードの部品ＩＤ欄には、部品ＩＤ“＃１”及び“＃２”が記録される。なお、文書中に含まれる各文書部品の部品ＩＤは、クライアント端末２０のメタ情報組込部２０４及び文書管理サーバ１０のメタ情報登録部１３２のいずれかが検出すればよい。例えば、部品ＩＤは属性名“partID”の属性値として記述するという取り決めをしておけば、文書内容の文字列を解析して“partID”の値を検出して記録することで、文書中に含まれる文書部品の部品ＩＤを抽出できる。なお、文書“ＩＤ１”の各部品“＃１”及び“＃２”の内容<CONTENT>は空である。

また、クライアント端末２０又は文書管理サーバ１０は、自身が持つ、あるいはネットワーク上のサーバに記憶されたユーザＩＤとユーザ種別の対応関係の情報を参照することで、文書に対して操作を行ったユーザに対応するユーザ種別を求めればよい。

内容編集者は、文書管理サーバ１０にアクセスして、あるいは構成編集者から電子メール等を経由して、文書構成を記述したＩＤ付き文書を取得する。内容編集者は、受け取ったＩＤ付き文書の文書内容から、自分が担当する文書部品以外の文書部品を削除し、自分の担当する文書部品の内容を作成又は編集する。なお、自分が担当する文書部品以外の文書部品を削除することは、後の処理において、それぞれの担当者が編集をした文書部品を特定するために行うのであって、削除自体は本発明にとっては本質的ではなく、削除せずに文書内容中における編集された文書部品を特定することもできる。例えば編集前の文書と編集後の文書の差分を作ることで、編集箇所を特定することができる。差分を計算するアルゴリズムは、例えばE. Myers (1986). “An O(ND) Difference Algorithm and Its Variations”. Algorithmica 1 (2): 251-266.に詳しい。別の方法では、編集した文書部品に編集日時属性を付与し、編集前の文書の編集日時と比較することによって、それ以降の編集日時を持つ文書部品を編集箇所として特定することができる。

この例では、文書部品“＃１”を担当するユーザ２及び文書部品“＃２”を担当するユーザ３が文書“ＩＤ１”を取得する。

次にユーザ２が、自分のクライアント端末２０でその文書“ＩＤ１”を開き、その文書から文書部品“＃２”を削除し、文書部品“＃１”の内容を作成する。この結果作成された文書は、操作ＩＤ“ＩＤ２”を付与され、文書管理サーバ１０に登録される（図５の２番目のレコード参照）。ここでは文書“ＩＤ２”が図９に示した例（ｂ）のような構造化文書であるとする。この構造化文書の表示例が、図９の例（ａ）である。

次に、構成編集者であるユーザ１が文書“ＩＤ１”を開いて文書構成を改訂したとする。この改訂では、図１０に示すように、１番目及び２番目の文書部品の表題<TITLE>の文字列を変更すると共に、３番目の文書部品“＃３”を追加している。図１０の例（ｂ）は改訂された文書構成を記述した構造化文書を示し、例（ａ）はその構造化文書の表示例を示す。改訂された文書は、操作ＩＤ“ＩＤ３”を付与され、文書管理サーバ１０に登録される（図５の３番目のレコード参照）。

次にユーザ３が、取得した文書“ＩＤ１”を開き、その文書から文書部品“＃１”を削除し、文書部品“＃２”の内容を作成する。この結果作成された文書は、操作ＩＤ“ＩＤ４”を付与され、文書管理サーバ１０に登録される（図５の４番目のレコード参照）。ここでは文書“ＩＤ４”が図１１に示した例（ｂ）のような構造化文書であるとする。この構造化文書の表示例が、図１１の例（ａ）である。

次にユーザ４が、文書“ＩＤ３”を取得して開き、その文書から文書部品“＃１”及び“＃２”を削除し、文書部品“＃３”の内容を作成する。この結果作成された文書は、操作ＩＤ“ＩＤ５”を付与され、文書管理サーバ１０に登録される（図５の５番目のレコード参照）。ここでは文書“ＩＤ４”が図１２に示した例（ｂ）のような構造化文書であるとする。この構造化文書の表示例が、図１２の例（ａ）である。

そして、ユーザ２が、先に作成した文書“ＩＤ２”を開き、文書部品“＃２”の内容を編集する。この結果内容が変更された文書は、操作ＩＤ“ＩＤ６”を付与され、文書管理サーバ１０に登録される（図５の６番目のレコード参照）。ここでは文書“ＩＤ６”が図１３に示した例（ｂ）のような構造化文書であるとする。この構造化文書の表示例が、図１３の例（ａ）である。

以上、このシステムにおける文書操作の情報の登録の様子を説明した。

図４の説明に戻り、要求処理部１４０は、クライアント端末２０からの操作ＩＤを含んだサービス要求に応じて、文書実体ＤＢ１００，文書属性ＤＢ１０５及び派生関係ＤＢ１１０を用いたサービスを提供する。

サービス要求は、クライアント端末２０に保持されたＩＤ付き文書に基づき発せられる。例えば、ユーザがクライアント端末２０の文書操作部２００によりＩＤ付き文書を開いた場合に、文書操作部２００が、派生関係を用いたサービスのメニューを提供し、そのメニューの中からユーザが所望するサービスの指定を受け付ける。そして、そのＩＤ付き文書の操作ＩＤと指定されたサービスを示すコードとを含むサービス要求を文書管理サーバ１０の要求処理部１４０に送信する。なお、操作ＩＤと、サービスを示すコード以外に、指示を行ったユーザの識別情報や、ユーザの入力した認証情報などといった他の情報を、クライアント端末２０から要求処理部１４０に送信するようにしてもよい。

また、別の例として、ＩＤ付き文書というオブジェクト種類に対して、そのようなサービスのメニューを対応づけてクライアント端末２０のオペレーティングシステムに登録しておいてもよい。

また別の例として、ユーザによるサービスの指定を一つの「操作」と捉え、その「操作」に対して新たに操作ＩＤを付与することも考えられる。この場合、指定されたサービスのコードを操作種別として含み、指定の際に用いられた元のＩＤ付き文書の操作ＩＤを親ＩＤとして含んだＩＤ付き文書を生成し、このＩＤ付き文書をサービス要求として文書管理サーバ１０に送ってもよい。この場合、要求処理部１４０は、受け取ったＩＤ付き文書内の操作種別の情報に基づき提供すべきサービスを判定し、同じくＩＤ付き文書内の親ＩＤを、派生関係を遡る処理の起点とする。

要求処理部１４０は、クライアント端末２０からサービス要求を受けた場合、そのサービス要求中に指定された操作ＩＤを起点に、派生関係ＤＢ１１０に登録された操作ＩＤと親ＩＤとの派生関係群が構成する木を走査（トラバース）し、その走査の結果得られた情報を用いて、ユーザから要求されたサービスを実行する。

要求処理部１４０が提供するサービスとして、以下では共同編集の実現のために文書部品群を合成するサービスを説明する。このサービスのために、要求処理部１４０は、文書合成部１４２及び文書検索部１４４を備える。文書合成部１４２は、複数の文書部品を合成するための処理を行う。文書検索部１４４は、文書合成部１４２から要求された文書部品を検索する。

構成編集者が自分のクライアント端末２０で、文書構成を示すＩＤ付き文書（図５，図７及び図８の例では文書“ＩＤ３”）を用いて文書合成を指示すると、その指示が文書合成部１４２に伝わる。クライアント端末２０は、例えば、当該端末２０を操作しているユーザが構成編集者である場合、そのＩＤ付き文書に対する操作として「文書合成」を選択可能とするような制御を行ってもよい。この指示を受けると、クライアント端末２０は、その指示に用いられた文書の操作ＩＤ（上述の例では“ＩＤ３”）を含んだ文書合成の指示を文書管理サーバ１０に送る。

この指示を受け取った文書管理サーバ１０は、文書合成部１４２を呼び出す。これに応じて文書合成部１４２が実行する処理手順の一例を図１４に示す。

この手順では、文書合成部１４２は、まず、文書合成指示の対象に指定された文書（すなわち、その指示に含まれる操作ＩＤに対応する文書。「指定文書」と呼ぶ）の文書内容を文書実体ＤＢ１００から取得し、その文書内容を解析することで、指定文書の文書構成（すなわち文書部品群が構成する論理構造又は章立て構造）を求め（Ｓ１）、その文書内容の中に含まれる部品ＩＤのリストを生成する（Ｓ２）。このリストには、共同編集文書を合成するために必要な文書部品の部品ＩＤが列挙されることになる。例えば、指定文書が図５に示した文書“ＩＤ３”（図１０の例（ｂ）参照）であれば、このリストには部品ＩＤ“＃１”，“＃２”，“＃３”が含まれることになる。

次に文書合成部１４２は、文書検索部１４４に対し、指定文書の文書ファミリーの収集を要求する（Ｓ３）。ここでいう文書ファミリーは、派生関係ＤＢ１１０に含まれる派生関係群が構成する１以上の木のうちで、指定文書が属する木に含まれるＩＤ付き文書の集合のことである。ただし、ここでは、共同編集文書の合成が目的なので、その木に含まれるＩＤ付き文書のうち、操作種別が「内容更新」に該当するものだけを収集することとし、その収集の結果できる文書の集合を文書ファミリーと呼ぶ。文書管理サーバ１０に登録されるＩＤ付き文書の中には、閲覧や印刷などといった文書内容の更新を伴わない操作の結果もあるので、そのようなものは収集の対象から外すのである。また、操作種別が「改訂」であるＩＤ付き文書は文書構成を示すものであるが、共同編集文書の文書構成は指定文書から求めることができるので、そのようなＩＤ付き文書は収集する必要がない。

この収集の要求を受けた場合、文書検索部１４４は、派生関係ＤＢ１１０を参照して、指定文書を先祖に遡ることで、指定文書が属する木の根を特定する。例えば、図５，図７及び図８の例で、指定文書が“ＩＤ３”である場合、派生関係ＤＢ１１０（図７参照）により“ＩＤ３”の親が“ＩＤ１”と特定でき、“ＩＤ１”の親は見つからないので、“ＩＤ１”が根であると判定できる。そして、特定した根を起点に、派生関係ＤＢ１１０の情報を用いて、その根から伸びる木の各ノード（操作ＩＤ）を行きがけ順に巡回し、その巡回の過程で行き当たった操作ＩＤのうち操作種別が「内容更新」であるものの文書属性と文書実体を文書属性ＤＢ１０５及び文書実体ＤＢ１００から収集する。そして、収集した文書属性と文書実体の各ペアを、収集順序と共に記録する。文書検索部１４４が収集した文書ファミリーの情報の例を図１５に示す。これは、図５，図７及び図８の例に対応するものである。例示のように、文書ファミリー情報に含まれる各レコードは、収集順序の番号、文書属性（「操作ＩＤ」〜「部品ＩＤ」）、及び文書実体（「内容」）を含む。文書検索部１４４は、収集した文書ファミリー情報を文書合成部１４２に渡す。

再び図１４の説明に戻る。文書合成部１４２は、文書検索部１４４から文書ファミリー情報を受け取ると（Ｓ４）、収集順序の若い順にレコードを取り出し（Ｓ５）、取り出したレコード中の文書実体（「内容」）を、ステップＳ２で作成したリスト中の対応する部品ＩＤ（すなわち当該レコード中の部品ＩＤと同じ値の部品ＩＤ）に関連づけて登録する（Ｓ６）。以上のステップＳ５及びＳ６の処理を、文書ファミリー情報の全レコードの処理が終わるまで繰り返す（Ｓ７）。

ここで、ステップＳ６では、リスト中の対応する部品ＩＤに対応づけて既に文書実体が登録されている場合は、取得したレコード中の文書実体を既に登録されている文書実体に上書きする。収集順序は根からの行きがけ順に巡回した場合の巡回順序なので、収集された文書ファミリーに同じ部品ＩＤのレコードが複数ある場合は、最終的には、それらレコードのうち派生関係の木において最も子孫側の操作ＩＤに対応するレコードの文書実体がリストに残ることになる。例えば、図１５の例には、部品ＩＤ“＃１”のレコードが２つあるが、そのうち収集順序が最も後ろの操作ＩＤ“ＩＤ６”に対応する文書実体（「本章ではシステムの概要を説明します。…）がリストに残ることとなる。

文書ファミリー情報の全レコードについてステップＳ５及びＳ６の処理が終わると、文書合成部１４２は、リストに含まれる各文書部品の文書実体（内容）をステップＳ１で求めた文書構成における各文書部品の論理的位置に組み込むことで、共同編集結果の文書を合成する（Ｓ８）。

図５，図７，図８及び図１５の例では、部品ＩＤ“＃１”に操作ＩＤ“ＩＤ６”の文書実体、部品ＩＤ“＃２”には操作ＩＤ“ＩＤ４”の文書実体、部品ＩＤ“＃３”には操作ＩＤ“ＩＤ５”の文書実体、を組み込んだ合成文書（図１６の例（ｂ）参照）が生成される。図１６の例（ａ）は、この合成文書の表示例を模式的に示したものである。

この例では、ユーザ２及びユーザ３が文書構成を示すＩＤ付き文書“ＩＤ１”を受け取った後に、その文書が改訂されてＩＤ付き文書“ＩＤ３”となり、文書部品が増えると共に、既存の文書部品の表題の文字列も変更される。しかし、ユーザ２及びユーザ３は、そのような変更を意識することなく、自分が取得した文書“ＩＤ１”の中で自分の担当する文書部品の文書内容を編集して、文書管理サーバ１０に登録するだけでよい。表題の文字列は、文書構成を示す文書“ＩＤ３”から採られるので、ユーザ２及びユーザ３は表題の文字列を変更しなくてもよい。

以上、文書合成部１４２による合成処理について説明したが、このような合成処理は、特開２００４−８６８５５号公報に記載された方式や、特開２００７−１５６９６５号公報に記載された方式で実現することができる。以下では、後者の方式で実現する場合の処理例を説明する。

特開２００７−１５６９６５号公報には、テンプレートを用いて複数の構造化文書から必要な部分を取捨選択して１乃至複数の電子文書を組み立てるための方法が開示されている。以下では、この文献に示された処理方法のことを「テンプレート処理」と呼ぶことにする。

章立て等の文書構成を表す構造化文書は、個々の文書部品の内容に比して文書構造が定型的であり、計算機の処理で繰り返し構造を検出するのが容易である。特にＸＭＬやＳＧＭＬのエディタを使う場合は、文書構成を表す構造化文書をＤＴＤ（文書型定義）に基づき論理構造が制限された形で編集することができる。したがって、章ごとの繰り返しを検出すことで、テンプレートと、流し込みに用いるデータとして、ディレクトリレコードを生成する。ディレクトリレコードは、文書の論理構造の表現形式の一形態であり、内容的にはＸＭＬ文書又はＤＯＭツリーで表現された構造と等価である。ディレクトリレコードの詳細については、特開２００７−１５６９６５号公報を参照されたい。

この処理では、まず、ユーザから文書合成の種文書として指定された構造化文書（例えば図５，図７及び図８の例での文書“ＩＤ３”）を公知のパーサー(parser)で構文解析する。この例では、構文解析により、種文書の要素（部品）間の論理構造を示す情報として、パースツリー(parse tree)を生成する。種文書が図１０の例（ｂ）に示すものであった場合に生成されるパースツリーを図１７に例示する。

次に、そのパースツリーのノード群を根から行きがけ順に巡回する際に、変換ルールを適用することで、流し込みに用いるテンプレートとディレクトリレコードを生成する。ここでは、一例として、図１８に示す変換ルールセットを用いる。

変換ルールセットは１以上のルールから構成される。個々のルールは、「要素条件」、「巡回条件」、「出力文字列」、「収集する属性」、「ディレクトリ属性」の各項目を含む。

パースツリーの巡回の中でノードに到達するごとに、そのノード（注目ノードと呼ぶ）が各ルールの「要素条件」及び「巡回条件」を満たすかどうかを検査する。そして、注目ノードがあるルールの「要素条件」及び「巡回条件」を満たした場合、そのルールにおける「出力文字列」、「収集する属性」、「ディレクトリ属性」の各項目の値に従ってテンプレートやディレクトリレコードを生成する。

「要素条件」は、注目ノードが表す要素（部品）についての条件であり、ここでは要素名についての条件が示される。

「巡回条件」は、注目ノードに到達したのが巡回経路において親ノードの次である（「下行」）か、子ノードの次である（「上行」）かの条件を示す。

注目ノードがあるルールの「要素条件」と「巡回条件」の両方を満たしたときに、この生成処理では、そのルールの項目「出力文字列」をテンプレートに出力する。例えば、根の次に要素名“Ｈ１”のノードに到達した場合、要素条件「Ｈ１」かつ巡回条件「下行」が満たされるので、そのノードには図１８のセットのうちの最も上のルールが適用されることになり、テンプレートには文字列“{{<H1>”が追加されることになる。

また、図１８のセットの３つめのルールにおける出力文字列「TITLE TEXT=”$H1.partID$”」のうち「$H1.partID$」は、変数要素を示している。変数要素は、変数名と属性名とにより示され、その前後を「$」で囲むことで表現される。テンプレート適用の際に、変数名がノードの要素名にマッチした場合に、変数要素の属性名に合致する当該ノード（又はその子孫ノード）の属性の値が、その変数要素に代入される。すなわち、テンプレート適用の際には、「$H1.partID$」には、<H1>要素（又はその子孫）に含まれる“partID”属性の値が代入されることになる。また、図１８のセットの４つめのルールにおける「$H1.body$」は内容データを表す変数要素であり、テンプレート適用の際にはその要素には<H1>要素の子孫の<CONTENT>要素に含まれる内容データの値が代入される。

「収集する属性」は、種文書に記述された注目ノードの属性のうち、ディレクトリレコードに収集する属性を指定する。この例では、「収集する属性」をＸＰＡＴＨ(XML Path Language)で記述している。例えば、“TITLE/@TEXT”との記述は、注目ノードの子ノードのうちTITLE要素のテキスト属性を収集対象として指定したことになる。

「ディレクトリ属性」は、「収集する属性」の値をディレクトリレコード中のどのカラムに書き込むかを指定する。

例えば、図１８のセットのうちの最も上のルールが満足された場合、注目ノードの子であるTITLE要素のテキスト属性がディレクトリレコードの“title”欄に、注目ノードの子であるCONTENT要素の“partID”属性がディレクトリレコードの“partID”欄にそれぞれ書き込まれることになる。

なお、この生成処理では、ルールを満たした注目ノードについて、「収集する属性」で指定された属性値に加えて、「アドレス情報(s_address)」と「要素名(s_tag)」とをディレクトリレコードに書き込む。

「アドレス情報」は、特開２００７−１５６９６５号公報における「コンテキスト識別子」と同じものであり、文書のノード（要素）群がなすツリーにおいて注目ノードが占める位置を表す。「アドレス情報」は、例えば、文書の根から数えて、パス区切り記号('/')で区切った兄弟順位からなる文字列で表現できる。根は'/'で表現される。例えば、図１０の例（ｂ）に含まれる３つの要素“<H1>”はいずれも根の直下にあるので、各々のアドレス情報はその出現順に'/1'，'/2'，'/3'となる。「アドレス情報」は、ディレクトリレコードでは“s_address”欄に書き込まれる。

また、「要素名」は注目ノードの要素名であり、例えば当該要素のタグに示されるタグ名を用いることができる。文書の根の要素名は“root”とする。「要素名」は、ディレクトリレコードでは“s_tag”欄に書き込まれる。

テンプレート生成処理では、図１７に例示した文書構造に対して図１８に例示した変換ルールセットを適用した場合、図１９に例示するテンプレートと、図２０に例示するディレクトリレコードとが得られる。なお、図２０のディレクトリレコードの“body”欄は、<CONTENT>要素に含まれる内容データを保持するための欄である。テンプレートを適用する際に、この欄に内容データが書き込まれる。

以上のようにして種文書（図１４のステップＳ１で指定された指定文書）からテンプレートと、ディレクトリレコードのひな形とが生成されると、次に、文書合成部１４２は、ステップＳ４で収集された文書ファミリー（図１５参照）とディレクトリレコードのひな形とをつき合わせて、ディレクトリレコードを完成させる。すなわち、文書ファミリーのレコードを収集順序の順に取り出し、取り出したレコードの「内容」欄の値を、当該レコードと同じpartIDを持つディレクトリレコード中のレコードのbody欄に書き込む。当該body欄に既に内容が書き込まれている場合は、取り出したレコードの「内容」欄の値を既に書き込まれている内容に上書きする。以上のようにして、ディレクトリレコードが完成する。図５〜図１５の具体例の場合、完成したディレクトリレコードは図２１に示すようなものとなる。

ディレクトリレコードが完成すると、文書合成部１４２は、これにテンプレートを適用することで、共同編集結果の文書を完成させる。ディレクトリレコードに対するテンプレートの適用処理では、特開２００７−１５６９６５号公報の例えば段落００４９〜００８４に例示される処理を行えばよい。このような処理により、例えば図１６の例（ｂ）に例示したような共同編集結果の文書が生成される。

このように、以上に説明した実施の形態によれば、内容編集者は、自分の担当する文書部品を文書管理サーバ１０に登録する際に、その文書部品が構造化文書中のどの部分に該当するのかを指定しなくてもよい。また、内容編集者による文書部品の作成・編集と構成編集者による構成の編集が並行的に実行できる。また、構成編集者が文書構成を改訂した後に、内容編集者が文書部品の内容を更新した場合でも、内容編集者はその更新後の文書を改訂後の文書構成のどの部分に反映させるかを指定する必要がない。

以上に例示した実施形態では、操作ＩＤの発行は各クライアント端末２０で行われていたが、この代わりに文書管理サーバ１０が操作ＩＤを発行してもよい。この場合、クライアント端末２０は、ＩＤ付き文書に対して操作を行った場合、操作前のＩＤ付き文書内の操作ＩＤを親ＩＤ３１４として含み、更にその操作についてのログ情報３１６と操作後の文書内容３２０とを含み、操作ＩＤ３１２は空欄の文書データを生成し、文書管理サーバ１０に送る。文書管理サーバ１０は、受け取った文書データに対して新たな操作ＩＤを付与し、この操作ＩＤとその文書データとに含まれる情報を、文書実体ＤＢ１００及び文書属性ＤＢ１０５及び派生関係ＤＢ１１０に登録する。また、文書管理サーバ１０は、付与した操作ＩＤを当該文書データにセットすることによりＩＤ付き文書を生成し、これをクライアント端末２０に返す。クライアント端末２０は、操作前のＩＤ付き文書を、受け取ったＩＤ付き文書に置き換える。このように、文書管理サーバ１０が操作ＩＤを付与する構成でも、上述実施形態の処理は同様に実行できる。

また以上の実施形態では、操作ＩＤ３１２、親ＩＤ３１４、ログ情報３１６、及び文書内容３２０を含んだＩＤ付き文書３００がクライアント端末２０に保存されたが、この代わりに、クライアント端末２０は操作ＩＤしか持たず、その他の情報は文書管理サーバ１０に保存されるようにしてもよい。この場合、クライアント端末２０で文書を操作する場合、その文書に対応する操作ＩＤを文書管理サーバ１０に送り、文書管理サーバ１０からその文書を取得する。

ここで、文書管理サーバ１０が操作ＩＤを付与する場合は、その取得の操作に対応する操作ＩＤを文書管理サーバ１０が生成し、その操作ＩＤと文書とを対応づけてクライアント２０に提供するとともに、その取得操作についてのログ情報（操作時刻や操作者など）と、元の操作ＩＤ（すなわち親ＩＤ）と、付与した操作ＩＤとを派生関係ＤＢ１１０に記録する。クライアント端末２０は、文書管理サーバ１０に送信した操作ＩＤを、受け取った操作ＩＤに置き換えると共に、受け取った文書を開く。ユーザは、開かれた文書に対して閲覧や編集などの操作を行う。クライアント端末２０は、文書に対する操作が完了すると、操作後の文書を操作ＩＤ及び当該操作についてのログ情報と共に文書管理サーバ１０に送る。文書管理サーバ１０は、受け取った文書に対して新たな操作ＩＤを付与して派生関係ＤＢ１１０に登録し、受け取った操作ＩＤを親ＩＤとして派生関係ＤＢ１１０に登録する。また、受け取ったログ情報及び操作後の文書を、文書属性ＤＢ１０５及び文書実体ＤＢ１００に登録する。そして、文書管理サーバ１０は、新たに付与した操作ＩＤをクライアント端末２０に返す。クライアント端末２０は、元の操作ＩＤを受け取った操作ＩＤで置き換える。以上のような処理により、操作間の派生関係が文書管理サーバ１０に蓄積されることになる。

一方、クライアント端末２０が操作ＩＤを付与する構成の場合は、文書管理サーバ１０は、クライアント端末２０から受け取った操作ＩＤに対応する文書をクライアントに返せばよい。クライアント端末２０は受け取った文書を開き、ユーザがその文書を操作する。操作の完了後、クライアント端末２０はその操作結果の文書に対して新たな操作ＩＤを付与し、この操作ＩＤを含んだ前述のＩＤ付き文書と同様の情報を、文書管理サーバ１０に送る。そして、クライアント端末２０は、そのＩＤ付き文書のうち操作ＩＤのみを保存し、その他の情報を削除する。

以上に例示した実施の形態及び変形例における文書管理サーバ１０は、例えば、汎用のコンピュータに上述の各機能モジュールの処理を表すプログラムを実行させることにより実現される。ここで、コンピュータは、例えば、ハードウエアとして、図２２に示すように、ＣＰＵ１０００等のマイクロプロセッサ、ランダムアクセスメモリ（ＲＡＭ）１００２およびリードオンリメモリ（ＲＯＭ）１００４等のメモリ（一次記憶）、ＨＤＤ（ハードディスクドライブ）１００６を制御するＨＤＤコントローラ１００８、各種Ｉ／Ｏ（入出力）インタフェース１０１０、ローカル・エリア・ネットワークなどのネットワークとの接続のための制御を行うネットワークインターフェイス１０１２等が、たとえばバス１０１４を介して接続された回路構成を有する。また、そのバス１０１４に対し、例えばＩ／Ｏインタフェース１０１０経由で、ＣＤやＤＶＤなどの可搬型ディスク記録媒体に対する読み取り及び／又は書き込みのためのディスクドライブ１０１６、フラッシュメモリなどの各種規格の可搬型の不揮発性記録媒体に対する読み取り及び／又は書き込みのためのメモリリーダライタ１０１８、などが接続されてもよい。上に例示した各機能モジュールの処理内容が記述されたプログラムがＣＤやＤＶＤ等の記録媒体を経由して、又はネットワーク等の通信手段経由で、ハードディスクドライブ等の固定記憶装置に保存され、コンピュータにインストールされる。固定記憶装置に記憶されたプログラムがＲＡＭ１００２に読み出されＣＰＵ１０００等のマイクロプロセッサにより実行されることにより、上に例示した機能モジュール群が実現される。なお、それら機能モジュール群のうちの一部又は全部を、専用ＬＳＩ(Large Scale Integration)、ＡＳＩＣ（Application Specific Integrated Circuit、特定用途向け集積回路）又はＦＰＧＡ（Field Programmable Gate Array）等のハードウエア回路として構成してもよい。

文書管理システムの概略構成の例を示すブロック図である。 クライアント端末の内部構成の例を示すブロック図である。 ＩＤ付き文書のデータ構造の例を模式的に示す図である。 文書管理サーバの内部構成の例を示すブロック図である。 文書属性ＤＢのデータ内容の一例を示す図である。 文書構成を表す構造化文書の表示例及びＸＭＬでの記述例を示す図である。 派生関係ＤＢのデータ内容の一例を示す図である。 派生関係がなす木構造の一例を示す図である。 文書部品の内容を記述した構造化文書の表示例及びＸＭＬでの記述例を示す図である。 改訂された文書構成を表す構造化文書の表示例及びＸＭＬでの記述例を示す図である。 別の文書部品の内容を記述した構造化文書の表示例及びＸＭＬでの記述例を示す図である。 更に別の文書部品の内容を記述した構造化文書の表示例及びＸＭＬでの記述例を示す図である。 修正された文書部品の内容を記述した構造化文書の表示例及びＸＭＬでの記述例を示す図である。 文書合成部の処理手順の一例を示すフローチャートである。 文書検索部が収集した文書ファミリーの情報の一例を示す図である。 文書合成部が出力する共同編集結果の文書の表示例及びＸＭＬでの記述例を示す図である。 具体例の文書のパースツリーを示す図である。 パースツリーに対して適用する変換ルールセットの一例を示す図である。 生成されるテンプレートの例を示す図である。 生成されるディレクトリレコードのひな形の例を示す図である。 完成したディレクトリレコードの例を示す図である。 コンピュータのハードウエア構成の一例を示す図である。

符号の説明

１０ 文書管理サーバ、２０ クライアント端末、３０ ネットワーク、１００ 文書実体ＤＢ、１０５ 文書属性ＤＢ、１１０ 派生関係ＤＢ、１３０ 文書登録部、１３２ メタ情報登録部、１４０ 要求処理部、１４２ 文書合成部、１４４ 文書検索部、２００ 文書操作部、２０２ ＩＤ割り当て部、２０４ メタ情報組込部、２１０ 登録処理部、３００ ＩＤ付き文書。

Claims (2)

1. 情報処理装置から、第１の構造化文書に対して行われた操作の種類と、当該操作の結果である第２の構造化文書と、を受信した場合に、前記操作の種類と前記第２の構造化文書とを対応づけて記憶装置に登録すると共に、前記第２の構造化文書が前記第１の構造化文書の子であることを示す派生関係を前記記憶装置に登録する登録手段と、
   前記記憶装置に記憶された派生関係群がなす木構造のうちユーザから指定された構造化文書を含む木に属する構造化文書であって、対応する操作の種類が文書内容の更新に該当する構造化文書を特定する特定手段と、
   前記指定された構造化文書に含まれる各文書部品の部品識別子を特定し、それら各部品識別子を持つ構造化文書を前記特定手段が特定した構造化文書群の中から検索する検索手段であって、前記特定手段が特定した構造化文書群の中に同じ部品識別子を持つ構造化文書が複数あった場合はそれら複数のうち前記木において最も葉に近いものを検索することを特徴とする検索手段と、
   前記検索手段が検索した前記各部品識別子を持つ構造化文書を、前記指定された構造化文書における前記各部品識別子に対応する要素に組み込むことで、合成文書を生成する生成手段と、
   を備える文書合成システム。
2. コンピュータを、
   情報処理装置から、第１の構造化文書に対して行われた操作の種類と、当該操作の結果である第２の構造化文書と、を受信した場合に、前記操作の種類と前記第２の構造化文書とを対応づけて記憶装置に登録すると共に、前記第２の構造化文書が前記第１の構造化文書の子であることを示す派生関係を前記記憶装置に登録する登録手段、
   前記記憶装置に記憶された派生関係群がなす木構造のうちユーザから指定された構造化文書を含む木に属する構造化文書であって、対応する操作の種類が文書内容の更新に該当する構造化文書を特定する特定手段、
   前記指定された構造化文書に含まれる各文書部品の部品識別子を特定し、それら各部品識別子を持つ構造化文書を前記特定手段が特定した構造化文書群の中から検索する検索手段であって、前記特定手段が特定した構造化文書群の中に同じ部品識別子を持つ構造化文書が複数あった場合はそれら複数のうち前記木において最も葉に近いものを検索することを特徴とする検索手段、
   前記検索手段が検索した前記各部品識別子を持つ構造化文書を、前記指定された構造化文書における前記各部品識別子に対応する要素に組み込むことで、合成文書を生成する生成手段、
   として機能させるためのプログラム。

Images