JP5636323B2 - 情報処理装置 - Google Patents

Description

本発明は、ユーザからの問い合わせに応じて店舗情報を提案するコンシェルジュ業務を支援する情報処理装置に関する。

従来から、ユーザが希望する飲食店やホテル等の施設を検索する検索システムが広く利用されている。この検索システムは、一般的に、ユーザが希望する施設の場所や料金などの検索条件の入力を受け、その検索条件に対応する施設をデータベースから検索してユーザに提示するようになっている。

上記のような検索システムは、例えば、特許文献１に開示されている。特許文献１の検索システムは、ユーザ端末と、当該ユーザ端末にネットワークを介して接続されたサーバ装置とにより構成されている。このサーバ装置は、ユーザ端末から入力される「業種、企業名、商品名」及び「エリア指定」を検索条件として受け付け、当該検索条件に該当する店舗を検索し、ユーザ端末に指定されたエリアの地図上に、店舗の位置を配置した表示データを送信するようになっている。

しかし、特許文献１の検索システムは、検索する対象が「業種、企業名、商品名」を特定できる場合に機能するものの、ユーザの漠然としたニーズや潜在ニーズに対応できないという問題を有している。特許文献１の検索システムは、例えば、「銀座で面白い店へ行きたい」等のニーズしか持っていないユーザに対して、そのユーザのニーズに応える店舗を検索することができない。

そして、上記のようなユーザの漠然としたニーズに応えるため、オペレータ（コンシェルジュ）によるコンシェルジュサービスを提供する事業者も現れている。このコンシェルジュサービスでは、オペレータがユーザからの飲食店やホテルなどに対する要望（ユーザの漠然としたニーズ等）についてヒアリングし、ユーザが求めている飲食店やホテルに関する情報を調べ、その調べた飲食店やホテルに関する情報をメール等でユーザに知らせている。

特開２００２−８２９５８号公報

しかしながら、上述したオペレータによるコンシェルジュサービスは、以下に示す技術的課題を有している。具体的には、コンシェルジュサービスを提供するオペレータは、ユーザの潜在ニーズ（曖昧なニーズ）に応えるリコメンドを行うために、ユーザの置かれているオケージョン、ユーザの価値観、要望等を把握した上で、オペレータ自身がユーザの要望に対応する飲食店を選定（判断）する必要がある。そのため、オペレータは、ユーザに対し、様々な質問をしてユーザのオケージョン、ユーザの価値観、要望等を把握しなければならず、そのやり取り（質問の応答）や判断に長時間費やされるという技術的課題を有している。すなわち、上述したオペレータによるコンシェルジュサービでは、ユーザに迅速に回答できないことがあった。また、オペレータとのやり取りがユーザのストレスを招いていた。

本発明は上記技術的課題に鑑みてなされたものであって、ユーザからの問い合わせに応じて店舗情報を提供するコンシェルジュ業務を支援する情報処理装置において、ユーザに手間をかけさせることなく短時間でユーザの要望に応える情報を提供できるようにすることを目的とする。

上記技術的課題を解決するための本発明は、ユーザからの問い合わせに応じて店舗情報を提案するコンシェルジュ業務を支援する情報処理装置であって、ユーザの識別情報毎に該ユーザの外食に対する考え方を示した外食価値観を関連付けたユーザデータベースと、店舗があるエリアと前記外食価値観と店舗の利用場面・利用状況を示す外食オケージョンとの組合せ毎にユーザの店舗に対するニーズを示したデータを関連付けたニーズ判定テーブルと、前記ユーザの識別情報、ユーザが探している店舗のエリア及びユーザが希望している前記外食オケージョンの入力を受け付ける入力部と、前記入力を受け付けたユーザの識別情報及び前記ユーザデータベースを用いて前記ユーザの外食価値観を特定すると共に、前記特定した外食価値観、前記入力を受け付けたエリア、前記入力を受け付けた外食オケージョン及び前記ニーズ判定テーブルからユーザの飲食店に対するニーズを選定して出力する情報選定部とを備えていることを特徴としている。

このように、本発明の情報処理装置は、ユーザの識別情報、ユーザが探している店舗のエリア及びユーザが希望している外食オケージョンの入力を受け付けることにより、ユーザデータベース及びニーズ判定テーブルを用いて、「エリア」、「外食価値観」、及び「外食オケージョン」から推定されるユーザのニーズを選定するようになっている。すなわち、本発明によれば、面倒な質疑応答をすることなく、ユーザの飲食店に対するニーズが選定されるため、ユーザの要求に応える店舗の提案を短時間で行うことができる。その結果、本発明によれば、上述した従来技術のようにユーザにストレスを生じさせることがない。

また、前記ユーザの識別情報に関連付けた外食価値観は、予め分類された複数の外食価値観のなかから、前記ユーザから得られた質問に対する回答を分析することにより、該ユーザを分類して当てはめたものであることが望ましい。尚、ユーザからの回答は、例えば、コンシェルジュ業務を提供する前段階の処理として（会員登録手続等において）、ユーザにアンケートを回答してもらい、回答結果を分析してユーザの外食価値観を把握しおけばよい。

