JP2020021252A - 中継装置、制御方法、及び、プログラム - Google Patents

Abstract

【課題】通信を用いたシステムの柔軟な運用を可能とすること。【解決手段】サービスを提供するサーバとそのサービスを受ける端末との通信を中継する中継装置は、第１の通信プロトコルに従って端末へ信号を送信する第１の通信装置と、第１の通信プロトコルと異なる第２の通信プロトコルに従って端末から信号を受信すると共に、サーバと通信を行う第２の通信回路と、を使用する。【選択図】 図１

Description

本発明は、拡張性を向上させるための通信ネットワークの構成技術に関する。

近年、インターネット等のネットワークを通じて提供されるサービスが増加し、それに伴って、ネットワーク接続可能な端末（クライアント端末）も急激に増加している。サービスによっては、それらの端末を管理するための中継サーバが設置され、その中継サーバを通じてサービスが提供される。例えば、クライアント端末がインクジェット方式の印刷装置であり、ユーザがクラウドサービスによってネットワーク上に保存された写真等のデータを、そのクライアント端末を用いて印刷する場合について説明する。この場合、クラウドサービスにおけるサービス提供サーバから、中継サーバである管理サーバを通じて、印刷命令がクライアント端末に通知され、その印刷命令によってクライアント端末が印刷を実行する。

このようなサービスをリアルタイムに実行するには、サービス提供サーバと、中継サーバと、クライアント端末とが、相互に通信可能な状態である必要がある。なお、クライアント端末と中継サーバとの間の通信には、ＸＭＰＰやＭＱＴＴ等のプロトコルが用いられる。なお、ＸＭＰＰは、Ｅｘｔｅｎｓｉｂｌｅ Ｍｅｓｓａｇｅｉｎｇ ａｎｄ Ｐｒｅｓｅｎｃｅ Ｐｒｏｔｏｃｏｌを表し、ＭＱＴＴは、Ｍｅｓｓａｇｅ Ｑｕｅｕｉｎｇ Ｔｅｌｅｍｅｔｒｙ Ｔｒａｎｓｐｏｒｔを表す。特許文献１には、ＸＭＰＰを利用して、クライアント端末がインターネット上のサーバと通信する手順が記載されている。

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

ＸＭＰＰサーバには、拡張性が乏しいという課題がある。このため、上述のようなシステムにおいて、ＸＭＰＰサーバへ接続される端末の急激な増加や、新たなサービスを提供するための新規サーバの既存システムへの追加が容易でないという課題があった。なお、ＸＭＰＰに限らず、所定の通信プロトコルを用いたサービスにおいて、その通信プロトコルを用いる端末やサービスの増大に対して、拡張などの柔軟な運用ができることが重要である。

本発明は、かかる課題に鑑みなされたものであり、通信を用いたシステムの柔軟な運用を可能とする技術を提供する。

上述のような課題を解決するため、本発明の中継装置は、サービスを提供するサーバと当該サービスを受ける端末との通信を中継する中継装置であって、第１の通信プロトコルに従って前記端末へ信号を送信する第１の通信手段と、前記第１の通信プロトコルと異なる第２の通信プロトコルに従って前記端末から信号を受信すると共に、前記サーバと通信を行う第２の通信手段と、を有する。

本発明によれば、通信を用いたシステムの柔軟な運用が可能となる。

情報処理システムの構成例を示す図である。 第１通信モジュールの構成例を示す図である。 中継サーバを介するサービスサーバからクライアント端末への信号送信時の通信の流れの例を示すシーケンス図である。 図３の通信のプロトコルスタックを概略的に説明する図である。 中継サーバを介するクライアント端末からサービスサーバへの信号送信時の通信の流れの例を示すシーケンス図である。 図５の通信のプロトコルスタックを概略的に説明する図である。 中継サーバを介するサービスサーバからクライアント端末への信号送信時の通信の流れの例を示すシーケンス図である。 図７の通信のプロトコルスタックを概略的に説明する図である。 中継サーバを介するクライアント端末からサービスサーバへの信号送信時の通信の流れの例を示すシーケンス図である。 図９の通信のプロトコルスタックを概略的に説明する図である。 情報登録処理の流れの例を示すフローチャートである。 登録される情報の例を示す図である。 クライアント端末と中継サーバとの間の通信セッションが確立されてから通信を行う処理の流れの例を示すフローチャートである。 情報処理システムの別の構成例を示す図である。

以下、図面を参照しながら本発明の実施の形態について説明する。なお、以下の実施形態は、本発明の技術的特徴について例を通じて説明するものであり、説明する実施形態の内容に本発明を限定することは意図されていない。すなわち、説明される技術的に特徴の一部または全部が、同様の技術的特徴を実現可能な他の構成と置き換えられてもよい。例えば、複数の機能ブロックや方法のステップが１つの機能ブロックや１つの方法のステップとしてまとめられてもよいし、１つの機能ブロックや方法のステップが、複数の機能ブロックや複数の方法のステップに分割されてもよい。また、必要に応じて、機能ブロックや方法のステップの少なくとも一部が省略されてもよい。

（システム構成）
本実施形態に係る情報処理システムの構成例を、図１に示す。本情報処理システムは、クライアント端末１００、中継サーバ２００、及びサービスサーバ３００を含んで構成される。なお、図１では、クライアント端末１００、中継サーバ２００、及びサービスサーバ３００がそれぞれ１台存在する場合について説明しているが、これらの装置はそれぞれ２台以上存在してもよい。また、複数のサービスサーバ３００が存在する場合、これらのサービスサーバ３００は、それぞれ異なるサービスを提供しうる。

クライアント端末１００は、ユーザが利用する端末であり、サービスサーバ３００は、ユーザに対して、印刷対象の画像情報の提供やクライアント端末１００によってスキャンされた画像の蓄積等の所定のサービスを提供するサーバである。また、中継サーバ２００は、クライアント端末１００とサービスサーバ３００との間で、サービスに関する通信を中継する。すなわち、クライアント端末１００が中継サーバ２００と接続し、中継サーバ２００がサービスサーバ３００と接続して、中継サーバ２００は、クライアント端末１００とサービスサーバ３００との間のサービスに関する通信を中継する。ユーザは、これにより、クライアント端末１００を介して、サービスサーバ３００からのサービスの提供を受けることができる。

クライアント端末１００と中継サーバ２００、及び、中継サーバ２００とサービスサーバ３００は、それぞれ、ネットワーク４００を介して（例えばインターネット上のルータを介して）接続される。なお、クライアント端末１００と中継サーバ２００との間のネットワークと、中継サーバ２００とサービスサーバ３００との間のネットワークとに対して同じ参照番号が付されているように共通のネットワークが使用されうるが、これに限られない。例えば、それぞれのネットワークが、別個のネットワークセグメントに属するなど、相異なる２つのネットワークが用いられてもよい。ただし、いずれの場合であっても、本実施形態では、クライアント端末１００は、サービスサーバ３００に直接接続するのではなく中継サーバ２００と接続し、中継サーバ２００を介してサービスサーバ３００に接続するものとする。

このようなシステムでは、上述のように、クライアント端末１００と中継サーバ２００との間の通信にＸＭＰＰ（Ｅｘｔｅｎｓｉｂｌｅ Ｍｅｓｓａｇｅｉｎｇ ａｎｄ Ｐｒｅｓｅｎｃｅ Ｐｒｏｔｏｃｏｌ）が使用される。なお、ＸＭＰＰに代えて、ＭＱＴＴ（Ｍｅｓｓａｇｅ Ｑｕｅｕｉｎｇ Ｔｅｌｅｍｅｔｒｙ Ｔｒａｎｓｐｏｒｔ）が使用されてもよい。中継サーバ２００は、ＸＭＰＰによる通信のためにＸＭＰＰサーバ機能を有し、１つ以上のクライアント端末１００とＸＭＰＰによる通信をこのＸＭＰＰサーバ機能を用いて実行する。このとき、上述のように、ＸＭＰＰサーバは、クライアント端末１００の急激な増加や、新規サービスのためのサービスサーバ３００の追加などの柔軟な運用が容易ではない場合がある。

このため、本実施形態では、クライアント端末１００が信号の送信側である場合と、クライアント端末１００が信号の受信側である場合とで、異なるプロトコルスタックを用いて通信を行う。例えば、クライアント端末１００が信号の送信側である場合にはＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）等の処理負荷の小さい通信プロトコルを用い、クライアント端末１００が信号の受信側である場合にはＸＭＰＰを用いる。これにより、中継サーバ２００のＸＭＰＰサーバ機能が実行する処理を、クライアント端末１００への信号送信に限定することで、そのＸＭＰＰサーバ機能の負荷を抑制する。一方で、クライアント端末１００が信号の送信側である場合の通信や、サービスサーバ３００との間の通信には、ＸＭＰＰより処理負荷の低い通信プロトコル（例えばＨＴＴＰ）を利用することで、中継サーバ２００の負荷を低減する。これにより、クライアント端末１００が急激に増加しても、ＸＭＰＰサーバの負荷を低減することができる。さらに、中継サーバ２００を、ＨＴＴＰ等の第１の通信プロトコルを利用するサーバと、ＸＭＰＰ等の第２の通信プロトコルを利用するサーバとを別個のサーバとすることにより、さらなる柔軟な運用が可能となる。すなわち、中継サーバ２００は、例えばローカルエリアネットワーク（ＬＡＮ）内に、例えば機能ごとに分離された、複数のサーバからなるサーバ群として構成されうる。機能ごとに別個のサーバを使用することによって、それらの別個のサーバごとにシステム運用により適した構成となるようなアップデート等を行うことで、より柔軟な運用が可能となる。なお、中継サーバ２００は、物理的には複数のサーバからなるサーバ群によって構成されていても、論理的には、例えばクライアント端末１００やサービスサーバ３００から１つの中継装置として認識されうる。

