JP2021089665A - 情報処理装置及びプログラム - Google Patents

Abstract

【課題】ある文書に変更が行われた場合にその文書に関係のある文書の関与者にその変更を知らせる情報処理装置及びプログラムを提供する。【解決手段】設計書管理システムにおいて、文書要素Ｂ−５（変更要素と呼ぶ）が変更されると、これを参照する文書要素Ａ−１（通知対象要素と呼ぶ）の関与者（＝ユーザ１）に対して、通知対象要素の変更の要否を確認する通知を送る。その関与者がその通知に応答できない場合、変更要素を参照する他の文書要素Ａ−３の関与者（＝ユーザ３）にその通知を送る。ユーザ３がその通知に応答できない場合、通知対象要素に類似する文書要素Ａ−２の関与者（＝ユーザ２）に対して通知を送る。【選択図】図１０

Description

本発明は、情報処理装置及びプログラムに関する。

世の中には相互に関係を持つ文書があふれている。相互に関係を持つ文書のうちの１つに変更が行われると、それに応じて残りのいくつかの文書に変更が必要になる場合がある。ある文書に変更が行われた場合にその文書に関係のある文書の関与者（例えば著者）にその変更を知らせることにより、その関係のある文書の変更等といった必要な対処を促す仕組みがある。

特許文献１には、複数のユーザが共有する文書データに関わるデータ処理をする文書データ処理装置が開示されている。この文書データ処理装置は、文書データを編集するユーザである現在の編集者によって当該文書データの更新が指示されたときに、予め複数のレベルに分類された更新の各レベルの態様を示すレベル設定情報に基づいて、指示された更新のレベルを判定する判定部と、前記複数のレベルごとに通知の要否および通知をする場合の通知先を定めた通知設定情報を参照し、前記判定部によって判定されたレベルが通知をするべきレベルであった場合に、前記判定されたレベルにおける通知先として定められたユーザに、指示された前記更新における文書データの変更箇所を含む変更内容を通知する通知部と、を備える。

特開２０１２−１５０６４７号公報

第１文書要素に変更があった場合に、第１文書要素に関係のある第２文書要素の関与者に対して、その変更に応じた第２文書要素の変更要否の確認を求める通知を行うシステムがある。この種のシステムでは、第２文書要素の関与者がいない場合や、その関与者がその通知に応答しない場合、第１文書要素の変更に応じた第２文書要素の変更の要否の確認や変更が適切に行われない。

本発明は、第１文書要素に関係のある第２文書要素の関与者のみに、第１文書の変更に応じた第２文書要素の変更要否の確認を求める通知を送る場合よりも、その変更に対する第２文書要素の変更要否の確認がなされる機会を増加させることを目的とする。

請求項１に係る発明は、プロセッサを備え、前記プロセッサは、第１文書要素に変更があった場合において、前記第１文書要素に対して関係のある第２文書要素の関与者が前記第１文書要素に応じた前記第２文書要素の変更要否の確認を求める通知に応答できない場合に、前記第１文書要素又は前記第２文書要素に関係のある第３文書要素の関与者に対して前記通知を送信する、ことを特徴とする情報処理装置である。

請求項２に係る発明は、前記第３文書要素は、前記第１文書要素が含まれる第１文書とは別の第２文書に含まれる文書要素である、請求項１に記載の情報処理装置である。

請求項３に係る発明は、前記第２文書は、前記第２文書要素を含む文書である、請求項２に記載の情報処理装置である。

請求項４に係る発明は、前記プロセッサは、前記第２文書要素に対して関係のある文書要素の中から、内容の類似度が高いほど優先的に前記第３文書要素として選択する、ことを特徴とする請求項１〜３のいずれか１項に記載の情報処理装置である。

請求項５に係る発明は、前記プロセッサは、前記第２文書要素が含まれる文書中の文書要素を、他の文書中の文書要素よりも優先的に、前記第３文書要素として選択する、ことを特徴とする請求項１〜４のいずれか１項に記載の情報処理装置である。

請求項６に係る発明は、前記プロセッサは、前記第３文書要素の前記関与者が前記第２文書要素に対する編集権限を持っていない場合に、該関与者に対して前記第２文書要素に対する編集権限を一時的に付与する、ことを特徴とする請求項１〜５のいずれか１項に記載の情報処理装置である。

請求項７に係る発明は、前記プロセッサは、前記編集権限を一時的に付与した前記第３文書要素の前記関与者が、前記通知に応じて前記第２文書要素に対して変更を行った場合に、該変更を認めるか否かを、前記第２文書要素を含む文書に編集権限を持つユーザに問い合わせる、ことを特徴とする請求項６に記載の情報処理装置である。

請求項８に係る発明は、前記プロセッサは、前記第３文書要素の前記関与者が、前記通知に応じて前記第２文書要素に対して変更を行った場合に、該変更を認めるか否かを、前記第２文書要素を含む文書に編集権限を持つユーザに問い合わせる、ことを特徴とする請求項１〜５のいずれか１項に記載の情報処理装置である。

請求項９に係る発明は、コンピュータに、第１文書要素に変更があった場合において、前記第１文書要素に対して関係のある第２文書要素の関与者が前記第１文書要素に応じた前記第２文書要素の変更要否の確認を求める通知に応答できない場合に、前記第１文書要素又は前記第２文書要素に関係のある第３文書要素の関与者に対して前記通知を送信する、処理を実行させるためのプログラムである。

請求項１又は９に係る発明によれば、第１文書要素に関係のある第２文書要素の関与者のみに、第１文書の変更に応じた第２文書要素の変更要否の確認を求める通知を送る場合よりも、その変更に対する第２文書要素の変更要否の確認がなされる機会を増加させることができる。

請求項２に係る発明によれば、第１文書要素が含まれる第１文書の中から第３文書要素を選ぶ場合と比べて、第２文書要素に対して適切な確認をできる可能性を高くすることができる。

請求項３に係る発明によれば、第２文書要素と第３文書要素が同じ第２文書に含まれない場合と比べて、通知を受ける第３文書要素の関与者が、第２文書要素に対して適切な確認をできる可能性を高くすることができる。

請求項４に係る発明によれば、第２文書要素との類似度を考慮せずに第３文書要素を選ぶ場合と比べて、通知を受ける第３文書要素の関与者が、第２文書要素に対して適切な確認をできる可能性を高くすることができる。

請求項５に係る発明によれば、第２文書要素と第３文書要素が同じ第２文書に含まれない場合と比べて、通知を受ける第３文書要素の関与者が、第２文書要素に対して適切な確認をできる可能性を高くすることができる。

請求項６に係る発明によれば、第２文書要素に対する編集権限を持っていない者が通知を受けた場合でも、その者が第２文書要素に対して、第１文書要素の変更に応じた変更を加えることが可能になる。

請求項７に係る発明によれば、一時的に編集権限を与えた関与者により、第２文書要素を含む文書全体から見て不適切な変更がその第２文書要素に対して行われてしまうことを防止することができる。

請求項８に係る発明によれば、第２文書要素を含む文書全体から見て不適切な変更がその第２文書要素に対して行われてしまうことを防止することができる。

