JP6666521B2 - 場所人気度推定システム - Google Patents

Description

本発明は、場所の人気度を推定する場所人気度推定システムに関する。

特許文献１に記載されているように、従来から、レストラン等の施設の人気度をはかってランク付けすることが提案されている。特許文献１においては、ランクは、対象地域が区切られたブロックの人数に基づいて設定されるとされている。また、インターネットのホームページ又は掲示板に、レストランの名前が記述されている場合、レストランが存在する位置のランクを更新するとされている。

特開２００７−１５６６３７号公報

移動通信端末が在圏している基地局又はＧＰＳ（グローバル・ポジショニング・システム）等から抽出できるユーザの位置を示す位置情報のデータと、マイクロブログ等のユーザによって投稿されたデータとを用いて施設の人気度を推定することを考える。推定したい人気度は、ユーザが訪れる施設としてどのくらい人気があるか、即ち、どの程度の数のユーザが施設を訪れているかを示すものである。

上記の位置情報のデータは、通常、誤差が含まれるため、ある程度の範囲の情報、例えば、メッシュ単位の人数の情報しか抽出することができない。従って、位置情報のデータから、ユーザがどの施設に実際に訪れたかを把握することは困難である。そこで、特許文献１に示されているように、ユーザによって投稿されたデータを用いて、メッシュ単位の人数を補正して、施設の人気度を推定することが考えられる。例えば、投稿されたデータであるテキストのうち、当該施設の名称が記載されているテキストを施設毎にカウントし、当該テキストの数が多い施設ほど人気のある施設であると推定することが考えらえる。

しかしながら、上記の方法では、訪問されていない施設の名称がテキストに記載されていた場合であっても、当該施設の人気度が高くなってしまう。例えば、事故又は事件のニュース等に施設が取り上げられると、当該施設の名称が記載されたテキストの数が膨大になることがある。このような場合、適切に施設の人気度を推定することができない。

本発明は、上記に鑑みてなされたものであり、ユーザの訪問を考慮して、施設等の場所の人気度を適切に推定することができる場所人気度推定システムを提供することを目的とする。

上記の目的を達成するために、本発明の一実施形態に係る場所人気度推定システムは、場所の人気度を推定する場所人気度推定システムであって、ユーザから投稿された投稿データを取得する投稿データ取得部と、投稿データ取得部によって取得された投稿データが、推定対象の場所に係るものであると共に当該投稿データを投稿したユーザが当該推定対象の場所を訪問したことを示すものであるかを判定する投稿データ判定部と、投稿データ判定部による判定に応じて、推定対象の場所について投稿データをカウントするカウント部と、推定対象の場所を含む領域に位置している人数を示す人数情報を取得する人数情報取得部と、カウント部によってカウントされた値、及び人数情報取得部によって取得された人数情報によって示される人数に基づいて、推定対象の場所の人気度を推定する人気度推定部と、人気度推定部によって推定された人気度を示す情報を出力する出力部と、を備える。

本発明の一実施形態に係る場所人気度推定システムでは、投稿データについて、推定対象の場所に係るものであるか、及び当該投稿データを投稿したユーザが当該推定対象の場所を訪問したことを示すものであるかの判定が行われる。当該判定に応じた投稿データがカウントされ、カウントされた値、及び人数情報に基づいて、推定対象の場所の人気度が推定される。従って、投稿データが、人気度の推定の上で適切に考慮される。即ち、本発明の一実施形態に係る場所人気度推定システムによれば、ユーザの訪問を考慮して、施設等の場所の人気度を適切に推定することができる。

本発明の一実施形態によれば、投稿データが、人気度の推定の上で適切に考慮されるため、ユーザの訪問を考慮して、施設等の場所の人気度を適切に推定することができる。

本発明の実施形態に係る場所人気度推定システムであるサーバの構成を示す図である。 マイクロブログ管理テーブルを示す図である。 施設情報管理テーブルを示す図である。 訪問ルール形態素管理テーブルを示す図である。 施設とマイクロブログ紐付け管理テーブルを示す図である。 メッシュ統計人口管理テーブルを示す図である。 施設スコア管理テーブルを示す図である。 本発明の実施形態に係る場所人気度推定システムであるサーバで実行される処理全体を示すフローチャートである。 本発明の実施形態に係る場所人気度推定システムであるサーバで実行される処理のうち、判定及びカウントの処理を示すフローチャートである。 本発明の実施形態に係る場所人気度推定システムであるサーバのハードウェア構成を示す図である。

以下、図面と共に本発明に係る場所人気度推定システムの実施形態について詳細に説明する。なお、図面の説明においては同一要素には同一符号を付し、重複する説明を省略する。

図１に本実施形態に係る場所人気度推定システムであるサーバ１０を示す。サーバ１０は、場所の人気度を推定するシステム（装置）である。本実施形態において、人気度の推定対象となる場所は、店舗、レジャー施設及び観光施設といった施設である。なお、人気度の推定対象となる場所は、位置を特定することができる任意の場所であればよく、施設以外の場所、例えば、施設以外の観光地及びＰＯＩ（Point of Interest）等であってもよい。人気度は、ユーザが訪れる施設としてどのくらい人気があるか、即ち、どの程度の数のユーザが施設を訪れているかを示すものである。推定される人気度は、例えば、施設の情報をユーザに提供する際に利用され得る。具体的には、施設の人気度のランクに基づいて、ユーザによって施設の情報の検索が行われる場合に人気度の高い施設を上位に表示したり、近隣のユーザに人気度の高い施設をレコメンドしたりすることができる。

サーバ１０は、インターネット等のネットワークに接続されており、他の装置との間で通信を行うことができる。サーバ１０は、他の装置との間で、施設の人気度の推定に用いる情報を送受信する。どのような装置と、どのような情報をやり取りするのかは後述する。

引き続いて、本実施形態に係るサーバ１０の機能を説明する。図１に示すようにサーバ１０は、記憶部１１と、投稿データ取得部１２と、投稿データ判定部１３と、カウント部１４と、人数情報取得部１５と、人気度推定部１６と、出力部１７とを備えて構成される。

記憶部１１は、サーバ１０における処理に必要となる情報を記憶する機能部である。記憶部１１が、どのような情報を記憶するかについては後述する。

投稿データ取得部１２は、ユーザから投稿された投稿データを取得する機能部である。投稿データ取得部１２によって取得される投稿データは、例えば、不特定多数のユーザの移動通信端末であるユーザ端末からマイクロブログに投稿（発信）されたテキストを含むデータである。投稿データは、当該テキストが投稿された位置を示す位置情報、即ち、ジオタグを含み得る。位置情報は、例えば、当該テキストが投稿された際のユーザ端末の位置を示す情報である。位置情報は、例えば、ユーザ端末においてＧＰＳ機能によって取得されるユーザ端末の位置の緯度及び経度を示す情報である。なお、マイクロブログのサービスは、マイクロブログサーバによって提供される。

