JP2020030469A - 情報処理装置、情報処理方法、及び情報処理プログラム - Google Patents

Abstract

【課題】ユーザが求める最適な施設を容易に検索可能な情報処理装置、情報処理方法、及び情報処理プログラムを提供する。【解決手段】サーバ装置１０は、第一ユーザに関する第一ユーザ属性、及び第二ユーザに関する第二ユーザ属性を取得するユーザ情報取得部１３１と、第一ユーザと第二ユーザとの関係性を判定する関係判定部１３５と、施設及び施設属性を関連付けた施設データを記憶する施設ＤＢ１２Ｂから、第一ユーザ属性及び第二ユーザ属性の少なくとも一方に対応し、かつ、第一ユーザ及び第二ユーザの関係性に対応する施設を検索する施設検索部１３７と、を備える。【選択図】図２

Description

本発明は、情報処理装置、情報処理方法、及び情報処理プログラムに関する。

従来、ユーザが入力した条件に合った施設を検索する情報処理システムが知られている（例えば、特許文献１参照）。
特許文献１に記載のような情報処理システムでは、ユーザからの検索クエリを受け付け、検索クエリに対する施設を検索する。この際、この情報処理システムでは、検索クエリと合致する属性を特定し、その属性に関連する施設に属性スコアを付与する。そして、検索クエリに基づいて各施設に付与される一般スコアに、前記属性スコアを反映させて出力順位を決定し、上位の施設を検索結果として出力する。

特開２０１８−２８７３２号公報

特許文献１に記載のような従来のシステムでは、ユーザが所望の施設を検索するために検索クエリを入力する必要がある。しかしながら、複数のユーザで施設を利用する場合では、各ユーザのそれぞれの好みを考慮した施設検索や、ユーザ同士の関係性を考慮した施設検索を求める場合もある。従来のシステムを用いてこのような施設検索を実施する場合、入力する検索クエリが複雑で、煩雑であるとの課題があった。
例えば、ユーザが恋人とデートをする場合を想定する。ユーザは、初回のデートでは、店舗内が明るく開放的な雰囲気の飲食店を求める場合がある。または、ユーザは、恋人に加え、気の許せる数人の友人と一緒にスポーツを楽しめるスポーツ施設を求めることがある。一方、複数回のデートを重ねることで、ユーザは、恋人と２人きりになれる個室タイプの飲食店や、夜景が楽しめる展望台等を求めることがある。
しかしながら、従来の施設紹介システムでは、ユーザが、検索クエリとして、「多人数」「個室タイプ」や「夜景」等のキーワードを入力しなければ、上記のようなユーザが求める最適な施設を検索することができない。これに加え、ユーザや恋人の嗜好に応じた検索クエリをさらに入力する必要もあり、施設検索に係る処理が煩雑となっていた。

本発明は、ユーザが求める最適な施設を容易に検索可能な情報処理装置、情報処理方法、及び情報処理プログラムを提供することを目的とする。

本発明の情報処理装置は、第一ユーザに関する第一ユーザ属性、及び第二ユーザに関する第二ユーザ属性を取得するユーザ情報取得部と、前記第一ユーザと前記第二ユーザとの関係性を判定する関係判定部と、施設及び前記施設の属性に関する施設属性を関連付けた施設データを記憶する施設データベースから、前記第一ユーザ属性及び前記第二ユーザ属性の少なくとも一方に対応し、かつ、前記第一ユーザ及び前記第二ユーザの前記関係性に対応する前記施設を検索する施設検索部と、を備えることを特徴とする。

本発明は、第一ユーザ及び第二ユーザの関係性を判定し、第一ユーザ及び第二ユーザの少なくとも一方のユーザ属性と、第一ユーザ及び第二ユーザの関係性とに基づいて施設を検索する。この場合、第一ユーザ及び第二ユーザの関係性に応じた詳細な検索クエリを入力することなく、第一ユーザ及び第二ユーザの関係性に応じた最適な施設を検索することができる。

本発明の一実施形態に係る情報処理装置であるサーバ装置を含む情報処理システムの概略構成を示すブロック図。 本実施形態のサーバ装置の概略構成を示すブロック図。 本実施形態の情報検索方法に係る、ユーザ情報の登録処理、及びメッセージの送受信処理を示すフローチャート。 本実施形態の情報検索方法に係る、デート提案処理（施設検索処理）のフローチャート。 ステップＳ２６により検索された施設検索結果と、親密度が低ランクであるユーザに対するデート提案例と、親密度が高ランクであるユーザに対するデート提案例とを示す図。 本実施形態の情報検索方法に係る、フィードバック処理のフローチャート。 本実施形態における施設評価依頼情報の一例を示す図。

以下、本発明に係る一実施形態の情報処理装置について説明する。
図１は、本実施形態の情報処理装置であるサーバ装置１０を含む情報処理システム１の概略構成を示すブロック図である。
図１に示すように、情報処理システム１は、サーバ装置１０と、サーバ装置１０にネットワーク（例えばインターネット等）を介して通信可能に接続される複数のユーザ端末２０とにより構築されている。なお、図１において、ユーザ端末２０のうちの１つを、第一ユーザが操作する第一ユーザ端末２０Ａとして示し、第一ユーザと恋人等の人間関係にある第二ユーザが操作するユーザ端末２０を第二ユーザ端末２０Ｂとして示している。

本実施形態の情報処理システム１は、インターネットを介して他のユーザとメッセージの交換が可能なソーシャルネットワークサービス（ＳＮＳ）や、相性の合う他のユーザを探索するマッチングサービスを提供することができる。
このような情報処理システム１では、各ユーザが、ユーザ端末２０を操作してプロフィール等のユーザ属性を含むユーザ情報をサーバ装置１０に送信する。サーバ装置１０は、得られたユーザ情報をデータベースに登録し、ユーザが許可した特定のユーザ属性を閲覧可能に公開してユーザ間のコミュニケーションをサポートする。例えば、システム上でユーザ間のメッセージ交換を許可したり、ユーザ属性に基づいて相性が合う他のユーザを紹介したりする。

そして、本実施形態のサーバ装置１０は、ユーザ端末２０からの要求により、ユーザ同士で利用する施設を紹介する施設紹介処理を実施する。ここで、本実施形態の情報処理システム１では、施設を利用する複数のユーザの関係性を考慮した施設検索処理を実施する。
このユーザの関係性としては、男女関係、友人関係、親子関係、職場等における先輩後輩関係、上司と部下との関係等、複数の人間関係を例示できるが、本実施形態では、一例として、男女関係にあるユーザ（第一ユーザ及び第二ユーザ）に対する施設検索処理（デート提案処理）について以降に説明する。

［サーバ装置１０の構成］
図２は、本実施形態のサーバ装置１０の概略構成を示すブロック図である。
本実施形態のサーバ装置１０は、コンピュータにより構成され、通信部１１と、記憶部１２と、制御部１３と、等を含んで構成されている。
通信部１１は、ネットワークに接続されており、ネットワークを介してユーザ端末２０や、ネットワーク上のその他の装置と通信する。

記憶部１２は、例えばメモリ、ハードディスク等により構成された情報記録装置（副記憶装置）であり、各種情報や各種プログラムが記憶されている。
この記憶部１２は、ユーザデータベース（ユーザＤＢ１２Ａ）と、施設データベース（施設ＤＢ１２Ｂ）と、関係管理データベース（関係管理ＤＢ１２Ｃ）とを含んで構成されている。
また、記憶部１２は、ユーザへのメッセージを記憶するメッセージ記憶部を備える。このメッセージ記憶部１２Ｄには、ユーザ毎のメッセージボックスが設けられており、ユーザに送信されたメッセージがメールボックス内に記憶される。
なお、ここでは、サーバ装置１０の記憶部１２に、ユーザＤＢ１２Ａ、施設ＤＢ１２Ｂ、関係管理ＤＢ１２Ｃ、メッセージ記憶部１２Ｄが設けられる例を示すが、サーバ装置１０とネットワークを介して通信可能に接続された他のデータサーバに、これらの、ユーザＤＢ１２Ａ、施設ＤＢ１２Ｂ、関係管理ＤＢ１２Ｃ、メッセージ記憶部１２Ｄが設けられる構成としてもよい。
さらに、記憶部１２には、サーバ装置１０を情報処理装置として機能させるための情報処理プログラムが記憶されている。

（ユーザＤＢ１２Ａに記憶されるユーザ情報）
ユーザＤＢ１２Ａは、ユーザ毎のユーザ情報を記憶するデータベースである。
このユーザ情報は、ユーザＩＤ、ユーザ名、ユーザ属性、スケジュール情報、履歴情報等を含む。
ユーザＩＤは、個々のユーザを識別するための情報であり、ユーザ名は、ユーザの名称（氏名やハンドルネーム等）である。

