JP6852331B2

JP6852331B2 - 画像形成装置及びプログラム

Info

Publication number: JP6852331B2
Application number: JP2016187281A
Authority: JP
Inventors: 森田　雅夫; 雅夫森田; 雅紀佐竹; 道村　唯夫; 唯夫道村
Original assignee: Fuji Xerox Co Ltd; Fujifilm Business Innovation Corp
Current assignee: Fujifilm Business Innovation Corp
Priority date: 2016-09-26
Filing date: 2016-09-26
Publication date: 2021-03-31
Anticipated expiration: 2036-09-26
Also published as: CN107870747A; CN107870747B; US20180091680A1; JP2018051797A; US10182168B2

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」する等である。

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

ブータ(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)５２のみをロードするので、システム起動時間及びアプリケーション起動時間が短縮される。

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

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

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

ホーム画面が表示された後は、利用者が適宜所望のボタンを操作して所望のジョブを実行させるが、各アプリケーション５０は、画像出力モジュール、画像入力モジュール、ファックスモジュール、用紙給紙モジュール、原稿給紙モジュール、画像処理アクセラレータ等のハードウェアデバイスを使用するため、ジョブを実行する前に必ずデバイスの状態を確認し、デバイスが何らかの要因で正常に動作できない場合に、例えば該当するアプリケーションのボタンを非表示とする等、利用者がアプリケーションを選択できないような構成とするのが望ましい。

図１５は、操作部２６に表示されるホーム画面例である。通常であれば、コピー(Copy)ボタン３４、スキャン(Scan)ボタン３８、ファックス(Fax)ボタン４０が表示されるところ、画像出力モジュールが正常に動作しないためコピー機能及びファックス機能が実行できない場合に、コピー(Copy)ボタン３４及びファックス(Fax)ボタン４０を非表示とし、スキャン(Scan)ボタン３８のみを表示している状態を示す。

このように、ハードウェアデバイスに不具合が生じた場合に対応する機能のボタンを非表示とするには、例えばフレームワーク３１にハードウェアデバイスの状態を監視し、ハードウェアデバイスに不具合が生じているときにアプリケーション５０のボタンを非表示とする機能を付加しておくことが考えられる。

図１６は、フレームワーク３１に、アプリケーション５０の中のコピー(Copy)アプリケーション５０ａ、スキャン(Scan)アプリケーション５０ｂ、ファックス(Fax)アプリケーション５０ｃに共通する機能として、ハードウェアデバイス（図ではIOTデバイスとして示す）を監視する機能と、ハードウェアデバイスが使えない場合にアプリケーションボタンを消す機能を実装する場合を模式的に示す。これは、各アプリケーション５０に共通する機能があれば、当該機能をフレームワーク３１側に実装するとの考えによるものである。また、特定のアプリケーション５０しか使用しない機能であっても、比較的複雑であるためフレームワーク３１側に実装してしまうとの考えもある。さらに、以前のバージョンでは共通機能であったため、その設計思想を引き継いでフレームワーク３１側に実装させておくという考えもあり得る。

但し、このようにフレームワーク３１側に実装してしまうと、フレームワーク３１が肥大化してしまう。また、特定のアプリケーション５０に仕様変更があり、多少なりとも共通機能を修正する必要が生じた場合に、共通実装をそのまま維持するためには当該特定のアプリケーションからの呼び出しであることを見分けられるようにして、当該特定のアプリケーションからの呼び出しのときだけ別のコードが動作するように構成することが必要となり、このような構成ではもはや共通機能の実装ではなくなる。

そこで、本実施形態では、アプリケーション５０の共通機能は全てフレームワーク３１に実装するのではなく、アプリケーション固有の判断はそれぞれのアプリケーションに委ね、各アプリケーション５０がハードウェアデバイスの状態を監視するとともに、ホーム画面を作成するホームアプリケーションが各アプリケーションに問い合わせ、各アプリケーションのボタンを表示するか否かを確認する構成とする。他方、このような構成では、フレームワーク３１の肥大化を防止できるものの、各アプリケーションはそれぞれのハードウェアデバイスを監視する機能を実装することになり、各アプリケーションが個別に情報を取りに行くと取得回数が増えてしまい、また、各アプリケーションがフレームワーク３１の下の階層に情報を取りに行くと呼び出し時間も増えてしまう。

このため、本実施形態では、ある特定のアプリケーション（以下、これをデバイス(Device)アプリケーションという）が他のアプリケーションに代わってまとめてハードウェアデバイスの状態を監視してハードウェアデバイスの状態情報を取得し、これを保持しておく。各アプリケーションは、個別にハードウェアデバイスの情報を取りに行くのではなく、デバイス(Device)アプリケーションに問い合わせて自分に関連するハードウェアデバイスの状態を取得する。かかる構成により、各アプリケーションが個別に情報を取りに行くと取得回数が増えてしまい、また、各アプリケーションがフレームワーク３１の下の階層に情報を取りに行くと呼び出し時間も増えてしまう問題を解消できる。

なお、各アプリケーションが自分に関連するハードウェアデバイス情報を取得した後は、ホーム画面を作成し表示するホームアプリケーションが各アプリケーションに問い合わせをし、その結果に応じてボタンを表示するか否かを決定すればよい。

デバイス(Device)アプリケーションがハードウェアデバイスの状態を監視して各アプリケーションに知らせ、ホームアプリケーションが各アプリケーションに問い合わせをして各アプリケーションのボタンを表示するか否かを決定する場合、各アプリケーションが既に動作状態にあることが前提となるが、本実施形態では既述したように全てのアプリケーション５０のコアロジック(Core Logic)５２をロードして起動状態にあるので、デバイス(Device)アプリケーションが各アプリケーションに通知し、かつ、ホームアプリケーションが各アプリケーションに問い合わせることが可能である。

