JP4586528B2 - ユーザサポート - Google Patents

Description

本発明は、デバイスの使用をオンラインでサポートする技術に関する。

プリンタ、スキャナなど種々のデバイスについて、ユーザに対するサポートを、インターネットを介してオンラインで行う方法が普及しつつある。このようなサポートの一例として電子メールを利用したサポート方法が挙げられる。この支援方法では、デバイスに異常が生じた場合に、デバイスのメーカが提供するサポート部門に、ユーザが電子メールで異常の内容を送信する。サポート部門では、電子メールの情報から異常の原因を解析し、ユーザに解決策を提示する。

また、オンラインでのサポートには、デバイスの使用に関する問題やデバイスの異常を解決するためのサポート情報、いわゆるオンラインヘルプをインターネットのＷｅｂページで提供するサポート方法も存在する。一般には、デバイスのメーカが提供するＷｅｂページにおいて、典型的な問題や異常、および、ユーザ側で解決できる異常などについて、解決方法が提供される。

しかし、一般のユーザにとっては、デバイスの運用状況やその異常について十分に説明することも困難であるため、電子メールや電話によっては、円滑なサポートを行うことが困難であった。また、一般のユーザとっては、デバイスの運用状況やその異常についての理解が困難であるため、いわゆるオンラインヘルプの活用による問題の解決も依然として困難であった。

また、従来の電子メールや電話によるサポート方法では、問題の原因について個別に対応する必要があり、サポートについての重複した負担が発生していた。この結果、解決が困難な深刻な異常に対するサポートが阻害されていた。

本発明は、従来技術における上述の課題を解決するためになされたものであり、オンラインでデバイスの運用をサポートする際における、ユーザ側とサポート側の双方の負担の軽減を図る技術を提供することを目的とする。

上述の課題の少なくとも一部を解決するため、本発明では、デバイスの使用をオンラインでサポートする。この際、まず、前記デバイスを備えたクライアントが、オンラインで前記デバイスの使用をサポートするユーザサポート用サーバに接続し、次に、前記クライアントが、前記デバイスの型式を特定可能なデバイス情報と、前記デバイスの使用環境を表す使用環境情報と、を前記ユーザサポート用サーバに送信する。最後に、前記ユーザサポート用サーバに送信された情報を使用して、前記デバイスの使用をサポートするためのデバイスサポート情報が生成され、前記デバイスサポート情報を前記クライアントに送信する。

本発明では、前記デバイスの型式を特定可能なデバイス情報と、前記デバイスの使用環境を表す使用環境情報とが前記ユーザサポート用サーバに送信されるので、そのデバイスのユーザは、これらの情報をユーザサポート側に説明する負担から解放される。一方、ユーザサポート側は、ユーザサポートに必要な情報を容易に取得することができ、円滑なユーザサポートが可能となる。

このようなサポートは、前記クライアントの前記ユーザサポート用サーバへのアクセスの許可を受けるためのユーザＩＤとパスワードとをあらかじめ取得しているユーザに限定することもできる。

こうすれば、サポートの対象となるユーザとデバイスを一致させることができ、ユーザに関する情報も蓄積でき、さらに、円滑なユーザサポートが可能となる。また、サポートを特定のユーザに限定することも可能となる。

上記方法において、
前記クライアントが、前記デバイスの型式を特定可能なデバイス情報と、前記デバイスの使用環境を表す使用環境情報とを前記ユーザサポート用サーバに送信する際には、前記クライアントが有するクライアント側エージェントが、前記デバイスに生じた異常の診断に使用するデバイス異常診断用情報を生成し、前記ユーザサポート用サーバに送信するようにしても良い。

こうすれば、さらに、精度の高い異常の診断が可能となり、ユーザサポートのさらなる円滑化が図られる。

また、前記クライアントがユーザサポート用サーバに接続するのに先だって、前記クライアント側エージェントが、前記デバイスの使用環境を表す使用環境情報を使用して、前記デバイスの使用をサポートするためのデバイスサポート情報を生成するようにしても良い。

こうすれば、ユーザサポート側の負担が軽減され、また、ユーザも通信回線に接続することなしに、ユーザサポート情報が得られる場合があり、デバイスの異常をさらに容易に解決することができる。

上記方法において、
前記ユーザサポート用サーバが有するユーザサポート側エージェントが、前記ユーザサポート用サーバに送信された情報を使用して、前記クライアントが有するデバイスに生じた異常の解決に使用するデバイス異常解決情報を生成するようにしても良い。

これにより、ユーザサポート用サーバに蓄積された情報により、クライアント側で解決できない異常の解決を図ることができる。

さらに、前記ユーザサポート用サーバ側エージェントが、前記デバイス異常解決情報を使用して、前記クライアントが有するデバイスに生じた異常を解決するのが好ましい。

こうすれば、デバイスに生じた異常が自動的に解決されるので、ユーザの負担は、さらに、軽減される。

なお、ユーザサポートは、オフラインでも行うことができる。こうすれば、インターネットに接続することなしに、問題の解決を図ることができる。

本発明の他の態様では、デバイスを備えたクライアントにからの要求に応じて、オンラインで前記デバイスの使用をサポートするユーザサポート用サーバからオンラインで情報を提供する。この際、まず、前記クライアントが、前記ユーザサポート用サーバに接続し、次に、前記クライアントが、前記デバイスの型式を特定可能なデバイス情報を前記ユーザサポート用サーバに送信する、最後に、前記ユーザサポート用サーバが、前記ユーザサポート用サーバに送信された情報に応じて、前記クライアントが有するデバイスの使用に利用する情報を前記クライアントに送信する。

この態様では、前記デバイスの型式を特定可能なデバイス情報が前記ユーザサポート用サーバに送信されるので、そのデバイスでしか利用できない情報として情報提供を行うことができる。この結果、たとえば、品質の保証がなされていない開発中のソフトウェアを特定の者に限定して配布することができる。

なお、本発明は、種々の態様で実現することが可能であり、たとえば、情報提供制御方法および情報提供制御装置、それらの方法または装置の機能を実現するためのコンピュータプログラム、そのコンピュータプログラムを記録した記録媒体、そのコンピュータプログラムを含み搬送波内に具現化されたデータ信号、等の態様で実現することができる。

次に、本発明の実施の形態を実施例に基づいて以下の順序で説明する。
Ａ．システムの構成とユーザ登録処理：
Ｂ．サポート要員を中心としたユーザサポート：
Ｃ．人工知能を中心としたユーザサポート：
Ｄ．サポート例：
Ｅ．新技術の先行提供：
Ｆ．変形例：

Ａ．システムの構成：
図１は、ユーザサポートをオンラインで行う場合のシステム構成例を示す説明図である。図の上半分にはユーザサポートを行うサポートセンタの構成を示し、下半分にはユーザが使用するクライアントシステムの構成を示した。サポートセンタは、ユーザサポート用サーバＳＶと、サポート要員とから構成される。デバイスのユーザへのユーザサポートは、いかなる者が提供しても構わないが、本実施例では、説明の便宜上、プリンタのメーカがサポートを提供するものとする。以下、デバイスの例としてプリンタ２０を使用して説明する。

クライアントシステムは、コンピュータ９０にプリンタ２０がパラレルケーブルにより接続された構成をなしている。本実施例では、パラレルケーブルを用いてプリンタ２０がコンピュータ９０にローカルに接続されている場合を例示したが、ＬＡＮ（Local Area Network）を介して接続される構成であってもよい。ただし、いずれの場合でも、コンピュータ９０とプリンタ２０との間で双方向通信が可能であることが望ましい。