このように、本発明は、予めユーザの外食価値観を分析しているため、上述した従来技術のように、オペレータがユーザから問い合わせを受けた際に、ユーザの外食価値観を判断する必要がなく、前記提案までの時間を短縮することができる。また、オペレータは、ユーザとのやり取り（質疑応答）が減るため、業務負担が軽減される共に、１件当たりの相談対応時間が短縮されるため、業務効率が向上する。

また、ユーザのニーズを示す店舗の特徴データが分類されて階層的に関連付けられて配置されていると共に、最下層の特徴データに、店舗情報が関連付けられている特徴データベースを備え、前記情報選定部は、前記特徴データベースにアクセスして、前記特定したユーザのニーズと同じ内容の特徴データを抽出し、その抽出した特徴データに関連付けられている店舗情報を選択して出力することが望ましい。

上記の構成により、情報処理装置は、上記選定したユーザのニーズに対応する店舗情報を自動的に選択することができる。その結果、本発明によれば、オペレータ及びユーザの両者の手間をかけずに、ユーザからの問い合わせに応じた店舗情報を短時間で選定することができる。また、上記のように構成された特徴データベースを用いることにより、ユーザのニーズ（例えば、「京都らしい雰囲気の店に行きたい」などのニーズ）から店舗情報を抽出することができる。すなわち、店舗の位置、店舗が提供している料理、具体的なメニューからではなく、ユーザのニーズに基づいた店舗検索が可能となる。

また、前記ユーザデータベースには、前記ユーザの識別情報に関連付けられて該ユーザのメールアドレスが登録されており、前記情報選定部は、前記ユーザのメールアドレス宛に、前記選択した店舗情報を送信することが望ましい。上記の構成により、例えば、ユーザの携帯電話端末にメールで店舗情報を送ることができるため、ユーザが現地（お店を探しているエリア）を訪問しながら、コンシェルジュ業務を行っているオペレータに電話で問い合わせをし、所望する店舗情報を取得することができるようになる。

本発明によれば、ユーザからの問い合わせに応じて店舗情報を提供するコンシェルジュ業務を支援する情報処理装置において、ユーザの手間をかけることなく短時間でユーザの要望に応える情報を提供できる。

本発明の実施形態のコンシェルジュ支援装置の機能ブロック図である。 本発明の実施形態のユーザデータベースのデータ構造の一例を模擬的に示した図である。 本発明の実施形態のニーズ判定テーブルのデータ構造の一例を模擬的に示した図である。 本発明の実施形態の特徴データベースのデータ構造の一例を模擬的に示した図である。 本発明の実施形態の店舗データベースのデータ構造の一例を模擬的に示した図である。 本発明の実施形態のコンシェルジュ支援装置により行われる店舗検索処理の手順を示したフローチャートである。

以下、本発明の実施形態について図面を用いて説明する。先ず、本実施形態のコンシェルジュ支援装置の構成について図１に基づいて説明する。なお、図１は、本実施形態のコンシェルジュ支援装置の機能ブロック図である。

本実施形態のコンシェルジュ支援装置（情報処理装置）１は、ユーザからの問い合わせに応じて店舗情報を提案するコンシェルジュ業務を支援するための装置であり、コンシェルジュサービスを提供している事業者のオフィス（サービスセンタ）に設置されている。また、コンシェルジュ支援装置１は、専門のオペレータ（コンシェルジュ）により操作されるようになっている。

また、ユーザは、前記コンシェルジュサービスの提供を受けるに当たり、事前に前記事業者に対して、会員登録（ユーザに関する各種情報を登録）をするようになっている。そして、ユーザは、オペレータに電話をかけて、利用したい店舗の場所（エリア）や要望（どのようなお店を探しているなどの要望）を伝える。オペレータは、ユーザからの電話を受けると、コンシェルジュ支援装置１にユーザから電話で伝えられた店舗のエリアや要望を入力する。そして、コンシェルジュ支援装置１は、前記入力された「店舗のエリアや要望（ニーズ）」に対応する店舗の店舗情報を選定し、ユーザのメールアドレス宛に選定した店舗情報を送信するようになっている。尚、以下では、ユーザが携帯電話端末２でオペレータに電話をかけ、コンシェルジュ支援装置１が携帯電話端末２に選定した店舗情報が提示された電子メールを送信する場合を例に説明する。

具体的には、本実施形態のコンシェルジュ支援装置１は、制御部１１と、入力部１２と、表示部１３と、通信処理部１４と、情報選定部１５と、記憶部１６とを備えている。また、前記記憶部１６には、ユーザデータベース２０、ニーズ判定テーブル３０、特徴データベース４０及び店舗データベース５０が記憶されている。