記憶部１１は、投稿データを記憶する。記憶部１１は、投稿データをマイクロブログ管理テーブルで保持する。図２にマイクロブログ管理テーブルを示す。１つの行（レコード）が、１つの投稿データについての情報である。図２に示すようにマイクロブログ管理テーブルは、ｔｅｘｔ＿ｉｄ、ｕｓｅｒ＿ｉｄ、ｔｉｍｅ＿ｓｔａｍｐ、ｌａｔ、ｌｎｇ及びｔｅｘｔの欄に、それぞれ対応付けられた情報を格納する。ｔｅｘｔ＿ｉｄの欄に格納される情報は、投稿されたテキスト（投稿データ）を識別する識別子である。ｕｓｅｒ＿ｉｄの欄に格納される情報は、テキストを投稿したユーザを識別する識別子である。当該識別子は、例えば、マイクロブログにおいてユーザの識別に用いられる識別子である。ｔｉｍｅ＿ｓｔａｍｐの欄に格納される情報は、テキストが投稿された時刻、具体的には、テキストが投稿された年月日、時間、分及び秒を示す情報である。

ｌａｔ及びｌｎｇの欄に格納される情報は、テキストが投稿された位置を示す位置情報であり、具体的には、それぞれ緯度及び経度を示す情報である。投稿が行われる際の設定等によって、位置情報は投稿データに含まれない場合がある。例えば、図２に示すマイクロブログ管理テーブルの２行目及び４行目の投稿データには、位置情報が含まれない。ｔｅｘｔの欄に格納される情報は、投稿されたテキスト（文字列）である。本実施形態では、投稿されたテキストは日本語である場合の例を示すが、日本語以外であっても本実施形態と同様に本発明の位置実施形態を実施することができる。

マイクロブログ管理テーブルに格納される投稿データは、予め、サーバ１０によってマイクロブログサーバから取得されている。あるいは、当該情報は、予め、サーバ１０の管理者等によって、マイクロブログサーバから取得されてサーバ１０に入力されていてもよい。

投稿データ取得部１２は、マイクロブログ管理テーブルに格納される複数の投稿データを読み出して取得する。投稿データ取得部１２は、テキストが投稿された時刻が、予め設定した時間帯、例えば後述する人数情報に対応する時間帯である投稿データのみを取得することとしてもよい。また、投稿データ取得部１２は、マイクロブログサーバに投稿データを要求して、マイクロブログサーバから投稿データを受信して取得してもよい。投稿データ取得部１２は、取得した投稿データを投稿データ判定部１３に出力する。

投稿データ判定部１３は、投稿データ取得部１２によって取得された投稿データが、推定対象の施設に係るものであると共に当該投稿データを投稿したユーザが当該推定対象の施設を訪問したことを示すものであるかを判定する機能部である。投稿データが推定対象の施設に係るものであるとは、例えば、投稿データのテキストが当該施設について記載されたものであることである。投稿データ判定部１３は、投稿データに含まれるテキストに推定対象の施設に応じた記載が含まれているか否かを判定して、投稿データが推定対象の施設に係るものであるか否かを判定することとしてもよい。

投稿データ判定部１３は、投稿データに含まれるテキストに基づいて、当該投稿データを投稿したユーザが推定対象の施設を訪問したことを示すものであるかを判定することとしてもよい。あるいは、投稿データ判定部１３は、投稿データに含まれる位置情報に基づいて、当該投稿データを投稿したユーザが推定対象の施設を訪問したことを示すものであるかを判定することとしてもよい。

記憶部１１は、当該判定に用いられる情報を記憶する。記憶部１１は、当該情報を施設情報管理テーブル及び訪問ルール形態素管理テーブルで保持する。図３に施設情報管理テーブルを示す。施設情報管理テーブルは、推定対象の施設についての情報を保持するテーブルである。１つの行（レコード）が、１つの施設についての情報である。

図３に示すように施設情報管理テーブルは、施設名称、ｍｅｓｈ＿ｃｏｄｅ、ｌａｔ及びｌｎｇの欄に、それぞれ対応付けられた情報を格納する。施設名称の欄に格納される情報は、施設の施設名称である文字列である。ｍｅｓｈ＿ｃｏｄｅの欄に格納される情報は、当該施設の位置を含むメッシュを識別する識別子である。メッシュは、施設が設けられる地域を分割したものである。各メッシュは、例えば、一辺が数十ｍ〜数百ｍ程度の矩形である。例えば、図３に示す施設情報管理テーブルの４つの施設に係る情報は、全て同じメッシュ内に位置している。ｌａｔ及びｌｎｇの欄に格納される情報は、施設の位置を示す位置情報であり、具体的には、それぞれ緯度及び経度を示す情報である。

図４に訪問ルール形態素管理テーブルを示す。訪問ルール形態素管理テーブルは、投稿データを投稿したユーザが推定対象の施設を訪問したことを示すものであるかの判定に用いる情報を保持するテーブルである。図４に示すように訪問ルール形態素管理テーブルは、ｉｄ及び訪問ルール形態素の欄に、それぞれ対応付けられた情報を格納する。ｉｄの欄に格納される情報は、訪問ルール形態素管理テーブルに格納される各情報を識別する識別子である。訪問ルール形態素の欄に格納される情報は、上記の判定に用いられる形態素である文字列である。当該文字列は、ユーザの施設への訪問を示しているもの、例えば、図４に示すように「行く」「来る」「訪れる」「いる」等のものである。施設情報管理テーブル及び訪問ルール形態素管理テーブルに保持される情報は、予め、サーバ１０の管理者等によって、サーバ１０に入力されている。

投稿データ判定部１３は、以下のように判定を行う。投稿データ判定部１３は、投稿データ取得部１２から投稿データを入力する。また、投稿データ判定部１３は、施設情報管理テーブル及び訪問ルール形態素管理テーブルに保持される情報を読み出す。投稿データ判定部１３は、入力した投稿データ毎に判定を行う。投稿データ判定部１３は、投稿データに含まれるテキストについて形態素解析を行う。形態素解析は、従来の任意の方法を利用して行われる。形態素解析においては、各形態素の時制が現在にされてもよい。

投稿データ判定部１３は、形態素解析によって得られた各形態素について、施設名称と一致するものがあるか判断する。この一致の判断は、全ての施設の施設名称に対して行われる。投稿データ判定部１３は、何れかの形態素と施設名称が一致したと判断した場合、投稿データが当該施設名称の施設に係るものであると判定する。即ち、テキストの中に施設名称が含まれていれば、投稿データが当該施設名称の施設に係るものであると判定される。投稿データ判定部１３は、何れの形態素も施設名称と一致しないと判断した場合、投稿データが何れか施設に係るものでないと判定する。

