JPH0528138A - 文書編集システム - Google Patents

Abstract

(57)【要約】 【目的】本発明は、複数のユーザが共同で文書上の同一
箇所を編集することのできる文書編集システムを提供す
ることを目的とする。 【構成】編集中の文書についての変更情報を蓄積する変
更情報蓄積手段２３３と、該変更情報蓄積手段２３３の
情報をもとに文書ファイルの格納を制御する文書格納手
段２４０を設け、文書上の同一箇所を複数のユーザ間で
同時に編集した場合に、変更情報蓄積手段２３３に蓄積
されている情報をもとに文書格納の順番を制御する。 【効果】後から変更を加えたユーザの変更が、先に変更
を加えたユーザの文書の変更との間で矛盾が生じること
を防ぐことができ、複数のユーザが共同で文書上の同一
箇所を編集することが可能となる。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、計算機上で文書等のデ
ータを作成する文書編集システムに係わり、特に複数の
ユーザが共同で文書等を作成する文書編集システムに関
する。

【０００２】

【従来の技術】従来、共同で文書を作成する場合には、
作成する文書をユーザ毎に複数のファイルに分割し、分
割された文書ファイルをそれぞれのユーザが作成してい
た。そして、各文書が完成後、それらの文書ファイルを
まとめて、最終的な文書として扱うことを行っていた。

【０００３】このような方法を採用する文書編集システ
ムの例として、例えば米国のＦｒａｍｅＭａｋｅｒ Ｔ
ｅｃｈｎｏｌｏｇｙ社の文書編集ソフトウェアであるＦ
ｒａｍｅＭａｋｅｒに採用されているブック機能が知ら
れている。ブック機能については例えば、米国シーボル
ト社から出版されているレポート”ＳｅｙｂｏｌｄＲｅ
ｐｏｒｔ ｏｎ Ｐｕｂｌｉｓｈｉｎｇ Ｓｙｓｔｅｍ
ｓ， ｐａｇｅ ２１， Ｖｏｌ．１９， Ｎｏ．７，
１９９０年５月１４日発行”に論じられている。

【０００４】

【発明が解決しようとする課題】しかしながら、複数の
ファイルに文書が分割されている場合、文書をネットワ
ークを通じて他のマシンに転送したり、電子メールを使
って遠方のマシンに送る場合には不都合であった。

【０００５】また、文書の同一箇所を同時に複数のユー
ザ間で編集することは困難であり、共同の文書編集を行
うには不十分であった。

【０００６】本発明は上記従来方法の問題点に鑑み為さ
れたもので、その目的は、複数のユーザが、共同で一文
書上の同一箇所を編集することの可能なために必要な文
書編集システムを提供することである。

【０００７】本発明の別の目的は、複数のユーザが同じ
箇所を更新した場合に、変更した順序で文書が格納され
ることにより、文書編集に矛盾が生じない文書編集シス
テムを提供することである。

【０００８】本発明の更に別の目的は、複数のユーザが
同じ箇所を更新した場合に、先行して変更した箇所をフ
ァイルに書き込まなかった場合でも、文書変更の整合性
を確保できる文書編集システムを提供することである。

【０００９】

【課題を解決するための手段】本発明は上記目的を達成
するためになされたもので、後から変更を加えたユーザ
のデータ格納が先に変更を加えたユーザのデータ格納の
後に実行されるようにして、データ格納時にデータの変
更内容に矛盾が生じることを防ぐことにより達成され
る。

【００１０】上記の別の目的はデータの変更状態を記憶
して、ユーザの指示に従い、その状態を変更することに
よりデータ変更の順序に矛盾が生じることを防ぐことに
より達成される。

【００１１】より具体的にいえば、データデータを分割
して取り扱い、該分割単位毎に異なるユーザが編集処理
を実行可能な文書編集システムであって、データの編集
処理を行う、一または二以上の編集手段と、編集手段に
よりデータの編集処理が行われた場合、その編集内容を
示す変更情報を、上記分割単位毎に蓄積する変更情報蓄
積手段と、上記編集処理においてデータの格納が指示さ
れた場合には、上記変更情報を確認し、該変更情報に基
づいて該格納処理の内容を変更する機能を有する格納手
段とを備えたことを特徴とする文書編集システムが提供
される。

【００１２】上記変更情報は、当該編集処理を実行した
ユーザを示す識別データと、更新日時と、該編集処理結
果の格納の有無を示すデータとを含み、上記格納手段
は、編集データの格納が指示された場合、該編集処理が
行なわれる以前に他人により作成された未格納編集デー
タが存在するか否かを、変更情報に基づいて、上記分割
単位毎に判定し、未格納編集データが存在する場合に
は、該編集処理により作成された編集データについて、
上記分割単位毎に、該他人の未格納編集データの存在を
記載したリストを作成し、該格納処理を待機状態とする
ことが好ましい。

【００１３】この場合、上記格納手段は、上記未格納編
集データが存在しない場合には、該編集データの格納処
理をただちに実行するものであることが好ましい。

【００１４】さらには、上記格納手段は、上記格納処理
を実行した後、該編集データの記載されたリストを検索
し、該リスト上から該編集データの記載を削除し、さら
に、該削除の結果、該リストが空になった場合には、該
リストに対応する未格納編集データの格納処理を実行す
ることが好ましい。

【００１５】また、上記編集手段が編集データを格納し
ないまま終了した場合、上記格納手段は、該編集データ
の記載されている上記リストを検索し、該リストに対応
する未格納編集データの格納指示を無効にするものであ
ってもよい。

【００１６】上記編集手段が編集データを格納しないま
ま終了した場合、上記格納手段は、該編集データの記載
されている上記リストを検索し、該リストに対応する未
格納編集データを回復用データとして保存するものであ
ってもよい。

