JP2014241494A - 情報処理システム、情報処理方法およびプログラム - Google Patents

Abstract

【課題】本体機器の機能を利用したアプリケーションの開発工数を低減可能な情報処理システム、情報処理方法およびプログラムを提供する。【解決手段】エラー画面が予め対応付けられたメーカアプリと、エラー画面が対応付けられていないベンダーアプリとが搭載されたＭＦＰは、表示部と異常検知部と描画部と制御部とを備える。表示部は、表示対象のアプリケーションの画面を表示する。異常検知部は、ＭＦＰで発生したエラーを検知する。描画部は、エラーが検知された場合、メーカアプリの画面に対して、その検知されたエラーを報知するエラー画面を描画する。制御部は、ベンダーアプリの動作中にエラーが検知された場合、表示対象のアプリを、ベンダーアプリからメーカアプリに切り替えて、エラー画面を表示する制御を行う。【選択図】図１

Description

本発明は、情報処理システム、情報処理方法およびプログラムに関する。

従来、機器本体を設計して製造する企業（以下、本明細書では「メーカ」と称する場合がある）以外の、機器本体に関するソフトウェアやハードウェアを提供する企業（以下、本明細書では「ベンダー」と称する場合がある）が、メーカ側から提供される本体機器の機能を利用して、特定の業務に特化したアプリを作成して顧客に提供する技術が知られている。例えば特許文献１には、アプリ開発者の負担を軽減することを目的として、ジョブが発生したエラーを検知した場合、リカバリ依頼を請け負ったジョブであるか否かを判別し、リカバリ依頼を請け負ったジョブである場合、そのエラーのリカバリ処理を行う機能（エラーリカバリーサービス）をアプリ開発者に対して提供する技術が開示されている。

ここで、メーカ側で開発するアプリケーション（以下、本明細書では「メーカアプリ」と称する場合がある）については、本体機器で発生するエラーのうちユーザに通知する必要があるエラーを報知するエラー画面が予め対応付けられており、メーカアプリの実行中に、ユーザに通知する必要があるエラーが本体機器で発生した場合、そのエラーを報知するエラー画面が表示される仕組みになっている。ここで、ベンダー側で開発するアプリケーション（以下、本明細書では「ベンダーアプリ」と称する場合がある）についても、エラー画面を予め対応付けておくことにすると、ベンダー側でも、ユーザへの通知が必要なエラーの種別ごとにエラー画面を開発する必要があるため、ベンダー側の開発工数が増大するという問題が起こる。

本発明は、上記に鑑みてなされたものであって、本体機器の機能を利用したアプリケーションの開発工数を低減可能な情報処理システム、情報処理方法およびプログラムを提供することを目的とする。

上述した課題を解決し、目的を達成するために、本発明は、エラーを報知するエラー画面が予め対応付けられた第１アプリケーションと、前記エラー画面が対応付けられていない第２アプリケーションとが搭載された情報処理システムであって、表示対象のアプリケーションの画面を表示する表示部と、前記情報処理システムで発生した前記エラーを検知する異常検知部と、前記エラーが検知された場合、前記第１アプリケーションの画面に対して、その検知された前記エラーを報知する前記エラー画面を描画する描画部と、前記第２アプリケーションの動作中に前記エラーが検知された場合、表示対象のアプリケーションを、前記第２アプリケーションから前記第１アプリケーションに切り替えて、前記エラー画面を表示する制御を行う制御部と、を備える情報処理システムである。

本発明によれば、本体機器の機能を利用したアプリケーションの開発工数を低減することが可能になる。

図１は、ＭＦＰの概略構成例を示す図である。 図２は、ＭＦＰのハードウェア構成例を示す図である。 図３は、ＭＦＰのソフトウェア構成例を示す図である。 図４は、操作部の機能構成例を示す図である。 図５は、操作部にインストール済みのアプリの起動手順の一例を示すシーケンス図である。 図６は、ベンダーアプリの動作中にＭＦＰでエラーが発生した場合における画面切替の動作手順の一例を示すシーケンス図である。 図７は、操作部に表示されたシンプルコピーアプリ画面の一例を示す図である。 図８は、コピーアプリ画面にエラー画面を重畳させた画面の一例を示す図である。 図９は、本体で発生したエラーが解消した場合における画面切替の動作手順の一例を示すシーケンス図である。 図１０は、エラー画面が非表示になったときの表示画面の一例を示す図である。 図１１は、画面切替が行われたときの画面タスク状態の遷移を示す模式図である。 図１２は、第２実施形態に係る操作部の機能構成例を示す図である。 図１３は、対応情報の一例を示す模式図である。 図１４は、変形例に係る操作部の機能構成例を示す図である。

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

（第１実施形態）
図１は、本実施形態のＭＦＰ１の概略構成例を示す図である。図１に示すように、ＭＦＰ１は、コピー機能、スキャナ機能、ファクス機能、プリンタ機能などの各種の機能を実現可能な本体１０と、ユーザの操作に応じた入力を受け付ける操作部２０と、を備える。本実施形態において、ベンダーアプリ開発者は、ＭＦＰ１に対して、自身が作成したアプリ（ベンダーアプリ）のインストールとアンインストールが可能である。