ユーザ属性は、ユーザに関する様々な情報が記録される。例えば、ユーザ属性として、ユーザの性別、年齢（年齢層）、居所（居住地域）、職種、職場、及び家族構成等の個人情報が含まれる。また、ユーザ属性として、趣味、興味分野、好物、嫌いな物、好きな異性のタイプ、嫌いな異性のタイプ、ユーザ自身の性格、容姿等のアピール情報が含まれる。これらのユーザ属性は、ユーザ端末２０からサーバ装置１０に送信されることで登録される情報であってもよく、サーバ装置１０が、ユーザのインターネット上の行動履歴から予測するものであってもよい。

スケジュール情報は、ユーザのスケジュールである。このスケジュール情報は、所定のタイミングで、ユーザ端末２０からサーバ装置１０に送信される。例えば、ユーザ端末２０にインストールされた所定のスケジュール管理アプリケーションが、自動または手動によりスケジュールをアップロードする。または、ユーザがユーザ端末２０からサーバ装置１０が提供するスケジュール管理ページにアクセスしてもよい。この場合、ユーザは、スケジュール管理ページを編集することで、サーバ装置１０は、ユーザのスケジュール情報を取得できる。

履歴情報は、ユーザのインターネット上の行動履歴であり、例えば、オンラインショップにおける商品の購入履歴、検索エンジン等で使用された検索キーワードの履歴、ＷＥＢサイトのブックマーク履歴やページ閲覧履歴等が含まれる。

（施設ＤＢ１２Ｂに記憶される施設情報）
施設ＤＢ１２Ｂには、複数の施設情報が記憶されている。施設情報には、施設ＩＤ、施設名、施設位置、施設属性等の各種情報が含まれる。
施設ＩＤは、個々の施設を識別するための情報であり、各施設情報には、それぞれ１つの施設ＩＤが付与されている。施設名は、施設の名称を示す情報であり、施設位置は、施設の住所や経緯度等の施設の位置を示す情報である。

施設属性は、例えば、施設のカテゴリ（飲食店、スポーツジム、レジャー施設等）、施設で提供されるサービスやサービス料等の施設で提供するサービスに関するサービス属性を含む。また、施設属性は、施設の規模、施設内の明るさ、客室の広さ、施設内の静かさ、施設を利用する利用客の客層（ターゲット層）等の、施設内の雰囲気や状態に関するステータス属性を含む。
また、施設属性として、ユーザから送信される評価や、投稿情報が記録されていてもよい。評価としては、例えば、施設内の明るさ、静かさ、カップル向きや女子会向き等の施設の雰囲気や状態に対する複数の項目、飲食物の美味しさ等の施設で取り扱う商品やサービスに対する複数の項目が含まれていてもよい。
投稿情報としては、例えばユーザが投稿したテキスト文章の他、テキスト文章の解析により得られたキーワード等がタグとして記録されていてもよい。

（関係管理ＤＢ１２Ｃに記憶される関係管理情報）
関係管理ＤＢ１２Ｃには、ユーザ間の関係性を示す関係管理情報が記録されている。なお、ここでは、関係管理ＤＢ１２Ｃに関係管理情報が記録される例を示すが、ユーザ情報に関係管理情報が含まれていてもよい。
この関係管理情報には、ユーザＩＤ、関係ユーザＩＤ、デート回数、施設利用情報、近傍話題情報、及び親密度等が記録される。

ユーザＩＤ及び関係ユーザＩＤは、関係管理情報で管理されるユーザを識別する情報であり、ユーザ情報のユーザＩＤと共通である。
個々のユーザに対して、それぞれ１つの関係管理情報を形成する場合、ユーザＩＤは、主体となるユーザ（第一ユーザ）を識別するユーザＩＤとなる。関係ユーザＩＤは、ユーザＩＤにより特定される第一ユーザと関係があるユーザのユーザＩＤである。つまり、第一ユーザと恋人関係、または、第一ユーザが好意を持っている、あるいは、第一ユーザに好意を持っている他のユーザのユーザＩＤである。
複数のユーザと関係を有する第一ユーザでは、そのユーザの数だけ関係ユーザＩＤが記録され、各関係ユーザＩＤに関連付けられてデート回数、施設利用情報、近傍話題情報、及び親密度が記録される。

なお、ここでは、個々のユーザに対して、それぞれ１つの関係管理情報が形成される例を示すがこれに限定されない。ユーザ間の組合せに応じた数だけ関係管理情報が形成されてもよい。つまり、１人のユーザが、複数のユーザと関係を持っている場合、その組み合わせの数だけ関係管理情報が生成される。

デート回数は、ユーザ同士が施設等においてデートを行った回数である。
施設利用情報には、ユーザ同士で利用した施設の利用施設履歴、施設に対する評価、利用施設傾向等が記録される。
利用施設履歴は、ユーザがデートで利用した施設の履歴である。利用施設履歴に記録される施設は、サーバ装置１０からユーザ端末２０にデート提案情報として紹介された施設であってもよく、デート提案情報とは別に個別にユーザ同士で訪れた施設であってもよい。

施設に対する評価は、利用施設に対する第一ユーザ及び第二ユーザの評価である。施設ＤＢ１２Ｂに記録される施設情報における評価が、施設を利用する全ユーザの総合的な評価であるのに対し、施設利用情報に記録される評価は、関係管理情報のユーザＩＤ及び関係ユーザＩＤで特定される第一ユーザ及び第二ユーザの、施設に対する評価となる。
つまり、施設に対する評価、特に施設の雰囲気等のステータス属性に関する評価は、施設の利用目的や、共に施設を利用する他のユーザによって変化する場合がある。例えば、第一ユーザが同性の友人と訪れた際に、施設内の明るさが適切であると感じた施設であっても、第一ユーザが恋人と施設を訪れた際に、施設内が暗すぎて相手がよく見えないと、不満を感じる場合もある。つまり、施設利用情報に記録される評価は、第一ユーザと第二ユーザとの関係性に基づいた評価となる。

利用施設傾向は、第一ユーザ及び第二ユーザが施設を選択する際の傾向を示す情報である。例えば、第一ユーザ及び第二ユーザのいずれかの嗜好（ユーザ属性）に偏った施設が利用されているか、よく利用される施設において共通の施設属性があるか等を示す。この利用施設傾向は、第一ユーザ及び第二ユーザが利用した各施設の履歴、各施設に対する各々の評価、各ユーザのユーザ属性等に基づいて判定される。

近傍話題情報は、第一ユーザと第二ユーザとの間で送受信されたメッセージに含まれるキーワードの履歴である。言い換えると、２者間のメッセージの話題が履歴として記録されている。
親密度は、ユーザ同士の関係性を示すパラメーターの１つであり、ユーザ同士の親密さを示す値となる。例えば、ネットワーク上で知り合ったものの、会ったことがない関係では第１ランクの親密度、１回だけ会ったことがある関係を第２ランクの親密度、２回デートしたことがある関係を第３ランクの親密度、３回のデートを積み重ねた関係を第４ランクの親密度等とする。
なお、上記例では、デート回数に応じて親密度が上がる一例であるが、これに限定されない。例えば、本実施形態では、ユーザ間でのメッセージ送受信の回数や頻度、メッセージの内容等により親密度が算出される。つまりメッセージ送受信の回数や頻度が高い程、ユーザ同士が親密である可能性が高い。また、メッセージの内容において、デートの場所や日付を求めるキーワードが多い程、親密である可能性が高い。さらに、メッセージの文体において、敬語体から相手と対等な言葉使い（いわゆる、タメ語）に変化した場合、親密度が上がった可能性が高い。メッセージの回数や頻度や内容、デート回数等の複数の要素に基づいてユーザ間の親密度が算出されることがより好ましい。
さらには、親密度として、過去の親密度の履歴が記録されていてもよい。

また、記憶部１２には、その他、施設情報に含まれるステータス属性と、ユーザ同士の関係性とを対応付けたデート施設対応情報が記録されている。
このデート施設対応情報には、ユーザ同士の関係性に対して、ユーザ間の関係を好適に進展させるための施設のステータス属性が記録されている。

（制御部１３の機能構成）
制御部１３は、ＣＰＵ（Central Processing Unit）等の演算回路、ＲＡＭ（Random Access Memory）等の記憶回路により構成される。制御部１３は、記憶部１２等に記憶されているプログラムをＲＡＭに展開し、ＲＡＭに展開されたプログラムとの協働で、各種処理を実行する。
そして、制御部１３は、記憶部１２に記憶された情報処理プログラムを読み取り実行することで、図２に示すように、ユーザ情報取得部１３１、回数取得部１３２、メッセージ送受信部１３３（メッセージ取得部）、キーワード解析部１３４、関係判定部１３５、スケジュール調整部１３６、施設検索部１３７、評価取得部１３８、及び施設傾向判定部１３９等として機能する。

