WO2016035699A1 - 予約システム - Google Patents

Abstract

【課題】　スマートフォンなどの携帯端末を利用して、店舗等の予約をする際に、店舗から提供するサービス内容を動的に変更可能とする。 【解決手段】　管理サーバ１００、携帯端末２００、店舗端末３００を備える予約システムを構築する。店舗は、管理サーバ１００に割引などのサービス情報を登録し、随時、更新する。ユーザは、携帯端末２００で、適宜、管理サーバ１００からサービス情報の配信を受け、予約したい店舗を選択し、予約を行う。店舗のサービス情報は随時更新されていくが、ユーザが予約した時点で、そのユーザとの間では、割引率などのサービス内容は固定される。こうすることにより、予約完了後に割引率が下がったとしてもユーザは安心して予約した時点でのサービスを受けることができる。また、店舗側も、混雑状況などに応じてサービス情報を動的に変更することにより来客を促すことができる。

Description

予約システム

　本発明は、スマートフォン、タブレット、携帯電話などの携帯端末を利用して、店舗等の予約をするための予約システムに関する。

　スマートフォン、タブレット、携帯電話などの携帯端末は、インターネットなどのネットワークを介して種々の情報を取得するのに幅広く利用されている。こうした情報の中には、飲食店を含む店舗が発信するクーポンその他のサービス情報も含まれる。ユーザは、これらのサービス情報を表示した画面を店舗で提示等することで、割引などのサービスを受けることができる。
　かかるサービス情報の送信は、店舗にとって有用な手段ではあるが、送信してもユーザに利用されないことも多く、集客に効率的に結びつけることが課題の一つとなっている。かかる課題に対し、例えば、特許文献１は、特定地点から特定距離で受信可能なユーザ端末に対して、リアルタイム情報を含む広告情報を送信する技術を開示する。特許文献２は、加盟店のリアルタイム情報を所定距離内のユーザに対して送信し、予約を受け付ける技術を開示する。これらの技術によれば、店舗の比較的近くにいるユーザに絞ってサービス情報を送信することにより、ユーザに雑多な情報が届くのを抑制することで、送信された情報に対するユーザの注意を惹きやすくする効果がある。

特開２００２－３５１３７０号公報 特開２０１２－２３８０８７号公報

　従来のサービス情報は、その内容が比較的固定されているという課題があった。例えば、店舗の管理者が、店舗が比較的すいていると判断し、集客のために一定時間に限定したタイムセールのようなサービス情報を送信した場合、そのタイムセール中は、サービス情報は固定化され、新たなサービス情報を送信することはできない。従前のサービス情報と異なる内容で、新たなサービス情報を送信してしまうと、混乱を招くだけでなく、ユーザに対して不信感を抱かせることも生じ得るからである。しかし、店舗側としては、店舗の混雑状況等に応じて動的にサービス情報を変化させることができれば、集客力向上のために非常に有用である。
　本発明は、かかる課題に鑑み、動的にサービス情報を変化させることが可能な予約システムを提供することを目的とする。

　本発明は、
　ユーザが利用する携帯端末に対して、所定の店舗におけるサービス内容を表すサービス情報を送信し、該携帯端末からの予約を受け付ける予約システムであって、
　前記店舗からの指示によって随時変化する前記サービス情報を格納するサービス情報データベースと、
　前記サービス情報を、前記携帯端末に送信する送信制御部と、
　該携帯端末またはユーザを特定する識別情報とともに予約の申し込みを前記携帯端末から受信し、該受信後に前記サービス情報が変化した場合であっても該申し込みに基づいて特定されるサービス内容で、前記識別情報と関連づけて予約を確定する予約処理部とを備える予約システムとして構成することができる。

　携帯端末としては、スマートフォン、タブレット、携帯電話、ノートパソコンなど携帯可能でネットワークに接続可能な種々の装置が該当する。
　携帯端末と予約システムとを接続するネットワークは、インターネットのような広域のものであってもよいし、イントラネットのように限られた領域内のものであってもよい。また、ネットワークを介した通信は、無線、有線を問わない。予約システムは、ハードウェア的には、これらのネットワークに接続された管理サーバを用いて構成することができる。
　サービス情報としては、店舗で利用できる割引、見本などの提供、利用金額に応じたポイントの付与、特売品の紹介など種々の内容のものを利用可能である。サービス情報は、必ずしもユーザにとって直接または間接に利益を与えるものでなくてもよい。例えば、飲食店などの待ち時間、人気商品の入荷状況、イベント情報、店舗や商品がメディアで紹介された記事などであってもよい。また、サービス情報の態様は、動画、静止画、テキストなどいずれであってもよい。
　識別情報としては、携帯端末を特定する端末識別情報や、ユーザを特定するユーザＩＤなどとすることができる。

　本発明によれば、店舗の管理者は、店舗の混雑状況などを踏まえて随時、サービス情報を予約システムに登録することができ、ユーザは、こうして随時変化するサービス情報を受け取ることができる。そして、ユーザがこのサービス情報に対して、予約の申し込みをすると、予約システムは、そのユーザとの間では、申し込みを受けたときのサービス情報の内容に固定をする。予約の確定後にサービス情報の内容が変化しても、当該ユーザとの間では影響はない。例えば、１０％割引を内容とするサービス情報に対して予約が確定すると、その後、店舗側が割引を１５％にアップした場合でも、割引を５％にダウンした場合でも、ユーザは１０％の割引を受けることができる。
　こうすることによって、ユーザはサービス情報に基づいて自分が求めるサービスを受けることができる。また、店舗側も、一旦、サービス情報を発信した後も、随時、その内容を変化させることができ、サービス情報を、より柔軟に集客に活用することが可能となる。
　また、サービス情報が動的に変化するため、ユーザによって受けられるサービスが異なることになるが、予約は識別情報によって管理されるため、混乱を回避することができる。

　本発明において、サービス情報は、予約システムから携帯端末に自動的に配信するものとしてもよいし、携帯端末のユーザがウェブページ等を介して取得するものとしてもよい。本明細書では、「送信」という用語は、いわゆるプッシュ型の配信と、プル型の取得の双方を含む意味で用いる。
　サービス情報を配信する場合には、例えば、サービス情報の対象となる店舗から所定の範囲内にいるユーザを対象としたり、予め本システムに登録されたユーザを対象としたり、サービス情報の内容と嗜好の合うユーザを対象とするなど、配信範囲を限定してもよい。

　本発明の予約システムにおいては、
　前記予約の申し込み時に、該予約ごとに設定される個別の有効時間を経過した場合に、該予約を取り消す実績管理部を備えるものとしてもよい。

