(57)【要約】      （修正有）【課題】  複数のアプリケーションモードを有するシステムにおけるアプリケーション制御を間便化する。【解決手段】  アプリケーションにユニークなＩＤを付与するＩＤ付与手段、アプリケーションの制御対象が明確に異なる機能毎に定義されるアプリケーションモードの遷移についての遷移制御手段、アプリケーション共通に定義されるシステム状態の遷移についてのシステム状態遷移制御手段、システム状態を管理するシステム状態管理スタックを備える。イベント発生時にイベントを受け取ったイベントディスパッチ手段が、前記管理スタックに保持された通知方法に依りアプリケーションに通知する。またモード遷移が必要な要因を検出した場合、遷移条件が満たされると前記システム状態遷移制御手段がスタックをプッシュして追加する。遷移条件が満たされない場合遷移要求イベントキューイングにキューイングする。【選択図】  図１７
2006146693.tif 000002
【特許請求の範囲】
【請求項１】
複数のアプリケーションモードを有するシステム、または、多機能プリンターシステムにおけるアプリケーション管理方法であって、
システム状態管理スタックと、イベントディスパッチを行なうイベントディスパッチステップと、
アプリケーションモード遷移制御を行なう遷移制御ステップと、システム状態遷移制御を行なう遷移制御ステップと、遷移要求イベントキューイングを行なうイベントキューイングステップと、ＩＤ付与を行なうＩＤ付与ステップと、
を備えることを特徴とするアプリケーション管理方法。
【請求項２】
複数のアプリケーションモードを有するシステム、または、多機能プリンターシステムにおけるアプリケーション管理方法であって、
アプリケーション登録・削除する登録・削除ステップと、アプリケーション管理テーブルと、システム状態管理スタックと、イベントディスパッチを行なうイベントディスパッチステップと、
アプリケーションモード遷移制御を行なう遷移制御ステップと、システム状態遷移制御を行なう遷移制御ステップと、遷移要求イベントキューイングを行なうイベントキューイングステップと、初期化同期する初期化同期ステップと、
を備えることを特徴とするアプリケーション管理方法。
【請求項３】
前記システム状態管理スタックは、対象となる状態に関連したＩＤと優先順位とイベント通知方法を保持すると共に、カレント状態を示すスタックポインターを持つ事を特徴とする請求項１または請求項２に記載のアプリケーション管理方法。
【請求項４】
前記イベントディスパッチを行なうイベントディスパッチステップは、送られて来たイベントを、
前記システム状態管理スタックの最上位にある状態に対応したイベント通知方法を用いて、対応したモジュールへ送付する送付ステップと、
前記イベント通知方法が失敗した場合に、あらかじめ定義されたデフォルトのイベント処理方法を呼び出す呼び出しステップと
を備えることを特徴とする請求項１または請求項２に記載のアプリケーション管理方法。
【請求項５】
前記アプリケーションモード遷移制御を行なう遷移制御ステップは、遷移要求イベントがキューイングされた場合には、遷移要求元のイベント通知方法を用いて、要求イベントが保留されたことを通知することを特徴とする請求項１または請求項２に記載のアプリケーション管理方法。
【請求項６】
前記遷移要求イベントキューイングを行なうイベントキューイングステップは、遷移要求イベントを優先度順に繋ぎ替えて保持することを特徴とする請求項１または請求項２に記載のアプリケーション管理方法。
【請求項７】
前記システム状態遷移制御を行なう遷移制御ステップは、状態遷移処理が行われた場合には、状態管理スタックにある全てのイベント通知ステップに対し、状態遷移が行われたことを通知することを特徴とする請求項１または請求項２に記載のアプリケーション管理方法。
【請求項８】
前記システム状態遷移制御を行なう遷移制御ステップは、状態遷移要求イベントがキューイングされた場合には、遷移要求元のイベント通知方法を用いて、要求イベントが保留されたことを通知することを特徴とする請求項１または請求項２に記載のアプリケーション管理方法。
【請求項９】
前記アプリケーションモード遷移制御を行なう遷移制御ステップは、
システム状態管理スタックの最上位にあるカレント状態（ＩＤ）とイベント通知方法と優先順位を読み出す読み出しステップと、
送付されたアプリケーションモード遷移要求イベントに含まれた遷移先モードのＩＤとイベント通知方法と優先順位を取り出す取出しステップと、
前記カレント状態が特定の状態と等しいことを評価する第１の評価ステップと、
前記カレント状態の優先順位と、前記遷移先モードの優先順位を比較して前記遷移先モードの優先順位が前記カレント状態の優先順位より高いことを評価する第２の評価ステップと、
アプリケーション管理システムの内部状態が遷移中でないことを評価する第３の評価ステップとを含み、
第１の評価ステップ、第２の評価ステップ、第３の評価ステップの評価結果が全て真である場合には、モード遷移処理を行い、第１の評価ステップ、第２の評価ステップ、第３の評価ステップの評価結果の少なくとも一つが偽であるときには、モード遷移を行わずに遷移要求イベントキューイングを行なうイベントキューイングステップをもちいて、前記アプリケーションモード遷移要求イベントをキューイングすることを特徴とする請求項１に記載のアプリケーション管理方法。
【請求項１０】
前記アプリケーションモード遷移制御を行なう遷移制御ステップは、
前記システム状態管理スタックの最上位にあるカレント状態（ＩＤ）とイベント通知方法と優先順位を読み出す読み出しステップと、
送付されたアプリケーションモード遷移要求イベントに含まれた遷移先モードのＩＤを取り出す取出しステップと、
前記遷移先モードＩＤに関連付けられて格納されている前記アプリケーション管理テーブル内の優先順位とイベント通知方法を読み込む読み込みステップと、
前記カレント状態が特定の状態と等しいことを評価する第４の評価ステップと、
前記カレント状態の優先順位と、前記遷移先モードの優先順位を比較して前記遷移先モードの優先順位が前記カレント状態の優先順位より高いことを評価する第５の評価ステップと、
アプリケーション管理システムの内部状態が遷移中でないことを評価する第６の評価ステップと、
第４の評価ステップ、第５の評価ステップ、第６の評価ステップの評価結果が全て真である場合には、モード遷移処理を行い、第４の評価ステップ、第５の評価ステップ、第６の評価ステップの評価結果の少なくとも一つが偽であるときには、モード遷移を行わずに前記遷移要求イベントキューイングを行なうイベントキューイングステップをもちいて前記アプリケーションモード遷移要求イベントをキューイングすることを特徴とする請求項２に記載のアプリケーション管理方法。
【請求項１１】
前記システム状態遷移制御を行なう遷移制御ステップは、送付された状態遷移要求イベントがアップスタックイベントであった場合には、
前記システム状態管理スタックの最上位にあるカレント状態（ＩＤ）とイベント通知方法を読み出す読み出しステップと、
送付された状態遷移要求イベントに含まれた遷移先モードのＩＤとイベント通知方法を取り出す取出しステップと、
前記カレント状態のイベント通知方法を用いて遷移可能条件を評価する第７の評価ステップと、
アプリケーション管理システムの内部状態が遷移中でないことを評価する第８の評価ステップと、
第７の評価ステップ、第８の評価ステップの評価結果が全て真である場合には、状態遷移処理を行い、第７の評価ステップ、第８の評価ステップの評価結果の少なくとも一つが偽であるときには、状態遷移を行わずに前記遷移要求イベントキューイングを行なうイベントキューイングステップをもちいて前記状態遷移要求イベントをキューイングすることを特徴とする請求項１記載のアプリケーション管理方法。
【請求項１２】
前記システム状態遷移制御を行なう遷移制御ステップは、送付された状態遷移要求イベントがアップスタックイベントであった場合には、
前記システム状態管理スタックの最上位にあるカレント状態（ＩＤ）とイベント通知方法を読み出す読み出しステップと、
送付された状態遷移要求イベントに含まれた遷移先モードのＩＤを取り出す取出しステップと、
前記遷移先モードＩＤに関連付けられて格納されている前記アプリケーション管理テーブル内のイベント通知方法を読み込む読み込みステップと、
前記カレント状態のイベント通知方法を用いて遷移可能条件を評価する第９の評価ステップと、
アプリケーション管理システムの内部状態が遷移中でないことを評価する第１０の評価ステップと、
第９の評価ステップ、第１０の評価ステップの評価結果が全て真である場合には、状態遷移処理を行い、第９の評価ステップ、第１０の評価ステップの評価結果の少なくとも一つが偽である場合には、状態遷移を行わずに前記遷移要求イベントキューイングを行なうイベントキューイングステップをもちいて前記状態遷移要求イベントをキューイングすることを特徴とする請求項２に記載のアプリケーション管理方法。
【請求項１３】
前記システム状態遷移制御を行なう遷移制御ステップは、送付された状態遷移要求イベントがダウンスタックイベントであった場合には、
送付された状態遷移要求イベントに含まれた解除対象モードのＩＤを取り出す取出しステップと、
前記システム状態管理スタックの最上位から状態ＩＤを検索して前記解除対象モードのＩＤと最初に一致した位置にあるスタック情報を取り出す取出しステップと、
アプリケーション管理システムの内部状態が遷移中でないことを評価する第１１の評価ステップと、
第１１の評価ステップの評価結果が真である場合には、状態遷移処理を行い、偽であるときには、状態遷移を行わずに前記遷移要求イベントキューイングを行なうイベントキューイングステップをもちいて前記状態遷移要求イベントをキューイングすることを特徴とする請求項１または請求項２に記載のアプリケーション管理方法。
【請求項１４】
前記システム状態遷移制御を行なう遷移制御ステップは、現在の状態に対し新たな状態をスタック上に積み上げる積み上げステップと、現在の状態をスタックから抜き去る抜き去りステップによって行なわれることを特徴とする請求項１または請求項２に記載のアプリケーション管理方法。
【請求項１５】
前記アプリケーション管理テーブルは、アプリケーション登録テーブルとシステム状態管理モジュール登録テーブルを別々に管理することを特徴とする請求項２に記載のアプリケーション管理方法。
【請求項１６】
前記アプリケーション管理テーブルは、アプリケーション登録テーブルの管理単位ごとに関連付けられた少なくとも一つ以上のシステム状態管理モジュール登録テーブルを持つ事を特徴とする請求項２に記載のアプリケーション管理方法。
【請求項１７】
前記アプリケーション登録・削除する登録・削除ステップは、登録対象となるアプリケーションから、モード遷移条件と、イベント通知方法を受け取り、対象となるアプリケーションに対してユニークなＩＤ番号を割り当てるＩＤ番号割当ステップと、前記モード遷移条件と、イベント通知方法を前記ＩＤ番号と関連付けて前記アプリケーション管理テーブルへ登録する登録ステップと、登録対象となるアプリケーションへ前記ＩＤ番号を通知する機能を備えることを特徴とする請求項２に記載のアプリケーション管理方法。
【請求項１８】
前記アプリケーション登録・削除する登録・削除ステップがアプリケーションから受け取る前記イベント通知方法は、アプリケーション自身が通知先になるものと、任意個の別プロセスが通知先になるものとから構成されることを特徴とする請求項２に記載のアプリケーション管理方法。
【請求項１９】
前記初期化同期する初期化同期ステップは、システム起動時にアプリケーション管理システムのリソース初期化が、アプリケーション登録処理よりも先に行われるように制御する制御ステップを備えることを特徴とする請求項２に記載のアプリケーション管理方法。
【請求項２０】
複数のアプリケーションモードを有するシステム、あるいは、多機能プリンターシステムにおけるアプリケーション管理方法を実現する制御プログラムであって、
システム状態管理スタックと、イベントディスパッチを行なうイベントディスパッチステップと、
アプリケーションモード遷移制御を行なう遷移制御ステップと、システム状態遷移制御を行なう遷移制御ステップと、遷移要求イベントキューイングを行なうイベントキューイングステップと、ＩＤ付与を行なうＩＤ付与ステップと、
を備えることを特徴とするアプリケーション管理方法の制御プログラム。
【請求項２１】
複数のアプリケーションモードを有するシステム、あるいは、多機能プリンターシステムにおけるアプリケーション管理方法を実現する制御プログラムであって、
アプリケーション登録・削除する登録・削除ステップと、アプリケーション管理テーブルと、システム状態管理スタックと、イベントディスパッチを行なうイベントディスパッチステップと、
アプリケーションモード遷移制御を行なう遷移制御ステップと、システム状態遷移制御を行なう遷移制御ステップと、遷移要求イベントキューイングを行なうイベントキューイングステップと、初期化同期する初期化同期ステップと、
を備えることを特徴とするアプリケーション管理方法の制御プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数の機能を有するいわゆる多機能プリンター等のアプリケーション管理システムに関するものである。
【背景技術】
【０００２】
従来のＰＣプリンターにおける制御ソフトウエアは、機構制御機能を主眼において作成されているため、ユーザーインターフェースに関わる制御やプリントソースの違い（ワードプロッセサのドキュメント、デジタルカメラの写真、スキャナーからの取り込み画像など）に起因するシーケンス切り替えなどの高度な制御を全てＰＣのアプリケーションに任せていた（例えば、特許文献１参照）。
【０００３】
しかしながら、近年、デジタルカメラなどの普及に伴い、その出力媒体としてのプリンターに対する高機能化のニーズが高まってきており、従来のようなＰＣからの印刷機能だけでなくデジタルカメラからのダイレクト印刷機能やコピー機能、或いはファックス機能など、あらゆるプリントニーズに対応できるマルチファンクションプリンターが市場に投入されてきている。このような複合機能を持ったマルチファンクションプリンターでは、従来のＰＣプリンターと異なり、高度なユーザーインターフェースを持ち、スタンドアローンで使用可能な機能が要求され、それに伴い従来ＰＣアプリケーションに任せていた制御を全て独自に行わなければならなくなってきている。マルチファンクションプリンターに対して求められる機能は決して単一ではなく、市場ターゲットに依存して変化することが当然であると考えられるので、機能の付加・削除に対して柔軟性を持ったソフトウエア構造が不可欠であり、そのためには機能ごとにモジュール化された個別のアプリケーションを間便に接続できる構成が必要となる。
【０００４】
アプリケーションのモジュール性を高めて拡張性を持たせるためには以下の要素が重要である。
１．異なるアプリケーションであっても、キーイベントなどの共通リソースから発生するイベントは一本化して共通のインターフェースでハンドリングできる構造を持つこと。（拡張性）
２．共通リソースから発生するイベントを効率的に扱う為に、イベントを受け取るべきアプリケーションが限定される管理機構を持っていること。（処理の効率性）
３．アプリケーションは各機能（カメラからの印刷、コピー印刷など）を実現するために必要な制御のみを行えば良いような構成となっていること。（保守性）
もし、上記１が満たされないとすると、イベントを投げるモジュールがアプリケーションに応じて制御を変えなければならず、拡張性が保たれなくなる。また１が満たされていても２が満足されないと、全てのアプリケーションがラウンドロビン的に起動され、制御にかかるオーバーヘッドが増加してしまう。また３が満たされないと、各機能で共通な要素（例えばエラー発生時の制御など）までアプリケーションが制御しなければならなくなってしまう。
【特許文献１】特開平０９−００６４０８
【特許文献２】特開平０７−１７５６７１
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、プリンターなどの組み込み機器で一般的に用いられているＩｔｒｏｎなどのＲＴＯＳはＰＣ上のＯＳとは異なり、キーイベントなどＵＩ系の共通イベントを、並列に動作するアプリケーションプロセスに対して効率的にハンドリングするウインドーシステム機構を持たないので、このままでは上述した１，２の要素を満たせないという欠点があった。
【０００６】
ＯＳ以外のサブシステムがプロセスを管理する技術の一例として例えば、特許文献２に開示されているように、ＯＳとプロセスの間に「プロセス管理プロセス」と呼ばれるサブシステムを導入することで、動作プロセスを管理する手法が提案されている。この手法を応用すれば同文献に記述された「動作条件」を適切に設定することで上述した２の要素は実現できるが、１と３の要素はやはり満たすことが出来ない。
【課題を解決するための手段】
【０００７】
本発明は、上述した問題点を解決するためになされたものであり、以下のような特徴を持つ。
【０００８】
複数のアプリケーションモードを有するシステム、あるいは、多機能プリンターシステムにおけるアプリケーション管理方法であって、
システム状態管理スタックと、イベントディスパッチを行なうイベントディスパッチステップと、
アプリケーションモード遷移制御を行なう遷移制御ステップと、システム状態遷移制御を行なう遷移制御ステップと、遷移要求イベントキューイングを行なうイベントキューイングステップと、ＩＤ付与を行なうＩＤ付与ステップと、
を備えることを特徴とする。
【０００９】
「アプリケーションモード」とは、制御対象が明確に異なる機能毎に定義された一つのモードを表す。例えば、「デジタルカメラからのダイレクト印刷機能」、「任意のＩ／Ｆに接続されたストレージデバイスからの印刷機能」、「ＰＣドライバーを介した印刷機能」、「スキャナーから画像を読み取りながら直接印刷を行うコピー印刷機能」などは、一般的に異なる制御を必要とし、それぞれが一つのアプリケーションモードを形成すると考えられる。それに対して「システム状態」とは、各アプリケーションモードに対して共通の概念を定義できる状態であり、例えば「エラー状態」などが「システム状態」に相当する。（尚、全てのモードにおける共通の概念として「アイドル状態」を定義する。この状態は、モードにおける「基底状態」であり、原則としてアプリケーションモードを管理するプロセス自身が制御するものとする。）ここでは、各アプリケーションモードを管理するモジュール（タスク）を単に「アプリケーション」と呼び、各システム状態を管理するモジュール（タスク）を「システム状態管理モジュール」と呼ぶことにする。
【発明の効果】
【００１０】
本願により、複数の機能を有する多機能システムにおいて、アプリケーション管理システムを導入し、イベント伝達系のインターフェースを統一することで個別モジュールのモジュール性を高めることができるので、結果としてシステムの拡張性を高めることができるという効果がある。
【００１１】
また、複数のアプリケーションモードにまたがって共通に定義されるシステム状態の概念を導入し、あるシステム状態における制御を一つのモジュールでモード横断的に行うことにより、モジュールの再利用性が高まり、結果としてシステム設計の生産性を向上させるという効果がある。
【００１２】
また、システム状態間の遷移は、単純なスタックのプッシュ・ポップ操作のみによって行われるため遷移にかかる負荷を最小限に抑えることが可能である。更に遷移要求が満たされなかった時は内部的なキューイング機構が働き、また状態が変わった時にはキューをサーチして自動的に再遷移を起動する仕組みを持つと同時に状態の変化を通知する仕組みも有するため、アプリケーション或いは状態管理モジュールが遷移処理にかける負荷を軽減できる。これらの要素により処理を高速化できる効果がある。
【００１３】
また、システムが起動されると、各アプリケーションは「ＩＤ付与手段」を呼び出して、ユニークなＩＤを獲得する。システム起動処理が終了すると、「アプリケーションモード遷移制御手段」において任意の方法を用いて起動時モードが決定される。この時取得された情報は、「システム状態管理スタック」の最基底部に書き込まれて、現在のアプリケーションモードを保持すると共に、システム状態が「アイドル状態」であることを明示化させる。「アイドル状態」における「アプリケーション」に対する共通イベント（例えばキー操作など）が発生すると、外部ハンドラーは「アプリケーション管理システムが提供する共通のＡＰＩ」を用いて対応するイベントを管理システムへ発行し、このイベントを受け取った「イベントディスパッチャー」が「システム状態管理スタック」に保持されたイベント通知方法を用いて「アプリケーション」に対して直接通知を行える。また、あるシステム状態を管理するモジュールが該当する状態遷移要因を検出した場合は、（例えば「エラー状態」を管理するモジュールがエラー発生を検出した場合など）任意のタイミングで「システム状態遷移制御手段」へ状態遷移要求イベントを通知することが出来る。
【００１４】
また、イベントを受け取った「システム状態遷移制御手段」は、あらかじめ定義された任意の方法を用いて遷移条件を判断し、遷移条件を満たした場合は状態遷移処理を行って「システム状態管理モジュール」へ通知すると共に「システム状態管理スタック」をプッシュしてカレント状態の上に「該当するシステム状態」を追加する。この時新しく追加された「システム状態」には、イベントの通知方法として「該当するシステム状態を管理するシステム状態管理モジュール」が定義したものが書き込まれる。従って、「アプリケーション」が何ら特別な制御を行うことなく、「該当するシステム状態」における共通イベントは、上述したのと同じ原理で、「該当するシステム状態管理モジュール」へ直接通知されることになる。
【００１５】
また、遷移条件を満たさなかった要求は「遷移要求イベントキューイングステップ」によりキューイングされて、適当なタイミングで再遷移を行うことが出来る。状態を復帰させる動作は、上述した「状態管理スタック」へのプッシュ処理をポップ処理にするのみで、全く対象的に行うことが出来る。
【００１６】
また、モード遷移が必要になるような外部イベントを受け取った「アプリケーション」は、任意のタイミングでアプリケーションモード遷移要求イベントを「アプリケーションモード遷移制御手段」へ送ることが可能である。「アプリケーションモード遷移制御手段」はイベントを受け取ると、要求元の情報と「システム状態管理スタック」の情報を参照して、遷移条件を満たした場合に、モード遷移処理を行い、「システム状態管理スタック」の最基底部に新しいアプリケーションの情報を書き込んでモードを切替えることができる。
【００１７】
また、遷移条件を満たさなかった要求は「遷移要求イベントキューイングステップ」によりキューイングされて、適当なタイミングで再遷移を行うことが出来る。
【００１８】
以上、述べたように、「アプリケーション」は、「アプリケーション管理システム」が定める共通Ｉ／Ｆを用いてイベントハンドリングの共通化を行うことが出来ると共に、アプリケーションへイベントを送るためのＩ／Ｆも共通化されるので、モジュールの拡張性を高めることが出来る。
【００１９】
また、「アプリケーションモード遷移制御手段」は遷移要求元が送付したデータを元にモード遷移制御を行い、更に「システム状態遷移制御手段」は、あらかじめ定義された方法でシステム状態遷移制御を行い、共に管理情報を「状態管理スタック」に書き込むことでカレント情報が「状態管理スタック」で一元管理されるため、任意のモード・状態の組み合わせにおいて、イベント通知方法が一義的に決定される。
【００２０】
更に、「システム状態管理モージュール」及び「システム状態遷移制御手段」は、上述した方法で連係してシステム状態遷移と、その状態における制御を行うため、「アプリケーション」を自身の機能実現の為だけに特化させることが可能になる。
【発明を実施するための最良の形態】
【００２１】
（実施例１）
本発明の第１実施例について説明する。（本実施例は本発明を多機能プリンターに適用した場合のことを想定しているが、同じようなシステム構成をとる任意の装置に適用可能なことは言うまでも無い。）まず、本実施例における構成について図１を用いて説明する。同図において、１００はアプリケーション管理システムである。１０１はアプリケーションモード遷移制御手段であり、特定のプロセスから発生するアプリケーションモード遷移要求イベントを受け取って、モード遷移を制御する。１０２は遷移要求イベントキューであり、アプリケーションモード遷移制御手段（１０１）或いはシステム状態遷移制御手段（１０３）での遷移処理において遷移条件が満たされなかった時に、要求イベントの履歴を保存するためのものである。１０３はシステム状態遷移制御手段であり、特定のプロセスから発生するシステム状態遷移要求イベントを受け取って、状態遷移を制御する。１０５はシステム状態管理スタックであり、モード遷移制御手段（１０１）または状態遷移制御手段（１０３）によってカレント状態がプッシュ或いはポップされる。１１３はイベントディスパッチャーであり、共通イベントをアプリケーション或いは状態管理モジュールへ通知する。１１４はＩＤ付与手段であり、制御対象となるモジュールに対してユニークなＩＤを割り振る機能を提供する。次に本実施例の動作について詳細に説明する。
【００２２】
始めにシステム起動時の処理について図２０を用いて説明する。同図はシステム起動時の処理フローを表す。システムが起動されるとＯＳリソースなどの初期化後に、まずＳ２００１においてＩＤ付与手段（１１４）の初期化が行われる。続いて各アプリケーションとシステム状態管理モジュールが起動されて、Ｓ２００２〜Ｓ２００４のループでＩＤ割付処理が行われる。Ｓ２００３におけるＩＤ割付は、各モジュールがＩＤ付与手段（１１４）が提供するＩ／Ｆを呼び出して、ユニークなＩＤを獲得する処理である。（以降、便箋的に、アプリケーションに与えられるＩＤを特にアプリケーションＩＤと呼び、システム状態管理モジュールに与えられるＩＤをシステムＩＤと呼ぶことにする。）ＩＤを獲得した各モジュールは、自身のＩＤを覚えておく。全てのアプリケーション及びシステム状態管理モジュールに対するＩＤ付与が終了したら、各モジュールはタスク間通信などの機能を用いて、制御の為に必要な他のモジュールのＩＤを取得する。次にＳ２００５でアプリケーション管理システム１００の初期化が行われ、続いてＳ２００６でシステム状態管理スタック（１０５）へビルトインアプリの情報が設定される。（後述するように、このアプリケーションは、システムが状態遷移途中にあって有効なモードが確定するまでの間だけ、暫定的に起動されるアプリケーションである。）この後、アプリケーション管理システム１００は、タスク遅延などの手段を用いて、アプリケーションに実行権を渡し、その間に、システム的にあらかじめ定められた「デフォルトモードアプリケーション」と、もし遷移要因が整っていれば任意のアプリケーションがモード遷移要求イベントを発行する。実行権を回復したアプリケーション管理システム１００は、Ｓ２００７でモード遷移シーケンスを起動して、初期化時のアプリケーションを立ち上げ、処理を終了する。（モード遷移に関しては、後述する。）ここでは、ＩＤ付与手段（１１４）が動的に各制御対象モジュールに対してＩＤを付与する方法について説明したが、これを静的に行う方法を用いても良い。即ち、システム設計時に抽出された動作モードとシステム状態に対して、マクロなどを用いて、あらかじめユニークなＩＤを静的に付与しておくことで、ここで述べた動的なＩＤ付与処理は省略することも可能である。以上で起動時処理の説明を終わる。
【００２３】
次にアプリケーションモード遷移制御処理について図５を用いて説明する。（ここでの説明はアプリケーションＡからアプリケーションＢへ遷移するものとして議論する。遷移前の状態は図２１（Ａ）のようになっているものとする。）同図は、アプリケーションモード遷移制御処理のフローを表している。Ｓ５０１〜Ｓ５０２における処理は、外部イベントハンドラーによる処理を表す。Ｓ５０３〜Ｓ５０５における処理は、モード遷移要求元であるプロセスによる処理を表す。（モード遷移イベント要求元となるプロセスは、必ずしもアプリケーションそのものである必要はないが、ここでは簡単の為にアプリケーションＢ自身が要求元であるものとする。）Ｓ５０６〜Ｓ５２０における処理は、アプリケーション管理システム１００での処理を表す。また、Ｓ５２３〜Ｓ５２４における処理は一義的にコンテキストが定まらないものであり、システムに依存してアプリケーションＡのコンテキストかアプリケーション管理システム１００のコンテキストのどちらかに属する。同様にＳ５２１〜Ｓ５２２の処理は、アプリケーションＢのコンテキストかアプリケーション管理システム１００のコンテキストのどちらかに属する。今、イベントハンドラーがアプリケーションＢの起動要因を検出したとすると（Ｓ５０１）、そのイベントが任意の方法を用いてアプリケーションＢに伝えられる。（Ｓ５０２）（イベントハンドラー及び起動要因に関しては、システムに依存して任意の構成をとることが出来る。例えばアプリケーションＢがデジタルカメラからの直接印刷機能を制御するものであるとすれば、イベントハンドラーはＵＳＢなどのインターフェースを監視し、カメラ接続事象を起動要因として、アプリケーションＢをキックするようなものが考えられる。）イベント待ち状態であったアプリケーションＢは、Ｓ５０３においてハンドラーからの遷移要因検出イベントを受けて、続くＳ５０４で、アプリケーション遷移制御手段（１０１）が提供するインターフェース（ＡＰＩ）を通じて、モード遷移要求イベントを発生させる。このインターフェースは、（１）遷移イベント要求元、（２）遷移イベントの種類、（３）付加情報の長さ、（４）付加情報へのポインター１１１、（５）優先順位１８１、（６）イベント通知手段１８２、をアプリケーションが設定して呼び出すものである。ここで（３）及び（４）は、呼び出し元とイベント種別に依存したデータである。（付加データとして明示的に定義された型を用いないのは、システム依存な部分をなるべく排除し、アプリケーション管理システム１００の汎用性を確保するためである。）また（６）は、イベントを通知する為の方法として、定義された関数型であり、引数としてイベント種別と付加データへのポインター８４が与えられる。ＡＰＩでは、付加情報の長さ分のメモリー領域を確保して、（４）の内容をコピーした後、図１８で示されるようなパケットを生成してアプリケーション管理システム１００に送付する。Ｓ５０６でイベント待ち状態であったアプリケーション管理システム１００は、モード遷移イベントがアプリケーションＢ（ＩＤ＝２）から発生したことを受けて、遷移シーケンスに入る。遷移シーケンスが起動されると、まずＳ５０７においてモード遷移可能かどうかが判断される。モード遷移可能条件は、次の３つの条件のＡＮＤで判断される。
１．システム状態がアイドル状態である。（スタックポインターが最下段を指している。）
２．内部状態が遷移中ではない。
３．遷移先のモードの優先度が現在の優先度より高い。
【００２４】
上記判断のための情報を獲得するために、図２１（Ａ）に示されたスタックポインター２１３が指す状態管理スタック２１１から、システム状態３４とカレント優先度３３、及びイベント通知方法３５（ここでは“ＦＵＮＣ＿Ａ”）が読み出される。同時に、Ｓ５０６で獲得したパケットにアクセスして、遷移先モードの優先度３３とイベント通知方法３５（ここでは“ＦＵＮＣ＿Ｂ”）が読み出される。これらの情報を用いて、上記１と３の条件が満たされるかどうかが判断され、同時にアプリケーション管理システム１００の内部情報である内部状態が２を満たすかどうかが判断される。全ての条件が満たされると遷移シーケンスが続行される。（条件が満たされなかった場合は、Ｓ５０９において要求イベントのキューイング処理が行われるが、これについては後述する。）続くＳ５０８で内部状態をモード遷移中に設定する。Ｓ５１１では、状態管理スタック２１１をポップした後、ビルトインアプリケーションの情報をプッシュする。（ビルトインアプリケーションとは、ＩＤ＝０を割り振られた特殊なアプリケーションであり、起動時直後、或いはアプリケーション管理システム１００が遷移処理状態にある時に暫定的なモード支配を行う様に設計されている。起動時アプリケーションが定義するイベント通知方法３５（ＦＵＮＣ＿ＳＹＳ）は、起動要求、停止要求、状態遷移通知のみ受け付けるようになっており、他の共通イベントは全てＦａｉｌする。従って起動時アプリケーションモードで発生した共通事象は全てシステムフックへ流されることになり、単純なＵＩ系イベントなどへの応答はしない。これに関連して、アイドル状態におけるイベントディスパッチ機構については後述する。）続いてＳ５１２、Ｓ５１３では、Ｓ５０７において読み出しておいたそれぞれのイベント通知方法３５（ＦＵＮＣ＿Ａ，ＦＵＮＣ＿Ｂ）を用いてアプリケーションＡには停止要求を、そしてアプリケーションＢには起動要求をそれぞれ送付する。（この時、Ｓ５０６で受け取ったパケットの付加情報も一緒に送る。）これらの通知処理を行った後、アプリケーション管理システム１００はＳ５１４でイベント待ち状態になる。一方、停止要求を受け取ったアプリケーションＡは、Ｓ５２３において停止の為に必要な処理を行う。（ここでの処理内容は、システムに依存して様々なものが有り得るが、例えば内部状態を切り替えたり、表示系などに関連した不要なリソースを解放する処理などが考えられる。）Ｓ５２３での処理が終了したら、Ｓ５２４においてアプリケーション管理システム１００へ停止処理が終了したことを伝える。（通知は、アプリケーション管理システム１００が用意したＡＰＩなどのインターフェースを用いて行う。）同様にしてアプリケーションＢはＳ５２１で起動処理（表示リソースの確保、初期表示等）を行った後、Ｓ５２２で起動処理終了通知をアプリケーション管理システム１００へ送る。（前述したように、これら２つの処理が行われるコンテキストは、アプリケーション側でも、アプリケーション管理システム側でも構わない。即ちＳ５１２において呼び出されたＦＵＮＣ＿Ａの中でＳ５２３、Ｓ５２４の処理が完結できるのであれば実行コンテキストは管理システム側になるし、ここでイベント通知のみが行われるのであれば、実行コンテキストは、アプリケーション側になる。どちらの形態をとるかは処理負荷などに応じて実装依存で定まることであり、肝心な事は必ず処理終了通知によって同期をとることである。）Ｓ５１４でイベント待ち状態だったアプリケーション管理システム１００は、停止終了通知と起動終了通知が両方とも揃ったことを確認したら、モード遷移シーケンスを継続させてＳ５１５に進み、システム状態管理スタック１０５にアプリケーションＢの管理情報を書き込み、更にモード遷移中であった内部状態をクリアする。更にＳ５１６において遷移要求イベントキュー１０２が調べられて、保留イベントが存在したらＳ５１８でリストの先頭要素を取り出す。取り出された要素のイベント種別８３がＳ５１９で調べられて、もしイベントが状態遷移要求であったら、Ｓ１００７へ分岐して状態遷移制御シーケンスが起動され、モード遷移要求であったら、再びＳ５０７へ戻って新しいモード遷移シーケンスに入る。キューが空であったら、そこで処理を終了する。（Ｓ５１７でイベント待ちになる。）モード遷移処理が終了するとアプリケーション管理システム１００内の状態は図２１（Ｂ）のようになり、アプリケーションＢが管理するモードとなる（尚、状態管理スタック２１１のデータ構造についても図２１（Ｃ）に示しておく）。
【００２５】
次にＳ５０９で行われるモード遷移要求イベント保留処理について図６を用いて説明する。処理が起動されるとモード遷移制御手段（１０１）は、Ｓ６０１で遷移要求イベントキュー（１０２）を検査してリストが空でないかどうか確認する。リストが空であった時には、Ｓ６０２においてリスト領域を確保し、必要な情報をリスト要素にコピーしてリストの先頭につなぐ。もしリストが空でなかった時は、Ｓ６０３でリストの検索処理を行う。検索処理は、（１）対象イベントのＩＤと等しい要素の検索、（２）対象イベントの優先度より低い（数値が小さいほうが優先度が高い）要素の検索、の順に行われ、（１）でヒットした場合は、Ｓ６０４で要素の入れ替え処理のみが行われ、（１）でヒットしなかった場合は、（２）で検索された要素の直前に、対象イベントの内容をコピーした新しいリスト要素を挿入する。（Ｓ６０５）（尚、（２）の検索処理において、リスト内の全ての要素の優先度が対象イベントの優先度以上であった場合は、リストの最後に接続される。）最後にＳ６０６において、対象イベントのイベント通知方法３５を用いて、イベントが保留されたことと保留要因（優先度に起因するものか、システム状態に起因するものか）を通知する。ここで用いるキューイングリストの構造は、例えば図８に示したようなものである。同図（Ａ）はリスト要素のデータ構造であり、ｐｒｅｖｉｏｕｓ８１／ｎｅｘｔ８２はそれぞれ自分の前及び後に接続された要素へのポインターであり、ＩＤ４３、優先度３３、及びイベント通知方法３５は、全てモード遷移要求発行元の情報である。またイベント種別８３は、遷移シーケンス起動の要因となった遷移要求イベントである。リストは同図（Ｂ）に示されたように優先度順の１次元リンクリストとして保持される。（ここで示したリスト構造は、一般的に用いられている優先度付汎用リスト構造である。ここでは、構造を例示したのみであり、本発明の範囲がこの構造に限定される訳ではない。）以上が、モード遷移要求イベント保留処理のシーケンスであるが、保留されたイベントは後述するように、状態遷移のタイミングで必ずフックされてしまう。もし、保留解除を待っている間に、モード遷移条件が崩れてしまったり（例えば一度接続されたデジタルカメラがはずされた等）、システム仕様的に、そもそも保留する必要がなかったりする場合も考えられるので、モード遷移制御手段（１０１）は、保留された遷移要求イベントを解除するインターフェースも備えている。このインターフェースを通じて呼び出された処理は、図９に示したシーケンスフローにより保留イベントを解除する。以上で、モード遷移要求イベント保留処理の説明を終わる。
【００２６】
次にシステム状態遷移制御処理について、図１０を用いて説明する。同図はシステム状態遷移制御処理のフローを表す。同図においてＳ１００１〜Ｓ１００２の処理は、外部イベントハンドラーによる処理を表す。Ｓ１００３〜Ｓ１００５の処理は、遷移要求元での処理を表す。また、Ｓ１００６〜Ｓ１０１８の処理はアプリケーション管理システム１００における処理を表す。今、イベントハンドラーが状態遷移要因を検出したとすると（Ｓ１００１）、そのイベントが任意の方法を用いて、状態遷移要求元となるモジュールに通知される。ここから状態遷移要求元がアプリケーション管理システム１００が提供するＡＰＩをコールして、状態遷移要求イベントを通知するまでの処理過程は、モード遷移制御においてＳ５０３からＳ５０６で行われるそれと殆ど同じであるので詳細な説明は省く。結果として、図１８で示された型のパケットがアプリケーション管理システム１００へ送られて、状態遷移要求イベントの発生が認識される。
【００２７】
ここで状態遷移要求イベントに関してその定義を説明しておく。パケットのイベント種別８３には、（１）アップスタックイベント、または（２）ダウンスタックイベント、のどちらかが格納されている。２つのイベントの定義は下記で与えられる。
（１）アップスタックイベント
新たな状態を状態管理スタックへ積み重ねる。
（２）ダウンスタックイベント
既に状態管理スタック２１１に入った状態を解除する。
【００２８】
再び図１０に戻ってシーケンスの説明を続ける。
【００２９】
イベントを受け取ったアプリケーション管理システム１００は、Ｓ１００６において状態遷移制御手段を呼び出して状態遷移シーケンスを起動する。同シーケンスは、まずＳ１００７で受け取ったパケットの内容を解析し、遷移先のＳｙｓｔｅｍ  ＩＤとイベント通知方法３５をパケットから取得する。ここで取得したイベント通知方法３５がＮＵＬＬだった場合は、この要求を無効であるものと見なし、イベントを捨てて処理を終了してしまう。イベント通知方法３５が有効であった時は、遷移可能条件が満たされているかどうかが判断される。遷移が許可されるためには、イベント種別８３に応じて下記の条件を満たす必要がある。
（１）アップスタックイベントの時
１．内部状態が遷移処理中ではなく、かつ
２．カレント状態管理モジュールが遷移を許可する。
（２）ダウンスタックイベントの時
１．内部状態が遷移処理中ではない。
【００３０】
アップスタックイベントの時は、２の条件を評価するために、カレント状態管理モジュールのイベント通知方法３５に対して、状態遷移判断要求イベントが遷移先のＳｙｓｔｅｍ  ＩＤと共に送付される。アプリケーション管理システム１００は、この関数の戻り値に応じて２の条件を評価する。ここで遷移が可能であると判断された場合は、遷移シーケンスを継続し、Ｓ１００８へ進む。（遷移が不可能であった場合は、Ｓ１００９で状態遷移要求イベントの保留処理が行われるが、この処理は図６の処理と同じである。ただし、モード遷移要求と異なり状態遷移要求は全て優先度０（優先度最大）の事象として扱われるので、必ずモード遷移要求より前につながれる。また、状態遷移要求同士の順位はＦＩＦＯ型になる。）Ｓ１００８ではアプリケーション管理システム１００の内部状態を状態遷移処理中に設定する。続くＳ１０１１では、システム状態管理スタック１０５をビルトインアプリのものに設定する。（この処理は、Ｓ５１１と同じ処理である。）次にＳ１０１２でイベントの種別による分岐が行われて、アップスタック処理（Ｓ１０１４）またはダウンスタック処理（Ｓ１０１３）が起動される。これらの処理が終了すると、Ｓ１０１５〜Ｓ１０１８においてキューイングリストへの対応処理が行われる（Ｓ５１６〜Ｓ５１９での処理と同じ）。
【００３１】
次に図１２を用いてＳ１０１４におけるアップスタック処理について説明する。まずＳ１２０１において遷移先に起動要求イベントを発行した後、イベント待ち状態に入る。（Ｓ１２０４）遷移先が起動終了通知を返してきたら、シーケンスを継続し、Ｓ１２０５で状態管理スタック２１１を操作する。この処理は、まずスタックをポップしてビルトインアプリ状態を解除してから、遷移先状態をスタックにプッシュするものである。最後にＳ１２０７で現在の状態管理スタック２１１上にある全てのモジュールに対して、状態遷移通知イベントを発行する。この時、イベントと共に図１４に示した構造をもつデータが各モジュールに送られる。同図において直前状態のＩＤ１４１及びカレント状態のＩＤ１４２は、それぞれ遷移前後でスタックの頂点にあった状態を表すＳｙｓｔｅｍ  ＩＤ（アプリケーションの場合はアプリケーションＩＤ）であり、イベント種別８３は遷移の起点となった遷移要求イベント（アップスタック要求、ダウンスタック要求、モード遷移要求）であり、付加情報は遷移要求元が要求イベント発行時に送ってきたものである。各モジュールは、通知イベントに同期して送られて来るこれらのデータを解析することで、必要な動作を行うことが出来る（例えば、状態遷移要求イベントを一度けられて、かつキューを削除した後で、遷移要求の再送タイミングを待っていたモジュールは、データを解析して遷移可能であると判断できる状態であれば、状態遷移要求を行うことが出来る）。
【００３２】
次に図１３を用いてダウンスタック処理について説明する。まずＳ１３０１で状態管理スタック２１１を上から下へ検索して要求元のＩＤと等しい情報を取り出す。（取り出した後のスタックは詰めておく）次にＳ１３０２で対象のモジュールに対し、停止要求イベントを投げた後Ｓ１３０５でイベント待ち状態になる。停止要求イベントを受けたモジュールから停止終了通知を受け取ったら、シーケンスを継続してＳ１３０６で状態管理スタック２１１を操作し、ビルトインアプリ状態を解除する。その後、状態遷移通知イベント発行処理（Ｓ１３０８）を行ってシーケンスを終了する（これらの処理は、Ｓ１２０７におけるものと同じである）。
【００３３】
ここで状態のネストについて簡単に説明しておく。注意深く設計されたシステムでは、状態管理スタック２１１上に同じ状態が複数現れることは稀である。（逆にそのようにシステム設計すべきである。）しかし、場合によっては状態のネストが生じることが避けられないこともあり得る。例えば、あるエラーが発生してエラー状態１５１になった後で、エラー解除の為にＡの状態１５２に入り、そこでまたエラーが発生して状態Ａを管理するモジュールが対応処理を何も行わなかった場合、図１５のようなスタック状態になることが考えられる。上述した様にダウンスタック処理ではＳ１３０１におけるスタック探索が上から下へ行われ、かつ対象が最上位にいなくても状態解除が可能なシーケンスとなっているため、仮にこの状態で最初に生じたエラーと２番目に生じたエラーが同時に解除されて、エラー状態管理モジュールが複雑なシーケンス管理を行わずに、ダウンスタックイベントを２回続けて投げるだけの操作を行ったとしても、状態の辻褄を合わせることが可能である。
【００３４】
次に本システムにおけるイベントディスパッチシーケンスについて図１６を用いて説明する。このシーケンスは、発生したイベントが前述した遷移要求イベント以外である時に起動されるものである。Ｓ１６０１でイベント発生要因を検出した外部ハンドラーが、Ｓ１６０２でアプリケーション管理システム１００が提供するＡＰＩを用いてイベントを通知する動作は、図５または図１０で説明したものと全く同じ処理内容である。（ただし、この場合図１８で示したパケットデータのうち、有効なものはイベント種別８３と付加情報へのポインターのみとなる。）Ｓ１６０３でイベント通知を受けたアプリケーション管理システム１００は、イベントディスパッチ手段（１１３）を呼び出してディスパッチシーケンスを起動する。同シーケンスが起動されると、Ｓ１６０４においてシステム状態管理スタック１０５のスタックポインターが指す位置に格納されたモジュールのイベント通知方法３５を使ってイベントが通知される。Ｓ１６０５では、呼び出したコールバックの戻り値を見て、処理が成功していたらＳ１６０６へ分岐してシーケンスを終了する。もし、コールバック関数が処理失敗を返してきたら、Ｓ１６０７のシステムディスパッチを行う。システムディスパッチャーは、あらかじめ定義された（或いは動的に登録された）ルーチンを用いて、主にシステムよりのイベントを処理するように実装されている。（例えば、動作中に電源キーが押された場合は、システムの電源を切る動作を統一的に行うことが一般的である。このようなイベントを処理するのがシステムディスパッチャーである。）
以上で、本実施例における全ての制御シーケンスの説明を終わる。
【００３５】
（実施例２）
本発明の第２実施例について説明する。（本実施例は本発明を多機能プリンターに適用した場合のことを想定しているが、同じようなシステム構成をとる任意の装置に適用可能なことは言うまでも無い。）まず、本実施例における構成について図１７を用いて説明する。（同図において第一実施例の構成図面である図１における構成要素と同じ機能を有するものについては、同じ参照符号を記し、説明を省く。）
同図において、１７００はアプリケーション管理システムである。１７０６はアプリケーション管理テーブルであり、そのコンテンツとしてアプリケーション登録テーブル（１７０７）及びシステム状態管理モジュール登録テーブル（１７０８〜１７１１）を含んでいる。１７１２はアプリケーション登録手段であり、アプリケーションがアプリケーション管理情報をアプリケーション管理テーブル（１７０６）へ登録したり、アプリケーション管理テーブル（１７０６）から削除したりするためのインターフェースを与える。１１３はイベントディスパッチャーであり、共通イベントをアプリケーション或いは状態管理モジュールへ通知する。１７１４は初期化同期手段であり、システム起動時にアプリケーションが登録動作を行う為に必要な同期機能を提供する。次に本実施例の動作について詳細に説明する。
【００３６】
始めにアプリケーションの登録・削除処理について説明する。
【００３７】
まずアプリケーションの登録処理について図２を用いて説明する。同図はシステム起動時に行われるアプリケーション登録処理のフローを表す。システムが起動されるとＯＳリソースなどの初期化後に、まず初期化同期手段（１７１４）の初期化が行われ、次に各アプリケーションタスクが起動されてＳ２０１〜Ｓ２０３のループで各アプリケーションが初期化同期のために必要なフラグを獲得する。この処理は各アプリケーションが初期化同期手段（１７１４）を呼び出して、ユニークなフラグを獲得する処理である。この時、初期化同期手段（１７１４）は、自分が与えたフラグを全て覚えておく。フラグを獲得したアプリケーションは、例えば初期値が０である共通のセマフォをゲットしにいくことで、待ち状態になる。全てのアプリケーションがフラグを獲得して待ち状態になると、Ｓ２０４においてアプリケーション管理システム１７００が起動されて、自身を初期化する。この初期化では、アプリケーション管理テーブル（１７０６）やシステム状態管理スタック（１０５）などの動的リソースに対する初期化処理を加える。アプリケーション管理システム（１７００）は、自身の初期化が終了すると初期化同期手段（１７１４）を呼び出して初期化終了を通知すると共に待ち状態に入る。初期化同期手段（１７１４）は例えば上述したセマフォをリリースすることで待ち行列に入っている先頭のアプリケーションを動作状態にする。初期化同期フラグ獲得後に待ち状態に入っていた各アプリケーションは、この事象に同期してＳ２０５〜Ｓ２０８のループでアプリケーション登録を行う。Ｓ２０６において行われるアプリケーション登録処理とは、自身のアプリケーション管理情報を、アプリケーション登録手段（１７１２）を用いてアプリケーション管理テーブル１７０６に記録する一連の手続きである。アプリケーション管理情報は図３に示した情報を含んでおり、図示されたように自身の優先度３３とイベント通知方法３５、及びあらかじめ定義されたシステム状態３４におけるイベント通知方法３５を指定する。（本実施例のシステムでは、システム状態３４として「Ｐｒｉｎｔ状態」、「Ｅｒｒｏｒ状態」、「ＩｎｋＣｈａｎｇｅ状態」が定義されているものとする。当然の事ながら、これらの定義はシステムに依存して定まるものであり、この例に限定されるものではない。）今、アプリケーション（Ａ）から図３（Ａ）で示された管理情報が、アプリケーション登録手段（１７１２）に送られたものとすると、アプリケーション登録手段（１７１２）はアプリケーション（Ａ）に対してユニークなアプリケーションＩＤ＝１を割り当てる。次にアプリケーション登録テーブル（１７０７）における“ＩＤ＝１”の項に、送られて来た優先度３３と、イベント通知方法３５を書き込む。更にＩＤ＝１にリンクされるシステム状態管理モジュール登録テーブル（１７０８）に、送られて来た各状態におけるイベント通知方法３５を書き込む。この時、図３（Ａ）の３行目（或いは４行目）で例示されているようにイベント通知方法３５が“Ｄｅｆａｕｌｔ”指定されていた場合は、システムがあらかじめ用意したデフォルトの方法をシステム状態管理モジュール登録テーブル（１７０８）へ書き込む。また、図３（Ｂ）に例示したように、登録指定の無いシステム状態に関しては、システム状態管理モジュール登録テーブル（１７０８）の該当する要素に“ＮＵＬＬ”を書き込んで、そのアプリケーションモードにおける無効なシステム状態を明示する。これら、アプリケーション管理テーブル１７０６への書き込み処理が終了すると、アプリケーション登録手段１７１２は、割り振ったアプリケーションＩＤを呼び出し元のアプリケーションへ返す。自身のＩＤを獲得したアプリケーションは、ＩＤを記憶すると共に、Ｓ２０７において初期化同期手段（１７１４）へ自分の初期化同期フラグを通知して登録処理が終了したことを通知する。初期化同期フラグを返却された初期化同期手段（１７１４）は、該当フラグをクリアした後、例えば前述したセマフォを再びリリースすることで、次のアプリケーションへ登録権を与える。以上の動作を全ての初期化同期フラグがクリアされるまで繰り返すことで、Ｓ２０５〜Ｓ２０８のループが完結する。（尚、各モードにおける（即ち異なるアプリケーションＩＤを持つ）モード制御を行うアプリケーションの実体が必ずしも異なる必要はない。もしモードを分割した方が見通しが良いが、タスクを分けてリソースを消費するほどの価値が見出せない２つの近接したモードがあったら、同じモジュールが２つのモードを制御するような構成にすることも一案である。）アプリケーション登録処理によって生成されたアプリケーション管理テーブル（１７０６）の一例を図４に示した。ＩＤ＝１を割り振られたアプリケーションは、優先度＝１２８であり、イベント通知方法３５は“ＦＵＮＣ＿Ａ”で与えられている。また「Ｐｒｉｎｔ状態」、「Ｅｒｒｏｒ状態」、「ＩｎｋＣｈａｎｇｅ状態」を全てハンドリング可能であり、この内「Ｐｒｉｎｔ状態」におけるイベント通知方法３５には独自のメソッドを定義している。同様にしてＩＤ＝２を持つアプリケーションは、優先度＝６４であり、イベント通知方法３５は“ＦＵＮＣ＿Ｂ”で与えられる。またシステム状態のうち、「Ｐｒｉｎｔ状態」をとることは無い。ＩＤ＝０のアプリケーションは、優先度が２５５であり、全てのシステム状態が無効である。（後述するように、このアプリケーションは、システムが状態遷移途中にあって有効なモードが確定するまでの間だけ、暫定的に起動される「ビルトインアプリケーション」である。）システム状態管理モジュール登録テーブル４２には状態名として“Ｓｙｓｔｅｍ  ＩＤ”が記述されているが、これはあらかじめ定義されたシステム状態をＩＤ番号で識別するためのものである（尚、この後、起動時の初期アプリケーション立ち上げ処理が行われるが、これに関しては第一実施例と同じであるので説明を省略する）。
【００３８】
次にアプリケーションの削除処理について説明する。削除を要求するアプリケーションは、自身のＩＤを引数にして、アプリケーション登録手段１７１２が提供するインターフェースをコールする。アプリケーション登録手段は、まず状態管理スタック２１１の最基底を調べて、削除対象のＩＤを持ったモードがアクティブである場合は失敗を返す。そうでなかった場合は、アプリケーション登録テーブル１７０７の該当項目における情報と、それに関連付けられたシステム状態管理モジュール登録テーブル４２を削除して処理を終了する。
【００３９】
以上で、アプリケーション登録・削除処理に関する動作説明を終えるが、ここで述べた初期化同期手段による同期管理のプロセスは、用いるＯＳの種類に依存して変化する可能性を持っており、説明した手法に限定されるものではない。即ちアプリケーション管理システム１７００の初期化後にアプリケーション登録処理が行われる構成であることが重要であり、それを実現する手段がいかようであろうとも、それらは全て本発明の範囲に含まれるべきものである。（例えばシステム初期化処理以降に、動的な登録処理を行う場面も想定できるが、それに関しても上述した方法によって容易に実現できることは言うまでも無い。）逆に、アプリケーション登録処理をシステム初期化前に行うことは、アプリケーション管理テーブル１７０６や状態管理スタック２１１が不定である期間にこれらのリソースを制御しなければならないので、現実的に不可能である。
【００４０】
次にアプリケーションモード遷移制御処理について図２２を用いて説明する。尚、同図において図５と同じ処理内容を示している部分には同じ参照符号を付し、説明を省く。また本実施例でもアプリケーションＡからアプリケーションＢへ遷移するものとして議論する。（遷移前の状態は図７（Ａ）のようになっている。）外部イベントハンドラーが遷移要因を受けて遷移要求元であるプロセスへ外部イベントを送った後、Ｓ２２０４ではアプリケーション遷移制御手段（１０１）が提供するインターフェース（ＡＰＩ）を通じて、モード遷移要求イベントを発生させる。このＡＰＩ仕様は第一実施例とは異なり、（１）遷移イベント要求元、（２）遷移イベントの種類、（３）付加情報の長さ、（４）付加情報へのポインター、を引数とする。このＡＰＩコールにより発生するパケットの構造は、図１１で表され、このパケットを受け取ったアプリケーション管理システム１７００は、第一実施例と同様にしてモード遷移シーケンスを起動する。Ｓ２２０７における遷移可否の判断ロジックは、第一実施例におけるものと全く同じである。ただし、遷移先モードの情報は、パケットから得るのではなく、アプリケーション登録テーブル１７０７にアクセスしてＩＤ＝２に格納された遷移先モードの優先度３３とイベント通知方法３５（ここでは“ＦＵＮＣ＿Ｂ”）が読み出される。後は、Ｓ２２１１に至るまで第一実施例と同じ処理を行い、Ｓ２２１１ではビルトインアプリの情報をシステム状態管理スタック１０５に設定すると同時に、状態管理モジュールテーブルも同アプリのものに入れ替える処理が付加される。同様にＳ２２１５においてもスタック操作に加えて、状態管理モジュールテーブルの入れ替え処理を行う。以降の処理に関しては、第一実施例と全く同じであるので、説明を省略する。モード遷移処理が終了すると、アプリケーション管理システム１７００の状態は図７（Ｂ）のようになり、アプリケーションモードが切り替わる。
【００４１】
次にシステム状態遷移制御処理について、図２３を用いて説明する。尚、同図において図１０と同じ処理内容を示している部分には同じ参照符号を付し、説明を省略する。Ｓ２３０４における状態遷移要求イベントの送付処理は、モード遷移制御と同様にアプリケーション管理システム１７００が提供するＡＰＩ仕様と、ＡＰＩが掃き出すパケットデータ構成が異なるのみである。Ｓ２３０７における処理は、データの収集先がパケットからシステム状態管理モジュール登録テーブルに変わるのみである。Ｓ２３１１における処理では、スタック操作に加えて、システム状態管理モジュール登録テーブルの変更処理が生じるのみである。以降の処理は全て第一実施例と同様である。
【００４２】
イベントディスパッチシーケンスは、第一実施例と全く同じであるので説明を省略する。
【００４３】
以上で、本実施例における全ての制御シーケンスの説明を終わる。尚、本実施例においても、起動要求処理、停止要求処理をアプリケーション管理システム１７００のコンテキストで行う様にすることが可能である。また、本実施例に特有の事項として、アプリケーション管理テーブルを持つことで、そこに管理される様々な情報を他のプロセスが必要に応じて取り出すための統一されたインターフェースを提供することが可能となり、制御の柔軟性が増すという効果がある。
【００４４】
また、本発明の目的は、上記実施の形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体（又は記録媒体）を、システム又は装置に供給し、そのシステム或いは装置のコンピュータ（又はＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読み出し実行することによっても、達成されることは言うまでもない。
【００４５】
この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。
【００４６】
また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているオペレーティングシステム（ＯＳ）等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【００４７】
さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張カードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張カードや機能拡張ユニットに備わるＣＰＵ等実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【００４８】
また、上記プログラムは、上述した実施の形態の機能をコンピュータで実現することができればよく、その形態は、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給されるスクリプトデータ等の形態を有するものでもよい。
【００４９】
プログラムを供給する記録媒体としては、例えば、ＲＡＭ、ＮＶ−ＲＡＭ、フロッピー（登録商標）ディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＭＯ、ＣＤ−Ｒ、ＣＤ−ＲＷ、ＤＶＤ（ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ、ＤＶＤ−ＲＷ、ＤＶＤ＋ＲＷ）、磁気テープ、不揮発性のメモリカード、他のＲＯＭ等の上記プログラムを記憶できるものであればよい。或いは、上記プログラムは、インターネット、商用ネットワーク、若しくはローカルエリアネットワーク等に接続される不図示の他のコンピュータやデータベース等からダウンロードすることにより供給される。
【図面の簡単な説明】
【００５０】
【図１】本発明の第一実施例の構成を表す図
【図２】本発明の第二実施例におけるアプリケーション登録処理を表すフローチャート
【図３】本発明の第二実施例におけるアプリケーション登録情報を表す図
【図４】本発明の第二実施例におけるアプリケーション管理テーブルの構成を表す図
【図５】本発明の第一実施例におけるアプリケーションモード遷移制御シーケンスを表すフローチャート
【図６】本発明における遷移要求イベントキューイング処理を表すフローチャート
【図７】本発明の第二実施例におけるアプリケーションモード遷移を説明するための図
【図８】本発明における遷移要求イベントキューイングリストの構造を表す図
【図９】本発明における遷移要求イベントキュー要素削除処理を表すフローチャート
【図１０】本発明の第一実施例におけるシステム状態遷移シーケンスを表すフローチャート
【図１１】本発明の第二実施例においてアプリケーション管理システムが受け取るイベントパケットのデータ構成を表す図
【図１２】本発明におけるアップスタック遷移処理を表すフローチャート
【図１３】本発明におけるダウンスタック遷移処理を表すフローチャート
【図１４】本発明において状態遷移完了後にシステムがスタック上のプロセスへ送るイベントのデータ構造を示す図
【図１５】本発明においてシステム状態がネストした場合の一例を示す図
【図１６】本発明におけるイベントディスパッチシーケンスを表すフローチャート
【図１７】本発明の第二実施例の構成を表す図
【図１８】本発明の第一実施例においてアプリケーション管理システムが受け取るイベントパケットのデータ構成を表す図
【図１９】本発明の第一実施例におけるＩＤ割り付け処理を表すフローチャート
【図２０】本発明の第一実施例における起動時処理を表すフローチャート
【図２１】本発明の第一実施例におけるアプリケーションモード遷移を説明するための図
【図２２】本発明の第二実施例におけるアプリケーションモード遷移制御シーケンスを表すフローチャート
【図２３】本発明の第二実施例におけるシステム状態遷移シーケンスを表すフローチャート
【符号の説明】
【００５１】
１００  アプリケーション管理システム
１０１  アプリケーションモード遷移制御手段
１０２  遷移要求イベントキュー
１０３  システム状態遷移制御手段
１０５  システム状態管理スタック
１１３  イベントディスパッチ手段
１１４  ＩＤ付与手段
１７００  アプリケーション管理システム
１７０６  アプリケーション管理テーブル
１７０７  アプリケーション登録テーブル
１７０８  システム状態管理モジュール登録テーブル
１７０９  システム状態管理モジュール登録テーブル
１７１０  システム状態管理モジュール登録テーブル
１７１１  システム状態管理モジュール登録テーブル
１７１２  アプリケーション登録手段
１７１４  初期化同期手段
３１  アプリケーション登録テーブルへの情報
３２  システム状態管理モジュール登録テーブルへの情報
３３  優先度
３４  システム状態
３５  イベント通知方法
４１  アプリケーション登録テーブル
４２  システム状態管理モジュール登録テーブル
４３  ＩＤ
４５  状態
８１  ｐｒｅｖｉｏｕｓ
８２  ｎｅｘｔ
８３  イベント種別
８４  付加データへのポインター
１１１  付加情報へのポインター
１４１  直前状態のＩＤ
１４２  カレント状態のＩＤ
１５１  エラー状態
１５２  Ａ状態
１５３  エラー状態
１５４  基底状態
１８１  優先順位
１８２  イベント通知手段
２１１  状態管理スタック
２１２  アプリケーション
２１３  スタックポインタ
【図１】
2006146693.tif 000003
【図２】
2006146693.tif 000004
【図３】
2006146693.tif 000005
【図４】
2006146693.tif 000006
【図５】
2006146693.tif 000007
【図６】
2006146693.tif 000008
【図７】
2006146693.tif 000009
【図８】
2006146693.tif 000010
【図９】
2006146693.tif 000011
【図１０】
2006146693.tif 000012
【図１１】
2006146693.tif 000013
【図１２】
2006146693.tif 000014
【図１３】
2006146693.tif 000015
【図１４】
2006146693.tif 000016
【図１５】
2006146693.tif 000017
【図１６】
2006146693.tif 000018
【図１７】
2006146693.tif 000019
【図１８】
2006146693.tif 000020
【図１９】
2006146693.tif 000021
【図２０】
2006146693.tif 000022
【図２１】
2006146693.tif 000023
【図２２】
2006146693.tif 000024
【図２３】
2006146693.tif 000025