JP5956729B2 - リレーサーバ、リレーサーバの制御方法、情報処理システム、およびプログラム - Google Patents

Description

本発明は、Ｗｅｂサーバおよび情報処理装置と通信可能なリレーサーバ、リレーサーバの制御方法、情報処理システム、およびプログラムに関する。

従来より、インターネット等のネットワークに接続して情報を取得する際に、関門中継処理装置を介して情報を取得する構成が知られている（特許文献１）。そのような構成において、関門中継処理装置は、例えば、セルラパケットシステムにおいてセルラ端末とパケット通信を行い、また衛星パケットシステムにおいて、衛星を介して端末とパケット通信を行う。その場合に、関門中継処理装置は、通信を行う端末が、セルラ端末であるか衛星を介して通信を行う端末であるかに応じて、関門中継処理装置と端末との通信におけるタイムアウト時間を設定することが記載されている。

特開２００１−１９７１２４号公報

クライアント装置がＷｅｂサーバからＷｅｂサービスを利用する場合に、クライアント装置のユーザが利用するＷｅｂサービスによってアクセス先が異なり、それによりＷｅｂサーバからの応答時間が異なる場合がある。

しかしながら、そのような構成においては、従来、クライアント装置のタイムアウト時間は一定とされる。そのため、Ｗｅｂサービスによって応答時間が異なるにも拘わらず、クライアント装置では、Ｗｅｂサービスに関係なく一定の時間でタイムアウトとなる。上記の従来技術では、クライアント装置の種類に応じて、サーバがタイムアウト時間を設定しているが、そのクライアント装置がアクセスするアクセス先については考慮されていない。そのため、そのクライアント装置が種々のＷｅｂサービスを利用する場合であっても、クライアント装置‐サーバ間のタイムアウト時間は一定となる。

このように、クライアント装置‐サーバ間のタイムアウト時間が一定の場合に、例えばクライアント装置がＷｅｂサーバから確実に情報を取得できるようにすることを考慮すれば、Ｗｅｂサーバからの応答時間が遅いＷｅｂサービスを想定して、タイムアウト時間を設定する必要がある。そのため、ユーザが利用するＷｅｂサービスが、Ｗｅｂサーバからの応答時間が早いものであったとしても、クライアント装置では、必要以上の長い時間、サーバからの応答を待ってからタイムアウトしなくてはならない場合がある。

本発明は、上記の点に鑑み、情報処理装置とリレーサーバとの間の通信を適切にタイムアウトさせることができるリレーサーバ、リレーサーバの制御方法、情報処理システム、およびプログラムを提供することを目的とする。

上記課題を解決するため、本発明に係るリレーサーバは、Ｗｅｂサーバおよび情報処理装置と通信可能なリレーサーバであって、前記情報処理装置からの要求を受信し、当該要求に応じて前記Ｗｅｂサーバが提供する複数のアクセス先のいずれかと通信し、当該通信により当該複数のアクセス先のいずれかから受信した情報を前記情報処理装置に送信する送信手段と、前記リレーサーバが前記Ｗｅｂサーバと通信するときの前記複数のアクセス先のそれぞれと前記リレーサーバとの間の通信条件として、前記リレーサーバが前記Ｗｅｂサーバと通信するためのＡＰＩコマンド数を取得する取得手段と、前記複数のアクセス先のうちの、前記情報処理装置が情報の受信を要求するアクセス先に対応する前記取得手段により取得された前記ＡＰＩコマンド数に応じたタイムアウト時間に従って、前記送信手段による前記情報処理装置と前記リレーサーバとの間の通信がタイムアウトされるように制御する制御手段と、を備えることを特徴とする。

本発明によれば、情報処理装置とリレーサーバとの間の通信を適切にタイムアウトさせることができる。

Ｗｅｂサービスシステムの構成を示す図である。 ＭＦＰのハードウェア構成を示す図である。 リレーサーバのアプリケーション構成を示す図である。 各サイトで登録されているデータ構成の一例を示す図である。 アルバムリストの記述例を示す図である。 サイトごとに定義されているＡＰＩの一覧を示す図である。 ＭＦＰとリレーサーバ間のＡＰＩと、リレーサーバとサイト間のＡＰＩとの対応を示す図である。 コンディションチェックの処理の手順を示す図である。 アルバムリストを取得し、表示するまでの処理の手順を示す図である。 印刷対象の画像を選択して印刷するまでの処理を示す図である。 サイト１０３に対してのＡＰＩ利用回数を説明するための図である。 サイト１０４に対してのＡＰＩの利用回数を説明するための図である。 タイムアウト値設定処理の手順を示すフローチャートである。 判定テーブルの一例を示す図である。 サービスＡＰＩの判定処理の手順を示すフローチャートである。 タイムアウト値の設定処理の手順を示すフローチャートである。 タイムアウト値設定処理の手順を示すフローチャートである。 サイトに対応するタイムアウト値の一覧を示す図である。

以下、添付図面を参照して本発明の好適な実施例を詳しく説明する。尚、以下の実施例は特許請求の範囲に係る本発明を限定するものでなく、また本実施例で説明されている特徴の組み合わせの全てが本発明の解決手段に必須のものとは限らない。なお、同一の構成要素には同一の参照番号を付して、説明を省略する。

〔実施例１〕
［システム構成とハードウェア構成］
図１は、本発明に係るＷｅｂサービスシステムの構成を示す図である。図１に示すように、クライアント装置としてのＭＦＰ（多機能複合装置：Ｍｕｌｔｉｆｕｎｃｔｉｏｎａｌ Ｐｅｒｉｐｈｅｒａｌ）１０１は、インターネット等のネットワーク１１０を介してＷｅｂサーバ１０３、１０４、１０５と接続されている。これらのサーバは、例えば写真共有サイト機能をクライアント装置に提供するサーバであり、以下、Ｗｅｂサーバ１０３、１０４、１０５をそれぞれサイト１０３、１０４、１０５ともいう。