　こうすることにより、予約しながらも来店しないユーザが増加するという事態、即ち予約の濫用を抑制できる。
　本発明の予約システムでは、予約の確定状況を見ながら店舗がサービス情報を動的に変化させることが可能となる点が利点である。しかし、予約しながらも来店しないユーザが増加すると、予約の確定状況の信憑性が低くなり、こうした利点を活かすことができない。上記態様によれば、予約の濫用を抑制できるため、予約の確定状況の信憑性、ひいては予約システムの有用性を向上させることが可能となる。
　ここで、有効時間は、「タイムサービス」のように予めサービス情報に対して固定的に設定されているものではなく、予約ごとに個別に設定されるものである。例えば、サービス情報を予約システムに登録した直後の予約に対しては比較的長い有効時間とし、登録後の経過時間が長い予約に対しては比較的短い有効時間としてもよい。確定済みの予約の件数が増加するのに応じて有効時間を短くするなどの態様としてもよい。予約システムを利用した期間や実績が高いユーザに対しては有効時間を長くするなどの態様としてもよい。

　上述の有効時間を用いる場合、
　前記有効時間は、前記申し込み時の前記携帯端末の位置と、前記店舗の位置とに基づいて設定されるものとしてもよい。

　こうすることによって、ユーザが来店に要する所要時間を踏まえて有効時間を設定することができる。有効時間の設定方法は、例えば、携帯端末と店舗の距離に応じて設定する方法、携帯端末の位置に基づいて交通機関の利用も踏まえた来店までの経路および所要時間を推測し、それに基づいて設定する方法などとすることができる。有効時間は、来店までの所要時間に対して余裕をもたせておくことが好ましい。携帯端末の位置は、ＧＰＳ（Global Positioning System）や通信に要する基地局を利用する方法などによって取得される位置情報を利用してもよいし、ユーザが住所等を入力するものとしてもよい。
　このように所要時間を踏まえた有効時間が設定されていれば、ユーザに対して、速やかに来店しようという動機付けを与えることができる。また、店舗にとっては、ユーザの来店を待つ時間、即ち来店するか否かが不特定な時間を抑制できるため、予約が店舗の収益に結びつかないという危険を抑制することができる。

　本発明においては、
　前記予約処理部は、前記申し込みが、該携帯端末に対して既に確定している他の予約と両立しない場合には、該申し込みによる予約を拒否するものとしてもよい。

　こうすることによって、予約の濫用を抑制することができる。上記態様の対象は、同一店舗における複数の予約の場合、異なる店舗間の予約の場合の双方が含まれる。同一店舗の予約とは、例えば、異なるタイミングで出されたサービス情報の双方に同一のユーザが予約する場合が挙げられる。異なる店舗間の予約としては、店舗Ａのサービス情報に対する予約と、店舗Ｂのサービス情報に対する予約とが、同じ時間帯になされる場合が挙げられる。このような両立しない予約を拒否することにより、予約の濫用を抑制し、確定された予約の信憑性、ひいては予約システムの有用性を向上させることができる。
　両立するか否かの判断は、種々の方法で行うことができる。例えば、店舗が同一か異なるかに関わらず、単一のユーザからは、複数の予約は受け付けないようにしてもよい。この場合は、予約した店舗に来店するか、予約の有効時間が経過して取り消された後でないと、新たな予約が受け付けられないことになる。また、別の方法として、店舗Ａに対する予約の後、店舗Ｂの予約に移動可能か否かを考慮して判断してもよい。この場合、有効時間内に店舗Ａに立ち寄った後、店舗Ｂに立ち寄ることができるのであれば、双方の予約は受付可能ということになる。

　本発明においては、
　前記予約をしたユーザが前記店舗に来店したことを表す来店確認報告を前記店舗から受信した場合に、該来店の実績を前記識別情報と関連づけて格納する実績管理部を備えるものとしてもよい。

　このようにユーザが来店した実績を管理することにより、予約の濫用を抑制することができる。また、来店の実績は、店舗からの報告によって管理するため、ユーザからの虚偽の報告を回避でき、実績の信憑性を高めることができる。
　店舗からの来店確認報告は、種々の方法で行うことができる。例えば、ユーザが来店したときに、店舗の従業員が、ユーザの識別情報を確認し、店舗に設置された端末から来店確認報告を送信するようにしてもよい。また、ユーザと予約との対応を確認するため、店舗に設置された端末から携帯端末に対してメール等を送信し、これにユーザが応答することによって、予約システムに来店確認報告が発信されるようにしてもよい。

　実績を管理する場合、
　前記予約処理部は、前記実績管理部に管理された実績を踏まえて、前記携帯端末からの予約の申し込みを確定するか拒否するかの判断を行うものとしてもよい。

　上記判断としては、例えば、来店の実績が低いユーザは、予約を濫用する傾向にあると判断し、以後の予約の受付けを拒否し、または他のユーザからよりも優先度を低くするなどの態様が考えられる。逆に、来店の実績が高いユーザに対しては、予約を優先的に受け付けるなどの態様が考えられる。
　こうすることにより、予約の濫用による店舗の不安または損失を回避することができる。また、ユーザに対しても、予約の濫用に対する抑止力になるとともに、確定した予約に対して来店を促す動機付けとなる。

　本発明においては、上述した種々の特徴を必ずしも全て備えている必要はなく、適宜、その一部を省略したり、組み合わせたりして構成してもよい。
　本発明は、上述した予約システムとしての態様に関わらず種々の態様で構成可能である。例えば、上述した予約システムを構成する携帯端末や管理サーバとして構成することもできる。また、この管理サーバを用いて予約を行う予約方法として構成してもよい。さらには、予約システムを構成する携帯端末や管理サーバに、上述したそれぞれの機能を実現するためのコンピュータプログラムとして構成し、また該コンピュータプログラムを記録したコンピュータが読み取り可能な記録媒体として構成してもよい。

予約システムの全体構成を示す説明図である。 予約システムの内部構成を示す説明図である。 管理サーバ、店舗端末におけるデータベースの構造を示す説明図である。 サービス情報登録および配信処理のフローチャートである。 予約処理のフローチャートである。 予約処理における処理例を示す説明図（１）である。 予約処理における処理例を示す説明図（２）である。 来店処理のフローチャートである。 来店実績管理処理のフローチャートである。 フィードバック処理のフローチャートである。

Ａ．システム構成：
　図１は、予約システムの全体構成を示す説明図である。予約システムは、店舗端末３００から登録されるサービス情報を、管理サーバ１００で管理して、ユーザが利用する携帯端末２００に送信し、予約を受け付けるシステムである。管理サーバ１００、携帯端末２００、店舗端末３００は、それぞれインターネットＩＮＴを介して接続されている。
　管理サーバ１００は、ユーザが予約に応じて来店した実績も管理し、実績に応じて、予約の優先度などを調整することもできる。店舗端末３００は、一つだけを描いてあるが、２以上としてもよいし、管理サーバ１００と統合してもよい。

