(58)【調査した分野】(Int.Cl.,DB名)
【発明を実施するための形態】
【0011】
以下、図面を参照しながら本発明の実施形態を詳細に説明する。
【0012】
1. 第1実施形態
1(1). 提示システムの概略
図1は、本発明の第1実施形態に係る提示システムPSと、提示システムPSに関係する複数のコンピュータ装置とを概略的に示す。本実施形態のコンピュータ装置は、所定のプロトコル(TCP/IP等)に従って通信する。提示システムPSは、位置情報サーバLS及びインデックスサーバISから取得した情報に基づいて、混雑している混雑エリアCAとその混雑エリアCAに関する混雑関連情報CIとをクライアント端末CLに提示する。本実施形態の混雑関連情報CIは、混雑エリアCAの混雑理由を示す情報である。
【0013】
提示システムPSは、混雑解析サーバASとウェブサーバWSとを備える。混雑解析サーバASは、位置情報サーバLSから提供されるユーザ(携帯端末)の位置情報Lを解析して、人口が集中している混雑エリアCAを時系列的に特定する。ウェブサーバWSは、混雑エリアCAと混雑関連情報CIとをクライアント端末CLに提示する。
【0014】
また、ウェブサーバWSは、インデックスサーバISから提供される投稿情報PIを解析して投稿情報PIの投稿数が上昇している場所を特定し、クライアント端末CLに提示する。以上の投稿情報PIは、ブログサーバBSからインデックスサーバISに供給される。本実施形態における投稿情報PIは、投稿ユーザの興味を示す興味情報である。
【0015】
ブログサーバBSは、ユーザ端末(たとえば、スマートフォン)からの投稿情報PIを受信して記憶し、外部からの要求に応じて投稿情報PIを提供する。以下、本実施形態における投稿情報PIの例を、非限定的に列挙する。
−マイクロブログサービス(例えば、Twitter[登録商標])における140文字以下の短文投稿(例えば、ツイート[登録商標])
−ブログ(ウェブログ)サービスにおける日記や寸評等の投稿
−ソーシャルネットワーキングサービス(SNS)におけるステータス投稿
【0016】
クライアント端末CLは、ユーザからの要求に応じてディスプレイに電子地図を表示する。加えて、クライアント端末CLは、ウェブサーバWSから提示された混雑エリアCAを電子地図上に表示する。また、クライアント端末CLは、混雑エリアCAに対応付けられる混雑関連情報CIを電子地図と併せて表示する。
【0017】
電子地図の表示に用いられる電子地図データは、ユーザからの要求に応じてクライアント端末CLが地図サーバ(不図示)から取得してもよいし、予めクライアント端末CLに記憶されていてもよい。また、混雑エリアCA及び混雑関連情報CIと共に、ウェブサーバWSからクライアント端末CLに提供されてもよい。その場合、ウェブサーバWSは予め電子地図データを記憶していてもよいし、地図サーバから、都度又は定期的に取得してもよい。
【0018】
1(2). 物理的構成
1(2)−1. サーバの構成
図2は、混雑解析サーバAS及びウェブサーバWSを始めとする本実施形態のサーバの物理的構成を示すブロック図である。各サーバ(AS,WS,LS,IS,BS)は、ネットワークインタフェース10と入力部12と出力部14とCPU(Central Processing Unit)16とRAM(Random Access Memory)18とROM(Read Only Memory)20とHDD(Hard Disk Drive)22とを備える。
【0019】
ネットワークインタフェース10は、ネットワークを介して他のコンピュータ装置と通信を実行する。入力部12は、キーボード等の入力装置からの入力信号を受け付ける。出力部14は、ディスプレイ等の出力装置に対して出力信号を送信する。CPU16は、主記憶装置であるRAM18及びROM20に記憶されているプログラムを実行することにより種々の制御及び演算を行う。HDD22は、RAM18上に展開可能なプログラム及びデータを記憶する補助記憶装置である。なお、HDD22に代えて又は加えてSSD等の記憶媒体が採用されてもよい。
【0020】
当業者が当然に理解する通り、1つのサーバが複数のコンピュータ装置によって構成されてもよいし、1つのコンピュータ装置が仮想化された複数のサーバを備えてもよい。
【0021】
1(2)−2. クライアント端末の構成
図3は、本実施形態のクライアント端末CLの物理的構成を示すブロック図である。クライアント端末CLは、ネットワークインタフェース30と入力部32と出力部34とCPU36とRAM38とROM40とHDD42とを備える。以上の各要素は、各サーバが備える、
図2を参照して説明された要素と同様の構成を有する。
【0022】
1(3). 論理的構成
図4は、第1実施形態の提示システムPSの論理的構成を示すブロック図である。混雑解析サーバASは、エリアAごとに人口を推計する人口推計部100と、推計人口を配列化する配列化処理部110と、推計人口の季節調整処理を実行する季節調整部120と、混雑エリアCAを抽出するエリア抽出部130とを機能ブロックとして備えると共に、推計人口テーブル140と配列テーブル150と調整後人口テーブル160とを論理テーブルとして備える。
【0023】
ウェブサーバWSは、クライアント端末CLに種々のデータを提示するデータ提示部200と、インデックスサーバISから取得した投稿情報PIを解析する投稿情報解析部210と、混雑エリアCAに関する投稿情報PIを保存する投稿情報保存部220とを機能ブロックとして備えると共に、抽出エリアテーブル230と画像テーブル240と投稿情報テーブル250と投稿上昇テーブル260とを論理テーブルとして備える。
【0024】
データ提示部200は第1クエリ部(第1興味指標取得部)202と場所提示部204と情報提示部206とを備える。投稿情報解析部210は第2クエリ部(第2興味指標取得部)212を備える。投稿情報保存部220はエリア取得部222と第3クエリ部224とを備える。
【0025】
インデックスサーバISは、ブログサーバBSから取得した投稿情報PIを処理してインデックスを付与するインデックス部300を機能ブロックとして備えると共に、辞書テーブル310と抽出投稿テーブル320と論理テーブルとして備える。
【0026】
以上の機能ブロックは、各サーバ(AS,WS,IS)の主記憶装置に記憶されているコンピュータプログラムをCPU16が実行することにより実現される。また、以上の論理テーブルは、複数のテーブルが所定の関係(リレーション)に基づいて連結される関係データベースの構成要素である。関係データベースは、不揮発性メモリであるHDD22にデータが記憶されるオンディスクデータベースで実装されてもよいし、揮発性メモリであるRAM18にデータが記憶されるインメモリデータベースで実装されてもよい。
【0027】
1(4). エリア提示動作
本実施形態のエリア提示動作を以下に説明する。エリア提示動作は、エリア抽出動作、インデックス動作、投稿情報解析動作、投稿情報保存動作、及びデータ提示動作を含む。
【0028】
1(4)−1. エリア抽出動作(混雑指標取得動作)
図5は、本実施形態のエリア抽出動作を示すフローチャートである。混雑解析サーバASの人口推計部100は、位置情報サーバLSから携帯端末ユーザの位置情報Lを取得する(S1010)。
図6に、位置情報サーバLSから提供される位置情報Lの具体的構成の一例を示す。位置情報Lは、ある時刻における携帯端末の位置(緯度経度)を示す複数のエントリを含む。各エントリは、携帯端末のユーザ識別子を示す「ユーザID」フィールド、携帯端末の緯度を示す「緯度」フィールド、携帯端末の経度を示す「経度」フィールド、及び携帯端末が測位を実施した時刻を示す「測位時刻」フィールドを有する。
【0029】
人口推計部100は、位置情報Lに基づいて、エリアAごと及び時間帯ごとに推計人口を算出する(S1020)。本ステップでは任意の推計手法が採用され得るが、例えば、エリアA内に実際に存在するユーザの数に、全人口に占める当該キャリアのユーザの割合の逆数を乗算することにより、推計人口を算出することが可能である。
【0030】
本実施形態において、エリアAは、緯度及び経度に基づいて分割された網目状の領域(メッシュ)である。以上のメッシュは、日本国の総務省統計局が提供する標準地域メッシュ(例えば、4分の1地域メッシュ)であってもよいし、他の手法により画定されたメッシュであってもよい。
【0031】
図7は、人口推計部100が算出した推計人口が格納される推計人口テーブル140の一例である。推計人口テーブル140の各エントリは、推計人口の算定対象を示す「時間帯」フィールド及び「メッシュコード」フィールド、算定された推計人口値を示す「推計人口」フィールド、並びにメッシュコードが含まれる都道府県を示す「都道府県」フィールドを含む。
【0032】
なお、
図7の推計人口テーブル140では、各時間帯の時間幅として1時間が採用されるが、任意の時間長が採用され得ることは当然に理解される。また、あるメッシュ(エリアA)のメッシュコードが決まれば、そのメッシュが属する都道府県を確定することができるので、推計人口テーブル140において「都道府県」フィールドは必須の情報項目ではない。なお、1つのメッシュコードに対応するメッシュが2以上の都道府県に跨がる場合は、そのメッシュにおいて最も広い面積を示す都道府県をそのメッシュコードに相当する都道府県としてもよいし、そのメッシュ内の所定の点(例えば、中心点)が属する都道府県をそのメッシュコードに相当する都道府県としてもよい。
【0033】
配列化処理部110は、エリアA(メッシュコード)ごとに推計人口を配列化する(S1030)。すなわち、配列化処理部110は、メッシュコードが同じ複数のエントリに含まれる推計人口値を1つの配列(同一タイプの複数データを含み得るデータ構造)に格納する。そして、格納された配列を示す「推計人口配列」フィールドを含む1つのエントリを作成して配列テーブル150に格納する。以上の配列化処理によってエントリ数が低減されることで、後続する処理の演算負荷が削減される。なお、演算負荷を更に削減するため、推計人口が所定閾値を上回るエリアAのみを以上の配列化処理の対象としてもよい。
【0034】
図8に示すように、配列テーブル150内の各エントリは、「推計人口配列」フィールドに加え、「メッシュコード」フィールド、「都道府県」フィールド、配列の第1番目の要素に対応する時間帯の開始時刻を示す「開始時刻」フィールド、及び各時間帯の時間幅を示す「時間幅」フィールドを含む。
【0035】
季節調整部120は、配列テーブル150に含まれる各エントリについて、季節調整処理を実行する(S1040)。季節調整処理とは、時系列データ(原系列)から周期的成分(季節変動)による影響を除去する処理である。本ステップでは任意の季節調整手法が採用され得る。例えば、季節調整部120が、各メッシュコードについて過去の一定期間の原系列から季節変動パターンを計算して季節指数を求め、季節指数に基づいて「推計人口配列」フィールド内の推計人口を調整する。季節指数は、移動平均法や連環比率法等の任意の手法により求められる。
【0036】
図9は、季節調整済みの推計人口が格納される調整後人口テーブル160の一例である。調整後人口テーブル160内の各エントリは、「メッシュコード」フィールド、「都道府県」フィールド、調整後推計人口の算定対象を示す「時間帯」フィールド、季節調整前の「推計人口」フィールド、上述の季節調整処理を施した「調整後推計人口」フィールド、季節調整処理後の推計人口の標準偏差を示す「標準偏差」フィールド、及び、比較的長い期間(例えば、1ヶ月間)にわたって推計人口を平均した値を示す「長期移動平均」フィールドを含む。なお、以上の標準偏差の算定対象となる期間は、長期移動平均と同程度の比較的長い期間である。
【0037】
図9から理解されるように、調整後人口テーブル160内の各エントリは、メッシュコードと時間帯との組合せにより特定される。前述の配列テーブル150(
図8)では1エントリに複数の時間帯が含まれるが、調整後人口テーブル160では推計人口テーブル140(
図7)と同様に1エントリが1つの時間帯に相当する。
【0038】
なお、季節調整部120が、配列テーブル150に含まれる全エントリについてではなく、選別されたエントリのみ(例えば、現在時刻の直前の時間帯における推計人口が所定閾値以上のエントリのみ)について、以上の季節調整処理を実行すると好適である。演算負荷が低減されるからである。
【0039】
エリア抽出部130は、調整後人口テーブル160を参照して、推計人口が集中している(増大している)混雑エリアCAを抽出する(S1050)。
【0040】
より具体的には、まず、エリア抽出部130は、以下の関係式に基づいて、調整後人口テーブル160内の各エントリについて、長期移動平均からの調整後推計人口のずれを示すσ
sadjと長期移動平均に対する調整後推計人口の倍率を示すM
sadjとを算定する。
σ
sadj = (調整後推計人口−長期移動平均)/標準偏差 ……(式1)
M
sadj = 調整後推計人口/長期移動平均 ……(式2)
その後、エリア抽出部130は、混雑指標I
Cに従ってソートした場合に第1順位(例えば、10位)以上となるエントリを抽出して、ソート順位と共に抽出エリアテーブル230(
図10)に格納する。以上の順位は、全国順位であってもよいし都道府県別の順位であってもよい。なお、エリア抽出部130は、ステップS1050において、混雑指標I
Cが第1閾値を上回るエントリを抽出して、抽出エリアテーブル230に格納してもよい。
【0041】
混雑指標I
Cに関しては、σ
sadjとM
sadjとのいずれか一方のみを混雑指標I
Cとしてもよいし、双方に基づく指標(例えば、I
C=α・σ
sadj+β・M
sadj。α及びβは重み付け係数)を混雑指標I
Cとしてもよい。
【0042】
また、ステップS1050において、推計人口が所定閾値以上のエントリのみを混雑指標I
Cの算定対象としてもよい。推計人口の増大を示す混雑指標I
Cが大きくても、推計人口自体が少なければ混雑エリアCAとは言えないからである。以上のように対象エントリを選別することで、演算量の削減が図られる。
【0043】
以上に説明した通り、混雑解析サーバASは、各エリアAにおける混雑度に関する混雑指標I
Cを取得する混雑指標取得部として機能する。以上のエリア抽出動作(混雑指標取得動作)により、人口(季節調整後の推計人口)が集中している混雑エリアCAと時間帯との組合せが抽出され、抽出エリアテーブル230に格納される。
【0044】
1(4)−2. インデックス動作
図11は、本実施形態のインデックス動作を示すフローチャートである。概略的には、インデックスサーバISのインデックス部300は、ブログサーバBSから取得した投稿情報PIのうち、位置に関連する情報(POI名称又はジオタグ)を有する投稿情報PIを抽出してインデックスする。「POI」はPoint of Interestの略であり、ランドマーク、史跡、店舗などの「人の興味を引く場所」を意味する。「ジオタグ」は緯度及び経度を示す情報であり、例えばGPS機能に基づいて取得される。
【0045】
インデックス部300は、ブログサーバBSから投稿情報PIを取得する(S1110)。ブログサーバBSに投稿される全ての投稿情報PIがインデックスサーバISに提供されてもよいし、所定の条件に基づいて選択された投稿情報PIがインデックスサーバISに提供されてもよい。投稿情報PIはリアルタイムに提供されてもよいし、所定の時間おきに提供されてもよい。
【0046】
図12に、ブログサーバBSから提供される投稿情報PIの一例を示す。投稿情報PIは、投稿を一意に識別する「投稿ID」フィールド、「投稿時刻」フィールド、投稿が行われた位置を示す「緯度」フィールド及び「経度」フィールド、並びに「投稿情報本文」フィールドを含む。「緯度」と「経度」のフィールドは、投稿ユーザの設定その他の要因により空欄である場合がある。
【0047】
インデックス部300は、取得した各投稿情報PIについて、「投稿情報本文」フィールドの中に、辞書テーブル310(
図13)に登録されているPOI名称が含まれるか否かを判定する(S1120)。POI名称が含まれない場合(S1120;NO)、処理はステップS1150に進む。なお、ステップS1120において、投稿情報PIが緯度及び経度を含む場合は、POI名称が含まれるか否かに関わらずステップS1150に進んでもよい。
【0048】
一方、「投稿情報本文」フィールドにPOI名称が含まれる場合(S1120;YES)、インデックス部300は、辞書テーブル310を参照して、そのPOI名称とそのPOI名称に対応するPOI識別子とをその投稿情報PIに付与する(S1130)。そして、インデックス部300は、そのPOI名称に対応する緯度及び経度をその投稿情報PIに付与する(S1140)。以上の付与が実行された後の投稿情報PIを、
図14に示す。
図14の例では、投稿ID9876543を有する投稿情報PIについて、投稿情報本文に含まれる「金閣寺」というPOI名称に基づいて、「POI識別子」、「POI名称」、「緯度」、及び「経度」の各フィールドに値が付与されている。
【0049】
なお、「投稿情報本文」フィールドにPOI名称が含まれる場合であって、当該投稿情報PIに緯度及び経度が既に含まれるときには、ステップS1140の緯度経度付与がスキップされてもよい。また、「投稿情報本文」フィールドに複数のPOI名称が含まれる場合には、1つの投稿情報PIに対して複数のPOI情報(POI識別子、POI名称、緯度、及び経度)が対応付けられてもよい。
【0050】
次いで、インデックス部300は、取得した投稿情報PIが緯度及び経度を含むか否かを判定する(S1150)。緯度及び経度が含まれない場合(S1150;NO)、処理はステップS1110に戻り、新たな投稿情報PIが取得される。
【0051】
一方、投稿情報PIに緯度及び経度が含まれる場合(S1150;YES)、インデックス部300は、その緯度及び経度に対応するメッシュコードを特定してその投稿情報PIに付与する(S1160)。その後、インデックス部300は、投稿情報PIを抽出投稿テーブル320に格納し、検索を容易にするためのインデックスを付与する(S1170)。
図15は、メッシュコードが付与され、抽出投稿テーブル320に格納された投稿情報PIを示す図である。その後、動作はステップS1110に戻り、新たな投稿情報PIが取得される。
【0052】
以上のインデックス動作により、位置に関連する情報(地理的属性)を有する投稿情報PIが抽出されインデックスされて抽出投稿テーブル320に格納される。
【0053】
1(4)−3. 投稿情報解析動作
図16は、本実施形態の投稿情報解析動作を示すフローチャートである。ウェブサーバWSの第2クエリ部212は、インデックスサーバIS(抽出投稿テーブル320)から投稿情報PIを取得し、POIごと及び対象となる時間帯ごとに投稿情報PIの合計投稿数S
Cを算出する。例えば、第2クエリ部212は、POI=金閣寺、及び、対象時間帯=2014/5/5 10:00:00〜2014/5/5 10:59:59について、投稿情報PIの合計投稿数S
Cを算出する。そして、投稿情報PIの合計投稿数が閾値N以上であるPOI及び対象時間帯の組合せ(上昇POI候補)をリストする(S1210)。
【0054】
第2クエリ部212は、リストされたPOI及び対象時間帯の組合せの各々について、その対象時間帯を含む長期間(例えば1日)にわたる投稿情報PIの合計投稿数S
Lを算出する(S1220)。例えば、第2クエリ部212は、POI=金閣寺、及び、過去期間=2014/5/4 11:00:00〜2014/5/5 10:59:59について、投稿情報PIの合計投稿数S
Lを算出する。
【0055】
第2クエリ部212は、リストされたPOI及び対象時間帯の組合せ(上昇POI候補)の各々について、以下の式3に従い、投稿数の量的変化を示す第2投稿指標I
P2(第2興味指標)を算出する(S1230)。
I
P2 = log{S
C/(S
L+V)} ……(式3)
なお、式3中の「V」は、正の値を取るスムージングパラメータであり、絶対的な投稿数が少ない場合に第2投稿指標I
P2をより小さく補正するための値である。
【0056】
第2クエリ部212は、第2投稿指標I
P2に基づいてPOI及び対象時間帯の組合せを抽出し、投稿上昇テーブル260に格納する(S1240)。より具体的には、第2クエリ部212は、第2投稿指標I
P2に従ってソートした場合に第2順位(例えば、8位)以上となるPOI及び対象時間帯の組合せについて、時間帯、POI識別子、POI名称、メッシュコード、POIの緯度、POIの経度、及び第2投稿指標I
P2を含むエントリを生成して、投稿上昇テーブル260に格納する。
図17に、投稿上昇テーブル260の構成例を示す。
【0057】
なお、ステップS1240において、第2クエリ部212が、第2投稿指標I
P2が第3閾値を上回るPOI及び対象時間帯の組合せを抽出し、投稿上昇テーブル260に格納してもよい。
【0058】
その後、第2クエリ部212は、抽出されたPOI及び対象時間帯の組合せに対応する投稿情報PIを、投稿情報テーブル250に格納する(S1250)。
【0059】
以上の投稿情報解析動作により、投稿情報PIの投稿数が上昇(増加)しているPOI及び時間帯の組合せ(上昇POI)が抽出され、投稿上昇テーブル260に格納される。
【0060】
なお、以上の投稿情報解析動作においてはPOI単位で解析が実行されるが、メッシュコード(エリアA)単位で解析が実行される構成も採用可能である。すなわち、第2クエリ部212が、メッシュコードごと及び対象時間帯ごとにS
C、S
L、及び第2投稿指標I
P2(第2興味指標)を算出して上記の抽出動作を実行してもよい。この場合、ステップS1240においては、メッシュコード及び対象時間帯の組合せについて、時間帯、メッシュコード、メッシュの緯度(メッシュの左上点)、メッシュの経度(メッシュの右下点)、及び第2投稿指標I
P2を含むエントリが生成され格納される。
【0061】
1(4)−4. 投稿情報保存動作
図18は、本実施形態の投稿情報保存動作を示すフローチャートである。ウェブサーバWSのエリア取得部222は、抽出エリアテーブル230に含まれる混雑エリアCAに関する情報(混雑エリアCAのメッシュコード及び混雑が生じた対象時間帯の組合せ)を取得し、第3クエリ部224に供給する(S1310)。
【0062】
第3クエリ部224は、エリア取得部222から供給されたメッシュコード及び対象時間帯に相当する投稿情報PI(すなわち、混雑エリアCAに対応する投稿情報PI)を、インデックスサーバISの抽出投稿テーブル320から取得する(S1320)。次いで、第3クエリ部224は、取得した投稿情報PIを投稿情報テーブル250に格納するのに加え、取得した投稿情報PIが画像情報(インターネット上の画像URL等)を含む場合にはその画像情報が指し示す画像データを取得し、投稿情報PIに含まれる投稿IDと共に画像テーブル240に格納する(S1330)。
【0063】
以上の投稿情報保存動作により、混雑エリアCAに対応する投稿情報PI及び関連画像がウェブサーバWS内に記憶される。以上の構成によれば、インデックスサーバISの抽出投稿テーブル320において古い投稿情報PIが定期的に削除され、関連画像が時間の経過と共にインターネット上から失われても、クライアント端末CLに提示される可能性のある投稿情報PI及び関連画像についてはウェブサーバWS内に確保される。
【0064】
なお、以上の投稿情報保存動作において、画像データ自体を取得しない構成も採用可能である。例えば、以上のステップS1330において、第3クエリ部224が、取得した投稿情報PIに含まれるURLが画像に相当するものであるか否か(すなわち、投稿情報PIに画像情報が含まれるか否か)を判定し、その判定結果(画像あり/画像なし)を示す情報を投稿IDと共に画像テーブル240に格納してもよい。
【0065】
1(4)−5. データ提示動作
ウェブサーバWSのデータ提示部200は、前述の動作により各テーブル(230,240,250,260)に格納されたエントリに基づいて、クライアント端末CLに種々のデータを提示する。
【0066】
1(4)−5−1. 混雑エリアの提示動作
図19は、混雑エリアCAをクライアント端末CLに提示する動作のフローチャートである。データ提示部200の第1クエリ部(第1興味指標取得部)202は、指定日時と指定表示範囲とを含む混雑エリア表示要求をクライアント端末CLから受信すると(S1410)、その混雑エリア表示要求に対応するエントリ(混雑エリアCA)を抽出エリアテーブル230から取得する(S1420)。すなわち、第1クエリ部202は、要求された指定表示範囲をメッシュコードに変換した後、指定日時を「時間帯」フィールドが示す期間に含み、かつ指定表示範囲に対応するメッシュコードのいずれかを「メッシュコード」フィールドに含む表示候補エントリを検索して取得する。取得された表示候補エントリは、場所提示部204に供給される。
【0067】
次いで、第1クエリ部202は、取得された表示候補エントリが示す時間帯及びメッシュコードに対応する投稿情報PIを投稿情報テーブル250から取得し(S1430)、各表示候補エントリに対応する投稿情報PIの数を示す第1投稿指標I
P1(第1興味指標)を算定して場所提示部204に供給する(S1440)。
【0068】
場所提示部204は、混雑指標I
Cに基づいて抽出された表示候補エントリのうち、第1投稿指標I
P1が第2閾値を上回るエントリに対応する混雑エリアCA(時間帯及びメッシュコード)を、クライアント端末CLに提示する(S1450)。すなわち、場所提示部204は、クライアント端末CLのディスプレイ上に、電子地図と共に混雑エリアCAを第1態様で表示させる制御信号をクライアント端末CLに送信する。
【0069】
その後、クライアント端末CLは、場所提示部204から受信した制御信号に従って混雑エリアCAをディスプレイ上に表示する。
図20は、ディスプレイに表示される画像Gの一例である。画像Gは、日時指定部DDと電子地図部EMと情報表示部IDとを備える。日時指定部DDは、表示要求における指定日時を指定する部分であり、日付指定用のカレンダーと時間指定用のスライダーとを含む。
【0070】
電子地図部EMは、電子地図及び混雑エリアCAの表示領域であるのに加え、表示要求における指定表示範囲を指定する部分である。電子地図部EMに表示される電子地図をマウス等によりスクロールさせることで、混雑エリア表示要求に含まれる指定表示範囲も変化する。
図20に示されるように、電子地図部EMには、ステップS1450で提示された混雑エリアCA(時間帯及びメッシュコード)に対応する混雑ボックスB1が表示される。混雑ボックスB1は、第1態様の一例である。情報表示部IDの詳細は後述される。
【0071】
1(4)−5−2. 投稿数上昇場所の提示動作
図21は、投稿情報PIの投稿数が上昇しているPOI(上昇POI)をクライアント端末CLに提示する動作のフローチャートである。第1クエリ部202は、指定日時と指定表示範囲とを含む上昇POI表示要求をクライアント端末CLから受信すると(S1510)、その上昇POI表示要求に対応するエントリを投稿上昇テーブル260から取得する(S1520)。すなわち、第1クエリ部202は、指定日時を「時間帯」フィールドが示す期間に含み、かつ「緯度」フィールド及び「経度」フィールドが示す緯度経度が指定表示範囲に含まれる表示対象エントリを検索して取得する。取得された表示対象エントリは、場所提示部204に供給される。
【0072】
場所提示部204は、取得された表示対象エントリに対応する上昇POI(時間帯及び緯度経度)を、クライアント端末CLに提示する(S1530)。すなわち、場所提示部204は、クライアント端末CLのディスプレイ上に、電子地図と共に上昇POIを第2態様で表示させる制御信号をクライアント端末CLに送信する。
【0073】
その後、クライアント端末CLは、場所提示部204から受信した制御信号に従って上昇POIをディスプレイ上に表示する。
図22は、ディスプレイに表示される画像Gの一例であり、
図20と同様の部分(DD,EM,ID)を備える。
図22に示されるように、電子地図部EMには、ステップS1530で提示された上昇POI(時間帯及び緯度経度)に対応する上昇ボックスB2が表示される。上昇ボックスB2は、第1態様とは異なる第2態様の一例である。
【0074】
なお、前述の投稿情報解析動作(項目1(4)−3)と同様、以上の提示動作を、投稿情報PIの投稿数が上昇しているエリアA(上昇エリア)について実行する構成も採用可能である。さらに、上昇POIについての提示動作と上昇エリアについての提示動作とを併せて実行する構成も採用可能である。
【0075】
1(4)−5−3. 混雑関連情報の提示動作
図23は、混雑エリアCAの混雑状況に関連する混雑関連情報CIをクライアント端末CLに提示する動作のフローチャートである。第1クエリ部202は、特定の混雑エリアCAを指定する情報表示要求をクライアント端末CLから受信すると(S1610)、その混雑エリアCA(メッシュコード及び時間帯)に対応付けられる投稿情報PIを投稿情報テーブル250から取得して、情報提示部206に供給する(S1620)。ステップS1610の情報表示要求は、例えば、電子地図部EMに表示される混雑ボックスB1をユーザがマウス等の入力デバイスにより選択すると生成される。
【0076】
情報提示部206は、供給された投稿情報PIを混雑関連情報CIとして扱う。混雑エリアCAに対応付けられる投稿情報PIは、その混雑エリアCAの混雑状況や混雑理由に関連する可能性が高いからである。情報提示部206は、混雑エリアCAについて取得された混雑関連情報CIの各々について、情報的価値に応じた優先度を決定する(S1630)。以上の優先度は、任意に決定され得る。以下に、優先度の決定手法の例を非限定的に列挙する。複数の優先度決定手法が併用されてもよい。
−混雑関連情報CIの投稿時刻が新しいほど優先度を高める
−混雑関連情報CIが共有された(リツイート又はシェアされた)回数が多いほど優先度を高める
−画像(画像リンクURL)が含まれる混雑関連情報CIの優先度を高める
−混雑エリアCA内のPOI名称が含まれる混雑関連情報CIの優先度を高める
【0077】
情報提示部206は、優先度に従ってクライアント端末CLに混雑関連情報CIを提示する(S1640)。例えば、情報提示部206は、優先度に従ってソートした混雑関連情報CIをクライアント端末CLに提示してもよいし、優先度が最も高い混雑関連情報CIをクライアント端末CLに提示してもよい。
【0078】
その後、クライアント端末CLは、情報提示部206から提示された混雑関連情報CIをディスプレイ(情報表示部ID)上に表示する。
図24は、ディスプレイに表示される画像Gの一例である。情報表示部IDには、投稿時刻に従って優先度が付与された混雑関連情報CIが表示される。なお、混雑関連情報CI(投稿情報PI)に対応する画像データは、情報提示部206が、画像テーブル240から取得してクライアント端末CLに提示してもよいし、混雑関連情報CIに含まれる画像情報(画像リンクURL)に基づいてインターネット上から取得して提示してもよい。また、情報提示部206から提示された混雑関連情報CIに基づいてクライアント端末CLがインターネット上から取得してもよい。
【0079】
なお、以上の動作により、混雑エリアCAに対応する投稿情報PI(混雑関連情報CI)が電子地図と共に表示されるが、上昇POI(又は上昇メッシュ)に対応する投稿情報PIについても、同様の動作に基づいて表示させることが可能である。
【0080】
1(5). 本実施形態の効果
以上の本実施形態の構成によれば、人口が集中している混雑エリアCAと、その混雑エリアCAの混雑状況に関連する混雑関連情報CIとが、併せてクライアント端末CLに提示され、電子地図と共に表示される。したがって、人口が集中しているエリアのみが提示される構成と比較して、ユーザへ提供される情報の価値がより高い。
【0081】
本実施形態では、混雑エリアCAに加えて、投稿情報PIの投稿数が上昇している場所(上昇POI又は上昇エリア)がクライアント端末CLに提示され、電子地図と共に表示される。すなわち、実際に混雑してはいないが、多くの人の興味を引いている場所がユーザへ通知される。
【0082】
本実施形態では、情報的価値に応じた優先度に従って混雑関連情報CIが提示される。したがって、より意味のある情報が優先してユーザへ提供される。
【0083】
2. 変形例
以上の実施形態は多様に変形される。具体的な変形の態様を以下に例示する。以上の実施の形態および以下の例示から任意に選択された2以上の態様は、相互に矛盾しない限り適宜に併合され得る。
【0084】
2(1). 変形例1(興味情報)
投稿情報PI以外の様々な情報が、興味情報として採用され得る。例えば、インターネット検索サービスを提供する検索サーバに入力される検索履歴SHが、興味情報として用いられ得る。検索履歴SHは、ブログサーバBSから提供される投稿情報PIと同様に、「検索時刻」、検索が行われた位置を示す「緯度」及び「経度」、並びに「検索ワード」を情報項目(フィールド)として含む。したがって、インデックスサーバISが検索サーバから検索履歴SHを取得することにより、前述の実施形態と同様の動作を実現することが可能である。
【0085】
また、POIに関連する情報を提供するPOI情報サーバへのアクセス履歴AHが、興味情報として用いられ得る。以上のアクセス履歴AHは、「アクセス時刻」、アクセスが行われた位置を示す「緯度」及び「経度」、並びに「アクセス対象POI」を情報項目(フィールド)として含む。したがって、インデックスサーバISがPOI情報サーバからアクセス履歴AHを取得することにより、前述の実施形態と同様の動作を実現することが可能である。
【0086】
さらに、2以上の情報を組み合わせて興味情報としてもよい。より具体的には、インデックスサーバISが、複数のサーバ(ブログサーバBS、検索サーバ、POI情報サーバ等)から、地理的属性を有する複数種類の情報(投稿情報PI、検索履歴SH、アクセス履歴AH等)を取得して記憶し、ウェブサーバWSが実行する場所提示及び情報提示の用に供してもよい。なお、興味指標(第1興味指標及び第2興味指標)の算出において、情報の種別に応じて重み付けが行われてもよい。
【0087】
2(2). 変形例2(混雑指標)
以上の実施形態では、推計人口(混雑度)の時系列的な変化を示すパラメータ(σ
sadj,M
sadj,又はこれらの組合せ)が混雑指標I
Cとして採用されるが、推計人口(混雑度)そのものが混雑指標I
Cとして採用されてもよい。
【0088】
2(3). 変形例3(第1興味指標)
以上の実施形態において、第1投稿指標I
P1(第1興味指標)は、指定時間帯における混雑エリアCAの投稿情報PIの数を示す。しかし、投稿情報PIの伝搬力を示す指標(例えば、投稿情報PIが共有された回数(リツイート数))を第1投稿指標I
P1が示してもよい。
【0089】
2(4). 変形例4(混雑関連情報)
以上の実施形態(ステップS1610〜S1640)では、投稿情報PIが混雑関連情報CIとしてクライアント端末CLに提示されるが、以下に示すようなその他の情報が混雑関連情報CIとして提示されてもよい。
【0090】
2(4)−1. イベント名称の提示
情報提示部206は、混雑エリアCA(メッシュコード及び時間帯)に対応付けられる投稿情報PIに含まれるイベント名称を、混雑関連情報CIとして提示してもよい。イベント名称は、予めウェブサーバWSに記憶されたイベント名称辞書データと投稿情報PIからの抽出語との突合によって取得されてもよいし、構文解析によって取得されてもよい。構文解析の例として、イベント名称と共に用いられる傾向のある文字列(例えば、『(イベント名称)が開催』や『(イベント名称)に参加』)に前置される名詞を、イベント名称として取得する構成が挙げられる。
【0091】
なお、複数のイベント名称が取得された場合には、イベントの優先度に基づいてクライアント端末CLにイベント名称が提示されると好適である。以上の優先度に関しては、例えば、イベント名称を含む投稿情報PIの数が多いほど、そのイベントの優先度が高く決定される。
【0092】
2(4)−2. 写真画像の提示
情報提示部206は、混雑エリアCAに対応付けられる投稿情報PIにリンクされる写真画像を、混雑関連情報CIとして提示してもよい。複数の写真画像が存在する場合は、人物認識処理により取得される画像内の人数が多いほど高くなる優先度に基づいて、写真画像がクライアント端末CLに提示されると好適である。
【0093】
2(5). 変形例5(エリア)
メッシュ以外の領域もエリアAとして採用され得る。例えば、所定のランドマークを中心とする円状の領域をエリアAとしてもよい。また、建造物や公園等のスポットの外縁に囲まれる領域をエリアAとしてもよい。
【0094】
2(6). 変形例6(提示システムおよび提示装置)
以上の実施形態では、提示システムPSにおいて混雑解析サーバASとウェブサーバWSとが別個に存在するが、混雑解析サーバASとウェブサーバWSとが1つの提示装置として構成されてもよい。ただし、混雑解析サーバASには携帯電話ユーザの行動を示す個人情報が含まれる一方、ウェブサーバWSには統計処理された情報のみが記憶され、外部に公開されるという特徴があるため、セキュリティ上は、以上の各サーバを別個に設ける実施形態の構成が好適である。
【0095】
他方、各サーバ(混雑解析サーバAS,ウェブサーバWS等)が、ネットワークによって相互に接続される複数のコンピュータ装置によって実現されてもよい。
【0096】
提示システムPSに、インデックスサーバISが含まれる構成も採用可能である。
【0097】
2(7). 変形例7(提示装置としてのクライアント端末)
混雑解析サーバAS及びウェブサーバWSにおいて実行される前述の動作は、クライアント端末CLにて実行されてもよい。すなわち、クライアント端末CLは、提示装置として機能し得る。
【0098】
2(8). 変形例8(ソート処理)
以上の実施形態(ステップS1050)では、値が大きいほど混雑上昇の度合いも高い混雑指標I
Cが降順にソートされてエントリの順位が決定される。しかし、値が小さいほど混雑上昇の度合いが高い混雑指標I
Cが採用され、混雑指標I
Cが昇順にソートされてエントリの順位が決定されてもよい。ステップS1240における第2投稿指標I
P2に従ったソートに関しても同様である。
【0099】
2(9). 変形例9(第1興味指標に従ったソート)
ステップS1240では、投稿数の量的変化を示す第2投稿指標I
P2(第2興味指標)に従ってソートが実行されるが、投稿数を示す第1投稿指標I
P1(第1興味指標)に従ってソートが実行されてもよい。
【0100】
2(10). 変形例10(可変閾値)
第1閾値及び第2閾値は可変に設定されてもよい。例えば、混雑指標I
Cが高いほど第1投稿指標I
P1(第1興味指標)に関する第2閾値が低く設定され、第1投稿指標I
P1が高いほど混雑指標I
Cに関する第1閾値が設定されると好適である。以上の構成によれば、第1閾値及び第2閾値を用いた二重の条件による混雑エリア判定において、一方の閾値と対比される値が高まるほど他方の閾値が低下するため、二重の条件が充足され易くなる。したがって、混雑エリアCAと判定されるケースが増大し、ひいてはユーザに対して提示される情報量が増大する。
【0101】
他方、混雑指標I
Cが高いほど第1投稿指標I
P1(第1興味指標)に関する第2閾値が高く設定されてもよく、第1投稿指標I
P1が高いほど混雑指標I
Cに関する第1閾値が高く設定されてもよい。一般的に、エリアAについての混雑指標I
Cと第1投稿指標I
P1とは正の相関を有すると見込まれるため、一方の閾値と対比される値が高まるほど他方の閾値も高く設定することにより、混雑エリアCAの判定精度を高められる。
【0102】
また、第1投稿指標I
P1(第1興味指標)に関する第2閾値が、他の指標に基づいて可変に設定されてもよい。例えば、エリアAに割り当てられた都会度に関する指標(例えば、人口密度)が高いほど、そのエリアAの第2閾値が高く設定されてもよい。
【0103】
2(11). 変形例11(第3態様によるエリア提示)
混雑エリアCAに関して、更なる提示態様が採用されてもよい。例えば、混雑指標I
Cが第1閾値を上回り、かつ投稿数の量的変化を示す第2投稿指標I
P2が第3閾値を上回るエリアAを、場所提示部204が第3態様で提示する。すなわち、場所提示部204は、電子地図部EM上のそのエリアAに、混雑ボックスB1ではなく注目ボックスB3(
図25)を表示させる制御信号を、クライアント端末CLに送信する。以上の構成によれば、人口の集中が発生しており、かつ投稿数も上昇しているエリアAが明示的に提示される。
【0104】
2(12). 変形例12(第4態様によるエリア提示)
電子地図部EMに、混雑エリアCA及び投稿数上昇場所(上昇POI,上昇メッシュ)に加え、イベント情報が表示されてもよい。
図26に示すように、本変形例のウェブサーバWSは、イベント情報エントリを記憶するイベント情報テーブル270を更に備える。イベント情報エントリは、イベント名称、イベントの開催日時、及びイベントの開催場所の地理的属性(POI,緯度経度)を含む。
【0105】
第1クエリ部202は、指定日時と指定表示範囲とを含むイベント表示要求をクライアント端末CLから受信すると、その指定日時と指定表示範囲とに対応するイベント情報エントリをイベント情報テーブル270から取得して、場所提示部204に供給する。場所提示部204は、取得されたイベント情報エントリに対応するエリアAをクライアント端末CLに提示する。すなわち、場所提示部204は、クライアント端末CLのディスプレイ上にイベントが開催されるエリアAを第4態様で表示させる制御信号を送信する。ディスプレイの電子地図部EMには、当該エリアAに対応するイベントボックスB4(
図27)が表示される。以上の構成によれば、イベントが開催される場所及び日時が明示的に提示される。
【0106】
なお、場所提示部204は、イベント情報エントリに対応するエリアAについて、当該エリアAの投稿数を示す第1投稿指標I
P1が第4閾値を上回る場合にのみ、当該エリアAを提示してもよい。第4閾値は、ステップS1450の第2閾値と等しくてもよいし、異なる値に設定されてもよい。以上の構成によれば、投稿数が基準に満たないイベントに関してはクライアント端末CLに提示されないので、実際に話題となっているイベントが選別される。
【0107】
2(13). 変形例13(投稿数上昇場所の非提示)
投稿情報PIの投稿数が上昇している場所(上昇POI又は上昇エリア)をクライアント端末CLに提示しない構成(混雑エリアCAのみを提示する構成)も採用可能である。以上の場合、上昇POI又は上昇エリアを特定する投稿情報解析動作も不要であることは当然に理解される。
【0108】
2(14). 変形例14(ボックスサイズの変化)
混雑指標I
Cに応じて、混雑エリアCAの提示対応が変化してもよい。例えば、混雑指標I
Cが高いほど、混雑ボックスB1が大きく表示されてもよい。同様に、第1投稿指標I
P1又は第2投稿指標I
P2に応じて、上昇POI又は上昇エリアの提示態様(例えば、上昇ボックスB2の大きさ)が変化してもよい。
【0109】
2(15). 変形例15(複数ボックスの統合)
電子地図の縮尺が変更され、所定の狭い領域に複数のボックスを表示しなければならない場合、複数のボックスをまとめて1つの統合ボックスとし、本来表示されるべきボックスの合計数と共に表示すると好適である。
【0110】
2(16). 変形例16(エリア指示の態様)
以上の実施形態では、混雑ボックスB1等のボックスが表示されることによってエリアAが指し示される。しかしながら、ボックス以外の態様(例えば、エリアAの表示色の変化)によってエリアAが指し示されてもよい。
【0111】
2(17). 変形例17(場所提示の態様)
場所提示部204が実行する場所提示の態様は、電子地図上のボックス表示に限られない。例えば、ステップS1450において、場所提示部204が、混雑エリアCAを所定順序(例えば、混雑指標I
Cが高い順序)のリスト形式で表示させるようにクライアント端末CLを制御してもよい。すなわち、混雑エリアCAのリストは第1態様の一例である。
【0112】
以上の混雑エリアCAのリストは、単独で(すなわち、電子地図とは独立して)クライアント端末CLのディスプレイに表示されてもよく、電子地図と共に表示されてもよい。リストが電子地図と共に表示される場合、ユーザがリスト上の混雑エリアCAの1つを選択するのに応じて、その混雑エリアCAに対応する電子地図上の位置に混雑ボックスB1が表示されるとより好適である。
【0113】
同様に、場所提示部204は、投稿情報PIの投稿数が上昇している上昇POI又は上昇エリアに関しても、リスト形式で表示させるようにクライアント端末CLを制御してもよい。すなわち、上昇POI又は上昇エリアのリストは第2態様の一例である。また、変形例11及び12について前述した場所提示についても、上述と同様のリスト形式の表示が採用され得る。
【0114】
2(18). 変形例18(CPU以外のデバイス)
コンピュータ装置、特に、混雑解析サーバAS、ウェブサーバWS、及びインデックスサーバISにおいてCPUが実行する各機能は、FPGA(Field Programmable Gate Array)またはDSP(Digital Signal Processor)等のプログラマブルロジックデバイスで実行されてもよい。