【００１７】本発明の他の態様としては、データを分割
して取り扱い、該分割単位毎に異なるユーザが編集処理
を実行可能な文書編集システムであって、データの編集
を行う複数の編集手段と、編集手段からのアクセスの可
否を示すステータスを、上記分割単位毎に、記憶するス
テータス手段と、上記編集手段からの要求に応じてステ
ータスを変更する機能を有するステータス変更手段とを
備えたことを特徴とする文書編集システムが提供され
る。

【００１８】この場合、上記ステータスには、プライベ
イト−ステイトと、リファレンス−ステイトと、パブリ
ック−ステイトとの少なくとも三種類を有し、プライベ
イト−ステイトとなっている分割単位については、編集
手段による編集結果を当該編集を実行した編集手段以外
の編集手段からは、参照も、編集もできない状態であ
り、リファレンス−ステイトとなっている分割単位につ
いては、編集手段による編集結果を当該編集を実行した
編集手段以外の編集手段から、参照はできるが、編集は
できない状態であり、パブリック−ステイトとなってい
る分割単位については、編集手段による編集結果を当該
編集を実行した編集手段以外の編集手段から、参照も編
集もできる状態であることが好ましい。

【００１９】また、一編集手段が、ある分割単位へアク
セスすると、該分割単位のステートを調べ、その結果が
リファレンス−ステイトまたはパブリック−ステイトで
あった場合には、該分割単位のステータスを該状態に変
更させた編集手段に対し、ステータスの変更要求を出力
するステータス変更要求手段を有し、上記ステータス変
更手段は、上記ステータス変更要求を受けたステータス
変更手段から、ステータスの変更を許可する指示を受け
取った場合、該分割単位のステータスを上記一編集手段
の要求に応じて変更する機能を有することが好ましい。

【００２０】以上説明した文書編集システムにおいて、
上記分割単位は、データの論理構造に基づいて決定され
るものであることが好ましい。また、頁によるものでも
構わない。

【００２１】また、上記ステータス変更手段は、各分割
単位のステータスの状態に応じて、当該分割単位毎の表
示態様を変更する機能を有するものであっても構わな
い。

【００２２】

【作用】編集手段によりデータの編集処理が行われた場
合、変更情報蓄積手段はその編集内容、例えば、当該編
集処理を実行したユーザを示す識別データ、更新日時、
該編集処理結果の格納の有無を示すデータ等の変更情報
を上記分割単位毎に蓄積する。

【００２３】編集処理が終了した後、データの格納が指
示されると、格納手段は、該編集処理が行なわれる以前
に他人により作成された未格納編集データが存在するか
否かを、変更情報に基づいて、上記分割単位毎に判定す
る。その結果、未格納編集データが存在する場合には、
該編集処理により作成された編集データについて、上記
分割単位毎に、該他人の未格納編集データの存在を記載
したリストを作成し、該格納処理を待機状態とする。一
方、上記未格納編集データが存在しない場合には、該編
集データの格納処理をただちに実行する。

【００２４】また、該格納手段は、格納処理を実行した
後、該編集データの記載されたリストを検索し、見つか
ったリスト上から該編集データの記載を削除する。さら
に、該削除の結果、該リストが空になった場合には、該
リストに対応する未格納編集データの格納処理を実行す
る。

【００２５】なお、編集手段が編集データを格納しない
まま終了した場合、格納手段は、該編集データの記載さ
れているリストを検索し、該リストに対応する未格納編
集データの格納指示を無効にする。あるいは、編集手段
が編集データを格納しないまま終了した場合、格納手段
は、編集データの記載されているリストを検索し、該リ
ストに対応する未格納編集データを回復用データとして
保存する。

【００２６】他の態様について説明する。

【００２７】一編集手段が、ある分割単位へアクセスす
る。すると、ステータス変更要求手段は、ステータス手
段に記憶されているステータスを調べて、該分割単位の
ステータスを調べる。そして、該分割単位のステートが
リファレンス−ステイトまたはパブリック−ステイトで
あった場合には、ステータス変更要求手段は、該分割単
位のステータスを該状態、つまり、リファレンス−ステ
イトまたはパブリック−ステイトにさせた編集手段に対
し、ステータスの変更要求を出力する。

【００２８】ステータス変更手段は、ステータス変更要
求を受けたステータス変更手段から、ステータスの変更
を許可する指示を受け取った場合、該分割単位のステー
タスを上記一編集手段の要求に応じて変更する。また、
同時にステータスに応じてその表示態様を変更する。

【００２９】なお、上記ステータスには、プライベイト
−ステイトと、リファレンス−ステイトと、パブリック
−ステイトとの少なくとも三種類を有している。

【００３０】プライベイト−ステイトとなっている分割
単位については、編集手段による編集結果を当該編集を
実行した編集手段以外の編集手段からは、参照も、編集
もできない。

【００３１】リファレンス−ステイトとなっている分割
単位については、編集手段による編集結果を当該編集を
実行した編集手段以外の編集手段から、参照はできる
が、編集はできない。

【００３２】パブリック−ステイトとなっている分割単
位については、編集手段による編集結果を当該編集を実
行した編集手段以外の編集手段から、参照も編集もでき
る。

【００３３】なお、分割単位は、第１章、第１節、第１
部等の文書データの論理構造、あるいは、頁や、基づい
て決定される。

【００３４】

【実施例】以下、本発明の実施例について、図面をもと
に説明する。

【００３５】実施例１ 本実施例の文書編集システムのネットワークハードウエ
ア構成を示す全体図を第９図を用いて説明する。

【００３６】本システムを構成するワークステーション
１０は、ローカルエリアネットワーク２０を介して接続
される。ローカルエリアネットワーク２０は、例えば、
ＩＥＥＥ８０２．３規格のイーサネットワークである。
ただし、これに限定されるものではなく、他のネットワ
ークでも構わない。また、広域ネットワークでも使用可
能であることは言うまでもない。後述する、サーバプロ
セスやクライアントプロセスは、任意のワークステーシ
ョン上で実行されるものである。もちろん、クライアン
トプロセスとサーバプロセスとが同一のワークステーシ
ョン上で実行されても構わない。

