JP2018051799A - 画像形成装置及びプログラム - Google Patents

Abstract

【課題】アプリケーション相互の依存関係を抑制し、アプリケーションの追加や削除を容易化し得る画像形成装置及びプログラムを提供する。
【解決手段】画像形成装置は、基本処理を担うコアロジック部、描画処理を担うＵＩフレーム部、及びアプリケーションの静的情報を規定するマニフェストファイル部に分離され、フレームワーク上で動作するアプリケーション５０と、アプリケーション及びフレームワークを実行する制御手段を備える。コアロジック部はフレームワークが定義するインターフェイス（Ｉ／Ｆ）を実装する。特定のアプリケーション５０のコアロジック部は、ログイン時に利用者情報を一括してユーザコンテキスト(User Context)８０に保存し、他のアプリケーションはこれを参照する構成とする。
【選択図】図１５

Description

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

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

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

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

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

ところで、従来においては、画像形成装置のシステムとして、巨大なルートアプリケーションを用意して各アプリケーションから利用される種々の機能を提供しており、全てのアプリケーションはこのルートアプリケーションに依存している。

また、画像形成装置の各種のデバイス状態を専門に扱うデバイスアプリケーションも別個に存在しており、ほぼ全てのアプリケーションがこのデバイスアプリケーションに依存している。

さらに、アプリケーション間での実装共通化が進んでおり、アプリケーション間での依存関係も生じている。

従って、アプリケーションを追加する場合や削除する場合でも、その都度アプリケーション間で調整が必要となり、これと同時に、ルートアプリケーションの修正も常に必要となることから、容易にアプリケーションの追加や削除ができない問題があった。

本発明の目的は、アプリケーション相互の依存関係を抑制し、アプリケーションの追加や削除を容易化し得る画像形成装置及びプログラムを提供することにある。

請求項１に記載の発明は、基本処理を担うコアロジック部、及び描画処理を担うＵＩフレーム部に分離され、フレームワーク上で動作するアプリケーションと、アプリケーション及びフレームワークを実行する制御手段とを備え、コアロジック部はフレームワークが定義するインターフェイス（Ｉ／Ｆ）を実装し、複数アプリケーションの中の特定アプリケーションのコアロジック部は、利用者情報を一括してユーザコンテキストに保存し、他のアプリケーションのコアロジック部は、ユーザコンテキストから利用者情報を取得する画像形成装置である。

請求項２に記載の発明は、複数アプリケーションの中の特定アプリケーションのコアロジック部は、利用者のログインに連動して利用者情報をユーザコンテキストに保存する請求項１に記載の画像形成装置である。

請求項３に記載の発明は、アプリケーションのコアロジック部は、画面の一番上に表示されるタイミングでユーザコンテキストから利用者情報を取得する請求項１，２のいずれかに記載の画像形成装置である。

請求項４に記載の発明は、基本処理を担うコアロジック部、及び描画処理を担うＵＩフレーム部に分離され、フレームワーク上で動作するアプリケーションと、アプリケーション及びフレームワークを実行する制御手段とを備え、コアロジック部はフレームワークが定義するインターフェイス（Ｉ／Ｆ）を実装し、複数アプリケーションの中の特定アプリケーションのコアロジック部は、システム固有情報を一括してグローバルコンテキストに保存し、他のアプリケーションのコアロジック部は、グローバルコンテキストからシステム固有情報を取得する画像形成装置である。

請求項５に記載の発明は、画像形成装置を制御するプロセッサに実行させるプログラムであって、基本処理を担うコアロジック部と、描画処理を担うＵＩフレーム部に分離されており、コアロジック部は、フレームワークが定義するインターフェイス（Ｉ／Ｆ）を実装し、システム起動時にフレームワークによりロードされ、利用者のログインに連動して利用者情報を一括してユーザコンテキストに保存させるプログラムである。

請求項１，５に記載の発明によれば、アプリケーション相互の依存関係を抑制し、アプリケーションの追加や削除を容易化できるとともに、複数のアプリケーションにおける利用者情報の利用が容易化される。

請求項２に記載の発明によれば、さらに、ログインに連動させて利用者情報を変更することができる。

