図面 (/)

技術 仲介装置及びプログラム

出願人 富士ゼロックス株式会社
発明者 高岡聡嶋立紀世子
出願日 2017年10月16日 (3年2ヶ月経過) 出願番号 2017-200469
公開日 2019年5月16日 (1年7ヶ月経過) 公開番号 2019-074920
状態 未査定
技術分野 マルチプログラミング
主要キーワード 操作メニュ 未ロード 要素処理 インチ単位 装置エラー 挿入済み ソフトウエア要素 情報項目毎
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2019年5月16日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (20)

課題

通知元が発した通知を、その通知の宛先のプログラムに常に通知する方式では、プログラムがその情報を受け取っても実際には利用せずに終わる場合にも通知が行われることになり、通知やそのための処理が無駄になる。

解決手段

プログラム管理部120は、各表示プログラム114の表示態様(例えば前面表示、非表示等)を管理している。通知仲介部130は、外部モジュール200から通知が到来した場合、その通知の宛先(例えば通知が示す情報項目によって決まる)の表示プログラム114が前面表示状態であれば、その通知を直ちにその表示プログラム114に渡す。一方、その宛先の表示プログラム114が非表示状態であれば、その通知を渡さない。通知仲介部130は、その通知の内容をキャッシュする。非表示状態であった宛先の表示プログラム114が前面表示となった際、通知仲介部130のキャッシュを参照することで、通知の内容を知る。

概要

背景

特許文献1には、ファイアウォールの介在等によりイベントを直接通知できない端末間でのイベント通知を効率よく行うためにイベント通知仲介システムを設けることが開示されている。

特許文献2に開示された装置は、バックグラウンドで処理を実行可能な情報処理装置であって、アプリケーションからの要求に応じて処理が実行される際に、バックグラウンドにおける別の処理の実行を制御する制御手段を備える。制御手段は、アプリケーションからの要求に応じて、別の処理がバックグラウンドにて実行されないように抑制し、アプリケーションから抑制の解除の要求が指示されない場合、抑制を開始してから所定の期間が経過した際に、抑制を解除する。

特許文献3に開示された装置は、スレッドとして実行されるアプリケーションのライフサイクルの管理を行うアプリケーション管理手段と、アプリケーションのライフサイクルに影響する画像形成装置のイベントをアプリケーション管理手段に通知するイベント通知手段とを備える。

概要

通知元が発した通知を、その通知の宛先のプログラムに常に通知する方式では、プログラムがその情報を受け取っても実際には利用せずに終わる場合にも通知が行われることになり、通知やそのための処理が無駄になる。プログラム管理部120は、各表示プログラム114の表示態様(例えば前面表示、非表示等)を管理している。通知仲介部130は、外部モジュール200から通知が到来した場合、その通知の宛先(例えば通知が示す情報項目によって決まる)の表示プログラム114が前面表示状態であれば、その通知を直ちにその表示プログラム114に渡す。一方、その宛先の表示プログラム114が非表示状態であれば、その通知を渡さない。通知仲介部130は、その通知の内容をキャッシュする。非表示状態であった宛先の表示プログラム114が前面表示となった際、通知仲介部130のキャッシュを参照することで、通知の内容を知る。

目的

プログラム管理部120は、ライフサイクル管理モジュール122及び表示態様管理モジュール124に管理されている各表示プログラムのライフサイクルや表示態様の情報を、他のプログラムに提供する

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

(分野番号表示ON)※整理標準化データをもとに当社作成

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

通知元から通知を受信する受信手段と、受信した前記通知の宛先のプログラムの状態に応じて、その通知を前記プログラムに渡すか否かを制御する通知制御手段と、を含む仲介装置

請求項2

前記プログラムの状態とは、当該プログラムが生成した表示要素の表示に関する状態であり、前記通知制御手段は、前記宛先のプログラムが生成した表示要素が表示されている状態であれば前記通知を当該プログラムに渡し、当該表示要素が表示されていない状態であれば前記通知を当該プログラムに渡さない、請求項1に記載の仲介装置。

請求項3

前記通知制御手段は、前記宛先のプログラムが生成した表示要素が表示されていない状態であっても、当該プログラムの前記状態が予め登録された特定の状態である場合には、前記通知を当該プログラムに渡す、請求項2に記載の仲介装置。

請求項4

前記プログラムの状態とは、当該プログラムのライフサイクル状態であり、前記通知制御手段は、前記宛先のプログラムのライフサイクル状態が、メモリ上にロード済みである状態であれば前記通知を当該プログラムに渡し、前記ライフサイクル状態が前記メモリ上にロードされていない状態であれば前記通知を当該プログラムに渡さない、請求項3に記載の仲介装置。

請求項5

前記通知制御手段は、前記宛先のプログラムの前記ライフサイクル状態が、前記メモリ上にロード中の状態であれば、ロードが完了したときに前記通知を当該プログラムに渡す、請求項4に記載の仲介装置。

請求項6

各プログラムからそれぞれ当該プログラムがどの状態のときに通知を受け取るかを示す通知設定を記憶する設定記憶手段、を更に含み、前記通知制御手段は、前記宛先のプログラムの状態が当該プログラムの前記通知設定の示す状態に該当すれば前記通知を当該プログラムに渡し、そうでなければ前記通知を当該プログラムに渡さない、請求項1に記載の仲介装置。

請求項7

前記通知設定は、前記プログラムと前記通知の対象である情報項目との組合せ毎に、当該プログラムがどの状態の時に当該情報項目についての前記通知を受け取るかを示すものであり、前記通知制御手段は、前記宛先のプログラムが、当該宛先のプログラムと、前記受信手段が受信した前記通知の対象である前記情報項目と、の組合せに対応する前記通知設定が示す状態に該当すれば前記通知を当該プログラムに渡し、そうでなければ前記通知を当該プログラムに渡さない、請求項6に記載の仲介装置。

請求項8

前記各プログラムを管理する常駐プログラムから、前記各プログラムについての前記通知設定の登録を受け付けて前記設定記憶手段に記憶させる手段、を更に含む請求項7に記載の仲介装置。

請求項9

前記常駐プログラムから登録された前記各プログラムの各通知設定に含まれる前記通知の対象の前記情報項目のリストを、通知して欲しい情報項目を示すリストとして前記通知元に登録する手段、を更に含む請求項8に記載の仲介装置。

請求項10

各プログラムからそれぞれ当該プログラムがどの状態のときに通知を受け取らないかを示す通知設定を記憶する手段、を更に有し、前記通知制御手段は、前記宛先のプログラムの状態が当該プログラムの前記通知設定の示す状態に該当すれば前記通知を当該プログラムに渡さず、そうでなければ前記通知を当該プログラムに渡す、請求項1に記載の仲介装置。

請求項11

コンピュータを、通知元から通知を受信する受信手段、受信した前記通知の宛先のプログラムの状態に応じて、その通知を前記プログラムに渡すか否かを制御する通知制御手段、として機能させるためのプログラム。

技術分野

0001

本発明は、仲介装置及びプログラムに関する。

背景技術

0002

特許文献1には、ファイアウォールの介在等によりイベントを直接通知できない端末間でのイベント通知を効率よく行うためにイベント通知仲介システムを設けることが開示されている。

0003

特許文献2に開示された装置は、バックグラウンドで処理を実行可能な情報処理装置であって、アプリケーションからの要求に応じて処理が実行される際に、バックグラウンドにおける別の処理の実行を制御する制御手段を備える。制御手段は、アプリケーションからの要求に応じて、別の処理がバックグラウンドにて実行されないように抑制し、アプリケーションから抑制の解除の要求が指示されない場合、抑制を開始してから所定の期間が経過した際に、抑制を解除する。

0004

特許文献3に開示された装置は、スレッドとして実行されるアプリケーションのライフサイクルの管理を行うアプリケーション管理手段と、アプリケーションのライフサイクルに影響する画像形成装置のイベントをアプリケーション管理手段に通知するイベント通知手段とを備える。

先行技術

0005

国際公開第2009/088048号
特開2005−269439号公報
特開2016−100731号公報

発明が解決しようとする課題

0006