ここで、制御部１１は、コンシェルジュ支援装置１全体の動作を制御する。また、入力部１２は、キーボード、操作ボタン、マウス等で構成されており、オペレータからの各種データの入力や要求を受け付ける。例えば、入力部１２は、ユーザからヒアリングして得られたユーザに関するユーザ情報と、そのユーザの探している店舗の希望条件（店舗の場所、後述する外食オケージョン）を受け付ける。また、表示部１３は、液晶ディスプレイ等で構成されており、各種データの入力を受け付けるための入力画面等の画像情報を表示する。また、通信処理部１４は、携帯電話網などの通信ネットワークを介して、ユーザの携帯電話端末２との間で各種情報の授受を行う。

また、情報選定部１５は、入力部１２を介して入力された前記ユーザ情報及び前記希望条件を受け付ける。また、情報選定部１５は、前記ユーザ情報及び前記希望条件を受け付けると、記憶部１６に記憶されている各データベース（ユーザデータベース２０、ニーズ判定テーブル３０、特徴データベース４０及び店舗データベース５０）にアクセスする。そして、情報選定部１５は、前記ユーザ情報及び前記希望条件と、前記各データベースとを用いて、前記希望条件に対応する店舗の店舗情報を選定し、ユーザの携帯電話端末２に選定した店舗情報を送信する。尚、情報選定部１５により行われる処理は後段で詳細に説明する。

また、コンシェルジュ支援装置１のハードウェア構成は特に限定されるものではないが、例えば、コンシェルジュ支援装置１は、ＣＰＵ、補助記憶装置、主記憶装置、ネットワークインターフェース及び入出力インターフェースを備えるコンピュータにより構成される。この場合、前記補助記憶装置には、制御部１１、通信処理部１４及び情報選定部１５の機能を実現するためのプログラムが格納されている。また、前記補助記憶装置の所定領域には、上述した記憶部１６が形成されている。そして、制御部１１、通信処理部１４及び情報選定部１５の機能は、前記ＣＰＵが前記補助記憶装置に格納された前記プログラムを前記主記憶装置にロードして実行することにより実現される。

次に、記憶部１６に記憶されている各データベース（ユーザデータベース２０、ニーズ判定テーブル３０、特徴データベース４０及び店舗データベース５０）のデータ構造について、図２〜図５に基づいて説明する。尚、図２は、本実施形態のユーザデータベースのデータ構造の一例を模擬的に示した図である。また、図３は、本実施形態のニーズ判定テーブルのデータ構造の一例を模擬的に示した図である。また、図４は、本実施形態の特徴データベースのデータ構造の一例を模擬的に示した図である。また、図５は、本実施形態の店舗データベースのデータ構造の一例を模擬的に示した図である。

先ず、ユーザデータベース２０のデータ構造を説明する。図２に示すように、ユーザデータベース２０は、ユーザを識別するユーザＩＤ（ユーザ識別情報）を登録するフィールド２０１と、ユーザ名を登録するフィールド２０２と、ユーザの外食価値観を登録するフィールド２０３と、ユーザの住所を登録するフィールド２０４と、ユーザのメールアドレスを登録するフィールド２０５と、ユーザの性別を登録するフィールド２０６と、ユーザの年齢を登録するフィールド２０７と、ユーザの履歴を登録するフィールド２０８とを備えて１つのレコードが形成されている。この構成により、ユーザデータベース２０には、各ユーザＩＤに、ユーザ名、外食価値観、住所、メールアドレス、性別、年齢及びユーザの履歴が関連付けられて登録される。

ここで、フィールド２０１に登録される「ユーザＩＤ」とは、コンシェルジュサービスを受けるためにユーザ情報を登録した（会員登録した）ユーザに与えられる一意の情報（英数字などの情報）をいう。また、「ユーザ名」は、フィールド２０１に登録されるユーザＩＤのユーザの氏名を示す情報をいう。また、「外食価値観」とは、フィールド２０１に登録されるユーザＩＤのユーザの外食に対する価値観を示す情報をいう。また、「住所」とは、フィールド２０１に登録されるユーザＩＤのユーザの自宅や勤務先の住所（又は最寄り駅）をいう。また、「メールアドレス」とは、ユーザの携帯電話端末２やパソコン等の情報処理端末のメールアドレスをいう。また、「ユーザの履歴」とは、フィールド２０１に登録されるユーザＩＤのユーザが過去に利用したコンシェルジュサービスの履歴情報のことをいう。

ここで、上記の外食価値観とは、会員登録の手続の際に行うアンケートによるライフスタイル分析の結果、そのユーザに当てはめられたものである。具体的には、ユーザに複数の質問に答えてもらい、その質問を分析することにより、予め分類された外食価値観（外食に対する価値観（考え方））のうちのいずれかに、そのユーザを分類して当てはめたものである。本実施形態では、外食価値観として、「伝統派（伝統尊重派）」、「社会派（社会達成派）」、「自己派（自己顕示派）」の３つの外食価値観を示し、ユーザをいずれかの外食価値観に当てはめた場合を例にするが、外食価値観の分類や数はあくまでも一例に過ぎない。

