JP4274227B2 - 画像処理装置及びプログラム - Google Patents

Description

本発明は、画像処理装置及びプログラムに関する。

複数の機能を含むアプリケーション（以下、「アプリ」とも記載する。）を新規にインストールすることが可能な画像処理装置にアプリケーションをインストールした場合、画像処理装置においてアプリケーションが動作する際、当該アプリケーションが予め用意された画像処理装置の機能を利用するためのＡＰＩ（アプリケーション・プログラミング・インタフェース）を呼び出すことが行われることが多い。このようなケースにおいて、利用可能なＡＰＩに制限をかける構成が特許文献１に開示されている。

特開２００５−２５８９２４号公報

利用可能なＡＰＩと利用できないＡＰＩとが混在する場合、ＡＰＩが利用できないことによりアプリケーションを利用できない場合が生じ得るが、ユーザは、実際にアプリケーションを動作させるまで、その旨を知ることができず、ユーザ側から見ればアプリケーションが動作しないというトラブルと認識されることもあるという問題点がある。

本発明は係る問題点に鑑みてなされたものであって、ＡＰＩの利用可否によるアプリケーション利用の可否を容易に判断することができる画像処理装置及びプログラムを提供することを目的としている。

上記の問題点を解決するために、本発明に係る画像処理装置は、複数の機能を有するアプリケーションを取得するアプリケーション取得手段と、ＡＰＩ毎の実行可否を判定するための、ＡＰＩ毎に関連する画像処理装置の機能設定情報及び／又は関連する画像処理装置の状態情報を格納したＡＰＩ情報格納手段と、前記ＡＰＩ情報格納手段の内容を参照して、ＡＰＩ毎に対応した機能設定情報及び／又は状態情報を取得する取得手段と、前記取得手段によって取得された機能設定情報及び／又は状態情報に基づいて、ＡＰＩ毎の実行可否を判定する判定手段と、ＡＰＩ毎の実行可否判定結果に基づいて、アプリケーションの有する複数の機能のうち、実行不可機能を抽出する抽出手段と、前記複数の機能の中で、ＡＰＩが使用できないために利用できない機能が存在する場合に、その旨をユーザに報知する報知手段とを備えることを特徴としている。

前記報知手段は、前記複数の機能の全てが利用できない場合に、当該アプリケーションが利用できない旨をユーザに報知する構成とすることができる。

画像処理装置は、ユーザ毎の機能毎の権限情報を格納したユーザ情報格納手段をさらに備え、前記判定手段は、前記ユーザ情報格納手段から、前記取得手段にて取得された機能設定情報に対応するログインユーザの権限情報を参照して、ＡＰＩ毎の実行可否を判定する構成とすることができる。

画像処理装置は、装置設定情報を格納する設定情報格納手段をさらに備え、前記判定手段は、前記設定情報格納手段から、前記取得手段にて取得された機能設定情報に対応する設定情報を参照して、ＡＰＩ毎の実行可否を判定する構成とすることができる。

画像処理装置は、装置状態情報を格納する状態情報格納手段をさらに備え、前記判定手段は、前記状態情報格納手段から、前記取得手段にて取得された状態情報に対応する状態情報を参照して、ＡＰＩ毎の実行可否を判定する構成とすることができる。

画像処理装置は、アプリケーションが有する複数の機能毎に、呼び出されるＡＰＩ情報を取得するアプリケーション機能別ＡＰＩ情報取得手段をさらに備え、前記抽出手段は、取得した機能毎のＡＰＩ情報と、判定された実行不可ＡＰＩ情報とに基づいて、実行不可機能を抽出し、前記報知手段は、アプリケーションの有する複数機能のうち一部が実行不可である場合には、当該アプリケーションをアプリケーション単位で選択可能に表示する一方、そのアプリケーションが有する実行不可機能についての報知を行う構成とすることができる。
前記アプリケーション機能別ＡＰＩ情報取得手段は、前記アプリケーションが有する複数の機能と、当該複数の機能の各々に対応して呼び出されるＡＰＩ情報との関係を保持するファイルを外部から取得する構成とすることができる。

前記報知手段は、アプリケーションが利用できない場合と、一部の機能が利用できない場合とで、報知の方法を切り替える構成とすることができる。

