JP2018151788A - 画像処理装置及びプログラム - Google Patents

Abstract

【課題】内部アプリケーションと外部アプリケーション等、異なる種類のアプリケーションが混在する場合についても画面制御し得る画像処理装置及びプログラムを提供する。【解決手段】画像処理装置は、フレームワーク上で動作する、内部アプリケーション及び外部アプリケーションと、内部アプリケーション及び外部アプリケーション並びにフレームワークを実行するプロセッサを備える。フレームワークは、内部アプリケーションのウインドウを地の色（背景色）の層８８とともに表示し、外部アプリケーションのウインドウをその下の階層に表示する場合に地の色（背景色）の層８８を透明に設定して外部アプリケーションを視認可能とする。フレームワークは、画面にフォールト９６等を表示する場合に地の色（背景色）の層８８を透明に設定する。【選択図】図２９

Description

本発明は、画像処理装置及びプログラムに関する。

コピー、プリンタ、ファクス等の機能を備える複合機は、さらに多機能化しており、各種のアプリケーション（アプリ）を含む全体システムを効率的に構築することが要求されている。

特許文献１には、アプリ一覧画面に表示されるアイコンのアプリが実行中であるか否かを、ユーザが容易に把握できるようにする画像処理装置が記載されている。アプリケーション及びアプリケーションの動作設定を登録したマクロを呼び出すためのアイコンに対し、アイコンの位置、アイコン画像、アプリケーションの識別情報、マクロの識別情報を含む一覧画面情報を記憶する画面情報記憶手段と、ジョブの状態が待機から実行に変化したアプリケーションの状態情報を取得し、識別情報を出力するとともに画面更新要求を行う画面制御手段と、一覧画面情報に基づき作成したアプリケーションの一覧画面に対して画面更新要求を受けた場合、取得された識別情報が示すアプリケーションのアイコンの表示形態を、他のアプリケーションのアイコンとは異なる表示形態に更新する画面作成手段と、更新されたアイコンを含む一覧画面を表示する表示手段を備えることが記載されている。

特許文献２には、多機能化する複合機において、ユーザの操作性を向上させることが記載されている。標準アプリケーションと、拡張アプリケーションと、標準及び拡張アプリケーションを識別するアプリ識別情報を、それぞれのアイコンの座標情報及びアイコンの画像情報に対応付けたアイコン配置情報を記憶する配置情報記憶手段と、アイコン配置情報に基づき、標準及び拡張アプリケーションに対応するアイコンが表示されるアプリ一覧画面を作成する一覧画面作成手段と、作成された前記アプリ一覧作成画面を表示する表示手段と、押下されたアイコンに対応する標準又は拡張アプリケーションをアイコン配置情報から特定し、特定された標準又は拡張アプリケーションに対し、操作画面の表示要求を行う画面制御手段を備えることが記載されている。

また、複数のアプリケーションの起動に関しては、例えば以下の技術が知られている。

特許文献３には、複数の独立したプログラムを連携させて動作させ、サブ処理の起動を行う際にサブ処理の起動情報を作成するとともにメイン処理の戻り先情報を設定し、処理終了後にメイン処理のメモリを解放してサブ処理の起動処理を行うことが記載されている。

特許文献４には、ファイル転送におけるアプリケーション連携処理において、ファイル転送プログラムに別のプログラムを起動する機能をもたせ、ファイル転送の前後で別のアプリケーションを起動して処理結果を転送し、転送結果を処理することが記載されている。

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

画像処理装置の汎用性あるいは拡張性を考慮すると、当初からシステム内部に組み込まれたアプリケーション（内部アプリケーション）に加えて、システム外の既存のアプリケーションやサードパーティから提供されるアプリケーション（外部アプリケーション）を適宜追加可能とすることが求められるところ、これら外部アプリケーションについても内部アプリケーションと同様にその画面制御ができることが要求される。特に、内部アプリケーションについては、所定の論理的階層構造に従って複数の画面を表示するとともに、画面遷移させる際の視覚的効果を持たせる等の工夫により利用者の視認性や操作性を向上させることが行われるが、このような視覚的効果を維持しつつも外部アプリケーションの画面制御を行うことが要求され得る。

本発明の目的は、内部アプリケーションと外部アプリケーション等、異なる種類のアプリケーションが混在する場合において背景色を表示するときでも画面制御し得る画像処理装置及びプログラムを提供することにある。

請求項１に記載の発明は、フレームワーク上で動作する、第１アプリケーション及び第２アプリケーションと、前記第１アプリケーション及び前記第２アプリケーション並びに前記フレームワークを実行する制御手段とを備え、前記制御手段は、前記フレームワークを実行することにより前記第１アプリケーションの第１ウインドウを背景色とともに表示し、前記第２アプリケーションの第２ウインドウを前記第１ウインドウの下の階層に表示する場合に前記背景色を透明に設定する画像処理装置である。

請求項２に記載の発明は、前記制御手段は、前記第２アプリケーションの前記第２ウインドウを表示しない場合に前記背景色を非透明に設定する請求項１に記載の画像処理装置である。

請求項３に記載の発明は、前記制御手段は、画面にフォールト表示する場合に前記背景色を透明に設定する請求項１，２のいずれかに記載の画像処理装置である。

請求項４に記載の発明は、前記制御手段は、画面にバナー表示する場合に前記背景色を透明に設定する請求項１，２のいずれかに記載の画像処理装置である。

請求項５に記載の発明は、前記制御手段は、前記第２アプリケーションの起動の指示に応じて前記第２アプリケーションのウインドウを管理するためのダミーの管理要素を前記第１アプリケーションの前記第１ウインドウに埋め込み、前記第２アプリケ−ションの前記第２ウインドウを表示するとともに前記ダミーの管理要素を透明表示する請求項１〜４のいずれかに記載の画像処理装置である。

請求項６に記載の発明は、前記制御手段は、透明表示された前記ダミーの管理要素に対する操作を前記第２アプリケーションに対する操作として前記第２アプリケーションを実行する請求項５に記載の画像処理装置である。

請求項７に記載の発明は、前記第１アプリケーションは予め組み込まれたアプリケーションであり、前記第２アプリケーションは追加可能なアプリケーションである請求項１〜６のいずれかに記載に画像処理装置である。

請求項８に記載の発明は、前記第１アプリケーションは、基本処理を担うコアロジック部、及び描画処理を担うＵＩフレーム部に分離され、前記コアロジック部は前記フレームワークが定義するインターフェイス（Ｉ／Ｆ）を実装する請求項７に記載の画像処理装置である。

請求項９に記載の発明は、画像処理装置を制御するプロセッサに実行させるプログラムであって、前記プロセッサを、フレームワーク上で動作する第１アプリケーション及び第２アプリケーション並びに前記フレームワークを実行する制御手段として機能させ、前記フレームワークを実行することにより前記第１アプリケーションの第１ウインドウを背景色とともに表示するステップと、前記第２アプリケーションの第２ウインドウを前記第１ウインドウの下の階層に表示する場合に前記背景色を透明に設定するステップとを実行させるプログラムである。

請求項１，２，９に記載の発明によれば、第１アプリケーション及び第２アプリケーションという異種類のアプリケーションが混在する場合において背景色を表示するときでも画面制御し得る。

請求項３に記載の発明によれば、さらに、フォールト表示の場合において画面制御し得る。

請求項４に記載の発明によれば、さらに、バナー表示の場合において画面制御し得る。

請求項５に記載の発明によれば、さらに、第１アプリケーション及び第２アプリケーションをシームレスに画面制御し得る。

請求項６に記載の発明によれば、さらに、第２アプリケーションに対する利用者（ユーザ）の操作を確実に実行し得る。

請求項７，８に記載の発明によれば、さらに、予め組み込まれたアプリケーションと追加可能アプリケーションを画面制御し得る。

画像処理装置の機能ブロック図である。 システムの論理構成図である。 ホーム画面の一例を示す説明図である。 アプリケーションの論理構成図である。 従来システムの論理構成図である。 フレームワーク上のアプリケーションの構成図である。 アプリケーションの具体的構成例を示す説明図である。 アプリケーションリストの具体的構成例を示す説明図である。 コアロジックとＵＩフレームのパターンを示す説明図である。 ＵＩ及びロジック変更時の説明図である。 フレームワーク上のアプリケーションのパターンを示す説明図である。 ブータ及びスタータを含むライフサイクル管理のシステム構成図である。 ライフサイクル管理のフローチャートである。 システム起動からホーム画面が表示されるまでの時間を示すグラフ図である。 外部アプリケーション（外部アプリ）を実装した場合の論理構成図である。 外部アプリを実装した場合の他の論理構成図である。 コンパニオンアプリの構成図である。 コンパニオンアプリのマニフェスト情報説明図である。 フレームワークの構成図である。 ウインドウ管理情報の構成図である。 外部アプリの起動シーケンス図である。 外部アプリの押し出しシーケンス図である。 外部アプリの再表示シーケンス図である。 外部アプリ正常終了時のシーケンス図である。 外部アプリ異常終了時のシーケンス図である。 外部からの外部アプリ終了時のシーケンス図である。 内部ブラウザの地の色が黒の場合の階層構造説明図である。 地の色が黒の場合の内部ブラウザと外部アプリの重畳表示状態説明図である。 地の色が透明の場合の内部ブラウザと外部アプリの重畳表示状態説明図（フォールト）である。 地の色が透明の場合の内部ブラウザと外部アプリの重畳表示状態説明図（バナー）である。 フォールト表示のシーケンス図である。 バナー表示のシーケンス図である。 バナー表示における操作イベント転送説明図である。

以下、図面に基づき本発明の実施形態について説明する。