【００３７】ワークステーションの内部構成を図１０を
用いて説明する。

【００３８】このワークステーションは、主に、プロセ
ッサボード３０、ディスプレイ装置７０、マウス７５、
キーボード８５、外部記憶装置９０からなる。

【００３９】プロセッサボード３０には、プログラムを
実行するマイクロプロセッサ（以下、ＭＰＵという）３
５、プログラムおよびデータを格納する主メモリ４０、
入出力インタフェース（以下、Ｉ／Ｏ−ＩＦという）４
５、ネットワーク制御プロセッサ６０、ディスプレイ装
置７０に表示するデータを生成する描画プロセッサ５
５、表示用データを格納する表示用メモリ５０が設けら
れている。

【００４０】Ｉ／Ｏ−ＩＦ４５は、キーボード８０、マ
ウス７５、外部記憶装置９０と接続されて、入出力を制
御するものである。

【００４１】ネットワーク制御プロセッサ６０は、ロー
カルエリアネットワーク２０に接続され、他のワークス
テーションとの間で通信を行いデータを交換するための
ものである。

【００４２】マウス７５は、１個以上のボタン８０を備
えている。

【００４３】次に、本実施例のプロセス構成を説明す
る。

【００４４】複数ユーザ間での共同編集機能は、編集プ
ロセス（クライアントプロセス）と共同編集管理サーバ
プロセスとの組み合わせにより実現される。

【００４５】図２は、前記クライアントプロセス１００
と前記サーバプロセス２００の接続関係を示す図であ
る。

【００４６】クライアントプロセス１００とサーバプロ
セス２００は、ワークステーション上で実行されるユー
ザプロセスの一種であり、クライアントプロセス１００
とサーバプロセス２００はネットワークを介しての通信
により、メッセージ及び文書データの交換を行う構成と
成っている。サーバプロセス２００はホスト計算機やサ
ーバマシン上で実行されることもある。一つのサーバプ
ロセス２００には複数のクライアントプロセス１００が
接続され、それらのクライアントプロセス１００間で同
一文書の共同編集が行える。クライアントプロセス１０
０とサーバプロセス２００を同一のワークステーション
上で実行することも、もちろん可能である。

【００４７】クライアントプロセス１００の構成につい
て詳細に説明する。

【００４８】図３はクライアントプロセス１００の主な
構成要素を示す図である。

【００４９】対話処理部１１０は、キーボード１７０や
マウス１８０などからイベント入力を受け取り、文書編
集処理部１２０に渡したり、ユーザ操作のために必要な
メニューや対話ウインドウを画面制御部１４０を介して
ディスプレイ１６０に表示する処理を行う。

【００５０】文書編集処理部１２０は、対話処理部１１
０やサーバインタフェース部１３０及び画面制御部１４
０と連動して文書の編集操作に関する機能を実行する。

【００５１】サーバインタフェース部１３０は、文書編
集処理部１２０が要求する処理をサーバプロセス２００
に対するメッセージに変換して転送したり、逆にサーバ
プロセス２００からクライアントプロセス１００へのメ
ッセージやデータを受け取り、対話処理部１１０に渡す
処理を行う。

【００５２】画面制御部１４０は文書編集処理部１２０
や対話処理部１１０から表示データを受け取り、画面バ
ッファ１５０に展開してディスプレイ１６０に表示す
る。

【００５３】以下、本発明では特に対話処理部１１０、
文書編集処理部１２０、サーバインタフェース部１３０
に密接に関連するため、これらの部分の有する機能につ
いて、更に詳細に説明する。

【００５４】まず、対話処理部１１０の機能について説
明する。

【００５５】対話処理部１１０では、通常のイベント処
理や表示処理の他に、以下に示す処理を行う機能を有し
ている。

【００５６】・文書格納指示 文書編集終了時に、文書の格納を指示するコマンドをユ
ーザから受け取り、文書格納シートを表示する。そし
て、格納シートに入力された指示に従い文書の格納を文
書編集処理部１２０に伝える。

【００５７】・他者による変更ある部分の表示処理 既に他者が変更した箇所については、変更したことが表
示上から確認できるように、変更した論理構造の部分の
背景色を変えて表示する。

【００５８】・変更指示 変更対象となる論理構造の部分について変更開始の宣言
をユーザから受け取り、文書編集処理部１２０に伝達す
る。

【００５９】・変更終了指示 変更終了した論理構造の部分について変更終了の宣言を
ユーザから受け取り、文書編集処理部１２０に伝達す
る。

【００６０】・異常処理 文書格納が正常に実行できなかった場合に、ユーザに問
い合わせて文書格納処理のキャンセル、あるいは格納指
示直前の状態の回復の指示を受け付ける。指示は文書編
集処理部１２０に伝達する。もちろん、それ以外にも、
色々な異常状態が発生する可能性が存在するが、本発明
の理解には必要がないので説明を省略する。

【００６１】次に、文書編集処理部１２０の機能につい
て説明する。

【００６２】・編集データバッファ サーバプロセス２００から送られた文書データを、編集
データバッファに記憶して、表示及び編集操作に使用す
る。変更したデータも本バッファに記憶される 。・変更開始処理 対話処理部１１０から変更開始の指示を受け取ると、サ
ーバインタフェース部１３０を介して変更開始要求のメ
ッセージをサーバプロセス２００に転送し、許可を受け
取る。許可されない場合には対話処理部１１０を介して
変更不可であることをユーザに伝える。

【００６３】・変更終了処理 対話処理部１１０から変更終了の指示を受け取ると、サ
ーバインタフェース部１３０を介して変更終了のメッセ
ージをサーバプロセス２００に転送し、変更操作を終了
する。

【００６４】・編集処理 前記変更開始処理で許可を受け取った後、変更開始宣言
をした論理構造の内容について編集操作を行う。本編集
操作は通常の操作と同様である。