本実施形態では、例えばＭＦＰ１の起動直後においては、各種のアプリごとに対応するアイコンが表示されるホーム画面が操作部２０に表示される。例えばユーザが、ホーム画面に表示された複数のアイコンのうちベンダーアプリに対応するアイコンを選択する操作（例えばタッチ操作）を行うと、ベンダーアプリが起動してベンダーアプリの画面が操作部２０に表示される。ここでは、ＭＦＰ１に搭載されたベンダーアプリは、ＭＦＰ１の設定を変更するためのインタフェースとして機能するＡＰＩ（Application Programming Interface）を利用したアプリケーションであり、その種類や数は任意に変更可能である。例えばＭＦＰ１が提供するコピー機能の各種の設定のうちの一部の設定（例えば色、用紙サイズ、部数などの設定）を変更するためのＡＰＩを利用したアプリケーションが、ベンダーアプリとしてＭＦＰ１に搭載（インストール）されていてもよい。

なお、本実施形態では、メーカアプリについては、ＭＦＰ１で発生したエラー（異常）を報知するエラー画面が予め対応付けられている一方、ベンダーアプリについては、エラー画面が対応付けられていない。この例では、メーカアプリは請求項の「第１アプリケーション」に対応し、ベンダーアプリは、請求項の「第２アプリケーション」に対応しているが、これに限られるものではない。

次に、ＭＦＰ１の具体的なハードウェア構成を説明する。図２は、ＭＦＰ１のハードウェア構成例を示すブロック図である。図２に示すように、ＭＦＰ１は、本体１０と操作部２０とを備え、これらが専用の通信路３０を介して相互に通信可能に接続されている。通信路３０は、例えばＵＳＢ（Universal Serial Bus）規格のものを用いることもできるが、有線か無線かを問わず任意の規格のものであってよい。

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

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

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

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

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

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

ＣＰＵ２１は、操作部２０の動作を統括的に制御する。ＣＰＵ２１は、ＲＡＭ２３をワークエリア（作業領域）としてＲＯＭ２２またはフラッシュメモリ２４等に格納されたプログラムを実行することで、操作部２０全体の動作を制御し、本体１０が備える機能（コピー機能、スキャナ機能、ファクス機能、プリンタ機能）に関する操作や表示を行うためのＵＩ（ユーザインタフェース）機能などの各種の機能を実現する。

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

操作パネル２７は、ユーザの操作に応じた各種の入力を受け付けるとともに、各種の画像を表示する。以下の説明では、操作パネル２７に表示される画像を「画面」と称する場合がある。この例では、操作パネル２７は、タッチパネル機能を搭載した液晶表示装置（ＬＣＤ）で構成されるが、これに限られるものではない。例えばタッチパネル機能が搭載された有機ＥＬ表示装置で構成されてもよい。さらに、これに加えて又はこれに代えて、ハードウェアキー等の操作部やランプ等の表示部を設けることもできる。

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

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

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

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

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

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

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

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

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

図４に示すように、操作部２０は、ユーザ操作イベント受信部２１０と、メーカアプリ管理部２２０と、ベンダーアプリ管理部２３０と、アプリ情報管理部２４０と、アプリ画面制御部２５０と、表示部２６０と、イベント送受信部２７０と、異常検知部２８０と、保持部２９０と、検索部３００と、アプリ動作制御部３１０とを有する。

ユーザ操作イベント受信部２１０は、操作部２０に対するユーザ操作イベントを受信する。例えばユーザ操作イベント受信部２１０は、操作パネル２７に対するユーザのタッチ操作に応じた入力を受け付ける。この例では、ユーザ操作イベント受信部２１０は、請求項の「受付部」に対応する。

メーカアプリ管理部２２０は、ＭＦＰ１にインストールされたメーカアプリを記憶する。ベンダーアプリ管理部２３０は、ＭＦＰ１にインストールされたベンダーアプリを記憶する。アプリ情報管理部２４０は、ＭＦＰ１へのアプリ（メーカアプリ、ベンダーアプリ）のインストール／アンインストールの管理を行う。また、アプリ情報管理部２４０は、アプリ情報（メーカアプリ管理部２２０、および、ベンダーアプリ管理部２３０の各々に記憶されたアプリ）の管理を行う。

アプリ画面制御部２５０は、アプリ動作制御部３１０からの要求に応じて、ＭＦＰ１で動作するアプリケーションの画面を描画する。図４では、説明の便宜上、１つのアプリ画面制御部２５０のみが例示されているが、本実施形態では、操作部２０に搭載された複数種類のアプリケーションと１対１に対応する複数のアプリ画面制御部２５０が設けられている。アプリ画面制御部２５０の詳細な動作については後述する。

表示部２６０は、操作部２０で動作するアプリケーションのうち表示対象のアプリケーションの画面を表示する。本実施形態では、表示部２６０は、アプリ画面制御部２５０からの要求に応じて、アプリ画面制御部２５０で描画された画面を、操作パネル２７に表示する制御を行う。表示部２６０の詳細な動作については後述する。

イベント送受信部２７０は、本体１０との間でイベント情報の送受信を行う。例えば本体１０から送信されてくるイベント情報には、本体１０で発生したエラーを示す情報や、発生したエラーが解消されたことを示す情報などが含まれる。

