JP7135761B2 - 電子機器、画面表示方法およびプログラム - Google Patents

Description

本発明は、電子機器、画面表示方法およびプログラムに関する。

従来、電子機器の機能を制御する制御アプリケーション、例えば、複合機等の画像形成装置におけるスキャン、プリント等を行う制御アプリケーションを作成する際には、複雑な電子機器の機能に合わせたアプリケーションの作り込みが必要となり、開発工数が多くかかる。

これに対し、電子機器の制御アプリケーションの画面や機能を提供するアプリケーションソフトウェア（以下、機能提供アプリと呼ぶ）を利用することにより、簡易に制御アプリケーションを開発することができる技術が開示されている。

特に、開発ベンダーが電子機器の制御アプリケーションを開発する際には、電子機器の詳細な仕様を理解する等、開発工数をかけずに開発できることが望まれている。

このように、電子機器の機能の制御のための複雑な処理を機能提供アプリが仲介して、機能を提供することで、少ない工数で制御アプリケーションを開発する技術が既に知られている。

しかしながら、従来の機能提供アプリは、機能提供アプリの提供する機能を呼び出すアプリのＵＩ（User Interface）と機能提供アプリのＵＩとの表示態様に差異があり、ユーザから見ると不自然なアプリケーションに見えるという問題があった。

本発明は、上記に鑑みてなされたものであって、機能提供アプリのＵＩ、機能提供アプリの提供する機能を呼び出す呼び出し元アプリのＵＩ等、アプリ間の表示態様を統一してユーザに違和感を覚えさせないようにすることを目的とする。

上述した課題を解決し、目的を達成するために、本発明は、少なくとも１つのアプリケーションと、前記アプリケーションから、画面の表示態様に関するパラメータを含む前記画面の表示要求を受け付ける第１の受付手段と、前記第１の受付手段により受け付けた前記表示要求に応じた前記画面の表示態様を前記パラメータに基づいて変更した前記画面を表示する第１の表示手段と、を有する機能提供アプリケーションと、電子機器の機能を実行制御する制御アプリケーションとを備え、前記機能提供アプリケーションは、前記第１の表示手段が表示した、表示態様を前記パラメータに基づいて変更した前記画面を介して、ユーザから受け付けた設定情報に基づいて前記機能の実行を前記制御アプリケーションに対して要求する第１の制御手段と、をさらに備えることを特徴とする。

本発明によれば、機能提供アプリのＵＩ、機能提供アプリの提供する機能を呼び出す呼び出し元のアプリのＵＩ等、アプリ間の表示態様を統一してユーザに違和感を覚えさせないことができる、という効果を奏する。

図１は、第１の実施の形態にかかるＭＦＰのハードウェア構成図である。 図２は、ＭＦＰのソフトウェア構成の一例を示す図である。 図３は、ＭＦＰに設けられているソフトウェアの一例を示す図である。 図４は、ＭＦＰの操作部の画面遷移の一例を示す図である。 図５は、ＭＦＰの操作部の画面遷移の別の一例を示す図である。 図６は、機能提供アプリの機能ブロック図である。 図７は、機能提供アプリの画面表示動作の流れを示すシーケンス図である。 図８は、設定画面にかかるＵＩパラメータを例示的に示す図である。 図９は、ＵＩパラメータに応じた変更例を示す図である。 図１０は、第２の実施の形態にかかるＭＦＰの機能提供アプリの機能ブロック図である。 図１１は、機能提供アプリの画面表示動作の流れを示すシーケンス図である。 図１２は、ユーザ情報とＵＩパラメータの紐づけ情報の一例を示す図である。 図１３は、第３の実施の形態にかかるＭＦＰに設けられているソフトウェアの一例を示す図である。 図１４は、ベンダーアプリの画面の一例を示す図である。 図１５は、機能提供アプリの機能ブロック図である。 図１６は、機能提供アプリの設定画面表示動作の流れを示すシーケンス図である。 図１７は、ベンダーアプリの識別子の一例を示す図である。 図１８は、ベンダーアプリの識別子と設定項目の一例を示す図である。 図１９は、第４の実施の形態にかかる機能提供アプリの設定画面表示動作の流れを示すシーケンス図である。 図２０は、第５の実施の形態にかかるＭＦＰの機能提供アプリの機能ブロック図である。 図２１は、機能提供アプリの画面表示動作の流れを示すシーケンス図である。 図２２は、復旧不可能なエラーが発生した場合のエラー画面の一例を示す図である。 図２３は、復旧可能なエラーが発生した場合のエラー画面の一例を示す図である。 図２４は、復旧不可能なエラーが通知された場合のベンダーアプリの動作の一例を示すシーケンス図である。 図２５は、復旧不可能なエラーが通知された場合のベンダーアプリの動作の一例を示すシーケンス図である。 図２６は、第６の実施の形態にかかる機能提供アプリの画面表示動作の流れを示すシーケンス図である。

以下に添付図面を参照して、電子機器、画面表示方法およびプログラムの実施の形態を詳細に説明する。

（第１の実施の形態）
図１は、第１の実施の形態にかかる複合機（ＭＦＰ：Multifunction Peripheral）１のハードウェア構成図である。ＭＦＰ１は、画像処理装置（電子機器）の一例である。ＭＦＰ１は、図１に示すように例えばコピー機能、スキャナ機能、ファクシミリ機能、プリンタ機能等の各種の画像処理を実行する本体部である本体１０と、例えばユーザから画像処理の実行指示の操作を受け付ける操作部２０とを備える。

本体１０と操作部２０は、専用の通信路３０を介して相互に通信可能に接続されている。通信路３０は、例えばＵＳＢ（Universal Serial Bus）規格のものを用いることができる。また、通信路３０は、有線又は無線を問わず任意の規格のものでもよい。また、本体１０は、コピー機能、スキャナ機能、ファクシミリ機能、プリンタ機能等の画像形成機能のうち、一つの機能を有していてもよいし、複数の機能を有していてもよい。

操作部２０としては、単独で完結した情報処理を実行可能な電子機器を用いることができる。一例として、操作部２０としては、スマートフォン又はタブレット型端末等の情報処理端末を用いることができる。この場合、操作部２０として用いられる情報処理端末は、ＭＦＰ１の操作部として機能する。

より詳しくは、従来、ＭＦＰ１には、操作部として専用の操作パネルが固定され設置されていた。これに対して、第１の実施の形態のＭＦＰ１の操作部２０として用いられる情報処理端末は、ＭＦＰ１の本体１０に装着及び取り外し可能となっている。すなわち、操作部２０として用いられる情報処理端末は、例えばＭＦＰ１の操作パネルが配置される位置等の所定の位置から取り外し可能（分離可能）ながらも、ＭＦＰ１と一体的に設置することも可能となっている。このため、操作部２０として用いられる情報処理端末及びＭＦＰ１は、一台の装置として把握されるものである。

操作部２０として用いられる情報処理端末は、ＭＦＰ１から取り外されると、ＭＦＰ１との間で、例えばＢｌｕｅｔｏｏｔｈ（登録商標）又は赤外線通信等の無線通信を行い、ＭＦＰ１の操作部として機能する。

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

（本体のハードウェア構成）
次に、本体１０のハードウェア構成について説明する。図１に示すように、本体１０は、ＣＰＵ（Central Processing Unit）１１と、ＲＯＭ（Read Only Memory）１２と、ＲＡＭ（Random Access Memory）１３と、ＨＤＤ（Hard Disk Drive）１４とを備える。また、本体１０は、通信Ｉ／Ｆ（Interface）１５と、接続Ｉ／Ｆ１６と、エンジン１７と、ファクシミリモデム（ＦＡＸモデム）１９とを備える。各部１１～１７及びＦＡＸモデム１９は、システムバス１８を介して相互に接続されている。

ＣＰＵ１１は、後述する制御アプリケーションを実行する第１のＣＰＵとして機能するものであって、本体１０の動作を統括的に制御する。ＣＰＵ１１は、ＲＡＭ１３をワークエリア（作業領域）としてＲＯＭ１２又はＨＤＤ１４等に格納されたプログラムを実行することで、本体１０全体の動作を制御し、上述したコピー機能、スキャナ機能、ファクシミリ機能、プリンタ機能などの各種の画像形成機能を実現する。なお、この本体１０のＨＤＤ１４は、フラッシュメモリを用いても、同様に実現可能である。

通信Ｉ／Ｆ１５は、ネットワーク４０上のクライアントＰＣ（Personal Computer）、Ｗｅｂサーバ装置又は認証サーバ装置等の外部装置と通信するためのインタフェースである。接続Ｉ／Ｆ１６は、通信路３０を介して操作部２０と通信するためのインタフェースである。なお、図１及び以下に説明する図２において、通信路３０は、有線的に図示しているが、上述のように操作部２０は、ＭＦＰ１の本体１０に対して装着及び取り外しが可能となっている。このため、操作部２０をＭＦＰ１に装着しているときには、通信路３０は有線通信路として機能し、操作部２０をＭＦＰ１から取り外したときには、通信路３０は無線通信路として機能するものと理解されたい。

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

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

