図1は、本発明の実施例に該当する融合機101を表す。図1の融合機101は、種々のハードウェア111と、種々のソフトウェア112と、融合機起動部113により構成される。
融合機101のハードウェア111としては、撮像部121と、印刷部122と、その他のハードウェア123が存在する。撮像部121は、読取原稿から画像(画像データ)を読み取るためのハードウェアである。印刷部122は、画像(画像データ)を印刷用紙に印刷するためのハードウェアである。
融合機101のソフトウェア112としては、種々のアプリケーション131と、種々のプラットフォーム132が存在する。これらのプログラムは、UNIX(登録商標)等のOS(オペレーティングシステム)によりプロセス単位で並列的に実行される。
アプリケーション131としては、コピー用のアプリケーションであるコピーアプリ141、プリンタ用のアプリケーションであるプリンタアプリ142、スキャナ用のアプリケーションであるスキャナアプリ143、ファクシミリ用のアプリケーションであるファクシミリアプリ144、ネットワークファイル用のアプリケーションであるネットワークファイルアプリ145が存在する。
アプリケーション131は、専用のSDK(ソフトウェア開発キット)を使用して開発することができる。SDKを使用して開発したアプリケーション131をSDKアプリと呼ぶ。専用のSDKとしては、C言語でアプリケーション131を開発するための「CSDK」や、Java(登録商標)言語でアプリケーション131を開発するための「JSDK」が提供される。CSDKを使用して開発したアプリケーション131を「CSDKアプリ」と呼び、JSDKを使用して開発したアプリケーション131を「JSDKアプリ」と呼ぶ。図1の融合機101にも、CSDKアプリ146と、JSDKアプリ147が存在する。図1の融合機101にはさらに、Java(登録商標)言語で記述されたJSDKアプリ147とC言語で記述された他のソフトウェア112との仲介を行うソフトウェア112として、JSDKプラットフォーム148が存在する。
プラットフォーム132としては、種々のコントロールサービス151、システムリソースマネージャ152、種々のハンドラ153が存在する。コントロールサービス151としては、ネットワークコントロールサービス(NCS)161、ファクシミリコントロールサービス(FCS)162、デリバリコントロールサービス(DCS)163、エンジンコントロールサービス(ECS)164、メモリコントロールサービス(MCS)165、オペレーションパネルコントロールサービス(OCS)166、サーティフィケーションコントロールサービス(CCS)167、ユーザディレクトリコントロールサービス(UCS)168、システムコントロールサービス(SCS)169が存在する。ハンドラ153としては、ファクシミリコントロールユニットハンドラ(FCUH)171、イメージメモリハンドラ(IMH)172が存在する。
NCS161のプロセスは、ネットワーク通信の仲介を行う。FCS162のプロセスは、ファクシミリのAPIを提供する。DCS163のプロセスは、蓄積文書の配信処理に関する制御を行う。ECS164のプロセスは、撮像部121や印刷部122に関する制御を行う。MCS165のプロセスは、メモリやハードディスクドライブに関する制御を行う。OCS166のプロセスは、オペレーションパネルに関する制御を行う。CCS167のプロセスは、認証処理や課金処理に関する制御を行う。UCS168のプロセスは、ユーザ情報の管理に関する制御を行う。SCS169のプロセスは、システムの管理に関する制御を行う。
アプリケーション131とプラットフォーム132の仲介を行うソフトウェア112として、仮想アプリケーションサービス(VAS)135が存在する。VAS135は、アプリケーション131をクライアントとするサーバプロセスとして動作すると共に、プラットフォーム132をサーバとするクライアントプロセスとして動作する。VAS135は、アプリケーション131から見てプラットフォーム132を隠蔽するラッピング機能を備え、プラットフォーム132のバージョンアップに伴うバージョン差を吸収する役割等を担う。
融合機起動部113は、融合機101の電源投入時に最初に実行される。これにより、UNIX(登録商標)等のOSが起動され、アプリケーション131やプラットフォーム132が起動される。これらのプログラムは、ハードディスクドライブやメモリカードに蓄積されており、ハードディスクドライブやメモリカードから再生されて、メモリに起動されることになる。
図2は、図1の融合機101に係るハードウェア構成図である。融合機101のハードウェア111としては、コントローラ201と、オペレーションパネル202と、ファクシミリコントロールユニット(FCU)203と、撮像部121と、印刷部122が存在する。
コントローラ201は、CPU211、ASIC212、NB221、SB222、MEM−P231、MEM−C232、HDD(ハードディスクドライブ)233、メモリカードスロット234、NIC(ネットワークインタフェースコントローラ)241、USBデバイス242、IEEE1394デバイス243、セントロニクスデバイス244により構成される。
CPU211は、種々の情報処理用のICである。ASIC212は、種々の画像処理用のICである。NB221は、コントローラ201のノースブリッジである。SB222は、コントローラ201のサウスブリッジである。MEM−P231は、融合機101のシステムメモリである。MEM−C232は、融合機101のローカルメモリである。HDD233は、融合機101のストレージである。メモリカードスロット234は、メモリカード235をセットするためのスロットである。NIC241は、MACアドレスによるネットワーク通信用のコントローラである。USBデバイス242は、USB規格の接続端子を提供するためのデバイスである。IEEE1394デバイス243は、IEEE1394規格の接続端子を提供するためのデバイスである。セントロニクスデバイス244は、セントロニクス仕様の接続端子を提供するためのデバイスである。
オペレーションパネル202は、オペレータが融合機101に入力を行うためのハードウェア(操作部)であると共に、オペレータが融合機101から出力を得るためのハードウェア(表示部)である。
図3は、図1の融合機101に係る外観図である。図3には、撮像部121の位置と、印刷部122の位置と、オペレーションパネル202の位置が図示されている。図3には更に、読取原稿のセット先となる原稿セット部301と、印刷用紙の給紙先となる給紙部302と、印刷用紙の排紙先となる排紙部303が図示されている。
オペレーションパネル202は、図4のように、タッチパネル311と、テンキー312と、スタートボタン313と、リセットボタン314と、機能キー315と、初期設定ボタン316により構成される。タッチパネル311は、タッチ操作で入力を行うためのハードウェア(タッチ操作部)であると共に、画面表示で出力を得るためのハードウェア(画面表示部)である。テンキー312は、キー(ボタン)操作で数字入力を行うためのハードウェアである。スタートボタン313は、ボタン操作でスタート操作を行うためのハードウェアである。リセットボタン314は、ボタン操作でリセット操作を行うためのハードウェアである。機能キー315は、キー(ボタン)操作でCSDKアプリ146やJSDKアプリ147による操作画面を表示させるためのハードウェアである。初期設定ボタン316は、ボタン操作で初期設定画面を表示させるためのハードウェアである。
原稿セット部301は、ADF(自動原稿搬送装置)321と、フラットベッド322と、フラットベッドカバー323により構成される。給紙部302は、4個の給紙トレイにより構成される。排紙部303は、1個の排紙トレイにより構成される。
(JSDK)
図5は、図1のJSDKアプリ147とJSDKプラットフォーム148のクラス図である。JSDKアプリ147とJSDKプラットフォーム148は、全体で1プロセスとして、同一プロセス上で実行される。JSDKアプリ147とJSDKプラットフォーム148中の各ブロックは、それぞれこの1プロセス上のスレッドとして、スレッド単位で並列的に実行(マルチスレッド)される。JSDKアプリ147とJSDKプラットフォーム148は、Java(登録商標)コンパイラによりソースコードからバイトコードに一括翻訳されており、Java(登録商標)仮想マシンにより逐次実行される。JSDKアプリ147とJSDKプラットフォーム148は、Java(登録商標) 2 Micro EditionのPersonal Basis Profileをベースとする実装となっている。
JSDKアプリ147としては、ユーザアプリ501に加えて、監視アプリ511と、JSDK GUI Manager512と、Task Bar Manager513等が存在する。
ユーザアプリ501は、融合機101のユーザ(例えばベンダ)がJSDKを使用して開発したJSDKアプリである。監視アプリ511は、他のJSDKアプリ(ユーザアプリ501等)の実行状態の監視等を行うJSDKアプリである。JSDK GUI Manager512は、他のJSDKアプリ(ユーザアプリ501等)を操作対象とする操作画面の表示等を行うJSDKアプリである。Task Bar Manager513は、他のJSDKアプリ(ユーザアプリ501等)を操作対象とするタスクバーの表示等を行うJSDKアプリである。
ユーザアプリ501はここでは、スタンドアロンアプリケーションやアプレットと並ぶJava(登録商標)アプリケーションであるXletである。監視アプリ511とJSDK GUI Manager512とTask Bar Manager513はここでは、独自の拡張を施したXlet(XletEx)である。
JSDKプラットフォーム148には、JSDK Main521と、JSDK Environment522と、Locale Manager523と、Xlet Manager531と、Multi Xlet Manager532と、JSDK Manager533と、Send Manager541と、Event Manager542と、System Event Manager543と、Panel Manager544と、Install Manager545と、Server/Client Manager546等のクラスが存在する。
JSDK Main521は、JSDKシステムの起動設定を行うクラスである。JSDK Environment522は、JSDKシステムの起動環境設定を行うクラスである。Locale Manager523は、国際化対応(言語指定)を行うクラスである。
Xlet Manager531は、1対1でXletのライフサイクルを管理するクラスである。ここでは、6個のXletのライフサイクルが1対1で6個のXlet Manager531によって管理される。Multi Xlet Manager532は、全てのXlet Manager531のライフサイクルを管理するクラスである。ここでは、6個のXlet Manager531のライフサイクルが全て1個のMulti Xlet Manager532によって管理される。JSDK Manager533は、JSDKシステム全体のライフサイクルを管理するクラスである。例えば、Multi Xlet Manager532,Send Manager541,Event Manager542,System Event Manager543,Panel Manager544,Install Manager545,Server/Client Manager546のライフサイクルが、JSDK Manager533によって管理される。
System Event Manager543は、図1のプラットフォーム132からのシステムイベント(電力モード等)の管理を行うクラスである。Panel Manager544は、1個のXletがオペレーションパネル202の画面を占有する際の調停等を行うクラスである。Install Manager545は、SDcardやWebからのインストールやアンインストールの管理を行うクラスである。
図5のJSDKシステムでは、APIとして、JSDK API551とJSDK API552が利用される。なお、XletとXletExの差異として、オブジェクトにアクセスするのにJSDK API551の利用とJSDKプラットフォーム148へのアクセスが可能である点が挙げられる。図1の融合機101にはさらに、図5のJSDKシステムに係る要素として、C言語とJava(登録商標)言語のインタフェースとなるJSDK Session553とNative JSDK Session554や、JSDKアプリ147とJSDKプラットフォーム148を実行するためJava(登録商標)仮想マシンであるCVM555等が存在する。
図6は、JSDKシステムの起動手順について説明するための図である。JSDKシステムではまず、JSDKアプリ147を起動するmain()関数を有するクラスであるJSDK Main521が、JSDK Environment522を生成(S1)する。続いて、JSDK Environment522が、Native層の構築(S2)と言語環境の構築(S3)をもって、JSDKシステムの実行環境の構築を行う。続いて、JSDK Environment522が、JSDK Manager533を生成(S4)する。JSDKシステムではそして、JSDK Manager533が、システム層のManagerを生成(S5−12)し、Multi Xlet Manager532とXlet Manager531を通じて、アプリ層のManagerを生成(S13−15)する。
図7は、JSDKシステムのGUI(Graphical User Interface)について説明するための図である。融合機101の機能キー315(図4参照)を押すと、図6のS1−15が実行されて、図7のGUIが融合機101のタッチパネル311(図4参照)に表示される。図7のGUIは、ユーザアプリ501を操作対象とする操作画面であり、図6のS14で起動されたJSDK GUI Manager512によって表示される。
図7Aは、画面を占有させるユーザアプリ501の切替操作を行うための切替操作画面である。図7Bは、ユーザアプリ501の起動操作を行うための起動操作画面である。図7Cは、ユーザアプリ501の終了操作を行うための終了操作画面である。図7Dは、ユーザアプリ501のインストール操作を行うためのインストール操作画面である。図7Eは、ユーザアプリ501のアンインストール操作を行うためのアンインストール操作画面である。図7Aが、機能キー315を押した直後にタッチパネル311に表示される初期画面であり、図7A,B,C,D,Eはそれぞれ切り替え,起動,終了,インストール,アンインストールのボタンをタッチすると表示されることになる。
SimplePrint,SimpleCopy,SimpleOcr,SimpleScan等はそれぞれユーザアプリ501である。例えば、SimplePrintは、電子文書のファイル名を入力することで当該電子文書のプリントを実行できるようにするためのアプリケーションである。なお、アプリケーションのタイプとは、GUIを有するアプリケーションであるか否かを意味する。
図7Aの切替操作画面について説明する。図7Aの切替操作画面には、切替操作対象としてインストール済みで実行中のユーザアプリ501の一覧が表示される。
図7Aの切替操作画面で「SimplePrint」にタッチすると、SimplePrintにオペレーションパネル202のオーナー権が付与されることになり、SimplePrintが画面を占有することになる。これに伴って、図7Aの画面から図8Aの画面に画面が移る。図8Aは、画面を占有するSimplePrintにより表示されるGUIである。
図7Aの切替操作画面で「SimpleCopy」にタッチすると、SimpleCopyにオペレーションパネル202のオーナー権が付与されることになり、SimpleCopyが画面を占有することになる。これに伴って、図7Aの画面から図8Bの画面に画面が移る。図7Aに示すように、SimpleCopyの状態は「異常」なので、図8Bのように、画面上にはSimpleCopyに係るエラーメッセージが表示される。
図7Aの切替操作画面で「SimpleOcr」にタッチすると、SimpleOcrにオペレーションパネル202のオーナー権が付与されることになり、SimpleOcrが画面を占有することになる。これに伴って、図7Aの画面から図8Cの画面に画面が移る。図7Aに示すように、SimpleOcrのタイプは「GUI無」なので、図8Cのように、画面上にはSimpleOcrの状態が表示される。
図8A,B,Cの画面の左端(楕円形で示す領域内)には、図6のS15で起動されたTask Bar Manager513により、ユーザアプリ501を操作対象とするタスクバーが表示される。これらのタスクバーは、画面を占有させるユーザアプリ501の切替操作を行うための切替タスクバーである。
図8Aの画面で切替タスクバー中の「SC」や「SO」にタッチすると、SimpleCopyやSimpleOcrにオペレーションパネル202のオーナー権が付与されることになり、SimpleCopyやSimpleOcrが画面を占有することになる。これに伴い、図8Aの画面から図8Bや図8Cの画面に画面が移る。図8Aの画面で切替タスクバー中の「JSDK」にタッチすると、図7Aの画面に画面が戻る。
図8Bの画面で切替タスクバー中の「SP」や「SO」にタッチすると、SimplePrintやSimpleOcrにオペレーションパネル202のオーナー権が付与されることになり、SimplePrintやSimpleOcrが画面を占有することになる。これに伴い、図8Bの画面から図8Aや図8Cの画面に画面が移る。図8Bの画面で切替タスクバー中の「JSDK」にタッチすると、図7Aの画面に画面が戻る。
図8Cの画面で切替タスクバー中の「SP」や「SC」にタッチすると、SimplePrintやSimpleCopyにオペレーションパネル202のオーナー権が付与されることになり、SimplePrintやSimpleCopyが画面を占有することになる。これに伴い、図8Cの画面から図8Aや図8Bの画面に画面が移る。図8Cの画面で切替タスクバー中の「JSDK」にタッチすると、図7Aの画面に画面が戻る。
図7Bの起動操作画面について説明する。図7Bの起動操作画面には、起動操作対象としてインストール済みで実行されていないユーザアプリ501の一覧が表示される。
図7Bの起動操作画面で「SimplePrint」にタッチすると、SimplePrintの起動処理を実行するか否かを確認する確認画面(図9)が表示される。図9の確認画面でプロダクトコードを入力し「実行」にタッチすると、SimplePrintが起動されることになる。
図7Cの終了操作画面について説明する。図7Cの終了操作画面には、終了操作対象としてインストール済みで実行中のユーザアプリ501の一覧が表示される。
図7Cの終了操作画面で「SimplePrint」にタッチすると、SimplePrintの強制終了処理を実行するか否かを確認する確認画面(図10)が表示される。図10の確認画面で「実行」にタッチすると、SimplePrintが強制終了されることになる。
図7Dのインストール操作画面について説明する。ユーザアプリ501のインストール処理により、起動可能ユーザアプリとして未登録のユーザアプリ501が起動可能ユーザアプリとして登録されることになる。図7Dのインストール操作画面には、インストール操作対象としてユーザアプリ501の一覧がインストール状況と共に表示される。
図7Dのインストール操作画面で「SimplePrint」にタッチすると、SDcardを格納元とするSimplePrintのインストール先を確認する確認画面(図11)が表示される。図11の確認画面で「SDcard」にタッチすると、SimplePrintがSDcardをインストール先としてインストールされることになり、図11の確認画面で「HDD」にタッチすると、SimplePrintがHDDをインストール先としてインストールされることになる。
図7Eのアンインストール操作画面について説明する。ユーザアプリ501のアンインストール処理により、起動可能ユーザアプリとして登録済みのユーザアプリ501が起動可能ユーザアプリとしての登録を抹消されることになる。図7Eのアンインストール操作画面には、アンインストール操作対象として登録済みのユーザアプリ501の一覧が表示される。
図7Eのアンインストール操作画面で「SimplePrint」にタッチすると、SimplePrintのアンインストール処理を実行するか否かを確認する確認画面(図12)が表示される。図12の確認画面で「実行」にタッチすると、SimplePrintがアンインストールされることになる。
図13は、起動操作画面の表示手順について説明するための図である。切替操作画面で起動のボタンがタッチされると、JSDK GUI Manager512からInstall Manager545に、インストール済みのユーザアプリ501の一覧要求が送信(S1)される。これに応じて、Install Manager545は、インストール済みのユーザアプリ501の格納位置に係る情報(融合機101内のNVRAMに格納されている)を元に、インストール済みのユーザアプリ501のJNLPファイルを取得(S2)する。融合機101にセットされたSDcardからは、当該SDcard内のユーザアプリ501のJNLPファイルが取得される。融合機101内のHDDからは、当該HDD内のユーザアプリ501のJNLPファイルが取得される。JNLPファイルは、ユーザアプリ501と1対1で対応しており、ユーザアプリ501の定義付けに係る情報を含んでいる。そして、インストール済みのユーザアプリ501のJNLPファイルの内容を元に、Install Manager545からJSDK GUI Manager512に、インストール済みのユーザアプリ501の一覧応答が送信(S3)される。これにより、切替操作画面から起動操作画面に画面が移ることになる。
図14は、起動処理の実行手順について説明するための図である。起動操作画面で選択操作が実行されて確認画面で確認操作が実行されると、JSDK GUI Manager512からJSDK Manager533に、ユーザアプリ501の起動要求が送信(S1)される。これに応じて、JSDK Manager533からMulti Xlet Manager532に、Authentication Manager547による認証処理を経由してから、ユーザアプリ501の起動要求が送信(S2)される。これに応じて、Multi Xlet Manager532がXlet Manager531を起動(S3)し、Xlet Manager531がPanel Manager544からルートウィンドウを取得(S4)し、Xlet Manager531がユーザアプリ501を起動(S5)する。そして、Multi Xlet Manager532からJSDK Manager533に、ユーザアプリ533の起動応答が送信(S6)される。そして、JSDK Manager533からJSDK GUI Manager512に、ユーザアプリ533の起動応答が送信(S7)される。
図15は、インストール操作画面の表示手順について説明するための図である。切替操作画面上でインストールのボタンがタッチされると、JSDK GUI Manager512からInstall Manager545に、ユーザアプリ501の一覧要求が送信(S1)される。これに応じて、Install Manager545は、ユーザアプリ501のJNLPファイルを取得(S2)する。融合機101にセットされたSDcardからは、当該SDcard内のユーザアプリ501のJNLPファイルが取得される。融合機101とネットワークで接続されたWebサーバからは、当該Webサーバ内のユーザアプリ501のJNLPファイルが取得される。JNLPファイルは、ユーザアプリ501と1対1で対応しており、ユーザアプリ501の定義付けに係る情報を含んでいる。そして、ユーザアプリ501のインストール状況に関する情報(融合機101内のNVRAMに格納されている)や、ユーザアプリ501のJNLPファイルの内容を元にして、Install Manager545からJSDK GUI Manager512に、ユーザアプリ501の一覧応答が送信(S3)される。これにより、切替操作画面からインストール操作画面に画面が移ることになる。
図16は、インストール処理の実行手順について説明するための図である。インストール操作画面で選択操作が実行されて確認画面で確認操作が実行されると、JSDK GUI Manager512からInstall Manager545に、ユーザアプリ501のインストール要求が送信(S1)される。これに応じて、Install Manager545は、Authentication Manager547による認証処理を経由してから、ユーザアプリ501をインストール(S2)する。そして、Install Manager545からJSDK GUI Manager512に、ユーザアプリ533のインストール応答が送信(S3)される。
図17は、JNLPファイルの構文の例を表す。JNLP(Java(登録商標) Network Launching Protocol)ファイルはXML(eXtensible Markup Language)ファイルであり、JNLPファイル書式はJNLP規格に準拠している。ただし、JSDK向けに独自の拡張を施している部分があるため、以下その部分について説明する。
記述1は、informationエレメントであり、アプリケーション名を示すtitleエレメント(記述1A)や、ベンダ名を示すvenderエレメント(記述1B)や、ベンダの電話番号を示すtelephoneエレメント(記述1C)や、ベンダのファクス電話番号を示すfaxエレメント(記述1D)や、アプリケーションのプロダクトIDを示すproductIDエレメント(記述1E)を含んでいる。
記述2は、securityエレメントである。
記述3は、resourceエレメントであり、JSDKのバージョンを指定するjsdkエレメント(記述3A)や、JARファイル(アプリケーションの実行ファイル)とそのバージョンを指定するjarエレメント(記述3B)や、SUB−JNLPファイルを指定するsub−jnlpエレメント(記述3C)を含んでいる。
記述4は、updateエレメントであり、更新処理の実行方法を設定するエレメントである。autoであればアプリケーションの更新処理は自動更新で実行され、manualであればアプリケーションの更新処理は手動更新で実行され、mailであればアプリケーションの更新処理が実行可能である場合にその旨を通知する更新通知メールが配信される。
記述5は、installエレメントであり、インストール処理の実行方法を設定するエレメントである。autoであればアプリケーションのインストール先は自動選択にて選択され、manualであればアプリケーションのインストール先は手動選択にて選択される。
記述6は、アプリケーションのタイプが「GUI有」であるか「GUI無」であるかを示す。
図17のupdateエレメントで触れたように、インストール済みのJSDKアプリ147は更新処理の対象となる。以下、インストール済みのJSDKアプリ147を自動更新する自動更新処理について説明する。
図18は、SDcard又はHDD内のJSDKアプリ147(更新対象アプリ)を、SDcardからのJSDKアプリ147(更新用アプリ)に自動更新する自動更新処理に係るフローチャートである。
JSDKプラットフォーム148は、融合機101に接続された更新用SDcardスロットに更新用SDcardがセットされた場合、更新用SDcard内の更新用アプリのJNLPファイルを取得(S101)する。JSDKプラットフォーム148は、そのJNLPファイルのupdateエレメントが「auto」で、そのJNLPファイルに係る更新用アプリと同一の更新対象アプリが存在する場合(S102・S103)には、その更新用アプリのバージョンとその更新対象アプリのバージョンとを比較(S104)する。JSDKプラットフォーム148は、更新用アプリのバージョンが更新対象アプリのバージョンより新しい場合(S105)には、更新用アプリをもって更新対象アプリを更新(S106)する。
図19は、SDcard又はHDD内のJSDKアプリ147(更新対象アプリ)を、WebからのJSDKアプリ147(更新用アプリ)に自動更新する自動更新処理に係るフローチャートである。
JSDKプラットフォーム148は、更新対象アプリのJNLPファイルを取得(S201)する。JSDKプラットフォーム148は、そのJNLPファイルのupdateエレメントが「auto」で、そのJNLPファイルに係る更新対象アプリと同一の更新用アプリが、融合機101とネットワーク接続されたWebサーバ内に存在する場合(S202・S203)には、その更新対象アプリのバージョンとその更新用アプリのバージョンとを比較(S204)する。JSDKプラットフォーム148は、更新対象アプリのバージョンより更新用アプリのバージョンが新しい場合(S205)には、更新対象アプリを更新用アプリをもって更新(S206)する。
最後に、図5の説明中で登場したXlet等のライフサイクルについて説明することにする。
図20は、Xletの状態遷移図である。Xletの状態としては、初期化状態(Loaded)と、停止状態(Paused)と、活性化状態(Active)と、終了状態(Destroyed)が存在する。Xletの状態は、起動(initXlet)や、開始(startXlet)や、停止(pauseXlet)や、終了(destroyXlet)等のメソッドコールによって遷移する。Xletのライフサイクルとは、このようなXletの状態遷移にほかならない。ただし、どのような状態が存在するか、どのようにして状態が遷移するか、については様々なバリエーションがあり得るだろう。このことは、Xlet ManagerやMulti Xlet Managerその他の各Managerについても同様である。
初期化状態は、Xletインスタンスの生成直後の状態である。初期化状態への遷移は1度限りである。停止状態は、サービス提供停止中の状態であり、活性化状態は、サービス提供中の状態である。停止状態と活性化状態との間の遷移は何度でも可能である。終了状態は、Xletインスタンスの消滅直後の状態である。終了状態への遷移は1度限りである。
図5の説明中で記載したように、JSDKアプリ147のライフサイクルは、JSDKプラットフォーム148によって管理される。例えば、JSDKアプリ147は、自己の開始・停止・終了の際には自己の開始・停止・終了をJSDKプラットフォーム148に依頼するのである。JSDKアプリ147のライフサイクルをJSDKプラットフォーム148によって管理するメリットとしては例えば、メモリの節約が可能になることが挙げられる。特に、多数のJSDKアプリ147がそれぞれスレッドとして実行されるマルチスレッドにおいては、このメリットの存在価値は大きいと言える。JSDKアプリ147をXletとするメリットとしては例えば、JSDKアプリ147のライフサイクル管理が容易になることが挙げられる。
(監視アプリ)
図21は、図5の監視アプリ511について説明するための図である。
監視アプリ511は、他のJSDKアプリの実行状態の監視等を行うJSDKアプリである。JSDKアプリの実行状態を、当該JSDKアプリと同一プロセス(CVM555のプロセス)上で実行されるJSDKアプリ「監視アプリ511」が監視するのである。JSDKアプリの実行状態を、当該JSDKアプリと異なるプロセス上で実行されるプログラムが監視する事にすると、プロセス間通信でデータが授受される事になり、メモリが消費される事になってしまう。しかしここでは、JSDKアプリの実行状態を、当該JSDKアプリと同じプロセス上で実行されるプログラムが監視する事にするため、プロセス間通信でなく直にデータが授受される事になり、メモリが節約される事になるのである。
監視アプリ511は、ユーザアプリ501の実行状態の監視(図21参照)に加えて、JSDK GUI Manager512やTask Bar Manager513の実行状態の監視を行う。そのため、JSDKシステムの起動手順(図6参照)において、監視アプリ511はJSDK GUI Manager512やTask Bar Manager513より先に起動(S13−15)してバックグラウンドで動作する。監視アプリ511はさらに、アプリ層の各スレッドの実行状態の監視に加えて、システム層の各スレッドの実行状態の監視を行う。監視アプリ511はこのように、同一プロセス上で実行される各スレッドの実行状態の監視を行う事ができる。
監視アプリ511は、図21(A)に示す障害処理機能、図21(B)に示す画面表示機能、図21(C)に示す内部保存機能、図21(D)に示す外部送信機能等を備える。これらの機能は、1種類毎に別々に使用する事もできるし、2種類以上を同時に使用する事もできる。
図21(A)に示す障害処理機能によれば、監視アプリ511は、ユーザアプリ501に発生した障害を検出した場合、当該ユーザアプリ501の実行状態を当該障害の種類に応じて制御する「障害処理」を実行することになる。例えば、ユーザアプリ501の続行に支障のない障害ならば、当該ユーザアプリ501を続行する「続行処理」を実行する。例えば、ユーザアプリ501の続行に支障のある障害で、ユーザアプリ501の再起動により回避可能な障害ならば、当該ユーザアプリ501を再起動する「再起動処理」を実行する。例えば、ユーザアプリ501の続行に支障のある障害で、ユーザアプリ501の再起動により回避不可能な障害ならば、当該ユーザアプリ501を終了する「終了処理」を実行する。例えば、JSDKシステム全体の続行に支障のある障害ならば、JSDKシステム全体を終了する「システム終了処理」を実行する。すなわち、ユーザアプリ501がスレッドとして実行されるプロセス(CVM555のプロセス)自体が終了する。以上のようにして、図21(A)に示す画面表示機能によれば、ユーザアプリ501に残存するバグによる障害等が適切に処理されて、他のスレッドへの影響等が適切に回避されることになるのである。
上記「障害」は例えば、Java(登録商標)の「例外」をもって規定することが可能であり、上記「検出」は例えば、Java(登録商標)の「throw,catch」をもって規定することが可能である。このときには例えば、例外「I/O Exception」をcatchしたら「続行処理」か「再起動処理」を、例外「Unsupported」をcatchしたら「終了処理」を、例外「Out of Memory」をcatchしたら「システム終了処理」を実行することにするとよいだろう。入出力の例外は一時的であり、サポートの例外は致命的であり、メモリの例外はJSDKシステム全体の問題だからである。監視対象のユーザアプリ501の規定方法や障害の種類の規定方法についても、Java(登録商標)の規約をもって規定することが可能である。
図21(B)に示す画面表示機能によれば、監視アプリ511は、ユーザアプリ501に発生した障害を検出した場合、当該障害に係る情報を当該融合機101の画面(タッチパネル311等の表示装置等)に表示することになる。図21では、当該障害に係る情報として、アプリケーション名,障害名,通知先が表示されている。図21では、当該障害に係る情報の他に、続行ボタン,再起動ボタン,終了ボタン,システム終了ボタンが表示されている。これらの操作ボタンを表示する場合、障害処理機能においてどんな障害処理を実行するかが「自動指定」でなく「手動指定」になることになる。以上のようにして、図21(B)に示す画面表示機能によれば、障害に係る情報が表示されて、ユーザに通知されることになるのである。従来であれば、各ユーザアプリ501に画面表示用のコードを記述しておく必要があったものである。
図21(C)に示す内部保存機能によれば、監視アプリ511は、ユーザアプリ501に発生した障害を検出した場合、当該障害に係る情報を当該融合機101の内部(HDD233等の記憶装置等)に保存することになる。例えば、当該障害に係る情報を、ログを格納するログファイルに格納して保存する。以上のようにして、図21(C)に示す内部保存機能によれば、障害に係る情報が保存されて、障害解析やデバッグに利用されることになるのである。従来であれば、各ユーザアプリ501に内部保存用のコードを記述しておく必要があったものである。
図21(D)に示す外部送信機能によれば、監視アプリ511は、ユーザアプリ501に発生した障害を検出した場合、当該障害に係る情報を当該融合機101の外部(PC等の端末装置等)に送信することになる。例えば、当該障害に係る情報を、FTP等によるファイル転送,SMTP等によるメール配信,HTTPやSOAP等によるWebページ配信,スキャナドライバやプリンタドライバ等への応答と言った形式で送信する。以上のようにして、図21(D)に示す外部送信機能によれば、障害に係る情報が送信されて、ユーザに通知されたり障害解析やデバッグに利用されたりすることになるのである。従来であれば、各ユーザアプリ501に外部送信用のコードを記述しておく必要があったものである。外部送信は、イーサネット(登録商標)等のLANとインタネット等のWANの一方を経由して実施されても両方を経由して実施されてもよい。
図22は、図5の監視アプリ511の障害処理機能について説明するためのシーケンス図である。
JSDKシステムでは、JSDK Main521がXlet Manager531を起動(S11)して、続いて、Xlet Manager531が監視アプリ511を起動(S12)して、続いて、Xlet Manager531がユーザアプリ501を起動(S13)する。障害処理機能によれば、監視アプリ511は、ユーザアプリ501に発生した「再起動処理を実行すべき障害」を検出(S14)すると、当該ユーザアプリ501を再起動すべく再起動要求を発行する「再起動処理」を実行(S15)する。これにより、Xlet Manager531が当該ユーザアプリ501を再起動(S16)する。
図23は、図5の監視アプリ511の画面表示機能について説明するためのシーケンス図である。
JSDKシステムでは、JSDK Main521がXlet Manager531を起動(S21)して、続いて、Xlet Manager531が監視アプリ511を起動(S22)して、続いて、Xlet Manager531がユーザアプリ501を起動(S23)する。画面表示機能によれば、監視アプリ511は、ユーザアプリ501に発生した障害を検出(S24)すると、当該障害に係る情報を当該融合機101の画面にOCS166(図1参照)等を通じて表示(S25)する。
図24は、図5の監視アプリ511の内部保存機能について説明するためのシーケンス図である。
JSDKシステムでは、JSDK Main521がXlet Manager531を起動(S31)して、続いて、Xlet Manager531が監視アプリ511を起動(S32)して、続いて、Xlet Manager531がユーザアプリ501を起動(S33)する。内部保存機能によれば、監視アプリ511は、ユーザアプリ501に発生した障害を検出(S34)すると、当該障害に係る情報を当該融合機101の内部にMCS165(図1参照)等を通じて保存(S35)する。
図25は、図5の監視アプリ511の外部送信機能について説明するためのシーケンス図である。
JSDKシステムでは、JSDK Main521がXlet Manager531を起動(S41)して、続いて、Xlet Manager531が監視アプリ511を起動(S42)して、続いて、Xlet Manager531がユーザアプリ501を起動(S43)する。外部送信機能によれば、監視アプリ511は、ユーザアプリ501に発生した障害を検出(S44)すると、当該障害に係る情報を当該融合機101の外部にNCS161(図1参照)等を通じて送信(S45)する。
(エミュレータ)
図26は、本発明の実施例に該当するPC(パーソナルコンピュータ)701を表す。図26のPC701は、図1の融合機101とネットワーク801で接続されており、図1の融合機101のエミュレータとして機能する。
図26のPC701は、PC本体711と、キーボード712と、マウス713と、ディスプレイ714等により構成される。PC本体711には、CPU、ROM、RAM、NVRAM、HDD、MODEM、NIC等が存在する。キーボード712とマウス713は、融合機101のオペレーションパネル202に代わって、オペレータが入力を行うためのハードウェア(操作部)となる。ディスプレイ714は、融合機101のオペレーションパネル202に代わって、オペレータが出力を得るためのハードウェア(表示部)となる。
図27は、図26のPC701内のJSDKアプリ147とJSDKプラットフォーム148のクラス図である。図1の融合機101と同様のJSDKアプリ147とJSDKプラットフォーム148が、図26のPC701内にも存在するのである。図1の融合機101内のJSDKアプリ147とJSDKプラットフォーム148のクラス図については、図5を参照されたい。以下、図5と図27の差異について説明する。
第1に、図5のPanel Manager544は、図27のPanel Manager Emulator744に置換されている。第2に、図5のJSDK Session553は、図27のEmulator JSDK Session753に置換されている。第3に、図5のNative JSDK Session554は、図27のEvent Emulator754に置換されている。第4には、図5のCVM555は、図27のJVM755に置換されている。
Panel Manager Emulator744は、Panel Manager544をエミュレートして、オペレーションパネル202の操作をキーボード712やマウス713の操作に変換するクラスである。Emulator JSDK Session753は、通信経路の確立処理を実行するクラスである。Event Emulator754は、融合機101の動作をエミュレートするクラスである。JVM755は、JSDKアプリ147とJSDKプラットフォーム148を実行するためJava(登録商標)仮想マシンである。
なお、PC701内のJSDKシステムの起動手順は、図6と同様である。また、PC701内のJSDKシステムのGUIは、図7−12と同様である。当該GUIは、融合機101又はPC701内のユーザアプリ501を操作対象とする操作画面乃至タスクバーであり、PC701内のJSDK GUI Manager512乃至Task Bar Manager513により表示される。操作部はキーボード712とマウス713であり、表示部はディスプレイ714である。
図28は、図1の融合機101内で実行される遠隔操作の準備処理の実行手順について説明するための図である。
最初に、融合機101内のServer/Client Manager546とPC701内のServer/Client Manager546との間で、セッションが確立(S1)される。
次に、融合機101内のServer/Client Manager546は、遠隔操作に移行できるか否かを融合機101内のJSDK Manager533に問い合わせて、遠隔操作に移行できるか否かを判断(S2)する。
次に、融合機101内のServer/Client Manager546は、遠隔操作に移行できる場合には、遠隔操作に必要なメッセージに係る要求を、融合機101内のSend Manager541を介してPC701に送信(S3)して、遠隔操作に必要なメッセージに係る応答を、融合機101内のEvent Manager542を介してPC701から受信(S4)する。
次に、融合機101内のServer/Client Manager546は、遠隔操作用の情報をPC701に転送する旨の要求を、Panel Manager544に送信(S5)する。
最後に、融合機101内のServer/Client Manager546とPC701内のServer/Client Manager546との間で、遠隔操作準備処理が完了した旨の通知が授受(S6)される。これによって、PC701からの融合機101の遠隔操作が可能になる。
(変形例)
図1の融合機101は、本発明(画像形成装置)の実施例に該当するものであり、図1の融合機101内で実行される情報処理は、本発明(情報処理方法)の実施例に該当するものである。図5の監視アプリ511は、本発明(情報処理プログラム)の実施例に該当するものであり、図5の監視アプリ511が記録されたSDcardやCD−ROMは、本発明(記録媒体)の実施例に該当するものである。これらの利用態様としては、これら情報処理プログラムのダウンロードやこれら記録媒体のオプション販売等が考えられる。
図26のPC701は、本発明(端末装置)の実施例に該当するものであり、図26のPC701内で実行される情報処理は、本発明(情報処理方法)の実施例に該当するものである。図27の監視アプリ511は、本発明(情報処理プログラム)の実施例に該当するものであり、図27の監視アプリ511が記録されたSDcardやCD−ROMは、本発明(記録媒体)の実施例に該当するものである。これらの利用態様としては、これら情報処理プログラムのダウンロードやこれら記録媒体のオプション販売等が考えられる。