コンピュータ９０には、所定のオペレーティングシステム１１上で起動するいくつかのプログラムがインストールされている。ここでは、代表的なプログラムとして、Ｗｅｂページの閲覧に供されるブラウザ１０と、プリンタ２０を駆動する機能を奏するプリンタドライバ１２と、プリンタ２０で印刷する文書および画像データを生成するアプリケーションプログラム１４とを示した。印刷を行う時には、アプリケーションプログラム１４から、印刷コマンドとともに印刷すべきファイルがプリンタドライバ１２に受け渡される。プリンタドライバ１２は、このファイルに対し、レンダリングその他の処理を行って、プリンタ２０に供給する印刷データを生成する。プリンタ２０は、パラレルケーブルを介してこの印刷データを受け取り、印刷を実行する。なお、プリンタ２０には、その動作を制御するファームウェア２２と、少なくともプリンタの動作状態を保持するデータベースであるＭＩＢ（Management Information Base）４６とを備えている。コンピュータ９０は、このＭＩＢ４６にアクセスすることにより、プリンタ２０の動作環境などに関する情報を得ることができる。

図２は、オンラインサポート用ユーザ登録処理の手順を示すフローチャートである。ステップＳ１０１では、コンピュータ９０とプリンタ２０が接続される。この接続が、オンラインサポート用ユーザ登録処理開始のトリガーとなる。ただし、この接続の時に、プリンタドライバ１２がコンピュータ９０にインストールされていない場合も想定される。このときは、プリンタドライバ１２のインストールがオンラインサポート用ユーザ登録処理開始のトリガーとなる。ステップＳ１０２では、プリンタＩＤがコンピュータ９０に登録される。この登録が完了すると、ステップＳ１０３に進み、ユーザに対して登録の希望の有無を問い合わせるダイアログボックス（図示せず）が表示される。

ユーザが登録を希望しない旨の応答をした場合はステップＳ１０４に進み、ユーザ登録用アイコンを、たとえば、デスクトップ上に生成した上で、ユーザ登録処理を終了する。ユーザ登録用アイコンを作るのは、ユーザがいつでもユーザ登録できるようにするためである。一方、ユーザが、登録を希望する旨の応答をした場合は、図３に示すダイアログボックスが表示される。

図３は、ユーザに対して情報提供の可否の問い合わせを行うダイアログボックスを例示する説明図である。このダイアログボックスは、ユーザに対して、ユーザサポートのための情報提供を許可する否かを確認するものである。情報提供の可否の確認をするのは、本実施例におけるユーザサポートでは、クライアントシステム内部の情報の提供が必要であり、この情報は個人情報に属する可能性があるからである。ユーザが情報提供を拒否した場合は、その旨がユーザ登録情報として記録され、従来のサポート方法により対応することになる。

ステップＳ１０５では、ユーザサポート用アイコンが生成される。このユーザサポート用アイコンをクリックすることにより、登録ユーザは、本発明の１実施例であるオンラインによるユーザサポートを受けることができる。また、ユーザ登録処理が通信エラーその他の事情により中断したときには、このユーザサポート用アイコンをクリックすることにより、ユーザ登録処理を再開できる。

ステップＳ１０６では、コンピュータ９０がユーザサポート用サーバＳＶに接続される。この接続は、プリンタドライバ１２が、コンピュータ９０に登録されたプリンタＩＤを使用して自動的に行うものである。接続が完了すると、ステップＳ１０７に進みユーザサポート用サーバＳＶへのユーザ登録処理が開始される。

図４は、ユーザサポート用サーバＳＶへの登録処理の手順を示すフローチャートである。ステップＳ２０１では、ユーザサポート用サーバＳＶにユーザのプリンタＩＤを登録する。プリンタＩＤを登録することにより、これを基準として顧客データベースを生成することができ、顧客管理が容易となる。ステップＳ２０２では、コンピュータ９０がユーザサポート用サーバＳＶにクライアント側の印刷環境情報を送信する。この印刷環境情報は、クライアントシステムの形態情報のうち、印刷作業の実行に関係する可能性のある情報である。この情報をユーザサポート側が把握することにより、ユーザサポートが容易になる。

図５は、ユーザサポートのためにクライアント側からユーザサポート用サーバＳＶに送信する情報を例示する表である。図示するように、このサーバに送信する情報には、印刷環境情報の他、デバイス異常診断用情報として使用できる印刷ログ情報、操作ログ情報、そして処理データを含めることもできる。これらのデータの詳細については後述する。また、印刷環境情報は、印刷環境に変化がある度に、その変化を記録しておくのが好ましい。印刷環境の変化が原因となってサポートが必要となる場合も多いため、印刷環境の変化もサポートの実施に有益な情報となるからである。印刷環境情報の取得は、たとえば、コンピュータ９０のオペレーティングシステム１１がＷｉｎｄｏｗｓ（登録商標）の場合、レジストリデータの一部又は全部を読み込むことにより、可能である。また、プリンタ２０に備えられたＭＩＢ４６に印刷環境情報を記録するようにし、ユーザサポート用サーバＳＶにアップロードするようにしても良い。ユーザサポート用サーバＳＶが印刷環境情報の受信を完了すると、ステップＳ２０３に進む。

ステップＳ２０３では、ユーザサポート用サーバＳＶは、コンピュータ９０に、ユーザ登録用の送信フォーム１２０（図１）を送信する。このフォームは、先に受信した情報に応じてカスタマイズしても良い。たとえば、デバイス毎に送信フォーム１２０を変えても良い。ステップＳ２０４では、ユーザは、ユーザ登録用の送信フォーム１２０に所定の事項を入力し、ユーザサポート用サーバＳＶに送信する。これにより、プリンタＩＤとユーザを一致させることができる。すなわち、プリンタＩＤからユーザを特定することができるので、ユーザサポートがさらに容易になる。

ステップＳ２０５では、ユーザサポート用サーバＳＶで、そのユーザのサポートに関するログの記録が開始される。このログを参照することにより、サポートを求めているユーザが過去にどのようなサポートを受けているかを知ることができる。これにより、ユーザサポート要員は、ユーザサポートをより円滑に進めることができる。

ステップＳ２０６では、クライアントシステムのログの記録が開始される。このログには、図５に示すように、印刷ログ情報と操作ログ情報がある。印刷ログ情報は、サポートの対象となるプリンタ２０の過去における印刷に関する情報、たとえば、どのような印刷環境で、いつ、どれだけの量の印刷が行われたかを表す情報である。操作ログ情報は、たとえば、エラー発生時またはサポート用アイコンのクリック前の、一定期間の操作内容の記録である。これらの情報は、ユーザサポート側で、ユーザがサポートを求める状況を再現するために使用する情報である。サポートの対象となる状況をサポート側で再現できれば、適切なユーザサポートを確実に行うことができるからである。

これらの情報の記録は、コンピュータ９０の記憶装置、プリンタ２０のＭＩＢ４６、またはその双方に行うことができる。しかし、これらの機器に故障が発生し得ることを考慮すると、双方に記録するのが好ましい。

Ｂ．サポート要員を中心としたユーザサポート：
図６は、サポート要員によるユーザサポート処理の手順を示すフローチャートであり、図７は、希望するサポートの内容をユーザに問い合わせるダイアログボックスを例示する説明図である。ステップＳ３０１では、ユーザがユーザサポート用アイコンをクリックする。これにより、ユーザサポート処理が開始され、ステップＳ３０２に進む。ステップＳ３０２では、コンピュータ９０が、インターネットを経由して、ユーザサポート用サーバＳＶに接続される。この接続が完了すると、ステップＳ３０３に進み、図７に示すダイアログボックスが表示される。このダイアログボックスでは、ユーザは、サポートの内容を、たとえば、「操作内容の問い合わせ」と「故障」とから選択することができる。この選択がなされると、ステップＳ３０４に進み、コンピュータ９０は、その選択結果とともに、プリンタＩＤをユーザサポート用サーバＳＶに送信する。