ＣＰＵ２１は、後述する各種のアプリケーション及び機能提供アプリケーションを実行する第２のＣＰＵとして機能するものであって、操作部２０の動作を統括的に制御する。ＣＰＵ２１は、ＲＡＭ２３をワークエリア（作業領域）としてＲＯＭ２２等に格納されたプログラムを実行することで操作部２０全体の動作を制御する。また、ＣＰＵ２１は、ＲＯＭ２２等に格納されたユーザ認証プログラムを実行することでユーザ認証処理を行う。通信Ｉ／Ｆ２５は、例えばネットワーク４０上のサーバ装置６０と通信するためのインタフェースである。接続Ｉ／Ｆ２６は、通信路３０を介して本体１０と通信するためのインタフェースである。

ＩＣカードＩ／Ｆ２９は、例えばＵＳＢケーブル等を介してカードリーダ６に接続されている。カードリーダ６は、ＭＦＰ１に対するログイン操作のときに、ユーザにより近接操作（非接触操作）されたＩＣカード５との間で非接触無線通信を行い、ＩＣカード５に記憶されているカードＩＤ、ユーザ情報等の認証情報の読み取りを行う。なお、非接触操作のほか、接触操作でＩＣカード５から認証情報を読み取ってもよい。

また、一例として、カードリーダ６と操作部２０は、物理的に異なる装置同士が、ＵＳＢケーブル等を介して接続されていることとしたが、操作部２０にカードリーダ６が内蔵されていてもよい。すなわち、操作部２０とカードリーダ６が一体的に形成されていてもよい（一つの装置として形成されていてもよい）。

また、ＩＣカード又はＩＤカード等の呼称の違いがあっても、記憶媒体であれば、どのような記憶媒体でも本発明を適用可能であり、ＩＣカード又はＩＤカード等のみに本発明の適用範囲が限定されることはない。また、カードリーダ装置も同様であり、このような記憶媒体からユーザ情報を読み取れる装置であればいずれも用いることができる。

操作パネル２７は、タッチセンサを備えた液晶表示装置（ＬＣＤ：Liquid Crystal Display）で構成される。操作パネル２７は、ユーザの操作に応じた各種の入力を受け付けると共に、例えば受け付けた入力に応じた情報、ＭＦＰ１の動作状況を示す情報、設定状態を示す情報等の各種の情報を表示する。なお、操作パネル２７は、タッチセンサを備えた有機ＥＬ（Organic Light-Emitting Diode：OLED）表示装置で構成してもよい。さらに、これに加えて又はこれに代えて、ハードウェアキー等の操作部又は発光部等の表示部を設けてもよい。

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

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

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

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

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

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

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

本体１０及び操作部２０を、別々のオペレーティングシステムで動作させることで、本体１０と操作部２０との間の通信は、共通の装置内のプロセス間通信ではなく、異なる装置間の通信として行われる。操作部２０が受け付けた入力（ユーザからの指示内容）を本体１０へ伝達する動作（コマンド通信）及び本体１０が操作部２０へイベントを通知する動作等がこれに該当する。ここでは、操作部２０が本体１０へコマンド通信を行うことにより、本体１０の機能を使用することができる。また、本体１０から操作部２０に通知するイベントには、本体１０における動作の実行状況、本体１０側で設定された内容等が挙げられる。

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

なお、この例では、本体１０と操作部２０は、通信路３０を介して電気的かつ物理的に接続されているが、上述のように本体１０から操作部２０を取り外すこともできる。この場合、本体１０及び操作部２０に、例えば赤外線通信部、ＲＦ通信部、Ｂｌｕｅｔｏｏｔｈ（登録商標）通信部等の近距離無線通信部を設ける。ＲＦは、「Radio Frequency」の略記である。または、本体１０及び操作部２０に、Ｗｉ－Ｆｉ（登録商標）等の無線ＬＡＮ通信機能を設け、図２に示すように無線ＬＡＮアクセスポイント（無線ＬＡＮＡＰ）４１及びネットワーク４０を介して相互に通信可能としてもよい。ＬＡＮは、「Local Area Network」の略記である。本体１０から操作部２０を取り外し可能である場合、操作部２０は、通信路３０を介して本体１０から供給された電力を二次電池に蓄電しておき、本体１０から取り外されたときに、二次電池に蓄電された電力で動作して本体１０と通信を行う。

（ＭＦＰに設けられているソフトウェア）
図３に、ＭＦＰ１に設けられているソフトウェアの一例を示す。上述のように、本体１０は、アプリ層１０１、サービス層１０２及びＯＳ層１０３に分かれている。このうち、アプリ層１０１には、図１に示すエンジン１７を制御して、原稿の読み取り制御又は印刷制御等を行うアプリが記憶されている。具体的には、アプリ層１０１には、コピーアプリ１１１、スキャナアプリ１１２、プリンタアプリ１１３及びＦＡＸアプリ１１４が記憶されている。コピーアプリ１１１～ＦＡＸアプリ１１４は、標準搭載のジョブ実行機能アプリであり、制御アプリケーションの一例である。

また、サービス層１０２には、省エネルギー管理プログラム（省エネ管理プログラム）１２１、メモリ管理プログラム１２２及びエンジン制御プログラム１２３等の、各アプリが共通で行う処理に対応する各種プログラムが記憶されている。サービス層１０２は、省エネルギー管理及びメモリ管理等、各アプリが共通で行う処理を行っている。

これに対して、操作部２０は、アプリ層２０１及びＯＳ層２０３に分かれている。本体アプリと操作部アプリの違いは、本体アプリではエンジン制御等を行うことで、例えば読み取り及び印刷等の画像形成装置の機能を制御するのに対し、操作部アプリではＵＩ制御を行っている。つまり、操作部アプリで画面表示を行うことでユーザの操作を受け付け、そのユーザ操作に基づいたエンジン制御を本体アプリが行っている。

操作部アプリには、スキャナアプリ１３３等に対して開発ベンダーが開発するベンダーアプリ１３７が存在する。

また、操作部アプリには、ベンダーアプリ１３７の開発を簡単にするために、操作部２０のコピーアプリ１３１～ＦＡＸアプリ１３５と同等の機能をベンダー等に提供する機能提供アプリケーションである機能提供アプリ１３６が設けられている。

すなわち、操作部２０のアプリ層２０１には、ユーザインタフェースを介してユーザ操作を受け付けるアプリが記憶されている。具体的には、アプリ層２０１には、ホームアプリ１３０、コピーアプリ１３１、スキャナアプリ１３３、プリンタアプリ１３４、ＦＡＸアプリ１３５、機能提供アプリ１３６及びベンダーアプリ１３７などの各種のアプリケーションが記憶されている。なお、以下では機能提供アプリ１３６が提供する機能としてプリンタ機能を例にして説明するが、これに限定されない。すなわち、機能提供アプリ１３６は、コピー機能やスキャン機能や、ＦＡＸ機能など、本体１０又は操作部２０が有する機能に対応することができる。

ホームアプリ１３０は、所望の操作を指定するためのアイコン等が並べられたメイン画面（初期画面）を表示する。そして、ユーザによりアイコン操作を介して指定されたアプリを起動する。コピーアプリ１３１は、操作ボタン及び設定ボタンを介して、ユーザのコピー操作を受け付けるアプリである。スキャナアプリ１３３は、操作ボタン及び設定ボタン等を介して、ユーザのスキャナ操作を受け付けるアプリである。プリンタアプリ１３４は、操作ボタン及び設定ボタン等を介して、ユーザのプリンタ操作を受け付けるアプリである。ＦＡＸアプリ１３５は、操作ボタン及び設定ボタン等を介して、ユーザのファクシミリ送受信操作を受け付けるアプリである。

機能提供アプリ１３６は、画像処理プログラムの一例である。また、機能提供アプリ１３６は、一例として操作部２０のＲＯＭ２２、ＲＡＭ２３又はフラッシュメモリ２４等の記憶部に記憶される。

機能提供アプリ１３６は、上述のようにベンダーアプリ１３７の開発を容易化するために、操作部２０のコピーアプリ１３１～ＦＡＸアプリ１３５と同等の機能を開発ベンダー等に提供する。

ベンダーアプリ１３７は、要求アプリケーションの一例である。ベンダーアプリ１３７は、例えばプリントの設定や実行を行う際に、例えばプリンタアプリ１３４にかかる機能提供アプリ１３６を呼び出す。

すなわち、機能提供アプリ１３６が例えばスキャナアプリ１３３に対応するアプリの場合、機能提供アプリ１３６は、通常の操作メニュー及び設定メニュー等のユーザインタフェースを表示する機能を開発ベンダーに提供する。また、機能提供アプリ１３６が例えばプリンタアプリ１３４に対応するアプリの場合、機能提供アプリ１３６は、通常の操作メニュー及び設定メニュー等のユーザインタフェースを表示する機能を開発ベンダーに提供する。

このようにＭＦＰ１の操作部２０には、コピーアプリ１３１～ＦＡＸアプリ１３５と同等の機能をベンダー等に提供するための機能提供アプリ１３６が設けられている。ベンダーアプリ１３７の開発ベンダーに対しては、機能提供アプリ１３６の機能を実現するＡＰＩ（Application Programming Interface）が公開されている。

本実施の形態においては、機能提供アプリ１３６は、「標準搭載のプリンタアプリ」、「ベンダーアプリへの機能の提供アプリ」として２つの役割を持つ、１つのアプリケーションである。

なお、本実施の形態においては、機能提供アプリ１３６は、プリンタアプリ１３４にのみ適用されるものとして説明する。なお、機能提供アプリ１３６は、プリンタアプリ１３４のみならず、他のコピーアプリ１３１、スキャナアプリ１３３等に適用されるものであっても何ら問題はない。

