JP4415751B2 - 情報通信装置 - Google Patents

Description

本発明は、パケット通信ネットワークにおいて、通信端末のネットワーク設定誤り、通信中継装置や通信相手装置の故障などの原因により通信障害が発生した場合に、通信端末自身が障害の発生箇所を特定する方法に関する。

近年、ＡＤＳＬやＦＴＴＨの普及に伴い、インターネットへのＰＣの常時接続環境が急速に普及している。この接続環境は利用者にとって便利なものであるが、通信障害が発生したときに、その原因の特定は難しい。通信障害の原因としては、例えば、ＰＣの設定誤り、家庭内ルータの設定誤り、ＰＣとルータのケーブル接続誤り、インターネット上（アクセス回線およびインターネット）の中継装置の故障など多岐にわたり様々である。

上記のような接続障害が発生したときには、利用者はＰＣ上で実行可能なｐｉｎｇなどのネットワークに関するコマンドを実行し、利用者自身で障害原因の特定を行わなければならない。さらには、単にｐｉｎｇだけで問題を解決できない場合もあり、そのときは他のコマンドを使い原因切り分けを行う。そのため、利用者はＯＳ、ネットワーク、ネットワークコマンドに関する専門的な知識が必要となる。

一方、サポートセンターに電話して原因特定の助けを求める場合においても、オペレータとの意思疎通のために基本的なネットワークの知識は必要であり、ＰＣの操作に習熟している必要がある。

また、専門的な知識に乏しい利用者（以後インターネットの接続に関する知識を十分に知らない利用者を「未熟達利用者」と呼ぶ）がネットワークコマンドを実行することによって、ＰＣのネットワーク設定を意図せず変更してしまう可能性がある。設定を変更してしまった場合には、障害切り分けがより複雑となり解決までの時間が長引くことがあった。

このように、現在のＰＣのインターネット接続においては、通信障害が発生したときに、障害を切り分けるのは困難である。

この問題を解決する手法として、試験制御手段を備え、対向する通信装置にループバック試験を行い、対向する通信装置から送り返された時間的に連続する複数のループバックデータの全てが送信データに一致する場合は、対向する通信装置は正常と判断し、そうでない場合は対向する通信装置に障害が発生したと判断する制御装置がある（特許文献１参照）。

このような方法により、通信障害が発生した場合に、対向する通信装置に障害が発生したのか、それとも通信ネットワークの障害であるのかを切り分けることができる。
特開２０００−１１５２８７号公報

しかしながら、このような従来の技術では、通信障害が対向する通信装置か通信ネットワークかを切り分けることを可能ではあるが、ネットワークの障害である場合に、ネットワーク上の障害機器を特定することはできない。

そのため、通信障害が発生したときに、ＯＳ・ネットワーク・ネットワークコマンドに関する専門知識に乏しい利用者自身が、適切に原因を特定し問題解決の対応を行うことは困難である。

本発明は、このような課題を解決するもので、ＯＳ・ネットワーク・ネットワークコマンドに関する専門知識に乏しい利用者自身でも、通信障害切り分けのための専用ボタンや選択形式のメニューを設けることによって意図しない設定変更を防止し、通信障害の原因を簡単かつ容易に障害を切り分け可能となる通信障害診断機能をそなえた情報通信装置を提供することを目的とする。

上記課題を解決するために、本発明は、本体からルータまでの疎通状態をチェックするルータチェック手段と、そのルータチェック手段を起動するチェック起動手段と、ルータチェック手段の結果を表示するチェック結果表示手段を有する。これによって、未熟達利用者であっても通信パス上のどこまでが正しく接続できているかを認識することができる。結果、未熟達利用者であっても通信障害の原因を把握しやすいという効果がある。

本発明の情報通信装置は、未熟達利用者であっても、１のチェック起動手段を操作することで、インターネットへの接続の段階を知ることができ、接続に障害が生じた際に安心して対応できるという効果がある。

（実施の形態１）
以下、本発明の実施の形態の一例について、図面を参照しながら説明する。

