JP2011065594A - 情報処理装置、その情報処理装置におけるユーザインタフェース表示制御方法、及び、プログラム - Google Patents

Abstract

【課題】情報処理装置が自身の装置情報を取得して、その装置情報に基づいた画面を表示するためのファイルをサーバに要求する情報処理装置を提供する。
【解決手段】情報処理装置の装置情報を取得し、取得された装置情報により、情報処理装置の機能を用いることができるか否かを判定し、情報処理装置の機能を用いることができると判定された場合に、情報処理装置の機能を用いた処理の実行の指示画面を表示するためのファイルをサーバに要求する。一方、情報処理装置の機能を用いることができないと判定された場合に、警告画面を表示するためのファイルをサーバに要求する。
【選択図】図８

Description

本発明は、ユーザインタフェースの表示を制御する情報処理装置、ユーザインタフェース表示制御方法、及び、プログラムに関する。

ネットワーク上のＷｅｂサーバと接続されたＰＣ等の情報処理装置において、Ｗｅｂサーバにより提供された操作画面をＷｅｂブラウザ上に表示することが一般的に広く知られている。そのような構成においては、まず、情報処理装置のＷｅｂブラウザがＷｅｂサーバに対して操作画面を要求する。次に、Ｗｅｂサーバ上のＷｅｂアプリケーションが情報処理装置からの要求に応えて、Ｗｅｂブラウザに操作画面を表示させるためのＨＴＭＬファイルを情報処理装置に送信する。情報処理装置のＷｅｂブラウザは、受信したＨＴＭＬファイルを解析して、ＨＴＭＬファイルの記述に基づいた操作画面を表示する。更に、Ｗｅｂブラウザに表示された操作画面においてユーザが指示を入力すると、情報処理装置のＷｅｂブラウザは、その指示をＷｅｂサーバに対して通知する。その通知を受けたＷｅｂサーバ上のＷｅｂアプリケーションは、入力された指示に従って処理を実行する。

近年、情報処理装置としての、スキャナやプリンタを備えたＭＦＰ（Multi Function Peripheral：多機能周辺装置）にも、Ｗｅｂブラウザを備えるようになってきた。ＭＦＰは、上記の手順でＷｅｂサーバにより提供される操作画面をＷｅｂブラウザ上に表示し、ユーザからの各種指示を受け付けることができる。また、Ｗｅｂサーバは、ＨＴＭＬファイルに組み込んだＪａｖａ（登録商標）Ｓｃｒｉｐｔや、ＨＴＭＬファイルに付随させたメタデータによって、ＭＦＰへの動作指示を表現したり、ＭＦＰから情報を取得して画面更新をハンドリングしたりすることもできる。

特許文献１によれば、通知サーバが所定のイベントを検出すると、そのイベントに対応づけられたネットワーク上のアドレスをＭＦＰに通知し、ＭＦＰがそのアドレスから画面情報を取得する。これにより、個々のイベントに対応した多様な画面情報をＭＦＰに提供することができると記載されている。

特開２００７−０８８６６５号公報

Ｗｅｂサーバと接続されたＭＦＰの操作画面は、Ｗｅｂサーバ上のＷｅｂアプリケーションによって提供される。従って、Ｗｅｂサーバは、適切な画面をＭＦＰに通知すべきである。

しかしながら、例えば、ユーザがログアウトしているにも関わらず、そのログアウト状態がＷｅｂアプリケーションに伝わっていないと、ログイン状態であると誤認識した状態のまま、操作画面上での画面遷移が行われてしまう。また、スキャナでエラーが発生していたとしても、そのスキャナ状態がＷｅｂアプリケーションに伝わっていないと、画面遷移を経た後、ＭＦＰへのジョブ投入を行う段階で初めてジョブが実行できないことが判明する、というような課題も生じてしまう。

たとえ、これを回避するために、Ｗｅｂアプリケーション側でＭＦＰの装置情報を常に監視して把握する構成にしたとしても、完全なリアルタイムを実現するためにネットワークのトラフィック的な問題や相互の処理負荷の問題を引き起こしてしまう。特許文献１では、イベントに対応した画面を、ＭＦＰの状態の変化に関わらずに一律表示するので、ＭＦＰの状態の変化に応じて適切な画面表示を行うとはいえない。

上記の点に鑑み、本発明は、情報処理装置が自身の装置情報を取得して、その装置情報に基づいた画面を表示するためのファイルをサーバに要求する情報処理装置、ユーザインタフェース表示制御方法、及び、プログラムを提供することを目的とする。

上記課題を解決するため、本発明に係る情報処理装置は、ユーザインタフェースを表示するためのファイルを提供するサーバに接続され、前記ファイルに基づいてユーザインタフェースを表示する情報処理装置であって、前記情報処理装置の装置情報を取得する取得手段と、前記取得手段により取得された装置情報により、前記情報処理装置の機能を用いることができるか否かを判定する判定手段と、前記情報処理装置の機能を用いることができると判定された場合に、前記情報処理装置の機能を用いた処理の実行の指示画面を表示するためのファイルを前記サーバに要求する第１の要求手段と、前記情報処理装置の機能を用いることができないと判定された場合に、警告画面を表示するためのファイルを前記サーバに要求する第２の要求手段とを備える。

本発明によれば、情報処理装置が自身の装置情報を取得して、その装置情報に基づいた画面を表示するためのファイルをサーバに要求するので、情報処理装置の状態の変化に基づいた適切な画面を表示することができる。

システムの全体構成を示す図である。 ＭＦＰのブロック構成を示す図である。 Ｗｅｂサーバのブロック構成を示す図である。 本システムにおけるソフトウェア構成を説明するための図である。 操作画面を要求する処理の手順を示すフローチャートである。 Ｗｅｂブラウザで表示される画面の一例を示す図である。 画面情報を示すＨＴＭＬファイルの一例を示す図である。 画面情報を要求する処理の手順を示すフローチャートである。 Ｗｅｂサーバでの処理の手順を示すフローチャートである。 メンテナンス画面の一例を示す図である。 装置情報を常に監視する場合の処理の手順を示すフローチャートである。 画面情報を要求する他の処理の手順を示すフローチャートである。

以下に、本発明を実施するための形態について、図面を参照しながら詳しく説明する。なお、同一の構成要素には同一の参照番号を付して、説明を省略する。

［実施例１］
第１の実施例では、情報処理装置の一例であるＭＦＰ１０１が画面遷移のタイミングで自身の装置情報を取得し、その結果に基づき、適切な画面を表示する場合について説明する。特に、ユーザアクションが発生したときに、ＭＦＰ１０１が自身の装置情報を取得し、その内容に応じて表示内容を変更する場合について説明する。ここで、ユーザアクションとは、例えば、ユーザがＷｅｂブラウザ４４０のボタン押下を行うことにより、画面遷移が発生することを示す。

図１は、本実施例におけるユーザインタフェース表示制御を行うシステムの全体構成を示す図である。ＬＡＮ１０４には、情報処理装置としてのＭＦＰ１０１、ＬＤＡＰ（Lightweight Directory Access Protocol）サーバ１０２、Ｗｅｂサーバ１０３が相互に通信可能に接続されている。また、ＬＡＮ１０４上には不図示のＦＴＰ（File Transfer Protocol）サーバも接続されており、ＭＦＰ１０１からＦＴＰサーバに対して画像データをＦＴＰ送信することができる。