文書サービスシステムを含む全体システムの構成を例示する図である。 図１のシステムにおける文書作成作業の例を説明するための図である。 文書サービスシステムが実装されたコンピュータのハードウエア構成を例示する図である。 文書サービスシステムが実行する、データベースの構築及び保守の処理手順を例示する図である。 文書の構造を例示する図である。 データベース中の文書プロパティのデータ構造を例示する図である。 データベース中の要素プロパティのデータ構造を例示する図である。 データベース中の関係情報を例示する図である。 データベースのデータ構造の別の例を示す図である。 通知対象要素に関する変更通知の送信先を選ぶ順序を説明するための図である。 文書要素の変更を検知したときに文書サービスシステムが実行する処理の手順を例示する図である。 図１１の手順の変更通知処理の内部手順を例示する図である。 図１２の手順の各ステップで実行される通知処理の手順を例示する図である。 変更通知画面の例を示す図である。 通知対象要素とは別の文書に含まれる文書要素の関与者も送信先の候補とする場合の、変更通知の送信先を選ぶ順序を説明するための図である。 通知対象要素とは別の文書に含まれる文書要素の関与者も送信先の候補とする場合の、変更通知処理の内部手順を例示する図である。 変更通知の送信先の関与者が通知対象要素を編集できるようにする手順を例示する図である。

＜全体システムの例＞
図１に、本発明に係る情報処理装置の一実施形態である文書サービスシステム１００を含んだ文書利用のための全体システムを例示する。

この例では、文書サービスシステム１００は、ある会社の社内ネットワーク４０に接続されている。社内ネットワーク４０には、設計書管理システム１０や社内規定管理システム２０のように、社内の各種文書を管理するための１以上の文書管理システムが接続されている。また、社内ネットワーク４０上には、その会社内のユーザの情報を管理するディレクトリサーバ４５が設けられている。ディレクトリサーバ４５が管理するユーザの情報には、ユーザＩＤ（すなわち識別情報）、所属グループ、役割、連絡先等の項目が含まれる。社内ネットワーク４０上のシステム（例えば設計書管理システム１０、ディレクトリサーバ４５等）によって異なるユーザＩＤが用いられている場合は、ディレクトリサーバ４５には、それらシステムごとのそのユーザのユーザＩＤが保持されている。また、ユーザの所属グループの情報は、例えば、そのユーザが所属している部署やプロジェクト等のグループのＩＤである。ユーザの所属グループの情報には、ユーザが過去に所属していたグループの履歴（すなわち期間ごとの所属グループの情報）が含まれていてもよい。またユーザの連絡先の情報には、電話番号、電子メールアドレス、ソーシャルネットワークサービスにおけるユーザＩＤ等が含まれる。また社内ネットワーク４０には、ユーザが操作するパーソナルコンピュータ等のクライアント３０が接続されている。

インターネット５０上には、法令管理システム６０や「ＸＸ」技術の標準文書を管理するＸＸ標準管理システム７０等の、各種の文書管理システムが存在する。社内ネットワーク４０上の文書サービスシステム１００やクライアント３０等の装置は、それらインターネット５０上の文書管理システムが持つ文書にアクセス可能である。

文書サービスシステム１００は、設計書管理システム１０等の社内の文書管理システム内の文書に関係する他文書に変更があった場合に、その文書に関してその他文書の変更に対応したサービス（例えば関係者へのその変更の通知）を提供する。

図２に例示するように、会社内のあるユーザが、ある製品の設計書Ａを作成して設計書管理システム１０に登録し、保守している場合を考える。製品は、各種の法令や各種の社内規定を満たすように設計される必要があるため、設計書Ａもそれら法令や社内規定等といった他の文書を参照しながら作成される。例えば、設計書Ａは、法令管理システム６０の法令ＤＢ６２に登録されている道路運送車両法と、社内規定管理システム２０の社内規定ＤＢ２２に登録されている完成検査実施規定とを参照して作成されている。法令ＤＢ６２内の各法令も社内規定ＤＢ２２内の各規定も、改正に追従して随時更新されている。

道路運送車両法と完成検査実施規定が改正されると、設計書Ａの内容を更新する必要が出てくる場合があるが、必ず更新が必要とは限らない。例えば、法令等の改正された部分が、設計書Ａの内容が依拠している部分と異なる場合には、設計書Ａの内容の更新は不要である。

また、設計書Ａが法令のある部分に依拠して作成されているとしても、その依拠の仕方は様々である。例えば、設計書Ａ内に法令の一節がそのままコピーする形で引用されている場合もあれば、法令の関係箇所を確認しつつ設計書Ａ内のある部分を記載しただけで両者間に用語の一致が見られる程度にすぎない場合もある。前者の場合は、法令のその一節が改正されるのに応じて、設計書Ａ内の引用箇所を修正する必要性は高い。これに対して、後者の場合、法令の関係箇所の改正に応じた設計書Ａ側での対応の必要度合いは、前者の場合より低い。

そこで本実施形態の文書サービスシステム１００は、この設計書Ａの管理担当者等の文書の関与者に対して、その文書に関係する他文書の変更に応じてその文書を変更する必要があるかどうか判断する作業を支援する等のサービスを提供する。

ここで、「文書」とは、何らかのデータ形式のデータであり、そのデータ形式は特に限定されない。例えば、文書は、テキストデータ形式のデータであってもよいし、ＰＤＦ形式等の各種の文書ファイル形式であってもよい。また文書は、様々なイメージデータ形式の画像データであってもよいし、動画データであってもよいし、ＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）形式やＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）形式等のような構造化文書形式のデータであってもよい。

またこの明細書では、文書にとっての「関与者」とは、その文書の内容の保守に関与している個人又はユーザグループである。関与者は、例えば、その文書の内容の保守の担当者であってもよいし、その担当者に対してその保守の実行を促す役割のものであってもよい。例えば、文書を作成したユーザや文書を更新したユーザが、関与者の代表例である。また、文書が複数の文書要素から構成され、文書要素ごとに関与者が設定されている場合もあり得る。

＜ハードウエア構成の例＞
文書サービスシステム１００は、コンピュータにそのシステムの機能を表すプログラムを実行させることにより実現される。

ここで、文書サービスシステム１００のベースとなるコンピュータは、例えば、図３に示すように、ハードウエアとして、プロセッサ１０２、ランダムアクセスメモリ（ＲＡＭ）等のメモリ（主記憶装置）１０４、フラッシュメモリやＳＳＤ（ソリッドステートドライブ）、ＨＤＤ（ハードディスクドライブ）等の補助記憶装置１０６を制御するコントローラ、各種の入出力装置１０８とのインタフェース、ローカルエリアネットワークなどのネットワークとの接続のための制御を行うネットワークインタフェース１１０等が、例えばバス１１２等のデータ伝送路を介して接続された回路構成を有する。文書サービスシステム１００の各機能の処理内容が記述されたプログラムが、ネットワーク等を経由してコンピュータにインストールされ、補助記憶装置１０６に保存される。補助記憶装置１０６に記憶されたプログラムが、プロセッサ１０２によりメモリ１０４を用いて実行されることにより、文書サービスシステム１００の各機能が実現される。

ここでプロセッサ１０２とは広義的なプロセッサを指し、汎用的なプロセッサ（例えばＣＰＵ：Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ、等）や、専用のプロセッサ（例えばＧＰＵ：Ｇｒａｐｈｉｃｓ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ、ＡＳＩＣ：Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ、ＦＰＧＡ：Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ、プログラマブル論理デバイス、等）を含むものである。

また、プロセッサ１０２の動作は、１つのプロセッサ１０２によってなすのみでなく、物理的に離れた位置に存在する複数のプロセッサ１０２が協働してなすものであってもよい。また、プロセッサ１０２の各動作は、以下の実施形態において説明する順序のみに限定されるものではなく、適宜に変更してもよい。

