JP6313658B2 - 通信システム、および通信システムにおける制御方法 - Google Patents

Description

本発明は、通信システム、情報処理装置およびその制御方法、並びにプログラムに関する。

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

特許第４８５０７６１号公報

上記のような遠隔保守サービスにおいて、顧客からの相談内容によってはコールセンターのオペレータでは原因の特定、解決が出来ない場合がある。その場合、フィールドのサービスマンが直接中継サーバを介して顧客と対応した方が効率良く問題を解決出来ることがある。こうした課題を鑑み、画像形成装置で発生した障害内容によって、通知先を変える仕組みが提案されている（特許文献１参照）。しかしながら、例えば発生した障害がサービスマンへ通知するものであっても、その処置が既に完了している場合は、サービスマンではなくオペレータへ通知すべきである。

本発明では、画像形成装置の状態だけでなく、サービスマンの対応状況も考慮し、通知先を切り替えることで効率的なサービスを提供する。

上記課題を解決するために本願発明は以下の構成を有する。すなわち、第一の端末、前記第一の端末から受信した該第一の端末の状態を管理する管理サーバ、および、前記第一の端末を含む複数の端末間の通信を中継する中継サーバを含む通信システムであって、前記第一の端末は、前記第一の端末の状態を前記管理サーバに送信する第１送信手段と、前記中継サーバに、前記第一の端末に対して前記中継サーバを介して通信するための前記中継サーバへの接続情報の作成要求を送信する要求手段と、前記作成要求に基づき前記中継サーバにより作成された前記接続情報を用いて前記中継サーバに通信してきた参加者の情報を、前記中継サーバに問い合わせる問い合わせ手段と、前記作成要求に基づき前記中継サーバにより作成された前記接続情報を前記管理サーバに送信する第２送信手段と、前記接続情報を用いて前記中継サーバに通信してきた参加者から、前記中継サーバを介してデータを受け付ける受け付け手段とを有し、前記管理サーバは、前記第一の端末にて発生した障害へのサービスマンによる対応履歴を含む履歴情報を管理する管理手段と、前記第一の端末から、前記接続情報を受信する受信手段と、前記接続情報を受信した際に、前記第一の端末の状態および前記管理された履歴情報に含まれる対応履歴に基づき、前記受信した接続情報の通知先を、前記サービスマンと該サービスマン以外のオペレータとのいずれかに決定する決定手段と、前記決定された通知先に対応する宛先情報を用いて、前記受信した接続情報を通知する通知手段とを有する。

本発明によれば、遠隔保守サービスの開始要求を受けると画像形成装置の状態とそれに対するサービスマンの対応状況によって通知先を切り替え、顧客への対応をより効率的に行うことが可能となる。

本発明の一実施形態に係る通信システムの全体構成の例を示す図。 本発明の一実施形態に係るＭＦＰの構成例を示す図。 本発明の一実施形態に係る各装置の構成例を示す図。 本発明の一実施形態に係るシーケンスを示す図。 本発明の一実施形態に係るＭＦＰの動作を示すフローチャート。 本発明の一実施形態に係るＰＣの動作を示すフローチャート。 本発明の一実施形態に係る中継サーバの動作を示すフローチャート。 本発明の一実施形態に係る管理サーバの動作を示すフローチャート。 本発明の一実施形態に係るＭＦＰ情報の一例を示す図。 第一の実施形態に係る各テーブルの構成例を示す図。 第一の実施形態に係る管理サーバの通知先切り替え処理を示すフローチャート。 第一の実施形態に係る各テーブルの構成例を示す図。 第二の実施形態に係る管理サーバの通知先切り替え処理を示すフローチャート。 第二の実施形態に係る通知先履歴テーブルの構成例を示す図。

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

＜第一の実施形態＞
本発明の第一の実施形態について図面を用いて説明する。

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

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