（構成の説明）図１に本発明の構成を示す。情報通信装置１００は、通信手段を有するテレビである。従って、放送波を受けるアンテナ９０、受信した放送波を復調するＦＥ（フロントエンド）９２、復調された放送波をデコードして映像・音声信号を取り出すデコーダ９４およびディスプレイ画面および音声再生手段を含む表示部１１０を有する。

これらを制御するとともに通信チェック手段を制御する制御部１２０、インターネットとの物理的な接続を行うイーサーネットコントローラ１５０を有する。

さらに入力部１４０は、制御部１２０を通じて通信チェック手段を起動する。また、工場出荷の際に、決められたテストサーバのＩＰアドレスを記憶しておくメモリ部１３０を有している。

入力部１４０は、情報通信装置１００の前面、側面、背面などに設けられたスイッチ、リモコンからの信号、表示画面１１０上で参照できるソフトスイッチなどでもよい。これらの具体例を図４、図５、図６に示す。

図４は情報通信装置１００の前面に起動ボタン１１３が「通信テスト」１１２の表示とともに設置されている。

図５はリモコン１４２に、「通信テスト」１４２ａと起動ボタン１４２ｂが設置されている状態を示している。

また、図６には、表示部１１０上でのソフトスイッチを示している。表示画面１１１上にメニュー１１１ａを表示させるのは、リモコンなどの指示による。メニュー１１１ａ中のネットワーク設定というメニューの中に、各種テストがあることを示している。これらのテストはそれぞれ単独で行うこともできるが、「通信テスト」１１１ｃのスイッチで順にテストを行い、その結果を表示させることができる。

本発明の情報通信装置１００はインターネットと接続するために、ホームルータ３００と接続される。ホームルータ３００は、ＤＨＣＰ（Ｄｙｎａｍｉｃ Ｈｏｓｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）サーバ機能およびＮＡＴ（Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ Ｔｒａｎｓｌａｔｉｏｎ）機能を有していることが望ましいが、ユーザー宅内のネットワーク（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）とユーザー宅外のインターネット（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）の間をつなぐ機能、すなわちＩＰ層でパケット中継する機能を有していればよい。

ホームルータ３００と本発明の情報通信装置１００との間にはハブ２００があってもよい。ハブ２００は、ホームルータ３００に複数の通信機器を接続させる際に利用されるもので、ハブ２００は、スター型接続で双方向通信が可能な中継器である。特にホームルータ３００に本発明の情報通信装置１００とパーソナルコンピューターを接続する際に必要となる。

ホームルータ３００は通常電話の差込口に接続され、宅外のネットワークと接続されることになる。宅外のネットワークとはインターネットを意味し、インターネット網上にはＤＮＳ（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｅｒｖｉｃｅ）サーバ４００やテストサーバ６００、および接続する目的先のＷｅｂサーバ５００がある。

（動作の説明）以上のような構成を有する本発明の動作について図１および図２を用いて説明する。本発明は、未熟達利用者がインターネットへの接続に失敗した場合に起動される。すなわち、未熟達利用者は図１のように結線を行ったにもかかわらず、接続に失敗したということである。

まず、未熟達利用者は入力部１４０を通信チェック手段起動部として通信チェック手段を起動する。通信チェック手段は制御部１２０が通信チェックソフトウェアを読み込んで実行することで実現される（図２のＳｔｅｐ１０００）。

次に制御部１２０はイーサーネットコントローラ１５０にハブ２００との接続を指示する。イーサーネットコンとローラ１５０は、ハブ２００との通信を試みる（Ｓｔｅｐ１１００）。ハブ２００との間は電気的に結合されているので、物理的な電気信号のやり取りで接続状態を確認できる。情報通信装置１００は、一定時間回答がない場合はハブ２００との接続が良好でないと判断し、Ｓｔｅｐ１３００へ制御を移す。

Ｓｔｅｐ１３００では、ハブ２００との接続が失敗した旨の表示を行い、チェック手段を終了する（Ｓｔｅｐ２２００へ）。

図７にハブ２００との接続が失敗した場合の表示部１１０の表示状態を例示する。