請求項３に記載の発明によれば、さらに、複数のアプリケーションによるアクセスを低減できる。

請求項４に記載の発明によれば、アプリケーション相互の依存関係を抑制し、アプリケーションの追加や削除を容易化できるとともに、複数のアプリケーションにおけるシステム固有情報の利用が容易化される。

画像形成装置の機能ブロック図である。 システムの論理構成図である。 ホーム画面の一例を示す説明図である。 アプリケーションの論理構成図である。 従来システムの論理構成図である。 フレームワーク上のアプリケーションの構成図である。 アプリケーションの具体的構成例を示す説明図である。 アプリケーションリストの具体的構成例を示す説明図である。 コアロジックとＵＩフレームのパターンを示す説明図である。 ＵＩ及びロジック変更時の説明図である。 フレームワーク上のアプリケーションのパターンを示す説明図である。 ブータ及びスタータを含むライフサイクル管理のシステム構成図である。 ライフサイクル管理のフローチャートである。 システム起動からホーム画面が表示されるまでの時間を示すグラフ図である。 ユーザコンテキスト(User Context)の説明図である。 ユーザコンテキスト(User Context)の操作処理フローチャート（その１）である。 ユーザコンテキスト(User Context)の操作処理フローチャート（その２）である。 ユーザコンテキスト(User Context)の操作処理フローチャート（その３）である。 ユーザコンテキスト(User Context)の操作処理フローチャート（その４）である。 ログイン時の画面説明図である。 グローバルコンテキスト（Global Context）の説明図である。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

プレゼンテーション層３０は、各種アプリケーションを実装する層であり、フレームワーク３１と、各種アプリケーションを含む。フレームワーク３１は、コンピュータシステム上でJavaScript（登録商標）アプリケーションを動かせるようにする実行環境ソフトウェア群である。より具体的には、JavaScriptはWebブラウザ上で実行され、BaseFrameとUIFrameは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.htmと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)５２のみをロードするので、システム起動時間及びアプリケーション起動時間が短縮される。

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

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

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

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

次に、ホーム画面が表示された後、利用者がログインを行う場合の処理について説明する。

従来においては、利用者がログインする場合、各アプリケーションは利用者がログインしたことを下層からイベント通知を受け、利用者変更の処理を行っている。すなわち、現在ログインしている利用者の情報を各アプリケーションがそれぞれ独自に取得している。

これに対し、実施形態では、起動されているアプリケーションが多くなると下層に利用者情報を取りにいくとその分だけ時間を要してしまうことに鑑み、ログイン処理を担当するアプリケーションが下層から利用者情報を取得して一括してまとめて保存し、各アプリケーションはまとめて保存された利用者情報を参照する構成としている。

図１５は、実施形態におけるログイン時の処理を模式的に示す。利用者のログイン時、各種アプリケーション５０の中のログインを担当するアプリケーション（認証App、あるいはAuthアプリ）が下層から当該利用者の情報を取得し、ユーザコンテキスト(User Context)８０内に保存する。そして、認証App以外のアプリケーションは、利用者情報を取得する場合には、下層まで取りにいくのではなく、認証Appが作成した（より特定的には認証Appのコアロジック(Core Logic)５２が作成した）ユーザコンテキスト(User Context)８０を参照することで必要な利用者情報を取得する。これにより、従来に比べて短時間で利用者情報を容易に取得することができる。ユーザコンテキスト８０は、例えば、
ＵＣ１：Ａｃｔｉｖｅ
ＵＣ０：Ｉｎａｃｔｉｖｅ
ＵＣ２：Ｉｎａｃｔｉｖｅ
ＵＣ３：Ｉｎａｃｔｉｖｅ
と作成される。ここで、Ａｃｔｉｖｅはアクティブな状態であることを示し、Ｉｎａｃｔｉｖｅは非アクティブな状態であることを示す。アクティブ、非アクティブについては後述する。

図１６〜図１９は、ログインに連動したユーザコンテキスト(User Context)８０の操作フローチャートを示す。

まず、図１６は、システム起動時の処理である。ログインを担当する認証Appは、デフォルトの利用者情報を下層から取得する。次に、デフォルトのユーザコンテキスト(User Context)８０としてＤＵＣを作成する（Ｓ１０１）。

