JP6123393B2 - 情報処理システム、情報処理方法及びプログラム - Google Patents

Description

この発明は、１又は複数の情報処理装置により実現される情報処理システム、このような情報処理システムにおける情報処理方法、及び１又は複数のコンピュータに実行させるプログラムに関する。

従来から、情報処理システムでは、イベントを検出し、そのイベントに応じてメッセージ等をユーザヘ提示すべき場合に、そのメッセージの文字列を操作部の表示画面上に表示させることが行われている。
そして、上記文字列を表示させる場合、操作部側のアプリケーション（単に「アプリ」ともいう）が、イベントに付加されている用語ＩＤに基づき必要な文字列を取得するようにしている。

そのため、操作部側のアプリケーションは、自己に対応付けて必要な用語リソースを保持している。用語リソースとは、用語ＩＤと表示すべき文字列との対応を示すテーブル等に相当するものである。
なお、上述した画面表示に関連する技術としては、例えば特許文献１〜３に記載のものが知られている。

しかしながら、上述したような従来の技術では、次のような問題があった。
すなわち、情報処理システムでは、本体の状態変化通知や設定変化通知、エラー通知など、１０００種類以上のイベントがあることも多く、それら全てを操作部側のアプリケーションで判定することは難しかった。つまり、検出可能な全てのイベントに対応する表示用の文字列をアプリケーション毎に保持しておくことが難しかった。また、本体側に用語の文字列を保持するようにしてしまうと、追加言語対応の度に本体側のソフトウェアも更新しなければならないという問題があった。

また、このような問題は、検出したイベントに対応する画像を表示画面に表示させる場合でも、同様に発生するものである。
さらに、検出したイベントに対応する文字列又は画像に基づく情報を音声等の他の出力方法によって出力させる場合でも、同様に発生するものである。
さらにまた、検出したイベントに対応する文字列又は画像に基づく情報の出力を行うのは、操作部に限らない。

この発明は、上記の点に鑑みてなされたものであり、１又は複数の情報処理装置により実現される情報処理システムにおいて、検出したイベントに対応する文字列又は画像に基づく情報（ユーザに提示する情報）の出力を低コストで且つ正確に行えるようにすることを目的とする。

この発明は、１又は複数の情報処理装置により実現される情報処理システムであって、上記の目的を達成するため、イベントを検出するイベント検出手段と、上記イベント検出手段がイベントを検出した場合に、イベントの種類又は送信元と該イベントと対応する文字列又は画像の取得先とを対応付けた取得先情報を参照して、上記検出したイベントの種類又は送信元に応じた取得先に、上記検出したイベントと対応する文字列又は画像を問い合わせる問い合わせ手段と、上記問い合わせ手段が上記取得先から取得した文字列又は画像に基づき、上記検出したイベントに応じてユーザに提示する情報を生成する生成手段とを備え、上記問い合わせ手段は、上記イベント検出手段が上記イベントを検出した場合に、まず所定の取得先に上記検出したイベントと対応する文字列又は画像を問い合わせ、その取得先から対応する文字列又は画像を取得できない場合に、上記取得先情報に従った取得先に上記検出したイベントと対応する文字列又は画像を問い合わせるものである。

上記構成によれば、１又は複数の情報処理装置により実現される情報処理システムにおいて、検出したイベントに対応する文字列又は画像に基づく情報（ユーザに提示する情報）の出力を低コストで且つ正確に行えるようにすることができる。

この発明の情報処理システムの一実施形態である画像処理システムの利用環境を示す図である。 図１の画像処理システムのハードウェア構成を示すブロック図である。 図２に示した本体及び操作部のソフトウェア構成を操作部とＬＡＮの通信に関する部分と共に示す図である。 図２に示した画像処理システムにおけるイベント発生時の文字列取得動作の第１の例について説明するための説明図である。 アプリが文字列の問い合わせを行う場合の動作シーケンスを示す図である。 イベント発生時の文字列取得動作の第２の例について説明するための説明図である。 イベント発生時の文字列取得動作の第３の例について説明するための説明図である。 イベント発生時の文字列取得動作の第４の例においてＵＩアプリがイベントの検出時に実行する、用語ＩＤと対応する文字列の取得に係る処理のフローチャートである。 実施形態の変形例について説明するための説明図である。 さらに別の変形例について説明するための説明図である。

以下、この発明を実施するための形態について、図１〜図１０を参照して具体的に説明する。
図１は、この発明の情報処理システムの一実施形態である画像処理システムの利用環境を示す図である。

画像処理システム１は、通信機能を有するＭＦＰ（複合機：Multifunction Peripheral）であり、例えばコピー機能，スキャナ機能，ファクス機能，プリンタ機能を備えている。これらの機能に関わる処理は、ユーザが画像処理システム１を直接操作することによって実行することができる。
また、画像処理システム１は、クライアントＰＣ（パーソナルコンピュータ）等の外部装置２とネットワーク３を介して通信可能であり、その外部装置２から受信した指示に従って上記機能に関わる処理を実行することもできる。

図２は、図１の画像処理システム１のハードウェア構成を示すブロック図である。
この画像処理システム１は、図２に示すように、ユーザの操作（ユーザからの指示）を受け付けるモジュールである操作部２０と、操作部２０が受け付けた操作に基づき動作を実行する動作部のモジュールである本体１０とを備え、それらを専用の通信路３０により相互に通信可能に接続した構成である。通信路３０は、この実施形態では制御線と電源線とからなるが、それらを別々にしても構わない。

なお、本体１０は、操作部２０が受け付けた操作に応じた動作だけでなく、上述のように外部装置２から受信した指示に応じた動作も行うことができる。また、後述するイベントが発生すると、それを操作部２０へ送信する動作を行うこともできる。更に、通信路３０は、例えばＵＳＢ（Universal Serial Bus）規格のものを用いることができる。しかし、有線、無線を問わず任意の規格のものでよい。１対１通信であっても、ネットワーク通信であってもよい。例えば、ＵＳＢの他、シリアル、有線または無線ＬＡＮ（ローカルエリアネットワーク）、ブルートゥース（Bluetooth：登録商標）、ＩｒＤＡ（Infrared
Data Association）等を用いることが考えられる。上記イベントを送信する動作は有線／無線問わずに同様に行える。

本体１０は、ＣＰＵ１１、ＲＯＭ１２、ＲＡＭ１３、ＨＤＤ（ハードディスクドライブ）１４、通信Ｉ／Ｆ（インタフェース）１５、接続Ｉ／Ｆ１６、及びエンジン部１７を備え、それらをシステムバス１８により接続した構成としている。そして、ＣＰＵ１１が、ＲＡＭ１３をワークエリアとしてＲＯＭ１２又はＨＤＤ１４に記憶されたプログラムを実行することにより、本体１０全体を制御し、後述する操作部２０へのイベント通知を含む操作部２０との通信制御をはじめとする各種機能を実現する。

