JP2015225128A - 提示システム、提示装置、及び提示方法 - Google Patents

Abstract

【課題】混雑しているエリアとそのエリアの混雑に関連する情報とを併せて提示する。
【解決手段】提示システムＰＳが、電子地図上の各エリアＡにおける混雑度に関する混雑指標Ｉ_Ｃを取得する混雑指標取得部ＡＳと、地理的属性を有する興味情報ＰＩに関する第１興味指標Ｉ_Ｐ１を取得する第１興味指標取得部２０２と、混雑指標Ｉ_Ｃ及び第１興味指標Ｉ_Ｐ１に応じてエリアＡを提示する場所提示部２０４と、場所提示部２０４が提示するエリアＡに対応付けられる興味情報ＰＩに基づいて混雑関連情報ＣＩを提示する情報提示部２０６とを備える。
【選択図】図２４

Description

本発明は、提示システム、提示装置、及び提示方法に関する。

近年、携帯端末の位置情報に基づいて人口の地理的分布を推定する技術が活用されている（例えば、特許文献１）。以上の位置情報は、例えば、携帯端末が備えるＧＰＳ機能による測位、または携帯端末が接続している無線基地局の位置に基づいて取得される。

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

携帯端末の位置情報により人口分布を推定する技術においては、ある特定のエリアに人口が集中していることを検出してユーザに提示できる。しかしながら、その特定エリアの混雑に関連する情報、例えば、その特定エリアに人口が集中している理由（すなわち、混雑理由）やその他の混雑状況を示す情報は、携帯端末の位置情報から取得し得ない。

以上の事情を考慮して、本発明は、混雑しているエリアとそのエリアの混雑に関連する情報とを併せて提示することを目的とする。

本発明の提示システムは、電子地図上の各エリアにおける混雑度に関する混雑指標を取得する混雑指標取得部と、地理的属性を有する興味情報に関する第１興味指標を取得する第１興味指標取得部と、前記混雑指標及び前記第１興味指標に応じて前記エリアを提示する場所提示部と、前記場所提示部が提示する前記エリアに対応付けられる前記興味情報に基づいて混雑関連情報を提示する情報提示部とを備える。

本発明の提示装置は、電子地図上の各エリアにおける混雑度に関する混雑指標を取得する混雑指標取得部と、地理的属性を有する興味情報に関する第１興味指標を取得する第１興味指標取得部と、前記混雑指標及び前記第１興味指標に応じて前記エリアを提示する場所提示部と、前記場所提示部が提示する前記エリアに対応付けられる前記興味情報に基づいて混雑関連情報を提示する情報提示部とを備える。

本発明の提示方法は、電子地図上の各エリアにおける混雑度に関する混雑指標を取得することと、地理的属性を有する興味情報に関する第１興味指標を取得することと、前記混雑指標及び前記第１興味指標に応じて前記エリアを提示することと、提示されるべき前記エリアに対応付けられる前記興味情報に基づいて混雑関連情報を提示することとを備える。

本発明によれば、混雑しているエリアとそのエリアの混雑に関連する情報とが併せて提示される。

第１実施形態に係る提示システムと、提示システムに関連するコンピュータ装置とを示す図である。 第１実施形態のサーバの物理構成ブロック図である。 第１実施形態のクライアント端末の物理構成ブロック図である。 第１実施形態の提示システムの論理構成ブロック図である。 第１実施形態のエリア抽出動作のフローチャートである。 位置情報の構成例を示す図である。 推計人口テーブルの構成例を示す図である。 配列テーブルの構成例を示す図である。 調整後人口テーブルの構成例を示す図である。 抽出エリアテーブルの構成例を示す図である。 第１実施形態のインデックス動作のフローチャートである。 投稿情報の構成例を示す図である。 辞書テーブルの構成例を示す図である。 投稿情報の構成例を示す図である。 投稿情報の構成例を示す図である。 第１実施形態の投稿情報解析動作のフローチャートである。 投稿上昇テーブルの構成例を示す図である。 第１実施形態の投稿情報保存動作を示すフローチャートである。 第１実施形態の混雑エリアの提示動作を示すフローチャートである。 クライアント端末のディスプレイに表示される画像の一例である。 第１実施形態の投稿数上昇場所の提示動作を示すフローチャートである。 クライアント端末のディスプレイに表示される画像の一例である。 第１実施形態の混雑関連情報の提示動作を示すフローチャートである。 クライアント端末のディスプレイに表示される画像の一例である。 注目ボックスを示す図である。 変形例のウェブサーバの論理構成の一部を示す図である。 イベントボックスを示す図である。

以下、図面を参照しながら本発明の実施形態を詳細に説明する。

１． 第１実施形態
１（１）． 提示システムの概略
図１は、本発明の第１実施形態に係る提示システムＰＳと、提示システムＰＳに関係する複数のコンピュータ装置とを概略的に示す。本実施形態のコンピュータ装置は、所定のプロトコル（ＴＣＰ／ＩＰ等）に従って通信する。提示システムＰＳは、位置情報サーバＬＳ及びインデックスサーバＩＳから取得した情報に基づいて、混雑している混雑エリアＣＡとその混雑エリアＣＡに関する混雑関連情報ＣＩとをクライアント端末ＣＬに提示する。本実施形態の混雑関連情報ＣＩは、混雑エリアＣＡの混雑理由を示す情報である。

提示システムＰＳは、混雑解析サーバＡＳとウェブサーバＷＳとを備える。混雑解析サーバＡＳは、位置情報サーバＬＳから提供されるユーザ（携帯端末）の位置情報Ｌを解析して、人口が集中している混雑エリアＣＡを時系列的に特定する。ウェブサーバＷＳは、混雑エリアＣＡと混雑関連情報ＣＩとをクライアント端末ＣＬに提示する。

また、ウェブサーバＷＳは、インデックスサーバＩＳから提供される投稿情報ＰＩを解析して投稿情報ＰＩの投稿数が上昇している場所を特定し、クライアント端末ＣＬに提示する。以上の投稿情報ＰＩは、ブログサーバＢＳからインデックスサーバＩＳに供給される。本実施形態における投稿情報ＰＩは、投稿ユーザの興味を示す興味情報である。

ブログサーバＢＳは、ユーザ端末（たとえば、スマートフォン）からの投稿情報ＰＩを受信して記憶し、外部からの要求に応じて投稿情報ＰＩを提供する。以下、本実施形態における投稿情報ＰＩの例を、非限定的に列挙する。
−マイクロブログサービス（例えば、Ｔｗｉｔｔｅｒ［登録商標］）における１４０文字以下の短文投稿（例えば、ツイート［登録商標］）
−ブログ（ウェブログ）サービスにおける日記や寸評等の投稿
−ソーシャルネットワーキングサービス（ＳＮＳ）におけるステータス投稿

クライアント端末ＣＬは、ユーザからの要求に応じてディスプレイに電子地図を表示する。加えて、クライアント端末ＣＬは、ウェブサーバＷＳから提示された混雑エリアＣＡを電子地図上に表示する。また、クライアント端末ＣＬは、混雑エリアＣＡに対応付けられる混雑関連情報ＣＩを電子地図と併せて表示する。