なお、設計書管理システム１０、社内規定管理システム２０、クライアント３０等の他の装置も、文書サービスシステム１００と同様、コンピュータをベースとして構成されている。

＜データベース構築＞
図４〜図８を参照して、文書サービスシステム１００がサービス提供のために用いるデータベースの構築処理の例を説明する。このデータベースは、文書サービスシステム１００が備える補助記憶装置１０６内に構築される。

文書サービスシステム１００は、設計書管理システム１０、社内規定管理システム２０、法令管理システム６０等、社内外の所定の文書管理システムを例えば定期的に巡回し、それら各文書管理システムに登録されている文書群を取得して解析する。この場合、文書サービスシステム１００は、通知された情報を解析する。図４に示す手順は、文書サービスシステム１００が、いずれかの文書管理システムから１つの文書を取得（Ｓ１０）したときに実行する処理を示している。

この場合、文書サービスシステム１００のプロセッサ１０２は、取得した文書の構造を解析することにより、その文書を文書要素の単位に分割する（Ｓ１２）。構造解析は、例えば、文書をＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）形式に変換する処理により行う。ＨＴＭＬ変換のための多種多様なツールが存在しており、Ｓ１２では、その文書のファイル形式にあったツールを用いればよい。または、文書内容から見出しや、章、節、段落等の構造を認識する既存技術を用いて構造解析を行ってもよい。また、取得した文書が既にＸＭＬ形式等の構造化文書である場合は、Ｓ１２は省略してもよい。

次にプロセッサ１０２は、Ｓ１０で取得した文書と同一の文書のデータがデータベース内に登録されているか否かを判定する（Ｓ１４）。ここで言う「同一」とは、文書の内容全体が同一ということではなく、文書同士が同一の識別情報を持つということである。文書の識別情報のことを文書ＩＤと呼ぶ。Ｓ１４では、取得した文書の同じ文書ＩＤを持つ文書の情報がデータベース内にあるか否かを判定する。

文書ＩＤとしては、例えば、その文書の取得元の文書管理システム（例えば社内規定管理システム２０や法令管理システム６０）の識別情報と、その文書管理システムでのその文書の識別情報との組合せを用いてもよい。例えば、文書管理システム内にあるその文書のＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）をその文書の文書ＩＤとする等である。

Ｓ１４の判定結果がＮｏの場合、Ｓ１０で取得した文書は、プロセッサ１０２が初めて出会った文書である。この場合、プロセッサ１０２は、Ｓ１０で取得した文書の情報と、Ｓ１２の構造解析により得られた各文書要素の情報をデータベースに登録する（Ｓ１６）。

次にプロセッサ１０２は、それら文書要素ごとに、データベース内に登録された他の文書要素との間での内容の類似度を計算し、得られた類似度をデータベースに登録する（Ｓ１７）。文書要素同士の内容の類似度は、例えば、それら個々の文書要素に含まれる文字列をベクトル化し、得られた文書要素のベクトル同士の類似度合いを公知の手法（例えばコサイン類似度）で計算することで求めればよい。文書要素の文字列をベクトル化する方法としては、ＴＦ−ＩＤＦ（Ｔｅｒｍ Ｆｒｅｑｕｅｎｃｙ−Ｉｎｖｅｒｓｅ Ｄｏｃｕｍｅｎｔ Ｆｒｅｑｕｅｎｃｙ）やｄｏｃ２ｖｅｃ等の既存の手法を用いればよい。

ここで、Ｓ１２で求めた文書要素との類似度を求める相手である「他の文書要素」は、典型的には、データベースに登録されている他の文書の文書要素である。ただし、これに限らず、Ｓ１２で求めた文書要素同士の間の類似度を更に計算してもよい。

次にプロセッサ１０２は、Ｓ１０で取得した文書と、データベースに登録されている他の文書との間の類似度を計算し、計算結果の類似度をデータベースに登録する（Ｓ１８）。例えば、Ｓ１２の構造解析において得られる文書内の章、節の見出しの文字列をその出現順に並べてマージした文字列を、その文書の特徴を示す文字列とし、その文字列をベクトル化する。このようにして得られた文書の特徴を示す文字列のベクトル同士の類似度を、それら文書間の類似度として求める。なお、文書間の類似度の計算方式はこれに限らない。この他に、例えば、文書内の文書要素（例えば章、節、段落）が構成するツリー構造をその文書の特徴とし、その特徴同士の類似度を、文書間の類似度としてもよい。

Ｓ１４の判定結果がＹｅｓの場合、Ｓ１０で取得した文書のデータは、文書サービスシステム１００のデータベース内に登録されている。この場合、プロセッサ１０２は、Ｓ１０で取得した文書、及びＳ１２で求めた各文書要素が、データベース内に登録されている文書及び文書要素から変更されているか否かを調べる（Ｓ２０）。このステップでは、例えば、Ｓ１２で求めた文書要素ごとに、その文書要素の内容（すなわち文字列）を、データベース内の同じ文書要素（すなわち識別情報が同じ文書要素）の内容と比較し、両者が一致すればその文書要素は変更なし、不一致ならばその文書要素は変更有りと判定する。また、Ｓ１２で求めた文書要素と同じ文書要素がデータベース内にない場合や、データベース内にある文書要素と同じ文書要素がＳ１２の構造解析結果にない場合も、その文書要素に変更がある場合の例である。そして、いずれか１以上の文書要素について変更有りと判定された場合は文書全体について変更があるということであり、変更有りと判定された文書要素が１つもなければ文書全体について変更がないということである。

プロセッサ１０２は、Ｓ２０で文書、文書要素についての変更を検出したかどうかを判定し（Ｓ２２）、変更を検出した場合は、検出した変更の情報をデータベースに反映する（Ｓ２４）。例えば、ある文書要素の内容が変更されていた場合、データベース内のその文書要素の内容を、その変更後の内容に更新する。変更が検出されなかった文書要素については、データベースに登録されている情報は変更不要である。また、文書内の文書要素の変更が検出された場合、データベース内のその文書の更新日時等の情報を変更する。

またプロセッサ１０２は、Ｓ２０で内容の変更が検出された文書要素について、データベース内の他の文書要素との間での内容の類似度を計算する。そして、データベースに登録されている、それら文書要素間の類似度の値を、その計算により得られた値へと更新する（Ｓ２６）。なお、Ｓ２０で検出された文書要素がデータベース内にない新規の文書要素である場合は、その文書要素とデータベース内の他の文書要素との類似度を計算し、その類似度をデータベースに登録する。また、データベース内にある文書要素がなくなったことがＳ２０で検出された場合は、そのなくなった文書要素と他の文書要素との類似度の情報をデータベースから削除してもよい。なお、変更が検出されなかった文書要素については、Ｓ２６の処理は行わない。

また、プロセッサ１０２は、Ｓ１０で取得した文書とデータベース内の他の文書との類似度を、Ｓ１８の場合と同様に計算し、データベース内の該文書と他の文書との類似度をその計算結果に応じて更新する（Ｓ２８）。

図５〜図８を参照して、文書サービスシステム１００内のデータベースに登録される情報の例を説明する。