　図中に、予約システムでやりとりされる情報の流れを示した。
　まず、店舗端末３００は、管理サーバ１００に対して、サービス情報を登録する（矢印ａ１）。店舗端末３００は、予め実施例の予約システムを利用するものとして利用申し込みがなされており、管理サーバ１００は、店舗端末３００が設置された店舗に付与された識別情報、即ち店舗ＩＤによって、登録されたサービス情報を管理する。
　サービス情報は、店舗端末３００からリアルタイムに変更可能である。例えば、店舗の管理者は、店舗がすいているときには、来客を誘引するように割引率の高いサービス情報を提供し、店舗が比較的混雑してきた場合には、割引率を下げ、または、ただいま混雑中といった内容のサービス情報にするなど、店舗の状況に応じて動的にサービス情報を変更することができる。

　管理サーバ１００に登録されたサービス情報は、ユーザが利用する携帯端末２００に電子メールなどを利用して配信される（矢印ａ２）。サービス情報は、管理サーバ１００から自動的に配信される他、ユーザが管理サーバ１００にアクセスして取得するようにしてもよい。取得する方法としては、例えば、管理サーバ１００が提供するウェブページにアクセスして、所望のクーポンをダウンロードする方法などが考えられる。

　ユーザは、配信または取得したサービス情報のうち、利用したいものがあれば、管理サーバ１００に、その店舗の予約を行う（矢印ａ３）。予約は、サービス情報に基づいて返信メールを送信する方法、サービス情報で指定されたリンク情報によってウェブページにアクセスする方法など、種々の方法で行うことができる。
　管理サーバ１００は、この予約を受け付け、管理する。店舗から登録されるサービス情報は、ユーザが予約を行った後も動的に変化する。しかし、本実施例では、管理サーバ１００は、ユーザからの予約が確定した時点で、そのユーザとの間では、サービス情報の内容を固定する。例えば、ユーザが予約した時点で、サービス情報で提示された割引が１０％であれば、その後、店舗が割引を５％にしたり、１５％にしたりしても、ユーザは１０％割引でのサービスを受けることになるのである。

　ユーザが予約に従って来店すると、店舗の管理者は、店舗端末３００を利用して、ユーザの来店を確認した報告を管理サーバ１００に送る（矢印ａ４）。また、管理サーバ１００は、ユーザの携帯端末２００との間で情報をやりとりし、確かに予約したユーザが来店していることを確認する（矢印ａ３）。ユーザが予約通りに来店したという実績は、管理亜サーバによって来店実績として管理され、次の予約時に、他のユーザよりも優先的に予約を受けられるなどの形で反映される。

　図２は、予約システムの内部構成を示す説明図である。図１で説明した機能を実現するために、各装置に備えられるべき機能ブロックを示した。本実施例では、携帯端末２００、および管理サーバ１００、店舗端末３００のいずれも、ＣＰＵ、ＲＡＭ、ＲＯＭ等を備えるコンピュータであるから、各機能ブロックは、主としてコンピュータにそれぞれの機能を実現するコンピュータプログラムをインストールすることによってソフトウェア的に構成されるものとしたが、いずれもハードウェア的に構成することも可能である。

　管理サーバ１００の構成について説明する。
　管理サーバ１００には、ユーザデータベース１０３、店舗データベース１０２、サービス情報データベース１０１の３つのデータベースが備えられている。ユーザデータベース１０３は、予約システムを利用するユーザに関する種々の情報を格納する。店舗データベース１０２は、予約システムを利用する店舗に関する種々の情報を格納する。サービス情報データベース１０１は、店舗から登録されたサービス情報を格納する。それぞれのデータベースの具体的な内容は後述する。
　配信制御部１１０は、サービス情報データベース１０１に登録されているサービス情報を配信する。配信のタイミングや配信範囲は、種々の設定が可能である。例えば、サービス情報が新たに登録または変更されたときに配信してもよいし、店舗から指定されたタイミングで配信してもよい。また、配信範囲は、ユーザデータベース１０３に登録されている全ユーザを対象としてもよいし、店舗から一定範囲内のユーザ、店舗からのクーポンの配信を希望するよう登録されているユーザ、店舗が嗜好に合うユーザなどに絞っても良い。
　予約処理部１１１は、携帯端末２００からの予約の申し込みを受信し、種々の条件を判断して予約を確立させる。本実施例では、それぞれの予約には、個別に有効時間が設定される。有効時間設定部１１２は、予約時の携帯端末２００の位置と、店舗の位置に基づいて、有効時間を設定する機能を奏する。
　実績管理部１１３は、予約に基づいてユーザが来店した実績、および予約したにも関わらず来店しなかった実績を管理する。この実績は、ユーザの次回の予約時に参照される。実績管理部１１３は、また、店舗に対するユーザの評価も管理する。ユーザによる評価は、店舗にフィードバックされ、店舗によるサービス改善に活用されることになる。

　携帯端末２００の構成について説明する。携帯端末２００には、端末を識別するための端末ＩＤが付されている。
　コマンド入力部２０１は、携帯端末２００の画面や、種々の物理的なスイッチなどを通じてユーザの操作によるコマンドを入力する。
　位置情報取得部２０２は、ＧＰＳ（Global Positioning System）等を利用して、携帯端末２００の位置情報を得る。
　サービス情報取得部２０３は、管理サーバ１００から、サービス情報を取得する。つまり、管理サーバ１００から配信されるサービス情報を受信し、また、管理サーバ１００にアクセスしてサービス情報をダウンロードする。サービス情報取得部２０３には、いわゆるフィルタ機能を持たせても良い。例えば、携帯端末２００の現在位置から所定範囲にある店舗からのサービス情報、ユーザが予め設定した嗜好、ジャンルに適合するサービス情報などの条件を満たすサービス情報のみを受け取るようにする機能である。かかる機能を設けることにより、ユーザにとって雑多なサービス情報を受け取ることを回避できる利点がある。
　予約処理部２０４は、取得したサービス情報に基づいて、携帯端末２００から管理サーバ１００に対して予約申し込み情報を送信し、また予約結果を受信する機能を奏する。予約申し込みには、端末ＩＤが含まれており、予約の申込者が簡易に特定可能とされている。端末ＩＤに代えて、ユーザを識別するためのユーザＩＤや、氏名等を入力するようにしてもよい。
　サービス情報記憶部２０５は、サービス情報取得部２０３で取得されたサービス情報を記憶する。全てのサービス情報を記憶しておく必要はなく、ユーザが指定したものだけでよい。また、サービス情報記憶部２０５は、予約が確定したサービス情報、例えば、店舗からの予約確認メールなども併せて記憶しておく。このサービス情報は、来店時に、ユーザ自身が予約者であることの確認などにも利用される。
　来店処理部２０６は、予約をしたユーザが来店したことを確認するための処理を行う。本実施例では、端末ＩＤを用いて予約が管理されているため、来店時にも、予約者であることの確認は、携帯端末２００の端末ＩＤを用いて行うものとしている。来店処理部２０６は、来店時に端末ＩＤを管理サーバ１００に送信するなどして、来店確認の処理をすすめるのである。予約の管理に、ユーザＩＤやユーザの氏名、予約番号などを用いる場合や、来店確認の際に端末ＩＤの確認までは行わない場合には、来店処理部２０６を省略することもできる。

