JP2015005058A - レコメンド装置、レコメンド方法及びレコメンドプログラム - Google Patents

Abstract

【課題】予約施設にユーザ全体の意見を反映すること。【解決手段】レコメンド装置１０は、複数人のユーザが投稿したメッセージが掲載されたルームからメッセージのログを収集する収集部１５ａと、収集部１５ａによって収集されたログに含まれるメッセージからキーワードを抽出する抽出部１５ｂと、抽出部１５ｂによって抽出されたキーワードのうち新たに投稿されたメッセージから抽出されたキーワードほど大きい重みを付与して施設を検索する検索部１５ｃと、検索部１５ｃによって検索された施設のレコメンドをルームに表示させる表示部１５ｄとを有する。【選択図】図２

Description

本発明は、レコメンド装置、レコメンド方法及びレコメンドプログラムに関する。

飲食店や宿泊等の施設を予約するための予約サイトが知られている。例えば、飲食店を予約する場合には、ユーザは、飲食店を探したい地域、利用を希望する日時や飲食店のジャンルなどの検索条件を指定することによって検索条件に該当する飲食店を検索することができる。

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

しかしながら、上記の従来技術では、予約を行う一部のユーザの趣味嗜好によって検索条件が決められるので、予約施設にユーザ全体の意見を反映することができない。

本願は、上記に鑑みてなされたものであって、予約施設にユーザ全体の意見を反映できるレコメンド装置、レコメンド方法及びレコメンドプログラムを提供することを目的とする。

一態様のレコメンド装置は、複数人のユーザが投稿したメッセージが掲載されたルームからメッセージのログを収集する収集部と、前記収集部によって収集されたログに含まれるメッセージからキーワードを抽出する抽出部と、前記抽出部によって抽出されたキーワードのうち新たに投稿されたメッセージから抽出されたキーワードほど大きい重みを付与して施設を検索する検索部と、前記検索部によって検索された施設のレコメンドを前記ルームに表示させる表示部とを有する。

実施形態の一態様によれば、予約施設にユーザ全体の意見を反映できるという効果を奏する。

図１は、実施形態に係るネットワークシステムの構成例を示す図である。 図２は、実施形態に係るレコメンド装置の構成例を示す図である。 図３は、メッセージのログの一例を示す図である。 図４は、メッセージのログの一例を示す図である。 図５は、実施形態に係るレコメンド処理の手順を示すフローチャートである。 図６は、レコメンドの表示方法の一例を示す図である。 図７は、レコメンドの表示方法の一例を示す図である。 図８は、レコメンドの表示方法の一例を示す図である。 図９は、リマインド画面の一例を示す図である。 図１０は、レコメンド装置の機能を実現するコンピュータの一例を示すハードウェア構成図である。

以下に、本願に係るレコメンド装置、レコメンド方法及びレコメンドプログラムを実施するための形態（以下、「実施形態」と呼ぶ）について図面を参照しつつ詳細に説明する。なお、この実施形態により本願に係るレコメンド装置、レコメンド方法及びレコメンドプログラムが限定されるものではない。また、以下の各実施形態において同一の部位には同一の符号を付し、重複する説明は省略される。

［１．システム構成］
まず、図１を用いて、実施形態に係るネットワークシステムの構成について説明する。図１は、実施形態に係るネットワークシステムの構成例を示す図である。図１に示すように、ネットワークシステム１には、レコメンド装置１０と、ＳＮＳ（Social Networking Service）サーバ２０と、予約サーバ３０と、端末装置５０Ａ〜５０Ｎとが収容される。なお、以下では、端末装置５０Ａ、５０Ｂ、・・・、５０Ｎを区別なく総称する場合に、「端末装置５０」と記載する。

これらレコメンド装置１０、ＳＮＳサーバ２０、予約サーバ３０及び端末装置５０は、図示しないネットワークＮを介して相互に通信可能に接続される。かかるネットワークＮには、有線または無線を問わず、インターネット（Internet）、ＬＡＮ（Local Area Network）やＶＰＮ（Virtual Private Network）などの任意の種類の通信網を採用できる。

このうち、ＳＮＳサーバ２０は、ソーシャルネットワーキングサービスを提供するサービス提供者によって運営されるサーバ装置である。一態様としては、ＳＮＳサーバ２０は、ソーシャルネットワーキングサービスの提供を受けるクライアント側のコミュニケーションアプリケーションがインストールされた端末装置５０に対し、各種のサービスを提供する。以下では、コミュニケーションアプリケーションのことを「コミュニケーションアプリ」と略記する場合がある。例えば、ＳＮＳサーバ２０は、チャット形式のメッセージ交換サービスを始め、自分のプロフィールやアバターなどを公開するマイページ機能、ＳＮＳ上で交流のある友人や知人を登録するアドレス帳の機能、マイページを訪問したユーザの履歴を参照できる訪問履歴の参照機能、ブログのように簡単にエントリを更新できる日記帳の機能などを提供できる。

予約サーバ３０は、施設の予約サービスを提供するサービス提供者によって運営されるサーバ装置である。一態様としては、予約サーバ３０は、施設に設置されたコンピュータから施設の空席状況を日別および時間帯別に収集し、施設ごとに日別および時間帯別の空席状況を管理する。かかる空席状況の管理の下、予約サーバ３０は、予約サーバが開設する予約サイトに対する検索条件を受け付ける。例えば、予約サーバ３０は、検索条件の一例としては、施設を探したい地域、利用を希望する日時や施設のジャンルなどを受け付ける。そして、予約サーバ３０は、検索条件に該当する施設を検索結果として出力する検索サービス、ひいては、検索結果の中から指定の施設を予約する予約サービスなどを提供する。