【００６５】・文書状態の問い合わせ 編集対象の文書についてサーバプロセス２００に文書の
状態を問い合わせる。問い合わせ項目としては、同時編
集中のユーザ数、文書の更新状態、ロック中の論理構造
箇所、その他、である。

【００６６】・ロック箇所の識別、ロック部分の入力禁
止 あるユーザが変更中の論理構造部分は、それ以外のユー
ザから変更できないようにロックされる。文書編集処理
部１２０はロック部分を識別して、ユーザの変更操作を
できないようにする。

【００６７】・文書データの要求 文書データはサーバプロセス２００に蓄積されているに
ので、前記編集データバッファに必要な文書データがな
い場合には、サーバインタフェース部１３０を介してサ
ーバプロセス２００に文書データの送信を要求する。

【００６８】・文書データの送出 文書変更を終了した時点で変更した文書データをサーバ
インタフェース部１３０を介してサーバプロセス２００
に転送する。

【００６９】・文書格納処理 対話処理部１１０から文書格納の指示を受け取ると、サ
ーバインタフェース部１３０を介して文書格納のメッセ
ージをサーバプロセス２００に転送する。文書格納が通
常の文書格納操作か、遅延文書格納操作になるかの判断
はサーバプロセス２００側で行う。

【００７０】次に、サーバインタフェース部１３０の機
能を説明をする。

【００７１】・サーバの接続、切り離し クライアントプロセス１００の起動時に、サーバプロセ
ス２００との間で通信の接続関係を確立する。通信路の
確立手段としては、一般的な通信プロトコルを利用す
る。本実施例では良く知られているＳｏｃｋｅｔ機能を
利用してサーバプロセス２００との間で通信路確立し通
信を行う。

【００７２】また、クライアントプロセス１００の実行
終了時には、サーバプロセス２００との通信接続を解消
し、サーバプロセス２００との接続関係を解除する。

【００７３】・サーバ間でのメッセージおよびデータの
交換 サーバプロセス２００とのメッセージ及びデータの交換
を上記通信路を使って行う。

【００７４】サーバプロセス２００の構成を説明する。

【００７５】図１は、サーバプロセス２００の主な構成
要素を示す図である。

【００７６】なお、図１に示す以外にもサーバプロセス
２００を構成する要素があることはもちろんであるが、
本発明の理解には必要がないので省略する。

【００７７】サーバプロセス２００は、クライアントイ
ンタフェース部２１０、共同編集制御部文書格納部２２
０、ファイルアクセス制御部２５０、文書データ管理部
２３０からなる。また、この文書データ管理部２３０
は、論理構造部分２３１、レイアウトデータ管理部２３
２、変更情報蓄積部２３３からなる。

【００７８】クライアントインタフェース部２１０は、
クライアントプロセス１００毎に用意され、クライアン
トプロセス１００との間で通信路を介してのメッセージ
交換やデータの交換を行うためものである。以下、クラ
イアントインタフェース部２１０の機能を詳細に説明す
る。

【００７９】・クライアントプロセスとの接続、切り離
し クライアントプロセス１００からの接続要求を受け取
り、クライアントプロセス１００との間で通信の接続関
係を確立する。また、クライアントプロセス１００から
の接続切断要求により、クライアントプロセス１００と
の通信接続の解消する。

【００８０】・クライアントプロセス間でのメッセー
ジ、及びデータの交換 クライアントプロセス１００とのメッセージ及びデータ
の交換は通信の接続関係を設定した通信路を使って行
う。

【００８１】共同編集制御部２２０の機能を説明する。

【００８２】・クライアントプロセス１００の状態監視 接続されているクライアントプロセス１００の数やそれ
ぞれの実行状態を監視して、それらの状態を記録してい
るデータを蓄積する。

【００８３】・メッセージの解釈 クライアントプロセス１００との間での処理の指示は通
信を介してメッセージの形で転送されるため、このメッ
セージを解釈して必要な処理を実行する。処理実行後は
応答のメッセージと必要に応じてデータを付加してクラ
イアントプロセス１００に送る。

【００８４】・文書データの受信 クライアントプロセス１００側で変更した文書データ
は、該当部分の編集が終了した時点でサーバプロセス２
００に転送されてくる。そこで、このデータを受け取
り、文書データ管理部２３０に渡して変更データを保管
する。

【００８５】・文書データの送信 クライアントプロセス１００に対してデータを送信す
る。この送信は、クライアントプロセス１００からの要
求に従って送信する場合と、サーバプロセス２００が自
主的に送信する場合とがある。

【００８６】サーバプロセス２００の自主的な送信は、
あるクライアントプロセス１００から変更されたデータ
を受け取った場合に行われる。その際には、受信したデ
ータ部分について、変更される以前のコピーをもってい
るクライアントプロセス１００全部に、該受信したデー
タを変更後のデータとして送信する。

【００８７】文書データ管理部２３０は、以下の機能を
有している。

【００８８】・論理ブロック単位のロック設定、解除 文書データは、論理構造を単位として編集の対象として
宣言される。そして、あるクライアントプロセス１００
から編集開始を宣言された論理構造部分は、それ以下に
属する構造部分も含めて、他のクライアントプロセス１
００から変更されないように上述の変更開始要求に従っ
てロックする。

【００８９】・変更部分のチェック 指定される論理構造が更新されているかの検査を行う。

【００９０】該文書データ管理部２３０は、論理構造管
理部２３１、レイアウトデータ管理部２３２、変更情報
蓄積部２３３とにより構成されている。そして、文書デ
ータは論理構造データと、レイアウト構造データとに分
離され、論理構造データは論理構造管理部２３１によっ
て、また、レイアウト構造データはレイアウトデータ管
理部２３２によって保管、管理する構成である。

