JP2012162044A - 情報処理システム、画像形成装置、情報処理方法、及びプログラム - Google Patents

Abstract

【課題】プリケーションプログラムに対するインタフェースについてＷｅｂページからの利用を簡便化すること。
【解決手段】画像形成装置は、Ｗｅｂページを表示させるＷｅｂページ表示制御部と、アプリケーションプログラムより呼び出し可能なインタフェースを有するプラットフォーム部とを有し、表示制御部は、表示中のＷｅｂページにおいて操作対象とされた部分に関連付けられている識別子を含む第一の要求を情報処理装置に送信し、該情報処理装置より返信されるリダイレクト命令に基づく第二の要求をプラットフォーム部に送信し、プラットフォーム部は、第二の要求に含まれる識別子に対応したアプリケーションプログラムを呼び出し、呼び出されたアプリケーションプログラムは、インタフェースを呼び出す。
【選択図】図７

Description

本発明は、情報処理システム、画像形成装置、情報処理方法、及びプログラムに関する。

近年の画像形成装置は、汎用的なコンピュータと同様にＣＰＵ（Central Processing Unit）を備え、各機能は、アプリケーションプログラム（以下、「アプリ」ともいう）等の制御によって実現されるようになっている。

このような画像形成装置の中には、アプリを実装するためのＡＰＩが公開され、ユーザ所望のアプリを搭載することにより、カスタマイズが可能とされているものもある。公開されているＡＰＩは、例えば、Ｃ言語やＪａｖａ（登録商標）言語等によるプログラムより呼び出し可能とされている。

また、ネットワーク上、又は機器内から取得したＨＴＭＬ（Hyper Text Markup Language）データを機器の画面として表示するＷｅｂブラウザが搭載された画像形成装置も存在する。このようなＷｅｂブラウザの中には、画面を表示するだけでなく、機器制御用に拡張されたスクリプトを解釈して機器制御を実行することが可能なものも有る。斯かるＷｅｂブラウザによれば、スクリプト等のブラウザベースのインタフェースをカスタマイズ用に提供することができる（例えば、特許文献１）。

しかしながら、ブラウザベースのインタフェースを介して利用可能な画像形成装置の機能の範囲は、上記ＡＰＩを介して利用可能な機能の範囲に比べて限定されたものである。もちろん、上記ＡＰＩが有する全ての関数又はメソッドに対応した拡張的なスクリプトに対する実装がＷｅｂブラウザに組み込まれれば、ブラウザベースのインタフェースを介して利用可能な機能の範囲を、上記ＡＰＩと同等とすることはできる。但し、このような形態を採用する場合、上記ＡＰＩの拡張に応じて、Ｗｅｂブラウザを継続的に改変しなければならない。

本発明は、上記の点に鑑みてなされたものであって、アプリケーションプログラムに対するインタフェースについてＷｅｂページからの利用を簡便化することのできる情報処理システム、画像形成装置、情報処理方法、及びプログラムの提供を目的とする。

そこで上記課題を解決するため、本発明は、アプリケーションプログラムをインストール可能な画像形成装置と、該画像形成装置にネットワークを介して接続される情報処理装置とを含む情報処理システムであって、前記画像形成装置は、Ｗｅｂページを表示させるＷｅｂページ表示制御部と、前記アプリケーションプログラムより呼び出し可能なインタフェースを有するプラットフォーム部とを有し、前記表示制御部は、表示中のＷｅｂページにおいて操作対象とされた部分に関連付けられている識別子を含む第一の要求を前記情報処理装置に送信し、該情報処理装置より返信されるリダイレクト命令に基づく第二の要求を前記プラットフォーム部に送信し、前記プラットフォーム部は、前記第二の要求に含まれる前記識別子に対応した前記アプリケーションプログラムを呼び出し、呼び出されたアプリケーションプログラムは、前記インタフェースを呼び出す。

このような情報処理システムでは、アプリケーションプログラムに対するインタフェースについてＷｅｂページからの利用を簡便化することができる。

本発明によれば、プリケーションプログラムに対するインタフェースについてＷｅｂページからの利用を簡便化することができる。

本発明の実施の形態におけるシステム構成例を示す図である。 本発明の実施の形態における画像形成装置のハードウェア構成例を示す図である。 本発明の実施の形態におけるＷｅｂサーバ装置のハードウェア構成例を示す図である。 本発明の実施の形態における画像形成装置のソフトウェア構成例を示す図である。 本発明の実施の形態におけるＷｅｂサーバ装置の機能構成例を示す図である。 第一の実施の形態におけるＳＤＫアプリの例を示す図である。 第一の実施の形態の処理手順を説明するためのシーケンス図である。 状態設定画面の表示例を示す図である。 対応不可要求記憶部の構成例を示す図である。 第二の実施の形態におけるＳＤＫアプリの例を示す図である。 第二の実施の形態の処理手順を説明するためのシーケンス図である。

以下、図面に基づいて本発明の実施の形態を説明する。図１は、本発明の実施の形態におけるシステム構成例を示す図である。同図において、一以上の画像形成装置１０及びＷｅｂサーバ装置２０は、ＬＡＮ（Local Area Network）又はインターネット等のネットワーク３０（有線又は無線の別は問わない）を介して通信可能に接続されている。

画像形成装置１０は、印刷、スキャン、コピー、及びＦＡＸ送受信等のうちの二以上の機能を一台の筐体によって実現する複合機である。但し、いずれか一つの機能を単体で有する機器が画像形成装置１０として用いられてもよい。画像形成装置１０には、機能拡張等を目的としてプログラムのインストール又はアンインストール等が可能である。

Ｗｅｂサーバ装置２０は、画像形成装置１０からの要求（ＨＴＴＰ（HyperText Transfer Protocol）リクエスト）に応じた処理を実行し、処理結果に応じたＷｅｂページを画像形成層装置１０に返信するコンピュータである。本実施の形態において、Ｗｅｂページとは、ＨＴＴＰ通信によって取得される表示用のデータをいう。Ｗｅｂページの代表的なデータ形式としてＨＴＭＬ（HyperText Markup Language）が挙げられる。

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

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

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

図３は、本発明の実施の形態におけるＷｅｂサーバ装置のハードウェア構成例を示す図である。図３のＷｅｂサーバ装置２０は、それぞれバスBで相互に接続されているドライブ装置２００、補助記憶装置２０２、メモリ装置２０３、ＣＰＵ２０４、及びインタフェース装置２０５等を有する。

Ｗｅｂサーバ装置２０での処理を実現するプログラムは、ＣＤ−ＲＯＭ等の記録媒体２０１によって提供される。プログラムを記録した記録媒体２０１がドライブ装置２００にセットされると、プログラムが記録媒体２０１からドライブ装置２００を介して補助記憶装置２０２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体２０１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置２０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。