端末装置５０は、ユーザによって使用される情報処理端末である。かかる端末装置５０は、携帯端末全般をその範疇に含む。例えば、端末装置５０には、スマートフォン、携帯電話機やＰＨＳ（Personal Handyphone System）などの移動体通信網に接続する能力を有する移動体通信端末を採用できる。また、端末装置５０には、移動体通信網に接続する能力を持たないＰＤＡ（Personal Digital Assistants）などのタブレット端末を採用することもできる。

レコメンド装置１０は、下記のレコメンドサービスを提供するコンピュータである。かかるレコメンド装置１０の一態様としては、パッケージソフトウェアやオンラインソフトウェアとしてレコメンドサービスを提供するレコメンドプログラムを所望のコンピュータにインストールさせることによって実装できる。例えば、レコメンド装置１０は、レコメンドサービスを提供するＷｅｂサーバとして実装することとしてもよいし、アウトソーシングによってレコメンドサービスを提供するクラウドとして実装することとしてもかまわない。

このような構成の下、実施形態に係るレコメンド装置１０は、予約施設にユーザ全体の意見を反映するレコメンドサービスを実現する。かかるレコメンドサービスを実現するために、検索条件の指定にチャット形式でメッセージ交換が実行されるトークルームを利用する点に工夫がある。ここで言う「トークルーム」とは、コミュニケーションアプリにおいて、複数のユーザがメッセージを会話形式で投稿し、それぞれのユーザが当該メッセージの履歴を確認することができるコミュニケーション機能とすることができる。ここでの「メッセージ」とは、テキスト形式のコメント文の他に、ユーザが取得／撮影した画像や動画データを含んでも良い。

この点を図１の例を用いて説明する。図１に示すように、レコメンド装置１０は、複数人のユーザが投稿するメッセージが掲載されたトークルームからメッセージのログを収集する（１）。その上で、レコメンド装置１０は、（１）で収集されたログに含まれるメッセージから場所、カテゴリ、時間及び人数に関するキーワードを抽出する（２）。

例えば、トークルームから収集されたログが図１に示すログＬ１であるとしたとき、レコメンド装置１０は、図１に示すメッセージに付した下線部の単語をキーワードとして抽出する。具体的には、メッセージＴ１から「３：３」が人数に関するキーワードとして抽出されるとともに、メッセージＴ３から「六本木」が場所（地名）に関するキーワードとして抽出される。また、メッセージＴ４から「中華」がカテゴリに関するキーワードとして抽出されるとともに、メッセージＴ５から「イタリアン」がカテゴリに関するキーワードとして抽出される。さらに、メッセージＴ７から「７時」が時間に関するキーワードとして抽出される。なお、本例では、残りのメッセージＴ２、Ｔ６及びＴ８からはキーワードが抽出されない。

その後、レコメンド装置１０は、施設の検索を予約サーバ３０に依頼するにあたって先に抽出した場所、カテゴリ、時間および人数に関するキーワードのうち検索条件として重複するキーワードが複数存在する場合に、各キーワードに重み付けを実行する。図１の例では、施設のカテゴリに関するキーワード「中華」及び「イタリアン」が検索条件の項目として重複する。この場合、「中華」が抽出されたメッセージがＴ４であり、「イタリアン」が抽出されたメッセージがＴ５であり、メッセージＴ５の方が新しい。このため、「イタリアン」には、「中華」よりも大きい重みが付与される。その結果、施設のカテゴリを絞り込むためのキーワードには、「イタリアン」が用いられることになる。

このように、レコメンド装置１０は、キーワードに重み付けを行った後に、場所、カテゴリ、時間および人数を検索条件とし、施設の検索を予約サーバ３０へ依頼する（３）。図１の例では、六本木界隈で１９時からの時間帯に６名の空席があるイタリアンの飲食店「イタリアンレストランＡ」が検索されることなる。その後、レコメンド装置１０は、予約サーバ３０から検索結果として応答された施設のレコメンドをトークルームに参加するユーザが持つ端末装置５０に出力する（４）。かかる出力を受けて、端末装置５０は、レコメンド装置１０によって出力された施設のレコメンドをトークルームにバナー広告として表示させる（５）。例えば、図１の例で言えば、端末装置５０の表示領域Ｐ１の底部に施設「イタリアンレストランＡ」のレコメンドＲ１を表示させる。なお、本例では、ログＬ１のうちメッセージＴ１〜Ｔ２が表示領域Ｐ１に収まらないので、メッセージＴ１〜Ｔ２は表示されない。

ここで、端末装置５０に表示されたレコメンドＲ１に対する操作、例えばタップ操作がなされた場合には、レコメンド装置１０は、当該レコメンドＲ１に対応する施設の予約確認画面をタップ操作がなされた端末装置５０へ出力する（６）。かかる出力を受けて、端末装置５０は、レコメンド装置１０によって出力された予約確認画面Ｙを表示させる（７）。このとき、端末装置５０に表示された予約確認画面Ｙ上にあるＯＫボタンＢ１がタップ操作されたとする。この場合には、レコメンド装置１０は、レコメンドに留まらず、先に検索条件として特定された時間や人数、さらには、ＳＮＳのアカウントに登録された情報、例えばユーザＩＤ（identifier）や連絡先などを施設への申請事項とし、当該施設「イタリアンレストランＡ」の予約を施設によって運営されるコンピュータ等へ依頼する。なお、端末装置５０に表示された予約確認画面Ｙ上にあるキャンセルボタンＢ２がタップ操作された場合には、端末装置５０は、トークルームの表示に戻す。

