本発明は、コピー／プリンタ／スキャナ／ファクシミリ／複合機／融合機等の画像形成装置、パーソナルコンピュータ等の端末装置、情報処理方法、情報処理プログラム、ＳＤｃａｒｄ／ＣＤ−ＲＯＭ等の記録媒体に関する。

近年、コピーとプリンタとスキャナとファクシミリとしての機能を備える複合機や融合機が市販されるようになった。 複合機や融合機は、撮像部や印刷部や通信部や操作表示部等のハードウェアを備えると共に、コピーとプリンタとスキャナとファクシミリに対応する４種類のソフトウェアを備え、これらのソフトウェアが切り替わることにより、コピーやプリンタやスキャナやファクシミリとして機能する。 複合機や融合機は、コピーやプリンタとして機能する場合、画像を印刷用紙等に印刷することになり、コピーやスキャナやとして機能する場合、画像を読取原稿から読み取ることになり、ファクシミリとして機能する場合、画像を電話回線等を介して他の機器と授受することになる。

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

特開２００２−４１３７４号公報

特開２００２−８４３８３号公報

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

特開２００２−３３３９９６号公報

複合機や融合機内では、様々なアプリケーションが実行される。 複合機や融合機内でのアプリケーションの実行態様としては、１プロセス上で１アプリケーションが実行される「１プロセス１アプリ」が主流であるが、１プロセス上で複数のアプリケーションが実行される「１プロセス複数アプリ」も登場しつつある。 しかし、１プロセス１アプリを前提とするシステムで１プロセス複数アプリの情報処理を実行するような場合、１プロセス１アプリ向けのアプリケーション管理機構では１プロセス複数アプリの各アプリケーションを管理することができないので、１プロセス複数アプリ向けのアプリケーション管理機構が必要となる。 この例からも理解されるように、複合機や融合機には、アプリケーションの実行態様に応じたアプリケーション管理機構が必要である。

したがって、本発明は、新たなアプリケーション管理機構を備える画像形成装置を提案することを課題とする。

請求項１に記載の発明は、アプリケーションのライフサイクルを管理するプラットフォームを備える画像形成装置であって、前記プラットフォームによってライフサイクルを管理されるアプリケーションとして、前記プラットフォームによってライフサイクルを管理される他のアプリケーションの実行状態を監視する監視アプリケーションを備えることを特徴とする画像形成装置である。

請求項２に記載の発明は、前記監視アプリケーションは、アプリケーションに発生した障害を検出した場合、当該アプリケーションを続行する続行処理，当該アプリケーションを再起動する再起動処理，当該アプリケーションを終了する終了処理，又は当該アプリケーションがスレッドとして実行されるプロセスを終了するプロセス終了処理を実行することを特徴とする請求項１に記載の画像形成装置である。

請求項３に記載の発明は、前記監視アプリケーションは、アプリケーションに発生した障害を検出した場合、当該障害に係る情報を当該画像形成装置の画面に表示することを特徴とする請求項１乃至２のいずれか１項に記載の画像形成装置である。

請求項４に記載の発明は、前記監視アプリケーションは、アプリケーションに発生した障害を検出した場合、当該障害に係る情報を当該画像形成装置の内部に保存することを特徴とする請求項１乃至３のいずれか１項に記載の画像形成装置である。

請求項５に記載の発明は、前記監視アプリケーションは、アプリケーションに発生した障害を検出した場合、当該障害に係る情報を当該画像形成装置の外部に送信することを特徴とする請求項１乃至４のいずれか１項に記載の画像形成装置である。

請求項６に記載の発明は、前記アプリケーションのライフサイクルには、アプリケーションの初期化状態，活性化状態，停止状態，終了状態が存在することを特徴とする請求項１乃至５のいずれか１項に記載の画像形成装置である。

請求項７に記載の発明は、前記アプリケーションは、コンパイラによりソースコードからバイトコードに一括翻訳されており、仮想マシンにより逐次実行されることを特徴とする請求項１乃至６のいずれか１項に記載の画像形成装置である。

請求項８に記載の発明は、前記アプリケーションは、それぞれスレッドとして実行されることを特徴とする請求項１乃至７のいずれか１項に記載の画像形成装置である。

請求項９に記載の発明は、前記アプリケーションは、Ｘｌｅｔであることを特徴とする請求項１乃至８のいずれか１項に記載の画像形成装置である。

請求項１０に記載の発明は、前記プラットフォームは、１対１で前記アプリケーションのライフサイクルを管理する個別管理手段と、複数の前記個別管理手段のライフサイクルを管理する一括管理手段と、前記一括管理手段のライフサイクルを管理するライフサイクル管理手段とを備えることを特徴とする請求項１乃至９のいずれか１項に記載の画像形成装置である。

請求項１１に記載の発明は、前記アプリケーションと前記プラットフォームは、同一のプロセス上で実行されることを特徴とする請求項１乃至１０のいずれか１項に記載の画像形成装置である。

請求項１２に記載の発明は、アプリケーションのライフサイクルを管理するプラットフォームを備える画像形成装置内で実行される情報処理方法であって、前記プラットフォームによってライフサイクルを管理されるアプリケーションが、前記プラットフォームによってライフサイクルを管理される他のアプリケーションの実行状態を監視する監視ステップを備えることを特徴とする情報処理方法である。

請求項１３に記載の発明は、アプリケーションのライフサイクルを管理するプラットフォームを備える画像形成装置内で実行するための情報処理プログラムであって、前記プラットフォームによってライフサイクルを管理されるアプリケーションであり、且つ、前記プラットフォームによってライフサイクルを管理される他のアプリケーションの実行状態を監視する監視アプリケーションであることを特徴とする情報処理プログラムである。

請求項１４に記載の発明は、請求項１３に記載の情報処理プログラムが記録された記録媒体である。

請求項１５に記載の発明は、画像形成装置のエミュレータとして機能する端末装置であって、当該端末装置のプラットフォームによりライフサイクルを管理されるアプリケーションとして、当該端末装置または当該画像形成装置のプラットフォームによりライフサイクルを管理される他のアプリケーションの実行状態を監視する監視アプリケーションを備えることを特徴とする端末装置である。

請求項１６に記載の発明は、画像形成装置のエミュレータとして機能する端末装置内で実行される情報処理方法であって、当該端末装置のプラットフォームによりライフサイクルを管理されるアプリケーションが、当該端末装置または当該画像形成装置のプラットフォームによりライフサイクルを管理される他のアプリケーションの実行状態を監視する監視ステップを備えることを特徴とする情報処理方法である。

請求項１７に記載の発明は、画像形成装置のエミュレータとして機能する端末装置内で実行するための情報処理プログラムであって、当該端末装置のプラットフォームによりライフサイクルを管理されるアプリケーションであり、且つ、当該端末装置または当該画像形成装置のプラットフォームによりライフサイクルを管理される他のアプリケーションの実行状態を監視する監視アプリケーションであることを特徴とする情報処理プログラムである。

請求項１８に記載の発明は、請求項１７に記載の情報処理プログラムが記録された記録媒体である。

請求項１記載の発明は、アプリケーション管理機構として、アプリケーションのライフサイクルを管理する「プラットフォーム」と、このプラットフォームによってライフサイクルを管理されるアプリケーションの実行状態を監視する「監視アプリケーション」とを備える。 アプリケーションのライフサイクルを「プラットフォーム」が管理し、このプラットフォームによってライフサイクルを管理されるアプリケーションの実行状態を「監視アプリケーション」が監視するのである。 そのため、アプリケーションの実装等が容易になる。 監視アプリケーションも、プラットフォームによってライフサイクルを管理されるアプリケーションである。 そのため、監視アプリケーションの実装，入れ替え等も容易である。

請求項１５記載の発明は、アプリケーション管理機構として、端末装置または画像形成装置のプラットフォームによりライフサイクルを管理されるアプリケーションの実行状態を監視する「監視アプリケーション」を備える。 端末装置または画像形成装置のプラットフォームによりライフサイクルを管理されるアプリケーションの実行状態を「監視アプリケーション」が監視するのである。 そのため、アプリケーションの実装等が容易になる。 監視アプリケーションもまた、端末装置のプラットフォームによりライフサイクルを管理されるアプリケーションである。 そのため、監視アプリケーションの実装，入れ替え等も容易である。

このように、本発明は、新たなアプリケーション管理機構を備える画像形成装置を提案するものである。

図１は、本発明の実施例に該当する融合機１０１を表す。 図１の融合機１０１は、種々のハードウェア１１１と、種々のソフトウェア１１２と、融合機起動部１１３により構成される。

融合機１０１のハードウェア１１１としては、撮像部１２１と、印刷部１２２と、その他のハードウェア１２３が存在する。 撮像部１２１は、読取原稿から画像（画像データ）を読み取るためのハードウェアである。 印刷部１２２は、画像（画像データ）を印刷用紙に印刷するためのハードウェアである。

融合機１０１のソフトウェア１１２としては、種々のアプリケーション１３１と、種々のプラットフォーム１３２が存在する。 これらのプログラムは、ＵＮＩＸ（登録商標）等のＯＳ（オペレーティングシステム）によりプロセス単位で並列的に実行される。