続いて、各装置の構成について説明する。

クライアント端末１００は、一例として、第１通信モジュール１１０、表示装置１０１、入力装置１０２、出力装置１０３、ＲＯＭ１０４、制御プログラム１０５、ＲＡＭ１０６、ＣＰＵ１０７を含んで構成される。ＲＯＭはＲｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ（読み出し専用メモリ）の、ＲＡＭはＲａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ（ランダムアクセスメモリ）の、ＣＰＵはＣｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ（中央演算処理装置）の、頭字語である。

第１通信モジュール１１０は、クライアント端末１００が外部の装置（例えば中継サーバ２００）と通信を行うための機能部である。第１通信モジュール１１０は、例えば、ＨＴＴＰを含んだプロトコルスタックで中継サーバ２００へ信号を送信し、ＸＭＰＰを含んだプロトコルスタックで中継サーバ２００から信号を受信する。すなわち、第１通信モジュール１１０は、送信と受信とで異なるプロトコルスタックが使用されるように構成される。第１通信モジュール１１０の詳細については、図２を用いて後述する。

表示装置１０１は、例えば発光パターンによって情報表示を行うランプや画面を用いて情報表示を行うディスプレイであり、ユーザがクライアント端末１００に入力した結果の情報や、各種処理が実行された結果の情報等を表示する。なお、表示装置１０１は、視覚的出力に代えて又はこれに加えて、音声等の聴覚的出力や振動出力等の各種情報出力を行うように、スピーカや振動子を含んで構成されてもよい。

入力装置１０２は、例えばキーボードやポインティングデバイス（マウス）、タッチパッド等によって構成され、ユーザ操作の受付を行い、そのユーザ操作を示す命令をクライアント端末１００内に取り込む。なお、入力装置１０２は、ユーザ操作やユーザ指示を受付可能である限り、どのような装置構成を取ってもよい。例えば、入力装置１０２は、ユーザ指示を音声で取得するマイクや、ユーザの動きを撮像してその動きによってユーザ指示を受け付けるカメラや、クライアント端末１００が振られたことを検出するセンサなどであってもよい。また、例えばタッチパネルを用いて、表示装置１０１と入力装置１０２とを１つの装置によって実現してもよい。

出力装置１０３は、入力装置１０２によって入力された命令の成果物を出力する。出力装置１０３は、例えば印刷装置であり、記録媒体（例えば紙）上にインクを吐出し、インク像が形成された記録媒体を成果物として出力する。また、出力装置１０３は、例えば外部又は内部の記憶装置に接続するインタフェイスであり、成果物を記憶装置に出力して蓄積させる。また、出力装置１０３により、これら以外の出力が行われてもよい。

ＲＯＭ１０４は、不揮発性メモリであり、例えば、クライアント端末１００が実行すべき（例えばバイナリ化された）プログラムコードを保存する。このプログラムコードの中には、制御プログラム１０５が含まれる。制御プログラム１０５は、例えば、クライアント端末１００の全体（第１通信モジュール１１０、表示装置１０１、入力装置１０２、出力装置１０３、及びＲＡＭ１０６）を制御するためのプログラムである。例えば、制御プログラム１０５がＣＰＵ１０７によって実行されることにより、第１通信モジュール１１０が制御され、この制御の下で第１通信モジュール１１０における信号の送受信処理が実行される。ＲＡＭ１０６は、揮発性メモリであり、一時的な情報を記憶する。ＣＰＵ１０７は、クライアント端末１００の全体の制御等、各種制御を実行する。ＣＰＵ１０７は、例えばＲＯＭ１０４から制御プログラム１０５を読み出して、ＲＡＭ１０６にロードし、ＲＡＭ１０６をワークスペースとして用いながら各種制御を実行する。なお、ＣＰＵ１０７や、ＲＯＭ１０４及びＲＡＭ１０６は、プロセッサとメモリの一例であり、これら以外のプロセッサ及びメモリ構成が用いられてもよい。また、例えば、少なくとも一部の処理が、ＡＳＩＣ（特定用途向け集積回路）や事前に所定の処理を実行するように設定されたＦＰＧＡ（フィールドプログラマブルゲートアレイ）等の、専用のハードウェアを用いて実行されてもよい。

上述の各装置は、一例において、すべて電気的な通信バス１５０によって相互に接続される。

クライアント端末１００では、例えばクライアント端末１００がインクジェット方式の印刷装置である場合、表示装置１０１が、紙のサイズの設定やカラー印刷かモノクロ印刷かの設定等の情報をユーザに提示する。そして、ユーザは、入力装置１０２を用いて、クライアント端末１００の印刷設定を行い、ＣＰＵ１０７がＲＯＭ１０４に保存されたプログラムを実行することによって出力装置１０３を制御して、出力装置１０３が印刷物を出力する。

中継サーバ２００は、第１サーバ２１０、第２サーバ２２０、制御サーバ２３０、及びデータベース２４０を含んで構成される。第１サーバ２１０、第２サーバ２２０、制御サーバ２３０、及びデータベース２４０は、例えばバス２５０等の回線によって、相互にかつ電気的に接続される。中継サーバ２００は、外部からは論理的に１つの装置として扱われうるが、物理的には、図１に示すように複数のサーバを含んだサーバ群からなり、外部からアクセスできないローカルエリアネットワーク（ＬＡＮ）等で相互に通信可能なように構成されうる。なお、中継サーバ２００は、第１サーバ２１０、第２サーバ２２０、及び制御サーバ２３０を含んでいると説明したが、１台のサーバでこれらのサーバの機能の全てを実現してもよい。

第１サーバ２１０は、例えば、第２通信モジュール２１１、ＲＯＭ２１２、ＲＡＭ２１３、ＣＰＵ２１４、及び記憶装置２１５を含んで構成される。第２サーバ２２０も同様に、第３通信モジュール２２１、ＲＯＭ２２２、ＲＡＭ２２３、ＣＰＵ２２４、及び記憶装置２２５を含んで構成される。なお、第２サーバ２２０は、例えば汎用のサーバを、第３通信モジュール２２１がＸＭＰＰを使用してクライアント端末１００へ信号を送信するように構成したサーバとして実現される。また、第１サーバ２１０も、例えば汎用のサーバを、第２通信モジュール２１１がＨＴＴＰ等を使用してクライアント端末１００からの信号の受信やサービスサーバ３００との通信を行うように構成したサーバとして実現される。制御サーバ２３０は、例えば汎用のサーバであり、ＲＯＭ２３１、ＲＡＭ２３２、ＣＰＵ２３３、及び、記憶装置２３４を含んで構成される。なお、制御サーバ２３０の記憶装置２３４には、例えば、第１サーバ２１０及び第２サーバ２２０の制御プログラムと、データベース２４０の制御を行うプログラムとを含む、制御プログラム２３５が記憶される。ただし、第１サーバ２１０や第２サーバ２２０は、制御サーバ２３０の制御によらずに一定の通信処理を実行することが可能なように構成されうる。なお、ＣＰＵやＲＡＭ及びＲＯＭ等のプロセッサ及びメモリ構成は、これらに限られず、各種処理を実行可能なプロセッサとメモリ（記憶装置）とによる任意の構成が用いられてもよい。データベース２４０は、第１サーバ２１０、第２サーバ２２０、および、制御サーバ２３０によって読み書きが行われる、ユーザの情報やサービスを提供するのに必要な情報を格納するデータベースである。

サービスサーバ３００は、第４通信モジュール３１０、ＲＯＭ３０２、ＲＡＭ３０３、ＣＰＵ３０４、及び、記憶装置３０５を含んで構成される。記憶装置３０５にはサービスサーバ３００全体を制御するプログラムが格納されている。なお、第４通信モジュール３１０、ＲＯＭ３０２、ＲＡＭ３０３、ＣＰＵ３０４、及び、記憶装置３０５は、電気的な配線バス３０１によって相互に接続される。

ネットワーク４００は、例えば、インターネットやイントラネット、ＬＡＮやＷＡＮ、電話回線、専用デジタル回線、ＡＴＭやフレームリレー回線、ケーブルテレビ回線、データ放送用無線回線等のいずれか、または、これらの組み合わせでありうる。なお、これらは一例であり、これら以外のネットワークが用いられてもよい。なお、ネットワーク４００は、有線ネットワークと無線ネットワークのいずれであってもよく、また、例えば一部区間が有線ネットワークであり、他の区間が無線ネットワークであるように構成されてもよい。例えば、クライアント端末１００と中継サーバ２００との間で、クライアント端末１００が無線ＬＡＮルータに接続し、無線ＬＡＮルータは、有線回線で中継サーバ２００と接続しうる。