ここで、図４はＭＦＰ１の操作部２０の画面遷移の一例を示す図である。図４は、機能提供アプリ１３６が、ベンダーアプリ１３７から呼び出される場合の画面遷移（設定、実行）である。図４中、破線はアプリの境界を表しており、アプリから別のアプリへの矢印はアプリ切り替えを意味し、アプリから同じアプリへの矢印はアプリ内での画面切り替えを意味する。

（１）．まず、ユーザが使用するアプリを選択するホーム画面（ＭＦＰ１にインストールされているさまざまなアプリのアイコンが表示される）Ａで、ベンダーアプリ１３７のアイコンを選択すると、ベンダーアプリ１３７が起動する。ベンダーアプリ１３７の画面Ｂは、パラメータを含むベンダーアプリ１３７からの要求に応じて表示され、画像処理の設定入力または画像処理の実行指示を選択するための選択画面である。

（２）．ベンダーアプリ１３７の画面Ｂのプリント設定ボタンＢ１を押下すると、機能提供アプリ１３６が起動してアプリが切り替わり、設定画面Ｃが表示される。設定画面Ｃは、ベンダーアプリ１３７の画面Ｂで設定入力を選択した場合に表示される画像処理の設定入力画面である。内部的には、ここでベンダーアプリ１３７から機能提供アプリ１３６に対するＡＰＩ呼び出しが行われて機能提供アプリ１３６が起動する。

（３）．機能提供アプリ１３６では、ユーザ操作によって様々なプリント設定の設定が可能である。

（４）．機能提供アプリ１３６の設定画面Ｃの設定完了ボタンＢ３を押下すると、プリント設定の設定情報が確定してアプリが切り替わり、ベンダーアプリ１３７の画面Ｂに戻る。内部的には、ベンダーアプリ１３７に設定値情報が通知される。

（５）．ベンダーアプリ１３７の画面Ｂのプリント実行ボタンＢ２を押下すると、機能提供アプリ１３６が起動してアプリが切り替わり、プリント実行画面Ｄが表示され、プリントが実行される。内部的には、ここでベンダーアプリ１３７から機能提供アプリ１３６に対するＡＰＩ呼び出しが行われて機能提供アプリ１３６が起動する。また、ＡＰＩの呼び出しの際に、プリント対象のファイルパスをパラメータとして機能提供アプリ１３６に受け渡す。なお、機能提供アプリ１３６に受け渡す情報には、プリント対象のファイルの設定値情報が含まれていても良い。

（６）．プリントが完了するとアプリが切り替わり、ベンダーアプリ１３７の画面Ｂに戻る。

また、図５はＭＦＰ１の操作部２０の画面遷移の別の一例を示す図である。図５は、機能提供アプリ１３６が、標準搭載のアプリとして機能する場合の画面遷移（設定＋実行）である。図５中、破線はアプリの境界を表しており、アプリから別のアプリへの矢印はアプリ切り替えを意味し、アプリから同じアプリへの矢印はアプリ内での画面切り替えを意味する。

（１）．まず、ユーザが使用するアプリを選択するホーム画面（ＭＦＰ１にインストールされているさまざまなアプリのアイコンが表示される）Ａで、ベンダーアプリ１３７のアイコンを選択すると、ベンダーアプリ１３７が起動する。ベンダーアプリ１３７の画面Ｂは、パラメータを含むベンダーアプリ１３７からの要求に応じて表示され、画像処理の設定入力または画像処理の実行指示を選択するための選択画面である。

（２）．ベンダーアプリ１３７の画面Ｂのプリント設定および実行ボタンＢ４を押下すると、機能提供アプリ１３６が起動してアプリが切り替わり、設定画面Ｃが表示される。設定画面Ｃは、ベンダーアプリ１３７の画面Ｂで設定入力を選択した場合に表示される画像処理の設定入力画面である。内部的には、ここでベンダーアプリ１３７から機能提供アプリ１３６に対するＡＰＩ呼び出しが行われて機能提供アプリ１３６が起動する。

（３）．機能提供アプリ１３６では、ユーザ操作によって様々なプリント設定の設定が可能である。

（４）．機能提供アプリ１３６の設定画面ＣのスタートボタンＢ５を押下すると、プリント設定の設定情報が確定してプリントが実行される。

（５）．プリントが完了するとアプリが切り替わり、ベンダーアプリ１３７の画面Ｂに戻る。

以上のように、ベンダーアプリ１３７は、プリント設定ボタンおよびプリント実行ボタン、またはプリント設定および実行ボタンを実装する。そして、ベンダーアプリ１３７は、各ボタン押下時に機能提供アプリ１３６に対するＡＰＩ呼び出し処理を実装するだけで、プリント設定やプリント実行をすることができる。

（機能提供アプリの機能）
図６は、機能提供アプリ１３６の機能ブロック図である。操作部２０のＣＰＵ２１は、例えばＲＯＭ２２、ＲＡＭ２３又はフラッシュメモリ２４等の記憶部に記憶されている機能提供アプリ１３６を実行することで、図６に示す、制御手段１５０、受付手段１５１、及び表示手段１５６を実現する。

受付手段１５１は、第１の受付手段として機能するものであって、機能提供アプリ１３６のアイコンが操作された場合に生成される起動要求、又は、ベンダーアプリ１３７からの起動要求を受け付ける。

制御手段１５０は、第１の制御手段として機能するものであって、新規に呼び出しを受け付けた後に、画面表示やジョブ実行などを行う。

表示手段１５６は、第１の表示手段として機能するものであって、操作パネル２７に対してメイン画面又は実行画面／エラー画面等の表示制御を行う。表示手段１５６は、実行画面／エラー画面を介してユーザにより設定された設定内容をベンダーアプリ１３７に通知する等の処理を行う。

なお、この例では、制御手段１５０、受付手段１５１、表示手段１５６をソフトウェアで実現することとしたが、制御手段１５０、受付手段１５１、表示手段１５６のうち、一部又は全部を、ＩＣ（Integrated Circuit）等のハードウェアで実現してもよい。

また、機能提供アプリ１３６は、インストール可能な形式又は実行可能な形式のファイルでＣＤ－ＲＯＭ、フレキシブルディスク（ＦＤ）等のコンピュータ装置で読み取り可能な記録媒体に記録して提供してもよい。また、ＣＤ－Ｒ、ＤＶＤ（Digital Versatile Disk）、ブルーレイディスク（登録商標）、半導体メモリ等のコンピュータ装置で読み取り可能な記録媒体に記録して提供してもよい。また、機能提供アプリ１３６は、インターネット等のネットワーク経由でインストールする形で提供してもよい。また、機能提供アプリ１３６は、機器内のＲＯＭ等に予め組み込んで提供してもよい。

（機能提供アプリの動作）
次に、機能提供アプリ１３６の動作を説明する。図７は、ベンダーアプリ１３７で設定を実行する場合における、機能提供アプリ１３６の画面表示動作の流れを示すシーケンス図である。

図７に示すように、ユーザにより、ホーム画面Ａを介してベンダーアプリ１３７が起動され（ステップＳ１）、設定ボタンＢ１が操作されると（ステップＳ２）、ベンダーアプリ１３７は、機能提供アプリ１３６に対して画面表示要求を行う（ステップＳ３）。なお、ベンダーアプリ１３７は、この際、ＵＩ（User Interface）パラメータを付与する。ベンダーアプリ１３７は、通知手段として機能する。

ここで、図８は設定画面ＣにかかるＵＩパラメータを例示的に示す図である。ステップＳ３で付与されるＵＩパラメータ（ＵＩパーツ）は、図８に示すように、例えば以下のようなものが挙げられる。
・設定画面Ｃのタイトル（図８に示すａ）
・設定画面Ｃのタイトルの文字色（図８に示すｂ）
・ヘッダ部分の背景色（図８に示すｃ）
・ヘッダ部分の背景画像（ロゴ）（図８に示すｄ）
・ボディ部分の背景色（図８に示すｅ）
・ボディ部分の背景画像（図８に示すｆ）
・設定項目の可視性（図８に示すｇ）
・ボタンの名称（図８に示すｈ）

ここで、背景画像は画像データ自体をパラメータに載せてもよいが、データ量が大きいため画像データのファイルパスを指定する方が望ましい。

次いで、機能提供アプリ１３６の受付手段１５１は、この画面表示要求を受信し、制御手段１５０に対して設定画面Ｃの表示要求（ＵＩパラメータ）を行う（ステップＳ４）。

次に、制御手段１５０は、表示手段１５６に対して設定画面Ｃの表示要求（ＵＩパラメータ）を行う（ステップＳ５）。

そして、表示手段１５６は、取得したＵＩパラメータに応じて設定画面Ｃを生成して、操作パネル２７に表示する（ステップＳ６）。より詳細には、表示手段１５６は、取得したＵＩパラメータに基づいて、ベンダーアプリ１３７の画面Ｂと少なくとも同じ背景色または背景画像を含む表示態様で設定画面Ｃを生成して表示する。

ここで、図９はＵＩパラメータに応じた変更例を示す図である。図９（ａ）は、設定画面Ｃのタイトルａを変更した例を示すものである。図９（ａ）の左は変更前を示し、右は変更後を示している。また、図９（ｂ）は、ボディ部分の背景色ｅを変更した例を示すものである。図９（ｂ）の左は変更前を示し、右は変更後を示している。このようにするのは、例えば、呼び出し元のベンダーアプリ１３７が青系のＵＩである場合に、機能提供アプリ１３６のＵＩが灰色系である場合に、ユーザから見るとアプリのＵＩが突然変化して違和感を覚えるということがあるためである。