メモリ装置２０３は、プログラムの起動指示があった場合に、補助記憶装置２０２からプログラムを読み出して格納する。ＣＰＵ２０４は、メモリ装置２０３に格納されたプログラムに従ってＷｅｂサーバ装置２０に係る機能を実行する。インタフェース装置２０５は、ネットワークに接続するためのインタフェースとして用いられる。

図４は、本発明の実施の形態における画像形成装置のソフトウェア構成例を示す図である。同図において、画像形成装置１０は、標準アプリ１５１、ＳＤＫアプリ１５２、ＳＤＫプラットフォーム１５３、機器ブラウザ１５４、ｌｉｂｗｗｗ１５５、ＶＡＳ（仮想アプリケーションサービス）１５６、コントロールサービス１５７、及びＯＳ１５８等を有する。

標準アプリ１５１は、画像形成装置１０に標準的に（出荷時に予め）実装されているアプリケーションの集合である。同図では、スキャンアプリ１５１１、印刷アプリ１５１２、コピーアプリ１５１３、及びＦＡＸアプリ１５１４が例示されている。スキャンアプリ１５１１は、スキャンジョブを実行する。印刷アプリ１５１２は印刷ジョブを実行する。コピーアプリ１５１３は、コピージョブを実行する。ＦＡＸアプリ１５１４は、ＦＡＸの送信ジョブ又は受信ジョブを実行する。

コントロールサービス１５７は、各種のハードウェアリソース等を制御するための機能を上位アプリケーション等に対して提供したり、画像形成装置１０の基盤的な機能等を実行したりするソフトウェアモジュール群である。

ＳＤＫアプリ１５２は、画像形成装置１０の出荷後において、画像形成装置１０の機能拡張等を図るためのプラグインとして追加的にインストールされるアプリケーションプログラムである。したがって、ＳＤＫアプリ１５２の機能は、所定のものに限定されない。例えば、各ＳＤＫアプリ１５２は、ＳＤカード８０から又はネットワークを介して画像形成装置１０にインストールされ、ＳＤＫプラットフォーム１５３上において一つのスレッドとして起動される。

ＳＤＫプラットフォーム１５３は、ＳＤＫアプリ１５２の実行環境を実現する。各ＳＤＫアプリ１５２は、ＳＤＫプラットフォーム１５３が提供するＡＰＩ（Application Program Interface）（以下、「ＳＤＫＡＰＩ」という。）を利用して開発される。例えば、ＳＤＫプラットフォーム１５３は、スキャン機能を利用させるためのＳＤＫＡＰＩ、印刷機能を利用させるためのＳＤＫＡＰＩ、コピー機能を利用させるためのＳＤＫＡＰＩ等をＳＤＫアプリ１５２に提供する。ＳＤＫＡＰＩは公開されており、サードベンダ等によってもＳＤＫアプリ１５２は開発されうる。また、ＳＤＫＡＰＩは、異機種間において平滑化されている。したがって、ＳＤＫアプリ１５２に関して、機種に応じて異なる実装が行われる必要性は低い。なお、ＳＤＫプラットフォーム１５３は、それ自体、画像形成装置１０にインストールされるアプリケーションの一種である。例えば、ＳＤＫプラットフォーム１５３は、ＳＤカード８０から又はネットワークを介して画像形成装置１０にインストールされる。

同図において、ＳＤＫプラットフォーム１５３は、クラスライブラリ１５３１及びＷｅｂサーバ部１５３２を含む。クラスライブラリ１５３１は、ＳＤＫＡＰＩに対する実装である。或るＳＤＫＡＰＩの呼び出しに応じ、当該ＳＤＫＡＰＩに対応するクラスライブラリ１５３１は、例えば、ＶＡＳ１５６を介してコントロールサービス１５７を呼び出して、画像形成装置１０に所定の処理を実行させる。

Ｗｅｂサーバ部１５３２は、ＨＴＴＰリクエストを待機し、ＨＴＴＰリクエストにおいて指定された識別子に対応するＳＤＫアプリ１５２を呼び出す。Ｗｅｂサーバ部１５３２より呼び出し可能なＳＤＫアプリ１５２の形態として、例えば、サーブレットが挙げられる。

ｌｉｂｗｗｗ１５５は、ＨＴＴＰ通信においてクライアントとしての機能を提供するライブラリである。

機器ブラウザ１５４は、ｌｉｂｗｗｗ１５５を利用して、Ｗｅｂサーバ装置２０よりＷｅｂページを取得し、当該Ｗｅｂページを操作パネル１５に表示させるプログラムである。機器ブラウザ１５４は、Ｗｅｂページに記述されたスクリプト（スクリプト言語によるプログラム）を解釈することができ、当該スクリプトに応じた処理を、画像形成装置１０に実行させる。すなわち、機器ブラウザ１５４は、汎用的なＷｅｂブラウザが解釈可能なスクリプトだけでなく、画像形成装置１０を制御するために拡張されたスクリプト（例えば、スキャンの実行命令等）を解釈することができ、これによって画像形成装置１０に画像処理等を実行させることができる。なお、機器ブラウザ１５４は、例えば、ＳＤカード８０から又はネットワークを介して画像形成装置１０にインストールされる。

ＶＡＳ１５６は、コントロールサービス１５７の利用者側からコントロールサービス１５７を隠蔽するラッピング機能を備え、コントロールサービス１５７のバージョンアップに伴うバージョン差を吸収する役割等を担う。コントロールサービス１５７の利用者とは、標準アプリ１５１、ＳＤＫプラットフォーム１５３、及び機器ブラウザ１５４等である。

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

図５は、本発明の実施の形態におけるＷｅｂサーバ装置の機能構成例を示す図である。同図に示されるように、Ｗｅｂサーバ装置２０は、通信制御部２１、及び一以上のＷｅｂアプリ２２等を有する。通信制御部２１及びＷｅｂアプリ２２は、Ｗｅｂサーバ装置２０にインストールされたプログラムがＣＰＵ２０４に実行させる処理によって実現される。

通信制御部２１は、ＨＴＴＰ通信においてサーバとしての通信制御を行う。例えば、通信制御部２１は、画像形成装置１０からの要求（ＨＴＴＰリクエスト）の受信を待機し、受信された要求に応じたＷｅｂアプリ２２を起動する。通信制御部２１は、起動されたＷｅｂアプリ２２から出力される情報（Ｗｅｂページ等）を含む応答（ＨＴＴＰレスポンス）の送信を行う。

各Ｗｅｂアプリ２２は、Ｗｅｂページ生成部２２１、対応可否判定部２２２、及び対応不可要求記憶部２２３等を有する。

