JP2005197803A - 端末装置、サーバ装置および通信障害調査方法 - Google Patents

Abstract

【課題】無線通信システムにおいて通信障害が発生している箇所を容易に特定可能とする。
【解決手段】一の端末装置がサーバ装置２００との通信経路に障害が生じていないか否かを調査する通信障害調査方法は、端末通信部１０６からサーバ装置２００に対してデータを送信し、端末装置とアクセスポイントとの間、およびアクセスポイントとＬＡＮ経路を介してサーバ装置との間で各々通信可能であることを確認するステップと、端末装置からの要求に対してサーバ装置が応答することを確認するステップと、各ステップでの確認結果を端末装置の端末表示部１０７に表示するステップとを有する。また、サーバ応用プログラム２３０がサーバ基本プログラム２２０に対して応答を要求し、所定の時間内にサーバ基本プログラム２２０から応答が得られたか否かで障害を判定する。
【選択図】図９

Description

本発明は、サーバ装置と無線通信が可能な携帯端末等の端末装置を使用する無線通信システムにおける端末装置、サーバ装置および通信障害調査方法に関する。

携帯端末をホスト側と通信可能とし、ホスト側の親機と端末側の子機とをデータ通信させるシステムが利用されている。例えば、バーコードスキャナ付ハンディターミナルを用いて、倉庫での在庫管理データの収集、店頭での商品データの収集、宅配システムの出荷／集荷データ入力等に利用されている。ハンディターミナル等の端末装置がサーバ装置とデータ通信する方式としては、端末装置に無線通信機能を内蔵する方式と、専用通信ユニットにセットして一括送信するバッチ方式とがある。後者は、ハンディターミナルでデータを順次入力して保持した後、クレードル等の通信ユニットに載置して一括してデータをホスト側に送出する方式である。これに対して無線内蔵型はホスト側と通信可能な状態であり、一々通信ユニットにセットすることなく、入力されたデータをリアルタイムで端末装置からサーバ側に送出できる利点がある（例えば特許文献１）。

このような無線通信機能を備える端末を用いたシステムにおいては、何らかの原因で端末側の動作が遅くなる、あるいは動作不能となることがある。このような原因としては通信経路に何らかの障害が発生したことや、プログラムの不具合等がある。特に通信障害が原因として考えられる場合、まず障害の発生している場所を特定し、その後障害回復のための必要な作業を行う。従来、このような作業を行うには専門の知識を有する開発者がpingなどのネットワークコマンドを使って経験と推測で異常個所の特定を行っていた。言い換えると、通信の仕組みやコマンドの利用方法を熟知していなければ、このような通信障害の発生箇所を特定するのは困難であった。
特開２００３−６９４７４号公報

本発明は、このような問題点を解決するためになされたものである。本発明の主な目的は、専門知識が無くとも容易に通信障害の発生箇所を特定可能な端末装置、サーバ装置および通信障害調査方法を提供することにある。

上記目的を達成するために、本発明の請求項１に記載される端末装置は、端末装置１００がアクセスポイント及び／又はＬＡＮ経路を介してサーバ装置２００と接続された無線通信システムにおいて使用される端末装置であって、アクセスポイント及び／又はＬＡＮ経路を介してサーバ装置２００と無線通信可能な端末通信部１０６と、通信結果等を表示可能な端末表示部１０７とを備えており、前記端末装置１００とサーバ装置２００との通信経路に障害が生じていないか否かを調査するために、前記端末通信部１０６からサーバ装置２００に対してデータを送信し、端末装置１００とアクセスポイント及び／又はＬＡＮ経路を介したサーバ装置２００との間で通信可能であることを確認し、かつサーバ装置２００が端末装置１００からの要求に対して応答することを確認する端末経路調査機能を実行可能であり、前記端末経路調査機能を実行した結果を前記端末表示部１０７に表示可能に構成している。これにより、通信障害が発生しているかどうか、およびどの部分で問題が生じているかを容易に判別できるようになる。特に、通信の物理層を端末装置とアクセスポイント及び／又はＬＡＮ経路、およびサーバ装置に区別し、それぞれのインターフェースで通信が確立できているか否かを判別できるので、問題の発生している箇所がいずれであるかを示すことによって、必要な処置を講じることができる。

また、請求項２の端末装置は、端末装置１００がアクセスポイント及びＬＡＮ経路を介してサーバ装置２００と接続された無線通信システムにおいて使用される端末装置であって、アクセスポイント及び／又はＬＡＮ経路を介してサーバ装置２００と無線通信可能な端末通信部１０６と、通信結果等を表示可能な端末表示部１０７とを備えており、前記端末装置１００とサーバ装置２００との通信経路に障害が生じていないか否かを調査するために、前記端末通信部１０６からサーバ装置２００に対してデータを送信し、端末装置１００とアクセスポイントとの間、およびアクセスポイントとＬＡＮ経路を介してサーバ装置２００との間で各々通信可能であることを確認し、かつサーバ装置２００が端末装置１００からの要求に対して応答することを確認する端末経路調査機能を実行可能であり、前記端末経路調査機能を実行した結果を前記端末表示部１０７に表示可能に構成している。これにより、通信障害が発生しているかどうか、およびどの部分で問題が生じているかを容易に判別できるようになる。特に、通信の物理層を端末装置とアクセスポイント、ＬＡＮ経路、およびサーバ装置に区別し、それぞれのインターフェースで通信が確立できているか否かを判別できるので、問題の発生している箇所がいずれであるかを示すことによって、必要な処置を講じることができる。

さらに、請求項３の端末装置は、請求項１または２に記載の端末装置であって、端末経路調査機能を実行した結果を前記端末表示部１０７に表示した後、サーバ装置２００側から端末装置１００に対してデータを送信し通信障害を調査するサーバ経路調査機能を行うための通信待ち受け状態に移行可能に構成している。これにより、端末装置とアクセスポイント及び／又はＬＡＮ経路との通信が確立できていることが確認できた後、サーバ装置側からの通信経路に問題があるかどうかを確認する作業にスムーズに移行できる。

さらにまた、請求項４の端末装置は、請求項１から３のいずれかに記載の端末装置であって、前記端末経路調査機能が、各々のインターフェース間で通信が確立されたか否かに応じて個別の戻り値を記録する一以上の関数を実行し、戻り値に基づいて前記端末表示部１０７に表示されるメッセージを変化させて通信が正常であるか否かを表示可能に構成している。これにより、通信状態の確認を行う関数を予め用意することで通信の各物理層のインターフェース間で各々の通信状態を戻り値として記録でき、どの部位で問題が生じているかを特定することが容易となる。

さらにまた、請求項５の端末装置は、請求項４に記載の端末装置であって、前記端末経路調査機能が、通信が確立されたか否かの判定で通信失敗となったとき、通信の不通となっている箇所をユーザに通知する。これにより、通信失敗のエラーが記録された部位で問題が生じていると判別でき、ユーザは容易に問題発生箇所を特定できる。

また、請求項６のサーバ装置は、一以上の端末装置１００がアクセスポイント及び／又はＬＡＮ経路を介してサーバ装置２００と接続された無線通信システムにおいて使用されるサーバ装置であって、一以上の端末装置１００と無線通信可能なサーバ通信部２０６と、サーバ装置２００で実行されるプログラムとして、前記サーバ通信部２０６を介して端末装置１００とデータ通信するためのサーバ基本プログラム２２０と、用途に応じて編集可能なサーバ応用プログラム２３０とを実行可能なサーバ制御部２０４と、通信結果等を表示可能なサーバ表示部２０７とを備え、前記サーバ応用プログラム２３０がサーバ基本プログラム２２０とのプロセス通信に障害が生じていないか否かを調査するために、前記サーバ応用プログラム２３０がサーバ基本プログラム２２０に応答を要求し、要求に対して所定の時間内に応答が得られたか否かで障害を判定するサーバ経路調査機能を実行可能であり、前記サーバ経路調査機能を実行した結果を前記サーバ表示部２０７に表示可能に構成している。これにより、サーバ応用プログラムとサーバ基本プログラムとでプロセス通信が正しく確立されているか否かを判定できる。サーバプログラム２１０をサーバ基本プログラムとサーバ応用プログラムに分離し、両者間でプロセス通信を行う構成を採用することによって、サーバプログラム２１０の内、予め提供されたサーバ基本プログラムとユーザが作成したサーバ応用プログラムのいずれの部分で不具合が生じているかを容易に特定し易くできる。特に、一般にサーバ基本プログラムは設計段階で予め十分な動作確認がなされており、不具合の発生する確率が低いのに対し、ユーザが作成したサーバ応用プログラムはそのような検証が不十分なことがあり、問題の発生する確率が高いため、上記構成によってサーバ応用プログラムに問題があることが容易に特定できるようになる。

さらに、請求項７のサーバ装置は、請求項６に記載のサーバ装置であって、前記サーバ応用プログラム２３０がリクエストハンドラ２３２を含んでおり、前記サーバ基本プログラム２２０がリクエストマネージャ２２２を含んでおり、前記サーバ経路調査機能が実行されると、前記サーバ応用プログラム２３０がリクエストハンドラ２３２に対し、前記リクエストマネージャ２２２から反応を要求する命令を呼び出すとともに計時を開始し、リクエストマネージャ２２２から反応を受理するまでの時間を計測して、所定時間以上経過すると障害発生と判定する。これにより、リクエストハンドラをサーバ応用プログラムと別個の構成とすることで、ユーザが作成するサーバ応用プログラムに不具合があってもリクエストハンドラは機能するので、通信など最低限の処理を行うことができ、単にいずれかの不具合によりシステム全体がダウンするという状態から、最低限の運用を可能とすることができ、これによってどの部分で通信が確立できていないかを特定することも可能となる。

さらにまた、請求項８のサーバ装置は、請求項６または７に記載のサーバ装置であって、前記サーバ経路調査機能によってリクエストハンドラ２３２からリクエストマネージャ２２２に命令が実行されると、前記リクエストマネージャ２２２がサーバ基本プログラム２２０で端末装置１００にデータを送信することにより、アクセスポイント及び／又はＬＡＮ経路と端末装置１００との間の通信経路を調査可能に構成している。これにより、サーバ応用プログラムとサーバ基本プログラムとでプロセス通信が正しく確立されているか否かの調査に加え、端末装置との通信が確立されているか否かも併せて確認できる。

