JP6962156B2 - 画像処理装置、画像処理装置の制御方法、画像処理システム、およびプログラム - Google Patents

Description

本発明は、ＭＦＰ（マルチ・ファンクション・ペリフェラル（Multi-Functional Peripheral））などの画像処理装置およびそれに関連する技術に関する。

近年、ウエブサーバによるサービスにおいてＡＰＩ（アプリケーションプログラミングインタフェース（Application Programming Interface））が提供され、サービスを受ける側のクライアントが当該ＡＰＩを利用する技術が存在する。具体的には、クライアントからサーバに対してＡＰＩリクエスト（たとえば、天気予報の表示に利用可能なＡＰＩのリクエスト）を送信し、当該ＡＰＩリクエストに応じて返信されてきたレスポンス情報に基づき、所定の情報（天気予報の情報）等を表示することなどが行われる。

また、特許文献１においては、ＭＦＰ（画像処理装置）内に内部サーバ（ＡＰＩサーバとして機能する）を設け、ＭＦＰにおけるジョブ操作に関するＡＰＩのリクエスト（ＡＰＩリクエスト）がＭＦＰの装置内部のブラウザから内部サーバに送信されると、当該内部サーバからレスポンス情報（ＡＰＩレスポンス）がブラウザに返信されることが記載されている。たとえば、ページ記述言語（ＨＴＭＬ等）およびＡＰＩ（ＭＦＰのジョブ設定操作に関するＡＰＩ、および／またはジョブの実行操作に関するＡＰＩ等）を利用して、当該ブラウザ内にＭＦＰの操作画面を構築し、当該操作画面を用いてＭＦＰを操作することが可能である。

ＭＦＰ（画像処理装置）のＡＰＩサーバは、ＭＦＰの内部のブラウザからのＡＰＩリクエストのみならずＭＦＰの外部装置（クライアント）からのＡＰＩリクエストに応じてレスポンス情報を返信することも可能である。換言すれば、上述のクライアント（外部クライアント）によるウエブサーバへのＡＰＩリクエスト等を実行する技術を、ＭＦＰ（画像処理装置）内のＡＰＩサーバに関して適用することも考えられる。

より具体的には、ＭＦＰ内にＡＰＩサーバを設け、ＭＦＰにおけるジョブ操作に関するＡＰＩのリクエスト（ＡＰＩリクエスト）がクライアント（外部クライアント）からＭＦＰ（ＡＰＩサーバ）に送信されると、当該ＡＰＩサーバからクライアントへとレスポンス情報（ＡＰＩレスポンス）が返信される。クライアントは、当該レスポンス情報に基づいて適宜の処理（受信情報の表示処理等）を実行する。たとえば、ページ記述言語（ＨＴＭＬ等）およびＡＰＩ（ＭＦＰのジョブ設定操作に関するＡＰＩ、および／またはジョブの実行操作に関するＡＰＩ等）を利用してＭＦＰの操作画面をクライアント（の表示部）に構築し、当該クライアントに表示された操作画面等を用いてＭＦＰを操作することが可能である。換言すれば、クライアントは、ＡＰＩを利用して、ＭＦＰ１０におけるジョブ操作等を実行することが可能である。

特開２０１３−０２１６３０号公報

しかしながら、ＡＰＩリクエストに対するレスポンス情報は、多岐に亘る種類の情報を含み、比較的大きなサイズを有することもある。そのようなレスポンス情報を常にサーバからクライアントへ送信する場合には、クライアントでの受信処理および受信データの解析処理等に比較的長時間を要するなどの問題が生じ得る。

そこで、この発明は、ＡＰＩのリクエストの送信元装置に対してレスポンス情報を効率的に送信することが可能な画像処理装置およびそれに関連する技術を提供することを課題とする。

上記課題を解決すべく、請求項１の発明は、画像処理装置であって、前記画像処理装置に関するＡＰＩのリクエストをクライアントから受け付ける受付手段と、前記リクエストの送信元装置である前記クライアントのクライアント種別を、各クライアントからのＡＰＩリクエストの履歴情報に基づいて判定する判定手段と、前記クライアントの前記クライアント種別に基づいて、前記ＡＰＩの前記リクエストに対するレスポンス情報を決定する決定手段と、前記決定されたレスポンス情報を前記クライアントに送信する送信手段と、を備え、前記決定手段は、前記クライアント種別が一の種別であると判定される場合、前記クライアント種別が他の種別であると判定される場合に比べて少ないデータ量の情報を、前記レスポンス情報として決定することを特徴とする。

請求項２の発明は、請求項１の発明に係る画像処理装置において、前記判定手段は、前記画像処理装置でのジョブ操作を実行する第１の種類のクライアントと、前記画像処理装置での前記ジョブ操作を実行せずデータ管理を実行する第２の種類のクライアントとのいずれかを、前記クライアント種別として判定することを特徴とする。

請求項３の発明は、請求項２の発明に係る画像処理装置において、前記判定手段は、前記ジョブ操作に関するＡＰＩの実行履歴が前記クライアントからの過去のＡＰＩリクエストとして前記履歴情報に存在するか否かに関する第１の基準に依拠して、前記送信元装置の前記クライアント種別が前記第１の種類のクライアントと前記第２の種類のクライアントとのいずれに該当するかを判定することを特徴とする。

請求項４の発明は、請求項２または請求項３の発明に係る画像処理装置において、前記決定手段は、前記送信元装置が前記第２の種類のクライアントであると判定される場合、前記ＡＰＩに対する前記レスポンス情報の候補群のうち、前記データ管理と前記ジョブ操作との双方で利用される基本情報のみを前記ＡＰＩに対する前記レスポンス情報として決定し、前記送信元装置が前記第１の種類のクライアントであると判定される場合、前記ＡＰＩに対する前記レスポンス情報の候補群のうち、前記基本情報のみならず、前記データ管理では利用されず前記ジョブ操作で利用される応用情報をも、前記ＡＰＩに対する前記レスポンス情報として決定することを特徴とする。

請求項５の発明は、請求項１の発明に係る画像処理装置において、前記判定手段は、ジョブに関するパラメータのうち基本レベルのパラメータ以外のパラメータである応用レベルのパラメータの設定変更をも実行する第３の種類のクライアントと、前記応用レベルのパラメータの設定変更を実行せず且つ前記基本レベルのパラメータの設定変更を実行する第４の種類のクライアントとのいずれかを、前記クライアント種別として判定し、前記基本レベルのパラメータは、所定の基本的な設定操作で利用されるパラメータであり、前記応用レベルのパラメータは、前記所定の基本的な設定操作以外の設定操作で利用されるパラメータであることを特徴とする。

請求項６の発明は、請求項５の発明に係る画像処理装置において、前記判定手段は、ジョブ設定操作に関するＡＰＩの実行履歴にて前記応用レベルのパラメータが過去に指定されていたか否かに関する第２の基準に依拠して、前記送信元装置の前記クライアント種別が前記第３の種類のクライアントと前記第４の種類のクライアントとのいずれに該当するかを判定することを特徴とする。

請求項７の発明は、請求項５または請求項６の発明に係る画像処理装置において、前記決定手段は、前記送信元装置が前記第４の種類のクライアントであると判定される場合、前記ＡＰＩに対する前記レスポンス情報の候補群のうち、前記基本レベルのパラメータ群のみを前記ＡＰＩに対する前記レスポンス情報として決定し、前記送信元装置が前記第３の種類のクライアントであると判定される場合、前記ＡＰＩに対する前記レスポンス情報の候補群のうち、前記基本レベルのパラメータ群のみならず前記応用レベルのパラメータ群をも、前記ＡＰＩに対する前記レスポンス情報として決定することを特徴とする。

請求項８の発明は、請求項１から請求項７のいずれかの発明に係る画像処理装置において、各クライアントからのＡＰＩリクエストの前記履歴情報を格納する格納手段、をさらに備えることを特徴とする。

請求項９の発明は、請求項１から請求項８のいずれかの発明に係る画像処理装置において、前記判定手段は、前記送信元装置の利用履歴が前記履歴情報に存在しない場合には、前記送信元装置から受信した前記送信元装置のＩＰアドレスに基づいて、前記送信元装置の前記クライアント種別を判定することを特徴とする。

請求項１０の発明は、請求項１の発明に係る画像処理装置において、前記判定手段は、前記送信元装置から受信した前記送信元装置のＩＰアドレスに基づいて、前記送信元装置の前記クライアント種別を判定することを特徴とする。

請求項１１の発明は、請求項９または請求項１０の発明に係る画像処理装置において、前記判定手段は、前記送信元装置から受信した前記送信元装置の前記ＩＰアドレスがグローバルＩＰアドレスであるかプライベートＩＰアドレスであるかに応じて、前記送信元装置の前記クライアント種別を判定することを特徴とする。

請求項１２の発明は、請求項１から請求項１１のいずれかの発明に係る画像処理装置において、決定された前記レスポンス情報が前記クライアントに送信された後、所定時間内に前記ＡＰＩと同じＡＰＩのリクエストである再リクエストが前記送信元装置から受け付けられる場合、前記送信手段は、前記ＡＰＩに対する前記レスポンス情報の候補群のうちの全てを、前記再リクエストに対するレスポンス情報として前記送信元装置に送信することを特徴とする。

請求項１３の発明は、画像処理システムであって、画像処理装置と、サーバと、を備え、前記画像処理装置は、前記画像処理装置に関するＡＰＩのリクエストをクライアントから受け付ける受付手段と、前記リクエストの送信元装置である前記クライアントのクライアント種別に基づいて、前記ＡＰＩの前記リクエストに対するレスポンス情報を決定する決定手段と、前記決定されたレスポンス情報を前記クライアントに送信する送信手段と、を備え、前記画像処理装置は、前記送信元装置の前記クライアント種別を前記サーバに問い合わせ、前記サーバは、前記リクエストの前記送信元装置である前記クライアントの前記クライアント種別を、各クライアントからのＡＰＩリクエストの履歴情報に基づいて判定し、前記画像処理装置は、前記サーバからの問合せ結果に基づいて前記クライアント種別を取得することを特徴とする。

請求項１４の発明は、画像処理装置の制御方法であって、ａ）前記画像処理装置に関するＡＰＩのリクエストをクライアントから受け付けるステップと、ｂ）前記リクエストの送信元装置である前記クライアントのクライアント種別を、各クライアントからのＡＰＩリクエストの履歴情報に基づいて判定するステップと、ｃ）前記クライアントの前記クライアント種別に基づいて、前記ＡＰＩの前記リクエストに対するレスポンス情報を決定するステップと、ｄ）前記決定されたレスポンス情報を前記クライアントに送信するステップと、を備え、前記クライアント種別が一の種別であると判定される場合、前記ステップｃ）においては、前記クライアント種別が他の種別であると判定される場合に比べて少ないデータ量の情報が前記レスポンス情報として決定されることを特徴とする。
請求項１５の発明は、請求項１４に記載の制御方法において、前記ステップｂ）は、ｂ−１）前記画像処理装置でのジョブ操作を実行する第１の種類のクライアントと、前記画像処理装置での前記ジョブ操作を実行せずデータ管理を実行する第２の種類のクライアントとのいずれかを、前記クライアント種別として判定するステップ、を備えることを特徴とする。
請求項１６の発明は、請求項１５に記載の制御方法において、前記ステップｂ−１）は、前記ジョブ操作に関するＡＰＩの実行履歴が前記クライアントからの過去のＡＰＩリクエストとして前記履歴情報に存在するか否かに関する第１の基準に依拠して、前記送信元装置の前記クライアント種別が前記第１の種類のクライアントと前記第２の種類のクライアントとのいずれに該当するかを判定するステップ、を備えることを特徴とする。
請求項１７の発明は、請求項１５または請求項１６に記載の制御方法において、前記ステップｃ）は、ｃ−１）前記送信元装置が前記第２の種類のクライアントであると判定される場合、前記ＡＰＩに対する前記レスポンス情報の候補群のうち、前記データ管理と前記ジョブ操作との双方で利用される基本情報のみを前記ＡＰＩに対する前記レスポンス情報として決定するステップと、ｃ−２）前記送信元装置が前記第１の種類のクライアントであると判定される場合、前記ＡＰＩに対する前記レスポンス情報の候補群のうち、前記基本情報のみならず、前記データ管理では利用されず前記ジョブ操作で利用される応用情報をも、前記ＡＰＩに対する前記レスポンス情報として決定するステップと、を備えることを特徴とする。
請求項１８の発明は、請求項１４に記載の制御方法において、ステップｂ）は、ｂ−１）ジョブに関するパラメータのうち基本レベルのパラメータ以外のパラメータである応用レベルのパラメータの設定変更をも実行する第３の種類のクライアントと、前記応用レベルのパラメータの設定変更を実行せず且つ前記基本レベルのパラメータの設定変更を実行する第４の種類のクライアントとのいずれかを、前記クライアント種別として判定するステップ、を備え、前記基本レベルのパラメータは、所定の基本的な設定操作で利用されるパラメータであり、前記応用レベルのパラメータは、前記所定の基本的な設定操作以外の設定操作で利用されるパラメータであることを特徴とする制御方法。
請求項１９の発明は、請求項１８に記載の制御方法において、ステップｂ−１）は、ジョブ設定操作に関するＡＰＩの実行履歴にて前記応用レベルのパラメータが過去に指定されていたか否かに関する第２の基準に依拠して、前記送信元装置の前記クライアント種別が前記第３の種類のクライアントと前記第４の種類のクライアントとのいずれに該当するかを判定するステップ、を有することを特徴とする制御方法。
請求項２０の発明は、請求項１８または請求項１９に記載の制御方法において、前記ステップｃ）は、ｃ−１）前記送信元装置が前記第４の種類のクライアントであると判定される場合、前記ＡＰＩに対する前記レスポンス情報の候補群のうち、前記基本レベルのパラメータ群のみを前記ＡＰＩに対する前記レスポンス情報として決定するステップと、ｃ−２）前記送信元装置が前記第３の種類のクライアントであると判定される場合、前記ＡＰＩに対する前記レスポンス情報の候補群のうち、前記基本レベルのパラメータ群のみならず前記応用レベルのパラメータ群をも、前記ＡＰＩに対する前記レスポンス情報として決定するステップと、を備えることを特徴とする制御方法。
請求項２１の発明は、請求項１４から請求項２０のいずれかに記載の制御方法において、前記ステップｂ）において、前記送信元装置の利用履歴が前記履歴情報に存在しない場合には、前記送信元装置から受信した前記送信元装置のＩＰアドレスに基づいて、前記送信元装置の前記クライアント種別が判定されることを特徴とする制御方法。
請求項２２の発明は、請求項２１に記載の制御方法において、前記ステップｂ）において、前記送信元装置から受信した前記送信元装置の前記ＩＰアドレスがグローバルＩＰアドレスであるかプライベートＩＰアドレスであるかに応じて、前記送信元装置の前記クライアント種別が判定されることを特徴とする制御方法。