　店舗端末３００の構成について説明する。
　店舗端末３００には、予約データベース３１０が備えられている。予約データベース３１０は、確定した予約情報を格納している。データ構造については後述する。
　サービス情報登録部３０１は、管理サーバ１００に店舗のサービス情報をアップロードする機能を奏する。本実施例では、サービス情報は、随時変更可能である。サービス情報登録部３０１で設定されたサービス情報は、サービス情報データベース３１１に、履歴として格納されている。
　予約情報管理部３０２は、予約を受け付け、予約データベース３１０を更新する機能を奏する。管理サーバ１００から予約の申し込みを受信したときには、サービス情報データベース３１１を参照し、申し込みに含まれているサービス内容の真偽を判断した上で、予約可否を応答する機能も有している。本実施例では、サービス情報は随時変化しているため、予約の申し込みに含まれるサービス内容が、その時点で配信しているサービス情報の内容とは異なる場合もあるため、内容の適否は、サービス情報の履歴を確認しないと判断できないからである。予約を受け付ける場合には、予約情報管理部３０２は、確定した予約を、予約データベース３１０に格納する。
　来店処理部３０３は、予約したユーザが来店したことを確認し、予約データベース３１０を更新する。先に説明した通り、本実施例では、ユーザの端末ＩＤを用いて来店の確認を行うものとした。端末ＩＤに代えて、ユーザＩＤや氏名、予約番号などを用いても良い。来店した実績、および予約しながら来店しなかった実績は、併せて予約データベース３１０に記録される。来店処理部３０３は、併せてユーザからの店舗に対する評価も受け付ける機能を有している。
　実績報告部３０４は、予約データベース３１０に記録されている来店の実績を、管理サーバ１００に報告する。実績の報告は、随時行うようにしてもよいし、定期的に行うようにしてもよい。

　図３は、管理サーバ、広告端末におけるデータベースの構造を示す説明図である。左側に、店舗端末３００の予約データベース３１０の構造を示し、右側に管理サーバ１００におけるサービス情報データベース１０１、店舗データベース１０２、ユーザデータベース１０３の構造を示した。

　店舗端末３００の予約データベース３１０には、図示する種々の情報が格納されている。予約データベース３１０には、全体に、店舗を識別するための店舗ＩＤが付されている。
　「時刻」は、予約の申し込みを受けた時刻である。
　「端末ＩＤ」は、予約したユーザが利用する携帯端末の識別情報である。
　「予約条件」は、予約の際のサービス情報に付されたサービス内容である。割引率、粗品等の進呈などの情報が含まれる。
　「人数」は、予約人数である。
　「予約番号」は、店舗端末３００が確定した予約に付す固有の番号である。
　「有効時間」は、予約の有効時間である。本実施例では、予約が濫用されるのを回避するため、それぞれの予約に個別に有効時間が設定される。予約の申し込みを受けた「時刻」から、「有効時間」を経過してもユーザが来店しなかった場合には、その予約はキャンセル扱いとなる。
　「来店」は、予約に対する来店確認の情報である。予約したユーザが来店した場合には、来店時刻や人数などの情報が格納される。また、予約したにもかかわらずユーザが来店しなかった場合も、無断キャンセルとして記録される。
　「フィードバック」は、ユーザの店舗に対する評価である。予約したユーザが来店した後、店舗に対する評価を送信すると、各予約と対応づけて「フィードバック」に記録される。評価の内容には、予約の前提となっているサービス内容と、実際に受けた内容が異なるなどの評価も含まれる。

　管理サーバ１００のデータベースについて説明する。
　サービス情報データベース１０１には、店舗ＩＤおよびサービス情報が格納されている。
　店舗ＩＤは、実施例の予約システムを利用する店舗ごとに付される識別情報である。
　サービス情報は、店舗からアップロードされたクーポンなどの情報である。本実施例では、サービス情報は、随時変化する。サービス情報データベース１０１は、サービス情報が更新されたときに、従前のサービス情報を上書きするようにしてもよいし、新たなサービス情報を履歴に追加するようにしてもよい。
　店舗データベース１０２は、店舗を識別するための店舗ＩＤ、基本情報、属性情報、評価情報が格納されている。
　基本情報は、店舗の名称、住所などの情報である。
　属性情報は、店舗のジャンル、広さ、営業時間などの情報である。
　評価情報は、ユーザからの店舗に対する評価、フィードバックを集計した情報である。管理サーバ１００は、評価が低い店舗に対しては、サービス向上を促す通知を発することができる。
　ユーザデータベース１０３は、各ユーザを識別するためのユーザＩＤ、基本情報、属性情報、ランキング情報、予約情報などが格納されている。
　基本情報は、氏名、端末ＩＤ、住所など、ユーザの個人情報等である。
　属性情報は、ユーザの嗜好などの情報である。
　ランキング情報は、ユーザが予約した店舗に来店した情報や、予約したにもかかわらずキャンセルした情報などによって与えられる評価である。ランキング情報は、次に予約を受け付ける際の優先度の調整に利用される。
　予約情報は、店舗端末３００の予約データベース３１０に対応する情報が格納されている。ユーザが予約をするのは一つの店舗に限られてはいないため、予約情報としては、複数の店舗の予約が履歴として残される。いずれの店舗に対する予約かは、店舗ＩＤによって特定可能である。

　以上で説明した各データベースの内容は、図中に示す通り、種々の識別情報によって相互に関連づけられている。例えば、店舗端末３００に用意されている予約データベース３１０には、店舗ＩＤが付されており、これによって、管理サーバ１００のサービス情報データベース１０１、店舗データベース１０２、およびユーザデータベース１０３の予約情報と関連づけられる。また、ユーザの端末ＩＤによって、ユーザデータベース１０３と、予約データベース３１０とが関連づけられる。

　以上のシステム構成により、予約システムは、図１で説明した種々の機能を実現する。
　以下では、それぞれの機能を実現するための処理内容をフローチャートに基づいて説明する。