本発明に係るプログラムは、プロセッサを備える画像処理装置にインストールされるプログラムであって、複数の機能を有するアプリケーションを取得するアプリケーション取得処理と、ＡＰＩ毎の実行可否を判定するための、ＡＰＩ毎に関連する画像処理装置の機能設定情報及び／又は関連する画像処理装置の状態情報を格納したＡＰＩ情報格納手段の内容を参照して、ＡＰＩ毎に対応した機能設定情報及び／又は状態情報を取得する取得処理と、前記取得処理によって取得された機能設定情報及び／又は状態情報に基づいて、ＡＰＩ毎の実行可否を判定する判定処理と、ＡＰＩ毎の実行可否判定結果に基づいて、アプリケーションの有する複数の機能のうち、実行不可機能を抽出する抽出処理と、前記複数の機能の中で、ＡＰＩが使用できないために利用できない機能が存在する場合に、その旨をユーザに報知する報知処理とを前記プロセッサに実行させることを特徴としている。

本発明に係る画像処理装置によると、ＡＰＩの利用可否によるアプリケーション利用の可否を容易に判断することができるという効果を奏する。

以下、本発明の実施の形態について、図面を参照しながら説明する。
（１）ネットワークシステムの構成

図１は、本実施の形態におけるネットワークシステムの構成の一例を示す図である。本実施の形態では、ＭＦＰ（マルチ・ファンクション・ペリフェラル）１００とＰＣ３１とが、ＬＡＮ等のネットワーク５００を介して接続されており、ＭＦＰ１００上で動作するアプリケーションを、ＰＣ３１からダウンロードすることが可能な構成となっている。ＭＦＰ１００内には、予め各種ＡＰＩが搭載されており、ダウンロードされたアプリケーションは、当該ＡＰＩを呼び出してアプリケーションの機能を実現する。

（２）ＭＦＰ１００の構成
次に、ＭＦＰ１００の構成について説明する。図２は、ＭＦＰ１００のハードウェア構成の一例を示す図である。

ＭＦＰ１００は、操作部１１、ディスプレイ部１２、スキャナ部１３、プリンタ部１４、通信インタフェース１６、ドキュメントフィーダ１７、給紙装置１８、ＣＰＵ２０、ＲＯＭ２１、ＲＡＭ２２、およびハードディスク２３などによって構成される。

操作部１１は、数字、文字、および記号などを入力するための複数のキー、押下されたキーを認識するセンサ、および認識したキーを示す信号をＣＰＵ２０に送信する送信用回路などによって構成される。

ディスプレイ部１２は、ユーザに対してメッセージを表示する画面、ユーザが設定内容や処理内容を入力するための画面、およびＭＦＰ１００で実行された処理の結果を示す画面などを表示する。本実施の形態ではディスプレイ部１２にタッチパネルが用いられており、これは操作部１１に含まれる。タッチパネルは、ユーザが指で触れたタッチパネル上の位置を検知し、検知結果を示す信号をＣＰＵ２０に送信する機能を備えている。

スキャナ部１３は、原稿に光を照射して反射光を検出することにより、原稿に描かれている画像を所定の読み取り解像度で読み取って、デジタルの画像データ（ここでは、ＲＧＢまたはブラックの濃度を表す濃度データ）を生成する。

得られた画像データは、プリンタ部１４において印刷のために用いられるほか、ＴＩＦＦ、ＰＤＦ、ＪＰＥＧなどの形式のファイルに変換されてハードディスク２３に記憶される。ＦＡＸデータに変換されてＦＡＸ送信に供されることもある。また、前記したようにメールに添付されて外部に送信されることもある。ドキュメントフィーダ１７は、例えばＭＦＰ１００の本体上部に設けられており、１枚または複数枚の原稿をスキャナ部１３に順次送るために用いられる。

プリンタ部１４は、スキャナ部１３にて読み取られた画像、ＬＡＮ等のネットワークを介して接続された他のＭＦＰ等の外部装置から送信されてきたデータの画像、またはＦＡＸ受信したＦＡＸデータの画像を、用紙またはフイルムなどの記録シートに印刷する。