図１７は、本実施形態におけるホーム画面のボタン表示処理を模式的に示す。デバイス(device)アプリケーション５０ｅのコアロジック部は、ハードウェアデバイスの状態として、画像出力モジュール（ＩＯＴ）、画像入力モジュール（ＩＩＴ）、モデム、及び画像処理ハードウェア（ＨＷ）の状態を調査し、これらが正常に動作するか否かの情報を取得して保持しておく。あるいは、デバイス(Device)アプリエーション５０ｅのコアロジック部は、各ハードウェアデバイスから状態変化通知を受け取る。デバイス(device)アプリケーション５０ｅのコアロジック部は、一定の順序で各ハードウェアデバイスの状態を監視してもよいし、順不同で監視してもよい。あるいは、状態が変化し正常に動作し得ないハードウェアデバイスから状態変化通知を受け取ってもよい。デバイス(Device)アプリケーション５０ｅのみが各ハードウェアデバイスの状態を監視するので、各アプリケーションが個別に状態を監視する場合に比べて取得回数が低減される。

デバイス(Device)アプリケーション５０ｅが情報を取得すると、各アプリケーション５０ａ、５０ｂ、５０ｃは、デバイス(Device)アプリケーション５０ｅに対して自分に関連するハードウェアデバイスの状態を問い合わせて取得する。具体的には、コピー(Copy)アプリケーション５０ａのコアロジック(Core Logic)５２は、自分に関連するＩＯＴの状態及びＩＩＴの状態を問い合わせて取得し、スキャン(Scan)アプリケーション５０ｂのコアロジック(Core Logic)５２は、自分に関連するＩＩＴ及び画像処理ハードウェアの状態を問い合わせて取得し、ファックス(Fax)アプリケーション５０ｃのコアロジック(Core Logic)５２は、自分に関連するＩＩＴ及びモデムの状態を取り合わせて取得する。各アプリケーション５０ａ，５０ｂ，５０ｃは、フレームワーク３１の下の階層に問い合わせるのではなく、フレームワーク３１上で動作するデバイス(Device)アプリケーション５０ｅに問い合わせて取得するので、短時間に必要な情報を取得できる。
また、各アプリケーションは、自身が必要とするデバイス情報が変化した場合に通知してもらうように、デバイスアプリに依頼することもできる。

図１８は、各アプリケーション５０ａ、５０ｂ、５０ｃがそれぞれ自分に関連するハードウェアデバイスの状態情報を取得した後の処理を模式的に示す。ホーム画面を作成するホームアプリケーション５０ｄのコアロジック(Core Logic)５２は、それぞれのアプリケーションのコアロジック(Core Logic)５２に問い合わせて、それぞれのアプリケーションに関連するハードウェアデバイスが正常に動作するか否かの情報を取得し、取得した情報に応じてそれぞれのアプリケーションのボタンを表示するか否かを決定する。

具体的には、各アプリケーションが保持している情報が、
コピー(Copy)アプリケーション５０ａ：異常
スキャン(Scan)アプリケーション５０ｂ：正常
ファックス(Fax)アプリケーション５０ｃ：異常
である場合、ホームアプリケーション５０のコアロジック(Core Logic)５２は、これに応じて各アプリケーションのボタンを
ボタン３４：非表示
ボタン３８：表示
ボタン４０：非表示
とする（図１５参照）。

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

また、フレームワーク３１を徒に肥大化させることなく、ホーム画面における各アプリケーション５０のボタンの表示／非表示を効率的に実行できる。

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

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

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

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

Claims

基本処理を担うコアロジック部、及び描画処理を担うＵＩフレーム部に分離され、フレームワーク上で動作するアプリケーションと、
アプリケーション及びフレームワークを実行する制御手段と、
を備え、コアロジック部はフレームワークが定義するインターフェイス（Ｉ／Ｆ）を実装し、
フレームワークは、システム起動時に、複数のアプリケーションの全コアロジック部をロードし、
複数のアプリケーションの中で、デバイスアプリケーションのコアロジック部は、他のアプリケーションの実行に関連するデバイスの状態を監視してその情報を保持し、
他のアプリケーションのコアロジック部は、デバイスアプリケーションからデバイスの情報を取得して表示情報として保持し、
ホーム画面を表示するホームアプリケーションのコアロジック部は、他のアプリケーションのコアロジック部に問い合わせて表示情報を取得して表示する
画像形成装置。
表示情報は、デバイスの状態に応じたアイコンの表示情報であり、
ホームアプリケーションのコアロジック部は、他のアプリケーションの実行に関連するデバイスが正常に動作しない場合にアイコンを非表示とし、他のアプリケーションの実行に関連するデバイスが正常に動作する場合にアイコンを表示する
請求項１に記載の画像形成装置。
画像形成装置を制御するプロセッサに実行させるプログラムであって、
基本処理を担うコアロジック部と、描画処理を担うＵＩフレーム部に分離されており、
コアロジック部は、フレームワークが定義するインターフェイス（Ｉ／Ｆ）を実装し、
フレームワークは、システム起動時に、複数のアプリケーションの全コアロジック部をロードし、
複数のアプリケーションの中でデバイスアプリケーションのコアロジック部は、他のアプリケーションの実行に関連するデバイスの状態を監視してその情報を保持し、他のアプリケーションのコアロジック部は、デバイスアプリケーションからデバイスの情報を取得して表示情報として保持し、ホーム画面を表示するホームアプリケーションのコアロジック部は、他のアプリケーションのコアロジック部に問い合わせて表示情報を取得して表示する、
プログラム。