なお、本実施の形態においては、設定画面Ｃを表示するときのＵＩを変更しているが、これに限るものではなく、例えば、直接ジョブを実行する場合のＵＩを変更するようにしてもよい。

このように本実施の形態によれば、呼び出し元のベンダーアプリ１３７が機能提供アプリ１３６を呼び出す際にＵＩに関するパラメータを付与して通知して、機能提供アプリ１３６が通知されたＵＩに関するパラメータをもとに画面のＵＩの表示態様を変更する。これにより、機能提供アプリ１３６のＵＩと呼び出し元のベンダーアプリ１３７のＵＩとの表示態様を統一することができるので、ユーザに違和感を覚えさせないことができる。

（第２の実施の形態）
次に、第２の実施の形態について説明する。

第２の実施の形態は、ＵＩパラメータとユーザ情報との組み合わせを記憶するようにした点が、第１の実施の形態と異なる。以下、第２の実施の形態の説明では、第１の実施の形態と同一部分の説明については省略し、第１の実施の形態と異なる箇所について説明する。

図１０は、第２の実施の形態にかかるＭＦＰ１の機能提供アプリ１３６の機能ブロック図である。操作部２０のＣＰＵ２１は、例えばＲＯＭ２２、ＲＡＭ２３又はフラッシュメモリ２４等の記憶部に記憶されている機能提供アプリ１３６を実行することで、図１０に示す、制御手段１５０、受付手段１５１、記憶手段１５２、及び表示手段１５６を実現する。

受付手段１５１は、機能提供アプリ１３６のアイコンが操作された場合に生成される起動要求、又は、ベンダーアプリ１３７からの起動要求を受け付ける。

記憶手段１５２は、第１の記憶手段として機能するものであって、例えばＲＯＭ２２、ＲＡＭ２３又はフラッシュメモリ２４等の記憶部に対し、ユーザ情報とＵＩパラメータとを紐づけた情報を記憶する。

制御手段１５０は、新規に呼び出しを受け付けた後に、画面表示やジョブ実行などを行う。

表示手段１５６は、操作パネル２７に対してメイン画面又は実行画面／エラー画面等の表示制御を行う。表示手段１５６は、実行画面／エラー画面を介してユーザにより設定された設定内容をベンダーアプリ１３７に通知する等の処理を行う。

なお、この例では、制御手段１５０、受付手段１５１、記憶手段１５２、表示手段１５６をソフトウェアで実現することとしたが、制御手段１５０、受付手段１５１、記憶手段１５２、表示手段１５６のうち、一部又は全部を、ＩＣ（Integrated Circuit）等のハードウェアで実現してもよい。

（機能提供アプリの動作）
次に、機能提供アプリ１３６の動作を説明する。図１１は、ベンダーアプリ１３７で設定を実行する場合における、機能提供アプリ１３６の画面表示動作の流れを示すシーケンス図である。

図１１に示すステップＳ１～Ｓ６は、図７に示すステップＳ１～Ｓ６と何ら変わるものではないため、その説明を省略する。

Ｓ６の処理が終了すると、表示手段１５６は、記憶手段１５２を介して記憶部にユーザ情報とＵＩパラメータとの紐づけ情報を記憶する（ステップＳ７）。ユーザ情報は、ＩＣカード５に記憶されているカードＩＤ、ユーザ情報等である。

ここで、図１２はユーザ情報とＵＩパラメータの紐づけ情報の一例を示す図である。図１２に示すように、記憶部には、ユーザ情報に対応付けてＵＩパラメータが記憶される。

この後、同一ユーザより、ホーム画面Ａを介してベンダーアプリ１３７が起動され（ステップＳ１１）、設定ボタンＢ１が操作されると（ステップＳ１２）、ベンダーアプリ１３７は、機能提供アプリ１３６に対して画面表示要求を行う（ステップＳ１３）。ただし、この場合、ベンダーアプリ１３７は、ＵＩパラメータを付与しない。

次いで、機能提供アプリ１３６の受付手段１５１は、この画面表示要求を受信し、制御手段１５０に対して設定画面Ｃの表示要求を行う（ステップＳ１４）。

次に、制御手段１５０は、表示手段１５６に対して設定画面Ｃの表示要求を行う（ステップＳ１５）。

表示手段１５６は、記憶部からユーザ情報とＵＩパラメータの紐づけ情報を取得する（ステップＳ１６）。

そして、表示手段１５６は、取得したＵＩパラメータに応じて設定画面Ｃを生成して、操作パネル２７に表示する（ステップＳ１７）。

このように本実施の形態によれば、ＵＩパラメータとユーザ情報との組み合わせを記憶することで、次回以降はＵＩパラメータの通知がなくてもＵＩを変更することができる。また、複数のＭＦＰ１を管理している場合などでは、ＵＩパラメータ通知を初回に実施してクラウドなどにエクスポートしておき、全てのＭＦＰ１にインポートすることでユーザはどのＭＦＰ１を使用しても同じＵＩの提供を受けることができる。

なお、本実施の形態においては、図１１のステップＳ１～Ｓ７、及びステップＳ１１～Ｓ１７のそれぞれの前のタイミングで、ユーザは、ＭＦＰ１（画像処理装置及び電子機器）に対してユーザ情報を使ったログイン操作を、すでに行っている。ＭＦＰ１（画像処理装置及び電子機器）に対するログイン操作は、操作パネル２７やハードキーを使ってユーザＩＤとパスワードを手打ち入力する操作や、ＭＦＰ１（画像処理装置及び電子機器）のカードリーダ６にユーザが所持するＩＣカード５をかざしてユーザ情報を入力する操作のことである。

ＭＦＰ１（画像処理装置及び電子機器）の内部または外部装置は、認証処理を行い、ＭＦＰ１（画像処理装置及び電子機器）に結果を返す一連の処理を行う。このログイン操作と処理によりＭＦＰ１（画像処理装置及び電子機器）がユーザ情報を保持する。

また、図１１のステップＳ１６の取得では、別のタイミングでログインした際にＭＦＰ１（画像処理装置及び電子機器）が保持しているユーザ情報を使って、図１１のステップＳ７で保存したＵＩパラメータを取得する処理を行っている。

（第３の実施の形態）
次に、第３の実施の形態について説明する。

従来の機能提供アプリにおいては、複数のベンダーアプリからジョブ実行機能を呼び出したときに、機能提供アプリの実態は１つだけのため、ユーザが途中まで変更したジョブ設定内容を保存・再現できていないという問題がある。第３の実施の形態は、複数のベンダーアプリ１３７から機能提供アプリ１３６を呼び出した際にも、ユーザが途中まで変更したジョブ設定内容を保存・再現することできるようにした点が、第１の実施の形態および第２の実施の形態と異なる。以下、第３の実施の形態の説明では、第１の実施の形態または第２の実施の形態と同一部分の説明については省略し、第１の実施の形態および第２の実施の形態と異なる箇所について説明する。

図１３は、第３の実施の形態にかかるＭＦＰ１に設けられているソフトウェアの一例を示す図である。図１３に示すように、本実施の形態においては、操作部アプリには、スキャナアプリ等に対して開発ベンダーが開発するベンダーアプリ１３７が複数存在する。本実施の形態においては、ベンダーアプリＡ１３７ＡおよびベンダーアプリＢ１３７Ｂとする。

図１４は、ベンダーアプリ１３７の画面の一例を示す図である。図１４に示すベンダーアプリ１３７の画面は、プリント対象のファイルを選択する画面例である。図１４の画面は、ベンダーアプリ（ベンダープリントアプリ）１３７の画面上でプリント対象のファイルを選択後に実行キーＫ１を押下させるための画面である。図１４に示すように、プリント対象のファイルは複数選択可能であってもよい。なお、１つもファイルが選択されていない場合は、実行キーＫ１が半輝度で押下不可であることが望ましい。

なお、図１４に示すように、ベンダーアプリ１３７の画面において印刷対象のファイルが選択可能である場合には、ファイル毎に、または複数のファイルに対してまとめて、プリント設定の設定及びプリントの実行を行っても良い。この場合、例えば図４で示した画面Ｂにおいてプリント設定の変更を行いたいファイルを選択した後、プリント設定ボタンＢ１を押下すると、該ファイルのプリント設定を変更することができる。なお、複数のファイルが選択されている場合は、印刷対象ファイルについて同一のプリント設定の設定を行っても良い。

（機能提供アプリの機能）
図１５は、機能提供アプリ１３６の機能ブロック図である。操作部２０のＣＰＵ２１は、例えばＲＯＭ２２、ＲＡＭ２３又はフラッシュメモリ２４等の記憶部に記憶されている機能提供アプリ１３６を実行することで、図１５に示すように、制御手段２５０、受付手段２５１、記憶手段２５２、入力手段２５３、ジョブ実行手段２５４、設定手段２５５、及び表示手段２５６を実現する。

受付手段２５１は、第２の受付手段として機能するものであって、機能提供アプリ１３６のアイコンが操作された場合に生成される起動要求、又は、ベンダーアプリ１３７からの起動要求を受け付ける。

