JP2016091311A - 情報処理装置、情報処理システム、及び情報処理方法 - Google Patents

Abstract

【課題】ＡＰＩにより提供される機能の情報を動的に変更することができるようにする。
【解決手段】ネットワークを介して接続された機器からの要求に応じて所定の機能を利用したサービスを提供する情報処理装置であって、サービスとサービスが利用する機能毎に、機器からの機能を利用したサービスの要求を受け付けるためのＷｅｂＡＰＩ４１０を示す情報と、ＷｅｂＡＰＩ４１０を用いて提供される機能に関する情報とを関連付けて所定の記憶領域に記憶させるＡＰＩ管理部４２３と、機器からの要求をＷｅｂＡＰＩ４１０毎に受け付ける要求管理部４２１と、要求管理部４２１により要求を受け付けると、機能に関する情報に基づき、要求に対応するサービスの機能を実行させて、サービスを提供するＡＰＩ制御部４２２と、機器からの要求又は情報処理装置の状態に応じて所定の記憶領域に記憶されている機能に関する情報を動的に変更する変更手段と、を有する。
【選択図】図５

Description

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

ＭＦＰ（Multifunction Peripheral）等の画像形成装置の機能をＰＣ等から利用できるＡＰＩ（Application Program Interface）を備えたＲＥＳＴ（Representational State Transfer）形式のフレームワークが既に知られている。

また、自身の機能をネットワークに接続されたＰＣ等から利用するためのＡＰＩを備えた情報処理装置が既に知られている（例えば特許文献１参照）。

しかしながら、上記の従来技術においては、情報処理装置の起動時に、例えばＡＰＩを用いてＰＣ等から受け取ることができるデータ量の上限等を登録し、起動後に変更することができなかった。したがって、例えばＡＰＩを用いてＰＣ等から受け取ることができるデータ量の上限等を変更したい場合、情報処理装置の再起動が必要であった。

本発明の一実施形態は、上記の点に鑑みてなされたもので、ＡＰＩにより提供される機能の情報を動的に変更することを目的とする。

上記目的を達成するため、本発明の一実施形態は、ネットワークを介して接続された機器からの要求に応じて所定の機能を利用したサービスを提供する情報処理装置であって、前記サービスと該サービスが利用する機能毎に、前記機器から前記機能を利用したサービスの要求を受け付けるためのＡＰＩを示す情報と、該ＡＰＩを用いて提供される機能に関する情報とを関連付けて所定の記憶領域に記憶させるＡＰＩ管理手段と、前記機器から前記要求を前記ＡＰＩ毎に受け付けるインタフェース手段と、前記インタフェース手段により前記要求を受け付けると、前記機能に関する情報に基づき、前記要求に対応するサービスの機能を実行させて、該サービスを提供するサービス提供手段と、前記機器からの要求又は前記情報処理装置の状態に応じて前記所定の記憶領域に記憶されている前記機能に関する情報を動的に変更する変更手段と、を有することを特徴とする。

本発明の一実施形態によれば、ＡＰＩにより提供される機能の情報を動的に変更することができる。

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

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

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

画像処理装置１０は、情報処理装置の一例である。画像処理装置１０は、ＰＣ２０や他の画像処理装置１０等の機器からの要求に応じて、コピー、ファックス、プリンタ、スキャナ等の画像処理に係るサービスを提供するＭＦＰである。ただし、画像処理装置１０はＭＦＰに限定されるものではなく、他の機器に対して各種サービスを提供することができる装置であればよい。

また、画像処理装置１０は、ＰＣ２０や他の画像処理装置１０等の機器が上記サービスを利用するためのＡＰＩを有する。画像処理装置１０は、上記サービスが利用する機能を追加・削除することができるとともに、サービスを提供するためのアプリケーションをインストール又はアンインストールすることにより、サービスを追加・削除することができる。

例えば、画像処理装置１０は、コピーサービスを提供するコピーアプリケーションの
インストール又はアンインストールにより、コピーサービスの追加又は削除を行うことができる。また、例えば、コピーサービスが利用する機能（例えば両面コピー機能、２ｉｎ１コピー機能等）の追加又は削除を行うことができる。

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

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

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

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

操作部１００は、ＬＣＤ（Liquid Crystal Display）デバイスやタッチパネル、ハードキー等を備えるユーザインタフェースであり、画像処理装置１０に対して、ユーザが各種操作を行う。

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

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

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

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

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

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

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

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

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

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

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

入力装置２０１は、キーボードやマウス、タッチパネル等を含み、ＰＣ２０に各操作信号を入力するのに用いられる。表示装置２０２は、ＬＣＤやＣＲＴ（Cathode Ray Tube）等を含み、ＰＣ２０による処理結果を表示する。