図２は、ＭＦＰ１０１のブロック構成を示す図である。ＣＰＵ２１１を含む制御部２１０は、ＭＦＰ１０１全体の動作を制御する。ＣＰＵ２１１は、ＲＯＭ２１２に記憶された制御プログラムを読み出して読取制御や送信制御などの各種制御処理を実行する。ＲＡＭ２１３は、ＣＰＵ２１１の主メモリ、ワークエリア等の一時的な記憶領域として用いられる。ＨＤＤ２１４は、画像データや各種プログラム等を記憶する。操作部Ｉ／Ｆ２１５は、操作部２１９と制御部２１０とを接続する。操作部２１９には、タッチパネル機能を有する液晶表示部やキーボード等が構成されている。また、ＭＦＰ１０１には、後述するＷｅｂブラウザ機能が備えられている。ＭＦＰ１０１のＷｅｂブラウザは、Ｗｅｂサーバ１０３から受信したＨＴＭＬファイルを解析し、ＨＴＭＬファイルの記述に基づく操作画面（ユーザインタフェース画面）を操作部２１９上に表示する。プリンタＩ／Ｆ２１６は、プリンタ２２０と制御部２１０とを接続する。プリンタ２２０で印刷すべき画像データは、プリンタＩ／Ｆ２１６を介して制御部２１０からプリンタ２２０に転送され、プリンタ２２０において記録媒体上に印刷される。スキャナＩ／Ｆ２１７は、スキャナ２２１と制御部２１０とを接続する。スキャナ２２１は、原稿上の画像を読み取って画像データを生成し、スキャナＩ／Ｆ２１７を介して制御部２１０に入力する。ネットワークＩ／Ｆ２１８は、制御部２１０をＬＡＮ１０４に接続する。ネットワークＩ／Ｆ２１８は、ＬＡＮ１０４上の他の装置（例えば、ＬＤＡＰサーバ１０２やＷｅｂサーバ１０３）に画像データや情報を送信したり、ＬＡＮ１０４上の他の装置から各種情報を受信する。

図３は、Ｗｅｂサーバ１０３のブロック構成を示す図である。ＣＰＵ３１１を含む制御部３１０は、Ｗｅｂサーバ１０３全体の動作を制御する。ＣＰＵ３１１は、ＲＯＭ３１２に記憶された制御プログラムを読み出して各種制御処理を実行する。ＲＡＭ３１３は、ＣＰＵ３１１の主メモリ、ワークエリア等の一時的な記憶領域として用いられる。ＨＤＤ３１４は、画像データや各種プログラム、或いは後述する各種情報テーブルを記憶する。ネットワークＩ／Ｆ３１５は、制御部３１０をＬＡＮ１０４に接続する。ネットワークＩ／Ｆ３１５は、ＬＡＮ１０４上の他の外部装置との間で各種情報を送受信する。

図４は、本システムにおけるソフトウェア構成を説明するための図である。図４に示す各機能部は、ＭＦＰ１０１、ＬＤＡＰサーバ１０２、Ｗｅｂサーバ１０３のそれぞれに備えられているＣＰＵが制御プログラムを実行することにより実現される。

ＭＦＰ１０１は、ログインアプリケーション４３０、Ｗｅｂブラウザ４４０、サービスプロバイダ４５０、ログ記録部４６０、ネイティブモジュール４９０を含む。ログインアプリケーション４３０は、画面表示部４３１と認証処理部４３２を含む。画面表示部４３１は、認証処理部４３２が実行する認証処理に必要な認証情報をユーザに入力させるための認証画面を操作部２１９に表示する。なお、この認証画面はＷｅｂサーバ１０３により提供されるものではなく、ログインアプリケーション４３０がＭＦＰ１０１内に保持している情報が読み出されて表示される。画面表示部４３１により表示された認証画面を介して認証情報が入力されると、認証処理部４３２が、入力された認証情報を用いてユーザ認証処理を行う。

ＬＤＡＰサーバ１０２は、認証情報管理部４７０と認証情報記憶部４８０を含む。認証情報記憶部４８０には、ＭＦＰ１０１の使用が許可されたユーザに対応する認証情報が予め記憶されている。認証情報管理部４７０は、認証情報記憶部４８０に記憶されている認証情報を管理する。認証処理部４３２により認証処理が行われる場合には、画面表示部４３１により表示される認証画面を介して入力された認証情報と、認証情報記憶部４８０に記憶されている認証情報とを照合する。そして、その照合結果に応じて、ユーザによるＭＦＰ１０１の使用が許可される。

Ｗｅｂブラウザ４４０は、通信部４４１、解析部４４２、画面表示部４４３とを含む。通信部４４１は、ＨＴＴＰプロトコルに従ってＷｅｂアプリケーション４１０のプレゼンテーション部４１１と通信する。例えば、通信部４４１は、Ｗｅｂブラウザ４４０で表示する操作画面をＷｅｂアプリケーション４１０に対して要求したり、Ｗｅｂブラウザ４４０で表示された操作画面を介して入力されたユーザからの指示をＷｅｂアプリケーション４１０に通知する。解析部４４２は、Ｗｅｂアプリケーション４１０から受信したＨＴＭＬファイルを解析する。このＨＴＭＬファイルには、Ｗｅｂブラウザに表示すべき操作画面の内容が記述されている。また、解析部４４２は、ＨＴＭＬファイルに含まれるＪａｖａ（登録商標）Ｓｃｒｉｐｔや、ＨＴＭＬファイルに付随したメタデータ（例えば、添付したＸＭＬファイル）の解釈も行う。画面表示部４４３は、解析部４４２による解析の結果に基づいて、操作部２１９上に操作画面を表示する。

ネイティブモジュール４９０は、プリンタ制御部４９１、スキャナ制御部４９２、ネットワーク制御部４９３を含む。プリンタ制御部４９１は、プリンタＩ／Ｆ２１６を介してプリンタ２２０の情報を取得する。スキャナ制御部４９２は、スキャナＩ／Ｆ２１７を介してスキャナ２２１の情報を取得する。ネットワーク制御部４９３は、ネットワークＩ／Ｆ２１８を介してＬＡＮ１０４の状態を取得する。Ｗｅｂブラウザ４４０の解析部４４２は、ＨＴＭＬファイルに含まれるＪａｖａ（登録商標）Ｓｃｒｉｐｔや付随したメタデータの指示により、このネイティブモジュール４９０に対してＭＦＰ１０１が正常に動作する状態なのかを問い合わせる。同様に、解析部４４２は、ログインアプリケーション４３０に対して、ユーザのログイン／ログアウト状態を問い合わせる。

Ｗｅｂサーバ１０３は、Ｗｅｂアプリケーション４１０とログ記録部４２０を含む。Ｗｅｂアプリケーション４１０は、プレゼンテーション部４１１、ロジック部４１２、認証処理部４１３を含む。プレゼンテーション部４１１は、ＭＦＰ１０１におけるＷｅｂブラウザ４４０の通信部４４１と通信し、ＭＦＰ１０１からの要求に応えてＭＦＰ１０１のＷｅｂブラウザ４４０で表示すべき操作画面をＭＦＰ１０１に送信する。また、ＭＦＰ１０１のＷｅｂブラウザ４４０に表示された操作画面を介して入力されたユーザからの指示をＭＦＰ１０１から受信する。このＭＦＰ１０１のＷｅｂブラウザ４４０からの要求には、ログイン／ログアウト情報等のユーザ情報も含まれる。