電子地図の表示に用いられる電子地図データは、ユーザからの要求に応じてクライアント端末ＣＬが地図サーバ（不図示）から取得してもよいし、予めクライアント端末ＣＬに記憶されていてもよい。また、混雑エリアＣＡ及び混雑関連情報ＣＩと共に、ウェブサーバＷＳからクライアント端末ＣＬに提供されてもよい。その場合、ウェブサーバＷＳは予め電子地図データを記憶していてもよいし、地図サーバから、都度又は定期的に取得してもよい。

１（２）． 物理的構成
１（２）−１． サーバの構成
図２は、混雑解析サーバＡＳ及びウェブサーバＷＳを始めとする本実施形態のサーバの物理的構成を示すブロック図である。各サーバ（ＡＳ，ＷＳ，ＬＳ，ＩＳ，ＢＳ）は、ネットワークインタフェース１０と入力部１２と出力部１４とＣＰＵ（Central Processing Unit）１６とＲＡＭ（Random Access Memory）１８とＲＯＭ（Read Only Memory）２０とＨＤＤ（Hard Disk Drive）２２とを備える。

ネットワークインタフェース１０は、ネットワークを介して他のコンピュータ装置と通信を実行する。入力部１２は、キーボード等の入力装置からの入力信号を受け付ける。出力部１４は、ディスプレイ等の出力装置に対して出力信号を送信する。ＣＰＵ１６は、主記憶装置であるＲＡＭ１８及びＲＯＭ２０に記憶されているプログラムを実行することにより種々の制御及び演算を行う。ＨＤＤ２２は、ＲＡＭ１８上に展開可能なプログラム及びデータを記憶する補助記憶装置である。なお、ＨＤＤ２２に代えて又は加えてＳＳＤ等の記憶媒体が採用されてもよい。

当業者が当然に理解する通り、１つのサーバが複数のコンピュータ装置によって構成されてもよいし、１つのコンピュータ装置が仮想化された複数のサーバを備えてもよい。

１（２）−２． クライアント端末の構成
図３は、本実施形態のクライアント端末ＣＬの物理的構成を示すブロック図である。クライアント端末ＣＬは、ネットワークインタフェース３０と入力部３２と出力部３４とＣＰＵ３６とＲＡＭ３８とＲＯＭ４０とＨＤＤ４２とを備える。以上の各要素は、各サーバが備える、図２を参照して説明された要素と同様の構成を有する。

１（３）． 論理的構成
図４は、第１実施形態の提示システムＰＳの論理的構成を示すブロック図である。混雑解析サーバＡＳは、エリアＡごとに人口を推計する人口推計部１００と、推計人口を配列化する配列化処理部１１０と、推計人口の季節調整処理を実行する季節調整部１２０と、混雑エリアＣＡを抽出するエリア抽出部１３０とを機能ブロックとして備えると共に、推計人口テーブル１４０と配列テーブル１５０と調整後人口テーブル１６０とを論理テーブルとして備える。

ウェブサーバＷＳは、クライアント端末ＣＬに種々のデータを提示するデータ提示部２００と、インデックスサーバＩＳから取得した投稿情報ＰＩを解析する投稿情報解析部２１０と、混雑エリアＣＡに関する投稿情報ＰＩを保存する投稿情報保存部２２０とを機能ブロックとして備えると共に、抽出エリアテーブル２３０と画像テーブル２４０と投稿情報テーブル２５０と投稿上昇テーブル２６０とを論理テーブルとして備える。

データ提示部２００は第１クエリ部（第１興味指標取得部）２０２と場所提示部２０４と情報提示部２０６とを備える。投稿情報解析部２１０は第２クエリ部（第２興味指標取得部）２１２を備える。投稿情報保存部２２０はエリア取得部２２２と第３クエリ部２２４とを備える。

インデックスサーバＩＳは、ブログサーバＢＳから取得した投稿情報ＰＩを処理してインデックスを付与するインデックス部３００を機能ブロックとして備えると共に、辞書テーブル３１０と抽出投稿テーブル３２０と論理テーブルとして備える。

以上の機能ブロックは、各サーバ（ＡＳ，ＷＳ，ＩＳ）の主記憶装置に記憶されているコンピュータプログラムをＣＰＵ１６が実行することにより実現される。また、以上の論理テーブルは、複数のテーブルが所定の関係（リレーション）に基づいて連結される関係データベースの構成要素である。関係データベースは、不揮発性メモリであるＨＤＤ２２にデータが記憶されるオンディスクデータベースで実装されてもよいし、揮発性メモリであるＲＡＭ１８にデータが記憶されるインメモリデータベースで実装されてもよい。

１（４）． エリア提示動作
本実施形態のエリア提示動作を以下に説明する。エリア提示動作は、エリア抽出動作、インデックス動作、投稿情報解析動作、投稿情報保存動作、及びデータ提示動作を含む。

１（４）−１． エリア抽出動作（混雑指標取得動作）
図５は、本実施形態のエリア抽出動作を示すフローチャートである。混雑解析サーバＡＳの人口推計部１００は、位置情報サーバＬＳから携帯端末ユーザの位置情報Ｌを取得する（S1010）。図６に、位置情報サーバＬＳから提供される位置情報Ｌの具体的構成の一例を示す。位置情報Ｌは、ある時刻における携帯端末の位置（緯度経度）を示す複数のエントリを含む。各エントリは、携帯端末のユーザ識別子を示す「ユーザＩＤ」フィールド、携帯端末の緯度を示す「緯度」フィールド、携帯端末の経度を示す「経度」フィールド、及び携帯端末が測位を実施した時刻を示す「測位時刻」フィールドを有する。

人口推計部１００は、位置情報Ｌに基づいて、エリアＡごと及び時間帯ごとに推計人口を算出する（S1020）。本ステップでは任意の推計手法が採用され得るが、例えば、エリアＡ内に実際に存在するユーザの数に、全人口に占める当該キャリアのユーザの割合の逆数を乗算することにより、推計人口を算出することが可能である。

本実施形態において、エリアＡは、緯度及び経度に基づいて分割された網目状の領域（メッシュ）である。以上のメッシュは、日本国の総務省統計局が提供する標準地域メッシュ（例えば、４分の１地域メッシュ）であってもよいし、他の手法により画定されたメッシュであってもよい。

図７は、人口推計部１００が算出した推計人口が格納される推計人口テーブル１４０の一例である。推計人口テーブル１４０の各エントリは、推計人口の算定対象を示す「時間帯」フィールド及び「メッシュコード」フィールド、算定された推計人口値を示す「推計人口」フィールド、並びにメッシュコードが含まれる都道府県を示す「都道府県」フィールドを含む。

なお、図７の推計人口テーブル１４０では、各時間帯の時間幅として１時間が採用されるが、任意の時間長が採用され得ることは当然に理解される。また、あるメッシュ（エリアＡ）のメッシュコードが決まれば、そのメッシュが属する都道府県を確定することができるので、推計人口テーブル１４０において「都道府県」フィールドは必須の情報項目ではない。なお、１つのメッシュコードに対応するメッシュが２以上の都道府県に跨がる場合は、そのメッシュにおいて最も広い面積を示す都道府県をそのメッシュコードに相当する都道府県としてもよいし、そのメッシュ内の所定の点（例えば、中心点）が属する都道府県をそのメッシュコードに相当する都道府県としてもよい。

