客から受けた注文に係る注文データを入力して無線送信するハンディターミナルと、前記ハンディターミナルから送信された前記注文データを無線受信する無線ステーションと、前記無線ステーションからの前記注文データの受信及び指示データの送信を行うオーダリングコントローラとを含んで構成されるオーダエントリシステムにおいて使われるハンディターミナルであって、前記ハンディターミナルは、OSオペレーティングシステムデータを2つ格納するとともに、店舗での注文業務に関するアプリケーションプログラムを格納する、書き換え可能な第1の不揮発性メモリーと、前記ハンディターミナルの起動時に前記第1の不揮発性メモリーに格納されている2つのOSデータのうち、どちらのOSデータを使用して起動するかを示す、OS起動フラグを格納する、書換え可能な第2の不揮発性メモリーと、前記ハンディターミナルの電源投入後、前記OS起動フラグが示すOSデータに基づいてOSを起動して前記アプリケーションプログラムを起動するCPUとを有し、前記アプリケーションプログラムを起動した前記CPUは、起動中の前記OSデータのバージョンが最新のものであるかを、前記オーダリングコントローラに確認し、前記起動中のOSのバージョンが最新でないことを確認した場合、前記オーダリングコントローラから最新のOSデータを取得して、前記第1の不揮発性メモリーの、現在、未起動のOSデータとの書き換えを実施し、前記OSデータの書き換えが成功した場合には、前記第2の不揮発性メモリーに記憶されている前記OS起動フラグを、前記書き換えが成功したOSデータを使用して起動することを示すように書き換えることを特徴とするハンディターミナル。従来のオーダエントリシステムにおいては、ハンディターミナルが起動する際にシステム側からアプリケーションプログラムを転送している。接客担当者が同一グループの他店舗に業務支援で応援に行った場合などを考えるとその店舗にハンディターミナルが必ず余っているとは考えられない。そこで自店舗のハンディターミナルを持参する必要があるが、必ず最初にシステム側からアプリケーションプログラムを転送しなければならず仕事を開始するまでに時間がかかってしまうという問題がある。また、ハンディターミナル内のROM内に基本OSオペレーションシステム部分を持ち、アプリケーションプログラムはそれぞれの業種、業態ごとにRAMに持つ。ここで業種、業態ごととは、居酒屋やレストラン等のように事業者が異なる場合のみならず、一つチェーン店であっても和食のお店と洋食のお店のように提供するメニューが異なる場合も含む。このROM書き換え可能であっても領域をひとつしか持っていないため、基本OS部分に不具合が発見された場合、店舗でROM内のデータを更新する時に失敗してしまうとハンディターミナル自体を廃棄するか、保守拠点で特殊な方法を用いて書き換えるしか方法がないという問題がある。よって、本発明の課題は、店舗においてFROM部分のデータ更新に失敗しても再度更新できるように複数の領域を有するハンディターミナルを提供することにある。上記課題を解決するために、請求項1の発明にかかるハンディターミナルは、OSオペレーティングシステムデータを2つ格納するとともに、店舗での注文業務に関するアプリケーションプログラムを格納する、書き換え可能な第1の不揮発性メモリーFROMFlashMemory、いわゆるフラッシュメモリーと、前記ハンディターミナルの起動時に前記第1の不揮発性メモリーに格納されている2つのOSデータのうち、どちらのOSデータを使用して起動するかを示す、OS起動フラグを格納する、書換え可能な第2の不揮発性メモリーEEPROMElectricallyErasableandProgrammableROMと、前記ハンディターミナルの電源投入後、前記OS起動フラグが示すOSデータに基づいてOSを起動して前記アプリケーションプログラムを起動するCPUとを有し、前記アプリケーションプログラムを起動した前記CPUは、起動中の前記OSデータのバージョンが最新のものであるかを、前記オーダリングコントローラに確認し、前記起動中のOSのバージョンが最新でないことを確認した場合、前記オーダリングコントローラから最新のOSデータを取得して、前記第1の不揮発性メモリーの、現在、未起動のOSデータとの書き換えを実施し、前記OSデータの書き換えが成功した場合には、前記第2の不揮発性メモリーに記憶されている前記OS起動フラグを、前記書き換えが成功したOSデータを使用して起動することを示すように書き換えるものとする。これにより、バージョンアップなどの書き換え作業で失敗しても、書き換えていない正常なOS領域を使って起動できるようになる。本発明では、店舗においてFROM内のOSデータ更新を行った際に書き換えの結果をEEPROM内のOS起動フラグに反映できるので、OSデータの書き換えに失敗しても再度更新できるようになり、起動できなくなるようなことを防止することができる。図1は、本発明に係るオーダエントリシステムの特徴的な構成部分を説明するためのシステム構成図である。図1においてオーダリングコントローラ1は、無線ステーション2との間での信号の送受、ハンディターミナル3との間での信号の送受、システム全体の管理等を行うものである。ハンディターミナル3は、従業員が店舗内で常時携帯する注文入力端末で、その前面にキー入力部37及び表示部38を有しており、前記キー入力部37を操作することによって、客から受けた注文品、伝票番号、テーブル番号等の注文データを電波で送出する機能とオーダリングコントローラ1から無線ステーション2を介してメッセージを無線で受ける機能を有している。店舗の各コーナー等に複数設置された無線ステーション2は、オーダリングコントローラ1とハンディターミナル3との間で行われる信号の送受を中継する機能を有する。ハンディターミナル3を使用して他店舗へ業務支援に行った場合のフローチャートを図2に示す。ハンディターミナル3内のFROM上にあるOSに関するプログラムを更新する場合のフローチャートを図3に示す。以下に示す実施例1は前記図1及び図2を用いて説明する。ハンディターミナル3を使用して他店舗へ業務支援に行った場合は次のようになる。まず、あらかじめハンディターミナル3のAPデータ部35およびAPデータ部36に目的とするアプリケーションプログラムを書き込んでおく。ここでは通常の業務を行っている場合はAPデータ部35に格納されているアプリケーションプログラムを使用し、他店舗の業務で使用するアプリケーションプログラムはAPデータ部36に格納されているとする。ステップ1S01では、本システムでは店舗毎にシステムIDという固有の値をEEPROM39内に設定する。無線部32はシステムIDを使用して無線通信の認証を行う。従って他店舗でハンディターミナルの電源をオンにしても、システムIDが異なるために無線ステーションに接続できない。ステップ2S02では、その店舗内で使用しているハンディターミナルと持参したハンディターミナルを特殊モードにし、共通のIDを設定する。これによりハンディターミナル間で通信できるようになるので、店舗内ハンディターミナル内のシステムIDを持参したハンディターミナルにコピーする。これにより持参したハンディターミナルは店舗内での無線通信が可能になる。ステップ3S03では、ここでハンディターミナルを通常のモードに戻す。アプリケーションが起動する前にOSがEEPROM39内に格納されているアプリケーションフラグの内容を読み取る。OSはこの内容に従って任意のアプリケーションを起動する。持参したハンディターミナルはAPデータ部35に格納されているアプリケーションプログラムで起動する設定になっているのでこのフラグを書き換えてAPデータ部36で起動するようにする。設定が正常に終了した場合、リセットをしてOSからの再起動を行う。ステップ4S04では、EEPROM39内のシステムIDとアプリケーションフラグが支援する店舗と同一になったので、元々その店舗で使用していたハンディターミナルと同じアプリケーションで起動する。メニューデータ12はオーダリングコントローラ1内に格納されているので、無線通信を使って受信する。通常はここで業務を開始できるようになる。ステップ5S05では、アプリケーションプログラムは起動してすぐにオーダリングコントローラ1内に最新のアプリケーションプログラムが格納されているか確認する。もし起動したアプリケーションプログラムが最新のバージョンであればステップ7に遷移し、最新でなければステップ6に遷移する。ステップ6S06では、FROM内のアプリケーションプログラムが最新でないと判断された場合、FROMに格納するアプリケーションプログラムを受信してFROMに書き込む。ここではアプリケーションフラグがAPデータ部36内のアプリケーションプログラムを起動する設定になっているのでAPデータ部36部分に書き込むことになる。成功した場合、再起動してステップ4に遷移する。ステップ7S07では、その店舗で使用している最新のアプリケーションプログラムとメニューデータに切り替わったのでアプリケーションプログラムを使って実際の業務を開始する。このように接客担当者が他店舗に業務支援に行った場合でも、アプリケーションプログラムをダウンロードする必要なく、システムIDとアプリケーションフラグの変更だけで即座に異なる業態の店舗でも業務を開始することができるようになる。以下に示す実施例2は前記図1及び図3を用いて説明する。あらかじめハンディターミナル3のFROM内には工場出荷時には動作するOSとプログラムが格納されている。機能追加や不具合が発生した場合などにこのFROM内のOSやプログラムを書き換えることになる。ここで書き換えに失敗しても起動可能なような仕組みを説明する。ここでは説明を簡略化するためにOS格納領域を2つもつ場合とする。また、オーダリングコントローラ1には常に最新のプログラムが格納されていることとする。ステップ11S11では、ハンディターミナル3の電源が投入されるとCPU31は決められたアドレスにあるプログラムの処理を行う。これをブートローダーと呼ぶ。ブートローダーはCPU31などのレジスタを指定された値に設定し終了する。次にOSの起動を行う。起動時にOSがどのFROM内のブロックにある部分で起動するかを示すOS起動フラグを参照する。このOS起動フラグはEEPROM39内に格納されている。参照したOS起動フラグの値が1すなわちOSデータ1側に書き込まれているOSで起動する事を示していれば後述するS02の処理を行う。参照したOS起動フラグの値が2すなわちOSデータ2側に書き込まれているOSで起動する事を示していれば後述するS03の処理を行う。ステップ12S12では、OSデータ1側のOSで起動するため、CPUはOS起動処理に制御を移しOSデータ1側をマウント処理してアプリケーションプログラムを起動する。ステップ13S13では、OSデータ2側のOSで起動するため、CPUはOS起動処理に制御を移しOSデータ2側をマウント処理してアプリケーションプログラムを起動する。ステップ14S14では、アプリケーションプログラムはFROM内に格納されているOSバージョンを読み取る。そして起動したOSデータ部のバージョンが最新のものかどうかをオーダリングコントローラ1に問い合わせる。ステップ15S15では、最新の場合はここで処理を終了してアプリケーションプログラムの業務部分を起動する。ステップ16S16では、最新でない場合はFROM内のOSデータ部を書き換えるための処理を開始する。オーダリングコントローラ1内に格納されている最新のOSデータ13を無線部32を使った無線通信によってハンディターミナル3内のRAM40にダウンロードする。OSデータ1側で起動している場合には最新OSデータを起動していない側、つまりOSデータ2側に書き込む。OSデータ2側で起動している場合には最新OSデータを起動していない側、つまりOSデータ1側に書き込む。ステップ17S17書き込みに成功したか否かを確認する。ステップ18S18では、書き込みに失敗した場合、現在起動していない側のFROM部分のデータは異常になっており起動しない可能性がある。そこで再起動した場合でも次回の起動は現在動作している側である。従ってステップ1で参照しているEEPROM39内に格納されているOS起動フラグは書き換えない。ステップ19S19では、書き込み処理に成功した場合、最新のOSデータが書き込まれているのは現在起動していない側である。OSデータ1側で起動している場合にはOSデータ2側であり、OSデータ2側で起動している場合にはOSデータ1側である。従ってステップ1で参照しているEEPROM39内に格納されているOS起動フラグを参照し、1であれば2に、2であれば1に書き換える。ステップ20S20では、再起動してステップ1に遷移する。このようにハンディターミナルのFROMにOS領域を二つもち、書き換えた結果によってEEPROM内のOS起動フラグを変更することによって、書き込みに失敗した場合でもOSおよびアプリケーションプログラムの起動が可能になる。