【００９１】変更情報蓄積部２３３は、変更された部分
の変更情報を、論理構造単位に蓄積するものである。該
変更情報蓄積部２３３は、変更情報に関する問い合わせ
を受けると、該当する論理構造データが変更情報内に存
在するか否かを調査する。そして、該当データが存在す
る場合には変更情報を返し、また、存在しない場合には
該当なしの回答をする。変更情報として蓄積するデータ
の主なものは、以下の通りである。

【００９２】変更後のデータ 変更元データと変更後のデータとの差分データ 変更日時 変更者 コメント 文書格納部２４０は、ファイルアクセス制御部２５０を
介して文書ファイルの格納及び読み出しを行うものであ
る。以下に、文書格納部２４０の機能を説明する。

【００９３】・文書格納処理 文書の変更を行っていたユーザが、文書の格納を指示し
た際に行われる処理の概要を説明する。

【００９４】図４は、その処理動作を示すフローチャー
トである。

【００９５】ユーザが文書格納の指示をクライアントプ
ロセス１００に対して行う（ステップ４１０）。する
と、クライアントプロセス１００は、この指示をメッセ
ージに変換し、サーバプロセス２００に転送する（ステ
ップ４２０）。文書格納のメッセージを受け取ったサー
バプロセス２００は、共同編集制御部２２０でメッセー
ジを解釈し、文書格納の処理を文書格納部２４０に依頼
する（ステップ４３０）。文書格納部２４０は、文書格
納処理依頼を受け取ると、遅延文書格納処理の必要性を
判定する（ステップ４４０）。遅延文書格納処理の必要
なしと判定された場合には通常の文書格納処理が行われ
る（ステップ４５０）。

【００９６】なお、ステップ４４０の遅延文書格納処理
判定は図５を用いて、また、ステップ４５０の通常文書
格納処理は図６を用いて後ほど詳細に説明する。

【００９７】図４のステップ４４０において行われる遅
延文書格納の判定処理を詳細に説明する。

【００９８】遅延文書格納処理判定は、文書格納を指示
したユーザが他者の更新した部分を後から更新し、且
つ、更新した他者がまだ更新した部分を含めて文書格納
していない状態であるか否かを判定するものである。

【００９９】遅延文書格納判定の処理のフローチャート
を図５に示す。

【０１００】まず、判定処理の初期状態として待ちリス
トに”ＮＵＬＬ”を設定する（ステップ５１０）。次
に、順番に、当該ユーザが行った変更箇所を検索して抽
出する（ステップ５２０）。

【０１０１】その後、変更箇所が残っているか否かを判
定する（ステップ５３０）。変更箇所がある場合には、
変更情報蓄積部２３３に蓄積されている変更情報を調べ
て、当該変更箇所を、他者が先行して変更しているか否
かを判断する（ステップ５４０）。

【０１０２】ステップ５４０において、他人が先行して
変更していると判断された場合、当該変更箇所の格納処
理を実行するためには、該部分について先行して行われ
た変更の格納処理が実行されるまで待たなければない。
そのため、格納処理を実行するために待たなければなら
ない、先行して行われた変更の識別符号、例えば先行し
て変更を行った者の名前等を待ちリストに登録する。一
方、先行して変更されていない場合には、単に処理５２
０に戻る。

【０１０３】なお、この場合の待ちリストとは、”変
更”毎に作成されるものであり、該変更の格納に先立っ
て行うべき格納処理、つまり、該変更と同じ変更個所に
対して、時間的に先行して行われた他の変更の存在を示
すためのものである。言い替えれば、このリストの所有
者となる変更の格納処理の実行を行う際に、待たなけれ
ばならない他の格納処理を記載したものである。

【０１０４】以上の処理を操り返し実行することにより
遅延文書格納の判定処理を行う。つまり、判定結果は待
ちリスト上に反映される。その結果、待ちリスト上に要
素が存在する場合には、該リスト上の要素に対応する格
納処理が実行されるまで、いわば該リストの所有者であ
る”変更”の格納処理は、その実行が待機状態となる。
つまり遅延文書格納が行われることになる。

【０１０５】一方、待ちリストがＮＵＬＬの場合には、
遅延文書格納処理は行われない。

【０１０６】なお、ステップ５３０において、変更箇所
が残っていなかった場合は、判定処理を終了する。

【０１０７】次に、図４のステップ４５０で行われる文
書格納処理を詳細に説明する。

【０１０８】該文書格納処理は、図６（ａ）に示した通
常文書格納処理６１０と、図６（ｂ）に示した遅延文書
格納処理６５０とからなる。

【０１０９】まず、通常文書格納処理６１０を説明す
る。

【０１１０】通常文書格納処理６１０は、変更された部
分をファイル上の元のデータと置き換えるファイル格納
処理（ステップ６１５）を実行する。そして、その後、
該文書格納処理待ちの遅延格納処理があるか否か、言い
替えれば、該変更が、他の変更のリストに記載されてい
るか否かを、各待ちリストを調べて（ステップ６２
０）、該文書についての格納操作を待つリストが存在す
るか否かを判断する（ステップ６２５）。

【０１１１】そして、存在する場合には、そのリスト要
素を持つリストの所有者となる変更に対して後述する遅
延格納処理６５０を起動する（ステップ６３０）。一
方、存在しない場合には、そのまま格納処理を終了す
る。

【０１１２】次に、ステップ６３０において起動される
遅延文書格納処理を図６（ｂ）を用いて説明する。

【０１１３】遅延文書格納処理６５０は、起動される
と、上述のステップ６１５において格納処理の実行され
た要素を、待ちリストから取り除き（ステップ６５
５）、続いて、リスト内にまだ要素が残っているか否か
を判定する（ステップ６６０）。

【０１１４】残りの要素がない場合には、もう他の文書
格納処理を待つ必要がないため、待ちリストそのものを
削除する（ステップ６６５）。その後、通常の文書格納
処理６１０を実行して、該ステップ６６５で削除された
りストの所有者にあたる未格納の文書を格納する。