なお、本実施形態では、上述のように中継サーバ２００からクライアント端末１００への通信はＸＭＰＰを含んだプロトコルスタックを用いて行われ、それ以外の通信がＨＴＴＰ等のＸＭＰＰ以外の通信プロトコルを含んだプロトコルスタックを用いて行われる。すなわち、サービスサーバ３００から中継サーバ２００への情報の送信時には、第４通信モジュール３１０から第２通信モジュール２１１へ、第１通信プロトコルスタックを利用して情報４１０が送信される。また、中継サーバ２００からクライアント端末１００への情報の送信時には、第３通信モジュール２２１から第１通信モジュール１１０へ、第２通信プロトコルスタックを用いて情報４２０が送信される。一方、クライアント端末１００から中継サーバ２００への情報の送信時には、第１通信モジュール１１０から第２通信モジュール２１１へ、第３通信プロトコルスタックを用いて情報４３０が転送される。また、中継サーバ２００からサービスサーバ３００への情報の送信時には、第２通信モジュール２１１から第４通信モジュール３１０へ、第４通信プロトコルを用いて情報４４０が送信される。このとき、クライアント端末１００と中継サーバ２００との間の通信で用いられる第２通信プロトコルスタックと第３通信プロトコルスタックは、異なる通信プロトコルにより構成される。例えば、第２通信プロトコルスタックはＸＭＰＰを含み、第３通信プロトコルスタックはＸＭＰＰを含まない。なお、本実施形態では、第１通信プロトコルスタック及び第４通信プロトコルスタックもＸＭＰＰを含まない。なお、第１通信プロトコルスタック、第３通信プロトコルスタック、及び第４通信プロトコルスタックは同じ通信プロトコルによって構成されるものとするが、これらは互いに異なる通信プロトコルを含んでもよい。

以下では、インターネット・プロトコル・スイート（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｃｏｌ Ｓｕｉｔｅ）で定められた通信プロトコルに従って説明する。第２通信プロトコルスタックと第３通信プロトコルスタックは、例えば、ネットワークインタフェイス層、ネットワーク層、及びトランスポート層は共通であり、それぞれ、イーサネット（登録商標）又はＷｉ−Ｆｉ（登録商標）、ＩＰ、及びＴＣＰでありうる。そして、アプリケーション層は、第２通信プロトコルスタックではＸＭＰＰが用いられ、第３通信プロトコルスタックではＨＴＴＰが用いられる。なお、ＴＣＰは、Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌの、ＩＰはＩｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌの、頭字語である。なお、本実施形態では、アプリケーション層のプロトコルとしてＨＴＴＰとＸＭＰＰとが用いられる例について説明するが、他のアプリケーション層のプロトコルが用いられてもよい。例えば、ＭＱＴＴプロトコルが用いられてもよい。また、トランスポート層のプロトコルはＴＣＰに限定されず、別のプロトコルが用いられてもよい。同様に、ネットワーク層のプロトコルはＩＰに限定されず、他のプロトコルが用いられてもよい。なお、本実施形態では、通信が暗号化されることが想定されるため、以下では、アプリケーション層の暗号化通信を明示的に示すために、ＨＴＴＰをＨＴＴＰ（Ｓ）、ＸＭＰＰをＸＭＰＰ（Ｓ）と記述する。

図２は、クライアント端末１００が有する第１通信モジュール１１０の構成例を示す図である。本実施形態では、第１通信モジュール１１０が無線通信用の通信モジュールであるものとするが、これに限られず、第１通信モジュール１１０は、有線通信モジュールであってもよい。第１通信モジュール１１０は、一般的な無線通信モジュールと同様に、受信部１２０、送信部１３０、送受信用のアンテナ１１１、送受信の切り替えスイッチ１１２、発振器１１３、及び、制御部１１４を含む。受信部１２０は、ＡＤＣ（アナログ−デジタルコンバータ）１２１、復調器１２２、ＬＮＡ（Ｌｏｗ Ｎｏｉｓｅ Ａｍｐｌｉｆｉｅｒ）１２３を含む。送信部１３０は、ＤＡＣ（デジタル−アナログコンバータ）１３１、変調器１３２、ＰＡ（Ｐｏｗｅｒ Ａｍｐｌｉｆｉｅｒ）を含む。

第３通信モジュール２２１から送信されてネットワーク４００を経由して第１通信モジュール１１０に到来したセグメントは、無線信号としてアンテナ１１１によって受信される。なお、このセグメントは、アプリケーション層がＸＭＰＰ（Ｓ）の第２通信プロトコルスタックのヘッダ情報を含んで構成される。この無線信号（セグメント）は、切り替えスイッチ１１２が受信部１２０とアンテナ１１１とを接続するように設定されることにより、受信部１２０へ伝達される。受信部１２０に伝達された無線周波数（ＲＦ）の信号は、ＬＮＡにより増幅されて、復調器１２２に入力される。復調器１２２は、発振器１１３で生成された周波数信号によってＲＦの信号を中間周波数やベースバンドの信号に変換する。そして、その信号は、ＡＤＣ１２１によってデジタル信号に変換されて出力される。なお、ＡＤＣ１２１は、例えば、中間周波数又はベースバンドのアナログ信号をデジタル化し、そのデジタル化されたベースバンド信号に対して、その信号の変調方式に基づく復調や誤り訂正復号等の各種処理を行いうる。出力されたデジタル信号は、通信バス１５０を介して、制御部１１４又はＣＰＵ１０７に入力される。そして、制御部１１４又はＣＰＵ１０７は、その信号のヘッダの解析を実行し、得られたデータをＲＡＭ１０６に保存する。

セグメントを第２通信モジュール２１１に向けて送信する際には、ＣＰＵ１０７又は制御部１１４が、アプリケーション層のＨＴＴＰ（Ｓ）ヘッダやその他必要なヘッダをデータに付加したデジタル信号を生成し、そのデジタル信号をＤＡＣ１３１へ出力する。そして、ＤＡＣ１３１は、入力されたデジタル信号をアナログ信号に変換し、変調器１３２は、発振器１１３で生成された周波数信号によりそのアナログ信号を偏重して無線周波数の信号を出力する。なお、ＤＡＣ１３１は、ヘッダが付加されたデジタル信号に対して、誤り訂正符号化や送信フレームフォーマットに適合させるためのパディング、一次変調によるアナログベースバンド信号の生成等の処理を行いうる。その後、その無線周波数の信号は、ＰＡ１３３によって増幅されてアンテナ１１１を介してクライアント端末１００の外部へ送出される。

このようにして、クライアント端末１００は、異なる通信プロトコルスタックを用いて、データの送受信を行うことができる。なお、図２の構成は一例であり、受信信号に基づいてヘッダ解析を行ってデータを取得することができ、また、データに各種プロトコルのヘッダを付加して送信信号を生成することができる構成であれば、これ以外の構成が用いられてもよい。

（通信の流れ）
続いて、本実施形態の通信に関する処理の流れについて説明する。

まず、図３を用いて、サービスサーバ３００からクライアント端末１００へデータが送信される場合の通信の流れの例について説明する。なお、ここで説明する処理は、サービスに関する様々な通信に適用されるものであり、その送受信されるデータについては特に限定されない。このため、図３においては、信号の流れのみを図示し、その送信されるデータの内容については図示していない。

本処理は、例えば、ユーザがクライアント端末１００とは異なる端末や別のコンピュータを用いてサービスサーバ３００にアクセスし、サービスサーバ３００がクライアント端末１００を対象としてサービスを提供するように指示した場合に実行される。以下では、具体例として、クライアント端末１００が印刷装置であり、サービスサーバ３００がストレージサービスを提供するサーバであるものとする。そして、ユーザが、サービスサーバ３００にアクセスして、そのサービスサーバ３００に保存されている画像データを、クライアント端末１００に印刷させる場合の例について説明する。なお、サービスサーバ３００は、ユーザが有するパーソナルコンピュータの画面等を介して、画像選択画面や印刷実行のユーザインタフェイスを提供することができる。ユーザは、自身が有するこのユーザインタフェイスを介して、サービスサーバ３００内に保存された画像と、出力先の印刷装置であるクライアント端末１００とを選択して、クライアント端末１００に画像の印刷を実行させる。

本処理では、まず、サービスサーバ３００のＣＰＵ３０４が、インターネット・プロトコル・スイートが定める形式に沿って、送信対象となる第１通信プロトコルスタックのヘッダ情報を有したセグメントを生成する。例えば、サービスサーバ３００のＣＰＵ３０４は、ユーザからの印刷対象画像の選択と印刷実行指示とを受け付けると、その画像データが保存されているＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）をデータとするセグメントを生成する。このときに、ＣＰＵ３０４は、アプリケーション層をＨＴＴＰ（Ｓ）、トランスポート層をＴＣＰ、インターネット層をＩＰ、ネットワークインタフェイス層をイーサネットとするプロトコルスタックのヘッダ情報をデータに付加してセグメントを生成する。なお、ＣＰＵ３０４は、ＩＰのヘッダとして、送信先の第２通信モジュール２１１のＩＰアドレスを含める。また、ＣＰＵ３０４は、このセグメントのデータ部に、ユーザの識別情報を含めてもよい。そして、ＣＰＵ３０４は、生成したセグメントを第４通信モジュール３１０に転送する（Ｓ５０１）。その後、第４通信モジュール３１０は、ネットワーク４００を介して、中継サーバ２００内の第１サーバ２１０（第２通信モジュール２１１）へ、セグメントを送信する（Ｓ５０２）。