中継サーバ群１２１は、インターネット１４０を介して中継サービスを提供する１または複数のサーバコンピュータ（中継サーバ１２０）からなるサーバ群である。なお、図１においては中継サーバ群１２１内の中継サーバ１２０は１台のみ図示する。中継サービスにより、各イントラネット内の端末間でインターネット１４０を介した通信が可能となる。

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

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

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

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

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

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

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

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

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

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

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

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

一方、中継サーバ１２０は、ＭＦＰ１００やＰＣ１１０から支援ＵＲＬにＧＥＴポーリングされると、ＲＡＭ２１３にバッファリングされた支援データをＭＦＰ１００やＰＣ１１０に返す。中継サーバ１２０は、支援ＵＲＬをＭＦＰ１００に送信する（Ｓ４０４）。ＭＦＰ１００は、支援ＵＲＬへ参加要求を送信する（Ｓ４０５）。ＭＦＰ１００は、支援ＵＲＬへ参加者情報のＧＥＴポーリングを開始する（Ｓ４０６）。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ＣＰＵ３１１は、ＭＦＰ１００からＭＦＰ識別子と支援ＵＲＬを受信するまで待機する（Ｓ８０１）。ＭＦＰ識別子と支援ＵＲＬを受信すると（Ｓ８０１にてＹＥＳ）、ＣＰＵ３１１は、それらの情報をオペレータ、サービスマンのどちらへ通知すべきかを決定するための通知先決定処理を行う（Ｓ８０２）。本処理の詳細については、図１１を用いて後述する。また、ＭＦＰ識別子と支援ＵＲＬを受信するタイミングは、図４のＳ４０７に相当する。ＣＰＵ３１１は、ＭＦＰ識別子と支援ＵＲＬを受信すると、Ｓ８０２で決定した通知先へ支援ＵＲＬおよび管理サーバＵＲＬを送信する（Ｓ８０３）。ＣＰＵ３１１は、ＰＣ１１０から管理サーバＵＲＬへのＭＦＰ情報要求を受信するまで待機する（Ｓ８０４）。ＭＦＰ情報要求を受信すると（Ｓ８０４にてＹＥＳ）、ＣＰＵ３１１は、通知先へＭＦＰ情報を送信する（Ｓ８０５）。そして、本処理フローを終了する。

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

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

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

以上により、ＭＦＰ１００からの支援開始要求に応じて、オペレータもしくはサービスマンは、ＭＦＰ１００の支援を開始することが可能となる。

［通知先決定処理］
次に、図８のＳ８０２において、管理サーバ１３０がＰＣ１１０へ支援ＵＲＬ、管理サーバ１３０のＵＲＬをメール通知する際の宛先を決定する処理について説明する。

図１０（Ａ）は、管理サーバ１３０がＭＦＰ１００で発生した障害とそれに対する対応状況を管理するために保持する対応状況管理テーブル１０１０の構成例である。対応状況管理テーブル１０１０は、管理サーバ１３０内のＨＤＤ３１４で保持される。列１０１１は、障害の発生日時であり、ＭＦＰ１００で障害が発生した際の日時を示す。列１０１２は、顧客名であり、ＭＦＰ１００が設置された顧客の名称を示す。列１０１３は、デバイスＩＤであり、ＭＦＰ１００を一意に識別するためのＩＤを示す。列１０１４は、障害コードであり、ＭＦＰ１００で発生した障害を一意に特定するためのコードである。

列１０１５は、障害内容を示す情報である。列１０１６は障害タイプであり、障害を大きく分類した際の区分（種類）である。「エラー（出動）」は、現場にサービスマンが出動し対応する必要がある障害を意味する。「エラー（電話）」は、コールセンターのオペレータによる電話対応で対応可能な障害を意味する。列１０１７は、発生した各障害に対する販売会社の対応状況を示している。「対応済み（ディスパッチ）」とは、サービスマンを派遣することで障害対応したことを意味する。「対応済み（電話）」とは、コールセンターのオペレータによる電話で障害対応したことを意味する。なお、列１０１４〜１０１７に入力される値は、予め定義され、オペレータやサービスマンが入力画面（不図示）により適宜選択して入力されるようにしてよい。

