サーバと通信可能な情報処理装置であって、前記情報処理装置が前記サーバと通信するときの、複数のアクセス先のそれぞれと前記情報処理装置との間の通信条件を取得する取得手段と、前記取得手段が取得した前記通信条件に基づき、前記複数のアクセス先のそれぞれに応じたタイムアウト時間を決定する決定手段と、前記情報処理装置が前記サーバと通信して、前記複数のアクセス先のいずれかにアクセスするときに、前記決定手段により決定された、当該アクセス先に応じたタイムアウト時間に従って、当該通信をタイムアウトにするように制御する制御手段と、を備えることを特徴とする情報処理装置。前記サーバはWebサーバであり、前記情報処理装置はリレーサーバを介して前記Webサーバと通信可能であって、前記通信条件は、前記情報処理装置が前記Webサーバと通信するためのAPIコマンド数である、ことを特徴とする請求項1に記載の情報処理装置。前記取得手段は、前記情報処理装置と前記サーバとにおいて通信されるデータに応じたAPIコマンド数を取得することを特徴とする請求項2に記載の情報処理装置。情報処理装置とサーバとが通信するときの、当該通信のタイムアウト時間を決定する情報処理方法であって、前記情報処理装置が前記サーバと通信するときの、複数のアクセス先のそれぞれと前記情報処理装置との間の通信条件を取得する取得工程と、前記取得工程において取得された前記通信条件に基づき、前記複数のアクセス先のそれぞれに応じたタイムアウト時間を決定する決定工程と、前記情報処理装置が前記サーバと通信して、前記複数のアクセス先のいずれかにアクセスするときに、前記決定工程において決定された、当該アクセス先に応じたタイムアウト時間に従って、当該通信をタイムアウトにするように制御する制御工程と、を有することを特徴とする情報処理方法。請求項4に記載の方法の各工程をコンピュータに実行させるプログラム。クライアント装置がWebサーバからWebサービスを利用する場合に、クライアント装置のユーザが利用するWebサービスによってアクセス先が異なり、それによりWebサーバからの応答時間が異なる場合がある。しかしながら、そのような構成においては、従来、クライアント装置のタイムアウト時間は一定とされる。そのため、Webサービスによって応答時間が異なるにも拘わらず、クライアント装置では、Webサービスに関係なく一定の時間でタイムアウトとなる。上記の従来技術では、クライアント装置の種類に応じて、サーバがタイムアウト時間を設定しているが、そのクライアント装置がアクセスするアクセス先については考慮されていない。そのため、そのクライアント装置が種々のWebサービスを利用する場合であっても、クライアント装置‐サーバ間のタイムアウト時間は一定となる。このように、クライアント装置‐サーバ間のタイムアウト時間が一定の場合に、例えばクライアント装置がWebサーバから確実に情報を取得できるようにすることを考慮すれば、Webサーバからの応答時間が遅いWebサービスを想定して、タイムアウト時間を設定する必要がある。そのため、ユーザが利用するWebサービスが、Webサーバからの応答時間が早いものであったとしても、クライアント装置では、必要以上の長い時間、サーバからの応答を待ってからタイムアウトしなくてはならない場合がある。本発明は、上記の点に鑑み、情報処理装置のアクセス先に応じて適切な時間で通信をタイムアウトさせることができる情報処理装置、情報処理方法およびプログラムを提供することを目的とする。上記課題を解決するため、本発明に係る情報処理装置は、サーバと通信可能な情報処理装置であって、前記情報処理装置が前記サーバと通信するときの、複数のアクセス先のそれぞれと前記情報処理装置との間の通信条件を取得する取得手段と、前記取得手段が取得した前記通信条件に基づき、前記複数のアクセス先のそれぞれに応じたタイムアウト時間を決定する決定手段と、前記情報処理装置が前記サーバと通信して、前記複数のアクセス先のいずれかにアクセスするときに、前記決定手段により決定された、当該アクセス先に応じたタイムアウト時間に従って、当該通信をタイムアウトにするように制御する制御手段と、を備えることを特徴とする。本発明によれば、情報処理装置のアクセス先に応じて適切な時間で通信をタイムアウトさせることができる。以下、添付図面を参照して本発明の好適な実施例を詳しく説明する。尚、以下の実施例は特許請求の範囲に係る本発明を限定するものでなく、また本実施例で説明されている特徴の組み合わせの全てが本発明の解決手段に必須のものとは限らない。なお、同一の構成要素には同一の参照番号を付して、説明を省略する。実施例1[システム構成とハードウェア構成]図1は、本発明に係るWebサービスシステムの構成を示す図である。図1に示すように、クライアント装置としてのMFP多機能複合装置:MultifunctionalPeripheral101は、インターネット等のネットワーク110を介してWebサーバ103、104、105と接続されている。これらのサーバは、例えば写真共有サイト機能をクライアント装置に提供するサーバであり、以下、Webサーバ103、104、105をそれぞれサイト103、104、105ともいう。またMFP101は、リレーサーバ102を介して、各Webサーバ103~105とデータの送受信を行う。この構成においてリレーサーバは、各Webサーバとの間でそれぞれ定義されたAPIを用いてデータの送受信を行っている。また、リレーサーバは、MFPとの間においてはその間で定義されたAPIを用いてデータの送受信を行う。つまり、リレーサーバがAPI変換の役割を果たす。さらに、このシステムにおいて、MFP101が利用するWebサービスによって、MFPがアクセスするWebサーバが異なる。即ち、MFP101は、MFP101のユーザが利用するWebサービス例えば写真共有サイトの種類に応じて、Webサーバ103~105のいずれかにアクセスする。このような構成において、MFP101がアクセスするWebサーバによって、リレーサーバ102とWebサーバの間の応答時間が異なってしまうことがある。この原因の1つに、WebサーバごとにAPIの構成が異なるという理由がある。よって、ユーザがMFP101を用いて複数のWebサービスを利用する場合に、Webサービスによってアクセス先のWebサーバが異なり、またアクセス先のWebサーバによって、リレーサーバ102‐Webサーバ間の応答時間が異なることになる。このように、MFP101のアクセス先のWebサーバによって応答時間が異なるため、MFP101‐リレーサーバ102間のタイムアウト時間も、そのアクセス先によって設定する必要がある。そこで、本実施例では、MFP101がリレーサーバ102を介して、Webサーバ103~105のいずれにアクセスする場合に、そのアクセス先のWebサーバに応じて、MFP101‐リレーサーバ102間のタイムアウト時間を設定する。詳細については後述する。ここで、写真共有サイト機能とは、クライアント装置により作成された写真等の画像をサーバに格納し、複数のクライアント装置により、サーバに格納されている画像にアクセスできる機能をいう。本実施例において情報処理装置としてのMFP101は、リレーサーバ102を介してサーバ103~105にアクセスすることで、各サイトの写真共有サイト機能を享受することができる。例えば、MFP101は、リレーサーバ102を介してサイト103~105から、画像が格納されている格納場所を示すURL等の登録情報を取得して、そのURLに従ってサーバにアクセスすることにより、アルバムや画像の選択画面を表示することができる。特に、上記のMFP101では、PC等を介さずにサイトにアクセスして、アルバムや画像の選択画面を表示装置に表示させることができる。ユーザがその選択画面において印刷を所望する画像を選択すると、MFP101は、印刷対象の画像データを各サイトから取得して印刷することができる。図2は、MFP101のハードウェア構成を示す図である。MFP101は、操作部201と、カードインタフェース202と、読取部208と、記録部209とを有する。また、MFP101は、CPU200と、ROM203と、RAM204と、不揮発性RAM205と、表示部206と、画像処理部210と、圧縮/解凍部211と、駆動部212と、センサ部213とを有する。CPU200は、MFP101全体を制御し、例えば操作部201を介して入力したユーザの指示に従ってROM203に記憶されているプログラムを実行する。ROM203は、MFP101の制御命令プログラム等を格納する。さらに、MFP101は、無線ネットワーク部207と有線ネットワーク部214とを有する。無線ネットワーク部207は、IEEE802.11a等の規格に対応した無線LANアクセスポイントと無線によって通信可能である。有線ネットワーク部214は、100Base-TX等のより対線ケーブルを接続可能なEthernet登録商標コネクタを有している。図1に示すリレーサーバ102や各サイト103~105には、一般的なPC等の構成が用いられる。つまり、リレーサーバ102や各サイト103~105は、一般的な、CPU、ROM、RAM、HDDやディスプレイ等の表示部、ポインティングデバイスやキーボード等の入力部を有する。例えば、上記各装置において、CPUはハードディスクやROM等から読み込まれたプログラムをRAMに展開して実行する。HDDは、各種フローチャートに示される処理を実行するプログラムや画像データを格納する。ディスプレイは、ユーザインタフェース等を表示し、ユーザは、ポインティングデバイスやキーボード等を用いてユーザインタフェース上で操作し、各種指示を入力することができる。[写真共有サイト]リレーサーバ102のアプリケーション構成を説明する前に、Webサービスの1つである写真共有サイト機能について説明する。各サイト103~105によりWebサービスとして提供される写真共有サイト機能は、主に、PCのブラウザで閲覧されることを想定している。また、ユーザはアカウントを取得し、そのアカウントとパスワードとをセットとして登録してからWebサービスを利用する。図4は、写真共有サイト機能について、各サイト103~105で登録されているデータ構成の一例を示す図である。各サイト103~105に登録される画像は、アルバムという単位で纏められている。例えば、図4に示すように、各サイトには、アルバムが5つ登録されている。また、アルバム1及び2には、それぞれ3つの画像が登録されている。また、アルバム3には1つの画像が登録され、アルバム4には4つの画像が登録され、アルバム5には2つの画像が登録されている。さらに、各アルバムには、そのアルバムを代表するサムネイル画像の他、アルバムのタイトルや、アルバム登録日等も含まれており、写真共有サイト機能を用いるためのブラウザ上に表示される。ユーザは、表示されたアルバムリストから1つのアルバムを選択すると、選択されたアルバムに登録された1つ以上の画像を閲覧することができる。以上のような写真共有サイト機能は、PCのブラウザからのみ利用可能というわけではない。例えば、公開された各サイト103~105のAPIを用いることによって、ブラウザを実装する装置以外の装置MFP等からもWebサービスを利用することができる。図5は、リレーサーバ102がAPIを利用して各サイト103~105から取得した、アルバムリストの記述例を示す図である。アルバムリストは、例えばXMLで記述される。図5に示すように、タグ<totalResults>から、アルバム数が10であることが確認できる。また、各アルバムの情報として、タグ<entry>ごとに、画像のURL、サムネイル画像のURL、ID、撮影日などが記述されている。MFP101は、ネットワーク通信機能によってリレーサーバ102のAPIに対応することができる。MFP101は、各サイト103~105から情報を取得する際に、各サイト103~105のAPIに直接、情報要求を発行しない。MFP101は、まず、リレーサーバ102との間で定義されたAPIを用いてリレーサーバ102とHTTPのPOST通信を利用してリレーサーバ102に対して情報要求を発行する。リレーサーバ102とMFP101との間でのAPIは、例えば下記のように定義される。API-R1コンディションチェック:MFP101の仕向け情報及びインターネット上のIPアドレスによって各サイトに接続可能かを確認する際に用いられる。API-R2ログイン認証:各サイトとの認証が可能かを判定する際に用いられる。API-R3アルバムリスト要求:全アルバムのリストを取得する際に用いられる。API-R4画像リスト要求:アルバムに登録されている全画像のリストを取得する際に用いられる。MFP101は、ユーザが指定したサイトに情報要求実際は、上記のようにリレーサーバ102に対して情報要求を発行することにより、当該情報要求に応じたアルバムリストや画像リストをリレーサーバ102から受信する。MFP101は、受信したリストの該当部分から表示用のデータのURLを取得することができる。MFP101は、認証及び上記リストの取得についてはリレーサーバ102を介して行うが、画像データ等のURLを取得した後は、各サイトから直接受信することができる。[リレーサーバ]リレーサーバ102は、MFP101が各サイト103~105から情報を取得する場合に、API変換機能を用いて仲介する役割を果たす。リレーサーバ102は、MFP101との関係においてWebサーバとして機能し、各サイト103~105との関係においては、Webクライアントとして機能する。図3は、リレーサーバ102のアプリケーション構成を示す図である。本実施例において、リレーサーバ102の主な機能はAPI変換機能である。リレーサーバ102は、MFP101との間でMFP-APIを定義している。リレーサーバ102は、MFP101との間で定義されたAPI構成を、接続先の各サイト103~105との間で定義されたAPI構成サイトA-API、サイトB-API、サイトC-APIにAPI変換する。図6は、サイトごとに定義されているAPIの一覧を示す図である。MFP101が各サイトから情報を取得するためには、リレーサーバ102が、各サイトとの間で定義されたAPI構成を用いる必要がある。つまり、MFP101が同じ情報を各サイトから取得する場合であっても、リレーサーバ102と各サイトとの間で定義されるAPIの構成は異なる。図7は、MFP101とリレーサーバ102との間で定義されるAPIAPIRとすると、リレーサーバ102と各サイトとの間で定義されるAPIとの対応を示す図である。この図7により、サイトからデータを取得するために必要なAPIの数は、MFPが要求するデータの種類によって異なり、また同じデータの種類であっても、接続先のサイトによっても異なることがわかる。例えば、アルバムリスト要求API-R3を用いてMFP101があるサイトを指定して情報要求する場合に、ユーザが指定したサイトによってリレーサーバ102から発行するAPIの種類と発行数が異なることが分かる。詳細については、後述する。図3を参照して、リレーサーバ102の各機能を説明する。リレーサーバ102は、以下のような機能を有している。なお、リレーサーバ102では、この各機能に対応するプログラムがROMに記憶されており、リレーサーバ102のCPUが、このROMに記憶されているプログラムを実行することにより、図3に示す各機能を実現できるものとする。パーサ機能:図5で示すような各サイトからのXMLリストをパーサにより解釈する。フィルタ機能:各サイトから受信したデータのうち、MFP101に送信する情報以外のデータを削除する。例えば、有効期限の切れたコンテンツや、指定以外のファイルタイプや、上限以上のファイルサイズの画像データ等を削除する。チェック機能:MFP101からのコンディションチェック要求に応じて、MFP101のIPアドレス及びMFP101から送信される情報に基づき、各サイトに接続可能かをチェックする。API判定機能:各サイトごとのAPI利用回数を比較する。例えば、MFP101から情報要求された場合に、その情報を取得するために必要なAPI利用回数を各サイトについて比較する。なお、本実施例では、このAPI判定機能によるAPI利用回数に基づいて、MFP101とリレーサーバとの間のタイムアウト時間を決定する。このAPI利用回数は、リレーサーバ102からMFP101に通知することが可能であり、MFP101は、この通知されたAPI利用回数に応じて、タイムアウト時間を決定する。制御機能:MFP101の仕向け情報に基づき、指定するサイトを振り分ける。本実施例においては、MFP101のタイムアウト値を、各サイトに応じて設定する。以下、その処理について説明する。MFP101は、まず、コンディションチェックを実行して接続可能なサイトを判定する。[コンディションチェック]図8は、コンディションチェックの処理の手順を示す図である。コンディションチェックは、リレーサーバ102と指定される各サイトとの通信状況を判定するための処理である。MFP101は、リレーサーバ102にコンディションチェックを要求するS801。リレーサーバ102がMFP101からの要求を受信すると、MFP101のIPアドレスに基づいて、そのMFP101が接続可能なサイトを特定するS802。リレーサーバ102は、その特定したサイトとともに、API判定機能による判定結果をMFP101に返信するS803。API判定機能による判定結果については後述する。また、リレーサーバ102は、コンディションチェックの要求を受信すると、テスト用のパケット等に基づき各サイトからの応答時間を確認して、MFP101に返信する。例えば、実測応答時間が230msecである場合には、その値MをMFP101に返信する。MFP101は、その値Mを各サイトとの通信環境の判定値として、ROM203等の自装置内のメモリに保存する。以下、接続候補になるサイトがサイト103~105の3つあり、そのうちサイト103とサイト104が接続可能と判定されたとして説明する。[MFPからのアルバムリスト/画像リスト要求例]MFP101が各サイトから画像を受信して印刷するまでの概要は以下のようである。まず、MFP101は、利用可能なサイト103及び104のうち1つを選択し、そのサイト内の個人用のアルバムにアクセスするためのアカウント及びパスワードを用いて、認証確認のためのAPI-R2をリレーサーバ102に発行する。その後、MFP101は、アルバムリストをサイトからリレーサーバ102経由で取得し、ユーザは、MFP101上で所望するアルバムを選択する。そして、MFP101は、所望のアルバムに登録されている画像リストをリレーサーバ102経由で取得し、ユーザは、MFP101上で所望する画像を選択する。MFP101は、選択された画像をサイトから受信して印刷を行う。上記の処理の流れについて、図9及び図10を参照して説明する。図9は、アルバムリストを取得して表示するまでの処理の手順を示す図である。MFP101は、アルバムリスト要求をAPI-R3を用いてリレーサーバ102に発行するS901。リレーサーバ102は、その要求を解析してAPI変換機能によって要求先のサイトに応じたAPI要求を発行するS902。要求先のサイトは、その要求に応じて、アルバムリストをリレーサーバ102に対して返信するS903。S902及びS903において用いられるAPIの構成は、各サイトにより異なる。リレーサーバ102は、例えば図5に示すような記述形式でアルバムリストを受信する。リレーサーバ102は、XMLをパースしてアルバムリストをMFP101に返信するS904。MFP101は、受信したアルバムリストに基づき、サイトに対して直接、HTTPのGet要求を発行するS905。そして、MFP101は、そのサイトからサムネイル画像を受信してS906、アルバムの選択画面をMFP101の表示画面に表示する。ユーザは、表示されたアルバムの選択画面から、所望のアルバムを選択するS907。若しくは、ユーザがアルバムの選択対象を切り替える度に、S905及びS906の処理が行われても良い。図10は、図9に示す処理の後、印刷対象の画像を特定して印刷するまでの処理を示す図である。MFP101は、アルバム画像を要求するために、API-R4をリレーサーバ102に発行するS1001。リレーサーバ102は、その要求を解析してAPI変換機能によって要求先のサイトに応じたAPI構成に変換し、その変換されたAPIを要求先のサイトに発行するS1002。サイトは、その要求に応じて、指定されたアルバム中の画像の画像リストをリレーサーバ102に対して返信するS1003。S1002及びS1003において用いられるAPIの構成は各サイトにより異なる。リレーサーバ102は、例えば図5に示すような記述形式で画像リストを受信する。リレーサーバ102は、XMLをパースして画像リストをMFP101に返信するS1004。MFP101は、受信した画像リストからサムネイル画像のURL情報等を取得し、サイトに対して直接、HTTPのGet要求を発行するS1005。そして、MFP101は、そのサイトからサムネイル画像を受信してS1006、画像の選択画面をMFP101の表示画面に表示する。ユーザは、表示された画像の選択画面から所望の画像を選択するS1007。若しくは、ユーザが画像の選択対象を切り替える度に、S1005及びS1006の処理が行われても良い。ユーザにより所望の画像が選択されて印刷が指示されると、MFP101は、印刷対象の画像データを取得するために、サイトに対して直接、HTTPのGet要求を発行しS1008、サイトから印刷対象の画像データを受信するS1009。MFP101は、受信した印刷対象の画像データを展開して記録媒体に印刷するS1010。[各サイトについてのAPI構成]上記の一連の処理において、アルバムリストや画像リスト取得のためにリレーサーバ102から各サイトに対して発行するAPIの利用回数発行されるAPIコマンド数が異なる。また、その相違に伴い、MFP101がサイトに情報を要求して取得するまでの応答時間も、各サイトによって異なる。以下、例を挙げて説明する。図11は、アルバムリストの要求をサイト103に対して発行した場合に、サイト103に対してリレーサーバ102が発行するAPIの利用回数を説明するための図である。リレーサーバ102は、サイト103に対して認証のためのAPI-A1を発行しS1101、次に、アルバムリストの取得のためのAPI-A2を発行するS1102。つまり、リレーサーバ102は、アルバムリスト取得までサイト103に対して、APIを2回発行する。図12は、アルバムリストの要求をサイト104に対して発行した場合に、サイト104に対してリレーサーバ102が発行するAPIの利用回数を説明するための図である。リレーサーバ102は、サイト104に対して認証を開始する条件確認のためのAPI-B1、API-B2、API-B3を発行するS1201~S1203。その後、リレーサーバ102は、認証のためのAPI-B4を発行するS1204。リレーサーバ102は、認証成功後、アルバムリスト取得のためのAPI-B5を発行するS1205。さらに、リレーサーバ102は、サイト104に対して、アルバムリストに含まれる各アルバムごとに、タイトルや撮影日等の情報取得のためのAPI-B6を発行するS1206。さらに、リレーサーバ102は、各アルバムごとに、アルバムに設定されている代表画像としてのサムネイル画像のURL等の情報を取得するためのAPI-B7を発行するS1207。例えば、図4に示すように、アルバムが5つ設定されている場合には、S1206及びS1207において各5回APIを利用するので、リレーサーバ102は、計15回のAPI要求をサイト104に対して発行することになる。図11に示す手順によって、MFP101が図4に示すアルバムリストを要求してからリレーサーバ102からアルバムリストを受信するまでの応答時間は1秒程度であった。一方で、図12に示す手順によって、MFP101が図4に示すアルバムリストを要求してからリレーサーバ102からアルバムリストを受信するまでの応答時間は10秒程度であった。このように、ユーザは、同じアルバムリストを異なるサイトから取得する場合に、各サイトに対して発行されるAPIの構成が異なるので、応答時間に差が生じてしまう。本実施例においては、上述のAPIの構成やコンディションチェック時の各サイトへの通信時間等の通信条件に応じて、各サイトに対するタイムアウト値を調整する。[タイムアウト値設定方法]図13は、本実施例におけるタイムアウト値設定処理の手順を示すフローチャートである。図13に示す処理は、例えば、CPU200がRAM204をワークメモリとしてROM203に記憶されているプログラムを実行することにより実行される。本実施例においては、MFP101とリレーサーバ102との間のコンディションチェックの結果を利用してタイムアウト値を設定する。上記のように、Webサーバのコンディションチェックにより、Webサーバ103~105のそれぞれの応答時間を取得することができる。また、コンディションチェックを実行するタイミングであるが、図13に示す処理を実行するときに実行してもよいが、予めコンディションチェックを行っていてもよい。この場合、コンディションチェックの結果である実測応答時間MがROM203に記憶されているため、タイムアウト時間を決定するタイミングでこの実測応答時間MをROM203から読み出して取得してもよい。また、図13において説明するタイムアウト時間の決定処理を実行するタイミングであるが、MFP101は、各サイトに対する情報要求をリレーサーバ102に発行する直前に、タイムアウト値を設定する。まず、CPU200は、S1301において、通信環境について判定を行う。S1301の判定においては、図14に示す判定テーブルを利用する。MFP101がリレーサーバ102にコンディションチェックを行なった際の実測応答時間Mを、予め定められた通信環境の基準値例えば、200[msec]と比較する。本実施例ではまず、実測応答時間Mを基準値200[msec]で除算して比率を求める。例えば、Mの値が230[msec]であるとすると、その比率は1.15となる。そして、図14に示すテーブルが参照される。本例においては、上段から2番目に該当するので、通信判定値は1.1と求められる。後述するが、本実施例では、S1301で取得した通信判定値に応じてタイムアウト時間の補正を行う。次に、CPU200は、S1302において、サービスAPIを判定する。図15は、サービスAPIの判定処理の手順を示すフローチャートである。以下、例えば、MFP101がアルバム数5、アルバム上の画像数50であるアルバム情報リストを各サイトから取得する場合について説明する。まず、CPU200は、S1501において、API判定機能を用いて判定する。サイト103については、図11に示すように、1つのアルバムリスト取得までにAPIを2回利用している。また、サイト104については、1つのアルバムリスト取得までにAPIを7回利用している認証で4回、データ取得で3回。また、サイト105については、例えば、図6に示すようにAPIが用いられるとすると、アルバムリスト取得までにAPIを1回利用する。本実施例においては、1つのアルバムリスト取得までの、複数のWebサーバにおける最低のAPI利用回数を基準として、各WebサーバにおけるAPI利用回数の比率を判定結果としている。このとき、サイト105におけるAPI利用回数1が最低の利用回数となる。よって、API利用回数の比率は、サイト103については2回/1回=2となり、サイト104については7回/1回=15となり、サイト105については1回/1回=1となる。即ち、MFPにより利用される複数のサイトのそれぞれの、APIの利用回数の比率により、API利用状況を複数のサイトにおいて相対的に評価する。この比率が高いほど、データを取得するために必要なAPIの数が多く、データを取得するために必要な時間が長くなると判断することができる。なお、API判定機能の判定結果として、上記のような比率の他に、各APIの処理時間や処理内容を考慮した値が用いられても良い。次に、CPU200は、S1502において、要求数補正処理を行う。これは、1つのサイトのAPI構成について、情報の要求数によってAPIを利用する回数が異なる場合に行われる。即ち、例えばMFP101においてユーザにより指定されたアルバムの数が複数であった場合、サイトによっては、その複数のアルバムのそれぞれに対して同数のAPIを用いる必要がない場合がある。このような場合に、1つのアルバム取得に必要なAPIの数を、単純にアルバム数で乗算するのではなく、各アルバムを取得するためのAPIの数を考慮してAPI使用回数を算出する。以下、サイト104について説明する。サイト104は、図6に示すように、最初のアルバムのアルバム情報を取得するためにAPIを3回API-B5~API-B7呼び出す必要があるが、2つ目のアルバム以降は、1つのアルバム情報取得のために、APIを2回API-B6及びAPI-B7呼び出す必要がある。例えば、サイト104から5つのアルバム情報を取得する場合、最初の1アルバムの時のAPI3回API-B5~API-B7に対して、追加の4アルバム分について、各2回API-B6及びAPI-B7増える。つまり、合計API利用回数は11回になる。本実施例においては、2回目以降の情報の取得のために必要なAPIの数を補正とする。よってサイト104では、補正値は2となる。一方、サイト103の場合には、情報の要求数によってAPIを利用する回数は変わらないので、補正値は0となる。次に、S1503において、API補正値を決定する。上述のように、例えばサイト104の場合には、API判定値は7であり、補正値は2である。従って、アルバム数5、アルバム上の画像数50であるアルバム情報リストを取得する場合には、API判定値は7で、追加の4アルバム分の補正値は8=4×2となる。つまり、サイト104に5アルバムを要求する場合に、API補正値は15=78と決定される。再び、図13を参照する。CPU200は、S1303において、タイムアウト値を設定する。図16は、タイムアウト値の設定処理の手順を示すフローチャートである。まず、CPU200は、S1601において、予め定められた初期タイムアウト値を取得する。ここでは、初期タイムアウト値を例えば30秒とする。次に、CPU200は、S1602において、S1301で判定した結果の通信判定値1.1を用いて、初期タイムアウト値を補正する。例えば、上述の30秒を1.1倍して、33秒と補正する。これにより、上記のコンディションチェックにより取得した実測応答時間Mに応じて、タイムアウト時間を調整できる。つまり、アクセス先のWebサーバの通信状況がよくない場合、実測応答時間Mが長くなるため、このときにはタイムアウト時間が長くなるように調整される。次に、CPU200は、S1603においては、S1302で決定されたAPI補正値を利用して、さらに補正を行う。ここで、サイト104について決定されたAPI補正値15を用いるとすると、上記33秒にAPI補正値15を乗算して495秒を算出する。これにより、アクセス先のWebサーバからデータを取得するために必要なAPIの数に応じて、タイムアウト時間を調整する。つまり、APIの使用回数が多い場合、タイムアウト時間がより長くなるよう調整される。CPU200は、S1604において、接続先サイトと情報要求数を確定して、リレーサーバ102に情報要求する前にタイムアウト値ここでは、495秒を設定する。このタイムアウト値は、MFP1101とリレーサーバ102との間のタイムアウト時間である。そして、例えばMFP101がリレーサーバ102に情報を要求してから、この設定されたタイムアウト時間が経過してもWebサーバからデータを取得できない場合に、MFP101においてタイムアウトとなる。上述した例では、サイト104に5つのアルバム情報を要求する場合には、495秒のタイムアウト値が設定される。本例においては、初期タイムアウト値30秒に実測応答時間に関する係数1.1と、要求するデータ量に応じたAPIコマンド数に関する係数15とを乗じて495秒を算出している。以上のように、本実施例では、MFP101がリレーサーバ102を介してWebサーバにアクセスするときの通信条件に応じて、MFP101とリレーサーバ102との間のタイムアウト時間を決定した。また、その通信条件の算出方法として、コンディションチェックにおいて計測された実測応答時間と、MFP101から要求するデータ量に応じたAPIコマンド数とに応じて算出した。このように算出したタイムアウト時間を、MFP101やリレーサーバ102に設定することにより、MFP101のアクセス先に応じた適切な時間で、タイムアウトとなる。例えばMFP101が、応答時間の短いアクセス先にアクセスして、そのアクセス先からデータを取得できない場合に、応答時間の長いアクセス先にアクセスした場合に比べて、短い時間でタイムアウトとなる。よって、MFP101のユーザが、必要以上に長い時間を待たなくても適切にタイムアウトになり、そのユーザは、当該アクセス先から適切にデータを取得するための操作や、他の操作を行うことができる。また、本実施例では、タイムアウト時間の算出方法として、初期タイムアウト値を、通信条件やAPIコマンド数に応じて変更する例を示した。しかしこれに限るものではなく、例えば、通信条件とAPIコマンド数に対応するタイムアウト時間を示すテーブルを、ROM203に記憶しておき、このテーブルに従ってタイムアウト値を設定してもよい。さらに、上記の初期タイムアウト値は、ROM203に予め記憶されているものを用いてもよいし、ユーザが指定できるようにしてもよい。実施例2図17は、本実施例におけるタイムアウト値設定処理の手順を示すフローチャートである。本実施例では、MFP101のアクセス先に応じて、予めタイムアウト値が設定されている例を示す。まず、CPU200は、S1701において、予め定められた初期タイムアウト値を取得する。例えば、初期タイムアウト値を30秒とする。次に、CPU200は、S1702において、情報を取得する先のサイトを特定する。ここでは、例えば、サイト104が特定されるとする。次に、CPU200は、S1703において、図18に示すテーブルを参照して、対応する接続サイトに応じたタイムアウト値を取得する。図18に示すテーブルは、ROM203に格納されており、サイトごとに予めAPIの構造的特性を考慮してタイムアウト値が予め設定されている。例えば、サイト104に対応するタイムアウト値は、600秒と設定されている。CPU200は、S1704において、取得したタイムアウト値600秒をタイムアウト値として決定し、リレーサーバ102に情報要求する前にタイムアウト値ここでは、600秒を設定する。本実施例では、MFP101のアクセス先に応じて、予めタイムアウト値が設定されているため、タイムアウト時間を簡単な処理で設定することができる。また、実施例1で示したように、アクセス先のタイムアウト時間を算出して、実施例2で示した図18に示すテーブルに、そのタイムアウト時間を追加する。例えば、クライアント装置に新たなアプリケーションがインストールされたときに、そのアプリケーションにおいてアクセスするアクセス先のタイムアウト時間を、実施例1に示したように算出する。そして、そのアクセス先と、タイムアウト時間を図18のテーブルに追加する。上記の新たにインストールされたアプリケーションにアクセスするときには、図18のテーブルを利用することができる。なお、以上の実施例では、複数のWebサーバのそれぞれがWebサービスを提供しており、Webサービスに応じてMFP101がアクセスするWebサーバによって、MFP101とリレーサーバ102の間のタイムアウト時間を設定していた。しかし、本発明は、1つのWebサーバにおいて複数のWebサービスを提供するシステムにおいても応用できるものである。その1つのサーバでは、複数のアクセス先URL等が設定されており、そのアクセス先により異なるサービスを提供する。このようなシステムにおいても、アクセス先によってデータの取得時間が異なる場合があり、即ちユーザが使用するサービスによってデータの取得時間が異なる場合がある。よって、上記の実施例を用いて、1つのサーバにおける複数のアクセス先のうち、ユーザが利用するWebサービスに対応するアクセス先に応じて、クライアント装置とリレーサーバの間のタイムアウト時間を設定してもよい。また、以上の実施例は、クライアント装置がリレーサーバを介してWebサーバからデータを取得する場合に限らず、Webサーバにデータを送信する場合においても適用できるものである。即ち、クライアント装置がリレーサーバを介してWebサーバにデータをアップロードするときの、クライアント装置とリレーサーバ間のタイムアウト時間を設定する場合であってもよい。そのように、クライアント装置からWebサーバにデータをアップロードするときにも、APIコマンド数に応じてタイムアウト時間を算出する。このときにも、アップロードするデータの種類やデータ量に応じて、APIコマンド数を算出する。さらに、以上の実施例では、クライアント装置であるMFP101がタイムアウト時間を決定する処理を行っていたが、本発明はこれに限らず、リレーサーバがこの決定処理を実行してもよい。さらに、以上の実施例では、Webサーバと通信を行うクライアント装置として、MFPを例に説明したが、クライアント装置はこれに限らず、例えばPCであってもよいし、携帯電話やデジタルカメラであってもよい。本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェアプログラムを、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータまたはCPUやMPU等がプログラムを読み出して実行する処理である。また、上記の処理を1つのプロセッサにより実行する場合に限らず、複数のプロセッサにより実行する場合であってもよい。