Ｓｔｅｐ１１００へ戻って、ハブ２００との接続に成功した場合は、ホームルータ確認に移る（Ｓｔｅｐ１２００）。

図３にＳｔｅｐ１２００をより詳細にしたフローを示す。ホームルータ３００との接続では、まずメモリ１３０からホームルータのＩＰアドレスを取得する（Ｓｔｅｐ１２１２）。なお、ホームルータ３００のＩＰアドレスは利用者が予め情報通信装置１００に設定しておくか、ＤＨＣＰで取得したデフォルトルータアドレスを用いる。

次にホームルータ３００に対してｐｉｎｇを送る（Ｓｔｅｐ１２１３）。このｐｉｎｇに対して応答がきた場合は、接続成功と表示し（Ｓｔｅｐ１２１５）、Ｓｔｅｐ１４００へ処理を移す。一方ｐｉｎｇの応答がない場合は、Ｓｔｅｐ１５００へ処理を移す。

図２に戻って、Ｓｔｅｐ１５００では、ホームルータ３００との接続に失敗した旨の表示を行い、チェック手段を終了する（Ｓｔｅｐ２２００へ）。

ホームルータ３００は、利用者の家庭内のネットワークと、利用者の家庭の外にあるインターネットをつなぐ接続部になるため、ホームルータまでの接続の可否は、接続時の故障原因を考察するために重要である。

すなわち、ホームルータ３００までの接続が確認されている場合は、利用者がチェックを行える箇所は、ホームルータ３００から電話差込口までの接続線の導通程度しかない。後はインターネットとの接続の問題であるため、インターネットを管理する業者に連絡をとるしかない。

一方、ホームルータ３００までの接続が確認されていない場合は、情報通信装置１００からホームルータ３００までの接続や設定に問題があることがわかる。従って、利用者はホームルータ３００までの結線状態や、ホームルータ３００のＩＰアドレスの設定に誤りがないかどうかを確認しなければならない。

Ｓｔｅｐ１４００では、テストサーバ６００との接続を確認する。テストサーバとは、インターネット上で業者が運営する接続を確認するためのサーバである。テストサーバのアドレスは、予め工場出荷時にＤＮＳサーバを介することなくアクセス可能なＩＰアドレスの形態でメモリ部１３０に記録されている。制御部１２０は、予め工場出荷時にメモリ部１３０に記録されているテストサーバ６００のＩＰアドレスを用いて、テストサーバ６００との接続を確かめる。具体的にはＳｔｅｐ１２００の内容と同様、ｐｉｎｇを打つ。このｐｉｎｇに応答があれば次のＳｔｅｐ１６００に処理を移すが、接続に失敗するとＳｔｅｐ１７００に移り、テストサーバと接続が失敗した旨の表示を行う。その後チェック手段を終了する（Ｓｔｅｐ２２００）。

Ｓｔｅｐ１６００では、ＤＮＳサーバ４００との接続をチェックする。ＤＮＳサーバのＩＰアドレスは通常ホームルータ３００が情報通信装置１００へＩＰアドレスを通知する際に同時に通知する。従って情報通信装置１００がメモリ部１３０などへ予めもつ必要はない。また、ＤＮＳサーバは情報通信装置１００がドメインネームでインターネット上のホームページなどを指定する際に、ドメインネームをＩＰアドレスへ変換するサービスを行ってくれるサーバである。従って、このサーバとの接続を確認するのも重要である。具体的なチェック方法はＳｔｅｐ１２００と同じでよく、ｐｉｎｇを送信し、それに対する応答を確認することでチェックできる。

応答がなく、一定時間経過後は接続がないと判断し、Ｓｔｅｐ１９００へ処理を移す。Ｓｔｅｐ１９００では、ＤＮＳサーバと接続できていない旨の表示を行い、その後チェック手段を終了する（Ｓｔｅｐ２２００）。