第１サーバ２１０において、ＣＰＵ２１４は、第２通信モジュール２１１がセグメントを受信したことに応じてそのセグメントを取得する（Ｓ５０３）。ＣＰＵ２１４は、インターネット・プロトコル・スイートが定める形式に沿ってそのセグメントを解析して、送信されたデータのＵＲＬやユーザの識別情報、受信時間など必要な様々な情報を取得する。そして、ＣＰＵ２１４は、その結果をデータベース２４０に書き込む（Ｓ５０４）。

制御サーバ２３０のＣＰＵ２３３は、データベース２４０の状態を、所定の周期で監視する（Ｓ５０５）。ＣＰＵ２３３は、Ｓ５０４において第１サーバ２１０のＣＰＵ２１４がデータをデータベース２４０に書き込むと、それを検出して、データベース２４０からデータを読み出す。そして、ＣＰＵ２３３は、読み出したデータに対して、アプリケーション層がＸＭＰＰ（Ｓ）、トランスポート層がＴＣＰ、インターネット層がＩＰ、ネットワークインタフェイス層がイーサネットのヘッダ情報を付加して、セグメントを生成する。ＣＰＵ２３３は、生成したセグメントを第２サーバ２２０のＣＰＵ２２４へ転送する（Ｓ５０６）。

第２サーバ２２０のＣＰＵ２２４は、制御サーバ２３０のＣＰＵ２３３からセグメントを受け取ると、セグメントを第３通信モジュール２２１に転送する（Ｓ５０７）。なお、制御サーバ２３０のＣＰＵ２３３は、セグメントを生成せずに、データが書き込まれたことを第２サーバ２２０のＣＰＵ２２４へ通知してもよい。この場合、第２サーバ２２０のＣＰＵ２２４が、データベース２４０からデータを読み出し、そのデータを含んだセグメントを生成しうる。なお、ＣＰＵ２２４は、第３通信モジュール２２１が第１通信モジュール１１０との間でＸＭＰＰ通信を確立していることを確認した上で、セグメントを第３通信モジュール２２１へ転送しうる。すなわち、ＣＰＵ２２４は、第３通信モジュール２２１が第１通信モジュール１１０との間でＸＭＰＰ通信を確立していない場合は、セグメントの生成を保留し、又は、第３通信モジュール２２１に転送しないようにしうる。なお、セグメントの第３通信モジュール２２１への転送を保留する場合、生成されたセグメントは、ＲＡＭ２２３に記憶されうる。そして、ＸＭＰＰ通信が確立され次第、そのセグメントがＣＰＵ２２４によって読み出され、第３通信モジュール２２１へ転送される。第３通信モジュール２２１は、ネットワーク４００を介してクライアント端末１００の第１通信モジュール１１０へ、セグメントを送信する（Ｓ５０８）。

クライアント端末１００のＣＰＵ１０７は、第１通信モジュール１１０がセグメントを受信したことを検出すると、そのセグメントを取得して（Ｓ５０９）、インターネット・プロトコル・スイートが定める形式に沿って解析を行う。そして、ＣＰＵ１０７は、解析によって得られたデータの内容に基づいて処理を実行し、その処理の結果に応じて出力装置１０３を制御する（Ｓ５１０）。本処理例では、解析によって得られるデータには画像データのＵＲＬが含まれ、ＣＰＵ１０７は、そのＵＲＬに基づいて画像データをダウンロードし、出力装置１０３を用いた印刷を実行する。

図４は、図３に示す通信のプロトコルスタックを示す図である。図４のプロトコルスタックは、インターネット・プロトコル・スイートで定められているように、下位層から順に、ネットワークインタフェイス層、インターネット層、トランスポート層、アプリケーション層が示されている。図４に示すように、サービスサーバ３００の第４通信モジュール３１０は、「イーサネット」、「ＩＰ」、「ＴＣＰ」、「ＨＴＴＰ（Ｓ）」のプロトコルスタックを有する。そして、中継サーバ２００の第２通信モジュール２１１も「イーサネット」、「ＩＰ」、「ＴＣＰ」、「ＨＴＴＰ（Ｓ）」のプロトコルスタックを有する。一方、第３通信モジュール２２１は、「イーサネット」、「ＩＰ」、「ＴＣＰ」、「ＸＭＰＰ（Ｓ）」のプロトコルスタックを有する。このように、中継サーバ２００がサービスサーバ３００から受信するセグメントと、中継サーバ２００がクライアント端末１００へ送信するセグメントとでは、アプリケーション層の通信プロトコルが異なる。なお、クライアント端末１００の第１通信モジュール１１０は、「Ｗｉ−Ｆｉ」、「ＩＰ」、「ＴＣＰ」、「ＸＭＰＰ（Ｓ）」のプロトコルスタックを有する。なお、図４では、クライアント端末１００が受信するセグメントが「Ｗｉ−Ｆｉ」を含むプロトコルスタックで送信されているが、これに限られない。すなわち、図４の例では、クライアント端末１００がＷｉ−Ｆｉで無線通信を行う場合を示しているが、クライアント端末１００も「イーサネット」で有線通信を行うようにしてもよい。

なお、図４は、クライアント端末１００がＷｉ−Ｆｉのアクセスポイント等（不図示）からセグメントを受信することを想定して、プロトコルスタックが「Ｗｉ−Ｆｉ」を含んでいる。すなわち、第３通信モジュール２２１が送信したセグメントは、例えば、イーサネットを用いてＷｉ−Ｆｉのアクセスポイントまで転送される。そして、そのアクセスポイントは、受信したセグメントのネットワークインタフェイス層のプロトコルをイーサネットからＷｉ−Ｆｉへ変換して、クライアント端末１００へそのセグメントを転送しうる。なお、クライアント端末１００が中継サーバ２００と直接接続する場合は、例えば中継サーバ２００が、Ｗｉ−Ｆｉの信号を受信して、イーサネットの信号へと変換する役割で動作しうる。すなわち、このような場合には、クライアント端末１００と中継サーバ２００との間で使用されるプロトコルスタックは当然に共通化される。

続いて、図５を用いて、クライアント端末１００からサービスサーバ３００へデータが送信される場合の通信の流れの例について説明する。なお、ここで説明する処理も、サービスに関する様々な通信に適用されるものであり、その送受信されるデータについては特に限定されない。このため、図５においては、信号の流れのみを図示し、その送信されるデータの内容については図示していない。

以下では、具体例として、クライアント端末１００がスキャン装置であり、サービスサーバ３００がストレージサービスを提供するサーバであるものとする。そして、ユーザが、クライアント端末１００を用いて文書や写真などをスキャンし、クライアント端末１００は、サービスサーバ３００にアクセスして、そのサービスサーバ３００にスキャンした文書や写真などを保存させる場合の例について説明する。図５の処理の開始前に、例えばユーザが読み取らせたい文書や写真等をクライアント端末１００にセットし、クライアント端末１００の入力装置１０２が、その文書や写真等をスキャンしてデジタル化したデータを生成する。そして、入力装置１０２は、ＣＰＵ１０７の制御により、生成したデジタルデータをＲＡＭ１０６に一時的に保存する。この状態で、ユーザが、入力装置１０２を介して、保存されているデータのサービスサーバ３００への格納をクライアント端末１００に対して指示する操作を行うことにより、図５の処理が開始される。

図５の処理では、ＣＰＵ１０７は、ＲＡＭ１０６に保存されているデータのサービスサーバ３００への格納を指示するユーザ指示に応じて、ＲＡＭ１０６からそのデータを読み出す（Ｓ６０１）。そして、ＣＰＵ１０７は、インターネット・プロトコル・スイートに沿って、プロトコルスタックの各プロトコルに応じたヘッダ情報を付加することによって、読み出したデータから送信すべきセグメントを生成する。ここでは、アプリケーション層がＨＴＴＰ（Ｓ）、トランスポート層がＴＣＰ、インターネット層がＩＰ、ネットワークインタフェイス層がＷｉ−Ｆｉのプロトコルスタックのヘッダ情報を有するセグメントが生成される。なお、このセグメントでは、例えば、ＩＰ層において、第２通信モジュール２１１のＩＰアドレスがヘッダ情報としてデータに付加される。その後、ＣＰＵ１０７は、生成したセグメントを第１通信モジュール１１０へ転送し（Ｓ６０２）、第１通信モジュール１１０は、そのセグメントを無線信号として送出する（Ｓ６０３）。このセグメントは、上述のように、ＩＰ層のヘッダ情報として第２通信モジュール２１１のＩＰアドレスが付加されているため、例えば無線信号を受信したアクセスポイント（不図示）を介して、第２通信モジュール２１１へ向けて転送される。