配列化処理部１１０は、エリアＡ（メッシュコード）ごとに推計人口を配列化する（S1030）。すなわち、配列化処理部１１０は、メッシュコードが同じ複数のエントリに含まれる推計人口値を１つの配列（同一タイプの複数データを含み得るデータ構造）に格納する。そして、格納された配列を示す「推計人口配列」フィールドを含む１つのエントリを作成して配列テーブル１５０に格納する。以上の配列化処理によってエントリ数が低減されることで、後続する処理の演算負荷が削減される。なお、演算負荷を更に削減するため、推計人口が所定閾値を上回るエリアＡのみを以上の配列化処理の対象としてもよい。

図８に示すように、配列テーブル１５０内の各エントリは、「推計人口配列」フィールドに加え、「メッシュコード」フィールド、「都道府県」フィールド、配列の第１番目の要素に対応する時間帯の開始時刻を示す「開始時刻」フィールド、及び各時間帯の時間幅を示す「時間幅」フィールドを含む。

季節調整部１２０は、配列テーブル１５０に含まれる各エントリについて、季節調整処理を実行する（S1040）。季節調整処理とは、時系列データ（原系列）から周期的成分（季節変動）による影響を除去する処理である。本ステップでは任意の季節調整手法が採用され得る。例えば、季節調整部１２０が、各メッシュコードについて過去の一定期間の原系列から季節変動パターンを計算して季節指数を求め、季節指数に基づいて「推計人口配列」フィールド内の推計人口を調整する。季節指数は、移動平均法や連環比率法等の任意の手法により求められる。

図９は、季節調整済みの推計人口が格納される調整後人口テーブル１６０の一例である。調整後人口テーブル１６０内の各エントリは、「メッシュコード」フィールド、「都道府県」フィールド、調整後推計人口の算定対象を示す「時間帯」フィールド、季節調整前の「推計人口」フィールド、上述の季節調整処理を施した「調整後推計人口」フィールド、季節調整処理後の推計人口の標準偏差を示す「標準偏差」フィールド、及び、比較的長い期間（例えば、１ヶ月間）にわたって推計人口を平均した値を示す「長期移動平均」フィールドを含む。なお、以上の標準偏差の算定対象となる期間は、長期移動平均と同程度の比較的長い期間である。

図９から理解されるように、調整後人口テーブル１６０内の各エントリは、メッシュコードと時間帯との組合せにより特定される。前述の配列テーブル１５０（図８）では１エントリに複数の時間帯が含まれるが、調整後人口テーブル１６０では推計人口テーブル１４０（図７）と同様に１エントリが１つの時間帯に相当する。

なお、季節調整部１２０が、配列テーブル１５０に含まれる全エントリについてではなく、選別されたエントリのみ（例えば、現在時刻の直前の時間帯における推計人口が所定閾値以上のエントリのみ）について、以上の季節調整処理を実行すると好適である。演算負荷が低減されるからである。

エリア抽出部１３０は、調整後人口テーブル１６０を参照して、推計人口が集中している（増大している）混雑エリアＣＡを抽出する（S1050）。

より具体的には、まず、エリア抽出部１３０は、以下の関係式に基づいて、調整後人口テーブル１６０内の各エントリについて、長期移動平均からの調整後推計人口のずれを示すσ_sadjと長期移動平均に対する調整後推計人口の倍率を示すＭ_sadjとを算定する。
σ_sadj ＝ （調整後推計人口−長期移動平均）／標準偏差 ……（式１）
Ｍ_sadj ＝ 調整後推計人口／長期移動平均 ……（式２）
その後、エリア抽出部１３０は、混雑指標Ｉ_Ｃに従ってソートした場合に第１順位（例えば、１０位）以上となるエントリを抽出して、ソート順位と共に抽出エリアテーブル２３０（図１０）に格納する。以上の順位は、全国順位であってもよいし都道府県別の順位であってもよい。なお、エリア抽出部１３０は、ステップS1050において、混雑指標Ｉ_Ｃが第１閾値を上回るエントリを抽出して、抽出エリアテーブル２３０に格納してもよい。

混雑指標Ｉ_Ｃに関しては、σ_sadjとＭ_sadjとのいずれか一方のみを混雑指標Ｉ_Ｃとしてもよいし、双方に基づく指標（例えば、Ｉ_Ｃ＝α・σ_sadj＋β・Ｍ_sadj。α及びβは重み付け係数）を混雑指標Ｉ_Ｃとしてもよい。

また、ステップS1050において、推計人口が所定閾値以上のエントリのみを混雑指標Ｉ_Ｃの算定対象としてもよい。推計人口の増大を示す混雑指標Ｉ_Ｃが大きくても、推計人口自体が少なければ混雑エリアＣＡとは言えないからである。以上のように対象エントリを選別することで、演算量の削減が図られる。

以上に説明した通り、混雑解析サーバＡＳは、各エリアＡにおける混雑度に関する混雑指標Ｉ_Ｃを取得する混雑指標取得部として機能する。以上のエリア抽出動作（混雑指標取得動作）により、人口（季節調整後の推計人口）が集中している混雑エリアＣＡと時間帯との組合せが抽出され、抽出エリアテーブル２３０に格納される。

１（４）−２． インデックス動作
図１１は、本実施形態のインデックス動作を示すフローチャートである。概略的には、インデックスサーバＩＳのインデックス部３００は、ブログサーバＢＳから取得した投稿情報ＰＩのうち、位置に関連する情報（ＰＯＩ名称又はジオタグ）を有する投稿情報ＰＩを抽出してインデックスする。「ＰＯＩ」はPoint of Interestの略であり、ランドマーク、史跡、店舗などの「人の興味を引く場所」を意味する。「ジオタグ」は緯度及び経度を示す情報であり、例えばＧＰＳ機能に基づいて取得される。

インデックス部３００は、ブログサーバＢＳから投稿情報ＰＩを取得する（S1110）。ブログサーバＢＳに投稿される全ての投稿情報ＰＩがインデックスサーバＩＳに提供されてもよいし、所定の条件に基づいて選択された投稿情報ＰＩがインデックスサーバＩＳに提供されてもよい。投稿情報ＰＩはリアルタイムに提供されてもよいし、所定の時間おきに提供されてもよい。

図１２に、ブログサーバＢＳから提供される投稿情報ＰＩの一例を示す。投稿情報ＰＩは、投稿を一意に識別する「投稿ＩＤ」フィールド、「投稿時刻」フィールド、投稿が行われた位置を示す「緯度」フィールド及び「経度」フィールド、並びに「投稿情報本文」フィールドを含む。「緯度」と「経度」のフィールドは、投稿ユーザの設定その他の要因により空欄である場合がある。

インデックス部３００は、取得した各投稿情報ＰＩについて、「投稿情報本文」フィールドの中に、辞書テーブル３１０（図１３）に登録されているＰＯＩ名称が含まれるか否かを判定する（S1120）。ＰＯＩ名称が含まれない場合（S1120；NO）、処理はステップS1150に進む。なお、ステップS1120において、投稿情報ＰＩが緯度及び経度を含む場合は、ＰＯＩ名称が含まれるか否かに関わらずステップS1150に進んでもよい。