通知元が発した通知を、その通知の宛先のプログラムに常に通知する方式では、プログラムがその情報を受け取っても実際には利用せずに終わる場合にも通知が行われることになり、通知やそのための処理が無駄になる場合がある。

課題を解決するための手段

0007

請求項1に係る発明は、通知元から通知を受信する受信手段と、受信した前記通知の宛先のプログラムの状態に応じて、その通知を前記プログラムに渡すか否かを制御する通知制御手段と、を含む仲介装置である。

0008

請求項2に係る発明は、前記プログラムの状態とは、当該プログラムが生成した表示要素の表示に関する状態であり、前記通知制御手段は、前記宛先のプログラムが生成した表示要素が表示されている状態であれば前記通知を当該プログラムに渡し、当該表示要素が表示されていない状態であれば前記通知を当該プログラムに渡さない、請求項1に記載の仲介装置である。

0009

請求項3に係る発明は、前記通知制御手段は、前記宛先のプログラムが生成した表示要素が表示されていない状態であっても、当該プログラムの前記状態が予め登録された特定の状態である場合には、前記通知を当該プログラムに渡す、請求項2に記載の仲介装置である。

0010

請求項4に係る発明は、前記プログラムの状態とは、当該プログラムのライフサイクル状態であり、前記通知制御手段は、前記宛先のプログラムのライフサイクル状態が、メモリ上にロード済みである状態であれば前記通知を当該プログラムに渡し、前記ライフサイクル状態が前記メモリ上にロードされていない状態であれば前記通知を当該プログラムに渡さない、請求項3に記載の仲介装置である。

0011

請求項5に係る発明は、前記通知制御手段は、前記宛先のプログラムの前記ライフサイクル状態が、前記メモリ上にロード中の状態であれば、ロードが完了したときに前記通知を当該プログラムに渡す、請求項4に記載の仲介装置である。

0012

請求項6に係る発明は、各プログラムからそれぞれ当該プログラムがどの状態のときに通知を受け取るかを示す通知設定を記憶する設定記憶手段、を更に含み、前記通知制御手段は、前記宛先のプログラムの状態が当該プログラムの前記通知設定の示す状態に該当すれば前記通知を当該プログラムに渡し、そうでなければ前記通知を当該プログラムに渡さない、請求項1に記載の仲介装置である。

0013

請求項7に係る発明は、前記通知設定は、前記プログラムと前記通知の対象である情報項目との組合せ毎に、当該プログラムがどの状態の時に当該情報項目についての前記通知を受け取るかを示すものであり、前記通知制御手段は、前記宛先のプログラムが、当該宛先のプログラムと、前記受信手段が受信した前記通知の対象である前記情報項目と、の組合せに対応する前記通知設定が示す状態に該当すれば前記通知を当該プログラムに渡し、そうでなければ前記通知を当該プログラムに渡さない、請求項6に記載の仲介装置である。

0014

請求項8に係る発明は、前記各プログラムを管理する常駐プログラムから、前記各プログラムについての前記通知設定の登録を受け付けて前記設定記憶手段に記憶させる手段、を更に含む請求項7に記載の仲介装置である。

0015

請求項9に係る発明は、前記常駐プログラムから登録された前記各プログラムの各通知設定に含まれる前記通知の対象の前記情報項目のリストを、通知して欲しい情報項目を示すリストとして前記通知元に登録する手段、を更に含む請求項8に記載の仲介装置である。

0016

請求項10に係る発明は、各プログラムからそれぞれ当該プログラムがどの状態のときに通知を受け取らないかを示す通知設定を記憶する手段、を更に有し、前記通知制御手段は、前記宛先のプログラムの状態が当該プログラムの前記通知設定の示す状態に該当すれば前記通知を当該プログラムに渡さず、そうでなければ前記通知を当該プログラムに渡す、請求項1に記載の仲介装置である。

0017

請求項11に係る発明は、コンピュータを、通知元から通知を受信する受信手段、受信した前記通知の宛先のプログラムの状態に応じて、その通知を前記プログラムに渡すか否かを制御する通知制御手段、として機能させるためのプログラムである。

発明の効果

0018

請求項1、11に係る発明によれば、通知元が発した通知をその通知の宛先のプログラムに常に通知する方式と比べて、通知やそのための処理が無駄になりにくくすることができる。

0019

請求項2に係る発明によれば、表示に直ちに反映されない通知を宛先のプログラムに渡すことにより生じる可能性のある無駄を低減することができる。

0020

請求項3に係る発明によれば、表示要素を表示中でなくても通知を渡すことが必要な状態のプログラムに対して、通知を渡すことができる。

0021

請求項4に係る発明によれば、ロード済みでないプログラムに対して通知を渡すことによる無駄を低減することができる。

0022

請求項5に係る発明によれば、ロード中の宛先のプログラムに対して通知を渡すことを試行する方式と比べて、無駄な試行を低減することができる。

0023

請求項6又は10に係る発明によれば、プログラム毎に、そのプログラムの特徴に応じて通知を渡すか否かを制御することができる。

0024

請求項7に係る発明によれば、通知の対象である情報項目毎に、宛先のプログラムに通知を渡してよい状態を規定することができる。

0025

請求項8に係る発明によれば、新たなプログラムが導入された場合等に、仲介装置に対して人手で通知設定を登録する手間をなくすことができる。

0026

請求項9に係る発明によれば、通知元に対して通知が必要な情報項目を知らせることができる。

図面の簡単な説明

0027

実施形態のシステム構成の例を示す図である。
ウェブブラウザが実行するプログラムの例を説明する図である。
ホーム画面の例を示す図である。
コピー画面の例を示す図である。
デバイス画面の例を示す図である。
一般設定画面の例を示す図である。
一般設定画面から呼び出される他の設定画面の例を示す図である。
エラー画面の例を示す図である。
コピー画面にバナーが表示された状態を例示する図である。
通知登録テーブルの例を示す図である。
外部モジュールが保持している個々の情報項目のデータ内容と、そのデータ内容が変化する理由とを示す図である。
表示態様管理モジュールが保持する表示態様の管理情報のある時点の状態を示す図である。
表示態様管理モジュールが保持する表示態様の管理情報のある時点の状態を示す図である。
表示態様管理モジュールが保持する表示態様の管理情報のある時点の状態を示す図である。
表示態様管理モジュールが保持する表示態様の管理情報のある時点の状態を示す図である。
表示態様管理モジュールが保持する表示態様の管理情報のある時点の状態を示す図である。
表示態様管理モジュールが保持する表示態様の管理情報のある時点の状態を示す図である。
表示態様管理モジュールが保持する表示態様の管理情報のある時点の状態を示す図である。
表示態様管理モジュールが保持する表示態様の管理情報のある時点の状態を示す図である。
表示態様管理モジュールが保持する表示態様の管理情報のある時点の状態を示す図である。
表示態様管理モジュールが保持する表示態様の管理情報のある時点の状態を示す図である。
表示態様管理モジュールが保持する表示態様の管理情報のある時点の状態を示す図である。
表示態様管理モジュールが保持する表示態様の管理情報のある時点の状態を示す図である。
表示態様管理モジュールが保持する表示態様の管理情報のある時点の状態を示す図である。
表示態様管理モジュールが保持する表示態様の管理情報のある時点の状態を示す図である。
表示態様管理モジュールが保持する表示態様の管理情報のある時点の状態を示す図である。
表示態様管理モジュールが保持する表示態様の管理情報のある時点の状態を示す図である。
表示態様管理モジュールが保持する表示態様の管理情報のある時点の状態を示す図である。
外部モジュールから通知を受信したときの通知仲介部の処理の手順を例示する図である。
外部モジュールから通知を受信したときの通知仲介部の処理の手順の別の例を示す図である。
外部モジュールから通知を受信したときの通知仲介部の処理の手順の更に別の例を示す図である。

実施例

0028

図1に、本実施形態のシステムの例を示す。例示するシステムは、画像形成装置に搭載されるソフトウエアシステムであり、ウェブブラウザ100と外部モジュール200とを含む。

0029

ウェブブラウザ100は、画像形成装置のUI(ユーザインタフェース)処理を担うソフトウエア要素である。このウェブブラウザ100は、外部モジュール200内のウェブサーバ等のサーバから供給されるウェブページの表示やウェブアプリケーションの実行を行う。ウェブブラウザ100は、プログラム110、プログラム管理部120、及び通知仲介部130を含む。