＜システム全体構成＞
図１は、本実施形態における画像処理装置を含む画像処理システムの構成ブロック図である。画像処理システムは、端末装置１０及び画像処理装置１２を備える。端末装置１０と画像処理装置１２は、通信手段１４を介して接続される。通信手段１４は、例えばＬＡＮ（ローカルエリアネットワーク）等のデータ通信ネットワークが用いられる。

端末装置１０は、通信手段１４を介して画像処理装置１２に接続され、利用者の指示に従い、文書の印刷命令を含む印刷ジョブ等を送信する。

画像処理装置１２は、ＲＯＭ１６、ＲＡＭ１８、ＨＤＤ２０、１つ又は複数のＣＰＵで構成される制御部２２、入出力インターフェイスＩ／Ｆ２４、タッチパネル等の操作部２６、画像処理部２８を備える。

１又は複数のＣＰＵで構成される制御部２２は、ＲＯＭ１６に記憶された処理プログラムに従い、入出力インターフェイスＩ／Ｆ２４を介して端末装置１０から印刷ジョブ命令等を受け付け、ＰＤＬデータを解釈して中間データを生成し、生成した中間データからさらに描画データ（ラスターデータ）を生成する。また、制御部２２は、操作部２６から受け付けたコピー（Copy）、スキャン（Scan）、ファクス(Fax)等の各種命令を実行する。

画像処理部２８は、プリントモジュール、スキャナモジュール、ファクスモジュール、用紙給紙モジュール、原稿給紙モジュール、及び画像処理アクセラレータを備える。

プリントモジュールは、画像を用紙に出力する機能を有するモジュールである。例えば、公知のインクジェット方式の構成を備え、描画データを用紙に印刷する。ノズル等から液体あるいは溶融固体インクを吐出し、紙、フィルム等に記録を行う。インクを吐出する方法には、静電誘引力を利用してインクを吐出させるドロップオンデマンド方式（圧力パルス方式）、高熱により気泡を形成・成長させることで生じる圧力を利用してインクを吐出させる熱インクジェット方式等がある。記録ヘッドは、例えば、シアンインクを吐出するヘッド、マゼンタインクを吐出するヘッド、イエローインクを吐出するヘッド、ブラックインクを吐出するヘッドを備え、各ヘッドが用紙の幅と少なくとも同等の幅を有するラインヘッドが用いられる。記録ヘッドにより各色のインク滴を中間転写体に吐出して記録し、その後に用紙に転写して印刷する。

スキャナモジュールは、用紙から画像を読み取って電子データに変換するモジュールである。

ファクス(Fax)モジュールは、モデムやファクス用画像処理モジュールを備え、ファクス機能を実行するモジュールである。

用紙給紙モジュールは、用紙トレイからプリントモジュールに用紙を搬送するモジュールである。

原稿給紙モジュールは、原稿トレイからスキャナモジュールに用紙を搬送するモジュールである。

画像処理アクセラレータは、スキャナモジュール等と連動して圧縮／伸長処理を行うモジュールである。この画像処理アクセラレータは必須ではなく、付加的モジュールとしてもよい。

なお、画像処理装置１２は、これら以外にも、用紙のパンチやソート等を行うフィニッシャ、ＵＳＢ、ＩＣカードリーダ等から構成され利用者の認証を行う認証部、課金部、人感センサや顔カメラ等を備えていてもよい。

また、画像処理装置１２は、通信手段１４を介してインターネットに接続されていてもよく、イーサネット（登録商標）やＷｉ−Ｆｉ（登録商標）を備えていてもよい。

＜プログラムの論理構成＞
図２は、制御部２２で実行されるシステムの論理構成を示す。システムは、大別して、プレゼンテーション層３０とデバイスサービス層３２の２つの層に分離される。

プレゼンテーション層３０は、各種アプリケーションを実装する層であり、フレームワーク３１と、各種アプリケーションを含む。フレームワーク３１は、コンピュータシステム上でJavaScript（登録商標）アプリケーションを動かせるようにする実行環境ソフトウェア群である。より具体的には、JavaScriptは、Ｗｅｂブラウザ上で実行され、Base FrameとUI FrameはHTMLのiframeとしてロードする。また、アプリケーションは、フレームワーク３１が提供するＩ／Ｆを実装したJavaScriptソフトウェアである。フレームワーク３１は、各種アプリケーションのライフサイクルを管理する。すなわち、フレームワーク３１は、各種アプリケーションに対して、ベースフレーム（Base Frame）を作成して各種アプリケーションのコアロジック（Core Logic）を読み込み、コアロジック(Core Logic)に対してイニシャライズ（初期化）を指示する。また、システム終了時には、各種アプリケーションのコアロジック（Core Logic）に対してファイナライズを指示し、ベースフレーム（Base Frame）を破棄する。各種アプリケーションのコアロジック（Core Logic）及びライフサイクル管理については、さらに後述する。

デバイスサービス層３２は、各種ハードウェアデバイスを管理する層であり、各種ハードウェアデバイスには、上記の画像処理部２８のプリントモジュール等が含まれる。

図３は、画像処理装置１２の操作部２６に表示される画面（ホーム画面）の一例を示す。ホーム画面には、コピー(Copy)ボタン３４，ＩＤカードコピー(ID Copy)ボタン３６、スキャン(Scan)ボタン３８、ファクス(Fax)ボタン４０、マイコピー(MyCopy)ボタン４２、ウェブアプリ(Web App1)ボタン４４，簡単コピーボタン４６の各アイコンが表示される。利用者がいずれかのボタンにタッチして選択すると、各ボタンに割り当てられたアプリケーションが起動し、アプリケーションの画面に遷移する。利用者は、各ボタンに各アプリケーションが対応していると認識し得る。

アプリケ−ションは、既述したように、フレームワーク３１が定義したＩ／Ｆを提供するJavaScriptソフトウェアであり、利用者に対して直接的に機能を提供するコンポーネントである。フレームワーク３１によって定義された共通の構成を有する。また、各アプリケーションは、他のアプリケーションとの間の結合度合いが低くなるように構成される。アプリケーションには、ユーザインターフェイス(UI)を介して利用者と協働して動作するものと、利用者と協働しないものがある。利用者と協働するアプリケーションは、主体的にプレゼンテーション層３０を通じて表示や入力を実行する。

なお、図には利用者がログインするためのログイン(Login)ボタン４８も表示されているが、このボタンにもアプリケーションが対応している。

＜アプリケーションの実装構造＞
図４は、アプリケーションの構造を示す。アプリケーション５０は、大別して、３つのコンポーネントに分離される。すなわち、コアロジック(Core Logic)５２、ＵＩフレーム(UI Frame)５４、及びマニフェストファイル(Manifest file)５６に分離される。ここで、「分離」とは、物理的に分離されることを意味するものではなく、論理的に分離されることを意味する。

コアロジック(Core Logic)５２は、アプリケーションとしての基本処理（基本的な振る舞いやアプリ間連携）を行うコンポーネントであり、各アプリケーションに必ず存在する。コアロジック(Core Logic)は、フレームワーク３１によって定義されたＩ／Ｆを提供する。

ＵＩフレーム(UI Frame)５４は、アプリケーションとして描画表示するためのコンポーネントであり、具体的には表示ウインドウとして管理される。

マニフェストファイル５６は、各アプリケーションの静的な情報のリストである。静的な情報は、アプリケーションの識別子（ＩＤ）、表示名称、アイコン画像、バージョン、作成日等である。マニフェストファイル５６には、コアロジック用マニフェストファイル５６−１と、ＵＩフレーム用マニフェストファイル５６−２がある。マニフェストファイル５６が記述する情報の一つは、isLaunchable属性である。この属性により、ホーム画面上にアイコン（ボタン）として表示されるか否かが決定され、
isLaunchable=trueで表示
isLaunchable=falseで非表示
となる。

このような構成において、コアロジック(Core Logic)５２とＵＩフレーム(UI Frame)５４との間の通信のルールは以下の通りである。
（１）コアロジック(Core Logic)５２は、他のコアロジック(Core Logic)５２と通信する。
（２）ＵＩフレーム(UI Frame)５４は、コアロジック(Core Logic)５２のみと通信する。

従って、ＵＩフレーム(UI Frame)５４は、他のＵＩフレーム(UI Frame)５４と通信することはない。

図５は、従来のプログラム構成を示す。従来においては、巨大なルートアプリケーション(RootApp)６０を用意して各アプリケーションから利用される種々の機能を提供しており、全てのアプリケーションはこのルートアプリケーション６０に依存している。また、各種のデバイス状態を専門に扱うデバイスアプリケーション(Device App)６２も別個に存在しており、ほぼ全てのアプリケーションがこのデバイスアプリケーション６２に依存している。さらに、アプリケーション間での実装共通化が進んでおり、アプリケーション間での依存関係も生じている。従って、アプリケーションを追加する場合や削除する場合でも、その都度アプリケーション間で調整が必要となり、また、ルートアプリケーション６０の修正も常に必要となることから、容易にアプリケーションの追加や削除ができない。

他方、図６は、本実施形態のプログラム構成を示す。各アプリケーションは、コアロジック(Core Logic)５２、ＵＩフレーム(UI Frame)５４、及びマニフェストファイル(Manifest file)５６に分離されており、各アプリケーションのコアロジック(Core Logic)５２がフレームワーク３１に接続され、各アプリケーションのＵＩフレーム(UI Frame)５４は当該アプリケーションのコアロジック(Core Logic)５２に接続される構成である。