一方、「投稿情報本文」フィールドにＰＯＩ名称が含まれる場合（S1120；YES）、インデックス部３００は、辞書テーブル３１０を参照して、そのＰＯＩ名称とそのＰＯＩ名称に対応するＰＯＩ識別子とをその投稿情報ＰＩに付与する（S1130）。そして、インデックス部３００は、そのＰＯＩ名称に対応する緯度及び経度をその投稿情報ＰＩに付与する（S1140）。以上の付与が実行された後の投稿情報ＰＩを、図１４に示す。図１４の例では、投稿ＩＤ9876543を有する投稿情報ＰＩについて、投稿情報本文に含まれる「金閣寺」というＰＯＩ名称に基づいて、「ＰＯＩ識別子」、「ＰＯＩ名称」、「緯度」、及び「経度」の各フィールドに値が付与されている。

なお、「投稿情報本文」フィールドにＰＯＩ名称が含まれる場合であって、当該投稿情報ＰＩに緯度及び経度が既に含まれるときには、ステップS1140の緯度経度付与がスキップされてもよい。また、「投稿情報本文」フィールドに複数のＰＯＩ名称が含まれる場合には、１つの投稿情報ＰＩに対して複数のＰＯＩ情報（ＰＯＩ識別子、ＰＯＩ名称、緯度、及び経度）が対応付けられてもよい。

次いで、インデックス部３００は、取得した投稿情報ＰＩが緯度及び経度を含むか否かを判定する（S1150）。緯度及び経度が含まれない場合（S1150；NO）、処理はステップS1110に戻り、新たな投稿情報ＰＩが取得される。

一方、投稿情報ＰＩに緯度及び経度が含まれる場合（S1150；YES）、インデックス部３００は、その緯度及び経度に対応するメッシュコードを特定してその投稿情報ＰＩに付与する（S1160）。その後、インデックス部３００は、投稿情報ＰＩを抽出投稿テーブル３２０に格納し、検索を容易にするためのインデックスを付与する（S1170）。図１５は、メッシュコードが付与され、抽出投稿テーブル３２０に格納された投稿情報ＰＩを示す図である。その後、動作はステップS1110に戻り、新たな投稿情報ＰＩが取得される。

以上のインデックス動作により、位置に関連する情報（地理的属性）を有する投稿情報ＰＩが抽出されインデックスされて抽出投稿テーブル３２０に格納される。

１（４）−３． 投稿情報解析動作
図１６は、本実施形態の投稿情報解析動作を示すフローチャートである。ウェブサーバＷＳの第２クエリ部２１２は、インデックスサーバＩＳ（抽出投稿テーブル３２０）から投稿情報ＰＩを取得し、ＰＯＩごと及び対象となる時間帯ごとに投稿情報ＰＩの合計投稿数Ｓ_Ｃを算出する。例えば、第２クエリ部２１２は、ＰＯＩ＝金閣寺、及び、対象時間帯＝2014/5/5 10:00:00〜2014/5/5 10:59:59について、投稿情報ＰＩの合計投稿数Ｓ_Ｃを算出する。そして、投稿情報ＰＩの合計投稿数が閾値Ｎ以上であるＰＯＩ及び対象時間帯の組合せ（上昇ＰＯＩ候補）をリストする（S1210）。

第２クエリ部２１２は、リストされたＰＯＩ及び対象時間帯の組合せの各々について、その対象時間帯を含む長期間（例えば１日）にわたる投稿情報ＰＩの合計投稿数Ｓ_Ｌを算出する（S1220）。例えば、第２クエリ部２１２は、ＰＯＩ＝金閣寺、及び、過去期間＝2014/5/4 11:00:00〜2014/5/5 10:59:59について、投稿情報ＰＩの合計投稿数Ｓ_Ｌを算出する。

第２クエリ部２１２は、リストされたＰＯＩ及び対象時間帯の組合せ（上昇ＰＯＩ候補）の各々について、以下の式３に従い、投稿数の量的変化を示す第２投稿指標Ｉ_Ｐ２（第２興味指標）を算出する（S1230）。
Ｉ_Ｐ２ ＝ ｌｏｇ｛Ｓ_Ｃ／（Ｓ_Ｌ＋Ｖ）｝ ……（式３）
なお、式３中の「Ｖ」は、正の値を取るスムージングパラメータであり、絶対的な投稿数が少ない場合に第２投稿指標Ｉ_Ｐ２をより小さく補正するための値である。

第２クエリ部２１２は、第２投稿指標Ｉ_Ｐ２に基づいてＰＯＩ及び対象時間帯の組合せを抽出し、投稿上昇テーブル２６０に格納する（S1240）。より具体的には、第２クエリ部２１２は、第２投稿指標Ｉ_Ｐ２に従ってソートした場合に第２順位（例えば、８位）以上となるＰＯＩ及び対象時間帯の組合せについて、時間帯、ＰＯＩ識別子、ＰＯＩ名称、メッシュコード、ＰＯＩの緯度、ＰＯＩの経度、及び第２投稿指標Ｉ_Ｐ２を含むエントリを生成して、投稿上昇テーブル２６０に格納する。図１７に、投稿上昇テーブル２６０の構成例を示す。

なお、ステップS1240において、第２クエリ部２１２が、第２投稿指標Ｉ_Ｐ２が第３閾値を上回るＰＯＩ及び対象時間帯の組合せを抽出し、投稿上昇テーブル２６０に格納してもよい。

その後、第２クエリ部２１２は、抽出されたＰＯＩ及び対象時間帯の組合せに対応する投稿情報ＰＩを、投稿情報テーブル２５０に格納する（S1250）。

以上の投稿情報解析動作により、投稿情報ＰＩの投稿数が上昇（増加）しているＰＯＩ及び時間帯の組合せ（上昇ＰＯＩ）が抽出され、投稿上昇テーブル２６０に格納される。

なお、以上の投稿情報解析動作においてはＰＯＩ単位で解析が実行されるが、メッシュコード（エリアＡ）単位で解析が実行される構成も採用可能である。すなわち、第２クエリ部２１２が、メッシュコードごと及び対象時間帯ごとにＳ_Ｃ、Ｓ_Ｌ、及び第２投稿指標Ｉ_Ｐ２（第２興味指標）を算出して上記の抽出動作を実行してもよい。この場合、ステップS1240においては、メッシュコード及び対象時間帯の組合せについて、時間帯、メッシュコード、メッシュの緯度（メッシュの左上点）、メッシュの経度（メッシュの右下点）、及び第２投稿指標Ｉ_Ｐ２を含むエントリが生成され格納される。

１（４）−４． 投稿情報保存動作
図１８は、本実施形態の投稿情報保存動作を示すフローチャートである。ウェブサーバＷＳのエリア取得部２２２は、抽出エリアテーブル２３０に含まれる混雑エリアＣＡに関する情報（混雑エリアＣＡのメッシュコード及び混雑が生じた対象時間帯の組合せ）を取得し、第３クエリ部２２４に供給する（S1310）。

第３クエリ部２２４は、エリア取得部２２２から供給されたメッシュコード及び対象時間帯に相当する投稿情報ＰＩ（すなわち、混雑エリアＣＡに対応する投稿情報ＰＩ）を、インデックスサーバＩＳの抽出投稿テーブル３２０から取得する（S1320）。次いで、第３クエリ部２２４は、取得した投稿情報ＰＩを投稿情報テーブル２５０に格納するのに加え、取得した投稿情報ＰＩが画像情報（インターネット上の画像ＵＲＬ等）を含む場合にはその画像情報が指し示す画像データを取得し、投稿情報ＰＩに含まれる投稿ＩＤと共に画像テーブル２４０に格納する（S1330）。