また、請求項９の通信障害調査方法は、一以上の端末装置１００がアクセスポイント及び／又はＬＡＮ経路を介してサーバ装置２００と接続された無線通信システムにおいて、一の端末装置１００がサーバ装置２００との通信経路に障害が生じていないか否かを調査する通信障害調査方法であって、前記端末通信部１０６からサーバ装置２００に対してデータを送信し、端末装置１００とアクセスポイントとの間、およびアクセスポイントとＬＡＮ経路を介してサーバ装置２００との間で各々通信可能であることを確認するステップと、端末装置１００からの要求に対してサーバ装置２００が応答することを確認するステップと、各ステップでの確認結果を端末装置１００の端末表示部１０７に表示するステップとを有する。これにより、通信障害が発生しているかどうか、およびどの部分で問題が生じているかを容易に判別できるようになる。特に、通信の物理層を端末装置とアクセスポイント、ＬＡＮ経路、およびサーバ装置に区別し、それぞれのインターフェースで通信が確立できているか否かを判別できるので、問題の発生している箇所がいずれであるかを示すことによって、必要な処置を講じることができる。

さらに、請求項１０の通信障害調査方法は、請求項９に記載の通信障害調査方法であって、さらに結果を端末表示部１０７に表示した後、サーバ装置２００側から端末装置１００に対してデータを送信し通信障害を調査するサーバ経路調査機能を行うための通信待ち受け状態に移行するステップを有する。これにより、端末装置とアクセスポイント及び／又はＬＡＮ経路との通信が確立できていることが確認できた後、サーバ装置側からの通信経路に問題があるかどうかを確認する作業にスムーズに移行できる。

さらにまた、請求項１１の通信障害調査方法は、一以上の端末装置１００がアクセスポイント及び／又はＬＡＮ経路を介してサーバ装置２００と接続された無線通信システムにおいて、一の端末装置１００がサーバ装置２００との通信経路に障害が生じていないか否かを調査する通信障害調査方法であって、調査結果を記録する調査結果データを初期化するステップと、前記端末通信部１０６からサーバ装置２００に対してデータを送信し、端末装置１００とアクセスポイントとの間で通信が可能か否かを判別して判定結果を調査結果データの該当する位置に記録するステップと、アクセスポイントとＬＡＮ経路を介してサーバ装置２００との間で通信が可能か否かを判別して判定結果を調査結果データの該当する位置に記録するステップと、サーバ装置２００で実行されるサーバプログラム２１０と通信が可能か否かを判別して判定結果を調査結果データの該当する位置に記録するステップと、調査結果データに記録された情報に従い、通信障害の結果を端末表示部１０７に表示するステップとを有する。これにより、通信障害が発生しているかどうか、およびどの部分で問題が生じているかを容易に判別できるようになる。特に、通信の物理層を端末装置とアクセスポイント及び／又はＬＡＮ経路、およびサーバ装置に区別し、それぞれのインターフェースで通信が確立できているか否かを判別できるので、問題の発生している箇所がいずれであるかを示すことによって、必要な処置を講じることができる。

また、請求項１２の通信障害調査方法は、一以上の端末装置１００がアクセスポイント及び／又はＬＡＮ経路を介してサーバ装置２００と接続された無線通信システムにおいて使用されるサーバ装置２００で実行されるサーバプログラム２１０を構成するサーバ応用プログラム２３０とサーバ基本プログラム２２０との間のプロセス通信に障害が生じていないか否かを調査する通信障害調査方法であって、前記サーバ応用プログラム２３０がサーバ基本プログラム２２０に対して応答を要求し、所定の時間内にサーバ基本プログラム２２０から応答が得られたか否かで障害を判定するステップと、判定結果をサーバ装置２００のサーバ表示部２０７に表示するステップとを有する。これにより、サーバ応用プログラムとサーバ基本プログラムとでプロセス通信が正しく確立されているか否かを判定できる。サーバプログラムをサーバ基本プログラムとサーバ応用プログラムに分離し、両者間でプロセス通信を行う構成を採用することによって、サーバプログラムの内、予め提供されたサーバ基本プログラムとユーザが作成したサーバ応用プログラムのいずれの部分で不具合が生じているかを容易に特定し易くできる。特に、一般にサーバ基本プログラムは設計段階で予め十分な動作確認がなされており、不具合の発生する確率が低いのに対し、ユーザが作成したサーバ応用プログラムはそのような検証が不十分なことがあり、問題の発生する確率が高いため、上記構成によってサーバ応用プログラムに問題があることが容易に特定できるようになる。

さらに、請求項１３の通信障害調査方法は、一以上の端末装置１００がアクセスポイント及び／又はＬＡＮ経路を介してサーバ装置２００と接続された無線通信システムにおいて使用されるサーバ装置２００で実行されるサーバプログラム２１０を構成するサーバ応用プログラム２３０とサーバ基本プログラム２２０との間のプロセス通信に障害が生じていないか否かを調査する通信障害調査方法であって、前記サーバ応用プログラム２３０に含まれるリクエストハンドラ２３２が、サーバ基本プログラム２２０に含まれるリクエストマネージャ２２２から反応を要求する命令を呼び出すステップと、前記命令が呼び出されたときから計時を開始するステップと、前記命令が要求する応答を所定の時間内にリクエストハンドラ２３２がリクエストマネージャ２２２から受け取ると計時を終了して正常と判定し、所定時間内に応答を受け取らない場合は異常と判定するステップと、判定結果をサーバ装置２００のサーバ表示部２０７に表示するステップとを有する。これにより、リクエストハンドラをサーバ応用プログラムと別個の構成とすることで、ユーザが作成するサーバ応用プログラムに不具合があってもリクエストハンドラは機能するので、通信など最低限の処理を行うことができ、単にいずれかの不具合によりシステム全体がダウンするという状態から、最低限の運用を可能とすることができ、これによってどの部分で通信が確立できていないかを特定することも可能となる。

さらにまた、請求項１４の通信障害調査方法は、一以上の端末装置１００がアクセスポイント及び／又はＬＡＮ経路を介してサーバ装置２００と接続された無線通信システムにおいて通信障害を調査する方法であって、通信障害を調査する通信経路に存在する任意の端末装置１００を通信の待ち受け状態とするステップと、前記サーバ装置２００で実行されるサーバプログラム２１０を構成するサーバ応用プログラム２３０とサーバ基本プログラム２２０との間のプロセス通信に障害が生じていないか否かを調査するために、前記サーバ応用プログラム２３０がサーバ基本プログラム２２０に対して応答を要求し、所定の時間内にサーバ基本プログラム２２０から応答が得られたか否かで障害を判定するステップと、サーバ基本プログラム２２０が端末装置１００に対して応答を要求し、所定の時間内に端末装置１００から応答が得られたか否かでサーバ装置２００と端末装置１００との間の通信障害を判定するステップと、判定結果をサーバ装置２００のサーバ表示部２０７に表示するステップとを有する。これにより、サーバ応用プログラムとサーバ基本プログラムとでプロセス通信が正しく確立されているか否かの調査に加え、端末装置との通信が確立されているか否かも併せて確認できる。

さらにまた、請求項１５の通信障害調査方法は、一以上の端末装置１００がアクセスポイント及び／又はＬＡＮ経路を介してサーバ装置２００と接続された無線通信システムにおいて使用されるサーバ装置２００で実行されるサーバプログラム２１０を構成するサーバ応用プログラム２３０とサーバ基本プログラム２２０との間のプロセス通信に障害が生じていないか否かを調査する通信障害調査方法であって、通信障害を調査する通信経路に存在する任意の端末装置１００を通信の待ち受け状態とするステップと、前記サーバ応用プログラム２３０に含まれるリクエストハンドラ２３２が、サーバ基本プログラム２２０に含まれるリクエストマネージャ２２２から反応を要求する命令を呼び出すステップと、前記命令が呼び出されたときから計時を開始するステップと、前記命令が要求する応答を所定の時間内にリクエストハンドラ２３２がリクエストマネージャ２２２から受け取ると計時を終了して正常と判定し、所定時間内に応答を受け取らない場合は異常と判定するステップと、リクエストマネージャ２２２がサーバ通信部を制御して端末装置１００に対して応答を要求し、所定の時間内に端末装置１００から応答が得られたか否かでサーバ装置２００と端末装置１００との間の通信障害を判定するステップと、判定結果をサーバ装置２００のサーバ表示部２０７に表示するステップとを有する。これにより、サーバ応用プログラムとサーバ基本プログラムとでプロセス通信が正しく確立されているか否かの調査に加え、端末装置との通信が確立されているか否かも併せて確認できる。

さらにまた、請求項１６の通信障害調査方法は、請求項１４または１５に記載の通信障害調査方法であって、端末装置１００の待ち受け時間を任意に設定可能としている。これにより、ユーザが待ち受けの時間を設定することで、通信環境や使用条件に応じてタイムアウトとなる時間を調整できる。

本発明の端末装置、サーバ装置および通信障害調査方法によれば、通信経路上の障害が発生している箇所を容易に特定できるようになる。特に、ネットワークの仕組みやネットワークコマンド、ログの解析といった専門知識を必要とすることなく、端末経路調査機能やサーバ経路調査機能などの通信障害調査機能を呼び出して実行するのみで、通信の物理層のいずれの部分で障害が発生しているか、あるいはサーバプログラムのサーバ基本プログラムとサーバ応用プログラムの間のプロセス間通信において不具合が生じているのかを特定することが可能となり、無線通信ネットワークシステムの運用においても初心者が扱い易い環境が実現される。

以下、本発明の実施の形態を図面に基づいて説明する。ただし、以下に示す実施の形態は、本発明の技術思想を具体化するための端末装置、サーバ装置および通信障害調査方法を例示するものであって、本発明は端末装置、サーバ装置および通信障害調査方法を以下のものに特定しない。

また、本明細書は特許請求の範囲に示される部材を、実施の形態の部材に特定するものでは決してない。特に実施の形態に記載されている構成部品の寸法、材質、形状、その相対的配置等は特に特定的な記載がない限りは、本発明の範囲をそれのみに限定する趣旨ではなく、単なる説明例にすぎない。なお、各図面が示す部材の大きさや位置関係等は、説明を明確にするため誇張していることがある。さらに以下の説明において、同一の名称、符号については同一もしくは同質の部材を示しており、詳細説明を適宜省略する。さらに、本発明を構成する各要素は、複数の要素を同一の部材で構成して一の部材で複数の要素を兼用する態様としてもよいし、逆に一の部材の機能を複数の部材で分担して実現することもできる。

