JP2017159666A - 画像形成装置、画像形成方法、および、プログラム - Google Patents

Abstract

【課題】発生したエラーの影響を受けないジョブを保証する。
【解決手段】本発明に係る情報処理システムは、ユーザによる操作に応じた入力を受け付ける操作部と、操作部に搭載されたオペレーティングシステムとは異なるオペレーティングシステムが搭載され、操作部で受け付けた入力に応じて動作する本体と、を備える。本体は、実行中のアプリケーションに対応する画面の描画を指示するコマンドを生成する生成部と、コマンドを操作部に送信する制御を行うコマンド送信制御部と、を有する。操作部は、本体からコマンドを受信する受信部と、受信したコマンドに従って画面を描画する画面描画部と、画面描画部により描画された画面を表示する表示部と、本体とは非同期に操作部のみのリブートを行うリブート部と、を有する。
【選択図】図１

Description

本発明は、画像形成装置、画像形成方法、および、プログラムに関する。

従来、機器の故障時に、自動で機器のリブート（再起動）を実現する構成が知られている（例えば特許文献１、特許文献２）。

しかしながら、従来技術では、例えば動作中のジョブには影響が無いエラー（異常）が発生した場合であっても、自動的に機器本体がリブートされるので、動作中のジョブが保証されないという問題がある。

本発明は、上記に鑑みてなされたものであって、発生したエラーの影響を受けないジョブを保証することが可能な画像形成装置、画像形成方法、および、プログラムを提供することを目的とする。

上述した課題を解決し、目的を達成するために、本発明は、ユーザによる操作に応じた入力を受け付ける操作部と、前記操作部に搭載されたオペレーティングシステムとは異なるオペレーティングシステムが搭載され、前記操作部で受け付けた入力に応じて動作する本体と、を備え、前記本体は、実行中のアプリケーションに対応する画面の描画を指示するコマンドを生成する生成部と、前記コマンドを前記操作部に送信する制御を行うコマンド送信制御部と、を有し、前記操作部は、前記本体から前記コマンドを受信する受信部と、前記受信部で受信した前記コマンドに従って前記画面を描画する画面描画部と、前記画面描画部により描画された前記画面を表示する表示部と、前記本体とは非同期に前記操作部のみのリブートを行うリブート部と、を有し、前記操作部は、前記操作部に異常が発生した際に、前記リブート部によって前記操作部のみのリブートが実行され、前記操作部の前記表示部は、前記本体と接続して異常が解消した場合、前記本体で実行中のアプリケーションの前記異常の解消後の処理状況に応じた前記画面を表示する、画像形成装置である。

本発明によれば、発生したエラーの影響を受けないジョブを保証することができる。

図１は、ＭＦＰのハードウェア構成例を示す図である。 図２は、ＭＦＰのソフトウェア構成例を示す図である。 図３は、本体の機能構成例を示す図である。 図４は、操作部の機能構成例を示す図である。 図５は、ＭＦＰの動作手順の一例を示すシーケンス図である。 図６は、第２実施形態の本体の機能構成例を示す図である。 図７は、中断画面の一例を示す図である。 図８は、第２実施形態のＭＦＰの動作手順の一例を示すシーケンス図である。

以下、添付図面を参照しながら、本発明に係る情報処理システムの実施形態を詳細に説明する。以下では、本発明に係る情報処理システムを、複合機（ＭＦＰ：Multifunction Peripheral）に適用した場合を例に挙げて説明するが、これに限定されるものではない。なお、複合機とは、印刷機能、複写機能、スキャナ機能、及びファクシミリ機能のうち少なくとも２つの機能を有する装置である。

（第１実施形態）
図１は、本実施形態のＭＦＰ１のハードウェア構成例を示すブロック図である。図１に示すように、ＭＦＰ１は、コピー機能、スキャナ機能、ファクス機能、プリンタ機能などの各種の機能を実現可能な本体１０と、ユーザの操作に応じた入力を受け付ける操作部２０と、を備える。本体１０と操作部２０は、専用の通信路３００を介して相互に通信可能に接続されている。通信路３００は、例えばＵＳＢ（Universal Serial Bus）規格のものを用いることもできるが、有線か無線かを問わず任意の規格のものであってよい。

なお、本体１０は、操作部２０で受け付けた入力に応じた動作を行うことができる。また、本体１０は、クライアントＰＣ（パーソナルコンピュータ）等の外部装置とも通信可能であり、外部装置から受信した指示に応じた動作を行うこともできる。

次に、本体１０のハードウェア構成について説明する。図１に示すように、本体１０は、ＣＰＵ１１と、ＲＯＭ１２と、ＲＡＭ１３と、ＨＤＤ（ハードディスクドライブ）１４と、通信Ｉ／Ｆ（インタフェース）１５と、接続Ｉ／Ｆ１６と、エンジン部１７とを備え、これらがシステムバス１８を介して相互に接続されている。

