JP2015225405A - 通信システムおよびその制御方法、端末およびその制御方法、並びにプログラム - Google Patents

Abstract

【課題】顧客からの遠隔保守サービス開始要求発生時に、支援対象の画像形成装置と通信するための情報を、適切な販売組織のコールセンターに通知する方法を提供する。
【解決手段】複数の端末、複数の端末を管理する管理サーバ１３０、および、端末間の通信の中継を行う中継サーバ１２０を含む通信システムであって、複数の端末のうちの第一の端末は、中継サーバ１２０に接続した際に取得した接続情報を管理サーバ１３０に送信する送信手段を有し、管理サーバ１３０は、第一の端末から受信した接続情報を、第一の端末と通信する際に中継サーバ１２０に接続するための情報として、複数の端末のうちの第二の端末に通知する通知手段を有する。
【選択図】図１

Description

本発明は、通信システムおよびその制御方法、端末およびその制御方法、並びにプログラムに関する。

従来、製品のトラブル対応の処置が複雑になるにつれ、顧客が直接メーカーのコールセンターに質問し、回答を得るということが頻繁に行われている。さらに、画像形成装置とコールセンター間のトラブル対応を迅速に行うため、音声や動画通信、遠隔操作による遠隔保守サービスが提供されている。

上記のような遠隔保守サービスにおいて、支援を受ける画像形成装置や、支援を行うコールセンターの情報処理装置は、一般的にファイアウォールの内側に配置される。それぞれ異なるイントラネットに位置する画像形成装置と情報処理装置が通信を行うために、インターネット上に両者の通信を中継する中継サーバを設置することが提案されている（例えば、特許文献１参照）。このような中継サーバを設置することによって、ファイアウォール内にある装置同士の通信が可能となる。

特開２０１３−２９９２２号公報

特許文献１の技術を遠隔保守サービスに適用する場合、顧客からの遠隔保守サービスの開始要求を受けて、画像形成装置とコールセンターが中継サーバに接続する必要がある。コールセンターは、遠隔保守サービス開始の旨を検知する必要がある。これに加えて、コールセンターは、支援対象の画像形成装置と通信する為の情報を知る必要がある。この時、中継サーバは１台とは限らない。また、中継サーバ内の中継用セッションも一つとは限らない。故に、支援対象の画像形成装置と通信する為の情報には、例えば、中継サーバのアドレスと中継用セッション情報が含まれる。

また、一般的に、コールセンターは画像形成装置の販売組織毎に運営される。よって、遠隔保守サービス開始の通報は、その画像形成装置を管理している販売組織のコールセンターに正しく通知されなければならない。そのためには、遠隔保守サービス適用対象となる全ての画像形成装置を対象として、其々がどの販売組織に属しているかの情報が適切に管理されている必要がある。

以上を鑑み、本発明では、遠隔保守サービスの開始要求発生時に、支援対象の画像形成装置と通信するための情報を、適切な販売組織のコールセンターに通知する方法を提供する。

上記課題を解決するために本願発明は以下の構成を有する。すなわち、複数の端末、前記複数の端末を管理する管理サーバ、および、端末間の通信の中継を行う中継サーバを含む通信システムであって、前記複数の端末のうちの第一の端末は、前記中継サーバに接続した際に取得した接続情報を前記管理サーバに送信する送信手段を有し、前記管理サーバは、前記第一の端末から受信した接続情報を、前記第一の端末と通信する際に前記中継サーバに接続するための情報として、前記複数の端末のうちの第二の端末に通知する通知手段を有する。

本発明によれば、画像形成装置からの遠隔保守サービスの開始要求に応じて、適切な販売組織のコールセンターが遠隔保守サービスを開始することができる。

本発明の一実施形態に係る通信システムの全体構成の例を示す図。 本発明の一実施形態に係るＭＦＰの構成例を示す図。 本発明の一実施形態に係る各装置の構成例を示す図。 本発明の一実施形態に係るシーケンスを示す図。 本発明の一実施形態に係るＭＦＰの動作を示すフローチャート。 本発明の一実施形態に係るＰＣの動作を示すフローチャート。 本発明の一実施形態に係る中継サーバの動作を示すフローチャート。 本発明の一実施形態に係る管理サーバの動作を示すフローチャート。 本発明の一実施形態に係るＭＦＰ情報の一例を示す図。 本発明の一実施形態に係るＭＦＰと中継サーバの接続時通信例を示す図。 本発明の一実施形態に係る中継サーバの支援ＵＲＬ発行通信例を示す図。 本発明の一実施形態に係るＰＣの中継サーバ接続通信例を示す図。 本発明の実施形態に係るＭＦＰの詳細動作を示すフローチャート。

以下、図面を参照して本発明を実施する形態を詳しく説明する。なお、以下の実施の形態は特許請求の範囲に係る発明を限定するものでなく、また実施の形態で説明されている特徴の組み合わせの全てが発明の解決手段に必須のものとは限らない。

［システム構成］
図１は、本願発明の一実施形態に係る通信システムの全体構成の例を示す図である。画像形成装置の一例であるＭＦＰ（Ｍｕｌｔｉ Ｆｕｎｃｔｉｏｎ Ｐｅｒｉｐｈｅｒａｌ）１００は、ユーザ環境１０２の中に配置され、ユーザによって操作される。画像形成装置は、ＭＦＰに限定するものではなく、例えば、単機能のネットワークプリンタやスキャナ等であってもよい。ＰＣ１１０は、情報処理装置であり、コールセンター１１２の中に配置され、オペレータによって操作される。ここでの情報処理装置は、ＰＣに限定するものではなく、例えば、タブレット端末やサーバ装置など、他の情報処理装置であってもよい。また、ユーザ環境１０２およびコールセンター１１２は、通信システム内の複数の拠点として存在してよく、図１に示す以外にも更に多くのＭＦＰ、ＰＣが含まれてもよい。

ユーザ環境１０２とコールセンター１１２にはそれぞれ、外部ネットワークであるインターネット１４０と接続する位置に、ファイアウォール１０１、１１１が設置されている。ファイアウォール１０１は、ユーザ環境１０２の内側にある端末（ＭＦＰ１００）からインターネット１４０への接続は許可するが、インターネット１４０側からユーザ環境１０２の内側にある端末への接続は拒否するように構成される。同様に、ファイアウォール１１１は、コールセンター１１２の内側にある端末（ＰＣ１１０）からインターネット１４０への接続は許可するが、インターネット１４０側からコールセンター１１２の内側にある端末への接続は拒否するように構成される。

