JP2014235645A - 機器、情報処理端末、情報処理システム、表示制御方法、及びプログラム - Google Patents

Abstract

【課題】機器の操作部の操作性を向上させること。
【解決手段】操作部を有する機器であって、前記機器は、画面の構成要素の表示を要求する第一の処理部と、当該機器におけるユーザの認証状態の変化を検知する検知部と、前記要求を受け付け、前記構成要素の識別情報を指定して、当該構成要素の表示要求を前記操作部に送信する、又は前記認証状態の変化を示す通知情報を前記操作部に送信する第一の通信部とを有し、前記操作部は、前記表示要求又は前記通知情報を受信する第二の通信部と、前記第二の通信部によって受信された表示要求に指定された識別情報に係る構成要素を、前記第一の通信部が受け付けた要求に指定された形態と異なる形態で表示させ、前記通知情報に応じて前記構成要素の表示態様を変化させる第二の処理部とを有する。
【選択図】図４

Description

本発明は、機器、情報処理端末、情報処理システム、表示制御方法、及びプログラム
に関する。

スマートフォンやタブレット型端末等の情報処理端末は、ユーザが任意にアプリケーションプログラムをインストールして、機能拡張等を図ることができる。また、このような情報処理端末は、表現豊かなＧＵＩ（Graphical User Interface）を表示可能であると共に、タッチパネルを介した操作性においても優れている。

本願発明者は、上記のような情報処理端末を、画像形成装置等の機器の操作部として機能させることを検討している。例えば、機器上で動作する各種のアプリケーションプログラムの操作画面を、情報処理端末に表示可能とすることが検討されている。既に市場において提供されているアプリケーションプログラムは多数存在するため、これらの資産に対する影響を出来るだけ抑えて、情報処理端末を機器の操作部として機能させるのが望ましい。そこで、情報処理端末に、機器における従来の操作部をエミュレートさせることが考えられる。

しかしながら、単なるエミュレートの場合、情報処理端末が有する表現豊かなＧＵＩによる操作性等を享受するのは困難である。エミュレートによって表示される画面は、従来の操作部が有する表示能力に応じた画面に過ぎないからである。したがって、単なるエミュレートでは、情報処理端末を操作部として機能させることの意義が没却されてしまう可能性が有る。

本発明は、上記の点に鑑みてなされたものであって、機器の操作部の操作性を向上させることを目的とする。

そこで上記課題を解決するため、操作部を有する機器であって、前記機器は、画面の構成要素の表示を要求する第一の処理部と、当該機器におけるユーザの認証状態の変化を検知する検知部と、前記要求を受け付け、前記構成要素の識別情報を指定して、当該構成要素の表示要求を前記操作部に送信する、又は前記認証状態の変化を示す通知情報を前記操作部に送信する第一の通信部とを有し、前記操作部は、前記表示要求又は前記通知情報を受信する第二の通信部と、前記第二の通信部によって受信された表示要求に指定された識別情報に係る構成要素を、前記第一の通信部が受け付けた要求に指定された形態と異なる形態で表示させ、前記通知情報に応じて前記構成要素の表示態様を変化させる第二の処理部とを有する。

機器の操作部の操作性を向上させること。

本発明の実施の形態における情報処理システムの構成例を示す図である。 本発明の実施の形態における画像形成装置のハードウェア構成例を示す図である。 本発明の実施の形態における情報処理端末のハードウェア構成例を示す図である。 本発明の実施の形態における情報処理システムの機能構成例を示す図である。 情報処理システムにおける表示機構を説明するための図である。 アプリケーションの起動時及び停止時の処理手順の一例を説明するためのシーケンス図である。 ホーム画面の表示例を示す図である。 ＳＤＫアプリの起動に応じた操作画面の生成処理の処理手順の一例を説明するためのシーケンス図である。 操作画面の表示例を示す図である。 操作画面における表示部品の操作に応じて実行される処理の処理手順の一例を説明するためのシーケンス図である。 アクションイベントに応じて実行される処理手順の一例を説明するためのシーケンス図である。 操作画面の表示状態の変更例を示す図である。 ソフトキーボードを表示させる際の処理手順の一例を説明するためのシーケンス図である。 文字列の入力に応じて実行される処理手順の一例を説明するためのシーケンス図である。 リッチＵＩアプリが画像形成装置に保存されているファイルリソースを必要とした場合に実行される処理手順の一例を説明するためのシーケンス図である。 認証リスナーの登録処理の処理手順の一例を説明するためのシーケンス図である。 リッチＵＩアプリに対して画像形成装置の認証状態の変化を通知するための処理手順の一例を説明するためのシーケンス図である。 認証状態の変化に関する通知情報の構成例を示す図である。 認証リスナーの登録解除処理の処理手順の一例を説明するためのシーケンス図である。

以下、図面に基づいて本発明の実施の形態を説明する。図１は、本発明の実施の形態における情報処理システムの構成例を示す図である。図１に示される情報処理システム１において、画像形成装置１０は、情報処理端末２０と通信可能に接続される。画像形成装置１０と情報処理端末２０との通信は、例えば、ＵＳＢ（Universal Serial Bus）、近距離無線通信、又はＬＡＮ（有線又は無線の別は問わない）等のネットワークを介して行われる。

画像形成装置１０は、印刷、スキャン、コピー、及びＦＡＸ送受信等のうちの２以上の機能を一台の筐体によって実現する複合機である。但し、いずれか一つの機能を有する機器が画像形成装置１０として用いられてもよい。また、本実施の形態における画像形成装置１０は、機器の一例であり、プロジェクタ、テレビ会議システム、又はデジタルカメラ等の機器が、画像形成装置１０の代わりに用いられてもよい。

情報処理端末２０は、例えば、スマートフォンやタブレット型端末等、単独で完結した情報処理を実行可能な電子機器である。本実施の形態において、情報処理端末２０は、画像形成装置１０の操作部として機能する。より詳しくは、情報処理端末２０は、従来、画像形成装置１０の専用の操作部として設置されていた操作パネルの代わりに、画像形成装置１０に接続される。以下、単に、「操作パネル」というとき、従来の画像形成装置１０において設置されていた操作パネルをいう。

情報処理端末２０は、例えば、画像形成装置１０の所定の位置（例えば、操作パネルが配置される位置）に固定されて設置される。したがって、情報処理端末２０及び画像形成装置１０とは、一台の装置として把握されてもよい。または、情報処理端末２０は、画像形成装置１０から取り外し可能（分離可能）であってもよい。情報処理端末２０が取り外された状態において、情報処理端末２０は、Ｂｌｕｅｔｏｏｔｈ（登録商標）又は赤外線等の無線通信等を介して、画像形成装置１０の操作部として機能可能であってもよい。

図２は、本発明の実施の形態における画像形成装置のハードウェア構成例を示す図である。図２において、画像形成装置１０は、コントローラ１１、スキャナ１２、プリンタ１３、モデム１４、端末インタフェース１５、ネットワークインタフェース１６、及びＳＤカードスロット１７等のハードウェアを有する。

コントローラ１１は、ＣＰＵ１１１、ＲＡＭ１１２、ＲＯＭ１１３、ＨＤＤ１１４、及びＮＶＲＡＭ１１５等を有する。ＲＯＭ１１３には、各種のプログラムやプログラムによって利用されるデータ等が記憶されている。ＲＡＭ１１２は、プログラムをロードするための記憶領域や、ロードされたプログラムのワーク領域等として用いられる。ＣＰＵ１１１は、ＲＡＭ１１２にロードされたプログラムを処理することにより、各種の機能を実現する。ＨＤＤ１１４には、プログラムやプログラムが利用する各種のデータ等が記憶される。ＮＶＲＡＭ１１５には、各種の設定情報等が記憶される。