またＭＦＰ１０１は、リレーサーバ１０２を介して、各Ｗｅｂサーバ１０３〜１０５とデータの送受信を行う。この構成においてリレーサーバは、各Ｗｅｂサーバとの間でそれぞれ定義されたＡＰＩを用いてデータの送受信を行っている。また、リレーサーバは、ＭＦＰとの間においてはその間で定義されたＡＰＩを用いてデータの送受信を行う。つまり、リレーサーバがＡＰＩ変換の役割を果たす。

さらに、このシステムにおいて、ＭＦＰ１０１が利用するＷｅｂサービスによって、ＭＦＰがアクセスするＷｅｂサーバが異なる。即ち、ＭＦＰ１０１は、ＭＦＰ１０１のユーザが利用するＷｅｂサービス（例えば写真共有サイト）の種類に応じて、Ｗｅｂサーバ１０３〜１０５のいずれかにアクセスする。

このような構成において、ＭＦＰ１０１がアクセスするＷｅｂサーバによって、リレーサーバ１０２とＷｅｂサーバの間の応答時間が異なってしまうことがある。この原因の１つに、ＷｅｂサーバごとにＡＰＩの構成が異なるという理由がある。よって、ユーザがＭＦＰ１０１を用いて複数のＷｅｂサービスを利用する場合に、Ｗｅｂサービスによってアクセス先のＷｅｂサーバが異なり、またアクセス先のＷｅｂサーバによって、リレーサーバ１０２‐Ｗｅｂサーバ間の応答時間が異なることになる。

このように、ＭＦＰ１０１のアクセス先のＷｅｂサーバによって応答時間が異なるため、ＭＦＰ１０１‐リレーサーバ１０２間のタイムアウト時間も、そのアクセス先によって設定する必要がある。そこで、本実施例では、ＭＦＰ１０１がリレーサーバ１０２を介して、Ｗｅｂサーバ１０３〜１０５のいずれにアクセスする場合に、そのアクセス先のＷｅｂサーバに応じて、ＭＦＰ１０１‐リレーサーバ１０２間のタイムアウト時間を設定する。詳細については後述する。

ここで、写真共有サイト機能とは、クライアント装置により作成された写真等の画像をサーバに格納し、複数のクライアント装置により、サーバに格納されている画像にアクセスできる機能をいう。本実施例において情報処理装置としてのＭＦＰ１０１は、リレーサーバ１０２を介してサーバ１０３〜１０５にアクセスすることで、各サイトの写真共有サイト機能を享受することができる。例えば、ＭＦＰ１０１は、リレーサーバ１０２を介してサイト１０３〜１０５から、画像が格納されている格納場所を示すＵＲＬ等の登録情報を取得して、そのＵＲＬに従ってサーバにアクセスすることにより、アルバムや画像の選択画面を表示することができる。特に、上記のＭＦＰ１０１では、ＰＣ等を介さずにサイトにアクセスして、アルバムや画像の選択画面を表示装置に表示させることができる。ユーザがその選択画面において印刷を所望する画像を選択すると、ＭＦＰ１０１は、印刷対象の画像データを各サイトから取得して印刷することができる。

図２は、ＭＦＰ１０１のハードウェア構成を示す図である。ＭＦＰ１０１は、操作部２０１と、カードインタフェース２０２と、読取部２０８と、記録部２０９とを有する。また、ＭＦＰ１０１は、ＣＰＵ２００と、ＲＯＭ２０３と、ＲＡＭ２０４と、不揮発性ＲＡＭ２０５と、表示部２０６と、画像処理部２１０と、圧縮／解凍部２１１と、駆動部２１２と、センサ部２１３とを有する。ＣＰＵ２００は、ＭＦＰ１０１全体を制御し、例えば操作部２０１を介して入力したユーザの指示に従ってＲＯＭ２０３に記憶されているプログラムを実行する。ＲＯＭ２０３は、ＭＦＰ１０１の制御命令プログラム等を格納する。さらに、ＭＦＰ１０１は、無線ネットワーク部２０７と有線ネットワーク部２１４とを有する。無線ネットワーク部２０７は、ＩＥＥＥ８０２．１１ａ等の規格に対応した無線ＬＡＮアクセスポイントと無線によって通信可能である。有線ネットワーク部２１４は、１００Ｂａｓｅ−ＴＸ等のより対線ケーブルを接続可能なＥｔｈｅｒｎｅｔ（登録商標）コネクタを有している。

図１に示すリレーサーバ１０２や各サイト１０３〜１０５には、一般的なＰＣ等の構成が用いられる。つまり、リレーサーバ１０２や各サイト１０３〜１０５は、一般的な、ＣＰＵ、ＲＯＭ、ＲＡＭ、ＨＤＤやディスプレイ等の表示部、ポインティングデバイスやキーボード等の入力部を有する。例えば、上記各装置において、ＣＰＵはハードディスクやＲＯＭ等から読み込まれたプログラムをＲＡＭに展開して実行する。ＨＤＤは、各種フローチャートに示される処理を実行するプログラムや画像データを格納する。ディスプレイは、ユーザインタフェース等を表示し、ユーザは、ポインティングデバイスやキーボード等を用いてユーザインタフェース上で操作し、各種指示を入力することができる。

［写真共有サイト］
リレーサーバ１０２のアプリケーション構成を説明する前に、Ｗｅｂサービスの１つである写真共有サイト機能について説明する。各サイト１０３〜１０５によりＷｅｂサービスとして提供される写真共有サイト機能は、主に、ＰＣのブラウザで閲覧されることを想定している。また、ユーザはアカウントを取得し、そのアカウントとパスワードとをセットとして登録してからＷｅｂサービスを利用する。

図４は、写真共有サイト機能について、各サイト１０３〜１０５で登録されているデータ構成の一例を示す図である。各サイト１０３〜１０５に登録される画像は、アルバムという単位で纏められている。例えば、図４に示すように、各サイトには、アルバムが５つ登録されている。また、アルバム１及び２には、それぞれ３つの画像が登録されている。また、アルバム３には１つの画像が登録され、アルバム４には４つの画像が登録され、アルバム５には２つの画像が登録されている。さらに、各アルバムには、そのアルバムを代表するサムネイル画像の他、アルバムのタイトルや、アルバム登録日等も含まれており、写真共有サイト機能を用いるためのブラウザ上に表示される。ユーザは、表示されたアルバムリストから１つのアルバムを選択すると、選択されたアルバムに登録された１つ以上の画像を閲覧することができる。