第１サーバ２１０において、ＣＰＵ２１４は、第２通信モジュール２１１がセグメントを受信したことに応じて、そのセグメントを取得して（Ｓ６０４）、解析することによって、クライアント端末１００から送信されてきたデータを取得する。そして、ＣＰＵ２１４は、サービスサーバ３００の第４通信モジュール３１０へそのデータを送信するために、インターネット・プロトコル・スイートに沿って、プロトコルスタックの各プロトコルに応じた適切なヘッダ情報を付加して、セグメントを生成する。ここでのセグメントでは、例えば、ＩＰ層において、第４通信モジュール３１０のＩＰアドレスがヘッダ情報としてデータに付加される。ＣＰＵ２１４は、生成したセグメントを第２通信モジュール２１１へ戻し（Ｓ６０５）、第２通信モジュール２１１は、このセグメントをネットワーク４００へ送出する（Ｓ６０６）。セグメントは、ネットワーク４００内のルータ等を介して第４通信モジュール３１０へ転送される。サービスサーバ３００において、ＣＰＵ３０４は、第４通信モジュール３１０がセグメントを受信したことに応じて、そのセグメントを取得する（Ｓ６０７）。そして、ＣＰＵ３０４は、取得したセグメントを解析し、クライアント端末１００によってスキャンされたデジタルデータを取得し、そのデジタルデータをＲＡＭ３０３又は記憶装置３０５に保存させる。

図６は、図５に示す通信のプロトコルスタックを示す図である。図６のプロトコルスタックは、図４と同様に、インターネット・プロトコル・スイートで定められているように、下位層から順に、ネットワークインタフェイス層、インターネット層、トランスポート層、アプリケーション層が示されている。図６に示すように、クライアント端末１００の第１通信モジュール１１０は、「Ｗｉ−Ｆｉ」、「ＩＰ」、「ＴＣＰ」、「ＨＴＴＰ（Ｓ）」のプロトコルスタックを有する。中継サーバ２００、サービスサーバ３００は、共に、「イーサネット」、「ＩＰ」、「ＴＣＰ」、「ＨＴＴＰ（Ｓ）」のプロトコルスタックを有する。図６のように、アプリケーション層に注目すると、クライアント端末１００から中継サーバ２００へのデータの送信と、中継サーバ２００からサービスサーバ３００へのデータの送信とにおいて、共にＨＴＴＰ（Ｓ）が利用される。

上述の実施形態では、クライアント端末１００が印刷装置やスキャン装置である場合について説明したが、これに限られない。すなわち、クライアント端末１００は、何らかのデータを、中継サーバ２００を介して送信または受信するように構成される限り、印刷装置やスキャン装置である必要はない。同様に、サービスサーバ３００も、ストレージサービス以外のサービスを提供することができる。また、中継サーバ２００も上述のような構成及び動作に限定されない。

本実施形態では、上述のように、クライアント端末１００、中継サーバ２００、サービスサーバ３００の間の通信において、送信と受信とでインターネット・プロトコル・スイートによって定められるアプリケーション層が異なる通信プロトコルを利用する。これにより、例えば、ＨＴＴＰ（Ｓ）を利用して中継サーバ２００に接続されるクライアント端末１００が急激に増大したとしても、ＸＭＰＰサーバ（第２サーバ２２０）の負荷を抑え、安定した通信を実現することができる。

［変形例］
上述の通信の流れの例では、中継サーバ２００が、クライアント端末１００からデータを受信すると、サービスサーバ３００からのデータ取得要求を受けることなくそのデータをサービスサーバ３００へ送信する、プッシュ型通信を行う例について説明した。一方で、中継サーバ２００は、サービスサーバ３００からのデータ取得要求を受け付けたことに応じて、その要求の返答としてクライアント端末１００から受信したデータを送信する、プル型通信を行うこともできる。本変形例では、このプル型通信が行われる場合の例について説明する。

なお、このようなプル型通信は、例えば、中継サーバ２００に保存されているデータが頻繁に変更される場合に有効である。すなわち、このような場合、中継サーバ２００は、プッシュ型通信によれば、データの変更ごとにその変更されたデータをクライアント端末１００又はサービスサーバ３００へ送信することとなる。一方で、プル型通信によれば、中継サーバ２００は、データが変更されても、クライアント端末１００又はサービスサーバ３００からのデータ取得要求がない限りはデータを送信しない。このため、プル型通信を行うことにより、中継サーバ２００の処理負荷を低減することができる。また、中継サーバ２００の処理負荷を低減することにより、クライアント端末１００やサービスサーバ３００が急激に増えた場合に対する中継サーバ２００の耐久性を増すことができる。

以下では、まず、中継サーバ２００がサービスサーバ３００からプッシュ型通信により情報を取得し、クライアント端末１００へプル型通信を通じて情報を提供する例について説明する。図７は、この場合の通信の流れの例を示している。本処理では、中継サーバ２００は、サービスサーバ３００から受信したデータがデータベース２４０に保存されたことに応じて、クライアント端末１００に対して、データが保存されたことをプッシュ型通信で通知する。その後、クライアント端末１００は、例えばユーザが所定の操作を行ったことに応じて、中継サーバ２００へデータ取得要求を送信する。そして、中継サーバ２００は、このデータ取得要求に応じて、データベース２４０に保存されたデータをクライアント端末１００へ送信する。

なお、図７は、図３の場合と同様のユースケースで実行される処理であり、例えば、サービスサーバ３００に保存された文書や写真等をクライアント端末１００に印刷させる場合に、図７のような処理が実行される。なお、図７の処理が実行される場合の通信のプロトコルスタックを図８に示す。図８に示すように、利用されるアプリケーション層の通信プロトコルは、サービスサーバ３００と中継サーバ２００との間の通信のためにＨＴＴＰが用いられる。そして、中継サーバ２００からクライアント端末１００へのプッシュ通知にはＸＭＰＰが使用され、クライアント端末１００から中継サーバ２００への情報要求にはＨＴＴＰが使用される。すなわち、上述のように、クライアント端末１００と中継サーバ２００との間の通信においては、クライアント端末１００が送信側である場合と受信側である場合とで、それぞれ異なる通信プロトコルが使用される。

サービスサーバ３００がデータを送信し、中継サーバ２００内で制御サーバ２３０が、データベース２４０にデータが格納されたことを検出するまでの処理（Ｓ７０１〜Ｓ７０５）は、図３のＳ５０１〜Ｓ５０５の処理と同様であるため説明を省略する。制御サーバ２３０のＣＰＵ２３３は、クライアント端末１００宛てのデータが格納されたことを検出すると、データが格納されたことをそのクライアント端末１００へ通知するためのセグメントの生成を、第２サーバ２２０のＣＰＵ２２４に指示する（Ｓ７０６）。ＣＰＵ２２４は、生成したセグメントを第３通信モジュール２２１へ転送し（Ｓ７０７）、第３通信モジュール２２１は、そのセグメントをクライアント端末１００へ宛ててプッシュ送信する（Ｓ７０８）。ここで、ＸＭＰＰプロトコルを用いたプッシュ通知は、クライアント端末１００に対して、取得すべきデータが中継サーバ２００内に存在することのみを通知すれば足りる。このため、ここでのプッシュ通知は、ＸＭＰＰで必要なヘッダの他には、１バイト〜１０キロバイト程度の少量の情報を含む。

クライアント端末１００のＣＰＵ１０７は、第１通信モジュール１１０がセグメントを受信したことを検出すると、そのセグメントを取得し（Ｓ７０９）、内容を解析する。そして、ＣＰＵ１０７は、そのセグメント内の情報によって、データベース２４０にクライアント端末１００宛てのデータが格納されていることを認識し、そのデータを取得するか否かを判定する。例えば、ＣＰＵ１０７は、ユーザに対して、印刷対象のデータが中継サーバ２００内に存在することを通知し、ユーザが、そのデータを取得することを示す指示を受け付けたことに応じて、そのデータを取得すると判定する。ＣＰＵ１０７は、データを取得すると判定した場合に、データ取得要求を含んだセグメントを生成し、そのセグメントを第１通信モジュール１１０へ転送する（Ｓ７１０）。第１通信モジュール１１０は、そのセグメントを第２通信モジュール２１１に宛てて送信する（Ｓ７１１）。第１サーバ２１０のＣＰＵ２１４は、第２通信モジュール２１１がセグメントを受信したことを検出すると、そのセグメントを取得して解析し、データ取得要求を受信したことを認識する（Ｓ７１２）。そして、ＣＰＵ２１４は、データ取得要求があったことを、第２サーバ２２０のＣＰＵ２２４に通知する（Ｓ７１３）。ＣＰＵ２２４は、この通知を受け取ると、例えばＲＡＭ２２３やデータベース２４０に記憶されている、クライアント端末１００宛のデータを取り出し、クライアント端末１００宛のセグメントを生成して、第３通信モジュール２２１に転送する（Ｓ７１４）。第３通信モジュール２２１は、受け取ったセグメントを、クライアント端末１００へ送信する（Ｓ７１５）。クライアント端末１００のＣＰＵ１０７は、第１通信モジュール１１０がセグメントを受信したことを検出すると、そのセグメントを取得して解析する（Ｓ７１６）。その後の処理（Ｓ７１７）は、図３のＳ５１０と同様である。

このように、プッシュ型通信ではクライアント端末１００宛のデータをすべてＸＭＰＰで送信する必要があるが、本変形例では、データが保存されていることの通知と、データ送信要求があったデータのみがＸＭＰＰプロトコルで送信される。このため、データベース２４０に保存されるデータが頻繁に更新される場合に、その一部のデータのみをクライアント端末１００に取り込む場合などにおいて、ＸＭＰＰで送信されるデータ量を大幅に削減し、ＸＭＰＰサーバの負荷を顕著に低減することができる。