ユーザ情報取得部１３１は、ユーザ端末２０からユーザ属性を含むユーザ情報を取得し、ユーザＤＢ１２Ａに登録する。つまり、ユーザ情報取得部１３１は、第一ユーザ端末２０Ａから第一ユーザのユーザ属性（第一ユーザ属性）を含むユーザ情報（第一ユーザ情報）を取得し、第二ユーザ端末２０Ｂから第二ユーザのユーザ属性（第二ユーザ属性）を含むユーザ情報（第二ユーザ情報）を取得する。

回数取得部１３２は、ユーザ同士（第一ユーザ及び第二ユーザ）が出会った回数（デート回数）を取得する。回数取得部１３２による回数取得方法としては、例えば、第一ユーザが操作する第一ユーザ端末２０Ａから第二ユーザと会った旨の情報、または、第二ユーザが操作する第二ユーザ端末２０Ｂから第一ユーザと会った旨の情報が送信された際に、出会った回数をカウントアップする。本実施形態では、サーバ装置１０は、ユーザ端末２０に対して施設評価依頼情報を送信し、ユーザ端末２０から施設評価情報（施設評価結果）が返信されることで、回数取得部１３２は、デート回数をカウントアップさせる。
あるいは、回数取得部１３２は、第一ユーザ端末２０Ａで測位される第一ユーザの位置の履歴と、第二ユーザ端末２０Ｂで測位される第二ユーザの位置の履歴とを受信してもよい。この場合、回数取得部１３２は、同一の時刻帯で、所定の施設内で第一ユーザと第二ユーザの位置情報が一致した場合に、出会った回数をカウントアップする。この場合、ユーザの施設評価情報等の送信操作を不要にできる。

メッセージ送受信部１３３は、ユーザ端末２０から、他のユーザ（送信先ユーザ）を宛先とするメッセージを受信した際に、そのメッセージを、記憶部１２の送信先ユーザのメールボックスに記憶する。
また、メッセージ送受信部１３３は、ユーザ端末２０から、メッセージを確認する旨の要求を受信した際に、メッセージボックスに記憶されたメッセージを読み出し、ユーザ端末２０に送信する。

キーワード解析部１３４は、メッセージボックスに記憶されるメッセージに含まれるキーワードを解析する。

関係判定部１３５は、ユーザと他のユーザとの関係性を判定する。関係判定部１３５による関係性の判定では、例えば、回数取得部１３２によってカウントされるデート回数、メッセージ送受信部１３３によるメッセージの送受信回数や頻度、キーワード解析部１３４により解析されるメッセージ内のキーワード等を用いて、ユーザ同士の関係性の１つを示す親密度を算出する。
また、関係判定部１３５は、各ユーザのユーザタイプを判定する。ユーザタイプとは、ユーザの性格を示す情報であり、例えば関係管理情報やユーザ情報等に基づいて判定される。ユーザタイプには、例えば、恋愛や人付き合い等に対して引っ込み思案な内気タイプ、活発で相手を引っ張るリードタイプ等が挙げられる。第一ユーザのユーザタイプと、第二ユーザのユーザタイプの組み合わせは、第一ユーザ及び第二ユーザの関係性の１つとなる。

スケジュール調整部１３６は、ユーザ端末からデート提案要求が送信された際に、ユーザ同士のスケジュール情報を参照して、デートの日程を調整する。

施設検索部１３７は、ユーザ端末２０からデート提案要求が送信された際に、デートで利用する施設を検索する。この際、施設検索部１３７は、デートを行う各ユーザの属性と、ユーザ同士の関係性（親密度やユーザタイプの組み合わせ）に基づいて施設検索を実施して、検索結果をユーザ端末２０に送信する。

評価取得部１３８は、ユーザ端末２０から施設に対する評価を受信する。本実施形態では、施設検索部１３７により施設検索が実施され、ユーザ端末２０に施設検索結果（デート提案情報）が送信された後、評価取得部１３８は、ユーザ端末２０に施設の評価を依頼する施設評価依頼情報を送信する。そして、評価取得部１３８は、この施設評価依頼情報に対する返信である施設評価情報を受信すると、受信した内容に基づいて施設を評価する。
施設傾向判定部１３９は、評価取得部１３８が取得した各ユーザからの評価結果に基づいて、ユーザが施設を利用する上での施設の嗜好傾向（利用施設傾向）を判定する。
なお、各機能構成の詳細な説明は後述する。

［ユーザ端末２０の構成］
ユーザ端末２０は、上述のように、ユーザが保有するコンピュータであり、例えばスマートフォンやタブレット端末、パーソナルコンピュータ等により構成される。すなわち、ユーザ端末２０は、図１に示すように、表示部２１、入力操作部２２、端末通信部２３、端末記憶部２４、及び端末制御部２５等を含んで構成される。
表示部２１は、例えば液晶ディスプレイ等により構成され、端末制御部２５の制御の下、所定の画像を表示させる。
入力操作部２２は、例えば表示部２１と一体に設けられたタッチパネルにより構成されてもよく、キーボードやマウス等の入力装置により構成されていてもよい。この入力操作部２２は、ユーザにより操作されることで、操作に応じた操作信号を端末制御部２５に出力する。
端末通信部２３は、サーバ装置１０やネットワーク上の所定の装置と通信する。

端末記憶部２４は、例えばメモリやハードディスク等のデータ記録装置により構成されている。端末記憶部２４には、ユーザ端末２０を制御するための各種プログラム等が記憶される。

端末制御部２５は、ＣＰＵ（Central Processing Unit）等の演算回路、ＲＡＭ（Random Access Memory）等の記憶回路により構成され、ユーザ端末２０の各部を制御する。端末制御部２５は、端末記憶部２４等に記憶されているプログラム（ソフトウェア）をＲＡＭに展開し、ＲＡＭに展開されたプログラムとの協働で、各種処理を実行する。具体的には、端末制御部２５は、上記プログラムを読み取り実行することで、サーバ装置１０から受信した各種情報を表示部２１に表示させたり、入力操作部２２から入力された入力情報をサーバ装置１０に送信したりする。

［情報処理方法］
次に、上述したような情報処理システム１における情報処理方法について、説明する。
［登録処理及びメッセージ送受信処理］
まず、情報処理システム１におけるユーザ情報の登録、及びメッセージの送受信処理について説明する。
図３は、本実施形態の情報処理方法に係る、ユーザ情報の登録処理、及びメッセージの送受信処理を示すフローチャートである。
この情報処理システム１を利用するために、ユーザ（第一ユーザや第二ユーザ）は、自分のプロフィールや個人情報等を含むユーザ情報を、ユーザ端末２０からサーバ装置１０に送信する。これにより、ユーザ情報取得部１３１は、受信したユーザ情報をユーザＤＢ１２Ａに登録する（ステップＳ１１）。ユーザ情報は、ユーザが任意のタイミングで自由に更新することが可能な情報である。例えば、第一ユーザは、ユーザＩＤと、設定されたパスワードとを用いて、第一ユーザ端末２０Ａからサーバ装置１０にアクセスし、ユーザＤＢ１２Ａに記録された自分のユーザ情報に編集して更新することができる。

ユーザ情報が登録されると、ユーザ情報のうち、ユーザが公開を許可した範囲が、情報処理システム１を利用するユーザに閲覧可能となる。また、サーバ装置１０が提供する掲示板への書き込みや読み込みを実行する権限、ユーザ間でメッセージの送受信を実行する権限等、各種サービスを利用する権限が各ユーザに与えられ、サービスの利用が可能となる（ステップＳ１２）。
例えば、ユーザ間でのメッセージの送受信機能に関し、サーバ装置１０は、記憶部１２に、登録ユーザのメッセージボックスを形成し、ユーザに対して、情報処理システム１を利用する他のユーザと間でメッセージの送受信を許可する。

そして、メッセージ送受信部１３３は、ユーザからメッセージを受信したか否かを判断する（ステップＳ１３）。
第一ユーザが、第一ユーザ端末２０Ａを操作して、情報処理システム１を利用する第二ユーザに対するメッセージを生成して送信する操作を実施すると、第一ユーザ端末２０Ａからサーバ装置１０に、第二ユーザを宛先とするメッセージが送信される。そして、メッセージ送受信部１３３は、このようなメッセージを受信すると、ステップＳ１３において、Ｙｅｓと判断し、受信したメッセージを第二ユーザのメッセージボックスに記録する（ステップＳ１４）。