プリンタＩＤを取得したサポートセンタは、プリンタＩＤを使用してサポート対象のプリンタ２０を特定する。さらに、サポートセンタ内のデータベースに照会して、ユーザサポート登録ユーザを特定することもできる。さらに、同時に受信した印刷環境情報を調査することにより、ユーザサポート要員は、サポートが求められているクライアントシステムのその時点での印刷環境を知ることができる。また、プリンタＩＤとユーザが特定されているので、サーバ側ログ情報を参照することにより、さらに、過去の印刷環境と比較することもできる。これにより、サポートを円滑に進めることができる。ユーザの特定が完了すると、後述するダイアログボックスが表示される。

図８は、ユーザの連絡先を確認するダイアログボックスを例示する説明図である。このダイアログボックスは、サポートセンタ内のデータベースに登録されたユーザと一致するかどうかを確認するとともに、サポートの対象となるユーザの連絡先を確認するために表示するものである。この確認が終了すると、ステップＳ３０５に進み、ユーザサポート用サーバＳＶが、コンピュータ９０にユーザサポート用の送信フォーム１２０を送信する。なお、ユーザに変更がある場合、図８のダイアログボックスで、「いいえ」を選択することにより、再度ユーザ登録をすることができる。

図９は、ユーザの置かれている状況の説明を入力する送信フォームを例示する説明図である。ステップＳ３０６では、クライアントシステムが受信したユーザサポート用の送信フォーム１２０（図１、図９）に、ユーザが、所定の事項を入力し、ユーザサポート用サーバＳＶに返信する。このユーザサポート用の送信フォーム１２０には、ユーザの入力を容易にするように、入力サンプルを添付したり、選択式の表示により記載内容を絞り込むようにするのが好ましい。この返信の際には、印刷環境情報、印刷ログ情報、操作ログ情報も同時送信される。サポートセンタの受信の完了をクライアントシステムが確認すると、情報の取得が完了し、クライアントシステムとユーザサポート用サーバＳＶの接続が解除される。なお、この接続の解除の時に、サポートセンタから、追って連絡があることを示す表示（図示せず）を行うのが好ましい。

ステップＳ３０７では、サポート要員によるクライアントシステムの状況分析が開始される。この状況の分析は、たとえば、異常に対するサポートの場合は、以下の手順で行うことができる。
（１）ユーザの技量の推定を行う。これは、サーバ側に記録された過去のサポートのログ情報から推定することができる。この技量を知ることで、簡単な異常か深刻な異常かをある程度推定することができる。
（２）印刷環境を特定する。ソフトウェアの干渉その他の印刷環境に基づく異常でないかどうかを、まず、チェックする。このチェックは、サポートセンタ内にデータベース化されたサポート情報を照会することにより行う。また、過去の印刷環境と比較することにより、現在の印刷環境との相違を特定し、異常診断の参考資料とすることもできる。さらに、印刷ログ情報を取得できれば、正常に行われた過去の印刷状況やプリンタ２０の負荷を知ることができ、異常の原因の特定が容易になる。
（３）操作内容を特定する。操作ログ情報を取得できれば、エラーその他のサポートを求める状況が発生するまでの操作内容を特定することができる。操作内容まで特定できれば、クライアントシステムの環境をサポートセンタ側で再現することもでき、サポートがさらに容易になる。

サポート要員による分析が終了すると、ステップＳ３０８に進み、ステップＳ３０４で確認された連絡先に、分析結果が電子メールとして送信される。なお、電子メールだけでなく、ファックスや電話で連絡するようにしても良い。電子メール等の内容は、定型化してデータベース化しておくのが好ましい。こうすれば、重複労力を軽減することができ、サポートの効率が向上する。

以上のように、印刷環境情報その他のユーザサポートに必要な情報が、オンラインで客観的にユーザサポート要員に提供されるので、ユーザサポートが容易となる。また、ユーザにとってもクライアントシステムの状況を説明する負担が大きく軽減され、ユーザサポートの円滑な運用が可能となる。

Ｃ．人工知能を中心としたユーザサポート：
図１０は、分散型人工知能によるユーザサポートシステムの構成を示すブロック図である。これは、複数の人工知能（エキスパート）からなるエキスパートシステムである。このエキスパートシステムは、各エキスパートをエージェントとして定義し、各エージェントが単独で、または必要に応じて相談しながら、サポートを行うシステムである。このシステムを異常診断を例にとって、以下に説明する。

この異常診断のためのエキスパートシステムは、クライアント側のエキスパートとして定義されるクライアント側エージェント２００と、サーバ側のエキスパートとして定義されるサーバ側エージェント２２０とから構成される。クライアント側エージェント２００は、ユーザ側の異常診断機能を有するエージェント（代理人）として機能し、サーバ側エージェント２２０は、サーバ側の異常診断機能を有するエージェント（代理人）として機能する。

図１１は、クライアント側エージェント２００を中心とした印刷部１００の構成を示すブロック図である。この印刷部１００は、クライアント側エージェント２００と、インタフェース専用回路５０と、オペレーティングシステム１１と、プリンタドライバ１２と、アプリケーションプログラム１４と、ファームウェア２２と、機構部３０とから構成される。このクライアント側エージェント２００は、クライアント側監視・制御部２０１とクライアント側異常診断エキスパートシステム２１０とから構成される。

クライアント側異常診断エキスパートシステム２１０は、異常診断のための推論を行うクライアント側推論エンジン２１１と、この推論の根拠となる知識から構成されるクライアント側知識ベース２１２と、推論過程をユーザに対して説明するための情報を生成するクライアント側推論過程説明部２１３とから構成される。クライアント側異常診断エキスパートシステム２１０の開発は、空の知識ベースと推論エンジンとからなる汎用のエキスパートシステム構築ツールを利用して、容易に行うことができる。すなわち、印刷部１００の異常診断用の知識を知識ベースに蓄積することにより、印刷部１００用の異常診断エキスパートシステムを構築することができる。汎用のエキスパートシステム構築ツールには、ＥＭＹＣＩＮ（商標）やＥＳＨＥＬＬ（商標）を初めとして、多くのツールが開発され利用可能な状態にある。さらに、Ｍａｃｉｎｔｏｓｈ（登録商標）、Ｗｉｎｄｏｗｓ（登録商標）、ＵＮＩＸ（登録商標）環境で作動するＣ言語ベースのものも普及しつつある。

クライアント側エージェント２００が備える異常診断エキスパートシステム２１０は、データが入力された知識ベースを備えるエキスパートシステムとして、プリンタ２０とともにユーザに提供しても良く、汎用のエキスパートシステム構築ツールとして、ユーザに提供しても良い。後者の場合、知識ベースに入れるデータは、ユーザサポート用サーバＳＶからダウンロードする。なお、いずれの場合も知識ベース内のデータを更新できるようにするのが好ましい。

クライアント側エージェントの監視・制御部２０１は、異常の検出と異常診断のための情報の収集を行うクライアント側エージェント２００の中核部である。このクライアント側監視・制御部２０１は、クライアント側異常診断エキスパートシステム２１０を制御するとともに、インタフェース専用回路５０を介して、オペレーティングシステム１１と、アプリケーションプログラム１４と、異常診断の対象となるモジュール（プリンタドライバ１２と、ファームウェア２２と、機構部３０）をも制御する。これにより、印刷部１００の異常診断のための情報収集とその異常の修復を行う。なお、異常診断の対象に、オペレーティングシステム１１やアプリケーションプログラム１４を加えても良い。

図１２は、サーバ側エージェント２２０を中心としたサポートシステムの構成を示すブロック図である。このサーバ側エージェント２２０は、監視・制御部２２１と異常診断エキスパートシステム２３０とから構成されている。このサーバ側監視・制御部２２１は、状況に応じてインターネットを介して、クライアント側エージェント２００とネゴシエートすることができ、印刷部１００を直接的に監視・制御することもできる。このサーバ側異常診断エキスパートシステム２３０は、クライアント側異常診断エキスパートシステム２１０と同様に、推論エンジン２３１と、知識ベース２３２とを備え、さらに、専門家であるサポート要員が知識ベース２３２を編集するためのルールエディタ２３４を備える。