0030

プログラム110は、ウェブブラウザ100上で実行可能なプログラムである。プログラム110は、例えばウェブアプリケーションの形で外部モジュール200内のウェブサーバ(図示省略)から提供され、ウェブブラウザ100上で実行される。プログラム110は、ウェブブラウザ100上で実行されることにより、画像形成装置のUIを構成する要素処理(例えばある目的のための画面の表示と、その画面上の各部へのタッチ操作を受け付ける処理)を実現する。後述するホーム画面(「Home」)やコピー画面(「Copy」)のように、UIを構成する要素毎にプログラム110が存在する。

0031

図示例では、プログラム110は、1つの常駐プログラム112と、1以上の表示プログラム114とを含む。常駐プログラム112は、対応する1以上の表示プログラム114を管理する。表示プログラム114は、UIを構成する画面、ウインドウダイアログ等の表示要素を画面表示したり、その表示要素に対するユーザの入力を受け付けたりするための処理を実行する。

0032

常駐プログラム112は、ユーザからの指示や外部モジュール200の状態に応じて、必要な表示プログラム114を起動したり、その表示プログラム114が生成する画面等の表示要素を表示したりする指示を、プログラム管理部120に対して行う。プログラム管理部120を介して、指示された表示プログラム114が起動されたり、起動済みのその表示プログラム114が生成した画面等の表示要素が、画像形成装置が備える表示装置に表示されたりする。表示プログラム114によって表示される画面は、GUIグラフィカルユーザインタフェース)を構成しており、ユーザの指示を受け、その指示に応じて外部モジュールを操作し、コピースキャン等のジョブを実行する。また、表示プログラム114は、外部モジュール200から通知される情報を、表示要素内に表示する。これにより、例えば、トナー消費エラー状況が画面表示される。また表示プログラム114は、自らが表示している表示要素に対してその表示要素を閉じる旨のユーザの指示を受けると、プログラム管理部120に対して自らの非表示及び削除を指示する。これに応じて、プログラム管理部120は、その表示プログラムを非表示とする処理、更に削除(メモリからアンロード)を行う。また、常駐プログラム112が外部モジュール200の状態の通知を受けて、対応する表示プログラム114の非表示、削除を実施することもある。

0033

プログラム管理部120は、ウェブブラウザ100上で実行される各プログラム110(特にその中の表示プログラム114)の状態を管理する。管理されるプログラムの状態には、ライフサイクル状態と表示態様とがある。

0034

ライフサイクル状態とは、その表示プログラム114が、プログラムのライフサイクルにおけるどのステージにあるかを示す状態である。最も簡単な例では、ライフサイクルの状態は、その表示プログラム114がウェブブラウザ100上で実行中(言い換えればメモリ上にロード済み)である第1状態(ロード済み状態とも呼ぶ)と、そうでない第2状態(非ロード済み状態とも呼ぶ)の2つに大別される。非ロード済み状態は、ロード中でまだロードが完了していない状態(ロード中状態)、メモリ上からの削除中の状態(削除中状態)、及びまったくロードされていない状態(未ロード状態)、の3つに分けることもできる。各表示プログラム114のライフサイクル状態は、ライフサイクル管理モジュール122により管理されている。

0035

表示態様とは、実行中状態にある表示プログラム114が生成する画面等の表示要素が画像形成装置付属の表示装置に表示されているか否かに関する状態である。簡単な例では、表示態様は、実際に表示装置に表示されている「表示」状態と、表示されていない「非表示」の2段階の状態である。また、階層的な複数の表示要素を切り替えて表示する場合を想定して「表示」状態を、「前面表示」と「背面表示」に細分化してもよい。前面表示状態の表示要素は表示装置に表示されている(従ってユーザの目に見える)のに対し、背面表示状態の表示要素は、メモリ上に画像データとしては存在するが、表示装置の画面上では、その前面表示状態の表示要素の下に隠れて見えない(表示されない)。なお、「非表示」状態の表示要素は、画像データがメモリ上に存在していてもよいし、存在していなくてもよい。存在していない場合は、その表示要素を再度表示する場合、画像データを再度生成する必要がある。各表示プログラムの表示態様は、表示態様管理モジュール124に管理されている。

0036

プログラム管理部120は、ライフサイクル管理モジュール122及び表示態様管理モジュール124に管理されている各表示プログラムのライフサイクルや表示態様の情報を、他のプログラムに提供する機能を持つ。

0037

通知仲介部130は、外部モジュール200からの通知を各プログラム110に仲介する処理を担う。どの通知をどのプログラム110に、どの場合に通知するかは、イベント管理部132に設定されている(詳細は後述)。通知仲介部130は、外部モジュール200から通知を受け取った場合、その通知の送り先のプログラムと、そのプログラムが通知を送るべき状態にあるか否かとを、イベント管理部132を参照して判定する。そして、その判定に従って、通知を送るべき状態のプログラムにその通知の情報を送る。

0038

外部モジュール200は、UIであるウェブブラウザ100からみて外部にあるモジュールであることを意味し、ここでは画像形成装置本体の制御を行うソフトウエアモジュールのことである。例えば、外部モジュール200は、画像形成装置が内蔵する印刷機構用紙送り機構スキャン機構ファックス装置等をユーザの指示に応じて制御する。また、外部モジュール200は、ユーザから指示されたコピー、スキャン等の処理(ジョブ)の処理順序や実行を管理する。また、外部モジュール200は、画像形成装置の各部に設けられたセンサの信号から、それら各部の状態を検知し、その状態の情報を保持・管理する。外部モジュール200は、自分が管理している各ジョブの状態、各種センサの信号が示す各種状態(例えば用紙やトナー等の状態)、画像形成装置のコンフィギュレーションオプション(例えば後処理装置)の有無などの情報項目を情報保持部202に保持し、管理している。

0039

また外部モジュール200が備える情報通知管理部204は、情報保持部202が保持する情報項目のうちのどれをウェブブラウザ100側に通知するのかを管理している。例えば情報通知管理部204には、ウェブブラウザ100(通知仲介部130)から通知の対象として登録された情報項目のリストが保持される。

0040

また外部モジュール200は、WebSocketサーバ206及びSOAPサーバ208を有する。WebSocketサーバ206は、WebSocket規格準拠した通信により情報をウェブブラウザ100に提供する。SOAPサーバ208は、SOAPプロトコルを用いて情報をウェブブラウザ100に提供する。

0041

次に、プログラム110の具体例を説明する。画像形成装置のUIを構成するプログラム110には、図2に例示するようにHome、Copy、Contacts、Device、Fault等の識別名(図中の「プログラム名」)で識別されるプログラムがある。

0042

Homeプログラムは、画像形成装置のUIのホーム画面(すなわち最上位操作メニューを表示する画面)を構成するためのプログラムである。Homeプログラムは、表示プログラム114として「home」という識別名(「表示プログラム名」)のプログラムを起動する。このhome表示プログラムにより表示されるホーム画面300の例を図3に示す。このホーム画面300には、画像形成装置が提供するコピー、スキャン、ファックス送信等の各機能を使用するための画面を呼び出すためのGUIボタン302が並べて表示される。また、ホーム画面300には、現在この画像形成装置にログインしているユーザ(すなわちこの画面を見て操作しているユーザ)のユーザIDを表示するユーザ表示欄304、設定を初期状態リセットするためのリセットボタン306などが表示される。なお、このホーム画面300をはじめとして、プログラム110群が生成する各種の画面は、タッチパネル型の表示装置に表示されることを想定したものである。

0043

Copyプログラムは、「copy」及び「idcopy」という2つの表示プログラム114を有する。

0044

copy表示プログラムは、図4に例示する通常のコピー指示入力用のコピー画面400を生成し、その画面からの入力を受け付けるプログラムである。例示のコピー画面400には、コピー部数の入力を受け付けて表示する部数入力欄402、部数入力欄402に数値を入力するためのテンキー404、及び複数の詳細設定欄406が表示される。図では、詳細設定欄406として出力カラー(OutPut Coler)の欄のみが示されるが、その下の画面表示範囲の外に更にいくつかの設定項目についての詳細設定欄406が画面外に存在しており、画面をスクロールすることで隠れているそれら詳細設定欄406が表示される。詳細設定欄406には、当該設定項目についての現在の値(図示例では出力カラーが「自動検出」(Auto Detect))が表示されており、ユーザがその詳細設定欄406にタッチすることで、当該設定項目の値を変更するための別画面が表示される。