ＨＤＤ１４は、不揮発性記憶媒体（記憶手段）であり、ＣＰＵ１１が実行する各種プログラムを含む各種データを格納（記憶）している。
通信Ｉ／Ｆ１５は、ネットワーク３を介してクライアントＰＣ等の外部装置２と通信するためのインタフェースである。

接続Ｉ／Ｆ１６は、通信路３０を介して操作部２０と通信するためのインタフェースである。ここではＵＳＢ規格のインタフェースとしている。
なお、通信Ｉ／Ｆ１５は、有線、無線を問わず任意の規格のものを採用可能である。接続Ｉ／Ｆ１６と共通化してもよい。通信Ｉ／Ｆ１５及び接続Ｉ／Ｆ１６としてそれぞれ複数のＩ／Ｆを設けてもよい。

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

操作部２０は、ＣＰＵ２１、ＲＯＭ２２、ＲＡＭ２３、フラッシュメモリ２４、通信Ｉ／Ｆ２５、接続Ｉ／Ｆ２６、及び操作パネル２７を備え、それらをシステムバス２８により接続した構成としている。そして、ＣＰＵ２１が、ＲＡＭ２３をワークエリアとしてＲＯＭ２２又はフラッシュメモリ２４に記憶されたプログラムを実行することにより、操作部２０全体を制御し、本体１０からのイベントの受信（検出）を含む本体１０との通信制御をはじめとする各種機能を実現する。

フラッシュメモリ２４は、不揮発性記憶媒体（記憶手段）であり、ＣＰＵ２１が実行する各種プログラムや、操作部２０が備える後述する用語リソースや画像リソースを含む各種データを格納（記憶）している。
通信Ｉ／Ｆ２５は、ネットワーク３を介してサーバ等の外部装置２と通信するためのインタフェースである。

接続Ｉ／Ｆ２６は、通信路３０を介して本体１０と通信するためのインタフェースである。ここではＵＳＢ規格のインタフェースとしている。
なお、通信Ｉ／Ｆ２５は、有線、無線を問わず任意の規格のものを採用可能である。接続Ｉ／Ｆ２６と共通化してもよい。通信Ｉ／Ｆ２５及び接続Ｉ／Ｆ２６としてそれぞれ複数のＩ／Ｆを設けてもよい。

操作パネル２７は、ユーザからの各種動作の実行や設定等の指示操作を受け付ける操作部と、画像処理システム１の動作状況や設定状態を表示する表示部とを備える操作表示手段である。この操作パネル２７は、例えばタッチパネルを積層した液晶表示装置（ＬＣＤ）により構成することができる。さらに、これに加えて又はこれに代えて、ハードウェアキー等の操作部やランプ等の表示部を設けることもできる。
なお、図１の外部装置２は、ハードウェアとしては、ＣＰＵ、ＲＯＭ、ＲＡＭ、通信Ｉ／Ｆ等を備えた公知のコンピュータでよい。

図３は、図２に示した本体１０及び操作部２０のソフトウェア構成を操作部２０とネットワーク３の通信に関する機能と共に示す図である。
図３に示すように、本体１０は、アプリケーション（以下「アプリ」ともいう）層１０１と、サービス層１０２と、オペレーティングシステム（以下「ＯＳ」という）層１０３とを含むソフトウェア群を備える。

アプリ層１０１のソフトウェアは、ハードウェア資源を動作させて所定の機能を提供するためのソフトウェアである。例えば、コピーアプリ，スキャナアプリ，ファクスアプリ，プリンタアプリ等を備え、それらによってコピー機能，スキャナ機能，ファクス機能，プリンタ機能等の各種機能を提供することができる。

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

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

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

操作部２０が備えるアプリ層２０１、サービス層２０２及びＯＳ層２０３も、階層構造については本体１０側と同様である。アプリ層２０１のアプリが提供する具体的な機能や、サービス層２０２が受け付け可能な動作要求の種類は、本体１０側とは異なる。操作部２０が備えるアプリは、操作部２０が備えるハードウェア資源を動作させてその機能を提供することもできるが、主として本体１０が備える機能に関する操作や表示を行うためのＵＩ（ユーザインタフェース）を提供する。
図３に示す３ａはＬＡＮ、３ｂは無線アクセスポイントである。

なお、この実施形態では、本体１０側と操作部２０側とで、ＯＳは独立して動作するものとする。また、本体１０と操作部２０とが相互に通信可能であれば、ＯＳが同じ種類である必要はない。例えば、本体１０ではＬｉｎｕｘ（登録商標）を用い、操作部２０ではＡｎｄｒｏｉｄ（登録商標）を用いることも可能である。ただし、本体１０側と操作部２０側とでＯＳが独立して動作することは必須ではない。

そして、この画像処理システム１において、本体１０と操作部２０とは異なるＯＳにより制御されるため、本体１０と操作部２０との間の通信は、１装置内のプロセス間通信ではなく、異なる装置間の通信として行う。
操作部２０が受け付けたユーザからの指示内容を本体１０へ伝達する動作（コマンド通信）や、本体１０が操作部２０へイベントを通知する動作がこれに該当する。

よって、操作部２０が本体１０へコマンド通信を行うことにより、本体１０の機能を使用することができる。また、本体１０から操作部２０に通知するイベントには、本体１０における動作の実行状況、本体１０においてなされている設定の内容などが挙げられる。

また、操作部２０への電源は本体１０から通信路３０にて供給されているため、操作部２０は本体１０の電源制御とは独立して動作が可能となっている。機能の独立性を保つために、本体１０と操作部２０は別々のＯＳで動作していて、操作部２０のアプリケーションが本体１０の機能を利用して動作することが可能になっている。

この実施形態の一つの特徴は、画像処理システム１が行う以下の動作である。つまり、操作部２０が本体１０からのイベントを検出した場合に、イベントの種類又は送信元とそのイベントと対応する文字列（用語）又は画像の取得先とを対応付けた取得先情報を参照する。そして、上記検出したイベントの種類又は送信元に応じた取得先に、上記検出したイベントと対応する用語又は画像を問い合わせる。その問い合わせで上記取得先から取得した用語又は画像に基づき、上記検出したイベントに応じてユーザに提示する情報を生成する。以下、本体１０及び操作部２０が備えるアプリの構成が異なるいくつかの例を用いて、この動作について説明する。
なお、以下において、説明の便宜のため、各装置のＣＰＵがアプリ等のプログラムを実行することによって行う動作を、そのアプリ等が実行する動作として説明する。

〔第１の例：図４及び図５〕
図４は、画像処理システム１におけるイベント発生時の文字列取得動作の第１の例について説明するための説明図である。
図４の例では、本体１０は、図３のアプリ層１０１に、コピー機能１０１ａ、スキャナ機能１０１ｂ、ファクシミリ機能１０１ｃ及びプリンタ機能１０１ｄを実現するアプリを備えているとする。