以上の投稿情報保存動作により、混雑エリアＣＡに対応する投稿情報ＰＩ及び関連画像がウェブサーバＷＳ内に記憶される。以上の構成によれば、インデックスサーバＩＳの抽出投稿テーブル３２０において古い投稿情報ＰＩが定期的に削除され、関連画像が時間の経過と共にインターネット上から失われても、クライアント端末ＣＬに提示される可能性のある投稿情報ＰＩ及び関連画像についてはウェブサーバＷＳ内に確保される。

なお、以上の投稿情報保存動作において、画像データ自体を取得しない構成も採用可能である。例えば、以上のステップS1330において、第３クエリ部２２４が、取得した投稿情報ＰＩに含まれるＵＲＬが画像に相当するものであるか否か（すなわち、投稿情報ＰＩに画像情報が含まれるか否か）を判定し、その判定結果（画像あり／画像なし）を示す情報を投稿ＩＤと共に画像テーブル２４０に格納してもよい。

１（４）−５． データ提示動作
ウェブサーバＷＳのデータ提示部２００は、前述の動作により各テーブル（２３０，２４０，２５０，２６０）に格納されたエントリに基づいて、クライアント端末ＣＬに種々のデータを提示する。

１（４）−５−１． 混雑エリアの提示動作
図１９は、混雑エリアＣＡをクライアント端末ＣＬに提示する動作のフローチャートである。データ提示部２００の第１クエリ部（第１興味指標取得部）２０２は、指定日時と指定表示範囲とを含む混雑エリア表示要求をクライアント端末ＣＬから受信すると（S1410）、その混雑エリア表示要求に対応するエントリ（混雑エリアＣＡ）を抽出エリアテーブル２３０から取得する（S1420）。すなわち、第１クエリ部２０２は、要求された指定表示範囲をメッシュコードに変換した後、指定日時を「時間帯」フィールドが示す期間に含み、かつ指定表示範囲に対応するメッシュコードのいずれかを「メッシュコード」フィールドに含む表示候補エントリを検索して取得する。取得された表示候補エントリは、場所提示部２０４に供給される。

次いで、第１クエリ部２０２は、取得された表示候補エントリが示す時間帯及びメッシュコードに対応する投稿情報ＰＩを投稿情報テーブル２５０から取得し（S1430）、各表示候補エントリに対応する投稿情報ＰＩの数を示す第１投稿指標Ｉ_Ｐ１（第１興味指標）を算定して場所提示部２０４に供給する（S1440）。

場所提示部２０４は、混雑指標Ｉ_Ｃに基づいて抽出された表示候補エントリのうち、第１投稿指標Ｉ_Ｐ１が第２閾値を上回るエントリに対応する混雑エリアＣＡ（時間帯及びメッシュコード）を、クライアント端末ＣＬに提示する（S1450）。すなわち、場所提示部２０４は、クライアント端末ＣＬのディスプレイ上に、電子地図と共に混雑エリアＣＡを第１態様で表示させる制御信号をクライアント端末ＣＬに送信する。

その後、クライアント端末ＣＬは、場所提示部２０４から受信した制御信号に従って混雑エリアＣＡをディスプレイ上に表示する。図２０は、ディスプレイに表示される画像Ｇの一例である。画像Ｇは、日時指定部ＤＤと電子地図部ＥＭと情報表示部ＩＤとを備える。日時指定部ＤＤは、表示要求における指定日時を指定する部分であり、日付指定用のカレンダーと時間指定用のスライダーとを含む。

電子地図部ＥＭは、電子地図及び混雑エリアＣＡの表示領域であるのに加え、表示要求における指定表示範囲を指定する部分である。電子地図部ＥＭに表示される電子地図をマウス等によりスクロールさせることで、混雑エリア表示要求に含まれる指定表示範囲も変化する。図２０に示されるように、電子地図部ＥＭには、ステップS1450で提示された混雑エリアＣＡ（時間帯及びメッシュコード）に対応する混雑ボックスＢ１が表示される。混雑ボックスＢ１は、第１態様の一例である。情報表示部ＩＤの詳細は後述される。

１（４）−５−２． 投稿数上昇場所の提示動作
図２１は、投稿情報ＰＩの投稿数が上昇しているＰＯＩ（上昇ＰＯＩ）をクライアント端末ＣＬに提示する動作のフローチャートである。第１クエリ部２０２は、指定日時と指定表示範囲とを含む上昇ＰＯＩ表示要求をクライアント端末ＣＬから受信すると（S1510）、その上昇ＰＯＩ表示要求に対応するエントリを投稿上昇テーブル２６０から取得する（S1520）。すなわち、第１クエリ部２０２は、指定日時を「時間帯」フィールドが示す期間に含み、かつ「緯度」フィールド及び「経度」フィールドが示す緯度経度が指定表示範囲に含まれる表示対象エントリを検索して取得する。取得された表示対象エントリは、場所提示部２０４に供給される。

場所提示部２０４は、取得された表示対象エントリに対応する上昇ＰＯＩ（時間帯及び緯度経度）を、クライアント端末ＣＬに提示する（S1530）。すなわち、場所提示部２０４は、クライアント端末ＣＬのディスプレイ上に、電子地図と共に上昇ＰＯＩを第２態様で表示させる制御信号をクライアント端末ＣＬに送信する。

その後、クライアント端末ＣＬは、場所提示部２０４から受信した制御信号に従って上昇ＰＯＩをディスプレイ上に表示する。図２２は、ディスプレイに表示される画像Ｇの一例であり、図２０と同様の部分（ＤＤ，ＥＭ，ＩＤ）を備える。図２２に示されるように、電子地図部ＥＭには、ステップS1530で提示された上昇ＰＯＩ（時間帯及び緯度経度）に対応する上昇ボックスＢ２が表示される。上昇ボックスＢ２は、第１態様とは異なる第２態様の一例である。

なお、前述の投稿情報解析動作（項目１（４）−３）と同様、以上の提示動作を、投稿情報ＰＩの投稿数が上昇しているエリアＡ（上昇エリア）について実行する構成も採用可能である。さらに、上昇ＰＯＩについての提示動作と上昇エリアについての提示動作とを併せて実行する構成も採用可能である。

１（４）−５−３． 混雑関連情報の提示動作
図２３は、混雑エリアＣＡの混雑状況に関連する混雑関連情報ＣＩをクライアント端末ＣＬに提示する動作のフローチャートである。第１クエリ部２０２は、特定の混雑エリアＣＡを指定する情報表示要求をクライアント端末ＣＬから受信すると（S1610）、その混雑エリアＣＡ（メッシュコード及び時間帯）に対応付けられる投稿情報ＰＩを投稿情報テーブル２５０から取得して、情報提示部２０６に供給する（S1620）。ステップS1610の情報表示要求は、例えば、電子地図部ＥＭに表示される混雑ボックスＢ１をユーザがマウス等の入力デバイスにより選択すると生成される。

情報提示部２０６は、供給された投稿情報ＰＩを混雑関連情報ＣＩとして扱う。混雑エリアＣＡに対応付けられる投稿情報ＰＩは、その混雑エリアＣＡの混雑状況や混雑理由に関連する可能性が高いからである。情報提示部２０６は、混雑エリアＣＡについて取得された混雑関連情報ＣＩの各々について、情報的価値に応じた優先度を決定する（S1630）。以上の優先度は、任意に決定され得る。以下に、優先度の決定手法の例を非限定的に列挙する。複数の優先度決定手法が併用されてもよい。
−混雑関連情報ＣＩの投稿時刻が新しいほど優先度を高める
−混雑関連情報ＣＩが共有された（リツイート又はシェアされた）回数が多いほど優先度を高める
−画像（画像リンクＵＲＬ）が含まれる混雑関連情報ＣＩの優先度を高める
−混雑エリアＣＡ内のＰＯＩ名称が含まれる混雑関連情報ＣＩの優先度を高める

