以下、本発明を図示する実施形態に基づいて説明する。
<<< §1. 基本的実施形態に係る店舗予約システム >>>
<1−1.システムの基本構成と基本動作>
図1は、本発明の基本的実施形態に係る店舗予約システムの構成および動作を示すブロック図である。この店舗予約システムは、訪問予定の店舗Qについて事前に予約を行うためのシステムであり、図示のとおり、予約場所Pに設置された予約用ユニット100と、店舗Qに設置された店舗用ユニット200と、予約用ユニット100および店舗用ユニット200と交信する機能を有する管理サーバ300と、を備えている。
ここでは、情報記録媒体Mを所持しているユーザU(店舗Qについての顧客)が、予約場所Pにおいて店舗Qの事前予約を行った後、店舗Qまで移動して店頭で予約確認を行う例を説明する。このシステムに利用される情報記録媒体Mは、携帯可能であって、何らかの識別情報Iが記録されており、当該識別情報Iを外部から読み出すことが可能な媒体であれば、どのような媒体であってもかまわない。ここでは、交通系ICカードを情報記録媒体Mとして用い、駅構内を予約場所Pとした場合を一例として、以下の説明を行う。
交通系ICカードは、公共交通機関が発行するIC内蔵型のプリペイドカードであり、改札口を通過するときの運賃の精算処理はもとより、様々な店舗での支払いに利用されている。一般に、ICカードには、個々のカードごとに固有のID番号が付与されている。当該ID番号は、内蔵されているICチップに記録されており、ICカード用リーダライタ装置を用いて外部に読み出すことができる。たとえば、最近の非接触型ICカードの場合、NFCの無線通信規格に応じた手順により、ID番号の読出しが可能になっている。
図1に示す例において、情報記録媒体Mは、この交通系ICカードであり、識別情報Iは、ICチップに記録されている固有のID番号である。駅の改札口を出たユーザUは、駅構内(予約場所P)に設置された予約用ユニット100を利用して予約操作を行う。予約用ユニット100は、情報記録媒体Mに記録されている識別情報Iを読み出す機能を有し、店舗Qの予約を行うために利用される装置である。図示の例の場合、予約用ユニット100は、いわゆる「キオスク端末」として駅構内に設置された装置であり、交通系ICカードから固有のID番号を読み出す機能を有している。
ユーザUは、この予約用ユニット100に対して、店舗Qの予約を行うための予約操作を行う。予約用ユニット100は、オペレータ(ユーザU)の予約操作に基づいて、情報記録媒体Mに記録されている識別情報Iを読み出し、これをネットワークを介して管理サーバ300に送信する。管理サーバ300は、予約用ユニット100から送信されてきた識別情報Iをネットワークを介して店舗用ユニット200へと転送する。店舗用ユニット200は、転送されてきた識別情報Iを予約受付を示す情報として格納する。以上で、このシステムにおける予約操作は完了である。
こうして、予約場所Pで事前予約を行ったユーザUは、情報記録媒体Mを所持したまま店舗Qへと移動する。図1において、店舗Qに描かれているユーザUおよび情報記録媒体Mは、予約場所Pに描かれているユーザUおよび情報記録媒体Mと同一のものである。店舗Qに到着したユーザUは、今度は、店舗用ユニット200に対して、予約操作に用いた情報記録媒体Mを利用して来店確認操作を行う。
店舗用ユニット200は、店舗においてユーザU(来店者)の来店確認を行うために利用される装置であり、オペレータの来店確認操作に基づいて、情報記録媒体Mに記録されている識別情報Iを読み出し、管理サーバ300から転送されてきた識別情報Iと照合する機能を有する。ここに示す例の場合、店舗用ユニット200は、交通系ICカードから固有のID番号を識別情報Iとして読み出すことになり、上述した予約操作時に管理サーバ300から転送されてきた固有のID番号と照合する処理を行う。照合に成功すれば、事前予約を行った客が実際に来店したことが確認できる。逆言すれば、当該来店者についての予約確認がとれたことになる。
より具体的には、店舗用ユニット200は、予約操作に基づいて管理サーバ300から転送されてきた識別情報Iを予約テーブルに格納しておき、来店確認操作に基づいて情報記録媒体Mから識別情報Iを読み出したときに、読み出した識別情報Iが予約テーブルに格納されているか否かを調べる照合処理を行い、格納されていた場合には、当該来店確認操作に対して予約が確認された旨を提示し、格納されていなかった場合には、当該来店確認操作に対して予約が確認できない旨を提示する。ここに示す実施例の場合、店舗用ユニット200には、ディスプレイが備わっており、このディスプレイの画面上に照合処理の結果が提示されることになる。
なお、店舗用ユニット200に対して来店確認操作を行うオペレータは、ユーザU自身であってもよいし、店舗Qのスタッフであってもかまわない。もっとも、特定の来店者について、事前予約がなされていたか否かの確認は、店舗Qのスタッフが行う必要がある(たとえば、予約の有無によって、来店者の案内順に優先順位をつけたりするため)。したがって、通常の運用では、ユーザUは来店時に、予約に用いた情報記録媒体Mを店舗Qのスタッフに手渡して事前予約を行っていることを告げ、店舗Qのスタッフが当該情報記録媒体Mを用いて来店確認操作を行い、ディスプレイ画面上で事前予約が行われていたことを確認することになろう。もちろん、ユーザU自身が来店確認操作を行い、店舗Qのスタッフに画面表示を見てもらうようにしてもかまわない。
続いて、上述した予約操作および来店確認操作の具体的な操作手順を、実際に表示される画面例を参照しながら説明する。図2は、図1に示す予約用ユニット100を用いた予約操作の画面表示例を示す図である。図2(a) は、「キオスク端末」として駅構内に設置された予約用ユニット100Aの正面図であり、その表示画面101Aには、レストランAについての事前予約を行うための予約開始画面が表示されている。また、この表示画面101Aの下方には、情報読取部102Aが設けられている。
予約操作を行うオペレータ(通常は、店舗Qを利用するユーザU)が、図2(a) に示す表示画面101A上の「予約開始」ボタンをタップすると、図2(b) に示す画面に切り替わり、「お持ちのICカードでタッチして下さい。」との案内が表示される。そこで、図2(c) に示すように、オペレータが情報記録媒体M(この例の場合、交通系ICカード)を情報読取部102Aに接触させる操作を行うと、情報記録媒体Mに記録されている識別情報Iが予約用ユニット100Aによって読み出され、管理サーバ300へ送信される。そして、画面は図2(d) のように切り替わり、予約が完了したことが通知される。この例の場合、予約操作が行われた時刻が予約受付時刻「17:32」として表示されている。前述したように、管理サーバ300へ送信された識別情報Iは、店舗用ユニット200へと転送され、予約テーブルに格納される。
一方、店舗Qに到着したユーザUが、予約操作に用いた情報記録媒体M(交通系ICカード)を店舗Qのスタッフに手渡して、事前予約を行っていることを告げた場合、当該スタッフがオペレータとして来店確認操作を行うことになる。
図3は、図1に示す店舗用ユニット200を用いた来店確認操作の画面表示例を示す図である。図3(a) は、店舗Qの受付に設置された店舗用ユニット200Aの正面図である。この店舗用ユニット200Aも、予約用ユニット100Aと同様の外観をもった装置であり、その表示画面201Aには、レストランAについての予約確認を行うための確認開始画面が表示されている。また、この表示画面201Aの下方には、情報読取部202Aが設けられている。
来店確認操作を行うオペレータ(上例の場合、店舗Qのスタッフ)が、図3(a) に示す表示画面201A上の「確認開始」ボタンをタップすると、図3(b) に示す画面に切り替わり、「予約に使ったICカードでタッチして下さい。」との案内が表示される。そこで、図3(c) に示すように、オペレータが情報記録媒体M(交通系ICカード)を情報読取部202Aに接触させる操作を行うと、情報記録媒体Mに記録されている識別情報Iが店舗用ユニット200Aによって読み出され、前述したように、読み出した識別情報Iが予約テーブルに格納されているか否かを調べる照合処理が行われる。照合に成功したら(すなわち、読み出した識別情報Iが予約テーブルに格納されていたら)、図3(d) に示すように、予約が確認された旨の画面が表示される。
なお、図3(d) に示す例では、予約が確認された旨の表示とともに、予約操作が行われた時刻が予約受付時刻「17:32」として表示されているが、これは、ここに示す実施例に係る店舗用ユニット200Aが、管理サーバ300から転送されてきた識別情報Iを、予約受付時刻を示す情報とともに予約テーブルに格納し、当該予約受付時刻の提示処理を行う機能を有しているためである。
予約受付時刻を示す情報は、図2(c) に示す予約操作が行われた際に予約用ユニット100によって発生するようにし、識別情報Iとともに管理サーバ300を介して店舗用ユニット200に送信するようにしてもよいが、店舗用ユニット200が、管理サーバ300から識別情報Iを受信した際に店舗用ユニット200によって発生するようにしてもかまわない。厳密に言えば、図2(c) に示す予約操作が行われた時点と、店舗用ユニット200が識別情報Iを受信した時点とは異なっているが、管理サーバ300が識別情報Iの転送を速やかに行えば、実用上、いずれの時点を予約受付時刻としても問題はない。もちろん、管理サーバ300が識別情報Iを受信した時点や識別情報Iを転送した時点を予約受付時刻とする運用を採ってもかまわない。
予約受付時刻は、後述するように、複数のユーザからの事前予約があった場合に、いずれのユーザの予約が先かを判定する基準として利用されるが、数秒や数分の誤差があっても、実用上、大きな問題にはならない。したがって、本発明を実施する上で、予約受付時刻としては、予約操作が行われたおおよその時刻を用いれば十分である。
予約操作が行われたときに、識別情報Iとともに予約受付時刻を予約テーブルに格納しておくようにすれば、来店確認操作が行われたときに、店舗用ユニット200Aによって予約受付時刻を提示することができる。たとえば、図3(d) に示す例の場合、当該来店者が17:32に事前予約を行っていたことが確認できる。したがって、店舗Qのスタッフは、この予約受付時刻を参考にして、各来店者の案内順を決定する運用が可能になる。
一方、店舗用ユニット200Aが、照合に失敗した場合、すなわち、店舗用ユニット200Aによって読み出された識別情報Iが、予約テーブルに格納されていなかった場合には、図4(a) に示すように、当該来店確認操作に対して予約が確認できない旨の表示が行われる。通常、同一の情報記録媒体Mを用いて予約操作と来店確認操作とを行えば、読み出される識別情報Iも同一なので、照合に成功するはずであるが、ユーザUが情報記録媒体Mを取り違えたような場合は、照合に失敗し、図4(a) に示すような画面表示がなされることになる。この場合、ユーザUは、正しい情報記録媒体Mを用いて再度来店確認操作を試みればよい。もちろん、どうしても照合に成功しなかった場合は、もともと事前予約がなかったものとして取り扱えばよい(この場合は、たとえば、予約受付時刻ではなく、現実の来店時刻に基づいて、案内順の決定が行われることになろう)。
<1−2.いくつかのバリエーション>
以上、交通系ICカードを情報記録媒体Mとして用いた例を述べたが、もちろん、情報記録媒体Mとして利用可能なICカードは、交通系ICカードに限定されるものではなく、銀行系ICカードや信販系ICカードでもよい。あるいは、運転免許証や社員証などとして機能するICカードを用いてもかまわない。また、本発明に用いる情報記録媒体Mは、必ずしもICカードである必要はなく、携帯可能であって、何らかの識別情報Iが記録されており、当該識別情報Iを外部から読み出すことが可能な媒体であれば、どのような媒体であってもかまわない。
具体的なバリエーションをいくつか挙げておくと、たとえば、ICカードの代わりにICタグを用いることも可能であるし、磁気カードを用いることも可能である。これらの媒体にも固有のID番号が記録されているため、当該ID番号を識別情報Iとして読み出して利用することができる。この場合、予約用ユニット100および店舗用ユニット200には、ICカード用リーダライタ装置の代わりに、ICタグ用読取装置や磁気カード用読取装置を組み込んでおけばよい。
また、識別情報Iは、バーコードやQRコード(登録商標)として媒体上に記録されていてもかまわない。この場合、予約用ユニット100および店舗用ユニット200には、バーコード読取装置やQRコード(登録商標)読取装置を組み込んでおけばよい。このような観点では、商品コードがバーコードやQRコード(登録商標)として印刷された商品を利用して、予約操作および来店確認操作を行うことも可能である。
たとえば、包装にバーコード(識別情報I)が印刷された板チョコ(情報記録媒体M)を手にしたユーザUは、予約用ユニット100に組み込まれたバーコード読取装置によって当該バーコード(識別情報I)を読み取らせることにより予約操作を行うことができ、店舗用ユニット200に組み込まれたバーコード読取装置によって当該バーコード(識別情報I)を読み取らせることにより来店確認操作を行うことができる。
あるいは、識別情報Iは、文字として媒体上に記録されていてもかまわない。この場合、予約用ユニット100および店舗用ユニット200には、OCR装置を組み込んでおけばよい。このような観点では、何らかの印刷物を利用して、予約操作および来店確認操作を行うことも可能である。
たとえば、タイトルを示す文字列(識別情報I)が印刷された雑誌(情報記録媒体M)を手にしたユーザUは、予約用ユニット100に組み込まれたOCR装置によって当該文字列(識別情報I)を読み取らせることにより予約操作を行うことができ、店舗用ユニット200に組み込まれたOCR装置によって当該文字列(識別情報I)を読み取らせることにより来店確認操作を行うことができる。
結局、ICカード用リーダライタ装置、ICタグ用読取装置、磁気カード用読取装置、バーコード読取装置、QRコード(登録商標)読取装置、もしくはOCR装置を備え、これらの各装置によって情報記録媒体Mに記録されている識別情報Iを読み出す機能をもった装置であれば、予約用ユニットや店舗用ユニットとして利用することができることになる。
図4(b) に示す予約用ユニット100Bは、多様な情報記録媒体Mに対応した予約用ユニットの一例である。具体的には、表示画面101Bに示されているとおり、ICカード、ICタグ、QRコード(登録商標)、磁気カード、バーコード、文字コードといった6種類のバリエーションに対応している。そのため、表示画面101Bの下方には、3種類の情報読取部103B,104B,105Bが設けられている。
ここで、情報読取部103Bは、ICカードおよびICタグから近距離無線通信を利用して識別情報Iを読み出すために利用され、情報読取部104Bは、挿入された磁気カードから識別情報Iを読み出すために利用される。一方、情報読取部105Bは、カメラとその撮影画像を解析する手段(QRコード(登録商標)認識手段・バーコード認識手段・OCR装置)によって構成され、QRコード(登録商標)、バーコード、文字コードが表示された媒体から、それぞれQRコード(登録商標)、バーコード、文字コードで表現された識別情報Iを読み出すために利用される。
予約操作を行うオペレータは、まず、図4(b) に示す画面上に表示された6種類の媒体の中から、予約操作に用いる媒体の種類を1つ選択する。たとえば、オペレータが、「磁気カード」をタップすると、画面は図4(c) に示すように切り替わり、情報読取部104Bに磁気カードを挿入するように促すメッセージが表示される。オペレータが磁気カードを情報読取部104Bに挿入すれば、磁気カード(情報記録媒体M)に記録されていた固有のID番号(識別情報I)が読み取られることになる。
一方、図4(d) に示す店舗用ユニット200Bは、予約用ユニット100Bと同様に、6種類の媒体に対応した店舗用ユニットである。具体的には、表示画面201Bに示されているとおり、ICカード、ICタグ、QRコード(登録商標)、磁気カード、バーコード、文字コードといった6種類のバリエーションに対応している。そのため、表示画面201Bの下方には、3種類の情報読取部203B,204B,205Bが設けられている。これら情報読取部203B,204B,205Bの機能は、図4(b) に示す情報読取部103B,104B,105Bの機能と全く同じである。
このように、図4(b) に示す予約用ユニット100Bおよび図4(d) に示す店舗用ユニット200Bを備えた店舗予約システムを用いれば、ユーザUが利用する情報記録媒体Mを、ICカード、ICタグ、QRコード(登録商標)、磁気カード、バーコード、文字コードという6種類のバリエーションに拡張することができ、使い勝手を向上させることができる。実際、ユーザUは、上述した例のように、板チョコや雑誌といった商品まで、情報記録媒体Mとして利用することができるので、きわめて広範囲な物品を用いて予約操作や来店確認操作を行うことができる。
しかも、ここで重要な点は、情報記録媒体Mから読み出される識別情報Iには、ユーザUの個人情報が含まれている必要がない点である。たとえば、情報記録媒体Mとして交通系ICカードを用いた場合、読み出される識別情報Iは当該ICカードに固有のID番号であるから、この識別情報Iによって1枚の交通系ICカードが特定されることになるが、当該交通系ICカードを所持しているユーザUについての住所、氏名、電話番号、メールアドレスといった個人情報が特定されるわけでない。仮に、免許証や社員証として用いられるICカードを情報記録媒体Mとして利用する場合であっても、識別情報Iとして当該ICカードに固有のID番号を読み出すようにすれば、やはり識別情報Iに個人情報は含まれていない。もちろん、板チョコや雑誌といった物品に個人情報が含まれていないのは明らかである。
したがって、万一、管理サーバ300や店舗用ユニット200から識別情報Iが漏洩したとしても、ユーザ個人を特定する情報ではないため、個人情報漏洩の危険性は回避される。要するに、本発明に係る店舗予約システムでは、ユーザ自身の個人情報の代わりに、任意の情報記録媒体に記録されている任意の識別情報を、事前予約者を特定する情報として利用して予約を行うことができるため、個人情報漏洩の危険性を回避しつつ、来店前の事前予約を行うことができる。
なお、一般に、ICカードやICタグに記録されているID番号は、ユニークな番号であるので、情報記録媒体MとしてICカードやICタグを用いる限り、異なるユーザUの予約操作によって、同一の識別情報Iが重複して予約テーブルに格納されることはない。しかしながら、情報記録媒体Mとして、たとえば、板チョコといった物品を用いた場合、同一の商品コード(バーコード)が付された物品が複数存在するため、異なるユーザUの予約操作によって、同一の識別情報Iが重複して予約テーブルに格納される可能性がある。
しかしながら、実用上、このように同一の識別情報Iが重複登録されるケースは稀であり、仮に、予約テーブルに同一の識別情報Iが重複登録されたとしても、重大な問題にはならない。たとえば、ユーザ甲と乙が、同じ板チョコを使って予約操作を行ったとすると、予約テーブルには、予約受付時刻が異なる2つの同一識別情報Iが重複して登録されることになるが、来店確認操作を行えば、甲乙いずれも予約確認がなされることになる。
なお、実際には、店舗用ユニット200が、来店確認操作に基づく照合処理によって予約が確認された識別情報Iについては、予約テーブルから削除するか、もしくは予約テーブルに照合済情報を書き込み、次回からは、照合の対象から除外する処理を行うようにするのが好ましい。そうすれば、1回の予約操作によって予約テーブルに登録された識別情報は、1回の来店確認操作による照合にのみ利用されることになり、より正確な照合動作が期待できる。
上述した重複登録例の場合、甲の来店確認操作によって甲の予約が確認されたときに一方の識別情報が削除され(もしくは照合済となり)、乙の来店確認操作によって乙の予約が確認されたときにもう一方の識別情報も削除される(もしくは照合済となる)。したがって、予約操作によって登録された識別情報と、来店確認操作によって照合された識別情報との間には、常に、1対1の対応関係が維持されることになる。
もちろん、場合によっては、甲の来店確認操作によって照合された識別情報が、実は乙の予約操作で登録されたものであり、乙の来店確認操作によって照合された識別情報が、実は甲の予約操作で登録されたものであった、という取り違えが生じる可能性がある。このような取り違えの発生は、本発明が、甲や乙といった個人を特定する情報を取り扱わない仕組を採用しており、予約テーブルに登録された個々の識別情報Iから個人を特定することができない以上、やむを得ないことである。しかしながら、そのような取り違えが発生しても、事実上の問題は、甲と乙の予約受付時刻が取り違えられるだけであり、実用上、重大な支障が生じることはない。
このような観点から、本発明に用いる情報記録媒体Mに記録されている識別情報Iは、必ずしもユニークなものである必要はなく、複数の情報記録媒体Mに重複して同一の識別情報Iが記録されていても、本発明の実施に関して重大な支障は生じない。もちろん、上記取り違えの発生を防止する上では、ユニークな識別情報Iが記録された情報記録媒体Mを用いるのが好ましい。
前述したように、実用上、店舗用ユニット200は、管理サーバ300から転送されてきた識別情報Iを、予約受付時刻を示す情報とともに予約テーブルに格納するのが好ましい。そうすれば、必要に応じて、この予約受付時刻を参考にして、来店者を案内する順序を決めることができる。もっとも、予約テーブルに格納する情報は、識別情報Iおよび予約受付時刻に限定されるものではなく、ユーザの氏名、来店予定時刻、予約人数等の予約補助情報を併せて格納するようにしてもよい。
すなわち、予約用ユニット100が、オペレータの予約操作を受けたときに、予約者の氏名、来店予定時刻もしくは予約人数を含む予約補助情報を入力し、この予約補助情報を識別情報Iとともに管理サーバ300に送信する処理を行うようにしておき、管理サーバ300が、予約用ユニット100から送信されてきた上記予約補助情報を識別情報とともに店舗用ユニット200へ転送する処理を行うようにしておけばよい。そうすれば、店舗用ユニット200は、管理サーバ300から転送されてきた予約補助情報を識別情報Iとともに予約テーブルに格納し、必要に応じて、これらの情報を提示することができる。
図5(a) 〜(c) は、このような予約補助情報の入力機能を備えた予約用ユニット100Aの表示画面101Aを示す図であり、図5(d) は、予約補助情報の表示機能を備えた店舗用ユニット200Aの表示画面201Aを示す図である。予約操作を行うオペレータ(ユーザU)は、まず、図5(a) に示す画面を利用して、氏名の入力を行う。図には「タナカ」なる文字列が入力された例が示されている。続いて、図5(b) に示す画面を利用して、来店予定時刻の入力を行う。この例の場合、30分単位で表示された時刻の中から1つを選択する入力方式が採用されている。最後に、図5(c) に示す画面を利用して、予約人数の入力を行う。この例の場合、1名〜6名の選択肢の中から1つを選択する入力方式が採用されている。
こうして、氏名、来店予定時刻、予約人数によって構成される予約補助情報を入力したら、図2(c) に示すように、情報記録媒体Mで情報読取部102Aにタッチして識別情報Iを読み取らせれば、予約操作は完了である。予約用ユニット100は、読み出した識別情報Iとともに、入力された予約補助情報を管理サーバ300に送信し、管理サーバ300は、これらを店舗用ユニット200へ転送する。
続いて、当該ユーザUが店舗Qに到着すると、前述したように、来店確認操作が行われる。ここで、照合に成功すると、予約が確認された旨の表示が行われる。図5(d) は、この予約確認表示の一例を示す図であり、予約が確認された旨のメッセージとともに、予約操作で入力した予約補助情報(氏名、来店予定時刻、予約人数)が併せて表示されている。店舗Qのスタッフは、この表示を見て、予約内容の詳細を確認することができる。
図6は、識別情報と予約受付時刻に加えて、更に、上述した予約補助情報(氏名、来店予定時刻、予約人数)を格納した予約テーブルTの一例を示す図である。店舗用ユニット200は、管理サーバ300から転送されてきた情報を、図示のような予約テーブルTの形式で格納し、必要に応じて、これらの情報を、たとえば図5(d) に示すような形式でディスプレイ画面上に表示する機能を有する。
なお、個人情報漏洩の危険性を回避する、という観点からは、氏名の入力はできるだけ避けた方が好ましい。したがって、実用上は、図6に例示するように、姓のみをカタカナで入力したり、「Mr.X」のようなニックネームで入力したりする運用を採るのが好ましい。もちろん、ここに示した予約補助情報は一例を示すものであり、予約操作を行う際には、この他にも様々な情報を予約補助情報として入力することができる。
以上、図1に示すブロック図を参照しながら、本発明の基本的実施形態に係る店舗予約システムの構成および動作を説明した。実際には、この店舗予約システムにおける予約用ユニット100および店舗用ユニット200は、コンピュータを内蔵した情報処理装置によって実現することができ、これまで述べてきた予約用ユニット100および店舗用ユニット200の処理機能は、コンピュータを内蔵した情報処理装置に専用のプログラムを組み込むことによって実現することができる。
<<< §2. 順位決定機能を有する店舗予約システム >>>
続いて、ここでは、より実用的な実施形態に係る店舗予約システムについて説明する。§1で述べたとおり、本発明に係る店舗予約システムは、個人情報漏洩の危険性を回避しつつ、来店前の事前予約を行うことを目的とするものであり、その特徴は、来店前に行う予約操作と、来店時に行う来店確認操作とで、同一の識別情報を読み取らせ、来店時にこれら識別情報の照合を行うことによって予約の確認を行うことができるようにした点にある。店舗Qのスタッフは、予約の事実確認を行った上で、来店者に接することができる。特に、予約受付時刻の確認が可能なシステムでは、予約受付時刻の先後に応じて、来店者の案内順に優先順位をつける対応が可能になる。
一般に、来店者で混雑する店舗の場合、来店時の案内順を、予約の先後に基づいて決定する運用を採るケースが少なくない。このような運用では、来店時刻に基づいて順位を決めるのではなく、予約受付時刻に基づいて順位を決めることになる。この§2では、このような現状に鑑みて、来店者についての順位(案内順)を自動的に決定する機能を有する実施形態を説明する。
<2−1.順位決定の基本方針>
ここでは、まず、この実施形態における順位決定の基本方針を、図7に示す予約テーブルT(店舗用ユニット200内に格納されるテーブル)を例にとって説明しよう。この図7に示す予約テーブルTには、登録順位、識別情報、予約受付時刻、来店時刻、優先順位の各欄が設けられている。
ここで、登録順位の欄は、説明の便宜上、テーブルの上の行から下の行に向かって順番に序数を記入した欄であり、実際の予約テーブルTには必ずしも設ける必要はない。識別情報の欄および予約受付時刻の欄は、予約操作の際に記録される欄であり、管理サーバ300から転送されてきた識別情報が識別情報の欄に記録され、予約操作が行われた時刻が予約受付時刻の欄に記録される。一方、来店時刻の欄および優先順位の欄は、来店確認操作の際に記録される欄であり、来店確認操作が行われた時刻が来店時刻の欄に記録され、当該来店確認操作に基づいて決定した優先順位が優先順位の欄に記録される。
なお、図7に示す予約テーブルTには、予約補助情報(氏名、来店予定時刻、予約人数)の欄は設けられていないが、予約操作の際に予約補助情報の入力を行った場合には、図6の予約テーブルTと同様に、予約補助情報の欄も併設されることになる。
ここでは、便宜上、店舗Qが非常に込み合うレストランであり、夕方以降は常に満席状態となり、必ず事前予約を行ってから来店する必要がある店舗であるものとして、以下の説明を行うことにする。
いま、現在時刻18:15の時点で、店舗用ユニット200内に図7(a) に示すような予約テーブルTが格納されていたものとしよう。この例では、まず、時刻18:01において、第1のユーザU1から識別情報「11111」を用いた予約操作が行われ登録順位1番に登録がなされ、次に、時刻18:05において、第2のユーザU2から識別情報「22222」を用いた予約操作が行われ登録順位2番に登録がなされ、続いて、時刻18:10において、第3のユーザU3から識別情報「33333」を用いた予約操作が行われ登録順位3番に登録がなされ、最後に、時刻18:12において、第4のユーザU4から識別情報「44444」を用いた予約操作が行われ登録順位4番に登録がなされている。
この事前予約を行った4人のユーザU1〜U4は、時刻18:15の時点では、まだ誰も店舗Qに到着していない。したがって、図7(a) に示す時刻18:15の時点では、予約テーブルTの来店時刻の欄および優先順位の欄はすべて空欄になっている。一方、図7(b) は、時刻18:35の時点の予約テーブルTであり、来店時刻の欄には、ユーザU4が時刻18:16に来店し、ユーザU3が時刻18:18に来店し、ユーザU1が時刻18:32に来店したことが示されている。また、優先順位の欄には、丸数字によって、現在時刻18:35の時点における各来店者の優先順位が示されている。
上述したように、このレストランは満席状態であり、来店したユーザU1,U3,U4は、待合室で案内待ちの状態になっている。ここで、現在時刻18:35の時点で1組分の空席が生じたため、待機中の来店者を1組だけ案内できる状態になったとしよう。この場合、店舗のスタッフは、優先順位の欄に丸数字で記された順位に従って、第1順位の客、すなわち、ユーザU1を優先的に案内すればよい。更にもう1組分の空席が生じたときには、第2順位の客、すなわち、ユーザU3を案内すればよい。
図7(b) に示す予約テーブルにおいて、各ユーザの来店時刻を比較すると、ユーザU4が最も早く、ユーザU1が最も遅い。しかしながら、予約受付時刻を比較すると、ユーザU1が最も早く、ユーザU4が最も遅い。このように、優先順位は、原則として、来店順ではなく予約受付順に決定されることになる。ただ、優先順位が付与されるのは、あくまでもその時点で来店確認がなされている客、すなわち、来店時刻の欄に記入がなされている客であり、未来店の客は優先順位決定の対象から除外される。したがって、図示の例の場合、ユーザU2は優先順位決定の対象から除外されている。このような取扱いを行うのは、空席が生じたとしても、未来店者を案内することはできないためである。
続いて、図7(a) に示す時刻18:15の時点から図7(b) に示す時刻18:35の時点に至るまでの中間時点における予約テーブルTの変遷を、図8(a) 〜(c) を参照しながら説明する。上述したように、図7(a) に示す時刻18:15の時点では、いずれのユーザも来店していないが、時刻18:16になると、ユーザU4が店舗に到着し、識別情報「44444」を用いた来店確認操作が行われる。これにより、登録順位4番の識別情報「44444」が照合され、図8(a) に示すように、登録順位4番の行に来店時刻18:16が記入される。この時点で来店しているのは、ユーザU4のみであるから、優先順位の欄の登録順位4番の行に優先順位第1位(丸数字1)が記録される。なお、テーブルの右欄外の「済」マークは、登録順位4番の行が照合済であることを示すマークである。
続いて、時刻18:18になると、ユーザU3が店舗に到着し、識別情報「33333」を用いた来店確認操作が行われる。これにより、登録順位3番の識別情報「33333」が照合され、図8(b) に示すように、登録順位3番の行に来店時刻18:18が記入される。この時点で来店しているのは、ユーザU3およびU4であるから、優先順位の欄の登録順位3番,4番の行にそれぞれ優先順位第1位,第2位が記録される。登録順位3番の行にも照合済であることを示すマークが付される。
そして、時刻18:32になると、ユーザU1が店舗に到着し、識別情報「11111」を用いた来店確認操作が行われる。これにより、登録順位1番の識別情報「11111」が照合され、図8(c) に示すように、登録順位1番の行に来店時刻18:32が記入される。この時点で来店しているのは、ユーザU1,U3,U4であるから、優先順位の欄の登録順位1番,3番,4番の行にそれぞれ優先順位第1位,第2位,第3位が記録される。登録順位1番の行にも照合済であることを示すマークが付される。図7(b) に示す予約テーブルTは、このまま現在時刻18:35に至った状態を示している。もちろん、図には示されていないが、新たな予約操作があれば、登録順位5番以降の行が順次追加されてゆくことになる。
このように、予約テーブルの内容は、予約操作および来店確認操作が行われるたびに時々刻々と更新されてゆき、優先順位も更新される。店舗用ユニット200は、オペレータの指示を受けて、この予約テーブルの内容をディスプレイ画面上に表示させる機能を有しており(あるいは、テーブル表示専用のディスプレイを設けておき、当該ディスプレイ上に予約テーブルを常時表示するようにしてもよい)、店舗のスタッフは、随時、予約テーブルの内容を確認することができる。したがって、空席が生じた場合、その時点の優先順位に従って、待機状態の客を席に案内することができる。
たとえば、図8に示す例において、1組分の空席発生が、時刻18:16〜18:17の場合は、ユーザU4を席に案内することになるが、時刻18:18〜18:31の場合は、ユーザU3を席に案内することになり、時刻18:32〜の場合は、ユーザU1を席に案内することになる。なお、予約テーブルにおいて、席への案内が完了した来店者についての行のデータをオペレータの操作によって抹消するようにしておけば、優先順位の欄には、常に、待機中の来店者についての順位が表示されるようになる。
<2−2.具体的なシステム構成>
これまで、図7,図8を参照しながら、順位決定の基本方針を説明したが、続いて、図9を参照しながら、このような順位決定機能を有する店舗予約システムの構成および動作を説明する。図9に示す店舗予約システムは、図1に示す基本的実施形態と同様に、予約用ユニット100、店舗用ユニット200、管理サーバ300を備えており、これらの各構成要素の基本機能は、既に§1で述べたとおりである。
ただ、この図9に示す店舗予約システムは、任意の情報記録媒体Mに記録されている任意の識別情報Iを、顧客を特定する情報として利用した順番管理が可能になるため、個人情報漏洩の危険性を回避しつつ、上述した順位決定の基本方針に基づいて来店者の順番を管理することができる。以下、その構成および動作を詳述する。
まず、図9の上方に描かれている情報記録媒体Mは、§1で述べたとおり、携帯可能であって、何らかの識別情報Iが記録されており、当該識別情報Iを外部から読み出すことが可能な媒体であれば、どのような媒体であってもかまわない。オペレータ(ユーザUもしくは店舗のスタッフ)は、この情報記録媒体Mを用いて、予約用ユニット100に対する予約操作および店舗用ユニット200に対する来店確認操作を行うことになる。
予約用ユニット100は、オペレータの予約操作に基づいて情報記録媒体Mに記録されている識別情報Iを読み出す予約用情報読出部110と、この予約用情報読出部110が読み出した識別情報Iを管理サーバ300に送信する識別情報送信部120と、を有している。予約用情報読出部110には、利用する情報記録媒体Mの種類に応じた読出機能を設けておくようにする。たとえば、図4(b) に例示した予約用ユニット100Bの場合、ICカード、ICタグ、QRコード(登録商標)、磁気カード、バーコード、文字コードといった6種類の情報記録媒体Mから識別情報Iを読み出す機能をもった予約用情報読出部110が備わっていることになる。もちろん、図2(a) 〜(d) ,図4(b) 〜(d) ,図5(a) 〜(c) に例示するような予約操作用の画面や予約補助情報の入力用画面を表示する機能も、予約用情報読出部110に備わっている機能である。
一方、識別情報送信部120としては、たとえば、インターネットを介して管理サーバ300と交信する機能をもった通信手段を用意しておけばよい。なお、識別情報送信部120は、必要に応じて、識別情報Iに加えて、予約操作が行われた時刻を示す予約受付時刻情報や、氏名、来店予定時刻、予約人数などの予約補助情報を管理サーバ300に送信する機能を有する。
管理サーバ300は、既に述べたとおり、予約用ユニット100から送信されてきた情報を店舗用ユニット200に転送する。また、必要があれば、これら転送した情報を管理サーバ300内に保存しておく構成を採ってもかまわない。
店舗用ユニット200は、図示のとおり、来店確認用情報読出部210、予約テーブル格納部220、識別情報照合部230、優先順位決定部240を有している。
予約テーブル格納部220は、管理サーバ300から転送されてきた識別情報(およびこれに付随する情報)を時系列順に登録することにより、予約テーブルTを作成し、これを格納する構成要素であり、店舗用ユニット200内の識別情報格納場所として機能する。予約テーブルTの具体例は、図6〜図8に例示したとおりである。
ここに示す実施例の場合、予約テーブル格納部220は、管理サーバ300から転送されてきた識別情報Iを、予約操作が行われた予約受付時刻(§1で述べたように、必ずしも予約操作が行われた際に予約用ユニット100が発生した時刻を採用する必要はなく、管理サーバ300が転送時に発生した時刻、店舗用ユニット200が転送されてきた識別情報Iを受信した時刻などを予約受付時刻としてもかまわない)とともに予約テーブルに登録する。
なお、予約テーブルに対する「時系列順の登録」とは、時間軸上での先後関係が認識できる方法で複数の識別情報が登録される形態であれば、どのような登録形態を採ってもかまわない。たとえば、図7,図8には、登録順位の欄を設けた予約テーブルTの例を示したが、このような登録順位の情報がなくても、たとえば、テーブルの上の行から下の行に向かって時間の流れを定義しておけば、登録された複数の識別情報の先後関係を認識することが可能である。もちろん、識別情報とともに予約受付時刻を登録する形態を採れば、予約受付時刻によって先後関係を認識することができるので、必ずしもテーブルの各行を時間の流れに沿って定義する必要はない。
来店確認用情報読出部210は、オペレータの来店確認操作に基づいて、情報記録媒体Mに記録されている識別情報Iを読み出す構成要素であり、予約用情報読出部110と同様に、利用する情報記録媒体Mの種類に応じた読出機能を設けておくようにする。たとえば、図4(d) に例示した店舗用ユニット200Bの場合、ICカード、ICタグ、QRコード(登録商標)、磁気カード、バーコード、文字コードといった6種類の情報記録媒体Mから識別情報Iを読み出す機能をもった来店確認用情報読出部210が備わっていることになる。もちろん、図3(a) 〜(c) ,図4(d) に例示するような来店確認操作用の画面を表示する機能も、来店確認用情報読出部210に備わっている機能である。
識別情報照合部230は、オペレータの来店確認操作に基づいて、来店確認用情報読出部210が読み出した識別情報Iを予約テーブルTに登録されている未照合の識別情報と照合し、一致確認が得られた識別情報については、照合済情報を予約テーブルTに登録する機能をもった構成要素である。また、識別情報照合部230は、図3(d) ,図4(a) ,図5(d) に例示するような照合結果を示す画面を表示する機能も有している。
なお、§1で述べたとおり、照合処理によって予約が確認された識別情報については、予約テーブルから削除するか、もしくは予約テーブルに照合済情報を書き込み、次回からは、照合の対象から除外するようにすれば、1回の予約操作によって予約テーブルに登録された識別情報は、1回の来店確認操作による照合にのみ利用されることになり、より正確な照合動作が期待できる。
ここに示す実施例の場合、優先順位の決定処理を行うため、照合済みの識別情報は予約テーブルから削除せず、照合済情報を書き込んで残すようにしている。図8の各予約テーブルTの右欄外に示した「済」マークは、この照合済情報である。また、ここに示す実施例の場合、識別情報照合部230は、照合済となった個々の識別情報に対応させて、来店確認操作が行われた来店時刻を予約テーブルに登録する処理を行う。したがって、実際には、来店時刻が照合済情報として機能するので、実用上は、わざわざ「済」マークとして照合済情報を書き込む必要はない。
すなわち、予約テーブルTに登録されている識別情報に対する照合処理は、来店確認操作に基づいて実行される処理であり、当該来店確認操作が行われた時刻は、識別情報照合部230によって、来店時刻として予約テーブルTに登録される。したがって、この来店時刻を照合済情報として利用し、来店時刻が登録されている識別情報を照合済、来店時刻が登録されていない識別情報を未照合と認識することができるので、実際には、図8の各予約テーブルTの右欄外に「済」マークで示すような照合済情報の記録は不要である。識別情報照合部230が、新たな識別情報についての照合処理を行う際には、予約テーブルTにおいて、来店時刻の欄が空白となっている識別情報のみを照会対象とする処理を行えばよい。
なお、予約受付時刻から長時間が経過しているにもかかわらず、来店時刻の登録が行われていない識別情報については、予約がキャンセルされたか、あるいは、もともといたずら目的で予約が行われたものと推定される。したがって、実用上は、予約テーブル格納部220に、所定の有効期限が経過した識別情報を予約テーブルTから抹消する処理を行う機能をもたせておくのが好ましい。たとえば、有効期限を予約受付時刻から2時間に設定しておけば、図8(c) に示す予約テーブルTにおける識別情報「22222」および同じ行に登録された情報は、来店確認操作が行われない限り、時刻20:05に抹消されることになる。もちろん、有効期限としては、「本日の営業終了まで」といった期限を設定することも可能である。この場合、未照合の識別情報は、翌日の営業開始までに抹消されることになる。
優先順位決定部240は、予約テーブルTに基づいて各来店者の優先順位を決定する機能をもった構成要素であり、その基本方針は図8を参照して説明したとおりである。すなわち、優先順位決定部240は、特定時点の優先順位として、当該特定時点において予約テーブルTに照合済情報が登録されている識別情報の時系列順に基づいて各来店者の優先順位を決定する。上述したとおり、実用上は、来店時刻の欄に登録された来店時刻の情報を照合済情報として利用することができる。ここに示す実施例の場合、優先順位決定部240は、来店票発行部241と順位通知部242とを有している。以下、これら2つの構成要素の働きについて説明を行う。
本発明に係る店舗予約システムは、個人情報漏洩の危険性を回避するという目的を達成するため、事前予約を行う際に、個人情報の入力を必須条件にはしていない。このため、前述した例のように、ユーザUは、板チョコを使った予約を行うことさえ可能である。したがって、たとえば、図7(b) に示すような優先順位が決定されたとしても、順位づけは個々のユーザに対して行われるわけではなく、あくまでも予約操作に用いられた「識別情報I」に対して行われることになる。別言すれば、図7(b) に示す予約テーブルTを閲覧した店舗のスタッフは、次に案内すべき客が、「11111」なる識別情報を用いて予約操作を行った客であることを認識することは可能であるが、当該客が、待合室で待機しているどの客であるのかを直接的に認識することはできない。
来店票発行部241は、このような不都合を解消するための構成要素であり、各来店者に来店票Sを発行する機能を有する。すなわち、来店票発行部241は、来店確認操作に基づいて、来店者を相互に区別するための来店者区別情報を生成し、当該来店者区別情報が記載された来店票Sの発行を行うとともに、当該来店確認操作に基づいて照合された識別情報に対応づけて、生成した来店者区別情報を予約テーブルTに登録する処理を行う。来店者は、来店確認操作に応じて発行された来店票Sを受け取り、待合室で呼び出されるまで待機することになる。
来店者区別情報としては、来店者を相互に区別することができる情報であれば、どのような情報であってもかまわない。最も単純な来店者区別情報は、シリアル番号である。たとえば、1,2,3,…といった連続番号を順番に生成し、これらの番号が記載された来店票Sを順次発行すればよい。この場合、来店票Sは、いわゆる番号札として機能することになり、個々の来店票Sを手にした来店者は、「○番の来店票をもつ来店者」として特定されることになる。店舗のスタッフは、「○番のお客様、お席の用意ができました」等のアナウンスを行い、順番が到来した来店者を席に案内することができる。
もっとも、実用上は、来店者区別情報として、来店順のシリアル番号を用いるのは避けた方が好ましい。これは、前述したとおり、優先順位の決定が、来店順ではなく、予約順に行われるためである。来店順のシリアル番号が記載された来店票Sは、番号札としての機能をもつため、待機中の来店者は、自分が番号札の順番に従って案内されるものであろうとの期待を抱くことになる。このため、先予約、後来店の別な客が自分より先に案内されると(自分の番号札よりも後の番号が先に呼び出されると)、不快に感じる場合がある。
このような弊害を防ぐためには、来店者区別情報として、先後の順序が定義できない情報を利用するのが好ましい。たとえば、動物や植物をモチーフとしてデザインしたマークを来店者区別情報として利用し、これらのマークが記載された来店票Sを発行するようにすれば、「ライオンのお客様」、「サクラのお客様」といった案内アナウンスを行うことができるので、上述した弊害を防ぐことができる。ここでは、便宜上、トランプの札を示すマークを来店者区別情報として用いた実施例について、以下の説明を行うことにする。
図10は、図9に示す予約テーブル格納部220内に格納される予約テーブルTの変遷例を示す図である。この図10に示す予約テーブルTの内容は、図8に示す予約テーブルTの内容とほぼ同じである。ただ、図8に示す予約テーブルTにおける「優先順位」の欄が、図10に示す予約テーブルTでは「来店票」の欄に変更されており、優先順位を示す丸数字は、右欄外に記載されている(ここに示す実施例の場合、この欄外に記載されている優先順位は、実際には記録や表示の必要はない)。
来店票発行部241は、来店確認操作に応じて、来店者区別情報(トランプの札を示すマーク)をランダムに生成し、来店票S(トランプの札に類似した札)の発行を行うとともに、当該来店者区別情報を予約テーブルTの対応欄に登録する処理を行う。図10に示す予約テーブルTにおける来店票の欄に記載された「スペードのJ」,「スペードの7」等のマークは、このようにして登録された来店者区別情報を示している。動物のマークを来店者区別情報として利用した場合は、来店票の欄に「ライオン」などの絵柄が登録されることになる。もちろん、絵柄の代わりに、「ライオン」という文字列を登録するようにしてもかまわない。
続いて、この予約テーブルTの変遷を、図10(a) 〜(c) を参照しながら説明する。この例の場合も、時刻18:15の時点では、いずれのユーザも来店していないが、時刻18:16になると、ユーザU4が店舗に到着し、識別情報「44444」を用いた来店確認操作が行われる。これにより、登録順位4番の識別情報「44444」が照合され、図10(a) に示すように、登録順位4番の行に来店時刻18:16が登録される点は、既に説明したとおりである。
来店票Sを発行する実施例の場合、来店票発行部241が「スペードのJ」なる来店者区別情報を生成し、当該情報が記載された来店票Sを発行するとともに、予約テーブルTの対応欄に「スペードのJ」なる来店者区別情報を登録する。図10(a) は、このような登録が行われた時点の予約テーブルTの状態を示している。右欄外に丸数字1で示すとおり、この時点では、この「スペードのJ」なる来店票Sを所持している来店者が優先順位第1位ということになる。
続いて、時刻18:18になると、ユーザU3が店舗に到着し、識別情報「33333」を用いた来店確認操作が行われ、図10(b) に示すように、登録順位3番の行に来店時刻18:18が登録される。また、この例の場合、来店票発行部241は「スペードの7」なる来店者区別情報が記載された来店票Sを発行するとともに、予約テーブルTの対応欄に「スペードの7」なる来店者区別情報を登録する。図10(b) は、このような登録が行われた時点の予約テーブルTの状態を示している。右欄外に丸数字1,2で示すとおり、この時点では、「スペードの7」なる来店票Sを所持している来店者が優先順位第1位ということになる。
そして、時刻18:32になると、ユーザU1が店舗に到着し、識別情報「11111」を用いた来店確認操作が行われ、図10(c) に示すように、登録順位1番の行に来店時刻18:32が登録される。また、この例の場合、来店票発行部241は「スペードの10」なる来店者区別情報が記載された来店票Sを発行するとともに、予約テーブルTの対応欄に「スペードの10」なる来店者区別情報を登録する。図10(c) は、このような登録が行われた時点の予約テーブルTの状態を示している。右欄外に丸数字1,2,3で示すとおり、この時点では、「スペードの10」なる来店票Sを所持している来店者が優先順位第1位ということになる。
順位通知部242は、この来店票発行部241が発行した来店票について、優先順位を認識して通知する機能を有する。優先順位決定の基本原理は、既に§2−1で述べたとおりである。すなわち、順位通知部242は、その時点における予約テーブルTを参照して、照合済情報が登録されている識別情報(実際には、来店時刻の欄に時刻が登録されている識別情報)の時系列順に基づいて、各識別情報に対応づけられた来店者区別情報の優先順位を認識して通知することになる。
順位通知部242による順位通知の具体的な方法としては、様々な方法を採ることが可能である。たとえば、図10に例示するような予約テーブルTを画面上に表示する方法を採るのであれば、順位通知部242には、単に、予約テーブル格納部220に格納されている現時点の予約テーブルTの内容をディスプレイ画面上に表示する機能をもたせておけばよい。
図10に示す例の場合、より上方の来店票欄に登録されている来店者区別情報ほど優先順位が上であるため、右欄外に示した丸数字の情報(優先順位を示す)がなくても、予約テーブルTの内容が表示されれば、来店票についての優先順位を直ちに把握することができる。したがって、店舗のスタッフ宛に優先順位の通知を行うのであれば、順位通知部242は、現時点の予約テーブルTの内容を表示するだけで十分である。もちろん、予約テーブルTのうち、来店票の欄の来店者区別情報だけを抽出して表示するようにしてもかまわないし、その時点で最上位の来店者区別情報のみを通知するようにしてもかまわない。
空席が生じた場合、店舗のスタッフは、この予約テーブルTの来店票の欄に登録されている来店者区別情報に基づいて、優先順位の高い順に(すなわち、より上方に登録されている来店者区別情報の順に)、待機中の来店者を呼び出して席に案内すればよい。たとえば、図10(b) に示す予約テーブルTが表示されていたときに1組分の空席が生じた場合は、「スペードの7のお客様、お席にご案内致します」との呼び出しを行えばよいし、図10(c) に示す予約テーブルTが表示されていたときに1組分の空席が生じた場合は、「スペードの10のお客様、お席にご案内致します」との呼び出しを行えばよい。
なお、実際には、席への案内が完了した時点で、「案内完了」を示す情報が予約テーブルTの該当行に登録されるようにし、「案内完了」が登録された来店者区別情報が、以後、優先順位の通知対象から除外されるようにする。たとえば、図10(c) に示す例において、「スペードの10」の客の案内が完了したら、店舗のスタッフは、順位通知部242に対して、「スペードの10」について「案内完了」である旨の指示を与えるようにする。順位通知部242は、当該指示に基づいて、予約テーブルTの「スペードの10」の行に対して、「案内完了」を示す情報を登録する処理を行う。たとえば、来店票の欄の「スペードの10」なる情報を「案内完了」なる情報に書き換え、来店者区別情報としての「スペードの10」を抹消する処理を行えばよい。
もちろん、順位通知を常時行う代わりに、オペレータからの通知要求を受けたときにのみ通知を行うようにしてもかまわない。たとえば、空席が生じた場合に、店舗のスタッフが順位通知部242に対して通知要求を行うと(具体的には、たとえば、通知要求ボタンを押す操作を行えばよい)、当該通知要求を受けて、その時点で最上位の来店者区別情報だけが通知されるようにすれば、店舗のスタッフには、必要なときに(空席が生じたときに)、必要な情報(どの客を案内すべきか)のみが通知されることになるので合理的な運用が可能になる。
また、順位通知部242が、来店者に対して直接的に通知を行うような実施形態を採ることも可能である。たとえば、空席が生じた場合に、店舗のスタッフが順位通知部242に対して通知要求を行うと、順位通知部242が予約テーブルを参照して、その時点で最上位にある来店者区別情報を用いて自動的に合成音声による案内ガイドを行うようにしておけば、店舗のスタッフの肉声による呼び出し作業を軽減することができる。たとえば、図10(c) に示す予約テーブルTが表示されていたときに1組分の空席が生じ、店舗のスタッフが通知要求ボタンを押す操作を行うと、順位通知部242によって、「スペードの10のお客様、お席の用意ができました」といった合成音声による案内ガイドが流されることになる。
<2−3.店頭登録の併用>
図9を参照しながら§2−2で説明した店舗予約システムは、あくまでも事前予約を行った来店者に関しての順位決定を行うシステムである。しかしながら、一般的な店舗では、顧客は必ずしも事前予約を行ってから来店するとは限らない。実際、本発明に係る店舗予約システムを導入した場合、一部の顧客は事前予約を行ってから来店するが、残りの顧客は予約なしで直接来店する、といった形態になることが予想される。ここでは、このような形態に対応するため、予約用ユニット100を用いた予約操作により事前予約を行った顧客と、予約なしで来店した客との双方について、順位決定が可能なシステムを述べることにする。
図11は、事前予約の有無に関わらず順位決定が可能な店舗予約システムの構成を示すブロック図である。この図11に示すシステムは、図9に示すシステムに、新たな構成要素として店頭登録部250を付加したものであり、その他の構成要素の基本機能は、図9に示すシステムの対応する構成要素の機能と同じである。別言すれば、図11に示す店舗用ユニット200′は、図9に示す店舗用ユニット200に、更に、店頭登録部250を付加したものである。この店頭登録部250の付加により、予約テーブル格納部220および優先順位決定部240にも、若干の付加機能が加えられることになる。
店頭登録部250は、オペレータの店頭登録操作に基づいて、予約なしの来店者を登録するための店頭登録情報を生成する構成要素である。この店頭登録部250は、たとえば、単純な押しボタンによって、店頭登録情報(識別情報Iの代わりに予約テーブルTに登録するためのコード)を生成する装置によって実現することができる。ここでは、店頭登録部250が、「<店頭登録>」なる文字列を店頭登録情報として生成する機能を有しているものとして以下の説明を行う。生成された店頭登録情報は、予約テーブルTに識別情報Iの代わりに登録される。また、店頭登録部250は、店頭登録操作が行われた時刻を来店時刻として予約テーブルTに登録する機能も有している。
結局、この図11に示す実施形態の場合、事前予約を行った来店者(もしくは、当該来店者のために操作を行う店舗のスタッフ)は、情報記録媒体M内の識別情報Iを来店確認用情報読出部210に読み込ませることにより、店舗用ユニット200′に対する来店確認操作を行うことになり、予約なしの来店者(もしくは、当該来店者のために操作を行う店舗のスタッフ)は、店頭登録部250に設けられた押しボタンを押すことにより、店舗用ユニット200′に対する店頭登録操作を行うことになる。後述するように、いずれの場合も、来店票発行部241から来店票Sが発行されるので、来店者は、事前予約の有無にかかわらず、この来店票Sを手にして待合室で待機することになる。
§2−2で述べたとおり、予約テーブル格納部220は、管理サーバ300から転送されてきた識別情報を予約テーブルTに時系列順に登録する機能を有しているが、ここに示す実施形態の場合、予約テーブル格納部220は、店頭登録部250が生成した店頭登録情報と店頭登録操作が行われた来店時刻とを予約テーブルTに時系列順に登録する付加機能を有している。別言すれば、予約テーブル格納部220は、管理サーバ300から転送されてきた識別情報と、店頭登録部250が生成した店頭登録情報との双方を、予約テーブルTに時系列順に登録する処理を行う。上述したように、ここに示す実施例の場合、店頭登録部250は、「<店頭登録>」なる文字列を店頭登録情報として生成するので、予約テーブル格納部220は、予約なしの来店者が来店したときには、識別情報Iの代わりに、「<店頭登録>」なる文字列を登録することになる。
このような店頭登録情報が登録された予約テーブルTの一例を、図12(a) に示す。この予約テーブルTにおいて、登録順位1番,3番,4番,7番の行に登録されている識別情報「11111」,「33333」,「44444」,「77777」は、いずれもこれまで述べてきた予約操作に基づく事前予約で登録された情報であり、予約用ユニット100から送信されてきた情報である。一方、登録順位2番,5番,8番の行に登録されている「<店頭登録>」なる情報は、店頭登録操作に基づいて登録された情報であり、店頭登録部250によって生成された店頭登録情報である。
前述したとおり、予約テーブルTでは、上の行から下の行に向かって時間の流れが定義されており、登録順位1〜8は、時間の流れどおりの順序を示している。この図12(a) に示す予約テーブルTは、現在時刻18:30における内容を示すものであるが、以下、このような予約テーブルTが作成されることになった経緯を、時間軸に沿った順序で、簡単に説明しておく。
まず、時刻18:01に、管理サーバ300から識別情報「11111」が転送されてきたため、登録順位1番の行に、識別情報「11111」と予約受付時刻「18:01」とが登録される。現在時刻18:30において、当該予約操作を行ったユーザは店舗に到着していないため、登録順位1番の行の来店時刻の欄および来店票の欄は空欄のままである。
続いて、時刻18:09に、予約なしの来店者が来店し、店頭登録操作を行ったため、登録順位2番の行に、「<店頭登録>」なる文字列からなる店頭登録情報が登録され、更に、予約受付時刻「18:09」と来店時刻「18:09」とが登録される。当該来店者は、予約を行っていないが、ここに示す実施例の場合、予約受付時刻の欄に、便宜上、来店時刻を登録することにしている。別言すれば、予約なしの来店者については、来店時刻が予約受付時刻ということになり、各来店者の優先順位は、この予約受付時刻についての時系列順に従って決定される。
また、店頭登録操作があった場合、来店票発行部241による来店票発行処理が行われる。具体的には、来店票発行部241は、来店者を相互に区別するための来店者区別情報(ここに示す実施例の場合は、トランプの札を示すマーク)を生成し、当該来店者区別情報が記載された来店票Sの発行を行うとともに、当該店頭登録操作に基づいて生成された店頭登録情報(ここに示す実施例の場合は、「<店頭登録>」なる文字列)に対応づけて、生成した来店者区別情報を予約テーブルTに登録する処理を行う。図示の例の場合、「ハートの8」なる来店者区別情報が生成されたため、登録順位2番の行の来店票の欄には、「ハートの8」が登録されている。もちろん、このとき発行された来店票Sには、「ハートの8」が描かれており、時刻18:09に店頭登録操作を行った予約なしの来店者は、この「ハートの8」が描かれた来店票Sを手にして待合室で待機することになる。
続いて、時刻18:10に、管理サーバ300から識別情報「33333」が転送されてきたため、登録順位3番の行には、識別情報「33333」と予約受付時刻「18:10」とが登録される(実際には、この時点では、まだ、来店時刻の欄および来店票の欄は空欄のままである)。更に、時刻18:12に、管理サーバ300から識別情報「44444」が転送されてきたため、登録順位4番の行には、識別情報「44444」と予約受付時刻「18:12」とが登録される(実際には、この時点では、まだ、来店時刻の欄および来店票の欄は空欄のままである)。
そして、時刻18:15になると、識別情報「44444」を用いて予約操作を行った客が店舗に到着し、来店確認操作が行われる。その結果、照合に成功し、登録順位4番の行の来店時刻の欄には、「18:15」なる来店時刻が登録される。また、この来店確認操作に応じて、来店票発行部241が「スペードのJ」なる来店者区別情報を生成し、登録順位4番の行の来店票の欄に、「スペードのJ」が登録される。もちろん、このとき発行された来店票Sには、「スペードのJ」が描かれており、識別情報「44444」を用いて予約操作を行った客は、この「スペードのJ」が描かれた来店票Sを手にして待合室で待機することになる。
続いて、時刻18:17に、予約なしの来店者が来店し、店頭登録操作を行ったため、登録順位5番の行に、「<店頭登録>」なる文字列からなる店頭登録情報が登録され、更に、予約受付時刻「18:17」と来店時刻「18:17」とが登録される。そして、来店票発行部241が「ハートの3」なる来店者区別情報を生成し、登録順位5番の行の来店票の欄に、「ハートの3」が登録される。もちろん、このとき発行された来店票Sには、「ハートの3」が描かれており、時刻18:17に店頭登録操作を行った予約なしの来店者は、この「ハートの3」が描かれた来店票Sを手にして待合室で待機することになる。
そして、時刻18:18になると、識別情報「33333」を用いて予約操作を行った客が店舗に到着し、来店確認操作が行われる。その結果、照合に成功し、登録順位3番の行の来店時刻の欄には、「18:18」なる来店時刻が登録される。また、この来店確認操作に応じて、来店票発行部241が「スペードの7」なる来店者区別情報を生成し、登録順位3番の行の来店票の欄に、「スペードの7」が登録される。もちろん、このとき発行された来店票Sには、「スペードの7」が描かれており、識別情報「33333」を用いて予約操作を行った客は、この「スペードの7」が描かれた来店票Sを手にして待合室で待機することになる。
次の登録順位6番には、照合に失敗した例が示されている。たとえば、事前に予約操作を行った客が、時刻18:20に店舗に到着し、来店確認操作を行ったところ、照合失敗の結果に終わったとしよう(照合失敗の原因は、たとえば、予約操作と来店確認操作とで異なる情報記録媒体Mを用いた場合、読取時にエラーが生じた場合、所定の有効期限が経過したため識別情報が予約テーブルTから抹消された場合、など様々である)。この場合、識別情報照合部230によって、たとえば、図4(a) に示すようなエラー表示がなされることになる。
ここに示す実施例の場合、このように、識別情報照合部230が照合を行った結果、一致確認が得られなかった場合には、識別情報Iの代わりに照合失敗情報を予約テーブルTの識別情報の欄に登録し、店頭登録操作が行われたときと同等の取扱いを行うようにしている。図示の例の場合、照合失敗情報として、「<照合失敗>」なる文字列を用いている。したがって、識別情報照合部230が照合に失敗したときには、予約テーブルTの識別情報の欄に「<照合失敗>」なる文字列が登録されることになる。
このため、図12(a) に示す予約テーブルTの登録順位6番の行には、「<照合失敗>」なる文字列からなる照合失敗情報が登録され、更に、予約受付時刻「18:20」と来店時刻「18:20」とが登録されている。これらの時刻は、もともとは、情報記録媒体Mを用いて来店確認操作を行った時刻である。また、図示の例の場合、照合に失敗したことにより、来店票発行部241が「ハートのK」なる来店者区別情報を生成し、登録順位6番の行の来店票の欄に、「ハートのK」が登録される。もちろん、このとき発行された来店票Sには、「ハートのK」が描かれており、予約確認ができなかった来店者は、この「ハートのK」が描かれた来店票Sを手にして待合室で待機することになる。
続いて、時刻18:23に、管理サーバ300から識別情報「77777」が転送されてきたため、登録順位7番の行には、識別情報「77777」と予約受付時刻「18:23」とが登録される(この時点では、まだ、来店時刻の欄および来店票の欄は空欄のままである)。
そして、時刻18:29に、予約なしの来店者が来店し、店頭登録操作を行ったため、登録順位8番の行に、「<店頭登録>」なる文字列からなる店頭登録情報が登録され、更に、予約受付時刻「18:29」と来店時刻「18:29」とが登録される。そして、来店票発行部241が「ハートの5」なる来店者区別情報を生成し、登録順位8番の行の来店票の欄に、「ハートの5」が登録される。もちろん、このとき発行された来店票Sには、「ハートの5」が描かれており、時刻18:29に店頭登録操作を行った予約なしの来店者は、この「ハートの5」が描かれた来店票Sを手にして待合室で待機することになる。
かくして、現在時刻18:30には、図12(a) に示すような予約テーブルTが得られることになる。このとき、待合室には、来店票欄に記載された各トランプの札に類似した来店票Sを手にした来店者が待機していることになる。この時点での来店票Sの優先順位は、右欄外に丸数字で示す順番ということになる。したがって、時刻18:30の時点で空席が生じた場合には、この時点で優先順位第1位である「ハートの8」の来店票を所持している来店者が席に案内されることになる。
ところが、現在時刻が18:32になると、予約テーブルTは、図12(b) に示すように変遷する。すなわち、時刻18:32には、識別情報「11111」を用いて予約操作を行った客が店舗に到着し、来店確認操作が行われる。その結果、照合に成功し、登録順位1番の行の来店時刻の欄には、「18:32」なる来店時刻が登録される。また、この来店確認操作に応じて、来店票発行部241が「スペードの10」なる来店者区別情報を生成し、登録順位1番の行の来店票の欄に、「スペードの10」が登録される。もちろん、このとき発行された来店票Sには、「スペードの10」が描かれており、識別情報「11111」を用いて予約操作を行った客は、この「スペードの10」が描かれた来店票Sを手にして待合室で待機することになる。この時点での来店票Sの優先順位は、右欄外に丸数字で示す順番ということになる。したがって、時刻18:32の時点で空席が生じた場合には、この時点で優先順位第1位である「スペードの10」の来店票を所持している来店者が席に案内されることになる。
なお、ここに示す実施例の場合、事前予約を行った来店者に発行する来店票Sは「スペードの札」となるようにし、予約なしの来店者(もしくは、照合に失敗した来店者)に発行する来店票Sは「ハートの札」となるようにしている。したがって、店舗のスタッフは、所持している来店票Sに描かれたトランプの札の種類により、個々の来店者が、事前予約を行った来店者か、予約なしの来店者かを認識することができる。
もっとも、来店者の立場からは、事前予約した者もしない者も、来店時に来店票Sを受け取り、呼び出されるまで待つ、という点に変わりはない。両者の相違点は、事前予約した来店者は、情報記録媒体Mを用いた来店確認操作により来店票Sの発行を受けるのに対して、予約なしの来店者は、ボタンを押すなどの単純な店頭登録操作により来店票Sの発行を受ける、という点だけである。このように、図11に示す実施例によれば、事前予約した来店者と、予約なしで来店した客との双方について、総合的に順位決定を行うことが可能になる。
要するに、この図11に示す実施例における優先順位決定部240は、予約テーブルTに登録されている識別情報(図12に示す例の場合は「11111」などの数字列)と、店頭登録情報(図12に示す例の場合は「<店頭登録>」なる文字列)と、の双方についての時系列順(予約受付時刻の順)に従って、各来店者の優先順位を決定する処理を行うことになる。たとえば、空席が発生した時点など、ある特定時点における優先順位を決定する際には、優先順位決定部240は、当該特定時点において照合済情報が登録されている識別情報(ここに示す実施例の場合、来店時刻を照合済情報として利用しているので、来店時刻が登録されている識別情報ということになる)と、当該特定時点において登録されている店頭登録情報(図12に示す例の場合は「<店頭登録>」なる文字列)との時系列順に基づいて各来店者の優先順位を決定することになる。
実際には、図11に示すとおり、優先順位決定部240は、各来店者に来店票を発行する来店票発行部241と、発行した来店票についての優先順位を認識して通知する順位通知部242と、を有している。
ここで、来店票発行部241は、来店確認操作があったときだけでなく、店頭登録操作があったときにも、来店者を相互に区別するための来店者区別情報(上例では、トランプの札を示すマーク)を生成し、当該来店者区別情報が記載された来店票Sの発行を行うとともに、来店確認操作に基づいて照合された識別情報または店頭登録操作に基づいて生成された店頭登録情報に対応づけて、生成した来店者区別情報を予約テーブルTに登録する処理を行うことになる。
一方、順位通知部242は、照合済情報(上例では、来店時刻)が登録されている識別情報および店頭登録情報(上例では「<店頭登録>」なる文字列)の時系列順に基づいて、これらに対応づけられた来店者区別情報の優先順位を認識して通知する。具体的な通知方法は、§2−2で述べたとおりである。
なお、図12(a) ,(b) では、登録順位6番の行に、識別情報の代わりに照合失敗情報(上例では、「<照合失敗>」の文字列)を記録した例を示した。このように、来店確認操作を行ったにもかかわらず、照合失敗という結果に終わった場合には、前述したとおり、店頭登録操作が行われたものとして取り扱う運用を行えばよい。
このような運用を行う場合、識別情報照合部230には、照合を行った結果、一致確認が得られなかった場合は、照合失敗情報を生成する機能をもたせておく。また、予約テーブル格納部220には、管理サーバ300から転送されてきた識別情報と、店頭登録部250が生成した店頭登録情報とに加えて、更に識別情報照合部230が生成した照合失敗情報を予約テーブルTに時系列順に登録する機能をもたせておけばよい。
また、来店票発行部241は、来店確認操作があったときに、たとえ照合に失敗する結果に終わったとしても、来店者区別情報を生成し、当該来店者区別情報が記載された来店票の発行を行うようにする。そして、照合に失敗する結果に終わった場合には、照合失敗により登録された照合失敗情報に対応づけて、生成した来店者区別情報を予約テーブルTに登録する処理を行うようにする。
一方、順位通知部242は、たとえば、空席が発生した時点など、ある特定時点における優先順位を決定する際に、当該特定時点において照合済情報(上例では、来店時刻)が登録されている識別情報と、当該特定時点において登録されている店頭登録情報(上例では「<店頭登録>」なる文字列)と、当該特定時点において登録されている照合失敗情報(上例では「<照合失敗>」なる文字列)と、の時系列順に基づいて、これらに対応づけられた来店者区別情報の優先順位(すなわち、各来店者の優先順位)を認識し、これを通知すればよい。
<<< §3. 実用的な実施例 >>>
最後に、本発明に係る店舗予約システムを実施する上で、より実用的な工夫を、いくつかの実施例として述べておく。
<3−1.複数のユニットを用いた実施例>
図1に示す基本的実施形態や、図9および図11に示す順位決定機能を有する実施形態では、単一の予約用ユニット100と単一の店舗用ユニット200とを用いた例に基づいて本発明の説明を行ったが、実用上は、図13に示す例のように、複数の予約用ユニットと複数の店舗用ユニットとを用いた運用を行うのが好ましい。この例では、3台の予約用ユニット100−1〜100−3および4台の店舗用ユニット200−1〜200−4と、これら各ユニットと交信する機能を有する管理サーバ300と、を設けた例である。
一般論として述べれば、複数n台の予約用ユニット100−1〜100−nと、複数m店の店舗に対応する複数m台の店舗用ユニット200−1〜200−mと、を設ければよい。もちろん、必要があれば、管理サーバ300を複数台設置するようにしてもよい。
なお、複数m店の店舗に対応する店舗予約システムとして運用する場合、ユーザUが予約用ユニット100を用いて予約操作を行うときに、どの店舗についての予約であるのかを指定する必要がある。そこで、予約用ユニット100には、複数m店のうち予約対象となる特定の店舗を指定するための店舗指定情報の入力を受け付け、識別情報とともに当該店舗指定情報を管理サーバ300に送信する機能を設けておくようにすればよい。この場合、管理サーバ300は、予約用ユニットから送信されてきた識別情報を店舗指定情報で指定された店舗に対応する店舗用ユニットへ転送するようにする。
図13に示す例の場合、ユーザUは、3台の予約用ユニット100−1〜100−3のどれを用いても、4つの店舗のうちの任意の店舗の予約を行うことが可能である。たとえば、ユーザUが第2の予約用ユニット100−2を用いて、第3の店舗(店舗用ユニット200−3が設置された店舗)についての予約を行う場合は、予約用ユニット100−2に対して、予約対象となる特定の店舗が第3の店舗であることを指定するための店舗指定情報を入力し、予約操作を行えばよい。予約用ユニット100−2は、読み出した識別情報とともに、第3の店舗を指定する店舗指定情報を管理サーバ300に送信する。管理サーバ300は、店舗指定情報を参照して、当該識別情報を第3の店舗に設置された店舗用ユニット200−3へ転送する処理を行うことになる。識別情報の転送を受けた店舗用ユニット200−3における処理は、これまで述べた実施例のとおりである。
実用上は、管理サーバ300に、各予約用ユニット100−1〜100−3に対して店舗リストを送信する機能をもたせておき、各予約用ユニット100−1〜100−3には、この店舗リストに掲載されている店舗の中から特定の店舗を指定する入力を受け付ける機能をもたせておくのが好ましい。管理サーバ300には、予め、現時点で設置されている店舗用ユニットに応じた店舗リストを用意しておくようにし、新たな店舗のために店舗用ユニットが増設された場合には、店舗リストを更新し、更新後の店舗リストを各予約用ユニットに送信すればよい。
図14は、店舗指定情報の入力を受け付ける機能をもった予約用ユニット100Cによる予約操作の画面表示例を示す図である。図14(a) に示す表示画面101Cは、予約操作の初期画面であり、ユーザUが「リストを入手」のボタンをタップすると、管理サーバ300から最新のリストがダウンロードされ、表示画面101Cは、図14(b) に示すような店舗リストの表示に切り替わる。
図示の例の場合、店舗リストには、レストランA〜Dの4店舗が表示されているが、これらの店舗には、それぞれ図13に示す店舗用ユニット200−1〜200−4が設置されている。ユーザUが、「イタリアンレストランC」のボタンをタップすると、「イタリアンレストランC」を指定する店舗指定情報の入力が行われることになり、読み出された識別情報は、管理サーバ300を介して、第3の店舗用ユニット200−3(「イタリアンレストランC」に設置されたユニット)へと転送される。このように、ユーザUは店舗リストに収録された任意の店舗についての事前予約を行うことができる。
なお、管理サーバ300から店舗リストを送信する際には、送信宛となる予約用ユニットの位置に適した店舗が掲載された店舗リストもしくは位置に適した順序で店舗が掲載された店舗リストを送信するようにするのが好ましい。たとえば、予約用ユニット100−1から管理サーバ300に対して店舗リストの送信要求があった場合には、予約用ユニット100−1の設置場所から半径5km以内の店舗についての店舗リストを送信するか、予約用ユニット100−1の設置場所から近い順に並べられた店舗リストを送信する処理が行われる。
なお、本願では便宜上、「店舗」という文言を用いているが、本願にいう「店舗」とは、様々な物品や役務の提供を行う施設を意味するものであり、飲食店、宿泊施設、遊戯施設、運動施設、銀行、証券会社、旅行社、美容院、図書館はもとより、各種病院や官公庁の施設まで広く含むものである。
また、このような様々な店舗では、当該店舗固有の情報記録媒体を発行していることが少なくない。たとえば、運動施設であれば会員カード、病院であれば診察カードなどの発行を行っていることが多い。そして、これらの店舗では、来店時に当該情報記録媒体を用いて受付を行うケースも少なくない。このようなケースでは、当該店舗に対する事前予約を行う際に、当該店舗が発行した情報記録媒体を用いて予約操作を行うようにすると、来店時に受付操作と来店確認操作とを一括して行うことができるようになるので便利である。
たとえば、来院時に診察カードを読取装置に挿入して来院受付を行うシステムが導入されている病院について予約操作を行う場合、当該診察カードを情報記録媒体Mとして用いて本発明に係る予約操作を行えば、来院時に診察カードを読取装置に挿入して行う来院受付操作と本発明に係る来店確認操作とを兼ねさせることが可能である。もちろん、この場合、来院受付を行う既存システムに、本発明に係る店舗用ユニットを組み込むような工夫が必要になるが、来院者にとっては、来院受付操作を行うだけで済むので手間が省けて便利である。
なお、複数の店舗についての予約が可能なシステムとして本発明を実施した場合、個々のユーザUは、予約対象となる店舗ごとに、それぞれ予約操作に用いる情報記録媒体Mを使い分けることにより、個人情報漏洩に対する安全性を更に高めることが可能である。たとえば、病院や銀行といった、ある程度信頼のおける店舗についての予約操作を行う際には、診察カードや運転免許証を情報記録媒体Mとして利用するが、遊戯施設についての予約操作を行う際には、バーコードが記録された板チョコを情報記録媒体Mとして利用する、といった使い分けを行うことにより、安全性を更に高めることが可能になる。
<3−2.携帯可能な予約用ユニット用いた実施例>
これまで、予約用ユニット100の一例として、「キオスク端末」として駅構内に設置されたユニットを用いる例を述べたが、本発明に用いる予約用ユニットは、必ずしも定位置に設置された装置である必要はなく、たとえば、スマートフォンのような携帯可能な装置であってもかまわない。スマートフォンには、アプリケーションプログラムをインストールすることにより、様々な機能を追加することができる。したがって、スマートフォンに、予約用ユニットとしての機能を追加する専用のアプリケーションプログラムをインストールことにより、スマートフォンを予約用ユニットとして利用することが可能になる。
もちろん、通信機能をもったタブレット型端末や、ノート型パソコンなども、携帯可能な予約用ユニットとして利用可能であるが、ここでは説明の便宜上、通信機能をもった携帯可能端末の代表例としてのスマートフォンを、予約用ユニットとして利用した場合の例について説明を行うことにする。
スマートフォンを予約用ユニットとして利用した場合、図2(a) 〜(d) に示す表示画面101Aは、スマートフォンのディスプレイ画面に表示されることになる。予約用ユニットには、情報記録媒体Mに記録されている識別情報Iを読み出す機能が必要であるが、一般的なスマートフォンには、様々な情報読出機能が備わっているので、これらの情報読出機能を利用して、情報記録媒体Mから識別情報Iを読み出すようにすればよい。
たとえば、最近のスマートフォンには、NFC規格の近距離無線通信機能が備わっているので、ICカード用リーダライタ装置として機能させることができ、近接させたICカードから識別情報Iを読み出すことが可能である。また、スマートフォンには、Webアクセス機能も備わっているので、読み出した識別情報Iを管理サーバ300に送信することも可能である。また、一般的なスマートフォンには、カメラが内蔵されているので、バーコード読取装置やQRコード(登録商標)読取装置として機能させることもでき、専用のアプリケーションプログラムを組み込めば、OCR装置として機能させることもできるので、様々な形態の情報記録媒体Mから識別情報Iを読み出すことが可能である。
このように、予約用ユニット100を、通信機能を有する携帯可能な情報処理装置によって構成すれば、オペレータの予約操作に基づいて、情報記録媒体Mに記録されている識別情報Iを読み出し、読み出した識別情報Iを当該通信機能を用いて管理サーバ300に送信することができるので、ユーザUは、どこでも手軽に予約操作を行うことができる。たとえば、電車に乗車して移動中であっても、交通系ICカードを情報記録媒体Mとして用いて、スマートフォンからなる予約用ユニット100に識別情報Iを読み出させて管理サーバ300に送信すれば、予約操作は完了する。その後、店舗に到着したら、今度は当該交通系ICカードを店舗用ユニット200に読み取らせて、来店確認操作を行えばよい。
また、スマートフォンをはじめとする携帯可能端末には、GPS情報、Wi−Fi情報、交信中の基地局情報などに基づいて、自分自身の現在位置を認識する機能が備わっている。このように、自分自身の現在位置を認識可能な携帯可能装置を予約用ユニット100として用いた場合は、現在位置に適した店舗リストを表示させることも可能である。具体的には、予約用ユニット100に、自分自身の現在位置を認識して管理サーバ300に報告する位置報告機能を付加しておき、管理サーバ300が、当該予約用ユニット100に対して、報告された現在位置に適した店舗が掲載された店舗リストを送信するようにすればよい。
具体的には、管理サーバ300内に、店舗の位置情報も含めた店舗リストを用意しておくようにし、特定の予約用ユニット100から位置報告があった場合、たとえば、当該位置から半径5km以内に存在する店舗のみを抽出した店舗リストを送信すればよい。あるいは、報告された現在位置に適した順序(たとえば、現在位置に近い順)で店舗が掲載された店舗リストを送信するようにしてもよい。
予約用ユニット100から管理サーバ300への位置報告を、所定時間間隔で周期的に行うようにすれば、管理サーバ300は、当該予約用ユニット100の移動速度や移動方向を認識することもできるので、これらの情報を参照して、より適切な店舗が形成された店舗リストを送信することも可能である。たとえば、位置と移動速度に基づいて、予約用ユニット100を所持しているユーザUが特定の電車に乗車していると判断できる場合には、当該電車の路線に沿った店舗を抽出した店舗リストを送信すればよい。また、移動速度に基づいて、徒歩で移動していると判断できる場合には、現在位置から半径5km以内に存在する店舗のみを抽出した店舗リストを送信し、自動車で移動していると判断できる場合には、現在位置から半径10km以内に存在する店舗のみを抽出した店舗リストを送信する、といった運用も可能である。
図14には、ユーザUが「リストを入手」のボタンをタップすると、管理サーバ300から店舗リストがダウンロードされ、当該店舗リストが表示画面101Cに表示される例を示したが、上記位置報告機能を利用した実施例を採用した場合、管理サーバ300からダウンロードされる店舗リストの内容は、予約用ユニット100の現在位置に応じて変化することになる。なお、ここで行う店舗リストのダウンロードは、あくまでもユーザUの操作に基づいて行われる、いわゆる「プル型」の情報取得形態であり、管理サーバ300側から一方的に店舗リストを配信する、いわゆる「プッシュ型」の情報形態ではない。したがって、ユーザUのメールアドレスなどの個人情報を伝える必要はなく、情報漏洩に対する安全性は確保される。
また、管理サーバ300が把握した予約用ユニット100の現在位置や移動速度などの情報を、当該予約用ユニット100が読み出した識別情報Iとともに店舗用ユニット200に報告するようにすれば、店舗用ユニット200では、報告された情報に基づいて、当該識別情報Iを予約テーブルTから抹消する等の処理を行うことも可能である。たとえば、報告された現在位置が店舗から極めて離れており、報告された移動速度では来店時刻が極めて遅くなると判断できる場合には、当該識別情報Iを予約テーブルTから抹消し、予約をキャンセルする措置をとることもできる。
<3−3.予約用ユニットを用いて来店確認操作を行う実施例>
これまで述べてきた実施例では、予約操作では、予約用ユニット100が情報記録媒体Mから識別情報Iを読み出し、来店確認操作では、店舗用ユニット200が情報記録媒体Mから識別情報Iを読み出す、という手順をとっていたが、§3−2で述べたように、携帯可能な予約用ユニット用いた実施例の場合、予約用ユニットを用いて来店確認操作を行うことも可能である。ここでは、そのような実施例を図15を参照しながら説明する。
図15に示す店舗予約システムにおいて、予約用ユニット100Dはスマートフォンを利用して構成された装置(スマートフォンに専用のアプリケーションプログラムを組み込んだ装置)である。なお、ここでは、このスマートフォン100Dには、通信者特定情報記録媒体MC(いわゆる、SIMカード)が装着されているものとする。また、ここでは、スマートフォン100Dには、当該スマートフォンを特定するための装置特定情報Dが記録されており(たとえば、IMEI(International Mobile Equipment Identifier))、SIMカードMCには、通信者特定情報C(ICCID(IC Card IDentifier))が記録されているものとする。
図15の上方に示された情報記録媒体Mは、これまで述べてきたように、何らかの識別情報Iが記録された携帯可能な媒体であれば、どのような媒体であってもかまわない。ここでは、説明の便宜上、交通系ICカードを情報記録媒体Mとして用いた場合を述べることにする。
さて、ユーザUは、まず、スマートフォン100Dと交通系ICカードMとを用いて予約操作を行う。具体的には、スマートフォン100Dに組み込まれた専用のアプリケーションを起動させて、当該スマートフォン100Dを予約用ユニット100Dとして機能させ、予約操作を行う旨の指示を与える。すると、当該アプリケーションの機能により、NFC規格の近距離無線通信を利用して交通系ICカードMから識別情報Iを読み出し、これを電話回線やWi−Fi等を利用したWebアクセス機能を用いて管理サーバ300に送信する処理が実行される。このような予約操作は、基本的に、これまで述べてきた実施例における予約操作と変わりはない。当該予約操作で管理サーバ300に送信された識別情報Iは、店舗用ユニット200Dに転送される。
これに対して、来店確認操作は、これまで述べてきた実施例とは若干異なる。これまで述べてきた実施例の来店確認操作では、店舗用ユニット200Dが、交通系ICカードMから直接的に識別情報Iを読み出す処理を行うことになるが、ここに示す実施例の場合、店舗用ユニット200Dは、交通系ICカードMに記録されている識別情報Iを、スマートフォン100Dを介して間接的に読み出すことになる。
すなわち、店舗に到着したユーザUは、スマートフォン100Dに組み込まれた専用のアプリケーションを起動させて、当該スマートフォン100Dを予約用ユニット100Dとして機能させ、来店確認操作を行う旨の指示を与える。すると、当該アプリケーションの機能により、NFC規格の近距離無線通信を利用して交通系ICカードMから識別情報Iを読み出す処理が実行される。
ただ、今回は来店確認操作を行う旨の指示を与えているため、ユーザUに対して、たとえば「スマートフォンを店舗用ユニットにタッチさせて下さい」のようなメッセージが提示される。ユーザUが、メッセージに従ってスマートフォン100Dを店舗用ユニット200Dにタッチさせると、両者間でNFC規格の近距離無線通信が行われ、スマートフォン100Dが読み出した識別情報Iが店舗用ユニット200Dに送信される。その後の処理は、これまで述べてきた実施例と全く同様である。
なお、予約操作時に読み出した識別情報Iをスマートフォン100D内に一時格納しておき、来店確認操作時に一時格納されていた識別情報Iを利用できるようにしておけば、来店確認操作時に改めて識別情報Iを読み出す処理は不要になる。この場合、店舗に到着したユーザUは、専用のアプリケーションを起動させて、そのままスマートフォン100Dを店舗用ユニットにタッチさせればよい。
結局、この図15に示す実施例の場合、スマートフォン100D(予約用ユニット)は、オペレータの来店確認操作に基づいて、交通系ICカード(情報記録媒体M)から読み出した識別情報Iを通信機能を用いて店舗用ユニット200Dに送信する機能を有しており、店舗用ユニット200Dは、予約操作が行われたときには、識別情報Iを管理サーバ300を介して受信し、来店確認操作が行われたときには、識別情報Iをスマートフォン100D(予約用ユニット)を介して受信することになる。すなわち、店舗用ユニット200Dは、来店確認操作時に、交通系ICカードMに記録されている識別情報Iを、スマートフォン100Dを介して間接的に読み出したことになる。
この図15に示す実施例の特徴は、予約用ユニット100Dが、通信者を特定するための通信者特定情報Cが記録された通信者特定情報記録媒体MCを装着しており、2通りの通信手段を用いた通信機能を有している点である。ここで、第1の通信手段を用いた通信は、通信者特定情報Cに基づいて通信者を特定することを条件として実行される通信であり、上例の場合、SIMカードMCを利用した通信ということになる。一方、第2の通信手段を用いた通信は、通信者特定情報Cに基づいて通信者を特定することを条件とせずに実行される通信であり、上例の場合、NFC規格の近距離無線通信ということになる。
そして、予約用ユニット100Dは、予約操作が行われたときには、情報記録媒体Mから読み出した識別情報Iを第1の通信手段を用いて管理サーバ300に送信する。図において、予約用ユニット100Dから管理サーバ300に向かう実線の矢印は、この第1の通信手段(たとえば、電話回線を利用した通信)を用いた識別情報Iの送信を示している。一方、予約用ユニット100Dは、来店確認操作が行われたときには、読み出した識別情報Iを第2の通信手段を用いて店舗用ユニット200Dに送信する。図において、予約用ユニット100Dから店舗用ユニット200Dに向かう一点鎖線の矢印は、この第2の通信手段(たとえば、NFC規格の近距離無線通信)を用いた識別情報Iの送信を示している。
もちろん、この図15に示す実施例は、予約用ユニット100Dが携帯可能な装置であるという前提で利用可能な実施例であり、予約用ユニットが「キオスク端末」のような定位置に設置されるタイプの装置である場合には利用できない。図15に示す実施例の利点は、ユーザUが、予約操作と来店確認操作との双方を、予約用ユニット100Dの機能(スマートフォンにインストールされた専用のアプリケーションの機能)を利用して行うことができる点である。
なお、図15に示されているとおり、スマートフォン100Dには、通信者特定情報記録媒体MC(SIMカード)が装着されているので、このSIMカードを情報記録媒体Mとして利用することも可能である。すなわち、SIMカードMCには、通信者特定情報Cが記録されているので、本発明に利用可能な情報記録媒体Mとしての条件を備えている。したがって、予約用ユニット(スマートフォン100D)が、通信者特定情報記録媒体MCに記録されている通信者特定情報Cを、情報記録媒体Mに記録されている識別情報Iとして読み出すようにすれば(専用のアプリケーションをそのようにプログラムしておけば)、図15の上方に示された情報記録媒体Mは不要になる。
別言すれば、ユーザUは、SIMカードMCが装着されたスマートフォン100Dだけを使って、予約操作と来店確認操作とを行うことができる。もちろん、通信者特定情報Cは、ユーザUを特定することが可能な情報であるが、氏名、住所、電話番号、メールアドレスといった個人情報と比べて、ユーザUを直接的に特定する情報ではないので、万一、漏洩したとしても、氏名、住所、電話番号、メールアドレスといった個人情報が漏洩した場合に比べれば、危険性は低いことになる。
この図15に示す実施例のもう1つの利点は、予約操作および来店確認操作に用いる識別情報Iに加工を施すことが可能になる点である。具体的には、予約用ユニット100Dに、情報記録媒体Mから読み出した識別情報I(SIMカードMCから読み出した通信者特定情報Cも含む)に対して所定の規則に基づく加工を施すことにより、新たな識別情報I′を生成する機能をもたせておくようにすれば、予約操作が行われたときには、当該新たな識別情報I′を管理サーバ300に送信し、来店確認操作が行われたときには、当該新たな識別情報I′を店舗用ユニット200Dに送信することができる。
このような実施形態をとれば、管理サーバ300や店舗用ユニット200Dには、情報記録媒体Mから読み出した識別情報I自体を送信せずに、これに加工を施すことにより得られた識別情報I′を送信することになるので、万一、識別情報I′について情報漏洩が生じたとしても、重大な情報漏洩にはならない。また、このような加工は、板チョコのバーコードのようなありふれた識別情報Iが読み出された場合でも、加工後に得られる新たな識別情報I′は、ありふれた情報ではなくなるので、異なるユーザが同一の板チョコを用いて予約操作を行ったとしても、重複予約がなされる事態を回避することができる。
識別情報Iに対する加工としては、予約用ユニット100Dに格納されている固有の装置特定情報Dを利用することができる。たとえば、予約用ユニット100Dは、少なくとも、情報記録媒体Mから読み出した識別情報Iと、自分自身に格納されている装置特定情報Dと、を用いた合成処理を行うことにより新たな識別情報を生成することができる。具体的には、識別情報Iと装置特定情報Dとを単に連結する合成を行って新たな識別情報I′を生成してもよいし、両者の和をとったり、両者について論理演算を施したり、それらにハッシュ関数を作用させたり、といった合成処理により新たな識別情報I′を生成してもよい。あるいは、更に、その日の日付のデータを合成するようなことも可能である。
<3−4.予約用ユニットと店舗用ユニットとの双方で識別情報に加工を施す実施例>
上述したように、情報記録媒体Mから読み出した識別情報I自体を店舗用ユニットに送信せずに、これに加工を施すことにより得られた新たな識別情報I′を送信するようにすると、情報漏洩時の危険性を低減する効果が得られる。図15に示す実施例のように、同一の予約用ユニット100Dを用いて予約操作と来店確認操作との双方を行う場合は、予約操作と来店確認操作とにおいて、共通の加工処理が行われるため、同一の識別情報I′に対する照合が行われることになり、照合処理に何ら支障は生じない。
もっとも、識別情報Iに加工を施す実施例は、たとえば、予約用ユニットが「キオスク端末」のような定位置に設置されるタイプの装置である場合にも適用可能である。この場合は、予約用ユニットと店舗用ユニットとの双方で、同一の規則に基づく加工を行うようにすればよい。
すなわち、予約用ユニット100には、情報記録媒体Mから読み出した識別情報Iに所定の規則に基づく加工を施すことにより新たな識別情報I′を生成する機能をもたせておき、予約操作が行われたときには、この新たな識別情報I′を管理サーバ300に送信するようにする。管理サーバ300は、予約用ユニット100から送信されてきた新たな識別情報I′を店舗用ユニット200へ転送することになるので、予約テーブルTには、この識別情報I′が登録されることになる。
一方、店舗用ユニット200も、情報記録媒体Mから読み出した識別情報Iに所定の規則に基づく加工を施すことにより新たな識別情報I′を生成する機能をもたせておく。しかも、予約用ユニット100側で行われる加工の規則と、店舗用ユニット200側で行われる加工の規則とが共通になるようにする。そして、来店確認操作が行われたときには、店舗用ユニット200で生成した新たな識別情報I′と管理サーバ300から転送されてきた新たな識別情報I′(予約テーブルTに登録されていた識別情報I′)とを照合する処理を行えばよい。
たとえば、共通の加工規則として、「識別情報I」+「日付を示すデータ」に所定のHASH関数を作用して得られるHASH値を新たな識別情報I′とする、という規則を設定しておき、予約用ユニット100と店舗用ユニット200との双方で、当該共通規則に基づく加工を行うようにすれば、まず、予約操作を行うと、予約用ユニット100により上記HASH値I′が生成される。当該HASH値I′は管理サーバ300経由で店舗用ユニット200へ転送され、予約テーブルTに登録される。続いて、来店確認操作を行えば、今度は店舗用ユニット200により上記HASH値I′が生成され、予約テーブルTに登録されていたHASH値I′と照合されることになる。
この場合、予約操作と来店確認操作とが同日中に実行されれば、双方で生成されたHASH値I′は同一のものになるため、照合に成功することになる。もちろん、来店確認操作が翌日に行われた場合は、照合失敗となるが、当日の予約のみを受け付けるという前提のシステムであれば、むしろこのような運用形態は好ましい形態ということになる。HASH値I′は、情報記録媒体Mに記録されていたもとの識別情報Iとはかけ離れたものになるので、万一、情報漏洩が生じたとしても、実害はほどんど生じないことになる。
なお、予約操作が行われたときの加工を、予約用ユニット100で行う代わりに管理サーバ300で行うことも可能である。この場合、管理サーバ300に、予約用ユニット100から送信されてきた識別情報Iに所定の規則に基づく加工を施すことにより新たな識別情報I′を生成する機能をもたせておき、生成した新たな識別情報が店舗用ユニット200へ転送されるようにすればよい。一方、店舗用ユニット200では、来店確認操作に基づいて情報記録媒体Mから読み出した識別情報Iに対して、上記規則と同じ規則に基づく加工を施すことにより、新たな識別情報I′を生成し、生成した新たな識別情報I′と管理サーバ300から転送されてきた新たな識別情報I′とを照合する処理を行えばよい。
<3−5.待ち状態を表示する実施例>
これまで述べた実施例では、ユーザUは、予約用ユニット100に対して予約操作を行ってから、店舗用ユニット200に対して来店確認操作を行うまで、この店舗予約システムに対して何ら中間的な操作を行うことはなかった。ここでは、ユーザUが中間的な操作を行うことにより、来店前に待ち状態(混雑状態)に関する情報を入手できるようにする実施例を説明する。なお、この実施例では、各ユーザUが予約操作で読み出させる識別情報Iがユニークなものであることが前提となる。
ここに示す実施例の場合、中間的な操作は、これまで述べてきた予約操作と同じ内容の操作でかまわない。別言すれば、ユーザUは、同じ情報記録媒体Mを用いて、これまで述べてきた予約操作を複数回行うことになる。この場合、第1回目の予約操作は、これまで述べてきた実施例のとおりの予約操作になるが、第2回目以降の予約操作は、待ち状態の確認操作として取り扱われる。
通常、事前予約を行ったユーザUは、店舗に向かって移動中であるが、§3−2で述べたように、スマートフォンなどの携帯可能な装置を予約用ユニット100として用いることにすれば、移動中も予約用ユニット100に対する操作が可能であるので、第2回目以降の予約操作(待ち状態の確認操作)を随時行うことができる。図16(a) は、予約用ユニット100Eとして用いられているスマートフォンの表示画面101Eに、現在の待ち状態を示す情報が表示された例を示す図である。ユーザUは、第1回目の予約操作を行った後、第2回目以降の予約操作を行うたびに、図示のような現在の待ち状態を示す情報を得ることができる。
図9や図11に示す実施形態に、このような表示を行うための機能を付加するには、次のようにすればよい。まず、予約テーブル格納部220に、管理サーバ300から識別情報Iが転送されてきたときに、予約テーブルTを検索して、当該識別情報Iが既に登録されているか否かを判定する処理を行う機能を設けておく。そして、当該識別情報Iが未登録の状態であれば、これまで述べてきた実施例で説明したとおり、当該識別情報Iを用いた予約操作があったものと判断し、これを予約テーブルTに登録する処理を行うようにする。したがって、ユーザUが第1回目の予約操作を行った場合は、これまでの実施例で説明したとおり、識別情報Iを用いた事前予約が行われることになる。
一方、当該識別情報Iが既登録の状態になっていた場合には、予約テーブル格納部220は、当該識別情報Iについての予約テーブルへの重複登録を行わずに、既登録の識別情報Iの時系列順に応じた現在の待ち状態を示す情報を発生させ、この待ち状態を示す情報を管理サーバ300に返送するようにする。管理サーバ300は、この待ち状態を示す情報を予約用ユニット100に転送する。そして、予約用ユニット100には、転送されてきた待ち状態を示す情報を表示する機能をもたせておけば、ユーザUが第2回目以降の予約操作を行うたびに、表示画面101E上に図16(a) に示すような現在の待ち状態を示す情報が表示されることになる。
現在の待ち状態を示す情報として、どのような情報が表示されるかは、予約テーブル格納部220に付加された処理機能次第である。図示の例の場合、「お客様は3組目です。あと20分ほどでご案内できます。」のような情報提示が行われているが、これは、現時点の予約テーブルTの内容を所定のアルゴリズムに基づいて解析した結果である。すなわち、この例の場合、既登録の識別情報Iは優先順位第3位に登録されており、その場合の待ち時間は20分程度であるという経験から、図示のような情報提示が行われたことになる。
もちろん、第2回目以降の予約操作はすべて待ち状態の確認操作として取り扱われるので、ユーザUは、この待ち状態の確認操作を繰り返し行うことができ、常に、最新の待ち状態を確認することが可能である。なお、ここで行う待ち状態の確認操作も、あくまでもユーザUの操作に基づいて行われる、いわゆる「プル型」の情報取得形態であるため、ユーザUのメールアドレスなどの個人情報を伝える必要はない。
<3−6.クーポンを発行する実施例>
サービスの一貫として、クーポンを発行する営業促進手段は、多くの店舗が採用している常套手段である。ここでは、本発明に係る店舗予約システムに、クーポン発行機能を組み込んだ実施例を述べる。
図9や図11に示す実施形態に、このようなクーポン発行機能を付加するには、次のようにすればよい。まず、予約テーブル格納部220には、管理サーバ300から転送されてきた識別情報Iを予約テーブルTに登録する際にクーポン情報を発生させ、識別情報Iとともに当該クーポン情報を予約テーブルに登録し、このクーポン情報を管理サーバ300に返送する機能をもたせておく。
たとえば、Webページなどに「本日、事前予約された方には、10%引きクーポン進呈」のような広告を掲載した場合、その当日に管理サーバ300から識別情報Iが転送されてきたときに、「10%引き」というクーポン情報を識別情報Iとともに予約テーブルTに登録するようにする。また、当該クーポン情報を管理サーバ300に返送するようにする。
管理サーバ300は、このクーポン情報を予約用ユニット100に転送するようにし、予約用ユニット100は、転送されてきたクーポン情報を表示するようにする。図16(b) は、このようなクーポン情報の転送を受けた予約用ユニット100Fの表示画面101Fを示す図である。ユーザUは、レストランAに対する予約操作を行った結果、図示のような表示が得られるので、「10%引き」というクーポンを受け取ったことを認識できる。なお、この予約用ユニット100Fに転送されたクーポン情報自体は、「10%引き」のサービスを受けるために必要な情報ではないので、予約用ユニット100Fは、クーポン情報の表示を行った後、これを削除してしまってもかまわない。
現在、スマートフォンなどにクーポン情報を配信し、店頭にて、このクーポン情報をスマートフォンの表示画面に表示させて店舗のスタッフに見せると、クーポンに記載された恩典を受けることができる、といったサービス形態が普及しているが、ここに示す実施例によるサービス形態では、受信したクーポン情報は、削除してしまってもかまわない。これは、クーポン情報が予約テーブル格納部220内に、識別情報Iに紐付けて登録されているためである。別言すれば、この実施例の場合、クーポンに記載された恩典を受けることができる対象者は、識別情報Iとの紐付けにより特定されることになる。
この実施例の場合、クーポンに記載された恩典を来店者に与えるために、来店確認用情報読出部210には、オペレータのクーポン確認操作に基づいて情報記録媒体Mに登録されている識別情報Iを読み出す機能が設けられている。また、識別情報照合部230には、このクーポン確認操作に基づいて読み出された識別情報Iを予約テーブルTに登録されている識別情報Iと照合し、一致確認が得られた識別情報Iについて登録されているクーポン情報を提示する機能を有している。
したがって、予約操作によりクーポン情報を取得したユーザが、来店時に店舗用ユニット200に対して、情報記録媒体Mを用いたクーポン確認操作を行えば、店舗用ユニット200のディスプレイ画面上に、「10%引き」というクーポン情報が表示されることになる。店舗のスタッフは、このクーポン情報の表示を確認した上で、当該クーポンに記載された恩典を来店者に与えればよい。
図16(b) に示すクーポン情報には、「会計時にピッ!」という文言が記載されているが、これは、クーポン確認操作を会計時に行うことを意図した記載である。これまで述べてきた実施例の場合、ユーザUは、予約操作(予約でピッ!)および来店確認操作(お店でピッ!)を行うことになるが、ここに示す実施例の場合、更に会計時にクーポン確認操作(会計時にピッ!)を行うことになる。したがって、実用上は、店舗の入り口付近に、来店確認操作(お店でピッ!)を行うための来店確認用情報読出部210を設置しておくとともに、店舗の会計カウンター付近に、クーポン確認操作(会計時にピッ!)を行うための来店確認用情報読出部210を設置しておくのが好ましい。
もちろん、来店確認操作(お店でピッ!)とクーポン確認操作(会計時にピッ!)とを統合した運用を行うことも可能である。すなわち、来店確認操作が行われたときに、これまで述べた実施例における処理を実行するとともに、上述したクーポン確認操作に対する処理も併せて実行すればよい。この場合、識別情報照合部230によって、クーポン情報を提示する処理が実行されるので、店舗のスタッフは、たとえば、ディスプレイ画面上でクーポン情報を確認した上で、「10%引きクーポン(紙の印刷物)」を来店確認操作を行った来店客に手渡すことができる。来店者は、この紙のクーポンを会計時に渡して、10%引きのサービスを受けることができる。
なお、クーポン情報の提示は、必ずしもディスプレイ画面上の表示として行う必要はなく、紙面への印刷という方法で提示を行うことも可能である。この場合、来店者は、店舗のスタッフの手を煩わせることなしに、自分でクーポン確認操作を行うことによって、その場で印刷されたクーポンを手にすることができる。また、上述したように、来店確認操作とクーポン確認操作とを統合した運用を行う場合は、来店確認操作により来店票Sが発行されるので、この来店票Sに「10%引き」といったクーポン情報を印刷するようにしておけば、紙の印刷物としてのクーポンを別個に発行する必要はなくなる。来店者は、この来店票Sをクーポンとして会計時に渡すことにより、10%引きのサービスを受けることができる。
クーポン情報は、予約テーブル格納部220内に、識別情報Iに紐付けて登録されるので、複数種類のクーポン情報をそれぞれ別の顧客に発行しても問題はない。たとえば、店舗の近くに位置する予約用ユニット100からの予約操作があった場合には、「10%引き」のクーポン情報を発行するが、店舗の遠くに位置する予約用ユニット100からの予約操作があった場合には、「20%引き」のクーポン情報を発行する、といった運用も可能である。個々の顧客は識別情報Iに紐付けられており、個々のクーポン情報は識別情報Iに紐付けられているので、個々の顧客に対して、それぞれ正しいクーポンに応じたサービス提供が可能である。
また、このようなクーポン情報の紐付けは、クーポンの不正使用防止にも役立つ。たとえば、クーポン利用時に、クーポン情報をスマートフォンの画面に表示させて店舗のスタッフに提示する運用を採る場合、スタッフがクーポンを確認したという証拠がどこにも残らないので、スタッフが勝手に割引を行ってしまう可能性があるが、クーポン情報の紐付けは、そのような不正行為に対する抑止力として機能する。同様に、クーポンの使用回数や割引金額についての不正行為に対する抑止効果も得られる。
<3−7.店舗用ユニットを分散させる実施例>
これまで述べた実施例では、店舗用ユニット200を当該店舗に設定した例を示したが、店舗用ユニット200の構成要素は、そのすべてを店舗に設置する必要はない。図17は、店舗用ユニット200を分散配置した変形例に係る店舗予約システムの構成を示すブロック図である。この変形例では、店舗用ユニット200は、店舗に設置される第1の店舗用部分ユニット200αと店舗以外の場所に設置される第2の店舗用部分ユニット200βとによって構成されている。
これまで述べてきた実施例において、店舗用ユニット200を構成する構成要素の一部は、第1の店舗用部分ユニット200α内に設けられ、残りの一部は、第2の店舗用部分ユニット200β内に設けられている。ここで、第1の店舗用部分ユニット200αと第2の店舗用部分ユニット200βとは相互に交信する機能を有しているので、分散配置された構成要素は、相互に交信することができ、動作上の問題は生じない。
図17に示す例は、店舗に設置される第1の店舗用部分ユニット200α内に、来店確認用情報読出部210、識別情報照合部230、優先順位決定部240、店頭登録部250を設け、店舗以外の場所に設置される第2の店舗用部分ユニット200β内に、予約テーブル格納部220を設けた例である。予約テーブルTは、店舗外の第2の店舗用部分ユニット200βに格納されることになるので、識別情報照合部230、優先順位決定部240、店頭登録部250は、ネットワークなどを利用して予約テーブル格納部220と交信し、予約テーブルTへのアクセスを行うことになる。
このように、店舗用ユニット200を分散させる実施例は、チェーン店を展開するような事業者が本発明を実施する場合に便利である。このような事業者は、多数の店舗に関する情報を本部で一元管理した方が効率的であるので、個々の店舗には、第1の店舗用部分ユニット200αとして必要最小限の構成要素を配置し、残りの構成要素を第2の店舗用部分ユニット200βとして本部、または事業者が契約する外部のサーバ等に設置する形態を採れば、個々の店舗の予約テーブルTを本部の管理下において一元管理することができる。
もっとも、来店確認用情報読出部210における情報記録媒体Mから識別情報Iを読み出すための読出装置部分、店頭登録部250における店頭登録操作の受付部分、優先順位決定部240における来店票発行部分、各種表示を行うためのディスプレイ部分などは、個々の店舗に設置する必要があるので、第2の店舗用部分ユニット200βに設けることができる構成要素は、店舗に直接設置する必要がない部分ということになる。