記憶手段２５２は、第２の記憶手段として機能するものであって、例えばＲＯＭ２２、ＲＡＭ２３又はフラッシュメモリ２４等の記憶部に対し、起動要求のあったアプリに対応する情報、呼び出し元の情報（標準搭載のアプリとして起動されているか、又は、ベンダーへの機能提供として起動されているかを示す情報）、設定値及び状況情報等の記憶制御及び読み出し制御を行う。

制御手段２５０は、第２の制御手段として機能するものであって、新規に呼び出しを受け付けた後に、記憶手段２５２を制御することにより現在呼び出し中のアプリ情報を記憶部から取り出し、新規呼び出し元アプリと比較して画面表示やジョブ実行などを行う。

入力手段２５３は、ユーザによる操作パネル２７の操作に応じて、操作パネル２７に表示した画面に対するユーザの入力を受け付ける。

表示手段２５６は、第２の表示手段として機能するものであって、操作パネル２７に対してメイン画面又はジョブ設定／実行画面等の表示制御を行う。表示手段２５６は、ジョブ設定／実行画面を介してユーザにより設定された設定内容をベンダーアプリ１３７に通知する等の処理を行う。

設定手段２５５は、ＭＦＰ１のスペックに合わせてジョブ設定／実行画面の表示内容にかかるジョブ設定情報を変更し、設定値の調整を行う。調整は、即ち、ＭＦＰ１の有するスペックとして、例えばモノクロ印刷の可否、カラー印刷の可否、または、片面印刷の可否・両面印刷の可否といった、保有機能に合わせて、設定された設定値を自動変更する。例えば、カラー設定の入力があったが、モノクロ印刷しか能力が無い場合には、印刷の設定値をカラー印刷からモノクロ印刷へ、値をスペックに合わせるもしくは落とす処理を自動的に行う。

ジョブ実行手段２５４は、本体１０のコピーアプリ１１１又はスキャナアプリ１１２等に決定した設定値を利用して所望の動作のジョブ実行要求を行う。

なお、この例では、制御手段２５０～表示手段２５６をソフトウェアで実現することとしたが、制御手段２５０～表示手段２５６のうち、一部又は全部を、ＩＣ（Integrated Circuit）等のハードウェアで実現してもよい。

また、機能提供アプリ１３６は、インストール可能な形式又は実行可能な形式のファイルでＣＤ－ＲＯＭ、フレキシブルディスク（ＦＤ）等のコンピュータ装置で読み取り可能な記録媒体に記録して提供してもよい。また、ＣＤ－Ｒ、ＤＶＤ（Digital Versatile Disk）、ブルーレイディスク（登録商標）、半導体メモリ等のコンピュータ装置で読み取り可能な記録媒体に記録して提供してもよい。また、機能提供アプリ１３６は、インターネット等のネットワーク経由でインストールする形で提供してもよい。また、機能提供アプリ１３６は、機器内のＲＯＭ等に予め組み込んで提供してもよい。

（機能提供アプリの動作）
次に、機能提供アプリ１３６の動作を説明する。図１６は、ベンダーアプリ１３７で設定を実行する場合における、機能提供アプリ１３６の設定画面表示動作の流れを示すシーケンス図である。図１６のシーケンス図は、「１．ベンダーアプリＡから機能提供アプリを呼び出して設定変更」、「２．ベンダーアプリＢから機能提供アプリを呼び出す」、「３．ベンダーアプリＡから機能提供アプリを呼び出す」という操作を順に行ったときに、３．の時に１．で変更した設定が復元されるシーケンスである。

すなわち、ユーザにより、ホーム画面を介してベンダーアプリＡ１３７Ａが起動され（ステップＳ１０１）、設定ボタンが操作されると（ステップＳ１０２）、ベンダーアプリＡ１３７Ａは、機能提供アプリ１３６に対して画面表示要求を行う（ステップＳ１０３）。なお、ベンダーアプリＡ１３７Ａは、この際、ベンダーアプリＡ１３７Ａの識別子をパラメータに付与する。ベンダーアプリ１３７は、通知手段として機能する。

ここで、図１７はベンダーアプリの識別子の一例を示す図である。ベンダーアプリの識別子は、ベンダーアプリを一意に区別できる識別子であればよい。図１７に示すように、例えば、ベンダーアプリの識別子は、ベンダーアプリのパッケージ名などでよい。

機能提供アプリ１３６の受付手段２５１は、この画面表示要求を受信し、制御手段２５０に対して例えばベンダータアプリＡ１３７Ａの画面表示要求を行う（ステップＳ１０４）。

制御手段２５０は、記憶手段２５２に対して、ベンダーアプリＡ１３７Ａの識別子の記憶を指示する（ステップＳ１０５）。ベンダーアプリＡ１３７Ａの識別子を記憶すると、制御手段２５０は、表示手段２５６に対し、設定画面の表示要求を行う（ステップＳ１０６）。

なお、制御手段２５０は、記憶手段２５２に対して、ベンダーアプリＡ１３７Ａの識別子に加えて現在の設定項目を記憶させるようにしてもよい。図１８はベンダーアプリの識別子と設定項目の一例を示す図である。図１８に示すように、ベンダーアプリの識別子に対応付けて設定項目を記憶することにより、機能提供アプリ１３６の画面が意図せず破棄された場合も、設定画面を復元することができる。なお、図１８では、設定項目としてプリント設定を記憶する場合を例に示すが、ベンダーアプリＡ１３７Ａが要求するジョブがコピージョブの場合はコピー設定を、スキャンジョブの場合はスキャン設定を、ＦＡＸジョブの場合はＦＡＸ設定をそれぞれ設定項目として記憶する。

表示手段２５６は、設定手段２５５にアクセスすることで、ジョブ設定情報を取得する（ステップＳ１０７）。その後、表示手段２５６は、取得したジョブ設定情報に基づいて操作パネル２７に対して設定画面を表示する（ステップＳ１０８）。

なお、ベンダーアプリの初回起動時等のように、前回のジョブ設定情報が記憶されていない場合、表示手段２５６は、デフォルトのジョブ設定情報に応じて設定画面を表示する。

次に、設定画面において、ステップＳ１０９に示すように、ユーザにより操作パネル２７を介して設定変更操作が行われると、入力手段２５３は、ステップＳ１１０において、ユーザにより入力されたジョブ設定情報を設定手段２５５に送信する。設定手段２５５は、ユーザにより設定されたジョブ設定情報等をＲＡＭ２３等の記憶部に、一時的に保持する。

ここで、ベンダーアプリＡ１３７Ａから機能提供アプリ１３６を呼び出している状態で、別のベンダーアプリＢ１３７Ｂから機能提供アプリ１３６を呼び出した場合について説明する。

ベンダーアプリＡ１３７Ａから機能提供アプリ１３６を呼び出している状態において、ユーザにより、ホーム画面を介してベンダーアプリＢ１３７Ｂが起動され（ステップＳ１１１）、設定ボタンが操作されると（ステップＳ１１２）、ベンダーアプリＢ１３７Ｂは、機能提供アプリ１３６に対して画面表示要求を行う（ステップＳ１１３）。なお、ベンダーアプリＢ１３７Ｂは、この際、ベンダーアプリＢ１３７Ｂの識別子をパラメータに付与する。機能提供アプリ１３６の受付手段２５１は、この画面表示要求を受信し、制御手段２５０に対して例えばベンダーアプリＢ１３７Ｂの画面表示要求を行う（ステップＳ１１４）。

次に、制御手段２５０は、要求中のベンダーアプリの識別子（ベンダーアプリＡ１３７Ａの識別子）を取得する（ステップＳ１１５）。

ここで、要求中のベンダーアプリの識別子（ベンダーアプリＡ１３７Ａの識別子）と新規に要求してきたベンダーアプリの識別子（ベンダーアプリＢ１３７Ｂの識別子）が異なる場合、制御手段２５０は、設定手段２５５から現在のジョブ設定情報を取得する（ステップＳ１１６）。

加えて、制御手段２５０は、要求中のベンダーアプリＡ１３７Ａに対して、現在のジョブ設定情報を通知する（ステップＳ１１７）。つまり、制御手段２５０は、ベンダーアプリＡ１３７Ａに対して、現在のジョブ設定情報を返却する。

ここで、ステップＳ１１７で通知される現在のジョブ設定情報は、機能提供アプリ１３６が解読できる情報であればよく、ベンダーアプリはその情報の中身（フォーマットなど）を知る必要はない。

その後、制御手段２５０は、表示手段２５６に対し、設定画面の表示要求を行う（ステップＳ１１８）。

表示手段２５６は、設定手段２５５にアクセスすることで、ジョブ設定情報を取得する（ステップＳ１１９）。ここでは、新規に画面を作り直すため、ジョブ設定情報を取得しなおすことになる。その後、表示手段２５６は、操作パネル２７に対して設定画面を表示する（ステップＳ１２０）。

さらに、ベンダーアプリＢ１３７Ｂから機能提供アプリ１３６を呼び出している状態で、別のベンダーアプリＡ１３７Ａから機能提供アプリ１３６を呼び出した場合について説明する。

ベンダーアプリＢ１３７Ｂから機能提供アプリ１３６を呼び出している状態において、ユーザにより、ホーム画面を介してベンダーアプリＡ１３７Ａが起動され（ステップＳ１２１）、設定ボタンが操作されると（ステップＳ１２２）、ベンダーアプリＡ１３７Ａは、機能提供アプリ１３６に対して画面表示要求を行う（ステップＳ１２３）。なお、ベンダーアプリＡ１３７Ａは、この際、ベンダーアプリＡ１３７Ａの識別子とステップＳ１１７で返却されたジョブ設定情報をパラメータに付与する。すなわち、ベンダーアプリＡ１３７Ａは、ステップＳ１１７で返却されたジョブ設定情報をステップＳ１２３の画面表示要求時にそのままパラメータとしてセットしている。