請求項２３の発明は、請求項１４から請求項２２のいずれかに記載の制御方法において、ｅ）前記ステップｃ）にて決定された前記レスポンス情報が前記ステップｄ）にて前記クライアントに送信された後、所定時間内に前記ＡＰＩと同じＡＰＩのリクエストである再リクエストが前記送信元装置から受け付けられる場合、前記ＡＰＩに対する前記レスポンス情報の候補群のうちの全てを、前記再リクエストに対するレスポンス情報として前記送信元装置に送信するステップ、をさらに備えることを特徴とする。

請求項２４の発明は、請求項１４から請求項２３のいずれかに記載の制御方法を、前記画像処理装置に内蔵されたコンピュータに実行させるプログラムであることを特徴とする。

請求項１から請求項２４に記載の発明によれば、ＡＰＩのリクエストの送信元装置であるクライアントのクライアント種別に基づいて、ＡＰＩのリクエストに対するレスポンス情報が決定されるので、当該ＡＰＩのリクエストの送信元装置に対してレスポンス情報を効率的に送信することが可能である。

また、各クライアントからのＡＰＩリクエストの履歴情報に基づいて判定されたクライアント種別に応じて、ＡＰＩのリクエストに対するレスポンス情報が決定されるので、ＩＰアドレスに対して固定的に割り付けられたクライアント種別に基づいてレスポンス情報が決定される場合に比べて、レスポンス情報を柔軟に且つ適切に決定することが可能である。

第１実施形態に係る画像処理システムの構成を示す概略図である。 ＭＦＰの機能ブロックを示す図である。 複数のＡＰＩに関する情報が規定されたデータテーブルを示す図である。 ＭＦＰの動作を示すフローチャートである。 図４の一部動作（クライアント種別の判定動作）を詳細に示すフローチャートである。 図４の一部動作（レスポンス情報の決定動作）を詳細に示すフローチャートである。 ＡＰＩ利用履歴情報を示す図である。 「登録ユーザ情報取得ＡＰＩ」向けの「レスポンス情報決定用テーブル」を示す図である。 ＭＦＰ内に格納されている登録ユーザ情報を示す図である。 「ボックス文書情報取得ＡＰＩ」向けの「レスポンス情報決定用テーブル」を示す図である。 第２実施形態に係るＡＰＩデータテーブルを示す図である。 第２実施形態に係る動作の一部（クライアント種別の判定動作）を詳細に示すフローチャートである。 第２実施形態に係る動作の一部（レスポンス情報の決定動作）を詳細に示すフローチャートである。 コピージョブに関するパラメータ群を示す図である。 「ジョブ設定変更ＡＰＩ」向けの「レスポンス情報決定用テーブル」を示す図である。 別のＡＰＩ利用履歴情報を示す図である。 第３実施形態に係るＡＰＩデータテーブルを示す図である。 第３実施形態に係る動作の一部（クライアント種別の判定動作）を詳細に示すフローチャートである。 第３実施形態に係る動作の一部（レスポンス情報の決定動作）を詳細に示すフローチャートである。 各クライアントの装置識別情報とクライアント種別情報との対応関係を規定したデータテーブルを示す図である。

以下、本発明の実施形態を図面に基づいて説明する。

＜１．第１実施形態＞
＜１−１．システム構成＞
図１は、本発明の第１実施形態に係る画像処理システム１の構成を示す概略図である。図１に示されるように、画像処理システム１は、ＭＦＰ１０（画像処理装置）とクライアントコンピュータ７０とを備える。クライアントコンピュータ７０は、ＭＦＰ１０の外部装置であるとも表現される。

ＭＦＰ１０とクライアントコンピュータ（単にクライアントとも称する）７０とは、ネットワーク１０８を介して互いに接続される。ネットワーク１０８は、ＬＡＮ（Local Area Network）およびインターネットなどによって構成される。また、ネットワーク１０８に対する接続態様は、有線接続であってもよく、或いは無線接続であってもよい。

クライアント７０は、ＬＡＮの内部からＭＦＰ１０にアクセスしてもよく、ＬＡＮの外部からルータ等を介してＭＦＰ１０にアクセスしてもよい。

＜１−２．ＭＦＰ１０の構成＞
図２は、ＭＦＰ（マルチ・ファンクション・ペリフェラル（Multi-Functional Peripheral））１０の機能ブロックを示す図である。

ＭＦＰ１０は、スキャン機能、コピー機能、ファクシミリ機能およびボックス格納機能などを備える装置（複合機とも称する）である。具体的には、ＭＦＰ１０は、図２の機能ブロック図に示すように、画像読取部２、印刷出力部３、通信部４、格納部５、操作部６およびコントローラ９等を備えており、これらの各部を複合的に動作させることによって、各種の機能を実現する。なお、ＭＦＰ１０は、画像処理装置あるいは画像形成装置などとも表現される。

画像読取部２は、ＭＦＰ１０の所定の位置に載置された原稿を光学的に読み取って（すなわちスキャンして）、当該原稿の画像データ（原稿画像なしいスキャン画像とも称する）を生成する処理部である。この画像読取部２は、スキャン部であるとも称される。

印刷出力部３は、印刷対象に関するデータに基づいて紙などの各種の媒体に画像を印刷出力する出力部である。このＭＦＰ１０は、電子写真方式のプリンタ（フルカラープリンタ等）であるとも表現され、印刷出力部３は、露光部、現像部、転写部、定着部などの各種のハードウエア機構を有している。

通信部４は、公衆回線等を介したファクシミリ通信を行うことが可能な処理部である。さらに、通信部４は、ネットワーク１０８を介したネットワーク通信を行うことも可能である。このネットワーク通信では、たとえば、ＴＣＰ／ＩＰ（Transmission Control Protocol / Internet Protocol）等の各種のプロトコルが利用される。当該ネットワーク通信を利用することによって、ＭＦＰ１０は、所望の相手先（たとえば、クライアント７０）との間で各種のデータを授受することが可能である。通信部４は、各種データを送信する送信部４ａと各種データを受信する受信部４ｂとを有する。

格納部５は、ハードディスクドライブ（ＨＤＤ）等の記憶装置（不揮発性記憶装置）で構成される。格納部５には、後述する、ＡＰＩ情報２１０（図３）、ＡＰＩ利用履歴情報３１０（図７）、レスポンス情報決定用情報（テーブルＢ１１（図８），Ｂ１２（図１０），...）、登録ユーザ関連情報４１０（図９）等が格納される。

操作部６は、ＭＦＰ１０に対する操作入力を受け付ける操作入力部６ａと、各種情報の表示出力を行う表示部６ｂとを備えている。このＭＦＰ１０においては、略板状の操作パネル部６ｃ（図１参照）が設けられ、当該操作パネル部６ｃは、その正面側にタッチパネル２５（図１参照）を有している。タッチパネル２５は、液晶表示パネルに圧電センサ等が埋め込まれて構成され、各種情報を表示するとともに操作者からの操作入力を受け付けることが可能である。たとえば、タッチパネル２５においては、メニュー画面等の各種の画面（ボタン画像等を含む）等が表示される。操作者は、タッチパネル２５内に仮想的に配置されるボタン（ボタン画像で表現されるボタン）を押下することによって、ＭＦＰ１０の各種設定内容を変更することなどが可能である。タッチパネル２５は、操作入力部６ａの一部としても機能するとともに、表示部６ｂの一部としても機能する。

コントローラ（制御部）９は、ＭＦＰ１０に内蔵され、ＭＦＰ１０を統括的に制御する制御装置である。コントローラ９は、ＣＰＵおよび各種の半導体メモリ（ＲＡＭ（揮発性メモリ）およびＲＯＭ（不揮発性メモリ））等を備えるコンピュータシステムとして構成される。コントローラ９は、ＣＰＵにおいて、ＲＯＭ（例えば、ＥＥＰＲＯＭ（登録商標））内に格納されている所定のソフトウエアプログラム（以下、単にプログラムとも称する）を実行することによって、各種の処理部を実現する。なお、当該プログラム（詳細にはプログラムモジュール群）は、ＵＳＢメモリなどの可搬性の記録媒体に記録され、当該記録媒体から読み出されてＭＦＰ１０にインストールされるようにしてもよい。あるいは、当該プログラムは、ネットワーク等を経由してダウンロードされてＭＦＰ１０にインストールされるようにしてもよい。

具体的には、図２に示すように、コントローラ９は、当該プログラムの実行により、通信制御部１１と入力制御部１２と表示制御部１３と動作制御部１５とＡＰＩリクエスト受付部１６とクライアント種別判定部１７とレスポンス情報決定部１８とを含む各種の処理部を実現する。

通信制御部１１は、他の装置（クライアント７０等）との間の通信動作を制御する処理部である。たとえば、通信制御部１１は、通信部４等と協働して、クライアント７０からの印刷指令等を受信する。

表示制御部１３は、表示部６ｂにおける表示動作を制御する処理部である。たとえば、表示制御部１３は、ＭＦＰ１０を操作するための操作画面等を表示部６ｂに表示させる。

入力制御部１２は、操作入力部６ａに対する操作入力動作を制御する制御部である。たとえば、入力制御部１２は、操作画面に対する操作入力を受け付ける動作を制御する。

動作制御部１５は、ＭＦＰ１０における印刷出力動作およびスキャン動作等を制御する制御部である。

ＡＰＩリクエスト受付部１６は、ＭＦＰ１０に関するＡＰＩ（アプリケーションプログラミングインタフェース（Application Programming Interface））のリクエストをクライアント７０等から受け付ける処理部である。ＡＰＩリクエスト受付部１６は、当該リクエスト（ＡＰＩリクエスト）の内容を解析する解析処理をも実行する。

クライアント種別判定部１７は、ＡＰＩリクエストの送信元装置であるクライアント（クライアント装置）のクライアント種別（後述）を判定する処理部である。

レスポンス情報決定部１８は、ＡＰＩリクエストに対するレスポンス情報（後述）を、当該ＡＰＩリクエストの送信元装置のクライアント種別に基づいて決定する処理部である。より詳細には、レスポンス情報決定部１８は、ＡＰＩリクエストに対するレスポンス情報の候補群の中から、当該ＡＰＩリクエストの送信元装置のクライアント種別に応じた情報を、当該送信元装置に実際に返信すべきレスポンス情報として決定（特定）する。このようにしてレスポンス情報が決定されると、当該レスポンス情報は、レスポンス情報決定部１８、通信制御部１１および通信部４等によって、送信元装置のクライアントへと送信される。

ＡＰＩリクエスト受付部１６、クライアント種別判定部１７、およびレスポンス情報決定部１８は、ＡＰＩサーバ部２０（クライアントからのＡＰＩリクエストに対するサーバ側の処理を実行するサーバ処理部）として機能する。