また、メッセージ送受信部１３３は、メッセージを受信した旨を、第二ユーザの第二ユーザ端末２０Ｂに送信する（ステップＳ１５）。第二ユーザ端末２０Ｂにおいて、第二ユーザの操作によりメッセージを確認する旨の操作が実施されると、メッセージ送受信部１３３は、第二ユーザ端末２０Ｂに第二ユーザを宛先としたメッセージを送信する。これにより、第二ユーザ端末２０Ｂにおいて、各メッセージが表示されることが可能となり、ユーザ間でのメッセージの送受信が完了する。

また、メッセージ送受信部１３３により、メッセージの送受信処理が実施されると、キーワード解析部１３４は、メッセージに含まれるキーワードを解析する（ステップＳ１６）。つまり、キーワード解析部１３４は、第一ユーザ及び第二ユーザとの間で送受信されたメッセージに対して、形態素解析処理等を実施して、メッセージに含まれる語句を解析する。例えば、「デート」等の２者間のイベントを示すキーワード、場所を示すキーワード、日付を示すキーワード、趣味やイベント等を示すキーワードを、記憶部１２に記憶された辞書データを用いて抽出する。
キーワード解析部１３４は、抽出したキーワードを、第一ユーザ及び第二ユーザの関係管理情報の近傍話題情報として記録する（ステップＳ１７）。以降、第一ユーザと第二ユーザとの間で、このようなメッセージの送受信が実施される毎に、ステップＳ１３からステップＳ１７の処理が繰り返し実施され、近傍話題情報が蓄積される。

［デート提案処理］
次に、本実施形態の情報処理方法に係るデート提案処理について説明する。図４は、デート提案処理（施設検索処理）のフローチャートである。
本実施形態では、第一ユーザが、例えばメッセージの送受信等によって親密になった第二ユーザと一緒に出掛けることになった場合に、サーバ装置１０が提供するデート提案サービスを利用することができる。このデート提案サービスでは、サーバ装置１０は、第一ユーザ及び第二ユーザのスケジュール情報等からデートの候補日時と、デートで利用する施設を含むデート提案情報を送信する。

これには、第一ユーザが第一ユーザ端末２０Ａを操作し、第一ユーザ端末２０Ａからサーバ装置１０に、デート提案要求を送信する。デート提案要求は、デート相手となる第二ユーザが含まれる。サーバ装置１０では、第一ユーザ端末２０Ａからのデート提案要求が受信されると（ステップＳ２１）、関係判定部１３５により、親密度算出処理が実施される（ステップＳ２２）。

ステップＳ２２では、関係判定部１３５は、上述したように、デート回数や、ユーザ間で送受信されたメッセージの回数やメッセージ送受信頻度、メッセージに含まれるキーワード、メッセージの文体等の複数の要素に基づいて親密度を算出する。
例えば、デート回数（Ｘｄ）、メッセージ送受信回数（Ｘｍ）、メッセージ送受信頻度（Ｔｍ）として、親密度判定値Ａを、Ａ＝α×Ｘｄ＋β×Ｘｍ×Ｔｍ／Ｔｒ＋γにより算出する。α、βは、それぞれデート回数、メッセージ送受信が親密度に与える重み係数である。Ｔｒは、メッセージの送受信頻度の基準値であり、例えば、予め設定された値であってもよく、第一ユーザ及び第二ユーザが知り合ってからの時間等に応じて変化する値であってもよい。
γは、例えばメッセージに含まれるキーワードや、メッセージの文体等から導かれる加点要素である。例えば、メッセージに含まれるキーワードの種類に対して、それぞれレベルを設定し、レベルに応じた加点要素γを加える。具体例を挙げると、挨拶や一般的な社交辞令等のキーワードのみの文章である場合を第１レベルの加点（最低点）とする。ユーザ属性等に基づいたキーワードを第１レベルよりも大きい第２レベルの加点とする。デートの場所や日時等に関するキーワードや、個人を特定可能情報がキーワードとして含まれている場合、さらに点数が大きい第３レベルの加点とする。
また、メッセージの文体の履歴等に基づいて、所定の加点要素を加えてもよい。例えば、メッセージの文体が敬語調から、相手と対等な言葉調（いわゆる、タメ語調）に変化した場合に、所定の加点要素を加算してもよい。
そして、関係判定部１３５は、算出された親密度判定値Ａに基づいて親密度を判定する。例えば、親密度判定値Ａの値を複数のランクに区分しておき、算出された親密度判定値Ａが属する区分のランクを、親密度として判定する。なお、ここでは、親密度判定値Ａから親密度に変換する例を示すが、親密度判定値Ａを親密度として以降の処理が行われてもよい。

また、関係判定部１３５は、第一ユーザ及び第二ユーザのユーザタイプを判定する（ステップＳ２３）。
このステップＳ２３では、関係判定部１３５は、例えば、ユーザの関係管理情報等に基づいて、ユーザタイプを判定する。
例えば、第一ユーザのユーザタイプを判定する場合、第一ユーザと関係性がある他のユーザ（第二ユーザ以外のユーザを含む）との関係管理情報を用いる。この際、メッセージ送受信回数やメッセージ頻度に対して、デート回数が所定数以下である場合、当該ユーザを、慎重タイプ、内気タイプとして判定してもよい。または、利用施設傾向として記録される施設として、自分のユーザ属性とは異なるタイプの施設が所定数以上記録されている場合、関係判定部１３５は、当該ユーザのユーザタイプを、従順タイプとして判定してもよい。逆に、利用施設傾向として、自分のユーザ属性に合致した施設属性の施設が多い場合、相手をリードする傾向にあるリードタイプとして判定してもよい。
また、関係管理情報に記録される情報が少ない場合等では、関係判定部１３５は、ユーザ属性として記録されている、ユーザ自身の性格や趣味等からユーザタイプを予測してもよい。

次に、スケジュール調整部１３６は、第一ユーザのユーザ情報に記録されたスケジュール情報、第二ユーザのユーザ情報に記録されたスケジュール情報を読み出して、スケジュール調整処理を実施する（ステップＳ２４）。
ステップＳ２４では、スケジュール調整部１３６は、第一ユーザ及び第二ユーザの双方のスケジュールにおいて予定が入っていない空き日時を候補日時として検出する。この際、スケジュール調整部１３６は、ステップＳ２２により判定された親密度やステップＳ２３により判定されたユーザタイプに基づいて、候補日時を決定してもよい。
例えば、親密度が第１ランクや第２ランク等の低ランクである場合、スケジュール調整部１３６は、ランチタイム（例えば、１１時から１４時までの間）やカフェタイム（例えば、１４時から１６時までの間）を候補日時とする。また、スケジュール調整部１３６は、親密度がより高いランクである第３ランク以上である場合、ディナータイム（例えば１７時以降）を候補日時として含ませる。

次に、施設検索部１３７は、デートで利用する施設を検索する。
具体的には、施設検索部１３７は、まず、基準検索クエリを設定する（ステップＳ２５）。基準検索クエリの設定では、施設検索部１３７は、例えば、第一ユーザ及び第二ユーザの関係管理情報に記録される近傍話題情報を第一優先（最優先）とし、利用施設傾向を第二優先とし、第一ユーザ及び第二ユーザのユーザ属性で共通する事項を第三優先とし、第一ユーザ及び第二ユーザのいずれか一方のユーザ属性（共通していない事項）を第四優先（最も低い優先度）とする。

つまり、第一ユーザと第二ユーザとの間のメッセージで、直近の話題に対応したキーワードを、最も高い優先度の基準検索クエリに設定する。
また、利用施設傾向は、第一ユーザと第二ユーザとの過去のデートで利用した施設の履歴に基づいた情報であり、第一ユーザと第二ユーザとが好む施設の傾向や、第一ユーザ及び第二ユーザのうちの重視すべきユーザ属性の傾向等が記録される。例えば、過去に第一ユーザのユーザ属性に基づいた施設でデートを実施した際に、第二ユーザから当該施設の評価が所定値以下であった場合、施設傾向判定部１３９によって、利用施設傾向として、第二ユーザのユーザ属性をより重視させるように利用施設傾向が更新される。つまり、複数回のデートが実施されることで、第一ユーザ及び第二ユーザがより楽しめるように利用施設傾向が更新される。よって、利用施設傾向を第二優先の基準検索クエリに設定することで、第一ユーザ及び第二ユーザの好みに合致した施設を検索することが可能となる。