情報提示部２０６は、優先度に従ってクライアント端末ＣＬに混雑関連情報ＣＩを提示する（S1640）。例えば、情報提示部２０６は、優先度に従ってソートした混雑関連情報ＣＩをクライアント端末ＣＬに提示してもよいし、優先度が最も高い混雑関連情報ＣＩをクライアント端末ＣＬに提示してもよい。

その後、クライアント端末ＣＬは、情報提示部２０６から提示された混雑関連情報ＣＩをディスプレイ（情報表示部ＩＤ）上に表示する。図２４は、ディスプレイに表示される画像Ｇの一例である。情報表示部ＩＤには、投稿時刻に従って優先度が付与された混雑関連情報ＣＩが表示される。なお、混雑関連情報ＣＩ（投稿情報ＰＩ）に対応する画像データは、情報提示部２０６が、画像テーブル２４０から取得してクライアント端末ＣＬに提示してもよいし、混雑関連情報ＣＩに含まれる画像情報（画像リンクＵＲＬ）に基づいてインターネット上から取得して提示してもよい。また、情報提示部２０６から提示された混雑関連情報ＣＩに基づいてクライアント端末ＣＬがインターネット上から取得してもよい。

なお、以上の動作により、混雑エリアＣＡに対応する投稿情報ＰＩ（混雑関連情報ＣＩ）が電子地図と共に表示されるが、上昇ＰＯＩ（又は上昇メッシュ）に対応する投稿情報ＰＩについても、同様の動作に基づいて表示させることが可能である。

１（５）． 本実施形態の効果
以上の本実施形態の構成によれば、人口が集中している混雑エリアＣＡと、その混雑エリアＣＡの混雑状況に関連する混雑関連情報ＣＩとが、併せてクライアント端末ＣＬに提示され、電子地図と共に表示される。したがって、人口が集中しているエリアのみが提示される構成と比較して、ユーザへ提供される情報の価値がより高い。

本実施形態では、混雑エリアＣＡに加えて、投稿情報ＰＩの投稿数が上昇している場所（上昇ＰＯＩ又は上昇エリア）がクライアント端末ＣＬに提示され、電子地図と共に表示される。すなわち、実際に混雑してはいないが、多くの人の興味を引いている場所がユーザへ通知される。

本実施形態では、情報的価値に応じた優先度に従って混雑関連情報ＣＩが提示される。したがって、より意味のある情報が優先してユーザへ提供される。

２． 変形例
以上の実施形態は多様に変形される。具体的な変形の態様を以下に例示する。以上の実施の形態および以下の例示から任意に選択された２以上の態様は、相互に矛盾しない限り適宜に併合され得る。

２（１）． 変形例１（興味情報）
投稿情報ＰＩ以外の様々な情報が、興味情報として採用され得る。例えば、インターネット検索サービスを提供する検索サーバに入力される検索履歴ＳＨが、興味情報として用いられ得る。検索履歴ＳＨは、ブログサーバＢＳから提供される投稿情報ＰＩと同様に、「検索時刻」、検索が行われた位置を示す「緯度」及び「経度」、並びに「検索ワード」を情報項目（フィールド）として含む。したがって、インデックスサーバＩＳが検索サーバから検索履歴ＳＨを取得することにより、前述の実施形態と同様の動作を実現することが可能である。

また、ＰＯＩに関連する情報を提供するＰＯＩ情報サーバへのアクセス履歴ＡＨが、興味情報として用いられ得る。以上のアクセス履歴ＡＨは、「アクセス時刻」、アクセスが行われた位置を示す「緯度」及び「経度」、並びに「アクセス対象ＰＯＩ」を情報項目（フィールド）として含む。したがって、インデックスサーバＩＳがＰＯＩ情報サーバからアクセス履歴ＡＨを取得することにより、前述の実施形態と同様の動作を実現することが可能である。

さらに、２以上の情報を組み合わせて興味情報としてもよい。より具体的には、インデックスサーバＩＳが、複数のサーバ（ブログサーバＢＳ、検索サーバ、ＰＯＩ情報サーバ等）から、地理的属性を有する複数種類の情報（投稿情報ＰＩ、検索履歴ＳＨ、アクセス履歴ＡＨ等）を取得して記憶し、ウェブサーバＷＳが実行する場所提示及び情報提示の用に供してもよい。なお、興味指標（第１興味指標及び第２興味指標）の算出において、情報の種別に応じて重み付けが行われてもよい。

２（２）． 変形例２（混雑指標）
以上の実施形態では、推計人口（混雑度）の時系列的な変化を示すパラメータ（σ_sadj，Ｍ_sadj，又はこれらの組合せ）が混雑指標Ｉ_Ｃとして採用されるが、推計人口（混雑度）そのものが混雑指標Ｉ_Ｃとして採用されてもよい。

２（３）． 変形例３（第１興味指標）
以上の実施形態において、第１投稿指標Ｉ_Ｐ１（第１興味指標）は、指定時間帯における混雑エリアＣＡの投稿情報ＰＩの数を示す。しかし、投稿情報ＰＩの伝搬力を示す指標（例えば、投稿情報ＰＩが共有された回数（リツイート数））を第１投稿指標Ｉ_Ｐ１が示してもよい。

２（４）． 変形例４（混雑関連情報）
以上の実施形態（ステップS1610〜S1640）では、投稿情報ＰＩが混雑関連情報ＣＩとしてクライアント端末ＣＬに提示されるが、以下に示すようなその他の情報が混雑関連情報ＣＩとして提示されてもよい。

２（４）−１． イベント名称の提示
情報提示部２０６は、混雑エリアＣＡ（メッシュコード及び時間帯）に対応付けられる投稿情報ＰＩに含まれるイベント名称を、混雑関連情報ＣＩとして提示してもよい。イベント名称は、予めウェブサーバＷＳに記憶されたイベント名称辞書データと投稿情報ＰＩからの抽出語との突合によって取得されてもよいし、構文解析によって取得されてもよい。構文解析の例として、イベント名称と共に用いられる傾向のある文字列（例えば、『（イベント名称）が開催』や『（イベント名称）に参加』）に前置される名詞を、イベント名称として取得する構成が挙げられる。

なお、複数のイベント名称が取得された場合には、イベントの優先度に基づいてクライアント端末ＣＬにイベント名称が提示されると好適である。以上の優先度に関しては、例えば、イベント名称を含む投稿情報ＰＩの数が多いほど、そのイベントの優先度が高く決定される。

２（４）−２． 写真画像の提示
情報提示部２０６は、混雑エリアＣＡに対応付けられる投稿情報ＰＩにリンクされる写真画像を、混雑関連情報ＣＩとして提示してもよい。複数の写真画像が存在する場合は、人物認識処理により取得される画像内の人数が多いほど高くなる優先度に基づいて、写真画像がクライアント端末ＣＬに提示されると好適である。