0045

また、idcopy表示プログラムは、免許証パスポート等の身分証明書IDカードの複数の面の画像を1枚の用紙に印刷するIDカードコピー機能の操作画面(図示省略)を生成し、操作を受け付けるためのプログラムである。

0046

通常のコピー(copy表示プログラム)とIDカードコピー(idcopy表示プログラム)とは、利用する設定項目や処理時に参照する情報項目等の多くが共通しているので、それらを共通のCopyプログラムの常駐プログラム112で管理している。

0047

またDeviceプログラムは、画像形成装置全体についての設定画面(図5のデバイス画面500等)を表示し、それら設定画面に対するユーザの入力を受け付ける。画像形成装置全体についての設定画面群は、階層構造をなしている。図5に例示したデバイス画面500は、その階層構造における最上位の画面であり、ホーム画面300内の「デバイス」ボタンが押下されると表示される。このデバイス画面500は、図2に示したdevice表示プログラムにより生成される。デバイス画面500には、装置設定項目カテゴリ502のリストが表示され、このリスト内のカテゴリ502がタッチ操作で選択されると、そのカテゴリ502の画面が表示される。例えば、デバイス画面500上の「General(一般)」カテゴリ502がタッチされると、図6に例示する一般設定画面510が表示される。この一般設定画面510は、図2に示したgeneral表示プログラムにより生成される。一般設定画面510には、一般設定項目512のリストが表示される。図には「Measurement(寸法の単位)」や「Date & Time(日付と時刻)」といった一般設定項目512が例示されている。一般設定画面510のリストからタッチ操作により一般設定項目512が選択されると、その設定項目についての設定画面520(図7参照)が表示される。図7は、「Measurement(寸法の単位)」が選択された場合に表示される設定画面520を例示している。図7の設定画面520には、寸法の単位に関する2つの詳細設定項目522が示されている。1つ目の詳細設定項目522は、
UIに表示される寸法の「Unit(単位)」としてインチ(inch)が選択されていることを示し、2つ目は用紙のサイズ(Paper Size)もインチ単位であることを示している。詳細設定項目522の欄にタッチすると、その項目の単位を変更するための変更画面(図示省略)が表示される。この設定画面520は、図2に示したmeasurement表示プログラムにより生成される。

0048

ホーム画面300上で「デバイス」ボタンが押下されると、まずdevice表示プログラムが起動され、デバイス画面500が表示される。ユーザがデバイス画面500上で「General」画面の表示を指示すると、device表示プログラムがデバイスの常駐プログラム112にgeneral表示プログラムの起動を依頼する。常駐プログラム112はdevice表示プログラムの子画面としてgeneral表示プログラムを起動するよう、プログラム管理部120に起動を依頼する。起動が完了すると常駐プログラム112はgeneral表示プログラムの生成した一般設定画面510を表示するようプログラム管理部120に依頼する。一般設定画面510に対してユーザがMesurement画面表示を指示すると、同様の流れでプログラム管理部120を介してmeasurement表示プログラムが起動され、設定画面520が表示されることとなる。このとき、プログラム管理部120は、Device−General−Mesurementという画面間階層関係を管理していると共に、それら階層関係のある画面群のうち、現在どの画面が前面に表示されており、どの画面がその裏に隠れているのかを把握している。

0049

Faultプログラムは複数のエラーをユーザに知らせるためのいくつかの表示プログラムをもつ。図8に、画像形成装置の前面カバー(Front Door)が開かれた場合に表示されるエラー画面600を例示する。このエラー画面600は、図2の表に挙げたfaultcommon表示プログラムによって表示される。Faultプログラムの常駐プログラム112は、画像形成装置にエラーが発生したことを検知できるよう、外部モジュール200から装置のエラーに関する情報項目について通知を受け取る旨の登録を予め通知仲介部130に行う。登録された情報はイベント管理部132に保持される。また、通知仲介部130は、外部モジュール200の情報通知管理部204に対して、装置のエラーに関する情報項目について通知を受け取る旨の登録を行う。前面カバーが開かれたことを外部モジュール200が検知すると、情報保持部202が保持する装置エラーに関する情報項目のデータ内容が、前面カバーが開いていることを示す値へと更新される。WebSocketサーバ206は、この更新を受けて、装置のエラーに関する情報項目について通知を受け取る旨の登録があるかどうか情報通知管理部204に問い合わせ、そのような登録があれば、WebSocketプロトコルを用いてウェブブラウザ100に対してその情報項目のデータ内容の更新を知らせる通知を送信する。ウェブブラウザ100の通知仲介部130は、その情報項目が通知対象とする旨の登録がFaultプログラムからなされているので、Faultプログラムに対してその通知を送信する。この通知には、前面カバーが開いていることを示すデータ内容が含まれる。Faultプログラムの常駐プログラム112は、受け取った通知の内容から、faultcommon表示プログラムを選択して起動し、その情報内容に対応した画面内容を表示する。すなわちこの場合、faultcommon表示プログラムは、前面カバーが開いているという状態とそれに対する対処法を示すエラー画面600を生成し表示する。

0050

Bannerプログラムは、バナーを生成し、表示するためのプログラムであり、banner表示プログラムやjobbanner表示プログラムを含む。バナーは、画面(すなわち画像形成装置付属の表示装置の全表示領域)の一部に表示される表示領域である。Bannerプログラムは、他の表示プログラムからユーザにメッセージを表示したい場合に起動され、そのメッセージを示したバナーを表示する。バナーは、その下のレイヤー(層)にある画面を部分的に隠す。図9には、コピー画面400の下端部にバナー700が表示されている状態を示す。このバナー700は、部数入力欄402に入力された部数の値が、許容範囲を逸脱していることを示すメッセージを表示する。コピー画面400の下側の一部分は、このバナー700により隠されるが、上側の大部分は表示されたままである。バナー700は、予め設定された時間が経過すると消去される。また、図示は省略したが、バナー700内に、そのバナー700を消去するためのボタンを設けてもよい。

0051

なお、図2のレイヤーの欄は、プログラム110内の表示プログラム114が生成した画面(コピー画面400やデバイス画面500等)が属する仮想的なレイヤー(層)を示す。複数の画面の表示が競合した場合、各画面を生成したプログラム110のレイヤーの優先順に従って、それら複数の画面のうちのどれを前面に表示するかを決める。

0052

次に、画像形成装置の電源投入時における、このシステムの動作を説明する。

0053

画像形成装置に電源投入されると、まずこの装置の主制御部である外部モジュール200が起動される。起動された外部モジュール200は、UIを担当するウェブブラウザ100を起動する。起動されたウェブブラウザ100は、設定に従って画像形成装置内のウェブサーバ(図示省略)から、各プログラム110の常駐プログラム112群、並びに、プログラム管理部120及び通知仲介部130のプログラムをダウンロードして起動する。起動された各常駐プログラム112は、外部モジュール200から通知して欲しい情報項目を通知仲介部130に対して登録する。より詳しくは、この登録では、常駐プログラム112が管理する表示プログラム114(すなわち常駐プログラム112と同じプログラム110に属する表示プログラム114)のうち、外部モジュール200からの通知を必要とする表示プログラム114ごとに、その表示プログラム114に対して通知して欲しい情報項目(後述する図10では「情報ID」)と、その表示プログラム114がどの状態(例えば後述する「表示態様」)のときにその情報項目についての通知を受け取るのか(あるいはどの状態のときに受け取らないのか)を示す情報(図10では「通知方法」)と、を含む登録項目を、通知仲介部130に登録する。この登録の内容はイベント管理部132内の通知登録テーブル(図示省略)に保持される。また起動された通知仲介部130は、WebSocket等のプロトコルで通信できるよう外部モジュール200と接続を行い、各常駐プログラム112から登録された通知対象の情報項目を、外部モジュール200に登録する。外部モジュール200は、通知仲介部130から登録された通知対象の情報項目のリストを保持している。

