【手続補正書】
【提出日】平成18年7月11日(2006.7.11)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ドキュメントを取り扱う情報処理装置であって、
前記ドキュメントに含まれる通知先情報を取得する取得手段と、
前記取得した通知先情報を基に、通知先に前記ドキュメントが登録あるいは更新されたことを通知する通知手段とを備えたことを特徴とする情報処理装置。
【請求項２】
前記ドキュメントを入力する入力手段と、
前記入力したドキュメントを蓄積する蓄積手段と、
前記入力したドキュメントの更新前のドキュメントが前記蓄積手段に蓄積されているか否かを判別する更新判別手段とを備え、
前記通知手段は、前記更新前のドキュメントが蓄積されていた場合、前記通知先に前記ドキュメントが更新されたことを通知することを特徴とする請求項１記載の情報処理装置。
【請求項３】
前記更新判別手段によって前記更新前のドキュメントが蓄積されていたと判別された場合、前記ドキュメントの更新部分が前記通知先に通知するための通知条件を満たすか否かを判別する条件判別手段を備え、
前記通知手段は、前記条件が満たされた場合、前記通知先に通知することを特徴とする請求項２記載の情報処理装置。
【請求項４】
前記通知条件は、前記ドキュメントの更新部分が前記ドキュメントに記述されたリンク先のファイルであることを特徴とする請求項３記載の情報処理装置。
【請求項５】
前記通知条件は、前記ドキュメントの更新部分が前記ドキュメントに記述された当該ドキュメントの所定範囲であることを特徴とする請求項３記載の情報処理装置。
【請求項６】
ドキュメントを取り扱う情報処理装置のドキュメント処理方法であって、
前記ドキュメントに含まれる通知先情報を取得する取得ステップと、
前記取得した通知先情報を基に、通知先に前記ドキュメントが登録あるいは更新されたことを通知する通知ステップとを有することを特徴とするドキュメント処理方法。
【請求項７】
前記ドキュメントを入力する入力ステップと、
前記入力したドキュメントを蓄積する蓄積ステップと、
前記入力したドキュメントの更新前のドキュメントが前記蓄積手段に蓄積されているか否かを判別する更新判別ステップとを有し、
前記通知ステップでは、前記更新前のドキュメントが蓄積されていた場合、前記通知先に前記ドキュメントが更新されたことを通知することを特徴とする請求項６記載のドキュメント処理方法。
【請求項８】
前記更新判別ステップで前記更新前のドキュメントが蓄積されていたと判別された場合、前記ドキュメントの更新部分が前記通知先に通知するための通知条件を満たすか否かを判別する条件判別ステップを有し、
前記通知ステップでは、前記条件が満たされた場合、前記通知先に通知することを特徴とする請求項７記載のドキュメント処理方法。
【請求項９】
クライアント装置およびサーバ装置を備え、ドキュメントを蓄積するクライアントサーバシステムであって、
前記クライアント装置は、前記ドキュメントをサーバ装置に出力する出力手段を備え、
前記サーバ装置は、前記クライアント装置から前記ドキュメントを入力する入力手段と、前記入力したドキュメントを蓄積する蓄積手段と、前記入力したドキュメントの更新前のドキュメントが前記蓄積手段に蓄積されているか否かを判別する判別手段と、
前記更新前のドキュメントが蓄積されている場合、前記入力したドキュメントと前記更新前のドキュメントを比較し、更新部分を認識する更新部分認識手段と、
前記ドキュメントに含まれる通知先情報、および前記通知先情報と関連付けられたドキュメント部分指示情報を取得する通知先情報取得手段と、
前記認識された更新部分が前記取得したドキュメント部分指示情報によって示されるドキュメント部分に含まれる場合、前記取得した通知先情報を基に、通知先に前記ドキュメントを更新した旨を通知する通知手段とを備えたことを特徴とするクライアントサーバシステム。
【請求項１０】
請求項６乃至８のいずれかに記載のドキュメント処理方法を実現するためのコンピュータ読み取り可能なプログラムコードを保持する記憶媒体。
【請求項１１】
請求項６乃至８のいずれかに記載のドキュメント処理方法を実現するためのコンピュータ読み取り可能なプログラムコードを有するプログラム。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】００１１
【補正方法】削除
【補正の内容】
【手続補正３】
【補正対象書類名】明細書
【補正対象項目名】００１２
【補正方法】削除
【補正の内容】
【手続補正４】
【補正対象書類名】明細書
【補正対象項目名】００１３
【補正方法】削除
【補正の内容】
【手続補正５】
【補正対象書類名】明細書
【補正対象項目名】００１４
【補正方法】削除
【補正の内容】
【手続補正６】
【補正対象書類名】明細書
【補正対象項目名】００１５
【補正方法】削除
【補正の内容】
【手続補正７】
【補正対象書類名】明細書
【補正対象項目名】００１６
【補正方法】削除
【補正の内容】
【手続補正８】
【補正対象書類名】明細書
【補正対象項目名】００１７
【補正方法】削除
【補正の内容】
【手続補正９】
【補正対象書類名】明細書
【補正対象項目名】００１８
【補正方法】削除
【補正の内容】
【手続補正１０】
【補正対象書類名】明細書
【補正対象項目名】００４７
【補正方法】変更
【補正の内容】
【００４７】
そして、ステップＳ１５で、全てのｍａｉｌｅｄ＿ｔｏ通知先アドレスを処理し終わったか、あるいは始めからｍａｉｌｅｄ＿ｔｏ通知先アドレスが１つもない場合、タイプｍａｉｌｅｄ＿ｔｏ＿ｗｉｔｈ＿ｄｏｃｕｍｅｎｔのテーブルの中に、通知先アドレスが記憶されているか否かを判別する（ステップＳ１９）。記憶されている場合、さらに、ｄｏｃ＿ｒｅｆ属性値が記憶されているか否かを判別する（ステップＳ２０）。これも記憶されている場合、処理中の通知先アドレスに対して、ｄｏｃ＿ｒｅｆ属性値であるＵＲＩ情報を付加し、メッセージ種別によって示されるメッセージを通知すると共に、ステップＳ１４で蓄積されたドキュメントも送信する（ステップＳ２２）。具体的にはドキュメントは、メールの添付ファイルとして送られる。この後、ステップＳ１９の処理に戻る。一方、ステップＳ２０でｄｏｃ＿ｒｅｆ属性値が記憶されていない場合、単に通知先アドレスに対し、メッセージ種別によって示されるメッセージを通知すると共に、ステップＳ１４で蓄積されたドキュメントも送信する（ステップＳ２１）。この後、ステップＳ１９の処理に戻る。ｄｏｃ＿ｒｅｆ属性が無くても、タイトルやＵＲＬを付加してもよいことは、前述した場合と同様である。このように通知した後、ステップＳ１９に戻って、次の通知先アドレスが記憶されているか否かを判別する。このループによって、全てのｍａｉｌｅｄ＿ｔｏ＿ｗｉｔｈ＿ｄｏｃｕｍｅｎｔ通知先アドレスを処理する。
【手続補正１１】
【補正対象書類名】明細書
【補正対象項目名】００４８
【補正方法】変更
【補正の内容】
【００４８】
そして、全てのｍａｉｌｅｄ＿ｔｏ＿ｗｉｔｈ＿ｄｏｃｕｍｅｎｔ通知先アドレスを処理し終わったか、あるいは始めからｍａｉｌｅｄ＿ｔｏ＿ｗｉｔｈ＿ｄｏｃｕｍｅｎｔ通知先アドレスが１つもない場合、本処理を終了する。このように、タイプｍａｉｌｅｄ＿ｔｏ＿ｗｉｔｈ＿ｄｏｃｕｍｅｎｔを指定すると、ドキュメントそのものも通知先アドレスに送られるので、通知されたユーザは、即座にドキュメントを確認できる。
【手続補正１２】
【補正対象書類名】明細書
【補正対象項目名】００５２
【補正方法】変更
【補正の内容】
【００５２】
この操作が行われた場合、クライアント装置１０６内の制御部１１３は、出力しようとしているドキュメントを解析する（ステップＳ４２）。この段階で、このドキュメントがＸＭＬドキュメントであるか否かを判別し、ＸＭＬドキュメントである場合、ＸＭＬ規格に則ってタグ付データ、要素、属性等を解析する。尚、このステップＳ４２における解析処理は、必ずしもこのステップ位置である必要はない。ステップＳ４１の出力操作の前であってもよく、ドキュメントを編集している場合、そこで解析処理を済ませてもよい。
【手続補正１３】
【補正対象書類名】明細書
【補正対象項目名】００５３
【補正方法】変更
【補正の内容】
【００５３】
制御部１１３は、これらの解析済み情報の中に通知先情報があるか否かを判別する（ステップＳ４３）。図２に示すドキュメントでは、制御部１１３がｎｏｔｉｆｉｃａｔｉｏｎ要素の中に、ｍａｉｌｅｄ＿ｔｏ要素あるいはｍａｉｌｅｄ＿ｔｏ＿ｗｉｔｈ＿ｄｏｃｕｍｅｎｔ要素を見つけると、通知先情報があったものと判断する。
【手続補正１４】
【補正対象書類名】明細書
【補正対象項目名】００５４
【補正方法】変更
【補正の内容】
【００５４】
ステップＳ４３で通知先情報が存在する場合、制御部１１３は、その通知先情報がｍａｉｌｅｄ＿ｔｏ要素であるか否かを判別する（ステップＳ４４）。ｍａｉｌｅｄ＿ｔｏ要素である場合、その内容に記述されている通知先メールアドレスを、タイプｍａｉｌｅｄ＿ｔｏのテーブルに記憶する（ステップＳ４５）。タイプｍａｉｌｅｄ＿ｔｏのテーブルは、クライアント装置１０６の記憶媒体１１２に記憶されるデータの一部であり、その形式は前述した図６に示す通りである。
【手続補正１５】
【補正対象書類名】明細書
【補正対象項目名】００５５
【補正方法】変更
【補正の内容】
【００５５】
一方、ステップＳ４４で通知先情報がｍａｉｌｅｄ＿ｔｏ要素でなかった場合、制御部１１３は、通知先情報がｍａｉｌｅｄ＿ｔｏ＿ｗｉｔｈ＿ｄｏｃｕｍｅｎｔ要素であるか否かを判別する（ステップＳ４９）。ｍａｉｌｅｄ＿ｔｏ＿ｗｉｔｈ＿ｄｏｃｕｍｅｎｔ要素である場合、その内容に記述されている通知先メールアドレスを、タイプｍａｉｌｅｄ＿ｔｏ＿ｗｉｔｈ＿ｄｏｃｕｍｅｎｔのテーブルに記憶する（ステップＳ５０）。タイプｍａｉｌｅｄ＿ｔｏ＿ｗｉｔｈ＿ｄｏｃｕｍｅｎｔのテーブルは、記憶媒体１１２に記憶されるデータの一部であり、その形式は前述した図７に示す通りである。
【手続補正１６】
【補正対象書類名】明細書
【補正対象項目名】００５８
【補正方法】変更
【補正の内容】
【００５８】
そして、ｄｏｃ＿ｒｅｆ属性値を記憶した後、あるいはステップＳ４６でｄｏｃ＿ｒｅｆ属性値がない場合、次の通知先情報を取得する（ステップＳ４８）。この後、ステップＳ４３に戻り、通知先情報がなくなるまで同様の処理を繰り返す。こうして全ての通知先情報を処理し終わり、ステップＳ４３で処理すべき通知先情報がなくなると、クライアント装置１０６内の制御部１１３は、サーバ装置１０１と交信を行い、ドキュメントの更新前バージョンがサーバ装置１０１に既に存在するか否かを調べる（ステップＳ５１）。この処理は所定のプロトコルに則って行われる。
【手続補正１７】
【補正対象書類名】明細書
【補正対象項目名】００５９
【補正方法】変更
【補正の内容】
【００５９】
ドキュメントの更新前バージョンがサーバ装置１０１に存在しない場合、今回の操作はドキュメントの登録とみなされ、後で送信するメッセージのメッセージ種別を”登録”として記憶する（ステップＳ５３）。一方、ドキュメントの更新前のバージョンがサーバ装置１０１に存在する場合、今回の操作はドキュメントの更新とみなされ、メッセージ種別を”更新”として記憶する（ステップＳ５２）。ステップＳ５２、Ｓ５３でメッセージ種別を記憶した後、クライアント装置１０６内の制御部１１３は、ドキュメントをサーバ装置１０１に出力する（ステップＳ５４）。
【手続補正１８】
【補正対象書類名】明細書
【補正対象項目名】００６２
【補正方法】変更
【補正の内容】
【００６２】
こうして通知された後、ステップＳ５５に戻り、次の通知先アドレスが記憶されているか否か判別する。このループによって、全てのｍａｉｌｅｄ＿ｔｏ通知先アドレスを処理する。全てのｍａｉｌｅｄ＿ｔｏ通知先アドレスを処理し終わったか、あるいは始めからｍａｉｌｅｄ＿ｔｏ通知先アドレスが１つもない場合、タイプｍａｉｌｅｄ＿ｔｏ＿ｗｉｔｈ＿ｄｏｃｕｍｅｎｔのテーブルの中に、通知先アドレスが記憶されているか否かを判別する（ステップＳ５９）。通知先アドレスが記憶されている場合、ｄｏｃ＿ｒｅｆ属性値が記憶されているか否かを判別する（ステップＳ６０）。これも記憶されている場合、処理中の通知先アドレスに対してｄｏｃ＿ｒｅｆ属性値であるＵＲＩ情報を付加し、メッセージ種別によって示されるメッセージを通知すると共に、ステップＳ５４で出力したドキュメントも送信する（ステップＳ６２）。この後、ステップＳ５９の処理に戻る。具体的に、ドキュメントはメールの添付ファイルとして送られる。
【手続補正１９】
【補正対象書類名】明細書
【補正対象項目名】００６４
【補正方法】変更
【補正の内容】
【００６４】
こうして通知が行われた後、ステップＳ５９に戻り、次の通知先アドレスが記憶されているか否かを判別する。このループによって、全てのｍａｉｌｅｄ＿ｔｏ＿ｗｉｔｈ＿ｄｏｃｕｍｅｎｔ通知先アドレスを処理する。そして、全てのｍａｉｌｅｄ＿ｔｏ＿ｗｉｔｈ＿ｄｏｃｕｍｅｎｔ通知先アドレスを処理し終わったか、あるいは始めからｍａｉｌｅｄ＿ｔｏ＿ｗｉｔｈ＿ｄｏｃｕｍｅｎｔ通知先アドレスが１つもない場合、本処理を終了する。
【手続補正２０】
【補正対象書類名】明細書
【補正対象項目名】００６８
【補正方法】変更
【補正の内容】
【００６８】
制御部１０３は、これらの解析済み情報の中に、通知先情報があるか否かを判別する（ステップＳ７３）。図２に示すドキュメントでは、制御部１０３がｎｏｔｉｆｉｃａｔｉｏｎ要素の中に、ｍａｉｌｅｄ＿ｔｏ要素あるいはｍａｉｌｅｄ＿ｔｏ＿ｗｉｔｈ＿ｄｏｃｕｍｅｎｔ要素を見つけると、通知先情報があったものと判断する。通知先情報があった場合、そのアドレスを記憶媒体１０２のテーブルに記憶する（ステップＳ７４）。図１６は通知先情報を示すテーブルである。このテーブルには、各通知先アドレスのエントリ毎に、タイプ、ｄｏｃ＿ｒｅｆ属性値、複数個のｉｆ＿ｕｐｄａｔｅｄ属性値を記憶する領域が設けられている。タイプとしては、タイプｍａｉｌｅｄ＿ｔｏであるか、あるいはタイプｍａｉｌｅｄ＿ｔｏ＿ｗｉｔｈ＿ｄｏｃｕｍｅｎｔのいずれかである。つまり、このテーブルは、前述した第１の実施形態における図６、図７のテーブルを結合した形式をとっている。尚、本実施形態において、図１６の形式をとることは必須ではない。前述した図６および図７の形式をとってもよい。また、前記第１もしくは第２の実施形態において、図１６の形式をとることも可能である。
【手続補正２１】
【補正対象書類名】明細書
【補正対象項目名】００６９
【補正方法】変更
【補正の内容】
【００６９】
ステップＳ７４の処理後、通知先情報の要素が示すタイプ（ｍａｉｌｅｄ＿ｔｏあるいはｍａｉｌｅｄ＿ｔｏ＿ｗｉｔｈ＿ｄｏｃｕｍｅｎｔのどちらか）をテーブルに記憶する（ステップＳ７５）。さらに、制御部１０３は、通知先情報の要素の中に、ｄｏｃ＿ｒｅｆ属性があるか否かを調べる（ステップＳ７６）。ｄｏｃ＿ｒｅｆ属性がある場合、そのｄｏｃ＿ｒｅｆ属性値を記憶する（ステップＳ７７）。一方、ｄｏｃ＿ｒｅｆ属性がない場合、ステップＳ７７の処理をスキップし、ステップＳ７８の処理に進む。
【手続補正２２】
【補正対象書類名】明細書
【補正対象項目名】００８８
【補正方法】変更
【補正の内容】
【００８８】
これにより、ドキュメント入力ステップとドキュメント比較ステップが分離されるので、それぞれのステップを別アプリケーションで実行可能となる。例えば、ＮＦＳ（Ｎｅｔｗｏｒｋ  Ｆｉｌｅ  Ｓｙｓｔｅｍ）プロトコルを用いて、クライアント装置１０６からサーバ装置１０１上のドキュメントファイルを更新する。この場合、サーバ装置１０１が実行する定期的なチェックにより、更新部分の認識は可能である。これにより、クライアント装置１０６は、特別なアプリケーションを立ち上げることなく、ドキュメントを単にエディットするだけで、更新が通知先に通知される。そして、通知先の部分については再入力の必要がない。