(57)【要約】飲食サービス施設において、顧客が、各自で電子的に献立注文を出し、支払いを済ませ、また前記の注文を処理する双方向システムを公開する。この発明には、少なくとも１台の発注機が含まれ、この発注機は、携帯機器または薄型で電池式のタッチ式端末のいずれかで、どちらもデータ入力機器、表示画面、無線通信装置を含み、前記献立注文と支払いの処理には、1台以上のサーバを有し、また、テキストと、もしくは 画像つきリストから選択するか、献立品目に一致するコードを入力するいずれかの手段を使って、献立品目を注文に追加する手段、前記飲食サービス施設のひとつ以上の食品調理場に、前記注文を無線送信する手段、前記現金不要支払い媒体を使って、支払いを受納する手段、この現金不要支払い媒体には、クレジットカード、デビットカード、スマートカード、プリペイドカードまたは他の非現金支払いシステムが適応され、また前記携帯機器が、前記の現金不要支払い媒体を利用して前記献立品目の支払いをする手段、この現金不要支払い媒体には、携帯電話ゲートウェイ接続業者またはインターネット接続業者の支払い体系が含まれ、また、食事代金を支払い、献立品目の注文を統括する食事会の責任者を識別する手段、顧客の報奨ポイントを一括する手段、システムを介してクーポンまたはプレミアムを提示し受け付け、請求書に算出する手段、また献立品目を閲覧し先行注文する手段、自動的に空席状況を検索し、席を予約する手段、前記端末からグローバル・コンピュータ・ネットワークにアクセスする手段、割引や特別サービスを精力的に顧客に提供する手段、注文を一括して処理するために、注文を仕分けし、品目を受注しやすい従業員に送り、品目をグループに分類する手段が含まれる。
2005527017.tif 000002
【特許請求の範囲】
【請求項１】
食品サービス施設において、顧客が出す献立注文を管理する双方向システムであって、前記注文に献立品目を追加することにより、顧客が前記注文を自分で出すことができる少なくとも1台の発注機と、前記注文を処理し転送する少なくとも１台のサーバと、前記発注機から送られてくる当該注文を、前記飲食サービス施設内の一箇所以上の食品調理場に無線送信する手段と、前記注文の進捗管理と支払い状況の追跡手段とを備え、前記献立注文は、食品、飲み物及び関連する品目を含み、前記発注機は、薄型のタッチ式端末または携帯機器で、どちらも組み込み表示画面、データ入力機能、データを無線で転送する機能を有し、コードレスで電力供給が可能な自立した発注機であり、更に現金不要支払い媒体を利用し、端末または携帯機を介して、当該顧客注文の支払いを受納する手段を含む双方向システム。
【請求項２】
前記現金不要支払い媒体は、クレジットカード、デビットカード、スマートカード及びプリベートカードに制限されず、前記携帯機を使って支払いをする顧客にとっては、前記顧客の携帯電話ゲートウェイ、インターネット接続業者または第三機関の支払い業者の支払い機構が含まれる請求項１に記載のシステム。
【請求項３】
更に、テキストまたは画像付きリストから献立品目を選択することにより、前記注文に前記献立注文を追加する手段を含む請求項１に記載のシステム。
【請求項４】
前記携帯機器を使って前記献立品目に一致する品目コードを入力することにより、前記注文に当該献立注文を追加する手段を含む請求項１に記載のシステム。
【請求項５】
食事代金の支払いと注文を管理する、団体幹事を識別する手段を含む請求項１に記載のシステム。
【請求項６】
前記端末または前記携帯機を介して、顧客の報奨ポイントを統合する手段と、割引券、クーポン、販売促進商品の引き換えを可能にする手段を含む請求項１に記載のシステム。
【請求項７】
前記携帯機器または前記第2の端末を使って、顧客は献立品目を閲覧し、事前注文できるようにする手段を含む請求項１に記載のシステム。
【請求項８】
前記食品サービス施設において、顧客が自動的に空席状況を検索し、席を予約できる手段を含む請求項１に記載のシステム。
【請求項９】
前記端末は、グローバルコンピュータネットワークに接続しており、エンドユーザーが、インターネット、ウエブサイト、ニュース、エンターテインメント及び他の情報へのアクセスが可能である請求項１に記載のシステム。
【請求項１０】
献立品目についた特別割引やサービスだけでなく、更新した献立表もリアルタイムで前記顧客に提供する手段を含む請求項１に記載のシステム。
【請求項１１】
更に、紙のもしくは電子領収書を発行する手段を含み、後者の領収書は、電子メールまたは電子的な手段で、前記顧客宛て、または該顧客が指定した宛先に送られる領収書である請求項１に記載のシステム。
【請求項１２】
更に、チップ及び心づけの支払いを促進する手段を含む請求項１に記載のシステム。
【請求項１３】
更に、顧客からのフィードバックや評価を提出する手段を含む請求項１に記載のシステム。
【請求項１４】
更に、指定された言語に一致する言語で画面を表示する手段を含む請求項１に記載のシステム。
【請求項１５】
更に、前記飲食サービス施設が、現金支払いを処理する手段を含む請求項１に記載のシステム。
【請求項１６】
更に、前記注文を仕分けし、前記注文に含まれる個人の献立品目を、最も処理しやすい従業員の前記端末に送信する手段を含む請求項１に記載のシステム。
【請求項１７】
更に、前記従業員によりまだ処理されていない前記個人の献立品目を、一括して処理するために、同じグループに分類する手段を含む請求項１に記載のシステム。
【請求項１８】
飲食サービス施設において、顧客が発注する献立注文を管理する顧客基盤の双方向システムであって、前記施設内のテーブルに取り付けられ、食品、飲み物及び他の関連品目が含まれた献立品目に対応しデータを表示可能なタッチ式画面を含むデータ入力機能を備え、中央サーバからアクセスが可能な、少なくとも１台の電池式端末と、前記献立品目を前記端末から前記食品サービス施設に無線で送信し、前記献立品目に含まれる個人の献立品目を、前記食品サービス施設内の適当な場所に伝送する手段と、クレジットカード、デビットカードまたは他の現金不要支払い媒体を受け付けることがきるように前記端末に備えられている支払いを受納手段とを含み、これによりこのシステムによってクーポンやプレミアムを提示し、承認し、請求書に算出する手段を含む顧客基盤の双方向システム。
【請求項１９】
更に、エンドユーザーが献立品目を読み、先行注文し、席を確保することができる第２の端末を含む請求項１８に記載のシステム。
【請求項２０】
更に、各テーブルで、相対する会席を調整する手段を含む請求項１８に記載のシステム。
【請求項２１】
更に、食事代金の支払いと献立品目の注文を承認する立場にある食事会の責任者を識別する手段を含む請求項１８に記載のシステム。
【請求項２２】
前記端末は、更に、グローバルコンピュータネットワークへ接続しており、エンドユーザーが、インターネットウエブサイト、ニュース、エンターテイメント及び他の情報源にアクセスを可能にすることを特徴とする、請求項１８に記載のシステム。
【請求項２３】
更に、献立品目についた特別割引やサービスだけでなく、更新された献立表をリアルタイムで前記顧客に提供する手段を含む請求項１８に記載のシステム。
【請求項２４】
前記飲食サービス施設が、更に、現金支払いを処理する手段を含む請求項１８に記載のシステム。
【請求項２５】
飲食サービス施設において、顧客が出す注文を管理する顧客基盤の双方向システムであって、前記飲食サービス施設のテーブルに取り付けられた少なくとも１台の電池式端末であって、この端末には、データ入力機能が付いており、更に端末に電気で接続されたタッチ式モニターを含み、デジタル方式でアクセスが可能で、献立品目に一致する画像を表示することができる前記端末と、前記端末が作動しない、または当該端末の電池の交換が必要になった時に、前記飲食サービス施設に警告する手段と、前記注文の支払いと前記献立品目の注文を承認する食事会の責任者を識別する手段と、前記献立注文を前記端末から前記飲食サービス施設に無線で送信し、当該献立注文に含まれる個々の献立品目を食品サービス施設内の適当な場所に伝送する手段と、支払いを受納する端末に備え付けられる手段と、これにはクレジットカード、デビットカードまたは他の非現金支払いシステムに適合する手段が含まれ、このシステムを介して、クーポンとプレミアムを提示し、承認し、請求書に算出する手段、とを備え、前記献立品目には、食品、飲み物及び他の関連品目が含まれる、顧客基盤の会話型システム。
【請求項２６】
飲食サービス施設が、更に現金の支払いを処理する手段を含む請求項２５に記載のシステム。
【請求項２７】
飲食サービス施設において、顧客が自分で注文を出し、支払いをする双方向システムであって、少なくともひとりの顧客が所持する無線携帯通信機器と、前記注文を処理し転送する少なくとも１台のサーバと、前記注文を、前記携帯通信機器から１台または複数のサーバに無線で、食品サービス施設内の一箇所以上の食品調理場に送る手段と、前記注文の進捗管理と支払い状況の追跡手段とを含み、この献立注文は、食品、飲み物及び他の関連品目が含まれ、前記注文は、前記携帯通信機器を介して発注され、前記注文への献立品目の追加は、前記献立品目のコードを入力するか前記携帯通信機器に表示されたテキストか画像入りリストから選択することができ、前記注文は、携帯通信機器を介して支払われ、顧客の現金不要支払い媒体の情報をサーバに転送する、顧客の携帯電話ゲートウェイ業者のアカウントに請求する、または第三機関支払い業者を介して処理するように構成されている双方向システム。
【請求項２８】
クレジットカード、デビットカード、スマートカード、プリペイドカードに制限されない前記の現金不要支払い媒体を含む請求項２７に記載のシステム。
【請求項２９】
食事代金の支払いと注文を管理する食事会の責任者を識別する手段を含む請求項２７に記載のシステム。
【請求項３０】
更に、前記携帯通信機器を介して、顧客の報奨ポイントを統合し、割引券、クーポン及び販売促進商品を引き換える手段を含む請求項２７に記載のシステム。
【請求項３１】
更に、前記携帯通信機器を使って、顧客が献立品目を閲覧し、先行注文できる手段を含む請求項２７に記載のシステム。
【請求項３２】
更に、顧客が、前記飲食サービス施設において、自動的に空席状況を検索し、席を予約できる手段を含む請求項２７に記載のシステム。
【請求項３３】
更に、献立品目についた特別割引やサービスだけでなく、更新された献立表をリアルタイムで前記顧客に提供する手段を含む請求項２７に記載のシステム。
【請求項３４】
更に、紙と、もしくは電子領収書を発行する手段を含んでおり、前記電子領収書は、前記顧客宛て、または顧客が指定した他の宛先に電子メールまたは電子的な手段で送られる領収書である請求項２７に記載のシステム。
【請求項３５】
更に、チップ及び心づけの支払いを促進する手段を含む請求項２７に記載のシステム。
【請求項３６】
更に、顧客からのフィードバック及び評価を提出する手段を含む請求項２７に記載のシステム。
【請求項３７】
更に、前記飲食サービス施設が、現金支払いを処理する手段を含む請求項２７に記載のシステム。
【請求項３８】
更に、前記注文を仕分けし、前記注文に含まれる個人の献立品目を、最も処理しやすい従業員の前記端末に送り、個人の献立品目を処理する手段を含む請求項２７に記載のシステム。
【請求項３９】
更に、前記従業員によってまだ処理されていない前記個人の献立品目を、一括して処理するために、その献立品目を団体に分類する手段を含む請求項２７に記載のシステム。
【請求項４０】
飲食サービス施設において、顧客が自分で献立品目を注文し、支払いをすることができる双方向システムであって、少なくとも１人の顧客が持つ無線携帯電話器と、前記注文を受注し転送する少なくとも１台のサーバと、前記携帯電話機器から前記の１台または複数のサーバに前記注文を無線送信し、前記注文を食品サービス施設内の一箇所以上の食品調理場に伝送する手段と、前記注文の進捗管理と支払い状況の追跡手段戸を含み、献立項目には、食品、飲み物及び他の関連品目が含まれ、前記注文は、前記携帯電話機器を介して発注され、献立品目を前記注文に追加するためには、当該携帯電話機器に献立品目コードを入力するか、表示されたテキストまたは画像入りのリストから献立品目を選択する手段が可能で、前記注文は、前記携帯通信機器を介して支払われ、顧客の現金不要支払い媒体の情報をサーバに転送し、顧客の携帯電話ゲートウェイ接続業者のアカウントに請求する、または第三機関支払い接続業者を介して処理される用に構成されている双方向システム。
【請求項４１】
前記現金不要支払い媒体は、クレジットカード、デビットカード、スマートカード、プリペイドカードに制限されない任意の支払い媒体である請求項４０に記載のシステム。
【請求項４２】
更に、前記携帯電話機器を介して、顧客の報奨ポイントを統合し、割引券、クーポン及び販売促進商品の引き換える手段を含む請求項４０に記載のシステム。
【請求項４３】
更に、前記携帯電話機器を使って、顧客が献立品目を閲覧し、先行注文できる手段を含む請求項４０に記載のシステム。
【請求項４４】
更に、飲食サービス施設が、現金支払いの処理ができる手段を含む請求項４０に記載のシステム。
【請求項４５】
注文を仕分けし、前記注文に含まれる個人の献立品目を最も処理しやすい従業員（システムを含む）の端末に送り、前記従業員によってまだ処理されていない前記個人の献立品目を、一括して処理するために、個人の献立品目を団体に分類する方法。
【請求項４６】
自立した電源と、ユーザーが入力するタッチ式画面と、現金不要支払い媒体から入力できる入力手段と、データを他機器に無線送信する手段とを含み、前記電源は、前記端末の作業時間を延長する目的で電池２つが含まれ、前記端末は、前記電池式電源に付いた電池2つのうちのひとつを交換する間、支障なく作動することが可能で、前記端末装置は、セキュリティー体系と設計の向上を目指すことで、不正なアクセスを防ぎ、端末装置が盗難にあうような要因を払拭して公共の場で使用でき、クレジットカード、デビットカード、スマートカード、プリペイドカードに制限されない、前記の現金不要支払い媒体が使用できる端末。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、食事注文、食事品の準備処理、支払いを促進し、顧客の全体的なレストラン及びその他の飲食サービス施設における体験を改善するという分野に関する。特に、この発明は、一つまたはそれ以上のサーバに無線で接続された、薄いタッチ式画面端末と携帯機を含有し、顧客が自分自身で迅速に、効率よく食事の注文及び支払いができるシステムに関する。
【背景技術】
【０００２】
最近の傾向として、レストラン業界で労働者不足が見られてきている。１９７０年以来、米国では、１０代の若者及び働いている中高生の数が減少している。全国のレストラン産業連合の２０００年レストラン業界予告によると、「テーブルサービスのレストランや、クイックサービスのレストランは、資格があり、やる気のある従業員を探すのが非常に困難で、この現象は、ますます悪くなると思われる」と報告している。また、米国労働統計局によると、レストラン産業は、２０１０年までに、更に２百万人の従業員が必要であると報告している。その上、ウエイターやウエイトレスが長続きしない率が高いことが問題を大きくしている。事実上、１９９８年には、完全サービスのレストラン等施設では、従業員の交代率が（レストランのタイプによって違うが）８３−８５％であった。この傾向に対処するため、レストランのいくつかは、従業員の労働時間を減らし始め、どんどんとオートマチックなシステムに頼り始めた。
【０００３】
レストラン及び他の飲食サービス施設は、従業員不足だけでなく、従業員の給料増加を心配している。民間の労働費用は、この１０年間に非常に増加して、労働コスト指数が２０００年には４．４％増え、民間の賃金は３．９％増加した。事実上、レストランで顧客が払った金額から、３０％は給料や賃金となり、５％が従業員の年金等の福祉用基金になる。即ち、合計として、支払い金額の３５％が労働費用となる。更に、飲食料業界では、管理者以外の賃金が、民間全体の賃金より急速に増加し続けている。この労働者団体の時給が、２０００年の７月までには、年間に、４．５％増加した。このより高い給料、賃金と年金等の従業員福祉費が、レストランの運用費を非常に増加させた。もしこの傾向が続き、レストランの料金がそれに応じて向上しないと、この労働者経費のために、レストランの税込み収入と利益が減少し続ける。
【０００４】
レストラン及び飲食サービス産業では、常連客を確保し、新しい顧客をつかもうと、常に業界で競争している。この飲食サービス産業界で生き延びる為には、新しい技術を使って、問題解決をする重要性が出てきているのは明らかである。また、顧客は娯楽性も求めてきている。この非常に競争し合う環境で生き延びるには、レストラン及び食事施設は、単なる食事経験以上の物を、顧客に供給する必要がある。その他の飲食サービス業界でも同じことがあてはまる。
【０００５】
顧客は、いろいろと知識を得てきて、飲食サービス店（特にレストラン）の従業員から、高いレベルの知識やサービスを期待してきている。ウエイターやウエイトレスは、更に教育訓練を受け、一緒になって顧客の接待を良くする必要がある。その為には、飲食サービス店負担の従業員教育訓練が更に必要になり、結果的に、顧客の支払い金額が増加することになる。
【０００６】
別な傾向として、ある飲食サービス店（特にレストラン）の従業員が、顧客の支払いのクレジットカードの情報を盗む、スキミングが起きている。このスキミングとは、従業員が顧客が見てない時に、ベルトに付けた小さな機器を使って、顧客のクレジットカードを差込みその情報を盗むやり方である。このような報告が、レストラン及び他の飲食サービス業界に厄介な影響を与え、顧客の信用を失う原因となっている。
【０００７】
また、統計によると、以前より多くの人が、外食するようになってきている。事実上、外食（レストラン及び他の飲食サービス施設で）する人の割合が、１９５５年の２５％から２００１年の４６％に伸び、２０１０年には５３％に達成すると予測されている。更にある国々では、仕事のスケジュールや生活スタイル、文化習慣等の為、外食するのがより普通となっている。
【０００８】
国際化がまた、レストラン及び他の飲食サービス店産業に非常に強い影響を及ぼしている。多くの人々が海外旅行するようになり、外国客にその人の言葉でサービスする必要性が出て来ている。
【０００９】
レストラン業界の一部は、テーブルの上に注文用スクリーンを置くのは、顧客に負担をかけすぎであり、人間性に欠けると思っている。しかしながら、我々は、日常生活で、最新技術を使うのに慣れてきており、例としては、電子メールの使用が１０年前に比べて急増していることがあげられる。更に、最新技術を使うことにより、人間ではなくとも、人間的な双方向関係を保つことは可能である（例、使い易さ、オンラインヘルプ、困ったときに従業員を呼ぶ機能）。大抵の場合、顧客が簡単に食品を自分で注文でき、本当に必要な時だけ人間の介入が必要とされる、システムを設計することが可能である。大抵の顧客は、自分たちの会話中、ウエイターやウエイトレスに邪魔されたくなく、必要な時だけ簡単にウエイターやウエイトレスを呼べれる方が良いのである。
【００１０】
顧客の立場からの観察
国内外のレストラン及び飲食サービス施設を訪れることにより、いくつかの観察報告が作成された。まず第一に、顧客の待ち時間が多いことである。注文するのに待ち、食事が来るのを待ち、支払いするのに待つ。顧客の待ち時間は、担当の従業員が、自分の役割をいかに効率よく果たすかによって変わる。従業員の役割（注文を取る、支払いを受ける、座席案内等）が増えたり、顧客数が増えると、ますます顧客の待ち時間が増える。また、レストランでは、従業員が料理に関する質問に答えられず、他の従業員やシェフ（料理人、コック）に質問をしたりして時間を無駄にすることもよくある。注文をミスしたり、忘れたりすると更に顧客を待たせることになる。顧客が従来以上に忙しいことを考慮すれば、迅速で効率がよく、待ち時間の少ないサービスを期待するのは当然である。以上が、今日の飲食サービス業界における、注文から支払いまでの作業遂行過程における主要な効率の悪さと、顧客における多大な不便さである。
【００１１】
また、別の観察によると、レストランやその他の飲食業設備において顧客は、もし特定の料理が初めて注文する料理だと、それがどんな料理かわからない。大抵のメニューには、顧客によりよい情報を提供するような料理の詳しい説明や絵は含まれていない。特に、休暇や会社の出張で、外国のレストランや飲食サービス店で料理の注文をする時に、顧客は嫌な思いをする。初めての訪れる国に行ったり、その国の言葉を話せないと、大変な試みと耐え難い屈辱の体験となる。
【００１２】
最新技術の普及と、デビットカード、クレジットカード、スマートカード等の現金不要支払い媒体が増加したことで、効率の悪さは簡単に排除でき、価値あるサービスを提供することができる。このような最先端の技術を使うことにより、飲食業者の費用大削減が可能で、常連客を確保し、新しい顧客を誘うことができる。またこれにより、仕事に熟練し、長続きする従業員を見つけられないという、オーナーや管理者の恐れも無くなる。その上、レストランや飲食サービス業界は、最新の技術を取り入れたサービスにより、顧客の全体的な体験を劇的に改善する。
【００１３】
特許文献にある、いくつかの発明（米国特許５，２３５，５０９、４，５３０，０６７、５，００３，４７２、５，８４５，２６３）は、注文処理の改善を試みたが成功はしなかった。米国特許５，８４５，２６３は、顧客と店舗間の相互作用を取り入れた、視覚的注文システムで、他の発明の中では一番高度の発明で、試みは非常によかったが、特に具体化した実施遂行の運用法で最適の解決法をだせなかった。
【００１４】
最初の論争点は、顧客の注文用装置の構成であり、それは２つの別々なハードウエア（つまり、コンピュータとビデオモニター）、から成り立っている。レストランや食事施設のテーブルの上に、コンピュータと付属モニターを置くのは、現実的でなく、顧客のテーブルの場所を取り、顧客が料理を食べる時の邪魔にもなる。その上、モニター付コンピュータは電気コンセントが２つ（コンピュータ用の電気コードと、モニター用の電気コード）必要になる。ラップトップコンピュータを使用しても電気コンセントが１つ必要である。しかしながら、大抵のレストランのテーブルには、電気コンセントが付いていない。レストランのテーブル１つ１つに電気コンセントを取り付ける工事には多額の金額がかかる。テーブルに電気コンセントが付いていたとしても、コンピュータ（及びモニター）からつながった電気コードが、顧客の邪魔になり、偶然に電気コードが、外れた場合、顧客に危険を与え、システムも使用不可能になる。
【００１５】
ソフトウエアに関しては、このシステムはＭｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓのオペレーティング・システム（ＯＳ）で作動する。更に、サーバとサーバにつながった１つ１つのコンピュータはＭｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓ  ＯＳを使用する免許が必要であり、システム全体の費用が非常に増加し、レストランのオーナーや食事施設の持ち主にとって、この免許の管理が大きな負担となる。
【００１６】
米国特許５，８４５，２６３によって提案されたシステムは、システムがクラッシュした時どう処理するかとの重要な問題を適切に対処していない。レストランのオーナーや食事施設のオーナーは、多額の金額を投資をしたビジネスを完全に左右するいかなるテクノロジーも、フェイルセイフ（安全にシステムダウンする）の機能を持ち、システムダウンをできるだけ防ぎまたは最小限にすることを確認する必要がある。
【００１７】
米国特許５，８４５，２６３のシステム機能は、単なる注文設定にとどまり、注文処理と統合すべき支払い方法の処理を対処していない。注文処理と支払い処理が統合されてないと、注文した食事品が支払われたかどうか、わからず、レストランでは、顧客が帰る前に勘定を支払ったかどうか、調べようがない。それ故、飲食業者にとって、支払い媒体の処理は、非常に重要な問題であり、対処する必要がある。
【００１８】
この米国特許５，８４５，２６３は、注文処理全体の論理を詳しく説明しておらず、飲食業者で受けた注文が、どのようにして従業員（やシェフ）によって処理されるか、よくわからない。この論理不明なところが、システム全体の運用に正に非常に重要で、システム施行に興味を持つ飲食業者の持ち主が、質問する点である。
【００１９】
要約すると、米国特許５，８４５，２６３は、飲食業者にとって不適切なハードウエアを使用し、費用がかなりかかり、システムのフェイルセイフ機能を持たず、食事料理品の注文処理上重要な部分（つまり、注文遂行全過程処理、及び支払い処理方法）に対処していない。
【００２０】
米国特許６，２０８，９７６は、顧客がメニューの変更や追加に対応できる端末を使用して注文できる注文管理システムを発表した。このシステムは始動した時に、メイン管理システムから、注文を取る１つ１つの端末へ、オペレーティングプログラムとイメージデータを送る。しかしながら、このシステムは、端末を、注文を入れることだけに使用し、端末のパワー管理や安全性には詳しく触れず、システムは単に、始動した時に（実時間上ダイナミックではない）、メニューの変更を送り、支払い処理方法には対処していない。
【発明の開示】
【発明が解決しようとする課題】
【００２１】
それ故、本発明は、以前の発明における多くの技術的欠点を克服するものである。本発明の目的には、飲食業界における最適なハードウエア機器の使用と施行により、顧客が従業員の介入なしで無線で注文できることを含有する。
【００２２】
完全な注文処理解決で、注文受付や、注文遂行過程処理、支払い処理方法に対処することが、本発明の更なる目的である。
【００２３】
低コストで信頼性のある、安全なシステムで、飲食業者の運用をより効率良くするシステムを提供することが、本発明の更なる目的である。
【００２４】
顧客の待ち時間を最小限にし、顧客へのサービスと、顧客の飲食業店における全体的な体験を改善することが、本発明の更なる目的である。
【００２５】
従業員不足と従業員費用増加を緩和するシステムを提供することが、本発明の更なる目的である。
【００２６】
固定した端末または携帯機を使用し、注文受付や支払い処理のできるシステムを提供することが、本発明の更なる目的である。携帯機には、携帯電話や、ＰＤＡ、及びそれ以外の無線機器が含まれる。
【００２７】
レストランや食事施設において、団体客の幹事として特定の人を認知するシステムを提供することが、本発明の更なる目的である。この団体の幹事が団体とシステム使用に関しコントロールと責任を持つことになる。
【００２８】
レストランや食事施設の為のトラッキング（運用調査）と安全性のあるシステムを提供することが、本発明の更なる目的である。
【００２９】
現金支払いでも現金不要支払いでも処理できる機能を提供することが、本発明の更に進んだ目的である。
【００３０】
割引や、クーポン、プロモーションの取り扱いを促進するシステムを提供することが、本発明の更なる目的である。
【００３１】
料理や飲み物の支払いに対し、端末または携帯機を使用し、現金不要媒体にて（テーブルで）支払いのできるシステムを提供することが、本発明の更なる目的である。
【００３２】
レストランや食事施設等において、ゲスト用端末または携帯機使用により、料理の事前注文やメニュー閲覧を可能にすることが、本発明の更なる目的である。
【００３３】
レストランや食事施設等において、自動座席配置（隣接するテーブルに着く選択も含む）を可能にすることが、本発明の更なる目的である。
【００３４】
注文を分割し、各々の注文品をその担当者に回すことで、未処理の同様な料理アイテムをまとめて一括処理できることを可能にするシステムを提供することが、本発明の更なる目的である。
【００３５】
紙や電子メール、若しくはその両方による領収書処理を促進するシステムを提供することが、本発明の更なる目的である。
【００３６】
注文情報や支払い状況を把握するために、携帯機を使い、いわゆる、ｅ−ｔｉｃｋｅｔの使用を提供することが、本発明の更なる目的である。
【００３７】
現金不要支払い媒体を受け入れ、電池だけで作動する、薄いタッチ式画面と無線端末を含むバージョンのシステムや、インターネットアクセスが可能な携帯機を取り入れた代替バージョンを含むシステムを提供することが、本発明の更なる目的である。
【００３８】
顧客が食べながら、または、注文した料理を待ちながら、インターネットを楽しんだり、種々な情報を得られる、薄い無線端末を提供することが、本発明の更なる目的である。
【００３９】
特定の食事料理に対するプロモーションやディスカウントを、顧客に実時間で同時に提供する動的販売を促進することが、本発明の更なる目的である。
【００４０】
国際的な顧客層を受け入れるために、また顧客が外国を訪れた際の料理注文処理を容易にするために、多国言語の注文処理システムを提供することが、本発明の更なる目的である。
【００４１】
以上の、またはそれ以外の本発明の目的が、以下の概要と詳細により、明白となる。
【課題を解決するための手段】
【００４２】
本発明は、レストラン等の食事施設にて、顧客の為の食事料理注文処理システムを改善することを目的としている。本発明は、特別に設計された端末と、現存のインターネット・アクセス（接続）が可能な携帯機器を利用し、レストラン等の食事施設にて、顧客が従業員の介入なしに、飲料品や食事料理品を無線で注文したり、その支払いができるようにしている。それ故、本発明は、注文処理と支払い処理だけにとどまらず、注文から支払いまでの完全な遂行過程処理を含み、更に、多国言語使用、自動着席案内、事前注文、顧客への報奨ポイント、動的販売、余った在庫販売の促進等の、特別追加企画を含む。
【００４３】
費用効率の良い、信頼性の高い、安全なシステムに加えて、この発明は、全体の注文処理を非常に早め、顧客の待ち時間を減らし、レストラン等の食事施設における運営の効率を向上させ、顧客へのサービスを増し、顧客のレストラン等での総合的体験を改善する。その上、この発明技術を取り入れることにより、レストラン等の食事施設の持ち主は、従業員不足と従業員費用の心配から緩和される。
【００４４】
顧客は、そのシステム用に特別に設計された端末（以下の段落で説明されているように）、または、自分のインターネットアクセスが可能な携帯機（例、携帯電話やパーソナル・ディジタル・アシスタント（ＰＤＡ））を使用することになる。顧客の注文は、レストラン等食事サービス施設の注文処理サーバに、直接に（無線ローカルエリアネットワーク（ＬＡＮ）を経由して）送られたり、間接的に（携帯機器の提供側とシステムサポートセンター経由のインターネットを通して）送られる。レストラン等食事施設のサーバは、高速度なインターネット提供側によって、システムサポートセンターに接続されている。このインターネット提供側は、仮想専用回線（ＶＰＮ）を使って、食事施設とシステムサポートセンターを接続している。サポートセンターは、現金不要支払いを処理する為に、支払いサービス提供側と、安全に接続されていている。支払い情報や特別コードのような安全性を必要とするデータは、全て、無線伝達時に暗号化される。
【００４５】
その上、データベースやその他の情報貯蔵媒体に貯蔵された重要なデータは、最適な安全確保のために暗号化される。食事サービス施設の種類（店、またはレストラン）と受け付ける支払い媒体（現金、または現金不要支払い）によって、注文の支払いは、処理するサーバに受け取られる前になったり、後になったりする。食事施設の担当者が注文料理を準備した後に、顧客は注文料理を受け取る。これが基本的な注文処理論理であるが、「好ましい実施形態の詳細な説明」と題された段落で説明されているように、その順序と段階は、実施遂行の仕方によって変わってくる。注文に使われる機器（端末や、携帯機）や、食事サービス施設の種類（店、またはレストラン）、及び受け付ける支払い媒体（現金、または現金不要支払い媒体、現金不要支払い媒体のみ）によって、実施遂行の仕方は変わってくる。
【００４６】
端末
端末はスペースを節約するように設計され、２インチ（約２．５ｃｍ）以下の厚さで、２つの充電できる電池を使い、電気コード無しで作用する。端末には、タッチ式画面や、１つまたはそれ以上の通信用部品があり、その通信用部品は電波中継器によって中央サーバやレストランにある他の端末に、無線接続されている。現金不要支払い媒体（デビットカードや、クレジットカード、スマートカード、プリペイドカード等）を処理する為に、一種のカードスキャン部品が、端末に含まれている。端末は、他の機器（例、顧客の携帯機内に装置された電子財布またはチップ）からの支払いを無線で受け取れる、赤外線技術やブルートゥース技術を使った通信用部品も含んでいる。この種の非常に薄い、２つの電池で稼動する端末は、以前の発明には見られず、テーブルの場所をとらず、客席の邪魔にならず、電源コードの問題もなく、顧客の様々な現金不要支払い媒体を可能にさせる。
【００４７】
更にその上の機能（詳細は以下に述べる）として、システム実施遂行（例、レストラン）と食事サービス施設の好みによるが、顧客は食事中または食後に、この端末を使って、インターネットの使用が可能である。この端末は、どんな入力でもかまわないオペレーティングシステムＬｉｎｕｘ、または派生するシステムで作動する。こうすると、高い費用を払って免許を取る必要がなくなり、レストランのオーナーや店主にとって、全システムの所有権費用を非常に削減できる。
【００４８】
食事サービス施設のサーバは、２つの連結した非常に薄いコンピュータまたは似た機能を提供する装置から構成されている。２つのコンピュータ（または同様な装置）で構成されている理由は、フェイルセイフという、故障に対処できる重複性を備えるためであり、もし１つのコンピュータが故障した場合、もうひとつのコンピュータが引き継ぎ作動し、システムが止まらず作動するのを確証するためである。このようなコンピュータ（１つは第一次で、もう１つが第二次）は、第一サーバが、そのデータを第二サーバに、継続的にコピーする。もし第一サーバが故障したら（例えば、ディスクまたは電源の故障の為に）、第二サーバが引き継ぎ再び処理を続け、新しく第一サーバとなる。その間に、食事サービス施設とシステムサポートセンターは直ぐに故障の通知を受けて、修正対処活動をとる。以前の発明にはなかった、この種の重複性が、食事サービス施設にとって滑らかな継続運営を保証する。
【００４９】
更に、サーバが常にシステムサポートセンターにつながっているので、食事サービス施設のサーバのバックアップは、毎日または、どんな時間間隔でも可能である。この機能は、他の注文システムになく、レストランの大事なデータを緊急事態（例えば、両方のサーバコンピュータの故障、洪水による被害、地震、盗難等）に備えてバックアップすることを確証する。システムサポートセンターに接続しているので、サーバと端末のソフトウェア修理や改善が離れた所から可能である。例えば、１つの端末が故障した時、システムサポートセンターが直ぐに調べて、問題が起きてから、数分以内で、離れた所から修理するのが可能である。この機能は以前の発明には見られず、食事サービス施設のシステムにとって、ダウンタイムを最小限にし、滑らかな継続運営をする為に非常に重要であり、レストランのオーナーや店主にとって、もし大災害が起きた時に、彼らのデータと他の重要な情報のバックアップがあるという確証となる。
【００５０】
食事サービス施設は、ディジタルカメラやビデオカメラを使って、写真やビデオをシステムに入れられる。特別のシステム・プログラムを使い、どの写真やビデオが特定のメニュー料理に対応しているか施設のユーザーに聞き、写真やビデオのメニューを作れる。食事サービス施設は、自分達で行わず、サポートセンターに頼んで、写真やビデオをシステムに入れることもできる。一旦、写真やビデオがシステムに入ると、顧客に情報を表示するメニュー文字やプログラムの変更と共に、ファイルが実時間または、食事サービス施設の指定した時間に、必要な最新データとして、端末に送られる。変更効果が生じるために、全体のシステムをリスタート（再始動）する必要はない。
【００５１】
顧客を保持する為に、システムは顧客のボーナスや「ｒｅｗａｒｄ  ｐｏｉｎｔ」（報奨ポイント）を維持できる。これにより、多くの食事サービス施設は、顧客の保持増進ができ、忠実に何度も来る顧客に割引や報奨を与えることができる。このシステムを使う食事サービス施設が増えることにより、より多くの顧客が、自分達の報奨ポイントを統合し、別々のレストランのポイントカードを持たないで、ポイントを一箇所で管理できる利益を味わえる。
【００５２】
システムの実施遂行（例、レストラン）によって、ログアウトの際、顧客は、食事サービス施設のサービス、メニュー料理の質などに対する、コメントを提出することができ、これが、レストランのオーナーや店主にとって、顧客の為にどのようにして食事料理とサービスを改善するかの非常に価値のあるフィードバックとなる。また、ログアウトの際、もしシステムまたはサービス施設が顧客にチップを要求することを選べば、顧客はチップを置いていくことができる。システムは、チップの割合または金額を要求でき、顧客に推薦もできる。これは重要で、特にチップのやり方が違う国に旅行したとき、いつ、どのくらいチップを置くか、しばしば迷う。ある国ではチップを置く習慣がなく、この場合システムは、チップを要求しないように設定される。この種のチップ機能のあるシステムは、チップを置くか置かないかの心配と迷いを確かに減らしてくれる。また、システムが自動的にチップを計算するので、顧客にとって容易になる。
【００５３】
上記のごとく、レストランや他の食事施設で、端末使用の解決システムが取り入れられると、レストランのオーナーや店主の設定する制御と選択次第で、顧客は食事中または食後に、インターネットを使用できる。例えば、人の入れ替わりの多い時や忙しい時に、インターネット使用時間を制限できる。しかしながら一般的に、忙しくない時には、レストランで食事したりコーヒーを飲みに会う友達客達は、インターネットを一緒に「ｓｕｒｆｉｎｇ」して（例、おそらく旅行の計画や、アパート探し、映画等の為に）楽しむことができる。レストランとシステムサポートセンターの制御や選択次第で、顧客は僅かなインターネット使用料金を払ったり、払わないですむ。
【００５４】
しかしながら、端末に表示される会社の宣伝収入や、顧客の追加注文が予想されるため、顧客からインターネット使用費を取る必要が無いということは可能である。注文料理ができるまでの待ち時間中や、食後のコーヒーやデザートを楽しみながら、インターネットを使用することにより、顧客の全体的な食事体験が良くなる。
【００５５】
顧客がタッチ式画面端末や自分の携帯機を使って注文して、注文がサーバに送られると、何が注文されたかや食事施設の選択するシステムにもよるが、どの注文をウエイターやウエイトレスの端末に送るか、また、どの注文をシェフの端末に送るかを、サーバが決める。例えば、飲み物とサラダの注文はウエイターやウエイトレスの端末に送られて処理され、料理する必要がある注文だけはシェフの端末に送られる。この労働分割促進により、注文処理が早くなり、非常に効率が良くなる。
【００５６】
別の処理改善点として、未処理の似た注文を必要に応じてとりまとめ、一括処理することが可能である。例えば、レストランで５人の違った客達から５つのステーキの注文が少しずつ離れた時間にあった時、このシステムにおいては、この５つのステーキを同時に処理できる。こうすると、シェフは全ステーキをまとめて準備し料理でき、注文が来た時に１つずつ順番に処理する必要がない。この一括処理の利点は、料理人が、１つのステーキを料理する時に、全部の材料、食物、道具を運び出し、終わった時にそれをかたずけて、また、数分後に別のステーキの注文を料理する為に同じ物を運び出す必要がないことである（別の注文料理（例、パスタ）が２つのステーキ注文の間にあった場合のように）。
【００５７】
シェフが多くいて、各々が違った得意料理をできるレストラン等施設では、各々がどの注文料理を準備するか選択でき、注文処理を更に促進できる。このようにすると、特定の注文料理を受けた時に、システムは、その特定の注文料理を準備できるシェフに渡す。注文料理を過度に負わせられたシェフは、その特定の料理を準備できる別のシェフに渡して頼むこともできる。更に、全シェフが同じ料理を準備できる場合には、システムは、全シェフに均等に注文料理を割り当てることができ、１人のシェフが注文料理を過度に負わせられることがない。
【００５８】
その上、従来的な「依頼と返答」技術（前回までの発明に使われたような）に反して、当システムはメッセージ交換技術を使い、端末（そしてメッセージ機能のある携帯機）とサーバ間でデータ（例、注文や他の情報）を送ることができる。「依頼と返答」に対し「メッセージ交換」の利点は数多いが、特に意義があるのは、１）端末がサーバに即答を待たずにデータを送ることができ、顧客の端末の応答性を大改善することであり、２）先に要求されてなくてもサーバが端末にデータを送れることである。後者の重要点は、メッセージ交換技術を基にしたシステムが、端末やメッセージ交換のできる携帯機に、情報を押し送れることである。これによって、レストラン等食事サービス施設で、顧客に食事料理品をダイナミック販売促進できる、以前不可能だった、まったく新しい機会が生じる。例えば、メッセージ交換システムを使うと、レストラン等食事サービス施設の全顧客に、（端末や携帯機器を通して）以下のような通知ができる。その通知とは、今から１０分間全ドリンク（飲料品）が半額になると通知したり、ステーキ夕食を注文する先着の３人の顧客に対して１０％の勘定割引またはデザートが無料になることを通知したりできる。このような機能を用いて、食事施設は、販売増進と、売れない在庫料理品を減らす為に、プロモーションや割引をダイナミックに提供できる。また、全顧客に対して必要な通知（例、最後の注文受け取り、１５分後閉店等）が、このメッセージ交換によって可能であり、忙しいウエイターやウエイトレスが歩き回って一人一人の顧客に知らせる必要がない。
【００５９】
本発明による、飲食サービス施設での料理注文、注文処理、支払いをコントロールする以下の項目から構成された、双方向システムがここに説明される。その構成項目とは、中央サーバから無線にアクセスされ、メニュー食品に対応する文字やマルチメディアファイルを表示するスクリーンや、データ入力手段を持った、無線端末か携帯機を、少なくとも一つ含むこと、端末や携帯機で受送信する注文情報データ処理ができるサーバを、少なくとも一つ含むこと、サーバと端末か携帯機の間で注文情報とデータを無線に送信できる手段があること、注文情報と支払い状況を調べる手段があること、注文の支払いを受け取る手段があることである。
【００６０】
双方向システムは更に、注文を分割し、注文の一部の料理品目を特定の料理品を取り扱う最適な担当者に伝達する手段を有し、未処理の料理品目を取りまとめ、一括に準備する手段を含む。
【００６１】
双方向システムは更に、クレジットカードや、デビットカード、プリペイドカード、スマートカード、また、携帯機プロバイダが提供する支払い装置などの、現金不要支払い媒体を使って、顧客が直接に端末や携帯機から支払う手段を有し、割引、クーポン、チップを取り扱う手段を有し、顧客の報奨ポイントを維持する手段を有し、紙の領収書、または顧客に電子メールできる電子領収書を発行する手段を含有する。
【００６２】
双方向システムは更に、端末や携帯機に表示されるメニュー品目を、実時間で更新する手段を含む。
【００６３】
双方向システムは更に、メニュー料理品目に対応するコードを携帯機から入力して、メニュー料理品を追加注文できる手段を含む。
【００６４】
双方向システムは更に、特定のメニュー料理品のプロモーションが実時間で端末や携帯機器に表示されて、動的にメニュー料理品を売る手段を有す。
【００６５】
この双方向システムは更に、誰が支払いや注文を仕切る幹事であるかを識別する手段を有す。
【００６６】
また、この双方向システムは、顧客が端末や携帯機器を使ってメニューを閲覧したり、前もって注文することができる手段を有す。
【００６７】
更にこの双方向システムは、自動的に空席情報を顧客に知らせる機能を持ち、端末や特別な着席案内機を用いることにより、顧客自身で席を選ぶことができる手段を有す。
【００６８】
双方向システムは、端末がインターネットに結続されて、ウエブサイト、ニュース、娯楽、その他の情報にアクセスできる機能を持ち、また、様々な言語で情報を表示する機能を有す。
【００６９】
双方向システムは、更に顧客がメニューやサービスの良し悪しなどの店へのフィードバックを残すことができる機能を含む。
【００７０】
更に進んだ実施形態として、この発明は、下記設備を有するレストラン若しくはそれに似た飲食店での注文、処理、支払いの管理のための双方向システムである。その設備とは、最低一つ、データ入力機能を持つ端末（テーブルに設置）とタッチ式画面、若しくは携帯機、いずれにおいても中央サーバから得られる文章やマルチメディアデータを表示することができ、メニューアイテムに通じることができるものの設置を有する。メニューの注文を無線通信で中央サーバに送り、そこから注文アイテムが、店の適切な従業員の端末に送られる機能を含む。誰がその団体の幹事で、支払いや注文を仕切っているのかを明確にする機能を含む。クレジットカード、デビットカード、その他の現金不要支払い媒体を使って支払いができる端末の設置を含む。クーポンや、割り増し料などもシステムにより提示、受容され、最終的な勘定書に表示できる機能を含む。
【００７１】
このような重要な改善は、注文処理の能率を多大に高め、時間を節約し、最終的には顧客への更に敏速なサービスをもたらすことができる。
【００７２】
能率が上がったのが確認できれば、レストランは一人の給仕係に給仕長の責任を与えて、店の中、特に食堂、顧客の在席する場所を見回り、質問のある顧客がいるかどうかなどチェックし、更に顧客サービスを改善することができる。
【００７３】
提出した発明は同封の図面と関連して説明されており、図面と同じ番号が使われている。
【発明を実施するための最良の形態】
【００７４】
図１．１は、端末を用いた場合のレストランにおける実施形態例の図である。示されているように、端末［１００］は、入り口、顧客のテーブルの上、給仕スタッフのカウンターの上、勘定カウンター上のキャッシュレジスターの隣、そしてシェフが食べ物の準備を行うキッチンの中と、店中に設置されている。端末用の電池充電棚［３００］が従業員の仕事場付近に設置されている。業務用サーバ［４００］が食堂設備内の事務所付近に設置されている。
【００７５】
図１．２は、端末を使用する店舗における実施形態例である。顧客は端末［１００］を用いて注文、支払いを行う［１５０］。もし顧客が現金不要支払い媒体（例、クレジットカード）を使うのならば、その端末を使って入れた注文への支払いができ、ディスペンサー［１１０］が顧客へのレシートをプリントし、顧客は自分の番号が呼ばれるのを待てばよい。そうでなく、もし顧客が現金で支払いをするのであれば、ディスペンサー［１１０］が別のスリップをプリントする。現金払いの顧客は現金払い＆領収書カウンター［１６０］へと進み、現金払い＆領収書マシン（ＣＤＲＭ）［４２０］のスリップ読み込み機［４２４］にスリップを挿入する。ＣＤＲＭ［４２０］の表示画面［４２２］が顧客に請求金額を示し、その金額を挿入することを促す。顧客はＣＤＲＭ紙幣挿入口［４２６］と、あるいはＣＤＲＭ硬貨投入口［４２８］にその金額を挿入すればよい。ＣＤＲＭ［４２０］はＣＤＲＭ釣り銭口［４３０］から釣り銭を出し、ＣＤＲＭレシート口［４３２］からレシートを出す。顧客の注文は業務用サーバ［４００］によって処理され、無線通信で従業員の端末［１００］に送られる。オプショナルとして、もし店がそれようの装置を所持していれば、注文番号は注文番号表示画面［１９０］に表示される。注文したものが用意されると顧客はそのレシートを提示し、従業員がバーコードスキャナー［１２０］を使ってレシートをスキャンする。注文が確認できれば従業員は注文の品を顧客に手渡す。
【００７６】
図２は、顧客が端末を使って注文を入れる手段における、ネットワークの接続を説明する概観図である。端末［１００］、業務用サーバ［４００］、そして電波中継器と転送機器［５００］が食堂設備内に設置されている。端末［１００］は現在、電波中継器と転送機器［５００］に８０２．１１無線通信［５０５］で、しかしそれに限られず、接続されている。業務用サーバ［４００］は電波中継器と転送機器［５００］は現在、イーサネットで、しかしそれに限られず、接続されている。電波中継器と転送機器［５００］は現在、ハイスピードインターネットプロバイダ（ＩＳＰ）［６００］に有線のブロードバンド接続［５２０］で、しかしそれに限られず、接続されている。ブロードバンド接続［５２０］は、インターネット［８００］へのインターネット接続［５４０］と、システムサポートセンター［７００］への仮想専用回線（ＶＰＮ）接続［５６０］の両方を提供する。この図は、業務用サーバ［４００］とシステムサポートセンター［７００］が同じＩＳＰ［６００］に接続されているというシナリオで描かれているのがわかる。しかし店とシステムサポートセンターのＩＳＰが同じでないことは大いに可能性がある。それでもこの場合には、業務用サーバ［４００］とシステムサポートセンター［７００］は、ＶＰＮのセッティングが双方の中継機器に配置されているため、確実なＶＰＮ接続を使って接続されることができる。支払い業務の処理をするためにはシステムサポートセンター［７００］が、ＶＰＮ若しくは他の確実な接続［７４０］を使って支払いサービスセンター［７５０］に接続されている。
【００７７】
図３は、顧客が無線携帯機器を使って注文をいれるところのネットワーク接続を示す概観図である。示されているように、携帯機器［９００］（例、携帯電話や電子手帳など）、業務用サーバ［４００］、電波中継器と転送機器［５００］が、食堂設備内に設置されている。携帯機器［９００］は現在、これに限られているわけではないが、移動体通信接続プロバイダ［６２０］若しくは、無線インターネットアクセスプロバイダ［６４０］によって、業務用サーバと相互接続しており、これらのプロバイダはインターネット［８００］を通じてシステムサポートセンター［７００］と結ばれていて、更にシステムサポートセンターは、業務用サーバ［４００］と結ばれている。セキュリティ上の理由から、これが無線携帯機［９００］が業務用サーバ［４００］と接続するには好ましい手段である。しかしながら、携帯機［９００］が業務用サーバ［４００］と、電波中継器と転送機器［５００］を通し、ローカルの無線接続を使って直接接続することも可能である。業務用サーバ［４００］は現在イーサネット接続［５１０］を用いて、しかしそれに限られず、電波中継器と転送機器［５００］に接続されている。電波中継器と転送機器［５００］は現在、有線のブロードバンド接続［５２０］を用いて、しかしそれに限られず、ハイスピードインターネットアクセスプロバイダ［６００］に接続されている。ブロードバンド接続［５２０］は、インターネット［８００］へのインターネット接続［５４０］、システムサポートセンター［７００］への仮想専用回線（ＶＰＮ）接続［５６０］の両方を提供する。この図は、業務用サーバ［４００］とシステムサポートセンター［７００］が同じＩＳＰ［６００］に接続されているというシナリオで描かれているのがわかる。しかし店とシステムサポートセンターのＩＳＰが同じでないことは大いに可能である。それでもこの場合には、業務用サーバ［４００］とシステムサポートセンター［７００］は、ＶＰＮのセッティングが双方の中継機器に配置されているため、確実なＶＰＮ接続を使って接続されることができる。支払い業務の処理をするためにはシステムサポートセンター［７００］が、ＶＰＮ若しくは他の確実な接続［７４０］を使って支払いサービスセンター［７５０］に接続されている。
【００７８】
図４は端末の外観図である。端末［２］の前面図［５００］には、超薄型の、タッチ式画面［４］、音声出力用のスピーカー［１４］、音声入力用の小型マイク［１２］、ＩｒＤＡ［６４］若しくはこれに似た短距離用赤外線通信のための技術及び、ＩｒＤＡや似た技術をサポートするその他の機器が描写されている。画面の右側には、画面の明るさを調整するノブ［１６０］、音量調整用ノブ［１５０］、スクロールする（例、ウエブページで）ためのノブ［１４０］、前画面、前ウエブページに戻るためのボタン［１４２］、そして次画面、次ページへジャンプするためのボタン［１４４］がある。端末の上部にあるのは、電池１の解除／ロック装置［１７０］と、電池２の解除／ロック装置［２２０］であり、顧客が端末の電池を取り外してしまう心配なく使用してもらえるように設置されている。前面からでは見えにくいが、左手には顧客の支払いカードが入るところの支払いカードベイ［２４］がかすかに表示されている。
【００７９】
端末［２］の左側図［５１０］は、超薄型のタッチ式画面（端末内に埋め込まれているため、ミシン線で描かれている）の一部［４］と電池２の解除／ロック装置［２２０］、加えて端末の後部連結板［６］を表示する。連結板［６］を用いることでは端末は、確実に端末を支えるためのほぼどんな装置にも固定できる。加えて、顧客が支払いカードを挿入するところの支払いカードスロット［２２］、顧客がカードをスロットから取り出すのを助ける支払いカードスロット指溝［２８］が表示されている。更にある特定のファンクションを行うボタンを安全に隠すコントロールパネルカバー［３６］が示されている。コントロールパネル解除／ロック装置［３０］が解除されているときにはコントロールパネルカバーの解除／ロック装置ブロッキングピース［３２］が右側に移動し、そのためもはやコントロールパネルカバーのブロックピース［３４］と連結していない。なのでコントロールパネルカバー［３６］をコントロールパネル引き込みエリア［３８］の中に滑り込ませることができ、コントロールパネルを現すことができる。飲食業環境においては、端末制御やセッティングがアクセスされたり、変えられたりすることのないように、この種のセキュリティ装置が必要とされる。
【００８０】
端末［２］の右側図［５２０］は、超薄型のタッチ式画面の一部［４］と電池１の解除／ロック装置［１７０］、そして端末の後部連結板［６］を表示する。加えて、画面の明るさ調整制御装置［１６０］、音量調整制御装置［１５０］、スクロール制御装置［１４０］、前画面移動制御装置［１４２］、次画面移動制御装置［１４４］が見える。
【００８１】
上部図［５３０］からは、電池１の解除／ロック装置［１７０］、電池２の解除／ロック装置［２２０］、電池１のスライド式カバー［１９０］そして電池２のスライド式カバー［２４０］がはっきりと見える。既に示されたように、超薄型タッチ式画面［４］の一部、コントロールパネル解除／ロック装置［３０］、画面の明るさ制御装置［１６０］、そして端末の後部連結板［６］も見ることができる。
【００８２】
下部図［５４０］からは、前記のごとく、超薄型タッチ式画面［４］の一部、支払いカード取り出しボタン［２０］、スクロール制御装置［１４０］、そして端末の後部連結板［６］が見られる。この図からは、内蔵してある送風機で熱くなった空気を端末内から吹き出すことを可能にする通気孔［３４０］が見られる。
【００８３】
上記に説明された多くの部品は、背部図［５００］にも見ることができるが、簡潔にするためにここでは省く。端末を従来のコンセントにつなぐことができる動力コードソケット［１３０］が示されている。このようなコードは簡単に引き抜くことができるため、顧客用にこれが使われることはまずないということを言及する。動力コードソケットは、店の従業員が用いる端末において使われることになる。端末内から出る熱のもう一つの逃げ口として、熱気孔［３４２］を示している。後部連結板支持部品［８］によって支えられる端末の後部連結板［６］は、端末を支える設備に安全に端末を固定するため、ねじなどを入れることができる留め具穴［１０］を持つ。付加された安全手段として、安全ロック［３５０］が端末に設置されている。これは端末と店内ある、静止していて（簡単には）動かされないもの（例、テーブル）を確実に止着させるためのものである。この安全ロックは今日のコンピュータ装置の多くに使われるようなものとよく似た役割をする。安全ケーブルが安全ロック開口部１［３５２］に入り込み、安全ロックの金属製留め具［３５４］の下を通り、安全ロック開口部２［３５６］から出る。ケーブルが端末の安全ロック［３５０］から取り外されるのを防ぐために、安全ケーブル（図省略）の端に従来の錠を取り付けることができる。
【００８４】
端末の様々な外観図の説明から解釈できるように、飲食業環境において盗難や端末のセッティングを変えられるという心配をせず使えるよう、セキュリティ重視でデザインされている。
【００８５】
図５は、内部構成図である。すべての部品への接続を維持するマザーボード［１０５］が端末内に内蔵されている。マザーボードに付属しているのは中央処理装置（ＣＰＵ）［１００］、小動力源［１２０］、メモリースロット［９０］、データ伝送器（ＵＳＢ）スロット［１１０］、グラフィックチップ［８０］、音声チップ［８５］、ミクロハードドライブや似た記憶装置（データを保存するためのもの）［７０］、送風機（端末から熱を取り除くためのもの）［３３０］、無線コミュニケーションチップ（限られてはいないが、大抵ブルートゥース）［６０］、そしてＩｒＤＡ（赤外線通信）か、匹敵するチップ［６５］である。
【００８６】
この発明における端末のユニークなところは、磁気カードやミクロチップが埋め込まれたスマートカードの両方の読み込みができる支払いカード読み込み機［２６］である。その結果端末は、デビットカード、クレジットカード、プリペイドカードなどの今日良く使われるカードの読み込みができるだけではなく、将来広く使われることが期待されるスマートカードと呼ばれる支払いカードを読み込むこともできる。支払いカード処理チップ［５０］を使うことで、支払いカードから情報が読まれる。顧客がカードを支払いカードスロット（図４：側面図［５１０］：パーツ２０）及び、支払いカード搭載ベイ［２４］に挿入すると、支払いカードは自動的に支払いカード読み込み機［２６］の中に搭載される。顧客は支払いカード取り出しボタン［２０］を押してカードを取り出すことができる。また、端末はある特定の条件において（例、ログアウト）自動的に顧客のカードを排出することもできる。
【００８７】
端末は更に、オプションとしてＰＣＭＣＩＡカードスロット［５５］を有する。これはもし、ＰＣＭＣＩＡカードスロットが重過ぎるとか、高価すぎると思われる場合には、簡単な８０２．１１無線通信チップや、同等のものに交換することができる。しかしながら、好ましい実施形態としては、ＰＣＭＣＩＡカードを有する方がよい。それによって将来、ＰＣＭＣＩＡカードがまだ今は知られていないような無線通信技術に使われるようになったとき、機能拡大を可能にするからである。
【００８８】
好ましい実施形態におけるこの端末のその他の特徴としては、一つだけではなく、二つの充電可能な電池を保持することである。飲食業環境においては、電源に接続された動力コードを使うことが適当でないことが理由にあげられる。動力コードは顧客にとっては邪魔であり、誤って引き抜かれたり、更には盗まれたりすることも大いに考えられる。更に飲食業環境において、特にレストランでは、客席付近に電源があることはあまりない。故に、動力コードは実行可能なオプションではない。そして、充電池の寿命が伸びているとはいえ、無線通信を使う特質や部品が頻繁に使われれば、充電池は長くはもたない。加えて、画像やビデオを観たり、音声を聞いたり、品書きを見たり、インターネットをサーフしたりすれば、充電池の寿命はあっという間に使い切られてしまう。このような訳で、顧客が端末を使っている途中で端末が遮断されることなく持続して端末が使用できるように、この端末は二つの電池を保持するやり方を適用する。この特徴においては、一つの電池が端末を可動させている間に、店の従業員が二つ目の電池を取り替えることも可能である。この手段をもって、顧客は不便なく、妨げられることなく端末を使い続けることができる。
【００８９】
典型的なコンピュター機器は、普通その持ち主のみによって取り扱われるため、充電池に対するセキュリティを提供しない。しかしながら、公共の場所では電池が盗まれたり、誤って取り外されたりすることがないように、施錠装置を設置することは重要である。結果として、端末は店の従業員のみが電池にアクセスできるというセキュリティ上の特質を適用する。図においては、電池１［２１４］と電池２［２６４］に対する安全装置は全く同じである。違う識別番号が両方の電池の同じ部品に付けられてはいるが、簡潔にするため、電池１の安全装置のみ、説明する。しかしながら、参考までにどの電池１の部品の識別番号が電池２のものに相当するのかを示すための表が以下のものである。
【００９０】
【表１】
2005527017.tif 000003
【００９１】
給仕係の一人が鍵を電池解除／ロック装置［１７０］に挿入し回すことにより、電池解除／ロック装置のフック［１８０］を下方の電池解除／ロック装置孔［１８５］の中に移動させる。これが起こると電池解除／ロック装置フックブロッキングピース［１８２］も下方に移動し、もはや電池スライド式カバーブロッキングピース［２０２］と噛み合っていない。後述の部品は自由に動かせるため、従業員が指を電池スライド式カバーの指溝［２００］に入れ、電池スライド式カバー［１９０］を電池スライド式カバーストッパー［２１０］に到達するまでスライドさせことによって電池挿入孔［２１２］を開けることができる。従業員は、電池取っ手溝［２１６］を使い、電池［２１４］を電池孔［２１２］から取り出すことができる。前述の如く、端末は端末に差し込まれているもう一つの電池に電力がある限り、妨げられることなく可動し続ける。従業員は取り出された、電力がなくなった電池を充電器棚［図．１．１：３００］の中で充電させ、充電終了後、端末内に戻すことができる。電池孔［２１２］を閉じるためには、従業員は単に電池スライド式カバー［１９０］を元の位置に戻し、まだ電池解除／ロック装置［１７０］に差し込まれている特別な鍵を、最初とは反対の方向に回せばよい。こうすることで、電池解除／ロック装置のフック［１８０］と電池解除／ロック装置フックブロッキングピース［１８２］は元の位置に戻り、電池スライド式カバーブロッキングピース［２０２］と噛み合い、電池スライド式カバー［１９０］が動かないようにする。
【００９２】
その他の安全上の特徴としては、ＵＳＢポートが無断で使われないようにするためのＵＳＢスロット解除／ロック装置［２８０］が含まれる。ＵＳＢスロットへのアクセスを得るためには従業員は同じ鍵をＵＳＢスロット解除／ロック装置［２８０］に差し込む。鍵を時計と反対方向に回すとＵＳＢスロット解除／ロック装置ブロッキングピース［２９０］が下方に回転し、ＵＳＢスロットブロッキングピース［３００］はもはや固定されなくなる。故に、従業員はＵＳＢスロットカバー［３１０］を左手のＵＳＢスロット引き込みエリア［３２０］に滑らせ、ＵＳＢスロットへのアクセスすることができる。
【００９３】
更にＵＳＢスロット解除／ロック装置［２８０］と同様に機能する、コントロールパネル解除／ロック装置［３０］も存在する。前述で用いられた同じ鍵を差し込み、従業員はコントロールパネルカバー［図４：側面図５１０：パーツ３６］を開けることができる。コントロールパネル［４０］内部には三つのボタンがある。一つは端末の入／切ボタン［４２］、二つ目は端末表示調節ボタン［４４］、三つ目は将来使用のための予備ボタン［４６］である。
【００９４】
前述の説明から解釈できるように端末は、ユニークな安全とダブル電池の特徴を以って、飲食業環境において最適に使われるようにデザインされている。
【００９５】
図６．１．１．１は、現金と現金不要支払い媒体の両方を受け入れるレストランにおいて端末使用するところの過程論理の図である。示されているように、過程は団体が店［１０］に入るところから始まる。この言葉「団体」は、首尾一貫性のために、顧客が数人であろうが一人であろうが用いられる。店の経営者の好みにより、顧客が自分で席を選ぶことができ、全ての注文過程を手早く済ませ、店の労働コストを削減することができる自動着席案内システム［１５］を使うかどうかを選ぶことができる。もし店が自動着席案内システムを使っているならば［１５：はい］、論理は図８．１．３．１［２５］に描写されているように進み、後でテーブルへ向かっている団体に戻る［２２０］。しかし、もし店が自動着席案内システムを使っていなければ［１５：いいえ］、従業員は団体の幹事から名前、人数、禁煙席か喫煙席かを聞かなければならない［３０］。
【００９６】
団体幹事の名前と来店コード（下参照）は注文システムにログインする安全な手段として一緒に使われている。付加して、団体幹事の名前は、「団体名」の役割を果たし、特に団体がいくつかのテーブルに分かれて座っていて、注文をするのに違う端末を使っている場合に、団体のメンバーを一まとめにすることに役立つ。団体幹事は名前が明記されている現金不要支払いカードを提示することにより、若しくはこのシステムのために特別にデザインされたカード（もしそのようなカードが使われるようになれば）を使うことにより、従業員に名前を知らせることもできるということは言及すべきである。
【００９７】
そして従業員は顧客の名前、団体の人数、禁煙席か喫煙席かをシステムに入力する［４０］。情報を入力することにより、システムはその団体のための「来店コード」を発行する［５０］。「来店コード」はアットランダムに作られるコードで、数字と文字によって成り立ち、団体が店にいる間、団体を識別するために用いられる。この来店コードは発行からその顧客の団体がログアウトし、勘定が支払われるまで有効である。つまり、来店コードは顧客が注文を入れる前に実際に店の中にいるということを確実にするための安全装置の役割をも果たす。これは現金支払いを食事の後に顧客から受けつける店において注文が携帯機器を用いて行われる場合に非常に重要である。もしなんらかの、団体が店で注文をしている間にのみ有効なアットランダムに作られたコードがなければ、誰かレストランの外にいる者が自分の携帯機器を使って悪ふざけで注文を入れるということも可能であるからである。更に、来店コードは顧客にテーブルが与えられて初めて使えるようになる。
【００９８】
その次に従業員は来店コードとバーコードが含まれたスリップを発行し、団体の幹事に手渡す［６０］。このスリップはステップ５０で来店コードが作られた後、システムによって自動的にプリントされることもできる。次に従業員は席が空いているかどうかを確認する［７０］。もし空席があれば［７０：はい］従業員は特定のテーブル用に来店コードを使用可能にし［２１０］、そして団体にテーブル番号を知らせる、若しくは団体にテーブルを示す［２１５］。その後団体はテーブルへと進む［２２０］。もし空席がなければ［７０：いいえ］、団体は待合室内の「ゲスト用端末」が空いているかを見ることができる［８０］。「ゲスト用端末」は、実際のテーブルで使えるのと同じような注文端末である。しかしながらこれはあくまでも閲覧するためと、その日可能なメニューアイテムの前注文をするためのみに使うことができる。顧客はまだ席に着いていないので、前注文されたアイテムはキッチンには送られず、臨時的に記憶されて、後に着席した後、回復することができる。
【００９９】
もし店が、待合室内にゲスト用端末を設置するならば［８０：はい］、団体が端末を使えるかどうかは他に端末を使っている顧客が待合室にいるかによる［９０］。待合室内に端末を使っている顧客が他にいなければ［９０：いいえ］（図８．１．３．５参照）、団体は端末を使ってメニューを閲覧したり、前注文を入れたりすることができる［１８０］。テーブルが空いたとき、従業員が団体の情報をシステムから取り出す［２００］。従業員の端末にテーブルの用意ができた団体の情報が自動的にシステムによって表示されるということを店が指定することも可能である。
【０１００】
もし団体がまだいれば（例、まだ店を離れていない）、従業員は団体の来店コードを団体にあてがわれた特定のテーブル用に使用可能にする［２１０］。従業員が団体にテーブルを示し［２１５］、団体が自分たちのテーブルへと向かう［２２０］。
【０１０１】
待ち合い所に、ゲスト用端末が無い場合［８０：いいえ］、若しくは、端末はあるが他の顧客が、使用中の場合、［９０：はい］、待っている団体が、携帯機（携帯電話、ＰＤＡ等）を所持していれば、メニューを見たり事前注文する［１５０］ことができる。
【０１０２】
もし、団体の誰も携帯機を持っていない場合［１５０：いいえ］従業員が、テーブルに案内するまで、待つことになる。しかし、団体が、携帯機を持っている場合［１５０：はい］、図形８．１．５に表されている説明に基づきメニューを見たり、前もって注文することができる。
テーブルが空くと、従業員が、団体の情報をシステムより読み取る［２００］。前にも述べたように、システムは、どの団体に、テーブルが利用できるか、表示することができる。それで、従業員が、団体の来店コードを利用できるテーブル用にアクティブ化する［２１５］。そして、団体はテーブルに案内される［２２０］。
【０１０３】
団体がテーブルに案内されると、幹事となる人が言語を選択する［２２５］、その店舗の所在する所で通常使われている言語と異なっていても、システムと店舗との設定がされていれば、選択された言語が端末のスクリーンに表示される。それから幹事が、名前と来店コードを端末に入力して、ログインする［２３０］。一つの団体が複数のテーブルを使用する場合、複数の端末を使用することになるので、システムはログインした人が幹事かどうかを確認する必要がある［２４０］。団体が二つ以上のテーブルと端末を使用する場合（テーブル一つに一端末と仮定して）、他のメンバーが端末に団体の来店コードでログインすることは可能だが、個人名意外に団体の幹事の名前を指定しなければならない。団体の幹事がログインした場合には他の人が同じ来店コードでログインするこが出来ない事を覚えておく必要がある。幹事以外の人が図形８．３．１に示された様に注文に追加することはできるが注文自体をすることはできない。幹事は注文担当を指名する場合以外は、メンバーの注文を確認する必要がある［図８．３．１：１０４−１０６］、その場合には、メンバーが直接注文することができる。
【０１０４】
ログインした客が幹事の場合［２４０：はい］、その人は支払い媒体を選択することになる［２７０］。ログインした人が幹事でない場合［２４０：いいえ］、システムは店が一人一人別途支払いをするかどうかを確認する［２５０］。
【０１０５】
支払いが現金であれ他の支払い媒体であれ、全ての店舗が顧客一人一人支払いできるシステムを導入しているわけではない。この問題の解決としては、個々の店の決断しかない。もし、その店が顧客一人一人別途に支払いする手段を導入していなければ、［２５０：いいえ］、団体のメンバーは支払い媒体を特定せずつぎのログインの順序へと進むことになる［３２０］。一方、その店舗が顧客一人一人別途に支払いする手段を導入していれば［２５０：はい］、団体のメンバーは次に支払い媒体を選択することになる［２７０］。
【０１０６】
支払い媒体が現金だとすると［２８０：現金払い］、顧客はログインを終了すべくつぎの指示に従う［３２０］。しかし、顧客が現金以外の支払い媒体を使用する場合［２８０：現金不要支払い］、顧客はカードを通す、番号など入力する、または、端末にその情報を送信しなければならない［２９０］。もし、その店舗がスロットつきの特殊な端末を使用していれば、顧客はカードをスロットに通す（クレジットカード、デビットカード、スマートカード等）。顧客の携帯機（携帯電話、ＰＤＡ等）に組み込まれている電子財布などの他の手段は、支払い情報を無線で送信することができる（赤外線通信やブルートゥースなど持ち歩き可能な装置に設定された送信手段にて）。しかしながら、特別な端末の様に一般的な端末に支払い機能が組み込まれていない場合、顧客は支払い媒体の情報をタッチ式画面により直接端末に入力しなければならない。
【０１０７】
ログイン時、ログアウト時のいずれに支払い媒体の情報を要求するかは、各店舗次第である（図８．１．３．４ログアウトの手順、３５０参照）。しかしながらログイン時顧客に支払い媒体を聞くのが通常好まれる、現金不要支払い媒体で支払うことを顧客に促す。現金不要支払いにすることで、食事後に従業員が支払いを取りたてる手間が省け、顧客の来店時の時間を短縮することができる。また、前もって支払い情報を得ることで、顧客が支払わずにレストランを出たり、ひやかしの注文をさけることができる。図６．１．１２に示されたように顧客が現金不要媒体で支払いするシステムになるのは、時間の問題であり、顧客は事前に支払い情報を提供することに抵抗を感じなくなるであろう。
【０１０８】
システムは支払い媒体が有効であることを確認し顧客の現金不要支払い媒体を許可する［３００］。もしその媒体が有効でなければ顧客は再度その媒体を試す、若しくは他の媒体で手順２９０−３１０に従って処理をすることになる。図６．１．１．１には、明確に表されていないが、顧客の現金不要支払い媒体が有効でない場合［３１０：いいえ］及び他の媒体がない場合は、顧客は現金払いを選択することができる。支払い媒体が有効であれば［３１０：はい］、顧客はログインの手順を終了することになる［３２０］。
【０１０９】
顧客は、ログインの段階を終了した時点で、該当すれば割引き及び販売促進コードを入力し、また、図８．３．３に明記されたように報奨ポイントの資格があるか見ることができる［３２５］。顧客は図８．３．１の注文過程に従って端末上でメニューを選択し［３３０］、注文をする［３４０］。図８．１．３．４のレストランログアウトの手順に従って全ての注文を入力した時点で顧客はログアウトする［３５０］。支払い処理の手順、図８．１．１．１の要領でログアウト後団体は店舗のカウンターにて支払いを済ませ領収書を受け取る［３６０］。
一旦領収書を受け取り食事の支払いが済めば、場合によって団体は店舗から退出することもできる［３７０］。
【０１１０】
現金不要支払い媒体のみを受け付ける店舗用の端末解決法の過程論理が、図６．１．２．１に明記されている。手順は団体が店舗に来店するところからはじまっている［１０］。店舗のオーナー自身の選択により顧客が自らテーブルにつき過程をはかどらせ経費を節約することのできる自動的座席配置システムを使用するかどうかが決められる［２０］。もし、店舗が自動着席案内システムを使用している場合［２０：はい］、図８．１．３．１の手順に進み［３０］、その後団体はテーブルにつくことになる［２３０］。もしその店舗がこのシステムを用いない場合［２０：いいえ］、従業員が団体の人数と喫煙するかどうかを確認することが必要となる［４０］。団体の情報をシステムに入力した後［５０］、メンバーの一人（ここからは、団体幹事と呼ぶ）が（店舗の入り口にある端末にて）現金不要支払い媒体（クレジットカード、スマートカード、前払いカード、電子財布など）［５８］を使用するか選択する必要が生じる。次に幹事は支払い媒体の情報を端末に入力または、転送することになる［６０］。幹事が前払いカードなどの名前が識別できない媒体を用いる場合、システムは幹事の名前を入力するように指示する。それで、幹事の支払い媒体が有効かどうか確認される［６５］。
【０１１１】
図表には示されていないが、支払い媒体が有効でない場合、その他の媒体を使用するように指示される。支払い媒体が有効であれば手順どおりに進める。
【０１１２】
テーブルが利用できれば［７０：はい］、従業員がテーブルを団体のために設定し（提携している端末も）［２１０］団体にテーブル番号を告げる若しくは、テーブルに案内することになる［２２０］。団体はテーブルにつく［２３０］。テーブルが利用できない場合は［７０：いいえ］、団体はゲスト用端末が待ち合いエリアにあるか確認する［８０］。
【０１１３】
店舗が待ち合いエリアに端末を設備している場合［８０：はい］、顧客が利用できるかどうかは、他の顧客が端末使用しているかどうかによる［９０］。待ち合いエリアで他の顧客が端末を使用していない場合［９０：いいえ］、団体は図８．１．３．５の手順でメニューを見たり前もって注文したりできる［１７０］。テーブルが空くと、従業員がシステムより、団体の情報を収集する［２００］。
【０１１４】
店舗が従業員の端末に自動的にどの団体にテーブルが利用できるかを表示するようにシステムを設定することができる。団体がその場に居合わせれば、（店舗の外にいなければ）従業員は団体のためにテーブルを用意する［２１０］。次に従業員がテーブルに案内し［２２０］、団体はテーブルにつく［２３０］。
【０１１５】
待ち合いエリアにゲスト用端末がない［８０：いいえ］、若しくは、端末はあるが他のお客様が、使用中の場合、［９０：はい］、待っている団体が、持ち歩きの可能な装置（携帯電話、ＰＤＡ等）［１５０］を所持していれば、メニューを見たり前もって注文することができる。もし団体の誰も携帯電話等所持していなければ［１５０：いいえ］、その場で従業員がテーブルが空いたのを知らせるまで待たなければならない［１６０］。しかし、団体の誰かが携帯電話等を所持していれば［１５０：はい］、図８．１．３．５に示されるようにメニューを見たり事前注文［１７０］したりすることができる。
【０１１６】
テーブルが空けば、従業員が団体の情報をシステムから読み取る［２００］。既に述べたように、システムが自動的にテーブルがどの団体に利用できるかを表示することもできる。それから、従業員が利用できるテーブルを団体のために設定し（提携している端末も）［２１０］、団体をテーブルに案内し［２２０］、団体はテーブルにつくことになる［２３０］。
【０１１７】
一旦団体がテーブルにつくと、幹事は言語を選択する［２３５］。その店舗の所在する所で通常使われている言語と異なっていても、システムと店舗との設定がされていれば、選択された言語が端末のスクリーンに表示される。
【０１１８】
幹事は来店時に指定した現金不要支払い媒体を選択［２４０］（手順５８）する。次に幹事は必要な情報を入力する若しくはカードを端末に通す、（カードの場合）または、支払いの媒体の情報を端末に転送する［２５０］。幹事は、来店時に選択したものと同じ支払い媒体を使用しなければならない。
【０１１９】
一つの団体がふたつ以上のテーブルにつき、複数の端末を使用することもありえるので（各テーブルにつき一つの端末）、その場合、他のテーブルでそれぞれ独自の支払い媒体を使用しログインする事ができる。しかしながら、団体の幹事がそれを承認し、関係者以外が使用することを防ぐ必要がある。
【０１２０】
一旦団体の幹事が端末にログインすると、店舗が個別に支払うシステムをとっているか確認される［２６０］、もし、不可なら［２６０：いいえ］、幹事は他のログイン手順へと進む［３１０］。だが、店舗が個別の支払いを可能としているなら［２６０：はい］、幹事は、団体のメンバーの希望を確認する［２７０］。個別の支払いを希望する人がいない場合は［２７０：いいえ］幹事は、ログイン段階を終了する［３１０］。もし、個別支払いを希望する人がいれば［２７０：はい］、その人が使用する支払い媒体を選択し［２７８］その情報を端末に入力または転送する［２８０］。その支払媒体は、システムで許可されなければならない［２９０］。もし、受入れられなければ［３００：いいえ］、そのメンバーは、取り消しをするか（図には含まれていない）２７８−２９０の手順を繰り返す。その支払い媒体が許可された場合［３００：はい］、システムは、他にも個別支払いを希望する人がいるか聞いてくる。もしいれば［２７０：はい］ステップ２７８−３００を繰り返す。もしいなければ、幹事はログイン段階を終了する［３１０］。
【０１２１】
幹事はログイン段階を終了すると、割引き及び販売促進コードがあれば入力する。図８．３．３．に示されているようにお得意様感謝得点の資格があるかも見ることもできる［３１５］。顧客は端末で注文メニューを選び［３２０］、図８．３．１の注文手順に沿って注文をする［３３０］。注文の入力を完了すれば幹事は図８．１．３．４に示されるごとく、レストランログアウト手順にそってシステムをログアウトする［３４０］。ログアウト終了後、図８．１．２．１に表されている要領で幹事の選んだ現金不要支払い媒体あてに料金が請求される［３５０］。団体はその店舗から一旦出ることもできる［３６０］。
【０１２２】
図６．１．３．１はレストランにおける端末解決法の表示画面例を表したものである。ここでは、全ての画面は紹介されていない、その都度多少異なるからである、それで顧客が一般的に用いる手順を中心にした画面が表示されている。
【０１２３】
図６．２．１．１は現金と現金不要支払いの両方を許可している店舗における端末解決法の過程論理の図である。手順は顧客の来店のところから始まり［１０］端末を利用した注文手段へと進む［２０］。システムと店舗において、その店舗の所在する国で通常使われている言語以外のものを使える設定がしてあるならば、最初に顧客は好みの言語を選択する［２２］。次に注文する前に顧客は割引きまたは、販売促進コードを入力する、また、図８．３．３に示されているようにお得意様得点の対象になるか見ることができる［２５］。
【０１２４】
図８．３．１、手順２５−１００の注文処理手順に沿って注文を入力し［３０］、その後支払い媒体の選択をする［４０］。現金不要支払い媒体を選択した場合［５０：現金不要支払い］、支払い媒体に関する情報を端末に入力または転送する［６０］。支払手段が有効であるか確認後、料金が選択された手段で請求される［７０］。支払手段が受け入れられれば、［８０：はい］、次の支払後の手順へと進む。
【０１２５】
顧客が現金支払いを選んだ場合［５０：現金払い］、システムは注文番号とバーコードプリントアウトし［１００］、注文システムよりログアウトする［１１０］。顧客は印刷された紙をカウンターに渡す［１２０］。店舗が現金支払い機を導入していれば［１３０：はい］、顧客はバーコードをスキャンする［１４０］。支払機は、支払い金額を表示する［１５０］。現金を支払機に挿入後［１６０］、釣り銭があれば出てくる［１７０］。そして論理は下記の「支払い後の論理」へと進む。
【０１２６】
店舗が現金支払い機を導入していない場合は［１３０：いいえ］、顧客は従業員にその紙を渡し［１８０］、従業員がシステムでバーコードをスキャンする［１９０］。その後顧客が料金を支払い［２００］、従業員が支払いを記録する［２１０］。そして論理は、下記の「支払い後の論理」に従って進む。
【０１２７】
支払後の論理
システムは顧客が注文システムからログアウトすると直ぐに顧客の注文内容とバーコードのついている領収書をプリントアウトする［２２０］。図８．３．４で表されているように同時に得点等の情報も新しくされ［２５３］、図８．３．１のオーダー処理手順（手順１１０−３９０）注文の連絡がされ、店舗は料理に取り掛かる［２６０］。この間に顧客は領収書を受け取り［２３０］番号の呼ばれるのを待つ［２４０］。注文が出来た時点で、店舗が注文番号表示パネルを使用していなければ［２７０：いいえ］、従業員が顧客の注文番号を呼び出す［２９０］。しかし店舗が注文番号表示パネルを使用していれば［２７０：はい］、顧客の番号が自動的に表示される［２８０］。注文品ができたことを知らされると、顧客はカウンターで注文品をピックアップする［３００］。顧客が領収書を従業員に渡すと［３１０］、従業員はそれをスキャンする［３２０］。この様に、二人の顧客が殆ど同時に良く似た注文をしたときにどの注文がどの顧客のものか解らなくなることを確実に防ぐ。
【０１２８】
従業員がバーコードをスキャンし、注文を確かめた上で顧客に注文されたものを手渡す［３３０］。顧客は、テイクアウトするか空いている席を見つけて店内で食事する事になる（店内で食事できる場合）［３４０］。
【０１２９】
図６．２．２．１では、現金不要支払いのみを導入している店舗における端末解決法の過程論理を解説している。この場合も、顧客の来店するところから始まり［１０］注文用の端末の使用へと進む［２２］。最初に顧客は言語を選択する［２２］、その店舗の所在する国で通常使われている言語と異なっていても、システムと店舗との設定がされていれば、選択された言語が端末のスクリーンに表示される。次に割引きまたは販売促進コードがあれば入力する、また図８．３．３の要領でお得意様得点の対象になるかどうかも見ることができる［２５］。顧客が全ての注文を入力した時点で［３０］（図８．３．１注文過程論理の２５−１００）、現金不要支払いの手段を選択する［４０］。その手段の情報を端末に入力または転送した後［５０］、システムが有効かどうか確認した上で請求額を選ばれた手段へ請求する［６０］。
【０１３０】
もし選択された支払い媒体が受け入れられない場合［７０：いいえ］、顧客は別の支払い媒体を選択し手順の５０−７０を繰り返すか注文を取消すことになる。支払い媒体が許可された場合［７０：はい］、システムは顧客の注文番号と、それに連結するバーコードを含む領収書をプリントアウトする［８０］。その直後に顧客はシステムをログアウトする［１１０］。同時に顧客のお得意様得点も図８．３．４で解説されている様に新しくされ［１１３］、注文内容が連絡され、図８．３．１の注文処理の手順（ステップ１１０−３９０）に沿って処理が行われる［１２０］。この間、顧客は領収書を受け取り［９０］注文番号を呼ばれるまで待つ［１００］。注文品が準備できると、店舗が注文番号表示パネルを導入していない場合は［１３０：いいえ］、従業員が顧客の注文番号を呼び出す［１４０］。しかし、店舗が注文番号表示パネルを導入している場合［１３０：はい］は、注文品ができると自動的にパネルに注文番号が表示される［１５０］。どちらかの形で知らせを受けると顧客はカウンターで注文をピックアップする［１６０］。顧客が従業員に領収書を渡すと［１７０］従業員はバーコードをスキャンする［１８０］。またこのようにして、二人の顧客が殆ど同時に良く似た注文をしたときにどの注文がどの顧客のものか解らなくなることを防ぐ。一旦従業員が顧客のバーコードと注文を確認すると従業員は顧客の注文を手渡す［１９０］。顧客は、テイクアウトするか空いている席を見つけて店内で食事する事になる（店内で食事できる場合）［２００］。
【０１３１】
図６．２．３．１は、店舗での端末解決法の表示画面例を解説している。ここでは、全ての画面は紹介されていない、その都度多少異なるからである、それで顧客が一般的に用いる手順を中心にした画面が表示されている。
【０１３２】
図７．１．１．１では、現金払いと現金不要支払いの両方を導入しているレストランでの携帯機解決法の過程論理を解説している。手順としては、団体が来店するところから始まる［１０］。店舗のオーナーの選択により顧客が自分でテーブルに着き注文過程をはかどらせ、人件費を節約することのできる自動着席案内システム［２０］が取り入れられている場合とそうでない場合がある。店舗がこのシステムを導入している場合［２０：はい］、図８．１．３．１に示された手順に進む［３０］。それからは「顧客はテーブルへ」と題した下記の論理へと進む。もし、店舗がこのシステムを導入していない場合は［２０：いいえ］、従業員が団体の幹事の名前、人数及び喫煙の有無を尋ねる［４０］。
【０１３３】
従業員が団体の幹事の名前、人数及び喫煙の好みを有無をシステムに入力する［５０］。情報を得るとシステムは顧客の団体に来店コードを発行する［６０］。それから従業員が来店コードとバーコードの記載されたスリップをプリントアウトし団体の幹事に渡す［７０］。ステップ５０で来店コードが発行された後、システムは自動的にその情報の記載された券をプリントアウトするようにもできる。
【０１３４】
次に従業員がテーブルの利用状況を確認する［８０］。テーブルが空いていれば［８０：はい］、次の手順は「従業員がテーブルを使用可能にする」と題した個所に述べられている。
【０１３５】
テーブルが空いていない場合［８０：いいえ］、団体は図８．１．３．５に添ってメニューを閲覧したり事前注文をしたりもできる［１００］。これで、店舗がゲスト用端末を導入していないという推定がされる。しかしながら、店舗が端末を導入していれば、顧客は他の顧客が端末を使用していない限り、端末を使ってメニューを見たり事前注文をしたりできる。テーブルが空くと従業員はシステムより団体の情報を読み取る［１４０］。前述の様に、システムはテーブルが空くと自動的に団体の情報を掲示することもできる。
【０１３６】
従業員がテーブルを使用可能にする
従業員は団体の来店コードを空いているテーブル用にアクティブ化し［１５０］、団体をテーブルに案内する［１６０］。
【０１３７】
顧客はテーブルへ
団体はテーブルへと向かう［１７０］。その団体が既にシステムにログインしている場合［１８０：はい］、「テーブル番号転送確認」と題した個所へと進む。
【０１３８】
団体がシステムにまだログインしていない場合「１８０：いいえ」、図７．３．１の携帯機ログイン登録論理に添ってログインする［１９０］。後にその顧客は図７．３．２の店舗内ログイン論理に示されている要領でレストランのシステムにログインする［２００］。
【０１３９】
テーブル番号転送確認
テーブル番号が既に携帯機に転送された場合［２０５：はい］、論理は「その他ログイン手順の終了」と題した個所へと進む。これは、顧客が自動着席案内システムを導入している店舗で携帯機を使用しており、顧客のテーブル番号が短波の電子通信の手段（例、赤外線通信若しくは、ブルートゥースなど）を通じて転送できる場合のみである。
【０１４０】
一方テーブル番号がまだ携帯機に転送されていない場合［２０５：いいえ］、顧客は項目を選択してテーブル番号を入力する［２１０］。システムログインにおいて、今回発明された携帯機の実施において顧客が言語を選択することは、端末の実施の場合のようには必要でないことに注意を払う必要がある。これは、顧客が携帯機に注文システムを登録する時点で的確なバージョンのプログラムまたは、ウエブページを好みの言語でダウンロードするからである。
【０１４１】
続いて図表の論理では、顧客が次にテーブル番号を入力する［２２０］。システムが団体のテーブル番号を認識していても団体が二つ以上のテーブルに別れる場合は、テーブル番号を入力する必要がある。その場合、顧客がテーブル番号を入力しなければ、従業員がどの注文をどのテーブルに届けるか解らなくなる。また、顧客がテーブル番号を入力することで、更なる支払い安全確認ともなる。
【０１４２】
その他のログイン手順
その他のログイン手順終了後［２３０］、顧客は割引きコードがあれば入力し、また図８．３．３で解説されているようにお得意様得点に該当するかも見ることができる［２３５］。次に顧客は携帯機［２４０］で注文メニューを選択する。
【０１４３】
次のステップ［２５０］、顧客の注文の仕方は、その店舗がシステムに明細なメニューリストを設定しているかどうかによる。もし、その店舗が無線機だけの注文システムを導入しており、同時に従来の印刷された形のメニューも使用している場合、システムには明細なメニューを載せていないことが多い。その様な場合［２５０：いいえ］や顧客がメニューのダウンロードを好まない場合は、電子メニューによる品目の選択の代りに印刷されたメニューから品目コードによって注文することになる［２７０］。注文手順論理、図８．３．１では、ステップ３０以外は同様で、表示されたリストから品目を選択する代わりに品目コードを入力することになる。このオプションの特徴は、より伝統的な店舗の顧客に実際に印刷されたメニューをその店舗全体の雰囲気を失わずして、しかも無線で注文することを可能にすることである。また、この特徴を店舗が徐々に伝統的な手段から電子メニューのみの手段へと切り替える中継ステップとも考えられる。
【０１４４】
店舗がシステムに明細なメニューを載せている場合［２５０：はい］、顧客はスタンダード手段で注文することになる［２７０］−コードを使用せずにリストから品目を選択する−図８．３．１注文手順論理に明記されている。注文を完了した時点で、図８．１．３．４のレストランログアウト論理の要領で顧客はシステムをログアウトする［２８０］。団体は支払い処理、図８．１．１．１に解説されているように支払いを済ませ領収書をカウンターで受け取る［９０］。食事の支払いが済み、領収書を受け取った時点で、その店舗で了承されていれば、顧客は店舗を一旦出ることが出来る［３００］。
【０１４５】
図７．１．２．１では、現金不要支払い媒体を導入しているレストランでの携帯機解決法の過程論理を詳しく表している。この手順も団体が来店する所から始まる［１０］。店舗のオーナーの好みにより顧客自身でテーブルに着き注文処理をはかどらせ、人件費を節約することのできる、自動着席案内システムを使用するかどうかが選ばれる［２０］。もし、その店舗がこのシステムを導入している場合［２０：はい］、論理は図８．１．３．１に進み［３０］、その後「顧客はテーブルへ」と題した個所に概略された論理へと進む。
【０１４６】
もし、その店舗がこのシステムを導入していない場合［２０：いいえ］、従業員が団体の幹事の名前と人数、喫煙の有無を尋ねる［４０］。そして従業員がシステムにそれらの情報を入力する［５０］。従業員はテーブルの利用状況を確認する［６０］。テーブルが空いていれば［６０：はい］、「従業員がテーブルを使用可能にする」と題した個所で解説された論理へと進む。
【０１４７】
テーブルが空いていなければ［６０：いいえ］、団体は図８．１．３．５に沿って、メニューを見たり、事前注文をしたりできる［７０］。この場合も、店舗がゲスト用端末を使用していないことを前提としている。店舗がゲスト用端末を導入していれば他の顧客が使用中でない限り、その端末でメニューを見たり、前注文をすることができる。テーブルが空くと、従業員がシステムからその団体の情報を読み取る［８０］。前述のように、システムは自動的にテーブルが割り当てられた団体を表示することもできる。
【０１４８】
従業員がテーブルを使用可能にする
従業員は団体の来店コードを空いているテーブル用にアクティブ化し［９０］、団体をテーブルに案内する［１００］。
【０１４９】
顧客はテーブルへ
団体はテーブルへと向かう［１１０］。その団体が既にシステムにログインしている場合［１２０：はい］、「テーブル番号転送確認」と題した個所へと進む。団体がシステムにまだログインしていない場合［１２０：いいえ］、図７．３．１の携帯機ログイン登録手順に添ってログインする［１３０］。後にその顧客は図７．３．２の店舗内ログイン手順に示されている要領でレストランのシステムにログインする［１４０］。
【０１５０】
テーブル番号転送確認
テーブル番号が既に携帯機に転送された場合［１４５：はい］、論理は「その他ログイン手順の終了」と題した個所へと進む。これは、顧客が自動着席案内システムを導入している店舗で携帯機を使用しており、顧客のテーブル番号が短波の電子通信の手段（赤外線通信、ブルートゥースなど）を通じて転送できる場合のみである。
【０１５１】
一方テーブル番号がまだ携帯機に転送されていない場合［１４５：いいえ］、顧客は項目を選択してテーブル番号を入力する［１５０］。システムログインにおいて、今回発明された携帯機の実施において、顧客が言語を選択することは端末の実装には必要でないことに注意を払う必要がある。これは、顧客が携帯機に注文システムを登録する時点で的確なバージョンのプログラムまたは、ウエブページを好みの言語でダウンロードするからである。
【０１５２】
図表の論理では、顧客が次にテーブル番号を入力する［１６０］。システムが団体のテーブル番号を認識していても団体が二つ以上のテーブルに別れる場合は、テーブル番号を入力する必要がある。その場合、顧客がテーブル番号を入力しなければ、従業員がどの注文をどのテーブルに届けるか解らなくなる。また、顧客がテーブル番号を入力することで、更なる支払い安全確認ともなる。
【０１５３】
その他のログイン手順の完結
ログイン手順を終了の後［１７０］、顧客は割引きコードや販売促進コードがあれば入力する、また図８．３．３に解説されているように、お得意様得点に該当するかも見ることができる［１７５］。次に顧客は携帯機でメニューを選択する［１８０］。
【０１５４】
このステップ［１９０］では、顧客がどのようにして注文をするかは、その店舗がシステムに明細なメニューを載せているかどうかによる。店舗によっては、無線機用の注文システムを導入しており、同時に従来の印刷された形のメニューも使用している場合、システムには明細なメニューを載せていないことが多い。
【０１５５】
その様な場合［１９０：いいえ］、や顧客がメニューのダウンロードを好まない場合は、電子メニューによる品目の選択の代りに印刷されたメニューから品目コードによって注文することになる「２００」。注文手順論理、図８．３．１では、ステップ３０以外は同様で、表示されたリストから品目を選択する代わりに品目コードを入力することになる。このオプションの特徴は、より伝統的な店舗の顧客に実際に印刷されたメニューをその店舗全体の雰囲気を失わずして、しかも無線で注文することを可能にすることである。また、この特徴を店舗が徐々に伝統的な手段から電子メニューのみの手段へと切り替える中継ステップとも考えられる。
【０１５６】
店舗がシステムに明細なメニューを載せている場合［１９０：はい］、顧客はスタンダードな手段で注文することになる［２００］−コードを使用せずにリストから品目を選択する−図８．３．１注文手順論理に明記されている。注文を完了した時点で、図８．１．３．４のレストランログアウト論理の要領で顧客はシステムをログアウトする［２２０］。団体は支払い処理、図８．１．１．１に解説されているように支払いを済ませ領収書をカウンターで受け取る［９０］。食事の支払いが済み、領収書を受け取った時点で、その店舗で了承されていれば、顧客は店舗を一旦出ることが出きる［２３０］。
【０１５７】
図７．１．３．１では、レストランにおける携帯機の解決法の表示画面例を詳しく表している。ここでは、顧客がよく見ることになる手順処理論理を視覚を通して説明する図で、スクリーンの個々の部分は変わることがあるため示されていない。ここでは、顧客はメニューを用いて品目を注文に加えていることに注意したい。しかしながら店舗や顧客の選択により顧客が品目コードを入力することによって注文を加えることも可能である。
【０１５８】
図７．２．１．１では、現金不要支払い媒体を導入しているレストランでの携帯機の解決法の過程論理を詳しく表している。顧客の来店後［１０］、顧客はシステムにログインし［２０］（図７．３．１、システムログイン登録に基づいて）、それから店舗のシステムにログインする［３０］（図７．３．２、店舗ログイン論理に沿って）。システムログインのおいて、今回発明された携帯機の実施において、顧客が言語を選択することは端末の実施のようには必要でないことに注意を払う必要がある。これは、顧客が携帯機に注文システムを登録する時点で的確なバージョンのプログラムまたは、ウエブページを好みの言語でダウンロードするからである。図表の論理では、次に顧客が割引きコードや販売促進コードを持っている場合は入力する、またお得意様得点に該当するかも図８．３．３に沿って［３５］、見ることができる。その後、顧客は自らの機器［４０］で注文メニューを選択する。
【０１５９】
その店舗が無線機用の注文システムを導入しており（端末は無し）、同時に従来の印刷された形のメニューも使用している場合、システムには明細なメニューを載せていないことが多い（例、携帯機に）。その様な場合［４５：いいえ］、電子メニューによる品目の選択の代りに印刷されたメニューから品目コードによって注文することになる「５０」。注文過程論理、図８．３．１では、ステップ３０以外は同様で、「表示されたリストから品目を選択する」代わりに「品目コードを入力する」ことになる。このオプションの特徴は、より伝統的な店舗の顧客に実際に印刷されたメニューをその店舗全体の雰囲気を失わずして、しかも無線で注文することを可能にすることである。また、この特徴を店舗が徐々に伝統的な手段から電子メニューのみの手段へと切り替える中継ステップとも考えられる。
【０１６０】
店舗が、明細なｅ−メニューを提供している場合［４５：はい］、スタンダードな手段で顧客は注文をする［５０］−リストから品目を選択する手段、コードは使用しない−図８．３．１注文過程論理参照。引き続きの過程論理は顧客がログイン時［６０］に指定した支払い媒体によるものである。
【０１６１】
現金不要支払い媒体での支払い処理
顧客が現金不要支払い媒体を用いているとき［６０：現金不要支払い］、システムは顧客の支払い媒体へ料金の請求をし［７０］、顧客の支払状況をシステムでアップデイトし［８０］、図８．３．４の要領で得点等もアップデイトし［８５］、顧客に領収書が必要かどうか尋ねる［９０］。顧客は、領収書の必要の有無を指定し、もし必要であれば、どのようなタイプの領収書が必要かを指定する［９２］。もし領収書が不要な場合［１００：いいえ］、論理は以下の「現金不要支払い：領収書発行後の論理」に従って進む。領収書が必要な場合［１００：はい］、顧客は領収書のタイプを選択しなければならない［１１０］。電子メールのみの領収書を希望する場合［１１０：電子メール］、システムは領収書を顧客に電子メールで送付する［１３０］。次の論理は以下の項目「現金不要支払い：領収書発行後の論理」に明記される過程に従って続く。顧客が印刷された領収書と電子メールでの領収書を両方希望する場合［１１０：電子メール＆印刷］、領収書は顧客に電子メールで送付される［１２０］。顧客は、現金支払いと同様に、以下の「現金支払い」と題した項目の手順２００に始まる手続きに従わなければならない。顧客が印刷された領収書だけを希望する場合［１１０：印刷］、論理は以下の「現金支払い」と題した項目の手順２００に続く。
【０１６２】
現金不要支払い：領収書発行後の論理
顧客の注文はシステムサポートセンターのインターネットのウエブサイトを経由して行われているため、システムは顧客の注文情報と支払い状況を施設の社内サーバに送信する［１４０］。８０２．１１などの無線技術、ブルートゥースなどを利用して顧客の注文と支払い状況を直接施設の社内サーバに送信することが、本発明の自然な発展型であろうが、現在の技術では限界があり、セキュリティへの警戒から、現状では上に明記したような手段をとる。
【０１６３】
施設がいったん注文情報を受信すると、２つの異なった過程が同時に起こる。一つは、以下の「注文の転送後」と題した項目に記述され、もう一つは、顧客と顧客の機器に焦点を当てたものであり、後述する。システムは、仮の（支払い済み）「ｅ−チケット」（電子チケット）を顧客の携帯機上に表示する［１６０］。ｅ−チケットには、顧客の支払い状況、修正された注文番号、場合によってバーコードが記載されている。注文番号はとても単純であるので（たとえば「１２３」またはその他の短いアルファベットと数字の組み合わせ）、何者かが自宅で複製をして複製された画像を自分の携帯機に送信することが可能である。そのため、システムは従業員が注文を確認するのに使用する元の注文番号の末尾に、短いランダムのアルファベットの組み合わせを追加する。これは、「修正された注文番号」と呼ばれる。現在の技術に限界があるためと、様々な携帯機の画面の素材（バーコートの読み取りが可能であるものとないものがある）が存在するため、バーコートの記載は任意である。
顧客は単に自分の注文番号が呼ばれるか、または施設の注文受取画面があれば、そこに番号が表示されるのを待つ［１７０］。顧客の注文が処理中または準備ができたとき、次の論理は、以下の「注文転送後」の項目に詳細が記される。
【０１６４】
現金支払い
顧客が現金支払いを希望するとき［６０：現金払い］、システムは領収書の必要の有無を尋ねる［１８０］。そして顧客が領収書を必要と指定する場合は、どのタイプの領収書が必要かを尋ねる［１９０］。その後、システムは顧客の注文情報と支払い状況を施設の社内サーバに送信する［２００］。仮の（未払い）ｅ−チケットが顧客の携帯機上に表示される［２１０］。この仮のｅ−チケットは、顧客の支払い状況が「未払い」であり注文番号が修正されたものではなく、元の注文番号が表示されるという点で、先に述べたｅ−チケットとは異なる。ｅ−チケットの支払い状況は「支払い済み」に設定され、修正された注文番号は顧客が注文分の支払いを済ませるまで表示されない。顧客が以前に現金不要支払い媒体を利用して支払いを行い、領収書のみを必要とするときは、支払い状況は「支払い済み」と設定され、表示される注文番号は修正されたものになる。
【０１６５】
次に、顧客は支払い／領収書カウンターへ進む［２２０］。施設が現金預入／受入機を利用している場合［２３０：はい］、顧客は自分のｅ−チケットの情報を機械に入力／スキャン／転送する［２４０］。顧客が自分の注文分を現金不要支払い媒体を利用して既に支払った場合［２５０：はい］、システムは顧客用領収書を印刷する［２６０］。顧客は領収書を受け取った後［２６２］、自分の注文番号が呼ばれる／表示されるのを待つ［３９０］。注文の品が準備できると、論理は以下の「注文転送後」と題した項目に記述される手順４１０に続く。もし顧客がまだ注文分の支払いを行っていない場合［２５０：いいえ］、現金預入／受入機は顧客が支払うべき金額を表示する［２７０］。顧客が支払うべき金額を機械に挿入した後［２８０］、論理は以下の「現金支払い後」の項目へ続く。
【０１６６】
施設が現金預入／受入機を利用していない場合［２３０：いいえ］、顧客はｅ−チケットの情報を従業員の機器または端末に提示／スキャン／転送する［２９０］。顧客のｅ−チケットの情報が従業員の機器または端末に直接スキャンまたは転送されない場合、従業員は顧客の注文番号を直接システムに入力する［３００］。顧客がすでに注文分の支払いを現金不要支払い媒体を使用して行っている場合［３１０：はい］、過程は以下の「現金支払い後」の手順３６０の論理に続く。顧客がまだ支払いを行っていない場合［３１０：いいえ］、従業員に注文分の料金を支払う［３２０］。従業員が顧客の支払いをシステムに入力した後［３３０］、過程は以下の「現金支払い後」の論理へと続く。
【０１６７】
現金支払い後
この時点で、システムは顧客の支払い状況を更新する［３４０］。その後、３つの過程が同時に起こる。まずはじめの過程は「注文転送後」と題した項目に記述される。２つめは、図８．３．４に記述されるように、システムが顧客の報奨ポイントを更新する［３４５］。最後は顧客が領収書を必要と指定したかどうかである［３５０］。顧客が以前に領収書が必要であると指定した場合［３５０：はい］、システムは適切なアクションをとる（つまり、適切な領収書を電子メールで送信そして／または印刷する）。領収書が不要の場合［３５０：いいえ］、顧客は自分の携帯機上で更新を選択する［３７０］。システムはｅ−チケットを顧客の携帯機上で更新する［３８０］。ｅ−チケットは、注文状態が「支払い済み」であり、注文番号は追加されたアルファベットと数字を含むはずである。
顧客は、自分の注文番号が呼ばれるか表示されるまで待つ必要がある［３９０］。顧客の注文が用意できると、論理は以下の「注文転送後」と題した項目の手順４１０に従って進む。
【０１６８】
注文転送後
図８．３．１における注文処理の論理の手順１１０−３９０に従って、施設は注文を処理する［４００］。従業員が顧客の注文番号を呼ぶか、またはシステムが施設の注文受取の画面に注文番号を表示する［４１０］。顧客は注文受取カウンターへと進む［４２０］。利用可能な技術により、顧客は自分の携帯機上のｅ−チケットを従業員に提示するか、自分の携帯機上のバーコードをシステムのバーコードリーダーにスキャンするか、または施設の端末や機器に自分のｅ−チケットの情報を伝送する［４３０］。従業員は顧客のｅ−チケットを確認し［４４０］、注文品を顧客に渡す［４５０］。注文品を受け取った後、顧客は施設を出るか、施設内で自由に着席する［４６０］。
【０１６９】
図７．２．２．１は、現金不要支払い媒体のみを許容する店舗向けの携帯機解決法の過程論理を詳述したものである。顧客が施設に入店した後［１０］、（図７．３．１に明記されるシステムログイン−登録の論理に従って）システムにログインし［２０］、その後（図７．３．２の施設にログインする論理に明記されるように）施設のシステムにログインしなければならない［３０］。本発明における携帯機の稼動においては、システムログイン時に、ターミナルの稼動と異なり、顧客は使用言語を選択する必要がないことに注意が必要である。これは、顧客がまず自分の携帯機を注文システムを利用するために登録するため、適切なバージョンのプログラムをダウンロードしたり、サポートされていれば自分の使用言語の適切なウエブページにアクセスしているからである。当図の論理に続いて、次に顧客は、図８．３．３に詳細が示される得意客／報奨の資格を満たすかどうかを確認し、更に、割引や販促コードを持っていればそれを入力する［３５］。顧客は注文メニューを自分の機器上で選択する［４０］。
【０１７０】
無線機器専用の注文システムを提供したり、様々な理由から従来的な表示／印刷されたメニューを使用することを希望する一部の施設では、システムに品目の詳細を提供しないこともある。そのような場合［４５：いいえ］または顧客が全メニューを閲覧／ダウンロードすることを希望しない場合、電子メニューから品目を選択するのではなく、表示／印刷されたメニューから単に品目コードを入力することによって注文が行われる［５０］。図８．３．１の注文処理の論理は、手順３０において表示されたリストの中から「品目を選択する」のではなく「品目コード」を入力するという点で本質的に同じである。これは、より保守的な施設が顧客からの無線受注を利用することを選択的に可能にする機能であるが、それでもなおメニューを「見て感じる」ことがこのような施設での雰囲気に重要な役割を果たす。この機能は、施設が電子メニューのみのシステムへと徐々に移行していく際の中間ステップとも考えられる。施設がシステムの中に詳細にわたるｅ−メニューを提供している場合［４５：はい］、図８．３．１の注文処理の論理に詳述されるように顧客は標準的な手段で−つまり、コードを使用するのではなく注文する品目をリストの中から選択することで注文を行う［５０］。
次に、システムは注文金額を顧客の現金不要支払い媒体に請求し［６０］、システム上の顧客の支払い状況を更新する［７０］。システムが顧客の携帯機上で領収書が必要かどうか尋ね［１００］、顧客の報奨ポイントを更新する［７５］と同時に、図８．３．４に明記されるようにシステムは顧客の注文情報と支払い状況を施設の社内サーバにも送信し［８０］、（図８．３．１の注文処理の論理の手順１１０−３９０に従って）施設は注文の処理を開始する［９０］。顧客の注文及び支払い情報を直接施設の社内サーバに８０２．１１、ブルートゥースのようなワイアレスの技術経由で送信することも可能であるが、現在の技術では限界があり、セキュリティへの警戒から、現状では上に明記したような手段になる。
【０１７１】
注文が処理されているあいだ、顧客は自分の携帯機上で領収書が必要かどうかを指定する［１１０］。領収書が不要の場合［１２０：いいえ］、過程は以下の「領収書の仕様の後の論理」と題した項目に明記される論理に続く。領収書が必要な場合［１２０：はい］、顧客は領収書のタイプを選択しなくてはならない［１４０］。電子メールバージョンのみの領収書を希望の場合［１４０：電子メール］、顧客は領収書の送付先の電子メールアドレスを指定そして／または確認しなければならない［１５０］。確認の後、システムは、領収書を顧客に電子メールで送付する［１６０］。過程は、以下の「領収書の仕様の後の論理」と題した項目で明記される論理へと続く。
【０１７２】
顧客が印刷された領収書と電子メールでの領収書と両方を希望する場合も［１４０：電子メール＆印刷］、同様に、顧客はまず領収書の送付先の電子メールアドレスを指定そして／または確認する［１７０］。システムが指定された電子メールアドレスへ領収書を送付した後［１８０］、過程は以下の「印刷された領収書の論理」と題した項目に明記される論理へ続く。印刷された領収書のみを希望の場合［１４０：印刷］、過程は「印刷された領収書の論理」と題した項目に明記された論理へ続く。
【０１７３】
印刷された領収書の論理
次にシステムは、顧客の携帯機上で施設の領収書発行機へ進むよう誘導する［１９０］。顧客がｅ−チケットの情報を機械に入力／スキャン／転送した後［２００］、システムは、顧客用の印刷された領収書を発行する［２１０］。ｅ−チケットには、顧客の支払い済み状態、修正された注文番号、場合によりバーコードが記載されている。注文番号はとても単純であるので、（例えば「１２３」またはその他の短いアルファベットと数字の組み合わせ）、何者が自宅で複製をして複製された画像を自分の携帯機に送信することが可能である。そのため、システムは従業員が注文を確認するのに使用する元の注文番号の末尾に、短いランダムのアルファベットの組み合わせを追加する。これは、「修正された注文番号」と呼ばれる。現在の技術に限界があるためと、様々な携帯機の画面の素材（バーコートの読み取りが可能であるものとないものがある）が存在するため、バーコートの記載は任意である。
顧客が領収書を受け取った後［２２０］に開始する過程は、以下の「領収書の仕様の後の論理」と題した項目に明記される。
【０１７４】
領収書の仕様の後の論理
システムが顧客の携帯機上でのｅ−チケットを表示した後［２４０］、顧客は自分の注文番号が呼ばれるか、表示されるのを待たなければならない［２５０］。顧客の注文が準備できたとき、従業員は顧客の注文番号を呼ぶかまたはまたは施設の「注文受取」画面があれば、そこに注文番号を表示する［２６０］。そして顧客はカウンターへ注文した品を受け取るため進む［２７０］。しかし、注文品を受け取る前に、顧客は自分のｅ−チケットの情報を従業員（または従業員の機器または端末）に提示／スキャン／転送しなければならない［２８０］。次に従業員は、顧客のｅ−チケットを確認する［２９０］。確認ができたら、従業員は注文品を顧客に渡す［３００］。顧客は施設を出るか、施設内で空席があれば自由に着席する［３１０］。
【０１７５】
図７．２．３．１は店舗における携帯機解決法の画面の見本を詳述したものである。この図は細部に変更がある可能性があり、また顧客がどのような画面を見ることになるかの進行過程の論理をビジュアルでサポートするために提供されているため、画面の種々の部分については、記述しない。この詳述において、顧客は品目コードを使用してメニュー品目を注文に追加していることに注意する。しかし、施設の希望と顧客の希望によっては、顧客がメニューから品目を選択して注文に追加することも可能である。
【０１７６】
図７．３．１は携帯機のシステムログインと登録過程の論理を詳述したものである。顧客がシステムを利用するのが初回ではない場合［１０：いいえ］、注文システムのアプリケーションや携帯機上のウエブページにアクセスするだけでよい［２００］。すると顧客が携帯機を起動したときに自動ログインさせることが可能かどうかの確認が行われる［２１０］。自動ログインとは、顧客がマニュアルで入力して自分で送信することを必要とせず、単にシステムが自動的に顧客のログイン情報（つまりＩＤとパスワード）をサーバに送信することをいう。これは、幾分顧客のセキュリティの嗜好とこの機能が携帯機に付帯しているかどうかによる。顧客が自動ログインを可能にしていなかった場合［２１０：いいえ］、論理は以下の「ログイン論理」と題した項目へ続く。一方、顧客が自動ログインを可能にしていた場合［２１０：はい］、論理は以下の「ログインを確認」と題した項目へ続く。
【０１７７】
しかし、顧客がシステムを初めて利用する場合［１０：はい］、自分の携帯機を使用してシステムサポートセンターのウエブサイトにアクセスする必要がある［２０］。そして顧客はサービスを利用できる会員になるために個人情報を登録する［２５］。次に、顧客はシステムの注文アプリケーションをダウンロードするか、または次に通信するウエブページにアクセスする［３０］。注文アプリケーションは顧客の携帯機にダウンロードされるプログラム、または顧客が様々なウエブページにアクセスするウエブサービスとして配備可能であることを強調しておかなくてはならない。であるから、この図は注文システムを利用するどちらかの手段に適用される論理を明記したものである。しかし、このシステムは、顧客が携帯機にアプリケーションをダウンロードする手段を優先する。なぜなら、携帯機にアプリケーションの中核と関連データを保存すると、ネットワーク上を行き来するデータ量を減少させ、顧客のコスト（送信されるデータのパケット毎に支払う）削減につながり、反応時間も短縮するためである。
次に、顧客はその他の個人情報と嗜好を登録する必要がある［４０］。次に、支払いが携帯機の携帯電話ゲートウェイプロバイダーまたはインターネットサービスプロバイダー（顧客の購入が請求書に記載されるモバイルプロバイダー会社で、顧客に代わって業者に支払いを行うプロバイダー）によって処理されることが可能なため、モバイルプロバイダーの支払いメカニズムが支払いを取り扱うために使用されているかどうかを確認しなければならない［４５］。もしされていれば［４５：はい］、論理は以下の「顧客情報の保存」と題した項目に明記される論理に続く。反対に、携帯機プロバイダーの支払いメカニズムが使用されていない場合［４５：いいえ］、システムは顧客が現金で支払うときに起こる余計な手続きと待ち時間を省略する利点のある現金不要支払い媒体を登録したいかどうか尋ねる［５０］。顧客が現金不要支払い媒体を今回は登録したくない場合［５０：いいえ］、論理は以下の「顧客情報の保存」と題した項目に明記された論理へ続く。
【０１７８】
しかし、顧客が現金不要支払い媒体の登録を希望する場合［５０：はい］、現金不要支払い媒体の情報を入力する［６０］。
【０１７９】
現金不要支払い媒体の確認
顧客は現金不要支払い媒体の情報が正しいかどうか確認する［７０］。顧客が入力された情報に間違いがあると判断した場合［８０：いいえ］、現金不要支払い媒体の情報を修正し［９０］、論理は上記の「現金不要支払い媒体の確認」と題した項目へ戻る。逆に、情報が正しい場合［８０：はい］、システムは現金不要支払い媒体を有効にする［１００］。顧客の現金不要支払い媒体が許容されると［１１０：はい］、過程は以下の「顧客情報の保存」と題した項目へ続く。
【０１８０】
現金不要支払い媒体が許容されない場合［１１０：いいえ］、現金不要支払い媒体のみを許容するシステムかどうかにより、顧客には２つの選択肢がある。システムが現金不要支払い媒体のみ（つまり現金不可）を許容する場合［１２０：はい］、顧客は媒体の情報を修正する必要があり［９０］、論理は上記の「現金不要支払い媒体の確認」と題した項目へ戻る。システムが現金も許容する場合［１２０：いいえ］、顧客は現金を使用するかまたは現金不要支払い媒体の登録を再試行するか尋ねられる［１３０］。顧客が現金不要支払い媒体の登録を再試行したい場合［１３０：いいえ］、現金不要支払い媒体を修正しなければならず［９０］、その後論理は上記の「現金不要支払い媒体の確認」と題した項目へ戻る。一方、顧客が単純に現金を使用したい場合（つまり、顧客がその他の現金不要支払い媒体を所有しない場合）［１３０：はい］、現金を使用すればよく、過程は以下の「顧客情報の保存」と題した項目に明記されるように続く。
【０１８１】
顧客情報の保存
システムは顧客の嗜好その他の情報を保存する［１４５］。顧客が注文機能の利用を当面希望しない場合［１５０：いいえ］、システムはメインメニューまたはウエブサイトを表示する［１６０］。しかし、顧客が直ちにシステムの利用を希望する場合［１５０：はい］、論理は次のように続く。
【０１８２】
ログインの論理
顧客はログイン情報を入力する［３００］。
【０１８３】
ログインの確認
システムは顧客情報が正しいと判断した後［３０２］、システムが施設ＩＤを顧客の携帯機に自動転送したかどうかの確認を行う［３０５］。この確認は、施設が自動着席案内システムを採用しており、システムが施設ＩＤを携帯機に、おそらく短距離の電子通信媒体（つまり赤外線やブルートゥース）を経由して自動転送する場合に行われる。
【０１８４】
施設ＩＤが顧客の携帯機に自動転送されない場合［３０５：いいえ］、顧客は施設ＩＤを入力するかまたは予め存在する登録施設のリストから施設を選択しなければならない［３１０］。しかし、施設ＩＤが顧客の携帯機に自動転送された場合には［３０５：はい］、顧客はシステムにログイン入力する必要はない。
【０１８５】
図７．３．２は、携帯機の施設へのログインの過程論理を詳述したものである。施設が店舗の場合［１０：店舗］、論理は以下の「システムタイプの論理」と題した項目に記述されている手順に従って進む。施設が飲食店（またはその他着席する施設）の場合［１０：飲食店］は、次の論理は施設が使用しているシステムのタイプによって異なる［２０］。システムが現金及び現金不要支払いを許容する場合［２０：現金＆現金不要支払い］、顧客は、団体の幹事名、若しくは団体固有の名前を入力する［４０］とともに、来店コードを入力しなければならない［３０］。システムが現金不要支払いを許容する場合［２０：現金不要支払いのみ］、顧客は団体の幹事名、若しくは団体固有の名前だけを入力すればよい［４０］。幹事以外の団体のその他のメンバーは、団体の来店コード、幹事名、団体固有の名前を使用してシステムにログインすることができる。いったん幹事がログインすると、幹事以外のメンバーは同じ名前と来店コードを使用してログインできないことに注意する。幹事以外の団体のメンバーは、図８．３．１で示すように、メニュー品目を注文に追加することはできるが、注文を出すことはできない。幹事は、団体のメンバーの注文を確認する必要がある［図８．３．１：１０４−１０６］。ただし、幹事がメンバーを信任された注文者として指定している場合は、そのメンバーは直接注文を出すことができる。
【０１８６】
システムは、顧客が幹事であるかどうか確認する［５０］。幹事であれば［５０：はい］、論理は以下の「システムタイプの論理」と題した項目に記述されている手順に従って進む。顧客が幹事でない場合［５０：いいえ］、システムは、施設が団体のメンバーに個別勘定を許容しているかどうかを確認する［６０］。団体のメンバーが個別勘定を許容されていない場合［６０：いいえ］は、以下の「続ける」と題した項目を参照する。団体のメンバーが個別勘定を許容されている場合［６０：はい］は、システムは顧客に自分の注文分の支払いをしたいかどうか尋ねる［７０］。団体のメンバーが自分の注文分の支払いをしたくない場合［７０：いいえ］、以下の「続ける」と題した項目を参照する。支払いをしたい場合［７０：はい］は、論理は以下の「システムタイプの論理」と題した項目へ進む。
【０１８７】
システムタイプの論理
現金不要支払いのみのシステムの場合［８０：現金不要支払いのみ］、システムは顧客の現金不要支払い媒体を確認し［１００］、論理は以下の「続ける」と題した項目に明記されるように続く。システムが現金と現金不要の両方の支払いを許容する場合［８０：現金＆現金不要支払い］で、顧客が現金不要支払い媒体で支払いをしたいと望むとき［９０：現金不要支払い］、システムは再び顧客の現金不要支払い媒体を確認し［１００］、論理は以下の「続ける」と題した項目に明記されるように続く。その他の場合、顧客が単純に現金で支払いをする場合［９０：現金払い］、論理は以下の「続ける」と題した項目に明記されるように続く。
【０１８８】
現金不要支払い媒体の登録が必要にもかかわらずされていない場合、または確認に問題がある場合には、顧客は再試行または別の媒体を登録するよう誘導されることに注意する。これは、図における、システムが「現金不要支払い媒体を確認する」全てのケースに該当する。
【０１８９】
継続
過程論理はこの過程論理の図に参照を付けた図に戻る。
【０１９０】
図８．１．１．１は、現金払いと現金不要支払い媒体を許容している飲食店の支払い決済の論理を詳述したものである。この過程は、顧客が注文システムからログアウトしていることを前提にする。顧客が以前に現金不要支払い媒体を利用して支払いを行うと指定した場合［１０：現金不要支払い］、その媒体は、顧客が支払うべき金額を請求される［２０］。結局、次の論理は、顧客が以前に現金で支払いを行うと指定した場合［１０：現金払い］と同じになる。顧客はチェックアウトカウンターや精算エリアへと進む［３０］。自動的に顧客から支払いを受領し、領収書を発行する支払い／受領機を施設が所有する場合［３５：はい］、論理は以下の「自動支払い受領」と題した項目へ続く。施設が支払い／受領機を利用しない場合［３５：いいえ］、論理は以下の「マニュアルの支払い受領」と題した項目で説明されるように進む。
【０１９１】
自動支払い受領
顧客が注文に携帯機を利用し、その携帯機が短距離通信機能（つまり赤外線、ブルートゥース）を持つ場合［１００：はい］、顧客は顧客ＩＤやその他の情報を支払い／受領機に無線で転送することができる［１１０］。しかし、顧客が短距離通信機能を持つ携帯機を利用しないまたは所有しない場合［１００：いいえ］、顧客は自分の来店スリップにあるバーコードを支払い／受領機へスキャンしなければならない［１２０］。どちらの場合も（１１０または１２０）、次の手順は顧客の支払い媒体によって異なる［１３０］。顧客が現金で支払う場合［１３０：現金払い］、支払い／受領機は支払い額を表示する［１４０］。次の論理は以下の「精算」と題した項目において詳述する。
【０１９２】
顧客の希望する支払い媒体が現金不要支払いである場合［１３０：現金不要支払い］、注文を終了した時点ですでに顧客の現金不要支払い媒体に請求が行われているはずである。であるから、支払い／受領機は、単に顧客の支払いが承認され、顧客が注文システムから問題なくログアウトしたかさえ確認すればよい［１５０］。顧客が領収書の発行を指定しない場合、防犯対策として、支払い／受領機は簡単なスリップを発行する。そこには顧客が全額支払い済みである旨が記載されており、顧客が従業員、警備係、その他の者に施設を退出するときに提示することができる。次の論理は、以下の「領収書の論理」と題した項目へ続く。
【０１９３】
マニュアルの支払い受領
顧客が注文に携帯機を利用し、その携帯機が短距離通信機能（つまり赤外線、ブルートゥース）を備えている場合［４０：はい］、顧客は顧客ＩＤやその他の情報をワイアレスで従業員の端末またはその他の機器に転送することができる［４５］。次の論理は以下の「マニュアルの支払い受領：顧客情報の表示」と題した項目へ続く。しかし、顧客が注文の際に短距離通信機能を持つ携帯機を利用しない場合［４０：いいえ］は、顧客はただ来店スリップを従業員に提示すればよい［５０］。従業員は来店スリップにあるバーコードをシステムにスキャンする［５５］。
【０１９４】
マニュアルの支払い受領：顧客情報の表示
システムは、顧客の注文情報を表示する［６０］。顧客が現金不要支払い媒体を利用して支払いを行った場合［７０：現金不要］、従業員は顧客がシステムから問題なくログアウトしたかどうか、そして顧客の支払いが承認されたかどうかだけを確認すればよい［８０］。論理は、以下の「領収書の論理」と題した項目に記述されるように続く。しかし、顧客が以前に現金で支払うと指定した場合［７０：現金］は、従業員は顧客に請求額の合計を伝える［９０］。
【０１９５】
請算の論理
顧客は、現金またはその他の支払い媒体を機械に挿入することにより請求書の支払いを行う［２００］。
【０１９６】
領収書の論理
システムは、以前に顧客が領収書を要求したかどうかを確認する［２１０］。もししていなければ［２１０：いいえ］、以下の「取引の完結」と題した項目を参照する。領収書が以前に指定された場合、［２１０：はい］、システムはシステム自身にどのタイプの領収書が要求されたか判断を求める［２２０］。顧客が電子メールのみの領収書を指定した場合［２２０：電子メール］、システムは顧客に電子メールを送信するかまたは電子メールで領収書を転送する［２６０］。次の論理は、以下の「取引の完結」と題した項目で説明される。顧客が電子メールと印刷された領収書の両方を指定した場合［２２０：電子メール＆印刷］、システムは顧客に電子メールを送信するかまたは電子メールで領収書を転送する［２３０］。次の論理は、顧客が印刷された領収書を指定した場合［２２０：印刷］と同じになり、以下の「領収書の印刷」と題した項目で詳述する。
【０１９７】
領収書の印刷
システムが顧客用の領収書を印刷した後［２４０］、顧客は領収書を受け取る［２５０］。
【０１９８】
取引の完結
顧客とその団体の来店取引は、顧客が支払い／受領機を利用した場合、または支払い／受領機が利用されない場合で従業員によりマニュアルで支払いが行われた場合、システムにより自動的に完結される［２７０］。個別勘定と領収書が指定された場合、その団体の支払いをするメンバー全員が支払いを行うまで、来店取引は正式に完結しない。
【０１９９】
図８．１．２．１は現金不要支払い媒体のみを許容している飲食店の支払い決済の論理を詳述したものである。顧客とその団体がシステムからログアウトした時点で、請求額は顧客の現金不要支払い媒体に請求される［１０］。団体の何人かが個別勘定を登録している状況では、各支払いメンバーの現金不要支払い媒体にも請求が行われていることに注意する。通常現金不要支払いの決済取引毎にわずかな手数料が発生するため、顧客の支払い媒体には注文ごとには請求されず（図８．３．１）、むしろ顧客とその団体が全注文の終了を示した後で請求される。ログアウトまで顧客の支払い媒体への請求を保留するもう一つの理由は、媒体によっては（例：クレジットカード、デビットカードなど）、全額または実際の請求がされるまでの仮請求を認めているためである。しかし、媒体の情報を保管し後から請求をする過程が可能でない、または仮請求がビジネスとして理にかなわない現金不要支払い媒体では、支払い媒体は各注文が承認される前に請求が行われることもある。これには、一部のプリペイドカードが該当する。
【０２００】
取引に問題がある場合［２０：はい］、従業員は通知を受ける［３０］。問題がない場合［２０：いいえ］、システムは顧客が以前に領収書を要求したかどうか問われる［４０］。印刷された領収書が指定されない場合［４０：いいえ］、論理は以下の「取引の完結」と題した項目へ続く。印刷された領収書が指定された場合［４０：はい］、システムはシステム自身にどのタイプの領収書が要求されたか判断を求める［５０］。
【０２０１】
顧客が電子メールのみの領収書を指定した場合［５０：電子メール］、システムは顧客に電子メールを送信するかまたは電子メールで領収書を転送し［６０］、次の論理は以下の「取引の完結」と題した項目で説明される。顧客が電子メールと印刷された領収書の両方を指定した場合［５０：電子メール＆印刷］、システムは顧客に電子メールを送信するかまたは電子メールで領収書を転送する［７０］。次の論理は、顧客が印刷された領収書を指定した場合［５０：印刷］と同じになり、以下の「顧客への通知」と題した項目において詳述する。
【０２０２】
顧客への通知
システムは、顧客にチェックアウト／領収書カウンターまで進み、印刷された領収書を入手するよう通知する［８０］。顧客はチェックアウト／領収書カウンターまで行く［９０］。顧客が短距離通信機能を持つ携帯機を利用した場合［９５：はい］、顧客は単に顧客ＩＤとその他の情報を領収書機器に転送するだけでよい［９７］。次の論理は、以下の「領収書の印刷」と題した項目に続く。顧客が短距離通信機能を持つ携帯機を利用しなかった場合［９５：いいえ］、顧客は現金不要支払い媒体タイプを選択し［１００］、支払い媒体またはその情報を領収書機器または端末に通す／入力する／転送する［１１０］。
【０２０３】
領収書の印刷
システムが顧客用の領収書を印刷した後［１２０］、顧客は領収書を受け取る［１３０］。
【０２０４】
取引の完結
システムは顧客とその団体の来店取引を完結する［１４０］。その団体内の支払いをするメンバー全員が支払いを完了し領収書を受け取るまで、来店取引は正式に完結しない。
【０２０５】
図８．１．３．１は飲食店の自動着席案内の論理を詳述したものである。この過程は、図８．１．３．２（手順１０：テーブルの利用可能性確認前）に記述されるように、事前にテーブルの利用可能性を確認することから始まる［１０］。入力された情報をもとにして、システムはテーブルが利用可能かどうか判断する［２０］。続いてシステムはテーブルが利用可能かどうか、自動着席案内システムが保留されていないかどうかの確認を行う［３０］。従業員は、様々な理由から必要と判断すれば、着席案内をマニュアルで行う。その場合はシステムにより自動的に顧客が着席案内されるのを一時的に望まないため、自動着席案内システムを保留にすることができる。
【０２０６】
利用可能なテーブルがあり、自動着席案内システムが保留になっていない場合［３０：はい］、システムは、利用可能なテーブルに顧客の団体の総人数が着席できるかどうか確認する［４０］。団体の規模が利用可能なテーブルの最大着席人数を超えない場合［４０：いいえ］、つまりその団体が着席できるテーブルが利用可能な場合には、論理は以下の「すぐに利用可能なテーブル」と題した項目に記述されるように続く。
【０２０７】
どの利用可能なテーブルにもその団体が着席できない場合［４０：はい］、システムは２つの隣接したテーブルが利用可能かどうか確認する［１００］。もしあれば［１００：はい］、次の論理は以下の「すぐに利用可能なテーブル」と題した項目で説明される。一方、もし２つの隣接するテーブルが利用可能でない場合［１００：いいえ］、その旨を示すメッセージが団体の幹事に表示される［１１０］。団体の幹事は、幹事とその団体は１）どんなテーブルの組み合わせでもその団体が着席できるか確認したい、２）隣接したテーブルが空くのを待ちたい、または３）待ちたくない（施設を去る）のいずれかを示唆しなければならない［１２０］。
【０２０８】
団体が待ちたくない場合［１２０：待たない］、施設を退出してもよい［１３０］。団体が隣接したテーブルが空くのを待ちたい場合［１２０：隣接したテーブルを待つ］、図８．１．３．２（手順３００：テーブルの利用可能性確認後）に示すように、団体の幹事は幹事の情報をログイン端末／機器に入力する［１４０］。するとシステムはその団体を（隣接するテーブルの）待機リストに追加する［１５０］。その団体は隣接するテーブルが利用可能になるまで待たなくてはならない［２００］。テーブルが利用可能となったときに起こる論理は、以下の「利用可能になったテーブル」と題した項目に記述される。もし、その団体の幹事がどんなテーブルの組み合わせも受容すると決定した場合［１２０：全てのテーブル］、システムはその団体に必要な数のテーブルが利用可能かどうか確認する［１６０］。もしあれば［１６０：はい］、次の論理は以下の「すぐに利用可能なテーブル」と題した項目で説明される。もし必要な数のテーブルが利用可能でない場合［１６０：いいえ］、団体の幹事は、幹事とその団体が待つか待たないかを決定する［１７０］。もしその団体が待ちたくない場合［１７０：いいえ］、施設を退出することは自由である［１３０］。もしその団体が待つことを決めた場合［１７０：はい］、図８．１．３．２（手順３００：テーブルの利用可能性確認後）に示すように、団体の幹事は幹事の情報を入力しなければならない［１８０］。システムはその団体を（すべての利用可能なテーブルの）待機リストに追加する［１９０］。その後その団体はただ待っているだけでよい［２００］。テーブルが利用可能になったときに起こる論理は以下の「利用可能になったテーブル」と題した項目に記述される。
【０２０９】
しばしば、どうしてもテーブルが利用できないことが起こる。（つまり、団体の規模に対してテーブルの席数の確認ができない）［３０：いいえ］このような場合には、団体はテーブルが利用可能になるのを待つかどうか決定できる［３００］。待ちたくない場合［３００：いいえ］、施設を退出しても良い［３１０］。しかし、待ちたい場合［３００：はい］、図８．１．３．２（手順３００：テーブルの利用可能性確認後）に特定されるように、団体幹事は自分の情報を入力しなければならない［３２０］。いったん入力が完了すると、その団体は待機リストに追加される［３３０］。
【０２１０】
待合場所にゲスト用端末がある場合［３４０：はい］、団体は、図８．１．３．５（手順１０：端末）に示された論理に従ってメニューを閲覧したり、事前に注文をしたりすることができる［３５０］。ゲスト用端末がない場合でも［３４０：いいえ］、団体のメンバーはメニューを閲覧することができる［３８０］。もし、団体のメンバーが携帯機を持たない場合や、持っていても自分の携帯機を使ってメニューの閲覧／事前注文をしない場合は［３８０：いいえ］、テーブルが利用可能になるまで待たなければならない［４００］。テーブルが利用可能になったときに起こる論理は、以下の「利用可能になったテーブル」と題する項目に記述される。団体メンバーの誰かが自分の携帯機を使ってメニューの閲覧や事前注文をしたい場合［３８０：はい］、図８．１．３．５（手順１０：携帯）に明記されているようにして、それをすることができる［３９０］。
【０２１１】
ゲスト用端末または携帯機がメニューの閲覧や事前注文に使用されるかどうかにかかわらず、テーブルが利用可能になったときの過程を表す論理は、以下の「利用可能になったテーブル」と題する項目に記述される。
【０２１２】
利用可能になったテーブル
施設が現金及び現金不要の支払いが可能なシステムを利用している場合［５００：現金＆現金不要支払い］、システムは特別な「利用可能なテーブル」の画面に、団体の幹事名、団体の人数、団体の着席の確認手段を表示する［５１０］。次の論理は、以下の「利用可能になったテーブル：来店スリップの確認」と題する項目に記述される。一方、施設が現金不要支払いのみのシステムを利用している場合［５００：現金不要支払いのみ］、「利用可能なテーブル」画面は、団体の幹事名、団体の人数、テーブル番号を表示する［５２０］。次の論理は、このまま続く（以下）。
【０２１３】
利用可能になったテーブル：来店スリップの確認
団体の幹事が来店スリップを持っている場合［５３０：はい］、幹事は自動着席案内または同様のサービスへと進み、自分の団体の来店スリップにあるバーコードをスキャンする［５４０］。システムは、来店スリップまたは別の用紙にその団体のテーブル番号を任意で印刷し［５５０］、論理は以下の「来店コードを有効にする」と題する項目に続く。団体の幹事が来店スリップを持っていない場合［５３０：いいえ］、顧客／団体の幹事が短距離通信機能をもつ携帯機（つまり赤外線、ブルートゥース）を使用しているかどうかで論理が異なる［５６０］。幹事がそのような機能を持つ携帯機を使用していない場合［５６０：いいえ］、次の論理は以下の「来店コードを有効にする」と題する項目で説明される。団体の幹事がそのような機能を持った携帯機を利用している場合［５６０：はい］、幹事は顧客ＩＤとその他の情報を自動着席案内または同様の機器／端末に送信しなければならない［５７０］。するとシステムは、利用可能なテーブルの番号を顧客の携帯機にワイアレスで転送する［５８０］。次の論理は、以下の「来店コードを有効にする」と題する項目に記述される。
【０２１４】
すぐ利用可能なテーブル
図８．１．３．２（手順３００：テーブルの利用可能性確認後）に記述されているように、団体の幹事は幹事情報の入力へと進み［５０］、論理は以下に記述されるように続く。
【０２１５】
来店コードを有効にする
システムは、団体の来店コードまたは顧客のアカウントを有効にし［５９０］、論理の流れは、この図の論理に参照を付けた図へと戻る。
【０２１６】
図８．１．３．２は、顧客情報の入力の過程論理を詳述したものであり、飲食店の自動着席案内の過程論理における図８．１．３．１によって主に使用される。過程が開始する時点は、自動着席案内過程論理の図［図８．１．３．１］から参照するタイミングによる［１０］。テーブルの利用可能性確認前に顧客情報の入力の要求が起こると［１０：テーブルの利用可能性確認前］、次の論理は以下の「テーブルの利用可能性確認前」と題した項目に記述される。しかし、テーブルが利用可能かどうかの確認の後に顧客情報の入力の要求が行われると［１０：テーブルの利用可能性確認後］、論理は以下の「テーブルの利用可能性確認後」と題した項目で説明される。
【０２１７】
テーブルの利用可能性確認前
顧客が短距離通信機能を備えた携帯機（つまり赤外線、ブルートゥース）も、注文システム専用のシステムカードも持たない場合［２０：いいえ］、顧客は専用の着席案内機器または端末を使用して、使用言語を選択しなければならない［３０］。次に、顧客は団体の人数と喫煙の有無を入力する［４０］。次の論理は、以下の「テーブルの利用可能性確認前：情報をサーバに転送する」と題する項目で説明される。
【０２１８】
顧客が短距離通信機能を備えた携帯機（つまり赤外線、ブルートゥース）またはシステムカードを持っている場合［２０：はい］、次の論理は顧客が携帯機またはシステムカードを使用しているかによって異なる［５０］。顧客がシステムカードを使用している場合［５０：カード］、顧客はシステムカードを着席案内機器または端末へ入力する（通す）［６０］。次の論理は、以下の「顧客ＩＤをサーバに送信する」と題した項目に記述される。
【０２１９】
一方、顧客が短距離通信機能を備えた携帯機を使用している場合［５０：携帯］、次の論理は携帯機がワイアレスの自動通知機能を備えておりそれが有効になっているかどうかで異なる［７０］。ワイアレス機器が、携帯機が同一または同様の技術を備えた隣接機器とワイアレス通信を自動交渉できる短距離通信機能の技術（つまりブルートゥース）を備えていれば、この自動通知機能を持つ。その場合、顧客が顧客の機器のこの機能を有効にしていれば、隣接機器が顧客の携帯機とワイアレス通信を開始することが可能である。顧客がこのようなタイプの携帯機を持たないか、または自動通知機能が有効になっていないとき［７０：いいえ］、図７．３．１に示されるように、顧客は注文システムにログインしなければならない［８０］。顧客は、マニュアルで（つまり、携帯機のボタンを押すことによって）顧客ＩＤを着席案内機器または端末に送信する［９０］。次の論理は以下の「顧客ＩＤをサーバに送信する」と題した項目に記述される。
【０２２０】
しかしながら、顧客が、ワイアレスで自動交渉通信機能を持つ携帯機を所有しており、自動通知機能が有効になっている場合［７０：はい］、システムまたは自動着席案内機器または端末は、顧客が施設に入場するやいなや、ワイアレスで携帯機との接続を自動交渉する［１００］。顧客がポケットやバッグから携帯機を取り出すことすらしなくても、システムは自動的に顧客をシステムにログインさせることができる［１１０］。これは、マニュアルでログインしたり、顧客が施設に到着したことを示すためにボタン操作したりする必要がないといった点で、顧客にとっての利点である。施設にとっての利益は、顧客ＩＤが自動的にサーバに転送されるため、誰（つまり優良客や大切な顧客）が施設に入ったかを知ることができるので、経営者が顧客にあいさつして、顧客の来店体験をより印象深いものにすることが可能である。
【０２２１】
顧客ＩＤをサーバに送信する
システムは顧客ＩＤを着席案内機器や端末からサーバに送信し［１２０］、その時点で顧客情報と嗜好が検索される［１３０］。従業員の端末にこの特別顧客の到着を任意で送信し、画面に顧客情報を表示することができる（この機能は「顧客到着の自動通知」として知られる）［１４０］一方、顧客は団体の喫煙の有無を確認し、団体の人数を入力する［１５０］。
【０２２２】
テーブルの利用可能性確認前：情報をサーバに転送する
顧客情報と嗜好はサーバに転送され［１６０］、論理はこの図の論理に参照を付けた図に戻る。
【０２２３】
テーブルの利用可能性確認後
顧客が、（テーブルの利用可能性確認前において）携帯機またはシステムカードを以前に使用したことがある場合［３００：はい］、次の論理は次の「テーブルの利用可能性確認後：利用履歴のある携帯機またはシステムカード」と題する項目に記述される。顧客が、携帯機またはシステムカードを以前に使用しなかった場合［３００：いいえ］、自動着席案内機器または端末は、支払い媒体の明細を含めた顧客情報を入力するよう要求する［３１０］。
【０２２４】
システムが現金と現金不要支払いの両方の支払いを取り扱う場合［３２０：現金＆現金不要支払い］、顧客は希望の支払い媒体を選択する［３３０］。支払い媒体が現金と指定された場合［３４０：現金］、論理は以下の「テーブルの利用可能性確認後：名前の入力」と題した項目へと進む。希望の支払い媒体が現金不要支払いの場合［３４０：現金不要支払い］、次の論理は以下の「テーブルの利用可能性確認後：現金不要支払い媒体の選択」と題した項目に記述される。システムが現金不要支払いのみ処理する場合は［３２０：現金不要支払いのみ］、論理は以下のように進む。
【０２２５】
テーブルの利用可能性確認後：現金不要支払い媒体の選択
顧客は現金不要支払い媒体タイプ（つまり、クレジットカード、デビットカード、プリペイドカード、スマートカード）を自動着席案内機器／端末上で選択し［３５０］、媒体情報を自動着席案内機器／端末へ入力または転送する［３６０］。自動着席案内機器／端末が、顧客名を現金不要支払い媒体から識別することが可能であれば［３７０：はい］、論理は、以下の「テーブルの利用可能性確認後：システムタイプ」と題した項目に記述されるように続く。しかし、顧客名が媒体から確定できない場合［３７０：いいえ］、論理は以下のように進む。
【０２２６】
テーブルの利用可能性確認後：名前の入力
顧客はマニュアルで名前を入力する［３８０］。この名前はどんな恣意的な名前も可能で、必ずしもフルネームである必要もないことに注意する。次の論理は、採用されているシステムのタイプによって異なり［６００］、以下の「テーブルの利用可能性確認後：システムタイプ」と題した項目に記述される。
【０２２７】
テーブルの利用可能性確認後：利用履歴のある携帯機またはシステムカード
顧客が以前にシステムカードを利用して嗜好を転送／入力したことがある場合［５００：カード］、次の論理は以下の「テーブルの利用可能性確認後：システムタイプ」と題した項目に記述される。また、顧客が短距離通信機能（つまり、赤外線、ブルートゥース）を備えた携帯機を使用した場合［５００：携帯］、サーバは顧客のバーコードと来店コードを顧客の携帯機に転送、保存、そして表示する［５１０］。システムが顧客のためにテーブルがすぐに利用可能であると判断した場合［５２０：はい］、サーバは更に顧客のテーブル番号を顧客の携帯機に転送、保存、そして表示する［５３０］。
【０２２８】
テーブルが利用可能である（上記のように）かないかにかかわらず［５２０：いいえ］、施設の選択またはシステムによって、サーバは再確認のために顧客用スリップを印刷する必要があるかどうかも確認する［５４０］。その理由は、２組の顧客または団体が同じテーブルをめぐって矛盾を起こすとき（つまり、起こる可能性は非常に低いが顧客が正当に見える情報を作成するために偽の画像を携帯機に作成した場合）、スリップがどちらの顧客または団体が有効な情報を持っているかを最終的に決定する。そのようなシナリオはほとんど起こる可能性はないが、スリップの確認のための追加論理がセーフガードとして提供されている。印刷されたスリップによる確認が必要であれば［５４０：はい］、次の論理は以下の「テーブルの利用可能性確認後：システムタイプ」と題した項目に記述される。必要でない場合［５４０：いいえ］、論理の流れはこの図に記述された論理に参照を付けた図へ戻る。
【０２２９】
テーブルの利用可能性確認後：システムタイプ
システムが現金及び現金不要支払い媒体を許容する場合［６００：現金＆現金不要支払い］、システムは来店コード及びバーコードの記載されたスリップを顧客及びその団体のために作成し印刷する［６１０］。次の論理は以下の「テーブルの利用可能性確認後：テーブルの利用可能性」と題した項目に記述される。システムが現金不要支払い媒体のみを許容する場合［６００：現金不要支払いのみ］、システムが現金不要支払いのみの環境でスリップを印刷するよう設定されているかどうか確認が行われる［６２０］。もし設定されていない場合［６２０：いいえ］、テーブルが利用可能であれば［６２４：はい］、顧客のテーブル番号が自動着席案内機器または端末に表示される［６２６］。（顧客が自分の携帯機ではなく自動着席案内機器または端末を使用している場合）しかし、もしテーブルが利用可能でない場合［６２４：いいえ］、論理の流れはこの論理図に参照を付けた論理図へ戻る。システムが現金不要支払いのみの設定においてスリップを印刷するよう設定されている場合［６２０：はい］、システムはバーコード及び顧客名が記載された顧客用来店スリップを作成し印刷する［６３０］。
【０２３０】
テーブルの利用可能性確認後：テーブルの利用可能性
テーブルが顧客のために利用可能であるとき［６４０：はい］、自動着席案内機器は顧客の来店スリップにテーブル番号も印刷する［６５０］。テーブルが利用可能であるかどうかにかかわらず［６４０：いいえ］、顧客は作成されたスリップを受け取り［６６０］、過程はこの論理図に参照を付けた論理図へ戻る。
【０２３１】
図８．１．３．４は飲食店のログアウトの論理を詳述したものである。顧客が自分の端末または携帯機上でログアウトボタンを選択するとき、システムは顧客に対し、施設に食事の質やサービスなどについてフィードバックを残したいかどうか尋ねる［１０］。顧客にこの情報を尋ねるかどうかは任意であり、この質問を顧客にするかどうかは施設の選択次第である。
【０２３２】
顧客がフィードバックを残すことを希望する場合［１０：はい］、顧客は食事の質やサービスなどについてのコメントの入力へと進む［２０］。そしてシステムは顧客の入力内容を表示し、顧客に入力内容の確認を求める［３０］。顧客が確認に同意する場合［４０：いいえ］、システムは顧客のフィードバックを保存し［４３］、論理は以下の「チップの論理」と題した項目へ続く。同意しない場合［４０：はい］、顧客は手順２０−３０を繰り返すことによって入力内容を修正できる。
【０２３３】
顧客がフィードバックを残すことを希望しない場合［１０：いいえ］、論理は次のように続く。
【０２３４】
チップの論理
次に、システムは顧客にチップ［５０］を払いたいかどうかを尋ねる。チップをサービス料として自動的に加算する飲食店もあるので、この情報を顧客に尋ねるかどうかは全くの任意である。また、国によってはチップの習慣がない。そのため、この質問を顧客にするかどうかは施設の選択次第であり、文化による場合もある。団体の幹事以外のメンバーも支払いをする場合、この質問は団体の幹事のみに向けられる。
【０２３５】
施設がこの質問を顧客にして、顧客がチップを払いたいと希望する場合［５０：はい］、システムは、（顧客が決定をしやすくするため）注文の総額／請求書の金額を表示する［５５］。顧客がチップの金額または料率を入力した後［６０］、システムは顧客の入力内容を表示し顧客に確認を求める［７０］。修正の必要がない場合［８０：いいえ］、システムはチップに関する情報を保存し［８３］、論理は以下の「領収書の論理」と題する項目へ続く。修正の必要がある場合［８０：はい］、顧客は手順５５−８０を繰り返すことによって入力内容を修正できる。
【０２３６】
領収書の論理
次に、図８．３．２に記述される領収書の仕様の論理に従って、顧客は領収書の有無を指定する［９０］。顧客が領収書の有無を指定した後、システムは、図８．３．４に定められているように、報奨ポイント更新論理を実行し［９５］、正式に顧客を施設のシステムからログアウトさせる［１００］。
【０２３７】
図８．１．３．５は、飲食店での閲覧／事前注文過程論理を詳述したものである。施設が来客用端末を所有し、顧客がそれを閲覧／事前注文に利用したいと希望した場合［１０：端末］、顧客は来客用端末へ進む［８０］。そこでシステムと施設が、施設が位置する国の主要言語以外の言語を画面に表示するよう設定されている場合、顧客は端末に使用言語を入力する［８５］。次に、顧客は以下の「閲覧／事前注文」と題する項目で説明されるように、商品を閲覧／事前注文することができる。顧客が自分の携帯機を閲覧／事前注文に使用することを希望する場合［１０：携帯］、図７．３．１のシステムログイン−登録の論理に記述されるように、顧客が以前ログイン（つまり、自動着席案内システムを利用）したことがない場合のみ、顧客は注文システムにログインしなければならない［１５］。顧客は自分の携帯機上で閲覧／事前注文の選択をする［２０］。
【０２３８】
「ｅ−メニュー」リストが利用可能でないとき［２５：いいえ］、顧客が商品を事前注文するためには、図７．３．２に詳細が示されているように、施設のログイン手続きを完了しなくてはならない［３０］。（顧客がすでに完了していない場合）「ｅ−メニュー」は「電子メニュー」の省略であり、顧客の携帯機に表示される実際のメニュー品目のリストを指す。メニューリストには、品目名、内容、単価、任意の画像、その他詳細が含まれるが、この限りではない。先の図の記述でも述べたように、既存の印刷されたメニューを使用し、従来の注文システムを提供することを好む施設もあるので、その場合は、顧客はメニュー品目のコードを自分の携帯機に入力するだけでよい。そのようなシステムには「ｅ−メニュー」はない。全てのメニュー品目の詳細は顧客の携帯機ではなく印刷されたメニューに表示されるからである。
【０２３９】
顧客が事前注文を希望する品目のコードを入力した後［３５］、システムは顧客が事前注文した品目を保存する［４０］。顧客が事前注文を終了したら［５０：終了］、次の論理は以下の「完了」と題する項目で記述される。テーブルが利用可能な場合［５０：テーブルの利用可能性］、次の論理は以下の「利用可能なテーブル」と題する項目で記述される。しかし、顧客が事前注文を終了していない場合やテーブルがまだ利用可能でない場合［５０：いいえ］、顧客は手順３５−５０を繰り返すことにより事前注文を続けることができる。ｅ−メニューリストが利用可能で［２５：はい］、それにより顧客が自分の機器上で実際のメニュー品目を見ることができる場合、次の論理はｅ−メニューが公開されているものかどうかによって異なる［６０］。施設によっては、（おそらく競争上の理由で）メニューを顧客以外には見られたくないかもしれない。その場合、施設は、顧客が閲覧／事前注文するために施設のログイン手続を完了するよう要求することができる。（すなわち閲覧／事前注文するためには顧客がその場にいることを要求する。）
ｅ−メニューが一般にアクセス可能でない場合［６０：いいえ］、図７．３．２に詳細が示されるように、顧客が施設のログイン手続を完了していない場合はする必要がある［７０］。ｅ−メニューが一般にアクセス可能である場合［６０：はい］、以下の「閲覧／事前注文」と題した項目で記述されるように、顧客は閲覧／事前注文することができる。
【０２４０】
閲覧／事前注文
顧客は、来客用端末を使用しても自分の携帯機を使用しても、利用可能なメニュー品目の閲覧へと進む［９０］。品目を閲覧しながら、顧客は特定の品目を事前注文することを決定することができる［９０：事前注文］。その場合、システムは顧客が先に施設のログイン手続を完了したかどうかを確認する［１１０］。顧客が施設のログイン手続を先に完了した場合［１１０：はい］、次の論理は以下の「ｅ−メニュー−事前注文した品目を保存する」と題した項目で説明される。完了していない場合［１１０：いいえ］、機器のタイプによって施設のログインが必要となる［１２０］。
【０２４１】
顧客が携帯機を閲覧／事前注文に使用しているとき［１２０：携帯］、図７．３．２に説明されるように、顧客が施設のログイン手続を完了していない場合はする必要がある［１３０］。次の論理は、以下の「ｅメニュー−事前注文した品目を保存する」と題した項目で説明される。しかし、顧客が施設の来客用端末を使用している場合［１２０：端末］、ログイン手続はシステムのタイプによって異なる［１４０］。
【０２４２】
施設のシステムが現金と現金不要支払いの両方の支払い媒体を許容する場合［１４０：現金＆現金不要支払い］、顧客は団体の来店コード、団体の幹事名、顧客が団体の幹事でない場合にはその画面上の名前を入力する［１５０］。次の論理は以下の「ｅ−メニュー−事前注文した品目を保存する」と題した項目で説明される。施設のシステムが現金不要支払い媒体のみを許容する場合［１４０：現金不要支払い］、顧客は現金不要支払い媒体タイプを選択し［１６０］、現金不要支払い媒体（またはその情報）を端末に入力または転送しなければならない［１７０］。そしてシステムは、図６．１．１．１の過程論理で詳述されるように、指定された現金不要支払い媒体と顧客が入場したときに示した支払い媒体が同一であることを確認する［１８０］。次の論理は、以下の「ｅ−メニュー−事前注文した品を保存する」と題する項目で説明される。
【０２４３】
ｅ−メニュー−事前注文した品目を保存する
システムは、顧客が事前注文したメニュー品目を保存する［１９０］。顧客が事前注文を終了したら［２００：終了］、次の論理は以下の「完了」と題する項目に記述される。テーブルが利用可能な場合［２００：テーブルの利用可能性］、次の論理は、以下の「利用可能なテーブル」と題する項目に記述される。しかし、顧客が事前注文を終了していない場合やテーブルがまだ利用可能ではない場合［２００：いいえ］、「閲覧／事前注文」と題する前項の手順を繰り返すことによって、顧客は事前注文を続けることができる。
【０２４４】
利用可能なテーブル
顧客がまだ閲覧／事前注文をしている間にテーブルが利用可能になった場合、システムは来客用端末または顧客の携帯機にテーブルが利用可能である旨メッセージを表示する［２１０］。施設が自動着席案内システムを利用していない場合［２２０：いいえ］、次の論理は、以下の「終了」と題する項目に記述される。しかし、もし施設が自動着席案内システムを利用している場合［２２０：はい］は、来客用端末または顧客の携帯機に次に表示されるメッセージはシステムタイプによって異なる［２３０］。
【０２４５】
施設のシステムが現金と現金不要支払い媒体の両方を許容する場合［２３０：現金＆現金不要支払い］、システムは、顧客に顧客の来店スリップにあるバーコードをバーコードリーダーにスキャンするようメッセージを表示する［２４０］。施設が現金不要支払い媒体のみを許容する場合［２３０：現金不要支払い］、システムは顧客とその団体が利用可能なテーブルの番号を表示する［２５０］。どちらのシステムタイプも、次の論理は、以下の「終了」と題する項目に記述される。
【０２４６】
終了
顧客の次のアクションは、顧客が使用している機器のタイプによって異なる［２６０］。もし顧客が自分の携帯機を使用している場合［２６０：携帯］、顧客は閲覧／事前注文を終了する選択を行う［２８０］。顧客が施設の来客用端末を使用している場合［２６０：端末］、顧客はログアウトの選択をする必要がある［２７０］。
【０２４７】
使用されている機器にかかわらず、テーブルが利用可能の場合［２９０：はい］、論理の流れはこの図に参照を付けた図へ戻る。しかし、テーブルが利用可能でない場合［２９０：いいえ］、顧客とその団体はテーブルが利用可能になるまでただ待たなければならない［３００］。テーブルが利用可能であるとき、次の論理はこの図に参照を付けた図の論理となる。
【０２４８】
図８．３．１は注文処理の核となる論理を示すもので、施設（レストラン、店舗）、機器のタイプ（端末、携帯機）及び支払い媒体（現金払い及び現金不要支払い、現金のみ）等に共通して使用される。この論理では、まず顧客が正式な注文に先立って、何か注文したかどうかを注文リスト、または注文「バスケット」をチェックすることから始められる［１０］。というのは、顧客が正式に着席するまでに、ゲスト用端末または携帯機から注文する可能性があるからである。
【０２４９】
顧客が事前注文した場合、注文リストに［１０：はい］記憶されていた品名がシステムから搭載される［２０］。しかし、品目が注文されていない場合、注文リストは［２０：いいえ］となり、それ以降の発注の手順は顧客によって、次のように進められる。１）新しい注文オプションボタンを選択する［２５］。２）注文品目を選択［３０］。３）品目の数量、オプションとして誰の注文かを明示する、その品目の調理に関連するオプションなどを選択［４０］。４）品目を注文リストに付け加える［５０］。次いで、顧客に対し、更に注文リストに品目を付け加えるかどうかを尋ねる［６０］。もし、「はい」であれば３０−６０を繰り返す。顧客が新たな品目の追加を必要としない場合には［６０：いいえ］でシステムは発注したすべての品目のリストを表示し［７０］、注文の確認を顧客に求める［８０］。注文が不満足な場合には［８０：いいえ］となり、顧客は注文を訂正することができる［９０］。この場合にはステップ７０−９０がくりかえされる。顧客が注文を確認して納得した場合［８０：はい］となり、顧客は注文を提出する［１００］。
【０２５０】
次いでシステムは顧客が「信用できる発注者」であることをチェックする［１０４］。
【０２５１】
「信用できる発注者」というのは、団体客の場合、団体客の幹事（接客係りが、幹事または代表としてシステムに名前を登録した人）が発注するのであるが、幹事以外からも注文される場合がある。その顧客が自分で注文してよいという指示が特に幹事によってなされている場合がこれにあてはまる。このチェックは基本的には安全の為であって、現金払い、または現金不要支払いのレストランにおいて、最終的には全ての注文の責任は幹事が取らなくてはならない。また、あまり考えられないことではあるが、「ハッカー」が紛れ込んでいて団体客の来店コードを察知し、団体客の注文にランダムに上乗せするような事態もあり得る。ともあれ、幹事以外からの注文は全て幹事によって確認される必要があるが、前以て幹事に確認する必要がないとされた顧客からの注文は毎回確認する必要はない。
【０２５２】
もしも発注者が信用出来る発注者でなければ［１０４、いいえ］、団体客の幹事は注文を承認あるいは承認せず、または注文のなかの品目を選択する［１０６］。それ以外の場合には、注文は「信用できる」ものとする［１０４：はい］。続いて、全ての注文（確認または承認されたもの）は施設のサーバに送信される［１１０］。端末の場合には注文は直接社内サーバに送信される。しかし、携帯機の場合には顧客の注文はインターネットによってシステムサポートセンターのウエブサイトに送られ、続いて電子的及び自動的に社内サーバに送られ処理される。携帯機によって、施設の社内サーバに直接送信する事は可能であるが、セキュリティーの理由から携帯機による注文の送信はインターネットを使用し、サポートセンターを経由して行われる。
【０２５３】
続いて、注文は「分割」され、夫々の品目はマスターアイテムプロセスリストに追加される［１２０］。品目の調理が必要かどうかで処理の経路が変わってくる［１３０］。まず調理を必要とする品目の経路は［１３０：はい］、調理を必要としない品目の経路は［１３０：いいえ］であるが、品目が調理されると調理を必要としない経路を通る。
【０２５４】
調理の必要な品目は［１３０：はい］、シェフのプロセスリストに追加される［１４０］。施設の選択に応じて、似たような品目でまだ調理されていないものを同じグループに入れるか、または同じグループに入れないなどの処理を行う［１５０］。シェフのプロセスリストの中で、幾つかの品目が同じ方法で調理される場合、または似たような方法で調理される場合、グループ化することによって調理時間の効率が良くなる。同じ品目をグループ化によって集め、バッチ化して調理することができる。これにより、シェフの準備、調理及び片付け等に掛かる時間は、個々の品目を注文の入った順番に準備、調理していくのに比べて少なくて済む。
【０２５５】
施設の選択として、グループ化機能を利用する場合は［１５０：はい］、続いて、同じ品目をグループ化して準備及び調理を同時に行う［１６０］。いったん品目がグループ化されると、施設内でグループ化機能を採用していない場合には［１５０：いいえ］。施設によってシェフの動きが明示されていれば、どのシェフの手があいている、または忙しくない［１８０］等によって、どのシェフがその品目の調理をするかシステムが決定する［１７０］。このことは、施設にとって、注文のあった品目の調理の手順とか、誰が特定の品目の調理に最適か、誰が最初に調理を始めるのかなどを決め、更に時間の短縮を計る事ができる。ある特定のシェフにある特定の品目の調理が可能であるとシステムが判定した場合、その品目は特定のシェフのプロセスリスト（シェフに割り当て）に追加される［１９０］。次いで、その品目は処理のため、シェフの端末に送信される［２００］。幾人かのシェフが同じ端末を共用している場合、その品目名の隣にそれを取り扱うシェフの名前が記載されるか、あるいは特定のシェフ専用の品目リストが提示される。シェフは口頭または手動でタッチ式画面を押し、リストから品目を選び、調理を始める。これにより、特定品目が準備中であることを表示する［２１０］。この時点で特定品目は調理進行中とマークされ［２３０］、シェフは特定品目の調理を開始する［２６０］。特定品目の状態が処理中にアップデイトされた場合には、顧客に対して随時、特定品目が調理中であることを通知する［２５０］。同時に、特定品目のコストを顧客の請求書に加算する［２４０］。特定品目の調理が終わると、シェフは口頭または手動でタッチ式画面を押し［２７０］、用意が終わったことを知らせる。特定品目は用意完了済みとサーバでアップデイトされ［２８０］、最優先取り扱いを指定される［２９０］。
【０２５６】
この時点で、調理された品目は、スタッフのプロセスリストに追加される［３００］。品目について注意すべき重要な点は、調理の必要が無い［１３０：いいえ］品目も同様な経路でスタッフのプロセスリストに追加される［３００］。次いで、品目のインフォメーションがスタッフの端末に送られて来る［３１０］。最優先の品目（例えば、できたてで、暖かいうちにサーブする必要のあるもの）はプロセスリストのトップに移行する［３２０］。手の空いているスタッフは誰でもそれらの品目を選び、名前を明記し接客係として注文を取り扱う［３３０］。続いてその品目は特定のスタッフのプロセスリストに登録される［３８０］（または単に品目を扱った接客係に指定される。）。それと同時にシェフによって準備されない品目は［３４０：いいえ］、処理中としてサーバにマークされる［３５０］。これらの事が完了すると、顧客に品目の準備中という通知がオプションとして送られる［３７０］、そして、それと同時に品目のコストが顧客の請求書に追加される［３６０］。このような事が起っている間に、接客係りは用意された品目の取り扱いや準備を始める［３９０］（例えば、サラダの用意、調理された品目をキッチンから運ぶ等）。これらの準備が終わると、接客係は品目を顧客に運ぶ［４００］。
【０２５７】
品目の受け渡し時に顧客が現金で支払う場合には［４０３：はい］、顧客が支払って［４０５］、支払い時のやり取りをスムーズにするためと、つり銭の受け渡しを避けるため、顧客の出した紙幣をそのまま受け取っておいて、バランスはチェックアウトの際に清算する。このようにすれば顧客が支払わないで「食い逃げ」をするのを防ぐことができる。図には示していないが、顧客が「注文だけ出して逃げる」のを防げるようにシステムを設定することができる。この際には顧客の注文がキッチンで処理される前に、支払いをチェックする必要がある（ステップ１１０）。品目の受け渡し時に顧客は支払う必要がなく、支払いが現金でない場合［４０３：いいえ］、その過程は次のようになる。
【０２５８】
接客係りは端末または機器に表示されているプロセスリストに、注文された品目のサービスが完了した事をアップデイトする［４１０］。これにより、顧客の注文した品目の状態及び請求書のインフォメーションがアップデイトされ［４２０］、そしてこの品目の取り扱いが完了したというインフォメーションが施設のログファイルに記録される［４３０］。
【０２５９】
施設としての選択にもよるが、ある条件下では顧客に対してダイアログや質問を表示する事ができる（例えば、全ての品目が完了しました）または、顧客が注文の選択を終わったかどうかに関わらず、ある一定の時間の経過後に質問を表示し、その時点で顧客は品目の注文を終わったかどうかを明らかにする［４４０］。顧客が全ての注文を完了した場合［４４０：はい］、そして顧客は全ての注文が終わった事を明示する［４５０］。それ以外の場合には［４４０：いいえ］、顧客は、注文を最初からやり直すため、ステップ２５に戻る。
【０２６０】
図８．３．２は、領収書発行のためのプロセス論理の流れを画いたものである。この論理では最初に顧客に対し、領収書が必要かどうかを尋ねる［１０］。領収書が必要でない場合［１０：いいえ］、システムは単に顧客の領収書に対する選択を保存する［４０］。領収書が必要な場合［１０：はい］、システムはどんなタイプの領収書が必要かを顧客に尋ねる［２０］。電子メール領収書の場合［２０：電子メール］、または領収書の印刷及び電子メールの場合は［２０：印刷及び電子メール］、そして顧客はメールの送り先のアドレスを指定する［３０］。システムは顧客の領収書の受け取り方を保存する［４０］。顧客が単に印刷された領収書を必要とする場合は［２０：印刷］、それ以外のインプットの必要はなく、システムは顧客の選択を保存する［４０］。
【０２６１】
図８．３．３は割引（または販売促進）及び報奨ポイント処理論理の流れを画いたものである。割引または販売促進は施設ごとに異なるためこのプログラムはオプショナルであり、施設の選択に依存する［１０］。施設が割引・販売促進を行わない場合は［１０：いいえ］、それを確認する論理は「報奨ポイント・論理」と題するセクションに続く。しかし、施設が割引・販売促進を行う場合［１０：はい］、続いてシステムは、顧客が割引、販売促進コードを持っているかどうかを尋ねる［２０］。
【０２６２】
顧客が割引料金または販売促進のためのプロモーションコードを持っていない場合［３０：いいえ］、次いで確認する論理は次の「報奨ポイント論理」と題するセクションに続く。一方、顧客が割引または販売促進のためのコードを持っている場合には［３０：はい］、続いて、顧客は割引またはプロモーションコードを入力するか、または以前に顧客のために保存してあった割引または販売促進のための特典をリストから選ぶ［４０］。次に顧客の割引または販売促進のための特典をシステムに保存し［５０］、そして割引または特典が顧客の注文に適用される事を表示する［６０］。
【０２６３】
報奨ポイント論理
具体的なシステムの選択としては、報奨ポイントの機能を備えていたほうがよい。しかし、論理は複雑になり、また、多くの施設ではすでに独自に実施している既存の報奨システムをシステムに入れられないことがある。それらを無視して論理を取り入れてあるが、将来はシステム全体として受け入れられるであろう。
【０２６４】
システムが報奨ポイント機能を備えていない場合には［７０：いいえ］、そして論理は次の「継続」と題するセクションに続く。しかし、システムが報奨ポイントの機能を備えている場合は［７０：はい］、そしてシステムは施設が報奨ポイントのプログラムを提供しているかどうかをチェックする［８０］。施設が報奨ポイントのプログラムを提供していない場合は［８０：いいえ］、そして論理は次の「継続」と題するセクションに続く。それ以外の場合は［８０：はい］、システムは顧客の機器にアクセスする為に、顧客の使用している機器をチェックする［９０］。
【０２６５】
顧客が携帯機を使用している場合は［９０：携帯機］、そしてそれを確認する論理は次の「報奨ポイントが充分な場合の論理」と題するセクションに続く。顧客が端末からアクセスしている場合は［９０：端末］、この場合システムは顧客の報奨ポイントアカウントのインフォメーションから、いつ顧客がシステムにログインしたかを決める必要があり、ログインしてあれば［１００］。携帯機を使用している顧客に対して報奨ポイントは自動的に記録されるようになっている。というのは、携帯機を使用している顧客は機器を使用する為に、システムアカウントに登録する必要があるからである。しかし、端末を使ってシステムにアクセスする顧客は、システムアカウントに登録する必要はない。顧客のシステムアカウントは現金不要支払い媒体の媒体に報奨ポイントのインフォメーションを記録することが可能である。しかし、それができない場合、端末を使用する顧客は報奨ポイントのインフォメーションを記録する報奨ポイントカードが必要となってくる。
【０２６６】
顧客の報奨ポイントアカウントの情報が現金不要支払い媒体の媒体から得られる場合は［１００：はい］、そしてそれを確認する論理は次の「報奨ポイントが充分な場合の論理」と題するセクションに続く。それ以外の場合は［１００：いいえ］、続いてシステムは顧客にシステム報奨ポイントカード、アカウントまたはそれらに関係する情報を顧客が持っているかどうかを尋ねる［１１０］。
【０２６７】
顧客がシステムに入力するための報奨ポイントカード、アカウント及び情報などを持たない場合は［１２０：いいえ］、そして、論理は次の「継続」と題するセクションに続く。それ以外の場合は［１２０：はい］、顧客はインプット／スワイプなどの方法で報奨ポイントカード、アカウントまたは関係する情報を端末に転送する［１３０］。
【０２６８】
報奨ポイントが充分な場合の論理
次いでシステムは、施設で決めた報奨ポイントプログラムに従って、顧客が充分な報奨ポイントを持っていて、報奨を受け取ることができるかどうかを決定する［１４０］。提供される報奨は施設によって異なり、顧客の支払い額の割引とか、顧客への無料の品目などが含まれるが、それらに限定されるものではない。基本的には、ひとつの施設で発行された報奨ポイントは、発行した施設が指定しない限り、または、施設が全国的、国際的なチェーンに入っているか、施設と施設がパートナー関係にあって、報奨ポイントをお互いに認め合う関係にある以外、他の施設で使うことができない。
【０２６９】
顧客が報奨を貰うのに充分なポイントを集めていない場合は［１５０：いいえ］、そして論理は次の「継続」と題するセクションに続く。しかし、顧客が報奨を貰うのに充分なポイントを集めている場合には［１５０：はい］、そしてシステムは顧客に報奨を見せて欲しいかと尋ねる［１６０］。システムが顧客に尋ねる理由は、顧客が知人と一緒に居る可能性があり、貰った報奨を顧客が知人に見せたくない場合があるからである。言い換えれば、顧客はポイントを自分で集めていて、他の人が居ない自分の好きな時に報奨を見たり、報奨と取り換えたりしたいことが、起り得るからである。これは、単に顧客のプライバシーを守るための小さな措置で、報奨を見たり、引き換えたりすることを顧客に決めて貰う事ができる。システムの設定を変えることで、このチェックを無効にすることが可能である。
【０２７０】
顧客が報奨を見ないと選択した場合は［１７０：いいえ］、そして論理は次の「継続」と題するセクションに続く。それ以外の場合「はい」では［１７０：はい］、システムは報奨を表示する［１８０］。そして、顧客に報奨を受け取りたいかどうかを尋ねる［１９０］。色々な理由から、顧客は今すぐ受け取りたくないこともあり得る。しかしながら、システムも顧客も施設によって決められている報奨の期限を、考慮に入れなければならない。
【０２７１】
顧客が報奨を受け取らない場合は［２００：いいえ］、そして論理は次の「継続」と題するセクションに続く。それ以外は［２００：はい］、システムは顧客の注文に報奨を適用する［２１０］。
【０２７２】
継続
過程論理は、ここに示す過程論理の図式を参照して作成した図式に戻る。
【０２７３】
図８．３．４は顧客の報奨ポイントをアップデイトする過程論理の図式を画いたものである。
【０２７４】
システムの選択としては、具体的に報奨ポイントの機能を備えていたほうがよい。しかし、論理は複雑になり、また多くの施設ではすでに独自に実施している報奨システムをシステムに入れられないことがある。それらを無視して論理を取り入れてあるが、将来はシステム全体として受け入れられるであろう。
【０２７５】
システムが報奨ポイントの機能を備えていない場合には［１０：いいえ］、そして論理は次の「継続」と題するセクションに続く。しかし、システムが報奨ポイントの機能を備えている場合は［１０：はい］、そしてシステムは施設が実際に報奨ポイントのプログラムを提供しているかどうかをチェックする［２０］。施設が報奨ポイントのプログラムを提供して居ない場合は［２０：いいえ］、そして論理は次の「継続」と題するセクションに続く。それ以外の場合は［２０：はい］、システムは顧客の機器にアクセスする為に、顧客の機器をチェックする［３０］。
【０２７６】
顧客が携帯機を使用している場合は［３０：携帯機］、そしてそれを確認する論理は次の「報奨ポイント保存の論理」と題するセクションに続く。顧客が端末からシステムにアクセスする場合には［３０：端末］、システムは、顧客が報奨ポイントのインフォメーションを記録しているカード、アカウント、または関連する情報をインプット、スワイプ、転送などの方法で以前にシステムに入力していたかどうかをチェックする［４０］。
【０２７７】
システムが顧客の報奨ポイントを以前に記録している場合は［４０：はい］、そしてそれを確認する論理は次の「報奨ポイント保存の論理」と題するセクションに続く。それ以外の場合は［４０：いいえ］、そして論理は次の「継続」と題するセクションに続く。
【０２７８】
報奨ポイント保存の論理
システムは現在のポイントが累積された顧客の報奨ポイントを保存する［５０］。
【０２７９】
継続
過程論理は、ここに示す過程論理の図式を参照して作成した図式に戻る。
【０２８０】
図８．３．５はシステムの動的販売機能に関する過程論理を画いたものである。
【０２８１】
この過程はスタッフが端末の動的販売オプションを選択することから始まる［１０］。次に従業員は特定の品目を選択するか、インプットすることにより［２０］、施設内で使用されている全ての機器に動的に（即時応答または即時応答に近い状態）転送する。次のステップとしては、適用される品目の数（または数量の上限）、タイムリミット（可能であれば）及びその他の必要なオプションを入力する［３０］。入力の終了は［４０］、システムは指定された品目の動的販売を表示する［５０］。得られた情報が不満足な場合は［６０：いいえ］、情報を修正［７０］、ステップ５０−６０を繰り返す。しかし、全ての情報が正確であると従業員が確認した場合は［６０：はい］、システムはログインした顧客が使用している施設内の機器をチェックする［８０］。
【０２８２】
顧客が端末を使用している場合は［８０：端末］、そして、それを確認する論理は次の「動的販売情報の送信」と題するセクションに続く。顧客が移動式の機器を使用している場合は［８０：携帯機］、システムは登録されている顧客用の機器がメッセージング‐アウェア型か、プログラムテクノロジーサポートメッセージング型かを判定する［９０］。ここにおける「メッセージング−アウェア」とは、携帯機またはプログラムテクノロジーを配備した機器で、非同期性（一方通行）のメッセージ・情報をサーバから受け取ることができ、機器側からのメッセージ・情報送信の要求は不要である。
【０２８３】
顧客の携帯機が真のメッセージング−アウェア型である場合は［９０：はい］、そしてそれを確認する論理は次の「動的販売情報の送信」と題するセクションに続く。
【０２８４】
それ以外の顧客の携帯機がメッセージングをサポートしない場合は［９０：いいえ］、次いで、システムは顧客のシステムに対し、「ポーリング」が可能かどうかチェックする［１００］。
【０２８５】
ポーリングとは真のメッセージング−アウェアでない機器が（この場合は顧客の携帯機）一定の時間間隔でサーバにアクセスして、メッセージ、情報が得られるかどうかを尋ねる方式である。
【０２８６】
もしも顧客が携帯機のポーリング機能を可能にすることができない場合は［１００：いいえ］、そしてそれを確認する論理は次の「品目情報の仮保存」と題するセクションに続く。しかし、顧客が携帯機のポーリング機能を可能にすることがすでに完了している場合には［１００：はい］、続いて、二つのアクションが同時に起る。第一のアクションは、以下の「品目情報の仮保存」と題するセクションで述べている。第二のアクションは、携帯機がポーリングの時間間隔に達したかどうかを機器が自分でチェックする［１０５］（サーバにメッセージの有無をチェック）。携帯機のポーリングの機能を前以て作動させていれば、機器は顧客の指定する時間間隔でサーバのポーリングを行うのである。
【０２８７】
ポーリングの時間間隔に達した場合は［１０５：はい］、そしてそれを確認する論理は次の「機器とサーバの交信」と題するセクションに続く。それ以外では、ポーリングの時間間隔に達しない場合で［１０５：いいえ］、携帯機のプログラムはある時間を置いてポーリングの時間間隔に達したかどうかを再度チェックする［１０５］。
【０２８８】
品目情報の仮保存
このシステムでは、動的な販売品目の情報は、顧客の機器がポーリングをした順番にサーバに保存する［１１０］、そして情報は次に顧客がサーバにアクセスする時まで保存されている。顧客が携帯機で何らかのアクションをすると、機器はサーバとの交信が必ず必要になってくる。次回に顧客がシステムにアクセスすると、顧客の動的な販売品目の情報を保持しているサーバを呼び出す［１１０：顧客アクセス］。この論理については次の「機器とサーバの交信」と題するセクションで述べる。
【０２８９】
機器とサーバの交信
顧客の携帯機がサーバと交信する場合［１１３］、システムは動的な販売品目の情報がまだ有効であるかどうかをチェックする［１１６］。有効性のチェックが重要なのは、動的な販売品目に対して、入手できる数量、または時間制限などがスタッフによって盛り込まれているからである。そのためシステムは動的販売が可能となるように、その品目を確保する必要がある。
【０２９０】
動的な販売品目が既に有効でなくなった場合は［１２０：いいえ］、システムは顧客にプロセスの終わったことを通知する［１２５］。それ以外の場合、品目が入手可能であれば［１２０：はい］、それを確認する論理は次の「動的販売情報の送信」と題するセクションに続く。
【０２９１】
動的販売情報の送信
サーバは機器に対して動的な販売品目に関する情報を送信する［１３０］。スタッフが動的販売品目情報を確認後（前述）、全てのメッセージング可能な機器はこの情報を受け取る。しかし、メッセージングが不可能な機器は、動的な販売品目が有効でなくなった時点で、その情報を受け取れないことがある。
【０２９２】
次に、動的な販売品目に関する情報は、然るべき機器（端末または携帯機）に表示される［１４０］。顧客がその品目を注文しない場合［１５０：いいえ］、システムは顧客が見ていた元の画面に戻し動的販売の過程論理を終了する［１６０］。
【０２９３】
顧客が品目の注文に興味を示した場合は［１５０：はい］、顧客は品目の数量を選択（可能であれば、スタッフは顧客に、その品目は一人当たり一個の限定であることを明示する）、更に誰宛の品目であるとか（オプション）、調理オプション及び必要な情報などを明示する［１７０］。次に、顧客は機器の送信オプションを選ぶ［１８０］、システムは注文をサーバに送信する［１９０］。
【０２９４】
動的販売の機能は基本的には先着順サービスであるから、特定の品目に付いて、他の顧客の動的販売注文が先にサーバに入力されると、その品目を取られてしまうことがある。
そのような事態が起らないように、システムは動的販売品目の在庫を再度チェックする［２００］。
【０２９５】
品目が品切れの場合は［２００：いいえ］、システムは特定品目の在庫状況を顧客に通知する［２１０］、この場合は、その品目は残念ながら品切れであることを通知する。
しかし、動的販売品目に在庫がある場合は［２００：はい］、すると二つのアクションが同時に起る。第一のアクションは、システムが顧客に対し特定品目の在庫状況を通知する［２１０］。この場合、顧客に注文が受け取られたことを通知する。他のアクションは図８．３．１に示される注文・プロセス・論理のステップ１０４−４３０が実行される［２２０］。
【０２９６】
本発明については、上記の各セクションで細かく説明しているが、最大の有利性はシステムである。このシステムはハードウェア機器、特にインターネットを利用できる携帯機及び特別にデザインした薄型の端末を利用している。これらの機器は外食施設での利用に最適であり、顧客は無線機器でスタッフの介入無しに注文の発注ができる完璧な注文処理の解決方法である。注文受取の指定、それに伴う一連の作業、支払い方法などがそれである。システムはコスト的に効率的であるＬｉｎｕｘなどオープンソースのソフトウェアが使用されている。システムは信頼性が高く、サーバは耐故障が高く、余力があり、施設に於ける重要なデーターはオフサイトで繰り返しバックアップすることができ、システムエラーは常にモニターされている。システムの機密保持には、来店コードが使用されている。このコードは注文の発注に必要であり、施設のシステムに保存されているが、機密性を必要とする信号やデーターは暗号化されている。システムは施設に於ける操業効率を向上させることができる。注文を分割して従業員またはシェフに送り、類似品目の注文はグループ化して注文の順番をいれ、一緒にまとめて処理する。このシステムの導入により、顧客の待ち時間は大幅に短縮される。なぜならば顧客は、１）メニューの提示（レストランの場合）、２）注文をとる、３）支払い処理をする、などの作業や手続きのために従業員を待つ必要がなくなってくる。それに加えて効率が良くなることで、全てがスピード化される。また、待ち時間を減らし、顧客が待つ間に品目を閲覧、注文の先取りが出来るようになる事でテーブルの回転率が向上する。
【０２９７】
システムの導入により、顧客サービスが向上し、外食施設に於ける顧客の体験が全体的に向上する。なぜなら、顧客が待つ時間が少なくなり、また顧客に対して問題提起や配慮の無いスタッフは配置転換されて顧客の満足度を向上させる事ができるからである。
【０２９８】
システムの導入により施設に於ける労働力不足やコストが緩和される。なぜなら、このシステムは従業員の過剰労働や人員不足時に於ける役割を以前にも取り扱ったことがあったからである。
このシステムでは、顧客の報奨ポイントを一箇所に統合することができる。
またシステム導入により、ある種の品目の動的な販売推進、在庫の削減などで販売を増加させることができる。
【０２９９】
上に述べた説明及び実施例のみが本発明の適用範囲に限定されるものと解釈されるべきではない。その他のバリエーションも実現可能であるため、本発明の適用範囲は特許請求の範囲及びその法的同等性によって決定されるべきである。
【図面の簡単な説明】
【０３００】
【図１．１】レストランでの実施形態例を示す図である。
【図１．２】店舗での実施形態例を示す図である。
【図２】顧客が端末を使って注文を入れる場合の、システムのネットワーク接続を示す概観図である。
【図３】顧客が携帯機を使って注文を入れる場合の、システムのネットワーク接続を示す概観図である。
【図４】端末の外観図である。
【図５】内部構成（部品）図である。
【図６．１．１．１】現金と現金不要支払い媒体の両方を受け入れるレストランにおける端末解決法の過程論理を描く図である。
【図６．１．２．１】現金不要支払い媒体のみを受け入れるレストランにおける端末解決法の過程論理を描く図である。
【図６．１．３．１】レストランでの端末の表示画面の表示例である。
【図６．２．１．１】現金と現金不要支払い媒体の両方を受け入れる店舗における端末解決法の過程論理を描く図である。
【図６．２．２．１】現金不要支払い媒体のみを使う店舗における端末解決法の過程論理を描く図である。
【図６．２．３．１】店舗での端末の表示画面の表示例である。
【図７．１．１．１】現金と現金不要支払い媒体の両方を受け入れるレストランにおける携帯機器解決法の過程論理を描く図である。
【図７．１．２．１】現金不要支払い媒体のみを受け入れるレストランにおける携帯機器解決法の過程論理を描く図である。
【図７．１．３．１】レストランでの携帯機器の表示画面の表示例である。
【図７．２．１．１】現金と現金不要支払い媒体の両方を受け入れる店舗における携帯機器解決法の過程論理を描く図である。
【図７．２．２．１】現金不要支払い媒体のみを受け入れる店舗における携帯機器解決法の過程論理を描く図である。
【図７．２．３．１】店舗での携帯機器の表示画面の表示例である。
【図７．３．１】携帯機器におけるシステムへのログインや登録方法の過程論理を描く図である。
【図７．３．２】携帯機器における店のログイン過程論理を描く図である。
【図８．１．１．１】現金と現金不要支払い媒体の両方を受け入れるレストランにおける支払い決算の論理を描く図である。
【図８．１．２．１】現金不要支払い媒体のみを受け入れるレストランにおける支払い決算の論理を描く図である。
【図８．１．３．１】レストランにおける自動着席案内システムの論理を描く図である。
【図８．１．３．２】レストランにおける自動着席案内システム論理において図．８．１．３．１によって最初に用いられた顧客情報入力過程論理を描く図である。
【図８．１．３．４】レストランにおけるログアウトの論理を描く図である。
【図８．１．３．５】レストランにおける閲覧、前注文の過程論理を描く図である。
【図８．３．１】業種（レストランか店舗か）、機種（端末か携帯機か）、そして支払い媒体（現金と現金不要、若しくは現金不要のみ）などにかかわらず、注文処理論理の核心となる図である。
【図８．３．２】領収書を明細なもととする過程論理を示す図である。
【図８．３．３】ディスカウント（若しくは販売促進特売）そして報奨ポイントの処理論理を描く図である。
【図８．３．４】顧客の報奨ポイントをアップデイトするところの過程論理を描く図である。
【図８．３．５】間違いなく売れるこのシステムの特徴の論理を描く図である。
【図１．１】
2005527017.tif 000004
【図１．２】
2005527017.tif 000005
【図２】
2005527017.tif 000006
【図３】
2005527017.tif 000007
【図４】
2005527017.tif 000008
【図５】
2005527017.tif 000009
【図６．１．１．１】
2005527017.tif 000010
【図６．１．２．１】
2005527017.tif 000011
【図６．１．３．１】
2005527017.tif 000012
【図６．２．１．１】
2005527017.tif 000013
【図６．２．２．１】
2005527017.tif 000014
【図６．２．３．１】
2005527017.tif 000015
【図７．１．１．１】
2005527017.tif 000016
【図７．１．２．１】
2005527017.tif 000017
【図７．１．３．１】
2005527017.tif 000018
【図７．２．１．１】
2005527017.tif 000019
【図７．２．２．１】
2005527017.tif 000020
【図７．２．３．１】
2005527017.tif 000021
【図７．３．１】
2005527017.tif 000022
【図７．３．２】
2005527017.tif 000023
【図８．１．１．１】
2005527017.tif 000024
【図８．１．２．１】
2005527017.tif 000025
【図８．１．３．１】
2005527017.tif 000026
【図８．１．３．２】
2005527017.tif 000027
【図８．１．３．４】
2005527017.tif 000028
【図８．１．３．５】
2005527017.tif 000029
【図８．３．１】
2005527017.tif 000030
【図８．３．２】
2005527017.tif 000031
【図８．３．３】
2005527017.tif 000032
【図８．３．４】
2005527017.tif 000033
【図８．３．５】
2005527017.tif 000034
【国際調査報告】
2005527017.tif 000035
2005527017.tif 000036
2005527017.tif 000037