Ｗｅｂページ生成部２２１は、画像形成装置１０からの要求に応じたＷｅｂページを生成する。対応可否判定部２２２は、対応不可要求記憶部２２３を参照して、画像形成装置１０からの要求に応じた処理を当該Ｗｅｂアプリ２２が実行可能であるか否か（対応可能か否か）を判定する。対応不可要求記憶部２２３は、補助記憶装置２０２又はＷｅｂサーバ装置２０とネットワークを介して接続可能な記憶装置等を用いて、当該Ｗｅｂアプリ２２が実行できない（対応できない）要求の識別情報の一覧を記憶する。

第一の実施の形態について説明する。第一の実施の形態では、図６に示されるようなロック状態設定アプリ１５２ａが、ＳＤＫアプリ１５２の一つとして画像形成装置１０にインストールされている例について説明する。

図６は、第一の実施の形態におけるＳＤＫアプリの例を示す図である。同図において、ロック状態設定アプリ１５２ａは、インタフェース部１６１ａ及びロック状態設定部１６２等を有する。インタフェース部１６１ａは、ＳＤＫプラットフォーム１５３が、機器ブラウザ１５４からの要求（ＨＴＴＰリクエスト）に応じて、ロック状態設定アプリ１５２ａを呼び出せるようにするためのインタフェースである。例えば、インタフェース部１６１ａは、ロック状態設定アプリ１５２ａがサーブレットとして振る舞えるようにするための実装である。ロック状態設定部１６２は、画像形成装置１０の各種の状態移行に関して、ロック状態（ロック（禁止）又はアンロック（禁止解除））の設定用のＳＤＫＡＰＩを呼び出す。ロック状態の設定の一例として、省エネ状態へ移行の禁止又は禁止解除、余熱移行の禁止又は禁止解除等が挙げられる。

以下、第一の実施の形態の処理手順について説明する。図７は、第一の実施の形態の処理手順を説明するためのシーケンス図である。

ステップＳ１０１において、機器ブラウザ１５４は、ロック状態をユーザに設定させるための画面（以下、「状態設定画面」という。）を表示させるＷｅｂページのＵＲＬを指定して、Ｗｅｂページの取得要求（ＨＴＴＰリクエスト）をＷｅｂサーバ装置２０に送信する。当該ＵＲＬは、例えば、以下の通りである。

ｈｔｔｐ：／／＜ＩＰ１：ＰＯＲＴ１＞／ｌｏｃｋｗｅｂａｐｌ／ｉｎｄｅｘ．ｈｔｍｌ ・・・（ａ）
ここで、ＩＰ１は、Ｗｅｂサーバ装置２０のＩＰアドレスを示す。ＰＯＲＴ１は、通信制御部２１のポート番号を示す。ＵＲＬ（ａ）は、例えば、ステップＳ１０１の直前において、機器ブラウザ１５４によって表示されていたＷｅｂページに張られていたリンク等に基づいて特定される。なお、機器ブラウザ１５４とＷｅｂサーバ装置２０との通信は、ｌｉｂｗｗｗ１５５を介して行われるが、図７の説明において、ｌｉｂｗｗｗ１５５は、便宜上、省略される。

Ｗｅｂサーバ装置２０の通信制御部２１によってＷｅｂページの取得要求が受信されると、ＵＲＬ（ａ）に含まれる識別子「ｌｏｃｋｗｅｂａｐｌ」に対応するＷｅｂアプリ２２（以下、「Ｗｅｂアプリ２２ａ」という。）が起動される。Ｗｅｂアプリ２２ａのＷｅｂページ生成部２２１は、当該取得要求において指定されたＵＲＬ（ａ）に対応するＷｅｂページを生成する。但し、当該Ｗｅｂページは、予め生成され、補助記憶装置２０２に保存されていてもよい。通信制御部２１は、生成されたＷｅｂページを含む応答（ＨＴＴＰレスポンス）を機器ブラウザ１５４に返信する（Ｓ１０２）。

続いて、機器ブラウザ１５４は、返信されたＷｅｂページに基づいて、状態設定画面を操作パネル１５に表示させる（Ｓ１０３）。

図８は、状態設定画面の表示例を示す図である。同図において、状態設定画面５１０は、省エネ状態移行に関して、禁止ボタン５１１及び解除ボタン５１２を有し、余熱移行に関して、禁止ボタン５１３及び解除ボタン５１４を有する。現時点においては、解除ボタン５１２及び解除ボタン５１４が選択状態とされている。したがって、省エネ状態への移行及び余熱移行はそれぞれ禁止されていない（ロックされていない）ことが分かる。各ボタンの選択状態は、例えば、状態設定画面５１０に係るＷｅｂページに記述されているスクリプトに基づいて実現される。例えば、当該スクリプトは、省エネ状態への移行及び余熱移行に関するロック状態を画像形成装置１０より取得し、当該ロック状態に基づいて、禁止ボタン５１１若しくは解除ボタン５１２、又は禁止ボタン５１３若しくは解除ボタン５１４を選択状態とする。

例えば、ユーザによって、禁止ボタン５１１が押下（選択）されると（Ｓ１０４）、機器ブラウザ１５４は、表示中のＷｅｂページにおいて、禁止ボタン５１１（操作対象とされた部分）に対する定義（例えば、リンク等）に基づく要求（ＨＴＴＰリクエスト）を、Ｗｅｂサーバ装置２０に送信する（Ｓ１０５）。当該要求には、例えば、次のようなＵＲＬが指定される。換言すれば、禁止ボタン５１１には、次のようなＵＲＬが関連付けられている。

ｈｔｔｐ：／／＜ＩＰ１：ＰＯＲＴ１＞ＩＰ：ＰＯＲＴ／ｌｏｃｋｗｅｂａｐｌ／Ｏｆｆｌｉｎｅ？Ｌｏｃｋ＝ｔｒｕｅ ・・・（ｂ）
ＵＲＬ（ｂ）において、「ｌｏｃｋｗｅｂａｐｌ」に続く記述である「Ｏｆｆｌｉｎｅ？Ｌｏｃｋ＝ｔｒｕｅ」は、Ｗｅｂアプリ２２ａに対する処理要求を示す。具体的には、省エネ状態への移行の禁止の設定要求を示す。すなわち、「Ｏｆｆｌｉｎｅ」は、省エネ状態に関する設定要求を示す。「Ｌｏｃｋ＝ｔｒｕｅ」は、禁止することを示す。

Ｗｅｂサーバ装置２０の通信制御部２１によってＵＲＬ（ｂ）を含む要求が受信されると、ＵＲＬ（ｂ）に含まれる識別子「ｌｏｃｋｗｅｂａｐｌ」に対応するＷｅｂアプリ２２ａが起動される。Ｗｅｂアプリ２２ａには、ＵＲＬ（ｂ）が伝達（入力）される。Ｗｅｂアプリ２２ａの対応可否判定部２２２は、対応不可要求記憶部２２３を参照して、ＵＲＬ（ｂ）に指定された処理要求について、Ｗｅｂアプリ２２ａが対応可能であるか否かを判定する（Ｓ１０６）。