なお、ホームルータではＮＡＴ機能を使うことが多い。この場合一般には、インターネットサービスプロバイダが指定するＤＮＳサーバ（以下、ＩＳＰ指定ＤＮＳサーバと記す）のアドレスをホームルータが自動的に取得するか、手動で設定することが多い。端末に対してはホームルータがＤＨＣＰサーバとなり、自動的にＤＮＳサーバ（以下、ルータ指定ＤＮＳサーバと記す）のアドレスを設定するが、このＤＮＳサーバのアドレスはホームルータのＬＡＮ側アドレス、すなわちＮＡＴの内側のプライベートアドレスであることが多い。この場合、ＩＳＰ指定ＤＮＳサーバは端末から知り得ることができないため、ホームルータよりＩＳＰ指定ＤＮＳサーバのＩＰアドレスを取得して、当該取得したＩＳＰ指定ＩＰアドレスをＤＮＳサーバのＩＰアドレスとして通信状態をチェックするとよい。

ここで、装置本体にホームルータ３００へＩＳＰ指定ＤＮＳサーバアドレスを問い合わせる手段をさらに設け、ホームルータ３００には問い合わせがあった場合にＩＳＰ指定ＤＮＳサーバアドレスを返信する手段を追加しておけばよい。これらの手段は、例えば問い合わせに係るコマンドを設定しておけば容易に実現できる。これによって、ホームルータ３００がＮＡＴ機能を有する場合にもＩＳＰ指定ＤＮＳサーバアドレスを知ることができ、通信確認を実行できる。

Ｓｔｅｐ１８００では、Ｗｅｂサーバ５００との接続状態を確認する。Ｗｅｂサーバ５００は所定のホームページで、そのＵＲＬは予めメモリ部１３０に書き込んである。しかし、利用者の好みに応じて指定できるのはいうまでもない。Ｗｅｂサーバ５００と接続が成功すれば、利用者の要求は満たされたことになるので、接続が成功した旨を表示し（Ｓｔｅｐ２０００）、チェック手段を終了する（Ｓｔｅｐ２２００）。

一方、Ｗｅｂサーバ５００との接続に失敗した場合は、Ｓｔｅｐ２１００へ処理を移し、Ｗｅｂサーバとの接続を失敗した旨の表示を行い、その後チェック手段を終了する（Ｓｔｅｐ２２００）。

チェック結果の表示としては、図７に示したようにチェックを行って、確認できたポイントまでの結果だけを示す方法以外に次のような表示を行ってもよい。なお、通信可能であることを確認すべきポイントを「接続中継点」と呼ぶ。

図８は、ホームルータ３００までの疎通は確認できたものの、テストサーバ６００との通信が確認できなかった旨の表示を示す。この場合利用者は、ホームルータ３００と電話差込口までの接続ラインの切断や、コネクタの接触不良などを確認したら、後はインターネット網を管理する業者に連絡を取る程度しか対応策はない。

図９にはよりビジュアル化した結果表示を示す。表示部１１１には、情報通信装置１００からテストサーバ６００までのパスが示してあり、どこまでの接続中継点の通信を確認したかが視覚的に理解できるようになっている。図９では、図８の結果と同じ結果を表示したものである。接続中継点のシンボルがそれぞれ示してある。斜線部分のシンボルが通信を確認できた接続中継点を示す。このような表示であると、未熟達利用者にもどこまで通信ができているかがわかる。それにより、みずからチェックできる範囲なのかどうかを判断でき、安心感を得ることができる。

また、接続の失敗について相談を受ける業者も、画面上でどこまで通信が可能になっているかという情報を未熟達利用者から聞き出すことによって、より迅速な対応が可能となる。

なお、図９では斜線によって通信の確認を示したが、ハイライト表示、太枠表示など通信を確認できなかった部分と差別化し見やすくした強調表示であればよい。

また、本実施の形態では、ハブ２００は、情報通信装置１００からの問い合わせに応答できる機能を有するような場合を示した。しかし、ハブ２００にはそのような機能が付加されていないものもある。そのため、画面に表示する接続中継点のシンボルに、ハブ２００を表示させないようにしてもよい。

また、本実施の形態では、情報通信装置１００とホームルータ３００の間にハブ２００が存在する場合を示したが、情報通信装置１００とホームルータ３００を直接接続してもよい。