また、第一ユーザと第二ユーザとが、知り合ってから間もない場合等では、近傍話題情報や、利用施設傾向が記録されていない場合がある。この場合、第一ユーザ及び第二ユーザのユーザ属性のうち、共通する事項を基準検索クエリとする。例えば、第一ユーザ及び第二ユーザで共通する趣味や好物等を検索クエリとする。
一方、これらの共通するユーザ属性がない場合では、第一ユーザ及び第二ユーザのいずれか一方のユーザ属性として記録される事項を検索クエリとする。

なお、ステップＳ２４において、設定された候補日時において、第一ユーザ及び第二ユーザの位置が予め予測できる場合は、第一ユーザ及び第二ユーザの位置から所定距離範囲内、または、所定移動時間内となる施設を、基準検索クエリとして加えてもよい。

この後、施設検索部１３７は、設定した基準検索クエリを用いて、施設ＤＢ１２Ｂから施設を検索する（ステップＳ２６）。
なお、このステップＳ２６での検索処理では、施設検索部１３７は、一般的な従来のスコア算出に基づいた検索処理を用いる。この際、基準検索クエリにおいて設定された優先度に応じて、スコアを算出する際の重み値を変化させる。例えば、第一優先に対応した施設は最も高い重み値が付与されてスコアが算出される。

次に、施設検索部１３７は、第一ユーザと第二ユーザとの関係性に基づいて、デート施設として紹介する施設を絞り込む（ステップＳ２７）。
具体的には、施設検索部１３７は、記憶部１２に記憶されているデート施設対応情報から、ステップＳ２２からステップＳ２３で得られた親密度、及びユーザタイプの組み合わせに対応する施設属性（ステータス属性）を読み出し、当該ステータス属性を含む施設を絞り込む（検索する）。
なお、この施設の絞り込み処理は、ステップＳ２６により検索された施設から、親密度やユーザタイプ等に対応した施設をさらに抽出する処理であってもよく、ステップＳ２６により検索された施設を、親密度やユーザタイプ等に対応した施設が先頭に表示されるように並び変えるソート処理であってもよい。

この後、施設検索部１３７は、ステップＳ２７により絞り込まれた施設の一覧（施設検索結果）と、デートの候補日時とを含むデート提案情報をユーザ端末２０に送信する（ステップＳ２８）。なお、施設検索部１３７は、デート提案要求の送信元である第一ユーザ端末２０Ａのみにデート提案情報を送信してもよく、第一ユーザ端末２０Ａ及び第二ユーザ端末２０Ｂの双方にデート提案情報を送信してもよい。また、第一ユーザ端末２０Ａに施設検索結果及び候補日時を含むデート提案情報を送信し、第二ユーザ端末２０Ｂに候補日時のみを送信してもよい。また、第一ユーザの要求により、施設検索結果及び候補日時の送信先を変更できるようにしてもよい。
これにより、施設検索結果及び候補日時が送信されたユーザ端末２０において、施設検索結果及び候補日時が表示され、第一ユーザ及び第二ユーザは、容易に、デートの日程と、訪れる施設とを決定することが可能となる。

ここで、本実施形態において、ユーザに送信されるデート提案情報の一例を、具体例を挙げて説明する。図５は、ステップＳ２６により検索された施設検索結果と、親密度が低ランクであるユーザに対するデート提案例と、親密度が高ランクであるユーザに対するデート提案例とを示す図である。
図５の例では、第一ユーザ及び第二ユーザのユーザ属性等に基づいて、ステップＳ２６の施設検索処理で、図５（Ａ）に示すような１０個の施設が検索される。図５（Ａ）に示される検索結果例は、従来の施設検索処理により得られる検索結果と同様である。
これに対して本実施形態において、例えば、第一ユーザ及び第二ユーザの親密度が低ランクであり、かつ、第一ユーザ及び第二ユーザがともに内気タイプである場合、ランチタイムやカフェタイムが候補日時として提案され、図５（Ｂ）に示すように、ランチやカフェに利用可能な飲食店等を候補施設としたデート提案情報が送信される。
一方、第一ユーザ及び第二ユーザの関係性において、親密度が高ランクに変化すると、ディナータイムやミッドナイトタイムが候補日時となり、図５（Ｃ）に示すように、個室居酒屋やバー等が候補施設となるデート提案情報が送信される。

［フィードバック処理］
次に、フィードバック処理について説明する。図６は、フィードバック処理のフローチャートである。
本実施形態では、第一ユーザ及び第二ユーザが実際にデートを行った後、デート先の施設の評価をサーバ装置１０に送信することで、施設検索処理における検索精度を高めることが可能となる。
具体的には、ステップＳ２８によって、施設検索結果と候補日時がユーザ端末２０に送信された後、所定時間経過後に、サーバ装置１０は、第一ユーザ端末２０Ａ及び第二ユーザ端末２０Ｂに、施設評価依頼情報を送信する。図７は、施設評価依頼情報の一例である。なお、本実施形態では、サーバ装置１０からユーザ端末２０へ、施設評価依頼情報が送信される例を示すが、施設評価フォームのアドレスを示すＵＲＬをユーザ端末２０に送信し、ユーザが施設評価フォームに対して入力操作を行うことで施設の評価を得る態様としてもよい。

施設評価依頼情報には、図７に示すように、ユーザが訪れた施設名欄３１０、訪問日時欄３２０、メンバー欄３３０、及び施設評価項目３４０等が含まれる。
施設名欄３１０は、例えばプルダウン形式等により複数の施設名からユーザが訪れた施設を選択する入力欄である。プルダウン形式等により表示される施設としては、例えば、デート提案情報として送信された施設を表示させる。
なお、ここでは、施設名欄３１０に、デート提案情報で提案された施設からいずれかを選択する例を示すが、ユーザが訪れた施設を任意に入力することが可能な態様としてもよい。この場合、ユーザが、デート提案情報として提案された施設とは異なる施設を訪れた場合でも、その施設に対する評価を得ることができる。
訪問日時欄３２０は、施設を訪れた日時の入力欄である。

メンバー欄３３０は、施設を訪れた第一ユーザ以外のメンバーを入力する欄である。デート提案情報に基づいて施設を訪れた場合、通常、デート提案において指定された第二ユーザ（または第二ユーザのユーザＩＤ）が記録される。なお、メンバー欄３３０に、第二ユーザ以外のユーザが入力されてもよい。この場合、当該メンバーが、情報処理システム１を利用するユーザであれば、当該ユーザを第二ユーザ（第一ユーザのデート相手）として、以降の処理が実施される。

施設評価項目３４０は、施設を評価する複数の項目により構成されており、例えば、各項目に対して、５段階評価の評価点を入力する欄である。
なお、ここでは、各項目を評価点で入力する例を示すが、その他テキスト文を入力する入力欄等が設けられていてもよい。
施設評価項目３４０としては、例えばサービス項目、及びステータス項目等が含まれる。
サービス項目は、例えば、施設が提供する商品やサービスの内容、品質、料金等に関する評価である。例えば、飲食店であれば、提供される飲食物の味、見た目、価格、メニュー数等が挙げられ、スポーツジムであれば、運動器具等の充実度、価格等が挙げられる。
ステータス項目は、例えば、施設の環境に関する項目である。例えば、施設の場所に関して、施設からの風景（夜景等）の評価、施設内の明るさや静寂性、施設を利用する客層等が挙げられる。

ユーザ端末２０において、施設評価情報に対する評価結果が入力されると、図６に示すように、評価取得部１３８は、ユーザ端末２０から施設評価結果が入力された施設評価情報を取得（受信）する（ステップＳ３１）。また、評価取得部１３８は、取得した施設評価情報に基づいて、関係管理情報を更新する（ステップＳ３２）。
具体的には、評価取得部１３８は、取得した施設評価結果に基づいて、第一ユーザ及び第二ユーザに関する関係管理情報のデート回数を１増加させる。また、利用施設履歴に、施設評価結果に記録されている施設と、利用日時を記録し、さらに、利用施設に対する評価を記録する。