例えば、「伝統尊重派」とは、「日本の文化伝統を守り継承する層（日本の文化・社会的伝統を守る意識が強く、義理・分別を重んじる層）」と分析されたユーザが分類される価値観グループをいう。また、「社会達成派」とは、「キャリア・社会志向の強い良識層（社会的・文化的関心が強く、客観的ゴールを設定して努力する、趣味も豊富である層）」と分析されたユーザが分類される価値観グループをいう。また、「自己顕示派」とは「レジャー・ファッション高感度享楽層（流行に敏感で自己表現にこだわり、今をエンジョイする層）」と分析されたユーザが分類される価値観グループをいう。

次に、ニーズ判定テーブル３０のデータ構造を説明する。図３に示すように、ニーズ判定テーブル３０は、店舗が立地しているエリア、外食価値観及び外食オケージョンの組合せ毎に、ニーズ（ユーザの飲食店に対するニーズ）が関連付けられたデータベースである。具体的には、ニーズ判定テーブル３０は、店舗があるエリアを登録するフィールド３０１と、外食価値観を登録するフィールド３０２と、外食オケージョンを登録するフィールド３０３と、ユーザの飲食店に対するニーズを登録するフィールド３０４とを備えて１つのレコードが形成されている。

ここで、フィールド３０１に登録される「エリア」とは、店舗の所在するエリアを指すデータであり、図示する例では「京都」が登録されている。また、フィールド３０２に登録される「外食価値観」とは、ユーザデータベース２０のフィールド２０３に登録されている各ユーザに当てはめられている価値観グループであり、その内容は上述した通りである。また、フィールド３０３に登録される「外食オケージョン」とは、ユーザがオペレータに伝えた「飲食店を利用する際の状況や場面等」を示すデータ（飲食店の利用場面・利用状況を示すデータ）のことをいう。図示する例では、「土地勘のない京都で友人と食事」というオケージョンを示す情報が登録されている。尚、フィールド３０３に登録されるオケージョンとしては、例えば、「銀座で会社の同僚とお酒を飲む」や「デートにふさわしいお店で恋人と食事をする」等の情報が挙げられる。

また、フィールド３０４に登録される「ニーズ」とは、店舗があるエリア、外食価値観及び外食オケージョンの組合せ毎に定めた、ユーザの飲食店に対するニーズのことをいう。具体的には、上記の各外食価値観を持つユーザが、所定のエリアにおいて、所定の外食オケージョンの基でどのようなニーズを持つかを統計調査する（アンケート等で得られたデータを統計的手法による分析調査をする）。そして、「エリア、外食価値観及び外食オケージョン」の組合せに、前記の統計調査により得られたニーズを紐付けしたものがニーズ判定テーブル３０となっている。尚、フィールド３０４に登録される「ニーズ」は、後述する特徴データベース４０に登録されている特徴データが用いられる。すなわち、この「ニーズ」は、後述する特徴データベース４０に登録された特徴データから選択される。このように、上記の組合せ毎に定めたニーズに、店舗（飲食店）のウリやピーアール等の特徴データを用いるようにしたのは、ユーザのニーズから店舗を検索できるようにするためである。

尚、図３の例では、「エリアが京都」、「外食価値観が伝統尊重派（伝統派）」、「外食オケージョンが土地勘のない京都で友人と食事」である場合、「京都らしい雰囲気の店、京都の味が楽しめる店」がニーズとして関連付けられている。また、「エリアが京都」、「外食価値観が社会達成派（社会派）」、「外食オケージョンが土地勘のない京都で友人と食事」である場合、「京都の一流店、有名店、京都の歴史・著名人にゆかりの店」がニーズとして関連付けられている。また、「エリアが京都」、「外食価値観が自己顕示派（自己派）」、「外食オケージョンが土地勘のない京都で友人と食事」である場合、「京都の話題店、先端店、京都の趣味の仲間が集まる店」がニーズとして関連付けられている。

次に、特徴データベース４０のデータ構造を説明する。特徴データベース４０は、図４に示すように、ユーザのニーズを示す飲食店の特徴データが分類されて階層的に関連付けられて配置されていると共に、最下層の特徴データに、店舗情報（店舗名）が関連付けられている。

ここで、特徴データとは、飲食店の広告やＷｅｂサイトに掲載されている情報（飲食店のウリやピーアール等の特徴）等から「店舗の選択、利用に直接対応していると考えられるニーズ」を網羅的に分析して抽出したキーワードや文等のデータや、その抽出したデータを上位概念化して示したデータのことをいう。この特徴データは、飲食店の特徴を示したものであるが、同時に、ユーザが求めているニーズも示している。例えば、図4に示す特徴データ４１０ａは、「食事と一緒にエンターテインメントを楽しみたい」という飲食店の特徴であると共に、ユーザのニーズも表している。