0054

図10に、イベント管理部132に保持される通知登録テーブルのデータ内容を例示する。このテーブルには、個々の登録毎に1つの行(エントリ)が含まれる。1つの行には、「プログラム名」、「表示プログラム名」、「情報ID」、「通知方法」、「キャッシュ要否」等の項目が登録される。

0055

「プログラム名」は、情報項目についての通知を依頼した依頼元のプログラム110の識別名である。

0056

「表示プログラム名」は、そのプログラム110内で当該情報項目の通知を受ける表示プログラム114の識別名である。「情報ID」は、通知の対象である情報項目の識別情報である。なお、図10の例において、表示プログラム名「baseframe」は、同じ行内のプログラム名が示すプログラム110の常駐プログラム112を示す。常駐プログラム112が通知を受け取り、その通知に対応する表示プログラム114を起動するなどの場合があるため、常駐プログラム112も通知の宛先となり得る。

0057

「通知方法」は、その表示プログラム114がどのような状態(例えば表示態様)にあるときに、外部モジュール200から受け取ったその情報項目についての通知をその表示プログラム114に渡すかを示す。例えば、通知方法が「前面表示時」である場合、通知仲介部130は、同じ行内の表示プログラム114の表示態様が「前面表示」であるときに限り、同じ行内の情報IDが示す情報項目についての通知をその表示プログラム114に渡す。また、通知方法が「表示時」の場合、通知仲介部130は、同じ行内の表示プログラム114の表示態様が何らかの「表示」状態に対応する場合、すなわち「前面表示」や「背面表示」などのように、表示プログラム114が生成した画面のデータがメモリ上に存在する場合(ただし実際に表示されていない場合もある)に、対応する情報項目に関する通知を、対応する表示プログラム114に送る。また、通知方法が「常時」である場合、プログラム管理部120は、同じ行内の表示プログラム114の表示態様によらず、同じ行内の情報IDが示す情報項目についての通知をその表示プログラム114に渡す。すなわち、「常時」の場合は、表示プログラム114の表示態様が「非表示」(すなわち表示装置に表示されない)であっても、その表示プログラム114に通知が送られる。

0058

通知登録テーブルの右端の項目「キャッシュ要否」は、同じ行の情報IDに対応する情報項目についての通知の内容のキャッシュが必要か否かを示す。「キャッシュ要否」の値が「要」の場合、通知仲介部130(イベント管理部132)は、対応する情報項目についての通知のデータ内容をキャッシュする。すなわち、イベント管理部132は、「キャッシュ要否」が「要」である個々の情報IDに対応付けて、その情報IDに対応する情報項目についての最新の通知のデータ内容を保持(キャッシュ)する。その情報項目について新たな通知が到来した場合、その情報項目のキャッシュ内容はその新たな通知のデータ内容へと更新される。キャッシュした情報項目のデータ内容は、起動された表示プログラム114から参照される場合がある。

0059

図10に例示した各エントリの情報は、それぞれ当該エントリのプログラム名に対応するプログラム110の常駐プログラム112が、画像形成装置の起動時に、通知仲介部130に登録する。

0060

なお、通知仲介部130は、画像形成装置の起動時に各プログラム110からの登録により通知登録テーブルを生成した場合、その通知登録テーブル内に登録された情報IDのリストを、通知対象を示す情報として外部モジュール200に登録する。図10に例示したように、通知登録テーブル内には、同じ情報IDが複数の表示プログラムのエントリに通知対象として登録されているが、外部モジュール200には、このような重複がない、各通知対象の情報IDを1つずつ示したリストが登録される。

0061

図11に、外部モジュール200が情報保持部202内に保持している個々の情報項目の情報IDに対応付けて、その情報項目のデータ内容(「内容」)と、そのデータ内容が変化する理由(「変化理由」)を示す。

0062

例えば、情報項目「PaperTray」(すなわち情報IDの値が「PaperTray」である情報項目のこと)は、データ内容として、画像形成装置が備える各用紙トレイ(図示例では、2つの用紙トレイTray1とTray2)について、当該用紙トレイ内の用紙のサイズと、その用紙トレイの状態とを持つ。用紙トレイの状態は、その用紙トレイが画像形成装置本体に挿入された状態か抜かれた状態かのいずれかである。また、この情報項目内のある用紙トレイの用紙サイズの値は、その用紙トレイ内に収容される用紙のサイズが変更されるのに応じて変化する。また、この情報項目内の、ある用紙トレイの状態の値は、その用紙トレイが抜かれたとき、その用紙トレイが挿されたとき、及びその用紙トレイが故障したときに、それぞれ変化する。例えば用紙トレイが抜かれたときには、その状態の値は「挿入済み」から「抜き出された」に変化し、故障した場合には「挿入済み」から「故障中」に変化する。

0063

また情報項目「DeviceFault」には、データ内容として、画像形成装置の前面カバーのエラー情報、オプションのエラー情報が含まれる。例えばオプジョンのエラー情報は、画像形成装置にオプションとして付属する両面装置や後処理装置(Finisher)が故障した場合に、「正常」を示す値から「故障」を示す値に変化する。

0064

次に、プログラム管理部120の機能について説明する。プログラム管理部120は、それぞれのプログラム110から表示プログラム114の起動や表示の要求があったとき、前面表示とする表示プログラムを決める。すなわち、複数の画面の表示要求が競合する場合には、所定のレイヤー優先順にしたがって前面に表示する画面を決める。例えば、図2に示された3つのレイヤーApplication、Fault、Bannerの中では、Faultが最も優先順位が高く、次位がBannerであり、最下位がApplicationである。表示対象として競合している画面同士のレイヤーが異なる場合は、そのうち優先順位が最も高いレイヤーの画面を前面表示とし、他の画面は非表示とする。また競合している画面のレイヤーがすべて同じ場合には、表示要求を受け付けた時間が最新の画面が前面表示される。すなわち、新たに来た表示要求に係る画面のレイヤーが、現在前面表示されている画面のレイヤーと同順位の場合、現在表示されている画面は非表示となり、その新たな表示要求に係る画面が前面表示される。例えばCopyプログラムとScanプログラムは共にApplicationレイヤーであり、それら両方から画面の表示要求を受けた場合、プログラム管理部120は、時間的に後に要求された方の画面を前面表示の対象と決定する。また、Copyプログラムの画面(例えばコピー画面400)が表示されているときに、より高順位のFaultレイヤーに該当するFaultプログラムの画面の表示要求があれば、Faultプログラムの画面が表示される。

0065

ここで、ウェブブラウザ100が使用可能なメモリ容量に限りがあるため、起動を要求されたすべての表示プログラム114を生成(起動)済み状態(すなわちメモリ上にロードされている状態)としておく余裕はない。そこで、プログラム管理部120は、メモリ上にロードする表示プログラム114の数に上限を設け、原則その上限を超える数の表示プログラム114がメモリ上に同時にロードされている状態とならないように制御する。すなわち、プログラム管理部120は、いずれかの常駐プログラム112から新たな表示プログラム114の生成(起動、ロード)が要求された場合、その時点でメモリ上にある表示プログラム114の数が上限に達していれば、原則、その中の1つの表示プログラム114(例えば現在表示中の表示プログラム114以外でもっとも生成時刻が古いもの)を削除し、その代わりに新たに要求された表示プログラム114をロードする。削除された表示プログラム114と同じプログラム110に属する常駐プログラム112は、プログラム管理部120から、その表示プログラム114が削除された旨を通知される。削除されたその表示プログラム114の画面を再度表示する場合には、その常駐プログラム112は、再度プログラム管理部120に対してその表示プログラム114の生成及び表示を要求する。

0066

ここで説明した表示プログラム114の同時ロード数の上限制御の例外の一つは、home表示プログラムにより表示されるホーム画面300である。ホーム画面300は、表示装置上にどの画面が表示されている場合でも、画像形成装置に設けられている機械式ホームキーや、表示中の画面内のGUIのホームキーが押下されると表示する必要があり、即応性が求められる。このため、home表示プログラムは常にメモリ上にロードされた状態とする。メモリ上の表示プログラム114の数が上限を超える場合でも、home表示プログラムは削除の対象にはならない。

