JP2007102525A - 混雑予想システム、混雑予想サーバー、混雑予想方法、及びプログラム - Google Patents

Abstract

【課題】開催日付にどれだけの入場があるのか時間別に予想する事で、混雑予想時の臨時増員雇用の人員配置及び混雑していない場合の人員の削減等に役立てる。
【解決手段】本発明では、複数のレストラン業者端末（１０）は、オーダー時にオーダリングターミナルにてサーバー（２０）に顧客情報を送信する。イベント開催者端末（３０）は、イベント開催日時が決定次第、サーバー（２０）に開催情報を送信する。サーバー（２０）は、過去のイベント開催履歴情報とレストラン顧客情報を蓄積しており、開催予定のイベント、及び、その周辺にあるレストラン業者端末（１０）がどれだけ混雑するかもデータ解析をして予想する。それぞれの予想した結果を一覧表にして、イベント開催者端末（３０）及びレストラン業者端末（１０）へ送信する。
【選択図】図１

Description

本発明は、イベント時におけるレストランの混雑を予想する混雑予想システム、混雑予想サーバー、混雑予想方法、及びプログラムに関する。

従来、イベント開催時のイベントの混雑度は、日付、曜日、イベント内容等に対して変動するものであり、予測が難しくイベント開催業者側の勘にまかされている事が多かった。また、周辺のレストラン業者も周辺のイベント開催施設の開催情報を入手するか、おおよその過去の経験の勘に頼っている部分が多くそれに応じて、材料の入手、従業員の増員等を行っていた。しかし、これでは人の手による判断のため、個人により異なってしまい、人員を増員したのに入場者が少ないケースや、材料を多く仕入れたのにも関わらず無駄にしてしまうケースも多々あった。

関連する技術として、特開２００２−１６９９１７号公報に「人員誘導システム」が開示されている。
この人員誘導システムは、中央管理装置と、複数の集客施設と、端末装置とを備える。前記中央管理装置は、空席又は在庫情報収集・管理サブシステムと混雑又は販売予測サブシステムと誘導サブシステムとを有する。前記複数の集客施設は、コンピュータ通信ネットワークによって前記空席又は在庫情報収集・管理サブシステムに空席又は在庫情報を提供する。前記端末装置は、前記コンピュータ通信ネットワークにより前記誘導サブシステムにアクセス可能な端末装置である。
この人員誘導システムでは、前記集客施設から提供された各空席又は在庫データを前記空席又は在庫情報収集・管理システムで管理するとともに、この空席又は在庫データを前記混雑又は販売予測サブシステムに提供する。前記混雑又は販売予測サブシステムは前記空席又は在庫データに基づき所定時間後の混雑又は販売予測データを演算して該混雑又は販売予測データを誘導サブシステムに提供する。前記誘導サブシステムは、集客施設の混雑又は販売予測データに基づき、集客施設への誘導データを演算して該誘導データを前記端末装置に提供する事を特徴とする。

特開２００４−３０５２３号公報に「店舗情報システム」が開示されている。
この店舗情報システムは、複数の店舗に設けられた情報端末装置と、複数の前記情報端末装置の各々とネットワークを介して接続されたサービス提供センターのサーバとから成る。そして、前記複数の店舗のいずれかで来客があったとき、その来客店舗は、自身の前記情報端末装置により前記サーバを介して自身以外の他の店舗に対して来客情報を送信し、前記他の店舗の各々は、受信した前記来客情報に対応して、自身の前記情報端末装置により前記サーバを介して自身以外の店舗に対して勧誘情報を送信する事を特徴とする

特開２００４−２１３０９８号公報に「混雑予測システム」が開示されている。
この混雑予測システムでは、受信機制御部と、外部イベント取込部と、模擬イベント発生部と、入力切替部と、イベント処理部とを備える。
前記受信機制御部は、通信ネットワークを介して、発信機を携帯した移動体が移動する観測エリア内の複数の受信機から送信される、該発信機のＩＤを含む発信機情報を受信する。前記外部イベント取込部は、前記発信機情報に基づき、前記発信機ＩＤ、前記発信機情報を送信した受信機のＩＤ、前記受信機の検出エリアに対する前記発信機の到着あるいは離脱を示す検出フラグ及び時刻情報を含む移動イベントを生成する。前記模擬イベント発生部は、前記移動体の行動を予測するために用いる移動体モデルに基づいて、前記移動イベントを生成する。前記入力切替部は、前記外部イベント取込部と前記模擬イベント発生部から送られる前記移動イベントを切り替えて出力する。前記イベント処理部は、前記入力切替部を介して前記外部イベント取込部から送られた移動イベントを順次取り出し、前記移動体の過去の移動履歴で表現される移動体情報を更新し、前記移動体の現在位置の推定を行う事と平行して、混雑予測を要求された時には、前記入力切替部を介して前記模擬イベント発生部から送られた移動イベントを用い、将来の混雑予測を行う。

特開２００２−１６９９１７号公報 特開２００４−３０５２３号公報 特開２００４−２１３０９８号公報

本発明の目的は、イベント開催情報及び顧客情報と過去のイベント開催の履歴よりイベントとレストランがどれだけ混雑するか予想して、それぞれの混雑状況を通知する混雑予想システム、混雑予想サーバー、混雑予想方法、及びプログラムを提供する事である。

以下に、［発明を実施するための最良の形態］で使用される番号を括弧付きで用いて、課題を解決するための手段を説明する。これらの番号は、［特許請求の範囲］の記載と［発明を実施するための最良の形態］との対応関係を明らかにするために付加されたものである。但し、それらの番号を、［特許請求の範囲］に記載されている発明の技術的範囲の解釈に用いてはならない。