図９は、対応不可要求記憶部の構成例を示す図である。同図に示されるように、対応不可要求記憶部２２３は、当該Ｗｅｂアプリ２２が対応することのできない処理要求の識別情報（例えば、キーワード）の一覧を記憶する。同図では、「ＰｏｗｅｒＯｆｆ」、「Ｏｆｆｌｉｎｅ」、及び「ＰａｎｅｌＯｆｆ」が、対応不可な処理要求の識別情報として記憶されている。

図９の例に基づけば、ＵＲＬ（ｂ）によって示される処理要求は、「Ｏｆｆｌｉｎｅ」を含むため、対応可否判定部２２２は、当該処理要求を対応不可であると判定する。対応可否判定部２２２は、対応不可であると判定した場合、リダイレクト命令を生成する。当該リダイレクト命令において、リダイレクト先は、例えば、次のようなＵＲＬとされる。

ｈｔｔｐ：／／＜ＩＰ２：ＰＯＲＴ２＞／ＬｏｃｋＡｐｌ／Ｏｆｆｌｉｎｅ？Ｌｏｃｋ＝ｔｒｕｅ＆ｒｅｔｕｒｎｐａｔｈ＝＜ＩＰ１：ＰＯＲＴ１＞／ｌｏｃｋｗｅｂａｐｌ／ｉｎｄｅｘ．ｈｔｍｌ ・・・（ｃ）
ＵＲＬ（ｃ）は、ＵＲＬ（ｂ）の＜ＩＰ１：ＰＯＲＴ１＞及びｌｏｃｋｗｅｂａｐｌが、＜ＩＰ２：ＰＯＲＴ２＞又はＬｏｃｋＡｐｌに置換されたものである。ＩＰ２は、処理要求元の画像形成装置１０のＩＰアドレスを示す。ＰＯＲＴ２は、当該画像形成装置１０のＷｅｂサーバ部１５３２のポート番号を示す。また、「ＬｏｃｋＡｐｌ」は、ロック状態設定アプリ１５２ａの識別子である。すなわち、ＵＲＬ（ｃ）を含むリダイレクト命令は、Ｗｅｂアプリ２２ａが対応できない処理要求「Ｏｆｆｌｉｎｅ？Ｌｏｃｋ＝ｔｒｕｅ」について、ロック状態設定アプリ１５２ａへの委譲要求に相当する。Ｗｅｂアプリ２２ａが対応できない処理要求の委譲先（「ＬｏｃｋＡｐｌ」）は、Ｗｅｂアプリ２２ａ（の対応可否判定部２２２）にロジックとして実装されていてもよい。または、処理要求の識別子ごとに委譲先の識別子がファイル等に記録されていてもよい。

ＵＲＬ（ｃ）には、更に、「ｒｅｔｕｒｎｐａｔｈ＝＜ＩＰ１：ＰＯＲＴ１＞／ｌｏｃｋｗｅｂａｐｌ／ｉｎｄｅｘ．ｈｔｍｌ」が付与されている。これは、ロック状態設定アプリ１５２ａに対して、表示対象のＷｅｂページの遷移先を通知するための情報である。当該情報がどのように用いられるかについては、後述される。

なお、対応可否判定部２２２によって、対応不可であると判定された場合、要求された処理がＷｅｂサーバ装置２０において実行され、当該処理結果を示すＷｅｂページが、機器ブラウザ１５４に返信される。このように、処理要求単位で対応の可否が判定されることにより、画像形成装置１０に固有のハードウェア資源の利用を必要としない処理に関して、Ｗｅｂサーバ装置２０に実行させることができる。したがって、画像形成装置１０の負荷を軽減することができると共に、画像形成装置１０の限られたハードウェア資源では実現することが困難な情報処理を、Ｗｅｂサーバ装置２０の豊富なハードウェア資源を用いて実行することができる。

続いて、通信制御部２１は、生成されたリダイレクト命令を含む応答を、機器ブラウザ１５４に返信する（Ｓ１０７）。機器ブラウザ１５４は、受信されたリダイレクト命令が示すＵＲＬ（ｃ）宛に、要求（ＨＴＴＰリクエスト）を送信する（Ｓ１０８）。要求元の機器ブラウザ１５４と同一の画像形成装置１０内のＷｅｂサーバ部１５３２によって受信される。Ｗｅｂサーバ部１５３２は、ＵＲＬ（ｃ）に含まれる「ＬｏｃｋＡｐｌ」に対応するロック状態設定アプリ１５２ａを起動する（Ｓ１０９）。この際、ロック状態設定アプリ１５２ａには、ＵＲＬ（ｃ）が伝達（入力）される。

続いて、ロック状態設定アプリ１５２ａは、ＵＲＬ（ｃ）に係る要求（ＨＴＴＰリクエスト）が同一画像形成装置１０内からのものであるか否かを判定する（Ｓ１１０）。当該判定は、例えば、ＨＴＴＰリクエストに含まれている送信元のＩＰアドレスと、当該画像形成装置１０のＩＰアドレスとを比較することにより行われる。両者が一致すれば、ＵＲＬ（ｃ）に係る要求は、同一画像形成装置１０内からの要求であり、一致しなければ、ＵＲＬ（ｃ）に係る要求は、他の画像形成装置１０からの要求である。又は、機器ブラウザ１５４は、ステップＳ１０８のＨＴＴＰリクエストの送信時において、当該画像形成装置１０の製造番号又はＭＡＣアドレスを当該画像形成装置１０より取得し、当該ＨＴＴＰリクエストに含めてもよい。この場合、ステップＳ１１０では、製造番号又はＭＡＣアドレスについて照合が行われればよい。

なお、ステップＳ１１０の判定は、他の画像形成装置１０からの要求に応じたロック状態設定アプリ１５２ａによる処理の実行（すなわち、各種のロック等）を制限するための判定である。すなわち、ユーザから見た場合、状態設定画面５１０に対する入力に応じて、他の画像形成装置１０において当該入力に対応する処理が実行されるのは不自然だからである。したがって、ＵＲＬ（ｃ）に係る要求が他の画像形成装置１０からの要求であると判定された場合、例えば、ロック状態設定アプリ１５２ａのロック状態設定部１６２は、エラー情報をＷｅｂサーバ部１５３２に出力する。Ｗｅｂサーバ部１５３２は、エラーを示すＷｅｂページを機器ブラウザに返信する。