投稿データ判定部１３は、投稿データが何れかの施設に係るものであると判定した場合、引き続いて、当該投稿データに位置情報が含まれているか（付与されているか）を判断する。投稿データ判定部１３は、投稿データに位置情報が含まれていると判断した場合、当該位置情報によって示される位置が、投稿データに係るとされた施設のメッシュ内であるか否かを判断する。投稿データ判定部１３は、予め緯度及び経度とメッシュとの対応関係を記憶しており、当該対応関係に基づいて上記の判断を行う。

投稿データ判定部１３は、投稿データに含まれる位置情報によって示される位置が、施設のメッシュ内であると判断した場合、当該投稿データが、当該投稿データを投稿したユーザが当該施設を訪問したことを示すものであると判定する。即ち、投稿データ判定部１３は、この場合、当該投稿データについて訪問フラグ有と判定（分類）する。当該判定は、施設に係る投稿を行っており、投稿された位置が施設のメッシュ内であった場合、ユーザが当該施設を訪問している蓋然性があることに基づいている。投稿データ判定部１３は、投稿データに含まれる位置情報によって示される位置が、施設のメッシュ内ではないと判断した場合、当該投稿データが、当該投稿データを投稿したユーザが当該施設を訪問したことを示すものであると判定しない。即ち、投稿データ判定部１３は、この場合、当該投稿データについて訪問フラグ無と判定（分類）する。

なお、上記の判定は、投稿データに係る位置が施設のメッシュ内であるか否かを判定するものであったが、例えば以下のように、投稿データに係る位置と施設の位置との距離に基づく判断を行うこととしてもよい。投稿データ判定部１３は、投稿データに係る位置を示す緯度及び経度と、施設情報管理テーブルに含まれている施設の位置を示す緯度及び経度との距離を算出する。投稿データ判定部１３は、算出した距離と予め設定した閾値（例えば、数ｍ〜数十ｍ）とを比較する。投稿データ判定部１３は、比較によって、距離が閾値以下であると判断した場合、当該投稿データについて訪問フラグ有と判定（分類）する。投稿データ判定部１３は、比較によって、距離が閾値以下でないと判断した場合、当該投稿データについて訪問フラグ無と判定（分類）する。

投稿データ判定部１３は、投稿データに位置情報が含まれていないと判断した場合、形態素解析によって得られた各形態素について、訪問ルール形態素と一致するものがあるか判断する。この一致の判断は、全ての訪問ルール形態素に対して行われる。投稿データ判定部１３は、何れかの形態素と訪問ルール形態素が一致したと判断した場合、当該投稿データが、当該投稿データを投稿したユーザが当該施設を訪問したことを示すものであると判定する。即ち、投稿データ判定部１３は、この場合、当該投稿データについて訪問フラグ有と判定（分類）する。当該判定は、施設に係る投稿を行っており、投稿されたテキストに施設への訪問を示す文字列が含まれていた場合、ユーザが当該施設を訪問している蓋然性があることに基づいている。投稿データ判定部１３は、何れの形態素も訪問ルール形態素と一致しないと判断した場合、当該投稿データが、当該投稿データを投稿したユーザが当該施設を訪問したことを示すものであると判定しない。即ち、投稿データ判定部１３は、この場合、当該投稿データについて訪問フラグ無と判定（分類）する。

図２に示す投稿データについての上記の判定の例を示す。ｔｅｘｔ＿ｉｄが「ｔｅｘｔＩＤ＿０００１」（図２のマイクロブログ管理テーブルの１行目の投稿データ）の投稿データについてのテキストは、形態素解析により「Ａ／の／サービス／素晴らしい」となる（「／」が形態素の区切りを示す）。これらの形態素の中に、施設名称である形態素「Ａ」が存在する。当該投稿データには位置情報が含まれるため、当該位置情報（１３９．０１，３５．０１）によって示される位置が施設名称「Ａ」の施設のメッシュ「ｍｅｓｈ＿Ａ」内か否かが判断される。当該位置がメッシュ内であるので、当該投稿データが、施設名称「Ａ」の施設に係るものであると共に訪問フラグ有と判定される。

ｔｅｘｔ＿ｉｄが「ｔｅｘｔＩＤ＿０００２」（図２のマイクロブログ管理テーブルの２行目の投稿データ）の投稿データについてのテキストは、形態素解析により「東京／観光／で／Ａ／に／初めて／来る／！／展望台／から／の／眺め／が／すごい／！」となる。これらの形態素の中に、施設名称である形態素「Ａ」が存在する。当該投稿データには位置情報が含まれないため、形態素の中に、訪問ルール形態素と一致する形態素が存在するか否かが判断される。これらの形態素の中に、訪問ルール形態素である形態素「来る」が存在する。従って、当該投稿データが、施設名称「Ａ」の施設に係るものであると共に訪問フラグ有と判定される。

ｔｅｘｔ＿ｉｄが「ｔｅｘｔＩＤ＿０００３」（図２のマイクロブログ管理テーブルの３行目の投稿データ）の投稿データについてのテキストは、形態素解析により「Ａ／の／ＣＭ／見る／けど／行く／みたい／わー」となる。これらの形態素の中に、施設名称である形態素「Ａ」が存在する。当該投稿データには位置情報が含まれるため、当該位置情報（１３８．００，３４．００）によって示される位置が施設名称「Ａ」の施設のメッシュ「ｍｅｓｈ＿Ａ」内か否かが判断される。当該位置がメッシュ内にないので、当該投稿データが、施設名称「Ａ」の施設に係るものであると共に訪問フラグ無と判定される。

ｔｅｘｔ＿ｉｄが「ｔｅｘｔＩＤ＿０００４」（図２のマイクロブログ管理テーブルの４行目の投稿データ）の投稿データは、上記の同様の判定によって、施設名称「Ｂ」の施設に係るものであると共に訪問フラグ有と判定される。

投稿データ判定部１３は、投稿データ毎に上記の判定結果を示す情報をカウント部１４に出力する。例えば、投稿データ判定部１３は、何れかの施設に係るものとされた投稿データについて、当該施設を示す情報、及び当該投稿データを投稿したユーザが当該推定対象の施設を訪問したことを示すものであると判定したか否かを示す情報をカウント部１４に出力する。

カウント部１４は、投稿データ判定部１３による判定に応じて、推定対象の施設について投稿データをカウントする機能部である。カウント部１４は、投稿データ判定部１３から判定結果を示す情報を入力する。カウント部１４は、当該情報に基づき、施設毎に、当該施設に係ると判定された投稿データのうち、ユーザが当該施設を訪問したことを示すものであると判定された投稿データの数、及びユーザが当該施設を訪問したことを示すものであると判定されなかった投稿データの数をそれぞれカウントする。