スキャナ１２は、原稿より画像データを読み取るためのハードウェア（画像読取手段）である。プリンタ１３は、印刷データを印刷用紙に印刷するためのハードウェア（印刷手段）である。モデム１４は、電話回線に接続するためのハードウェアであり、ＦＡＸ通信による画像データの送受信を実行するために用いられる。端末インタフェース１５は、情報処理端末２０と通信（接続）するためのインタフェースである。例えば、端末インタフェース１５は、例えば、ＵＳＢインタフェースでもよいし、近距離無線通信のためのハードウェアでもよい。または、端末インタフェース１５は、ＬＡＮ等のネットワーク（有線又は無線の別は問わない。）に接続するためのハードウェアでもよい。ネットワークインタフェース１６は、ＬＡＮ等のネットワーク（有線又は無線の別は問わない。）に接続するためのハードウェアである。ＳＤカードスロット１７は、ＳＤカード８０に記憶されたプログラムを読み取るために利用される。すなわち、画像形成装置１０では、ＲＯＭ１１３に記憶されたプログラムだけでなく、ＳＤカード８０に記憶されたプログラムもＲＡＭ１１２にロードされ、実行されうる。なお、他の記録媒体（例えば、ＣＤ−ＲＯＭ又はＵＳＢ（Universal Serial Bus）メモリ等）によってＳＤカード８０が代替されてもよい。すなわち、ＳＤカード８０の位置付けに相当する記録媒体の種類は、所定のものに限定されない。この場合、ＳＤカードスロット１７は、記録媒体の種類に応じたハードウェアによって代替されればよい。

図３は、本発明の実施の形態における情報処理端末のハードウェア構成例を示す図である。図３において、情報処理端末２０は、ＣＰＵ２０１、メモリ２０２、補助記憶装置２０３、タッチパネル２０４、無線通信装置２０５、及び機器インタフェース２０６等を有する。

補助記憶装置２０３は、情報処理端末２０にインストールされたプログラム等を記憶する。メモリ２０２は、プログラムの起動指示があった場合に、補助記憶装置２０３からプログラムを読み出して記憶する。ＣＰＵ２０１は、メモリ２０２に記憶されたプログラムに従って情報処理端末２０に係る機能を実現する。

タッチパネル２０４は、入力機能と表示機能との双方を備えた電子部品であり、情報の表示や、ユーザからの入力の受け付け等を行う。タッチパネル２０４は、表示装置２１１及び入力装置２１２等を含む。

表示装置２１１は、液晶ディスプレイ等であり、タッチパネル２０４の表示機能を担う。入力装置２１２は、表示装置２１１に対する接触物の接触を検出するセンサを含む電子部品である。接触物の接触の検出方式は、静電方式、抵抗膜方式、又は光学方式等、公知の方式のいずれであってもよい。なお、接触物とは、タッチパネル２０４の接触面（表面）に接触する物体をいう。斯かる物体の一例として、ユーザの指や専用又は一般のペン等が挙げられる。

無線通信装置２０５は、無線ＬＡＮ（Local Area Network）又は移動体通信網等における通信を行うために必要とされるアンテナ等の電子部品である。機器インタフェース２０６は、画像形成装置１０と通信するためのインタフェースである。すなわち、機器インタフェース２０６は、端末インタフェース１５に対応した形態によって、画像形成装置１０との通信を行う。

図４は、本発明の実施の形態における情報処理システムの機能構成例を示す図である。図４において、画像形成装置１０は、ＯＳ１２１、コントロールサービス１２２、ＳＤＫプラットフォーム１２３、及びＳＤＫアプリ１２４等を有する。

ＯＳ１２１は、いわゆるＯＳ（Operating System）である。画像形成装置１０上の各ソフトウェアは、ＯＳ１２１上においてプロセス又はスレッドとして動作する。

コントロールサービス１２２は、各種のハードウェアリソース等を制御するための機能を有し、その機能を上位アプリケーション等に利用させるためのインタフェースを提供するソフトウェアモジュール群である。コントロールサービス１２２は、例えば、ネットワーク通信に関する機能、スキャナ１２の制御機能、プリンタ１３の制御機能、メモリ（ＲＡＭ１１２、ＲＯＭ１１３、及びＮＶＲＡＭ１１５等）の管理機能等を有する。また、コントロールサービス１２２は、操作パネルの制御機能をも有する。

ＳＤＫプラットフォーム１２３は、ＳＤＫアプリ１２４を開発するためのＡＰＩ（Application Program Interface）を備えると共に、ＳＤＫアプリ１２４の実行環境を提供する。ＡＰＩの形態は、例えば、関数であってもよいし、オブジェクト指向のクラス及びクラスのメソッド等であってもよい。以下、ＳＤＫプラットフォーム１２３が提供するＡＰＩを、「ＳＤＫＡＰＩ」という。例えば、ＳＤＫプラットフォーム１２３は、スキャン機能に関するＳＤＫＡＰＩ、印刷機能に関するＳＤＫＡＰＩ、コピー機能に関するＳＤＫＡＰＩ等をＳＤＫアプリ１２４に提供する。なお、ＳＤＫＡＰＩは公開されており、サードベンダ等によってもＳＤＫアプリ１２４は開発されうる。なお、ＳＤＫプラットフォーム１２３は、Ｊａｖａ（登録商標）ＶＭ（Virtual Machine）を含んでいてもよい。この場合、ＳＤＫアプリ１２４は、Ｊａｖａ（登録商標）言語によって実装される。

なお、本実施の形態では、便宜上、画像形成装置１０にインストール可能なプログラムとして、ＳＤＫアプリ１２４及びＳＤＫプラットフォーム１２３等が例示されているが、画像形成装置１０にインストール可能なプログラムは、ＳＤＫアプリ１２４及びＳＤＫプラットフォーム１２３等に限定されない。画像形成装置１０には、ＳＤＫアプリ１２４及びＳＤＫプラットフォーム１２３以外のプログラムがインストールされてもよく、画像形成装置１０にインストール可能なプログラムには、画像形成装置１０にインストールされるプログラム全般が含まれうる。

図４において、ＳＤＫプラットフォーム１２３は、パネル管理部１２３１、端末通信部１２３２、及び認証管理部１２３３等を含む。パネル管理部１２３１は、操作パネルの表示制御を本来の責務とする。すなわち、パネル管理部１２３１は、操作パネルの表示制御に関するＳＤＫＡＰＩ（以下、「ＳＤＫパネルＡＰＩ」という。）を提供し、ＳＤＫパネルＡＰＩの呼び出しに応じて、操作パネルの表示制御を行う。例えば、パネル管理部１２３１は、ＳＤＫアプリ１２４からの表示部品の表示状態の変更要求を、コントロールサービス１２２に伝達する。その結果、コントロールサービス１２２によって、操作パネルにおいて当該表示部品の表示状態が変更される。表示部品の表示状態の変更には、表示部品の表示及び非表示、並びに表示部品の反転等が含まれる。

但し、本実施の形態におけるパネル管理部１２３１は、操作パネルの表示制御の要求に応じた表示状態の変更を、情報処理端末２０に反映させるための処理を実行する。例えば、パネル管理部１２３１は、ＳＤＫアプリ１２４からの表示部品の表示状態の変更要求を、端末通信部１２３２を介して情報処理端末２０に伝達する。その結果、ＳＤＫアプリ１２４による表示制御を、情報処理端末２０におけるリッチＵＩアプリ２５による表示制御と連携又は同期させることができる。

なお、表示部品とは、画面の構成要素となる各種の部品である。表示部品は、例えば、画像形成装置１０に処理（ジョブ）を実行させるために表示される。表示部品の一例として、ボタン、ソフトキー、ソフトキーボード、ウィンドウ、文字列を表示させるラベル等が挙げられる。なお、ソフトキーとは、例えば、スマートフォンやタブレット型端末等において、文字列の入力を受け付けるために表示される、ソフトウェアのキー群である。

認証管理部１２３３は、画像形成装置１０におけるユーザの認証状態の管理等を行う。例えば、認証管理部１２３３は、画像形成装置１０に対するユーザのログイン又はログアウト等の認証状態の変化を通知するための情報を、ＳＤＫアプリ１２４に通知する。認証管理部１２３３は、また、当該情報を、端末通信部１２３２を介して情報処理端末２０に伝達する。