より具体的には、特徴データベース４０は、第１階層（最上位概念）の特徴データを登録するフィールド４０１と、フィールド４０１に登録された特徴データに関連付けられた第２階層の特徴データ（第１階層の特徴データの内容を具体化したもの）を登録するフィールド４０２と、フィールド４０２に登録された特徴データに関連付けられた第３階層の特徴データ（第２階層の特徴データの内容を具体化したもの）を登録するフィールド４０３と、フィール４０３に登録された特徴データに関連付けられた第４階層の特徴データ（第３階層の特徴データの内容を具体化したもの）を登録するフィールド４０４と、フィールド４０４に登録された特徴データに関連付けられた飲食店情報（店舗名）を登録するフィールド４０５とを備えている。

図４では、「第１階層」を登録するフィールド４０１に、例えば、「食事と一緒にエンターテインメントを楽しみたい」という特徴データ４１０ａが登録されている。また、この特徴データ４１０ａの一つ下の階層を登録するフィールド４０２に、前記特徴データ４１０ａの内容を具体的に示した特徴データ（食事をしながらライブ演奏やショーを楽しみたい）４２０ａが関連付けられて登録されている。また、この特徴データ４２０ａの一つ下の階層を登録するフィールド４０３に、前記特徴データ４２０ａの内容を具体的に示した特徴データ（音楽のライブが楽しめる店）４３０ａが関連付けられて登録されている。また、この特徴データ４３０ａの一つ下の階層を登録するフィールド４０４に、前記特徴データ４３０ａの内容を具体的に示した特徴データ（日本の民謡が楽しめる店）４４０ａが関連付けられて登録されている。

そして、上位階層の特徴データは、飲食店のジャンル（和食、中華、居酒屋等のジャンル）や提供するサービス、店舗の立地に直接関係しない概念的な飲食店に対するニーズを示したものとなっている。また、上位階層の特徴データから下位階層の特徴データに向かうにしたがい、飲食店の具体的なニーズ（体験できるサービスの具体的な内容等）を表現したデータになっている。尚、本実施形態の説明では、「第１階層」が最上位の階層を示し、「第２階層」が「第１階層の１つ下の階層」を示し、「第３階層」が「第２階層の１つ下の階層」を示し、「第４階層」が「第３階層の１つ下の階層」を示すものとする。また、図示する特徴データベース４０の階層数は、あくまでも一例である。

このように、店舗の特徴データを上位概念から下位概念に向けて階層的に関連付けて配置すると共に、最下層の特徴データに飲食店の店舗を紐付けすることにより、飲食店のジャンル（和食、中華、居酒屋等のジャンル）や提供するメニュー、店舗の立地に直接関係しない概念的な飲食店に対するニーズから、ユーザが求めている飲食店を検索することができるようになる。すなわち、特徴データベース４０を用いることにより、ユーザの潜在ニーズ（曖昧なニーズ）に応える飲食店を抽出することができる。

次に、店舗データベース５０のデータ構造を説明する。図５に示すように、店舗データベース５０は、店舗名（及び店舗ＩＤ）を登録するフィールド５０１と、店舗の住所を登録するフィールド５０２と、店舗の最寄駅を登録するフィールド５０３と、店舗の電話番号を登録するフィールド５０４と、店舗のＵＲLを登録するフィールド５０５と、提供する料理の種類を登録するフィールド５０６と、店舗のメニューを登録するフィールド５０７と、店舗のＰＲ・店舗の特徴（店舗のウリ）を示す情報（特徴データ）を登録するフィールド５０８とを備えて１つのレコードが構成されている。尚、特徴データとは、特徴データベース４０に登録されているものと同じである。

次に、本実施形態のコンシェルジュ支援装置１により行われる店舗を選定する処理について、図６に基づいて説明する。ここで、図６は、本発明の実施形態のコンシェルジュ支援装置により行われる店舗検索処理の手順を示したフローチャートである。尚、以下に示す処理フローのなかのユーザは、コンシェルジュサービスを提供する事業者に会員登録を行っており、当該ユーザのユーザ情報はユーザデータベース２０に登録されているものとする。

先ず、ユーザは、携帯電話端末２から前記事業者のオペレータ（コンシェルジュ）に電話をかけて、オペレータに「ユーザ名」及び「ユーザＩＤ（会員番号）」を伝える。オペレータは、入力部１２を操作して、コンシェルジュ支援装置１に、ユーザから聞いた「ユーザ名」及び「ユーザＩＤ」を入力する。具体的には、コンシェルジュ支援装置１の情報選定部１５は、入力部１２を介して、「ユーザ名」及び「ユーザＩＤ」の入力を受け付ける（Ｓ１）。