図５に、データベースに登録されている２つの文書２００及び２１０の、ＨＴＭＬ化による構造解析結果の情報を例示する。文書２００は、Ｈ１要素（例えば当該文書のタイトル）を子の文書要素（以下、子要素と呼ぶ）として持ち、そのＨ１要素は子要素として２つのＨ２要素を持ち、それらＨ２要素はそれぞれ２つ及び１つのＨ３要素を子要素として持つ。このように文書２００の構造情報は、図示のツリー構造により表現される。文書及び各文書要素にはそれぞれ一意な識別情報が割り当てられている。データベースには、文書の構造情報として、その文書の識別情報に対応付けて、図示のツリー構造を表現するデータが登録される。

また、データベースには、文書２００及び２１０のそれぞれについてのプロパティデータ（「文書プロパティ」と呼ぶ）と、個々の文書要素についてのプロパティデータ（「要素プロパティ」と呼ぶ）が登録される。

また、文書２００と文書２１０との間の、文書間の類似度が計算され、データベースに登録される。また、この文書要素同士の間の内容の類似度が計算され、データベースに登録される。

図６は、データベースに登録されている文書プロパティのデータ構造の一例を示す。図６に例示した文書の文書プロパティには、該文書の文書ＩＤ、文書名、文書特徴、作成者、作成日時、最終更新者、更新日時、取得日時、格納場所の各項目が含まれる。文書名は、例えば該文書のファイル名である。また、文書特徴は、該文書の特徴を示すデータであり、例えば前述した該文書内の章、節の見出しの文字列をその出現順に並べてマージした文字列がその一例である。またこの文字列をベクトル化したものを文書特徴として用いてもよい。作成者は、該文書を最初に作成したユーザのユーザＩＤを示し、作成日時はその作成の日時を示す。また最終更新者は、該文書を最後に更新したユーザのユーザＩＤを示し、更新日時はその更新の日時を示す。これら作成者、作成日時、最終更新者、更新日時の情報は、例えば、その文書のファイルの属性データから取得すればよい。また、取得日時は、プロセッサ１０２が、社内規定管理システム２０や法令管理システム６０等の文書管理システムから該文書を最後に取得した日時を示す。格納場所は、該文書が元々格納されていた文書管理システムを特定する情報（例えばその文書管理システムのＵＲＬ）である。

前述した図４の手順のＳ１８及びＳ２６では、このような文書プロパティの情報と、Ｓ１２で求めた該文書のツリー構造の情報をデータベースに登録する。

図７は、データベースに登録されている要素プロパティのデータ構造の一例を示す。図７に例示した文書要素の要素プロパティには、該文書要素の要素ＩＤ、要素名、要素内容、内容特徴、作成者、作成日時、最終更新者、更新日時、取得日時、格納場所の各項目が含まれる。要素ＩＤは、該文書要素の識別情報である。例えば、該文書要素が含まれている文書の文書ＩＤと、該文書内で該文書要素に一意に割り当てた番号との組を、要素ＩＤとしてもよい。要素名は、該文書要素の名前である。例えば、該文書要素が見出しを含む場合はその見出しを要素名としてもよい。また該文書要素が見出しを含まない場合は、該文書要素の先頭の所定文字数の文字列を要素名としてもよい。要素内容は、該文書要素の内容のデータである。例えば該文書要素がテキストであれば、要素内容はそのテキストの文字列である。要素特徴は、該文書要素の特徴を示すデータであり、例えば前述した該文書要素の文字列をベクトル化したものである。作成者は、該文書要素を最初に作成したユーザのユーザＩＤを示し、作成日時はその作成の日時を示す。元の文書のファイル（又はこれを管理している文書管理システム）が、文書要素単位で作成者や作成日時の情報を有している場合は、それらの情報が要素プロパティの作成者及び作成日時の項目に登録される。元の文書のファイルが、文書単位での作成者及び作成日時しか持たない通常のケースでは、該文書に含まれる文書要素の要素プロパティの作成者及び作成日時には、該文書の作成者及び作成日時が登録される。

最終更新者は、該文書要素を最後に更新したユーザのユーザＩＤを示し、更新日時はその更新の日時を示す。元の文書のファイル（又はこれを管理している文書管理システム）が、文書要素単位で最終更新者や更新日時の情報を有している場合は、それらの情報が要素プロパティの最終更新者及び更新日時の項目に登録される。元の文書のファイルが、文書単位での最終更新者や更新日時しか持たない通常のケースでは、該文書に含まれる文書要素の要素プロパティの最終更新者や更新日時の項目には、該文書要素の内容が変更されたことを検知したときの文書の最終更新者や更新日時の値が登録される。なお、文書要素の内容が変更されたか否かは、Ｓ１２で得た文書要素の要素内容又は内容特徴と、これと同じ要素ＩＤを持つデータベース内の文書要素の要素内容又は内容特徴とを比較することで判定すればよい。

また、取得日時は、プロセッサ１０２が、該文書要素を最後に取得した日時である。この取得日時は、該文書要素が含まれる文書の取得日時と同じである。格納場所は、該文書要素が元々格納されていた文書管理システムを特定する情報であり、該文書が含まれる位文書の格納場所と同じである。

前述した図４の手順のＳ１６では、このような要素プロパティの各項目の情報をデータベースに登録する。またＳ２４では、変更が検知された文書要素の要素プロパティの各項目の値を、その変更の内容に応じた値に更新する。

なお、文書が外部（例えば社内ネットワーク４０の外）の文書管理システムから取得されたものである場合、その文書については図６及び図７に例示した文書プロパティ及び要素プロパティのうちの全ての項目の情報が取得できない場合がある。そのような項目は空値とするか、又は他の情報に基づき文書サービスシステム１００が求めた値を設定する。例えば、法令管理システム６０から取得した文書については、作成者、作成日時、最終更新者、更新日時の情報が、その文書又は法令管理システム６０から入手できないことが考えられる。その場合、作成者、作成日時、最終更新者の項目は空値としておいてもよい。また、取得した文書内の文書要素に図４の手順のＳ２０で変更を検知した場合、文書サービスシステム１００は、その文書要素及びその文書の更新日時に、その取得の日時を設定すればよい。

図６及び図７に例示した文書プロパティ及び要素プロパティの項目群はあくまで一例に過ぎない。文書プロパティ及び要素プロパティは、図示した項目の全てを含んでいる必要はないし、また図示していない項目を含んでいてもよい。

図８に、データベースに登録されている文書要素同士の関係情報を例示する。図８に例示した関係情報は、２つの文書要素の要素ＩＤのペアに対応付けて、それら２つの文書要素の内容の類似度の値と、その値から判定されるそれら文書要素同士の関係の種類とを含んでいる。この例では、文書要素同士の関係の種類を、文書要素同士の内容の類似度の大きさに応じていくつかに分類している。例えば、文書要素同士の内容の類似度が０．９５（すなわち９５％）以上の場合は、それら文書要素同士の関係の種類を「引用」と名付ける。また、文書要素同士の内容の類似度が０．８０以上０．９５未満の場合の関係の種類を「類似」と名付け、０．６０以上０．８０未満の場合の関係の種類を「参照」と名付ける。また、類似度が０．６０未満場合は、それら２つの文書要素は無関係と判断する。

また、図８では省略したが、類似度や関係の種類を判定した日時を更に関係情報に登録してもよい。

図４の手順のＳ１７及びＳ２６では、文書要素同士の類似度と、その類似度に対応する関係の種類を判定し、それらの値を図８に例示した関係情報に登録する。