このように、主にコントローラ９のＣＰＵにてソフトウエアプログラムを実行することによって、上述の各種の動作が実行される。ただし、これに限定されず、ＭＦＰ１０（詳細には、コントローラ９の内部あるいは外部）にて設けられた専用ハードウエア等を用いて、上述の各種の動作が実行されるようにしてもよい。たとえば、通信制御部１１、入力制御部１２、表示制御部１３、動作制御部１５、ＡＰＩリクエスト受付部１６、クライアント種別判定部１７、レスポンス情報決定部１８等の各種の処理部のうちの全部または一部が、１または複数の専用ハードウエアを用いて実現されてもよい。

＜１−３．クライアントコンピュータ７０の構成＞
クライアントコンピュータ７０は、コントローラ（ＣＰＵおよび半導体メモリ等を含む）、格納部（ＨＤＤ、ＳＳＤ等）、通信部、操作部などの物理的構成を備えるパーソナルコンピュータなどの情報処理装置により構成される。ただし、クライアント７０は、パーソナルコンピュータに限定されず、スマートフォンあるいはタブレット端末などであってもよい。

クライアント７０のコントローラは、そのＣＰＵにおいて、所定のプログラム（プリンタドライバ等）を実行することによって、各種の処理部を実現する。

各クライアントコンピュータ（以下、単にクライアントとも称する）７０には、１又は複数のアプリケーションプログラム（以下、単にアプリケーションとも称する）がインストールされている。

各アプリケーションは、対応するサービスの起動指示を各ユーザから受け付ける処理等を実行する。その後、クライアント７０は、ＭＦＰ１０に対してＡＰＩ（ＭＦＰ１０に関するＡＰＩ）のリクエスト（ＡＰＩリクエスト）を送信し、当該ＡＰＩリクエストに対するレスポンス情報をＭＦＰ１０（ＡＰＩサーバ部２０等）から受信する。そして、当該レスポンス情報に含まれる各種の情報を利用して、各種のサービスを実行する。

クライアント７０におけるアプリケーションとしては、たとえば、ＭＦＰ１０でのジョブ操作に関するアプリケーション（「ジョブ操作アプリケーション」）が例示される。当該「ジョブ操作アプリケーション」では、ジョブの設定変更処理および当該ジョブの実行処理等が実行される。より詳細には、ＭＦＰ１０の操作用画像（たとえば、ＭＦＰ１０の操作パネル部６ｃに表示されるパネル画像の模擬画像あるいは当該パネル画像に依拠しない独自画像等）をクライアントコンピュータ７０の表示部７５（図１参照）に表示してユーザからの指示入力（ジョブの開始指示等）を受け付け、当該指示入力に基づきＭＦＰ１０でのジョブの開始指令（実行指令）等がＭＦＰ１０に対して付与される。また、ユーザのジョブ実行に際して、当該アプリケーションは、ジョブに関する各種の設定値をＭＦＰ１０から取得し、当該各種の設定値の一部又は全部を必要に応じてクライアント７０上の操作用画像に表示するとともに、当該設定値に関するユーザによる設定変更を受け付け当該設定変更の内容をＭＦＰ１０に送信する。さらに、ＭＦＰ１０は、設定変更された設定項目を含む複数の設定項目に関する設定値（設定内容）をクライアント７０へと送信し、クライアントコンピュータ７０は、当該複数の設定項目のうちの一部または全部の設定項目に関する情報（設定内容等）を表示する。

また、クライアント７０におけるアプリケーションとしては、ＭＦＰ１０に関するデータの管理等を実行するアプリケーション（「データ管理アプリケーション」）等も例示される。当該「データ管理アプリケーション」では、ＭＦＰ１０に関する各種の情報（データ）の収集処理および管理処理等が実行される。

これらのアプリケーションにおいては、後述するような各種のＡＰＩ（ＭＦＰ用のＡＰＩ）が利用される。なお、各アプリケーションは、それぞれ、１又は複数のＡＰＩを利用して実行される。

たとえば、「ジョブ操作アプリケーション」においては、ジョブの設定値の取得処理および／または変更処理を実行するＡＰＩ（「ジョブ設定変更ＡＰＩ」）、ならびにジョブの実行指令等を付与するＡＰＩ（「ジョブ実行ＡＰＩ」）等が利用される。なお、「ジョブ実行ＡＰＩ」は、ジョブ実行指令のみならず、ジョブの実行中止指令および／または実行再開指令等を行い得るＡＰＩであってもよい。

「ジョブ設定変更ＡＰＩ」を利用することによって、クライアント７０は、ジョブにおける設定変更指令をＭＦＰ１０に対して付与するとともに、当該設定変更指令に応じて変更された１又は複数の設定値をＭＦＰ１０から受信することができる。

たとえば、クライアント７０は、「ジョブ設定変更ＡＰＩ」におけるパラメータ（「刷用紙：Ａ３」）を指定することによって、印刷用紙サイズを「Ａ４」から「Ａ３」に変更すべき旨の設定変更指令をＭＦＰ１０へと付与することができる。また、ＭＦＰ１０は、複数の設定項目（指定パラメータ以外の他の設定項目（たとえば、「変倍率」）をも含む）の設定値を含むレスポンス情報をクライアント７０に返信する。より詳細には、他の設定項目「変倍率」の設定値が「自動」に設定されている場合、「印刷用紙サイズ」の設定変更（「Ａ４」→「Ａ３」）に伴って、「変倍率」の実際の設定値が「１００％」から「１４４％」に変更される。このとき、クライアント７０は、変更後の印刷用紙サイズ（「Ａ３」）と用紙サイズ変更後の拡大率の（実際の）値（「１４４％」）とを含むレスポンス情報をＭＦＰ１０から受信することによって、複数の設定項目の設定変更後の設定値を知得することが可能である。なお、設定変更の指示入力、および設定変更後の設定値の表示は、クライアント７０の表示部内の操作用画像（ＭＦＰ１０の操作用画像）を用いて行われる。

また、「ジョブ実行ＡＰＩ」を利用することによって、クライアント７０は、ジョブの実行指令等をＭＦＰ１０に対して付与することができる。

さらに、「データ管理アプリケーション」においては、ジョブの実行履歴情報を取得するＡＰＩ（「ジョブ実行履歴取得ＡＰＩ」）、登録ユーザに関する情報を取得するＡＰＩ（「登録ユーザ情報取得ＡＰＩ」）、ボックス文書に関する情報を取得するＡＰＩ（「ボックス文書情報取得ＡＰＩ」）等が利用される。なお、「ボックス」は、ＭＦＰ１０の格納部５に設けられるフォルダ（記憶領域）である。

たとえば、「登録ユーザ情報取得ＡＰＩ」を利用することによって、クライアント７０は、ＭＦＰ１０の全ユーザ（あるいは指定ユーザ）のユーザ情報をＭＦＰ１０から取得することができる。

ここにおいて、各クライアント７０は、必ずしも「ジョブ操作アプリケーション」と「データ管理アプリケーション」との両種類のアプリケーションの双方をインストールしているとは限らない。換言すれば、各クライアント７０が、必ずしも当該両種類のアプリケーションの双方を利用するとは限らない。

たとえば、或るクライアント７０（たとえば７０ｂ）においては、「ジョブ操作アプリケーションがインストールされておらず、「データ管理アプリケーション」（のみ）がインストールされている。このようなクライアントは、「ジョブ操作」（ＭＦＰ１０でのジョブ操作）を実行しない種類のクライアント、換言すれば、「データ管理」を専ら行うクライアントであり、「データ管理クライアント」であるとも表現される。

一方、別の或るクライアント７０（たとえば７０ａ）においては、「ジョブ操作アプリケーション」のみ（あるいは「データ管理クライアント」と「ジョブ操作アプリケーション」との双方）がインストールされていることがある。このようなクライアントは、「ジョブ操作」（ＭＦＰ１０でのジョブ操作）を実行する種類のクライアントであり、「ジョブ操作クライアント」であるとも表現される。

この実施形態においては、後述するように、ＡＰＩの送信元装置（クライアント）のクライアント種別（「ジョブ操作クライアント」／「データ管理クライアント」）が、ジョブの実行履歴情報（ＡＰＩ利用履歴情報３１０（図７参照））に基づいて判される。

＜１−４．ＡＰＩの種類＞
図３は、複数のＡＰＩに関する情報が規定されたデータテーブル２１０（２１１）を示す図である。当該データテーブル（ＡＰＩデータテーブルあるいはＡＰＩ情報とも称する）２１０は、ＭＦＰ１０内に予め保存されている。図３のデータテーブル２１０においては、本システムにて利用され得る複数のＡＰＩ等が示されている。

図３では、「ジョブ設定変更ＡＰＩ」、「ジョブ実行ＡＰＩ」、「ジョブ実行履歴取得ＡＰＩ」、「登録ユーザ情報取得ＡＰＩ」、「ボックス文書情報取得ＡＰＩ」等が例示されている（データテーブル２１０の「ＡＰＩ名称」欄参照）。

このうち、「ジョブ設定変更ＡＰＩ」および「ジョブ実行ＡＰＩ」は、ＭＦＰ１０でのジョブ操作に関するアプリケーション（「ジョブ操作アプリケーション」）において利用されるＡＰＩであることから、「ジョブ操作用ＡＰＩ」（ジョブ系ＡＰＩとも称される）に分類される
一方、「ジョブ実行履歴取得ＡＰＩ」、「登録ユーザ情報取得ＡＰＩ」、および「ボックス文書情報取得ＡＰＩ」は、ＭＦＰ１０に関するデータの管理等を実行するアプリケーション（「データ管理アプリケーション」）において利用されるＡＰＩであることから、「データ管理用ＡＰＩ」（データ系ＡＰＩとも称される）に分類される。

図３のデータテーブル２１０においては、「ＡＰＩ分類」の欄において、各ＡＰＩが「ジョブ操作用ＡＰＩ」に分類されるか或いは「データ管理用ＡＰＩ」に分類されるかが記述されている。

また、この実施形態では、図３に示されるように、複数のＡＰＩのそれぞれについて「レスポンス情報変更処理（決定処理）の要否」が予め規定されており、この規定内容に基づいてレスポンス情報変更処理の要否がＡＰＩごとに決定される。また、レスポンス情報変更処理を要する旨（「レスポンス情報変更処理の要否」＝「要」）が予め規定されているＡＰＩに関しては、「レスポンス情報決定用テーブル」として利用すべきテーブル（「対応テーブル」）の情報が規定されている。

たとえば、図３においては、「ジョブ実行履歴取得ＡＰＩ」、「登録ユーザ情報取得ＡＰＩ」、および「ボックス文書情報取得ＡＰＩ」に関しては、レスポンス情報変更処理を要しない旨（「不要」）が規定されている。一方、「登録ユーザ情報取得ＡＰＩ」および「ボックス文書情報取得ＡＰＩ」に関しては、レスポンス情報変更処理を要する旨が規定されている。さらに、「登録ユーザ情報取得ＡＰＩ」に関してはテーブルＢ１１（図８参照）を「レスポンス情報決定用テーブル」として利用すべき旨が規定されており、「ボックス文書情報取得ＡＰＩ」に関してはテーブルＢ１２（図１０参照）を「レスポンス情報決定用テーブル」として利用すべき旨が規定されている。

なお、この実施形態においては、複数のＡＰＩのうち、レスポンス情報変更処理を要する旨（「レスポンス情報変更処理（決定処理）の要否」＝「要」）が予め規定されているＡＰＩに関してのみ、レスポンス情報の決定処理（ステップＳ１４（図４参照））等が実行される。

また、ここでは、各ＡＰＩが、複数のジョブ種類に共通するＡＰＩである態様を主に例示する。たとえば、「ジョブ設定変更ＡＰＩ」は、複数のジョブ種類（コピージョブ、スキャンジョブ、ファクシミリジョブ（ファクシミリ送信ジョブ）、プリントジョブ（ボックスプリントジョブ）等）に共通のジョブ設定変更ＡＰＩである。ただし、これに限定されず、各ＡＰＩは、ジョブ種類ごとに設けられたＡＰＩ（複数のジョブ種類のそれぞれに固有のＡＰＩ）であってもよい。たとえば、「ジョブ設定変更ＡＰＩ」は、対応ジョブ専用の複数のＡＰＩ（「コピージョブ設定変更ＡＰＩ」、「スキャンジョブ設定変更ＡＰＩ」、「ファクシミリ送信ジョブ設定変更ＡＰＩ」、「ボックスプリントジョブ設定変更ＡＰＩ」等）に分けて設けられても良い。

＜１−５．動作＞
図４は、ＭＦＰ１０の動作を示すフローチャートである。図５は、図４の動作のうちの一部（ステップＳ１２）の動作を詳細に示すフローチャートであり、図６は、図４の動作のうちの他の一部（ステップＳ１４）の動作を詳細に示すフローチャートである。また、図７は、ＡＰＩの利用履歴に関する情報（ＡＰＩ利用履歴情報）３１０（３１１）を示す図である。

