メッセージを表示する表示部と、衝撃や振動や落下の際の加速度の時間変化を検出する加速度センサと、所定の状況の下での加速度の時間変化のパターンを衝撃パターンとして格納する衝撃データベースと、該加速度センサが検出した加速度の時間変化が、該衝撃データベースの衝撃パターンと一致した場合に、警告メッセージを該表示部に表示させる制御部と、を備えることを特徴とする携帯端末。携帯端末と通信することによって障害が発生する状況を検出する障害検出システムであって、メッセージを表示する表示部と、衝撃や振動や落下の際の加速度の時間変化を検出する加速度センサとを備える携帯端末と、所定の状況の下での加速度の時間変化のパターンを衝撃パターンとして格納する衝撃データベースと、該加速度センサが検出した加速度の時間変化が、該衝撃データベースの衝撃パターンと一致した場合に、警告メッセージを該携帯端末の該表示部に表示させる、該携帯端末とネットワークにより接続されたサーバと、を備えることを特徴とする障害検出システム。前記衝撃データベースは、前記携帯端末に設けられることを特徴とする請求項2に記載の障害検出システム。前記衝撃データベースは、前記サーバに設けられることを特徴とする請求項2に記載の障害検出システム。前記サーバは、複数の携帯端末とネットワークにより接続され、異なる携帯端末の加速度センサが検出した加速度の時間変化が、所定時間内に所定回数、同じ衝撃パターンに一致した場合には、該サーバに接続されている該複数の携帯端末の全てに警告メッセージを表示させることを特徴とする請求項2に記載の障害検出システム。前記衝撃データベースは、事前に作成されることを特徴とする請求項2に記載の障害検出システム。前記衝撃データベースは、前記携帯端末が新たに加速度の変化を検出するごとに、エントリが追加されることを特徴とする請求項2に記載の障害検出システム。携帯端末と通信することによって障害が発生する状況を検出する障害検出システムの処理方法であって、該携帯端末に設けられた加速度センサが検出する、衝撃や振動や落下の際の加速度の時間変化を、衝撃データベースに格納された、所定の状況の下での加速度の時間変化のパターンを衝撃パターンと比較し、該加速度センサが検出した加速度の時間変化が、該衝撃データベースの衝撃パターンと一致した場合に、警告メッセージを該携帯端末の表示部に表示させる、ことを特徴とする処理方法。しかし、従来では、下記の問題が発生していた。故障返却された装置を調べても、落下衝撃の位置、方向、頻度等の詳細情報が記録されていないため、落下した根本原因の調査において破損状態の外観確認に頼ることとなり、調査に長時間を要している。小さな衝撃の蓄積による疲労は、外観に痕跡が残りにくく、障害原因が断定できないことがあった。大規模運用において、複数端末で問題が発生しても、リアルタイムの改善対策ができなかった。本発明の課題は、携帯端末の故障時の衝撃の原因を速やかに特定することの可能な携帯端末及びその障害検出システムを提供することである。本発明の一側面における携帯端末は、メッセージを表示する表示部と、衝撃や振動や落下の際の加速度の時間変化を検出する加速度センサと、所定の状況の下での加速度の時間変化のパターンを衝撃パターンとして格納する衝撃データベースと、該加速度センサが検出した加速度の時間変化が、該衝撃データベースの衝撃パターンと一致した場合に、警告メッセージを該表示部に表示させる制御部とを備える。本発明の一側面における障害検出システムは、携帯端末と通信することによって障害が発生する状況を検出する障害検出システムであって、メッセージを表示する表示部と、衝撃や振動や落下の際の加速度の時間変化を検出する加速度センサとを備える携帯端末と、所定の状況の下での加速度の時間変化のパターンを衝撃パターンとして格納する衝撃データベースと、該加速度センサが検出した加速度の時間変化が、該衝撃データベースの衝撃パターンと一致した場合に、警告メッセージを該携帯端末の該表示部に表示させる、該携帯端末とネットワークにより接続されたサーバとを備える。本発明によれば、携帯端末の故障時の衝撃の原因を速やかに特定することの可能な携帯端末及びその障害をリアルタイムに検出して携帯端末に警告表示するシステムを提供することができる。本実施形態においては、以下のような構成を備える。1予め携帯端末を様々な方向高さから落下させたり、衝撃、振動を与え、加速度とその時間変化を衝撃パターンとしてデータベース化して保持する。2上記の衝撃DBを携帯端末またはサーバに搭載し、端末の加速度を記録して衝撃DBと比較することで、落下故障時の衝撃の原因を速やかに特定する。複数の端末の衝撃検出情報をサーバに集約し、同一の故障原因の発生が複数見られた場合に、リアルタイムに全端末に改善指示を発することで、故障の予防を図る。以上によって、携帯端末の故障時の衝撃の原因を速やかに特定する。従来の衝撃分析は、障害発生装置の外観調査等により、衝撃原因の特定まで数時間を要していたが、本実施形態によれば、衝撃DBのパターン比較により、リアルタイムで衝撃原因を特定することが可能となる。また、従来では検出できなかった、小振動や小さな衝撃の蓄積による障害も、衝撃DBに振動パターンを登録しておくことで、速やかな原因特定が可能となる。また、複数の携帯端末の運用において、リアルタイムに故障の予防を図ることが可能となる。従来は、同一傾向の障害の端末が複数台修理センタに返却された後、原因の分析を行い、数日を要して運用改善の指示を行っていたが、本実施形態では、リアルタイムのスタンドアローンまたはサーバ分析により、障害発生時にリアルタイムで警告を表示できる。図1は、本実施形態に従った、スタンドアローン型携帯端末の機能ブロック構成図である。本実施形態のスタンドアローン型携帯端末9では、衝撃DB15を内蔵する。メモリ12は、携帯端末9を動作させるOS等が格納されており、CPU11がこれを実行することにより、携帯端末9を動作させる。操作部13は、携帯端末9のユーザからの入力を受け付ける。操作部13からの入力は、CPU11によって処理され、表示部10に表示される。表示部10は、商品の決済処理において発生する情報を表示する。携帯端末9には、加速度センサ14が搭載され、検出した加速度とその時間変化を衝撃パターンとして、メモリ12に格納する。データベース衝撃DB15には、予め携帯端末9の設計開発時に、テストとして、様々な衝撃や振動を与えたときの加速度とその時間変化が衝撃パターンとして予め格納されている。CPU11は、メモリ12に格納されている加速度センサ14が検出した衝撃パターンが衝撃DB15の衝撃パターンと一致するか否かを判断し、一致したものがあった場合には、衝撃DB15に衝撃パターンに対応して格納される警告メッセージを読み出し、警告表示を表示部10に表示させる。以上は、スタンドアローン型携帯端末の構成であったが、携帯端末をネットワークを介してサーバに接続する形態の障害検出システムを構成することも可能である。図2は、本実施形態に従った、サーバ接続型の障害検出システムのシステム構成図である。店員はそれぞれ1つずつ携帯端末20を保持する。携帯端末20は、アクセスポイント25を介して、ネットワーク26に接続されたサーバ21にアクセスする。この場合、衝撃DB15は、携帯端末20あるいはサーバ21に設けられる。ここでは、衝撃DB15は、サーバ21に設けられるものとして説明する。携帯端末20は、内蔵の加速度センサが検出した衝撃パターンをサーバ21に送信し、サーバ21において、検出された衝撃パターンと衝撃DBに格納された衝撃パターンの照合が行なわれる。サーバ21は、例えば、モバイルPOSシステムの場合、店舗内に配置されたり、モバイルPOSシステムの管理センターなどに配置される。図3は、サーバ接続型障害検出システムの機能ブロック構成図である。図3において、図1と同じ構成要素には同じ参照符号を付し、それらの説明を省略する。携帯端末20は、衝撃DB15を備えず、その代わりに、通信部22を備える。通信部22は、ネットワークを介して、サーバ21にアクセスする。サーバ21は、通信部23を用いて、携帯端末20と通信を行う。サーバ21は、携帯端末20から送られてくる、検出された衝撃パターンを受け取り、衝撃DB15内の衝撃パターンと照合し、一致するものがあるか否かを検出する。サーバ21は、オペレータによって監視されており、携帯端末20から送られてきた衝撃パターンと、衝撃DB15内の衝撃パターンとの一致が得られた場合には、オペレータにその旨の表示を行なう。オペレータは、サーバ21によって表示された内容から、衝撃パターンの一致を見た携帯端末20に対し、警告を発するか否かを判断する。警告を発する場合には、警告メッセージを携帯端末20に送り、表示部10に警告表示を表示させる。なお、図3においては、衝撃DB15は、サーバ21に設けられるとしたが、携帯端末20にも受けても良い。そして、携帯端末20が衝撃パターンの照合を行い、一致した場合には、衝撃パターンと共にその旨をサーバ21に通知するようにしても良い。図4は、衝撃DBに格納されるデータの例を示す図である。衝撃DBには、衝撃パターンとその衝撃パターンが得られた際の落下振動条件とを警告メッセージと対応付けたデータが格納される。落下振動条件は、携帯端末にどのような加速度、振動が加えられたかを記述するものである。このような落下振動条件において、加速度センサが検出した衝撃パターンが、対応付けられて格納される。衝撃パターンは、携帯端末を基準にした、x、y、z軸方向の加速度とその時間変化である。そして、そのような衝撃パターンを受けた際に、ユーザに取り扱い上の注意を促すための警告メッセージが格納される。例えば、No.1の衝撃パターンは、1.5mの高さから、LCD画面を下にして落下した状態で得られたものであるので、高所に持ち込むなという警告メッセージを登録している。No.2の衝撃パターンは、1.2mの高さから、LCD画面を下にして落下した状態で得られたものであるので、ストラップを付けろという警告メッセージを登録している。1.5mからの落下は、高所に置かれている場合が想定でき、1.2mからの落下は、ユーザの手から落ちたことが想定できるからである。また、No.3の衝撃パターンは、トラックに携帯端末を搭載し、砂利道を走った場合であって、携帯端末を横向きにおいた場合である。この場合には、携帯端末がクレードルに正しくは取り付けられていないために振動が起きている可能性があるので、クレードル取り付けを確認という警告メッセージが登録されている。No.4の衝撃パターンは、トラックに携帯端末を搭載し、砂利道を走った場合であって、携帯端末を縦向きに置いた場合である。この場合には、携帯端末をクレードルに取り付ける位置がおかしい可能性があるので、クレードル位置がおかしいという警告メッセージが登録されている。そのほかの例として、電池ケース部を1.3Nで殴打した場合は、丁寧に操作してくださいという警告メッセージが登録されている。このような衝撃パターンが生じたのは携帯端末を何かにぶつけた可能性が高いからである。以上のような警告メッセージは、衝撃パターンを登録する際に、作業者が落下振動条件から想定される実際の携帯端末の状況を想定して、適切と思われるメッセージを登録するようにする。図5は、携帯端末の外観図である。携帯端末30の本体は、表示画面32、入力キー33が表面に配置されており、裏面には、不図示であるが、カード読み取り器や、バーコード読み取り器などが配置されている。クレードル31は、携帯端末30を保持する筐体で、携帯端末30を使用しない場合には、携帯端末30をクレードル31に取り付けて保管する。なお、クレードル31には、携帯端末30を保持する以外に、充電機能を持っても良い。図6は、衝撃検出処理のフローチャートである。衝撃検出を開始すると、ステップS10において、現在の加速度値を収集する。ステップS11において、加速度値をメモリに書き込む。ステップS12において、過去X回Xは設計者が適宜決定するものとするの加速度ベクタx成分、y成分、z成分の組からなる加速度値を加速度ベクタと呼んでいるを含む衝撃パターンと衝撃DBの衝撃パターンをパターンマッチングする。ステップS13において、一致パターンがあるか否かを判断する。ステップS13の判断がNoの場合には、ステップS10に戻り、ステップS13の判断がYesの場合には、ステップS14に進む。ステップS14においては、衝撃DBに格納されている一致した衝撃パターンの警告メッセージを携帯端末に表示して処理を終了する。図7は、本実施形態に従った、サーバ型障害検出システムであって、サーバから複数の携帯端末に同時に警告メッセージを送出する構成のシステム構成図である。この構成例では、携帯端末20は、アクセスポイント25にアクセスし、ネットワーク26を介してサーバ21に、衝撃パターンを送信する。サーバ21は、受信した衝撃パターンと内蔵の衝撃DBの衝撃パターンとを比較し、一致するかを判断する。そして、一致した場合には、どの携帯端末からの衝撃パターンが、所定時間内に、衝撃DBのどの衝撃パターンと何回一致したかをメモリに格納する。そして、例えば、異なる携帯端末からの衝撃パターンが、衝撃DBの同じ衝撃パターンと所定回一致した場合には、そのような状況がその他の携帯端末にも生じうると判断して、全携帯端末に警告メッセージを表示させる。このようにすることにより、多くの携帯端末で発生しがちな障害を発生する状況をいち早く検知し、全携帯端末に警告を送り、障害発生を未然に防ぐことが出来る。図8は、図7の構成例のサーバ型障害検出システムの機能ブロック構成図である。図8において、図3と同じ構成要素には同じ参照符号を付し、それらの説明を省略する。図8においては、サーバ21にメモリ40サーバメモリが設けられている。メモリ40には、携帯端末20から送られてくる衝撃パターンと、衝撃DB15の衝撃パターンとのパターンマッチング結果が格納される。パターンマッチングの結果において、異なる携帯端末からの衝撃パターンが、所定時間内に所定回、衝撃DB15の衝撃パターンと一致した場合には、全携帯端末において、同様な状況が発生し、同様な障害が発生する可能性が高いと判断する。そして、そのように判断された場合には、全携帯端末に警告メッセージを表示させる。図9は、サーバメモリに格納されるデータの例を示した図である。サーバメモリのデータには、衝撃パターンの発生時刻と、衝撃パターンを送信してきた携帯端末の識別子と、一致した衝撃パターンの識別子と、一致回数と、全携帯端末への警告を行なったか否かの情報が対応付けられて格納される。図9において、端末Dからの衝撃パターンは、衝撃No.165と一致している。衝撃No.165は、端末Cからの衝撃パターンと同じであり、端末Dから衝撃パターンを受け取ったことにより、異なる端末で同じ衝撃パターンに一致した回数が2回となっている。この場合、異なる端末で同じ衝撃パターンが発生したことから、他の端末でも同様の衝撃パターンが発生する可能性が高いと判断できる。したがって、端末Dから衝撃パターンを受け取ったときに、全端末へ警告メッセージを送信し、全端末の表示画面に警告表示を行なわせる。なお、ここでは、一致を検出する際の所定時間内の所定回数として、2回を例示したが、この回数は、設計者により適宜設定されるべきものである。以上の処理により、複数の携帯端末で同様な障害が発生する状況を避けるように、ユーザに予め警告をすることが出来るので、複数の携帯端末が同じ原因により故障するということを防止することが出来る。図10は、図7の構成例におけるサーバの動作のフローチャートである。ステップS20において、携帯端末から衝撃パターンのデータを受信する。このデータを、ステップS21において、サーバメモリに書き込む。ステップS22において、過去の全てまたは指定時間内の衝撃パターンに同一パターンがあるか否かを検索する。ここで、過去の指定時間内の衝撃パターンについてのみ同一パターンの検索を行なうのは、同様の衝撃パターンが発生しても問題にならないよう既に運用改善される場合があるからである。指定時間としては、一週間とか、一ヶ月とか、店舗の売り上げの回転率などを考えて、オペレータが設定するようにする。ステップS23において、ステップS22の検索において同一パターンが見つかったか否かを判断する。ステップS23の判断がNoの場合には、ステップS20に戻る。ステップS23の判断がYesの場合には、ステップS24において、全端末へ警告メッセージを送信し、表示させて、処理を終了する。図11は、事前に衝撃DBの衝撃パターンのデータを作成する処理のフローチャートである。衝撃パターンの作成を開始すると、ステップS30において、現在の時刻、及び加速度を最終記録として保存しておく。ステップS31において、衝撃が発生すると、加速度の測定期間内であるか否かを判断する。ステップS31の判断がYesの場合には、ステップS32において、ステップS30で記録された最終記録の加速度と現在の加速度の差を比較し、ステップS33において、当該差が閾値を超えているか否かを判断する。この閾値は、測定の誤差や、問題とならない加速度の変化を取り除くためのものである。閾値の値は、設計者が予め決定しておく。ステップS33の判断がNoの場合には、ステップS31に戻る。ステップS33の判断がYesの場合には、ステップS34において、最終記録と現在の時間差、加速度を1組としてメモリに追加する。ステップS35において、現在の時刻、加速度を最終記録として保存し、ステップS31に戻る。ステップS31の判断がNoの場合には、ステップS36において、測定開始から完了までに追加した全組のデータを衝撃パターンとして衝撃DBに記録して、処理を終了する。以上の処理は、1つの衝撃パターンの作成処理なので、これを、様々な落下振動条件について繰り返すことにより、衝撃DBの衝撃パターンを蓄積する。上記処理は、衝撃DBの衝撃パターンのデータを予め蓄積しておくためのものであったが、リアルタイムに順次衝撃パターンを蓄積することも可能である。図12は、サーバ型の障害検出システムにおいて、リアルタイムで衝撃DBのデータを作成する処理のフローチャートである。図12の処理においては、特に、携帯端末がローカルに衝撃DBを持っていて、ローカルな衝撃DBに衝撃パターンをリアルタイムに格納する場合を示す。ステップS40において、現在の時刻、加速度を最終記録として保存しておく。ステップS41において、衝撃が発生すると、現在の時刻-最終記録の時刻を演算して、閾値と比較する。ステップS41において、演算値が閾値未満である場合には、ステップS42において、最終記録の加速度と現在の加速度の差を比較し、ステップS43において、差が閾値を超えているか否かを判断する。ステップS43の判断がNoの場合には、ステップS41に戻る。ステップS43の判断がYesの場合には、ステップS44において、最終記録と現在の時間差、加速度を1組として、衝撃DBに追加する。ステップS43の閾値は、図11のステップS33と同様の意味を持つものである。ステップS45においては、現在の時刻、加速度を最終記録として保存し、ステップS41に戻る。ステップS41の判断で、演算値が閾値以上であると判断された場合には、ステップS46に進む。これは、衝撃パターンの時間長の閾値以上であると判断するものである。すなわち、ステップS41の閾値は、衝撃パターンが、どのくらいの時間加速度を記録するかを設定するものである。この閾値は、設計者が適宜設定する。ステップS46においては、測定開始から完了までに追加した全組のデータを衝撃パターンとして、衝撃DBを検索する。ステップS47において、類似パターンが既にあるか否かを判断する。ステップS47の判断がNoの場合には、ステップS48において、衝撃パターンを衝撃DBに記録し、ステップS49に進む。ステップS47の判断がYesの場合には、そのままステップS49に進む。ステップS49においては、衝撃が発生したことをサーバに通知するために、衝撃パターンをサーバへ通知する。図13は、本実施形態に従ったサーバ型障害検出システムであって、サーバが衝撃DBを備える場合の衝撃DBの作成処理のフローチャートである。図13の場合は、サーバに衝撃DBが設けられている場合である。ステップS55において、現在の時刻、加速度を携帯端末から受信し、最終記録として保存しておく。ステップS56において、衝撃が発生すると、現在の時刻、加速度を携帯端末から受信する。ステップS57において、携帯端末の現在時刻-携帯端末の最終記録の時刻を演算する。ステップS57の演算値が閾値未満の場合、ステップS58に進む。ステップS58では、最終記録の加速度と現在の加速度の差を比較し、ステップS59において、差が閾値を超えているか否かを判断する。ステップS59の判断がNoの場合には、ステップS56に戻り、ステップS59の判断がYesの場合には、ステップS60に進む。ステップS59の閾値は、図12のステップS43と同様のものである。ステップS60においては、最終記録と現在の時間差、加速度を1組としてメモリに追加する。ステップS61において、現在の時刻、加速度を最終記録として保存し、ステップS56に戻る。ステップS57の判断で、演算値が、衝撃パターンの時間長の閾値以上であると判断された場合には、ステップS62に進む。ここでの閾値は図12のステップS41と同様である。ステップS62においては、測定開始から完了までに追加した全組のデータを衝撃パターンとしてメモリ内のデータを検索する。ステップS63において、類似パターンが既にあるか否かを判断する。ステップS63の判断がYesの場合には、ステップS64において、衝撃パターンをサーバに送り、衝撃DBに記録して処理を終了する。ステップS63の判断がNoの場合には、そのまま処理を終了する。図14は、衝撃データのフォーマットを説明する図である。図14aは、加速度データのフォーマットである。加速度のx、y、z成分のいずれかが閾値aを超えて変化した場合に、前回の送信したときからの経過時間と、x方向加速度値、y方向加速度値、z方向加速度値を1レコードのデータとして生成する。図14bは、例として、装置が机から落下し、数回バウンドした場合のデータ例を示している。装置が落下したときは、前回の衝撃時からかなり時間が経っているので、前回送信からの時間は例として99999としている。このとき、落下によって加速度値が0となる方向が発生している。その後、落下の衝撃により、前回送信からの時間が450のとき、x方向加速度値が大きな値を示している。その後、前回送信からの時間が3のとき、空中に装置が跳ね上がり、x方向加速度値が0となっている。前回送信からの時間が91のとき、再び衝撃が発生し、y方向加速度値が大きな値を示している。前回送信からの時間が2のとき、再び空中に装置が跳ね上がり、y方向加速度値が0となり、前回送信からの時間が20のとき、装置が床に付いて、x方向加速度値が大きな値となっている。ここで、前回送信からの時間の単位は、落下の跳ね上がり状態等を検出するためには、ミリ秒単位が好ましい。サーバ型障害検出システムの場合、携帯端末がサーバ接続時には、図14aのようなフォーマットのデータがリアルタイムにサーバに通知される。図15は、衝撃パターンのパターンマッチング処理のフローチャートである。図15において、発生した衝撃パターンが衝撃DBのどのパターンと一致するかは、パターンマッチングにより、最も類似度の高いパターンを抽出し、そのパターンの類似度が閾値を超えているかどうかで判定する。パターンマッチングのアルゴリズムは、簡易な方法として、時間/加速度値の差の絶対値の合計後述の類似度を負にしたものが最小となるパターンを選ぶ方法や、DPマッチング等の伸縮マッチング手法を用いることが出来る。ステップS70において、現在の最大類似度を0に設定する。ステップS71において、衝撃DBに残りパターンがあるか否かを判断する。ステップS71の判断がYesの場合には、ステップS72において、衝撃DBの次のパターンを読み込む。ステップS73において、発生パターンと衝撃DBから読み出した衝撃パターンの類似度を計算する。ステップS74において、類似度が最大か否かを判断する。ステップS74の判断がNoの場合には、ステップS71に戻る。ステップS74の判断がYesの場合には、ステップS75において、最大類似度の値を現在の類似度で更新し、ステップS71に戻る。ステップS71の判断がNoの場合には、ステップS76において、最大類似度が閾値以上か否かを判断する。ステップS76の判断がYesの場合には、ステップS77において、類似衝撃パターンを検出したとし、ステップS76の判断がNoの場合には、ステップS78において、類似衝撃パターンがないと判断して、処理を終了する。