次に、作成したＤＵＣに下層から取得したデフォルトの利用者情報を設定する（Ｓ１０２）。そして、デフォルトの利用者情報が設定されたＤＵＣをアクティブにする（Ｓ１０３）。

図１７は、利用者がログインする場合の処理である。認証Appは、ログインする利用者の名前（ログインユーザ名）を取得する（Ｓ２０１）。

次に、ログインユーザの情報を下層から取得する（Ｓ２０２）。

次に、ユーザコンテキスト(User Context)８０を作成し（Ｓ２０３）、このユーザコンテキスト(User Context)８０（これをＵＣ１とする）にＳ２０３で取得したログインユーザの情報を設定する（Ｓ２０４）。そして、ログインユーザの情報が設定されたＵＣ１をアクティブにする（Ｓ２０５）。このとき、他にアクティブなUCがあれば、そのUCはインアクティブとなる。(アクティブなUCは高々一つ)

図１８は、ログイン後の各アプリケーション５０の処理である。各アプリケーション５０は、アクティブとなっているユーザコンテキスト(User Context)８０を参照する（Ｓ３０１）。ここで、アクティブとなっているのはＵＣ１であるから、ＵＣ１を参照する。

そして、アクティブなユーザコンテキスト(User Context)８０であるＵＣ１から必要な利用者情報を取得する（Ｓ３０２）。

図１９は、利用者がログアウトする場合の処理である。まず、認証Appは、現在アクティブとなっているユーザコンテキスト(User Context)８０を取得する（Ｓ４０１）。下層に対してログアウトを指示する。次に、デフォルトの利用者情報を下層から取得する。次に、デフォルトのユーザコンテキスト(User Context)としてＤＵＣを作成し、作成したＤＵＣに下層から取得したデフォルトの利用者情報を設定する。そして、これに代えてデフォルトのユーザコンテキスト(User Context)８０をアクティブとする（Ｓ４０３）。アクティブとなっていたユーザコンテキスト(User Context)８０を破棄する（Ｓ４０２）。

利用者がログインする毎に、新たなユーザコンテキスト(User Context)８０が作成され、そこに当該利用者の情報が設定されてアクティブとなることが理解されよう。

図２０は、ログイン時の画面を示す。図２０（ａ）は初期画面であり、所定位置に「ログイン(Login)」アイコンが表示される。このアイコンにはログインを担当するアプリケーションである認証Appが対応付けられている。このときのユーザコンテキスト(User Context)８０はデフォルトのユーザコンテキスト(User Context)８０、つまりＤＵＣである。

図２０（ｂ）は、利用者がログインアイコンを操作した場合の画面例である。ユーザ名とパスワードの入力画面に遷移する。利用者がユーザ名とパスワードを入力すると、認証Appが入力されたユーザ名とパスワードを照合し、正当な利用者であることを認証すると、
新たにユーザコンテキスト(User Context)８０を作成し、そこにログインした利用者の情報を設定してアクティブとする。

各アプリケーション５０は、ユーザコンテキスト(User Context)８０が新たに変更されると、新たな利用者情報をアクティブなユーザコンテキスト(User Context)８０から取得するが、全てのアプリケーション５０がユーザコンテキスト(User Context)８０の情報を取りにいくと、従来のように下層まで取りにいく場合と比べて効率的であるものの、アクセス数は同様に多くなる。

そこで、各種アプリケーション５０の中で表示画面を支配しているアプリケーションは画面上の一番上にあるアプリケーションに限定されることに着目し、自分が画面上で一番上として表示される時に、当該アプリケーションがアクティブなユーザコンテキスト(User Context)８０を参照してログインした利用者の情報を取得する構成とすることで、アクセス数を低減することができる。

図２０（ｃ）は、ログイン処理後の画面である。ホーム画面を描画するアプリケーションが画面上の一番上にあり、アクティブなユーザコンテキスト(User Context)８０を参照してログインした利用者の情報を取得し、画面の所定位置（図ではログインアイコンの位置）に利用者名（図ではMr.A）を表示する。