本発明の混雑予想システムは、イベントの開催場所の周辺にある店舗に入店した顧客及び前記顧客の注文に関する顧客情報、及び前記イベントに関するイベント開催情報に基づいて、開催予定のイベントが開催された際の前記店舗の混雑予想を行う混雑予想サーバー（２０）と、前記顧客情報を前記混雑予想サーバー（２０）に送信する商業者端末（１０）と、前記イベント開催情報を前記混雑予想サーバー（２０）に送信するイベント開催者端末（３０）とを有し、前記混雑予想サーバー（２０）は、前記混雑予想の結果として混雑予想状況表を前記商業者端末（１０）に送信する。

本発明の混雑予想システムは、前記顧客情報を格納する飲食店顧客履歴データベース（２０２）と、前記店舗の詳細情報を格納する飲食店情報データベース（２０３）と、前記イベントの入退場履歴であるイベント履歴情報を格納するイベント履歴データベース（２０４）と、前記イベント開催情報を格納するイベント登録データベース（２０５）と、前記開催場所の詳細情報を格納する開催場所データベース（２０６）と、日付に関する情報を格納するカレンダーデータベース（２０７）と、前記イベントの入場者に関する情報を格納するイベント入場者データベース（２０８）と、前記店舗の入店者に関する情報を格納するレストラン入店者データベース（２０９）とを更に具備する。

前記混雑予想サーバー（２０）は、前記イベント登録データベース（２０５）に登録されたイベントの分類及び開催場所と一致するレコードを前記イベント履歴データベース（２０４）から抽出し、前記レコードの日付と前記カレンダーデータベース（２０７）の日付とを照合し、前記カレンダーデータベース（２０７）の日付に対応する休日又は祝日を示すフラグから決定される条件フラグを前記レコードに割り振り、前記条件フラグを前記イベント履歴データベース（２０４）に格納する。

前記条件フラグは、祝日の設定、通常の休日の設定、休日の前後日の設定、及び平日の設定、の区分を含む。

前記混雑予想サーバー（２０）は、性別、年齢層、入場時間、及び前記条件フラグ毎に前記入場者の人数の平均値を算出し、前記平均値を前記イベント入場者データベース（２０８）に予想人数として格納する。

前記混雑予想サーバー（２０）は、前記イベント登録データベース（２０５）から前記開催場所を認識し、前記開催場所データベース（２０６）から前記開催場所の周辺エリアのＧＰＳ位置情報を取得し、前記飲食店情報データベース（２０３）から前記ＧＰＳ位置情報に該当する前記商業者端末（１０）を選択する。

本発明の混雑予想サーバー（２０）は、処理装置（２０１）と、前記処理装置（２０１）がイベントの開催場所の周辺にある店舗に来店した顧客及び前記顧客の注文に関する顧客情報を格納する飲食店顧客履歴データベース（２０２）と、前記処理装置（２０１）が前記店舗の詳細情報を格納する飲食店情報データベース（２０３）と、前記処理装置（２０１）が前記イベントの履歴情報を格納するイベント履歴データベース（２０４）と、前記処理装置（２０１）が前記イベントの開催情報を格納するイベント登録データベース（２０５）と、前記処理装置（２０１）が前記開催場所の詳細情報を格納する開催場所データベース（２０６）と、前記処理装置（２０１）が日付に関する情報を格納するカレンダーデータベース（２０７）と、前記処理装置（２０１）が前記イベントの入場者に関する情報を格納するイベント入場者データベース（２０８）と、前記処理装置（２０１）が前記店舗の入店者に関する情報を格納するレストラン入店者データベース（２０９）とを具備する。

前記処理装置（２０１）は、前記イベント登録データベース（２０５）に登録されたイベントの分類及び開催場所と一致するレコードを前記イベント履歴データベース（２０４）から抽出し、前記レコードの日付と前記カレンダーデータベース（２０７）の日付とを照合し、前記カレンダーデータベース（２０７）の日付に対応する休日又は祝日を示すフラグから決定される条件フラグを前記レコードに割り振り、前記条件フラグを前記イベント履歴データベース（２０４）に格納する。

前記条件フラグは、祝日の設定、通常の休日の設定、休日の前後日の設定、及び平日の設定、の区分を含む。

前記処理装置（２０１）は、性別、年齢層、入場時間、及び前記条件フラグ毎に前記入場者の人数の平均値を算出し、前記平均値を前記イベント入場者データベース（２０８）に予想人数として格納する。

本発明の混雑予想方法は、（ａ）インターネットを介して、イベントの開催場所の周辺にある店舗の顧客のオーダー時にオーダリングターミナルを通して顧客及びオーダー情報を取得するステップと、（ｂ）前記顧客及びオーダー情報情報を飲食店顧客履歴データベース（２０２）に格納するステップと、（ｃ）インターネットを介して、前記イベントの開催が決定した時に開催情報を取得するステップと、（ｄ）自動的に割り当てたイベントＮＯと共に前記開催情報をイベント登録データベース（２０５）に格納するステップと、（ｅ）過去のイベントの入退場履歴であるイベント履歴データベース（２０４）の分類及び場所の情報が、前記イベント登録データベース（２０５）に登録された分類及び場所の情報と一致した場合、前記一致した情報を含むレコードを前記イベント履歴データベース（２０４）から抽出するステップと、（ｆ）前記抽出したレコードの日付とカレンダーデータベース（２０７）の日付とを照合し、一致した日付のレコードを前記カレンダーデータベース（２０７）から選択し、前記選択したレコードの休日フラグと祝日フラグとを読み込み、前記休日フラグ及び祝日フラグに基づいて判別される条件に応じて条件フラグを振り分け、前記条件フラグを前記イベント履歴データベース（２０４）に格納するステップと、（ｇ）前記イベント履歴データベース（２０４）から抽出された、性別、年齢層、入場時間、及び前記条件フラグをキーにして、１レコードを入場者１名としてカウントし、前記キーのそれぞれの値の平均値を算出し、前記平均値をイベント入場者データベース（２０８）に格納するステップとを具備する。

前記条件フラグは、祝日の設定、通常の休日の設定、休日の前後日の設定、及び平日の設定、の区分を含む。