認証処理部４１３は、プレゼンテーション部４１１からの指示に従い、プレゼンテーション部４１１が受信したユーザ情報と同等の情報（例えば、ログイン／ログアウト情報）を記憶する。ロジック部４１２は、ＭＦＰ１０１に対して処理の実行を依頼する場合には、ＭＦＰ１０１のサービスプロバイダ４５０内の通信部４５１と通信する。例えば、ＭＦＰ１０１のプリンタ２２０による印刷処理の実行や、スキャナ２２１による読取処理の実行、或いは、ネットワークＩ／Ｆ２１８を介した送信処理の実行を依頼する。また、その処理結果をロジック部４１２において受信する。ログ記録部４２０は、ＭＦＰ１０１により実行された処理の結果を記録する。ロジック部４１２が処理結果を受け取ったタイミングにおいて、処理結果がログ記録部４２０に書き込まれる。なお、ログ記録部４２０には、Ｗｅｂサーバ１０３で更新されたユーザ情報（例えば、ログイン／ログアウト情報）の更新経過も記録される。これは、認証処理部４１３からの指示に従って書き込まれる。

サービスプロバイダ４５０は、通信部４５１、ジョブ生成部４５２を含む。通信部４５１は、Ｗｅｂアプリケーション４１０内のロジック部４１２からの処理依頼を受け付ける。Ｗｅｂアプリケーション４１０から処理の実行を依頼された場合に、ジョブ生成部４５２は、依頼された処理を実行するためのジョブを生成して実行する。ジョブを実行した結果は、ログ記録部４６０に記録される。なお、ログ記録部４６０には、ログインアプリケーション４３０により実行される認証処理の結果や、Ｗｅｂサーバ１０３との通信履歴なども記録される。図４において点線部の内部サーバ４９５については、第２の実施例において後述する。

図５は、ＭＦＰ１０１がユーザ認証の処理を行うとともに、この認証に用いた認証情報をＷｅｂサーバ１０３に送信することにより、自装置のＷｅｂブラウザで表示すべき操作画面を要求する処理の手順を示すフローチャートである。図５のフローチャートに示す各動作は、ＭＦＰ１０１のＣＰＵ２１１が制御プログラムを実行することにより実現される。なお、Ｓ５０１〜Ｓ５０６はログインアプリケーション４３０により実行され、Ｓ５０７〜Ｓ５１２はＷｅｂブラウザ４４０により実行される。

Ｓ５０１において、画面表示部４３１が操作部２１９に認証画面を表示する。図６の（ａ）は、Ｓ５０１で表示される認証画面の一例を示す図である。以下、図６の（ａ）、（ｂ）、（ｃ）、（ｄ）は、同様に操作部２１９に表示される。ＭＦＰ１０１は、図６の（ａ）に示す認証画面を介して、ユーザからのユーザＩＤ及びパスワード入力を検知する。

Ｓ５０２において、画面表示部４３１がユーザから認証情報が入力されたか否かを判定する。例えば、図６の（ａ）に示す認証画面のＯＫボタン６０１が押下されたか否かによって判定される。ここで、認証情報が入力されたと判定した場合に、Ｓ５０３に進み、認証情報が入力されたと判定されるまで、Ｓ５０２の処理を繰り返す。

Ｓ５０３では、入力されたユーザＩＤ及びパスワードを用いて、認証処理部４３２が認証処理を行う。Ｓ５０４において、認証処理部４３２は、ＬＤＡＰサーバ１０２と通信し、入力されたユーザＩＤ及びパスワードを認証情報記憶部４８０に予め記憶されている情報と照合する。認証処理の結果、ユーザが正常に認証された場合には、Ｓ５０５に進み、認証されなかった場合には、Ｓ５０２に戻り、認証情報入力を再度待ち受ける。Ｓ５０５において、認証処理部４３２が、認証されたユーザに対応するログインコンテキストを生成する。ログインコンテキストとは認証されたユーザを示す情報であって、図６の（ａ）に示す認証画面を介して入力されたユーザＩＤを含む。Ｓ５０６では、認証処理部４３２が、ユーザ認証が正常に終了してユーザがログインしたこと（ログインイベント）をＷｅｂブラウザ４４０に対して通知する。

Ｓ５０７において、Ｗｅｂブラウザ４４０における解析部４４２は、ログインアプリケーション４３０により生成されたログインコンテキストを取得する。Ｓ５０８において、解析部４４２は、取得したログインコンテキストの中から、図６の（ａ）に示す認証画面でユーザが入力したユーザＩＤを抽出する。Ｓ５０９において、解析部４４２は、ＭＦＰ１０１のＷｅｂブラウザに表示する操作画面の１つであって、ユーザが処理の実行を指示するためのメニュー画面を送信することをＷｅｂサーバ１０３に対して要求するためのメニュー画面送信要求を生成する。このメニュー画面送信要求には、Ｓ５０８で抽出されたユーザＩＤが含まれる。Ｓ５１０において、通信部４４１が、解析部４４２で生成したメニュー画面送信要求をＷｅｂサーバ１０３に対して送信する。

Ｓ５１１において、通信部４４１は、Ｓ５１０で送信したメニュー画面送信要求に応じてＷｅｂサーバ１０３からメニュー画面が送信されてきたか否かを判定する。例えば、メニュー画面をＷｅｂブラウザに表示するための画面情報として、ＨＴＭＬファイルがＷｅｂサーバ１０３から送信される。ここで、Ｗｅｂサーバ１０３からメニュー画面を受信したと判定された場合には、Ｓ５１２に進み、メニュー画面を受信していないと判定された場合には、メニュー画面を受信するまでＳ５１１を繰り返す。Ｓ５１２において、画面表示部４４３は、受信したＨＴＭＬファイルの記述に従って、図６の（ｂ）に示すようなメニュー画面を表示する。

図６の（ｂ）は、Ｓ５１２で表示されるメニュー画面の一例を示す図である。図６の（ｂ）には、ＭＦＰ１０１の機能の指定を受付けるためのメニューが表示されている。例えば、本実施例では、「スキャンしてＦＴＰサーバに送信する」機能６０２、「スキャンしてＦａｘ送信する」機能６０３、「Ｐｒｉｎｔする」機能６０４が選択ボタンとして表示されている。これらの選択ボタンの押下をＷｅｂブラウザ４４０が検知すると、図６の（ｃ）に示すような実行指示画面に遷移する。画面遷移は、図６の（ａ）におけるＳ５０９〜Ｓ５１２に示す処理と同様に行われる。但し、ＯＫボタン６０２の押下を検知した場合の処理は、前述の処理とは異なる。これは図７において説明する。