なお本明細書においては、無線接続と有線接続を混在させることもできる。例えば、無線接続のハンディターミナルに加えて、有線接続のハンディターミナルも併用するシステムにおいても本発明を適用できる。また、サーバ装置とホスト装置の接続方式については、無線、有線を問わない。例えば、電気接点やコネクタを介した物理的な電気接続による接続方式としては、ＩＥＥＥ１３９４、ＲＳ−２３２ｘやＲＳ−４２２、ＵＳＢ等のシリアル接続、パラレル接続、あるいは１０ＢＡＳＥ−Ｔ、１００ＢＡＳＥ−ＴＸ、１０００ＢＡＳＥ−Ｔ等のネットワークを介して電気的に接続して通信を行うことができる。無線接続族の例としては、ＩＥＥＥ８０２．１ｘ、ＯＦＤＭ方式等の無線ＬＡＮやＢｌｕｅｔｏｏｔｈ等の電波、ＩｒＤＡ等の赤外線、光通信等を利用した方式が挙げられる。また、これらの通信は必要に応じて暗号化、圧縮等の処理を付加することもできる。あるいはＯＥＩＣ（オプトエレクトロニクスインテグレーテッドサーキット）等電気光素子を用いたデータやエネルギーの送受信のように、電気や光をはじめとする電磁気、圧力、音波、電波、熱等を媒体とする信号データの送受信や各種エネルギーの送受信が可能なように「接続」された状態も本明細書でいう接続であるとするものであり、直接接続、間接接続は問わない。さらには、常時接続されている必要はなく、スイッチ回路や切り替え回路にて駆動回路の駆動状況に応じて必要時のみ（例えば電荷、電気、電流が通る時のみ）接続されるように構成しても良い。あるいはまた、コンピュータで作成したアプリケーションプログラムの端末装置への送信は、記録媒体を介した伝達も可能であり、このような記録媒体としてはＰＣカードやコンパクトフラッシュ（登録商標）、スマートメディア、ＳＤカード、メモリスティック等のメモリカードや半導体メモリ、磁気ディスク、光ディスク、光磁気ディスク等が利用できる。

本明細書において端末プログラム設定装置、端末プログラム設定プログラム、サーバプログラム設定装置、サーバプログラム設定プログラムは、プログラムの作成や設定等を行うシステムそのもの、ならびにプログラム作成、設定等に関連する入出力、表示、演算、通信その他の処理をハードウェア的に行う装置や方法に限定するものではない。ソフトウェア的に処理を実現する装置や方法も本発明の範囲内に包含する。例えば汎用の回路やコンピュータにソフトウェアやプログラム、プラグイン、オブジェクト、ライブラリ、アプレット、コンパイラ、モジュール、特定のプログラム上で動作するマクロ等を組み込んでアプリケーション作成、設定自体あるいはこれに関連する処理を可能とした汎用あるいは専用のコンピュータ、ワークステーション、端末、携帯型電子機器、ＰＤＣやＣＤＭＡ、Ｗ−ＣＤＭＡ、ＦＯＭＡ（登録商標）、ＧＳＭ、ＩＭＴ２０００や第４世代等の携帯電話、ＰＨＳ、ＰＤＡ、ページャ、スマートフォンその他の電子デバイスも、本発明の端末プログラム設定装置、端末プログラム設定プログラム、サーバプログラム設定装置、サーバプログラム設定プログラムの少なくともいずれかに含まれる。また本明細書においては、プログラム自体もプログラム設定装置に含むものとする。また本プログラムは単体で使用するものに限られず、特定のコンピュータプログラムやソフトウェア、サービス等の一部として機能する態様や、必要時に呼び出されて機能する態様、ＯＳ等の環境においてサービスとして提供される態様、環境に常駐して動作する態様、バックグラウンドで動作する態様やその他の支援プログラムという位置付けで使用することもできる。

図１に本発明の一実施の形態としてサーバ装置、ホスト装置等がネットワーク接続されたシステムに端末装置を無線通信可能に接続したシステムの一例を示す。この例では、在庫管理システムにおいて子機である端末装置１００にバーコードスキャナを備えるハンディターミナルを使用し、在庫に付されたバーコードをスキャンして親機であるサーバ装置に無線送信し、サーバ装置で在庫管理を行う例を示している。サーバ装置２００は、アクセスポイント５００やハブ７００等を介して複数の端末装置１００と接続される。図の例ではアクセスポイント５００やサーバ装置２００、ホスト装置３００等を一のみ図示しているが、複数の機器をネットワークで接続可能であることはいうまでもない。このようなネットワーク接続においては、イーサネット（登録商標）によるＴＣＰ／ＩＰプロトコル等、既存の、あるいは将来開発される通信プロトコルが適宜採用できる。図１の例では端末装置１００とサーバ装置２００との無線接続の通信方式は、本実施の形態においてはＩＥＥＥ８０２．１１ｂを利用している。ただ、ＩＥＥＥ８０２．１１ａやｇ、ｈ等の他、ＢｌｕｅｔｏｏｔｈやＩｒＤＡ等の赤外線通信等、無線による通信が可能な他の方式も利用可能であることは言うまでもない。このようなＬＡＮ等のネットワークは、ルータを介して他のネットワークと接続することもできる。例えば、ＬＡＮやＷＡＮなどのネットワークとして、図２や図３のような構成が利用できる。図２の例は、社内ＬＡＮなどのネットワークを、ルータ６００を介してインターネットなど外部のネットワークと接続できる。また図３の例では、複数のネットワークをルータを介して接続している。例えば、１Ｆのネットワークに接続されたルータ６０１と、２Ｆのネットワークに接続されたルータ６０２とを、ルータ６０３に接続することで、これらのネットワーク間をブリッジしたネットワークを構築できる。また図３の例ではサーバ２０７が１Ｆのネットワークに接続されているが、他のネットワークに接続していてもよい。

端末装置１００は、カードリーダ、バーコードスキャナ、プリンタ等の機能を一以上備えるハンディターミナルや、ＰＤＡや携帯電話等の携帯型電子端末である。これらの端末装置１００は、いわゆるリッチクライアント方式又はファットクライアント方式により、端末装置自体に端末プログラムの実行機能を備えており、ホスト装置３００との間で通信が確立されていない状態でも処理を行える。ただ、本発明においては端末側にデータの入出力等最低限の動作が可能な小規模なプログラムをおき、コンピュータ等のホスト側にアプリケーションやデータを置き、端末側ではデータの入力のみ行い、必要な処理はすべてホスト側に置かれたアプリケーションプログラムで行うシンクライアント方式の端末装置も利用できる。以下の例では、端末装置１００として図４に示すリッチクライアント方式のバーコードスキャナ付ハンディターミナルを用いる場合を説明する。図４（ａ）はハンディターミナルの正面図、図４（ｂ）は斜視図をそれぞれ示す。このハンディターミナルは、通信結果等を表示可能な端末表示部１０７として液晶ディスプレイや操作キー等の端末操作部１０８等が設けられる。また、無線通信用ユニットや背面に備えたバーコードスキャナ１０９、端末表示部１０７、端末操作部１０８等の制御を実行するための端末制御部１０４として、マイクロプロセッサを搭載している。

サーバ装置２００及びホスト装置３００は、コンピュータやメインフレーム等が利用される。図の例では、サーバ装置２００及びホスト装置３００に汎用のパーソナルコンピュータを使用している。またサーバ装置２００やホスト装置３００のコンピュータには、モニタや入出力デバイスを接続しない構成とすることもできる。ホスト装置３００は、システムに必要なデータベース４００を接続している。データベース４００は外付けの他、ホスト装置３００を構成するコンピュータのハードディスク等の二次記憶装置と併用する等により、内蔵式としても良い。なお図の例ではホスト装置３００とサーバ装置２００を個別に用意しているが、本明細書においては、図５に示すようにホスト装置を統合したサーバ装置２００Ｂとし、データベース４００を接続してホスト装置としても機能させる態様も包含する。なお本明細書においてデータベースとは、データベース管理プログラムによって作成された専用フォーマットのデータファイルに限られず、汎用的なファイル形式も含めたデータを含むファイルを意味し、例えばテーブルやフォーマットに関するデータを含む。

図６に、端末装置１００とサーバ装置２００及びホスト装置３００とがデータをやりとりする状態を示す。この図に示すように端末装置１００では端末プログラム１１０が実行されており、サーバ装置２００ではサーバプログラム２１０が実行される。なお図６において、斜線部分はユーザが設定可能な部分を示している。

［端末装置１００］
端末装置１００は、端末プログラム１１０やデータを保持するための端末記憶部１０２と、端末記憶部１０２から必要なデータを読み込んで端末プログラム１１０を実行する端末制御部１０４と、サーバ装置２００と通信するための端末通信部１０６とを備える。

［端末プログラム１１０］
端末プログラム１１０は、端末記憶部１０２に保存されており、端末制御部１０４に呼び出されて実行される。端末記憶部１０２は読み書き可能な記憶素子であり、Ｅ^２ＰＲＯＭ等のメモリやハードディスク等の二次記憶媒体が利用できる。これによって、後述するように更新・変更された端末プログラム１１０をダウンロードして書き換え保存することができる。端末プログラム１１０は端末プログラム設定装置や端末プログラム設定プログラムを用いて作成される。典型的には、端末プログラム設定プログラムをインストールしたコンピュータ上で作成される。端末プログラムは、使用される端末装置やサーバ装置の仕様や用途に応じて予め複数の端末ライブラリ１１２が用意されており、これらを呼び出して必要な機能が実行される。所定の動作を行うライブラリを予め端末装置に実装して提供することで、これらを利用してプログラムの作成や編集を容易に行え、ユーザは端末プログラム設定装置等を用いて端末プログラムのすべての機能を規定して作成するプログラミング作業を軽減される。また、所定の機能を備える端末プログラムを予め提供して、ユーザはプログラミング作業を行うことなくこれを利用することもできる。また、ユーザが使用目的等に応じて端末プログラムをカスタマイズすることもできる。端末ライブラリ１１２には、通信用のライブラリが含まれる。端末プログラム１１０は端末ライブラリ１１２を用いて、端末通信部１０６を介してサーバ装置２００とデータ通信を行う。