異常検知部２８０は、ＭＦＰ１で発生したエラーを検知する。本実施形態では、異常検知部２８０は、イベント送受信部２７０で受信したイベント情報に基づいて、本体１０で発生したエラーを検知する。また、異常検知部２８０は、イベント送受信部２７０で受信したイベント情報に基づいて、本体１０で発生したエラーが解消されたことを検知する。

保持部２９０は、エラーの種別ごとに、エラー画面の元となる画面情報を対応付けて保持する。検索部３００は、保持部２９０で保持された複数の画面情報の中から、異常検知部２８０で検知されたエラーに対応する画面情報を検索する。

アプリ動作制御部３１０は、制御部３１１と、割り当て部３１２とを含む。制御部３１１は、ＭＦＰ１で動作するアプリの切り替え制御を行う。本実施形態では、制御部３１１は、ベンダーアプリの動作中に、異常検知部２８０によりエラーが検知された場合、表示対象のアプリケーションを、ベンダーアプリからメーカアプリに切り替えて、エラー画面を表示する制御を行う。また、制御部３１１は、異常検知部２８０により検知されたエラーが解消された場合、表示対象のアプリケーションを、ベンダーアプリに切り替える。

割り当て部３１２は、ＭＦＰ１にインストールされた複数のアプリのうちの何れか１つのアプリの選択を指示する入力をユーザ操作イベント受信部２１０で受け付けた場合に、選択が指示されたアプリケーションに対してのみ画面操作権を割り当てる。アプリ動作制御部３１０の詳細な動作については後述する。

以上に説明したユーザ操作イベント受信部２１０、メーカアプリ管理部２２０、ベンダーアプリ管理部２３０、アプリ情報管理部２４０、アプリ画面制御部２５０、表示部２６０、イベント送受信部２７０、異常検知部２８０、検索部３００、および、アプリ動作制御部３１０（制御部３１１、割り当て部３１２）の各々の機能は、ＣＰＵ２１が、ＲＡＭ２３をワークエリア（作業領域）としてＲＯＭ２２またはフラッシュメモリ２４等に格納されたプログラムを実行することにより実現されるが、これに限らず、例えば操作部２０の上記各部の機能のうちの少なくとも一部が専用のハードウェア回路（例えば半導体集積回路等）で実現されてもよい。また、上述の保持部２９０は、ＲＯＭ２２やフラッシュメモリ２４等により実現可能である。

次に、操作部２０にインストール済みのアプリの起動について説明する。図５は、操作部２０にインストール済みのアプリの起動手順の一例を示すシーケンス図である。この例では、まずユーザは、ホーム画面に表示された複数のアイコンのうち、選択対象のアプリに対応するアイコンをタッチする操作を行う。これにより、ユーザ操作イベント受信部２１０は、そのタッチ操作に応じた入力を受け付ける。見方を変えれば、ユーザ操作イベント受信部２１０は、何れかのアプリの選択を指示する入力を受け付けていると考えることもできる。そして、ユーザ操作イベント受信部２１０は、アプリ動作制御部３１０に対して、ユーザ操作イベントを通知する（ステップＳ１）。この例では、ユーザ操作イベント受信部２１０は、ユーザにより選択されたアイコンを示すアイコン情報を、アプリ動作制御部３１０へ通知する。

次に、アプリ動作制御部３１０は、アプリ情報管理部２４０に対して、ユーザ操作イベント受信部２１０から通知されたアイコン情報に対応するアプリ（アプリ情報）を要求する（ステップＳ２）。この要求を受けたアプリ情報管理部２４０は、メーカアプリ管理部２２０およびベンダーアプリ管理部２３０の各々に格納されたアプリの中から、要求されたアプリを読み出してアプリ動作制御部３１０へ送信する（ステップＳ３）。次に、アプリ動作制御部３１０は、アプリ情報管理部２４０から取得したアプリに対して、起動指示を出力する（ステップＳ４）。また、アプリ動作制御部３１０（割り当て部３１２）は、アプリ情報管理部２４０から取得したアプリ（つまり、選択が指示されたアプリ）に対してのみ画面操作権を割り当てる。

アプリ動作制御部３１０からの起動指示を受けて起動したアプリは、アプリ動作制御部３１０に対して、当該アプリの画面（当該アプリが保持している画面と捉えることもできる）の描画を要求する。この要求を受けたアプリ動作制御部３１０は、起動したアプリに対応するアプリ画面制御部２５０に対して、アプリ画面の描画を要求する（ステップＳ５）。この要求を受けたアプリ画面制御部２５０は、アプリ画面の描画を行う（ステップＳ６）。アプリ画面の描画が完了すると、アプリ画面制御部２５０は、表示部２６０に対して、描画したアプリ画面の表示を要求する（ステップＳ７）。この要求を受けた表示部２６０は、アプリ画面制御部２５０により描画されたアプリ画面を、操作パネル２７上に表示する制御を行う（ステップＳ８）。

以上の起動シーケンスは、メーカアプリであるかベンダーアプリであるかを問わない（同じ起動シーケンスとなる）。なお、メーカアプリは、ＭＦＰ１起動時に自動的に起動されるので、アイコンのタッチ操作による明示的な指示がなく、操作部２０の最前面に表示されていない場合でも常に起動はしている。

