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

Abstract

【課題】機器と情報処理システムとの間の通信環境の状態を推定可能とする。
【解決手段】情報処理システム（サービス提供装置）２０のサーバ応答性監視部２３０は、ネットワークを介して接続される機器１０のスキャンアプリ１２０ａからスキャンサーバアプリ２１ａへの第１の要求Ａが受信されるＳ３０１と、第１の要求Ａに対する応答Ａ’の返信Ｓ３０２時から第１の要求Ａの後に機器１０から送信されるＳ３０４第２の要求Ｂの受信時までの経過時間を、機器１０から情報処理システムに対する第１の要求Ａに対して応答Ａ’が返却されるまでの通信時間の推定値として計測する。
【選択図】図２０

Description

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

例えば、オフィス等に設置されている複合機等の共用機器は、複数のユーザによって入れ替わり立ち替わり利用される。また、近年では、インターネット等のネットワークを介して提供されているサービス（例えば、クラウドサービス等）にアクセス可能な機器も有る。

上記のような利用形態を有する機器のアプリケーションは、ユーザによる操作に対する応答性が低下する場合が有る。このような機器は、並列的にタスクが実行される場合が多く、タスクの並列実行によって機器自体が高負荷状態になる可能性が有るからである。例えば、複合機であれば、大量の印刷やスキャン等の様々なタスクが並行的に実行されることにより、高負荷状態になる。

しかしながら、ネットワークを介して提供されているサービスと連携しているアプリケーションの応答性の低下の原因は、必ずしも機器自体が高負荷状態であることに限られない。例えば、機器自体は低負荷状態であるにも拘わらず、ネットワークの通信性能が低い若しくはネットワークの通信負荷が高いことも考えられる。又は、ネットワークを介して提供されているサービスへのアクセスが集中し、当該サービスの負荷が高まっていることも考えられる。

このように、応答性の低下に関して複数の原因が考えられる状況において、機器とネットワークを介して連携する情報処理システムとの通信環境の状態を知ることは、応答性の低下の原因の切り分けを行う上で有意義であると考えられる。

本発明は、上記の点に鑑みてなされたものであって、機器と情報処理システムとの間の通信環境の状態を推定可能とすることを目的とする。

そこで上記課題を解決するため、１以上の情報処理装置を含む情報処理システムは、ネットワークを介して接続される機器から第１の要求が受信されると、前記第１の要求に対する応答の返信時から前記第１の要求の後に前記機器から送信される第２の要求の受信時までの経過時間を、前記第１の要求と前記応答との通信時間の推定値として計測する計測部を有する。

機器と情報処理システムとの間の通信環境の状態を推定可能とすることができる。

第一の実施の形態における情報処理システムの構成例を示す図である。 第一の実施の形態における機器のハードウェア構成例を示す図である。 第一の実施の形態におけるサービス提供装置のハードウェア構成例を示す図である。 第一の実施の形態における機器の機能構成例を示す図である。 機器側応答性監視アプリの機能構成例を示す図である。 実待機時間計測部の状態遷移を示す図である。 第一の実施の形態におけるサービス提供装置の機能構成例を示す図である。 第一の実施の形態における情報処理システムが実行する処理手順の一例を説明するための図である。 応答性設定記憶部の構成例を示す図である。 高負荷閾値記憶部の構成例を示す図である。 機器側応答性監視アプリによって記録される情報の一例を示す図である。 各経過時間における印刷アプリのアプリ状態及びソケット通信状態を説明するための図である。 各経過時間におけるスキャンアプリのアプリ状態及びソケット通信状態を説明するための図である。 呼び出し元のアプリ名の特定方法を説明するための図である。 機器側応答性監視アプリによって記録される情報をグラフ化した図である。 遅延時間に対する閾値が二つである例を示す図である。 実待機時間の計測処理の処理手順の一例を説明するためのフローチャートである。 ｐｉｎｇコマンドを使用した通信環境の計測を説明するための図である。 第二の実施の形態におけるサービス提供装置の機能構成例を示す図である。 第二の実施の形態におけるサーバ応答時間の推定方法を説明するための図である。 サーバ応答時間の推定に用いられるシーケンスの所要時間の内訳を示す図である。 第二の実施の形態における情報処理システムが実行する処理手順の一例を説明するための図である。 サーバ応答時間の計測処理の処理手順の一例を説明するためのフローチャートである。 監視要求記憶部の構成例を示す図である。 第三の実施の形態におけるサービス提供装置の機能構成例を示す図である。 第三の実施の形態における情報処理システムが実行する処理手順の一例を説明するための図である。

以下、図面に基づいて本発明の実施の形態を説明する。図１は、第一の実施の形態における情報処理システムの構成例を示す図である。図１に示される情報処理システム１において、サービス提供環境Ｅ２及びユーザ環境Ｅ１は、インターネット等の広域的なネットワークを介して通信可能とされている。

サービス提供環境Ｅ２は、ネットワークを介してクラウドサービスを提供する組織におけるシステム環境である。なお、本実施の形態では、クラウドサービスを具体例に採用して説明するが、ＡＳＰ（Application Service Provider）によって提供されるサービスやＷｅｂサービス等、ネットワークを介して提供される他の形態のサービスに関して、本実施の形態が適用されてもよい。

サービス提供環境Ｅ２は、サービス提供装置２０を有する。サービス提供装置２０は、ネットワークを介して所定のサービスを提供する。サービス提供装置２０が提供するサービスの一つとして、「クラウドスキャンサービス」を例示する。クラウドスキャンサービスとは、機器１０においてスキャンされ、機器１０より転送された画像データを、所定のストレージに配信するサービスをいうが、特にその呼称に限定されるものではない。なお、サービス提供装置２０は、ユーザ環境Ｅ１に設置されてもよい。すなわち、サービス提供環境Ｅ２は、ユーザ環境Ｅ１に包含されてもよい。

ユーザ環境Ｅ１は、機器１０のユーザ企業等の組織におけるシステム環境である。ユーザ環境Ｅ１において、一台以上の機器１０と管理者端末３０とはＬＡＮ（Local Area Network）等のネットワークを介して接続されている。本実施の形態の機器１０は、スキャン、印刷、コピー、及びファクス（ＦＡＸ）通信等のうちの２以上の機能を１台の筐体で実現する複合機である。但し、上記のうちの１つの機能のみ、或いは他の機能を有する画像形成装置が機器１０として利用されてもよい。また、プロジェクタ、電子黒板、又はテレビ会議システム等の画像形成装置以外の機器が、機器１０として利用されてもよい。

管理者端末３０は、ユーザ環境Ｅ１における機器１０の管理者が使用する端末である。管理者端末３０の一例として、ＰＣ（Personal Computer）、ＰＤＡ（Personal Digital Assistance）、タブレット型端末、スマートフォン、又は携帯電話等が挙げられる。

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

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

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

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

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

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

なお、サービス提供装置２０は、図３に示されるようなハードウェアを有する複数のコンピュータによって構成されてもよい。すなわち、後述においてサービス提供装置２０が実行する処理は、複数のコンピュータに分散されて実行されてもよい。

図４は、第一の実施の形態における機器の機能構成例を示す図である。図４において、機器１０は、ＳＤＫアプリ１２０、ＳＤＫプラットフォーム１３０、コントロールサービス１４１、ソケットサービス１４２、ソケットフック部１４３、及びイベントフック部１４４等を有する。

ＳＤＫアプリ１２０は、機器１０の出荷後において、機器１０の機能拡張を図るために追加的にインストールされるアプリケーションプログラム（又はプラグイン、Ｂｒｏｗｓｅｒアプリなどともいう。）である。同図では、ＳＤＫアプリ１２０の一例として、スキャンアプリ１２０ａ、印刷アプリ１２０ｂ、及び機器側応答性監視アプリ１２０ｃ等が示されている。

スキャンアプリ１２０ａは、原稿からの画像データの読み取りと、当該画像データのサービス提供装置２０へアップロードとを機器１０に実行させるＳＤＫアプリ１２０である。サービス提供装置２０へアップロードされた画像データは、所定の宛先に配信される。

印刷アプリ１２０ｂは、サービス提供装置２０へ事前にアップロードされている印刷データのダウンロードと、当該印刷データの印刷とを機器１０に実行させるＳＤＫアプリ１２０である。なお、本実施の形態において、印刷データとは、印刷対象のデータを意味する。したがって、印刷データは、必ずしも、ＰＤＬ（Page Description Language）等の特定の言語によって記述されたデータに限定されない。例えば、文書データ等、ＰＤＬデータに変換前のデータが、印刷データであってもよい。

機器側応答性監視アプリ１２０ｃは、機器１０において起動されている各ＳＤＫアプリ１２０の状態監視や、機器１０の負荷状態の計測等を機器１０に実行させるＳＤＫアプリ１２０である。

なお、機器１０には、ＳＤＫアプリ１２０以外に、標準的なアプリケーションプログラムが、出荷時に予め実装されていてもよい。

ＳＤＫプラットフォーム１３０は、ＳＤＫアプリ１２０を開発するためのＡＰＩ（Application Program Interface）を備え、ＳＤＫアプリ１２０の実行環境を提供する。ＡＰＩの形態は、例えば、関数であってもよいし、オブジェクト指向プログラミングにおけるクラスのメソッド等であってもよい。以下、ＳＤＫプラットフォーム１３０が提供するＡＰＩを、「ＳＤＫＡＰＩ」という。例えば、ＳＤＫプラットフォーム１３０は、スキャン機能に関するＳＤＫＡＰＩ、印刷機能に関するＳＤＫＡＰＩ、コピー機能に関するＳＤＫＡＰＩ、通信に関するＡＰＩ等をＳＤＫアプリ１２０に提供する。ＳＤＫＡＰＩは公開されており、サードベンダ等によってもＳＤＫアプリ１２０は開発されうる。なお、ＳＤＫプラットフォーム１３０は、Ｊａｖａ（登録商標）ＶＭ（Virtual Machine）（以下、単に、「ＪａｖａＶＭ」という。）を含んでいてもよい。この場合、ＳＤＫアプリ１２０は、Ｊａｖａ（登録商標）言語によって実装される。例えば、ＳＤＫアプリ１２０は、Ｘｌｅｔアプリとして実装されてもよい。