Ｂ．サービス情報登録および配信処理：
　図４は、サービス情報登録および配信処理のフローチャートである。左側から、店舗端末３００の処理、管理サーバ１００の処理、携帯端末２００の処理を順に示した。
　店舗端末３００では、サービス情報登録処理が実行される。まず、店舗の管理者が、サービス情報を作成する（ステップＳ１０）。図中にサービス情報の例を示した。サービスタイムで１０％ＯＦＦをサービス内容とするクーポンの例である。サービス情報は、画像データの形で用意してもよいし、動画、テキストなどの形式で用意してもよい。店舗端末３００は、サービス情報を、店舗ＩＤとともに管理サーバ１００にアップロードする。
　管理サーバ１００では、サービス情報配信処理が実行される。管理サーバ１００は、店舗端末３００からサービス情報を受信すると（ステップＳ２０）、サービス情報データベースを更新する（ステップＳ２１）。本実施例では、新たに受信したサービス情報を履歴として順次格納する形をとった。本実施例では、サービス情報は随時更新されるため、サービス情報データベースには、同一店舗からの複数の情報が存在することになる。管理サーバ１００は、同一店舗からのサービス情報、即ち同一の店舗ＩＤが付されたサービス情報については常に最新のものが有効であると判断する。かかる判断を容易にするため、サービス情報データベースに格納された各サービス情報に、有効／無効のフラグを付すようにしてもよい。この場合は、新たなサービス情報が登録される度に、同一の店舗ＩＤを付した従前のサービス情報を検索し、そのフラグを無効に更新する処理を行うことになる。

　管理サーバ１００は、サービス情報データベースを更新すると、配信先の端末を特定する（ステップＳ２２）。特定方法としては、例えば、店舗から所定の距離内にある端末や、ユーザデータベース１０３に登録された属性情報を確認し、店舗が指定されたジャンルに該当するユーザの端末を特定する方法などとすることができる。これらの条件は、いずれか一方を考慮してもよいし、双方を考慮してもよい。いずれの条件を考慮するかを店舗が設定可能としてもよい。
　店舗から所定の距離内にある端末に配信するためには、携帯端末の位置情報が必要となる。そこで、管理サーバ１００は、携帯端末２００にリクエストを送信する。携帯端末２００では、サービス情報取得処理が起動しており、管理サーバ１００からのリクエストに応じて、端末ＩＤと位置情報を送信する（ステップＳ３０）。位置情報は、携帯端末２００が通信するための基地局などを利用して管理サーバ１００が取得するようにしてもよい。
　また、既に予約が確定している携帯端末２００は、予約している店舗からのサービス情報を配信する場合には、配信対象から除外するようにしてもよい。

　管理サーバ１００は、配信先の携帯端末を特定すると、サービス情報を配信する（ステップＳ２３）。携帯端末２００は、このサービス情報を受信し（ステップＳ３１）、画面に表示等してユーザに知らせる。管理サーバ１００から携帯端末２００に配信する他、ユーザが携帯端末２００を操作して、管理サーバ１００からサービス情報を取得する方法を併用しても良い。例えば、ユーザが管理サーバ１００によって提供されるウェブページにアクセスし、サービス情報を閲覧する方法や、携帯端末２００にインストールしたアプリケーションを利用して、管理サーバ１００に最新のサービス情報を配信するようにリクエストする方法などをとることができる。
　管理サーバ１００は、サービス情報の配信を完了すると、配信完了通知を店舗端末３００に送信する。店舗端末３００は、配信完了通知を受信することにより、配信確認処理を行う（ステップＳ１１）。配信確認処理としては、サービス情報データベース３１１に、配信が完了した旨の情報を記録し、店舗端末３００に配信完了の表示を行うなどの処理が挙げられる。

　以上で説明したサービス情報の登録および配信は、新たなサービス情報が登録される都度、随時、行うようにしてもよい。また、新たなサービス情報の登録が所定数に達した時点や、一定の周期などで行うようにしてもよい。ただし、サービス情報が随時更新され、それをユーザに配信することによって顧客の誘引を図るという本システムの利点を活かすためには、サービス情報の配信は、サービス情報の登録から配信までの経過時間が長時間にならないように、配信のタイミングを制御することが好ましい。

Ｃ．予約処理：
　図５は、予約処理のフローチャートである。左側から、店舗端末３００の処理、管理サーバ１００の処理、携帯端末２００の処理を順に示した。
　まず、ユーザは携帯端末２００で、取得したサービス情報を閲覧し、予約したいと思うサービス情報を選択する（ステップＳ７０）。そして、そのサービス情報を利用して予約情報を送信する（ステップＳ７１）。予約情報の送信は、サービス情報に対する返信メール、ウェブページに表示された予約ボタンのクリック、予約フォームへの入力などの方法で行うことができる。予約情報には、携帯端末２００の端末ＩＤ、予約する店舗の店舗ＩＤ、予約条件、携帯端末２００の位置情報などが含まれる。

　管理サーバ１００は、予約情報を受信すると（ステップＳ６０）、携帯端末２００の位置情報に基づいて申し込みを受けた予約の有効時間を設定する（ステップＳ６１）。本実施例では、有効時間は、来店のための所要時間に余裕を持たせて設定するものとした。まず、管理サーバ１００は、店舗ＩＤに基づいて店舗データベース１０２を参照し、店舗の位置を確認する。そして、携帯端末２００の位置情報を出発地、店舗を目的地として経路探索を行って所要時間を推測する。このとき、交通機関の利用時間も考慮する。そして、推測された所要時間に対して所定の割合または所定時間の余裕時間を加えることで、有効時間を設定するのである。有効時間の設定は、この他、携帯端末２００と店舗の距離に応じて設定してもよいし、携帯端末２００の位置とは無関係に設定してもよい。
　管理サーバ１００は、有効時間を設定すると、申し込みを受けた予約について、予約可否の判定を行う（ステップＳ６２）。予約可否の判定は、予約の濫用、即ちユーザが同じ時間帯に複数の予約を重ねて入れることを回避するための処理である。この判定の方法については後述する。
　予約可否の判定とともに、管理サーバ１００は、ランキング調整を行う（ステップＳ６３）。これは、ユーザが今までに予約した店舗に来店した、または、予約しておきながら来店しなかったなどの実績に基づいて、予約の受付を調整する処理である。キャンセルが多いユーザは、予約を濫用する傾向にあるため、予約を受け付ける優先度が低下する。例えば、一つの店舗に複数の候補者からの予約が申し込まれている場合には、ランキングの低いユーザよりも、高いユーザに優先的に予約を認めるようにしてもよい。また、店舗からの指定に基づき、ランキングが所定値よりも低いユーザからの予約は拒否するようにしてもよい。
　これらの処理を経て、予約が許可できないと判断する場合には、管理サーバ１００は、予約不可の通知を携帯端末２００に送信する（ステップＳ６４）。携帯端末２００は、この結果を受信し（ステップＳ７２）、画面に表示等する。

