JP2014179813A - 通信システム、通信端末、および端末プログラム - Google Patents

Abstract

【課題】他の通信端末との間で通信を行う通信端末の利用を支援し、利用者の利便性を向上させること。
【解決手段】通信回線を介して複数の通信端末５が通信を行う通信システム１は、通信端末５に内蔵される機器または通信端末５と接続された機器の状態を診断する診断部と、診断結果データを通信端末５毎に管理する管理部と、通信端末５の診断結果データに基づいて、通信端末５の利用法を判定する判定部と、判定部により判定された利用法に基づく情報を、通信端末５に対して診断された機器の状態とともに表示部に表示処理する表示処理部とを備える。
【選択図】図１

Description

本発明は、通信システム、通信端末、および端末プログラムに関する。

従来から、通信接続される通信端末の情報（例えば故障情報等）をネットワーク経由で収集し、管理する技術が知られている。例えば、特許文献１には、ＯＡ機器の診断結果の解析効率を高める目的で、ＯＡ機器の遠隔診断を行って遠隔診断結果をＨＴＴＰ経由で収集し、Ｗｅｂブラウザを介して閲覧できるようにした遠隔集中管理システムが開示されている。

しかしながら、特許文献１の技術は、あくまでも遠隔集中管理システムを運用する管理者がＯＡ機器を管理するために遠隔診断結果を収集するものであり、遠隔診断結果をＯＡ機器の利用者に提示することは目的としていないことから、例えば複数の通信端末間で通信を行う場合において通信相手となる他の通信端末の状態を把握するため等に活用することは困難であった。そのため、他の通信端末との通信において不具合が生じた場合には、管理者を介した利用者間の問い合わせや、利用者同士が直接連絡する等の必要が生じ、手間であった。

本発明は、上記に鑑みてなされたものであって、他の通信端末との間で通信を行う通信端末の利用を支援し、利用者の利便性を向上させることができる通信システム、通信端末、および端末プログラムを提供することを目的とする。

上記した課題を解決し、目的を達成するため、本発明にかかる通信システムは、通信回線を介して複数の通信端末が通信を行う通信システムであって、前記通信端末に内蔵される機器または前記通信端末と接続された機器の状態を診断する診断部と、診断結果データを前記通信端末毎に管理する管理部と、前記通信端末の診断結果データに基づいて、前記通信端末の利用法を判定する判定部と、前記判定部により判定された利用法に基づく情報を、前記通信端末に対して診断された機器の状態とともに表示部に表示処理する表示処理部と、を備えることを特徴とする。

本発明によれば、互いに通信を行う通信端末の現時点での各々の状態に応じて通信端末の利用法を判定し、利用法例として利用者に提示することができる。したがって、他の通信端末との間で通信を行う通信端末の利用を支援し、利用者の利便性を向上させることができるという効果を奏する。

図１は、通信システムの全体構成例を示す図である。 図２は、サーバおよび通信端末の概略構成例を示すブロック図である。 図３は、サーバおよび通信端末の処理手順を示すフローチャートである。 図４は、機器診断処理の詳細な処理手順を示すフローチャートである。 図５は、診断結果データのデータ構成例を示す図である。 図６は、他の診断結果データのデータ構成例を示す図である。 図７は、端末別診断結果テーブルのデータ構成例を示す図である。 図８は、変形例における診断結果データのデータ構成例を示す図である。 図９は、変形例における他の診断結果データのデータ構成例を示す図である。 図１０は、用途判定テーブルのデータ構成例を示す図である。 図１１は、利用法の判定原理を説明する図である。 図１２は、サーバおよび通信端末の他の処理手順を示すフローチャートである。 図１３は、お知らせ画面の一例を示す図である。 図１４は、詳細画面の一例を示す図である。 図１５は、変形例における通信端末の処理手順を示すフローチャートである。 図１６は、変形例における通信端末の処理手順を示すフローチャートである。 図１７は、変形例における詳細画面の一例を示す図である。 図１８は、通信端末のハードウェア構成例を示すブロック図である。

以下、図面を参照して、本発明の通信システム、通信端末、および端末プログラムを実施するための形態について説明する。なお、この実施の形態によって本発明が限定されるものではない。また、図面の記載において、同一部分には同一の符号を付して示している。

（実施の形態）
図１は、本実施の形態の通信システム１の全体構成例を示す図である。また、図２は、通信システム１を構成するサーバ３および通信端末５の概略構成例を示すブロック図である。図１および図２に示すように、通信システム１は、サーバ３と、通信端末５と、管理ＤＢ７とを含み、サーバ３と通信端末５とが通信回線Ｎを介して通信接続されて構成される。通信回線Ｎは、例えばＬＡＮやインターネット、電話回線網、専用線網、イントラネット等の各種通信網である。なお、図１および図２中では１つの通信端末５を図示しているが、実際には、１つ以上の通信端末５がサーバ３と通信接続される。

本実施の形態では、ビデオ会議に参加する拠点に設置されたビデオ会議端末間で映像データや音声データを送受することによりビデオ会議を行うビデオ会議システムに通信システム１を適用し、通信端末５としてビデオ会議端末を想定した場合を例示する。

この通信システム１では、図１に示すように、通信端末５から診断結果データがサーバ３にアップロードされ（Ｄ１１）、サーバ３からは、お知らせデータと対象端末の診断結果データとが配信データとして通信端末５にダウンロードされる（Ｄ１３）。管理ＤＢ７は、前述の診断結果データや別途利用者全体に向けて用意されるお知らせデータを蓄積しており、サーバ３によって随時これらのデータの書き込みまたは読み出しが行われる（Ｄ１５）。また、サーバ３では、管理者による管理ＤＢ７の参照や後述する配信設定等のためのデータの入出力が行われる（Ｄ１７）。すなわち、管理者は、Ｗｅｂブラウザ等を介して管理ＤＢ７に蓄積される通信端末５毎の診断結果データを閲覧したり、配信設定等のための操作を行う。管理者には、サーバ３の管理者、通信端末５の利用者、通信システム１を含むシステム全体の管理者が含まれる。

サーバ３は、図２に示すように、主な機能部として、管理部３１と、配信部３３とを備える。また、サーバ３は、その他にも、操作部（入力部）や表示部、記録部等の必要な構成を備えている。

管理部３１は、通信端末５からアップロードされた診断結果データを管理ＤＢ７に書き込んで管理する。

配信部３３は、通信端末５毎に配信設定を行う処理、管理ＤＢ７に蓄積された診断結果データやお知らせデータを読み出し、配信設定に従って配信データを作成する処理、通信回線Ｎを介して配信データを通信端末５に送信する処理等を行う。

