飲食店推薦システム
【課題】企業の社員等に対して昼食時における混雑を回避しつつジャンルを考慮して飽きがこないように近隣の飲食店を推薦する飲食店推薦システムを提供する。
【解決手段】飲食店推薦サーバ１０は、携帯端末４０を介して取得した各社員の現在の所在に係る情報を保持する社員所在ＤＢ２１と、近隣の飲食店に係る情報を保持する飲食店ＤＢ２３と、社員が昼食時に選択した飲食店のジャンルの情報を履歴として蓄積するジャンル履歴ＤＢ２２とを有し、各社員の現在の所在の情報に基づいて各飲食店についての混雑回避度を算出する混雑度判定部１２と、対象社員についてのジャンルの履歴に基づいて嗜好と飽きを判断してジャンル毎推薦度を算出するジャンル推薦部１４と、各飲食店について混雑回避度とジャンル毎推薦度とに基づいてスコアを算出し、スコアが上位の順に携帯端末４０を介して提示する飲食店推薦部１５とを有する。
【解決手段】飲食店推薦サーバ１０は、携帯端末４０を介して取得した各社員の現在の所在に係る情報を保持する社員所在ＤＢ２１と、近隣の飲食店に係る情報を保持する飲食店ＤＢ２３と、社員が昼食時に選択した飲食店のジャンルの情報を履歴として蓄積するジャンル履歴ＤＢ２２とを有し、各社員の現在の所在の情報に基づいて各飲食店についての混雑回避度を算出する混雑度判定部１２と、対象社員についてのジャンルの履歴に基づいて嗜好と飽きを判断してジャンル毎推薦度を算出するジャンル推薦部１４と、各飲食店について混雑回避度とジャンル毎推薦度とに基づいてスコアを算出し、スコアが上位の順に携帯端末４０を介して提示する飲食店推薦部１５とを有する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ユーザに近隣の飲食店を推薦する技術に関し、特に、多数の社員を有する企業等において昼食時に社員に対して近隣の飲食店を推薦する飲食店推薦システムに適用して有効な技術に関するものである。
【背景技術】
【０００２】
従前より、インターネット等を利用して、ユーザに対して特定の地域における店舗や施設等を抽出して推薦するような情報処理システムが存在する。特に、例えばスマートフォン等の携帯端末をクライアント端末として利用することによって、ユーザの現在位置に基づいて近隣の店舗等を提示することが行われている。また、例えば、ユーザの行動履歴や操作履歴、嗜好や属性、さらには他のユーザ等によって登録されたいわゆるクチコミ情報などに基づいて、対象のユーザにより合致した店舗等をランキング形式で提示して推薦するようなシステムも存在する。
【０００３】
例えば、特開２０１０−９３１５号公報（特許文献１）には、店舗位置情報を含む店舗情報を店舗情報記憶手段に記憶しておくとともに、店舗名を含むクチコミ情報をクチコミ情報記憶手段に記憶しておき、携帯端末から端末位置情報を受信した場合に、店舗情報検索手段が、受信した端末位置情報に関連する店舗位置情報を有する店舗情報を抽出し、推薦店舗決定手段が、抽出した店舗情報に含まれる店舗名を含むクチコミ情報を抽出して各店舗の人気度を求め、人気度の高い店舗を推薦店舗として決定し、店舗情報送信手段が、推薦店舗の店舗情報を携帯端末に送信することで、インターネット上のクチコミ情報を活用して、利用者がいる場所付近における人気の店舗を検出し、利用者に対して提示することが可能な推薦店舗提示システムが記載されている。
【０００４】
また、例えば、特開２００８−１５８８２３号公報（特許文献２）には、各利用者ごとに、各ジャンルの特徴項目についての嗜好値を含む利用者嗜好情報が格納される利用者嗜好情報格納部と、各店舗ごとに、そのジャンルの特徴項目についての評価値を含む店舗評価情報が格納される店舗評価情報格納部と、利用者嗜好情報に合致した店舗評価情報をもつ店舗情報を選択して利用者に提供する店舗情報提供部とを有し、利用者が、特定の店舗情報を閲覧したり、特定の店舗を利用したりすると、当該特定の店舗が関心店舗記録部に関心店舗として蓄積され、蓄積された関心店舗の店舗評価情報に基づき利用者嗜好情報を更新する嗜好値更新部を有することで、店舗情報格納部内に用意された店舗情報を各利用者に提供する際に、各利用者の嗜好を正確に把握してこれを反映させた情報提供を行うことを可能とする情報提供システムが記載されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０１０−９３１５号公報
【特許文献２】特開２００８−１５８８２３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
例えば上記の特許文献１、２などに記載されているようなシステムを利用することで、ユーザの現在位置の近隣における人気の高い店舗や、ユーザの嗜好、属性等に合致した店舗をユーザに対して推薦することが可能である。
【０００７】
しかしながら、このように推薦された店舗等がユーザのあらゆる場面・状況において適切なものであるとは限らない。例えば、多数の社員が在籍する企業等においては、昼食時には多数の社員が一斉に勤務地のビル等の近隣の飲食店に向かうことになり、特に郊外などに所在する企業の場合は、繁華街と比べて近隣の飲食店の数も比較的少なく、これらの飲食店に社員が集中して混雑し易いという特徴を有する。このような状況で上記のような手段によって飲食店の推薦を受けてそこに向かったとしても、さらに混雑が激しくなるだけという結果になる。また、飲食店に到着してから混雑が判明すると、そこからまた別の飲食店を探すなどの労力を要することになり、通常昼食時の休憩時間は限られていることから、予め混雑を避けて飲食店を選択するという必要性は高い。
【０００８】
一方、毎日繰り返される昼食という点からは、連続して同じジャンルの飲食店に行くと通常は飽きてしまうため、直近に行った飲食店のジャンルを考慮して、別のジャンルの飲食店を選択するということも社員にとっては通常行われる行動である。しかし、ジャンルの選択に迷って時間を浪費するという場合も多々あり、時間的制約のある昼食時にはこのような無駄な時間を削減するという必要性も高い。
【０００９】
そこで本発明の目的は、企業の社員等に対して、昼食時における混雑を回避しつつ、ジャンルを考慮して飽きがこないように近隣の飲食店を推薦する飲食店推薦システムを提供することにある。本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。
【課題を解決するための手段】
【００１０】
本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。
【００１１】
本発明の代表的な実施の形態による飲食店推薦システムは、一つの拠点に複数のユーザが所在するグループにおいて、昼食時にユーザに対して近隣の飲食店を推薦する飲食店推薦システムであって、各ユーザが保有する携帯端末と、前記各携帯端末がネットワークを介して接続する飲食店推薦サーバとから構成され、以下の特徴を有するものである。
【００１２】
すなわち、前記飲食店推薦サーバは、前記携帯端末を介して取得した各ユーザの現在の所在に係る情報を保持するユーザ所在記録手段と、各ユーザが昼食時に利用可能な近隣の飲食店に係るマスタ情報を保持する飲食店記録手段と、ユーザが昼食時に実際に選択した飲食店のジャンルの情報をユーザ毎に履歴として蓄積保持するジャンル履歴記録手段とを有する。
【００１３】
さらに、前記ユーザ所在記録手段に記録された各ユーザの現在の所在の情報に基づいて、前記飲食店記録手段に保持する各飲食店についての混雑していない程度を示す混雑回避度を算出する混雑度判定部と、前記ジャンル履歴記録手段に記録された対象ユーザについてのジャンルの履歴に基づいて、前記対象ユーザの嗜好と飽きを判断して、前記対象ユーザについてのジャンル毎推薦度を算出するジャンル推薦部と、前記飲食店記録手段に保持する各飲食店について、前記混雑回避度と各飲食店のジャンルに対応する前記ジャンル毎推薦度とに基づいてスコアを算出し、前記スコアが上位の順に各飲食店を前記携帯端末を介して前記対象ユーザに提示する飲食店推薦部とを有することを特徴とするものである。
【発明の効果】
【００１４】
本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。
【００１５】
本発明の代表的な実施の形態によれば、企業の社員等に対して、昼食時における混雑を回避しつつ、ジャンルを考慮して飽きがこないように近隣の飲食店を推薦することが可能となり、社員等が昼食時の飲食店を選択する際に要する労力や時間の浪費を解消することが可能となる。
【図面の簡単な説明】
【００１６】
【図１】本発明の一実施の形態である飲食店推薦システムの構成例について概要を示した図である。
【図２】本発明の一実施の形態における飲食店の推薦処理の例について概要を示した図である。
【図３】本発明の一実施の形態における社員所在ＤＢのデータ構成の例を示した図である。
【図４】本発明の一実施の形態におけるジャンル履歴ＤＢのデータ構成の例を示した図である。
【図５】本発明の一実施の形態における飲食店ＤＢのデータ構成の例を示した図である。
【図６】本発明の一実施の形態における混雑回避度ａを算出する具体例を示した図である。
【図７】本発明の一実施の形態における不選択度ｆを算出する具体例を示した図である。
【図８】本発明の一実施の形態における嗜好度ｌを算出する具体例を示した図である。
【図９】本発明の一実施の形態におけるジャンル毎推薦度ｒを算出する具体例を示した図である。
【図１０】本発明の一実施の形態におけるスコアＳを算出する具体例を示した図である。
【発明を実施するための形態】
【００１７】
以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。
【００１８】
＜概要＞
本発明の一実施の形態である飲食店推薦システムは、例えば多数の社員を有する企業など、一つの拠点に複数のユーザが所在するグループにおいて、昼食時にユーザ（本実施の形態では企業の社員を例とする）に対して、混雑を回避しつつジャンルを考慮して飽きがこないように近隣の飲食店を推薦することを可能とする情報処理システムである。本実施の形態では、昼食時の飲食店を推薦する際の判断基準として、各社員が一斉に近隣の飲食店に向かうことに伴う各飲食店の混雑度と、社員が過去の昼食の際に選択したジャンルの履歴に基づいて社員の嗜好と飽きを判断して得られるジャンルの推薦度の２つを利用する。
【００１９】
図２は、本実施の形態の飲食店推薦システムによる飲食店の推薦処理の例について概要を示した図である。図２の左側では混雑度の判定を行う処理が行われ、右側ではジャンルを推薦する処理が行われることを示している。混雑度の判定処理においては、まず、社員が企業から貸与等されて保有しているスマートフォン等の携帯端末４０を利用して、各社員が昼食時にどこ（の飲食店）にいるかについての所在の情報を収集しておく（Ｓ１）。ここでは、例えば携帯端末４０がＧＰＳ（Global Positioning System）５０を利用して取得した位置情報を利用する。この位置情報は、例えば社員所在ＤＢ２１としてデータベースに記録しておく。
【００２０】
この社員所在ＤＢ２１に記録された各社員の所在の情報に基づいて、近隣の各飲食店についての混雑回避度２５を算出する（Ｓ２）。近隣の飲食店に係る情報は、例えば飲食店ＤＢ２３に予めマスタとして登録されている。なお、本実施の形態では、各飲食店が混雑している程度を示す混雑度に加えて、混雑していない（混雑を回避できる）程度を示す混雑回避度２５を混雑度に基づいて算出し、これを利用するものとする。
【００２１】
一方、ジャンルを推薦する処理においては、まず、各社員が過去の昼食の際に選択したジャンルの履歴の情報がジャンル履歴ＤＢ２２のデータベースに蓄積されており、社員からの携帯端末４０を介した飲食店の推薦要求をトリガとして、ジャンル履歴ＤＢ２２の情報に基づいて対象の社員の嗜好や飽きを判断し、対象の社員に対するジャンル毎の推薦度であるジャンル毎推薦度２６を算出する（Ｓ３）。このジャンル毎推薦度２６を参照することで、飲食店ＤＢ２３に登録されている各飲食店について、その店のジャンルに対応する推薦度２７を得る（Ｓ４）。
【００２２】
上記の処理で得られた各飲食店についての混雑回避度２５と推薦度２７とに基づいて各飲食店についてのスコアを算出し（Ｓ５）、スコアが上位の順に飲食店を並べたものをランキング２８として携帯端末４０を介して社員に提示する。なお、ステップＳ５におけるスコアリングの際には、予め設定した重み付け設定値２４によって、混雑回避度２５と推薦度２７のいずれを重視するかに応じて値に重み付けした上でスコアを算出することができる。
【００２３】
社員は、ランキング２８を参照することで昼食時の飲食店を選択した上で対象の飲食店に向かうことができ、飲食店の選択に要する労力や時間の浪費を解消することができる。なお、実際に飲食店で昼食をとっている際の当該社員の所在の情報は、携帯端末４０のＧＰＳ機能によって社員所在ＤＢ２１にフィードバックされる。また、社員が実際に選択した飲食店のジャンルに係る情報は、ジャンル履歴ＤＢ２２に蓄積される。
【００２４】
＜システム構成＞
図１は、本発明の一実施の形態である飲食店推薦システムの構成例について概要を示した図である。飲食店推薦システム１は、例えば、上述した飲食店推薦サービスを社員に提供する企業等が運用管理するサーバ等のコンピュータ機器からなる飲食店推薦サーバ１０と、当該企業の社員等がそれぞれ保有するスマートフォン等の携帯端末４０から構成される。各携帯端末４０は、無線によるデータ通信機能を利用して、インターネットやイントラネット等のネットワーク３０を介して飲食店推薦サーバ１０に接続することができる。
【００２５】
飲食店推薦サーバ１０は、図示しないＯＳ（Operating System）やＷｅｂサーバプログラム、データベース管理プログラムなどのミドルウェアを有し、さらに、例えばこれらの上で稼働するソフトウェアプログラムとして実装される、社員所在収集部１１、混雑度判定部１２、ジャンル履歴管理部１３、ジャンル推薦部１４、および飲食店推薦部１５などの各部を有する。また、例えばデータベースとして構成される社員所在ＤＢ２１、ジャンル履歴ＤＢ２２、および飲食店ＤＢ２３や、設定ファイル等として構成される重み付け設定値２４などの各データを有する。
【００２６】
一方、携帯端末４０は、上述したようにＧＰＳ５０を利用して位置情報を取得する機能を有しており、また、図示しないＷｅｂブラウザ等のソフトウェアプログラムや、専用のアプリケーションプログラムなどにより、ネットワーク３０を介して飲食店推薦サーバ１０にアクセスして、上記の位置情報を含む所定の情報を送信したり飲食店の推薦要求を送信したりして飲食店推薦サービスを実行することができる。なお、位置情報の送信については、ＧＰＳ５０によって得られた位置情報に限らず、社員が現在地の住所等を手動で入力したり、携帯端末４０に表示された地図上の対応する箇所をタップ等によって指定したりするなどの手段により得た位置情報であってもよい。
【００２７】
飲食店推薦サーバ１０の社員所在収集部１１は、図２のステップＳ１における処理として、携帯端末４０から送信されたＧＰＳ５０等による位置情報を取得し、社員所在ＤＢ２１に記録する。このとき、ＧＰＳ５０等による位置情報だけでなく、当該位置情報と後述する飲食店ＤＢ２３に保持している各飲食店の位置情報とをマッチングすることにより、どの飲食店にいるかについての情報を算出しておき、この情報を保持するようにしてもよい。
【００２８】
混雑度判定部１２は、図２のステップＳ２における処理として、社員所在ＤＢ２１に記録された各社員の現在の所在の情報に基づいて、飲食店ＤＢ２３にマスタとして登録されている近隣の飲食店毎に混雑回避度２５を算出する。ここでは、各飲食店の位置情報と各社員の現在の位置情報とをマッチングすることにより、各飲食店にいると推定される社員の数を算出し、これに基づいて各飲食店の混雑回避度２５を算出する。
【００２９】
ジャンル履歴管理部１３は、社員が実際に昼食時に選択した飲食店のジャンルの情報を携帯端末４０を介した社員からの入力等を利用して取得し、これを履歴情報としてジャンル履歴ＤＢ２２に所定の期間分蓄積する。なお、社員がジャンルの情報を携帯端末４０から入力するためのユーザインタフェースを提供するソフトウェアプログラムが飲食店推薦サーバ１０もしくは携帯端末４０に実装される。
【００３０】
ジャンル推薦部１４は、図２のステップＳ３における処理として、ジャンル履歴ＤＢ２２に蓄積された対象の社員の昼食時のジャンルの履歴の情報を解析して、対象の社員の嗜好や飽きを判断して、対象の社員についてのジャンル毎推薦度２６を算出する。
【００３１】
飲食店推薦部１５は、図２のステップＳ４およびＳ５における処理として、飲食店ＤＢ２３に登録された各飲食店について、ジャンル推薦部１４によって算出されたジャンル毎推薦度２６を参照して得られる各飲食店のジャンルに対応する推薦度２７と、混雑度判定部１２によって算出された各飲食店の混雑回避度２５とに基づいてスコアを算出し、スコアが上位の順に飲食店をランキング２８として出力することで社員に提示する。このとき、予め設定された重み付け設定値２４によって、混雑回避度２５と推薦度２７のいずれを重視するかに応じてそれぞれの値に重み付けした上でスコアを算出することができる。
【００３２】
上記の各部以外にも、例えば、各社員が飲食店推薦サーバ１０にアクセスする際のユーザ認証を行うための認証部などを有していてもよい。また、各社員が例えば、自身が好む／好まない昼食のジャンルや飲食店の情報を嗜好に係る情報として予め登録できるようにしておき、ジャンル推薦部１４が対象の社員についてのジャンル毎推薦度２６を算出したり、飲食店推薦部１５が飲食店毎のスコアを算出したりする際に利用できるようにしてもよい。
【００３３】
＜データ構成＞
図３は、社員所在ＤＢ２１のデータ構成の例を示した図である。社員所在ＤＢ２１は、各社員の現在の所在に係る情報を保持するテーブルであり、例えば、社員ＩＤ、位置情報、所在飲食店、および更新日時などの各項目を有する。キー項目は社員ＩＤである。
【００３４】
社員ＩＤの項目は、各社員を一意に識別することができるＩＤや社員番号等の情報を保持する。位置情報の項目は、対象の社員の現在の所在位置に係る情報であり、対象の社員が保有する携帯端末４０がＧＰＳ５０等を利用して取得した位置情報を保持する。ＧＰＳ５０を利用した場合、位置情報は緯度・経度の情報として構成されるが、例えば多数の飲食店が入居するビルにおける階の情報を判断可能とするために高さ情報を含んでいてもよい。また、位置情報が緯度・経度ではなく住所等の他の形式の場合には、社員所在収集部１１等により緯度・経度の情報に変換するなどの処理を行ってもよい。
【００３５】
所在飲食店の項目は、対象の社員の現在の位置情報に基づいて、後述する飲食店ＤＢ２３に保持している各飲食店の位置情報とのマッチングによりどの飲食店にいるかを算出した結果の情報を保持する。更新日時の項目は、対象の社員についての所在の情報が最後に更新されたタイムスタンプの情報を保持する。
【００３６】
図４は、ジャンル履歴ＤＢ２２のデータ構成の例を示した図である。ジャンル履歴ＤＢ２２は、各社員が毎日（毎回）の昼食時に実際に選択した飲食店のジャンルの情報を社員毎に履歴として蓄積保持するテーブルであり、例えば、社員ＩＤ、飲食日、ジャンル、および店舗ＩＤなどの各項目を有する。キー項目は社員ＩＤと飲食日である。
【００３７】
社員ＩＤの項目は、履歴情報の対象となる社員を特定するＩＤ情報であり、図３の社員所在ＤＢ２１における社員ＩＤの項目と同様である。飲食日の項目は、対象の社員が昼食をとった日付の情報を保持する。ジャンルおよび店舗ＩＤの項目は、対象の社員が対象の日の昼食時に選択したジャンルおよびその飲食店を特定する店舗ＩＤの情報をそれぞれ保持する。なお、これ以外にも例えば、飲食店が複数ジャンルのメニューを有する場合なども考慮して、対象の社員が実際に選択したメニューに関する情報を保持する項目や、選択した飲食店／メニューについての対象の社員による評価の情報を保持する項目などを有して、ジャンル履歴ＤＢ２２に蓄積された履歴情報に基づいて各社員のジャンルに対する嗜好をより詳細に解析できるようにしてもよい。
【００３８】
図５は、飲食店ＤＢ２３のデータ構成の例を示した図である。飲食店ＤＢ２３は、社員が昼食時に利用可能な近隣の飲食店に係るマスタ情報を保持するテーブルであり、例えば、店舗ＩＤ、店舗名、住所、位置情報、ジャンル、座席数、および社員比率などの各項目を有する。キー項目は店舗ＩＤである。
【００３９】
店舗ＩＤの項目は、各飲食店を一意に識別することができるＩＤの情報を保持する。当該店舗ＩＤの値は、例えば管理者等が飲食店のマスタ情報を飲食店ＤＢ２３に登録する際に、飲食店推薦サーバ１０が自動で割り当てるようにすることができる。店舗名の項目は、対象の飲食店の名称の情報を保持する。住所および位置情報の項目は、対象の飲食店の所在に係る情報として、住所および位置情報をそれぞれ保持する。位置情報は、図３の社員所在ＤＢ２１における位置情報の項目とマッチングするため、これと同様の緯度、経度の形式で保持する。対象の飲食店が多数の飲食店が入居するビル内などにある場合を考慮して高さ情報を含んでいてもよい。
【００４０】
ジャンルの項目は、対象の飲食店における昼食のジャンル（例えば“和食”や“中華”など）の情報を保持する。飲食店が複数ジャンルのメニューを有する場合なども考慮して、ジャンルの情報を複数保持できるようにしてもよい。座席数の項目は、対象の飲食店が有する全座席の数の情報を保持する。社員比率の項目は、対象の飲食店における昼食時の来店客構成の情報として、全ての来店客に占める当該企業の社員の割合の情報を保持する。例えば、社員比率＝１．０の場合には、対象の飲食店における来店客の全てが当該企業の社員であることを示す。同様に、例えば、社員比率＝０．８の場合には、来店客の８割が当該企業の社員であり、それ以外に２割の一般の来店客が存在することを示す。
【００４１】
なお、この社員比率の情報は厳密である必要はなく、例えば、対象の飲食店で昼食をとった社員から、大まかな来店客構成の情報をヒアリングや携帯端末４０を利用した入力等によって取得し、その統計情報等から算出することなどが考えられる。この社員比率の値と対象の飲食店にいると推測される社員の数（図３の社員所在ＤＢ２１を集計して算出することができる）とに基づいて、対象の飲食店にいる全ての来店客数を推測することができる。
【００４２】
なお、上述の図３〜図５で示した各テーブルのデータ構成（項目）はあくまで一例であり、同様のデータを保持・管理することが可能な構成であれば、他のテーブル構成やデータ構成であってもよい。
【００４３】
＜スコア算出方法＞
以下では、図２に示した飲食店の推薦処理の例において、各飲食店についてのスコアを算出する際の具体的な手順について説明する。まず、図２における混雑度の判定処理として、ステップＳ２の混雑回避度２５の算出処理では、飲食店ＤＢ２３に保持する各飲食店について、対象の飲食店の座席数と対象の飲食店に現在来店していると推測される社員数（図３の社員所在ＤＢ２１を集計して算出することができる）、および対象の飲食店の社員比率に基づいて混雑回避度２５を算出する。具体的には、例えば以下の式によって、飲食店Ｒについての混雑率ｃ（Ｒ）を算出し、さらに混雑回避度２５（ａ（Ｒ））を算出する。
【００４４】
【数１】
【００４５】
図６は、混雑回避度ａを算出する具体例を示した図である。図６では、例えば、図示するような座席数、来店客としての社員数、および社員比率を有する“店舗Ａ”、“店舗Ｂ”について、それぞれ数１に示した式に従って混雑回避度ａを算出した場合の例を示している。混雑回避度ａは、値が大きいほど対象の飲食店が混雑していない（混雑を回避できる）ことを示すため、推薦の程度が高くなることを示す。すなわち、図６の例では、“店舗Ｂ”の混雑回避度ａ（店舗Ｂ）＝０．３０のほうが“店舗Ａ”の混雑回避度ａ（店舗Ａ）＝０．２９より値が大きいため、混雑という観点からは“店舗Ｂ”のほうが推薦の程度が高くなる。
【００４６】
一方、図２におけるジャンルの推薦処理として、ステップＳ３のジャンル毎推薦度２６の算出処理では、対象の社員について、ジャンル履歴ＤＢ２２に蓄積された昼食時に選択したジャンルの情報を解析して、当該社員の各ジャンルについての嗜好と飽きの程度を判定し、これらに基づいてジャンル毎推薦度２６を算出する。具体的には、飽きの程度として、直近で昼食に選択したジャンルほど飽きている程度が高い（選択されていないジャンルほど飽きていない程度が高い）と判断し、例えば以下の式によって、過去７日間に選択した昼食のジャンルに基づいて、ジャンルＧについての飽きていない程度を示す不選択度ｆ（Ｇ）を算出する。
【００４７】
【数２】
【００４８】
図７は、不選択度ｆを算出する具体例を示した図である。図７では、例えば、対象の社員が過去７日（７回）に選択したジャンルが図示するような状態であった場合について、各ジャンルについて数２に示した式に従って不選択度ｆを算出した場合の例を示している。なお、ジャンル履歴ＤＢ２２から直近７日（７回）のジャンルの履歴を取得するには、例えば飲食日の項目でソートした結果から最新の７レコードを抽出すればよい。また、抽出する範囲は直近７日に限定されないが、少なくともジャンルの種類の数（例えば本実施の形態では“和食”、“中華”、“洋食”、“韓国料理”、“イタリアン”の５つ）よりも大きい値であるほうが望ましい。
【００４９】
不選択度ｆは、値が大きいほど対象のジャンルが直近で選択されていない（飽きていない）程度が高いことを示すため、ジャンルとしての推薦の程度が高くなることを示す。すなわち、図７の例では、“イタリアン”、“和食”、“韓国料理”、“中華”、“洋食”の順で推薦の程度が高くなる。
【００５０】
なお、“イタリアン”については過去７日間で一度も選択されていない結果、不選択度ｆ（イタリアン）＝１．０となり、推薦の程度が最も高くなっている。しかし、この場合は対象の社員がそもそも“イタリアン”が好みではないことから選択していないだけということも考えられる。従って、対象の社員の各ジャンルに対する飽きだけではなく嗜好についても考慮する必要がある。そこで、過去に多く昼食に選択したジャンルほど嗜好する程度が高いと判断し、例えば以下の式によって、過去１００日間に選択した昼食のジャンルに基づいて、ジャンルＧについての嗜好の程度を示す嗜好度ｌ（Ｇ）を算出する。
【００５１】
【数３】
【００５２】
図８は、嗜好度ｌを算出する具体例を示した図である。図８では、例えば、対象の社員が過去１００日（１００回）に選択したジャンルを集計したものが図示するような状態であった場合について、各ジャンルについて数３に示した式に従って嗜好度ｌを算出した場合の例を示している。なお、ジャンル履歴ＤＢ２２から過去１００日（１００回）のジャンルの履歴を取得するには、上記と同様に例えば飲食日の項目でソートした結果から最新の１００レコードを抽出すればよい。過去１００回より前の履歴をメンテナンス処理等によってジャンル履歴ＤＢ２２から削除するようにしてもよい。また、抽出する履歴の範囲は過去１００日に限定されないが、嗜好を判断できるサンプル数として十分大きな値とするのが望ましい。
【００５３】
嗜好度ｌは、値が大きいほど対象の社員が当該ジャンルを好んでいる程度が高いことを示すため、ジャンルとしての推薦の程度が高くなることを示す。すなわち、図８の例では、“和食”、“中華”、“洋食”、“韓国”、“イタリアン”の順で推薦の程度が高くなる。
【００５４】
以上によって得られた各ジャンルＧについての不選択度ｆ（Ｇ）と嗜好度ｌ（Ｇ）に基づいて、例えば以下の式によって、ジャンルＧについてのジャンル毎推薦度２６（ｒ（Ｇ））を算出する。
【００５５】
【数４】
【００５６】
図９は、ジャンル毎推薦度ｒを算出する具体例を示した図である。図９では、例えば、各ジャンルＧについて算出された不選択度ｆ（Ｇ）と嗜好度ｌ（Ｇ）がそれぞれ図７、図８に示したような値であった場合について、各ジャンルについて数４に示した式に従ってジャンル毎推薦度ｒを算出した場合の例を示している。ジャンル毎推薦度ｒは、値が大きいほどジャンルとしての推薦の程度が高くなることを示す。すなわち、図９の例では、“和食”、“韓国料理”、“イタリアン”、“中華”、“洋食”の順で推薦の程度が高くなる。
【００５７】
各飲食店についての混雑回避度２５と、各ジャンルについてのジャンル毎推薦度２６とが算出されると、これらに基づいて各飲食店についての推薦の程度を示すスコアを算出する。具体的には、図２におけるステップＳ４での各飲食店のジャンルに対応する推薦度２７を取得する処理、およびステップＳ５での各飲食店についての推薦の程度を示すスコアを算出する処理を合わせて、例えば以下の式によって、各飲食店Ｒについての混雑回避度２５（ａ（Ｒ））と、各飲食店ＲのジャンルＧに対応するジャンル毎推薦度２６（ｒ（Ｇ））（すなわち図２における推薦度２７）とに基づいて、例えば以下の式によって、各飲食店ＲについてのスコアＳ（Ｒ，Ｇ）を算出する。
【００５８】
【数５】
【００５９】
このとき、上述したように、混雑回避度ａ（Ｒ）と、ジャンル毎推薦度ｒ（Ｇ）のいずれを重視するかに応じて、重み付け設定値２４（α）に従ってそれぞれの値に重み付けした上でスコアを算出することができる。
【００６０】
図１０は、スコアＳを算出する具体例を示した図である。図１０では、例えば、各飲食店Ｒについて算出された混雑回避度ａ（Ｒ）と、ジャンル毎推薦度ｒ（Ｇ）がそれぞれ図示するような状態であった場合について、各飲食店について数５に示した式に従ってスコアＳを算出した場合の例を示している。ここでは比較のため、重み付け設定値２４としてα＝０．５（混雑回避度ａとジャンル毎推薦度ｒを等しく評価）を適用した場合と、α＝０．８（混雑回避度ａを重視）を適用した場合とを示している。
【００６１】
スコアリングした結果、スコアＳが上位の順に飲食店を並べてランキング２８として出力する。すなわち、図１０の例では、スコアが上位３つの飲食店を提示するものとして、α＝０．５の場合は“店舗Ｄ”、“店舗Ｃ”、“店舗Ｂ”の順に、α＝０．８の場合は“店舗Ｄ”、“店舗Ｃ”、“店舗Ｅ”の順にランキング２８として出力する。
【００６２】
なお、上述したスコアの算出方法、および数１〜数５で示した各計算式はあくまで一例であり、近隣の各飲食店の混雑度、および対象の社員の嗜好と飽きを判断して得られるジャンルの推薦度を判断基準として利用するものであれば、他の算出方法や計算式であってもよい。
【００６３】
以上に説明したように、本発明の一実施の形態である飲食店推薦システム１によれば、例えば多数の社員を有する企業等において、昼食時の飲食店を推薦する際の判断基準として、各社員が一斉に近隣の飲食店に向かうことに伴う各飲食店の混雑度（混雑回避度２５）と、社員が過去の昼食の際に選択したジャンルの履歴に基づいて社員の嗜好と飽きを判断して得られるジャンルの推薦度（ジャンル毎推薦度２６および推薦度２７）の２つを利用してスコアを算出してランキング２８として提示する。これにより、社員に対して、混雑を回避しつつジャンルを考慮して飽きがこないように近隣の飲食店を推薦することが可能となり、社員が昼食時の飲食店を選択する際に要する労力や時間の浪費を解消することが可能となる。
【００６４】
以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。
【産業上の利用可能性】
【００６５】
本発明は、多数の社員を有する企業等において昼食時に社員に対して近隣の飲食店を推薦する飲食店推薦システムに利用可能である。
【符号の説明】
【００６６】
１…飲食店推薦システム、
１０…飲食店推薦サーバ、１１…社員所在収集部、１２…混雑度判定部、１３…ジャンル履歴管理部、１４…ジャンル推薦部、１５…飲食店推薦部、
２１…社員所在データベース（ＤＢ）、２２…ジャンル履歴ＤＢ、２３…飲食店ＤＢ、２４…重み付け設定値、２５…混雑回避度、２６…ジャンル毎推薦度、２７…推薦度、２８…ランキング、
３０…ネットワーク、
４０…携帯端末、
５０…ＧＰＳ。
【技術分野】
【０００１】
本発明は、ユーザに近隣の飲食店を推薦する技術に関し、特に、多数の社員を有する企業等において昼食時に社員に対して近隣の飲食店を推薦する飲食店推薦システムに適用して有効な技術に関するものである。
【背景技術】
【０００２】
従前より、インターネット等を利用して、ユーザに対して特定の地域における店舗や施設等を抽出して推薦するような情報処理システムが存在する。特に、例えばスマートフォン等の携帯端末をクライアント端末として利用することによって、ユーザの現在位置に基づいて近隣の店舗等を提示することが行われている。また、例えば、ユーザの行動履歴や操作履歴、嗜好や属性、さらには他のユーザ等によって登録されたいわゆるクチコミ情報などに基づいて、対象のユーザにより合致した店舗等をランキング形式で提示して推薦するようなシステムも存在する。
【０００３】
例えば、特開２０１０−９３１５号公報（特許文献１）には、店舗位置情報を含む店舗情報を店舗情報記憶手段に記憶しておくとともに、店舗名を含むクチコミ情報をクチコミ情報記憶手段に記憶しておき、携帯端末から端末位置情報を受信した場合に、店舗情報検索手段が、受信した端末位置情報に関連する店舗位置情報を有する店舗情報を抽出し、推薦店舗決定手段が、抽出した店舗情報に含まれる店舗名を含むクチコミ情報を抽出して各店舗の人気度を求め、人気度の高い店舗を推薦店舗として決定し、店舗情報送信手段が、推薦店舗の店舗情報を携帯端末に送信することで、インターネット上のクチコミ情報を活用して、利用者がいる場所付近における人気の店舗を検出し、利用者に対して提示することが可能な推薦店舗提示システムが記載されている。
【０００４】
また、例えば、特開２００８−１５８８２３号公報（特許文献２）には、各利用者ごとに、各ジャンルの特徴項目についての嗜好値を含む利用者嗜好情報が格納される利用者嗜好情報格納部と、各店舗ごとに、そのジャンルの特徴項目についての評価値を含む店舗評価情報が格納される店舗評価情報格納部と、利用者嗜好情報に合致した店舗評価情報をもつ店舗情報を選択して利用者に提供する店舗情報提供部とを有し、利用者が、特定の店舗情報を閲覧したり、特定の店舗を利用したりすると、当該特定の店舗が関心店舗記録部に関心店舗として蓄積され、蓄積された関心店舗の店舗評価情報に基づき利用者嗜好情報を更新する嗜好値更新部を有することで、店舗情報格納部内に用意された店舗情報を各利用者に提供する際に、各利用者の嗜好を正確に把握してこれを反映させた情報提供を行うことを可能とする情報提供システムが記載されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０１０−９３１５号公報
【特許文献２】特開２００８−１５８８２３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
例えば上記の特許文献１、２などに記載されているようなシステムを利用することで、ユーザの現在位置の近隣における人気の高い店舗や、ユーザの嗜好、属性等に合致した店舗をユーザに対して推薦することが可能である。
【０００７】
しかしながら、このように推薦された店舗等がユーザのあらゆる場面・状況において適切なものであるとは限らない。例えば、多数の社員が在籍する企業等においては、昼食時には多数の社員が一斉に勤務地のビル等の近隣の飲食店に向かうことになり、特に郊外などに所在する企業の場合は、繁華街と比べて近隣の飲食店の数も比較的少なく、これらの飲食店に社員が集中して混雑し易いという特徴を有する。このような状況で上記のような手段によって飲食店の推薦を受けてそこに向かったとしても、さらに混雑が激しくなるだけという結果になる。また、飲食店に到着してから混雑が判明すると、そこからまた別の飲食店を探すなどの労力を要することになり、通常昼食時の休憩時間は限られていることから、予め混雑を避けて飲食店を選択するという必要性は高い。
【０００８】
一方、毎日繰り返される昼食という点からは、連続して同じジャンルの飲食店に行くと通常は飽きてしまうため、直近に行った飲食店のジャンルを考慮して、別のジャンルの飲食店を選択するということも社員にとっては通常行われる行動である。しかし、ジャンルの選択に迷って時間を浪費するという場合も多々あり、時間的制約のある昼食時にはこのような無駄な時間を削減するという必要性も高い。
【０００９】
そこで本発明の目的は、企業の社員等に対して、昼食時における混雑を回避しつつ、ジャンルを考慮して飽きがこないように近隣の飲食店を推薦する飲食店推薦システムを提供することにある。本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。
【課題を解決するための手段】
【００１０】
本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。
【００１１】
本発明の代表的な実施の形態による飲食店推薦システムは、一つの拠点に複数のユーザが所在するグループにおいて、昼食時にユーザに対して近隣の飲食店を推薦する飲食店推薦システムであって、各ユーザが保有する携帯端末と、前記各携帯端末がネットワークを介して接続する飲食店推薦サーバとから構成され、以下の特徴を有するものである。
【００１２】
すなわち、前記飲食店推薦サーバは、前記携帯端末を介して取得した各ユーザの現在の所在に係る情報を保持するユーザ所在記録手段と、各ユーザが昼食時に利用可能な近隣の飲食店に係るマスタ情報を保持する飲食店記録手段と、ユーザが昼食時に実際に選択した飲食店のジャンルの情報をユーザ毎に履歴として蓄積保持するジャンル履歴記録手段とを有する。
【００１３】
さらに、前記ユーザ所在記録手段に記録された各ユーザの現在の所在の情報に基づいて、前記飲食店記録手段に保持する各飲食店についての混雑していない程度を示す混雑回避度を算出する混雑度判定部と、前記ジャンル履歴記録手段に記録された対象ユーザについてのジャンルの履歴に基づいて、前記対象ユーザの嗜好と飽きを判断して、前記対象ユーザについてのジャンル毎推薦度を算出するジャンル推薦部と、前記飲食店記録手段に保持する各飲食店について、前記混雑回避度と各飲食店のジャンルに対応する前記ジャンル毎推薦度とに基づいてスコアを算出し、前記スコアが上位の順に各飲食店を前記携帯端末を介して前記対象ユーザに提示する飲食店推薦部とを有することを特徴とするものである。
【発明の効果】
【００１４】
本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。
【００１５】
本発明の代表的な実施の形態によれば、企業の社員等に対して、昼食時における混雑を回避しつつ、ジャンルを考慮して飽きがこないように近隣の飲食店を推薦することが可能となり、社員等が昼食時の飲食店を選択する際に要する労力や時間の浪費を解消することが可能となる。
【図面の簡単な説明】
【００１６】
【図１】本発明の一実施の形態である飲食店推薦システムの構成例について概要を示した図である。
【図２】本発明の一実施の形態における飲食店の推薦処理の例について概要を示した図である。
【図３】本発明の一実施の形態における社員所在ＤＢのデータ構成の例を示した図である。
【図４】本発明の一実施の形態におけるジャンル履歴ＤＢのデータ構成の例を示した図である。
【図５】本発明の一実施の形態における飲食店ＤＢのデータ構成の例を示した図である。
【図６】本発明の一実施の形態における混雑回避度ａを算出する具体例を示した図である。
【図７】本発明の一実施の形態における不選択度ｆを算出する具体例を示した図である。
【図８】本発明の一実施の形態における嗜好度ｌを算出する具体例を示した図である。
【図９】本発明の一実施の形態におけるジャンル毎推薦度ｒを算出する具体例を示した図である。
【図１０】本発明の一実施の形態におけるスコアＳを算出する具体例を示した図である。
【発明を実施するための形態】
【００１７】
以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。
【００１８】
＜概要＞
本発明の一実施の形態である飲食店推薦システムは、例えば多数の社員を有する企業など、一つの拠点に複数のユーザが所在するグループにおいて、昼食時にユーザ（本実施の形態では企業の社員を例とする）に対して、混雑を回避しつつジャンルを考慮して飽きがこないように近隣の飲食店を推薦することを可能とする情報処理システムである。本実施の形態では、昼食時の飲食店を推薦する際の判断基準として、各社員が一斉に近隣の飲食店に向かうことに伴う各飲食店の混雑度と、社員が過去の昼食の際に選択したジャンルの履歴に基づいて社員の嗜好と飽きを判断して得られるジャンルの推薦度の２つを利用する。
【００１９】
図２は、本実施の形態の飲食店推薦システムによる飲食店の推薦処理の例について概要を示した図である。図２の左側では混雑度の判定を行う処理が行われ、右側ではジャンルを推薦する処理が行われることを示している。混雑度の判定処理においては、まず、社員が企業から貸与等されて保有しているスマートフォン等の携帯端末４０を利用して、各社員が昼食時にどこ（の飲食店）にいるかについての所在の情報を収集しておく（Ｓ１）。ここでは、例えば携帯端末４０がＧＰＳ（Global Positioning System）５０を利用して取得した位置情報を利用する。この位置情報は、例えば社員所在ＤＢ２１としてデータベースに記録しておく。
【００２０】
この社員所在ＤＢ２１に記録された各社員の所在の情報に基づいて、近隣の各飲食店についての混雑回避度２５を算出する（Ｓ２）。近隣の飲食店に係る情報は、例えば飲食店ＤＢ２３に予めマスタとして登録されている。なお、本実施の形態では、各飲食店が混雑している程度を示す混雑度に加えて、混雑していない（混雑を回避できる）程度を示す混雑回避度２５を混雑度に基づいて算出し、これを利用するものとする。
【００２１】
一方、ジャンルを推薦する処理においては、まず、各社員が過去の昼食の際に選択したジャンルの履歴の情報がジャンル履歴ＤＢ２２のデータベースに蓄積されており、社員からの携帯端末４０を介した飲食店の推薦要求をトリガとして、ジャンル履歴ＤＢ２２の情報に基づいて対象の社員の嗜好や飽きを判断し、対象の社員に対するジャンル毎の推薦度であるジャンル毎推薦度２６を算出する（Ｓ３）。このジャンル毎推薦度２６を参照することで、飲食店ＤＢ２３に登録されている各飲食店について、その店のジャンルに対応する推薦度２７を得る（Ｓ４）。
【００２２】
上記の処理で得られた各飲食店についての混雑回避度２５と推薦度２７とに基づいて各飲食店についてのスコアを算出し（Ｓ５）、スコアが上位の順に飲食店を並べたものをランキング２８として携帯端末４０を介して社員に提示する。なお、ステップＳ５におけるスコアリングの際には、予め設定した重み付け設定値２４によって、混雑回避度２５と推薦度２７のいずれを重視するかに応じて値に重み付けした上でスコアを算出することができる。
【００２３】
社員は、ランキング２８を参照することで昼食時の飲食店を選択した上で対象の飲食店に向かうことができ、飲食店の選択に要する労力や時間の浪費を解消することができる。なお、実際に飲食店で昼食をとっている際の当該社員の所在の情報は、携帯端末４０のＧＰＳ機能によって社員所在ＤＢ２１にフィードバックされる。また、社員が実際に選択した飲食店のジャンルに係る情報は、ジャンル履歴ＤＢ２２に蓄積される。
【００２４】
＜システム構成＞
図１は、本発明の一実施の形態である飲食店推薦システムの構成例について概要を示した図である。飲食店推薦システム１は、例えば、上述した飲食店推薦サービスを社員に提供する企業等が運用管理するサーバ等のコンピュータ機器からなる飲食店推薦サーバ１０と、当該企業の社員等がそれぞれ保有するスマートフォン等の携帯端末４０から構成される。各携帯端末４０は、無線によるデータ通信機能を利用して、インターネットやイントラネット等のネットワーク３０を介して飲食店推薦サーバ１０に接続することができる。
【００２５】
飲食店推薦サーバ１０は、図示しないＯＳ（Operating System）やＷｅｂサーバプログラム、データベース管理プログラムなどのミドルウェアを有し、さらに、例えばこれらの上で稼働するソフトウェアプログラムとして実装される、社員所在収集部１１、混雑度判定部１２、ジャンル履歴管理部１３、ジャンル推薦部１４、および飲食店推薦部１５などの各部を有する。また、例えばデータベースとして構成される社員所在ＤＢ２１、ジャンル履歴ＤＢ２２、および飲食店ＤＢ２３や、設定ファイル等として構成される重み付け設定値２４などの各データを有する。
【００２６】
一方、携帯端末４０は、上述したようにＧＰＳ５０を利用して位置情報を取得する機能を有しており、また、図示しないＷｅｂブラウザ等のソフトウェアプログラムや、専用のアプリケーションプログラムなどにより、ネットワーク３０を介して飲食店推薦サーバ１０にアクセスして、上記の位置情報を含む所定の情報を送信したり飲食店の推薦要求を送信したりして飲食店推薦サービスを実行することができる。なお、位置情報の送信については、ＧＰＳ５０によって得られた位置情報に限らず、社員が現在地の住所等を手動で入力したり、携帯端末４０に表示された地図上の対応する箇所をタップ等によって指定したりするなどの手段により得た位置情報であってもよい。
【００２７】
飲食店推薦サーバ１０の社員所在収集部１１は、図２のステップＳ１における処理として、携帯端末４０から送信されたＧＰＳ５０等による位置情報を取得し、社員所在ＤＢ２１に記録する。このとき、ＧＰＳ５０等による位置情報だけでなく、当該位置情報と後述する飲食店ＤＢ２３に保持している各飲食店の位置情報とをマッチングすることにより、どの飲食店にいるかについての情報を算出しておき、この情報を保持するようにしてもよい。
【００２８】
混雑度判定部１２は、図２のステップＳ２における処理として、社員所在ＤＢ２１に記録された各社員の現在の所在の情報に基づいて、飲食店ＤＢ２３にマスタとして登録されている近隣の飲食店毎に混雑回避度２５を算出する。ここでは、各飲食店の位置情報と各社員の現在の位置情報とをマッチングすることにより、各飲食店にいると推定される社員の数を算出し、これに基づいて各飲食店の混雑回避度２５を算出する。
【００２９】
ジャンル履歴管理部１３は、社員が実際に昼食時に選択した飲食店のジャンルの情報を携帯端末４０を介した社員からの入力等を利用して取得し、これを履歴情報としてジャンル履歴ＤＢ２２に所定の期間分蓄積する。なお、社員がジャンルの情報を携帯端末４０から入力するためのユーザインタフェースを提供するソフトウェアプログラムが飲食店推薦サーバ１０もしくは携帯端末４０に実装される。
【００３０】
ジャンル推薦部１４は、図２のステップＳ３における処理として、ジャンル履歴ＤＢ２２に蓄積された対象の社員の昼食時のジャンルの履歴の情報を解析して、対象の社員の嗜好や飽きを判断して、対象の社員についてのジャンル毎推薦度２６を算出する。
【００３１】
飲食店推薦部１５は、図２のステップＳ４およびＳ５における処理として、飲食店ＤＢ２３に登録された各飲食店について、ジャンル推薦部１４によって算出されたジャンル毎推薦度２６を参照して得られる各飲食店のジャンルに対応する推薦度２７と、混雑度判定部１２によって算出された各飲食店の混雑回避度２５とに基づいてスコアを算出し、スコアが上位の順に飲食店をランキング２８として出力することで社員に提示する。このとき、予め設定された重み付け設定値２４によって、混雑回避度２５と推薦度２７のいずれを重視するかに応じてそれぞれの値に重み付けした上でスコアを算出することができる。
【００３２】
上記の各部以外にも、例えば、各社員が飲食店推薦サーバ１０にアクセスする際のユーザ認証を行うための認証部などを有していてもよい。また、各社員が例えば、自身が好む／好まない昼食のジャンルや飲食店の情報を嗜好に係る情報として予め登録できるようにしておき、ジャンル推薦部１４が対象の社員についてのジャンル毎推薦度２６を算出したり、飲食店推薦部１５が飲食店毎のスコアを算出したりする際に利用できるようにしてもよい。
【００３３】
＜データ構成＞
図３は、社員所在ＤＢ２１のデータ構成の例を示した図である。社員所在ＤＢ２１は、各社員の現在の所在に係る情報を保持するテーブルであり、例えば、社員ＩＤ、位置情報、所在飲食店、および更新日時などの各項目を有する。キー項目は社員ＩＤである。
【００３４】
社員ＩＤの項目は、各社員を一意に識別することができるＩＤや社員番号等の情報を保持する。位置情報の項目は、対象の社員の現在の所在位置に係る情報であり、対象の社員が保有する携帯端末４０がＧＰＳ５０等を利用して取得した位置情報を保持する。ＧＰＳ５０を利用した場合、位置情報は緯度・経度の情報として構成されるが、例えば多数の飲食店が入居するビルにおける階の情報を判断可能とするために高さ情報を含んでいてもよい。また、位置情報が緯度・経度ではなく住所等の他の形式の場合には、社員所在収集部１１等により緯度・経度の情報に変換するなどの処理を行ってもよい。
【００３５】
所在飲食店の項目は、対象の社員の現在の位置情報に基づいて、後述する飲食店ＤＢ２３に保持している各飲食店の位置情報とのマッチングによりどの飲食店にいるかを算出した結果の情報を保持する。更新日時の項目は、対象の社員についての所在の情報が最後に更新されたタイムスタンプの情報を保持する。
【００３６】
図４は、ジャンル履歴ＤＢ２２のデータ構成の例を示した図である。ジャンル履歴ＤＢ２２は、各社員が毎日（毎回）の昼食時に実際に選択した飲食店のジャンルの情報を社員毎に履歴として蓄積保持するテーブルであり、例えば、社員ＩＤ、飲食日、ジャンル、および店舗ＩＤなどの各項目を有する。キー項目は社員ＩＤと飲食日である。
【００３７】
社員ＩＤの項目は、履歴情報の対象となる社員を特定するＩＤ情報であり、図３の社員所在ＤＢ２１における社員ＩＤの項目と同様である。飲食日の項目は、対象の社員が昼食をとった日付の情報を保持する。ジャンルおよび店舗ＩＤの項目は、対象の社員が対象の日の昼食時に選択したジャンルおよびその飲食店を特定する店舗ＩＤの情報をそれぞれ保持する。なお、これ以外にも例えば、飲食店が複数ジャンルのメニューを有する場合なども考慮して、対象の社員が実際に選択したメニューに関する情報を保持する項目や、選択した飲食店／メニューについての対象の社員による評価の情報を保持する項目などを有して、ジャンル履歴ＤＢ２２に蓄積された履歴情報に基づいて各社員のジャンルに対する嗜好をより詳細に解析できるようにしてもよい。
【００３８】
図５は、飲食店ＤＢ２３のデータ構成の例を示した図である。飲食店ＤＢ２３は、社員が昼食時に利用可能な近隣の飲食店に係るマスタ情報を保持するテーブルであり、例えば、店舗ＩＤ、店舗名、住所、位置情報、ジャンル、座席数、および社員比率などの各項目を有する。キー項目は店舗ＩＤである。
【００３９】
店舗ＩＤの項目は、各飲食店を一意に識別することができるＩＤの情報を保持する。当該店舗ＩＤの値は、例えば管理者等が飲食店のマスタ情報を飲食店ＤＢ２３に登録する際に、飲食店推薦サーバ１０が自動で割り当てるようにすることができる。店舗名の項目は、対象の飲食店の名称の情報を保持する。住所および位置情報の項目は、対象の飲食店の所在に係る情報として、住所および位置情報をそれぞれ保持する。位置情報は、図３の社員所在ＤＢ２１における位置情報の項目とマッチングするため、これと同様の緯度、経度の形式で保持する。対象の飲食店が多数の飲食店が入居するビル内などにある場合を考慮して高さ情報を含んでいてもよい。
【００４０】
ジャンルの項目は、対象の飲食店における昼食のジャンル（例えば“和食”や“中華”など）の情報を保持する。飲食店が複数ジャンルのメニューを有する場合なども考慮して、ジャンルの情報を複数保持できるようにしてもよい。座席数の項目は、対象の飲食店が有する全座席の数の情報を保持する。社員比率の項目は、対象の飲食店における昼食時の来店客構成の情報として、全ての来店客に占める当該企業の社員の割合の情報を保持する。例えば、社員比率＝１．０の場合には、対象の飲食店における来店客の全てが当該企業の社員であることを示す。同様に、例えば、社員比率＝０．８の場合には、来店客の８割が当該企業の社員であり、それ以外に２割の一般の来店客が存在することを示す。
【００４１】
なお、この社員比率の情報は厳密である必要はなく、例えば、対象の飲食店で昼食をとった社員から、大まかな来店客構成の情報をヒアリングや携帯端末４０を利用した入力等によって取得し、その統計情報等から算出することなどが考えられる。この社員比率の値と対象の飲食店にいると推測される社員の数（図３の社員所在ＤＢ２１を集計して算出することができる）とに基づいて、対象の飲食店にいる全ての来店客数を推測することができる。
【００４２】
なお、上述の図３〜図５で示した各テーブルのデータ構成（項目）はあくまで一例であり、同様のデータを保持・管理することが可能な構成であれば、他のテーブル構成やデータ構成であってもよい。
【００４３】
＜スコア算出方法＞
以下では、図２に示した飲食店の推薦処理の例において、各飲食店についてのスコアを算出する際の具体的な手順について説明する。まず、図２における混雑度の判定処理として、ステップＳ２の混雑回避度２５の算出処理では、飲食店ＤＢ２３に保持する各飲食店について、対象の飲食店の座席数と対象の飲食店に現在来店していると推測される社員数（図３の社員所在ＤＢ２１を集計して算出することができる）、および対象の飲食店の社員比率に基づいて混雑回避度２５を算出する。具体的には、例えば以下の式によって、飲食店Ｒについての混雑率ｃ（Ｒ）を算出し、さらに混雑回避度２５（ａ（Ｒ））を算出する。
【００４４】
【数１】
【００４５】
図６は、混雑回避度ａを算出する具体例を示した図である。図６では、例えば、図示するような座席数、来店客としての社員数、および社員比率を有する“店舗Ａ”、“店舗Ｂ”について、それぞれ数１に示した式に従って混雑回避度ａを算出した場合の例を示している。混雑回避度ａは、値が大きいほど対象の飲食店が混雑していない（混雑を回避できる）ことを示すため、推薦の程度が高くなることを示す。すなわち、図６の例では、“店舗Ｂ”の混雑回避度ａ（店舗Ｂ）＝０．３０のほうが“店舗Ａ”の混雑回避度ａ（店舗Ａ）＝０．２９より値が大きいため、混雑という観点からは“店舗Ｂ”のほうが推薦の程度が高くなる。
【００４６】
一方、図２におけるジャンルの推薦処理として、ステップＳ３のジャンル毎推薦度２６の算出処理では、対象の社員について、ジャンル履歴ＤＢ２２に蓄積された昼食時に選択したジャンルの情報を解析して、当該社員の各ジャンルについての嗜好と飽きの程度を判定し、これらに基づいてジャンル毎推薦度２６を算出する。具体的には、飽きの程度として、直近で昼食に選択したジャンルほど飽きている程度が高い（選択されていないジャンルほど飽きていない程度が高い）と判断し、例えば以下の式によって、過去７日間に選択した昼食のジャンルに基づいて、ジャンルＧについての飽きていない程度を示す不選択度ｆ（Ｇ）を算出する。
【００４７】
【数２】
【００４８】
図７は、不選択度ｆを算出する具体例を示した図である。図７では、例えば、対象の社員が過去７日（７回）に選択したジャンルが図示するような状態であった場合について、各ジャンルについて数２に示した式に従って不選択度ｆを算出した場合の例を示している。なお、ジャンル履歴ＤＢ２２から直近７日（７回）のジャンルの履歴を取得するには、例えば飲食日の項目でソートした結果から最新の７レコードを抽出すればよい。また、抽出する範囲は直近７日に限定されないが、少なくともジャンルの種類の数（例えば本実施の形態では“和食”、“中華”、“洋食”、“韓国料理”、“イタリアン”の５つ）よりも大きい値であるほうが望ましい。
【００４９】
不選択度ｆは、値が大きいほど対象のジャンルが直近で選択されていない（飽きていない）程度が高いことを示すため、ジャンルとしての推薦の程度が高くなることを示す。すなわち、図７の例では、“イタリアン”、“和食”、“韓国料理”、“中華”、“洋食”の順で推薦の程度が高くなる。
【００５０】
なお、“イタリアン”については過去７日間で一度も選択されていない結果、不選択度ｆ（イタリアン）＝１．０となり、推薦の程度が最も高くなっている。しかし、この場合は対象の社員がそもそも“イタリアン”が好みではないことから選択していないだけということも考えられる。従って、対象の社員の各ジャンルに対する飽きだけではなく嗜好についても考慮する必要がある。そこで、過去に多く昼食に選択したジャンルほど嗜好する程度が高いと判断し、例えば以下の式によって、過去１００日間に選択した昼食のジャンルに基づいて、ジャンルＧについての嗜好の程度を示す嗜好度ｌ（Ｇ）を算出する。
【００５１】
【数３】
【００５２】
図８は、嗜好度ｌを算出する具体例を示した図である。図８では、例えば、対象の社員が過去１００日（１００回）に選択したジャンルを集計したものが図示するような状態であった場合について、各ジャンルについて数３に示した式に従って嗜好度ｌを算出した場合の例を示している。なお、ジャンル履歴ＤＢ２２から過去１００日（１００回）のジャンルの履歴を取得するには、上記と同様に例えば飲食日の項目でソートした結果から最新の１００レコードを抽出すればよい。過去１００回より前の履歴をメンテナンス処理等によってジャンル履歴ＤＢ２２から削除するようにしてもよい。また、抽出する履歴の範囲は過去１００日に限定されないが、嗜好を判断できるサンプル数として十分大きな値とするのが望ましい。
【００５３】
嗜好度ｌは、値が大きいほど対象の社員が当該ジャンルを好んでいる程度が高いことを示すため、ジャンルとしての推薦の程度が高くなることを示す。すなわち、図８の例では、“和食”、“中華”、“洋食”、“韓国”、“イタリアン”の順で推薦の程度が高くなる。
【００５４】
以上によって得られた各ジャンルＧについての不選択度ｆ（Ｇ）と嗜好度ｌ（Ｇ）に基づいて、例えば以下の式によって、ジャンルＧについてのジャンル毎推薦度２６（ｒ（Ｇ））を算出する。
【００５５】
【数４】
【００５６】
図９は、ジャンル毎推薦度ｒを算出する具体例を示した図である。図９では、例えば、各ジャンルＧについて算出された不選択度ｆ（Ｇ）と嗜好度ｌ（Ｇ）がそれぞれ図７、図８に示したような値であった場合について、各ジャンルについて数４に示した式に従ってジャンル毎推薦度ｒを算出した場合の例を示している。ジャンル毎推薦度ｒは、値が大きいほどジャンルとしての推薦の程度が高くなることを示す。すなわち、図９の例では、“和食”、“韓国料理”、“イタリアン”、“中華”、“洋食”の順で推薦の程度が高くなる。
【００５７】
各飲食店についての混雑回避度２５と、各ジャンルについてのジャンル毎推薦度２６とが算出されると、これらに基づいて各飲食店についての推薦の程度を示すスコアを算出する。具体的には、図２におけるステップＳ４での各飲食店のジャンルに対応する推薦度２７を取得する処理、およびステップＳ５での各飲食店についての推薦の程度を示すスコアを算出する処理を合わせて、例えば以下の式によって、各飲食店Ｒについての混雑回避度２５（ａ（Ｒ））と、各飲食店ＲのジャンルＧに対応するジャンル毎推薦度２６（ｒ（Ｇ））（すなわち図２における推薦度２７）とに基づいて、例えば以下の式によって、各飲食店ＲについてのスコアＳ（Ｒ，Ｇ）を算出する。
【００５８】
【数５】
【００５９】
このとき、上述したように、混雑回避度ａ（Ｒ）と、ジャンル毎推薦度ｒ（Ｇ）のいずれを重視するかに応じて、重み付け設定値２４（α）に従ってそれぞれの値に重み付けした上でスコアを算出することができる。
【００６０】
図１０は、スコアＳを算出する具体例を示した図である。図１０では、例えば、各飲食店Ｒについて算出された混雑回避度ａ（Ｒ）と、ジャンル毎推薦度ｒ（Ｇ）がそれぞれ図示するような状態であった場合について、各飲食店について数５に示した式に従ってスコアＳを算出した場合の例を示している。ここでは比較のため、重み付け設定値２４としてα＝０．５（混雑回避度ａとジャンル毎推薦度ｒを等しく評価）を適用した場合と、α＝０．８（混雑回避度ａを重視）を適用した場合とを示している。
【００６１】
スコアリングした結果、スコアＳが上位の順に飲食店を並べてランキング２８として出力する。すなわち、図１０の例では、スコアが上位３つの飲食店を提示するものとして、α＝０．５の場合は“店舗Ｄ”、“店舗Ｃ”、“店舗Ｂ”の順に、α＝０．８の場合は“店舗Ｄ”、“店舗Ｃ”、“店舗Ｅ”の順にランキング２８として出力する。
【００６２】
なお、上述したスコアの算出方法、および数１〜数５で示した各計算式はあくまで一例であり、近隣の各飲食店の混雑度、および対象の社員の嗜好と飽きを判断して得られるジャンルの推薦度を判断基準として利用するものであれば、他の算出方法や計算式であってもよい。
【００６３】
以上に説明したように、本発明の一実施の形態である飲食店推薦システム１によれば、例えば多数の社員を有する企業等において、昼食時の飲食店を推薦する際の判断基準として、各社員が一斉に近隣の飲食店に向かうことに伴う各飲食店の混雑度（混雑回避度２５）と、社員が過去の昼食の際に選択したジャンルの履歴に基づいて社員の嗜好と飽きを判断して得られるジャンルの推薦度（ジャンル毎推薦度２６および推薦度２７）の２つを利用してスコアを算出してランキング２８として提示する。これにより、社員に対して、混雑を回避しつつジャンルを考慮して飽きがこないように近隣の飲食店を推薦することが可能となり、社員が昼食時の飲食店を選択する際に要する労力や時間の浪費を解消することが可能となる。
【００６４】
以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。
【産業上の利用可能性】
【００６５】
本発明は、多数の社員を有する企業等において昼食時に社員に対して近隣の飲食店を推薦する飲食店推薦システムに利用可能である。
【符号の説明】
【００６６】
１…飲食店推薦システム、
１０…飲食店推薦サーバ、１１…社員所在収集部、１２…混雑度判定部、１３…ジャンル履歴管理部、１４…ジャンル推薦部、１５…飲食店推薦部、
２１…社員所在データベース（ＤＢ）、２２…ジャンル履歴ＤＢ、２３…飲食店ＤＢ、２４…重み付け設定値、２５…混雑回避度、２６…ジャンル毎推薦度、２７…推薦度、２８…ランキング、
３０…ネットワーク、
４０…携帯端末、
５０…ＧＰＳ。
【特許請求の範囲】
【請求項１】
一つの拠点に複数のユーザが所在するグループにおいて、昼食時にユーザに対して近隣の飲食店を推薦する飲食店推薦システムであって、
各ユーザが保有する携帯端末と、前記各携帯端末がネットワークを介して接続する飲食店推薦サーバとから構成され、
前記飲食店推薦サーバは、
前記携帯端末を介して取得した各ユーザの現在の所在に係る情報を保持するユーザ所在記録手段と、各ユーザが昼食時に利用可能な近隣の飲食店に係るマスタ情報を保持する飲食店記録手段と、ユーザが昼食時に実際に選択した飲食店のジャンルの情報をユーザ毎に履歴として蓄積保持するジャンル履歴記録手段とを有し、さらに、
前記ユーザ所在記録手段に記録された各ユーザの現在の所在の情報に基づいて、前記飲食店記録手段に保持する各飲食店についての混雑していない程度を示す混雑回避度を算出する混雑度判定部と、
前記ジャンル履歴記録手段に記録された対象ユーザについてのジャンルの履歴に基づいて、前記対象ユーザの嗜好と飽きを判断して、前記対象ユーザについてのジャンル毎推薦度を算出するジャンル推薦部と、
前記飲食店記録手段に保持する各飲食店について、前記混雑回避度と各飲食店のジャンルに対応する前記ジャンル毎推薦度とに基づいてスコアを算出し、前記スコアが上位の順に各飲食店を前記携帯端末を介して前記対象ユーザに提示する飲食店推薦部とを有することを特徴とする飲食店推薦システム。
【請求項２】
請求項１に記載の飲食店推薦システムにおいて、
前記ジャンル推薦部は、
前記ジャンル履歴記録手段に記録された前記対象ユーザについてのジャンルの履歴における直近の所定の数の履歴に基づいて、ジャンル毎に前記対象ユーザに選択されていない程度を不選択度として算出し、
また、前記ジャンル履歴記録手段に記録された前記対象ユーザについてのジャンルの履歴における過去の所定の数の履歴に基づいて、ジャンル毎に前記対象ユーザに選択された回数から嗜好度を算出し、
前記不選択度と前記嗜好度とに基づいて前記対象ユーザについての前記ジャンル毎推薦度を算出することを特徴とする飲食店推薦システム。
【請求項３】
請求項１または２に記載の飲食店推薦システムにおいて、
前記混雑度判定部は、
前記ユーザ所在記録手段を集計して算出された各飲食店に現在来店していると推測されるユーザの数と、前記飲食店記録手段に保持する各飲食店における昼食時の来店客に占める前記グループに属するユーザの割合の情報とに基づいて、各飲食店についての昼食時の全来店客数を推測し、これに基づいて各飲食店についての前記混雑回避度を算出することを特徴とする飲食店推薦システム。
【請求項４】
請求項１〜３のいずれか１項に記載の飲食店推薦システムにおいて、
前記飲食店推薦部は、
各飲食店についての前記混雑回避度と各飲食店のジャンルに対応する前記ジャンル毎推薦度とに基づいてスコアを算出する際、予め設定された重み付け設定値によって、前記混雑回避度と前記ジャンル推薦度の値にそれぞれ重み付けした上で前記スコアを算出することを特徴とする飲食店推薦システム。
【請求項５】
請求項１〜４のいずれか１項に記載の飲食店推薦システムにおいて、
前記飲食店推薦サーバは、さらに、
各ユーザが保有する前記携帯端末から、前記携帯端末のＧＰＳ機能により取得した位置情報を取得して、各ユーザの現在の所在に係る情報として前記ユーザ所在記録手段に記録するユーザ所在収集部を有することを特徴とする飲食店推薦システム。
【請求項１】
一つの拠点に複数のユーザが所在するグループにおいて、昼食時にユーザに対して近隣の飲食店を推薦する飲食店推薦システムであって、
各ユーザが保有する携帯端末と、前記各携帯端末がネットワークを介して接続する飲食店推薦サーバとから構成され、
前記飲食店推薦サーバは、
前記携帯端末を介して取得した各ユーザの現在の所在に係る情報を保持するユーザ所在記録手段と、各ユーザが昼食時に利用可能な近隣の飲食店に係るマスタ情報を保持する飲食店記録手段と、ユーザが昼食時に実際に選択した飲食店のジャンルの情報をユーザ毎に履歴として蓄積保持するジャンル履歴記録手段とを有し、さらに、
前記ユーザ所在記録手段に記録された各ユーザの現在の所在の情報に基づいて、前記飲食店記録手段に保持する各飲食店についての混雑していない程度を示す混雑回避度を算出する混雑度判定部と、
前記ジャンル履歴記録手段に記録された対象ユーザについてのジャンルの履歴に基づいて、前記対象ユーザの嗜好と飽きを判断して、前記対象ユーザについてのジャンル毎推薦度を算出するジャンル推薦部と、
前記飲食店記録手段に保持する各飲食店について、前記混雑回避度と各飲食店のジャンルに対応する前記ジャンル毎推薦度とに基づいてスコアを算出し、前記スコアが上位の順に各飲食店を前記携帯端末を介して前記対象ユーザに提示する飲食店推薦部とを有することを特徴とする飲食店推薦システム。
【請求項２】
請求項１に記載の飲食店推薦システムにおいて、
前記ジャンル推薦部は、
前記ジャンル履歴記録手段に記録された前記対象ユーザについてのジャンルの履歴における直近の所定の数の履歴に基づいて、ジャンル毎に前記対象ユーザに選択されていない程度を不選択度として算出し、
また、前記ジャンル履歴記録手段に記録された前記対象ユーザについてのジャンルの履歴における過去の所定の数の履歴に基づいて、ジャンル毎に前記対象ユーザに選択された回数から嗜好度を算出し、
前記不選択度と前記嗜好度とに基づいて前記対象ユーザについての前記ジャンル毎推薦度を算出することを特徴とする飲食店推薦システム。
【請求項３】
請求項１または２に記載の飲食店推薦システムにおいて、
前記混雑度判定部は、
前記ユーザ所在記録手段を集計して算出された各飲食店に現在来店していると推測されるユーザの数と、前記飲食店記録手段に保持する各飲食店における昼食時の来店客に占める前記グループに属するユーザの割合の情報とに基づいて、各飲食店についての昼食時の全来店客数を推測し、これに基づいて各飲食店についての前記混雑回避度を算出することを特徴とする飲食店推薦システム。
【請求項４】
請求項１〜３のいずれか１項に記載の飲食店推薦システムにおいて、
前記飲食店推薦部は、
各飲食店についての前記混雑回避度と各飲食店のジャンルに対応する前記ジャンル毎推薦度とに基づいてスコアを算出する際、予め設定された重み付け設定値によって、前記混雑回避度と前記ジャンル推薦度の値にそれぞれ重み付けした上で前記スコアを算出することを特徴とする飲食店推薦システム。
【請求項５】
請求項１〜４のいずれか１項に記載の飲食店推薦システムにおいて、
前記飲食店推薦サーバは、さらに、
各ユーザが保有する前記携帯端末から、前記携帯端末のＧＰＳ機能により取得した位置情報を取得して、各ユーザの現在の所在に係る情報として前記ユーザ所在記録手段に記録するユーザ所在収集部を有することを特徴とする飲食店推薦システム。
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１】
【図２】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１】
【図２】
【公開番号】特開２０１２−１１３５４４（Ｐ２０１２−１１３５４４Ａ）
【公開日】平成２４年６月１４日（２０１２．６．１４）
【国際特許分類】
【出願番号】特願２０１０−２６２５９７（Ｐ２０１０−２６２５９７）
【出願日】平成２２年１１月２５日（２０１０．１１．２５）
【出願人】（０００１５５４６９）株式会社野村総合研究所 (1,067)
【Ｆターム（参考）】
【公開日】平成２４年６月１４日（２０１２．６．１４）
【国際特許分類】
【出願日】平成２２年１１月２５日（２０１０．１１．２５）
【出願人】（０００１５５４６９）株式会社野村総合研究所 (1,067)
【Ｆターム（参考）】
[ Back to top ]