特許第6911405号(P6911405)IP Force 特許公報掲載プロジェクト 2022.1.31 β版

ホーム > 特許ランキング > 富士フイルムビジネスイノベーション株式会社

このエントリーをはてなブックマークに追加

知財求人 - 知財ポータルサイト「IP Force」

▶ 富士ゼロックス株式会社の特許一覧

(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】6911405
(24)【登録日】2021年7月12日
(45)【発行日】2021年7月28日
(54)【発明の名称】画像処理装置及びプログラム
(51)【国際特許分類】
   G06F 8/00 20180101AFI20210715BHJP
【ＦＩ】
   G06F8/00
【請求項の数】11
【全頁数】31
(21)【出願番号】特願2017-46673(P2017-46673)
(22)【出願日】2017年3月10日
(65)【公開番号】特開2018-55668(P2018-55668A)
(43)【公開日】2018年4月5日
【審査請求日】2020年1月21日
(31)【優先権主張番号】特願2016-187292(P2016-187292)
(32)【優先日】2016年9月26日
(33)【優先権主張国】JP
(73)【特許権者】
【識別番号】000005496
【氏名又は名称】富士フイルムビジネスイノベーション株式会社
(74)【代理人】
【識別番号】110001210
【氏名又は名称】特許業務法人ＹＫＩ国際特許事務所
(72)【発明者】
【氏名】遠藤 康裕
(72)【発明者】
【氏名】佐竹 雅紀
(72)【発明者】
【氏名】森田 雅夫
(72)【発明者】
【氏名】道村 唯夫
【審査官】 金田 孝之
(56)【参考文献】
【文献】 米国特許出願公開第２０１２／００９６３９２（ＵＳ，Ａ１）
【文献】 米国特許出願公開第２０１２／０１１０５４７（ＵＳ，Ａ１）
【文献】 特開２０１６−０１９１４５（ＪＰ，Ａ）
【文献】 特開２００２−１１１８０５（ＪＰ，Ａ）
(58)【調査した分野】（Int.Cl.，ＤＢ名）
Ｇ０６Ｆ ８／００ − ８／３８
Ｇ０６Ｆ ８／６０ − ８／７７
Ｇ０６Ｆ ９／４４ − ９／４４５
Ｇ０６Ｆ ９／４５１−
(57)【特許請求の範囲】
【請求項1】
基本処理を担うコアロジック部、及び描画処理を担うＵＩフレーム部に分離され、フレームワーク上で動作するアプリケーションと、
前記アプリケーション及び前記フレームワークを実行する制御手段と、
を備え、前記コアロジック部は前記フレームワークが定義するインターフェイス（Ｉ／Ｆ）を実装し、かつ、他のアプリケーションのコアロジック部との通信に用いられるメソッド及びイベントを公開し、既公開のメソッド及びイベントの公開を停止する、
画像処理装置。
【請求項2】
前記コアロジック部は、既公開のメソッドの呼び出し、既公開のイベントのリスナ登録、イベントの発火の少なくともいずれかを実行する、
請求項１に記載の画像処理装置。
【請求項3】
画像処理装置を制御するプロセッサに実行させるプログラムであって、
基本処理を担うコアロジック部と、描画処理を担うＵＩフレーム部に分離されており、前記コアロジック部は、フレームワークが定義するインターフェイス（Ｉ／Ｆ）を実装し、システム起動時に前記フレームワークによりロードされ、他のアプリケーションのコアロジック部との通信に用いられるメソッド及びイベントを公開し、既公開のメソッド及びイベントの公開を停止する、
プログラム。
【請求項4】
外部アプリケーションと、
前記フレームワークと前記外部アプリケーションとの間に介在するコンパニオンアプリケーションと、
デバイスサービス層と、
をさらに備え、
前記コンパニオンアプリケーションは、利用者からの指示に応じて前記フレームワークに対してウインドウの生成指令を発行し、
前記フレームワークは、前記デバイスサービス層に対して前記外部アプリケーションの起動を指令し、
前記デバイスサービス層は、前記外部アプリケーションの起動の指令に応じて前記外部アプリケーションを起動し、
前記フレームワークは、前記外部アプリケーションのウインドウを前記アプリケーションのウインドウよりも下の階層に配置して表示する、
請求項１に記載の画像処理装置。
【請求項5】
前記フレームワークは、前記外部アプリケーションのウインドウを前記アプリケーションのウインドウよりも下の階層に配置して一旦非表示とし、前記コンパニオンアプリケーションからの外部アプリケーションの表示の指示に応じて前記アプリケーションのウインドウを非表示とするとともに前記外部アプリケーションのウインドウを表示する
請求項４に記載の画像処理装置。
【請求項6】
前記フレームワークは、バナーあるいはフォールトを表示する場合には前記コンパニオンアプリケーションからの外部アプリケーションの表示の指示に応じて前記アプリケーションのウインドウを表示とする
請求項５に記載の画像処理装置。
【請求項7】
前記フレームワークは、前記外部アプリケーションのウインドウを管理するためのダミーの管理要素を前記アプリケーションのウインドウに埋め込み、前記外部アプリケーションのウインドウを表示するとともに前記ダミーの管理要素を透明表示する
請求項４〜６のいずれかに記載の画像処理装置。
【請求項8】
前記フレームワークは、透明表示された前記ダミーの管理要素に対する操作を前記外部アプリケーションに対する操作として前記外部アプリケーションを操作する
請求項７に記載の画像処理装置。
【請求項9】
前記フレームワークは、利用者からの前記外部アプリケーションの終了指示に応じて前記コンパニオンアプリケーションに対して外部アプリケーションの終了を指示し、
前記コンパニオンアプリケーションは、前記外部アプリケーションの終了の指示に応じて前記外部アプリケーションの管理情報を削除し、前記フレームワークに対して初期画面表示を指示し、
前記フレームワークは、前記初期画面表示の指示に応じて前記外部アプリケーションに代えて初期画面を表示する
請求項４に記載の画像処理装置。
【請求項10】
前記フレームワークは、前記外部アプリケーションが異常終了した場合に前記コンパニオンアプリケーションに対して外部アプリケーションの終了を指示し、
前記コンパニオンアプリケーションは、前記外部アプリケーションの終了の指示に応じて前記外部アプリケーションの管理情報を削除し、前記フレームワークに対して初期画面表示を指示し、
前記フレームワークは、前記初期画面表示の指示に応じて前記外部アプリケーションに代えて初期画面を表示する
請求項４に記載の画像処理装置。
【請求項11】
前記フレームワークは、前記外部アプリケーションのウインドウが表示されている場合において、利用者からの操作に応じてホーム画面を表示したときに、前記外部アプリケーションのウインドウを非表示とするとともに前記コンパニオンアプリケーションに対して前記外部アプリケーションのウインドウの非表示を通知し、
前記コンパニオンアプリケーションは、前記外部アプリケーションのウインドウの非表示の通知に応じて前記外部アプリケーションの管理情報を更新する
請求項４に記載の画像処理装置。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、画像処理装置及びプログラムに関する。
【背景技術】
【0002】
コピー、プリンタ、ファクス等の機能を備える複合機は、さらに多機能化しており、各種のアプリケーション（アプリ）を含む全体システムを効率的に構築することが要求されている。
【0003】
特許文献１には、アプリ一覧画面に表示されるアイコンのアプリが実行中であるか否かを、ユーザが容易に把握できるようにする画像処理装置が記載されている。アプリケーション及びアプリケーションの動作設定を登録したマクロを呼び出すためのアイコンに対し、アイコンの位置、アイコン画像、アプリケーションの識別情報、マクロの識別情報を含む一覧画面情報を記憶する画面情報記憶手段と、ジョブの状態が待機から実行に変化したアプリケーションの状態情報を取得し、識別情報を出力するとともに画面更新要求を行う画面制御手段と、一覧画面情報に基づき作成したアプリケーションの一覧画面に対して画面更新要求を受けた場合、取得された識別情報が示すアプリケーションのアイコンの表示形態を、他のアプリケーションのアイコンとは異なる表示形態に更新する画面作成手段と、更新されたアイコンを含む一覧画面を表示する表示手段を備えることが記載されている。
【0004】
特許文献２には、多機能化する複合機において、ユーザの操作性を向上させることが記載されている。標準アプリケーションと、拡張アプリケーションと、標準及び拡張アプリケーションを識別するアプリ識別情報を、それぞれのアイコンの座標情報及びアイコンの画像情報に対応付けたアイコン配置情報を記憶する配置情報記憶手段と、アイコン配置情報に基づき、標準及び拡張アプリケーションに対応するアイコンが表示されるアプリ一覧画面を作成する一覧画面作成手段と、作成された前記アプリ一覧作成画面を表示する表示手段と、押下されたアイコンに対応する標準又は拡張アプリケーションをアイコン配置情報から特定し、特定された標準又は拡張アプリケーションに対し、操作画面の表示要求を行う画面制御手段を備えることが記載されている。
【先行技術文献】
【特許文献】
【0005】
【特許文献1】特開２０１２−２４８１０２号公報
【特許文献2】特開２０１２−２７６６２号公報
【発明の概要】
【発明が解決しようとする課題】
【0006】
ところで、従来においては、画像処理装置のシステムとして、巨大なルートアプリケーションを用意して各アプリケーションから利用される種々の機能を提供しており、全てのアプリケーションはこのルートアプリケーションに依存している。
【0007】
また、画像処理装置の各種のデバイス状態を専門に扱うデバイスアプリケーションも別個に存在しており、ほぼ全てのアプリケーションがこのデバイスアプリケーションに依存している。
【0008】
さらに、アプリケーション間での実装共通化が進んでおり、アプリケーション間での依存関係も生じている。
【0009】
従って、アプリケーションを追加する場合や削除する場合でも、その都度アプリケーション間で調整が必要となり、これと同時に、ルートアプリケーションの修正も常に必要となることから、容易にアプリケーションの追加や削除ができない問題があった。
【0010】
本発明の目的は、アプリケーション相互の依存関係を抑制し、アプリケーションの追加や削除を容易化し得る画像処理装置及びプログラムを提供することにある。
【課題を解決するための手段】
【0011】
請求項１に記載の発明は、基本処理を担うコアロジック部、及び描画処理を担うＵＩフレーム部に分離され、フレームワーク上で動作するアプリケーションと、前記アプリケーション及び前記フレームワークを実行する制御手段と、を備え、前記コアロジック部は前記フレームワークが定義するインターフェイス（Ｉ／Ｆ）を実装し、かつ、他のアプリケーションのコアロジック部との通信に用いられるメソッド及びイベントを公開し、既公開のメソッド及びイベントの公開を停止する、画像処理装置である。
【0013】
請求項２に記載の発明は、コアロジック部は、既公開のメソッドの呼び出し、既公開のイベントのリスナ登録、イベントの発火の少なくともいずれかを実行する、請求項１に記載の画像処理装置である。
【0014】
請求項３に記載の発明は、画像処理装置を制御するプロセッサに実行させるプログラムであって、基本処理を担うコアロジック部と、描画処理を担うＵＩフレーム部に分離されており、前記コアロジック部は、フレームワークが定義するインターフェイス（Ｉ／Ｆ）を実装し、システム起動時に前記フレームワークによりロードされ、他のアプリケーションのコアロジック部との通信に用いられるメソッド及びイベントを公開し、既公開のメソッド及びイベントの公開を停止する、プログラムである。
【0015】
請求項４に記載の発明は、外部アプリケーションと、前記フレームワークと前記外部アプリケーションとの間に介在するコンパニオンアプリケーションと、デバイスサービス層と、をさらに備え、前記コンパニオンアプリケーションは、利用者からの指示に応じて前記フレームワークに対してウインドウの生成指令を発行し、前記フレームワークは、前記デバイスサービス層に対して前記外部アプリケーションの起動を指令し、前記デバイスサービス層は、前記外部アプリケーションの起動の指令に応じて前記外部アプリケーションを起動し、前記フレームワークは、前記外部アプリケーションのウインドウを前記アプリケーションのウインドウよりも下の階層に配置して表示する、請求項１に記載の画像処理装置である。
【0016】
請求項５に記載の発明は、前記フレームワークは、前記外部アプリケーションの起動の指示に応じて前記外部アプリケーションのウインドウを前記アプリケーションのウインドウよりも下の階層に配置して一旦非表示とし、前記コンパニオンアプリケーションからの外部アプリケーションの表示の指示に応じて前記アプリケーションのウインドウを非表示とするとともに前記外部アプリケーションのウインドウを表示する請求項４に記載の画像処理装置である。
【0017】
請求項６に記載の発明は、前記フレームワークは、バナーあるいはフォールトを表示する場合には前記コンパニオンアプリケーションからの外部アプリケーションの表示の指示に応じて前記アプリケーションのウインドウを表示とする請求項５に記載の画像処理装置である。
【0018】
請求項７に記載の発明は、前記フレームワークは、前記外部アプリケーションの起動の指示に応じて前記外部アプリケーションのウインドウを管理するためのダミーの管理要素を前記アプリケーションのウインドウに埋め込み、前記外部アプリケーションのウインドウを表示するとともに前記ダミーの管理要素を透明表示する請求項４〜６のいずれかに記載の画像処理装置である。
【0019】
請求項８に記載の発明は、前記フレームワークは、透明表示された前記ダミーの管理要素に対する操作を前記外部アプリケーションに対する操作として前記外部アプリケーションを操作する請求項７に記載の画像処理装置である。
【0020】
請求項９に記載の発明は、前記フレームワークは、利用者からの前記外部アプリケーションの終了指示に応じて前記コンパニオンアプリケーションに対して外部アプリケーションの終了を指示し、前記コンパニオンアプリケーションは、前記外部アプリケーションの終了の指示に応じて前記外部アプリケーションの管理情報を削除し、前記フレームワークに対して初期画面表示を指示し、前記フレームワークは、前記初期画面表示の指示に応じて前記外部アプリケーションに代えて初期画面を表示する請求項４に記載の画像処理装置である。
【0021】
請求項１０に記載の発明は、前記フレームワークは、前記外部アプリケーションが異常終了した場合に前記コンパニオンアプリケーションに対して外部アプリケーションの終了を指示し、前記コンパニオンアプリケーションは、前記外部アプリケーションの終了の指示に応じて前記外部アプリケーションの管理情報を削除し、前記フレームワークに対して初期画面表示を指示し、前記フレームワークは、前記初期画面表示の指示に応じて前記外部アプリケーションに代えて初期画面を表示する請求項４に記載の画像処理装置である。
【0022】
請求項１１に記載の発明は、前記フレームワークは、前記外部アプリケーションのウインドウが表示されている場合において、利用者からの操作に応じてホーム画面を表示したときに、前記外部アプリケーションのウインドウを非表示とするとともに前記コンパニオンアプリケーションに対して前記外部アプリケーションのウインドウの非表示を通知し、前記コンパニオンアプリケーションは、前記外部アプリケーションのウインドウの非表示の通知に応じて前記外部アプリケーションの管理情報を更新する請求項４に記載の画像処理装置である。
【発明の効果】
【0023】
請求項１，３に記載の発明によれば、アプリケーション相互の依存関係を抑制し、アプリケーションの追加や削除を容易化できるとともに、アプリケーション間の通信を可能にできる。
【0024】
請求項１，３に記載の発明によれば、一旦公開したメソッド及びイベントもその後に公開停止とすることができる。
【0025】
請求項２に記載の発明によれば、アプリケーション間で既公開のメソッドの呼び出し、既公開のイベントのリスナ登録、イベントの発火が可能となる。
【0026】
請求項４，５に記載の発明によれば、さらに、外部アプリケーションを追加した場合においても、フレームワークにより外部アプリケーションの起動を制御できる。
【0027】
請求項６に記載の発明によれば、さらに、外部アプリケーションにバナーあるいはフォールトを重畳表示できる。
【0028】
請求項７に記載の発明によれば、さらに、外部アプリケーションも通常のアプリケーションと同様に制御できる。
【0029】
請求項８に記載の発明によれば、さらに、バナー等が重畳表示された状態においても外部アプリケーションの操作が可能となる。
【0030】
請求項９，１０に記載の発明によれば、さらに、フレームワークにより外部アプリケーションの終了を制御できる。
【0031】
請求項１１に記載の発明によれば、さらに、フレームワークにより外部アプリケーションに代えたホーム画面の表示とその管理を制御できる。
【図面の簡単な説明】
【0032】
【図1】画像処理装置の機能ブロック図である。
【図2】システムの論理構成図である。
【図3】ホーム画面の一例を示す説明図である。
【図4】アプリケーションの論理構成図である。
【図5】従来システムの論理構成図である。
【図6】フレームワーク上のアプリケーションの構成図である。
【図7】アプリケーションの具体的構成例を示す説明図である。
【図8】アプリケーションリストの具体的構成例を示す説明図である。
【図9】コアロジックとＵＩフレームのパターンを示す説明図である。
【図10】ＵＩ及びロジック変更時の説明図である。
【図11】フレームワーク上のアプリケーションのパターンを示す説明図である。
【図12】ブータ及びスタータを含むライフサイクル管理のシステム構成図である。
【図13】ライフサイクル管理のフローチャートである。
【図14】システム起動からホーム画面が表示されるまでの時間を示すグラフ図である。
【図15】外部アプリケーション（外部アプリ）を実装した場合の論理構成図である。
【図16】外部アプリを実装した場合の他の論理構成図である。
【図17】コンパニオンアプリの構成図である。
【図18】コンパニオンアプリのマニフェスト情報説明図である。
【図19】フレームワークの構成図である。
【図20】ウインドウ管理情報の構成図である。
【図21】外部アプリの起動シーケンス図である。
【図22】外部アプリの押し出しシーケンス図である。
【図23】外部アプリの再表示シーケンス図である。
【図24】外部アプリ正常終了時のシーケンス図である。
【図25】外部アプリ異常終了時のシーケンス図である。
【図26】外部からの外部アプリ終了時のシーケンス図である。
【図27】内部ブラウザと外部アプリの階層構造説明図である。
【図28】外部アプリとバナーの重畳表示状態説明図である。
【発明を実施するための形態】
【0033】
以下、図面に基づき本発明の実施形態について説明する。
【0034】
＜システム全体構成＞
図１は、本実施形態における画像処理装置を含む画像処理システムの構成ブロック図である。画像処理システムは、端末装置１０及び画像処理装置１２を備える。端末装置１０と画像処理装置１２は、通信手段１４を介して接続される。通信手段１４は、例えばＬＡＮ（ローカルエリアネットワーク）等のデータ通信ネットワークが用いられる。
【0035】
端末装置１０は、通信手段１４を介して画像処理装置１２に接続され、利用者の指示に従い、文書の印刷命令を含む印刷ジョブ等を送信する。
【0036】
画像処理装置１２は、ＲＯＭ１６、ＲＡＭ１８、ＨＤＤ２０、１つ又は複数のＣＰＵで構成される制御部２２、入出力インターフェイスＩ／Ｆ２４、タッチパネル等の操作部２６、画像処理部２８を備える。
【0037】
１又は複数のＣＰＵで構成される制御部２２は、ＲＯＭ１６に記憶された処理プログラムに従い、入出力インターフェイスＩ／Ｆ２４を介して端末装置１０から印刷ジョブ命令等を受け付け、ＰＤＬデータを解釈して中間データを生成し、生成した中間データからさらに描画データ（ラスターデータ）を生成する。また、制御部２２は、操作部２６から受け付けたコピー（Copy）、スキャン（Scan）、ファクス(Fax)等の各種命令を実行する。
【0038】
画像処理部２８は、プリントモジュール、スキャナモジュール、ファクスモジュール、用紙給紙モジュール、原稿給紙モジュール、及び画像処理アクセラレータを備える。
【0039】
プリントモジュールは、画像を用紙に出力する機能を有するモジュールである。例えば、公知のインクジェット方式の構成を備え、描画データを用紙に印刷する。ノズル等から液体あるいは溶融固体インクを吐出し、紙、フィルム等に記録を行う。インクを吐出する方法には、静電誘引力を利用してインクを吐出させるドロップオンデマンド方式（圧力パルス方式）、高熱により気泡を形成・成長させることで生じる圧力を利用してインクを吐出させる熱インクジェット方式等がある。記録ヘッドは、例えば、シアンインクを吐出するヘッド、マゼンタインクを吐出するヘッド、イエローインクを吐出するヘッド、ブラックインクを吐出するヘッドを備え、各ヘッドが用紙の幅と少なくとも同等の幅を有するラインヘッドが用いられる。記録ヘッドにより各色のインク滴を中間転写体に吐出して記録し、その後に用紙に転写して印刷する。
【0040】
スキャナモジュールは、用紙から画像を読み取って電子データに変換するモジュールである。
【0041】
ファクス(Fax)モジュールは、モデムやファクス用画像処理モジュールを備え、ファクス機能を実行するモジュールである。
【0042】
用紙給紙モジュールは、用紙トレイからプリントモジュールに用紙を搬送するモジュールである。
【0043】
原稿給紙モジュールは、原稿トレイからスキャナモジュールに用紙を搬送するモジュールである。
【0044】
画像処理アクセラレータは、スキャナモジュール等と連動して圧縮／伸長処理を行うモジュールである。この画像処理アクセラレータは必須ではなく、付加的モジュールとしてもよい。
【0045】
なお、画像処理装置１２は、これら以外にも、用紙のパンチやソート等を行うフィニッシャ、ＵＳＢ、ＩＣカードリーダ等から構成され利用者の認証を行う認証部、課金部、人感センサや顔カメラ等を備えていてもよい。
【0046】
また、画像処理装置１２は、通信手段１４を介してインターネットに接続されていてもよく、イーサネット（登録商標）やＷｉ−Ｆｉ（登録商標）を備えていてもよい。
【0047】
＜プログラムの論理構成＞
図２は、制御部２２で実行されるシステムの論理構成を示す。システムは、大別して、プレゼンテーション層３０とデバイスサービス層３２の２つの層に分離される。
【0048】
プレゼンテーション層３０は、各種アプリケーションを実装する層であり、フレームワーク３１と、各種アプリケーションを含む。フレームワーク３１は、コンピュータシステム上でJavaScript（登録商標）アプリケーションを動かせるようにする実行環境ソフトウェア群である。より具体的には、JavaScriptは、Ｗｅｂブラウザ上で実行され、Base FrameとUI FrameはHTMLのiframeとしてロードする。また、アプリケーションは、フレームワーク３１が提供するＩ／Ｆを実装したJavaScriptソフトウェアである。フレームワーク３１は、各種アプリケーションのライフサイクルを管理する。すなわち、フレームワーク３１は、各種アプリケーションに対して、ベースフレーム（Base Frame）を作成して各種アプリケーションのコアロジック（Core Logic）を読み込み、コアロジック(Core Logic)に対してイニシャライズ（初期化）を指示する。また、システム終了時には、各種アプリケーションのコアロジック（Core Logic）に対してファイナライズを指示し、ベースフレーム（Base Frame）を破棄する。各種アプリケーションのコアロジック（Core Logic）及びライフサイクル管理については、さらに後述する。
【0049】
デバイスサービス層３２は、各種ハードウェアデバイスを管理する層であり、各種ハードウェアデバイスには、上記の画像処理部２８のプリントモジュール等が含まれる。
【0050】
図３は、画像処理装置１２の操作部２６に表示される画面（ホーム画面）の一例を示す。ホーム画面には、コピー(Copy)ボタン３４，ＩＤカードコピー(ID Copy)ボタン３６、スキャン(Scan)ボタン３８、ファクス(Fax)ボタン４０、マイコピー(MyCopy)ボタン４２、ウェブアプリ(Web App1)ボタン４４，簡単コピーボタン４６の各アイコンが表示される。利用者がいずれかのボタンにタッチして選択すると、各ボタンに割り当てられたアプリケーションが起動し、アプリケーションの画面に遷移する。利用者は、各ボタンに各アプリケーションが対応していると認識し得る。
【0051】
アプリケ−ションは、既述したように、フレームワーク３１が定義したＩ／Ｆを提供するJavaScriptソフトウェアであり、利用者に対して直接的に機能を提供するコンポーネントである。フレームワーク３１によって定義された共通の構成を有する。また、各アプリケーションは、他のアプリケーションとの間の結合度合いが低くなるように構成される。アプリケーションには、ユーザインターフェイス(UI)を介して利用者と協働して動作するものと、利用者と協働しないものがある。利用者と協働するアプリケーションは、主体的にプレゼンテーション層３０を通じて表示や入力を実行する。
【0052】
なお、図には利用者がログインするためのログイン(Login)ボタン４８も表示されているが、このボタンにもアプリケーションが対応している。
【0053】
＜アプリケーションの実装構造＞
図４は、アプリケーションの構造を示す。アプリケーション５０は、大別して、３つのコンポーネントに分離される。すなわち、コアロジック(Core Logic)５２、ＵＩフレーム(UI Frame)５４、及びマニフェストファイル(Manifest file)５６に分離される。ここで、「分離」とは、物理的に分離されることを意味するものではなく、論理的に分離されることを意味する。
【0054】
コアロジック(Core Logic)５２は、アプリケーションとしての基本処理（基本的な振る舞いやアプリ間連携）を行うコンポーネントであり、各アプリケーションに必ず存在する。コアロジック(Core Logic)は、フレームワーク３１によって定義されたＩ／Ｆを提供する。
【0055】
ＵＩフレーム(UI Frame)５４は、アプリケーションとして描画表示するためのコンポーネントであり、具体的には表示ウインドウとして管理される。
【0056】
マニフェストファイル５６は、各アプリケーションの静的な情報のリストである。静的な情報は、アプリケーションの識別子（ＩＤ）、表示名称、アイコン画像、バージョン、作成日等である。マニフェストファイル５６には、コアロジック用マニフェストファイル５６−１と、ＵＩフレーム用マニフェストファイル５６−２がある。マニフェストファイル５６が記述する情報の一つは、isLaunchable属性である。この属性により、ホーム画面上にアイコン（ボタン）として表示されるか否かが決定され、
isLaunchable=trueで表示
isLaunchable=falseで非表示
となる。
【0057】
このような構成において、コアロジック(Core Logic)５２とＵＩフレーム(UI Frame)５４との間の通信のルールは以下の通りである。
（１）コアロジック(Core Logic)５２は、他のコアロジック(Core Logic)５２と通信する。
（２）ＵＩフレーム(UI Frame)５４は、コアロジック(Core Logic)５２のみと通信する。
【0058】
従って、ＵＩフレーム(UI Frame)５４は、他のＵＩフレーム(UI Frame)５４と通信することはない。
【0059】
図５は、従来のプログラム構成を示す。従来においては、巨大なルートアプリケーション(RootApp)６０を用意して各アプリケーションから利用される種々の機能を提供しており、全てのアプリケーションはこのルートアプリケーション６０に依存している。また、各種のデバイス状態を専門に扱うデバイスアプリケーション(Device App)６２も別個に存在しており、ほぼ全てのアプリケーションがこのデバイスアプリケーション６２に依存している。さらに、アプリケーション間での実装共通化が進んでおり、アプリケーション間での依存関係も生じている。従って、アプリケーションを追加する場合や削除する場合でも、その都度アプリケーション間で調整が必要となり、また、ルートアプリケーション６０の修正も常に必要となることから、容易にアプリケーションの追加や削除ができない。
【0060】
他方、図６は、本実施形態のプログラム構成を示す。各アプリケーションは、コアロジック(Core Logic)５２、ＵＩフレーム(UI Frame)５４、及びマニフェストファイル(Manifest file)５６に分離されており、各アプリケーションのコアロジック(Core Logic)５２がフレームワーク３１に接続され、各アプリケーションのＵＩフレーム(UI Frame)５４は当該アプリケーションのコアロジック(Core Logic)５２に接続される構成である。
【0061】
例えば、コピー(Copy)アプリケーションを例にとると、コピーアプリケーションは、コアロジック(Core Logic)５２、ＵＩフレーム(UI Frame)５４、及びマニフェストファイル(Manifest file)５６に分離され、そのコアロジック(Core Logic)５２はフレームワーク３１に接続され、そのＵＩフレーム(UI Frame)５４はそのコアロジック(Core Logic)５２に接続される。各アプリケーション間の結合は限定的であって従来のように依存関係になく、各アプリケーション間の連携は、コアロジック(Core Logic)５２を介してフレームワーク３１により実行される。各アプリケーションのコアロジック(Core Logic)５２は、フレームワーク３１によって定義されたＩ／Ｆを提供するから、新たにアプリケーションを追加する場合でも、フレームワーク３１によって定義されたＩ／Ｆを提供することで容易に追加できる。また、アプリケーション間の結合も限定的であるため、アプリケーションの削除も容易である。
【0062】
図７は、コピーアプリケーションの例を示す。図において、baseframe.htmlがコアロジック(Core Logic)５２であり、base_manifest.jsonがコアロジック(Core Logic)５２のマニフェストファイル５６−１である。また、uiframe.htmlがＵＩフレーム(UI Frame)５４であり、app_manifest.jsonがＵＩフレーム(UI Frame)５４のマニフェストファイル５６−２である。
【0063】
図８は、アプリケーションリストの例を示す。図において、”base”がコアロジック(Core Logic)５２のマニフェストファイル５６−１を示し、”app”がＵＩフレーム(UI Frame)５４のマニフェストファイル５６−２を示す。マニフェストファイル５６−２の中の”type”は、アプリケーションの種類を示す。アプリケーションの種類については以下の通りである。
すなわち、アプリケーションには、
ＳＴＤ：標準搭載されるアプリケーション
ＯＴ：標準搭載されるアプリケーション（ＳＴＤ）のショートカット
ＥＸＴ：追加可能なアプリケーション（その１）
ＣＳ：追加可能なアプリケーション（その２）
の４つの種類がある。標準搭載されるアプリケーションは、図３に示されるコピー(Copy)やスキャン(Scan)、ファクス(Fax)等に対応するアプリケーションである。また、ＯＴ、ＥＸＴ、ＣＳの各アプリケーションには、それぞれ特別なコンパニオンアプリケーションが割り当てられ、各コンパニオンアプリケーションがそれぞれの機能を担う。各コンパニオンアプリケーションも、ＳＴＤアプリケーションと同様にコアロジック(Core Logic)５２を有する。マニフェストファイル５６にアプリケーションの種類を含めることで、各アプリケーションの内部実装を互いに区別することができる。
【0064】
また、マニフェストファイル５６−２の中の”isLaunchable”は既述したように、アイコンをホーム画面上に表示するか否かを決定する属性情報である。図では、
isLaunchable=true
となっており、これはコピーのボタンを表示することを意味する。
【0065】
アプリケーションは、コアロジック(Core Logic)５２とＵＩフレーム(UI frame)５４に分離されているから、アプリケーションリストは、両者の対応関係が記述されていると言うことができる。
【0066】
マニフェストファイル５６は、アプリケーション毎に作成されるから、アプリケーション毎の種別を示す識別子と、種別内で一意の識別子を設定することが望ましい。例えば、コピーアプリケーションのマニフェストファイルには、
type:STD
ID:copy
等である。typeは種別を示す識別子であり（標準搭載されるアプリケーション）、IDは一意の識別子である。
【0067】
さらに、マニフェストファイル５６には、静的情報として、起動時に必要とされる情報及びホーム画面描画に必要な情報も含まれる。起動時に必要とされる情報は、コアロジック(Core Logic)５２の格納先情報及びＵＩフレーム(UI frame)５４の格納先情報であり、フレームワーク３１はコアロジック(Core Logic)５２の格納先情報を参照してコアロジック(Core Logic)５２をロードする。また、コアロジック(Core Logic)５２は、ＵＩフレーム(UI frame)５４の格納先情報を参照してＵＩフレーム(UI frame)５４を必要に応じてロードする。
【0068】
ホーム画面描画に必要とされる情報は、アイコンボタン格納先情報及びボタンの表示順序である。
【0069】
マニフェストファイル５６は、後述するようにデバイスサービス層のアプリケーション管理コンポーネントで参照され、アプリケーションリストの作成に供される。
【0070】
図９は、アプリケーションの実装構造のパターンを示す。
【0071】
図９（ａ）は、コアロジック(Core Logic)５２は存在するが、ＵＩフレーム(UI Frame)５４が存在しないパターンである。標準搭載されるアプリケーションではなく、コンパニオンアプリケーション等が該当する。図９（ｄ）は、図９（ａ）に対応するアプリケ−ションリストである。
【0072】
図９（ｂ）は、コアロジック(Core Logic)５２及びＵＩフレーム(UI frame)５４が存在するパターンであり、それぞれ１対１に対応するパターンである。図９（ｅ）は、図９（ｂ）に対応するアプリケーションリストである。
【0073】
他方、図９（ｃ）は、コアロジック(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"
}
である。
【0074】
なお、図９（ｂ）及び図９（ｃ）において、ＵＩフレーム(UI Frame)５４のマニフェストファイル５６−２のisLaunchable属性値を設定することで、実際にホーム画面上にボタンを表示するか否かが決定される。例えば、図９（ｃ）において、コアロジック(Core Logic)５２を共通に持つ、第１のＵＩフレーム(UI Frame)５４と第２のＵＩフレーム(UI Frame)５４が存在し、第１のＵＩフレーム(UI Frame)54のマニフェストファイルのisLaunchable=trueであるのに対し、第２のＵＩフレーム(UI Frame)５４のマニフェストファイルのisLaunchable=falseである場合、前者はボタンとして表示されるが後者は表示されない。
【0075】
アプリケーションの実行構造として、コアロジック(Core Logic)５２とＵＩフレーム(UI Frame)５４を分離しているので、コアロジック(Core Logic)５２を変更することなくＵＩフレーム(UI Frame)５４のみを変更し、アプリケーションの画面上の表示形態を容易にカスタマイズすることが可能である。
【0076】
図１０は、画面上の表示形態をカスタマイズする場合の例を示す。
【0077】
図１０（ａ）は、当初の表示形態である。ＩＤカードコピーのアプリケーションに着目すると、そのＵＩフレーム(UI Frame)５４はidcopy/uiframe.htmlであり、そのマニフェストファイル５６−２はidcopy/app_manifest.jsonである。
【0078】
図１０（ｂ）は、表示形態をカスタマイズする場合である。ＩＤコピーのアプリケーションにおいて、そのＵＩフレーム(UI frame)５４とマニフェストファイル５６−２を新しい表示形態用のidcopy_for_xxx/uiframe.htmlとidcopy_for_xxx/app_manifest.jsonに入れ替える。勿論、マニフェストファイル５６−２のみを入れ替えることも可能である。
【0079】
他方、図１０（ｃ）は、表示形態ではなくアプリケーションのロジックを変更する場合である。この場合には、コアロジック(Core Logic)５２、ＵＩフレーム(UI Frame)５４、マニフェストファイル５６を全て新しいものに入れ替える。すなわち、copy以下をcopy_for_xxxに入れ替える。
【0080】
図１１は、フレームワーク３１を含めた具体的なアプリケーションの実装構造のパターンを示す。
【0081】
図１１（ａ）は、コピーアプリケーションとＩＤコピーアプリケーションを実装する場合のパターンの例である。コピーアプリケーションは、コアロジック(Core Logic)５２とＵＩフレーム(UI frame)５４に分離され、コアロジック(Core Logic)５２がフレームワーク３１と通信する。ＵＩフレーム(UI frame)５４はコアロジック(Core Logic)５２のみと通信する。また、ＩＤコピーも同様にコアロジック(Core Logic)５２とＵＩフレーム(UI frame)５４に分離され、コアロジック(Core Logic)５２がフレームワーク３１と通信する。ＵＩフレーム(UI frame)５４はコアロジック(Core Logic)５２のみと通信する。
【0082】
図１１（ｂ）は、コピーアプリケーションとＩＤコピーアプリケーションに加え、プリントアプリケーションを実装する場合の他の例である。コピーアプリケーションとＩＤコピーアプリケーションは、共通のコアロジック(Core Logic)５２とそれぞれのＵＩフレーム(UI frame)５４に分離される。すなわち、コピーアプリケーション及びIDコピーアプリケーションは、共通のコアロジック(Core Logic)５２を介してフレームワーク３１と通信する。また、プリントアプリケーションは、コアロジック(Core Logic)５２は存在するもののＵＩフレーム(UI frame)５４はない。図１１には、図９に示す全てのパターンが含まれている。
【0083】
従来のアプリケーション実装構造では、このようにコアロジック(Core Logic)５２とＵＩフレーム(UI frame)５４とが分離しておらず、処理と画面描画とが混在して分かり難い構造であった。また、アプリケーションの共通Ｉ／Ｆも存在せず、各アプリケーションはいわば勝手にＩ／Ｆを公開し、勝手にこれを参照していた。これに対し、実施形態では、フレームワーク３１がアプリケーションＩ／Ｆとして定義し、各アプリケーションのコアロジック(Core Logic)５２がこのアプリケーションＩ／Ｆを必ず実装する構造であるため、従来とはＩ／Ｆの向きが相違するといえる。また、フレームワーク３１とアプリケーション間の通信のみならず、アプリケーション間の通信Ｉ／Ｆについてもフレームワーク３１が提供するＩ／Ｆ公開機能とＩ／Ｆ参照機能で実現され得る。
【0084】
なお、理論上は、複数のアプリケーションでＵＩフレーム(UI frame)５４を共通化し、コアロジック(Core Logic)５２をそれぞれ個別に設けるパターンも存在し得る。但し、この場合にはフレームワーク３１から見ると構造が複雑化するため、実施形態では特に言及していない。勿論、このことは当該パターンの排除を必ずしも意味するものではない。
【0085】
＜アプリケーションのライフサイクル管理＞
図１２は、フレームワーク３１による各アプリケーションのライフサイクル管理を行う際の基本構成を示す。ここで、フレームワーク３１は、アプリケーションの実行環境である。
【0086】
プレゼンテーション層に、フレームワーク３１及び各種アプリケーション５０が存在するとともに、ブータ（Booter）６０及びスタータアプリケーション６４が存在する。また、デバイスサービス層に、アプリケーション管理コンポーネント６２が存在する。
【0087】
ブータ（Booter）６０は、プレゼンテーション層全体の起動終了管理を行うコンポーネントである。フレームワーク３１は、ブータ(Booter)６０により初期化され起動される。
【0088】
アプリケーション管理コンポーネント６２は、各種アプリケーション５０のマニフェストファイル５６に基づきアプリケーションのリストをフレームワーク３１に提供する。
【0089】
スタータアプリケーション６４は、フレームワーク３１が定義するスタータＩ／Ｆ７０を実装するアプリケーションである。このスタータアプリケーション６４は、システムで唯一つ存在するアプリケーションであり、全アプリケーション５０の初期化完了時にフレームワーク３１から呼び出される。
【0090】
各種アプリケーション５０は、既述したようにコピーアプリケーションやＩＤコピーアプリケーション、ファクスアプリケーション等であり、コアロジック(Core Logic)５２を備える。各種アプリケーション５０のコアロジック(Core Logic)５２は、フレームワーク３１が定義するアプリケーションＩ／Ｆ７２を実装する。
【0091】
各アプリケーション５０が実装するアプリケーションＩ／Ｆは、具体的には、
・初期化時処理(initialize)
・終了時処理(finalize)
・ウインドウ押し出し処理(windowPushedOut)
・ウインドウ露出時処理(windowPrepareExposed)
・ウインドウ削除時処理(windowPrepareTerminated)
である。各アプリケーション５０は、これらのイベントに対するハンドラを実装する。
【0092】
フレームワーク３１は、各種アプリケーション５０のコアロジック(Core Logic)５２の間で、メソッドの公開／呼び出し、イベントの公開／購読／発行を可能にするためのJava Scriptコンポーネント（これを通信制御コンポーネントと称する）を備える。メソッドは任意の引数をとり、任意の戻り値を返す定義が可能である。公開したメソッドは、アプリケーション毎に独立して管理される。メソッド呼び出し側のアプリケーションは、メソッドの処理完了をコールバック呼出により確認できる。また、イベントは、各アプリケーションが任意のデータを伴って定義可能である。公開したイベントは、アプリケーション毎に独立して管理される。より詳細には、通信制御コンポーネントはコアロジック(Core Logic)５２によるメソッドの公開及び呼び出し、イベントの定義と発行及びリスナの登録を可能とし、「on」によりメソッドを公開し、「off」によりメソッドの公開を停止する。公開されたメソッドはcallにより呼び出し可能である。例えば、第１のアプリケーションがあるＩ／Ｆを「on」してフレームワーク３１に対して公開し、第２のアプリケーションが第１のアプリケーションの公開されたＩ／Ｆを対象としてフレームワーク３１に対して「call」する等である。
【0093】
メソッドの公開／呼び出し、イベントの公開／購読／発行をより具体的な仕様（ＡＰＩ）で説明すると以下の通りである。
【0094】
Java ScriptコンポーネントであるArena comのオブジェクトをarenaComとし、arenaCom.on(methodName,methodFunc)によりメソッドを公開する。引数methodNameは公開するメソッドの名前であり、methodFuncは公開するメソッド処理の実体である。公開さえたメソッドは、callにより呼び出すことができる。
【0095】
arenaCom.off(methodName)によりメソッドの公開を停止する。methodNameは公開を停止するメソッドの名前である。
【0096】
arenaCom.call(appid,methodName,args,callbacl)により公開されているメソッドを呼び出す。Appidはメソッド公開元のアプリケーションＩＤ、methodNameは呼び出す公開メソッド名、argsは引数、callbackはメソッド処理の完了時に呼び出されるコールバックである。
【0097】
arenaCom.publishEvent(eventName)によりイベントを公開する。eventNameは公開するイベント名である。イベントは、公開直後からリスナ登録が可能となる。また、arenaCom.unpublishEvent(eventName)によりイベントを非公開にする。eventNameは非公開にするイベント名である。
【0098】
arenaCom.addListener(appid,eventName,listenerFunction,completeCallback)により公開イベントに対してリスナを登録する。Appidはイベントを公開しているアプリケーションのＩＤ、eventNameは受信するイベントの名前、listenerFunctionはイベント発生時に呼び出される処理の実体、completeCallbackはリスナ登録の完了時に呼び出されるコールバックである。
【0099】
arenaCom.fireEvent(EventName,data,completeCallback)によりイベントを発火する。EventNameは発火させるイベント名、dataはイベントに付随するデータ、completeCallbackは当該イベントに対する全リスナへの発火完了時に呼び出されるコールバックである。
【0100】
arenaCom.fireEventTo(listenerid,eventName,data,completeCallback)により特定リスナに対してイベントを発火する。listeneridはイベント通知先のアプリケーションＩＤ，completeCallbackは当該イベントに対する特定リスナへの発火完了時に呼び出されるコールバックである。
【0101】
図１３は、フレームワーク３１による各種アプリケーションのライフサイクル管理のフローチャートを示す。
【0102】
ブータ(Booter)６０がフレームワーク３１を起動すると、フレームワーク３１は、デバイスサービス層のアプリケーション管理コンポーネント６２に対してアプリケーションリストを要求し、アプリケーション管理コンポーネント６２からアプリケーションリストを取得する。
【0103】
フレームワーク３１は、アプリケーションリストを取得すると、このリストに従ってアプリケーション毎のベースフレーム（Base frame）を作成し、スタータアプリケーション６４を含む各種アプリケーション５０のロードを行う（ロードフェーズ）。すなわち、各アプリケーションのコアロジック(Core Logic)５２の読み込みを行う。具体的には、フレームワーク３１は、マニフェストファイル５６に規定されたコアロジック(Core Logic)５２の格納先情報を参照してコアロジック(Core Logic)５２をロードする。ベースフレーム(Base Frame)は、各アプリケーションのコアロジック(Core Logic)５２を実行するためのフレームであり、このフレームが表示されることはない。各アプリケーションのコアロジック(Core Logic)５２のロード順序は任意であり順不同である。全てのアプリケーションが、アプリケーションＩ／Ｆ実装を登録完了した時点で次のフェーズに移行する。
【0104】
なお、アプリケーションＩ／Ｆ実装の登録処理よりも前に、各アプリケーション自身のメソッド及びイベントは公開されているものとする。
【0105】
次に、フレームワーク３１は、アプリケーションＩ／Ｆを通じて、各アプリケーションにイニシャライズ（初期化）を指示する（イニシャライズフェーズ）。具体的には、フレームワーク３１は、各アプリケーションに対して”app”イベント、”initialize”メソッドを発行する。全アプリケーションが、初期化指示に対する完了時呼び出しコールバックを呼び出した時点で、フレームワーク３１はブータ(Booter)６０に対して初期化処理の完了を通知し、次のフェーズに移行する。各アプリケーションの初期化順序も任意である。この初期化処理において、各アプリケーションはデバイスサービス層に対するデータ取得を実行する。
【0106】
次に、ブータ(Booter)６０は、フレームワーク３１に対してアプリケーションによる機能提供の開始指示を行い、フレームワーク３１は、これを受けてスタータアプリケーション６４に対して開始指示を行う（開始フェーズ）。スタータアプリケーション６４は、デバイスサービス層で管理されている初期起動アプリケーションの情報を取得し、初期画面を表示する。スタータアプリケーション６４が、開始指示に対する完了時呼び出しコールバックを呼び出した時点でこのフェーズが完了する。
【0107】
なお、システム終了時には、フレームワーク３１は各アプリケーションのコアロジック(Core Logic)５２に対してファイナライズ（終了）を指示する。また、アプリケーション毎のベースフレーム（Base frame）を破棄する。
【0108】
ロードフェーズでは、順不同で各アプリケーションのコアロジック(Core Logic)５２を読み込むので、アプリケーションを追加したとしてもこのロードフェーズを変更する必要がない。また、イニシャライズフェーズでは、全アプリケーションの初期化を行うので他のアプリケーションを呼び出すことが保証されており、個別の待ち合わせは不要である。このように、アプリケーション間の待ち合わせが無くなり、かつ、比較的小さいサイズのコアロジック(Core Logic)５２のみをロードするので、システム起動時間及びアプリケーション起動時間が短縮される。
【0109】
各アプリケーションが独自にＩ／Ｆを公開している場合、アプリケーション毎に起動、初期化前処理、初期化、初期化後処理、停止、一時停止等が異なるためアプリケーション毎に初期化レベルに相違が生じ、アプリケーションを呼び出すことができるタイミングもばらついてしまう。特に、アプリケーションを呼び出す前に、相手を呼び出せる状態であるか否かを確認する必要が生じ、制御が複雑化してしまう。これに対し、実施形態では、上記のように初期化時間が短縮されるとともに、初期化後のホーム画面の起動時間も短縮され得る。
【0110】
図１４は、従来及び実施形態におけるシステム起動からホーム画面が表示されるまでの時間を比較して示す。
【0111】
従来においては、アプリ初期化時間は、純粋な初期化時間に加えて待ち時間を要しており、ホーム画面の起動時間も同様に純粋な起動時間に加えて待ち時間を要していたところ、実施形態では純粋な初期化時間を短縮できるとともに待ち時間を削減することもできる。ホーム起動時間についても同様である。従来においては、アプリケーション間で依存関係がある場合にはデッドロックが生じないような調整が必要であるところ、実施形態ではこのような依存関係がないためデッドロック用調整も不要化される。
【0112】
以上説明したように、本実施形態では、アプリケーションをコアロジック(Core Logic)５２とＵＩフレーム(UI frame)５４に分離し、フレームワーク３１が定義するＩ／Ｆをコアロジック(Core Logic)５２が実装する構成とし、コアロジック(Core Logic)５２がフレームワーク３１を介して他のアプリケーションのコアロジック(Core Logic)５２と通信し、他方でＵＩフレーム(UI frame)５４はそのアプリケ−ションのコアロジック(Core Logic)５２のみと通信する構成とすることで、各アプリケーションは、フレームワーク３１によって定義された共通の構成を有すると同時に、他のアプリケーションとの間の結合度合いが低くなるように構成することが可能となり、追加や削除が容易化される。
【0113】
次に、追加可能なアプリケーションを実装する場合について説明する。既述したように、アプリケーションには、標準搭載されるアプリケーションの他に、追加可能なアプリケーションがある。標準搭載されるアプリケーションは、フレームワーク３１が定義したＩ／Ｆを提供するソフトウェアであり、内部アプリケーションといえる。他方、追加可能なアプリケーションは、既存のアプリケーションであり得、またサードパーティから提供されるアプリケーションであり得るため、必ずしもフレームワーク３１が定義したＩ／Ｆを提供するとは限らない外部アプリケーションである。このため、後から追加可能なアプリケーション（以下では「外部アプリケーション」と称する）に対して大幅な修正を加えることなく実装することが可能で、しかも、たとえ外部アプリケーションの動作が不安定あるいは異常が生じた場合であっても、他の内部アプリケーションの動作に影響を与えないことが望ましい。
【0114】
そこで、既述したように、外部アプリケーションには、外部アプリケーションの種類毎に特別なコンパニオンアプリケーションを割り当て、コンパニオンアプリケーションがフレームワーク３１と外部アプリケーションとの間に介在して外部アプリケーションを実行する。
【0115】
図１５は、外部アプリケーション及びコンパニオンアプリケーションを備えるシステムの論理構成を示す。図２に対応するものである。プレゼンテーション層３０には、内部アプリケーション（内部アプリ）として、ホーム画面を表示するためのホームアプリケーション（ホームアプリ）７０、異常時の画面を制御するフォールトアプリケーション（フォールトアプリ）７２に加え、コンパニオンアプリケーション（コンパニオンアプリ）７４，７６，７８が実装される。また、外部アプリケーション（外部アプリ）として、外部アプリＡ８０、外部アプリＢ８２，外部アプリＣ８４が実装される。コンパニオンアプリ７４は外部アプリＡ８０に対応するコンパニオンアプリであり、コンパニオンアプリ７６は外部アプリＢ８２に対応するコンパニオンアプリであり、コンパニオンアプリ７８は外部アプリＣ８４に対応するコンパニオンアプリである。各コンパニオンアプリ７４，７６，７８は、フレームワーク３１と外部アプリＡ８０、外部アプリＢ８２、外部アプリＣ８４とを仲介するソフトウェアであり、フレームワーク３１が外部アプリＡ８０、外部アプリＢ８２、外部アプリＣ８４に要求する条件を吸収する機能を備える。コンパニオンアプリ７４，７６，７８は、ホーム画面上のボタンが利用者により操作されると、ホームアプリ
７０からの要求に応じて外部アプリＡ８０，Ｂ８２，Ｃ８４を起動する。コンパニオンアプリ７４，７６，７８が内部アプリとしての要求を吸収するので、外部アプリＡ８０，外部アプリＢ８２，外部アプリＣ８４を修正することなく、内部アプリとしての要件を満たし得る。
【0116】
図１６は、他の論理構成を示す。外部アプリ毎にコンパニオンアプリを実装するのではなく、単一のコンパニオンアプリ７５で複数の外部アプリを管理する構成である。コンパニオンアプリ７５は外部アプリＡ８０，外部アプリＢ８２、及び外部アプリＣ８４に対応するコンパニオンアプリである。コンパニオンアプリ７５は、フレームワーク３１と外部アプリＡ８０、外部アプリＢ８２、及び外部アプリＣ８４とを仲介するソフトウェアであり、フレームワーク３１が外部アプリＡ８０、外部アプリＢ８２、及び外部アプリＣ８４に要求する条件を吸収する機能を備える。
【0117】
外部アプリを起動する場合、内部アプリと同様の画面遷移及び操作性が維持されることがシステム全体をシームレスに構築する観点からは望ましい。このため、内部アプリは内部ブラウザで起動し、外部アプリは外部ブラウザで起動するように互いに異なるブラウザでそれぞれのアプリを起動するようにしてたとえ外部ブラウザに異常が生じたとしても内部ブラウザに影響を与えないようにし、フレームワーク３１が内部ブラウザのみならず外部ブラウザもまとめて管理し、より特定的には、通常のiframeベースのウインドウに加えて外部ブラウザもウインドウの一種として扱い統一的に管理する。このように、内部ブラウザと外部ブラウザをまとめて管理し、ともにウインドウとして制御することで、内部アプリと外部アプリの画面制御情報が一元化されるので、制御が簡易化される。
【0118】
なお、本実施形態では、フレームワーク３１が内部ブラウザのみならず外部ブラウザもまとめて管理し、通常のiframeベースのウインドウに加えて外部ブラウザもウインドウの一種として扱い統一的に管理するが、これとは異なり、コンパニオンアプリが状況に応じて内部ブラウザと外部ブラウザの切替を行うスーパーバイザー的な機能を有するシステムとして構築することも可能である。
【0119】
図１７は、コンパニオンアプリ７４の機能ブロック図を示す。コンパニオンアプリ７５，７６，７８についても同様である。
【0120】
コンパニオンアプリ７４は、機能モジュールとして、外部アプリメタ情報管理部７４１と、動作条件検査部７４２と、外部アプリ起動指示部７４３と、外部アプリプロセス管理部７４４と、イベント検知部７４５を備える。
【0121】
外部アプリ起動指示部７４３は、フレームワーク３１を介してホームアプリ７０に外部アプリボタン情報を提供するとともに、ユーザが外部アプリボタンを操作するとこれに応じてフレームワーク３１を介してホームアプリ７０からのlaunch指令を受信する。外部アプリ起動指示部７４３は、Launch指令を受信すると、フレームワーク３１に対してウインドウの生成及びウインドウの表示指令を提供し、外部アプリプロセス管理部７４４の情報を更新する。
【0122】
外部アプリメタ情報管理部７４１は、コンパニオンアプリ７４のマニフェスト情報を記憶する。
【0123】
動作条件検査部７４２は、起動指令を受けたときにその権限の有無をチェックする。
【0124】
外部アプリプロセス管理部７４４は、ウインドウの生成指令で生成された外部アプリプロセスを記憶する。
【0125】
イベント検知部７４５は、外部アプリ終了要求コマンドを受け付ける。
【0126】
なお、コンパニオンアプリ７４は、これ以外にも、外部プロセスが異常終了したときにその通知を受け取り、外部アプリプロセス管理部７４４の管理情報を更新する異常終了検知部や、ログアウト等を検知して起動中の外部アプリを終了させてキャッシュクリアするコンテキスト変更検知部等を備えていてもよい。
【0127】
図１８は、外部アプリメタ情報管理部７４１に記憶されるマニフェスト情報の一例を示す。図において、”type”はアプリケーションの種別を示し、”EXT”とあるのは外部アプリであることを示す。また、”subid”は種別内でのＩＤを示す。また、”appUrl”は、外部ブラウザが開くＵＲＬを示す。さらに、”toolsicon”と”displayName”は、ホーム画面に表示するアイコンと名前を示す。
【0128】
図１９は、フレームワーク３１の機能ブロック図を示す。フレームワーク３１は、機能モジュールとして、イベント送受信部３１１、画面制御部３１２、アプリ判別部３１３、ウインドウ管理部３１４、階層管理部３１５、及びアプリケーション管理部３１６を備える。
【0129】
画面制御部３１２は、全体のフローを制御する。すなわち、外部からのウインドウの生成要求の受付からその結果を返す全体の制御を行う。また、ウインドウ管理情報を生成し、ウインドウ管理部３１４に情報を追加する。
【0130】
アプリ判別部３１３は、アプリの種別を用いて呼び出す関数を呼び分ける。すなわち、内部用関数か外部用関数かで呼び分ける。具体的には、アプリの種別と関数の対応関係を規定するテーブルを記憶し、このテーブルを用いて呼び分ける。
【0131】
階層管理部３１５は、階層構造を管理する。階層管理部３１５は、各階層のアクティブなウインドウを管理する。階層管理部３１５は、具体的にはアプリケーション層／ポップアップ層／バナー層／アラート（低レベル）層／アラート（高レベル）層／フォールト層の順に階層構造を管理するとともに、外部アプリについて内部アプリのアプリケーション層の下にウインドウを挿入する。
【0132】
ウインドウ管理部３１４は、ウインドウＩＤをキーにして各ウインドウの情報を管理する。ウインドウ情報には、内部ウインドウ情報及び外部アプリウインドウ情報が含まれる。
【0133】
図２０は、ウインドウ管理部３１４で管理されるウインドウ管理情報の一例を示す。ウインドウ管理情報は、共通管理情報３１４ａと、内部ウインドウ管理情報３１４ｂあるいは外部アプリウインドウ管理情報３１４ｃから構成される。内部アプリの場合には共通管理情報３１４ａと内部ウインドウ管理情報３１４ｂから構成され、外部アプリの場合には共通管理情報３１４ａと外部アプリウインドウ管理情報３１４ｃから構成される。共通管理情報３１４ａには、ウインドウＩＤや表示状態、階層を規定する階層ｉｄが含まれる。内部ウインドウ管理情報３１４ｂには、内部ウインドウのhtmlのdiv要素やhtmlのiframe要素が含まれる。外部アプリウインドウ管理情報３１４ｃには、外部ウインドウのhtmlのdiv要素やデバイスサービス層（Ｄ層）のプロセスＩＤが含まれる。ここで、外部ウインドウのhtmlのdiv要素は、外部ウインドウを内部ウインドウに埋め込むためのdiv要素である。この外部ウインドウのhtmlのdiv要素は、透明な枠だけの空のdiv要素であり、いわばダミーのdiv要素として機能する。このダミーのdiv要素を内部アプリのiframeを扱うのと同じように画面階層に挿入することでシームレスな画面制御が可能となる。
【0134】
コンパニオンアプリ７４の各機能モジュール、及びフレームワーク３１の各機能モジュールの動作について、さらに詳述する。
【0135】
図２１は、ホーム画面上の外部アプリのボタンがユーザにより操作されてから、外部アプリが表示されるまでのシーケンスを示す。ユーザ、ホームアプリ７０、コンパニオンアプリ７４（あるいはコンパニオンアプリ７５，７６，７８）、フレームワーク３１、及びデバイスサービス層（デバイス層）３２の処理である。
【0136】
ユーザが外部アプリボタンを押下操作すると、ホームアプリ７０は、ユーザにより押下されたボタンのlaunch指令とその付随情報をコンパニオンアプリ７４に送信する。付随情報には、外部アプリのＩＤ、すなわちマニフェスト情報のsubidが含まれる。
【0137】
コンパニオンアプリ７４の外部アプリ起動指示部７４３は、ホームアプリ７０からのlaunch指令を受信し、外部アプリＩＤに基づいて外部アプリメタ情報管理部７４１から外部アプリメタ情報を取得する。また、外部アプリ起動指示部７４３は、動作条件検査部７４２に対して指定された外部アプリの起動条件が満たされているか否かをチェックするように指令する。コンパニオンアプリ７４の動作条件検査部７４２は、現在のユーザをフレームワーク３１から取得するとともに、現在のユーザが有する権限をデバイスサービス層３２の権限情報管理部から取得し、現在のユーザが指定された外部アプリを起動する権限を有しているか否かを確認する。コンパニオンアプリ７４の外部アプリ起動指示部７４３は、現在のユーザが指定された外部アプリを起動する権限を有している場合、フレームワーク３１に対してウインドウの生成指令（createWindow）を発行する。この際、外部アプリの詳細情報、具体的には外部アプリの種別とそのＩＤを提供する。
【0138】
フレームワーク３１の画面制御部３１２は、コンパニオンアプリ７４からのウインドウの生成指令createWindow）を受け取ると、アプリ判別部３１３がウインドウ情報生成に用いる関数を決定する。画面制御部３１２は、アプリ判別部３１３で決定された外部アプリ用ウインドウ生成関数を実行して、ウインドウ管理情報を生成する。ウインドウ管理情報は、共通管理情報３１４ａ及び外部アプリウインドウ管理情報３１４ｃから構成される。外部アプリウインドウ管理情報３１４ｃには、既述したように内部側の埋め込み用としてのダミーのdiv要素も含まれる。画面制御部３１２は、生成したウインドウ管理情報をウインドウ管理部３１４に追加する。画面制御部３１２は、これらの管理情報に基づいてデバイスサービス層３２に対して外部アプリの起動を指令する。具体的には、外部アプリの種別及びＩＤとともに外部ブラウザの起動要求を指令する。
【0139】
デバイスサービス層３２は、指定された外部アプリを起動し、そのプロセスＩＤをフレームワーク３１に返す。デバイスサービス層３２は、生成した外部アプリウインドウを非表示とし、かつ、内部ブラウザウインドウよりも下の階層に配置する。
【0140】
フレームワーク３１は、プロセスＩＤを受け取ると、外部アプリのウインドウＩＤをウインドウ生成指令createWindow）の結果としてコンパニオンアプリ７４に返す。
【0141】
コンパニオンアプリ７４は、次に、フレームワーク３１に対して外部アプリ表示要求(showWindow)を発行する。
【0142】
フレームワーク３１の画面制御部３１２は、外部アプリ表示要求（showWindow）を受け付けると、指定されたウインドウの表示処理を開始し、同じ階層に表示されている別のウインドウがあればその別ウインドウの非表示処理を開始する（押し出し処理）。指定されたウインドウが外部アプリウインドウであれば、内部側にダミーあるいはエイリアスとして作成したdivを表示し、外部アプリウインドウを表示する。そして、階層管理部３１５に指定されたウインドウを最下位階層のウインドウとして登録する。また、画面制御部３１２は、内部ブラウザウインドウを表示するか否かを決定する。すなわち、階層管理部３１５に問い合わせて、各階層に表示されているウインドウを確認し、最下位階層以外にバナーやフォールト等のウインドウが内部側に表示されている場合には内部ブラウザを表示し、そうでない場合には内部ブラウザを非表示とする（図では、内部側をLUIと略記する）。
【0143】
図２２は、押し出し処理のシーケンスを示す。
【0144】
画面には、外部アプリウインドウが表示されており、ユーザがこの状態からホームキーを押下した場合を想定する。
【0145】
デバイスサービス層３２は、ユーザによるホームキーの押下を検知すると、フレームワーク３１に対してホームキーの押下を提供する。
【0146】
フレームワーク３１のイベント送受信部３１１は、ホームキーの押下イベントを受け付けると、ホームアプリ７０にその旨を通知する。
【0147】
ホームアプリ７０は、ホームキー押下イベントを受信すると、フレームワーク３１に対して作成済みのホーム画面のウインドウＩＤを指定してウインドウ表示（showWindow）を呼ぶ。
【0148】
フレームワーク３１の画面制御部３１２は、ウインドウ表示（showWindow）を受け付けると、指定されたウインドウの表示処理を開始し、同じ階層に表示されている別のウインドウがあればその別ウインドウの非表示処理を開始する。非表示になったウインドウが外部アプリウインドウであれば、内部側へのダミーあるいはエイリアスとして作成したdivを非表示とし、外部アプリウインドウを非表示とする。そして、コンパニオンアプリ７４に押し出しイベントwindowPusheOut）を通知する。この押し出しイベント通知は、言うまでもなく外部アプリウインドウが非表示になったことの通知である。これにより、ホーム画面の表示指令によって外部アプリウインドウは非表示になる。
【0149】
コンパニオンアプリ７４は、押し出しイベント（windowPushedOut）を受信すると、イベント検知部７４５がこれを検知して必要な処理、具体的には内部のウインドウ状態管理を更新する。
【0150】
図２３は、ユーザがホーム画面上の外部アプリボタンを押下したときに、既に起動済みの外部アプリが存在し、非表示になっていた場合のシーケンス図を示す。
【0151】
ユーザがホーム画面上の外部アプリボタンを押下すると、ホームアプリ７０は、押下されたボタンのLaunch指令とその付随情報、すなわち外部アプリＩＤ（マニフェスト情報におけるsubid）をコンパニオンアプリ７４に通知する。
【0152】
コンパニオンアプリ７４の外部アプリ起動指示部７４３は、Launch指令を受け取ると、外部アプリプロセス管理部７４４に指定された外部アプリが起動済みか否かを問い合わせる。指定された外部アプリが起動済みの場合、外部アプリ起動指示部７４３は、外部アプリプロセス管理部７４４から外部アプリＩＤに対応するウインドウＩＤを取得し、フレームワーク３１に対して外部アプリ表示要求（showWindow）を発行する。
【0153】
フレームワーク３１の画面制御部３１２は、外部アプリ表示要求showWindow）を受け付けると、指定されたウインドウの表示処理を開始し、同じ階層に表示されている別のウインドウがあればその別ウインドウの非表示処理を開始する（押し出し処理）。指定されたウインドウが外部アプリウインドウであれば、内部側のダミーあるいはエイリアスとして作成したdivを表示し、外部アプリウインドウを表示する。そして、階層管理部３１５に指定されたウインドウを最下位階層の表示ウインドウとして登録する。また、画面制御部３１２は、内部ブラウザウインドウを表示するか否かを決定する。すなわち、階層管理部３１５に問い合わせて、各階層に表示されているウインドウを確認し、最下位階層以外にフォールトやバナー等のウインドウが表示されている場合は内部ブラウザを表示し、そうでない場合は内部ブラウザを非表示とする。
【0154】
図２４は、外部アプリ正常終了時のシーケンス図であり、ユーザが外部アプリ内の終了ボタンを押下した場合のシーケンス図である。
【0155】
ユーザが外部アプリの終了ボタンを押下すると、当該外部アプリはデバイスサービス層３２に対して終了要求を通知する。
【0156】
デバイスサービス層３２は、外部アプリから終了要求を受け付けると、フレームワーク３１に対して終了要求を通知する。
【0157】
フレームワーク３１のイベント送受信部３１１は、プロセスＩＤを含む終了要求を受け付けると、ウインドウ管理部３１４にプロセスＩＤからウインドウＩＤへの変換を指示する。そして、イベント送受信部３１１は、コンパニオンアプリ７４に対してウインドウ終了準備イベント（windowPrepareTerminated）を発行する。
【0158】
コンパニオンアプリ７４のイベント検知部７４５は、フレームワーク３１からのウインドウ終了準備イベントを受信し、当該外部アプリの終了準備を行う。すなわち、ブラウザのヒストリ及びキャッシュをクリアし、認証アプリへのリスナの削除等である。イベント検知部７４５は、フレームワーク３１に対してウインドウ終了準備完了を通知する。
【0159】
フレームワーク３１のイベント送受信部３１１は、コンパニオンアプリ７４からウインドウ終了準備完了通知を受信すると、デバイスサービス層３２に対してプロセス終了要求を発行し、階層管理部３１５の表示中ウインドウを削除する。また、ウインドウ管理部３１４からウインドウ情報を削除する。さらに、イベント送受信部３１１は、コンパニオンアプリ７４に対してウインドウ終了イベント（windowTerminated）を発行する。
【0160】
コンパニオンアプリ７４のイベント検知部７４５は、フレームワーク３１からウインドウ終了イベントを受信すると、外部アプリプロセス管理部７４４に当該プロセスの管理情報の削除を指示し、フレームワーク３１に対して初期画面表示要求を発行する。
【0161】
フレームワーク３１のアプリケーション管理部３１６は、コンパニオンアプリ７４からの初期画面表示要求を受信すると、ホームアプリ７０（初期起動アプリ）に初期画面表示要求を発行する。これにより、初期画面としてホーム画面が表示される。なお、初期画面としてホーム画面以外を設定してもよい。
【0162】
図２５は、外部アプリ異常終了時のシーケンス図であり、外部アプリのプロセスがメモリ不足やセグメンテーションフォルト等の何らかの原因により異常終了する場合のシーケンス図である。なお、ユーザには動作中の外部アプリが見えている場合もあれば、押し出し処理によりバックグラウンドで存在している場合もある。
【0163】
オペレーティングシステム（ＯＳ）が外部アプリの異常終了を検知すると、デバイスサービス層３２はフレームワーク３１に対して外部アプリ異常終了を通知する。
【0164】
フレームワーク３１のイベント送受信部３１１は、プロセスＩＤが含まれる外部アプリ異常終了通知を受信すると、ウインドウ管理部３１４にプロセスＩＤからウインドウＩＤへの変換を指示し、外部アプリウインドウが表示中だった場合には、階層管理部３１５の表示中ウインドウを削除する。また、イベント送受信部３１１は、ウインドウ管理部からウインドウ情報を削除し、コンパニオンアプリ７４に対してウインドウ終了イベント（windowTerminated）を発行する。
【0165】
コンパニオンアプリ７４のイベント検知部７４５は、フレームワーク３１からウインドウ終了イベントを受信すると、外部アプリプロセス管理部７４４に当該プロセスの管理情報の削除を指示するとともに、その他の必要な後処理を行う。さらに、イベント検知部７４５は、外部アプリが表示中だった場合には、フレームワーク３１に対して初期画面表示要求を発行する。
【0166】
フレームワーク３１のアプリケーション管理部３１６は、初期画面表示要求を受信すると、ホームアプリ７０（初期起動アプリ）に初期画面表示要求を発行する。なお、外部アプリの異常終了の場合、初期画面としてのホーム画面ではなく、バナーやフォールトでエラー通知してもよい。
【0167】
図２６は、外部から終了した場合のシーケンス図であり、ユーザが画像処理装置のWeb（ウェブ）UIから外部アプリ利用禁止設定をした場合のシーケンス図である。
【0168】
ユーザは、WebUI上で外部アプリの利用を禁止する設定を行う。WebUIは、外部アプリ利用禁止設定をデバイスサービス層３２に通知する。
【0169】
コンパニオンアプリ７４のイベント検知部７４５は、デバイスサービス層３２から外部アプリ利用設定が禁止になった旨の通知を受信すると、外部アプリプロセス管理部７４４に起動中の外部アプリが存在するか否かをチェックするように指示する。イベント検知部７４５は、起動中の外部アプリが存在し、かつ表示中の場合、フレームワーク３１に対して初期画面表示要求を発行するとともに、ウインドウ終了イベント（terminateWindow）を発行する。その引数はウインドウＩＤである。
【0170】
フレームワーク３１の画面制御部３１２は、ウインドウ終了イベント（terminateWindow）を受け付け、外部アプリが表示中である場合に、階層管理部３１５の表示中ウインドウを削除し、ウインドウ管理部３１４からウインドウ情報を削除する。また、デバイスサービス層３２に対してプロセス終了要求を発行する。デバイスサービス層３２は、このプロセス終了要求に応じて外部アプリを終了する。さらに、アプリケーション管理部３１６は、コンパニオンアプリ７４からの初期画面表示要求を受信し、初期画面起動アプリとしてのホームアプリ７０に初期画面表示要求を発行する。これにより、外部アプリが終了して初期画面としてホーム画面が表示される。
【0171】
図２７は、コンパニオンアプリ７４及びフレームワーク３１で制御・管理されるウインドウの階層構造を模式的に示す。
【0172】
フレームワーク３１は、コンパニオンアプリ７４からの外部アプリ起動要求を受信すると、ウインドウ管理情報として共通情報及び外部ウインドウ管理情報を生成し、外部ウインドウ管理情報として内部ブラウザへの埋め込み用のdiv要素を生成する。このdiv要素はダミーあるいはエイリアスとして機能し、透明なdiv要素である。フレームワーク３１はデバイスサービス層３２に対して外部アプリの起動を依頼し、デバイスサービス層３２は、外部アプリウインドウを非表示にするとともに内部ブラウザよりも下の階層に配置する。内部ブラウザは、アプリ層／ポップアップ層／バナー層／アラート（低レベル）層／アラート（高レベル）層／フォールト層の順で管理され、図では簡略化のためアプリ層及びフォールト層のみを示す。アプリ層にはダミーあるいはエイリアスとして内部ブラウザに埋め込まれたdiv要素が存在する。このdiv要素は、透明な枠だけのウインドウである。
【0173】
フレームワーク３１は、コンパニオンアプリ７４から外部アプリ表示要求を受信すると、div要素を表示するとともに、外部アプリウインドウを表示し、かつ、内部ブラウザを非表示とする。これにより、ユーザは外部アプリウインドウを視認することができ、外部アプリを操作できる。埋め込まれたdiv要素は、表示されているが透明であるため、ユーザの視認上は何らの影響も及ぼさない。他方で、このdiv要素が表示されていることで、フレームワーク３１は外部アプリが表示されていることを容易に把握することができ、内部アプリのウインドウ（iframeベース）に加えて外部ブラウザもウインドウの一種として取り扱い、内部アプリと同様のシームレスな管理が可能となる。何らかの異常が生じてフォールト層を表示する場合には、フレームワーク３１は、外部アプリウインドウを表示するとともに内部ブラウザを表示状態としてフォールトを最上位で表示する。これにより、外部アプリウインドウに重畳してフォールトを表示することができる。バナーについても同様である。ここで、「フォールト」は、システムに異常が生じた場合の表示で、「バナー」は、ジョブに関する情報を報知する場合の表示であり、通常、フォールトの方がバナーよりも優先度ないし緊急度が高いといえる。バナーとフォールトは互いにその機能及び伝えるべき情報が異なるため、これらは択一的に表示されるものではなく、バナーを表示するとともにフォールトも重畳表示する場合もあり得る。
【0174】
なお、外部アプリウインドウにバナーを重畳表示する場合、バナーの表示部分についてはバナー層の下にある外部アプリウインドウは隠れて見えないが、バナーの表示部分以外についてはシステム自体の異常ではないため外部アプリウインドウが見えて外部アプリを操作し得る必要があるところ、アプリ層には既述したように外部アプリウインドウの管理のためのダミーの透明div要素が存在するため、この透明div要素を通してバナーの表示部分以外の外部アプリウインドウを視認可能にできる。
【0175】
図２８（ａ）は、外部アプリを起動して外部アプリウインドウを表示した状態を示し、図２８（ｂ）は、外部アプリウインドウに重畳してバナーを表示した状態を示す。
【0176】
図２８（ａ）において、内部ブラウザは非表示状態であり、外部アプリウインドウが表示状態となってユーザは外部アプリを視認することができる。内部ブラウザは非表示であるが、ダミーの透明div要素は表示状態にある。この状態において、何らかの異常、例えば画像処理装置のカバーやドアがオープンとなった場合、フレームワーク３１の画面制御部３１２はバナー９０を画面の所定位置、例えば画面の下部に外部アプリウインドウに重畳して表示する。バナー９０の表示部分においては当然ながらその下の外部アプリウインドウは隠れて見えないが、バナー９０の表示部分以外は透明div要素が存在するため外部アプリウインドウ９２が見えている。ユーザは、バナー９０の表示部分以外の外部アプリウインドウ９２が見えている部分において外部アプリを操作すると、論理構成上は透明div要素を操作することになるから、フレームワーク３１のイベント検知部７４５がこのdiv要素に対するユーザの操作を検知してデバイスサービス層３２に対して当該操作に伴うイベントを通知し、デバイスサービス層３２が操作イベントを外部アプリに通知する。このように、外部アプリウインドウの上位階層が表示されていても、透明div要素を介在させることで外部アプリを操作することが可能となる。すなわち、ダミーとしての透明div要素は、内部アプリウインドウと外部アプリウインドウをシームレスに管理・制御する機能を有するとともに、外部アプリにバナーを重畳表示した場合にもバナーで隠れていない部分での外部アプリの操作を可能とする機能を有するといえる。
【0177】
本実施形態における「コンポーネント」とは、論理的に分離可能なソフトウェアの部品を意味する。コンポーネントは１つ又は複数のプロセッサによって実行され得る。本実施形態では、JavaScriptを用いているが、勿論これ以外のプログラミング言語を用いることもできる。
【0178】
また、本発明は上記の実施形態に限定されるものではなく、種々の変形例が可能である。以下に、変形例について説明する。
【0179】
＜変形例１＞
実施形態では、画像処理装置１２の制御部（プロセッサ）２２が、プレゼンテーション層３０のフレームワーク３１及び各種アプリケーション５０を実行するものとしているが、図２に示すように、プレゼンテーション層３０とデバイスサービス層３２は分離しているから、プレゼンテーション層３０のフレームワーク及び各種アプリケーション５０を画像処理装置１２と異なる別個の装置、例えば画像処理装置１２を制御するためのスマートフォンやタブレット端末等の携帯端末のプロセッサが実行する構成としてもよい。また、図１における操作部２６も携帯端末に搭載されることが望ましい。この場合、携帯端末と画像処理装置１２とを併せて画像処理装置ないし画像処理システムと言うことができる。
【0180】
＜変形例２＞
実施形態では、フォールト及びバナーを例示的に説明しているが、必ずしもこれに限定されるものではなく、アプリケーション層よりも上位の階層に表示される全てのウインドウに関して、外部アプリウインドウを覆い隠すことができ、ウインドウ自身が半透明ならば外部アプリウインドウが透けて見えるとの条件を満たせばよい。
【符号の説明】
【0181】
１０ 端末装置、１２ 画像処理装置、１６ ＲＯＭ、１８ ＲＡＭ、２０ ＨＤＤ、２４ 入出力インターフェイスＩ／Ｆ、２６ 操作部、２８ 画像処理部、３０ プレゼンテーション層、３１ フレームワーク、３２ デバイスサービス層、５０ アプリケーション、５２ コアロジック(Core Logic)、５４ ＵＩフレーム(UI frame)、５６ マニフェストファイル、７４，７５，７６，７８ コンパニオンアプリ。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【図25】
【図26】
【図27】
【図28】
Copyright © 2010-2025 Science Impact Inc. All Rights Reserved.