一方、通信端末５は、利用者側、例えば、ビデオ会議を行う拠点の会議室等に設置される。通信端末５は、複数（図２では２つ）の機器１０（１０−１，２）を有する。

本実施の形態のように通信端末５としてビデオ会議端末を想定している場合、通信端末５はビデオ会議に必要な機器を有している必要があり、これらの機器は、通信端末５に内蔵され、または通信端末５と接続される。ビデオ会議に必要な機器としては、通信端末５に内蔵され、または通信端末５と接続されるマイクやスピーカー、カメラ、ディスプレイ等が挙げられる。以下、通信端末５に内蔵されている機器および接続されている機器を包括して、通信端末５が有する機器１０と呼ぶ。

また、通信端末５は、主な機能部として、診断部としての自己診断部５１と、判定部および表示処理部としての利用法提案部５３と、送信部および受信部としての通信部５５とを備える。また、通信端末５は、その他にも、操作部（入力部）や表示部、記録部等の必要な構成を備えている。なお、通信端末５のハードウェア構成については後述する（図１８を参照）。

自己診断部５１は、通信端末５が有する機器１０を診断するためのものであり、診断した機器１０毎の状態（正常／異常）に基づいて診断結果データを作成し、通信部５５および通信回線Ｎを介してサーバ３にアップロードする。

利用法提案部５３は、自己診断部５１が作成した診断結果データや通信回線Ｎおよび通信部５５を介してサーバ３からダウンロードした配信データ等に基づいて、お知らせおよび利用法例を示す情報を表示部に表示する処理を行う。

通信部５５は、サーバ３との間でデータを送受するためのものであり、モデムやＴＡ、通信ケーブルのジャックや制御回路等によって実現される。

次に、通信システム１においてサーバ３および通信端末５が行う処理の流れについて説明する。本実施の形態では、通信システム１は、個々の通信端末５が実施した自己診断の結果を管理するとともに、利用者に対するお知らせの提示および利用法例の提案を行う。

先ず、自己診断結果の管理について説明する。図３は、そのためのサーバ３および通信端末５の処理手順を示すフローチャートである。図３に示すように、通信端末５では、自己診断部５１が、図３中左側の自己診断の実施手順に従って通信端末５が有する機器１０を診断する。この自己診断の実施は、例えば、通信端末５の起動時等の所定の実施タイミングで行われる。すなわち、自己診断部５１は先ず、機器診断処理を行う（ステップＳ１１）。図４は、機器診断処理の詳細な処理手順を示すフローチャートである。

この機器診断処理では、自己診断部５１は、通信端末５が有する機器１０を順次診断対象とし、機器１０毎にループＡの処理を実行する（ステップＳ３１１〜ステップＳ３２９）。すなわち、ループＡでは、自己診断部５１は先ず、診断対象の機器１０の接続確認を行う（ステップＳ３１３）。そして、自己診断部５１は、該当する機器１０の接続が確認できない場合は、異常ありとして（ステップＳ３１５：Ｙｅｓ）、ステップＳ３２７に移行する。

接続が確認でき、異常がない場合には（ステップＳ３１５：Ｎｏ）、自己診断部５１は、続いて、診断対象の機器１０の応答確認を行う（ステップＳ３１７）。そして、自己診断部５１は、該当する機器の応答が確認できない場合は、異常ありとして（ステップＳ３１９：Ｙｅｓ）、ステップＳ３２７に移行する。

応答が確認でき、異常がない場合には（ステップＳ３１９：Ｎｏ）、自己診断部５１は、続いて、診断対象の機器１０に自己診断機能を実施させる（ステップＳ３２１）。従来から、自己診断機能を備えた機器が知られている。ステップＳ３２１では、診断対象の機器１０が自己診断機能を備えている場合に、これを実施させる。そして、機器１０による自己診断機能の実施によって異常があった場合には（ステップＳ３２３：Ｙｅｓ）、ステップＳ３２７に移行する。異常がなければ（ステップＳ３２３：Ｎｏ）、ステップＳ３２５に移行する。なお、診断対象の機器１０が自己診断機能を備えていない場合には、自己診断部５１は、ステップＳ３２１，ステップＳ３２３の処理は行わずにステップＳ３２５に移行すればよい。

そして、ステップＳ３２５では、自己診断部５１は、診断対象の機器１０を正常とし、該当する機器１０についてのループＡの処理を終える。一方、ステップＳ３２７では、自己診断部５１は、診断対象の機器１０を異常とし、該当する機器１０についてのループＡの処理を終える。

例えば、診断対象の機器１０が、ＵＳＢ（Universal Serial Bus）を用いて通信端末５に接続されたＵＳＢスピーカーであったとする。この場合、自己診断部５１は、ステップＳ３１３の処理として先ず、ＯＳが認識しているＵＳＢ機器一覧の取得要求をＯＳに依頼することによりＵＳＢ機器一覧を取得する。そして、自己診断部５１は、取得したＵＳＢ機器一覧からスピーカーを検索し、存在する場合に接続確認とする一方、存在しなければ異常とする。また、自己診断部５１は、ステップＳ３１７の処理として、初期化処理等のＵＳＢスピーカーの動作環境を設定するための処理の終了を待機し、正常に終了した場合に応答確認とする一方、正常終了しない場合は異常とする。

以上のようにして通信端末５が有する全ての機器１０についてループＡの処理を行ったならば、自己診断部５１は、ステップＳ３２５またはステップＳ３２７において正常または異常とした通信端末５が有する機器１０毎の状態（自己診断結果）を設定した診断結果データを作成し（ステップＳ３３１）。その後、図３のステップＳ１１にリターンしてステップＳ１３に移行する。

図５および図６は、診断結果データのデータ構成例を示す図である。図５では、端末名が「会議室Ａ」の通信端末５で作成された診断結果データを示し、図６では、端末名が「端末Ｂ」の通信端末５で作成された診断結果データを示している。図５および図６に示すように、診断結果データには、機器１０毎の自己診断結果（正常：○／異常：×）が設定される。なお、この診断結果データは、通信端末５が有する機器１０の各々が正常なのか異常なのかの設定を少なくとも含めばよいが、異常の機器１０について異常の内容を含めてもよい。

そして、図３のステップＳ１３では、自己診断部５１は、図４のステップＳ３３１で作成した診断結果データを通信端末５の識別情報とともにサーバ３にアップロードする。識別情報としては、端末名の他、自端末に対して固有に割り当てられた端末ＩＤ等を用いることができる。なお、作成された診断結果データは、自端末の記録部にも記録される。