ＣＰＵ１１は、本体１０の動作を統括的に制御する。ＣＰＵ１１は、ＲＡＭ１３をワークエリア（作業領域）としてＲＯＭ１２またはＨＤＤ１４等に格納されたプログラムを実行することで、本体１０全体の動作を制御し、上述したコピー機能、スキャナ機能、ファクス機能、プリンタ機能などの各種機能を実現する。

通信Ｉ／Ｆ１５は、クライアントＰＣ（パーソナルコンピュータ）等の外部装置と通信するためのインタフェースである。接続Ｉ／Ｆ１６は、通信路３００を介して操作部２０と通信するためのインタフェースである。

エンジン部１７は、コピー機能、スキャナ機能、ファクス機能、および、プリンタ機能を実現させるための、汎用的な情報処理及び通信以外の処理を行うハードウェアである。例えば、原稿の画像をスキャンして読み取るスキャナ（画像読取部）、用紙等のシート材への印刷を行うプロッタ（画像形成部）、ファクス通信を行うファクス部などを備えている。更に、印刷済みシート材を仕分けるフィニッシャや、原稿を自動給送するＡＤＦ（自動原稿給送装置）のような特定のオプションを備えることもできる。

次に、操作部２０のハードウェア構成について説明する。図１に示すように、操作部２０は、ＣＰＵ２１と、ＲＯＭ２２と、ＲＡＭ２３と、フラッシュメモリ２４と、通信Ｉ／Ｆ２５と、接続Ｉ／Ｆ２６と、操作パネル２７と、リセットスイッチ２８とを備え、これらがシステムバス２９を介して相互に接続されている。

ＣＰＵ２１は、操作部２０の動作を統括的に制御する。ＣＰＵ２１は、ＲＡＭ２３をワークエリア（作業領域）としてＲＯＭ２２またはフラッシュメモリ２４等に格納されたプログラムを実行することで、操作部２０全体の動作を制御し、ユーザから受け付けた入力に応じた情報（画像）の表示などの後述する各種機能を実現する。

通信Ｉ／Ｆ２５は、インターネットなどのネットワークを介してサーバ装置等の外部装置と通信するためのインタフェースである。接続Ｉ／Ｆ２６は、通信路３００を介して本体１０と通信するためのインタフェースである。

操作パネル２７は、ユーザの操作に応じた各種の入力を受け付けるとともに、各種の情報（例えばＭＦＰ１の動作状況を示す情報、設定状態などを示す情報など）を表示する。この例では、操作パネル２７は、タッチパネル機能を搭載した液晶表示装置（ＬＣＤ）で構成されるが、これに限られるものではない。例えばタッチパネル機能が搭載された有機ＥＬ表示装置で構成されてもよい。さらに、これに加えて又はこれに代えて、ハードウェアキー等の操作部やランプ等の表示部を設けることもできる。

リセットスイッチ２８は、操作部２０のみのリブート（再起動）の実行指示を入力するのに用いられる操作デバイスである。この例では、ユーザがリセットスイッチ２８の押下操作を行うと、操作部２０のみのリブートの実行指示が入力される。リセットスイッチ２８は、請求項の「入力デバイス」に対応しているが、請求項の「入力デバイス」の形態はこれに限られるものではない。

次に、ＭＦＰ１のソフトウェア構成について説明する。図２は、ＭＦＰ１のソフトウェア構成の一例を示す模式図である。図２に示すように、本体１０は、アプリ層１０１と、サービス層１０２と、ＯＳ層１０３とを有する。アプリ層１０１、サービス層１０２、および、ＯＳ層１０３の実体は、ＲＯＭ１２やＨＤＤ１４等に格納されている各種ソフトウェアである。ＣＰＵ１１が、これらのソフトウェアを実行することにより、各種の機能が提供される。

アプリ層１０１のソフトウェアは、ハードウェア資源を動作させて所定の機能を提供するためのアプリケーションソフトウェア（以下の説明では、単に「アプリ」あるいは「アプリケーション」と称する場合がある）である。例えばアプリケーションの種類としては、コピー機能を提供するためのコピーアプリ、スキャナ機能を提供するためのスキャナアプリ、ファクス機能を提供するためのファクスアプリ、プリンタ機能を提供するためのプリンタアプリなどが挙げられる。

サービス層１０２のソフトウェアは、アプリ層１０１とＯＳ層１０３との間に介在し、アプリケーションに対し、本体１０が備えるハードウェア資源を利用するためのインタフェースを提供するためのソフトウェアである。より具体的には、ハードウェア資源に対する動作要求の受付、動作要求の調停を行う機能を提供するためのソフトウェアである。サービス層１０２が受け付ける動作要求としては、スキャナによる読み取りやプロッタによる印刷等の要求が考えられる。