カウント部１４によってカウントされる数は、例えば、図５に示す施設とマイクロブログ紐付け管理テーブルにまとめられる。図５に示すように施設とマイクロブログ紐付け管理テーブルは、施設名称、ｍｅｓｈ＿ｃｏｄｅ、ｆｌｇ＿ｆａｌｓｅ及びｆｌｇ＿ｔｒｕｅの欄に、それぞれ対応付けられた情報を格納する。施設名称及びｍｅｓｈ＿ｃｏｄｅの欄に格納される情報はそれぞれ、カウントされる数に係る施設の施設名称である文字列、及び当該施設の位置を含むメッシュの識別子である。ｆｌｇ＿ｆａｌｓｅの欄に格納される情報は、当該施設に係ると判定された投稿データのうち、訪問フラグ無と判定された投稿データの数である。ｆｌｇ＿ｔｒｕｅの欄に格納される情報は、当該施設に係ると判定された投稿データのうち、訪問フラグ有と判定された投稿データの数である。ｆｌｇ＿ｔｒｕｅの数は、ユーザが施設を訪問した上で、当該施設についての投稿を行った（と推定される）数である。カウント部１４は、カウントによって得られた図５に示す施設とマイクロブログ紐付け管理テーブルの情報を人気度推定部１６に出力する。

なお、上記の数は、投稿データの数（投稿数）ではなく、ユーザ数としてもよい。即ち、同一のユーザが、同一の判定が行われる複数の投稿を行ったとしても、複数回カウントせず、１とカウントする。このカウントによって、１人のユーザが、何度も同一の判定が行われる投稿を行ったとしても、ユーザあたりの投稿の回数を考慮せずに施設の人気度の推定を行うことができる。

人数情報取得部１５は、推定対象の施設を含む領域に位置している人数を示す人数情報を取得する機能部である。例えば、当該領域は、上述したメッシュであり、当該人数情報は、メッシュ及び時間帯毎の人数を示す情報である。

記憶部１１は、人数情報を記憶する。記憶部１１は、人数情報をメッシュ統計人口管理テーブルで保持する。図６にメッシュ統計人口管理テーブルを示す。１つの行（レコード）が、１つのメッシュ及び１つの時間帯についての人数情報である。図６に示すようにメッシュ統計人口管理テーブルは、ｍｅｓｈ＿ｃｏｄｅ、ｄａｔｅ、ｔｉｍｅ＿ｓｔａｒｔ、ｔｉｍｅ＿ｅｎｄ及びｐｏｐｕｌａｔｉｏｎの欄に、それぞれ対応付けられた情報を格納する。ｍｅｓｈ＿ｃｏｄｅの欄に格納される情報は、人数情報に係るメッシュの識別子である。ｄａｔｅ、ｔｉｍｅ＿ｓｔａｒｔ及びｔｉｍｅ＿ｅｎｄの欄に格納される情報は、人数情報に係る時間帯を示す情報である。ｄａｔｅの欄に格納される情報は年月日を示す情報である。ｔｉｍｅ＿ｓｔａｒｔ及びｔｉｍｅ＿ｅｎｄの欄に格納される情報は、それぞれ当該時間帯の開始時刻及び終了時刻の時間、分及び秒を示す情報である。ｐｏｐｕｌａｔｉｏｎの欄に格納される情報は、当該メッシュ及び当該時間帯における人数である。

各メッシュの人数は、例えば、携帯電話機等の移動通信端末（ユーザ端末）の位置を示す情報に基づいて得ることができる。メッシュ毎の移動通信端末の数をカウントすることで、当該メッシュの人数情報が得られる。メッシュ統計人口管理テーブルに格納されるデータは、例えば、予め、サーバ１０によって人数情報を提供する移動体通信の通信事業者のサーバ等から取得されている。あるいは、当該情報は、予め、サーバ１０の管理者等によって、当該通信事業者のサーバ等から取得されてサーバ１０に入力されていてもよい。

人数情報取得部１５は、メッシュ統計人口管理テーブルに格納される人数情報を読み出して取得する。人数情報取得部１５は、予め設定した時間帯（例えば、現時点から過去１時間、１日分、１週間分、１ヶ月分等）の人数情報のみを取得することとしてもよい。また、人数情報取得部１５は、通信事業者のサーバ等に人数情報を要求して、当該通信事業者のサーバ等から人数情報を受信して取得してもよい。人数情報取得部１５は、取得した人数情報を人気度推定部１６に出力する。

人気度推定部１６は、カウント部１４によってカウントされた値、及び人数情報取得部１５によって取得された人数情報によって示される人数に基づいて、推定対象の施設の人気度を推定する機能部である。人気度推定部１６は、人数情報取得部１５によって取得された人数情報によって示される人数に対して、カウント部１４によってカウントされた値に応じた重み付けを行って、推定対象の施設の人気度を示すスコアを算出してもよい。人気度推定部１６は、カウント部１４によってカウントされた値の、推定対象の施設を含む領域であるメッシュ内の施設毎の割合に基づいて、推定対象の施設の人気度を推定してもよい。

人気度推定部１６は、カウント部１４及び人数情報取得部１５から、それぞれ情報を入力する。人気度推定部１６は、入力した情報に基づいて、人気度推定部１６は、施設毎の人気度を示すスコアを算出して、人気度を推定する。人気度推定部１６は、以下の式によって、施設ＰＯＩの人気度を示すスコアＰＯＰ（ＰＯＩ）を算出する。

上記の式において、Ｐは、推定対象の施設が含まれるメッシュの人数である。人気度推定部１６は、人数情報によって示される人数からＰを算出する。例えば、人気度推定部１６は、１日分の人数情報を用いて、当該メッシュの１時間単位の人数情報の平均値をＰとする。ｆｌｇ＿ｆａｌｓｅ（ＰＯＩ）及びｆｌｇ＿ｔｒｕｅ（ＰＯＩ）は、それぞれ当該施設のｆｌｇ＿ｆａｌｓｅ及びｆｌｇ＿ｔｒｕｅの値である。ｓｕｍ（ｆｌｇ＿ｆａｌｓｅ）は、当該メッシュに含まれる施設全てのｆｌｇ＿ｆａｌｓｅの値の総和である。ｓｕｍ（ｆｌｇ＿ｔｒｕｅ）は、当該メッシュに含まれる施設全てのｆｌｇ＿ｔｒｕｅの値の総和である。α，βは、予め設定されたそれぞれの項の重み係数である。例えば、α＝β＝１とする。なお、訪問フラグ有とされた投稿データの重みを、訪問フラグ無とされた投稿データの重みよりも重くしたい場合には、βの値をαの値と比べて大きくすればよい。また、α，βは、チューニングによって適宜、調節されてもよい。