図４において、ＳＤＫプラットフォーム１３０は、アプリ管理部１３１、パネル管理部１３２、パネルサービス部１３３、スキャンサービス部１３４、及び印刷サービス部１３５等を含む。

アプリ管理部１３１は、各ＳＤＫアプリ１２０のライフサイクルを管理する。すなわち、ＳＤＫアプリ１２０は、明確に定義されたライフサイクルモデルに従って動作する。ライフサイクルとは、例えば、起動状態、アクティブ状態、一時停止状態、及び終了状態の状態遷移を意味する。起動状態は、ＳＤＫアプリ１２０の起動時において初期化処理が実行される状態である。アクティブ状態は、ＳＤＫアプリ１２０が有する機能が実行される状態である。一時停止状態は、ＳＤＫアプリ１２０が有する機能が一時的に停止される状態である。終了状態は、ＳＤＫアプリ１２０が終了する状態である。

図４には、スキャンアプリ１２０ａ及び印刷アプリ１２０ｂのそれぞれの内部に、状態遷移図が示されている。それぞれの状態遷移図において、アクティブ状態の内部は、操作画面の遷移を示す。例えば、スキャンアプリ１２０ａの操作画面は、スキャン指定画面、スキャン実行画面、スキャン配信画面の順で遷移することが示されている。スキャン指定画面は、スキャンの設定情報等を受け付けるための画面である。スキャン実行画面は、スキャンの実行中に表示される画面である。スキャン配信画面は、スキャンされた画像データの配信中（アップロード中）に表示される画面である。また、印刷アプリ１２０ｂの操作画面は、印刷指定画面、印刷データ取得画面、及び印刷中画面の順で遷移することが示されている。印刷指定画面は、印刷の設定情報等を受け付けるための画面である。印刷データ取得画面は、印刷データのダウンロード中に表示される画面である。印刷中画面は、印刷の実行中に表示される画面である。

パネル管理部１３２は、アプリ管理部１３１の指示に従い、操作パネル１５の利用権限（以下、「パネル利用権限」という。）を管理する。すなわち、ＳＤＫアプリ１２０間において、操作パネル１５の利用（操作パネル１５への操作画面の表示）は、排他的である。したがって、基本的に、或る瞬間において、パネル利用権限が与えられるＳＤＫアプリ１２０は一つであり、斯かるパネル利用権限の授与及び回収等が、パネル管理部１３２によって行われる。本実施の形態では、アクティブ状態に遷移したＳＤＫアプリ１２０に、パネル利用権限が授与される。したがって、基本的に、アクティブ状態への遷移は排他的である。また、アクティブ状態でないことは（例えば、一時停止状態であること）、パネル利用権限を有さないこと、すなわち、バックグラウンドで動作中であることを示す。なお、一時停止状態は、必ずしも処理が完全に停止する状態であるとは限らない。パネル利用権限を有さなくても実行可能な機能を有するＳＤＫアプリ１２０については、一時停止状態において、当該機能に係る処理が実行される場合が有る。例えば、印刷アプリ１２０ｂは、印刷指定後において、バックグラウンドで印刷データの取得及び印刷を実行可能である。したがって、印刷アプリ１２０ｂは、一時停止状態において、印刷データの取得及び印刷を実行する場合がある。そうすることで、例えば、印刷が完了するまで他のＳＤＫアプリ１２０（例えば、スキャンアプリ１２０ａ）を利用できないといった不都合の発生を回避することができる。したがって、或るＳＤＫアプリ１２０のアクティブ状態と他のＳＤＫアプリ１２０の一時停止状態とが並行することで、２以上のＳＤＫアプリ１２０の処理が並列的に実行される可能性が有る。

パネルサービス部１３３は、操作パネル１５に対する操作画面等の描画に関するＳＤＫＡＰＩを提供する。パネルサービス部１３３は、パネル管理部１３２によってパネル利用権限が授与されたＳＤＫアプリ１２０による当該ＳＤＫＡＰＩの呼び出しに応じ、当該ＳＤＫアプリ１２０の操作画面の描画等を行う。

スキャンサービス部１３４は、スキャンの実行に関するＳＤＫＡＰＩを提供し、ＳＤＫアプリ１２０による当該ＳＤＫＡＰＩの呼び出しに応じ、スキャンの実行制御等を行う。当該実行制御に関して、スキャンサービス部１３４からコントロールサービス１４１に対してスキャンの実行要求が入力される。スキャンサービス部１３４は、複数のＳＤＫアプリ１２０からの要求について、排他制御を行う。

印刷サービス部１３５は、印刷の実行に関するＳＤＫＡＰＩを提供し、ＳＤＫアプリ１２０による当該ＳＤＫＡＰＩの呼び出しに応じ、印刷の実行制御等を行う。当該実行制御に関して、印刷サービス部１３５からコントロールサービス１４１に対して印刷の実行要求が入力される。印刷サービス部１３５は、複数のＳＤＫアプリ１２０からの要求について、排他制御を行う。

コントロールサービス１４１は、各種のハードウェアリソース等を制御するための機能（ＡＰＩ）を上位ソフトウェア等（ここでは、ＳＤＫプラットフォーム１３０等）に対して提供するソフトウェアモジュール群である。例えば、コントロールサービス１４１は、スキャナ１２の制御機能、プリンタ１３の制御機能、メモリ（ＲＡＭ１１２、ＲＯＭ１１３、及びＮＶＲＡＭ１１５等）の管理機能等を有する。なお、本実施の形態において、コントロールサービス１４１は、Ｃ又はＣ＋＋によるＡＰＩを提供する。一方、ＳＤＫＡＰＩは、Ｊａｖａ（登録商標）言語によるＡＰＩである。ＳＤＫＡＰＩは、コントロールサービス１４１が提供するＡＰＩについて、機種の相違に対して平滑化されたＪａｖａ（登録商標）によるＡＰＩであってもよい。その結果、各ＳＤＫアプリ１２０の機種に対する依存度を低下させることができる。

ソケットサービス１４２は、ソケット通信に関するＡＰＩを提供し、当該ＡＰＩの呼び出しに応じた処理を実行する。

ソケットフック部１４３は、ソケットサービス１４２が含むソケットモジュールの呼び出しを監視し、ソケット通信が行われたことを、予めソケットフック部１４３に対して登録されている通知先に通知する。本実施の形態では、機器側応答性監視アプリ１２０ｃが通知先として登録される。斯かる通知先の登録は、イベントリスナーを用いて実現されてもよい。イベントリスナーとは、イベントの通知を受け付けるためのメソッドを有するオブジェクトをいう。イベントの通知を受けたい側（ここでは、機器側応答性監視アプリ１２０ｃ）は、イベントの通知元（ここでは、ソケットフック部１４３）が呼び出し可能なメソッドを有するイベントリスナーを生成し、当該イベントリスナーを、イベントの通知元に登録する。イベントの通知元は、通知すべきイベント（ここでは、ソケット通信）を検知すると、登録されているイベントリスナーのメソッドを呼び出すことで、当該イベントの発生を、通知先に通知する。なお、以下に示されるようなＪａｖａ（登録商標）言語の関数を利用して、ソケットフック部１４３が実装されてもよい。

public static void Socket.setSocketImplFactory(SocketImplFactory fac)
イベントフック部１４４は、ＳＤＫプラットフォーム１３０とコントロールサービス１４１とのやりとりを（通信）監視し、当該やりとりが行われたことを、予めイベントフック部１４４に登録されている通知先に通知する。当該通知先についても、イベントフック部１４４に対応したイベントリスナーが用いられて実現されてもよい。なお、コントロールサービス１４１は、ＳＤＫプラットフォーム１３０より下層に位置するため、機器１０のハードウェアにより近い位置に存在する。したがって、機器１０のハードウェアに関して発生したイベント（例えば、キー操作）は、コントロールサービス１４１からＳＤＫプラットフォーム１３０に通知される。また、ＳＤＫプラットフォーム１３０が、機器１０のハードウェアを利用したい場合、コントロールサービス１４１に対して当該ハードウェアの利用に関する要求が行われる。このようなやりとりが、イベントフック部１４４によって監視される。

機器側応答性監視アプリ１２０ｃについて更に詳しく説明する。図５は、機器側応答性監視アプリの機能構成例を示す図である。図５に示されるように、機器側応答性監視アプリ１２０ｃは、実待機時間計測部１２１、遅延時間算出部１２２、負荷抑制部１２３、キー操作監視部１２４、ソケット監視部１２５、及び状態監視部１２６等として、機器１０を機能させる。なお、これら各部は、それぞれ異なるスレッドとして起動されてもよい。

実待機時間計測部１２１は、実待機時間計測部１２１として機器１０を機能させるスレッドについて、待機状態の所要時間を計測する。すなわち、実待機時間計測部１２１は、指定された待機時間（以下、「指定時間」という。）の待機と、待機からの復帰への状態遷移とを繰り返し、当該待機の開始から復帰までの経過時間（以下、「実待機時間」という。）を計測する。なお、実待機時間計測部１２１に係るスレッドの優先度は、他のＳＤＫアプリ１２０のスレッドの優先度と同等とされるのが望ましい。当該優先度は、ＯＳ（Operating System）において管理される優先度である。

図６は、実待機時間計測部の状態遷移を示す図である。図６に示される状態遷移図において、Ｒｕｎｎｉｎｇ状態は、上記での実行状態である。ＴｉｍｅｄＷａｉｔｉｎｇ状態は、上記での待機状態である。

実待機時間計測部１２１は、Ｒｕｎｎｉｎｇ状態からＴｉｍｅｄＷａｉｔｉｎｇ状態へ遷移する際に、Ｒｕｎｎｉｎｇ状態の退出時の時刻を記録しておく。ＴｉｍｅｄＷａｉｔｉｎｇ状態へ遷移すると、実待機時間計測部１２１は、指定時間分の待機を開始する。ＴｉｍｅｄＷａｉｔｉｎｇ状態において指定時間経過後、実待機時間計測部１２１は、Ｒｕｎｎｉｎｇ状態へ遷移する。但し、機器１０の負荷状態によっては、Ｒｕｎｎｉｎｇ状態へ遷移が指定時間に対して遅れる場合が有る。実待機時間計測部１２１は、Ｒｕｎｎｉｎｇ状態への遷移時に、前回のＲｕｎｎｉｎｇ状態の退出時刻から現在時刻までの経過時間（実待機時間）を計測し、計測結果を、例えば、ＲＡＭ１１２に記録する。ここで、Ｒｕｎｎｉｎｇ状態へ遷移が指定時間に対して遅れた場合、実待機時間は、指定時間よりも長くなる。

