情報処理装置、情報処理装置の制御方法およびプログラム
【課題】複数のアクセス先のそれぞれにおいてデータの取得時間が異なることに起因するユーザの違和感を軽減することができる情報処理装置を提供する。
【解決手段】複数のアクセス先のそれぞれと情報処理装置との間の通信条件に基づき、前記情報処理装置が前記複数のアクセス先のそれぞれにデータを要求してから当該情報処理装置が当該データを取得するまでの応答時間が、当該複数のアクセス先において合うように、当該情報処理装置が当該複数のアクセス先のそれぞれにデータを要求するときの、当該データのデータ量を決定する。そして、そのデータ量に従って、当該データ量のデータを前記複数のアクセス先のそれぞれに要求する要求する。
【解決手段】複数のアクセス先のそれぞれと情報処理装置との間の通信条件に基づき、前記情報処理装置が前記複数のアクセス先のそれぞれにデータを要求してから当該情報処理装置が当該データを取得するまでの応答時間が、当該複数のアクセス先において合うように、当該情報処理装置が当該複数のアクセス先のそれぞれにデータを要求するときの、当該データのデータ量を決定する。そして、そのデータ量に従って、当該データ量のデータを前記複数のアクセス先のそれぞれに要求する要求する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サーバにデータを要求する情報処理装置、情報処理装置の制御方法およびプログラムに関する。
【背景技術】
【０００２】
Ｗｅｂサービスを提供するＷｅｂサーバから各種情報を取得して、Ｗｅｂサービスを享受することが広く行われている。特許文献１には、複数のＷｅｂアプリケーションサーバ（ＷｅｂＡＰサーバ）から構成される統合Ｗｅｂサービスシステムが記載されている。そのシステムでは、統合ＷｅｂＡＰサーバが各ＷｅｂＡＰサーバにリクエストを送信したときの応答時間を計測し、各ＷｅｂＡＰサーバの計測結果を監視サーバに通知する。そして、監視サーバは、各ＷｅｂＡＰサーバの計測結果から、処理能力が低下しているＷｅｂＡＰサーバを判定することが記載されている。そして、統合ＷｅｂＡＰサーバは、複数のＷｅｂＡＰサーバのいずれかから情報を取得しようとする場合に、上記のように処理能力が低下していると判定されたＷｅｂＡＰサーバへの接続を回避することが記載されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００６−１９５７０９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
上記のようなＷｅｂサーバを有するシステムにおいて、ユーザが指定したＷｅｂサービスによって、クライアント装置がアクセスするアクセス先が異なる場合がある。
【０００５】
上記の従来技術では、応答時間の長いＷｅｂサーバを、処理能力が低下しているものとして判定しているが、ユーザが使用するサービスによってクライアント装置がアクセスするアクセス先が異なる場合、そもそもサービスによって応答時間が異なることがある。よって、クライアント装置が類似のサービスを異なるアクセス先に要求する場合、接続先のＷｅｂサーバによって、クライアント装置がＷｅｂサーバからデータを取得して処理できるまでの時間が異なる。このことが、クライアント装置のユーザに対して違和感を与えてしまうことがある。
【０００６】
本発明は、上記の点に鑑み、アクセス先に応じて適切なデータ量のデータを要求することができる情報処理装置、その情報処理装置におけるデータ制御方法およびプログラムを提供することを目的とする。
【課題を解決するための手段】
【０００７】
上記課題を解決するため、本発明に係る情報処理装置は、サーバと通信可能な情報処理装置であって、前記情報処理装置が前記サーバからデータを取得するときの、複数のアクセス先のそれぞれと前記情報処理装置との間の通信条件を取得する取得手段と、前記取得手段が取得した前記通信条件に基づき、前記情報処理装置が前記複数のアクセス先のそれぞれにデータを要求してから当該情報処理装置が当該データを取得するまでの応答時間が、当該複数のアクセス先において合うように、当該情報処理装置が当該複数のアクセス先のそれぞれにデータを要求するときの、当該データのデータ量を決定する決定手段と、前記決定手段が決定した、前記複数のサーバのそれぞれに対応するデータ量に従って、当該データ量のデータを、前記複数のアクセス先のそれぞれに要求する要求手段と、を備えることを特徴とする。
【発明の効果】
【０００８】
本発明によれば、アクセス先に応じて適切なデータ量のデータを要求することができる。
【図面の簡単な説明】
【０００９】
【図１】Ｗｅｂサービスシステムの構成を示す図である。
【図２】ＭＦＰのハードウェア構成を示す図である。
【図３】リレーサーバのアプリケーション構成を示す図である。
【図４】各サイトで登録されているデータ構成の一例を示す図である。
【図５】アルバムリストの記述例を示す図である。
【図６】サイトごとに定義されているＡＰＩの一覧を示す図である。
【図７】ＭＦＰとリレーサーバ間のＡＰＩと、リレーサーバとサイト間のＡＰＩとの対応を示す図である。
【図８】コンディションチェックの処理の手順を示す図である。
【図９】アルバムリストを取得し、表示するまでの処理の手順を示す図である。
【図１０】印刷対象の画像を選択して印刷するまでの処理を示す図である。
【図１１】サイト１０３に対してのＡＰＩ利用回数を説明するための図である。
【図１２】サイト１０４に対してのＡＰＩの利用回数を説明するための図である。
【図１３】要求するデータ量を調整する処理の第１の例を示す図である。
【図１４】要求するデータ量を調整する処理の第２の例を示す図である。
【図１５】要求するデータ量を調整する処理の第３の例を示す図である。
【発明を実施するための形態】
【００１０】
以下、添付図面を参照して本発明の好適な実施例を詳しく説明する。尚、以下の実施例は特許請求の範囲に係る本発明を限定するものでなく、また本実施例で説明されている特徴の組み合わせの全てが本発明の解決手段に必須のものとは限らない。なお、同一の構成要素には同一の参照番号を付して、説明を省略する。
【００１１】
〔実施例１〕
［システム構成とハードウェア構成］
図１は、本発明に係るＷｅｂサービスシステムの構成を示す図である。図１に示すように、クライアント装置としてのＭＦＰ（多機能複合装置：Ｍｕｌｔｉｆｕｎｃｔｉｏｎａｌ Ｐｅｒｉｐｈｅｒａｌ）１０１は、インターネット等のネットワーク１１０を介して、Ｗｅｂサーバ１０３、１０４、１０５と接続されている。これらのサーバは、例えば写真共有サイト機能をクライアント装置に提供するサーバであり、以下、Ｗｅｂサーバ１０３、１０４、１０５をそれぞれサイト１０３、１０４、１０５ともいう。
【００１２】
またＭＦＰ１０１は、リレーサーバ１０２を介して、各Ｗｅｂサーバ１０３〜１０５とデータの送受信を行う。この構成においてリレーサーバは、各Ｗｅｂサーバとの間でそれぞれ定義されたＡＰＩを用いてデータの送受信を行っている。また、リレーサーバは、ＭＦＰとの間においてはその間で定義されたＡＰＩを用いてデータの送受信を行う。つまり、リレーサーバがＡＰＩ変換の役割を果たす。
【００１３】
この構成においては、各Ｗｅｂサーバから同じデータ量のデータを取得しようとする場合であって、Ｗｅｂサーバごとにデータの取得時間（応答時間）が異なってしまうことがある。この原因の１つに、各Ｗｅｂサーバから類似の情報を取得する場合であっても、ＷｅｂサーバごとにＡＰＩの構成が異なるという理由がある。よって、例えばＭＦＰ１０１のユーザが、同様のサービス内容の複数のＷｅｂサービス（例えば複数の写真共有サイト）を利用する場合に、Ｗｅｂサービスによって応答時間が異なることになってしまう。よって、ユーザは、同様のサービス内容であるにも拘わらず応答時間が異なるため、ＭＦＰ１０１の操作時に違和感を覚えてしまうことがある。
【００１４】
例えばクライアント装置がＷｅｂサーバから取得したデータを表示画面に表示させる場合に、仮にＷｅｂサーバ１０３の応答速度が、Ｗｅｂサーバ１０４の３倍速いとする。このとき、同じ内容の写真をダウンロードして表示する場合、Ｗｅｂサーバ１０４が画像の表示を開始するときには、Ｗｅｂサーバ１０３が表示を開始する時間の３倍の時間を要する必要になる。しかしながら、ユーザにとっては、同じ内容の画像を表示させるときの時間が異なることに違和感を覚えることがある。
【００１５】
そこで本実施例では、ＭＦＰがＷｅｂサーバと通信するときに、複数のサーバにおいて、ＭＦＰが単位時間で取得するデータ量の差が少なくなるように、ＭＦＰが一度に要求するデータ量を決定する。なお、このデータ量は、ＭＦＰがＷｅｂサーバとアクセスするときのＡＰＩの利用回数や、Ｗｅｂサーバとの通信環境に応じて決定する。詳細については後述する。
【００１６】
ここで、写真共有サイト機能とは、クライアント装置により作成された写真等の画像をサーバに格納し、複数のクライアント装置により、サーバに格納されている画像にアクセスできる機能をいう。本実施例において情報処理装置としてのＭＦＰ１０１は、リレーサーバ１０２を介してサーバ１０３〜１０５にアクセスすることで、各サイトの写真共有サイト機能を享受することができる。例えば、ＭＦＰ１０１は、リレーサーバ１０２を介してサイト１０３〜１０５から、画像が格納されている場所を示すＵＲＬ等の登録情報を取得して、そのＵＲＬに従ってサーバにアクセスすることにより、アルバムや画像の選択画面を表示することができる。特に上記のＭＦＰでは、ＰＣ等を介さずにサイトにアクセスして、アルバムや画像の選択画面を表示することができる。ユーザがその選択画面において印刷を所望する画像を選択すると、ＭＦＰ１０１は、印刷対象の画像データを各サイトから取得して印刷することができる。
【００１７】
図２は、ＭＦＰ１０１のハードウェア構成を示す図である。ＭＦＰ１０１は、操作部２０１と、カードインタフェース２０２と、読取部２０８と、記録部２０９とを有する。また、ＭＦＰ１０１は、ＣＰＵ２００と、ＲＯＭ２０３と、ＲＡＭ２０４と、不揮発性ＲＡＭ２０５と、表示部２０６と、画像処理部２１０と、圧縮／解凍部２１１と、駆動部２１２と、センサ部２１３とを有する。ＣＰＵ２００は、ＭＦＰ１０１全体を制御し、例えば操作部２０１を介して入力したユーザ操作に従ってＲＯＭ２０３に記憶されているプログラムを実行する。ＲＯＭ２０３は、ＭＦＰ１０１の制御命令プログラム等を格納する。さらに、ＭＦＰ１０１は、無線ネットワーク部２０７と有線ネットワーク部２１４とを有する。無線ネットワーク部２０７は、ＩＥＥＥ８０２．１１ａ等の規格に対応した無線ＬＡＮアクセスポイントと無線によって通信可能である。有線ネットワーク部２１４は、１００Ｂａｓｅ−ＴＸ等のより対線ケーブルを接続可能なＥｔｈｅｒｎｅｔ（登録商標）コネクタを有している。
【００１８】
図１に示すリレーサーバ１０２や各サイト１０３〜１０５には、一般的なＰＣ等の構成が用いられる。つまり、リレーサーバ１０２や各サイト１０３〜１０５は、一般的な、ＣＰＵ、ＲＯＭ、ＲＡＭ、ＨＤＤやディスプレイ等の表示部、ポインティングデバイスやキーボード等の入力部を有する。例えば、上記各装置において、ＣＰＵはハードディスクやＲＯＭ等から読み込まれたプログラムをＲＡＭに展開して実行する。ＨＤＤは、各種フローチャートに示される処理を実行するプログラムや画像データを格納する。ディスプレイは、ユーザインタフェース等を表示し、ユーザは、ポインティングデバイスやキーボード等を用いてユーザインタフェース上で操作し、各種指示を入力することができる。
【００１９】
［写真共有サイト］
リレーサーバ１０２のアプリケーション構成を説明する前に、Ｗｅｂサービスの１つである写真共有サイト機能について説明する。各サイト１０３〜１０５によりＷｅｂサービスとして提供される写真共有サイト機能は、主に、ＰＣのブラウザで閲覧されることを想定している。また、ユーザはアカウントを取得し、そのアカウントとパスワードとをセットとして登録してからＷｅｂサービスを利用する。
【００２０】
図４は、写真共有サイト機能について、各サイト１０３〜１０５で登録されているデータ構成の一例を示す図である。各サイト１０３〜１０５に登録される画像は、アルバムという単位で纏められている。例えば、図４に示すように、各サイトには、アルバムが５つ登録されている。また、アルバム１及び２には、それぞれ３つの画像が登録されている。また、アルバム３には１つの画像が登録され、アルバム４には４つの画像が登録され、アルバム５には２つの画像が登録されている。さらに、各アルバムには、そのアルバムを代表するサムネイル画像の他、アルバムのタイトルや、アルバム登録日等も含まれており、写真共有サイト機能を用いるためのブラウザ上に表示される。ユーザは、表示されたアルバムリストから１つのアルバムを選択すると、選択されたアルバムに登録された１つ以上の画像を閲覧することができる。
【００２１】
以上のような写真共有サイト機能は、ＰＣのブラウザからのみ利用可能というわけではない。例えば、公開された各サイト１０３〜１０５のＡＰＩを用いることによって、ブラウザを実装する装置以外の装置（ＭＦＰ等）からもＷｅｂサービスを利用することができる。
【００２２】
図５は、リレーサーバ１０２がＡＰＩを利用して各サイト１０３〜１０５から取得した、アルバムリストの記述例を示す図である。アルバムリストは、例えばＸＭＬで記述される。図５に示すように、タグ「＜ｔｏｔａｌ Ｒｅｓｕｌｔｓ＞」から、アルバム数が１０であることが確認できる。また、各アルバムの情報として、タグ「＜ｅｎｔｒｙ＞」ごとに、画像のＵＲＬ、サムネイル画像のＵＲＬ、ＩＤ、撮影日などが記述されている。
【００２３】
ＭＦＰ１０１は、ネットワーク通信機能によってリレーサーバ１０２のＡＰＩに対応することができる。ＭＦＰ１０１は、各サイト１０３〜１０５から情報を取得する際に、各サイト１０３〜１０５のＡＰＩに直接、情報要求を発行しない。ＭＦＰ１０１は、まず、リレーサーバ１０２との間で定義されたＡＰＩを用いてリレーサーバ１０２とＨＴＴＰのＰＯＳＴ通信を利用してリレーサーバ１０２に対して情報要求を発行する。
【００２４】
リレーサーバ１０２とＭＦＰ１０１との間でのＡＰＩは、例えば下記のように定義される。
【００２５】
・ＡＰＩ−Ｒ１（コンディションチェック）：ＭＦＰ１０１の仕向け情報及びインターネット上のＩＰアドレスによって各サイトに接続可能かを確認する際に用いられる。
【００２６】
・ＡＰＩ−Ｒ２（ログイン認証）：各サイトとの認証が可能かを判定する際に用いられる。
【００２７】
・ＡＰＩ−Ｒ３（アルバムリスト要求）：全アルバムのリストを取得する際に用いられる。
【００２８】
・ＡＰＩ−Ｒ４（画像リスト要求）：アルバムに登録されている全画像のリストを取得する際に用いられる。
【００２９】
ＭＦＰ１０１は、ユーザが指定したサイトに情報要求（実際は、上記のようにリレーサーバ１０２に対して情報要求を発行）することにより、当該情報要求に応じたアルバムリストや画像リストをリレーサーバ１０２から受信する。ＭＦＰ１０１は、受信したリストの該当部分から表示用のデータのＵＲＬを取得することができる。ＭＦＰ１０１は、認証及び上記リストの取得についてはリレーサーバ１０２を介して行うが、画像データ等のＵＲＬを取得した後は、各サイトから直接受信することができる。
【００３０】
［リレーサーバ］
リレーサーバ１０２は、ＭＦＰ１０１が各サイト１０３〜１０５から情報を取得する場合に、ＡＰＩ変換機能を用いて仲介する役割を果たす。リレーサーバ１０２は、ＭＦＰ１０１との関係においてＷｅｂサーバとして機能し、各サイト１０３〜１０５との関係においては、Ｗｅｂクライアントとして機能する。
【００３１】
図３は、リレーサーバ１０２のアプリケーション構成を示す図である。本実施例において、リレーサーバ１０２の主な機能はＡＰＩ変換機能である。リレーサーバ１０２は、ＭＦＰ１０１との間で「ＭＦＰ−ＡＰＩ」を定義している。リレーサーバ１０２は、ＭＦＰ１０１との間で定義されたＡＰＩ構成を、接続先の各サイト１０３〜１０５との間で定義されたＡＰＩ構成（「サイトＡ−ＡＰＩ」、「サイトＢ−ＡＰＩ」、「サイトＣ−ＡＰＩ」）にＡＰＩ変換する。
【００３２】
図６は、サイトごとに定義されているＡＰＩの一覧を示す図である。ＭＦＰ１０１が各サイトから情報を取得するためには、リレーサーバ１０２が、各サイトとの間で定義されたＡＰＩ構成を用いる必要がある。つまり、ＭＦＰ１０１が同じ情報を各サイトから取得する場合であっても、リレーサーバ１０２と各サイトとの間で定義されるＡＰＩの構成は異なる。
【００３３】
図７は、ＭＦＰ１０１とリレーサーバ１０２との間で定義されるＡＰＩ（ＡＰＩ-Ｒとする）と、リレーサーバ１０２と各サイトとの間で定義されるＡＰＩとの対応を示す図である。この図７により、サイトからデータを取得するために必要なＡＰＩの数は、ＭＦＰが要求するデータの種類によって異なり、また同じデータの種類であっても、接続先のサイトによっても異なることがわかる。例えば、アルバムリスト要求ＡＰＩ−Ｒ３を用いてＭＦＰ１０１があるサイトを指定して情報要求する場合に、ユーザが指定したサイトによってリレーサーバ１０２から発行するＡＰＩの種類と発行数が異なることが分かる。詳細については、後述する。
【００３４】
図３を参照して、リレーサーバ１０２の各機能を説明する。リレーサーバ１０２は、以下のような機能を有している。なお、リレーサーバ１０２では、この各機能に対応するプログラムがＲＯＭに記憶されており、リレーサーバ１０２のＣＰＵが、このＲＯＭに記憶されているプログラムを実行することにより、図３に示す各機能を実現できるものとする。
【００３５】
・パーサ機能：図５で示すような各サイトからのＸＭＬリストをパーサにより解釈する。
【００３６】
・フィルタ機能：各サイトから受信したデータのうち、ＭＦＰ１０１に送信する情報以外のデータを削除する。例えば、有効期限の切れたコンテンツや、指定以外のファイルタイプや、上限以上のファイルサイズの画像データ等を削除する。
【００３７】
・チェック機能：ＭＦＰ１０１からのコンディションチェック要求に応じて、ＭＦＰ１０１のＩＰアドレス及びＭＦＰ１０１から送信される情報に基づき、各サイトに接続可能かをチェックする。
【００３８】
・ＡＰＩ判定機能：各サイトごとのＡＰＩ利用回数を比較する。例えば、ＭＦＰ１０１から情報要求された場合に、その情報を取得するために必要なＡＰＩ利用回数を各サイトについて比較する。なお、本実施例では、このＡＰＩ判定機能によるＡＰＩ利用回数に基づいて、ＭＦＰ１０１がＷｅｂサーバに一度に要求するデータ量を決定する。
【００３９】
・制御機能：ＭＦＰ１０１の仕向け情報に基づき、指定するサイトを振り分ける。
【００４０】
本実施例においては、ＭＦＰ１０１が各サイトへの情報要求量（ＭＦＰ１０１がＷｅｂサーバに対して要求するデータのデータ量）を調整することにより、各サイトから情報を取得するまでの応答時間を基準時間に近づけ、その結果、各サイト間での応答時間の差を低減する。以下、その処理について説明する。ＭＦＰ１０１は、まず、コンディションチェックを実行して接続可能なサイトを判定する。
【００４１】
［コンディションチェック］
図８は、コンディションチェックの処理の手順を示す図である。コンディションチェックは、リレーサーバ１０２と指定される各サイトとの通信状況を判定するための処理である。ＭＦＰ１０１は、リレーサーバ１０２にコンディションチェックを要求する（Ｓ８０１）。リレーサーバ１０２がＭＦＰ１０１からの要求を受信すると、ＭＦＰ１０１のＩＰアドレスに基づいて、そのＭＦＰ１０１が接続可能なサイトを特定する（Ｓ８０２）。リレーサーバ１０２は、その特定したサイトとともに、ＡＰＩ判定機能による判定結果をＭＦＰ１０１に返信する（Ｓ８０３）。ＡＰＩ判定機能による判定結果については後述する。また、リレーサーバ１０２は、コンディションチェックの要求を受信すると、テスト用のパケット等に基づき各サイトからの応答時間を確認して、ＭＦＰ１０１に返信する。例えば、実測応答時間が２３０ｍｓｅｃである場合には、その値「Ｍ」をＭＦＰ１０１に返信する。ＭＦＰ１０１は、その値Ｍを各サイトとの通信環境の判定値として自装置内に保存する。以下、接続候補になるサイトがサイト１０３〜１０５の３つあり、そのうちサイト１０３とサイト１０４が接続可能と判定されたとして説明する。
【００４２】
［ＭＦＰからのアルバムリスト／画像リスト要求例］
ＭＦＰ１０１が各サイトから画像を受信して印刷するまでの概要は以下のようである。まず、ＭＦＰ１０１は、利用可能なサイト１０３及び１０４のうち１つを選択し、そのサイト内の個人用のアルバムにアクセスするためのアカウント及びパスワードを用いて、認証確認のためのＡＰＩ−Ｒ２をリレーサーバ１０２に発行する。その後、ＭＦＰ１０１は、アルバムリストをサイトからリレーサーバ１０２経由で取得し、ユーザは、ＭＦＰ１０１上で所望するアルバムを選択する。そして、ＭＦＰ１０１は、所望のアルバムに登録されている画像リストをリレーサーバ１０２経由で取得し、ユーザは、ＭＦＰ１０１上で所望する画像を選択する。ＭＦＰ１０１は、選択された画像をサイトから受信して印刷を行う。
【００４３】
上記の処理の流れについて、図９及び図１０を参照して説明する。図９は、アルバムリストを取得して表示するまでの処理の手順を示す図である。ＭＦＰ１０１は、アルバムリスト要求をＡＰＩ−Ｒ３を用いてリレーサーバ１０２に発行する（Ｓ９０１）。リレーサーバ１０２は、その要求を解析してＡＰＩ変換機能によって要求先のサイトに応じたＡＰＩ要求を発行する（Ｓ９０２）。要求先のサイトは、その要求に応じて、アルバムリストをリレーサーバ１０２に対して返信する（Ｓ９０３）。Ｓ９０２及びＳ９０３において用いられるＡＰＩの構成は、各サイトにより異なる。リレーサーバ１０２は、例えば図５に示すような記述形式でアルバムリストを受信する。リレーサーバ１０２は、ＸＭＬをパースしてアルバムリストをＭＦＰ１０１に返信する（Ｓ９０４）。
【００４４】
ＭＦＰ１０１は、受信したアルバムリストに基づき、サイトに対して直接、ＨＴＴＰのＧｅｔ要求を発行する（Ｓ９０５）。そして、ＭＦＰ１０１は、そのサイトからサムネイル画像を受信して（Ｓ９０６）、アルバムの選択画面をＭＦＰ１０１の表示画面に表示する。ユーザは、表示されたアルバムの選択画面から、所望のアルバムを選択する（Ｓ９０７）。若しくは、ユーザがアルバムの選択対象を切り替える度に、Ｓ９０５及びＳ９０６の処理が行われても良い。
【００４５】
図１０は、図９に示す処理の後、印刷対象の画像を特定して印刷するまでの処理を示す図である。ＭＦＰ１０１は、アルバム画像を要求するために、ＡＰＩ−Ｒ４をリレーサーバ１０２に発行する（Ｓ１００１）。リレーサーバ１０２は、その要求を解析してＡＰＩ変換機能によって要求先のサイトに応じたＡＰＩ構成に変換し、その変換されたＡＰＩを要求先のサイトに発行する（Ｓ１００２）。サイトは、その要求に応じて、指定されたアルバム中の画像の画像リストをリレーサーバ１０２に対して返信する（Ｓ１００３）。Ｓ１００２及びＳ１００３において用いられるＡＰＩの構成は各サイトにより異なる。リレーサーバ１０２は、例えば図５に示すような記述形式で画像リストを受信する。リレーサーバ１０２は、ＸＭＬをパースして画像リストをＭＦＰ１０１に返信する（Ｓ１００４）。
【００４６】
ＭＦＰ１０１は、受信した画像リストからサムネイル画像のＵＲＬ情報等を取得し、サイトに対して直接、ＨＴＴＰのＧｅｔ要求を発行する（Ｓ１００５）。そして、ＭＦＰ１０１は、そのサイトからサムネイル画像を受信して（Ｓ１００６）、画像の選択画面をＭＦＰ１０１の表示画面に表示する。ユーザは、表示された画像の選択画面から所望の画像を選択する（Ｓ１００７）。若しくは、ユーザが画像の選択対象を切り替える度に、Ｓ１００５及びＳ１００６の処理が行われても良い。ユーザにより所望の画像が選択されて印刷が指示されると、ＭＦＰ１０１は、印刷対象の画像データを取得するために、サイトに対して直接、ＨＴＴＰのＧｅｔ要求を発行し（Ｓ１００８）、サイトから印刷対象の画像データを受信する（Ｓ１００９）。ＭＦＰ１０１は、受信した印刷対象の画像データを展開して記録媒体に印刷する（Ｓ１０１０）。
【００４７】
［各サイトについてのＡＰＩ構成］
上記の一連の処理において、アルバムリストや画像リスト取得のためにリレーサーバ１０２から各サイトに対して発行するＡＰＩの利用回数（発行されるＡＰＩコマンド数）が異なる。また、その相違に伴い、ＭＦＰ１０１がサイトに情報を要求して取得するまでの応答時間も、各サイトによって異なる。以下、例を挙げて説明する。
【００４８】
図１１は、アルバムリストの要求をサイト１０３に対して発行した場合に、サイト１０３に対してリレーサーバ１０２が発行するＡＰＩの利用回数を説明するための図である。リレーサーバ１０２は、サイト１０３に対して認証のためのＡＰＩ−Ａ１を発行し（Ｓ１１０１）、次に、アルバムリストの取得のためのＡＰＩ−Ａ２を発行する（Ｓ１１０２）。つまり、リレーサーバ１０２は、アルバムリスト取得までサイト１０３に対して、ＡＰＩを２回発行する。
【００４９】
図１２は、アルバムリストの要求をサイト１０４に対して発行した場合に、サイト１０４に対してリレーサーバ１０２が発行するＡＰＩの利用回数を説明するための図である。リレーサーバ１０２は、サイト１０４に対して認証を開始する条件確認のためのＡＰＩ−Ｂ１、ＡＰＩ−Ｂ２、ＡＰＩ−Ｂ３を発行する（Ｓ１２０１〜Ｓ１２０３）。その後、リレーサーバ１０２は、認証のためのＡＰＩ−Ｂ４を発行する（Ｓ１２０４）。リレーサーバ１０２は、認証成功後、アルバムリスト取得のためのＡＰＩ−Ｂ５を発行する（Ｓ１２０５）。さらに、リレーサーバ１０２は、サイト１０４に対して、アルバムリストに含まれる各アルバムごとに、タイトルや撮影日等の情報取得のためのＡＰＩ−Ｂ６を発行する（Ｓ１２０６）。さらに、リレーサーバ１０２は、各アルバムごとに、アルバムに設定されている代表画像としてのサムネイル画像のＵＲＬ等の情報を取得するためのＡＰＩ−Ｂ７を発行する（Ｓ１２０７）。例えば、図４に示すように、アルバムが５つ設定されている場合には、Ｓ１２０６及びＳ１２０７において各５回ＡＰＩを利用するので、リレーサーバ１０２は、計１５回のＡＰＩ要求をサイト１０４に対して発行することになる。
【００５０】
図１１に示す手順によって、ＭＦＰ１０１が図４に示すアルバムリストを要求してからリレーサーバ１０２からアルバムリストを受信するまでの応答時間は１秒程度であった。一方で、図１２に示す手順によって、ＭＦＰ１０１が図４に示すアルバムリストを要求してからリレーサーバ１０２からアルバムリストを受信するまでの応答時間は１０秒程度であった。
【００５１】
このように、ユーザは、同じアルバムリストを異なるサイトから取得する場合に、各サイトに対して発行されるＡＰＩの構成が異なるので、応答時間に差が生じてしまう。そして、そのことがユーザに対して操作上の違和感を与えてしまう。本実施例においては、上述のＡＰＩの構成やコンディションチェック時の各サイトへの通信時間等の通信条件に応じて、各サイトへの情報要求量を基準となる応答時間となるように調整する。そのような構成によって、各サイト間での応答時間の差を低減する。
【００５２】
［データ制御方法］
ＭＦＰ１０１は、まず、少なくとも以前に１つのＷｅｂサービスを利用して、応答時間の基準値（基準時間ともいう）が設定されたか否かを判定する。この基準値は、ＭＦＰがＷｅｂサーバに要求するデータ量を補正するか否かを判定するための値である。ここで、まだ、基準値が設定されていないと判定された場合には、図１３に示す処理が実行され、基準値が既に設定されていると判定された場合には、図１４に示す処理が実行される。図１３及び図１４に示す処理は、例えば、ＭＦＰ１０１のＣＰＵ２００により実行される。
【００５３】
最初に、図１３を説明する。ＣＰＵ２００は、まず上記の基準値として、ユーザが待ち時間として違和感を与えないとされる基準時間Ｔ（例えば、２秒等）を設定する（Ｓ１３０１）。次に、ＣＰＵ２００は、図８のＳ８０３において自装置に保存された実測応答時間の値Ｍを読み出して閾値との比率を算出することで、通信状況の判定を行う（Ｓ１３０２）。なお、この値Ｍは、上記のように、Ｗｅｂサーバのコンディションチェックの際に応答時間判定を行うことにより、取得することができる。このとき、例えば、Ｍ＝１６０ｍｓｅｃであり、比較値が２００ｍｓｅｃの場合には、その比率は０．８となる。この比率が大きいほど、通信状況が良好であり、サイトとの通信に必要な時間が短くて済むことになる。この比率より、各サイトとの通信に必要な時間を評価することができる。以下、その０．８を通信環境の判定値として用いる。次に、ＣＰＵ２００は、図８のＳ８０３においてリレーサーバ１０２から受信したＡＰＩ判定機能の判定結果を参照する（Ｓ１３０３）。
【００５４】
ここで、図１１及び図１２を参照しながら、ＡＰＩ判定機能の判定結果について説明する。例えば、サイト１０３については、図１１に示すように、アルバムリスト取得までにＡＰＩを２回利用している。また、サイト１０４については、アルバムリスト取得までにＡＰＩを１５回利用している。また、サイト１０５については、例えば、図６に示すようにＡＰＩが用いられるとすると、アルバムリスト取得までにＡＰＩを１回利用する。本実施例においては、アルバムリスト取得までの、複数のＷｅｂサーバにおける最低のＡＰＩ利用回数を基準として、各利用回数の比率を判定結果としている。このとき、サイト１０４におけるＡＰＩ利用回数「１」が最低の利用回数となり、サイト１０３のＡＰＩ利用回数が図１１の説明から２回、サイト１０４のＡＰＩ利用回数が図１２の説明から１５回であることがわかる。よって、ＡＰＩ利用回数の比率は、サイト１０３については２／１＝２となり、サイト１０４については１５／１＝１５となり、サイト１０５については１／１＝１となる。即ち、ＭＦＰにより利用される複数のサイトのそれぞれの、ＡＰＩの利用回数の比率により、ＡＰＩ利用状況を複数のサイトにおいて相対的に評価する。この比率が高いほど、データを取得するために必要なＡＰＩの数が多く、データを取得するために必要な時間が長くなると判断することができる。なお、ＡＰＩ判定機能の判定結果として、上記のような比率の他に、各ＡＰＩの処理時間や処理内容を考慮した値が用いられても良い。
【００５５】
次に、ＣＰＵ２００は、Ｓ１３０２、Ｓ１３０３において判定された通信状況、ＡＰＩの使用状況においてＭＦＰがＷｅｂサーバに要求する情報量を評価する為に、所定の情報要求量を設定する（Ｓ１３０４）。本実施例においては、例えばアルバム情報要求量が「１０００」とすると、その「１０００」に対して、Ｓ１３０２において算出された比率とＳ１３０３において算出されたＡＰＩ判定結果とを反映して、新たな情報要求量を決定する。
【００５６】
例えば、Ｓ１３０２において算出された応答時間の比率とＳ１３０３において算出されたＡＰＩ利用回数の比率とを用いて（所定の情報要求量／応答時間の比率）／ＡＰＩ利用回数の比率（式１）を、新たな情報要求量として算出する。上記の例では、応答時間の比率が「０．８」、ＡＰＩ利用回数の比率が「２」（サイト１０３の場合）であるため、（１０００／０．８）／２＝６２５を新たな情報要求量として設定する。
【００５７】
本実施例においては、各サイトへの情報要求量を、各サイトとの通信状況と、各サイトとリレーサーバとの間のＡＰＩ構成とを考慮して調整する。つまり、式１に示すように、リレーサーバ１０２とサイトとのコンディションチェックの結果が良くない程（通信時間がかかる程）、若しくは、接続先サイトに対して用いられるＡＰＩ構成が複雑になる程（ＡＰＩ利用回数が多い程）、ＭＦＰがＷｅｂサーバに一度に要求する情報要求量を少なくする。そのように調整することによって、接続先サイトからの情報の応答時間を基準時間に近づけることができる。式１においては、Ｓ１３０１における基準時間Ｔは考慮されていないが、Ｗｅｂサーバからの応答時間が、おおよそＳ１３０１で取得した基準時間Ｔとなるであろう情報要求量を算出することができる。Ｓ１３０７において、予想応答時間と実際の実応答時間との差に基づき、その情報要求量を、上記の算出した情報要求量に補正して次回以降の情報要求量とする。詳細については後述する。
【００５８】
次に、ＣＰＵ２００は、Ｓ１３０５において、サイト１０３に対する「６２５」分のアルバム情報要求を、リレーサーバ１０２に発行する。Ｓ１３０６において、ＣＰＵ２００は、アルバム情報要求量「６２５」を要求してから取得するまでの実応答時間を取得する。そして、ＣＰＵ２００は、Ｓ１３０６において取得した実応答時間を、Ｓ１３０１において設定された基準時間Ｔと比較する。ここで、実応答時間が基準時間Ｔより小さい場合には、基準時間Ｔをその実応答時間により更新する（Ｓ１３０９）。例えば、上記のように情報量「６２５」を要求したが、実際にＷｅｂサーバに登録されていたデータ量が、要求されたデータ量よりも少ない場合に、取得時間が基準時間よりも少なくなる。その際に、実際に受信したアルバム情報量（例えば、「６２５」分を要求したが実際に受信したのは「５００」分であった場合）もあわせて保存する。この保存された「５００」が、Ｓ１３０９において更新された基準時間Ｔに対する新たな情報要求量となる。この新たな情報要求量に基づく処理については、図１４を用いて後述する。
【００５９】
一方、Ｓ１３０６における実応答時間が基準時間Ｔ以上の場合には、ユーザの待ち時間としてはまだ不適当であるので、Ｓ１３０８において情報要求量を補正する。例えば、実応答時間が基準時間Ｔの１．２倍である場合には、Ｓ１３０４で設定した要求量「６２５」を１．２で除した値「５２１」を、次回の情報要求量として、ＲＯＭ２０３、不揮発性ＲＡＭ２０５等のメモリに記憶する。そして、次回の情報要求の際にＭＦＰは、メモリに記憶されている情報要求量（データ量「５２１」）のデータをＷｅｂサーバに要求することで、基準時間Ｔよりも短い時間でデータを取得することができる。
【００６０】
以降、ＣＰＵ２００は、図９のＳ９０５〜Ｓ９０７のように、受信したアルバム情報に基づき、サムネイル画像を各サイトから受信し、ユーザにアルバム選択画面を表示する処理を行う（Ｓ１３１０）。
【００６１】
この図１３に示したように、Ｓ１３０２において算出された応答時間の比率とＳ１３０３において算出されたＡＰＩ利用回数の比率とを用いて、Ｓ１３０４で情報要求量を算出する。そして、Ｓ１３０５〜Ｓ１３０７で、Ｓ１３０４で算出された情報要求量のデータを、実際にＷｅｂサーバに要求し、そのときの取得時間を、基準時間Ｔにより評価する。そして、Ｓ１３０７でデータの取得時間が基準時間Ｔ以上であった場合に、クライアント装置によりＷｅｂサーバに一度に要求する情報量を調整することで、データを要求してから基準時間Ｔよりも短い時間で、データを取得することができる。
【００６２】
また、上記の図７に示すように、クライアント装置がデータを要求するＷｅｂサーバや、またＷｅｂサーバに要求するデータの種類によって、データの取得に必要なＡＰＩの数は異なる。よって、上記のように情報要求量をメモリに記憶するときに、Ｗｅｂサーバの種類や、データの種類に対応させて、情報要求量を記憶しておいてもよい。そして、データ要求の際には、そのデータ要求を行うＷｅｂサーバ、またデータの種類に応じた情報要求量に従って、データを要求する。
【００６３】
次に、図１３において基準時間Ｔが更新された後に、Ｗｅｂサーバ１０３とは異なるＷｅｂサーバ（Ｗｅｂサーバ１０４）に、ＭＦＰが情報を要求する処理について、図１４を用いて説明する。図１４は、図１３に示す処理に従って、新たな基準時間Ｔ’に更新したときに、新たな情報要求量を決定する処理について説明するためのフローチャートである。例えば図１３のＳ１３０６においてサイト１０３から「５００」分のアルバム情報を取得して、基準時間Ｔ’が決定された後に、サイト１０４に対して同じ情報要求量「５００」分のアルバム情報を要求する場合を示す。
【００６４】
ＣＰＵ２００は、まず、基準時間Ｔ’が設定されていることを確認する（Ｓ１４０１）。このときの基準時間Ｔ’とは、例えば、図１３のＳ１３０９において更新された基準時間Ｔや、図１３で基準時間の更新が行われなければ、Ｓ１３０１で取得した基準時間Ｔである。Ｓ１４０２及びＳ１４０３における処理は、Ｓ１３０２及びＳ１３０３における説明と同じである。ただし、本図においては、サイト１０４を接続先としたときの通信環境の判定値（応答時間の比率）を「１．０」として、またＡＰＩ使用回数は図１２の説明から「１５」である。
【００６５】
次に、ＣＰＵ２００は、情報要求量を設定する（Ｓ１４０４）。本図においては、情報要求量「５００」に対して、Ｓ１４０２において算出された比率とＳ１４０３において算出されたＡＰＩ判定結果とを反映して、新たな情報要求量を決定する。例えば、Ｓ１４０２において算出された「１．０」と、Ｓ１４０３において算出されたＡＰＩ判定結果「７．５」とを用いて、（５００／１．０）／７．５＝６７を算出する。なお、ＡＰＩ判定結果「７．５」は、Ｗｅｂサーバ１０４の場合のＡＰＩ使用回数「１５」、Ｗｅｂサーバ１０３の場合のＡＰＩ使用回数「２」の比率（１５／２）＝７．５により求めることができる。Ｓ１４０５において、ＣＰＵ２００は、サイト１０４に対する「６７」分のアルバム情報要求をリレーサーバ１０２に発行する。Ｓ１４０６において、ＣＰＵ２００は、アルバム情報要求量「６７」を要求してから取得するまでの実応答時間を取得する。
【００６６】
次に、ＣＰＵ２００は、Ｓ１４０６において取得した実応答時間が基準時間Ｔ’と比べて±２０％の範囲内に入っているか否かを判定する。ここで、その範囲内に入っていると判定された場合には、Ｓ１４０９に進む。Ｓ１４０９における処理は、Ｓ１３１０における説明と同じである。Ｓ１４０７においてＳ１４０９に進む判定とは、Ｓ１４０４において求めた情報要求量「６７」をサイト１０４に対して要求した場合に、おおよそ応答時間Ｔ’でその情報量のデータを取得することを意味する。即ち、サイト１０４に対してデータを要求した場合に、その応答時間が、サイト１０３にデータを要求したときとほぼ差がないということである。
【００６７】
一方、Ｓ１４０７において、±２０％の範囲内に入っていないと判定された場合には、Ｓ１４０８において、Ｓ１３０８と同様に要求量の補正を行い、Ｓ１４０４から繰り返す。これにより、情報要求量を、応答時間がＴ’となるように調整することができる。
【００６８】
以上の図１４に示す処理によって、ＭＦＰ１０１が接続するサイトを変更した場合においても、変更前の接続先のＷｅｂサーバの応答時間と同程度の応答時間で、変更後の接続先のＷｅｂサーバからデータを取得することができる。即ち、接続先のＷｅｂサーバの変更後も、変更前のＷｅｂサーバの応答時間に対して所定の範囲内に収まる誤差の応答時間で、データを取得できる情報要求量を決定することができる。
【００６９】
また、上記のように、Ｓ１４０８、Ｓ１４０４〜Ｓ１４０６において、ＭＦＰ１０１からのリレーサーバ１０２へ、情報要求量の補正、データの再要求、データの再取得が行われる。この再情報要求発行から再取得までの時間（Ｓ１４０８−Ｓ１４０４−Ｓ１４０６）がユーザへの違和感を生じさせる上で無視できない場合もある。そのような場合には、Ｓ１３０８と同様に補正後の情報要求量（例えば、「６０」）を次回の要求量と決定するとともに、最初にＳ１４０６で取得した「６７」分のアルバム情報に基づいてＭＦＰ１０１の表示画面に表示するように表示制御しても良い。即ち、更新された情報要求量「６０」によりデータが再取得されるのを待って、その再取得されたデータを表示させるのではなく、初めに情報要求量「６７」により取得された、情報量「６７」のデータを表示させる。これにより、ユーザは情報要求量が決定されるのを待たなくても、既に取得されているデータを確認することができる。また、図１３及び図１４においては、アルバム情報取得時について説明したが、アルバム中の画像リスト取得時に対しても適用することができる。
【００７０】
以上の実施例によれば、クライアント装置としてＭＦＰが、Ｗｅｂサーバ１０３からデータを取得する場合と、Ｗｅｂサーバ１０４からデータを取得する場合とにおいて、クライアント装置によるデータ要求に対して、データが取得されるまでの取得時間が、おおよそ基準時間Ｔとなるように、情報要求量が設定される。
【００７１】
よって、クライアント装置は、おおよそ基準時間Ｔ毎にデータを取得して、取得されたデータを処理することができる。例えばクライアント装置がＷｅｂサーバ１０３、１０４のそれぞれから取得したデータを表示画面に表示させる場合、共に、基準時間Ｔごとに新たなデータが表示することができる。
【００７２】
よって、クライアント装置がアクセスするＷｅｂサーバによって取得時間が異なることに起因して、ユーザに違和感を与えてしまうことを防ぐことができる。なお、以上の実施例では、Ｗｅｂサーバ１０３、１０４の情報要求量を、データの取得時間が基準時間Ｔになるように設定することで、Ｗｅｂサーバ１０３、１０４のデータの取得時間を合わせていた。
【００７３】
しかし本発明は、これに限らず、例えばＷｅｂサーバ１０３を基準にして、所定のデータ量のデータをＷｅｂサーバ１０３に要求したときの取得時間に、Ｗｅｂサーバ１０４のデータの取得時間が合うように、Ｗｅｂサーバ１０４に対する情報要求量を決定してもよい。例えば、Ｗｅｂサーバ１０３に実際に所定のデータ量のデータを要求し、そのデータを取得するまでの時間を計測する。そして、そのデータと同種のデータをＷｅｂサーバ１０４に要求したときに、データの取得時間が、上記のＷｅｂサーバ１０３の計測時間に合うように、Ｗｅｂサーバ１０４の情報要求量を決定する。この方法によっても、Ｗｅｂサーバ１０３、１０４において、データの取得時間を合わせることができる。
【００７４】
〔実施例２〕
本実施例においては、クライアント装置によりＷｅｂサーバにデータを要求するときに、データの取得時間がユーザに違和感を与えない範囲でＭＦＰの一度の要求で多くのデータを取得できるように、最低限の情報要求量から順次増加することで、情報要求量を設定する処理を行う。
【００７５】
図１５に示すＳ１５０１〜Ｓ１５０３については、図１３のＳ１３０１〜Ｓ１３０３の説明と同じである。本実施例においては、Ｓ１５０４において、ＣＰＵ２００は、最低限必要な情報要求量を設定する。例えば、ＭＦＰ１０１でサムネイル画像を一時に９画面表示可能な場合には、情報要求量を「９」として設定する。Ｓ１５０５〜Ｓ１５０７は、図１４のＳ１４０５〜Ｓ１４０７と同じである。
【００７６】
Ｓ１５０７では、Ｓ１５０６で情報を取得したときの取得時間が、基準時間Ｔの―２０％以内か判定する。なお、Ｓ１５０６では、データの取得時間が基準時間Ｔよりも十分小さくなるように、情報要求量を設定しており、Ｓ１５０５ではその情報要求量のデータを要求するようにする。
【００７７】
Ｓ１５０７において、取得時間が基準時間Ｔの―２０％以内と判定された場合には、データの取得時間が基準時間Ｔよりも短いためユーザに違和感を与えるものではなく、また情報要求量が十分大きいと判定する。Ｓ１５１０において、図９のＳ９０５〜Ｓ９０７のように、取得したアルバム情報に基づき、サムネイル画像を各サイトに要求し、ユーザにアルバム選択画面を表示する処理を行う。一方、−２０％の範囲内に入っていないと判定された場合には、情報要求量を予め定められた分増加して（Ｓ１５０８）、次回における情報要求量とする（Ｓ１５０９）。そして、今回のＳ１５０６において取得したアルバム情報に基づき、サムネイル画像を各サイトに要求し、ユーザにアルバム選択画面を表示する処理を行う。
【００７８】
なお、上記の説明では、Ｓ１５０６において、データの取得時間が基準時間Ｔよりも十分短くなるように設定していたがこれに限らない。例えば、Ｓ１５０７の判定の前に、上述したＳ１３０７、Ｓ１４０７のように、取得時間が基準時間Ｔより短いか判定して、取得時間が短い場合に、Ｓ１５０７において「取得時間が基準時間の―２０％以内か？」を判定してもよい。 一方、取得時間が基準時間Ｔ以上であった場合には、上述したＳ１３０８、Ｓ１４０８のように、取得時間が短くなるように補正計算を行う。
【００７９】
つまり、本実施例においては、ＭＦＰ１０１の表示上、最低限必要な情報要求量を要求し、その取得時間が基準時間より大幅に下回る場合には、基準時間から予め定められた範囲内に収まるまで、要求量を順次増加させていく。
【００８０】
これにより、データの取得時間がユーザに違和感を与えない範囲で、ＭＦＰによる一度の要求で多くのデータを取得できるように、情報要求量を設定することができる。
【００８１】
以上の実施例によれば、クライアント装置が複数のＷｅｂサーバのそれぞれからデータを取得するときに、クライアント装置によるデータ要求に対するＷｅｂサーバからの応答時間（データの取得時間）が、複数のＷｅｂサーバにおいて同じになるように、情報要求量を決定することができる。
【００８２】
これにより、複数のＷｅｂサーバにおいて、同一のデータ量のデータ要求に対する応答時間が異なる場合であっても、同じ応答時間でデータを取得することができる。よって、Ｗｅｂサーバにデータを要求して、データを取得し、処理を開始するまでの時間を、上記の複数のＷｅｂサーバのそれぞれにおいて統一することができる。よって、複数のＷｅｂサーバのそれぞれにおいて応答時間が異なることに起因するユーザの違和感を軽減することができる。
【００８３】
なお、以上の実施例では、複数のＷｅｂサーバのそれぞれがＷｅｂサービスを提供しており、複数のＷｅｂサーバにおいてデータの取得時間を合わせるように、Ｗｅｂサーバごとに情報要求量を決定していた。
【００８４】
しかし、本発明は、１つのＷｅｂサーバにおいて複数のＷｅｂサービスを提供するシステムにおいても応用できるものである。その１つのサーバでは、複数のアクセス先（ＵＲＬ等）が設定されており、そのアクセス先により異なるサービスを提供する。このようなシステムにおいても、アクセス先によってデータの取得時間が異なる場合があり、即ちユーザが使用するサービスによってデータの取得時間が異なる場合がある。よって、上記の実施例を用いて、１つのサーバにおける複数のアクセス先のそれぞれにおいてデータの取得時間が合うように、アクセス先のそれぞれに応じた情報要求量を決定してもよい。
【００８５】
また、以上の実施例では、Ｗｅｂサーバと通信を行うクライアント装置として、ＭＦＰを例に説明したが、クライアント装置はこれに限らず、例えばＰＣであってもよいし、携帯電話やデジタルカメラであってもよい。
【００８６】
本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。また、上記の処理を１つのプロセッサにより実行する場合に限らず、複数のプロセッサにより実行する場合であってもよい。
【技術分野】
【０００１】
本発明は、サーバにデータを要求する情報処理装置、情報処理装置の制御方法およびプログラムに関する。
【背景技術】
【０００２】
Ｗｅｂサービスを提供するＷｅｂサーバから各種情報を取得して、Ｗｅｂサービスを享受することが広く行われている。特許文献１には、複数のＷｅｂアプリケーションサーバ（ＷｅｂＡＰサーバ）から構成される統合Ｗｅｂサービスシステムが記載されている。そのシステムでは、統合ＷｅｂＡＰサーバが各ＷｅｂＡＰサーバにリクエストを送信したときの応答時間を計測し、各ＷｅｂＡＰサーバの計測結果を監視サーバに通知する。そして、監視サーバは、各ＷｅｂＡＰサーバの計測結果から、処理能力が低下しているＷｅｂＡＰサーバを判定することが記載されている。そして、統合ＷｅｂＡＰサーバは、複数のＷｅｂＡＰサーバのいずれかから情報を取得しようとする場合に、上記のように処理能力が低下していると判定されたＷｅｂＡＰサーバへの接続を回避することが記載されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００６−１９５７０９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
上記のようなＷｅｂサーバを有するシステムにおいて、ユーザが指定したＷｅｂサービスによって、クライアント装置がアクセスするアクセス先が異なる場合がある。
【０００５】
上記の従来技術では、応答時間の長いＷｅｂサーバを、処理能力が低下しているものとして判定しているが、ユーザが使用するサービスによってクライアント装置がアクセスするアクセス先が異なる場合、そもそもサービスによって応答時間が異なることがある。よって、クライアント装置が類似のサービスを異なるアクセス先に要求する場合、接続先のＷｅｂサーバによって、クライアント装置がＷｅｂサーバからデータを取得して処理できるまでの時間が異なる。このことが、クライアント装置のユーザに対して違和感を与えてしまうことがある。
【０００６】
本発明は、上記の点に鑑み、アクセス先に応じて適切なデータ量のデータを要求することができる情報処理装置、その情報処理装置におけるデータ制御方法およびプログラムを提供することを目的とする。
【課題を解決するための手段】
【０００７】
上記課題を解決するため、本発明に係る情報処理装置は、サーバと通信可能な情報処理装置であって、前記情報処理装置が前記サーバからデータを取得するときの、複数のアクセス先のそれぞれと前記情報処理装置との間の通信条件を取得する取得手段と、前記取得手段が取得した前記通信条件に基づき、前記情報処理装置が前記複数のアクセス先のそれぞれにデータを要求してから当該情報処理装置が当該データを取得するまでの応答時間が、当該複数のアクセス先において合うように、当該情報処理装置が当該複数のアクセス先のそれぞれにデータを要求するときの、当該データのデータ量を決定する決定手段と、前記決定手段が決定した、前記複数のサーバのそれぞれに対応するデータ量に従って、当該データ量のデータを、前記複数のアクセス先のそれぞれに要求する要求手段と、を備えることを特徴とする。
【発明の効果】
【０００８】
本発明によれば、アクセス先に応じて適切なデータ量のデータを要求することができる。
【図面の簡単な説明】
【０００９】
【図１】Ｗｅｂサービスシステムの構成を示す図である。
【図２】ＭＦＰのハードウェア構成を示す図である。
【図３】リレーサーバのアプリケーション構成を示す図である。
【図４】各サイトで登録されているデータ構成の一例を示す図である。
【図５】アルバムリストの記述例を示す図である。
【図６】サイトごとに定義されているＡＰＩの一覧を示す図である。
【図７】ＭＦＰとリレーサーバ間のＡＰＩと、リレーサーバとサイト間のＡＰＩとの対応を示す図である。
【図８】コンディションチェックの処理の手順を示す図である。
【図９】アルバムリストを取得し、表示するまでの処理の手順を示す図である。
【図１０】印刷対象の画像を選択して印刷するまでの処理を示す図である。
【図１１】サイト１０３に対してのＡＰＩ利用回数を説明するための図である。
【図１２】サイト１０４に対してのＡＰＩの利用回数を説明するための図である。
【図１３】要求するデータ量を調整する処理の第１の例を示す図である。
【図１４】要求するデータ量を調整する処理の第２の例を示す図である。
【図１５】要求するデータ量を調整する処理の第３の例を示す図である。
【発明を実施するための形態】
【００１０】
以下、添付図面を参照して本発明の好適な実施例を詳しく説明する。尚、以下の実施例は特許請求の範囲に係る本発明を限定するものでなく、また本実施例で説明されている特徴の組み合わせの全てが本発明の解決手段に必須のものとは限らない。なお、同一の構成要素には同一の参照番号を付して、説明を省略する。
【００１１】
〔実施例１〕
［システム構成とハードウェア構成］
図１は、本発明に係るＷｅｂサービスシステムの構成を示す図である。図１に示すように、クライアント装置としてのＭＦＰ（多機能複合装置：Ｍｕｌｔｉｆｕｎｃｔｉｏｎａｌ Ｐｅｒｉｐｈｅｒａｌ）１０１は、インターネット等のネットワーク１１０を介して、Ｗｅｂサーバ１０３、１０４、１０５と接続されている。これらのサーバは、例えば写真共有サイト機能をクライアント装置に提供するサーバであり、以下、Ｗｅｂサーバ１０３、１０４、１０５をそれぞれサイト１０３、１０４、１０５ともいう。
【００１２】
またＭＦＰ１０１は、リレーサーバ１０２を介して、各Ｗｅｂサーバ１０３〜１０５とデータの送受信を行う。この構成においてリレーサーバは、各Ｗｅｂサーバとの間でそれぞれ定義されたＡＰＩを用いてデータの送受信を行っている。また、リレーサーバは、ＭＦＰとの間においてはその間で定義されたＡＰＩを用いてデータの送受信を行う。つまり、リレーサーバがＡＰＩ変換の役割を果たす。
【００１３】
この構成においては、各Ｗｅｂサーバから同じデータ量のデータを取得しようとする場合であって、Ｗｅｂサーバごとにデータの取得時間（応答時間）が異なってしまうことがある。この原因の１つに、各Ｗｅｂサーバから類似の情報を取得する場合であっても、ＷｅｂサーバごとにＡＰＩの構成が異なるという理由がある。よって、例えばＭＦＰ１０１のユーザが、同様のサービス内容の複数のＷｅｂサービス（例えば複数の写真共有サイト）を利用する場合に、Ｗｅｂサービスによって応答時間が異なることになってしまう。よって、ユーザは、同様のサービス内容であるにも拘わらず応答時間が異なるため、ＭＦＰ１０１の操作時に違和感を覚えてしまうことがある。
【００１４】
例えばクライアント装置がＷｅｂサーバから取得したデータを表示画面に表示させる場合に、仮にＷｅｂサーバ１０３の応答速度が、Ｗｅｂサーバ１０４の３倍速いとする。このとき、同じ内容の写真をダウンロードして表示する場合、Ｗｅｂサーバ１０４が画像の表示を開始するときには、Ｗｅｂサーバ１０３が表示を開始する時間の３倍の時間を要する必要になる。しかしながら、ユーザにとっては、同じ内容の画像を表示させるときの時間が異なることに違和感を覚えることがある。
【００１５】
そこで本実施例では、ＭＦＰがＷｅｂサーバと通信するときに、複数のサーバにおいて、ＭＦＰが単位時間で取得するデータ量の差が少なくなるように、ＭＦＰが一度に要求するデータ量を決定する。なお、このデータ量は、ＭＦＰがＷｅｂサーバとアクセスするときのＡＰＩの利用回数や、Ｗｅｂサーバとの通信環境に応じて決定する。詳細については後述する。
【００１６】
ここで、写真共有サイト機能とは、クライアント装置により作成された写真等の画像をサーバに格納し、複数のクライアント装置により、サーバに格納されている画像にアクセスできる機能をいう。本実施例において情報処理装置としてのＭＦＰ１０１は、リレーサーバ１０２を介してサーバ１０３〜１０５にアクセスすることで、各サイトの写真共有サイト機能を享受することができる。例えば、ＭＦＰ１０１は、リレーサーバ１０２を介してサイト１０３〜１０５から、画像が格納されている場所を示すＵＲＬ等の登録情報を取得して、そのＵＲＬに従ってサーバにアクセスすることにより、アルバムや画像の選択画面を表示することができる。特に上記のＭＦＰでは、ＰＣ等を介さずにサイトにアクセスして、アルバムや画像の選択画面を表示することができる。ユーザがその選択画面において印刷を所望する画像を選択すると、ＭＦＰ１０１は、印刷対象の画像データを各サイトから取得して印刷することができる。
【００１７】
図２は、ＭＦＰ１０１のハードウェア構成を示す図である。ＭＦＰ１０１は、操作部２０１と、カードインタフェース２０２と、読取部２０８と、記録部２０９とを有する。また、ＭＦＰ１０１は、ＣＰＵ２００と、ＲＯＭ２０３と、ＲＡＭ２０４と、不揮発性ＲＡＭ２０５と、表示部２０６と、画像処理部２１０と、圧縮／解凍部２１１と、駆動部２１２と、センサ部２１３とを有する。ＣＰＵ２００は、ＭＦＰ１０１全体を制御し、例えば操作部２０１を介して入力したユーザ操作に従ってＲＯＭ２０３に記憶されているプログラムを実行する。ＲＯＭ２０３は、ＭＦＰ１０１の制御命令プログラム等を格納する。さらに、ＭＦＰ１０１は、無線ネットワーク部２０７と有線ネットワーク部２１４とを有する。無線ネットワーク部２０７は、ＩＥＥＥ８０２．１１ａ等の規格に対応した無線ＬＡＮアクセスポイントと無線によって通信可能である。有線ネットワーク部２１４は、１００Ｂａｓｅ−ＴＸ等のより対線ケーブルを接続可能なＥｔｈｅｒｎｅｔ（登録商標）コネクタを有している。
【００１８】
図１に示すリレーサーバ１０２や各サイト１０３〜１０５には、一般的なＰＣ等の構成が用いられる。つまり、リレーサーバ１０２や各サイト１０３〜１０５は、一般的な、ＣＰＵ、ＲＯＭ、ＲＡＭ、ＨＤＤやディスプレイ等の表示部、ポインティングデバイスやキーボード等の入力部を有する。例えば、上記各装置において、ＣＰＵはハードディスクやＲＯＭ等から読み込まれたプログラムをＲＡＭに展開して実行する。ＨＤＤは、各種フローチャートに示される処理を実行するプログラムや画像データを格納する。ディスプレイは、ユーザインタフェース等を表示し、ユーザは、ポインティングデバイスやキーボード等を用いてユーザインタフェース上で操作し、各種指示を入力することができる。
【００１９】
［写真共有サイト］
リレーサーバ１０２のアプリケーション構成を説明する前に、Ｗｅｂサービスの１つである写真共有サイト機能について説明する。各サイト１０３〜１０５によりＷｅｂサービスとして提供される写真共有サイト機能は、主に、ＰＣのブラウザで閲覧されることを想定している。また、ユーザはアカウントを取得し、そのアカウントとパスワードとをセットとして登録してからＷｅｂサービスを利用する。
【００２０】
図４は、写真共有サイト機能について、各サイト１０３〜１０５で登録されているデータ構成の一例を示す図である。各サイト１０３〜１０５に登録される画像は、アルバムという単位で纏められている。例えば、図４に示すように、各サイトには、アルバムが５つ登録されている。また、アルバム１及び２には、それぞれ３つの画像が登録されている。また、アルバム３には１つの画像が登録され、アルバム４には４つの画像が登録され、アルバム５には２つの画像が登録されている。さらに、各アルバムには、そのアルバムを代表するサムネイル画像の他、アルバムのタイトルや、アルバム登録日等も含まれており、写真共有サイト機能を用いるためのブラウザ上に表示される。ユーザは、表示されたアルバムリストから１つのアルバムを選択すると、選択されたアルバムに登録された１つ以上の画像を閲覧することができる。
【００２１】
以上のような写真共有サイト機能は、ＰＣのブラウザからのみ利用可能というわけではない。例えば、公開された各サイト１０３〜１０５のＡＰＩを用いることによって、ブラウザを実装する装置以外の装置（ＭＦＰ等）からもＷｅｂサービスを利用することができる。
【００２２】
図５は、リレーサーバ１０２がＡＰＩを利用して各サイト１０３〜１０５から取得した、アルバムリストの記述例を示す図である。アルバムリストは、例えばＸＭＬで記述される。図５に示すように、タグ「＜ｔｏｔａｌ Ｒｅｓｕｌｔｓ＞」から、アルバム数が１０であることが確認できる。また、各アルバムの情報として、タグ「＜ｅｎｔｒｙ＞」ごとに、画像のＵＲＬ、サムネイル画像のＵＲＬ、ＩＤ、撮影日などが記述されている。
【００２３】
ＭＦＰ１０１は、ネットワーク通信機能によってリレーサーバ１０２のＡＰＩに対応することができる。ＭＦＰ１０１は、各サイト１０３〜１０５から情報を取得する際に、各サイト１０３〜１０５のＡＰＩに直接、情報要求を発行しない。ＭＦＰ１０１は、まず、リレーサーバ１０２との間で定義されたＡＰＩを用いてリレーサーバ１０２とＨＴＴＰのＰＯＳＴ通信を利用してリレーサーバ１０２に対して情報要求を発行する。
【００２４】
リレーサーバ１０２とＭＦＰ１０１との間でのＡＰＩは、例えば下記のように定義される。
【００２５】
・ＡＰＩ−Ｒ１（コンディションチェック）：ＭＦＰ１０１の仕向け情報及びインターネット上のＩＰアドレスによって各サイトに接続可能かを確認する際に用いられる。
【００２６】
・ＡＰＩ−Ｒ２（ログイン認証）：各サイトとの認証が可能かを判定する際に用いられる。
【００２７】
・ＡＰＩ−Ｒ３（アルバムリスト要求）：全アルバムのリストを取得する際に用いられる。
【００２８】
・ＡＰＩ−Ｒ４（画像リスト要求）：アルバムに登録されている全画像のリストを取得する際に用いられる。
【００２９】
ＭＦＰ１０１は、ユーザが指定したサイトに情報要求（実際は、上記のようにリレーサーバ１０２に対して情報要求を発行）することにより、当該情報要求に応じたアルバムリストや画像リストをリレーサーバ１０２から受信する。ＭＦＰ１０１は、受信したリストの該当部分から表示用のデータのＵＲＬを取得することができる。ＭＦＰ１０１は、認証及び上記リストの取得についてはリレーサーバ１０２を介して行うが、画像データ等のＵＲＬを取得した後は、各サイトから直接受信することができる。
【００３０】
［リレーサーバ］
リレーサーバ１０２は、ＭＦＰ１０１が各サイト１０３〜１０５から情報を取得する場合に、ＡＰＩ変換機能を用いて仲介する役割を果たす。リレーサーバ１０２は、ＭＦＰ１０１との関係においてＷｅｂサーバとして機能し、各サイト１０３〜１０５との関係においては、Ｗｅｂクライアントとして機能する。
【００３１】
図３は、リレーサーバ１０２のアプリケーション構成を示す図である。本実施例において、リレーサーバ１０２の主な機能はＡＰＩ変換機能である。リレーサーバ１０２は、ＭＦＰ１０１との間で「ＭＦＰ−ＡＰＩ」を定義している。リレーサーバ１０２は、ＭＦＰ１０１との間で定義されたＡＰＩ構成を、接続先の各サイト１０３〜１０５との間で定義されたＡＰＩ構成（「サイトＡ−ＡＰＩ」、「サイトＢ−ＡＰＩ」、「サイトＣ−ＡＰＩ」）にＡＰＩ変換する。
【００３２】
図６は、サイトごとに定義されているＡＰＩの一覧を示す図である。ＭＦＰ１０１が各サイトから情報を取得するためには、リレーサーバ１０２が、各サイトとの間で定義されたＡＰＩ構成を用いる必要がある。つまり、ＭＦＰ１０１が同じ情報を各サイトから取得する場合であっても、リレーサーバ１０２と各サイトとの間で定義されるＡＰＩの構成は異なる。
【００３３】
図７は、ＭＦＰ１０１とリレーサーバ１０２との間で定義されるＡＰＩ（ＡＰＩ-Ｒとする）と、リレーサーバ１０２と各サイトとの間で定義されるＡＰＩとの対応を示す図である。この図７により、サイトからデータを取得するために必要なＡＰＩの数は、ＭＦＰが要求するデータの種類によって異なり、また同じデータの種類であっても、接続先のサイトによっても異なることがわかる。例えば、アルバムリスト要求ＡＰＩ−Ｒ３を用いてＭＦＰ１０１があるサイトを指定して情報要求する場合に、ユーザが指定したサイトによってリレーサーバ１０２から発行するＡＰＩの種類と発行数が異なることが分かる。詳細については、後述する。
【００３４】
図３を参照して、リレーサーバ１０２の各機能を説明する。リレーサーバ１０２は、以下のような機能を有している。なお、リレーサーバ１０２では、この各機能に対応するプログラムがＲＯＭに記憶されており、リレーサーバ１０２のＣＰＵが、このＲＯＭに記憶されているプログラムを実行することにより、図３に示す各機能を実現できるものとする。
【００３５】
・パーサ機能：図５で示すような各サイトからのＸＭＬリストをパーサにより解釈する。
【００３６】
・フィルタ機能：各サイトから受信したデータのうち、ＭＦＰ１０１に送信する情報以外のデータを削除する。例えば、有効期限の切れたコンテンツや、指定以外のファイルタイプや、上限以上のファイルサイズの画像データ等を削除する。
【００３７】
・チェック機能：ＭＦＰ１０１からのコンディションチェック要求に応じて、ＭＦＰ１０１のＩＰアドレス及びＭＦＰ１０１から送信される情報に基づき、各サイトに接続可能かをチェックする。
【００３８】
・ＡＰＩ判定機能：各サイトごとのＡＰＩ利用回数を比較する。例えば、ＭＦＰ１０１から情報要求された場合に、その情報を取得するために必要なＡＰＩ利用回数を各サイトについて比較する。なお、本実施例では、このＡＰＩ判定機能によるＡＰＩ利用回数に基づいて、ＭＦＰ１０１がＷｅｂサーバに一度に要求するデータ量を決定する。
【００３９】
・制御機能：ＭＦＰ１０１の仕向け情報に基づき、指定するサイトを振り分ける。
【００４０】
本実施例においては、ＭＦＰ１０１が各サイトへの情報要求量（ＭＦＰ１０１がＷｅｂサーバに対して要求するデータのデータ量）を調整することにより、各サイトから情報を取得するまでの応答時間を基準時間に近づけ、その結果、各サイト間での応答時間の差を低減する。以下、その処理について説明する。ＭＦＰ１０１は、まず、コンディションチェックを実行して接続可能なサイトを判定する。
【００４１】
［コンディションチェック］
図８は、コンディションチェックの処理の手順を示す図である。コンディションチェックは、リレーサーバ１０２と指定される各サイトとの通信状況を判定するための処理である。ＭＦＰ１０１は、リレーサーバ１０２にコンディションチェックを要求する（Ｓ８０１）。リレーサーバ１０２がＭＦＰ１０１からの要求を受信すると、ＭＦＰ１０１のＩＰアドレスに基づいて、そのＭＦＰ１０１が接続可能なサイトを特定する（Ｓ８０２）。リレーサーバ１０２は、その特定したサイトとともに、ＡＰＩ判定機能による判定結果をＭＦＰ１０１に返信する（Ｓ８０３）。ＡＰＩ判定機能による判定結果については後述する。また、リレーサーバ１０２は、コンディションチェックの要求を受信すると、テスト用のパケット等に基づき各サイトからの応答時間を確認して、ＭＦＰ１０１に返信する。例えば、実測応答時間が２３０ｍｓｅｃである場合には、その値「Ｍ」をＭＦＰ１０１に返信する。ＭＦＰ１０１は、その値Ｍを各サイトとの通信環境の判定値として自装置内に保存する。以下、接続候補になるサイトがサイト１０３〜１０５の３つあり、そのうちサイト１０３とサイト１０４が接続可能と判定されたとして説明する。
【００４２】
［ＭＦＰからのアルバムリスト／画像リスト要求例］
ＭＦＰ１０１が各サイトから画像を受信して印刷するまでの概要は以下のようである。まず、ＭＦＰ１０１は、利用可能なサイト１０３及び１０４のうち１つを選択し、そのサイト内の個人用のアルバムにアクセスするためのアカウント及びパスワードを用いて、認証確認のためのＡＰＩ−Ｒ２をリレーサーバ１０２に発行する。その後、ＭＦＰ１０１は、アルバムリストをサイトからリレーサーバ１０２経由で取得し、ユーザは、ＭＦＰ１０１上で所望するアルバムを選択する。そして、ＭＦＰ１０１は、所望のアルバムに登録されている画像リストをリレーサーバ１０２経由で取得し、ユーザは、ＭＦＰ１０１上で所望する画像を選択する。ＭＦＰ１０１は、選択された画像をサイトから受信して印刷を行う。
【００４３】
上記の処理の流れについて、図９及び図１０を参照して説明する。図９は、アルバムリストを取得して表示するまでの処理の手順を示す図である。ＭＦＰ１０１は、アルバムリスト要求をＡＰＩ−Ｒ３を用いてリレーサーバ１０２に発行する（Ｓ９０１）。リレーサーバ１０２は、その要求を解析してＡＰＩ変換機能によって要求先のサイトに応じたＡＰＩ要求を発行する（Ｓ９０２）。要求先のサイトは、その要求に応じて、アルバムリストをリレーサーバ１０２に対して返信する（Ｓ９０３）。Ｓ９０２及びＳ９０３において用いられるＡＰＩの構成は、各サイトにより異なる。リレーサーバ１０２は、例えば図５に示すような記述形式でアルバムリストを受信する。リレーサーバ１０２は、ＸＭＬをパースしてアルバムリストをＭＦＰ１０１に返信する（Ｓ９０４）。
【００４４】
ＭＦＰ１０１は、受信したアルバムリストに基づき、サイトに対して直接、ＨＴＴＰのＧｅｔ要求を発行する（Ｓ９０５）。そして、ＭＦＰ１０１は、そのサイトからサムネイル画像を受信して（Ｓ９０６）、アルバムの選択画面をＭＦＰ１０１の表示画面に表示する。ユーザは、表示されたアルバムの選択画面から、所望のアルバムを選択する（Ｓ９０７）。若しくは、ユーザがアルバムの選択対象を切り替える度に、Ｓ９０５及びＳ９０６の処理が行われても良い。
【００４５】
図１０は、図９に示す処理の後、印刷対象の画像を特定して印刷するまでの処理を示す図である。ＭＦＰ１０１は、アルバム画像を要求するために、ＡＰＩ−Ｒ４をリレーサーバ１０２に発行する（Ｓ１００１）。リレーサーバ１０２は、その要求を解析してＡＰＩ変換機能によって要求先のサイトに応じたＡＰＩ構成に変換し、その変換されたＡＰＩを要求先のサイトに発行する（Ｓ１００２）。サイトは、その要求に応じて、指定されたアルバム中の画像の画像リストをリレーサーバ１０２に対して返信する（Ｓ１００３）。Ｓ１００２及びＳ１００３において用いられるＡＰＩの構成は各サイトにより異なる。リレーサーバ１０２は、例えば図５に示すような記述形式で画像リストを受信する。リレーサーバ１０２は、ＸＭＬをパースして画像リストをＭＦＰ１０１に返信する（Ｓ１００４）。
【００４６】
ＭＦＰ１０１は、受信した画像リストからサムネイル画像のＵＲＬ情報等を取得し、サイトに対して直接、ＨＴＴＰのＧｅｔ要求を発行する（Ｓ１００５）。そして、ＭＦＰ１０１は、そのサイトからサムネイル画像を受信して（Ｓ１００６）、画像の選択画面をＭＦＰ１０１の表示画面に表示する。ユーザは、表示された画像の選択画面から所望の画像を選択する（Ｓ１００７）。若しくは、ユーザが画像の選択対象を切り替える度に、Ｓ１００５及びＳ１００６の処理が行われても良い。ユーザにより所望の画像が選択されて印刷が指示されると、ＭＦＰ１０１は、印刷対象の画像データを取得するために、サイトに対して直接、ＨＴＴＰのＧｅｔ要求を発行し（Ｓ１００８）、サイトから印刷対象の画像データを受信する（Ｓ１００９）。ＭＦＰ１０１は、受信した印刷対象の画像データを展開して記録媒体に印刷する（Ｓ１０１０）。
【００４７】
［各サイトについてのＡＰＩ構成］
上記の一連の処理において、アルバムリストや画像リスト取得のためにリレーサーバ１０２から各サイトに対して発行するＡＰＩの利用回数（発行されるＡＰＩコマンド数）が異なる。また、その相違に伴い、ＭＦＰ１０１がサイトに情報を要求して取得するまでの応答時間も、各サイトによって異なる。以下、例を挙げて説明する。
【００４８】
図１１は、アルバムリストの要求をサイト１０３に対して発行した場合に、サイト１０３に対してリレーサーバ１０２が発行するＡＰＩの利用回数を説明するための図である。リレーサーバ１０２は、サイト１０３に対して認証のためのＡＰＩ−Ａ１を発行し（Ｓ１１０１）、次に、アルバムリストの取得のためのＡＰＩ−Ａ２を発行する（Ｓ１１０２）。つまり、リレーサーバ１０２は、アルバムリスト取得までサイト１０３に対して、ＡＰＩを２回発行する。
【００４９】
図１２は、アルバムリストの要求をサイト１０４に対して発行した場合に、サイト１０４に対してリレーサーバ１０２が発行するＡＰＩの利用回数を説明するための図である。リレーサーバ１０２は、サイト１０４に対して認証を開始する条件確認のためのＡＰＩ−Ｂ１、ＡＰＩ−Ｂ２、ＡＰＩ−Ｂ３を発行する（Ｓ１２０１〜Ｓ１２０３）。その後、リレーサーバ１０２は、認証のためのＡＰＩ−Ｂ４を発行する（Ｓ１２０４）。リレーサーバ１０２は、認証成功後、アルバムリスト取得のためのＡＰＩ−Ｂ５を発行する（Ｓ１２０５）。さらに、リレーサーバ１０２は、サイト１０４に対して、アルバムリストに含まれる各アルバムごとに、タイトルや撮影日等の情報取得のためのＡＰＩ−Ｂ６を発行する（Ｓ１２０６）。さらに、リレーサーバ１０２は、各アルバムごとに、アルバムに設定されている代表画像としてのサムネイル画像のＵＲＬ等の情報を取得するためのＡＰＩ−Ｂ７を発行する（Ｓ１２０７）。例えば、図４に示すように、アルバムが５つ設定されている場合には、Ｓ１２０６及びＳ１２０７において各５回ＡＰＩを利用するので、リレーサーバ１０２は、計１５回のＡＰＩ要求をサイト１０４に対して発行することになる。
【００５０】
図１１に示す手順によって、ＭＦＰ１０１が図４に示すアルバムリストを要求してからリレーサーバ１０２からアルバムリストを受信するまでの応答時間は１秒程度であった。一方で、図１２に示す手順によって、ＭＦＰ１０１が図４に示すアルバムリストを要求してからリレーサーバ１０２からアルバムリストを受信するまでの応答時間は１０秒程度であった。
【００５１】
このように、ユーザは、同じアルバムリストを異なるサイトから取得する場合に、各サイトに対して発行されるＡＰＩの構成が異なるので、応答時間に差が生じてしまう。そして、そのことがユーザに対して操作上の違和感を与えてしまう。本実施例においては、上述のＡＰＩの構成やコンディションチェック時の各サイトへの通信時間等の通信条件に応じて、各サイトへの情報要求量を基準となる応答時間となるように調整する。そのような構成によって、各サイト間での応答時間の差を低減する。
【００５２】
［データ制御方法］
ＭＦＰ１０１は、まず、少なくとも以前に１つのＷｅｂサービスを利用して、応答時間の基準値（基準時間ともいう）が設定されたか否かを判定する。この基準値は、ＭＦＰがＷｅｂサーバに要求するデータ量を補正するか否かを判定するための値である。ここで、まだ、基準値が設定されていないと判定された場合には、図１３に示す処理が実行され、基準値が既に設定されていると判定された場合には、図１４に示す処理が実行される。図１３及び図１４に示す処理は、例えば、ＭＦＰ１０１のＣＰＵ２００により実行される。
【００５３】
最初に、図１３を説明する。ＣＰＵ２００は、まず上記の基準値として、ユーザが待ち時間として違和感を与えないとされる基準時間Ｔ（例えば、２秒等）を設定する（Ｓ１３０１）。次に、ＣＰＵ２００は、図８のＳ８０３において自装置に保存された実測応答時間の値Ｍを読み出して閾値との比率を算出することで、通信状況の判定を行う（Ｓ１３０２）。なお、この値Ｍは、上記のように、Ｗｅｂサーバのコンディションチェックの際に応答時間判定を行うことにより、取得することができる。このとき、例えば、Ｍ＝１６０ｍｓｅｃであり、比較値が２００ｍｓｅｃの場合には、その比率は０．８となる。この比率が大きいほど、通信状況が良好であり、サイトとの通信に必要な時間が短くて済むことになる。この比率より、各サイトとの通信に必要な時間を評価することができる。以下、その０．８を通信環境の判定値として用いる。次に、ＣＰＵ２００は、図８のＳ８０３においてリレーサーバ１０２から受信したＡＰＩ判定機能の判定結果を参照する（Ｓ１３０３）。
【００５４】
ここで、図１１及び図１２を参照しながら、ＡＰＩ判定機能の判定結果について説明する。例えば、サイト１０３については、図１１に示すように、アルバムリスト取得までにＡＰＩを２回利用している。また、サイト１０４については、アルバムリスト取得までにＡＰＩを１５回利用している。また、サイト１０５については、例えば、図６に示すようにＡＰＩが用いられるとすると、アルバムリスト取得までにＡＰＩを１回利用する。本実施例においては、アルバムリスト取得までの、複数のＷｅｂサーバにおける最低のＡＰＩ利用回数を基準として、各利用回数の比率を判定結果としている。このとき、サイト１０４におけるＡＰＩ利用回数「１」が最低の利用回数となり、サイト１０３のＡＰＩ利用回数が図１１の説明から２回、サイト１０４のＡＰＩ利用回数が図１２の説明から１５回であることがわかる。よって、ＡＰＩ利用回数の比率は、サイト１０３については２／１＝２となり、サイト１０４については１５／１＝１５となり、サイト１０５については１／１＝１となる。即ち、ＭＦＰにより利用される複数のサイトのそれぞれの、ＡＰＩの利用回数の比率により、ＡＰＩ利用状況を複数のサイトにおいて相対的に評価する。この比率が高いほど、データを取得するために必要なＡＰＩの数が多く、データを取得するために必要な時間が長くなると判断することができる。なお、ＡＰＩ判定機能の判定結果として、上記のような比率の他に、各ＡＰＩの処理時間や処理内容を考慮した値が用いられても良い。
【００５５】
次に、ＣＰＵ２００は、Ｓ１３０２、Ｓ１３０３において判定された通信状況、ＡＰＩの使用状況においてＭＦＰがＷｅｂサーバに要求する情報量を評価する為に、所定の情報要求量を設定する（Ｓ１３０４）。本実施例においては、例えばアルバム情報要求量が「１０００」とすると、その「１０００」に対して、Ｓ１３０２において算出された比率とＳ１３０３において算出されたＡＰＩ判定結果とを反映して、新たな情報要求量を決定する。
【００５６】
例えば、Ｓ１３０２において算出された応答時間の比率とＳ１３０３において算出されたＡＰＩ利用回数の比率とを用いて（所定の情報要求量／応答時間の比率）／ＡＰＩ利用回数の比率（式１）を、新たな情報要求量として算出する。上記の例では、応答時間の比率が「０．８」、ＡＰＩ利用回数の比率が「２」（サイト１０３の場合）であるため、（１０００／０．８）／２＝６２５を新たな情報要求量として設定する。
【００５７】
本実施例においては、各サイトへの情報要求量を、各サイトとの通信状況と、各サイトとリレーサーバとの間のＡＰＩ構成とを考慮して調整する。つまり、式１に示すように、リレーサーバ１０２とサイトとのコンディションチェックの結果が良くない程（通信時間がかかる程）、若しくは、接続先サイトに対して用いられるＡＰＩ構成が複雑になる程（ＡＰＩ利用回数が多い程）、ＭＦＰがＷｅｂサーバに一度に要求する情報要求量を少なくする。そのように調整することによって、接続先サイトからの情報の応答時間を基準時間に近づけることができる。式１においては、Ｓ１３０１における基準時間Ｔは考慮されていないが、Ｗｅｂサーバからの応答時間が、おおよそＳ１３０１で取得した基準時間Ｔとなるであろう情報要求量を算出することができる。Ｓ１３０７において、予想応答時間と実際の実応答時間との差に基づき、その情報要求量を、上記の算出した情報要求量に補正して次回以降の情報要求量とする。詳細については後述する。
【００５８】
次に、ＣＰＵ２００は、Ｓ１３０５において、サイト１０３に対する「６２５」分のアルバム情報要求を、リレーサーバ１０２に発行する。Ｓ１３０６において、ＣＰＵ２００は、アルバム情報要求量「６２５」を要求してから取得するまでの実応答時間を取得する。そして、ＣＰＵ２００は、Ｓ１３０６において取得した実応答時間を、Ｓ１３０１において設定された基準時間Ｔと比較する。ここで、実応答時間が基準時間Ｔより小さい場合には、基準時間Ｔをその実応答時間により更新する（Ｓ１３０９）。例えば、上記のように情報量「６２５」を要求したが、実際にＷｅｂサーバに登録されていたデータ量が、要求されたデータ量よりも少ない場合に、取得時間が基準時間よりも少なくなる。その際に、実際に受信したアルバム情報量（例えば、「６２５」分を要求したが実際に受信したのは「５００」分であった場合）もあわせて保存する。この保存された「５００」が、Ｓ１３０９において更新された基準時間Ｔに対する新たな情報要求量となる。この新たな情報要求量に基づく処理については、図１４を用いて後述する。
【００５９】
一方、Ｓ１３０６における実応答時間が基準時間Ｔ以上の場合には、ユーザの待ち時間としてはまだ不適当であるので、Ｓ１３０８において情報要求量を補正する。例えば、実応答時間が基準時間Ｔの１．２倍である場合には、Ｓ１３０４で設定した要求量「６２５」を１．２で除した値「５２１」を、次回の情報要求量として、ＲＯＭ２０３、不揮発性ＲＡＭ２０５等のメモリに記憶する。そして、次回の情報要求の際にＭＦＰは、メモリに記憶されている情報要求量（データ量「５２１」）のデータをＷｅｂサーバに要求することで、基準時間Ｔよりも短い時間でデータを取得することができる。
【００６０】
以降、ＣＰＵ２００は、図９のＳ９０５〜Ｓ９０７のように、受信したアルバム情報に基づき、サムネイル画像を各サイトから受信し、ユーザにアルバム選択画面を表示する処理を行う（Ｓ１３１０）。
【００６１】
この図１３に示したように、Ｓ１３０２において算出された応答時間の比率とＳ１３０３において算出されたＡＰＩ利用回数の比率とを用いて、Ｓ１３０４で情報要求量を算出する。そして、Ｓ１３０５〜Ｓ１３０７で、Ｓ１３０４で算出された情報要求量のデータを、実際にＷｅｂサーバに要求し、そのときの取得時間を、基準時間Ｔにより評価する。そして、Ｓ１３０７でデータの取得時間が基準時間Ｔ以上であった場合に、クライアント装置によりＷｅｂサーバに一度に要求する情報量を調整することで、データを要求してから基準時間Ｔよりも短い時間で、データを取得することができる。
【００６２】
また、上記の図７に示すように、クライアント装置がデータを要求するＷｅｂサーバや、またＷｅｂサーバに要求するデータの種類によって、データの取得に必要なＡＰＩの数は異なる。よって、上記のように情報要求量をメモリに記憶するときに、Ｗｅｂサーバの種類や、データの種類に対応させて、情報要求量を記憶しておいてもよい。そして、データ要求の際には、そのデータ要求を行うＷｅｂサーバ、またデータの種類に応じた情報要求量に従って、データを要求する。
【００６３】
次に、図１３において基準時間Ｔが更新された後に、Ｗｅｂサーバ１０３とは異なるＷｅｂサーバ（Ｗｅｂサーバ１０４）に、ＭＦＰが情報を要求する処理について、図１４を用いて説明する。図１４は、図１３に示す処理に従って、新たな基準時間Ｔ’に更新したときに、新たな情報要求量を決定する処理について説明するためのフローチャートである。例えば図１３のＳ１３０６においてサイト１０３から「５００」分のアルバム情報を取得して、基準時間Ｔ’が決定された後に、サイト１０４に対して同じ情報要求量「５００」分のアルバム情報を要求する場合を示す。
【００６４】
ＣＰＵ２００は、まず、基準時間Ｔ’が設定されていることを確認する（Ｓ１４０１）。このときの基準時間Ｔ’とは、例えば、図１３のＳ１３０９において更新された基準時間Ｔや、図１３で基準時間の更新が行われなければ、Ｓ１３０１で取得した基準時間Ｔである。Ｓ１４０２及びＳ１４０３における処理は、Ｓ１３０２及びＳ１３０３における説明と同じである。ただし、本図においては、サイト１０４を接続先としたときの通信環境の判定値（応答時間の比率）を「１．０」として、またＡＰＩ使用回数は図１２の説明から「１５」である。
【００６５】
次に、ＣＰＵ２００は、情報要求量を設定する（Ｓ１４０４）。本図においては、情報要求量「５００」に対して、Ｓ１４０２において算出された比率とＳ１４０３において算出されたＡＰＩ判定結果とを反映して、新たな情報要求量を決定する。例えば、Ｓ１４０２において算出された「１．０」と、Ｓ１４０３において算出されたＡＰＩ判定結果「７．５」とを用いて、（５００／１．０）／７．５＝６７を算出する。なお、ＡＰＩ判定結果「７．５」は、Ｗｅｂサーバ１０４の場合のＡＰＩ使用回数「１５」、Ｗｅｂサーバ１０３の場合のＡＰＩ使用回数「２」の比率（１５／２）＝７．５により求めることができる。Ｓ１４０５において、ＣＰＵ２００は、サイト１０４に対する「６７」分のアルバム情報要求をリレーサーバ１０２に発行する。Ｓ１４０６において、ＣＰＵ２００は、アルバム情報要求量「６７」を要求してから取得するまでの実応答時間を取得する。
【００６６】
次に、ＣＰＵ２００は、Ｓ１４０６において取得した実応答時間が基準時間Ｔ’と比べて±２０％の範囲内に入っているか否かを判定する。ここで、その範囲内に入っていると判定された場合には、Ｓ１４０９に進む。Ｓ１４０９における処理は、Ｓ１３１０における説明と同じである。Ｓ１４０７においてＳ１４０９に進む判定とは、Ｓ１４０４において求めた情報要求量「６７」をサイト１０４に対して要求した場合に、おおよそ応答時間Ｔ’でその情報量のデータを取得することを意味する。即ち、サイト１０４に対してデータを要求した場合に、その応答時間が、サイト１０３にデータを要求したときとほぼ差がないということである。
【００６７】
一方、Ｓ１４０７において、±２０％の範囲内に入っていないと判定された場合には、Ｓ１４０８において、Ｓ１３０８と同様に要求量の補正を行い、Ｓ１４０４から繰り返す。これにより、情報要求量を、応答時間がＴ’となるように調整することができる。
【００６８】
以上の図１４に示す処理によって、ＭＦＰ１０１が接続するサイトを変更した場合においても、変更前の接続先のＷｅｂサーバの応答時間と同程度の応答時間で、変更後の接続先のＷｅｂサーバからデータを取得することができる。即ち、接続先のＷｅｂサーバの変更後も、変更前のＷｅｂサーバの応答時間に対して所定の範囲内に収まる誤差の応答時間で、データを取得できる情報要求量を決定することができる。
【００６９】
また、上記のように、Ｓ１４０８、Ｓ１４０４〜Ｓ１４０６において、ＭＦＰ１０１からのリレーサーバ１０２へ、情報要求量の補正、データの再要求、データの再取得が行われる。この再情報要求発行から再取得までの時間（Ｓ１４０８−Ｓ１４０４−Ｓ１４０６）がユーザへの違和感を生じさせる上で無視できない場合もある。そのような場合には、Ｓ１３０８と同様に補正後の情報要求量（例えば、「６０」）を次回の要求量と決定するとともに、最初にＳ１４０６で取得した「６７」分のアルバム情報に基づいてＭＦＰ１０１の表示画面に表示するように表示制御しても良い。即ち、更新された情報要求量「６０」によりデータが再取得されるのを待って、その再取得されたデータを表示させるのではなく、初めに情報要求量「６７」により取得された、情報量「６７」のデータを表示させる。これにより、ユーザは情報要求量が決定されるのを待たなくても、既に取得されているデータを確認することができる。また、図１３及び図１４においては、アルバム情報取得時について説明したが、アルバム中の画像リスト取得時に対しても適用することができる。
【００７０】
以上の実施例によれば、クライアント装置としてＭＦＰが、Ｗｅｂサーバ１０３からデータを取得する場合と、Ｗｅｂサーバ１０４からデータを取得する場合とにおいて、クライアント装置によるデータ要求に対して、データが取得されるまでの取得時間が、おおよそ基準時間Ｔとなるように、情報要求量が設定される。
【００７１】
よって、クライアント装置は、おおよそ基準時間Ｔ毎にデータを取得して、取得されたデータを処理することができる。例えばクライアント装置がＷｅｂサーバ１０３、１０４のそれぞれから取得したデータを表示画面に表示させる場合、共に、基準時間Ｔごとに新たなデータが表示することができる。
【００７２】
よって、クライアント装置がアクセスするＷｅｂサーバによって取得時間が異なることに起因して、ユーザに違和感を与えてしまうことを防ぐことができる。なお、以上の実施例では、Ｗｅｂサーバ１０３、１０４の情報要求量を、データの取得時間が基準時間Ｔになるように設定することで、Ｗｅｂサーバ１０３、１０４のデータの取得時間を合わせていた。
【００７３】
しかし本発明は、これに限らず、例えばＷｅｂサーバ１０３を基準にして、所定のデータ量のデータをＷｅｂサーバ１０３に要求したときの取得時間に、Ｗｅｂサーバ１０４のデータの取得時間が合うように、Ｗｅｂサーバ１０４に対する情報要求量を決定してもよい。例えば、Ｗｅｂサーバ１０３に実際に所定のデータ量のデータを要求し、そのデータを取得するまでの時間を計測する。そして、そのデータと同種のデータをＷｅｂサーバ１０４に要求したときに、データの取得時間が、上記のＷｅｂサーバ１０３の計測時間に合うように、Ｗｅｂサーバ１０４の情報要求量を決定する。この方法によっても、Ｗｅｂサーバ１０３、１０４において、データの取得時間を合わせることができる。
【００７４】
〔実施例２〕
本実施例においては、クライアント装置によりＷｅｂサーバにデータを要求するときに、データの取得時間がユーザに違和感を与えない範囲でＭＦＰの一度の要求で多くのデータを取得できるように、最低限の情報要求量から順次増加することで、情報要求量を設定する処理を行う。
【００７５】
図１５に示すＳ１５０１〜Ｓ１５０３については、図１３のＳ１３０１〜Ｓ１３０３の説明と同じである。本実施例においては、Ｓ１５０４において、ＣＰＵ２００は、最低限必要な情報要求量を設定する。例えば、ＭＦＰ１０１でサムネイル画像を一時に９画面表示可能な場合には、情報要求量を「９」として設定する。Ｓ１５０５〜Ｓ１５０７は、図１４のＳ１４０５〜Ｓ１４０７と同じである。
【００７６】
Ｓ１５０７では、Ｓ１５０６で情報を取得したときの取得時間が、基準時間Ｔの―２０％以内か判定する。なお、Ｓ１５０６では、データの取得時間が基準時間Ｔよりも十分小さくなるように、情報要求量を設定しており、Ｓ１５０５ではその情報要求量のデータを要求するようにする。
【００７７】
Ｓ１５０７において、取得時間が基準時間Ｔの―２０％以内と判定された場合には、データの取得時間が基準時間Ｔよりも短いためユーザに違和感を与えるものではなく、また情報要求量が十分大きいと判定する。Ｓ１５１０において、図９のＳ９０５〜Ｓ９０７のように、取得したアルバム情報に基づき、サムネイル画像を各サイトに要求し、ユーザにアルバム選択画面を表示する処理を行う。一方、−２０％の範囲内に入っていないと判定された場合には、情報要求量を予め定められた分増加して（Ｓ１５０８）、次回における情報要求量とする（Ｓ１５０９）。そして、今回のＳ１５０６において取得したアルバム情報に基づき、サムネイル画像を各サイトに要求し、ユーザにアルバム選択画面を表示する処理を行う。
【００７８】
なお、上記の説明では、Ｓ１５０６において、データの取得時間が基準時間Ｔよりも十分短くなるように設定していたがこれに限らない。例えば、Ｓ１５０７の判定の前に、上述したＳ１３０７、Ｓ１４０７のように、取得時間が基準時間Ｔより短いか判定して、取得時間が短い場合に、Ｓ１５０７において「取得時間が基準時間の―２０％以内か？」を判定してもよい。 一方、取得時間が基準時間Ｔ以上であった場合には、上述したＳ１３０８、Ｓ１４０８のように、取得時間が短くなるように補正計算を行う。
【００７９】
つまり、本実施例においては、ＭＦＰ１０１の表示上、最低限必要な情報要求量を要求し、その取得時間が基準時間より大幅に下回る場合には、基準時間から予め定められた範囲内に収まるまで、要求量を順次増加させていく。
【００８０】
これにより、データの取得時間がユーザに違和感を与えない範囲で、ＭＦＰによる一度の要求で多くのデータを取得できるように、情報要求量を設定することができる。
【００８１】
以上の実施例によれば、クライアント装置が複数のＷｅｂサーバのそれぞれからデータを取得するときに、クライアント装置によるデータ要求に対するＷｅｂサーバからの応答時間（データの取得時間）が、複数のＷｅｂサーバにおいて同じになるように、情報要求量を決定することができる。
【００８２】
これにより、複数のＷｅｂサーバにおいて、同一のデータ量のデータ要求に対する応答時間が異なる場合であっても、同じ応答時間でデータを取得することができる。よって、Ｗｅｂサーバにデータを要求して、データを取得し、処理を開始するまでの時間を、上記の複数のＷｅｂサーバのそれぞれにおいて統一することができる。よって、複数のＷｅｂサーバのそれぞれにおいて応答時間が異なることに起因するユーザの違和感を軽減することができる。
【００８３】
なお、以上の実施例では、複数のＷｅｂサーバのそれぞれがＷｅｂサービスを提供しており、複数のＷｅｂサーバにおいてデータの取得時間を合わせるように、Ｗｅｂサーバごとに情報要求量を決定していた。
【００８４】
しかし、本発明は、１つのＷｅｂサーバにおいて複数のＷｅｂサービスを提供するシステムにおいても応用できるものである。その１つのサーバでは、複数のアクセス先（ＵＲＬ等）が設定されており、そのアクセス先により異なるサービスを提供する。このようなシステムにおいても、アクセス先によってデータの取得時間が異なる場合があり、即ちユーザが使用するサービスによってデータの取得時間が異なる場合がある。よって、上記の実施例を用いて、１つのサーバにおける複数のアクセス先のそれぞれにおいてデータの取得時間が合うように、アクセス先のそれぞれに応じた情報要求量を決定してもよい。
【００８５】
また、以上の実施例では、Ｗｅｂサーバと通信を行うクライアント装置として、ＭＦＰを例に説明したが、クライアント装置はこれに限らず、例えばＰＣであってもよいし、携帯電話やデジタルカメラであってもよい。
【００８６】
本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。また、上記の処理を１つのプロセッサにより実行する場合に限らず、複数のプロセッサにより実行する場合であってもよい。
【特許請求の範囲】
【請求項１】
サーバと通信可能な情報処理装置であって、
前記情報処理装置が前記サーバからデータを取得するときの、複数のアクセス先のそれぞれと前記情報処理装置との間の通信条件を取得する取得手段と、
前記取得手段が取得した前記通信条件に基づき、前記情報処理装置が前記複数のアクセス先のそれぞれにデータを要求してから当該情報処理装置が当該データを取得するまでの応答時間が、当該複数のアクセス先において合うように、当該情報処理装置が当該複数のアクセス先のそれぞれにデータを要求するときの、当該データのデータ量を決定する決定手段と、
前記決定手段が決定した、前記複数のサーバのそれぞれに対応するデータ量に従って、当該データ量のデータを、前記複数のアクセス先のそれぞれに要求する要求手段と、
を備えることを特徴とする情報処理装置。
【請求項２】
前記決定手段は、前記複数のアクセス先のそれぞれの応答時間が、所定の範囲に収まるように、当該複数のアクセス先のそれぞれに要求するデータのデータ量を決定することを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記決定手段は、前記要求手段が前記サーバにデータを要求してから当該データを当該サーバから受信するまでの実応答時間に基づき、当該サーバにデータを要求するときのデータ量を補正することを特徴とする請求項１又は２に記載の情報処理装置。
【請求項４】
前記サーバはＷｅｂサーバであり、前記情報処理装置はリレーサーバを介して前記Ｗｅｂサーバと通信可能であって、
前記通信条件は、前記要求手段による要求に応じて前記Ｗｅｂサーバと前記リレーサーバとの間で用いられるＡＰＩコマンド数を含むことを特徴とする請求項１乃至３のいずれか１項に記載の情報処理装置。
【請求項５】
前記要求手段による要求により取得されたデータを、表示装置に表示させる表示制御手段をさらに備えることを特徴とする請求項４に記載の情報処理装置。
【請求項６】
サーバと通信可能な情報処理装置の制御方法であって、
前記情報処理装置が前記サーバからデータを取得するときの、複数のアクセス先のそれぞれと前記情報処理装置との間の通信条件を取得する取得工程と、
前記取得工程において取得した前記通信条件に基づき、前記情報処理装置が前記複数のアクセス先のそれぞれにデータを要求してから当該情報処理装置が当該データを取得するまでの応答時間が、当該複数のアクセス先において合うように、当該情報処理装置が当該複数のアクセス先のそれぞれにデータを要求するときの、当該データのデータ量を決定する決定工程と、
前記決定工程において決定した、前記複数のサーバのそれぞれに対応するデータ量に従って、当該データ量のデータを、前記複数のアクセス先のそれぞれに要求する要求工程と、
を備えることを特徴とする制御方法。
【請求項７】
請求項６に記載の制御方法をコンピュータに実行させるプログラム。
【請求項１】
サーバと通信可能な情報処理装置であって、
前記情報処理装置が前記サーバからデータを取得するときの、複数のアクセス先のそれぞれと前記情報処理装置との間の通信条件を取得する取得手段と、
前記取得手段が取得した前記通信条件に基づき、前記情報処理装置が前記複数のアクセス先のそれぞれにデータを要求してから当該情報処理装置が当該データを取得するまでの応答時間が、当該複数のアクセス先において合うように、当該情報処理装置が当該複数のアクセス先のそれぞれにデータを要求するときの、当該データのデータ量を決定する決定手段と、
前記決定手段が決定した、前記複数のサーバのそれぞれに対応するデータ量に従って、当該データ量のデータを、前記複数のアクセス先のそれぞれに要求する要求手段と、
を備えることを特徴とする情報処理装置。
【請求項２】
前記決定手段は、前記複数のアクセス先のそれぞれの応答時間が、所定の範囲に収まるように、当該複数のアクセス先のそれぞれに要求するデータのデータ量を決定することを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記決定手段は、前記要求手段が前記サーバにデータを要求してから当該データを当該サーバから受信するまでの実応答時間に基づき、当該サーバにデータを要求するときのデータ量を補正することを特徴とする請求項１又は２に記載の情報処理装置。
【請求項４】
前記サーバはＷｅｂサーバであり、前記情報処理装置はリレーサーバを介して前記Ｗｅｂサーバと通信可能であって、
前記通信条件は、前記要求手段による要求に応じて前記Ｗｅｂサーバと前記リレーサーバとの間で用いられるＡＰＩコマンド数を含むことを特徴とする請求項１乃至３のいずれか１項に記載の情報処理装置。
【請求項５】
前記要求手段による要求により取得されたデータを、表示装置に表示させる表示制御手段をさらに備えることを特徴とする請求項４に記載の情報処理装置。
【請求項６】
サーバと通信可能な情報処理装置の制御方法であって、
前記情報処理装置が前記サーバからデータを取得するときの、複数のアクセス先のそれぞれと前記情報処理装置との間の通信条件を取得する取得工程と、
前記取得工程において取得した前記通信条件に基づき、前記情報処理装置が前記複数のアクセス先のそれぞれにデータを要求してから当該情報処理装置が当該データを取得するまでの応答時間が、当該複数のアクセス先において合うように、当該情報処理装置が当該複数のアクセス先のそれぞれにデータを要求するときの、当該データのデータ量を決定する決定工程と、
前記決定工程において決定した、前記複数のサーバのそれぞれに対応するデータ量に従って、当該データ量のデータを、前記複数のアクセス先のそれぞれに要求する要求工程と、
を備えることを特徴とする制御方法。
【請求項７】
請求項６に記載の制御方法をコンピュータに実行させるプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【公開番号】特開２０１３−２５６４２（Ｐ２０１３−２５６４２Ａ）
【公開日】平成２５年２月４日（２０１３．２．４）
【国際特許分類】
【出願番号】特願２０１１−１６１３６５（Ｐ２０１１−１６１３６５）
【出願日】平成２３年７月２２日（２０１１．７．２２）
【出願人】（０００００１００７）キヤノン株式会社 (59,756)
【Ｆターム（参考）】
【公開日】平成２５年２月４日（２０１３．２．４）
【国際特許分類】
【出願日】平成２３年７月２２日（２０１１．７．２２）
【出願人】（０００００１００７）キヤノン株式会社 (59,756)
【Ｆターム（参考）】
[ Back to top ]