図７の利用履歴情報３１０においては、図４〜図６の動作が開始されるまでに利用されたＡＰＩの利用履歴が示されている。より詳細には、複数のクライアントのそれぞれによって利用された各ＡＰＩの利用履歴が示されている。利用履歴情報３１０においては、ＡＰＩリクエストの受信日時、ＡＰＩリクエストの送信元装置の識別情報（ここではＩＰアドレス）、ＡＰＩ名称（「登録ユーザ情報取得ＡＰＩ」、「ジョブ設定変更ＡＰＩ」等）、ＡＰＩにおける被指定パラメータ（「印刷用紙：Ａ４」、「部数：１０」、「集約：２ｉｎ１」，....）等が、利用された複数のＡＰＩのそれぞれについて記録されている。当該利用履歴情報３１０は、ＭＦＰ１０内に格納される。

以下、図４〜図６を参照しつつ、ＭＦＰ１０の動作を中心に本システムの動作について説明する。なお、図４の動作は、ＡＰＩリクエストが受け付けられるごとに実行される。

図４のステップＳ１１において、ＭＦＰ１０は、当該ＭＦＰ１０に関するＡＰＩのリクエスト（ＡＰＩリクエスト）をクライアント７０（たとえば、７０ａ）から受信し（受け付け）、当該ＡＰＩリクエストの内容を解析する。

＜ステップＳ１２：クライアント種別判定＞
次のステップＳ１２において、ＭＦＰ１０は、当該ＡＰＩリクエストの送信元装置であるクライアント７０（７０ａ）のクライアント種別を判定する。

この実施形態では、ＡＰＩの利用履歴情報３１０（３１１）（図７参照）に基づいて、ＡＰＩリクエストの送信元装置のクライアント種別が判定される。

図５は、ステップＳ１２の詳細動作を示すフローチャートである。以下、図５等をも参照しつつ、ステップＳ１２の動作について詳細に説明する。

ステップＳ２０（図５）において、ＭＦＰ１０は、受信したＡＰＩの送信元装置（クライアント７０）のクライアント種別を判定すべきか否かを決定する。具体的には、ＭＦＰ１０は、ＡＰＩデータテーブル２１０（２１１）（図３）の「レスポンス情報変更処理の要否」の欄を参照し、「受信したＡＰＩがレスポンス情報の変更処理（決定処理）を要するＡＰＩであるか否か」、を判定する。

当該ＡＰＩがレスポンス情報の変更処理を要しないＡＰＩである場合には、当該ＡＰＩの送信元装置（クライアント７０）のクライアント種別を判定しなくてよい旨が決定される。そして、ステップＳ１２の処理を終了する。

一方、当該ＡＰＩがレスポンス情報の変更処理を要するＡＰＩである場合には、当該ＡＰＩの送信元装置（クライアント７０）のクライアント種別を判定すべき旨が決定される。そして、ステップＳ２２に進む。

たとえば、受信したＡＰＩが、「ジョブ設定変更ＡＰＩ」、「ジョブ実行ＡＰＩ」、および「ジョブ実行履歴取得ＡＰＩ」等のいずれかである場合には、「レスポンス情報変更」が「不要」（図３参照）であり、当該ＡＰＩの送信元装置のクライアント種別を判定しなくてよい旨が決定される。この場合、図５の処理を終了する。

一方、受信したＡＰＩが、「登録ユーザ情報取得ＡＰＩ」および「ボックス文書情報取得ＡＰＩ」等のいずれかである場合には、「レスポンス情報変更」が「要」（図３参照）であり、当該ＡＰＩの送信元装置のクライアント種別を判定すべき旨が決定される。そして、ステップＳ２２に進む。

ステップＳ２２〜Ｓ２４においては、送信元装置のクライアント種別が、「ジョブ操作クライアント」と「データ管理クライアント」とのいずれであるかが判定される。

ステップＳ２２においては、当該送信元装置による「ジョブ操作用ＡＰＩ」の利用履歴（一のＡＰＩ分類「ジョブ操作用ＡＰＩ」に分類されるＡＰＩの利用履歴）がＡＰＩ利用履歴情報３１０に含まれているか否かが判定される。換言すれば、「ジョブ操作に関するＡＰＩ」の実行履歴が当該送信元装置からの過去のＡＰＩリクエストとして履歴情報（ＡＰＩ利用履歴情報３１０）に存在するか否かが判定される。そして、その判定結果に基づいて、当該送信元装置が「ジョブ操作クライアント」であるか「データ管理クライアント」であるかが判定される。このように、当該クライアント種別の判定処理は、当該送信元装置による「ジョブ操作用ＡＰＩ」の利用履歴がＡＰＩ利用履歴情報３１０に含まれているか否かに関する基準Ｄ１に依拠して、実行される。

詳細には、当該送信元装置による「ジョブ操作用ＡＰＩ」の利用履歴がＡＰＩ利用履歴情報３１０に含まれている場合には、当該送信元装置は「ジョブ操作クライアント」であると判定される（ステップＳ２３）。一方、当該送信元装置による「ジョブ操作用ＡＰＩ」の利用履歴がＡＰＩ利用履歴情報３１０に含まれていない場合には、当該送信元装置は「データ管理クライアント」であると判定される（ステップＳ２４）。

たとえば、送信元装置のＩＰアドレスが「192.168.56.XXX」である場合、図７のＡＰＩ利用履歴情報３１０においては、当該ＩＰアドレスのクライアントにより「ジョブ設定変更ＡＰＩ」が利用され、且つ、当該ＩＰアドレスのクライアントにより「ジョブ実行ＡＰＩ」が利用された旨の履歴が含まれている。ここにおいて、上述のように「ジョブ設定変更ＡＰＩ」および「ジョブ実行ＡＰＩ」は、「ジョブ操作用ＡＰＩ」に分類される（図３参照）。したがって、当該送信元装置による「ジョブ操作用ＡＰＩ」の利用履歴がＡＰＩ利用履歴情報３１０に含まれている旨が判定される。そして、当該送信元装置は「ジョブ操作クライアント」であると判定される（ステップＳ２３）。

一方、送信元装置のＩＰアドレスが「10.0.22.YYY」である場合、当該ＩＰアドレスのクライアントによる「データ管理用ＡＰＩ」（具体的には、「登録ユーザ情報取得ＡＰＩ」および「ボックス文書情報取得ＡＰＩ」）の利用履歴はＡＰＩ利用履歴情報３１０内に存在するものの、「ジョブ操作用ＡＰＩ」の利用履歴はＡＰＩ利用履歴情報３１０内に存在しない。この場合、当該送信元装置による「ジョブ操作用ＡＰＩ」の利用履歴がＡＰＩ利用履歴情報３１０に含まれていない旨が判定される。そして、当該送信元装置は「データ管理クライアント」であると判定される（ステップＳ２４）。

このように、第１実施形態における「（送信元装置の）クライアント種別の判定処理」は、当該送信元装置によって利用された履歴を有するＡＰＩ（図７のＡＰＩ利用履歴情報３１０内の「ＡＰＩ名称」欄等参照）の「ＡＰＩ分類」情報（図３参照）（「ジョブ操作用ＡＰＩ」／「データ管理用ＡＰＩ」）に基づいて実行される。

＜ステップＳ１４：レスポンス情報決定＞
次に、ステップＳ１４（図４）において、ステップＳ１１で受信されたＡＰＩリクエストに対する「レスポンス情報」（当該ＡＰＩリクエストに応答して返信されるべき情報）が、ステップＳ１２で判定されたクライアント種別に基づいて、決定される。

図６は、ステップＳ１４の詳細動作を示すフローチャートである。以下、図６等をも参照しつつ、ステップＳ１４の動作について詳細に説明する。

ステップＳ４０（図６）において、ＭＦＰ１０は、受信したＡＰＩのレスポンス情報をクライアント種別に応じて変更すべきか否かを決定する。具体的には、ＭＦＰ１０は、ＡＰＩデータテーブル２１０（２１１）（図３）の「レスポンス情報変更処理の要否」の欄を参照し、「受信したＡＰＩが、レスポンス情報の変更処理を要するＡＰＩであるか否か」、を判定する。

当該ＡＰＩがレスポンス情報の変更処理を要しないＡＰＩである場合には、当該ＡＰＩのレスポンス情報をクライアント種別に応じて変更しなくてよい旨が決定される。そして、ステップＳ１４の処理を終了する。

一方、当該ＡＰＩがレスポンス情報の変更処理（決定処理）を要するＡＰＩである場合には、当該ＡＰＩのレスポンス情報をクライアント種別に応じて変更（決定）すべき旨が決定される。そして、ステップＳ４２に進む。

たとえば、受信したＡＰＩが、「ジョブ設定変更ＡＰＩ」、「ジョブ実行ＡＰＩ」、および「ジョブ実行履歴取得ＡＰＩ」等のいずれかである場合には、「レスポンス情報変更処理の要否」が「不要」（図３参照）であり、当該ＡＰＩのレスポンス情報をクライアント種別に応じて変更しなくてよい旨が決定される。一方、受信したＡＰＩが、「登録ユーザ情報取得ＡＰＩ」および「ボックス文書情報取得ＡＰＩ」等のいずれかである場合には、「レスポンス情報変更処理の要否」が「要」（図３参照）であり、当該ＡＰＩのレスポンス情報をクライアント種別に応じて変更すべき旨が決定される。

また、ステップＳ４２においては、ＡＰＩの送信元装置が「ジョブ操作クライアント」であるか「データ管理クライアント」であるかが判定される。そして、その判定結果に応じて、当該ＡＰＩのレスポンス情報が決定される。

具体的には、ＡＰＩの送信元装置が「ジョブ操作クライアント」である場合には、「ジョブ操作クライアント」用の情報がレスポンス情報として決定される（ステップＳ４３）。一方、ＡＰＩの送信元装置が「データ管理クライアント」である場合には、「データ管理クライアント」用の情報がレスポンス情報として決定される（ステップＳ４４）。ここにおいて、「ジョブ操作クライアント」用の情報、および「データ管理クライアント」用の情報は、各ＡＰＩごとに予め規定されている。

＜「登録ユーザ情報取得ＡＰＩ」に関するレスポンス情報＞
以下、たとえば、「登録ユーザ情報取得ＡＰＩ」がステップＳ１１にて受信されていた場合を想定する。

まず、図３のデータテーブル２１０（２１１）が参照される。

この場合、データテーブル２１１においては、「登録ユーザ情報取得ＡＰＩ」に関するレスポンス情報決定用テーブルとしてデータテーブルＢ１１（図８も参照）を参照すべき旨が規定されている。ＭＦＰ１０は、この規定内容に従ってデータテーブルＢ１１を参照する。

データテーブルＢ１１には、「登録ユーザ情報取得ＡＰＩ」に関する、「ジョブ操作クライアント」用の情報（詳細には、情報項目）および「データ管理クライアント」用の情報（情報項目）が規定されている。なお、データテーブルＢ１１は、ＭＦＰ１０内に予め格納されている。

ここにおいて、「登録ユーザ情報取得ＡＰＩ」は、上述のように登録ユーザに関する情報等を取得するＡＰＩである。「登録ユーザ情報取得ＡＰＩ」によれば、登録ユーザに関する複数の情報項目（「ユーザＮｏ．」、「ユーザ名」、「所属」、「連絡先」、「出力制限」、「機能制限」、「印刷カウント」等）（図８参照）の情報が取得され得る。これらの複数の情報項目の情報（内容）は、レスポンス情報の候補群である、とも表現される。

ここで、「ユーザＮｏ．」は、そのユーザの番号を示す情報項目であり、「ユーザ名」は、そのユーザの名称を示す情報項目である。また、「所属」は、そのユーザの所属（グループＧＲ１，ＧＲ２等）を示す情報項目である。さらに、「連絡先」は、そのユーザの連絡先（メールアドレス）を示す情報項目である。

また、「出力制限」は、そのユーザによる出力色（フルカラー出力）に関する制限（ユーザ制限）を示す情報項目である。項目「出力制限」に関しては、「制限無し（モノクロ出力およびフルカラー出力の双方が可能）」と「制限有り（モノクロ出力のみ可能）（フルカラー出力は不可能）」とのいずれかを示す情報が規定されている（図９も参照）。或るユーザに対する出力制限が設定されている場合、当該ユーザは、フルカラー印刷出力をＭＦＰ１０に実行させることができない。

また、「機能制限」は、そのユーザによる使用可能機能に関する制限を示す情報項目である。項目「出力制限」に関しては、「制限無し」、「制限有り（スキャン送信不可）」のいずれかに関する情報が規定されている。或るユーザに対する「機能制限」が設定されている場合、当該ユーザは、スキャン送信機能を利用するこができない。

また、「印刷カウント」は、そのユーザによる印刷出力枚数（現時点での印刷出力済みの枚数）を示す情報項目である。項目「印刷カウント」には、そのユーザによる所定期間における印刷枚数（「１２３枚」あるいは「２３」枚等）に関する情報が規定されている。或るユーザに対する「印刷カウント」が上限値（規定値）に到達した場合、当該ユーザは、それ以後、ＭＦＰ１０に印刷出力処理を実行させることができない。