本発明の混雑予想方法は、（ｈ）イベント毎にイベント混雑予想状況表を自動作成し、前記イベント混雑予想状況表に前記平均値を格納するステップと、（ｉ）前記イベント混雑予想状況表を、前記イベントの開催場所の周辺にある店舗が有する端末に送信するステップとを更に具備する。

本発明のプログラムは、上記のいずれかの混雑予想方法を、コンピュータに実行させるためのプログラムである。

（１）難しい、人の判断による入場や入店の予想をしなくてもよくなる。
（２）過去の履歴から、入場や入店の予想が容易にできるので材料の入手や人員の増員等も安易に可能であり、経費の節約に繋がる。
（３）レストラン業者は、周辺のイベント開催施設の開催情報を入手しなくても良い。
（４）時間及び日付による混雑予想により、パートやアルバイトの時間配慮がうまくできるので人件費の節約もできる。

以下に本発明の第１実施形態について添付図面を参照して説明する。
図１に示す通り、本発明のイベント時レストラン混雑予想システムでは、レストラン業者端末１０、混雑予想サーバー２０、イベント開催者端末３０が各々インターネット１００を介して接続されている。

レストラン業者端末１０は、オーダー時に顧客情報を登録するオーダリングターミナルなどの情報処理装置であり、１台以上のレストラン業者端末１０（１０−ｉ、ｉ＝１〜ｎ：ｎは端末数）を有している。

混雑予想サーバー２０は、処理装置と複数のＤＢ（データベース）を有するサーバーである。なお、混雑予想サーバー２０は複数でも良い。例えば、混雑予想に関する処理を、複数のサーバーで分散処理する場合、複数の混雑予想サーバー２０を使用する状況となる。この時、複数の混雑予想サーバー２０間で各ＤＢを共有するようにしても良い。

イベント開催者端末３０は、イベント開催情報登録のため、開催情報を登録するユーザが使用するパソコンなどの情報処理装置であり、１台以上のイベント開催者端末３０（３０−ｉ、ｉ＝１〜ｎ）を有している。
また、イベント開催者端末３０は、インターネット１００を介して、混雑予想サーバー２０にアクセスしイベント開催情報の登録を行う。また、分析後混雑予想サーバー２０より、「イベント混雑予想状況表（図１３）」を受信する事を目的とする。

図２に示すように、本発明の混雑予想サーバー２０は、処理装置２０１、飲食店顧客履歴ＤＢ２０２、飲食店情報ＤＢ２０３、イベント履歴ＤＢ２０４、イベント登録ＤＢ２０５、開催場所ＤＢ２０６、カレンダーＤＢ２０７、イベント入場者ＤＢ２０８、レストラン入店者ＤＢ２０９を備えている。但し、上記の構成は一例に過ぎず、実際には、飲食店顧客履歴ＤＢ２０２〜レストラン入店者ＤＢ２０９の各ＤＢは、混雑予想サーバー２０の外部に設けても良い。
なお、混雑予想サーバー２０が複数存在する場合、複数の混雑予想サーバー２０に上記の各ＤＢを分散して配置しても良い。

処理装置２０１はサーバ等の情報処理装置であり、インターネット１００を介してレストラン端末１０から受信した各情報を、対応するＤＢ（データベース）に格納する。

飲食店顧客履歴ＤＢ２０２は、顧客及びオーダー情報を格納するデータベースである。
図６に示すように、飲食店顧客履歴ＤＢ２０２が有するデータテーブルの主な項目は、「店舗の識別情報（店舗ＮＯ）」「顧客の“入店時間”」「顧客の“退店時間”」「顧客の“年齢層”」「顧客の“性別”」「顧客が入店した“日付”」「注文された“メニュー”」「休日又は祝日“フラグ”」等である。フラグは、休日又は祝日を識別するための情報である。

飲食店情報ＤＢ２０３は、店舗の詳細情報を格納するデータベースである。
図７に示すように、飲食店情報ＤＢ２０３が有するデータテーブルの主な項目は、「店舗の識別情報（店舗ＮＯ）」「店舗の名称（飲食店名）」「店舗の所在情報（住所）」「店舗の電話番号（ＴＥＬ）」「店舗の“代表者”」「店舗の“ＧＰＳ位置”（ＧＰＳアドレス）」「店舗の“メールアドレス”」等である。
なお、ＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）アドレスは、図１１のように地図上を１００Ｍ等の四方に区切り、座標として表現をしたアドレスである。

イベント履歴ＤＢ２０４は、イベントの履歴情報を格納するデータベースである。
図８に示すように、イベント履歴ＤＢ２０４が有するデータテーブルの主な項目は、「イベントの識別情報（イベントＮＯ）」「イベントの“分類”」「イベントの名称（イベント名）」「イベントの開催された“場所”」「入場者の“年齢層”」「入場者の“性別”」「入場者の“入場時間”」「入場者の“退場時間”」「入場者が入場した“日付”」「入場者が入場した“曜日”」「休日又は祝日“フラグ”」等である。

イベント登録ＤＢ２０５は、イベント開催情報を格納するデータベースである。
図９に示すように、イベント登録ＤＢ２０５が有するデータテーブルの主な項目は、「イベントの識別情報（イベントＮＯ）」「イベントの“分類”」「イベントの名称（イベント名）」「イベントの“開催場所”」「入場者の“性別”」「イベントの開催された“日付”」「イベントの開催された“時間”」「イベントの開催された“曜日”」「イベントの“担当者”」「担当者の“メールアドレス”」等である。

開催場所ＤＢ２０６は、開催場所の詳細情報を格納するデータベースである。
図１０に示すように、開催場所ＤＢ２０６が有するデータテーブルの主な項目は、「イベントの開催場所の識別情報（場所ＮＯ）」「イベントの“開催場所”」「開催場所の“住所”」「開催場所の電話番号（ＴＥＬ）」「開催場所の“代表者”」「開催場所の周辺エリアの“ＧＰＳ位置”」等である。

カレンダーＤＢ２０７は、日付に関する情報を格納するデータベースである。
図１４に示すように、カレンダーＤＢ２０７が有するデータテーブルの主な項目は、「日付」「曜日」「祝日名」「休日フラグ」「祝日フラグ」等である。