ＵＲＬ（ｃ）に係る要求が同一画像形成装置１０内からのものである場合、ロック状態設定アプリ１５２ａのロック状態設定部１６２は、ＵＲＬ（ｃ）における処理要求（「Ｏｆｆｌｉｎｅ？Ｌｏｃｋ＝ｔｒｕｅ」）に応じ、省エネ状態移行の禁止を設定するためのＳＤＫＡＰＩ（関数又はメソッド）を呼び出す（Ｓ１１１）。当該ＳＤＫＡＰＩの呼び出しに応じ、クラスライブラリ１５３１において当該ＳＤＫＡＰＩの実装に相当する部分（クラス）は、省エネ状態移行の禁止の設定要求をＶＡＳ１５６を介してコントロールサービス１５７に行う。コントロールサービス１５７は、当該画像形成装置１０に関して、省エネ状態への移行を禁止するための設定を行う。

続いて、インタフェース部１６１ａは、ＵＲＬ（ｃ）の「ｒｅｔｕｒｎｐａｔｈ＝＜ＩＰ１：ＰＯＲＴ１＞／ｌｏｃｋｗｅｂａｐｌ／ｉｎｄｅｘ．ｈｔｍｌ」に基づいて、以下のＵＲＬをリダイレクト先とするリダイレクト命令をＷｅｂサーバ部１５３２に出力する（Ｓ１１２）。

ｈｔｔｐ：／／＜ＩＰ１：ＰＯＲＴ１＞／ｌｏｃｋｗｅｂａｐｌ／ｉｎｄｅｘ．ｈｔｍｌ ・・・（ｄ）
すなわち、ＵＲＬ（ｃ）において、「ｒｅｔｕｒｎｐａｔｈ＝」以降は、ロック状態設定アプリ１５２ａが、リダイレクト先（Ｗｅｂページの遷移先）を判定するために用いられる。

続いて、Ｗｅｂサーバ部１５３２は、当該リダイレクト命令を含む応答（ＨＴＴＰレスポンス）を、機器ブラウザ１５４に返信する（Ｓ１１３）。続いて、機器ブラウザ１５４は、受信されたリダイレクト命令が示すＵＲＬ（ｄ）宛に、要求（ＨＴＴＰリクエスト）を送信する（Ｓ１１５）。なお、ＵＲＬ（ｄ）は、ＵＲＬ（ａ）と同じである。したがって、当該要求に応じて、ステップＳ１０２の際と同じＷｅｂページが返信される（Ｓ１１５）。機器ブラウザ１５４は、当該Ｗｅｂページに基づいて、状態設定画面５１０を操作パネル１５に表示させる。但し、この時点において、当該画像形成装置１０は、省エネ状態移行に関して禁止に設定されている。したがって、改めて表示された状態設定画面５１０では、当該Ｗｅｂページ内のスクリプトが機器ブラウザ１５４によって実行されることにより禁止ボタン５１１が選択状態となる。

上述したように、第一の実施の形態によれば、機器ブラウザ１５４は、表示対象のＷｅｂページの定義に従って、ＳＤＫプラットフォーム１５３のＷｅｂサーバ部１５３２を介して、ＳＤＫアプリ１５２を起動させることができる。したがって、機器ブラウザ１５４に表示させるＷｅｂページからＳＤＫＡＰＩを利用したい場合に、当該ＳＤＫＡＰＩの呼び出しを、ＳＤＫアプリ１５２に代行させることができる。その結果、機器ブラウザ１５４に関して、ＳＤＫＡＰＩに対応する拡張的なスクリプトの実装を行わなくても、実質的に、ＷｅｂページからＳＤＫＡＰＩの呼び出しを可能とすることができる。したがって、例えば、ＳＤＫＡＰＩの関数又はメソッドごとに、それぞれに一対一に対応するＳＤＫアプリ１５２を実装することで、全てのＳＤＫＰＩの呼び出しを、Ｗｅｂページ（機器ブラウザ１５４）から可能とすることができる。また、新たなＳＤＫＡＰＩが追加された場合であっても、当該ＳＤＫＡＰＩに対応するＳＤＫアプリ１５２を実装すればよく、機器ブラウザ１５４に関して改変が必要とされる可能性は低い。

すなわち、本実施の形態において、ロック状態設定アプリ１５２ａは、一般的なアプリケーションプログラムが実行するような、或る機能を提供するための一連の処理を実行することを目的とするアプリケーションプログラムではなく、Ｗｅｂページ（機器ブラウザ１５４）からのＳＤＫＡＰＩの呼び出しを仲介又は代行を目的とするアプリケーションプログラムであるともいえる。

次に、第二の実施の形態について説明する。第二の実施の形態では、第一の実施の形態と異なる点について説明する。したがって、特に言及しない点については、第一の実施の形態と同様でよい。

第二の実施の形態では、図１０に示されるようなカード認証アプリ１５２ｂ、カードＩＤ取得アプリ１５２ｃ、認証アプリ１５２ｄ及び等が、ＳＤＫアプリ１５２として画像形成装置２０にインストールされている例について説明する。

図１０は、第二の実施の形態におけるＳＤＫアプリの例を示す図である。同図において、カードＩＤ取得アプリ１５２ｃは、非図示のカードリーダにセットされたＩＣカード又は磁気カード（以下、単に、「カード」という。）よりカードＩＤを取得する処理を実行するＳＤＫアプリ１５２である。当該カードは、例えば、画像形成装置１０に対する利用権限が与えられた各ユーザに配布されている。認証アプリ１５２ｄは、ユーザ名及びパスワードの入力に応じて、ユーザの認証を実行するＳＤＫアプリ１５２である。

カード認証アプリ１５２ｂは、カードより取得されたカードＩＤに基づいて、ユーザの認証を実行するＳＤＫアプリ１５２である。同図において、カード認証アプリ１５２ｂは、インタフェース部１６１ｂ及びカード認証部１６３等を有する。インタフェース部１６１ｂは、ＳＤＫプラットフォーム１５３が、機器ブラウザ１５４からの要求（ＨＴＴＰリクエスト）に応じて、カード認証アプリ１５２ｂを呼び出せるようにするためのインタフェースである。カード認証部１６３は、カードＩＤの取得に関してカードＩＤ取得アプリ１５２ｃを利用する。カード認証部１６３は、取得されたカードＩＤをユーザ名及びパスワードに置換し、置換されたユーザ名及びパスワードに基づく認証に関して認証アプリ１５２ｄを利用する。但し、カード認証アプリ１５２ｂ内に、カードＩＤ取得アプリ１５２ｃ及び認証アプリ１５２ｄの機能が含まれていてもよい。

