[1.施設検索システムの全体構成]
以下、本発明に係る施設検索システムの実施形態の例を説明する。図1は、施設検索システムの全体構成を示す図である。図1に示すように、施設検索システムSは、施設端末10、サーバ20、及び検索者端末30を含み、これらは、インターネットなどのネットワークNに接続可能である。なお、図1では、施設端末10、サーバ20、及び検索者端末30を1台ずつ示しているが、これらは複数台あってよい。例えば、施設ごとに、少なくとも1つの施設端末10が存在してもよい。
施設端末10は、施設の担当者が操作するコンピュータである。施設は、所定の目的で使用される建造物又は場所であり、例えば、ホテル、レストラン、店舗、ショッピングモール、病院、公園、競技場、イベント会場、テーマパーク、駅、空港、停留所、公営施設、又は観光施設等である。担当者は、施設に関係するユーザであればよく、例えば、施設の従業員であってもよいし、施設から情報管理の委託を受けた管理者であってもよい。
例えば、施設端末10は、携帯電話機(スマートフォンを含む)、携帯情報端末(タブレット型コンピュータを含む)、又は、パーソナルコンピュータ等である。本実施形態では、施設端末10は、制御部11、記憶部12、通信部13、操作部14、及び表示部15を含む。
制御部11は、少なくとも1つのマイクロプロセッサを含む。制御部11は、記憶部12に記憶されたプログラムやデータに従って処理を実行する。記憶部12は、主記憶部及び補助記憶部を含む。例えば、主記憶部はRAMなどの揮発性メモリであり、補助記憶部は、ROM、EEPROM、フラッシュメモリ、又はハードディスクなどの不揮発性メモリである。
通信部13は、有線通信又は無線通信用の通信インタフェースであり、ネットワークを介してデータ通信を行う。操作部14は、入力デバイスであり、例えば、タッチパネルやマウス等のポインティングデバイス、キーボード、又はボタン等である。操作部14は、ユーザによる操作内容を制御部11に伝達する。表示部15は、例えば、液晶表示部又は有機EL表示部等である。表示部15は、制御部11の指示に従って画像を表示する。
サーバ20は、サーバコンピュータである。サーバ20は、制御部21、記憶部22、及び通信部23を含む。制御部21、記憶部22、及び通信部23の物理的構成は、それぞれ制御部11、記憶部12、及び通信部13と同様であってよい。
検索者端末30は、検索者が操作するコンピュータである。検索者は、施設を検索するユーザである。別の言い方をすれば、検索者は、検索結果の提供を受けるユーザであり、エンドユーザということもできる。検索結果の提供とは、サーバ20から検索結果を受信することであり、検索結果を表示させたりダウンロードしたりすることである。例えば、検索者は、施設の場所を調べたり施設を予約したりするために、施設検索システムSを利用する。
例えば、検索者端末30は、携帯電話機(スマートフォンを含む)、携帯情報端末(タブレット型コンピュータを含む)、又は、パーソナルコンピュータ等である。本実施形態では、検索者端末30は、制御部31、記憶部32、通信部33、操作部34、及び表示部35を含む。制御部31、記憶部32、通信部33、操作部34、及び表示部35の物理的構成は、それぞれ制御部11、記憶部12、通信部13、操作部14、及び表示部15と同様であってよい。
なお、記憶部12,22,32に記憶されるものとして説明するプログラム及びデータは、ネットワークNを介して供給されるようにしてもよい。また、上記説明した各コンピュータのハードウェア構成は、上記の例に限られず、種々のハードウェアを適用可能である。例えば、コンピュータ読み取り可能な情報記憶媒体を読み取る読取部(例えば、光ディスクドライブやメモリカードスロット)や外部機器とデータの入出力をするための入出力部(例えば、USBポート)が含まれていてもよい。例えば、情報記憶媒体に記憶されたプログラムやデータが読取部や入出力部を介して、各コンピュータに供給されるようにしてもよい。
[2.施設検索システムの概要]
施設検索システムSは、検索者が入力した検索条件に基づいて、複数の施設の中から検索条件に合致する施設を検索する。検索条件は、検索のクエリであり、例えば、キーワード、場所、ジャンル、カテゴリ、属性、又は数値(例えば、価格帯又は利用日)といった種々の条件を指定可能である。
本実施形態では、施設は、自身のページを有しており、施設検索システムSは、検索者が選択した施設のページを検索者端末30に表示させる。ページは、施設ごとに用意されており、検索者端末30のブラウザやアプリケーションなどを利用して閲覧される。ページは、ウェブページ、ウェブサイト、又はホームページと呼ばれるものであってもよい。例えば、各施設は、自身のページに表示させる施設情報をサーバ20に登録する。
施設情報は、施設に関する情報であればよく、例えば、施設の名前、ジャンル、ページのタイトル、画像若しくは動画等のコンテンツ、紹介文、施設の住所、緯度経度情報、電話番号、又はメールアドレスといった情報である。紹介文は、施設の紹介を示す文章であり、例えば、施設が提供する商品又はサービスを示す文章であってもよいし、施設の予約方法や利用方法等を示す文章であってもよい。
本実施形態では、施設情報が検索のインデックスとして用いられる場合を説明するが、施設情報は、特にインデックスとはならなくてもよい。更に、施設情報の全ての項目がインデックスとなる必要はなく、一部の項目だけがインデックスとなってもよい。例えば、施設の担当者が、施設端末10を操作してサーバ20にログインすると、施設情報を入力するための情報入力画面が表示部15に表示される。
図2は、情報入力画面の一例を示す図である。図2に示すように、情報入力画面G1には、施設名を入力するための入力フォームF10が表示される。施設の担当者は、入力フォームF10に文字列を入力することによって、施設名を入力する。
また例えば、情報入力画面G1には、施設のページに表示させる画像をアップロードするためのボタンB11が表示され、表示領域A12には、アップロード済みの画像が表示される。また例えば、情報入力画面G1には、施設の紹介文を入力するための入力フォームF13が表示される。施設の担当者は、入力フォームF13に文字列を入力することによって、施設の紹介文を入力する。
また例えば、情報入力画面G1には、施設の住所を入力するための入力フォームF14が表示される。施設の担当者は、入力フォームF14に郵便番号や文字列を入力することによって、施設の住所を入力する。また例えば、情報入力画面G1には、施設の緯度経度情報を入力するためのボタンB15が表示される。施設の担当者がボタンB15を選択すると、表示部15に地図が表示され、地図上の位置を指定することで緯度経度情報が入力される。
また例えば、情報入力画面G1には、プレイスタグを入力するための入力フォームF16が表示される。プレイスタグは、本発明に係るエリア情報の一例である。このため、本実施形態でプレイスタグと記載した箇所は、エリア情報と読み替えることができる。
プレイスタグは、施設の位置を含むエリアの名前に関する情報である。別の言い方をすれば、プレイスタグは、施設を分類するために入力されたエリア名である。プレイスタグは、エリア名を示す文字列を含む。プレイスタグは、文字列以外にも、プレイスタグであることを識別可能な「#」や「%」といった特定の記号を含んでもよい。即ち、このような記号によって、プレイスタグなのか単なる文字列なのかを識別可能としてもよい。
例えば、プレイスタグは、サーバ20側で用意された名前ではなく、施設の担当者が入力した名前であってもよいし、施設以外の者(例えば、検索者)が入力した名前であってもよい。プレイスタグは、実在の地名であってもよいし、実在の地名でなくてもよい。プレイスタグが実在の地名である場合には、住所に含まれる地名そのものがプレイスタグとなってもよいし、地名の略称がプレイスタグとなってもよい。
一方、プレイスタグが実在の地名でない場合には、例えば、プレイスタグは、エリアの俗称であってもよいし、今では使われなくなった古い名称であってもよい。他にも例えば、プレイスタグは、エリア内又はその付近にある有名な施設の名称であってもよいし、エリア内又はその付近にある有名な観光地の名称であってもよいし、エリア内又はその付近で開催されるイベントの名称であってもよい。
例えば、施設の担当者は、入力フォームF16に文字列を入力することによって、施設のプレイスタグを入力する。なお、プレイスタグの入力方法は、これに限られず、プレイスタグは、任意の方法で入力可能である。例えば、紹介文の中でプレイスタグを入力可能としてもよいし、近隣の他の施設に付与されたプレイスタグの一覧を表示させ、当該一覧の中からプレイスタグを選択させてもよい。
図2の例であれば、「レストランA」という施設は、「XXXリゾート」という有名な施設一帯のエリア内に存在し、観光客やマスコミ等は、当該エリアを「XXXリゾート」エリアと呼んでいるものとする。「XXXリゾート」は、実在の地名ではないがエリアを認識可能な名前なので、「レストランA」の担当者は、自身のプレイスタグを「XXXリゾート」と指定する。
情報入力画面G1から入力された施設情報は、サーバ20に登録され、施設のページを表示させるために利用されたり、検索時のインデックスとして利用されたりする。例えば、検索者がプレイスタグを指定すると、当該プレイスタグが付与された施設が検索される。例えば、検索者が「XXXリゾート」というプレイスタグを検索条件に含めて検索すると、当該プレイスタグが付与された「レストランA」が検索結果にヒットする。
なお、施設の担当者は、情報入力画面G1の全ての項目を入力する必要はなく、一部の項目だけを入力してもよい。このため、施設によっては、プレイスタグが付与されていないこともある。例えば、「XXXリゾート」付近にある「おみやげ屋B」の担当者が、情報入力画面G1から特にプレイスタグを入力しなかったとすると、「おみやげ屋B」には、プレイスタグは付与されない。このため、検索者が「XXXリゾート」というプレイスタグを検索条件に含めて検索しても、「おみやげ屋B」は検索結果にヒットしない。
例えば、「XXXリゾート」というプレイスタグが検索で頻繁に使用されているような場合には、「おみやげ屋B」にプレイスタグを付与した方がよいことがある。しかし、「おみやげ屋B」の担当者がその事実に気付くことは難しいので、本実施形態の施設検索システムSは、プレイスタグが付与されていない施設が、プレイスタグが付与された施設に囲まれている場合には、プレイスタグの付与を提案するようにしている。
図3は、プレイスタグが付与された施設と、プレイスタグが付与されなかった施設と、を含む地図の一部を示す図である。図3では、施設を円で示しており、地図Mの中には、施設FA1〜FA15が存在する。なお、地図Mは、道路や線路等も示されているが、図3では省略している。
地図Mのうち、黒い円は、プレイスタグが付与された施設を示し、白い円は、プレイスタグが付与されなかった施設を示す。図3の例では、施設FA1〜FA7の各々に対し、「XXXリゾート」というプレイスタグが付与されており、施設FA8〜FA15には、当該プレイスタグが付与されていないものとする。
図3に示すように、例えば、施設FA8,FA9は、プレイスタグが付与された施設FA1〜FA6に囲まれており、プレイスタグを付与した方が良いことがある。施設検索システムSは、プレイスタグを付与した方が良い施設を特定するために、プレイスタグが付与された施設群の位置に基づいて、地図M上に領域を設定する。以降、当該領域を付与領域と記載する。
図4は、地図M上に付与領域が設定される様子を示す図である。図4に示すように、プレイスタグが付与された施設FA1〜FA7のうち、施設FA7については、他の施設FA1〜FA6から離れた位置にある。このため、本実施形態では、施設FA7に付与されたプレイスタグは、信頼性が低いものとして付与領域A1の設定では除外され、互いに近い位置にある施設FA1〜FA6に基づいて付与領域A1が設定される。
付与領域A1は、任意の形状であってよいが、本実施形態では、施設FA1〜F6を結ぶ多角形とする。例えば、施設FA1から順番に、近い位置にある他の施設が2つ特定され、これら3つで囲われる三角形により付与領域A1が構成される。図4の例では、付与領域A1は、施設FA1,FA2,FA4,FA5,FA6,FA3,FA1の順で繋いだ線によって囲われた領域となる。
本実施形態では、プレイスタグが設定されていない施設FA8〜FA15のうち、付与領域A1内にある施設FA8,FA9がプレイスタグを付与した方が良い施設として決定される。施設FA8,FA9に対し、プレイスタグが自動的(強制的)に付与されてもよいが、プレイスタグが施設FA8,FA9に適しているか否かは、地図上の位置関係だけでは判別できないことがある。例えば、プレイスタグの適否は、地図から得られるルート情報や3次元の建物情報を駆使しても判別することが難しいことがあるので、本実施形態では、サーバ20は、施設FA8,FA9の各々に対し、プレイスタグを付与するか否かを問い合わせるようにしている。
例えば、施設FA8,FA9が、「XXXリゾート」のライバル会社が運営していることがあるので、サーバ20は、施設FA8,FA9に「XXXリゾート」といったプレイスタグを付与するか否かを問い合わせてもよい。また例えば、プレイスタグが「YYY花火大会」といったイベントの開催場所を示したとすると、施設FA8,FA9と花火の打ち上げ場所との間に高層ビルが配置されていれば、施設FA8,FA9から花火を見ることができないので、サーバ20は、施設FA8,FA9に「YYY花火大会」といったプレイスタグを付与するか否かを問い合わせてもよい。施設FA8,FA9の施設端末10は、サーバ20からの問い合わせを受けると、問い合わせ画面が表示部15に表示される。
図5は、問い合わせ画面の一例を示す図である。図5に示すように、問い合わせ画面G2には、プレイスタグの付与を提案するメッセージが表示される。施設FA8,F9の各々の担当者は、メッセージの内容を確認し、自身の施設にプレイスタグを付与して良ければボタンB20を選択し、特にその必要が無ければボタンB21を選択する。ここでは、施設FA8,F9の各々の担当者が何れもボタンB20を選択した場合について説明する。
図6は、施設FA8,FA9にプレイスタグが設定される様子を示す図である。図6に示すように、施設FA8,FA9の各々の担当者がボタンB20を選択すると、施設FA8,FA9にプレイスタグが設定され、プレイスタグによる検索が可能となる。このため、検索者が「XXXリゾート」というプレイスタグを検索条件に含めて施設検索を実行した場合、施設FA8,FA9も検索結果に含まれるようになる。
次に、検索者が施設検索を実行する際の流れについて説明する。例えば、検索者が検索者端末30から所定の操作をすると、検索条件を入力するための施設検索画面が表示部35に表示される。
図7は、施設検索画面の一例を示す図である。図7に示すように、施設検索画面G3には、検索条件を入力するための入力フォームF30が表示される。検索者は、入力フォームF30から検索条件を入力する。検索条件は、キーワード、施設のカテゴリ、利用日、又は利用人数といった種々の条件を入力可能であってよいが、ここでは、プレイスタグの文字列が入力される場合について説明する。例えば、検索者が入力フォームF30から「XXXリゾート」といったプレイスタグの文字列を入力し、ボタンB31を選択すると、当該文字列をクエリとした検索が実行され、検索結果を示す検索結果画面が表示部35に表示される。
図8は、検索結果画面の一例を示す図である。図8に示すように、検索結果画面G4には、検索で使用された検索条件が入力フォームF40に表示される。検索者は、入力フォームF40から検索条件を変更して再度検索を実行することもできる。検索結果画面G4の表示領域A41には、検索でヒットした施設の一覧が表示される。ここでは、「XXXリゾート」というプレイスタグが検索条件として入力されたので、当該プレイスタグが付与された施設が表示領域A41に表示される。例えば、図6で説明したように、プレイスタグが予め付与されていた施設FA1〜FA7だけでなく、プレイスタグが事後的に付与された施設FA8,FA9も、検索結果に含まれることになる。
以上のように、本実施形態の施設検索システムSでは、プレイスタグが付与されていない施設が付与領域A1に含まれる場合に、当該施設にプレイスタグを付与することによって、検索の精度を向上させるようになっている。以降、この技術の詳細を説明する。
[3.実施形態において実現される機能]
図9は、実施形態の施設検索システムSで実現される機能の一例を示す機能ブロック図である。なお、本実施形態では、主な機能がサーバ20で実現される場合を説明するが、後述する変形例のように、施設端末10、サーバ20、及び検索者端末30のうちの少なくとも2つで機能が分担されてもよい。
図9に示すように、施設検索システムSでは、データ記憶部200、第1付与部201、問い合わせ部202、回答取得部203、第2付与部204、取扱部205、及び施設検索部206が実現される。データ記憶部200、第1付与部201、問い合わせ部202、回答取得部203、第2付与部204、取扱部205、及び施設検索部206は、それぞれ記憶手段、第1付与手段、問い合わせ手段、回答取得手段、第2付与手段、取扱手段、及び施設検索手段の一例である。
[3−1.データ記憶部]
データ記憶部200は、記憶部22を主として実現される。データ記憶部200は、施設検索に必要なデータを記憶する。ここでは、データ記憶部200が記憶するデータの一例として、施設データベースDBを説明する。
図10は、施設データベースDBのデータ格納例を示す図である。図10に示すように、施設データベースDBは、施設に関する種々の情報を格納するためのデータベースである。例えば、施設データベースDBには、施設を一意に識別する施設IDに関連付けて、施設情報が格納される。
施設情報としては、例えば、施設の名前、画像や動画などのコンテンツ、紹介文、住所、緯度経度情報、プレイスタグ、又はページのアドレス等が格納される。例えば、施設の担当者が情報入力画面G1から施設情報を入力すると、当該施設の施設IDと関連付けられて施設情報が施設データベースDBに格納される。
なお、データ記憶部200に記憶されるデータは、上記の例に限られない。例えば、データ記憶部200は、情報入力画面G1、問い合わせ画面G2、施設検索画面G3、及び検索結果画面G4の各々を表示させるための画像データを記憶してもよい。また例えば、データ記憶部200は、地図Mに関する地図データを記憶してもよい。地図データ自体は、種々のデータを適用可能であり、例えば、2次元的な地図のデータであてもよいし、3次元的な地形も反映されたデータであってもよい。
[3−2.第1付与部]
第1付与部201は、制御部21を主として実現される。第1付与部201は、施設が位置するエリアの名前に関するプレイスタグが入力された場合に、当該施設に当該プレイスタグを付与する。
施設にプレイスタグを付与するとは、プレイスタグを施設のインデックスとして設定することである。別の言い方をすれば、施設にプレイスタグを付与するとは、データベース上で施設IDとプレイスタグを関連付けることである。施設にプレイスタグが付与されると、当該プレイスタグを利用して施設を検索可能となる。本実施形態では、施設データベースDBに、施設IDに関連付けてプレイスタグを格納することが、施設にプレイスタグを付与することに相当する。
本実施形態では、施設の担当者によってプレイスタグが入力される場合を説明するが、プレイスタグは、検索者によって入力されてもよいし、検索者以外のユーザによって入力されてもよい。例えば、施設端末10は、操作部14の検出信号に基づいて、施設の担当者により入力されたプレイスタグを特定する。施設端末10は、特定したプレイスタグを、施設の施設IDとともに当該サーバ20に送信する。サーバ20は施設IDとプレイスタグを受信し、第1付与部201は、施設データベースDBのうち、受信した施設IDが格納されたレコードに、受信したプレイスタグを格納する。
なお、第1付与部201は、施設に対し、プレイスタグを1つだけ付与してもよいし、複数のプレイスタグを付与してもよい。複数のプレイスタグが施設に付与される場合には、第1付与部201は、複数のプレイスタグを一度に付与してもよいし、プレイスタグを1つずつ繰り返し付与してもよい。また、施設に付与されるプレイスタグの数は、上限数を設けてもよいし、特に上限数は設けなくてもよい。
[3−3.問い合わせ部]
問い合わせ部202は、制御部21を主として実現される。問い合わせ部202は、他の施設に対し、第2付与部204によるプレイスタグの付与を許可するか否かを問い合わせる。他の施設とは、付与領域A1に含まれる施設のうち、当該付与領域A1が示すプレイスタグが付与されていない施設である。別の言い方をすれば、他の施設とは、問い合わせの対象となる施設である。
例えば、問い合わせ部202は、施設端末10に対し、問い合わせ画面G2の表示データを送信することによって、問い合わせを行う。表示データは、任意のデータ形式であればよく、例えば、HTMLデータであってもよいし、アプリケーション上で画面を表示させるための画像データやテキストデータであってもよい。問い合わせ画面G2では、施設による回答を選択可能となっている。
回答とは、問い合わせに対する回答であり、例えば、プレイスタグの付与を許可すること、又は、プレイスタグの付与を許可しないことの何れか一方を示す。プレイスタグの付与を許可するとは、プレイスタグの付与を指示すること、又は、プレイスタグの付与を希望することを意味する。プレイスタグの付与を許可しないとは、プレイスタグの付与を拒否すること、又は、プレイスタグの付与を禁止することを意味する。
なお、問い合わせ方法自体は、種々の方法を適用可能であり、上記の例に限られない。例えば、問い合わせ部202は、電子メール、メッセージアプリによるメッセージ、プッシュ通知、又はソーシャルネットワーキングサービスによるメッセージといった方法によって、問い合わせを行ってもよい。また、施設端末10を識別する情報は、データ記憶部200に予め記憶させておけばよく、問い合わせ部202は、当該情報に基づいて、問い合わせ先の施設端末10を特定すればよい。当該情報は、施設のアカウント、メールアドレス、メッセージアプリのID、施設端末10の個体識別情報、又はソーシャルネットワーキングサービスのアカウント等であってよい。
[3−4.回答取得部]
回答取得部203は、制御部21を主として実現される。回答取得部203は、他の施設による回答を取得する。他の施設及び回答の意味は、先述した通りである。回答取得部203は、施設端末10から、回答データを受信することによって、回答を取得する。
回答データは、回答内容を示すデータであればよく、例えば、プレイスタグの付与を許可すること、又は、プレイスタグの付与を許可しないことの何れかを示す。例えば、回答データが第1の値を示す場合は、プレイスタグの付与を許可しないことを意味し、回答データが第2の値を示す場合は、プレイスタグの付与を許可しないことを示す。本実施形態では、問い合わせ画面G2において回答が選択されるので、回答データは、ボタンB20又はB21の何れが選択されたかを示すデータとなる。
例えば、施設端末10は、操作部14の検出信号に基づいて、施設の回答を特定する。施設端末10は、特定した回答を示す回答データをサーバ20に送信する。例えば、施設の担当者がボタンB20を選択した場合には、施設端末10は、プレイスタグの付与を許可する旨の回答データを送信する。また例えば、施設の担当者がボタンB21を選択した場合には、施設端末10は、プレイスタグの付与を許可しない旨の回答データを送信する。サーバ20の回答取得部203は、回答データを受信することによって、施設の回答を取得する。
なお、回答の取得方法は、問い合わせ方法に応じた方法で取得されるようにすればよく、上記の例に限られない。例えば、回答取得部203は、電子メール、メッセージアプリによるメッセージ、プッシュ通知、又はソーシャルネットワーキングサービスによるメッセージといった方法によって、回答を取得してもよい。
[3−5.第2付与部]
第2付与部204は、制御部21を主として実現される。第2付与部204は、同じプレイスタグが付与された施設群の位置に基づく領域に、当該プレイスタグが付与されていない他の施設の位置が含まれる場合に、当該他の施設に当該プレイスタグを付与する。
同じプレイスタグとは、インデックスとして同じであることを意味する。例えば、プレイスタグが同名である場合に、同じプレイスタグとしてもよい。また例えば、同じ名前で呼ばれるエリアが全く異なる場所に存在することもあるので、プレイスタグが同名であり、かつ、当該プレイスタグが付与された施設群同士の位置が近いことが、同じプレイスタグであることの条件となってもよい。なお、エリア名には表記ゆれが存在するので、文字列としては違ったとしても、表記ゆれを考慮したうえで同じプレイスタグが特定されてもよい。
施設群とは、複数の施設の総称である。施設群には、n個(nは2以上の整数)の施設が含まれており、その数は任意であってよい。例えば、施設群には、2つの施設だけが含まれていてもよいし、3個〜数百個の施設が含まれていてもよい。また例えば、施設群には、千個以上の施設が含まれていてもよい。
同じプレイスタグが付与された施設群の位置に基づく領域とは、当該施設群の位置に基づいて定まる領域であり、当該施設群の位置を少なくとも含む領域である、本実施形態では、当該領域の一例として付与領域A1を説明する。このため、本実施形態で付与領域A1と記載した箇所は、同じプレイスタグが付与された施設群の位置に基づく領域と読み替えることができる。
なお、施設の位置とは、地球上又は地図上の位置である。施設の位置は、絶対的な位置を特定可能な情報で示されるようにすればよく、例えば、緯度経度情報、座標情報、又は住所によって示される。本実施形態では、施設の位置が緯度経度情報によって示される場合を説明する。
例えば、第2付与部204は、施設群に含まれる少なくとも1つの施設の位置に基づいて、付与領域A1を設定する。本実施形態では、第2付与部204は、施設群に含まれる全ての施設の位置に基づいて付与領域A1を設定する場合を説明するが、施設群に含まれる一部の施設の位置に基づいて付与領域A1を設定してもよい。一部の施設の位置に基づいて付与領域A1が設定される場合には、施設群の中からランダムに選出された施設の位置が利用されてもよいし、施設群のうちページの閲覧数や施設の予約数の多い施設の位置だけが利用されてもよい。
例えば、第2付与部204は、施設群の位置を含むように付与領域A1を設定する。付与領域A1は、施設群の全ての位置を含んでもよいし、一部の施設の位置だけを含んでもよい。付与領域A1が一部の施設の位置だけを含む場合には、プレイスタグが付与された施設群のうちの所定個数(例えば、数個〜数十個程度)又は所定割合(例えば、50%〜90%程度)以上の施設を含むよういにしてもよい。
本実施形態では、第2付与部204は、同じプレイスタグが付与された施設群の各々の位置を結ぶ多角形に基づいて、付与領域A1を設定する。多角形は、任意の頂点数であってよく、ここでは三角形とするが、四角形、五角形、又は六角形であってもよいし、七角形以上であってもよい。例えば、第2付与部204は、施設群の各々の位置について、直近の他の2つの位置を特定し、これら3つの位置を結ぶ三角形を繰り返し設定することによって、付与領域A1を設定する。
図11は、付与領域A1の設定方法の詳細を示す図である。図11に示すように、まず、第2付与部204は、施設FA1の位置から近い順に2つの位置を特定する。ここでは、施設FA2,FA3の位置が特定されるので、第2付加部は、施設FA1,FA2,FA3を結ぶ三角形T1を設定する。
次に、第2付与部204は、施設FA2の位置から近い順に2つの位置を特定する。ただし、施設FA1については三角形T1を設定済みなので、対象外とする。ここでは、施設FA3,FA4が特定されるので、第2付加部は、施設FA2,FA3,FA4を結ぶ三角形T2を設定する。以降同様にして、第2付加部は、施設FA3,FA4,FA5を結ぶ三角形T3と、施設FA3,FA5,FA6を結ぶ三角形T4と、を設定する。この時点で、プレイスタグが付与された施設FA1〜FA6の全てが、少なくとも1つの三角形の頂点を構成しているので、第2付加部は、三角形の設定を終了し、これら4つの三角形を結合して付与領域A1とする。
本実施形態では、第2付与部204は、同じプレイスタグが付与された施設群の中で、直近の施設との距離が閾値未満となる施設群の位置に基づいて、付与領域A1を設定する。直近とは、距離的に最も近いことを意味する。第2付与部204は、各施設の位置に基づいて直近の施設を特定し、距離が閾値以上であるか否かを判定する。閾値は、固定値としてもよいし、施設群やプレイスタグに応じて可変値としてもよい。閾値を可変値とする場合には、プレイスタグが付与された施設群の数が多いほど閾値を高くしてもよい。
図4の例であれば、施設FA7にプレイスタグが設定されているが、施設FA7は、同じプレイスタグが付与された施設群のうち、直近の施設FA1又はFA3から離れているので、第2付与部204は、付与領域A1を設定する際に、施設FA7の位置は参照しない。一方、施設FA1〜FA6については、直近の施設との距離が閾値未満となっているので、第2付与部204は、施設FA1〜FA6の各々の位置に基づいて、付与領域A1を設定する。
本実施形態では、他の施設に対する問い合わせが行われるので、第2付与部204は、回答に基づいて、他の施設にプレイスタグを付与する。例えば、第2付与部204は、プレイスタグの付与を許可する旨の回答が取得された場合は、他の施設にプレイスタグを付与し、プレイスタグの付与を許可しない旨の回答が取得された場合は、他の施設にプレイスタグを付与しない。なお、他の施設が問い合わせに対する回答をしなかった場合には、第2付与部204は、プレイスタグを自動的に付与してもよいし、この場合にはプレイスタグを付与しなくてもよい。
なお、付与領域A1の設定方法は、上記の例に限られない。例えば、第2付与部204は、同じプレイスタグが付与された施設群の個々の施設ごとに、当該施設の位置を含むように領域を設定し、当該領域が重なる部分を連結して付与領域A1を設定してもよい。当該領域は、任意の形状であってよく、例えば、円形であってもよいし、多角形であってもよい。
例えば、第2付与部204は、同じプレイスタグが付与された施設群の個々の施設ごとに、当該施設を中心とした円領域を設定し、円領域が重なる部分を連結して付与領域A1を設定してもよい。また例えば、第2付与部204は、連結した領域の外接円を付与領域A1としてもよいし、連結した領域の外接矩形を付与領域A1としてもよい。
また例えば、第2付与部204は、同じプレイスタグが付与された施設群の位置の中心点又は重心点に基づいて、付与領域A1を設定してもよい。中心点又は重心点は、所定の計算式に基づいて計算されるようにすればよく、例えば、各施設の位置の単純平均又は加重平均であってもよい。加重平均とする場合には、施設の密度の応じた重み付けをしてもよいし、施設のページの閲覧数や予約数に応じた重み付けをしてもよい。第2付与部204は、中心点又は重心点を含むように付与領域A1を設定してもよい。例えば、第2付与部204は、中心点又は重心点を中心とした所定半径の円を付与領域A1としてもよいし、中心点又は重心点を含む多角形を付与領域A1としてもよい。この場合、付与領域A1に、全ての施設が含まれている必要は無く、一部の施設については、付与領域A1の外に位置するようにしてもよい。
[3−6.取扱部]
取扱部205は、制御部21を主として実現される。取扱部205は、同じプレイスタグが付与された第1施設群と第2施設群との距離が閾値以上となる場合には、第1施設群に付与された当該プレイスタグと、第2施設群に付与された当該プレイスタグと、を別のプレイスタグとして取り扱う。
図12は、取扱部205の処理の説明図である。図12に示すように、例えば、取扱部205は、同じ名前のプレイスタグが付与された施設群の位置に基づいて、直近の施設との距離が第1閾値未満となる施設同士を同じ施設群としてグルーピングする。そして、取扱部205は、同じ名前のプレイスタグから第1施設群FG1と第2施設群FG2が検出された場合に、これらの距離Lが第2閾値以上であるか否かを判定する。第2閾値は、第1閾値と同じであってもよいが、ここでは、第1閾値よりも大きく設定するものとする。
取扱部205は、第1施設群FG1と第2施設群FG2との距離Lが第2閾値未満である場合は、第1施設群FG1に付与されたプレイスタグと、第2施設群FG2に付与されたプレイスタグと、を同じプレイスタグとして取り扱う。即ち、取扱部205は、第1施設群FG1と第2施設群FG2を同じ施設群とし、同じプレイスタグでこれらを検索可能とする。
一方、取扱部205は、第1施設群FG1と第2施設群FG2との距離が第2閾値以上である場合に、第1施設群FG1に付与されたプレイスタグと、第2施設群FG2に付与されたプレイスタグと、が同じ名前であったとしても、互いに異なるプレイスタグとして取り扱う。例えば、取扱部205は、プレイスタグが示すエリア名の前後に、互いを識別する識別情報を付与してもよいし、表示上は同じエリア名とするが内部的に互いを識別する識別情報を付与してもよい。
[3−7.施設検索部]
施設検索部206は、制御部21を主として実現される。施設検索部206は、各施設に付与されたプレイスタグに基づいて、施設検索を実行する。施設検索部206は、検索者により入力された検索条件をクエリとし、プレイスタグをインデックスとして、施設検索を実行する。なお、プレイスタグ以外の情報がインデックスとされてもよく、例えば、施設検索部206は、施設名、紹介文、住所、又は緯度経度情報といった情報をインデックスとして、施設検索を実行してもよい。
例えば、施設検索部206は、検索条件と、施設データベースDBに格納されたプレイスタグと、一致するか否かを判定する。ここでの一致は、完全一致であってもよいし、部分一致であってもよい。施設検索部206は、検索条件と一致するプレイスタグが付与された施設を、検索結果として取得する。なお、施設検索部206は、あいまい検索を利用して施設検索を実行してもよい。
[4.本実施形態において実行される処理]
次に、施設検索システムSにおいて実行される処理を説明する。ここでは、施設情報をサーバ20に登録するための施設情報登録処理、他の施設にプレイスタグを付与するためのプレイスタグ付与処理、及び、施設検索を実行するための施設検索処理を説明する。
[4−1.施設情報登録処理]
図13は、施設情報登録処理のフロー図である。図13に示す処理は、制御部11,21が、それぞれ記憶部12,22に記憶されたプログラムに従って動作することによって実行される。下記に説明する処理は、図9に示す機能ブロックにより実行される処理の一例である。
図13に示すように、まず、施設端末10とサーバ20との間で、所定のログイン処理が実行され(S100)、ログイン処理が成功すると、制御部11は、情報入力画面G1を表示部15に表示させる(S101)。S100においては、施設の担当者が操作部14を操作し、ブラウザから情報入力画面G1のURLが指定されたり、所定のアプリケーションが起動されたりすると、制御部11は、サーバ20にアクセス要求を送信する。アクセス要求は、所定のデータ形式の要求であればよく、例えば、施設IDを含んでもよい。S101においては、施設の担当者がアカウントとパスワードを入力してもよいし、記憶部12に記憶されたアカウントとパスワードがサーバ20に送信されてもよい。
制御部11は、操作部14の検出信号に基づいて、施設の担当者の操作を特定する(S102)。ここでは、入力フォームF10に施設名を入力する操作、ボタンB11を選択する操作、入力フォームF13に施設紹介を入力する操作、入力フォームF14に住所を入力する操作、ボタンB15を選択する操作、入力フォームF16にプレイスタグを入力する操作、又は、ボタンB17を選択する操作の何れかが行われるものとする。
入力フォームF10に施設名が入力された場合(S102;F10)、制御部11は、当該入力された施設名を入力フォームF10に表示させる(S103)。S103においては、制御部11は、入力された施設名を記憶部12に記録する。
S102において、ボタンB11が選択された場合(S102;B11)、制御部11は、施設の画像の一覧を表示部15に表示させ、施設の担当者により選択された画像を表示領域A12に表示させる(S104)。S104においては、制御部11は、当該選択された画像を識別する情報を記憶部12に記録する。
S102において、入力フォームF13に紹介文が入力された場合(S102;F13)、制御部11は、当該入力された紹介文を入力フォームF13に表示させる(S105)。S105においては、制御部11は、入力された紹介文を記憶部12に記録する。なお、先述したように、紹介文の中にプレイスタグが入力されるようにしてもよい。
S102において、入力フォームF14に住所が入力された場合(S102;F14)、制御部11は、当該入力された住所を入力フォームF14に表示させる(S106)。S106においては、制御部11は、入力された住所を記憶部12に記録する。
S102において、ボタンB15が選択された場合(S102;B15)、制御部11は、地図を表示部15に表示させ、施設の担当者により指定された地図上の位置を記憶部12に記録する(S107)。S107においては、制御部11は、施設の緯度経度情報を記憶部12に記録することになる。
S102において、入力フォームF16にプレイスタグが入力された場合(S102;F16)、制御部11は、当該入力されたプレイスタグを入力フォームF16に表示させる(S108)。S108においては、制御部11は、入力されたプレイスタグを記憶部12に記録する。
S102において、ボタンB17が選択された場合(S102;B17)、制御部11は、サーバ20に対し、施設IDとともに施設情報を送信する(S109)。S109においては、制御部11は、S103〜S108の処理で記憶部12に記録された施設名やプレイスタグ等を含む施設情報を送信することになる。なお、施設IDは、予め記憶部12に記憶されているものとする。
サーバ20においては、施設IDと施設情報を受信すると、制御部21は、施設情報を施設データベースDBに格納し(S110)、本処理は終了する。S110においては、制御部21は、施設データベースDBのうち、受信した施設IDが格納されたレコードを特定し、当該レコードに、受信した施設情報を格納する。施設の担当者がプレイスタグを入力していた場合には、当該プレイスタグが施設に付与されることになる。
[4−2.プレイスタグ付与処理]
図14は、プレイスタグ付与処理のフロー図である。図14に示す処理は、制御部11,21が、それぞれ記憶部12,22に記憶されたプログラムに従って動作することによって実行される。下記に説明する処理は、図9に示す機能ブロックにより実行される処理の一例である。なお、プレイスタグ付与処理は、定期的に実行されてもよいし、システム管理者の指示に応じて実行されてもよい。
図14に示すように、まず、サーバ20においては、制御部21は、施設データベースDBの中から、処理対象のプレイスタグを決定する(S200)。処理対象とは、以降説明する処理を実行すべきプレイスタグである。即ち、処理対象は、付与領域A1を設定し、プレイスタグが付与されていない施設に対して問い合わせを行うべきプレイスタグである。処理対象のプレイスタグは、施設データベースDBに格納されたプレイスタグが格納されたレコードが若い順に決定されてもよいし、ランダムに決定されてもよい。
制御部21は、S200で決定したプレイスタグが付与された施設群の位置に基づいて、付与領域A1の設定で用いる位置を決定する(S201)。S201においては、制御部21は、直近の施設との距離が閾値以上となる施設は、処理対象から除外する。S201の処理により、図3の施設FA7は、付与領域A1の設定では用いられないようになる。
制御部21は、S200で決定したプレイスタグが付与された施設群の位置に基づいて、地図M上に付与領域A1を設定する(S202)。S202においては、制御部21は、施設群の各々の位置に基づいて、全ての施設の位置が少なくとも1つの三角形の頂点を構成するまで三角形を設定し、これら設定した三角形を結合することによって、付与領域A1を設定する。
制御部21は、施設データベースDBに基づいて、処理中のプレイスタグが付与されていない他の施設の中から、S202で設定した付与領域A1に含まれる施設を特定する(S203)。S203においては、制御部21は、処理中のプレイスタグが付与されていない他の施設の位置が付与領域A1に含まれるか否かを判定することになる。
制御部21は、施設データベースDBに基づいて、S203で特定した他の施設の施設端末10に対し、プレイスタグの付与を許可するか否かを問い合わせる(S204)。S204においては、制御部21は、S203で特定した他の施設がサーバ20にアクセスした場合に、問い合わせ画面G2が表示されるように設定してもよいし、電子メール等を利用して問い合わせてもよい。S203において、複数の施設が特定された場合には、S204においては、これら複数の施設の各々に対して問い合わせが行われる。
施設端末10においては、問い合わせが行われると、制御部11は、問い合わせ画面G2を表示部15に表示させる(S205)。制御部11は、操作部14の検出信号に基づいて、施設の担当者の操作を特定する(S206)。ここでは、ボタンB20を選択する操作、又は、ボタンB21を選択する操作の何れかが行われる。
ボタンB20が選択された場合(S206;B20)、制御部11は、サーバ20に対し、施設IDとともに、プレイスタグの付与を許可する旨の回答を送信する(S207)。S207においては、制御部11は、ボタンB20が選択された旨の回答を送信する。
サーバ20においては、施設IDと回答を受信すると、制御部21は、施設IDが示す施設にプレイスタグを付与する(S208)。S208においては、制御部21は、施設データベースDBのうち、受信した施設IDが格納されたレコードに、処理中のプレイスタグを格納する。これにより、当該プレイスタグをインデックスとして利用可能となる。
一方、S206において、ボタンB21が選択された場合(S206;B21)、制御部11は、サーバ20に対し、プレイスタグの付与を許可しない旨の回答を送信する(S209)。S209においては、制御部11は、ボタンB21が選択された旨の回答を送信する。サーバ20においては、回答を受信すると、S208の処理が実行されず、制御部21は、施設にプレイスタグを付与することなく、S210の処理に移行する。
制御部21は、施設データベースDBに基づいて、全てのプレイスタグについて処理を完了したか否かを判定する(S210)。まだ処理を完了していないプレイスタグが存在する場合(S210;N)、S201の処理に戻り、次のプレイスタグについて処理が実行される。一方、全てのプレイスタグについて処理を完了したと判定された場合(S210;Y)、本処理は終了する。
[4−3.施設検索処理]
図15は、施設検索処理のフロー図である。図15に示す処理は、制御部21,31が、それぞれ記憶部22,32に記憶されたプログラムに従って動作することによって実行される。下記に説明する処理は、図9に示す機能ブロックにより実行される処理の一例である。
図15に示すように、まず、検索者端末30においては、制御部31は、施設検索画面G3を表示部35に表示させる(S300)。S300においては、検索者が操作部34を操作し、ブラウザから施設検索画面G3のURLが指定されたり、所定のアプリケーションが起動されたりすると、施設検索画面G3が表示部35に表示される。
制御部31は、操作部34の検出信号に基づいて、検索者の操作を特定する(S301)。S301においては、入力フォームF30に検索条件を入力する操作、又は、ボタンB31を選択する操作が実行される。
入力フォームF30に検索条件が入力された場合(S301;F30)、制御部31は、当該入力された検索条件を入力フォームF30に表示させる(S302)。S302においては、制御部31は、入力された検索条件を記憶部32に記録する。検索者がプレイスタグを検索条件として入力した場合には、当該プレイスタグを示す文字列が記録されることになる。
一方、ボタンB31が選択された場合(S301;B31)、制御部31は、サーバ20に対し、入力フォームF30に入力された検索条件を送信する(S303)。S303においては、制御部31は、S302で記録した検索条件を送信する。
サーバ20においては、検索条件を受信すると、制御部21は、施設データベースDBに基づいて、施設検索を実行する(S304)。S304においては、制御部21は、受信した検索条件をクエリとし、施設データベースDBに格納された施設情報をインデックスとして、検索を実行する。検索者がプレイスタグを検索条件として入力した場合には、制御部21は、検索者が入力したプレイスタグをクエリとし、施設データベースDBに格納されたプレイスタグをインデックスとして、検索を実行する。
制御部21は、検索者端末30に対し、検索結果を送信する(S305)。S304においては、制御部21は、検索でヒットした施設の施設ID、施設名、及び画像といったデータセットを送信する。
検索者端末30においては、検索結果を受信すると、制御部31は、検索結果画面G4を表示部35に表示させ(S306)、本処理は終了する。以降、検索者が検索結果画面G4の表示領域A41を選択すると、検索者が選択した施設のページが表示されたり、当該施設の予約処理が実行されたりする。ページの表示及び予約処理自体は、公知の処理を適用可能なので、ここでは説明を省略する。
実施形態の施設検索システムSによれば、同じプレイスタグが付与された付与領域A1に、当該プレイスタグが付与されていない他の施設の位置が含まれる場合に、他の施設にプレイスタグが付与され、他の施設がプレイスタグを入力しなくても、プレイスタグをインデックスとした施設検索が実行されるので、検索の精度を向上させることができる。
また、同じプレイスタグが付与された施設群の中で、直近の施設との距離が閾値未満となる施設群の位置に基づいて付与領域A1が設定され、直近の施設との距離が遠い施設の位置が付与領域A1に影響されないので、信頼性の低い施設のせいで、関係性の低い施設までプレイスタグが付与されてしまうことを防止できる。このため、プレイスタグを用いた施設検索の精度を効果的に向上させることができる。
また、同じプレイスタグが付与されたとしても施設群同士が遠い場合には、別のプレイスタグとして扱うことによって、異なるエリアについてたまたま同じ名前のプレイスタグが付与されたとしても、これらを別物として扱うことができる。このため、プレイスタグを用いた施設検索の精度を効果的に向上させることができる。
また、プレイスタグが付与されていない他の施設に対し、プレイスタグの付与を許可するか否かを問い合わせることにより、適切でないプレイスタグが当該他の施設に付与されてしまうことを防止できる。このため、地図や直線的な距離だけでは判別できない条件も考慮したうえで、各施設にプレイスタグを付与することができ、プレイスタグを用いた施設検索の精度を効果的に向上させることができる。
また、同じプレイスタグが付与された施設群の各々の位置を結ぶ多角形に基づいて付与領域A1が設定され、より簡易的な処理で付与領域A1を設定することができるので、サーバ20の処理負荷を軽減することができる。また、プレイスタグを付与する処理を高速化することもできる。更に、プレイスタグが付与された施設群の中心に円を設定し、大まかな付与領域A1を設定するような場合に比べて、付与領域A1の輪郭の形状を細かく設定することで、付与領域A1を適切に設定することができる。
[5.変形例]
なお、本発明は、以上に説明した実施の形態に限定されるものではない。本発明の趣旨を逸脱しない範囲で、適宜変更可能である。
図16は、変形例の機能ブロック図である。図16に示すように、以降説明する変形例では、実施形態で説明した機能に加えて、記録部207、在庫情報取得部208、無効部209、設定部210、及び決定部211が実現される。実施形態と同様、以降説明する変形例では、主な機能がサーバ20で実現される場合を説明するが、後述する変形例のように、施設端末10、サーバ20、及び検索者端末30のうちの少なくとも2つで機能が分担されてもよい。記録部207、在庫情報取得部208、無効部209、設定部210、及び決定部211は、それぞれ記録手段、在庫情報取得手段、無効手段、設定手段、及び決定手段の一例である。
(1)例えば、検索者が検索条件として指定したプレイスタグが付与された施設であっても、施設にとって当該プレイスタグが適切でなければ、検索者は、当該施設のページを閲覧したり当該施設を予約したりしないことがある。このような施設については、検索のスコアを下げたり、検索結果に含めないようにしたりしてもよい。
変形例(1)の施設検索システムSは、記録部207を含む。記録部207は、制御部21を主として実現される。記録部207は、施設検索部206の検索結果に対する検索者の行動を行動情報に記録する。
検索結果に対する検索者の行動とは、検索結果画面G4に対する検索者の操作である。例えば、検索者の行動は、検索結果画面G4に表示された施設を選択すること、施設のページを閲覧すること、又は、施設を利用(予約)することである。
行動情報には、検索結果に対する検索者の行動が示される。例えば、行動情報は、施設の選択状況が示される。選択状況は、検索結果からの選択回数又は選択頻度である。別の言い方をすれば、選択状況は、施設のページの閲覧状況(例えば、いわゆるクリック率)、又は、施設の利用状況(例えば、いわゆるコンバージョン)ということもできる。
行動情報には、少なくとも1人の検索者の行動が示されるようにすればよく、例えば、複数の検索者の全ての行動が示されてもよいし、複数の検索者の一部の行動が示されてもよい。また、行動情報には、過去の全期間の行動が示されてもよいし、直近の所定期間(例えば、数日〜数か月程度)の行動が示されてもよい。
本変形例のデータ記憶部200は、行動情報を記憶する。ここでは、行動情報が施設データベースDBに格納される場合を説明するが、行動情報は、他のデータベースに格納されてもよい。
図17は、変形例(1)の施設データベースDBのデータ格納例を示す図である。図17に示すように、各施設のプレイスタグごとに、行動情報が格納される。複数のプレイスタグが施設に付与されている場合には、これら複数のプレイスタグの各々に関連付けて、行動情報が格納される。即ち、プレイスタグごとに、行動情報が格納される。各行動情報は、当該行動情報が示すプレイスタグに基づく検索結果に対する検索者の行動が示される。
図17のデータ格納例であれば、「レストランA」と「ホテルC」には、「XXXリゾート」というプレイスタグが付与されている。これらの施設には、当該プレイスタグの行動情報が格納されており、「XXXリゾート」を検索条件にした検索者の行動が示されている。例えば、「XXXリゾート」を検索条件にした検索者が、検索結果から「レストランA」や「ホテルC」が選択されたり予約されたりすると、行動情報が更新される。
本変形例の施設検索部206は、行動情報に更に基づいて、施設検索を実行する。即ち、施設検索部206は、各施設に付与されたプレイスタグと、当該プレイスタグに関連付けられた行動情報と、に基づいて、施設検索を実行する。例えば、施設検索部206は、各施設のプレイスタグに関連付けられた行動情報に基づいて、当該施設が検索されることを制限する。
制限とは、施設を検索対象から除外すること、又は、施設を検索対象とするがスコアを低くすることである。検索対象から除外するとは、検索時に施設のインデックスを参照しないこと、又は、インデックスを参照するが検索結果には施設を含めないことを意味する。
スコアは、検索条件に合致する蓋然性である。スコアが高いほど蓋然性が高く、スコアが低いほど蓋然性が低い。即ち、スコアが高いほど検索条件に合致する確率が高く、スコアが低いほど検索条件に合致する確率が低い。スコアの計算方法自体は、種々の手法を適用可能であり、例えば、文字列の一致度に基づいてスコアが計算されてもよいし、Word2vec等により計算される単語ベクトル間の距離によってスコアが計算されてもよい。スコアは、検索結果画面G4における表示順に影響する。例えば、検索結果画面G4では、各施設のスコアに基づいて表示される。例えば、検索結果としてヒットした施設が、スコアの降順となるように表示される。
例えば、施設検索部206は、行動情報が示す選択状況が所定の状況である場合に、プレイスタグに基づく検索を制限する。例えば、施設検索部206は、行動情報が示す選択回数が所定回数未満である場合に、プレイスタグに基づく検索を制限したり、行動情報が示す選択頻度が所定頻度未満である場合に、プレイスタグに基づく検索を制限したりする。
また例えば、施設検索部206は、検索者が入力した検索条件、施設のインデックス、及び行動情報に基づいて、スコアを決定してもよい。例えば、施設検索部206は、検索者が入力した検索条件と、施設のインデックスと、に基づいて、スコアを仮決定し、行動情報が示す選択状況に基づいて、当該仮決定したスコアの最終的な値を決定する。施設検索部206は、行動情報が示す選択回数又は選択頻度が高いほどスコアが高くなり、行動情報が示す選択回数又は選択頻度が低いほどスコアが低くなるように、スコアを決定すればよい。
変形例(1)によれば、プレイスタグを用いた検索結果に対する検索者の行動も考慮したうえで施設検索を実行し、適切でない施設に対してプレイスタグが付与されてしまった場合に検索を制限したりスコアを下げたりすることで、適切なプレイスタグが付与された施設を検索結果に含めることができる。即ち、検索結果からノイズを除去し、施設検索の精度を効果的に向上させることができる。
(2)また例えば、施設検索システムSから施設の予約を可能とする場合には、検索者がプレイスタグを検索条件に指定して検索したとしても、当該プレイスタグが付与された施設の在庫が少ないことがある。この場合、在庫のある施設が所定個数以上見つかるまで、施設を検索する領域を徐々に広げてもよい。
変形例(2)の施設検索システムSは、在庫情報取得部208を含む。在庫情報取得部208は、制御部21を主として実現される。在庫情報取得部208は、各施設の在庫に関する在庫情報を取得する。ここでは、在庫情報が施設データベースDBに格納される場合を説明するが、在庫情報は、他のデータベースに格納されてもよい。
図18は、変形例(2)の施設データベースDBのデータ格納例を示す図である。図18に示すように、施設データベースDBには、施設ごとに、在庫情報が格納される。
在庫とは、施設の予約可能数又は利用可能数である。例えば、施設が宿泊施設であれば、在庫は、部屋の残室数である。施設がレストランであれば、在庫は、レストラン内のテーブル又は座席の残数である。施設が店舗であれば、在庫情報は、商品の在庫数である。施設がレンタカー会社であれば、在庫情報は、車の残台数を示す。施設がバス会社であれば、在庫は、バス内の座席の残席数である。施設が駅であれば、在庫は、列車内の座席の残席数である。施設がツアー会社であれば、在庫は、予約可能な残り人数を示す。在庫情報は、これらの数値を示せばよい。
本変形例の施設検索部206は、各施設の在庫情報に更に基づいて、在庫のある施設を検索し、在庫のある施設が所定個数以上検索されるまで、プレイスタグに基づく検索領域を広げながら施設検索を実行する。所定個数は、固定値であってもよいし、プレイスタグに応じて可変値としてもよい。所定個数を可変とする場合には、プレイスタグが付与された施設数が多いほど個数を多くしてもよい。
検索領域とは、検索対象とする領域である。別の言い方をすれば、検索領域は、検索時にインデックスを参照する施設が位置する領域である。例えば、検索領域は、プレイスタグが付与された施設群のうち、少なくとも1つの施設を含むように設定される。
例えば、施設検索部206は、実施形態で説明した方法と同様にして、検索者が入力したプレイスタグが付与された施設を検索する。そして、施設検索部206は、当該施設の在庫情報を参照し、在庫の有無を判定する。例えば、施設検索部206は、検索でヒットした施設の在庫数が閾値以上であるか否かを判定する。施設検索部206は、在庫数が閾値以上であれば在庫があると判定し、在庫数が閾値未満であれば在庫がないと判定する。この閾値は、1としてもよいし、2以上の数値を設定して在庫がわずかの場合には在庫なしとみなしてもよい。
例えば、施設検索部206は、検索でヒットした施設のうち、在庫がある施設の数が所定個数以上であれば、特に検索領域を設定することなく、検索を終了する。一方、施設検索部206は、検索でヒットした施設のうち、在庫がある施設の数が所定個数未満であれば、検索者が入力したプレイスタグに基づいて、検索領域を設定する。
図19は、変形例(2)において検索領域が設定される様子を示す図である。図19に示すように、施設検索部206は、プレイスタグが付与された施設群の位置に基づいて、検索領域A2を設定する。施設検索部206は、施設群の全ての位置に基づいて検索領域を設定してもよいし、検索群の一部の位置に基づいて検索領域を設定してもよい。
例えば、施設検索部206は、施設FA20〜FA25の位置の平均値を算出し、当該平均値の位置を中心Oとした所定半径の検索領域A2aを設定する。施設検索部206は、検索領域A2aの半径を拡大しながら、在庫がある施設を検索する。
なお、中心Oは、施設群の位置の単純平均であってもよいし、加重平均としてもよい。加重平均とする場合には、施設群の密度に応じて重み付けをしてもよいし、施設の選択回数又は選択頻度に応じて重み付けをしてもよい。また、図19では、検索領域を円形として説明するが、検索領域は、任意の形状であってよい。例えば、検索領域は、三角形や四角形などの多角形であってもよい。
例えば、施設検索部206は、検索領域A2aの半径を所定倍(例えば、1.1倍〜2倍程度)し、検索領域A2bを設定する。そして、施設検索部206は、検索者が入力した検索条件に基づいて、検索領域A2b内の位置の施設を検索する。なお、検索領域A2aの外にある施設は、原則としてプレイスタグが設定されていないので、検索条件からプレイスタグが除外されたうえで検索が実行されてもよい。施設検索部206は、検索でヒットした施設の在庫情報を参照し、在庫の有無を判定する。
例えば、施設検索部206は、検索でヒットした施設のうち、在庫がある施設の数が所定個数以上であれば、特に検索領域を広げることなく、検索を終了する。一方、施設検索部206は、検索でヒットした施設のうち、在庫がある施設の数が所定個数未満であれば、検索領域A2bの半径を広げたうえで、再度検索を実行する。以降、検索領域A2c,A2d・・・といったように、施設検索部206は、在庫がある施設の数が所定個数以上になるまで、検索領域の拡張及び検索の実行を繰り返す。
変形例(2)によれば、在庫のある施設が所定個数以上検索されるまで、プレイスタグに基づく検索範囲を広げながら施設検索をすることで、在庫のある施設を検索結果に含めることができる。例えば、検索範囲内の施設にプレイスタグが付与されていなかったとしても、プレイスタグが付与された施設から近いので、エリアに関係している蓋然性が高い。このような施設も検索対象とすることで、在庫のある施設を検索者に提示することができる。
(3)また例えば、検索者が検索条件として指定したプレイスタグが付与された施設であっても、施設にとって当該プレイスタグが適切でなければ、検索者は、当該施設のページを閲覧したり当該施設を予約したりしないことがある。このような施設については、プレイスタグを無効としてもよい。
変形例(3)の施設検索システムSは、記録部207と無効部209とを含む。記録部207は、変形例(1)で説明した通りである。
無効部209は、制御部21を主として実現される。無効部209は、行動情報に基づいて、各施設に付与されたプレイスタグを無効にする。
無効とは、プレイスタグに基づく検索が実行されないようにすることであり、プレイスタグをインデックスとして参照しないこと、又は、プレイスタグをインデックスから削除することである。例えば、無効部209は、プレイスタグが施設に関連付けられた状態から関連付けられない状態に変化させる。例えば、無効部209は、施設データベースDBに格納されたプレイスタグを削除したり、当該プレイスタグを他のデータベースに退避させたりする。
また例えば、施設データベースDBに、プレイスタグの有効性を示す有効性フラグを格納してもよい。有効性フラグは、プレイスタグが有効であることを示す第1の値、又は、プレイスタグが無効であることを示す第2の値の何れかの値となる。施設検索部206は、検索を実行する際に、有効性フラグが第1の値であるプレイスタグだけをインデックスとして参照する。無効部209は、有効性フラグの値を第1の値から第2の値に変化させることによって、プレイスタグを無効としてもよい。
例えば、無効部209は、行動情報が示す選択状況が所定の状況である場合に、プレイスタグを無効にする。例えば、施設検索部206は、行動情報に基づいて施設ごとにプレイスタグの評価値を計算し、当該評価値が閾値未満である場合にプレイスタグを無効にしてもよい。例えば、施設検索部206は、行動情報が示す選択回数が所定回数未満である場合に、プレイスタグを無効にしたり、行動情報が示す選択頻度が所定頻度未満である場合に、プレイスタグを無効にしたりする。
変形例(3)によれば、プレイスタグを用いた検索結果に対する検索者の行動に基づいて各施設のプレイスタグの有効性を判断し、適切でない施設に対してプレイスタグが付与されてしまった場合に、プレイスタグを無効とすることで、適切なプレイスタグが付与された施設を検索結果に含めることができる。即ち、検索結果からノイズを除去し、施設検索の精度を効果的に向上させることができる。
(4)また例えば、施設から、プレイスタグの付与を許可しない旨の回答が取得された場合には、その施設は、地図上では、プレイスタグが付与された施設に囲まれていたとしても、実際にはプレイスタグを付与するのが適切ではないことがある。このような場合には、当該施設周辺を、プレイスタグを付与しない禁止領域としてもよい。
変形例(4)の施設検索システムSは、設定部210を含む。設定部210は、制御部21を主として実現される。設定部210は、他の施設からプレイスタグの付与を許可しない旨の回答が取得された場合に、当該他の施設の位置に基づいて、当該プレイスタグの付与を禁止する禁止領域を設定する。
禁止領域は、付与領域A1の一部の領域であり、付与領域A1に施設が含まれていたとしてもプレイスタグを付与しない領域である。ここでは、禁止領域を円形として説明するが、禁止領域は、任意の形状であってよい。例えば、禁止領域は、三角形や四角形などの多角形であってもよい。
図20は、禁止領域の説明図である。図20に示す例では、施設FA30〜FA36にプレイスタグが付与されており、施設FA37に対し、プレイスタグの付与を許可するか否かの問い合わせが行われたものとする。そして、施設FA37から、プレイスタグの付与を許可しない旨の回答が送信されたものとする。図20に示すように、設定部210は、プレイスタグの付与を許可しない旨の回答をした施設FA37を含むように、禁止領域A3を設定する。例えば、設定部210は、施設FA37の位置を中心とした所定半径の禁止領域A3を設定する。
本変形例の第2付与部204は、禁止領域A3に基づいて、他の施設にプレイスタグを付与する。第2付与部204は、付与領域A1内であり、かつ、禁止領域A3外である他の施設にプレイスタグを付与することになる。図20の例であれば、施設FA38,FA39のうち、施設FA38は禁止領域A3内にあるので、プレイスタグの付与を許可するか否かを問い合わせることなく、プレイスタグが付与されない。一方、施設FA39は、付与領域A1内にあり、かつ、禁止領域A3外にあるので、プレイスタグの付与を許可するか否かが問い合わせられたうえで、プレイスタグが付与される。
変形例(4)によれば、プレイスタグの付与を許可しない旨の回答が取得された場合に禁止領域A3が設定され、より適切な付与領域A1を設定することができる。例えば、「YYY花火大会」といったプレイスタグが付与された場合に、距離的には近くても実際には花火が見えない施設の周辺に禁止領域A3が設定されるので、適切でないプレイスタグが施設に付与されることを防止し、プレイスタグの信頼性を高めることができる。また、不要な問い合わせが施設に送信されることも防止できる。このため、サーバ20の処理負荷及びネットワークNの通信負荷を軽減することができる。
(5)また例えば、プレイスタグが示すエリアによっては、より大きな他のエリアが重複していたり、より小さな他のエリアが重複していたりすることがある。複数のエリアの各々が重複する面積が小さければ、当該複数のエリアは関連性が低いと推測されるが、当該面積が大きければ、当該複数のエリアは関連性が高いと推測される。このため、複数のエリアの各々が重複する面積が大きい場合に、各エリアのプレイスタグに上下関係を設けておき、プレイスタグが階層構造を有するようにしてもよい。
変形例(5)の施設検索システムSは、決定部211を含む。決定部211は、制御部21を主として実現される。決定部211は、複数のプレイスタグに基づいて定まる複数の領域が互いに重なる場合に、当該複数の領域の重なり方に基づいて、当該複数のプレイスタグの各々の上下関係を決定する。
プレイスタグに基づいて定まる領域とは、プレイスタグが付与された施設群の位置に基づいて定まる領域であり、ここでは、付与領域A1と同じである場合を説明するが、付与領域A1とは異なる領域であってもよい。付与領域A1とは異なる領域の場合には、施設群に含まれる少なくとも1つの施設の位置を含む領域であればよく、例えば、施設群の中心点又は重心点を中心とした円であってもよいし、当該中心点又は重心点を含む多角形であってもよい。
重なり方とは、複数の領域の各々の重複部分のサイズである。サイズは、重複部分の面積であってもよいし、幅であってもよい。上下関係は、上位と下位の関係であり、親子関係又は階層関係ということもできる。上下関係のあるプレイスタグは、互いに同じ地域を示すが、地域のサイズが異なっている。
例えば、上位のプレイスタグが示す地域は、下位のプレイスタグが示す地域よりも広い。上位のプレイスタグが示す地域は、下位のプレイスタグが示す地域を全て含んでいてもよいし、一部だけを含んでいてもよい。ただし、上位のプレイスタグが示す地域は、下位のプレイスタグが示す地域を少なくとも所定割合(例えば、50%〜80%)以上含むものとする。
なお、上位のプレイスタグが示す地域と、下位のプレイスタグが示す地域と、の位置は全く同じであってもよいが、微妙にずれていてもよい。ただし、これらの位置が大きくずれていると、関連性が低くなるので、これらの距離は所定距離(例えば、数十メートル〜数キロメートル)未満としてもよい。
例えば、決定部211は、複数のプレイスタグの各々に基づく付与領域A1の重複部分のサイズが閾値以上である場合に、当該複数のプレイスタグに上下関係を設け、当該サイズが閾値未満である場合に、当該複数のプレイスタグに上下関係を設けない。
図21は、上下関係を有するプレイスタグの一例を示す図である。図21の例では、施設FA40〜FA55に、第1のプレイスタグである「XYZシティ」が付与されており、施設FA52,FA56〜FA63に、第2のプレイスタグである「ZZZアウトレット」が付与されているものとする。図21に示すように、第1のプレイスタグ「XYZシティ」に基づく付与領域A1aと、第2のプレイスタグ「ZZZアウトレット」に基づく付与領域A1bと、は重なっている。
例えば、決定部211は、付与領域A1aと付与領域A1bの重複部分のサイズが閾値以上であるか否かを判定する。閾値は、固定値であってもよいし、プレイスタグが付与された施設数等に応じた可変値であってもよい。また、閾値は、絶対的なサイズであってもよいし、付与領域のサイズに応じた相対的なサイズであってもよい。相対的なサイズとは、例えば、付与領域のサイズに対する割合である。なお、サイズは、付与領域の面積を意味してもよいし、付与領域の幅又は外周の長さを意味してもよい。
ここでは、決定部211は、上記重複部分が、付与領域A1a,A1bの少なくとも一方の所定割合以上を占めるか否かを判定する場合を一例として説明する。図21の例では、重複部分は、付与領域A1bの所定割合以上を占めているので、決定部211は、第1のプレイスタグ「XYZシティ」と第2のプレイスタグ「ZZZアウトレット」に上下関係があると判定する。
上下関係の決定方法は、任意であってよく、例えば、サイズが大きい方を上位とし、サイズが小さい方を下位としてもよい。また例えば、プレイスタグが付与された施設数が多い方を上位とし、施設数が少ない方を下位としてもよい。また例えば、検索者による選択回数又は選択頻度が多い方を上位とし、選択回数又は選択頻度が少ない方を下位としてもよい。
ここでは、決定部211は、付与領域のサイズが大きな第1のプレイスタグ「XYZシティ」を上位とし、付与領域のサイズが小さな第2のプレイスタグ「ZZZアウトレット」を下位とする場合を一例として説明する。例えば、決定部211は、付与領域A1aのサイズと、付与領域A1bのサイズと、を計算し、これらのサイズを比較することによって、上下関係を決定する。
なお、プレイスタグに上下関係が存在するか否かを判定する方法は、上記の例に限られない。例えば、また例えば、決定部211は、プレイスタグが付与された施設群の数に基づいて、上下関係が存在するか否かを判定してもよい。例えば、決定部211は、プレイスタグが付与された施設群のうち、重複部分に含まれている施設の割合が所定割合以上である場合に、上下関係が存在すると判定し、当該割合が所定割合未満である場合に、上下関係が存在しないと判定してもよい。
また、下位のプレイスタグは、少なくとも1つの上位のプレイスタグを持つことが可能であり、上位のプレイスタグを1つだけ持ってもよいし、複数の上位のプレイスタグを持ってもよい。同様に、上位のプレイスタグは、少なくとも1つの下位のプレイスタグを持つことが可能であり、下位のプレイスタグを1つだけ持ってもよいし、複数の下位のプレイスタグを持ってもよい。
施設検索部206は、決定部211により決定された上下関係に更に基づいて、施設検索を実行する。例えば、施設検索部206は、施設検索画面G3において、上下関係を有するプレイスタグを選択可能に表示させてもよい。この場合、プレイスタグをツリー上に表示させてもよい。施設検索画面G3に表示されたプレイスタグを、検索者に次々と選択させることによって、エリアの絞り込みをさせるようにしてもよい。
また例えば、施設検索部206は、検索条件にヒットした施設の数が所定個数以上である場合に、下位のプレイスタグに基づいて施設の絞り込みを実行してもよい。これとは逆に、施設検索部206は、検索条件にヒットした施設の数が所定個数未満である場合に、上位のプレイスタグに基づいて、検索条件を緩和して、検索結果に含める施設を多くしてもよい。
変形例(5)によれば、プレイスタグに上下関係を設けることで、施設検索の精度を効果的に向上させることができる。また、互いに関連性のあるプレイスタグに上下関係を設けることで、プレイスタグの管理を用意にすることができる。
(6)また例えば、上記変形例を組み合わせてもよい。
また例えば、付与領域A1の設定方法は、実施形態及び変形例で説明した方法に限られない。例えば、実施形態で図11を参照して説明したように、プレイスタグが付与された施設の位置を結ぶ三角形を利用して付与領域が設定される場合、任意の三角形分割方法を適用可能であり、図11以外の方法を利用してもよい。例えば、ドロネーの三角形分割のアルゴリズムを利用してもよい。他にも例えば、下記に説明する3つのパターン(以降、パターン1−3と記載する)によって付与領域A1が設定されてもよい。
図22−図23は、パターン1によって付与領域A1が設定される様子を示す図である。パターン1では、第2付与部204は、プレイスタグが付与された施設ごとに、1番目に距離が近い他の施設と、2番目に距離が近い他の施設と、を特定し、これらの間を線で結ぶ。そして、第2付与部204は、これらの線のうち外側にある線を特定し、当該特定した線で囲われた領域を付与領域A1として設定してもよい。この場合、付与領域A1の外縁(外周)が特定される。
図22の例であれば、第2付与部204は、施設FA70から1番目に距離が近い施設FA71と、施設FA70から2番目に距離が近い施設FA72と、を特定し、施設FA70,FA71を結ぶ線と、施設FA70,FA72を結ぶ線と、を設定する。そして、第2付与部204は、施設FA71から1番目に距離が近い施設FA73と、施設FA71から2番目に距離が近い施設FA72と、を特定し、施設FA71,FA73を結ぶ線と、施設FA71,FA72を結ぶ線と、を設定する。
以降同様にして、第2付与部204は、施設FA73,FA71を結ぶ線、施設FA73,FA74を結ぶ線、施設FA74,FA73を結ぶ線、施設FA74,FA72を結ぶ線、施設FA75,FA72を結ぶ線、及び施設FA75,FA74を結ぶ線を設定する。付与領域A1は、これらの線のうち外側にある線で囲われた領域(施設FA70,FA71,FA73,FA74,FA75,FA72,FA70の順でつないだ線によって囲われた領域)となる。
図23の例であれば、第2付与部204は、施設FA80から1番目に距離が近い施設FA81と、施設FA80から2番目に距離が近い施設FA82と、を特定し、施設FA80,FA81を結ぶ線と、施設FA80,FA82を結ぶ線と、を設定する。そして、第2付与部204は、施設FA81から1番目に距離が近い施設FA83と、施設FA81から2番目に距離が近い施設FA80と、を特定し、施設FA81,FA83を結ぶ線と、施設FA81,FA80を結ぶ線と、を設定する。
以降同様にして、第2付与部204は、施設FA82,FA81を結ぶ線、施設FA82,FA84を結ぶ線、施設FA83,FA81を結ぶ線、施設FA83,FA82を結ぶ線、施設FA84,FA82を結ぶ線、施設FA84,FA85を結ぶ線、施設FA85,FA84、及び施設FA85,FA82を結ぶ線を設定する。付与領域A1は、これらの線のうち外側にある線で囲われた領域(施設FA80,FA81,FA83,FA82,FA84,FA85,FA82,FA80の順でつないだ線によって囲われた領域)となる。即ち、付与領域A1は、複数の領域を含むようにしてもよい。
図24−図25は、パターン2によって付与領域A1が設定される様子を示す図である。なお、図24の施設の配置は、図22と同じであり、図25の施設の配置は、図23と同じである。パターン2では、第2付与部204は、プレイスタグが付与された施設ごとに、1番目に距離が近い施設と、2番目に距離が近い施設と、を特定し、これら3つの施設の間で三角形を設定する。そして、第2付与部204は、各施設の三角形を連結したり重ね合せたりした領域を、付与領域A1として設定してもよい。なお、パターン2では、必ずしも、施設は、付与領域A1の頂点とはならないこともある。
図24の例であれば、第2付与部204は、施設FA70、施設FA70から1番目に距離が近い施設FA71、及び、施設FA70から2番目に距離が近い施設FA72を結ぶ三角形を設定する。第2付与部204は、施設FA71、施設FA71から1番目に距離が近い施設FA73、及び、施設FA71から2番目に距離が近い施設FA72を結ぶ三角形を設定する。
以降同様にして、第2付与部204は、施設FA72,FA71,FA70を結ぶ三角形、施設FA73,FA71,FA74を結ぶ三角形、施設FA74,FA73,FA72を結ぶ三角形、及び、施設FA75,FA72,FA74を結ぶ三角形を設定する。付与領域A1は、これらの三角形を連結したり重ね合せたりした領域となり、図24の付与領域A1は、図22と同じとなる。
一方、図25の例であれば、第2付与部204は、施設FA80、施設FA80から1番目に距離が近い施設FA81、及び、施設FA80から2番目に距離が近い施設FA82を結ぶ三角形を設定する。第2付与部204は、施設FA81、施設FA81から1番目に距離が近い施設FA80、及び、施設FA81から2番目に距離が近い施設FA83を結ぶ三角形を設定する。
以降同様にして、第2付与部204は、施設FA82,FA81,FA84を結ぶ三角形、施設FA83,FA81,FA82を結ぶ三角形、施設FA84,FA85,FA82を結ぶ三角形、及び、施設FA85,FA84,FA82を結ぶ三角形を設定する。付与領域A1は、これらの三角形を連結したり重ね合せたりした領域となり、図25の付与領域A1は、図23とは異なる領域(施設FA80,FA81,FA83、交点P、施設FA84,FA85,FA82の順でつないだ線によって囲われた領域)となる。即ち、図25の付与領域A1は、図23の付与領域A1よりも、交点Pと、施設FA82,FA84と、を結ぶ三角形の分だけ広い領域となる。
図26は、パターン3によって付与領域A1が設定される様子を示す図である。図26に示すように、例えば、第2付与部204は、プレイスタグが付与された各施設を結ぶことによって、付与領域A1を設定してもよい。例えば、第2付与部204は、全ての施設を結んでもよいし、互いに所定距離以内にある施設同士を結んでもよい。パターン3では、付与領域A1の外縁(外周)が特定される。
図26の例であれば、各施設の配置は図22,24と同じであるが、付与領域A1は、図22,図24とは異なる領域(施設FA70,FA71,FA73,FA74,FA75,FA70の順でつないだ線によって囲われた領域)となる。即ち、図26の付与領域A1は、図22,24の付与領域A1よりも、施設FA70,FA72,FA75を結ぶ三角形の分だけ広い領域となる。
また例えば、付与領域A1は、定期的に設定し直されるようにしてもよい。例えば、所定のタイミング(例えば、1週間ごと)が訪れた場合に上記説明した処理が再度実行され、付与領域A1が再設定されてもよい。
また例えば、プレイスタグが新たに付与された施設が、付与領域A1の外側、かつ、直近の施設から所定距離以内に位置する場合には、当該施設にプレイスタグが付与された後に、サーバ20の処理負荷が低い時間帯が到来したタイミングで、上記の処理が再度実行され、付与領域A1が再設定されてもよい。処理負荷としては、コンピュータの負荷に関する情報であればよく、例えば、CPU使用率、メモリ使用率、又は単位時間当たりの通信量等である。これらの取得方法自体は、公知の種々の手法を適用可能であり、例えば、所定のコマンド(例えば、topコマンド)を利用してCPU使用率やメモリ使用率が取得されてもよいし、単位時間当たりのデータ受信量が計測されることで通信量が取得されてもよい。第2付与部204は、サーバ20の処理負荷が閾値以上であるか否かを判定し、処理負荷が閾値以上である場合には、付与領域A1を再設定する処理を実行せず、処理負荷が閾値未満である場合に、付与領域A1を再設定する処理を実行する。このようにすることで、サーバ20の処理負荷を軽減することができる。
また例えば、第2付与部204は、付与領域A1全体を作り直してもよいし、既存の付与領域A1に対して領域を追加することによって、付与領域A1を再設定してもよい。例えば、図24又は図25のように三角形を利用して付与領域A1が設定される場合には、第2付与部204は、既存の三角形の一辺と交わらないように、プレイスタグが新たに付与された施設を頂点とし、距離の近い2つの施設を選択して三角形を特定し、特定した三角形を付与領域A1に追加してもよい。このようにすることで、付与領域A1全体を作り直す場合に比べて、付与領域A1の再設定を簡易な処理によって実現できる。このため、付与領域A1を設定する処理を高速化しつつ、サーバ20の処理負荷を軽減することができる。
図27は、付与領域A1に新たな領域が追加される様子を示す図である。図27の例では、プレイスタグが付与された施設FA90,FA91,FA92によって付与領域A1が設定されていたとする。この場合に、プレイスタグが付与された施設FA93が新たに追加されたとすると、施設FA93から距離が近い施設は、FA90とFA91であるが、施設FA93,FA90,FA91を結ぶ三角形は、既存の三角形と交差するので、第2付与部204は、施設FA91は三角形の設定から除外し、施設FA93,FA90,FA92を結ぶ三角形を既存の付与領域A1に追加し、新たな付与領域A1としてもよい。
また例えば、施設端末10、サーバ20、及び検索者端末30の各々で機能が分担されてもよい。また例えば、第1付与部201が、施設端末10において実現されてもよい。この場合、第1付与部201は、制御部11を主として実現される。施設端末10の第1付与部201は、施設IDとプレイスタグのデータセットをサーバ20に送信し、サーバ20は、受信したデータセットを施設データベースDBに格納してもよい。また例えば、第1付与部201は、検索者端末30において実現されてもよい。この場合、第1付与部201は、制御部31を主として実現される。検索者端末30の第1付与部201は、操作部34の検出信号に基づいて、検索者により入力されたプレイスタグを取得し、施設IDとプレイスタグのデータセットをサーバ20に送信し、サーバ20は、受信したデータセットを施設データベースDBに格納してもよい。
また例えば、問い合わせ部202及び回答取得部203が施設端末10において実現されてもよい。この場合、問い合わせ部202及び回答取得部203は、制御部11を主として実現される。例えば、問い合わせ部202は、問い合わせ画面G2を表示部15に表示させ、回答取得部203は、操作部14の検出信号に基づいて回答を取得し、サーバ20に回答を送信してもよい。
また例えば、第2付与部204が施設端末10において実現されてもよい。この場合、第2付与部204は、制御部11を主として実現される。施設端末10の第2付与部201は、施設IDとプレイスタグのデータセットをサーバ20に送信し、サーバ20は、受信したデータセットを施設データベースDBに格納してもよい。また例えば、第2付与部204は、検索者端末30において実現されてもよい。この場合、第2付与部204は、制御部31を主として実現される。検索者端末30の第2付与部204は、操作部34の検出信号に基づいて、検索者により入力されたプレイスタグを取得し、施設IDとプレイスタグのデータセットをサーバ20に送信し、サーバ20は、受信したデータセットを施設データベースDBに格納してもよい。
また例えば、データ記憶部200で記憶されるものとして説明したデータは、サーバ20とは異なるデータベースサーバによって記憶されてもよいし、施設検索システムSの外部にあるデータベースサーバによって記憶されていてもよい。