アプリケーション１３１としては、コピー用のアプリケーションであるコピーアプリ１４１、プリンタ用のアプリケーションであるプリンタアプリ１４２、スキャナ用のアプリケーションであるスキャナアプリ１４３、ファクシミリ用のアプリケーションであるファクシミリアプリ１４４、ネットワークファイル用のアプリケーションであるネットワークファイルアプリ１４５が存在する。

アプリケーション１３１は、専用のＳＤＫ（ソフトウェア開発キット）を使用して開発することができる。 ＳＤＫを使用して開発したアプリケーション１３１をＳＤＫアプリと呼ぶ。 専用のＳＤＫとしては、Ｃ言語でアプリケーション１３１を開発するための「ＣＳＤＫ」や、Ｊａｖａ（登録商標）言語でアプリケーション１３１を開発するための「ＪＳＤＫ」が提供される。 ＣＳＤＫを使用して開発したアプリケーション１３１を「ＣＳＤＫアプリ」と呼び、ＪＳＤＫを使用して開発したアプリケーション１３１を「ＪＳＤＫアプリ」と呼ぶ。 図１の融合機１０１にも、ＣＳＤＫアプリ１４６と、ＪＳＤＫアプリ１４７が存在する。 図１の融合機１０１にはさらに、Ｊａｖａ（登録商標）言語で記述されたＪＳＤＫアプリ１４７とＣ言語で記述された他のソフトウェア１１２との仲介を行うソフトウェア１１２として、ＪＳＤＫプラットフォーム１４８が存在する。

プラットフォーム１３２としては、種々のコントロールサービス１５１、システムリソースマネージャ１５２、種々のハンドラ１５３が存在する。 コントロールサービス１５１としては、ネットワークコントロールサービス（ＮＣＳ）１６１、ファクシミリコントロールサービス（ＦＣＳ）１６２、デリバリコントロールサービス（ＤＣＳ）１６３、エンジンコントロールサービス（ＥＣＳ）１６４、メモリコントロールサービス（ＭＣＳ）１６５、オペレーションパネルコントロールサービス（ＯＣＳ）１６６、サーティフィケーションコントロールサービス（ＣＣＳ）１６７、ユーザディレクトリコントロールサービス（ＵＣＳ）１６８、システムコントロールサービス（ＳＣＳ）１６９が存在する。 ハンドラ１５３としては、ファクシミリコントロールユニットハンドラ（ＦＣＵＨ）１７１、イメージメモリハンドラ（ＩＭＨ）１７２が存在する。

ＮＣＳ１６１のプロセスは、ネットワーク通信の仲介を行う。 ＦＣＳ１６２のプロセスは、ファクシミリのＡＰＩを提供する。 ＤＣＳ１６３のプロセスは、蓄積文書の配信処理に関する制御を行う。 ＥＣＳ１６４のプロセスは、撮像部１２１や印刷部１２２に関する制御を行う。 ＭＣＳ１６５のプロセスは、メモリやハードディスクドライブに関する制御を行う。 ＯＣＳ１６６のプロセスは、オペレーションパネルに関する制御を行う。 ＣＣＳ１６７のプロセスは、認証処理や課金処理に関する制御を行う。 ＵＣＳ１６８のプロセスは、ユーザ情報の管理に関する制御を行う。 ＳＣＳ１６９のプロセスは、システムの管理に関する制御を行う。

アプリケーション１３１とプラットフォーム１３２の仲介を行うソフトウェア１１２として、仮想アプリケーションサービス（ＶＡＳ）１３５が存在する。 ＶＡＳ１３５は、アプリケーション１３１をクライアントとするサーバプロセスとして動作すると共に、プラットフォーム１３２をサーバとするクライアントプロセスとして動作する。 ＶＡＳ１３５は、アプリケーション１３１から見てプラットフォーム１３２を隠蔽するラッピング機能を備え、プラットフォーム１３２のバージョンアップに伴うバージョン差を吸収する役割等を担う。

融合機起動部１１３は、融合機１０１の電源投入時に最初に実行される。 これにより、ＵＮＩＸ（登録商標）等のＯＳが起動され、アプリケーション１３１やプラットフォーム１３２が起動される。 これらのプログラムは、ハードディスクドライブやメモリカードに蓄積されており、ハードディスクドライブやメモリカードから再生されて、メモリに起動されることになる。

図２は、図１の融合機１０１に係るハードウェア構成図である。 融合機１０１のハードウェア１１１としては、コントローラ２０１と、オペレーションパネル２０２と、ファクシミリコントロールユニット（ＦＣＵ）２０３と、撮像部１２１と、印刷部１２２が存在する。

コントローラ２０１は、ＣＰＵ２１１、ＡＳＩＣ２１２、ＮＢ２２１、ＳＢ２２２、ＭＥＭ−Ｐ２３１、ＭＥＭ−Ｃ２３２、ＨＤＤ（ハードディスクドライブ）２３３、メモリカードスロット２３４、ＮＩＣ（ネットワークインタフェースコントローラ）２４１、ＵＳＢデバイス２４２、ＩＥＥＥ１３９４デバイス２４３、セントロニクスデバイス２４４により構成される。

ＣＰＵ２１１は、種々の情報処理用のＩＣである。 ＡＳＩＣ２１２は、種々の画像処理用のＩＣである。 ＮＢ２２１は、コントローラ２０１のノースブリッジである。 ＳＢ２２２は、コントローラ２０１のサウスブリッジである。 ＭＥＭ−Ｐ２３１は、融合機１０１のシステムメモリである。 ＭＥＭ−Ｃ２３２は、融合機１０１のローカルメモリである。 ＨＤＤ２３３は、融合機１０１のストレージである。 メモリカードスロット２３４は、メモリカード２３５をセットするためのスロットである。 ＮＩＣ２４１は、ＭＡＣアドレスによるネットワーク通信用のコントローラである。 ＵＳＢデバイス２４２は、ＵＳＢ規格の接続端子を提供するためのデバイスである。 ＩＥＥＥ１３９４デバイス２４３は、ＩＥＥＥ１３９４規格の接続端子を提供するためのデバイスである。 セントロニクスデバイス２４４は、セントロニクス仕様の接続端子を提供するためのデバイスである。

オペレーションパネル２０２は、オペレータが融合機１０１に入力を行うためのハードウェア（操作部）であると共に、オペレータが融合機１０１から出力を得るためのハードウェア（表示部）である。

図３は、図１の融合機１０１に係る外観図である。 図３には、撮像部１２１の位置と、印刷部１２２の位置と、オペレーションパネル２０２の位置が図示されている。 図３には更に、読取原稿のセット先となる原稿セット部３０１と、印刷用紙の給紙先となる給紙部３０２と、印刷用紙の排紙先となる排紙部３０３が図示されている。

オペレーションパネル２０２は、図４のように、タッチパネル３１１と、テンキー３１２と、スタートボタン３１３と、リセットボタン３１４と、機能キー３１５と、初期設定ボタン３１６により構成される。 タッチパネル３１１は、タッチ操作で入力を行うためのハードウェア（タッチ操作部）であると共に、画面表示で出力を得るためのハードウェア（画面表示部）である。 テンキー３１２は、キー（ボタン）操作で数字入力を行うためのハードウェアである。 スタートボタン３１３は、ボタン操作でスタート操作を行うためのハードウェアである。 リセットボタン３１４は、ボタン操作でリセット操作を行うためのハードウェアである。 機能キー３１５は、キー（ボタン）操作でＣＳＤＫアプリ１４６やＪＳＤＫアプリ１４７による操作画面を表示させるためのハードウェアである。 初期設定ボタン３１６は、ボタン操作で初期設定画面を表示させるためのハードウェアである。

原稿セット部３０１は、ＡＤＦ（自動原稿搬送装置）３２１と、フラットベッド３２２と、フラットベッドカバー３２３により構成される。 給紙部３０２は、４個の給紙トレイにより構成される。 排紙部３０３は、１個の排紙トレイにより構成される。

（ＪＳＤＫ）
図５は、図１のＪＳＤＫアプリ１４７とＪＳＤＫプラットフォーム１４８のクラス図である。 ＪＳＤＫアプリ１４７とＪＳＤＫプラットフォーム１４８は、全体で１プロセスとして、同一プロセス上で実行される。 ＪＳＤＫアプリ１４７とＪＳＤＫプラットフォーム１４８中の各ブロックは、それぞれこの１プロセス上のスレッドとして、スレッド単位で並列的に実行（マルチスレッド）される。 ＪＳＤＫアプリ１４７とＪＳＤＫプラットフォーム１４８は、Ｊａｖａ（登録商標）コンパイラによりソースコードからバイトコードに一括翻訳されており、Ｊａｖａ（登録商標）仮想マシンにより逐次実行される。 ＪＳＤＫアプリ１４７とＪＳＤＫプラットフォーム１４８は、Ｊａｖａ（登録商標） ２ Ｍｉｃｒｏ ＥｄｉｔｉｏｎのＰｅｒｓｏｎａｌ Ｂａｓｉｓ Ｐｒｏｆｉｌｅをベースとする実装となっている。