中継サーバ群１２１は、インターネット１４０を介して中継サービスを提供する１または複数のサーバコンピュータ（中継サーバ１２０）からなるサーバ群である。物理的に複数の中継サーバ１２０により構成される場合には、負荷分散装置１２２や負荷分散プログラムなどを利用して、複数の中継サーバ１２０を仮想的に一つのサーバであるかのようにふるまわせてもよい。このように負荷分散装置を利用することにより、複数台の中継サーバはそれぞれのハードウェアリソースを効率よく利用できるようになる。図１においては中継サーバ１２０が１台のみ設置される拠点と、負荷分散装置を用いて複数台の中継サーバが設置される拠点を図示している。

ＭＦＰ１００およびＰＣ１１０は、ＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）によるデータ通信機能を備える。ＨＴＴＰによるデータ通信において、クライアントノード同士は、ＨＴＴＰ中継サーバから提供されるＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）にＰＯＳＴメソッド及びＧＥＴメソッドを繰り返し行うことでデータ通信を実施する。本実施形態ではＰＯＳＴメソッドを繰り返し行うことを「ＰＯＳＴポーリング」と呼び、ＧＥＴメソッドを繰り返し行うことを「ＧＥＴポーリング」と呼ぶ。これにより、クライアントノード同士がプライベートアドレスエリアやファイアウォールに遮られていてもデータ通信を行うことができる。

本実施形態では、ＭＦＰ１００およびＰＣ１１０は、ＨＴＴＰクライアントノードとして動作する。また、ＭＦＰ１００には自身を監視するモジュールが組み込まれている。このモジュールは、ＭＦＰ１００のステータスを監視し、管理サーバ１３０へＭＦＰ１００の状態を通知する。本実施形態において、中継サーバ１２０がＨＴＴＰ中継サーバとして動作する。管理サーバ１３０は、インターネット１４０上に設置され、ユーザ環境１０２それぞれに設置されているＭＦＰ１００内の監視モジュールと通信を行う事により、ＭＦＰ１００の情報を収集し、管理する。管理サーバ１３０の収集するＭＦＰの情報（以下、管理情報）は、カウンタ値、稼動ログ、ＭＦＰ内に複数使用されている各部品の消耗度を表す部品カウンタ値などの稼動情報、及びハード障害やジャム等の障害情報などを含む。

管理サーバ１３０は、管理するすべてのＭＦＰ１００が複数設けられたコールセンター１１２のうち、いずれによって管理されているかを対応づけたＭＦＰ情報テーブル１３１を保管する。ＭＦＰ情報テーブル１３１についての詳細は図９を用いて後述する。ＭＦＰ情報テーブル１３１により、ＭＦＰ１００の基本的な利用状況や、障害発生時の緊急連絡などを、適切なコールセンター１１２へ提供することができる。具体的には、管理サーバ１３０のユーザであるオペレータは、管理サーバ１３０にログインすると、監視対象のＭＦＰ１００から収集した管理情報をＰＣ１１０の表示部に表示させ、ＭＦＰ１００の状態を監視することができる。また、サービスコールエラーやハード障害などの緊急性の高い情報は、対応テーブルに記載の通知先へメールを送信することで通知することができる。

また、ＭＦＰ１００と管理サーバ１３０との通信により、ＭＦＰ１００が中継サーバ１２０に接続した情報も、イベント情報として即時に管理サーバ１３０を介してオペレータに通知される。管理サーバ１３０は、ＭＦＰ１００とそれに対応するコールセンター１１２の情報を管理する。また、本実施形態では、ＭＦＰ１００およびＰＣ１１０は、インターネット１４０に対してファイアウォール１０１、１１１を介して通信する構成であるが、ファイアウォール１０１、１１１を介さないネットワーク構成でもよい。また、通信プロトコルとして、ＨＴＴＰ以外のプロトコルを用いてもよい。

なお、本実施形態において、ＰＣ１１０のオペレータがＭＦＰ１００のユーザを支援するためにＰＣ１１０とＭＦＰ１００間で送受信される各種データを「支援データ」と呼ぶ。また、本実施形態において便宜上、問い合わせを行う側のＭＦＰ１００を「第一の端末」とも記載し、問い合わせを受ける側であるコールセンター１１２のＰＣ１１０を「第二の端末」とも記載する。

［装置構成］
図２は、ＭＦＰ１００の構成例を示す図である。ＣＰＵ２１１を含む制御部２１０は、ＭＦＰ１００全体の動作を制御する。ＣＰＵ２１１は、ＲＯＭ２１２に記憶された各種制御プログラムを読み出し読取装置や送信制御などの各種制御を行う。ＲＡＭ２１３は、ＣＰＵ２１１の主メモリ、ワークエリア等の一時記憶領域として用いられる。なお、ＭＦＰ１００の場合、１つのＣＰＵ２１１が１つのメモリ（ＲＡＭ２１３またはＨＤＤ２１４）を用いて後述するフローチャートに示す各処理を実行するものとするが、他の態様であっても構わない。例えば、複数のＣＰＵや複数のＲＡＭまたはＨＤＤを協働させてフローチャートに示す各処理を実行するようにしてもよい。ＨＤＤ２１４は、画像データや各種プログラムを記憶する。

操作部Ｉ／Ｆ２１５は、操作部２１９と制御部２１０とを接続する。操作部２１９には、タッチパネル機能を有する液晶表示部（不図示）やキーボード（不図示）などが備えられる。プリンタＩ／Ｆ２１６は、プリンタ２２０と制御部２１０とを接続する。プリンタ２２０で印刷すべき画像データはプリンタＩ／Ｆ２１６を介して制御部２１０から転送され、プリンタ２２０において記録媒体上に印刷される。スキャナＩ／Ｆ２１７は、スキャナ２２１と制御部２１０とを接続する。スキャナ２２１は、原稿上の画像を読み取って画像データ（画像ファイル）を生成し、スキャナＩ／Ｆ２１７を介して制御部２１０に入力する。ＭＦＰ１００は、スキャナ２２１で生成された画像データ（画像ファイル）をファイル送信またはメール送信することができる。ネットワークＩ／Ｆ２１８は、制御部２１０をインターネット１４０に接続する。