外部Ｉ／Ｆ２０３は、外部装置とのインタフェースである。外部装置には、記録媒体２０３ａ等がある。記録媒体２０３ａには、例えば、画像処理装置１０から提供されるサービスを用いた各種処理（例えばコピー処理）の対象となる各種データ等を格納することができる。ＰＣ２０は外部Ｉ／Ｆ２０３を介して、記録媒体２０３ａの読み取り及び／又は書き込みを行うことができる。記録媒体２０３ａにはＵＳＢメモリ、ＳＤメモリカード（SD Memory card）、ＤＶＤ（Digital Versatile Disk）、ＣＤ（Compact Disk）、フレキシブルディスク等の記録媒体を用いることができる。

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

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

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

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

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

本実施形態に係る画像処理装置１０及びＰＣ２０は、例えば上記のハードウェア構成を有することにより、後述するような各種処理を実現することができる。

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

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

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

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

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

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

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

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

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

ＷｅｂＡＰＩ４１０は、例えば外部の機器（ＰＣ２０や他の画像処理装置１０等）が画像処理装置１０が提供する各種サービスを利用するためのＡＰＩの集まりである。画像処理装置１０は、ＷｅｂＡＰＩ４１０に含まれるＡＰＩ毎に、外部の機器からの要求を受け付ける。

要求管理部４２１は、例えばＣＰＵ１２１等により実現され、ＷｅｂＡＰＩ４１０から処理要求を受信し、ＡＰＩ制御部４２２に処理を依頼する。また、要求管理部４２１は、結果応答部４２４から処理結果を受信し、ＷｅｂＡＰＩ４１０に処理結果を送信する。

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

ＡＰＩ管理部４２３は、例えばＣＰＵ１２１等により実現され、リソース情報の登録要求があった場合、リソース情報を画像処理装置１０のフレームワーク４２０の例えばＨＤＤ１２３の所定の記憶領域に記憶する。また、ＡＰＩ管理部４２３は、リソース情報の取得要求があった場合、リソース情報を画像処理装置１０のフレームワーク４２０の所定の記憶領域から取得する。

結果応答部４２４は、例えばＣＰＵ１２１等により実現され、ソフトウェア群４０１の各アプリケーションや各モジュールが実行した機能の処理結果を作成し、要求管理部４２１に送信する。

ＡＰＩ情報変更部４２５は、例えばＣＰＵ１２１等により実現され、フレームワーク４２０の所定の記憶領域に記憶されているリソース情報を変更する。

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

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

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

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

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

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

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

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

次に、図５（ｃ）は、フレームワーク４２０の所定の記憶領域に記憶されているリソース情報の変更を行う場合の画像処理装置１０の処理の概要の一例を説明するための図である。

ＡＰＩ情報変更部４２５は、例えば画像処理装置１０の所定の記憶装置の残容量が、所定の基準値未満になったことを検知すると、ＡＰＩ管理部４２３に対してリソース情報の変更を要求する。すると、ＡＰＩ管理部４２３は、例えばＰＣ２０等から受信可能なデータ量の上限値が、より小さい値となるようにリソース情報を変更する。これにより、例えばＰＣ２０等がＡＰＩを介して画像処理装置１０に対して送信可能なデータ量が少なくなるように変更される。後述するように、図５（ｂ）及び図５（ｃ）で説明したリソース情報の登録や変更は、画像処理装置１０において動的に行われる。したがって、例えば、既に登録済みのリソース情報に対して変更の必要が生じた場合でも、画像処理装置１０を再起動させることなく、変更を行うことができる。

次に、リソース情報の詳細について説明する。図６は、リソース情報の一例の構成図である。図６に示すように、リソース情報は、ＵＲＬ、メソッド、システム、アクセス、認証方式等のデータ項目を有する。

ＵＲＬは、サービス部及びリソース部のデータ項目を有する。サービス部は、例えばプリンタアプリケーション４３３やアドレス帳管理サービス４５９等のサービスを特定する情報である。リソース部は、各サービスが有するリソース（機能）を特定する情報である。例えば、サービス部「printer」は、プリンタの状態を表示させる機能に関するリソース「status」と、プリントを実行する機能に関するリソース「job」の２つのリソースを有する。後述するように、サービス部（サービス名）とリソース部（リソース名）とを、例えばスラッシュ「/」で連結させてＵＲＬ形式とすることで、外部（ＰＣ２０や他の画像処理装置１０等）から利用可能なＡＰＩとして提供することができる。なお、リソース名は、同一のサービスにおいて一意（ユニーク）であればよい。

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

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

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

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

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

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

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