イベント入場者ＤＢ２０８は、入場者に関する情報を格納するデータベースである。
図１５に示すように、イベント入場者ＤＢ２０８が有するデータテーブルの主な項目は、「イベントの識別情報（イベントＮＯ）」「入場者の“入場時間”」「入場者の“年齢層”」「入場者の“性別”」「入場者平均値」「休日又は祝日“フラグ”」等である。

レストラン入店者ＤＢ２０９は、入店者に関する情報を格納するデータベースである。
図１６に示すように、レストラン入店者ＤＢ２０９が有するデータテーブルの主な項目は、「店舗の識別情報（店舗ＮＯ）」「顧客の“入店時間”」「顧客の“年齢層”」「顧客の“性別”」「入場者平均値」「休日又は祝日“フラグ”」等である。

なお、飲食店情報ＤＢ２０３、イベント履歴ＤＢ２０４、開催場所ＤＢ２０６、カレンダーＤＢ２０７はあらかじめ登録されているものとし、飲食店、開催場所、イベント情報が更新される度に随時格納されるものとする。

図３を参照して、レストラン業者端末側の動作について説明する。
（１）ステップＳ１０１
レストラン業者端末１０は、顧客からオーダーがあるか否か判断する。
（２）ステップＳ１０２
レストラン業者端末１０は、オーダーがあれば、インターネット１００を介して、混雑予想サーバー２０に、顧客及びオーダー情報を送信する。
（３）ステップＳ１０３
レストラン業者端末１０は、店舗の所在地がイベント開催場所周辺エリア内か否か判断する。
（４）ステップＳ１０４
また、分析後、混雑予想サーバー２０より、イベント開催場所周辺エリア内であれば「レストラン別混雑予想状況表（図１２）」を受信する事を目的とする。

図１２に示すように、レストラン別混雑予想状況表の主な項目は、「イベントの名称（イベント名）」「イベントの“開催場所”」「日付」「レストランの名称（飲食店名）」「入店者の“入店時間”」「入店者の“予想人数”」「入店者の“年齢層”」「入店者の“性別”」等である。

図４を参照して、イベント開催者端末側の動作について説明する。
（１）ステップＳ２０１
イベント開催者端末３０は、開催情報があるか否か判断する。
（２）ステップＳ２０２
イベント開催者端末３０は、開催情報があれば、インターネット１００を介して、混雑予想サーバー２０に、開催情報を送信する。
（３）ステップＳ２０３
また、イベント開催者端末３０は、混雑予想サーバー２０より、イベント開催場所周辺エリア内であれば「イベント別混雑予想状況表（図１３）」を受信する。

図１３に示すように、イベント別混雑予想状況表の主な項目は、「イベントの名称（イベント名）」「イベントの“開催場所”」「日付」「入場者の“入場時間”」「入場者の“予想人数”」「入場者の“年齢層”」「入場者の“性別”」等である。

図５Ａを参照して、混雑予想サーバー側の第１の動作について説明する。
（１）ステップＳ３０１
レストラン業者端末１０が顧客及びオーダー情報を有する場合、ステップＳ３０２の処理を行う。有しない場合、処理を終了する。
（２）ステップＳ３０２
処理装置２０１は、顧客及びオーダー情報があれば、インターネット１００を介して、レストラン業者端末１０から、顧客及びオーダー情報を受信する。
（３）ステップＳ３０３
この時、処理装置２０１は、顧客及びオーダー情報の受信日時を自動的に取得する。
（４）ステップＳ３０４
処理装置２０１は、インターネット１００を介してレストラン端末１０から受信した顧客及びオーダー情報を飲食店顧客履歴ＤＢ２０２に格納する。