なお、図８に例示した関係情報はあくまで例示的なものにすぎない。関係情報としては、類似度は含むが関係の種類を含まないものを用いてもよいし、その逆に類似度は含まないが関係の種類は含むものを用いてもよい。

図４〜図８を参照して説明した例では、文書要素同士の関係の種類を、それら文書要素の内容の類似度に応じて定めたが、これは一例に過ぎない。

例えば、文書要素を作成又は更新したユーザが、その文書要素に関係を持つ他の文書要素とその関係の種類を文書サービスシステム１００に登録してもよい。

また、ユーザに文書編集の機能を提供する装置（例えばクライアント３０が提供する文書編集アプリケーション）が、ユーザが文書要素を編集中に行った操作に応じて、文書要素間の関係を判定し、文書サービスシステム１００に登録してもよい。例えば、ユーザが、装置の画面上に開いた文書Ａ内の文書要素ａを、コピー＆ペースト操作により、その画面上に開いた別の文書Ｂ内の文書要素ｂにコピーした場合、その装置は、文書要素ｂが文書要素ａに対して「引用」の種類の関係を持つと判定する。そして、その「引用」関係を文書サービスシステム１００に登録する。また、例えば、装置は、ユーザが画面上に開いた文書要素ｃを編集中に、その画面上に別の文書要素ｄが開かれていた（ただし、文書要素ｄからｃに対してコピー＆ペーストは行われなかった）場合、文書要素ｃが文書要素ｄに対して「参照」の関係を持つと判定する。

文書サービスシステム１００が持つデータベースの構造として、図５〜図８に示した構造とは別の構造を図９に示す。図９に示すデータベース構造は、文書要素ごとに１つのレコード（すなわち図に示される表の１行）を有する。文書要素のレコードには、「文書ＩＤ」、「要素ＩＤ」、「要素内容」、「関与者」、「関係先文書ＩＤ」、「関係先要素ＩＤ」、「関係先要素内容」、「関係種類」の項目が含まれる。「文書ＩＤ」は、その文書要素が属する文書の文書ＩＤである。「要素ＩＤ」は、その文書要素の要素ＩＤである。「要素内容」は、その文書要素の要素内容である。「関与者」は、その文書要素の関与者のユーザＩＤを示す。文書要素の関与者は、例えば、その文書要素の作成者や最終更新者である。「関係先文書ＩＤ」は、その文書要素が関係する他の文書要素（以下「関係先要素」と呼ぶ）が属する文書の文書ＩＤである。「関係先要素ＩＤ」は、その関係先要素の要素ＩＤである。「関係先要素内容」は、その関係先要素の要素内容である。「関係種類」は、当該文書要素と関係先要素との関係の種類である。

＜文書要素の変更の通知処理＞
以下、上に例示したデータベースを参照して文書サービスシステム１００が行う、文書要素の変更についての通知について説明する。

ある文書要素が変更された場合、その文書要素に対して関係を持つ他の文書要素をその変更に応じて修正する必要がでてくる場合がある。例えば、ある製品の設計書内のあるパーツに関する説明が、そのパーツが準拠すべきある法令の条文に則して記載されている場合、その条文が変更された場合、そのパーツの説明に変更する必要となる場合があり得る。

そこで、文書サービスシステム１００は、前者の文書要素に変更があったことを、後者の文書要素の関与者に通知する。これにより、その関与者は、前者の変更に応じて後者に変更が必要か確認し、必要であれば後者に対して変更を行う。

ところが、前者の文書要素の変更が発見されたときに、後者の文書要素の関与者が退職等の事情で、社内ネットワーク４０を利用している会社からいなくなっている場合があり得る。そのような場合、その関与者に対して通知を行うことができない。また仮に通知を行うことができても、その関与者はいないので必要な確認や対処はなされず、その通知は無駄になる。また、そのときにその関与者が長期の休暇等により不在である場合のように、その関与者が会社内に存在していてもその関与者がその通知に対して適切な対処をすぐに取れない場合もあり得る。

このような状況を想定し、文書サービスシステム１００は、変更があった文書要素に関係のある文書要素の関与者が、その変更を知らせる通知に対して応答できない場合に、適格性が高いと判定される別のユーザに対してその通知を送信する。以下では、記載の簡潔化のために、変更があった文書要素のことを「変更要素」と呼び、その変更要素に関係がある文書要素であってその変更を知らせる通知の対象とする文書要素のことを「通知対象要素」と呼ぶ。また、変更要素が変更されたことを知らせる通知のことを「変更通知」と呼ぶ。

通知対象要素の関与者が、変更通知に「応答できない場合」には、その関与者が文書サービスシステム１００（ひいては社内ネットワーク４０）のユーザでない場合が含まれる。その関与者がその通知の時点で退職済みである場合がその一例である。この場合、文書サービスシステム１００は、ディレクトリサーバ４５を参照することで、その関与者が既に登録されているユーザでないことを認識し、そもそもその関与者に対して変更通知を送信しないこともあり得る。このような場合も、その関与者がその変更通知に「応答できない場合」の概念の範囲内である、またその「応答できない場合」には、その関与者がその変更通知に応じて所定時間以内に通知対象要素の変更要否の確認をしなかった場合も含まれる。例えば、その関与者が長期休暇等でその通知に対してすぐに反応できない場合が、その一例である。

図１０を参照して、文書サービスシステム１００が、変更通知を送信する送信先ユーザの選択順位の一例を説明する。図１０の例は、通知対象要素が含まれる文書内の文書要素群の関与者群の中から、送信先ユーザを選ぶ場合の例を示す。

図１０の例では、設計書管理システム１０に登録されている「設計書Ａ」は、文書要素Ａ−１、Ａ−２、Ａ−３、Ａ−４から構成されており、それぞれ関与者（例えば最終更新者）としてユーザ１、ユーザ２、ユーザ３、ユーザ４が登録されている。また社内規定管理システム２０に登録されている文書「完成検査実施規定Ｂ」は、文書要素Ｂ−４、Ｂ−５、Ｂ−６を含んでいる。文書要素Ａ−１及びＡ−３は、共に文書要素Ｂ−５に対して「参照」の種類の関係を持っている。文書要素Ａ−１とＡ−２とは互いに「類似」の関係を持っている。

この状況でユーザαが文書要素Ｂ−５を編集してその内容を変更し、これに応じて文書サービスシステム１００が文書要素Ａ−１を通知対象要素に選んだ場合を考える。この場合、文書サービスシステム１００は、最初に、通知対象要素である文書要素Ａ−１の関与者、すなわちユーザ１に対して変更通知の送信を試みる。

ユーザ１がその変更通知に対して応答できない場合、文書サービスシステム１００は、次に、同じく文書要素Ｂ−５を「参照」している文書要素Ａ−３の関与者、すなわちユーザ３に変更通知の送信を試みる。文書要素Ａ−３は、通知対象要素Ａ−１と同一文書内であり、かつ変更された同じ文書要素Ｂ−５を参照しているので、文書要素Ａ−３の関与者であるユーザ３は、通知対象要素Ａ−１に対して知見を有している可能性が高いと考えられる。そこで、ユーザ１が応答できない場合に、ユーザ３に通知を試みるのである。