また、図１０（Ａ）に示す対応状況管理テーブル１０１０は、オペレータやサービスマンの対応状況やその対応結果に応じて適宜更新されるものとする。したがって、履歴情報としての役割も有する。例えば、オペレータはＰＣ１１０を介して対応結果を入力してもよい。また、サービスマンは、保持している端末の入力画面（不図示）を介して対応結果および対応状況を入力できるようにしても構わない。

図１０（Ｂ）は、管理サーバ１３０がＭＦＰ１００で障害が発生した際に通知する、販売会社のサービスマン、オペレータの宛先を管理する通知先テーブル１０２０の構成例である。通知先テーブル１０２０は、管理サーバ１３０内のＨＤＤ３１４で保持される。列１０２１は、列１０１３と同様にデバイスＩＤであり、ＭＦＰ１００を識別するためのＩＤを示す。列１０２２は、各ＭＦＰを担当するサービスマンの宛先を意味する。列１０２３は、各ＭＦＰを担当するオペレータの宛先を意味する。なお、１のＭＦＰに対して担当するサービスマンおよびオペレータは、１または複数定義してよい。図１０（Ｂ）に示す通知先テーブル１０２０は、必要に応じて適宜更新されるものとする。

図１１は、図８のＳ８０２の管理サーバ１３０がＭＦＰ１００より支援ＵＲＬを受信した際に、ＭＦＰ１００の状態と対応状況から通知先を決定する処理を説明したフローチャートである。図１１のフローチャートに示す各動作（ステップ）は、管理サーバ１３０のＣＰＵ３１１がＨＤＤ３１４に記憶された制御プログラムを実行することによって実現される。

Ｓ１１０１にて、管理サーバ１３０は、ＭＦＰ１００からＭＦＰ１００の識別ＩＤと支援ＵＲＬを受信する。Ｓ１１０２にて、管理サーバ１３０は、対応状況管理テーブル１０１０を参照し、対象ＭＦＰの状態を確認する。Ｓ１１０３にて、管理サーバ１３０は、対象ＭＦＰの状態が「エラー（出動）」状態か否かを判定する。対象ＭＦＰの状態がエラー（出動）状態であった場合（Ｓ１１０３にてＹＥＳ）、Ｓ１１０４にて管理サーバ１３０は、サービスマンの対応状況（出動状況）を確認する。サービスマンの対応状況とは、図１０（Ａ）で説明した列１０１７に示す情報を意味する。

Ｓ１１０５にて、管理サーバ１３０は、サービスマンの対応状況が未対応もしくは対応中であるか否かを判定する。すなわち、出動可能なサービスマンがいるか否かを判定する。対応状況が未対応もしくは対応中である場合（Ｓ１１０５にてＹＥＳ）、管理サーバ１３０は、Ｓ１１０６でサービスマンへ支援ＵＲＬと管理サーバ１３０のＵＲＬを通知する。通知先は、通知先テーブル１０２０を参照し、対象のデバイスＩＤ（列１０２１）から取得される。そして、本処理フローを終了する。

一方、サービスマンの対応状況が未対応もしくは対応中でない場合（Ｓ１１０５にてＮＯ）、Ｓ１１０９にて管理サーバ１３０は、オペレータへ支援ＵＲＬと管理サーバ１３０ＵＲＬを通知する。オペレータへ通知することで、顧客に対してサービスマンを派遣した旨を伝えることが出来る。そして、本処理フローを終了する。