給紙装置１８は、例えばＭＦＰ１００本体下部に設けられており、記録シートをプリンタ部１４に供給するために用いられる。プリンタ部１４によって画像が印刷された記録シートは、例えば排紙トレイ上に排出される。

通信インタフェース１６は、ＰＣ３１、メールサーバ３３等の外部装置とＬＡＮ、ＷＡＮ等のネットワークを介して通信を行ったり、電話回線を通じてＦＡＸ送受信を行ったりするためのインタフェースである。通信インタフェース１６として、例えばＮＩＣ（ネットワーク・インタフェース・カード）、ＴＡ（ターミナル・アダプタ）などを用いることができる。

ＲＯＭ２１には、画像の読取（スキャン）、原稿の複写（コピー）、ＦＡＸデータの送受信、ネットワークプリンティング、およびドキュメントサーバ（ボックス機能）などのＭＦＰ１００の基本機能を実現するためのプログラム、データが記憶されている。そのほか、本実施の形態の機能を実現するプログラムおよびデータが記憶されている。

なお、これらのプログラムまたはデータの一部または全部を、ハードディスク２３にインストールしておいてもよい。この場合は、ハードディスク２３にインストールされているプログラムまたはデータは、必要に応じてＲＡＭ２２にロードされる。

本実施の形態で説明する機能は、必ずしもＣＰＵ２０だけでなく専用ハードウェアを利用したり、一部はオペレーティングシステム（ＯＳ）等の汎用プログラムの機能を利用して実現することもできる。

図３は、本実施の形態のＭＦＰ１００の機能的構成の一例について説明するためのブロック図である。ＭＦＰ１００は、アプリ取得部２０１、アプリ情報管理部２０２、ＵＩ表示部２０３を備えている。これらの各部の機能は、ＲＯＭ２１やＲＡＭ２２に格納されたプログラムがＣＰＵ２０上で動作することにより実現される。なお、ハードディスク２３は、アプリ情報格納部２３１、機能情報格納部２３２、ユーザ情報格納部２３３、ＭＦＰ情報格納部２３４、ＡＰＩ情報格納部２３５、実行不可情報格納部２３６を含んでいる。

アプリ取得部２０１は、ＰＣ３１からアプリケーションをダウンロードし、ＭＦＰ１００にインストールする。インストールされたアプリケーションは、ＭＦＰ１００内に予め用意されたＡＰＩを呼び出して機能を実現する。

アプリ情報管理部２０２は、ハードディスク２３に格納されたアプリケーションに関する各種情報を管理する。ＵＩ表示部２０３は、ディスプレイ部１２へのユーザインタフェース画面の表示内容を制御する。

図４は、アプリ情報格納部２３１に格納されるアプリケーション情報（アプリ情報）の内容の一例を示す図である。本実施の形態では、アプリ情報として、アプリケーション名、ファイルサイズ、バージョン、アプリケーションを販売している会社名、及び当該アプリケーションで使用されるＡＰＩが規定されたＡＰＩリストのファイル名が格納される。格納される内容は、これに限定されないことは勿論であり、例えばインストールされた日付や時刻、必要なデジタル証明書などを併せて格納することもできる。

上記したＡＰＩリストのファイルは、本実施の形態ではＸＭＬ形式のファイルとして機能情報格納部２３２に格納される。図５は、ＡＰＩリストのファイルの内容の一例を示す図であり、アプリケーションごとに、複数の機能、及び当該機能を実現するために呼び出されるＡＰＩが定義される。同図の例では、「帳簿印刷」の機能と「帳簿登録」の機能とが例示されており、それぞれの機能を利用する際に呼び出されるＡＰＩが記述されている。このＡＰＩリストは、予め作成しておき、例えばアプリケーションをダウンロードする際にダウンロード先から取得することができる。

図６は、ユーザ情報格納部２３３に格納されるユーザ情報の内容の一例を示す図である。本実施の形態では、ユーザごとに付与されたユーザ番号、所属部署、氏名、及び各ユーザの権限情報が保持される。権限情報として、本実施の形態では、コピー、スキャン、ＦＡＸの各機能の利用権限の有無、プリント枚数の上限と実際のプリント枚数、管理者権限の有無が格納されている。実際のプリント枚数については、ほぼリアルタイムに更新される。また、プリント枚数の上限が月単位で設定されていれば、月が切り替わったときに「実際のプリント枚数」は、一旦リセットされた後に、カウントアップが継続される。権限情報は、これに限定されず、他の機能（例えばボックスの作成など）の利用権限の有無を保持することもできる。