続いて、中継サーバ２００が、クライアント端末１００からプッシュ型通信により情報を取得し、サービスサーバ３００へプル型通信を通じて情報を提供する例について説明する。図９は、この場合の通信の流れの例を示している。本処理では、中継サーバ２００は、クライアント端末１００からデータを受信したことに応じて、サービスサーバ３００に対して、データが保存されたことをプッシュ型通信で通知する。その後、中継サーバ２００は、サービスサーバ３００からデータ取得要求があった場合に、ＲＡＭ２１３等に一時保存したデータをサービスサーバ３００へ送信する。なお、サービスサーバ３００は、例えば自装置の負荷や中継サーバ２００との間の回線の負荷が所定値以下となったこと等に応じて、データ取得要求を、中継サーバ２００へ送信しうる。

なお、図９は、図５の場合と同様のユースケースで実行される処理であり、例えば、クライアント端末１００がスキャンした画像を、サービスサーバ３００に保存させる場合に、図９のような処理が実行される。なお、図９の処理が実行される場合の通信のプロトコルスタックを図１０に示す。図１０に示すように、利用されるアプリケーション層の通信プロトコルは、クライアント端末１００から中継サーバ２００への信号の送信と、中継サーバ２００とサービスサーバ３００との間の通信とのいずれにおいても、ＨＴＴＰが用いられる。

クライアント端末１００がセグメントを送信し、第１サーバ２１０のＣＰＵ２１４がそのセグメントを受信して解析することによってデータを取得するまでの処理（Ｓ８０１〜Ｓ８０４）は、図５のＳ６０１〜Ｓ６０４の処理と同様であるため説明を省略する。ＣＰＵ２１４は、解析によって得られたデータを、例えばＲＡＭ２１３に保存し、データが保存されていることを示す情報を含んだセグメントを生成し、第２通信モジュール２１１を介してサービスサーバ３００へ送信する（Ｓ８０５、Ｓ８０６）。ここで、第２通信モジュール２１１から第４通信モジュール３１０へ向けて送信される情報はプッシュ通知である。このプッシュ通知は、サービスサーバ３００に対して、クライアント端末１００から送信された情報を中継サーバ２００が保存していることのみを通知すれば足りる。このため、ここでのプッシュ通知は、ＨＴＴＰで必要なヘッダの他には、１バイト〜１０キロバイト程度の少量の情報を含む。プッシュ通知は、サービスサーバ３００のＣＰＵ３０４によって検出される（Ｓ８０７）。そして、ＣＰＵ３０４は、このプッシュ通知に応じて、また、必要に応じて自装置の負荷等に基づいてデータを取得すべき状態であるか否かの判定に従って、中継サーバ２００へのＨＴＴＰリクエストを生成する。そして、生成されたＨＴＴＰリクエストは、ＣＰＵ３０４から第４通信モジュール３１０へ転送され（Ｓ８０８）、第４通信モジュール３１０から第２通信モジュール２１１へ送信される（Ｓ８０９）。サービスサーバ３００は、そのＨＴＴＰリクエストを送信することにより、例えば第１サーバ２１０のＲＡＭ２１３に一時保存されたデータを、第２通信モジュール２１１を介して取得する（Ｓ８１０、Ｓ８１１）。これにより、サービスサーバ３００は、クライアント端末１００からの要求を取得及び処理することができる。

本変形例では、中継サーバ２００は、サービスサーバ３００からの要求を受けると、それに連動して、クライアント端末１００にプッシュ通知を行う例を示したが、これに限られない。例えば、中継サーバ２００は、サービスサーバ３００からの情報を受信した後にプッシュ通知を行わなくてもよい。この場合、クライアント端末１００が、例えば周期的に又はユーザ操作に応じて、情報を取得するリクエストを中継サーバ２００へ送信しうる。そして、中継サーバ２００は、そのリクエストに応じて、自装置内にクライアント端末１００宛の情報が保存されているか否かを判定し、その判定結果を示す情報をクライアント端末１００へ送信してもよい。同様に、本変形例では、中継サーバ２００は、クライアント端末１００からの要求を受けると、それに連動して、サービスサーバ３００にプッシュ通知を行う例を示したが、これに限られない。例えば、中継サーバ２００は、クライアント端末１００から情報を受信した後にプッシュ通知を行わなくてもよい。この場合、サービスサーバ３００が例えば周期的に情報を取得するリクエストを中継サーバ２００へ送信しうる。そして、中継サーバ２００は、そのリクエストに応じて、自装置内にサービスサーバ３００宛の情報が保存されているか否かを判定し、その判定結果を示す情報をサービスサーバ３００へ送信しうる。

本変形例のように、中継サーバ２００にデータが保存されていることを示すだけのデータサイズの十分に小さい信号を送信するようにすることで、クライアント端末１００やサービスサーバ３００の増加に対する負荷の増加を低く抑えることができる。また、中継サーバ２００が情報を保存していることのみを相手装置に通知するようにすることで、中継サーバ２００の制御プログラムの更新を行わずに、新たなサービスを提供するサービスサーバや様々なクライアント端末１００に対応することが可能となる。

（クライアント端末とサービスとの関連付け処理）
以下では、クライアント端末１００とサービスとの対応関係を中継サーバ２００が記憶しておき、その関係に基づいて、サービスサーバ３００がそのクライアント端末１００にサービスを提供するか否かを決定する処理について説明する。本処理では、クライアント端末１００は、中継サーバ２００のデータベース２４０にクライアント端末１００に固有の識別情報（端末ＩＤ）を登録し、クライアント端末１００がサービスを受ける準備を完了させる。なお、端末ＩＤは、例えば、クライアント端末１００の製造過程で付与される固有のＩＤであるシリアルナンバーや、第１通信モジュール１１０に付与されるＭＡＣアドレス等でありうる。一方、サービスサーバ３００は、自装置が提供するサービスに固有の識別情報（サービスＩＤ）とサービスを受ける端末ＩＤとをデータベース２４０に登録する。そして、このような情報が登録された後に、クライアント端末１００が、サービスサーバ３００からサービスを受けることができるようにする。なお、本処理は、上述の通信処理に加えて又は上述の通信処理が用いられない場合であっても実行されうる。

以下では、このような処理における、情報登録処理（クライアント端末１００とサービスとの関連付け処理）について説明する。図１１（Ａ）は、クライアント端末１００から、中継サーバ２００のデータベース２４０にクライアント端末１００の端末ＩＤを登録し、クライアント端末１００がサービスを受ける準備を完了させる処理の流れの例を示している。また、図１１（Ｂ）は、サービスサーバ３００から、サービス固有の識別情報（サービスＩＤ）とサービスを受ける端末ＩＤとをデータベース２４０に登録し、クライアント端末１００がサービスを受ける準備を完了させる処理の流れの例を示している。

また、図１２に、データベース２４０に記憶される、端末ＩＤとサービスＩＤとを関連付ける情報の例を示す。この情報は、図１２に示すように、サービスマスタテーブル１００１とサービス登録テーブル１００２、クライアント端末登録テーブル１００３、及び、クライアント端末−サービス紐付けテーブル１００４を含む。各テーブルは、一意キーとして、各レコードの登録時に作成されると共にほぼ重複する可能性がない固有の文字列（Ｕｎｉｖｅｒｓａｌｌｙ Ｕｎｉｑｕｅ ＩＤ、ＵＵＩＤ）を含む。サービスマスタテーブル１００１は、一意キーであるＵＵＩＤに加えて、属性値として、サービスＩＤ、及び、サービスが登録された登録日時を含む。サービス登録テーブル１００２は、ＵＵＩＤに加えて、属性値として、サービスＩＤと端末ＩＤ、及び、登録日時を含む。クライアント端末登録テーブル１００３は、ＵＵＩＤに加えて、端末ＩＤ、端末の詳細な情報が記載された端末情報、及び、登録日時を含む。クライアント端末−サービス紐付けテーブル１００４は、ＵＵＩＤに加えて、端末ＩＤ、サービスＩＤ、登録日時を含む。

図１１（Ａ）において、クライアント端末１００は、入力装置１０２を介してユーザ操作を受け付け、クライアント端末登録テーブル１００３に対する端末ＩＤ及び端末情報を登録するリクエストを、中継サーバ２００へ送信する（Ｓ９０１）。ここで、クライアント端末１００から中継サーバ２００への通信は、上述のように、ＨＴＴＰを用いて行ってもよいし、ＸＭＰＰを用いて行ってもよい。また、クライアント端末１００がデータ取得要求を受信することなく情報を中継サーバ２００へ送信するプッシュ型通信が用いられてもよいし、中継サーバ２００の要求に応じてクライアント端末１００が情報を送信するプル型通信が用いられてもよい。中継サーバ２００は、クライアント端末１００からのリクエストを受信すると、ＵＵＩＤを作成し、その値を一意キーとして、また、端末ＩＤ、端末情報、及び登録日時を属性値として、対応付けて登録する。なお、中継サーバ２００は、クライアント端末登録テーブル１００３にリクエストで通知された端末ＩＤを含むレコードが作成済みであるか否かをチェックしうる。そして、中継サーバ２００は、通知された端末ＩＤがクライアント端末登録テーブル１００３に登録済みであった場合は、その端末ＩＤが登録済みであることを示す情報を、クライアント端末１００へ送信しうる。その後、中継サーバ２００は、サービス登録テーブル１００２を走査して、その端末ＩＤを属性値として含むレコードが存在するか否かを判定する（Ｓ９０２）。そして、中継サーバ２００は、その端末ＩＤを属性値として含むレコードが存在する場合（Ｓ９０２でＹＥＳ）、クライアント端末−サービス紐付けテーブル１００４に、そのレコードに含まれるサービスＩＤと端末ＩＤを登録する（Ｓ９０３）。この関連付けにより、クライアント端末１００は、サービスサーバ３００が提供するサービスを受ける準備を完了する（Ｓ９０４）。なお、中継サーバ２００は、その端末ＩＤを属性値として含むレコードが存在しない場合（Ｓ９０２でＮＯ）、図１１（Ａ）の処理を終了する。この場合、図１１（Ｂ）に示される、サービスサーバ３００からのサービスＩＤの登録処理が実行されるのを待つことになる。