＜処理の詳細＞
次に、第１の実施形態に係る画像処理システム１の処理の詳細について説明する。

≪サービス提供処理≫
図７は、第１の実施形態に係るサービス提供処理の一例のシーケンス図である。

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

図８（ａ）のＨＴＴＰリクエストは、リクエスト部１００１、ヘッダ部１００２を有する。リクエスト部１００１に指定された「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」と特定することができる。これにより、図８（ａ）のＨＴＴＰリクエストは、アドレス帳管理サービス４５９のアドレス帳の状態の取得するためのＡＰＩを介して要求されたものであることを特定することができる。

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

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

ステップＳ１０６において、ＡＰＩ制御部４２２は、アドレス帳管理サービス４５９のアドレス帳状態の取得に関するリソース（リソース名「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」、リソース名が「groups」、データ項目がＰＯＳＴの「上限」及びＰＵＴの「上限」、変更後のデータ項目値が「1000」である場合、図１４に示すように、上限値を「5000」から「1000」に変更する。

以上により、画像処理装置１０の所定の記憶領域に記憶されているリソース情報を動的に変更することができる。換言すれば、画像処理装置１０の再起動等を行う必要なく、リソース情報の変更を行うことができる。したがって、例えば、画像処理装置１０に搭載されたメモリの残量が少なくなった場合（又は残量が増えた場合）等において、ＡＰＩを介してＰＣ２０等から受信するデータ量の上限値を動的に変更（増加又は減少）することができる。

なお、上記では、画像処理装置１０がＡＰＩを介してＰＣ２０等から受信するデータ量の上限を変更する場合について説明したが、これに限られず、変更要求に応じてリソース情報の他のデータ項目を変更してもよい。例えば、データ項目「権限」を「一般ユーザ」から「管理者」に変更する、電力制御を「×」から「○」に変更する等である。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

＜処理の詳細＞
次に、第２の実施形態に係る画像処理システム１の処理の詳細について説明する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ステップＳ７１０において、結果応答部４２４は、応答要求からＨＴＴＰレスポンスを生成する。なお、このとき生成されるＨＴＴＰレスポンスのボディ部には、上記のステップＳ７０８で作成されたＡＰＩリストが所定のデータ形式で記述（指定）される。

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

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

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

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

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

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

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

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

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

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

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

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

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

＜処理の詳細＞
次に、第３の実施形態に係る画像処理システム１の処理の詳細について説明する。本実施形態は、図１８におけるステップＳ７０７のリソース情報の取得処理が第２の実施形態と異なる。したがって、以降ではリソース情報の取得処理のみ説明する。図２１は、第２の実施形態に係るリソース情報の取得処理の他の例のフローチャートである。なお、図２１においてステップＳ９０２〜ステップＳ９０５の処理は、それぞれ図２０で説明したステップＳ８０１〜ステップＳ８０４の処理と同様であるため、これらの処理についても説明を省略する。

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

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

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

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

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

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

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

なお、ＡＰＩ管理部４２３は、ＡＰＩ管理手段の一例である。ＷｅｂＡＰＩ４１０は、インタフェース手段の一例である。ＡＰＩ制御部４２２は、サービス提供手段の一例である。ＡＰＩ情報変更部４２５は、変更手段の一例である。ＡＰＩリスト作成部４２６は、取得手段及びリスト生成手段の一例である。

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

１ 画像処理システム
１０ 画像処理装置
２０ ＰＣ
４１０ ＷｅｂＡＰＩ
４２０ フレームワーク
４２１ 要求管理部
４２２ ＡＰＩ制御部
４２３ ＡＰＩ管理部
４２４ 結果応答部
４２４ＡＰＩ情報変更部
４２６ ＡＰＩリスト作成部

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

Claims (10)

1. ネットワークを介して接続された機器からの要求に応じて所定の機能を利用したサービスを提供する情報処理装置であって、
   前記サービスと該サービスが利用する機能毎に、前記機器から前記機能を利用したサービスの要求を受け付けるためのＡＰＩを示す情報と、該ＡＰＩを用いて提供される機能に関する情報とを関連付けて所定の記憶領域に記憶させるＡＰＩ管理手段と、
   前記機器から前記要求を前記ＡＰＩ毎に受け付けるインタフェース手段と、
   前記インタフェース手段により前記要求を受け付けると、前記機能に関する情報に基づき、前記要求に対応するサービスの機能を実行させて、該サービスを提供するサービス提供手段と、
   前記機器からの要求又は前記情報処理装置の状態に応じて前記所定の記憶領域に記憶されている前記機能に関する情報を動的に変更する変更手段と、
   を有する情報処理装置。