すなわち、一般的に、非リアルタイムＯＳの場合、決められた時間に処理が完了することは保障されていない。スレッドのスケジュールは、ＯＳが担っており、システムが高負荷で無い場合は、遅延が大きくなることがないが、高負荷の場合は遅延が大きくなる。例えば、相対的に高い優先度のプロセス（スレッド）が優先して実行されている場合や、低い優先度のプロセス（スレッド）がリソースを占有し、高い優先度のプロセス（スレッド）による当該リソースへのアクセスがブロックされる場合等において、遅延が大きくなる。

そこで、ＳＤＫアプリ１２０と同一の優先度のスレッドについて、図６に示される状態遷移の遅延（≒スレッドスケジュールの遅延）を測定することで、ＳＤＫアプリ１２０の応答の遅延が予測できると考えられる。なお、ＯＳのプロセス（スレッド）スケジューラは、スレッドの優先順位に応じて公平に処理順番を決めるが、低い優先度のスレッドが高い優先度のスレッドをブロックする場合もあるので、実行される順番は、ＯＳのスケジューラの仕様で決まる。

遅延時間算出部１２２は、機器１０（ＳＤＫアプリ１２０）の応答の遅延時間とスレッドの状態遷移の遅延時間とについて、以下の式（１）で示される相関に着目して、実待機時間に基づいて、機器１０の負荷の程度を示す指標値を生成する。

機器１０の応答の遅延時間≒スレッドの状態遷移の遅延時間 ・・・（１）
ここで、スレッドの状態遷移の遅延時間は、以下の式（２）によって求められる。

スレッドの状態遷移の遅延時間＝現時点のＲｕｎｎｉｎｇ状態入場時刻−前回のＲｕｎｎｉｎｇ状態退出時刻−指定時間 ・・・（２）
スレッドの状態遷移の遅延時間は、機器１０の負荷の程度を示す指標値の一例である。すなわち、遅延時間算出部１２２は、実待機時間計測部１２１によって計測される実待機時間と、実待機時間計測部１２１に対する指定時間との比較に基づいて、機器１０の負荷の程度を示す指標値を生成する。

負荷抑制部１２３は、遅延時間算出部１２２によって算出される遅延時間と、遅延時間に対する閾値とを継続的に比較し、比較結果が所定の条件を満たす場合（例えば、遅延時間が閾値以上である場合）に、機器１０が高負荷状態であると判定する。負荷抑制部１２３は、機器１０が高負荷状態であると判定された場合に、機器１０の負荷を低下させるための処理を実行して、当該高負荷状態の解消を試みる。機器１０の負荷を低下させる処理の一例として、機器１０おいて起動されている一部のプログラムに係る処理の制限が挙げられる。

キー操作監視部１２４は、機器１０の操作パネル１５に対するハードウェアキーの操作を監視し、検出されたキー操作の履歴を記録する。例えば、キー操作監視部１２４は、イベントフック部１４４に対してイベントリスナーを登録しておくことにより、キー操作の発生を検知することができる。

ソケット監視部１２５は、各ＳＤＫアプリ１２０によるソケット通信を監視し、ソケット通信の履歴を記録する。例えば、ソケット監視部１２５は、ソケットフック部１４３にイベントリスナーを登録しておくことにより、ソケット通信の発生を検知することができる。

状態監視部１２６は、各ＳＤＫアプリ１２０の起動状態、アクティブ状態、一時停止状態、及び終了状態等に関する状態遷移等を監視し、状態遷移の履歴を記録する。例えば、状態監視部１２６は、アプリ管理部１３１に対してイベントリスナーを登録しておくことにより、各ＳＤＫアプリ１２０の状態遷移を検知することができる。また、状態監視部１２６は、パネル管理部１３２にイベントリスナーを登録しておくことにより、いずれかのＳＤＫアプリ１２０によるパネル利用権限の獲得を検知することができる。更に、状態監視部１２６は、パネルサービス部１３３にイベントリスナーを登録しておくことにより、各ＳＤＫアプリ１２０の操作画面の画面遷移を検知することができる。

図７は、第一の実施の形態におけるサービス提供装置の機能構成例を示す図である。図７において、サービス提供装置２０は、スキャンサーバアプリ２１ａ、印刷サーバアプリ２１ｂ、及び機器側応答性監視サーバアプリ２１ｃ等のサーバアプリ２１を有する。各サーバアプリ２１は、機器１０におけるＳＤＫアプリ１２０と連携するための処理を、サービス提供装置２０のＣＰＵ２０４に実行させるアプリケーションプログラムである。スキャンサーバアプリ２１ａは、スキャンアプリ１２０ａと連携する。印刷サーバアプリ２１ｂは、印刷アプリ１２０ｂと連携する。機器側応答性監視サーバアプリ２１ｃは、機器側応答性監視アプリ１２０ｃと連携する。

サービス提供装置２０は、また、印刷データ記憶部２１１、応答性設定記憶部２２１、高負荷閾値記憶部２２２、高負荷情報記憶部２２３、及び負荷低下情報記憶部２２４等を利用する。これら各記憶部は、補助記憶装置２０２、又はサービス提供装置２０にネットワークを介して接続可能な記憶装置等を用いて実現可能である。

印刷データ記憶部２１１は、機器１０の印刷アプリ１２０ｂによって印刷される印刷データを記憶する。応答性設定記憶部２２１、高負荷閾値記憶部２２２、高負荷情報記憶部２２３、及び負荷低下情報記憶部２２４は、機器側応答性監視アプリ１２０ｃに関する設定情報や、機器側応答性監視アプリ１２０ｃから通知される情報等を記憶する。

以下、情報処理システム１において実行される処理手順について説明する。図８は、第一の実施の形態における情報処理システムが実行する処理手順の一例を説明するための図である。

ステップＳ１０１において、ユーザ環境Ｅ１の管理者が、管理者端末３０に表示されている画面を介して、機器１０の応答性設定について、機器１０ごとに選択を行う。応答性設定とは、高負荷時における機器１０の振る舞い（対処方法）に関する設定をいう。選択肢としては、例えば、以下の（１）及び（２）が有る。

（１）操作レスポンス優先
高負荷時にバックグランド処理を休止させ、操作パネル１５の操作に対する応答性を優先させる。バックグラウンド処理の休止は、例えば、当該バックグラウンド処理に係るスレッドの優先度を低下させることによって行われてもよい。又は、当該処理自体が停止されてもよい。

（２）同一優先
高負荷時でもバックグランド処理の休止は行わない。すなわち、高負荷時において特段の対処は行われない。

ここでは、（１）が選択されたこととする。管理者端末３０は、機器１０ごとの選択結果をサービス提供装置２０に送信する。すなわち、機器１０ごとに、当該機器１０の識別情報（以下、「機体番号」という。）と、当該機器１０に関する応答性設定の選択結果とを含む設定要求が、サービス提供装置２０に送信される。当該設定要求には、また、ユーザ環境Ｅ１ごとの識別情報も含まれる。当該識別情報を、以下「テナントＩＤ」という。

サービス提供装置２０の機器側応答性監視サーバアプリ２１ｃは、当該設定要求を受信すると、当該設定要求に含まれているテナントＩＤ，機体番号、及び選択結果を対応付けて、応答性設定記憶部２２１に記憶する（Ｓ１０２）。

図９は、応答性設定記憶部の構成例を示す図である。図９に示されるように、応答性設定記憶部２２１は、テナントＩＤ及び機体番号に対応付けて、応答性設定の選択結果を記憶する。

続いて、ユーザ環境Ｅ１において、いずれかの機器１０が起動されると、当該機器１０の機器側応答性監視アプリ１２０ｃの実待機時間計測部１２１は、当該機器１０に対する応答性設定の照会要求を、サービス提供装置２０に送信する（Ｓ１２１）。当該照会要求には、当該機器１０において起動されているＳＤＫアプリ１２０の識別情報（以下、「アプリ名」という。）の一覧、当該機器１０の機種名、及び当該機器１０の機体番号等が含まれる。

サービス提供装置２０の機器側応答性監視サーバアプリ２１ｃは、当該照会要求を受信すると、当該照会要求に含まれている機体番号に対応するレコードが、応答性設定記憶部２２１に記憶されているか否かを判定する。該当するレコードが有る場合、機器側応答性監視サーバアプリ２１ｃは、当該レコードに含まれている応答性設定の値を、照会要求の送信元の機器１０に返信する（Ｓ１２３）。なお、応答性設定の値と共に、機器１０が高負荷であることを判定するための、実待機時間に対する閾値（以下、「高負荷閾値」という。）と、負荷を低下させるための方法を示す情報（以下、「負荷低下方法」という。）とが返信される。高負荷閾値及び負荷低下方法は、高負荷閾値記憶部２２２に記憶されている。

図１０は、高負荷閾値記憶部の構成例を示す図である。図１０に示されるように、高負荷閾値記憶部２２２は、機種名に対応付けて、高負荷閾値及び負荷低下方法を記憶する。高負荷閾値が、機種名ごとに設定されるのは、機種に応じて処理性能が異なることにより、高負荷時の実待機時間の大きさが異なる可能性が有るからである。また、負荷低下方法が、機種名ごとに設定されるのは、例えば、機種に応じて、各種の負荷低下方法の実施の可否が異なるからである。図１０では、負荷低下方法の一例として、「サービス停止」及び「優先度低下」が示されている。「サービス停止」は、バックグラウンドで実行されているＳＤＫアプリ１２０が利用するサービス（本実施の形態では、スキャンサービス部１３４又は印刷サービス部１３５）の処理を一時的に停止させることを示す。「サービス停止」は、サービス側が一時停止用のインタフェース及び実装を備えている必要が有るため、特定の機種において実行可能な負荷低下方法である。優先度低下は、バックグラウンドで実行されているＳＤＫアプリ１２０のスレッドの優先度を低下させることを示す。

ステップＳ１２３において返信されるのは、照会要求に含まれている機種名に対応付けられて高負荷閾値記憶部２２２に記憶されている高負荷閾値及び負荷低下方法である。