次に、ベンダーアプリの動作中にＭＦＰ１でエラーが発生した場合における画面切替の動作手順を説明する。図６は、この場合のシーケンス図である。ここでは、操作部２０には、メーカアプリとして、ＭＦＰ１が提供するコピー機能に関する全ての操作を行うためのＵＩ機能を提供することが可能な「コピーアプリ」が搭載されているとともに、ベンダーアプリとして、ＭＦＰ１が提供するコピー機能の各種の設定のうちの一部の設定（例えば色、用紙サイズ、部数などの設定）を変更するためのＡＰＩを利用した「シンプルコピーアプリ」が搭載されているものとする。

以下の説明では、シンプルコピーアプリの動作中に、コピー機能に関するエラーが本体１０で発生する場面を想定して説明する。なお、以下の説明では、コピーアプリに対応するアプリ画面制御部２５０を「メーカアプリ画面制御部２５０ａ」と称し、シンプルコピーアプリに対応するアプリ画面制御部２５０を「ベンダーアプリ画面制御部２５０ｂ」と称して説明する。この例では、メーカアプリ画面制御部２５０ａは、請求項の「描画部」に対応しているが、これに限られるものではない。

図６の例では、まずユーザは、ホーム画面に表示された複数のアイコンのうち、シンプルコピーアプリに対応するアイコンをタッチする操作を行う。これにより、ユーザ操作イベント受信部２１０は、そのタッチ操作に応じた入力を受け付ける。そして、ユーザ操作イベント受信部２１０は、アプリ動作制御部３１０に対して、ユーザ操作イベントを通知する（ステップＳ１０）。この例では、ユーザ操作イベント受信部２１０は、ユーザにより選択されたアイコンとして、シンプルコピーアプリに対応するアイコンを示すアイコン情報を、アプリ動作制御部３１０へ通知する。

次に、アプリ動作制御部３１０は、アプリ情報管理部２４０に対して、ユーザ操作イベント受信部２１０から通知されたアイコン情報に対応するシンプルコピーアプリ（アプリ情報）を要求する（ステップＳ１１）。この要求を受けたアプリ情報管理部２４０は、ベンダーアプリ管理部２３０に格納されたアプリの中から、要求されたシンプルコピーアプリを読み出してアプリ動作制御部３１０へ送信する（ステップＳ１２）。次に、アプリ動作制御部３１０は、アプリ情報管理部２４０から取得したシンプルコピーアプリに対して、起動指示を出力する（ステップＳ１３）。また、アプリ動作制御部３１０（割り当て部３１２）は、アプリ情報管理部２４０から取得したシンプルコピーアプリに対してのみ画面操作権を割り当てる。

アプリ動作制御部３１０からの起動指示を受けて起動したシンプルコピーアプリは、アプリ動作制御部３１０に対して、当該シンプルコピーアプリの画面（以下、「シンプルコピーアプリ画面」と称する場合がある）の描画を要求する。この要求を受けたアプリ動作制御部３１０は、起動したシンプルコピーアプリに対応するベンダーアプリ画面制御部２５０ｂに対して、シンプリコピーアプリ画面の描画を要求する（ステップＳ１４）。この要求を受けたベンダーアプリ画面制御部２５０ｂは、シンプルコピーアプリ画面の描画を行う（ステップＳ１５）。シンプルコピーアプリ画面の描画が完了すると、ベンダーアプリ画面制御部２５０ｂは、表示部２６０に対して、描画したシンプルコピーアプリ画面の表示を要求する（ステップＳ１６）。この要求を受けた表示部２６０は、ベンダーアプリ画面制御部２５０ｂにより描画されたシンプルコピーアプリ画面を、操作パネル２７上に表示する制御を行う（ステップＳ１７）。図７は、操作部２０に表示されたシンプルコピーアプリ画面の一例を示す図である。

図６に戻って説明を続ける。上述のステップＳ１７の後、本体１０で非同期に発生するエラーは、イベント送受信部２７０から異常検知部２８０を経由してアプリ動作制御部３１０へ通知される。図６の例では、コピー機能に関するエラーが本体１０で発生した場合、イベント送受信部２７０は、本体１０で発生したエラーを示すイベント情報を本体１０から受信する。そして、イベント送受信部２７０は、本体１０で発生したエラーを示すイベント情報を、異常検知部２８０へ通知する（ステップＳ１８）。この通知を受けた異常検知部２８０は、通知されたイベント情報に基づいて、本体１０で発生したエラーを検知する（ステップＳ１９）。そして、異常検知部２８０は、本体１０でエラーが発生したこと、および、発生したエラーの種別を示す情報を含むエラー情報を、動作中のシンプルコピーアプリへ通知する（ステップＳ２０）。図６では、エラー情報の通知先はアプリ動作制御部３１０であるように図示されているが、ここでは、エラー情報の通知先は、画面操作権を有するシンプルコピーアプリである。なお、これに限らず、例えばアプリ動作制御部３１０が、ＭＦＰ１にインストールされた各アプリの動作を制御する場合は、図６のとおりにエラー情報の通知先をアプリ動作制御部３１０としてもよい。