なお、サービス層１０２によるインタフェースの機能は、本体１０のアプリ層１０１だけではなく、操作部２０のアプリ層２０１に対しても提供される。すなわち、操作部２０のアプリ層２０１（アプリ）も、サービス層１０２のインタフェース機能を介して、本体１０のハードウェア資源（例えばエンジン部１７）を利用した機能を実現することができる。

ＯＳ層１０３のソフトウェアは、本体１０が備えるハードウェアを制御する基本機能を提供するための基本ソフトウェア（オペレーティングシステム）である。サービス層１０２のソフトウェアは、各種アプリからのハードウェア資源の利用要求を、ＯＳ層１０３が解釈可能なコマンドに変換してＯＳ層１０３に渡す。そして、ＯＳ層１０３のソフトウェアによりコマンドが実行されることで、ハードウェア資源は、アプリケーションの要求に従った動作を行う。

同様に、操作部２０は、アプリ層２０１と、サービス層２０２と、ＯＳ層２０３とを有する。操作部２０が備えるアプリ層２０１、サービス層２０２及びＯＳ層２０３も、階層構造については本体１０側と同様である。ただし、アプリ層２０１のアプリにより提供される機能や、サービス層２０２が受け付け可能な動作要求の種類は、本体１０側とは異なる。アプリ層２０１のアプリとしては、操作部２０が備えるハードウェア資源を動作させて所定の機能を提供するためのソフトウェアであってもよいが、主として、本体１０が備える機能（コピー機能、スキャナ機能、ファクス機能、プリンタ機能）に関する操作や表示を行うためのＵＩ（ユーザインタフェース）の機能を提供するためのソフトウェアが含まれる。

なお、本実施形態では、機能の独立性を保つために、本体１０側のＯＳ層１０３のソフトウェアと操作部２０側のＯＳ層２０３のソフトウェアが互いに異なる。つまり、本体１０と操作部２０は、別々のオペレーティングシステムで互いに独立して動作する。例えば、本体１０側のＯＳ層１０３のソフトウェアとしてＬｉｎｕｘ（登録商標）を用い、操作部２０側のＯＳ層２０３のソフトウェアとしてＡｎｄｒｏｉｄ（登録商標）を用いることも可能である。

また、本実施形態では、操作部２０に対する電力供給は、本体１０から通信路３００を経由して行われているので、操作部２０の電源制御を、本体１０の電源制御とは別に（独立して）行うことができる。

次に、ＭＦＰ１の機能構成について説明する。図３は、本体１０の機能構成例を示す図であり、図４は、操作部２０の機能構成例を示す図である。説明の便宜上、図３および図４では、本発明に係る機能を主に例示しているが、ＭＦＰ１が有する機能は、これらに限られるものではない。

まず本体１０側の機能について説明する。図３に示すように、本体１０は、通信部１１０と、生成部１２０と、コマンド送信制御部１３０と、第１検出部１４０と、描画抑制部１５０とを有する。

通信部１１０は、前述の通信路３００を介して操作部２０と通信する。

生成部１２０は、実行中のアプリケーションに対応する画面の描画を指示する描画コマンドを生成する。ここでは、「画面」とは、操作部２０（操作パネル２７）に表示すべき画像を指す。アプリケーションに対応する画面としては、そのアプリケーションの種類やそのアプリケーションの実行状況に応じて様々な形態を取り得る。例えば実行中のアプリケーションがプリンタアプリの場合、実行中のプリンタアプリに対応する画面としては、現在の印刷枚数を報知する画像を含む形態であってもよい。

コマンド送信制御部１３０は、描画コマンドを操作部２０に送信する制御を行う。より具体的には、コマンド送信制御部１３０は、生成部１２０により描画コマンドが生成されると、その生成された描画コマンドを操作部２０へ送信するよう、通信部１１０を制御する。なお、本実施形態における描画コマンドは、請求項の「コマンド」に対応している。

第１検出部１４０は、操作部２０との間の通信に異常が発生したか否かを検出する。本実施形態では、第１検出部１４０は、ＵＳＢのデタッチまたはＴＣＰ（Transmission Control Protocol）通信の切断が発生したか否かを検出することができる。

描画抑制部１５０は、第１検出部１４０により異常が検出された場合、操作部２０による画面の描画を抑制する制御（以下の説明では、「描画抑制制御」と称する場合がある）を行う。本実施形態では、描画抑制部１５０は、第１検出部１４０により異常が検出された場合、生成部１２０に対して描画コマンドの生成を停止することを指示するとともに、コマンド送信制御部１３０に対して描画コマンドを破棄することを指示する。なお、本実施形態では、操作部２０との間の通信に異常が発生しても（第１検出部１４０により異常が検出されても）、本体１０側で実行中のアプリケーション（例えばプリンタアプリ等）は、そのまま動作を継続する。