実待機時間計測部１２１が、機器側応答性監視サーバアプリ２１ｃから返信された情報を受信し、当該情報に含まれている応答性設定の値が（１）である場合、機器側応答性監視アプリ１２０ｃは、機器１０の負荷状態の監視を開始する。

例えば、ステップＳ１２５において、実待機時間計測部１２１は、図６に示した状態遷移を実行することにより実待機時間を計測する。遅延時間算出部１２２は、実待機時間が計測されるたびに、式（２）に基づいて遅延時間を算出する（Ｓ１２６）。この際、遅延時間算出部１２２は、今回の遅延時間の期間において、ＦｕｌｌＧＣ（ガベージコレクション）等、図６の状態遷移を遅延させる既知の要因が発生した場合、遅延時間の算出を行わなくてもよい。すなわち、当該期間において計測された実待機時間は、無効とされてもよい。ＦｕｌｌＧＣの場合、大きな遅延を引き起こす場合が有り、このような要因によって機器１０の負荷状態を判定するのは、適切でないからである。

遅延時間が算出された場合、負荷抑制部１２３は、算出された遅延時間と、ステップＳ１２４において受信された高負荷閾値とを比較して、機器１０が高負荷状態であるか否かを判定する（Ｓ１２７）。例えば、当該遅延時間が当該高負荷閾値以上であれば、機器１０が高負荷状態であると判定される。

機器１０が高負荷状態でないと判定された場合、ステップＳ１２５が繰り返される。機器１０が高負荷状態であると判定された場合、負荷抑制部１２３は、当該機器１０に係るテナントＩＤ及び機体番号と、各ＳＤＫアプリ１２０の状態を示す情報と、遅延時間とを含む通知を、サービス提供装置２０に送信する（Ｓ１２８）。サービス提供装置２０の機器側応答性監視サーバアプリ２１ｃは、当該通知を受信すると、当該通知に含まれている情報を、高負荷情報記憶部２２３に記憶する（Ｓ１２９）。

続いて、負荷抑制部１２３は、負荷を低下させるための処理を実行する（Ｓ１３０）。例えば、当該処理は、ステップＳ１２４において受信された負荷低下方法に従って実行される。負荷低下方法が「サービス停止」である場合、負荷抑制部１２３は、現在バックグラウンド状態にあるＳＤＫアプリ１２０が利用するサービス（スキャンサービス部１３４又は印刷サービス部１３５）に対して、処理の一時停止を要求する。すなわち、該当するＳＤＫアプリ１２０がスキャンアプリ１２０ａである場合、スキャンサービス部１３４に対して一時停止が要求される。該当するＳＤＫアプリ１２０が印刷アプリ１２０ｂである場合、印刷サービス部１３５に対して一時停止が要求される。一時停止を要求されたサービスは、ＳＤＫアプリ１２０から既に要求されて実行中の処理、又はＳＤＫアプリ１２０から今後要求される処理について実行を停止する。その結果、ＣＰＵ１１１等の負荷が低下し、操作パネル１５を介した入力に対する応答性の向上を期待することができる。

また、負荷低下方法が「優先度低下」である場合、負荷抑制部１２３は、現在バックグラウンド状態にあるＳＤＫアプリ１２０のスレッドの優先度を低下させる。その結果、パネル利用権限を有するＳＤＫアプリ１２０の優先度が相対的に高くなり、ＣＰＵ１１１等の資源が当該ＳＤＫアプリ１２０に対して優先的に割り当てられる。したがって、操作パネル１５を介した当該ＳＤＫアプリ１２０への入力に対する応答性の向上を期待することができる。

なお、いずれのＳＤＫアプリ１２０がバックグラウンド状態であるかについては、状態監視部１２６によって記録される情報を参照することにより特定可能である。すなわち、ステップＳ１３０の時点において、当該情報が一時停止状態を示すＳＤＫアプリ１２０が、バックグラウンド状態であるＳＤＫアプリ１２０として特定されてもよい。

負荷抑制部１２３は、また、当該機器１０に係るテナントＩＤ及び機体番号と、実行した負荷低下処理の内容とを含む情報（以下、「負荷低下情報」という。）を、サービス提供装置２０へ送信する。サービス提供装置２０の機器側応答性監視サーバアプリ２１ｃは、当該負荷低下情報を負荷低下情報記憶部２２４に記憶する（Ｓ１３１）。続いて、ステップＳ１２５以降が繰り返される。なお、負荷低下情報記憶部２２４に記憶された負荷低下情報と、その後のステップＳ１２８において機器１０から送信される高負荷状態の通知とに基づいて、負荷低下情報が示す負荷低下方法の効果について評価が行われてもよい。例えば、負荷の低下効果が低い負荷低下方法については、見直し等が行われてもよい。

機器側応答性監視アプリ１２０ｃによって、ステップＳ１２５以降が繰り返し実行されている状況において、ユーザは、機器１０の操作パネル１５を介して印刷アプリ１２０ｂに対して印刷指示を入力する（Ｓ１１１）。続いて、印刷アプリ１２０ｂは、印刷指示において選択された印刷データを、サービス提供装置２０の印刷サーバアプリ２１ｂから取得（ダウンロード）する（Ｓ１１２）。なお、ステップＳ１１２においては、まず、ユーザがアクセス可能な印刷データの一覧情報が、印刷サーバアプリ２１ｂから取得される。当該一覧情報の中から選択された印刷データが、印刷サーバアプリ２１ｂ経由で印刷データ記憶部２１１から取得される。印刷アプリ１２０ｂは、印刷データを取得すると、当該印刷データに関して印刷ジョブを開始する（Ｓ１１３）。

ユーザは、また、印刷指示の後、印刷の完了を待たずにスキャンアプリ１２０ａの利用を開始する。例えば、操作パネル１５を介してスキャンアプリ１２０ａの操作画面の表示指示が入力されると、操作パネル１５に、スキャンアプリ１２０ａの操作画面（スキャン指定画面）が表示される。したがって、このタイミングで、印刷アプリ１２０ｂは、バックグラウンド状態となる。

ユーザは、スキャン指定画面を介してスキャンの実行指示を入力する（Ｓ１１４）。スキャンの実行指示には、画像データの読み取り設定や、読み取られた画像データの配信先の指定等が含まれる。続いて、スキャンアプリ１２０ａは、読み取り設定に従って、原稿からの画像データの読み取り（スキャン）を開始する（Ｓ１１５）。画像データの読み取りが完了すると、スキャンアプリ１２０ａは、当該画像データに関するアップロード要求を、サービス提供装置２０のスキャンサーバアプリ２１ａに送信する（Ｓ１１６）。画像データのアップロードが完了すると、スキャンアプリ１２０ａは、ユーザによって指定された配信先を示す情報を含む配信要求を、スキャンサーバアプリ２１ａに送信する（Ｓ１１７）。スキャンサーバアプリ２１ａは、アップロードされた画像データを、当該配信要求に含まれている情報が示す配信先へ配信する。

図８に示されるような処理が実行される場合、機器側応答性監視アプリ１２０ｃは、例えば、図１１に示されるような情報を記録する。図１１は、機器側応答性監視アプリによって記録される情報の一例を示す図である。

図１１に示されるテーブルの１行は、１秒毎のレコードである。各レコードは、経過時間、メモリ消費量、遅延時間、並びに各ＳＤＫアプリ１２０のアプリ状態及びソケット通信状態等を含む。なお、図１１は、各情報が一つのテーブルに記録されなければならないことを示すものではない。図１１は、機器側応答性監視アプリ１２０ｃの各部によって記録される各情報を時刻に基づいて同期させると、当該テーブルに示されるような情報が得られることを示すものである。

経過時間は、或る時点（例えば、印刷指示の開始時）からの経過時間を示す。メモリ消費量は、当該経過時間におけるメモリ消費量である。例えば、メモリ消費量は、ＯＳに問い合わせることにより取得可能である。遅延時間は、遅延時間算出部１２２によって算出及び記録される遅延時間である。単位は、ミリ秒である。

各ＳＤＫアプリ１２０（図１１では、スキャンアプリ１２０ａ及び印刷アプリ１２０ｂ）のアプリ状態は、当該経過時間における各ＳＤＫアプリ１２０のパネル利用権限の有無（すなわち、フォアグラウンド状態かバックグラウンド状態か）及び画面遷移を示す。すなわち、「：」の前の「Ｂ」は、パネル利用権限を有さないバックグランド状態を意味する。「Ｆ」は、パネル利用権限を有するフォアグラウンド状態を意味する。また、「Ｂ−＞Ｆ」は、バックグラウンド状態からフォアグラウンド状態への移行を意味し、「Ｆ−＞Ｂ」は、フォアグラウンド状態からバックグラウンド状態への移行を意味する。「：」の後は、表示中の操作画面を示す。アプリ状態は、機器側応答性監視アプリ１２０ｃの状態監視部１２６によって記録される。すなわち、「Ｂ」、「Ｆ」、「Ｂ−＞Ｆ」、及び「Ｆ−＞Ｂ」は、パネル管理部１３２から通知されるパネル利用権限の授与又は回収に基づいて記録される。パネル管理部１３２からの通知には、パネル利用権限の授与又は回収を示す情報と、パネル利用権限の授与先又は回収元のＳＤＫアプリ１２０のアプリ名とが含まれる。画面遷移は、パネルサービス部１３３からの画面の描画の通知に基づいて記録される。

ソケット通信状態は、ソケット通信の状態を示す情報である。「：」の前の「Ｃ」は、通信相手がサービス提供装置２０であることを示す。通信相手の識別は、ＩＰアドレスに基づいて行われてもよい。「：」の後の「Ｒ」又は「Ｗ」は、通信の方向を示す。「Ｒ」は、受信を示す。「Ｗ」は、送信を示す。「Ｒ」又は「Ｗ」に続く括弧内の値は、通信データのサイズと通信回数とを示す。ソケット通信状態は、機器側応答性監視アプリ１２０ｃのソケット監視部１２５によって記録される。すなわち、ソケット通信状態は、ソケットフック部１４３からソケット監視部１２５へ通知される情報である。なお、アプリ状態及びソケット状態について、「↓」は、直前の経過時間における状態が継続していることを示す。

各経過時間における印刷アプリ１２０ｂのアプリ状態及びソケット通信状態の記録について説明する。図１２は、各経過時間における印刷アプリのアプリ状態及びソケット通信状態を説明するための図である。図１２において、括弧内の数字は、図１１の経過時間に対応する。また、以下の説明における括弧内の数字も、図１１の経過時間に対応する。