例えば、コピー(Copy)アプリケーションを例にとると、コピーアプリケーションは、コアロジック(Core Logic)５２、ＵＩフレーム(UI Frame)５４、及びマニフェストファイル(Manifest file)５６に分離され、そのコアロジック(Core Logic)５２はフレームワーク３１に接続され、そのＵＩフレーム(UI Frame)５４はそのコアロジック(Core Logic)５２に接続される。各アプリケーション間の結合は限定的であって従来のように依存関係になく、各アプリケーション間の連携は、コアロジック(Core Logic)５２を介してフレームワーク３１により実行される。各アプリケーションのコアロジック(Core Logic)５２は、フレームワーク３１によって定義されたＩ／Ｆを提供するから、新たにアプリケーションを追加する場合でも、フレームワーク３１によって定義されたＩ／Ｆを提供することで容易に追加できる。また、アプリケーション間の結合も限定的であるため、アプリケーションの削除も容易である。

図７は、コピーアプリケーションの例を示す。図において、baseframe.htmlがコアロジック(Core Logic)５２であり、base_manifest.jsonがコアロジック(Core Logic)５２のマニフェストファイル５６−１である。また、uiframe.htmlがＵＩフレーム(UI Frame)５４であり、app_manifest.jsonがＵＩフレーム(UI Frame)５４のマニフェストファイル５６−２である。

図８は、アプリケーションリストの例を示す。図において、”base”がコアロジック(Core Logic)５２のマニフェストファイル５６−１を示し、”app”がＵＩフレーム(UI Frame)５４のマニフェストファイル５６−２を示す。マニフェストファイル５６−２の中の”type”は、アプリケーションの種類を示す。アプリケーションの種類については以下の通りである。
すなわち、アプリケーションには、
ＳＴＤ：標準搭載されるアプリケーション
ＯＴ：標準搭載されるアプリケーション（ＳＴＤ）のショートカット
ＥＸＴ：追加可能なアプリケーション（その１）
ＣＳ：追加可能なアプリケーション（その２）
の４つの種類がある。標準搭載されるアプリケーションは、図３に示されるコピー(Copy)やスキャン(Scan)、ファクス(Fax)等に対応するアプリケーションである。また、ＯＴ、ＥＸＴ、ＣＳの各アプリケーションには、それぞれ特別なコンパニオンアプリケーションが割り当てられ、各コンパニオンアプリケーションがそれぞれの機能を担う。各コンパニオンアプリケーションも、ＳＴＤアプリケーションと同様にコアロジック(Core Logic)５２を有する。マニフェストファイル５６にアプリケーションの種類を含めることで、各アプリケーションの内部実装を互いに区別することができる。

また、マニフェストファイル５６−２の中の”isLaunchable”は既述したように、アイコンをホーム画面上に表示するか否かを決定する属性情報である。図では、
isLaunchable=true
となっており、これはコピーのボタンを表示することを意味する。

アプリケーションは、コアロジック(Core Logic)５２とＵＩフレーム(UI frame)５４に分離されているから、アプリケーションリストは、両者の対応関係が記述されているということができる。

マニフェストファイル５６は、アプリケーション毎に作成されるから、アプリケーション毎の種別を示す識別子と、種別内で一意の識別子を設定することが望ましい。例えば、コピーアプリケーションのマニフェストファイルには、
type:STD
ID:copy
等である。typeは種別を示す識別子であり（標準搭載されるアプリケーション）、IDは一意の識別子である。

さらに、マニフェストファイル５６には、静的情報として、起動時に必要とされる情報及びホーム画面描画に必要な情報も含まれる。起動時に必要とされる情報は、コアロジック(Core Logic)５２の格納先情報及びＵＩフレーム(UI frame)５４の格納先情報であり、フレームワーク３１はコアロジック(Core Logic)５２の格納先情報を参照してコアロジック(Core Logic)５２をロードする。また、コアロジック(Core Logic)５２は、ＵＩフレーム(UI frame)５４の格納先情報を参照してＵＩフレーム(UI frame)５４を必要に応じてロードする。

ホーム画面描画に必要とされる情報は、アイコンボタン格納先情報及びボタンの表示順序である。

マニフェストファイル５６は、後述するようにデバイスサービス層のアプリケーション管理コンポ−ネントで参照され、アプリケーションリストの作成に供される。

図９は、アプリケーションの実装構造のパターンを示す。

図９（ａ）は、コアロジック(Core Logic)５２は存在するが、ＵＩフレーム(UI Frame)５４が存在しないパターンである。標準搭載されるアプリケーションではなく、コンパニオンアプリケーション等が該当する。図９（ｄ）は、図９（ａ）に対応するアプリケ−ションリストである。

図９（ｂ）は、コアロジック(Core Logic)５２及びＵＩフレーム(UI frame)５４が存在するパターンであり、それぞれ１対１に対応するパターンである。図９（ｅ）は、図９（ｂ）に対応するアプリケーションリストである。

他方、図９（ｃ）は、コアロジック(Core Logic)５２及びＵＩフレーム(UI frame)５４が存在するものの、複数のＵＩフレーム(UI Frame)５４が共通のコアロジック(Core Logic)５２を有する場合である。ＵＩフレーム(UI Frame)５４はホーム画面にボタンを表示する際の表示形態を決定するが、複数のボタンを表示する際にもそのコアロジック(Core Logic)５２を共通化することで実装が効率化される。また、複数のアプリケーションでコアロジック(Core Logic)５２を共通化することでメンテナンス性が向上する。コアロジック(Core Logic)５２を共通に持つＵＩフレーム(UI Frame)５４の数に制限はない。図９（ｆ）は、図９（ｃ）に対応するアプリケーションリストである。マニフェストファイル５６−１の具体例は、例えば、
{
"id": "appId.std.copy",
"url": "app/copy/baseframe/baseframe.html"
}
であり、マニフェストファイル５６−２の具体例は、例えば、
{
"subId": "copy",
"type": "STD",
"appUrl": "app/copy/copy/uiframe.html",
"isLaunchable": true,
"orderWeight": 100,
"largeIcon": "common/img/preset/app/app_copy_120.png",
"smallIcon": "common/img/preset/app/app_copy_48.png",
"displayName": "Copy",
"displayNameId": "001"
}
あるいは、
{
"subId": "idcopy",
"type": "STD",
"appUrl": "app/copy/idcopy/uiframe.html",
"isLaunchable": true,
"orderWeight": 900,
"largeIcon": "common/img/preset/app/app_idcardcopy_120.png",
"smallIcon": "common/img/preset/app/app_idcardcopy_48.png",
"displayName": "IDCardCopy",
"displayNameId": "002"
}
である。

なお、図９（ｂ）及び図９（ｃ）において、ＵＩフレーム(UI Frame)５４のマニフェストファイル５６−２のisLaunchable属性値を設定することで、実際にホーム画面上にボタンを表示するか否かが決定される。例えば、図９（ｃ）において、コアロジック(Core Logic)５２を共通に持つ、第１のＵＩフレーム(UI Frame)５４と第２のＵＩフレーム(UI Frame)５４が存在し、第１のＵＩフレーム(UI Frame)54のマニフェストファイルのisLaunchable=trueであるのに対し、第２のＵＩフレーム(UI Frame)５４のマニフェストファイルのisLaunchable=falseである場合、前者はボタンとして表示されるが後者は表示されない。

アプリケーションの実行構造として、コアロジック(Core Logic)５２とＵＩフレーム(UI Frame)５４を分離しているので、コアロジック(Core Logic)５２を変更することなくＵＩフレーム(UI Frame)５４のみを変更し、アプリケーションの画面上の表示形態を容易にカスタマイズすることが可能である。

図１０は、画面上の表示形態をカスタマイズする場合の例を示す。

図１０（ａ）は、当初の表示形態である。ＩＤカードコピーのアプリケーションに着目すると、そのＵＩフレーム(UI Frame)５４はidcopy/uiframe.htmlであり、そのマニフェストファイル５６−２はidcopy/app_manifest.jsonである。

図１０（ｂ）は、表示形態をカスタマイズする場合である。ＩＤコピーのアプリケーションにおいて、そのＵＩフレーム(UI frame)５４とマニフェストファイル５６−２を新しい表示形態用のidcopy_for_xxx/uiframe.htmlとidcopy_for_xxx/app_manifest.jsonに入れ替える。勿論、マニフェストファイル５６−２のみを入れ替えることも可能である。

他方、図１０（ｃ）は、表示形態ではなくアプリケーションのロジックを変更する場合である。この場合には、コアロジック(Core Logic)５２、ＵＩフレーム(UI Frame)５４、マニフェストファイル５６を全て新しいものに入れ替える。すなわち、copy以下をcopy_for_xxxに入れ替える。

図１１は、フレームワーク３１を含めた具体的なアプリケーションの実装構造のパターンを示す。

図１１（ａ）は、コピーアプリケーションとＩＤコピーアプリケーションを実装する場合のパターンの例である。コピーアプリケーションは、コアロジック(Core Logic)５２とＵＩフレーム(UI frame)５４に分離され、コアロジック(Core Logic)５２がフレームワーク３１と通信する。ＵＩフレーム(UI frame)５４はコアロジック(Core Logic)５２のみと通信する。また、ＩＤコピーも同様にコアロジック(Core Logic)５２とＵＩフレーム(UI frame)５４に分離され、コアロジック(Core Logic)５２がフレームワーク３１と通信する。ＵＩフレーム(UI frame)５４はコアロジック(Core Logic)５２のみと通信する。

図１１（ｂ）は、コピーアプリケーションとＩＤコピーアプリケーションに加え、プリントアプリケーションを実装する場合の他の例である。コピーアプリケーションとＩＤコピーアプリケーションは、共通のコアロジック(Core Logic)５２とそれぞれのＵＩフレーム(UI frame)５４に分離される。すなわち、コピーアプリケーション及びIDコピーアプリケーションは、共通のコアロジック(Core Logic)５２を介してフレームワーク３１と通信する。また、プリントアプリケーションは、コアロジック(Core Logic)５２は存在するもののＵＩフレーム(UI frame)５４はない。図１１には、図９に示す全てのパターンが含まれている。