図１３は、本発明の実施例における異常診断処理の手順を示すフローチャートである。ステップＳ４０１では、クライアント側エージェント２００の監視・制御部２０１が印刷部１００の異常を検出する。この異常検出が異常診断処理のトリガーとなる。なお、異常が検出されなくても、ユーザサポート用アイコンをクリックすれば、異常診断処理が開始される。この異常診断処理が開始されると、後述するダイアログボックスが表示される。

図１４は、クライアントシステムが診断中であることを示すダイアログボックスを例示する説明図である。このダイアログボックスは、クライアント側エージェント２００、サーバ側エージェント２２０、またはその双方が、印刷部１００の異常診断を行っていることを示すものである。この異常診断を中止したい場合は、「中止」をクリックすると異常診断が中止される。このダイアログボックスにより、ユーザは、印刷部１００の状況を知ることができるとともに、この異常診断をいつでも中止することができる。

ステップＳ４０２では、クライアント側エージェント２００が印刷部１００の異常診断を行う。この異常診断は、印刷部１００の内部で行う診断である。この診断により、診断結果が取得できれば異常解決処理に進み、診断不能と判断されるとダイアログボックス（図示せず）が表示される。このダイアログボックスは、ユーザサポート用サーバＳＶへのインターネット経由の接続許可をユーザに求めるものである。このユーザサポート用サーバＳＶへの接続は、クライアント側エージェント２００で行う印刷部１００内部の異常診断から、サーバ側エージェント２２０によるリモート異常診断またはクライアント側エージェント２００とサーバ側エージェント２２０の協調による異常診断に移行するために行うものである。この接続が完了すると、ステップＳ４０３に進む。

ステップＳ４０３では、サーバ側エージェント２２０が関与する異常診断が行われる。この異常診断には、前述のように様々な態様があり、たとえば、クライアント側エージェント２００に替わって、サーバ側エージェント２２０が直接的に印刷部１００を診断する態様と、サーバ側エージェント２２０とクライアント側エージェント２００とが協調して異常診断を行う態様とがある。さらに、この協調による異常診断には、サーバ側エージェント２２０とクライアント側エージェント２００とが互いに通信を行う態様と、黒板と呼ばれる共有メモリを、たとえば、サーバ側に設ける態様とがある。一般に、協調による異常診断の方が、サーバ側エージェント２２０のみによる異常診断より深刻な事態に対応できるという利点があるが、インターネットの通信量が多くなるという欠点を有する。したがって、異常の状況に応じて、いずれかを選ぶのが好ましい。たとえば、最初の段階では、サーバ側エージェント２２０のみが診断を行い、診断結果が出ない場合や後述する推定確率が低い場合に、協調診断に移行するようにしても良い。

以上の診断の結果、診断結果が取得されたときは異常解決処理に進み、診断不能と判断されたときはダイアログボックス（図示せず）が表示される。このダイアログボックスは、人工知能（エキスパートシステム）によっては、異常の診断ができなかったことをユーザに知らせるとともに、サポート要員による異常診断への移行の許可をユーザに求めるものである。サポート要員による異常診断への移行が許可されなかったときは、異常診断処理は終了し、その旨が表示される。一方、この許可が為された場合、図９に示すダイアログが表示され、これにユーザが入力してサポートセンタに送信すると、ステップＳ４０４に進む。

ステップＳ４０４では、サポート要員による異常診断が行われる。この異常診断の際、サポート要員は、クライアント側エージェント２００とサーバ側エージェント２２０が収集した情報とその診断結果を考慮して、図９に示すフォームにユーザが記載した状況を分析することができる。これにより、サポート要員による異常診断についてもその負担が軽減される。一方、ユーザも印刷部１００の状況の説明を簡略化でき、負担が軽減される。サポート要員による異常診断によっても診断ができないときは、ダイアログボックス（図示せず）が表示される。このダイアログボックスは、プリンタ２０の回収またはサービスマンの派遣を希望するかどうかをユーザに問い合わせるものである。ユーザがプリンタ２０の回収等を希望しないときは異常診断処理を終了し、希望するときはステップＳ４０５に進む。

ステップＳ４０５では、状況に応じてプリンタ２０の回収またはサービスマンの派遣が行われる。この際、プリンタＩＤによりプリンタ２０が特定されているので、回収されたプリンタ２０の修理担当者に、異常診断に関する情報や記録されている修理履歴を提供することができる。これにより、修理の負担も軽減される。また、サービスマンの派遣に際しても、同様の情報をあらかじめ提供することができる。

図１５は、クライアント側エージェント２００による異常診断処理の手順を示すフローチャートである。ステップＳ５０１では、クライアント側エージェント２００がログ情報を取得する。このログ情報には、前述のように、印刷ログ情報と操作ログ情報とがある。ログ情報は、コンピュータ９０の記憶装置とプリンタ２０のＭＩＢ４６の少なくとも一方に記録されており、いずれかから読み出す。

印刷ログ情報は、サポートの対象となるプリンタ２０の過去における印刷に関する情報、たとえば、どのような印刷環境で、いつ、どれだけの量の印刷が行われたかを表す情報である。過去にどのような印刷作業が実行されたかで、たとえば、プリンタ２０の負荷の大きさを知ることができ、異常の特定の参考とすることができる。たとえば、プリンタ２０の特定の部品の寿命が近づいているかどうかの判断の資料となる。また、異常発生の前に極めて長い間プリンタ２０が使用されていないときは、インクの揮発による濃縮化やノズルの詰まりが疑われる。

また、過去に多くの印刷作業を行っているか否かで、ユーザの印刷作業に関する技量を知ることもできる。これにより、たとえば、ユーザの操作方法に問題があるのを、「故障」としてサポートを求めてきていないかどうかの判断の一資料ともなる。さらに、ユーザの使用に関する問題、たとえば、ユーザが使用方法で困っているようなときにサポートを求めてきた場合にも、ユーザの技量を推定することができ、サポートが容易になる。

操作ログ情報は、たとえば、エラー発生時またはサポート用アイコンのクリック時の前の、一定期間の操作内容の記録である。この記録は、コンピュータ９０やプリンタ２０に対してなされた操作内容の特定に使用できる。この情報は、クライアントシステム内の所定のメッセージ信号やイベント信号に関する情報である。また、この操作ログ情報には、エラーコードやエラーメッセージを含めても良い。これにより、異常の特定がさらに容易になるからである。

ステップＳ５０２では、印刷環境情報の取得を行う。印刷環境情報には、図５に示すように、たとえば、オペレーティングシステム１１、プリンタドライバ１２、およびファームウェア２２の情報（バージョン情報と設定情報）、インクカートリッジＩＤ、インク残量、インク開封日、コンピュータ９０搭載のメモリの量、ＣＰＵといった印刷部１００による印刷の実行に関係のある環境情報が含まれる。この印刷環境情報には、過去における印刷環境の変化の径時的な記録を含めるのが好ましい。正常に印刷しているときの印刷環境を知ることが、異常の診断に特に有益だからである。

ステップＳ５０３では、異常部位の特定を行う。異常部位の特定とは、たとえば、プリンタドライバ１２、コンピュータ９０とプリンタ２０の接続部、ファームウェア２２、機構部３０のいずれに異常があるかを特定するための処理である。これは、異常診断の推定精度を上げるために行う処理である。

図１６は、本発明の実施例における異常部位特定処理の手順を示すフローチャートである。ステップＳ６０１では、たとえば、クライアント側エージェント２００の監視・制御部２０１が１００×１００のＲＧＢテストデータをプリンタドライバ１２に入力する。ステップＳ６０２では、プリンタドライバ１２による処理データと正常時におけるプリンタドライバ１２の処理データとを比較する。正常時におけるプリンタドライバ１２の処理データは、たとえば、プリンタドライバ１２インストール時に、あらかじめクライアント側エージェント２００が取得しておいたものである。