機能提供アプリ１３６の受付手段２５１は、この画面表示要求を受信し、制御手段２５０に対して例えばベンダーアプリＡ１３７Ａの画面表示要求を行う（ステップＳ１２４）。

次に、制御手段２５０は、要求中のベンダーアプリの識別子（ベンダーアプリＢ１３７Ｂの識別子）を取得する（ステップＳ１２５）。

ここで、要求中のベンダーアプリの識別子（ベンダーアプリＢ１３７Ｂの識別子）と新規に要求してきたベンダーアプリの識別子（ベンダーアプリＡ１３７Ａの識別子）とが異なる場合、制御手段２５０は、設定手段２５５から現在のジョブ設定情報を取得する（ステップＳ１２６）。

加えて、制御手段２５０は、要求中のベンダーアプリＢ１３７Ｂに対して、現在のジョブ設定情報を通知する（ステップＳ１２７）。つまり、制御手段２５０は、ベンダーアプリＢ１３７Ｂに対して、現在のジョブ設定情報を返却する。

その後、制御手段２５０は、表示手段２５６に対し、設定画面の表示要求を行う（ステップＳ１２８）。この際、制御手段２５０は、表示するジョブ設定情報（ステップＳ１１７で返却されたジョブ設定情報）をパラメータに付与する。

そして、表示手段２５６は、ステップＳ１１７で返却されたジョブ設定情報に従い、操作パネル２７に対して設定画面を表示する（ステップＳ１２９）。

このように本実施の形態によれば、ベンダーアプリＡ１３７Ａから機能提供アプリ１３６を呼び出している状態で、別のベンダーアプリＢ１３７Ｂから機能提供アプリ１３６を呼び出した際に、最初に呼び出したベンダーアプリＡ１３７Ａに現在のジョブ設定情報を通知する。そして、次回ベンダーアプリＡ１３７Ａを呼び出した際には、ベンダーアプリＡ１３７Ａが機能提供アプリ１３６から通知されたジョブ設定情報を機能提供アプリ１３６に通知するので、複数のベンダーアプリ１３７から機能提供アプリ１３６を呼び出した際にも、ユーザが途中まで変更したジョブ設定内容を保存・再現することできる。

（第４の実施の形態）
次に、第４の実施の形態について説明する。

第４の実施の形態は、現在要求中のベンダーアプリ１３７にジョブ設定情報を通知する際に、リトライが必要な旨を一緒に通知するようにした点が、第３の実施の形態と異なる。以下、第４の実施の形態の説明では、第３の実施の形態と同一部分の説明については省略し、第３の実施の形態と異なる箇所について説明する。

図１９は、第４の実施の形態にかかる機能提供アプリ１３６の設定画面表示動作の流れを示すシーケンス図である。図１９のシーケンス図は、「１．ベンダーアプリＡから機能提供アプリを呼び出して設定変更」、「２．ベンダーアプリＢから機能提供アプリを呼び出す」、「３．ベンダーアプリＡから機能提供アプリを呼び出す」という操作を順に行ったときに、３．の時に１．で変更した設定が復元されるシーケンスである。

図１９に示すステップＳ１０１～Ｓ１１５は、図１６に示すステップＳ１０１～Ｓ１１５と何ら変わるものではないため、その説明を省略する。

要求中のベンダーアプリの識別子（ベンダーアプリＡ１３７Ａの識別子）と新規に要求してきたベンダーアプリの識別子（ベンダーアプリＢ１３７Ｂの識別子）が異なる場合、制御手段２５０は、設定手段２５５から現在のジョブ設定情報を取得する（ステップＳ１１６）。

加えて、図１９に示すように、制御手段２５０は、要求中のベンダーアプリＡ１３７Ａに対して、現在のジョブ設定情報を通知する（ステップＳ１３１）。つまり、制御手段２５０は、ベンダーアプリＡ１３７Ａに対して、現在のジョブ設定情報を返却する。加えて、制御手段２５０は、この際、要リトライのパラメータを付与する。

その後、制御手段２５０は、表示手段２５６に対し、設定画面の表示要求を行う（ステップＳ１１８）。

表示手段２５６は、設定手段２５５にアクセスすることで、ジョブ設定情報を取得する（ステップＳ１１９）。ここでは、新規に画面を作り直すため、ジョブ設定情報を取得しなおすことになる。その後、表示手段２５６は、操作パネル２７に対して設定画面を表示する（ステップＳ１２０）。

さらに、ベンダーアプリＢ１３７Ｂから機能提供アプリ１３６を呼び出している状態で、別のベンダーアプリＡ１３７Ａから機能提供アプリ１３６を呼び出した場合について説明する。

ベンダーアプリＢ１３７Ｂから機能提供アプリ１３６を呼び出している状態において、ユーザにより、ホーム画面を介してベンダーアプリＡ１３７Ａが起動されると（ステップＳ１２１）、図１９に示すように、ベンダーアプリＡ１３７Ａは、要リトライの通知を受けている場合、機能提供アプリ１３６に対して画面表示要求を行う（ステップＳ１３２）。第３の実施の形態では、設定ボタンの操作（ステップＳ１２２）をトリガーとして機能提供アプリ１３６に対して画面表示要求を行うようにしていたが、本実施の形態では、自動的に機能提供アプリ１３６に対して画面表示要求を行うようにしたものである。

図１９に示すステップＳ１２４～Ｓ１２９は、図１６に示すステップＳ１２４～Ｓ１２９と何ら変わるものではないため、その説明を省略する。

このように本実施の形態によれば、ベンダーアプリ１３７から機能提供アプリ１３６を一度開いた場合に、再度ベンダーアプリ１３７を開いた場合に、自動的に機能提供アプリ１３６を開くことができる。

例えば、汎用ＯＳの仕様が原因でアプリが複数起動され、最初に起動したアプリがバックグラウンドにいる場合、最初に起動したアプリの画面(Activity)が破棄されることがある。本実施の形態によれば、表示していた画面がこれらの理由で破棄されてしまった場合でも、自動でリトライ制御が行えるとともに、最初に設定した設定値で、最初に起動したアプリを介して入力・表示した設定画面を表示しなおすことができる。

（第５の実施の形態）
次に、第５の実施の形態について説明する。

第５の実施の形態は、機能提供アプリ１３６を呼び出して実行したジョブでエラーが発生した場合にユーザに正しくエラーを通知することができるようにした点が、第３の実施の形態または第４の実施の形態と異なる。以下、第５の実施の形態の説明では、第３の実施の形態または第４の実施の形態と同一部分の説明については省略し、第３の実施の形態または第４の実施の形態と異なる箇所について説明する。

図２０は、第５の実施の形態にかかるＭＦＰ１の機能提供アプリ１３６の機能ブロック図である。操作部２０のＣＰＵ２１は、例えばＲＯＭ２２、ＲＡＭ２３又はフラッシュメモリ２４等の記憶部に記憶されている機能提供アプリ１３６を実行することで、図２０に示すように、制御手段２５０、受付手段２５１、入力手段２５３、ジョブ実行手段２５４、及び表示手段２５６を実現する。

受付手段２５１は、機能提供アプリ１３６のアイコンが操作された場合に生成される起動要求、又は、ベンダーアプリ１３７からの起動要求を受け付ける。

制御手段２５０は、新規に呼び出しを受け付けた後に、画面表示やジョブ実行などを行う。

入力手段２５３は、ユーザによる操作パネル２７の操作に応じて、操作パネル２７に表示した画面に対するユーザの入力を受け付ける。

表示手段２５６は、操作パネル２７に対して実行画面／エラー画面等の表示制御を行う。表示手段２５６は、実行画面／エラー画面を介してユーザにより設定された設定内容をベンダーアプリ１３７に通知する等の処理を行う。

ジョブ実行手段２５４は、本体１０のコピーアプリ１１１又はスキャナアプリ１１２等に決定した設定値を利用して所望の動作のジョブ実行要求を行う。

なお、この例では、制御手段２５０、受付手段２５１、入力手段２５３、ジョブ実行手段２５４、表示手段２５６をソフトウェアで実現することとしたが、制御手段２５０、受付手段２５１、入力手段２５３、ジョブ実行手段２５４、表示手段２５６のうち、一部又は全部を、ＩＣ（Integrated Circuit）等のハードウェアで実現してもよい。

（機能提供アプリの動作）
次に、機能提供アプリ１３６の動作を説明する。図２１は、ベンダーアプリ１３７でジョブを実行する場合における、機能提供アプリ１３６の画面表示動作の流れを示すシーケンス図である。なお、以下ではプリントジョブを実行する場合を例にして説明するが、コピージョブ、スキャンジョブ、ＦＡＸジョブなどの他のジョブを実行する場合でも同様に処理を行うことができる。

図２１に示すように、ユーザにより、ホーム画面Ａを介してベンダーアプリ１３７が起動され（ステップＳ２０１）、実行ボタンＢ２が操作されると（ステップＳ２０２）、ベンダーアプリ１３７は、機能提供アプリ１３６に対してジョブ実行要求を行う（ステップＳ２０３）。なお、ベンダーアプリ１３７は、この際、印刷ファイルの情報をパラメータに付与する。また、印刷ファイルの情報として、プリント設定を含んでも良い。

