(57)【要約】      （修正有）【課題】ＦＲＯＭ部分の書き換えに失敗しても再度更新できるように次回起動可能なハンディターミナルを提供する。【解決手段】ハンディターミナル３内のＦＲＯＭにＯＳデータ３３、ＯＳデータ３４の２つのＯＳデータ領域を持ち、ＯＳ域書き換え結果によってＥＥＰＲＯＭ３９の２つのＯＳデータのうち起動することを示すＯＳ起動フラグを、書き換えが成功したＯＳデータを使用して起動することを示すように変更して、次回の起動領域を決定する。【選択図】図１
2011138525.tif 000002
【特許請求の範囲】
【請求項１】
客から受けた注文に係る注文データを入力して無線送信するハンディターミナルと、前記ハンディターミナルから送信された前記注文データを無線受信する無線ステーションと、前記無線ステーションからの前記注文データの受信及び指示データの送信を行うオーダリングコントローラとを含んで構成されるオーダエントリシステムにおいて使われるハンディターミナルであって、
前記ハンディターミナルは、
ＯＳ（オペレーティングシステム）データを２つ格納するとともに、店舗での注文業務に関するアプリケーションプログラムを格納する、書き換え可能な第１の不揮発性メモリーと、
前記ハンディターミナルの起動時に前記第１の不揮発性メモリーに格納されている２つのＯＳデータのうち、どちらのＯＳデータを使用して起動するかを示す、ＯＳ起動フラグを格納する、書換え可能な第２の不揮発性メモリーと、
前記ハンディターミナルの電源投入後、前記ＯＳ起動フラグが示すＯＳデータに基づいてＯＳを起動して前記アプリケーションプログラムを起動するＣＰＵとを有し、
前記アプリケーションプログラムを起動した前記ＣＰＵは、
起動中の前記ＯＳデータのバージョンが最新のものであるかを、前記オーダリングコントローラに確認し、
前記起動中のＯＳのバージョンが最新でないことを確認した場合、前記オーダリングコントローラから最新のＯＳデータを取得して、前記第１の不揮発性メモリーの、現在、未起動のＯＳデータとの書き換えを実施し、
前記ＯＳデータの書き換えが成功した場合には、前記第２の不揮発性メモリーに記憶されている前記ＯＳ起動フラグを、前記書き換えが成功したＯＳデータを使用して起動することを示すように書き換える
ことを特徴とするハンディターミナル。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、レストラン、居酒屋あるいはホテル等に設置されるオーダエントリシステムで使用するハンディターミナルに関する。
【背景技術】
【０００２】
従来から、レストラン、居酒屋あるいはホテル等ではオーダエントリシステムが使用されている。例えば、無線方式を用いたオーダエントリシステムの一例を概略説明すると、接客担当者が客から料理の注文を受けた場合、携帯しているハンディターミナルに、テーブル番号等とともに注文を受けた各メニューを入力する。この入力された注文データは、前記ハンディターミナルから無線送信される。
【０００３】
前記無線送信された注文データは、店舗内の各コーナー等に設置された無線ステーションによって受信され、各種データの処理や一元管理等を行うオーダリングコントローラに出力される。前記オーダリングコントローラでは、前記注文データ及び該注文データを受信した時刻、接客担当者を識別する番号等の情報を記憶装置に記憶する。
【０００４】
そして、厨房に設置されたプリンタから調理指示用の伝票を印刷出力して、調理担当者に調理の指示を送る。また、会計用伝票がプリンタから印刷出力され、これは接客担当者により客に手渡される。調理担当者は調理指示伝票に従って調理を開始し、調理完了するとその旨を接客担当者に通知する。これにより、接客担当者は注文を受けた客に調理を運んで配膳することになる（例えば、非特許文献１参照。）。
【先行技術文献】
【非特許文献】
【０００５】
【非特許文献１】会田邦弘・浅川明著「オーダーシステムが外食産業を変える」泉文堂、１９９９年２月２０日、Ｐ１７
【発明の概要】
【発明が解決しようとする課題】
【０００６】
従来のオーダエントリシステムにおいては、ハンディターミナルが起動する際にシステム側からアプリケーションプログラムを転送している。接客担当者が同一グループの他店舗に業務支援で応援に行った場合などを考えるとその店舗にハンディターミナルが必ず余っているとは考えられない。そこで自店舗のハンディターミナルを持参する必要があるが、必ず最初にシステム側からアプリケーションプログラムを転送しなければならず仕事を開始するまでに時間がかかってしまうという問題がある。
【０００７】
また、ハンディターミナル内のＲＯＭ内に基本ＯＳ（オペレーションシステム）部分を持ち、アプリケーションプログラムはそれぞれの業種、業態ごとにＲＡＭに持つ。ここで業種、業態ごととは、居酒屋やレストラン等のように事業者が異なる場合のみならず、一つチェーン店であっても和食のお店と洋食のお店のように提供するメニューが異なる場合も含む。このＲＯＭ書き換え可能であっても領域をひとつしか持っていないため、基本ＯＳ部分に不具合が発見された場合、店舗でＲＯＭ内のデータを更新する時に失敗してしまうとハンディターミナル自体を廃棄するか、保守拠点で特殊な方法を用いて書き換えるしか方法がないという問題がある。
【０００８】
よって、本発明の課題は、店舗においてＦＲＯＭ部分のデータ更新に失敗しても再度更新できるように複数の領域を有するハンディターミナルを提供することにある。
【課題を解決するための手段】
【０００９】
上記課題を解決するために、請求項１の発明にかかるハンディターミナルは、ＯＳ（オペレーティングシステム）データを２つ格納するとともに、店舗での注文業務に関するアプリケーションプログラムを格納する、書き換え可能な第１の不揮発性メモリー（ＦＲＯＭ（Ｆｌａｓｈ  Ｍｅｍｏｒｙ、いわゆるフラッシュメモリー））と、前記ハンディターミナルの起動時に前記第１の不揮発性メモリーに格納されている２つのＯＳデータのうち、どちらのＯＳデータを使用して起動するかを示す、ＯＳ起動フラグを格納する、書換え可能な第２の不揮発性メモリー（ＥＥＰＲＯＭ（Ｅｌｅｃｔｒｉｃａｌｌｙ  Ｅｒａｓａｂｌｅ  ａｎｄ  Ｐｒｏｇｒａｍｍａｂｌｅ  ＲＯＭ））と、前記ハンディターミナルの電源投入後、前記ＯＳ起動フラグが示すＯＳデータに基づいてＯＳを起動して前記アプリケーションプログラムを起動するＣＰＵとを有し、前記アプリケーションプログラムを起動した前記ＣＰＵは、起動中の前記ＯＳデータのバージョンが最新のものであるかを、前記オーダリングコントローラに確認し、前記起動中のＯＳのバージョンが最新でないことを確認した場合、前記オーダリングコントローラから最新のＯＳデータを取得して、前記第１の不揮発性メモリーの、現在、未起動のＯＳデータとの書き換えを実施し、前記ＯＳデータの書き換えが成功した場合には、前記第２の不揮発性メモリーに記憶されている前記ＯＳ起動フラグを、前記書き換えが成功したＯＳデータを使用して起動することを示すように書き換えるものとする。
【００１０】
これにより、バージョンアップなどの書き換え作業で失敗しても、書き換えていない正常なＯＳ領域を使って起動できるようになる。
【発明の効果】
【００１１】
本発明では、店舗においてＦＲＯＭ内のＯＳデータ更新を行った際に書き換えの結果をＥＥＰＲＯＭ内のＯＳ起動フラグに反映できるので、ＯＳデータの書き換えに失敗しても再度更新できるようになり、起動できなくなるようなことを防止することができる。
【図面の簡単な説明】
【００１２】
【図１】本発明のオーダエントリシステムの特徴的な構成部分を説明するためのシステム構成図である。
【図２】ハンディターミナルを他店舗へ持っていった場合のプログラム切り替え方法を説明するフロー図である。
【図３】ハンディターミナル内のＦＲＯＭ上にあるプログラムを更新する場合を説明するフロー図である。
【発明を実施するための形態】
【００１３】
図１は、本発明に係るオーダエントリシステムの特徴的な構成部分を説明するためのシステム構成図である。
【００１４】
図１においてオーダリングコントローラ１は、無線ステーション２との間での信号の送受、ハンディターミナル３との間での信号の送受、システム全体の管理等を行うものである。
【００１５】
ハンディターミナル３は、従業員が店舗内で常時携帯する注文入力端末で、その前面にキー入力部３７及び表示部３８を有しており、前記キー入力部３７を操作することによって、客から受けた注文品、伝票番号、テーブル番号等の注文データを電波で送出する機能とオーダリングコントローラ１から無線ステーション２を介してメッセージを無線で受ける機能を有している。
【００１６】
店舗の各コーナー等に複数設置された無線ステーション２は、オーダリングコントローラ１とハンディターミナル３との間で行われる信号の送受を中継する機能を有する。
【００１７】
ハンディターミナル３を使用して他店舗へ業務支援に行った場合のフローチャートを図２に示す。
【００１８】
ハンディターミナル３内のＦＲＯＭ上にあるＯＳに関するプログラムを更新する場合のフローチャートを図３に示す。
【００１９】
以下に示す実施例１は前記図１及び図２を用いて説明する。
【実施例１】
【００２０】
ハンディターミナル３を使用して他店舗へ業務支援に行った場合は次のようになる。
まず、あらかじめハンディターミナル３のＡＰデータ部３５およびＡＰデータ部３６に目的とするアプリケーションプログラムを書き込んでおく。ここでは通常の業務を行っている場合はＡＰデータ部３５に格納されているアプリケーションプログラムを使用し、他店舗の業務で使用するアプリケーションプログラムはＡＰデータ部３６に格納されているとする。
【００２１】
ステップ１（Ｓ０１）では、本システムでは店舗毎にシステムＩＤという固有の値をＥＥＰＲＯＭ３９内に設定する。無線部３２はシステムＩＤを使用して無線通信の認証を行う。従って他店舗でハンディターミナルの電源をオンにしても、システムＩＤが異なるために無線ステーションに接続できない。
【００２２】
ステップ２（Ｓ０２）では、その店舗内で使用しているハンディターミナルと持参したハンディターミナルを特殊モードにし、共通のＩＤを設定する。これによりハンディターミナル間で通信できるようになるので、店舗内ハンディターミナル内のシステムＩＤを持参したハンディターミナルにコピーする。これにより持参したハンディターミナルは店舗内での無線通信が可能になる。
【００２３】
ステップ３（Ｓ０３）では、ここでハンディターミナルを通常のモードに戻す。アプリケーションが起動する前にＯＳがＥＥＰＲＯＭ３９内に格納されているアプリケーションフラグの内容を読み取る。ＯＳはこの内容に従って任意のアプリケーションを起動する。持参したハンディターミナルはＡＰデータ部３５に格納されているアプリケーションプログラムで起動する設定になっているのでこのフラグを書き換えてＡＰデータ部３６で起動するようにする。設定が正常に終了した場合、リセットをしてＯＳからの再起動を行う。
【００２４】
ステップ４（Ｓ０４）では、ＥＥＰＲＯＭ３９内のシステムＩＤとアプリケーションフラグが支援する店舗と同一になったので、元々その店舗で使用していたハンディターミナルと同じアプリケーションで起動する。メニューデータ１２はオーダリングコントローラ１内に格納されているので、無線通信を使って受信する。通常はここで業務を開始できるようになる。
【００２５】
ステップ５（Ｓ０５）では、アプリケーションプログラムは起動してすぐにオーダリングコントローラ１内に最新のアプリケーションプログラムが格納されているか確認する。もし起動したアプリケーションプログラムが最新のバージョンであればステップ７に遷移し、最新でなければステップ６に遷移する。
【００２６】
ステップ６（Ｓ０６）では、ＦＲＯＭ内のアプリケーションプログラムが最新でないと判断された場合、ＦＲＯＭに格納するアプリケーションプログラムを受信してＦＲＯＭに書き込む。ここではアプリケーションフラグがＡＰデータ部３６内のアプリケーションプログラムを起動する設定になっているのでＡＰデータ部３６部分に書き込むことになる。成功した場合、再起動してステップ４に遷移する。
【００２７】
ステップ７（Ｓ０７）では、その店舗で使用している最新のアプリケーションプログラムとメニューデータに切り替わったのでアプリケーションプログラムを使って実際の業務を開始する。
【００２８】
このように接客担当者が他店舗に業務支援に行った場合でも、アプリケーションプログラムをダウンロードする必要なく、システムＩＤとアプリケーションフラグの変更だけで即座に異なる業態の店舗でも業務を開始することができるようになる。
【実施例２】
【００２９】
以下に示す実施例２は前記図１及び図３を用いて説明する。
【００３０】
あらかじめハンディターミナル３のＦＲＯＭ内には工場出荷時には動作するＯＳとプログラムが格納されている。機能追加や不具合が発生した場合などにこのＦＲＯＭ内のＯＳやプログラムを書き換えることになる。ここで書き換えに失敗しても起動可能なような仕組みを説明する。
【００３１】
ここでは説明を簡略化するためにＯＳ格納領域を２つもつ場合とする。また、オーダリングコントローラ１には常に最新のプログラムが格納されていることとする。
【００３２】
ステップ１１（Ｓ１１）では、ハンディターミナル３の電源が投入されるとＣＰＵ３１は決められたアドレスにあるプログラムの処理を行う。これをブートローダーと呼ぶ。ブートローダーはＣＰＵ３１などのレジスタを指定された値に設定し終了する。次にＯＳの起動を行う。起動時にＯＳがどのＦＲＯＭ内のブロックにある部分で起動するかを示すＯＳ起動フラグを参照する。このＯＳ起動フラグはＥＥＰＲＯＭ３９内に格納されている。参照したＯＳ起動フラグの値が１すなわちＯＳデータ１側に書き込まれているＯＳで起動する事を示していれば後述するＳ０２の処理を行う。参照したＯＳ起動フラグの値が２すなわちＯＳデータ２側に書き込まれているＯＳで起動する事を示していれば後述するＳ０３の処理を行う。
【００３３】
ステップ１２（Ｓ１２）では、ＯＳデータ１側のＯＳで起動するため、ＣＰＵはＯＳ起動処理に制御を移しＯＳデータ１側をマウント処理してアプリケーションプログラムを起動する。
【００３４】
ステップ１３（Ｓ１３）では、ＯＳデータ２側のＯＳで起動するため、ＣＰＵはＯＳ起動処理に制御を移しＯＳデータ２側をマウント処理してアプリケーションプログラムを起動する。
【００３５】
ステップ１４（Ｓ１４）では、アプリケーションプログラムはＦＲＯＭ内に格納されているＯＳバージョンを読み取る。そして起動したＯＳデータ部のバージョンが最新のものかどうかをオーダリングコントローラ１に問い合わせる。
【００３６】
ステップ１５（Ｓ１５）では、最新の場合はここで処理を終了してアプリケーションプログラムの業務部分を起動する。
【００３７】
ステップ１６（Ｓ１６）では、最新でない場合はＦＲＯＭ内のＯＳデータ部を書き換えるための処理を開始する。オーダリングコントローラ１内に格納されている最新のＯＳデータ１３を無線部３２を使った無線通信によってハンディターミナル３内のＲＡＭ４０にダウンロードする。ＯＳデータ１側で起動している場合には最新ＯＳデータを起動していない側、つまりＯＳデータ２側に書き込む。ＯＳデータ２側で起動している場合には最新ＯＳデータを起動していない側、つまりＯＳデータ１側に書き込む。
【００３８】
ステップ１７（Ｓ１７）書き込みに成功したか否かを確認する。
【００３９】
ステップ１８（Ｓ１８）では、書き込みに失敗した場合、現在起動していない側のＦＲＯＭ部分のデータは異常になっており起動しない可能性がある。そこで再起動した場合でも次回の起動は現在動作している側である。従ってステップ１で参照しているＥＥＰＲＯＭ３９内に格納されているＯＳ起動フラグは書き換えない。
【００４０】
ステップ１９（Ｓ１９）では、書き込み処理に成功した場合、最新のＯＳデータが書き込まれているのは現在起動していない側である。ＯＳデータ１側で起動している場合にはＯＳデータ２側であり、ＯＳデータ２側で起動している場合にはＯＳデータ１側である。従ってステップ１で参照しているＥＥＰＲＯＭ３９内に格納されているＯＳ起動フラグを参照し、１であれば２に、２であれば１に書き換える。
【００４１】
ステップ２０（Ｓ２０）では、再起動してステップ１に遷移する。
【００４２】
このようにハンディターミナルのＦＲＯＭにＯＳ領域を二つもち、書き換えた結果によってＥＥＰＲＯＭ内のＯＳ起動フラグを変更することによって、書き込みに失敗した場合でもＯＳおよびアプリケーションプログラムの起動が可能になる。
【符号の説明】
【００４３】
１    オーダリングコントローラ
２    無線ステーション
３    ハンディターミナル
１１  オーダーコントロール・ソフトウェア
１２  メニューデータ
１３  ハンディターミナル用最新ＯＳデータ
２１  データ転送ソフトウェア
２２  無線制御ソフトウェア
３１  ＣＰＵ
３２  無線制御部
３３  ＯＳデータ部１
３４  ＯＳデータ部２
３５  ＡＰデータ部１
３６  ＡＰデータ部２
３７  キー入力部
３８  表示部
３９  ＥＥＰＲＯＭ
４０  ＲＡＭ
【図１】
2011138525.tif 000003
【図２】
2011138525.tif 000004
【図３】
2011138525.tif 000005