この後、施設傾向判定部１３９は、第一ユーザ及び第二ユーザの間での施設に対する嗜好傾向（利用施設傾向）を判定し、関係管理情報の利用施設傾向を更新する（ステップＳ３３）。
このステップＳ３３では、施設傾向判定部１３９は、例えば、施設が有する施設属性、第一ユーザのユーザ属性、第一ユーザによる施設評価結果、第二ユーザのユーザ属性、及び第二ユーザによる施設評価結果に基づいて利用施設傾向を判定する。
例えば、第一ユーザ及び第二ユーザのユーザ属性と、対象となる施設の施設属性とを比較し、当該施設が、第一ユーザのユーザ属性に近い施設属性か、第二ユーザのユーザ属性に近い施設属性かを判定する。施設属性とユーザ属性とが近いか否かは、施設属性とユーザ属性とで共通する属性の数により判定することができる。第一ユーザ属性として、好物「オムレツ」「コーヒー」が記録され、第二ユーザ属性として、好物「オムレツ」「紅茶」が記録され、施設属性として「オムレツ」「コーヒー」が記録される場合、施設属性が第一ユーザ属性に近い属性であると判定できる。
また、施設に対する、第一ユーザ及び第二ユーザの施設評価結果に基づいて、第一ユーザ及び第二ユーザが好む利用施設傾向、つまり、第一ユーザ及び第二ユーザの関係をより良好とするために最適となる施設属性を判定する。
例えば、デート先の施設の施設属性が、第二ユーザよりも、第一ユーザのユーザ属性に近い属性を有し、第二ユーザの施設評価結果において不評となる項目がある場合、当該不評とされた項目に対応する施設属性を向上させる旨の利用施設傾向が記録される。また、第二ユーザの施設評価結果において、所定数以上の項目において不評となっていた場合、施設検索を実施する際の施設属性として、第二ユーザのユーザ属性により近い属性とする旨の利用施設傾向が記録される。言い換えると、第一ユーザと第二ユーザとにおいて、どちらのユーザ属性（趣味等）を重視するかのパワーバランスが、利用施設傾向として記録される。
これにより、次回、ステップＳ２６の施設検索処理を実施する際に、第一ユーザまたは第二ユーザが、不評とした点を改善した施設検索を実施することが可能となり、第一ユーザと第二ユーザとがより親密な関係となるような、雰囲気作りを支援することが可能となる。

［本実施形態の作用効果］
本実施形態のサーバ装置１０の制御部１３は、ユーザ情報取得部１３１、関係判定部１３５、施設検索部１３７として機能する。ユーザ情報取得部１３１は、ユーザ（第一ユーザ及び第二ユーザ）のユーザ属性を含むユーザ情報を取得し、関係判定部１３５は、第一ユーザと第二ユーザとの関係性を判定する。そして、施設検索部１３７は、第一ユーザ属性及び第二ユーザ属性の少なくとも一方に対応し、かつ、第一ユーザ及び第二ユーザの関係性に対応する施設属性を含む施設を検索する。これにより、ユーザが求める最適な施設を容易に知ることができる。

つまり、従来の施設検索では、基準検索クエリに対応するスコア順で検索結果を出力されるのみであるため、基準検索クエリを変更しない限り同じ検索結果が表示される。例えば、「パスタ」との検索キーワードに対して、スコア順で表示されることで、毎回、Ｌ１店、Ｌ２店、Ｌ３店との順で施設が紹介される。この場合、第一ユーザが第二ユーザとデートをしたい場合、各店舗の紹介ページ等を確認して、デートに相応しい店舗であるか否かを判断する必要がある。あるいは、ユーザがデートとして利用したい施設の特徴をさらに検索クエリに追加する必要がある。
これに対して、本実施形態では、ステップＳ２７の処理が実施されることで、ユーザ同士の関係性によって、検索結果が変化する。例えば、「パスタ」との検索キーワードに対して、初回の施設紹介時には、開放的な客室を備えるＭ１店、Ｍ２店、Ｍ３店が紹介される。そして、ユーザ同士がデートを複数回繰り返す等によって、親密度が高くなると、「パスタ」との検索キーワードに対して、２人きりになれる個室を備えるＮ１店、Ｎ２店、Ｎ３店が紹介される。
したがって、ユーザは、施設検索に係る手間を省略でき、容易に、ユーザが求める最適な施設の検索結果を得ることができる。

本実施形態では、回数取得部１３２が、第一ユーザと第二ユーザとが実際に合った回数（デート回数）をカウントし、関係判定部１３５は、カウントされたデート回数に基づいて、第一ユーザ及び第二ユーザの関係性を判定する。
これにより、第一ユーザと第二ユーザとが実際に会った回数に基づいて、適正に第一ユーザ及び第二ユーザの関係性（親密度）を判定することができ、関係性に応じた適正な施設を提案することができる。例えば、第一ユーザ及び第二ユーザが初めてデートをする場合、お互いが緊張せずに安心できる施設等が選択されることになる。また、第一ユーザ及び第二ユーザが複数回デートして、親密な関係となっている場合では、お互いがより身近に感じられる空間を提供可能な施設が選択されることになる。すなわち、サーバ装置１０は、第一ユーザ及び第二ユーザ間の関係をより良好にするための施設を提案することができる。

本実施形態では、メッセージ送受信部１３３が、第一ユーザ及び第二ユーザの間でメッセージの送受信を行う。そして、関係判定部１３５は、メッセージに基づいて第一ユーザ及び第二ユーザの間の関係性を判定する。
例えば、第一ユーザ及び第二ユーザの仲が良く、親密である場合、メッセージの送受信回数も多く、送受信頻度も高くなる。また、メッセージの内容としても、単なる挨拶や社交辞令ではなく、お互いの趣味や興味に対する話題、デートの約束やデートで訪れたい場所等がキーワードとして現れることが多い。したがって、本実施形態のように、メッセージの送受信回数や頻度、メッセージ内容に基づいて、２人の関係性を精度よく判定することができる。

本実施形態では、第一ユーザと第二ユーザの関係性として、第一ユーザ及び第二ユーザの親密さを示す親密度を含む。つまり、関係判定部１３５は、上述したようなデート回数や、メッセージの送受信回数や頻度、メッセージの内容に基づいて、親密度を算出する。このように、複数の要素に基づいた親密度を算出することで、２人の親密さを数値として表すことができる。この場合、親密度と、施設属性と対応付けたデート施設対応情報に基づいて、容易に施設を絞り込むことができる。

本実施形態では、関係判定部１３５は、さらに、第一ユーザのユーザタイプと、第二ユーザのユーザタイプとを判定する。つまり、本実施形態の関係性は、親密度に加え、ユーザタイプの組み合わせが含まれ、施設検索部１３７は、親密度とユーザタイプの組み合わせとに基づいて施設を絞り込む。
例えば、第一ユーザと第二ユーザとの親密度が低く、両者とも内気タイプである場合と、同じく親密度が低いが、両者のいずれかが異性に対して積極的なタイプである場合とでは、ユーザタイプの組み合わせによって、異なる施設が検索されることになる。つまり、本実施形態では、第一ユーザと第二ユーザの親密度に加え、第一ユーザ及び第二ユーザのそれぞれの性格を考慮した施設を絞り込むことができ、２人の関係性をより良好にするための好適な施設を提案することが可能となる。

ここで、関係判定部１３５は、第一ユーザ及び第二ユーザの利用施設履歴と、各ユーザのユーザ属性とに基づいて、それぞれのユーザタイプを判定する。
一般に、ユーザが過去に利用した複数の施設が、自身のユーザ属性よりもデート相手のユーザ属性に近い施設属性を有している場合、そのユーザの性格（ユーザタイプ）は、比較的おとなしい内気タイプであるか、相手に合わせる従順タイプ、または相手に対する優しさを重視する気配りタイプ等である可能性が高い。なお、本実施形態では、ユーザからの施設評価情報に基づいて、利用施設傾向も更新される。したがって、内気タイプであっても、例えば自分の趣味等に強い拘りがある場合には、サーバ装置１０から紹介される施設も改善されることになる。すなわち、本実施形態のように、関係判定部１３５は、施設評価情報によって更新される利用施設履歴、及びユーザ属性に基づいて、そのユーザがどのような施設を好むかを精度よく判定することができる。

本実施形態では、評価取得部１３８が、施設に対する第一ユーザ及び第二ユーザの評価を取得する。そして、施設傾向判定部１３９は、第一ユーザ属性、第二ユーザ属性、施設に対する第一ユーザ及び第二ユーザのそれぞれの評価に基づいて、第一ユーザ及び第二ユーザの施設に対する嗜好傾向（利用施設傾向）を判定する。そして、施設検索部１３７は、第一ユーザ及び第二ユーザの関係性、第一ユーザ属性、第二ユーザ属性、及び利用施設傾向に基づいて、施設を検索する。
一般に、施設を一人で利用する場合では、そのユーザのユーザ属性に基づいた施設検索を実施する。この場合、ユーザが求める施設を検索することができる。一方、複数人で利用する施設を検索する場合、各々のユーザ属性のうちの共通するユーザ属性に基づいて施設を検索してもよいが、この場合、一部の限られた施設しか検索できない場合がある。また、パートナーとデートを楽しむ場合、相手の好みに合わせたいと思うユーザや、相手に自分の好みを教えたいと思うユーザ等、様々なユーザが存在し、かつ、デートの相手のパートナーによって付き合い方が変化する場合もある。よって、第一ユーザ及び第二ユーザの共通属性に基づいた施設検索では、ユーザの満足度が不十分となる場合も多々ある。
これに対して、本実施形態では、第一ユーザと第二ユーザが実際にデートを行った施設に対する、第一ユーザ及び第二ユーザの当該施設に対する評価に基づいた利用施設傾向を用いて施設検索を実施する。これにより、パートナーとの付き合い方が相手によって変化する場合でも、ユーザの嗜好に合わせた施設検索を実施することが可能となる。