端末通信部１２３２は、情報処理端末２０との通信を制御する。端末通信部１２３２は、例えば、ＨＴＴＰ（HyperText Transfer Protocol）によって情報処理端末２０と通信する。但し、画像形成装置１０と情報処理端末２０との間において利用される通信プロトコルは、ＨＴＴＰに限定されなくてもよい。

ＳＤＫアプリ１２４は、画像形成装置１０の出荷後において、画像形成装置１０の機能拡張を図るために追加的にインストールされるアプリケーションプログラム（又はプラグインともいう。）である。図４では、ＳＤＫアプリ１２４として、レガシーアプリＡ１２４１が例示されている。レガシーアプリＡ１２４１は、操作画面の表示をパネル管理部１２３１に要求し、当該操作画面に対する入力に応じて、所定の処理を実行する。なお、レガシーアプリＡ１２４１の「レガシー」とは、後述されるリッチＵＩアプリ２５に対する相対的な表現として便宜的に付加されたものあり、レガシーアプリＡ１２４１の機能や用途等を限定する趣旨の文言ではない。

一方、情報処理端末２０は、リッチＵＩＯＳ２１、コントローラ通信部２２、アプリ管理部２３、パネルフィルタ部２４、リッチＵＩアプリ２５、及び認証ラッパー部２６等を有する。

リッチＵＩＯＳ２１は、操作性に優れ、表現豊かなＧＵＩ（Graphical User Interface）を提供可能なＯＳ（Operating System）である。例えば、リッチＵＩＯＳ２１は、近年におけるスマートフォンやタブレット型端末等において利用されるＯＳであってもよい。

コントローラ通信部２２は、画像形成装置１０の端末通信部１２３２との通信を制御する。アプリ管理部２３は、リッチＵＩアプリ２５とＳＤＫアプリ１２４との対応関係の管理等を行う。

パネルフィルタ部２４は、リッチＵＩアプリ２５とＳＤＫアプリ１２４との間の、表示制御の連携又は同期のためのインタフェースを、リッチＵＩアプリ２５に提供する。

認証ラッパー部２６は、認証管理部１２３３より通知される、認証状態の変化を示す情報を、リッチＵＩアプリ２５に通知する。

リッチＵＩアプリ２５は、ＳＤＫアプリ１２４による操作パネルに対する表示制御を、情報処理端末２０に反映するために、情報処理端末２０にインストールされるアプリケーションプログラムである。基本的に、リッチＵＩアプリ２５とＳＤＫアプリ１２４とは１対１の関係を有する。例えば、図Ｋ３において例示されているリッチＵＩアプリＡ２５１は、レガシーアプリＡ１２４１のＧＵＩを、リッチＵＩＯＳ２１上で実現するためのリッチＵＩアプリ２５である。

なお、リッチＵＩＯＳ２１やリッチＵＩアプリ２５の「リッチ」とは、レガシーアプリＡ１２４１に対する相対的な表現として便宜的に付加されたものであり、リッチＵＩＯＳ２１やリッチＵＩアプリ２５の機能や用途等を限定する趣旨の文言ではない。

続いて、情報処理システム１における表示機構について更に詳しく説明する。図５は、情報処理システムにおける表示機構を説明するための図である。

レガシーアプリＡ１２４１が、何らかの表示部品（以下、「表示部品Ａ」という。）の生成をパネル管理部１２３１に要求すると（Ｓ１１）、パネル管理部１２３１は、従来通りコントロールサービス１２２に対して表示部品Ａの生成（表示）を要求すると共に（Ｓ１２）、端末通信部１２３２に対して、表示部品Ａを生成したことの通知を要求する（Ｓ１３）。

表示部品Ａの生成要求に応じ、コントロールサービス１２２は、操作パネルが設置されていた頃と同様に、表示部品Ａを生成する（Ｓ１４）。但し、操作パネルは実在しないため、生成された表示部品Ａの表示は行われない。

一方、端末通信部１２３２は、表示部品Ａの生成通知をコントローラ通信部２２に送信する（Ｓ１５）。コントローラ通信部２２は、表示部品Ａの生成をパネルフィルタ部２４に通知する（Ｓ１６）。パネルフィルタ部２４は、当該生成要求をリッチＵＩアプリＡ２５１に通知する（Ｓ１７）。リッチＵＩアプリＡ２５１は、表示部品Ａを生成する。生成された表示部品Ａは、タッチパネル２０４に表示される。なお、リッチＵＩアプリＡ２５１が、「表示部品Ａ」をどのような表示部品として生成するかは、リッチＵＩアプリＡ２５１の実装に依存する。例えば、レガシーアプリＡ１２４１にとって、「表示部品Ａ」がボタンであっとしても、リッチＵＩアプリＡ２５１は、「表示部品Ａ」を、リッチＵＩＯＳ２１上で表現可能な他の表示部品として生成することもできる。すなわち、リッチＵＩａプリＡ２５１は、レガシーアプリＡ１２４１が、パネル管理部１２３１に対して生成を要求した際に指定した表示部品と異なる形態（種別）の表示部品を生成してもよい。そうすることで、単なるエミュレータと異なり、リッチＵＩＯＳ２１における表現能力を駆使したＧＵＩの構築が実現可能となる。

なお、図５より明らかなように、情報処理端末２０が操作パネルに置き換わったことによる影響の大部分は、ＳＤＫプラットフォーム１２３及びコントロールサービス１２２において吸収されている。したがって、既存の資産であるＳＤＫアプリ１２４のソースコードの改変の必要性を低減させることができる。

以下、情報処理システム１が実行する処理手順について説明する。図６は、アプリケーションの起動時及び停止時の処理手順の一例を説明するためのシーケンス図である。

例えば、情報処理端末２０のタッチパネル２０４に表示されているホーム画面（初期画面）において、リッチＵＩアプリＡ２５１のアイコンがタッチされると、リッチＵＩＯＳ２１は、選択されたアイコンに対応するリッチＵＩアプリＡ２５１に対して、アクティブであることを通知する（Ｓ１０１）。アクティブであることとは、操作対象として画面の表示領域を占有する地位を得たことをいう。

図７は、ホーム画面の表示例を示す図である。図７において、（１）は、情報処理端末２０のタッチパネル２０４におけるホーム画面５１０の表示例を示す。また、（２）は、参考までに、画像形成装置１０において仮想的に生成されるホーム画面６１０の例を示す。

例えば、タッチパネル２０４において、アイコン５１１が選択されると、ステップＳ１０１が実行される。なお、アイコン５１１は、ホーム画面６１０のアイコン６１１に対応する。

続いて、リッチＵＩアプリＡ２５１は、マスク画面をタッチパネル２０４に表示させる（Ｓ１０２）。マスク画面とは、図５において説明した機構によって、ＳＤＫアプリ１２４からの要求に応じてタッチパネル２０４に表示される操作画面を隠蔽することで、当該操作画面の可視化のタイミングを、リッチＵＩアプリＡ２５１によって制御可能とするために表示される画面である。例えば、マスク画面には、「しばらくお待ち下さい。」等のメッセージが表示されてもよい。

続いて、リッチＵＩアプリＡ２５１は、リッチＵＩアプリＡ２５１のアプリＩＤを指定して、オーナー獲得をアプリ管理部２３に通知する（Ｓ１０３）。アプリＩＤは、リッチＵＩアプリ２５ごとの識別情報である。また、オーナー獲得とは、画面の表示領域のオーナー（占有者）としての地位を獲得することをいい、アクティブになることとほぼ同義である。