上記の式に示す通り、スコアＰＯＰ（ＰＯＩ）は、当該メッシュの人数を、ｆｌｇ＿ｆａｌｓｅ（ＰＯＩ）及びｆｌｇ＿ｔｒｕｅ（ＰＯＩ）それぞれの値で重み付けしたものである。スコアＰＯＰ（ＰＯＩ）は、施設に訪れた人数の指標値である。スコアＰＯＰ（ＰＯＩ）が大きいほど、多くの人が訪れていると考えられ、高い人気を有している施設であることを示している。

例えば、メッシュの中にある施設が、図５の施設とマイクロブログ紐付け管理テーブルに示す４つの施設であり、各施設についてのｆｌｇ＿ｆａｌｓｅ及びｆｌｇ＿ｔｒｕｅの値が当該テーブルに示すものであったとする。また、メッシュの人数の平均値Ｐが２００であったとする。この場合、各施設についてのスコアＰＯＰ（ＰＯＩ）は、以下のようになる。
ＰＯＰ（Ａ）＝２００／２＊｛（１＊１００／３８０）＋（１＊５０／８５）｝＝１００＊（０．２６３＋０．５８８）＝８５．１
ＰＯＰ（Ｂ）＝２００／２＊｛（１＊２００／３８０）＋（１＊１０／８５）｝＝１００＊（０．５２６＋０．１１８）＝６４．４
ＰＯＰ（Ｃ）＝２００／２＊｛（１＊ ５０／３８０）＋（１＊１０／８５）｝＝１００＊（０．１３２＋０．１１８）＝２５．０
ＰＯＰ（Ｄ）＝２００／２＊｛（１＊ ３０／３８０）＋（１＊１５／８５）｝＝１００＊（０．０７９＋０．１７６）＝２５．５

なお、上記の例では、１日分の人数情報を用いることとしたが、特定の時間帯の人数情報のみを用いることとしてもよい。例えば、施設（店舗）が営業していない深夜の時間帯の人数情報を用いないこととしてもよい。また、複数日（例えば、１ヶ月）の人数情報から、１日の中の時間帯毎の人数の平均値を段出して、時間帯毎の施設のスコアを算出してもよい。即ち、時間帯毎の施設の人気度を推定してもよい。

また、各施設についてのｆｌｇ＿ｆａｌｓｅ及びｆｌｇ＿ｔｒｕｅの値についても、人数の平均の算出に用いられる人数情報の時間帯に対応する投稿データのみを用いて算出することとしてもよい。

人気度推定部１６は、算出したスコアを、例えば、図７に示す施設スコア管理テーブルにまとめる。図７に示すように施設スコア管理テーブルは、施設名称、ｍｅｓｈ＿ｃｏｄｅ、ｓｃｏｒｅの欄に、それぞれ対応付けられた情報を格納する。施設名称及びｍｅｓｈ＿ｃｏｄｅの欄に格納される情報はそれぞれ、算出されるスコアに係る施設の施設名称である文字列、及び当該施設の位置を含むメッシュの識別子である。ｓｃｏｒｅの欄に格納される情報は、算出されるスコアである。人気度推定部１６は、施設スコア管理テーブルの情報を出力部１７に出力する。

出力部１７は、人気度推定部１６によって推定された人気度を示す情報を出力する機能部である。出力部１７は、人気度推定部１６から図７に示す施設スコア管理テーブルの情報を入力する。例えば、出力部１７は、図７に示す施設スコア管理テーブルの情報を記憶部１１に出力して記憶させる。記憶部１１に記憶された施設スコア管理テーブルの情報は、施設の情報をユーザに提供する装置又はモジュール等によって参照される。あるいは、出力部１７は、当該情報を当該装置又はモジュールに送信してもよい。

なお、上記の各機能部の動作は、例えば、サーバ１０の管理者等によってトリガがサーバ１０に入力されたタイミング、又は予め設定されたタイミングで行われる。具体的には、ユーザに施設の情報の提供が行われる前、又は行われる際に行われる。以上が、本実施形態に係るサーバ１０の機能である。

引き続いて、図８及び図９のフローチャートを用いて、本実施形態に係るサーバ１０で実行される処理（サーバ１０が行う動作方法）を説明する。図８のフローチャートを用いて、本処理全体の処理を説明する。

本処理では、まず、投稿データ取得部１２によって、投稿データが取得される（Ｓ０１）。続いて、投稿データ判定部１３によって、各投稿データについて、推定対象の施設に係るものであるかの判定、及び訪問フラグ有無の判定が行われる（Ｓ０３）。続いて、カウント部１４によって、投稿データ判定部１３による判定に応じたカウントが行われる（Ｓ０３）。

上記の判定（Ｓ０２）及びカウント（Ｓ０３）の処理について、図９のフローチャートを用いて詳細に説明する。当該処理は、投稿データ毎に全ての投稿データについて行われる。本処理では、まず、投稿データ取得部１２によって、投稿データに含まれるテキストについて形態素解析が行われる（Ｓ２１）。続いて、投稿データ判定部１３によって、各形態素について、施設名称と一致するものがあるか判断される（Ｓ２２）。投稿データ判定部１３によって、何れの形態素も施設名称と一致しないと判断された場合（Ｓ２２のＮＯ）、投稿データは何れか施設に係るものでないと判定される。この場合、投稿データはカウント対象とはされずに、当該投稿データについての処理が終了する。

投稿データ判定部１３によって、何れかの形態素と施設名称が一致したと判断された場合（Ｓ２２のＹＥＳ）、投稿データが当該施設名称の施設に係るものであると判定される。続いて、投稿データ判定部１３によって、当該投稿データに位置情報が含まれているか（付与されているか）が判断される（Ｓ２３）。投稿データ判定部１３によって、投稿データに位置情報が含まれていると判断された場合（Ｓ２３のＹＥＳ）、続いて、当該位置情報によって示される位置が、投稿データに係るとされた施設のメッシュ内であるか否かが判断される（Ｓ２４）。

投稿データ判定部１３によって、投稿データに含まれる位置情報によって示される位置が、施設のメッシュ内であると判断された場合（Ｓ２４のＹＥＳ）、当該投稿データについて訪問フラグ有と判定（分類）される。続いて、当該判定に応じて、カウント部１４によって、当該施設についてのｆｌｇ＿ｔｒｕｅの値が＋１される（Ｓ３１）。一方、Ｓ２４において、投稿データ判定部１３によって、投稿データに含まれる位置情報によって示される位置が、施設のメッシュ内ではないと判断された場合（Ｓ２４のＮＯ）、当該投稿データについて訪問フラグ無と判定（分類）される（Ｓ３２）。続いて、当該判定に応じて、カウント部１４によって、当該施設についてのｆｌｇ＿ｆａｌｓｅの値が＋１される。各施設についてのｆｌｇ＿ｔｒｕｅ及びｆｌｇ＿ｆａｌｓｅの値は、判定（Ｓ０２）及びカウント（Ｓ０３）の処理の前に０にされる。