　予約は許可してもよいと判断すると（ステップＳ６４）、管理サーバ１００は、予約情報を店舗端末３００に送信する（ステップＳ６５）。予約情報には、端末ＩＤ、予約条件（有効時間を含む）などが含まれる。位置情報は省略してもよい。
　店舗端末３００は、予約情報を受信すると（ステップＳ５０）、サービス情報データベース３１１を参照し、予約情報の内容を確認する（ステップＳ５１）。サービス情報は随時更新されるため、予約条件として指定されたサービス情報が、現在、登録しているサービス情報と異なることもあるからである。指定された予約条件が、店舗側で現在または過去に登録したサービス情報に合致しない場合には、予約はサービス内容が改ざんされたものと判断し、店舗端末３００は管理サーバ１００に予約拒否の回答をする（ステップＳ５１）。管理サーバ１００は、ユーザデータベース１０３の予約情報として、ユーザが申し込みを行った予約内容およびそれが拒否された旨の情報を格納してユーザデータベースを更新し、携帯端末に予約結果を送信する（ステップＳ６６）。
　一方、店舗端末３００は、予約情報は正しいものであり、予約が可能であると判断すると（ステップＳ５１）、予約情報を格納して予約データベース３１０を更新し（ステップＳ５２）、管理サーバ１００に予約受付の回答を送信する。管理サーバ１００は、これを受けて、ユーザデータベース１０３の予約情報を更新し、予約結果を携帯端末２００に送信する（ステップＳ６６）。
　携帯端末２００は、予約結果を受信し（ステップＳ７２）、画面に表示等する。

　図６は、予約処理における処理例を示す説明図（１）である。
　上段には、ユーザが予約を申し込む際の携帯端末２００の表示画面例を示した。携帯端末２００には、図示するように種々の店舗からのサービス情報が表示され、ユーザはこれらを一覧表示させたり、切り換えて表示させたりして、希望の店舗を選択する。また、店舗ごとのサービス情報も随時更新される。図の例は、〇〇店のサービス情報は、割引が１０％、５％…というように時間によって変化していく例を示している。ユーザは、任意のタイミングで予約を申し込むことができる。例えば、図の例において、割引が１０％、５％と変化した後、１５％が提示された時点でユーザが予約を希望すれば、「予約」ボタンを押せばよい。ユーザが予約を申し込んだ後も、随時、サービス情報は更新されるため、図に示すように、割引がさらに２０％にあがる可能性もある。本実施例では、かかる場合でも、ユーザが申し込んだ予約は、１５％の割引率で処理される。逆に、予約を申し込んだ後、割引率が５％に下がったとしても、ユーザの予約は１５％の割引率で処理される。

　下段には、管理サーバにおける処理例を示した。
　まず、予約可否判定について説明する。この処理は、予約処理の予約可否判定（図５のステップＳ６２）に相当する処理であり、予約禁止時間内の予約は受け付けないことによって、ユーザからの予約の濫用を回避する処理である。図中には、予約禁止時間の設定方法を示した。それぞれの予約には、先に説明した通り、ユーザが来店するまでの所要時間を考慮した有効時間が設定されている。この有効時間に対して、来店したときに最低限滞在すると考えられる滞在時間を加えた時間が予約禁止時間である。滞在時間は、管理サーバ１００が、店舗の種別に応じて自動的に設定してもよいし、店舗が指定してもよい。例えば、飲食店であれば注文をして飲食をするのに要する最低時間、例えば３０分程度を滞在時間とすることができる。また、商店であれば品物を選んで会計をするのに要する最低時間、例えば１０分程度を滞在時間とすることができる。一方、既に来店済みの予約の場合は、来店までの所要時間に応じて設定される有効時間は考慮する必要がないから、滞在時間のみが予約禁止時間となる。
　予約または来店してから予約禁止時間が経過するまでの時間帯は、その予約に従えば、ユーザの行動が制約されることになるから、他の店舗に向かうこともできず、他の店舗で過ごすこともできないはずである。従って、管理サーバ１００は、既に確定した予約があるユーザについては、予約禁止時間が経過するまでの時間帯には他の予約を受け付けないものとしている。
　図の例において、あるユーザの予約として、未処理の予約、即ちまだ来店していない予約１があるものとする。予約１に対する予約禁止時間１は、予約１がなされた時点から、有効時間１および滞在時間１が経過するまでの時間帯である。この時間帯にユーザから他の予約が申し込まれた場合には、予約不可との判定がなされることになる。また、来店予約、即ち来店済みの予約２が存在する場合、予約２に対する予約禁止時間２は、来店までの有効時間２は無関係となり、来店された時点から、滞在時間２が経過するまでの時間帯である。この時間帯にユーザから他の予約が申し込まれた場合には、予約不可との判定がなされることになる。

　次に、ランキング調整について説明する。この処理は、予約処理のランキング調整（図５のステップＳ６３）に相当する処理であり、複数の予約があるときは、来店実績に応じて優先順位を調整するという処理である。図の中に、一つの店舗に、複数のユーザからの予約申し込みがなされている例を示した。予約１～４は、それぞれ端末ＩＤ、ユーザＩＤが異なる４人のユーザからの予約申し込みであり、上から予約時間が早い順に表示されている。ランキングは、各ユーザの来店実績を表しており、この値が高いほど、予約通りに来店した実績があることを示している。この例では、ＵＳＥＲ２およびＵＳＥＲ４のランキングがそれぞれ５、４となっており、ＵＳＥＲ１、ＵＳＥＲ３よりも高い。従って、管理サーバ１００は、ランキングの高いＵＳＥＲ２、ＵＳＥＲ４の順に予約を受け付ける。仮に予約を受け付ける定員が２名であるとすれば、ＵＳＥＲ１、ＵＳＥＲ３は、それぞれＵＳＥＲ２、ＵＳＥＲ４よりも早く申し込んでいるにもかかわらず、予約をすることができないことになる。
　ランキング調整は、かかる方法の他、予約に必要な最低限のランキングを設定するようにしてもよい。例えば、店舗がランキング３以上のユーザからの予約しか受け付けない旨を指定している場合には、管理サーバ１００は、ランキング３未満のＵＳＥＲ１、ＵＳＥＲ３からの予約は拒否することになる。
　このように予約の受付可否にランキングを考慮することによって、予約の濫用を抑制することができる。

　図７は、予約処理における処理例を示す説明図（２）である。
　上段には、店舗端末３００での処理例を示した。まず予約情報確認について説明する。この処理は、予約処理の予約情報確認（図５のステップＳ５０）に相当する処理であり、申し込まれた予約情報の真偽を判断する処理である。図中に、２つの予約情報が受信された例を示した。「ＡＢＣ１」なる端末ＩＤから受信した予約情報は、予約時刻が「１９：１５：３０」であり、予約条件として割引が「１５％」である旨の内容である。右側には、店舗端末３００のサービス情報データベース３１１を例示した。サービス情報データベース３１１には、時刻ごとの予約条件、この例では割引率の履歴が格納されている。このデータベースを参照すると、予約時刻が「１９：１５：３０」の時点では、割引率は「５％」であり、予約条件に示されている「１５％」となってはいない。従って、店舗端末３００は、この予約情報は、予約条件が改ざんされたものであると判断し、予約を拒否する。一方、「ＡＢＣ２」なる端末ＩＤからの予約情報は、予約時刻が「１９：０８：４５」であり、予約条件として割引が「８％」である。サービス情報データベース３１１を参照すれば、この予約条件は、適正であることが分かるから、店舗端末３００は、予約を許可する。
　このようにサービス情報データベースの履歴を参照することによって、予約の真偽を判断することが可能となる。