図１１（Ｂ）の処理は、例えば、ユーザが不図示のパーソナルコンピュータ等による操作を行ったことに基づいて、サービスサーバ３００が開始する。本処理が開始されると、サービスサーバ３００は、サービス登録テーブル１００２に登録したサービスと、そのサービスを受ける端末ＩＤとを登録するように、中継サーバ２００に対するリクエストを送信する（Ｓ９２１）。中継サーバ２００は、そのリクエストを受信すると、まず、リクエストに含まれるサービスＩＤが、サービスマスタテーブル１００１内に登録されているか否かを確認する（Ｓ９２２）。リクエストに含まれるサービスＩＤがサービスマスタテーブル１００１に登録されている場合（Ｓ９２２でＹＥＳ）、処理はＳ９２３へ進む。Ｓ９２３では、中継サーバ２００は、リクエストで示される端末ＩＤを含んだレコードがクライアント端末登録テーブル１００３内に存在するか否かを確認する確認する（Ｓ９２３）。そのようなレコードがクライアント端末登録テーブル１００３内に存在する場合（Ｓ９２３でＹＥＳ）、中継サーバ２００は、そのサービスＩＤと端末ＩＤとをクライアント端末−サービス紐付けテーブル１００４に登録する（Ｓ９２４）。この関連付けにより、クライアント端末１００は、サービスサーバ３００が提供するサービスを受ける準備を完了する（Ｓ９２５）。なお、サービスＩＤがサービスマスタテーブル１００１に登録されていない場合（Ｓ９２２でＮＯ）又は端末ＩＤを含んだレコードがクライアント端末登録テーブル１００３内に存在しない場合（Ｓ９２３でＮＯ）、処理が終了する。この場合、図１１（Ａ）に示される、クライアント端末１００からの端末ＩＤの登録処理が実行されるのを待つことになる。

これにより、クライアント端末１００とサービスサーバ３００が提供するサービスとの対応関係が登録され、登録されていないクライアント端末１００にサービスが提供されるのを防ぐことができる。なお、クライアント端末１００が他人に譲渡される場合等には、端末ＩＤをクライアント端末登録テーブル１００３から削除することもできる。この場合、クライアント端末−サービス紐付けテーブル１００４からその端末ＩＤを属性値として有するレコードが削除され、また、サービス登録テーブル１００２からその端末ＩＤを有するレコードが削除されることにより、関連付けがすべて解除される。また、サービスマスタテーブル１００１からサービスが削除された場合は、サービス登録テーブル１００２において、そのサービスに対応するサービスＩＤを属性値として有するレコードが削除されうる。また、クライアント端末−サービス紐付けテーブル１００４からも、そのサービスＩＤを有するレコードが削除されうる。これにより、サービスＩＤが別のサービスに割り当てられた場合に、その別のサービスが、本来提供されるべきでないクライアント端末に対して提供されることを防ぐことができる。

本処理では、中継サーバ２００を中心として、クライアント端末１００の登録とサービスの登録とを別個に行い、その関連付けを確認してサービスが提供される。この構成によれば、例えば、新規のサービスを追加するために新たなサービスサーバ３００を既存のシステムに追加する場合、サービスマスタテーブル１００１に新たなサービスが登録される。そして、その後に、新規サービスの提供を受けたい端末が、サービス登録テーブル１００２に登録される。このように、新規サービスの追加が、サービスマスタテーブル１００１によって管理されることにより、新規サービスを提供するサービスサーバの増設への対応が容易になり、また、中継サーバ２００の処理の内容を大幅に変更する必要がなくなる。また、処理内容の大幅な変更がないため、中継サーバ２００の負荷も大幅に増えることがなく、また、演算能力の向上のための構成変更が過剰となることを防ぐことができる。

（セッション確立状態に基づく信号送信処理）
中継サーバ２００がクライアント端末１００へ情報を送信する際に、中継サーバ２００が利用する通信プロトコルのセッションの有無を確認してから情報を送信する処理の例について説明する。また、その通信プロトコルのセッションが確立されておらず、中継サーバ２００からクライアント端末１００に情報が送信できない場合に、クライアント端末１００からセッションを確立する処理の例について説明する。上述の例と同様に、中継サーバ２００からクライアント端末１００へ信号を送信する際に用いる通信プロトコルはＸＭＰＰであるものとする。なお、本処理は、上述の各処理に加えて又は上述の各処理が用いられない場合であっても実行されうる。

図１３は、図３において、Ｓ５０５からＳ５０８までの間の処理の流れの例を詳細に示した図である。中継サーバ２００は、データベース２４０にジョブの通知があることを確認すると（Ｓ１１０１でＹＥＳ）、ジョブの存在を第２サーバ２２０のＣＰＵ２２４に通知する（Ｓ１１０２）。その後、ＣＰＵ２２４は、クライアント端末１００との間でＸＭＰＰセッションが確立されているかを判定する（Ｓ１１０３）。そして、ＣＰＵ２２４は、ＸＭＰＰセッションが確立されていると判定した場合（Ｓ１１０３でＹＥＳ）は、第３通信モジュール２２１を介して、クライアント端末１００の第１通信モジュール１１０へ、情報を送信する（Ｓ１１０４、Ｓ１１０５）。一方、ＸＭＰＰセッションが確立されていない場合（Ｓ１１０３でＮＯ）は、中継サーバ２００は、情報の送信を保留し、ジョブが存在していることを継続的に監視する。例えば、ジョブには有効期限が設定されており、この期限を経過するとジョブは削除されうる。ただし、この場合、ＣＰＵ２２４が、ジョブの有効期限内においてデータベース２４０と常に接続することとなるため、データベース２４０の負荷が増大しうる。そこで、クライアント端末１００を操作するユーザは、クライアント端末１００が想定されたジョブを実行しない場合（Ｓ１１２１でＮＯ）は、クライアント端末１００に中継サーバ２００とのＸＭＰＰセッションの確立処理を実行させうる（Ｓ１１１１）。例えば、ユーザは、予めクライアント端末１００に設けられたＸＭＰＰセッション確立機能を有効にするようにクライアント端末１００に対する操作を行うことにより、ＸＭＰＰセッションの確立処理を実行させる。中継サーバ２００は、ＸＭＰＰセッションが確立されていないと判定した場合には、その後のジョブの確認を行わず、クライアント端末１００との間でＸＭＰＰセッションを確立した時点で、有効期限内のジョブが存在しているか否かを判定してもよい。これにより、データベース２４０の負荷を低減することが可能となる。なお、ＸＭＰＰセッション確立機能は、例えば、第２サーバ２２０が新規に設置された場合などに利用されうる。

本処理のように、中継サーバ２００からクライアント端末１００へ情報を送信する際に、予めセッションの確立を確認することにより、セッションが確立されていないにも関わらずデータの送信のための処理が開始されてしまうことを防ぐことができる。また、クライアント端末１００がセッション確立機能を有することにより、中継サーバ２００内でのデータベース２４０への余計なアクセスの発生を防ぐことができる。また、クライアント端末１００主導で早期にセッションが確立されることで、中継サーバ２００にジョブが貯まることが少なくなる。このため、中継サーバ２００の負荷を低減することができ、かつ、クライアント端末１００が早期にジョブを実行することができる。

（別の構成例）
中継サーバ２００が、システムの状況を監視して、状況に応じた通信プロトコルの選択するようにしうる。中継サーバ２００は、例えば、システム全体の通信トラフィック、プッシュ型通信とプル型通信とのいずれが用いられているか、さらに、各サーバの負荷の状況を監視し、その状況に応じて通信プロトコルを変化させうる。また、中継サーバ２００は、各通信プロトコルの特性に応じて、利用する通信プロトコルを動的に選択しうる。