ＪＳＤＫアプリ１４７としては、ユーザアプリ５０１に加えて、監視アプリ５１１と、ＪＳＤＫ ＧＵＩ Ｍａｎａｇｅｒ５１２と、Ｔａｓｋ Ｂａｒ Ｍａｎａｇｅｒ５１３等が存在する。

ユーザアプリ５０１は、融合機１０１のユーザ（例えばベンダ）がＪＳＤＫを使用して開発したＪＳＤＫアプリである。 監視アプリ５１１は、他のＪＳＤＫアプリ（ユーザアプリ５０１等）の実行状態の監視等を行うＪＳＤＫアプリである。 ＪＳＤＫ ＧＵＩ Ｍａｎａｇｅｒ５１２は、他のＪＳＤＫアプリ（ユーザアプリ５０１等）を操作対象とする操作画面の表示等を行うＪＳＤＫアプリである。 Ｔａｓｋ Ｂａｒ Ｍａｎａｇｅｒ５１３は、他のＪＳＤＫアプリ（ユーザアプリ５０１等）を操作対象とするタスクバーの表示等を行うＪＳＤＫアプリである。

ユーザアプリ５０１はここでは、スタンドアロンアプリケーションやアプレットと並ぶＪａｖａ（登録商標）アプリケーションであるＸｌｅｔである。 監視アプリ５１１とＪＳＤＫ ＧＵＩ Ｍａｎａｇｅｒ５１２とＴａｓｋ Ｂａｒ Ｍａｎａｇｅｒ５１３はここでは、独自の拡張を施したＸｌｅｔ（ＸｌｅｔＥｘ）である。

ＪＳＤＫプラットフォーム１４８には、ＪＳＤＫ Ｍａｉｎ５２１と、ＪＳＤＫ Ｅｎｖｉｒｏｎｍｅｎｔ５２２と、Ｌｏｃａｌｅ Ｍａｎａｇｅｒ５２３と、Ｘｌｅｔ Ｍａｎａｇｅｒ５３１と、Ｍｕｌｔｉ Ｘｌｅｔ Ｍａｎａｇｅｒ５３２と、ＪＳＤＫ Ｍａｎａｇｅｒ５３３と、Ｓｅｎｄ Ｍａｎａｇｅｒ５４１と、Ｅｖｅｎｔ Ｍａｎａｇｅｒ５４２と、Ｓｙｓｔｅｍ Ｅｖｅｎｔ Ｍａｎａｇｅｒ５４３と、Ｐａｎｅｌ Ｍａｎａｇｅｒ５４４と、Ｉｎｓｔａｌｌ Ｍａｎａｇｅｒ５４５と、Ｓｅｒｖｅｒ／Ｃｌｉｅｎｔ Ｍａｎａｇｅｒ５４６等のクラスが存在する。

ＪＳＤＫ Ｍａｉｎ５２１は、ＪＳＤＫシステムの起動設定を行うクラスである。 ＪＳＤＫ Ｅｎｖｉｒｏｎｍｅｎｔ５２２は、ＪＳＤＫシステムの起動環境設定を行うクラスである。 Ｌｏｃａｌｅ Ｍａｎａｇｅｒ５２３は、国際化対応（言語指定）を行うクラスである。

Ｘｌｅｔ Ｍａｎａｇｅｒ５３１は、１対１でＸｌｅｔのライフサイクルを管理するクラスである。 ここでは、６個のＸｌｅｔのライフサイクルが１対１で６個のＸｌｅｔ Ｍａｎａｇｅｒ５３１によって管理される。 Ｍｕｌｔｉ Ｘｌｅｔ Ｍａｎａｇｅｒ５３２は、全てのＸｌｅｔ Ｍａｎａｇｅｒ５３１のライフサイクルを管理するクラスである。 ここでは、６個のＸｌｅｔ Ｍａｎａｇｅｒ５３１のライフサイクルが全て１個のＭｕｌｔｉ Ｘｌｅｔ Ｍａｎａｇｅｒ５３２によって管理される。 ＪＳＤＫ Ｍａｎａｇｅｒ５３３は、ＪＳＤＫシステム全体のライフサイクルを管理するクラスである。 例えば、Ｍｕｌｔｉ Ｘｌｅｔ Ｍａｎａｇｅｒ５３２，Ｓｅｎｄ Ｍａｎａｇｅｒ５４１，Ｅｖｅｎｔ Ｍａｎａｇｅｒ５４２，Ｓｙｓｔｅｍ Ｅｖｅｎｔ Ｍａｎａｇｅｒ５４３，Ｐａｎｅｌ Ｍａｎａｇｅｒ５４４，Ｉｎｓｔａｌｌ Ｍａｎａｇｅｒ５４５，Ｓｅｒｖｅｒ／Ｃｌｉｅｎｔ Ｍａｎａｇｅｒ５４６のライフサイクルが、ＪＳＤＫ Ｍａｎａｇｅｒ５３３によって管理される。

Ｓｙｓｔｅｍ Ｅｖｅｎｔ Ｍａｎａｇｅｒ５４３は、図１のプラットフォーム１３２からのシステムイベント（電力モード等）の管理を行うクラスである。 Ｐａｎｅｌ Ｍａｎａｇｅｒ５４４は、１個のＸｌｅｔがオペレーションパネル２０２の画面を占有する際の調停等を行うクラスである。 Ｉｎｓｔａｌｌ Ｍａｎａｇｅｒ５４５は、ＳＤｃａｒｄやＷｅｂからのインストールやアンインストールの管理を行うクラスである。

図５のＪＳＤＫシステムでは、ＡＰＩとして、ＪＳＤＫ ＡＰＩ５５１とＪＳＤＫ ＡＰＩ５５２が利用される。 なお、ＸｌｅｔとＸｌｅｔＥｘの差異として、オブジェクトにアクセスするのにＪＳＤＫ ＡＰＩ５５１の利用とＪＳＤＫプラットフォーム１４８へのアクセスが可能である点が挙げられる。 図１の融合機１０１にはさらに、図５のＪＳＤＫシステムに係る要素として、Ｃ言語とＪａｖａ（登録商標）言語のインタフェースとなるＪＳＤＫ Ｓｅｓｓｉｏｎ５５３とＮａｔｉｖｅ ＪＳＤＫ Ｓｅｓｓｉｏｎ５５４や、ＪＳＤＫアプリ１４７とＪＳＤＫプラットフォーム１４８を実行するためＪａｖａ（登録商標）仮想マシンであるＣＶＭ５５５等が存在する。

図６は、ＪＳＤＫシステムの起動手順について説明するための図である。 ＪＳＤＫシステムではまず、ＪＳＤＫアプリ１４７を起動するｍａｉｎ（）関数を有するクラスであるＪＳＤＫ Ｍａｉｎ５２１が、ＪＳＤＫ Ｅｎｖｉｒｏｎｍｅｎｔ５２２を生成（Ｓ１）する。 続いて、ＪＳＤＫ Ｅｎｖｉｒｏｎｍｅｎｔ５２２が、Ｎａｔｉｖｅ層の構築（Ｓ２）と言語環境の構築（Ｓ３）をもって、ＪＳＤＫシステムの実行環境の構築を行う。 続いて、ＪＳＤＫ Ｅｎｖｉｒｏｎｍｅｎｔ５２２が、ＪＳＤＫ Ｍａｎａｇｅｒ５３３を生成（Ｓ４）する。 ＪＳＤＫシステムではそして、ＪＳＤＫ Ｍａｎａｇｅｒ５３３が、システム層のＭａｎａｇｅｒを生成（Ｓ５−１２）し、Ｍｕｌｔｉ Ｘｌｅｔ Ｍａｎａｇｅｒ５３２とＸｌｅｔ Ｍａｎａｇｅｒ５３１を通じて、アプリ層のＭａｎａｇｅｒを生成（Ｓ１３−１５）する。

図７は、ＪＳＤＫシステムのＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）について説明するための図である。 融合機１０１の機能キー３１５（図４参照）を押すと、図６のＳ１−１５が実行されて、図７のＧＵＩが融合機１０１のタッチパネル３１１（図４参照）に表示される。 図７のＧＵＩは、ユーザアプリ５０１を操作対象とする操作画面であり、図６のＳ１４で起動されたＪＳＤＫ ＧＵＩ Ｍａｎａｇｅｒ５１２によって表示される。

図７Ａは、画面を占有させるユーザアプリ５０１の切替操作を行うための切替操作画面である。 図７Ｂは、ユーザアプリ５０１の起動操作を行うための起動操作画面である。 図７Ｃは、ユーザアプリ５０１の終了操作を行うための終了操作画面である。 図７Ｄは、ユーザアプリ５０１のインストール操作を行うためのインストール操作画面である。 図７Ｅは、ユーザアプリ５０１のアンインストール操作を行うためのアンインストール操作画面である。 図７Ａが、機能キー３１５を押した直後にタッチパネル３１１に表示される初期画面であり、図７Ａ，Ｂ，Ｃ，Ｄ，Ｅはそれぞれ切り替え，起動，終了，インストール，アンインストールのボタンをタッチすると表示されることになる。