図６の（ｃ）は、選択した機能を実行するための画面の一例を示す図である。図６の（ｃ）は、ＭＦＰ１０１のスキャナ２２１を用いて原稿上の画像を読み取って画像データを生成し、生成した画像データをＬＡＮ１０４上のＦＴＰサーバに送信することを指示するための画面である。図６の（ｃ）は、画像データをＰＤＦフォーマットで生成し、「ｔｅｓｔ．ｐｄｆ」というファイル名を付与することが設定された状態の画面である。ここで、ＯＫボタン６０６の押下を検知すると実際に処理が実行され、完了すると図６の（ｄ）に示すような実行結果表示画面に遷移する。画面遷移は、図６の（ａ）におけるＳ５０９〜Ｓ５１２に示す処理と同様に行われる。

図６の（ｄ）は、実行結果を表示するための画面の一例を説明する図である。図６の（ｄ）では、実行結果がユーザに提示されている。ここで、ＯＫボタン６０６の押下を検知すると、図６の（ｂ）の画面に戻る。画面遷移は、図６の（ａ）におけるＳ５０９〜Ｓ５１２に示す処理と同様に行われる。

図７の（ａ）、（ｂ）は、図６の（ｂ）の実行指示画面の画面情報を示すＨＴＭＬファイルの例の一部を示した図である。便宜上、図７の（ａ）、（ｂ）としているが実際にはこのＨＴＭＬファイルは１つである。このＨＴＭＬファイルは、Ｗｅｂサーバ１０３から送られ、ＭＦＰ１０１に備えられているＣＰＵ２１１が制御プログラムを実行することにより解釈される。以下は、ユーザアクションに従って、ＭＦＰ１０１の装置情報を取得する部分に関する説明である。

図７の（ａ）、（ｂ）におけるＨＴＭＬファイルのＪａｖａ（登録商標）Ｓｃｒｉｐｔの表現として、７０１部分は、「スキャンしてＦＴＰサーバに送信する」ボタン６０２が選択されてＷｅｂブラウザ４４０がそのボタン押下を検知した場合に処理される内容である。Ｗｅｂブラウザ４４０が押下を検知すると、ｇｅｔＳｃａｎＴｏＦＴＰＤｅｖＳｔａｔｅという関数７０３を呼び出す。ｇｅｔＳｃａｎＴｏＦＴＰＤｅｖＳｔａｔｅ関数７０３では、ログイン／ログアウト情報と、「スキャンしてＦＴＰサーバに送信する」機能を実行するために必要なＭＦＰ１０１の装置情報を取得する。

まず、ログイン／ログアウト情報を取得するため、７０４部分に示すように、ｇｅｔＬｏｇｏｕｔＩｎｆｏ関数を呼び出す。ｇｅｔＬｏｇｏｕｔＩｎｆｏ関数は、Ｗｅｂブラウザ４４０が提供する関数である。Ｗｅｂブラウザ４４０の内部では、ログアウト状態であると判定した場合に、図６（ａ）の認証画面を呼び出す。具体的には、Ｗｅｂブラウザ４４０の解析部４４２がログインアプリケーション４３０の認証処理部４３２を呼び出す。そして、図５のＳ５０１で表示したのと同様に、認証処理部４３２は、画面表示部４３１に対して操作部２１９への認証画面の表示依頼を行い、画面表示部４３１がその画面を表示する。ここで、ｇｅｔＳｃａｎＴｏＦＴＰＤｅｖＳｔａｔｅ関数７０３がｆａｌｓｅで終了し、ｕｒｌ１へのＰＯＳＴリクエストは破棄される。

また、ログアウトしていればＭＦＰ１０１の装置情報を取得する必要はないので、後述の処理（スキャナ２２１、ネットワーク（ＬＡＮ１０４）の情報取得）は省略される。７０４部分の処理でログイン状態であった場合（ｌｏｇｏｕｔがｔｒｕｅでなかった場合）には、ＭＦＰ１０１の装置情報を取得する。ここでは、「スキャンしてＦＴＰサーバに送信する」機能を実行するために必要なＭＦＰ１０１の装置情報であるスキャナ２２１とネットワーク（ＬＡＮ１０４）の情報を取得する。このために、７０５部分に示すように、ｇｅｔＳｃａｎＴｏＦＴＰＩｎｆｏ関数を呼び出す。ｇｅｔＳｃａｎＴｏＦＴＰＩｎｆｏ関数も、Ｗｅｂブラウザ４４０が提供する関数である。Ｗｅｂブラウザ４４０の内部では、ＭＦＰ１０１の装置情報が異常であると判定した場合には、図１０のメンテナンス画面を呼び出す。具体的には、Ｗｅｂブラウザ４４０の解析部４４２が、通信部４４１を介してＷｅｂサーバ１０３のＷｅｂアプリケーション４１０を呼び出して、図１０のメンテナンス画面情報を取得して表示する。ここで、ｇｅｔＳｃａｎＴｏＦＴＰＤｅｖＳｔａｔｅ関数７０３がｆａｌｓｅで終了し、ｕｒｌ１へのＰＯＳＴリクエストは破棄される。

７０２部分は、「ＳｃａｎしてＦａｘ送信する」ボタン６０３、「Ｐｒｉｎｔする」ボタン６０４の押下をＷｅｂブラウザ４４０が検知した場合に処理される内容である。７０１部分と同様に、Ｗｅｂブラウザ４４０がボタンの押下を検知すると、それぞれ、ｇｅｔＳｃａｎＴｏＦａｘＤｅｖＳｔａｔｅ、ｇｅｔＰｒｉｎｔＤｅｖＳｔａｔｅという関数７０６を呼び出す。その後、７０１部分の処理と同様に、図６の（ａ）の認証画面または図１０のメンテナンス画面を取得する。

本実施例では、ＨＴＭＬ＋Ｊａｖａ（登録商標）Ｓｃｒｉｐｔによる実現を例に出したが、その実現形態は他の方法であっても良い。例えばＨＴＭＬ上で送信指示（ｓｕｂｍｉｔ処理）を行わず、すべてＪａｖａ（登録商標）Ｓｃｒｉｐｔで行う（Ｊａｖａ（登録商標）Ｓｃｒｉｐｔ内にｓｕｂｍｉｔ処理を記載する）方法でも良い。ここでの詳細説明は、割愛する。

また、図７の（ａ）、（ｂ）において、「スキャンしてＦＴＰサーバに送信する」機能や「Ｐｒｉｎｔする」機能のためにも、必要なＭＦＰ１０１の装置情報を取得する。これは、スキャン（原稿読み取り）を実行する場合に、スキャナ２２１やネットワーク（ＬＡＮ１０４）、プリンタ２２０の正常動作が必要であるので、この処理が必要となる。逆に、他の画面においては、このスキャナ２２１やネットワーク（ＬＡＮ１０４）、プリンタ２２０の状態取得をする必要がない。よって、図６の（ｂ）のメニュー画面の画面情報にのみ、上記で説明した内容が含まれる。なお、ログアウト情報については、認証実施後のすべての画面遷移のタイミングで、その情報が取得される。図７の（ａ）、（ｂ）と同様に、ＭＦＰ１０１の装置情報を取得する方法となるが詳細は割愛する。

図８は、ＭＦＰ１０１において、ユーザアクションを検知した際の処理の手順を示すフローチャートである。図８のフローチャートに示す各動作は、ＭＦＰ１０１のＣＰＵ２１１が制御プログラムを実行することにより実現される。図８の点線におけるＳ１２１８は、第２の実施例において後述する。