図３は、ＰＣ１１０、中継サーバ１２０、および管理サーバ１３０の構成例を示す図である。ＣＰＵ３１１を含む制御部３１０は、装置全体の動作を制御する。ＣＰＵ３１１は、ＲＯＭ３１２に記憶された制御プログラムを読み出して各種制御処理を実行する。ＲＡＭ３１３は、ＣＰＵ３１１の主メモリ、ワークエリア等の一時記憶領域として用いられる。ＨＤＤ３１４は、画像データや各種プログラムを記憶する。操作部Ｉ／Ｆ３１５は、操作部３１７と制御部３１０を接続する。操作部３１７には、タッチパネル機能を有する液晶表示部やキーボード、マウスなどが備えられる。ネットワークＩ／Ｆ３１６は、制御部３１０をインターネット１４０に接続する。

なお、図２および図３にて示した各装置のハードウェア構成は一例であり、その他の部位を備えていても構わない。

［処理シーケンス］
図４は、操作支援時のＭＦＰ１００、ＰＣ１１０、中継サーバ１２０、および管理サーバ１３０のシーケンス図である。本シーケンス図の動作は、各処理主体のＣＰＵがＨＤＤ等に格納された本処理シーケンスに係る制御プログラムを読み出して実行することにより実現される。

ＭＦＰ１００は、ユーザにより操作部２１９から支援開始要求が入力されると、中継サーバ１２０へログインを行う（Ｓ４０１）。ＭＦＰ１００は、中継サーバ１２０へ支援ＵＲＬ作成要求を行う（Ｓ４０２）。中継サーバ１２０は、支援ＵＲＬを作成する（Ｓ４０３）。本実施形態において、ＭＦＰ１００およびＰＣ１１０が中継サーバ１２０に対してＰＯＳＴ要求、ＧＥＴ要求を送信する際には、共通のＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）を指定する必要がある。以下、このＵＲＬを「支援ＵＲＬ」と呼ぶ。支援ＵＲＬは、複数存在してもよく、支援ＵＲＬ毎に中継サーバ１２０のＲＡＭ２１３のバッファリング領域が割り当てられることになる。また、中継サーバ１２０は、ＭＦＰ１００やＰＣ１１０から支援ＵＲＬへの参加要求を受信すると、ＭＦＰ１００やＰＣ１１０の情報を参加者としてＲＡＭ２１３にバッファリングする。ここでの「参加要求」とは、中継サーバ１２０にて作成した支援ＵＲＬを用いて、複数の装置間で連携を行う際に発行される要求を指す。一方、参加後に連携を解除する際には、「脱退要求」が送信されることとなる。また、中継サーバ１２０は、参加しているユーザの情報を参加者情報として保持しているものとする。

一方、中継サーバ１２０は、ＭＦＰ１００やＰＣ１１０から支援ＵＲＬへの参加者情報のＧＥＴポーリングを受信すると、ＲＡＭ２１３にバッファリングされた参加者の更新情報をＭＦＰ１００やＰＣ１１０に返す。また、中継サーバ１２０は、ＭＦＰ１００やＰＣ１１０から支援ＵＲＬへの脱退要求を受信すると、ＲＡＭ２１３にバッファリングされた参加者情報から対応する情報を削除する。中継サーバ１２０は、ＭＦＰ１００やＰＣ１１０から支援ＵＲＬへの支援データのＰＯＳＴポーリングを受信すると、支援データをＲＡＭ２１３にバッファリングする。支援データとしては、例えば、動画や音声、または遠隔操作の命令データなどが挙げられる。

一方、中継サーバ１２０は、ＭＦＰ１００やＰＣ１１０から支援ＵＲＬにＧＥＴポーリングされると、ＲＡＭ２１３にバッファリングされた支援データをＭＦＰ１００やＰＣ１１０に返す。なお、支援ＵＲＬは複数存在してもよく、支援ＵＲＬ毎にＲＡＭ２１３のバッファリング領域が割り当てられることになる。中継サーバ１２０は、支援ＵＲＬをＭＦＰ１００に送信する（Ｓ４０４）。ＭＦＰ１００は、支援ＵＲＬへ参加要求を送信する（Ｓ４０５）。ＭＦＰ１００は、支援ＵＲＬへ参加者情報のＧＥＴポーリングを開始する（Ｓ４０６）。

ＭＦＰ１００は、自身のＭＦＰ識別子と中継サーバ１２０から割り当てられた支援ＵＲＬを管理サーバ１３０に送信する（Ｓ４０７）。ＭＦＰ識別子は、ＭＦＰを特定するための全世界でユニークな識別子である。詳細は後述するが、管理サーバ１３０は、ＭＦＰ１００とコールセンター１１２の対応テーブルを持つ。この対応テーブル（対応情報）により、ＭＦＰが複数のコールセンターのうちのいずれのコールセンターに管理、保守され、遠隔保守サービスが提供されるかが示される。

管理サーバ１３０は、ＭＦＰ識別子から通知先のコールセンター１１２を特定した上で、ＰＣ１１０に支援ＵＲＬと管理サーバＵＲＬを送信する（Ｓ４０８）。本実施形態では、Ｓ４０８の送信に使用するプロトコルは電子メールとするが、電子メール以外でもよい。例えば、ファイアウォール１１１を超えるために、ＰＣ１１０から管理サーバ１３０へＨＴＴＰのＧＥＴポーリングを行うことによって、データを取得する方法であってもよい。詳細は後述するが、管理サーバ１３０は、ＭＦＰ情報としてＭＦＰのエラー履歴を管理する。各装置は、管理サーバ１３０のＵＲＬ（以下、管理サーバＵＲＬ）に接続することにより、ＭＦＰ１００のエラー履歴を取得できる。オペレータは、ＭＦＰ１００を支援する際に、過去のエラー発生状況を参考にすることが可能となる。本実施形態では、ＭＦＰ情報の一例としてエラー履歴を扱うが、部品交換情報やカウンタ情報等、他の情報であってもよい。