このように、本実施形態に係るレコメンド装置１０は、検索条件の指定にチャット形式でメッセージ交換が実行されるトークルームを利用する。このため、予約サイトを用いた予約のように、予約を行うユーザの独断によって検索条件が決定されず、施設を利用するユーザ全体による話し合いの中から検索条件とするキーワードが抽出される。したがって、本実施形態に係るレコメンド装置１０によれば、予約施設にユーザ全体の意見を反映できる。加えて、新たに投稿されたメッセージから抽出されたキーワードほど大きい重みを付与して施設が検索される。このため、ユーザ間で最新に話し合われたメッセージから抽出されたキーワードが施設の検索に使用されやすくなる。よって、ユーザ間で話しの筋に変更があった場合でも会話の流れに沿って施設を検索することができる。

［２．レコメンド装置の構成］
続いて、図２を用いて、実施形態に係るレコメンド装置１０の構成について説明する。図２は、実施形態に係るレコメンド装置１０の構成例を示す図である。図２に示すように、レコメンド装置１０は、通信Ｉ／Ｆ（Interface）部１１と、記憶部１３と、制御部１５とを有する。なお、レコメンド装置１０は、図２に示した機能部以外にも既知のコンピュータが有する各種の機能部、例えば各種の入力デバイスや音声出力デバイスなどの機能部を有することとしてもかまわない。

（通信Ｉ／Ｆ部１１について）
通信Ｉ／Ｆ部１１は、他の装置、例えばＳＮＳサーバ２０、予約サーバ３０や端末装置５０との間で通信制御を行うインタフェースである。かかる通信Ｉ／Ｆ部１１の一態様としては、ＬＡＮカードなどのネットワークインタフェースカードを採用できる。

例えば、通信Ｉ／Ｆ部１１は、ＳＮＳサーバ２０からトークルームへ投稿されたメッセージのログを受信したり、また、施設のレコメンドや予約確認画面などをＳＮＳサーバ２０へ送信したりする。また、通信Ｉ／Ｆ部１１は、検索条件を含む施設の検索依頼を予約サーバ３０へ送信したり、予約サーバ３０から検索結果を受信したりする。

（記憶部１３について）
記憶部１３は、制御部１５で実行されるＯＳ（Operating System）や上記のレコメンドサービスを提供するレコメンドプログラムなどの各種プログラムを記憶する記憶デバイスである。記憶部１３の一態様としては、フラッシュメモリなどの半導体メモリ素子、ハードディスク、光ディスクなどの記憶装置が挙げられる。なお、記憶部１３は、上記の種類の記憶装置に限定されるものではなく、ＲＡＭ（Random Access Memory)、ＲＯＭ（Read Only Memory)であってもよい。

記憶部１３は、制御部１５で実行されるプログラムに用いられるデータの一例として、ログデータ１３ａを記憶する。なお、上記のログデータ１３ａ以外にも、他の電子データ、例えばテキストに含まれる文字列から形態素を解析する場合に用いる辞書データなども併せて記憶することもできる。

（ログデータ１３ａについて）
ログデータ１３ａは、トークルームに含まれるメッセージのログに関するデータである。かかるログデータ１３ａの一態様としては、時系列に整列されたメッセージごとに当該メッセージを投稿したユーザのＳＮＳのユーザＩＤが対応付けられたデータを採用できる。一例としては、ログデータ１３ａは、後述の収集部１５ａによってＳＮＳサーバ２０から収集された場合に、記憶部１３に登録される。他の一例としては、ログデータ１３ａは、施設の検索を行うキーワードを抽出するために、後述の抽出部１５ｂによって参照される。

（制御部１５について）
制御部１５は、各種の処理手順を規定したプログラムや制御データを格納するための内部メモリを有し、これらによって種々の処理を実行する。制御部１５は、図２に示すように、収集部１５ａと、抽出部１５ｂと、検索部１５ｃと、表示部１５ｄと、予約部１５ｅとを有する。

制御部１５は、ＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）などに特典付与プログラムを実行させることによって実現できる。また、上記の各機能部は、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）などのハードワイヤードロジックによっても実現できる。

（収集部１５ａについて）
収集部１５ａは、トークルームからメッセーのログを収集する処理部である。一態様としては、収集部１５ａは、下記に例示するタイミングでＳＮＳサーバ２０からトークルームに投稿されたメッセージのログを収集する。例えば、収集部１５ａは、トークルームに新規のメッセージが投稿される度に、当該トークルームからメッセージのログを収集する。また、収集部１５ａは、一定周期、例えば３０秒間や１分間などが経過する度に、あるいはＯＳ等によって内部管理された現時刻が定期時刻になった場合に、ＳＮＳサーバ２０からトークルームへ投稿されたログを収集する。ログの収集後、収集部１５ａは、ＳＮＳサーバ２０から収集されたメッセージのログをログデータ１３ａとして記憶部１３へ登録する。なお、ここでは、ＳＮＳサーバ２０から収集されたログを記憶部１３へ一旦登録する場合を例示したが、後段の抽出部１５ｂへそのまま入力することとしてもかまわない。

（抽出部１５ｂについて）
抽出部１５ｂは、ログデータ１３ａに含まれるメッセージからキーワードを抽出する処理部である。一態様としては、抽出部１５ｂは、ログデータ１３ａに含まれる各メッセージから場所、カテゴリ、時間および人数に関するキーワードを抽出する。例えば、抽出部１５ｂは、ログに含まれる各メッセージのテキストの文字列に対し、形態素解析を実行する。そして、抽出部１５ｂは、解析結果として得られた品詞が「名詞」または「固有名詞」である形態素のうち、場所、カテゴリ、時間または人数に関する名詞の形態素をキーワードとして抽出する。