ＳｉｍｐｌｅＰｒｉｎｔ，ＳｉｍｐｌｅＣｏｐｙ，ＳｉｍｐｌｅＯｃｒ，ＳｉｍｐｌｅＳｃａｎ等はそれぞれユーザアプリ５０１である。 例えば、ＳｉｍｐｌｅＰｒｉｎｔは、電子文書のファイル名を入力することで当該電子文書のプリントを実行できるようにするためのアプリケーションである。 なお、アプリケーションのタイプとは、ＧＵＩを有するアプリケーションであるか否かを意味する。

図７Ａの切替操作画面について説明する。 図７Ａの切替操作画面には、切替操作対象としてインストール済みで実行中のユーザアプリ５０１の一覧が表示される。

図７Ａの切替操作画面で「ＳｉｍｐｌｅＰｒｉｎｔ」にタッチすると、ＳｉｍｐｌｅＰｒｉｎｔにオペレーションパネル２０２のオーナー権が付与されることになり、ＳｉｍｐｌｅＰｒｉｎｔが画面を占有することになる。 これに伴って、図７Ａの画面から図８Ａの画面に画面が移る。 図８Ａは、画面を占有するＳｉｍｐｌｅＰｒｉｎｔにより表示されるＧＵＩである。

図７Ａの切替操作画面で「ＳｉｍｐｌｅＣｏｐｙ」にタッチすると、ＳｉｍｐｌｅＣｏｐｙにオペレーションパネル２０２のオーナー権が付与されることになり、ＳｉｍｐｌｅＣｏｐｙが画面を占有することになる。 これに伴って、図７Ａの画面から図８Ｂの画面に画面が移る。 図７Ａに示すように、ＳｉｍｐｌｅＣｏｐｙの状態は「異常」なので、図８Ｂのように、画面上にはＳｉｍｐｌｅＣｏｐｙに係るエラーメッセージが表示される。

図７Ａの切替操作画面で「ＳｉｍｐｌｅＯｃｒ」にタッチすると、ＳｉｍｐｌｅＯｃｒにオペレーションパネル２０２のオーナー権が付与されることになり、ＳｉｍｐｌｅＯｃｒが画面を占有することになる。 これに伴って、図７Ａの画面から図８Ｃの画面に画面が移る。 図７Ａに示すように、ＳｉｍｐｌｅＯｃｒのタイプは「ＧＵＩ無」なので、図８Ｃのように、画面上にはＳｉｍｐｌｅＯｃｒの状態が表示される。

図８Ａ，Ｂ，Ｃの画面の左端（楕円形で示す領域内）には、図６のＳ１５で起動されたＴａｓｋ Ｂａｒ Ｍａｎａｇｅｒ５１３により、ユーザアプリ５０１を操作対象とするタスクバーが表示される。 これらのタスクバーは、画面を占有させるユーザアプリ５０１の切替操作を行うための切替タスクバーである。

図８Ａの画面で切替タスクバー中の「ＳＣ」や「ＳＯ」にタッチすると、ＳｉｍｐｌｅＣｏｐｙやＳｉｍｐｌｅＯｃｒにオペレーションパネル２０２のオーナー権が付与されることになり、ＳｉｍｐｌｅＣｏｐｙやＳｉｍｐｌｅＯｃｒが画面を占有することになる。 これに伴い、図８Ａの画面から図８Ｂや図８Ｃの画面に画面が移る。 図８Ａの画面で切替タスクバー中の「ＪＳＤＫ」にタッチすると、図７Ａの画面に画面が戻る。

図８Ｂの画面で切替タスクバー中の「ＳＰ」や「ＳＯ」にタッチすると、ＳｉｍｐｌｅＰｒｉｎｔやＳｉｍｐｌｅＯｃｒにオペレーションパネル２０２のオーナー権が付与されることになり、ＳｉｍｐｌｅＰｒｉｎｔやＳｉｍｐｌｅＯｃｒが画面を占有することになる。 これに伴い、図８Ｂの画面から図８Ａや図８Ｃの画面に画面が移る。 図８Ｂの画面で切替タスクバー中の「ＪＳＤＫ」にタッチすると、図７Ａの画面に画面が戻る。

図８Ｃの画面で切替タスクバー中の「ＳＰ」や「ＳＣ」にタッチすると、ＳｉｍｐｌｅＰｒｉｎｔやＳｉｍｐｌｅＣｏｐｙにオペレーションパネル２０２のオーナー権が付与されることになり、ＳｉｍｐｌｅＰｒｉｎｔやＳｉｍｐｌｅＣｏｐｙが画面を占有することになる。 これに伴い、図８Ｃの画面から図８Ａや図８Ｂの画面に画面が移る。 図８Ｃの画面で切替タスクバー中の「ＪＳＤＫ」にタッチすると、図７Ａの画面に画面が戻る。

図７Ｂの起動操作画面について説明する。 図７Ｂの起動操作画面には、起動操作対象としてインストール済みで実行されていないユーザアプリ５０１の一覧が表示される。

図７Ｂの起動操作画面で「ＳｉｍｐｌｅＰｒｉｎｔ」にタッチすると、ＳｉｍｐｌｅＰｒｉｎｔの起動処理を実行するか否かを確認する確認画面（図９）が表示される。 図９の確認画面でプロダクトコードを入力し「実行」にタッチすると、ＳｉｍｐｌｅＰｒｉｎｔが起動されることになる。

図７Ｃの終了操作画面について説明する。 図７Ｃの終了操作画面には、終了操作対象としてインストール済みで実行中のユーザアプリ５０１の一覧が表示される。

図７Ｃの終了操作画面で「ＳｉｍｐｌｅＰｒｉｎｔ」にタッチすると、ＳｉｍｐｌｅＰｒｉｎｔの強制終了処理を実行するか否かを確認する確認画面（図１０）が表示される。 図１０の確認画面で「実行」にタッチすると、ＳｉｍｐｌｅＰｒｉｎｔが強制終了されることになる。

図７Ｄのインストール操作画面について説明する。 ユーザアプリ５０１のインストール処理により、起動可能ユーザアプリとして未登録のユーザアプリ５０１が起動可能ユーザアプリとして登録されることになる。 図７Ｄのインストール操作画面には、インストール操作対象としてユーザアプリ５０１の一覧がインストール状況と共に表示される。

図７Ｄのインストール操作画面で「ＳｉｍｐｌｅＰｒｉｎｔ」にタッチすると、ＳＤｃａｒｄを格納元とするＳｉｍｐｌｅＰｒｉｎｔのインストール先を確認する確認画面（図１１）が表示される。 図１１の確認画面で「ＳＤｃａｒｄ」にタッチすると、ＳｉｍｐｌｅＰｒｉｎｔがＳＤｃａｒｄをインストール先としてインストールされることになり、図１１の確認画面で「ＨＤＤ」にタッチすると、ＳｉｍｐｌｅＰｒｉｎｔがＨＤＤをインストール先としてインストールされることになる。

図７Ｅのアンインストール操作画面について説明する。 ユーザアプリ５０１のアンインストール処理により、起動可能ユーザアプリとして登録済みのユーザアプリ５０１が起動可能ユーザアプリとしての登録を抹消されることになる。 図７Ｅのアンインストール操作画面には、アンインストール操作対象として登録済みのユーザアプリ５０１の一覧が表示される。

図７Ｅのアンインストール操作画面で「ＳｉｍｐｌｅＰｒｉｎｔ」にタッチすると、ＳｉｍｐｌｅＰｒｉｎｔのアンインストール処理を実行するか否かを確認する確認画面（図１２）が表示される。 図１２の確認画面で「実行」にタッチすると、ＳｉｍｐｌｅＰｒｉｎｔがアンインストールされることになる。

図１３は、起動操作画面の表示手順について説明するための図である。 切替操作画面で起動のボタンがタッチされると、ＪＳＤＫ ＧＵＩ Ｍａｎａｇｅｒ５１２からＩｎｓｔａｌｌ Ｍａｎａｇｅｒ５４５に、インストール済みのユーザアプリ５０１の一覧要求が送信（Ｓ１）される。 これに応じて、Ｉｎｓｔａｌｌ Ｍａｎａｇｅｒ５４５は、インストール済みのユーザアプリ５０１の格納位置に係る情報（融合機１０１内のＮＶＲＡＭに格納されている）を元に、インストール済みのユーザアプリ５０１のＪＮＬＰファイルを取得（Ｓ２）する。 融合機１０１にセットされたＳＤｃａｒｄからは、当該ＳＤｃａｒｄ内のユーザアプリ５０１のＪＮＬＰファイルが取得される。 融合機１０１内のＨＤＤからは、当該ＨＤＤ内のユーザアプリ５０１のＪＮＬＰファイルが取得される。 ＪＮＬＰファイルは、ユーザアプリ５０１と１対１で対応しており、ユーザアプリ５０１の定義付けに係る情報を含んでいる。 そして、インストール済みのユーザアプリ５０１のＪＮＬＰファイルの内容を元に、Ｉｎｓｔａｌｌ Ｍａｎａｇｅｒ５４５からＪＳＤＫ ＧＵＩ Ｍａｎａｇｅｒ５１２に、インストール済みのユーザアプリ５０１の一覧応答が送信（Ｓ３）される。 これにより、切替操作画面から起動操作画面に画面が移ることになる。