２（５）． 変形例５（エリア）
メッシュ以外の領域もエリアＡとして採用され得る。例えば、所定のランドマークを中心とする円状の領域をエリアＡとしてもよい。また、建造物や公園等のスポットの外縁に囲まれる領域をエリアＡとしてもよい。

２（６）． 変形例６（提示システムおよび提示装置）
以上の実施形態では、提示システムＰＳにおいて混雑解析サーバＡＳとウェブサーバＷＳとが別個に存在するが、混雑解析サーバＡＳとウェブサーバＷＳとが１つの提示装置として構成されてもよい。ただし、混雑解析サーバＡＳには携帯電話ユーザの行動を示す個人情報が含まれる一方、ウェブサーバＷＳには統計処理された情報のみが記憶され、外部に公開されるという特徴があるため、セキュリティ上は、以上の各サーバを別個に設ける実施形態の構成が好適である。

他方、各サーバ（混雑解析サーバＡＳ，ウェブサーバＷＳ等）が、ネットワークによって相互に接続される複数のコンピュータ装置によって実現されてもよい。

提示システムＰＳに、インデックスサーバＩＳが含まれる構成も採用可能である。

２（７）． 変形例７（提示装置としてのクライアント端末）
混雑解析サーバＡＳ及びウェブサーバＷＳにおいて実行される前述の動作は、クライアント端末ＣＬにて実行されてもよい。すなわち、クライアント端末ＣＬは、提示装置として機能し得る。

２（８）． 変形例８（ソート処理）
以上の実施形態（ステップS1050）では、値が大きいほど混雑上昇の度合いも高い混雑指標Ｉ_Ｃが降順にソートされてエントリの順位が決定される。しかし、値が小さいほど混雑上昇の度合いが高い混雑指標Ｉ_Ｃが採用され、混雑指標Ｉ_Ｃが昇順にソートされてエントリの順位が決定されてもよい。ステップS1240における第２投稿指標Ｉ_Ｐ２に従ったソートに関しても同様である。

２（９）． 変形例９（第１興味指標に従ったソート）
ステップS1240では、投稿数の量的変化を示す第２投稿指標Ｉ_Ｐ２（第２興味指標）に従ってソートが実行されるが、投稿数を示す第１投稿指標Ｉ_Ｐ１（第１興味指標）に従ってソートが実行されてもよい。

２（１０）． 変形例１０（可変閾値）
第１閾値及び第２閾値は可変に設定されてもよい。例えば、混雑指標Ｉ_Ｃが高いほど第１投稿指標Ｉ_Ｐ１（第１興味指標）に関する第２閾値が低く設定され、第１投稿指標Ｉ_Ｐ１が高いほど混雑指標Ｉ_Ｃに関する第１閾値が設定されると好適である。以上の構成によれば、第１閾値及び第２閾値を用いた二重の条件による混雑エリア判定において、一方の閾値と対比される値が高まるほど他方の閾値が低下するため、二重の条件が充足され易くなる。したがって、混雑エリアＣＡと判定されるケースが増大し、ひいてはユーザに対して提示される情報量が増大する。

他方、混雑指標Ｉ_Ｃが高いほど第１投稿指標Ｉ_Ｐ１（第１興味指標）に関する第２閾値が高く設定されてもよく、第１投稿指標Ｉ_Ｐ１が高いほど混雑指標Ｉ_Ｃに関する第１閾値が高く設定されてもよい。一般的に、エリアＡについての混雑指標Ｉ_Ｃと第１投稿指標Ｉ_Ｐ１とは正の相関を有すると見込まれるため、一方の閾値と対比される値が高まるほど他方の閾値も高く設定することにより、混雑エリアＣＡの判定精度を高められる。

また、第１投稿指標Ｉ_Ｐ１（第１興味指標）に関する第２閾値が、他の指標に基づいて可変に設定されてもよい。例えば、エリアＡに割り当てられた都会度に関する指標（例えば、人口密度）が高いほど、そのエリアＡの第２閾値が高く設定されてもよい。

２（１１）． 変形例１１（第３態様によるエリア提示）
混雑エリアＣＡに関して、更なる提示態様が採用されてもよい。例えば、混雑指標Ｉ_Ｃが第１閾値を上回り、かつ投稿数の量的変化を示す第２投稿指標Ｉ_Ｐ２が第３閾値を上回るエリアＡを、場所提示部２０４が第３態様で提示する。すなわち、場所提示部２０４は、電子地図部ＥＭ上のそのエリアＡに、混雑ボックスＢ１ではなく注目ボックスＢ３（図２５）を表示させる制御信号を、クライアント端末ＣＬに送信する。以上の構成によれば、人口の集中が発生しており、かつ投稿数も上昇しているエリアＡが明示的に提示される。

２（１２）． 変形例１２（第４態様によるエリア提示）
電子地図部ＥＭに、混雑エリアＣＡ及び投稿数上昇場所（上昇ＰＯＩ，上昇メッシュ）に加え、イベント情報が表示されてもよい。図２６に示すように、本変形例のウェブサーバＷＳは、イベント情報エントリを記憶するイベント情報テーブル２７０を更に備える。イベント情報エントリは、イベント名称、イベントの開催日時、及びイベントの開催場所の地理的属性（ＰＯＩ，緯度経度）を含む。

第１クエリ部２０２は、指定日時と指定表示範囲とを含むイベント表示要求をクライアント端末ＣＬから受信すると、その指定日時と指定表示範囲とに対応するイベント情報エントリをイベント情報テーブル２７０から取得して、場所提示部２０４に供給する。場所提示部２０４は、取得されたイベント情報エントリに対応するエリアＡをクライアント端末ＣＬに提示する。すなわち、場所提示部２０４は、クライアント端末ＣＬのディスプレイ上にイベントが開催されるエリアＡを第４態様で表示させる制御信号を送信する。ディスプレイの電子地図部ＥＭには、当該エリアＡに対応するイベントボックスＢ４（図２７）が表示される。以上の構成によれば、イベントが開催される場所及び日時が明示的に提示される。

なお、場所提示部２０４は、イベント情報エントリに対応するエリアＡについて、当該エリアＡの投稿数を示す第１投稿指標Ｉ_Ｐ１が第４閾値を上回る場合にのみ、当該エリアＡを提示してもよい。第４閾値は、ステップS1450の第２閾値と等しくてもよいし、異なる値に設定されてもよい。以上の構成によれば、投稿数が基準に満たないイベントに関してはクライアント端末ＣＬに提示されないので、実際に話題となっているイベントが選別される。

２（１３）． 変形例１３（投稿数上昇場所の非提示）
投稿情報ＰＩの投稿数が上昇している場所（上昇ＰＯＩ又は上昇エリア）をクライアント端末ＣＬに提示しない構成（混雑エリアＣＡのみを提示する構成）も採用可能である。以上の場合、上昇ＰＯＩ又は上昇エリアを特定する投稿情報解析動作も不要であることは当然に理解される。

２（１４）． 変形例１４（ボックスサイズの変化）
混雑指標Ｉ_Ｃに応じて、混雑エリアＣＡの提示対応が変化してもよい。例えば、混雑指標Ｉ_Ｃが高いほど、混雑ボックスＢ１が大きく表示されてもよい。同様に、第１投稿指標Ｉ_Ｐ１又は第２投稿指標Ｉ_Ｐ２に応じて、上昇ＰＯＩ又は上昇エリアの提示態様（例えば、上昇ボックスＢ２の大きさ）が変化してもよい。