一方、対象ＭＦＰの状態がエラー（出動）状態でない場合（Ｓ１１０３にてＮＯ）、Ｓ１１０７にて管理サーバ１３０は、サービスマンの対応履歴を確認する。サービスマンの対応履歴とは、対象ＭＦＰへの対応状況が「対応済み（ディスパッチ）」となった履歴を意味し、サービスマンが訪問することで障害対応を行った履歴のことである。この履歴は対応状況管理テーブル１０１０内の対応状況（列１０１７）を参照することで取得できる。Ｓ１１０８にて、管理サーバ１３０は、直近でサービスマンが対象ＭＦＰに対して訪問対応を行った日時が規定日以内であるか否かを確認する。ここでの規定日にて示す期間の情報は予め定義され、管理サーバ１３０のＨＤＤ３１４等にて管理されているものとする。確認の結果、対応日が所定の期間内である場合（Ｓ１１０８にてＹＥＳ）、Ｓ１１０６にて管理サーバ１３０は、サービスマンへ支援ＵＲＬと管理サーバ１３０のＵＲＬを通知する。そして、本処理フローを終了する。これにより、本来であればＭＦＰ１００の状態がエラー（電話）などのオペレータが対応可能なものであっても、直近に訪問したサービスマンへ通知することにより効率の良い対応をすることが可能となる。

Ｓ１１０８での確認の結果、対応日が規定日以内でない場合（Ｓ１１０８にてＮＯ）、Ｓ１１０９にて管理サーバ１３０は、オペレータへ支援ＵＲＬと管理サーバ１３０のＵＲＬを通知する。そして、本処理フローを終了する。

本実施形態では、ＭＦＰ１００から識別子と中継サーバ１２０へ接続するための支援ＵＲＬを受信することに起因して、管理サーバ１３０が一定の条件に基づいて通知先を切り替える処理について説明した。この場合、一人のサービスマンが担当するＭＦＰが複数台ある場合において、あるＭＦＰを対応していると、別のＭＦＰから支援要求があっても対応することが出来ないという課題がある。その他にも、サービスマンが運転中、もしくは休暇などで支援要求の通知を受け取れないことも想定される。

この課題に対応するため、管理サーバ１３０は更に、図１２に示す、サービスマンの状況を管理するサービスマン作業ステータステーブル１２００とサービスマンが作業した履歴を管理する作業履歴テーブル１２１０を保持する。図１２（Ａ）に示すサービスマン作業ステータステーブル１２００において、列１２０１は、担当のサービスマンを意味する。列１２０２は、対象ＭＦＰに対する作業ステータスを意味する。列１２０３は、対象ＭＦＰのシリアル番号を意味する。図１２（Ｂ）に示す作業履歴テーブル１２１０において、列１２１１は、サービスマンが作業を開始、終了した際の日時を意味する。列１２１２は、作業開始か終了を意味する。

これらの情報を適宜管理するために、例えば、サービスマンがＭＦＰ１００のパネルにて、作業開始／終了時のボタン押下、サービスマン向け画面への入出により管理サーバ１３０へ通知がされる仕組みなどで実現することが出来る。また、ユーザが保持する端末から進捗状況や対応結果、出動履歴を入力できるようにしてもよい。

上記２つのテーブルから、本実施形態ではデバイスＩＤ「ＤＥＶ００００１」に対して、サービスマンＡが現在対応している状態（「対応中」）がわかる。更に、「２０１４／０２／１２ １１：０２」に作業を開始、その後作業が現時点で終了していないことを知ることができる。したがって、この状態でＤＥＶ００００１から支援要求を受信した場合、管理サーバ１３０はサービスマンＡへは通知せず、オペレータ、もしくは他のサービスマン（例えば、現在対応を行っていないサービスマンＫ）などへ通知することが可能となる。

また、販売会社の方針によっては、顧客からの問い合わせは一旦全てコールセンターのオペレータで受けることも想定される。この構成に対応するために、管理サーバ１３０は自動的に通知先を切り替えるか否かを意味するフラグを販売会社ごとに持たせる通知先自動設定テーブル１２２０を保持するようにしてもよい。図１２（Ｃ）に示す通知先自動設定テーブル１２２０において、列１２２１は、販売会社名を意味する。列１２２２は、自動的に通知先を切り替えるか否かを意味する。つまり、通知先の決定処理の有効化／無効化を設定することができる。この設定変更は、例えば、ＵＩ画面もしくは申請により可能である。