図５Ｂ，図５Ｃ，図５Ｄを参照して、混雑予想サーバー側の第２の動作について説明する。
（１）ステップＳ４０１
イベント開催者端末３０が開催情報を有する場合、ステップＳ４０２の処理を行う。有しない場合、処理を終了する。
（２）ステップＳ４０２
処理装置２０１は、開催情報があれば、インターネット１００を介して、イベント開催者端末３０から、開催情報を受信する。
（３）ステップＳ４０３
また、処理装置２０１は、イベントＮＯ（イベントの識別情報）を自動的に割り当てる。
（４）ステップＳ４０４
処理装置２０１は、イベントＮＯと、イベント開催業者端末３０より受信したイベント開催情報をイベント登録ＤＢ２０５に格納する。
（５）ステップＳ４０５
また、処理装置２０１は、イベント登録ＤＢ２０５に登録後、イベント登録ＤＢ２０５を読み込む。
（６）ステップＳ４０６
処理装置２０１は、イベント履歴ＤＢ２０４に対して、イベント登録ＤＢ２０５に登録されたイベントの“分類”“場所”と一致するレコードを検索する。
（７）ステップＳ４０７
一致するレコードが存在する場合、ステップＳ４０８の処理を行う。存在しない場合、処理を終了する。
（８）ステップＳ４０８
処理装置２０１は、イベント登録ＤＢ２０５に登録されたイベントの“分類”“場所”と一致したレコード（日付を含む）をイベント履歴ＤＢ２０４より抽出する。
（９）ステップＳ４０９
処理装置２０１は、カレンダーＤＢ２０７を読み込む。
（１０）ステップＳ４１０
処理装置２０１は、イベント履歴ＤＢ２０４より抽出したレコードの“日付”とカレンダーＤＢ２０７の“日付”を照合する。
（１１）ステップＳ４１１
処理装置２０１は、カレンダーＤＢ２０７より“休日”“祝日”フラグを認識する。この時、処理装置２０１は、“休日”フラグと“祝日”フラグとを識別する。
（１２）ステップＳ４１２
処理装置２０１は、休日又は祝日フラグに基づいて、条件の“１”〜“４”に割り振り、イベント履歴ＤＢ２０４に格納する。
なお、「条件」の内容については以下の通りである。
“１”→休日フラグが“○”で祝日フラグが“○”のレコード・・・祝日日の設定（ＧＷ等）
“２”→休日フラグが“○”で祝日フラグが“×”のレコード・・・通常休日の設定（土日）
“３”→前後のレコードに休日フラグが“○”のレコード・・・休日の前後日の設定（月金等）
“４”→“３”の条件以外で、休日フラグが“×”で祝日フラグが“×”のレコード・・・平日の設定
（１３）ステップＳ４１３
イベント履歴ＤＢ２０４に格納後、処理装置２０１は、“性別”“年齢層”“入場時間”“フラグ”毎に入場者の平均値を算出する。この平均値が「予想人数」にあたる。
なお、平均値（予想人数）の算出方法の詳細は以下の通りである。
まず、開催されたイベントの過去の履歴の日付で、カレンダーＤＢ（図１４）より“１”〜“４”のフラグにわけ、対象となるＧＰＳ範囲のレストランを洗い出し、同じくそのレストランを飲食店顧客履歴ＤＢ（図６）より“１”〜“４”のフラグにわける。
その後、飲食店顧客履歴ＤＢを“フラグ”“性別”“年齢層”“入店時間”をキーに１レコードを１人としてカウントし、“１”〜“４”毎の平均値を算出する。
（１４）ステップＳ４１４
処理装置２０１は、イベント入場者ＤＢ２０８（図１５）に予想人数を格納する。
（１５）ステップＳ４１５
また、処理装置２０１は、イベントＮＯ又はイベント開催情報に基づいて、イベント登録ＤＢ２０５を検索し、イベント登録ＤＢ２０５より開催場所を認識する。
（１６）ステップＳ４１６
また、処理装置２０１は、開催場所に基づいて、開催場所ＤＢ２０６を検索する。
（１７）ステップＳ４１７
処理装置２０１は、開催場所ＤＢ２０６より“周辺エリアＧＰＳ”を選択する。
（１８）ステップＳ４１８
処理装置２０１は、飲食店情報ＤＢ２０３を読み込む。
（１９）ステップＳ４１９
処理装置２０１は、飲食店情報ＤＢ２０３に登録されているレストラン業者端末１０の“ＧＰＳ位置”に、“周辺エリアＧＰＳ”の範囲内に収まるものがない場合、処理を終了する。範囲内に収まるものがある場合、ステップＳ４１８の処理を行う。
（２０）ステップＳ４２０
処理装置２０１は、飲食店情報ＤＢ２０３の“ＧＰＳ位置”に当てはまるレストラン業者端末１０を選択する。
（２１）ステップＳ４２１
選択後、処理装置２０１は、イベント登録ＤＢ２０５を読み込む。
（２２）ステップＳ４２２
また、処理装置２０１は、イベント履歴ＤＢ２０４を読み込む。
（２３）ステップＳ４２３
処理装置２０１は、イベント登録ＤＢ２０５とイベント履歴ＤＢ２０４の“分類”を照合し、一致していればステップＳ４２４の処理を行い、一致しなければ処理を終了する。
（２４）ステップＳ４２４
処理装置２０１は、イベント履歴情報ＤＢ２０４より“日付”を抽出する。
（２５）ステップＳ４２５
処理装置２０１は、飲食店顧客履歴ＤＢ２０２を読み込む。
（２６）ステップＳ４２６
処理装置２０１は、イベント登録ＤＢ２０５とイベント履歴ＤＢ２０４の“分類”を照合した結果、一致したイベント履歴情報ＤＢ２０４の“日付”と飲食店顧客履歴ＤＢ２０２の“日付”を照合する。
（２７）ステップＳ４２７
処理装置２０１は、“ＧＰＳ位置”に当てはまるレストラン業者端末１０のレコード（日付を含む）を飲食店顧客履歴ＤＢ２０２より抽出する。
（２８）ステップＳ４２８
処理装置２０１は、カレンダーＤＢ２０７を読み込む。
（２９）ステップＳ４２９
処理装置２０１は、抽出したレコードの“日付”とカレンダーＤＢ２０７の“日付”を照合する。
（３０）ステップＳ４３０
処理装置２０１は、抽出したレコードの“休日”又は“祝日”フラグを認識する。
（３１）ステップＳ４３１
処理装置２０１は、休日又は祝日フラグから条件の“１”〜“４”に割り振り飲食店顧客履歴ＤＢ２０２に格納する。
（３２）ステップＳ４３２
飲食店顧客履歴ＤＢ２０２に格納後、処理装置２０１は、“性別”“年齢層”“入店時間”“フラグ”毎に入店者の平均値を算出する。
（３３）ステップＳ４３３
処理装置２０１は、レストラン入店者ＤＢ２０９（図１６）に予想人数を格納する。
（３４）ステップＳ４３４
処理装置２０１は、イベント登録ＤＢ２０５を読み込む。
（３５）ステップＳ４３５
処理装置２０１は、カレンダーＤＢ２０７を読み込む。
（３６）ステップＳ４３６
処理装置２０１は、イベント登録ＤＢ２０５より開催されるイベントの“日付”がカレンダーＤＢ２０７の“日付”の条件“１”〜“４”のどれに当てはまるか照合する。
（３７）ステップＳ４３７
処理装置２０１は、カレンダーＤＢ２０７よりフラグを決定する。
（３８）ステップＳ４３８
処理装置２０１は、決定したフラグとレストラン入店者ＤＢ２０９のフラグと比較し一致したフラグのレコードのみを抽出する。
（３９）ステップＳ４３９
処理装置２０１は、抽出したレコード及びイベント登録ＤＢ２０５、飲食店情報ＤＢ２０３を元に「レストラン別混雑予想状況表（図１２）」を自動作成する。
（４０）ステップＳ４４０
作成後、「レストラン別混雑予想状況表（図１２）」は、レストラン業者端末１０のメールアドレスに送信する
（４１）ステップＳ４４１
処理装置２０１は、決定したフラグとイベント入場者ＤＢ２０８のフラグと比較し一致したフラグのレコードのみを抽出する。
（４２）ステップＳ４４２
また、処理装置２０１は、「イベント混雑予想状況（図１３）」を自動作成する。
（４３）ステップＳ４４３
また、処理装置２０１は、「イベント混雑予想状況（図１３）」をイベント開催業者端末３０のメールアドレスに送信する。