図９は、これらの情報がユーザごとに格納されているデータテーブル（登録ユーザ関連情報）４１０を示す図である。図９のデータテーブル４１０においては、複数の登録ユーザＵ１〜Ｕ５等のそれぞれに関して、上記の複数の設定項目に関する各情報が規定されている。

再び図８を参照する。「データ管理クライアント」は、これらの複数の項目の情報のうち、基本的な情報（たとえば、「ユーザＮｏ．」、「ユーザ名」、「所属」、「連絡先」の情報）を利用することが多い。一方、「ジョブ操作クライアント」は、当該複数の項目の情報のうち、当該基本的な情報（基本情報とも称する）のみならず、さらに別の情報（具体的には、ジョ操作で利用される情報）（たとえば、「出力制限」、「機能制限」、「印刷カウント」等の情報）（応用情報あるいは非基本情報とも称する）をも利用することが多い。

そこで、この実施形態では、ＡＰＩ（「登録ユーザ情報取得ＡＰＩ」）の送信元装置が「データ管理クライアント」であると判定される場合、当該ＡＰＩに対するレスポンス情報の候補群のうち、データ管理とジョブ操作との双方で利用される「基本情報」のみが、当該ＡＰＩに対するレスポンス情報として決定される（ステップＳ４４）。より具体的には、データテーブルＢ１１（レスポンス情報決定用テーブル）を参照し、「基本情報」に関する情報項目（「ユーザＮｏ．」、「ユーザ名」、「所属」、「連絡先」）のみがレスポンス情報の情報項目として決定されるとともに、当該情報項目に対応する情報内容（実体データ）がレスポンス情報の内容として取得（決定）される。

一方、ＡＰＩ（「登録ユーザ情報取得ＡＰＩ」）の送信元装置が「ジョブ操作クライアント」であると判定される場合、当該ＡＰＩに対するレスポンス情報の候補群のうち、「基本情報」のみならず、データ管理では利用されずジョブ操作で利用される「応用情報」もが、当該ＡＰＩに対するレスポンス情報として決定される（ステップＳ４３）。より具体的には、「基本情報」に関する情報項目と「応用情報」に関する情報項目（「出力制限」、「機能制限」、「印刷カウント」等）との双方（レスポンス情報の候補群に関する全項目）がレスポンス情報の情報項目であると決定されるとともに、当該情報項目に対応する情報内容がレスポンス情報の内容として取得（決定）される。

＜「ボックス文書情報取得ＡＰＩ」に関するレスポンス情報＞
つぎに、「ボックス文書情報取得ＡＰＩ」がステップＳ１１にて受信されていた場合を想定する。この場合、図３のデータテーブル２１０（２１１）に基づき、データテーブルＢ１２を参照すべき旨が決定される。

データテーブルＢ１２（図１０参照）には、「ボックス文書情報取得ＡＰＩ」に関する、「ジョブ操作クライアント」用の情報（詳細には、情報項目）および「データ管理クライアント」用の情報（情報項目）が規定されている。なお、データテーブルＢ１２は、ＭＦＰ１０内に予め格納されている。

ここにおいて、「ボックス文書情報取得ＡＰＩ」は、上述のようにボックス文書に関する情報等を取得するＡＰＩである。「ボックス文書情報取得ＡＰＩ」によれば、ボックス内の文書に関する複数の情報項目（「文書名」、「（文書の作成ユーザの）ユーザＮｏ．」、「（文書の作成ユーザの）ユーザ名」、「（文書の）保存日時」、「（文書の）プレビュー画像」、「文書データ（自体）」等）（図１０参照）の情報が取得され得る。これらの複数の情報項目の情報（内容）は、レスポンス情報の候補群である、とも表現される。

「データ管理クライアント」は、これらの複数の項目の情報のうち、基本的な情報（たとえば、「文書名」、「（文書の作成ユーザの）ユーザＮｏ．」、「（文書の作成ユーザの）ユーザ名」、「（文書の）保存日時」、「（文書の）プレビュー画像」の情報）を利用することが多い。一方、「ジョブ操作クライアント」は、当該複数の項目の情報のうち、当該基本的な情報（基本情報とも称する）のみならず、さらに別の情報（具体的には、ジョ操作で利用される情報）（たとえば、「文書データ（自体）」等の情報）（応用情報あるいは非基本情報とも称する）をも利用することが多い。

そこで、この実施形態では、ＡＰＩ（「ボックス文書情報取得ＡＰＩ」）の送信元装置が「データ管理クライアント」であると判定される場合、当該ＡＰＩに対するレスポンス情報の候補群のうち、データ管理とジョブ操作との双方で利用される「基本情報」のみが、当該ＡＰＩに対するレスポンス情報として決定される（ステップＳ４４）。より具体的には、ステップＳ１４において、データテーブルＢ１２（図１０）を参照し、「基本情報」に関する情報項目（「文書名」、「ユーザＮｏ．」、「ユーザ名」、「保存日時」、「プレビュー画像」）のみがレスポンス情報の情報項目であると決定されるとともに、当該情報項目に対応する情報内容がレスポンス情報の内容として取得（決定）される。

一方、ＡＰＩ（「ボックス文書情報取得ＡＰＩ」）の送信元装置が「ジョブ操作クライアント」であると判定される場合、当該ＡＰＩに対するレスポンス情報の候補群のうち、「基本情報」のみならず、データ管理では利用されずジョブ操作で利用される「応用情報」をも、当該ＡＰＩに対するレスポンス情報として決定される（ステップＳ４３）。より具体的には、「基本情報」に関する情報項目と「応用情報」に関する情報項目（「文書データ（自体）」等）との双方（レスポンス情報の候補群に関する全項目）がレスポンス情報の情報項目であると決定されるとともに、当該情報項目に対応する情報内容がレスポンス情報の内容として取得（決定）される。

以上のようにして、ステップＳ１４の処理が実行される。

＜ステップＳ１６以後等＞
次のステップＳ１６（図４）においては、ステップＳ１４で決定されたレスポンス情報がＭＦＰ１０からクライアント７０へと送信される。このようにして、クライアント７０からＭＦＰ１０へのＡＰＩリクエスト（ＨＴＴＰリクエスト等）に対するレスポンス（ＨＴＴＰレスポンス等）が、ＭＦＰ１０からクライアント７０へと送信される。なお、当該ＨＴＴＰレスポンスは、ＸＭＬ形式あるいはＪＳＯＮ (JavaScript（登録商標） Object Notation)形式のデータ等で構成されればよい。

また、ステップＳ１７において、ＡＰＩ利用履歴情報３１０が更新される。

その後、レスポンス情報を受信したクライアント７０は、当該レスポンス情報を利用して、各種の処理（表示処理等）を実行する。

たとえば、ジョブ操作クライアントであるクライアント７０が、「登録ユーザ情報取得ＡＰＩ」に関するレスポンス情報を受信し、特定ユーザに関する出力制限に関する情報（「制限有り」（フルカラー禁止））を取得する場合、当該クライアント７０にて表示される操作画面（ＭＦＰ１０を操作するための特定ユーザ向けの操作画面）内の「フルカラー」を設定するためのボタンを無効化するなどの処理を実行することが可能である。

以上のような動作によれば、ＭＦＰ１０は、当該ＭＦＰ１０に関するＡＰＩリクエストをクライアント（送信元装置）７０から受け付け、当該ＡＰＩリクエストの送信元装置７０のクライアント種別（「ジョブ操作クライアント」／「データ管理クライアント」）を判定する。そして、当該ＭＦＰ１０は、当該ＡＰＩリクエストに対するレスポンス情報を当該クライアント種別に基づいて決定する。

詳細には、送信元装置が「データ管理クライアント」である場合には、当該ＡＰＩリクエストに対するレスポンス情報の候補群のうち、基本情報（データ管理とジョブ操作との双方で利用される情報）のみが当該ＡＰＩリクエストに対するレスポンス情報として決定される。一方、送信元装置が「ジョブ操作クライアント」であると判定される場合、基本情報のみならず、応用情報（データ管理では利用されずジョブ操作で利用される情報）もが、当該ＡＰＩリクエストに対するレスポンス情報として決定される。そして、ＭＦＰ１０は、決定されたレスポンス情報を送信元装置７０に送信する。

したがって、ＭＦＰ１０は、ＡＰＩのリクエスト元のクライアント（送信元装置）に対して効率的に情報を送信することが可能である。特に、送信元装置が「データ管理クライアント」である場合には、基本情報のみ（すなわち比較的少量のデータ）が当該ＡＰＩリクエストに対するレスポンス情報として送信される。それ故、送受信の対象データを絞り込むことによって、送信遅延等を抑制し、高い応答性（高い操作性）を得ることが可能である。

また、特に、ＡＰＩ利用履歴情報３１０に基づいて自動的に判定されたクライアント種別に応じて、ＡＰＩリクエストに対するレスポンス情報が自動的に決定される。したがって、ＩＰアドレスに対して固定的に割り付けられたクライアント種別に基づいてレスポンス情報が決定される場合（後述）に比べて、レスポンス情報を柔軟に且つ適切に決定することが可能である。

＜２．第２実施形態＞
第２実施形態は、第１実施形態の変形例である。以下では、第１実施形態との相違点を中心に説明する。

上記第１実施形態では、ステップＳ１２において、或るＡＰＩリクエストの送信元装置のクライアント種別が「ジョブ操作クライアント」と「データ管理クライアント」とのいずれに該当するかが判定される。この判定処理は、当該送信元装置による「ジョブ操作用ＡＰＩ」の利用履歴がＡＰＩ利用履歴情報３１０に含まれているか否かに関する基準Ｄ１（第１の基準とも称する）に依拠して実行される。また、送信元装置が「データ管理クライアント」である場合には、データ管理とジョブ操作との双方で利用される基本情報のみが当該ＡＰＩリクエストに対するレスポンス情報として決定される。一方、送信元装置が「ジョブ操作クライアント」であると判定される場合、基本情報のみならず、応用情報（データ管理では利用されずジョブ操作で利用される情報）もが、当該ＡＰＩリクエストに対するレスポンス情報として決定される。

これに対して、この第２実施形態では、ステップＳ１２において、或るＡＰＩリクエストの送信元装置のクライアント種別が「基本操作クライアント」（後述）と「応用操作クライアント」（後述）とのいずれに該当するかが判定される。この判定処理は、当該送信元装置による「ジョブ操作用ＡＰＩ」の利用履歴において「非基本レベル（応用レベル）パラメータ」が指定されているか否かに関する基準Ｄ２（第２の基準とも称する）に依拠して実行される。また、ステップＳ１４においては、送信元装置が「基本操作クライアント」である場合には、ＡＰＩに対するレスポンス情報の候補群のうち、「基本レベル」のパラメータ群のみが、当該ＡＰＩに対するレスポンス情報として決定される。一方、送信元装置が「応用操作クライアント」である場合には、「基本レベル」のパラメータ群のみならず「応用レベル」のパラメータ群もが、当該ＡＰＩに対するレスポンス情報として決定される。

第２実施形態においては、図３のデータテーブル２１０（２１１）に代えて図１１のデータテーブル２１０（２１２）が利用される。図３のデータテーブル２１１と比較すると判るように、図１１のデータテーブル２１２においては、「ジョブ設定変更ＡＰＩ」に関する「レスポンス情報変更処理の要否」が（「不要」ではなく）「要」に設定されており、その対応テーブルとしてテーブルＢ２１が規定されている点で、図３のデータテーブル２１１と相違する。また、図１１のデータテーブル２１２においては、「登録ユーザ情報取得ＡＰＩ」および「ボックス文書情報取得ＡＰＩ」のそれぞれに関する「レスポンス情報変更処理の要否」が（「要」ではなく）「不要」に設定されている点においても、図３のデータテーブル２１１と相違する。

また、第２実施形態においては、ステップＳ１２の動作として図１２の各動作が（図５の各動作に代えて）実行され、ステップＳ１４の動作として図１３の各動作が（図６の各動作に代えて）実行される。

具体的には、図１２に示されるように、第２実施形態に係るステップＳ１２（Ｓ１２Ｂとも称する）においては、ステップＳ２０が実行された後、（ステップＳ２２〜Ｓ２４に代えて）ステップＳ３２〜Ｓ３４が実行される。

なお、第２実施形態では、ステップＳ２０において図１１のデータテーブル２１２に基づきクライアント種別の判定要否が判定される。ステップＳ１１で受信していたＡＰＩが、「ジョブ実行ＡＰＩ」、「ジョブ実行履歴取得ＡＰＩ」、「登録ユーザ情報取得ＡＰＩ」および「ボックス文書情報取得ＡＰＩ」等のいずれかである場合には、「レスポンス情報変更処理の要否」が「不要」（図１１参照）であり、当該ＡＰＩの送信元装置のクライアント種別を判定しなくてよい旨が決定される。一方、ステップＳ１１で受信していたＡＰＩが「ジョブ設定変更ＡＰＩ」等である場合には、「レスポンス情報変更処理の要否」が「要」（図１１参照）であり、当該ＡＰＩの送信元装置のクライアント種別を判定すべき旨が決定される。