また、結果の表示の際に、音を出すようにしてもよい。このときに接続中継点毎に音色や音階を変え、接続中継点毎のユニークな音を決めておくとよい。すなわち、ハブ２００までの通信が確認できたら「ド」の音、ホームルータ３００までの通信が確認できたら「レ」の音を出すなどである。具体的には、図１の制御部１２０が結果を表示部１１０に出力する際に音声再生手段によってその音を出力する。このようにすることで、電話等で業者に、接続できない場合の相談を行っている際、業者は電話を通じて結果を音で知ることができ、未熟達利用者に対するサポートが便利になる。

さらにチェック結果の表示としては、図１０に示したように、チェックを行って確認できなかったポイントについて接続に失敗した推定原因あるいは対処方法を表示するとよい。

図１０においては、上記の一例としてハブまでは接続が確認できたがホームルータ３００の接続が確認できなかった場合を示している。図９と同様に斜線部分のシンボルが通信を確認できた接続中継点を示している。そしてこの場合はホームルータ３００の接続が確認できなかったので、他の接続中継点のシンボルと異なる表示をしている。

そして、ホームルータ３００の接続が確認できなかった推定原因あるいは対処方法として、「ルータの電源を確認してください」、「ケーブルが抜けていないか確認してください」、「ケーブルが断線していませんか」、「ルータが故障している可能性があります」といった内容を、どの接続中継点の通信が確認できなかったかと同時に表示するようにしている。

なお、それぞれの接続中継点で接続を失敗する推定原因としては次のようなものが想定される。ハブとの接続確認に失敗した場合は、ハブの電源がＯＦＦになっている、ハブ自体の故障、ケーブル抜けあるいはケーブル断線が考えられる。ホームルータへのｐｉｎｇに正常な応答がない場合は、ルータの電源がＯＦＦになっている、ルータ自体の故障、ケーブル抜けあるいはケーブル断線が考えられる。テストサーバへのｐｉｎｇに正常な応答がない場合は、ルータの設定ミス、ＡＤＳＬ／ＦＴＴＨ／ＣＡＴＶ回線の異常あるいはインターネットプロバイダ網の異常が考えられる。ＤＮＳサーバへの名前解決の問い合わせに対して応答がない場合は、ＤＮＳサーバのダウンあるいはルータの設定ミスが考えられる。ＤＮＳサーバで名前を解決できなかった場合は、指定したＵＲＬが間違っていることが考えられる。そして上記の全ての接続のチェックに成功していながら所望のＷＥＢサーバへ接続できなかった場合は、ＷＥＢサーバがダウンしていることが考えられる。

以上のような推定原因あるいは対処方法を予め装置内に記憶しておき、それを接続に失敗した接続中継点に対応して表示することで、未熟達利用者であっても自らの能力の範疇の対処であれば自ら対応できるようになる。

（実施の形態２）
本発明にかかる情報通信装置１００においてはレイトコリジョンに関する通信障害の検出を追加することができる。その実施の形態の一例を以下に述べる。なお本実施の形態では、その構成は図１に示すとおりであり、実施の形態１と同様のためその説明は省略し、特徴的な動作を説明するとする。

レイトコリジョンとは、対向する通信機器の設定が、一方が半二重、他方が全二重のときに半二重側で発生する送信データの衝突で、イーサネット(登録商標)の規格違反となるものである。不安定ながらも通信はできてしまうので、切り分けが難しい部類の障害である。その原因として、ハブは通常半二重に設定されているが、ユーザーが情報通信装置１００を全二重に設定すると、この状況が起こる。

イーサネット(登録商標)の半二重通信ではメディアアクセス制御方式としてＣＳＭＡ／ＣＤを採用している。この方式では、複数の端末が同時にデータ送信を開始することがあり得るため衝突が発生することがあるが、この衝突は正常な衝突であり、再送信によって通信は保障される。

ところが、１０ＢＡＳＥ−Ｔや１００ＢＡＳＥ−ＴＸではツイストペアケーブルを用いて全二重通信が可能であるため、各端末の通信設定によっては半二重端末と全二重端末が通信するという異常な状態が発生する可能性がある。この状況下では、半二重端末が送信中でも全二重端末は送信を行ってしまうため、レイトコリジョンが発生してしまう。この場合も衝突が発生するが、異常な衝突であり通信は保障されないため、このような状況は回避しなければならない。