オペレータ側であるＰＣ１１０は、支援ＵＲＬへ参加要求を送信する（Ｓ４０９）。中継サーバ１２０は、参加者情報をＭＦＰ１００に送信する（Ｓ４１０）。ＭＦＰ１００とＰＣ１１０は、支援ＵＲＬへの支援データのＰＯＳＴポーリング及びＧＥＴポーリングを開始する（Ｓ４１１、Ｓ４１２）。ＰＣ１１０は、管理サーバＵＲＬへＭＦＰ情報の取得要求を送信する（Ｓ４１３）。管理サーバ１３０は、ＰＣ１１０へ、ＭＦＰ１００のＭＦＰ情報を送信する（Ｓ４１４）。オペレータによる支援が終了すると、ＭＦＰ１００およびＰＣ１１０は、支援ＵＲＬへ脱退要求を送信する（Ｓ４１５，Ｓ４１６）。中継サーバ１２０は、不要になった支援ＵＲＬを破棄する（Ｓ４１７）。そして、本シーケンスを終了する。

［処理フロー］
以下に各処理主体における処理フローについて説明する。なお、図５〜図８、図１３は、図４にて示した各主体の処理シーケンスに対応する。

（ＭＦＰ）
図５は、ユーザ環境１０２のユーザ側であるＭＦＰ１００の動作を説明するフローチャートである。図５のフローチャートに示す各動作（ステップ）は、ＭＦＰ１００のＣＰＵ２１１がＨＤＤ２１４に記憶された制御プログラムを実行することによって実現される。

ＣＰＵ２１１は、ＭＦＰ１００にエラーが発生したことを検知する（Ｓ５０１）。ＣＰＵ２１１は、管理サーバ１３０へエラーを送信する（Ｓ５０２）。なお、ＭＦＰ１００は、エラーの重要度や緊急度を基にエラーのレベル分けをし、レベルの高いエラーのみを管理サーバ１３０へ送信する構成としてもよい。この場合、レベルに関する情報は予め定義され、ＨＤＤ２１４等に保持されているものとする。ＣＰＵ２１１は、ユーザによる操作部２１９から支援開始要求の入力を受け付けるまで待機する（Ｓ５０３）。

支援開始要求の入力を検知すると（Ｓ５０３にてＹＥＳ）、ＣＰＵ２１１は、中継サーバ１２０へログインする（Ｓ５０４）。ＣＰＵ２１１は、中継サーバ１２０へＭＦＰ１００が中継サーバ１２０へ問題なくログインできたか否かを判定する（Ｓ５０５）。ログインに成功した場合（Ｓ５０５にてＹＥＳ）、ＣＰＵ２１１は、中継サーバ１２０へ支援ＵＲＬ作成要求を送信する（Ｓ５０６）。ＣＰＵ２１１は、中継サーバ１２０から支援ＵＲＬを受信する（Ｓ５０７）。ＣＰＵ２１１は、支援ＵＲＬへ参加要求を送信する（Ｓ５０８）。ＣＰＵ２１１は、支援ＵＲＬへ参加者情報のＧＥＴポーリングを開始する（Ｓ５０９）。ＣＰＵ２１１は、管理サーバ１３０へ自身のＭＦＰ識別子と中継サーバ１２０から受信した支援ＵＲＬを送信する（Ｓ５１０）。ＣＰＵ２１１は、ＭＦＰ１００が管理サーバ１３０へ送信が成功したか否かを判定する（Ｓ５１１）。

管理サーバ１３０へ送信が成功した場合（Ｓ５１１にてＹＥＳ）、ＣＰＵ２１１は、中継サーバ１２０から参加者情報を受信する（Ｓ５１２）。ＣＰＵ２１１は、支援ＵＲＬへ支援データのＰＯＳＴポーリンとＧＥＴポーリングを開始する（Ｓ５１３）。支援データとしては、例えば、動画や音声、または遠隔操作の命令データなどが挙げられる。これにより、ＭＦＰ１００のユーザは、オペレータから、音声や動画通信、遠隔操作による支援を受けることが可能となる。支援が終了すると、ＣＰＵ２１１は、ユーザによる操作部２１９から支援停止要求の入力を受け付けるまで待機する（Ｓ５１４）。操作部２１９から支援停止要求の入力を受けると（Ｓ５１４にてＹＥＳ）、ＣＰＵ２１１は、支援ＵＲＬへ脱退要求を送信する（Ｓ５１５）。そして、本処理フローを終了する。

一方、ログインに失敗した場合（Ｓ５０５にてＹＥＳ）、ＣＰＵ２１１は、管理サーバ１３０に中継サーバ１２０への接続失敗を送信する（Ｓ５１６）。ＣＰＵ２１１は、管理サーバ１３０へ送信が成功したか否かを判定する（Ｓ５１７）。ＣＰＵ２１１は、管理サーバ１３０へ送信が成功した場合（Ｓ５１７にてＹＥＳ）、ＣＰＵ２１１は、コールセンターへ通知した旨を操作部２１９へ表示し（Ｓ５１８）、本処理フローを終了する。

一方、管理サーバ１３０へ送信が失敗した場合（Ｓ５１７にてＮＯ）、ＣＰＵ２１１は、コールセンターの電話番号と連絡を促すメッセージを操作部２１９へ表示し（Ｓ５１９）、本処理フローを終了する。この場合、例えば、ユーザは表示された電話番号等を用いて、コールセンターへ連絡することとなる。

一方、管理サーバ１３０へ送信が失敗した場合（Ｓ５１１にてＮＯ）、ＣＰＵ２１１は、中継サーバ１２０にて発行された支援ＵＲＬ、コールセンターの電話番号と連絡を促すメッセージを操作部２１９へ表示し（Ｓ５２０）、本処理フローを終了する。この場合、例えば、ユーザは表示された電話番号等を用いて、コールセンターへ連絡することとなる。

（ＰＣ）
図６は、コールセンター１１２のオペレータ側であるＰＣ１１０の動作を説明するフローチャートである。図６のフローチャートに示す各動作（ステップ）は、ＰＣ１１０のＣＰＵ３１１がＨＤＤ３１４に記憶された制御プログラムを実行することによって実現される。