［サーバ装置２００］
一方サーバ装置２００は、同様にサーバプログラム２１０やデータを保持するためのサーバ記憶部２０２と、サーバ記録部から必要なデータを読み込んでサーバプログラム２１０を実行するサーバ制御部２０４と、端末装置１００と通信するためのサーバ通信部２０６と、通信結果等を表示可能なモニタ等で構成されるサーバ表示部２０７を備える。サーバ制御部２０４は、コンピュータのＭＰＵ等の演算部により実現される。

［サーバプログラム２１０］
サーバプログラム２１０は、同様にサーバ記憶部２０２に保存されており、サーバ制御部２０４に呼び出されて実行される。サーバ記憶部２０２も読み書き可能な記憶素子であり、Ｅ^２ＰＲＯＭ等のメモリやハードディスク等の二次記憶媒体が利用できる。これによって、サーバプログラム２１０も書き換え可能とできる。サーバプログラム２１０はサーバプログラム設定装置やサーバプログラム設定プログラムを用いて作成される。なお、これらの設定装置やプログラムは、サーバプログラムに加えて、端末プログラムの作成、編集も可能とすることもできるし、あるいは個別の装置や機器を使用して端末プログラムやサーバプログラムをそれぞれ作成、編集するよう設計することもできる。図６の例では、サーバ装置２００を構成するコンピュータにインストールされたサーバプログラム設定プログラムによってサーバプログラム２１０を作成・編集し、サーバ記憶部２０２に保存する。サーバプログラム２１０は、サーバ通信部２０６を介して端末装置１００とデータ通信するためのサーバ基本プログラム２２０と、これとは独立したプログラムとして、用途に応じて作成されるサーバ応用プログラム２３０とを備える。サーバ応用プログラム２３０は、ユーザがエディタ等を利用してプログラムコードを記述したテキストファイルとして作成される。ただ、ユーザのプログラム設計を支援するサーバプログラム設定プログラムを用いてサーバ応用プログラム２３０を作成・編集することもできる。これらのサーバ応用プログラム２３０とサーバ基本プログラム２２０との間は、サーバ装置２００内部で通信を行う。具体的には、サーバ基本プログラム２２０に含まれるリクエストマネージャ２２２と、サーバ応用プログラム２３０に含まれるリクエストハンドラ２３２とが、各プログラムのプロセス間の通信を行う。リクエストハンドラ２３２とリクエストマネージャ２２２は、共有メモリ、メールスロット、パイプ、ソケット通信等の手段を使用して通信する。またサーバ基本プログラム２２０は端末プログラム１１０と同様に通信用のライブラリを備えており、これによってサーバ通信部２０６のハードウェアを制御し、サーバ装置２００と端末装置１００との通信が行われる。この構成により、サーバ応用プログラム２３０はサーバ基本プログラム２２０を介して端末装置１００側とデータ通信を行う。このように、端末プログラム１１０は端末通信用ライブラリを含む形で実装されているが、これに対してサーバプログラム２１０では、サーバ応用プログラム２３０をサーバ通信用ライブラリ２２４を含むサーバ基本プログラム２２０と独立させている。

このようにプログラムを多層化し、ユーザが作成するプログラムと他の機器との間で通信を受け持つプログラムとを切り分けることによって、不具合発生時の動作の維持と問題の特定とを可能とする。すなわち、システム側で提供されるサーバ基本プログラム部分は、一般に製造元が様々な試験を行い動作確認を行っているため、不具合の発生する可能性は少ない。一方、ユーザが作成するサーバ応用プログラム部分は、このような動作確認が不十分であることがあり、動作不良を生じる原因となる可能性が高くなる。したがって、サーバ応用プログラム部分に不具合が生じても、端末装置１００との通信等最低限の動作をサーバ基本プログラム２２０が受け持つことによってシステム全体をダウンさせることなく、不具合が生じたサーバ装置以外のシステムの動作を維持できる。また、プログラムを多層化することにより、問題発生箇所の特定も容易となる。すなわち、サーバ応用プログラム部分のいずれかで不具合が生じる可能性が高いと考えられるため、この部分のみの検証を行うことで問題を特定できる可能性が高くなり、作業時間の短縮に寄与し得る。

［要求データ１４０］
図６に示す無線通信システムにおいては、データ通信は端末装置１００からサーバ装置２００に対して要求を発信することで開始される。要求データ１４０は、端末プログラム１１０をロードした端末制御部１０４で生成され、サーバ装置２００に対して送信される。要求データ１４０は図７（ａ）〜（ｂ）に示すようなフォーマットで生成される。この図に示す要求データ１４０は、先頭にデータ種別を示すヘッダ情報１４１を有し、実データ１４３を含んでいる。要求データ１４０がデータベースにアクセスする必要のある要求、例えば指定された検索式による検索結果を含んでいる場合は、データベースへのアクセスを容易にする構造を実データ１４３に含ませることが好ましい。このような構造としては、データベースへのアクセスに必要な条件を変数としたデータ構造が好適に利用できる。変数の一例を表１に示す。実データ１４３は、表１のような構造体のデータを通信に適したバイナリもしくはテキストデータに変換したものである。

上記の表１の例では、要求データ１４０に含まれる変数として、アクセス対象となるデータベース名（１２７文字まで指定可能）、テーブル名（１２７文字まで指定可能）、さらに検索条件を指定する等の処理内容を示すkeydataとして、ここでは検索データに関する有効フィールドのデータ数、フィールドのインデックス番号、演算式、検索キー等を使用する。また、加えてnewdataとして取得するフィールドに関する変数のフィールドを適宜追加できる。このように、データベース中の検索等、処理に必要な項目を変数としてフィールド毎に記述することで、処理内容の解析が容易となり、要求データ１４０を受信したサーバ装置２００はデータベースに対するアクセス情報を取得して処理をスムーズに行うことができる。

［応答データ２４０］
このような変数を含む要求データ１４０をサーバ基本プログラム２２０が受け取ると、これをサーバ応用プログラム２３０に送信する。サーバ応用プログラム２３０は受信した要求データ１４０のコマンドを解析し、例えばホスト装置３００に接続されたデータベース４００にアクセスする等、適切な処理を行い、その処理結果を応答データ２４０として作成し、サーバ基本プログラム２２０に送信して端末装置１００側に返信する。端末装置１００は応答データ２４０を受信した後、端末プログラム１１０で規定されている後処理を行い、次の要求データを送信できる状態に戻る。サーバ装置２００はサーバ通信用ライブラリ２２４にて用意された関数を実行することで、応答データ２４０を端末装置１００側に送信して次の要求データ待ち状態となる。このように端末プログラム１１０とサーバ応用プログラム２３０との間にサーバ基本プログラム２２０を介在させることにより、仮にサーバ応用プログラムが動作を停止していても端末装置からの要求をサーバ基本プログラム２２０が受け取ることができるので、端末装置へエラー応答を返すことや、要求を溜めてサーバ応用プログラムの回復後に要求データを一括送信することが可能となる。

応答データ２４０のフォーマットは、例えば図７（ｃ）〜（ｄ）に示すように、先頭にデータ種別を示すヘッダ情報２４１を有し、実データ２４３を含んでいる。この実データ２４３に含まれる変数の一例を表２に示す。

上記の表２の例では、応答データ２４０に含まれる変数として、処理が成功か失敗かを示すresult、処理結果を示すresultdataとして、有効フィールドのデータ数を示すfield_num、フィールドのインデックス数を示すindex、及び検索結果データを示すdata（１２７文字まで指定可能）等が含まれる。なお演算子を示すoperation変数は、応答データ２４０では使用されない。このような変数で、要求データ１４０に対する結果を端末装置１００側に返す。

また要求データ１４０の作成時に予め上記演算結果の変数を含めておき、その値を仮に０やnull等としてサーバ装置２００側に送信し、サーバ装置２００で応答データ２４０の作成時に演算結果を各変数の値として代入して端末装置１００側に返送することで、端末装置１００側で必要なデータを適切に得ることができる。

［経過時間取得機能］
さらに、図１に示す端末装置は通信経路での経過時間を計測する機能を備える。すなわち、端末装置がアクセスポイント等を介してＬＡＮ上のサーバ装置とデータ通信を行うのに要した時間を処理毎に確認することができる。具体的には、要求データを送信してから応答データ２４０が返信されるまでのＴＡＴ時間において、指定した処理を行ったラップ時間を経過時間取得手段で取得し、端末表示部１０７に表示できる。これによって、ログを解析するといった専門的な知識が無くとも、ユーザはコマンドの実行時に通信経路上のどの部分で最も時間がかかっているかを簡単に調べることができるようになる。例えば、システムの運用中に急に処理が重くなる、あるいは特定のコマンドのみレスポンスが悪いといった問題が発生したときに、通信経路上のどの部分に問題が生じているか、あるいはどのプログラムの処理に不具合が生じているかといった問題の所在を容易に特定できる。特に、一旦ログを取得して事後的に解析するのでなく、システム運用中に直ちに確認できるので、専門知識が無くても簡単に扱えるという利点が得られる。

経過時間取得手段は、端末制御部１０４を構成するマイクロプロセッサやサーバ制御部２０４を構成するＭＰＵ等で実現される。すなわち、経過時間を取得する命令をサーバ装置側に送信する。経過時間取得機能を実行するには、端末装置からサーバ装置に送信される要求データに経過時間取得命令を付加する。要求データ１４０のヘッダ情報１４１には、経過時間取得機能の実行を指示する経過時間取得情報が含まれる。例えば、経過時間取得情報としてフラグを設けて、フラグのＯＮ／ＯＦＦで経過時間取得機能のＯＮ／ＯＦＦを切り替える。図７（ａ）、（ｂ）に要求データ１４０の構造を、（ｃ）、（ｄ）に応答データ２４０の構造をそれぞれ示す。図７（ａ）の要求データ１４０は経過時間取得機能をＯＦＦとしており、これに対して図７（ｃ）のような応答データ２４０が返される。一方、図７（ｂ）の要求データ１４０は経過時間取得機能をＯＮとしており、これに従い経過時間データ１４５の領域が付加されている。この要求データ１４０に対して図７（ｄ）のような、記録済み経過時間データ２４５が記録された応答データ２４０が返される。このような切替を行う経過時間取得情報は、ヘッダ情報１４１に記録する他、要求データ１４０の実データの末尾にフッタ情報として付加したり、あるいは要求データ１４０と別の命令として、関数の引数などで実現することもできる。経過時間取得情報により経過時間取得機能の実行が指示されると、図７に示すように実データに経過時間データ１４５が付加される。経過時間データ１４５は、例えば後述するような構造体のデータとし、初期化した状態で図７（ｂ）に示すように要求データ１４０の末尾に付加され、端末装置とサーバ装置との間で伝達されることによって、構造体のメンバに取得された経過時間が記録されて、図７（ｄ）に示すように記録済み経過時間データ２４５が記録された応答データ２４０が得られる。もちろん、経過時間データは実データの末尾に付加する他、実データの前や内部に含めてもよい。