次に、情報選定部１５は、Ｓ１で受け付けた「ユーザ名」及び「ユーザＩＤ」と、ユーザデータベース２０とを用いて、ユーザの外食価値観を特定する（Ｓ２）。具体的には、情報選定部１５は、ユーザデータベース２０のなかから、Ｓ１で受け付けた「ユーザ名」及び「ユーザＩＤ」が登録されたレコードを抽出する。また、情報選定部１５は、その抽出されたレコードのフィールド２０３に登録された外食価値観を、Ｓ１で入力されたユーザ情報（ユーザ名、ユーザＩＤ）のユーザの外食価値観として特定する。また、情報選定部１５は、ユーザの外食価値観が特定されると、表示部１３に、ユーザ認証が成功された旨のデータと、抽出されたレコードに登録されたユーザ情報とを表示する。

尚、情報選定部１５は、ユーザデータベース２０のなかに、Ｓ１で受け付けた「ユーザ名」及び「ユーザＩＤ」が登録されたレコードが無ければ、表示部１３に認証エラーを示すデータを表示し、オペレータに「ユーザ名」及び「ユーザＩＤ」の再入力を促してＳ１の処理に戻る（図示せず）。或いは、情報選定部１５は、前記登録されたレコードが無ければ、表示部１３に認証エラーを示すデータを表示して処理を終了する。

次に、オペレータは、電話の相手先であるユーザに、ユーザが探している飲食店のエリア（住所、地名、郵便番号等のエリアを指す情報）を聞き、入力部１２を操作して、コンシェルジュ支援装置１に、ユーザから聞いた「エリア」を入力する。具体的には、コンシェルジュ支援装置１の情報選定部１５は、入力部１２を介して、オペレータからの「エリア」の入力を受け付ける（Ｓ３）。

尚、Ｓ３において、情報選定部１５は、予め分類した複数のエリアを表示部１３に表示し、オペレータに、分類したエリアから一のエリアを選択させるように構成されていてもよい。この場合、オペレータは、前記表示されたエリアのなかから、ユーザから聞いた「エリア」と同じエリア（或いは一番近いエリア）を選択する。この場合、記憶部１６には、予め分類した複数のエリアを示すデータが格納されているものとする。

次に、オペレータは、電話の相手先であるユーザに、ユーザが希望している外食オケージョン（「土地勘のない京都で友人と食事」をしたい等の内容）を聞き、入力部１２を操作して、コンシェルジュ支援装置１に、ユーザから聞いた「外食オケージョン」を入力する。具体的には、コンシェルジュ支援装置１の情報選定部１５は、入力部１２を介して、オペレータからの「外食オケージョン」の入力を受け付けて（Ｓ４）、Ｓ５に進む。

尚、Ｓ４において、情報選定部１５は、予め類型化した複数の外食オケージョンを表示部１３に表示し、オペレータに、複数の外食オケージョンから一の外食オケージョンを選択させるように構成されていてもよい。この場合、オペレータは、前記表示された外食オケージョンのなかから、ユーザから聞いた「外食オケージョン」同じもの（或いは一番近いもの）を選択する。この場合、記憶部１６には、予め類型化した複数の外食オケージョンを示すデータが格納されているものとする。

Ｓ５では、情報選定部１５は、電話の相手先であるユーザのニーズの特定を行う。具体的には、情報選定部１５は、Ｓ２で特定した外食価値観と、Ｓ３で受け付けた飲食店の「エリア」と、Ｓ４で受け付けた「外食オケージョン」と、ニーズ判定テーブル３０とにより、ユーザのニーズの特定を行う。すなわち、情報選定部１５は、ニーズ判定テーブル３０のなかから、上記の「エリア」、「外食価値観」及び「外食オケージョン」が登録されたレコードを抽出する。また、情報選定部１５は、その抽出されたレコードのフィールド３０４に登録されたニーズを、Ｓ１で入力されたユーザ情報（ユーザ名、ユーザＩＤ）のユーザのニーズとして特定する。また、情報選定部１５は、表示部１３に前記特定したユーザのニーズを表示（出力）する。

例えば、Ｓ２で特定した外食価値観が「伝統派」であり、Ｓ３で受け付けた飲食店の「エリア」が「京都」であり、Ｓ４で受け付けた外食オケージョンが「土地勘のない京都で友人と食事」であれば、情報選定部１５は、図３のニーズ判定テーブル３０から、ユーザのニーズが「京都らしい雰囲気のお店、京都の味が楽しめるお店」であると特定する。

次に、情報選定部１５は、Ｓ５で特定したユーザのニーズ（例えば、「京都らしい雰囲気のお店、京都の味が楽しめるお店」）と、特徴データベース４０とを用いて、Ｓ５で特定したユーザのニーズに関連付けられている店舗を選定する（Ｓ６）。具体的には、情報選定部１５は、特徴データベース４０を検索し、特徴データベース４０のなかから、Ｓ５で特定したユーザのニーズと同じ又は類似する特徴データを抽出し、その抽出した特徴データに関連付けられている店舗情報を選択する。例えば、Ｓ５で特定したニーズが「京都らしい雰囲気のお店、京都の味が楽しめるお店」であれば、図４に例示する特徴データ４０にから、「京料理○×」、「京料理○△」、「京懐石○○」が選択される。尚、上記の特徴データが類似するか否かを判定は周知技術により実現されるものであるため、ここでの説明は省略する。