ＣＰＵ３１１は、支援ＵＲＬおよび管理サーバＵＲＬを管理サーバ１３０から受信する（Ｓ６０１）。ＣＰＵ３１１は、受信した支援ＵＲＬおよび管理サーバＵＲＬを、操作部３１７に表示する（Ｓ６０２）。これは、受信した電子メールの情報をそのまま操作部３１７に表示する構成でもよいし、アプリケーション画面として表示する構成でもよい。ＣＰＵ３１１は、オペレータにより操作部３１７から支援ＵＲＬへの接続の入力を受け付けるまで待機する（Ｓ６０３）。支援ＵＲＬ接続の入力を受け付けると（Ｓ６０３にてＹＥＳ）、ＣＰＵ３１１は、支援ＵＲＬへ参加要求を送信する（Ｓ６０４）。ＣＰＵ３１１は、支援ＵＲＬへ支援データのＰＯＳＴ、ＧＥＴポーリングを開始する（Ｓ６０５）。これにより、オペレータは、ＭＦＰ１００のユーザに対して、音声や動画通信、遠隔操作による支援を行うことが可能となる。

ＣＰＵ３１１は、オペレータにより操作部３１７から管理サーバＵＲＬへの接続の入力を受け付けるまで待機する（Ｓ６０６）。管理サーバＵＲＬへの接続の入力を受けると（Ｓ６０６にてＹＥＳ）、管理サーバＵＲＬへＭＦＰ情報要求を送信する（Ｓ６０７）。ＣＰＵ３１１は、管理サーバ１３０からＭＦＰ情報を受信する（Ｓ６０８）。ＣＰＵ３１１は、ＭＦＰ情報を操作部３１７に表示する（Ｓ６０９）。これにより、オペレータは、支援を行う際に、ＭＦＰ１００の過去のエラー発生状況を参考にすることが可能となる。支援が終了すると、ＣＰＵ３１１は、操作部３１７から支援停止要求の入力を受け付けるまで待機する（Ｓ６１０）。

操作部３１７から支援停止要求を受けると（Ｓ６１０にてＹＥＳ）、ＣＰＵ３１１は、支援ＵＲＬへ脱退要求を送信する（Ｓ６１１）。そして、本処理フローを終了する。

（中継サーバ）
図７は、中継サーバ１２０の動作を説明するフローチャートである。図７のフローチャートに示す各動作（ステップ）は、中継サーバ１２０のＣＰＵ３１１がＨＤＤ３１４に記憶された制御プログラムを実行することによって実現される。

ＣＰＵ３１１は、ＭＦＰ１００からログインを受信するまで待機する（Ｓ７０１）。ＭＦＰ１００からログインを受けると（Ｓ７０１にてＹＥＳ）、ＣＰＵ３１１は、支援ＵＲＬ作成要求を受信する（Ｓ７０２）。ＣＰＵ３１１は、支援ＵＲＬを作成する（Ｓ７０３）。ＣＰＵ３１１は、ＭＦＰ１００へ支援ＵＲＬを送信する（Ｓ７０４）。ＣＰＵ３１１は、ＭＦＰ１００から支援ＵＲＬへの参加要求を受信する（Ｓ７０５）。ＣＰＵ３１１は、ＭＦＰ１００から参加者情報のＧＥＴポーリングを受信する（Ｓ７０６）。

ＣＰＵ３１１は、ＰＣ１１０から支援ＵＲＬへの参加要求を受信する（Ｓ７０７）。ＣＰＵ３１１は、ＭＦＰ１００へ参加者情報を送信する（Ｓ７０８）。ＣＰＵ３１１は、ＭＦＰ１００とＰＣ１１０から支援データのＰＯＳＴ、ＧＥＴポーリングを受信する（Ｓ７０９）。これにより、ＭＦＰ１００とＰＣ１１０間で支援データが送受信され、その上でコールセンター側のオペレータは、ユーザ環境側のユーザに対して支援を行うことができる。支援が終了すると、ＣＰＵ３１１は、ＭＦＰ１００およびＰＣ１１０から支援ＵＲＬへ脱退要求を受信するまで待機する（Ｓ７１０）。支援ＵＲＬへの脱退要求を受信すると（Ｓ７１０にてＹＥＳ）、ＣＰＵ３１１は、支援ＵＲＬを破棄する（Ｓ７１１）。そして、本処理フローを終了する。

（管理サーバ）
図８は、本実施形態に係る管理サーバ１３０の動作を説明するフローチャートである。図８のフローチャートに示す各動作（ステップ）は、管理サーバ１３０のＣＰＵ３１１がＨＤＤ３１４に記憶された制御プログラムを実行することによって実現される。

ＣＰＵ３１１は、ＭＦＰ１００からＭＦＰ識別子と支援ＵＲＬを受信するまで待機する（Ｓ８０１）。ＭＦＰ識別子と支援ＵＲＬを受信すると（Ｓ８０１にてＹＥＳ）、ＣＰＵ３１１は、ＰＣ１１０へ支援ＵＲＬおよび管理サーバＵＲＬを送信する（Ｓ８０２）。ＣＰＵ３１１は、ＰＣ１１０から管理サーバＵＲＬへのＭＦＰ情報要求を受信するまで待機する（Ｓ８０３）。ＭＦＰ情報要求を受信すると（Ｓ８０３にてＹＥＳ）、ＣＰＵ３１１は、ＰＣ１１０へＭＦＰ情報を送信する（Ｓ８０４）。そして、本処理フローを終了する。

（ＭＦＰ情報）
図９は、管理サーバ１３０のＨＤＤ３１４に記憶されているＭＦＰ情報の構成例を示す図である。情報９１０は、ＭＦＰを一意に識別するための情報（ＭＦＰＩＤ）である。情報９１０は、図７のＳ４０７に示すＭＦＰ識別子に該当する。情報９１１は、ＭＦＰの製品名称を示す情報である。情報９１２は、ＭＦＰの過去の通報を一意に識別するための情報（通報ＩＤ）である。情報９１２は、通報の数に応じて複数あってもよい。情報９１３は、通報の時刻を示す情報である。情報９１４は、通報の内容を示す情報である。情報９１５は、通報のステータスを示す情報である。情報９１２〜９１５は、図４のＳ４１３およびＳ４１４に示すＭＦＰ情報に該当する。