この両処理データが一致する場合、プリンタドライバ１２は正常に処理していることになる。一方、処理データに不一致が見られた場合、プリンタドライバ１２が正常に処理していないことが明らかになる。すなわち、プリンタドライバ１２の作動に異常があることが分かる。

ステップＳ６０３では、ファームウェア２２の入力データをチェックする。入力データをチェックするのは、コンピュータ９０とプリンタ２０との接続をチェックするためである。このチェックは、たとえば、プリンタドライバ１２の出力データをプリンタ２０に送信し、プリンタ２０でバッファして、さらに、コンピュータ９０に送り返し、そのデータとプリンタドライバ１２の出力データを比較する方法が考えられる。これにより、コンピュータ９０とプリンタ２０との接続に問題があるかどうかが明らかになる。また、コンピュータ９０とプリンタ２０との間で行われる制御データの確認も同様にして行うのが好ましい。たとえば、制御信号にノイズが乗って問題が生じている場合に、その特定が可能となるからである。

ステップＳ６０４では、ファームウェア２２の作動をチェックする。このチェックは、プリンタドライバ１２のチェックと同様の方法により行うことができる。ステップＳ６０５では、機構部３０のチェックを行う。このチェックは、機構部の中に備えられたセンサを使用して、たとえば、紙づまりの有無をチェックする。なお、異常部位特定処理の対象に、アプリケーションプログラム１４やオペレーティングシステム１１を含めても良い。異常部位特定処理が終了すると、ステップ５０４に進む。

ステップＳ５０４では、印刷部１００の状態推定を行う。この状態推定は、ステップＳ５０１〜５０３で取得した情報に基づいて、たとえば、
（１）プリンタドライバ１２が他のソフトウェアと干渉している。
（２）ファームウェア２２が破損している。
（３）コンピュータ９０とプリンタ２０の接続に問題がある。
といった観点からの印刷部１００の状態の推定である。

ステップＳ５０５では、修復計画を生成する。この修復計画は、印刷部１００の推定された状態から正常な状態へ変化させるための工程を規定するものである。たとえば、プリンタドライバ１２が他の特定のソフトウェアと干渉している場合、そのソフトウェアを削除するのが最も簡単な修復方法である。ファームウェア２２が破損している場合、ファームウェア２２の再インストールが可能であればそれが最も簡単な修復方法である。ファームウェア２２の再インストールは、ファームウェア２２が、ＥＥＰＲＯＭのような書き換え可能なメモリに格納されていれば可能である。また、コンピュータ９０とプリンタ２０の接続に問題がある場合、接続コネクタにぐらつきはないか、接続方法に問題がないかをユーザに確認するように示唆することが考えられる。

修復計画を生成において、複数の診断結果と複数の修復方法が得られた場合、クライアント側エージェント２００は、ユーザにとって負担の小さなものから順に提案する。たとえば、プリンタドライバ１２が他のソフトウェアと干渉しているとの推定の確率が４０％で、ファームウェア２２が破損しているとの推定の確率が３０％の場合、推定確率だけを考慮すると他のソフトウェアの削除が第１の修復方法案となる。しかし、この場合、そのソフトウェアをユーザが使用することができなくなる。一方、ファームウェア２２の再インストールは、ユーザにとって負担がないに等しい。したがって、この場合は、ファームウェア２２の再インストールが第１の修復計画となる。

また、第１に優先となる修復計画は、エキスパートシステムによる自動修復が可能なソフト的なものとし、第２に優先される修復計画は、ユーザがハード的に修復できるもの、たとえば、コンピュータ９０とプリンタ２０との接続方法の変更とし、最後はサービスマンの派遣や回収とする。こうすれば、最小の負担で修復が可能となる確率が高くなる。

ステップＳ５０６では、診断結果の決定可否を判断する。この判断は、推定確率と修復負担とから、有効な解決方法が見いだせたか否かにより、総合的に判断する。たとえば、推定確率が十分大きく修復負担が十分小さい場合には、ユーザに提示する診断結果として決定する。また、推定確率が多少小さくても修復負担が極めて小さい場合には、それを診断結果として決定する。一方、推定確率が多少大きくても、ユーザ負担が極めて大きい大きい場合、たとえば、回収が必要と診断された場合は決定しない。診断結果が決定されたときは、クライアント側エージェント２００による異常解決処理に進み、診断結果が決定されないときは、サーバ側エージェント２２０の異常診断処理に進む。

図１７は、本発明の実施例におけるクライアント側エージェント２００による異常解決処理の手順を示すフローチャートである。ステップＳ７０１では、推論過程説明部２１３が推論過程の情報を生成する。この情報は、異常診断における推論過程をユーザに説明するためのデータ、たとえば、テキストデータであり、ユーザが、エキスパートシステムによる診断結果と修復計画の提案の受諾または拒否の判断に使用するものである。この情報の生成が完了すると、ステップＳ７０２に進み、解決方法の提案と推定過程の説明が行われる。

図１８は、クライアント側エージェント２００による診断結果を示すダイアログボックスを例示する説明図である。このダイアログボックスは、異常についての診断結果をユーザに知らせるとともに、その修復方法をユーザに提案する。また、「推定過程の確認」をクリックすると、診断結果に至るまでの推定の過程をユーザに説明する画面が表示される。この画面については後述する。

ユーザは、診断結果を見て、また、必要であればその推定過程も見て、修復方法が妥当か否かを判断する。ユーザが妥当と判断して、「はい」をクリックするとステップＳ７０３に進み、クライアント側エージェント２００が印刷部１００の修復を行う。一方、ユーザが妥当でないと判断して、「いいえ」をクリックすると、別の修復計画を提案することになる。エージェントによる修復作業が完了すると、ステップＳ７０４に進む。一方、クライアント側エージェント２００によるすべての提案を受諾できない場合は、サーバ側エージェント２２０が関与する異常診断処理に進む。

ステップＳ７０２とＳ７０３を具体例を使用して説明する。この例では、あるソフトウェアとプリンタドライバ１２が干渉しているとの診断結果が得られた場合である。この場合、クライアント側エージェント２００は、図１８に示すようなダイアログボックスを表示して、修復方法の提案受諾を求める。ユーザが受諾した場合、たとえば、試しにインストールしたフリーウェアのように、そのソフトウェアが重要なものでないときは、「はい」をクリックすれば、そのソフトウェアを、クライアント側エージェント２００の監視・制御部２０１が削除する。

この際、ユーザは、「推定過程の確認」をクリックすることにより、推定過程を確認することもできる。この推定過程は、ユーザがクライアント側エージェント２００が提案する修復計画を受諾するかどうかの参考となるものである。一方、そのソフトウェアの削除を望まない場合は、ユーザは、「いいえ」をクリックする。そうすると第２の修復計画が提示される。第２の修復計画がない場合は、ユーザサポート用サーバＳＶに接続して診断をサーバ側エージェント２２０も含めて再度診断を行う。あるいは、複数の診断結果と修復計画を同時に表示して、ユーザに選択させるようにしても良い。

図１９は、クライアント側エージェント２００による推定過程を示すダイアログボックスを例示する説明図である。このダイアログボックスは、修復提案の受諾を行うかどうかについてのユーザの判断を、より的確かつ容易にするものである。また、図１９に示すように、このダイアログボックスで、クライアント側エージェント２００が感知できない症状をユーザに確認させるのが好ましい。これにより、ユーザはより的確な判断ができるからである。たとえば、症状が印刷結果に生ずる問題である。

ステップＳ７０４では、ユーザに対して、問題が解決したかどうかダイアログボックス（図示せず）で確認する。この結果、問題が解決したときは、ステップＳ７０５に進み、問題が解決しないときは、サーバ側エージェント２２０による異常診断処理に進む。ステップＳ７０５では、クライアント側エージェント２００の知識ベースの更新を行う。この更新は、第１に推定確率を見直すためのものである。すなわち、異常が解決したときは、その診断に使用した知識の推定確率を上げる。第２に、特定の異常を解決した旨を記録し、次回に同じ状態になったときにユーザに知らせるためのものである。

