JP2015222557A - 情報処理装置、情報処理方法、プログラム及び情報処理システム - Google Patents

Abstract

【課題】サービスが利用する機能が追加された場合、この追加された機能のインタフェース情報を追加することができる情報処理装置、情報処理方法、プログラム及び情報処理システムを提供する。
【解決手段】ネットワークを介して接続された機器からの要求に応じて所定の機能を利用したサービスを提供する画像処理装置１０であって、サービスとサービスが利用する機能毎に、機器から機能を利用したサービスの要求を受け付けるためのインタフェース情報を含む、機能に関する情報を記憶させる機能記憶手段(ＡＰＩ管理部４２３）と、機能に関する情報に含まれるインタフェース情報毎に機器からの要求を受け付けるインタフェース手段（ＷｅｂＡＰＩ４１０）と、を有する。機能記憶手段は、サービスが利用する機能が追加された場合、追加された機能に関する情報を記憶させる。
【選択図】図４

Description

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

自身の機能をネットワークに接続されたＰＣなどから利用するためのＡＰＩ（Application Program Interface）を備えた、情報処理装置の一例としての画像処理装置は既に知られている（例えば特許文献１参照）。

しかしながら、上記従来技術においては、情報処理装置に機能を追加するたびに、追加した機能を利用するためのＡＰＩを作成する必要があった。したがって、追加した機能に関係のない機能を利用するためのＡＰＩも含めてオブジェクトを再作成しなければならなかった。

本発明の一実施形態は、上記の点に鑑みてなされたもので、サービスが利用する機能が追加された場合、この追加された機能のインタフェース情報を追加することを目的とする。

上記目的を達成するため、本発明の一実施形態は、ネットワークを介して接続された機器からの要求に応じて所定の機能を利用したサービスを提供する情報処理装置であって、前記サービスと該サービスが利用する機能毎に、前記機器から前記機能を利用したサービスの要求を受け付けるためのインタフェース情報を含む、前記機能に関する情報を記憶させる機能記憶手段と、前記機能に関する情報に含まれるインタフェース情報毎に前記機器からの要求を受け付けるインタフェース手段と、を有し、前記機能記憶手段は、前記サービスが利用する機能が追加された場合、該追加された機能に関する情報を記憶させる、ことを特徴とする。

本発明の一実施形態によれば、サービスが利用する機能が追加された場合、この追加された機能のインタフェース情報を追加することができる。

第１の実施形態に係る画像処理システムの一例の構成図である。 第１の実施形態に係る画像処理装置の一例のハードウェア構成図である。 第１の実施形態に係るＰＣの一例のハードウェア構成図である。 第１の実施形態に係る画像処理装置の一例の機能構成図である。 第１の実施形態に係る画像処理装置の処理の一例を説明する説明図である。 リソース情報の一例の構成図である。 サービス提供処理の一例のシーケンス図である。 リクエスト及びレスポンスの一例の説明図である。 ＵＲＬの一例の説明図である。 第１の実施形態に係るリソース情報追加／削除処理の一例のシーケンス図である。 第１の実施形態に係るアプリケーションインストール処理の一例のシーケンス図である。 第１の実施形態に係るアプリケーションアンインストール処理の一例のシーケンス図である。 第２の実施形態に係る画像処理装置の一例の機能構成図である。 第２の実施形態に係るＰＣの一例の機能構成図である。 第２の実施形態に係る画像処理装置の処理の一例を説明する説明図である。 リソース情報の他の例の構成図である。 第２の実施形態に係るリソース情報追加／削除処理の一例のシーケンス図である。 第２の実施形態に係るＡＰＩリスト表示処理の一例のシーケンス図である。 ＡＰＩリストの一例を説明するための説明図である。 第２の実施形態に係るリソース情報取得処理の一例のフローチャートである。 第３の実施形態に係るリソース情報取得処理の一例のフローチャートである。 第４の実施形態に係る画像処理装置の一例のハードウェア構成図である。 第４の実施形態に係る画像処理装置の一例の機能構成図である。 第４の実施形態に係る画像処理装置の起動時の処理の一例のシーケンス図である。 第４の実施形態に係る認証要否判定処理の一例のフローチャートである。

次に、本発明の実施の形態について、詳細に説明する。なお、以下では、本発明に係る情報処理装置を、ＭＦＰ（Multifunction Peripheral）等の画像処理装置に適用した場合の実施形態について説明する。ただし、本発明に係る情報処理装置の適用先は、これに限定されるものではなく、画像処理装置以外に適用してもよい。

［第１の実施形態］
＜システム構成＞
図１は、第１の実施形態に係る画像処理システムの一例の構成図である。図１の画像処理システムは、１台以上の画像処理装置１０、１台以上のＰＣ（パーソナルコンピュータ）２０が、ネットワークＮ１に有線や無線で接続されている。

画像処理装置１０は、情報処理装置の一例である。画像処理装置１０は、ＰＣ２０や他の画像処理装置１０などの機器からの要求に応じて、コピー、ファックス、プリンタ、スキャナなどの画像処理に係るサービスを提供するＭＦＰである（ただし、画像処理装置１０はＭＦＰに限定されるものではない）。また、画像処理装置１０は、ＰＣ２０や他の画像処理装置１０などの機器がこれらのサービスを利用するためのＡＰＩを有する。画像処理装置１０は、これらのサービスが利用する機能を追加・削除することができる。また、画像処理装置１０は、画像処理に係るサービスを提供するためのアプリケーションをインストール又はアンインストールすることにより、サービスを追加・削除することができる。

すなわち、画像処理装置１０は、サービス（例えばコピーアプリケーション）の追加・削除、及びサービスが利用する機能（例えば両面コピー、２ｉｎ１コピーなど）の追加・削除を行うことができる。

ＰＣ２０は、機器の一例である。ＰＣ２０は、ＰＣ（パーソナルコンピュータ）の他、タブレット端末、スマートフォンや携帯電話、ＰＤＡなどの携帯情報端末、電子ホワイトボード等の表示装置、プロジェクタ等の投影装置、画像処理装置１０と連携したサービスを提供するためのクラウドサーバなどでもよい。ＰＣ２０は画像処理装置１０に画像処理に係るサービスの提供を要求することができる。

なお、本発明における情報処理装置は、図１の画像処理システムのように、画像処理装置１０以外の機器からサービスの要求を受ける画像処理装置１０に限らない。例えば、画像処理装置１０が、互いに独立したＯＳを搭載した画像処理装置本体と操作部とが有線や無線で接続された構成となっており、画像処理装置本体が操作部からサービスの要求を受けるものであってもよい。つまり、画像処理装置本体が、ネットワークを介して接続された機器である操作部からサービスの要求を受けるものであり、この画像処理装置本体を本発明における情報処理装置として捉えることもできる。

＜ハードウェア構成＞
《画像処理装置》
画像処理装置１０は、例えば図２に示すようなハードウェア構成により実現される。図２は、第１の実施形態に係る画像処理装置の一例のハードウェア構成図である。

図２に示すように、画像処理装置１０は操作部２００と本体部２１０を有する。

操作部２００は、ＬＣＤデバイスやタッチパネル、ハードキーなどを備えるユーザインタフェースであり、画像処理装置１０に対して、ユーザが各種データの設定、登録を行う際に操作する。

本体部２１０は、コントローラ２２０と、ファックス制御ユニット２４０と、エンジン群２５０とを有する。更に、ファックス制御ユニット２４０は、Ｇ３規格対応ユニット２４１と、Ｇ４規格対応ユニット２４２とを有する。また、エンジン群２５０は、プロッタエンジン２５１と、スキャナエンジン２５２と、その他のハードウェアリソース２５３とを有する。

コントローラ２２０は、ＣＰＵ２２１と、ＡＳＩＣ２２２と、ＨＤＤ（Hard Disk Drive）２２３と、システムメモリ（ＭＥＭ−Ｐ）２２４と、ローカルメモリ（ＭＥＭ−Ｃ）２２５と、ノースブリッジ（以下、ＮＢと記す）２２６とを有する。また、シリアルバス２２７と、ＮＩＣ（Network Interface Card）２２８と、ＵＳＢデバイス２２９とを有する。更に、ＩＥＥＥ８０２．１１ｂデバイス２３０と、ＩＥＥＥ１３９４デバイス２３１と、ＵＳＢホスト２３２と、メモリカードＩ／Ｆ２３３とを有する。

また、シリアルバス２２７、ＮＩＣ２２８、ＵＳＢデバイス２２９、ＩＥＥＥ８０２．１１ｂデバイス２３０、ＩＥＥＥ１３９４デバイス２３１、ＵＳＢホスト２３２、及びメモリカードＩ／Ｆ２３３は、ＮＢ２２６にＰＣＩバスを介して接続されている。

なお、コントローラ２２０において、ＡＳＩＣ２２２には、ローカルメモリ２２５、ＨＤＤ２２３等が接続されている。また、ＣＰＵ２２１とＡＳＩＣ２２２とは、ＣＰＵチップセットのＮＢ２２６を介して接続されている。更に、ファックス制御ユニット２４０及びエンジン群２５０は、ＡＳＩＣ２２２にＰＣＩバスを介して接続されている。

ＣＰＵ２２１は、画像処理装置１０の全体を制御するものである。ＣＰＵ２２１は、後述する各種サービスを起動して実行する。

ＮＢ２２６は各要素を接続するためのブリッジである。具体的には、ＣＰＵ２２１、システムメモリ２２４、ＡＳＩＣ２２２、シリアルバス２２７、ＮＩＣ２２８、ＵＳＢデバイス２２９を接続する。更に、ＩＥＥＥ８０２．１１ｂデバイス２３０、ＩＥＥＥ１３９４デバイス２３１、ＵＳＢホスト２３２、及びメモリカードＩ／Ｆ２３３を接続する。

システムメモリ２２４は、画像処理装置１０の描画用メモリ等として用いるメモリである。また、ローカルメモリ２２５は、コピー用画像バッファ、符号バッファ等として用いるメモリである。

ＡＳＩＣ２２２は、画像処理用のハードウェア要素を有する画像処理用途向けのＩＣ（Integrated Circuit）である。また、ＨＤＤ２２３は、各種情報を蓄積するためのストレージである。なお、ＨＤＤ２２３に蓄積される情報には、例えば、ファクシミリ送信のための宛先データや電子メールの宛先データ（すなわち、アドレス帳データ）が含まれる。また、ファクシミリ送信や電子メール送信等の送信履歴を記憶するための履歴データや、プリントジョブのデータである蓄積画像データや蓄積文書データが含まれる。その他、課金データやユーザ認証を行うためのユーザ認証情報、各種プログラム、フォントデータ、フォームデータ等が含まれる。

シリアルバス２２７、ＮＩＣ２２８、ＵＳＢデバイス２２９、ＩＥＥＥ８０２．１１ｂデバイス２３０、ＩＥＥＥ１３９４デバイス２３１、ＵＳＢホスト２３２、メモリカードＩ／Ｆ２３３は、各々が対応する規格の可搬型記憶装置と接続するインタフェースである。例えば、図２に示すように、ＵＳＢホスト２３２には、ＵＳＢメモリ２６１を接続することができ、メモリカードＩ／Ｆ２３３には、メモリカード２６２を接続することができる。

《ＰＣ》
ＰＣ２０は、例えば図３に示すようなハードウェア構成により実現される。図３は、第１の実施形態に係るＰＣの一例のハードウェア構成図である。

図３に示したＰＣ２０は、入力装置１０１、表示装置１０２、外部Ｉ／Ｆ１０３、ＲＡＭ（Random Access Memory）１０４、ＲＯＭ（Read Only Memory）１０５、ＣＰＵ１０６、通信Ｉ／Ｆ１０７、及びＨＤＤ１０８などを備え、それぞれがバスＢで相互に接続されている。

入力装置１０１は、キーボードやマウス、タッチパネルなどを含み、ＰＣ２０に各操作信号を入力するのに用いられる。

表示装置１０２は、ＬＣＤ（Liquid Crystal Display）やＣＲＴ（Cathode Ray Tube）などを含み、ＰＣ２０による処理結果を表示する。

外部Ｉ／Ｆ１０３は、外部装置とのインタフェースである。外部装置には、記録媒体１０３ａなどがある。記憶媒体１３０ａには、実施形態を実現するプログラムを格納することができる。ＰＣ２０は外部Ｉ／Ｆ１０３を介して、記録媒体１０３ａの読み取り及び／又は書き込みを行うことができる。

記録媒体１０３ａにはＵＳＢメモリ、ＳＤメモリカード（SD Memory card）、ＤＶＤ（Digital Versatile Disk）、ＣＤ（Compact Disk）、フレキシブルディスクなどの記録媒体を用いることができる。

ＲＡＭ１０４は、プログラムやデータを一時保持する揮発性の半導体メモリ（記憶装置）である。

ＲＯＭ１０５は、電源を切ってもプログラムやデータを保持することができる不揮発性の半導体メモリ（記憶装置）である。ＲＯＭ１５１には、ＰＣ２０の起動時に実行されるＢＩＯＳ（Basic Input/Output System）、ＯＳ（Operating System）設定、及びネットワーク設定などのプログラムやデータが格納されている。

ＣＰＵ１０６は、ＲＯＭ１０５やＨＤＤ１０８などの記憶装置からプログラムやデータをＲＡＭ１０４上に読み出し、処理を実行することで、ＰＣ２０全体の制御や機能を実現する演算装置である。

通信Ｉ／Ｆ装置１０７は、ネットワークに接続するインタフェースである。これにより、ＰＣ２０は通信Ｉ／Ｆ装置１０７を介してデータ通信を行うことができる。

ＨＤＤ１０８は、プログラムやデータを格納している不揮発性の記憶装置である。格納されるプログラムやデータには、例えば、ＰＣ２０全体を制御する基本ソフトウェアであるＯＳや、ＯＳ上において各種機能を提供するアプリケーションソフトウェアなどがある。ＨＤＤ１５２は格納しているプログラムやデータを所定のファイルシステム及び／又はＤＢ（Data Base）により管理している。

ＰＣ２０、例えば上記のハードウェア構成により、後述するような各種処理を実現できる。

＜機能構成＞
次に、画像処理装置１０の機能構成について説明する。図４は、第１の実施形態に係る画像処理装置の一例の機能構成図である。図４に示すように、画像処理装置１０は、大別するとソフトウェア群４０１と、ハードウェア資源４０２とに分けられる。

ソフトウェア群４０１は、アプリケーション層４０３とサービスモジュール層４０４を有する。

アプリケーション層４０３は、コピー、ファックス、プリンタ、及びスキャナ等の画像処理に係るサービスとして、それぞれ固有の処理を行うプログラムを有する。ここで、図４に示すアプリケーション層４０３には、例えば、コピー用のアプリケーションであるコピーアプリケーション４３１、ファックス用のアプリケーションであるファックスアプリケーション４３２、プリンタ用のアプリケーションであるプリンタアプリケーション４３３、スキャナ用のアプリケーションであるスキャナアプリケーション４３４が含まれる。

サービスモジュール層４０４は、アプリケーション層４０３の各アプリケーションからの処理要求を解釈して共通の機能や制御を行うモジュールを有する。また、サービスモジュール層４０４は、アプリケーション層４０３の各アプリケーションからの処理要求を解釈してハードウェア資源４０２の獲得要求を発生し、獲得したハードウェア資源４０２の管理等を行うモジュールを有する。これらのサービスモジュール層４０４の各モジュールは、予め定義された関数等によりアプリケーション層４０３からの処理要求を受信する内部ＡＰＩ４４０を介して、アプリケーション層４０３の各アプリケーションから利用することができる。

ここで、図４に示すサービスモジュール層４０４には、例えば、システム制御サービス４５１、ファックス制御サービス４５２、エンジン制御サービス４５３、メモリ制御サービス４５４、ネットワーク制御サービス４５５、ログ制御サービス４５６、電源制御サービス４５７、認証制御サービス４５８、アドレス帳管理サービス４５９が含まれる。

ここで、ソフトウェア群４０１は、ＯＳ（Operating System）４６０上において実行される。ＯＳ４６０は、アプリケーション層４０３及びサービスモジュール層４０４のソフトウェア群４０１のそれぞれのソフトウェアをプロセスとして並列実行する。

なお、ソフトウェア群４０１が有する各種サービスは、それぞれ１以上の機能を有している。この機能のことをリソースと称する。例えばコピーアプリケーション４３１は、片面コピーを行うためのリソース、両面コピーを行うためのリソース、２ｉｎ１コピーを行うためのリソースなどを有している。また、例えばアドレス帳管理サービス４５９は、アドレス帳のアドレスを全件取得するためのリソース、アドレス帳のアドレスを１件取得するためのリソース、アドレス帳の状態を取得するためのリソースなどを有している。

ＰＣ２０や他の画像処理装置１０は、ソフトウェア群４０１によって実現される各種サービスを、ＰＣ２０や他の画像処理装置１０からの処理要求を受信するＷｅｂＡＰＩ４１０を介して利用することができる。

フレームワーク４２０は、ＷｅｂＡＰＩ４１０が受信したＰＣ２０や他の画像処理装置１０からの処理要求を解釈し、ソフトウェア群４０１の各種サービスに対して処理要求を行う。フレームワーク４２０は、要求管理部４２１、ＡＰＩ制御部４２２、ＡＰＩ管理部４２３、結果応答部４２４を有する。

ＷｅｂＡＰＩ４１０は、例えば外部の機器が各種サービスや各種リソースを利用するためのＡＰＩの集まりである。

要求管理部４２１は、ＷｅｂＡＰＩ４１０から処理要求を受信し、ＡＰＩ制御部４２２に処理を依頼する。また、要求管理部４２１は、結果応答部４２４から処理結果を受信し、ＷｅｂＡＰＩ４１０に処理結果を送信する。

ＡＰＩ制御部４２２は、ＡＰＩ管理部４２３からリソース情報（機能情報）を取得し、ソフトウェア群４０１の各種サービスに処理を要求する。ここで、リソース情報とは、ソフトウェア群４０１の各アプリケーションや各モジュールが、要求された機能を実行するために利用するリソース（機能）に関する情報である。リソース情報の詳細については後述する。

ＡＰＩ管理部４２３は、リソース情報の登録要求があった場合、リソース情報を画像処理装置１０のフレームワーク４２０の記憶領域に記憶する。また、ＡＰＩ管理部４２３は、リソース情報の取得要求があった場合、リソース情報を画像処理装置１０のフレームワーク４２０の記憶領域から取得する。結果応答部４２４は、ソフトウェア群４０１の各アプリケーションや各モジュールが実行した機能の結果を作成し、要求管理部４２１に送信する。

また、エンジンＩ／Ｆ４７０は、ソフトウェア群４０１のそれぞれのソフトウェアにより予め定義されている関数等によりエンジン制御ボード４８０を介してハードウェア資源４０２に対する獲得要求を送信する。

ここで、図４に示すハードウェア資源４０２には、例えばプロッタエンジン２５１、スキャナエンジン２５２、その他のハードウェアリソース２５３が含まれる。

＜処理の概要＞
次に、第１の実施形態に係る画像処理装置の処理の概要について説明する。図５は、第１の実施形態に係る画像処理装置の処理の一例を説明する説明図である。

図５（ａ）は、例えばＰＣ２０や他の画像処理装置１０などからサービスの提供要求あった場合の画像処理装置１０の処理の一例を説明する説明図である。

まず、画像処理装置１０のＷｅｂＡＰＩ４１０は、例えばＰＣ２０や他の画像処理装置１０などから、サービスとこのサービスが利用するリソース（機能）とを指定したＨＴＴＰ（HyperText Transfer Protocol）リクエストを受信する。サービスは、ソフトウェア群４０１の各アプリケーションや各モジュールのことであり、例えばファックスアプリケーション４３２やアドレス帳管理サービス４５９である。リソースは、ソフトウェア群４０１の各アプリケーションや各モジュールが実行する機能のことであり、例えばアドレス帳管理サービス４５９においてアドレス帳のアドレスを全件取得する機能である。ユーザが例えばファックス操作においてファックスの送信先アドレス一覧を取得したい場合、サービスとしてアドレス帳管理サービス４５９、リソースとしてアドレス帳一覧を取得する機能（アドレス帳の取得（全件））を指定することでアドレス帳のアドレス一覧を取得することができる。

次に、要求管理部４２１はＷｅｂＡＰＩ４１０から呼び出されるとＨＴＴＰリクエストを受け取り、ＡＰＩ制御部４２２に処理要求を行う。そして、ＡＰＩ制御部４２２はＡＰＩ管理部４２３を介してリソース情報を取得し、ＨＴＴＰリクエストにより呼び出されたＡＰＩ（ＷｅｂＡＰＩ４１０）を特定する。なお、ＡＰＩの特定には、リソース情報に含まれるＵＲＬで判断する。リソース情報の詳細については後述する。

ＡＰＩ制御部４２２は該当のサービスに対して、リソースを指定（図５（ａ）の例では、サービス１に対してリソースＡを指定）して操作要求を行う。そして、サービスは、応答要求を結果応答部４２４に行う。

結果応答部４２４はＨＴＴＰレスポンスを作成し、要求管理部４２１に送信要求を行う。要求管理部４２１は、結果応答部４２４からＨＴＴＰレスポンスを受け取ると、ＷｅｂＡＰＩ４１０を介してＰＣ２０などにＨＴＴＰレスポンスを送信する。

図５（ｂ）は、画像処理装置１０にサービスやリソースの登録をする場合の画像処理装置１０の処理の一例を説明する説明図である。図５（ｂ）では、画像処理装置１０にリソースＣを有するサービス２を新たに登録する場合について説明する。

ユーザは例えばネットワークなどを介して、リソースＣを有するサービス２を画像処理装置１０にインストールする。すると、ＡＰＩ管理部４２３は、リソースＣのリソース情報を画像処理装置１０の記憶領域に登録する。リソース情報を登録することで、このリソース情報に含まれるＵＲＬをＰＣ２０や他の画像処理装置１０から利用可能なＡＰＩとして提供することができる。

これにより、画像処理装置１０に新たにサービスやリソースが追加された場合、追加されたリソースに関するリソース情報をＡＰＩ管理部４２３を介して記憶領域に登録することで、外部から利用可能なＡＰＩを提供することができる。

次に、リソース情報の詳細について説明する。図６は、リソース情報の一例の構成図である。

リソース情報は、ＵＲＬ、メソッド、システムなどのデータ項目を有する。ＵＲＬは、サービス部とリソース部などのデータ項目を有する。サービス部は、例えばプリンタアプリケーション４３３やアドレス帳管理サービス４５９などのサービスを特定する情報である。リソース部は、各サービスが有するリソースを特定する情報である。例えば、サービス部「ｐｒｉｎｔｅｒ」は、プリンタの状態を表示させる機能に関するリソース「ｓｔａｔｕｓ」と、プリントを実行する機能に関するリソース「ｊｏｂ」の２つのリソースを有する。後述するように、サービス部（サービス名）とリソース部（リソース名）とを、例えば「／」で連結させてＵＲＬ形式とすることで、外部（ＰＣ２０や他の画像処理装置１０など）から利用可能なＡＰＩとして提供することができる。なお、リソース名は、同一のサービスにおいてユニークであればよい。なお、ＵＲＬはインタフェース情報の一例である。

メソッドは、ＧＥＴ、ＰＯＳＴ、ＰＵＴ、ＤＥＬＥＴＥなどのデータ項目を有する。これらの項目は、リソース部で指定されたリソースを利用したサービスを利用したい場合に、どのメソッドが定義されたＨＴＴＰリクエストで利用することができるかを示す項目である。例えば、プリンタの状態を表示させる機能を利用したい場合（サービス部「ｐｒｉｎｔｅｒ」、リソース部「ｓｔａｔｕｓ」）、ＰＣ２０などはＧＥＴメソッドを定義したＨＴＴＰリクエストを画像処理装置１０に送信する。

一方、例えばプリンタの状態を表示させる機能を利用したい場合（サービス部「ｐｒｉｎｔｅｒ」、リソース部「ｓｔａｔｕｓ」）には、ＰＣ２０などはＰＯＳＴメソッドやＰＵＴメソッド、ＤＥＬＥＴＥメソッドを定義したＨＴＴＰリクエストを利用することはできない。なお、画像処理装置１０は、このようなＨＴＴＰリクエストを受信した場合、エラーを示すＨＴＴＰレスポンスを送信するようにしてもよい。

システムは、電力制御、認証などのデータ項目を有する。これらの項目は、リソース部で指定されたリソースを利用したサービスを利用したい場合に、必要なシステム条件を示す項目である。例えば、プリンタを表示させる機能を利用したい場合（サービス部「ｐｒｉｎｔｅｒ」、リソース部「ｓｔａｔｕｓ」）、認証が必要であることを示す。すなわち、この場合、プリンタアプリケーション４３３は内部ＡＰＩ４４０を介して認証制御サービス４５８に処理を依頼し、ユーザ認証などを行う。これにより、サービス毎、リソース毎に利用権限やアクセス権限などを設定することができる。

また、例えばプリントを実行する機能を利用する場合（サービス部「ｐｒｉｎｔｅｒ」、リソース部「ｊｏｂ」）、電力制御が必要であることを示す。すなわち、この場合、プリンタアプリケーション４３３は内部ＡＰＩ４４０を介して電源制御サービス４５７に処理を依頼し、電力制御を行う。

なお、以上に示したリソース情報のデータ項目は一例であり、他のデータ項目を有していてもよい。

＜処理の詳細＞
次に、第１の実施形態に係る画像処理装置の処理の詳細について説明する。図７は、サービス提供処理の一例のシーケンス図である。

ステップＳ１０１において、ＰＣ２０などはサービスとリソースを指定したリクエストを画像処理装置１０に送信する。そして、画像処理装置１０のＷｅｂＡＰＩ４１０はＰＣ２０などからのリクエストを受信する。以降では一例として、ＰＣ２０は、サービスとしてアドレス帳管理サービス４５９、リソースとしてアドレス帳状態を取得する機能を指定したＨＴＴＰリクエストを送信したものとする。図８（ａ）は、ＨＴＴＰリクエストの一例の説明図である。

図８（ａ）のＨＴＴＰリクエストは、リクエスト部１００１、ヘッダ部１００２を有する。リクエスト部１００１に指定された「http://192.168.1.1:8080」の部分は画像処理装置１０のＩＰアドレス（及びポート番号）である。「/rws/addressbook/status」の部分は、後述するようにサービス部とリソース部を含むリソース情報のＵＲＬを含む情報である。この情報に含まれるＵＲＬにより、ＡＰＩ制御部４２２はＡＰＩを特定し、該当のサービスの該当のリソースに操作を要求する。

なお、一般にＨＴＴＰリクエストは、リクエスト部、ヘッダ部、ボディ部から構成されている。図８（ａ）の例では、データの取得（アドレス帳状態の取得）を行うためのメソッドであるＧＥＴが指定されているため、ボディ部は定義されていない。なお、例えばアドレス帳に新たにアドレスを追加する場合は、ＨＴＴＰリクエストのリクエスト部にＰＯＳＴメソッドを指定し、ボディ部に追加するアドレスの情報（データ）をＸＭＬ（Extensible Markup Language）形式やＪＳＯＮ（JavaScript Object Notation）形式、バイナリ形式などで指定（記述）する。

ステップＳ１０２において、要求管理部４２１はＷｅｂＡＰＩ４１０からＨＴＴＰリクエストを受け取り、ＡＰＩ制御部４２２に処理要求を行う。

ステップＳ１０３において、ＡＰＩ制御部４２２はＡＰＩ管理部４２３にリソース情報の取得要求を行う。そして、ＡＰＩ管理部４２３はリソース情報を画像処理装置１０の記憶領域から取得し、この取得したリソース情報をＡＰＩ制御部４２２に送信する。

ステップＳ１０４において、ＡＰＩ制御部４２２は、ＡＰＩ管理部４２３から取得したリソース情報に基づいてＡＰＩを特定する。すなわち、ＨＴＴＰリクエストに指定されているＵＲＬとリソース情報に含まれるＵＲＬからＡＰＩを特定する。図８（ａ）の例では、ＨＴＴＰリクエストのリクエスト部の「http://192.168.1.1:8080/rws/addressbook/status」と図６のリソース情報に含まれるサービス部とリソース部からＡＰＩ（ＵＲＬ）は「addressbook/status」と特定することができる。これにより、図８（ａ）のＨＴＴＰリクエストは、アドレス帳管理サービス４５９のアドレス帳状態の取得を要求していると判断することができる。

このようにＷｅｂＡＰＩ４１０のＡＰＩを特定することで、ＡＰＩ制御部４２２は、後述の処理において操作要求を行うサービスとリソースを特定することができる。

ステップＳ１０５において、ＡＰＩ制御部４２２はＨＴＴＰリクエストを解析する。解析とは、例えばＨＴＴＰリクエストのボディ部にＸＭＬ形式やＪＳＯＮ形式などで記述されている情報をプログラム（例えばアドレス帳管理サービス４５９）が扱うことができるデータ構造に変換することをいう。

ステップＳ１０６において、ＡＰＩ制御部４２２はアドレス帳管理サービス４５９のアドレス帳状態の取得に関するリソース（リソース名「ｓｔａｔｕｓ」）に対して操作要求を行う。

ステップＳ１０７において、アドレス帳管理サービス４５９はアドレス帳状態を取得する。

ステップＳ１０８において、アドレス帳管理サービス４５９はステップＳ１０７における処理の処理結果を含む応答要求を結果応答部４２４に対して行う。

ステップＳ１０９において、結果応答部４２４は受信した処理結果を含む応答要求からＨＴＴＰレスポンスを作成する。図８（ｂ）は、ＨＴＴＰレスポンスの一例の説明図である。

図８（ｂ）のＨＴＴＰレスポンスのレスポンス部２００１にはステータスコードが記述されている。図８（ｂ）の例では、ＨＴＴＰリクエストは成功し、要求に応じた情報が返信された旨のステータスコード（２００ ＯＫ）が記述されている。ヘッダ部２００２には、このＨＴＴＰレスポンスが作成された日時やボディ部２００３で記述されているデータのデータ形式などが記述されている。ボディ部２００３では、ＨＴＴＰリクエストの要求に応じた情報が記述されている。図８（ｂ）の例では、アドレス帳状態に関する情報などが記述されている。例えばアドレス帳に５００件のデータ（エントリ）が格納されていることを示す情報（entryNum:500）などである。

ステップＳ１１０において、結果応答部４２４は作成したＨＴＴＰレスポンスの送信要求を要求管理部４２１に対して行う。

ステップＳ１１１において、要求管理部４２１はＨＴＴＰレスポンスをＷｅｂＡＰＩ４１０を介してＰＣ２０などに送信する。

以上により、画像処理装置１０の外部に存在するＰＣ２０や他の画像処理装置１０などは、画像処理装置１０に対してサービスとリソースを指定したリクエストを送信することにより、このリソースを利用したサービスを実行させることができる。言い換えれば、ＰＣ２０や他の画像処理装置１０などは、ネットワークなどを介して画像処理装置１０に搭載されている機能を利用することができる。

ここで、ＨＴＴＰリクエストのリクエスト部に指定されるリソース情報に含まれるＵＲＬについて、他の例を説明する。図９は、ＵＲＬの一例の説明図である。

例えばユーザがアドレス帳のアドレス情報を全件取得したい場合、ＨＴＴＰリクエストのリクエスト部において、ＧＥＴメソッドで画像処理装置１０のＩＰアドレス（http://192.168.1.1:8080）に続けて、「/rws/addressbook/entries」と指定すればよい。

また、例えばアドレス帳のアドレス情報を１件取得したい場合、ＨＴＴＰリクエストのリクエスト部において、ＧＥＴメソッドで画像処理装置１０のＩＰアドレス（http://192.168.1.1:8080）に続けて、「/rws/addressbook/entries/123」（「123」は、エントリＩＤなどのアドレス帳のアドレス情報を一意に識別する情報）と指定すればよい。なお、例えばアドレス帳にアドレス情報を追加する場合は、ＰＯＳＴメソッドで上記と同様に画像処理装置１０のＩＰアドレスに続けて、「/rws/addressbook/entries/234」などと指定すればよい。これにより、エントリＩＤ「２３４」のアドレス情報が追加される。また、同様に、ＰＵＴメソッドでアドレス情報の更新、ＤＥＬＥＴＥメソッドでアドレス情報の削除などを行うことができる。なお、ＰＯＳＴメソッドやＰＵＴメソッドを指定する場合、ＨＴＴＰリクエストのボディ部に追加するアドレス情報又は更新するアドレス情報を記述する。

次に、画像処理装置１０に搭載されているサービスに、新たにリソースを追加又はリソースを削除した場合の処理について説明する。図１０は、第１の実施形態に係るリソース追加／削除処理の一例のシーケンス図である。

ステップＳ２０１において、ユーザはサービスにリソースの追加又サービスからリソースの削除を行う。リソースの追加は、リソースに関する情報を例えばネットワークを介したインストールや外部記憶媒体からのインストールなどの方法により行うことができる。

ステップＳ２０２において、ユーザはリソースの追加又は削除を行ったサービスを起動する。

ステップＳ２０３において、画像処理装置１０のサービスは追加したリソースの情報の設定の追加又は削除したリソースの情報の設定の削除を行う。すなわち、サービスは追加したリソースの情報又は削除したリソースの情報を設定ファイルなどに反映させる。このように、画像処理装置１０は、サービスに対して新たにリソースを追加することにより、追加したリソースを用いた機能を提供することができるようになる。また、画像処理装置１０は、サービスからリソースを削除することにより、削除したリソースを用いた機能を削除することができる。

ステップＳ２０４において、サービスはＡＰＩ管理部４２３に対してリソース情報の登録又は削除要求を行う。

ステップＳ２０５において、ＡＰＩ管理部４２３は画像処理装置１０の記憶領域に追加したリソースのリソース情報の登録又は削除したリソースのリソース情報の削除を行う。

なお、ＡＰＩ管理部４２３は追加したリソースのリソース情報が画像処理装置１０の記憶領域に登録されている場合、リソース情報の登録を行わない。すなわち、ＡＰＩ管理部４２３はリソース情報の重複があるか否かのチェックを行い、重複したリソース情報が存在する場合、リソース情報の登録を行わない。

以上により、画像処理装置１０のサービスに新たにリソースが追加された場合、追加されたリソースのリソース情報をＡＰＩ管理部４２３を介して画像処理装置１０の記憶領域に登録することができる。これにより、このリソースを利用するための外部から利用可能なＡＰＩの追加をリソースの追加と同時に行うことができる。

また、画像処理装置１０のサービスからリソースを削除する場合、削除されたリソースのリソース情報をＡＰＩ管理部４２３を介して画像処理装置１０の記憶領域から削除することができる。これにより、このリソースを利用するための外部から利用可能なＡＰＩの削除をリソースの削除と同時に行うことができる。

次に、画像処理装置１０に新たにアプリケーションをインストールした場合の処理について説明する。図１１は、第１の実施形態に係るアプリケーションインストール処理の一例のシーケンス図である。

ステップＳ３０１において、ユーザは画像処理装置１０にアプリケーション（サービス）をインストールする。なお、アプリケーションは例えばコピーアプリケーション４３１などのサービスを提供するソフトウェアなどである。また、アプリケーション（サービス）は、例えば片面コピーを行うためのリソースなど１以上のリソースを有する。

ステップＳ３０２において、ユーザは画像処理装置１０にインストールされたアプリケーション（サービス）を起動する。

ステップＳ３０３において、アプリケーション（サービス）は、リソースの情報を設定する。このリソースの情報の設定により、例えばコピーアプリケーション４３１（サービス）において片面コピー機能（リソース）を実行することができるようになる。

ステップＳ３０４において、アプリケーション（サービス）は、ＡＰＩ管理部４２３に対してリソース情報の登録要求を行う。

ステップＳ３０５において、ＡＰＩ管理部４２３は画像処理装置１０の記憶領域にインストールしたアプリケーションのリソース情報を登録する。

なお、ＡＰＩ管理部４２３はインストールしたアプリケーション（サービス）のリソース情報が画像処理装置１０の記憶領域に登録されている場合、リソース情報の登録を行わない。すなわち、ＡＰＩ管理部４２３はリソース情報の重複があるか否かのチェックを行い、重複したリソース情報が存在する場合、リソース情報の登録を行わない。

以上により、画像処理装置１０に新たにアプリケーションをインストールし、サービスが追加された場合、このサービスが利用するリソースのリソース情報をＡＰＩ管理部４２３を介して画像処理装置１０の記憶領域に登録することができる。これにより、このリソースを利用するための外部から利用可能なＡＰＩの追加をサービスの追加と同時に行うことができる。

次に、画像処理装置１０からアプリケーションをアンインストールした場合の処理について説明する。図１２は、第１の実施形態に係るアプリケーションアンインストール処理の一例のシーケンス図である。

ステップＳ４０１において、ユーザは画像処理装置１０からアプリケーション（サービス）をアンインストールする。

ステップＳ４０２において、アプリケーション（サービス）は、ＡＰＩ管理部４２３に対してリソース情報の削除要求を行う。

ステップＳ４０３において、ＡＰＩ管理部４２３は画像処理装置１０の記憶領域からアンインストールしたアプリケーションのリソース情報を削除する。このとき、ＡＰＩ管理部４２３はアンインストールしたアプリケーション（サービス）が複数のリソースを有していた場合、すべてのリソースのリソース情報を削除する。

以上により、画像処理装置１０からアプリケーションがアンインストールされ、サービスが削除された場合、このサービスが利用するリソースのリソース情報をＡＰＩ管理部４２３を介して画像処理装置１０の記憶領域から削除することができる。これにより、このリソースを利用するための外部から利用可能なＡＰＩの削除をサービスの削除と同時に行うことができる。

＜まとめ＞
以上のように、本実施形態に係る画像処理装置１０は、ＰＣ２０や他の画像処理装置１０からの機能の実行要求に応じて、機能を実行することができる。

また、本実施形態に係る画像処理装置１０はＰＣ２０や他の画像処理装置１０からの機能の実行要求を受け付けるためのＷｅｂＡＰＩ４１０を有する。そして、ＰＣ２０や他の画像処理装置１０は、このＷｅｂＡＰＩ４１０を利用して画像処理装置１０に対して機能の実行を要求することができる。

また、本実施形態に係る画像処理装置１０は、アプリケーションのインストール／アンインストールによりサービスの追加／削除を行うことができる。また、本実施形態に係る画像処理装置１０は、サービスが利用するリソースの追加／削除を行うことができる。そして、本実施形態に係る画像処理装置１０は、上記サービスの追加／削除、リソースの追加／削除の際、追加又は削除したリソースのリソース情報を画像処理装置１０の記憶領域に登録又は削除することができる。

また、本実施形態に係る画像処理装置１０が有するリソース情報に含まれるＵＲＬは、ＰＣ２０や他の画像処理装置１０から利用可能なＡＰＩとして提供することができる。したがって、画像処理装置１０の記憶領域にリソース情報が登録／削除されることで、外部から利用可能なＡＰＩが同時に登録／削除されることになる。これにより、本実施形態に係る画像処理装置１０は、サービスやリソースが追加／削除された場合でも動的にＡＰＩを追加／削除することができる。すなわち、本実施形態に係る画像処理装置１０は、サービスやリソースが追加／削除された場合において、ＡＰＩの追加／削除に伴う再ビルドやオブジェクトの再作成などを行う必要がない。

［第２の実施形態］
次に、第２の実施形態に係る画像処理システムについて説明する。本実施形態においては、画像処理装置１０において利用可能なＡＰＩのリストをＰＣ２０に提供する。なお、システム構成及びハードウェア構成については、第１の実施形態と同様であるため説明を省略する。

＜機能構成＞
《画像処理装置》
図１３は、第２の実施形態に係る画像処理装置の一例の機能構成図である。第２の実施形態に係る画像処理装置１０は、ＡＰＩリスト作成部４２５を有する点が第１の実施形態に係る画像処理装置１０と異なる。なお、第２の実施形態に係る画像処理装置１０においてＡＰＩリスト作成部４２５以外の各構成は、第１と実施形態と同様であるため、説明を省略する。

ＡＰＩリスト作成部４２５は、ＰＣ２０等が画像処理装置１０において利用可能なＡＰＩの一覧（以降、「ＡＰＩリスト」という。）を作成する。また、ＡＰＩリスト作成部４２５は、ＰＣ２０等がＡＰＩリストを要求するためのリソース情報の登録要求をＡＰＩ管理部４２３に対して行う。

《ＰＣ》
図１４は、第２の実施形態に係るＰＣの一例の機能構成図である。図１４に示すようにＰＣ２０は、表示部５１０を有する。なお、図１４において、本実施形態の説明に必要のない構成については図示を省略している。

表示部５１０は、画像処理装置１０から受け取ったＡＰＩリストに基づき、ＡＰＩリストの表示画面を生成し、ＰＣ２０の表示装置１０２等に表示させる。

＜処理の概要＞
次に、第２の実施形態に係る画像処理装置の処理の概要について説明する。図１５は、第２の実施形態に係る画像処理装置の処理の一例を説明する説明図である。

図１５（ａ）は、ＰＣ２０がＡＰＩリストを画像処理装置１０から取得するためのリソース情報を登録する場合の画像処理装置１０の処理の一例を説明する説明図である。

ユーザは例えばネットワークなどを介して、フレームワーク４２０にＡＰＩリスト作成部４２５を追加する。すると、ＡＰＩ管理部４２３は、ＡＰＩリスト作成部４２５のリソース情報を画像処理装置１０の記憶領域に登録する。このようにリソース情報を登録することで、このリソース情報に含まれるＵＲＬをＰＣ２０や他の画像処理装置１０などから利用可能なＡＰＩとして提供することができる。

ＰＣ２０や他の画像処理装置１０などは、ＡＰＩリスト作成部４２５のリソース情報に含まれるＵＲＬをＡＰＩとして利用することで、このＰＣ２０や他の画像処理装置１０などが利用可能なＡＰＩリストを取得することができる。

図１５（ｂ）は、例えばＰＣ２０や他の画像処理装置１０などからＡＰＩリストの取得要求があった場合の画像処理装置１０の処理の一例を説明する説明図である。

まず、画像処理装置１０のＷｅｂＡＰＩ４１０は、例えばＰＣ２０や他の画像処理装置１０などからＡＰＩリストの取得要求に係るＨＴＴＰリクエストを受信する。次に、要求管理部４２１はＷｅｂＡＰＩ４１０から呼び出されるとＡＰＩリストの取得要求に係るＨＴＴＰリクエストを受け取り、ＡＰＩ制御部４２２に処理要求を行う。そして、ＡＰＩ制御部４２２はＡＰＩ管理部４２３を介してリソース情報を取得し、ＨＴＴＰリクエストにより呼び出されたＡＰＩ（ＷｅｂＡＰＩ４１０）を特定する。なお、このとき、呼び出されたＡＰＩはＡＰＩリストの取得要求に係るＡＰＩである。

ＡＰＩ制御部４２２は、ＡＰＩリスト作成部４２５に対して操作要求を行う。続いて、ＡＰＩリスト作成部４２５は、ＡＰＩ管理部４２３を介して画像処理装置１０に登録されているリソース情報を取得する。そして、取得したリソース情報からＡＰＩリストを作成し、応答要求を結果応答部４２４に行う。

結果応答部４２４は、ＡＰＩリストを含むＨＴＴＰレスポンスを作成し、要求管理部４２１に送信要求を行う。要求管理部４２１は、結果応答部４２４からＨＴＴＰレスポンスを受け取ると、ＷｅｂＡＰＩ４１０を介してＰＣ２０などにＨＴＴＰレスポンスを送信する。

これにより、ユーザは、例えばＰＣ２０などを操作して、このＰＣ２０が利用可能な画像処理装置１０のＡＰＩの一覧（ＡＰＩリスト）を取得することができる。したがって、ユーザは、例えば、この取得したＡＰＩリストから所望のＡＰＩを選択し、画像処理装置１０の機能を利用することができる。

次に、本実施形態に係るリソース情報の詳細について説明する。図１６は、リソース情報の他の例の構成図である。

本実施形態に係るリソース情報は、ＵＲＬ、メソッド、システム、アクセス、認証方式などのデータ項目を有する。図１６に示されるリソース情報のＵＲＬは、図６に示されるリソース情報と同様であるため、説明を省略する。

メソッドは、ＧＥＴ、ＰＯＳＴ、ＰＵＴ、ＤＥＬＥＴＥなどについて、上限、権限などのデータ項目を有する。これらの項目は、リソース部で指定されたリソースを利用したサービスを利用したい場合に、どのメソッドが定義されたＨＴＴＰリクエストで利用することができるかを示す項目である。このとき、ＨＴＴＰリクエストのＢｏｄｙ部（メッセージボディ）に指定することができる容量の上限（上限データ量）と、リソースを利用することができる権限とがそれぞれ上限及び権限のデータ項目で指定されている。

例えば、アドレス帳のアドレス情報を取得したい場合、ＵＲＬとして「/addressbook/entries」、メソッドとして「ＧＥＴ」を指定すればよい。また、このメソッドの権限は、「管理者」が指定されているため、このリソースを利用することができるのは例えば管理者権限のユーザである。換言すれば、ＰＣ２０や他の画像処理装置１０などに、管理者権限のユーザとしてログインしているユーザが、アドレス帳のアドレス情報を取得するためのリソースを利用することができる。なお、ＧＥＴメソッドは、Ｂｏｄｙ部を指定しないため、上限のデータ項目には「０」が指定されている。

また、例えば、アドレス帳にアドレス情報を追加したい場合、ＵＲＬとして「/addressbook/entries」、メソッドとして「ＰＯＳＴ」を指定すればよい。このメソッドの権限も「管理者」が指定されているため、このリソースを利用することができるのも例えば管理者権限のユーザである。さらに、上限のデータ項目には「１０００」が指定されているため、アドレス帳からアドレス情報を取得するに際に、例えば１回のＨＴＴＰリクエストで取得可能なアドレス情報の上限は１０００バイトまでである。

なお、利用することができないメソッドは、上限及び権限のデータ項目に「−」（ハイフン）が指定されている。例えば、プリンタの状態を表示させる機能を利用したい場合（サービス部「ｐｒｉｎｔｅｒ」、リソース部「ｓｔａｔｕｓ」）には、ＰＯＳＴメソッドやＰＵＴメソッド、ＤＥＬＥＴＥメソッドを定義したＨＴＴＰリクエストを利用することはできない。

システム、アクセス、認証方式の各データ項目は、リソース部で指定されたリソースを利用したサービスを利用したい場合に、それぞれ、必要なシステム条件、アクセス条件、利用する認証方式を示す項目である。電力制御はリソースの利用中に電力制御を行うか否か、ロックはリソースの利用中に他のリソースの利用を制限するか否かを示す。また、リモートのデータ項目は画像処理装置１０とネットワークを介したＰＣ２０などからリソースの利用が可能か否か、他方、操作部のデータ項目は画像処理装置１０を操作部２００を介して直接操作する場合にリソースの利用が可能か否かを示す。

認証方式は、リソースの利用に際して使用する認証方式である。例えば、リソース部で指定されるリソースを利用する際に、認証方式としてＢＡＳＩＣ認証を使用できるか否か、Ｄｉｇｅｓｔ認証を使用できるか否かを示す。

なお、以上に示したリソース情報のデータ項目は一例であり、他のデータ項目を有していてもよい。

＜処理の詳細＞
次に、第２の実施形態に係る画像処理装置の処理の詳細について説明する。まず、画像処理装置１０に対して、この画像処理装置１０において利用可能なＡＰＩリストを取得するためのリソース情報を登録する処理について説明する。図１７は、第２の実施形態に係るリソース情報追加／削除処理の一例のシーケンス図である。

ステップＳ５０１において、ユーザは例えばネットワークを介して、フレームワーク４２０にＡＰＩリスト作成部４２５を追加又は削除する。これは、例えば、ネットワークを介して、ＡＰＩリスト作成部４２５を追加又は削除するための所定のインストーラ等を取得し、このインストーラを実行することでＡＰＩリスト作成部４２５を追加又は削除することができる。すると、ＡＰＩリスト作成部４２５は、ＡＰＩ管理部４２３に対してリソース情報の登録又は削除要求を行う。

ステップＳ５０２において、ＡＰＩ管理部４２３は画像処理装置１０の記憶領域に、ＡＰＩリストを取得するためのリソース情報の登録又は削除を行う。

以上により、画像処理装置１０に対して、この画像処理装置１０において利用可能なＡＰＩリストを取得するためのリソース情報の登録又は削除を行うことができる。これにより、ＡＰＩリストを取得するためのＡＰＩが画像処理装置１０のＷｅｂＡＰＩ４１０に登録又はＷｅｂＡＰＩ４１０から削除される。後述するように、ＰＣ２０や他の画像処理装置１０は、ここで登録されたＡＰＩを利用して、画像処理装置１０において利用可能なＡＰＩリストを取得することができる。

次に、ユーザがＰＣ２０などを操作して、このＰＣ２０が画像処理装置１０において利用可能なＡＰＩの一覧（ＡＰＩリスト）を表示させるための処理について説明する。図１８は、第２の実施形態に係るＡＰＩリスト表示処理の一例のシーケンス図である。

ステップＳ６０１において、ＰＣ２０などはサービスとリソースを指定したＨＴＴＰリクエストを画像処理装置１０に送信する。ここで指定されるサービス及びリソースは、ＡＰＩリストを取得するためのリソース及びサービスである。例えば、ＰＣ２０は、サービスとしてＡＰＩリスト作成部４２５、リソースとしてＡＰＩリストを取得する機能を示すＵＲＬ「resourcelist/entries」と、メソッドにＧＥＴメソッドとを指定したＨＴＴＰリクエストを画像処理装置１０に送信する。

ステップＳ６０２において、要求管理部４２１はＷｅｂＡＰＩ４１０からＨＴＴＰリクエストを受け取り、ＡＰＩ制御部４２２に処理要求を行う。

ステップＳ６０３において、ＡＰＩ制御部４２２はＡＰＩ管理部４２３にリソース情報の取得要求を行う。そして、ＡＰＩ管理部４２３はリソース情報を画像処理装置１０の記憶領域から取得し、この取得したリソース情報をＡＰＩ制御部４２２に送信する。

ステップＳ６０４において、ＡＰＩ制御部４２２は、ＡＰＩ管理部４２３から取得したリソース情報に基づいてＡＰＩを特定する。すなわち、ＨＴＴＰリクエストに指定されているＵＲＬとリソース情報に含まれるＵＲＬとからＡＰＩを特定する。ここでは、ＷｅｂＡＰＩ４１０のＡＰＩとして、ＡＰＩリストを取得するためのＡＰＩ（例えば、ＵＲＬとして「resourcelist/entries」で指定されるＡＰＩ）が特定される。

ステップＳ６０５において、ＡＰＩ制御部４２２はＨＴＴＰリクエストを解析する。

ステップＳ６０６において、ＡＰＩ制御部４２２はＡＰＩリスト作成部４２５に対して操作要求を行う。

ステップＳ６０７において、ＡＰＩリスト作成部４２５は、ＡＰＩ管理部４２３に対して画像処理装置１０の記憶領域に登録されているすべてのリソース情報の取得要求を行う。そして、ＡＰＩ管理部４２３は、ＰＣ２０等が利用可能なリソース情報を画像処理装置１０の記憶領域から取得し、この取得したリソース情報をＡＰＩリスト作成部４２５に送信する。このステップＳ６０７の処理の詳細については後述する。

ステップＳ６０８において、ＡＰＩリスト作成部４２５は、ＡＰＩ管理部４２３から取得したリソース情報に基づいてＡＰＩリストを作成する。ここで作成されるＡＰＩリストは、例えば図１９に示されるような情報である。図１９は、ＡＰＩリストの一例を説明するための説明図である。図１９に示されるＡＰＩリスト３０００は、利用可能なサービス及びリソースのリソース情報３００１とリソース情報３００２とが記述されている。また、各リソース情報はＡＰＩを利用するためのＵＲＬやこのＡＰＩを利用する際に指定することができるメソッド等が記述されている。すなわち、ＡＰＩリストには、図１６で示したリソース情報の各データ項目の値が記述されている。後述する処理において、ＰＣ２０は、受け取ったＡＰＩリストを表示部５１０に表示させる。

ステップＳ６０９において、ＡＰＩリスト作成部４２５は、ＡＰＩリストを含む応答要求を結果応答部４２４に対して行う。

ステップＳ６１０において、結果応答部４２４は、応答要求からＨＴＴＰレスポンスを作成する。

ステップＳ６１１において、結果応答部４２４は、作成したＨＴＴＰレスポンスの送信要求を要求管理部４２１に対して行う。

ステップＳ６１２において、要求管理部４２１は、ＨＴＴＰレスポンスをＷｅｂＡＰＩ４１０を介してＰＣ２０などに送信する。

ステップＳ６１３において、ＰＣ２０の表示部５１０は、ＨＴＴＰレスポンスを受け取ると、このＨＴＴＰレスポンスに含まれるＡＰＩリストからＡＰＩリストの表示画面を作成し、表示装置１０２等に表示させる。これにより、ユーザは、ＰＣ２０や他の画像処理装置１０が利用することができる画像処理装置１０のＡＰＩを知ることができる。なお、ユーザは、ＰＣ２０や他の画像処理装置１０に限らず、例えば、画像処理装置１０の操作部２００を操作して、この操作部２００が利用可能な画像処理装置１０のＡＰＩリストを取得してもよい。

以上により、ユーザは、ＰＣ２０等を用いて、このＰＣ２０が利用可能な画像処理装置１０のＡＰＩリストを取得することができる。ユーザは、表示されたＡＰＩリストから所望のＡＰＩを選択等することで、画像処理装置１０が提供するＡＰＩを利用することができる。なお、上記においては、ＰＣ２０等が利用可能な画像処理装置１０のＡＰＩリストを取得したが、例えば、利用可能か否かに関わらず画像処理装置１０が提供するすべてのＡＰＩのリストを取得するようにしてもよい。

次に、図１８を用いて説明したＡＰＩリスト表示処理におけるステップＳ６０７の処理（リソース情報取得処理）の詳細について説明する。図２０は、第２の実施形態に係るリソース情報取得処理の一例のフローチャートである。

ステップＳ７０１において、ＡＰＩ管理部４２３は、ＡＰＩリスト作成部４２５からリソース情報の取得要求を受け取ると、取得済みのリソース情報の数が画像処理装置１０の記憶領域に登録されているリソース情報の数未満か否かを判定する。換言すれば、ＡＰＩ管理部４２３は、画像処理装置１０の記憶領域に登録されているすべてのリソース情報を取得したか否かを判定する。すべてのリソース情報を取得していない場合、ステップＳ７０２に進み、他方、すべてのリソース情報を取得済の場合、処理を終了させる。

ステップＳ７０２において、ＡＰＩ管理部４２３は、画像処理装置１０の記憶領域からリソース情報を取得する。

ステップＳ７０３において、ＡＰＩ管理部４２３は、上記のステップＳ７０２で取得したリソース情報について、ＰＣ２０等が利用可能なＡＰＩであるか否かを判定する。利用可能である場合、ステップＳ７０４に進み、他方、利用することができない場合、ステップＳ７０１に戻る。

ここで、上記のステップＳ７０３で取得したリソース情報に係るＡＰＩについて、ＰＣ２０が利用可能であるか否かは、例えば、図１６に示したリソース情報の権限やアクセス等のデータ項目に基づいて判定される。例えば、図１６に示す権限のデータ項目が「管理者」であり、ＰＣ２０にログインしているユーザが「一般ユーザ」である場合、権限のデータ項目が「管理者」であるリソース情報に係るＡＰＩは利用することができないと判定される。また、例えば、図１６に示すアクセスのデータ項目について、リモートが「×」、操作部が「○」であるリソース情報である場合、画像処理装置１０とネットワークを介して接続されたＰＣ２０からは利用することができないと判定され、他方、画像処理装置１０の操作部２００からは利用することができると判定される。

ステップＳ７０４において、ＡＰＩ管理部４２３は、上記のステップＳ７０４において取得したリソース情報を一時的に保持する。すなわち、ここでＡＰＩ管理部４２３が保持したリソース情報がＡＰＩリスト作成部４２５に送信される。そして、図１８のステップＳ６０８で説明したように、ＡＰＩリスト作成部４２５は、ＡＰＩ管理部４２３から送信されたリソース情報に基づきＡＰＩリストを作成する。なお、ＡＰＩ管理部４２３は、取得したリソース情報を一時的に保持せずに、ＡＰＩリスト作成部４２５に即座に送信してもよい。

以上により、ＡＰＩ管理部４２３は、画像処理装置１０の記憶領域に登録されているリソース情報からＡＰＩリストの取得要求を行ったＰＣ２０等が利用することができるＡＰＩのリソース情報を取得する。これにより、ＰＣ２０等において、自身が利用することができる画像処理装置１０のＡＰＩリストを表示等させることができる。

＜まとめ＞
以上のように、本実施形態に係る画像処理装置１０は、ＰＣ２０や他の画像処理装置１０、さらには画像処理装置１０の操作部２００からのＡＰＩリスト取得要求に応じて、これらのＰＣ２０等が利用可能な画像処理装置１０のＡＰＩリストを返信する。したがって、ＰＣ２０等は、自身が利用可能な画像処理装置１０のＡＰＩリストを表示部などに表示させることができる。その後、ユーザは、例えば表示部に表示されているＡＰＩリストから自身が利用したいと所望のＡＰＩを選択することで、この選択したＡＰＩを利用することができる。

［第３の実施形態］
次に、第３の実施形態に係る画像処理システムについて説明する。本実施形態においては、画像処理装置１０において利用可能なＡＰＩのリストをＰＣ２０に提供するに際し、ＡＰＩ管理部４２３が取得したリソース情報をキャッシュとして保存する。なお、システム構成、機能構成及びハードウェア構成については、第２の実施形態と同様であるため説明を省略する。

＜処理の詳細＞
次に、第３の実施形態に係る画像処理装置の処理の詳細について説明する。本実施形態は、リソース情報取得処理が第２の実施形態と異なる。したがって、リソース情報取得処理のみ説明し、リソース情報追加／削除処理及びＡＰＩリスト表示処理については説明を省略する。なお、リソース情報取得処理において、第２の実施形態と同様の処理については、同一の符号を付し、その説明を省略する。図２１は、第３の実施形態に係るリソース情報取得処理の一例のフローチャートである。

ステップＳ８０１において、ＡＰＩ管理部４２３は、リソース情報がキャッシュに存在するか否かを判定する。リソース情報がキャッシュに存在しない場合、ステップＳ７０１に進み、他方、リソース情報がキャッシュに存在する場合、ステップＳ８０２に進む。

ここで、キャッシュとは、リソース情報取得処理において、ＡＰＩ管理部４２３が取得したリソース情報を保存するための、画像処理装置１０のＨＤＤ２２３等に確保された記憶領域である。なお、キャッシュはキャッシュ記憶手段の一例である。

ステップＳ８０２において、ＡＰＩ管理部４２３は、キャッシュ作成後に、画像処理装置１０の記憶領域にリソース情報が新たに登録又は削除されたか否かを判定する。キャッシュ作成後にリソース情報が新たに登録又は削除された場合、ステップＳ７０１に進み、他方、キャッシュ作成後にリソース情報が新たに登録も削除もされていない場合、ステップＳ８０３に進む。

ステップＳ８０３において、ＡＰＩ管理部４２３は、キャッシュに保存されているリソース情報を取得する。

ステップＳ８０４において、ＡＰＩ管理部４２３は、取得したリソース情報をキャッシュに保存する。なお、上記のステップＳ８０３においてキャッシュに保存されているリソース情報を取得した場合には、キャッシュの内容に変更はないが、本処理を行うことにより例えばキャッシュのタイムスタンプを更新させることができる。したがって、キャッシュが一定期間経過により削除されるような場合、本処理により、キャッシュの保存期間がリフレッシュされる。

このように、キャッシュにリソース情報が存在し、かつ、キャッシュ作成後に新たなリソース情報が登録されていない場合は、キャッシュに保存されているリソース情報をＡＰＩリスト作成部４２５に送信する。したがって、この場合、ステップＳ７０１〜７０４の処理を行う必要がないため、ＰＣ２０はＡＰＩリストの取得を高速に行うことができる。

＜まとめ＞
以上のように、本実施形態に係る画像処理装置１０は、画像処理装置１０において利用可能なＡＰＩのリストをＰＣ２０に提供するに際し、ＡＰＩ管理部４２３が取得したリソース情報をキャッシュとして保存する。また、キャッシュにリソース情報が存在し、かつ、キャッシュ作成後に新たなリソース情報が登録されていない場合は、キャッシュに保存されているリソース情報をＡＰＩリスト作成部４２５に送信する。これにより、キャッシュにリソース情報が存在する場合は、ＰＣ２０はＡＰＩリストの取得を高速に行うことができる。したがって、ＰＣ２０等からのＡＰＩリストの取得要求のレスポンスが第２の実施形態と比較して高速になる。

［第４の実施形態］
次に、第４の実施形態に係る画像処理システムについて説明する。本実施形態に係る画像処理装置１０は、操作部２００Ａと本体部２１０とがそれぞれ独立したＣＰＵを有する。また、本体部２１０は、ＰＣ２０から要求を受け付けるための機能部と、操作部から要求を受け付けるための機能部とをそれぞれ有している。そして、本体部２１０の起動に応じて、操作部から要求を受け付けるための機能部を起動させた後、ＰＣ２０から要求を受け付けるための機能部を起動させるものである。なお、システム構成については、第３の実施形態と同様であるため説明を省略する。

＜ハードウェア構成＞
まず、第４の実施形態に係る画像処理装置１０のハードウェア構成について説明する。第４の実施形態に係る画像処理装置１０は、例えば図２２に示すようなハードウェア構成により実現される。図２２は、第４の実施形態に係る画像処理装置の一例のハードウェア構成図である。図２２に示すように、画像処理装置１０は、操作部２００Ａと本体部２１０とを有する。なお、本体部２１０のハードウェア構成は、第３の実施形態と同様であるため説明を省略する。

操作部２００Ａは、ＬＣＤデバイスやタッチパネル、ハードキーなどに加えて、ＣＰＵ２７１やメモリ２７２などを備えるユーザインタフェースであり、画像処理装置１０に対して、ユーザが各種データの設定、登録、処理の実行などを行う際に操作する。なお、メモリ２７２は、例えば、ＲＡＭ、ＲＯＭなどである。メモリ２７２に、ＨＤＤやＳＳＤ（Solid State Drive）などを含めてもよい。なお、操作部２００Ａと本体部２１０との間は、有線（又は無線）で通信可能に接続されている。

このように、第４の実施形態に係る画像処理装置１０の操作部２００Ａは、ＣＰＵ２７１、メモリ２７２などを備えた、情報処理装置である。すなわち、第４の実施形態に係る画像処理装置１０は、２台の情報処理装置（操作部２００Ａ及び本体部２１０）により構成されている。ただし、画像処理装置１０を構成する情報処理装置は、２台に限られず、３台以上の情報処理装置により構成されていてもよい。

＜機能構成＞
次に、第４の実施形態に係る画像処理装置１０の機能構成について説明する。図２３は、第４の実施形態に係る画像処理装置の一例の機能構成図である。第４の実施形態に係る画像処理装置１０は、操作部２００Ａを有する点が異なる。また、画像処理装置１０は、フレームワーク４２０の要求管理部４２１Ａの機能及びフレームワーク４２０にフレームワーク起動制御部４２６を有する点、並びに本体部２１０に本体起動制御部４９０を有する点が異なる。なお、これら以外の各機能は、第３の実施形態と同様であるため、説明を省略する。

操作部２００Ａは、ＯＳ５４０上で実行されるアプリケーション群５０１と、ＬＣＤデバイスやタッチパネルへの表示を制御する表示制御部５２０と、本体部２１０のＷｅｂＡＰＩ４１０と通信を行う通信部５５０とを有する。

アプリケーション群５０１は、ＯＣＲ（Optical Character Reader）アプリケーション５３１、コピーアプリケーション５３２、翻訳アプリケーション５３３などを有する。これらのアプリケーションは、本体部２１０のソフトウェア群４０１に含まれるプログラムと連携して、又は、単独で、各種処理を実行する。例えば、ＯＣＲアプリケーション５３１は、本体部２１０のスキャナアプリケーション４３４により原稿をスキャンして生成された画像データに対してＯＣＲ処理を行う。また、例えば、翻訳アプリケーション５３３は、操作部２００ＡのＬＣＤデバイス上に表示されている文字等を他の言語に翻訳して表示する。このように、操作部２００Ａには、ＯＳ５４０により制御される各種アプリケーション群５０１が搭載されている。なお、ＯＳ５４０としては、例えば、Ａｎｄｒｏｉｄなどを用いることができる。

要求管理部４２１Ａは、操作部２００ＡからＷｅｂＡＰＩ４１０を介した処理要求を受け付けるための操作部要求受付部４２１１と、ＰＣ２０からＷｅｂＡＰＩ４１０を介した処理要求を受け付けるためのリモート要求受付部４２１２とを有する。このように要求管理部４２１Ａは、要求元に応じた機能部で処理要求を受け付ける。

フレームワーク起動制御部４２６は、フレームワーク４２０内の各機能部の起動を制御する。すなわち、フレームワーク起動制御部４２６は、本体起動制御部４９０からの要求に応じて、操作部要求受付部４２１１、リモート要求受付部４２１２を起動させる。また同様に、フレームワーク起動制御部４２６は、ＡＰＩ制御部４２２、ＡＰＩ管理部４２３、結果応答部４２４、ＡＰＩリスト作成部４２５、フレームワーク起動制御部４２６を起動させる。

本体起動制御部４９０は、本体部２１０の起動に応じて、本体部２１０の各機能部の起動を制御する。すなわち、本体起動制御部４９０は、本体部２１０の起動に応じて、フレームワーク起動制御部４２６やソフトウェア群４０１に含まれる各アプリケーションやサービスモジュールなどのプログラムを起動させる。

＜処理の詳細＞
次に、第４の実施形態に係る画像処理装置の処理の詳細について説明する。本実施形態では、画像処理装置１０を起動した際の処理について説明する。なお、これ以外の処理については、第１〜第３の実施形態と同様であるため説明を省略する。図２４は、第４の実施形態に係る画像処理装置の起動時の処理の一例のシーケンス図である。

以降では、例えば画像処理装置１０のユーザなどにより、画像処理装置１０に電源が投入されたものとして、説明する。

ステップＳ９０１において、画像処理装置１０に電源が投入されると、本体起動制御部４９０は、フレームワーク起動制御部４２６に対して、起動要求を送信する。これにより、フレームワーク起動制御部４２６が起動される。

ステップＳ９０２において、フレームワーク起動制御部４２６は、操作部要求受付部４２１１に対して、起動要求を送信する。これにより、操作部要求受付部４２１１が起動される。なお、このとき、フレームワーク起動制御部４２６は、ＡＰＩ制御部４２２、ＡＰＩ管理部４２３、結果応答部４２４、ＡＰＩリスト作成部４２５などに対して、起動要求を送信して、これら各部を起動させてもよい。

ステップＳ９０３において、操作部要求受付部４２１１は、操作部２００Ａの通信部５５０と通信を行うための通信ポートを開放する。これにより、操作部要求受付部４２１１は、操作部２００Ａからの処理要求を受け付けることができるようになる。

ステップＳ９０４において、本体起動制御部４９０は、サービスに対して、起動要求を送信する。これにより、サービスが起動される。ここで、本体起動制御部４９０が起動要求を送信するサービスは、ネットワーク制御サービス４５５を除く、ソフトウェア群４０１に含まれるアプリケーション又はサービスモジュールである。すなわち、本体起動制御部４９０は、ネットワーク制御サービス４５５を除くソフトウェア群４０１に含まれるアプリケーション及びサービスモジュールのすべてに対して、起動要求を送信する。

ただし、これに限られず、本体起動制御部４９０は、ネットワーク制御サービス４５５を除くソフトウェア群４０１に含まれるアプリケーション又はサービスモジュールのうち、操作部２００Ａの表示処理に必要なサービスに対してのみ起動要求を送信してもよい。

ステップＳ９０５において、サービスは、リソース情報を登録する。より具体的には、図１０で説明したように、サービスは、ＡＰＩ管理部４２３に対して、リソース情報の登録要求を行う。すると、ＡＰＩ管理部４２３により、該当のサービスのリソース情報が画像処理装置１０の記憶領域に登録される。

ステップＳ９０６において、本体起動制御部４９０は、操作部２００Ａに対して、表示要求を送信する。ここで、表示要求は、操作部２００ＡのＬＣＤデバイスなどに、ユーザが画像処理装置１０の操作を行うための画面（操作画面）を表示させるための要求である。

ステップＳ９０７において、操作部２００Ａの表示制御部５２０は、通信部５５０を介して、操作部要求受付部４２１１に対してリクエストを送信する。より具体的には、表示制御部５２０は、通信部５５０を介して、操作画面の表示に必要なサービスとリソースを指定したリクエスト（ＨＴＴＰリクエスト）を操作部要求受付部４２１１に送信する。

なお、操作画面の表示に必要なサービスとリソースとは、例えば、操作部２００Ａのアプリケーション群５０１に含まれるアプリケーションの初期設定の取得などである。より具体的には、例えば、アプリケーション群５０１に含まれるコピーアプリケーション５３２の初期設定（例えば、カラー／モノクロ、用紙サイズなどの設定項目の設定値）を、コピーアプリケーション４３１（サービス）から取得するリソースなどである。

ステップＳ９０８において、操作部要求受付部４２１１は、リクエストを受信すると、認証要否判定処理を行う。この認証要否判定処理の詳細については後述する。

ステップＳ９０９において、操作部要求受付部４２１１は、ＡＰＩ制御部４２２を介して、該当のサービスの該当のリソースに対して操作要求を行う。より具体的には、図７で説明したのと同様に、操作部要求受付部４２１１は、ＷｅｂＡＰＩ４１０からＨＴＴＰリクエストを受け取り、ＡＰＩ制御部４２２に処理要求を行う。そして、ＡＰＩ制御部４２２は、ＡＰＩ管理部４２３からリソース情報を取得し、ＡＰＩの特定及び解析を行い、該当のサービスの該当のリソースに対して操作要求を行う。

ステップＳ９１０において、サービスは、処理を実行する。すなわち、例えば、サービスがコピーアプリケーション４３１、リソースが初期設定の取得である場合、処理を実行することで、操作部２００Ａのコピーアプリケーション５３２の初期設定に関する情報が取得される。

ステップＳ９１１において、サービスは、結果応答部４２４を介して、上記のステップＳ９１０で実行された処理の処理結果を、操作部要求受付部４２１１に送信する。より具体的には、図７で説明したのと同様に、上記のステップＳ９１０で実行された処理の処理結果を含む応答要求を結果応答部４２４に対して送信する。そして、結果応答部４２４は、ＨＴＴＰレスポンスを作成して、当該ＨＴＴＰレスポンスの送信要求を操作部要求受付部４２１１に対して行う。

ステップＳ９１２において、操作部要求受付部４２１１は、ＨＴＴＰレスポンスをＷｅｂＡＰＩ４１０を介して、操作部２００Ａに送信する。

上記のステップＳ９０７〜Ｓ９１２の処理は、操作部２００Ａが操作画面を表示させるのに必要なサービスとリソースに対して実行される。

ステップＳ９１３において、操作部２００Ａの表示制御部５２０は、上記のステップＳ９０７〜Ｓ９１２の処理により取得された情報に基づき、ＬＣＤデバイスなどに操作画面を表示させる。これにより、ユーザは、操作部２００Ａを用いて、画像処理装置１０を利用することができるようになる。

ステップＳ９１４において、本体起動制御部４９０は、ネットワーク制御サービス４５５に対して、起動要求を送信する。これにより、ネットワーク制御サービス４５５が起動される。

ステップＳ９１５において、ネットワーク制御サービス４５５は、ＰＣ２０などと通信を行うための通信ポートを開放する。

ステップＳ９１６において、フレームワーク起動制御部４２６は、リモート要求受付部４２１２に対して、起動要求を送信する。これにより、リモート要求受付部４２１２が起動される。なお、フレームワーク起動制御部４２６がリモート要求受付部４２１２に起動要求を送信するタイミングは、操作部要求受付部４２１１が起動された直後又は操作部要求受付部４２１１が起動されてから所定の時間（例えば３０秒）経過後などとすればよい。

ステップＳ９１７において、リモート要求受付部４２１２は、ネットワーク制御サービス４５５により開放された通信ポートに対して、コネクション接続要求を送信する。これにより、リモート要求受付部４２１２は、ネットワーク制御サービス４５５により開放された通信ポートを用いて、ＰＣ２０などと通信を行うことができるようになる。

このように、本実施形態に係る画像処理装置１０が電源投入などにより起動された場合、操作部要求受付部４２１１を起動させた後、リモート要求受付部４２１２を起動させる。これにより、操作部２００Ａに操作画面が迅速に表示され、ユーザが操作を開始するまでの待ち時間を軽減することができる。

すなわち、従来においては、ユーザが操作部２００Ａによる操作を所望する場合でもリモート要求受付部４２１２やネットワーク制御サービス４５５などが起動されるまで、ユーザは待たされていた。しかしながら、本実施形態によれば、先に操作部要求受付部４２１１を起動させ、操作部２００Ａに操作画面を表示させることで、ユーザの待ち時間が軽減される。

次に、図２４のステップＳ９０８の認証要否判定処理の詳細について説明する。図２５は、第４の実施形態に係る認証要否判定処理の一例のフローチャートである。

ステップＳ１００１において、操作部要求受付部４２１１は、リクエストを受信すると、当該リクエストに含まれるユーザ情報（例えば、ユーザ名など）に基づき、当該ユーザが認証済みが否かを判定する。認証済みである場合、ステップＳ１００２に進み、認証済みでない場合、ステップＳ１００３に進む。なお、画像処理装置１０を起動した際の処理である図２４のステップＳ９０８の段階では、ユーザ名としてはいわゆるデフォルトユーザ名などが用いられる。

ステップＳ１００２において、操作部要求受付部４２１１は、ＡＰＩ制御部４２２を介して、該当のサービスの該当のリソースに対して操作要求を行う。すなわち、図２４のステップＳ９０９の処理を実行する。

ステップＳ１００３において、操作部要求受付部４２１１は、認証処理を行う。すなわち、当該リクエストに含まれるユーザ情報（例えば、ユーザ名とパスワードの組）に基づき、当該ユーザ情報が正当なものであるか否かを判定する。

このように、操作部２００Ａから本体部２１０に対して複数回リクエストがあった場合は、初回のみ認証処理を行い、２回目以降は認証処理を省くように制御する。これにより、操作部２００Ａに操作画面が表示されるまでのユーザの待ち時間を、さらに軽減させることができる。

＜まとめ＞
以上のように、本実施形態に係る画像処理装置１０は、当該画像処理装置１０が起動された場合、操作部要求受付部４２１１を起動させた後、リモート要求受付部４２１２を起動させる。したがって、操作部２００Ａに操作画面が表示されるまでのユーザの待ち時間が軽減される。

また、本実施形態に係る画像処理装置１０は、操作部２００Ａから本体部２１０に対して複数回リクエストがあった場合は、初回のみ認証処理を行い、２回目以降は認証処理を省くように制御する。これにより、操作部２００Ａに操作画面が表示されるまでのユーザの待ち時間がさらに軽減される。

なお、画像処理装置１０は、情報処理装置の一例である。ＰＣ２０は、機器の一例である。ＡＰＩ管理部４２３は、機能記憶手段、判定手段及び取得手段の一例である。ＷｅｂＡＰＩ４１０及び要求管理部４２１は、インタフェース手段の一例である。ＡＰＩ制御部４２２は、特定手段及び処理要求手段の一例である。ＡＰＩリスト作成部４２５は、生成手段の一例である。

本発明は、具体的に開示された上記の実施形態に限定されるものではなく、特許請求の範囲から逸脱することなく、種々の変形や変更が可能である。

１ 画像処理システム
１０ 画像処理装置
２０ ＰＣ
１０１ 入力装置
１０２ 表示装置
１０３ 外部Ｉ／Ｆ
１０３ａ 記録媒体
１０４ ＲＡＭ
１０５ ＲＯＭ
１０６ ＣＰＵ
１０７ 通信Ｉ／Ｆ
１０８ ＨＤＤ
２５１ プロッタエンジン
２５２ スキャナエンジン
２５３ その他のハードウェアリソース
４０１ ソフトウェア群
４０２ ハードウェア資源
４０３ アプリケーション層
４０４ サービスモジュール層
４１０ ＷｅｂＡＰＩ
４２０ フレームワーク
４２１ 要求管理部
４２２ ＡＰＩ制御部
４２３ ＡＰＩ管理部
４２４ 結果応答部
４２５ ＡＰＩリスト作成部
４３１ コピーアプリケーション
４３２ ファックスアプリケーション
４３３ プリンタアプリケーション
４３４ スキャナアプリケーション
４４０ 内部ＡＰＩ
４５１ システム制御サービス
４５２ ファックス制御サービス
４５３ エンジン制御サービス
４５４ メモリ制御サービス
４５５ ネットワーク制御サービス
４５６ ログ制御サービス
４５７ 電源制御サービス
４５８ 認証制御サービス
４５９ アドレス帳管理サービス
４６０ ＯＳ
４７０ エンジンＩ／Ｆ
４８０ エンジン制御ボード
５１０ 表示部

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

Claims (20)

1. ネットワークを介して接続された機器からの要求に応じて所定の機能を利用したサービスを提供する情報処理装置であって、
   前記サービスと該サービスが利用する機能毎に、前記機器から前記機能を利用したサービスの要求を受け付けるためのインタフェース情報を含む、前記機能に関する情報を記憶させる機能記憶手段と、
   前記機能に関する情報に含まれるインタフェース情報毎に前記機器からの要求を受け付けるインタフェース手段と、を有し、
   前記機能記憶手段は、
   前記サービスが利用する機能が追加された場合、該追加された機能に関する情報を記憶させる、情報処理装置。
2. 前記機器からの要求を受け付けたインタフェース手段と前記機能に関する情報とから、該受け付けたインタフェース手段に対応するインタフェース情報を特定する特定手段と、
   前記特定手段で特定したインタフェース情報に基づいて、該インタフェース情報に対応するサービス及び機能を特定し、該特定したサービスに対して該特定した機能を利用した処理を要求する処理要求手段と、
   を有する請求項１記載の情報処理装置。
3. 前記インタフェース情報は、サービスのサービス名と該サービスが利用する機能の機能名を連結させ、ＵＲＬ形式で表した情報である、請求項１又は２記載の情報処理装置。
4. 前記機能記憶手段は、
   さらに、前記サービスが利用する機能が削除された場合、該削除された機能に関する情報を削除する、請求項１ないし３のいずれか１項に記載の情報処理装置。
5. 前記機能記憶手段は、
   さらに、前記サービスが前記情報処理装置から削除された場合、該削除されたサービスが利用する機能に関する情報を削除する、請求項１ないし４のいずれか１項に記載の情報処理装置。
6. 前記サービスが利用する機能が追加された場合、該追加された機能に関する情報が前記機能記憶手段に記憶されているか否かを判定する判定手段を有し、
   前記機能記憶手段は、
   前記判定手段において前記追加された機能に関する情報が記憶されていないと判定された場合、該追加された機能に関する情報を前記記憶させる、請求項１ないし５のいずれか１項に記載の情報処理装置。
7. 前記インタフェース手段により前記機器から前記情報処理装置が提供するサービスのリストの要求を受け付けると、前記機能記憶手段に記憶されている機能に関する情報を取得する取得手段と、
   前記取得手段により取得された前記機能に関する情報から前記機器が利用することができるサービスと該サービスが利用する機能とを含む利用可能なサービスに関する情報を生成する生成手段と、
   を有する請求項１ないし６のいずれか１項に記載の情報処理装置。
8. 前記取得手段により取得される機能に関する情報は、該機能に関する情報に対応するサービスが利用する機能を前記機器が利用するための権限に関する情報を含む、請求項７記載の情報処理装置。
9. 前記取得手段は、
   前記インタフェース手段により前記機器から前記情報処理装置が提供するサービスのリストの要求を受け付けると、前記機能記憶手段に記憶されている機能に関する情報のうち、前記権限に関する情報に基づき、該機器が利用可能な機能を利用するサービスに対応する前記機能に関する情報を取得する、請求項８記載の情報処理装置。
10. 前記機器には、前記情報処理装置の操作部を含み、
    前記取得手段により取得される機能に関する情報は、前記機器が前記情報処理装置の操作部であるか否かを示す情報を含み、
    前記取得手段は、
    前記インタフェース手段により前記機器から前記情報処理装置が提供するサービスのリストの要求を受け付けると、前記機能記憶手段に記憶されている機能に関する情報のうち、前記機器が前記情報処理装置の操作部であるか否かを示す情報に基づき、該機器が利用可能な機能を利用するサービスに対応する前記機能に関する情報を取得する、請求項７ないし９のいずれか１項に記載の情報処理装置。
11. 前記取得手段により取得される機能に関する情報は、該機能に関する情報に対応するサービスが利用する機能を前記機器が利用する際の上限データ量に関する情報を含む、請求項７ないし１０のいずれか１項に記載の情報処理装置。
12. 前記情報処理装置が提供するサービスに対応する機能に関する情報を、キャッシュとして記憶するキャッシュ記憶手段を有し、
    前記取得手段は、前記情報処理装置が提供するサービスに対応する機能に関する情報が前記キャッシュ記憶手段に存在しない場合に、前記機能に関する情報を取得する、請求項７ないし１１のいずれか１項に記載の情報処理装置。
13. 前記情報処理装置は、前記所定の機能を利用したサービスを提供する本体部と、該本体部に前記機能を利用したサービスを要求する操作部とを含み、
    前記本体部及び前記操作部は、それぞれ独立したＣＰＵを有する、請求項１ないし１２のいずれか１項に記載の情報処理装置。
14. 前記インタフェース手段は、
    前記機能に関する情報に含まれるインタフェース情報毎に前記操作部からの要求を受け付ける操作部受付手段と、
    前記機能に関する情報に含まれるインタフェース情報毎に前記機器からの要求を受け付ける機器受付手段と
    を有し、
    前記操作部受付手段及び前記機器受付手段は、
    前記本体部が起動されたことに基づき、前記操作部受付手段が起動された後、前記機器受付手段が起動される、請求項１３記載の情報処理装置。
15. 前記操作部受付手段及び前記機器受付手段は、
    前記本体部の起動に応じて、前記操作部受付手段が起動された後、所定の時間の経過後に、前記機器受付手段が起動される、請求項１４記載の情報処理装置。
16. ネットワークを介して接続された機器からの要求に応じて所定の機能を利用したサービスを提供する情報処理装置に用いられる情報処理方法であって、
    前記サービスが利用する機能が追加された場合、該追加された機能に関する情報を、前記サービスと該サービスが利用する機能毎に機能記憶手段に記憶させる記憶手順と、
    前記機能記憶手段に記憶されている機能に関する情報に含まれるインタフェース情報に基づき、前記機器からの要求を受け付けるインタフェース手順と、
    を有する情報処理方法。
17. 前記インタフェース手順により前記機器から前記情報処理装置が提供するサービスのリストの要求を受け付けると、前記機能記憶手段に記憶されている機能に関する情報を取得する取得手順と、
    前記取得手順により取得された前記機能に関する情報から前記機器が利用することができるサービスと該サービスが利用する機能とを含む利用可能なサービスに関する情報を生成する生成手順と、
    を有する請求項１６記載の情報処理方法。
18. ネットワークを介して接続された機器からの要求に応じて所定の機能を利用したサービスを提供する情報処理装置を、
    前記サービスが利用する機能が追加された場合、該追加された機能に関する情報を、前記サービスと該サービスが利用する機能毎に機能記憶手段に記憶させる記憶手段、
    前記機能記憶手段に記憶されている機能に関する情報に含まれるインタフェース情報に基づき、前記機器からの要求を受け付けるインタフェース手段、
    として機能させるためのプログラム。
19. 前記情報処理装置を、
    前記インタフェース手段により前記機器から前記情報処理装置が提供するサービスのリストの要求を受け付けると、前記機能記憶手段に記憶されている機能に関する情報を取得する取得手段、
    前記取得手段により取得された前記機能に関する情報から前記機器が利用することができるサービスと該サービスが利用する機能とを含む利用可能なサービスに関する情報を生成する生成手段、
    として機能させるための請求項１８記載のプログラム。
20. 機器と、該機器からの要求に応じて所定の機能を利用したサービスを提供する情報処理装置とを有する情報処理システムであって、
    前記サービスと該サービスが利用する機能毎に、前記機器から前記機能を利用したサービスの要求を受け付けるためのインタフェース情報を含む、前記機能に関する情報を記憶させる機能記憶手段と、
    前記機能に関する情報に含まれるインタフェース情報毎に前記機器からの要求を受け付けるインタフェース手段と、
    前記インタフェース手段により前記情報処理装置が提供するサービスのリストの要求を受け付けると、前記機能記憶手段に記憶されている機能に関する情報を取得する取得手段と、
    前記取得手段により取得された前記機能に関する情報から前記機器が利用することができるサービスと該サービスが利用する機能とを含む利用可能なサービスに関する情報を生成する生成手段と、
    前記生成手段により生成された前記利用可能なサービスに関する情報に基づき、前記情報処理装置が提供するサービスのリストを表示部に表示させる表示手段と、を有し
    前記機能記憶手段は、
    前記サービスが利用する機能が追加された場合、該追加された機能に関する情報を記憶させる、情報処理システム。

Images