(57)【要約】【課題】  １又は複数の情報処理装置により実現される情報処理システムにおいて、メッセージの見やすい表示を低コストで行えるようにする。【解決手段】  １又は複数の情報処理装置により実現される情報処理システムにおいて、メッセージの表示指示であって表示内容を指定する用語ＩＤを含むものを検出し、用語ＩＤと表示用の文字列とを対応付けて記憶する用語テーブルから、上記検出した表示指示に含まれる用語ＩＤと対応する文字列を取得し（Ｓ２）、その取得した文字列の文字数に応じて上記表示指示に係るメッセージの表示形式を選択し（Ｓ５）、その選択した表示形式で、上記取得した文字列を表示手段に表示させるようにした（Ｓ６）。【選択図】        図８
2014179038.tif 000002
【特許請求の範囲】
【請求項１】
１又は複数の情報処理装置により実現される情報処理システムであって、
メッセージの表示指示であって表示内容を指定する用語ＩＤを含むものを検出する検出手段と、
用語ＩＤと表示用の文字列とを対応付けて記憶する用語情報記憶手段から、前記検出手段が検出した表示指示に含まれる用語ＩＤと対応する文字列を取得する取得手段と、
前記取得手段が取得した文字列の文字数に応じて前記表示指示に係るメッセージの表示形式を選択する選択手段と、
前記選択手段が選択した表示形式で、前記取得手段が取得した文字列を表示手段に表示させる表示制御手段とを備えたことを特徴とする情報処理システム。
【請求項２】
請求項１に記載の情報処理システムであって、
前記選択手段が、表示すべきメッセージの数に応じて該メッセージの表示形式を選択することを特徴とする情報処理システム。
【請求項３】
請求項１又は２に記載の情報処理システムであって、
前記選択手段が、メッセージを表示してからの時間経過に応じて該メッセージの表示形式を変更する手段を備えることを特徴とする情報処理システム。
【請求項４】
請求項１乃至３のいずれか一項に記載の情報処理システムであって、
前記取得手段が、用語ＩＤの共通する表示を複数行う場合に、該複数の表示をまとめて行うための文字列を前記用語情報記憶手段から取得する手段を備えることを特徴とする情報処理システム。
【請求項５】
１又は複数の情報処理装置により実現される情報処理システムであって、
メッセージの表示指示であって表示内容を指定する用語ＩＤを含むものを検出する検出手段と、
用語ＩＤと表示用の文字列とを対応付けて記憶する用語情報記憶手段から、前記検出手段が検出した表示指示に含まれる用語ＩＤと対応する文字列を取得する取得手段と、
表示すべきメッセージに含まれる用語ＩＤの数に応じて前記表示指示に係るメッセージの表示形式を選択する選択手段と、
前記選択手段が選択した表示形式で、前記取得手段が取得した文字列を表示手段に表示させる表示制御手段とを備えたことを特徴とする情報処理システム。
【請求項６】
１の情報処理装置が、または複数の情報処理装置が協働して、
メッセージの表示指示であって表示内容を指定する用語ＩＤを含むものを検出する検出手順と、
用語ＩＤと表示用の文字列とを対応付けて記憶する用語情報記憶手段から、前記検出手順で検出した表示指示に含まれる用語ＩＤと対応する文字列を取得する取得手順と、
前記取得手順で取得した文字列の文字数に応じて前記表示指示に係るメッセージの表示形式を選択する選択手順と、
前記選択手順で選択した表示形式で、前記取得手順で取得した文字列を表示手段に表示させる表示制御手順とを実行することを特徴とする情報処理方法。
【請求項７】
請求項６に記載の情報処理方法であって、
前記選択手順は、表示すべきメッセージの数に応じて該メッセージの表示形式を選択する手順であることを特徴とする情報処理方法。
【請求項８】
請求項６又は７に記載の情報処理方法であって、
前記選択手順は、メッセージを表示してからの時間経過に応じて該メッセージの表示形式を変更する手順を備えることを特徴とする情報処理方法。
【請求項９】
請求項６乃至８のいずれか一項に記載の情報処理方法であって、
前記取得手順が、用語ＩＤの共通する表示を複数行う場合に、該複数の表示をまとめて行うための文字列を前記用語情報記憶手段から取得する手順を備えることを特徴とする情報処理システム。
【請求項１０】
１の情報処理装置が、または複数の情報処理装置が協働して、
メッセージの表示指示であって表示内容を指定する用語ＩＤを含むものを検出する検出手順と、
用語ＩＤと表示用の文字列とを対応付けて記憶する用語情報記憶手段から、前記検出手順で検出した表示指示に含まれる用語ＩＤと対応する文字列を取得する取得手順と、
表示すべきメッセージに含まれる用語ＩＤの数に応じて前記表示指示に係るメッセージの表示形式を選択する選択手順と、
前記選択手順で選択した表示形式で、前記取得手順で取得した文字列を表示手段に表示させる表示制御手順とを実行することを特徴とする情報処理方法。
【請求項１１】
１のコンピュータを、または複数のコンピュータを協働させて、請求項１乃至５のいずれか一項に記載の情報処理システムとして機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、１又は複数の情報処理装置により実現される情報処理システム、このような情報処理システムにおける情報処理方法、及び１又は複数のコンピュータに実行させるプログラムに関する。
【背景技術】
【０００２】
従来から、情報処理システムでは、アプリケーション（単に「アプリ」ともいう）がイベントを検出し、そのイベントに応じてメッセージ等をユーザヘ提示すべき場合に、そのメッセージの文字列を表示画面上に表示させることが行われている。
そして、上記文字列を表示させる場合、アプリに、イベントに含まれている用語ＩＤに基づき必要な文字列を取得させることも行われている。
【０００３】
上記の従来の情報処理システムにおいて、上記アプリは、上記メッセージの表示を行う場合、自己に関連付けて必要な用語リソースを保持している。用語リソースとは、用語ＩＤと表示すべき文字列との対応を示すテーブル等に相当するものである。
また、アプリに、取得した文字列を表示するための固定的な表示エリアを規定するデータを保持させ、アプリが用語ＩＤに基づき取得した文字列を、そのデータが示す表示エリアに表示させることも行われている。
【０００４】
一方、上述した画面表示に関連する技術としては、例えば特許文献１〜３に記載のものが知られている。
特許文献１には、サーバからネットワーク経由でアドレスの通知を受け、そのアドレスにアクセスしてそこから画面情報を取得して、それを表示画面上に表示する情報表示システムについて開示されている。
特許文献２には、外部デバイス用データから外部デバイス用情報（画面情報）を読み込み、それを表示画面上に表示する画像形成装置について開示されている。
特許文献３には、ヘルプメッセージを含むメッセージ表示領域を表示する表示位置の位置座標と記憶装置から読み出した位置座標とが一致するように、ウィンドウとメッセージ表示領域の各々とを関連付けて表示画面に表示させる表示装置について開示されている。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、上述したような従来の技術では、次のような問題があった。すなわち、特にアプリの数が多い場合、各アプリが、メッセージの内容を必ずしも適切な形式（表示位置も含む）で表示させることはできなかった。
【０００６】
情報処理システムでは、本体の状態変化通知や設定変化通知、エラー通知など、１０００種類以上のイベントがあることも多いため、全てのイベントについて対応する適切な表示形式をアプリに設定しておくことが難しかったためである。容量の問題があるし、メッセージの追加や変更がある度に、全てのアプリについて、メッセージと対応する表示形式を定めるデータを更新しなければならない。
また、アプリがメッセージの内容を解釈して動的に表示形式を選択できるようにするロジックをメッセージ数分準備することも、負担が大きかった。
【０００７】
なお、メッセージに表示すべき文字列を直接記載せず、用語ＩＤを記載してこれと対応する表示用文字列を取得する構成は、他言語対応のために有用である。しかし、この構成を採ると、言語によってメッセージの文字数が変わるため、メッセージと対応付けて適切な表示形式を予め定めておくことは、一層難しかった。
このため、メッセージと対応する文字列が長すぎて用意した表示領域に入り切らなかったり、逆に表示領域が広すぎてメッセージ以外の表示が見づらくなってしまったりすることもあった。
この点については、特許文献１乃至３に記載の発明を用いても効果的な対応はできなかった。
【０００８】
この発明は、上記の点に鑑みてなされたものであり、１又は複数の情報処理装置により実現される情報処理システムにおいて、メッセージの見やすい表示を低コストで行えるようにすることを目的とする。
【課題を解決するための手段】
【０００９】
以上の目的を達成するため、この発明は、１又は複数の情報処理装置により実現される情報処理システムにおいて、メッセージの表示指示であって表示内容を指定する用語ＩＤを含むものを検出する検出手段と、用語ＩＤと表示用の文字列とを対応付けて記憶する用語情報記憶手段から、上記検出手段が検出した表示指示に含まれる用語ＩＤと対応する文字列を取得する取得手段と、上記取得手段が取得した文字列の文字数に応じて上記表示指示に係るメッセージの表示形式を選択する選択手段と、上記選択手段が選択した表示形式で、上記取得手段が取得した文字列を表示手段に表示させる表示制御手段とを設けたものである。
【発明の効果】
【００１０】
上記構成によれば、１又は複数の情報処理装置により実現される情報処理システムにおいて、メッセージの見やすい表示を低コストで行えるようにすることができる。
【図面の簡単な説明】
【００１１】
【図１】この発明の情報処理システムの一実施形態である画像処理システムの利用環境を示す図である。
【図２】図に示した画像処理システムのハードウェア構成を示すブロック図である。
【図３】図２に示した本体及び操作部のソフトウェア構成を操作部とネットワークの通信に関する機能と共に示す図である。
【図４】図２に示した操作部が本体から送信されるイベントを検出した場合の、該イベントと対応するメッセージの表示動作の例を示す図である。
【図５】用語テーブルの例を示す図である。
【図６】用語の問い合わせに関する動作シーケンスの例を示す図である。
【図７】その別の例を示す図である。
【図８】図２に示した操作部のＣＰＵがイベントの検出時に実行する、用語ＩＤと対応する文字列の取得及び表示に係る処理のフローチャートである。
【図９】ダイアログ表示の例を示す図である。
【図１０】バナー表示の例を示す図である。
【図１１】メッセージ表示の例を示す図である。
【図１２】メッセージの表示に関するデータの例を示す図である。
【図１３】表示形式選択処理の第１例を示すフローチャートである。
【図１４】用語ＩＤの数と表示形式との対応関係の例を示す図である。
【図１５】表示形式選択処理の第２例を示すフローチャートである。
【図１６】表示用文字列の文字数と表示形式との対応関係の例を示す図である。
【図１７】表示形式選択処理の第３例を示すフローチャートである。
【図１８】メッセージＩＤの数と表示形式との対応関係の例を示す図である。
【図１９】可変文字列を用いたメッセージの表示例を示す図である。
【図２０】まとめ表示を行うための処理のフローチャートである。
【図２１】第２の変形例におけるメッセージ表示の遷移例を示す図である。
【図２２】メッセージ表示開始からの時間と、選択すべき表示形式との対応関係の例を示す図である。
【図２３】表示形式の変更に係る処理のフローチャートである。
【発明を実施するための形態】
【００１２】
以下、この発明を実施するための形態について、具体的に説明する。
まず図１に、この発明の情報処理システムの一実施形態である画像処理システムの利用環境を示す。
【００１３】
画像処理システム１は、通信機能を有するＭＦＰ（複合機：Multifunction Peripheral）であり、例えばコピー機能，スキャナ機能，ファクス機能，プリンタ機能を備えている。これらの機能に関わる処理は、ユーザが画像処理システム１を直接操作することによって実行することができる。
また、画像処理システム１は、クライアントＰＣ（パーソナルコンピュータ）等の外部装置２とネットワーク３を介して通信可能であり、その外部装置２から受信した指示に従って上記機能に関わる処理を実行することもできる。
【００１４】
図２は、図１の画像処理システム１のハードウェア構成を示すブロック図である。
この画像処理システム１は、図２に示すように、ユーザの操作（ユーザからの指示）を受け付ける操作部２０と、操作部２０が受け付けた操作に基づき動作を実行する動作部である本体１０とを備え、それらを専用の通信路３０により相互に通信可能に接続した構成である。通信路３０は、この実施形態では制御線と電源線とからなるが、それらを別々にしても構わない。
【００１５】
なお、本体１０は、操作部２０が受け付けた操作に応じた動作だけでなく、上述のように外部装置２から受信した指示に応じた動作も行うことができる。また、後述するイベントが発生すると、それを操作部２０へ送信する動作を行うこともできる。更に、通信路３０は、例えばＵＳＢ（Universal Serial Bus）規格のものを用いることができる。しかし、有線、無線を問わず任意の規格のものでよい。１対１通信であっても、ネットワーク通信であってもよい。例えば、ＵＳＢの他、シリアル、有線または無線ＬＡＮ（ローカルエリアネットワーク）、ブルートゥース（Bluetooth：登録商標）、ＩｒＤＡ（Infrared
Data Association）等を用いることが考えられる。上記イベントを送信する動作は有線／無線問わずに同様に行える。
【００１６】
本体１０は、ＣＰＵ１１、ＲＯＭ１２、ＲＡＭ１３、ＨＤＤ１４（ハードディスクドライブ）、通信Ｉ／Ｆ（インタフェース）１５、接続Ｉ／Ｆ１６、及びエンジン部１７を備え、それらをシステムバス１８により接続した構成としている。そして、ＣＰＵ１１が、ＲＡＭ１３をワークエリアとしてＲＯＭ１２又はＨＤＤ１４に記憶されたプログラムを実行することにより、本体１０全体を制御し、後述する操作部２０へのイベント通知を含む操作部２０との通信制御をはじめとする各種機能を実現する。
【００１７】
ＨＤＤ１４は、不揮発性記憶媒体（記憶手段）であり、ＣＰＵ１１が実行する各種プログラムを含む各種データを格納（記憶）している。
通信Ｉ／Ｆ１５は、ネットワーク３を介してクライアントＰＣ等の外部装置２と通信するためのインタフェースである。
【００１８】
接続Ｉ／Ｆ１６は、通信路３０を介して操作部２０と通信するためのインタフェースである。ここではＵＳＢ規格のインタフェースとしている。
なお、通信Ｉ／Ｆ１５は、有線、無線を問わず任意の規格のものを採用可能である。接続Ｉ／Ｆ１６と共通化してもよい。通信Ｉ／Ｆ１５及び接続Ｉ／Ｆ１６としてそれぞれ複数のＩ／Ｆを設けてもよい。
【００１９】
エンジン部１７は、コピー機能，スキャナ機能，ファクス機能，プリンタ機能を実現させるための、汎用的な情報処理及び通信以外の処理を行うハードウェアである。例えば、原稿の画像をスキャンして読み取るスキャナ（画像読取部）、用紙等のシート材への印刷を行うプロッタ（画像形成部）、ファクス通信を行う通信部などを備えている。更に、印刷済みシート材を仕分けるフィニッシャや、原稿を自動給送するＡＤＦ（自動原稿給送装置）のような特定のオプションを備えることもできる。
【００２０】
一方、操作部２０は、ＣＰＵ２１、ＲＯＭ２２、ＲＡＭ２３、フラッシュメモリ２４、通信Ｉ／Ｆ２５、接続Ｉ／Ｆ２６、及び操作パネル２７を備え、それらをシステムバス２８により接続した構成としている。そして、ＣＰＵ２１が、ＲＡＭ２３をワークエリアとしてＲＯＭ２２又はフラッシュメモリ２４に記憶されたプログラムを実行することにより、操作部２０全体を制御し、本体１０からのイベントの受信（検出）を含む本体１０との通信制御をはじめとする各種機能を実現する。
【００２１】
フラッシュメモリ２４は、不揮発性記憶媒体（記憶手段）であり、ＣＰＵ２１が実行する各種プログラムや、操作部２０が備える後述する用語リソースや画像リソースを含む各種データを格納（記憶）している。
通信Ｉ／Ｆ２５は、ネットワーク３を介してクライアントＰＣ等の外部装置２と通信するためのインタフェースである。
【００２２】
接続Ｉ／Ｆ２６は、通信路３０を介して本体１０と通信するためのインタフェースである。ここではＵＳＢ規格のインタフェースとしている。
なお、通信Ｉ／Ｆ２５は、有線、無線を問わず任意の規格のものを採用可能である。接続Ｉ／Ｆ２６と共通化してもよい。通信Ｉ／Ｆ２５及び接続Ｉ／Ｆ２６としてそれぞれ複数のＩ／Ｆを設けてもよい。
【００２３】
操作パネル２７は、ユーザからの各種動作の実行や設定等の指示操作を受け付ける操作部と、画像処理システム１の動作状況や設定状態を表示する表示部とを備える操作表示手段である。この操作パネルは、例えばタッチパネルを積層した液晶表示装置（ＬＣＤ）により構成することができる。さらに、これに加えて又はこれに代えて、ハードウェアキー等の操作部やランプ等の表示部を設けることもできる。
なお、図１の外部装置２は、ハードウェアとしては、ＣＰＵ、ＲＯＭ、ＲＡＭ、通信Ｉ／Ｆ等を備えた公知のコンピュータでよい。
【００２４】
図３は、図２に示した本体１０及び操作部２０のソフトウェア構成を操作部２０とネットワーク３の通信に関する機能と共に示す図である。
図３に示すように、本体１０は、アプリケーション（以下「アプリ」ともいう）層１０１と、サービス層１０２と、オペレーティングシステム（以下「ＯＳ」という）層１０３とを含むソフトウェア群を備える。
【００２５】
アプリ層１０１のソフトウェアは、ハードウェア資源を動作させて所定の機能を提供するためのソフトウェアである。例えば、コピーアプリ，スキャナアプリ，ファクスアプリ，プリンタアプリ等を備え、それらによってコピー機能，スキャナ機能，ファクス機能，プリンタ機能等の各種機能を提供することができる。
【００２６】
サービス層１０２のソフトウェアは、アプリ層１０１とＯＳ層１０３との間に介在し、アプリ層１０１のソフトウェアに対し、本体１０が備えるハードウェア資源を利用するためのインタフェースを提供する。より具体的には、ハードウェア資源に対する動作要求の受付及びその動作要求の調停を行う機能を備える。サービス層１０２が受け付ける動作要求には、スキャナによる読み取りやプロッタによる印刷等の要求が考えられる。
【００２７】
なお、このインタフェースの機能は、本体１０のアプリ層１０１だけではなく、操作部２０のアプリ層２０１に対しても提供する。すなわち、操作部２０のアプリ層２０１にあるアプリも、サービス層１０２にアクセスすることにより、本体１０のハードウェア資源（例えばエンジン部１７）を利用して各種機能を実現することができる。
【００２８】
ＯＳ層１０３は、基本ソフトウェアであり、本体１０が備えるハードウェアを制御する基本機能を提供する。サービス層１０２のソフトウェアは、各種アプリからのハードウェア資源の利用要求を、ＯＳ層１０３が解釈可能なコマンドに変換してＯＳ層１０３に渡す。そして、ＯＳ層１０３のソフトウェアがそのコマンドを実行することにより、ハードウェア資源にアプリの要求に従った動作を行わせる。
【００２９】
操作部２０が備えるアプリ層２０１、サービス層２０２及びＯＳ層２０３も、階層構造については本体１０側と同様である。アプリ層２０１のアプリが提供する具体的な機能や、サービス層２０２が受け付け可能な動作要求の種類は、本体１０側とは異なる。操作部２０が備えるアプリは、操作部２０が備えるハードウェア資源を動作させて所定の機能を提供することもできるが、主として本体１０が備える機能に関する操作や表示を行うためのＵＩ（ユーザインタフェース）の機能を提供する。
【００３０】
なお、この実施形態では、本体１０側と操作部２０側とで、ＯＳは独立して動作するものとする。また、本体１０と操作部２０とが相互に通信可能であれば、ＯＳが同じ種類である必要はない。例えば、本体ではＬｉｎｕｘ（登録商標）を用い、操作部２０ではＡｎｄｒｏｉｄ（登録商標）を用いることも可能である。ただし、本体１０側と操作部２０側とでＯＳが独立して動作することは必須ではない。
【００３１】
そして、この画像処理システム１において、本体１０と操作部２０とは異なるＯＳにより制御されるため、本体１０と操作部２０との間の通信は、１装置内のプロセス間通信ではなく、異なる装置間の通信として行う。
操作部２０が受け付けたユーザからの指示内容を本体１０へ伝達する動作（コマンド通信）や、本体１０が操作部２０へイベントを通知する動作がこれに該当する。
【００３２】
よって、操作部２０が本体１０へコマンド通信を行うことにより、本体１０の機能を使用することができる。また、本体１０から操作部２０に通知するイベントには、本体１０における動作の実行状況、本体１０においてなされている設定の内容などが挙げられる。
【００３３】
また、操作部２０への電源は本体１０から通信路３０にて供給されているため、操作部２０は本体１０の電源制御とは独立して動作が可能となっている。機能の独立性を保つために、本体１０と操作部２０は別々のＯＳで動作していて、操作部２０のアプリケーションが本体１０の機能を利用して動作することが可能になっている。
【００３４】
次に、図４に、画像処理システム１において操作部２０が本体１０から送信されるイベントを検出した場合の、該イベントと対応するメッセージの表示動作の例を示す。
なお、以下において、説明の便宜のため、各装置のＣＰＵがアプリ等のプログラムを実行することによって行う動作を、そのアプリ等が実行する動作として説明する。
図４の例では、本体１０は、図３のアプリ層１０１に、コピー機能１０１ａ、スキャナ機能１０１ｂ、ファクシミリ機能１０１ｃ及びプリンタ機能１０１ｄを実現するアプリを備えているとする。
【００３５】
一方、操作部２０は、図３のアプリ層２０１に、コピー機能１０１ａ、スキャナ機能１０１ｂ、ファクシミリ機能１０１ｃ及びプリンタ機能１０１ｄに関する標準的なＵＩを提供するＵＩアプリ２０１ａを備えている。このＵＩアプリ２０１ａは、コピー機能１０１ａ〜プリンタ機能１０１ｄの４つの機能全てについて、その機能で発生するイベントで用いられる用語ＩＤと、その用語ＩＤと対応する表示用文字列との関係を記憶した用語情報記憶手段である用語テーブル２１１ａを備えている。また、この用語テーブル２１１ａには、特定の機能に依存せずシステムで標準的に用いられる用語ＩＤと対応する表示用文字列との関係の情報も登録されているとする。
【００３６】
そして、イベントを検出した場合に、ＵＩアプリ２０１ａは、イベントに含まれる用語ＩＤを用いて用語テーブル２１１ａを検索し、対応する表示用文字列を取得することにより、その文字列を用いて、イベントと対応するメッセージを操作パネル２７に表示させることができる。
【００３７】
なお、イベントには、該イベントに応じてメッセージを表示すべき場合、１又は複数のメッセージＩＤが含まれ、このメッセージＩＤがメッセージの表示指示に該当する。そして、そのメッセージ毎に、１又は複数の用語ＩＤにより、そのメッセージに係る表示内容が指定される。この点については、図８を用いて後に詳述する。
【００３８】
図５に、用語テーブル２１１ａの例を示す。
この用語テーブル２１１ａは、上述のように、用語ＩＤと、その用語ＩＤと対応する表示用文字列との関係を記憶するものである。
なお、表示用文字列の中には、別の文字列を組み込んで表示すべきことを示すものもある。これらの表示用文字列を用いた表示例については図１６を用いて後述する。
【００３９】
なお、図５では１言語分の表示用文字列のみ示しているが、用語テーブル２１１ａに複数言語について言語毎に文字列を記憶させておくとよい。そして、用語ＩＤと対応する文字列を検索する際に、使用中言語と対応する文字列を取得することにより、使用中の言語でメッセージを表示させることができる。ただし、説明を簡単にするため、以下の説明においては基本的にはこのような複数言語対応については触れない。
【００４０】
図４の説明に戻る。
操作部２０においては、ＵＩの機能を拡張することが可能になっており、ＵＩアプリ２０１ａに加え、この操作部２０上で動作可能な新しいＵＩアプリ２０１ｂをアプリ層２０１に後から追加することができる。ここでは、この後から追加されたＵＩアプリ２０１ｂは、スキャナ機能１０１ｂに関する操作や表示を行うためのＵＩを提供するが、ＵＩアプリ２０１ａとは操作や表示の方法が異なる。標準的な操作部とは異なるデザイン（フリック，ピンチ操作などを取り入れた新しい操作体系に対応する）を取り入れる等である。
【００４１】
このようなＵＩアプリ２０１ｂを後から追加する場合、ＵＩアプリ２０１ａの場合と同様に、アプリと対応する用語テーブルを設けることも考えられる。しかしながら、スキャナ機能１０１ｂに関する用語ＩＤと表示用文字列との対応関係を変えなくてよい場合にまでアプリ毎にテーブルを持つとすると、メモリ等のリソースの無駄になる。また、スキャナ機能１０１ｂにおいて新たにイベントを追加した場合に、アプリ毎に用語テーブルを更新しなければならず、この点も面倒である。
【００４２】
そこで、ＵＩアプリ２０１ｂには、自身と対応する用語テーブルを設けていない。その代わり、ＵＩアプリ２０１ｂは、本体１０からの非同期のイベントを受信（検出）すると、そのイベントに含まれる用語ＩＤをＵＩアプリ２０１ａに渡し、その用語ＩＤと対応する表示用文字列の検索を要求する。ＵＩアプリ２０１ａはこの要求を受けると、受け取った用語ＩＤを用いて自身の用語テーブル２１１ａを検索し、対応する表示用文字列をＵＩアプリ２０１ｂに返す。
【００４３】
図６に、この問い合わせを行う場合の動作シーケンスを示す。ＵＩアプリ２０１ｂは、本体１０からのイベントを受信すると（Ｓ１０１）、問い合わせ先であるＵＩアプリ２０１ａに、受信したイベントに含まれる用語ＩＤと対応する文字列を問い合わせる（Ｓ１０２）。ＵＩアプリ２０１ａは、受け取った用語ＩＤと対応する表示用文字列をＵＩアプリ２０１ｂに返す（Ｓ１０３）。
このことにより、ＵＩアプリ２０１ｂは、自身の用語テーブルを持たなくても、イベントに含まれる用語ＩＤに基づき、イベントと対応するメッセージを操作パネル２７に表示させることができる。
【００４４】
この場合、ＵＩアプリ２０１ｂには、全てのイベントについて、イベントと対応する文字列をＵＩアプリ２０１ａに問い合わせるべきことが設定されていると考えることができる。操作部２０が必ず備えている基本ＵＩであれば、操作部２０のベンダーと別のベンダーがＵＩアプリ２０１ｂを提供する場合であっても、ＵＩアプリ２０１ｂに文字列の取得先として登録することは、さほど困難ではないと考えられる。仕様の情報等からＵＩアプリ２０１ａの識別情報及び機能を把握できると考えられるためである。
【００４５】
したがって、以上の構成を採用することにより、検出したイベントに対応する用語又は画像に基づく情報（ユーザに提示するメッセージ等の情報）の表示を低コストで且つ正確に行うことができる。例えば、操作部２０側に本体１０側の機能を操作する新しいＵＩアプリを後から追加する場合、そのＵＩアプリを作成するベンダーなどが本体１０で発生するイベント（状態変化やエラー）の種類を全て把握していなくても、そのＵＩアプリは正しい情報を表示できる。つまり、操作部２０で動作するＵＩアプリ間の用語の不一致を防止しつつ一元管理ができる。また、本体１０側の機能を操作する追加のＵＩアプリを開発する際に、既に存在する情報を利用できるため、アプリ開発効率の向上が図れ、コストの低下につながる。更に、正しい情報が常に表示されることで、利便性の向上につながる。
【００４６】
なお、「ＳｃａｎＴｏＭｅ」と呼ばれるＵＩアプリ（ＳｃａｎＴｏＭｅアプリ）など、例えば複数の機能のうち特定の一部分のみを操作するためのＵＩを提供するプチアプリをＵＩアプリ２０１ｂとして後から追加することも考えられる。ＳｃａｎＴｏＭｅアプリは、スキャナにスキャンを実行させ、スキャンで読み取られた画像データを外部装置２に備えた記憶手段の所定領域（所定フォルダ等）に保存させるといった機能に関する操作を行うためのＵＩを提供するアプリである。
【００４７】
このような小規模なアプリの場合、関連するイベントはスキャナ機能１０１ｂに関するイベントのうち一部のみであると考えられる。しかし、どのイベントがアプリに関連するかを判断してそのイベントのみに関する用語テーブルを作成することは難しい。かといって、全イベントに関する用語テーブルを小規模なアプリに持たせると、アプリ自体のサイズに比して用語テーブルの占めるサイズが大きく、リソースの無駄が大きくなる。
したがって、このような小規模なアプリに、用語を他のアプリに問い合わせる機能を設けると、特に有用である。
【００４８】
なお、図４の例では、用語テーブルを持つアプリはＵＩアプリ２０１ａのみであった。しかし、用語テーブルを持つアプリが複数ある場合、１つのアプリに用語ＩＤと対応する文字列を問い合わせてその文字列が得られなかった場合、他のアプリに同じ問い合わせを行うことが考えられる。
【００４９】
図７に、この場合の図６と対応する動作シーケンスを示す。図７の例において、操作部２０は、用語テーブルを持つアプリとしてＵＩアプリ２０１ａの他、ＵＩアプリ２０１ｘを備えるとする。
この例では、ＵＩアプリ２０１ｂが、検出したイベント（Ｓ２０１）に含まれる用語ＩＤと対応する表示用文字列を取得する場合、まずＵＩアプリ２０１ａに、受信したイベントに含まれる用語ＩＤと対応する文字列を問い合わせる（Ｓ２０２）。初めの問い合わせ先をどこにするかは、固定でもよいし、イベントの種類等に応じて定めるようにしてもよい。
【００５０】
ここで、ＵＩアプリ２０１ａが備える用語テーブルに該当用語ＩＤが登録されていない場合には、ＵＩアプリ２０１ａは用語ＩＤがみつからない旨の応答を返す（Ｓ２０３）。
すると、ＵＩアプリ２０１ｂは、別の問い合わせ先（ここではＵＩアプリ２０１ｘ）に対し、同様な問い合わせを行う（Ｓ２０４）。ＵＩアプリ２０１ｘが備える用語テーブルに該当用語ＩＤが登録されているとすると、ＵＩアプリ２０１ｘは対応する文字列を返す（Ｓ２０５）。
【００５１】
なお、ステップＳ２０４における別の問い合わせ先は、複数の問い合わせ先を優先順位をつけて登録しておき、その優先順位に従って選択することが考えられる。あるいは、ＯＳ層２０３に対して現在操作部２０において動作中のアプリ一覧を問い合わせ、その中から任意にアプリを選択して問い合わせ先とすることも考えられる。
【００５２】
以下の説明において、ＵＩアプリを、個体を特定せず指す場合、添え字無しの符号２１０を用いる。ただし、ＣＰＵ２１がＵＩアプリのプログラムを実行することにより行う処理（ＵＩアプリが実行する処理ともいう）について説明する場合、特に断らない限り、少なくとも１つのＵＩアプリが実行すれば足りる。全てのＵＩアプリがその処理を実行することは必須ではない。
【００５３】
次に、図８に、ＵＩアプリ２１０がイベントの検出時に実行する、用語ＩＤと対応する文字列の取得及び表示に係る処理のフローチャートを示す。この処理は、ＣＰＵ２１がＵＩアプリ２１０のプログラムを実行することにより行うものである。
【００５４】
操作部２０において、ＣＰＵ２１は常に、本体１０等の外部装置から送信されたり、操作部２０内で発生したりするイベントを監視している。そして、イベントが発生すると、これを検出する。この機能及び動作が、検出手段及び検出手順と対応する。この検出機能は、操作部２０が備えるアプリ毎にあってもよいし、複数のアプリで共用してもよい。
いずれにせよ、ＣＰＵ２１は、あるＵＩアプリ２１０が処理すべきイベントを検出すると、そのＵＩアプリ２１０の機能として、図８のフローチャートに示す処理を開始する。
【００５５】
そしてまず、ＣＰＵ２１は、文字列の問い合わせ先を決定する（Ｓ１）。この問い合わせ先は、固定であっても、イベントの種類等に応じて定めてもよい。その後、ＣＰＵ２１は、決定した文字列問い合わせ先へ、検出したイベントに含まれる用語ＩＤに対応する表示用文字列を問い合わせ、応答があればこれを取得する（Ｓ２）。このステップＳ２の処理が取得手順の処理であり、ＣＰＵ２１は、このステップＳ２において、取得手段として機能する。
【００５６】
ＣＰＵ２１は次に、問い合わせに対する応答の有無を判断する（Ｓ３）。所定時間内に応答がなかった場合には、応答なしとするとよい。
そして応答があれば、ＣＰＵ２１は、文字列の返答があった否かを判断する（Ｓ４）。  そして、文字列の返答があった場合には、メッセージの表示形式を選択するための表示形式選択処理（Ｓ５）を行う。その後、ステップＳ２で取得した文字列を、ステップＳ５で選択した表示形式で操作パネル２７に表示させ（Ｓ６）、処理を終了する。なお、ステップＳ６において、図８の処理開始前から既に表示されていたメッセージがあれば、今回取得した文字列に係るメッセージと、既に表示されていたメッセージとを、合わせて１つの表示部に表示することが望ましい。
【００５７】
ステップＳ５が選択手順の処理であり、ＣＰＵ２１は、ステップＳ５において選択手段として機能する。また、ステップＳ６が表示制御手順の処理であり、ＣＰＵ２１は、ステップＳ５において表示制御手段として機能する。
なお、表示に用いる用語ＩＤが複数ある場合、ステップＳ４でＹｅｓの後ステップＳ１又はＳ２に戻り、その全ての用語ＩＤと対応する表示用文字列が得られるまで処理を繰り返す。
【００５８】
一方、ステップＳ４で文字列の返答を受けなかった場合（用語なしの返答を受けた場合）には、ＣＰＵ２１は、文字列問い合わせ先の次候補の有無を判断する（Ｓ７）。
そして、次候補がある場合には、その次候補を文字列問い合わせ先として再決定した後（Ｓ８）、ステップＳ２へ戻り、再決定した文字列問い合わせ先へ問い合わせを行い、以下の処理を繰り返す。
【００５９】
また、ステップＳ７で次候補がない場合、すなわち、全ての問い合わせ先候補に問い合わせても用語ＩＤと対応する文字列が得られない場合、用語ＩＤと対応する文字列が得られない状態でＵＩの動作を継続するか否かを判断する（Ｓ９）。
ここでは例えば、検出したイベントが次操作に影響がないイベント（ネットワーク動作が低下中など）であれば、処理を継続すると判断することができる。
【００６０】
また、そのままでは次の処理を行えないイベントであれば、文字列が得られないと正しい状態を操作パネル２７上に表示してユーザに提示できないので、処理を中断すると判断することができる。汎用メッセージを表示しても不具合を解決できないイベント（装置の電源ＯＦＦ、ＯＮが必要なイベントなど）や、正しいガイダンスやフィードバックを表示できないため、継続して動作させると誤動作を誘発する可能性があるイベントについても同様である。
【００６１】
また、操作パネル２７上に処理を継続するか中断するかの操作を促すメッセージや操作ボタン等を表示させ、その操作ボタン等の操作を受け付けることにより、処理を継続するか中断するかを決定することもできる。また、無条件に処理を中断することも可能である。
【００６２】
いずれにせよ、ステップＳ９で処理を継続する場合、ＣＰＵ２１は、検出したイベントに対応する文字列の代わりとなる汎用文字列を取得する（Ｓ１０）。その後、その生成した情報を、所定の表示形式で操作パネル２７に表示させ（Ｓ１１）、処理を終了する。なお、汎用文字列は、予め定めておくものであり、「ＭＦＰ本体の状態が変化しました。しばらくしてから実行してください。」等が考えられる。また、ここで表示形式が所定であるのは、表示すべきメッセージが予め定められているためである。
【００６３】
また、ステップＳ３で応答がなかった場合には、ＣＰＵ２１は、問い合わせ先のアプリが停止中か否かを判断する（Ｓ１２）。この判断は、問い合わせ先のアプリの状態を監視することによって行うことができる。また、この判断を行うのは、問い合わせ先のアプリが起動していなければ用語の問い合わせができないためである。また、アプリは、操作パネル２７上での操作が一定時間ない場合にスリープ状態になる設定がなされていた場合等には、起動されていても一時的に停止する場合がある。
【００６４】
ＣＰＵ２１は、ステップＳ１２で停止中と判断した場合、ＯＳに対して問い合わせ先アプリの再起動を要求する（Ｓ１３）。そして、再起動が成功したか否か判断し（Ｓ１４）、成功してれば、ステップＳ２に戻って再度の問い合わせを行う。なお、ステップＳ１４での待機中はユーザにレスポンスを待たせることになるため、タイムアウトを設定し、一定時間内に再起動が成功しない場合、再起動失敗として処理を進めるとよい。
【００６５】
また、ステップＳ１２で停止中でないか、またはステップＳ１４で再起動できない場合、問い合わせ先のアプリは当面利用できないことがわかる。なお、応答がない（Ｓ４でＮ）にも関わらず停止中でない（Ｓ１２でＮ）場合には、アプリがハングアップしていることが考えられる。
この場合、ＣＰＵ２１は、問い合わせ先アプリが利用できない状態でＵＩの動作を継続するか否かを判断する（Ｓ１５）。この判断は、継続するか否かの設定に基づいて行えばよい。また、ステップＳ１５の時点で操作パネル２７上に継続するか否かの選択画面を表示させ、ユーザに選択させるようにしてもよい。
【００６６】
ステップＳ１５に進むということは、本来文字列を問い合わせるべきアプリが利用できないということで、用語ＩＤと対応する文字列を取得できなかったり、あちこちに問い合わせて取得に時間がかかったりすることが想定される。このような状態でも実行中のアプリの動作を継続させたいか否かに基づき、ステップＳ１５の判断結果が定められればよい。
【００６７】
いずれにせよ、ステップＳ１５で継続する場合、ＣＰＵ２１は、ステップＳ７に進み、他の問い合わせ先を探す。他に問い合わせ先がない場合、ステップＳ９以下の処理に進むことになる。
また、継続しない場合、ＣＰＵ２１は、検出したイベントに対応する文字列の代わりとなる汎用のエラー文字列を取得し（Ｓ１６）、そのエラー文字列を所定の表示形式で操作パネル２７に表示させる（Ｓ１７）。なお、エラー文字列は、予め定めておくものであり、「エラーが発生しました。」等が考えられる。また、ここで表示形式が所定であるのは、表示すべきメッセージが予め定められているためである。
【００６８】
その後、ＣＰＵ２１は、実行中の処理に係るアプリの動作を中断（一旦停止）し（Ｓ１８）、処理を終了する。この状態で動作を継続しても、イベントに対応するメッセージ等を迅速かつ適切に表示できないと考えられるためである。またこのため、更なる不具合の原因となることが考えられるためである。
【００６９】
次に、図８のステップＳ５における表示形式選択処理の種々の例について説明する。
まず、ＵＩアプリが利用可能な表示形式について説明する。ここで説明する表示形式は、操作部２０が備える各ＵＩアプリが共通して利用可能な形式である。
図９乃至図１１は、その各表示形式における表示例を示す図である。
図９に示すのは、ダイアログ表示の例である。このダイアログ表示では、操作パネル２７に備える表示部３００に、ダイアログ３１０をポップアップ表示させる。
【００７０】
このダイアログ３１０には、３行以上のメッセージ表示が可能なメッセージ表示欄３１１と、各種ボタンを設けることができる。ボタンとしては、図９の例ではＯＫボタン３１２とキャンセルボタン３１３を設けている。このダイアログ３１０は、ＯＫボタン３１２又はキャンセルボタン３１３が操作されるまで、表示が継続される。
【００７１】
図１０に示すのは、バナー表示の例である。このバナー表示では、表示部３００の下部に、１行のメッセージを表示するバナー表示部３２０を設ける。このバナー表示部３２０は、他の画面と併存して表示可能であり、表示部３００への画面表示を行うアプリが切り替わっても表示を残しておく。
【００７２】
図１１に示すのは、メッセージ表示の例である。このメッセージ表示では、表示部３００の右上部に、２行のメッセージを表示するメッセージ表示部３３０を設ける。このメッセージ表示部は、表示部３００への画面表示を行うアプリが切り替わる時に消去される。
以上のダイアログ表示、バナー表示及びメッセージ表示は、表示できる文字数及びその表示位置、表示期間がそれぞれ異なるものである。表示形式選択処理においては、この各表示形式の特性を考慮し、イベントの検出に応じて表示すべきメッセージの内容に応じて、適切な表示形式を選択するための処理である。
【００７３】
〔表示形式選択処理の第１例：図１２乃至図１４〕
まず、表示形式選択処理の第１例について説明する。この第１例は、表示すべきメッセージに含まれる用語ＩＤの数に応じて表示形式を選択する例である。
図１２に、本体１０が操作部２０に送信するイベントに記載する、メッセージの表示に関するデータの例を示す。
【００７４】
画像処理システム１において、本体１０は、図１２に示すメッセージＩＤテーブルを記憶している。そして、各機能１０１ａ〜１０１ｄ及びＯＳは、イベントを操作部２０に送信するに当たり、操作部２０にメッセージの表示を要求する場合、メッセージＩＤテーブルから１又は複数のメッセージＩＤを選択してイベントに記載する。このとき、そのメッセージＩＤと対応してメッセージＩＤテーブルに登録されている１又は複数の用語ＩＤ、アクション及びタイプの情報もイベントに記載する。
【００７５】
このメッセージＩＤは、操作部２０（イベントの送信先）に対するメッセージの表示指示である。用語ＩＤは、メッセージの表示内容を指定するデータでる。アクションは、メッセージと共に「ＮＯＮＥ」以外の場合、メッセージの表示をダイアログ表示で行い、ここで設定された種類のボタンを表示すべきことを指定するデータである。タイプは、メッセージの目的を大まかに示すデータである。「ＩＮＦＯ」は単なる情報表示、「ＥＲＲＯＲ」はエラー通知であることを示す。
そして、以上の各情報を含むイベントの検出に応じて図８の処理を実行する操作部２０のＣＰＵ２１は、ステップＳ５の表示形式選択処理として、図１３の処理を開始する。
【００７６】
図１３は、表示形式選択処理の第１例を示すフローチャートである。
この処理においてＣＰＵ２１はまず、検出したイベントに記載されたアクションが「ＮＯＮＥ」か否か判断する。
そして、ここでＮＯＮＥであれば、イベントに従って表示すべきメッセージの用語ＩＤの数に従い、表示形式を選択する（Ｓ３２）。ここで考慮する用語ＩＤ数は、今回検出したイベントに含まれる用語ＩＤ全てと、もしあれば既に表示中のメッセージに係る用語ＩＤ全てである。今回検出したイベント中に複数のメッセージＩＤが含まれる場合、これら全てと対応する用語ＩＤを考慮する。
【００７７】
このステップＳ３２では、例えば図１４に示す対応関係に従って表示形式を選択する。すなわち、用語ＩＤの数が多いほど、表示領域の行数が多い表示形式を選択する。このことにより、表示すべきメッセージの量に応じた、適切な広さの表示領域に表示を行うことができる。従って、メッセージが表示領域に収まらなかったり、メッセージ以外の表示を無用に邪魔してしまったりすることを防止できる。
また、表示形式の選択に当たり、ＵＩアプリ２１０はどのようなイベントが通知され得るか、どのような用語ＩＤを用いた表示を指示されるかを把握している必要がない。従って、表示形式の選択に係る機能を、少ない工数で開発することができる。
【００７８】
また、ステップＳ３１でＮＯＮＥでない場合、用語ＩＤの数によらず、表示形式としてダイアログ形式を選択し、イベントに含まれるアクションで指定されたボタンを表示することを決定する（Ｓ３３）。
イベントにおいてボタンを表示すべきことを指定された場合、これに対応できる表示形式はダイアログ形式のみであるから、これを選択するようにしたものである。なお、ボタン押下時の処理については、イベントとは別に本体１０から操作部２０へ通知される。
【００７９】
〔表示形式選択処理の第２例：図１５及び図１６〕
次に、表示形式選択処理の第２例について説明する。この第２例は、表示すべきメッセージの文字数に応じて表示形式を選択する例である。
図１５に、表示形式選択処理の第２例のフローチャートを示す。
この第２例の場合、イベントの検出に応じて図８の処理を実行する操作部２０のＣＰＵ２１は、ステップＳ５の表示形式選択処理として、図１４の処理を開始する。
【００８０】
この処理において、ステップＳ４１及びＳ４３は、図１３のステップＳ３１及びＳ３３と同じである。しかし、ステップＳ４１でアクションが「ＮＯＮＥ」である場合、図８のステップＳ２で取得した表示用文字列の文字数に従い、表示形式を選択する（Ｓ４２）。  ここで考慮する文字数は、今回検出したイベントに含まれる用語ＩＤ全てと、もしあれば既に表示中のメッセージに係る用語ＩＤ全てに対応する表示に用いる文字列の文字数である。もちろん、今回検出したイベント中に複数の用語ＩＤが含まれる場合、これら全てと対応する表示用文字列を考慮する。
【００８１】
このステップＳ４２では、例えば図１６に示す対応関係に従って表示形式を選択する。すなわち、表示用文字列の文字数が多いほど、表示領域の行数が多い表示形式を選択する。このことにより、表示すべきメッセージの文字数に応じた、適切な広さの表示領域に表示を行うことができる。従って、メッセージが表示領域に収まらなかったり、メッセージ以外の表示を無用に邪魔してしまったりすることを防止できる。
表示形式の選択に当たり、ＵＩアプリ２１０はどのようなイベントが通知され得るか等を把握している必要がない点は、第１例の場合と同様である。
なお、言語によって１文字の表示に必要なスペースが異なることから、図１６の文字数の基準を、使用言語毎に設けてもよい。
【００８２】
〔表示形式選択処理の第３例：図１７，図１８〕
次に、表示形式選択処理の第３例について説明する。この第３例は、表示すべきメッセージ数に応じて表示形式を選択する例である。
図１７に、表示形式選択処理の第３例のフローチャートを示す。
この第３例の場合、イベントの検出に応じて図８の処理を実行する操作部２０のＣＰＵ２１は、ステップＳ５の表示形式選択処理として、図１７の処理を開始する。
【００８３】
この処理において、ステップＳ５１及びＳ５３は、図１３のステップＳ３１及びＳ３３と同じである。しかし、ステップＳ５１でアクションが「ＮＯＮＥ」である場合、表示すべきメッセージ数（メッセージＩＤの数）に従い、表示形式を選択する（Ｓ５２）。
ここで考慮するメッセージＩＤは、今回検出したイベントに含まれるメッセージＩＤ全てと、もしあれば既に表示中のメッセージに係るメッセージＩＤ全てに対応する表示に用いる文字列の文字数である。もちろん、今回検出したイベント中に複数のメッセージＩＤが含まれる場合、これら全てと対応する表示用文字列を考慮する。
【００８４】
このステップＳ５２では、例えば図１８に示す対応関係に従って表示形式を選択する。すなわち、表示すべきメッセージの数が多いほど、表示領域の行数が多い表示形式を選択する。このことにより、表示すべきメッセージの量に応じた、適切な広さの表示領域に表示を行うことができる。従って、メッセージが表示領域に収まらなかったり、メッセージ以外の表示を無用に邪魔してしまったりすることを防止できる。
表示形式の選択に当たり、ＵＩアプリ２１０はどのようなイベントが通知され得るか等を把握している必要がない点は、第１例の場合と同様である。
【００８５】
後述のように可変文字列を用いる場合、ある用語ＩＤと対応する文字列を、他の用語ＩＤと対応する文字列に埋め込んで表示することがある。このような場合、複数の用語ＩＤを用いて、実質的には１つの用語ＩＤに係る表示を行うことになる。従って、このような可変文字列を採用する場合、用語ＩＤの数よりもメッセージＩＤの数に基づきメッセージの量を見積もった方が、より正確に見積もることができる。
【００８６】
〔第１の変形例：図１９及び図２０〕
次に、イベントの検出に応じて操作部２０のＣＰＵ２１が実行する図８の処理の変形例について説明する。
この処理は、用語ＩＤと対応する文字列として、可変文字列の利用が可能な場合に用いる処理である。
【００８７】
図５に示したように、用語テーブル２１１ａにおいては、表示用文字列として、一部に別の文字列を組み込んで表示すべきことを示す文字列を定義可能である。図５で例えば「COM_ERR_AAA_ID1」と対応する表示用文字列中にある「[%]」は、ここに別の文字列を組み込んで表示すべきことを示す。「[%]」が、可変文字列である。
【００８８】
そして、イベント中に「COM_ERR_AAA_ID1, COM_COLOR_M」のように用語ＩＤを並べて記載することにより、COM_ERR_AAA_ID1と対応する表示用文字列における[%]の部分に、COM_COLOR_Mと対応する表示用文字列を組み込むべきことを指定できる。
図５から、COM_COLOR_Mと対応する表示用文字列は、「赤色」であるので、２つの用語ＩＤ「COM_ERR_AAA_ID1, COM_COLOR_M」と対応する表示用文字列は、「本体の赤色トナーがなくなりました。」となる。
【００８９】
ところで、図１９（Ａ）のように、可変文字列の部分のみが異なる複数のメッセージが表示部に表示されると、似たようなメッセージが並ぶことになり、視認性が低下して誤解の原因となる。そこで、この第１の変形例においては、可変文字列の部分のみが異なるメッセージを複数表示することとなった場合に、それらをまとめて図１９（Ｂ）に示すような箇条書きのまとめ表示を行うようにしている。
【００９０】
図２０に、このまとめ表示を行うための処理のフローチャートを示す。
この第１の変形例において、操作部２０のＣＰＵ２１は、図８のステップＳ４でＹｅｓの場合、すなわち用語ＩＤと対応する表示用文字列が得られた場合に、図２０のフローチャートに示す処理を開始する。
【００９１】
そしてまず、ＣＰＵ２１は、表示すべきメッセージ中に同じ用語ＩＤが複数あるか否か判断する（Ｓ６１）。ここで複数あれば、可変文字列の部分のみが異なるメッセージが複数表示される状態であることがわかる。ただし、ステップＳ６１において、複数あった用語ＩＤと対応する表示用文字列が可変文字列を含むことを確認するようにしてもよい。なお、表示用文字列に可変文字列を含まない用語ＩＤで同じものが複数あるとすると、全く同じ文字列を複数表示することになるので、このようなことは起こらないようにイベントを生成するようにすることが望ましい。
【００９２】
そして、ステップＳ６１でＹｅｓの場合、ＣＰＵ２１は、ステップＳ６１で発見した用語ＩＤから、まとめ表示用の用語ＩＤを生成する（Ｓ６２）。例えば、上述の「COM_ERR_AAA_ID1」の場合、まとめ表示用の用語ＩＤは、後ろに「_L」を追加することにより、「COM_ERR_AAA_ID1_L」として生成することができる。このように、元の用語ＩＤとまとめ表示用の用語ＩＤとの関係が何らかの規則性を持つように予め用語ＩＤを定義しておくとよい。
【００９３】
次に、ＣＰＵ２１は、ステップＳ６１で発見した用語ＩＤにつき、可変文字列として組み込む文字列に重複するものがあるか否か判断する（Ｓ６３）。もしあれば、表示内容が重複しないよう、重複する可変部分を一つに統合する（Ｓ６４）。
いずれの場合も、その後ＣＰＵ２１は、まとめ表示用の用語ＩＤと、可変部分の用語ＩＤとを用いて、ステップＳ６１で発見した用語ＩＤに係る表示と対応する表示のための用語ＩＤ群を生成する（Ｓ６５）。
【００９４】
例えば、図１９の例において、（Ａ）の表示では、共通の用語ＩＤ「COM_ERR_AAA_ID1」を含むメッセージが３つある。そこで、この用語ＩＤからまとめ表示用の用語ＩＤ「COM_ERR_AAA_ID1_L」を生成する。図５からわかるように、「COM_ERR_AAA_ID1_L」と対応する表示用文字列は、「以下の本体のトナーがなくなりました。」の後に、複数の文字列（トナーの色を想定）を箇条書きにすることを示すものである。
【００９５】
そして、元の「COM_ERR_AAA_ID1」の後ろにあってなくなったトナーの色を示していた「COM_COLOR_M」、「COM_COLOR_C」及び「COM_COLOR_M」の用語ＩＤを「COM_ERR_AAA_ID1_L」の後ろに配置することにより、図１９（Ａ）と対応する図１９（Ｂ）のまとめ表示を行うための用語ＩＤ群を生成することができる。
【００９６】
以上のステップＳ６５の後は、ステップＳ２に戻ってまとめ表示用の用語ＩＤと対応する表示用文字列の問い合わせを行う。ここで文字列を取得できれば、それに基づきまとめ表示を行うことができる。また、ステップＳ５での表示形式選択処理も、まとめ表示状態のＩＤ数や文字数に従って行う。
また、ステップＳ６１でＮｏの場合、表示内容を変更する必要はないため、そのままステップＳ５に進む。
以上の処理により、用語ＩＤの共通する表示を複数行う場合に、該複数の表示をまとめて行うための文字列を取得して、それらをまとめて表示することができ、見やすい表示を実現できる。
【００９７】
〔第２の変形例：図２１乃至図２３〕
次に、図８の処理によりメッセージを表示した後で、メッセージを表示してからの時間経過に応じて表示形式を変更する例について説明する。
図２１に、この第２の変形例におけるメッセージ表示の遷移例を示す。
この第２の変形例では、各表示形式におけるメッセージの表示期間に注目して表示形式の選択を行うようにしている。
【００９８】
そして、メッセージを初めに表示する際には、図２１（Ａ）に示すようにメッセージ形式で表示を行う。このメッセージ形式の表示は、表示部３００への画面表示を行うアプリが切り替わる時に消去される。このため、メッセージに対してユーザが何も対処しなくても、メッセージの表示が消去される場合がある。なお、一旦表示されたメッセージも、メッセージの表示終了が指示されない限りは、画面上から消去されても、「表示すべきメッセージ」として残り、元のアプリに切り替わった際には再度表示される。
【００９９】
そして、所定時間経過してもメッセージに対してユーザが何も対処せず、表示終了とならない場合、表示形式をバナー形式に変更する。バナー形式は、表示部３００への画面表示を行うアプリが切り替わっても表示を残しておくので、メッセージ形式よりもユーザに注目されやすい表示であり、注意喚起に好適である。
【０１００】
そして、さらに所定時間経過してもメッセージに対してユーザが何も対処せず、表示終了とならない場合、表示形式をダイアログ形式に変更する。ダイアログ形式は、ＯＫボタン３１２又はキャンセルボタン３１３が操作されるまで、表示が継続され、それまで画面上で他の操作ができないので、確実にユーザに対処をしてもらうことができる。
図２１の例では、受信文書を保存又は印刷出力することが「対処」に当たる。
【０１０１】
図２２に、メッセージ表示開始からの時間と、選択すべき表示形式との対応関係を示す。なお、この表に関わらず、上述した実施形態の表示形式選択処理に従い、初めの表示形式をメッセージ形式以外のものとすることができる。そして、この場合でも、時間の経過に応じて、より目立つ表示形式に変更することができる。
【０１０２】
図２３に、この表示形式の変更に係る処理のフローチャートを示す。
操作部２０のＣＰＵ２１は、一定時間毎に図２３に示す処理を開始する。
そしてまず、表示継続時間が図２２に示す閾値を超えたメッセージがあるか否か判断する（Ｓ７１）。なければそのまま処理を終了するが、あれば、該当メッセージの表示形式を表示継続時間に応じた表示形式に変更し（Ｓ７２）、そのメッセージを変更後の表示形式で操作パネル２７に再表示させ（Ｓ７３）、処理を終了する。
以上の処理を行うことにより、長期間対応がなされていないメッセージを、より目立つようにユーザに提示することができる。
【０１０３】
以上で実施形態の説明を終了するが、この発明において、各部の具体的な構成や処理の内容、通信の手順、データの構成、選択可能な表示形式の種類等は、実施形態で説明したものに限るものではない。
例えば、本体１０と対になった操作部２０だけでなく、本体１０と任意に無線接続可能な端末装置（例えばタブレット端末）においても、同様に、アプリが検出したイベントと対応する用語の問い合わせを行うことができる。このようにすれば、タブレット端末を、本体１０を操作するための操作部２０と同様なリモートコントローラとして用いることができる。
【０１０４】
また、用語テーブルは、情報処理システムを構成する装置以外の装置が記憶していてもよい。その装置がＵＩアプリ２１０からの要求を受け付け、用語ＩＤと対応する表示用文字列を返す機能を備えていれば、上述した実施形態及び変形例の動作に特に支障はない。
また、表示形式選択処理のうち第１例から第３例に示した選択基準を組み合わせて用いてもよい。例えば、表示用文字列を基準に選択した表示形式と、メッセージＩＤを基準に選択した表示形式のうち、表示領域の広い方の表示形式を最終的に選択する、といった選択処理も可能である。
【０１０５】
また、例えば、上述した実施形態では画像処理システム１を、本体１０と操作部２０とを固定的に組み合わせて構成した例について説明したが、これには限られない。
操作部と本体（動作部）とを、ハードウェアコンポーネントとして全く別の装置としてもよい。例えば、スマートフォン等のモバイル端末を操作部とし、ＭＦＰ等の画像処理装置を動作部として画像処理システムあるいは情報処理システムを構成してもよい。特に、操作部と動作部を無線で接続する場合には、これらは全く独立した装置として構成可能である。
【０１０６】
また、操作部と動作部とは、１対１でなくてもよい。例えば、本体に有線接続された操作部がある画像処理装置を、モバイル端末からも操作できるようにすることが考えられる。あるいは、１台の画像処理装置を複数のモバイル端末から操作できるようにすることも考えられる。あるいはまた、１台のモバイル端末から操作対象を切り替えつつ複数の画像処理装置を操作できるようにすることも考えられる。
【０１０７】
また、操作部及び動作部がそれぞれ１台の装置で構成される必要はない。複数台の装置が協働して操作部あるいは動作部の機能を実現する構成であってもよい。逆に、操作部及び動作部が同じ筐体に収まっていてもよい。
また、システムが３以上の操作部あるいは動作部を複数を備える場合についても、本発明は適用可能である。
また、情報処理システムは、１の情報処理装置により実現されるものであってもよい。例えば、操作部２０は、単独でも情報処理システムであると考えることができる。
【０１０８】
また、情報処理システムが、スキャナやプロッタのような画像処理エンジンを備えていることも必須ではない。情報処理システムを構成する各装置は、任意の情報処理装置でよい。もちろん、情報処理以外の物理的な入力や出力を合わせて行う装置でもよい。
この発明の実施形態であるプログラムは、１のコンピュータを、または複数のコンピュータを協働させて、上述した情報処理システムの機能を実現させるためのプログラムである。そして、このようなプログラムをコンピュータに実行させることにより、上述したような効果を得ることができる。
【０１０９】
このようなプログラムは、はじめからコンピュータに備えるＲＯＭや他の不揮発性記憶媒体（フラッシュメモリ，ＥＥＰＲＯＭ等）などに格納しておいてもよい。しかし、記録媒体であるＣＤ−ＲＯＭ、あるいはメモリカード，フレキシブルディスク，ＭＯ，ＣＤ−Ｒ，ＣＤ−ＲＷ，ＤＶＤ＋Ｒ，ＤＶＤ＋ＲＷ，ＤＶＤ−Ｒ，ＤＶＤ−ＲＷ，又はＤＶＤ−ＲＡＭ等の不揮発性記録媒体に記録して提供することもできる。それらの記録媒体に記録されたプログラムをコンピュータにインストールして実行させることにより、上述した各手順を実行させることができる。
【０１１０】
さらに、ネットワークに接続され、プログラムを記録した記録媒体を備える外部装置あるいはプログラムを記憶手段に記憶した外部装置からダウンロードし、コンピュータにインストールして実行させることも可能である。
また、以上説明してきた実施形態及び変形例の構成は、相互に矛盾しない限り任意に組み合わせて実施可能であることは勿論である。
【符号の説明】
【０１１１】
１：画像処理システム、２：外部装置、３：ネットワーク、１０：本体、１１，２１：ＣＰＵ、１２，２２：ＲＯＭ、１３，２３：ＲＡＭ、１４：ＨＤＤ、１５，２５：通信Ｉ／Ｆ、１６，２６：接続Ｉ／Ｆ、１７：エンジン部、１８，２８：システムバス、２０：操作部、２７：操作パネル、３０：通信路、１０１，２０１：アプリ層、１０１ａ：コピー機能、１０１ｂ：スキャナ機能、１０１ｃ：ファクシミリ機能、１０１ｄ：プリンタ機能、１０２，２０２：サービス層、１０３，２０３：ＯＳ層、２０１ａ，２０１ｂ，２０１ｘ：ＵＩアプリ、２１１ａ：用語テーブル、３００：表示部、３１０：ダイアログ、３１１：メッセージ表示欄、３１２：ＯＫボタン、３１３：キャンセルボタン、３２０：バナー表示部、３３０：メッセージ表示部
【先行技術文献】
【特許文献】
【０１１２】
【特許文献１】特開２００７−０８８６６５号公報
【特許文献２】特開２００７−０７６０７３号公報
【特許文献３】特開２０１０−００９２４０号公報
【図１】
2014179038.tif 000003
【図２】
2014179038.tif 000004
【図３】
2014179038.tif 000005
【図４】
2014179038.tif 000006
【図５】
2014179038.tif 000007
【図６】
2014179038.tif 000008
【図７】
2014179038.tif 000009
【図８】
2014179038.tif 000010
【図９】
2014179038.tif 000011
【図１０】
2014179038.tif 000012
【図１１】
2014179038.tif 000013
【図１２】
2014179038.tif 000014
【図１３】
2014179038.tif 000015
【図１４】
2014179038.tif 000016
【図１５】
2014179038.tif 000017
【図１６】
2014179038.tif 000018
【図１７】
2014179038.tif 000019
【図１８】
2014179038.tif 000020
【図１９】
2014179038.tif 000021
【図２０】
2014179038.tif 000022
【図２１】
2014179038.tif 000023
【図２２】
2014179038.tif 000024
【図２３】
2014179038.tif 000025