エラー情報の通知を受けたシンプルコピーアプリは、エラーを報知するエラー画面が対応付けられていない（つまり、エラー画面を保持していない）ので、アプリ動作制御部３１０に対して、表示対象のアプリケーションを、各種のエラー画面が予め対応付けられたメーカアプリに切り替えることを依頼するとともに、本体１０で発生したエラーの種別を示す情報を通知する。この依頼を受けたアプリ動作制御部３１０は、コピー機能に関する各種のエラー画面が予め対応付けられたコピーアプリに対応するメーカアプリ画面制御部２５０ａに対して、エラー画面の描画を要求する（ステップＳ２１）。また、このとき、アプリ動作制御部３１０は、メーカアプリ画面制御部２５０ａに対して、本体１０で発生したエラーの種別を示す情報も通知する。

アプリ動作制御部３１０からの要求（エラー画面の描画要求）を受けたメーカアプリ画面制御部２５０ａは、検索部３００に対して、本体１０で発生したエラーに対応する画面情報の検索を要求する（ステップＳ２２）。この要求（画面情報の検索要求）を受けた検索部３００は、保持部２９０に記憶された複数の画面情報のうち、本体１０で発生したエラーに対応する画面情報を検索し（ステップＳ２３）、本体１０で発生したエラーに対応する画面情報を取得する（ステップＳ２４）。そして、検索部３００は、検索により取得した画面情報を、メーカアプリ画面制御部２５０ａへ送信する（ステップＳ２５）。

次に、検索部３００から画面情報を取得したメーカアプリ画面制御部２５０ａは、コピーアプリの画面（コピーアプリ画面）に対して、取得した画面情報に基づくエラー画面を描画する（ステップＳ２６）。より具体的には、メーカアプリ画面制御部２５０ａは、取得した画面情報に基づくエラー画面がコピーアプリ画面に重畳するように描画する。図８は、コピーアプリ画面にエラー画面を重畳させた画面の一例を示す図である。なお、前述したように、ＭＦＰ１の起動時にメーカアプリは自動的に起動するので、メーカアプリ画面制御部２５０ａは、既にコピーアプリ画面の描画を完了している。

図６に戻って説明を続ける。エラー画面の描画が完了すると、メーカアプリ画面制御部２５０ａは、エラー画面の描画結果をアプリ動作制御部３１０に通知する（ステップＳ２７）。この通知を受けたアプリ動作制御部３１０は、表示するアプリ（表示対象のアプリケーション）を切り替える（ステップＳ２８）。この例では、アプリ動作制御部３１０は、表示するアプリを、シンプルコピーアプリ（ベンダーアプリ）からコピーアプリ（メーカアプリ）に切り替える。そして、アプリ動作制御部３１０は、メーカアプリ画面制御部２５０ａに対して、コピーアプリ画面の描画を要求する（ステップＳ２９）。この要求を受けたメーカアプリ画面制御部２５０ａは、既にコピーアプリ画面の描画を完了しているので、表示部２６０に対して、ステップＳ２６で描画した画面（コピーアプリ画面にエラー画面を重畳させた画面）の表示を要求する（ステップＳ３０）。この要求を受けた表示部２６０は、コピーアプリ画面にエラー画面を重畳させた画面を、操作パネル２７上に表示する制御を行う（ステップＳ３１）。

次に、以上の画面切替が行われた後に、本体１０で発生したエラーが解消した場合における画面切替の動作手順を説明する。図９は、この場合のシーケンス図である。本体１０で発生したエラーが解消した場合、イベント送受信部２７０は、本体１０で発生したエラーが解消されたことを示すイベント情報を本体１０から受信する。そして、イベント送受信部２７０は、本体１０で発生したエラーが解消されたことを示すイベント情報を、異常検知部２８０へ通知する（ステップＳ４０）。この通知を受けた異常検知部２８０は、通知されたイベント情報に基づいて、本体１０で発生したエラーが解消されたことを検知する（ステップＳ４１）。そして、異常検知部２８０は、本体１０で発生したエラーが解消されたことを示すエラー解除情報を、画面操作権を有するシンプルコピーアプリに対して通知する（ステップＳ４２）。図９では、エラー解除情報の通知先はアプリ動作制御部３１０であるように図示されているが、ここでは、エラー解除情報の通知先は、画面操作権を有するシンプルコピーアプリである。なお、これに限らず、例えばアプリ動作制御部３１０が、ＭＦＰ１にインストールされた各アプリの動作を制御する場合は、図９のとおりにエラー解除情報の通知先をアプリ動作制御部３１０としてもよい。

エラー解除情報の通知を受けたシンプルコピーアプリは、アプリ動作制御部３１０に対して、表示対象のアプリケーションを、シンプルコピーアプリに切り替えることを依頼する。この依頼を受けたアプリ動作制御部３１０は、メーカアプリ画面制御部２５０ａに対して、エラー画面の破棄を要求する（ステップＳ４３）。この要求を受けたメーカアプリ画面制御部２５０ａは、コピーアプリ画面に重畳されていたエラー画面を破棄する（ステップＳ４４）。これにより、図１０に示すように、コピーアプリ画面の上に表示されていたエラー画面が非表示となる。