　次に、予約データベース更新について説明する。図中には、予約データベースの例を示した。この例では、１９：０８：４５という時刻に、「ＡＢＣ２」という端末ＩＤから、８％の割引率、予約人数は４人で予約がなされていることが分かる。この予約を特定する予約番号は００１であり、予約の有効時間は４５分である。また、来店「未」であるから、まだ予約をしたユーザは来店していないことが分かる。店舗端末３００では、新たな予約がなされると、その情報が更新され、図示した画面等で確認することができる。予約データベースの表示画面は、図の例に限らず、種々の形式をとることができる。また、予約データベースには、この他にも種々の情報を記録可能である。

　下段には、携帯端末２００における予約結果の受信画面例を示した。左側は、予約不可通知の例である。管理サーバ１００が、予約可否の判定の結果、予約を拒否する場合（図５のステップＳ６４）、および店舗端末３００が予約情報に改ざんがあると判断し、予約を拒否する場合（図５のステップＳ５１）などに受ける通知画面である。図では、「予約は受け付けできませんでした。」と結果だけを表示する例を示したが、その理由など、さらに詳細な情報を含めても良い。
　右側は、予約が確定した場合の予約結果通知の例である。店名および予約番号、予約人数、予約条件を表示するとともに、「１９：４８までにご来店下さい」のように、有効時間についての表示も行う。こうすることによって、ユーザの来店を促すことができる。

Ｄ．来店処理：
　図８は、来店処理のフローチャートである。左側から、店舗端末３００の処理、管理サーバ１００の処理、携帯端末２００の処理を順に示した。
　来店すると、ユーザの操作に応じて、携帯端末２００は予約結果（図７参照）を表示する（ステップＳ１２０）。
　店員は、店舗端末３００で予約データベースを表示させ（ステップＳ１００）、予約番号に対応する予約を確認する。店舗端末３００は、店員がユーザの来店を示す来店ボタンをクリッしたことを確認すると（ステップＳ１０１）、来店情報を管理サーバ１００に送信する（ステップＳ１０２）。来店情報には、端末ＩＤ、店舗ＩＤ、予約条件、予約番号などの情報が含まれる。来店ボタンは、例えば、予約データベースの表示画面（図７参照）において、各予約の横に設けても良い。また、店舗端末３００に、来店処理用の画面を表示させ、予約番号を入力するようにしてもよい。

　管理サーバ１００は、店舗端末３００からの来店情報を中継し（ステップＳ１１０）、携帯端末２００に送信する。携帯端末２００は、来店確認通知を受信すると（ステップＳ１２１）、ユーザの操作に応じて、来店確認処理を実行する（ステップＳ１２２）。来店確認処理は、来店確認通知を受信した旨を応答する処理である。例えば、来店確認通知がメールで送信されている場合には、そのままメールを返信する方法としてもよいし、来店確認通知に基づいて表示されるウェブページで、「確認」などのボタンを操作する方法としてもよい。来店確認処理を行うと、携帯端末２００から管理サーバ１００に、端末ＩＤ、店舗ＩＤ、予約番号などの情報が返信される。
　管理サーバ１００は、来店確認情報を、店舗端末３００に中継する（ステップＳ１１１）。
　店舗端末３００は、来店確認情報を受信し（ステップＳ１０３）、予約データベースを更新する（ステップＳ１０４）。即ち、来店確認情報に含まれる端末ＩＤ、予約番号などの情報が、ステップＳ１０２で来店情報を送信した予約の内容と合致している場合には、ユーザが確かに来店していると判断されるため、予約データベースの「来店」の情報を、来店済みに更新するのである。来店が確認された時刻を記録するようにしてもよい。そして、店舗端末３００は、管理サーバ１００に対して、来店確認報告を送信する（ステップＳ１０５）。
　管理サーバ１００は、来店確認報告を受けて、ユーザデータベースを更新する（ステップＳ１１２）。つまり、ユーザデータベース１０３の予約情報（図３参照）に、ユーザが来店したことを記録するのである。この結果、ユーザの来店実績が向上することになる。
　本実施例では、端末ＩＤを用いてユーザの来店を確認するため、来店情報および来店確認情報の送受信を行うものとしたが（ステップＳ１０２、Ｓ１０３、Ｓ１１０、Ｓ１１１、Ｓ１２１、Ｓ１２２）、これらの処理を省略し、店舗端末３００で来店ボタンの確認によって、予約データベースの更新等の処理（ステップＳ１０４、Ｓ１０５、Ｓ１１２）を行うものとしてもよい。

Ｅ．来店実績管理処理：
　図９は、来店実績管理処理のフローチャートである。管理サーバ１００が実行する処理である。この処理は、定期的に行うものとしてもよいし、店舗端末３００から予約受付、来店確認などの通知を受信した際などのタイミングで行ってもよい。
　この処理を開始すると、管理サーバ１００は、処理対象となるユーザについて、ユーザデータベースを参照する（ステップＳ１４０）。そして、未処理の予約がなければ（ステップＳ１４１）、そのまま処理を終了する。
　未処理の予約がある場合、即ち確定された予約はあるが、まだ来店していない予約がある場合には（ステップＳ１４１）、処理対象の予約を選択し、その予約について来店確認報告を受信しているかを確認する（ステップＳ１４２）。店舗端末３００に対して、来店が確認されているかを問い合わせるようにしてもよい。来店が確認された場合には、その予約について、来店完了した旨のデータを記録し、ユーザのランキングをアップさせる処理を行う（ステップＳ１４３）。
　来店が確認されない場合は（ステップＳ１４２）、次に、有効時間が経過しているか否かを判断する（ステップＳ１４４）。有効時間が経過している場合には、ユーザは、その予約通りに来店しないものと判断し、予約を取り消すとともに、ユーザのランキングをダウンする処理を行う（ステップＳ１４５）。
　管理サーバ１００は、以上の処理を、そのユーザについて未処理の予約がなくなるまで繰り返し実行して（ステップＳ１４１）、来店実績管理処理を終了する。

Ｆ．フィードバック処理：
　図１０は、フィードバック処理のフローチャートである。ユーザが来店した後、その店舗の評価を行うための処理である。
　ユーザは、携帯端末で、来店後に、予約結果を表示する（ステップＳ１８０）。そして、予約結果に基づいて評価情報を送信する（ステップＳ１８１）。図中に評価情報の入力例を示した。例えば、サービスが予約通りであったか否か、サービスに対する評価などが入力される。評価情報の入力および送信は、種々の方法で行うことができる。例えば、予約結果に表示されたリンク情報に基づいて、評価用のウェブページを表示させ、そこで、評価を入力するようにしてもよい。また、予約結果に返信メールを送信すると、評価情報の入力フォームが返送されてくるようにしてもよい。いずれにおいても、予約結果を用いることにより、ユーザが利用した店舗や予約番号などの入力を省略することができる利点がある。
　携帯端末２００から送信される評価情報には、端末ＩＤ、店舗ＩＤ、予約番号、評価などの情報が含まれる。

