(57)【要約】【課題】  飲食店において来客者が口頭で注文及び清算請求をすることが困難な状況下において、注文及び清算請求をインターネット等による汎用メッセージングサービスで実現する。【解決手段】  図表１の来客者は飲食店に対し注文及び清算請求をするに、来客者が利用する汎用メッセージングサービスに、仲介装置により管理された飲食店・座席情報のＱＲコードを撮影した画像を仲介装置に送信し、同装置により管理された注文メニュー情報及び清算要求を入力することで、飲食店に対し注文及び清算要求が仲介装置から通知される。【選択図】図１
2020047231.tif 000002
【特許請求の範囲】
【請求項１】
専用アプリケーションを必要とせず、汎用メッセージングサービスを介した飲食店への注文・清算要求を実現する仲介装置。
【請求項２】
体系化された飲食店・座席情報をＱＲコードとして飲食店内座席付近に提示し、来客者がＱＲコードを撮影し、そのまま画像として仲介装置へ送信することで、来客者が手入力で誤った情報を送信することなく、汎用メッセンジャーサービスにＱＲコード内容の識別機能を要求することもなく、より正確な注文・清算要求を飲食店に通知することを実現する仲介装置。
【請求項３】
第三者が来客者に成りすまして注文する飲食店被害を防ぎつつ、来店客の実用的利便性を確保する目的で、初回注文数を０から任意数に制限し、飲食店が来店客の顔写真や来店人数の申告数・着席状態によって本人確認ができ、又は仲介装置から表示される本システムの利用実績、モバイル決済登録有無、過去問題歴を参照し、その結果として問題が無いと判断されれば、注文制限を解除し、不明な場合は仲介装置が発行する確認番号を飲食店から来店客へ通知し、来店客が汎用メッセンジャーサービスを通じ制限を外す仲介装置。
【請求項４】
飲食店による配膳時の注文者特定方法として、仲介装置からイラストや写真で指定された「ジェスチャー」を配膳前に通知し、配膳時に来店客が主に顔の近くで実施し、飲食店が注文者を特定できる仲介装置。
【発明の詳細な説明】
【技術分野】
【０００１】  本発明は、飲食店において注文及び清算をインターネット等による汎用メッセージングサービスで実現する仲介装置に関するものである。
【背景技術】
【０００２】  多種多様な商取引において、従来は口頭や紙面などによるコミュニケーションを通じて行われていたものが、インターネット普及に伴い、機械化・ネットワーク化され、専用システムやアプリケーションによって普及しつつある。【０００３】  しかし、各社ごとに従来の商取引の慣例を継承する必要性や、悪意ある第三者による攻撃を防ぐ安全性の観点等から、独自の専用システムやアプリケーション・ソフトウェアなどによってシステムを構築してきた。【０００４】  一方で、特に飲食業界において営業対象となる顧客は一般人が主となる中、専用アプリケーションのインストールを要するサービスやシステムの導入ハードルは高く、そのようなインストール作業や顧客の動作を極力必要とせず、一方で確実で安全な飲食提供サービスを実現する装置の実現が求められていた。【０００５】特許文献１では、携帯端末において位置情報を取得し、店舗位置情報の範囲内であれば注文を受け付けることで、悪戯防止を図っている。【０００６】特許文献２では、顧客の注文の手間を省くことができるオーダシステムとして、専用端末または顧客端末を使用することが記載されている。【０００７】特許文献３では、より安価にかつ簡便に店舗内の各客席から注文を受け付けられるようにするため、顧客端末等を使用した専用システムを使用することが記載されている。【０００８】特許文献４では、より安価にメニューブックを参照し客層情報及び注文取得し、注文入力端末を介し注文管理をすることが記載されている。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】特開２０１４−２６４１号公報
【００１０】
【特許文献２】特開２００２−２１５７５５号公報
【００１１】
【特許文献３】特開２００２−３６７０４０号公報
【００１２】
【特許文献４】特開２０１１−２２７６４５号公報
【発明の概要】
【発明が解決しようとする課題】
【００１３】  特許文献１、特許文献２及び特許文献３に記載の技術並びに従来は、来店客が飲食店へインターネット等の通信を通じ注文する場合、専用アプリケーションが必要、又は専用アプリケーション・ソフトウェアを携帯端末にインストールする作業が必要であった。【００１４】  また、特許文献１ではＧＰＳ等により位置を捕捉している飲食店の特定及びその座席位置情報も、従来のタッチパネル端末等による注文の場合、事前に飲食店が座席を設定しているため、来客者に提示する必要がなく、注文及び清算請求用途において来客者へ提示されていない。【００１５】  更に、特許文献１で座席位置情報を来客者が間違って入力した場合、異なる来客者に配膳されるリスク、つまり、正当な来客者ではない第三者が、当該座席から注文していると装う悪戯・偽造行為が可能である課題があった。【００１６】また、配膳場所に多人数が存在している場合、注文者本人の特定を円滑に実施する課題があった。
【課題を解決するための手段】
【００１７】  飲食店への来客者が、自らの携帯端末において専用アプリケーションを必要とせず、主にテキストによるコミュニケーションを目的とした汎用メッセージングサービスを介し、注文・清算を実現する。【００１８】  体系化された飲食店及び座席情報をＱＲコードとして飲食店内座席付近に提示し、来客者がＱＲコードを自らの携帯端末で撮影し、そのまま画像として仲介装置へ送信することで、来客者がテキストや手入力で誤った座席情報及び飲食店を送信することなく、正しい飲食店と座席情報を仲介装置に通知できる。【００１９】  また、飲食店は座席位置情報で特定される来店者及び飲食店双方に仲介装置から通知される共通の「確認コード」を、注文前又は配膳時に口頭又は画面提示で確認できるようにすること、又は来店客が事前に仲介装置に保存した顔写真による同一人物性の確認、又は来店客が仲介装置を過去に利用した際の履歴等による信頼性確認を通じ、第三者による悪戯行為を未然に防ぐ。【００２０】  更に、配膳時の本人確認として、仲介装置からイラストや写真で指定された「ジェスチャー」を来店客が主に顔の近くで実施し、飲食店が本人特定をする。
【発明の効果】
【００２１】  特許文献１、特許文献２及び特許文献３に記載の背景と同じく、飲食店において、繁忙時や人手不足、及び日本語に不慣れな外国人アルバイト等による接客で、円滑に来客者から注文を受注し、清算要求に応えることが難しいことがある。【００２２】  本発明により、来客者は自身が使い慣れている携帯端末の汎用メッセージングサービスで注文・清算要求を行え、また、間違った飲食店・座席情報を入力することが避けられるため、飲食店の売上や回転率の向上に寄与すると考えられる。【００２３】  また、配膳時の「ジェスチャー」による静音な本人確認の実施方法によって、スポーツ観戦や音楽演奏中のような雑踏、又は静音が求められる場所などの口頭でのコミュニケーションが難しい場所でも、本人確認が円滑に行えるため、受注だけでなく配膳がスムーズに行え、前記と同じく飲食店の売上向上が期待できる。
【図面の簡単な説明】
【００２４】
【図１】本発明の実施形態の基本的構成図である。
【図２】本発明における受注開始までの動作を表すフローチャートである。
【図３】本発明の実施形態における情報の流れを表す接続図である。
【図４】図３と異なる実施形態を表す接続図である。
【図５】飲食店２００用の専用アプリケーションの画面例である。
【図６】本発明の実施形態における画面例（来客者による開始）である。
【図７】本発明の実施形態における画面例（来客者による注文）である。
【図８】本発明の実施形態における画面例（来客者によるその他）である。
【図９】本発明の実施形態における画面例（飲食店による受注等）である。
【図１０】本発明の実施形態における画面例（来客者による清算）である。
【図１１】本発明の実施形態における画面例（飲食店による清算）である。
【図１２】本発明の実施形態における画面例（飲食店によるメニュー作成）である。
【図１３】本発明の実施形態における画面例（飲食店によるメニュー修正や削除）である。
【図１４】本発明の実施形態におけるジェスチャー指示図例である。
【図１５】本発明の実施形態におけるジェスチャーを利用した飲食店の受注例である。
【発明を実施するための形態】
【００２５】  汎用メッセージングサービスを介し、来店客が飲食店において注文及び清算又は清算要求をすることを目的とした本発明の一実施形態について図面を参照して説明する。
【実施例１】
【００２６】  まず、本発明は図１にある基本構成の通り、インターネット６００や汎用メッセンジャーサービス３００といった通信インフラ及びメッセージング機能の活用の上で成立するものであるが、汎用メッセンジャーサービス３００を限定するものではない。【００２７】  来店客１００は、飲食店２００へ来店時に、本発明が導入されていることを飲食店の説明や掲示、Ｗｅｂ等により知る。その説明の中で、汎用メッセンジャーサービス３００を使った仲介装置５００へのコンタクト方法（連絡先）を知る。このコンタクト方法は、飲食店２００が異なっても同一サービスである限り同じであるため、一回、本発明を利用した場合は、二回目以降について連絡先は汎用メッセンジャーサービス３００に登録されている。【００２８】  次に、来店客１００は、飲食店・座席情報が収納されたＱＲコード２１０を来店客１００が有する携帯端末で撮影し、汎用メッセンジャーサービス３００を介して仲介装置５００へ画像として送信する。【００２９】  仲介装置５００は、来店客３００からの前記ＱＲコード２１０の画像を受信し、ＱＲコード内の情報を解読することで、飲食店・座席情報を得る。【００３０】  仲介装置５００は、前記で得られた飲食店・座席情報を元に、該当する飲食店として登録されている飲食店２００の汎用メッセンジャーサービス３００の宛先に来店客１００が座席情報で示される座席に着いたことを通知する。【００３１】  同時に、図２のフロー図にある通り、仲介装置５００は、来店客１００に対して汎用メッセンジャーサービス３００を通じ、飲食店の名称及び歓迎のあいさつ等を通知した後に、飲食店２００の事前の要望に応じて利用人数の確認を来客者１００に実施する。【００３２】  続いて仲介装置５００は、来客者１００のリスク審査を実施し、過去のトラブル回数や正常利用履歴数、モバイル決済登録の有無などを加味し、飲食店２００への注文を受注（仲介）することを自動判断する。この際に、飲食店２００の事前の要望に応じて、このリスク審査を省略することができる。【００３３】  来客者１００のリスク審査において仲介装置５００が飲食店２００へ来客者１００の現認（目視での現場確認）を求めることがある。この場合、事前に来客者１００が自身を識別できる顔写真などを仲介装置５００の求めに応じ送付していた場合、該当写真を飲食店２００へ提示し、また、飲食店２００での様子を鑑み、飲食店２００が利用者１００を現認できない場合、来客者１００に対して汎用メッセンジャーサービス３００を通じ確認コード（数字又はテキスト４桁相当）の回答を求める通知をする。【００３４】  一方、飲食店２００の汎用メッセンジャーサービス３００には確認コードが提示され、その確認コードを来客者１００に口頭等にて伝達するよう指示を出し、当該確認コードを来客者１００が飲食店２００から得て、汎用メッセンジャーサービス３００を介し仲介装置５００に送信することで、来客者１００は飲食店２００へ注文を送信できる権利を得る。当該確認コードが正しくない場合、又は第三者による悪戯や偽装アクセスであるとした場合、注文受付拒否及び前記リスク審査で参照されるトラブル回数として加算される。【００３５】  リスク審査を通���又は前記の通り図２の受注開始に至った場合、図３の受注開始後の注文受付状態になる。【００３６】  図３において注文を来客者１００が行うには、注文メニュー表２２０（メニューブックとも表現される当該飲食店で注文可能な一覧）に記載されたメニュー名又は省略番号について汎用メッセンジャーサービス３００を介し仲介装置５００に「○○を注文する」と通知すると、仲介装置５００は来客者１００が飲食店２００を利用中だと認識しているため、汎用メッセンジャーサービス３００を介し飲食店２００へ対し、来客者１００から通知された注文メニューを通知する。
【実施例２】
【００３７】  実施例１のように飲食店２００は汎用メッセンジャーサービス３００を介して仲介装置５００から通知を受領するだけでなく、図４のように、汎用メッセンジャーサービス３００ではなく、専用アプリケーション２３０による通知受領方式も有効である。これは来客者１００が利用する汎用メッセンジャーサービス３００と飲食店２００が直接接続されている訳でなく、仲介装置５００を介しているために可能な選択肢である。【００３８】  また、具体的な前記の専用アプリケーション２３０の待機画面例としては図５のように、汎用メッセンジャーサービス３００では表現が難しい状態の一覧を提示できることが特徴であり、受注状態や配膳状況、会計等の指示及び情報を得られる。
【実施例３】
【００３９】  具体的な来店客１００による汎用メッセンジャーサービス３００の、来店時の画面例を図６に示す。来店客１００における汎用メッセンジャーサービス３００の画面では、左側が仲介装置５００により通知されるメッセージとなり、右側が来店客１００による入力又は選択メッセージとなる。図６では、飲食店・座席位置情報を含むＱＲコードを撮影し送信、来店人数を入力している。【００４０】  続いて図７においては、来店客１００による注文までの基本的な画面を示し、図８において注文の確定及び注文のキャンセル、そして注文の際にオプションとして「好み」を付帯させる場合の画面例を示す。
【実施例４】
【００４１】  図９には、飲食店２００が１００から注文を受領し、受注確定又は欠品時の画面例を示す。特に「来店客審査」については、過去にトラブル回数が追加された要注意客が来店時し、本発明を利用した際にも提示されるもので、プライバシー保護の観点から仲介装置５００から提示される項目は制限することになる。
【実施例５】
【００４２】  図１０には清算（会計）を来店客１００が飲食店２００へ要求する際の画面例を示す。本実施例においては、清算要求を来店客１００が行うと、仲介装置５００を通じて飲食店２００へ通知され、従来通りの会計（飲食店による会計）として処理することを前提としている。来店客１００は、汎用メッセンジャーサービス３００を通じて仲介装置５００から、過去の注文品などの明細を得られ、同じく飲食店２００も、汎用メッセンジャーサービス３００を通じて同情報を得られるため、会計時に口頭での注文品合計と合算することで、従来通りの会計として処理可能である。そのため、会計レジ（ＰＯＳレジ等）を効率的にする観点で、飲食店２００の専用アプリケーション２３０では、図１１の画面例のような清算機能を有する。
【実施例６】
【００４３】  飲食店２００は来店客１００から受注する際に注文メニュー表２２０の内容を仲介装置５００に記録しておく必要がある。これをメニュー作成とし、同機能を飲食店２００は汎用メッセンジャーサービス３００を介し、仲介装置５００にメニューの名称や金額、商品写真などを登録できる画面例を、図１２に示す。特に全国又は地域で一般的なメニューについては定番メニューとして事前定義を仲介装置５００は有し、極力この定番メニューを飲食店２００が活用することで、飲食店が異なる場合でも同一メニューとして扱うことができるため、来店客１００の趣向性判定に活かせる有効な履歴データとなる。また、一般的な居酒屋では「今日のお勧め」のようなメニューがあり来店客１００に強く推奨するが、そのメニュー表については、そのまま写真画像として仲介装置５００に保存できるようにし、来店客１００が飲食店・座席情報を通知後のレスポンスとして、同画像を提示し、通常来店時と同じように推奨感を出すことができる。【００４４】  また、図１３には飲食店２００が作成したメニューの修正や削除についての画面例を示す。
【実施例７】
【００４５】  飲食店２００の座席位置を示す範囲が大きい場合、または観覧席のように１つのシートに複数人が着座又は立席している場合、受注した商品を飲食店２００が来店客１００に配膳する際に、演奏を伴う場合、環境が煩い場合など注文本人の特定が口頭では難しい場合がある。【００４６】  その際に、来店客１００が注文本人である本人特定を円滑にするため、図１４のようなジェスチャーを示すイラスト又は写真を、図１５にある本人特定手法として活用する。仲介装置５００を通じ、飲食店２００及び来店客１００に通知される確認番号以外に、同様に図１５のようなジェスチャー指示を通知することで、配膳する際のスタッフが迷っていた場合に、同ジェスチャーをすることで、スタッフが円滑に注文本人の特定ができ、配膳が円滑に行える。特に、顔の近くで行う顔と手のシンプルなジェスチャーとすることで、動きにくい環境や顔しか見えないような場所でも、ジェスチャーを提示しやすいため、そのようなジェスチャーにしている。
【符号の説明】
【００４７】１００    来店客
２００    飲食店
２１０    ＱＲコード（飲食店・座席情報）
２２０    注文メニュー表
２３０    専用アプリケーション
３００    汎用メッセンジャーサービス
５００    仲介装置
６００    インターネット・通信網
【図１】
2020047231.tif 000003
【図２】
2020047231.tif 000004
【図３】
2020047231.tif 000005
【図４】
2020047231.tif 000006
【図５】
2020047231.tif 000007
【図６】
2020047231.tif 000008
【図７】
2020047231.tif 000009
【図８】
2020047231.tif 000010
【図９】
2020047231.tif 000011
【図１０】
2020047231.tif 000012
【図１１】
2020047231.tif 000013
【図１２】
2020047231.tif 000014
【図１３】
2020047231.tif 000015
【図１４】
2020047231.tif 000016
【図１５】
2020047231.tif 000017