ユーザコンテキスト(User Context)８０には、利用者情報が設定されるが、具体的には以下のような情報が設定され得る。
・利用者名（ユーザ名）
・ユーザアイコン
・ユーザ表示言語
・ユーザキーボード言語、ユーザ入力言語
例えばユーザ表示言語の場合、利用者がログインすると、認証Appがログインした利用者のＩＤを取得してユーザコンテキスト(User Context)８０に保存するとともに、当該利用者の利用者情報の一つとして表示言語をユーザコンテキスト(User Context)８０に保存する。次に、各種アプリケ−ション５０の中のApp１に遷移し、App１がユーザコンテキスト(User Context)８０を参照して表示言語を取得し、その表示言語に従って画面を作成して表示する。同様に、別のApp２に遷移すると、App２がユーザコンテキスト(User Context)８０を参照して表示言語を取得し、その表示言語に従って画面を作成して表示する。

以上は、利用者情報に関する処理であるが、システムには利用者情報以外にもシステム設定値という固有情報もある。具体的には、プロダクト保存情報や機械固有情報等である。従来においては、これらの固有情報も各アプリケーションが必要となった時（特にシステム起動時）に各アプリケーションが下層に取りにいっているが、このような固有情報も同様に特定のアプリケーションが下層から取得し、一括してまとめてコンテキストとして保存し、各アプリケーションはこのコンテキストを参照する構成とすることができる。

図２１は、この場合の構成を模式的に示す。システム起動時、各種アプリケーション５０の中の担当アプリケーション（図では認証Appとしているがこれに限定されない）が下層から当該利用者の情報を取得し、グローバルコンテキスト(Global Context)８２内に保存する。そして、各種アプリケーション５０は、固有情報を取得する場合には、下層まで取りにいくのではなく、認証Appが作成したグローバルコンテキスト(Global Context)８２を参照することで必要な固有情報を取得する。これにより、従来に比べて短時間で固有情報を容易に取得することができる。システム起動時において、まずフレームワーク３１がデフォルトのグローバルコンテキスト(Global Context)８２を作成し、その後に担当アプリケーションが固有情報を取得してグローバルコンテキスト(Global Context)８２に設定する構成としてもよい。

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

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

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

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

Claims (5)

1. 基本処理を担うコアロジック部、及び描画処理を担うＵＩフレーム部に分離され、フレームワーク上で動作するアプリケーションと、
   アプリケーション及びフレームワークを実行する制御手段と、
   を備え、コアロジック部はフレームワークが定義するインターフェイス（Ｉ／Ｆ）を実装し、
   複数アプリケーションの中の特定アプリケーションのコアロジック部は、利用者情報を一括してユーザコンテキストに保存し、他のアプリケーションのコアロジック部は、ユーザコンテキストから利用者情報を取得する
   画像形成装置。
2. 複数アプリケーションの中の特定アプリケーションのコアロジック部は、利用者のログインに連動して利用者情報をユーザコンテキストに保存する
   請求項１に記載の画像形成装置。
3. アプリケーションのコアロジック部は、画面の一番上に表示されるタイミングでユーザコンテキストから利用者情報を取得する
   請求項１，２のいずれかに記載の画像形成装置。
4. 基本処理を担うコアロジック部、及び描画処理を担うＵＩフレーム部に分離され、フレームワーク上で動作するアプリケーションと、
   アプリケーション及びフレームワークを実行する制御手段と、
   を備え、コアロジック部はフレームワークが定義するインターフェイス（Ｉ／Ｆ）を実装し、
   複数アプリケーションの中の特定アプリケーションのコアロジック部は、システム固有情報を一括してグローバルコンテキストに保存し、他のアプリケーションのコアロジック部は、グローバルコンテキストからシステム固有情報を取得する
   画像形成装置。
5. 画像形成装置を制御するプロセッサに実行させるプログラムであって、
   基本処理を担うコアロジック部と、描画処理を担うＵＩフレーム部に分離されており、コアロジック部は、フレームワークが定義するインターフェイス（Ｉ／Ｆ）を実装し、システム起動時にフレームワークによりロードされ、
   利用者のログインに連動して利用者情報を一括してユーザコンテキストに保存させる、
   プログラム。
   

Images