(57)【要約】【課題】  処理装置の状態の変化を通知するための電子メールを受信した受信装置においてユーザが該変化を容易に確認することができるよう、電子メールを送信する。【解決手段】  所定のステータス項目に対応する第１の電子メールを送信した後、同一のステータス項目に対応する第２の電子メールを送信する場合、第１の電子メールに関する所定の情報とともに第２の電子メールを送信する。【選択図】  図９
2018073106.tif 000002
【特許請求の範囲】
【請求項１】
電子メールを送信する処理装置であって、
複数のステータス項目のいずれかについて前記処理装置の状態が変化した場合に、前記変化を通知するための電子メールを送信する送信手段と、
前記送信手段による送信対象の電子メールに関する所定の情報を取得する取得手段と、
を有し、
前記送信手段は、
前記複数のステータス項目のうちの第１のステータス項目に対応する第１の電子メールを送信した後、前記第１のステータス項目に対応する第２の電子メールを、前記取得手段により取得された前記第１の電子メールに関する所定の情報とともに送信し、
前記第１の電子メールを送信した後に前記第１のステータス項目とは異なる第２のステータス項目に対応する第３の電子メールを送信する場合、前記第１の電子メールの前記所定の情報を送信せずに、前記第３の電子メールを送信し、
前記送信手段により送信された電子メールを受信する受信装置は、
前記送信手段により前記第２の電子メールが前記第１の電子メールの前記所定の情報とともに送信された場合、前記所定の情報に基づき、前記第１の電子メールと前記第２の電子メールを関連付けて表示することを特徴とする処理装置。
【請求項２】
前記送信手段は、
前記第１の電子メールに関する所定の情報を含む前記第２の電子メールを送信し、
前記受信装置において、前記第２の電子メールに含まれている前記所定の情報に基づき、前記第１の電子メールと前記第２の電子メールが関連付けられて表示されることを特徴とする請求項１に記載の処理装置。
【請求項３】
前記送信手段は、
前記第１のステータス項目に関する前記処理装置の状態が前記第１のステータス項目に対応する複数の状態のうちの所定の状態になったことに応じて前記第１の電子メールを送信した場合、前記第１の電子メールの送信の後に前記第１のステータス項目について前記処理装置の状態が変化したとしても、前記第１の電子メールの前記所定の情報を送信せずに、前記変化を通知する前記第２の電子メールを送信することを特徴とする請求項１または２に記載の処理装置。
【請求項４】
前記所定の状態は、前記処理装置において、前記第１のステータス項目に関する変化の完了として設定されている状態であることを特徴とする請求項３に記載の処理装置。
【請求項５】
前記送信手段は、前記所定の情報を前記第１の電子メールに設定して、前記所定の情報が設定された前記第１の電子メールを送信し、
前記取得手段は、前記第１の電子メールに設定された前記所定の情報を取得することを特徴とする請求項１乃至４のいずれか１項に記載の処理装置。
【請求項６】
前記所定の情報は電子メールを特定するための特定情報であり、
前記送信手段は、前記第１の電子メールに設定された、前記第１の電子メールの特定情報を、前記第２の電子メールの所定のヘッダに設定し、前記特定情報が設定された前記第２の電子メールを送信し、
前記受信装置は、前記第２の電子メールの前記所定のヘッダに前記特定情報が設定されている場合、前記第１の電子メールと前記第２の電子メールを関連付けて表示することを特徴とする請求項５に記載の処理装置。
【請求項７】
前記所定のヘッダは、Ｉｎ−Ｒｅｐｌｙ−Ｔｏヘッダであることを特徴とする請求項６に記載の処理装置。
【請求項８】
前記所定のヘッダは、Ｒｅｆｅｒｅｎｃｅｓヘッダであることを特徴とする請求項６に記載の処理装置。
【請求項９】
前記送信手段は、前記第１のステータス項目に関するエラーの発生に応じて、前記エラーを通知するための前記第１の電子メールを送信した後、前記エラーの解除に応じて、前記解除を通知するための前記第２の電子メールを、前記第１の電子メールに関する前記所定の情報とともに送信することを特徴とする請求項１乃至８のいずれか１項に記載の処理装置。
【請求項１０】
前記第１のステータス項目は、前記処理装置による前記所定の処理の進捗に関する項目であり、
前記第１のステータス項目に関する状態の変化は、前記所定の処理の開始と、前記所定の処理の終了の少なくも一方を含むことを特徴とする請求項１乃至９のいずれか１項に記載の処理装置。
【請求項１１】
前記送信手段は、
前記第２のステータス項目に対応する前記第３の電子メールを送信した後、前記第２のステータス項目に対応する第４の電子メールを送信する場合にも、前記取得手段により取得された前記第３の電子メールに関する前記所定の情報とともに前記第４の電子メールを送信することを特徴とする請求項１乃至１０のいずれか１項に記載の処理装置。
【請求項１２】
画像を印刷媒体に印刷する印刷手段を有することを特徴とする請求項１乃至１１のいずれか１項に記載の処理装置。
【請求項１３】
前記複数のステータス項目は、前記印刷手段による印刷に用いられる記録材に関する項目と、前記印刷手段による印刷に用いられる印刷媒体に関する項目の少なくとも一方を含むことを特徴とする請求項１２に記載の処理装置。
【請求項１４】
前記所定の処理は、文書を管理する処理であることを特徴とする請求項１乃至１１のいずれか１項に記載の処理装置。
【請求項１５】
電子メールを送信する処理装置の状態の変化を通知する通知方法であって、
複数のステータス項目のいずれかについて前記処理装置の状態が変化した場合に、前記変化を通知するための電子メールを送信する送信工程と、
前記送信工程における送信対象の電子メールに関する所定の情報を取得する取得工程と、
を有し、
前記送信工程では、
前記複数のステータス項目のうちの第１のステータス項目に対応する第１の電子メールを送信した後、前記第１のステータス項目に対応する第２の電子メールを、前記取得工程において取得された前記第１の電子メールに関する所定の情報とともに送信し、
前記第１の電子メールを送信した後に前記第１のステータス項目とは異なる第２のステータス項目に対応する第３の電子メールを送信する場合、前記第１の電子メールの前記所定の情報を送信せずに、前記第３の電子メールを送信し、
前記送信手段により送信された電子メールを受信する受信装置は、
前記送信工程において前記第２の電子メールが前記第１の電子メールの前記所定の情報とともに送信された場合、前記所定の情報に基づき、前記第１の電子メールと前記第２の電子メールを関連付けて表示することを特徴とする通知方法。
【請求項１６】
電子メールを送信する処理装置と、前記処理装置から送信された電子メールを受信する受信装置とを含み、前記処理装置の変化を通知する処理システムであって、
前記処理装置は、
複数のステータス項目のいずれかについて前記処理装置の状態が変化した場合に、前記変化を通知するための電子メールを送信する送信手段と、
前記送信手段による送信対象の電子メールに関する所定の情報を取得する取得手段と、
を有し、
前記受信装置は、
前記送信手段により送信された電子メールを受信する受信手段と、
前記受信手段により受信された複数の電子メールに関する表示を行う表示手段と、
を有し、
前記送信手段は、
前記複数のステータス項目のうちの第１のステータス項目に対応する第１の電子メールを送信した後、前記第１のステータス項目に対応する第２の電子メールを、前記取得手段により取得された前記第１の電子メールに関する所定の情報とともに送信し、
前記第１の電子メールを送信した後に前記第１のステータス項目とは異なる第２のステータス項目に対応する第３の電子メールを送信する場合、前記第１の電子メールの前記所定の情報を送信せずに、前記第３の電子メールを送信し、
前記表示手段は、
前記第２の電子メールが前記第１の電子メールの前記所定の情報とともに前記受信手段により受信された場合、前記所定の情報に基づき、前記第１の電子メールと前記第２の電子メールを関連付けて表示することを特徴とする処理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、状態の変化に関する電子メールを送信する処理装置、通知方法、および処理システムに関するものである。
【背景技術】
【０００２】
近年電子メールの普及により、通知や連絡の手段として電子メールが日常的に利用されるようになっている。電子メールの送受信は据え置きのコンピュータ装置だけでなく、携帯電話やスマートホンなどの携帯情報端末でも閲覧することができ、外出先や遠隔地でも確認することができる利便性がある。この利便性を利用して、各種の処理装置にエラーが発生したときや、処理装置に対するユーザの処理要求が完了したときなどに、遠隔地にいるユーザに対して電子メールで通知する技術がある。
【０００３】
特許文献１では、ネットワークファクシミリ装置において発生したエラーについて電子メールが作成される場合に、その電子メールのヘッダ情報のＳｕｂｊｅｃｔフィールドにエラーコードがセットされることが記載されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０００−０１３５５０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、特許文献１の記載のように電子メールのヘッダ情報のＳｕｂｊｅｃｔフィールドにエラーコードがセットされたとしても、複数の事象が並行して発生した場合などに、受信メールの表示において事象の関連性を認識し難い場合がある。
【０００６】
例えば処理装置においてエラーが発生したとき、またそのエラーが解除されたときのそれぞれにおいて電子メールにより通知が行われるとする。このとき、例えば処理装置に複数のエラーが発生してそれぞれに対応する電子メールが送信され、そのうちのいくつかのエラーが解除され、エラー解除それぞれを通知するための電子メールが送信されたとする。このとき、電子メールを受信した装置において例えば受信メールの一覧が表示されたとしても、上記複数のエラーのうち、どのエラーが解除されずに残っているのかをユーザが容易に把握することができないことがある。
【０００７】
以上の課題を鑑みて本発明は、処理装置の状態の変化を通知するための電子メールを受信した受信装置においてユーザが該変化を容易に確認することができるよう、電子メールを送信することができる処理装置、処理方法、処理システムを提供する。
【課題を解決するための手段】
【０００８】
上記問題点を解決するために、本発明の処理装置は、電子メールを送信する処理装置であって、複数のステータス項目のいずれかについて前記処理装置の状態が変化した場合に、前記変化を通知するための電子メールを送信する送信手段と、前記送信手段による送信対象の電子メールに関する所定の情報を取得する取得手段と、を有し、前記送信手段は、前記複数のステータス項目のうちの第１のステータス項目に対応する第１の電子メールを送信した後、前記第１のステータス項目に対応する第２の電子メールを、前記取得手段により取得された前記第１の電子メールに関する所定の情報とともに送信し、前記第１の電子メールを送信した後に前記第１のステータス項目とは異なる第２のステータス項目に対応する第３の電子メールを送信する場合、前記第１の電子メールの前記所定の情報を送信せずに、前記第３の電子メールを送信し、前記送信手段により送信された電子メールを受信する受信装置は、前記送信手段により前記第２の電子メールが前記第１の電子メールの前記所定の情報とともに送信された場合、前記所定の情報に基づき、前記第１の電子メールと前記第２の電子メールとを関連付けて表示することを特徴とする。
【発明の効果】
【０００９】
本発明によれば、処理装置の状態の変化を通知するための電子メールを受信した受信装置においてユーザが該変化を容易に確認することができるよう、電子メールを送信することができる。
【図面の簡単な説明】
【００１０】
【図１】一実施形態である画像処理システム１００の構成を示す図である。
【図２】ＭＦＰ２００の構成を示すブロック図である。
【図３】メール設定画面３０１の内容を示す図である。
【図４】状態変化通知メール管理領域４００の内容を示す図である。
【図５】状態変化事象管理表５０１の内容を示す図である。
【図６】ＭＦＰ２００のＣＰＵ２０１の処理内容を示すフローチャートである。
【図７】ＭＦＰ２００から送信される状態変化通知メールのメールヘッダの内容を示す図である。
【図８】電子メール閲覧ソフトのメール一覧画面６００の受信順表示の場合の表示内容を示す図である。
【図９】電子メール閲覧ソフトのメール一覧画面６００のスレッド表示の場合の表示内容を示す図である。
【図１０】第２の実施形態としての文書管理システム７００の構成を示す図である。
【図１１】文書管理サーバ７０１の構成を示すブロック図である。
【図１２】文書管理サーバで取り扱う文書のライフサイクルにおけるワークフロー状態遷移を表す図である。
【図１３】各文書に対して記憶される文書管理領域９００の内容を示す図である。
【図１４】文書管理サーバ８００の処理内容を示すフローチャートである。
【図１５】文書管理サーバ７０１から送信される状態変化通知メールのメールヘッダの内容を示す図である。
【図１６】電子メール閲覧ソフトのメール一覧画面６００の受信順表示の場合の表示内容を示す図である。
【図１７】電子メール閲覧ソフトのメール一覧画面６００のスレッド表示の場合の表示内容を示す図である。
【発明を実施するための形態】
【００１１】
以下、本発明の実施の形態について詳細に説明する。なお、この実施の形態に記載されている構成要素は、本発明の例としての形態を示すものであり、この発明の範囲をそれらのみに限定するものではない。
【００１２】
［実施形態１］
図１は、実施形態１における画像処理システム１００の構成を示す図である。ローカル端末装置１０１とマルチファンクションプリンタ（以下、ＭＦＰ）２００はＬＡＮ１０２により相互に接続されている。またＬＡＮ１０２はルーター１０３により外部のインターネット１０４に接続されており、ローカル端末装置１０１およびＭＦＰ２００はインターネット１０４上のメールサーバ１０５とも通信可能である。リモート端末装置１０６はＭＦＰ２００と直接通信することはできないが、インターネット１０４を通してメールサーバ１０５と通信可能である。
【００１３】
ＭＦＰ２００は、自身の状態の変化に関する電子メールを作成し、所定のメールアドレスを指定してメールサーバ１０５に送信する処理装置として動作する。そして、ローカル端末装置１０１とリモート端末装置１０６はそれぞれ、メールサーバ１０５経由でＭＦＰ２００からの電子メールを受信して表示する受信装置として動作することができる。
【００１４】
なお、この構成は本実施形態の一例を示すものであって、異なる構成を取るものであっても本実施形態の効果は変わらない。例えばメールサーバ１０５はインターネット１０４上にあるものとして記載しているが、ＬＡＮ１０２内に別のメールサーバを設置してそこから外部のメールサーバ１０５へ転送するように構成してもよい。
【００１５】
また、ローカル端末装置１０１またはリモート端末装置１０６がメール閲覧ソフト等のアプリケーションにより電子メールを受信してもよいし、Ｗｅｂブラウザにより、インターネット上のサーバが提供するＷｅｂメールサービスを利用してもよい。Ｗｅｂメールサービスの場合、メールの送受信はサーバが行い、ローカル端末装置１０１またはリモート端末装置１０６は、Ｗｅｂブラウザにより該サーバにアクセスすることで、Ｗｅｂページとしてメールを表示することができる。
【００１６】
図２は、ＭＦＰ２００の構成を示すブロック図である。マイクロプロセッサ形態のＣＰＵ２０１は、内部バス２０２を介して接続されているＲＯＭ形態のプログラムメモリ２０３に格納されている制御プログラムと、ＲＡＭ形態のデータメモリ２０４の内容とに従って動作する。ＣＰＵ２０１はスキャナ部２０５を制御して原稿を読み取り、データメモリ２０４中の画像メモリ２０６に格納する。印刷部２０７は、インクやトナー等の記録材を用いて、用紙等の印刷媒体に画像を印刷する。ＣＰＵ２０１は印刷部２０７を制御することで、データメモリ２０４中の画像メモリ２０６の画像を印刷部２０７に印刷媒体へ印刷させることができる。
【００１７】
このように、ＣＰＵ２０１は、印刷部２０７やスキャナ部２０５を制御して各種の動作を行わせるとともに、印刷部２０７やスキャナ部２０５に設けられた不図示のセンサや制御回路を制御することにより、各種のエラーや動作状態を監視することができる。また、ＣＰＵ２０１は操作部制御回路２０８を制御することによって操作パネル２０９に印刷装置の状態の表示や機能選択メニューの表示を行い、またユーザからの操作を受け付けることが可能である。
【００１８】
操作パネル２０９はタッチパネルで構成されており、ユーザは、表示されているオブジェクトをタッチすることでオブジェクトに対する操作を行うことができる。また、ＣＰＵ２０１はネットワーク制御回路２１０を通じてＬＡＮ１０２で接続される他の装置と通信を行うことができる。これにより、他の装置からの印刷ジョブを受信して印刷部２０７により印刷を実行し、またスキャナ部２０５で読み取った画像を他の装置に送信することも可能である。
【００１９】
また、ＣＰＵ２０１はｈｔｔｐサーバモジュール２１１を制御し、ＬＡＮ１０２経由で接続された不図示のローカル端末装置１０１上で動作するＷｅｂブラウザからのｈｔｔｐプロトコルによる要求に対し、ｈｔｍｌ文書を生成して応答したりすることができる。これにより、ＣＰＵ２０１は、操作パネル２０９と同様に、各種の設定や状態表示を行う画面をローカル端末装置上で動作するＷｅｂブラウザ上に表示させ、またユーザがその画面上で操作した内容を受けて、装置の設定や動作を変更することが可能である。このように、ローカル端末装置上で動作するＷｅｂブラウザに画面を表示して操作を受け付ける構成を、以後本明細書においてはリモートＵＩと称する。
【００２０】
不揮発メモリ２１２はバッテリバックアップＲＡＭやＥＥＰＲＯＭ、フラッシュメモリなど、装置の電源が供給されなくなってもしても内容を覚えているメモリである。ＭＦＰ２００に対する設定情報など、電源を切っても覚えておく必要がある情報はこの不揮発メモリ２１２に書き込んでおく。
【００２１】
図３は、ＭＦＰ２００が表示するメール設定画面３０１の内容を示す図である。メール設定画面３０１は、ＭＦＰ２００の状態の変化を通知するためのメールの送信に関する設定を行うための画面であり、ＭＦＰ２００本体の操作パネル２０９に表示される。メール設定画面３０１は、メール送信に関する設定項目を含み、ユーザからの設定操作を受け付ける。なお、ローカル端末装置１０１やリモート端末装置１０６は、Ｗｅｂブラウザによりｈｔｔｐサーバモジュール２１１にアクセスすることで、メール設定画面３０１をリモートＵＩとして表示させ、該装置においてユーザの操作を受け付けることも可能である。
【００２２】
メール設定画面３０１の上部には、通知先メールアドレス入力フィールド３０２が配置されている。操作パネル２０９において、通知先メールアドレス入力フィールド３０２がタッチされることにより、不図示のソフトウェアキーボードが表示されてユーザはメールアドレスを入力することができる。
【００２３】
通知先メールアドレス入力フィールド３０２の下には、状態変化通知メールの送信条件等をユーザが設定するためのオブジェクトが配置されている。通知要因分類３０３は、状態変化通知メールの通知要因として大まかに分類された各要因を示し、ユーザはこの要因毎に状態変化通知メールの各種設定を行うことができる。ユーザはチェックボックス３０４にチェックを入れるか否かを切り替えることで、要因毎に、状態変化通知メールを送信するか否かを選択することができる。具体的には、チェックボックス３０４をユーザがタッチすることにより、状態変化通知メールを送信するか否かで設定が切り替わる。またプルダウンボタン３０５は、要因毎に、状態変化通知メールの重要度を設定することができる。このプルダウンボタン３０５をタッチすることにより、不図示のプルダウンメニューが表示され、１から５の数字で状態変化通知メールの重要度を設定することができる。設定ボタン３０６は、この画面で入力、設定された内容を確定し、ＭＦＰ２００に記憶させるためのボタンである。キャンセルボタン３０７はこの画面で入力、設定された内容を破棄し、もとの状態に戻すためのボタンである。このように図３が示すメール設定画面３０１に対してユーザが設定した内容が、ＭＦＰ２００のＣＰＵ２０１により、不揮発メモリ２１２における状態変化通知メール管理領域４００において管理される。
【００２４】
図４は、ＭＦＰ２００の状態変化通知メール管理領域４００の内容を示す図である。この管理領域の内容は不揮発メモリ２１２に記憶されている。通知先メールアドレス４０１は文字列型の変数で、ＭＦＰ２００の工場出荷時のデフォルト値はＮＵＬＬすなわち空文字列である。
【００２５】
ＭＦＰ２００の状態変化通知メール管理領域４００では、通知要因分類３０３が示す要因毎に、状態変化通知メール設定が記憶されている。通知要因分類（以下、ステータス項目ともいう）として、インク関係エラー４０２、用紙関係エラー４０３、ジョブ実行状況４０４、その他のエラー４０５が含まれる。
【００２６】
通知要因分類のそれぞれに対して設定される状態変化通知メール設定は以下の通りである。通知設定４０６は、通知要因分類（ステータス項目）に状態変化があった場合に状態変化通知メールを送信するか否かを表し、ＴＲＵＥ（送信する）またはＦＡＬＳＥ（送信しない）の２値を表すＢｏｏｌｅａｎ型の変数であり、デフォルト値はＴＲＵＥである。通知設定４０６には、チェックボックス３０４における設定が反映される。重要度設定４０７は、通知要因分類（ステータス項目）について状態変化があった場合に送信される状態変化通知メールの重要度を表し、１から５までの値を取る整数型変数であり、デフォルト値は中心値である３である。重要度設定４０７の内容には、プルダウンボタン３０５における設定が反映される。
【００２７】
最終送信メッセージＩＤ４０８は、通知要因分類（ステータス項目）に状態変化があった場合に送信する状態変化通知メールのうち、最後に送信した状態変化通知メールに付したメッセージＩＤを記憶する領域である。これは文字列型の変数であり、デフォルト値はＮＵＬＬすなわち空文字である。なお、メッセージＩＤは、電子メールを一意に特定するための特定情報である。
【００２８】
以上の状態変化通知メール管理領域４００に含まれている情報に基づいて、ＭＦＰ２００は、ＭＦＰ２００の状態に変化があった場合に状態変化通知メール送信処理を行う。具体的には、通知要因分類（ステータス項目）に状態変化があった場合に、ＣＰＵ２０１は、最終送信メッセージＩＤ４０８として記憶されているＩＤに基づいて、状態変化通知メールを送信する。これにより、該メールを受信した装置において上記のＩＤによりメールを関連付けて表示することができる。そのため、例えばインク関係エラーが発生し、該エラーが解除された場合、エラー発生に対応するメールがＩＤとともに送信され、エラー解除に対応するメールが該ＩＤとともに送信される。そして、該２通のメールを表示する装置においては、２通のメールが関連づけて表示される。そのため、例えば複数の通知要因分類についてエラーが発生して複数のメールが送信され、その後、その複数の通知要因分類の一部についてエラーが解除され、さらに複数のメールが送信されたとする。この場合でも、同一の通知要因分類については、エラー発生、エラー解除の２通のメールが関連づけて表示されるため、種々のメールが表示されたとしても、ユーザは各通知要因分類の状態について容易に確認することができる。このメール送信、メール表示についての詳細は後述する。
【００２９】
なお、ここでは通知先メールアドレスが１か所の場合を説明しているが、図４の管理領域を必要数分だけの要素を持つ配列として持つことで、複数の通知先を登録して通知先ごとに異なる設定で状態変化通知メールを送信することが可能になる。
【００３０】
また、上記のように通知要因分類３０３および図４の４０２から４０５が示すエラー内容は、ＭＦＰ２００において発生し得るエラーが大まかに分類されたものである。そのため、ＣＰＵ２０１は、ＭＦＰ２００においてエラーが発生した場合、図５に示す情報を参照することで、該エラーが含まれる通知要因分類を特定する。そしてＭＦＰ２００は、図４に示した状態変化通知メール管理領域４００において、その特定された通知要因分類に対応する設定を参照することで、該エラーについて電子メールを送るか否か、また電子メールを送る際の重要度等を判定する。
【００３１】
図５は、ＭＦＰ２００で発生する代表的な状態変化の事象と、状態変化通知メールの通知要因分類の関係を示す状態変化事象管理表５０１を示す図である。この表は、プログラムメモリ２０３中に静的なテーブルデータとして保持されており、ＣＰＵ２０１から処理中に参照が可能である。表中「○」または「◎」は、通知要因分類に含まれる事象であり、該当する通知要因分類に対する通知設定４０６がＴＲＵＥにセットされている場合、状態変化通知メール送信の対象となる事象であることを示す。このうち、◎が付いているものは、通知要因分類の一連の事象の完了となる事象であることを示す。
【００３２】
例えば、ジョブ進行状況には、印刷ジョブの進捗として、「印刷ジョブの開始」、「印刷ジョブの進行」、「印刷ジョブ正常終了」、「印刷ジョブエラー終了」が含まれる。そして「印刷ジョブ正常終了」、「印刷ジョブエラー終了」が、印刷処理という一連の事象の完了であると定義されている。なお、「印刷ジョブの進行」は、任意の進捗状況でよい。例えば印刷開始後、インクなしエラー、用紙なしエラー等のエラーが発生せずに、印刷を開始できた場合に、印刷処理の進捗が「印刷ジョブの進行」の段階に到達したと判定されてもよい。
【００３３】
本実施形態でＭＦＰ２００は、図５の状態変化事象管理表５０１において○となっている事象について電子メールを送信した後に、該事象の完了となる事象（図５の状態変化事象管理表５０１において◎となっている事象）について電子メールを送信する。この際に、電子メールを受信した装置において上記２つの電子メールが一連の事象であることをユーザに示す表示ができるように、該事象の完了となる事象についての電子メールのヘッダに所定の情報を書き込む。この処理について、図６のフローチャートを用いて詳細に説明する。
【００３４】
図６は、ＭＦＰ２００のＣＰＵ２０１の処理内容を示すフローチャートである。図６に示すフローチャートにおける処理を実行するためのプログラムがプログラムメモリ２０３に格納されている。そして、図５で示した状態変化の事象がＭＦＰ２００の装置内部で発生した場合に、ＣＰＵ２０１が該プログラムを、データメモリ２０４をワークメモリとして実行することによって、図６に示す各処理が実現される。
【００３５】
ＣＰＵ２０１はＳ２００１において、図５で示した状態変化事象管理表５０１を参照することで、発生した状態変化事象が属する通知要因分類を取得する。次にＳ２００２においてＣＰＵ２０１は、状態変化通知メール管理領域４００を参照し、発生事象が属する通知要因分類の通知設定がＴＲＵＥとなっているかどうかを確認する。即ち、Ｓ２００２では、Ｓ２００１において取得された通知要因分類が状態変化通知メールの送信対象であるか判定される。
【００３６】
なお、本図では表記していないが、一つの発生事象が複数の通知要因分類に属することも想定される。例えば図５における正常待機状態（アイドル状態）などがそれに当たる。このような場合、Ｓ２００２では、発生事象が属するいずれか一つ以上の通知要因分類の通知設定がＴＲＵＥである場合に、該発生事象についてメールを送信すると判断される（Ｓ２００２においてＹｅｓと判断される）。Ｓ２００２において、通知設定がＴＵＲＥでない場合は、当該エラーについては電子メールの送信対象外であるため、以下の処理は行わず、図６に示す処理を終了する。一方、Ｓ２００２において、通知設定がＴＲＵＥであった場合には、Ｓ２００３へ処理が進む。
【００３７】
Ｓ２００３においてＣＰＵ２０１は、当該エラーの発生に対して送信される状態変化通知メールのメッセージＩＤを生成する。メッセージＩＤは、当該送信される状態変化通知メールを特定するための特定情報であり、他の電子メールメッセージと重複しないよう、電子メールメッセージを一意に特定するものである。このためＣＰＵ２０１は、メールサーバのドメイン名と、メールサーバ上のユーザ名に日時情報、プロセスＩＤ、生成番号などの情報を組み合わせることにより生成する。これら電子メールメッセージを一意に特定するメッセージＩＤの生成方法については、種々の方法を用いることができる。
【００３８】
次にＣＰＵ２０１はＳ２００４において、電子メール情報を作成する。ここでは、発生した状態変化事象に応じてあらかじめ規定の件名、本文を持つ電子メールメッセージを生成し、状態変化通知メール管理領域４００に格納されている通知先メールアドレス４０１を、電子メールヘッダの「ｔｏ：」ヘッダに設定する。またＣＰＵ２０１は、Ｓ２００３において生成された送信メッセージＩＤを電子メールヘッダに含ませる。なお、上記の規定の件名には、ＭＦＰ２００の一意の名称（或いは機種名）を示すデバイス名と、発生した状態変化事象を示すテキストが含まれる。また、ＣＰＵ２０１は、Ｓ２００１で取得された通知要因分類に対応する重要度設定４０７を、状態変化通知メール管理領域４００を参照することで確認する。そして、ＣＰＵ２０１は、確認された重要度設定４０７を、電子メール情報の所定の領域に書き込む。このように書き込まれた重要度設定４０７は、電子メールを受信した装置において当該電子メールに関する表示が行われるときに、当該電子メールの重要度としての表示に反映される。
【００３９】
Ｓ２００５でＣＰＵ２０１は、発生した状態変化事象が属する通知要因分類（Ｓ２００１で取得された通知要因分類）の最終送信メッセージＩＤ４０８を状態変化通知メール管理領域４００から取得し、その内容をチェックする。最終送信メッセージＩＤ４０８がＮＵＬＬでない場合は、Ｓ２００６へ進み、電子メールヘッダに「Ｉｎ−Ｒｅｐｌｙ−Ｔｏ：」ヘッダを追加し、そこに最終送信メッセージＩＤ４０８を追加する。
【００４０】
電子メールのヘッダ内の「Ｉｎ−Ｒｅｐｌｙ−Ｔｏ：」ヘッダに送信メッセージＩＤがある場合、該電子メールを表示するメール閲覧ソフトは、該電子メールを同一の送信メッセージＩＤをヘッダに含む電子メールの返信メールとして表示することができる。そのため、ＣＰＵ２０１はＳ２００６による処理により、Ｓ２００４において作成された電子メールを、最終送信メッセージＩＤ４０８を送信メッセージＩＤとしてヘッダに含む他の電子メールの返信メールとして表示させることができる。例えばメール閲覧ソフトは、メールスレッド表示により、受信された電子メールと該電子メールの返信メールを関連付けて表示することができる。メールスレッド表示については詳細を後述する。
【００４１】
また、メール閲覧ソフトによってはＩｎ−Ｒｅｐｌｙ−ＴｏヘッダでなくＲｅｆｅｒｅｎｃｅｓヘッダを参照してメールスレッド管理を行うものもあるため、Ｓ２００６では「Ｒｅｆｅｒｅｎｃｅｓ：」ヘッダも同様に追加する。
【００４２】
Ｓ２００５で最終送信メッセージＩＤ４０８がＮＵＬＬであった場合は、Ｓ２００６の処理は行われずに処理がＳ２００７へ進み、「Ｉｎ−Ｒｅｐｌｙ−Ｔｏ：」ヘッダ、「Ｒｅｆｅｒｅｎｃｅｓ：」ヘッダの追加は行われない。
【００４３】
Ｓ２００７でＣＰＵ２０１は、Ｓ２００４で作成した電子メール（Ｓ２００６の処理が実行された場合にはメールヘッダが追記された電子メール）の送信処理を行う。
【００４４】
次にＳ２００８においてＣＰＵ２０１は、状態変化事象管理表５０１を参照し、発生した状態変化事象が通知要因分類における完了事象であるかどうか判定する。その状態変化事象が完了事象でない場合は、処理がＳ２００９に進む。ＣＰＵ２０１はＳ２００９において、Ｓ２００３で生成した送信メッセージＩＤを、Ｓ２００１で取得された通知要因分類の最終送信メッセージＩＤ４０８として、状態変化通知メール管理領域４００に格納する。これは、次に同じ通知要因分類に属する状態変化事象が発生した場合に、Ｓ２００５でＣＰＵ２０１が最終送信メッセージＩＤ４０８を参照し、またＳ２００６で最終送信メッセージＩＤ４０８を電子メールヘッダに追記するためである。
【００４５】
一方、Ｓ２００８において完了事象であると判定された場合には、Ｓ２０１０においてＣＰＵ２０１は、状態変化通知メール管理領域４００の、Ｓ２００１で取得された通知要因分類の最終送信メッセージＩＤ４０８にＮＵＬＬを格納する。これにより、次に同じ通知要因分類について状態変化事象が発生した場合、Ｓ２００６の処理が行われない。即ち、返信メールとして送信するための処理が行われないので、新たな事象の状態変化通知メールが送信されることになる。
【００４６】
図６に示したＳ２００７における処理により、完了事象でない状態変化（図５において「○」に相当する事象）があった場合に、ＣＰＵ２０１は、該事象の状態変化通知メールを送信する。またそれとともに、ＣＰＵ２０１は、Ｓ２００９において、最終送信メッセージＩＤ４０８をＮＵＬＬから該メールの送信メッセージＩＤに更新する。そして、その後、同じ通知要因分類について完了事象についてのメールが送信されるまで、該通知要因分類についての状態変化通知メールは、先に送信したメールの返信メールとして送信される。
【００４７】
例えばＭＦＰ２００において、印刷によりインク残量が少なくなっていき、インク関係エラーとして、「インク残量少警告」が発生し、「インクなしエラー」が発生し、その後、インクタンクが交換されて「インクエラー／警告解除」が発生したとする。すると、図５に示した状態変化事象管理表５０１と、図６に示した処理により、「インク残量少警告」を通知するメールＡが送信される。そして、メールＡの返信メールとして「インクなしエラー」を通知するメールＢが送信され、さらにメールＢの返信メールとして「インクエラー／警告解除」を通知するメールＣが送信される。
【００４８】
図７は、ＭＦＰ２００から送信される状態変化通知メールのメールヘッダの内容を示す図である。ここではインクなしエラーの通知メール（例えば上記のメールＢ）のメールヘッダの例を表している。「Ｍｅｓｓａｇｅ−Ｉｄ：」ヘッダには本通知メールのメッセージＩＤとして「２０１５０４０９１３５７４８．Ｎ０００２．ｑｑｑｑ＠ｘｘｘ．ｙｙｙｙ．ｃｏ．ｊｐ」が設定されている。また、「Ｉｎ−Ｒｅｐｌｙ−Ｔｏ：」ヘッダおよび「Ｒｅｆｅｒｅｎｃｅｓ：」ヘッダには「２０１５０４０６１３５５０３．Ｎ０００１．ｑｑｑｑ＠ｘｘｘ．ｙｙｙｙ．ｃｏ．ｊｐ」が設定されている。これはそれより以前に送られている、「インク残量少警告発生」の通知メール（例えば上記のメールＡ）のメッセージＩＤを示している。
【００４９】
次に、ＭＦＰ２００から受信されたメールを表示する処理について説明する。
【００５０】
図８は、ローカル端末装置１０１またはリモート端末装置１０６の電子メール閲覧ソフトによるメール一覧画面６００を示す図である。図８のメール一覧画面６００では、受信順にメールが一覧表示される。
【００５１】
図８では特に、図６におけるＳ２００５、Ｓ２００６、Ｓ２００８〜Ｓ２０１０における処理が行われず、ＭＦＰで発生した複数の事象それぞれについて、送信メッセージの関連付けを行わずに複数のメールがＭＦＰ２００から送信された場合の例を示す。
【００５２】
メール一覧画面６００には、重要度欄６０１、件名欄６０２、送信者欄６０３、送信日時欄６０４の各項目が含まれており、受信された各メールに対して各項目の情報が一覧表示されている。メールの本文についてはメール一覧画面６００では表示されておらず、ユーザがメール一覧画面６００でメールを選択することによって別画面で本文を参照することができる。なお、重要度欄６０１に表示される重要度は、図６のＳ２００４において電子メール情報に書き込まれた重要度設定４０７に基づいて表示される。
【００５３】
図８におけるメール一覧画面６００は、Ｉｎ−Ｒｅｐｌｙ−ＴｏヘッダやＲｅｆｅｒｅｎｃｅヘッダによりメールメッセージ間の関連付けは行われずに、受信したメールを受信時間に基づいて受信順に表示している。図８に示すように、ユーザは各状態変化通知メールが何を表しているかは認識できるが、最終的に現時点でＭＦＰ２００がどのような状態にあるか、ユーザが認識し難い場合がある。特に図８における６１０のメール以降は、「Ｐｒｉｎｔｅｒ  Ｄｅｖｉｃｅ  １」と「Ｐｒｉｎｖｅｒ  Ｄｅｖｉｃｅ  ２」の、２台のＭＦＰ２００から、それぞれの状態変化通知メールが混在して送られてきている。このため、それぞれのＭＦＰ２００で発生した状態変化事象が、その後どう推移しているのか、ユーザが認識できない場合がある。
【００５４】
図９は、メール一覧画面６００の別の例を示す図である。なお、図９に示す画面もローカル端末装置１０１またはリモート端末装置１０６の電子メール閲覧ソフトにより表示される。
【００５５】
図９に示す画面は、ＭＦＰ２００により図６に示した処理が実行され、且つ電子メール閲覧ソフトによりスレッド表示が行われた場合のメール一覧画面である。スレッド表示とは、受信したメールのＩｎ−Ｒｅｐｌｙ−ＴｏヘッダまたはＲｅｆｅｒｅｎｃｅｓヘッダの内容に基づいて、あるメールの返信メールを、元となるメール下に階層的に表示する表示方法である。図６に示した処理により、同一のＭＦＰにおいて同一の通知要因分類として複数の事象が連続して発生した場合、前回発生した事象についての元メールの返信メールとして新規のメールが送信される。そのため、上記の複数の事象についての複数のメールが、発生順序に従って下位階層のメールとなるように表示される。
【００５６】
具体的には、図９に示すように、同一のＭＦＰにおいて同一の通知要因分類として発生した事象についてのメールが階層的に表示される。図９に示したメール一覧画面では、各ＭＦＰで発生した状態変化事象がどのように推移し且つ現在どのような状態になっているかについて、図８に示したメール一覧画面に比べてユーザが認識し易いように表示されていることがわかる。例えば、図９における６１１の状態変化通知メールにおいて、Ｐｒｉｎｔｅｒ  Ｄｅｖｉｃｅ  １の印刷ジョブの開始が通知されているが、その印刷ジョブがまだ完了していないということが認識し易いことが分かる。
【００５７】
なお、電子メール閲覧ソフトによるメールの表示方法はスレッド表示に限らず、他の表示方法が用いられてもよい。電子メール閲覧ソフトが、対応するＩＤ（メール特定情報）を含む複数のメールについて関連付けて表示することが可能な表示方法により、図６に示した処理により送信された複数のメールを表示することで、図９で示した表示と同様の効果を得ることができる。
【００５８】
以上のように本実施形態により、状態変化通知メールを受信した電子メールソフトが、メール一覧画面として、状態変化の事象の推移や、事象間の関連性をユーザが分かりやすいように表示を行うことができる。
【００５９】
なお、上記のように、メールの受信は、端末装置内の電子メールソフトに限らず、Ｗｅｂメールサービスを提供するインターネット上のサーバが行ってもよい。そして、該サーバが図９に示したＷｅｂページを作成し、端末装置がＷｅｂブラウザにより該Ｗｅｂページを表示することでも、同様の効果を得ることができる。
【００６０】
［実施形態２］
実施形態１においては、デバイスにおけるステータスの変化を通知するためのメールを例に、本実施形態におけるメール送信処理を説明した。実施形態２においては、文書を管理する文書管理システムにおける業務ワークフローの各工程について通知するためのメールを例に、メール送信処理について説明する。
【００６１】
図１０は、実施形態２における文書管理システム７００の構成を示す図である。文書管理サーバ８００と端末装置７０１、７０２はＬＡＮなどのネットワーク７０３を介して接続されている。ユーザは端末装置７０１、７０２からＷｅｂブラウザを使って文書管理サーバにアクセスし、文書管理サーバ上に文書を作成、編集、削除を行うことができる。また、業務ワークフローに基づいて、作成した文書の承認依頼、却下、リリース、廃版などの処理（以下、ワークフロー処理と称する）の依頼を行うことができる。ネットワーク７０３にはメールサーバ７０４が接続されている。これにより端末装置７０１、７０２の間で相互に電子メールの送受信を行うほか、文書管理サーバ８００から配信される電子メールを端末装置７０１、７０２で受信することも可能である。なお、この構成は実施形態の一例を示すものであって、異なる構成を取るものであっても本実施形態の効果は変わらない。例えばメールサーバ７０４はネットワーク７０３内にあるものとして記載しているが、ルーター等を通して外部のインターネット上のメールサーバを利用するように構成してもよい。
【００６２】
図１１は、文書管理サーバ８００の構成を示すブロック図である。マイクロプロセッサ形態のＣＰＵ８０１は、内部バス８０２を介して接続されているＲＯＭ８０３、ＲＡＭ８０４に格納されている制御プログラムおよびデータの内容に従って動作する。また、ＣＰＵ８０１はネットワーク制御部８０５を通じてネットワーク７０３で接続される他の装置と通信を行うことができる。ｈｔｔｐサーバ部８０６は、文書管理サーバ８００をｈｔｔｐサーバとして動作させるためのソフトウェアモジュールである。また、Ｗｅｂアプリケーション部８０７は、ｈｔｔｐサーバ部８０６を通じて文書管理サーバ８００を外部から操作するユーザインタフェースを提供するためのソフトウェアモジュールである。端末装置７０１、７０２上で動作するＷｅｂブラウザが文書管理サーバ８００にアクセスするとＷｅｂアプリケーション部８０７が提供するユーザインタフェースがｈｔｔｐサーバ部８０６から端末装置７０１、７０２に送られる。これによって端末装置７０１、７０２から文書管理サーバ８００上の文書に対して各種の操作を行うことができる。文書データベースストレージ８０８は、ユーザが作成した文書や、その文書に対するワークフロー管理情報を保存するためのデータベース保存領域である。
【００６３】
図１２は、文書管理サーバにおける文書管理の状態遷移を表す図である。図１２はＵＭＬの状態遷移図によって記載されており、角の丸い長方形が状態（工程）を示し、状態間を結ぶ矢印は状態遷移を示している。矢印に付記している文言では、状態遷移のきっかけとなるイベント名称と、その後ろに「／」に続けて状態遷移時に実行されるアクションを示している。
【００６４】
文書は、ユーザが端末装置７０１または７０２からＷｅｂアプリケーション部８０７を通じて文書作成を指示したときに発生する文書作成イベントＥ４００１により生成される。これにより、文書管理サーバにおいて文書管理の状態が編集中状態Ｓ３００１となる。編集中状態Ｓ３００１で審査依頼イベントＥ４００２が発生すると、文書管理サーバにおいて文書管理の状態が審査中状態Ｓ３００２となり、あらかじめ定められている審査担当者に審査依頼メールが送信される。このとき、作成者自身にも同じメールがカーボンコピー（以下、ｃｃと表記する）として送信される。審査中状態Ｓ３００２で必要な審査処理が終了すると承認依頼イベントＥ４００３が発生し、文書管理サーバにおいて文書管理の状態が承認中状態Ｓ３００３へ移行する。そして承認担当者あてに承認依頼メールが送信される。このとき、審査担当者にも同じメールがｃｃとして送信される。一方、審査中状態Ｓ３００２で審査担当者が却下の操作を行った場合には却下イベントＥ４００４が発生し、文書管理サーバにおいて文書管理の状態が編集中状態Ｓ３００１に戻る。それとともに、文書作成者に対して却下通知メールが送信される。このとき、審査担当者にも同じメールがｃｃとして送信される。
【００６５】
承認中状態Ｓ３００３では承認者による承認が行われると承認イベントＥ４００５が発生し、文書管理サーバにおいて文書管理の状態がリリース済状態Ｓ３００４に移行する。このとき文書作成者、審査担当者、承認担当者およびあらかじめ定められている関係者宛に、リリース通知メールが送信される。一方、承認中状態Ｓ３００３で承認担当者が却下の操作を行った場合には却下イベントＥ４００６が発生し、文書管理サーバにおいて文書管理の状態が審査中状態Ｓ３００２に戻るとともに、審査担当者に対して却下通知メールが送信される。このとき、承認担当者にも同じメールがｃｃとして送信される。
【００６６】
リリース済状態Ｓ３００４で作成担当者による改版の手続きが行われた場合には、改版要求イベントＥ４００７が発生し、文書管理サーバにおいて文書管理の状態が編集中状態Ｓ３００１に戻る。また、リリース済状態Ｓ３００４で廃版の手続きが行われた場合には、廃版要求イベントＥ４００８が発生して、文書管理サーバにおいて文書管理の状態が廃版承認中状態Ｓ３００５に移行する。そして、承認担当者宛に廃版承認依頼メールが送信される。このとき、廃版手続きを行った担当者にも同じメールがｃｃとして送信される。廃版承認中状態Ｓ３００５で承認者が承認の手続きを行った場合には承認イベントＥ４００９が発生し、文書を廃版させるとともに、関係者宛に廃版通知メールが送信される。一方、廃版承認中状態Ｓ３００５で承認者が却下の手続きを行った場合には却下イベントＥ４０１０が発生し、文書管理の状態がリリース済状態Ｓ３００４に戻る。それとともに、廃版手続きを行った担当者宛に、廃版却下通知メールが送信される。
【００６７】
図１３は、各文書に対して記憶される文書管理領域９００の内容を示す図である。この文書管理領域９００は、作成される文書そのものとともに、文書管理サーバ８００の文書データベースストレージ８０８に格納される。文書名９０１は文字列型の変数で、初期値としてはＮＵＬＬであるが、文書作成時にユーザにより設定される。文書状態９０２は、文書の状態が図１２で示した状態遷移図上のどの状態にあるかを示す状態変数である。各状態を一意に特定する番号を振って整数型の変数として記憶される。審査依頼通知メールメッセージＩＤ９０３から廃版通知メールメッセージＩＤ９０７の各変数は、それぞれの状態遷移イベントが発生した時に送信した状態変化通知メールに付したメッセージＩＤを記憶する領域である。これは文字列型の変数であり、デフォルト値はＮＵＬＬすなわち空文字である。以上の管理領域の情報に基づいて、文書状態変化があった場合の状態変化通知メール送信処理が行われる。
【００６８】
図１４は、文書管理サーバ８００の処理内容を示すフローチャートである。この処理は、文書管理サーバ８００において図１２で示した状態遷移図における状態遷移イベントが発生した場合に実行される処理である。図１４に示す処理に対応するプログラムがＲＯＭ８０３に格納されており、該プログラムをＣＰＵ８０１がＲＡＭ８０４上で実行することで、図１４に示す処理が実行される。
【００６９】
Ｓ２１０１においてＣＰＵ８０１は、文書データベースストレージ８０８に記憶されているデータベースから、処理対象とする文書に対応する文書管理領域９００を参照し、文書状態９０２を取得する。続くＳ２１０２においてＣＰＵ８０１は、Ｓ２１０１で取得した状態と発生したイベントから、図１２の状態遷移図に照らし合わせて発生したイベントが状態遷移イベントであったかどうかを判別する。状態遷移イベントでなかった場合にはＣＰＵ８０１はイベントに対する処理を終了する。一方、発生したイベントが状態遷移イベントであった場合には処理がＳ２１０３に進み、ＣＰＵ８０１は状態変化通知メール送信のために送信メッセージＩＤを生成する。続くＳ２１０４においてＣＰＵ８０１は、発生したイベントに応じた電子メール情報を作成する。次のＳ２１０５においてＣＰＵ８０１は、メールヘッダに同一文書に対する履歴メッセージのＩＤをメッセージヘッダに追加する。ひとつは、ＣＰＵ８０１が発生したイベントの直前の履歴通知メールのメッセージＩＤを文書管理領域９００から取得して「Ｉｎ−Ｒｅｐｌｙ−Ｔｏ：」ヘッダに設定する。またＣＰＵ８０１は、発生したイベントの前段階までの履歴通知メールのメッセージＩＤ全てを文書管理領域９００から取得して、「Ｒｅｆｅｒｅｎｃｅｓ：」ヘッダに設定する。例えば、リリース通知メールの「Ｉｎ−Ｒｅｐｌｙ−Ｔｏ：」ヘッダには、承認依頼通知メールメッセージＩＤ９０４が設定される。また、「Ｒｅｆｅｒｅｎｃｅｓ：」ヘッダには、審査依頼通知メールメッセージＩＤ９０３および承認依頼通知メールメッセージＩＤ９０４が列挙して設定される。続くＳ２１０６においてＣＰＵ８０１は、作成された電子メールの送信処理を行う。電子メールの送信後、ＣＰＵ８０１は、Ｓ２１０７において、送信されたメールのメッセージＩＤを文書管理領域９００の該当するメールメッセージＩＤ格納変数に格納する。最後にＳ２１０８においてＣＰＵ８０１は、図１２の状態遷移図に応じて適切な状態に移行し、文書管理領域９００の状態変数を更新する。
【００７０】
図１５は、文書管理サーバから送信される状態変化通知メールのメールヘッダの内容を示す図である。本図では図１２における承認イベントＥ４００５の発生時に送信されるリリース通知メールのメールヘッダの例を表している。「Ｍｅｓｓａｇｅ−Ｉｄ：」ヘッダには本通知メールのメッセージＩＤとして「ＸＸＸＸ．Ｓ０００３．Ｎ０００１．ｑｑｑｑ＠ｘｘｘ．ｙｙｙｙ．ｃｏ．ｊｐ」が設定されている。また、「Ｉｎ−Ｒｅｐｌｙ−Ｔｏ：」ヘッダには承認依頼メールのメッセージＩＤとして「ＸＸＸＸ．Ｓ０００２．Ｎ０００１．ｑｑｑｑ＠ｘｘｘ．ｙｙｙｙ．ｃｏ．ｊｐ」が設定されている。「Ｒｅｆｅｒｅｎｃｅｓ：」ヘッダには、審査依頼メールのメッセージＩＤとして「ＸＸＸＸ．Ｓ０００１．Ｎ０００１．ｑｑｑｑ＠ｘｘｘ．ｙｙｙｙ．ｃｏ．ｊｐ」が設定されている。また、承認依頼メールのメッセージＩＤとして「ＸＸＸＸ．Ｓ０００２．Ｎ０００１．ｑｑｑｑ＠ｘｘｘ．ｙｙｙｙ．ｃｏ．ｊｐ」が列挙して設定されている。このように「Ｒｅｆｅｒｅｎｃｅｓ：」ヘッダにはこれまでのワークフローの履歴の全てのメール通知のメッセージＩＤを設定することで、例えば審査依頼メールとリリース通知メールだけを受け取った場合にもその関連性が分かるようにすることができる。
【００７１】
図１６は、端末装置７０２、７０３の電子メール閲覧ソフトのメール一覧画面６００の受信順表示の場合の表示内容を示す図である。本図におけるメール一覧画面６００は、Ｉｎ−Ｒｅｐｌｙ−ＴｏヘッダやＲｅｆｅｒｅｎｃｅヘッダを参照してのメールメッセージ間の関連性は考慮されず、受信したメールを受信時間に基づいて受信順に表示した状態を表している。例えば、図１４におけるＳ２１０５の処理を行わずにメールが送信された場合、図１６に示すような一覧表示が表示される。図１６では、現時点での各文書の状態をユーザが認識し難い場合がある。例えば図１６の６２０のメール以降は、「文書Ｄ」と「文書Ｅ」の、２つの文書に関する状態変化通知メールが混在して送られてきている。このため、それぞれの文書の状態がその後どう推移しているのかユーザが認識し難い場合がある。
【００７２】
図１７は、図１４における処理により電子メールが送信された場合の、該電子メールを受信した端末装置７０２、７０３におけるメール一覧画面の一例を示す図である。具体的には、端末装置７０２、７０３の電子メール閲覧ソフトでは、メール一覧画面の表示方法の設定として、スレッド表示が設定されている。
【００７３】
図１７に示すメール一覧画面においては、図１６に示したメール一覧画面に比べ、各文書の状態がどう推移しているのかが認識し易く表示されていることがわかる。例えばこのメール一覧画面６００に対応するメールアドレスを所有するユーザが審査担当者である場合、図１７の文書Ａに対しては、審査依頼メール、承認依頼メール、リリース通知メールが受信される。図１７では、これらのメールの関係がメールスレッドとして分かりやすく表示されていることが分かる。一方、図１７の６２１で示すように、文書Ｂに対しては審査依頼メールの後に承認依頼メールがなくリリース通知メールを受信していることが分かる。例えば、このユーザが文書Ｂの作成担当者である場合、承認依頼メールのｃｃ送信が行われず、図１７に示す受信状態となる。図１４のＳ２１０５で説明した処理により、リリース通知メールには、審査依頼メールおよび承認依頼メールのメッセージＩＤ全てを「Ｒｅｆｅｒｅｎｃｅｓ：」ヘッダに設定している。このため、途中段階の承認依頼メールを受信していなくても、審査依頼メールとリリース通知メールの依存関係が階層的に表示されるようになる。また、図１７の６２２の文書Ｃのリリース承認通知メール、６２３の文書Ｆのリリース承認通知メールに関しては、前段階の審査依頼、承認依頼のメールが受信されていない。上記ユーザがこれら文書の作成、審査、承認に関わっていない場合、図１７に示す受信状態になる。また図１７の６２４の状態変化通知メールにおいて、文書Ｅの承認依頼が通知されているが、その承認処理はまだ完了していないということを上記ユーザは容易に認識することができる。
【００７４】
以上の実施形態によれば、処理装置が該処理装置の状態の変化についてメールで通知する。このとき該処理装置は、特定の項目に対応する状態の変化については、該特定の項目に関して先に送信したメールのメッセージＩＤを、該メールとの関連情報として含むメールを作成し、送信する。上記の例では、先に送信したメールのメッセージＩＤが「Ｉｎ−Ｒｅｐｌｙ−Ｔｏ：」ヘッダおよび「Ｒｅｆｅｒｅｎｃｅｓ：」ヘッダにユーザが指示しなくても自動的に記載されたメールが作成され、送信される。
【００７５】
そのため、これら複数のメールを受信した装置が、上記の関連情報を参照することで、該複数のメールを関連付けて表示することができる。例えば、メールを受信した電子メールソフトにおいて表示設定がスレッド表示に設定されている場合、該電子メールソフトにおいて「Ｉｎ−Ｒｅｐｌｙ−Ｔｏ：」ヘッダおよび「Ｒｅｆｅｒｅｎｃｅｓ：」ヘッダが参照される。そして、あるメッセージＩＤに対応するメールと、同一のメッセージＩＤを「Ｉｎ−Ｒｅｐｌｙ−Ｔｏ：」ヘッダまたは「Ｒｅｆｅｒｅｎｃｅｓ：」ヘッダに含むメールが関連付けられて表示される。
【００７６】
以上の実施形態によれば、上記の構成により、状態変化通知メールを受信した電子メールソフトのメール一覧画面表示において、状態変化の事象の推移の関連性が分かりやすく表示することができる。
【００７７】
なお、上記の実施形態においては、関連する事象を通知した電子メールのメッセージＩＤを設定する電子メールヘッダとして「Ｉｎ−Ｒｅｐｌｙ−Ｔｏ：」ヘッダおよび「Ｒｅｆｅｒｅｎｃｅｓ：」ヘッダを利用する場合を説明した。この方法であれば、「Ｉｎ−Ｒｅｐｌｙ−Ｔｏ：」ヘッダおよび「Ｒｅｆｅｒｅｎｃｅｓ：」ヘッダを参照可能な標準的なメールソフトにおいて、複数の状態変化通知メールを関連付けて表示することができる。
【００７８】
ただし、これらヘッダの代わりに、複数のメッセージの関連性を表すその他のヘッダを用いることも可能である。例えば、特定のメールソフトに定義された独自のヘッダ領域に対し、複数のメールの関連性を示す関連情報を記載し、該メールソフトに対してメールを送信することも可能である。この場合、メールを送信する処理装置は、上記独自のヘッダ領域に、関連情報以外の各種の情報を書き込むこともできる。
【００７９】
また、先に送信された電子メールのメッセージＩＤを設定するヘッダ領域をユーザが選択できる構成としてもよい。例えば、上記の特定のメールソフトに対応するメールアドレスに状態変化通知メールが送信される場合、メッセージＩＤを独自のヘッダ領域に記述するようユーザにより選択される。一方で、標準的なメールソフトに対応するメールアドレスに状態変化通知メールが送信される場合、メッセージＩＤを「Ｉｎ−Ｒｅｐｌｙ−Ｔｏ：」ヘッダおよび「Ｒｅｆｅｒｅｎｃｅｓ：」ヘッダに記述するようユーザにより選択される。
【００８０】
また他の構成として、各種メールソフトが利用するヘッダ情報をＭＦＰ２００や文書管理システム７００が保持し、ユーザがメールソフトを選択できるようにし、選択されたメールソフトに対応するヘッダ領域に関連情報を追加するように構成してもよい。
【００８１】
或いは、ユーザにより上記の選択が行われることなく、常にメッセージＩＤが上記独自のヘッダ領域、「Ｉｎ−Ｒｅｐｌｙ−Ｔｏ：」ヘッダおよび「Ｒｅｆｅｒｅｎｃｅｓ：」ヘッダに記述されてもよい。この場合、状態変化通知メールを受信した電子メールソフトが上記特定のメールソフトであっても、一般的なメールソフトであっても、複数の状態変化通知メールを関連付けて表示することができる。
【００８２】
また以上の実施形態では、例えば印刷装置に関する状態（ステータス）の変化について、印刷装置自身が電子メールを送信していたが、これに限らない。例えば印刷装置と接続されているＰＣやＷｅｂサーバが、印刷装置の状態を示すステータス情報を取得し、取得されたステータス情報に基づいて電子メールの作成、送信を行っても良い。
【００８３】
なお、以上の実施形態の機能は以下の構成によっても実現することができる。つまり、本実施形態の処理を行うためのプログラムコードをシステムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）がプログラムコードを実行することによっても達成される。この場合、記憶媒体から読み出されたプログラムコード自体が上述した実施形態の機能を実現することとなり、またそのプログラムコードを記憶した記憶媒体も以上の実施形態の機能を実現することになる。
【００８４】
また、以上の実施形態の機能を実現するためのプログラムコードを、１つのコンピュータ（ＣＰＵ、ＭＰＵ）で実行する場合であってもよいし、複数のコンピュータが協働することによって実行する場合であってもよい。さらに、プログラムコードをコンピュータが実行する場合であってもよいし、プログラムコードの機能を実現するための回路等のハードウェアを設けてもよい。またはプログラムコードの一部をハードウェアで実現し、残りの部分をコンピュータが実行する場合であってもよい。
【符号の説明】
【００８５】
２００  ＭＦＰ
２０１  ＣＰＵ
２０２  内部バス
２０３  プログラムメモリ
２０４  データメモリ
【図１】
2018073106.tif 000003
【図２】
2018073106.tif 000004
【図３】
2018073106.tif 000005
【図４】
2018073106.tif 000006
【図５】
2018073106.tif 000007
【図６】
2018073106.tif 000008
【図７】
2018073106.tif 000009
【図８】
2018073106.tif 000010
【図９】
2018073106.tif 000011
【図１０】
2018073106.tif 000012
【図１１】
2018073106.tif 000013
【図１２】
2018073106.tif 000014
【図１３】
2018073106.tif 000015
【図１４】
2018073106.tif 000016
【図１５】
2018073106.tif 000017
【図１６】
2018073106.tif 000018
【図１７】
2018073106.tif 000019