(57)【要約】    【課題】  ドキュメントを取り扱う際、その登録あるいは更新を通知する通知先の情報を一緒に取り扱うことができる情報処理装置を提供する。    【解決手段】  サーバ装置１０１内の制御部１０３は、クライアント装置１０６からのドキュメントを入力し（Ｓ１）、解析する（Ｓ２）。解析済み情報の中に、通知先情報があるか否かを判別する（Ｓ３）。全ての通知先情報を処理し終わると、制御部１０３は、ドキュメントの更新前バージョンが記憶媒体１０２に既に存在するか否かを判別し（Ｓ１１）、存在しない場合、送信するメッセージのメッセージ種別を”登録”に設定して記憶する（Ｓ１３）。一方、更新前バージョンが記憶媒体１０２に既に存在する場合、メッセージ種別を”更新”に設定して記憶する（Ｓ１２）。メッセージ種別を記憶した後、制御部１０３は、ドキュメントを記憶媒体１０２の所定の位置に蓄積する（Ｓ１４）。【選択図】      図３
2005346671.tif 000002
【特許請求の範囲】
【請求項１】
ドキュメントを取り扱う情報処理装置であって、
前記ドキュメントに含まれる通知先情報を取得する取得手段と、
前記取得した通知先情報を基に、通知先に前記ドキュメントが登録あるいは更新されたことを通知する通知手段とを備えたことを特徴とする情報処理装置。
【請求項２】
前記ドキュメントを入力する入力手段と、
前記入力したドキュメントを蓄積する蓄積手段と、
前記入力したドキュメントの更新前のドキュメントが前記蓄積手段に蓄積されているか否かを判別する更新判別手段とを備え、
前記通知手段は、前記更新前のドキュメントが蓄積されていた場合、前記通知先に前記ドキュメントが更新されたことを通知することを特徴とする請求項１記載の情報処理装置。
【請求項３】
前記更新判別手段によって前記更新前のドキュメントが蓄積されていたと判別された場合、前記ドキュメントの更新部分が前記通知先に通知するための通知条件を満たすか否かを判別する条件判別手段を備え、
前記通知手段は、前記条件が満たされた場合、前記通知先に通知することを特徴とする請求項２記載の情報処理装置。
【請求項４】
前記通知条件は、前記ドキュメントの更新部分が前記ドキュメントに記述されたリンク先のファイルであることを特徴とする請求項３記載の情報処理装置。
【請求項５】
前記通知条件は、前記ドキュメントの更新部分が前記ドキュメントに記述された当該ドキュメントの所定範囲であることを特徴とする請求項３記載の情報処理装置。
【請求項６】
ドキュメントを取り扱う情報処理装置のドキュメント処理方法であって、
前記ドキュメントに含まれる通知先情報を取得する取得ステップと、
前記取得した通知先情報を基に、通知先に前記ドキュメントが登録あるいは更新されたことを通知する通知ステップとを有することを特徴とするドキュメント処理方法。
【請求項７】
前記ドキュメントを入力する入力ステップと、
前記入力したドキュメントを蓄積する蓄積ステップと、
前記入力したドキュメントの更新前のドキュメントが前記蓄積手段に蓄積されているか否かを判別する更新判別ステップとを有し、
前記通知ステップでは、前記更新前のドキュメントが蓄積されていた場合、前記通知先に前記ドキュメントが更新されたことを通知することを特徴とする請求項６記載のドキュメント処理方法。
【請求項８】
前記更新判別ステップで前記更新前のドキュメントが蓄積されていたと判別された場合、前記ドキュメントの更新部分が前記通知先に通知するための通知条件を満たすか否かを判別する条件判別ステップを有し、
前記通知ステップでは、前記条件が満たされた場合、前記通知先に通知することを特徴とする請求項７記載のドキュメント処理方法。
【請求項９】
ドキュメントを蓄積するサーバ装置であって、
前記ドキュメントに含まれる通知先情報を取得する通知先情報取得手段と、
前記取得した通知先情報を基に、通知先に前記ドキュメントを登録した旨を通知する通知手段とを備えたことを特徴とするサーバ装置。
【請求項１０】
ドキュメントを出力するクライアント装置であって、
前記ドキュメントをサーバ装置に出力する出力手段と、
前記ドキュメントに含まれる通知先情報を取得する通知先情報取得手段と、
前記取得した通知先情報を基に、通知先に前記ドキュメントを登録した旨を通知する通知手段とを備えたことを特徴とするクライアント装置。
【請求項１１】
クライアント装置およびサーバ装置を備え、ドキュメントを蓄積するクライアントサーバシステムであって、
前記クライアント装置は、前記ドキュメントをサーバ装置に出力する出力手段を備え、
前記サーバ装置は、前記クライアント装置から前記ドキュメントを入力する入力手段と、前記ドキュメントに含まれる通知先情報を取得する通知先情報取得手段と、前記通知先情報を基に通知先に前記ドキュメントを登録した旨を通知する通知手段とを備えたことを特徴とするクライアントサーバシステム。
【請求項１２】
ドキュメントを蓄積するサーバ装置であって、
前記ドキュメントを入力する入力手段と、
前記入力したドキュメントを蓄積する蓄積手段と、
前記入力したドキュメントの更新前のドキュメントが前記蓄積手段に蓄積されているか否かを判別する判別手段と、
前記ドキュメントに含まれる通知先情報を取得する通知先情報取得手段と、
前記更新前のドキュメントが蓄積されていた場合、前記取得した通知先情報を基に、通知先に前記ドキュメントを更新した旨を通知する通知手段とを備えたことを特徴とするサーバ装置。
【請求項１３】
ドキュメントを出力するクライアント装置であって、
前記ドキュメントをサーバ装置に出力する出力手段と、
前記ドキュメントの更新前のドキュメントが前記サーバ装置にあるか否かを判別する判別手段と、
前記ドキュメントに含まれる通知先情報を取得する通知先情報取得手段と、
前記更新前のドキュメントが前記サーバ装置にある場合、前記取得した通知先情報を基に、通知先に前記ドキュメントを更新した旨を通知する通知手段とを備えたことを特徴とするクライアント装置。
【請求項１４】
クライアント装置およびサーバ装置を備え、ドキュメントを蓄積するクライアントサーバシステムであって、
前記クライアント装置は、前記ドキュメントをサーバ装置に出力する出力手段を備え、
前記サーバ装置は、前記クライアント装置から前記ドキュメントを入力する入力手段と、前記入力したドキュメントを蓄積する蓄積手段と、前記入力したドキュメントの更新前のドキュメントが前記蓄積手段に蓄積されているか否かを判別する判別手段と、前記ドキュメントに含まれる通知先情報を取得する通知先情報取得手段と、前記更新前のドキュメントが蓄積されていた場合、前記通知先情報を基に通知先に前記ドキュメントを更新した旨を通知する通知手段とを備えたことを特徴とするクライアントサーバシステム。
【請求項１５】
ドキュメントを蓄積するサーバ装置であって、
前記ドキュメントを入力する入力手段と、
前記入力したドキュメントを蓄積する蓄積手段と、
前記入力したドキュメントの更新前のドキュメントが前記蓄積手段に蓄積されているか否かを判別する判別手段と、
前記更新前のドキュメントが蓄積されていた場合、前記入力したドキュメントと前記更新前のドキュメントを比較し、更新部分を認識する更新部分認識手段と、
前記ドキュメントに含まれる通知先情報、および前記通知先情報と関連付けられたドキュメント部分指示情報を取得する通知先情報取得手段と、
前記認識された更新部分が前記取得したドキュメント部分指示情報によって示されるドキュメント部分に含まれる場合、前記取得した通知先情報を基に、通知先に前記ドキュメントを更新した旨を通知する通知手段とを備えたことを特徴とするサーバ装置。
【請求項１６】
ドキュメントを出力するクライアント装置であって、
前記ドキュメントをサーバ装置に出力する出力手段と、
前記ドキュメントの更新前のドキュメントが前記サーバ装置にあるか否かを判別する判別手段と、
前記更新前のドキュメントが前記サーバ装置にある場合、前記出力したドキュメントと前記更新前のドキュメントを比較し、更新部分を認識する更新部分認識手段と、
前記ドキュメントに含まれる通知先情報、および前記通知先情報と関連付けられたドキュメント部分指示情報を取得する通知先情報取得手段と、
前記認識された更新部分が前記取得したドキュメント部分指示情報によって示されるドキュメント部分に含まれる場合、前記取得した通知先情報を基に、通知先に前記ドキュメントを更新した旨を通知する通知手段とを備えたことを特徴とするクライアント装置。
【請求項１７】
クライアント装置およびサーバ装置を備え、ドキュメントを蓄積するクライアントサーバシステムであって、
前記クライアント装置は、前記ドキュメントをサーバ装置に出力する出力手段を備え、
前記サーバ装置は、前記クライアント装置から前記ドキュメントを入力する入力手段と、前記入力したドキュメントを蓄積する蓄積手段と、前記入力したドキュメントの更新前のドキュメントが前記蓄積手段に蓄積されているか否かを判別する判別手段と、前記更新前のドキュメントが蓄積されている場合、前記入力したドキュメントと前記更新前のドキュメントを比較し、更新部分を認識する更新部分認識手段と、前記ドキュメントに含まれる通知先情報、および前記通知先情報と関連付けられたドキュメント部分指示情報を取得する通知先情報取得手段と、前記認識された更新部分が前記取得したドキュメント部分指示情報によって示されるドキュメント部分に含まれる場合、前記取得した通知先情報を基に、通知先に前記ドキュメントを更新した旨を通知する通知手段とを備えたことを特徴とするクライアントサーバシステム。
【請求項１８】
請求項６乃至８のいずれかに記載のドキュメント処理方法を実現するためのコンピュータ読み取り可能なプログラムコードを保持する記憶媒体。
【請求項１９】
請求項６乃至８のいずれかに記載のドキュメント処理方法を実現するためのコンピュータ読み取り可能なプログラムコードを有するプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ドキュメントの登録あるいは更新を行う際、登録あるいは更新があったことをユーザに通知する情報処理装置およびドキュメント処理方法に関する。
【背景技術】
【０００２】
従来、ユーザによって参照されるデータを蓄積するコンピュータシステムでは、データの更新があったことをユーザに通知することが行われている。ここで、データに該当するものとして、文書データ、スプレッドシートのデータ、Ｗｅｂページ、これらの複合データなど種々のものが挙げられるが、ここでは、これらをひとまとめにしてドキュメントと称することにする。
【０００３】
ドキュメントがサーバに蓄積された場合、サーバ上のドキュメントが更新されただけで、何も通知しなければ、ドキュメントの最新情報を知る必要があるユーザにそのことが伝わらないおそれがあった。このユーザは、最新情報を知るために、自らアクションを起こし、常にサーバ上のドキュメントを確認する必要があった。しかしながら、当然のことながら、確認を忘れた人がドキュメントの最新情報を知らなかったという状況が発生する。また、ドキュメントの更新に気付くのが遅れることもある。
【０００４】
これに対し、特許文献１には、ホームページが更新された場合、予めカテゴリに分けて登録されたメールアドレスに対し、通知することが示されている。また、特許文献２には、データファイルの登録要求時に指定される通知先アドレスを、そのデータファイルに関連付けて登録する通知先登録手段を備え、データファイルの登録が電子メールで通知先に通知されることが示されている。また、データファイルが変更または削除された場合、その旨を電子メールで通知する更新通知手段も示されている。
【特許文献１】特開２００１−３３１４１２号公報
【特許文献２】特開平１０−２５４７５２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、上記従来例では、以下に掲げる問題があった。すなわち、特許文献１では、どのホームページが更新された場合、どのユーザに通知されるのかを詳細に決めることができなかった。ある程度のカテゴリ分けによって捉えられるのかも知れないが、逆に言えば、通知先はカテゴリに登録されたアドレスに限定されてしまう。例えば、ホームページ１ページ毎に通知先を変更するようなことはできなかった。
【０００６】
また、特許文献２では、書棚／書類箱に格納された書類と通知先アドレスの関連情報が存在する。したがって、書類毎に通知先を変更することが可能である。しかし、この関連付け情報は、ファイリングサーバシステム上に存在する。また、ドキュメントの変更と同時に通知先も変更したい場合、ユーザは、ドキュメントの変更に加え、ファイリングサーバシステム内の所定の機能を起動し、ドキュメントに関連付けられた通知先アドレスを変更しなければならなかった。これは、ユーザにとって二度手間である。
【０００７】
さらに、上記特許文献１、２のいずれにおいても、「ドキュメントの特定の部分が変更された場合に限って、その旨を誰かに通知する」というような通知はできなかった。
【０００８】
そこで、本発明は、ドキュメントを取り扱う際、その登録あるいは更新を通知する通知先の情報を一緒に取り扱うことができる情報処理装置およびドキュメント処理方法を提供することを目的とする。また、本発明は、ドキュメントの一部が更新され、更新部分が事前に指定されている部分である場合、更新の通知を所定のユーザに行うか否かを設定できる情報処理装置およびドキュメント処理方法を提供することを他の目的とする。
【課題を解決するための手段】
【０００９】
上記目的を達成するために、本発明の情報処理装置は、ドキュメントを取り扱う情報処理装置であって、前記ドキュメントに含まれる通知先情報を取得する取得手段と、前記取得した通知先情報を基に、通知先に前記ドキュメントが登録あるいは更新されたことを通知する通知手段とを備えたことを特徴とする。
【００１０】
本発明のドキュメント処理方法は、ドキュメントを取り扱う情報処理装置のドキュメント処理方法であって、前記ドキュメントに含まれる通知先情報を取得する取得ステップと、前記取得した通知先情報を基に、通知先に前記ドキュメントが登録あるいは更新されたことを通知する通知ステップとを有することを特徴とする。
【００１１】
本発明のサーバ装置は、ドキュメントを蓄積するサーバ装置であって、前記ドキュメントに含まれる通知先情報を取得する通知先情報取得手段と、前記取得した通知先情報を基に、通知先に前記ドキュメントを登録した旨を通知する通知手段とを備えたことを特徴とする。
【００１２】
本発明のクライアント装置は、ドキュメントを出力するクライアント装置であって、前記ドキュメントをサーバ装置に出力する出力手段と、前記ドキュメントに含まれる通知先情報を取得する通知先情報取得手段と、前記取得した通知先情報を基に、通知先に前記ドキュメントを登録した旨を通知する通知手段とを備えたことを特徴とする。
【００１３】
本発明のクライアントサーバシステムは、クライアント装置およびサーバ装置を備え、ドキュメントを蓄積するクライアントサーバシステムであって、前記クライアント装置は、前記ドキュメントをサーバ装置に出力する出力手段を備え、前記サーバ装置は、前記クライアント装置から前記ドキュメントを入力する入力手段と、前記ドキュメントに含まれる通知先情報を取得する通知先情報取得手段と、前記通知先情報を基に通知先に前記ドキュメントを登録した旨を通知する通知手段とを備えたことを特徴とする。
【００１４】
本発明のサーバ装置は、ドキュメントを蓄積するサーバ装置であって、前記ドキュメントを入力する入力手段と、前記入力したドキュメントを蓄積する蓄積手段と、前記入力したドキュメントの更新前のドキュメントが前記蓄積手段に蓄積されているか否かを判別する判別手段と、前記ドキュメントに含まれる通知先情報を取得する通知先情報取得手段と、前記更新前のドキュメントが蓄積されていた場合、前記取得した通知先情報を基に、通知先に前記ドキュメントを更新した旨を通知する通知手段とを備えたことを特徴とする。
【００１５】
本発明のクライアント装置は、ドキュメントを出力するクライアント装置であって、前記ドキュメントをサーバ装置に出力する出力手段と、前記ドキュメントの更新前のドキュメントが前記サーバ装置にあるか否かを判別する判別手段と、前記ドキュメントに含まれる通知先情報を取得する通知先情報取得手段と、前記更新前のドキュメントが前記サーバ装置にある場合、前記取得した通知先情報を基に、通知先に前記ドキュメントを更新した旨を通知する通知手段とを備えたことを特徴とする。
【００１６】
本発明のクライアントサーバシステムは、クライアント装置およびサーバ装置を備え、ドキュメントを蓄積するクライアントサーバシステムであって、前記クライアント装置は、前記ドキュメントをサーバ装置に出力する出力手段を備え、前記サーバ装置は、前記クライアント装置から前記ドキュメントを入力する入力手段と、前記入力したドキュメントを蓄積する蓄積手段と、前記入力したドキュメントの更新前のドキュメントが前記蓄積手段に蓄積されているか否かを判別する判別手段と、前記ドキュメントに含まれる通知先情報を取得する通知先情報取得手段と、前記更新前のドキュメントが蓄積されていた場合、前記通知先情報を基に通知先に前記ドキュメントを更新した旨を通知する通知手段とを備えたことを特徴とする。
【００１７】
本発明のサーバ装置は、ドキュメントを蓄積するサーバ装置であって、前記ドキュメントを入力する入力手段と、前記入力したドキュメントを蓄積する蓄積手段と、前記入力したドキュメントの更新前のドキュメントが前記蓄積手段に蓄積されているか否かを判別する判別手段と、前記更新前のドキュメントが蓄積されていた場合、前記入力したドキュメントと前記更新前のドキュメントを比較し、更新部分を認識する更新部分認識手段と、前記ドキュメントに含まれる通知先情報、および前記通知先情報と関連付けられたドキュメント部分指示情報を取得する通知先情報取得手段と、前記認識された更新部分が前記取得したドキュメント部分指示情報によって示されるドキュメント部分に含まれる場合、前記取得した通知先情報を基に、通知先に前記ドキュメントを更新した旨を通知する通知手段とを備えたことを特徴とする。
【００１８】
本発明のクライアント装置は、ドキュメントを出力するクライアント装置であって、前記ドキュメントをサーバ装置に出力する出力手段と、前記ドキュメントの更新前のドキュメントが前記サーバ装置にあるか否かを判別する判別手段と、前記更新前のドキュメントが前記サーバ装置にある場合、前記出力したドキュメントと前記更新前のドキュメントを比較し、更新部分を認識する更新部分認識手段と、前記ドキュメントに含まれる通知先情報、および前記通知先情報と関連付けられたドキュメント部分指示情報を取得する通知先情報取得手段と、前記認識された更新部分が前記取得したドキュメント部分指示情報によって示されるドキュメント部分に含まれる場合、前記取得した通知先情報を基に、通知先に前記ドキュメントを更新した旨を通知する通知手段とを備えたことを特徴とする。
【００１９】
本発明のクライアントサーバシステムは、クライアント装置およびサーバ装置を備え、ドキュメントを蓄積するクライアントサーバシステムであって、前記クライアント装置は、前記ドキュメントをサーバ装置に出力する出力手段を備え、前記サーバ装置は、前記クライアント装置から前記ドキュメントを入力する入力手段と、前記入力したドキュメントを蓄積する蓄積手段と、前記入力したドキュメントの更新前のドキュメントが前記蓄積手段に蓄積されているか否かを判別する判別手段と、前記更新前のドキュメントが蓄積されている場合、前記入力したドキュメントと前記更新前のドキュメントを比較し、更新部分を認識する更新部分認識手段と、前記ドキュメントに含まれる通知先情報、および前記通知先情報と関連付けられたドキュメント部分指示情報を取得する通知先情報取得手段と、前記認識された更新部分が前記取得したドキュメント部分指示情報によって示されるドキュメント部分に含まれる場合、前記取得した通知先情報を基に、通知先に前記ドキュメントを更新した旨を通知する通知手段とを備えたことを特徴とする。
【発明の効果】
【００２０】
本発明の請求項１に係る情報処理装置によれば、ドキュメントに含まれる通知先情報を取得し、取得した通知先情報を基に、通知先にドキュメントが登録あるいは更新されたことを通知するので、ドキュメントを取り扱う際、その登録あるいは更新を通知する通知先の情報を一緒に取り扱うことができる。したがって、ドキュメントと通知先の情報をまとめて管理することができ、必要な時にドキュメントの閲覧・変更を途切れることなく行うことができる。
【００２１】
請求項３に係る情報処理装置によれば、ドキュメントの一部が更新され、更新部分が事前に指定されている部分である場合、更新の通知を所定のユーザに行うか否かを設定できる。請求項４に係る情報処理装置によれば、リンクされたファイルの更新の通知を設定できる。
【発明を実施するための最良の形態】
【００２２】
本発明の情報処理装置およびドキュメント処理方法の実施の形態について図面を参照しながら説明する。本実施形態の情報処理装置はクライアントサーバシステムに適用される。
【００２３】
［第１の実施形態］
図１は第１の実施形態におけるクライアントサーバシステムの構成を示す図である。本実施形態のクライアントサーバシステムは、サーバ装置１０１および複数台のクライアント装置１０６、１２６がネットワーク（ＬＡＮ）１０５を介して接続された構成を有する。また、ＬＡＮ１０５は、インターネット１０７に接続されている。インターネット１０７には、携帯電話１０８、ＰＣ１０９、携帯情報端末（ＰＤＡ）１１０等、多くの機器が接続されている。
【００２４】
サーバ装置１０１は、記憶媒体１０２、制御部１０３およびネットワークＩ／Ｆ１０４を備え、各種ドキュメントを蓄積する。記憶媒体１０２として、ハードディスク、ＲＡＭ、ＲＯＭ、その他のディスク装置やメモリ等が挙げられる。また、記憶媒体１０２には、ドキュメントが蓄積されると共に、各種アプリケーションプログラム、オペレーティングシステムのコード、および動作中のデータが記憶される。制御部１０３は、記憶媒体１０２に記憶されているプログラムを実行し、サーバ装置１０１全体を制御する。ネットワークＩ／Ｆ１０４は、ＬＡＮ１０５に接続するためのインタフェースである。ＬＡＮ１０５には、前述したように、サーバ装置１０１の他、複数台のクライアント装置１０６、１２６が接続されている。クライアント装置１０６、１２６は、サーバ装置１０１と同様、それぞれ記憶媒体１１２、制御部１１３およびネットワークＩ／Ｆ１１４を備え、サーバ装置１０１と同様の動作を行う。
【００２５】
尚、本実施形態では、ドキュメントは、テキスト文書に限定されず、例えばマルチメディアデータ等を含むものとして取り扱われる。あるいは、マルチメディアデータそのもの、例えばＧＩＦ画像ファイルとして取り扱われる。ただし、本実施形態のドキュメントは、その内部に通知先情報を含むものであるので、付加的情報を埋め込むことができないフォーマットを有するものはその対象外である。また、本実施形態では、ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）ドキュメントを、一例として示したが、これに限定されるものではない。
【００２６】
図２はＸＭＬドキュメントを示す図である。このＸＭＬドキュメント（以下、単にドキュメントという）では、最初の行にＸＭＬ宣言（”＜？ｘｍｌ”で始まり、”？＞”で終わる）が置かれ、Ｗ３Ｃ（Ｗｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂ  Ｃｏｎｓｏｒｔｉｕｍ）が定めるＸＭＬ規格に則ったドキュメントであることが示されている。
【００２７】
そして、ＤＴＤ（Ｄｏｃｕｍｅｎｔ  Ｔｙｐｅ  Ｄｅｆｉｎｉｔｉｏｎ、”＜！ＤＯＣＴＹＰＥ”で始まり、”］＞”で終わる）内で、ドキュメント内のタグ付データに現れる要素、属性等の宣言を行う。ＤＴＤの内容は本発明の本質と関係がないので省略する。実際のドキュメントでは、以下に示す要素や属性が宣言されてもよい。尚、ＤＴＤは、ＸＭＬドキュメントに必須というわけではなく、存在しなくてもよい。
【００２８】
そして、最上位（ルート）要素であるｄｏｃ要素２０１が置かれる。ｄｏｃ要素の内容として、ドキュメントのタイトルを示すｔｉｔｌｅ要素２０２、章を示す複数のｃｈａｐｔｅｒ要素２０３、２０４、２０５、および通知先情報を示すｎｏｔｉｆｉｃａｔｉｏｎ要素２０７が記述される。
【００２９】
また、ｎｏｔｉｆｉｃａｔｉｏｎ要素２０７の内容として、ｍａｉｌｅｄ＿ｔｏ要素２０８、２０９、２１１等、ｍａｉｌｅｄ＿ｔｏ＿ｗｉｔｈ＿ｄｏｃｕｍｅｎｔ要素２１０が記述される。ｍａｉｌｅｄ＿ｔｏ要素、ｍａｉｌｅｄ＿ｔｏ＿ｗｉｔｈ＿ｄｏｃｕｍｅｎｔ要素の内容として、通知先メールアドレス（単に、通知先アドレスともいう）が記述される。これらの要素には、様々な属性が付与される。
【００３０】
ここでは、通知先情報としてメールアドレスを記述したが、例えば、何らかの機器に通知する場合、マシンアドレスでもよい。また、携帯電話１０８のユーザに通知する場合、その電話番号でもよい。つまり、ドキュメントを解析して通知を行う主体が、要素内容を認識し、所定の手段を用いて通知できればよい。
【００３１】
尚、図１では、携帯電話１０８はインターネット１０７に接続されることが示されているが、図示しない携帯電話網からの着信を受けることは勿論可能である。この場合、例えばサーバ装置１０１から携帯電話網に向かって発信する手段、および携帯電話１０８の応答後、サーバ装置１０１から音声合成で通知する手段が必要である。
【００３２】
図３、図４および図５はクライアント装置１０６からサーバ装置１０１にドキュメントが送られた場合、サーバ装置１０１による通知処理手順を示すフローチャートである。この処理プログラムは、サーバ装置１０１内の記憶媒体１０２に格納されており、制御部１０３によって実行される。尚、送信のトリガとなる手段およびプロトコルについては、限定されない。実際、ＨＴＴＰ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）やＦＴＰ（Ｆｉｌｅ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）といった、一般的によく使用される既存のプロトコルでもよい。また、クライアント装置１０６は特定のアプリケーションを実行し、そのアプリケーションからの送信データを受け取るための特定のアプリケーションがサーバ装置１０１で実行される構成であってもよい。つまり、ドキュメントを受信したサーバ装置１０１が図３、図４および図５に示される通知処理を実行する。
【００３３】
まず、サーバ装置１０１内の制御部１０３は、ネットワークＩ／Ｆ１０４を通じて、クライアント装置１０６から送信されたドキュメントを入力する（ステップＳ１）。そして、入力されたドキュメントを解析する（ステップＳ２）。この段階で、このドキュメントがＸＭＬドキュメントであるか否かが判別され、ＸＭＬドキュメントである場合、ＸＭＬ規格に則って、タグ付データ、要素、属性等が解析される。
【００３４】
制御部１０３は、これらの解析済み情報の中に、通知先情報があるか否かを判別する（ステップＳ３）。図２に示すドキュメントでは、制御部１０３がｎｏｔｉｆｉｃａｔｉｏｎ要素の中にｍａｉｌｅｄ＿ｔｏ要素、もしくはｍａｉｌｅｄ＿ｔｏ＿ｗｉｔｈ＿ｄｏｃｕｍｅｎｔ要素を見つけると、通知先情報があったものと判断する。尚、通知先情報の形式は、上記要素に限定されるものではない。例えば、入力したデータがＧＩＦ画像ファイルであり、通知先の情報がアプリケーション拡張ブロック内に格納されている場合、それを解析し、通知先情報として取得してもよい。ステップＳ３で通知先情報が存在する場合、制御部１０３は、その通知先情報がｍａｉｌｅｄ＿ｔｏ要素であるか否かを判別する（ステップＳ４）。ｍａｉｌｅｄ＿ｔｏ要素である場合、その内容に記述されている通知先メールアドレスを、タイプｍａｉｌｅｄ＿ｔｏのテーブルに記憶する（ステップＳ５）。
【００３５】
図６は通知先アドレスが登録されたタイプｍａｉｌｅｄ＿ｔｏのテーブルである。このタイプｍａｉｌｅｄ＿ｔｏのテーブルは、記憶媒体１０２に記憶されるデータの一部である。例えば、図２の要素２０８のデータを解析した結果、ｓａｔｏ＠ａｂｃ．ｃｏｍという通知先メールアドレスが得られるので、そのメールアドレスがタイプｍａｉｌｅｄ＿ｔｏのテーブルに登録される。一方、ステップＳ４で通知先情報がｍａｉｌｅｄ＿ｔｏ要素でなかった場合、制御部１０３は、通知先情報がｍａｉｌｅｄ＿ｔｏ＿ｗｉｔｈ＿ｄｏｃｕｍｅｎｔ要素であるか否かを判別する（ステップＳ９）。
【００３６】
ｍａｉｌｅｄ＿ｔｏ＿ｗｉｔｈ＿ｄｏｃｕｍｅｎｔ要素である場合、その内容に記述されている通知先メールアドレスを、タイプｍａｉｌｅｄ＿ｔｏ＿ｗｉｔｈ＿ｄｏｃｕｍｅｎｔのテーブルに記憶する（ステップＳ１０）。図７はタイプｍａｉｌｅｄ＿ｔｏ＿ｗｉｔｈ＿ｄｏｃｕｍｅｎｔのテーブルである。このタイプｍａｉｌｅｄ＿ｔｏ＿ｗｉｔｈ＿ｄｏｃｕｍｅｎｔのテーブルは、記憶媒体１０２に記憶されるデータの一部である。テーブル構成は、タイプｍａｉｌｅｄ＿ｔｏのテーブルと同様である。
【００３７】
一方、ステップＳ９で通知先情報がｍａｉｌｅｄ＿ｔｏ＿ｗｉｔｈ＿ｄｏｃｕｍｅｎｔ要素でなかった場合、その要素を無視し、次の通知先情報を取得する（ステップＳ８）。この後、ステップＳ３の処理に戻る。そして、通知先情報がなくなるまで同様の処理を繰り返す。
【００３８】
そして、ステップＳ５およびステップＳ１０において、通知先アドレスを記憶した後、その要素に、ｄｏｃ＿ｒｅｆ属性があるか否かを判別する(ステップＳ６）。ｄｏｃ＿ｒｅｆ属性がある場合、要素のタイプに対応するテーブルにｄｏｃ＿ｒｅｆ属性値を記憶する（ステップＳ７）。要素のタイプとしては、前述したタイプｍａｉｌｅｄ＿ｔｏあるいはタイプｍａｉｌｅｄ＿ｔｏ＿ｗｉｔｈ＿ｄｏｃｕｍｅｎｔのいずれかである。例えば、図２の要素２１１の場合、ｄｏｃ＿ｒｅｆ属性値である”ｈｔｔｐ：／／ｗｗｗ．ｘｙｚ．ｃｏｍ／Ｘ３／ｍａｎｕａｌ．ｈｔｍｌ”を、図６のアドレスｔａｎａｋａ＠ａｂｃ．ｃｏｍに対応したｄｏｃ＿ｒｅｆ属性値欄に記憶する。
【００３９】
ここで、ｄｏｃ＿ｒｅｆ属性とは、このドキュメントリソースを識別するものあり、図２では、その属性値はＵＲＬ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）となっている。ドキュメントが登録あるいは更新された旨が通知先アドレスに対して通知される際、本属性がある場合、これも併せて通知される。これにより、通知された側は、どのドキュメントが更新されたのかを容易に知ることができる。
【００４０】
尚、本実施形態では、ｄｏｃ＿ｒｅｆ属性値として、ＵＲＬを使用しているが、これに限らず、より一般的にリソースを指すＵＲＩ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒ）を用いることも可能である。この場合、リソースの物理的な保存位置とは関係なく、リソースを一意に指すことが可能である。
【００４１】
ここで、ｄｏｃ＿ｒｅｆ属性値の決め方としては、クライアント装置１０６が決定する場合（ステップＳ１でドキュメントがサーバ装置１０１に入力された時点で、既に挿入されている場合）と、サーバ装置１０１が決定する場合（ステップＳ２で、サーバ装置１０１がドキュメントを解析している途中で決定して挿入する場合）の２通りの方法が考えられる。
【００４２】
前者の方法では、さらに、クライアント装置１０６において、サーバ装置１０１上の蓄積位置であるＵＲＬを決定して挿入する場合と、ドキュメントの識別子を意味するＵＲＩを決定して挿入する場合の２通りの方法が考えられる。一方、後者の方法では、ステップＳ２において、ステップＳ１４における蓄積位置を決定し、そのＵＲＬを挿入する方法が考えられる。いずれにせよ、ＵＲＩ規格はＵＲＬを含むので、以下の説明では、特に断らない限り、ＵＲＩを用いるものとする。
【００４３】
そして、ｄｏｃ＿ｒｅｆ属性値を記憶した後、あるいはステップＳ６でｄｏｃ＿ｒｅｆ属性値がない場合、次の通知先情報を取得する（ステップＳ８）。この後、ステップＳ３の処理に戻り、通知先情報がなくなるまで繰り返す。
【００４４】
このように、全ての通知先情報を処理し終わり、ステップＳ３で処理すべき通知先情報がなくなると、制御部１０３は、ドキュメントの更新前バージョンが記憶媒体１０２に既に存在するか否かを判別する（ステップＳ１１）。存在しない場合、今回の操作はドキュメントの登録であるとみなされ、後で送信するメッセージのメッセージ種別を”登録”に設定して記憶する（ステップＳ１３）。一方、ステップＳ１１でドキュメントの更新前バージョンが記憶媒体１０２に既に存在する場合、今回の操作はドキュメントの更新とみなされ、メッセージ種別を”更新”に設定して記憶する（ステップＳ１２）。メッセージ種別を記憶した後、制御部１０３は、ドキュメントを記憶媒体１０２の所定の位置に蓄積する（ステップＳ１４）。
【００４５】
そして、タイプｍａｉｌｅｄ＿ｔｏのテーブルの中に、通知先アドレスが記憶されているか否かを判別する（ステップＳ１５）。記憶されている場合、ｄｏｃ＿ｒｅｆ属性値が記憶されているか否かを判別する（ステップＳ１６）。これも記憶されている場合、処理中の通知先アドレスに対してｄｏｃ＿ｒｅｆ属性値であるＵＲＩ情報を付加し、メッセージ種別によって示されるメッセージを通知する（ステップＳ１８）。具体的に、ドキュメントのメッセージ種別が”登録”の場合、「ドキュメントが新たに登録されました。ＵＲＩは・・・です」のような本文を備えるメッセージを通知先のメールアドレスに送信する。この後、ステップＳ１５の処理に戻る。
【００４６】
一方、ステップＳ１６で、ｄｏｃ＿ｒｅｆ属性値が記憶されていない場合、単に通知先アドレスに対し、メッセージ種別によって示されるメッセージを通知する（ステップＳ１７）。この後、ステップＳ１５の処理に戻る。尚、ＵＲＩがなく、ドキュメントが新たに登録された旨を伝えるだけでは、何のドキュメントが登録されたのか分かりにくい。この場合、図２の要素２０２に示したドキュメントタイトルをメッセージに付加するようにしてもよい。また、ステップＳ１４で蓄積した際、記憶媒体１０２の蓄積位置を示すＵＲＬを決定し、それを付加するようにしてもよい。これにより、ｄｏｃ＿ｒｅｆ属性が存在しなくても、そのＵＲＬを用いて通知されたユーザは、ドキュメントにアクセスできる。このように通知した後、ステップＳ１５に戻り、次の通知先アドレスが記憶されているか否かを判別する。このループによって、全てのｍａｉｌｅｄ＿ｔｏ通知先アドレスを処理する。
【００４７】
そして、ステップＳ１５で、全てのｍａｉｌｅｄ＿ｔｏ通知先アドレスを処理し終わったか、あるいは始めからｍａｉｌｅｄ＿ｔｏ通知先アドレスが１つもない場合、タイプｍａｉｌｅｄ＿ｔｏ＿ｗｉｔｈｏｕｔ＿ｄｏｃｕｍｅｎｔのテーブルの中に、通知先アドレスが記憶されているか否かを判別する（ステップＳ１９）。記憶されている場合、さらに、ｄｏｃ＿ｒｅｆ属性値が記憶されているか否かを判別する（ステップＳ２０）。これも記憶されている場合、処理中の通知先アドレスに対して、ｄｏｃ＿ｒｅｆ属性値であるＵＲＩ情報を付加し、メッセージ種別によって示されるメッセージを通知すると共に、ステップＳ１４で蓄積されたドキュメントも送信する（ステップＳ２２）。具体的にはドキュメントは、メールの添付ファイルとして送られる。この後、ステップＳ１９の処理に戻る。一方、ステップＳ２０でｄｏｃ＿ｒｅｆ属性値が記憶されていない場合、単に通知先アドレスに対し、メッセージ種別によって示されるメッセージを通知すると共に、ステップＳ１４で蓄積されたドキュメントも送信する（ステップＳ２１）。この後、ステップＳ１９の処理に戻る。ｄｏｃ＿ｒｅｆ属性が無くても、タイトルやＵＲＬを付加してもよいことは、前述した場合と同様である。このように通知した後、ステップＳ１９に戻って、次の通知先アドレスが記憶されているか否かを判別する。このループによって、全てのｍａｉｌｅｄ＿ｔｏ＿ｗｉｔｈｏｕｔ＿ｄｏｃｕｍｅｎｔ通知先アドレスを処理する。
【００４８】
そして、全てのｍａｉｌｅｄ＿ｔｏ＿ｗｉｔｈｏｕｔ＿ｄｏｃｕｍｅｎｔ通知先アドレスを処理し終わったか、あるいは始めからｍａｉｌｅｄ＿ｔｏ＿ｗｉｔｈｏｕｔ＿ｄｏｃｕｍｅｎｔ通知先アドレスが１つもない場合、本処理を終了する。このように、タイプｍａｉｌｅｄ＿ｔｏ＿ｗｉｔｈｏｕｔ＿ｄｏｃｕｍｅｎｔを指定すると、ドキュメントそのものも通知先アドレスに送られるので、通知されたユーザは、即座にドキュメントを確認できる。
【００４９】
第１の実施形態によれば、サーバ装置は、ドキュメントに含まれる通知先情報を取得し、取得した通知先情報を基に、通知先にドキュメントが登録あるいは更新されたことを通知するので、ドキュメントを取り扱う際、その登録あるいは更新を通知する通知先の情報を一緒に取り扱うことができる。したがって、ドキュメントと通知先の情報をまとめて管理することができ、必要な時にドキュメントの閲覧・変更を途切れることなく行うことができる。
【００５０】
［第２の実施形態］
第２の実施形態では、クライアント装置１０６が通知を行う場合である。第２の実施形態のクライアントサーバシステムの構成は、前記第１の実施形態と同様であるので、その説明を省略する。
【００５１】
図８、図９および図１０は第２の実施形態におけるクライアント装置による通知処理手順を示すフローチャートである。この処理プログラムは、クライアント装置１０６内の記憶媒体１１２に格納されており、制御部１１３によって実行される。まず、ユーザによってクライアント装置１０６が操作され、ドキュメントをサーバ装置１０１に出力する操作が行われたことを入力する（ステップＳ４１）。
【００５２】
この操作が行われた場合、クライアント装置１０６内の制御部１０３は、出力しようとしているドキュメントを解析する（ステップＳ４２）。この段階で、このドキュメントがＸＭＬドキュメントであるか否かを判別し、ＸＭＬドキュメントである場合、ＸＭＬ規格に則ってタグ付データ、要素、属性等を解析する。尚、このステップＳ４２における解析処理は、必ずしもこのステップ位置である必要はない。ステップＳ４１の出力操作の前であってもよく、ドキュメントを編集している場合、そこで解析処理を済ませてもよい。
【００５３】
制御部１０３は、これらの解析済み情報の中に通知先情報があるか否かを判別する（ステップＳ４３）。図２に示すドキュメントでは、制御部１０３がｎｏｔｉｆｉｃａｔｉｏｎ要素の中に、ｍａｉｌｅｄ＿ｔｏ要素あるいはｍａｉｌｅｄ＿ｔｏ＿ｗｉｔｈ＿ｄｏｃｕｍｅｎｔ要素を見つけると、通知先情報があったものと判断する。
【００５４】
ステップＳ４３で通知先情報が存在する場合、制御部１０３は、その通知先情報がｍａｉｌｅｄ＿ｔｏ要素であるか否かを判別する（ステップＳ４４）。ｍａｉｌｅｄ＿ｔｏ要素である場合、その内容に記述されている通知先メールアドレスを、タイプｍａｉｌｅｄ＿ｔｏのテーブルに記憶する（ステップＳ４５）。タイプｍａｉｌｅｄ＿ｔｏのテーブルは、クライアント装置１０６の記憶媒体１１２に記憶されるデータの一部であり、その形式は前述した図６に示す通りである。
【００５５】
一方、ステップＳ４４で通知先情報がｍａｉｌｅｄ＿ｔｏ要素でなかった場合、制御部１０３は、通知先情報がｍａｉｌｅｄ＿ｔｏ＿ｗｉｔｈ＿ｄｏｃｕｍｅｎｔ要素であるか否かを判別する（ステップＳ４９）。ｍａｉｌｅｄ＿ｔｏ＿ｗｉｔｈ＿ｄｏｃｕｍｅｎｔ要素である場合、その内容に記述されている通知先メールアドレスを、タイプｍａｉｌｅｄ＿ｔｏ＿ｗｉｔｈ＿ｄｏｃｕｍｅｎｔのテーブルに記憶する（ステップＳ５０）。タイプｍａｉｌｅｄ＿ｔｏ＿ｗｉｔｈ＿ｄｏｃｕｍｅｎｔのテーブルは、記憶媒体１０２に記憶されるデータの一部であり、その形式は前述した図７に示す通りである。
【００５６】
一方、ステップＳ４９で通知先情報がｍａｉｌｅｄ＿ｔｏ＿ｗｉｔｈ＿ｄｏｃｕｍｅｎｔ要素でなかった場合、その要素を無視し、次の通知先情報を取得する（ステップＳ４８）。この後、ステップＳ４３の処理に戻り、通知先情報がなくなるまで繰り返す。
【００５７】
そして、ステップＳ４５およびステップＳ５０において通知先アドレスを記憶した後、その要素に、ｄｏｃ＿ｒｅｆ属性があるか否かを判別する(ステップＳ４６）。ｄｏｃ＿ｒｅｆ属性がある場合、要素のタイプに対応したテーブルにｄｏｃ＿ｒｅｆ属性値を記憶する（ステップＳ４７）。要素のタイプとしては、タイプｍａｉｌｅｄ＿ｔｏであるか、あるいはタイプｍａｉｌｅｄ＿ｔｏ＿ｗｉｔｈ＿ｄｏｃｕｍｅｎｔのいずれかである。この処理では、ｄｏｃ＿ｒｅｆ属性はクライアント装置１０６によって決定される。
【００５８】
そして、ｄｏｃ＿ｒｅｆ属性値を記憶した後、あるいはステップＳ４６でｄｏｃ＿ｒｅｆ属性値がない場合、次の通知先情報を取得する（ステップＳ４８）。この後、ステップＳ４３に戻り、通知先情報がなくなるまで同様の処理を繰り返す。こうして全ての通知先情報を処理し終わり、ステップＳ４３で処理すべき通知先情報がなくなると、クライアント装置１０６内の制御部１０３は、サーバ装置１０１と交信を行い、ドキュメントの更新前バージョンがサーバ装置１０１に既に存在するか否かを調べる（ステップＳ５１）。この処理は所定のプロトコルに則って行われる。
【００５９】
ドキュメントの更新前バージョンがサーバ装置１０１に存在しない場合、今回の操作はドキュメントの登録とみなされ、後で送信するメッセージのメッセージ種別を”登録”として記憶する（ステップＳ５３）。一方、ドキュメントの更新前のバージョンがサーバ装置１０１に存在する場合、今回の操作はドキュメントの更新とみなされ、メッセージ種別を”更新”として記憶する（ステップＳ５２）。ステップＳ５２、Ｓ５３でメッセージ種別を記憶した後、クライアント装置１０６内の制御部１０３は、ドキュメントをサーバ装置１０１に出力する（ステップＳ５４）。
【００６０】
そして、タイプｍａｉｌｅｄ＿ｔｏのテーブルの中に、通知先アドレスが記憶されているか否かを判別する（ステップＳ５５）。記憶されている場合、さらにｄｏｃ＿ｒｅｆ属性値が記憶されているか否かを判別する（ステップＳ５６）。これも記憶されている場合、処理中の通知先アドレスに対し、ｄｏｃ＿ｒｅｆ属性値であるＵＲＩ情報を付加し、メッセージ種別によって示されるメッセージを通知する（ステップＳ５８）。この後、ステップＳ５５の処理に戻る。
【００６１】
一方、ステップＳ５６でｄｏｃ＿ｒｅｆ属性値が記憶されていない場合、単に通知先アドレスに対し、メッセージ種別によって示されるメッセージを通知する（ステップＳ５７）。尚、ＵＲＩがなく、ドキュメントが新たに登録された旨を伝えるだけでは、何のドキュメントが登録されたのか分かりにくい。このような場合、図２の要素２０２に示されたドキュメントタイトルをメッセージに付加してもよい。また、ステップＳ５４でドキュメントをサーバ装置１０１に出力した際、出力先としてＵＲＬが指定された場合、それを付加してもよい。これにより、ｄｏｃ＿ｒｅｆ属性が存在しなくても、そのＵＲＬを用いることで、通知されたユーザは、ドキュメントにアクセスできる。
【００６２】
こうして通知された後、ステップＳ５５に戻り、次の通知先アドレスが記憶されているか否か判別する。このループによって、全てのｍａｉｌｅｄ＿ｔｏ通知先アドレスを処理する。全てのｍａｉｌｅｄ＿ｔｏ通知先アドレスを処理し終わったか、あるいは始めからｍａｉｌｅｄ＿ｔｏ通知先アドレスが１つもない場合、タイプｍａｉｌｅｄ＿ｔｏ＿ｗｉｔｈｏｕｔ＿ｄｏｃｕｍｅｎｔのテーブルの中に、通知先アドレスが記憶されているか否かを判別する（ステップＳ５９）。通知先アドレスが記憶されている場合、ｄｏｃ＿ｒｅｆ属性値が記憶されているか否かを判別する（ステップＳ６０）。これも記憶されている場合、処理中の通知先アドレスに対してｄｏｃ＿ｒｅｆ属性値であるＵＲＩ情報を付加し、メッセージ種別によって示されるメッセージを通知すると共に、ステップＳ５４で出力したドキュメントも送信する（ステップＳ６２）。この後、ステップＳ５９の処理に戻る。具体的に、ドキュメントはメールの添付ファイルとして送られる。
【００６３】
一方、ステップＳ６０でｄｏｃ＿ｒｅｆ属性値が記憶されていない場合、単に通知先アドレスに対し、メッセージ種別によって示されるメッセージを通知すると共に、ステップＳ５４で出力したドキュメントも送信する（ステップＳ６１）。尚、ｄｏｃ＿ｒｅｆ属性が無い場合、タイトルやＵＲＬを付加してもよいことは、前述した場合と同様である。
【００６４】
こうして通知が行われた後、ステップＳ５９に戻り、次の通知先アドレスが記憶されているか否かを判別する。このループによって、全てのｍａｉｌｅｄ＿ｔｏ＿ｗｉｔｈｏｕｔ＿ｄｏｃｕｍｅｎｔ通知先アドレスを処理する。そして、全てのｍａｉｌｅｄ＿ｔｏ＿ｗｉｔｈｏｕｔ＿ｄｏｃｕｍｅｎｔ通知先アドレスを処理し終わったか、あるいは始めからｍａｉｌｅｄ＿ｔｏ＿ｗｉｔｈｏｕｔ＿ｄｏｃｕｍｅｎｔ通知先アドレスが１つもない場合、本処理を終了する。
【００６５】
このように、第２の実施形態によれば、クライアント装置は、ドキュメントに含まれる通知先情報を取得し、取得した通知先情報を基に、通知先にドキュメントが登録あるいは更新されたことを通知するので、ドキュメントを取り扱う際、その登録あるいは更新を通知する通知先の情報を一緒に取り扱うことができる。
【００６６】
［第３の実施形態］
第３の実施形態では、サーバ装置１０１がドキュメントの一部分の更新を認識し、その認識された更新部分が予め指定されている場合、通知先に通知が行われる。図１１、図１２、図１３、図１４および図１５は第３の実施形態におけるサーバ装置１０１による通知処理手順を示すフローチャートである。この処理プログラムは、サーバ装置１０１内の記憶媒体１０２に格納されており、制御部１０３によって実行される。
【００６７】
まず、サーバ装置１０１内の制御部１０３は、ネットワークＩ／Ｆ１０４を通じて、クライアント装置１０６からのドキュメントを入力する（ステップＳ７１）。そして、入力したドキュメントを解析する（ステップＳ７２）。この段階で、このドキュメントがＸＭＬドキュメントであるか否かが判別され、ＸＭＬドキュメントであると判別された場合、ＸＭＬ規格に則ってタグ付データ、要素、属性等が解析される。
【００６８】
制御部１０３は、これらの解析済み情報の中に、通知先情報があるか否かを判別する（ステップＳ７３）。図２に示すドキュメントでは、制御部１０３がｎｏｔｉｆｉｃａｔｉｏｎ要素の中に、ｍａｉｌｅｄ＿ｔｏ要素あるいはｍａｉｌｅｄ＿ｔｏ＿ｗｉｔｈ＿ｄｏｃｕｍｅｎｔ要素を見つけると、通知先情報があったものと判断する。通知先情報があった場合、そのアドレスを記憶媒体１０２のテーブルに記憶する（ステップＳ７４）。図１６は通知先情報を示すテーブルである。このテーブルには、各通知先アドレスのエントリ毎に、タイプ、ｄｏｃ＿ｒｅｆ属性値、複数個のｉｆ＿ｕｐｄａｔｅｄ属性値を記憶する領域が設けられている。タイプとしては、タイプｍａｉｌｅｄ＿ｔｏであるか、あるいはタイプｍａｉｌｅｄ＿ｔｏ＿ｗｉｔｈｏｕｔ＿ｄｏｃｕｍｅｎｔのいずれかである。つまり、このテーブルは、前述した第１の実施形態における図６、図７のテーブルを結合した形式をとっている。尚、本実施形態において、図１６の形式をとることは必須ではない。前述した図６および図７の形式をとってもよい。また、前記第１もしくは第２の実施形態において、図１６の形式をとることも可能である。
【００６９】
ステップＳ７４の処理後、通知先情報の要素が示すタイプ（ｍａｉｌｅｄ＿ｔｏあるいはｍａｉｌｅｄ＿ｔｏ＿ｗｉｔｈｏｕｔ＿ｄｏｃｕｍｅｎｔのどちらか）をテーブルに記憶する（ステップＳ７５）。さらに、制御部１０３は、通知先情報の要素の中に、ｄｏｃ＿ｒｅｆ属性があるか否かを調べる（ステップＳ７６）。ｄｏｃ＿ｒｅｆ属性がある場合、そのｄｏｃ＿ｒｅｆ属性値を記憶する（ステップＳ７７）。一方、ｄｏｃ＿ｒｅｆ属性がない場合、ステップＳ７７の処理をスキップし、ステップＳ７８の処理に進む。
【００７０】
そして、制御部１０３は、通知先情報の要素の中に、ｉｆ＿ｕｐｄａｔｅｄ属性があるか否かを調べる（ステップＳ７８）。ここで、ｉｆ＿ｕｐｄａｔｅｄ属性は、ドキュメント内の部分を示す。その部分が更新された場合、通知先アドレスに通知することを要求する。本実施形態では、ｉｆ＿ｕｐｄａｔｅｄ属性は、ＸＭＬの関連規格の１つであるＸＰｏｉｎｔｅｒあるいはＸＬｉｎｋを用いて表現される。図２の要素２１２および要素２１３では、ＸＰｏｉｎｔｅｒが用いられている。要素２１４では、ＸＬｉｎｋが用いられている。
【００７１】
尚、要素２１２のｉｆ＿ｕｐｄａｔｅｄ属性値である”＃ｉｎｔｒｏｄｕｃｔｉｏｎ”は、ｉｄ属性が”ｉｎｔｒｏｄｕｃｔｉｏｎ”である要素、すなわち要素２０３を指し示している。つまり、要素２０３のｃｈａｐｔｅｒ要素の内部が変更された場合、通知先アドレスに通知することを要求している。
【００７２】
要素２１３のｉｆ＿ｕｐｄａｔｅｄ属性値である”＃ｘｐｏｉｎｔｅｒ（／ｄｏｃ／ｃｈａｐｔｅｒ［２］／ｒａｎｇｅ−ｔｏ（／ｄｏｃ／ｃｈａｐｔｅｒ［３］））”は、ｃｈａｐｔｅｒ要素の２番目から３番目、すなわち要素２０４および要素２０５を指し示している。
【００７３】
要素２１４のｉｆ＿ｕｐｄａｔｅｄ属性値である”ｒｅｓｏｕｒｃｅ”は、更新部分を指す際にＸＬｉｎｋが用いられることを示す。同一タグ内にあるＸＬｉｎｋ指定がそれであり、ここでは相対ＵＲＩを用いて、”ｉｍｇ／ｓａｍｐｌｅ１．ｊｐｇ”が指定されている。要素２０６を見ると、同じＵＲＩが指定されている。つまり、サーバ装置１０１は、要素２０６で指定されているＵＲＩの更新をチェックすることになる。ＸＬｉｎｋを用いることで、１つのファイル内の更新だけでなく、リンクされたリソースの更新もチェックできる。尚、図２の例には存在しないが、ｉｆ＿ｕｐｄａｔｅｄ属性を、１つの要素の中で複数個指定することも可能である。この場合、１つの通知先に対して、複数個のドキュメント部分（あるいはリソース部分）が対応付けられることになる。しかし、要素２１４を考えると、このままの書式では、属性値”ｒｅｓｏｕｒｃｅ”のｉｆ＿ｕｐｄａｔｅｄ属性を１つの要素の中で複数個指定することは不可能である。どのｉｆ＿ｕｐｄａｔｅｄ属性がどのＸＬｉｎｋで指定されるＵＲＩに対応しているのか分からなくなるからである。そこで、複数個の属性値”ｒｅｓｏｕｒｃｅ”のｉｆ＿ｕｐｄａｔｅｄ属性を、１つの通知先アドレスに対して指定したい場合、同一の通知先アドレスに対し、複数個のｍａｉｌｅｄ＿ｔｏあるいはｍａｉｌｅｄ＿ｔｏ＿ｗｉｔｈ＿ｄｏｃｕｍｅｎｔ要素を指定すればよい。
【００７４】
ステップＳ７８で、ｉｆ＿ｕｐｄａｔｅｄ属性が存在した場合、その要素に存在する全てのｉｆ＿ｕｐｄａｔｅｄ属性値を記憶する（ステップＳ７９）。その中の１つのｉｆ＿ｕｐｄａｔｅｄ属性値が”ｒｅｓｏｕｒｃｅ”であるか否かを判別し（ステップＳ８０）、”ｒｅｓｏｕｒｃｅ”であった場合、同一要素内のｘｌｉｎｋ：ｈｒｅｆ属性値であるＵＲＩを記憶する（ステップＳ８１）。一方、ステップＳ８０で”ｒｅｓｏｕｒｃｅ”でなかった場合、ステップＳ８１の処理をスキップし、ステップＳ８２の処理に進む。また一方、ステップＳ７８でｉｆ＿ｕｐｄａｔｅｄ属性が１つも存在しない場合、ステップＳ７９〜Ｓ８１の処理をスキップし、ステップＳ８２の処理に進む。
【００７５】
こうして、１つの通知先情報の要素に関する処理が終了すると、ドキュメントから次の通知先情報の要素を取得する（ステップＳ８２）。この後、ステップＳ７３の処理に戻り、その要素について処理する。このループで全ての要素が処理される。
【００７６】
そして、ステップＳ７３で全ての要素の処理が終了した場合、制御部１０３は、ドキュメントの更新前のバージョンがサーバ装置１０１の記憶媒体１０２に存在するか否かを判別する（ステップＳ８３）。存在しない場合、今回の操作はドキュメントの登録とみなされ、後で送信するメッセージのメッセージ種別を”登録”として記憶する（ステップＳ８５）。存在する場合、今回の操作はドキュメントの更新とみなされ、メッセージ種別を”更新”として記憶する（ステップＳ８４）。
【００７７】
制御部１０３は、図１６のテーブルに通知先アドレスが記憶されているか否かを判別する（ステップＳ８６）。１つでも通知先アドレスが記憶されている場合、少なくとも１つのｉｆ＿ｕｐｄａｔｅｄ属性値が記憶されており、かつメッセージ種別が”更新”であるか否かを判別する（ステップＳ８７）。ＹＥＳである場合、フラグを”送信しない”に初期化する（ステップＳ８８）。
【００７８】
そして、１つずつｉｆ＿ｕｐｄａｔｅｄ属性値を処理していくが、最初のｉｆ＿ｕｐｄａｔｅｄ属性値をテーブルから取得し、ｉｆ＿ｕｐｄａｔｅｄ属性値がまだ残っているかを否かを判別する（ステップＳ８９）。最初のｉｆ＿ｕｐｄａｔｅｄ属性を処理する場合、当然、Ｙｅｓの方向に進む。このｉｆ＿ｕｐｄａｔｅｄ属性値が”ｒｅｓｏｕｒｃｅ”であるか否かを判別する（ステップＳ９１）。”ｒｅｓｏｕｒｃｅ”でない場合、ドキュメントの更新部分を既に取得したか否かを調べる（ステップＳ９２）。まだ取得していない場合、ドキュメントを更新前のバージョンと比較し、更新部分を認識して取得する（ステップＳ９４）。例えば、ＸＭＬドキュメントの場合、各ドキュメント要素毎に比較を行い、どの要素が更新されたかを記憶しておく。一方、ステップＳ９２で既に取得した場合、ドキュメントを比較する必要がないので、ステップＳ９４の処理をスキップし、ステップＳ９６の処理に進む。
【００７９】
一方、ステップＳ９１でｉｆ＿ｕｐｄａｔｅｄ属性値が”ｒｅｓｏｕｒｃｅ”である場合、ＸＬｉｎｋで示されたＵＲＩが指すリソースの更新部分を既に取得したか否かを調べる（ステップＳ９３）。まだ取得していない場合、そのリソースを更新前のバージョンと比較し、更新部分を認識して取得する（ステップＳ９５）。一方、ステップＳ９３で既に取得した場合、リソースを比較する必要がないので、ステップＳ９５の処理をスキップし、ステップＳ９６の処理に進む。
【００８０】
リソースの比較に関し、図２の要素２１４を例にとって示す。この場合、ＵＲＩは”ｉｍｇ／ｓａｍｐｌｅ１．ｊｐｇ”である。サーバ装置１０１内の制御部１０３は、必要に応じて、このＵＲＩが指すリソースを所定のプロトコルを用いてクライアント装置１０６から取得する。そして、それを記憶媒体１０２に記憶されている”ｉｍｇ／ｓａｍｐｌｅ１．ｊｐｇ”と比較する。ここでは、ＪＰＥＧ画像を例に挙げているので、更新した部分を求めるというのは意味があまりないかも知れないが、少なくとも更新したか否かは判別可能である。また、リソースとして、他のＸＭＬドキュメントを指すことも可能であり、その場合、ステップＳ９４と同様、更新部分を取得できる。
【００８１】
そして、このように更新部分を取得した後、取得した更新部分にｉｆ＿ｕｐｄａｔｅｄ属性値によって示される部分が含まれているか否かを判別する（ステップＳ９６）。含まれている場合、ｉｆ＿ｕｐｄａｔｅｄ属性値によって示される部分が更新されていることを、後で送信するメッセージに付加する（ステップＳ９７）。例えば、図１６の通知先アドレス”ｓａｓａｋｉ＠ｈｉｊｋ．ｃｏｍ”を処理している場合、要素２０３で示されるｃｈａｐｔｅｒが更新されていると、「ｃｈａｐｔｅｒ  ”ｉｎｔｒｏｄｕｃｔｉｏｎ”が更新されています」というメッセージが付加される。この後、フラグを”送信する”に変更する（ステップＳ９８）。このように、ｉｆ＿ｕｐｄａｔｅｄ属性が１つでも更新部分と重なった場合、フラグを”送信する”に変更する。
【００８２】
このような手順により、１つのｉｆ＿ｕｐｄａｔｅｄ属性についての処理が終了すると、次のｉｆ＿ｕｐｄａｔｅｄ属性値を取得し（ステップＳ９９）、ステップＳ８９に戻り、同様の処理を行う。このループで、全てのｉｆ＿ｕｐｄａｔｅｄ属性について処理が行われる。全てのｉｆ＿ｕｐｄａｔｅｄ属性についての処理が終了すると、制御部１０３は、最終的なフラグが”送信する”になっているか否かを判別する（ステップＳ９０）。フラグが”送信する”になっていない場合、ｉｆ＿ｕｐｄａｔｅｄ属性が１つも更新部分と重なっていないということで、通知メールは送信されず、次の通知先アドレスをテーブルから取得する（ステップＳ１０６）。この後、ステップＳ８６に戻り、同様の処理を行う。一方、フラグが”送信する”になっている場合、ステップＳ１００以降の通知メールを送信する段階に移行する。尚、ステップＳ８７で通知先アドレスに対してｉｆ＿ｕｐｄａｔｅｄ属性が記憶されていないか、あるいはメッセージ種別が”登録”である場合、必ずメールを送信するので、ステップＳ１００以降の通知メールを送信する段階に移行する。
【００８３】
制御部１０３は、まず図１６のテーブルを参照し、通知先アドレスに対し、ｄｏｃ＿ｒｅｆ属性値が記憶されているか否かを調べる（ステップＳ１００）。ｄｏｃ＿ｒｅｆ属性値が記憶されている場合、そのＵＲＩ情報をメッセージに付加する（ステップＳ１０１）。一方、ｄｏｃ＿ｒｅｆ属性値が記憶されていない場合、このステップＳ１０１の処理をスキップし、ステップＳ１０２の処理に進む。さらに、制御部１０３は、通知先アドレスのタイプが”ｍａｉｌｅｄ＿ｔｏ＿ｗｉｔｈ＿ｄｏｃｕｍｅｎｔ”であるか否かを調べる（ステップＳ１０２）。通知先アドレスのタイプが”ｍａｉｌｅｄ＿ｔｏ＿ｗｉｔｈ＿ｄｏｃｕｍｅｎｔ”である場合、ドキュメントの内容をメッセージに付加する（ステップＳ１０３）。一方、ステップＳ１０２で通知先アドレスのタイプが”ｍａｉｌｅｄ＿ｔｏ”である場合、ドキュメント内容はメッセージに付加されない。
【００８４】
最後に、制御部１０３は、メッセージ種別に従って、更新または登録した旨をメッセージに追加し（ステップＳ１０４）、出来上がったメッセージを通知先アドレスに送信する（ステップＳ１０５）。こうして、１つの通知先アドレスに対する処理が終了すると、次の通知先アドレスをテーブルから取得し（ステップＳ１０６）、ステップＳ８６に戻り、同様の処理を行う。このループによって、全ての通知先アドレスが処理される。全ての通知先アドレスの処理が終了すると、サーバ装置１０１内の制御部１０３は、ドキュメントを記憶媒体１０２の所定の位置に蓄積する（ステップＳ１０７）。さらに、リンクされたドキュメントがある場合、それも記憶媒体１０２の所定の位置に蓄積する（ステップＳ１０８）。この後、本処理を終了する。
【００８５】
尚、第３の実施形態では、サーバ装置１０１の処理手順を示したが、前記第２の実施形態と同様、これと同様の処理をクライアント装置１０６において実行することも可能である。
【００８６】
また、第１および第３の実施形態では、サーバ装置１０１がドキュメントを入力した時点でドキュメントを解析していたが、ドキュメントの解析時期はこれに限定されない。例えば、サーバ装置内の制御部が、タイマによってインターバルを計測し、図３におけるステップＳ２以降のステップ処理、あるいは図１１におけるステップＳ７２以降のステップ処理を実行するようにしてもよく、ドキュメントの入力時以外にも、ドキュメントの登録あるいは更新を認識できる。
【００８７】
この場合、ドキュメントの登録を認識する際、サーバ装置１０１内の制御部１０３は、ドキュメントがどこに登録されるかを知っていればよい。制御部１０３がその場所を定期的にチェックすることで、新たなドキュメントの登録を認識できる。一方、ドキュメントの更新をチェックする際、前回チェック時のドキュメントを記憶媒体１０２に別名で保存しておけばよい。そして、定期チェック時、本物のドキュメントと別名で保存したドキュメントを比較する。また、更新部分の認識が不要である場合、単に前回チェック時のドキュメントの更新日時を記憶しておくことでもよい。そして、定期チェック時、ドキュメントの更新日時と記憶しておいた更新日時を比較する。
【００８８】
これにより、ドキュメント入力ステップとドキュメント比較ステップが分離されるので、それぞれのステップを別アプリケーションで実行可能となる。例えば、ＮＦＳ（Ｎｅｔｗｏｒｋ  Ｆｉｌｅ  Ｓｙｓｔｅｍ）プロトコルを用いて、クライアント装置１０６からサーバ装置１０１上のドキュメントファイルを更新する。この場合、サーバ装置１０１が実行する定期的なチェックにより、更新部分の認識は可能である。これにより、クライアント装置１０１は、特別なアプリケーションを立ち上げることなく、ドキュメントを単にエディットするだけで、更新が通知先に通知される。そして、通知先の部分については再入力の必要がない。
【００８９】
また、上記各実施形態では、サーバ装置とクライアント装置の間でドキュメントの入出力および蓄積を行ったが、本発明はこれに限定されるものではなく、例えば、図１のサーバ装置１０１、クライアント装置１０６、携帯電話１０８、ＰＣ１０９、ＰＤＡ１１０等、様々な機器あるいはこれらの組み合わせで実現可能である。
【００９０】
尚、本発明は、上記実施形態の構成に限られるものではなく、特許請求の範囲で示した機能、または本実施形態の構成が持つ機能が達成できる構成であればどのようなものであっても適用可能である。
【００９１】
例えば、本発明は、ハードウエアを必要とするものの、各装置で動作するプログラムによって実現可能である。したがって、前述した実施形態の機能を実現するソフトウエアのプログラム、およびプログラムコードを記憶した記憶媒体においても、それを読み出して実行することにより、上記機能を実現することが可能である。
【００９２】
すなわち、本発明の目的は、上記実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）が記憶媒体に格納されたプログラムコードを読み出して実行することによっても達成される。
【００９３】
この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。
【００９４】
プログラムコードを供給するための記憶媒体としては、例えば、ＲＯＭ、フロッピー（登録商標）ディスク、ＰＣＭＣＩＡカードやコンパクトフラッシュ（登録商標）等のメモリカード、ハードディスク、マイクロＤＡＴ、光磁気ディスク、ＣＤ−ＲやＣＤ−ＲＷ等の光ディスク、ＤＶＤ等の相変化型光ディスク等で構成されてもよい。また、プログラムコードをネットワークを介してダウンロードしてもよい。
【００９５】
また、コンピュータが読み出したプログラムコードを実行することにより、上記実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることはいうまでもない。
【００９６】
更に、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれる。
【図面の簡単な説明】
【００９７】
【図１】第１の実施形態におけるクライアントサーバシステムの構成を示す図である。
【図２】ＸＭＬドキュメントを示す図である。
【図３】クライアント装置１０６からサーバ装置１０１にドキュメントが送られた場合、サーバ装置１０１による通知処理手順を示すフローチャートである。
【図４】図３につづくクライアント装置１０６からサーバ装置１０１にドキュメントが送られた場合、サーバ装置１０１による通知処理手順を示すフローチャートである。
【図５】図３および図４につづくクライアント装置１０６からサーバ装置１０１にドキュメントが送られた場合、サーバ装置１０１による通知処理手順を示すフローチャートである。
【図６】通知先アドレスが登録されたタイプｍａｉｌｅｄ＿ｔｏのテーブルである。
【図７】タイプｍａｉｌｅｄ＿ｔｏ＿ｗｉｔｈ＿ｄｏｃｕｍｅｎｔのテーブルである。
【図８】第２の実施形態におけるクライアント装置による通知処理手順を示すフローチャートである。
【図９】図８につづく第２の実施形態におけるクライアント装置による通知処理手順を示すフローチャートである。
【図１０】図８および図９につづく第２の実施形態におけるクライアント装置による通知処理手順を示すフローチャートである。
【図１１】第３の実施形態におけるサーバ装置１０１による通知処理手順を示すフローチャートである。
【図１２】図１１につづく第３の実施形態におけるサーバ装置１０１による通知処理手順を示すフローチャートである。
【図１３】図１１および図１２につづく第３の実施形態におけるサーバ装置１０１による通知処理手順を示すフローチャートである。
【図１４】図１１、図１２および図１３につづく第３の実施形態におけるサーバ装置１０１による通知処理手順を示すフローチャートである。
【図１５】図１１、図１２、図１３および図１４につづく第３の実施形態におけるサーバ装置１０１による通知処理手順を示すフローチャートである。
【図１６】通知先情報を示すテーブルである。
【符号の説明】
【００９８】
１０１  サーバ装置
１０２、１１２  記憶媒体
１０３、１１３  制御部
１０６  クライアント装置
【図１】
2005346671.tif 000003
【図２】
2005346671.tif 000004
【図３】
2005346671.tif 000005
【図４】
2005346671.tif 000006
【図５】
2005346671.tif 000007
【図６】
2005346671.tif 000008
【図７】
2005346671.tif 000009
【図８】
2005346671.tif 000010
【図９】
2005346671.tif 000011
【図１０】
2005346671.tif 000012
【図１１】
2005346671.tif 000013
【図１２】
2005346671.tif 000014
【図１３】
2005346671.tif 000015
【図１４】
2005346671.tif 000016
【図１５】
2005346671.tif 000017
【図１６】
2005346671.tif 000018