従来のアプリケーション実装構造では、このようにコアロジック(Core Logic)５２とＵＩフレーム(UI frame)５４とが分離しておらず、処理と画面描画とが混在して分かり難い構造であった。また、アプリケーションの共通Ｉ／Ｆも存在せず、各アプリケーションはいわば勝手にＩ／Ｆを公開し、勝手にこれを参照していた。これに対し、実施形態では、フレームワーク３１がアプリケーションＩ／Ｆとして定義し、各アプリケーションのコアロジック(Core Logic)５２がこのアプリケーションＩ／Ｆを必ず実装する構造であるため、従来とはＩ／Ｆの向きが相違するといえる。また、フレームワーク３１とアプリケーション間の通信のみならず、アプリケーション間の通信Ｉ／Ｆについてもフレームワーク３１が提供するＩ／Ｆ公開機能とＩ／Ｆ参照機能で実現され得る。

なお、理論上は、複数のアプリケーションでＵＩフレーム(UI frame)５４を共通化し、コアロジック(Core Logic)５２をそれぞれ個別に設けるパターンも存在し得る。但し、この場合にはフレームワーク３１から見ると構造が複雑化するため、実施形態では特に言及していない。勿論、このことは当該パターンの排除を必ずしも意味するものではない。

＜アプリケーションのライフサイクル管理＞
図１２は、フレームワーク３１による各アプリケーションのライフサイクル管理を行う際の基本構成を示す。ここで、フレームワーク３１は、アプリケーションの実行環境である。

プレゼンテーション層に、フレームワーク３１及び各種アプリケーション５０が存在するとともに、ブータ（Booter）６０及びスタータアプリケーション６４が存在する。また、デバイスサービス層に、アプリケーション管理コンポーネント６２が存在する。

ブータ（Booter）６０は、プレゼンテーション層全体の起動終了管理を行うコンポーネントである。フレームワーク３１は、ブータ(Booter)６０により初期化され起動される。

アプリケーション管理コンポーネント６２は、各種アプリケーション５０のマニフェストファイル５６に基づきアプリケーションのリストをフレームワーク３１に提供する。

スタータアプリケーション６４は、フレームワーク３１が定義するスタータＩ／Ｆ７０を実装するアプリケーションである。このスタータアプリケーション６４は、システムで唯一つ存在するアプリケーションであり、全アプリケーション５０の初期化完了時にフレームワーク３１から呼び出される。

各種アプリケーション５０は、既述したようにコピーアプリケーションやＩＤコピーアプリケーション、ファクスアプリケーション等であり、コアロジック(Core Logic)５２を備える。各種アプリケーション５０のコアロジック(Core Logic)５２は、フレームワーク３１が定義するアプリケーションＩ／Ｆ７２を実装する。

各アプリケーション５０が実装するアプリケーションＩ／Ｆは、具体的には、
・初期化時処理(initialize)
・終了時処理(finalize)
・ウインドウ押し出し処理(windowPushedOut)
・ウインドウ露出時処理(windowPrepareExposed)
・ウインドウ削除時処理(windowPrepareTerminated)
である。各アプリケーション５０は、これらのイベントに対するハンドラを実装する。

フレームワーク３１は、各種アプリケーション５０のコアロジック(Core Logic)５２の間で、メソッドの公開／呼び出し、イベントの公開／購読／発行を可能にするためのJava Scriptコンポーネント（これを通信制御コンポーネントと称する）を備える。メソッドは任意の引数をとり、任意の戻り値を返す定義が可能である。公開したメソッドは、アプリケーション毎に独立して管理される。メソッド呼び出し側のアプリケーションは、メソッドの処理完了をコールバック呼出により確認できる。また、イベントは、各アプリケーションが任意のデータを伴って定義可能である。公開したイベントは、アプリケーション毎に独立して管理される。より詳細には、通信制御コンポーネントはコアロジック(Core Logic)５２によるメソッドの公開及び呼び出し、イベントの定義と発行及びリスナの登録を可能とし、「on」によりメソッドを公開し、「off」によりメソッドの公開を停止する。公開されたメソッドはcallにより呼び出し可能である。例えば、第１のアプリケーションがあるＩ／Ｆを「on」してフレームワーク３１に対して公開し、第２のアプリケーションが第１のアプリケーションの公開されたＩ／Ｆを対象としてフレームワーク３１に対して「call」する等である。

メソッドの公開／呼び出し、イベントの公開／購読／発行をより具体的な仕様（ＡＰＩ）で説明すると以下の通りである。

Java ScriptコンポーネントであるArena comのオブジェクトをarenaComとし、arenaCom.on(methodName,methodFunc)によりメソッドを公開する。引数methodNameは公開するメソッドの名前であり、methodFuncは公開するメソッド処理の実体である。公開さえたメソッドは、callにより呼び出すことができる。

arenaCom.off(methodName)によりメソッドの公開を停止する。methodNameは公開を停止するメソッドの名前である。

arenaCom.call(appid,methodName,args,callbacl)により公開されているメソッドを呼び出す。Appidはメソッド公開元のアプリケーションＩＤ、methodNameは呼び出す公開メソッド名、argsは引数、callbackはメソッド処理の完了時に呼び出されるコールバックである。

arenaCom.publishEvent(eventName)によりイベントを公開する。eventNameは公開するイベント名である。イベントは、公開直後からリスナ登録が可能となる。また、arenaCom.unpublishEvent(eventName)によりイベントを非公開にする。eventNameは非公開にするイベント名である。

arenaCom.addListener(appid,eventName,listenerFunction,completeCallback)により公開イベントに対してリスナを登録する。Appidはイベントを公開しているアプリケーションのＩＤ、eventNameは受信するイベントの名前、listenerFunctionはイベント発生時に呼び出される処理の実体、completeCallbackはリスナ登録の完了時に呼び出されるコールバックである。

arenaCom.fireEvent(EventName,data,completeCallback)によりイベントを発火する。EventNameは発火させるイベント名、dataはイベントに付随するデータ、completeCallbackは当該イベントに対する全リスナへの発火完了時に呼び出されるコールバックである。

arenaCom.fireEventTo(listenerid,eventName,data,completeCallback)により特定リスナに対してイベントを発火する。listeneridはイベント通知先のアプリケーションＩＤ，completeCallbackは当該イベントに対する特定リスナへの発火完了時に呼び出されるコールバックである。

図１３は、フレームワーク３１による各種アプリケーションのライフサイクル管理のフローチャートを示す。

ブータ(Booter)６０がフレームワーク３１を起動すると、フレームワーク３１は、デバイスサービス層のアプリケーション管理コンポーネント６２に対してアプリケーションリストを要求し、アプリケーション管理コンポーネント６２からアプリケーションリストを取得する。

フレームワーク３１は、アプリケーションリストを取得すると、このリストに従ってアプリケーション毎のベースフレーム（Base frame）を作成し、スタータアプリケーション６４を含む各種アプリケーション５０のロードを行う（ロードフェーズ）。すなわち、各アプリケーションのコアロジック(Core Logic)５２の読み込みを行う。具体的には、フレームワーク３１は、マニフェストファイル５６に規定されたコアロジック(Core Logic)５２の格納先情報を参照してコアロジック(Core Logic)５２をロードする。ベースフレーム(Base Frame)は、各アプリケーションのコアロジック(Core Logic)５２を実行するためのフレームであり、このフレームが表示されることはない。各アプリケーションのコアロジック(Core Logic)５２のロード順序は任意であり順不同である。全てのアプリケーションが、アプリケーションＩ／Ｆ実装を登録完了した時点で次のフェーズに移行する。

なお、アプリケーションＩ／Ｆ実装の登録処理よりも前に、各アプリケーション自身のメソッド及びイベントは公開されているものとする。

次に、フレームワーク３１は、アプリケーションＩ／Ｆを通じて、各アプリケーションにイニシャライズ（初期化）を指示する（イニシャライズフェーズ）。具体的には、フレームワーク３１は、各アプリケーションに対して”app”イベント、”initialize”メソッドを発行する。全アプリケーションが、初期化指示に対する完了時呼び出しコールバックを呼び出した時点で、フレームワーク３１はブータ(Booter)６０に対して初期化処理の完了を通知し、次のフェーズに移行する。各アプリケーションの初期化順序も任意である。この初期化処理において、各アプリケーションはデバイスサービス層に対するデータ取得を実行する。

次に、ブータ(Booter)６０は、フレームワーク３１に対してアプリケーションによる機能提供の開始指示を行い、フレームワーク３１は、これを受けてスタータアプリケーション６４に対して開始指示を行う（開始フェーズ）。スタータアプリケーション６４は、デバイスサービス層で管理されている初期起動アプリケーションの情報を取得し、初期画面を表示する。スタータアプリケーション６４が、開始指示に対する完了時呼び出しコールバックを呼び出した時点でこのフェーズが完了する。

なお、システム終了時には、フレームワーク３１は各アプリケーションのコアロジック(Core Logic)５２に対してファイナライズ（終了）を指示する。また、アプリケーション毎のベースフレーム（Base frame）を破棄する。

ロードフェーズでは、順不同で各アプリケーションのコアロジック(Core Logic)５２を読み込むので、アプリケーションを追加したとしてもこのロードフェーズを変更する必要がない。また、イニシャライズフェーズでは、全アプリケーションの初期化を行うので他のアプリケーションを呼び出すことが保証されており、個別の待ち合わせは不要である。このように、アプリケーション間の待ち合わせが無くなり、かつ、比較的小さいサイズのコアロジック(Core Logic)５２のみをロードするので、システム起動時間及びアプリケーション起動時間が短縮される。