0067

また表示プログラム114の同時ロード数の上限制御の例外の別の例として、上に例示したDeviceプログラム内のdevice、general、measurement表示プログラム114のように階層(親子)関係がある表示プログラム114がある。メモリ上にロードされている表示プログラム114に対して階層関係上で先祖に該当する表示プログラム114は、上述の上限制御において削除の対象には選ばれない。

0068

次に、図12A図12Qを参照して、プログラム管理部120の表示態様管理モジュール124が保持する表示態様の管理情報の変遷の具体例を説明する。以下の例は、ウェブブラウザ100が同時に実行可能な表示プログラム114の上限数が2である場合の例である。

0069

まず画像形成装置に電源が投入されてウェブブラウザ100が起動されると、ウェブブラウザ100が、最初に起動するものとして設定されているhome表示プログラム114を起動する。これにより画像形成装置付属の表示装置にホーム画面300が表示される。図12Aには、この時点での表示態様管理モジュール124内の管理情報の内容が示される。管理情報には、メモリ上にロードされている(すなわち起動済みで未削除)の表示プログラム114毎に1つの行(エントリ)が含まれる。個々のエントリには、PID、プログラム名、表示プログラム名、親表示プログラム名、表示態様及びレイヤー等の項目が含まれる。PIDは、その表示プログラム114に付与されたID(識別情報)である。プログラム名は、その表示プログラム114が属するプログラム110の識別名である。表示プログラム名はその表示プログラム114自身の識別名であり、親表示プログラム名は、階層(親子)関係をなす表示プログラム114群(例えば上述したDeviceプログラムに属するdevice、general、measurement)において、当該表示プログラム114の親に該当する表示プログラム114の識別名である。レイヤーは、その表示プログラム114が属するレイヤー(図2参照)である。図12Aに示すように、ウェブブラウザ100が起動された時点の管理情報には、home表示プログラムが「前面表示」状態であることを示すエントリのみが含まれる。

0070

次に、ホーム画面300上でコピーボタンが押下されると、copy表示プログラムが起動され、これによりコピー画面400が表示される。このとき、図12Bに示すように、copy表示プログラムは「前面表示」となる。また、それまで「前面表示」状態であったhome表示プログラムは、同じレイヤーのcopy表示プログラムは「前面表示」となったことにより、いわば押し出され、「非表示」に変化する。

0071

次に、コピー画面400が表示されている状態でホームボタンが押下されると、ホーム画面300が表示されてhome表示プログラムの表示態様が「前面表示」に変化し、copy表示プログラムの表示態様が「非表示」に変化する(図12C参照)。

0072

次に、ホーム画面300上のFAXボタンが押下されると、FAX画面が表示され、fax表示プログラムが「前面表示」となる。その代わりにhome表示プログラムは「非表示」となる(図12D参照)。

0073

次に、ホームボタンが押下されると、ホーム画面300が表示され、図12Eに示すように、home表示プログラムが「前面表示」となり、代わってfax表示プログラムが「非表示」になる。

0074

次に、ホーム画面300上のコピーボタンが押下されると、コピー画面400が表示され、copy表示プログラムの表示態様が「前面表示」となる。一方、home表示プログラムが「非表示」となる(図12F参照)。

0075

次に、CopyプログラムからBannerプログラムにメッセージ表示が要求されると、banner表示プログラムが起動される。そして、banner表示プログラムがバナーを生成して表示し、そのバナー内にメッセージを表示する。例えばユーザが入力したコピー部数が上限値を超えた場合には、Copyプログラムからの要求に応じて図9に例示するバナー700が表示される。この結果、図12Gに示すように、プログラム管理部120の管理情報では、banner表示プログラムが「前面表示」となる。また、図9に例示したようにバナー700は表示装置の全表示領域のうちの下端近傍の一部にしか表示されないため、コピー画面400の残りの大部分は表示されたままとなる。このため、管理情報内のcopy表示プログラムの表示態様は「前面表示」のままとなる。そして、メモリ上に同時にロード可能な表示プログラムの数を上限数2以下に制限する制御により、fax表示プログラムがメモリ上から削除される。すなわち、home表示プログラムは上限数の制御の枠外として常にメモリ上に残るので、これ以外のbanner、copy、faxの各表示プログラムの中から上限数である2個がメモリ上に残ることになる。この場合、今回新たに生成され前面表示となったbannnerと、ひきつづき前面表示状態であるcopyとの2つがメモリ上に残り、faxは削除されることになる。このため、図12Gに示す管理情報からは、fax表示プログラムのエントリはなくなっている。

0076

次に、バナー表示後、所定の時間が経過すると、そのバナーが非表示となり、コピー画面400が表示領域全域に表示された状態となる。バナーは、コピー画面400等のようにユーザから入力を受け付ける画面と異なり、再度表示が必要になる可能性は極めて低いので、banner表示プログラムをメモリ上に残しておくメリットはない。このためbanner表示プログラムはメモリから削除される。このときの表示態様管理モジュール124内の管理情報は図12Hに示す状態となる。

0077

次に、ホームボタンが押下されると、ホーム画面300が前面表示となり、コピー画面400は非表示となる(図12I参照)。

0078

次に、ホーム画面300のデバイスボタン(図3参照)が押下されると、デバイス画面500(図5参照)が前面表示となり、ホーム画面300及びコピー画面は非表示となる。この結果、図12Jに示すように、管理情報では、デバイス画面500を生成するdevice表示プログラムの表示態様が前面表示となり、home及びcopyの各表示プログラムの表示態様は非表示となる。

0079

次に、ユーザがデバイス画面500上の「General」(一般設定)にタッチすると、general表示プログラムが起動され、この表示プログラムが生成する一般設定画面510(図6参照)が表示される。この結果、図12Kに示すように、general表示プログラムの表示態様が前面表示となる。また、general表示プログラムは、前述の通り階層関係においてdevice表示プログラムの子に該当するので、図12Kの管理情報では、general表示プログラムのエントリの親表示プログラム名の欄にdevice表示プログラムの識別名が登録される。一方、それまで表示されていたデバイス画面500は、一般設定画面510に隠されて非表示となり、図12Kの管理情報におけるdevice表示プログラムの表示態様の値は背面表示となる。背面表示という表示態様は、非表示よりも再表示されやすい状態である。なお、互いに階層関係にある一群の表示プログラムは、同時ロード可能な表示プログラム数の上限制御において1つとカウントされるので(またhomeは上限制御における表示プログラム数にはカウントされないので)、copy表示プログラムはメモリ上に残り、管理情報にも非表示として残る。

0080

次にホームボタンが押下されると、図12Lに示すように、home表示プログラムの表示態様が前面表示となり、device及びgeneralの各表示プログラムの表示態様は非表示となる。

0081

次に、ホーム画面300上のアドレス帳ボタンが押下されると、Contactsプログラム中のaddressbook表示プログラム(図2参照)が生成するアドレス帳画面が前面表示となる。一方、home表示プログラムの表示態様は非表示となる。また、addressbook表示プログラムが新たにロードされることで、同時ロード数の上限制御により、共に非表示であるcopy表示プログラムと、device及びgeneral表示プログラム(これら2つで1つとカウント)とのうち、より古いcopy表示プログラムがメモリから削除される。その結果、表示態様管理モジュール124内の管理情報は、図12Mに示す状態となる。

0082

次に、ユーザが画像形成装置の前面カバーを開いたとする。この場合、外部モジュール200からウェブブラウザ100に対して、情報IDが「DeviceFault」(図10参照)で、データ内容として前面カバーが開いたことを示す値を含んだ通知が送られる。これを受け取った通知仲介部130は、情報ID「DeviceFault」の通知を「常時」待ち受けているFaultプログラムの常駐プログラム112(プログラム名「baseframe」)に対して、その通知を渡す。その常駐プログラム112は、その通知に応じてfaultcommon表示プログラムを起動する。faultcommon表示プログラムは、その通知に応じて、前面カバーが開いていることを示すエラー画面600(図8参照)を表示する。この結果、図12Nに示すように、faultcommon表示プログラムの表示態様が前面表示となる。また、それまで表示されていたアドレス帳画面を管理しているaddressbook表示プログラムは、新たに表示されたFaultプログラムの画面よりも優先度が低いレイヤーに属するので、表示態様は背面表示となる。それまで前面表示されていたアドレス帳画面は、エラー画面600に係るエラーが解消されると再び表示することになるので、addressbook表示プログラムは非表示ではなく、背面表示となる。また、今回のfaultcommon表示プログラムの起動により、同時ロード数の上限制御が行われ、非表示で最も古いdevice及びgeneralの表示プログラム(これらは一体に扱われる)がメモリから削除され、表示態様管理モジュール124の管理情報からもそれら表示プログラムのエントリは削除される。