本例では、図１４に示すように、中継サーバ２００が、通信プロトコルとしてＸＭＰＰを利用する第２サーバ２２０に加え、さらに、ＭＱＴＴを通信プロコルとして利用する第３サーバ２６０を有する。第３サーバ２６０は、第２サーバ２２０と同様に、第５通信モジュール２６１、ＲＯＭ２６２、ＲＡＭ２６３、ＣＰＵ２６４、及び記憶装置２６５を含んで構成される。中継サーバ２００は、例えば、クライアント端末１００へのプッシュ通知にＸＭＰＰサーバ（第２サーバ２２０）を利用している間、そのＸＭＰＰサーバの負荷を監視する。そして、中継サーバ２００は、負荷が例えば所定値を超える程度に高い場合に、そのＸＭＰＰサーバの負荷低減のために、クライアント端末１００へのプッシュ通知を、ＭＱＴＴサーバ（第３サーバ２６０）を介したＭＱＴＴ通信によって実行しうる。これにより、中継サーバ２００は、負荷を分散し、安定したシステム運用を行うことが可能となる。このとき、通知のためのプッシュ通知は暗号化されてもよいし、暗号化されなくてもよい。

また、中継サーバ２００は、通信プロトコルの特性に応じて通信プロトコルを選択してもよい。例えば、一般的に、ＸＭＰＰプロトコルは通信時のオーバーヘッドが大きく、送信容量が大きくなる傾向があり、ＭＱＴＴではオーバーヘッドが小さ送信容量を抑えることが可能である。一方、ＸＭＰＰはセキュリティが強い特性がある。このため、中継サーバ２００は、秘匿性の少ないプッシュ通知のみを行う場合は暗号化せず、かつ、容量の小さいＭＱＴＴプロトコルを利用し、秘匿性の高い通信が必要な場合にはＸＭＰＰプロトコルを選択してもよい。このように、中継サーバ２００は、送信対象データの特性（容量、秘匿性等）に基づいて、使用する通信プロトコルを選択することができる。

このように、中継サーバ２００は、状況に応じて、クライアント端末１００へ情報を送信する際に用いる通信プロトコルを、柔軟かつ動的に変更することができる。これにより、情報処理システムが、クライアント端末１００やサービスサーバ３００の増加に柔軟に対応することが可能となり、かつ、情報セキュリティ技術を適切に適用することが可能となる。

なお、上述の各実施形態では、第２通信モジュール２１１が、クライアント端末１００からの信号の受信と、サービスサーバ３００との間の通信とで、共通のＨＴＴＰを用いるとしたが、これに限られない。例えば、第２通信モジュール２１１は、クライアント端末１００からの信号の受信のために第１のプロトコルを使用し、サービスサーバ３００との間の通信のために第２の通信プロトコルを離床するようにしてもよい。また、サービスサーバ３００への信号の送信とサービスサーバ３００からの信号の受信とで、それぞれ異なる通信プロトコルを用いてもよい。

（その他の実施形態）
本発明は、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワークまたは各種記憶媒体を介してシステムあるいは装置に供給し、そのシステムあるいは装置のコンピュータがプログラムを読み出して実行することでも実現される。この場合、そのプログラム、および該プログラムを記憶した記憶媒体は本発明を構成する。

１００：クライアント端末、１１０：第１通信モジュール、２００：中継サーバ、２１０：第１サーバ、２１１：第２通信モジュール、２２０：第２サーバ、２２１：第３通信モジュール、３００：サービスサーバ、３１０：第４通信モジュール

Claims (20)

1. サービスを提供するサーバと当該サービスを受ける端末との通信を中継する中継装置であって、
   第１の通信プロトコルに従って前記端末へ信号を送信する第１の通信手段と、
   前記第１の通信プロトコルと異なる第２の通信プロトコルに従って前記端末から信号を受信すると共に、前記サーバと通信を行う第２の通信手段と、
   を有することを特徴とする中継装置。
2. 前記第１の通信手段を含む第１のサーバと、前記第２の通信手段を含むと共に前記第１のサーバと異なる第２のサーバとを含む、
   ことを特徴とする請求項１に記載の中継装置。
3. 前記第２の通信手段は、前記サーバとの通信においても前記第２の通信プロトコルを使用する、
   ことを特徴とする請求項１又は２に記載の中継装置。
4. 前記第１の通信手段は、前記第２の通信手段が前記サーバから前記端末へ宛てたデータを受信した場合に、前記端末からの要求を受け付けることなく、当該データを前記端末へ送信する、
   ことを特徴とする請求項１から３のいずれか１項に記載の中継装置。
5. 前記第１の通信手段は、前記第２の通信手段が前記サーバから前記端末へ宛てたデータを受信した場合に、前記端末からの要求を受け付けたことに応じて、当該データを前記端末へ送信する、
   ことを特徴とする請求項１から３のいずれか１項に記載の中継装置。
6. 前記第２の通信手段は、前記端末から前記サーバへ宛てたデータを受信した場合に、前記サーバからの要求を受け付けることなく、当該データを前記サーバへ送信する、
   ことを特徴とする請求項１から５のいずれか１項に記載の中継装置。
7. 前記第２の通信手段は、前記端末から前記サーバへ宛てたデータを受信した場合に、前記サーバからの要求を受け付けたことに応じて、当該データを前記サーバへ送信する、
   ことを特徴とする請求項１から５のいずれか１項に記載の中継装置。
8. 前記端末を示す情報を含んだ第１のテーブルと、前記サーバが提供するサービスを示す情報と当該サービスの提供を受ける前記端末を示す情報とを含んだ第２のテーブルと、前記第１のテーブルと前記第２のテーブルとを関連付ける第３のテーブルとを記憶する記憶手段をさらに有する、
   ことを特徴とする請求項１から７のいずれか１項に記載の中継装置。
9. 前記記憶手段は、前記端末がサービスの提供を受ける前に、前記第１のテーブルに当該端末の情報を登録する、
   ことを特徴とする請求項８に記載の中継装置。
10. 前記記憶手段は、前記サーバが前記端末にサービスを提供する前に、前記第２のテーブルに当該サービスの情報と、当該サービスの提供を受ける前記端末の情報とを登録する、
    ことを特徴とする請求項８又は９に記載の中継装置。
11. 前記記憶手段は、前記端末がサービスの提供を受ける前に、前記第１のテーブルに登録される前記端末の情報が前記第２のテーブルに登録されている場合に、前記第２のテーブルにおいて当該端末の情報に対応するサービスの情報と、当該端末の情報とが対応付けられて前記第３のテーブルに登録する、
    ことを特徴とする請求項８から１０のいずれか１項に記載の中継装置。
12. 前記端末に情報を送信する際に、当該端末との間で前記第１の通信プロトコルによるセッションが確立されているか否かを確認する確認手段をさらに有し、
    前記第１の通信手段は、前記端末との間で前記第１の通信プロトコルによるセッションが確立されていることが確認されてから、当該端末へ信号を送信する、
    ことを特徴とする請求項１から１１のいずれか１項に記載の中継装置。
13. 前記端末に対するユーザの操作に応じて、前記第１の通信プロトコルによるセッションが、前記中継装置と前記端末の間で確立される、
    ことを特徴とする請求項１２に記載の中継装置。
14. 前記第１の通信プロトコルおよび前記第２の通信プロトコルと異なる第３の通信プロトコルで前記端末へ信号を送信する第３の通信手段をさらに有し、
    前記第１の通信手段の負荷と、送信される情報の特性との少なくともいずれかに基づいて、前記第１の通信手段と前記第３の通信手段とのいずれによって前記端末へ信号を送信するかを選択する、
    ことを特徴とする請求項１から１３のいずれか１項に記載の中継装置。
15. 前記第３の通信プロトコルは、ＭＱＴＴ（Ｍｅｓｓａｇｅ Ｑｕｅｕｉｎｇ Ｔｅｌｅｍｅｔｒｙ Ｔｒａｎｓｐｏｒｔ）プロトコルを含む、
    ことを特徴とする請求項１４に記載の中継装置。
16. 前記第１の通信プロトコルが、ＭＱＴＴ（Ｍｅｓｓａｇｅ Ｑｕｅｕｉｎｇ Ｔｅｌｅｍｅｔｒｙ Ｔｒａｎｓｐｏｒｔ）プロトコルを含む、
    ことを特徴とする請求項１から１４のいずれか１項に記載の中継装置。
17. 前記第１の通信プロトコルが、ＸＭＰＰ（Ｅｘｔｅｎｓｉｂｌｅ Ｍｅｓｓａｇｅｉｎｇ ａｎｄ Ｐｒｅｓｅｎｃｅ Ｐｒｏｔｏｃｏｌ）を含む、
    ことを特徴とする請求項１から１５のいずれか１項に記載の中継装置。
18. 前記第２の通信プロトコルが、ＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）を含む、
    ことを特徴とする請求項１から１７のいずれか１項に記載の中継装置。
19. サービスを提供するサーバと当該サービスを受ける端末との通信を中継する中継装置が実行する制御手段であって、
    第１の通信プロトコルに従って前記端末へ信号を送信するように第１の通信手段を制御する工程と、
    前記第１の通信プロトコルと異なる第２の通信プロトコルに従って前記端末から信号を受信すると共に、前記サーバと通信を行うように第２の通信手段を制御する工程と、
    を有することを特徴とする制御方法。
20. サービスを提供するサーバと当該サービスを受ける端末との通信を中継する中継装置に備えられたコンピュータに、
    第１の通信プロトコルに従って前記端末へ信号を送信するように第１の通信手段を制御させ、
    前記第１の通信プロトコルと異なる第２の通信プロトコルに従って前記端末から信号を受信すると共に、前記サーバと通信を行うように第２の通信手段を制御させる、
    ためのプログラム。

Images