情報９２０は、ＭＦＰの顧客（所有者）を一意に識別するための情報（顧客ＩＤ）である。情報９２１は、顧客の名称を示す情報である。情報９３０は、ＭＦＰが属するコールセンターを一意に識別するための情報（コールセンターＩＤ）である。ここでは、コールセンターと表現しているが、ＭＦＰの販売、管理を行う販売会社であってもよい。また、コールセンター、顧客、およびＭＦＰは、階層構造として管理サーバ１３０へ登録することができ、販売会社の下には複数の顧客を、顧客の下には複数のＭＦＰを登録することができる。情報９３１は、コールセンターの名称を示す情報である。情報９３２は、コールセンターのメールアドレスを示す情報である。情報９３２は、図４のＳ４０８に示す電子メールの送信先として用いられる情報である。

情報９４０は、支援作業を一意に識別するための情報（支援ＩＤ）である。図４のＳ４０７にて、ＭＦＰ１００から管理サーバ１３０にＭＦＰ識別子と支援ＵＲＬが送信されたタイミングで、情報９４０は更新される。情報９４１は、支援ＵＲＬを示す情報である。情報９４１は、図４のＳ４０７に示す支援ＵＲＬに該当する。

以上により、ＭＦＰ１００からの支援開始要求に応じて、ＰＣ１１０は、ＭＦＰ１００の支援を開始することが可能となる。

［本実施形態に係る処理］
上記説明では、ＭＦＰ１００が、中継サーバ１２０から受信した支援ＵＲＬを管理サーバ１３０を介してＰＣ１１０へ通知し、ＭＦＰ１００からの通信セッションとＰＣ１１０からの通信セッションとが中継サーバ１２０にて「待ち合わせ」を行う。この通信セッションの待ち合わせにより、各ローカルネットワークからの接続を関連付け、ＭＦＰ１００とＰＣ１１０の通信を確立する。

しかし、コールセンターがサポートするＭＦＰの管理台数が数万台のような大規模になると、その接続を支える中継サーバは、複数台のコンピュータを準備し多数のセッションを関連付ける必要がある。このとき、複数のコンピュータを用意しただけでは、各サーバのＩＰアドレスが分散してしまい、効率よく中継サーバのコンピュータリソースを使用することができない。このような場合に、負荷分散装置などを利用して、一つのＩＰアドレスに対して、複数のコンピュータに通信を振り分ける技術が知られている。しかし、本願発明のような通信セッションの待ち合わせを同一コンピュータによって確立させなければならない場合には、負荷分散の仕組みを組み合わせにくいという課題がある。

本願発明では、負荷分散環境を備えた中継サーバにおいても、端末間の通信セッションの待ち合わせを可能とし、通信セッションの関連付けを行う方法について説明する。

（通信データ）
図１０は、ＭＦＰ１００が中継サーバ１２０へログインする際の通信データの構成例を示している。ここでは、ＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）形式にて記述されている。これらのデータは、図４のＳ４０１にてＭＦＰ１００から送信されるデータに相当する。

図１０（ａ）は、ＭＦＰ１００がＨＴＴＰ、または、ＨＴＴＰＳを利用して中継サーバ１２０へ送信するログイン要求情報の構成例を表している。この例では、ログインのためのアカウント情報（＜ｕｓｅｒｎａｍｅ＞タグ）は、ＭＦＰ１００を一意に識別するためのＩＤであり、ＭＦＰ１００のシリアル番号で表されている。このデータは、図４のＳ４０１にて送信されるデータである。中継サーバ１２０は、図１０（ａ）のログイン要求を受け付けた場合、次回から同じリクエスタとの通信とその他の通信を区別して認識できるように、レスポンスにセッションＩＤを付与して、図１０（ｂ）に示すデータにて返す。これは、一般的にＨＴＴＰ通信においてＣｏｏｋｉｅが利用できるクライアントに対して発行されるセッション情報であり、ここではＣｏｏｋｉｅオプションによるセッションＩＤと呼ぶ。ここでは、Ｃｏｏｋｉｅオプションについての詳細な説明は省略する。

図１０（ｂ）のＨＴＴＰヘッダ中の３行目のＳｅｔ−Ｃｏｏｋｉｅ：ＪＳＥＳＳＩＯＮＩＤから続く値がセッションＩＤの例を示している。セッションＩＤは、中継サーバ１２０内でユニークな値であり、セッションＩＤを受信したクライアント（ここではＭＦＰ１００）は、中継サーバ１２０に再度アクセスする際、このセッションＩＤを送信する。これにより、中継サーバ１２０は、同一のリクエスタによる通信であることを認識することができる。また、ＸＭＬのデータ内には、ログイン要求に対する結果を示すコードが示される。図１０（ｂ）に示す例において、＜ｒｅｓｕｌｔＣｏｄｅ＞タグの値は“０”であり、これはログイン成功した旨をＭＦＰ１００に返している。失敗した場合には、例えば、この値を“１”とする。

なお、図１０（ａ）では、セッションＩＤの例として、Ｃｏｏｋｉｅオプションを利用しているが、他の方法を用いたセッション制御でもよい。例えば、Ｃｏｏｋｉｅを利用できないブラウザに対しては、ＵＲＬパス情報の中にセッション情報を埋め込むようにするＵＲＬリトライ・オプションを利用してセッションを制御する方法がある。また、認証情報をＨＴＴＰ認証ヘッダ・オプション（Ａｕｔｈｏｒｉｚａｔｉｏｎヘッダ）としてリクエストに挿入する方法などもある。これらの公知技術は、サーバ側が同一利用者であることを認識・制御するために発行する識別子である。サーバがクライアントからのアクセス負荷に耐えられるように負荷分散を行った場合でも、上記の識別情報を利用し、前回アクセスした利用者を判別することで、同一リクエスタは前回アクセスしたサーバと同じサーバに接続することができる。

図１１は、セッションＩＤを受信したＭＦＰ１００が、中継サーバ１２０から支援ＵＲＬを発行してもらうための通信に用いられる通信データの構成例を表している。図１１（ａ）は、図４のＳ４０２にてＭＦＰ１００から送信されるデータに相当し、図１１（ｂ）は、図４のＳ４０４にて中継サーバ１２０から送信されるデータに相当する。図１１（ａ）は、ＨＴＴＰまたはＨＴＴＰＳを利用したデータであり、ヘッダ部とボディ部（ＸＭＬ部）から構成される。図１１（ａ）の例においては、Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈの行までがヘッダ部となり、それよりも下の記述がボディ部となる。ＭＦＰ１００は、図１１（ａ）のヘッダ部に、図１０（ｂ）にて中継サーバ１２０から発行されたセッションＩＤを出力することで、中継サーバ１２０に対してログイン済みの通信であることを表す。