各アプリケーションが独自にＩ／Ｆを公開している場合、アプリケーション毎に起動、初期化前処理、初期化、初期化後処理、停止、一時停止等が異なるためアプリケーション毎に初期化レベルに相違が生じ、アプリケーションを呼び出すことができるタイミングもばらついてしまう。特に、アプリケーションを呼び出す前に、相手を呼び出せる状態であるか否かを確認する必要が生じ、制御が複雑化してしまう。これに対し、実施形態では、上記のように初期化時間が短縮されるとともに、初期化後のホーム画面の起動時間も短縮され得る。

図１４は、従来及び実施形態におけるシステム起動からホーム画面が表示されるまでの時間を比較して示す。

従来においては、アプリ初期化時間は、純粋な初期化時間に加えて待ち時間を要しており、ホーム画面の起動時間も同様に純粋な起動時間に加えて待ち時間を要していたところ、実施形態では純粋な初期化時間を短縮できるとともに待ち時間を削減することもできる。ホーム起動時間についても同様である。従来においては、アプリケーション間で依存関係がある場合にはデッドロックが生じないような調整が必要であるところ、実施形態ではこのような依存関係がないためデッドロック用調整も不要化される。

以上説明したように、本実施形態では、アプリケーションをコアロジック(Core Logic)５２とＵＩフレーム(UI frame)５４に分離し、フレームワーク３１が定義するＩ／Ｆをコアロジック(Core Logic)５２が実装する構成とし、コアロジック(Core Logic)５２がフレームワーク３１を介して他のアプリケーションのコアロジック(Core Logic)５２と通信し、他方でＵＩフレーム(UI frame)５４はそのアプリケ−ションのコアロジック(Core Logic)５２のみと通信する構成とすることで、各アプリケーションは、フレームワーク３１によって定義された共通の構成を有すると同時に、他のアプリケーションとの間の結合度合いが低くなるように構成することが可能となり、追加や削除が容易化される。

次に、追加可能なアプリケーションを実装する場合について説明する。既述したように、アプリケーションには、標準搭載されるアプリケーションの他に、追加可能なアプリケーションがある。標準搭載されるアプリケーションは、フレームワーク３１が定義したＩ／Ｆを提供するソフトウェアであり、内部アプリケーションといえる。他方、追加可能なアプリケーションは、既存のアプリケーションであり得、またサードパーティから提供されるアプリケーションであり得るため、必ずしもフレームワーク３１が定義したＩ／Ｆを提供するとは限らない外部アプリケーションである。このため、後から追加可能なアプリケーション（以下では「外部アプリケーション」と称する）に対して大幅な修正を加えることなく実装することが可能で、しかも、たとえ外部アプリケーションの動作が不安定あるいは異常が生じた場合であっても、他の内部アプリケーションの動作に影響を与えないことが望ましい。

そこで、既述したように、外部アプリケーションには、外部アプリケーションの種類毎に特別なコンパニオンアプリケーションを割り当て、コンパニオンアプリケーションがフレームワーク３１と外部アプリケーションとの間に介在して外部アプリケーションを実行する。

図１５は、外部アプリケーション及びコンパニオンアプリケーションを備えるシステムの論理構成を示す。図２に対応するものである。プレゼンテーション層３０には、内部アプリケーション（内部アプリ）として、ホーム画面を表示するためのホームアプリケーション（ホームアプリ）７０、異常時の画面を制御するフォールトアプリケーション（フォールトアプリ）７２に加え、コンパニオンアプリケーション（コンパニオンアプリ）７４，７６，７８が実装される。また、外部アプリケーション（外部アプリ）として、外部アプリＡ８０、外部アプリＢ８２，外部アプリＣ８４が実装される。コンパニオンアプリ７４は外部アプリＡ８０に対応するコンパニオンアプリであり、コンパニオンアプリ７６は外部アプリＢ８２に対応するコンパニオンアプリであり、コンパニオンアプリ７８は外部アプリＣ８４に対応するコンパニオンアプリである。各コンパニオンアプリ７４，７６，７８は、フレームワーク３１と外部アプリＡ８０、外部アプリＢ８２、外部アプリＣ８４とを仲介するソフトウェアであり、フレームワーク３１が外部アプリＡ８０、外部アプリＢ８２、外部アプリＣ８４に要求する条件を吸収する機能を備える。コンパニオンアプリ７４，７６，７８は、ホーム画面上のボタンが利用者により操作されると、ホームアプリ
７０からの要求に応じて外部アプリＡ８０，Ｂ８２，Ｃ８４を起動する。コンパニオンアプリ７４，７６，７８が内部アプリとしての要求を吸収するので、外部アプリＡ８０，外部アプリＢ８２，外部アプリＣ８４を修正することなく、内部アプリとしての要件を満たし得る。

図１６は、他の論理構成を示す。外部アプリ毎にコンパニオンアプリを実装するのではなく、単一のコンパニオンアプリ７５で複数の外部アプリを管理する構成である。コンパニオンアプリ７５は外部アプリＡ８０，外部アプリＢ８２、及び外部アプリＣ８４に対応するコンパニオンアプリである。コンパニオンアプリ７５は、フレームワーク３１と外部アプリＡ８０、外部アプリＢ８２、及び外部アプリＣ８４とを仲介するソフトウェアであり、フレームワーク３１が外部アプリＡ８０、外部アプリＢ８２、及び外部アプリＣ８４に要求する条件を吸収する機能を備える。

外部アプリを起動する場合、内部アプリと同様の画面遷移及び操作性が維持されることがシステム全体をシームレスに構築する観点からは望ましい。このため、内部アプリは内部ブラウザで起動し、外部アプリは外部ブラウザで起動するように互いに異なるブラウザでそれぞれのアプリを起動するようにしてたとえ外部ブラウザに異常が生じたとしても内部ブラウザに影響を与えないようにし、フレームワーク３１が内部ブラウザのみならず外部ブラウザもまとめて管理し、より特定的には、通常のiframeベースのウインドウに加えて外部ブラウザもウインドウの一種として扱い統一的に管理する。このように、内部ブラウザと外部ブラウザをまとめて管理し、ともにウインドウとして制御することで、内部アプリと外部アプリの画面制御情報が一元化されるので、制御が簡易化される。

なお、本実施形態では、フレームワーク３１が内部ブラウザのみならず外部ブラウザもまとめて管理し、通常のiframeベースのウインドウに加えて外部ブラウザもウインドウの一種として扱い統一的に管理するが、これとは異なり、コンパニオンアプリが状況に応じて内部ブラウザと外部ブラウザの切替を行うスーパーバイザー的な機能を有するシステムとして構築することも可能である。

図１７は、コンパニオンアプリ７４の機能ブロック図を示す。コンパニオンアプリ７５，７６，７８についても同様である。

コンパニオンアプリ７４は、機能モジュールとして、外部アプリメタ情報管理部７４１と、動作条件検査部７４２と、外部アプリ起動指示部７４３と、外部アプリプロセス管理部７４４と、イベント検知部７４５を備える。

外部アプリ起動指示部７４３は、フレームワーク３１を介してホームアプリ７０に外部アプリボタン情報を提供するとともに、ユーザが外部アプリボタンを操作するとこれに応じてフレームワーク３１を介してホームアプリ７０からのlaunch指令を受信する。外部アプリ起動指示部７４３は、Launch指令を受信すると、フレームワーク３１に対してウインドウの生成及びウインドウの表示指令を提供し、外部アプリプロセス管理部７４４の情報を更新する。

外部アプリメタ情報管理部７４１は、コンパニオンアプリ７４のマニフェスト情報を記憶する。

動作条件検査部７４２は、起動指令を受けたときにその権限の有無をチェックする。

外部アプリプロセス管理部７４４は、ウインドウの生成指令で生成された外部アプリプロセスを記憶する。

イベント検知部７４５は、外部アプリ終了要求コマンドを受け付ける。

なお、コンパニオンアプリ７４は、これ以外にも、外部プロセスが異常終了したときにその通知を受け取り、外部アプリプロセス管理部７４４の管理情報を更新する異常終了検知部や、ログアウト等を検知して起動中の外部アプリを終了させてキャッシュクリアするコンテキスト変更検知部等を備えていてもよい。

図１８は、外部アプリメタ情報管理部７４１に記憶されるマニフェスト情報の一例を示す。図において、”type”はアプリケーションの種別を示し、”EXT”とあるのは外部アプリであることを示す。また、”subid”は種別内でのＩＤを示す。また、”appUrl”は、外部ブラウザが開くＵＲＬを示す。さらに、”toolsicon”と”displayName”は、ホーム画面に表示するアイコンと名前を示す。

図１９は、フレームワーク３１の機能ブロック図を示す。フレームワーク３１は、機能モジュールとして、イベント送受信部３１１、画面制御部３１２、アプリ判別部３１３、ウインドウ管理部３１４、階層管理部３１５、及びアプリケーション管理部３１６を備える。

画面制御部３１２は、全体のフローを制御する。すなわち、外部からのウインドウの生成要求の受付からその結果を返す全体の制御を行う。また、ウインドウ管理情報を生成し、ウインドウ管理部３１４に情報を追加する。

アプリ判別部３１３は、アプリの種別を用いて呼び出す関数を呼び分ける。すなわち、内部用関数か外部用関数かで呼び分ける。具体的には、アプリの種別と関数の対応関係を規定するテーブルを記憶し、このテーブルを用いて呼び分ける。

階層管理部３１５は、階層構造を管理する。階層管理部３１５は、各階層のアクティブなウインドウを管理する。階層管理部３１５は、具体的にはアプリケーション層／ポップアップ層／バナー層／アラート（低レベル）層／アラート（高レベル）層／フォールト層の順に階層構造を管理するとともに、外部アプリについて内部アプリのアプリケーション層の下にウインドウを挿入する。