本実施形態において、各サーバや装置の構成、また、支援要求を受信した際の管理サーバ１３０の処理フローを示したが、これらは一例であり、これに限るものではない。

以上により、遠隔保守サービスの開始要求を受けると画像形成装置の状態とそれに対するサービスマンの対応状況によって通知先を切り替え、顧客への対応をより効率的に行うことが可能となる。

＜第二の実施形態＞
顧客からの支援要求に対して、オペレータもしくはサービスマンが対応後、問題が再発したなどの理由から再度支援要求される場合がある。その際、直前の支援要求に対応したオペレータやサービスマンが問題把握や、対応をし易いことから、一定時間内の再支援要求に対しては前回対応者へ通知することで対応効率を上げることが出来る。第二の実施形態では、前回の支援対応から一定時間内の再支援要求があった際の処理について説明する。

［処理フロー］
図１３は、管理サーバ１３０がＭＦＰ１００より支援ＵＲＬを受信した際に、前回の支援要求を受信した日時が一定時間内か否かで通知先を決定する処理を説明したフローチャートである。本処理フローは、管理サーバ１３０のＣＰＵがＨＤＤ等の記憶部に格納されたプログラムを読み出して実行することにより実現される。なお、本処理フローは、第一の実施形態における図１１の処理に対応し、重複する処理の詳細な説明は省略する。

Ｓ１３０１にて、管理サーバ１３０は、ＭＦＰ１００から支援要求（支援ＵＲＬ、識別ＩＤ）を受信する。Ｓ１３０２にて、管理サーバ１３０は、支援要求の通知先履歴を確認する。図１４は、ＭＦＰ１００で障害が発生し、対象のサービスマンへ通知がされた通知先履歴を管理するための通知先履歴テーブル１４００の構成例である。通知先履歴テーブル１４００は、ＭＦＰ１００ごとに管理され、管理サーバ１３０内のＨＤＤ３１４で保持される。通知先履歴テーブル１４００において、列１４０１は、管理サーバ１３０が支援要求を通知した日時を示す。列１４０２は、通知先がサービスマンかオペレータかを示す情報である。Ｓ１３０２にて確認する通知先の履歴は、通知先履歴テーブル１４００を参照する。

Ｓ１３０３にて、管理サーバ１３０は、最後に通知した際の日時が規定時間内であるか否かを判定する。規定時間内である場合（Ｓ１３０３にてＹＥＳ）、Ｓ１３１２にて管理サーバ１３０は、通知先履歴テーブル１４００を参照し、前回の通知先へ通知する。そして、本処理フローを終了する。

一方、直近の通知した際の日時が規定時間内でなかった場合（Ｓ１３０３にてＮＯ）、Ｓ１３０４にて管理サーバ１３０は、対象ＭＦＰの状態を確認する。ここで用いられる規定時間（所定の期間）の情報は予め定義され、管理サーバ１３０内に保持されているものとする。Ｓ１３０５以降の処理は、第一の実施形態にて説明した図１１のＳ１１０３〜Ｓ１１０９の処理と同等であるため、ここでの説明は省略する。

以上、本実施形態により、第一の実施形態よりも更に効率化した顧客への対応を可能とする。

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

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

Claims (5)