そして、情報選定部１５は、前記店舗が抽出されると、表示部１３に、「Ｓ５で特定したユーザのニーズ」及び「Ｓ６で選定した店舗情報」が提示された画像情報を表示する。オペレータは、この表示された画像情報を見て、ユーザに電話で「お店のデータを折り返しメールで送信する旨を伝える（例えば、ユーザに、「京都らしい雰囲気のお店をお勧めします。メールでお店の情報をお送りしますのでお待ちください。」等のメッセージを伝える）。

次に、情報選定部１５は、店舗データベース５０からＳ６で選定したお店の情報を抽出すると共に、ユーザデータベース２０からユーザのメールアドレスを抽出して、前記選定した店舗を紹介するメール（宛先が、ユーザの携帯電話端末２のメールアドレスに設定したメール）を作成する。また、情報選定部１５は、通信処理部１４を介して、ユーザの携帯電話端末２に前記メールを送信し、処理を終了する（Ｓ７）。ここで、店舗を紹介するメールには、店舗データベース５０の各フィールド５０１〜５０８に登録されたデータが記載されている。すなわち、前記メールには、店舗名、住所、最寄駅、電話番号、店舗のＵＲL、料理種別、メニューに加えて、その店舗のＰＲ・特徴（店舗のウリ）となる情報も記載されている。これにより、ユーザは、メールを見て、店舗のＰＲ・特徴（店舗のウリ）を参考にして店舗選びをすることができる。尚、情報選定部１５は、Ｓ７の処理を終了する前に、ユーザデータベース２０のフィールド２０８に、今回行われた処理の履歴情報（処理日時、Ｓ３、Ｓ４で入力した「エリア」、「オケージョン」、Ｓ５で特定した「ニーズ」、Ｓ６で選定した「店舗情報」）を登録する。

このように、本実施形態のコンシェルジュ支援装置１は、各ユーザの外食価値観を特定（把握）し、各ユーザの外食価値観を登録したユーザデータベース２０を備えている。そのため、本実施形態のコンシェルジュ支援装置１を利用することにより、オペレータがユーザから問い合わせを受けた際に、ユーザの外食価値観を判断する必要がなく、ユーザにお店を提案するまでの時間を短縮させることができる。

また、コンシェルジュ支援装置１は、店舗のエリア、外食価値観及び外食オケージョンの組合せ毎に、飲食店に対するニーズを紐付けしたニーズ判定テーブル３０を備えている。この構成により、コンシェルジュ支援装置１は、ユーザ名、店舗があるエリア及び外食オケージョンの入力を受け付けることにより、ユーザデータベース２０及びニーズ判定テーブル３０を用いて、「エリア」及び「外食オケージョン」からユーザのニーズを選定することができる。すなわち、本実施形態によれば、面倒な質疑応答をすることなく、ユーザの飲食店に対するニーズが選定されるため、ユーザの要求に応える店舗の提案を短時間で行うことができる。その結果、本発明によれば、上述した従来技術のようにユーザにストレスを生じさせることがない。また、本実施形態によれば、オペレータは、ユーザとのやり取り（質疑応答）が減るため、業務負担が軽減される共に、１件当たりの相談対応時間が短縮されるため、業務効率が向上する。

また、本実施形態のコンシェルジュ支援装置１は、ユーザのニーズを示す飲食店の特徴データを分類して階層的に関連付けて配置すると共に、最下層の特徴データに、店舗情報（店舗名）を関連付けた特徴データベース４０を備えている。この構成により、コンシェルジュ支援装置１は、前記のようにユーザのニーズを選定すると、特徴データベース４０を用いて、当該選定したユーザのニーズに対応する店舗情報を自動的に抽出することができる。

すなわち、本実施形態のコンシェルジュ支援装置１は、上記の構成により、ユーザ名、店舗があるエリア及び外食オケージョンを入力することにより、ユーザの要望（エリア、外食オケージョン）に応える店舗情報を選定できるため、上述した従来技術のコンシェルジュサービスと比べて、短時間でユーザの要望に応えることができる。

また、本実施形態によれば、オペレータは、コンシェルジュ支援装置１に、ユーザ認証が終わると、前記エリアおよび前記外食オケージョンを入力すれば、その後は、装置側が自動的にユーザの要望（エリア、外食オケージョン）に応える店舗情報を選定してくれるため、オペレータの業務負担が大幅に軽減される。また、コンシェルジュ支援装置１が、ユーザのニーズに応える店舗情報を選定するようになっているため、オペレータ毎の経験・スキルに左右されないコンシェルジュサービスを提供することができる。