図２０は、サーバ側エージェント２２０による異常診断処理の手順を示すフローチャートである。ステップＳ８０１では、コンピュータ９０がユーザサポート用サーバＳＶにアクセスする。このアクセスは、クライアント側エージェント２００が、ユーザの許諾を得て自動で行う。このとき、ユーザの許諾は、ダイアログボックス（図示せず）を使って行う。

ステップＳ８０２では、クライアント側エージェント２００が、その収集した情報と診断結果をユーザサポート用サーバＳＶに送信する。これにより、サーバ側エージェント２２０がクライアント側エージェント２００が取得した情報と診断結果を得ることができる。サーバ側エージェント２２０は、この情報に基づいて診断を行う。この診断を行う方法には、サーバ側エージェント２２０がクライアント側エージェント２００に替わって単独で診断する方法と、サーバ側エージェント２２０がクライアント側エージェント２００と協調して、診断を行う方法がある。後者は、一般に、マルチエージェントシステムと呼ばれる。

また、マルチエージェントシステムには、エージェント同士が通信して情報を共有する契約ネットの方式と、二つのエージェントがメモリを共有する黒板方式とがある。

ステップＳ８０３では、クライアント側エージェント２００を介したさらなる情報収集を行う。この情報収集は、サーバ側エージェント２２０が、診断のためにさらに情報収集が必要と判断した場合に行われる。情報収集の方法は、サーバ側エージェント２２０がクライアント側エージェント２００に情報を要求するか、サーバ側エージェント２２０がクライアント側エージェント２００をスレーブエージェントして、直接制御することにより行う。

ステップＳ８０４では、サーバ側エージェント２２０の異常診断エキスパートシステム２３０が、その収集した情報に基づいて、その知識ベース２３２を使用して診断する。この代わりに、サーバ側エージェント２２０が、クライアント側エージェント２００と協調して、印刷部１００の状態推定を行うようにしてもよい。ステップＳ８０５では、この推定された状態に基づいて、修復計画を生成する。ステップＳ８０６では、診断結果をコンピュータ９０に表示し、サーバ側エージェント２２０による異常解決処理に進む。診断不能と判断された場合は、サポート要員による異常診断に進む。

図２１は、サーバ側エージェント２２０による異常解決処理の手順を示すフローチャートである。サーバ側エージェント２２０は、最新の知識ベース２３２を使用して、診断と修復計画を行うことができる。たとえば、知識ベース２３２に、最新のバージョンのプリンタドライバ１２が、前述したソフトウェアとの干渉を起こさない旨のデータがあった場合、プリンタドライバ１２の最新のバージョンへの更新で異常を解決できる旨の診断を決定できる。

サーバ側エージェント２２０による異常解決処理の手順は、クライアント側エージェント２００による異常解決処理の手順とほぼ同じである。ただし、サーバ側エージェント２２０による提案が拒否された場合の後の処理と、問題が解決したの後の処理（ステップＳ９０５）が異なる。すなわち、このような提案が拒否された場合、サポート要員によるサポートに移行する。また、問題が解決したの後は、サーバ側の知識ベース２３２が更新されるが、この更新は、解決までの過程を確認したサポート要員がルールエディタ２３４（図１２）を用いて行うのが好ましい。さらに、更新された知識ベースの一部を、デバイスに応じて、ユーザにダウンロードできるようにすることもできる。このときには、デバイスＩＤを用いて、必要な知識ベースを特定することもできる。

図２２は、サーバ側エージェント２２０による診断結果を示すダイアログボックスを例示する説明図である。このダイアログボックスは、新しいプリンタドライバ１２への更新の可否をユーザに問い合わせるものである。ユーザが「はい」をクリックすると、サーバ側エージェント２２０が、ユーザサポート用サーバＳＶ内のプリンタドライバ１２のデータを使用して、自動的にコンピュータ９０のプリンタドライバ１２を更新する。ユーザが「いいえ」をクリックすると、第２の修復計画が提示されるか、サポート要員による診断に移行する。このときも、修復計画が複数あるときは、最初から複数提示するようにしても良い。

サポート要員による診断への移行に際しては、図７〜図９が表示され、本発明の第１の実施例（サポート要員を中心としたユーザサポート）の手順で処理が行われる。ただし、前述のように、サポート要員は、クライアント側エージェント２００とサーバ側エージェント２２０により収集した情報と診断結果を使用して診断を行うことができる。

サポート要員による診断により異常が解決した場合、診断結果と異常の解決方法に関する情報をデータベース化し、他のサポート要員が使用できるようにするとともに、知識ベースを更新することもできる。具体的には、ルールエディタ２３４（図１２）を使用して、サーバ側知識ベース２３２を更新し、さらに、クライアント側知識ベース２１２も更新可能とするのが好ましい。こうすれば、同様のサポートの要請に対して、人工知能で対応することでき、重複労力が軽減されることになる。

以上に説明した人工知能を中心としたサポート方法は、ユーザのサポート負担を飛躍的に軽減するとともに、サポート要員の重複労力を軽減することができる。

Ｄ．サポート例：
以下では、上述した実施例において、デバイスの異常がどのように解決されるかを具体例に則して説明する。第１の事例は、Ｍａｃｉｎｔｏｓｈ環境で特定のアプリケーションプログラム１４（図１）を使用して印刷をしようとするとコンピュータ９０がフリーズする場合である。このときの症状は、特定のアプリケーションプログラム１４が停止し、所定のエラーメッセージがディスプレイ上に表示されて正常に印刷できないというものである。この異常は、以下の条件で発生する。
（１）オペレーティングシステム１１がＭａｃｉｎｔｏｓｈである。
（２）特定のアプリケーションプログラム１４でのみ発生する。
（３）プリンタドライバ１２の設定が「ページを縮小する」に設定されている。
この事例に対する最も有効な対応策は、プリンタドライバ１２の設定を「ページを縮小する」から、「プリント領域外の部分はプリントしない」または「プリント領域外の部分を別ページにプリントする」に変更することである。

この事例において、サポート要員を中心としたユーザサポートは、以下のように行われる。サポート要員は、オンラインで印刷環境情報と操作ログ情報を取得しており、この情報には、
（１）オペレーティングシステム１１がＭａｃｉｎｔｏｓｈであること。
（２）特定のアプリケーションプログラム１４の操作においてエラーが発生していること。
（３）所定のエラーメッセージが出力されていること。
（４）プリンタドライバ１２の設定が「ページを縮小する」に設定されている。
が含まれている。したがって、異常の原因を容易に特定することが可能である。この特定は、サポートセンタにあるサポートのための共有データベースと照合することにより、客観的に行うのが好ましい。

異常を特定したと判断したサポート要員は、ユーザに対して、電子メールや電話で症状を確認した上で、プリンタドライバ１２の設定の変更その他の有効な異常回避方法を提案することができる。

このように、ユーザが異常の状況を説明しなくても、サポート要員は、客観的かつ正確な情報を容易に取得することができる。これにより、ユーザとサポート要員の双方の負担が大きく軽減され、円滑なサポートができることになる。

一方、人工知能を中心としたユーザサポートは、以下のように行われる。クライアント側エージェント２００（図１１）は、そのクライアント側監視・制御部２０１を通じて、コンピュータ９０の内部で印刷環境情報と操作ログ情報を取得しており、この情報には、
（１）オペレーティングシステム１１がＭａｃｉｎｔｏｓｈであること。
（２）特定のアプリケーションプログラム１４の操作においてエラーが発生していること。
（３）所定のエラーメッセージが出力されていること。
（４）プリンタドライバ１２の設定が「ページを縮小する」に設定されている。
といった情報が含まれている。

印刷環境情報と操作ログ情報から、不具合が発生する条件を満たし、その確率が８０％であることが分かる。クライアント側エージェント２００の異常診断エキスパートシステムが有する知識ベース２１２には、この異常が発生する条件とその条件が満たされた場合の異常の発生確率（８０％とする）、そして異常が発生したときの症状が入力されているからである。