以上のような写真共有サイト機能は、ＰＣのブラウザからのみ利用可能というわけではない。例えば、公開された各サイト１０３〜１０５のＡＰＩを用いることによって、ブラウザを実装する装置以外の装置（ＭＦＰ等）からもＷｅｂサービスを利用することができる。

図５は、リレーサーバ１０２がＡＰＩを利用して各サイト１０３〜１０５から取得した、アルバムリストの記述例を示す図である。アルバムリストは、例えばＸＭＬで記述される。図５に示すように、タグ「＜ｔｏｔａｌ Ｒｅｓｕｌｔｓ＞」から、アルバム数が１０であることが確認できる。また、各アルバムの情報として、タグ「＜ｅｎｔｒｙ＞」ごとに、画像のＵＲＬ、サムネイル画像のＵＲＬ、ＩＤ、撮影日などが記述されている。

ＭＦＰ１０１は、ネットワーク通信機能によってリレーサーバ１０２のＡＰＩに対応することができる。ＭＦＰ１０１は、各サイト１０３〜１０５から情報を取得する際に、各サイト１０３〜１０５のＡＰＩに直接、情報要求を発行しない。ＭＦＰ１０１は、まず、リレーサーバ１０２との間で定義されたＡＰＩを用いてリレーサーバ１０２とＨＴＴＰのＰＯＳＴ通信を利用してリレーサーバ１０２に対して情報要求を発行する。

リレーサーバ１０２とＭＦＰ１０１との間でのＡＰＩは、例えば下記のように定義される。

・ＡＰＩ−Ｒ１（コンディションチェック）：ＭＦＰ１０１の仕向け情報及びインターネット上のＩＰアドレスによって各サイトに接続可能かを確認する際に用いられる。

・ＡＰＩ−Ｒ２（ログイン認証）：各サイトとの認証が可能かを判定する際に用いられる。

・ＡＰＩ−Ｒ３（アルバムリスト要求）：全アルバムのリストを取得する際に用いられる。

・ＡＰＩ−Ｒ４（画像リスト要求）：アルバムに登録されている全画像のリストを取得する際に用いられる。

ＭＦＰ１０１は、ユーザが指定したサイトに情報要求（実際は、上記のようにリレーサーバ１０２に対して情報要求を発行）することにより、当該情報要求に応じたアルバムリストや画像リストをリレーサーバ１０２から受信する。ＭＦＰ１０１は、受信したリストの該当部分から表示用のデータのＵＲＬを取得することができる。ＭＦＰ１０１は、認証及び上記リストの取得についてはリレーサーバ１０２を介して行うが、画像データ等のＵＲＬを取得した後は、各サイトから直接受信することができる。

［リレーサーバ］
リレーサーバ１０２は、ＭＦＰ１０１が各サイト１０３〜１０５から情報を取得する場合に、ＡＰＩ変換機能を用いて仲介する役割を果たす。リレーサーバ１０２は、ＭＦＰ１０１との関係においてＷｅｂサーバとして機能し、各サイト１０３〜１０５との関係においては、Ｗｅｂクライアントとして機能する。

図３は、リレーサーバ１０２のアプリケーション構成を示す図である。本実施例において、リレーサーバ１０２の主な機能はＡＰＩ変換機能である。リレーサーバ１０２は、ＭＦＰ１０１との間で「ＭＦＰ−ＡＰＩ」を定義している。リレーサーバ１０２は、ＭＦＰ１０１との間で定義されたＡＰＩ構成を、接続先の各サイト１０３〜１０５との間で定義されたＡＰＩ構成（「サイトＡ−ＡＰＩ」、「サイトＢ−ＡＰＩ」、「サイトＣ−ＡＰＩ」）にＡＰＩ変換する。

図６は、サイトごとに定義されているＡＰＩの一覧を示す図である。ＭＦＰ１０１が各サイトから情報を取得するためには、リレーサーバ１０２が、各サイトとの間で定義されたＡＰＩ構成を用いる必要がある。つまり、ＭＦＰ１０１が同じ情報を各サイトから取得する場合であっても、リレーサーバ１０２と各サイトとの間で定義されるＡＰＩの構成は異なる。

図７は、ＭＦＰ１０１とリレーサーバ１０２との間で定義されるＡＰＩ（ＡＰＩ-Ｒとする）と、リレーサーバ１０２と各サイトとの間で定義されるＡＰＩとの対応を示す図である。この図７により、サイトからデータを取得するために必要なＡＰＩの数は、ＭＦＰが要求するデータの種類によって異なり、また同じデータの種類であっても、接続先のサイトによっても異なることがわかる。例えば、アルバムリスト要求ＡＰＩ−Ｒ３を用いてＭＦＰ１０１があるサイトを指定して情報要求する場合に、ユーザが指定したサイトによってリレーサーバ１０２から発行するＡＰＩの種類と発行数が異なることが分かる。詳細については、後述する。

図３を参照して、リレーサーバ１０２の各機能を説明する。リレーサーバ１０２は、以下のような機能を有している。なお、リレーサーバ１０２では、この各機能に対応するプログラムがＲＯＭに記憶されており、リレーサーバ１０２のＣＰＵが、このＲＯＭに記憶されているプログラムを実行することにより、図３に示す各機能を実現できるものとする。

・パーサ機能：図５で示すような各サイトからのＸＭＬリストをパーサにより解釈する。

・フィルタ機能：各サイトから受信したデータのうち、ＭＦＰ１０１に送信する情報以外のデータを削除する。例えば、有効期限の切れたコンテンツや、指定以外のファイルタイプや、上限以上のファイルサイズの画像データ等を削除する。

・チェック機能：ＭＦＰ１０１からのコンディションチェック要求に応じて、ＭＦＰ１０１のＩＰアドレス及びＭＦＰ１０１から送信される情報に基づき、各サイトに接続可能かをチェックする。