図１４は、起動処理の実行手順について説明するための図である。 起動操作画面で選択操作が実行されて確認画面で確認操作が実行されると、ＪＳＤＫ ＧＵＩ Ｍａｎａｇｅｒ５１２からＪＳＤＫ Ｍａｎａｇｅｒ５３３に、ユーザアプリ５０１の起動要求が送信（Ｓ１）される。 これに応じて、ＪＳＤＫ Ｍａｎａｇｅｒ５３３からＭｕｌｔｉ Ｘｌｅｔ Ｍａｎａｇｅｒ５３２に、Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｍａｎａｇｅｒ５４７による認証処理を経由してから、ユーザアプリ５０１の起動要求が送信（Ｓ２）される。 これに応じて、Ｍｕｌｔｉ Ｘｌｅｔ Ｍａｎａｇｅｒ５３２がＸｌｅｔ Ｍａｎａｇｅｒ５３１を起動（Ｓ３）し、Ｘｌｅｔ Ｍａｎａｇｅｒ５３１がＰａｎｅｌ Ｍａｎａｇｅｒ５４４からルートウィンドウを取得（Ｓ４）し、Ｘｌｅｔ Ｍａｎａｇｅｒ５３１がユーザアプリ５０１を起動（Ｓ５）する。 そして、Ｍｕｌｔｉ Ｘｌｅｔ Ｍａｎａｇｅｒ５３２からＪＳＤＫ Ｍａｎａｇｅｒ５３３に、ユーザアプリ５３３の起動応答が送信（Ｓ６）される。 そして、ＪＳＤＫ Ｍａｎａｇｅｒ５３３からＪＳＤＫ ＧＵＩ Ｍａｎａｇｅｒ５１２に、ユーザアプリ５３３の起動応答が送信（Ｓ７）される。

図１５は、インストール操作画面の表示手順について説明するための図である。 切替操作画面上でインストールのボタンがタッチされると、ＪＳＤＫ ＧＵＩ Ｍａｎａｇｅｒ５１２からＩｎｓｔａｌｌ Ｍａｎａｇｅｒ５４５に、ユーザアプリ５０１の一覧要求が送信（Ｓ１）される。 これに応じて、Ｉｎｓｔａｌｌ Ｍａｎａｇｅｒ５４５は、ユーザアプリ５０１のＪＮＬＰファイルを取得（Ｓ２）する。 融合機１０１にセットされたＳＤｃａｒｄからは、当該ＳＤｃａｒｄ内のユーザアプリ５０１のＪＮＬＰファイルが取得される。 融合機１０１とネットワークで接続されたＷｅｂサーバからは、当該Ｗｅｂサーバ内のユーザアプリ５０１のＪＮＬＰファイルが取得される。 ＪＮＬＰファイルは、ユーザアプリ５０１と１対１で対応しており、ユーザアプリ５０１の定義付けに係る情報を含んでいる。 そして、ユーザアプリ５０１のインストール状況に関する情報（融合機１０１内のＮＶＲＡＭに格納されている）や、ユーザアプリ５０１のＪＮＬＰファイルの内容を元にして、Ｉｎｓｔａｌｌ Ｍａｎａｇｅｒ５４５からＪＳＤＫ ＧＵＩ Ｍａｎａｇｅｒ５１２に、ユーザアプリ５０１の一覧応答が送信（Ｓ３）される。 これにより、切替操作画面からインストール操作画面に画面が移ることになる。

図１６は、インストール処理の実行手順について説明するための図である。 インストール操作画面で選択操作が実行されて確認画面で確認操作が実行されると、ＪＳＤＫ ＧＵＩ Ｍａｎａｇｅｒ５１２からＩｎｓｔａｌｌ Ｍａｎａｇｅｒ５４５に、ユーザアプリ５０１のインストール要求が送信（Ｓ１）される。 これに応じて、Ｉｎｓｔａｌｌ Ｍａｎａｇｅｒ５４５は、Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｍａｎａｇｅｒ５４７による認証処理を経由してから、ユーザアプリ５０１をインストール（Ｓ２）する。 そして、Ｉｎｓｔａｌｌ Ｍａｎａｇｅｒ５４５からＪＳＤＫ ＧＵＩ Ｍａｎａｇｅｒ５１２に、ユーザアプリ５３３のインストール応答が送信（Ｓ３）される。

図１７は、ＪＮＬＰファイルの構文の例を表す。 ＪＮＬＰ（Ｊａｖａ（登録商標） Ｎｅｔｗｏｒｋ Ｌａｕｎｃｈｉｎｇ Ｐｒｏｔｏｃｏｌ）ファイルはＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）ファイルであり、ＪＮＬＰファイル書式はＪＮＬＰ規格に準拠している。 ただし、ＪＳＤＫ向けに独自の拡張を施している部分があるため、以下その部分について説明する。

記述１は、ｉｎｆｏｒｍａｔｉｏｎエレメントであり、アプリケーション名を示すｔｉｔｌｅエレメント（記述１Ａ）や、ベンダ名を示すｖｅｎｄｅｒエレメント（記述１Ｂ）や、ベンダの電話番号を示すｔｅｌｅｐｈｏｎｅエレメント（記述１Ｃ）や、ベンダのファクス電話番号を示すｆａｘエレメント（記述１Ｄ）や、アプリケーションのプロダクトＩＤを示すｐｒｏｄｕｃｔＩＤエレメント（記述１Ｅ）を含んでいる。

記述２は、ｓｅｃｕｒｉｔｙエレメントである。

記述３は、ｒｅｓｏｕｒｃｅエレメントであり、ＪＳＤＫのバージョンを指定するｊｓｄｋエレメント（記述３Ａ）や、ＪＡＲファイル（アプリケーションの実行ファイル）とそのバージョンを指定するｊａｒエレメント（記述３Ｂ）や、ＳＵＢ−ＪＮＬＰファイルを指定するｓｕｂ−ｊｎｌｐエレメント（記述３Ｃ）を含んでいる。

記述４は、ｕｐｄａｔｅエレメントであり、更新処理の実行方法を設定するエレメントである。 ａｕｔｏであればアプリケーションの更新処理は自動更新で実行され、ｍａｎｕａｌであればアプリケーションの更新処理は手動更新で実行され、ｍａｉｌであればアプリケーションの更新処理が実行可能である場合にその旨を通知する更新通知メールが配信される。

記述５は、ｉｎｓｔａｌｌエレメントであり、インストール処理の実行方法を設定するエレメントである。 ａｕｔｏであればアプリケーションのインストール先は自動選択にて選択され、ｍａｎｕａｌであればアプリケーションのインストール先は手動選択にて選択される。

記述６は、アプリケーションのタイプが「ＧＵＩ有」であるか「ＧＵＩ無」であるかを示す。

図１７のｕｐｄａｔｅエレメントで触れたように、インストール済みのＪＳＤＫアプリ１４７は更新処理の対象となる。 以下、インストール済みのＪＳＤＫアプリ１４７を自動更新する自動更新処理について説明する。

図１８は、ＳＤｃａｒｄ又はＨＤＤ内のＪＳＤＫアプリ１４７（更新対象アプリ）を、ＳＤｃａｒｄからのＪＳＤＫアプリ１４７（更新用アプリ）に自動更新する自動更新処理に係るフローチャートである。

ＪＳＤＫプラットフォーム１４８は、融合機１０１に接続された更新用ＳＤｃａｒｄスロットに更新用ＳＤｃａｒｄがセットされた場合、更新用ＳＤｃａｒｄ内の更新用アプリのＪＮＬＰファイルを取得（Ｓ１０１）する。 ＪＳＤＫプラットフォーム１４８は、そのＪＮＬＰファイルのｕｐｄａｔｅエレメントが「ａｕｔｏ」で、そのＪＮＬＰファイルに係る更新用アプリと同一の更新対象アプリが存在する場合（Ｓ１０２・Ｓ１０３）には、その更新用アプリのバージョンとその更新対象アプリのバージョンとを比較（Ｓ１０４）する。 ＪＳＤＫプラットフォーム１４８は、更新用アプリのバージョンが更新対象アプリのバージョンより新しい場合（Ｓ１０５）には、更新用アプリをもって更新対象アプリを更新（Ｓ１０６）する。

図１９は、ＳＤｃａｒｄ又はＨＤＤ内のＪＳＤＫアプリ１４７（更新対象アプリ）を、ＷｅｂからのＪＳＤＫアプリ１４７（更新用アプリ）に自動更新する自動更新処理に係るフローチャートである。