（１）印刷アプリ１２０ｂは、アクティブ状態に遷移してパネル利用権限を獲得し、印刷指定画面を操作パネル１５に表示させている。アプリ管理部１３１は、印刷アプリ１２０ｂのアクティブ状態への遷移を、状態監視部１２６に通知する。また、パネル管理部１３２は、印刷アプリ１２０ｂにパネル利用権限を授与したことを状態監視部１２６に通知する。更に、パネルサービス部１３３は、印刷指定画面の描画を状態監視部１２６に通知する。状態監視部１２６は、これらの通知に基づいて、「Ｆ：印刷指定」を記録する。

（２）印刷アプリ１２０ｂは、印刷サーバアプリ２１ｂに対して、印刷データの一覧情報をソケット通信経由で要求する。ソケットフック部１４３は、当該ソケット通信に関する情報を、ソケット監視部１２５に通知する。ソケット監視部１２５は、当該通知に基づいて、「Ｃ：Ｒ（１ＫＢ／１回）」を記録する。

（３）印刷アプリ１２０ｂは、一覧情報の中から選択された印刷データについて、ソケット通信経由で印刷サーバアプリ２１ｂに対して取得要求を送信し、印刷指定画面から印刷データ取得画面へ操作画面を遷移させる。ソケットフック部１４３は、当該ソケット通信に関する情報を、ソケット監視部１２５に通知する。ソケット監視部１２５は、当該通知に基づいて、「Ｃ：Ｗ（１ＫＢ／１回）」を記録する。また、パネルサービス部１３３は、印刷データ取得画面の描画を状態監視部１２６に通知する。状態監視部１２６は、当該通知に基づいて、「Ｆ：印刷データ取得」を記録する。

（４）機器１０は、ユーザからのアプリケーションの切り替え指示に応じ、操作パネル１５へスキャンアプリ１２０ａの操作画面を表示させる。この際、アプリ管理部１３１は、印刷アプリ１２０ｂを一時停止状態に遷移させ、当該遷移を状態監視部１２６に通知する。また、パネル管理部１３２は、印刷アプリ１２０ｂからパネル利用権限を回収し、当該回収を状態監視部１２６に通知する。状態監視部１２６は、これらの通知に基づいて「Ｆ−＞Ｂ：画面切替」を記録する。但し、印刷アプリ１２０ｂは、一時停止状態へ移行してもソケット通信経由で印刷データの取得（ダウンロード）を実行する。ソケットフック部１４３は、当該ソケット通信に関する情報を、ソケット監視部１２５に通知する。ソケット監視部１２５は、当該通知に基づいて、「Ｃ：Ｒ（４ＭＢ／４回）」を記録する。

（５）印刷アプリ１２０ｂは、ソケット通信経由での印刷データの取得を継続する。ソケットフック部１４３は、当該ソケット通信に関する情報を、ソケット監視部１２５に通知する。ソケット監視部１２５は、当該通知に基づいて、「Ｃ：Ｒ（４ＭＢ／４回）」を記録する。（６）〜（８）も同様である。

（９）印刷アプリ１２０ｂは、取得した印刷データに関して印刷を開始する。

続いて、各経過時間におけるスキャンアプリ１２０ａのアプリ状態及びソケット通信状態の記録について説明する。図１３は、各経過時間におけるスキャンアプリのアプリ状態及びソケット通信状態を説明するための図である。図１３において、括弧内の数字は、図１１の経過時間に対応する。また、以下の説明における括弧内の数字も、図１１の経過時間に対応する。

（４）機器１０は、ユーザからのアプリケーションの切り替え指示に応じ、操作パネル１５へスキャンアプリ１２０ａの操作画面（スキャン指定画面）を表示させる。この際、アプリ管理部１３１は、スキャンアプリ１２０ａを一時停止状態からアクティブ状態に遷移させ、当該遷移を状態監視部１２６に通知する。また、パネル管理部１３２は、印刷アプリ１２０ｂから回収したパネル利用権限をスキャンアプリ１２０ａに授与し、当該授与を状態監視部１２６に通知する。状態監視部１２６は、これらの通知に基づいて「Ｂ−＞Ｆ：画面切替」を記録する。

（５）スキャンアプリ１２０ａは、ソケット通信経由でスキャンサーバアプリ２１ａから配信先候補情報受信する。配信先候補情報は、画像データの配信先の候補を示す情報である。ソケットフック部１４３は、当該ソケット通信に関する情報を、ソケット監視部１２５に通知する。ソケット監視部１２５は、当該通知に基づいて、「Ｃ：Ｒ（１ＫＢ／１回）」を記録する。配信先候補の受信は、（６）においても継続される。配信先情報の受信が完了すると、スキャンアプリ１２０ａは、配信先候補情報をスキャン指定画面に表示する。

続いて、ユーザによって、スキャン指定画面を介して、読み取り設定及び配信先指定等が入力され、スキャンの実行が指示される。

（８）機器１０は、原稿の読み取りを開始し、操作画面をスキャン実行画面へ遷移させる。この際、パネルサービス部１３３は、スキャン実行画面を描画し、当該描画を状態監視部１２６に通知する。状態監視部１２６は、当該通知に基づいて、「Ｆ：スキャン実行」を記録する。

（９）スキャンアプリ１２０ａは、原稿から読み取られた画像データを、ソケット通信経由でスキャンサーバアプリ２１ａに送信する。スキャンアプリ１２０ａは、また、操作画面をスキャン配信画面へ遷移させる。ソケットフック部１４３は、当該ソケット通信に関する情報を、ソケット監視部１２５に通知する。ソケット監視部１２５は、当該通知に基づいて、「Ｃ：Ｗ（１ＫＢ／４回）」を記録する。パネルサービス部１３３は、スキャン配信画面を描画し、当該描画を状態監視部１２６へ通知する。状態監視部１２６は、当該通知に基づいて、「Ｆ：スキャン配信」を記録する。（１０）から（１１）において、画像データの送信は継続する。なお、送信される画像データのサイズは、１２ＭＢあり、１ＭＢ単位で分割されて送信される。

（１２）スキャンアプリ１２０ａは、画像データの配信先を示す情報を、ソケット通信経由でスキャンサーバアプリ２１ａに送信する。ソケットフック部１４３は、当該ソケット通信に関する情報を、ソケット監視部１２５に通知する。ソケット監視部１２５は、当該通知に基づいて、「Ｃ：Ｗ（１ＫＢ／１回）」を記録する。

なお、ソケットフック部１４３によって検知されるソケット通信の通信元のが、いずれのＳＤＫアプリ１２０であるかについては、例えば、次のように特定されてもよい。

ＳＤＫアプリ１２０が、Ｊａｖａ（登録商標）アプリケーションである場合、例えば、Ｊａｖａ（登録商標）の標準クラスであるスレッドグループ（ＴｈｒｅａｄＧｒｏｕｐ）を用いて、各ＳＤＫアプリ１２０を識別することができる。スレッドグループとは、スレッド（Ｔｈｒｅａｄ）やスレッドグループの集合であり、一つ以上のスレッドをスレッドグループに関連付けることができる。また、スレッドグループには、名前（スレッドグループ名）を付加することができる。そして、各スレッド内では、当該スレッドが属するスレッドグループを識別することができる。なお、本実施の形態において、ＳＤＫプラットフォーム１３０の各部、ソケットフック部１４３、及びイベントフック部１４４等は、独立したプロセス又は独立したスレッドとして起動されるものではなく、ＳＤＫＡＰＩの呼び出し元のＳＤＫアプリ１２０のスレッド上で動作する。

斯かる仕組みに基づけば、例えば、ソケットフック部１４３では、以下のように呼び出し元のＳＤＫアプリ１２０のアプリ名を特定することができる。図１４は、呼び出し元のアプリ名の特定方法を説明するための図である。

図中、ＧＰｘ（ｘはａ〜ｃ）は、スレッドグループを示す。ｔｈｘ（ｘは、ａ〜ｄ）は、スレッドを示す。図１４の例では、スキャンアプリ１２０ａには、スレッドグループＧＰｂが関連付けられており、スレッドグループ名としてスキャンアプリ１２０ａのアプリ名が付加されている。また、スキャンサービス部１３４にはスレッドグループＧＰｃが関連付けられている。

スキャンアプリ１２０ａには、メソッドＡを実行中のスレッドｔｈａと、メソッドＢを実行中のスレッドｔｈｂとが存在する。ここで、スレッドｔｈａとスレッドｔｈｂとは、スレッドグループＧＰｂに属する。例えば、スキャンアプリ１２０ａのメソッドＢ内より、スキャンサービス部１３４のメソッドＣが呼び出された場合、メソッドＣは、スレッドｔｈｂ上で動作する。更に、メソッドＣよりソケット通信に関するＡＰＩが呼び出された場合、当該呼び出しを検知したソケットフック部１４３は、スレッドｔｈｂ上で動作する。したがって、ソケットフック部１４３が、ソケット通信を検知した時点のスレッドを確認するとスレッドｔｈｂが特定される。更に、ソケットフック部１４３が、スレッドｔｈｂが属するスレッドグループを確認すると、スレッドグループＧＰｂが特定される。そこで、ソケットフック部１４３が、スレッドグループＧＰｂのスレッドグループ名を取得すると、取得されるスレッドグループ名は、ソケット通信元のＳＤＫアプリ１２０のアプリ名に該当する。

なお、図１５は、機器側応答性監視アプリによって記録される情報をグラフ化した図である。図１５に示される折れ線グラフの縦軸は遅延時間であり、横軸は経過時間である。遅延時間が大きい時期に、機器１０の応答性が低下していることが推定される。

グラフの下側には、スキャンアプリ１２０ａ及び印刷アプリ１２０ｂのおおよその状態が経過時間に同期して図示されている。画面切り替えが発生した期間（すなわち、印刷データの取得が行われている期間）や、画像データのアップロードと印刷とが並行して実行される期間において、遅延時間が大きくなっている。このような期間では、スキャンアプリ１２０ａの操作画面の応答性が低下することが推測される。そこで、画面切り替え後において、印刷アプリ１２０ｂに関して負荷低下処理が実行されることで、スキャンアプリ１２０ａの操作画面の応答性の改善を期待することができる。