・ＡＰＩ判定機能：各サイトごとのＡＰＩ利用回数を比較する。例えば、ＭＦＰ１０１から情報要求された場合に、その情報を取得するために必要なＡＰＩ利用回数を各サイトについて比較する。なお、本実施例では、このＡＰＩ判定機能によるＡＰＩ利用回数に基づいて、ＭＦＰ１０１とリレーサーバとの間のタイムアウト時間を決定する。このＡＰＩ利用回数は、リレーサーバ１０２からＭＦＰ１０１に通知することが可能であり、ＭＦＰ１０１は、この通知されたＡＰＩ利用回数に応じて、タイムアウト時間を決定する。

・制御機能：ＭＦＰ１０１の仕向け情報に基づき、指定するサイトを振り分ける。

本実施例においては、ＭＦＰ１０１のタイムアウト値を、各サイトに応じて設定する。以下、その処理について説明する。ＭＦＰ１０１は、まず、コンディションチェックを実行して接続可能なサイトを判定する。

［コンディションチェック］
図８は、コンディションチェックの処理の手順を示す図である。コンディションチェックは、リレーサーバ１０２と指定される各サイトとの通信状況を判定するための処理である。ＭＦＰ１０１は、リレーサーバ１０２にコンディションチェックを要求する（Ｓ８０１）。リレーサーバ１０２がＭＦＰ１０１からの要求を受信すると、ＭＦＰ１０１のＩＰアドレスに基づいて、そのＭＦＰ１０１が接続可能なサイトを特定する（Ｓ８０２）。リレーサーバ１０２は、その特定したサイトとともに、ＡＰＩ判定機能による判定結果をＭＦＰ１０１に返信する（Ｓ８０３）。ＡＰＩ判定機能による判定結果については後述する。また、リレーサーバ１０２は、コンディションチェックの要求を受信すると、テスト用のパケット等に基づき各サイトからの応答時間を確認して、ＭＦＰ１０１に返信する。例えば、実測応答時間が２３０ｍｓｅｃである場合には、その値「Ｍ」をＭＦＰ１０１に返信する。ＭＦＰ１０１は、その値Ｍを各サイトとの通信環境の判定値として、ＲＯＭ２０３等の自装置内のメモリに保存する。以下、接続候補になるサイトがサイト１０３〜１０５の３つあり、そのうちサイト１０３とサイト１０４が接続可能と判定されたとして説明する。

［ＭＦＰからのアルバムリスト／画像リスト要求例］
ＭＦＰ１０１が各サイトから画像を受信して印刷するまでの概要は以下のようである。まず、ＭＦＰ１０１は、利用可能なサイト１０３及び１０４のうち１つを選択し、そのサイト内の個人用のアルバムにアクセスするためのアカウント及びパスワードを用いて、認証確認のためのＡＰＩ−Ｒ２をリレーサーバ１０２に発行する。その後、ＭＦＰ１０１は、アルバムリストをサイトからリレーサーバ１０２経由で取得し、ユーザは、ＭＦＰ１０１上で所望するアルバムを選択する。そして、ＭＦＰ１０１は、所望のアルバムに登録されている画像リストをリレーサーバ１０２経由で取得し、ユーザは、ＭＦＰ１０１上で所望する画像を選択する。ＭＦＰ１０１は、選択された画像をサイトから受信して印刷を行う。

上記の処理の流れについて、図９及び図１０を参照して説明する。図９は、アルバムリストを取得して表示するまでの処理の手順を示す図である。ＭＦＰ１０１は、アルバムリスト要求をＡＰＩ−Ｒ３を用いてリレーサーバ１０２に発行する（Ｓ９０１）。リレーサーバ１０２は、その要求を解析してＡＰＩ変換機能によって要求先のサイトに応じたＡＰＩ要求を発行する（Ｓ９０２）。要求先のサイトは、その要求に応じて、アルバムリストをリレーサーバ１０２に対して返信する（Ｓ９０３）。Ｓ９０２及びＳ９０３において用いられるＡＰＩの構成は、各サイトにより異なる。リレーサーバ１０２は、例えば図５に示すような記述形式でアルバムリストを受信する。リレーサーバ１０２は、ＸＭＬをパースしてアルバムリストをＭＦＰ１０１に返信する（Ｓ９０４）。

ＭＦＰ１０１は、受信したアルバムリストに基づき、サイトに対して直接、ＨＴＴＰのＧｅｔ要求を発行する（Ｓ９０５）。そして、ＭＦＰ１０１は、そのサイトからサムネイル画像を受信して（Ｓ９０６）、アルバムの選択画面をＭＦＰ１０１の表示画面に表示する。ユーザは、表示されたアルバムの選択画面から、所望のアルバムを選択する（Ｓ９０７）。若しくは、ユーザがアルバムの選択対象を切り替える度に、Ｓ９０５及びＳ９０６の処理が行われても良い。

図１０は、図９に示す処理の後、印刷対象の画像を特定して印刷するまでの処理を示す図である。ＭＦＰ１０１は、アルバム画像を要求するために、ＡＰＩ−Ｒ４をリレーサーバ１０２に発行する（Ｓ１００１）。リレーサーバ１０２は、その要求を解析してＡＰＩ変換機能によって要求先のサイトに応じたＡＰＩ構成に変換し、その変換されたＡＰＩを要求先のサイトに発行する（Ｓ１００２）。サイトは、その要求に応じて、指定されたアルバム中の画像の画像リストをリレーサーバ１０２に対して返信する（Ｓ１００３）。Ｓ１００２及びＳ１００３において用いられるＡＰＩの構成は各サイトにより異なる。リレーサーバ１０２は、例えば図５に示すような記述形式で画像リストを受信する。リレーサーバ１０２は、ＸＭＬをパースして画像リストをＭＦＰ１０１に返信する（Ｓ１００４）。

ＭＦＰ１０１は、受信した画像リストからサムネイル画像のＵＲＬ情報等を取得し、サイトに対して直接、ＨＴＴＰのＧｅｔ要求を発行する（Ｓ１００５）。そして、ＭＦＰ１０１は、そのサイトからサムネイル画像を受信して（Ｓ１００６）、画像の選択画面をＭＦＰ１０１の表示画面に表示する。ユーザは、表示された画像の選択画面から所望の画像を選択する（Ｓ１００７）。若しくは、ユーザが画像の選択対象を切り替える度に、Ｓ１００５及びＳ１００６の処理が行われても良い。ユーザにより所望の画像が選択されて印刷が指示されると、ＭＦＰ１０１は、印刷対象の画像データを取得するために、サイトに対して直接、ＨＴＴＰのＧｅｔ要求を発行し（Ｓ１００８）、サイトから印刷対象の画像データを受信する（Ｓ１００９）。ＭＦＰ１０１は、受信した印刷対象の画像データを展開して記録媒体に印刷する（Ｓ１０１０）。