一方、サーバ３では、通信端末５からアップロードされた診断結果データを受信したならば（ステップＳ２１：Ｙｅｓ）、管理部３１が、受信した診断結果データを受信日時とともに管理ＤＢ７に書き込み、端末別診断結果テーブルとして管理する（ステップＳ２３）。

図７は、端末別診断結果テーブルのデータ構成例を示す図である。図７に示すように、診断結果テーブルには、通信端末５からアップロードされた診断結果データが端末名および受信日時と対応付けられて蓄積される。この診断結果テーブルの１レコード分が、該当する端末名の通信端末５から該当する受信日時にアップロードされた診断結果データ（図５，図６）に相当する。

このように端末別診断結果テーブルによって通信端末５からアップロードされた診断結果データを管理することによれば、例えば、端末名をキーとしてレコードを抽出することによって、最新の受信日時における該当する通信端末５の機器１０の自己診断結果を知ることができる。また、異常の機器１０が存在する場合に、その異常がいつから継続しているのか等の特定も可能である。例えば、図７において会議室Ａに着目すると、該当する通信端末５では、内蔵マイクが２０１３年１月６日１４時３５分の時点では正常であったが、その後の２０１３年１月７日１７時２５分の時点では異常であったことがわかる。

ここで、自己診断は、通信端末５に内蔵も接続もされていない機器について実施することはできないが、通信端末５が有しているべき機器に関する情報を予め設定しておけば、該当する機器が内蔵も接続もされていない場合を異常とする診断結果データを作成できる。例えば、本実施の形態では通信端末５としてビデオ会議端末を想定しているが、通信端末５がディスプレイやプロジェクタ等の映像出力機器を内蔵していない場合には、映像出力機器が接続されていなければビデオ会議端末としては利用できない。このような場合に、映像出力機器を有しているべき機器として設定しておき、有しているべき機器毎に自己診断結果を設定した診断結果データを作成すればよい。これによれば、例えば通信端末５が映像出力機器を有していない場合（接続確認ができない場合）を異常とした診断結果データを作成できる。

なお、通信端末５が有しているべき機器の設定およびその状態の判定は、サーバ３側で行うこととしてもよい。例えば、管理部３１は、有しているべきとして設定されている機器の自己診断結果が通信端末５からアップロードされた診断結果データに含まれない場合に、その状態を異常として診断結果データに追加し、その上で管理ＤＢ７に書き込んで管理する。

また、通信端末５からアップロードされる診断結果データの蓄積形式は、図７に示した端末別診断結果テーブルに限定されるものではない。すなわち、診断結果データの蓄積形式は、通信端末５毎に診断結果データを記録しておくことができ、後から必要な情報を抽出可能な構成であればよい。

また、ここでは、通信端末５において自己診断部５１が自己診断を実施し、機器１０毎に正常または異常を設定した診断結果データを作成することとしたが、診断結果データの内容は適宜変更してよい。

例えば、自己診断結果が異常の機器があったとしても、所定の機能を実現するのには問題ない場合もある。具体的には、通信端末５は、ビデオ会議端末としての用途（利用形態）においては、音声および映像の入出力が可能であればよい。そこで、通信端末５の機能に関する情報を予め設定しておくようにしてもよい。

この場合には、自己診断部５１は、作成部として、機能毎に正常／異常を設定した診断結果データを作成する。具体的には、自己診断部５１は、通信端末５がその用途に必須の機能を実現し得る同種の機器を複数有する場合には、少なくとも１つが正常であればその機能を正常として診断結果データを作成する。例えば、音声入力機能が必須の場合に、仮に通信端末５において故障したマイクが内蔵または接続されていたとしても、正常なマイクが内蔵または接続されていればよい。通信端末５が内蔵カメラと外部カメラを有している場合や、内蔵スピーカーとヘッドホンとを有している場合等も同様である。

図８および図９は、この場合の診断結果データのデータ構成例を示す図であり、通信端末５の機能として映像入力、映像出力、音声入力、音声出力を例示している。具体的には、図８では、図５に示した機器１０毎の自己診断結果から作成した診断結果データを示している。図５に示すように、会議室Ａでは、内蔵マイクの自己診断結果が異常ではあるが、外部マイクが正常であるために音声入力機能を実現できる。この場合は、図８に示すように、音声入力を正常とする診断結果データが作成される。また、図９では、図６に示した機器１０毎の自己診断結果から作成した診断結果データを示している。図６に示すように、端末Ｂでは、内蔵マイクの自己診断結果が異常であり、外部マイクは接続されていない。この場合は、図９に示すように、音声入力機能を異常とする診断結果データが作成される。

なお、通信端末５で実現可能な機能の判定は、サーバ３側で行うこととしてもよい。例えば、通信端末５は、機器１０毎に自己診断結果を設定した診断結果データ（図５，図６）を作成し、サーバ３にアップロードする。一方、サーバ３では、管理部３１が、受信した機器毎の診断結果データを機能毎の正常／異常を設定した診断結果データに変換し（図８，図９）、その上で管理ＤＢ７に書き込んで管理する。

このようにして診断結果データを作成すれば、個々の通信端末５で実現可能な機能を診断結果データから判定できる。また、これによれば、自己診断結果が異常の機器があったとしても、通信端末５が所定の用途に利用できる状況にあれば通信端末５全体としては正常とする判定等も可能となる。例えば、図８に示す会議室Ａでは音声および映像の入出力が可能であるためビデオ会議に利用できるが、図９に示す端末Ｂでは音声の入力ができないため、ビデオ会議には利用できないことが判定できる。

次に、利用者に対するお知らせの提示および利用法例の提案について説明する。先ず、そのためにサーバ３および通信端末５が行う処理の概要について説明する。このお知らせの提示および利用法例の提案にあたり、サーバ３では、配信部３３が、個々の通信端末５に向けたお知らせデータを対象端末の診断結果データとともに配信データとして通信端末５に送信する。

ここで、お知らせデータは、他端末情報を必要としない利用者全体に向けて用意されるお知らせデータと、他端末情報を必要とする対象端末に関するお知らせデータとを含み、通信端末５において解釈可能であって表示部に表示可能なフォーマットで記述された表示画面データとして用意され、または作成される。