続いて、アプリ管理部２３は、オーナー獲得の通知に指定されたアプリＩＤに対応するＳＤＫアプリ１２４のプロダクトＩＤを判定する（Ｓ１０４）。具体的には、情報処理端末２０の補助記憶装置２０３には、リッチＵＩアプリ２５ごとに設定ファイルが記憶されている。各設定ファイルには、当該設定ファイルに係るリッチＵＩアプリ２５のアプリＩＤと、当該リッチＵＩアプリ２５に対応するＳＤＫアプリ１２４のプロダクトＩＤとが対応付けられて記憶されている。したがって、アプリ管理部２３は、オーナー獲得の通知に指定されたアプリＩＤに対応する設定ファイルよりプロダクトＩＤを取得する。なお、プロダクトＩＤとは、ＳＤＫアプリ１２４ごとの識別情報である。

なお、ステップＳ１０３において、リッチＵＩアプリＡ２５１は、自らに対応するＳＤＫアプリ１２４のプロダクトＩＤを指定して、オーナー獲得をアプリ管理部２３に通知してもよい。この場合、リッチＵＩアプリＡ２５１は、自らの設定ファイルより、当該プロダクトＩＤを取得してもよいし、リッチＵＩアプリＡ２５１のソースコード内に、当該プロダクトＩＤが記述されていてもよい。リッチＵＩアプリＡ２５１によってプロダクトＩＤが指定される場合、ステップＳ１０４は、実行されなくてもよい。

続いて、アプリ管理部２３は、取得されたプロダクトＩＤを指定して、ＳＤＫプラットフォーム１２３に対して、当該プロダクトＩＤに係るＳＤＫアプリ１２４（レガシーアプリＡ１２４１）に関するオーナー獲得要求を送信する（Ｓ１０５）。オーナー獲得要求は、指定されたプロダクトＩＤに係るＳＤＫアプリ１２４に、オーナーの地位を獲得させることの要求を送信する（Ｓ１０５）。ＳＤＫアプリ１２４にとって、オーナーの地位とは、操作パネルに対する画面の表示領域のオーナーとしての地位である。なお、図６においては省略されているが、アプリ管理部２３と、ＳＤＫプラットフォーム１２３との間の通信は、コントローラ通信部２２及び端末通信部１２３２を介して行われる。

続いて、ＳＤＫプラットフォーム１２３は、オーナー獲得要求に指定されたプロダクトＩＤに係るレガシーアプリＡ１２４１を起動させる（Ｓ１０６）。なお、レガシーアプリＡ１２４１が既に起動されている場合には、ステップＳ１０６はスキップされる。レガシーアプリＡ１２４１が既に起動されている場合の一例として、画像形成装置１０の起動後に、既に図６の処理が１回以上実行されている場合が挙げられる。

起動されたレガシーアプリＡ１２４１は、自らの操作画面の生成処理を開始し、当該生成処理において生成される表示部品が、図５において説明した機構によってタッチパネル２０４に表示されるが、この処理手順については、後述される。なお、この時点では、タッチパネル２０４には、マスク画面が表示されているため、各表示部品は、マスク画面に隠蔽された（覆われた）状態となり、ユーザからは見えない状態である。

続いて、ＳＤＫプラットフォーム１２３は、コントロールサービス１２２に対して、レガシーアプリＡ１２４１について、オーナー獲得を要求する（Ｓ１０７）。操作パネルのオーナーの地位については、操作パネルへの表示制御を行うコントロールサービス１２２によって管理されているからである。

続いて、ＳＤＫプラットフォーム１２３は、レガシーアプリＡ１２４１のオーナー獲得の成否を示す応答を、アプリ管理部２３に返信する（Ｓ１０８）。アプリ管理部２３は、レガシーアプリＡ１２４１のオーナー獲得の成否を示す情報を、リッチＵＩアプリ２５に応答する（Ｓ１０９）。

リッチＵＩアプリ２５は、レガシーアプリＡ１２４１のオーナー獲得が成功した場合、マスク画面を消去する（Ｓ１１０）。その結果、マスク画面の下に生成されていた操作画面が表示される。ユーザは、リッチＵＩアプリＡ２５１が生成した操作画面を介して、レガシーアプリＡ１２４１を操作することができる。

その後、レガシーアプリＡ１２４１の利用が終了し、リッチＵＩアプリＡ２５１の停止指示がユーザによって入力されると、リッチＵＩＯＳ２１は、停止通知をリッチＵＩアプリＡ２５１に入力する（Ｓ１２１）。停止通知に応じて、リッチＵＩアプリＡ２５１は、アクティブでなくなる。その結果、操作画面は消去され、タッチパネル２０４には、例えば、ホーム画面５１０が表示される。続いて、リッチＵＩアプリＡ２５１は、オーナーのリリース（オーナーの地位の解放）をアプリ管理部２３に通知する（Ｓ１２２）。

なお、画像形成装置１０側では、依然として、レガシーアプリＡ１２４１がオーナーのままであり、オーナーに関して、情報処理端末２０と不整合が生じた状態となる。しかし、他のリッチＵＩアプリ２５がアクティブとされた際に、ステップＳ１０１以降が実行されることにより、当該リッチＵＩアプリ２５に対応したＳＤＫアプリ１２４がオーナーとなり、不整合は解消される。また、オーナーについて、画像形成装置１０と情報処理端末２０とにおいて常に同期している必要はない。したがって、本実施の形態では、ステップＳ１２２に続いて、レガシーアプリＡ１２４１についてのオーナーのリリース要求は、ＳＤＫプラットフォーム１２３に送信されない。

続いて、ステップＳ１０５におけるＳＤＫアプリ１２４（レガシーアプリＡ１２４１）の起動に応じた操作画面の生成処理の詳細について説明する。

図８は、ＳＤＫアプリの起動に応じた操作画面の生成処理の処理手順の一例を説明するためのシーケンス図である。

ステップＳ２０１において、ＳＤＫプラットフォーム１２３は、レガシーアプリＡ１２４１を起動する。なお、ステップＳ２０１は、図６におけるステップＳ１０５に対応する。レガシーアプリＡ１２４１は、起動に応じ、操作画面の生成処理を開始する（Ｓ２０２）。操作画面の生成処理の過程において、レガシーアプリＡ１２４１は、操作画面の構成要素である表示部品ごとに、表示部品の生成をパネル管理部１２３１に要求する（Ｓ２０３）。表示部品の生成要求には、表示部品の個体ごとの識別情報であるコンポーネントＩＤが指定される。なお、個体ごとの識別情報とは、例えば、表示部品の種別が同じであっても（例えば、同じボタンであっても）、表示部品ごとに値が異なる識別情報である。

パネル管理部１２３１は、指定されたコンポーネントＩＤを含む、表示部品の生成の通知を端末通信部１２３２に要求する（Ｓ２０４）。なお、図５において説明したように、パネル管理部１２３１は、コントロールサービス１２２に対して、表示部品の生成を要求するが、図８においては、便宜上、省略されている。

端末通信部１２３２は、コンポーネントＩＤを指定して、表示部品の生成通知をパネルフィルタ部２４に送信する（Ｓ２０５）。なお、図８では、便宜上、コントローラ通信部２２は省略されている。パネルフィルタ部２４は、当該コンポーネントＩＤを指定して、表示部品の生成をリッチＵＩアプリＡ２５１の通知する（Ｓ２０６）。なお、リッチＵＩアプリＡ２５１は、例えば、アクティブになった際に、パネルフィルタ部２４からの通知を受けるための通知先（一般的に、コールバック又はリスナーと呼ばれる関数又はメソッド等）を、パネルフィルタ部２４に登録しておく。パネルフィルタ部２４は、当該通知先に対し表示部品の生成を通知することで、リッチＵＩアプリＡ２５１への表示部品の生成の通知を実現する。

続いて、リッチＵＩアプリＡ２５１は、指定されたコンポーネントＩＤに対応する表示部品を生成する（Ｓ２０７）。

なお、リッチＵＩアプリＡ２５１は、コンポーネントＩＤに係る表示部品が、レガシーアプリＡ１２４１にとって、どのような表示部品であるかを知っているという前提である。例えば、リッチＵＩアプリＡ２５１の開発者は、レガシーアプリＡ１２４１の開発者と同一人物であってもよいし、レガシーアプリＡ１２４１のソースコードを理解している人物であってもよい。したがって、リッチＵＩアプリＡ２５１の開発者は、コンポーネントＩＤに係る表示部品を、リッチＵＩＯＳ２１上において、どのような表示部品によって表現すれば良いかを検討し、コンポーネントＩＤに対応させてリッチＵＩアプリＡ２５１が生成する表示部品を決定することができる。