一方、操作部２０は、図３のアプリ層２０１に、コピー機能１０１ａ、スキャナ機能１０１ｂ、ファクシミリ機能１０１ｃ、プリンタ機能１０１ｄに関する標準的なＵＩを提供するＵＩアプリ２０１ａを備えている。このＵＩアプリ２０１ａは、コピー機能１０１ａ〜プリンタ機能１０１ｄの４つの機能全てについて、その機能で発生するイベントで用いられる用語ＩＤと、その用語ＩＤと対応する表示用文字列との関係を記憶した用語テーブル２１１ａを備えている。そして、イベントを検出した場合に、イベントに含まれる用語ＩＤを用いて用語テーブル２１１ａを検索し、対応する表示用文字列を取得することにより、その文字列を用いて、イベントと対応するメッセージを操作パネル２７に表示させることができる。

表１に、用語テーブル２１１ａの例を示す。この用語テーブルに登録される用語ＩＤの数は、例えばコピー、スキャナ、ファクシミリ、プリンタの１つの機能当たり約１０００程度である。

なお、用語テーブル２１１ａに複数言語について言語毎に文字列を記憶しておけば、用語ＩＤと対応する文字列を検索する際に、使用中言語と対応する文字列を取得することにより、使用中の言語でメッセージを表示させることができる。ただし、説明を簡単にするため、以下の説明においてはこのような複数言語対応については触れない。

また、イベントの種類と用語ＩＤは、１対１対応であってもよいし、１つのイベント中に複数の用語ＩＤが含まれ得たり、複数種類のイベントが共通の用語ＩＤを含み得たりしてもよい。いずれの場合も、用語ＩＤは、イベントと対応する表示用文字列の取得に用いるＩＤである。また、イベントの種類と用語ＩＤが１対１対応の場合、用語ＩＤを、イベントの種類を示すＩＤであると捉えることもできる。

また、操作部２０においては、ＵＩの機能を拡張することが可能になっており、この操作部２０上で動作可能な新しいＵＩアプリ２０１ｂをアプリ層２０１に後から追加することができる。ここでは、この後から追加されたＵＩアプリ２０１ｂは、スキャナ機能１０１ｂに関する操作や表示を行うためのＵＩを提供するが、ＵＩアプリ２０１ａとは操作や表示の方法が異なる。標準的な操作部とは異なるデザイン（フリック，ピンチ操作などを取り入れた新しい操作体系に対応する）を取り入れる等である。

このようなＵＩアプリ２０１ｂを後から追加する場合、ＵＩアプリ２０１ａの場合と同様に、アプリと対応する用語テーブルを設けることも考えられる。しかしながら、スキャナ機能１０１ｂに関する用語ＩＤと表示用文字列との対応関係を変えなくてよい場合にまでアプリ毎にテーブルを持つとすると、メモリ等のリソースの無駄になる。また、スキャナ機能１０１ｂにおいて新たにイベントを追加した場合に、アプリ毎に用語テーブルを更新しなければならず、この点も面倒である。

そこで、ＵＩアプリ２０１ｂには、自身と対応する用語テーブルを設けていない。その代わり、ＵＩアプリ２０１ｂは、本体１０からの非同期のイベントを受信（検出）すると、そのイベントに含まれる用語ＩＤをＵＩアプリ２０１ａに渡し、その用語ＩＤと対応する表示用文字列の検索を要求する。ＵＩアプリ２０１ａはこの要求を受けると、受け取った用語ＩＤを用いて自身の用語テーブル２１１ａを検索し、対応する表示用文字列をＵＩアプリ２０１ｂに返す。

図５に、この問い合わせを行う場合の動作シーケンスを示す。ＵＩアプリ２０１ｂは、本体１０からのイベントを受信すると（Ｓ１０１）、問い合わせ先であるＵＩアプリ２０１ａに、受信したイベントに含まれる用語ＩＤと対応する文字列を問い合わせる（Ｓ１０２）。ＵＩアプリ２０１ａは、受け取った用語ＩＤと対応する表示用文字列をＵＩアプリ２０１ｂに返す（Ｓ１０３）。
このことにより、ＵＩアプリ２０１ｂは、自身の用語テーブルを持たなくても、イベントに含まれる用語ＩＤに基づき、イベントと対応するメッセージを操作パネル２７に表示させることができる。

この場合、ＵＩアプリ２０１ｂには、全てのイベントについて、イベントと対応する文字列をＵＩアプリ２０１ａに問い合わせるべきことが、取得先情報として設定されていると考えることができる。操作部２０が必ず備えている基本ＵＩであれば、操作部２０のベンダーと別のベンダーがＵＩアプリ２０１ｂを提供する場合であっても、ＵＩアプリ２０１ｂに文字列の取得先として登録することは、さほど困難ではないと考えられる。仕様の情報等からＵＩアプリ２０１ａの識別情報及び機能を把握できると考えられるためである。

したがって、以上の構成を採用することにより、検出したイベントに対応する用語又は画像に基づく情報（ユーザに提示するメッセージ等の情報）の表示を低コストで且つ正確に行うことができる。例えば、操作部２０側に本体１０側の機能を操作する新しいＵＩアプリを後から追加する場合、そのＵＩアプリを作成するベンダーなどが本体１０で発生するイベント（状態変化やエラー）の種類を全て把握していなくても、そのＵＩアプリは正しい情報を表示できる。つまり、操作部２０で動作するＵＩアプリ間の用語の不一致を防止しつつ一元管理ができる。また、本体１０側の機能を操作する追加のＵＩアプリを開発する際に、既に存在する情報を利用できるため、アプリ開発効率の向上が図れ、コストの低下につながる。更に、正しい情報が常に表示されることで、利便性の向上につながる。

なお、「ＳｃａｎＴｏＭｅ」と呼ばれるＵＩアプリ（ＳｃａｎＴｏＭｅアプリ）など、例えば複数の機能のうち特定の一部分のみを操作するためのＵＩを提供するプチアプリをＵＩアプリ２０１ｂとして後から追加することも考えられる。ＳｃａｎＴｏＭｅアプリは、スキャナにスキャンを実行させ、スキャンで読み取られた画像データを外部装置２に備えた記憶手段の所定領域（所定フォルダ等）に保存させるといった機能に関する操作を行うためのＵＩを提供するアプリである。

このような小規模なアプリの場合、関連するイベントはスキャナ機能１０１ｂに関するイベントのうち一部のみであると考えられる。しかし、どのイベントがアプリに関連するかを判断してそのイベントのみに関する用語テーブルを作成することは難しい。かといって、全イベントに関する用語テーブルを小規模なアプリに持たせると、アプリ自体のサイズに比して用語テーブルの占めるサイズが大きく、リソースの無駄が大きくなる。
したがって、このような小規模なアプリに、用語を他のアプリに問い合わせる機能を設けると、特に有用である。