ユーザ３がその変更通知に対して応答できない場合、文書サービスシステム１００は、次に、通知対象要素に対して「類似」の関係を持つ文書要素Ａ−２の関与者、すなわちユーザ２に変更通知の送信を試みる。文書要素Ａ−２は、通知対象要素Ａ−１と同一文書内であり、かつ通知対象要素Ａ−１と内容が類似しているので、文書要素Ａ−２の関与者であるユーザ２は、通知対象要素Ａ−１に対して知見を有している可能性が高いと考えられる。そこで、ユーザ２に通知を試みるのである。

ユーザ３もユーザ２もその変更通知に対して応答できない場合、文書サービスシステム１００は、次に、通知対象要素と同じ文書内の別の文書要素Ａ−４の関与者、すなわちユーザ４に変更通知の送信を試みる。文書要素Ａ−４は、変更された文書要素Ｂ−５に対してまったく関係を持っておらず、かつ通知対象要素Ａ−１に類似してもいない。文書要素Ａ−４は、通知対象要素Ａ−１と同一文書内のものなので、文書要素Ａ−４の関与者であるユーザ４は、通知対象要素Ａ−１に対して知見を有している可能性がある。そこで、ユーザ１も２も３も応答できない場合に、ユーザ４に通知を試みるのである。

図１０を参照して説明した変更通知の処理の手順の一例を、図１１〜図１３を参照して説明する。

図１１は、ある文書要素の内容が変更されたことを検知したとき（例えば図４の手順のＳ２２の判定結果がＹｅｓとなったとき）に、文書サービスシステム１００のプロセッサ１０２が実行する全体的な処理の手順を示す。プロセッサ１０２は、文書サービスシステム１００内のデータベースから、内容が変更されたことを検知した文書要素（すなわち変更要素）に関係がある文書要素を抽出する（Ｓ３０）。Ｓ３０では、変更要素に対して何らかの関係を持つ文書要素を全て抽出してもよい。この場合、抽出されないのは、変更要素に対して関係を持たない文書要素である。また、Ｓ３０では、変更要素に対して特定の条件を満たす関係を持つ文書要素を抽出してもよい。ここでの特定の条件としては、例えば、その関係の種類が予め定めたいくつかの種類に該当する、という条件がある。具体的な例では、変更要素に対して「引用」関係を持つ文書要素を抽出する場合がその例である。この具体例では、変更要素に対して「類似」又は「参照」の関係を持つ文書要素は抽出されない。また、特定の条件の別の例として、変更要素に対して内容の類似度が所定値以上である、という条件も考えられる。このようにしてＳ３０で特定した文書要素が通知対象要素である。

次にプロセッサ１０２は、抽出した通知対象要素ごとに、変更通知処理（Ｓ３２）を実行する。

変更通知処理の手順を、図１２に例示する。図１２の手順では、プロセッサ１０２は、該通知対象要素を注目要素Ｘとして、通知処理を実行する（Ｓ４０）。通知処理の具体的な例は、後で図１３を参照して説明する。

Ｓ４０の処理結果は、通知成功か通知失敗のいずれかとなる。処理結果が通知成功の場合は、プロセッサ１０２は該通知対象要素についての変更通知が成功した旨を記録し、変更通知処理（Ｓ３２）を終了する。

Ｓ４０の処理結果が通知失敗の場合、プロセッサ１０２は、該通知対象要素と同じ文書に属する文書要素であって、変更要素に対して関係がある文書要素をデータベースから求める。ここでは、Ｓ３０と同様、変更要素に対して特定の条件を満たす関係を持つ文書要素を求める。そして、求めた各文書要素をそれぞれ注目要素Ｘとして、通知処理（図１３参照）を実行する（Ｓ４２）。Ｓ４２の処理結果が通知成功の場合は、プロセッサ１０２は該通知対象要素についての変更通知処理（Ｓ３２）を終了する。

Ｓ４２の処理結果が通知失敗の場合、プロセッサ１０２は、該通知対象要素と同じ文書に属する文書要素であって、通知対象要素に類似する文書要素をデータベースから求める。ここでは例えば、通知対象要素に対する類似度が所定の閾値以上である文書要素をデータベースから求める。あるいは、通知対象要素に対して種類「類似」の関係を持つ文書要素をデータベースから求める。そして、求めた各文書要素をそれぞれ注目要素Ｘとして、通知処理（図１３参照）を実行する（Ｓ４４）。Ｓ４４の処理結果が通知成功の場合は、プロセッサ１０２は該通知対象要素についての変更通知が成功した旨を記録し、変更通知処理（Ｓ３２）を終了する。

Ｓ４４の処理結果が通知失敗の場合、プロセッサ１０２は、該通知対象要素と同じ文書に属する文書要素のうち、Ｓ４２及びＳ４４のいずれでも注目要素Ｘとならなかった文書要素をデータベースから求める。そして、求めた各文書要素をそれぞれ注目要素Ｘとして、通知処理（図１３参照）を実行する（Ｓ４６）。Ｓ４６の処理結果が通知成功の場合は、プロセッサ１０２は該通知対象要素についての変更通知が成功した旨を記録し、変更通知処理（Ｓ３２）を終了する。Ｓ４６の処理結果が通知失敗の場合、プロセッサ１０２は、該通知対象要素についての変更通知が失敗した旨を記録し、変更通知処理（Ｓ３２）を終了する。

次に図１３を参照して、Ｓ４０〜Ｓ４６で実行される、個々の注目要素Ｘについての通知処理の手順を説明する。

この手順では、プロセッサ１０２は、Ｓ４０〜Ｓ４６のうち現在実行しているステップにおける注目要素Ｘの条件を満たす文書要素をデータベースから探し（Ｓ１０２）、見つかったかどうか判定する（Ｓ１０４）。その条件を満たす文書要素、すなわち注目要素Ｘが見つかった場合（Ｓ１０４の結果がＹｅｓ）、プロセッサ１０２は、注目要素Ｘの関与者をデータベースから求める（Ｓ１０６）。ここでは、データベース中の注目要素Ｘの要素プロパティ（図７参照）の最終更新者、又は図９に示すデータ構造のデータベースにおける注目要素Ｘの関与者、を求める。

次にプロセッサ１０２は、Ｓ１０６で特定した関与者が登録されているかどうかディレクトリサーバ４５に問い合わせる（Ｓ１０８）。この問合せでは、その特定した関与者のユーザＩＤをディレクトリサーバ４５に送る。この問合せに対してディレクトリサーバ４５は、そのユーザＩＤが自身に登録されているか否かを示す応答を返す。プロセッサ１０２は、その応答に基づき、その関与者がまだ社内に存在するか否かを判定する（Ｓ１１０）。この判定の結果がＮｏの場合、プロセッサ１０２は、Ｓ１０２に戻り、次の注目要素Ｘを探す。

Ｓ１１０の判定結果がＹｅｓの場合、プロセッサ１０２は、変更要素が変更されたことを示す変更通知を、Ｓ１０６で特定した関与者に送信する（Ｓ１１２）。

変更通知を受け取った関与者が、その変更通知に応じて、通知対象要素の変更要否の確認や通知対象要素の内容の変更等の処置を行うと、文書サービスシステム１００のプロセッサ１０２はその旨を検知する。

プロセッサ１０２は、Ｓ１１２の変更通知を関与者に送信してから所定長さの期間、その関与者がその変更通知に応じた処置を実行するのを待つ（Ｓ１１４）。その期間内にその関与者がその変更通知に応じた処置を実行すると、プロセッサ１０２は、通知対象要素について通知成功と判定し（Ｓ１１６）、図１３の処理を終了する。