【０１１５】一方、待ちリスト内にまだ要素が残ってい
る場合には、さらに他の文書格納処理を待つ必要がある
ので、処理は次の文書格納処理の待ちとなる。

【０１１６】なお、この遅延文書格納処理６５０は、ス
テップ６２５において、該当要素ありと判断されたすべ
てのリストに対して、各リスト毎に、行われるものであ
る。

【０１１７】この文書格納処理は、該通常文書格納処理
６１０と遅延文書格納処理６５０とが連携して実行され
るため、ある一つの文書の格納処理を行った結果、格納
処理の実行が許されるようになった未格納文書について
も、その時点で格納を実行することになる。

【０１１８】・遅延文書格納の異常終了処理 先行して行われた変更等のクライアントプロセス１００
の処理が、文書格納を実行しないで終了した場合には、
該変更よりも時間的に後から変更されながら先に格納の
指示がされていた部分、つまり、待ちリストに上記先行
して行われた変更を有し、待機状態になっているものに
ついては、格納処理を実行することができない。

【０１１９】従って、この場合には、遅延文書格納の異
常終了処理が実行される。また、この異常終了した遅延
文書格納、を指示したユーザが、再度同一文書をオープ
ンした時点で遅延文書格納復帰処理が実行される。

【０１２０】あるユーザが使用していたクライアントプ
ロセス１００が文書格納せずに終了することが共同編集
制御部２２０に伝えられると、共同編集制御部２２０
は、文書格納部２４０に対して遅延文書格納異常処理を
要求する。文書格納部２４０では、この要求に従い、異
常終了処理を行う。

【０１２１】この異常終了処理を図７のフローチャート
に従って説明する。

【０１２２】まず、文書格納せずに終了したクライアン
トプロセス１００が格納されるのをを待つ遅延文書格納
が存在するか否かを判断するために、全ての待ちリスト
を調べる（ステップ７１０）。そして、該当するクライ
アントプロセス１００の格納を待っている遅延文書格納
が存在するか判定する（ステップ７２０）。

【０１２３】該当する遅延文書格納があった場合、遅延
文書格納失敗時の回復用に回復用文書ファイルを生成し
する（ステップ７３０）。そして、待ちリストから格納
を指示しないまま終了した文書を削除して（ステップ７
４０）、異常終了リストにユーザ名と文書名を登録する
（ステップ７５０）。

【０１２４】なお、ステップ７２０において該当する遅
延文書格納が存在しない場合には、なにもしない。

【０１２５】次に、この異常終了処理が行われた後の復
帰処理を説明する。

【０１２６】登録されている文書が再オープンされた場
合には、文書格納部２４０によって異常終了リストが調
べられる。この遅延文書格納復帰処理は、この時に、該
再オープンされた文書が、異常終了リストと一致した場
合、つまり、該文書が、上述の回復用文書ファイルであ
った場合に、共同編集制御部２２０によって開始される
ものである。

【０１２７】図８はその遅延文書格納復帰処理の処理を
示すフローチャートである。

【０１２８】共同編集制御部２２０は、遅延格納処理が
異常終了したことをユーザに伝え、ユーザの指示を待つ
（ステップ８１０）。そして、ユーザからの指示を受け
取ると（ステップ８２０）、指示の内容を調べる（ステ
ップ８３０）。ユーザの指示がキャンセルである場合に
は該回復用文書ファイルを削除して終了する（ステップ
８４０）。

【０１２９】一方、ユーザの指示が回復を指示している
場合には、回復可能であるか調べる（ステップ８５
０）。回復可能である場合には、該回復用文書ファイル
からデータを読み込み復元する（ステップ８６０）。回
復不可能である場合には、回復不可能であることをユー
ザに通知して終了する（ステップ８７０）。

【０１３０】本実施例によれば、複数のユーザが同じ箇
所を更新した場合に、文書格納指示の順に関係無く、変
更した順序で文書が格納処理が実行されるため、文書編
集に矛盾が生じない。従って、他のユーザが格納を指示
する前であっても、複数のユーザが同じ個所の編集をす
ることができるという効果がある。

【０１３１】実施例２ 次に本発明の別の実施例について説明する。

【０１３２】本実施例においては、文書の変更箇所につ
いての状態として、プライベイト−ステイト、リファレ
ンス−ステイト、パブリック−ステイトの３種類のステ
イトを設けている。そして、変更したあるいは変更中の
箇所の状態を、このステータスにより分類している。

【０１３３】これらの変更箇所のステイトは論理構造の
要素を単位として設定されるものである。プライベイト
−ステイトは、変更した結果の文書部分を他者から参照
も更新もできない状態である。リファレンス−ステイト
は、他者からの参照はできるが変更はできない状態であ
る。パブリック−ステイトは、他者から参照も変更も可
能な状態である。従って、編集中の論理構造のステイト
状態はプライベイト−ステイトとなっている。

【０１３４】システムの構成は、実施例１と同様にクラ
イアントプロセス（１００）とサーバプロセス（２０
０）からなる。

【０１３５】クライアントプロセス（１００）を構成す
る主な要素も実施例１と同様であるが、以下に示す部分
で異なる機能をサポートしている。

【０１３６】対話処理部（１１０）についていて説明す
る。

【０１３７】・ステートの表示処理 画面に表示されている部分が変更されている場合、その
ステートを色別に表示するものである。

【０１３８】・ステート変更要求 ユーザの指示を受け付けて、論理構造の要素を指定し
て、そのステートの変更を要求する処理である。この変
更の要求は、当該論理構造部分について先に変更を行っ
たユーザへ、ステート変更要求指示を送ることにより行
なわれる。

【０１３９】・ステート変更要求指示 自分が更新した論理構造部分について、他のクライアン
トプロセスが編集を行うために、ステートの変更を要求
してくる場合がある。この場合、該対話処理部１１０
は、その旨を当該ユーザに知らせて、指示を仰ぐ。この
要求を受け取ったユーザ（この場合、自分）は、ステー
ト変更指示、あるいはステート変更拒否の指示をする必
要がある。