（検索部１５ｃについて）
検索部１５ｃは、抽出部１５ｂによって抽出されたキーワードのうち新たに投稿されたメッセージから抽出されたキーワードほど大きい重みを付与して施設を検索する処理部である。一態様としては、検索部１５ｃは、施設の検索を予約サーバ３０に依頼するにあたって抽出部１５ｃによって抽出された場所、カテゴリ、時間および人数に関するキーワードのうち検索条件の項目として重複するキーワードが複数存在するか否かを判定する。このとき、検索部１５ｃは、検索条件の項目として重複するキーワードが複数存在する場合に、複数存在するキーワードに重み付けを実行する。

まず、検索部１５ｃは、複数存在するキーワードのうち新たに投稿されたメッセージから抽出されたキーワードほど大きい重みを付与する。さらに、検索部１５ｃは、複数存在するキーワードのうち肯定語および否定語の直前に出現するキーワードに次のような重み付けを実行する。例えば、検索部１５ｃは、次のキーワードが出現するまでの間に肯定語が存在するキーワードに、次のキーワードが出現するまでの間に肯定語が存在しないキーワードの重みよりも大きい重みを付与する。つまり、検索部１５ｃは、肯定語の直前に出現するキーワードに大きな重みを付与する。また、検索部１５ｃは、次のキーワードが出現するまでの間に否定語が存在するキーワードに、次のキーワードが出現するまでの間に否定語が存在しないキーワードの重みよりも小さい重みを付与する。つまり、検索部１５ｃは、否定語の直前に出現するキーワードに小さな重みを付与する。加えて、検索部１５ｃは、複数存在するキーワードのうち発言回数が多いユーザによって投稿されたメッセージから抽出されたキーワードほど小さい重みを付与する。

これらの重み付けを実行した後に、検索部１５ｃは、複数存在するキーワードのうち最も重みが大きいキーワードを検索条件として採用する。その上で、検索部１５ｃは、場所、カテゴリ、時間および人数の４つの項目のキーワードが全て揃っている場合に、これらのキーワードを検索条件とし、施設の検索を予約サーバ３０へ依頼する。

（表示部１５ｄについて）
表示部１５ｄは、検索部１５ｃによって検索された施設のレコメンドをトークルームに表示させる処理部である。一態様としては、表示部１５ｄは、予約サーバ３０から検索結果として応答された施設のレコメンドをトークルームに参加するユーザが持つ端末装置５０に出力する。かかる出力を受けて、端末装置５０では、表示部１５ｄによって出力された施設のレコメンドがトークルームにバナー広告として表示されることになる。その後、表示部１５ｄは、端末装置５０に表示されたレコメンドに対する操作がなされた場合に、当該レコメンドを行った施設の予約確認画面をタップ操作がなされた端末装置５０へ出力する。かかる出力を受けて、端末装置５０では、表示部１５ｄによって出力された予約確認画面が表示される。なお、ここでは、バナー広告を表示させる場合を例示したが、テキスト広告であってもかまわない。

（予約部１５ｅについて）
予約部１５ｅは、レコメンドを行った施設の予約処理を実行する処理部である。一態様としては、予約部１５ｅは、端末装置５０に表示された予約確認画面上で予約の実行操作が実行された場合に、先に検索条件として特定された時間や人数、さらには、ＳＮＳのアカウントに登録された情報、例えばユーザＩＤや連絡先などを施設への申請事項とし、当該施設の予約を施設によって運営されるコンピュータへ依頼する。なお、ここでは、レコメンド装置１０が施設のコンピュータへ予約を依頼する場合を例示したが、予約サーバ３０を介して施設の予約を行うこととしてもかまわない。

［３−１．重み付けの具体例１］
次に、図３を用いて、キーワードの重み付けの具体例１について説明する。図３は、メッセージのログの一例を示す図である。ここでは、一例として、各キーワードの初期状態の重みを「１」とし、各々の重み付けで下記の係数が付与されることとする。例えば、検索条件の項目として重複するキーワードのうち最新のメッセージから抽出されたキーワードには、重み係数として「２」が付与される。また、肯定語の直前に出現するキーワードには、重み係数として「１．５」が付与される。また、否定語の直前に出現するキーワードには、重み係数として「０．５」が付与される。また、検索条件の項目として重複する各キーワードには、当該キーワードが抽出されたメッセージを投稿したユーザの発言回数の逆数が付与される。

図３に示すように、ログＬ２に含まれるメッセージＴ１０から「３：３」が人数に関するキーワードとして抽出されるとともに、メッセージＴ１２から「六本木」が場所に関するキーワードとして抽出される。また、メッセージＴ１３から「中華」がカテゴリに関するキーワードとして抽出されるとともに、メッセージＴ１４から「イタリアン」がカテゴリに関するキーワードとして抽出される。さらに、メッセージＴ１５から「ドイツ料理」がカテゴリに関するキーワードとして抽出され、メッセージＴ１６から「７時」が時間に関するキーワードとして抽出されるとともに、メッセージＴ１７から「タイ料理」がカテゴリに関するキーワードとして抽出される。なお、本例では、残りのメッセージＴ１１及びＴ１８からはキーワードが抽出されない。

図３の例では、カテゴリに関するキーワードが「中華」、「イタリアン」、「ドイツ料理」および「タイ料理」の４つが存在し、検索条件の項目として重複している。このうち、「タイ料理」は、カテゴリに関するキーワードのうち最新のメッセージが抽出されたキーワードであるので、重み係数として「２」が付与される。続いて、肯定語の前にも否定語の前にもカテゴリに関するキーワードが存在しないので、肯定語および否定語に関する重み付けは実行されない。最後に、各キーワードに重み係数「１／発言回数」が付与される。これら４つのキーワードのうち「中華」、「イタリアン」および「タイ料理」は、ユーザ「○○」の発言であり、「ドイツ料理」は、ユーザ「マル子」の発言である。よって、「中華」、「イタリアン」および「タイ料理」には、重み係数「１／３」が付与される一方で、「ドイツ料理」には、重み係数「１／１」が付与されることになる。