図１５には、高負荷閾値の一例が示されている。高負荷閾値が、図１５に示されるような値である場合、経過時間（４）において、負荷低下処理が実行される。但し、図１５のグラフには、負荷低下処理の効果は反映されていない。

なお、遅延時間に対する閾値は、２つ以上であってもよい。図１６は、遅延時間に対する閾値が二つである例を示す図である。図１６では、高負荷閾値に加え、中負荷閾値が追加され、機器１０の負荷状態が、低負荷状態、中負荷状態、及び高負荷状態の３つの状態に分類される例が示されている。例えば、負荷抑制部１２３は、中負荷状態を検知した場合と、高負荷状態を検知した場合とで、相互に異なる負荷低下処理を実行してもよい。高負荷状態の方が、相対的に負荷の低下効果が高い負荷低下処理が実行されてもよい。

なお、負荷抑制部１２３は、高負荷状態又は中負荷状態が検知された時点において、図アプリ状態の値（図１１参照）の先頭が「Ｂ」であるＳＤＫアプリ１２０を、負荷低下処理の対象として選択する。

続いて、図８のステップＳ１２５の詳細について説明する。図１７は、実待機時間の計測処理の処理手順の一例を説明するためのフローチャートである。

実待機時間計測部１２１は、待機の開始時（Ｒｕｎｎｉｎｇ状態の退出時）に、現在時刻を変数Ｔ０に代入する（Ｓ２０１）。続いて、実待機時間計測部１２１は、指定時間分の待機を実行する（Ｓ２０２）。指定時間は、予め指定されている。例えば、ｗａｉｔ関数が用いられる場合、ｗａｉｔ関数の引数に指定時間が指定される。指定時間分の待機から復帰すると、実待機時間計測部１２１は、現在時刻を変数Ｔ１に代入する（Ｓ２０３）。続いて、実待機時間計測部１２１は、Ｔ１−Ｔ０を実待機時間として算出する（Ｓ２０４）。

上述したように、本実施の形態によれば、機器側応答性監視アプリ１２０ｃが実行する処理は、図６又は図１７に示されるように、負荷の低い処理である。したがって、機器１０の負荷状態を比較的低負荷な処理によって推定可能とすることができる。

また、遅延時間が閾値を超える場合、バックグラウンド処理に関して、負荷を低下させるための処理が実行される。その結果、操作パネル１５を介したユーザによる操作に対する応答性を向上させることができ、ユーザに対してストレスの小さい操作性を提供できる可能性を高めることができる。

なお、既存のＳＤＫアプリ１２０（スキャンアプリ１２０ａ及び印刷アプリ１２０ｂ等）内において、ユーザからの操作要求を受け付ける箇所と、当該操作要求に対する応答を返却する箇所のそれぞれに、時間測定の監視コードを埋め込むことも考えられる。また、ＣＰＵ及びＩ／Ｏのトラフィックをカーネルレベルで監視することで負荷を監視することも可能である。しかし、これらの方法では、既存の各ＳＤＫアプリ１２０を改変する必要が有ったり、監視するために多くのＣＰＵリソースが消費されてしまったりする可能性が高い。本実施の形態によれば、このような問題を回避しつつ、機器１０の負荷状態を推定することができる。

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

第二の実施の形態では、機器１０（例えば、スキャンアプリ１２０ａ）からサービス提供装置２０（例えば、スキャンサービス部１３４アプリ）に対する要求に対して応答が返却されるまでの時間（以下、「サーバ応答時間」という。）等を計測する例について説明する。サーバ応答時間は、以下の式（３）によって規定される。

サーバ応答時間＝サービス実行時間＋往復の通信時間 ・・・（３）
サービス実行時間は、機器１０からの要求に応じてサービス提供装置２０側で実行される処理の所要時間である。往復の通信時間は、機器１０からの要求と、サービス提供装置２０からの応答とのそれぞれの通信時間の合計である。通信時間は、ユーザ環境Ｅ１の通信環境（例えば、通信性能）に依存する。通信環境を計測するための手段として、ｐｉｎｇコマンド（Packet Internet Groper）を用いることが考えられる。

図１８は、ｐｉｎｇコマンドを使用した通信環境の計測を説明するための図である。図１８では、サービス提供装置２０を対象（宛先）として、機器１０において実行されるｐｉｎｇコマンドｃ１と、機器１０を対象（宛先）として、サービス提供装置２０において実行されるｐｉｎｇコマンドｃ２とが示されている。

一般的に、ｐｉｎｇコマンドｃ１に対しては、サービス提供装置２０からの応答が正常に返信される。したがって、機器１０においては、ユーザ環境Ｅ１の通信環境を計測することができる。一方、ｐｉｎｇコマンドｃ２に関するパケットは、ユーザ環境Ｅ１に設置されているファイアウォールによって、通過が許可されない。したがって、サービス提供装置２０において、ｐｉｎｇコマンドを使用して、ユーザ環境Ｅ１の通信環境を計測することは困難である。

したがって、各機器１０においてｐｉｎｇコマンドを実行させれば、各機器１０の通信環境を計測することができる。しかし、既に利用されている全ての機器に対して、通信環境を計測するためのプログラムをインストールするのは経済的ではない。

そこで、第二の実施の形態では、ｐｉｎｇコマンドを用いずに、ユーザ環境Ｅ１の通信環境をサービス提供装置２０側で計測し、更に、機器１０から見た場合の、サービス提供装置２０の応答時間（すなわち、サーバ応答時間）を、サービス提供装置２０側で推定する例について説明する。

図１９は、第二の実施の形態におけるサービス提供装置の機能構成例を示す図である。図１９中、図７と同一部分には同一符号を付し、その説明は省略する。図１９において、サービス提供装置２０は、サーバ応答性監視部２３０を有する。サービス提供装置２０は、また、監視機器記憶部２３１及び監視要求記憶部２３２を利用する。監視機器記憶部２３１及び監視要求記憶部２３２は、補助記憶装置２０２、又はサービス提供装置２０にネットワークを介して接続可能な記憶装置等を用いて実現可能である。

サーバ応答性監視部２３０は、各機器１０から各サーバアプリ２１への要求と、各サーバアプリ２１から各機器１０への応答とを監視して、サーバ応答時間等を推定する。監視機器記憶部２３１は、サーバ応答時間の推定対象とする監視対象の機器１０の機体番号を記憶する。監視要求記憶部２３２は、監視対象とする要求及び応答を識別するための情報を記憶する。なお、本実施の形態では、監視対象とする要求及び応答が、全ての機器１０に対して共通である例を説明するが、機器１０ごとに、監視対象とする要求及び応答が異なってよい。

図２０は、第二の実施の形態におけるサーバ応答時間の推定方法を説明するための図である。サーバ応答性監視部２３０は、機器１０のＳＤＫアプリ１２０からの、サーバアプリ２１に対する要求の順番の規則性に着目して、サーバ応答時間等を推定する。すなわち、或る要求については、必ず特定の要求の次に送信されるという規則性が有り、当該規則性を利用して、サーバ応答時間等が推定される。図２０では、スキャンアプリ１２０ａからスキャンサーバアプリ２１ａに対して、要求Ａの後には、要求Ｂが送信されることが示されている。

すなわち、スキャンアプリ１２０ａが、スキャンサーバアプリ２１ａに対して要求Ａを送信すると（Ｓ３０１）、スキャンサーバアプリ２１ａは、要求Ａに応じた処理（サービスＡ）を実行し、その処理結果を含む応答Ａ'を返信する（Ｓ３０２）。スキャンアプリ１２０ａは、応答Ａ'を受信すると、応答Ａ'に含まれている情報を利用した処理を実行する（Ｓ３０３）。続いて、スキャンアプリ１２０ａが、要求Ｂをスキャンサーバアプリ２１ａに送信すると（Ｓ３０４）、スキャンサーバアプリ２１ａは、要求Ｂに応じた処理（サービスｂ）を実行し、その処理結果を含む応答Ｂ'を返信する（Ｓ３０５）。

スキャンアプリ１２０ａからスキャンサーバアプリ２１ａへの要求に関して、このような規則性が有る場合、サーバ応答性監視部２３０は、要求Ａの受信を検知すると、要求Ａが受信されてから応答Ａ'が返信されるまでの時間（サービス実行時間）を計測する。サーバ応答性監視部２３０は、また、応答Ａ'が返信されてから、要求Ｂが受信されるまでの時間を計測する。なお、応答Ａ'が返信されてから、要求Ｂが受信されるまでの時間を、「サービス待機時間」という。すなわち、サービス待機時間は、以下の式（４）によって規定される。

サービス待機時間＝応答Ａ'の通信時間＋応答Ａ'利用処理時間＋要求Ｂの通信時間 ・・・（４）
図２０に示されるシーケンスの所要時間の内訳は、例えば、図２１に示される通りである。図２１は、サーバ応答時間の推定に用いられるシーケンスの所要時間の内訳を示す図である。図２１において、横軸は、処理が実行される箇所を示し、縦軸は、時間を示す。縦軸に示されている時間ｔ１〜ｔ１５は、各処理の所要時間を示す。

時間ｔ１は、ユーザによる入力から要求Ａが送出されるまでに機器１０内で実行される処理の所要時間である。時間ｔ２は、機器１０から要求Ａが送出されてから、サービス提供装置２０において要求Ａが受信されたことがサーバ応答性監視部２３０によって検知されるまでの所要時間である。時間ｔ３は、サーバ応答性監視部２３０によって要求Ａの受信が検知されてから、スキャンサーバアプリ２１ａが要求Ａを受信するまでの所要時間である。時間ｔ４は、スキャンサーバアプリ２１ａによる、要求Ａに応じた処理（サービスＡ）の所要時間である。時間ｔ５は、スキャンサーバアプリ２１ａが応答Ａ'を出力してから、サービス提供装置２０による応答Ａ'の送出をサーバ応答性監視部２３０が検知するまでの所要時間である。なお、例えば、時間ｔ３〜ｔ５が、要求Ａに係るサービス実行時間である。