【０１４０】・ステート変更指示 ある論理構造部分の現在のステートを別のステートに変
更するものである。ステートの変更は、当該部分につい
ての内容を変更したユーザのみが実行できる。

【０１４１】・ステート変更拒否指示 ステート変更要求を受け取ったがステートの変更を実行
したくない場合にステート変更拒否を指示するものであ
る。

【０１４２】文書編集処理部（１２０）の機能について
説明する。

【０１４３】・ステートの問い合わせ サーバプロセス（２００）に依頼して、指定された論理
構造のステートを問い合わせる処理である。

【０１４４】・ステート変更処理 対話処理部（１１０）から受け取ったステート変更にし
たがい、サーバプロセス（２００）に対してステートの
変更を指示する処理である。

【０１４５】続いて、サーバプロセス（２００）を説明
する。

【０１４６】サーバプロセス（２００）を構成する主な
要素も実施例１と同様であるが、以下に示す部分で異な
る機能をサポートしている。

【０１４７】共同編集制御部（２２０）について説明す
る。

【０１４８】・ステートの問い合わせ クライアントプロセス（１００）から指定された論理構
造要素について、文書データ管理部（２３０）に問い合
わせて、そのステートの値を返す。

【０１４９】・ステートの変更 クライアントプロセス（１００）から指定された論理構
造要素について、そのステートの変更を文書データ管理
部（２３０）に指示する。

【０１５０】文書データ管理部（２３０）について説明
する。

【０１５１】・ステートの問い合わせに対する回答 指定された論理構造要素について変更情報蓄積部（２３
３）のステートを参照して、その値を返す。

【０１５２】・ステート変更処理 指定された論理構造要素について、論理構造管理部（２
３１）のデータを参照してステートの変更権をチェック
後、変更権を有するユーザからの変更要求である場合に
は、変更情報蓄積部（２３３）内の指定された論理構造
のステートを変更する。

【０１５３】蓄積データとしては、以下のものがある。

【０１５４】・変更後のデータ ・変更元データと変更後のデータとの差分データ ・変更日時 ・変更者 ・コメント ・ステート 次に、本実施例のステイトの変更処理動作について説明
する。

【０１５５】ステートが”パブリック”になっている部
分、つまり、だれも文書変更を行なっていない部分対
し、文書更新を行なおうとした場合の処理を図１１を用
いて具体的に説明する。

【０１５６】ユーザは、文書内容を変更するため、変更
対象部分のステートを、”プライベイト”にするように
サーバプロセス２００に要求する（ステップ９５０）。
サーバプロセス２００は、該要求を受け取ると、当該個
所のステートを”プライベイト”に変更する。また、該
変更を要求したユーザに、これを通知する（ステップ９
５５）。その後、該ユーザは、当該個所についてその内
容を変更することができる（ステップ９６０）。

【０１５７】変更が終了すると、該ユーザは、当該部分
のステートを”パブリック”に戻すように、サーバプロ
セス２００に要求する（ステップ９６５）。

【０１５８】サーバプロセス２００は、該要求を受け取
ると、当該部分のステートを”パブリック”に変更す
る。

【０１５９】次に、ステートが”リファレンス”になっ
ている部分、つまり、別のユーザが既に変更を行なって
いる部分対し、文書更新を行なおうとした場合処理を図
１２を用いて具体的に説明する。

【０１６０】ユーザＡが、文書のある部分、例えば、第
３章、のステートを、”リファレンス”に設定している
（ステップ９１０）。

【０１６１】この状態で、ユーザＢが、該第３章の部分
を更新しようした場合、該部分のステートは”リファレ
ンス”であるため、該ユーザＢは更新ができない。その
ため、ユーザＢは、サーバプロセス２００に、第３章の
ステートを”パブリック”にするように変更を要求する
（ステップ９１５）。すると、サーバプロセス２００
は、当該個所のステートを”リファレンス”に設定した
ユーザを調べて、該ユーザ、この場合ユーザＡに、ステ
ートを”パブリック”に変更するように要求する（ステ
ップ９２０）。

【０１６２】該要求に応じる場合には、ユーザＡは、該
変更要求の承認をサーバプロセス２００に通知する（ス
テップ９２５）。すると、サーバプロセス２００は、第
三章のステートを”パブリック”に変更する（ステップ
９３０）。また、該部分をアクセスしている全ユーザ
と、ユーザＢのようにアクセスを要求しているユーザに
ステートが変更されたことを通知する（ステップ９３
５）。

【０１６３】ユーザＢは、ステートが変更された通知を
受けると、該部分へのアクセスが可能となる（ステップ
９４０）。

【０１６４】以上説明した本実施例によれば、変更箇所
が重複する場合にも、文書格納の操作を伴わずに同一箇
所を複数のユーザ間で重ねて変更することができる特徴
がある。また、実施例１のような遅延文書格納のような
操作も必要ないという効果がある。

【０１６５】

【発明の効果】本発明によれば、後から変更を加えたユ
ーザの変更が先に変更を加えたユーザの文書の変更との
間で矛盾が生じることを防ぐことができるので複数のユ
ーザ間で共同で文書上の同一箇所を編集することが可能
となる効果がある。

【図面の簡単な説明】

【図１】図２に示した実施例のサーバプロセスの構成を
示す機能ブロック図である。

【図２】本発明の一実施例を示す全体のブロック図であ
る。

【図３】図２に示した実施例のクライアントプロセスの
構成を示す機能ブロック図である。

【図４】本実施例の文書格納処理全体の概要を示すフロ
ーチャートである。

【図５】遅延文書格納処理判定を示すフローチャートで
ある。

【図６】文書格納処理を説明するフローチャートであ
る。

【図７】文書編集終了時の待ちリストチェック処理を示
すフローチャートである。

【図８】遅延文書格納復帰処理の内容を示すフローチャ
ートである。

