レストラン予約時素材代替システム、サーバ装置及びそれらに用いるレストラン予約時素材代替方法
【課題】 レストランの前日の余剰、残り、仕入れミスを無駄なく最大限にいかすことが可能なレストラン予約時素材代替方法を提供する。
【解決手段】 レストラン端末２及び利用者端末３は、インタネット１００を利用して、前日の余剰等の材料、空席情報、レストラン情報、利用者情報、メニュー情報、代替可能情報等をレストラン予約サーバ１に送信する。レストラン予約サーバ１はレストラン端末２及び利用者端末３から各種情報を受信すると、それらの情報をデータベースに格納し、利用者のサーチした条件でレストランを洗い出し、利用者との送受信によってレストランの空席情報に応じて当日の来店時間予約後、既存のメニューと代替希望の素材とを選択してもらう。これによって、レストラン予約サーバ１は、前日の余剰等の材料から適合する代替材料を洗い出し、利用者端末３に通知する。
【解決手段】 レストラン端末２及び利用者端末３は、インタネット１００を利用して、前日の余剰等の材料、空席情報、レストラン情報、利用者情報、メニュー情報、代替可能情報等をレストラン予約サーバ１に送信する。レストラン予約サーバ１はレストラン端末２及び利用者端末３から各種情報を受信すると、それらの情報をデータベースに格納し、利用者のサーチした条件でレストランを洗い出し、利用者との送受信によってレストランの空席情報に応じて当日の来店時間予約後、既存のメニューと代替希望の素材とを選択してもらう。これによって、レストラン予約サーバ１は、前日の余剰等の材料から適合する代替材料を洗い出し、利用者端末３に通知する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はレストラン予約時素材代替システム、サーバ装置及びそれらに用いるレストラン予約時素材代替方法並びにそのプログラムに関し、特にレストランの予約を行うための予約システムに関する。
【背景技術】
【０００２】
従来、この種のレストラン予約システムにおいては、レストランの予約を行う際に、席の予約か、予め決まったメニューの予約しか行うことができない。しかしながら、好き嫌い及びアレルギ等によって食べれる材料には個人差があり、そのメニューを予約して頼んでもすべて食すことができないのが現状である。
【０００３】
このメニューの予約に関しては、メニューの予約時に、メニューや写真だけの選択注文ではなく、殖財、カロリー、栄養素等による複数の方法でメニューを選択して注文するシステム（例えば、特許文献１参照）、宗教上の理由で食べられない食材を事前に登録してその食材を使用しない献立をたてる方法（例えば、特許文献２参照）等が提案されている。
【０００４】
【特許文献１】特開２００１−３０６６６６号公報
【特許文献２】特開平０９−０２６９５２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
上述した従来のレストラン予約システムでは、電話やインタネットでのレストラン予約が可能となっているが、席の予約か、もしくはメニュー及びコースの予約しか行うことができない。
【０００６】
メニューの予約では、各個人で好みや好き嫌い、アレルギで食べられない材料もあり、その予め決まっているメニューでも完全に綺麗に食べられずに残すケースも多々存在している。これでは、食材の無駄であり、また提供するレストラン側もお客様に満足して頂けない。また、特にチェーン店のレストランのメニューは全て同一であり、レストラン自体の特徴が薄く、店自体のアピールがない。このような問題は上記の特許文献１，２に記載の技術でも解決することが困難である。
【０００７】
そこで、本発明の目的は上記の問題点を解消し、レストランの前日の余剰、残り、仕入れミスを無駄なく最大限にいかすことができるレストラン予約時素材代替システム、サーバ装置及びそれらに用いるレストラン予約時素材代替方法を提供することにある。
【課題を解決するための手段】
【０００８】
本発明によるレストラン予約時素材代替システムは、レストランに対応して設けられかつそのレストランの各種情報を通知するレストラン端末と、ユーザの情報を通知して前記レストランの予約を行う利用者端末と、前記利用者端末からの前記レストランの予約を受け付けて前記レストラン端末各々にその予約情報を通知するための統括制御を行うサーバ装置とからなるレストラン予約時素材代替システムであって、
前記サーバ装置は、前記利用者端末からの前記レストランの予約の受け付け時に前記利用者端末に既存のメニューとそのメニューに対応する代替可能な素材とを通知する手段と、前記レストラン端末から少なくとも前日の余剰材料が通知された時にその前日の余剰材料を登録するデータベースと、前記代替可能な素材の通知に対する前記利用者端末からの回答を基に当該メニューにおける代替材料を前記データベースから検索する手段と、その検索結果を前記利用者端末に通知する手段とを備えている。
【０００９】
本発明によるサーバ装置は、ユーザの情報を通知してレストランの予約を行う利用者端末からの前記レストランの予約を受け付け、前記レストランに対応して設けられかつそのレストランの各種情報を通知するレストラン端末各々にその予約情報を通知するための統括制御を行うサーバ装置であって、
前記利用者端末からの前記レストランの予約の受け付け時に前記利用者端末に既存のメニューとそのメニューに対応する代替可能な素材とを通知する手段と、前記レストラン端末から少なくとも前日の余剰材料が通知された時にその前日の余剰材料を登録するデータベースと、前記代替可能な素材の通知に対する前記利用者端末からの回答を基に当該メニューにおける代替材料を前記データベースから検索する手段と、その検索結果を前記利用者端末に通知する手段とを備えている。
【００１０】
本発明によるレストラン予約時素材代替方法は、レストランに対応して設けられかつそのレストランの各種情報を通知するレストラン端末と、ユーザの情報を通知して前記レストランの予約を行う利用者端末と、前記利用者端末からの前記レストランの予約を受け付けて前記レストラン端末各々にその予約情報を通知するための統括制御を行うサーバ装置とからなるレストラン予約システムに用いるレストラン予約時素材代替方法であって、
前記サーバ装置が、前記利用者端末からの前記レストランの予約の受け付け時に前記利用者端末に既存のメニューとそのメニューに対応する代替可能な素材とを通知する処理と、前記レストラン端末から少なくとも前日の余剰材料が通知された時にその前日の余剰材料をデータベースに登録する処理と、前記代替可能な素材の通知に対する前記利用者端末からの回答を基に当該メニューにおける代替材料を前記データベースから検索する処理と、その検索結果を前記利用者端末に通知する処理とを実行している。
【００１１】
本発明のプログラムは、レストランに対応して設けられかつそのレストランの各種情報を通知するレストラン端末と、ユーザの情報を通知して前記レストランの予約を行う利用者端末と、前記利用者端末からの前記レストランの予約を受け付けて前記レストラン端末各々にその予約情報を通知するための統括制御を行うサーバ装置とからなるレストラン予約システムにおいて前記サーバ装置によって実行されるプログラムであって、
前記サーバ装置の中央処理装置に、前記利用者端末からの前記レストランの予約の受け付け時に前記利用者端末に既存のメニューとそのメニューに対応する代替可能な素材とを通知する処理と、前記レストラン端末から少なくとも前日の余剰材料が通知された時にその前日の余剰材料をデータベースに登録する処理と、前記代替可能な素材の通知に対する前記利用者端末からの回答を基に当該メニューにおける代替材料を前記データベースから検索する処理と、その検索結果を前記利用者端末に通知する処理とを実行させている。
【００１２】
すなわち、本発明のレストラン予約時素材代替システムは、インタネットを利用して、レストラン業者と利用者とから、前日の余剰等の材料、空席情報、レストラン情報、利用者情報、メニュー情報、代替可能情報等をサーバ装置に送信することによって、既存の用意されたメニューからでも利用者の希望に応じて前日の余剰等の材料によって利用素材を代替することを特徴としている。
【００１３】
サーバ装置は、レストラン業者と利用者とから各種情報を受信すると、それらの情報をＤＢ（データベース）に格納し、利用者のサーチした条件でレストランを洗い出し、利用者との送受信によってレストランの空席情報に応じて当日の来店時間予約後、既存のメニューと代替希望の素材とを選択してもらう。これによって、サーバ装置は、前日の余剰等の材料から適合する代替材料を洗い出し、利用者に通知することが可能となる。利用者は、代替後の素材使用メニューで予約するか否かをサーバ装置に回答することによって、メニューと座席予約とが完了する。
【００１４】
これらの動作によって、本発明のレストラン予約時素材代替システムでは、利用者が好みの素材を使ったオリジナルなメニューを注文することが可能となり、食べ物残しもなくなる。また、レストラン側も利用者のニーズに答えることによって、店の評判もよくなり、材料も無駄にならない。
【００１５】
レストラン側は、当日に前日の残り、余剰、期限切れ近い材料をサーバ装置に登録しておく。これによって、利用者がレストラン予約時も予め決まったメニューを選択し、この時に代替してほしい材料を選択することによって、予めサーバ装置で用意されていた代替品料理ＤＢと、登録した余剰材料等を登録してあるＤＢとを検索し、一致した材料を差し替えることが可能となる。よって、利用者は席の予約と全て自分好みのオリジナリティーにあふれたメニューの予約とを行うことが当日のみ可能となる。
【発明の効果】
【００１６】
本発明は、上記のような構成及び動作とすることで、レストランの前日の余剰、残り、仕入れミスを無駄なく最大限にいかすことができるという効果が得られる。
【発明を実施するための最良の形態】
【００１７】
次に、本発明の実施例について図面を参照して説明する。図１は本発明の一実施例によるレストラン予約時素材代替システムの構成を示すブロック図である。図１において、本発明の一実施例によるレストラン予約時素材代替システムは、レストランの予約を受け付けて各レストランに通知するための統括制御を行うレストラン予約サーバ１と、レストランに対応して設けられかつそのレストランの各種情報を通知するレストラン端末２と、ユーザの情報を通知してレストランの予約を行う利用者端末３とをそれぞれインタネット１００を介して相互に接続して構成されている。尚、レストラン予約サーバ１とレストラン端末２と利用者端末３とをそれぞれ接続するネットワークとしてはインタネット１００以外の通信網であってもよい。
【００１８】
利用者端末３は会員情報の登録及びレストラン予約を行うためにユーザが使用するパ−ソナルコンピュータ（以下、パソコンとする）等の情報処理装置であり、インタネット１００を介してレストラン予約サーバ１に会員情報を送信する。この時、利用者端末３はユーザが新規会員であれば、レストラン予約サーバ１から“会員Ｎｏ”を受信することができる。
【００１９】
また、利用者端末３はレストランの予約時に、「市区町村名」、または「市区町村名」及び「ジャンル」、あるいは「市区町村名」及び「店名」のいずれかを送信し、レストラン予約サーバ１から「レストランサーチ結果（図１５参照）」を受信することができる。この場合、利用者端末３は、その回答として“予約希望レストランＮｏ”と“予約希望時間”と“人数”とをレストラン予約サーバ１へ送信する目的に利用される。
【００２０】
利用者端末３は、空席が“予約希望時間帯”に存在しなかった場合、レストラン予約サーバ１から「満席による時間変更のお願い（図２３参照）」を受信することができる。これによって、利用者端末３では、予約するのであれば“予約可能時間帯”が入力されると、その内容をレストラン予約サーバ１に回答する機能を有している。
【００２１】
空席が存在した場合、利用者端末３はレストラン予約サーバ１から「オーダメニュー選択依頼（図１７参照）」を受信し、予約したいメニューの“選定”欄に数量が、代替したい材料がある場合に“代替希望材料”欄に材料名がそれぞれ入力されると、その内容をレストラン予約サーバ１に回答することができる。
【００２２】
この回答結果によって、利用者端末３はレストラン予約サーバ１から「代替材料一致のお知らせ（図１９参照）」を受信し、そのメニューでよければ“回答”欄に“○”を入力することができる。予約が完了し次第、利用者端末３はレストラン予約サーバ１から「レストラン予約完了通知（図２２参照）」を受信する目的に利用される。
【００２３】
図２は図１のレストラン予約サーバ１の構成を示すブロック図である。図２において、レストラン予約サーバ１は処理装置［ＣＰＵ（中央処理装置）］１１と、処理装置１１が実行する制御プログラム１２ａを格納するメインメモリ１２と、インタネット１００を通して他の装置に接続するための通信制御を行う通信制御装置１３と、前日余剰材料ＤＢ（データベース）１４と、レストラン情報ＤＢ１５と、通常メニューＤＢ１６と、代替可能材料ＤＢ１７と、会員情報ＤＢ１８と、オーダ情報ＤＢ１９と、レストラン空席ＤＢ２０とから構成されている。
【００２４】
処理装置１１はレストラン予約サーバ１内の各部を制御し、インタネット１００を介して利用者端末３から会員情報を受信すると、その会員情報を会員情報ＤＢ１８（図１６参照）に格納する機能を有している。またこの時、利用者端末３のユーザが新規会員であれば、処理装置１１は“会員Ｎｏ“を自動採番し、利用者端末３に送信する機能も有している。
【００２５】
また同様に、処理装置１１は複数のレストラン端末２からレストラン情報、通常メニュー情報、代替可能な材料情報、余剰等材料情報、空席情報を受信し、レストラン情報ＤＢ１５（図１２参照）、通常メニューＤＢ１６（図１３参照）、代替可能材料ＤＢ１７（図１４参照）、前日余剰材料ＤＢ１４（図１１参照）、レストラン空席ＤＢ２０（図２１参照）にそれぞれに格納する機能も有している。
【００２６】
処理装置１１は利用者端末３から予約情報を受信すると、受信した情報でレストラン情報ＤＢ１５の検索を行い、一致した情報を基に「レストランサーチ結果」を自動作成して利用者端末３に送信することができる。また、処理装置１１は「レストランサーチ結果」に対する回答を利用者端末３から受信すると、利用者端末３からの希望時間がレストラン空席ＤＢ２０において満席と判断した場合に前後の時間をサーチし、「満席による時間変更のお願い」を自動作成して利用者端末３へ送信する。
【００２７】
これに対する利用者端末３からの回答を受信すると、処理装置１１は「予約する」の内容であれば、レストラン情報ＤＢ１５から“空き人数”をその予約人数分マイナスして上書き格納する。空席と判断した場合、処理装置１１は、上記と同様に、レストラン情報ＤＢ２０から“空き人数”をその予約人数分マイナスして上書き格納する。
【００２８】
さらに、処理装置１１は、利用者端末３からの回答に記載の“予約希望レストランＮｏ”よりレストラン情報ＤＢ２０と通常メニューＤＢ１６とから「オーダメニュー選択依頼」を自動作成して利用者端末３へ送信する。これに対する回答を利用者端末３から受信すると、処理装置１１はオーダ情報ＤＢ１９（図１８）に格納する機能を有している。
【００２９】
処理装置１１は代替希望材料がある場合、オーダ情報ＤＢ１９及び代替可能材料ＤＢ１７各々の「レストランＮｏ」、「メニューＮｏ」、「代替可能部分」、「代替希望材料」を比較して一致した材料を選択し、前日余剰材料ＤＢ１４から一致した材料が“使用量”分だけ”残量があるかどうかを確認し、これらのデータを基に「代替希望材料一致のお知らせ」を自動作成して利用者端末３へ送信する目的に利用される。
【００３０】
利用者端末３からの「代替希望材料一致のお知らせ」に対する回答を受信すると、処理装置１１はその回答内容をオーダ情報ＤＢ１９に格納する。この時、処理装置１１は代替可能材料ＤＢ１７から使用量を抽出し、前日余剰材料ＤＢ１４から使用量をマイナスし、“残量”欄に上書き格納する。それらのデータの格納後、処理装置１１はオーダ情報ＤＢ１９、会員情報ＤＢ１８、レストラン情報ＤＢ１５の内容を基に「レストラン予約のお願い（図２０参照）」を自動作成してレストラン端末２へ送信すると同時に、「レストラン予約完了通知」も自動作成して利用者端末３へ送信することもできる。
【００３１】
レストラン端末２はレストラン及び通常メニュー、代替可能な材料、余剰、空席の各種情報を登録するユーザが使用するパソコン等の情報処理装置であり、複数のレストラン端末２から構成されている。レストラン端末２各々はインタネット１００を介して、レストラン予約サーバ１にレストラン及び通常メニュー、代替可能な材料、余剰、空席の各種情報を送信する機能を有している。また、レストラン端末２各々はレストラン予約サーバ１からの予約が確定した際に、「レストラン予約のお願い」を受信する目的に利用される。
【００３２】
図３〜図１０は本発明の一実施例によるレストラン予約時素材代替システムの動作を示すシーケンスチャートであり、図１１は図２の前日余剰材料ＤＢ１４の構成例を示す図であり、図１２は図２のレストラン情報ＤＢ１５の構成例を示す図であり、図１３は図２の通常メニューＤＢ１６の構成例を示す図であり、図１４は図２の代替可能材料ＤＢ１７の構成例を示す図であり、図１５は本発明の一実施例による「レストランサーチ結果」の一例を示す図である。
【００３３】
図１６は図２の会員情報ＤＢ１８の構成例を示す図であり、図１７は本発明の一実施例による「オーダーメニュー選択依頼」の一例を示す図であり、図１８は図２のオーダ情報ＤＢ１９の構成例を示す図であり、図１９は本発明の一実施例による「代替希望材料一致のお知らせ」の一例を示す図であり、図２０は本発明の一実施例による「レストラン予約のお願い」の一例を示す図であり、図２１は図２のレストラン空席ＤＢ２０の構成例を示す図であり、図２２は本発明の一実施例による「レストラン予約完了通知」の一例を示す図であり、図２３は本発明の一実施例による「満席による時間変更のお願い」の一例を示す図である。
【００３４】
図１１において、前日余剰材料ＤＢ１４には、レストラン名（「００１Ｒ」、・・・）、日付（「２００５／１２／１３」、・・・）、材料（「とうもろこし」、「オリーブ」、「ハム」、「キャベツ」、「トマト」、・・・）、量（「１Ｋｇ」、「４Ｋｇ」、「３Ｋｇ」、「３０Ｋｇ」、「１５Ｋｇ」、・・・）、残量（「７００ｇ」、「５００ｇ」、「２Ｋｇ」、「２Ｋｇ」、「２Ｋｇ」、・・・）が対応付けられて格納されている。
【００３５】
図１２において、レストラン情報ＤＢ１５には、レストランＮｏ（「００１Ｒ」、「００２Ｒ」、・・・）、市区町村名（「千葉県千葉市美浜区Ａ町」、「千葉県千葉市稲毛区Ａ町」、・・・）、ＴＥＬ（「ＸＸＸ」、・・・）、店名（「ハングリー」、「Ｂ店」、・・・）、ジャンル（「ファミレス」、・・・）、メールアドレス（「ＤＥＮＩ＠ＪＰ」、「ＳＫＹ＠ＪＰ」、・・・）、地図（「ＸＸ」、「」、・・・）、案内（「ＸＸ」、・・・）が対応付けられて格納されている。
【００３６】
図１３において、通常メニューＤＢ１６には、レストランＮｏ（「００１Ｒ」、・・・）、大区分（「ステーキ」、「サラダ」、「汁物」、・・・）、メニューＮｏ（「１」、「２」、「３」、・・・）、メニュー名（「デミグラスハンバーグ」、「マーメイドサラダ」、「ハングリーサラダ」、「トン汁」、・・・）、メニュー写真（「ＸＸ」、・・・）、代替可能部分（「付け合せ」、「トッピング」、「具」、・・・）、代替部分使用材料（「にんじん、エンドウ、ピーマン」、「アスパラ、卵、シーチキン」、「トマト、かいわれ」、「にんじん、ジャガ芋、こんにゃく、肉」、・・・）、価格（「１２００円」、「５００円」、「３００円」、「２００円」、・・・）が対応付けられて格納されている。
【００３７】
図１４において、代替可能材料ＤＢ１７には、レストランＮｏ（「００１Ｒ」、・・・）、メニューＮｏ（「２」、「１」、・・・）、代替可能部分（「トッピング」、「付け合せ」、・・・）、代替部分使用材料（「アスパラ」、「シーチキン」、「卵」、「にんじん」、「エンドウ」、・・・）、代替可能材料（「とうもろこし」、「オリーブ」、「かいわれ」、「キャベツ」、「ブロッコリー」、・・・）、使用量（１人前）（「１００ｇ」、「２００ｇ」、・・・）が対応付けられて格納されている。
【００３８】
図１６において、会員情報ＤＢ１８には、会員Ｎｏ（「Ｎｏ１」、「Ｎｏ２」、「Ｎｏ３」、・・・）、住 所（「ＸＸＸ」、・・・）、氏 名（「かつや」、「りか」、「ゆかり」、・・・）、年齢（「ＸＸ」、・・・）、ＴＥＬ（「ＸＸＸ」、・・・）、メールアドレス（「ＫＡＴＵＹＡ＠ＪＰ」、「ＲＩＫＡ＠ＪＰ」、「ＹＵＫＡＲＩ＠ＪＰ」、・・・）が対応付けられて格納されている。
【００３９】
図１８において、オーダ情報ＤＢ１９には、会員Ｎｏ（「２」、・・・）、レストランＮｏ（「００１Ｒ」、・・・）、日付（「２００５／１２／１３」、・・・）、メニューＮｏ（「２」、「１」、・・・）、メニュー名（「マーメイドサラダ」、「デミグラスハンバーグ」、・・・）、時間（「ＸＸ：ＸＸ」、・・・）、代替可能部分（「トッピング」、「付け合せ」、・・・）、代替希望材料（「アスパラ、卵」、・・・）、代替材料（「とうもろこし、卵」、・・・）、数量（「１」、・・・）が対応付けられて格納されている。
【００４０】
図２１において、レストラン空席ＤＢ２０には、レストランＮｏ（「００１Ｒ」）、日付（「２００５／１２／１３」）、種別（「空席」、・・・）、時間（「１０：００−１１：００」、「１１：００−１２：００」、・・・）、空き人数（「４８人」、「３０人」、・・・）が対応付けられて格納されている。
【００４１】
これら図１〜図２３を参照して本発明の一実施例によるレストラン予約時素材代替システムの動作について説明する。尚、図３〜図１０において、レストラン予約サーバ１の処理動作は処理装置１１が制御プログラム１２ａを実行することで実現される。
【００４２】
利用者端末３（ユーザ名：りか）は、予約をしたい時、会員情報がない場合に、新規に登録しないといけないので、インタネット１００を介して新規会員情報をレストラン予約サーバ１へ送信する（図６のｃ１〜ｃ３）。レストラン予約サーバ１の処理装置１１は新規会員情報を受信すると（図６のａ３１）、会員Ｎｏを自動採番し（図６のａ３２）、“会員Ｎｏ（Ｎｏ２）”とともに会員情報ＤＢ１８に格納する（図６のａ３３）。処理装置１１はそれらの情報を格納した後、採番した“会員Ｎｏ（Ｎｏ２）”を利用者端末３（ユーザ名：りか）へ送信する（図６のａ３４）。
【００４３】
利用者端末３（ユーザ名：りか）は、新規採番した“会員Ｎｏ（Ｎｏ２）”を受信すると（図６のｃ４）、自身の会員Ｎｏが“会員Ｎｏ（Ｎｏ２）”であることを認識する。この場合、その“会員Ｎｏ（Ｎｏ２）”を利用者端末３（ユーザ名：りか）内に記憶してもよい。
【００４４】
複数のレストラン端末２は、新規にレストラン情報を登録する場合、インタネット１００を介して新規レストラン情報をレストラン予約サーバ１へ送信する（図３のｂ１，ｂ２）。レストラン予約サーバ１の処理装置１１は、新規レストラン情報を受信すると（図３のａ１）、レストランＮｏを自動採番し（図３のａ２）、“レストランＮｏ”とともにレストラン情報ＤＢ１５に格納する（図３のａ３）。
【００４５】
また、複数のレストラン端末２は、上記と同様に、新規の通常メニューがある場合、インタネット１００を介して新規通常メニュー情報をレストラン予約サーバ１へ送信する（図３のｂ３，ｂ４）。レストラン予約サーバ１の処理装置１１は、新規通常メニュー情報を受信すると（図３のａ４）、“メニューＮｏ”を自動採番し（図３のａ５）、レストラン情報ＤＢ１５への格納時に採番した“レストランＮｏ”とともに通常メニューＤＢ１６（図１３に示す形式）に格納する（図３のａ６〜ａ８）。
【００４６】
さらに、レストラン端末２は格納した通常メニューＤＢ１６に対する新規代替可能な部分及び材料情報をインタネット１００を介してレストラン予約サーバ１に送信する（図４のｂ５，ｂ６）。レストラン予約サーバ１の処理装置１１は、新規代替可能な部分及び材料情報を受信すると（図４のａ９）、レストラン情報ＤＢ１５（図１２に示す形式）への格納時に採番した“レストランＮｏ”及び通常メニューＤＢ１６への格納時に採番した“メニューＮｏ“とともに代替可能材料ＤＢ１７（図１４に示す形式）に格納する（図４のａ１０〜ａ１４）。
【００４７】
複数のレストラン端末２は、当日に前日の材料に余剰、残り、仕入れミス等がある場合、インタネット１０を介して材料情報をレストラン予約サーバ１に送信し（図４のｂ７，ｂ８）、これと同時に、当日の空席情報もレストラン予約サ―バ１に送信する（図５のｂ９，ｂ１０）。レストラン予約サーバ１の処理装置１１は、材料情報をレストラン情報ＤＢ１５に格納した時に採番した“レストランＮｏ”とともに、前日余剰材料ＤＢ１４（図１１に示す形式）に格納し（図４のａ１５〜ａ１８）、また空席情報は“レストランＮｏ”毎にレストラン空席ＤＢ２０（図２１に示す形式）に格納する（図５のａ１９〜ａ２２）。
【００４８】
利用者端末３（ユーザ名：りか）は、レストランの予約をしたい時、インタネット１００を介してレストラン予約サーバ１に予約したいレストランをサーチするために「市区町村名」、または「市区町村名」及び「ジャンル」、あるいは「市区町村名」及び「店名」のいずれかのサーチ情報を送信する（図６のｃ５）。以下の説明では、例えば、「市区町村名」＝千葉県千葉市美浜区Ａ町、「ジャンル」＝ファミレスのサーチ情報を送信するものとする。
【００４９】
レストラン予約サーバ１の処理装置１１は、サーチ情報を受信すると（図６のａ３５）、条件（「市区町村名」＝千葉県千葉市美浜区Ａ町、「ジャンル」＝ファミレス）でレストラン情報ＤＢ１５から“市区町村名”、“ジャンル”をサーチし（図６のａ３６）、選択した“地図（図）”、“案内”を基に「レストランサーチ結果（図１５に示す形式）」で自動作成し（図６のａ３７）、利用者端末３（ユーザ名：りか）のメールアドレスに送信すると同時に、ＷＥＢで閲覧できるように掲載する（図６のａ３８）。上記のサーチにおいては、「市区町村名＝“千葉県千葉市美浜区Ａ町”」、「ジャンル＝“ファミレス”」で行われている。
【００５０】
利用者端末３（ユーザ名：りか）は、「レストランサーチ結果」を受信すると（図６のｃ６）、回答欄に“予約希望レストランＮｏ（００１Ｒ）“、”予約希望時間（１０：００−１１：００）“、”人数（２人）“を入力し、レストラン予約サーバ１に送信する（図７のｃ７）。
【００５１】
レストラン予約サーバ１の処理装置１１は、利用者端末３（ユーザ名：りか）から「レストランサーチ結果」の回答を受信すると（図７のａ３９）、「回答欄」に記載の“予約希望レストランＮｏ：００１Ｒ”及び“予約希望時刻：１０：００−１１：００”と、レストラン空席ＤＢ２０の“レストランＮｏ（００１Ｒ）”及び“時間（１０：００−１１：００）”とを比較し、一致したレコードの“種別”をみて以下の処理を行う。
【００５２】
パターン１：“種別“＝満席の場合（図７のａ４１）、処理装置１１は、“時間（１０：００−１１：００）”前後周辺で最も指定された時間の近いレコードの“種別（空席）”レコードの“時間”を抽出し（図７のａ４２）、「満席による時間変更のお願い（図２３参照）」を自動作成し（図７のａ４３）、利用者端末３（ユーザ名：りか）のメールアドレスへ送信すると同時に、ＷＥＢで閲覧できるように掲載する（図７のａ４４）。この時、締切り時間は、一番早い“予約可能時間”の一定の時間前とする（今回の場合は、１時間前とする）。
【００５３】
利用者端末３（ユーザ名：りか）は、「満席による時間変更のお願い」をメールにて受信、もしくはＷＥＢより閲覧すると（図７のｃ９）、締切り時間までに回答欄に予約する場合に（１．予約する）に予約時間を選択して入力し、予約しない場合に（２．予約しない）にチェックし、回答をレストラン予約サーバ１に送信する（図７のｃ１０，ｃ１１）。
【００５４】
レストラン予約サーバ１の処理装置１１は、締切り時間までに回答を受信すると（図７のａ４５，ａ４６）、回答欄が（１．予約する）の回答のみ“予約希望レストランＮｏ：００１Ｒ”及び回答欄に記載の“予約希望時刻：１０：００−１１：００”と、レストラン空席ＤＢ２０の“レストランＮｏ（００１Ｒ）”及び“時間（１０：００−１１：００）”とを比較し（図７のａ４７，図８のａ５０，ａ５１）、“空き人数（４８人）”を抽出し、「回答欄」記載の“人数：２人”をマイナスする（４８人−２人＝４６人）（図８のａ５２）。この計算によって４６人分の空席がこの時間帯に存在することが分かるので、処理装置１１は、“空き人数”を更新し、４８人より４６人にレコードを書き換える（図８のａ５３）。レストラン予約サーバ１は上記の締切り時間が経過した時点で回答受信を拒否する。
【００５５】
パターン２：“種別”＝空席の場合（図７のａ４１）、処理装置１１は、“空人数（４８人）”を抽出し、「回答欄」記載の“人数：２人”をマイナスする（４８人−２人＝４６人）（図７のａ４８）。この計算によって４６人分の空席がこの時間帯に存在することが分かるので、処理装置１１は、“空き人数”を更新し、４８人より４６人にレコードを書き換える（図７のａ４９）。
【００５６】
パターン１，２以降の処理の場合、処理装置１１は、「回答欄」に記載の“予約希望レストランＮｏ：００１Ｒ”を、レストラン情報ＤＢ１５から“レストランＮｏ（００１Ｒ）”でレコードを抽出し（図８のａ５４）、またこれと同様に、通常メニューＤＢ１６から“レストランＮｏ（００１Ｒ）”のレコードも抽出する（図８のａ５５）。さらに、処理装置１１は、これらのレコードを基に「オーダメニュー選択依頼（図１７参照）」を自動作成し（図８のａ５６）、利用者端末３（ユーザ名：りか）のメールアドレスへ送信すると同時に、ＷＥＢで閲覧できるように掲載する（図８のａ５７）。
【００５７】
利用者端末３（ユーザ名：りか）は、「オーダメニュー選択依頼」をメールにて受信、もしくはＷＥＢより閲覧すると（図８のｃ１２）、“選定欄”に注文数量を入力し、“代替部分使用材料欄”に苦手、もしくは気に入らない材料があったらその材料を“代替部分利用材料”から抽出し、“代替希望材料欄”に入力し、これらの入力後、レストラン予約サーバ１にメールにて送信、またはＷＥＢにて回答を行う（図８のｃ１３）。
【００５８】
レストラン予約サーバ１の処理装置１１は、利用者端末３（ユーザ名：りか）から「オーダメニュー選択依頼」の回答を受信すると（図８のａ５８）、オーダ情報ＤＢ１９（図１８に示す形式）に当日の日付とともに格納する（図８のａ５９）。さらに、処理装置１１は、“代替希望材料”欄に代替希望がある場合、“代替材料”指定のオーダ情報ＤＢ１９の“レストランＮｏ（００１Ｒ）“、”メニューＮｏ（２）“、”代替可能部分（トッピング）“、”代替希望材料（アスパラ、卵）“と、代替可能材料ＤＢ１７の“レストランＮｏ（００１Ｒ）“、”メニューＮｏ（２）“、”代替可能部分（トッピング）“、”代替部分使用材料（アスパラ、卵）“とを照合し、一致した”代替可能材料（アスパラ：とうもろこし、卵：かいわれ）“と”使用量（１人前）（１００Ｇずつ）“を代替可能材料ＤＢ１７から選択する（図８のａ６０，ａ６１）。
【００５９】
選択後、処理装置１１は、“代替可能材料（アスパラ：とうもろこし、卵：かいわれ）”が前日余剰材料ＤＢ１４の“レストランＮｏ（００１Ｒ）”の当日の日付の全てのレコードの“材料”と比較し、一致した材料（とうもろこし、かいわれ）で“残量”があり、かつ代替可能材料ＤＢ１７から選択した“使用量（１人前）（１００ｇずつ）”以上の“材料（アスパラ：とうもろこし（残量＝７００ｇ、卵：かいわれ（無し））”を前日余剰材料ＤＢ１４から抽出する（図９のａ６２）。抽出後、処理装置１１は、「代替希望材料一致のお知らせ（図１９に示す形式）」をオーダ情報ＤＢ１９、代替可能材料ＤＢ１７から自動作成し（図９のａ６３）、利用者端末３（ユーザ名：りか）のメールアドレスへ送信すると同時に、ＷＥＢで閲覧できるように掲載する（図９のａ６４）。
【００６０】
利用者端末３（ユーザ名：りか）は、「代替希望材料一致のお知らせ（図１９参照）」を受信すると（図９のｃ１５）、“回答”欄に“代替希望材料”が“代替可能材料”（アスパラ→とうもろこし、卵→代替なし）で注文するのであれば「○」の入力を、注文しないのであれば「×」の入力を行い、レストラン予約サーバ１へ送信、またはＷＥＢにて回答を行う（図９のｃ１６）。
【００６１】
レストラン予約サーバ１の処理装置１１は、回答を受信すると（図９のａ６５）、「代替希望材料一致のお知らせ（図１９参照）」の“代替可能材料”欄を、“会員Ｎｏ”、“レストランＮｏ”、“メニューＮｏ“をキーにしてオーダ情報ＤＢ１９の“代替材料”欄に格納する（図９のａ６６）。またこの時、処理装置１１は、代替可能材料ＤＢ１７を“レストランＮｏ（００１Ｒ）”、“メニューＮｏ（２）”、“代替可能部分（トッピング）“、”代替部分使用材料（アスパラ）“で検索し、一致した”使用量（１人前）（１００ｇ）“を抽出する（図９のａ６７）。
【００６２】
さらに、処理装置１１は、前日余剰材料ＤＢ１４の“レストランＮｏ”を“００１Ｒ”及び“材料”を“とうもろこし”で抽出し（図９のａ６８）、一致したレコードの残量（７００ｇ）から、代替可能材料ＤＢ１７で選択した”使用量（１人前）（１００ｇ）“を引いた量”６００ｇ“を残量として、前日余剰材料ＤＢ１４の”残量“欄を上書き格納する（図９のａ６９，ａ７０）。
【００６３】
処理装置１１は、オーダ情報ＤＢ１９、会員情報ＤＢ１８、レストラン情報ＤＢ１５の内容を基に「レストラン予約のお願い（図２０参照）」、「レストラン予約完了通知（図２２参照）」をそれぞれ自動作成し（図９のａ７１〜ａ７４，図１０のａ７５）、レストラン端末２（レストラン名：ハングリー）、利用者端末３（ユーザ名：りか）のメールアドレスへ送信すると同時に、ＷＥＢで閲覧できるように掲載する（図１０のａ７６，ａ７７）。
【００６４】
レストラン端末２（レストラン名：ハングリー）は、「レストラン予約のお願い」を受信すると（図１０のｂ１１）、当日の利用者端末３（ユーザ名：りか）の来店時間、来店時予約メニュー、代替材料メニューを認識して予約を入れ、予約時間まで準備をしておくことができる。また、利用者端末３（ユーザ名：りか）は、「レストランレストラ完了通知」を受信した当日の予約した時間にレストランへ行き、苦手や好みでない食材がその日の材料で代替可能になるので、自由に選択することができ、食べ残しもなくなる。
【００６５】
このように、本実施例では、レストランの前日の、余剰、残り、仕入れミスを無駄なく最大限にいかすことができる。また、本実施例では、ユーザが苦手な食材をレストランの前日の余剰等に応じて好みの食材へ変更することができるので、食べ残しがなくなる。
【００６６】
さらに、本実施例では、レストラン独自のメニューが食材の代替によってできるので、店のアピールにも繋がり、余剰、残り、仕入れミス素材が無駄にならなず、ユーザ１人１人のニーズに答えることによって、店の評判もよくなる。
【図面の簡単な説明】
【００６７】
【図１】本発明の一実施例によるレストラン予約時素材代替システムの構成を示すブロック図である。
【図２】図１のレストラン予約サーバ１の構成を示すブロック図である。
【図３】本発明の一実施例によるレストラン予約時素材代替システムの動作を示すシーケンスチャートである。
【図４】本発明の一実施例によるレストラン予約時素材代替システムの動作を示すシーケンスチャートである。
【図５】本発明の一実施例によるレストラン予約時素材代替システムの動作を示すシーケンスチャートである。
【図６】本発明の一実施例によるレストラン予約時素材代替システムの動作を示すシーケンスチャートである。
【図７】本発明の一実施例によるレストラン予約時素材代替システムの動作を示すシーケンスチャートである。
【図８】本発明の一実施例によるレストラン予約時素材代替システムの動作を示すシーケンスチャートである。
【図９】本発明の一実施例によるレストラン予約時素材代替システムの動作を示すシーケンスチャートである。
【図１０】本発明の一実施例によるレストラン予約時素材代替システムの動作を示すシーケンスチャートである。
【図１１】図２の前日余剰材料ＤＢの構成例を示す図である。
【図１２】図２のレストラン情報ＤＢの構成例を示す図である。
【図１３】図２の通常メニューＤＢの構成例を示す図である。
【図１４】図２の代替可能材料ＤＢの構成例を示す図である。
【図１５】本発明の一実施例による「レストランサーチ結果」の一例を示す図である。
【図１６】図２の会員情報ＤＢの構成例を示す図である。
【図１７】本発明の一実施例による「オーダーメニュー選択依頼」の一例を示す図である。
【図１８】図２のオーダ情報ＤＢの構成例を示す図である。
【図１９】本発明の一実施例による「代替希望材料一致のお知らせ」の一例を示す図である。
【図２０】本発明の一実施例による「レストラン予約のお願い」の一例を示す図である。
【図２１】図２のレストラン空席ＤＢの構成例を示す図である。
【図２２】本発明の一実施例による「レストラン予約完了通知」の一例を示す図である。
【図２３】本発明の一実施例による「満席による時間変更のお願い」の一例を示す図である。
【符号の説明】
【００６８】
１ レストラン予約サーバ
２ レストラン端末
３ 利用者端末
１１ 処理装置
１２ メインメモリ
１２ａ 制御プログラム
１３ 通信制御装置
１４ 前日余剰材料データベース
１５ レストラン情報データベース
１６ 通常メニューデータベース
１７ 代替可能材料データベース
１８ 会員情報データベース
１９ オーダ情報データベース
２０ レストラン空席データベース
１００ インタネット
【技術分野】
【０００１】
本発明はレストラン予約時素材代替システム、サーバ装置及びそれらに用いるレストラン予約時素材代替方法並びにそのプログラムに関し、特にレストランの予約を行うための予約システムに関する。
【背景技術】
【０００２】
従来、この種のレストラン予約システムにおいては、レストランの予約を行う際に、席の予約か、予め決まったメニューの予約しか行うことができない。しかしながら、好き嫌い及びアレルギ等によって食べれる材料には個人差があり、そのメニューを予約して頼んでもすべて食すことができないのが現状である。
【０００３】
このメニューの予約に関しては、メニューの予約時に、メニューや写真だけの選択注文ではなく、殖財、カロリー、栄養素等による複数の方法でメニューを選択して注文するシステム（例えば、特許文献１参照）、宗教上の理由で食べられない食材を事前に登録してその食材を使用しない献立をたてる方法（例えば、特許文献２参照）等が提案されている。
【０００４】
【特許文献１】特開２００１−３０６６６６号公報
【特許文献２】特開平０９−０２６９５２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
上述した従来のレストラン予約システムでは、電話やインタネットでのレストラン予約が可能となっているが、席の予約か、もしくはメニュー及びコースの予約しか行うことができない。
【０００６】
メニューの予約では、各個人で好みや好き嫌い、アレルギで食べられない材料もあり、その予め決まっているメニューでも完全に綺麗に食べられずに残すケースも多々存在している。これでは、食材の無駄であり、また提供するレストラン側もお客様に満足して頂けない。また、特にチェーン店のレストランのメニューは全て同一であり、レストラン自体の特徴が薄く、店自体のアピールがない。このような問題は上記の特許文献１，２に記載の技術でも解決することが困難である。
【０００７】
そこで、本発明の目的は上記の問題点を解消し、レストランの前日の余剰、残り、仕入れミスを無駄なく最大限にいかすことができるレストラン予約時素材代替システム、サーバ装置及びそれらに用いるレストラン予約時素材代替方法を提供することにある。
【課題を解決するための手段】
【０００８】
本発明によるレストラン予約時素材代替システムは、レストランに対応して設けられかつそのレストランの各種情報を通知するレストラン端末と、ユーザの情報を通知して前記レストランの予約を行う利用者端末と、前記利用者端末からの前記レストランの予約を受け付けて前記レストラン端末各々にその予約情報を通知するための統括制御を行うサーバ装置とからなるレストラン予約時素材代替システムであって、
前記サーバ装置は、前記利用者端末からの前記レストランの予約の受け付け時に前記利用者端末に既存のメニューとそのメニューに対応する代替可能な素材とを通知する手段と、前記レストラン端末から少なくとも前日の余剰材料が通知された時にその前日の余剰材料を登録するデータベースと、前記代替可能な素材の通知に対する前記利用者端末からの回答を基に当該メニューにおける代替材料を前記データベースから検索する手段と、その検索結果を前記利用者端末に通知する手段とを備えている。
【０００９】
本発明によるサーバ装置は、ユーザの情報を通知してレストランの予約を行う利用者端末からの前記レストランの予約を受け付け、前記レストランに対応して設けられかつそのレストランの各種情報を通知するレストラン端末各々にその予約情報を通知するための統括制御を行うサーバ装置であって、
前記利用者端末からの前記レストランの予約の受け付け時に前記利用者端末に既存のメニューとそのメニューに対応する代替可能な素材とを通知する手段と、前記レストラン端末から少なくとも前日の余剰材料が通知された時にその前日の余剰材料を登録するデータベースと、前記代替可能な素材の通知に対する前記利用者端末からの回答を基に当該メニューにおける代替材料を前記データベースから検索する手段と、その検索結果を前記利用者端末に通知する手段とを備えている。
【００１０】
本発明によるレストラン予約時素材代替方法は、レストランに対応して設けられかつそのレストランの各種情報を通知するレストラン端末と、ユーザの情報を通知して前記レストランの予約を行う利用者端末と、前記利用者端末からの前記レストランの予約を受け付けて前記レストラン端末各々にその予約情報を通知するための統括制御を行うサーバ装置とからなるレストラン予約システムに用いるレストラン予約時素材代替方法であって、
前記サーバ装置が、前記利用者端末からの前記レストランの予約の受け付け時に前記利用者端末に既存のメニューとそのメニューに対応する代替可能な素材とを通知する処理と、前記レストラン端末から少なくとも前日の余剰材料が通知された時にその前日の余剰材料をデータベースに登録する処理と、前記代替可能な素材の通知に対する前記利用者端末からの回答を基に当該メニューにおける代替材料を前記データベースから検索する処理と、その検索結果を前記利用者端末に通知する処理とを実行している。
【００１１】
本発明のプログラムは、レストランに対応して設けられかつそのレストランの各種情報を通知するレストラン端末と、ユーザの情報を通知して前記レストランの予約を行う利用者端末と、前記利用者端末からの前記レストランの予約を受け付けて前記レストラン端末各々にその予約情報を通知するための統括制御を行うサーバ装置とからなるレストラン予約システムにおいて前記サーバ装置によって実行されるプログラムであって、
前記サーバ装置の中央処理装置に、前記利用者端末からの前記レストランの予約の受け付け時に前記利用者端末に既存のメニューとそのメニューに対応する代替可能な素材とを通知する処理と、前記レストラン端末から少なくとも前日の余剰材料が通知された時にその前日の余剰材料をデータベースに登録する処理と、前記代替可能な素材の通知に対する前記利用者端末からの回答を基に当該メニューにおける代替材料を前記データベースから検索する処理と、その検索結果を前記利用者端末に通知する処理とを実行させている。
【００１２】
すなわち、本発明のレストラン予約時素材代替システムは、インタネットを利用して、レストラン業者と利用者とから、前日の余剰等の材料、空席情報、レストラン情報、利用者情報、メニュー情報、代替可能情報等をサーバ装置に送信することによって、既存の用意されたメニューからでも利用者の希望に応じて前日の余剰等の材料によって利用素材を代替することを特徴としている。
【００１３】
サーバ装置は、レストラン業者と利用者とから各種情報を受信すると、それらの情報をＤＢ（データベース）に格納し、利用者のサーチした条件でレストランを洗い出し、利用者との送受信によってレストランの空席情報に応じて当日の来店時間予約後、既存のメニューと代替希望の素材とを選択してもらう。これによって、サーバ装置は、前日の余剰等の材料から適合する代替材料を洗い出し、利用者に通知することが可能となる。利用者は、代替後の素材使用メニューで予約するか否かをサーバ装置に回答することによって、メニューと座席予約とが完了する。
【００１４】
これらの動作によって、本発明のレストラン予約時素材代替システムでは、利用者が好みの素材を使ったオリジナルなメニューを注文することが可能となり、食べ物残しもなくなる。また、レストラン側も利用者のニーズに答えることによって、店の評判もよくなり、材料も無駄にならない。
【００１５】
レストラン側は、当日に前日の残り、余剰、期限切れ近い材料をサーバ装置に登録しておく。これによって、利用者がレストラン予約時も予め決まったメニューを選択し、この時に代替してほしい材料を選択することによって、予めサーバ装置で用意されていた代替品料理ＤＢと、登録した余剰材料等を登録してあるＤＢとを検索し、一致した材料を差し替えることが可能となる。よって、利用者は席の予約と全て自分好みのオリジナリティーにあふれたメニューの予約とを行うことが当日のみ可能となる。
【発明の効果】
【００１６】
本発明は、上記のような構成及び動作とすることで、レストランの前日の余剰、残り、仕入れミスを無駄なく最大限にいかすことができるという効果が得られる。
【発明を実施するための最良の形態】
【００１７】
次に、本発明の実施例について図面を参照して説明する。図１は本発明の一実施例によるレストラン予約時素材代替システムの構成を示すブロック図である。図１において、本発明の一実施例によるレストラン予約時素材代替システムは、レストランの予約を受け付けて各レストランに通知するための統括制御を行うレストラン予約サーバ１と、レストランに対応して設けられかつそのレストランの各種情報を通知するレストラン端末２と、ユーザの情報を通知してレストランの予約を行う利用者端末３とをそれぞれインタネット１００を介して相互に接続して構成されている。尚、レストラン予約サーバ１とレストラン端末２と利用者端末３とをそれぞれ接続するネットワークとしてはインタネット１００以外の通信網であってもよい。
【００１８】
利用者端末３は会員情報の登録及びレストラン予約を行うためにユーザが使用するパ−ソナルコンピュータ（以下、パソコンとする）等の情報処理装置であり、インタネット１００を介してレストラン予約サーバ１に会員情報を送信する。この時、利用者端末３はユーザが新規会員であれば、レストラン予約サーバ１から“会員Ｎｏ”を受信することができる。
【００１９】
また、利用者端末３はレストランの予約時に、「市区町村名」、または「市区町村名」及び「ジャンル」、あるいは「市区町村名」及び「店名」のいずれかを送信し、レストラン予約サーバ１から「レストランサーチ結果（図１５参照）」を受信することができる。この場合、利用者端末３は、その回答として“予約希望レストランＮｏ”と“予約希望時間”と“人数”とをレストラン予約サーバ１へ送信する目的に利用される。
【００２０】
利用者端末３は、空席が“予約希望時間帯”に存在しなかった場合、レストラン予約サーバ１から「満席による時間変更のお願い（図２３参照）」を受信することができる。これによって、利用者端末３では、予約するのであれば“予約可能時間帯”が入力されると、その内容をレストラン予約サーバ１に回答する機能を有している。
【００２１】
空席が存在した場合、利用者端末３はレストラン予約サーバ１から「オーダメニュー選択依頼（図１７参照）」を受信し、予約したいメニューの“選定”欄に数量が、代替したい材料がある場合に“代替希望材料”欄に材料名がそれぞれ入力されると、その内容をレストラン予約サーバ１に回答することができる。
【００２２】
この回答結果によって、利用者端末３はレストラン予約サーバ１から「代替材料一致のお知らせ（図１９参照）」を受信し、そのメニューでよければ“回答”欄に“○”を入力することができる。予約が完了し次第、利用者端末３はレストラン予約サーバ１から「レストラン予約完了通知（図２２参照）」を受信する目的に利用される。
【００２３】
図２は図１のレストラン予約サーバ１の構成を示すブロック図である。図２において、レストラン予約サーバ１は処理装置［ＣＰＵ（中央処理装置）］１１と、処理装置１１が実行する制御プログラム１２ａを格納するメインメモリ１２と、インタネット１００を通して他の装置に接続するための通信制御を行う通信制御装置１３と、前日余剰材料ＤＢ（データベース）１４と、レストラン情報ＤＢ１５と、通常メニューＤＢ１６と、代替可能材料ＤＢ１７と、会員情報ＤＢ１８と、オーダ情報ＤＢ１９と、レストラン空席ＤＢ２０とから構成されている。
【００２４】
処理装置１１はレストラン予約サーバ１内の各部を制御し、インタネット１００を介して利用者端末３から会員情報を受信すると、その会員情報を会員情報ＤＢ１８（図１６参照）に格納する機能を有している。またこの時、利用者端末３のユーザが新規会員であれば、処理装置１１は“会員Ｎｏ“を自動採番し、利用者端末３に送信する機能も有している。
【００２５】
また同様に、処理装置１１は複数のレストラン端末２からレストラン情報、通常メニュー情報、代替可能な材料情報、余剰等材料情報、空席情報を受信し、レストラン情報ＤＢ１５（図１２参照）、通常メニューＤＢ１６（図１３参照）、代替可能材料ＤＢ１７（図１４参照）、前日余剰材料ＤＢ１４（図１１参照）、レストラン空席ＤＢ２０（図２１参照）にそれぞれに格納する機能も有している。
【００２６】
処理装置１１は利用者端末３から予約情報を受信すると、受信した情報でレストラン情報ＤＢ１５の検索を行い、一致した情報を基に「レストランサーチ結果」を自動作成して利用者端末３に送信することができる。また、処理装置１１は「レストランサーチ結果」に対する回答を利用者端末３から受信すると、利用者端末３からの希望時間がレストラン空席ＤＢ２０において満席と判断した場合に前後の時間をサーチし、「満席による時間変更のお願い」を自動作成して利用者端末３へ送信する。
【００２７】
これに対する利用者端末３からの回答を受信すると、処理装置１１は「予約する」の内容であれば、レストラン情報ＤＢ１５から“空き人数”をその予約人数分マイナスして上書き格納する。空席と判断した場合、処理装置１１は、上記と同様に、レストラン情報ＤＢ２０から“空き人数”をその予約人数分マイナスして上書き格納する。
【００２８】
さらに、処理装置１１は、利用者端末３からの回答に記載の“予約希望レストランＮｏ”よりレストラン情報ＤＢ２０と通常メニューＤＢ１６とから「オーダメニュー選択依頼」を自動作成して利用者端末３へ送信する。これに対する回答を利用者端末３から受信すると、処理装置１１はオーダ情報ＤＢ１９（図１８）に格納する機能を有している。
【００２９】
処理装置１１は代替希望材料がある場合、オーダ情報ＤＢ１９及び代替可能材料ＤＢ１７各々の「レストランＮｏ」、「メニューＮｏ」、「代替可能部分」、「代替希望材料」を比較して一致した材料を選択し、前日余剰材料ＤＢ１４から一致した材料が“使用量”分だけ”残量があるかどうかを確認し、これらのデータを基に「代替希望材料一致のお知らせ」を自動作成して利用者端末３へ送信する目的に利用される。
【００３０】
利用者端末３からの「代替希望材料一致のお知らせ」に対する回答を受信すると、処理装置１１はその回答内容をオーダ情報ＤＢ１９に格納する。この時、処理装置１１は代替可能材料ＤＢ１７から使用量を抽出し、前日余剰材料ＤＢ１４から使用量をマイナスし、“残量”欄に上書き格納する。それらのデータの格納後、処理装置１１はオーダ情報ＤＢ１９、会員情報ＤＢ１８、レストラン情報ＤＢ１５の内容を基に「レストラン予約のお願い（図２０参照）」を自動作成してレストラン端末２へ送信すると同時に、「レストラン予約完了通知」も自動作成して利用者端末３へ送信することもできる。
【００３１】
レストラン端末２はレストラン及び通常メニュー、代替可能な材料、余剰、空席の各種情報を登録するユーザが使用するパソコン等の情報処理装置であり、複数のレストラン端末２から構成されている。レストラン端末２各々はインタネット１００を介して、レストラン予約サーバ１にレストラン及び通常メニュー、代替可能な材料、余剰、空席の各種情報を送信する機能を有している。また、レストラン端末２各々はレストラン予約サーバ１からの予約が確定した際に、「レストラン予約のお願い」を受信する目的に利用される。
【００３２】
図３〜図１０は本発明の一実施例によるレストラン予約時素材代替システムの動作を示すシーケンスチャートであり、図１１は図２の前日余剰材料ＤＢ１４の構成例を示す図であり、図１２は図２のレストラン情報ＤＢ１５の構成例を示す図であり、図１３は図２の通常メニューＤＢ１６の構成例を示す図であり、図１４は図２の代替可能材料ＤＢ１７の構成例を示す図であり、図１５は本発明の一実施例による「レストランサーチ結果」の一例を示す図である。
【００３３】
図１６は図２の会員情報ＤＢ１８の構成例を示す図であり、図１７は本発明の一実施例による「オーダーメニュー選択依頼」の一例を示す図であり、図１８は図２のオーダ情報ＤＢ１９の構成例を示す図であり、図１９は本発明の一実施例による「代替希望材料一致のお知らせ」の一例を示す図であり、図２０は本発明の一実施例による「レストラン予約のお願い」の一例を示す図であり、図２１は図２のレストラン空席ＤＢ２０の構成例を示す図であり、図２２は本発明の一実施例による「レストラン予約完了通知」の一例を示す図であり、図２３は本発明の一実施例による「満席による時間変更のお願い」の一例を示す図である。
【００３４】
図１１において、前日余剰材料ＤＢ１４には、レストラン名（「００１Ｒ」、・・・）、日付（「２００５／１２／１３」、・・・）、材料（「とうもろこし」、「オリーブ」、「ハム」、「キャベツ」、「トマト」、・・・）、量（「１Ｋｇ」、「４Ｋｇ」、「３Ｋｇ」、「３０Ｋｇ」、「１５Ｋｇ」、・・・）、残量（「７００ｇ」、「５００ｇ」、「２Ｋｇ」、「２Ｋｇ」、「２Ｋｇ」、・・・）が対応付けられて格納されている。
【００３５】
図１２において、レストラン情報ＤＢ１５には、レストランＮｏ（「００１Ｒ」、「００２Ｒ」、・・・）、市区町村名（「千葉県千葉市美浜区Ａ町」、「千葉県千葉市稲毛区Ａ町」、・・・）、ＴＥＬ（「ＸＸＸ」、・・・）、店名（「ハングリー」、「Ｂ店」、・・・）、ジャンル（「ファミレス」、・・・）、メールアドレス（「ＤＥＮＩ＠ＪＰ」、「ＳＫＹ＠ＪＰ」、・・・）、地図（「ＸＸ」、「」、・・・）、案内（「ＸＸ」、・・・）が対応付けられて格納されている。
【００３６】
図１３において、通常メニューＤＢ１６には、レストランＮｏ（「００１Ｒ」、・・・）、大区分（「ステーキ」、「サラダ」、「汁物」、・・・）、メニューＮｏ（「１」、「２」、「３」、・・・）、メニュー名（「デミグラスハンバーグ」、「マーメイドサラダ」、「ハングリーサラダ」、「トン汁」、・・・）、メニュー写真（「ＸＸ」、・・・）、代替可能部分（「付け合せ」、「トッピング」、「具」、・・・）、代替部分使用材料（「にんじん、エンドウ、ピーマン」、「アスパラ、卵、シーチキン」、「トマト、かいわれ」、「にんじん、ジャガ芋、こんにゃく、肉」、・・・）、価格（「１２００円」、「５００円」、「３００円」、「２００円」、・・・）が対応付けられて格納されている。
【００３７】
図１４において、代替可能材料ＤＢ１７には、レストランＮｏ（「００１Ｒ」、・・・）、メニューＮｏ（「２」、「１」、・・・）、代替可能部分（「トッピング」、「付け合せ」、・・・）、代替部分使用材料（「アスパラ」、「シーチキン」、「卵」、「にんじん」、「エンドウ」、・・・）、代替可能材料（「とうもろこし」、「オリーブ」、「かいわれ」、「キャベツ」、「ブロッコリー」、・・・）、使用量（１人前）（「１００ｇ」、「２００ｇ」、・・・）が対応付けられて格納されている。
【００３８】
図１６において、会員情報ＤＢ１８には、会員Ｎｏ（「Ｎｏ１」、「Ｎｏ２」、「Ｎｏ３」、・・・）、住 所（「ＸＸＸ」、・・・）、氏 名（「かつや」、「りか」、「ゆかり」、・・・）、年齢（「ＸＸ」、・・・）、ＴＥＬ（「ＸＸＸ」、・・・）、メールアドレス（「ＫＡＴＵＹＡ＠ＪＰ」、「ＲＩＫＡ＠ＪＰ」、「ＹＵＫＡＲＩ＠ＪＰ」、・・・）が対応付けられて格納されている。
【００３９】
図１８において、オーダ情報ＤＢ１９には、会員Ｎｏ（「２」、・・・）、レストランＮｏ（「００１Ｒ」、・・・）、日付（「２００５／１２／１３」、・・・）、メニューＮｏ（「２」、「１」、・・・）、メニュー名（「マーメイドサラダ」、「デミグラスハンバーグ」、・・・）、時間（「ＸＸ：ＸＸ」、・・・）、代替可能部分（「トッピング」、「付け合せ」、・・・）、代替希望材料（「アスパラ、卵」、・・・）、代替材料（「とうもろこし、卵」、・・・）、数量（「１」、・・・）が対応付けられて格納されている。
【００４０】
図２１において、レストラン空席ＤＢ２０には、レストランＮｏ（「００１Ｒ」）、日付（「２００５／１２／１３」）、種別（「空席」、・・・）、時間（「１０：００−１１：００」、「１１：００−１２：００」、・・・）、空き人数（「４８人」、「３０人」、・・・）が対応付けられて格納されている。
【００４１】
これら図１〜図２３を参照して本発明の一実施例によるレストラン予約時素材代替システムの動作について説明する。尚、図３〜図１０において、レストラン予約サーバ１の処理動作は処理装置１１が制御プログラム１２ａを実行することで実現される。
【００４２】
利用者端末３（ユーザ名：りか）は、予約をしたい時、会員情報がない場合に、新規に登録しないといけないので、インタネット１００を介して新規会員情報をレストラン予約サーバ１へ送信する（図６のｃ１〜ｃ３）。レストラン予約サーバ１の処理装置１１は新規会員情報を受信すると（図６のａ３１）、会員Ｎｏを自動採番し（図６のａ３２）、“会員Ｎｏ（Ｎｏ２）”とともに会員情報ＤＢ１８に格納する（図６のａ３３）。処理装置１１はそれらの情報を格納した後、採番した“会員Ｎｏ（Ｎｏ２）”を利用者端末３（ユーザ名：りか）へ送信する（図６のａ３４）。
【００４３】
利用者端末３（ユーザ名：りか）は、新規採番した“会員Ｎｏ（Ｎｏ２）”を受信すると（図６のｃ４）、自身の会員Ｎｏが“会員Ｎｏ（Ｎｏ２）”であることを認識する。この場合、その“会員Ｎｏ（Ｎｏ２）”を利用者端末３（ユーザ名：りか）内に記憶してもよい。
【００４４】
複数のレストラン端末２は、新規にレストラン情報を登録する場合、インタネット１００を介して新規レストラン情報をレストラン予約サーバ１へ送信する（図３のｂ１，ｂ２）。レストラン予約サーバ１の処理装置１１は、新規レストラン情報を受信すると（図３のａ１）、レストランＮｏを自動採番し（図３のａ２）、“レストランＮｏ”とともにレストラン情報ＤＢ１５に格納する（図３のａ３）。
【００４５】
また、複数のレストラン端末２は、上記と同様に、新規の通常メニューがある場合、インタネット１００を介して新規通常メニュー情報をレストラン予約サーバ１へ送信する（図３のｂ３，ｂ４）。レストラン予約サーバ１の処理装置１１は、新規通常メニュー情報を受信すると（図３のａ４）、“メニューＮｏ”を自動採番し（図３のａ５）、レストラン情報ＤＢ１５への格納時に採番した“レストランＮｏ”とともに通常メニューＤＢ１６（図１３に示す形式）に格納する（図３のａ６〜ａ８）。
【００４６】
さらに、レストラン端末２は格納した通常メニューＤＢ１６に対する新規代替可能な部分及び材料情報をインタネット１００を介してレストラン予約サーバ１に送信する（図４のｂ５，ｂ６）。レストラン予約サーバ１の処理装置１１は、新規代替可能な部分及び材料情報を受信すると（図４のａ９）、レストラン情報ＤＢ１５（図１２に示す形式）への格納時に採番した“レストランＮｏ”及び通常メニューＤＢ１６への格納時に採番した“メニューＮｏ“とともに代替可能材料ＤＢ１７（図１４に示す形式）に格納する（図４のａ１０〜ａ１４）。
【００４７】
複数のレストラン端末２は、当日に前日の材料に余剰、残り、仕入れミス等がある場合、インタネット１０を介して材料情報をレストラン予約サーバ１に送信し（図４のｂ７，ｂ８）、これと同時に、当日の空席情報もレストラン予約サ―バ１に送信する（図５のｂ９，ｂ１０）。レストラン予約サーバ１の処理装置１１は、材料情報をレストラン情報ＤＢ１５に格納した時に採番した“レストランＮｏ”とともに、前日余剰材料ＤＢ１４（図１１に示す形式）に格納し（図４のａ１５〜ａ１８）、また空席情報は“レストランＮｏ”毎にレストラン空席ＤＢ２０（図２１に示す形式）に格納する（図５のａ１９〜ａ２２）。
【００４８】
利用者端末３（ユーザ名：りか）は、レストランの予約をしたい時、インタネット１００を介してレストラン予約サーバ１に予約したいレストランをサーチするために「市区町村名」、または「市区町村名」及び「ジャンル」、あるいは「市区町村名」及び「店名」のいずれかのサーチ情報を送信する（図６のｃ５）。以下の説明では、例えば、「市区町村名」＝千葉県千葉市美浜区Ａ町、「ジャンル」＝ファミレスのサーチ情報を送信するものとする。
【００４９】
レストラン予約サーバ１の処理装置１１は、サーチ情報を受信すると（図６のａ３５）、条件（「市区町村名」＝千葉県千葉市美浜区Ａ町、「ジャンル」＝ファミレス）でレストラン情報ＤＢ１５から“市区町村名”、“ジャンル”をサーチし（図６のａ３６）、選択した“地図（図）”、“案内”を基に「レストランサーチ結果（図１５に示す形式）」で自動作成し（図６のａ３７）、利用者端末３（ユーザ名：りか）のメールアドレスに送信すると同時に、ＷＥＢで閲覧できるように掲載する（図６のａ３８）。上記のサーチにおいては、「市区町村名＝“千葉県千葉市美浜区Ａ町”」、「ジャンル＝“ファミレス”」で行われている。
【００５０】
利用者端末３（ユーザ名：りか）は、「レストランサーチ結果」を受信すると（図６のｃ６）、回答欄に“予約希望レストランＮｏ（００１Ｒ）“、”予約希望時間（１０：００−１１：００）“、”人数（２人）“を入力し、レストラン予約サーバ１に送信する（図７のｃ７）。
【００５１】
レストラン予約サーバ１の処理装置１１は、利用者端末３（ユーザ名：りか）から「レストランサーチ結果」の回答を受信すると（図７のａ３９）、「回答欄」に記載の“予約希望レストランＮｏ：００１Ｒ”及び“予約希望時刻：１０：００−１１：００”と、レストラン空席ＤＢ２０の“レストランＮｏ（００１Ｒ）”及び“時間（１０：００−１１：００）”とを比較し、一致したレコードの“種別”をみて以下の処理を行う。
【００５２】
パターン１：“種別“＝満席の場合（図７のａ４１）、処理装置１１は、“時間（１０：００−１１：００）”前後周辺で最も指定された時間の近いレコードの“種別（空席）”レコードの“時間”を抽出し（図７のａ４２）、「満席による時間変更のお願い（図２３参照）」を自動作成し（図７のａ４３）、利用者端末３（ユーザ名：りか）のメールアドレスへ送信すると同時に、ＷＥＢで閲覧できるように掲載する（図７のａ４４）。この時、締切り時間は、一番早い“予約可能時間”の一定の時間前とする（今回の場合は、１時間前とする）。
【００５３】
利用者端末３（ユーザ名：りか）は、「満席による時間変更のお願い」をメールにて受信、もしくはＷＥＢより閲覧すると（図７のｃ９）、締切り時間までに回答欄に予約する場合に（１．予約する）に予約時間を選択して入力し、予約しない場合に（２．予約しない）にチェックし、回答をレストラン予約サーバ１に送信する（図７のｃ１０，ｃ１１）。
【００５４】
レストラン予約サーバ１の処理装置１１は、締切り時間までに回答を受信すると（図７のａ４５，ａ４６）、回答欄が（１．予約する）の回答のみ“予約希望レストランＮｏ：００１Ｒ”及び回答欄に記載の“予約希望時刻：１０：００−１１：００”と、レストラン空席ＤＢ２０の“レストランＮｏ（００１Ｒ）”及び“時間（１０：００−１１：００）”とを比較し（図７のａ４７，図８のａ５０，ａ５１）、“空き人数（４８人）”を抽出し、「回答欄」記載の“人数：２人”をマイナスする（４８人−２人＝４６人）（図８のａ５２）。この計算によって４６人分の空席がこの時間帯に存在することが分かるので、処理装置１１は、“空き人数”を更新し、４８人より４６人にレコードを書き換える（図８のａ５３）。レストラン予約サーバ１は上記の締切り時間が経過した時点で回答受信を拒否する。
【００５５】
パターン２：“種別”＝空席の場合（図７のａ４１）、処理装置１１は、“空人数（４８人）”を抽出し、「回答欄」記載の“人数：２人”をマイナスする（４８人−２人＝４６人）（図７のａ４８）。この計算によって４６人分の空席がこの時間帯に存在することが分かるので、処理装置１１は、“空き人数”を更新し、４８人より４６人にレコードを書き換える（図７のａ４９）。
【００５６】
パターン１，２以降の処理の場合、処理装置１１は、「回答欄」に記載の“予約希望レストランＮｏ：００１Ｒ”を、レストラン情報ＤＢ１５から“レストランＮｏ（００１Ｒ）”でレコードを抽出し（図８のａ５４）、またこれと同様に、通常メニューＤＢ１６から“レストランＮｏ（００１Ｒ）”のレコードも抽出する（図８のａ５５）。さらに、処理装置１１は、これらのレコードを基に「オーダメニュー選択依頼（図１７参照）」を自動作成し（図８のａ５６）、利用者端末３（ユーザ名：りか）のメールアドレスへ送信すると同時に、ＷＥＢで閲覧できるように掲載する（図８のａ５７）。
【００５７】
利用者端末３（ユーザ名：りか）は、「オーダメニュー選択依頼」をメールにて受信、もしくはＷＥＢより閲覧すると（図８のｃ１２）、“選定欄”に注文数量を入力し、“代替部分使用材料欄”に苦手、もしくは気に入らない材料があったらその材料を“代替部分利用材料”から抽出し、“代替希望材料欄”に入力し、これらの入力後、レストラン予約サーバ１にメールにて送信、またはＷＥＢにて回答を行う（図８のｃ１３）。
【００５８】
レストラン予約サーバ１の処理装置１１は、利用者端末３（ユーザ名：りか）から「オーダメニュー選択依頼」の回答を受信すると（図８のａ５８）、オーダ情報ＤＢ１９（図１８に示す形式）に当日の日付とともに格納する（図８のａ５９）。さらに、処理装置１１は、“代替希望材料”欄に代替希望がある場合、“代替材料”指定のオーダ情報ＤＢ１９の“レストランＮｏ（００１Ｒ）“、”メニューＮｏ（２）“、”代替可能部分（トッピング）“、”代替希望材料（アスパラ、卵）“と、代替可能材料ＤＢ１７の“レストランＮｏ（００１Ｒ）“、”メニューＮｏ（２）“、”代替可能部分（トッピング）“、”代替部分使用材料（アスパラ、卵）“とを照合し、一致した”代替可能材料（アスパラ：とうもろこし、卵：かいわれ）“と”使用量（１人前）（１００Ｇずつ）“を代替可能材料ＤＢ１７から選択する（図８のａ６０，ａ６１）。
【００５９】
選択後、処理装置１１は、“代替可能材料（アスパラ：とうもろこし、卵：かいわれ）”が前日余剰材料ＤＢ１４の“レストランＮｏ（００１Ｒ）”の当日の日付の全てのレコードの“材料”と比較し、一致した材料（とうもろこし、かいわれ）で“残量”があり、かつ代替可能材料ＤＢ１７から選択した“使用量（１人前）（１００ｇずつ）”以上の“材料（アスパラ：とうもろこし（残量＝７００ｇ、卵：かいわれ（無し））”を前日余剰材料ＤＢ１４から抽出する（図９のａ６２）。抽出後、処理装置１１は、「代替希望材料一致のお知らせ（図１９に示す形式）」をオーダ情報ＤＢ１９、代替可能材料ＤＢ１７から自動作成し（図９のａ６３）、利用者端末３（ユーザ名：りか）のメールアドレスへ送信すると同時に、ＷＥＢで閲覧できるように掲載する（図９のａ６４）。
【００６０】
利用者端末３（ユーザ名：りか）は、「代替希望材料一致のお知らせ（図１９参照）」を受信すると（図９のｃ１５）、“回答”欄に“代替希望材料”が“代替可能材料”（アスパラ→とうもろこし、卵→代替なし）で注文するのであれば「○」の入力を、注文しないのであれば「×」の入力を行い、レストラン予約サーバ１へ送信、またはＷＥＢにて回答を行う（図９のｃ１６）。
【００６１】
レストラン予約サーバ１の処理装置１１は、回答を受信すると（図９のａ６５）、「代替希望材料一致のお知らせ（図１９参照）」の“代替可能材料”欄を、“会員Ｎｏ”、“レストランＮｏ”、“メニューＮｏ“をキーにしてオーダ情報ＤＢ１９の“代替材料”欄に格納する（図９のａ６６）。またこの時、処理装置１１は、代替可能材料ＤＢ１７を“レストランＮｏ（００１Ｒ）”、“メニューＮｏ（２）”、“代替可能部分（トッピング）“、”代替部分使用材料（アスパラ）“で検索し、一致した”使用量（１人前）（１００ｇ）“を抽出する（図９のａ６７）。
【００６２】
さらに、処理装置１１は、前日余剰材料ＤＢ１４の“レストランＮｏ”を“００１Ｒ”及び“材料”を“とうもろこし”で抽出し（図９のａ６８）、一致したレコードの残量（７００ｇ）から、代替可能材料ＤＢ１７で選択した”使用量（１人前）（１００ｇ）“を引いた量”６００ｇ“を残量として、前日余剰材料ＤＢ１４の”残量“欄を上書き格納する（図９のａ６９，ａ７０）。
【００６３】
処理装置１１は、オーダ情報ＤＢ１９、会員情報ＤＢ１８、レストラン情報ＤＢ１５の内容を基に「レストラン予約のお願い（図２０参照）」、「レストラン予約完了通知（図２２参照）」をそれぞれ自動作成し（図９のａ７１〜ａ７４，図１０のａ７５）、レストラン端末２（レストラン名：ハングリー）、利用者端末３（ユーザ名：りか）のメールアドレスへ送信すると同時に、ＷＥＢで閲覧できるように掲載する（図１０のａ７６，ａ７７）。
【００６４】
レストラン端末２（レストラン名：ハングリー）は、「レストラン予約のお願い」を受信すると（図１０のｂ１１）、当日の利用者端末３（ユーザ名：りか）の来店時間、来店時予約メニュー、代替材料メニューを認識して予約を入れ、予約時間まで準備をしておくことができる。また、利用者端末３（ユーザ名：りか）は、「レストランレストラ完了通知」を受信した当日の予約した時間にレストランへ行き、苦手や好みでない食材がその日の材料で代替可能になるので、自由に選択することができ、食べ残しもなくなる。
【００６５】
このように、本実施例では、レストランの前日の、余剰、残り、仕入れミスを無駄なく最大限にいかすことができる。また、本実施例では、ユーザが苦手な食材をレストランの前日の余剰等に応じて好みの食材へ変更することができるので、食べ残しがなくなる。
【００６６】
さらに、本実施例では、レストラン独自のメニューが食材の代替によってできるので、店のアピールにも繋がり、余剰、残り、仕入れミス素材が無駄にならなず、ユーザ１人１人のニーズに答えることによって、店の評判もよくなる。
【図面の簡単な説明】
【００６７】
【図１】本発明の一実施例によるレストラン予約時素材代替システムの構成を示すブロック図である。
【図２】図１のレストラン予約サーバ１の構成を示すブロック図である。
【図３】本発明の一実施例によるレストラン予約時素材代替システムの動作を示すシーケンスチャートである。
【図４】本発明の一実施例によるレストラン予約時素材代替システムの動作を示すシーケンスチャートである。
【図５】本発明の一実施例によるレストラン予約時素材代替システムの動作を示すシーケンスチャートである。
【図６】本発明の一実施例によるレストラン予約時素材代替システムの動作を示すシーケンスチャートである。
【図７】本発明の一実施例によるレストラン予約時素材代替システムの動作を示すシーケンスチャートである。
【図８】本発明の一実施例によるレストラン予約時素材代替システムの動作を示すシーケンスチャートである。
【図９】本発明の一実施例によるレストラン予約時素材代替システムの動作を示すシーケンスチャートである。
【図１０】本発明の一実施例によるレストラン予約時素材代替システムの動作を示すシーケンスチャートである。
【図１１】図２の前日余剰材料ＤＢの構成例を示す図である。
【図１２】図２のレストラン情報ＤＢの構成例を示す図である。
【図１３】図２の通常メニューＤＢの構成例を示す図である。
【図１４】図２の代替可能材料ＤＢの構成例を示す図である。
【図１５】本発明の一実施例による「レストランサーチ結果」の一例を示す図である。
【図１６】図２の会員情報ＤＢの構成例を示す図である。
【図１７】本発明の一実施例による「オーダーメニュー選択依頼」の一例を示す図である。
【図１８】図２のオーダ情報ＤＢの構成例を示す図である。
【図１９】本発明の一実施例による「代替希望材料一致のお知らせ」の一例を示す図である。
【図２０】本発明の一実施例による「レストラン予約のお願い」の一例を示す図である。
【図２１】図２のレストラン空席ＤＢの構成例を示す図である。
【図２２】本発明の一実施例による「レストラン予約完了通知」の一例を示す図である。
【図２３】本発明の一実施例による「満席による時間変更のお願い」の一例を示す図である。
【符号の説明】
【００６８】
１ レストラン予約サーバ
２ レストラン端末
３ 利用者端末
１１ 処理装置
１２ メインメモリ
１２ａ 制御プログラム
１３ 通信制御装置
１４ 前日余剰材料データベース
１５ レストラン情報データベース
１６ 通常メニューデータベース
１７ 代替可能材料データベース
１８ 会員情報データベース
１９ オーダ情報データベース
２０ レストラン空席データベース
１００ インタネット
【特許請求の範囲】
【請求項１】
レストランに対応して設けられかつそのレストランの各種情報を通知するレストラン端末と、ユーザの情報を通知して前記レストランの予約を行う利用者端末と、前記利用者端末からの前記レストランの予約を受け付けて前記レストラン端末各々にその予約情報を通知するための統括制御を行うサーバ装置とからなるレストラン予約時素材代替システムであって、
前記サーバ装置は、前記利用者端末からの前記レストランの予約の受け付け時に前記利用者端末に既存のメニューとそのメニューに対応する代替可能な素材とを通知する手段と、前記レストラン端末から少なくとも前日の余剰材料が通知された時にその前日の余剰材料を登録するデータベースと、前記代替可能な素材の通知に対する前記利用者端末からの回答を基に当該メニューにおける代替材料を前記データベースから検索する手段と、その検索結果を前記利用者端末に通知する手段とを有することを特徴とするレストラン予約時素材代替システム。
【請求項２】
前記レストラン端末は、前記前日の余剰材料、空席情報、メニュー情報、代替可能な素材の情報を少なくとも前記サーバ装置に送信し、
前記利用者端末は、利用者情報と予約の指定日時と希望するレストラン情報とを少なくとも前記サーバ装置に送信し、
前記サーバ装置は、前記既存メニューの利用素材を、前記利用者端末からの希望情報に応じて前記前日の余剰材料によって代替することを前記レストラン端末に通知することを特徴とする請求項１記載のレストラン予約時素材代替システム。
【請求項３】
前記利用者端末は、代替後の素材使用メニューで予約するか否かを前記サーバ装置に回答することを特徴とする請求項１または請求項２記載のレストラン予約時素材代替システム。
【請求項４】
前記レストラン端末は、前日の残り、余剰、期限切れ近い材料を少なくとも前記サーバ装置に登録することを特徴とする請求項１から請求項３のいずれか記載のレストラン予約時素材代替システム。
【請求項５】
前記サーバ装置は、前記利用者端末によるレストラン予約時に選択したメニューにおいて代替してほしい材料が選択された時、予め用意されている代替メニューと前記レストラン端末から登録された余剰材料とを比較して一致した材料で当該メニューの材料を差し替えることを特徴とする請求項４記載のレストラン予約時素材代替システム。
【請求項６】
前記サーバ装置と前記レストラン端末と前記利用者端末とをネットワークを介して相互に接続することを特徴とする請求項１から請求項５のいずれか記載のレストラン予約時素材代替システム。
【請求項７】
ユーザの情報を通知してレストランの予約を行う利用者端末からの前記レストランの予約を受け付け、前記レストランに対応して設けられかつそのレストランの各種情報を通知するレストラン端末各々にその予約情報を通知するための統括制御を行うサーバ装置であって、
前記利用者端末からの前記レストランの予約の受け付け時に前記利用者端末に既存のメニューとそのメニューに対応する代替可能な素材とを通知する手段と、前記レストラン端末から少なくとも前日の余剰材料が通知された時にその前日の余剰材料を登録するデータベースと、前記代替可能な素材の通知に対する前記利用者端末からの回答を基に当該メニューにおける代替材料を前記データベースから検索する手段と、その検索結果を前記利用者端末に通知する手段とを有することを特徴とするサーバ装置。
【請求項８】
前記レストラン端末から、前記前日の余剰材料、空席情報、メニュー情報、代替可能な素材の情報が少なくとも通知され、
前記利用者端末から、利用者情報と予約の指定日時と希望するレストラン情報とが少なくとも通知された時に、前記既存メニューの利用素材を、前記利用者端末からの希望情報に応じて前記前日の余剰材料によって代替することを前記レストラン端末に通知することを特徴とする請求項７記載のサーバ装置。
【請求項９】
前記利用者端末からの回答として、代替後の素材使用メニューで予約するか否かが通知されることを特徴とする請求項７または請求項８記載のサーバ装置。
【請求項１０】
前記レストラン端末からの前日の残り、余剰、期限切れ近い材料を少なくとも登録することを特徴とする請求項７から請求項９のいずれか記載のサーバ装置。
【請求項１１】
前記利用者端末によるレストラン予約時に選択したメニューにおいて代替してほしい材料が選択された時、予め用意されている代替メニューと前記レストラン端末から登録された余剰材料とを比較して一致した材料で当該メニューの材料を差し替えることを特徴とする請求項１０記載のサーバ装置。
【請求項１２】
前記レストラン端末と前記利用者端末とに対してネットワークを介して相互に接続することを特徴とする請求項７から請求項１１のいずれか記載のサーバ装置。
【請求項１３】
レストランに対応して設けられかつそのレストランの各種情報を通知するレストラン端末と、ユーザの情報を通知して前記レストランの予約を行う利用者端末と、前記利用者端末からの前記レストランの予約を受け付けて前記レストラン端末各々にその予約情報を通知するための統括制御を行うサーバ装置とからなるレストラン予約システムに用いるレストラン予約時素材代替方法であって、
前記サーバ装置が、前記利用者端末からの前記レストランの予約の受け付け時に前記利用者端末に既存のメニューとそのメニューに対応する代替可能な素材とを通知する処理と、前記レストラン端末から少なくとも前日の余剰材料が通知された時にその前日の余剰材料をデータベースに登録する処理と、前記代替可能な素材の通知に対する前記利用者端末からの回答を基に当該メニューにおける代替材料を前記データベースから検索する処理と、その検索結果を前記利用者端末に通知する処理とを実行することを特徴とするレストラン予約時素材代替方法。
【請求項１４】
前記レストラン端末が、前記前日の余剰材料、空席情報、メニュー情報、代替可能な素材の情報を少なくとも前記サーバ装置に送信し、
前記利用者端末が、利用者情報と予約の指定日時と希望するレストラン情報とを少なくとも前記サーバ装置に送信し、
前記サーバ装置が、前記既存メニューの利用素材を、前記利用者端末からの希望情報に応じて前記前日の余剰材料によって代替することを前記レストラン端末に通知することを特徴とする請求項１３記載のレストラン予約時素材代替方法。
【請求項１５】
前記利用者端末が、代替後の素材使用メニューで予約するか否かを前記サーバ装置に回答することを特徴とする請求項１３または請求項１４記載のレストラン予約時素材代替方法。
【請求項１６】
前記レストラン端末が、前日の残り、余剰、期限切れ近い材料を少なくとも前記サーバ装置に登録することを特徴とする請求項１３から請求項１５のいずれか記載のレストラン予約時素材代替方法。
【請求項１７】
前記サーバ装置が、前記利用者端末によるレストラン予約時に選択したメニューにおいて代替してほしい材料が選択された時、予め用意されている代替メニューと前記レストラン端末から登録された余剰材料とを比較して一致した材料で当該メニューの材料を差し替えることを特徴とする請求項１６記載のレストラン予約時素材代替方法。
【請求項１８】
前記サーバ装置と前記レストラン端末と前記利用者端末とをネットワークを介して相互に接続することを特徴とする請求項１３から請求項１７のいずれか記載のレストラン予約時素材代替方法。
【請求項１９】
レストランに対応して設けられかつそのレストランの各種情報を通知するレストラン端末と、ユーザの情報を通知して前記レストランの予約を行う利用者端末と、前記利用者端末からの前記レストランの予約を受け付けて前記レストラン端末各々にその予約情報を通知するための統括制御を行うサーバ装置とからなるレストラン予約システムにおいて前記サーバ装置によって実行されるプログラムであって、
前記サーバ装置の中央処理装置に、前記利用者端末からの前記レストランの予約の受け付け時に前記利用者端末に既存のメニューとそのメニューに対応する代替可能な素材とを通知する処理と、前記レストラン端末から少なくとも前日の余剰材料が通知された時にその前日の余剰材料をデータベースに登録する処理と、前記代替可能な素材の通知に対する前記利用者端末からの回答を基に当該メニューにおける代替材料を前記データベースから検索する処理と、その検索結果を前記利用者端末に通知する処理とを実行させるためのプログラム。
【請求項１】
レストランに対応して設けられかつそのレストランの各種情報を通知するレストラン端末と、ユーザの情報を通知して前記レストランの予約を行う利用者端末と、前記利用者端末からの前記レストランの予約を受け付けて前記レストラン端末各々にその予約情報を通知するための統括制御を行うサーバ装置とからなるレストラン予約時素材代替システムであって、
前記サーバ装置は、前記利用者端末からの前記レストランの予約の受け付け時に前記利用者端末に既存のメニューとそのメニューに対応する代替可能な素材とを通知する手段と、前記レストラン端末から少なくとも前日の余剰材料が通知された時にその前日の余剰材料を登録するデータベースと、前記代替可能な素材の通知に対する前記利用者端末からの回答を基に当該メニューにおける代替材料を前記データベースから検索する手段と、その検索結果を前記利用者端末に通知する手段とを有することを特徴とするレストラン予約時素材代替システム。
【請求項２】
前記レストラン端末は、前記前日の余剰材料、空席情報、メニュー情報、代替可能な素材の情報を少なくとも前記サーバ装置に送信し、
前記利用者端末は、利用者情報と予約の指定日時と希望するレストラン情報とを少なくとも前記サーバ装置に送信し、
前記サーバ装置は、前記既存メニューの利用素材を、前記利用者端末からの希望情報に応じて前記前日の余剰材料によって代替することを前記レストラン端末に通知することを特徴とする請求項１記載のレストラン予約時素材代替システム。
【請求項３】
前記利用者端末は、代替後の素材使用メニューで予約するか否かを前記サーバ装置に回答することを特徴とする請求項１または請求項２記載のレストラン予約時素材代替システム。
【請求項４】
前記レストラン端末は、前日の残り、余剰、期限切れ近い材料を少なくとも前記サーバ装置に登録することを特徴とする請求項１から請求項３のいずれか記載のレストラン予約時素材代替システム。
【請求項５】
前記サーバ装置は、前記利用者端末によるレストラン予約時に選択したメニューにおいて代替してほしい材料が選択された時、予め用意されている代替メニューと前記レストラン端末から登録された余剰材料とを比較して一致した材料で当該メニューの材料を差し替えることを特徴とする請求項４記載のレストラン予約時素材代替システム。
【請求項６】
前記サーバ装置と前記レストラン端末と前記利用者端末とをネットワークを介して相互に接続することを特徴とする請求項１から請求項５のいずれか記載のレストラン予約時素材代替システム。
【請求項７】
ユーザの情報を通知してレストランの予約を行う利用者端末からの前記レストランの予約を受け付け、前記レストランに対応して設けられかつそのレストランの各種情報を通知するレストラン端末各々にその予約情報を通知するための統括制御を行うサーバ装置であって、
前記利用者端末からの前記レストランの予約の受け付け時に前記利用者端末に既存のメニューとそのメニューに対応する代替可能な素材とを通知する手段と、前記レストラン端末から少なくとも前日の余剰材料が通知された時にその前日の余剰材料を登録するデータベースと、前記代替可能な素材の通知に対する前記利用者端末からの回答を基に当該メニューにおける代替材料を前記データベースから検索する手段と、その検索結果を前記利用者端末に通知する手段とを有することを特徴とするサーバ装置。
【請求項８】
前記レストラン端末から、前記前日の余剰材料、空席情報、メニュー情報、代替可能な素材の情報が少なくとも通知され、
前記利用者端末から、利用者情報と予約の指定日時と希望するレストラン情報とが少なくとも通知された時に、前記既存メニューの利用素材を、前記利用者端末からの希望情報に応じて前記前日の余剰材料によって代替することを前記レストラン端末に通知することを特徴とする請求項７記載のサーバ装置。
【請求項９】
前記利用者端末からの回答として、代替後の素材使用メニューで予約するか否かが通知されることを特徴とする請求項７または請求項８記載のサーバ装置。
【請求項１０】
前記レストラン端末からの前日の残り、余剰、期限切れ近い材料を少なくとも登録することを特徴とする請求項７から請求項９のいずれか記載のサーバ装置。
【請求項１１】
前記利用者端末によるレストラン予約時に選択したメニューにおいて代替してほしい材料が選択された時、予め用意されている代替メニューと前記レストラン端末から登録された余剰材料とを比較して一致した材料で当該メニューの材料を差し替えることを特徴とする請求項１０記載のサーバ装置。
【請求項１２】
前記レストラン端末と前記利用者端末とに対してネットワークを介して相互に接続することを特徴とする請求項７から請求項１１のいずれか記載のサーバ装置。
【請求項１３】
レストランに対応して設けられかつそのレストランの各種情報を通知するレストラン端末と、ユーザの情報を通知して前記レストランの予約を行う利用者端末と、前記利用者端末からの前記レストランの予約を受け付けて前記レストラン端末各々にその予約情報を通知するための統括制御を行うサーバ装置とからなるレストラン予約システムに用いるレストラン予約時素材代替方法であって、
前記サーバ装置が、前記利用者端末からの前記レストランの予約の受け付け時に前記利用者端末に既存のメニューとそのメニューに対応する代替可能な素材とを通知する処理と、前記レストラン端末から少なくとも前日の余剰材料が通知された時にその前日の余剰材料をデータベースに登録する処理と、前記代替可能な素材の通知に対する前記利用者端末からの回答を基に当該メニューにおける代替材料を前記データベースから検索する処理と、その検索結果を前記利用者端末に通知する処理とを実行することを特徴とするレストラン予約時素材代替方法。
【請求項１４】
前記レストラン端末が、前記前日の余剰材料、空席情報、メニュー情報、代替可能な素材の情報を少なくとも前記サーバ装置に送信し、
前記利用者端末が、利用者情報と予約の指定日時と希望するレストラン情報とを少なくとも前記サーバ装置に送信し、
前記サーバ装置が、前記既存メニューの利用素材を、前記利用者端末からの希望情報に応じて前記前日の余剰材料によって代替することを前記レストラン端末に通知することを特徴とする請求項１３記載のレストラン予約時素材代替方法。
【請求項１５】
前記利用者端末が、代替後の素材使用メニューで予約するか否かを前記サーバ装置に回答することを特徴とする請求項１３または請求項１４記載のレストラン予約時素材代替方法。
【請求項１６】
前記レストラン端末が、前日の残り、余剰、期限切れ近い材料を少なくとも前記サーバ装置に登録することを特徴とする請求項１３から請求項１５のいずれか記載のレストラン予約時素材代替方法。
【請求項１７】
前記サーバ装置が、前記利用者端末によるレストラン予約時に選択したメニューにおいて代替してほしい材料が選択された時、予め用意されている代替メニューと前記レストラン端末から登録された余剰材料とを比較して一致した材料で当該メニューの材料を差し替えることを特徴とする請求項１６記載のレストラン予約時素材代替方法。
【請求項１８】
前記サーバ装置と前記レストラン端末と前記利用者端末とをネットワークを介して相互に接続することを特徴とする請求項１３から請求項１７のいずれか記載のレストラン予約時素材代替方法。
【請求項１９】
レストランに対応して設けられかつそのレストランの各種情報を通知するレストラン端末と、ユーザの情報を通知して前記レストランの予約を行う利用者端末と、前記利用者端末からの前記レストランの予約を受け付けて前記レストラン端末各々にその予約情報を通知するための統括制御を行うサーバ装置とからなるレストラン予約システムにおいて前記サーバ装置によって実行されるプログラムであって、
前記サーバ装置の中央処理装置に、前記利用者端末からの前記レストランの予約の受け付け時に前記利用者端末に既存のメニューとそのメニューに対応する代替可能な素材とを通知する処理と、前記レストラン端末から少なくとも前日の余剰材料が通知された時にその前日の余剰材料をデータベースに登録する処理と、前記代替可能な素材の通知に対する前記利用者端末からの回答を基に当該メニューにおける代替材料を前記データベースから検索する処理と、その検索結果を前記利用者端末に通知する処理とを実行させるためのプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【公開番号】特開２００７−３１６７８１（Ｐ２００７−３１６７８１Ａ）
【公開日】平成１９年１２月６日（２００７．１２．６）
【国際特許分類】
【出願番号】特願２００６−１４３４６６（Ｐ２００６−１４３４６６）
【出願日】平成１８年５月２４日（２００６．５．２４）
【出願人】（０００２３２１４０）ＮＥＣフィールディング株式会社 (373)
【公開日】平成１９年１２月６日（２００７．１２．６）
【国際特許分類】
【出願日】平成１８年５月２４日（２００６．５．２４）
【出願人】（０００２３２１４０）ＮＥＣフィールディング株式会社 (373)
[ Back to top ]