この結果、「中華」及び「イタリアン」の重みは、「０．３３３…（＝１／３）」となり、「タイ料理」の重みは、「０．６６６…（＝２／３）」となり、「ドイツ料理」の重みは、「１（＝１／１）」となる。よって、カテゴリに関する検索条件には、キーワード「ドイツ料理」が用いられる。その結果、端末装置５０の表示領域Ｐ２の底部に施設「ドイツ料理店Ｄ」のレコメンドＲ２が表示される。

このように、発言回数が多いユーザによって投稿されたメッセージから抽出されたキーワードほど小さい重みを付与することによって、３回もカテゴリに関する発言を行っているユーザ「○○」の発言にかき消されることなく、１回しか発言していないユーザ「マル子」の発言を尊重できる。

［３−２．重み付けの具体例２］
続いて、図４を用いて、キーワードの重み付けの具体例２について説明する。図４は、メッセージのログの一例を示す図である。ここでも、上記の具体例１と同様の重み係数が付与されるもととして以下の説明を行う。

図４に示すように、ログＬ３に含まれるメッセージＴ２１から「３：３」が人数に関するキーワードとして抽出されるとともに、メッセージＴ２３から「六本木」が場所に関するキーワードとして抽出される。また、メッセージＴ２４から「中華」がカテゴリに関するキーワードとして抽出されるとともに、メッセージＴ２５から「ドイツ料理」がカテゴリに関するキーワードとして抽出される。さらに、メッセージＴ２７から「××料理」がカテゴリに関するキーワードとして抽出され、メッセージＴ３２から「７時」が時間に関するキーワードとして抽出される。また、施設の検索に用いるキーワードではないが、メッセージＴ２６から「いい」が肯定語として抽出され、メッセージＴ２８から「やだ」が否定語として抽出されるとともに、メッセージＴ２９から「苦手」が否定語として抽出される。

図４の例では、カテゴリに関するキーワードが「中華」、「ドイツ料理」および「××料理」の３つが存在し、検索条件の項目として重複している。このうち、「××料理」は、カテゴリに関するキーワードのうち最新のメッセージが抽出されたキーワードであるので、重み係数として「２」が付与される。しかしながら、否定語「苦手」の直前に出現するキーワードは、「××料理」であり、否定語「やだ」の直前に出現するキーワードも、「××料理」である。このため、重み係数として「０．５」、「０．５」が付与される。一方、肯定語「いい」の直前に出現するキーワードは、「ドイツ料理」であるので、重み係数として「１．５」が付与される。最後に、各キーワードに重み係数「１／発言回数」が付与される。これら３つのキーワードのうち「中華」および「ドイツ料理」は、ユーザ「○○」の発言であり、「××料理」は、ユーザ「あの人」の発言である。よって、「中華」および「ドイツ料理」には、重み係数「１／２」が付与される一方で、「××料理」には、重み係数「１／１」が付与されることになる。

この結果、「××料理」の重みは、「０．５（＝１×２×０．５×０．５×１）」となり、「中華」の重みは、「０．５（＝１／２）」となり、「ドイツ料理」の重みは、「０．７５（＝１×１．５／２）」となる。よって、カテゴリに関する検索条件には、キーワード「ドイツ料理」が用いられる。その結果、端末装置５０の表示領域Ｐ３の底部に施設「ドイツ料理店Ｄ」のレコメンドＲ３が表示される。

このように、肯定語の直前に出現するキーワードに大きな重みを付与する一方で、否定語の直前に出現するキーワードに小さな重みを付与することによって、発言者以外の評価を反映した上でキーワードの重み付けを実行できる結果、予約施設にユーザ全体の意見をより正確に反映できる。

［４．レコメンド装置による処理手順］
次に、実施形態に係るレコメンド装置１０による処理手順について説明する。図５は、実施形態に係るレコメンド処理の手順を示すフローチャートである。図５に示すフローチャートは、一例として、トークルームごとに処理が並列して実行される。

図５に示すように、トークルームに新規のメッセージが書き込まれると（ステップＳ１０１Ｙｅｓ）、収集部１５ａは、トークルームからメッセージのログを収集する（ステップＳ１０２）。続いて、抽出部１５ｂは、ステップＳ１０２で収集されたログに含まれる各メッセージから場所、カテゴリ、時間および人数に関するキーワードを抽出する（ステップＳ１０３）。

そして、検索部１５ｃは、ステップＳ１０３で抽出されたキーワードに場所、カテゴリ、時間または人数のうちいずれかの項目の不足がないか否かを判定する（ステップＳ１０４）。このとき、キーワードに不足がある場合（ステップＳ１０４Ｎｏ）には、施設の検索を実行しても施設を絞り込めないので、ステップＳ１０１の処理に戻る。

一方、キーワードに不足がない場合（ステップＳ１０４Ｙｅｓ）には、検索部１５ｃは、複数存在するキーワードのうち新たに投稿されたメッセージから抽出されたキーワードほど大きい重みを付与する。これとともに、検索部１５ｃは、複数存在するキーワードのうち肯定語の直前に出現するキーワードに大きな重みを付与する一方で、否定語の直前に出現するキーワードに小さな重みを付与する（ステップＳ１０５）。加えて、検索部１５ｃは、複数存在するキーワードのうち発言回数が多いユーザによって投稿されたメッセージから抽出されたキーワードほど小さい重みを付与する（ステップＳ１０６）。

その後、検索部１５ｃは、検索条件の項目として重複する複数のキーワードのうち最も重みが大きいキーワードを採用し、場所、カテゴリ、時間および人数の４つの項目のキーワードを検索条件とし、施設の検索を予約サーバ３０へ依頼する（ステップＳ１０７）。