本発明の実施例について以下に説明する。
レストラン業者端末１０は、インターネットを介してオーダー時にオーダリングターミナルを通して混雑予想サーバー２０に顧客及びオーダー情報（店舗ＮＯ、年齢層、性別、メニュー）を送信する。

混雑予想サーバー２０の処理装置２０１は、その度顧客及びオーダー情報を飲食店顧客履歴ＤＢ２０２（図６の形式）に格納する。

イベント開催者端末３０は、インターネットを介してイベント開催が決定したら開催情報を送信する。

混雑予想サーバー２０の処理装置２０１は、イベントＮＯ（００１イ）を自動採番し、開催情報と共にイベント登録ＤＢ２０５（図９の形式）に格納する。

混雑予想サーバー２０の処理装置２０１は、イベント登録ＤＢ２０５に格納されたら、過去のイベントの入退場履歴であるイベント履歴ＤＢ２０４（図８）よりイベント登録ＤＢ２０５に登録された“分類（電子展示）”“場所（Ｍ国際展示場）”がイベント履歴ＤＢ２０４の“分類（電子展示）”“場所（Ｍ国際展示場）”と一致したレコードをイベント履歴ＤＢ２０４より抽出する。

更に処理装置２０１は、抽出したイベント履歴ＤＢ２０４のレコードの“日付”とカレンダーＤＢ２０７の“日付”を照合し、一致した“日付”（２００５／３／１２，２００５／５／１２２００５／６／１４）のレコードをカレンダーＤＢ２０７より選択する。
更に選択したレコードの“休日フラグ”と“祝日フラグ”を読み込み、下記「★条件★」に応じて“フラグ”を“１”〜“４”に振り分ける。

★条件★
“１”→休日フラグが“○”で祝日フラグが“○”のレコード・・・祝日日の設定（ＧＷ等）
“２”→休日フラグが“○”で祝日フラグが“×”のレコード・・・通常休日の設定（土日）
“３”→前後のレコードに休日フラグが“○”のレコード・・・休日の前後日の設定（月金等）
“４”→“３”の条件以外で、休日フラグが“×”で祝日フラグが“×”のレコード・・・平日の設定

振り分け後、処理装置２０１は、抽出したイベント履歴ＤＢ２０５の“フラグ”欄に振り分けたフラグを全て格納する。

格納後、処理装置２０１は、上記で抽出したイベント履歴ＤＢ２０５の“性別”“年齢層”“入場時間”（１時間毎に区切る）“フラグ”をキーにして、１レコードを入場者１名としてカウントして上記キーのそれぞれの値の平均値を算出しそれぞれイベント入場者ＤＢ（図１５）の“入場者平均値”に格納する。
これにより、イベントが開催される“分類”“場所”“フラグ”毎のイベント入場者の１時間毎の入場者平均値が算出される。

更に処理装置２０１は、イベント開催者端末３０が送信したイベント登録ＤＢ２０５（図９）の“場所”より、開催場所が“Ｍ国際展示場”なので開催場所ＤＢ２０６（図１０）より“開催場所（Ｍ国際展示場）“で抽出し、”周辺エリアＧＰＳ（Ａ１〜Ａ４）“を選択する。

選択した“周辺エリア（Ａ１〜Ａ４）”が飲食店情報ＤＢ２０３（図７）の”ＧＰＳ位置“に当てはまる、レストラン業者端末１０（００１Ｔ：Ｄレストラン）を選択する事によりイベントが開催される周辺のレストラン業者端末１０を選定できる。
なお、ＧＰＳアドレスとは、図１１のように地図上を１００Ｍ等の四方に区切り、座標として表現をしたアドレスである。

更に処理装置２０１は、イベント登録ＤＢ２０５の“分類”が“電子展示“なのでイベント履歴ＤＢ２０４の“分類”を比較し“電子展示”のレコードを抽出する。
抽出したイベント履歴ＤＢ２０４のレコードの“日付”と飲食店顧客履歴ＤＢ２０２の“日付”を照合し、上記で“ＧＰＳ位置”に当てはまった周辺のレストラン業者端末１０（００１Ｔ：Ｄレストラン）のデータを全て抽出する。

更に、抽出した飲食店顧客履歴ＤＢ２０２の全レコードの“日付”とカレンダーＤＢ２０７“日付”を照合し、一致した“日付”（２００５／３／１２，２００５／５／１２）のレコードをカレンダーＤＢ２０７より選択する。

選択したレコードより“休日フラグ”と“祝日フラグ”を読み込み、上記「★条件★」に応じて“フラグ”を“１”〜“４”に振り分ける。
振り分けした後、抽出した飲食店顧客履歴ＤＢ２０２の“フラグ”欄に振り分けた“フラグ”を格納する。

格納後、飲食店顧客履歴ＤＢ２０２の“性別”“年齢層”“入店時間”（１時間毎に区切る）“フラグ”をキーにして、１レコードを入店者１名としてカウントし上記にキーのそれぞれの値の平均値を算出しレストラン入店者ＤＢ２０９（図１６）の“入店者平均値”に格納する。

これにより、イベント開催の“分類”により“フラグ”毎のレストラン入店者の１時間毎の入店者平均値が算出される。

処理装置２０１は、イベント登録ＤＢ２０５よりイベントＮＯ（００１イ：ＮＷ機器展示会）の“日付”（２００５／１０／１５）とカレンダーＤＢ２０７の“日付”を照合し、上記「★条件★」の中で“１”〜“４”のどの“フラグ”に当てはまるか決定する。（今回は“４”の設定とする）これにより、イベント開催日は、どの“フラグ”に当てはまるかが分かる。