その期間内にその関与者がその変更通知に応じた処置を実行しないままその所定長さの期間が過ぎると、Ｓ１１４の判定結果はＮｏとなる。この場合、プロセッサ１０２は、Ｓ１０２に戻り、図１３の処理を繰り返す。また、図１３の処理手順を繰り返して、注目要素Ｘの条件を満たす文書要素がそれ以上データベースから見つからなくなった場合、Ｓ１０４の判定結果はＮｏとなる。この場合も、プロセッサ１０２は、通知対象要素について通知失敗と判定し（Ｓ１１８）、図１３の処理を終了する。

Ｓ１１２で関与者に送られる変更通知の一例を、図１４に示す。図１４に例示するのは、関与者の操作するクライアント３０の画面にポップアップ表示される変更通知画面３００の一例である。この変更通知画面３００には、内容が変更された変更要素を特定する情報と、その変更に応じて内容の変更が必要か否かの確認を求める文書要素、すなわち通知対象要素、を特定する情報と、を含むメッセージ３０２が表示される。このように、変更通知は、変更要素の変更に応じた通知対象要素の変更要否の確認を求めるものとなっている。図示例のメッセージ３０２では、「設計書Ａ」という文書内の「排出濃度基準」という文書要素が通知対象要素であり、「完成検査実施規定Ｂ」という文書内の「排出濃度テストによる検査」という文書要素が変更要素である。このメッセージ３０２は、変更要素の変更に応じて通知対象要素に変更が必要か否か、関与者（この例では「ユーザ１」）に対して確認を求める内容となっている。また、変更通知画面３００には、確認ボタン３１０が表示される。変更通知画面３００を見た関与者が、マウスのクリック操作等により確認ボタン３１０を押下すると、プロセッサ１０２は、例えば、変更があった文書「完成検査実施規定Ｂ」の文書要素「排出濃度テストによる検査」の最新（すなわち変更後）の内容と、その文書を参照している「設計書Ａ」の文書要素「排出濃度基準」の内容を表示する画面を関与者の端末に提供する。関与者は、その変更要素「排出濃度テストによる検査」の内容を確認しながら、通知対象要素「排出濃度基準」の内容に変更が必要かどうかを判断する。また、この画面には、変更要素の変更後の内容だけでなく、変更前の内容も併せて表示してもよい。また、その画面に、変更前と変更後の差の情報を表示してもよい。

また関与者への変更通知の提供方式の他の例として、例えば関与者が文書サービスシステム１００にログインした際に表示するポータルページ上の通知欄に表示する方式や、関与者の電子メールアドレスに対して電子メールで送信する方式等がある。関与者の電子メールアドレスは、ディレクトリサーバ４５から入手すればよい。

＜他の文書の文書要素の関与者も送信先の候補とする例＞
図１０及び図１２に示した例は、変更通知を送信先は、通知対象要素と同じ文書内の文書要素の関与者から選ばれた。しかし、これは一例に過ぎない。

別の例として、図１５に示す例には、図１０に例示した「設計書Ａ」及び「完成検査実施規定Ｂ」に加え、「設計書Ｃ」が示されている。「設計書Ｃ」は、文書要素Ｃ−１及びＣ−２を含んでおり、これらにはユーザ５及びユーザ６がそれぞれ関与者として登録されている。文書要素Ｃ−１は、文書要素Ａ−１及びＡ−３と同じく、文書要素Ｂ−５を参照しているものとする。この例では、例えば、通知対象要素である文書要素Ａ−１と同じ文書「設計書Ａ」内のどの文書要素の関与者も変更通知に応答できない場合、変更要素である文書要素Ｂ−５を参照している別の文書「設計書Ｃ」内の文書要素Ｃ−１の関与者であるユーザ５に変更通知を送信する。

この例におけるプロセッサ１０２の全体的な処理手順は図１１に示したものと同じであり、その中の変更通知処理（Ｓ３２）の手順は、図１２ではなく、図１６に示したものとなる。図１６の手順のうち、図１２に示したステップと同様のステップには、同一の符号を付した。

図１６の手順では、プロセッサ１０２は、図１２と同じＳ４０〜Ｓ４６を実行し、Ｓ４６の結果が「通知失敗」となった場合に、通知対象要素が属する文書とは異なる文書に属する文書要素の中から、変更要素に対して関係がある文書要素を探す。ここでは、Ｓ３０と同様、変更要素に対して特定の条件を満たす関係を持つ文書要素を求める。そのような文書要素が見つかれば、その文書要素を注目要素Ｘとして、図１３に示した通知処理を実行する（Ｓ４８）。Ｓ４８の処理結果が通知成功の場合は、プロセッサ１０２は該通知対象要素についての変更通知が成功した旨を記録し、変更通知処理（Ｓ３２）を終了する。

なお、Ｓ４６とＳ４８の実行順序を逆にしてもよい。Ｓ４６のように同一文書内であること、又はＳ４８のように変更要素に対して関係があること、のうちのどちらを優先するか（すなわちＳ４６とＳ４８のどちらを先に実行するか）は、利用側のポリシーによる。

図１５及び図１６を参照して説明したとおり、通知対象要素と異なる文書に含まれる文書要素の関与者を、変更通知の送信先の候補とすることにより、変更通知がユーザに伝わる可能性が高くなる。

＜通知先のユーザへの編集権限の一時的付与＞
上述のように、通知対象要素以外の文書要素の関与者に変更通知を送った場合、その変更通知を受け取った者が通知対象要素に対して編集権限を持っていない場合があり得る。変更通知を受け取った者が、その通知に係る変更要素と通知対象要素の内容を確認し、その結果通知対象要素に変更が必要と判断したとしても、その者がその通知対象要素に対する編集権限を持っていない場合、必要な変更ができない。そこで、以下に説明する例では、変更通知の送信先の関与者が、通知対象要素に対する編集権限を持っていない場合、その関与者に対してその編集権限を一時的に付与する。

図１７にこの例の処理手順を例示する。この手順は、図１２又は図１６のＳ４０〜Ｓ４８において、通知成功の処理結果が得られた場合に実行される。この手順では、プロセッサ１０２は、通知が成功したときの送信先である関与者が、通知対象要素に対して編集権限を持っているか否かを判定する（Ｓ１５０）。この判定では、例えば、その通知対象要素を含む文書を管理している文書管理システム（例えば図１の例では設計書管理システム１０等）に対して、その関与者のユーザＩＤがその通知対象要素に対して編集権限を持っているか問い合わせればよい。Ｓ１５０の判定結果がＹｅｓ、すなわちその関与者が通知対象要素への編集権限を持っている場合は、プロセッサ１０２は図１７の手順を終了する。

Ｓ１５０の判定結果がＮｏの場合、プロセッサ１０２は、その関与者に対して通知対象要素への編集権限を一時的に付与する（Ｓ１５２）。この一時的な付与は、例えば、文書サービスシステム１００が、その関与者から通知対象要素への編集を受け付け、その編集の結果を文書サービスシステム１００の権限で、文書管理システム内のその通知対象要素のオリジナルに反映させることにより実現する。また別の例として、文書サービスシステム１００が、その通知対象要素のオリジナルを管理している文書管理システムに、その関与者にその通知対象要素への一時的な編集権限を付与するよう要求し、これに応じ文書管理システムがそのような権限設定を行ってもよい。

プロセッサ１０２は、この後、その関与者から通知対象要素の確認や編集等の操作が完了した旨の通知が来るのを待ち（Ｓ１５４）、その通知を受け取ると、付与した一時的な編集権限を削除する（Ｓ１５６）。