そして、表示部１５ｄは、予約サーバ３０から検索結果として応答された施設のレコメンドをトークルームに参加するユーザが持つ端末装置５０に出力する（ステップＳ１０８）。これによって、端末装置５０では、施設のレコメンドをトークルームにバナー広告として表示される。

続いて、端末装置５０に表示されたレコメンドに対する操作がなされた場合（ステップＳ１０９Ｙｅｓ）には、表示部１５ｄは、当該レコメンドを行った施設の予約確認画面をタップ操作がなされた端末装置５０へ出力する（ステップＳ１１０）。かかる出力を受けて、端末装置５０では、表示部１５ｄによって出力された予約確認画面が表示される。なお、レコメンドに対する操作がなされなかった場合（ステップＳ１０９Ｎｏ）には、上記のステップＳ１０１の処理へ戻る。

その後、端末装置５０に表示された予約確認画面上で予約の実行操作が実行された場合（ステップＳ１１１Ｙｅｓ）には、予約部１５ｅは、先に検索条件として特定された時間や人数、さらには、ＳＮＳのアカウントに登録された情報、例えばユーザＩＤや連絡先などを施設への申請事項とし、当該施設の予約を施設によって運営されるコンピュータへ依頼し（ステップＳ１１２）、処理を終了する。なお、予約確認画面上で予約の実行操作が実行されなかった場合（ステップＳ１１１Ｎｏ）には、上記のステップＳ１０１へ戻る。

［５．変形例及び応用例］
上記の実施形態に係るレコメンド装置１０は、上記の実施形態以外にも種々の異なる形態にて実施されてよい。そこで、以下では、上記のレコメンド装置１０の他の実施形態について説明する。

［５−１．複数のレコメンド表示］
上記の実施形態では、レコメンド装置１０が端末装置５０の表示領域の底部に施設のレコメンドを１つ表示させる場合を例示したが、施設のレコメンドを複数表示させることもできる。本実施形態に係るレコメンド装置１０は、施設のレコメンドを複数表示させる場合に、施設の検索に用いられたキーワードが含まれるメッセージに対応付けて施設のレコメンドを表示させることができる。

図６は、レコメンドの表示方法の一例を示す図である。図６に示すように、ログＬ４に含まれるメッセージＴ４１から「３：３」が人数に関するキーワードとして抽出されるとともに、メッセージＴ４３から「六本木」が場所に関するキーワードとして抽出される。また、メッセージＴ４４から「中華」がカテゴリに関するキーワードとして抽出されるとともに、メッセージＴ４５から「イタリアン」がカテゴリに関するキーワードとして抽出される。さらに、メッセージＴ４６から「ドイツ料理」がカテゴリに関するキーワードとして抽出され、メッセージＴ４８から「７時」が時間に関するキーワードとして抽出される。

図６の例で言えば、カテゴリに関するキーワードが「中華」、「イタリアン」および「ドイツ料理」の３つが存在し、検索条件の項目として重複している。この場合には、レコメンド装置１０は、キーワード「中華」を含むメッセージＴ４４に対応付けて中華飯店ＣのレコメンドＲ１０を表示させ、キーワード「イタリアン」を含むメッセージＴ４５に対応付けてイタリアンレストランＡのレコメンドＲ１１を表示させるとともに、キーワード「ドイツ料理」を含むメッセージＴ４６に対応付けてドイツ料理店ＤのレコメンドＲ１２を表示させる。これによって、トークルームに参加するユーザは、バナー広告によって複数の施設の間で比較をしながら予約に値するかどうかを思考することができる。また、施設のレコメンドがスタンプのごとく表示されるので、デザイン性も向上させることができる。

このように、端末装置５０に施設のレコメンドを複数表示させる場合には、３つの施設のレコメンドＲ１０〜Ｒ１２の各々に投票ボタンＢ１０〜Ｂ１２をさらに表示させることもできる。例えば、端末装置５０に表示された中華飯店ＣのレコメンドＲ１０の投票ボタンＢ１０がタップ操作された場合には、レコメンド装置１０は、中華飯店Ｃへ行くのに賛成であるか、あるいは反対であるのかを投票できる投票画面を端末装置５０に表示させる。かかる投票画面には、図６に示すように、賛成ボタンＢ２０と、反対ボタンＢ２１とが設けられている。トークルームに参加する各メンバは、賛成ボタンＢ２０または反対ボタンＢ２１のいずれかをタップ操作することによって中華飯店Ｃへ行くのに賛成であるか、あるいは反対であるのかを意思表示できる。

［５−２．レコメンドの段階表示］
また、レコメンド装置１０は、図６に示したように、施設のレコメンドを複数表示させる場合には、施設間でバナーの大きさや広告の詳細度を変えて表示させることもできる。例えば、施設への賛成票の投票回数が多いほど施設のバナー広告を大きくしたり、あるいは広告の内容を詳細にしたりすることができる。これとは逆に、施設への反対票の投票回数が多いほど施設のバナー広告を小さくしたり、あるいは広告の内容を荒くしたりすることができる。

図７は、レコメンドの表示方法の一例を示す図である。図７に示すメッセージのログＬ４は、図６に示したメッセージのログＬ４と同様である。図７に示すように、中華飯店ＣのレコメンドＲ１０、イタリアンレストランＡのレコメンドＲ１１及びドイツ料理店ＤのレコメンドＲ１２０のうちドイツ料理店Ｄの賛成票の投票率が所定の閾値、例えば半数以上である。このため、ドイツ料理店ＤのレコメンドＲ１２０が中華飯店ＣのレコメンドＲ１０及びイタリアンレストランＡのレコメンドＲ１１よりも大きく、かつ広告の内容が詳細化されている。かかるレコメンドの段階表示を実行することによって、表示の大きさや詳細度から他のユーザがどの施設に高い関心を持っているのかを直感的に把握できる。さらに、半数を超えた施設のレコメンドＲ１２０には、投票ボタンＢ１２だけでなく、予約ボタンＢ１２０も併せて表示される。かかる予約ボタンＢ１２０がタップ操作された場合には、予約確認画面の表示なしに予約処理が実行される。これによって、トークルームに参加するユーザによって広く受け入れられている施設をワンタッチで予約まで誘導させることもできる。