1. 第一の端末、前記第一の端末から受信した該第一の端末の状態を管理する管理サーバ、および、前記第一の端末を含む複数の端末間の通信を中継する中継サーバを含む通信システムであって、
   前記第一の端末は、
   前記第一の端末の状態を前記管理サーバに送信する第１送信手段と、
   前記中継サーバに、前記第一の端末に対して前記中継サーバを介して通信するための前記中継サーバへの接続情報の作成要求を送信する要求手段と、
   前記作成要求に基づき前記中継サーバにより作成された前記接続情報を用いて前記中継サーバに通信してきた参加者の情報を、前記中継サーバに問い合わせる問い合わせ手段と、
   前記作成要求に基づき前記中継サーバにより作成された前記接続情報を前記管理サーバに送信する第２送信手段と、
   前記接続情報を用いて前記中継サーバに通信してきた参加者から、前記中継サーバを介してデータを受け付ける受け付け手段と
   を有し、
   前記管理サーバは、
   前記第一の端末にて発生した障害へのサービスマンによる対応履歴を含む履歴情報を管理する管理手段と、
   前記第一の端末から、前記接続情報を受信する受信手段と、
   前記接続情報を受信した際に、前記第一の端末の状態および前記管理された履歴情報に含まれる対応履歴に基づき、前記受信した接続情報の通知先を、前記サービスマンと該サービスマン以外のオペレータとのいずれかに決定する決定手段と、
   前記決定された通知先に対応する宛先情報を用いて、前記受信した接続情報を通知する通知手段と
   を有することを特徴とする通信システム。
2. 前記決定手段は、前記第一の端末の状態がサービスマンの出動が必要な障害を示す場合、前記受信した接続情報の通知先を前記サービスマンに決定することを特徴とする請求項１に記載の通信システム。
3. 前記決定手段は、前記第一の端末の状態がサービスマンの出動が必要ない状態を示す場合、前記受信した接続情報の通知先を該サービスマン以外のオペレータに決定することを特徴とする請求項１または２に記載の通信システム。
4. 前記決定手段は、
   前記第一の端末の状態がサービスマンの出動が必要ない状態を示し、かつ、前記対応履歴に基づき所定の期間内に前記サービスマンの出動が行われていた場合、前記受信した接続情報の通知先を前記サービスマンに決定し、
   前記第一の端末の状態がサービスマンの出動が必要ない状態を示し、かつ、前記対応履歴に基づき所定の期間内に前記サービスマンの出動が行われていなかった場合、前記受信した接続情報の通知先を該サービスマン以外のオペレータに決定することを特徴とする請求項３に記載の通信システム。
5. 第一の端末、前記第一の端末から受信した該第一の端末の状態を管理する管理サーバ、および、前記第一の端末を含む複数の端末間の通信を中継する中継サーバを含む通信システムにおける制御方法であって、
   前記管理サーバは、前記第一の端末にて発生した障害へのサービスマンによる対応履歴を含む履歴情報を管理する管理手段を有し、
   前記第一の端末において、前記第一の端末の状態を前記管理サーバに送信する第１送信工程と、
   前記第一の端末において、前記中継サーバに、前記第一の端末に対して前記中継サーバを介して通信するための前記中継サーバへの接続情報の作成要求を送信する要求工程と、
   前記第一の端末において、前記作成要求に基づき前記中継サーバにより作成された前記接続情報を用いて前記中継サーバに通信してきた参加者の情報を、前記中継サーバに問い合わせる問い合わせ工程と、
   前記第一の端末において、前記作成要求に基づき前記中継サーバにより作成された前記接続情報を前記管理サーバに送信する第２送信工程と、
   前記第一の端末において、前記接続情報を用いて前記中継サーバに通信してきた参加者から、前記中継サーバを介してデータを受け付ける受け付け工程と、
   前記第一の端末において、前記管理サーバに対して、前記接続情報を送信する第３送信工程と、
   前記管理サーバにおいて、前記接続情報を受信する受信工程と、
   前記管理サーバにおいて、前記接続情報を受信した際に、前記第一の端末の状態および前記管理された履歴情報に含まれる対応履歴に基づき、前記受信した接続情報の通知先を、前記サービスマンと該サービスマン以外のオペレータとのいずれかに決定する決定工程と、
   前記決定された通知先に対応する宛先情報を用いて、前記受信した接続情報を通知する通知工程と、
   を有することを特徴とする制御方法。

Images