なお、カードＩＤからユーザ名及びパスワードへの置換は、予めＮＶＲＡＭ１１５又はＨＤＤ１１４等に記録されている、カードＩＤとユーザ名及びパスワードとの対応情報を用いて行われる。

以下、第二の実施の形態の処理手順について説明する。図１１は、第二の実施の形態の処理手順を説明するためのシーケンス図である。

ステップＳ２０１において、機器ブラウザ１５４は、認証方法を選択させるための画面（以下、「認証方法選択画面」という。）を表示させるＷｅｂページのＵＲＬを指定して、Ｗｅｂページの取得要求（ＨＴＴＰリクエスト）をＷｅｂサーバ装置２０に送信する。当該ＵＲＬは、例えば、以下の通りである。

ｈｔｔｐ：／／＜ＩＰ１：ＰＯＲＴ１＞／ａｕｔｈｗｅｂａｐｌ／ｉｎｄｅｘ．ｈｔｍｌ ・・・（ｅ）
Ｗｅｂサーバ装置２０の通信制御部２１によってＷｅｂページの取得要求が受信されると、ＵＲＬ（ｅ）に含まれる識別子「ａｕｔｈｗｅｂａｐｌ」に対応するＷｅｂアプリ２２（以下、「Ｗｅｂアプリ２２ｂ」という。）が起動される。Ｗｅｂアプリ２２ｂのＷｅｂページ生成部２２１は、当該取得要求において指定されたＵＲＬ（ｅ）に対応するＷｅｂページを生成する。通信制御部２１は、生成されたＷｅｂページを含む応答（ＨＴＴＰレスポンス）を機器ブラウザ１５４に返信する（Ｓ２０２）。

続いて、機器ブラウザ１５４は、返信されたＷｅｂページに基づいて、認証方法選択画面を操作パネル１５に表示させる（Ｓ２０３）。認証方法選択画面には、例えば、カード認証、パスワード認証等、認証方法ごとにボタンが配置されている。

例えば、ユーザによって、カード認証ボタンが押下（選択）されると（Ｓ２０４）、機器ブラウザ１５４は、Ｗｅｂページにおいて、カード認証ボタンに対する定義（例えば、リンク等）に基づく要求（ＨＴＴＰリクエスト）を、Ｗｅｂサーバ装置２０に送信する（Ｓ２０５）。当該要求には、例えば、次のようなＵＲＬが指定される。換言すれば、カード認証ボタンには、次のようなＵＲＬが関連付けられている。

ｈｔｔｐ：／／＜ＩＰ１：ＰＯＲＴ１＞ＩＰ：ＰＯＲＴ／ａｕｔｈｗｅｂａｐｌ／ＣａｒｄＬｏｇｉｎ ・・・（ｆ）
ＵＲＬ（ｆ）において、「ａｕｔｈｗｅｂａｐｌ」は、Ｗｅｂアプリ２２ｂの識別子を示す。「ａｕｔｈｗｅｂａｐｌ」に続く記述である「ＣａｒｄＬｏｇｉｎ」は、Ｗｅｂアプリ２２ｂに対する処理要求を示す。具体的には、カード認証の実行要求を示す。

Ｗｅｂサーバ装置２０の通信制御部２１によってＵＲＬ（ｆ）を含む要求が受信されると、ＵＲＬ（ｆ）に含まれる識別子「ａｕｔｈｗｅｂａｐｌ」に対応するＷｅｂアプリ２２ｂが起動される。Ｗｅｂアプリ２２ｂには、ＵＲＬ（ｆ）が伝達（入力）される。Ｗｅｂアプリ２２ｂの対応可否判定部２２２は、対応不可要求記憶部２２３を参照して、ＵＲＬ（ｆ）に指定された処理要求について、Ｗｅｂアプリ２２ｂが対応可能であるか否かを判定する（Ｓ２０６）。ここでは、「ＣａｒｄＬｏｇｉｎ」が対応不可要求記憶部２２３に記録されていることとする。したがって、対応可否判定部２２２は、当該処理要求を対応不可であると判定する。そこで、対応可否判定部２２２は、リダイレクト命令を生成する。当該リダイレクト命令において、リダイレクト先は、例えば、次のようなＵＲＬとされる。

ｈｔｔｐ：／／＜ＩＰ２：ＰＯＲＴ２＞／ＣａｒｄＡｕｔｈＡｐｌ／ＣａｒｄＬｏｇｉｎ？ｒｅｔｕｒｎｐａｔｈ＝＜ＩＰ１：ＰＯＲＴ１＞／ａｕｔｈｗｅｂａｐｌ ・・・（ｇ）
ＵＲＬ（ｇ）は、ＵＲＬ（ｆ）の＜ＩＰ１：ＰＯＲＴ１＞及びａｕｔｈｗｅｂａｐｌが、＜ＩＰ２：ＰＯＲＴ２＞又はＣａｒｄＡｕｔｈＡｐｌに置換されたものである。＜ＩＰ２：ＰＯＲＴ２＞は、処理要求元の画像形成装置１０のＩＰアドレスと、当該画像形成装置１０のＷｅｂサーバ部１５３２のポート番号とである。また、「ＣａｒｄＡｕｔｈＡｐｌ」は、カード認証アプリ１５２ｂの識別子である。すなわち、ＵＲＬ（ｇ）を含むリダイレクト命令は、Ｗｅｂアプリ２２ｂが対応できない処理要求「ＣａｒｄＬｏｇｉｎ」について、カード認証アプリ１５２ｂへの委譲要求に相当する。Ｗｅｂアプリ２２ｂが対応できない処理要求の委譲先（「ＣａｒｄＡｕｔｈＡｐｌ」）は、Ｗｅｂアプリ２２ｂ（の対応可否判定部２２２）にロジックとして実装されていてもよい。または、処理要求の識別子ごとに委譲先の識別子がファイル等に記録されていてもよい。

なお、ＵＲＬ（ｇ）には、「ｒｅｔｕｒｎｐａｔｈ＝＜ＩＰ１：ＰＯＲＴ１＞／ａｕｔｈｗｅｂａｐｌ」が付与されている。これは、第一の実施の形態と同様、カード認証アプリ１５２ｂに対して、表示対象のＷｅｂページの遷移先を通知するための情報である。

続いて、通信制御部２１は、生成されたリダイレクト命令を含む応答を、機器ブラウザ１５４に返信する（Ｓ２０７）。機器ブラウザ１５４は、受信されたリダイレクト命令が示すＵＲＬ（ｇ）宛に、要求（ＨＴＴＰリクエスト）を送信する（Ｓ２０８）。要求元の機器ブラウザ１５４と同一の画像形成装置１０内のＷｅｂサーバ部１５３２によって受信される。Ｗｅｂサーバ部１５３２は、ＵＲＬ（ｇ）に含まれる「ＣａｒｄＡｕｔｈＡｐｌ」に対応するカード認証アプリ１５２ｂを起動する（Ｓ２０９）。この際、カード認証アプリ１５２ｂには、ＵＲＬ（ｇ）が伝達（入力）される。