ＪＳＤＫプラットフォーム１４８は、更新対象アプリのＪＮＬＰファイルを取得（Ｓ２０１）する。 ＪＳＤＫプラットフォーム１４８は、そのＪＮＬＰファイルのｕｐｄａｔｅエレメントが「ａｕｔｏ」で、そのＪＮＬＰファイルに係る更新対象アプリと同一の更新用アプリが、融合機１０１とネットワーク接続されたＷｅｂサーバ内に存在する場合（Ｓ２０２・Ｓ２０３）には、その更新対象アプリのバージョンとその更新用アプリのバージョンとを比較（Ｓ２０４）する。 ＪＳＤＫプラットフォーム１４８は、更新対象アプリのバージョンより更新用アプリのバージョンが新しい場合（Ｓ２０５）には、更新対象アプリを更新用アプリをもって更新（Ｓ２０６）する。

最後に、図５の説明中で登場したＸｌｅｔ等のライフサイクルについて説明することにする。

図２０は、Ｘｌｅｔの状態遷移図である。 Ｘｌｅｔの状態としては、初期化状態（Ｌｏａｄｅｄ）と、停止状態（Ｐａｕｓｅｄ）と、活性化状態（Ａｃｔｉｖｅ）と、終了状態（Ｄｅｓｔｒｏｙｅｄ）が存在する。 Ｘｌｅｔの状態は、起動（ｉｎｉｔＸｌｅｔ）や、開始（ｓｔａｒｔＸｌｅｔ）や、停止（ｐａｕｓｅＸｌｅｔ）や、終了（ｄｅｓｔｒｏｙＸｌｅｔ）等のメソッドコールによって遷移する。 Ｘｌｅｔのライフサイクルとは、このようなＸｌｅｔの状態遷移にほかならない。 ただし、どのような状態が存在するか、どのようにして状態が遷移するか、については様々なバリエーションがあり得るだろう。 このことは、Ｘｌｅｔ ＭａｎａｇｅｒやＭｕｌｔｉ Ｘｌｅｔ Ｍａｎａｇｅｒその他の各Ｍａｎａｇｅｒについても同様である。

初期化状態は、Ｘｌｅｔインスタンスの生成直後の状態である。 初期化状態への遷移は１度限りである。 停止状態は、サービス提供停止中の状態であり、活性化状態は、サービス提供中の状態である。 停止状態と活性化状態との間の遷移は何度でも可能である。 終了状態は、Ｘｌｅｔインスタンスの消滅直後の状態である。 終了状態への遷移は１度限りである。

図５の説明中で記載したように、ＪＳＤＫアプリ１４７のライフサイクルは、ＪＳＤＫプラットフォーム１４８によって管理される。 例えば、ＪＳＤＫアプリ１４７は、自己の開始・停止・終了の際には自己の開始・停止・終了をＪＳＤＫプラットフォーム１４８に依頼するのである。 ＪＳＤＫアプリ１４７のライフサイクルをＪＳＤＫプラットフォーム１４８によって管理するメリットとしては例えば、メモリの節約が可能になることが挙げられる。 特に、多数のＪＳＤＫアプリ１４７がそれぞれスレッドとして実行されるマルチスレッドにおいては、このメリットの存在価値は大きいと言える。 ＪＳＤＫアプリ１４７をＸｌｅｔとするメリットとしては例えば、ＪＳＤＫアプリ１４７のライフサイクル管理が容易になることが挙げられる。

（監視アプリ）
図２１は、図５の監視アプリ５１１について説明するための図である。

監視アプリ５１１は、他のＪＳＤＫアプリの実行状態の監視等を行うＪＳＤＫアプリである。 ＪＳＤＫアプリの実行状態を、当該ＪＳＤＫアプリと同一プロセス（ＣＶＭ５５５のプロセス）上で実行されるＪＳＤＫアプリ「監視アプリ５１１」が監視するのである。 ＪＳＤＫアプリの実行状態を、当該ＪＳＤＫアプリと異なるプロセス上で実行されるプログラムが監視する事にすると、プロセス間通信でデータが授受される事になり、メモリが消費される事になってしまう。 しかしここでは、ＪＳＤＫアプリの実行状態を、当該ＪＳＤＫアプリと同じプロセス上で実行されるプログラムが監視する事にするため、プロセス間通信でなく直にデータが授受される事になり、メモリが節約される事になるのである。

監視アプリ５１１は、ユーザアプリ５０１の実行状態の監視（図２１参照）に加えて、ＪＳＤＫ ＧＵＩ Ｍａｎａｇｅｒ５１２やＴａｓｋ Ｂａｒ Ｍａｎａｇｅｒ５１３の実行状態の監視を行う。 そのため、ＪＳＤＫシステムの起動手順（図６参照）において、監視アプリ５１１はＪＳＤＫ ＧＵＩ Ｍａｎａｇｅｒ５１２やＴａｓｋ Ｂａｒ Ｍａｎａｇｅｒ５１３より先に起動（Ｓ１３−１５）してバックグラウンドで動作する。 監視アプリ５１１はさらに、アプリ層の各スレッドの実行状態の監視に加えて、システム層の各スレッドの実行状態の監視を行う。 監視アプリ５１１はこのように、同一プロセス上で実行される各スレッドの実行状態の監視を行う事ができる。

監視アプリ５１１は、図２１（Ａ）に示す障害処理機能、図２１（Ｂ）に示す画面表示機能、図２１（Ｃ）に示す内部保存機能、図２１（Ｄ）に示す外部送信機能等を備える。 これらの機能は、１種類毎に別々に使用する事もできるし、２種類以上を同時に使用する事もできる。

図２１（Ａ）に示す障害処理機能によれば、監視アプリ５１１は、ユーザアプリ５０１に発生した障害を検出した場合、当該ユーザアプリ５０１の実行状態を当該障害の種類に応じて制御する「障害処理」を実行することになる。 例えば、ユーザアプリ５０１の続行に支障のない障害ならば、当該ユーザアプリ５０１を続行する「続行処理」を実行する。 例えば、ユーザアプリ５０１の続行に支障のある障害で、ユーザアプリ５０１の再起動により回避可能な障害ならば、当該ユーザアプリ５０１を再起動する「再起動処理」を実行する。 例えば、ユーザアプリ５０１の続行に支障のある障害で、ユーザアプリ５０１の再起動により回避不可能な障害ならば、当該ユーザアプリ５０１を終了する「終了処理」を実行する。 例えば、ＪＳＤＫシステム全体の続行に支障のある障害ならば、ＪＳＤＫシステム全体を終了する「システム終了処理」を実行する。 すなわち、ユーザアプリ５０１がスレッドとして実行されるプロセス（ＣＶＭ５５５のプロセス）自体が終了する。 以上のようにして、図２１（Ａ）に示す画面表示機能によれば、ユーザアプリ５０１に残存するバグによる障害等が適切に処理されて、他のスレッドへの影響等が適切に回避されることになるのである。

上記「障害」は例えば、Ｊａｖａ（登録商標）の「例外」をもって規定することが可能であり、上記「検出」は例えば、Ｊａｖａ（登録商標）の「ｔｈｒｏｗ，ｃａｔｃｈ」をもって規定することが可能である。 このときには例えば、例外「Ｉ／Ｏ Ｅｘｃｅｐｔｉｏｎ」をｃａｔｃｈしたら「続行処理」か「再起動処理」を、例外「Ｕｎｓｕｐｐｏｒｔｅｄ」をｃａｔｃｈしたら「終了処理」を、例外「Ｏｕｔ ｏｆ Ｍｅｍｏｒｙ」をｃａｔｃｈしたら「システム終了処理」を実行することにするとよいだろう。 入出力の例外は一時的であり、サポートの例外は致命的であり、メモリの例外はＪＳＤＫシステム全体の問題だからである。 監視対象のユーザアプリ５０１の規定方法や障害の種類の規定方法についても、Ｊａｖａ（登録商標）の規約をもって規定することが可能である。

図２１（Ｂ）に示す画面表示機能によれば、監視アプリ５１１は、ユーザアプリ５０１に発生した障害を検出した場合、当該障害に係る情報を当該融合機１０１の画面（タッチパネル３１１等の表示装置等）に表示することになる。 図２１では、当該障害に係る情報として、アプリケーション名，障害名，通知先が表示されている。 図２１では、当該障害に係る情報の他に、続行ボタン，再起動ボタン，終了ボタン，システム終了ボタンが表示されている。 これらの操作ボタンを表示する場合、障害処理機能においてどんな障害処理を実行するかが「自動指定」でなく「手動指定」になることになる。 以上のようにして、図２１（Ｂ）に示す画面表示機能によれば、障害に係る情報が表示されて、ユーザに通知されることになるのである。 従来であれば、各ユーザアプリ５０１に画面表示用のコードを記述しておく必要があったものである。

図２１（Ｃ）に示す内部保存機能によれば、監視アプリ５１１は、ユーザアプリ５０１に発生した障害を検出した場合、当該障害に係る情報を当該融合機１０１の内部（ＨＤＤ２３３等の記憶装置等）に保存することになる。 例えば、当該障害に係る情報を、ログを格納するログファイルに格納して保存する。 以上のようにして、図２１（Ｃ）に示す内部保存機能によれば、障害に係る情報が保存されて、障害解析やデバッグに利用されることになるのである。 従来であれば、各ユーザアプリ５０１に内部保存用のコードを記述しておく必要があったものである。