図９に戻って説明を続ける。エラー画面の破棄が完了すると、メーカアプリ画面制御部２５０ａは、エラー画面の破棄結果をアプリ動作制御部３１０に通知する（ステップＳ４５）。この通知を受けたアプリ動作制御部３１０は、表示するアプリを切り替える（ステップＳ４６）。この例では、アプリ動作制御部３１０は、表示するアプリを、コピーアプリからシンプルコピーアプリに切り替える。そして、アプリ動作制御部３１０は、ベンダーアプリ画面制御部２５０ｂに対して、シンプルコピーアプリ画面の描画を要求する（ステップＳ４７）。この要求を受けたベンダーアプリ画面制御部２５０ｂは、シンプルコピープリ画面の描画を既に完了しているので、表示部２６０に対して、図６のステップＳ１５で描画したシンプルコピーアプリ画面の表示を要求する（ステップＳ４８）。

図１１は、図６および図９に示す画面切替が行われたときの画面タスク状態の遷移を示す模式図である。この例では、図１１の左側に位置するアプリほど画面タスクの順位（表示優先度）が高くなることを表している。本実施形態では、アプリ動作制御部３１０は、画面操作権を有するアプリ（この例ではシンプルコピーアプリ）からの表示切替の依頼のみを受け付ける。これにより、表示切替の依頼の競合が発生することを防止している。また、本実施形態では、異常検知部２８０は、本体１０で発生したエラーを検知した場合、そのときに画面操作権を有するアプリ（この例ではシンプルコピーアプリ）に対してのみエラー情報を通知し、本体１０で発生したエラーが解消されたことを検知した場合、そのときに画面操作権を有するアプリ（この例ではシンプルコピーアプリ）に対してのみエラー解除情報を通知する。

なお、本実施形態では、アプリ動作制御部３１０は、複数のアプリが画面タスク内に存在する場合でも、画面操作権が割り当てられるアプリはただ１つのアプリとなるように管理する。また、本実施形態では、アプリ動作制御部３１０（割り当て部３１２）は、画面操作権を有するアプリがジョブ実行中でないときに限り、他のアプリに対して画面操作権を割り当てることができる。他のアプリに対して画面操作権が割り当てられた場合、それまでに画面操作権を保持していたアプリは、画面操作権を失うことになる。

以上に説明したように、本実施形態では、エラー画面が対応付けられていないベンダーアプリ（例えばシンプルコピーアプリ）の動作中に、本体１０で発生したエラーが検知された場合、各種のエラー画面が予め対応付けられたメーカアプリの画面上に、その検知されたエラーを報知するエラー画面が描画される。そして、表示対象のアプリが、ベンダーアプリからメーカアプリ（例えばコピーアプリ）に切り替えられることにより、メーカアプリの画面上に描画されたエラー画面が表示される。したがって、本実施形態によれば、ベンダーアプリの開発者はエラー画面を開発する必要が無いので、ＭＦＰ１の機能を利用したアプリケーションの開発工数を低減することが可能になる。

（第２実施形態）
次に、第２実施形態について説明する。本実施形態では、ベンダーアプリの動作中に、ＭＦＰ１（本体１０）でエラーが発生した場合、エラーの種別ごとに、エラー画面への表示切替を行うべきベンダーアプリの種類を対応付けた対応情報に基づいて、エラー画面への表示切替を行うか否かを判断する点で上述の第１実施形態と相違する。以下、具体的な内容を説明する。なお、上述の第１実施形態と共通する部分については適宜に説明を省略する。

図１２は、第２実施形態に係る操作部２０００の機能構成例を示す図である。図１２に示すように、操作部２０００は、対応情報記憶部３２０をさらに有する点で上述の第１実施形態と相違する。対応情報記憶部３２０は、例えばＲＯＭ２２やフラッシュメモリ２４等により実現可能である。

対応情報記憶部３２０は、ＭＦＰ１で発生するエラーの種別ごとに、エラー画面への表示切替を行うべきベンダーアプリの種類を対応付けた対応情報を記憶する。図１３は、対応情報の一例を示す模式図である。例えば第５行目の「プロッタカバーオープン」を示すエラーの種別に対しては、コピー系の機能を提供するためのベンダーアプリ、および、ファクス系の機能を提供するためのベンダーアプリは、エラー画面への表示切替を行う必要があることを示す情報が対応付けられているとともに（コピー系「○」、ファクス系「○」）、スキャナ系の機能を提供するためのベンダーアプリは、エラー画面への表示切替を行う必要はないことを示す情報が対応付けられている（スキャナ系「−」）ことが示されている。見方を変えれば、第５行目の「プロッタカバーオープン」を示すエラーの種別に対しては、エラー画面への表示切替を行うべきベンダーアプリの種類として、コピー系の機能を提供するためのベンダーアプリと、ファクス系の機能を提供するためのベンダーアプリとが対応付けられていると捉えることもできる。他の行についても同様に考えることができる。

ここで、第１実施形態と同様に、ベンダーアプリの動作中に本体１０でエラーが発生すると、異常検知部２８０は、本体１０で発生したエラーを検知し、前述のエラー情報を、動作中のベンダーアプリに通知する。本実施形態では、この通知を受けたベンダーアプリは、エラー情報が示すエラーの種別と、対応情報記憶部３２０に記憶された対応情報とに基づいて、エラー画面の表示切替を行うか否かを判断する。より具体的には、エラー情報の通知を受けたベンダーアプリは、対応情報記憶部３２０に記憶された対応情報に含まれるエラーの種別のうち、エラー情報が示すエラーの種別に対応する（一致する）エラーの種別を特定し、特定したエラー種別に対応付けられた情報（エラー画面への表示切替を行うべきベンダーアプリの種類を示す情報）を参照して、当該ベンダーアプリ（エラー情報の通知を受けたベンダーアプリ）が、エラー画面への表示切替を行うべきベンダーアプリに該当するか否かを判断する。