“フラグ（“４”）が決定したので、処理装置２０１はレストラン入店者ＤＢ２０９の“フラグ”が“４”のレコードのみを抽出し、これらのデータとレストラン毎に飲食店顧客ＤＢ２０３より「レストラン別混雑予想状況表（図１２）」を自動作成し、算出した“入店者平均値”を“予想人数”に格納する。

「レストラン別混雑予想状況表（図１２）」の作成後、それぞれの周辺エリアに当てはまるレストラン業者端末１０のメールアドレス（００１Ｔ：Ｄレストラン（ＤＤＤ＠ＪＰ））に送信する。

同じく処理装置２０１はイベント入場者ＤＢ２０８の“フラグ”が同じく“４”のレコードのみを抽出し、これらのデータとイベント登録ＤＢ２０５より、イベント毎に「イベント混雑予想状況表（図１３）」を自動作成し“入場者平均値”を“予想人数”に格納する。

「イベント混雑予想状況表（図１３）」の作成後、それぞれのイベント開催者端末３０のメールアドレス（ＡＢＣ＠ＪＰ）に送信する。

「レストラン別混在予想状況表」を受信したレストラン業者端末１０（００１Ｔ：Ｄレストラン）は、レストラン業者端末１０の過去の顧客履歴と過去のイベント入場者履歴より“入店時間”“性別”“年齢層”毎の入店人数の予想が分かる。

これにより、人員の配置人数及び材料の入手量が推定でき余分なコストを使わなくてすむようになり、無駄がなくなるので経費削減に繋がる。

また、「イベント混雑予想状況表」を受信したイベント開催者端末３０は過去のイベントの分類等を見て入場予想をしたものなので、これにより開催日付にどれだけの入場があるのか時間別に予想できる。

したがって、混雑予想時の臨時増員雇用の人員配置及び混雑していない場合の人員の削減等に役立つのでコストの削減及び、イベントのスムーズ化に繋がる。

以上のように、本発明はインターネットを利用して、イベント開催者がイベント開催情報を送信する事と、複数のレストラン業者がオーダリングターミナルにて顧客情報を送信する事により、これらの情報と過去のイベント開催の履歴よりイベントとレストランがどれだけ混雑するか予想して、それぞれの混雑状況を通知するシステムである。

本発明において、複数のレストラン業者は、オーダー時にオーダリングターミナルにてサーバーに顧客情報を送信する。イベント開催者はイベント開催日時が決定次第、サーバーに開催情報を送信する。サーバー側では、過去のイベント開催履歴情報とレストラン顧客情報を蓄積しており、開催予定のイベントがどれだけ混雑するか予想する。

また、同じく、その周辺にあるレストラン業者がどれだけ混雑するかもデータ解析をして予想する。それぞれの予想した結果を一覧表にして、イベント開催業者及びレストラン業者へ送信する。

これにより、混雑の予想ができるので開催場の整理、及びレストランでの材料の入庫、人員の配置がスムーズに進み経費削減にも繋がる事ができる。

なお、前述の説明では、混雑予想の対象としてレストランを例にしているが、実際にはレストランに限定されるものではない。例えば、レストランの代わりに、イベント会場の周辺にあるコンビニや量販店、交通機関（駅、バス停等）を対象として本発明を実施する事も可能である。この場合、“メニュー”は、コンビニや量販店であれば販売される商品名、交通機関であれば利用される路線となる。

図１は、本発明の全体の構成図である。 図２は、混雑予想サーバーの構成図である。 図３は、レストラン業者端末側の動作のフローチャートである。 図４は、イベント開催者端末側の動作のフローチャートである。 図５Ａは、混雑予想サーバー側の第１の動作のフローチャートである。 図５Ｂは、混雑予想サーバー側の第２の動作のフローチャートである。 図５Ｃは、図５Ｂのフローチャートの続きである。 図５Ｄは、図５Ｃのフローチャートの続きである。 図６は、飲食店顧客履歴ＤＢ（データベース）の内容の一例である。 図７は、飲食店情報ＤＢの内容の一例である。 図８は、イベント履歴ＤＢの内容の一例である。 図９は、イベント登録ＤＢ内容の一例である。 図１０は、開催場所ＤＢの内容の一例である。 図１１は、ＧＰＳアドレスの内容の一例である。 図１２は、レストラン別混雑予想状況表の内容の一例である。 図１３は、イベント混雑予想状況表の内容の一例である。 図１４は、カレンダーＤＢの内容の一例である。 図１５は、イベント入場者ＤＢの内容の一例である。 図１６は、イベント入店者ＤＢの内容の一例である。

符号の説明

１０（−ｉ、ｉ＝１〜ｎ） レストラン業者端末
２０ 混雑予想サーバー
３０（−ｉ、ｉ＝１〜ｎ） イベント開催者端末
１００ インターネット
２０１ 処理装置
２０２ 飲食店顧客履歴ＤＢ（データベース）
２０３ 飲食店情報ＤＢ
２０４ イベント履歴ＤＢ
２０５ イベント登録ＤＢ
２０６ 開催場所ＤＢ
２０７ カレンダーＤＢ
２０８ イベント入場者ＤＢ
２０９ レストラン入店者ＤＢ

Claims (14)

1. イベントの開催場所の周辺にある店舗に入店した顧客及び前記顧客の注文に関する顧客情報、及び前記イベントに関するイベント開催情報に基づいて、開催予定のイベントが開催された際の前記店舗の混雑予想を行う混雑予想サーバーと、
   前記顧客情報を前記混雑予想サーバーに送信する商業者端末と、
   前記イベント開催情報を前記混雑予想サーバーに送信するイベント開催者端末と
   を有し、
   前記混雑予想サーバーは、前記混雑予想の結果として混雑予想状況表を前記商業者端末に送信する
   混雑予想システム。