本実施の形態では、プログラム言語で呼び出せるライブラリ関数として、rqTimeStampを用意している。この関数rqTimeStampは、処理を行った際の時刻を取得するものであり、またユーザが任意の文字列でコメントを付加できる。例えば、端末プログラムやサーバプログラム中で以下のように記述する。
int rqTimeStamp ( char* comment );
ここでintはデータが整数型の変数であることを示す型宣言であり、次のrqTimeStampで取得された時刻を整数として扱う。また、コメントとして変数commentを、文字列の変数（char*）として宣言している。

この関数を用いて、サーバプログラムのサーバ応用プログラムを作成する際に、例えば以下のようなコードを記述できる。
rqTimeStamp ("start-connect")//サーバ装置との接続
rqTimeStamp ("start-send-data")//サーバ装置へデータを送信
rqTimeStamp ("end-send-data")//サーバ装置から端末装置へデータを送信
これらの命令は、各々のタイミングで経過時間を取得すると共に、指定したコメントの文字列情報を付加するものである。このようにプログラムのソースコード中に、ユーザが経過時間を取得したいプロセスに続けて上記のコマンドを付加することで、そのプロセスが実行された時刻を取得し確認できるようになる。

一方、経過時間を取得する命令を実行した際に、取得した経過時間データを保持するために、例えば端末プログラムを規定するプログラム言語において以下のような構造体を定義し、この構造体に取得したＴＡＴ時間に関するデータを保持するよう設定する。
typedef struct{
char time[12]; // 時刻（hh:mm:ss形式の文字列）
long lap_time; // サーバ内経過時刻[ms]
char comment[48]; // コメント
} TAT_RECORD；

上記の構造体TAT_RECORDは、後述するＴＡＴデータの個別のレコード情報を保持するものである。具体的には、typedefの宣言で構造体（struct）としてTAT_RECORDを定義するとともに、この構造体の要素であるメンバとして、time、lap_time、commentを定義する。この内、time[12]は最大１２バイトの文字型データ（char）として定義され、取得された時刻をhh:mm:ss形式の文字列として保持できる。またlap_timeは桁数を多くした整数型（long）として定義され、サーバ装置内での経過時間をラップ時間として保持する。さらに、comment[48]は最大４８バイトの文字型データ（char）として定義され、ユーザがコメントを１バイト文字なら４８文字、２バイト文字なら２４文字まで付加できる。

さらに、上記で定義された構造体TAT_RECORDを持つ上位の構造体として、TAT_DATAをＴＡＴデータ構造体として定義する。
typedef struct{
TAT_RECORD HT_send ; // 計測開始時刻（リクエスト送信）
TAT_RECORD SV_recv ; // リクエスト受信時刻
TAT_RECORD post ; // メッセージポスト
TAT_RECORD user[16]; // ユーザタイムスタンプ
TAT_RECORD response; // ユーザレスポンス時刻
TAT_RECORD SV_send ; // レスポンス送信時刻
TAT_RECORD HT_recv ; // レスポンス受信時刻
} TAT_DATA；

上記の構造体TAT_DATAは、ＴＡＴデータを保持するものであり、本実施の形態では端末装置側とサーバ装置側にそれぞれ用意されている。具体的には、構造体TAT_DATAを定義するとともに、メンバとして上述したTAT_RECORD構造体を個々に有するHT_send、SV_recv、post、user、response、SV_send、HT_recvを定義する。この内、HT_sendは計測開始時間すなわち端末装置がサーバ装置に要求（リクエスト）データを送信したタイミングを記録する。図６の例では、端末ライブラリ１１２内の端末通信用ライブラリが記録を行う。この端末装置側のTAT_DATA構造体の情報は、図７（ｂ）の経過時間データ１４５部分に展開されて、端末通信部１０６からサーバ通信部２０６へ伝達される。またSV_recvはサーバ装置がこの要求データ１４０を受信した時刻を記録する。図６の例では、サーバ基本プログラム２２０内のサーバ通信用ライブラリ２２４が記録を行う。さらにpostはメッセージポストのタイミングを記録する。図６の例では、サーバ基本プログラム２２０内のリクエストマネージャ２２２が記録を行う。さらにまたuserは、ユーザが１６個まで指定可能な任意のタイミングを記録する。図６の例では、サーバ応用プログラム２３０内のリクエストハンドラ２３２が記録を行う。またresponseはユーザレスポンス時刻を図６の例ではリクエストマネージャ２２２が記録し、SV_sendはサーバ装置が応答（レスポンス）データを端末装置に送信した時刻を図６の例ではサーバ基本プログラム２２０内のサーバ通信用ライブラリ２２４が記録する。ここで、サーバ基本プログラム２２０内のサーバ通信用ライブラリ２２４がサーバ装置側のTAT_DATA構造体の情報を経過時間データ２４５に展開して、応答データ２４０としてサーバ通信部２０６から端末通信部１０６へ伝達される。HT_recvはこの応答データ２４０を端末装置が受信した時刻を図６の例では端末ライブラリ１１２内の端末通信用ライブラリが記録する。このように、各プロセスに記録を行う部分がそれぞれ用意されており、これによって、端末装置側でサーバ装置内での動作の記録を知ることが可能になる。また、端末ライブラリ１１２が記録するHT_sendやHT_recvは、単に端末装置側で情報を保持するにとどめ、サーバ装置側で記録するものだけを経過時間データ２４５として通信させてもよい。

以上のような経過時間取得命令を用いて、実際に経過時間を取得した例を、表３及び図８にそれぞれ示す。表３は、経過時間取得命令によって取得されたデータを保持する各構造体について、メンバに入力された値を示している。また図８（ａ）、（ｂ）は、経過時間取得命令実行後に、この結果を端末表示部１０７に表示する一例を示している。

表３に示すデータが、経過時間データ２４５として図８に示すように端末装置に一覧で表示される。なお端末装置の端末表示部１０７で表示しきれない場合は、画面をスクロールさせる等の方法で全体を表示できる。また途中結果として、サーバ装置側のTAT_DATA構造体の情報をサーバ装置側のサーバ表示部２０７で表示させるよう構成してもよい。図８（ｂ）は、（ａ）の画面をスクロールさせて表示させた状態を示している。この例では、構造体TAT_DATAのメンバであるuserとして、user[0]には上述したstart-connect、user[1]にはstart-send-data・・・が割り当てられ、それぞれrqTimeStamp命令で取得された時刻を取得し、構造体に入力される。このように、ユーザが端末プログラムやサーバプログラム中で指定した任意のタイミングで時間を取得できる。この例ではuserの配列を１６個に指定しており、１６個までタイミングを指定できるが、もちろんこれより多い数、あるいはこれより少ない数の指定を可能とすることもできる。表３に示すように、各構造体のメンバの値を、time（時刻）、lap_time（ラップ時刻）、comment（コメント）の順にそれぞれ表示する。表３の例では端末装置からサーバ装置にデータが送信された時刻として２０：３０：５４、ラップ時間として０、コメントとして「send to Server @HT[10.10.18.100]」を表示している。このコメントはサーバ装置への送信を示す「send to Server」と、その動作主体を＠以下に示している。ここでは端末装置であるハンディターミナルのＩＰアドレスを示すことで、複数あるハンディターミナルのいずれが通信しているかを区別している。この例では、動作主体としてHTがハンディターミナル、Serverがサーバ装置、Request handlerがリクエストハンドラ、User Appがユーザが作成するサーバ応用プログラムをそれぞれ表している。

なお、このような経過時間取得機能は、特定の処理に対して選択的に付加できる。すなわち、ユーザが必要なときに特定の処理に対して経過時間取得機能をＯＮすれば、上記のコマンドが端末プログラム及び／又はサーバ応用プログラム中の予め指定された位置に自動的に付加され、また要求データ１４０には構造体TAT_DATAが付加されて経過時間取得命令が実行されて構造体のメンバに時刻が入力され、記録済み経過時間データ２４５を含む応答データ２４０が端末装置に返されてユーザは各々の経過時間を表示部で確認できる。また、このような機能が不要な場合は経過時間取得機能をＯＦＦすることで、経過時間を取得しない通常の処理が実行される。このように経過時間の取得を選択的に実行可能とすることで、通信状態の変化で特定の処理ができなくなったり動作が重くなったりした場合に、経過時間取得機能を実行させて原因を特定できる。また、具体的な処理を行わない空のデータを送り、送受信タイミング等の基本的な処理の経過時間のみ取得させることもできる。あるいは、取得された経過時間のデータをファイルに保存してログのように利用することもできる。またこのファイルをサーバ装置や他の端末装置に転送して閲覧させることもできる。

なお上記は一例であって、構造体や関数等は他の規定方法によっても実現できることはいうまでもない。例えば、構造体に代わって配列を使用してもよいし、コメントの文字列を長くしたり漢字等の２バイト文字を使用することもできる。また、プログラム言語についても、高級言語、低級言語のいずれで記述してもよい。例えばＣ言語等のコンパイラ言語の他、Perl、Awk、JavaScript（登録商標）等のインタープリタ言語を使用することもできる。あるいは、アセンブラ言語や機械語を使用することもできる。また、経過時間の記録は、上記の構成ではラップ時間として表示することで、端末装置の時計とサーバ装置の時計とで時刻がずれている場合でも対応可能としている。ただ、端末装置とサーバ装置で定期的に通信する等の方法で、予め両者の内蔵時計の時刻を一致させておくことにより、絶対的な時間表示も可能とでき、経過時間をより見易くすることもできる。