Ｓ２３において、投稿データ判定部１３によって、投稿データに位置情報が含まれていないと判断された場合（Ｓ２３のＮＯ）、続いて、各形態素について、訪問ルール形態素と一致するものがあるか判断される（Ｓ２５）。投稿データ判定部１３によって、何れかの形態素と訪問ルール形態素が一致したと判断された場合（Ｓ２５のＹＥＳ）、当該投稿データについて訪問フラグ有と判定（分類）される。続いて、当該判定に応じて、カウント部１４によって、当該施設についてのｆｌｇ＿ｔｒｕｅの値が＋１される（Ｓ３１）。一方、Ｓ２５において、投稿データ判定部１３によって、何れの形態素も訪問ルール形態素と一致しないと判断された場合（Ｓ２５のＮＯ）、当該投稿データについて訪問フラグ無と判定（分類）される。続いて、当該判定に応じて、カウント部１４によって、当該施設についてのｆｌｇ＿ｆａｌｓｅの値が＋１される（Ｓ３２）。以上が、判定（Ｓ０２）及びカウント（Ｓ０３）の処理である。

図８に戻り、続いて、人数情報取得部１５によって、人数情報が取得される（Ｓ０４）。続いて、カウント部１４によってカウントされた値、及び人数情報取得部１５によって取得された人数情報に基づいて、人気度推定部１６によって、施設の人気度を示すスコアが算出される（Ｓ０５）。続いて、出力部１７によって、推定された人気度を示す情報が出力される（Ｓ０６）。以上が、本実施形態に係るサーバ１０で実行される処理である。

本実施形態では、投稿データについて、推定対象の施設に係るものであるか、及び当該投稿データを投稿したユーザが当該推定対象の施設を訪問したことを示すものであるかの判定が行われる。当該判定に応じた投稿データがカウントされ、カウントされた値、及び人数情報に基づいて、推定対象の施設の人気度が推定される。従って、投稿データが、人気度の推定の上で適切に考慮される。従って、本発明の一実施形態に係る場所人気度推定システムによれば、ユーザの訪問を考慮して、施設等の場所の人気度を適切に推定することができる。

例えば、カウントされた値が、図５の施設とマイクロブログ紐付け管理テーブルに示すものであった場合を考える。推定対象の施設に係る投稿データの数、即ち、ｆｌｇ＿ｆａｌｓｅ及びｆｌｇ＿ｔｒｕｅの値の和は、２００＋１０で施設名称が「Ｂ」が最も多くなる。従って、ユーザが施設を訪問したことを示すものであるかの判定を行わない場合には、施設名称が「Ｂ」が最も人気があるという推定がなされてしまう。

一方で、ユーザが施設を訪問したことを示す投稿データは、施設名称が「Ａ」が最も多く、最も多くのユーザが訪れたと考えられる施設は、施設名称が「Ａ」の施設である。施設名称が「Ｂ」については、ユーザが施設を訪問したことを示す投稿データは、比較的少ない。従って、ユーザの訪問を考慮した場合には、施設名称が「Ａ」が最も人気があるという推定がなされることが適切であると考えられる。本実施形態では、図７の施設スコア管理テーブルに示すように施設名称が「Ａ」が最も人気があるとされており、適切な推定がなされている。

また、推定対象の施設に係る投稿データの数を用いれば、施設名称が「Ｃ」の施設の人気度が、施設名称が「Ｄ」の施設の人気度よりも高くなる。しかしながら、上記の「Ａ」「Ｂ」の場合と同様に本実施形態では、「Ｄ」の施設の人気度が、「Ｃ」の施設の人気度よりも高くなる。

また、ユーザが施設を訪問したことを示すものではない投稿データ、即ち、ｆｌｇ＿ｆａｌｓｅもカウントされて、人気度の推定に用いられるため、ユーザが訪れたことのみによる推定ではなく、施設の評判等を考慮した適切な推定を行うことができる。推定された人気度は、上述したようにユーザへの情報の提供の際に用いられる。従って、適切な人気度の推定が行われることで、ユーザへ提供される情報を適切な情報のみとすることができ、端末との間の通信量を削減したり、情報提供の際の処理負荷を軽減したりすることができる。即ち、本実施形態によれば、情報の提供の際のネットワーク資源又はハードウェア資源を効率的に利用することができる。

また、本実施形態のように、投稿データが推定対象の施設に係るものであるかの判定、及びユーザが推定対象の施設を訪問したことを示すものであるかの判定に、投稿データに含まれるテキスト及び位置情報を用いることとしてもよい。この構成によれば、適切かつ確実に判定を行うことができ、適切かつ確実に本発明の一実施形態を実施することができる。但し、上記の判定は、必ずしも上述した情報を用いて、上述した方法で行われる必要はなく、投稿データを用いたものであれば、どのように行われてもよい。

また、本実施形態のように、人数情報によって示されるメッシュの人数に対して、ｆｌｇ＿ｆａｌｓｅ及びｆｌｇ＿ｔｒｕｅの値に応じた重み付けを行って、スコアを算出することとしてもよい。この構成によれば、施設の人気度を適切かつ確実に推定することができる。

更に、本実施形態のスコアの算出の式のように、メッシュに含まれる施設全てのｆｌｇ＿ｆａｌｓｅ及びｆｌｇ＿ｔｒｕｅの値の総和に対する、ｆｌｇ＿ｆａｌｓｅ及びｆｌｇ＿ｔｒｕｅの割合の値を用いて、人気度のスコアを算出することとしてもよい。通常、訪問フラグ有の投稿データは、訪問フラグ無の投稿データと比べて数が少ない。上記のように割合の値を用いることで、訪問フラグ有の投稿データの重みを適切かつ容易に重くすることができる。従って、この構成によれば、施設の人気度を更に適切に推定することができる。但し、必ずしも上記の割合の値及び上述した式をスコアの算出に用いる必要はなく、カウントした値に基づく人気度の推定であれば、どのように推定を行うこととしてもよい。

なお、上述したように、本実施形態では、判定において、テキストにおける施設に応じた記載として、施設名称を用いたが、施設に応じた文字列であれば、それ以外の文字列が用いられてもよい。

なお、上記実施の形態の説明に用いたブロック図は、機能単位のブロックを示している。これらの機能ブロック（構成部）は、ハードウェア及び／又はソフトウェアの任意の組み合わせによって実現される。また、各機能ブロックの実現手段は特に限定されない。すなわち、各機能ブロックは、物理的及び／又は論理的に結合した１つの装置により実現されてもよいし、物理的及び／又は論理的に分離した２つ以上の装置を直接的及び／又は間接的に(例えば、有線及び／又は無線)で接続し、これら複数の装置により実現されてもよい。