Ｓ８０１において、Ｗｅｂブラウザ４４０がユーザアクションを検知したか否かを判定する。また、ユーザアクションを検知するまで、Ｗｅｂブラウザ４４０ではＳ８０１を繰り返す。Ｓ８０１でユーザアクションを検知すると、Ｓ８０２に進む。Ｓ８０２において、Ｗｅｂブラウザ４４０は、ユーザアクションが「スキャンしてＦＴＰサーバに送信する」ボタン６０２の押下であるか否かを判定する。ここで、「スキャンしてＦＴＰサーバに送信する」ボタン６０２の押下である場合には、Ｓ８０３に進む。Ｓ８０３において、図７の（ｂ）の７０４で説明したようにＪａｖａ（登録商標）Ｓｃｒｉｐｔに従って、Ｗｅｂブラウザ４４０がログインアプリケーション４３０に問い合わせを行い、ログイン／ログアウト情報を取得する。その後、Ｓ８０４に進み、Ｗｅｂブラウザ４４０は、ログイン状態か否かを判定する。ここで、ログアウト状態の場合には、Ｓ８１７に進む。一方、ログイン状態の場合には、Ｓ８０５に進む。Ｓ８０４は、認証判定の処理の一例である。

Ｓ８０５において、図７の（ｂ）の７０５で説明したようにＪａｖａ（登録商標）Ｓｃｒｉｐｔに従って、Ｗｅｂブラウザ４４０は、ネイティブモジュール４９０に問い合わせを行い、スキャナ２２１、ネットワーク（ＬＡＮ１０４）の情報を取得する。その後、Ｓ８０６に進み、Ｗｅｂブラウザ４４０は、スキャナ２２１、ネットワーク（ＬＡＮ１０４）の情報が正常か否かを判定する。ここで、正常でないと判定された場合には、Ｓ８１８に進む。一方、正常と判定された場合には、Ｓ８０７に進む。Ｓ８０７において、Ｗｅｂブラウザ４４０は、「スキャンしてＦＴＰサーバに送信する」画面のＵＲＬを設定してＷｅｂサーバ１０３にＨＴＴＰリクエストを送信する。Ｓ８０７は、第１の要求の処理の一例である。

再び、Ｓ８０２を参照する。Ｓ８０２で「スキャンしてＦＴＰサーバに送信する」ボタン６０２の押下でないと判定された場合には、Ｓ８０８に進む。Ｓ８０８において、Ｗｅｂブラウザ４４０が「Ｐｒｉｎｔする」ボタン６０４の押下の判断を行う。ここで「Ｐｒｉｎｔする」ボタン６０４の押下と判定された場合には、Ｓ８０９に進む。Ｓ８０９において、Ｗｅｂブラウザ４４０は、ログインアプリケーション４３０に問い合わせを行い、ログイン／ログアウト情報を取得する。その後、Ｓ８１０に進み、Ｗｅｂブラウザ４４０は、ログイン状態か否かを判定する。ここで、ログアウト状態の場合には、Ｓ８１７に進む。一方、ログイン状態の場合には、Ｓ８１１に進む。

Ｓ８１１において、Ｗｅｂブラウザ４４０は、ネイティブモジュール４９０に問い合わせを行い、プリンタ２２０の情報を取得する。その後、Ｓ８１２に進み、Ｗｅｂブラウザ４４０は、プリンタ２２０の情報が正常か否かを判定する。ここで、正常でないと判定された場合には、Ｓ８１８に進む。一方、正常と判定された場合には、Ｓ８１３に進む。Ｓ８１３において、Ｗｅｂブラウザ４４０は、「Ｐｒｉｎｔする」画面のＵＲＬを設定してＷｅｂサーバ１０３にＨＴＴＰリクエストを送信する。

なお、本フローチャートでは省略したが、Ｗｅｂブラウザ４４０が「スキャンしてＦａｘ送信する」機能ボタン６０３の押下の検知をした場合の処理は、Ｓ８０２〜Ｓ８０７やＳ８０８〜Ｓ８１３と同様である。

再び、Ｓ８０８を参照する。Ｓ８０８において「Ｐｒｉｎｔする」ボタン６０４の押下でないと判定された場合には、Ｓ８１４に進む。Ｓ８１４において、Ｗｅｂブラウザ４４０は、ログインアプリケーション４３０に問い合わせを行い、ログイン／ログアウト情報を取得する。この処理が行われる画面は、認証後、Ｗｅｂブラウザ４４０が遷移要求を検知した画面が該当する。遷移要求を検知した画面とは、例えば、図６の（ｄ）の実行結果表示画面などを指す。但し、図６の（ｂ）のメニュー画面は、ＭＦＰ１０１の装置情報を取得するＳ８０２、Ｓ８０８で分岐するために、遷移要求を検知した画面には含まれない。その後、Ｓ８１５に進み、Ｗｅｂブラウザ４４０は、ログイン状態であるか否かを判定する。ここで、ログアウト状態であると判定された場合には、Ｓ８１７に進む。一方、ログイン状態であると判定された場合には、Ｓ８１６に進む。Ｓ８１６において、Ｗｅｂブラウザ４４０は、遷移を検知した画面のＵＲＬを設定して、Ｗｅｂサーバ１０３にＨＴＴＰリクエストを送信する。

Ｓ８１７は、Ｓ８０４、Ｓ８１０、Ｓ８１５において、Ｗｅｂブラウザ４４０がログアウト状態と判定した場合に行われる処理である。Ｓ８１７では、Ｗｅｂブラウザ４４０はログインアプリケーション４３０を呼び出し、ログインアプリケーション４３０が図６の（ａ）の認証画面を表示する。これは、「スキャンしてＦＴＰサーバに送信する」の実行指示画面である図６の（ｃ）への遷移依頼にも関わらず、その遷移は行わずに、認証画面である図６（ａ）に遷移することになる。つまり、この時点では、実行指示画面である図６の（ｃ）の表示よりも、認証画面である図６の（ａ）の方が適切な画面表示であるということを示す。Ｓ８１７は、第３の要求の処理の一例である。

Ｓ８１８は、Ｓ８０６、Ｓ８１２において、Ｗｅｂブラウザ４４０がＭＦＰ１０１の装置情報に異常ありと判定した場合に行われる処理である。Ｓ８１８では、Ｗｅｂブラウザ４４０が、メンテナンス画面（警告画面）である図１０（後述）のＵＲＬを設定してＷｅｂサーバ１０３にＨＴＴＰリクエストを送信して受信した画面を表示する。これは、例えば「スキャンしてＦＴＰサーバに送信する」の実行指示画面である図６の（ｃ）への遷移依頼にも関わらず、その遷移は行わずに、メンテナンス画面である図１０に遷移することになる。つまり、この時点では、ＭＦＰ１０１に異常があるため、実行指示画面である図６の（ｃ）の表示よりも、メンテナンス画面である図１０の方が適切な画面表示であるということを示す。Ｓ８１８は、第２の要求の処理の一例である。

図９は、Ｗｅｂサーバ１０３において、ＭＦＰ１０１からのＨＴＴＰリクエストを受信した際の動作について説明したフローチャートである。図９のフローチャートに示す各動作は、Ｗｅｂサーバ１０３のＣＰＵ３１１が制御プログラムを実行することにより実現される。