ステップＳ２０３以降が、操作画面を構成する全ての表示部品に関して実行されると、レガシーアプリＡ１２４１の操作画面が、リッチＵＩアプリＡ２５１によって、情報処理端末２０のタッチパネル２０４に再現される。

図９は、操作画面の表示例を示す図である。図９において、（１）は、情報処理端末２０のタッチパネルに表示される操作画面５２０の例を示す。（２）は、参考までに、画像形成装置１０において仮想的に生成されるレガシーアプリＡ１２４１の操作画面６２０の例を示す。

例えば、操作画面６２０におけるボタン６２１及び６２２は、操作画面５２０において、アイコン５２１及び５２２に置き換えられている。また、操作画面６２０におけるボタン６２３は、操作画面５２０において、ボタン５２３に置き換えられている。このように、リッチＵＩアプリＡ２５１は、レガシーアプリＡ１２４１と異なった形態の表示部品を生成することで、表現豊かであって、操作性が向上した操作画面を生成することができる。

なお、ユーザから見た場合、図７の（１）のホーム画面５１０において、アイコン５１１をタッチすると、図９の操作画面に遷移するように見える。

続いて、操作画面５２０における表示部品の操作に応じて実行される処理手順の一例について説明する。図１０は、操作画面における表示部品の操作に応じて実行される処理の処理手順の一例を説明するためのシーケンス図である。

例えば、操作画面６２０において、いずれかの表示部品が操作されると（Ｓ３０１）、リッチＵＩアプリＡ２５１は、当該表示部品及び当該表示部品に対する操作内容（操作種別）を含む情報であるアクションイベントを、パネルフィルタ部２４に通知する（Ｓ３０２）。パネルフィルタ部２４は、当該アクションイベントを、パネル管理部１２３１に送信し（Ｓ３０３）、アクションイベントを受け付けたことを、リッチＵＩアプリＡ２５１に応答する（Ｓ３０４）。

一方、パネル管理部１２３１は、現在オーナーのレガシーアプリＡ１２４１に対して、アクションイベントを通知する（Ｓ３０５）。なお、レガシーアプリＡ１２４１は、例えば、オーナーとなった際に、パネル管理部１２３１からの通知を受けるための通知先（一般的に、コールバック又はリスナーと呼ばれる関数又はメソッド等）を、パネル管理部１２３１に登録しておく。パネル管理部１２３１は、当該通知先に対してアクションイベントを通知することで、レガシーアプリＡ１２４１へのアクションイベントの通知を実現する。

続いて、アクションイベントに応じて実行される処理手順の一例について説明する。図１１は、アクションイベントに応じて実行される処理手順の一例を説明するためのシーケンス図である。

ステップＳ３０５において、アクションイベントを通知されたレガシーアプリＡ１２４１は、当該アクションイベントに応じた処理を実行する。例えば、操作対象とされた表示部品の表示属性（表示状態）を変更する必要があれば、レガシーアプリＡ１２４１は、当該表示部品のコンポーネントＩＤを指定して、表示属性の変更をパネル管理部１２３１に要求する（Ｓ４０１）。なお、ステップＳ３０５においてレガシーアプリＡ１２４１に通知されるアクションイベントは、レガシーアプリＡ１２４１にとっては、例えば、操作画面６２０（図９の（２））のいずれかの表示部品に対する操作を示すアクションイベントである。すなわち、レガシーアプリＡ１２４１は、操作画面６２０に対応する操作画面５２０が、情報処理端末２０において表示されていることは認識していない。したがって、ステップＳ３０５に応じて実行されるステップＳ４０１についても、操作パネルを備えた画像形成装置においてレガシーアプリＡ１２４１が利用される場合と同じ処理が実行される。

続いて、パネル管理部１２３１は、指定されたコンポーネントＩＤを含む表示属性の変更の通知要求を端末通信部１２３２に要求する（Ｓ４０２）。なお、図５において説明したように、パネル管理部１２３１は、コントロールサービス１２２に対して、表示属性の変更を要求するが、図１１においては、便宜上、省略されている。

端末通信部１２３２は、コンポーネントＩＤを指定して、表示属性の変更通知をパネルフィルタ部２４に送信する（Ｓ４０３）。なお、図１１では、便宜上、コントローラ通信部２２は省略されている。パネルフィルタ部２４は、当該コンポーネントＩＤを指定して、表示属性の変更を、表示部品の生成の通知と同様の方法で、リッチＵＩアプリＡ２５１に通知する（Ｓ４０４）。リッチＵＩアプリＡ２５１は、指定されたコンポーネントＩＤに対応する表示部品の表示属性を、指定された状態に変更する（Ｓ４０５）。但し、変更の態様は、厳密に指定された状態でなくてもよい。表示属性の変更対象の表示部品の種別が、レガシーアプリＡ１２４１における表示部品と、リッチＵＩアプリＡ２５１における表示部品とで異なる場合、表示属性の変更の態様も変わる可能性が有るからである。

例えば、図９の操作画面５２０において、アイコン５２１がタッチされた場合、レガシーアプリＡ１２４１は、アイコン５２１を選択状態（例えば、反転表示）とすべきことを判定する。そこで、アイコン５２１のコンポーネントＩＤが指定された、選択状態を示す表示属性の変更要求が、パネル管理部１２３１、端末通信部１２３２、及びパネルフィルタ部２４等を介してレガシーアプリＡ１２４１に通知される。そこで、レガシーアプリＡ１２４１は、アイコン５２１を選択状態とさせる。その結果、操作画面５２０の表示状態は、例えば、図１２に示されるようになる。

図１２は、操作画面の表示状態の変更例を示す図である。図１２の（１）に示される操作画面５２０では、アイコン５２１が選択された状態が示されている。なお、（２）に示されるように、コントロールサービス１２２によって仮想的に生成されている操作画面６２０においても、ボタン６２１は、選択状態であることが認識されている。

なお、仮に、操作画面５２０においてボタン５２３がタッチされた場合、図１０のステップＳ３０１〜Ｓ３０５が実行され、レガシーアプリＡ１２４１は、自らに実装されているジョブのためのロジックを画像形成装置１０に実行させる。この際、レガシーアプリＡ１２４１は、ボタン５２１及び５２２のいずれが選択されているのかを、例えば、ステップＳ３０５に応じて認識しているため、ボタン５２１又は５２２が選択された状態に対応するジョブを画像形成装置１０に実行させることができる。

また、表示部品の操作に応じて画面を遷移させる必要が有る場合、ステップＳ３０５に続いて、図８のステップＳ２０２以降が実行される。その結果、新たな画面がタッチパネル２０４に表示される。

また、表示部品の操作に応じて、ソフトキーボードを表示させ、文字列の入力を受け付ける状態に遷移する必要がある場合、図１１の処理手順に代わって、図１３の処理手順が実行される。

図１３は、ソフトキーボードを表示させる際の処理手順の一例を説明するためのシーケンス図である。

レガシーアプリＡ１２４１は、アクションイベントに応じてソフトキーボードを表示させる必要があると判断すると、ソフトキーボードの生成をパネル管理部１２３１に要求する（Ｓ５０１）。パネル管理部１２３１は、ソフトキーボードの生成をコントロールサービス１２２に要求する（Ｓ５０２）。その結果、画像形成装置１０においては、仮想的にソフトキーボードが生成された状態となる。

続いて、パネル管理部１２３１は、文字列入力要求を端末通信部１２３２に入力する（Ｓ５０３）。端末通信部１２３２は、文字列入力要求を、パネルフィルタ部２４に送信する（Ｓ５０４）。なお、図１３では、便宜上、コントローラ通信部２２は省略されている。