図７は、ＭＦＰ情報格納部２３４に格納されるＭＦＰ情報の内容の一例を示す図である。本実施の形態では、ＭＦＰ情報として、同図（ａ）に示されるＭＦＰ設定情報と、同図（ｂ）に示されるＭＦＰ状態情報とがある。ＭＦＰ状態情報は動的に変化する。

図８は、ＡＰＩ情報格納部２３５に格納されるＡＰＩ情報の内容の一例を示す図である。本実施の形態では、ＡＰＩ情報として、同図（ａ）に示されるＡＰＩ関連機能情報と、同図（ｂ）に示されるＡＰＩ関連状態情報とがある。ＡＰＩ関連機能情報とは、ＡＰＩごとに、関連する機能を表すものである。

同図において、「○」は、当該ＡＰＩが各機能と関連があることを示し、「×」は関連がないことを示している。また、「Ｕ」が設定されている場合には、ユーザ情報を参照してＡＰＩの利用可否が決定されることを意味する。プリント枚数の上限はユーザにより異なるからである。また、「ＭＳ」が設定されている場合は、ＭＦＰ設定情報（図７（ａ）の例では「セキュリティ強化モードの設定」）を参照してＡＰＩの利用可否が決定されることを意味する。

ＡＰＩ関連状態情報とは、ＡＰＩごとに関連する状態（ＭＦＰの状態）を表すものである。例えばＡＰＩ「ＣｒｅａｔｅＢｏｘ」の利用可否の判定には、ハードディスクの状態を参照することを表している。なお、ＡＰＩ関連機能情報やＡＰＩ関連状態情報が上記に規定されたものに限定されないことは勿論である。

実行不可情報格納部２３６には、上記に説明した各部の情報から、実行することができないＡＰＩ、及びＡＰＩが実行できないことにより、利用できないアプリケーションの機能などに関する情報を格納する。この実行不可情報については、後に詳細に説明する。

（３）ＭＦＰ１００の処理内容
以下、本実施の形態のＭＦＰ１００の処理内容について説明する。図９は、ＭＦＰ１００の処理内容の一例について説明するためのフローチャートである。なお、本実施の形態においてフローチャートにより説明される処理は、当該処理を実現するプログラムがＲＯＭ２１上で動作することにより実現される。

ＭＦＰ１００は、アプリケーションの一覧表示が指示された場合（Ｓ１０１：ＹＥＳ）、まず、その時点でＭＦＰ１００にログインしているユーザのユーザＩＤを取得する（Ｓ１０２）。ＭＦＰ１００を使用しているユーザがユーザ認証を経ていない場合も有り得るが、その場合には、例えば「Ｇｕｅｓｔ」といったユーザＩＤを付与しておくことができ、そのユーザＩＤが取得される構成とすることができる。

次に、ユーザ情報格納部２３３の内容を参照して、ユーザ情報を取得する（Ｓ１０３）。なお、ユーザ情報は、操作部１１などを介して、予め登録しておくことができる。次に、ＭＦＰ情報格納部２３４に格納されているＭＦＰ情報を取得する（Ｓ１０４）。そして、実行可否判定処理を行う（Ｓ１０５）。

図１０は、実行可否判定処理の内容の一例について説明するためのフローチャートである。実行可否判定処理とは、ＡＰＩごとの実行可否を判定し、最終的に当該ＡＰＩを呼び出すアプリケーションの複数の機能（アプリケーション「帳簿管理」の場合であれば、機能としては「帳簿印刷」、「帳簿登録」等）の実行可否を判定する処理である。

実行可否判定処理では、まず、アプリケーションごとに、使用するＡＰＩ及びパラメータ設定を取得する（Ｓ２０１）。この情報取得は、図５に例示されるＡＰＩリストのファイル（本実施の形態ではＸＭＬ形式）の内容を参照して行うことができる。