エラー情報の通知を受けたベンダーアプリは、自身が、エラー画面への表示切替を行うべきベンダーアプリに該当すると判断した場合は、エラー画面の表示切替を行うと判断し、アプリ動作制御部３１０に対して、表示するアプリの切り替えを依頼する。一方、エラー情報の通知を受けたベンダーアプリは、自身が、エラー画面への表示切替を行うべきベンダーアプリに該当しないと判断した場合は、エラー画面への表示切替を行わないと判断し、アプリ動作制御部３１０に対して、表示するアプリの切り替えを依頼しない。したがって、アプリ動作制御部３１０（制御部３１１）は、エラー情報の通知を受けたベンダーアプリによりエラー画面への表示切替を行うと判断された場合は、エラー画面への表示切替を行う一方、エラー情報の通知を受けたベンダーアプリによりエラー画面への表示切替を行わないと判断された場合は、エラー画面への表示切替を行わない。

本実施形態では、ベンダーアプリの動作中にエラーが検知された場合、前述の対応情報に基づいて、エラー画面への表示切替を行うか否かを判断する機能（請求項の「判断部」に対応）をベンダーアプリが有しているが、これに限らず、例えば図１４に示すように、アプリ動作制御部３１０が、判断部３１３をさらに有する形態であってもよい。この形態では、第１実施形態と同様に、異常検知部２８０からのエラー情報の通知を受けたベンダーアプリは、アプリ動作制御部３１０に対して、表示対象のアプリを切り替えることを依頼するとともに、本体１０で発生したエラーの種別を示す情報を通知する。そして、判断部３１３は、エラー情報の通知を受けたベンダーアプリから、表示対象のアプリの切替依頼とともに、本体１０で発生したエラーの種別を示す情報を受け付けた場合、受け付けたエラーの種別と、対応情報記憶部３２０に記憶された対応情報とに基づいて、エラー画面への表示切替を行うか否かを判断する。そして、制御部３１１は、判断部３１３によりエラー画面への表示切替を行うと判断された場合は、エラー画面への表示切替を行う一方、判断部３１３によりエラー画面への表示切替を行わないと判断された場合は、エラー画面への表示切替を行わない。

要するに、操作部２０００は、ベンダーアプリの動作中にエラーが検知された場合、対応情報に基づいて、エラー画面への表示切替を行うか否かを判断する判断部をさらに備える形態であればよい。

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

（変形例）
以下、変形例を記載する。以下の変形例同士は任意に組み合わせることもできる。また、以下の変形例は、上述の各実施形態と任意に組み合わせることもできる。

（１）変形例１
上述の各実施形態では、アプリ動作制御部３１０（制御部３１１）は、画面操作権を有するベンダーアプリ（例えばシンプルコピーアプリ）の動作中に、本体１０で発生したエラーが検知された場合、表示対象のアプリケーションを、ベンダーアプリからメーカアプリに切り替え、その検知されたエラーが解消された場合、表示対象のアプリを、画面操作権を有するベンダーアプリに切り替えているが、これに限らず、例えば制御部３１１は、異常検知部２８０により検知されたエラーが解消されたときに、エラー画面とは異なる画面であって、画面操作権を有するベンダーアプリの画面よりも表示優先度の高い画面（例えばホーム画面）が表示されている場合は、表示対象のアプリを、画面操作権を有するベンダーアプリに切り替えることはしない形態であってもよい。

例えば前述のシンプルコピーアプリ（ベンダーアプリの一例）を使用してコピーを実行中に、本体１０で紙詰まり（エラー）が発生したために、ユーザは別の操作を行うことを目的として、操作部２０のホームボタン（不図示）を押下した場面を想定する。ホームボタンの押下により、操作部２０に表示される画面はホーム画面に戻るので、画面タスク内の１番上（表示優先度が最も高い画面）はホーム画面となる。その後、紙詰まりが解消されると、エラー解除情報がシンプルコピーアプリに通知され、アプリ動作制御部３１０（制御部３１１）は、画面操作権を有するシンプルコピーアプリから、表示対象のアプリの切替依頼を受けるが、画面操作権を有するシンプルコピーアプリの画面よりも表示優先度が高いホーム画面が表示されているため、制御部３１１は、表示対象のアプリを、シンプルコピーアプリに切り替えることはしない。これにより、ユーザに対して呈示される画面が、ユーザの意思とは無関係に、現在ユーザが必要としていない画面（この例ではシンプルコピーアプリ画面）に勝手に切り替わってしまうことを防止できる。

（２）変形例２
上述の各実施形態では、本体１０と操作部２０（２０００）は、別々のオペレーティングシステムで互いに独立して動作しているが、これに限らず、例えば本体１０と操作部２０（２０００）が同じオペレーティングシステムで動作する形態であってもよい。