［５−３．レコメンドの分割表示］
また、レコメンド装置１０は、図６に示したように、施設のレコメンドを複数表示させる場合には、端末装置５０の表示領域をメッセージの表示領域とレコメンドの表示領域とに分割することもできる。

図８は、レコメンドの表示方法の一例を示す図である。図８に示すように、ログＬ５に含まれるメッセージＴ５１から「３：３」が人数に関するキーワードとして抽出されるとともに、メッセージＴ５３から「六本木」が場所に関するキーワードとして抽出される。また、メッセージＴ５４から「中華」がカテゴリに関するキーワードとして抽出されるとともに、メッセージＴ５５から「イタリアン」がカテゴリに関するキーワードとして抽出される。さらに、メッセージＴ５７から「ドイツ料理」がカテゴリに関するキーワードとして抽出され、メッセージＴ６１から「７時」が時間に関するキーワードとして抽出される。

図８に示すように、端末装置５０上で所定の分割操作、例えばボタンタップがなされた場合には、表示領域Ｐ６のうち境界線Ｚを境界にし、右側には、メッセージが表示される一方で、左側には、施設のレコメンドＲ３０〜Ｒ３２とその投票ボタンＢ３０〜Ｂ３２が表示される。このように、メッセージの表示領域とレコメンドの表示領域とを分割して表示を実行する場合には、レコメンドをメッセージに対応付けずにタイムラインに沿って整列させることができる。このため、レコメンドをメッセージに対応付けて表示させる場合には、古いメッセージに対応付けられたレコメンドを画面内に表示させることはできないが、分割時には、古いメッセージに対応付けられたレコメンドを表示させることができる。

［５−４．リマインド］
本実施形態に係るレコメンド装置１０は、上記の実施形態の応用例として、予約時間よりも前に設定された設定時間になった場合に、注意喚起を行うこともできる。

例えば、レコメンド装置１０は、ＯＳ等によって内部管理された現時刻が予約時間よりも前の時間であって予め設定された設定時間、例えば予約時間の１時間前あるいは当日になったか否かを判定する。その上で、レコメンド装置１０は、現時刻が設定時間になった場合に、図９に示すリマインド画面を端末装置５０Ａに表示させる。図９は、リマインド画面の一例を示す図である。図９には、合コン当日になった場合に端末装置５０Ａに通知されたリマインド画面が図示されている。図９に示すリマインド画面の表示によって、ユーザは、本日の８月２８日の１９時００分から六本木のドイツ料理店Ｄで合コンの予定があったことを思い出すことができる。かかるリマインド画面に、合コンのリマインドに併せて予算を表示させることによって予め必要な現金を用意しておくことができる。さらに、図９に示すリマインド画面に表示された「地図を見る」ボタンＢ５０が押下された場合には、勤務地から集合場所である六本木のドイツ料理店Ｄまでの地図を表示させることができる。これによって、ユーザは、予約時間に遅れず、さらに、迷わずに現地へ到着することが可能になる。

［５−５．成果報酬型の課金］
本実施形態に係るレコメンド装置１０は、上記の実施形態の応用例として、施設の予約が成立した場合に、当該施設に対し、送客の対価を課金することもできる。

［５−６．分散および統合］
また、図示した各装置の各構成要素は、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。例えば、収集部１５ａ、抽出部１５ｂ、検索部１５ｃ、表示部１５ｄまたは予約部１５ｅをレコメンド装置１０の外部装置としてネットワーク経由で接続するようにしてもよい。また、収集部１５ａ、抽出部１５ｂ、検索部１５ｃ、表示部１５ｄまたは予約部１５ｅを別の装置がそれぞれ有し、ネットワーク接続されて協働することで、上記のレコメンド装置１０の機能を実現するようにしてもよい。すなわち、レコメンド装置１０は、複数のサーバコンピュータで実現してもよく、また、機能によっては外部のプラットフォーム等をＡＰＩ（Application Programming Interface）やネットワークコンピューティングなどで呼び出して実現するなど、構成は柔軟に変更できる。

［５−７．レコメンドプログラム］
上記の実施形態におけるレコメンド装置１０は、例えば図１０に示すような構成のコンピュータ１００によって実現される。図１０は、レコメンド装置１０の機能を実現するコンピュータ１００の一例を示すハードウェア構成図である。コンピュータ１００は、ＣＰＵ１１０、ＲＡＭ１２０、ＲＯＭ１３０、ＨＤＤ１４０、通信インターフェイス（Ｉ／Ｆ）１５０、入出力インターフェイス（Ｉ／Ｆ）１６０およびメディアインターフェイス（Ｉ／Ｆ）１７０を有する。

ＣＰＵ１１０は、ＲＯＭ１３０またはＨＤＤ１４０に格納されたプログラムに基づいて動作し、各部の制御を行う。ＲＯＭ１３０は、コンピュータ１００の起動時にＣＰＵ１１０によって実行されるブートプログラムや、コンピュータ１００のハードウェアに依存するプログラム等を格納する。

ＨＤＤ１４０は、ＣＰＵ１１０によって実行されるプログラムおよび当該プログラムによって使用されるデータ等を格納する。通信インターフェイス１５０は、ネットワークＮを介して他の機器からデータを受信してＣＰＵ１１０へ送り、ＣＰＵ１１０が生成したデータを、ネットワークＮを介して他の機器へ送信する。