〔第２の例：図６〕
次に、図６に、画像処理システム１におけるイベント発生時の文字列取得動作の第２の例を示す。図６に示すのは、図４とは操作部２０にインストールされているアプリが異なる場合の例である。
図６の例では、本体１０は、アプリ層１０１に、コピー機能１０１ａ及びスキャナ機能１０１ｂを実現するアプリを備えているとする。

一方、操作部２０は、アプリ層２０１に、コピー機能１０１ａに関する標準的なＵＩを提供するＵＩアプリ２０１ｄと、スキャナ機能１０１ｂに関する標準的なＵＩを提供するＵＩアプリ２０１ｅとを備えている。さらに、コピー機能１０１ａとスキャナ機能１０１ｂの双方に関するＵＩを提供する追加ＵＩアプリ２０１ｆを備えている。

これらのうち、ＵＩアプリ２０１ｄとＵＩアプリ２０１ｅは、それぞれ対応する用語テーブル２１１ｄ，２１１ｅを備える。用語テーブル２１１ｄは、コピー機能１０１ａから通知されるイベントで用いる用語ＩＤに関して、用語ＩＤと、その用語ＩＤと対応する表示用文字列との関係を記憶したテーブルである。用語テーブル２１１ｅは、スキャナ機能１０１ｂに関する同様なテーブルである。
追加ＵＩアプリ２０１ｆは、対応する用語テーブルは持たない。

また、操作部２０は、ＯＳ層２０３にも、ＯＳの動作に関連するシステムイベントで用いる用語ＩＤに関して、用語ＩＤと、その用語ＩＤと対応する表示用文字列との関係を記憶した用語テーブル２１３を備える。

以上の操作部２０において、ＵＩアプリ２０１ｄ及びＵＩアプリ２０１ｅは、イベントを検出した場合、自身が備える用語テーブル２１１ｄ，２１１ｅを検索することにより、イベントに含まれる用語ＩＤと対応する表示用文字列を得ることができる。システムイベントについては、ＯＳ層２０３に問い合わせて用語テーブル２１３を検索させれば、用語ＩＤと対応する表示用文字列を得ることができる。

一方、追加ＵＩアプリ２０１ｆは、システムイベント以外のイベントであっても、ＵＩアプリ２０１ｄ又はＵＩアプリ２０１ｅに用語ＩＤと対応する表示用文字列を問い合わせる必要がある。しかし、ＵＩアプリ２０１ｄとＵＩアプリ２０１ｅのどちらも、追加ＵＩアプリ２０１ｆが使用する用語ＩＤを網羅した用語テーブルは持っていない。

そこで、追加ＵＩアプリ２０１ｆは、検出したイベントの種類及び送信元に基づき、そこに含まれる用語ＩＤと対応する文字列の問い合わせ先を決定するようにしている。
具体的には、追加ＵＩアプリ２０１ｆは、イベントを検出した場合、そのイベントの種類を特定する。種類とは、「エラー」、「インフォ」、「共通」等のイベントの性格を表す情報と、「コピー」、「スキャナ」、「システム」等のイベントの発生元を表す情報とを含むものである。

イベントの種類は、イベントの名称がその種類を示す識別子を含んでいれば、イベントの名称から特定することができる。例えば、コピーアプリ１０１ａが生成するエラーに関するイベントに、「CPY_ERR_01」という名称を付す等である。
しかし、イベントの名称がそのような識別子を含まない場合、例えば表２に示すような、イベントのＩＤ又は名称とそのイベントのタイプとの対応関係を記憶したイベント種類判定テーブルを用いることができる。このテーブルに、追加ＵＩアプリ２０１ｆが処理すべき全てのイベントの情報を登録しておけば、イベントの検出時に、そのイベントのＩＤ又は名称を用いて検索を行うことにより、検出したイベントの種類を特定することができる。

いずれにせよ、検出したイベントの種類を特定できた場合、追加ＵＩアプリ２０１ｆは、表３に示すような問い合わせ先検索テーブルを参照して、そのイベントに関する文字列の問い合わせ先を決定する。

この問い合わせ先検索テーブルは、イベントの種類と対応付けて、イベントに関する文字列の問い合わせ先となるアプリ又はＯＳの情報と記憶した、取得先情報である。
追加ＵＩアプリ２０１ｆは、以上のように文字列の問い合わせ先を決定することにより、検出したイベントに含まれる用語ＩＤに基づき、該イベントと対応する表示を行うための文字列を、その問い合わせ先から取得することができる。

なお、問い合わせ先検索テーブルは、操作部２０が備えるアプリがある程度特定されている場合には、追加ＵＩアプリ２０１ｆの開発時に予め用意しておくこともできる。しかし、そうでない場合、追加ＵＩアプリ２０１ｆをインストールした時に、既にインストールされている各アプリが持つ用語テーブルを調査して、その結果に基づき自動生成するようにするとよい。また、追加ＵＩアプリ２０１ｆのインストール後も、自動的に又はユーザの操作に応じて適宜更新可能とするとよい。

また、問い合わせ先の決定は、検出したイベントの種類ではなく、そのイベントの送信元に基づき行うことも考えられる。各アプリが持つ用語テーブルは、本体１０が備える特定の機能（アプリ又はシステム）毎に用意することが望ましいためである。また、ここでいう送信元は、ここで説明する例では、装置内のどの機能か、を示すものである。また、イベントの名称等ではなくイベントに係るデータを受け取った際に付されている送信元情報等によって特定可能なものであるとする。ただし、送信元を装置単位で考えることや、イベントの名称等から送信元を判定することを妨げるものではない。

表４に、イベント送信元と問い合わせ先とを対応付けた問い合わせ先検索テーブルの例を示す。

また、この第２の例において、追加ＵＩアプリ２０１ｆが自身の用語テーブルを備え、問い合わせ先検索テーブルに登録する問い合わせ先に、追加ＵＩアプリ２０１ｆ自身が含まれる構成も取り得る。
この第２の例の構成においても、イベントを検出した場合に、取得先情報を参照して、検出したイベントの種類又は送信元に応じた取得先に上記検出したイベントと対応する文字列又は画像を問い合わせるようにしたことにより、第１の例の場合と同様な効果を得ることができる。また、操作部２０が備えるアプリや用語テーブルの構成を、第１の例の場合より柔軟なものとすることができる。

〔第３の例：図７〕
次に、図７に、画像処理システム１におけるイベント発生時の文字列取得動作の第３の例を示す。
第３の例は、操作部２０が、ＵＩアプリ２０１ｈ〜２０１ｊの３つのＵＩアプリを備え、これらが全て対応する用語テーブルを備える場合における例である。本体１０側のアプリの構成については、本例の特徴に関係しないため、説明を省略する。