システムに生じ得る問題や不具合の特定は、一般に処理に要している時間をもって判断される。したがって、各処理の時間を記録することで、どの部位で問題が生じているかを判断できるようになる。その結果、上記の方法により各処理の実行された時刻を容易に確認できるので、ユーザはどの部分で時間がかかっているのかを容易に判断できる。従来、ネットワーク技術等に詳しいユーザであれば、pingコマンド等を用いて通信の状態を調べていたが、専門的な知識が必要であり一般ユーザには困難であり、また実際の処理に要する時間を求めることはできなかった。これに対して本実施の形態によれば、経過時間取得機能を利用するのみで、各処理における経過時間を確認できるので、どの部分で時間がかかっているかを極めて容易に判断できる。またこの方法は、従来であれば複数の装置で個別に取得しなければならなかったログを集め時系列や処理順序に対比していた作業を、取得された時間のデータを一箇所に集め、時系列に並べて見易くする作業を自動化することで、専門知識が無いユーザにも極めて容易に問題の特定が行えるようにしている。これによって問題箇所の特定作業が簡単かつ速やかに行え、必要な対応策を講じることができる。

［通信経路障害調査機能］
端末装置側からサーバ装置側にデータ通信を行うとき、反応が遅くなる原因としては通信経路の障害か、プログラム内部での不具合かが考えられる。この原因を特定するために、端末側で通信経路の障害を調査する端末経路調査機能を備える。この様子を図９に基づき説明する。図９は、通信経路障害を調査するプロセスを示している。この図の例では、通信経路を構成する物理層を４つのエリアに区別している。すなわち、端末装置―アクセスポイント間をＡエリアとし、ＬＡＮをＢエリアとし、サーバ装置２００で実行されるサーバプログラム２１０の内、サーバ基本プログラム２２０の通信部分をＣエリアとし、サーバプログラム２１０のサーバ応用プログラム２３０をＤエリアとして、どの部分で障害が起きているかを特定する。

ここで、往路即ち端末装置側からサーバ装置への通信経路の障害調査を行う端末経路調査機能は、端末装置側からサーバ装置側に応答を要求して行う。なお応答を要求するとは、応答を要求する命令を含む要求データを送信することである。ここでは端末プログラム１１０で、端末経路調査機能専用の関数をコールするとその内容で実行可能な３つの関数を用いて通信経路を調査し、それらの結果は戻り値として順次端末装置に通知される。一方、復路即ちサーバ装置側から端末装置側に向かう通信経路を調査するサーバ経路調査機能、具体的にはサーバプログラム２１０のサーバ応用プログラム２３０からサーバ基本プログラム２２０へのプロセス間通信の調査は、サーバ装置側から専用の関数をコールし、その結果を端末装置とサーバ応用プログラム２３０に通知することにより実行される。上記端末経路調査機能およびサーバ経路調査機能の結果から、図９の物理層のどのエリアで問題が生じているかを特定できる。

［端末経路調査機能］
次に、端末経路調査機能を実現する手順の一例を、図１０のフローチャート及び図９のデータの流れを示す説明図に基づき説明する。まず、ステップＳ１で調査結果を記録する調査結果データを初期化する。この例では、通信経路障害の結果を保存する調査結果データを以下のような構造体として定義する。
//経路異常検出・レスポンス構造体
typedef struct{
long result ; // 総合判定結果
long open ; // btRf Open() 実行結果 [ Ａエリア ]
long ping ; // btRf PingRequest() 実行結果 [ Ｂエリア ]
long send ; // btRf SendData() 実行結果 [ Ｃエリア ]
long wait ; // 待ち受け時の結果
} RES_FIND_TROUBLE;
この構造体RES_FIND_TROUBLEは、構造体の要素であるメンバとしてresult、open、ping、send、waitを含んでいる。この内、resultはどのエリアで問題が発生しているかを伝えるためのメンバであり、各調査エリアでの判定結果を随時入力していく。またopen、ping、sendなどは、それぞれ図９のＡエリア、Ｂエリア、Ｃエリアで実行した関数の戻り値が代入される。これによって、各エリアでの詳細な情報が各々のメンバに記録される。例えば、端末経路調査機能を実行後resultを参照してＡエリアで問題が発生していることが判明した場合に、openの内容をチェックするとＡエリアでのさらに詳しい情報を得ることができる。一方、waitは後述する待ち受け実行時の結果を記録するためのものである。このようにして定義された構造体RES_FIND_TROUBLEを初期化する。ここでは、各メンバにFT_NOT_TRYを代入し、障害調査が未だ行われていないことを記録する。

次にステップＳ２で、アクセスポイントとの通信が確立できるか否かを判別する。ここでは専用に用意された関数で、端末装置とアクセスポイントとの間で通信が可能か否かを判別して判定結果を調査結果データの該当する位置に記録する。具体的には、第１の関数として関数btRfOpen()を実行し、その戻り値をメンバopenに記録する。例えば、アクセスポイントとの無線通信が確立できた場合は、戻り値「BT_RF_API_SET_OK」をRES_FIND_TROUBLE．openに記録し、端末表示部１０７でこのメンバが参照された際に「無線による接続を完了しました。」等と表示されるように設定する。また無線通信が確立できない場合、「BT_RF_API_RF_ERR」を記録し、「無線による接続に失敗しました。」と表示されるように設定する。なお、無線通信が確立されたか否かは、所定の応答時間内に応答が返されるか否か等の方法で判定できる。また既に通信が確立されている場合は、「BT_RF_API_SET_ERR」と記録し、「オープンされています。」と表示されるように設定する。このように戻り値をRES_FIND_TROUBLE．openに記録し、戻り値が「BT_RF_API_RF_ERR」以外の場合は、ステップＳ３に進む。一方、戻り値が「BT_RF_API_RF_ERR」の場合、即ちアクセスポイントとの通信に問題があるときは、ステップＳ２−１に進みアクセスポイントエラーを記録する。この場合は、問題がＡエリアで発生していることになるので、RES_FIND_TROUBLE．resultにFT_ERR_HT_APをセットし、ステップＳ７へジャンプする。

次にステップＳ３で、アクセスポイントとサーバ装置との間の物理層、即ちルータ、ハブ等のネットワーク機器や１０ＢａｓｅＴ等のＬＡＮケーブルといったＬＡＮ経路を介して、サーバ装置との間で通信が確立可能か否かを判定する。ここではサーバ装置と通信が可能か否かを判定して、判定結果を調査結果データの該当する位置に記録する。具体的には、第２の関数として関数btRfPingRequest()を実行し、その戻り値をメンバpingに記録する。例えば、データの送信先のサーバ装置と接続が確立された場合は、戻り値「BT_RF_API_SND_OK」をRES_FIND_TROUBLE．pingにセットし、端末装置１００の端末表示部１０７でこのメンバが参照された際に「設定されているホストＰＣとの接続が確立されています。」などのメッセージが表示されるよう設定する。この場合は正常であるため、次のステップＳ４に進む。一方、通信の相手先の指定が誤っているなど通信設定に誤りがある場合は、戻り値「BT_RF_API_PARAM_ERR」を記録し、「パラメータエラー」と表示されるように設定する。さらに無線圏外による送信失敗の場合は、戻り値「BT_RF_API_OUTRANGE」を記録し、「無線圏外による送信失敗」等と表示されるように設定する。なお無線圏外かどうかの判定は、例えば端末装置自体に周囲の電波状態を把握させ、電波の強度に応じて通信可能かどうかを判断させる。これは、携帯電話が電波状態の把握してアンテナに電波のマークを段階的に表示させる手法と類似の方法が採用でき、アンテナ表示が圏外表示となっている場合に「無線圏外による送信失敗」と判定する。さらにまた、一定時間内に応答が得られない場合は、戻り値「BT_RF_API_TIMEOUT」を記録し、「タイムアウト」等と表示されるよう設定される。以上のように、戻り値が「BT_RF_API_SND_OK」の場合は問題なしとして次ステップＳ４に進み、それ以外の場合はエラー発生としてステップＳ３−１に進む。ステップＳ３−１ではエラーの種別が通信設定エラーか否かを判定し、戻り値が「BT_RF_API_PARAM_ERR」のときはステップＳ３−１１に進み通信設定エラーを記録する。ここでは戻り値「FT_ERR_PARAM」をRES_FIND_TROUBLE．result にセットして、ステップＳ７へ進む。またそれ以外のエラーの場合はステップＳ３−１２に進みアクセスポイントからサーバ装置までのＬＡＮ経路に異常があることを記録する。ここでは戻り値として「FT_ERR_AP_PC」をRES_FIND_TROUBLE．result にセットして、ステップＳ７へ進む。

ステップＳ４では、サーバ装置との接続が確立できるか否かを判定する。ここでは、サーバ装置で実行されるサーバプログラム２１０の内、通信を制御するサーバ基本プログラム２２０と通信が可能か否かを判別して、判定結果を調査結果データの該当する位置に記録する。具体的には、第３の関数としてbtRfSndData()を実行し、その戻り値をメンバsendに記録する。例えば、通信先として指定されたサーバ装置へのデータ送信が実行できた場合は、戻り値として「BT_RF_API_SND_OK」をRES_FIND_TROUBLE．sendにセットし、端末表示部１０７でこのメンバが参照された際に「設定されているホストへのデータ送信が完了しました。」と表示されるように設定する。また、サーバ装置へのデータ送信を失敗した場合は、戻り値「BT_RF_API_SND_NG」をRES_FIND_TROUBLE．sendにセットし、「送信失敗」等と表示されるように設定する。以下の処理は上記ステップＳ３とほぼ同様であり、通信の相手先の指定が誤っているなど通信設定に誤りがある場合は、戻り値「BT_RF_API_PARAM_ERR」を記録し、「パラメータエラー」と表示されるように設定する。さらに無線圏外による送信失敗の場合は、戻り値「BT_RF_API_OUTRANGE」を記録し、「無線圏外による送信失敗」等と表示されるように設定する。以上のように、戻り値が「BT_RF_API_SND_OK」の場合は問題なしとして次ステップＳ５に進み、それ以外の場合はエラー発生としてステップＳ４−１に進む。ステップＳ４−１ではエラーの種別が通信設定エラーか否かを判定し、戻り値が「BT_RF_API_PARAM_ERR」のときはステップＳ４−１１に進み通信設定エラーを記録する。ここでは戻り値「FT_ERR_PARAM」をRES_FIND_TROUBLE．result にセットして、ステップＳ７へ進む。またそれ以外のエラーの場合はステップＳ４−１２に進み、サーバ装置のサーバプログラム２１０に異常があることを記録する。ここでは戻り値として「FT_ERR_AP_PC」をRES_FIND_TROUBLE．result にセットして、ステップＳ７へ進む。