利用者全体に向けて用意されるお知らせデータは、例えば、システムのアップデート情報、サービスの停止予定等の情報、過去の障害の発生についての情報、新商品の案内情報、サービスを利用する上でのＴＩＰＳ、サービスの利用状況情報（例えば従量課金であれば指定金額到達等）、管理者からのメッセージ等を内容とする文字データや画像データ、映像データ、音声データ等で構成され、管理ＤＢ７に蓄積される。なお、この利用者全体に向けて用意されるお知らせデータは、管理ＤＢ７ではなくサーバ３自体が有する記録部に記録する構成としてもよいし、サーバ３と通信接続が可能な別のサーバに蓄積しておく構成としてもよい。

一方、対象端末に関するお知らせデータは、該当する他の通信端末５の自己診断結果等を報知するためのものであり、管理ＤＢ７に端末別診断結果テーブルとして蓄積される診断結果データを用いて配信部３３によって作成される。例えば、対象端末に関するお知らせデータは、対象端末において異常の機器（故障機器）についてその原因（故障内容）や異常が発生した時期（故障日時）等を内容とする。

実際に配信データにどのお知らせデータを含めるのかや、どの通信端末５を対象端末とするのかは、予め配信設定として通信端末５毎に設定しておく。この配信設定は、利用者に提示するお知らせの項目に関する設定と、対象端末の設定とを含む。お知らせの項目に関する設定では、配信データに含めるお知らせデータの種別を通信端末５毎に指定する。例えば、サービス停止予定の情報は含め、新商品の案内情報は含めないといったことである。一方、対象端末の設定では、対象端末とする他の通信端末５を通信端末５毎に指定する。例えば、予定されているビデオ会議の参加拠点に従い、各参加拠点の通信端末５毎に通信相手（ビデオ会議の相手先）の通信端末５を対象端末に指定するといったことである。なお、この配信設定は例えば管理者が行うが、利用者が行う構成としてもよい。

また、通信端末５では、利用者に利用法例を提案するために、利用法提案部５３が、サーバ３から配信データとしてダウンロードした対象端末の診断結果データを用いて現時点で可能な自端末の利用法を判定する。ここで、利用法例の判定原理について説明する。例えば、利用法提案部５３は、予め記録部に記録された用途判定テーブルを用い、自端末および対象端末で実現可能な用途を特定する。図１０は、用途判定テーブルのデータ構成例を示す図である。

図１０に示すように、用途判定テーブルは、通信端末５の用途毎に必須の機能が設定されたデータテーブルである。例えば、ビデオ会議であれば、映像入力、映像出力、音声入力、および音声出力の各機能が必須である。これに対し、講演に聴講者として参加する場合や、音声会議に参加する場合は映像入力機能は必須ではないため、例えば映像入力機能が異常の通信端末５では、ビデオ会議は行えないものの、講演（聴講者）や音声会議は行える。したがって、このような場合には、利用法例として、講演（聴講者）の用途や音声会議の用途を提案し得る。ただし、実際には、講演（聴講者）や音声会議の参加者となるためには、講演者となる他の通信端末５や、音声会議の相手先となる他の通信端末５において該当する用途に必須の機能が実現可能となっている必要がある。そのため、利用法提案部５３は、利用法の判定に際し、配信データとしてサーバ３からダウンロードした対象端末の診断結果データを併せて用いる。

ここで、自端末の端末名が「端末Ｂ」であり、対象端末の端末名が「会議室Ａ」であって、各通信端末５において図１１に示す機能が実現可能であったとする。図１１中のレコードＬ１１は、サーバ３からダウンロードした対象端末（会議室Ａ）の診断結果データに相当する。また、レコードＬ１３は、自端末（端末Ｂ）が直前の起動時等に実施した自己診断で得られ、記録部に記録された診断結果データに相当する。

この場合には、利用法提案部５３は、用途判定テーブルに従い、レコードＬ１１の診断結果データから、対象端末である会議室Ａで実現可能な用途を講演（聴講者）および音声会議として特定する。また、利用法提案部５３は、レコードＬ１３の診断結果データから、自端末である端末Ｂで実現可能な用途を講演（聴講者）として特定する。その後、利用法提案部５３は、特定した双方の用途を照らし合わせて提案可能な利用法を判定する。本例では、端末Ｂは音声会議に利用できず、端末Ｂおよび会議室Ａの双方が講演（講演者）に利用できないことから、可能な利用法はないと判定する。これによれば、対象端末の状態との組合せでは不可能な利用法については除外し、現時点で対象端末との間で確実に行える利用法例を利用者に提案することができる。

なお、別の場合として、図１１において端末Ｂの音声入力機能が正常の場合であれば、端末Ｂで実現可能な用途は、ビデオ会議、講演（講演者）、講演（聴講者）、および音声会議として特定されることとなる。この場合には、利用法提案部５３は、会議室Ａとの音声会議、および会議室Ａを聴講者とする講演の２つを端末Ｂにおいて可能な利用法として判定する。

利用法提案部５３は、以上のようにして判定した可能な利用法を利用法例とし、サーバ３から配信データとしてダウンロードした対象端末に関するお知らせデータに利用法例を示す情報を含めて表示部に表示する。これにより、利用者にお知らせが提示され、利用法例の提案を示す情報が表示される。

なお、現時点では不可能な利用法であっても、未接続の外部機器を接続することによって可能となる利用法があれば、その旨を含めて利用法例を提案することも可能である。この場合には、自端末に接続可能な外部機器の種類に関する情報を予め設定しておく。そして、利用法提案部５３は、検知部として、前述の設定に従って自端末において未接続の外部機器を検知し、検知した未接続の外部機器を接続することによって可能となる利用法を判定する。同様に、通信相手となり得る他の通信端末５についても接続可能な外部機器の種類に関する情報を予め設定しておくようにしてもよい。この場合には、利用法提案部５３は、対象端末において未接続の外部機器を検知し、検知した未接続の外部機器を対象端末が接続することで可能となる利用法を判定する。

例えば、自端末において接続可能な外部機器の種類に関する情報が設定されている場合であって、図１１に示すように端末Ｂにおいて音声入力機能のみが異常の場合に、端末Ｂにおいて接続可能な外部機器としてマイクが設定されていたとする。仮に端末Ｂにマイクを接続し、音声入力機能が正常となれば、端末Ｂで実現可能な用途は、ビデオ会議、講演（講演者）、講演（聴講者）、および音声会議として特定されることとなる。結果、会議室Ａとの音声会議、および会議室Ａを聴講者とする講演の２つが可能な利用法として判定される。そこで、利用法提案部５３は、このような場合に、自端末において未接続のマイクを接続することによって会議室Ａとの音声会議、および会議室Ａを聴講者とする講演の２つが可能となる旨を可能な利用法例を示す情報とともに表示部に表示し、利用者に提案するようにしてもよい。