たとえば、「ジョブ設定変更ＡＰＩ」がステップＳ１１（図４）で受信されていた場合、ステップＳ２０からステップＳ３２に進む。

ステップＳ３２〜Ｓ３４においては、送信元装置のクライアント種別が、「基本操作クライアント」と「応用操作クライアント」とのいずれであるかが判定される。ここで、「基本操作クライアント」は、ジョブに関する複数のパラメータのうち「基本レベル」のパラメータ（設定値）のみの設定変更を実行するクライアント（「応用レベル」（次述）のパラメータの設定変更を実行しないクライアント）である。一方、「応用操作クライアント」は、ジョブに関する複数のパラメータのうち「応用レベル」のパラメータ（複数のパラメータのうち、基本レベルのパラメータ以外のパラメータ）の設定変更をも実行するクライアントである。

ここにおいて、たとえばコピージョブに関しては、図１４に示すような各種のパラメータが存在する。これらの複数のパラメータのうち、「カラー」、「用紙サイズ」、「倍率」、「濃度」、「原稿：片面／両面」、「印刷：片面／両面」、「部数」の各項目に関するパラメータは、基本的な操作で利用されるパラメータであり、「基本レベル」のパラメータ（基本レベルパラメータ）に分類される。一方、「原稿画質」、「集約」、「パンチ」、「ステープル」、「折り」、「カバー紙」などの各項目に関するパラメータは、基本的な操作では利用されず応用操作で利用されるパラメータであり、「応用レベル」のパラメータ（応用レベルパラメータ）に分類される。なお、他の種類のジョブ（スキャンジョブ等）のパラメータに関しても同様にして、「基本レベルパラメータ」と「応用レベルパラメータ」とに分類される。

この第２実施形態では、応用レベルパラメータに関する設定変更履歴の有無に基づいて、クライアント種別が判定される。

具体的には、ステップＳ３２において、当該送信元装置による「ジョブ設定操作ＡＰＩ」の利用履歴において、「応用レベルパラメータ」が過去に指定（設定変更）されていたか否かが判定される。換言すれば、「応用レベルのパラメータ」の指定履歴がＡＰＩ利用履歴情報３１０に存在するか否かが判定される。そして、その判定結果に基づいて、当該送信元装置が「応用操作クライアント」であるか「基本操作クライアント」であるかが判定される。

詳細には、当該送信元装置による「応用レベルパラメータ」の指定履歴がＡＰＩ利用履歴情報３１０に含まれている場合には、当該送信元装置は「応用操作クライアント」であると判定される（ステップＳ３３）。一方、当該送信元装置による「応用レベルパラメータ」の指定履歴がＡＰＩ利用履歴情報３１０に含まれていない場合には、当該送信元装置は「基本操作クライアント」であると判定される（ステップＳ３４）。

たとえば、送信元装置のＩＰアドレスが「192.168.56.XXX」である場合、図７（特に上から４段目参照）に示されるように、当該ＩＰアドレスのクライアントにより「ジョブ設定変更ＡＰＩ」が利用され、且つ、そのＡＰＩのパラメータとして「集約：２ｉｎ１」が指定されていた旨の履歴が、ＡＰＩ利用履歴情報３１０に含まれている。この場合、応用レベルパラメータの指定を伴う「ジョブ設定変更ＡＰＩ」が当該送信元装置から過去に受信（利用）されていた旨が判定される。そして、当該送信元装置は「応用操作クライアント」であると判定される（ステップＳ３３）。

一方、図７のようなＡＰＩ利用履歴情報３１０（３１１）ではなく図１６のようなＡＰＩ利用履歴情報３１０（３１２）が得られている場合には、異なる判定結果が得られる。具体的には、ＡＰＩ利用履歴情報３１２（図１６）には、「集約：２ｉｎ１」などの「応用レベルパラメータ」を指定したＡＰＩの利用履歴が存在しないので、当該送信元装置は「基本操作クライアント」であると判定される（ステップＳ３４）。

なお、図７のようなＡＰＩ利用履歴情報３１０（３１１）が得られている場合でも、送信元装置のＩＰアドレスが「10.0.22.YYY」であるときには、「応用レベルパラメータ」を指定したＡＰＩの利用履歴がＡＰＩ利用履歴情報３１０内に存在しないので、当該送信元装置は「基本操作クライアント」であると判定される（ステップＳ３４）。

このように、第２実施形態における「クライアント種別の判定処理」は、ジョブ設定操作に関するＡＰＩ（ジョブ設定変更ＡＰＩ等）の実行履歴にて応用レベルのパラメータが過去に指定されていたか否かに関する第２の基準Ｄ２に依拠して、実行される。換言すれば、送信元装置によって過去に利用されたＡＰＩにて指定されていたパラメータ情報（ＡＰＩ利用履歴情報３１０内の「被指定パラメータ」）に基づいて、当該送信元装置のクライアント種別が判定される。

次に、ステップＳ１４（詳細には、Ｓ１４Ｂ（図１３））の動作が行われる。ステップＳ１４（Ｓ１４Ｂ）においては、ステップＳ１１で受信されたＡＰＩリクエストに対する「レスポンス情報」が、ステップＳ１２で判定されたクライアント種別に基づいて、決定される。

ただし、第２実施形態に係るステップＳ１４Ｂにおいては、ステップＳ４０の後、（図６のステップＳ４２〜Ｓ４４に代えて）ステップＳ５２〜Ｓ５４が実行される。なお、ここでは、「ジョブ設定変更ＡＰＩ」がステップＳ１１で受信されていた場合を想定する。この場合、ＡＰＩのレスポンス情報をクライアント種別に応じて変更すべき旨が決定され、ステップＳ５２に進む。

ステップＳ５２においては、ＡＰＩの送信元装置が「応用操作クライアント」であるか「基本操作クライアント」であるかが判定される。そして、その判定結果に応じて、当該ＡＰＩのレスポンス情報が決定される。

具体的には、ＡＰＩの送信元装置が「応用操作クライアント」である場合には、「応用操作クライアント」用の情報がレスポンス情報として決定される（ステップＳ５３）。一方、ＡＰＩの送信元装置が「基本操作クライアント」である場合には、「基本操作クライアント」用の情報がレスポンス情報として決定される（ステップＳ５４）。

ここにおいて、「応用操作クライアント」用の情報、および「基本操作クライアント」用の情報は、各ＡＰＩごとに予め規定されている。たとえば、「ジョブ設定変更ＡＰＩ」に関しては、データテーブルＢ２１（図１５）に規定されている。

「ジョブ設定変更ＡＰＩ」がステップＳ１１にて受信されていた場合、図１１のデータテーブル２１０（２１２）に基づき、「ジョブ設定変更ＡＰＩ」に対応するデータテーブル（レスポンス情報決定用テーブル）Ｂ２１をさらに参照すべき旨が決定される。そして、ＭＦＰ１０は、データテーブルＢ２１（図１５）を参照することによって、「応用操作クライアント」用の情報、および「基本操作クライアント」用の情報を取得する（ステップＳ５３，Ｓ５４）。

図１５のデータテーブルＢ２１においては、「ジョブ設定変更ＡＰＩ」に対するレスポンス情報の候補群が列挙されている。具体的には、「カラー」、「用紙サイズ」、「倍率」、「濃度」、「原稿：片面／両面」、「印刷：片面／両面」、「部数」、「原稿画質」、「集約」、「パンチ」、「ステープル」、「折り」、「カバー紙」等のパラメータ群が、レスポンス情報の候補群として規定されている。なお、データテーブルＢ２１は、ＭＦＰ１０内に予め格納されている。

また、データテーブルＢ２１においては、当該ＡＰＩ（「ジョブ設定変更ＡＰＩ」）に対するレスポンス情報の候補群のうち、基本レベルのパラメータ群（「カラー」、「用紙サイズ」、「倍率」、「濃度」、「原稿：片面／両面」、「印刷：片面／両面」、「部数」等）のみが、「基本操作クライアント」用の情報として規定されている。

さらに、データテーブルＢ２１においては、当該ＡＰＩ（「ジョブ設定変更ＡＰＩ」）に対するレスポンス情報の候補群のうち、基本レベルのパラメータ群のみならず、応用レベルのパラメータ群（「原稿画質」、「集約」、「パンチ」、「ステープル」、「折り」、「カバー紙」等）もが、「応用操作クライアント」用の情報として規定されている。端的に言えば、レスポンス情報の候補群の全てが「応用操作クライアント」用の情報として規定されている。

ステップＳ５３においては、このデータテーブルＢ２１に基づいて、「応用操作クライアント」用の情報（基本レベルパラメータ群と応用レベルパラメータ群との双方）がレスポンス情報として決定される。また、ステップＳ５４においては、当該データテーブルＢ２１に基づいて、「基本操作クライアント」用の情報（基本レベルパラメータ群のみ）がレスポンス情報として決定される。

なお、複数のジョブ種類に共通する「ジョブ設定変更ＡＰＩ」がステップＳ１１で受信される場合には、ステップＳ５４においては複数のジョブ種類のパラメータ群（レスポンス情報の候補群）のうち基本レベルパラメータ群のみがレスポンス情報として決定され、ステップＳ５３においては複数のジョブ種類のパラメータ群のうち基本レベルパラメータ群と応用レベルパラメータ群との双方がレスポンス情報として決定されればよい。あるいは、複数のジョブ種類のそれぞれに固有のＡＰＩ（たとえば「コピージョブ設定変更ＡＰＩ」）がステップＳ１１で受信される場合には、ステップＳ５４においては当該ＡＰＩに対応する特定のジョブ種類（たとえば「コピージョブ」）のパラメータ群（レスポンス情報の候補群）のうち基本レベルパラメータ群のみがレスポンス情報として決定され、ステップＳ５３においては当該特定のジョブ種類のパラメータ群のうち基本レベルパラメータ群と応用レベルパラメータ群との双方がレスポンス情報として決定されればよい。

その後、ステップＳ１６，Ｓ１７の処理が実行される。

以上のような動作によれば、ＭＦＰ１０は、応用的な操作をも実行する応用操作クライアントに対しては、候補群の情報の全て（基本レベルパラメータ群と応用レベルパラメータ群との双方）をレスポンス情報として返信することによって、クライアント側で利用され得る可能性を一定程度以上有する情報を当該クライアントに適切に送信することが可能である。

一方、基本的な操作のみを実行する基本操作クライアントに対しては、比較的少量のデータ（基本レベルパラメータ群のみ）をレスポンス情報として返信することによって、通信対象のデータ量を削減することができる。そのため、クライアント側での受信処理および受信データの解析処理等に要する時間の長大化を抑制することが可能である。

このように、ＭＦＰ１０は、ＡＰＩのリクエスト元のクライアント（送信元装置）に対して効率的に情報を送信することが可能である。

＜３．第３実施形態＞
第３実施形態は、第１実施形態と第２実施形態との組合せに係る変形例である。以下では、上記第１実施形態等との相違点を中心に説明する。

この第３実施形態では、ＡＰＩごとに異なる基準（詳細には、２つの基準Ｄ１，Ｄ２）に基づき、送信元装置のクライアント種別が決定される。さらに、ＡＰＩごとに、異なる分類手法に基づくクライアント種別に応じて、レスポンス情報が決定される。

第３実施形態においては、データテーブル２１１，２１２（図３，図１１参照）に代えて図１７のデータテーブル２１０（２１３）が利用される。

図１７のデータテーブル２１３においては、「レスポンス情報変更処理の要否」に代えて、「区分基準」の欄が設けられている。この「区分基準」においては、各ＡＰＩに関するレスポンス情報の決定に際して、クライアント種別を判別する際の基準（Ｄ１，Ｄ２）等が規定されている。たとえば、「ジョブ設定変更ＡＰＩ」の送信元装置のクライアント種別の判定処理においては、上述の第２の基準Ｄ２が利用されるべき旨が規定されている。また、「登録ユーザ情報取得ＡＰＩ」および「ボックス文書情報取得ＡＰＩ」のそれぞれの送信元装置のクライアント種別の判定処理においては、上述の第１の基準Ｄ１が利用されるべき旨が規定されている。また、レスポンス情報変更処理を要しない場合（クライアント種別用の基準を要しない場合）には、「区分不要」の旨が規定されている。

また、第２実施形態においては、ステップＳ１２の動作として図１８の各動作が実行され、ステップＳ１４の動作として図１９の各動作が実行される。

具体的には、図１８に示されるように、第３実施形態に係るステップＳ１２（Ｓ１２Ｃとも称する）においては、ステップＳ２０が実行された後、ステップＳ２１〜Ｓ２４，Ｓ３１〜Ｓ３４が実行される。