Ｓ９０１において、Ｗｅｂサーバ１０３のＷｅｂアプリケーション４１０は、ＭＦＰ１０１からのＨＴＴＰリクエストを受信したか否かを判定する。ここで、リクエストを受信するまでＳ９０１を繰り返す。リクエストを受信すると、Ｓ９０２に進む。Ｓ９０２において、Ｗｅｂアプリケーション４１０は、そのリクエストの内容が「ＳｃａｎしてＦＴＰサーバに送信する」機能についての図６の（ｃ）の実行指示画面であるか否かを判定する。

「ＳｃａｎしてＦＴＰサーバに送信する」機能の実行指示画面であると判定された場合に、Ｓ９０３に進み、Ｗｅｂアプリケーション４１０は、その画面をレスポンスとしてＭＦＰ１０１に送信する。一方、その実行指示画面でないと判定された場合には、Ｓ９０４に進む。Ｓ９０４において、Ｗｅｂアプリケーション４１０は、そのリクエストの内容が「Ｐｒｉｎｔする」機能の実行指示画面であるか否かを判定する。ここで、「Ｐｒｉｎｔする」機能の実行指示画面であると判定された場合に、Ｓ９０５に進み、Ｗｅｂアプリケーション４１０は、その実行指示画面をレスポンスとしてＭＦＰ１０１に送信する。一方、その実行指示画面でないと判定された場合には、Ｓ９０６に進み、Ｗｅｂアプリケーション４１０は、そのリクエストの内容がメンテナンス画面であるか否かを判定する。ここで、メンテナンス画面であると判定された場合に、Ｓ９０７に進み、Ｗｅｂアプリケーション４１０は、そのメンテナンス画面をレスポンスとしてＭＦＰ１０１に送信する。一方、メンテナンス画面でないと判定された場合に、Ｓ９０８に進む。

Ｓ９０８において、Ｗｅｂアプリケーション４１０は、そのリクエストの内容がメニュー画面であるか否かを判定する。ここで、メニュー画面であると判定された場合に、Ｓ９０９に進み、Ｗｅｂアプリケーション４１０が、そのメニュー画面をレスポンスとしてＭＦＰ１０１に送信する。一方、メニュー画面でないと判定された場合には、Ｓ９１０に進み、Ｗｅｂアプリケーション４１０がエラーの旨をＨＴＴＰレスポンスとしてＭＦＰ１０１に送信する。

図１０は、図８において、Ｗｅｂブラウザ４４０がＭＦＰ１０１の装置情報を取得し、図６の（ｃ）の実行指示画面を表示すべきでない場合に表示するメンテナンス画面の例を示す図である。図１０に示す画面は、スキャナで紙詰まりが発生したことを示している。Ｗｅｂブラウザ４４０は、ＯＫボタン１００１の押下を検知すると、図６の（ｂ）のメニュー画面に戻るべく、Ｗｅｂサーバ１０３にリクエストを送信する。

本実施例によれば、ＭＦＰ１０１における画面遷移のタイミングでＭＦＰ１０１が自身の装置情報を取得し、その時点で画面が適切か否かを判定する。その結果に基づき、そのまま画面を表示するか、適切な画面情報への画面取得要求に変更するかを判定するので、適切な画面表示を行うことができる。つまり、ＭＦＰ１０１が自身の装置情報を取得した結果に基づいた画面の要求を行うので、Ｗｅｂサーバ１０３のＷｅｂアプリケーション４１０への無駄な装置情報の通知を省くことができる。その結果、双方の処理負荷の低減に寄与し、ネットワークトラフィックの増加を防ぐことができる。さらには、ユーザアクションごとに情報取得の内容を変更しているので、無駄な処理や画面表示を省くことができる。

［実施例２］
第２の実施例では、第１の実施例で説明した各構成に加えて、ＭＦＰ１０１が内部に備える内部サーバ４９５が図１０に示すメンテナンス画面を生成するケースについて説明する。以下、第１の実施例との差分のみ説明する。

図４の点線に示される部分を含めた図４の構成が、本実施例における構成となる。本実施例においては、ＭＦＰ１０１に内部サーバ４９５が含まれる。内部サーバ４９５は、プレゼンテーション部４９６を含む。プレゼンテーション部４９６は、Ｗｅｂブラウザ４４０の通信部４４１と通信し、Ｗｅｂブラウザ４４０からの要求に応えて、Ｗｅｂブラウザ４４０で表示すべき操作画面をＭＦＰ１０１に送信する。また、Ｗｅｂブラウザ４４０に表示された操作画面を介して入力されたユーザからの指示を、ＭＦＰ１０１から受信する。

本実施例では、実施例１の図１０に示すメンテナンス画面だけをこのプレゼンテーション部４９６で扱う。但し、図１０のメンテナンス画面のみを扱うことに制限されるものではない。

図８のＳ１２１８は、本実施例において、Ｓ８０６、Ｓ８１２においてＷｅｂブラウザ４４０がＭＦＰ１０１の装置情報に異常ありと判断した場合に行われる処理である。Ｓ１２１８では、Ｗｅｂブラウザ４４０が図１０に示すメンテナンス画面のＵＲＬを設定して内部サーバ４９５にＨＴＴＰリクエストを送信して受信した画面を表示する。このとき、本実施例では、図１０に示す画面のＵＲＬが内部サーバ４９５で扱われる。具体的には、Ｗｅｂブラウザ４４０の通信部４４１がリダイレクト処理を行い、ＨＴＴＰリクエストを内部サーバ４９５のプレゼンテーション部４９６に対して行う。ここで、リダイレクト先となる内部サーバ４９５が保持するＵＲＬは予め決められている。Ｗｅｂブラウザ４４０の通信部４４１は、予めそのＵＲＬを知っており、そのＵＲＬを用いてリダイレクト処理を実施する。

ここで、実施例１と同様に、例えば、図６の（ｃ）の「スキャンしてＦＴＰサーバに送信する」の実行指示画面への遷移依頼にも関わらず、その遷移は行わずに、図１０に示すメンテナンス画面に遷移することになる。つまり、この時点では、実行指示画面である図６（ｃ）の実行指示画面よりも、図１０に示すメンテナンス画面の方が適切な画面表示であるということを示す。

本実施例においては、実施例１に加え、Ｗｅｂサーバ１０３への画面要求をさらに少なくすることができる。つまりＷｅｂサーバ１０３の処理負荷のさらなる低減に寄与し、ネットワークトラフィック増加も防ぐことができる。

［実施例３］
第３の実施例では、Ｗｅｂブラウザ４４０がログイン／ログアウト情報、ＭＦＰ１０１の装置情報を常に監視するケースについて説明する。

図１１は、ＭＦＰ１０１で、Ｗｅｂブラウザ４４０がログイン／ログアウト情報、ＭＦＰ１０１の装置情報を常に監視する場合の処理の手順を示すフローチャートである。以下に説明するＳ１１０１〜Ｓ１１０５を繰り返すことにより、Ｗｅｂブラウザ４４０がログイン／ログアウト情報、ＭＦＰ１０１の装置情報を監視する。図１１のフローチャートに示す各動作は、ＭＦＰ１０１のＣＰＵ２１１が制御プログラムを実行することにより実現される。図１１に示す点線部（Ｓ１４０６）については、第４の実施例において説明する。