2. 前記要求を受け付けると、該要求を受け付けたインタフェース手段に対応するＡＰＩを特定する特定手段を有し、
   前記サービス提供手段は、
   前記特定されたＡＰＩに対応する機能に関する情報に基づき、該ＡＰＩと対応するサービスの機能を実行させて、該サービスを提供する、請求項１記載の情報処理装置。
3. 前記機能に関する情報は、該機能に関する情報に対応する機能を利用したサービスを提供する場合に前記情報処理装置が前記機器から受信可能なデータの上限値を含み、
   前記変更手段は、
   前記機器からの前記機能に関する情報の変更要求、又は、前記情報処理装置に搭載されている所定の記憶装置の総容量の変化若しくは該所定の記憶装置の残容量の変化に応じて、前記所定の記憶領域に記憶されている前記機能に関する情報に含まれる前記上限値を動的に変更する、請求項１又は２記載の情報処理装置。
4. 前記情報処理装置に搭載されている所定の記憶装置は、ＲＡＭ又はＨＤＤである、請求項３記載の情報処理装置。
5. 前記ＡＰＩは、サービスのサービス名と、該サービスが利用する機能のリソース名とを連結させてＵＲＬ形式で表した情報である、請求項１ないし４のいずれか１項に記載の情報処理装置。
6. 前記ＡＰＩ管理手段は、
   前記サービスが利用する機能が追加された場合、前記機器から前記追加された機能を利用したサービスの要求を受け付けるためのＡＰＩを示す情報と、前記追加された機能に関する情報とを関連付けて前記所定の記憶領域に記憶させる、請求項１ないし５のいずれか１項に記載の情報処理装置。
7. 前記ＡＰＩ管理手段は、
   前記サービスが利用する機能が削除された場合、前記機器から前記削除された機能を利用したサービスの要求を受け付けるためのＡＰＩを示す情報と、該ＡＰＩを示す情報と関連付けて前記所定の記憶領域に記憶されている前記削除された機能に関する情報とを削除する、請求項１ないし６のいずれか１項に記載の情報処理装置。
8. 前記インタフェース手段により前記機器から前記情報処理装置が提供するサービスのリストの取得要求を受け付けると、前記所定の記憶領域に記憶されているＡＰＩを示す情報と、該ＡＰＩを用いて提供される機能に関する情報とを取得する取得手段と、
   前記取得手段により取得された前記ＡＰＩを示す情報及び前記機能に関する情報のうち、前記機器が利用することができるサービス及び機能に対応する前記ＡＰＩを示す情報を含むリストを生成するリスト生成手段と、
   を有する請求項１ないし７のいずれか１項に記載の情報処理装置。
9. 機器と、該機器からの要求に応じて所定の機能を利用したサービスを提供する情報処理装置とがネットワークを介して接続された情報処理システムであって、
   前記サービスと該サービスが利用する機能毎に、前記機器から前記機能を利用したサービスの要求を受け付けるためのＡＰＩを示す情報と、該ＡＰＩを用いて提供される機能に関する情報とを関連付けて所定の記憶領域に記憶させるＡＰＩ管理手段と、
   前記機器から前記要求を前記ＡＰＩ毎に受け付けるインタフェース手段と、
   前記インタフェース手段により前記要求を受け付けると、前記機能に関する情報に基づき、前記要求に対応するサービスの機能を実行させて、該サービスを提供するサービス提供手段と、
   前記機器からの要求又は前記情報処理装置の状態に応じて前記所定の記憶領域に記憶されている前記機能に関する情報を動的に変更する変更手段と、
   を有する情報処理システム。
10. ネットワークを介して接続された機器からの要求に応じて所定の機能を利用したサービスを提供する情報処理装置における情報処理方法であって、
    前記サービスと該サービスが利用する機能毎に、前記機器から前記機能を利用したサービスの要求を受け付けるためのＡＰＩを示す情報と、該ＡＰＩを用いて提供される機能に関する情報とを関連付けて所定の記憶領域に記憶させるＡＰＩ管理手順と、
    前記機器から前記要求を前記ＡＰＩ毎に受け付けるインタフェース手順と、
    前記インタフェース手順により前記要求を受け付けると、前記機能に関する情報に基づき、前記要求に対応するサービスの機能を実行させて、該サービスを提供するサービス提供手順と、
    前記機器からの要求又は前記情報処理装置の状態に応じて前記所定の記憶領域に記憶されている前記機能に関する情報を動的に変更する変更手順と、
    を有する情報処理方法。

Images