そして、ＡＰＩ関連機能を取得する（Ｓ２０２）。ここで、ＡＰＩ関連機能とは、図５のＡＰＩリストにおいて、＜Ｆｕｎｃｔｉｏｎ＞タグに記載されている各機能である。図５に示されるように、関連機能には、呼び出されるＡＰＩが対応付けられているため、ステップＳ２０１で取得したＡＰＩから、関連機能を取得することができる。

次に、図６に例示されるユーザ情報と、図８に例示されるＡＰＩ関連機能情報、ＡＰＩ関連状態情報を参照し、ユーザ情報による実行不可ＡＰＩを抽出する（Ｓ２０３）。例えば、図８で、ＡＰＩ「ＣｒｅａｔｅＪｏｂ」において、ＡＰＩ関連機能情報において上限管理が「Ｕ」が設定されているので、ユーザ情報を参照し、ユーザ情報として保持されているプリント枚数が上限に到達していれば、もはや当該ユーザはプリント処理を実行することができないのであるから、ＡＰＩ「ＣｒｅａｔｅＪｏｂ」を利用することができない。

また、「ＣｒｅａｔｅＢｏｘ」については、ＡＰＩ関連状態情報を参照して、スキャナ状態が関連していることがわかるため、ユーザにスキャンの権限が無い場合には、やはり当該ＡＰＩを利用することができない。このように実行不可ＡＰＩを抽出した後、実行不可ＡＰＩが存在する場合（Ｓ２０４：ＹＥＳ）、実行不可ＡＰＩ情報を実行不可情報格納部２３６に書き込む（Ｓ２０５）。図１１は、実行不可情報格納部２３６の内容の一例について説明するための図である。

実行不可情報格納部２３６には、図１１（ａ）に示されるような実行不可ＡＰＩ情報と図１１（ｂ）に示されるような実行不可機能情報とが格納される。上記のステップＳ２０５では、実行不可ＡＰＩ情報が書き込まれる。本実施の形態では、この際に、実行不可な理由（例えば「プリント枚数上限到達」）が併せて格納される。この理由は、後述するようなディスプレイ部１２への表示によるユーザへの実行可否報知に利用される。

次にＭＦＰ情報による実行不可ＡＰＩの抽出を行う（Ｓ２０６）。図７に例示したようにＭＦＰ情報にはＭＦＰ設定情報とＭＦＰ状態情報とがあるが、ここでは、その両者を参照して実行不可ＡＰＩを抽出する。例えば、アドレス帳設定が禁止されている場合には、アドレス帳設定を行うＡＰＩは実行できないし、ハードディスク２３の状態がレディでない場合には、ハードディスクにアクセスするＡＰＩは実行できない。このように、ＭＦＰ状態も参照して、実行不可ＡＰＩが抽出される。

ＭＦＰ情報による実行不可ＡＰＩが存在する場合には（Ｓ２０７：ＹＥＳ）、ステップＳ２０５と同様に実行不可情報格納部２３６に実行不可ＡＰＩ情報を書き込む（Ｓ２０８）。図１２のフローチャートへと進み、全ての実行不可ＡＰＩ抽出が終了すると（Ｓ２０９：ＹＥＳ）、実行不可ＡＰＩが存在することによる実行不可機能を抽出する（Ｓ２１０）。

実行不可機能が存在する場合には（Ｓ２１１：ＹＥＳ）、実行不可情報格納部２３６に実行不可機能情報を書き込む（Ｓ２１２）。この結果、図１１（ｂ）に例示したような実行不可機能情報が書き込まれる。

図４に例示したアプリ情報が登録された全てのアプリケーションについて、実行不可機能の抽出が終了すると（Ｓ２１３：ＹＥＳ）、全ての機能が実行不可であるアプリケーションが存在するか否かを判定する（Ｓ２１４）。全ての機能が実行不可であるアプリケーションが存在する場合には（Ｓ２１４：ＹＥＳ）、当該アプリケーションを実行不可アプリとして登録する（Ｓ２１５）。この処理は、例えば図４のテーブルに実行不可フラグをセットするような形態も可能である。