次に、異常部位特定処理（図１６）で、プリンタドライバ１２等自体の異常の有無を確認する。プリンタドライバ１２等自体に異常がなければ、アプリケーションプログラム１４自体またはアプリケーションプログラム１４とプリンタドライバ１２の相性に問題があることが５０％の確率で推定できる。

以上の分析より、印刷部１００の状態として９０％の推定確率で上記の異常があることが自動的に推定できる。この推定に基づいて、正常な印刷部１００に修復するための手順を策定する。この修復計画の策定が完了すると、診断結果をユーザに知らせて修復方法を提案するダイアログボックス（図２３）が表示される。

図２３は、診断結果を示すダイアログボックスを例示する説明図である。このダイアログを見ることにより、ユーザは、異常の原因とその修復方法の概要を知ることができる。ユーザは、この情報に基づいて、クライアント側エージェント２００による修復を許可するか否かを判断することがきる。ユーザは、この提示された情報のみでクライアント側エージェント２００に修復を任せて良いと判断した場合、「はい」をクリックする。推定過程を確認したい場合は、「推定状態の確認」をクリックする。一方、この診断に承服できないときは、「いいえ」をクリックする。

図２４は、診断結果に至るまでの推定過程を示すダイアログボックスを例示する説明図である。このダイアログボックスは、クライアント側エージェント２００による診断と修復方法の適否を、ユーザが判断するためのものである。このダイアログボックスは、複数ページに渡るものとしても良く。また、判断の要素となる各判断基準の推定確率を表示するものでも良い。さらに、診断された異常からユーザが関知できる症状を表示することにより、ユーザによる判断を容易にするのが好ましい。

クライアント側エージェント２００による診断の結果、複数の異常が推定され、各々の確率の差が小さい場合、この画面でユーザと対話する事により、状態推定を進めるようにしても良い。たとえば、推定された各状態に伴う症状をユーザに説明し、該当するか否かをユーザが選択的に回答させることで、推定を進めることができる。これにより、さらに、精度の高い推定が可能となる。

図２５は、複数の修復方法を示すダイアログボックスを例示する説明図である。この事例においては、修復方法に選択の余地があるので、複数の修復方法が提案されている。ユーザは、この中から、自分が望む修復方法を選択し、クリックする。こうすると、クライアント側エージェント２００がその監視・制御部２０１を用いて、自動的に修復する。

以上のように、クライアント側エージェント２００とサーバ側エージェント２２０が自動的に診断・修復することにより、異常発生時のユーザ側の負担は大きく軽減される。また、ユーザサポートを一部自動化することにより、ユーザサポートの重複労力が軽減され、その円滑な運用が可能となる。

Ｅ．新技術の先行提供：
図２６は、本発明の実施例における新技術の先行提供の手順を示すフローチャートであり、図２７は、希望するサポートの内容をユーザに問い合わせるダイアログボックスを例示する説明図である。この処理は、たとえば、プリンタドライバ１２のベータ版の配布のように、品質の保証がなされていないソフトウェアの先行版を特定のユーザにのみ配布するための処理である。この処理は、以下の手順で行われる。

ステップＳ１００１では、ユーザがユーザサポートアイコンをクリックする。そうすると、希望するサポートの内容をユーザに問い合わせるダイアログボックスがコンピュータ９０のディスプレイに表示される。ユーザが「新技術を試す」をクリックすると、ステップＳ１００２に進む。

ステップＳ１００２では、コンピュータ９０が、インターネットを介してユーザサポート用サーバＳＶに接続される。ステップＳ１００３では、オーソライゼーションがなされる。このオーソライゼーションは、クライアントシステムがユーザ登録において取得したユーザＩＤ、プリンタＩＤ、およびパスワードを送信し、ユーザサポート用サーバがそれを確認することにより行われる。

ステップＳ１００４では、ユーザがソフトウェアを選択する。この選択は、たとえば、ダイアログボックス（図示せず）にリストアップされるソフトウェアから、ユーザが試してみたいものをクリックすることにより行われる。ステップＳ１００５では、選択されたソフトウェアを、プリンタ２０に接続されたコンピュータ９０にインストールする。このインストールは、ユーザサポート用サーバＳＶがコンピュータ９０に対して直接行う。また、インストールするソフトウェアは、たとえば、そのプリンタでのみ動作するように、ソースコードを修正した上でコンパイルしたものである。こうすれば、そのソフトウェアは、インストールされたコンピュータ９０上でしか作動しないことになる。

インストールが正常に完了すると、その旨がユーザサポートサーバに送信され、そのユーザのユーザＩＤとプリンタＩＤが登録される。この際、印刷環境情報をユーザサポート用サーバＳＶに自動的にアップロードするのが好ましい。

以上の手順により、新技術の提供を登録ユーザに限定することができ、また、品質の保証がなされていないソフトウェアが再配布により拡散するという弊害を防止することができる。

Ｆ．変形例：
なお、この発明は上記の実施例や実施形態に限られるものではなく、その要旨を逸脱しない範囲において種々の態様において実施することが可能であり、たとえば次のような変形も可能である。

本発明の機能の一部または全部がソフトウェアで実現される場合には、そのソフトウェア（コンピュータプログラム）は、コンピュータ読み取り可能な記録媒体に格納された形で提供することができる。この発明において、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスクやＣＤ−ＲＯＭのような携帯型の記録媒体に限らず、各種のＲＡＭやＲＯＭ等のコンピュータ内の内部記憶装置や、ハードディスク等のコンピュータに固定されている外部記憶装置も含んでいる。

ユーザサポートをオンラインで行う場合のシステム構成例を示す説明図。 オンラインサポート用ユーザ登録処理の手順を示すフローチャート。 ユーザに対して情報提供の可否の問い合わせを行うダイアログボックスを例示する説明図。 ユーザサポート用サーバへの登録処理の手順を示すフローチャート。 ユーザサポートのためにクライアント側からユーザサポート用サーバに送信する情報を例示する表。 サポート要員によるユーザサポート処理の手順を示すフローチャート。 希望するサポートの内容をユーザに問い合わせるダイアログボックスを例示する説明図。 ユーザの連絡先を確認するダイアログボックスを例示する説明図。 ユーザの置かれている状況の説明を入力する送信フォームを例示する説明図。 分散型人工知能によるユーザサポートシステムの構成を示すブロック図。 クライアント側エージェントを中心とした印刷部の構成を示すブロック図。 サーバ側エージェント２２０を中心としたサポートシステムの構成を示すブロック図。 本発明の実施例における異常診断処理の手順を示すフローチャート。 クライアントシステムが診断中であることを示すダイアログボックスを例示する説明図。 クライアント側エージェントによる異常診断処理の手順を示すフローチャート。 本発明の実施例における異常部位特定処理の手順を示すフローチャート。 クライアント側エージェントによる異常解決処理の手順を示すフローチャート。 クライアント側エージェント２００による診断結果を示すダイアログボックスを例示する説明図。 クライアント側エージェントによる推定過程を示すダイアログボックスを例示する説明図。 サーバ側エージェント２２０による異常診断処理の手順を示すフローチャート。 サーバ側エージェント２２０による異常解決処理の手順を示すフローチャート。 サーバ側エージェント２２０による診断結果を示すダイアログボックスを例示する説明図。 診断結果を示すダイアログボックスを例示する説明図。 診断結果に至るまでの推定過程を示すダイアログボックスを例示する説明図。 複数の修復方法を示すダイアログボックスを例示する説明図。 本発明の実施例における新技術先行提供の手順を示すフローチャート。 希望するサポートの内容をユーザに問い合わせるダイアログボックスを例示する説明図。

符号の説明