時間ｔ６は、サーバ応答性監視部２３０が応答Ａ'の送出を検知してから、機器１０において応答Ａ'が受信されるまでの所要時間である。時間ｔ７は、機器１０において応答Ａ'が受信されてから、応答Ａ'を利用した処理が開始されるまでの所要時間である。時間ｔ８は、応答Ａ'に応じて機器１０が実行する処理の所要時間である。時間ｔ９は、当該処理の完了から、要求Ｂが送出されるまでの所要時間である。なお、例えば、時間ｔ７〜ｔ９は、応答Ａ'利用処理時間である。時間ｔ１０は、機器１０から要求Ａが送出されてから、サービス提供装置２０において要求Ａが受信されたことがサーバ応答性監視部２３０によって検知されるまでの所要時間である。なお、例えば、時間ｔ６〜時間ｔ１０までが、サービス待機時間である。

時間ｔ１１以降の説明については、時間ｔ３〜ｔ７に関する説明により自明であるため省略する。

本実施の形態では、式（３）によって規定されるサーバ応答時間を、サービス提供装置２０において算出可能とするために、以下の式（５）及び式（６）によって示される前提が導入される。

（機器１０の低負荷時の）応答Ａ'利用処理時間＜＜サービス待機時間 ・・・（式５）
要求の通信量及び通信速度＝応答の通信量及び通信速度 ・・・（式６）
式（５）は、サービス待機時間に対して、応答Ａ'利用処理時間が十分小さい（無視できる程度に小さい）ことを示す。換言すれば、本実施の形態では、単に、相互に前後関係にあるという条件を満たすだけでなく、式（５）及び式（６）を満たすような要求が、要求Ａ及び要求Ｂとして選択される。すなわち、要求Ａ又は要求Ｂに該当する要求の識別情報が、監視要求記憶部２３２に登録される。

式（５）及び式（６）が満たされる場合、サービス待機時間を、機器１０とサービス提供装置２０との間の往復の通信時間としてみなすことができるため、式（３）によって規定されるサーバ応答時間は、式（３'）によって近似することができる。

サーバ応答時間≒サービス実行時間＋サービス待機時間 ・・・（３'）
ここで、サービス実行時間及びサービス待機時間は、サーバ応答性監視部２３０によって計測可能な時間である。したがって、第二の実施の形態によれば、機器１０から見たサービス提供装置２０の応答時間（すなわち、サーバ応答時間）を、サービス提供装置２０において推定することができる。なお、機器１０ごとに通信速度は異なるため、サービス待機時間は、機器１０ごとに異なる。したがって、サーバ応答時間は、機器１０ごとに計測（推定）される。

図２２は、第二の実施の形態における情報処理システムが実行する処理手順の一例を説明するための図である。図２２中、図８と同一処理には同一ステップ番号を付し、その説明は適宜省略する。

ステップＳ４０１において、ユーザ環境Ｅ１の管理者が、管理者端末３０に表示されている画面を介して、サーバ応答時間の計測対象とする機器１０の選択を行うと、管理者端末３０は、当該ユーザ環境Ｅ１のテナントＩＤと、選択された機器１０の機体番号とを含む、サーバ応答時間の計測要求を、サービス提供装置２０に送信する。

サーバ応答性監視部２３０は、当該計測要求を受信すると、当該計測要求に含まれているテナントＩＤ及び機体番号をサービス提供装置２０の監視機器記憶部２３１に記憶し、当該テナントＩＤ及び機体番号に係る機器１０からの要求の監視を開始する（Ｓ４０２）。すなわち、機器１０からの各要求には、テナントＩＤ及び機体番号そのもの、又はテナントＩＤ及び機体番号に関連付けられてサービス提供装置２０において管理されている情報が含まれている。なお、複数の機器１０が監視対象とされてもよい。

続いて、監視対象とされた機器１０に関して、ステップＳ１１４〜Ｓ１１７が実行される。ステップＳ１１４〜Ｓ１１７については、図８において説明した通りでよい。

サーバ応答性監視部２３０は、ステップＳ１１６において機器１０から送信されたアップロード要求がサービス提供装置２０において受信されたことを検知すると、サーバ応答時間の計測処理を開始する（Ｓ４１１）。すなわち、本実施の形態では、スキャンアプリ１２０ａからのアップロード要求が、図２０において説明した要求Ａに相当する。したがって、ステップＳ４１１では、アップロード要求に対する応答や、当該応答に応じてステップＳ１１７において機器１０から送信される配信要求等が監視される。サーバ応答性監視部２３０は、監視対象とされた要求又は応答が検知された時刻を、例えば、メモリ装置２０３に機器１０別に記録し、記録された時刻に基づいて、サービス実行時間、サービス待機時間、及びサーバ応答時間等を、監視対象とされた機器１０ごとに算出する。ここでのサービス実行時間は、アップロード要求の受信が検知されてから、アップロード要求に対する応答が返信されるまでの経過時間である。また、ここでのサービス待機時間は、アップロード要求に対する応答が返信されてから、配信要求が受信されるまでの経過時間である。サービス待機時間は、監視対象の機器１０とサービス提供装置２０との間のネットワークの通信環境（通信性能）を示す値として利用される。

続いて、サーバ応答性監視部２３０は、例えば、サービス実行時間、サービス待機時間、及びサーバ応答時間と、これらの時間が算出された機器１０に係るテナントＩＤ及び機体番号とを含む報告情報を、スキャンサーバアプリ２１ａと、当該機器１０が属するユーザ環境Ｅ１の管理者端末３０とに送信する（Ｓ４１２）。なお、管理者端末３０への報告情報の送信は、電子メールを利用して行われてもよい。例えば、サービス提供装置２０には、予め、機器１０ごとに、管理者端末３０に対するメールアドレスが記憶されていてもよい。

スキャンサーバアプリ２１ａは、報告情報を受信すると、当該報告情報に応じた処理を実行する（Ｓ４１３）。例えば、スキャンサーバアプリ２１ａは、当該報告情報に含まれているサービス待機時間が閾値を超える場合は、当該報告情報に含まれているテナントＩＤ及び機体番号に係る機器１０からの要求に関して制限を加えてもよい。すなわち、サービス待機時間は、機器１０とサービス提供装置２０との間の通信時間の推定値である。したがって、サービス待機時間が長い機器１０は、通信性能の低いネットワークに接続されている可能性が高いと考えられる。しかし、機器１０のユーザには、サービス提供装置２０の性能の劣化の問題であると認識される可能性が有る。

そこで、サービス提供装置２０の性能について、誤解を受けないようにするための対策として、このような機器１０に対しては、アップロード可能な画像データの合計サイズ等を制限することで、サーバ応答時間の長期化が回避されてもよい。

アップロード可能な画像データの合計サイズは、例えば、当該機器１０からの次回のスキャンサーバアプリ２１ａに対する何らかの要求の受信に対する応答に含められて、当該機器１０に通知されてもよい。当該機器１０は、当該通知を示す情報を、例えば、ＨＤＤ１１４に記憶する。スキャンアプリ１２０ａは、次回のジョブの実行の際に、当該情報が示す合計サイズの範囲内となるように、ユーザが指定可能なスキャン枚数及び解像度等を制限してもよい。

また、管理者端末３０に送信される報告情報には、機器１０とサービス提供装置２０との連携に関するアドバイスが含まれてもよい。例えば、当該報告情報には、ユーザ環境Ｅ１に係る通信環境が、サービス提供装置２０との連携に適した通信環境であるか否かを示す情報が含まれてもよい。サービス提供装置２０との連携に適した通信環境であるか否かは、サービス待機時間と閾値との比較に基づいて判定されてもよい。

また、機器１０の機体番号ごとに、サーバ応答時間及びサービス待機時間の履歴が時系列に記録されてもよい。斯かる履歴に基づいて、特定の時間帯における通信品質の劣化（すなわち、サービス待機時間の長期化）を示す情報が、管理者端末３０に送信される報告情報に含められてもよい。また、推奨可能なアプリケーションを示す情報が報告情報に含まれてもよい。

更に、報告情報は、機器１０に対して送信されてもよい。機器１０は、ジョブの実行前に、当該報告情報を参照して、サーバ応答時間の予測値を表示してもよい。

続いて、ステップＳ４１１の詳細について説明する。図２３は、サーバ応答時間の計測処理の処理手順の一例を説明するためのフローチャートである。

サーバ応答性監視部２３０は、機器１０からの要求の受信、又はサーバアプリ２１からの応答の返信を待機している（Ｓ５０１、Ｓ５０２）。サーバ応答性監視部２３０は、機器１０からの要求がサービス提供装置２０において受信されたことを検知すると（Ｓ５０１でＹｅｓ）、当該要求（以下、「対象要求」という。）の送信元の機器１０が監視対象であるか否かを判定する（Ｓ５０３）。当該判定は、対象要求に含まれている情報に基づいて特定される当該機器１０のテナントＩＤ及び機体番号が、監視機器記憶部２３１に記憶されているか否かに基づいて行うことができる。

当該テナントＩＤ及び機体番号が監視機器記憶部２３１に記憶されている場合（Ｓ５０３でＹｅｓ）、サーバ応答性監視部２３０は、当該要求が監視対象の要求であるか否かを、監視要求記憶部２３２を参照して判定する（Ｓ５０４）。

図２４は、監視要求記憶部の構成例を示す図である。図２４において、監視要求記憶部２３２は、計測開始要求と計測終了要求とのそれぞれの識別情報を記憶する。

計測開始要求は、サーバ応答時間等の計測の開始の契機となる要求である。図２４では、スキャンサーバアプリ２１ａに対するアップロード要求が、計測開始要求である例が示されている。計測終了要求は、サーバ応答時間等の計測の終了の契機となる要求である。図２４では、スキャンサーバアプリ２１ａに対する配信要求が、計測終了要求である例が示されている。なお、計測開始要求は、図２０の要求Ａに相当し、計測終了要求は、図２０の要求Ｂに相当する。

ステップＳ５０４では、対象要求に含まれている要求の内容が、計測開始要求又は計測終了要求に該当するか否かが判定される。すなわち、機器１０からの要求には、要求先のサーバアプリ２１の識別情報と、要求の識別情報とが含まれている。

対象要求が、監視対象に該当し（Ｓ５０４Ｙｅｓ）、かつ、対象要求が計測開始要求である場合（Ｓ５０５でＹｅｓ）、サーバ応答性監視部２３０は、変数Ｔ０（機体番号）に、現在時刻を代入する（Ｓ５０６）。なお、変数Ｔ０（機体番号）における「（機体番号）」は、対象要求の送信元の機器１０の機体番号を示す。すなわち、変数Ｔ０（機体番号）は、機体番号別に用意される変数Ｔ０のうち、対象要求に係る機体番号に対応する変数Ｔ０を意味する。後述される変数Ｔ１及びＴ２についても同様である。