続いて、パネルフィルタ部２４は、文字列入力要求を、リッチＵＩアプリＡ２５１に通知する（Ｓ５０５）。リッチＵＩアプリＡ２５１は、リッチＵＩＯＳ２１上において生成可能な表示部品によって、文字列の入力用の画面を生成する（Ｓ５０６）。その結果、タッチパネル２０４に、文字列の入力用の画面が表示される。なお、当該画面は、ソフトキーボードでもよいし、他の表示部品でもよい。

続いて、ステップＳ５０６に応じて、ユーザによって文字列が入力された際に実行される処理手順の一例について説明する。図１４は、文字列の入力に応じて実行される処理手順の一例を説明するためのシーケンス図である。

タッチパネル２０４に表示されている文字列の入力用の画面において、ユーザによる文字列の入力が確定すると（Ｓ６０１）、リッチＵＩアプリＡ２５１は、文字列の入力結果（入力された文字列）をパネルフィルタ部２４に通知する（Ｓ６０２）。パネルフィルタ部２４は、文字列の入力結果を、端末通信部１２３２に送信する（Ｓ６０３）。なお、図１４では、便宜上、コントローラ通信部２２は省略されている。

続いて、端末通信部１２３２は、文字列の入力結果をパネル管理部１２３１に通知する（Ｓ６０４）。文字列の入力結果の通知に応じて、パネル管理部１２３１は、ソフトキーボードの非表示をコントロールサービス１２２に要求する（Ｓ６０５）。その結果、仮想的に生成されていたソフトキーボードは、破棄される。続いて、パネル管理部１２３１は、文字列の入力結果を、ソフトキーボードにおける入力の確定結果として、レガシーアプリＡ１２４１に通知する（Ｓ６０６）。すなわち、パネル管理部１２３１は、レガシーアプリＡ１２４１に対して、操作パネル上のソフトキーボードを介して文字列が入力されたように見せかける。レガシーアプリＡ１２４１は、通知された文字列を、例えば、ジョブの属性値として記憶する。

続いて、リッチＵＩアプリＡ２５１が、画像形成装置１０に保存されているファイルリソース（ファイルに格納されたデータ）を必要とした場合に実行される処理手順の一例について説明する。例えば、従来の操作パネルでは、ファイル名の一覧が表示されていた操作画面において、タッチパネル２０４上では、サムネイル画像の一覧を表示させたい場合等に、リッチＵＩアプリＡ２５１は、ファイルリソースを必要とする。

図１５は、リッチＵＩアプリが画像形成装置に保存されているファイルリソースを必要とした場合に実行される処理手順の一例を説明するためのシーケンス図である。

ステップＳ７０１において、リッチＵＩアプリＡ２５１は、必要とするファイルリソースのファイルパス名を指定して、ファイルリソースの転送をパネルフィルタ部２４に要求する。パネルフィルタ部２４は、当該要求に対する識別情報（以下、「受付ＩＤ」という。）を生成し、当該受付ＩＤを、リッチＵＩアプリＡ２５１に応答する。なお、受付ＩＤは、ファイルリソースの転送要求（Ｓ７０１）に対して、その応答（後述のステップＳ７０８）が、非同期に行われるため、リッチＵＩアプリＡ２５１側で、ステップＳ７０８における応答が、いずれの要求に対応するのかを区別可能とするために、リッチＵＩアプリＡ２５１に通知される。

続いて、パネルフィルタ部２４は、ファイルパス名を指定して、ファイルリソースの転送要求を端末通信部１２３２に送信する（Ｓ７０３）。なお、図１５では、コントローラ通信部２２は、便宜上、省略されている。

続いて、端末通信部１２３２は、転送要求に指定されたファイルパス名に係るファイルリソースの転送の可否を確認する（Ｓ７０４）。例えば、当該ファイルパス名に係るファイルの存否が確認される。ファイルリソースを転送可能であることが確認された場合、端末通信部１２３２は、転送要求に指定されたファイルパス名に係るファイルより、ファイルリソースを読み込む（Ｓ７０５）。続いて、端末通信部１２３２は、ファイルリソースをパネルフィルタ部２４に転送する（Ｓ７０６）。なお、複数のファイルリソースが転送される場合、例えば、ファイルリソースごとに、ファイルパス名が対応付けられて転送が行われてもよい。

パネルフィルタ部２４は、ファイルリソースを受信すると、情報処理端末２０の補助記憶装置２０３にファイルを生成し、当該ファイルにファイルリソースを保存する（Ｓ７０７）。続いて、パネルフィルタ部２４は、受付ＩＤと、ファイルリソースの保存先のファイルのファイルパス名等を含むファイルリソース転送結果を、リッチＵＩアプリＡ２５１に通知する（Ｓ７０８）。

リッチＵＩアプリＡ２５１は、受付ＩＤに基づいて、いずれの要求に対するファイルリソース転送結果であるのかを判定する。その後、リッチＵＩアプリＡ２５１は、通知されたファイルパス名に係るファイルに対するアクセスを行う。

ところで、画像形成装置１０へのユーザのログインやログアウトは、情報処理端末２０を経由せずに行われうる。例えば、ＩＣカードを利用したカード認証の場合、ユーザが所持するＩＣカードが、画像形成装置１０に接続されたカードリーダにセットされることにより、ユーザのログインが行われる。カードリーダへのＩＣカードのセット等は、画像形成装置１０のコントロールサービス１２２によって検知されるため、当該ＩＣカードに基づくログインのための認証処理について、情報処理端末２０が関与する必然性は無い。したがって、当該認証処理は、コントロールサービス１２２によって行われる。また、ユーザのログインは、カードリーダへのＩＣカードのセット状態の解除や、又は情報処理端末２０とは別に、画像形成装置１０に設けられているハードキーの押下等によって実現されうる。これらのイベントについても、画像形成装置１０のコントロールサービス１２２によって検知される。したがって、これらのイベントに応じたログアウト処理も、コントロールサービス１２２によって行われる。

一方、リッチＵＩアプリ２５が、画像形成装置１０の認証状態の変化に応じて振る舞いを変更させたい場合が有る。振る舞いの変更とは、例えば、処理内容の変更や画面若しくは画面の構成要素等の表示内容又は表示態様の変更等である。画像形成装置１０の認証状態の変化とは、例えば、画像形成装置１０に対するユーザのログイン若しくはログアウト、又は認証に関する設定の変更等に応じて発生する事象である。

そこで、次に、リッチＵＩアプリ２５に対して、画像形成装置１０の認証状態を通知するための処理について説明する。以下においては、リッチＵＩアプリＡ２５１が、画像形成装置１０の認証状態に応じて振る舞いを変更する必要の有るリッチＵＩアプリ２５であるとする。この場合、リッチＵＩアプリＡ２５１は、まず、図１６に示される処理を実行する必要が有る。

図１６は、認証リスナーの登録処理の処理手順の一例を説明するためのシーケンス図である。

ステップＳ８０１において、リッチＵＩアプリＡ２５１は、認証リスナーを指定して、認証ラッパー部２６に対して、認証リスナーの登録を要求する。当該要求には、例えば、リッチＵＩアプリＡ２５１に対応するレガシーアプリＡ１２４１のプロダクトＩＤが指定される。認証リスナーとは、画像形成装置１０の認証状態が変化したときの通知先を示す情報であり、例えば、当該通知先となるオブジェクトのアドレス又は関数のアドレス等であてもよい。認証ラッパー部２６は、リッチＵＩアプリＡ２５１から登録が要求された認証リスナーを、当該要求において指定されたプロダクトＩＤに対応付けて、例えば、メモリ２０２に記憶しておく。なお、認証リスナーに対して、プロダクトＩＤが対応付けられるのは、認証状態は、ＳＤＫアプリ１２４ごとに異なる可能性が有るからである。具体的には、画像形成装置１０は、ＳＤＫアプリ１２４ごとに、認証の要否の設定が可能とされている。ＳＤＫアプリ１２４ごとに認証が必要とされる設定が画像形成装置１０に対してなされている場合、或るＳＤＫアプリ１２４に対してユーザはログインしているが、他のＳＤＫアプリ１２４に対して当該ユーザはログインしていないといった状態が発生しうる。すなわち、ＳＤＫアプリ１２４ごとに、認証状態が異なりうるのである。以下、ＳＤＫアプリ１２４ごとの認証を、「アプリ別認証」という。