0083

次に前面カバーが閉められると、前面カバーが開いているというエラー状態は解消し、外部モジュール200はその旨を知らせる通知をウェブブラウザ100に送る。ウェブブラウザ100の通知仲介部130は、その通知をfaultcommon表示プログラム及びこれに対応する常駐プログラムに渡す。これにより、それらまで表示していたエラー画面600は非表示となり、faultcommon表示プログラムは一時的な表示のためのものであり近々に再度表示される可能性はほぼ無いので、メモリ上から削除される。これに伴い、それまで背面表示状態であったアドレス帳画面が前面表示となる。この結果、表示態様管理モジュール124内の管理情報は図12Oに示す状態となる。

0084

次に、ホームボタンが押下されると、ホーム画面300が前面表示となり、アドレス帳画面は非表示となる。表示態様管理モジュール124内の管理情報は図12Pに示す状態となる。

0085

次に、ホーム画面300内のコピーボタンが押下されると、copy表示プログラムが起動され、この表示プログラムが生成したコピー画面400が前面に表示される。コピーボタン押下の直前の時点では、copy表示プログラムはメモリ上にロードされていないので、コピーボタンが押下されると、プログラム管理部120は新たなPID(プログラムID。この場合は「9」)を採番し、copy表示プログラムに付与する。表示態様管理モジュール124内の管理情報は図12Qに示す状態となる。

0086

次に、外部モジュール200の動作について説明する。

0087

前述の通り、外部モジュール200の情報通知管理部204には、ウェブブラウザ100の通知仲介部130から登録された通知対象の情報項目のリストが保持されている。情報保持部202に保持された情報項目の値に変化があった場合、外部モジュール200は、その情報項目が通知対象であるかどうかをそのリストに基づいて判定する。この判定の結果、その変化した情報項目が通知対象であれば、WebSocketサーバ206又はSOAPサーバ208のうちその情報項目に対応するサーバが、その情報項目の変化をウェブブラウザ100に通知する。この通知には、その情報項目の情報IDと、変化後の値とが含まれる。なお、値が変化した情報項目が通知対象でない(すなわちそのリストに含まれない)場合は、その情報項目の変化はウェブブラウザ100には通知されない。

0088

次に、通知仲介部130の機能について説明する。上述の通り、通知仲介部130には、各プログラム110の起動時に登録された情報を保持する通知登録テーブル(図10参照)がある。通知仲介部130は、外部モジュール200から通知対象の情報項目についての通知を受け取った場合、通知登録テーブルを参照して、その通知を処理する。この処理の手順を図13に示す。

0089

この手順では、通知仲介部130は、外部モジュール200から受け取った通知に含まれる情報IDを取得し(S10)、取得した情報IDを含むエントリを通知登録テーブルから抽出する(S12)。例えば、通知登録テーブルの登録内容図10に示すものであり、外部モジュール200から受け取った通知に含まれる情報IDが「DeviceFault」である場合、(プログラム名,表示プログラム名,通知方法,キャッシュ要否)がそれぞれ(Device,baseframe,常時,要)、(Device,device,表示時,要)、(Device,notification,前面表示時,要)、(Fault,baseframe,常時,不要)、(Fault,faultcommon,前面表示時,不要)である4つのエントリが抽出される。

0090

S12で情報IDに対応するエントリが1つも抽出されない場合は、処理を終了する(図13では省略)。S12で1以上のエントリが抽出された場合には、それらエントリごとに、S16〜S20の処理が行われる。

0091

すなわち、通知仲介部130は、処理対象のエントリ内の通知方法が「常時」か否かを判定し(S14)、「常時」でない場合、そのエントリ内の「表示プログラム名」に対応する表示プログラムの現在の表示態様を表示態様管理モジュール124から取得する(S16)。次に通知仲介部130は、取得した現在の表示態様が、当該エントリ内の通知方法に該当するか否かを判定する(S18)。例えば、エントリ内の通知方法が「前面表示時」である場合には、S16で取得した表示態様が「前面表示」である場合に限り、S18の判定結果がYesとなる。また、エントリ内の通知方法が「表示時」である場合には、S16で取得した表示態様が「非表示」以外の場合(すなわち「前面表示」又は「背面表示」の場合)に、S18の判定結果がYesとなる。
取得した表示態様が当該エントリの通知方法に該当すれば、通知仲介部130は、その表示プログラム114に対して、当該通知の情報内容(情報IDと、情報項目の値(変化後のもの)とを含む)を通知する(S20)。この通知を受けた表示プログラム114は、その表示プログラム114が生成している画面に、その通知の内容を反映させる。これにより、現在表示されているその表示プログラム114の画面の画像が、外部モジュール200からの通知の内容を反映したものに変化する。例えば、ある用紙トレイ内の用紙サイズが変更され、その用紙トレイの識別情報と変更後の用紙サイズを含んだ通知が外部モジュール200から送信され、かつ現在copy表示プログラムによるコピー画面400が前面表示されている場合、その変更後の用紙サイズの情報がコピー画面400上の当該用紙トレイの用紙サイズの表示に反映される。

0092

一方、S16で取得した表示態様が当該エントリの通知方法に該当しない場合、通知仲介部130は、S20の処理をスキップする。

0093

また、S14で通知方法が「常時」と判定した場合、通知仲介部130は、その表示プログラム114に対して、当該通知の情報内容を通知する(S20)。

0094

また、図13では省略したが、通知仲介部130は、外部モジュール200から受信した通知内の情報IDを含むエントリであって、「キャッシュ要否」の項目の値が「要」であるエントリが通知登録テーブル内に1以上あれば、その通知の情報(情報IDと、当該情報項目の値(変化後の値)を含む)をキャッシュする。すなわち、通知仲介部130は、情報ID毎に、その情報IDに対応付けてその情報IDが示す情報項目の最新の値を保持するキャッシュを有しており、受信した通知がキャッシュ「要」であれば、キャッシュ内のその通知の情報IDに対応する最新の値を、その通知が示す値へと更新する。なお、キャッシュされた情報項目の値は、その情報項目を表示に用いる表示プログラム114が「前面表示」に遷移する際(すなわちUIの表示装置に表示される際)に、その表示プログラム114により参照され、その表示プログラム114が生成する画面に反映される。

0095

図13の手順では、外部モジュール200からのある情報IDについての通知を受け取る旨を示すエントリが通知登録テーブル(図10参照)に登録されていることを前提としている。そして、通知仲介部130は、そのエントリ内の表示プログラム114に対して通知を渡すか否かを、その表示プログラム114の表示態様が、そのエントリの通知方法に該当するか否かで判定した。表示プログラム114が非表示である場合、その表示プログラム114の生成する画面は現在表示されておらず、またその画面が近い将来表示されるかどうかも未定である。したがって、仮にこの段階で通知をその表示プログラム114に渡すことができたとしても、渡した通知が無駄になる可能性が高い。したがって、非表示の表示プログラム114には通知は渡されない。また、「背面表示」のように「前面表示」と「非表示」の中間的な意味合いを持つ表示態様の場合、当該表示態様の表示プログラム114にその通知を渡すべきかどうか(渡した通知が無駄になる可能性が低いかどうか)は、表示プログラム114毎に異なる。したがって、「前面表示」と「非表示」の中間的な意味合いの表示態様である場合にある情報IDについての通知を渡すべきであると判断される表示プログラム114については、通知登録テーブル内のその情報IDとその表示プログラムとのペアを含んだエントリの通知方法は、「表示時」(すなわち背面表示等の場合も通知される)とされる。逆に、「前面表示」と「非表示」の中間的な意味合いの表示態様である場合にある情報IDについての通知を渡すべきでないと判断される表示プログラム114については、通知登録テーブル内のその情報IDとその表示プログラムとのペアを含んだエントリの通知方法は、「前面表示時」とされる。