［各サイトについてのＡＰＩ構成］
上記の一連の処理において、アルバムリストや画像リスト取得のためにリレーサーバ１０２から各サイトに対して発行するＡＰＩの利用回数（発行されるＡＰＩコマンド数）が異なる。また、その相違に伴い、ＭＦＰ１０１がサイトに情報を要求して取得するまでの応答時間も、各サイトによって異なる。以下、例を挙げて説明する。

図１１は、アルバムリストの要求をサイト１０３に対して発行した場合に、サイト１０３に対してリレーサーバ１０２が発行するＡＰＩの利用回数を説明するための図である。リレーサーバ１０２は、サイト１０３に対して認証のためのＡＰＩ−Ａ１を発行し（Ｓ１１０１）、次に、アルバムリストの取得のためのＡＰＩ−Ａ２を発行する（Ｓ１１０２）。つまり、リレーサーバ１０２は、アルバムリスト取得までサイト１０３に対して、ＡＰＩを２回発行する。

図１２は、アルバムリストの要求をサイト１０４に対して発行した場合に、サイト１０４に対してリレーサーバ１０２が発行するＡＰＩの利用回数を説明するための図である。リレーサーバ１０２は、サイト１０４に対して認証を開始する条件確認のためのＡＰＩ−Ｂ１、ＡＰＩ−Ｂ２、ＡＰＩ−Ｂ３を発行する（Ｓ１２０１〜Ｓ１２０３）。その後、リレーサーバ１０２は、認証のためのＡＰＩ−Ｂ４を発行する（Ｓ１２０４）。リレーサーバ１０２は、認証成功後、アルバムリスト取得のためのＡＰＩ−Ｂ５を発行する（Ｓ１２０５）。さらに、リレーサーバ１０２は、サイト１０４に対して、アルバムリストに含まれる各アルバムごとに、タイトルや撮影日等の情報取得のためのＡＰＩ−Ｂ６を発行する（Ｓ１２０６）。さらに、リレーサーバ１０２は、各アルバムごとに、アルバムに設定されている代表画像としてのサムネイル画像のＵＲＬ等の情報を取得するためのＡＰＩ−Ｂ７を発行する（Ｓ１２０７）。例えば、図４に示すように、アルバムが５つ設定されている場合には、Ｓ１２０６及びＳ１２０７において各５回ＡＰＩを利用するので、リレーサーバ１０２は、計１５回のＡＰＩ要求をサイト１０４に対して発行することになる。

図１１に示す手順によって、ＭＦＰ１０１が図４に示すアルバムリストを要求してからリレーサーバ１０２からアルバムリストを受信するまでの応答時間は１秒程度であった。一方で、図１２に示す手順によって、ＭＦＰ１０１が図４に示すアルバムリストを要求してからリレーサーバ１０２からアルバムリストを受信するまでの応答時間は１０秒程度であった。

このように、ユーザは、同じアルバムリストを異なるサイトから取得する場合に、各サイトに対して発行されるＡＰＩの構成が異なるので、応答時間に差が生じてしまう。本実施例においては、上述のＡＰＩの構成やコンディションチェック時の各サイトへの通信時間等の通信条件に応じて、各サイトに対するタイムアウト値を調整する。

［タイムアウト値設定方法］
図１３は、本実施例におけるタイムアウト値設定処理の手順を示すフローチャートである。図１３に示す処理は、例えば、ＣＰＵ２００がＲＡＭ２０４をワークメモリとしてＲＯＭ２０３に記憶されているプログラムを実行することにより実行される。本実施例においては、ＭＦＰ１０１とリレーサーバ１０２との間のコンディションチェックの結果を利用してタイムアウト値を設定する。上記のように、Ｗｅｂサーバのコンディションチェックにより、Ｗｅｂサーバ１０３〜１０５のそれぞれの応答時間を取得することができる。また、コンディションチェックを実行するタイミングであるが、図１３に示す処理を実行するときに実行してもよいが、予めコンディションチェックを行っていてもよい。この場合、コンディションチェックの結果である実測応答時間ＭがＲＯＭ２０３に記憶されているため、タイムアウト時間を決定するタイミングでこの実測応答時間ＭをＲＯＭ２０３から読み出して取得してもよい。

また、図１３において説明するタイムアウト時間の決定処理を実行するタイミングであるが、ＭＦＰ１０１は、各サイトに対する情報要求をリレーサーバ１０２に発行する直前に、タイムアウト値を設定する。

まず、ＣＰＵ２００は、Ｓ１３０１において、通信環境について判定を行う。Ｓ１３０１の判定においては、図１４に示す判定テーブルを利用する。ＭＦＰ１０１がリレーサーバ１０２にコンディションチェックを行なった際の実測応答時間Ｍを、予め定められた通信環境の基準値（例えば、２００［ｍｓｅｃ］）と比較する。本実施例ではまず、実測応答時間Ｍを基準値２００［ｍｓｅｃ］で除算して比率を求める。例えば、Ｍの値が２３０［ｍｓｅｃ］であるとすると、その比率は「１．１５」となる。そして、図１４に示すテーブルが参照される。本例においては、上段から２番目に該当するので、通信判定値は「＊１．１」と求められる。後述するが、本実施例では、Ｓ１３０１で取得した通信判定値に応じてタイムアウト時間の補正を行う。

次に、ＣＰＵ２００は、Ｓ１３０２において、サービスＡＰＩを判定する。図１５は、サービスＡＰＩの判定処理の手順を示すフローチャートである。以下、例えば、ＭＦＰ１０１がアルバム数５、アルバム上の画像数５０であるアルバム情報リストを各サイトから取得する場合について説明する。