サーバ応答性監視部２３０は、また、いずれかのサーバアプリ２１からの応答の送信を検知すると（Ｓ５１２でＹｅｓ）、当該応答の送信先が、監視対象の機器１０であるか否かを判定する（Ｓ５１３）。斯かる判定は、当該応答（以下、「対象応答」という。）に含まれている情報に基づいて特定されるテナントＩＤ及び機体番号が、監視機器記憶部２３１に記憶されているか否かに基づいて行うことができる。

当該テナントＩＤ及び機体番号が監視機器記憶部２３１に記憶されている場合（Ｓ５１３でＹｅｓ）、サーバ応答性監視部２３０は、対象応答が監視対象の応答であるか否かを、監視要求記憶部２３２を参照して判定する（Ｓ５１４）。すなわち、対象応答が計測開始要求に対する応答であれば、対象応答は、監監視対象であると判定される。なお、対象応答には、いずれの要求に対する応答であるのかを識別するための情報が含まれている。

対象応答が監視対象である場合（Ｓ５１４でＹｅｓ）、サーバ応答性監視部２３０は、変数Ｔ１（機体番号）に、現在時刻を代入する（Ｓ５１５）。

また、ステップＳ５０１において受信された要求（以下、「対象要求」という。）が、計測終了要求に該当する場合（Ｓ５０５でＮｏ）、サーバ応答性監視部２３０は、変数Ｔ２（機体番号）に、現在時刻を代入する（Ｓ５０７）。続いて、サーバ応答性監視部２３０は、Ｔ２（機体番号）−Ｔ１（機体番号）の演算結果をサービス待機時間（機体番号）に代入する（Ｓ５０８）。続いて、サーバ応答性監視部２３０は、Ｔ１（機体番号）−Ｔ０（機体番号）の演算結果をサービス実行時間（機体番号）に代入する（Ｓ５０９）。続いて、サーバ応答性監視部２３０は、Ｔ２（機体番号）−Ｔ０（機体番号）の演算結果を、サーバ応答時間（機体番号）に代入する（Ｓ５１０）。なお、ステップＳ５０８〜Ｓ５１０９に関して、変数Ｔ０、Ｔ１、及びＴ２の添え字である「（機体番号）」は、対象要求の送信元の機器１０の機体番号を示す。

続いて、サーバ応答性監視部２３０は、サービス待機時間（機体番号）及びサーバ応答時間（機体番号）を、例えば、補助記憶装置２０２に記録する（Ｓ５１１）。

上述したように、第二の実施の形態によれば、機器１０からの要求と、当該要求に対するサービス提供装置２０による応答との通信時間を、サービス提供装置２０において機器１０ごとに推定することができる。また、当該通信時間の推定値に基づいて、サーバ応答時間をサービス提供装置２０において推定することもできる。その結果、例えば、サービス提供装置２０の運用者は、機器１０ごとに、サービス提供装置２０の応答性を把握することができる。

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

図２５は、第三の実施の形態におけるサービス提供装置の機能構成例を示す図である。図２５中、図３又は図１９と同一部分には同一符号を付し、その説明は省略する。

第三の実施の形態において、サービス提供装置２０は、第一の実施の形態における構成と第二の実施の形態における構成とを含む構成を有する。

なお、機器１０は、例えば、図４において説明した構成を有する。

図２６は、第三の実施の形態における情報処理システムが実行する処理手順の一例を説明するための図である。図２６中、図８又は図２２と同一ステップには同一ステップ番号を付し、その説明は省略する。

第三の実施の形態では、基本的に、第一の実施の形態における処理手順と第二の実施の形態における処理手順とが組み合わされた処理手順が実行される。但し、図２６では、図２２のステップＳ４１２の代わりに、ステップＳ４５１が実行される。ステップＳ４５１において、サーバ応答性監視部２３０は、機器１０から受信された遅延時間や、当該機器１０に係るサービス待機時間、及びサーバ応答時間等に基づいて、応答性の低下の要因の分析処理を実行する。ここでいう応答性は、ユーザから見た場合の機器１０及びサービス提供装置２０による応答性をいう。当該分析処理は、サーバ応答時間が閾値以上である場合に行われてもよい。

例えば、機器１０から受信された遅延時間が所定値以上である場合には、機器１０における並列処理が、応答性の低下の要因であると判定されてもよい。また、サービス実行時間が所定値以上である場合には、サービス提供装置２０の負荷の増加が、応答性の低下の要因であると判定されてもよい。また、サービス待機時間が所定値以上である場合は、ユーザ環境Ｅ１の通信環境が、応答性の低回の要因であると判定されてもよい。なお、遅延時間、サービス実行時間、及びサービス待機時間等は、機器１０ごとに計測される。したがって、応答性の判定は、機器１０ごとに実行される。

なお、解析結果が、機器１０における並列処理が要因であることを示す場合には、サーバ応答性監視部２３０は、当該解析結果を当該機器１０に送信してもよい。この場合、当該機器１０は、負荷低下処理を実行してもよい。

また、解析結果が、サービス提供装置２０の負荷の増加を示す場合には、サービス提供装置２０において利用頻度の低いサーバアプリ２１や、現在利用されていないサーバアプリ２１等が停止されてもよい。また、リアルタイムでの実行が要求されていない処理が、後回しにされてもよい。

また、解析結果が、ユーザ環境Ｅ１の通信環境が要因であることを示す場合には、第二の実施の形態において説明した通りの対策が行われてもよい。

上述したように、第三の実施の形態によれば、機器１０側において計測される遅延時間と、サービス提供装置２０側で計測されるサービス実行時間及びサービス待機時間等に基づいて、機器１０とサービス提供装置２０との連携によって実現される処理に関する応答性の低下について、要因（原因）の切り分けを行うことができる。

なお、上記各実施の形態において、サービス提供装置２０は、情報処理システムの一例である。サーバ応答性監視部２３０は、計測部の一例である。

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

１ 情報処理システム
１０ 機器
１１ コントローラ
１２ スキャナ
１３ プリンタ
１４ モデム
１５ 操作パネル
１６ ネットワークインタフェース
１７ ＳＤカードスロット
２０ サービス提供装置
２１ サーバアプリ
２１ａ スキャンサーバアプリ
２１ｂ 印刷サーバアプリ
２１ｃ 機器側応答性監視サーバアプリ
３０ 管理者端末
８０ ＳＤカード
１１１ ＣＰＵ
１１２ ＲＡＭ
１１３ ＲＯＭ
１１４ ＨＤＤ
１１５ ＮＶＲＡＭ
１２０ ＳＤＫアプリ
１２０ａ スキャンアプリ
１２０ｂ 印刷アプリ
１２０ｃ 機器側応答性監視アプリ
１２１ 実待機時間計測部
１２２ 遅延時間算出部
１２３ 負荷抑制部
１２４ キー操作監視部
１２５ ソケット監視部
１２６ 状態監視部
１３０ ＳＤＫプラットフォーム
１３１ アプリ管理部
１３２ パネル管理部
１３３ パネルサービス部
１３４ スキャンサービス部
１３５ 印刷サービス部
１４１ コントロールサービス
１４２ ソケットサービス
１４３ ソケットフック部
１４４ イベントフック部
２００ ドライブ装置
２０１ 記録媒体
２０２ 補助記憶装置
２０３ メモリ装置
２０４ ＣＰＵ
２０５ インタフェース装置
２１１ 印刷データ記憶部
２２１ 応答性設定記憶部
２２２ 高負荷閾値記憶部
２２３ 高負荷情報記憶部
２２４ 負荷低下情報記憶部
２３０ サーバ応答性監視部
２３１ 監視機器記憶部
２３２ 監視要求記憶部
Ｂ バス

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

Claims (10)

1. １以上の情報処理装置を含む情報処理システムであって、
   ネットワークを介して接続される機器から第１の要求が受信されると、前記第１の要求に対する応答の返信時から前記第１の要求の後に前記機器から送信される第２の要求の受信時までの経過時間を、前記第１の要求と前記応答との通信時間の推定値として計測する計測部を有することを特徴とする情報処理システム。
2. 前記第２の要求は、前記第１の要求の次に受信される要求である、
   ことを特徴とする請求項１記載の情報処理システム。
3. 前記計測部は、更に、前記第１の要求の受信時から前記第２の要求の受信時までの経過時間を、前記第１の要求に対する応答時間の推定値として計測する、
   ことを特徴とする請求項１又は２記載の情報処理システム。
4. 前記情報処理システムは、ネットワークを介して複数の機器に接続され、
   前記計測部は、機器別に前記経過時間を計測する、
   ことを特徴とする請求項１乃至３いずれか一項記載の情報処理システム。
5. １以上の情報処理装置を含む情報処理システムが、
   ネットワークを介して接続される機器から第１の要求が受信されると、前記第１の要求に対する応答の返信時から前記第１の要求の後に前記機器から送信される第２の要求の受信時までの経過時間を、前記第１の要求と前記応答との通信時間の推定値として計測する計測手順を実行することを特徴とする情報処理方法。
6. 前記第２の要求は、前記第１の要求の次に受信される要求である、
   ことを特徴とする請求項５記載の情報処理方法。
7. 前記計測手順は、更に、前記第１の要求の受信時から前記第２の要求の受信時までの経過時間を、前記第１の要求に対する応答時間の推定値として計測する、
   ことを特徴とする請求項５又は６記載の情報処理方法。
8. 情報処理装置に、
   ネットワークを介して接続される機器から第１の要求が受信されると、前記第１の要求に対する応答の返信時から前記第１の要求の後に前記機器から送信される第２の要求の受信時までの経過時間を、前記第１の要求と前記応答との通信時間の推定値として計測する計測手順を実行させることを特徴とするプログラム。
9. 前記第２の要求は、前記第１の要求の次に受信される要求である、
   ことを特徴とする請求項８記載のプログラム。
10. 前記計測手順は、更に、前記第１の要求の受信時から前記第２の要求の受信時までの経過時間を、前記第１の要求に対する応答時間の推定値として計測する、
    ことを特徴とする請求項８又は９記載のプログラム。

Images