例えば、本発明の一実施の形態におけるサーバ１０は、本実施形態のサーバ１０の処理を行うコンピュータとして機能してもよい。図１０は、本実施形態に係るサーバ１０のハードウェア構成の一例を示す図である。上述のサーバ１０は、物理的には、プロセッサ１００１、メモリ１００２、ストレージ１００３、通信装置１００４、入力装置１００５、出力装置１００６、バス１００７などを含むコンピュータ装置として構成されてもよい。

なお、以下の説明では、「装置」という文言は、回路、デバイス、ユニットなどに読み替えることができる。サーバ１０のハードウェア構成は、図に示した各装置を１つ又は複数含むように構成されてもよいし、一部の装置を含まずに構成されてもよい。

サーバ１０における各機能は、プロセッサ１００１、メモリ１００２などのハードウェア上に所定のソフトウェア（プログラム）を読み込ませることで、プロセッサ１００１が演算を行い、通信装置１００４による通信、並びにメモリ１００２及びストレージ１００３におけるデータの読み出し及び／又は書き込みを制御することで実現される。

プロセッサ１００１は、例えば、オペレーティングシステムを動作させてコンピュータ全体を制御する。プロセッサ１００１は、周辺装置とのインターフェース、制御装置、演算装置、レジスタなどを含む中央処理装置（ＣＰＵ：Central Processing Unit）で構成されてもよい。例えば、サーバ１０の各機能部１１〜１７は、プロセッサ１００１を含んで実現されてもよい。

また、プロセッサ１００１は、プログラム（プログラムコード）、ソフトウェアモジュール及びデータを、ストレージ１００３及び／又は通信装置１００４からメモリ１００２に読み出し、これらに従って各種の処理を実行する。プログラムとしては、上述の実施の形態で説明した動作の少なくとも一部をコンピュータに実行させるプログラムが用いられる。例えば、サーバ１０の各機能部１１〜１７は、メモリ１００２に格納され、プロセッサ１００１で動作する制御プログラムによって実現されてもよく、他の機能ブロックについても同様に実現されてもよい。上述の各種処理は、１つのプロセッサ１００１で実行される旨を説明してきたが、２以上のプロセッサ１００１により同時又は逐次に実行されてもよい。プロセッサ１００１は、１以上のチップで実装されてもよい。なお、プログラムは、電気通信回線を介してネットワークから送信されても良い。

メモリ１００２は、コンピュータ読み取り可能な記録媒体であり、例えば、ＲＯＭ（Read Only Memory）、ＥＰＲＯＭ（Erasable Programmable ＲＯＭ）、ＥＥＰＲＯＭ（Electrically Erasable Programmable ＲＯＭ）、ＲＡＭ（Random Access Memory）などの少なくとも１つで構成されてもよい。メモリ１００２は、レジスタ、キャッシュ、メインメモリ（主記憶装置）などと呼ばれてもよい。メモリ１００２は、本発明の一実施の形態に係る方法を実施するために実行可能なプログラム（プログラムコード）、ソフトウェアモジュールなどを保存することができる。

ストレージ１００３は、コンピュータ読み取り可能な記録媒体であり、例えば、ＣＤ−ＲＯＭ（Compact Disc ＲＯＭ）などの光ディスク、ハードディスクドライブ、フレキシブルディスク、光磁気ディスク(例えば、コンパクトディスク、デジタル多用途ディスク、Ｂｌｕ−ｒａｙ（登録商標）ディスク)、スマートカード、フラッシュメモリ(例えば、カード、スティック、キードライブ)、フロッピー（登録商標）ディスク、磁気ストリップなどの少なくとも１つで構成されてもよい。ストレージ１００３は、補助記憶装置と呼ばれてもよい。上述の記憶媒体は、例えば、メモリ１００２及び／又はストレージ１００３を含むデータベース、サーバその他の適切な媒体であってもよい。

通信装置１００４は、有線及び／又は無線ネットワークを介してコンピュータ間の通信を行うためのハードウェア（送受信デバイス）であり、例えばネットワークデバイス、ネットワークコントローラ、ネットワークカード、通信モジュールなどともいう。例えば、上述のサーバ１０の各機能部１１〜１７は、通信装置１００４を含んで実現されてもよい。

入力装置１００５は、外部からの入力を受け付ける入力デバイス（例えば、キーボード、マウス、マイクロフォン、スイッチ、ボタン、センサなど）である。出力装置１００６は、外部への出力を実施する出力デバイス（例えば、ディスプレイ、スピーカー、LEDランプなど）である。なお、入力装置１００５及び出力装置１００６は、一体となった構成（例えば、タッチパネル）であってもよい。

また、プロセッサ１００１及びメモリ１００２などの各装置は、情報を通信するためのバス１００７で接続される。バス１００７は、単一のバスで構成されてもよいし、装置間で異なるバスで構成されてもよい。

また、サーバ１０は、マイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ：Digital Signal Processor）、ＡＳＩＣ（Application Specific Integrated Circuit）、ＰＬＤ（Programmable Logic Device）、ＦＰＧＡ（Field Programmable Gate Array）などのハードウェアを含んで構成されてもよく、当該ハードウェアにより、各機能ブロックの一部又は全てが実現されてもよい。例えば、プロセッサ１００１は、これらのハードウェアの少なくとも１つで実装されてもよい。

以上、本実施形態について詳細に説明したが、当業者にとっては、本実施形態が本明細書中に説明した実施形態に限定されるものではないということは明らかである。本実施形態は、特許請求の範囲の記載により定まる本発明の趣旨及び範囲を逸脱することなく修正及び変更態様として実施することができる。したがって、本明細書の記載は、例示説明を目的とするものであり、本実施形態に対して何ら制限的な意味を有するものではない。

本明細書で説明した各態様／実施形態の処理手順、シーケンス、フローチャートなどは、矛盾の無い限り、順序を入れ替えてもよい。例えば、本明細書で説明した方法については、例示的な順序で様々なステップの要素を提示しており、提示した特定の順序に限定されない。

入出力された情報等は特定の場所(例えば、メモリ)に保存されてもよいし、管理テーブルで管理してもよい。入出力される情報等は、上書き、更新、または追記され得る。出力された情報等は削除されてもよい。入力された情報等は他の装置へ送信されてもよい。

判定は、１ビットで表される値（０か１か）によって行われてもよいし、真偽値（Boolean：trueまたはfalse）によって行われてもよいし、数値の比較（例えば、所定の値との比較）によって行われてもよい。

本明細書で説明した各態様／実施形態は単独で用いてもよいし、組み合わせて用いてもよいし、実行に伴って切り替えて用いてもよい。また、所定の情報の通知（例えば、「Ｘであること」の通知）は、明示的に行うものに限られず、暗黙的（例えば、当該所定の情報の通知を行わない）ことによって行われてもよい。