まず、ＣＰＵ２００は、Ｓ１５０１において、ＡＰＩ判定機能を用いて判定する。サイト１０３については、図１１に示すように、１つのアルバムリスト取得までにＡＰＩを２回利用している。また、サイト１０４については、１つのアルバムリスト取得までにＡＰＩを７回利用している（認証で４回、データ取得で３回）。また、サイト１０５については、例えば、図６に示すようにＡＰＩが用いられるとすると、アルバムリスト取得までにＡＰＩを１回利用する。本実施例においては、１つのアルバムリスト取得までの、複数のＷｅｂサーバにおける最低のＡＰＩ利用回数を基準として、各ＷｅｂサーバにおけるＡＰＩ利用回数の比率を判定結果としている。このとき、サイト１０５におけるＡＰＩ利用回数「１」が最低の利用回数となる。よって、ＡＰＩ利用回数の比率は、サイト１０３については２回／１回＝２となり、サイト１０４については７回／１回＝１５となり、サイト１０５については１回／１回＝１となる。即ち、ＭＦＰにより利用される複数のサイトのそれぞれの、ＡＰＩの利用回数の比率により、ＡＰＩ利用状況を複数のサイトにおいて相対的に評価する。この比率が高いほど、データを取得するために必要なＡＰＩの数が多く、データを取得するために必要な時間が長くなると判断することができる。なお、ＡＰＩ判定機能の判定結果として、上記のような比率の他に、各ＡＰＩの処理時間や処理内容を考慮した値が用いられても良い。

次に、ＣＰＵ２００は、Ｓ１５０２において、要求数補正処理を行う。これは、１つのサイトのＡＰＩ構成について、情報の要求数によってＡＰＩを利用する回数が異なる場合に行われる。即ち、例えばＭＦＰ１０１においてユーザにより指定されたアルバムの数が複数であった場合、サイトによっては、その複数のアルバムのそれぞれに対して同数のＡＰＩを用いる必要がない場合がある。このような場合に、１つのアルバム取得に必要なＡＰＩの数を、単純にアルバム数で乗算するのではなく、各アルバムを取得するためのＡＰＩの数を考慮してＡＰＩ使用回数を算出する。

以下、サイト１０４について説明する。サイト１０４は、図６に示すように、最初のアルバムのアルバム情報を取得するためにＡＰＩを３回（（ＡＰＩ−Ｂ５〜ＡＰＩ−Ｂ７）呼び出す必要があるが、２つ目のアルバム以降は、１つのアルバム情報取得のために、ＡＰＩを２回（ＡＰＩ−Ｂ６及びＡＰＩ−Ｂ７）呼び出す必要がある。例えば、サイト１０４から５つのアルバム情報を取得する場合、最初の１アルバムの時のＡＰＩ３回（ＡＰＩ−Ｂ５〜ＡＰＩ−Ｂ７）に対して、追加の４アルバム分について、各２回（ＡＰＩ−Ｂ６及びＡＰＩ−Ｂ７）増える。つまり、合計ＡＰＩ利用回数は１１回になる。本実施例においては、２回目以降の情報の取得のために必要なＡＰＩの数を補正とする。よってサイト１０４では、補正値は「２」となる。一方、サイト１０３の場合には、情報の要求数によってＡＰＩを利用する回数は変わらないので、補正値は「０」となる。

次に、Ｓ１５０３において、ＡＰＩ補正値を決定する。上述のように、例えばサイト１０４の場合には、ＡＰＩ判定値は「７」であり、補正値は「２」である。従って、アルバム数５、アルバム上の画像数５０であるアルバム情報リストを取得する場合には、ＡＰＩ判定値は「７」で、追加の４アルバム分の補正値は「８（＝４×２）」となる。つまり、サイト１０４に５アルバムを要求する場合に、ＡＰＩ補正値は「１５（＝７＋８）」と決定される。

再び、図１３を参照する。ＣＰＵ２００は、Ｓ１３０３において、タイムアウト値を設定する。図１６は、タイムアウト値の設定処理の手順を示すフローチャートである。まず、ＣＰＵ２００は、Ｓ１６０１において、予め定められた初期タイムアウト値を取得する。ここでは、初期タイムアウト値を例えば「３０秒」とする。次に、ＣＰＵ２００は、Ｓ１６０２において、Ｓ１３０１で判定した結果の通信判定値「＊１．１」を用いて、初期タイムアウト値を補正する。例えば、上述の３０秒を１．１倍して、３３秒と補正する。これにより、上記のコンディションチェックにより取得した実測応答時間Ｍに応じて、タイムアウト時間を調整できる。つまり、アクセス先のＷｅｂサーバの通信状況がよくない場合、実測応答時間Ｍが長くなるため、このときにはタイムアウト時間が長くなるように調整される。

次に、ＣＰＵ２００は、Ｓ１６０３においては、Ｓ１３０２で決定されたＡＰＩ補正値を利用して、さらに補正を行う。ここで、サイト１０４について決定されたＡＰＩ補正値「１５」を用いるとすると、上記３３秒にＡＰＩ補正値１５を乗算して４９５秒を算出する。これにより、アクセス先のＷｅｂサーバからデータを取得するために必要なＡＰＩの数に応じて、タイムアウト時間を調整する。つまり、ＡＰＩの使用回数が多い場合、タイムアウト時間がより長くなるよう調整される。

ＣＰＵ２００は、Ｓ１６０４において、接続先サイトと情報要求数を確定して、リレーサーバ１０２に情報要求する前にタイムアウト値（ここでは、４９５秒）を設定する。このタイムアウト値は、ＭＦＰ1１０１とリレーサーバ１０２との間のタイムアウト時間である。そして、例えばＭＦＰ１０１がリレーサーバ１０２に情報を要求してから、この設定されたタイムアウト時間が経過してもＷｅｂサーバからデータを取得できない場合に、ＭＦＰ１０１においてタイムアウトとなる。

上述した例では、サイト１０４に５つのアルバム情報を要求する場合には、４９５秒のタイムアウト値が設定される。本例においては、初期タイムアウト値「３０秒」に実測応答時間に関する係数「１．１」と、要求するデータ量に応じたＡＰＩコマンド数に関する係数「１５」とを乗じて「４９５秒」を算出している。