本実施形態では、ユーザ情報取得部１３１は、ユーザのスケジュール情報を取得し、スケジュール調整部１３６は、取得したスケジュール情報から、デート日程のスケジュール調整を実施する。この際、スケジュール調整部１３６は、第一ユーザ及び第二ユーザの関係性に基づいて、デートの候補日時を調整する。
例えば、第一ユーザ及び第二ユーザが知り合ったばかりで、親密度が低い場合では、ランチタイムやカフェタイムをデートの候補日時として抽出する。また、親密度が高い場合では、ディナータイム以降を候補日時として含ませる。これにより、第一ユーザ及び第二ユーザが、お互いを警戒することなく、気軽に会いやすい日時を設定することができ、２人の関係性のさらなる進展を支援することができる。

［変形例］
なお、本発明は、上述した実施形態に限定されるものではなく、本発明の目的を達成できる範囲で、以下に示される変形をも含むものである。
［変形例１］
上記実施形態では、サーバ装置１０では、男女関係や恋愛関係にある第一ユーザ及び第二ユーザに対してデート提案情報を提供する例を示しているが、これに限定されない。例えば、ユーザ同士の関係性としては、友人関係、親子関係、同僚関係、先輩後輩関係、上司部下関係等、様々な人間性に対応した施設検索を実施する情報処理装置に適用することができる。
例えば、サーバ装置１０は、友人関係に基づいて、友人同士で遊びに行く日程や施設を提案してもよい。この場合、回数取得部１３２は、例えば一緒に行動した（遊んだ）回数や、出会った回数等をカウントすればよい。また、同僚関係や、上司と部下の関係性等では、回数取得部１３２は、同じプロジェクトに参加した回数や、飲み会等に参加した回数等をカウントすればよい。
また、関係管理情報として、第一ユーザと第二ユーザとの関係性として、友人関係であるか、恋愛関係であるか、職場の同僚であるか等を示す、間柄情報をさらに記録してもよい。この場合、間柄情報に基づいた施設を検索することができる。

［変形例２］
上記実施形態では、ＳＮＳ等の情報処理システム１に登録されている第一ユーザ及び第二ユーザを対象として、デート提案処理を実施したが、第一ユーザのみが、情報処理システム１を利用するユーザとしてユーザ登録されていてもよい。この場合、第一ユーザが、第一ユーザ端末２０Ａを操作して、第一ユーザと第二ユーザとの関係性（親密度やお互いのユーザタイプ）等をサーバ装置１０に入力すればよい。

［変形例３］
上記実施形態では、各ユーザのそれぞれに対応した関係管理情報が記憶部１２に記憶されている。したがって、第一ユーザの関係管理情報に、第二ユーザとの関係が記録されている場合、第二ユーザの関係管理情報に、第一ユーザとの関係が同様に記録される。
ここで、第一ユーザの関係管理情報に記録される第二ユーザに対する親密度と、第二ユーザの関係管理情報に記録される第一ユーザに対する親密度とが異なる親密度であってもよい。
例えば、第一ユーザが第二ユーザに片思いをしている場合等では、第一ユーザの第二ユーザに対するメッセージ回数や頻度に対して、第二ユーザの第一ユーザに対するメッセージ回数や頻度が小さくなる。この場合、関係判定部１３５は、メッセージの回数や頻度に基づいて、第二ユーザの第一ユーザに対する親密度を、第一ユーザの第二ユーザに対する親密度よりも低く判定してもよい。

また、この場合、施設検索部１３７は、第二ユーザの親密度に基づいて、第二ユーザのユーザ属性を重視した施設検索処理を実施することが好ましい。つまり、第一ユーザの親密度に基づいた施設検索を実施した場合や、第一ユーザのユーザ属性を重視した施設検索を実施した場合、第二ユーザが意図しない施設に戸惑う可能性があり、第一ユーザと第二ユーザとの関係性が進展する可能性が低くなる。これに対して、第二ユーザの親密度に基づき、第二ユーザのユーザ属性を重視した施設検索を実施する場合では、第一ユーザにとっては多少不満となるものの、第二ユーザの施設に対する評価は高まり、第二ユーザの第一ユーザに対する親密度も高まる可能性が大きくなる。

［変形例４］
上記実施形態において、スケジュール調整部１３６は、第一ユーザ及び第二ユーザのスケジュールに加え、第一ユーザ及び第二ユーザの位置に基づいて、候補日時を設定してもよい。例えば、第一ユーザ及び第二ユーザの職場が離れていて、ランチタイムやカフェタイムでの時間設定が困難である場合は、ディナータイムの候補日時に調整されてもよい。

［変形例５］
上記実施形態では、施設検索部１３７は、施設検索処理として、まず、基準検索クエリに基づいて施設を検索し、検索された施設を、第一ユーザ及び第二ユーザの関係性に基づいて絞り込んだ。これに対して、施設検索部１３７は、利用施設傾向に基づいた優先度のユーザ属性と、第一ユーザ及び第二ユーザの関係性に対応した施設のステータス属性とを検索クエリとして施設検索を実施し、その検索結果をデート提案情報としてユーザに送信してもよい。

［変形例６］
上記実施形態において、関係判定部１３５は、デート回数、メッセージの送信回数や頻度、メッセージ内に含まれるキーワード等に基づいて親密度判定値や親密度を算出する例を示したが、これらのうちのいずれか１つを用いて親密度を算出してもよい。

また、関係判定部１３５は、第一ユーザ及び第二ユーザのユーザ属性のうち、両者で共通する属性の個数によって、第一ユーザ及び第二ユーザの相性度を算出し、相性度に応じて親密度を変化させてもよい。例えば、デート回数Ｘｄや、メッセージ送受信回数Ｘｍに乗算する係数α，βとして、共通事項が多い第一ユーザ及び第二ユーザでは、共通事項が少ない第一ユーザ及び第二ユーザよりも大きい係数α，βを用いてもよい。

この場合、ユーザ同士の相性に応じた最適な親密度の算出が可能となり、ユーザに対してより好適なデート提案情報を提供できる。つまり、第一ユーザ及び第二ユーザの相性が良い場合、少数回のデートでも第一ユーザと第二ユーザとが極めて親密となる可能性もある。このような場合に、親密度が低ランクであると判定すると、ユーザを満足させるデート提案情報を送信することができない。これに対して、上記のように、ユーザ属性に基づいた相性度に基づいた親密度を算出したり、相性度に基づいて親密度を補正したりすることで、ユーザ同士の親密度を適正に判断でき、ユーザ満足度の向上を図ることができる。

［変形例７］
さらに、関係判定部１３５は、メッセージに含まれるキーワードの継続性を判定してもよい。例えば、第一ユーザから、所定のキーワード“Ｋ”を含むメッセージが送信された場合、関係判定部１３５は、第１の加点要素γ１を親密度判定値Ａに加算する。この後、第二ユーザからキーワード“Ｋ”、またはキーワード“Ｋ”と関連性のあるキーワード“Ｋ２”を含むメッセージが返信された場合に、関係判定部１３５は、第１の加点要素γ１より大きい第２の加点要素γ２を親密度判定値Ａに加算する。以降、キーワード“Ｋ”、あるいは、キーワード“Ｋ”と関連性のあるキーワード“Ｋ２”がメッセージに含まれる度に加点要素γを増大させる。なお、キーワード“Ｋ”と、キーワード“Ｋ”に関連するキーワード“Ｋ２”とは、例えば辞書ファイル等に記録しておけばよい。

上記のように、複数回のメッセージの送受信において、特定のキーワード“Ｋ”が含まれる場合、第一ユーザ及び第二ユーザが、共通の話題“Ｋ”で話が盛り上がり、両者の親密度が向上している可能性が高い。このような場合に、親密度を一定数向上させるようにすることで、デート回数やメッセージ回数のカウント数のみで親密度を算出する場合に比べて、精度の高い親密度の算出が可能となる。
また、施設検索時においても、当該キーワード“Ｋ”に基づいた施設検索を実施することで、第一ユーザと第二ユーザとの共通の話題に関する施設検索が実施でき、第一ユーザ及び第二ユーザの関係性の進展に大きく貢献することができる。