図２１（Ｄ）に示す外部送信機能によれば、監視アプリ５１１は、ユーザアプリ５０１に発生した障害を検出した場合、当該障害に係る情報を当該融合機１０１の外部（ＰＣ等の端末装置等）に送信することになる。 例えば、当該障害に係る情報を、ＦＴＰ等によるファイル転送，ＳＭＴＰ等によるメール配信，ＨＴＴＰやＳＯＡＰ等によるＷｅｂページ配信，スキャナドライバやプリンタドライバ等への応答と言った形式で送信する。 以上のようにして、図２１（Ｄ）に示す外部送信機能によれば、障害に係る情報が送信されて、ユーザに通知されたり障害解析やデバッグに利用されたりすることになるのである。 従来であれば、各ユーザアプリ５０１に外部送信用のコードを記述しておく必要があったものである。 外部送信は、イーサネット（登録商標）等のＬＡＮとインタネット等のＷＡＮの一方を経由して実施されても両方を経由して実施されてもよい。

図２２は、図５の監視アプリ５１１の障害処理機能について説明するためのシーケンス図である。

ＪＳＤＫシステムでは、ＪＳＤＫ Ｍａｉｎ５２１がＸｌｅｔ Ｍａｎａｇｅｒ５３１を起動（Ｓ１１）して、続いて、Ｘｌｅｔ Ｍａｎａｇｅｒ５３１が監視アプリ５１１を起動（Ｓ１２）して、続いて、Ｘｌｅｔ Ｍａｎａｇｅｒ５３１がユーザアプリ５０１を起動（Ｓ１３）する。 障害処理機能によれば、監視アプリ５１１は、ユーザアプリ５０１に発生した「再起動処理を実行すべき障害」を検出（Ｓ１４）すると、当該ユーザアプリ５０１を再起動すべく再起動要求を発行する「再起動処理」を実行（Ｓ１５）する。 これにより、Ｘｌｅｔ Ｍａｎａｇｅｒ５３１が当該ユーザアプリ５０１を再起動（Ｓ１６）する。

図２３は、図５の監視アプリ５１１の画面表示機能について説明するためのシーケンス図である。

ＪＳＤＫシステムでは、ＪＳＤＫ Ｍａｉｎ５２１がＸｌｅｔ Ｍａｎａｇｅｒ５３１を起動（Ｓ２１）して、続いて、Ｘｌｅｔ Ｍａｎａｇｅｒ５３１が監視アプリ５１１を起動（Ｓ２２）して、続いて、Ｘｌｅｔ Ｍａｎａｇｅｒ５３１がユーザアプリ５０１を起動（Ｓ２３）する。 画面表示機能によれば、監視アプリ５１１は、ユーザアプリ５０１に発生した障害を検出（Ｓ２４）すると、当該障害に係る情報を当該融合機１０１の画面にＯＣＳ１６６（図１参照）等を通じて表示（Ｓ２５）する。

図２４は、図５の監視アプリ５１１の内部保存機能について説明するためのシーケンス図である。

ＪＳＤＫシステムでは、ＪＳＤＫ Ｍａｉｎ５２１がＸｌｅｔ Ｍａｎａｇｅｒ５３１を起動（Ｓ３１）して、続いて、Ｘｌｅｔ Ｍａｎａｇｅｒ５３１が監視アプリ５１１を起動（Ｓ３２）して、続いて、Ｘｌｅｔ Ｍａｎａｇｅｒ５３１がユーザアプリ５０１を起動（Ｓ３３）する。 内部保存機能によれば、監視アプリ５１１は、ユーザアプリ５０１に発生した障害を検出（Ｓ３４）すると、当該障害に係る情報を当該融合機１０１の内部にＭＣＳ１６５（図１参照）等を通じて保存（Ｓ３５）する。

図２５は、図５の監視アプリ５１１の外部送信機能について説明するためのシーケンス図である。

ＪＳＤＫシステムでは、ＪＳＤＫ Ｍａｉｎ５２１がＸｌｅｔ Ｍａｎａｇｅｒ５３１を起動（Ｓ４１）して、続いて、Ｘｌｅｔ Ｍａｎａｇｅｒ５３１が監視アプリ５１１を起動（Ｓ４２）して、続いて、Ｘｌｅｔ Ｍａｎａｇｅｒ５３１がユーザアプリ５０１を起動（Ｓ４３）する。 外部送信機能によれば、監視アプリ５１１は、ユーザアプリ５０１に発生した障害を検出（Ｓ４４）すると、当該障害に係る情報を当該融合機１０１の外部にＮＣＳ１６１（図１参照）等を通じて送信（Ｓ４５）する。

（エミュレータ）
図２６は、本発明の実施例に該当するＰＣ（パーソナルコンピュータ）７０１を表す。 図２６のＰＣ７０１は、図１の融合機１０１とネットワーク８０１で接続されており、図１の融合機１０１のエミュレータとして機能する。

図２６のＰＣ７０１は、ＰＣ本体７１１と、キーボード７１２と、マウス７１３と、ディスプレイ７１４等により構成される。 ＰＣ本体７１１には、ＣＰＵ、ＲＯＭ、ＲＡＭ、ＮＶＲＡＭ、ＨＤＤ、ＭＯＤＥＭ、ＮＩＣ等が存在する。 キーボード７１２とマウス７１３は、融合機１０１のオペレーションパネル２０２に代わって、オペレータが入力を行うためのハードウェア（操作部）となる。 ディスプレイ７１４は、融合機１０１のオペレーションパネル２０２に代わって、オペレータが出力を得るためのハードウェア（表示部）となる。

図２７は、図２６のＰＣ７０１内のＪＳＤＫアプリ１４７とＪＳＤＫプラットフォーム１４８のクラス図である。 図１の融合機１０１と同様のＪＳＤＫアプリ１４７とＪＳＤＫプラットフォーム１４８が、図２６のＰＣ７０１内にも存在するのである。 図１の融合機１０１内のＪＳＤＫアプリ１４７とＪＳＤＫプラットフォーム１４８のクラス図については、図５を参照されたい。 以下、図５と図２７の差異について説明する。

第１に、図５のＰａｎｅｌ Ｍａｎａｇｅｒ５４４は、図２７のＰａｎｅｌ Ｍａｎａｇｅｒ Ｅｍｕｌａｔｏｒ７４４に置換されている。 第２に、図５のＪＳＤＫ Ｓｅｓｓｉｏｎ５５３は、図２７のＥｍｕｌａｔｏｒ ＪＳＤＫ Ｓｅｓｓｉｏｎ７５３に置換されている。 第３に、図５のＮａｔｉｖｅ ＪＳＤＫ Ｓｅｓｓｉｏｎ５５４は、図２７のＥｖｅｎｔ Ｅｍｕｌａｔｏｒ７５４に置換されている。 第４には、図５のＣＶＭ５５５は、図２７のＪＶＭ７５５に置換されている。

Ｐａｎｅｌ Ｍａｎａｇｅｒ Ｅｍｕｌａｔｏｒ７４４は、Ｐａｎｅｌ Ｍａｎａｇｅｒ５４４をエミュレートして、オペレーションパネル２０２の操作をキーボード７１２やマウス７１３の操作に変換するクラスである。 Ｅｍｕｌａｔｏｒ ＪＳＤＫ Ｓｅｓｓｉｏｎ７５３は、通信経路の確立処理を実行するクラスである。 Ｅｖｅｎｔ Ｅｍｕｌａｔｏｒ７５４は、融合機１０１の動作をエミュレートするクラスである。 ＪＶＭ７５５は、ＪＳＤＫアプリ１４７とＪＳＤＫプラットフォーム１４８を実行するためＪａｖａ（登録商標）仮想マシンである。

なお、ＰＣ７０１内のＪＳＤＫシステムの起動手順は、図６と同様である。 また、ＰＣ７０１内のＪＳＤＫシステムのＧＵＩは、図７−１２と同様である。 当該ＧＵＩは、融合機１０１又はＰＣ７０１内のユーザアプリ５０１を操作対象とする操作画面乃至タスクバーであり、ＰＣ７０１内のＪＳＤＫ ＧＵＩ Ｍａｎａｇｅｒ５１２乃至Ｔａｓｋ Ｂａｒ Ｍａｎａｇｅｒ５１３により表示される。 操作部はキーボード７１２とマウス７１３であり、表示部はディスプレイ７１４である。

図２８は、図１の融合機１０１内で実行される遠隔操作の準備処理の実行手順について説明するための図である。

最初に、融合機１０１内のＳｅｒｖｅｒ／Ｃｌｉｅｎｔ Ｍａｎａｇｅｒ５４６とＰＣ７０１内のＳｅｒｖｅｒ／Ｃｌｉｅｎｔ Ｍａｎａｇｅｒ５４６との間で、セッションが確立（Ｓ１）される。