Ｓ１１０１において、Ｗｅｂブラウザ４４０は、ログインアプリケーション４３０に問い合わせを行いログイン／ログアウト情報を取得する。その後、Ｓ１１０２に進み、Ｗｅｂブラウザ４４０は、ログイン状態か否かを判定する。ここで、ログアウト状態であると判定された場合には、Ｓ１１０３に進む。Ｓ１１０３において、Ｗｅｂブラウザ４４０は、ログインアプリケーション４３０を呼び出し、ログインアプリケーション４３０が、図６の（ａ）の認証画面を表示する。一方、Ｓ１１０２において、ログイン状態であると判定された場合には、Ｓ１１０４に進む。Ｓ１１０４において、Ｗｅｂブラウザ４４０は、ネイティブモジュール４９０に問い合わせを行い、スキャナ２２１、ネットワーク（ＬＡＮ１０４）、プリンタ２２０などＭＦＰ１０１の装置情報を取得する。その後、Ｓ１１０５に進み、Ｗｅｂブラウザ４４０は、スキャナ２２１、ネットワーク（ＬＡＮ１０４）、プリンタ２２０などの情報が正常か否かを判定する。

ここで、正常でないと判定された場合には、Ｓ１１０６に進み、Ｗｅｂブラウザ４４０は、メンテナンス画面である図１０のＵＲＬを設定して、Ｗｅｂサーバ１０３にＨＴＴＰリクエストを送信する。一方、正常であると判定された場合には、Ｓ１１０１に戻り、再度、ログイン／ログアウト情報、ＭＦＰ１０１の装置情報を監視することになる。

本実施例によれば、常にＭＦＰ１０１が自身の装置情報を監視し、取得した時点で画面が適切か否かを判定する。その結果に基づいて、適切な画面取得要求を送信して画面表示を変更するので、適切な画面表示を行うことができる。また、本実施例において、Ｓ１１０５で装置情報が正常であると判定された場合に、その機能を用いた処理の指示を受付けるようにし、ＷｅｂサーバにＨＴＴＰリクエストを送信するようにしても良い。

［実施例４］
第４の実施例では、Ｗｅｂブラウザ４４０がログイン／ログアウト情報、ＭＦＰ１０１の装置情報を常に監視するケースで、かつ、ＭＦＰ１０１が内部に備える内部サーバ４９５が図１０に示すメンテナンス画面を生成するケースについて説明する。以下、第３の実施例との差分のみ説明する。

本実施例では、図１１のＳ１４０６において、Ｗｅｂブラウザ４４０が図１０のメンテナンス画面のＵＲＬを設定して、内部サーバ４９５にＨＴＴＰリクエストを送信する。これにより、メンテナンス画面はＷｅｂサーバ１０３に問い合わせをすることなく、図１０のメンテナンス画面を表示することができる。

本実施例によれば、第３の実施例に加え、Ｗｅｂサーバ１０３への画面要求をさらに少なくすることができる。つまり、Ｗｅｂサーバ１０３の処理負荷を更に低減し、ネットワークトラフィック増加も防ぐことができる。

［実施例５］
第５の実施例では、Ｗｅｂブラウザ４４０が画面情報の受信時にログアウト情報やＭＦＰ１０１の装置情報を取得するケースについて説明する。

図１２は、ＭＦＰ１０１において、ユーザアクションを検知し、その後にログアウト情報やＭＦＰ１０１の装置情報の取得を画面情報の受信時に行う際の処理の手順を示すフローチャートである。図１２に示すフローチャートに示す各動作は、ＭＦＰ１０１のＣＰＵ２１１が制御プログラムを実行することにより実現される。図１２に示す点線部（Ｓ１６１９）については、第６の実施例において説明する。

Ｓ１２０１において、Ｗｅｂブラウザ４４０がユーザアクションを検知したか否かを判定する。ここで、ユーザアクションを検知するまで、Ｗｅｂブラウザ４４０で、Ｓ１２０１の処理を繰り返す。Ｓ１２０１でＷｅｂブラウザ４４０がユーザアクションを検知すると、Ｓ１２０２に進む。Ｓ１２０２において、ユーザアクションが「スキャンしてＦＴＰサーバに送信する」ボタン６０２の押下か否かが判定される。ここで、「スキャンしてＦＴＰサーバに送信する」ボタン６０２の押下であると判定された場合には、Ｓ１２０３に進む。

Ｓ１２０３において、Ｗｅｂブラウザ４４０は、Ｗｅｂサーバ１０３に対して図６の（ｃ）の「スキャンしてＦＴＰサーバに送信する」の実行指示画面情報の取得リクエストを送信して、その後、受信する。Ｓ１２０４において、Ｗｅｂブラウザ４４０は、Ｓ１２０３で受信した画面情報に従い、ネイティブモジュール４９０に対してログイン／ログアウト情報、ＭＦＰ１０１の装置情報の問い合わせを行う。Ｓ１２０５において、Ｗｅｂブラウザ４４０は、ログイン状態か否かを判定する。ここで、ログアウト状態であると判定された場合には、Ｓ１２１８に進む。一方、ログイン状態であると判定された場合には、Ｓ１２０６に進む。Ｓ１２０６において、Ｗｅｂブラウザ４４０は、スキャナ２２１、ネットワーク（ＬＡＮ１０４）の情報が正常か否かを判定する。ここで、正常でないと判定された場合には、Ｓ１２１９に進む。一方、正常であると判定された場合には、Ｓ１２０７に進み、Ｗｅｂブラウザ４４０は、図６の（ｃ）の「スキャンしてＦＴＰサーバに送信する」の実行指示画面を表示する。

再び、Ｓ１２０２を参照する。Ｓ１２０２において「スキャンしてＦＴＰサーバに送信する」ボタン６０２の押下でなかったと判定された場合には、Ｓ１２０８に進み、「Ｐｒｉｎｔする」ボタン６０３の押下であるか否かが判定される。ここで、「Ｐｒｉｎｔする」ボタン６０４の押下と判定された場合には、Ｓ１２０９に進む。Ｓ１２０９において、Ｗｅｂブラウザ４４０は、Ｗｅｂサーバ１０３に対して不図示の「Ｐｒｉｎｔする」の実行指示画面の画面情報の取得リクエストを送信し、その後、受信する。Ｓ１２１０において、Ｗｅｂブラウザ４４０は、Ｓ１２１０で受信した画面情報に従い、ネイティブモジュール４９０に対してログイン／ログアウト情報、ＭＦＰ１０１の装置情報の問い合わせを行う。

Ｓ１２１１において、Ｗｅｂブラウザ４４０は、ログイン状態か否かを判定する。ここで、ログアウト状態であると判定された場合には、Ｓ１２１８に進む。一方、ログイン状態であると判定された場合には、Ｓ１２１２に進む。Ｓ１２１２において、Ｗｅｂブラウザ４４０は、ネイティブモジュール４９０に問い合わせを行い、プリンタ２２０の情報を取得して、プリンタ２２０の情報が正常か否かを判定する。ここで、正常でないと判定ｓされた場合には、Ｓ１２１９に進む。一方、正常であると判定された場合には、Ｓ１２１３に進み、Ｗｅｂブラウザ４４０は、「Ｐｒｉｎｔする」の実行指示画面を表示する。