ステップＳ２１，Ｓ３１では、ステップＳ１１で受信されたＡＰＩリクエストの送信元装置のクライアント種別を判定するための基準として、判定基準Ｄ１と判定基準Ｄ２とのいずれを採用すべきかが判定される。

ＭＦＰ１０は、データテーブル２１３（図１７）を参照して、判定基準Ｄ１を採用すべき旨が判定される場合には、（ステップＳ２０からステップＳ２１を経由して）ステップＳ２２に進む。そして、ステップＳ２３あるいはステップＳ２４において、判定基準Ｄ１に基づきクライアント種別（ジョブ操作クライアント／データ管理クライアント）が決定される。判定基準Ｄ１を採用すべき旨が判定される場合、ステップＳ３２〜Ｓ３４の処理は実行されない。

一方、ＭＦＰ１０は、データテーブル２１３（図１７）を参照して、判定基準Ｄ２を採用すべき旨が判定される場合には、（ステップＳ２０からステップＳ２１，Ｓ３１を経由して）ステップＳ３２に進む。そして、ステップＳ３３あるいはステップＳ３４において、判定基準Ｄ２に基づきクライアント種別（応用操作クライアント／基本操作クライアント）が決定される。判定基準Ｄ２を採用すべき旨が判定される場合、ステップＳ２２〜Ｓ２４の処理は実行されない。

その後、ステップＳ１４（Ｓ１４Ｃ）（図１９）の処理が実行される。

図１９に示されるように、第３実施形態に係るステップＳ１４（Ｓ１４Ｃとも称する）においては、ステップＳ４０が実行された後、ステップＳ４１〜Ｓ４４，Ｓ５１〜Ｓ５４が実行される。

ステップＳ４１，Ｓ５１では、ステップＳ１１で受信されたＡＰＩリクエストの送信元装置のクライアント種別を判定するための基準として、判定基準Ｄ１と判定基準Ｄ２とのいずれがステップＳ１２Ｃにて採用されていたかが判定される。

判定基準Ｄ１が採用されていた場合には、（ステップＳ４０からステップＳ４１を経由して）ステップＳ４２に進む。そして、ステップＳ４３あるいはステップＳ４４において、ステップＳ１２Ｃで決定されたクライアント種別（ジョブ操作クライアント／データ管理クライアント）に応じて、レスポンス情報が決定される。判定基準Ｄ１が採用されていた場合、ステップＳ５２〜Ｓ５４の処理は実行されない。

一方、判定基準Ｄ２が採用されていた場合には、（ステップＳ４０からステップＳ４１，Ｓ５１を経由して）ステップＳ５２に進む。そして、ステップＳ５３あるいはステップＳ５４において、ステップＳ１２Ｃで決定されたクライアント種別（応用操作クライアント／基本操作クライアント）に応じて、レスポンス情報が決定される。判定基準Ｄ２が採用されていた場合、ステップＳ４２〜Ｓ４４の処理は実行されない。

このような態様によれば、第１実施形態および第２実施形態と同様の効果を得ることができる。また、各ＡＰＩごとに、より適切なクライアント種別が判定され得るとともに、各ＡＰＩごとに、より適切なレスポンス情報が決定され得る。したがって、ＭＦＰ１０は、より多様なＡＰＩに関して、各ＡＰＩのリクエスト元のクライアント（送信元装置）に対して効率的に情報を送信することが可能である。

＜４．変形例等＞
以上、この発明の実施の形態について説明したが、この発明は上記説明した内容のものに限定されるものではない。

たとえば、上記各実施形態においては、ステップＳ１１（図４）にて一の送信元装置から一のＡＰＩのリクエストが受け付けられた場合、常に同じ処理（ステップＳ１２〜Ｓ１７）が実行されるが、これに限定されない。具体的には、ステップＳ１１にて一の送信元装置から一のＡＰＩのリクエストが受け付けられた場合において、当該リクエストが所定時間内の再リクエストであるときには、上記と異なる動作が実行されるようにしてもよい。

詳細には、ステップＳ１１にて一の送信元装置から一のＡＰＩのリクエストが受け付けられ、ステップＳ１４にて決定されたレスポンス情報が当該一の送信元装置にステップＳ１６にて送信された後、当該一のＡＰＩのリクエストの受付時点（あるいは、ステップＳ１６での送信時点）から所定時間以内（たとえば１分以内）に当該一のＡＰＩと同じＡＰＩのリクエストである再リクエストが当該送信元装置（一のＡＰＩの送信元装置と同じ装置）から受け付けられる場合を想定する。この場合、ステップＳ１２，Ｓ１４の処理は行われないようにしてもよい。そして、ステップＳ１６において、ＭＦＰ１０は、（今度は）当該ＡＰＩに対するレスポンス情報の候補群のうちの全てを当該再リクエストに対するレスポンス情報として決定し、当該候補群のうちの全てを当該再リクエストに対するレスポンス情報として当該送信元装置に送信するようにしてもよい。なお、この変形例では、クライアント７０は、一のＡＰＩリクエストに対して返信されたレスポンス情報に所要の情報が含まれていないときには、再リクエストを送信するように構成されているものとする。

このような変形例においては、一のリクエスト（最初のリクエスト）に対するレスポンス情報として、レスポンス情報の候補群の全てのデータのうちの一部のみ（たとえば「データ管理クライアント用のレスポンス情報」あるいは「基本操作クライアント用のレスポンス情報」）が送信されていた場合でも、「再リクエスト」に対するレスポンス情報としては、レスポンス情報の候補群の全てのデータ（当該一部のみよりも広範なデータ）が送信される。

これによれば、最初のリクエストに対するステップＳ１２でのクライアント種別の判定処理（推定処理）の結果が適切でなく最初のリクエストに対するレスポンス情報として所要の情報を得ることができない場合であっても、クライアント７０は、所定時間内に再リクエストをＭＦＰ１０に送信することによって、所要の情報を得ることが可能である。

また、上記各実施形態においては、ＡＰＩ利用履歴情報３１０に基づいて送信元装置のクライアント種別が判定（推定）されているが、これに限定されない。

たとえば、送信元装置から受信した当該送信元装置のＩＰアドレスに基づいて、当該送信元装置のクライアント種別が判定されてもよい。

具体的には、送信元装置のＩＰアドレスがグローバルＩＰアドレスであるかプライベートＩＰアドレスであるかに応じて、クライアント種別（「データ管理クライアント」／「ジョブ操作クライアント」）が判定されてもよい。

より詳細には、送信元装置のＩＰアドレスが「192.168.56.XXX」等）である場合には、当該ＩＰアドレスがプライベートＩＰアドレスであると判定される。この場合、当該送信元装置（クライアント７０）が社内に存在する可能性が高い。それ故、ＭＦＰ１０は、当該ＭＦＰ１０でのジョブ実行が当該クライアント７０を用いて操作されようとしている状況であると判断し、当該送信元装置を「ジョブ操作クライアント」として判定する。

一方、送信元装置のＩＰアドレスが「10.0.22.YYY」等）である場合には、当該ＩＰアドレスがグローバルＩＰアドレスであると判定される。この場合、当該送信元装置（クライアント７０）が社外に存在する可能性が高い。それ故、ＭＦＰ１０は、当該ＭＦＰ１０でのジョブ実行が当該クライアント７０を用いて操作されようとしている可能性は低いと判断し、当該送信元装置を（ジョブ操作クライアントではなく）データ管理クライアントとして判定する。

このように、送信元装置のＩＰアドレスに基づいて（詳細には、当該送信元装置のＩＰアドレスがグローバルＩＰアドレスであるかプライベートＩＰアドレスであるかに応じて）、当該送信元装置のクライアント種別が判定（推定）されてもよい。

あるいは、送信元装置から受信した当該送信元装置の装置識別情報（ＩＰアドレス等）と、各クライアントの装置識別情報と各クライアントのクライアント種別情報との対応関係を規定したデータテーブル５１０（図２０参照）とに基づいて、当該送信元装置のクライアント種別が判定されてもよい。換言すれば、ＩＰアドレスとクライアント種別との固定的な対応関係に基づいて、クライアント種別が判定されてもよい。

具体的には、各クライアントの装置識別情報（ＩＰアドレス等）と各クライアントのクライアント種別情報との対応関係を規定したデータテーブル５１０（図２０）をＭＦＰ１０内に格納しておく。そして、当該データテーブル５１０と、送信元装置から受信した送信元装置の装置識別情報（ＩＰアドレス）とに基づいて、送信元装置のクライアント種別が判定されてもよい。たとえば、送信元装置のＩＰアドレスが「192.168.56.XXX」である場合において判定基準Ｄ１が採用されるときには、データテーブル５１０に基づき、当該送信元装置は「ジョブ操作クライアント」である旨が判定されるようにしてもよい。同様に、送信元装置のＩＰアドレスが「192.168.56.XXX」である場合において判定基準Ｄ２が採用されるときには、当該送信元装置は「基本操作クライアント」である旨が判定されるようにしてもよい。

また、当該改変例のクライアント種別の判定手法と上記各実施形態のクライアント種別の判定手法とが状況に応じて組み合わせられるようにしてもよい。具体的には、送信元装置の利用履歴がＡＰＩ利用履歴情報３１０に存在する場合には、上記各実施形態のように送信元装置のクライアント種別がＡＰＩ利用履歴情報３１０に基づいて判定される。一方、当該送信元装置の利用履歴がＡＰＩ利用履歴情報３１０に存在しない場合には、上記改変例のように送信元装置から受信した当該送信元装置のＩＰアドレス（およびデータテーブル５１０）に基づいて、送信元装置のクライアント種別が判定されるようにしてもよい。

なお、上記各実施形態のように、各クライアントからのＡＰＩリクエストの履歴情報（ＡＰＩ利用履歴情報３１０）に基づいて、ＡＰＩリクエストの送信元装置のクライアント種別が判定されることによれば、当該クライアント種別を容易に判定することが可能である。また、ＡＰＩ利用履歴情報３１０に基づいて判定されたクライアント種別に応じて、ＡＰＩのリクエストに対するレスポンス情報が決定されるので、レスポンス情報を柔軟に且つ適切に決定することが可能である。

特に、上述の改変例のようにＩＰアドレス（およびデータテーブル５１０）に基づき判定する場合に比べて、同じＩＰアドレスの装置にて利用されるサービスの変更に対して（当該装置にて利用されるＡＰＩの変更に対して）柔軟に対応することが可能である。より詳細には、データテーブル５１０を変更することなく、ＡＰＩ利用履歴情報３１０内の履歴情報が自動的に変更されることに応じて、クライアント種別の判定結果を自動的に変更することが可能である。

たとえば、クライアント種別の判定結果を、基本操作クライアントから応用操作クライアントへと（あるいは、データ管理クライアントからジョブ操作クライアントへと）自動的に変更することが可能である。より詳細には、基本操作クライアントとして運用されていた或るクライアントが応用操作クライアントとして運用されるように変更された場合において、ＡＰＩ利用履歴情報３１０内の履歴情報に基づき当該クライアントのクライアント種別が自動的に変更され且つ当該クライアントへのレスポンス情報も「応用操作クライアント用の情報」へと自動的に変更される。

このように、上記各実施形態によれば、ＩＰアドレスに対して固定的に割り付けられたクライアント種別に基づいてレスポンス情報が決定される場合に比べて、レスポンス情報を柔軟に且つ適切に決定することが可能である。

また特に、上述の別の改変例のようにＩＰアドレスがグローバルＩＰアドレスかプライベートＩＰアドレスかに応じてクライアント種別が判定される場合に比べて、クライアント種別を正確に判定することが可能である。

また、上記各実施形態等においては、ＡＰＩ利用履歴情報３１０がＭＦＰ１０内に格納されているが、これに限定されない。

たとえば、ＡＰＩ利用履歴情報３１０は、ＭＦＰ１０とは別に設けられた外部サーバ（外部サーバの格納装置等）に格納されていてもよい。

その場合、ＭＦＰ１０は、ＡＰＩ利用履歴情報（詳細には、ＡＰＩの送信元装置に関する複数のＡＰＩの利用履歴情報）の送信要求を外部サーバに送信し、当該送信要求に応じて受信されたＡＰＩ利用履歴情報に基づいて、上記各実施形態等と同様の判定動作を実行すればよい。

さらには、当該判定動作を外部サーバが行うようにしてもよい。換言すれば、当該判定動作は、ＭＦＰ１０ではなく外部サーバによって行われようにしてもよい。より具体的には、ＭＦＰ１０は、送信元装置のクライアント種別を外部サーバに問い合わせ、当該外部サーバが当該判定処理を実行し、その処理結果（当該外部サーバからの問合せ結果）をＭＦＰ１０に返信する。そして、ＭＦＰ１０は、当該問合せ結果に基づいて、当該送信元装置のクライアント種別を取得するようにしてもよい。なお、当該外部サーバは、各装置のクライアント種別をＡＰＩ利用履歴情報３１０に基づき（ＭＦＰ１０からの問合せに先立って）予め判定しておいてもよい。あるいは、当該外部サーバは、ＡＰＩ利用履歴情報３１０を利用する手法以外の手法によって、各装置のクライアント種別を予め判定しておいてもよい。