また、本実施形態では、第１検出部１４０により検出された異常が解消した場合、描画抑制部１５０は、操作部２０による画面の描画の抑制を解除（描画抑制制御を解除）する。より具体的には、操作部２０との間の通信が復旧した場合、描画抑制部１５０は、生成部１２０に対して描画コマンドの生成を再開することを指示するとともに、コマンド送信制御部１３０に対して、描画コマンドの送信を再開することを指示する。この指示を受けた生成部１２０は、実行中のアプリケーションの現在の状況に応じた画面の描画を指示する描画コマンドを生成し、コマンド送信制御部１３０は、生成部１２０により生成された描画コマンドを操作部２０へ送信する制御を行う。

例えば、本体１０側で実行中のアプリケーションがプリンタアプリであり、実行中のプリンタアプリに対応する画面は、現在の印刷枚数を報知する画像を含む場合を想定する。例えば現在の印刷枚数が「２０枚」のときに、第１検出部１４０により異常が検出された場合、実行中のプリンタアプリはそのまま動作を継続するが、上述の描画抑制制御により、実行中のプリンタアプリに対応する画面の生成は停止され、生成された描画コマンドは破棄される。その後、第１検出部１４０により検出された異常が解消した場合、描画抑制部１５０は、生成部１２０に対して描画コマンドの生成を再開することを指示する。この指示を受けた時点での印刷枚数が「５０枚」である場合、生成部１２０は、実行中のプリンタアプリの現在の状況に応じた画面として、現在の印刷枚数が「５０枚」であることを報知する画像を含む画面の描画を指示する描画コマンドを生成するという具合である。

以上に説明した通信部１１０、生成部１２０、コマンド送信制御部１３０、第１検出部１４０、および、描画抑制部１５０の各々の機能は、ＣＰＵ１１が、ＲＡＭ１３をワークエリア（作業領域）としてＲＯＭ１２またはＨＤＤ１４等に格納されたプログラムを実行することにより実現されるが、これに限らず、例えば本体１０の上記各部の機能のうちの少なくとも一部が専用のハードウェア回路（例えば半導体集積回路等）で実現されてもよい。

次に、操作部２０の機能について説明する。図４に示すように、操作部２０は、通信部２１０と、画面描画部２２０と、表示部２３０と、リブート部２４０とを有する。

通信部２１０は、前述の通信路３００を介して本体１０と通信する。例えば通信部２１０は、本体１０から送信される描画コマンドを受信することもできる。この例では、通信部２１０は、請求項の「受信部」に対応している。

画面描画部２２０は、本体１０から受信した描画コマンドに従って画面を描画する。表示部２３０は、画面描画部２２０により描画された画面を表示する。より具体的には、表示部２３０は、画面描画部２２０により描画された画面を操作パネル２７に表示する制御を行う。

リブート部２４０は、本体１０とは非同期に操作部２０のみのリブートを行う。本実施形態では、リブート部２４０は、ユーザによるリセットスイッチ２８の操作に応じて、操作部２０のみのリブートの実行を指示する入力を受け付けた場合、操作部２０のみのリブートを実行する。より具体的には、ユーザがリセットスイッチ２８の押下操作を行うと、操作部２０のみのリブートの実行指示が入力される。そして、この実行指示の入力を受け付けた場合、リブート部２４０は、操作部２０のみのリブートを実行する。

以上に説明した通信部２１０、画面描画部２２０、表示部２３０、および、リブート部２４０の各々の機能は、ＣＰＵ２１が、ＲＡＭ２３をワークエリア（作業領域）としてＲＯＭ２２またはフラッシュメモリ２４等に格納されたプログラムを実行することにより実現されるが、これに限らず、例えば操作部２０の上記各部の機能のうちの少なくとも一部が専用のハードウェア回路（例えば半導体集積回路等）で実現されてもよい。

次に、本実施形態に係るＭＦＰ１の動作例を説明する。図５は、本実施形態に係るＭＦＰ１の動作手順の一例を示すシーケンス図である。なお、図５に例示した操作部２０における「描画アプリ」は、前述の画面描画部２２０に対応していると捉えることもできる。説明の便宜上、図５では、操作部２０のサービス層２０２や他のアプリの図示を省略している。

まず、ユーザが不図示の電源スイッチの押下操作を行うと、ＭＦＰ１に対する電力の供給が開始されて、本体１０側のＯＳ層１０３が起動する。起動したＯＳ層１０３は、サービス層１０２に対して起動指示を出力する（ステップＳ１）。また、起動したＯＳ層１０３は、操作部２０側のＯＳ層２０３に対して起動信号を出力する（ステップＳ２）。なお、この例では、操作部２０側のＯＳ層２０３は、本体１０側のＯＳ層１０３からの起動信号を受け付けて起動しているが、これに限らず、例えば操作部２０側のＯＳ層２０３は、電源スイッチの押下操作により開始される電力の供給を受けることで起動する形態であってもよい。