一方、対象端末において接続可能な外部機器の種類に関する情報が設定されている場合であって、図１１に示すように会議室Ａにおいて映像入力機能のみが異常の場合に、会議室Ａにおいて接続可能な外部機器としてカメラが設定されていたとする。仮に会議室Ａにカメラを接続し、映像入力機能が正常となれば、会議室Ａで実現可能な用途は、ビデオ会議、講演（講演者）、講演（聴講者）、および音声会議として特定されることとなる。結果、会議室Ａを講演者とする講演が可能な利用法として判定される。そこで、利用法提案部５３は、このような場合に、対象端末において未接続のカメラを接続することによって会議室Ａを講演者とする講演が可能となる旨を可能な利用法例を示す情報とともに表示部に表示し、利用者に提案するようにしてもよい。

なお、利用法提案部５３は、自端末において未接続の外部機器を接続することで可能となる利用法、および対象端末において未接続の外部機器を接続することで可能となる利用法の両方を判定するようにしてもよい。この場合には、両方について判定された可能となる利用法例を示す情報を、可能な利用法例を示す情報とともに表示部に表示すればよい。

これによれば、通信端末５において機器の状態が異常なのではなく、単に未接続である場合には、該当する機器が接続された場合の利用法例をも利用者に提案することができる。したがって、利用法例の提案の幅を広げることができる。

また、以上説明した利用法提案部５３が行う処理は、通信端末５ではなくサーバ３が行う構成としてもよい。この場合には、サーバ３は、判定した利用法を利用法例とし、対象端末に関するお知らせデータに利用法例を示す情報を含めて通信端末５に送信する。本変形例では、通信端末５は利用法提案部５３を備える必要がなく、サーバ３から対象端末に関するお知らせデータとして送信される表示画面データを表示部に表示するだけでよい。この場合において、サーバ３が通信端末５において未接続の外部機器を検知する場合には、通信端末毎に各通信端末が接続可能な外部機器の種類に関する情報を予め設定しておけばよい。

図１２は、通信システム１が利用者にお知らせを提示し、利用法例を提案するためのサーバ３および通信端末５の処理手順を示す図である。図１２に示すように、先ず、通信端末５が、お知らせの送信要求をサーバに通知する（ステップＳ４１）。

そして、サーバ３では、通信端末５からのお知らせの送信要求を受信すると（ステップＳ５１：Ｙｅｓ）、配信部３３が、該当する通信端末５についての配信設定に従い、管理ＤＢ７を参照して他端末情報を必要としない上記した利用者全体に向けて用意されるお知らせデータを取得するとともに（ステップＳ５３）、対象端末の診断結果データを取得する（ステップＳ５５）。

具体的には、ステップＳ５３では、配信部３３は、該当する通信端末５についての利用者に提示するお知らせの項目に関する設定に従い、管理ＤＢ７に蓄積されているお知らせデータの中から、配信データに含めるお知らせデータを抽出する。一方、ステップＳ５５では、配信部３３は、対象端末の設定に従い、管理ＤＢ７の端末別診断結果テーブルに蓄積されている対象端末の診断結果データを抽出する。また、この対象端末の診断結果データの抽出時において、配信部３３は、対象端末に関するお知らせデータを上記した要領で作成する。

なお、抽出する診断結果データは、対象端末の端末名が対応付けられたレコードの全部であってもよいし、その中から必要なもののみを抽出することとしてもよい。また、ステップＳ５３の処理とステップＳ５５の処理とは並行して行ってもよいし、ステップＳ５５の処理を先に、ステップＳ５３の処理を後に行う処理手順としてもよい。

そして、配信部３３は、ステップＳ５３で取得した利用者全体向けのお知らせデータとステップＳ５５で作成した対象端末に関するお知らせデータとをお知らせデータとし、ステップＳ５５で取得した対象端末の診断結果データとともに配信データとして該当する通信端末５に送信する（ステップＳ５７）。なお、ステップＳ５３で取得した利用者全体向けのお知らせデータについては、配信データに含めるにあたり特に加工する必要はない。

一方、通信端末５では、以上のようにしてサーバ３から送信された配信データのダウンロードを完了すると（ステップＳ４３：Ｙｅｓ）、利用法提案部５３が、現時点で可能な自端末の利用法を上記した要領で判定する（ステップＳ４５）。そして、利用法提案部５３は、ステップＳ４５で可能と判定した利用法を利用法例とし、お知らせとともに利用法例を示す情報を表示部に表示処理する（ステップＳ４７）。

ステップＳ４７では、利用法提案部５３は、対象端末に関するお知らせデータに利用法例を示す情報を追加した上で、利用者全体向けのお知らせデータとともにお知らせ画面やこのお知らせ画面から遷移可能な詳細画面を表示部に表示する。図１３は、お知らせ画面の一例を示す図である。お知らせ画面には、サーバ３からダウンロードしたお知らせデータ、すなわち、利用者全体に向けたお知らせデータや対象端末に関するお知らせデータ等を内容とするお知らせの件名が選択可能に並べて表示される。なお、図１３に示すお知らせ画面は一例であって、例えば対象端末に関するお知らせデータのみを表示させたり、あるいはこれを表示させないようにしてもよい。例えば、予めお知らせの表示のさせ方に関する表示設定を行っておくことで実現できる。この表示設定は、管理者が例えばサーバ３側で行う構成としてもよいし、利用者が通信端末５側で行う構成としてもよい。

このお知らせ画面においてお知らせの件名を選択操作すると、その詳細情報が表示される。例えば、最上段のファームウェアアップデートのお知らせＩ１１の詳細情報は利用者全体に向けたお知らせデータに相当し、このお知らせＩ１１をクリックすると、アップデートが可能なファームウェアについてアップデートの期日やアップデートの内容等が表示される。

一方、中段のお知らせＩ１３の詳細情報は、利用法例を示す情報が追加された対象端末に関するお知らせデータに相当する。図１４は、お知らせＩ１３をクリックした場合に表示される詳細画面例を示す図である。詳細画面には、対象端末である会議室Ａの故障機器やその故障日時、故障内容等が表示され、図１４では、会議室Ａにおいてカメラ故障が８／２２の１５：２４以降に発生したことを内容としている。また、この詳細画面には、併せて利用法例を示す情報が表示される。ここで、図１４に示す利用法例２は、未接続の外部機器を接続することで可能となる利用法例を示す情報であり、外部カメラの接続を要する旨が併せて明記されている。その他、詳細画面には、適宜管理者の連絡先等を含めてもよい。