0096

図13の手順では、外部モジュール200からの通知を表示プログラム114に渡すかどうかを、通知登録テーブル内の対応するエントリ内の通知方法を参照して決めたが、これは一例に過ぎない。より簡素な方法として、S16で取得した表示プログラム114の表示態様が前面表示か否かをS18で判定し、前面表示の場合は、S20で当該表示プログラム114に通知を渡し、前面表示でない場合にはS20をスキップするという手順を用いてもよい。現在「前面表示」でない表示プログラム114にその通知を渡しても、渡した通知が無駄になる可能性が高いので、このような簡素な手順でもある程度の効果を見込める。

0097

図13の手順は、外部モジュール200からの通知を渡す表示プログラム114の絞込を、それら各表示プログラム114の現在の表示態様(図12A図12Q参照)に基づいて行った。別の例として、ライフサイクル管理モジュール122が管理する各表示プログラム114のライフサイクル状態に応じて、通知先の絞込を行ってもよい。

0098

ライフサイクル管理モジュール122には、各表示プログラム114がロード済み状態及び非ロード済み状態のいずれであるかを示す情報が少なくとも保持されている。すなわち、プログラム管理部120は、未ロード状態の表示プログラム114を起動する指示を受けた場合、その表示プログラム114をメモリにロードして実行するが、このときその表示プログラム114のロードが完了した時点で、ライフサイクル管理モジュール122内のその表示プログラム114のライフサイクル状態を「非ロード済み状態」から「ロード済み状態」へと変更する。また、プログラム管理部120は、「ロード済み状態」の表示プログラム114をメモリから削除する処理を開始すると、ライフサイクル管理モジュール122内のその表示プログラム114のライフサイクル状態を「非ロード済み状態」へと変更する。なお、プログラム管理部120が表示プログラム114をメモリから削除するケースには、その表示プログラム114に対応する常駐プログラム112から表示プログラム114の削除指示が到来した場合と、上述した同時ロード数の上限制御によりプログラム管理部120自体がいずれかの表示プログラム114を選択して削除する場合とがある。前者の場合の例としては、例えばエラー表示用のFaultプログラムの常駐プログラム112が、エラー画面600を表示した後所定時間が経過して、そのエラー画面600を生成していた表示プログラム114を削除する場合がある。

0099

図14に、ライフサイクル状態に基づき絞込を行う場合の通知仲介部130の処理手順の一例を示す。

0100

この手順では、図13の手順のS10及びS12と同様、通知仲介部130は、外部モジュール200から受け取った通知に含まれる情報IDを取得し(S30)、取得した情報IDを含むエントリを通知登録テーブルから抽出する(S32)。S32で情報IDに対応するエントリが1つも抽出されない場合は、処理を終了する。S32で1以上のエントリが抽出された場合には、それらエントリごとに、S34〜S38の処理が行われる。

0101

すなわち、通知仲介部130は、処理対象のエントリ内の「表示プログラム名」に対応する表示プログラムの現在のライフサイクル状態をライフサイクル管理モジュール122から取得する(S34)。次に通知仲介部130は、取得した現在のライフサイクル状態が「ロード済み状態」であるかどうかを判定する(S36)。判定結果が「ロード済み状態」であれば、通知仲介部130は、その表示プログラム114に対して、当該通知の情報内容を通知する(S38)。この通知を受けた表示プログラム114は、その表示プログラム114が生成している画面の画像又は当該表示プログラム114が管理している内部状態に、その通知の内容を反映させる。一方、S34で取得したライフサイクル状態が「ロード済み状態」でない場合、通知仲介部130は、S38の処理をスキップする。

0102

このように図14に示した処理手順では、外部モジュール200からの通知を受け取るものとして登録された表示プログラム114がロード済み状態である場合にのみ、通知仲介部130はその通知をその表示プログラム114に渡す。非ロード済み状態の表示プログラム114は次にいつロードされ、表示画面を生成するのか分からないので、仮に外部モジュール200からの通知をその表示プログラム114に渡すことができたとしても、その通知は使われずに無駄になる可能性が高い。むしろ、通知仲介部130のキャッシュ内に各情報項目の最新の値を保持しておくことで、非ロード済み状態の表示プログラム114がその後起動したときに必要な情報項目の最新の値が得られるようにしておけば十分である。

0103

図14の手順では、表示プログラム114のライフサイクル状態がロード済み状態か非ロード済み状態かに応じて通知を制御した。別の例として、より詳細なライフサイクル状態を用いて通知を制御してもよい。例えば、非ロード済み状態を、ロード中状態、削除中状態、未ロード状態に細分する例を考える。この場合、通知仲介部130は、ある表示プログラムについてS34で取得したライフサイクル状態がロード中状態であれば、その表示プログラム114のロードが完了するのを待ち、完了したら、その表示プログラム114に通知を渡す。一方、その表示プログラム114についてS34で取得したライフサイクル状態が削除中状態又は未ロード状態であれば、通知をその表示プログラム114には渡さない。ロード済み状態の場合は、図14の手順と同様、S38で表示プログラム114に通知を渡す。

0104

次に、図15を参照して、表示プログラム114の表示態様とライフサイクル状態の両方を考慮する場合の通知仲介部130の処理手順を説明する。

0105

図15の手順は、S30〜S36までは図14の手順と同じである。図14の手順では、S36で表示プログラム114のライフサイクル状態がロード済み状態と判定された場合、通知仲介部130は必ずその表示プログラム114に対して通知を渡した。これに対して、図15の手順では、S36で表示プログラム114がロード済み状態と判定した場合、通知仲介部130は、図13のS14〜S20の処理を行うことで、その表示プログラム114に対して通知を行うか否かを、その表示プログラム114の表示態様に基づいて制御する。

0106

以上に説明した本発明の実施形態はあくまで一例に過ぎず、本発明の範囲内で様々な変形が可能である。例えば、上記実施形態ではウェブ(WWW :World Wide Web)技術によりUIを構築したが、ウェブ技術以外の方法でUIを構築した場合でも、上記実施形態の手法は適用可能である。また、上記実施形態は、画像形成装置のUIに適用した場合の例であったが、画像形成装置以外の装置の情報処理機構が実行する各プログラムに外部モジュールからの通知を渡す場合にも上記実施形態の手法は適用可能である。

0107

以上に例示したウェブブラウザ100及び外部モジュール200は、コンピュータに上述の各機能を表すプログラムを実行させることにより実現される。ここで、コンピュータは、例えば、ハードウエアとして、CPU等のマイクロプロセッサランダムアクセスメモリ(RAM)およびリードオンリメモリ(ROM)等のメモリ(一次記憶)、フラッシュメモリSSD(ソリッドステートドライブ)、HDDハードディスクドライブ)や等の固定記憶装置を制御するコントローラ、各種I/O(入出力インタフェースローカルエリアネットワークなどのネットワークとの接続のための制御を行うネットワークインタフェース等が、たとえばバス等を介して接続された回路構成を有する。それら各機能の処理内容記述されたプログラムがネットワーク等の経由でフラッシュメモリ等の固定記憶装置に保存され、コンピュータにインストールされる。固定記憶装置に記憶されたプログラムがRAMに読み出されCPU等のマイクロプロセッサにより実行されることにより、上に例示した機能モジュール群が実現される。

0108

100ウェブブラウザ、110プログラム、112常駐プログラム、114表示プログラム、120プログラム管理部、122ライフサイクル管理モジュール、124表示態様管理モジュール、130通知仲介部、132イベント管理部、200外部モジュール、202情報保持部、204情報通知管理部、206 WebSocketサーバ、208SOAPサーバ。

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

該当するデータがありません

関連する公募課題

該当するデータがありません

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

(分野番号表示ON)※整理標準化データをもとに当社作成

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い技術

関連性が強い 技術一覧

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

該当するデータがありません

この 技術と関連する公募課題

該当するデータがありません

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