この例では、ＵＩアプリ２０１ｈが、検出したイベント（Ｓ２０１）に含まれる用語ＩＤと対応する表示用文字列を取得する場合、まず自身が備える用語テーブルを検索する（Ｓ２０２）。そして、自身が備える用語テーブルに該当の用語ＩＤが登録されていない場合に（Ｓ２０３）、第２の例で説明したように、表３あるいは表４に示したような問い合わせ先検索テーブルを参照し、イベントの種類又は送信元と対応する問い合わせ先（図７の例ではＵＩアプリ２０１ｉ）に問い合わせを行う（Ｓ２０４）。

ここで、ＵＩアプリ２０１ｉが備える用語テーブルに該当用語ＩＤが登録されていない場合には、ＵＩアプリ２０１ｉは用語ＩＤがみつからない旨の応答を返す（Ｓ２０５）。
すると、ＵＩアプリ２０１ｈは、別の問い合わせ先（ここではＵＩアプリ２０１ｊ）に対し、同様な問い合わせを行う（Ｓ２０６）。ＵＩアプリ２０１ｊが備える用語テーブルに該当用語ＩＤが登録されているとすると、ＵＩアプリ２０１ｊは対応する文字列を返す（Ｓ２０７）。図示は省略したが、ＵＩアプリ２０１ｊも用語ＩＤがみつからない旨の応答を返してきた場合、ＵＩアプリ２０１ｈはさらに別の問い合わせ先を探して問い合わせを行う。

なお、ステップＳ２０６等における別の問い合わせ先は、問い合わせ先検索テーブルに、イベントの種類又は送信元と対応させて複数の問い合わせ先を優先順位をつけて登録しておき、その優先順位に従って選択することが考えられる。あるいは、ＯＳ層２０３に対して現在操作部２０において動作中のアプリ一覧を問い合わせ、その中から任意にアプリを選択して問い合わせ先とすることも考えられる。

ＵＩアプリ２０１ｈを含む各ＵＩアプリに、アプリ名を元に問い合わせができるアプリ間インタフェースを設けておけば、問い合わせ先が用語テーブルを備えているか否かを気にせずに問い合わせることができる。そして、有効な返答がない場合に用語がみつからないとして扱えばよい。
例えばＡｎｄｒｏｉｄ（登録商標）の場合、ＩＮＴＥＮＴの仕組みでアプリ間の通信が可能となり、サポートしていないアプリにリクエストを出した場合でも呼び出しエラーにはならないようになっている。

以上により、ＵＩアプリ２０１ｈは、自身の用語テーブルに該当の用語ＩＤが含まれる場合には、他のアプリに問い合わせを行うことなく必要な文字列を取得できるため、低い処理負荷で文字列を取得することができる。
また、問い合わせ先検索テーブルに不備がある等で、テーブルに従った問い合わせ先で必要な文字列を取得できない場合でも、別の問い合わせ先から取得を試みることができ、必要な文字列を取得する可能性を高めることができる。
なお、ＵＩアプリ２０１ｈが初めに検索する用語テーブルは、自身が備えるものでなくてもよい。決まった取得先であれば、第２の例の場合と比べ、少なくとも取得先の決定に係る処理は省略することができる。

〔第４の例：図８〕
次に、画像処理システム１におけるイベント発生時の文字列取得動作の第４の例について説明する。
図８は、この第４の例においてＵＩアプリがイベントの検出時に実行する、用語ＩＤと対応する文字列の取得に係る処理のフローチャートである。この処理は、ＣＰＵ２１がＵＩアプリのプログラムを実行することにより行うものである。また、この処理において特徴的な点の一つは、用語ＩＤと対応する文字列の問い合わせに対し、問い合わせ先から応答がなかった場合の動作である。

操作部２０において、ＣＰＵ２１は常に、本体１０等の外部装置から送信されたり、操作部２０内で発生したりするイベントを監視している。そして、イベントが発生すると、これを検出する。この機能及び動作が、イベント検出手段及びイベント検出手順と対応する。この検出機能は、操作部２０が備えるアプリ毎にあってもよいし、複数のアプリで共用してもよい。
いずれにせよ、ＣＰＵ２１は、あるＵＩアプリが処理すべきイベントを検出すると、そのＵＩアプリの機能として、図８のフローチャートに示す処理を開始する。

そしてまず、ＣＰＵ２１は、検出したイベントとイベント種類判定テーブル等を参照し（Ｓ１）、第２の例で説明した手法と同様に、文字列の問い合わせ先を決定する（Ｓ２）。その後、ＣＰＵ２１は、決定した文字列問い合わせ先へ、検出したイベントに含まれる用語ＩＤに対応する表示用文字列を問い合わせる（Ｓ３）。ＣＰＵ２１は、以上のステップＳ１乃至Ｓ３において、問い合わせ手段として機能する。

ＣＰＵ２１は次に、問い合わせに対する応答の有無を判断する（Ｓ４）。所定時間内に応答がなかった場合には、応答なしとするとよい。
そして、応答があれば、ＣＰＵ２１は文字列の返答があったか否かを判断する（Ｓ５）。
そして、文字列の返答があった場合には、その返答された文字列を用いて、検出したイベントに応じて操作パネル２７に表示させる情報（ユーザに提示する表示画面など）を生成する（Ｓ６）。その後、その生成した情報を操作パネル２７に表示させ（Ｓ７）、処理を終了する。
また、ステップＳ６が生成手順の処理であり、ＣＰＵ２１は、ステップＳ６において生成手段として機能する。

一方、ステップＳ５で文字列の返答を受けなかった場合（文字列なしの返答を受けた場合）には、ＣＰＵ２１は、文字列問い合わせ先の次候補の有無を判断する（Ｓ８）。次候補の探索は、第３の例と同様な手法で行うことができる。
そして、次候補がある場合には、その次候補を文字列問い合わせ先として再決定した後（Ｓ９）、ステップＳ３へ戻り、再決定した文字列問い合わせ先へ問い合わせを行い、以下の処理を繰り返す。

また、ステップＳ８で次候補がない場合、すなわち、全ての問い合わせ先候補に問い合わせても用語ＩＤと対応する文字列が得られない場合、用語ＩＤと対応する文字列が得られない状態でＵＩの動作を継続するか否かを判断する（Ｓ１０）。
ここでは例えば、検出したイベントが次操作に影響がないイベント（ネットワーク動作が低下中など）であれば、処理を継続すると判断することができる。また、そのままでは次の処理を行えないイベントであれば、文字列が得られないと正しい状態を操作パネル２７上に表示してユーザに提示できないので、処理を中断すると判断することができる。汎用メッセージを表示しても不具合を解決できないイベント（装置の電源ＯＦＦ、ＯＮが必要なイベントなど）や、正しいガイダンスやフィードバックを表示できないため、継続して動作させると誤動作を誘発する可能性があるイベントについても同様である。