中継サーバ１２０は、このデータを受信するとヘッダ部のセッションＩＤから以前に同じセッションＩＤを発行したリクエスタからの通信であることを認識する。ボディ部には、ＭＦＰ１００からのリクエストが出力されており、ここでは支援ＵＲＬ発行のリクエストが表される。この図１１（ａ）に示すリクエストを受信した中継サーバ１２０は、応答として図１１（ｂ）のデータをＭＦＰ１００へ返す。このデータのボディ部には、支援ＵＲＬ（＜ａｃｃｅｓｓＵｒｌ＞タグ）と通信に関する成功・失敗を表すコード（＜ｒｅｓｕｌｔＣｏｄｅ＞タグ）と発行時刻（＜ｔｉｍｅＳｔａｍｐ＞タグ）を表す。

図１２は、ＰＣ１１０が受信した支援ＵＲＬに接続する際に送信する通信データの構成例を示す。このデータは、図４のＳ４０９にて、ＰＣ１１０が中継サーバ１２０へ送信するデータに相当する。

ＭＦＰ１００は、自身の識別子、図１１（ｂ）に示すデータで受信した支援ＵＲＬ、および図１０（ｂ）に示すデータで受信したセッションＩＤを、管理サーバ１３０へ送信する（図４の４０７）。これらの情報を受信した管理サーバ１３０は、ＭＦＰ情報テーブル１３１を用いて、受信したＭＦＰ１００の識別子に基づき、支援ＵＲＬとセッションＩＤを送信すべきコールセンターを確定する。そして、管理サーバ１３０は、それらの情報を確定したコールセンターへ転送する。データ転送先であるコールセンター内のＰＣ１１０は、受信した支援ＵＲＬとセッションＩＤを用いて、図１２にて表すようなデータを作成し、支援ＵＲＬに対して接続要求を行う。ここでのデータ送信時に、ＭＦＰ１００が通信で利用しているセッションＩＤをＰＣ１１０も利用することで、負荷分散を行っている複数の中継サーバを構成するコンピュータのうちＭＦＰ１００とのセッションが確立されているコンピュータへ接続することができる。

図１２のデータ例では、Ｃｏｏｋｉｅオプションを利用したが、セッションを利用した接続先を制御する仕組みとして、ＵＲＬリトライ・オプションやＨＴＴＰ認証ヘッダー・オプションを利用しても構わない。これらのセッションＩＤを利用することで、負荷分散装置等は、ＭＦＰ１００と同一機器からのリクエストと認識し、中継サーバ１２０を構成する複数のコンピュータの内の、ＭＦＰ１００が接続待ちを行っているコンピュータへ正しく接続が行われる。なお、同じセッションＩＤを利用し続けると中継サーバ１２０は、ＭＦＰ１００の接続かＰＣ１１０の接続かが区別できなくなる場合がある。そのため、図１２のデータを受信したタイミングで新しいセッションＩＤを割り当てる構成としてもよい。

（処理フロー）
図１３は、本実施形態に係る図５のフローチャートにおけるＳ５０４〜Ｓ５１１までの処理の詳細を示し、ＭＦＰ１００がセッションＩＤ情報を取得し、送信する際のフローチャートを示している。ここでの処理について、図５の処理と異なる箇所のみを説明する。

中継サーバ１２０へのログインが成功した場合（Ｓ５０５にてＹＥＳ）、ＣＰＵ２１１は、Ｓ１３０１へ処理を進める。Ｓ１３０１にて、ＣＰＵ２１１は、ログインレスポンス内にセッション情報（図１０（ｂ）にて示したセッションＩＤ）が付加されているか否かを確認する。ログインレスポンス内にセッション情報が付加してある場合（Ｓ１３０１にてＹＥＳ）、Ｓ１３０２にて、ＣＰＵ２１１は、これ以降の中継サーバ１２０へのアクセスには、取得したセッション情報を付加して通信を行うよう設定する。そして、ＣＰＵ２１１は、処理をＳ５０６へ進める。ログインレスポンス内にセッション情報が付加されていない場合は（Ｓ１３０１にてＮＯ）、ＣＰＵ２１１は、処理をＳ５０６へ進める。

Ｓ５０９にて、中継サーバ１２０に対してＧＥＴポーリングを開始すると、ＣＰＵ２１１は、管理サーバ１３０に対して中継サーバ１２０への接続情報を送信する。Ｓ１３０３にて、ＣＰＵ２１１は、ＭＦＰ１００がセッション情報を保持しているか否かを確認する。セッション情報を保持している場合（Ｓ１３０３にてＹＥＳ）、Ｓ１３０４にてＣＰＵ２１１は、自身の識別子と支援ＵＲＬとともに、セッション情報を管理サーバ１３０へ送信する。この処理が完了すると、ＣＰＵ２１１は、処理をＳ５１１へ進める。

一方、ＭＦＰ１００がセッション情報を保持していない場合（Ｓ１３０３にてＮＯ）、ＣＰＵ２１１は、処理をＳ５１０へと進め、管理サーバ１３０へＭＦＰ識別子と支援ＵＲＬを送信する。この処理が完了すると、ＣＰＵ２１１は、処理をＳ５１１へ進める。以降の処理は、図５と同様である。上記のようにして、セッション情報を、管理サーバ１３０経由でＰＣ１１０へ送信し、ＰＣ１１０が中継サーバ１２０に送信する際に、受け取ったセッション情報を利用することで、負荷分散環境においても同じ中継サーバへ接続することができる。