ステップＳ５では、正常に通信が行われているため、サーバ装置が端末装置に応答を返す。ここでは通信経路障害の調査を行っており、実際のデータ通信とは異なるため、サーバ装置では、端末装置からの要求をサーバ応用プログラム２３０のリクエストマネージャ２２２には送信しなくてもよい。一方、端末装置からの要求データに対しては、ヘッダ情報を解析して応答データを返信する。応答データは空のダミーデータとして「REQ_FIND_TROUBLE」などをサーバ基本プログラム２２０が端末装置に送信する。次にステップＳ６に進み、端末調査を終了する。ここでは、正常終了したことを示す戻り値「FT_SEND_FIN」をRES_FIND_TROUBLE．resultにセットする。さらに、端末装置１００の端末表示部１０７に、調査結果データの記録内容を表示することもできる。例えば、メンバresultにエラーが記録されている場合は、該当するエラー内容を表示し、どのエリアで問題が生じているかを表示する。さらに詳細な情報が必要であれば、該当するメンバの内容に対応するメッセージを表示し、該エリアのエラー内容を表示する。また、通信が正常である場合は、次にサーバ経路調査機能を実行するための待ち受け画面への移行を促すメッセージを表示する。例えば、「通信上の問題はありません。アプリに問題がある可能性があります。サーバ側から経路異常を調査してください。」などと表示させ、ステップＳ７に移行する。ステップＳ７では、サーバ経路調査機能の実行に必要な通信待ち受け状態を端末装置で実行するか否かを判定する。例えば、端末表示部１０７に「＜サーバ側からの経路異常調査＞待ち受けを実行しますか？ ＹＥＳ／ＮＯ」とダイヤログを表示させ、ＹＥＳを選択した場合はステップＳ８に移行し、ＮＯの場合は処理を終了する。ステップＳ８では、端末装置の待ち受け状態を実行する。ここでは、第４の関数hcWaitFT(short timeout)を実行する。この引数は待ち受けのタイムアウト時間を指定することができるが、予めシステムで指定しておいた適当な固定値を利用してもよい。またこの関数hcWaitFT()の戻り値を構造体RES_FIND_TROUBLEのメンバwaitに記録する。なお、いずれの場合においても、端末経路調査の専用関数の関数終了時の戻り値は、RES_FIND_TROUBLE．resultの値をそのまま使用する。

以上のように、端末経路調査機能によって、通信経路の各物理層での通信が可能かどうかをエリア毎に判定し、結果を表示することができる。これによって、どの部分でどのような障害が生じているかを容易に判断できる。ただ、この方法では図９のＤエリア、すなわちサーバ基本プログラム２２０とサーバ応用プログラム２３０間のプロセス間通信の異常を判定することができない。そこで、サーバ経路調査機能によってこの部分の通信が正常かどうかを判断する。

［サーバ経路調査機能］
以下、サーバ経路調査機能を実行する手順を図１１のフローチャート、および図１２のデータの流れを示す図に基づいて説明する。まずステップＳ１１では、サーバ経路調査機能を実行するサーバ装置と接続された任意の端末装置で待ち受けを実行する。具体的には、上述したステップＳ８において、端末プログラム１１０で待ち受け関数hcWaitFT(short timeout)を実行する。これによって、端末装置は所定の時間サーバ装置からのデータ送信を待ち続ける状態となる。なお、上記の端末経路調査機能の実行中にステップＳ８から待ち受けを実行する以外に、ユーザが上記機能と別に明示的に待ち受け関数を実行することもできる。

次にステップＳ１２で、サーバ装置のサーバ応用プログラム２３０がサーバ基本プログラム２２０に対して応答を要求する。具体的には、サーバ応用プログラム２３０に含まれるリクエストハンドラ２３２が、サーバ基本プログラム２２０に含まれるリクエストマネージャ２２２から反応を要求する関数を呼び出す。ここでは、リクエストハンドラ２３２の公開関数として用いたbtrqFindTrouble()を実行する。

次にステップＳ１３で、所定の時間内にサーバ基本プログラム２２０から応答が得られたか否かを判定する。具体的には、関数が呼び出されたときから計時を開始し、応答を受信するまでの時間を測定する。ここでは、リクエストハンドラ２３２がbtrqFindTrouble()を呼ばれたら、タイマをスタートし、戻り値「HTRQ_FT」をリクエストマネージャ２２２から受信するまでの時間をチェックする。所定時間内にリクエストハンドラ２３２がリクエストマネージャ２２２から応答を受け取ると計時を終了して正常と判定し、所定時間内に応答が無い場合は異常と判定する。

サーバ基本プログラム２２０は一方で、端末装置との接続状態を確認する（ステップＳ１４）。ここでは、サーバ基本プログラム２２０が端末装置に対して応答を要求し、所定の時間内に端末装置から応答が得られたか否かでサーバ装置と端末装置との間の通信障害を判定する。具体的には、サーバ基本プログラム２２０がサーバ通信部を制御するよう、リクエストマネージャ２２２が関数内部で通信ライブラリのhcFindTrouble()をコールする。hcFindTrouble(LPCTSTR IpAddress)内では、引数で指定された端末装置に向かって、ダミーデータを送信し、送信後関数を終了する。待ち受け状態にある端末装置は、ダミーデータを受信すると受信できた旨のメッセージを端末装置に表示する。これによって、サーバ装置から端末装置への送信が正しく伝わるかどうか、すなわちＢエリア、Ａエリアでの通信が正常に行われているかどうかを確認できる。なお、この部分の調査は上述した端末経路調査機能でチェックできるため、ステップＳ１４は補足的なものであり、このステップを省略することもできる。

次にステップＳ１５で、リクエストマネージャ２２２は、リクエストハンドラ２３２に対して応答を返信する。ここでは、「HTRQ_FT」というメッセージをポストする。リクエストハンドラ２３２側では、HTRQ_FTを受信する。タイマの計時を確認し、所定時間内に受信できた場合は、正常に動作していると判断して、その旨のメッセージをサーバ表示部２０７に表示する。時間内に受信できずタイムアウトが生じた場合は、異常発生と判断し、その旨のエラーメッセージをサーバ表示部２０７に表示する。すなわち、サーバ応答プログラムとサーバ基本プログラム２２０とのプロセス間通信に障害が発生していると判断される。このように、サーバ経路調査機能の判定結果をサーバ装置２００のサーバ表示部２０７に表示することで、ユーザはプロセス間通信に問題が生じていることを確認できる。なお、判定結果は端末装置側にも送信して端末表示部で表示させることもできるし、サーバ表示部に表示させない構成としても良い。プロセス間通信の不具合の原因は、サーバ応答プログラム、サーバ基本プログラム２２０のいずれかにあると考えられ、一般的にはユーザが作成したサーバ応用プログラム２３０側で不具合が生じている可能性があるため、この部分を調査して必要な作業を行うこととなる。

以上のように、端末経路調査機能とサーバ経路調査機能を用いて、通信の不具合がどの部分で発生しているかを把握することができる。Ａエリア、Ｂエリア、Ｃエリアのいずれかの部分で問題が発生している場合は、端末経路調査機能によって問題を検出できる。また端末経路調査機能で問題が検出されず、サーバ経路調査機能を実行してメッセージが取得できない場合は、Ｄエリアで障害が起きていると判断できる。

本発明に係る端末装置等を用いて、ハンディターミナルの端末装置と、コンピュータであるホスト装置を組み合わせたＰＯＳ（販売時点管理システム）や在庫管理、入出庫管理、出荷検品、入荷検品、発注管理、工程進捗管理、発注管理等のシステムに好適に利用できる。

本発明の一実施の形態に係る端末装置、サーバ装置、ホスト装置が通信可能に接続されて無線通信システムを構成する一例を示す概念図である。 本発明の他の実施の形態に係る端末装置のネットワークの構成例を示す概念図である。 本発明のさらに他の実施の形態に係る端末装置のネットワークの構成例を示す概念図である。 図１の端末装置を構成するバーコードスキャナ付ハンディターミナルを示す正面図及び斜視図である 本発明のさらに他の実施の形態に係る端末装置、サーバ装置兼ホスト装置が通信可能に接続されて無線通信システムを構成する一例を示す概念図である。 端末装置とサーバ装置及びホスト装置とがデータをやりとりする状態を示す概念図である。 要求データ及び応答データの構成を示す概念図である。 経過時間データを表示部に示した状態を示すイメージ図である。 通信経路を構成する物理層において通信経路障害を調査するプロセスを示す説明図である。 端末経路調査機能を実行する手順を示すフローチャートである。 サーバ経路調査機能を実行する手順を示すフローチャートである。 サーバ応用プログラムとサーバ基本プログラムとのプロセス間通信において通信経路障害を調査するプロセスを示す説明図である。

符号の説明

１００…端末装置
１０２…端末記憶部
１０４…端末制御部
１０６…端末通信部
１０７…端末表示部
１０８…端末操作部
１０９…バーコードスキャナ
１１０…端末プログラム
１１２…端末ライブラリ
１４０…要求データ
１４１…ヘッダ情報
１４３…実データ
１４５…経過時間データ
２００、２００Ｂ…サーバ装置
２０２…サーバ記憶部
２０４…サーバ制御部
２０６…サーバ通信部
２０７…サーバ表示部
２１０…サーバプログラム
２２０…サーバ基本プログラム
２２２…リクエストマネージャ
２２４…サーバ通信用ライブラリ
２３０…サーバ応用プログラム
２３２…リクエストハンドラ
２４０…応答データ
２４１…ヘッダ情報
２４３…実データ
２４５…経過時間データ
３００…ホスト装置
４００…データベース
５００…アクセスポイント
６００〜６０３…ルータ
７００…ハブ

Claims (16)

1. 端末装置(100)がアクセスポイント及び／又はＬＡＮ経路を介してサーバ装置(200)と接続された無線通信システムにおいて使用される端末装置であって、
   アクセスポイント及び／又はＬＡＮ経路を介してサーバ装置(200)と無線通信可能な端末通信部(106)と、
   通信結果等を表示可能な端末表示部(107)とを備えており、
   前記端末装置(100)とサーバ装置(200)との通信経路に障害が生じていないか否かを調査するために、前記端末通信部(106)からサーバ装置(200)に対してデータを送信し、端末装置(100)とアクセスポイント及び／又はＬＡＮ経路を介したサーバ装置(200)との間で通信可能であることを確認し、かつサーバ装置(200)が端末装置(100)からの要求に対して応答することを確認する端末経路調査機能を実行可能であり、前記端末経路調査機能を実行した結果を前記端末表示部(107)に表示可能に構成してなることを特徴とする端末装置。