以上説明したように、本実施の形態によれば、通信端末５で実施された自己診断の診断結果データをサーバ３において通信端末５毎に管理することができる。そして、サーバ３は、通信端末５からお知らせの送信要求が通知された際に、対象端末の診断結果データを配信データに含めて該当する通信端末５に送信することができる。一方、通信端末５では、サーバ３から送信された対象端末の診断結果データを用いて現時点で可能な自端末の利用法を判定し、可能な利用法を利用法例としてこの利用法例を示す情報を対象端末における機器の状態（診断結果データ）とともに表示部に表示することができる。よって、現時点での自端末の利用法例を利用者に提案することができる。これによれば、利用者が通信端末５の利用法を自分で考える必要がない。また、利用者が自ら考えたのでは利用法を思いつかない場合もあり、そのような場合であっても、自端末の利用法例を適切に利用者に提案することができる。加えて、対象端末の機器が異常なために当初予定していた用途で自端末を利用できない場合であっても、事前連絡を必要とせずにその旨を知ることができるので、管理者や利用者の手間とならない。したがって、他の通信端末との間で通信を行う通信端末の利用を支援し、利用者の利便性を向上させることができる。

例えば、通信システム１が適用されるビデオ会議システムにおいて、端末名が「端末Ｂ」の通信端末５を利用者Ｘが操作し、端末名が「会議室Ａ」の通信端末５との間でビデオ会議を行う場合であって、会議室Ａにおいてカメラが故障していた場合を考える。この場合、端末Ｂの利用者Ｘは会議室Ａの映像を見ることはできないが、従来のビデオ会議システムでは、利用者Ｘが会議室Ａのカメラ故障を事前に知るためには、会議室Ａの利用者や管理者がその旨を利用者Ｘに別途連絡する必要があった。これに対し、本実施の形態の通信システム１によれば、この別途必要であった連絡がなくても、図１３のお知らせ画面や図１４の詳細画面を閲覧することで、利用者Ｘは、始めから音声会議のつもりで会議に臨むことができる。あるいは、利用者Ｘは、会議室Ａの利用者に故障機器のない別の通信端末を使用してもらうように事前に依頼することができる。

なお、上記した実施の形態では、通信端末５は、起動時を実施タイミングとして自己診断を実施することとした。これに対し、自己診断の実施タイミングは、起動時以外のタイミングであってもよい。例えば、実施指示を管理者が手動で、あるいはサーバ３側からプログラムにより自動的に通信端末５に指示する構成としてもよい。この場合には、通信端末５は、サーバ３からの実施指示の通知に応答して自己診断を実施する。また、通信端末５において利用者による実施指示操作を受け付け、この実施指示操作に応じて自己診断を実施するようにしてもよい。

あるいは、予め起動時以外の別のタイミングを実施タイミングとして設定しておき、自己診断を実施することとしてもよい。例えば、配信データのダウンロードと並行して自己診断を実施することとしてもよい。図１５は、この場合の通信端末５の処理手順を示すフローチャートである。なお、図１５において、図１２と同様の処理工程には同一の符号を付して説明は省略する。

本変形例では、図１５に示すように、通信端末５は、お知らせの送信要求をサーバ３に通知する（ステップＳ４１）のと同時に、自己診断部５１が自己診断の実施を開始する（ステップＳ６１１）。なお、図１５ではサーバ３の処理手順は示していないが、サーバ３は、ステップＳ４１の通知に応答して図１２に示して説明したステップＳ５１〜ステップＳ５７の処理を行う。また、図１５のステップＳ６１１で開始する自己診断の実施は、図３に示した処理手順に従ってサーバ３および通信端末５が処理を行うことで実現できる。

その後、通信端末５は、ステップＳ６１１で開始した自己診断の実施を完了し、配信データのダウンロードを完了するとまで待機する（ステップＳ６１３：Ｎｏ）。そして、これらを完了すると（ステップＳ６１３：Ｙｅｓ）、ステップＳ４５に移行する。本変形例では、ステップＳ４５において利用法提案部５３が可能な利用法を判定する際、直前に実施した自端末の自己診断結果に応じた利用法例の提案が可能となる。

また、通信端末５からサーバ３への配信データの配信タイミング、およびお知らせ画面や詳細画面等の表示タイミングについても、自己診断の実施タイミングと同様に適宜設定あるいは指示する構成としてよい。

また、上記した実施の形態では、自端末の診断結果データと併せて対象端末の診断結果データを用いることで自端末において可能な利用法を判定し、利用法例を提案する場合について説明した。これに対し、自端末の診断結果データのみから判定できる自端末単独で可能な利用法を判定し、利用法例として提案するようにしてもよい。例えば、通信不良等によって通信回線Ｎを介した通信が行えず、対象端末の診断結果データをサーバ３からダウンロードできない場合等に適用できる。ただし、通信回線Ｎを介した通信が行える場合であっても、例えば通信端末５を自端末単独での用途で利用したい場合等もあり、そのような場合においても適用できる。

図１６は、この場合の通信端末５の処理手順を示すフローチャートである。図１６に示すように、通信端末５は、先ず、サーバ３との間で通信を確立するための処理を行い、通信回線Ｎを介した通信の可否を判定する（ステップＳ７１）。通信が確立でき、通信回線Ｎを介した通信が可能であれば、ステップＳ７３に移行して通信可能時処理を行う。この通信可能時処理は、例えば、図１５に示した処理である。

一方、サーバ３との間で通信が確立できず、通信回線Ｎを介した通信が不可の場合にはステップＳ７５に移行し、自己診断部５１が自己診断を実施する。図３に示した処理手順に従ってサーバ３および通信端末５が処理を行うことで実現できる。

続いて、利用法提案部５３が、ステップＳ７５で実施した自己診断で得られた診断結果データを用い、現時点で自端末単独で可能な利用法を判定する（ステップＳ７７）。例えば、単独用途判定テーブルとして、自端末単独で行える用途に必須の機能が設定されたデータテーブルを予め記録部に記録しておく。そして、利用法提案部５３は、単独用途判定テーブルに従い、ステップＳ７５で得られた診断結果データから自端末で実現可能な用途を特定し、特定した用途を自端末単独で可能な利用法と判定する。