［変形例８］
上記実施形態では、サーバ装置１０は、第一ユーザ端末２０Ａからデート相手である第二ユーザを指定したデート提案要求を受信することで、デート提案情報を第一ユーザ端末２０Ａに送信した。
これに対して、サーバ装置１０は、第一ユーザ端末２０Ａや第二ユーザ端末２０Ｂに所定のタイミングで、レコメンド情報としてデート提案情報を送信してもよい。このタイミングとしては、第一ユーザと第二ユーザとが初めてメッセージを送受信した日時から所定日時経過後等を例示できる。また、第一ユーザと第二ユーザとのメッセージ送受信が所定回数となったタイミングであってもよい。
あるいは、特定のキーワード“Ｋ”、及び、キーワード“Ｋ”と関連性のあるキーワード“Ｋ２”が含まれるメッセージが所定回数送受信されたタイミングであってもよい。

また、上記実施形態では、デート提案要求として、デート相手である第二ユーザを指定することで、第一ユーザ及び第二ユーザの嗜好性にあった施設が第一ユーザ及び第二ユーザに紹介される例であるが、他の検索クエリをデート提案要求に加えてもよい。
例えば、ユーザは、デート相手を「第二ユーザ」とし、検索施設を「レストラン」等に絞る旨のデート提案要求をユーザ端末２０からサーバ装置１０に送信してもよい。この場合、ステップＳ２５において、施設検索部１３７は、基準検索クエリとして、入力された条件を第一優先として、基準検索クエリを設定することが好ましい。

［変形例９］
上記実施形態において、ステップＳ２１でデート提案要求を受信すると、関係判定部１３５は、ステップＳ２２の親密度算出処理を実施した後、ステップＳ２３でさらに、ユーザタイプを判定した。また、施設検索部１３７は、ステップＳ２５の基準検索クエリを設定した後、ステップＳ２６で基準検索クエリに基づいた検索処理を実施し、さらにステップＳ２７で、ユーザの関係性に基づいた絞り込み処理を実施した。
これに対して、ＡＩを用いた機械学習を利用して、より簡易なフローにより施設を検索してもよい。例えば、サーバ装置１０は、複数のユーザについて、ユーザ属性、メッセージの送受信回数や頻度、１通あたりのメッセージの文字数、及びユーザのインターネット上の行動履歴（例えば検索履歴や購入履歴）、デート回数等を特定可能な施設利用情報を入力用データとして蓄積している。また、サーバ装置１０は、各ユーザが他のユーザと共に施設を利用した際の施設に対する評価等を含む利用履歴情報を出力検証用データとして蓄積している。

ここで、サーバ装置１０は、第一ユーザに関する第一入力用データと、第二ユーザに関する第二入力用データとを入力とし、親密度やユーザタイプに応じた施設属性を出力としたモデルを機械学習により生成してもよい。なお、出力検証用データは、モデル検証用に用いる。
このモデルは、収集された多数のカップルのデータから最適な施設属性を抽出するためのモデルであり、第一ユーザ及び第二ユーザと類似する入力用データを有するカップルに基づいて、第一ユーザ及び第二ユーザの現在のメッセージの送信回数や頻度、デート回数に対応する関係性に対応した施設属性（ステータス属性）を出力する。よって、ステップＳ２２やステップＳ２３、ステップＳ２５の処理を省略でき、ステップＳ２６及びステップＳ２７の代わりに、モデルから出力された施設属性を用いた検索処理を実施すればよい。また、デート提案要求として、ユーザから検索条件が入力されている場合は、モデルから出力された施設属性と、入力された検索条件とを用いた施設検索処理を実施すればよい。

その他、本発明の実施の際の具体的な構造及び手順は、本発明の目的を達成できる範囲で他の構造などに適宜変更できる。

１…情報処理システム、１０…サーバ装置（情報処理装置）、１１…通信部、１２…記憶部、１３…制御部、２０…ユーザ端末、２０Ａ…第一ユーザ端末、２０Ｂ…第二ユーザ端末、１３１…ユーザ情報取得部、１３２…回数取得部、１３３…メッセージ送受信部（メッセージ取得部）、１３４…キーワード解析部、１３５…関係判定部、１３６…スケジュール調整部、１３７…施設検索部、１３８…評価取得部、１３９…施設傾向判定部。

Claims (10)

1. 第一ユーザに関する第一ユーザ属性、及び第二ユーザに関する第二ユーザ属性を取得するユーザ情報取得部と、
   前記第一ユーザと前記第二ユーザとの関係性を判定する関係判定部と、
   施設及び前記施設の属性に関する施設属性を関連付けた施設データを記憶する施設データベースから、前記第一ユーザ属性及び前記第二ユーザ属性の少なくとも一方に対応し、かつ、前記第一ユーザ及び前記第二ユーザの前記関係性に対応する前記施設を検索する施設検索部と、
   を備えることを特徴とする情報処理装置。
2. 請求項１に記載の情報処理装置において、
   前記第一ユーザと前記第二ユーザとが実際に会った回数を取得する回数取得部を備え、
   前記関係判定部は、前記回数に基づいて前記関係性を判定する
   ことを特徴とする情報処理装置。
3. 請求項１に記載の情報処理装置において、
   前記第一ユーザが操作する第一ユーザ端末から送信される前記第二ユーザへのメッセージ、及び前記第二ユーザが操作する第二ユーザ端末から送信される前記第一ユーザに対するメッセージを取得するメッセージ取得部を備え、
   前記関係判定部は、前記メッセージに基づいて、前記関係性を判定する
   ことを特徴とする情報処理装置。
4. 請求項１から請求項３のいずれか１項に記載の情報処理装置において、
   前記関係性は、前記第一ユーザ及び前記第二ユーザの親密さを示す親密度を含む
   ことを特徴とする情報処理装置。
5. 請求項１から請求項４のいずれか１項に記載の情報処理装置において、
   前記関係性は、前記第一ユーザの性格であるユーザタイプと、前記第二ユーザの性格であるユーザタイプとの組み合わせを含む
   ことを特徴とする情報処理装置。
6. 請求項５に記載の情報処理装置において、
   前記関係判定部は、前記第一ユーザが他のユーザとともに利用した前記施設の履歴と、前記第一ユーザ属性とに基づいて前記第一ユーザのユーザタイプを判定し、前記第二ユーザが他のユーザとともに利用した前記施設の履歴と前記第二ユーザ属性とに基づいて、前記第二ユーザのユーザタイプを判定する
   ことを特徴とする情報処理装置。
7. 請求項１から請求項６のいずれか１項に記載の情報処理装置において、
   前記施設に対する前記第一ユーザの評価、及び前記施設に対する前記第二ユーザの評価を取得する評価取得部と、
   前記第一ユーザ属性、前記第二ユーザ属性、及び前記評価に基づいて、前記第一ユーザ及び前記第二ユーザの前記施設の嗜好傾向を判定する施設傾向判定部と、を備え、
   前記施設検索部は、前記第一ユーザ属性及び前記第二ユーザ属性の少なくとも一方と、前記関係性と、前記施設の嗜好傾向とに基づいて、前記施設を検索する
   ことを特徴とする情報処理装置。
8. 請求項１から請求項７のいずれか１項の情報処理装置において、
   前記ユーザ情報取得部は、前記第一ユーザ及び前記第二ユーザのスケジュールを取得し、
   前記第一ユーザ及び前記第二ユーザが合う候補日時を調整するスケジュール調整部を備え、
   前記スケジュール調整部は、前記第一ユーザのスケジュール、前記第二ユーザのスケジュール、及び、前記第一ユーザと前記第二ユーザの前記関係性に基づいて前記候補日時を調整する
   ことを特徴とする情報処理装置。
9. コンピュータにより施設を検索させる情報処理方法であって、
   前記コンピュータは、ユーザ情報取得部、関係判定部、及び施設検索部を備え、
   前記ユーザ情報取得部が、第一ユーザに関する第一ユーザ属性、及び第二ユーザに関する第二ユーザ属性を取得するステップと、
   前記関係判定部が、前記第一ユーザと前記第二ユーザとの関係性を判定するステップと、
   前記施設検索部が、前記施設及び前記施設の属性に関する施設属性を関連付けた施設データを記憶する施設データベースから、前記第一ユーザ属性及び前記第二ユーザ属性の少なくとも一方に対応し、かつ、前記第一ユーザ及び前記第二ユーザの前記関係性に対応する前記施設を検索するステップと、
   を実施することを特徴とする情報処理方法。
10. コンピュータにより読み取り実行される情報処理プログラムであって、
    前記コンピュータを、請求項１から請求項８のいずれか１項に記載の情報処理装置として機能させる
    ことを特徴とする情報処理プログラム。