(57)【要約】【課題】  少なくとも第一の装置と第二の装置との間で、互いに通信を行うことにより、第一の装置によって第二の装置を制御するように構成された情報処理装置において、第一の装置と第二の装置との間で、命令等の通信が正常に行われたか否かを確実に判別することができ、命令等の通信の対応を維持することを可能とする。【解決手段】  前記第一の装置は、当該第一の装置が協調動作を継続できないことを第二の装置に通知する通知手段と、前記第二の装置からの応答を待つ応答待ち手段と、前記第二の装置からの応答を待つまでに受け取った情報を処理する処理手段と、を備え、前記第二の装置は、前記第一の装置から協調動作を継続できないことの通知を受け取る受信手段と、前記協調動作を継続できないことの通知を受け取った場合に、前記第一の装置へ当該通知を受け取った旨の応答を返す応答手段を備えるように構成して課題を解決した。【選択図】  図１
2005339341.tif 000002
【特許請求の範囲】
【請求項１】
互いに通信を行うことによって情報の交換を行う少なくとも第一の装置と第二の装置とを備え、少なくとも一方の装置が他方の装置と協調した動作を行うことにより、情報を処理する情報処理装置において、
前記第一の装置は、
当該第一の装置が協調動作を継続できないことを第二の装置に通知する通知手段と、
前記第二の装置からの応答を待つ応答待ち手段と、
前記第二の装置からの応答を待つまでに受け取った情報を処理する処理手段と、
を備え、
前記第二の装置は、
前記第一の装置から協調動作を継続できないことの通知を受け取る受信手段と、
前記協調動作を継続できないことの通知を受け取った場合に、前記第一の装置へ当該通知を受け取った旨の応答を返す応答手段を備えたことを特徴とする情報処理装置。
【請求項２】
前記応答待ち手段は、一定時間応答がない場合、応答があったものとして扱うことを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記処理手段は、処理を行っても無駄になる情報については処理しないことを特徴とする請求項１又は２に記載の情報処理装置。
【請求項４】
前記処理手段は、前記応答手段が応答を返した後に受け取った情報は処理しないことを特徴とする請求項１乃至３のいずれかに記載の情報処理装置。
【請求項５】
前記処理手段は、前記応答手段が応答を返した後に受け取った情報で処理を行うと第一の装置の状態に影響を及ぼす処理のみについては処理しないことを特徴とする請求項１乃至３のいずれかに記載の情報処理装置。
【請求項６】
前記通知手段は、第一の装置の復帰処理の影響が第二の装置に及ぶか否かの情報を通知することを特徴とする請求項１乃至５のいずれかに記載の情報処理装置。
【請求項７】
互いに通信を行うことによって情報の交換を行う少なくとも第一の装置と第二の装置とを備え、少なくとも一方の装置が他方の装置と協調した動作を行うことにより、情報を処理する情報処理装置において、
前記第一の装置は、
当該第一の装置が協調動作を継続できないことを第二の装置に通知する通知手段と、
前記第二の装置からの応答を待つ応答待ち手段と、
前記第二の装置からの応答を待つまでに受け取った情報を処理する処理手段と、
を備え、
前記第二の装置は、
前記第一の装置から協調動作を継続できないことの通知を受け取る受信手段と、
前記協調動作を継続できないことの通知を受け取った場合に、前記第一の装置へ当該通知を受け取った旨の応答を返す応答手段と、
前記協調動作を終了させるための後処理を行う後処理手段と、
を備えたことを特徴とする情報処理装置。
【請求項８】
前記後処理手段が行う後処理は、不揮発性記憶手段への装置状態の退避であることを特徴とする請求項７に記載の情報処理装置。
【請求項９】
前記後処理手段が行う後処理は、装置メカニズムの適切な位置への退避であることを特徴とする請求項７に記載の情報処理装置。
【請求項１０】
前記後処理手段が行う後処理は、情報処理動作の完全停止であることを特徴とする請求項７に記載の情報処理装置。
【請求項１１】
互いに通信を行うことによって情報の交換を行う少なくとも第一の装置と第二の装置とを備え、少なくとも一方の装置が他方の装置と協調した動作を行うことにより、情報を処理する情報処理装置において、
前記第一の装置は、
特定の条件が生じたときに、当該第一の装置の動作状態を第二の動作状態に遷移させる遷移手段と、
特定の条件が生じたことを第二の装置に通知する通知手段と、
前記特定の条件が解消されたことを第二の装置に認識させる認識手段と、
前記特定の条件が解消されたときに第二の動作状態にある前記第一の装置の状態を元の動作状態に復帰させる復帰手段と、
を備えたことを特徴とする情報処理装置。
【請求項１２】
前記特定の条件とは、前記第一の装置がエラーを検知したときであることを特徴とする請求項１１に記載の情報処理装置。
【請求項１３】
前記特定の条件が生じたことを第二の装置に通知する手段は、第一の装置からの通知によることを特徴とする請求項１１又は１２に記載の情報処理装置。
【請求項１４】
前記特定の条件が解消したことを第二の装置に認識させる手段は、第一の装置からの通知によることを特徴とする請求項１１乃至１３のいずれかに記載の情報処理装置。
【請求項１５】
前記第二の動作状態に遷移している間は、一部の情報を処理せず無視するように構成したことを特徴とする請求項１１乃至１４のいずれかに記載の情報処理装置。
【請求項１６】
互いに通信を行うことによって情報の交換を行う少なくとも第一の装置と第二の装置とを備え、少なくとも一方の装置が他方の装置と協調した動作を行うことにより、情報を処理する情報処理装置において、前記第一の装置及び第二の装置は、一方の装置が動作可能であることを他方の装置に対して通知する動作可能通知手段と、前記一方の装置が他方の装置から動作可能である旨の通知を受けて、他方の装置が動作可能であることを確認すると、当該一方の装置が確認したことを他方の装置に応答する確認応答手段と、を備え、前記第一の装置又は第二の装置の少なくとも一方は、前記動作可能通知手段による動作確認通知を通知したか、又は前記確認応答手段による確認応答を受けたことの少なくとも一方を条件に、特定の動作状態に遷移するように制御する制御手段を備えたことを特徴とする情報処理装置。
【請求項１７】
前記一方の装置が動作可能であるとは、当該一方の装置を制御するソフトウェアが動作を開始した状態であることを特徴とする請求項１６に記載の情報処理装置。
【請求項１８】
前記特定の動作状態として、互いに異なる複数の動作状態が設定されていることを特徴とする請求項１６又は１７に記載の情報処理装置。
【請求項１９】
前記特定の動作状態は、動作確認通知を通知したか、又は前記確認応答手段による確認応答を受けたかによって、遷移すべき状態が異なることを特徴とする請求項１６乃至１８のいずれかに記載の情報処理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、電子写真方式やインクジェット方式などを用いたプリンタや複写機等の画像形成装置の如く、画像データなどの情報に基づいて画像出力等の情報処理を行う情報処理装置に関し、特にコントローラ等の第一の装置とプリンタエンジン等の第二の装置との間で、命令の対応を維持することを可能とした情報処理装置に関するものである。
【背景技術】
【０００２】
【特許文献１】特開２０００−２２２３３４号公報
【特許文献２】特開２００１−９２６０４号公報
【０００３】
従来、この種の電子写真方式やインクジェット方式などを採用したプリンタや複写機等の画像形成装置では、例えば、コントローラと画像出力装置（ＩＯＴ）との間で、互いに通信を行うことによって、画像出力装置（ＩＯＴ）等のデバイスを制御するように構成されているものがある。このような画像形成装置の場合には、コントローラが画像出力装置（ＩＯＴ）を制御するために、制御する側であるコントローラが、制御される側である画像出力装置（ＩＯＴ）の状態を把握しておく必要がある。そのため、上記コントローラと画像出力装置（ＩＯＴ）の間では、メッセージのやりとりが行われ、コントローラが画像出力装置（ＩＯＴ）の状態を常時把握しておくように構成されている。
【０００４】
ところが、上記コントローラと画像出力装置（ＩＯＴ）の間では、シリアル通信等によってメッセージのやりとりを行う関係上、通信にある程度の時間を必要とし、リアルタイムで通信を行うことができず、主に通信遅延のため、一時的に、制御する側であるコントローラが認識している画像出力装置（ＩＯＴ）の状態と、実際の画像出力装置（ＩＯＴ）の状態との間にずれが生じる場合がある。通常、このコントローラが認識している画像出力装置（ＩＯＴ）の状態と、実際の画像出力装置（ＩＯＴ）の状態との間のずれは、問題とならないが、次のような場合に不都合が生じる虞れがある。
【発明の開示】
【発明が解決しようとする課題】
【０００５】
すなわち、上記従来技術の場合には、次のような問題点を有している。
図１３は画像出力装置（ＩＯＴ）としてのプリンタエンジンが、コントローラに対して２ぺージ目の印刷完了の通知を送信した後に、何らかの原因でシステムがリセットされたか若しくはシステムが再起動された場合のシーケンスを示したものである。
【０００６】
この場合、プリンタエンジン側から見た場合には、図１３（ｂ）に示すように、コントローラ側が２ぺージ目の印刷完了通知を正常に受信して処理したのか、図１３（ａ）に示すように、コントローラ側が２ぺージ目の印刷完了通知を受信する以前に、システムのリセット要因等が発生して、２ぺージ目の印刷完了通知を正常に受信できず処理しなかったのかを判別することができない。また、図１３（ａ）に示す場合、コントローラ側では、プリンタエンジンが２ぺージ目の印刷動作を完了し、２ぺージ目の印刷完了通知を送信したか否か判別することができないため、プリンタエンジンから２ぺージ目の印刷完了通知が送信されたが、正常に受信できなかったのか、プリンタエンジンから２ぺージ目の印刷完了通知自体がなかったのか判別することができない。
【０００７】
図１４はコントローラとプリンタエンジンとの間で通信エラーが発生した場合の具体的な例を更に示したものである。
【０００８】
図１４（ａ）はコントローラからプリンタエンジンが２枚目の印刷指示を受信した後に、プリンタエンジンがエラー通知をコントローラに送信するとともに、引き続きエラーが解消してエラー解消通知をコントローラに送信した場合を示したものである。また、図１４（ｂ）はコントローラからプリンタエンジンが２枚目の印刷指示を受信する直前に、プリンタエンジンがエラー通知をコントローラに送信し、当該プリンタエンジンが２枚目の印刷指示を受信した後に、プリンタエンジンがエラー解消通知をコントローラに送信した場合を示したものである。さらに、図１４（ｃ）はコントローラからプリンタエンジンが２枚目の印刷指示を送信する以前に、プリンタエンジンがエラー通知をコントローラに送信し、当該エラー通知をプリンタエンジンが受信する以前に、コントローラが２枚目の印刷指示を送信するとともに、当該２枚目の印刷指示をプリンタエンジンが受信する以前に、プリンタエンジンがエラー解消通知をコントローラに送信した場合を示したものである。
【０００９】
これらの図１４（ａ）、（ｂ）、（ｃ）共に、コントローラから見た場合には、プリンタエンジンに対して２枚目の印刷指示を送信した直後、エラー通知を受信してエラーが発生したことを知るとともに、エラー解消通知を受信して、直ぐにエラーが解消しているようにしか見ることができない。
【００１０】
図１４( ａ) 、（ｂ）、（ｃ）に示すように、プリンタエンジン側では全く異なった状態が発生しているため、プリンタエンジンの仕様によっては、次のような問題点が生じることになる。
【００１１】
すなわち、上記プリンタエンジンがエラー発生時やエラー解消時に以前のプリント指示を単純にクリアしてしまうように構成されている場合、つまり図１４（ｂ）に示す場合には、すべてのプリント指示がクリアされるのに対して、図１４（ｃ）に示す場合には、エラー解消の通知後に２枚目の印刷指示を受信しているため、２枚目の印刷指示がそのまま残ってしまうことになる。そのため、上記コントローラ側では、図１４（ａ）、（ｂ）、（ｃ）に示す各々の状態を識別することができず、場合によっては、２枚目が印刷されなかったり、２枚目が重複して印刷されてしまうなどの不都合が生じるという問題点を有していた。
【００１２】
また、図１５はコントローラとプリンタエンジンとの間において、制御ソフトウェアの動作開始時の動作の一例を示すものである。
【００１３】
コントローラは、図１５に示すように、制御ソフトウェアの動作が開始すると、プリンタエンジンへ情報交換のためのメッセージ１、２を送信する。一方、このメッセージ１、２を受け取るべきプリンタエンジンのソフトウェアが動作を開始している場合は、そのまま情報交換が始まるが、プリンタエンジンのソフトウェアが動作を開始していない場合は、コントローラから送信されたメッセージ１、２が無駄になってしまうという不都合が生じる。
【００１４】
その際、コントローラ自身は、少なくとも通信部分のソフトウェアが動作しており、メッセージの送信自体は正常に終了しているため、コントローラは、送信したメッセージがプリンタエンジン側のソフトウェアに正常に伝わったか否かを、当該メッセージに対して応答が返ってくることでしか知ることができない。そのため、コントローラは、タイムアウト時間を適宜設定し、応答が返ってくるまで同じメッセージを送り続けるように構成されている。その結果、タイムアウト時間を短く設定すればレスポンスは良くなるが、コントローラが頻繁にメッセージを送信しなければならないなど、コントローラの負荷などが増加するという問題点を有している。
【００１５】
また、エラー発生時にプリンタエンジンのソフトウェアを再起動した場合には、手順を始めからやり直す必要があるが、そのままではコントローラは、プリンタエンジンにメッセージが伝わっているのか、プリンタエンジンにメッセージが伝わらずに再起動されたのかを知ることができないという問題点を有している。
【００１６】
そこで、本発明は、上記従来技術の問題点を解決するためになされたものであり、そのとするところは、少なくとも制御装置等の第一の装置と被制御装置等の第二の装置との間で、互いに通信を行うことにより、第一の装置によって第二の装置を制御するように構成された情報処理装置において、第一の装置と第二の装置との間で、命令等の通信が正常に行われたか否かを確実に判別することができ、命令等の通信の対応を維持することが可能な情報処理装置を提供することにある。
【課題を解決するための手段】
【００１７】
上記の課題を解決するため、請求項１に記載された発明は、
互いに通信を行うことによって情報の交換を行う少なくとも第一の装置と第二の装置とを備え、少なくとも一方の装置が他方の装置と協調した動作を行うことにより、情報を処理する情報処理装置において、
前記第一の装置は、
当該第一の装置が協調動作を継続できないことを第二の装置に通知する通知手段と、
前記第二の装置からの応答を待つ応答待ち手段と、
前記第二の装置からの応答を待つまでに受け取った情報を処理する処理手段と、
を備え、
前記第二の装置は、
前記第一の装置から協調動作を継続できないことの通知を受け取る受信手段と、
前記協調動作を継続できないことの通知を受け取った場合に、前記第一の装置へ当該通知を受け取った旨の応答を返す応答手段を備えたことを特徴とする情報処理装置である。
【００１８】
また、請求項２に記載された発明は、前記応答待ち手段は、一定時間応答がない場合、応答があったものとして扱うことを特徴とする請求項１に記載の情報処理装置である。
【００１９】
さらに、請求項３に記載された発明は、前記処理手段は、処理を行っても無駄になる情報については処理しないことを特徴とする請求項１又は２に記載の情報処理装置である。
【００２０】
又、請求項４に記載された発明は、前記処理手段は、前記応答手段が応答を返した後に受け取った情報は処理しないことを特徴とする請求項１乃至３のいずれかに記載の情報処理装置である。
【００２１】
更に、請求項５に記載された発明は、前記処理手段は、前記応答手段が応答を返した後に受け取った情報で処理を行うと第一の装置の状態に影響を及ぼす処理のみについては処理しないことを特徴とする請求項１乃至３のいずれかに記載の情報処理装置である。
【００２２】
また、請求項６に記載された発明は、前記通知手段は、第一の装置の復帰処理の影響が第二の装置に及ぶか否かの情報を通知することを特徴とする請求項１乃至５のいずれかに記載の情報処理装置である。
【００２３】
さらに、請求項７に記載された発明は、
互いに通信を行うことによって情報の交換を行う少なくとも第一の装置と第二の装置とを備え、少なくとも一方の装置が他方の装置と協調した動作を行うことにより、情報を処理する情報処理装置において、
前記第一の装置は、
当該第一の装置が協調動作を継続できないことを第二の装置に通知する通知手段と、
前記第二の装置からの応答を待つ応答待ち手段と、
前記第二の装置からの応答を待つまでに受け取った情報を処理する処理手段と、
を備え、
前記第二の装置は、
前記第一の装置から協調動作を継続できないことの通知を受け取る受信手段と、
前記協調動作を継続できないことの通知を受け取った場合に、前記第一の装置へ当該通知を受け取った旨の応答を返す応答手段と、
前記協調動作を終了させるための後処理を行う後処理手段と、
を備えたことを特徴とする情報処理装置である。
【００２４】
又、請求項８に記載された発明は、前記後処理手段が行う後処理は、不揮発性記憶手段への装置状態の退避であることを特徴とする請求項７に記載の情報処理装置である。
【００２５】
更に、請求項９に記載された発明は、前記後処理手段が行う後処理は、装置メカニズムの適切な位置への退避であることを特徴とする請求項７に記載の情報処理装置である。
【００２６】
また、請求項１０に記載された発明は、前記後処理手段が行う後処理は、情報処理動作の完全停止であることを特徴とする請求項７に記載の情報処理装置である。
【００２７】
さらに、請求項１１に記載された発明は、
互いに通信を行うことによって情報の交換を行う少なくとも第一の装置と第二の装置とを備え、少なくとも一方の装置が他方の装置と協調した動作を行うことにより、情報を処理する情報処理装置において、
前記第一の装置は、
特定の条件が生じたときに、当該第一の装置の動作状態を第二の動作状態に遷移させる遷移手段と、
特定の条件が生じたことを第二の装置に通知する通知手段と、
前記特定の条件が解消されたことを第二の装置に認識させる認識手段と、
前記特定の条件が解消されたときに第二の動作状態にある前記第一の装置の状態を元の動作状態に復帰させる復帰手段と、
を備えたことを特徴とする情報処理装置である。
【００２８】
又、請求項１２に記載された発明は、前記特定の条件とは、前記第一の装置がエラーを検知したときであることを特徴とする請求項１１に記載の情報処理装置である。
【００２９】
更に、請求項１３に記載された発明は、前記特定の条件が生じたことを第二の装置に通知する手段は、第一の装置からの通知によることを特徴とする請求項１１又は１２に記載の情報処理装置である。
【００３０】
また、請求項１４に記載された発明は、前記特定の条件が解消したことを第二の装置に認識させる手段は、第一の装置からの通知によることを特徴とする請求項１１乃至１３のいずれかに記載の情報処理装置である。
【００３１】
さらに、請求項１５に記載された発明は、前記第二の動作状態に遷移している間は、一部の情報を処理せず無視するように構成したことを特徴とする請求項１１乃至１４のいずれかに記載の情報処理装置である。
【００３２】
又、請求項１６に記載された発明は、互いに通信を行うことによって情報の交換を行う少なくとも第一の装置と第二の装置とを備え、少なくとも一方の装置が他方の装置と協調した動作を行うことにより、情報を処理する情報処理装置において、前記第一の装置及び第二の装置は、一方の装置が動作可能であることを他方の装置に対して通知する動作可能通知手段と、前記一方の装置が他方の装置から動作可能である旨の通知を受けて、他方の装置が動作可能であることを確認すると、当該一方の装置が確認したことを他方の装置に応答する確認応答手段と、を備え、前記第一の装置又は第二の装置の少なくとも一方は、前記動作可能通知手段による動作確認通知を通知したか、又は前記確認応答手段による確認応答を受けたことの少なくとも一方を条件に、特定の動作状態に遷移するように制御する制御手段を備えたことを特徴とする情報処理装置である。
【００３３】
更に、請求項１７に記載された発明は、前記一方の装置が動作可能であるとは、当該一方の装置を制御するソフトウェアが動作を開始した状態であることを特徴とする請求項１６に記載の情報処理装置である。
【００３４】
また、請求項１８に記載された発明は、前記特定の動作状態として、互いに異なる複数の動作状態が設定されていることを特徴とする請求項１６又は１７に記載の情報処理装置である。
【００３５】
さらに、請求項１９に記載された発明は、前記特定の動作状態は、動作確認通知を通知したか、又は前記確認応答手段による確認応答を受けたかによって、遷移すべき状態が異なることを特徴とする請求項１６乃至１８のいずれかに記載の情報処理装置である。
【発明の効果】
【００３６】
この発明によれば、制御装置と被制御装置との間で、互いに通信を行うことにより、制御装置によって被制御装置を制御するように構成された情報処理装置において、制御装置と被制御装置との間で、命令等の通信が正常に行われたか否かを確実に判別することができ、命令等の通信の対応を維持することが可能な情報処理装置を提供することが可能となる。
【発明を実施するための最良の形態】
【００３７】
以下に、この発明の実施の形態について図面を参照して説明する。
【００３８】
実施の形態１
図２はこの実施の形態１に係る画像処理装置としてのプリンタを示すブロック図である。
【００３９】
このプリンタ１００は、図２に示すように、第一の装置としてのコントローラ２００と、第二の装置としてのプリンタエンジン３００とから構成されている。コントローラ２００は、当該コントローラ２００とプリンタエンジン３００とを制御するＣＰＵ２０１と、作業領域として利用されるＲＡＭ２０２と、ブートストラップなど基本的なソフトウェアを格納したＲＯＭ２０３と、複雑な制御やユーザに機能を提供するためソフトウェアなどを格納するハードディスク２０４と、ネットワークと接続するためのネットワークインターフェースコントローラ２０５と、プリンタエンジン３００と通信するためのシリアルインターフェースコントローラ２０６とを備えるように構成されている。
【００４０】
一方、プリンタエンジン３００は、図２に示すように、当該プリンタエンジン３００のプリント動作を制御するＣＰＵ３０１と、作業領域として利用されるＲＡＭ３０２と、制御用のソフトウェアを格納するＲＯＭ３０３と、コントローラと通信するためのシリアルインターフェースコントローラ３０４と、印刷を行うために利用する印刷デバイス３０５とを備えるように構成されている。
【００４１】
また、上記コントローラ２００とプリンタエンジン３００とは、通信線４００を介して互いに通信可能に接続されており、これらコントローラ２００とプリンタエンジン３００は、通信線４００を介してシリアルインターフェースコントローラ２０６、３０４により種々の通信を行い、プリンタエンジン３００における情報処理動作としてのプリント動作を制御するように構成されている。
【００４２】
図１は上記プリンタの構成を機能的に表した場合の論理的な構成図である。
【００４３】
上記コントローラ２００とプリンタエンジン３００との間では、図１に示すように、互いに通信モジュール２１０、３１０を利用して情報が交換される。通信モジュール２１０、３１０は、コントローラ２００及びプリンタエンジン３００の双方に設けられており、ハードウェアやソフトウェアを適宜初期化しつつ通信可能にするものである。また、上記通信モジュール２１０、３１０は、通信バッファの管理などを行い、コントローラ２００とプリンタエンジン３００との間で適切に通信を行えるように構成されている。
【００４４】
上記コントローラ２００には、その他、システムの制御を行うシステム制御モジュール２１１と、コントローラの各機能を実現する機能モジュール２１２と、ネットワーク通信モジュール２１３とが設けられている。
【００４５】
上記ネットワーク通信モジュール２１３は、ネットワーク５００に関する入出力制御を行うものである。このネットワーク通信モジュール２１３は、例えば、ＰＤＬ（Page Description Language ）等で記述されたプリントすべきデータを、図示しないホストコンピュータ等から受け取る機能を果たしている。また、機能モジュール２１２は、コントローラ２００の各機能を実現するためのものであり、例えば、ネットワーク５００から受け取ったＰＤＬで記述されたプリントデータから、印刷のビットマップを作成（レンダリング）したり、サーバ機能を実現したりする。
【００４６】
さらに、上記システム制御モジュール２１１は、システム全体の制御を行うためのものであり、通信モジュール２１０を介してプリンタエンジン３００のエンジン制御モジュール３１１を制御する機能を果たしている。このシステム制御モジュール２１１とエンジン制御モジュール３１１は、通信モジュール２１０、３１０を介して通信が行われるが、制御モジュール２１１、３１１間のメッセージ通信の開始やメッセージ通信開始以前のバッファの初期化指示などは制御モジュール２１１、３１１が行い、通信モジュール２１０、３１０は、相手側の通信モジュール２１０、３１０との間の通信が可能なことを保障するのみとなっている。
【００４７】
また、プリンタエンジン３００には、通信モジュール３１０以外に、エンジン制御モジュール３１１が設けられており、当該エンジン制御モジュール３１１は、システム制御モジュール２１１の指示に応じてプリント動作を制御するように構成されている。
【００４８】
ところで、この実施の形態では、図１に示すように、互いに通信を行うことによって情報の交換を行う少なくともコントローラ２００とプリンタエンジン３００とを備え、少なくとも一方の装置が他方の装置と協調した動作を行うことにより、情報を処理するプリンタ１００において、前記コントローラ２００は、当該コントローラ２００が協調動作を継続できないことをプリンタエンジン３００に通知する通知手段としての通信モジュール２１０と、前記プリンタエンジン３００からの応答を待つ応答待ち手段としてのシステム制御モジュール２１１と、前記プリンタエンジン３００からの応答を待つまでに受け取った情報を処理する機能モジュール２１２と、を備え、前記プリンタエンジン３００は、前記コントローラ２００から協調動作を継続できないことの通知を受け取る受信手段としての通信モジュール３１０と、前記協調動作を継続できないことの通知を受け取った場合に、前記コントローラ２００へ当該通知を受け取った旨の応答を返す応答手段としてのエンジン制御モジュール３１１を備えるように構成されている。
【００４９】
以上の構成において、この実施の形態に係るプリンタでは、次のようにして、制御装置と被制御装置との間で、互いに通信を行うことにより、制御装置によって被制御装置を制御するように構成された情報処理装置において、制御装置と被制御装置との間で、命令等の通信が正常に行われたか否かを確実に判別することができ、命令等の通信の対応を維持することが可能となっている。
【００５０】
すなわち、この実施の形態では、コントローラ２００がリセット要因を検知した場合に、図３のフローチャトに示すような動作が実行される。
【００５１】
まず、リセットする要因が発生すると、コントローラ２００のシステムモジュール２１１は、通信モジュール２１０を介して、図４に示すように、リセット事前通知でリセットを行うことをプリンタエンジン３００に通知する（ステップ１０１）。ここで、リセットする要因としては、ユーザによるリセット要求の場合や、システム機能モジュール２１１に予め設定されたリセット要因が発生した場合などが挙げられる。このとき、上記リセット事前通知には、プリンタエンジン３００を含めたシステム全体がリセットされるのか、コントローラ２００だけがリセットされるのかを知らせるフラグがセットされている。
【００５２】
次に、コントローラ２００は、リセット処理を実行するための事前準備を行うようになっている（ステップ１０２）。この事前準備としては、例えば、ハードディスク２０４ヘのキャッシュデータの退避などが挙げられる。
【００５３】
さらに、コントローラ２００は、所定のタイムアウト時間を設定して（ステップ１０３）、リセット事前通知の確認応答がプリンタエンジン３００から返ってくるまで待機する。その間、コントローラ２００は、プリンタエンジン３００から送られてきた情報のうち、リセットされても情報として意味がある出力情報のみを処理するように構成されている。なお、コントローラ２００は、その他の情報を受信しても、単に受信するだけで無視するようになっている。
【００５４】
実際には、コントローラ２００は、確認応答待ちの間、図５に示すような動作を実行する。コントローラ２００は、リセット事前確認応答待ちの状態（ステップ２０１）にあると、印刷済みのぺージを通知するメッセージの場合に限り、文書のぺージをどこまで出力したかを当該コントローラ２００は管理している都合上、印刷済みページの更新処理を行うようになっている（ステップ２０２）。また、コントローラ２００は、図３に示すように、事前通知の確認応答をプリンタエンジン３００から受信すると（ステップ１０４）、当然のことながら、図４の確認応答待ちの状態から抜け出し、リセット動作を実行するようになっている（ステップ１０５）。これ以外のメッセージの場合は、コントローラ２００は、たとえ処理をしてもリセットされてしまうため、処理を行わず単にメッセージを取得するのみとなっている。また、コントローラ２００は、リセット事前通知への確認応答が一定時間内に通知されない場合も、図５に示すように、タイムアウトとして確認応答待ち状態から抜け出るように設定されている。
【００５５】
そしてこれは、上記コントローラ２００は、リセット事前通知の確認応答を待つときに、プリンタエンジン３００からの応答が一定時間以上無ければ、強制的にリセットを行うようにタイムアウト時間があらかじめ設定されているためである。
【００５６】
一方、プリンタエンジン３００側は、図３に示すように、リセット事前通知を受信すると、次のような動作を行う。
【００５７】
まず、プリンタエンジン３００は、図３に示すように、プリント処理中であるか否かを判別し（ステップ１０６）、プリント処理中の場合には、印刷動作の停止処理を開始する（ステップ１０７）。この印刷動作停止処理は、できる限り速やかに行われる。その理由は、コントローラ２００側でリセットを行う要因が発生しているため、コントローラ２００側から情報が送られてくる保障がないためである。一方、プリンタエンジン３００がプリント処理中でない場合は、そのまま次の処理に進む。
【００５８】
次に、プリンタエンジン３００は、まだ送信されていないが送信しなければならない必要最低限の情報をコントローラ２００に送信する（ステップ１０８）。必要最低限の情報とは、通常は電源のＯＮ／ＯＦＦに関係なく管理されるプリンタエンジン３００の状態についての情報である。その後、プリンタエンジン３００は、当該プリンタエンジン３００も同時にリセットされるか否かをフラグにより判別し（ステップ１０９）、プリンタエンジン３００も同時にリセットされることがリセット事前通知によって通知されていれば、リセットされた場合に備える処理を行う（ステップ１１０）。例えば、コントローラ２００と同時にプリンタエンジン３００もリセットされる場合には、確実にプリンタエンジン３００が停止していなければならないので、当該停止処理を行うなどである。なお、この場合、コントローラ２００だけがリセットされる場合は、コントローラ２００からの応答が無くとも、プリントエエンジン３００は停止処理を完了することができることを前提としている。コントローラ２００のみのリセットである場合は、この時点ではプリンタエンジン３００は何も行わない。最後に、プリンタエンジン３００は、図４に示すように、リセット事前通知への応答を返すことで（ステップ１１１）、これ以上、コントローラ２００がリセットされるまでの間に処理すべき情報がないことを通知するようになっている。
【００５９】
なお、リセット事前通知への応答を返した直後から実際にリセットが実行されるまでのメッセージをコントローラ２００に送信するように構成してもよい。実装が容易になるなどの理由でこれらのメッセージは送信されるが、何らの影響もコントローラ２００には与えない。
【００６０】
図６はこの実施の形態で用いられる送受信メッセージを示す説明図である。
【００６１】
ここで、リセット事前通知には、システムリセット通知フラグが併せて送信されるように構成されており、コントローラ２００と共にプリンタ１００のシステム全体がリセットされる場合には、その旨が通知されるようになっている。
【００６２】
このように、上記実施の形態１では、コントローラ２００が何らかの要因でリセットされる場合には、当該コントローラ２００からプリンタエンジン３００にリセット事前通知を送信し、当該プリンタエンジン３００からリセット事前通知の確認通知を受信してから、リセット動作を実行するように構成されている。そのため、コントローラ２００とプリンタエンジン３００との間で、リセット通知等の命令の通信が正常に行われたか否かを確実に判別することができ、命令等の通信の対応を維持することが可能となっている。
【００６３】
実施の形態２
この実施の形態２において、装置の基本構成は前記実施の形態１と同一であり、図７が当該実施の形態２の特徴部分を示すものであるが、前記実施の形態と同一の部分には同一の符号を付して説明すると、この実施の形態２では、互いに通信を行うことによって情報の交換を行う少なくとも第一の装置と第二の装置とを備え、少なくとも一方の装置が他方の装置と協調した動作を行うことにより、情報を処理する情報処理装置において、前記第一の装置は、特定の条件が生じたときに、当該第一の装置の動作状態を第二の動作状態に遷移させる遷移手段と、特定の条件が生じたことを第二の装置に通知する通知手段と、前記特定の条件が解消されたことを第二の装置に認識させる認識手段と、前記特定の条件が解消されたときに第二の動作状態にある前記第一の装置の状態を元の動作状態に復帰させる復帰手段と、を備えるように構成されている。
【００６４】
また、この実施の形態では、前記特定の条件とは、前記第一の装置がエラーを検知したことであるように構成されている。
【００６５】
さらに、この実施の形態では、前記特定の条件が生じたことを第二の装置に通知する手段は、第一の装置からの通知によるように構成されている。
【００６６】
又、この実施の形態では、前記特定の条件が解消したことを第二の装置が認識する手段は、第一の装置からの通知によるように構成されている。
【００６７】
更に、この実施の形態では、前記第二の動作状態に遷移している間は、一部の情報を処理せず無視するように構成されている。
【００６８】
すなわち、この実施の形態２に係るプリンタでは、エラーが発生したときの対応例を示すものである。
【００６９】
図７はエラーが発生したときにコントローラが行う動作の状態遷移図である。
【００７０】
コントローラ２００は、図７に示すように、始めに、通常処理状態（第一の動作状態）で動作するようになっている（ステップ３０１）。次に、コントローラ２００は、エラーが発生したことをプリンタエンジン３００から通知されると、エラー処理状態（第二の動作状態）に遷移する（ステップ３０２）。コントローラ２００は、エラーが発生している間に、ＵＩ（ユーザインターフェイス）などを利用してユーザに指示を出し、エラーを解消するための動作を実行する。ここでは、エラー解消の手段については、関係がないため、これ以上は述べない。また、コントローラ２００は、エラー処理状態の時に、別のエラーが新たに発生したとしても、エラー処理状態であることに変わりはなく、そのままエラー処理状態となる。一方、コントローラ２００は、ユーザによってエラーが解消されると、プリンタエシジン３００にエラーハンドリング状態を解除することを通知して、通常の処理状態に遷移する（ステップ３０１）。このとき、印刷が完了せずにプリンタエンジン３００が保持していたプリント指示については、全て破棄したとみなされるため、コントローラ２００は、新たにプリント指示からやり直すことになる。
【００７１】
図８はエラーが発生したときのプリンタエンジンの状態遷移図である。
【００７２】
図８において、通常動作状態（第一の状態）は、プリンタエンジン３００がプリント動作を行うことができる状態を意味している（ステップ４０１）。この状態で、プリンタエンジン３００にエラーが発生すると、当該プリンタエンジン３００は、図９に示すように、エラー発生通知をコントローラ２００に送信し、エラー発生中状態（第二の状態）に遷移する（ステップ４０２）。エラー発生中状態では、その後に新たなエラーが発生しても、エラー発生中状態であることに変わりはないので、状態の変化はない。また、プリンタエンジン３００では、エラー発生中状態において、エラーが解消されると、直ちに、通常動作状態には移行せずに、エラー解消通知をコントローラ２００に送信して、エラー解消済状態（第二の状態）に遷移する（ステップ４０３）。
【００７３】
エラー発生中状態とエラー解消済状態は、第二の状態としてのエラーハンドリング状態という状態の中の互いに異なったサブ状態である。つまり、エラーが解消しただけでは、図９に示すように、エラーハンドリング状態に留まっており、直ちに通常動作状態に戻ることはない。また、エラーハンドリング状態では、給紙トレイの選択切り替えなどの処理は実行されるが、コントローラ２００からの新たなプリント指示は、すべて無視される。上記プリンタエンジン３００は、エラー解消済状態の時に通知したエラー解消済通知に対するエラーハンドリング状態解除通知（図７参照）が、コントローラ２００から到来したときのみ通常動作状態に遷移する（ステップ４０１）。その際、上記プリンタエンジン３００は、エラー解消済状態の時に、エラー解消済通知を複数回送信した場合には、最後に通知したエラー解消済通知に対するエラーハンドリング状態解除通知が、コントローラ２００から到来したときのみ通常動作状態に遷移する（ステップ４０１）。
【００７４】
つまり、上記プリンタエンジン３００は、図８に示すように、エラー解消済状態の時に、新たにエラーが発生すると、エラー発生通知をコントローラ２００に送信して、再度エラー発生中状態に遷移する。そして、このエラー発生中状態においてエラーが解消されて、エラー解消済状態に遷移するときに、再度、エラー解消済通知がコントローラ２００に送信される場合がある。
【００７５】
その際、最後のエラー解消済通知に対するエラーハンドリング状態解除通知であることを識別するために、エラー解消済通知にＩＤ（識別符号）を付けて区別するか、エラー解消通知の数に応じただけのエラーハンドリング状態解除通知を受け取ることによって、最後のエラー解消済通知に対するエラーハンドリング状態解除通知を受領したことを識別するように構成されている。
【００７６】
エラーハンドリング状態から通常動作状態に遷移するときに、印刷が完了していないコントローラ２００からのプリント指示が存在する場合には、これらのプリント指示は破棄される。
【００７７】
このように、上記実施の形態２では、プリンタエンジン３００において、通常の動作状態でエラーが発生した場合には、コントローラ２００にその旨を通知するとともに、エラー発生状態に遷移する。さらに、上記プリンタエンジン３００では、エラーが解消された場合、コントローラ２００にその旨を通知するとともに、直ちに通常の動作状態に遷移せずに、サブ状態であるエラー解消済状態に遷移し、最後に通知したエラー解消済通知に対するエラーハンドリング状態解除通知が、コントローラ２００から到来したときのみ通常動作状態に遷移するように構成されている。
【００７８】
そのため、この実施の形態２では、プリンタエンジン３００がエラー解消済通知をコントローラ２００に送信した後、何らかの理由でエラーが発生した場合でも、コントローラ２００からエラー解消済通知に対するエラーハンドリング状態解除通知が到来するまでは、プリンタエンジン３００は、エラーハンドリング状態を維持するため、当該プリンタエンジン３００もコントローラ２００とともに、エラー状態が完全に解消していないことを知ることができ、コントローラ２００とプリンタエンジン３００との間で、プリント指示等の命令の通信が正常に行われたか否かを確実に判別することができ、命令等の通信の対応を維持することが可能となっている。
【００７９】
実施の形態３
この実施の形態３において、装置の基本構成は前記実施の形態１と同一であり、図１０が当該実施の形態３の特徴部分を示すものであるが、前記実施の形態と同一の部分には同一の符号を付して説明すると、この実施の形態３では、互いに通信を行うことによって情報の交換を行う少なくとも第一の装置と第二の装置とを備え、少なくとも一方の装置が他方の装置と協調した動作を行うことにより、情報を処理する情報処理装置において、前記第一の装置及び第二の装置は、一方の装置が動作可能であることを他方の装置に対して通知する動作可能通知手段と、前記一方の装置が他方の装置から動作可能である旨の通知を受けて、他方の装置が動作可能であることを確認すると、当該一方の装置が確認したことを他方の装置に応答する確認応答手段と、を備え、前記第一の装置又は第二の装置の少なくとも一方は、前記動作可能通知手段による動作確認通知を通知したか、又は前記確認応答手段による確認応答を受けたことの少なくとも一方を条件に、特定の動作状態に遷移するように制御する制御手段を備えるように構成されている。
【００８０】
また、この実施の形態３では、前記一方の装置が動作可能であるとは、当該一方の装置を制御するソフトウェアが動作を開始した状態であるように構成されている。
【００８１】
さらに、この実施の形態３では、前記特定の動作状態として、互いに異なる複数の動作状態が設定されているように構成されている。
【００８２】
又、この実施の形態３では、前記特定の動作状態は、動作確認通知を通知したか、又は前記確認応答手段による確認応答を受けたかによって、遷移すべき状態が異なるように構成されている。
【００８３】
図１０は制御モジュールの動作の状態遷移を示した状態図である。ここでは、特に動作開始に関する状態にのみ注目し、それ以外の状態は簡略化されている。
【００８４】
ここでは、説明の都合上、コントローラ２００のシステム制御モジュール２１１が動作を開始したとして説明するが、プリンタエンジン３００の制御モジュール３１１が動作を開始した場合も同様である。つまり、本発明においては、基本的に第一の装置と第二の装置の存在を前提とするが、コントローラ２００とプリンタエンジン３００のうち、いずれが第一の装置に該当し、いずれが第二の装置に該当するかは任意であり、コントローラ２００が第一の装置に該当する場合もあれば、プリンタエンジン３００が第一の装置に該当する場合もある。
【００８５】
図１０において、初期化状態は、システム制御モジュール２１１がモジュール起動時に必要な初期化を行っている状態である（ステップ５０１）。この初期化状態には、動作開始前に届いたメッセージなど、誤動作を起こす可能性がある不要なメッセージをクリアする動作も含まれている。そのため、初期化状態以前にコントローラ２００に届いたメッセージは、全て失われることになる。
【００８６】
次に、コントローラ２００は、初期化動作が終了すると、動作可能であることの通知をプリンタエンジン３００のエンジン制御モジュール３１１に送り、次の処理可能状態（特定の動作状態の１つ）に遷移する（ステップ５０２）。この処理可能状態では、プリンタエンジン３００からのメッセージを待つことになる。プリンタエンジン３００からのメッセージのうち、動作可能通知または確認応答を受信したときのみ、次の特定の動作状態の１つである暫定通常状態又は通常状態への遷移を行う。コントローラ２００が処理可能状態であるときに、動作可能通知を受信する状態は、例えば、図１１（ａ）に示すように、コントローラ２００が動作可能通知を送信した時点で、プリンタエンジン３００が動作可能でなかったために、コントローラ２００のメッセージが破棄された場合に生じる。この場合は、コントローラ２００が確認応答をプリンタエンジン３００に送信した後に、図１０に示す暫定通常状態に遷移する（ステップ５０３）。
【００８７】
一方、図１１（ｂ）に示すような場合は、コントローラ２００が動作可能通知を送信して、処理可能状態に遷移した後に、この動作可能通知に対する確認応答を受信することになる。この場合は、図１０に示すように、処理可能状態から通常状態に遷移する（ステップ５０４）。暫定通常状態と通常状態の違いは、プリンタエンジン３００からの確認応答の扱いの違いである。通常状態では、ソフトウェアにバグ等がない限り、確認応答を受信することはないため、確認応答を通常状態で受信した場合は、原則としてエラー扱いとなる。暫定通常状態の場合は、図１１（ｃ）に示すような状態が生じるため、確認応答を受信する可能性があるため、これを許容する。
【００８８】
更に説明すると、図１１（ｃ）に示す状態では、コントローラ２００が動作可能通知を送信して、処理可能状態に遷移した後に、プリンタエンジン３００からの動作可能通知を受け取って、暫定通常状態に遷移し、更にプリンタエンジン３００からの確認応答を受信しているため、通常状態に遷移している。
【００８９】
コントローラ２００は、図１０に示すように、状態が暫定通常状態であるときに、プリンタエンジン３００から制御に関する通常のメッセージを受信すると、メッセージ実行状態に遷移する（ステップ５０５）。このメッセージ実行状態は、通常のメッセージを実行している状態である。そして、上記メッセージの実行が終了すると、コントローラ２００は、通常状態に遷移する（ステップ５０４）。
【００９０】
また、コントローラ２００は、暫定通常状態で応答メッセージを受信すると、単に通常状態に遷移する（ステップ５０４）。通常状態は、プリント指示などの制御に関するメッセージの交換を行う状態である。そして、コントローラ２００は、新しいメッセージを受信する度に、メッセージ実行状態に遷移し、メッセージの処理が行われる（ステップ５０４、５０５）。
【００９１】
ところで、図１０に示す状態には、突然プリンタエンジン３００のエンジン制御モジュール３１２が初期化されて、始めから動作を開始した場合の状態も含まれる。エンジン制御モジュール３１１のメッセージ送信に関するサブモジュールなどの不具合により再起動の通知がコントローラ２００に通知できない場合もこれに該当する。
【００９２】
プリンタエンジン３００のエンジン制御モジュール３１２が初期化されたことは、プリンタエンジン３００から動作可能通知が送信されてくることで判断することができる。理論上、図１０に示すどの状態においても、動作可能通知が送信されてくる可能性があるが、初期化状態のときは単に無視されるだけであり、処理可能状態のときに受信した場合は、上述したように暫定通常状態に遷移する。メッセージ実行状態にあるときは、通常状態に復帰するまで受信メッセージが来たことを認識することができないため、メッセージの受信は、通常状態に遷移するまで遅延される。
【００９３】
従って、重要であるのは、図１２に示すように、暫定通常状態又は通常状態のときに動作可能通知を受信したときである。この場合は、図１０に示すように、どちらの状態のときも終了初期化状態に遷移する（ステップ５０６）。この終了初期化状態では、プリント動作を終了させる終了処理や、システムの状態を初期状態に戻すために必要な最低限の初期化などが行われる。たとえば、プリント処理が行われている場合では、プリント途中の用紙の排出やクリーニング動作、あるいはプリント指示を保持するキューのクリアなど、ＲＡＭ２０２等のワークエリアの初期化が行われる。終了初期化処理が終了すると、処理可能状態に遷移する（ステップ５０２）。このとき、コントローラ２００からプリンタエンジン３００ヘ動作可能通知が送信される。その後の処理は、通常の制御モジュール２１２の起動時と同様である。
【００９４】
更に説明すると、図１２（ａ）に示すように、コントローラ２００が通常の動作状態にあるときに、意図しない制御モジュールの再起動などによって、プリンタエンジン３００から動作可能通知が送られてくると、コントローラ２００は、終了初期化状態に遷移して、終了初期化処理を開始する。そして、コントローラ２００は、終了初期化処理が完了すると、処理可能状態に遷移すると共に動作可能通知を送信する。それに対してプリンタエンジン３００から確認応答を受信すると、通常状態に遷移するとともに、更に通常メッセージを受信すると、メッセージ実行状態に遷移して、メッセージを実行した後、通常状態に再度遷移する。
【００９５】
また、図１２（ｂ）では、図１２（ａ）と異なり、コントローラ２００が通常の動作状態にあるときに、意図しない制御モジュールの再起動などによって、プリンタエンジン３００から動作可能通知が送られてくると、コントローラ２００は、終了初期化状態に遷移して、終了初期化処理を開始する。そして、コントローラ２００は、終了初期化処理が完了すると、処理可能状態に遷移すると共に動作可能通知を送信する。この状態の時に意図しない制御モジュールの再起動などによって、プリンタエンジン３００から再度動作可能通知が送られてくると、コントローラ２００は、図１０に示すように、確認応答を送信し暫定通常状態に遷移する。
【００９６】
その後、コントローラ２００は、プリンタエンジン３００から動作可能通知に対する確認応答を受信すると、通常状態に遷移し、更に通常メッセージを受信すると、メッセージ実行状態に遷移して、メッセージを実行した後、通常状態に再度遷移する。
【００９７】
このように、上記実施の形態３では、例えば、コントローラ２００が動作確認通知を通知したか、又は確認応答を受けたかによって、初期化状態から処理可能状態、暫定通常状態、通常状態、メッセージ実行状態、終了初期化処理状態などに順次遷移するように構成されており、動作確認通知や確認応答等の命令とコントローラ２００の状態とが、常に一対一に対応しており、動作確認通知が正常に受信されていなかったり、動作確認通知と確認応答の到着が前後した場合などでも、各状態に応じて、適宜特定の動作状態に遷移して動作を実行することができ、コントローラ２００とプリンタエンジン３００との間で、命令等の通信の対応を維持することが可能となっている。
【図面の簡単な説明】
【００９８】
【図１】図１はこの発明の実施の形態１乃至３に係る情報処理装置としてのプリンタを示すブロック図である。
【図２】図２はこの発明の実施の形態１乃至３に係る情報処理装置を示す機能ブロック図である。
【図３】図３はこの発明の実施の形態１に係る情報処理装置の動作を示すフローチャートである。
【図４】図４はこの発明の実施の形態１に係る情報処理装置としてのプリンタの動作を示す説明図である。
【図５】図５はこの発明の実施の形態１に係る情報処理装置の動作を示す状態遷移図である。
【図６】図６は送受信に使用されるメッセージを示す説明図である。
【図７】図７はこの発明の実施の形態２に係る情報処理装置の動作を示す状態遷移図である。
【図８】図８はこの発明の実施の形態２に係る情報処理装置の動作を示す状態遷移図である。
【図９】図９はこの発明の実施の形態２に係る情報処理装置の動作を示す説明図である。
【図１０】図１０はこの発明の実施の形態３に係る情報処理装置の動作を示す状態遷移図である。
【図１１】図１１はこの発明の実施の形態３に係る情報処理装置の代表的なシーケンスを示す説明図である。
【図１２】図１２はこの発明の実施の形態３に係る情報処理装置の代表的なシーケンスを示す説明図である。
【図１３】図１３は従来技術におけるプリンタの動作を示す説明図である。
【図１４】図１４は従来技術におけるプリンタの動作を示す説明図である。
【図１５】図１５は従来技術におけるプリンタの動作を示す説明図である。
【符号の説明】
【００９９】
１００：プリンタ、２００：コントローラ、３００：プリンタエンジン、４００：通信回線。
【図１】
2005339341.tif 000003
【図２】
2005339341.tif 000004
【図３】
2005339341.tif 000005
【図４】
2005339341.tif 000006
【図５】
2005339341.tif 000007
【図６】
2005339341.tif 000008
【図７】
2005339341.tif 000009
【図８】
2005339341.tif 000010
【図９】
2005339341.tif 000011
【図１０】
2005339341.tif 000012
【図１１】
2005339341.tif 000013
【図１２】
2005339341.tif 000014
【図１３】
2005339341.tif 000015
【図１４】
2005339341.tif 000016
【図１５】
2005339341.tif 000017