そして、利用法提案部５３は、ステップＳ７７で可能と判定した利用法を利用法例とし、お知らせとともに利用法例を示す情報を表示部に表示処理する（ステップＳ７９）。例えば、利用法提案部５３は、ステップＳ７５で得られた診断結果データを用いて自端末の自己診断結果を報知するための自端末に関するお知らせデータを作成する。自端末に関するお知らせデータは、自端末において異常の機器（故障機器）についてその原因（故障内容）や異常が発生した時期（故障日時）等を内容とする。そして、利用法提案部５３は、ステップＳ７７で可能と判定した利用法を利用法例とし、この利用法例を示す情報を自端末に関するお知らせデータに追加して表示画面データ（詳細画面）を作成して、表示部に表示する。

図１７は、本変形例における詳細画面の一例を示す図である。この場合の詳細画面には、自端末の故障機器やその故障日時、故障内容等とともに自端末単独での利用法例を示す情報が表示される。例えば、通信端末５としてビデオ会議端末を想定している場合、通信回線Ｎを介した通信が不可の場合にはビデオ会議を行うことはできない。このような場合であっても、図１７に示す映像録画のように、自端末において正常な機器あるいは機能の組合せによっては自端末単独で実現可能な用途も存在する。本変形例によれば、例えば通信回線Ｎを介した通信が行えず、サーバ３との通信が確立できずに対象端末の診断結果データが受信できない場合であっても、自端末が自端末単独で可能な利用法を判定し、利用法例として利用者に提案することができる。

また、上記した実施の形態では、通信端末５としてビデオ会議端末を想定し、通信システム１をビデオ会議システムに適用した場合について説明したが、適用対象はこれに限定されるものではなく、通信端末が有する機器の状態を通信端末毎に管理する場合に広く適用が可能である。

また、上記した実施の形態においてサーバ３が行うこととして説明した処理を通信端末５が行う構成としてもよいし、通信端末５が行うこととして説明した処理をサーバ３が行う構成としてもよい。また、上記した実施の形態において説明したサーバ３と通信端末５とが通信接続されるシステム構成は一例であり、用途や目的に応じて様々なシステム構成例があることは言うまでもない。例えば、通信システムを構成するサーバは複数台としてもよく、各サーバが行う処理の分担も特に限定されない。

ここで、以上説明した通信端末５を実現するためのハードウェア構成例について図１８を参照して説明する。図１８に示すように、通信端末５は、通信端末５全体の動作を制御するＣＰＵ（Central Processing Unit）１０１と、端末プログラム等の通信端末５を動作させるための各種プログラムを記録したＲＯＭ（Read Only Memory）１０２と、ＣＰＵ１０１のワークエリアとして使用されるＲＡＭ（Random Access Memory）１０３と、各種データを記録するフラッシュメモリ１０４と、ＣＰＵ１０１の制御に従ってフラッシュメモリ１０４に対する各種データの書き込みまたは読み出しを制御するＳＳＤ（Solid State Drive）１０５と、フラッシュメモリ等のメディア１０６に対するデータの書き込みまたは読み出しを制御するメディアドライブ１０７と、各種操作入力を行うための操作ボタン１０８と、通信端末５の電源のＯＮ／ＯＦＦを切り換えるための電源スイッチ１０９と、通信回線Ｎを介して外部（例えばサーバ３）との間でデータを送受するためのネットワークＩ／Ｆ（Interface）１１１とを備える。

また、通信端末５は、ＣＰＵ１０１の制御に従って被写体を撮像して画像データを得る内蔵型のカメラ１１２と、このカメラ１１２の駆動を制御する撮像素子Ｉ／Ｆ１１３と、音声を入力する内蔵型のマイク１１４と、音声を出力する内蔵型のスピーカー１１５と、ＣＰＵ１０１の制御に従ってマイク１１４およびスピーカー１１５との間で音声信号の入出力を処理する音声入出力Ｉ／Ｆ１１６と、ＣＰＵ１０１の制御に従って外付け（通信端末５に接続された）ディスプレイ１２０に画像データを伝送するディスプレイＩ／Ｆ１１７と、各種の外部機器を接続するための外部機器接続Ｉ／Ｆ１１８と、上記各構成要素を電気的に接続するためのアドレスバスやデータバス等のバスライン１１０とを備えている。

ディスプレイ１２０は、液晶や有機ＥＬによって構成された表示装置である。また、ディスプレイ１２０は、ケーブル１２０ｃによってディスプレイＩ／Ｆ１１７に接続される。このケーブル１２０ｃは、アナログＲＧＢ（ＶＧＡ）信号用のケーブルであってもよいし、コンポーネントビデオ用のケーブルであってもよいし、ＨＤＭＩ（High-Definition Multimedia Interface）やＤＶＩ（Digital Video Interactive）信号用のケーブルであってもよい。

カメラ１１２は、レンズや、光を電荷に変換して被写体の画像（映像）を電子化する固体撮像素子を含み、固体撮像素子として、ＣＭＯＳ（Complementary Metal Oxide Semiconductor）や、ＣＣＤ（Charge Coupled Device）等が用いられる。

外部機器接続Ｉ／Ｆ１１８には、ＵＳＢ（Universal Serial Bus）ケーブル等によって外部カメラ、外部マイク、外部スピーカー等の外部機器がそれぞれ電気的に接続可能である。

メディア１０６は、通信端末５に対して着脱自在な構成となっている。また、ＣＰＵ１０１の制御に従ってデータの書き込みまたは読み出しを行う不揮発性メモリであれば、フラッシュメモリ１０４に限らず、ＥＥＰＲＯＭ（Electrically Erasable and Programmable ROM）等を用いてもよい。

なお、図１８に示すハードウェア構成は一例であって、通信端末５が図１８に示す全ての構成を備えている必要はない。例えば、通信端末５に期待される機能においてカメラ１１２やマイク１１４等が不要であったとする。この場合には、通信端末５は、これらを除いたハードウェア構成としてよい。また、図１８では外付けのディスプレイ１２０を示したが、内蔵型のディスプレイを備えたハードウェア構成としてもよい。例えば、通信端末５は、ワークステーションやパソコン等の汎用コンピュータ、スマートフォン、タブレット型端末等を適宜利用することができる。

また、サーバ３のハードウェア構成については図示しないが、ＣＰＵ等の演算装置、主記録装置、サーバプログラム等のサーバ３を動作させるための各種プログラムを記録したＲＯＭ、ハードディスクや各種記録媒体等の記録装置、通信装置、表示装置や印刷装置等の出力装置、入力装置、各部を接続し、あるいは外部入力を接続するインターフェース装置等を備えた公知のハードウェア構成のコンピュータ等で実現できる。