１０…ブラウザ
１１…オペレーティングシステム
１２…プリンタドライバ
１４…アプリケーションプログラム
２０…プリンタ
２２…ファームウェア
３０…機構部
４６…ＭＩＢ
５０…インタフェース専用回路
９０…コンピュータ
１００…印刷部
１２０…送信フォーム
２００…クライアント側エージェント
２０１…クライアント側監視・制御部
２１０…クライアント側異常診断エキスパートシステム
２１１…クライアント側推論エンジン
２１２…クライアント側知識ベース
２１３…クライアント側推論過程説明部
２２０…サーバ側エージェント
２２１…サーバ側エージェント監視・制御部
２３０…サーバ側異常診断エキスパートシステム
２３１…サーバ側推論エンジン
２３２…サーバ側知識ベース
２３３…サーバ側側推論過程説明部
２３４…ルールエディタ
ＳＶ…ユーザサポート用サーバ

Claims (4)

1. コンピュータに接続されたデバイスの使用をサポートするユーザサポート方法であって、
   前記コンピュータは、前記デバイスを制御する第１の制御部と、前記第１の制御部を診断するための第１の入力テストデータと、前記第１の入力テストデータが前記第１の制御部に入力されたときに出力されるべき第１の出力テストデータと、を格納し、
   前記ユーザサポート方法は、
   前記コンピュータが前記第１の制御部に前記第１の入力テストデータを入力する入力工程と、
   前記コンピュータが前記第１の制御部に前記第１の入力テストデータを処理させる処理工程と、
   前記コンピュータが前記処理の結果得られた第１の処理データと前記第１の出力テストデータとを比較し、前記第１の処理データと前記第１の出力テストデータとが一致した場合には前記第１の制御部が正常であると診断し、前記第１の処理データと前記第１の出力テストデータとが一致しなかった場合には前記第１の制御部が異常を有すると診断する診断工程と、
   を備え、
   前記デバイスは、前記デバイスを制御する第２の制御部を有し、前記コンピュータから送信されたデータを前記第２の制御部で処理して前記コンピュータに返信する作動モードである診断モードを有し、
   前記コンピュータは、前記第２の制御部を診断するための第２の入力テストデータと、前記第２の入力テストデータが前記第２の制御部に入力されたときに出力されるべき第２の出力テストデータと、を格納し、
   前記ユーザサポート方法は、
   前記コンピュータが前記デバイスの作動モードを前記診断モードとする工程と、
   前記コンピュータが前記診断モードのデバイスに前記第２の入力テストデータを送信する送信工程と、
   前記コンピュータが、前記第２の入力テストデータを前記第２の制御部で処理した結果得られた第２の処理データを前記診断モードのデバイスから受信する受信工程と、
   前記コンピュータが前記第２の処理データと前記第２の出力テストデータとを比較し、前記第２の処理データと前記第２の出力テストデータとが一致した場合には前記第２の制御部が正常であると診断し、前記処理データと前記第２の出力テストデータとが一致しなかった場合には前記第２の制御部が異常を有すると診断する診断工程と、
   を備えるユーザサポート方法。
2. 請求項１に記載のユーザサポート方法であって、
   前記デバイスは、前記コンピュータから送信されたデータを前記コンピュータに返信する作動モードである返信モードを有し、
   前記ユーザサポート方法は、
   前記コンピュータが前記デバイスの作動モードを前記返信モードとする工程と、
   前記コンピュータが前記返信モードのデバイスに所定のデータを送信する送信工程と、
   前記コンピュータが前記返信モードのデバイスから前記所定のデータを受信する受信工程と、
   前記送信した所定のデータと前記受信した所定のデータとを比較し、前記送信した所定のデータと前記受信した所定のデータとが一致した場合には前記コンピュータと前記デバイスとの間の通信が正常であると診断し、前記送信した所定のデータと前記受信した所定のデータとが一致しなかった場合には前記コンピュータと前記デバイスとの間の通信が異常を有すると診断する診断工程と、
   を備えるユーザサポート方法。
3. デバイスを制御するとともに、前記デバイスの使用をサポートする装置であって、
   前記デバイスを制御する第１の制御部と、
   前記第１の制御部を診断するための第１の入力テストデータと、前記第１の入力テストデータが前記第１の制御部に入力されたときに出力されるべき第１の出力テストデータと、を格納するテストデータ格納部と、
   を備え、
   前記装置は、
   前記第１の制御部に前記第１の入力テストデータを入力するとともに、前記第１の制御部に前記第１の入力テストデータを処理させる処理部と、
   前記処理の結果得られた第１の処理データと前記第１の出力テストデータとを比較し、前記第１の処理データと前記第１の出力テストデータとが一致した場合には前記第１の制御部が正常であると診断し、前記第１の処理データと前記第１の出力テストデータとが一致しなかった場合には前記第１の制御部が異常を有すると診断する診断部と、
   を備え、
   前記デバイスは、前記デバイスを制御する第２の制御部を有し、前記装置から送信されたデータを前記第２の制御部で処理して前記装置に返信する作動モードである診断モードを有し、
   前記テストデータ格納部は、前記第２の制御部を診断するための第２の入力テストデータと、前記第２の入力テストデータが前記第２の制御部に入力されたときに出力されるべき第２の出力テストデータと、を格納し、
   前記装置の前記処理部は、前記デバイスの作動モードを前記診断モードとし、前記診断モードのデバイスに前記第２の入力テストデータを送信し、前記第２の入力テストデータを前記第２の制御部で処理した結果得られた第２の処理データを前記診断モードのデバイスから受信し、
   前記装置の前記診断部は、前記第２の処理データと前記第２の出力テストデータとを比較し、前記第２の処理データと前記第２の出力テストデータとが一致した場合には前記第２の制御部が正常であると診断し、前記処理データと前記第２の出力テストデータとが一致しなかった場合には前記第２の制御部が異常を有すると診断する、装置。
4. デバイスを制御する第１の制御部と、前記第１の制御部を診断するための第１の入力テストデータと前記第１の入力テストデータが前記第１の制御部に入力されたときに出力されるべき第１の出力テストデータとを格納するテストデータ格納部と、を備えたコンピュータ上において、前記デバイスの使用をサポートするためのコンピュータプログラムを記録したコンピュータ読み取り可能な記録媒体であって、
   前記コンピュータプログラムは、
   前記コンピュータが前記第１の制御部に前記第１の入力テストデータを入力する入力機能と、
   前記コンピュータが前記第１の制御部に前記第１の入力テストデータを処理させる処理機能と、
   前記コンピュータが前記処理の結果得られた第１の処理データと前記第１の出力テストデータとを比較し、前記第１の処理データと前記第１の出力テストデータとが一致した場合には前記第１の制御部が正常であると診断し、前記第１の処理データと前記第１の出力テストデータとが一致しなかった場合には前記第１の制御部が異常を有すると診断する診断機能と、
   を前記コンピュータに実現させ、
   前記デバイスは、前記デバイスを制御する第２の制御部を有し、前記コンピュータから送信されたデータを前記第２の制御部で処理して前記コンピュータに返信する作動モードである診断モードを有し、
   前記コンピュータの前記テストデータ格納部は、前記第２の制御部を診断するための第２の入力テストデータと、前記第２の入力テストデータが前記第２の制御部に入力されたときに出力されるべき第２の出力テストデータと、を格納し、
   前記コンピュータプログラムは、
   前記コンピュータが前記デバイスの作動モードを前記診断モードとする機能と、
   前記コンピュータが前記診断モードのデバイスに前記第２の入力テストデータを送信する送信機能と、
   前記コンピュータが、前記第２の入力テストデータを前記第２の制御部で処理した結果得られた第２の処理データを前記診断モードのデバイスから受信する受信機能と、
   前記コンピュータが前記第２の処理データと前記第２の出力テストデータとを比較し、前記第２の処理データと前記第２の出力テストデータとが一致した場合には前記第２の制御部が正常であると診断し、前記処理データと前記第２の出力テストデータとが一致しなかった場合には前記第２の制御部が異常を有すると診断する第２の診断機能と、
   を前記コンピュータに実現させる、記録媒体。

Images