続いて、カード認証アプリ１５２ｂは、ＵＲＬ（ｇ）に係る要求（ＨＴＴＰリクエスト）が同一画像形成装置１０内からのものであるか否かを判定する（Ｓ２１０）。当該判定方法は、第一の実施の形態と同様でよい。

ＵＲＬ（ｇ）に係る要求が同一画像形成装置１０内からのものである場合、カード認証アプリ１５２ｂのカード認証部１６３は、ＵＲＬ（ｇ）における処理要求（「ＣａｒｄＬｏｇｉｎ」）に応じ、カードＩＤ取得アプリ１５２ｃにカードＩＤの取得を要求する（Ｓ２１１）。カードＩＤ取得アプリ１５２ｃは、要求に応じ、カードリーダにセットされているカードよりカードＩＤを取得するための処理を制御する（Ｓ２１２）。この際、カードＩＤ取得アプリ１５２ｃは、例えば、カードＩＤを取得するためのＳＤＫＡＰＩを呼び出す（Ｓ２１３）。当該ＳＤＫＡＰＩの呼び出しに応じ、クラスライブラリ１５３１において当該ＳＤＫＡＰＩの実装に相当する部分（クラス）は、カードＩＤの取得処理を実行する。続いて、カードＩＤ取得アプリ１５２ｃは、取得されたカードＩＤをカード認証アプリ１５２ｂに出力する（Ｓ２１４）。

続いて、カード認証アプリ１５２ｂは、カードＩＤをユーザ名及びパスワードに置換し、当該ユーザ名及びパスワードに基づく認証を、認証アプリ１５２ｄに要求する（Ｓ２１５）。認証アプリ１５２ｄは、要求に応じ、ユーザ名及びパスワードに基づく認証処理を制御する（Ｓ２１６）。この際、認証アプリ１５２ｄは、例えば、認証用のＳＤＫＡＰＩを呼び出す（Ｓ２１７）。当該ＳＤＫＡＰＩの呼び出しに応じ、クラスライブラリ１５３１において当該ＳＤＫＡＰＩの実装に相当する部分（クラス）は、認証処理を実行する。続いて、認証アプリ１５２ｄは、認証結果（認証の成否を示す情報）をカード認証アプリ１５２ｂに出力する（Ｓ２１８）。

続いて、カード認証アプリ１５２ｂのインタフェース部１６１ｂは、ＵＲＬ（ｇ）の「ｒｅｔｕｒｎｐａｔｈ＝＜ＩＰ１：ＰＯＲＴ１＞／ａｕｔｈｗｅｂａｐｌ」に基づいて、以下のＵＲＬをリダイレクト先とするリダイレクト命令をＷｅｂサーバ部１５３２に出力する（Ｓ２１９）。

ｈｔｔｐ：／／＜ＩＰ１：ＰＯＲＴ１＞／ａｕｔｈｗｅｂａｐｌ／ｌｏｇｉｎｓｕｃｃｅｓｓ．ｈｔｍｌ ・・・（ｈ）
ここで、末尾の「ｌｏｇｉｎｓｕｃｃｅｓｓ．ｈｔｍｌ」は、インタフェース部１６１ｂが、認証結果に応じて付加したものである。ここでは、認証に成功した場合の例が示されている。すなわち、「ｌｏｇｉｎｓｕｃｃｅｓｓ．ｈｔｍｌ」は、認証に成功した場合に遷移する画面の識別子である。例えば、認証に失敗した場合、認証エラーを示す画面の識別子（例えば、「ｌｏｇｉｎｅｒｒｏｒ．ｈｔｍｌ」）が、「ｌｏｇｉｎｓｕｃｃｅｓｓ．ｈｔｍｌ」の代わりにＵＲＬ（ｈ）に付加される。

続いて、Ｗｅｂサーバ部１５３２は、当該リダイレクト命令を含む応答（ＨＴＴＰレスポンス）を、機器ブラウザ１５４に返信する（Ｓ２２０）。続いて、機器ブラウザ１５４は、受信されたリダイレクト命令が示すＵＲＬ（ｈ）宛に、要求（ＨＴＴＰリクエスト）を送信する（Ｓ２２１）。当該要求に応じて、Ｗｅｂアプリ２２ｂによって、「ｌｏｇｉｎｓｕｃｃｅｓｓ．ｈｔｍｌ」又は「ｌｏｇｉｎｅｒｒｏｒ．ｈｔｍｌ」によって識別される画面を表示させるＷｅｂページが生成され、機器ブラウザ１５４に返信される（Ｓ２１５）。機器ブラウザ１５４は、当該Ｗｅｂページに基づいて、認証成功時又は認証失敗時の画面を操作パネル１５に表示させる。

上述したように、第二の実施の形態においても、第一の実施の形態と同様の効果を得ることができる。すなわち、第一の実施の形態において説明した事項は、特定の機能（ＳＤＫＣＡＰＩ）に関して有効な事項ではなく、汎用的に有効な事項である。

なお、各実施の形態では、Ｗｅｂサーバ装置２０が、画像形成装置１０から独立している例を示したが、Ｗｅｂサーバ装置２０の有する機能が、画像形成装置１０内に実装されていてもよい。この場合、図７又は図１１において説明した処理手順は、一つの画像形成装置１０内において行われる。

また、図７のステップＳ１０８又は図１１のステップＳ２０８におけるＨＴＴＰリクエストは、必ずしもリダイレクト命令によって実行されなくてもよい。例えば、状態設定画面５１０の禁止ボタン５１１に、ＵＲＬ（ｃ）（ロック状態設定アプリ１５２ａに対する省エネ状態移行のロック要求を示すＵＲＬ）が関連付けられていてもよい。この場合、禁止ボタン５１１の押下に応じて、機器ブラウザ１５４は、同一の画像形成装置１０のＷｅｂサーバ部１５３２宛にＵＲＬ（ｃ）に係るＨＴＴＰリクエストを送信することになる。

同様に、認証方法選択画面のカード認証ボタンに、ＵＲＬ（ｇ）（カード認証アプリ１５２ｂに対するカード認証の実行要求を示すＵＲＬ）が関連付けられていてもよい。この場合、カード認証ボタンの押下に応じて、機器ブラウザ１５４は、同一の画像形成装置１０のＷｅｂサーバ部１５３２宛にＵＲＬ（ｇ）に係るＨＴＴＰリクエストを送信することになる。

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