また、前述のようなハードウェア構成のサーバ３や通信端末５が実行するサーバプログラムおよび端末プログラムは、インストール可能な形式または実行可能な形式のファイルでコンピュータによる読み取り可能な記録媒体（例えば通信端末５のメディア１０６）に記録されて提供される構成としてもよい。記録媒体としては、例えば、ＣＤ−ＲＯＭやフレキシブルディスク（ＦＤ）、ＣＤ−Ｒ、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ）等を用いることができる。あるいは、サーバプログラムおよび端末プログラムを、インターネット等の通信回線に接続されたコンピュータ上に格納し、通信回線を介してダウンロードさせることにより提供するように構成してもよい。また、サーバプログラムおよび端末プログラムを、インターネット等の通信回線を介して提供または配布するように構成してもよい。

ここで、端末プログラムは、図２に示した各機能部を含むモジュール構成となっており、ＣＰＵ１０１がＲＯＭ１０２から端末プログラムを読み出して実行することによって自己診断部５１や利用法提案部５３が主記憶装置上にロードされ、主記憶装置上に生成されるようになっている。

ただし、図２に示した各機能部をソフトウェア（サーバプログラムや端末プログラム）の実装により実現する場合に限らず、例えば、図２に示した各機能部の一部又は全部をハードウェアの実装により実現してもよい。

１ 通信システム
３ サーバ
３１ 管理部
３３ 配信部
５ 通信端末
５１ 自己診断部
５３ 利用法提案部
５５ 通信部
１０（１０−１，２） 機器
７ 管理ＤＢ
Ｎ 通信回線

特開２００３−３４８２４９号公報

Claims (8)

1. 通信回線を介して複数の通信端末が通信を行う通信システムであって、
   前記通信端末に内蔵される機器または前記通信端末と接続された機器の状態を診断する診断部と、
   診断結果データを前記通信端末毎に管理する管理部と、
   前記通信端末の診断結果データに基づいて、前記通信端末の利用法を判定する判定部と、
   前記判定部により判定された利用法に基づく情報を、前記通信端末に対して診断された機器の状態とともに表示部に表示処理する表示処理部と、
   を備えることを特徴とする通信システム。
2. 前記複数の通信端末には、第一の通信端末と、該第一の通信端末の通信相手となる第二の通信端末と、が少なくとも含まれ、
   前記判定部は、前記第一の通信端末が有する正常な機器によって実現可能な前記第一の通信端末の用途を特定するとともに、前記第二の通信端末が有する正常な機器によって実現可能な前記第二の通信端末の用途を特定し、前記第一の通信端末および前記第二の通信端末の各々で実現可能な用途の組合せから前記可能な利用法を判定することを特徴とする請求項１に記載の通信システム。
3. 前記複数の通信端末には、第一の通信端末と、該第一の通信端末の通信相手となる第二の通信端末と、が少なくとも含まれ、
   前記診断部による診断結果に基づいて、機能が同種の機器のうちの少なくとも１つが正常の場合に該機能を正常とし、機能が同種の機器の全てが異常の場合に該機能を異常として前記診断結果データを作成する作成部を備え、
   前記判定部は、前記第一の通信端末が有する正常な機能によって実現可能な前記第一の通信端末の用途を特定するとともに、前記第二の通信端末が有する正常な機能によって実現可能な前記第二の通信端末の用途を特定し、前記第一の通信端末および前記第二の通信端末の各々で実現可能な用途の組合せから前記可能な利用法を判定することを特徴とする請求項１に記載の通信システム。
4. 予め前記通信端末に接続可能として設定された外部機器の種類に基づいて、前記診断結果データに従って前記通信端末において未接続の外部機器を検知する検知部を備え、
   前記判定部は、前記検知部により検知された未接続の外部機器を接続することによって可能となる利用法を判定し、
   前記表示処理部は、前記判定部により可能と判定された利用法に基づく情報を表示する処理を行うことを特徴とする請求項１〜３のいずれか１項に記載の通信システム。
5. 通信端末毎の診断結果データを管理するサーバと通信回線を介して通信接続される通信端末であって、
   自端末に内蔵される機器または自端末と接続された機器の状態を診断する診断部と、
   前記診断部による診断結果データを前記サーバに送信する送信部と、
   前記サーバから送信された前記通信端末の診断結果データを受信する受信部と、
   前記診断部による診断結果データと、前記受信部により受信された前記通信端末の診断結果データとに基づいて、自端末の利用法を判定する判定部と、
   前記判定部により判定された利用法に基づく情報を、前記通信端末に対して診断された機器の状態とともに表示部に表示処理する表示処理部と、
   を備えることを特徴とする通信端末。
6. 前記判定部は、前記通信回線を介した通信が行えない場合に、前記診断部による診断結果データに基づいて自端末単独で可能な利用法を判定し、
   前記表示処理部は、前記判定部により判定された自端末単独で可能な利用法に基づく情報を、自端末に対して診断された機器の状態とともに表示部に表示処理することを特徴とする請求項５に記載の通信端末。
7. サーバで実行されるサーバプログラムと、通信端末とが通信回線を介して接続可能に構成された通信システムであって、
   前記サーバプログラムは、
   前記通信端末から送信された診断結果データを前記通信端末毎に管理する管理部、
   前記通信端末に対し、前記管理部によって管理される前記通信端末の診断結果データを配信する配信部、
   として前記サーバを機能させ、
   前記通信端末は、
   自端末に内蔵される機器または自端末と接続された機器の状態を診断する診断部と、
   前記診断部による診断結果データを前記サーバに送信する送信部と、
   前記サーバから送信された前記通信端末の診断結果データを受信する受信部と、
   前記診断部による診断結果データと、前記受信部により受信された前記通信端末の診断結果データとに基づいて、自端末の利用法を判定する判定部と、
   前記判定部により判定された利用法に基づく情報を、前記通信端末に対して診断された機器の状態とともに表示部に表示処理する表示処理部と、
   を備えることを特徴とする通信システム。
8. 通信端末毎の診断結果データを管理するサーバと通信回線を介して通信接続される通信端末を、
   自端末に内蔵される機器または自端末と接続された機器の状態を診断する診断部、
   前記診断部による診断結果データを通信回線を介して前記サーバに送信する送信部、
   前記サーバから送信された前記通信端末の診断結果データを受信する受信部、
   前記診断部による診断結果データと、前記受信部により受信された前記通信端末の診断結果データとに基づいて、自端末の利用法を判定する判定部、
   前記判定部により判定された利用法に基づく情報を、前記通信端末に対して診断された機器の状態とともに表示部に表示処理する表示処理部、
   として機能させることを特徴とする端末プログラム。

Images