本体１０からの起動信号を受け付けて起動した操作部２０側のＯＳ層２０３は、描画アプリに対して起動指示を出力する（ステップＳ３）。次に、本体１０側のＯＳ層１０３と操作部２０側のＯＳ層２０３との間でＵＳＢ接続が行われる（ステップＳ４）。本体１０側のＯＳ層１０３は、ＵＳＢ接続を検出すると、その旨をサービス層１０２に通知する（ステップＳ５）。この通知を受けたサービス層１０２は、ＯＳ層１０３に対してＴＣＰ接続を要求する（ステップＳ６）。また、操作部２０側のＯＳ層２０３は、ＵＳＢ接続を検出すると、その旨を描画アプリに通知する（ステップＳ７）。この通知を受けた描画アプリは、ＯＳ層２０３に対してＴＣＰ接続を要求する（ステップＳ８）。そして、本体１０側のＯＳ層１０３と操作部２０側のＯＳ層２０３との間でＴＣＰ接続が行われる（ステップＳ９）。

上述のステップＳ３の起動指示を受け付けて起動した描画アプリが、動作可能な状態になった場合、描画アプリは、ＯＳ層２０３に対して動作可能であることを通知する（ステップＳ１０）。以下の説明では、描画アプリが動作可能な状態であることを「操作部レディ」、描画アプリが動作不能な状態であることを「操作部Ｎｏｔレディ」と称する場合がある。この通知を受けたＯＳ層２０３は、本体１０側のＯＳ層１０３に対して、操作部レディを通知する（ステップＳ１１）。そして、本体１０側のＯＳ層１０３は、アプリ層１０１に対して操作部レディを通知する（ステップＳ１２）。

操作部レディの通知を受けたアプリ層１０１（生成部１２０）は、前述の描画コマンドを生成する。そして、アプリ層１０１（コマンド送信制御部１３０）は、ＯＳ層１０３に対して描画コマンドの通知を依頼する（ステップＳ１３）。この依頼を受けたＯＳ層１０３は、操作部２０側のＯＳ層２０３に対して、描画コマンドを通知する（ステップＳ１４）。操作部２０側のＯＳ層２０３は、描画アプリに対して、本体１０から送信されてきた描画コマンドを通知し（ステップＳ１５）、描画アプリは、通知された描画コマンドに従って画面を描画する（ステップＳ１６）。

その後、図５の例では、操作部２０のストール、通信異常等によりＴＣＰ通信またはＵＳＢ通信が切断されることが想定されている（ステップＳ１７）。ＵＳＢ通信またはＴＣＰ通信が切断された場合、本体１０側のＯＳ層１０３（第１検出部１４０）は、ＵＳＢのデタッチまたはＴＣＰ通信の切断を検出する（ステップＳ１８）。そして、ＯＳ層１０３は、サービス層１０２に対して、操作部２０との間の通信に異常が発生したことを通知する（ステップＳ１９）。この通知を受けたサービス層１０２は、アプリ層１０１に対して、操作部Ｎｏｔレディを通知する（ステップＳ２０）。

操作部Ｎｏｔレディの通知を受けたアプリ層１０１（描画抑制部１５０）は、前述の描画抑制制御を行う（ステップＳ２１）。より具体的には、前述したように、描画抑制部１５０は、生成部１２０に対して描画コマンドの生成を停止することを指示するとともに、コマンド送信制御部１３０に対して描画コマンドを破棄することを指示する。一方、操作部２０（操作パネル２７）に表示された画面は、異常が発生する直前の画面のままフリーズした状態となるので、これを見たユーザは、何らかの異常が発生したと判断し、リセットスイッチ２８の押下操作を行う（ステップＳ２２）。これにより操作部２０のみのリブートの実行指示が入力され、実行指示の入力を受け付けたリブート部２４０は、操作部２０のみのリブートを実行する。

操作部２０のみのリブートが完了すると、最初の起動時と同様に、本体１０側のＯＳ層１０３と操作部２０側のＯＳ層２０３との間でＵＳＢ接続およびＴＣＰ接続が行われる（ステップＳ２３〜ステップＳ２８）。そして、再起動した描画アプリが、動作可能な状態になった場合、描画アプリは、ＯＳ層２０３に対して動作可能であることを通知する（ステップＳ２９）。この通知を受けたＯＳ層２０３は、本体１０側のＯＳ層１０３に対して、操作部レディを通知する（ステップＳ３０）。そして、本体１０側のＯＳ層１０３は、アプリ層１０１に対して操作部レディを通知する（ステップＳ３１）。