尚、本発明は、上述した実施形態に限定されるものではなく、その要旨の範囲内において種々の変更が可能である。例えば、上述した実施形態では、コンシェルジュ支援装置１が自動的に、ユーザのニーズに応える店舗情報を選定していたが、特にこれに限定されるものではない。コンシェルジュ支援装置１は、上述したＳ５の処理によりニーズを特定した後は、表示部１３に、その特定したニーズ及びユーザの履歴を出力して処理を終了してもよい。この場合、オペレータは、表示されたニーズや、ユーザの履歴情報等を見た上で、オペレータが、自身の経験や知識を利用して、ユーザにお勧めする店舗を選定する。この構成においても、オペレータは、ユーザに様々な質問をしてユーザの外食価値観やニーズを把握する必要がないため、短時間でユーザの所望する店舗情報を提供することができる。

また、例えば、上述した実施形態では、コンシェルジュ支援装置１を操作するオペレータが、ユーザの要望（エリア、外食オケージョン）を入力することにより、ユーザのニーズに応える飲食店情報を選定していたが特にこれに限定されるものではない。例えば、コンシェルジュ支援装置１は、通信ネットワークを介してユーザ端末（パソコン、スマートフォン等）に接続され、当該ユーザ端末との間でデータの授受が行えるように構成されていてもよい。この場合、コンシェルジュ支援装置１は、通信ネットワークを介して、前記ユーザ端末から「ユーザＩＤ、ユーザ名、エリア、外食オケージョン」の入力を受け付ける。また、コンシェルジュ支援装置１は、その受け付けた「ユーザＩＤ、ユーザ名、エリア、外食オケージョン」からユーザのニーズに応える飲食店情報を選定する。また、コンシェルジュ支援装置１は、通信ネットワークを介して、前記ユーザ端末に、前記選定した飲食店情報を送信する。この構成においても、上述した実施形態と同様の効果を奏することができる。

また、上述した実施形態のユーザデータベース２０のフィールド２０８に登録された履歴を利用して、会員向けのＥＤＭサービスに利用するようにしてもよい。これにより、ユーザに対して、関心が高いと想定される飲食店情報を提供することができ、会員となったユーザに有益な情報が配信される。

また、上述した実施形態では、店舗情報として飲食店の情報を示していたが、あくまでもこれは一例に過ぎない。店舗情報が飲食店以外の店舗や、ホテルや旅館等の宿泊施設に関する情報であったり、音楽コンサートやスポーツ興行等のイベント情報であってもよい。

１…コンシェルジュ支援装置、２…携帯電話端末、１１…制御部、１２…入力部、１３…表示部、１４…通信処理部、１５…情報選定部、１６…記憶部、２０…ユーザデータベース、３０…ニーズ判定テーブル、４０…特徴データベース、５０…店舗データベース

Claims (5)

1. ユーザからの問い合わせに応じて店舗情報を提案するコンシェルジュ業務を支援する情報処理装置であって、
   ユーザの識別情報毎に該ユーザの外食に対する考え方を示した外食価値観を関連付けたユーザデータベースと、
   店舗があるエリアと前記外食価値観と店舗の利用場面・利用状況を示す外食オケージョンとの組合せ毎にユーザの店舗に対するニーズを示したデータを関連付けたニーズ判定テーブルと、
   前記ユーザの識別情報、ユーザが探している店舗のエリア及びユーザが希望している前記外食オケージョンの入力を受け付ける入力部と、
   前記入力を受け付けたユーザの識別情報及び前記ユーザデータベースを用いて前記ユーザの外食価値観を特定すると共に、前記特定した外食価値観、前記入力を受け付けたエリア、前記入力を受け付けた外食オケージョン及び前記ニーズ判定テーブルからユーザの飲食店に対するニーズを選定して出力する情報選定部とを備えている
   ことを特徴とする情報処理装置。
2. 前記ユーザの識別情報に関連付けた外食価値観は、予め分類された複数の外食価値観のなかから、前記ユーザから得られた質問に対する回答を分析することにより、該ユーザを分類して当てはめたものである
   ことを特徴とする請求項１に記載の情報処理装置。
3. ユーザのニーズを示す店舗の特徴データが分類されて階層的に関連付けられて配置されていると共に、最下層の特徴データに、店舗情報が関連付けられている特徴データベースを備え、
   前記情報選定部は、前記特徴データベースにアクセスして、前記特定したユーザのニーズと同じ内容の特徴データを抽出し、その抽出した特徴データに関連付けられている店舗情報を選択して出力する
   ことを特徴とする請求項１又は請求項２に記載の情報処理装置。
4. 前記特徴データとは、店舗の広告やＷｅｂサイトに掲載されている情報から店舗の選択、利用に直接対応していると推定されるキーワード、文を示すデータ、及びそのデータを上位概念化して示したデータである
   ことを特徴とする請求項３に記載の情報処理装置。
5. 前記ユーザデータベースには、前記ユーザの識別情報に関連付けられて該ユーザのメールアドレスが登録されており、
   前記情報選定部は、前記ユーザのメールアドレス宛に、前記選択した店舗情報を送信する
   ことを特徴とする請求項４に記載の情報処理装置。

Images