次いで、機能提供アプリ１３６の受付手段２５１は、このジョブ実行要求を受信し、制御手段２５０に対してジョブ実行要求（印刷ファイルの情報）を行う（ステップＳ２０４）。

次に、制御手段２５０は、表示手段２５６に対してジョブ実行画面表示要求を行う（ステップＳ２０５）。

そして、表示手段２５６は、ジョブ実行画面であるプリント実行画面Ｄを生成して、操作パネル２７に表示する（ステップＳ２０６）。

次いで、制御手段２５０は、ジョブ実行手段２５４に対してジョブ実行要求（印刷ファイルの情報）を行う（ステップＳ２０７）。

ジョブ実行手段２５４は、本体１０のプリントアプリに対してジョブ実行を行う（ステップＳ２０８）。

ここで、エラーが発生した場合について説明する。

エラーが発生すると、本体１０のプリントアプリは、機能提供アプリ１３６のジョブ実行手段２５４にジョブエラーを通知する（ステップＳ２０９）。なお、本体１０のプリントアプリは、この際、エラー種別をパラメータに付与する。

ジョブ実行手段２５４は、このジョブエラー（エラー種別）を受信し、制御手段２５０に対してジョブエラー（エラー種別）の通知を行う（ステップＳ２１０）。

次に、制御手段２５０は、表示手段２５６に対してエラー画面表示要求を行う（ステップＳ２１１）。

そして、表示手段２５６は、エラー画面を生成して、操作パネル２７に表示する（ステップＳ２１２）。

本実施の形態においては、発生したエラーのエラー種別に従って、以下の通りに機能提供アプリ１３６の振る舞いが異なる。

（エラー種別：復旧不可能なエラーの場合）
例えば、本体１０のエンジン１７であるプロッタデバイスの故障やスキャナデバイスの故障などが該当する。

復旧不可能なエラーの場合、制御手段２５０は、上述のように表示手段２５６に対してエラー画面表示要求を行った後（ステップＳ２１１）、即座にベンダーアプリ１３７に対してジョブ実行結果通知を行う（ステップＳ２１３）。この際、制御手段２５０は、エラーをパラメータに付与する。

ここで、図２２は復旧不可能なエラーが発生した場合のエラー画面の一例を示す図である。図２２に示すように、復旧不可能なエラーが発生した場合、「エラーが発生しました。サービスに連絡してください。」というようなエラー画面が表示される。

復旧不可能なエラーが発生している場合、ユーザはエラーを解除することができない。そこで、この場合、エラー発生と同時にベンダーアプリ１３７に対してジョブ実行結果通知を行う。これにより、機能提供アプリ１３６を非表示にして再度ベンダーアプリ１３７を起動しても機能提供アプリ１３６は呼び出されない（後述するシーケンスのステップＳ２２０は実行されない）。

この振る舞いは、ベンダーアプリ１３７が機能提供アプリ１３６で複数の機能を呼び出すケースを想定している。例えば、ベンダーアプリ１３７が機能提供アプリ１３６のスキャンとプリントの機能を使う場合、スキャン側で復旧不可能なエラーが発生した場合でもプリント側は使用可能な場合がある。その場合、ベンダーアプリ１３７を立ち上げて必ずスキャンのエラー画面を出してしまうとプリント機能を使用できなくなる。以上より、復旧不可能なエラーが発生した場合には、ジョブ実行結果通知を即座に通知することで、別の機能について使用可能にする。

（エラー種別：復旧可能なエラーの場合）
例えば、本体１０のエンジン１７であるプロッタデバイスにおける紙ジャム、メモリフルなどが該当する。

復旧可能なエラーの場合、制御手段２５０は、上述のように表示手段２５６に対してエラー画面表示要求を行った後（ステップＳ２１１）、ユーザによるエラー解除に待機する（ステップＳ２１４）。

ここで、図２３は復旧可能なエラーが発生した場合のエラー画面の一例を示す図である。図２３（ａ）に示すエラー画面は、解除するためにユーザアクションが不要なエラーの場合に表示される画面である（例：メモリフルなど）。この場合は、確認キーＫ２のユーザによる押下をトリガーとして、ベンダーアプリ１３７に対してジョブ実行結果通知が行われる。図２３（ｂ）に示すエラー画面は、解除するためにユーザアクションが必要なエラーの場合に表示される画面である（例：ジャムが発生した場合など）。この場合は、解除動作を実施する（ジャム紙を取り除くなど）ことで、ベンダーアプリ１３７に対してジョブ実行結果通知が行われる。

ユーザによるエラー解除したことが入力されると、入力手段２５３は、制御手段２５０に対してエラー解除を通知する（ステップＳ２１５）。

制御手段２５０は、表示手段２５６に対してエラー画面非表示要求を行う（ステップＳ２１６）。

そして、表示手段２５６は、操作パネル２７に表示されているエラー画面を非表示にする（ステップＳ２１７）。

そして、制御手段２５０は、ベンダーアプリ１３７に対してジョブ実行結果通知を行う（ステップＳ２１８）。この際、制御手段２５０は、エラーをパラメータに付与する。

ユーザにより、ホーム画面Ａを介してベンダーアプリ１３７が起動されると（ステップＳ２１９）、ジョブ実行要求中の場合、ベンダーアプリ１３７は、機能提供アプリ１３６を呼び出す（ステップＳ２２０）。

このようにするのは、復旧可能なエラーが発生している場合、ユーザにエラーを解除させる必要があるため、機能提供アプリ１３６を一旦非表示にして再度ベンダーアプリ１３７を表示させても、エラー画面を表示させる必要があるからである。エラーが解除されるまではジョブ実行要求中のままにして、ベンダーアプリ１３７から機能提供アプリ１３６を呼び出してもらうために、エラー解除後にジョブ実行結果通知を行う。

ここで、ステップＳ２１３でジョブ実行結果通知を受け取ったベンダーアプリ１３７の動作について説明する。

ここで、図２４は復旧不可能なエラーが通知された場合のベンダーアプリ１３７の動作の一例を示すシーケンス図である。

図２４に示すように、通知されたエラーが復旧不可能な致命的エラーである場合、ベンダーアプリ１３７は、再度、機能提供アプリ１３６を呼び出しても無駄なため、実行ボタンＢ２を半輝度に変化させて押下不可にする（ステップＳ３０１）。

また、図２５は復旧不可能なエラーが通知された場合のベンダーアプリ１３７の動作の一例を示すシーケンス図である。

図２５に示すように、通知されたエラーが復旧不可能な致命的エラーである場合、ベンダーアプリ１３７は、再度、機能提供アプリ１３６を呼び出しても無駄なため、エラーが発生したことを、ベンダーアプリ１３７からサーバＳに通知する（ステップＳ３０２）。

このように本実施の形態によれば、機能提供アプリ１３６が実行したジョブで発生したエラーのエラー種別に応じてエラーダイアログを表示し、またエラー種別に応じて機能提供アプリ１３６から呼び出し元のベンダーアプリ１３７に結果を通知するタイミングを切り替えるので、機能提供アプリ１３６を呼び出して実行したジョブでエラーが発生した場合にユーザに正しくエラーを通知することができる。

（第６の実施の形態）
次に、第６の実施の形態について説明する。

第６の実施の形態は、ベンダーアプリ１３７が、現在自分自身が機能提供アプリ１３６に要求中かどうかの判定を不要にした点が、第３の実施の形態ないし第５の実施の形態と異なる。以下、第６の実施の形態の説明では、第３の実施の形態ないし第５の実施の形態と同一部分の説明については省略し、第３の実施の形態ないし第５の実施の形態と異なる箇所について説明する。

ここで、第６の実施の形態にかかる機能提供アプリ１３６の動作を説明する。図２６は、第６の実施の形態にかかるベンダーアプリ１３７でジョブを実行する場合における、機能提供アプリ１３６の画面表示動作の流れを示すシーケンス図である。

図２６に示すように、ユーザにより、ホーム画面Ａを介してベンダーアプリ１３７が起動され（ステップＳ２０１）、実行ボタンＢ２が操作されると（ステップＳ２０２）、ベンダーアプリ１３７は、機能提供アプリ１３６に対してジョブ実行要求を行う（ステップＳ２３１）。なお、ベンダーアプリ１３７は、この際、印刷ファイルの情報と呼び出し元のベンダーアプリ１３７のアプリ情報をパラメータに付与する。

図２６に示すステップＳ２０４～Ｓ２１８は、図２１に示すステップＳ２０４～Ｓ２１８と何ら変わるものではないため、その説明を省略する。

ユーザにより、ホーム画面Ａを介してベンダーアプリ１３７が起動されると（ステップＳ２１９）、ベンダーアプリ１３７は、受付手段２５１に対して再表示要求を行う（ステップＳ２３２）。この際、ベンダーアプリ１３７は、呼び出し元のベンダーアプリ１３７のアプリ情報をパラメータに付与する。

受付手段２５１は、現在要求中のアプリからの再表示要求かどうかを判定して、現在要求中のアプリと再表示要求をしてきたアプリが同一の場合、起動する（ステップＳ２３３）。

このように本実施の形態によれば、ベンダーアプリ１３７が、現在自分自身が機能提供アプリ１３６に要求中かどうかを判定する必要がなくなり、ベンダーアプリ１３７の実装が簡単になる。