図１６の処理が実行されることにより、リッチＵＩアプリＡ２５１については、認証状態の変化の通知を受けるための準備は整ったことになる。なお、ステップＳ８０１は、リッチＵＩアプリＡ２５１の任意のタイミングに行われてよい。例えば、リッチＵＩアプリＡ２５１の起動直後に行われてもよいし、所定の処理が実行された場合に行われてもよい。

続いて、図１７は、リッチＵＩアプリに対して画像形成装置の認証状態の変化を通知するための処理手順の一例を説明するためのシーケンス図である。

コントロールサービス１２２は、画像形成装置１０の認証状態の変化を検知すると、当該認証状態の変化を認証管理部１２３３に通知する（Ｓ８１１）。ここで通知される情報（以下、「通知情報」という。）は、例えば、図１８に示されるような構成を有する。

図１８は、認証状態の変化に関する通知情報の構成例を示す図である。図１８では、通知情報の種類ごとに、当該種類に属する通知情報を構成する項目、及び各項目の値の例等が示されている。

ログイン通知は、画像形成装置１０に対して、又は特定のＳＤＫアプリ１２４に対してログインが行われたときに通知される通知情報である。ログイン通知は、プロダクトＩＤ、ユーザ名、ユーザＩＤ、ログイン結果、認証の種類、及び設定中の課金装置種類等の項目を含む。プロダクトＩＤは、ログイン先が特定のＳＤＫアプリ１２４である場合に、当該ＳＤＫアプリ１２４のプロダクトＩＤである。画像形成装置１０へのログインに対するログイン通知の場合、例えば、画像形成装置１０においてインストールされている又は起動されているＳＤＫアプリ１２４ごとに、ログイン通知が生成され、認証管理部１２３３に通知される。ユーザ名は、ログインしたユーザのユーザ名である。ユーザＩＤは、ログインしたユーザの識別情報である。ログイン結果は、ログインの成否を示す情報である。認証の種類は、ログインにおいて行われた認証の種類である。認証の種類としては、例えば、管理者認証、個人認証、アプリ別認証、及びサービスマン認証等が有る。管理者認証は、ユーザが管理者としてログインする場合に実行される認証である。個人認証とは、ユーザが一般ユーザとしてログインする場合に実行される認証である。なお、管理者とは、特別な権限を有しているユーザをいう。例えば、管理者には、一般ユーザに許可されない、特定の操作が許可される。サービスマン認証は、ユーザがサービスマンとしてログインする場合に実行される認証である。サービスマンとは、画像形成装置１０の保守作業を担当する者であり、保守作業のための特別な操作に対する権限を有しているユーザをいう。設定中の課金装置種類は、課金のために利用される装置として設定されている装置である。

ログアウト通知は、画像形成装置１０から、又は特定のＳＤＫアプリ１２４からのログアウトが行われたときに通知される通知情報である。ログアウト通知は、プロダクトＩＤ、認証の種類、設定中の課金装置種類、及びログアウト結果等の項目を含む。プロダクトＩＤは、ログアウト対象が特定のＳＤＫアプリ１２４である場合に、当該ＳＤＫアプリ１２４のプロダクトＩＤである。画像形成装置１０からのログアウトに対するログアウト通知の場合、例えば、画像形成装置１０においてインストールされている又は起動されているＳＤＫアプリ１２４ごとに、ログアウト通知が生成され、認証管理部１２３３に通知される。ログアウト結果は、ログアウトの成否を示す情報である。

認証設定変更通知は、画像形成装置１０の認証に関する設定が変更されたときに通知される通知情報である。認証設定変更通知は、対象項目及び設定中の課金装置種類等の項目を含む。対象項目は、設定変更の対象とされた設定項目の名前である。

認証設定解除通知は、画像形成装置１０の認証に関する設定のうち、設定が解除されたときに通知される通知情報である。認証設定解除通知は、対象項目等を含む。対象項目は、設定が解除された設定項目の名前である。

続いて、認証管理部１２３３は、当該認証状態の変化を示す通知情報を、端末通信部を介してコントローラ通信部２２に送信する（Ｓ８１２）。続いて、コントローラ通信部２２は、当該認証状態の変化を示す通知情報を、認証ラッパー部２６に通知する（Ｓ８１３）。認証ラッパー部２６は、登録された認証リスナーを介して、リッチＵＩアプリＡ２５１に対して通知情報を通知する（Ｓ８１４）。その結果、リッチＵＩアプリＡ２５１は、当該認証状態に応じて、処理内容や画面の表示内容等を変更することができる。なお、通知情報がログイン通知又はログアウト通知の場合、当該ログイン通知のプロダクトＩＤに対応付いている認証リスナーに係るリッチＵＩアプリ２５に対して通知情報が通知される。

なお、認証ラッパー部２６は、各通知情報を、メモリ２０２等に記憶しておき、図１６のステップＳ８０１に応じて、記憶している通知情報のうち、認証リスナーの登録要求元に対応する通知情報を、当該登録要求元に通知するようにしてもよい。そうすることにより、当該登録要求元のリッチＵＩアプリ２５は、認証リスナーの登録に応じて、現在の画像形成装置１０の認証状態を迅速に把握することができる。認証リスナーの登録要求元に対応する通知情報とは、例えば、ログイン通知又はログアウト通知であれば、当該通知情報に含まれているプロダクトＩＤが、当該認証リスナーに対応付いているプロダクトＩＤと一致する通知情報をいう。

なお、認証管理部１２３３は、レガシーアプリＡ１２４１に対しても通知情報を通知する（Ｓ８１５）。その結果、対応関係にあるＳＤＫアプリ１２４とリッチＵＩアプリ２５との間で、画像形成装置１０の認証状態に対する認識を整合させることができる。

その後、リッチＵＩアプリＡ２５１は、画像形成装置１０の認証状態を把握する必要が無くなった場合、図１９に示される処理を実行する。

図１９は、認証リスナーの登録解除処理の処理手順の一例を説明するためのシーケンス図である。

ステップＳ８２１において、リッチＵＩアプリＡ２５１は、ステップＳ８０１において登録した認証リスナーを指定して、認証ラッパー部２６に対して、認証リスナーの登録解除を要求する。認証ラッパー部２６は、登録されている認証リスナーの中で、指定された認証リスナーに一致する認証リスナーの登録を解除する。例えば、該当する認証リスナーがメモリ２０２より削除される。その結果、当該認証リスナーは、ステップＳ８１４における通知先から除外される。すなわち、リッチＵＩアプリＡ２５１は、画像形成装置１０の認証状態の変化の通知先から除外される。

なお、図１９の処理は、例えば、リッチＵＩアプリＡ２５１の終了時等、リッチＵＩアプリＡ２５１の任意のタイミングで実行されてよい。

上述したように、本実施の形態によれば、操作部の表示能力及び操作性を向上させることができる。また、操作部に情報処理端末２０に置き換えることの影響は、ＳＤＫプラットフォーム１２３及びコントロールサービス１２２等において吸収されている。したがって、ＳＤＫアプリ１２４のロジック部分に関して、改変が行われる必要性を低減することができる。

また、本実施の形態によれば、画像形成装置１０におけるユーザの認証状態に応じて、情報処理端末２０の振る舞いを変更することができる。したがって、操作部が、画像形成装置１０からは独立した機器によって実現されることによる、利便性又は操作性の劣化等を抑制することができる。

なお、本実施の形態において、レガシーアプリＡ１２４１は、第一の処理部の一例である。ＳＤＫプラットフォーム１２３は、第一の通信部の一例である。リッチＵＩアプリＡ２５１は、第二の処理部の一例である。コントローラ通信部２２及びパネルフィルタ部２４は、第二の通信部の一例である。コントロールサービス１２２は、検知部の一例である。