【図９】本発明の一実施例のネットワーク構成を示す説
明図である。

【図１０】本発明の一実施例のハードウエア構成を示す
説明図である。

【図１１】実施例２のステート変更処理を示すフローチ
ャートである。

【図１２】実施例２のステート変更処理を示すフローチ
ャートである。

【符号の説明】

１００…クライアントプロセス、１１０…対話処理部、
１２０…文書編集処理部、１３０…サーバインタフェー
ス部、１４０…画面制御部、１５０…画面バッファ、１
６０…ディスプレイ、１７０…キーボード、１８０…マ
ウス、２００…サーバプロセス、１１０…対話処理部、
１２０…文書編集処理部、１３０…サーバインタフェー
ス部、２１０…クライアントインタフェース部、２２０
…共同編集制御部、２３０…文書データ管理部、２３１
…論理構造管理部、２３２…レイアウトデータ管理部、
２３３…変更情報蓄積部、２４０…文書格納部、２５０
…ファイルアクセス制御部。

Claims (12)

【特許請求の範囲】
1. 【請求項１】データを分割して取り扱い、該分割単位毎
   に異なるユーザが編集処理を実行可能な文書編集システ
   ムであって、 データの編集処理を行う、一または二以上の編集手段
   と、 編集手段によりデータの編集処理が行われた場合、その
   編集内容を示す変更情報を、上記分割単位毎に蓄積する
   変更情報蓄積手段と、 上記編集処理においてデータの格納が指示された場合に
   は、上記変更情報を確認し、該変更情報に基づいて該格
   納処理の内容を変更する機能を有する格納手段と、 を備えたことを特徴とする文書編集システム。
2. 【請求項２】上記変更情報は、当該編集処理を実行した
   ユーザを示す識別データと、更新日時と、該編集処理結
   果の格納の有無を示すデータとを含み、 上記格納手段は、編集データの格納が指示された場合、
   該編集処理が行なわれる以前に他人により作成された未
   格納編集データが存在するか否かを、変更情報に基づい
   て、上記分割単位毎に判定し、未格納編集データが存在
   する場合には、該編集処理により作成された編集データ
   について、上記分割単位毎に、該他人の未格納編集デー
   タの存在を記載したリストを作成し、該格納処理を待機
   状態とすることを特徴とする請求項１記載の文書編集シ
   ステム。
3. 【請求項３】上記格納手段は、上記未格納編集データが
   存在しない場合には、該編集データの格納処理をただち
   に実行することを特徴とする請求項２記載の文書編集シ
   ステム。
4. 【請求項４】上記格納手段は、上記格納処理を実行した
   後、該編集データの記載されたリストを検索し、該リス
   ト上から該編集データの記載を削除し、さらに、該削除
   の結果、該リストが空になった場合には、該リストに対
   応する未格納編集データの格納処理を実行することを特
   徴とする請求項３記載の文書編集システム。
5. 【請求項５】上記編集手段が編集データを格納しないま
   ま終了した場合、上記格納手段は、該編集データの記載
   されている上記リストを検索し、該リストに対応する未
   格納編集データの格納指示を無効にすることを特徴とす
   る請求項４記載の文書編集システム。
6. 【請求項６】上記編集手段が編集データを格納しないま
   ま終了した場合、上記格納手段は、該編集データの記載
   されている上記リストを検索し、該リストに対応する未
   格納編集データを回復用データとして保存することを特
   徴とする請求項４記載の文書編集システム。
7. 【請求項７】データを分割して取り扱い、該分割単位毎
   に異なるユーザが編集処理を実行可能な文書編集システ
   ムであって、 データの編集を行う複数の編集手段と、 編集手段からのアクセスの可否を示すステータスを、上
   記分割単位毎に、記憶するステータス手段と、 上記編集手段からの要求に応じてステータスを変更する
   機能を有するステータス変更手段と、 を備えたことを特徴とする文書編集システム。
8. 【請求項８】上記ステータスには、プライベイト−ステ
   イトと、リファレンス−ステイトと、パブリック−ステ
   イトとの少なくとも三種類を有し、 プライベイト−ステイトとなっている分割単位について
   は、編集手段による編集結果を当該編集を実行した編集
   手段以外の編集手段からは、参照も、編集もできない状
   態であり、 リファレンス−ステイトとなっている分割単位について
   は、編集手段による編集結果を当該編集を実行した編集
   手段以外の編集手段から、参照はできるが、編集はでき
   ない状態であり、 パブリック−ステイトとなっている分割単位について
   は、編集手段による編集結果を当該編集を実行した編集
   手段以外の編集手段から、参照も編集もできる状態であ
   ることを特徴とする請求項７記載の文書編集システム。
9. 【請求項９】一編集手段が、ある分割単位へアクセスす
   ると、該分割単位のステートを調べ、その結果がリファ
   レンス−ステイトまたはパブリック−ステイトであった
   場合には、該分割単位のステータスを該状態に変更させ
   た編集手段に対し、ステータスの変更要求を出力するス
   テータス変更要求手段を有し、 上記ステータス変更手段は、上記ステータス変更要求を
   受けたステータス変更手段から、ステータスの変更を許
   可する指示を受け取った場合、該分割単位のステータス
   を上記一編集手段の要求に応じて変更する機能を有する
   ことを特徴とする請求項８記載の文書編集システム。
10. 【請求項１０】上記分割単位は、データの論理構造に基
    づいて決定されることを特徴とする請求項１、２、３、
    ４、５、６、７、８または９記載の文書編集システム。
11. 【請求項１１】上記分割の単位は、頁であることを特徴
    とする請求項１、２、３、４、５、６、７、８または９
    記載の文書編集システム。
12. 【請求項１２】上記ステータス変更手段は、各分割単位
    のステータスの状態に応じて、当該分割単位毎の表示態
    様を変更することを特徴とする請求項１、２、３、４、
    ５、６、７、８、９、１０または１１記載の文書編集シ
    ステム。