以上で、実行可否判定処理を終了し、図９のフローチャートへと戻ってアプリ一覧表示を行う（Ｓ１０７）。この処理では、ディスプレイ部１２にアプリケーションの一覧を表示する。図１３は、一覧表示された状態の一例を示す図である。

同図に示されるように、本実施の形態のアプリ一覧表示では、全機能が実行可能であるアプリケーション（同図の例では「本箱」）、一部の機能が実行不可であるアプリケーション（同図の例では「帳簿管理」、「簡単セットアップ」）、及び全機能が実行不可であるアプリケーション（同図の例では「ホームページ印刷」）で、表示の方法を切り替えるとともに、実行不可機能を報知する。この表示の切り替えは、実行不可機能情報を参照して行うことができる。なお、同図において全機能が実行不可であるアプリケーションについては、当該ボタンが押下された場合でもアプリケーションが起動しない構成とすることが好ましく、また当該ボタン自体を表示しないような構成としても良い。

以上に説明したように、本実施の形態では、アプリ一覧表示において、実行不可であるアプリケーションが選択不能に表示されるだけでなく、ＡＰＩが利用できないことにより実行できない機能が存在することを容易に識別することができるので、例えばユーザがアプリケーションの動作中に該機能を動作させようとして動作せず、対応に困るといった事態の発生を防止することができる。また、ＡＰＩの利用可／不可の判断は、動的に変化する状態を反映させて行うことができ、固定的な設定値をいちいち再設定する必要がない。

（変形例）
以上、本発明の実施の形態について説明したが、本発明の内容が上記実施の形態において説明された具体例によって限定されないことは勿論であり、例えば、以下のような変形例を実施することもできる。

即ち、上記実施の形態では、ＰＣ３１からアプリケーションをインストールする場合について説明したが、アプリケーションのインストールは、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、ＵＳＢメモリ、その他の各種媒体から実行することもでき、いずれの場合も本発明を適用することは可能である。

また、上記実施の形態では、実行可否判定処理がアプリケーション一覧表示指示があった際に行われるが、アプリケーション立ち上げ後にも随時実行可否判定処理を行ってもよい。その場合には、動的な状態変化にも、より正確に実行可否判定が行える。

本発明は、例えば、画像処理装置に適用することができる。

本実施の形態におけるネットワークシステムの構成の一例を示す図である。 ＭＦＰ１００のハードウェア構成の一例を示す図である。 本実施の形態のＭＦＰ１００の機能的構成の一例について説明するためのブロック図である。 アプリ情報格納部２３１に格納されるアプリケーション情報（アプリ情報）の内容の一例を示す図である。 ＡＰＩリストのファイルの内容の一例を示す図である。 ユーザ情報格納部２３３に格納されるユーザ情報の内容の一例を示す図である。 ＭＦＰ情報格納部２３４に格納されるＭＦＰ情報の内容の一例を示す図である。 ＡＰＩ情報格納部２３５に格納されるＡＰＩ情報の内容の一例を示す図である。 ＭＦＰ１００の処理内容の一例について説明するためのフローチャートである。 実行可否判定処理の内容の一例について説明するためのフローチャートである。 実行不可情報格納部２３６の内容の一例について説明するための図である。 実行可否判定処理の内容の一例について説明するためのフローチャートである。 アプリケーションの一覧が表示された状態の一例を示す図である。

符号の説明

１１ 操作部
１２ ディスプレイ部
１３ スキャナ部
１４ プリンタ部
１６ 通信インタフェース
１７ ドキュメントフィーダ
１８ 給紙装置
２０ ＣＰＵ
２１ ＲＯＭ
２２ ＲＡＭ
２３ ハードディスク
３１ パーソナル・コンピュータ（ＰＣ）
２０１ アプリ取得部
２０２ アプリ情報管理部
２０３ ＵＩ表示部
２３１ アプリ情報格納部
２３２ 機能情報格納部
２３３ ユーザ情報格納部
２３４ ＭＦＰ情報格納部
２３５ ＡＰＩ情報格納部
２３６ 実行不可情報格納部
５００ ネットワーク

Claims (9)