次にプロセッサ１０２は、その通知対象要素を含む文書に編集権限を持つ者（例えばその文書の所有者）に対して、関与者によるその通知対象要素の編集結果を承認するか否かを問い合わせる（Ｓ１５８）。その通知対象要素を含む文書に編集権限を持つ者の情報は、プロセッサ１０２が、その文書を管理している文書管理システムに対して問い合わせることにより取得すればよい。また、文書に編集権限を持つ者への問合せには、例えば、関与者による編集の前後の通知対象要素の内容や、変更要素の変更内容などを示すウェブページへのＵＲＬが含まれる。この問合せを受けた者は、そのＵＲＬを用いてそのウェブページにアクセスし、関与者による通知対象要素の編集内容の適否を判断し、その判断に基づきその編集を承認するか又は拒絶する。

プロセッサ１０２は、Ｓ１５８の問合せの結果、通知対象要素の編集内容が承認されたか否かを判定し（Ｓ１６０）、承認された場合には、その編集内容を確定する（Ｓ１６２）。この場合、プロセッサ１０２は、例えば、文書管理システムに対して、その関与者による通知対象要素の編集結果を、その通知対象要素の文書に反映して保存するよう指示する。Ｓ１６０の判定結果がＮｏの場合、プロセッサ１０２は、関与者による編集結果を取り消す（Ｓ１６４）。例えば、文書管理システムに対して、その関与者による通知対象要素の編集結果を破棄し、その通知対象要素の文書をその編集を受ける前の状態とするよう指示する。

図示は省略したが、プロセッサ１０２は、通知対象要素への一時的な編集権限を受けた関与者が編集等の操作を行わないまま所定時間が経過した場合、その一時的な編集権限を削除する。

また、図１７の手順では、通知対象要素の一時的な編集権限を受けた関与者の編集結果について、その要素を含む文書の編集権限を持つ者に承認を求めた。別の例として、通知対象要素の関与者以外の者に変更通知を送り、その変更通知に応じてその者が行った編集の結果について、通知対象要素を含む文書の編集権限を持つ者に承認を求めるようにしてもよい。

＜その他＞
以上に説明した実施形態において、例えば図１２又は図１６のＳ４２〜Ｓ４８の各ステップにおいて、注目要素Ｘとなる条件を満たす文書要素が複数ある場合がある。この場合、同じ条件を満たす文書要素をどの順に注目要素Ｘとして選び、処理していくかについては、いくつかの方法がある。

一つの例は、その条件を満たす文書要素と、通知対象要素との文書内での物理的な距離の近い順に選択するという方式である。この方式は、通知対象要素と同一文書内にある文書要素を注目要素として選ぶ場合にできる。この方式では、文書サービスシステム１００は、各文書要素の文書内で位置を把握している。文書要素の文書内での位置は、例えば、その文書要素がその文書の何ページ目にあるかという情報と、その文書要素のそのページ内のページ内での位置との組合せで表される。文書要素のページ内での位置は、例えば、その文書要素の先頭の行の行番号、或いはその先頭行と末尾の行の行番号の組合せ、である。また別の例では、文書要素のページ内での位置は、ページ内でのその文書要素の領域の代表点（例えばその領域の重心、又はその領域の左上の頂点）で表される。この方式では、条件を満たす文書要素を、位置が通知対象要素に「近い」順に注目要素Ｘとして選び、その関与者に対して変更通知の送信を試みる。そして、選択した注目要素Ｘの関与者がその変更通知に対して応答した場合には、その変更通知の送信の試行の結果が「通知成功」となり、図１２又は図１６の処理が終了する。

別の方式では、その条件を満たす文書要素を、通知対象要素との内容の類似度が高い順に、注目要素Ｘに選ぶ。類似度が高い文書要素の関与者は、通知対象要素に対する知見も高いと期待される。

また、通知対象要素と物理的な距離と内容の類似度の両方を加味したスコアを各文書要素について求め、そのスコアの値が高い文書要素から順に注目要素Ｘに選択してもよい。
以上に説明した実施形態において、文書要素は、文書を構成する要素のことである。ここで、文書管理システムが管理する個々の文書を構成要素とするより大きな単位の文書が存在してもよい。この場合、前者の個々の文書は、後者の大きな単位の文書にとっての文書要素である。例えば、ハイパーリンクで結びつけられた複数の文書から構成されるハイパーテキストを大きな単位の文書と捉えた場合、それら複数の文書はそのハイパーテキストから見ると文書要素に当たる。

１０ 設計書管理システム、２０ 社内規定管理システム、３０ クライアント、４０ 社内ネットワーク、４５ ディレクトリサーバ、５０ インターネット、６０ 法令管理システム、７０ ＸＸ標準管理システム、１００ 文書サービスシステム。

Claims (9)

1. プロセッサを備え、
   前記プロセッサは、
   第１文書要素に変更があった場合において、前記第１文書要素に対して関係のある第２文書要素の関与者が前記第１文書要素に応じた前記第２文書要素の変更要否の確認を求める通知に応答できない場合に、前記第１文書要素又は前記第２文書要素に関係のある第３文書要素の関与者に対して前記通知を送信する、
   ことを特徴とする情報処理装置。
2. 前記第３文書要素は、前記第１文書要素が含まれる第１文書とは別の第２文書に含まれる文書要素である、請求項１に記載の情報処理装置。
3. 前記第２文書は、前記第２文書要素を含む文書である、請求項２に記載の情報処理装置。
4. 前記プロセッサは、前記第２文書要素に対して関係のある文書要素の中から、内容の類似度が高いほど優先的に前記第３文書要素として選択する、ことを特徴とする請求項１〜３のいずれか１項に記載の情報処理装置。
5. 前記プロセッサは、前記第２文書要素が含まれる文書中の文書要素を、他の文書中の文書要素よりも優先的に、前記第３文書要素として選択する、ことを特徴とする請求項１〜４のいずれか１項に記載の情報処理装置。
6. 前記プロセッサは、
   前記第３文書要素の前記関与者が前記第２文書要素に対する編集権限を持っていない場合に、該関与者に対して前記第２文書要素に対する編集権限を一時的に付与する、
   ことを特徴とする請求項１〜５のいずれか１項に記載の情報処理装置。
7. 前記プロセッサは、前記編集権限を一時的に付与した前記第３文書要素の前記関与者が、前記通知に応じて前記第２文書要素に対して変更を行った場合に、該変更を認めるか否かを、前記第２文書要素を含む文書に編集権限を持つユーザに問い合わせる、
   ことを特徴とする請求項６に記載の情報処理装置。
8. 前記プロセッサは、
   前記第３文書要素の前記関与者が、前記通知に応じて前記第２文書要素に対して変更を行った場合に、該変更を認めるか否かを、前記第２文書要素を含む文書に編集権限を持つユーザに問い合わせる、
   ことを特徴とする請求項１〜５のいずれか１項に記載の情報処理装置。
9. コンピュータに、
   第１文書要素に変更があった場合において、前記第１文書要素に対して関係のある第２文書要素の関与者が前記第１文書要素に応じた前記第２文書要素の変更要否の確認を求める通知に応答できない場合に、前記第１文書要素又は前記第２文書要素に関係のある第３文書要素の関与者に対して前記通知を送信する、
   処理を実行させるためのプログラム。

Images