また、上記各実施形態においては、第１の基準Ｄ１および／または第２の基準Ｄ２に基づいてクライアント種別が判定されているが、これに限定されず、その他の基準に基づいてクライアント種別が判定されてもよい。また、クライアント種別は、上述の種別以外の種別であってもよい。

１ 画像処理システム
１０ ＭＦＰ
２０ ＡＰＩサーバ部
７０ クライアント
２１０ ＡＰＩデータテーブル
３１０ ＡＰＩ利用履歴情報
４１０ 登録ユーザ関連情報
Ｂ１１、Ｂ１２，Ｂ２１ レスポンス情報決定用情報

Claims (24)

1. 画像処理装置であって、
   前記画像処理装置に関するＡＰＩのリクエストをクライアントから受け付ける受付手段と、
   前記リクエストの送信元装置である前記クライアントのクライアント種別を、各クライアントからのＡＰＩリクエストの履歴情報に基づいて判定する判定手段と、
   前記クライアントの前記クライアント種別に基づいて、前記ＡＰＩの前記リクエストに対するレスポンス情報を決定する決定手段と、
   前記決定されたレスポンス情報を前記クライアントに送信する送信手段と、
   を備え、
   前記決定手段は、前記クライアント種別が一の種別であると判定される場合、前記クライアント種別が他の種別であると判定される場合に比べて少ないデータ量の情報を、前記レスポンス情報として決定することを特徴とする画像処理装置。
2. 請求項１に記載の画像処理装置において、
   前記判定手段は、前記画像処理装置でのジョブ操作を実行する第１の種類のクライアントと、前記画像処理装置での前記ジョブ操作を実行せずデータ管理を実行する第２の種類のクライアントとのいずれかを、前記クライアント種別として判定することを特徴とする画像処理装置。
3. 請求項２に記載の画像処理装置において、
   前記判定手段は、前記ジョブ操作に関するＡＰＩの実行履歴が前記クライアントからの過去のＡＰＩリクエストとして前記履歴情報に存在するか否かに関する第１の基準に依拠して、前記送信元装置の前記クライアント種別が前記第１の種類のクライアントと前記第２の種類のクライアントとのいずれに該当するかを判定することを特徴とする画像処理装置。
4. 請求項２または請求項３に記載の画像処理装置において、
   前記決定手段は、
   前記送信元装置が前記第２の種類のクライアントであると判定される場合、前記ＡＰＩに対する前記レスポンス情報の候補群のうち、前記データ管理と前記ジョブ操作との双方で利用される基本情報のみを前記ＡＰＩに対する前記レスポンス情報として決定し、
   前記送信元装置が前記第１の種類のクライアントであると判定される場合、前記ＡＰＩに対する前記レスポンス情報の候補群のうち、前記基本情報のみならず、前記データ管理では利用されず前記ジョブ操作で利用される応用情報をも、前記ＡＰＩに対する前記レスポンス情報として決定することを特徴とする画像処理装置。
5. 請求項１に記載の画像処理装置において、
   前記判定手段は、ジョブに関するパラメータのうち基本レベルのパラメータ以外のパラメータである応用レベルのパラメータの設定変更をも実行する第３の種類のクライアントと、前記応用レベルのパラメータの設定変更を実行せず且つ前記基本レベルのパラメータの設定変更を実行する第４の種類のクライアントとのいずれかを、前記クライアント種別として判定し、
   前記基本レベルのパラメータは、所定の基本的な設定操作で利用されるパラメータであり、
   前記応用レベルのパラメータは、前記所定の基本的な設定操作以外の設定操作で利用されるパラメータであることを特徴とする画像処理装置。
6. 請求項５に記載の画像処理装置において、
   前記判定手段は、ジョブ設定操作に関するＡＰＩの実行履歴にて前記応用レベルのパラメータが過去に指定されていたか否かに関する第２の基準に依拠して、前記送信元装置の前記クライアント種別が前記第３の種類のクライアントと前記第４の種類のクライアントとのいずれに該当するかを判定することを特徴とする画像処理装置。
7. 請求項５または請求項６に記載の画像処理装置において、
   前記決定手段は、
   前記送信元装置が前記第４の種類のクライアントであると判定される場合、前記ＡＰＩに対する前記レスポンス情報の候補群のうち、前記基本レベルのパラメータ群のみを前記ＡＰＩに対する前記レスポンス情報として決定し、
   前記送信元装置が前記第３の種類のクライアントであると判定される場合、前記ＡＰＩに対する前記レスポンス情報の候補群のうち、前記基本レベルのパラメータ群のみならず前記応用レベルのパラメータ群をも、前記ＡＰＩに対する前記レスポンス情報として決定することを特徴とする画像処理装置。
8. 請求項１から請求項７のいずれかに記載の画像処理装置において、
   各クライアントからのＡＰＩリクエストの前記履歴情報を格納する格納手段、
   をさらに備えることを特徴とする画像処理装置。
9. 請求項１から請求項８のいずれかに記載の画像処理装置において、
   前記判定手段は、前記送信元装置の利用履歴が前記履歴情報に存在しない場合には、前記送信元装置から受信した前記送信元装置のＩＰアドレスに基づいて、前記送信元装置の前記クライアント種別を判定することを特徴とする画像処理装置。
10. 請求項１に記載の画像処理装置において、
    前記判定手段は、前記送信元装置から受信した前記送信元装置のＩＰアドレスに基づいて、前記送信元装置の前記クライアント種別を判定することを特徴とする画像処理装置。
11. 請求項９または請求項１０に記載の画像処理装置において、
    前記判定手段は、前記送信元装置から受信した前記送信元装置の前記ＩＰアドレスがグローバルＩＰアドレスであるかプライベートＩＰアドレスであるかに応じて、前記送信元装置の前記クライアント種別を判定することを特徴とする画像処理装置。
12. 請求項１から請求項１１のいずれかに記載の画像処理装置において、
    決定された前記レスポンス情報が前記クライアントに送信された後、所定時間内に前記ＡＰＩと同じＡＰＩのリクエストである再リクエストが前記送信元装置から受け付けられる場合、前記送信手段は、前記ＡＰＩに対する前記レスポンス情報の候補群のうちの全てを、前記再リクエストに対するレスポンス情報として前記送信元装置に送信することを特徴とする画像処理装置。
13. 画像処理システムであって、
    画像処理装置と、
    サーバと、
    を備え、
    前記画像処理装置は、
    前記画像処理装置に関するＡＰＩのリクエストをクライアントから受け付ける受付手段と、
    前記リクエストの送信元装置である前記クライアントのクライアント種別に基づいて、前記ＡＰＩの前記リクエストに対するレスポンス情報を決定する決定手段と、
    前記決定されたレスポンス情報を前記クライアントに送信する送信手段と、
    を備え、
    前記画像処理装置は、前記送信元装置の前記クライアント種別を前記サーバに問い合わせ、
    前記サーバは、前記リクエストの前記送信元装置である前記クライアントの前記クライアント種別を、各クライアントからのＡＰＩリクエストの履歴情報に基づいて判定し、
    前記画像処理装置は、前記サーバからの問合せ結果に基づいて前記クライアント種別を取得することを特徴とする画像処理システム。
14. 画像処理装置の制御方法であって、
    ａ）前記画像処理装置に関するＡＰＩのリクエストをクライアントから受け付けるステップと、
    ｂ）前記リクエストの送信元装置である前記クライアントのクライアント種別を、各クライアントからのＡＰＩリクエストの履歴情報に基づいて判定するステップ、
    ｃ）前記クライアントの前記クライアント種別に基づいて、前記ＡＰＩの前記リクエストに対するレスポンス情報を決定するステップと、
    ｄ）前記決定されたレスポンス情報を前記クライアントに送信するステップと、
    を備え、
    前記クライアント種別が一の種別であると判定される場合、前記ステップｃ）においては、前記クライアント種別が他の種別であると判定される場合に比べて少ないデータ量の情報が前記レスポンス情報として決定されることを特徴とする制御方法。
15. 請求項１４に記載の制御方法において、
    前記ステップｂ）は、
    ｂ−１）前記画像処理装置でのジョブ操作を実行する第１の種類のクライアントと、前記画像処理装置での前記ジョブ操作を実行せずデータ管理を実行する第２の種類のクライアントとのいずれかを、前記クライアント種別として判定するステップ、
    を備えることを特徴とする制御方法。
16. 請求項１５に記載の制御方法において、
    前記ステップｂ−１）は、
    前記ジョブ操作に関するＡＰＩの実行履歴が前記クライアントからの過去のＡＰＩリクエストとして前記履歴情報に存在するか否かに関する第１の基準に依拠して、前記送信元装置の前記クライアント種別が前記第１の種類のクライアントと前記第２の種類のクライアントとのいずれに該当するかを判定するステップ、
    を備えることを特徴とする制御方法。
17. 請求項１５または請求項１６に記載の制御方法において、
    前記ステップｃ）は、
    ｃ−１）前記送信元装置が前記第２の種類のクライアントであると判定される場合、前記ＡＰＩに対する前記レスポンス情報の候補群のうち、前記データ管理と前記ジョブ操作との双方で利用される基本情報のみを前記ＡＰＩに対する前記レスポンス情報として決定するステップと、
    ｃ−２）前記送信元装置が前記第１の種類のクライアントであると判定される場合、前記ＡＰＩに対する前記レスポンス情報の候補群のうち、前記基本情報のみならず、前記データ管理では利用されず前記ジョブ操作で利用される応用情報をも、前記ＡＰＩに対する前記レスポンス情報として決定するステップと、
    を備えることを特徴とする制御方法。
18. 請求項１４に記載の制御方法において、
    ステップｂ）は、
    ｂ−１）ジョブに関するパラメータのうち基本レベルのパラメータ以外のパラメータである応用レベルのパラメータの設定変更をも実行する第３の種類のクライアントと、前記応用レベルのパラメータの設定変更を実行せず且つ前記基本レベルのパラメータの設定変更を実行する第４の種類のクライアントとのいずれかを、前記クライアント種別として判定するステップ、
    を備え、
    前記基本レベルのパラメータは、所定の基本的な設定操作で利用されるパラメータであり、
    前記応用レベルのパラメータは、前記所定の基本的な設定操作以外の設定操作で利用されるパラメータであることを特徴とする制御方法。
19. 請求項１８に記載の制御方法において、
    ステップｂ−１）は、
    ジョブ設定操作に関するＡＰＩの実行履歴にて前記応用レベルのパラメータが過去に指定されていたか否かに関する第２の基準に依拠して、前記送信元装置の前記クライアント種別が前記第３の種類のクライアントと前記第４の種類のクライアントとのいずれに該当するかを判定するステップ、
    を有することを特徴とする制御方法。
20. 請求項１８または請求項１９に記載の制御方法において、
    前記ステップｃ）は、
    ｃ−１）前記送信元装置が前記第４の種類のクライアントであると判定される場合、前記ＡＰＩに対する前記レスポンス情報の候補群のうち、前記基本レベルのパラメータ群のみを前記ＡＰＩに対する前記レスポンス情報として決定するステップと、
    ｃ−２）前記送信元装置が前記第３の種類のクライアントであると判定される場合、前記ＡＰＩに対する前記レスポンス情報の候補群のうち、前記基本レベルのパラメータ群のみならず前記応用レベルのパラメータ群をも、前記ＡＰＩに対する前記レスポンス情報として決定するステップと、
    を備えることを特徴とする制御方法。
21. 請求項１４から請求項２０のいずれかに記載の制御方法において、
    前記ステップｂ）において、前記送信元装置の利用履歴が前記履歴情報に存在しない場合には、前記送信元装置から受信した前記送信元装置のＩＰアドレスに基づいて、前記送信元装置の前記クライアント種別が判定されることを特徴とする制御方法。
22. 請求項２１に記載の制御方法において、
    前記ステップｂ）において、前記送信元装置から受信した前記送信元装置の前記ＩＰアドレスがグローバルＩＰアドレスであるかプライベートＩＰアドレスであるかに応じて、前記送信元装置の前記クライアント種別が判定されることを特徴とする制御方法。
23. 請求項１４から請求項２２のいずれかに記載の制御方法において、
    ｅ）前記ステップｃ）にて決定された前記レスポンス情報が前記ステップｄ）にて前記クライアントに送信された後、所定時間内に前記ＡＰＩと同じＡＰＩのリクエストである再リクエストが前記送信元装置から受け付けられる場合、前記ＡＰＩに対する前記レスポンス情報の候補群のうちの全てを、前記再リクエストに対するレスポンス情報として前記送信元装置に送信するステップ、
    をさらに備えることを特徴とする制御方法。
24. 請求項１４から請求項２３のいずれかに記載の制御方法を、前記画像処理装置に内蔵されたコンピュータに実行させるプログラム。

Images