なお、本フローチャートでは省略したが、Ｗｅｂブラウザ４４０が「スキャンしてＦａｘ送信する」機能ボタン６０３の押下の検知をした場合の処理についても、Ｓ１２０２〜Ｓ１２０７、Ｓ１２０８〜Ｓ１２１３と同様である。

再び、Ｓ１２０８を参照する。Ｓ１２０８において、「Ｐｒｉｎｔする」ボタン６０４の押下でないと判定された場合には、Ｓ１２１４に進み、Ｗｅｂブラウザ４４０は、遷移要求を検知した画面のＵＲＬを設定して画面情報を取得する。Ｓ１２１５において、Ｗｅｂブラウザ４４０は、ログインアプリケーション４３０に問い合わせを行い、ログイン／ログアウト情報を取得する。Ｓ１２１６において、Ｗｅｂブラウザ４４０は、ログイン状態か否かを判定する。ここで、ログアウト状態であると判定された場合には、Ｓ１２１８に進む。一方、ログイン状態であると判定された場合には、Ｓ１２１７に進み、Ｗｅｂブラウザ４４０は、遷移要求を検知した画面を表示する。遷移要求を検知した画面とは、例えば、図６の（ｄ）の実行結果表示画面などを指す。

Ｓ１２１８は、Ｓ１２０５、Ｓ１２１１、Ｓ１２１６において、Ｗｅｂブラウザ４４０がログアウト状態と判定した場合に行われる処理である。Ｓ１２１８において、Ｗｅｂブラウザ４４０は、ログインアプリケーション４３０を呼び出し、ログインアプリケーション４３０が、図６の（ａ）の認証画面を表示する。これは、図６の（ｃ）の「スキャンしてＦＴＰサーバに送信する」の実行指示画面への遷移依頼にも関わらず、その遷移は行わずに、図６の（ａ）の認証画面に遷移することになる。つまり、この時点では、実行指示画面である図６の（ｃ）の表示よりも、図６の（ａ）の認証画面の方が適切な画面表示であるということを示す。

Ｓ１２１９は、Ｓ１２０６、Ｓ１２１２において、Ｗｅｂブラウザ４４０がＭＦＰ１０１の装置情報に異常ありと判定した場合に行われる処理である。Ｓ１２１９において、Ｗｅｂブラウザ４４０は、図１０のメンテナンス画面のＵＲＬを設定してＷｅｂサーバ１０３にＨＴＴＰリクエストを送信する。これは、例えば、図６の（ｃ）の「スキャンしてＦＴＰサーバに送信する」の実行指示画面への遷移依頼にも関わらず、その遷移は行わずに、図１０のメンテナンス画面に遷移することになる。つまり、この時点では、図６の（ｃ）の実行指示画面の表示よりも、図１０のメンテナンス画面の方が適切な画面表示であるということを示す。

本実施例によれば、ＭＦＰ１０１が、受信した画面情報を元に、その表示を行う直前に自身の装置情報を取得し、その時点で画面が適切か否かを判定する。その結果に基づいて、適切な画面情報の取得要求を送信して画面表示を変更するので、適切な画面表示を行うことができる。

［実施例６］
第６の実施例では、Ｗｅｂブラウザ４４０が画面情報の受信時にログアウト情報やＭＦＰ１０１の装置情報を取得するケースで、かつ、ＭＦＰ１０１が内部に備える内部サーバ４９５が図１０のメンテナンス画面を生成するケースについて説明する。以下、第５の実施例との差分のみ説明する。

本実施例においては、図１２のＳ１６１９において、Ｗｅｂブラウザ４４０は、図１０のメンテナンス画面のＵＲＬを設定して内部サーバ４９５にＨＴＴＰリクエストを送信する。これにより、メンテナンス画面はＷｅｂサーバ１０３に問い合わせをすることなく、図１０のメンテナンス画面を表示することができる。

本実施例によれば、第５の実施例に加え、Ｗｅｂサーバ１０３への画面要求をさらに少なくすることができる。つまり、Ｗｅｂサーバ１０３の処理負荷を更に低減し、ネットワークトラフィック増加も防ぐことができる。

［他の実施例］
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

Claims (5)

1. ユーザインタフェースを表示するためのファイルを提供するサーバに接続され、前記ファイルに基づいてユーザインタフェースを表示する情報処理装置であって、
   前記情報処理装置の装置情報を取得する取得手段と、
   前記取得手段により取得された装置情報により、前記情報処理装置の機能を用いることができるか否かを判定する判定手段と、
   前記情報処理装置の機能を用いることができると判定された場合に、前記情報処理装置の機能を用いた処理の実行の指示画面を表示するためのファイルを前記サーバに要求する第１の要求手段と、
   前記情報処理装置の機能を用いることができないと判定された場合に、警告画面を表示するためのファイルを前記サーバに要求する第２の要求手段と
   を備えることを特徴とする情報処理装置。
2. 表示されたユーザインタフェースにおいて、前記情報処理装置の機能を用いた処理の指定を受け付ける受付手段をさらに備え、
   前記受付手段により指示を受け付けると、前記取得手段が前記情報処理装置の装置情報を取得することを特徴とする請求項１に記載の情報処理装置。
3. 表示されたユーザインタフェースにおいて、前記情報処理装置の機能を用いた処理の指定を受け付ける受付手段と、
   前記受付手段により指示を受け付けると、前記情報処理装置がログイン状態であるかログアウト状態であるかを判定する認証判定手段と、
   前記ログアウト状態であると判定された場合に、認証画面を表示するためのファイルを前記サーバに要求する第３の要求手段と
   をさらに備えることを特徴とする請求項１に記載の情報処理装置。
4. ユーザインタフェースを表示するためのファイルを提供するサーバに接続され、前記ファイルに基づいてユーザインタフェースを表示する情報処理装置において実行されるユーザインタフェース表示制御方法であって、
   前記情報処理装置の取得手段が、前記情報処理装置の装置情報を取得する取得工程と、
   前記情報処理装置の判定手段が、前記取得工程において取得された装置情報により、前記情報処理装置の機能を用いることができるか否かを判定する判定工程と、
   前記情報処理装置の第１の要求手段が、前記情報処理装置の機能を用いることができると判定された場合に、前記情報処理装置の機能を用いた処理の実行の指示画面を表示するためのファイルを前記サーバに要求する第１の要求工程と、
   前記情報処理装置の第２の要求手段が、前記情報処理装置の機能を用いることができないと判定された場合に、警告画面を表示するためのファイルを前記サーバに要求する第２の要求工程と
   を備えることを特徴とするユーザインタフェース表示制御方法。
5. ユーザインタフェースを表示するためのファイルを提供するサーバに接続され、前記ファイルに基づいてユーザインタフェースを表示する情報処理装置において実行されるプログラムであって、
   前記情報処理装置の装置情報を取得する取得手段と、
   前記取得手段により取得された装置情報により、前記情報処理装置の機能を用いることができるか否かを判定する判定手段と、
   前記情報処理装置の機能を用いることができると判定された場合に、前記情報処理装置の機能を用いた処理の実行の指示画面を表示するためのファイルを前記サーバに要求する第１の要求手段と、
   前記情報処理装置の機能を用いることができないと判定された場合に、警告画面を表示するためのファイルを前記サーバに要求する第２の要求手段と
   してコンピュータを機能させるプログラム。

Images