また、操作パネル２７上に表示させたい画面やその画面操作により、処理を継続するか中断するかを決定することもできる。あるいはまた、操作パネル２７上に処理を継続するか中断するかの操作を促すメッセージや操作ボタン等を表示させ、その操作ボタン等の操作を受け付けることにより、処理を継続するか中断するかを決定することもできる。また、無条件に処理を中断することも可能である。

いずれにせよ、ステップＳ１０で処理を継続する場合、ＣＰＵ２１は、検出したイベントに対応する文字列の代わりとなる汎用文字列を取得し、その汎用文字列を用いて操作パネル２７に表示させる情報（ユーザに提示する表示画面など）を生成する（Ｓ１１）。その後、その生成した情報を操作パネル２７に表示させ（Ｓ７）、処理を終了する。なお、汎用文字列は、予め定めておくものであり、「ＭＦＰ本体の状態が変化しました。しばらくしてから実行してください。」等が考えられる。
また、ステップＳ１１も生成手順の処理であり、ＣＰＵ２１は、ステップＳ１１においても生成手段として機能する。

また、ステップＳ４で応答がなかった場合には、ＣＰＵ２１は、問い合わせ先のアプリが停止中か否かを判断する（Ｓ１２）。この判断は、問い合わせ先のアプリの状態を監視することによって行うことができる。また、この判断を行うのは、問い合わせ先のアプリが起動していなければ文字列の問い合わせができないためである。また、アプリは、操作パネル２７上での操作が一定時間ない場合にスリープ状態になる設定がなされていた場合等には、起動されていても一時的に停止する場合がある。

ＣＰＵ２１は、ステップＳ１２で停止中と判断した場合、ＯＳに対して問い合わせ先アプリの再起動を要求する（Ｓ１３）。そして、再起動が成功したか否か判断し（Ｓ１４）、成功してれば、ステップＳ３に戻って再度の問い合わせを行う。なお、ステップＳ１４での待機中はユーザにレスポンスを待たせることになるため、タイムアウトを設定し、一定時間内に再起動が成功しない場合、再起動失敗として処理を進めるとよい。
ＣＰＵ２１は、ステップＳ１３において再起動手段として機能する。

また、ステップＳ１２で停止中でないか、またはステップＳ１４で再起動できない場合、問い合わせ先のアプリは当面利用できないことがわかる。なお、応答がない（Ｓ４でＮ）にも関わらず停止中でない（Ｓ１２でＮ）場合には、アプリがハングアップしていることが考えられる。
この場合、ＣＰＵ２１は、問い合わせ先アプリが利用できない状態でＵＩの動作を継続するか否かを判断する（Ｓ１５）。この判断は、継続するか否かの設定に基づいて行えばよい。また、ステップＳ１５の時点で操作パネル２７上に継続するか否かの選択画面を表示させ、ユーザに選択させるようにしてもよい。

ステップＳ１５に進むということは、本来文字列を問い合わせるべきアプリが利用できないということで、用語ＩＤと対応する文字列を取得できなかったり、あちこちに問い合わせて取得に時間がかかったりすることが想定される。このような状態でも実行中のアプリの動作を継続させたいか否かに基づき、ステップＳ１５の判断結果が定められればよい。

いずれにせよ、ステップＳ１５で継続する場合、ＣＰＵ２１は、ステップＳ８に進み、他の問い合わせ先を探す。他に問い合わせ先がない場合、ステップＳ１０以下の処理に進むことになる。
また、継続しない場合、ＣＰＵ２１は、検出したイベントに対応する文字列の代わりとなる汎用のエラー文字列を取得し、そのエラー文字列を用いて操作パネル２７に表示させる情報（ユーザに提示する表示画面など）を生成する（Ｓ１６）。なお、エラー文字列は、予め定めておくものであり、「エラーが発生しました。」等が考えられる。

そして、その生成した情報を操作パネル２７に表示させた後（Ｓ１７）、実行中の処理に係るアプリの動作を中断（一旦停止）する（Ｓ１８）。
ＣＰＵ２１は、ステップＳ１８において停止手段として機能する。この状態で動作を継続しても、イベントに対応するメッセージ等を迅速かつ適切に表示できないと考えられるためである。またこのため、更なる不具合の原因となることが考えられるためである。

以上の処理によれば、操作部２０のアプリが、いずれの問い合わせ先からも検出したイベントと対応する文字列を取得できない場合に、ユーザに提示する情報として、予め定めた情報を生成することができる。そして、このことにより、アプリがエラーで終了してしまうのを防止することができる。また、上記予め定めた情報により、検出したイベントと対応する文字列又は画像を取得できない旨をユーザが知ることが可能になり、ユーザによる使い勝手の向上につながる。

また、アプリが、問い合わせ先検索テーブルに含まれる問い合わせ先の少なくとも１つが利用できないことを検出した場合に、自己を停止させることができる。そして、このことにより、迅速かつ適切な反応が難しい状態でアプリを動作させて、ユーザに不快感を持たせたり、誤動作を誘発したりすることを避けられる。
また、アプリが、文字列の取得先のアプリ等が停止していることを検出した場合に、その問い合わせ先の再起動を試みることができる。そして、このことにより、問い合わせ先がスリープ状態等で停止していた場合でも、そこから上記検出したイベントと対応する文字列を取得することができる。

〔この実施形態におけるプログラム〕
この発明の実施形態であるプログラムは、操作部２０を制御するＣＰＵ２１（コンピュータ）に上述した機能を実現させるためのプログラムである。そして、このようなプログラムをコンピュータに実行させることにより、上述したような効果を得ることができる。

このようなプログラムは、はじめからコンピュータに備えるＲＯＭや他の不揮発性記憶媒体（フラッシュメモリ，ＥＥＰＲＯＭ等）などに格納しておいてもよい。しかし、記録媒体であるＣＤ−ＲＯＭ、あるいはメモリカード，フレキシブルディスク，ＭＯ，ＣＤ−Ｒ，ＣＤ−ＲＷ，ＤＶＤ＋Ｒ，ＤＶＤ＋ＲＷ，ＤＶＤ−Ｒ，ＤＶＤ−ＲＷ，又はＤＶＤ−ＲＡＭ等の不揮発性記録媒体に記録して提供することもできる。それらの記録媒体に記録されたプログラムをコンピュータにインストールして実行させることにより、上述した各手順を実行させることができる。
さらに、ネットワークに接続され、プログラムを記録した記録媒体を備える外部装置あるいはプログラムを記憶手段に記憶した外部装置からダウンロードし、コンピュータにインストールして実行させることも可能である。