上述のステップＳ３１における操作部レディの通知を受けたアプリ層１０１（描画抑制部１５０）は、描画抑制制御を解除する（ステップＳ３２）。より具体的には、前述したように、描画抑制部１５０は、生成部１２０に対して描画コマンドの生成を再開することを指示するとともに、コマンド送信制御部１３０に対して、描画コマンドの送信を再開することを指示する。この指示を受けた生成部１２０は、実行中のアプリケーションの現在の状況に応じた画面の描画を指示する描画コマンドを生成する。そして、コマンド送信制御部１３０は、ＯＳ層１０３に対して、生成部１２０により生成された描画コマンドの通知を依頼する（ステップＳ３３）。この依頼を受けたＯＳ層１０３は、操作部２０側のＯＳ層２０３に対して、描画コマンドを通知する（ステップＳ３４）。操作部２０側のＯＳ層２０３は、描画アプリに対して、本体１０から送信されてきた描画コマンドを通知し（ステップＳ３５）、描画アプリは、通知された描画コマンドに従って画面を描画する（ステップＳ３６）。このとき本体１０から通知される描画コマンドは、実行中のアプリケーションの現在の状況に応じた画面の描画を指示する描画コマンドであるので、リブート直後の画面として、実行中のアプリケーションの現在の状況に応じた画面を提示することができる。

以上に説明したように、本実施形態では、操作部２０は、本体１０とは非同期に操作部２０のみのリブートを行う機能（リブート部２４０）を有しているので、例えば操作部２０のストール、通信異常等によりＴＣＰ通信またはＵＳＢ通信が切断され、操作部２０に表示される画面がフリーズ状態になった場合、ユーザは、操作部２０のみのリブートを実行させるためにリセットスイッチ２８の押下操作を行う。つまり、ＭＦＰ１全体の電源をＯＦＦする必要は無く、操作部２０と同期して本体１０がリブートされることも無いので、操作部２０との間の通信異常の影響を受けない本体１０側のアプリケーションの実行を継続することができる。つまり、発生した異常（エラー）の影響を受けない本体１０側のアプリケージョンのジョブを保証することができる。

また、上述したように、本体１０側の描画抑制部１５０は、操作部２０との間の通信異常が検出された場合、操作部２０による画面の描画を抑制する制御（「描画抑制制御」）を行うので、操作部２０との間の通信異常が解消したときに、不要な描画コマンドが操作部２０に通知されることを確実に防止できる。

（第２実施形態）
次に、第２実施形態について説明する。以下の説明では、第２実施形態に係る本体を、「本体１００」と表記する。第２実施形態に係る本体１００は、第１検出部１４０により異常が検出された場合、実行中のアプリケーションの動作を中断する中断処理を行う中断処理部をさらに備える点で上述の第１実施形態と相違する。以下、具体的な内容を説明する。なお、上述の第１実施形態と共通する部分については適宜に説明を省略する。

図６は、本体１００の機能構成例を示す図である。図６に示すように、本体１００は、中断処理部１６０と、記憶部１７０とをさらに有する。記憶部１７０は、アプリケーションの種別ごとに、中断処理を実行するか否かを示す実行可否情報を対応付けて記憶する。

中断処理部１６０は、第１検出部１４０により異常が検出された場合、実行中のアプリケーションに対応する実行可否情報が中断処理を実行することを示す場合は中断処理を実行する。一方、実行中のアプリケーションに対応する実行可否情報が中断処理を実行しないことを示す場合は、中断処理部１６０は中断処理を実行しない。より具体的には、中断処理部１６０は、第１検出部１４０により異常が検出された場合、記憶部１７０に記憶された複数の実行可否情報のうち、実行中のアプリケーションに対応する実行可否情報を読み出す。そして、中断処理部１６０は、読み出した実行可否情報が中断処理を実行することを示す場合は中断処理を実行する。一方、読み出した実行可否情報が中断処理を実行しないことを示す場合は、中断処理部１６０は中断処理を実行しない。

なお、例えば記憶部１７０が設けられない構成とすることもできる。この構成では、中断処理部１６０は、第１検出部１４０により異常が検出された場合、実行中のアプリケーションの種別を問わず無条件に中断処理を実行する。

また、本実施形態では、上述の中断処理が実行されている状況で、第１検出部１４０により検出された異常が解消した場合、描画抑制部１５０は画面抑制制御を解除し、生成部１２０は、アプリケーションの動作が中断中である旨を報知する画面を示す中断画面の描画を指示する描画コマンドを生成する。図７は、中断画面の一例を示す図である。図７の例では、中断画面は、アプリケーションの動作が中断中である旨を示す画像に加えて、中断中のアプリケーションの動作を継続するかキャンセルするかの選択を促す画像を含んでいる。この例では、中断画面を見たユーザは、中断中のアプリケーションの動作の継続を選択することもできるし、キャンセルを選択することもできる。中断中のアプリケーションの動作の継続を選択する入力を受け付けた場合、本体１００は、中断中のアプリケーションの動作を継続する。一方、中断中のアプリケーションのキャンセルを選択する入力を受け付けた場合、本体１００は、中断中のアプリケーションの実行を破棄する。なお、中断画面の形態は、図７の例に限られるものではない。例えば中断画面は、中断中のアプリケーションの動作を継続するかキャンセルするかの選択を促す画像を含まない形態であってもよい。

次に、本実施形態に係るＭＦＰの動作例を説明する。図８は、本実施形態に係るＭＦＰの動作手順の一例を示すシーケンス図である。図８では、上述の中断処理に関する部分以外の上述の第１実施形態と共通する部分については適宜図示を省略している。以下、中断処理に関する部分を中心に説明する。