以上のように、本実施例では、ＭＦＰ１０１がリレーサーバ１０２を介してＷｅｂサーバにアクセスするときの通信条件に応じて、ＭＦＰ１０１とリレーサーバ１０２との間のタイムアウト時間を決定した。また、その通信条件の算出方法として、コンディションチェックにおいて計測された実測応答時間と、ＭＦＰ１０１から要求するデータ量に応じたＡＰＩコマンド数とに応じて算出した。

このように算出したタイムアウト時間を、ＭＦＰ１０１やリレーサーバ１０２に設定することにより、ＭＦＰ１０１のアクセス先に応じた適切な時間で、タイムアウトとなる。例えばＭＦＰ１０１が、応答時間の短いアクセス先にアクセスして、そのアクセス先からデータを取得できない場合に、応答時間の長いアクセス先にアクセスした場合に比べて、短い時間でタイムアウトとなる。よって、ＭＦＰ１０１のユーザが、必要以上に長い時間を待たなくても適切にタイムアウトになり、そのユーザは、当該アクセス先から適切にデータを取得するための操作や、他の操作を行うことができる。

また、本実施例では、タイムアウト時間の算出方法として、初期タイムアウト値を、通信条件やＡＰＩコマンド数に応じて変更する例を示した。しかしこれに限るものではなく、例えば、通信条件とＡＰＩコマンド数に対応するタイムアウト時間を示すテーブルを、ＲＯＭ２０３に記憶しておき、このテーブルに従ってタイムアウト値を設定してもよい。さらに、上記の初期タイムアウト値は、ＲＯＭ２０３に予め記憶されているものを用いてもよいし、ユーザが指定できるようにしてもよい。

〔実施例２〕
図１７は、本実施例におけるタイムアウト値設定処理の手順を示すフローチャートである。本実施例では、ＭＦＰ１０１のアクセス先に応じて、予めタイムアウト値が設定されている例を示す。

まず、ＣＰＵ２００は、Ｓ１７０１において、予め定められた初期タイムアウト値を取得する。例えば、初期タイムアウト値を「３０秒」とする。次に、ＣＰＵ２００は、Ｓ１７０２において、情報を取得する先のサイトを特定する。ここでは、例えば、サイト１０４が特定されるとする。

次に、ＣＰＵ２００は、Ｓ１７０３において、図１８に示すテーブルを参照して、対応する接続サイトに応じたタイムアウト値を取得する。図１８に示すテーブルは、ＲＯＭ２０３に格納されており、サイトごとに予めＡＰＩの構造的特性を考慮してタイムアウト値が予め設定されている。例えば、サイト１０４に対応するタイムアウト値は、６００秒と設定されている。ＣＰＵ２００は、Ｓ１７０４において、取得したタイムアウト値「６００秒」をタイムアウト値として決定し、リレーサーバ１０２に情報要求する前にタイムアウト値（ここでは、６００秒）を設定する。

本実施例では、ＭＦＰ１０１のアクセス先に応じて、予めタイムアウト値が設定されているため、タイムアウト時間を簡単な処理で設定することができる。

また、実施例１で示したように、アクセス先のタイムアウト時間を算出して、実施例２で示した図１８に示すテーブルに、そのタイムアウト時間を追加する。例えば、クライアント装置に新たなアプリケーションがインストールされたときに、そのアプリケーションにおいてアクセスするアクセス先のタイムアウト時間を、実施例１に示したように算出する。そして、そのアクセス先と、タイムアウト時間を図１８のテーブルに追加する。上記の新たにインストールされたアプリケーションにアクセスするときには、図１８のテーブルを利用することができる。

なお、以上の実施例では、複数のＷｅｂサーバのそれぞれがＷｅｂサービスを提供しており、Ｗｅｂサービスに応じてＭＦＰ１０１がアクセスするＷｅｂサーバによって、ＭＦＰ１０１とリレーサーバ１０２の間のタイムアウト時間を設定していた。しかし、本発明は、１つのＷｅｂサーバにおいて複数のＷｅｂサービスを提供するシステムにおいても応用できるものである。その１つのサーバでは、複数のアクセス先（ＵＲＬ等）が設定されており、そのアクセス先により異なるサービスを提供する。このようなシステムにおいても、アクセス先によってデータの取得時間が異なる場合があり、即ちユーザが使用するサービスによってデータの取得時間が異なる場合がある。よって、上記の実施例を用いて、１つのサーバにおける複数のアクセス先のうち、ユーザが利用するＷｅｂサービスに対応するアクセス先に応じて、クライアント装置とリレーサーバの間のタイムアウト時間を設定してもよい。

また、以上の実施例は、クライアント装置がリレーサーバを介してＷｅｂサーバからデータを取得する場合に限らず、Ｗｅｂサーバにデータを送信する場合においても適用できるものである。即ち、クライアント装置がリレーサーバを介してＷｅｂサーバにデータをアップロードするときの、クライアント装置とリレーサーバ間のタイムアウト時間を設定する場合であってもよい。

そのように、クライアント装置からＷｅｂサーバにデータをアップロードするときにも、ＡＰＩコマンド数に応じてタイムアウト時間を算出する。このときにも、アップロードするデータの種類やデータ量に応じて、ＡＰＩコマンド数を算出する。

さらに、以上の実施例では、クライアント装置であるＭＦＰ１０１がタイムアウト時間を決定する処理を行っていたが、本発明はこれに限らず、リレーサーバがこの決定処理を実行してもよい。さらに、以上の実施例では、Ｗｅｂサーバと通信を行うクライアント装置として、ＭＦＰを例に説明したが、クライアント装置はこれに限らず、例えばＰＣであってもよいし、携帯電話やデジタルカメラであってもよい。

本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。また、上記の処理を１つのプロセッサにより実行する場合に限らず、複数のプロセッサにより実行する場合であってもよい。

Claims (14)