ウインドウ管理部３１４は、ウインドウＩＤをキーにして各ウインドウの情報を管理する。ウインドウ情報には、内部ウインドウ情報及び外部アプリウインドウ情報が含まれる。

図２０は、ウインドウ管理部３１４で管理されるウインドウ管理情報の一例を示す。ウインドウ管理情報は、共通管理情報３１４ａと、内部ウインドウ管理情報３１４ｂあるいは外部アプリウインドウ管理情報３１４ｃから構成される。内部アプリの場合には共通管理情報３１４ａと内部ウインドウ管理情報３１４ｂから構成され、外部アプリの場合には共通管理情報３１４ａと外部アプリウインドウ管理情報３１４ｃから構成される。共通管理情報３１４ａには、ウインドウＩＤや表示状態、階層を規定する階層ｉｄが含まれる。内部ウインドウ管理情報３１４ｂには、内部ウインドウのhtmlのdiv要素やhtmlのiframe要素が含まれる。外部アプリウインドウ管理情報３１４ｃには、外部ウインドウのhtmlのdiv要素やデバイスサービス層（Ｄ層）のプロセスＩＤが含まれる。ここで、外部ウインドウのhtmlのdiv要素は、外部ウインドウを内部ウインドウに埋め込むためのdiv要素である。この外部ウインドウのhtmlのdiv要素は、透明な枠だけの空のdiv要素であり、いわばダミーのdiv要素として機能する。このダミーのdiv要素を内部アプリのiframeを扱うのと同じように画面階層に挿入することでシームレスな画面制御が可能となる。

コンパニオンアプリ７４の各機能モジュール、及びフレームワーク３１の各機能モジュールの動作について、さらに詳述する。

図２１は、ホーム画面上の外部アプリのボタンがユーザにより操作されてから、外部アプリが表示されるまでのシーケンスを示す。ユーザ、ホームアプリ７０、コンパニオンアプリ７４（あるいはコンパニオンアプリ７５，７６，７８）、フレームワーク３１、及びデバイスサービス層（デバイス層）３２の処理である。

ユーザが外部アプリボタンを押下操作すると、ホームアプリ７０は、ユーザにより押下されたボタンのlaunch指令とその付随情報をコンパニオンアプリ７４に送信する。付随情報には、外部アプリのＩＤ、すなわちマニフェスト情報のsubidが含まれる。

コンパニオンアプリ７４の外部アプリ起動指示部７４３は、ホームアプリ７０からのlaunch指令を受信し、外部アプリＩＤに基づいて外部アプリメタ情報管理部７４１から外部アプリメタ情報を取得する。また、外部アプリ起動指示部７４３は、動作条件検査部７４２に対して指定された外部アプリの起動条件が満たされているか否かをチェックするように指令する。コンパニオンアプリ７４の動作条件検査部７４２は、現在のユーザをフレームワーク３１から取得するとともに、現在のユーザが有する権限をデバイスサービス層３２の権限情報管理部から取得し、現在のユーザが指定された外部アプリを起動する権限を有しているか否かを確認する。コンパニオンアプリ７４の外部アプリ起動指示部７４３は、現在のユーザが指定された外部アプリを起動する権限を有している場合、フレームワーク３１に対してウインドウの生成指令（createWindow）を発行する。この際、外部アプリの詳細情報、具体的には外部アプリの種別とそのＩＤを提供する。

フレームワーク３１の画面制御部３１２は、コンパニオンアプリ７４からのウインドウの生成指令createWindow）を受け取ると、アプリ判別部３１３がウインドウ情報生成に用いる関数を決定する。画面制御部３１２は、アプリ判別部３１３で決定された外部アプリ用ウインドウ生成関数を実行して、ウインドウ管理情報を生成する。ウインドウ管理情報は、共通管理情報３１４ａ及び外部アプリウインドウ管理情報３１４ｃから構成される。外部アプリウインドウ管理情報３１４ｃには、既述したように内部側の埋め込み用としてのダミーのdiv要素も含まれる。画面制御部３１２は、生成したウインドウ管理情報をウインドウ管理部３１４に追加する。画面制御部３１２は、これらの管理情報に基づいてデバイスサービス層３２に対して外部アプリの起動を指令する。具体的には、外部アプリの種別及びＩＤとともに外部ブラウザの起動要求を指令する。

デバイスサービス層３２は、指定された外部アプリを起動し、そのプロセスＩＤをフレームワーク３１に返す。デバイスサービス層３２は、生成した外部アプリウインドウを非表示とし、かつ、内部ブラウザウインドウよりも下の階層に配置する。

フレームワーク３１は、プロセスＩＤを受け取ると、外部アプリのウインドウＩＤをウインドウ生成指令createWindow）の結果としてコンパニオンアプリ７４に返す。

コンパニオンアプリ７４は、次に、フレームワーク３１に対して外部アプリ表示要求(showWindow)を発行する。

フレームワーク３１の画面制御部３１２は、外部アプリ表示要求（showWindow）を受け付けると、指定されたウインドウの表示処理を開始し、同じ階層に表示されている別のウインドウがあればその別ウインドウの非表示処理を開始する（押し出し処理）。指定されたウインドウが外部アプリウインドウであれば、内部側にダミーあるいはエイリアスとして作成したdivを表示し、外部アプリウインドウを表示する。そして、階層管理部３１５に指定されたウインドウを最下位階層のウインドウとして登録する。また、画面制御部３１２は、内部ブラウザウインドウを表示するか否かを決定する。すなわち、階層管理部３１５に問い合わせて、各階層に表示されているウインドウを確認し、最下位階層以外にバナーやフォールト等のウインドウが内部側に表示されている場合には内部ブラウザを表示し、そうでない場合には内部ブラウザを非表示とする（図では、内部側をLUIと略記する）。

図２２は、押し出し処理のシーケンスを示す。

画面には、外部アプリウインドウが表示されており、ユーザがこの状態からホームキーを押下した場合を想定する。

デバイスサービス層３２は、ユーザによるホームキーの押下を検知すると、フレームワーク３１に対してホームキーの押下を提供する。

フレームワーク３１のイベント送受信部３１１は、ホームキーの押下イベントを受け付けると、ホームアプリ７０にその旨を通知する。

ホームアプリ７０は、ホームキー押下イベントを受信すると、フレームワーク３１に対して作成済みのホーム画面のウインドウＩＤを指定してウインドウ表示（showWindow）を呼ぶ。

フレームワーク３１の画面制御部３１２は、ウインドウ表示（showWindow）を受け付けると、指定されたウインドウの表示処理を開始し、同じ階層に表示されている別のウインドウがあればその別ウインドウの非表示処理を開始する。非表示になったウインドウが外部アプリウインドウであれば、内部側へのダミーあるいはエイリアスとして作成したdivを非表示とし、外部アプリウインドウを非表示とする。そして、コンパニオンアプリ７４に押し出しイベントwindowPusheOut）を通知する。この押し出しイベント通知は、言うまでもなく外部アプリウインドウが非表示になったことの通知である。これにより、ホーム画面の表示指令によって外部アプリウインドウは非表示になる。

コンパニオンアプリ７４は、押し出しイベント（windowPushedOut）を受信すると、イベント検知部７４５がこれを検知して必要な処理、具体的には内部のウインドウ状態管理を更新する。

図２３は、ユーザがホーム画面上の外部アプリボタンを押下したときに、既に起動済みの外部アプリが存在し、非表示になっていた場合のシーケンス図を示す。

ユーザがホーム画面上の外部アプリボタンを押下すると、ホームアプリ７０は、押下されたボタンのLaunch指令とその付随情報、すなわち外部アプリＩＤ（マニフェスト情報におけるsubid）をコンパニオンアプリ７４に通知する。

コンパニオンアプリ７４の外部アプリ起動指示部７４３は、Launch指令を受け取ると、外部アプリプロセス管理部７４４に指定された外部アプリが起動済みか否かを問い合わせる。指定された外部アプリが起動済みの場合、外部アプリ起動指示部７４３は、外部アプリプロセス管理部７４４から外部アプリＩＤに対応するウインドウＩＤを取得し、フレームワーク３１に対して外部アプリ表示要求（showWindow）を発行する。

フレームワーク３１の画面制御部３１２は、外部アプリ表示要求showWindow）を受け付けると、指定されたウインドウの表示処理を開始し、同じ階層に表示されている別のウインドウがあればその別ウインドウの非表示処理を開始する（押し出し処理）。指定されたウインドウが外部アプリウインドウであれば、内部側のダミーあるいはエイリアスとして作成したdivを表示し、外部アプリウインドウを表示する。そして、階層管理部３１５に指定されたウインドウを最下位階層の表示ウインドウとして登録する。また、画面制御部３１２は、内部ブラウザウインドウを表示するか否かを決定する。すなわち、階層管理部３１５に問い合わせて、各階層に表示されているウインドウを確認し、最下位階層以外にフォールトやバナー等のウインドウが表示されている場合は内部ブラウザを表示し、そうでない場合は内部ブラウザを非表示とする。

図２４は、外部アプリ正常終了時のシーケンス図であり、ユーザが外部アプリ内の終了ボタンを押下した場合のシーケンス図である。

ユーザが外部アプリの終了ボタンを押下すると、当該外部アプリはデバイスサービス層３２に対して終了要求を通知する。

デバイスサービス層３２は、外部アプリから終了要求を受け付けると、フレームワーク３１に対して終了要求を通知する。

フレームワーク３１のイベント送受信部３１１は、プロセスＩＤを含む終了要求を受け付けると、ウインドウ管理部３１４にプロセスＩＤからウインドウＩＤへの変換を指示する。そして、イベント送受信部３１１は、コンパニオンアプリ７４に対してウインドウ終了準備イベント（windowPrepareTerminated）を発行する。