２（１５）． 変形例１５（複数ボックスの統合）
電子地図の縮尺が変更され、所定の狭い領域に複数のボックスを表示しなければならない場合、複数のボックスをまとめて１つの統合ボックスとし、本来表示されるべきボックスの合計数と共に表示すると好適である。

２（１６）． 変形例１６（エリア指示の態様）
以上の実施形態では、混雑ボックスＢ１等のボックスが表示されることによってエリアＡが指し示される。しかしながら、ボックス以外の態様（例えば、エリアＡの表示色の変化）によってエリアＡが指し示されてもよい。

２（１７）． 変形例１７（場所提示の態様）
場所提示部２０４が実行する場所提示の態様は、電子地図上のボックス表示に限られない。例えば、ステップS1450において、場所提示部２０４が、混雑エリアＣＡを所定順序（例えば、混雑指標Ｉ_Ｃが高い順序）のリスト形式で表示させるようにクライアント端末ＣＬを制御してもよい。すなわち、混雑エリアＣＡのリストは第１態様の一例である。

以上の混雑エリアＣＡのリストは、単独で（すなわち、電子地図とは独立して）クライアント端末ＣＬのディスプレイに表示されてもよく、電子地図と共に表示されてもよい。リストが電子地図と共に表示される場合、ユーザがリスト上の混雑エリアＣＡの１つを選択するのに応じて、その混雑エリアＣＡに対応する電子地図上の位置に混雑ボックスＢ１が表示されるとより好適である。

同様に、場所提示部２０４は、投稿情報ＰＩの投稿数が上昇している上昇ＰＯＩ又は上昇エリアに関しても、リスト形式で表示させるようにクライアント端末ＣＬを制御してもよい。すなわち、上昇ＰＯＩ又は上昇エリアのリストは第２態様の一例である。また、変形例１１及び１２について前述した場所提示についても、上述と同様のリスト形式の表示が採用され得る。

２（１８）． 変形例１８（ＣＰＵ以外のデバイス）
コンピュータ装置、特に、混雑解析サーバＡＳ、ウェブサーバＷＳ、及びインデックスサーバＩＳにおいてＣＰＵが実行する各機能は、ＦＰＧＡ（Field Programmable Gate Array）またはＤＳＰ（Digital Signal Processor）等のプログラマブルロジックデバイスで実行されてもよい。

１０……ネットワークインタフェース、１２……入力部、１４……出力部、１６……ＣＰＵ、１８……ＲＡＭ、２０……ＲＯＭ、２２……ＨＤＤ、３０……ネットワークインタフェース、３２……入力部、３４……出力部、３６……ＣＰＵ、３８……ＲＡＭ、４０……ＲＯＭ、４２……ＨＤＤ、１００……人口推計部、１１０……配列化処理部、１２０……季節調整部、１３０……エリア抽出部、１４０……推計人口テーブル、１５０……配列テーブル、１６０……調整後人口テーブル、２００……データ提示部、２０２……第１クエリ部、２０４……場所提示部、２０６……情報提示部、２１０……投稿情報解析部、２１２……第２クエリ部、２２０……投稿情報保存部、２２２……エリア取得部、２２４……第３クエリ部、２３０……抽出エリアテーブル、２４０……画像テーブル、２５０……投稿情報テーブル、２６０……投稿上昇テーブル、３００……インデックス部、３１０……辞書テーブル、３２０……抽出投稿テーブル、Ａ……エリア、ＡＳ……混雑解析サーバ、ＢＳ……ブログサーバ、ＣＡ……混雑エリア、ＣＩ……混雑関連情報、ＣＬ……クライアント端末、ＤＤ……日時指定部、ＥＭ……電子地図部、Ｇ……画像、ＩＤ……情報表示部、ＩＳ……インデックスサーバ、ＬＳ……位置情報サーバ、ＰＩ……投稿情報、ＰＳ……提示システム、ＷＳ……ウェブサーバ。

Claims (9)

1. 電子地図上の各エリアにおける混雑度に関する混雑指標を取得する混雑指標取得部と、
   地理的属性を有する興味情報に関する第１興味指標を取得する第１興味指標取得部と、
   前記混雑指標及び前記第１興味指標に応じて前記エリアを提示する場所提示部と、
   前記場所提示部が提示する前記エリアに対応付けられる前記興味情報に基づいて混雑関連情報を提示する情報提示部と
   を備える提示システム。
2. 前記興味情報の量的変化を示す第２興味指標を取得する第２興味指標取得部をさらに備え、
   前記場所提示部は、
   前記混雑指標が第１閾値を上回りかつ前記第１興味指標が第２閾値を上回るエリアを第１態様で提示し、
   前記第２興味指標が第３閾値を上回る前記電子地図上の興味点（Point of Interest）またはエリアを前記第１態様とは異なる第２態様で提示する
   請求項１の提示システム。
3. 前記場所提示部は、
   前記混雑指標が前記第１閾値を上回りかつ前記第２興味指標が前記第３閾値を上回るエリアを前記第１態様とは異なる第３態様で提示する
   請求項２の提示システム。
4. 前記混雑指標に応じて前記第２閾値が設定され、前記第１興味指標に応じて前記第１閾値が設定される
   請求項２または３の提示システム。
5. 前記興味情報の量的変化を示す第２興味指標を取得する第２興味指標取得部をさらに備え、
   前記場所提示部は、
   複数の前記エリアを前記混雑指標に従ってソートした場合に第１順位以上となりかつ前記第１興味指標が閾値を上回るエリアの各々を第１態様で提示し、
   前記電子地図上の複数の興味点または複数の前記エリアを前記第１興味指標および前記第２興味指標のいずれかに従ってソートした場合に第２順位以上となる興味点またはエリアの各々を前記第１態様とは異なる第２態様で提示する
   請求項１の提示システム。
6. 前記情報提示部は、
   前記エリアについて取得された前記混雑関連情報の各々について、当該混雑関連情報の情報的価値に応じた優先度を決定し、
   決定された前記優先度に従って前記混雑関連情報の少なくともいずれかを提示する
   請求項１から５のいずれかの提示システム。
7. 地理的属性を有するイベント情報を記憶するイベント情報記憶部を備え、
   前記場所提示部は、
   前記イベント情報に含まれる前記地理的属性が前記エリアに対応付けられ、かつ当該エリアの前記第１興味指標が第４閾値を上回る場合に、当該エリアを第４態様で提示する
   請求項１から６のいずれかの提示システム。
8. 電子地図上の各エリアにおける混雑度に関する混雑指標を取得する混雑指標取得部と、
   地理的属性を有する興味情報に関する第１興味指標を取得する第１興味指標取得部と、
   前記混雑指標及び前記第１興味指標に応じて前記エリアを提示する場所提示部と、
   前記場所提示部が提示する前記エリアに対応付けられる前記興味情報に基づいて混雑関連情報を提示する情報提示部と
   を備える提示装置。
9. 電子地図上の各エリアにおける混雑度に関する混雑指標を取得することと、
   地理的属性を有する興味情報に関する第１興味指標を取得することと、
   前記混雑指標及び前記第１興味指標に応じて前記エリアを提示することと、
   提示されるべき前記エリアに対応付けられる前記興味情報に基づいて混雑関連情報を提示することと
   を備える提示方法。

Images