なお、上記各実施の形態では、本発明の画像処理装置（電子機器）を、コピー機能、プリンタ機能、スキャナ機能およびファクシミリ機能のうち少なくとも２つの機能を有する複合機に適用した例を挙げて説明するが、複写機、プリンタ、スキャナ装置、ファクシミリ装置等の少なくともスキャナまたはプリンタを有して画像処理を実行する画像処理装置であればいずれにも適用することができる。

なお、電子機器は、通信機能を備えた装置であれば、ＭＦＰ１に限られない。電子機器は、例えば、ＰＪ（Projector：プロジェクタ）、ＩＷＢ（Interactive White Board：相互通信が可能な電子式の黒板機能を有する白板）、デジタルサイネージ等の出力装置、ＨＵＤ（Head Up Display）装置、産業機械、製造装置、撮像装置、集音装置、医療機器、ネットワーク家電、ノートＰＣ（Personal Computer）、携帯電話、スマートフォン、タブレット端末、ゲーム機、ＰＤＡ（Personal Digital Assistant）、デジタルカメラ、ウェアラブルＰＣまたはデスクトップＰＣ等であってもよい。

上記で説明した実施形態の各機能は、一又は複数の処理回路によって実現することが可能である。ここで、本明細書における「処理回路」とは、電子回路により実装されるプロセッサのようにソフトウェアによって各機能を実行するようプログラミングされたプロセッサや、上記で説明した各機能を実行するよう設計されたＡＳＩＣ（Application Specific Integrated Circuit）、ＤＳＰ（Digital Signal Processor）、ＦＰＧＡ（Field Programmable Gate Array）や従来の回路モジュール等のデバイスを含むものとする。

上記で説明した複数の実施形態のシーケンス、制御や操作は、自在に組み合わせ、または同時に並行して電子機器または画像処理装置で実行、処理することが可能である。これによってベンダーアプリと機能提供アプリとの関係や、複数のベンダーアプリ間の関係において、表示内容の違いによるユーザの違和感を低減する効果や、各パラメータ及び設定情報の受け渡しを簡易に行って設定を反映することができる効果がある。

上記で説明した「ベンダーアプリ」は、その他の表現として、
・機能提供アプリケーションに処理を要求する「要求アプリケーション」
・サードベンダやユーザ等が開発し機器の操作部に追加インストールする「追加アプリケーション」
・操作部上で機能提供アプリケーションの提供する仕組み（ＵＩやＡＰＩなど）を利用する「利用アプリケーション」などと言うこともできる。

また、「機能提供アプリケーション」は、電子機器及び画像処理装置の操作部に備えるＯＳの下でＣＰＵにより動作し操作部上で動作する他のアプリケーションにＡＰＩを提供する「ＡＰＩアプリケーション」や「操作部ＡＰＩアプリケーション」などと言うこともできる。

１ 電子機器、画像処理装置
１０ 本体部
１１ 第１のＣＰＵ
２０ 操作部
２１ 第２のＣＰＵ
１５０ 第１の制御手段
１５１ 第１の受付手段
１５２ 第１の記憶手段
１５６ 第１の表示手段
２５０ 第２の制御手段
２５１ 第２の受付手段
２５２ 第２の記憶手段
２５４ ジョブ実行手段
２５５ 設定手段
２５６ 第２の表示手段

特開２０１４－１５０３２０号公報

Claims (10)

1. 少なくとも１つのアプリケーションと、
   前記アプリケーションから、画面の表示態様に関するパラメータを含む前記画面の表示要求を受け付ける第１の受付手段と、
   前記第１の受付手段により受け付けた前記表示要求に応じた前記画面の表示態様を前記パラメータに基づいて変更した前記画面を表示する第１の表示手段と、
   を有する機能提供アプリケーションと、
   電子機器の機能を実行制御する制御アプリケーションとを備え、
   前記機能提供アプリケーションは、
   前記第１の表示手段が表示した、表示態様を前記パラメータに基づいて変更した前記画面を介して、ユーザから受け付けた設定情報に基づいて前記機能の実行を前記制御アプリケーションに対して要求する第１の制御手段と、
   をさらに備えることを特徴とする電子機器。
2. 前記第１の受付手段により受け付けた前記パラメータとユーザを識別するユーザ情報との組み合わせを記憶部に記憶する第１の記憶手段を更に備え、
   前記第１の表示手段は、前記記憶部から前記ユーザ情報と前記パラメータとの組み合わせを取得し、取得した前記パラメータに基づいて前記画面の表示態様を変更する、
   ことを特徴とする請求項１に記載の電子機器。
3. 前記機能提供アプリケーションは、
   前記制御アプリケーションに対する前記電子機器の機能の実行にかかる要求および前記要求に対して付与される識別子に関するパラメータを前記アプリケーションから受け付ける第２の受付手段と、
   前記第２の受付手段により受け付けた前記要求と前記パラメータとを記憶部に記憶する第２の記憶手段と、
   前記要求に応じた設定情報の調整を行う設定手段と、
   前記第２の受付手段により受け付けた前記要求に応じた前記電子機器の機能の実行を前記制御アプリケーションに対して要求する第２の制御手段と、
   を備え、
   前記第２の制御手段は、異なる識別子に関するパラメータが付与された前記要求を、前記アプリケーションとは異なる他のアプリケーションから前記第２の受付手段により受け付けた場合、前記設定手段から要求中の前記設定情報を取り出し、前記アプリケーションに対して、当該設定情報を通知し、
   前記アプリケーションは、前記第２の受付手段に対する前記要求を再度行う際、通知された前記設定情報と前記識別子と前記設定情報をパラメータに付与する、
   ことを特徴とする請求項２に記載の電子機器。
4. 前記第２の制御手段は、前記アプリケーションに対して、前記設定情報を通知する際に、リトライが必要な旨を併せて通知する、
   ことを特徴とする請求項３に記載の電子機器。
5. 前記第２の制御手段は、前記第２の記憶手段に対して、前記識別子に加えて現在の設定情報を記憶させる、
   ことを特徴とする請求項３または４に記載の電子機器。
6. 画面を表示する第２の表示手段と、
   前記制御アプリケーションからエラー種別を付したジョブエラーを受信し、前記第２の制御手段に対して前記ジョブエラーの通知を行うジョブ実行手段と、
   を更に備え、
   前記第２の制御手段は、前記ジョブエラーの通知を受けると、前記第２の表示手段に対して前記エラー種別に応じたエラー画面表示要求を行い、前記エラー種別が復旧不可能なエラーの場合、前記アプリケーションに対してジョブ実行結果通知を行い、また、前記エラー種別が復旧可能なエラーの場合、エラーの解除通知をトリガーとして前記第２の表示手段に対してエラー画面非表示要求を行う、
   ことを特徴とする請求項３に記載の電子機器。
7. 前記電子機器は、少なくともスキャナまたはプリンタを有して画像処理を実行する画像処理装置であり、
   前記機能提供アプリケーションは、
   前記パラメータを含む前記アプリケーションからの要求に応じて表示され、画像処理の設定入力または画像処理の実行指示を選択するための選択画面と、前記設定入力を選択した場合に表示される画像処理の設定入力画面とを、前記パラメータに基づいて、前記アプリケーションと少なくとも同じ背景色または背景画像を含む表示態様で表示し、
   前記制御アプリケーションは、入力された画像処理の前記設定入力に基づき、前記画像処理を実行する、
   ことを特徴とする請求項１に記載の電子機器。
8. 前記画像処理装置は、
   前記制御アプリケーションを実行する第１のＣＰＵ（Central Processing Unit）を有する画像処理を実行する本体部と、
   前記アプリケーション及び前記機能提供アプリケーションを実行する第２のＣＰＵを有し、ユーザから画像処理の実行指示の操作を受け付ける操作部と、
   を備え、
   前記第２のＣＰＵが、前記機能提供アプリケーションの表示画面で、画像処理の設定入力及び、画像処理の実行指示を指示するユーザの入力を受け付けると、前記入力に応じて操作部から本体部に要求を送り、前記第１のＣＰＵが前記制御アプリケーションを用いて前記設定入力で画像処理を実行する、
   ことを特徴とする請求項７に記載の電子機器。
9. 電子機器で実行される画面表示方法であって、
   少なくとも１つのアプリケーションから、画面の表示態様に関するパラメータを含む前記画面の表示要求を受け付ける受付工程と、
   前記受付工程により受け付けた前記表示要求に応じた前記画面の表示態様を前記パラメータに基づいて変更した前記画面を表示する表示工程と、
   前記表示工程が表示した、表示態様を前記パラメータに基づいて変更した前記画面を介して、ユーザから受け付けた設定情報に基づいて前記電子機器の機能の実行を要求する制御工程と、
   を含むことを特徴とする画面表示方法。
10. 電子機器を制御するコンピュータを、
    少なくとも１つのアプリケーションから、画面の表示態様に関するパラメータを含む前記画面の表示要求を受け付ける受付機能と、
    前記受付機能により受け付けた前記表示要求に応じた前記画面の表示態様を前記パラメータに基づいて変更した前記画面を表示する表示機能と、
    前記表示機能が表示した、表示態様を前記パラメータに基づいて変更した前記画面を介して、ユーザから受け付けた設定情報に基づいて前記電子機器の機能の実行を要求する制御機能と、
    として機能させるためのプログラム。

Images