（３）変形例３
上述の操作部２０（２０００）に搭載された各部の機能は、操作部２０（２０００）と、本体１０とに適宜に分散されて搭載されてもよい。

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

１ ＭＦＰ
１０ 本体
２０ 操作部
３０ 通信路
２１０ ユーザ操作イベント受信部
２２０ メーカアプリ管理部
２３０ ベンダーアプリ管理部
２４０ アプリ情報管理部
２５０ アプリ画面制御部
２６０ 表示部
２７０ イベント送受信部
２８０ 異常検知部
２９０ 保持部
３００ 検索部
３１０ アプリ動作制御部
３１１ 制御部
３１２ 割り当て部
３１３ 判断部
３２０ 対応情報記憶部

特開２００５−１５３２１８号公報

Claims (8)

1. エラーを報知するエラー画面が予め対応付けられた第１アプリケーションと、前記エラー画面が対応付けられていない第２アプリケーションとが搭載された情報処理システムであって、
   表示対象のアプリケーションの画面を表示する表示部と、
   前記情報処理システムで発生した前記エラーを検知する異常検知部と、
   前記エラーが検知された場合、前記第１アプリケーションの画面に対して、その検知された前記エラーを報知する前記エラー画面を描画する描画部と、
   前記第２アプリケーションの動作中に前記エラーが検知された場合、表示対象のアプリケーションを、前記第２アプリケーションから前記第１アプリケーションに切り替えて、前記エラー画面を表示する制御を行う制御部と、を備える、
   情報処理システム。
2. 前記エラーの種別ごとに、画面情報を対応付けて保持する保持部と、
   前記エラーが検知された場合、前記保持部に記憶された複数の前記画面情報の中から、検知された前記エラーに対応する前記画面情報を検索する検索部と、をさらに備え、
   前記描画部は、前記第１アプリケーションの画面に対して、前記検索部により検索された前記画面情報に基づく前記エラー画面を描画する、
   請求項１に記載の情報処理システム。
3. 前記エラーの種別ごとに、前記エラー画面への表示切替を行うべき前記第２アプリケーションの種類を対応付けた対応情報を記憶する対応情報記憶部と、
   前記第２アプリケーションの動作中に前記エラーが検知された場合、前記対応情報に基づいて、前記エラー画面への表示切替を行うか否かを判断する判断部と、をさらに備え、
   前記制御部は、前記判断部により前記エラー画面への表示切替を行うと判断された場合は、前記エラー画面への表示切替を行う一方、前記判断部により前記エラー画面への表示切替を行わないと判断された場合は、前記エラー画面への表示切替を行わない、
   請求項１または請求項２に記載の情報処理システム。
4. 前記第１アプリケーションおよび前記第２アプリケーションを含む複数のアプリケーションのうち何れか１つのアプリケーションの選択を指示する入力を受け付ける受付部と、
   選択が指示されたアプリケーションに対してのみ画面操作権を割り当てる割り当て部と、をさらに備える、
   請求項１乃至３のうちの何れか１項に記載の情報処理システム。
5. 前記制御部は、前記画面操作権を有する第２アプリケーションの動作中に前記エラーが検知された場合、表示対象のアプリケーションを、前記第２アプリケーションから前記第１アプリケーションに切り替え、その検知された前記エラーが解消された場合、表示対象のアプリケーションを、前記第２アプリケーションに切り替える、
   請求項４に記載の情報処理システム。
6. 前記制御部は、前記異常検知部により検知された前記エラーが解消されたときに、前記エラー画面とは異なる画面であって、前記画面操作権を有する前記第２アプリケーションの画面よりも表示優先度の高い画面が表示されている場合は、表示対象のアプリケーションを、前記第２アプリケーションに切り替えることはしない、
   請求項５に記載の情報処理システム。
7. エラーを報知するエラー画面が予め対応付けられた第１アプリケーションと、前記エラー画面が対応付けられていない第２アプリケーションとが搭載された情報処理システムが実行する情報処理方法であって、
   表示対象のアプリケーションの画面を表示する表示ステップと、
   前記情報処理システムで発生したエラーを検知する異常検知ステップと、
   前記エラーが検知された場合、前記第１アプリケーションの画面に対して、その検知された前記エラーを報知する前記エラー画面を描画する描画ステップと、
   前記第２アプリケーションの動作中に前記エラーが検知された場合、表示対象のアプリケーションを、前記第２アプリケーションから前記第１アプリケーションに切り替えて、前記エラー画面を表示する制御を行う制御ステップと、を含む、
   情報処理方法。
8. エラーを報知するエラー画面が予め対応付けられた第１アプリケーションと、前記エラー画面が対応付けられていない第２アプリケーションとが搭載された情報処理システムのコンピュータに、
   表示対象のアプリケーションの画面を表示する表示ステップと、
   前記情報処理システムで発生したエラーを検知する異常検知ステップと、
   前記エラーが検知された場合、前記第１アプリケーションの画面に対して、その検知された前記エラーを報知する前記エラー画面を描画する描画ステップと、
   前記第２アプリケーションの動作中に前記エラーが検知された場合、表示対象のアプリケーションを、前記第２アプリケーションから前記第１アプリケーションに切り替えて、前記エラー画面を表示する制御を行う制御ステップと、を実行させるためのプログラム。

Images