ソフトウェアは、ソフトウェア、ファームウェア、ミドルウェア、マイクロコード、ハードウェア記述言語と呼ばれるか、他の名称で呼ばれるかを問わず、命令、命令セット、コード、コードセグメント、プログラムコード、プログラム、サブプログラム、ソフトウェアモジュール、アプリケーション、ソフトウェアアプリケーション、ソフトウェアパッケージ、ルーチン、サブルーチン、オブジェクト、実行可能ファイル、実行スレッド、手順、機能などを意味するよう広く解釈されるべきである。

また、ソフトウェア、命令などは、伝送媒体を介して送受信されてもよい。例えば、ソフトウェアが、同軸ケーブル、光ファイバケーブル、ツイストペア及びデジタル加入者回線（ＤＳＬ）などの有線技術及び／又は赤外線、無線及びマイクロ波などの無線技術を使用してウェブサイト、サーバ、又は他のリモートソースから送信される場合、これらの有線技術及び／又は無線技術は、伝送媒体の定義内に含まれる。

本明細書で説明した情報、信号などは、様々な異なる技術のいずれかを使用して表されてもよい。例えば、上記の説明全体に渡って言及され得るデータ、命令、コマンド、情報、信号、ビット、シンボル、チップなどは、電圧、電流、電磁波、磁界若しくは磁性粒子、光場若しくは光子、又はこれらの任意の組み合わせによって表されてもよい。

なお、本明細書で説明した用語及び／又は本明細書の理解に必要な用語については、同一の又は類似する意味を有する用語と置き換えてもよい。

本明細書で使用する「システム」および「ネットワーク」という用語は、互換的に使用される。

また、本明細書で説明した情報、パラメータなどは、絶対値で表されてもよいし、所定の値からの相対値で表されてもよいし、対応する別の情報で表されてもよい。

上述したパラメータに使用する名称はいかなる点においても限定的なものではない。さらに、これらのパラメータを使用する数式等は、本明細書で明示的に開示したものと異なる場合もある。

移動通信端末は、当業者によって、加入者局、モバイルユニット、加入者ユニット、ワイヤレスユニット、リモートユニット、モバイルデバイス、ワイヤレスデバイス、ワイヤレス通信デバイス、リモートデバイス、モバイル加入者局、アクセス端末、モバイル端末、ワイヤレス端末、リモート端末、ハンドセット、ユーザエージェント、モバイルクライアント、クライアント、またはいくつかの他の適切な用語で呼ばれる場合もある。

本明細書で使用する「判断(determining)」、「決定(determining)」という用語は、多種多様な動作を包含する場合がある。「判断」、「決定」は、例えば、計算(calculating)、算出(computing)、処理(processing)、導出(deriving)、調査(investigating)、探索(looking up)（例えば、テーブル、データベースまたは別のデータ構造での探索）、確認(ascertaining)した事を「判断」「決定」したとみなす事などを含み得る。また、「判断」、「決定」は、受信(receiving)（例えば、情報を受信すること）、送信(transmitting)(例えば、情報を送信すること)、入力(input)、出力(output)、アクセス(accessing)（例えば、メモリ中のデータにアクセスすること）した事を「判断」「決定」したとみなす事などを含み得る。また、「判断」、「決定」は、解決(resolving)、選択(selecting)、選定(choosing)、確立(establishing)、比較(comparing)などした事を「判断」「決定」したとみなす事を含み得る。つまり、「判断」「決定」は、何らかの動作を「判断」「決定」したとみなす事を含み得る。

本明細書で使用する「に基づいて」という記載は、別段に明記されていない限り、「のみに基づいて」を意味しない。言い換えれば、「に基づいて」という記載は、「のみに基づいて」と「に少なくとも基づいて」の両方を意味する。

「含む（include）」、「含んでいる（including）」、およびそれらの変形が、本明細書あるいは特許請求の範囲で使用されている限り、これら用語は、用語「備える(comprising)」と同様に、包括的であることが意図される。さらに、本明細書あるいは特許請求の範囲において使用されている用語「または（or）」は、排他的論理和ではないことが意図される。

本明細書において、文脈または技術的に明らかに1つのみしか存在しない装置である場合以外は、複数の装置をも含むものとする。本開示の全体において、文脈から明らかに単数を示したものではなければ、複数のものを含むものとする。

１０…サーバ、１１…記憶部、１２…投稿データ取得部、１３…投稿データ判定部、１４…カウント部、１５…人数情報取得部、１６…人気度推定部、１７…出力部、１００１…プロセッサ、１００２…メモリ、１００３…ストレージ、１００４…通信装置、１００５…入力装置、１００６…出力装置、１００７…バス。

Claims (6)

1. 場所の人気度を推定する場所人気度推定システムであって、
   ユーザから投稿された投稿データを取得する投稿データ取得部と、
   前記投稿データ取得部によって取得された投稿データが、推定対象の場所に係るものであると共に当該投稿データを投稿したユーザが当該推定対象の場所を訪問したことを示すものであるかを判定する投稿データ判定部と、
   前記投稿データ判定部による判定に応じて、前記推定対象の場所について投稿データをカウントするカウント部と、
   前記推定対象の場所を含む領域に位置している人数を示す人数情報を取得する人数情報取得部と、
   前記カウント部によってカウントされた値、及び前記人数情報取得部によって取得された人数情報によって示される人数に基づいて、前記推定対象の場所の人気度を推定する人気度推定部と、
   前記人気度推定部によって推定された人気度を示す情報を出力する出力部と、
   を備える場所人気度推定システム。
2. 前記人気度推定部は、前記人数情報取得部によって取得された人数情報によって示される人数に対して、前記カウント部によってカウントされた値に応じた重み付けを行って、前記推定対象の場所の人気度を示すスコアを算出する、請求項１に記載の場所人気度推定システム。
3. 前記投稿データ取得部は、テキストを含む投稿データを取得し、
   前記投稿データ判定部は、前記投稿データに含まれるテキストに前記推定対象の場所に応じた記載が含まれているか否かを判定して、投稿データが推定対象の場所に係るものであるかを判定する、請求項１又は２に記載の場所人気度推定システム。
4. 前記投稿データ取得部は、テキストを含む投稿データを取得し、
   前記投稿データ判定部は、前記投稿データに含まれるテキストに基づいて、当該投稿データを投稿したユーザが前記推定対象の場所を訪問したことを示すものであるかを判定する、請求項１〜３の何れか一項に記載の場所人気度推定システム。
5. 前記投稿データ取得部は、位置を示す位置情報を含む投稿データを取得し、
   前記投稿データ判定部は、前記投稿データに含まれる位置情報に基づいて、当該投稿データを投稿したユーザが前記推定対象の場所を訪問したことを示すものであるかを判定する、請求項１〜４の何れか一項に記載の場所人気度推定システム。
6. 前記人気度推定部は、前記カウント部によってカウントされた値の、前記推定対象の場所を含む領域内の場所毎の割合に基づいて、推定対象の場所の人気度を推定する請求項１〜５の何れか一項に記載の場所人気度推定システム。

Images