一般に正規の衝突のコリジョンの検出は、送信中のデータと送信中に監視している受信しているデータとが異なる場合に衝突と判断している。そこで本発明に係る情報通信装置では接続のチェックをするとともに、ダミーデータを送信して、送信中のダミーデータとハブあるいはホームルータ３００を経由して受信しているデータを監視する。両データが異なる場合に衝突が発生しているものとし、この衝突が、送信開始からの一定時間内に起こった場合は正規の衝突（コリジョン）と判断する。一方、一定時間を超えて衝突が起こった場合は、異常な衝突（レイトコリジョン）と判断する。ここで上記の一定時間とは、イーサネット(登録商標)規格で規定されている５１２ビット時間である。

以上のようにしてレイトコリジョンの発生を検出した場合は、図１１に示すように装置本体からハブあるいはホームルータ３００までの間で通信障害が発生している旨を表示する。さらにその対処方法として通信モードを切替えればよい旨を表示する。

このようにすることで、各接続中継点の接続が可能であっても通信が不安定になったり通信が阻害されたりする状態も検出され、さらにその対処方法も表示されるので、たとえ未熟達利用者であっても自らの能力の範疇の対処であれば自ら対応できるようになる。

なお、通信モードが本体装置で自動的に切り換えられるように構成し、レイトコリジョンが発生した場合は、本発明の情報通信装置が半二重のときは全二重に、全二重のときは半二重に通信モード自動的に切替えることにより、レイトコリジョンを回避するようにしてもよい。この場合は、レイトコリジョンを検出したことや通信モードを切替えたことをユーザーに通知し、履歴を残すようにするとよい。

（実施の形態３）
上記の実施の形態においてＤＮＳサーバまでの全ての接続のチェックに成功していながら所望のＷＥＢサーバへ接続できなかった場合は、ＷＥＢサーバがダウンしていることが考えられるが、本発明にかかる情報通信装置においては、さらに接続に失敗している原因を切り分けることができる。その実施の形態の一例を以下に述べる。なお本実施の形態では、その構成は図１に示すとおりであり、実施の形態１と同様のためその説明は省略し、特徴的な動作を説明するとする。

Ｗｅｂサーバ５００では、端末の地域情報（郵便番号）や端末時刻などの端末情報を利用してサービスを行うことが予測される。そのため、図１２に示す本発明の情報通信装置の動作において、ＤＮＳサーバ４００までの全ての接続のチェックに成功していながら所望のＷＥＢサーバ５００へ接続できなかった場合に端末情報をチェックするステップを追加する。

図１２においてＳｔｅｐ１０００〜２２００は図２の実施の形態１と同様であるので説明を省略する。同図においてＳｔｅｐ３０００がテストサーバによる端末情報の確認に係るステップである。このＳｔｅｐ３０００の詳細を図１３に示し、本実施の形態における動作を説明する。

通信のチェックがスタートし、ハブの接続を確認し（Ｓｔｅｐ１１００）、ホームルータへのｐｉｎｇが正常に応答するか確認し（Ｓｔｅｐ１２００）、テストサーバ６００へのｐｉｎｇが正常に応答するか確認し（Ｓｔｅｐ１４００）、ＤＮＳサーバ４００への名前解決の問い合わせに対して応答があるか確認し（Ｓｔｅｐ１６００）、それで所望のＷＥＢサーバ５００へ接続の確認（Ｓｔｅｐ１８００）において失敗した場合に、図１３のＳｔｅｐ３１１０へ移る。

まず、情報通信装置１００は、ＨＴＴＰリクエスト（ＰＯＳＴメソッド）の中に端末情報（郵便番号や端末時刻）を含めてテストサーバ６００に送信する（Ｓｔｅｐ３１１０）。テストサーバ６００は、端末から送信されたＨＴＴＰリクエストを受信し、ＨＴＴＰヘッダに含まれるバージョン情報やヘッダフィールドから、Ｗｅｂサーバ５００に適したプロトコルかどうかを解析する（Ｓｔｅｐ３１１１）。ここでＷｅｂサーバ５００に適したプロトコルでないと判断した場合は（Ｓｔｅｐ３１１２）、情報通信装置１００の通信ソフトウェアが最新ではなく、アップデート（更新）の必要があることを通知する（Ｓｔｅｐ３１１６）。