2. 端末装置(100)がアクセスポイント及びＬＡＮ経路を介してサーバ装置(200)と接続された無線通信システムにおいて使用される端末装置であって、
   アクセスポイント及びＬＡＮ経路を介してサーバ装置(200)と無線通信可能な端末通信部(106)と、
   通信結果等を表示可能な端末表示部(107)とを備えており、
   前記端末装置(100)とサーバ装置(200)との通信経路に障害が生じていないか否かを調査するために、前記端末通信部(106)からサーバ装置(200)に対してデータを送信し、端末装置(100)とアクセスポイントとの間、およびアクセスポイントとＬＡＮ経路を介してサーバ装置(200)との間で各々通信可能であることを確認し、かつサーバ装置(200)が端末装置(100)からの要求に対して応答することを確認する端末経路調査機能を実行可能であり、前記端末経路調査機能を実行した結果を前記端末表示部(107)に表示可能に構成してなることを特徴とする端末装置。
3. 請求項１または２に記載の端末装置であって、端末経路調査機能を実行した結果を前記端末表示部(107)に表示した後、サーバ装置(200)側から端末装置(100)に対してデータを送信し通信障害を調査するサーバ経路調査機能を行うための通信待ち受け状態に移行可能に構成してなることを特徴とする端末装置。
4. 請求項１から３のいずれかに記載の端末装置であって、前記端末経路調査機能が、各々のインターフェース間で通信が確立されたか否かに応じて個別の戻り値を記録する一以上の関数を実行し、戻り値に基づいて前記端末表示部(107)に表示されるメッセージを変化させて通信が正常であるか否かを表示可能に構成してなることを特徴とする端末装置。
5. 請求項４に記載の端末装置であって、前記端末経路調査機能が、通信が確立されたか否かの判定で通信失敗となったとき、通信の不通となっている箇所をユーザに通知することを特徴とする端末装置。
6. 一以上の端末装置(100)がアクセスポイント及び／又はＬＡＮ経路を介してサーバ装置(200)と接続された無線通信システムにおいて使用されるサーバ装置であって、
   一以上の端末装置(100)と無線通信可能なサーバ通信部(206)と、
   サーバ装置(200)で実行されるプログラムとして、前記サーバ通信部(206)を介して端末装置(100)とデータ通信するためのサーバ基本プログラム(220)と、用途に応じて編集可能なサーバ応用プログラム(230)とを実行可能なサーバ制御部(204)と、
   通信結果等を表示可能なサーバ表示部(207)と、
   を備え、
   前記サーバ応用プログラム(230)がサーバ基本プログラム(220)とのプロセス通信に障害が生じていないか否かを調査するために、前記サーバ応用プログラム(230)がサーバ基本プログラム(220)に応答を要求し、要求に対して所定の時間内に応答が得られたか否かで障害を判定するサーバ経路調査機能を実行可能であり、前記サーバ経路調査機能を実行した結果を前記サーバ表示部(207)に表示可能に構成してなることを特徴とするサーバ装置。
7. 請求項６に記載のサーバ装置であって、前記サーバ応用プログラム(230)がリクエストハンドラ(232)を含んでおり、前記サーバ基本プログラム(220)がリクエストマネージャ(222)を含んでおり、
   前記サーバ経路調査機能が実行されると、前記サーバ応用プログラム(230)がリクエストハンドラ(232)に対し、前記リクエストマネージャ(222)から反応を要求する命令を呼び出すとともに計時を開始し、リクエストマネージャ(222)から反応を受理するまでの時間を計測して、所定時間以上経過すると障害発生と判定することを特徴とするサーバ装置。
8. 請求項６または７に記載のサーバ装置であって、前記サーバ経路調査機能によってリクエストハンドラ(232)からリクエストマネージャ(222)に命令が実行されると、前記リクエストマネージャ(222)がサーバ基本プログラム(220)で端末装置(100)にデータを送信することにより、アクセスポイント及び／又はＬＡＮ経路と端末装置(100)との間の通信経路を調査可能に構成してなることを特徴とするサーバ装置。
9. 一以上の端末装置(100)がアクセスポイント及び／又はＬＡＮ経路を介してサーバ装置(200)と接続された無線通信システムにおいて、一の端末装置(100)がサーバ装置(200)との通信経路に障害が生じていないか否かを調査する通信障害調査方法であって、
   前記端末通信部(106)からサーバ装置(200)に対してデータを送信し、端末装置(100)とアクセスポイントとの間、およびアクセスポイントとＬＡＮ経路を介してサーバ装置(200)との間で各々通信可能であることを確認するステップと、
   端末装置(100)からの要求に対してサーバ装置(200)が応答することを確認するステップと、
   各ステップでの確認結果を端末装置(100)の端末表示部(107)に表示するステップと、
   を有することを特徴とする通信障害調査方法。
10. 請求項９に記載の通信障害調査方法であって、さらに結果を端末表示部(107)に表示した後、サーバ装置(200)側から端末装置(100)に対してデータを送信し通信障害を調査するサーバ経路調査機能を行うための通信待ち受け状態に移行するステップを有することを特徴とする通信障害調査方法。
11. 一以上の端末装置(100)がアクセスポイント及び／又はＬＡＮ経路を介してサーバ装置(200)と接続された無線通信システムにおいて、一の端末装置(100)がサーバ装置(200)との通信経路に障害が生じていないか否かを調査する通信障害調査方法であって、
    調査結果を記録する調査結果データを初期化するステップと、
    前記端末通信部(106)からサーバ装置(200)に対してデータを送信し、端末装置(100)とアクセスポイントとの間で通信が可能か否かを判別して判定結果を調査結果データの該当する位置に記録するステップと、
    アクセスポイントとＬＡＮ経路を介してサーバ装置(200)との間で通信が可能か否かを判別して判定結果を調査結果データの該当する位置に記録するステップと、
    サーバ装置(200)で実行されるサーバプログラム(210)と通信が可能か否かを判別して判定結果を調査結果データの該当する位置に記録するステップと、
    調査結果データに記録された情報に従い、通信障害の結果を端末表示部(107)に表示するステップと、
    を有することを特徴とする通信障害調査方法。
12. 一以上の端末装置(100)がアクセスポイント及び／又はＬＡＮ経路を介してサーバ装置(200)と接続された無線通信システムにおいて使用されるサーバ装置(200)で実行されるサーバプログラム(210)を構成するサーバ応用プログラム(230)とサーバ基本プログラム(220)との間のプロセス通信に障害が生じていないか否かを調査する通信障害調査方法であって、
    前記サーバ応用プログラム(230)がサーバ基本プログラム(220)に対して応答を要求し、所定の時間内にサーバ基本プログラム(220)から応答が得られたか否かで障害を判定するステップと、
    判定結果をサーバ装置(200)のサーバ表示部(207)に表示するステップと、
    を有することを特徴とする通信障害調査方法。
13. 一以上の端末装置(100)がアクセスポイント及び／又はＬＡＮ経路を介してサーバ装置(200)と接続された無線通信システムにおいて使用されるサーバ装置(200)で実行されるサーバプログラム(210)を構成するサーバ応用プログラム(230)とサーバ基本プログラム(220)との間のプロセス通信に障害が生じていないか否かを調査する通信障害調査方法であって、
    前記サーバ応用プログラム(230)に含まれるリクエストハンドラ(232)が、サーバ基本プログラム(220)に含まれるリクエストマネージャ(222)から反応を要求する命令を呼び出すステップと、
    前記命令が呼び出されたときから計時を開始するステップと、
    前記命令が要求する応答を所定の時間内にリクエストハンドラ(232)がリクエストマネージャ(222)から受け取ると計時を終了して正常と判定し、所定時間内に応答を受け取らない場合は異常と判定するステップと、
    判定結果をサーバ装置(200)のサーバ表示部(207)に表示するステップと、
    を有することを特徴とする通信障害調査方法。
14. 一以上の端末装置(100)がアクセスポイント及び／又はＬＡＮ経路を介してサーバ装置(200)と接続された無線通信システムにおいて通信障害を調査する方法であって、
    通信障害を調査する通信経路に存在する任意の端末装置(100)を通信の待ち受け状態とするステップと、
    前記サーバ装置(200)で実行されるサーバプログラム(210)を構成するサーバ応用プログラム(230)とサーバ基本プログラム(220)との間のプロセス通信に障害が生じていないか否かを調査するために、前記サーバ応用プログラム(230)がサーバ基本プログラム(220)に対して応答を要求し、所定の時間内にサーバ基本プログラム(220)から応答が得られたか否かで障害を判定するステップと、
    サーバ基本プログラム(220)が端末装置(100)に対して応答を要求し、所定の時間内に端末装置(100)から応答が得られたか否かでサーバ装置(200)と端末装置(100)との間の通信障害を判定するステップと、
    判定結果をサーバ装置(200)のサーバ表示部(207)に表示するステップと、
    を有することを特徴とする通信障害調査方法。
15. 一以上の端末装置(100)がアクセスポイント及び／又はＬＡＮ経路を介してサーバ装置(200)と接続された無線通信システムにおいて使用されるサーバ装置(200)で実行されるサーバプログラム(210)を構成するサーバ応用プログラム(230)とサーバ基本プログラム(220)との間のプロセス通信に障害が生じていないか否かを調査する通信障害調査方法であって、
    通信障害を調査する通信経路に存在する任意の端末装置(100)を通信の待ち受け状態とするステップと、
    前記サーバ応用プログラム(230)に含まれるリクエストハンドラ(232)が、サーバ基本プログラム(220)に含まれるリクエストマネージャ(222)から反応を要求する命令を呼び出すステップと、
    前記命令が呼び出されたときから計時を開始するステップと、
    前記命令が要求する応答を所定の時間内にリクエストハンドラ(232)がリクエストマネージャ(222)から受け取ると計時を終了して正常と判定し、所定時間内に応答を受け取らない場合は異常と判定するステップと、
    リクエストマネージャ(222)がサーバ通信部を制御して端末装置(100)に対して応答を要求し、所定の時間内に端末装置(100)から応答が得られたか否かでサーバ装置(200)と端末装置(100)との間の通信障害を判定するステップと、
    判定結果をサーバ装置(200)のサーバ表示部(207)に表示するステップと、
    を有することを特徴とする通信障害調査方法。
16. 請求項１４または１５に記載の通信障害調査方法であって、端末装置(100)の待ち受け時間を任意に設定可能としたことを特徴とする通信障害調査方法。