2. 請求項１に記載の混雑予想システムにおいて、
   前記顧客情報を格納する飲食店顧客履歴データベースと、
   前記店舗の詳細情報を格納する飲食店情報データベースと、
   前記イベントの入退場履歴であるイベント履歴情報を格納するイベント履歴データベースと、
   前記イベント開催情報を格納するイベント登録データベースと、
   前記開催場所の詳細情報を格納する開催場所データベースと、
   日付に関する情報を格納するカレンダーデータベースと、
   前記イベントの入場者に関する情報を格納するイベント入場者データベースと、
   前記店舗の入店者に関する情報を格納するレストラン入店者データベースと
   を更に具備する
   混雑予想システム。
3. 請求項２に記載の混雑予想システムにおいて、
   前記混雑予想サーバーは、前記イベント登録データベースに登録されたイベントの分類及び開催場所と一致するレコードを前記イベント履歴データベースから抽出し、前記レコードの日付と前記カレンダーデータベースの日付とを照合し、前記カレンダーデータベースの日付に対応する休日又は祝日を示すフラグから決定される条件フラグを前記レコードに割り振り、前記条件フラグを前記イベント履歴データベースに格納する
   混雑予想システム。
4. 請求項３に記載の混雑予想システムにおいて、
   前記条件フラグは、祝日の設定、通常の休日の設定、休日の前後日の設定、及び平日の設定、の区分を含む
   混雑予想システム。
5. 請求項４に記載の混雑予想システムにおいて、
   前記混雑予想サーバーは、性別、年齢層、入場時間、及び前記条件フラグ毎に前記入場者の人数の平均値を算出し、前記平均値を前記イベント入場者データベースに予想人数として格納する
   混雑予想システム。
6. 請求項５に記載の混雑予想システムにおいて、
   前記混雑予想サーバーは、前記イベント登録データベースから前記開催場所を認識し、前記開催場所データベースから前記開催場所の周辺エリアのＧＰＳ位置情報を取得し、前記飲食店情報データベースから前記ＧＰＳ位置情報に該当する前記商業者端末を選択する
   混雑予想システム。
7. 処理装置と、
   前記処理装置がイベントの開催場所の周辺にある店舗に来店した顧客及び前記顧客の注文に関する顧客情報を格納する飲食店顧客履歴データベースと、
   前記処理装置が前記店舗の詳細情報を格納する飲食店情報データベースと、
   前記処理装置が前記イベントの履歴情報を格納するイベント履歴データベースと、
   前記処理装置が前記イベントの開催情報を格納するイベント登録データベースと、
   前記処理装置が前記開催場所の詳細情報を格納する開催場所データベースと、
   前記処理装置が日付に関する情報を格納するカレンダーデータベースと、
   前記処理装置が前記イベントの入場者に関する情報を格納するイベント入場者データベースと、
   前記処理装置が前記店舗の入店者に関する情報を格納するレストラン入店者データベースと
   を具備する
   混雑予想サーバー。
8. 請求項７に記載の混雑予想サーバーにおいて、
   前記処理装置は、前記イベント登録データベースに登録されたイベントの分類及び開催場所と一致するレコードを前記イベント履歴データベースから抽出し、前記レコードの日付と前記カレンダーデータベースの日付とを照合し、前記カレンダーデータベースの日付に対応する休日又は祝日を示すフラグから決定される条件フラグを前記レコードに割り振り、前記条件フラグを前記イベント履歴データベースに格納する
   混雑予想サーバー。
9. 請求項８に記載の混雑予想サーバーにおいて、
   前記条件フラグは、祝日の設定、通常の休日の設定、休日の前後日の設定、及び平日の設定、の区分を含む
   混雑予想サーバー。
10. 請求項９に記載の混雑予想サーバーにおいて、
    前記処理装置は、性別、年齢層、入場時間、及び前記条件フラグ毎に前記入場者の人数の平均値を算出し、前記平均値を前記イベント入場者データベースに予想人数として格納する
    混雑予想サーバー。
11. （ａ）インターネットを介して、イベントの開催場所の周辺にある店舗の顧客のオーダー時にオーダリングターミナルを通して顧客及びオーダー情報を取得するステップと、
    （ｂ）前記顧客及びオーダー情報情報を飲食店顧客履歴データベースに格納するステップと、
    （ｃ）インターネットを介して、前記イベントの開催が決定した時に開催情報を取得するステップと、
    （ｄ）自動的に割り当てたイベントＮＯと共に前記開催情報をイベント登録データベースに格納するステップと、
    （ｅ）過去のイベントの入退場履歴であるイベント履歴データベースの分類及び場所の情報が、前記イベント登録データベースに登録された分類及び場所の情報と一致した場合、前記一致した情報を含むレコードを前記イベント履歴データベースから抽出するステップと、
    （ｆ）前記抽出したレコードの日付とカレンダーデータベースの日付とを照合し、一致した日付のレコードを前記カレンダーデータベースから選択し、前記選択したレコードの休日フラグと祝日フラグとを読み込み、前記休日フラグ及び祝日フラグに基づいて判別される条件に応じて条件フラグを振り分け、前記条件フラグを前記イベント履歴データベースに格納するステップと、
    （ｇ）前記イベント履歴データベースから抽出された、性別、年齢層、入場時間、及び前記条件フラグをキーにして、１レコードを入場者１名としてカウントし、前記キーのそれぞれの値の平均値を算出し、前記平均値をイベント入場者データベースに格納するステップと
    を具備する
    混雑予想方法。
12. 請求項１１に記載の混雑予想方法において、
    前記条件フラグは、祝日の設定、通常の休日の設定、休日の前後日の設定、及び平日の設定、の区分を含む
    混雑予想方法。
13. 請求項１１に記載の混雑予想方法において、
    （ｈ）イベント毎にイベント混雑予想状況表を自動作成し、前記イベント混雑予想状況表に前記平均値を格納するステップと、
    （ｉ）前記イベント混雑予想状況表を、前記イベントの開催場所の周辺にある店舗が有する端末に送信するステップと
    を更に具備する
    混雑予想方法。
14. 請求項１１乃至１３のいずれか一項に記載の混雑予想方法を、コンピュータに実行させるためのプログラム。

Images