〔変形例〕
以上で実施形態の説明を終了するが、この発明において、各部の具体的な構成や処理の内容、通信の手順、データの構成等は、実施形態で説明したものに限るものではない。
例えば、操作部２０内のＵＩアプリ（ここではＵＩアプリ２０１ｘとする）が利用する用語テーブルを、操作部２０とも本体１０とも異なるサーバ４０に設けることが考えられる。

この場合、図９に示すように、操作部２０は、ネットワーク３経由で用語ＩＤに対応する文字列をサーバ４０に問い合わせ、その文字列を取得する。このとき、操作部２０は、図２に示した通信Ｉ／Ｆ２５を介してサーバ４０と通信してもよいし、接続Ｉ／Ｆ２６を介して本体１０経由でサーバ４０と通信してもよい。サーバ４０に、上述の実施形態で説明したＵＩアプリと同様なアプリ間インタフェースを設けておけば、ＵＩアプリ２０１ｘからは、操作部２０内のＵＩアプリ２０１ｄに問い合わせる場合も、外部のサーバ４０に問い合わせる場合も、同じように問い合わせが可能である。図９において、ＵＩアプリ２０１ｄは図６のＵＩアプリ２０１ｄと同じであり、ＵＩアプリ２０１ｅ′は図６のＵＩアプリ２０１ｅと対応する。
また、ＵＩアプリ２０１ｅ′が、サーバ４０に対し、サーバ４０をスリープから復帰させるためのダミーデータを送信したり、サーバ４０のＯＳに対して用語問い合わせ先となるＵＩアプリの起動を要求したりすることができるようにしてもよい。

また、本体１０と対になった操作部２０だけでなく、本体１０と任意に無線接続可能な端末装置（例えばタブレット端末５０）においても、同様に、アプリが検出したイベントと対応する文字列の問い合わせを行うことができる。
図１０に示すように、タブレット端末５０内のＵＩアプリ２０１ａ′，２０１ｂ′が、ネットワーク３経由で本体１０からのイベントを受信し、操作部２０内のＵＩアプリ２０１ａ，２０１ｂ等と同様の処理を行う。ＵＩアプリ２０１ａ，２０１ｂは、図４に示したものと同じである。本体１０から操作部２０へのイベント通知はＷｅｂ・ＡＰＩ（Application Programming Interface）を用いるため、ネットワーク３経由のイベント通知でもＷｅｂ・ＡＰＩを用いることが可能である。なお、イベントを受信するタブレット端末５０では、予め本体１０との間でネゴシエーションを確立しておき、イベントの待ち状態を作っておくことが前提となる。
このことにより、タブレット端末５０を、本体１０を操作するための操作部２０と同様なリモートコントローラとして用いることができる。

また、上述した実施形態では、ＵＩアプリが用語ＩＤと対応する文字列を取得する例について説明したが、取得するのは画像であってもよい。もちろん、文字列と画像の組み合わせであってもよい。
表５に、画像を格納した用語テーブルの例を示す。この画像は、画像データそのものであってもよいし、画像データ（画像ファイル）の格納位置を示す情報であってもよい。

また、例えば、上述した実施形態では画像処理システム１を、本体１０と操作部２０とを固定的に組み合わせて構成した例について説明したが、これには限られない。
操作部と本体（動作部）とを、ハードウェアコンポーネントとして全く別の装置としてもよい。例えば、スマートフォン等のモバイル端末を操作部とし、ＭＦＰ等の画像処理装置を動作部として画像処理システムあるいは情報処理システムを構成してもよい。特に、操作部と動作部を無線で接続する場合には、これらは全く独立した装置として構成可能である。

また、操作部と動作部とは、１対１でなくてもよい。例えば、本体に有線接続された操作部がある画像処理装置を、モバイル端末からも操作できるようにすることが考えられる。あるいは、１台の画像処理装置を複数のモバイル端末から操作できるようにすることも考えられる。あるいはまた、１台のモバイル端末から操作対象を切り替えつつ複数の画像処理装置を操作できるようにすることも考えられる。
また、情報処理システムは、１の情報処理装置により実現されるものであってもよい。例えば、操作部２０は、単独でも情報処理システムであると考えることができる。

また、モジュール１つが１台の装置で構成される必要はない。複数台の装置が協働して１つのモジュールの機能を実現する構成であってもよい。逆に、複数のモジュールが１つの筐体に収まっていてもよい。
また、システムが３以上のモジュールを備える場合についても、本発明は適用可能である。

また、情報処理システムを構成する１のモジュールが、スキャナやプロッタのような画像処理エンジンを備えていることも必須ではない。各モジュールは、任意の情報処理装置でよい。もちろん、情報処理以外の物理的な入力や出力を合わせて行う装置でもよい。
さらに、この発明は上述した実施形態に限定されるものではなく、特許請求の範囲に記載された技術思想に含まれる技術的事項の全てが対象となることは言うまでもない。
さらにまた、以上説明してきた実施形態、動作例及び変形例の構成は、相互に矛盾しない限り任意に組み合わせて実施可能であることは勿論である。

１：画像処理システム、２：外部装置、３：ネットワーク、３ａ：ＬＡＮ、３ｂ：無線アクセスポイント、１０：本体、１１，２１：ＣＰＵ、１２，２２：ＲＯＭ、１３，２３：ＲＡＭ、１４：ＨＤＤ、１５，２５：通信Ｉ／Ｆ、１６，２６：接続Ｉ／Ｆ、１７：エンジン部、１８，２８：システムバス、２０：操作部、２７：操作パネル、３０：通信路、４０：サーバ、５０：タブレット端末、１０１，２０１：アプリ層、１０１ａ：コピー機能、１０１ｂ：スキャナ機能、１０１ｃ：ファクシミリ機能、１０１ｄ：プリンタ機能、１０２，２０２：サービス層、１０３，２０３：ＯＳ層、２０１ａ，２０１ｂ，２０１ａ′，２０１ｂ′，２０１ｄ，２０１ｄ′，２０１ｅ，２０１ｅ′，２０１ｆ，２０１ｈ，２０１ｉ，２０１ｊ：ＵＩアプリ、２１１ａ，２１１ｄ，２１１ｅ，２１３：用語テーブル

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

Claims (11)

1. １又は複数の情報処理装置により実現される情報処理システムであって、
   イベントを検出するイベント検出手段と、
   前記イベント検出手段がイベントを検出した場合に、イベントの種類又は送信元と該イベントと対応する文字列又は画像の取得先とを対応付けた取得先情報を参照して、前記検出したイベントの種類又は送信元に応じた取得先に、前記検出したイベントと対応する文字列又は画像を問い合わせる問い合わせ手段と、
   前記問い合わせ手段が前記取得先から取得した文字列又は画像に基づき、前記検出したイベントに応じてユーザに提示する情報を生成する生成手段とを備え、
   前記問い合わせ手段は、前記イベント検出手段が前記イベントを検出した場合に、まず所定の取得先に前記検出したイベントと対応する文字列又は画像を問い合わせ、該取得先から対応する文字列又は画像を取得できない場合に、前記取得先情報に従った取得先に前記検出したイベントと対応する文字列又は画像を問い合わせることを特徴とする情報処理システム。