図８に示すステップＳ２１（図５に示すステップＳ２１の内容と同様）における描画抑制制御の後、アプリ層１０１（中断処理部１６０）は、記憶部１７０に記憶された複数の実行可否情報のうち、実行中のアプリケーションに対応する実行可否情報を読み出し、読み出した実行可否情報に応じて、中断処理を実行するか否かを決定する。図８の例では、実行中のアプリケーションに対応する実行可否情報は中断処理を実行することを示す場合を想定しており、アプリ層１０１（中断処理部１６０）は、中断処理を実行する（ステップＳ４０）。その後、ステップＳ３２（図５に示すステップＳ３２の内容と同様）までの流れは、上述の第１実施形態と同様である。

図８に示すステップＳ３２において、上述の第１実施形態と同様に、アプリ層１０１（描画抑制部１５０）は、描画抑制制御を解除する。より具体的には、前述したように、描画抑制部１５０は、生成部１２０に対して描画コマンドの生成を再開することを指示するとともに、コマンド送信制御部１３０に対して、描画コマンドの送信を再開することを指示する。この指示を受けた生成部１２０は、中断画面の描画を指示する描画コマンドを生成する。そして、コマンド送信制御部１３０は、ＯＳ層１０３に対して、生成部１２０により生成された中断画面の描画を指示する描画コマンドの通知を依頼する（ステップＳ４１）。この依頼を受けたＯＳ層１０３は、操作部２０側のＯＳ層２０３に対して、その描画コマンドを通知することになり（図５に示すステップＳ３４と同様の内容）、その後の流れは、上述の第１実施形態と同様である。

以上、本発明に係る実施形態について説明したが、本発明は、上述の実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上述の実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。

例えば上述の各実施形態では、リセットスイッチ２８の押下操作を契機として、操作部２０のみのリブートが行われている（手動操作によりリブートが実行されている）が、これに限らず、例えば操作部２０は、操作部で異常が発生したか否かを検出する第２検出部をさらに備え、リブート部２４０は、第２検出部により異常が検出された場合、操作部２０のみのリブートを自動的に実行する形態であってもよい。この形態では、上述のリセットスイッチ２８は不要となる。

（プログラム）
上述した実施形態のＭＦＰ１で実行されるプログラムは、インストール可能な形式または実行可能な形式のファイルでＣＤ−ＲＯＭ、フレキシブルディスク（ＦＤ）、ＣＤ−Ｒ、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ）、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）等のコンピュータで読み取り可能な記録媒体に記録して提供するように構成してもよいし、インターネット等のネットワーク経由で提供または配布するように構成してもよい。また、各種プログラムを、ＲＯＭ等に予め組み込んで提供するように構成してもよい。

１ ＭＦＰ
１０ 本体
２０ 操作部
１１０ 通信部
１２０ 生成部
１３０ コマンド送信制御部
１４０ 第１検出部
１５０ 描画抑制部
１６０ 中断処理部
１７０ 記憶部
２１０ 通信部
２２０ 画面描画部
２３０ 表示部
２４０ リブート部

特開２００４−１５２０１０号公報 特開２００５−２１９２４７号公報

Claims (12)

1. ユーザによる操作に応じた入力を受け付ける操作部と、
   前記操作部に搭載されたオペレーティングシステムとは異なるオペレーティングシステムが搭載され、前記操作部で受け付けた入力に応じて動作する本体と、を備え、
   前記本体は、
   実行中のアプリケーションに対応する画面の描画を指示するコマンドを生成する生成部と、
   前記コマンドを前記操作部に送信する制御を行うコマンド送信制御部と、を有し、
   前記操作部は、
   前記本体から前記コマンドを受信する受信部と、
   前記受信部で受信した前記コマンドに従って前記画面を描画する画面描画部と、
   前記画面描画部により描画された前記画面を表示する表示部と、
   前記本体とは非同期に前記操作部のみのリブートを行うリブート部と、を有し、
   前記操作部は、前記操作部に異常が発生した際に、前記リブート部によって前記操作部のみのリブートが実行され、
   前記操作部の前記表示部は、前記本体と接続して異常が解消した場合、前記本体で実行中のアプリケーションの異常の解消後の処理状況に応じた前記画面を表示する、
   画像形成装置。
2. 前記本体で実行中の前記アプリケーションがプリンタアプリであり、前記本体が印刷を実行している場合、
   前記操作部の前記表示部は、
   異常が発生している時は印刷枚数を表示せず、
   前記リブート部によって前記操作部のみのリブートが実行された後に前記本体と再接続して異常が解消した場合、異常の解消後の印刷枚数を表示する、
   請求項１に記載の画像形成装置。