＜その他の実施形態＞
また、Ｇｏｏｇｌｅ社（Ｇｏｏｇｌｅ Ｉｎｃ．）やＡｍａｚｏｎ社（Ａｍａｚｏｎ．ｃｏｍ Ｉｎｔ’ｌ Ｓａｌｅｓ， Ｉｎｃ．）のようなクラウドサービスを行っている会社がある。このようなクラウドサービスでは、クラウド環境にアクセスする際、ＤＮＳ（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｅｒｖｉｃｅ）の名前解決の応答に対し、リクエスタからネットワーク的に近いコンピュータのＩＰアドレスを提供する場合がある。このような場合、ＭＦＰ１００がＤＮＳから受信した中継サーバ１２０のＩＰアドレスと、ＰＣ１１０がＤＮＳから受信した中継サーバ１２０のＩＰアドレスが異なる場合がある。すると、それぞれのＩＰアドレスが示すコンピュータは異なるため、ＭＦＰ１００とＰＣ１１０からのそれぞれのセッションを「待ち合わせ」することができなくなる。

本願発明では、図１３のＳ５１０で、ＭＦＰ１００は、中継サーバ１２０に接続したときに発行される支援ＵＲＬについて、ホスト部分にグローバルＩＰアドレスを利用して送信するようにしてもよい。この構成により上記問題を、回避することができる。この場合の支援ＵＲＬは、ＰＣ１１０が中継サーバ１２０へアクセスする際のＵＲＬ情報であり、そのＵＲＬ情報を構成する文字列のうち、ホスト部には、中継サーバ１２０のアドレスが記される。ここで、ホスト部をホスト名で示さず、グローバルＩＰアドレスで示す。このようにグローバルＩＰアドレスを送信することで、中継サーバ１２０がインターネット上で識別可能となり、セッションを確実に中継できる。

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

１００ ＭＦＰ、１２０ 中継サーバ、１３０ 管理サーバ

Claims (13)

1. 複数の端末、前記複数の端末を管理する管理サーバ、および、端末間の通信の中継を行う中継サーバを含む通信システムであって、
   前記複数の端末のうちの第一の端末は、前記中継サーバに接続した際に取得した接続情報を前記管理サーバに送信する送信手段を有し、
   前記管理サーバは、前記第一の端末から受信した接続情報を、前記第一の端末と通信する際に前記中継サーバに接続するための情報として、前記複数の端末のうちの第二の端末に通知する通知手段を有する
   ことを特徴とする通信システム。
2. 前記接続情報は、前記第一の端末が前記中継サーバに接続した際に発行されたセッション情報を含むことを特徴とする請求項１に記載の通信システム。
3. 前記接続情報は、前記中継サーバを一意に識別するための識別情報としてのグローバルＩＰアドレスを含むことを特徴とする請求項１に記載の通信システム。
4. 前記中継サーバは、複数の装置および負荷分散装置を有し、
   前記中継サーバが前記第一の端末から接続要求を受信した場合、前記負荷分散装置は前記第一の端末に前記複数の装置のいずれかへの接続を割り当て、当該接続に用いる情報を前記接続情報として発行することを特徴とする請求項１乃至３のいずれか一項に記載の通信システム。
5. 前記管理サーバは、
   前記複数の端末のうちの端末それぞれを対応づけた対応情報を保持する保持手段と、
   前記第一の端末が前記中継サーバに接続した際に、前記対応情報に基づいて、当該第一の端末に対応する前記第二の端末を特定する特定手段と、
   を更に有することを特徴とする請求項１乃至４のいずれか一項に記載の通信システム。
6. 前記第二の端末は、前記管理サーバから受信した接続情報を用いて、前記中継サーバへ接続することを特徴とする請求項１乃至５のいずれか一項に記載の通信システム。
7. 前記中継サーバは、前記第二の端末が前記接続情報を用いて前記中継サーバへ接続を行った場合、当該第二の端末に対し、当該中継サーバへ接続するための新たな接続情報を発行する手段を更に有することを特徴とする請求項１乃至６のいずれか一項に記載の通信システム。
8. 前記第一の端末は、前記中継サーバへ接続した際の認証の応答として前記接続情報を取得することを特徴とする請求項１乃至７のいずれか一項に記載の通信システム。
9. 前記第一の端末は、画像形成装置であり、
   前記第二の端末は、前記画像形成装置の遠隔保守サービスを行う際に当該遠隔保守サービスを提供する側にて用いられる情報処理装置であることを特徴とする請求項１乃至８のいずれか一項に記載の通信システム。
10. 複数の端末を管理する管理サーバ、および、端末の間の通信の中継を行う中継サーバにネットワークを介して接続された前記複数の端末のうちの第一の端末であって、
    前記中継サーバに接続した際に接続情報を取得する取得手段と、
    前記管理サーバを介して、前記複数の端末のうちの第二の端末に前記接続情報を送信する送信手段と
    を有し、
    前記第一の端末と前記第二の端末とが、前記接続情報にて特定される前記中継サーバとの接続を介して通信を行うことを特徴とする第一の端末。
11. 複数の端末、前記複数の端末を管理する管理サーバ、および、端末間の中継を行う中継サーバを含む通信システムのおける制御方法であって、
    前記複数の端末のうちの第一の端末において、前記中継サーバに接続した際に取得した接続情報を前記管理サーバに送信する送信工程を有し、
    前記管理サーバは、前記第一の端末から受信した接続情報を、前記第一の端末と通信する際に前記中継サーバに接続するための情報として、前記複数の端末のうちの第二の端末に通知する通知手段を有する
    ことを特徴とする通信システムの制御方法。
12. 複数の端末を管理する管理サーバ、および、端末の間の通信の中継を行う中継サーバにネットワークを介して接続された前記複数の端末のうちの第一の端末の制御方法であって、
    前記中継サーバに接続した際に接続情報を取得する工程と、
    前記管理サーバを介して、前記複数の端末のうちの第二の端末に前記接続情報を送信する工程と
    を有し、
    前記第一の端末と前記第二の端末とが、前記接続情報にて特定される前記中継サーバとの接続を介して通信を行うことを特徴とする制御方法。
13. コンピュータを、
    コンピュータの間の通信の中継を行う中継サーバに接続した際に接続情報を取得する取得手段、
    複数のコンピュータを管理する管理サーバを介して、前記複数のコンピュータのうちの別のコンピュータに前記接続情報を送信する送信手段
    として機能させ、
    前記コンピュータと前記別のコンピュータとが、前記接続情報にて特定される前記中継サーバとの接続を介して通信を行うことを特徴とするプログラム。

Images