Ｗｅｂサーバ５００に適したプロトコルであると判断した場合は、テストサーバ６００は、端末から送信された端末情報、本実施の形態では郵便番号や端末時刻が有効な値であるかどうかを判断する（Ｓｔｅｐ３１１３）。ここで郵便番号や端末時刻が有効な値でないと判断したときは（Ｓｔｅｐ３１１４）、端末情報の郵便番号や時刻を正しく設定する必要があることを通知する（Ｓｔｅｐ３１１８）。

ここで、テストサーバ６００の端末情報が有効であるかどうかの判断の具体例として、まず郵便番号については、情報通信装置１００から送信されてきた７桁の郵便番号を、サーバが保持している郵便番号一覧を記載したテーブルと照合すればよい。Ｗｅｂサーバ５００が地域情報として郵便番号を要求しているのに対し、郵便番号が設定されていない、あるいは誤って設定されているために無効な番号となっていないか判断できる。

あるいは郵便番号が設定されていないような状況については上位３桁でも判断できる。この場合は、情報通信装置１００から送信されてきた上位３桁の郵便番号を、サーバが保持している郵便番号一覧を記載したテーブルと照合するようにすればよい。ある程度の地域の特定を可能にしつつ、郵便番号一覧のテーブル容量と照合処理に要するサーバのＣＰＵパワーを節約することが可能となる。

端末時刻については、情報通信装置１００から送信されてきた時刻と、サーバが保持している時刻を照合し、許容誤差範囲内（例えば±１０分）であるかどうかを判別する。

情報通信端末では、通信ソフトウェアが最新ではなく、アップデート（更新）の必要がある旨の通知を受けた場合は、通信ソフトの更新が必要である旨の表示を行う（Ｓｔｅｐ３１１７）。あるいは、端末情報の郵便番号や時刻を正しく設定する必要がある旨の通知を受けた場合は、その旨の表示を行う（Ｓｔｅｐ３１１９）。

図１４には、端末時刻が正しくない旨の通知を受けた場合の表示の一例を示す。同図において、このような表示を受けた未熟達利用者は本体の端末時刻を正しく設定しなおして再度Ｗｅｂサーバ５００との接続を試みることになる。

なお、本実施の形態において以下のような構成とすればテストサーバによる端末情報自動設定機能を追加することもできる。

端末情報に不備がある場合、日付などテストサーバで設定できる項目に限り、テストサーバから端末に対して単に端末情報が正しくない旨の通知をするだけでなく正しい値をＨＴＴＰレスポンスに含めて端末に送信するようにする。具体的には、ＨＴＴＰヘッダに専用のフィールド（Ｕｐｄａｔｅフィールド）を追加し、一例として次のような書式で更新すべき情報を記載する。

Ｕｐｄａｔｅ： ｄａｔｅ＝２００４／１／１， ｔｉｍｅ＝１２：１０：００
情報通信装置１００においては、上記の返信データを受信した場合は、ＨＴＴＰレスポンスに含まれた設定情報を抽出し、自動的に設定する。なお自動設定する場合は、自動設定することを通知するとよい。

なお、テストサーバ６００との送受信を予め端末に備えられたブラウザで実行することにより、Ｓｔｅｐ３１１７あるいはＳｔｅｐ３１１９における通知の表示や上記の自動設定の通知をＨＴＭＬで行うことができるようになる。

以上のように、プロトコルや端末情報等、アプリケーションレベルのテストをテストサーバで行うことにより、サービスを行うサーバのエラー処理の頻度を減らし、負担を軽減することができるとともに、Ｗｅｂサーバの接続に失敗している原因を切り分けることができる。

本発明にかかる情報通信装置は、パーソナルコンピューター、ディジタルテレビジョン受像機、その他ネットワークに接続される機器に適用できる。