1. Ｗｅｂサーバおよび情報処理装置と通信可能なリレーサーバであって、
   前記情報処理装置からの要求を受信し、当該要求に応じて前記Ｗｅｂサーバが提供する複数のアクセス先のいずれかと通信し、当該通信により当該複数のアクセス先のいずれかから受信した情報を前記情報処理装置に送信する送信手段と、
   前記リレーサーバが前記Ｗｅｂサーバと通信するときの前記複数のアクセス先のそれぞれと前記リレーサーバとの間の通信条件として、前記リレーサーバが前記Ｗｅｂサーバと通信するためのＡＰＩコマンド数を取得する取得手段と、
   前記複数のアクセス先のうちの、前記情報処理装置が情報の受信を要求するアクセス先に対応する前記取得手段により取得された前記ＡＰＩコマンド数に応じたタイムアウト時間に従って、前記送信手段による前記情報処理装置と前記リレーサーバとの間の通信がタイムアウトされるように制御する制御手段と、
   を備えることを特徴とするリレーサーバ。
2. 前記取得手段は、前記リレーサーバと前記Ｗｅｂサーバとにおいて通信されるデータに応じた前記ＡＰＩコマンド数を取得することを特徴とする請求項１に記載のリレーサーバ。
3. 前記取得手段はさらに、前記情報処理装置が情報の受信を要求するアクセス先との通信環境を特定するための情報を取得し、
   前記制御手段は、当該取得した通信環境を特定するための情報により特定される通信環境と前記ＡＰＩコマンド数とに応じて、タイムアウト時間を決定することを特徴とする請求項１又は２に記載のリレーサーバ。
4. 前記取得手段は、前記情報処理装置が情報の受信を要求するアクセス先と通信することにより、前記通信環境を特定するための情報を取得することを特徴とする請求項３に記載のリレーサーバ。
5. 前記Ｗｅｂサーバは、複数の画像を格納しており、
   前記送信手段は、前記Ｗｅｂサーバが提供する複数のアクセス先のいずれかから、前記Ｗｅｂサーバに格納されている前記複数の画像を特定するための情報を取得し、当該取得した前記複数の画像を特定するための情報を前記情報処理装置に送信することを特徴とする請求項１乃至４のいずれか１項に記載のリレーサーバ。
6. 前記Ｗｅｂサーバにおいて、前記複数の画像が複数のアルバムに分類されており、
   前記送信手段は、前記Ｗｅｂサーバが提供する複数のアクセス先のいずれかから、前記Ｗｅｂサーバにおいて分類されている前記複数のアルバムを特定するための情報を取得し、当該取得された前記複数のアルバムを特定するための情報を前記情報処理装置に送信することを特徴とする請求項５に記載のリレーサーバ。
7. 前記情報処理装置は、画像を印刷する印刷装置であり、
   前記情報処理装置は、前記送信手段により送信された情報に従って前記Ｗｅｂサーバから画像を取得し、当該取得された画像を印刷することを特徴とする請求項５又は６に記載のリレーサーバ。
8. 前記送信手段は、前記Ｗｅｂサーバに格納されている前記複数の画像に対応するＵＲＬを含む情報を前記情報処理装置に送信し、
   前記情報処理装置は、前記ＵＲＬに従って、前記リレーサーバを介さずに前記Ｗｅｂサーバにアクセスすることで画像を取得することを特徴とする請求項７に記載のリレーサーバ。
9. 前記情報処理装置は、前記送信手段により送信された情報に従って前記Ｗｅｂサーバから複数のサムネイル画像を取得し、当該取得された複数のサムネイル画像のうちのユーザにより選択されたサムネイル画像に対応する画像を前記Ｗｅｂサーバから取得し、当該取得された画像を印刷することを特徴とする請求項５乃至８のいずれか１項に記載のリレーサーバ。
10. 前記Ｗｅｂサーバは、複数のサーバ装置を含み、
    前記複数のサーバ装置が前記複数のアクセス先を提供することを特徴とする請求項１乃至９のいずれか１項に記載のリレーサーバ。
11. 前記Ｗｅｂサーバとしての１つのサーバ装置が前記複数のアクセス先を提供することを特徴とする請求項１乃至９のいずれか１項に記載のリレーサーバ。
12. Ｗｅｂサーバおよび情報処理装置と通信可能なリレーサーバの制御方法であって、
    前記情報処理装置から、前記Ｗｅｂサーバが提供する複数のアクセス先のいずれかから情報を受信する要求を受信する受信工程と、
    前記リレーサーバが前記Ｗｅｂサーバと通信するときの前記複数のアクセス先のそれぞれと前記リレーサーバとの間の通信条件として、前記リレーサーバが前記Ｗｅｂサーバと通信するためのＡＰＩコマンド数を取得し、前記リレーサーバが、前記受信工程において受信された要求に応じて前記複数のアクセス先のいずれかから受信した情報を前記情報処理装置に送信するときの、前記情報処理装置と前記リレーサーバとの間の通信が、前記情報処理装置が情報の受信を要求するアクセス先に対応する当該取得された前記ＡＰＩコマンド数に応じたタイムアウト時間に従って、タイムアウトされるように制御する制御工程と、
    を有することを特徴とする制御方法。
13. Ｗｅｂサーバと通信可能なリレーサーバと、前記リレーサーバと通信可能な情報処理装置を含む情報処理システムであって、
    前記情報処理装置は、
    前記Ｗｅｂサーバが提供する複数のアクセス先のいずれかからの情報の受信を、前記リレーサーバに要求する要求手段を備え、
    前記リレーサーバは、
    前記要求手段による要求に応じて前記Ｗｅｂサーバが提供する複数のアクセス先のいずれかと通信し、当該通信により当該複数のアクセス先のいずれかから受信した情報を前記情報処理装置に送信する送信手段と、
    前記リレーサーバが前記Ｗｅｂサーバと通信するときの前記複数のアクセス先のそれぞれと前記リレーサーバとの間の通信条件として、前記リレーサーバが前記Ｗｅｂサーバと通信するためのＡＰＩコマンド数を取得し、前記複数のアクセス先のうちの、前記情報処理装置が情報の受信を要求するアクセス先に対応する当該取得された前記ＡＰＩコマンド数に応じたタイムアウト時間に従って、前記送信手段による前記情報処理装置と前記リレーサーバとの間の通信がタイムアウトされるように制御する制御手段とを備える、
    ことを特徴とする情報処理システム。
14. 請求項１乃至１１のいずれか１項に記載のリレーサーバが備える各手段としてコンピュータを機能させるためのプログラム。

Images