　管理サーバ１００は、評価情報を店舗端末３００に中継する（ステップＳ１７０）。併せて、管理サーバ１００は、評価情報に基づいて店舗データベース１０２の評価情報を更新する（ステップＳ１７１）。評価情報を単純に履歴として蓄積する方法をとってもよいが、本実施例では、評価結果を評価値に換算し、その平均値によって累積評価を求めるようにした。累積評価への換算は、評価情報の各項目に点数を与え、その和を求める方法で行うことができる。例えば、（項目１）サービスが予約通りであったか否か、および（項目２）サービスに対する５段階評価の２つの項目で店舗を評価する場合には、次の換算式を用いることができる。
　　評価値＝重み係数×評価１＋評価２；
　　ここで評価１は、サービスが予約通りのときに値１、そうでないときに値０とし、
　　評価２は、サービスに対する５段階評価を表す０～５の整数とする。
　　重み係数は、項目１の項目２に対する重み値であり、任意に設定可能である。サービスが予約通りでないことを重視する場合、例えば、値３など、１よりも大きい値とすることが好ましい。
　評価値への換算は、上述の方法に限らず、種々の方法をとることができる。
　管理サーバ１００は、店舗について累積評価が悪い場合、即ち累積評価が所定値よりも低い場合（ステップＳ１７２）、店舗に対して警告情報を送信する（ステップＳ１７３）。

　一方、店舗端末３００は、評価情報を受信し（ステップＳ１６０）、予約データベースを更新する（ステップＳ１６１）。そして、店舗端末３００の画面にフィードバックを表示する（ステップＳ１６２）。管理サーバ１００から、警告を受信した場合には（ステップＳ１７３）、併せて警告も表示する。
　図中にフィードバックの表示例を示した。本実施例では、予約情報の横に、評価の欄を設け、ここに評価情報を併せて表示する形式としている。この例では、ＡＢＣ２なる端末ＩＤからの評価は最低ランクの「１」であることが分かる。
　そして、画面の下側には、「累積評価が下がっています」という管理サーバ１００からの警告が表示されている。
　本実施例では、このようにユーザからの評価および管理サーバ１００からの警告を表示することにより、店舗のサービス向上に対する動機付けを与えることができる。評価および警告等の表示は、図中に例示した他、種々の形式で行うことが可能である。

Ｇ．効果及び変形例：
　以上で説明した本実施例の予約システムによれば、店舗から動的にサービス情報を変更しても、ユーザが予約を申し込んだ時点で、そのユーザとの間ではサービス内容が固定されるため、混乱なく予約を処理することができる。また、このように動的にサービス情報を変更可能としているため、店舗の混雑状況などに応じて柔軟にサービス内容を変更することができ、ユーザに対して来店を促すことが可能となる。
　実施例で説明した種々の機能は必ずしも全て備えられている必要はなく、適宜、一部を省略したり組み合わせたりすることも可能である。
　また、本実施例では、端末ＩＤを用いて予約を管理する例を示したが、ユーザＩＤ、ユーザの氏名など端末の識別情報以外を用いてもよい。
　携帯端末２００、店舗端末３００が実現する種々の機能は、アプリケーションをインストールする方法、ウェブプログラミングによる方法などで実現可能である。

　本発明は、スマートフォン、タブレット、携帯電話などの携帯端末を利用して、店舗等の予約をするために利用可能である。

１００　　：管理サーバ
１０１　　：サービス情報データベース
１０２　　：店舗データベース
１０３　　：ユーザデータベース
１１０　　：配信制御部
１１１　　：予約処理部
１１２　　：有効時間設定部
１１３　　：実績管理部
２００　　：携帯端末
２０１　　：コマンド入力部
２０２　　：位置情報取得部
２０３　　：サービス情報取得部
２０４　　：予約処理部
２０５　　：サービス情報記憶部
２０６　　：来店処理部
３００　　：店舗端末
３０１　　：サービス情報登録部
３０２　　：予約情報管理部
３０３　　：来店処理部
３０４　　：実績報告部
３１０　　：予約データベース
３１１　　：サービス情報データベース

 

Claims (7)

1. 　ユーザが利用する携帯端末に対して、所定の店舗におけるサービス内容を表すサービス情報を送信し、該携帯端末からの予約を受け付ける予約システムであって、
   　前記店舗からの指示によって随時変化する前記サービス情報を格納するサービス情報データベースと、
   　前記サービス情報を、前記携帯端末に送信する送信制御部と、
   　該携帯端末またはユーザを特定する識別情報とともに予約の申し込みを前記携帯端末から受信し、該受信後に前記サービス情報が変化した場合であっても該申し込みに基づいて特定されるサービス内容で、前記識別情報と関連づけて予約を確定する予約処理部とを備える予約システム。
2. 　請求項１記載の予約システムであって、
   　前記予約の申し込み時に、該予約ごとに設定される個別の有効時間を経過した場合に、該予約を取り消す実績管理部を備える予約システム。
3. 　請求項２記載の予約システムであって、
   　前記有効時間は、前記申し込み時の前記携帯端末の位置と、前記店舗の位置とに基づいて設定される予約システム。
4. 　請求項１～３いずれか記載の予約システムであって、
   　前記予約処理部は、前記申し込みが、該携帯端末に対して既に確定している他の予約と両立しない場合には、該申し込みによる予約を拒否する予約システム。
5. 　請求項１～４いずれか記載の予約システムであって、
   　前記予約をしたユーザが前記店舗に来店したことを表す来店確認報告を前記店舗から受信した場合に、該来店の実績を前記識別情報と関連づけて格納する実績管理部を備える予約システム。
6. 　請求項５記載の予約システムであって、
   　前記予約処理部は、前記実績管理部に管理された実績を踏まえて、前記携帯端末からの予約の申し込みを確定するか拒否するかの判断を行う予約システム。
7. 　ユーザが利用する携帯端末に対して、所定の店舗におけるサービス内容を表すサービス情報を送信し、該携帯端末からの予約を受け付ける管理サーバを用いる予約方法であって、
   　前記管理サーバが行う処理として、
   　前記店舗からの指示によって随時変化する前記サービス情報を格納するステップと、
   　前記サービス情報を、前記携帯端末に送信するステップと、
   　該携帯端末またはユーザを特定する識別情報とともに予約の申し込みを前記携帯端末から受信し、該受信後に前記サービス情報が変化した場合であっても該申し込みに基づいて特定されるサービス内容で、前記識別情報と関連づけて予約を確定するステップとを備える予約方法。
   　

Images