本発明の情報通信装置の構成図 本発明の情報通信装置の通信チェック手段の動作を示すフローを示す図 図２のフローのうちの一部のフローをより詳細に示す図 テレビ自体に設けられた通信チェック起動用のスイッチを示す図 リモコンに設けられた通信チェック起動用のスイッチを示す図 ソフトスイッチを画面上で見た場合を示す図 結果表示の一例を示す図 結果の表示の一例で確認できなかった箇所の前までをも表示する場合を示す図 より視覚的にわかりやすいように結果を表示した図 チェック結果と推定原因あるいは対処方法を表示した図 通信障害の検査結果を表示した図 実施の形態３に係る情報通信装置の通信チェック手段の動作を示すフローを示す図 図１２のフローのうちの一部のフローをより詳細に示す図 実施の形態３に係るチェック結果を表示した図

符号の説明

１００ 情報通信装置
１１０ 表示部
１２０ 制御部
１３０ メモリ部
１４０ 入力部
１５０ イーサーネットコントローラ
２００ ハブ
３００ ホームルータ
４００ ＤＮＳサーバ
５００ Ｗｅｂサーバ
６００ テストサーバ

Claims (7)

1. 本体からルータまでの疎通状態をチェックするルータチェック手段と、前記ルータチェック手段を起動するチェック起動手段と、
   前記ルータチェック手段の結果を表示するチェック結果表示手段と、
   インターネット上に少なくとも通信確認のコマンドに対し返信する機能を有する、インターネット上での接続を確認するためのテストサーバが設けられており、前記テストサーバのＩＰアドレスを記録するＩＰアドレス記録手段と、
   前記テストサーバとの通信状態をチェックするテストサーバチェック手段をさらに有し、前記チェック起動手段は前記テストサーバチェック手段をさらに起動し、前記チェック結果表示手段は、前記テストサーバチェック手段の結果をさらに表示し、
   さらに、前記テストサーバのアドレスを、ＤＮＳサーバを介することなくアクセス可能なＩＰアドレスの形態で、予め前記ＩＰアドレス記録手段に記録し、
   さらに、前記ＤＮＳサーバと通信可能であり且つＷｅｂサーバとの通信に失敗した場合には、前記テストサーバに端末情報を送信し、前記テストサーバから送信した前記端末情報が有効な値であるかどうかの判定結果を得ることを特徴とする情報通信装置。
2. ＤＮＳサーバのＩＰアドレスを記録するＩＰアドレス記録手段と、ＤＮＳサーバとの通信状態をチェックするＤＮＳサーバチェック手段をさらに有し、前記チェック起動手段は前記ＤＮＳサーバチェック手段をさらに起動し、前記チェック結果表示手段は、前記ＤＮＳサーバチェック手段の結果をさらに表示することを特徴とする請求項１に記載の情報通信装置。
3. 前記ルータがＮＡＴ機能を有する場合には、インターネットサービスプロバイダが指定するＤＮＳサーバのＩＰアドレスを前記ルータより取得して、当該取得したＩＰアドレスを前記ＤＮＳサーバのＩＰアドレスとして通信状態をチェックすることを特徴とする請求項２に記載の情報通信装置。
4. 前記テストサーバの通信状態のチェックは、少なくとも本体からルータまでの疎通状態のチェックの後であり、かつＤＮＳサーバとの通信状態のチェックの前に行われることを特徴とする請求項３に記載の情報通信装置。
5. 前記チェック結果表示手段は、チェックする接続中継点のシンボルを表示し、通信可能である前記接続中継点までを強調的に表示することを特徴とする請求項１乃至４に記載の情報通信装置。
6. 前記チェック結果表示手段が、通信ができなかった前記接続中継点における接続に失敗した推定原因あるいは対処方法をさらに表示することを特徴とする請求項５に記載の情報通信装置。
7. 前記チェック結果表示手段は、チェックする接続中継点ごとに決められたユニークな音を通信可能である接続中継点まで順に出力してゆくことを特徴とする請求項１乃至４に記載の情報通信装置。
   
   

Images