以上、本発明の実施例について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

１ 情報処理システム
１０ 画像形成装置
１１ コントローラ
１２ スキャナ
１３ プリンタ
１４ モデム
１５ 端末インタフェース
１６ ネットワークインタフェース
１７ ＳＤカードスロット
２０ 情報処理端末
２１ リッチＵＩＯＳ
２２ コントローラ通信部
２３ アプリ管理部
２４ パネルフィルタ部
２５ リッチＵＩアプリ
２６ 認証ラッパー部
８０ ＳＤカード
１１１ ＣＰＵ
１１２ ＲＡＭ
１１３ ＲＯＭ
１１４ ＨＤＤ
１１５ ＮＶＲＡＭ
１２１ ＯＳ
１２２ コントロールサービス
１２３ ＳＤＫプラットフォーム
１２４ ＳＤＫアプリ
２０１ ＣＰＵ
２０２ メモリ
２０３ 補助記憶装置
２０４ タッチパネル
２０５ 無線通信装置
２０６ 機器インタフェース
２１１ 表示装置
２１２ 入力装置
２５１ リッチＵＩアプリＡ
１２３１ パネル管理部
１２３２ 端末通信部
１２３３ 認証管理部
１２４１ レガシーアプリＡ

特開２００９−２２３５７７号公報

Claims (11)

1. 操作部を有する機器であって、
   前記機器は、
   画面の構成要素の表示を要求する第一の処理部と、
   当該機器におけるユーザの認証状態の変化を検知する検知部と、
   前記要求を受け付け、前記構成要素の識別情報を指定して、当該構成要素の表示要求を前記操作部に送信する、又は前記認証状態の変化を示す通知情報を前記操作部に送信する第一の通信部とを有し、
   前記操作部は、
   前記表示要求又は前記通知情報を受信する第二の通信部と、
   前記第二の通信部によって受信された表示要求に指定された識別情報に係る構成要素を、前記第一の通信部が受け付けた要求に指定された形態と異なる形態で表示させ、前記通知情報に応じて前記構成要素の表示態様を変化させる第二の処理部とを有する機器。
2. 前記第二の処理部は、表示させた構成要素の操作に応じ、当該構成要素の識別情報と前記操作の内容とを含む操作情報を、前記第二の通信部を介して前記第一の通信部に送信し、
   前記第一の通信部は、前記操作情報を前記第一の処理部に通知し、
   前記第一の処理部は、前記操作情報に応じた処理を実行する請求項１記載の機器。
3. 前記第一の処理部は、前記操作情報に応じ、当該操作情報が含む識別情報に係る構成要素の表示状態の変更要求を、前記第一の通信部を介して前記第二の通信部に送信し、
   前記第二の通信部は、前記表示状態の変更要求を、前記第二の処理部に通知し、
   前記第二の処理部は、前記表示状態の変更要求の対象とされた識別情報に係る構成要素の表示状態を変更させる請求項２記載の機器。
4. 前記構成要素は、前記第一の処理部が前記機器に処理を実行させるための表示部品である請求項１乃至３いずれか一項記載の機器。
5. 前記操作部は、前記機器と分離可能であり、
   前記第一の通信部と前記第二の通信部とはネットワークを介して通信する請求項１乃至４いずれか一項記載の機器。
6. 機器の操作部として機能する情報処理端末であって、
   前記機器は、
   画面の構成要素の表示を要求する第一の処理部と、
   当該機器におけるユーザの認証状態の変化を検知する検知部と、
   前記要求を受け付け、前記構成要素の識別情報を指定して、当該構成要素の表示要求を前記情報処理端末に送信する、又は前記認証状態の変化を示す通知情報を前記情報処理端末に送信する第一の通信部とを有し、
   前記情報処理端末は、
   前記表示要求又は前記通知情報を受信する第二の通信部と、
   前記第二の通信部によって受信された表示要求に指定された識別情報に係る構成要素を、前記第一の通信部が受け付けた要求に指定された形態と異なる形態で表示させ、前記通知情報に応じて前記構成要素の表示態様を変化させる第二の処理部とを有する情報処理端末。
7. 機器と、前記機器の操作部として機能する情報処理端末とを含む情報処理システムであって、
   前記機器は、
   画面の構成要素の表示を要求する第一の処理部と、
   当該機器におけるユーザの認証状態の変化を検知する検知部と、
   前記要求を受け付け、前記構成要素の識別情報を指定して、当該構成要素の表示要求を前記情報処理端末に送信する、又は前記認証状態の変化を示す通知情報を前記情報処理端末に送信する第一の通信部とを有し、
   前記情報処理端末は、
   前記表示要求又は前記通知情報を受信する第二の通信部と、
   前記第二の通信部によって受信された表示要求に指定された識別情報に係る構成要素を、前記第一の通信部が受け付けた要求に指定された形態と異なる形態で表示させ、前記通知情報に応じて前記構成要素の表示態様を変化させる第二の処理部とを有する情報処理システム。
8. 操作部を有する機器が、
   画面の構成要素の表示を要求する要求手順と、
   当該機器におけるユーザの認証状態の変化を検知する検知手順と、
   前記要求を受け付け、前記構成要素の識別情報を指定して、当該構成要素の表示要求を前記機器に送信する、又は前記認証状態の変化を示す通知情報を前記操作部に送信する送信手順とを実行し、
   前記操作部は、
   前記表示要求を受信する第二の通信部と、
   前記第二の通信部によって受信された表示要求に指定された識別情報に係る構成要素を、前記送信手順が受け付けた要求に指定された形態と異なる形態で表示させ、前記通知情報に応じて前記構成要素の表示態様を変化させる第二の処理部とを有する表示制御方法。
9. 画面の構成要素の表示を要求する第一の処理部と、
   当該機器におけるユーザの認証状態の変化を検知する検知部と、
   前記要求を受け付け、前記構成要素の識別情報を指定して、当該構成要素の表示要求を情報処理端末に送信する、又は前記認証状態の変化を示す通知情報を前記情報処理端末に送信する第一の通信部とを有する機器の操作部として機能する前記情報処理端末が、
   前記表示要求又は前記通知情報を受信する受信手順と、
   前記受信手順において受信された表示要求に指定された識別情報に係る構成要素を、前記第一の通信部が受け付けた要求に指定された形態と異なる形態で表示させる表示手順と、
   前記通知情報に応じて前記構成要素の表示態様を変化させる変化手順とを実行する表示制御方法。
10. 操作部を有する機器に、
    画面の構成要素の表示を要求する要求手順と、
    当該機器におけるユーザの認証状態の変化を検知する検知手順と、
    前記要求を受け付け、前記構成要素の識別情報を指定して、当該構成要素の表示要求を前記機器に送信する、又は前記認証状態の変化を示す通知情報を前記操作部に送信する送信手順とを実行させ、
    前記操作部は、
    前記表示要求又は前記通知情報を受信する第二の通信部と、
    前記第二の通信部によって受信された表示要求に指定された識別情報に係る構成要素を、第一の通信部が受け付けた要求に指定された形態と異なる形態で表示させ、前記通知情報に応じて前記構成要素の表示態様を変化させる第二の処理部とを有するプログラム。
11. 画面の構成要素の表示を要求する第一の処理部と、
    当該機器におけるユーザの認証状態の変化を検知する検知部と、
    前記要求を受け付け、前記構成要素の識別情報を指定して、当該構成要素の表示要求を情報処理端末に送信する、又は前記認証状態の変化を示す通知情報を前記情報処理端末に送信する第一の通信部とを有する機器の操作部として機能する前記情報処理端末に、
    前記表示要求又は前記通知情報を受信する受信手順と、
    前記受信手順において受信された表示要求に指定された識別情報に係る構成要素を、前記第一の通信部が受け付けた要求に指定された形態と異なる形態表示させる表示手順と、
    前記通知情報に応じて前記構成要素の表示態様を変化させる変化手順とを実行させるプログラム。

Images