次に、融合機１０１内のＳｅｒｖｅｒ／Ｃｌｉｅｎｔ Ｍａｎａｇｅｒ５４６は、遠隔操作に移行できるか否かを融合機１０１内のＪＳＤＫ Ｍａｎａｇｅｒ５３３に問い合わせて、遠隔操作に移行できるか否かを判断（Ｓ２）する。

次に、融合機１０１内のＳｅｒｖｅｒ／Ｃｌｉｅｎｔ Ｍａｎａｇｅｒ５４６は、遠隔操作に移行できる場合には、遠隔操作に必要なメッセージに係る要求を、融合機１０１内のＳｅｎｄ Ｍａｎａｇｅｒ５４１を介してＰＣ７０１に送信（Ｓ３）して、遠隔操作に必要なメッセージに係る応答を、融合機１０１内のＥｖｅｎｔ Ｍａｎａｇｅｒ５４２を介してＰＣ７０１から受信（Ｓ４）する。

次に、融合機１０１内のＳｅｒｖｅｒ／Ｃｌｉｅｎｔ Ｍａｎａｇｅｒ５４６は、遠隔操作用の情報をＰＣ７０１に転送する旨の要求を、Ｐａｎｅｌ Ｍａｎａｇｅｒ５４４に送信（Ｓ５）する。

最後に、融合機１０１内のＳｅｒｖｅｒ／Ｃｌｉｅｎｔ Ｍａｎａｇｅｒ５４６とＰＣ７０１内のＳｅｒｖｅｒ／Ｃｌｉｅｎｔ Ｍａｎａｇｅｒ５４６との間で、遠隔操作準備処理が完了した旨の通知が授受（Ｓ６）される。 これによって、ＰＣ７０１からの融合機１０１の遠隔操作が可能になる。

（変形例）
図１の融合機１０１は、本発明（画像形成装置）の実施例に該当するものであり、図１の融合機１０１内で実行される情報処理は、本発明（情報処理方法）の実施例に該当するものである。 図５の監視アプリ５１１は、本発明（情報処理プログラム）の実施例に該当するものであり、図５の監視アプリ５１１が記録されたＳＤｃａｒｄやＣＤ−ＲＯＭは、本発明（記録媒体）の実施例に該当するものである。 これらの利用態様としては、これら情報処理プログラムのダウンロードやこれら記録媒体のオプション販売等が考えられる。

図２６のＰＣ７０１は、本発明（端末装置）の実施例に該当するものであり、図２６のＰＣ７０１内で実行される情報処理は、本発明（情報処理方法）の実施例に該当するものである。 図２７の監視アプリ５１１は、本発明（情報処理プログラム）の実施例に該当するものであり、図２７の監視アプリ５１１が記録されたＳＤｃａｒｄやＣＤ−ＲＯＭは、本発明（記録媒体）の実施例に該当するものである。 これらの利用態様としては、これら情報処理プログラムのダウンロードやこれら記録媒体のオプション販売等が考えられる。

本発明の実施例に該当する融合機を表す。

図１の融合機に係るハードウェア構成図である。

図１の融合機に係る外観図である。

オペレーションパネルを表す。

図１のＪＳＤＫアプリとＪＳＤＫプラットフォームのクラス図である。

ＪＳＤＫシステムの起動手順について説明するための図である。

ＪＳＤＫシステムのＧＵＩについて説明するための図である。

切替操作画面について説明するための図である。

起動操作画面について説明するための図である。

終了操作画面について説明するための図である。

インストール操作画面について説明するための図である。

アンインストール操作画面について説明するための図である。

起動操作画面の表示手順について説明するための図である。

起動処理の実行手順について説明するための図である。

インストール操作画面の表示手順について説明するための図である。

インストール処理の実行手順について説明するための図である。

ＪＮＬＰファイルの構文の例を表す。

ＪＳＤＫアプリをＳＤｃａｒｄからのＪＳＤＫアプリに自動更新する自動更新処理に係るフローチャートである。

ＪＳＤＫアプリをＷｅｂからのＪＳＤＫアプリに自動更新する自動更新処理に係るフローチャートである。

Ｘｌｅｔの状態遷移図である。

監視アプリについて説明するための図である。

監視アプリの障害処理機能について説明するためのシーケンス図である。

監視アプリの画面表示機能について説明するためのシーケンス図である。

監視アプリの内部保存機能について説明するためのシーケンス図である。

監視アプリの外部送信機能について説明するためのシーケンス図である。

本発明の実施例に該当するＰＣを表す。

ＰＣ内のＪＳＤＫアプリとＪＳＤＫプラットフォームのクラス図である。

融合機内で実行される遠隔操作の準備処理の実行手順について説明するための図である。

符号の説明

１０１ 融合機 １１１ ハードウェア １１２ ソフトウェア １１３ 融合機起動部 １２１ 撮像部 １２２ 印刷部 １２３ その他のハードウェア １３１ アプリケーション １３２ プラットフォーム １３３ アプリケーションプログラムインタフェース １３４ エンジンインタフェース １３５ 仮想アプリケーションサービス １４１ コピーアプリ １４２ プリンタアプリ １４３ スキャナアプリ １４４ ファクシミリアプリ １４５ ネットワークファイルアプリ １４６ ＣＳＤＫアプリ １４７ ＪＳＤＫアプリ １４８ ＪＳＤＫプラットフォーム １５１ コントロールサービス １５２ システムリソースマネージャ １５３ ハンドラ １６１ ネットワークコントロールサービス １６２ ファクシミリコントロールサービス １６３ デリバリコントロールサービス １６４ エンジンコントロールサービス １６５ メモリコントロールサービス １６６ オペレーションパネルコントロールサービス １６７ サーティフィケーションコントロールサービス １６８ ユーザディレクトリコントロールサービス １６９ システムコントロールサービス １７１ ファクシミリコントロールユニットハンドラ １７２ イメージメモリハンドラ ２０１ コントローラ ２０２ オペレーションパネル ２０３ ファクシミリコントロールユニット ２１１ ＣＰＵ
２１２ ＡＳＩＣ
２２１ ＮＢ
２２２ ＳＢ
２３１ ＭＥＭ−Ｐ
２３２ ＭＥＭ−Ｃ
２３３ ＨＤＤ
２３４ メモリカードスロット ２３５ メモリカード ２４１ ＮＩＣ
２４２ ＵＳＢデバイス ２４３ ＩＥＥＥ１３９４デバイス ２４４ セントロニクスデバイス ３０１ 原稿セット部 ３０２ 給紙部 ３０３ 排紙部 ３１１ タッチパネル ３１２ テンキー ３１３ スタートボタン ３１４ リセットボタン ３１５ 機能キー ３１６ 初期設定ボタン ３２１ ＡＤＦ
３２２ フラットベッド ３２３ フラットベッドカバー ５０１ ユーザアプリ ５１１ 監視アプリ ５１２ ＪＳＤＫ ＧＵＩ Ｍａｎａｇｅｒ
５１３ Ｔａｓｋ Ｂａｒ Ｍａｎａｇｅｒ
５２１ ＪＳＤＫ Ｍａｉｎ
５２２ ＪＳＤＫ Ｅｎｖｉｒｏｎｍｅｎｔ
５２３ Ｌｏｃａｌｅ Ｍａｎａｇｅｒ
５３１ Ｘｌｅｔ Ｍａｎａｇｅｒ
５３２ Ｍｕｌｔｉ Ｘｌｅｔ Ｍａｎａｇｅｒ
５３３ ＪＳＤＫ Ｍａｎａｇｅｒ
５４１ Ｓｅｎｄ Ｍａｎａｇｅｒ
５４２ Ｅｖｅｎｔ Ｍａｎａｇｅｒ
５４３ Ｓｙｓｔｅｍ Ｅｖｅｎｔ Ｍａｎａｇｅｒ
５４４ Ｐａｎｅｌ Ｍａｎａｇｅｒ
５４５ Ｉｎｓｔａｌｌ Ｍａｎａｇｅｒ
５４６ Ｓｅｒｖｅｒ／Ｃｌｉｅｎｔ Ｍａｎａｇｅｒ
５４７ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｍａｎａｇｅｒ
５５１ ＪＳＤＫ ＡＰＩ
５５２ ＪＳＤＫ ＡＰＩ
５５３ ＪＳＤＫ Ｓｅｓｓｉｏｎ
５５４ Ｎａｔｉｖｅ ＪＳＤＫ Ｓｅｓｓｉｏｎ
５５５ ＣＶＭ
７０１ ＰＣ
７１１ ＰＣ本体 ７１２ キーボード ７１３ マウス ７１４ ディスプレイ ７４４ Ｐａｎｅｌ Ｍａｎａｇｅｒ Ｅｍｕｌａｔｏｒ
７５３ Ｅｍｕｌａｔｏｒ ＪＳＤＫ Ｓｅｓｓｉｏｎ
７５４ Ｅｖｅｎｔ Ｅｍｕｌａｔｏｒ
７５５ ＪＶＭ
８０１ ネットワーク