コンパニオンアプリ７４のイベント検知部７４５は、フレームワーク３１からのウインドウ終了準備イベントを受信し、当該外部アプリの終了準備を行う。すなわち、ブラウザのヒストリ及びキャッシュをクリアし、認証アプリへのリスナの削除等である。イベント検知部７４５は、フレームワーク３１に対してウインドウ終了準備完了を通知する。

フレームワーク３１のイベント送受信部３１１は、コンパニオンアプリ７４からウインドウ終了準備完了通知を受信すると、デバイスサービス層３２に対してプロセス終了要求を発行し、階層管理部３１５の表示中ウインドウを削除する。また、ウインドウ管理部３１４からウインドウ情報を削除する。さらに、イベント送受信部３１１は、コンパニオンアプリ７４に対してウインドウ終了イベント（windowTerminated）を発行する。

コンパニオンアプリ７４のイベント検知部７４５は、フレームワーク３１からウインドウ終了イベントを受信すると、外部アプリプロセス管理部７４４に当該プロセスの管理情報の削除を指示し、フレームワーク３１に対して初期画面表示要求を発行する。

フレームワーク３１のアプリケーション管理部３１６は、コンパニオンアプリ７４からの初期画面表示要求を受信すると、ホームアプリ７０（初期起動アプリ）に初期画面表示要求を発行する。これにより、初期画面としてホーム画面が表示される。なお、初期画面としてホーム画面以外を設定してもよい。

図２５は、外部アプリ異常終了時のシーケンス図であり、外部アプリのプロセスがメモリ不足やセグメンテーションフォルト等の何らかの原因により異常終了する場合のシーケンス図である。なお、ユーザには動作中の外部アプリが見えている場合もあれば、押し出し処理によりバックグラウンドで存在している場合もある。

オペレーティングシステム（ＯＳ）が外部アプリの異常終了を検知すると、デバイスサービス層３２はフレームワーク３１に対して外部アプリ異常終了を通知する。

フレームワーク３１のイベント送受信部３１１は、プロセスＩＤが含まれる外部アプリ異常終了通知を受信すると、ウインドウ管理部３１４にプロセスＩＤからウインドウＩＤへの変換を指示し、外部アプリウインドウが表示中だった場合には、階層管理部３１５の表示中ウインドウを削除する。また、イベント送受信部３１１は、ウインドウ管理部からウインドウ情報を削除し、コンパニオンアプリ７４に対してウインドウ終了イベント（windowTerminated）を発行する。

コンパニオンアプリ７４のイベント検知部７４５は、フレームワーク３１からウインドウ終了イベントを受信すると、外部アプリプロセス管理部７４４に当該プロセスの管理情報の削除を指示するとともに、その他の必要な後処理を行う。さらに、イベント検知部７４５は、外部アプリが表示中だった場合には、フレームワーク３１に対して初期画面表示要求を発行する。

フレームワーク３１のアプリケーション管理部３１６は、初期画面表示要求を受信すると、ホームアプリ７０（初期起動アプリ）に初期画面表示要求を発行する。なお、外部アプリの異常終了の場合、初期画面としてのホーム画面ではなく、バナーやフォールトでエラー通知してもよい。

図２６は、外部から終了した場合のシーケンス図であり、ユーザが画像処理装置のWeb（ウェブ）UIから外部アプリ利用禁止設定をした場合のシーケンス図である。

ユーザは、WebUI上で外部アプリの利用を禁止する設定を行う。WebUIは、外部アプリ利用禁止設定をデバイスサービス層３２に通知する。

コンパニオンアプリ７４のイベント検知部７４５は、デバイスサービス層３２から外部アプリ利用設定が禁止になった旨の通知を受信すると、外部アプリプロセス管理部７４４に起動中の外部アプリが存在するか否かをチェックするように指示する。イベント検知部７４５は、起動中の外部アプリが存在し、かつ表示中の場合、フレームワーク３１に対して初期画面表示要求を発行するとともに、ウインドウ終了イベント（terminateWindow）を発行する。その引数はウインドウＩＤである。

フレームワーク３１の画面制御部３１２は、ウインドウ終了イベント（terminateWindow）を受け付け、外部アプリが表示中である場合に、階層管理部３１５の表示中ウインドウを削除し、ウインドウ管理部３１４からウインドウ情報を削除する。また、デバイスサービス層３２に対してプロセス終了要求を発行する。デバイスサービス層３２は、このプロセス終了要求に応じて外部アプリを終了する。さらに、アプリケーション管理部３１６は、コンパニオンアプリ７４からの初期画面表示要求を受信し、初期画面起動アプリとしてのホームアプリ７０に初期画面表示要求を発行する。これにより、外部アプリが終了して初期画面としてホーム画面が表示される。

ここで、画面を削除する場合等、ある画面から別の画面に遷移させる場合、地の色（背景色）がないと見栄えが良くないため、地の色を例えば黒等にして画面遷移させることが効果的である。

図２７（ａ）は、フレームワーク３１の画面制御部３１２及び階層管理部３１５で制御される内部ブラウザによるウインドウの階層構造を模式的に示す。既述したように、画面制御部３１２及び階層管理部３１５は、アプリ層／ポップアップ層／バナー層／アラート（低レベル）層／アラート（高レベル）層／フォールト層の順に階層構造を管理するが、図では簡略化のため、アプリ層及びフォールト層のみを示す。アプリ層の下に地の色（背景色）の層８８を配置し、内部ブラウザのみでウインドウを表示する場合には、この地の色を例えば黒に設定する（図のハッチング領域）。従って、アプリ層のアプリのウインドウが例えばそのウインドウの中心に収縮するように画面遷移すると、ユーザには遷移中の余白領域の色として当該地の色である黒が見える。

図２７（ｂ）は、ホーム画面においてユーザが特定のアプリボタンを押下し、特定のアプリを起動した場合の画面例を示す。ホーム画面のウインドウ９０が縮小し、これとともに特定のアプリ（図ではコピー）のウインドウ９２がホーム画面９０の上に表示される。このとき、ホーム画面及びアプリ画面の下に、地の色（黒）９４が表示される。

他方、地の色として黒を表示すると、内部ブラウザのアプリ層の下に外部アプリのウインドウを配置した場合、この地の色の黒がユーザの視点の妨げとなり、アプリ層の下の外部アプリを視認することができない事態が生じ得る。勿論、内部ブラウザを非表示とする場合には地の色も当然ながら非表示となるため外部アプリを視認することが可能であるが、アプリ層の上の階層のフォールト層やバナー層においてフォールト表示やバナー表示を行う場合には、内部ブラウザを表示することになるため地の色も表示されることとなり、地の色のために外部アプリが視認不能となってしまう。

図２８は、アプリ層の下の階層に外部アプリを配置してこれを表示状態にするとともに、フォールトやバナー表示を行うために内部ブラウザも表示状態とした場合の階層構造を示す。地の色の層８８としての黒が存在するため、ユーザからは外部アプリを見ることができない。図において、×印は視認不能であることを示す。

そこで、外部アプリを内部ブラウザの下の階層に配置して表示する場合において、内部ブラウザを表示する必要があるときに、フレームワーク３１は、地の色を通常の黒から他の色、例えば半透明や透明に変化させて、外部アプリを視認可能とする。外部アプリを表示する場合において内部ブラウザも表示する必要があるときは、具体的にはフォールト層にフォールト表示を行うとき、あるいはバナー層にバナー表示を行う時などである。

図２９（ａ）は、外部アプリを内部ブラウザの下の階層に配置して表示する場合において、フォールト表示を行う場合の階層構造を模式的に示す。フレームワーク３１は内部ブラウザを表示状態にしてフォールト表示を行うとともに、地の色の層８８を例えば透明とする。

図２９（ｂ）は、このときの画面表示を示す。地の色が透明であるため、フォールト９６（例えばドキュメントフィーダのカバーが開いている場合のメッセージ表示）を表示しても地の色の下の階層に配置されている外部アプリを視認することができる。

図３０（ａ）は、外部アプリを内部ブラウザの下の階層に配置して表示する場合において、バナー表示を行う場合の階層構造を模式的に示す。フレームワーク３１は内部ブラウザを表示状態にしてバナー表示するとともに、地の色を例えば透明とする。

図３０（ｂ）は、このときの画面表示を示す。地の色の層８８が透明であるため、バナー９８を表示しても地の色の下の階層に配置されている外部アプリを視認することができる。なお、図２９に示すフォールト表示の場合、装置自体の異常であるためユーザはアプリを操作することはできないが、図３０に示すバナー表示の場合、装置自体の異常ではないためユーザは継続して外部アプリを操作したいと欲する場合もある。この場合、内部ブラウザのアプリ層に埋め込まれたダミーの透明div要素を用いて外部アプリに対するユーザ操作を検知し得る。この点については更に後述する。

図３１は、フォールト表示を行う場合のシーケンス図を示す。外部アプリが起動されて外部アプリのウインドウが表示されている状態において、ユーザが例えば装置のインターロックを解除した場合のシーケンス図である。

ユーザがインターロックを解除（オープン）すると、デバイスサービス層３２がこれを検知し、フォールトアプリにフォールト発生のイベントを通知する。

フォールトアプリは、フォールト発生のイベントを受け付けると、フレームワーク３１に対してフォールト画面の生成（createWindow）を要求する。なお、フォールト画面は、最上位の層として要求する。また、フォールトアプリは、フレームワーク３１に対してフォールト画面の表示（showWindow）を要求する。