3. 前記本体と前記操作部はＵＳＢで接続され、
   前記表示部は、
   前記ＵＳＢのデタッチが検出された場合、前記本体で実行中のアプリケーションの処理状況に応じた前記画面を表示せず、前記デタッチ後、前記本体と前記操作部との接続が検出されて異常が解消した場合、前記ＵＳＢを介して前記本体から送信された前記コマンドに基づいて、異常の解消後の印刷枚数を表示する、
   請求項１または請求項２に記載の画像形成装置。
4. 前記本体は、
   前記操作部との間の通信に異常が発生したか否かを検出する第１検出部と、
   前記第１検出部により異常が検出された場合、前記操作部による前記画面の描画を抑制する制御を行う描画抑制部と、を有し、
   前記操作部は、
   前記第１検出部により検出された異常が解消した場合、前記描画抑制部は、前記操作部による前記画面の描画の抑制を解除し、前記生成部は、前記本体で実行中のアプリケーションの現在の処理状況に応じた前記画面の描画を指示する前記コマンドを生成する、
   請求項１乃至３のうちの何れか１項に記載の画像形成装置。
5. 前記描画抑制部は、前記第１検出部により異常が検出された場合、前記生成部に対して前記コマンドの生成を停止することを指示するとともに、前記コマンド送信制御部に対して前記コマンドを破棄することを指示する、
   ことを特徴とする請求項４に記載の画像形成装置。
6. 前記本体は、
   前記第１検出部により異常が検出された場合、実行中のアプリケーションの動作を中断する中断処理を行う中断処理部をさらに備える、
   ことを特徴とする請求項４または請求項５に記載の画像形成装置。
7. アプリケーションの種別ごとに、前記中断処理を実行するか否かを示す実行可否情報を対応付けて記憶する記憶部をさらに備え、
   前記中断処理部は、前記第１検出部により異常が検出された場合、実行中のアプリケーションに対応する前記実行可否情報が前記中断処理を実行することを示す場合は前記中断処理を実行する一方、前記実行可否情報が前記中断処理を実行しないことを示す場合は前記中断処理を実行しない、
   ことを特徴とする請求項６に記載の画像形成装置。
8. 前記中断処理が実行されている状況で、前記第１検出部により検出された異常が解消した場合、前記描画抑制部は、前記操作部による前記画面の描画の抑制を解除し、前記生成部は、アプリケーションの動作が中断中である旨を報知する前記画面を示す中断画面の描画を指示する前記コマンドを生成する、
   ことを特徴とする請求項６または請求項７に記載の画像形成装置。
9. 前記操作部は、
   前記操作部のみのリブートの実行指示を入力するのに用いられる操作デバイスをさらに備え、
   前記ユーザによる前記操作デバイスの操作に応じて、前記操作部のみのリブートの実行を指示する入力を受け付けた場合、前記リブート部は、前記操作部のみのリブートを実行する、
   請求項１乃至８のうちの何れか１項に記載の画像形成装置。
10. 前記操作部は、
    前記操作部で異常が発生したか否かを検出する第２検出部をさらに備え、
    前記リブート部は、前記第２検出部により異常が検出された場合、前記操作部のみのリブートを自動的に実行する、
    請求項１乃至８のうちの何れか１項に記載の画像形成装置。
11. ユーザによる操作に応じた入力を受け付けると共に、該入力に応じて動作する本体に搭載されたオペレーティングシステムとは異なるオペレーティングシステムが搭載された、操作部が実行する画像形成方法であって、
    前記本体から実行中のアプリケーションに対応する画面の描画を指示するコマンドを受信する受信ステップと、
    受信した前記コマンドに従って前記画面を描画する画面描画ステップと、
    描画された前記画面を表示部に表示する表示ステップと、
    前記本体とは非同期に前記操作部のみのリブートを行うリブートステップと、
    を含み、
    前記リブートステップは、前記操作部に異常が発生した際に前記操作部のみのリブートを実行し、
    前記表示ステップは、前記本体と接続して異常が解消した場合、前記本体で実行中のアプリケーションの異常の解消後の処理状況に応じた前記画面を表示する、
    画像形成方法。
12. ユーザによる操作に応じた入力を受け付けると共に、該入力に応じて動作する本体に搭載されたオペレーティングシステムとは異なるオペレーティングシステムが搭載された、操作部に搭載されたコンピュータに、
    前記本体から実行中のアプリケーションに対応する画面の描画を指示するコマンドを受信する受信ステップと、
    受信した前記コマンドに従って前記画面を描画する画面描画ステップと、
    描画された前記画面を表示部に表示する表示ステップと、
    前記本体とは非同期に前記操作部のみのリブートを行うリブートステップと、
    を実行させるためのプログラムであって、
    前記リブートステップは、前記操作部に異常が発生した際に前記操作部のみのリブートを実行し、
    前記表示ステップは、前記本体と接続して異常が解消した場合、前記本体で実行中のアプリケーションの異常の解消後の処理状況に応じた前記画面を表示する、
    プログラム。

Images