2. １又は複数の情報処理装置により実現される情報処理システムであって、
   イベントを検出するイベント検出手段と、
   前記イベント検出手段がイベントを検出した場合に、イベントの種類又は送信元と該イベントと対応する文字列又は画像の取得先とを対応付けた取得先情報を参照して、前記検出したイベントの種類又は送信元に応じた取得先に、前記検出したイベントと対応する文字列又は画像を問い合わせる問い合わせ手段と、
   前記問い合わせ手段が前記取得先から取得した文字列又は画像に基づき、前記検出したイベントに応じてユーザに提示する情報を生成する生成手段とを備え、
   前記生成手段は、前記問い合わせ手段が前記取得先から前記検出したイベントと対応する文字列又は画像を取得できない場合に、前記ユーザに提示する情報として、予め定めた情報を生成することを特徴とする情報処理システム。
3. 請求項１に記載の情報処理システムであって、
   前記生成手段は、前記問い合わせ手段が前記取得先から前記検出したイベントと対応する文字列又は画像を取得できない場合に、前記ユーザに提示する情報として、予め定めた情報を生成することを特徴とする情報処理システム。
4. １又は複数の情報処理装置により実現される情報処理システムであって、
   イベントを検出するイベント検出手段と、
   前記イベント検出手段がイベントを検出した場合に、イベントの種類又は送信元と該イベントと対応する文字列又は画像の取得先とを対応付けた取得先情報を参照して、前記検出したイベントの種類又は送信元に応じた取得先に、前記検出したイベントと対応する文字列又は画像を問い合わせる問い合わせ手段と、
   前記問い合わせ手段が前記取得先から取得した文字列又は画像に基づき、前記検出したイベントに応じてユーザに提示する情報を生成する生成手段とを備え、
   前記問い合わせ手段は、当該情報処理システムが備えるアプリケーションに含まれるものであり、
   前記取得先情報に含まれる取得先の少なくとも１つが利用できないことを検出した場合に、前記問い合わせ手段を備えるアプリケーションを停止させる停止手段を備えることを特徴とする情報処理システム。
5. 請求項１乃至３のいずれか一項に記載の情報処理システムであって、
   前記問い合わせ手段は、当該情報処理システムが備えるアプリケーションに含まれるものであり、
   前記取得先情報に含まれる取得先の少なくとも１つが利用できないことを検出した場合に、前記問い合わせ手段を備えるアプリケーションを停止させる停止手段を備えることを特徴とする情報処理システム。
6. １又は複数の情報処理装置により実現される情報処理システムであって、
   イベントを検出するイベント検出手段と、
   前記イベント検出手段がイベントを検出した場合に、イベントの種類又は送信元と該イベントと対応する文字列又は画像の取得先とを対応付けた取得先情報を参照して、前記検出したイベントの種類又は送信元に応じた取得先に、前記検出したイベントと対応する文字列又は画像を問い合わせる問い合わせ手段と、
   前記問い合わせ手段が前記取得先から取得した文字列又は画像に基づき、前記検出したイベントに応じてユーザに提示する情報を生成する生成手段とを備え、
   前記問い合わせ手段は、前記取得先情報が示す、前記検出したイベントの種類又は送信元に応じた取得先が停止していることを検出した場合に、該取得先の再起動を試みる再起動手段を備えることを特徴とする情報処理システム。
7. 請求項１乃至３のいずれか一項に記載の情報処理システムであって、
   前記問い合わせ手段は、前記取得先情報が示す、前記検出したイベントの種類又は送信元に応じた取得先が停止していることを検出した場合に、該取得先の再起動を試みる再起動手段を備えることを特徴とする情報処理システム。
8. １又は複数の情報処理装置により実現される情報処理システムであって、
   イベントを検出するイベント検出手段と、
   前記イベント検出手段がイベントを検出した場合に、イベントの種類又は送信元と該イベントと対応する文字列又は画像の取得先とを対応付けた取得先情報を参照して、前記検出したイベントの種類又は送信元に応じた取得先に、前記検出したイベントと対応する文字列又は画像を問い合わせる問い合わせ手段と、
   前記問い合わせ手段が前記取得先から取得した文字列又は画像に基づき、前記検出したイベントに応じてユーザに提示する情報を生成する生成手段とを備え、
   ユーザの操作を受け付けるための操作部と、該操作部が受け付けた操作に基づき動作を実行する動作部とを備え、
   前記操作部が、前記イベント検出手段、前記問い合わせ手段及び前記生成手段を備え、
   前記イベント検出手段は、前記動作部から送信されるイベントを検出することを特徴とする情報処理システム。
9. 請求項１乃至７のいずれか一項に記載の情報処理システムであって、
   ユーザの操作を受け付けるための操作部と、該操作部が受け付けた操作に基づき動作を実行する動作部とを備え、
   前記操作部が、前記イベント検出手段、前記問い合わせ手段及び前記生成手段を備え、
   前記イベント検出手段は、前記動作部から送信されるイベントを検出することを特徴とする情報処理システム。
10. １の情報処理装置が、または複数の情報処理装置が協働して、
    イベントを検出するイベント検出手順と、
    前記イベント検出手順でイベントを検出した場合に、まず所定の取得先に前記検出したイベントと対応する文字列又は画像を問い合わせ、該取得先から対応する文字列又は画像を取得できない場合に、イベントの種類又は送信元と該イベントと対応する文字列又は画像の取得先とを対応付けた取得先情報を参照して、前記検出したイベントの種類又は送信元に応じた取得先に、前記検出したイベントと対応する文字列又は画像を問い合わせる問い合わせ手順と、
    前記問い合わせ手順で前記取得先から取得した文字列又は画像に基づき、前記検出したイベントに応じてユーザに提示する情報を生成する生成手順とを実行することを特徴とする情報処理方法。
11. １のコンピュータを、または複数のコンピュータを協働させて、
    イベントを検出するイベント検出手段と、
    前記イベント検出手段がイベントを検出した場合に、まず所定の取得先に前記検出したイベントと対応する文字列又は画像を問い合わせ、該取得先から対応する文字列又は画像を取得できない場合に、イベントの種類又は送信元と該イベントと対応する文字列又は画像の取得先とを対応付けた取得先情報を参照して、前記検出したイベントの種類又は送信元に応じた取得先に、前記検出したイベントと対応する文字列又は画像を問い合わせる問い合わせ手段と、
    前記問い合わせ手段が前記取得先から取得した文字列又は画像に基づき、前記検出したイベントに応じてユーザに提示する情報を生成する生成手段として機能させるためのプログラム。

Images