1. 複数の機能を有するアプリケーションを取得するアプリケーション取得手段と、
   ＡＰＩ毎の実行可否を判定するための、ＡＰＩ毎に関連する画像処理装置の機能設定情報及び／又は関連する画像処理装置の状態情報を格納したＡＰＩ情報格納手段と、
   前記ＡＰＩ情報格納手段の内容を参照して、ＡＰＩ毎に対応した機能設定情報及び／又は状態情報を取得する取得手段と、
   前記取得手段によって取得された機能設定情報及び／又は状態情報に基づいて、ＡＰＩ毎の実行可否を判定する判定手段と、
   ＡＰＩ毎の実行可否判定結果に基づいて、アプリケーションの有する複数の機能のうち、実行不可機能を抽出する抽出手段と、
   前記複数の機能の中で、ＡＰＩが使用できないために利用できない機能が存在する場合に、その旨をユーザに報知する報知手段とを備える
   ことを特徴とする画像処理装置。
2. 前記報知手段は、
   前記複数の機能の全てが利用できない場合に、当該アプリケーションが利用できない旨をユーザに報知する
   ことを特徴とする請求項１に記載の画像処理装置。
3. ユーザ毎の機能毎の権限情報を格納したユーザ情報格納手段をさらに備え、
   前記判定手段は、
   前記ユーザ情報格納手段から、前記取得手段にて取得された機能設定情報に対応するログインユーザの権限情報を参照して、ＡＰＩ毎の実行可否を判定する
   ことを特徴とする請求項１又は２に記載の画像処理装置。
4. 装置設定情報を格納する設定情報格納手段をさらに備え、
   前記判定手段は、
   前記設定情報格納手段から、前記取得手段にて取得された機能設定情報に対応する設定情報を参照して、ＡＰＩ毎の実行可否を判定する
   ことを特徴とする請求項１から３のいずれかに記載の画像処理装置。
5. 装置状態情報を格納する状態情報格納手段をさらに備え、
   前記判定手段は、
   前記状態情報格納手段から、前記取得手段にて取得された状態情報に対応する状態情報を参照して、ＡＰＩ毎の実行可否を判定する
   ことを特徴とする請求項１から４のいずれかに記載の画像処理装置。
6. アプリケーションが有する複数の機能毎に、呼び出されるＡＰＩ情報を取得するアプリケーション機能別ＡＰＩ情報取得手段をさらに備え、
   前記抽出手段は、取得した機能毎のＡＰＩ情報と、判定された実行不可ＡＰＩ情報とに基づいて、実行不可機能を抽出し、
   前記報知手段は、アプリケーションの有する複数機能のうち一部が実行不可である場合には、当該アプリケーションをアプリケーション単位で選択可能に表示する一方、そのアプリケーションが有する実行不可機能についての報知を行う
   ことを特徴とする請求項１から５のいずれかに記載の画像処理装置。
7. 前記アプリケーション機能別ＡＰＩ情報取得手段は、
   前記アプリケーションが有する複数の機能と、当該複数の機能の各々に対応して呼び出されるＡＰＩ情報との関係を保持するファイルを外部から取得する
   ことを特徴とする請求項６に記載の画像処理装置。
8. 前記報知手段は、
   アプリケーションが利用できない場合と、一部の機能が利用できない場合とで、報知の方法を切り替える
   ことを特徴とする請求項１から７のいずれかに記載の画像処理装置。
9. プロセッサを備える画像処理装置にインストールされるプログラムであって、
   複数の機能を有するアプリケーションを取得するアプリケーション取得処理と、
   ＡＰＩ毎の実行可否を判定するための、ＡＰＩ毎に関連する画像処理装置の機能設定情報及び／又は関連する画像処理装置の状態情報を格納したＡＰＩ情報格納手段の内容を参照して、ＡＰＩ毎に対応した機能設定情報及び／又は状態情報を取得する取得処理と、
   前記取得処理によって取得された機能設定情報及び／又は状態情報に基づいて、ＡＰＩ毎の実行可否を判定する判定処理と、
   ＡＰＩ毎の実行可否判定結果に基づいて、アプリケーションの有する複数の機能のうち、実行不可機能を抽出する抽出処理と、
   前記複数の機能の中で、ＡＰＩが使用できないために利用できない機能が存在する場合に、その旨をユーザに報知する報知処理とを前記プロセッサに実行させる
   ことを特徴とするプログラム。

Images