１０ 画像形成装置
１１ コントローラ
１２ スキャナ
１３ プリンタ
１４ モデム
１５ 操作パネル
１６ ネットワークインタフェース
１７ ＳＤカードスロット
２０ Ｗｅｂサーバ装置
２１ 通信制御部
２２ Ｗｅｂアプリ
８０ ＳＤカード
１１１ ＣＰＵ
１１２ ＲＡＭ
１１３ ＲＯＭ
１１４ ＨＤＤ
１１５ ＮＶＲＡＭ
１５１ 標準アプリ
１５２ ＳＤＫアプリ
１５２ａ ロック状態設定アプリ
１５２ｂ カード認証アプリ
１５２ｃ カードＩＤ取得アプリ
１５２ｄ 認証アプリ
１５３ ＳＤＫプラットフォーム
１５４ 機器ブラウザ
１５５ ｌｉｂｗｗｗ
１５６ ＶＡＳ
１５７ コントロールサービス
１５８ ＯＳ
１６１ａ インタフェース部
１６１ｂ インタフェース部
１６２ ロック状態設定部
１６３ カード認証部
２００ ドライブ装置
２０１ 記録媒体
２０２ 補助記憶装置
２０３ メモリ装置
２０４ ＣＰＵ
２０５ インタフェース装置
２２１ Ｗｅｂページ生成部
２２２ 対応可否判定部
２２３ 対応不可要求記憶部
１５１１ スキャンアプリ
１５１２ 印刷アプリ
１５１３ コピーアプリ
１５１４ ＦＡＸアプリ
１５３１ クラスライブラリ
１５３２ Ｗｅｂサーバ部
Ｂ バス

特開２００６−３５２８４５号公報

Claims (12)

1. アプリケーションプログラムをインストール可能な画像形成装置と、該画像形成装置にネットワークを介して接続される情報処理装置とを含む情報処理システムであって、
   前記画像形成装置は、
   Ｗｅｂページを表示させるＷｅｂページ表示制御部と、
   前記アプリケーションプログラムより呼び出し可能なインタフェースを有するプラットフォーム部とを有し、
   前記表示制御部は、表示中のＷｅｂページにおいて操作対象とされた部分に関連付けられている識別子を含む第一の要求を前記情報処理装置に送信し、該情報処理装置より返信されるリダイレクト命令に基づく第二の要求を前記プラットフォーム部に送信し、
   前記プラットフォーム部は、前記第二の要求に含まれる前記識別子に対応した前記アプリケーションプログラムを呼び出し、
   呼び出されたアプリケーションプログラムは、前記インタフェースを呼び出す情報処理システム。
2. 前記プラットフォーム部は、前記第二の要求に含まれる前記識別子に対応し、前記インタフェースと一対一に対応する前記アプリケーションプログラムを呼び出す請求項１記載の情報処理システム。
3. 前記情報処理装置は、
   当該情報処理装置では対応できない要求の識別情報を記憶した記憶部と、
   前記記憶部を参照して、前記第一の要求に対する対応の可否を判定する対応可否判定部とを有し、
   前記対応可否判定部によって前記第一の要求に対応できないと判定された場合に、前記リダイレクト命令を返信する請求項１又は２記載の情報処理システム。
4. アプリケーションプログラムをインストール可能な画像形成装置であって、
   Ｗｅｂページを表示させるＷｅｂページ表示制御部と、
   前記アプリケーションプログラムより呼び出し可能なインタフェースを有するプラットフォーム部とを有し、
   前記表示制御部は、表示中のＷｅｂページにおいて操作対象とされた部分に関連付けられている識別子を含む要求を前記プラットフォーム部に送信し、
   前記プラットフォーム部は、前記要求に含まれる前記識別子に対応した前記アプリケーションプログラムを呼び出し、
   呼び出されたアプリケーションプログラムは、前記インタフェースを呼び出す画像形成装置。
5. 前記表示制御部は、表示中のＷｅｂページにおいて操作対象とされた部分に関連付けられている識別子を含む第一の要求を、ネットワークを介して接続される情報処理装置に送信し、該情報処理装置より返信されるリダイレクト命令に基づく第二の要求を前記プラットフォーム部に送信する請求項４記載の画像形成装置。
6. 前記プラットフォーム部は、前記要求に含まれる前記識別子に対応し、前記インタフェースと一対一に対応する前記アプリケーションプログラムを呼び出す請求項４又は５記載の画像形成装置。
7. アプリケーションプログラムをインストール可能であり、Ｗｅｂページを表示させるＷｅｂページ表示制御部と、前記アプリケーションプログラムより呼び出し可能なインタフェースを有するプラットフォーム部とを有を有する画像形成装置が実行する情報処理方法であって、
   前記表示制御部が、表示中のＷｅｂページにおいて操作対象とされた部分に関連付けられている識別子を含む要求を前記プラットフォーム部に送信する手順と、
   前記プラットフォーム部が、前記要求に含まれる前記識別子に対応した前記アプリケーションプログラムを呼び出す手順と、
   呼び出されたアプリケーションプログラムが、前記インタフェースを呼び出す手順とを有する情報処理方法。
8. 前記表示制御部は、表示中のＷｅｂページにおいて操作対象とされた部分に関連付けられている識別子を含む第一の要求を、ネットワークを介して接続される情報処理装置に送信し、該情報処理装置より返信されるリダイレクト命令に基づく第二の要求を前記プラットフォーム部に送信する請求項７記載の情報処理方法。
9. 前記プラットフォーム部は、前記要求に含まれる前記識別子に対応し、前記インタフェースと一対一に対応する前記アプリケーションプログラムを呼び出す請求項７又は８記載の情報処理方法。
10. アプリケーションプログラムをインストール可能な画像形成装置を、
    Ｗｅｂページを表示させるＷｅｂページ表示制御部と、
    前記アプリケーションプログラムより呼び出し可能なインタフェースを有するプラットフォーム部として機能させ、
    前記表示制御部は、表示中のＷｅｂページにおいて操作対象とされた部分に関連付けられている識別子を含む要求を前記プラットフォーム部に送信し、
    前記プラットフォーム部は、前記要求に含まれる前記識別子に対応した前記アプリケーションプログラムを呼び出し、
    呼び出されたアプリケーションプログラムは、前記インタフェースを呼び出すプログラム。
11. 前記表示制御部は、表示中のＷｅｂページにおいて操作対象とされた部分に関連付けられている識別子を含む第一の要求を、ネットワークを介して接続される情報処理装置に送信し、該情報処理装置より返信されるリダイレクト命令に基づく第二の要求を前記プラットフォーム部に送信する請求項１０記載のプログラム。
12. 前記プラットフォーム部は、前記要求に含まれる前記識別子に対応し、前記インタフェースと一対一に対応する前記アプリケーションプログラムを呼び出す請求項１０又は１１記載のプログラム。

Images