ＣＰＵ１１０は、入出力インターフェイス１６０を介して、ディスプレイやプリンタ等の出力装置、および、キーボードやマウス等の入力装置を制御する。ＣＰＵ１１０は、入出力インターフェイス１６０を介して、入力装置からデータを取得する。また、ＣＰＵ１１０は、生成したデータを、入出力インターフェイス１６０を介して出力装置へ出力する。

メディアインターフェイス１７０は、記録媒体１８０に格納されたプログラムまたはデータを読み取り、ＲＡＭ１２０を介してＣＰＵ１１０に提供する。ＣＰＵ１１０は、当該プログラムを、メディアインターフェイス１７０を介して記録媒体１８０からＲＡＭ１２０上にロードし、ロードしたプログラムを実行する。記録媒体１８０は、例えばＤＶＤ（Digital Versatile Disc）、ＰＤ（Phase change rewritable Disk）等の光学記録媒体、ＭＯ（Magneto-Optical disk）等の光磁気記録媒体、テープ媒体、磁気記録媒体、または半導体メモリ等である。

コンピュータ１００が上記の実施形態におけるレコメンド装置１０として機能する場合、コンピュータ１００のＣＰＵ１１０は、ＲＡＭ１２０上にロードされたプログラムを実行することにより、収集部１５ａ、抽出部１５ｂ、検索部１５ｃ、表示部１５ｄ及び予約部１５ｅの各機能を実現する。また、ＨＤＤ１４０には、記憶部１３内のデータが格納される。

コンピュータ１００のＣＰＵ１１０は、これらのプログラムを、記録媒体１８０から読み取って実行するが、他の例として、他の装置から、ネットワークＮを介してこれらのプログラムを取得してもよい。

１０ レコメンド装置
１１ 通信Ｉ／Ｆ部
１３ 記憶部
１３ａ ログデータ
１５ 制御部
１５ａ 収集部
１５ｂ 抽出部
１５ｃ 検出部
１５ｄ 表示部
１５ｅ 予約部
２０ ＳＮＳサーバ
３０ 予約サーバ
５０Ａ，５０Ｂ，５０Ｎ 端末装置

Claims (9)

1. 複数人のユーザが投稿したメッセージが掲載されたルームからメッセージのログを収集する収集部と、
   前記収集部によって収集されたログに含まれるメッセージからキーワードを抽出する抽出部と、
   前記抽出部によって抽出されたキーワードのうち新たに投稿されたメッセージから抽出されたキーワードほど大きい重みを付与して施設を検索する検索部と、
   前記検索部によって検索された施設のレコメンドを前記ルームに表示させる表示部と
   を有することを特徴とするレコメンド装置。
2. 前記抽出部は、
   施設に関する場所、カテゴリ、時間および人数に関するキーワードを抽出し、
   前記検索部は、
   前記抽出部によって抽出された場所、カテゴリ、時間および人数に関するキーワードで指定される条件を満たす施設を検索することを特徴とする請求項１に記載のレコメンド装置。
3. 前記検索部は、
   前記抽出部によって抽出されたキーワードに当該キーワードを含むメッセージを投稿したユーザの投稿回数の多寡によって定まる重みを付与して施設を検索することを特徴とする請求項１または２に記載のレコメンド装置。
4. 前記抽出部は、
   前記キーワードが抽出されたメッセージの後に投稿されたメッセージに含まれる肯定語または否定語をさらに抽出し、
   前記検索部は、
   前記抽出部によって抽出された肯定語および否定語の直前に出現するキーワードに重みを付与して施設を検索することを特徴とする請求項１、２または３に記載のレコメンド装置。
5. 前記表示部は、
   前記検索部によって検索された施設のレコメンドを、前記ルームのライムライン上に表示されるメッセージのうち当該施設の検索に用いられたキーワードが抽出されたメッセージに対応付けて表示させることを特徴とする請求項１〜４のいずれか一つに記載のレコメンド装置。
6. 前記表示部は、
   前記メッセージに対応付けて表示される施設のレコメンドに対する賛成または反対の投票結果にしたがって前記施設のレコメンドの表示態様を変化させることを特徴とする請求項５に記載のレコメンド装置。
7. 前記表示部は、
   前記ルームが表示される端末装置の表示領域をメッセージの表示領域と施設のレコメンドの表示領域とに分割して前記メッセージおよび前記施設のレコメンドを表示させることを特徴とする請求項１〜６のいずれか一つに記載のレコメンド装置。
8. コンピュータが、
   複数人のユーザが投稿したメッセージが掲載されたルームからメッセージのログを収集する収集工程と、
   前記収集工程によって収集されたログに含まれるメッセージからキーワードを抽出する抽出工程と、
   前記抽出工程によって抽出されたキーワードのうち新たに投稿されたメッセージから抽出されたキーワードほど大きい重みを付与して施設を検索する検索工程と、
   前記検索工程によって検索された施設のレコメンドを前記ルームに表示させる表示工程と
   を実行することを特徴とするレコメンド方法。
9. コンピュータに、
   複数人のユーザが投稿したメッセージが掲載されたルームからメッセージのログを収集する収集手順と、
   前記収集手順によって収集されたログに含まれるメッセージからキーワードを抽出する抽出手順と、
   前記抽出手順によって抽出されたキーワードのうち新たに投稿されたメッセージから抽出されたキーワードほど大きい重みを付与して施設を検索する検索手順と、
   前記検索手順によって検索された施設のレコメンドを前記ルームに表示させる表示手順と
   を実行させることを特徴とするレコメンドプログラム。

Images