フレームワーク３１の画面制御部３１２は、フォールトアプリからの要求を受け付けると、内部アプリとしての通常の処理を行いウインドウを表示する。すなわち、iframeを生成し、フォールト画面のhtmlファイルをロードする。そして、フォールトアプリからの画面表示の要求に応じてiframeを表示する。このとき、画面制御部３１２は、ウインドウ管理部３１４に問い合わせ、表示すべき内部ウインドウがあるか否か、及び表示すべき外部アプリウインドウがあるか否かをチェックする。そして、チェック結果に応じて以下の表示処理を実行する。
（ａ）表示すべき内部ウインドウがなく、表示すべき外部ウインドウがある場合：
内部ブラウザを非表示とし、外部アプリウインドウを表示する
（ｂ）表示すべき内部ウインドウがあり、表示すべき外部ウインドウがある場合：
内部ブラウザを表示するとともに、地の色（背景色）を透明に設定し、外部アプリウインドウを表示する
（ｃ）表示すべき内部ウインドウがあり、表示すべき外部アプリウインドウがない場合：
内部ブラウザを表示し、外部アプリウインドウは表示しない
（ｄ）表示すべき内部ウインドウがなく、表示すべき外部アプリウインドウもない場合：
内部ブラウザを表示し、外部アプリウインドウは表示しない

図において、上記の（ｂ）の場合が相当するとして画面制御部３１２は地の色を透明に設定している。地の色を透明にすることで、内部ブラウザを表示していても、その下の階層の外部アプリウインドウを表示してユーザに視認させ得る。

なお、上記の（ｃ）の場合において、内部ブラウザを表示しても地の色を透明にせず黒のままとしているのは、表示すべき外部アプリウインドウがないため地の色を透明化する必要がないからである。（ｂ）から（ｃ）の状態に遷移した場合も、地の色を透明から元の黒に変更することは言うまでもない。

バナー表示を行う場合のシーケンス図も、図３１に示すフォールト表示を行う場合のシーケンス図と同様である。但し、バナー表示を行う場合、ユーザはバナー表示で隠されていない部分の外部アプリを操作したいと欲する場合がある。

図３２は、バナー表示を行っている状態でのシーケンス図である。外部アプリが起動されて外部アプリのウインドウが表示され、かつバナー表示されている状態において、ユーザがバナー表示以外の外部アプリ部分を操作する場合のシーケンス図である。

ユーザがバナー表示以外の部分であって外部アプリが見えている部分について操作を行うと、フレームワーク３１のイベント送受信部３１１は外部アプリウインドウ領域に対応する透明div要素を用いてユーザの操作イベントを受け付けると、デバイスサービス層３２に対して当該操作イベントの転送を要求する。

デバイスサービス層３２は、フレームワーク３１からの転送要求に応じて、外部アプリに対して当該操作イベントを転送する。これにより、外部アプリは、ユーザの操作を受け付けて操作に応じた処理を実行する。バナー表示の部分は、透明div要素よりも上の階層に配置されているので、透明div要素を介して外部アプリに操作イベントが転送されることはない。ダミーとしての透明div要素は、内部アプリウインドウと外部アプリウインドウをシームレスに管理・制御する機能を有するとともに、外部アプリにバナーを重畳表示した場合にもバナー表示で隠れていない部分での外部アプリの操作を可能とする機能を有するといえる。

図３３は、バナー表示におけるユーザ操作イベントの転送処理を模式的に示す。バナー表示されていても、ユーザには透明div要素及び透明の地の色の層８８を通して外部アプリが視認できる。ユーザが画面を操作すると、当該操作は透明div要素に対する操作として検知され、フレームワーク３１はデバイスサービス層３２を介して外部アプリに当該操作イベントを転送する。ユーザは、透明div要素及び透明の地の色の層８８を介して外部アプリを操作しているといえる。

本実施形態における「コンポーネント」とは、論理的に分離可能なソフトウェアの部品を意味する。コンポーネントは１つ又は複数のプロセッサによって実行され得る。本実施形態では、JavaScriptを用いているが、勿論これ以外のプログラミング言語を用いることもできる。

また、本発明は上記の実施形態に限定されるものではなく、種々の変形例が可能である。以下に、変形例について説明する。

＜変形例１＞
実施形態では、画像処理装置１２の制御部（プロセッサ）２２が、プレゼンテーション層３０のフレームワーク３１及び各種アプリケーション５０を実行するものとしているが、図２に示すように、プレゼンテーション層３０とデバイスサービス層３２は分離しているから、プレゼンテーション層３０のフレームワーク及び各種アプリケーション５０を画像処理装置１２と異なる別個の装置、例えば画像処理装置１２を制御するためのスマートフォンやタブレット端末等の携帯端末のプロセッサが実行する構成としてもよい。また、図１における操作部２６も携帯端末に搭載されることが望ましい。この場合、携帯端末と画像処理装置１２とを併せて画像処理装置ないし画像処理システムということができる。

＜変形例２＞
実施形態では、画面遷移の視覚的効果を考慮して地の色（背景色）を黒等の非透明にし、外部アプリウインドウを表示するとともにフォールト表示やバナー表示の場合に地の色を透明（半透明を含む）に設定しているが、表示すべきフォールトやバナーの種類に応じて地の色を変化させてもよい。例えば、フォールト表示の場合には地の色を半透明とし、バナー表示の場合には地の色を透明とする、あるいはフォールト表示の場合には地の色をグレーとする、あるいは特定のバナー表示の場合には地の色をグレーとし、その他のバナー表示の場合には地の色を透明とする等である。地の色を透明にするのは、フォールト表示やバナー表示にもかかわらず外部アプリウインドウをユーザに視認させることが目的であるから、外部アプリを視認させる必要がある場合のみ地の色を透明に設定し得る。

＜変形例３＞
実施形態では、フレームワーク３１が定義したＩ／Ｆを提供するシステムに標準実装されたアプリケーションを内部アプリケーション（内部アプリ）とし、追加可能なアプリケーションであって、既存のアプリケーションあるいはサードパーティから提供されるアプリケーションでありフレームワーク３１が定義したＩ／Ｆを提供するとは限らないアプリケーションを外部アプリケーション（外部アプリ）と定義しているが、これに限らず、互いに異なる種類の第１アプリと第２アプリを実装するシステムに広く適用し得る。例えば、システムに予め組み込まれた標準的なアプリ等を第１アプリ、これ以外の追加可能なアプリ等を第２アプリとし、第１アプリのウインドウ（第１ウインドウ）を背景色とともに表示する場合であって、第１アプリの第１ウインドウの下の階層に第２アプリのウインドウ（第２ウインドウ）を表示するときに、背景色を透明（半透明を含む）に設定することができる。

１０ 端末装置、１２ 画像処理装置、１６ ＲＯＭ、１８ ＲＡＭ、２０ ＨＤＤ、２４ 入出力インターフェイスＩ／Ｆ、２６ 操作部、２８ 画像処理部、３０ プレゼンテーション層、３１ フレームワーク、３２ デバイスサービス層、５０ アプリケーション、５２ コアロジック(Core Logic)、５４ ＵＩフレーム(UI frame)、５６ マニフェストファイル、７４，７５，７６，７８ コンパニオンアプリ、８８ 地の色（背景色）の層。

Claims (9)

1. フレームワーク上で動作する、第１アプリケーション及び第２アプリケーションと、
   前記第１アプリケーション及び前記第２アプリケーション並びに前記フレームワークを実行する制御手段と、
   を備え、前記制御手段は、前記フレームワークを実行することにより前記第１アプリケーションの第１ウインドウを背景色とともに表示し、前記第２アプリケーションの第２ウインドウを前記第１ウインドウの下の階層に表示する場合に前記背景色を透明に設定する
   画像処理装置。
2. 前記制御手段は、前記第２アプリケーションの前記第２ウインドウを表示しない場合に前記背景色を非透明に設定する
   請求項１に記載の画像処理装置。
3. 前記制御手段は、画面にフォールト表示する場合に前記背景色を透明に設定する
   請求項１，２のいずれかに記載の画像処理装置。
4. 前記制御手段は、画面にバナー表示する場合に前記背景色を透明に設定する
   請求項１，２のいずれかに記載の画像処理装置。
5. 前記制御手段は、前記第２アプリケーションの起動の指示に応じて前記第２アプリケーションのウインドウを管理するためのダミーの管理要素を前記第１アプリケーションの前記第１ウインドウに埋め込み、前記第２アプリケ−ションの前記第２ウインドウを表示するとともに前記ダミーの管理要素を透明表示する
   請求項１〜４のいずれかに記載の画像処理装置。
6. 前記制御手段は、透明表示された前記ダミーの管理要素に対する操作を前記第２アプリケーションに対する操作として前記第２アプリケーションを実行する
   請求項５に記載の画像処理装置。
7. 前記第１アプリケーションは予め組み込まれたアプリケーションであり、前記第２アプリケーションは追加可能なアプリケーションである
   請求項１〜６のいずれかに記載に画像処理装置。
8. 前記第１アプリケーションは、基本処理を担うコアロジック部、及び描画処理を担うＵＩフレーム部に分離され、前記コアロジック部は前記フレームワークが定義するインターフェイス（Ｉ／Ｆ）を実装する
   請求項７に記載の画像処理装置。
9. 画像処理装置を制御するプロセッサに実行させるプログラムであって、
   前記プロセッサを、フレームワーク上で動作する第１アプリケーション及び第２アプリケーション並びに前記フレームワークを実行する制御手段として機能させ、
   前記フレームワークを実行することにより前記第１アプリケーションの第１ウインドウを背景色とともに表示するステップと、
   前記第２アプリケーションの第２ウインドウを前記第１ウインドウの下の階層に表示する場合に前記背景色を透明に設定するステップと、
   を実行させるプログラム。

Images