JP7044748B2 - 表示制御装置、表示制御方法および表示制御プログラム - Google Patents

Description

本発明は、表示制御装置、表示制御方法および表示制御プログラムに関する。

従来、路線検索システムを用いて混雑度を予測する技術が知られている。例えば、特許文献１には、乗り換え案内のログ情報を基に、乗り換え案内の利用状況を利用駅の混雑度と予測する技術が開示されている。

特開２０１３－１９０８６７号公報

しかしながら、上記の従来技術では、効率的に駅を利用できるよう支援することができるとは限らない。例えば、上記の従来技術では、乗り換え案内のログ情報を基に、検索ルート上の各駅と時間帯の乗り換え案内の利用状況を作成集計して、乗り換え案内の利用状況を利用駅の混雑度と予測しているに過ぎず、現在、駅への入場規制や駅からの出場規制がどのようになっているかの予測までは行っていない。このようなことから、ユーザは上記従来技術では、入場規制や出場規制（以下、まとめて入出規制という場合がある）の状況までは把握することができないため、例えば、駅に到着してから入場規制がかけられていることを知り、時間を無駄に浪費してしまう可能性がある。したがって、上記の従来技術では、必ずしも効率的に駅を利用できるよう支援することができるとは限らない。

本願は、上記に鑑みてなされたものであって、効率的に駅を利用できるよう支援することができる表示制御装置、表示制御方法および表示制御プログラムを提供することを目的とする。

本願にかかる表示制御装置は、駅に関する所定の情報に基づいて、当該駅に対して入出規制がかけられているか否かを推定する推定部と、前記推定部により入出規制がかけられていると推定された場合には、当該入出規制がかけられていると推定された駅に関する駅情報を表示させる表示制御部とを有し、前記推定部は、前記駅に関する所定の情報として、路線に関する所定の検索サービスにおける検索履歴であって、前記駅に関する検索履歴に基づいて、混雑の発生に関係なく、前記駅に対して入出規制がかけられているか否かを推定することを特徴とする。

実施形態の一態様によれば、効率的に駅を利用できるよう支援することができるといった効果を奏する。

図１は、実施形態にかかる推定処理を実現可能な根拠を説明する説明図（１）である。 図２は、実施形態にかかる推定処理を実現可能な根拠を説明する説明図（２）である。 図３は、実施形態にかかる表示制御処理における処理手順の一例を示す図である。 図４は、実施形態にかかる推定処理のバリエーションを示す図である。 図５は、実施形態にかかる配信対象のページ（１）の一例を示す図である。 図６は、実施形態にかかる配信対象のページ（２）の一例を示す図である。 図７は、実施形態にかかる表示制御システムの構成例を示す図である。 図８は、実施形態にかかる表示制御装置の構成例を示す図である。 図９は、実施形態にかかる時刻表情報記憶部の一例を示す図である。 図１０は、実施形態にかかる検索履歴記憶部の一例を示す図である。 図１１は、実施形態にかかる投稿履歴記憶部の一例を示す図である。 図１２は、実施形態にかかる表示制御処理手順を示すフローチャートである。 図１３は、表示制御装置の機能を実現するコンピュータの一例を示すハードウェア構成図である。

以下に、本願にかかる表示制御装置、表示制御方法および表示制御プログラムを実施するための形態（以下、「実施形態」と呼ぶ）について図面を参照しつつ説明する。なお、この実施形態により本願にかかる表示制御装置、表示制御方法および表示制御プログラムが限定されるものではない。また、以下の実施形態において、同一の部位には同一の符号を付し、重複する説明は省略される。

〔１．表示制御処理の概要〕
図３～図６を用いて、実施形態にかかる表示制御処理の一例について説明する。図３では、実施形態にかかる表示制御処理の処理手順の一例を説明する。また、図４では、実施形態にかかる推定処理の一例を説明する。また、図５および図６では、実施形態にかかる表示制御に応じた画面例について説明する。また、実施形態にかかる表示制御処理は、図３に示す表示制御装置１００によって行われる。表示制御装置１００は、例えば、サーバ装置である。また、図１および図２では、実施形態にかかる表示制御処理に含まれる推定処理を実現可能な根拠ついて説明する。

上記の説明に先立って、図７を用いて、まず、実施形態にかかる表示制御システムについて説明する。図７は、実施形態にかかる表示制御システム１の構成例を示す図である。実施形態にかかる表示制御システム１は、図７に示すように、端末装置１０と、外部装置３０と、表示制御装置１００とを含む。端末装置１０、外部装置３０、表示制御装置１００は、ネットワークＮを介して有線または無線により通信可能に接続される。

端末装置１０は、表示制御装置１００からのサービスを受けるユーザによって利用される情報処理端末である。端末装置１０は、例えば、スマートフォンや、タブレット型端末や、ノート型ＰＣ（Personal Computer）や、デスクトップＰＣや、携帯電話機や、ＰＤＡ（Personal Digital Assistant）等である。また、端末装置１０には、表示制御装置１００に対応するアプリケーションが予めインストールされているものとする。本実施形態では、端末装置１０には、路線案内に関するアプリケーション（以下、「アプリＡＰ」と表記する場合がある）が予めインストールされているものとする。

例えば、端末装置１０は、アプリＡＰの制御に従って、表示制御装置１００にアクセスし、アクセスに応じた結果を表示制御装置１００から受信しこれを表示する。例えば、端末装置１０は、アプリＡＰの制御に従って、ユーザにより入力された検索条件に対応する路線検索結果を路線案内として表示する。また、端末装置１０は、アプリＡＰの制御に従って、路線毎の運行状況や路線毎の時刻表情報等も表示する。

外部装置３０は、鉄道会社毎の運行状況を示す運行情報を随時取得することにより、運行情報を最新のものに更新して蓄積しているサーバ装置である。例えば、外部装置３０は、各鉄道会社に属するサーバ装置から運行情報を取得して、最新の運行情報へと更新する。また、外部装置３０を管理する事業者と、表示制御装置１００を管理する事業者とは同一であってもよいし異なっていてもよい。

表示制御装置１００の説明の前に、ここで、実施形態にかかる表示制御処理が行われるにあたっての前提について説明する。駅には所定の事象が原因で当該駅への入場を規制する入場規制がかけられる場合がある。例えば、台風・大雪等の自然災害、人身事故が起きた場合には、平常運転時と比較して電車の運行本数が減数されることや運行休止されることがあるが、このような運行状況を知らないユーザは駅を利用しようと駅へと向かう。そうすると、電車に乗ることができないユーザで駅は大混雑してしまう。また、運行休止が通勤の時間帯（例えば、８時台～９時台、１８時台～１９時台）にかさなると、この混雑はより悪化する。混雑が悪化すると、ホームにまで人が殺到したり人が将棋倒しになる等の二次災害が発生する恐れもある。このため、例えば、駅の駅員は駅のゲートを閉じる等して改札内（あるいは駅構内）に入場できないよう入場規制をかける。

ここで、駅に到着してみて初めて入場規制がかけられていることを知るユーザも多い。かかるユーザは、もしかしたら入場規制はすぐに解除されかもしれない等と考え、長蛇の列に並び時間を無駄に浪費してしまうといった状況に陥る可能性がある。すなわち、効率的に駅を利用できないといった状況に陥る可能性がある。そこで、実施形態にかかる表示制御処理は、ユーザが利用しようとする駅に対して入場規制がかけられているか否かを推定し推定結果をユーザに通知することで、ユーザが時間を無駄に浪費し駅を効率的に利用できなくなるといった状況を事前に回避させるために成されるものである。これにより、例えば、入場規制を知ることができたユーザは、自宅で待機あるいは他の駅の利用といった対策を取ることができるようになるため、結果的に、効率的に駅を利用することができるようになると考えられる。

さて、入場規制に焦点を当てて説明してきたが、実施形態にかかる表示制御処理は、入場規制だけではなく出場規制にも対応可能なものである。したがって、ここからは出場規制の観点から実施形態にかかる表示制御処理が行われるにあたっての前提について説明する。

駅には所定の事象が原因で当該駅からの出場を規制する出場規制がかけられる場合がある。例えば、駅周辺で大きなイベント（例えば、花火大会・スポーツの国際大会・コンサート・フェス等）が開催される場合、この駅からイベント会場までの移動経路が大混雑し、結果的に、駅全体にまで混雑が発生し、駅構外に出ることがでいないといった状況が発生する。このように、駅構内にまで混雑が行きわたってしまうと、ホームにまで人が殺到したり人が将棋倒しになる等の二次災害が発生する恐れがある。このため、例えば、駅員は、特に混雑の激しい出口からの出場を規制する出場規制をかける一方で、比較的混雑の緩やかな他の出口へと迂回して出場するよう誘導する。

ここで、電車からホームへと出てみて初めてこの駅に出場規制がかけられていることを知るユーザも多い。他の出口へと迂回するよう誘導されていたとしても、駅が混雑していることには変わりないため、ユーザは駅構外に出られるまでには多くの時間を浪費してしまうといった状況に陥る可能性がある。このようなとき、例えば、ユーザは一つ前の駅で降車していれば徒歩の時間を考慮してももっと早く帰宅できていたかもしれない。したがって、効率的に駅を利用できないといった状況に陥る可能性がある。そこで、実施形態にかかる表示制御処理は、ユーザが利用しようとする駅に対して出場規制がかけられているか否かを推定し推定結果をユーザに通知することで、ユーザが時間を無駄に浪費し駅を効率的に利用できなくなるといった状況を事前に回避させるために成されるものである。これにより、例えば、出場規制を知ることができたユーザは、例えば、帰宅する際に他の駅を利用すべきといった対策を取ることができるようになるため、結果的に、効率的に駅を利用することができるようになると考えられる。

図３および図４にて詳細に説明するが、具体的には、実施形態にかかる表示制御装置１００は、路線に関する所定の検索サービスにおける検索履歴であって、処理対象の駅に関する検索履歴に基づいて、当該駅に対して入出規制がかけられているか否かを推定する。路線に関する所定の検索サービスとは、例えば、ユーザにより入力された検索条件に対応する路線検索結果を路線案内として表示するサービスであり、アプリＡＰを介して提供されるサービスである。このような検索履歴を用いることで、入出規制がかけられているか否かを推定することができる根拠について図１を用いて説明する。図１は、実施形態にかかる推定処理を実現可能な根拠を説明する説明図（１）である。

図１に示すグラフＧｘ１は、入場規制がかけられることのなかったある日のＦ駅を対象に、７時３０分～９時００分までの１０分おきにアプリＡＰを利用して検索された際の検索履歴に基づいて、Ｆ駅に関して検索された検索数を集計した集計結果を示すグラフである。グラフＧｘ１によると、入場規制がかけられることのなかったとき、すなわち平常時では、出勤の時間帯（８時前後）周辺において多少検索数が伸びているものの、全体としては検索数に大きな変化はみられていない。入場規制がかられていなかったということは、何らかの自然災害が起こっていたわけでもない。このため、Ｆ駅では平常運転されていることを疑う余地はなったため、多くのユーザはわざわざアプリＡＰを利用する必要がなかったということがグラフＧｘ１が示す検索数の変化に反映されている。

一方、図１に示すグラフＧｘ２は、入場規制がかけられた日でのＦ駅を対象に、７時３０分～９時００分までの１０分おきにアプリＡＰを利用して検索された際の検索履歴に基づいて、Ｆ駅に関して検索された検索数を集計した集計結果を示すグラフである。グラフＧｘ２によると、入場規制がかられていたとき、すなわち異常発生時では、平常時と比較して全体的な検索数が大幅に増加しているうえ、出勤の時間帯（８時前後）周辺においてはさらに検索数が急増している。入場規制がかけられたということは、台風等の自然災害が発生していたと考えることができる。このため、多くのユーザがＦ駅での運行状況を知るためにアプリＡＰを利用してＦ駅に関して検索したということがグラフＧｘ２が示す検索数の変化に反映されている。

要は、同一駅における検索数であっても、平常時と異常発生時とでは、図１に示されるように特徴的な乖離が発生する。具体的には、平常時と比較して異常発生時では、検索数に大幅な上昇がみられる。このようなことから、例えば、基準となる平常時の検索数と、リアルタイムで検索履歴から集計した検索数とを比較することで、入場規制されているか否かを推定することが可能となる。

上記をまとめると、表示制御装置１００は、アプリＡＰにおける検索履歴であって、処理対象の駅に関する検索履歴を集計して得られた集計結果が所定の条件情報を満たす場合には、処理対象の駅に対して入出規制がかけられていると推定する。例えば、表示制御装置１００は、処理対象の駅に関して検索された検索数に関する情報、または、処理対象の駅に関して検索されたことによるアプリＡＰの使用率に基づく情報が、所定の条件情報を満たす場合には、当該駅に対して入出規制がかけられていると推定する。一例としては、表示制御装置１００は、所定の条件情報を満たす場合として、所定の基準値に対して集計結果が所定値以上の上昇を示す場合には、処理対象の駅に対して入出規制がかけられていると推定する。

また、実施形態にかかる表示制御装置１００は、所定の情報共有サービス（例えば、ソーシャル・ネットワーキング・サービス；ＳＮＳ）における投稿履歴であって、処理対象の駅に関する投稿履歴に基づいて、当該駅に対して入出規制がかけられているか否かを推定する。このような投稿履歴を用いることで、入出規制がかけられているか否かを推定することができる根拠について図２を用いて説明する。図２は、実施形態にかかる推定処理を実現可能な根拠を説明する説明図（２）である。

図２（ａ）は、異常発生時（例えば、台風発生時）において所定のＳＮＳサービス（以下、「サービスＳＡ」とする）を利用して投稿された投稿情報の履歴（投稿履歴）をトレンドワードの観点から集計した集計結果を示す。図２（ａ）によると、異常発生時には、「入場規制」、「駅名」、「電車遅延」、「台風一過」といたワードがトレンドワードとしてランクインしている。このようなことから、例えば、投稿履歴を投稿内容の観点から集計した集計結果（例えば、トレンドワード）に着目すれば、入場規制されているか否かを推定することが可能となる。

次に、図２（ｂ）には、駅毎に当該駅に関する投稿履歴を集計した集計結果として、特定の期間（例えば、６ヶ月）全体としての投稿数の平均と、駅毎に当該駅に関する投稿履歴を集計した集計結果として、台風等の異常が発生した日を含む月における投稿数の平均とが示されている。図２（ｂ）によると、全体平均と所定１ヶ月平均とでは、投稿数に特徴的な乖離がみられる。具体的には、全体平均と比較して異常発生日を含む所定１ヶ月平均は、短期間にも拘らず大幅に上昇している。このようなことから、例えば、基準となる全体平均と、リアルタイムで投稿履歴から集計した投稿数とを比較することで、入場規制されているか否かを推定することが可能となる。

上記をまとめると、表示制御装置１００は、サービスＳＡにおける投稿履歴の中に、駅名とともに入出規制に関する文言が含まれる投稿情報が存在する場合には、当該駅名が示す駅に対して入出規制がかけられていると推定する。また、表示制御装置１００は、サービスＳＡおける投稿履歴であって、処理対象の駅に関する投稿履歴を集計して得られた集計結果が所定の条件情報を満たす場合には、処理対象の駅に対して入出規制がかけられていると推定する。例えば、表示制御装置１００は、処理対象の駅に関する投稿情報の投稿数に基づくが、所定の条件情報を満たす場合には、処理対象の駅に対して入出規制がかけられていると推定する。

さて、ここまで実施形態にかかる表示制御処理の前提や、実施形態にかかる推定処理が可能となる根拠等を概要として説明してきた。以下では、実際に実施形態にかかる表示制御処理の一例について処理手順を交えて詳細に説明してゆく。

〔２．表示制御処理の一例〕
ここからは、図３を用いて、実際に実施形態にかかる表示制御処理の一例について処理手順を交えて説明する。図３は、実施形態にかかる表示制御処理における処理手順の一例を示す図である。図３では、アプリＡＰを介してユーザＵ１から受け付けた検索条件（路線案内に関する検索条件）に対応する検索結果（路線案内）画面において、実施形態にかかる表示制御処理が行われる例を示す。なお、実施形態にかかる表示制御処理が対象とする画面は、検索結果画面に限定されない。例えば、実施形態にかかる表示制御処理が対象とする画面は、検索結果画面以外にも、路線毎の運行状況が一覧表示される一覧表示画面や、時刻表検索に対応する検索結果画面が挙げられる。

また、以下の実施形態では、入場規制および出場規制のうち、特に入場規制の方に焦点を当てて説明する。また、以下の実施形態では、路線に関する所定の検索サービスは、「アプリＡＰ」を介して提供される路線案内であるものとする。したがって、路線に関する所定の検索サービスは、単に、「アプリＡＰ」と言い換えることができるものとする。また、以下の実施形態では、所定の情報共有サービスは、ＳＮＳサービスとしての「サービスＳＡ」であるものとする。

このような状態において、表示制御装置１００は、駅毎に、当該駅に関する所定の情報に基づいて、当該駅に入場規制がかけられているか否かを推定する推定処理を行う（ステップＳ１１）。例えば、駅に関する所定の情報とは、これまでの説明の通りこの駅に関する検索履歴や投稿履歴であるが、検索サービスやＳＮＳサービスが利用される度に、これら履歴は随時更新されてゆく。したがって、表示制御装置１００は、随時更新される履歴を用いて、リアルタイムに処理対象の駅に対して入場規制がかけられているか否かを推定する。

実施形態にかかる推定処理としては、図４に示す５つのパターン（バリエーション）が挙げられる。図４は、実施形態にかかる推定処理のバリエーションを示す図である。図４に示すように、実施形態にかかる推定処理は、検索サービスすなわちアプリＡＰにおける検索履歴を用いるパターンと、ＳＮＳサービスすなわちサービスＳＡにおける投稿履歴を用いるパターンと、検索サービスおよびＳＮＳサービスの双方の情報をかけあわせるパターンと、混雑度を用いるパターンに分けられる。以下、パターン毎に説明してゆくが、重複する説明については適宜省略する。

（パターンＰＴ１について）
まずは、検索サービス（アプリＡＰ）における検索履歴を用いるパターンである推定処理パターンＰＴ１（以下、「パターンＰＴ１」と略す）について説明する。パターンＰＴ１では、表示制御装置１００は、時刻の経過（時刻経過）に応じて随時更新される検索履歴を取得する。例えば、表示制御装置１００は、時刻経過に応じた所定の時間間隔（例えば、１０分間隔）毎に検索履歴を取得する。図７に示す表示制御システム１では、不図示であるが、例えば、表示制御システム１にアプリＡＰに対応するサーバ装置が含まれる場合には、表示制御装置１００は、このサーバ装置から検索履歴を取得することができる。そして、表示制御装置１００は、検索履歴を取得する度に取得した検索履歴を検索履歴記憶部１２２に格納することで検索履歴記憶部１２２を更新する。検索履歴記憶部１２２の構成については後ほど図１０を用いて説明する。

そして、表示制御装置１００は、検索履歴に含まれる検索情報に基づいて、この検索情報がどの駅に関する検索情報であるかを判断することで、検索履歴を駅別に分ける。図１０の例を用いて、例えば、検索情報ＳＣＤＡ１に含まれる出発駅情報ＳＴＤＡ１が「京都駅」であるものとすると、表示制御装置１００は、検索情報ＳＣＤＡ１としての検索履歴を「京都駅」に分類させる。表示制御装置１００は、このように分類した各駅を処理対象の駅と定める。

このような状態において、表示制御装置１００は、処理対象の駅別の検索履歴から、当該処理対象の駅に関して検索された検索数を集計する。例えば、表示制御装置１００は、時刻経過に応じて、当該時刻での検索数を集計する。検索数は、検索人数と言い換えることができる。なお、表示制御装置１００は、処理対象の駅に関して検索されたことによるアプリＡＰの使用率を集計してもよく、かかる場合には、例えば、時刻経過に応じて、当該時刻での使用率を集計（算出）する。表示制御装置１００は、例えば、検索数に基づいて、アプリＡＰの使用率を集計することができる。例えば、表示制御装置１００は、アプリＡＰを利用している利用者総数を分母、現在時刻での検索者数を分子として使用率を算出することで、使用率を集計することができる。

次に、表示制御装置１００は、今回の集計結果と、通常時における同時刻での平均検索数とを比較し、今回の集計結果が所定値以上上回っているか否か判定する。表示制御装置１００は、使用率を集計した場合には、通常時における同時刻での平均検索数と比較し、今回の集計結果が所定値以上上回っているか否か判定する。そして、表示制御装置１００は、今回の集計結果が所定値以上上回っている場合には、対応する駅に入場規制がかけられていると推定する。

上記パターンＰＴ１について、処理対象の駅として「京都駅」を例に挙げてより詳細に説明する。表示制御装置１００は、時刻経過に応じて、当該時刻での最新の検索履歴であって、「京都駅」に関する検索履歴に基づいて、「京都駅」に入場規制がかけられているか否かを推定する。ここで、現在時刻は「８時００分」であるものとする。そうすると、表示制御装置１００は、「京都駅」に対応する検索履歴から、「８時００分」において「京都駅」に関して検索された検索数を集計する。なお、「８時００分」において「京都駅」に関して検索された検索数とは、「８時００分」での検索数であってもよいし、「８時００分」までの検索数の累計であってもよい。例えば、表示制御装置１００は、「京都駅」に対応する検索履歴から、「８時００分」において「京都駅」に関して検索された検索数として「Ｎ１１」を集計したとする。次に、表示制御装置１００は、今回の集計結果である「Ｎ１１」と、「８時００分」での平均検索数であって、通常時における「京都駅」での平均検索数「Ｎ１２」（所定の基準値）とを比較し、Ｎ１１がＮ１２を所定値以上上回っているか否か判定する。例えば、表示制御装置１００は、Ｎ１１がＮ１２を所定値以上上回っていると判定した場合には、「８時００分」現在では「京都駅」に入場規制がかけられていると推定する。

（パターンＰＴ２について）
次に、ＳＮＳサービス（サービスＳＡ）における投稿履歴を用いるパターンである推定処理パターンＰＴ２（以下、「パターンＰＴ２」と略す）について説明する。パターンＰＴ２では、表示制御装置１００は、時刻の経過（時刻経過）に応じて随時更新される投稿履歴を取得する。例えば、表示制御装置１００は、時刻経過に応じた所定の時間間隔（例えば、１０分間隔）毎に投稿履歴を取得する。図７に示す表示制御システム１では、不図示であるが、例えば、表示制御システム１にサービスＳＡに対応するサーバ装置が含まれる場合には、表示制御装置１００は、このサーバ装置から投稿履歴を取得することができる。そして、表示制御装置１００は、投稿履歴を取得する度に取得した投稿履歴を投稿履歴記憶部１２３に格納することで投稿履歴記憶部１２３を更新する。投稿履歴記憶部１２３の内部構成については後ほど図１１を用いて説明する。

そして、表示制御装置１００は、投稿履歴に含まれる投稿情報に基づいて、この投稿情報がどの駅に関する投稿情報であるかを判断することで、投稿履歴を駅別に分ける。例えば、図１１の場合、投稿情報ＰＴＤＡ１に含まれる駅名ＳＴＮＡ１が「京都駅」であるものとすると、表示制御装置１００は、投稿情報ＰＴＤＡ１としての投稿履歴を「京都駅」に分類させる。表示制御装置１００は、このように分類した各駅を処理対象の駅と定める。

このような状態において、表示制御装置１００は、処理対象の駅別の投稿履歴から、当該処理対象の駅を対象に入場規制を示唆する文言を含む投稿情報を集計する。例えば、表示制御装置１００は、（処理対象の駅の）「駅名」および「入場規制」の２つの単語を含む投稿情報を集計する。そして、表示制御装置１００は、「駅名」および「入場規制」が含まれる投稿情報を取得できた場合には、この駅名が示す駅に入場規制がかけられていると推定する。

上記パターンＰＴ２について、処理対象の駅として「京都駅」を例に挙げてより詳細に説明する。表示制御装置１００は、時刻経過に応じて、当該時刻での最新の投稿履歴であって、「京都駅」に関する投稿履歴に基づいて、「京都駅」に入場規制がかけられているか否かを推定する。ここで、現在時刻は「８時００分」であるものとする。そうすると、表示制御装置１００は、「京都駅」に対応する投稿履歴であって、「８時００分」までに投稿された投稿履歴の中から、「京都駅」および「入場規制」の２つの単語を含む投稿情報を集計する。次に、表示制御装置１００は、「京都駅」および「入場規制」の２つの単語を含む投稿情報を集計した集計数が所定数以上であるか否かを判定する。例えば、表示制御装置１００は、集計数が所定数以上であると判定した場合には、「８時００分」現在では「京都駅」に入場規制がかけられていると推定する。

（パターンＰＴ３について）
次に、ＳＮＳサービス（サービスＳＡ）における投稿履歴を用いるパターンである推定処理パターンＰＴ３（以下、「パターンＰＴ３」と略す）について説明する。パターンＰＴ３でも、表示制御装置１００は、時刻の経過（時刻経過）に応じて随時更新される投稿履歴を取得する。例えば、表示制御装置１００は、時刻経過に応じた所定の時間間隔（例えば、１０分間隔）毎に投稿履歴を取得することで投稿履歴記憶部１２３を更新する。また、表示制御装置１００は、投稿履歴に含まれる投稿情報に基づいて、この投稿情報がどの駅に関する投稿情報であるかを判断することで、投稿履歴を駅別に分ける。

このような状態において、表示制御装置１００は、処理対象の駅別の投稿履歴から、当該処理対象の駅に関して投稿された投稿数を集計する。例えば、表示制御装置１００は、時刻経過に応じて、当該時刻での投稿数を集計する。次に、表示制御装置１００は、今回の集計結果と、通常時における同時刻での平均投稿数とを比較し、今回の集計結果が所定値以上上回っているか否か判定する。そして、表示制御装置１００は、今回の集計結果が所定値以上上回っている場合には、対応する駅に入場規制がかけられていると推定する。

上記パターンＰＴ３について、処理対象の駅として「京都駅」を例に挙げてより詳細に説明する。表示制御装置１００は、時刻経過に応じて、当該時刻での最新の投稿履歴であって、「京都駅」に関する投稿履歴に基づいて、「京都駅」に入場規制がかけられているか否かを推定する。ここで、現在時刻は「８時００分」であるものとする。そうすると、表示制御装置１００は、「京都駅」に対応する投稿履歴から、「８時００分」において「京都駅」に関して投稿された投稿数を集計する。なお、「８時００分」において「京都駅」に関して投稿された投稿数とは、「８時００分」での投稿数であってもよいし、「８時００分」までの投稿数の累計であってもよい。例えば、表示制御装置１００は、「京都駅」に対応する投稿履歴から、「８時００分」において「京都駅」に関して投稿された投稿数として「Ｎ２１」を集計したとする。次に、表示制御装置１００は、今回の集計結果である「Ｎ２１」と、「８時００分」での平均投稿数であって、通常時における「京都駅」での平均投稿数「Ｎ２２」（所定の基準値）とを比較し、Ｎ２１がＮ２２を所定値以上上回っているか否か判定する。例えば、表示制御装置１００は、Ｎ２１がＮ２２を所定値以上上回っていると判定した場合には、「８時００分」現在では「京都駅」に入場規制がかけられていると推定する。

なお、上記例では、表示制御装置１００が、所定の基準値として、「８時００分」での平均投稿数であって、通常時における「京都駅」での平均投稿数を用いている例が示されているが、表示制御装置１００は、入場規制がかけられることのなかった所定１ヶ月間での平均投稿数を所定の基準値として用いてもよい。また、表示制御装置１００は、「８時００分」現在における「京都駅」に対応する最新の投稿履歴から、単位時間当たりの投稿数（例えば、投稿数／１０分、あるいは、投稿数／１時間）を集計してもよい。例えば、表示制御装置１００は、単位時間当たりの投稿数として「Ｎ２３／１０分」を算出したとする。この場合には、表示制御装置１００は、今回の集計結果である「Ｎ２３／１０分」と、「８時００分」代での単位時間当たりの平均投稿数であって、通常時における「京都駅」での単位時間当たりの平均投稿数「Ｎ２４」（所定の基準値）とを比較し、Ｎ２３がＮ２４を所定値以上上回っているか否か判定する。例えば、表示制御装置１００は、Ｎ２３がＮ２４を所定値以上上回っていると判定した場合には、「８時００分」現在では「京都駅」に入場規制がかけられていると推定する。なお、このように単位時間当たりの数を用いる手法はパターンＰＴ１での検索数にも応用可能である。

（パターンＰＴ４について）
次に、検索サービス（アプリＡＰ）における検索履歴と、ＳＮＳサービス（サービスＳＡ）における投稿履歴の双方を組み合わせて用いるパターンである推定処理パターンＰＴ４（以下、「パターンＰＴ４」と略す）について説明する。例えば、表示制御装置１００は、まず、パターンＰＴ１で処理対象の駅毎に入場規制がかけられているか否かを推定する。そして、表示制御装置１００は、処理対象の駅の中に入場規制がかけられていると推定した駅が存在する場合、この駅を対象として、パターンＰＴ２またはＰＴ３の推定処理を適用する。例えば、表示制御装置１００は、パターンＰＴ２またはＰＴ３でもこの駅に入場規制がかけられていると推定した場合には、この駅に入場規制がかけられているとの推定を確定させることができる。

このように検索履歴を用いた推定処理と、投稿履歴を用いた推定処理を組み合わせることで、表示制御装置１００は、推定精度をより高めることができる。例えば、パターンＰＴ２のみで入場規制がかけられているかを推定しようとした場合、「下北沢駅、ライブハウス混雑」といったノイズの投稿情報も集計に含まれてしまう可能性がある。そうすると、表示制御装置１００は、実際には、下北沢駅は混雑していないにも拘らず混雑している、すなわち入場規制の可能性があると推定してしまうかもしれない。このようなとき、検索履歴を用いた推定処理を組み合わせれば、表示制御装置１００は、ノイズに基づく推定結果を除去することができるため、推定精度をより高めることができる。

（パターンＰＴ５について）
次に、駅での混雑度を用いるパターンである推定処理パターンＰＴ５（以下、「パターンＰＴ５」と略す）について説明する。混雑度とは、駅での混雑状況の度合いを示す指標値であり、例えば、この駅にいると予測される人数に基づく情報に応じて、例えば、数段階のレベルによって示される。

パターンＰＴ５では、表示制御装置１００は、時刻の経過（時刻経過）に応じて随時更新される検索履歴を取得する。例えば、表示制御装置１００は、時刻経過に応じた所定の時間間隔（例えば、１０分間隔）毎に検索履歴を取得する。また、表示制御装置１００は、時刻の経過（時刻経過）に応じて随時更新される投稿履歴を取得する。例えば、表示制御装置１００は、時刻経過に応じた所定の時間間隔（例えば、１０分間隔）毎に投稿履歴を取得する。

このような状態において、表示制御装置１００は、処理対象の駅別の検索履歴から、当該処理対象の駅に関して検索された検索数を集計する。例えば、表示制御装置１００は、時刻経過に応じて、当該時刻での検索数を集計する。表示制御装置１００は、処理対象の駅別の投稿履歴から、当該処理対象の駅に関して投稿された投稿数を集計する。例えば、表示制御装置１００は、時刻経過に応じて、当該時刻での投稿数を集計する。

次に、表示制御装置１００は、集計結果に基づいて、処理対象の駅での混雑度を算出する。表示制御装置１００は、検索数に関する集計結果と、投稿数に関する集計結果とを掛け合わせることで混雑度を算出してもよいし、検索数に関する集計結果または投稿数に関する集計結果のいずれか一方だけで混雑度を算出してもよい。例えば、表示制御装置１００は、集計結果に基づいて、集計結果に対応する処理対象の駅での人数を予測し、予測した人数に応じた混雑度を算出する。例えば、表示制御装置１００は、時刻経過に応じて、当該時刻での混雑度を算出する。例えば、表示制御装置１００は、現在時刻での最新の履歴情報（検索履歴または投稿履歴）を集計することにより、集計結果に基づいて、集計結果に対応する処理対象の駅での人数を予測し、予測した人数に応じた混雑度を算出する。一例を示すと、表示制御装置１００は、「７時２０分」における「京都駅」での混雑度、「７時３０分」における「京都駅」での混雑度、「７時４０分」における「京都駅」での混雑度、「７時５０分」における「京都駅」での混雑度、「８時００分」における「京都駅」での混雑度、といった形で１０分間隔でその時点での最新の混雑度を算出する。

なお、表示制御装置１００は、集計結果だけでなく、投稿情報が示す投稿内容や投稿画像から得られた情報をさらに組み合わせることで、処理対象の駅での人数を予測することができる。例えば、表示制御装置１００は、「京都駅の改札前めっちゃ混雑して動けない」といったコメントともに、混雑の様子が映された画像を含む投稿情報を取得したとする。かかる場合、表示制御装置１００は、例えば、この投稿情報と、京都駅改札前のキャパシティとに基づいて、京都駅改札前の人数を予測することができる。また、表示制御装置１００は、処理対象の駅に設置されるカメラによる撮像情報を取得することで、取得した撮像映像から処理対象の駅での人数を予測することもできる。

そして、表示制御装置１００は、処理対象の駅での混雑度が所定値以上であるか否か判定する。表示制御装置１００は、混雑度が所定値以上であると判定した場合には、処理対象の駅に入場規制がかけられていると推定する。例えば、表示制御装置１００は、「８時００分」現在における「京都駅」での混雑度「レベル４」を算出し、また、所定値「３」が予め設定されている場合には、京都駅に入場規制がかけられていると推定する。不図示であるが、表示制御装置１００は、後の表示制御のために、駅毎の推定結果を所定の記憶部に記憶させておくことができる。

ここまで、ステップＳ１１での推定処理として、図４に示す推定処理パターンＰＴ１～ＰＴ５それぞれについて説明してきた。ここからは図３の説明に戻る。表示制御装置１００は、時刻経過に応じてリアルタイムに各駅について推定処理を行っているが、このようなときユーザＵ１は、アプリＡＰを介して検索条件を入力し表示制御装置１００に対して検索条件を送信したとする。ユーザＵ１は、端末装置１０がアプリＡＰによる制御に応じて表示画面Ｄに表示させる入力ページＰ１に検索条件を入力することができる。

図３の例では、ユーザＵ１の端末装置１０の表示画面Ｄにおいて、路線検索のための検索条件を入力するための入力ページＰ１が表示されている。端末装置１０は、アプリＡＰの制御に従って、このような入力ページＰ１を表示画面Ｄに表示させる。また、図３の例では、入力ページＰ１には、出発駅を入力させるための入力欄ＡＲ１１、経由駅を入力させるための入力欄ＡＲ１２、到着駅を入力させるための入力欄ＡＲ１３、時刻を入力させるための入力欄ＡＲ１４が含まれる。また、図３の例では、入力ページＰ１には、上記入力欄に入力された検索条件で検索するよう要求する検索ボタンＢＴが含まれる。このような状態において、ユーザＵ１は、図３に示すように、出発駅として「京都」を入力し、到着駅として「西九条」を入力し、また、時刻として「８：００」を入力し、検索ボタンＢＴを押下したとする。すなわち、図３の例では、ユーザＵ１は、「京都駅から西九条駅間の路線を検索するとともに、京都駅から西九条駅間の路線において８時００分以降で利用可能な車両としてどのような車両があるのかを検索するよう条件付ける検索条件」を入力したといえる。

かかる場合、端末装置１０は、入力された検索条件を表示制御装置１００に送信する。そうすると、表示制御装置１００は、端末装置１０から検索条件を受信する（ステップＳ１２）。

次に、表示制御装置１００は、検索条件を用いて検索を行うことにより、検索条件を満たす情報を特定（検索）する（ステップＳ１３）。例えば、表示制御装置１００は、検索条件を満たす路線経路を特定するとともに、特定した経路（特定経路）に含まれる各路線について、検索条件を満たす車両を特定する。ここで、検索条件を満たす車両とは、検索条件を満たす車両がどのような車両であるかを識別可能な情報、すなわち車両識別情報であり、車両識別情報は、例えば、車両種別（特急、急行、快速、新快速等）および車両番号（冠名、車両番号、末尾記号で構成される車両番号）で示される。不図示であるが、表示制御装置１００は、例えば、検索用の所定のデータベースを検索することができる。

後に、図５でも示すが、図３の例では、表示制御装置１００は、検索条件を満たす路線経路として、京都駅－大阪駅間を結ぶ「ＡＡ線」と、大阪駅－西九条駅間を結ぶ「ＡＢ線」を特定したとする。また、表示制御装置１００は、検索条件を満たす車両として、ＡＡ線において京都駅「８時００分発」－大阪駅「８時２８分着」の「快速Ｋ１」と、ＡＢ線において大阪駅「８時３８分発」－西九条駅「８時４３分着」の「快速Ｋ２」とを特定したとする。

次に、表示制御装置１００は、利用候補駅に対応する推定結果を取得する（ステップＳ１４）。利用候補駅とは、図３の例では、ユーザＵ１が乗車しようとする出発駅である。したがって、図３の例では、表示制御装置１００は、検索条件で出発駅「京都駅」が指定されていることに応じて、「京都」に対応する推定結果（ステップＳ１１での推定処理による推定結果）を取得する。例えば、表示制御装置１００は、「８時００分」おいて推定した推定結果を取得してもよいし、「８時００分」までの１０分間隔での推定結果を全て取得してもよい。かかる例では、表示制御装置１００は、ユーザＵ１によって検索が行われた「８時００分」現在における「京都駅」に対する推定結果として、「京都駅は普段よりかなり混雑している可能性があるため、入場規制されている可能性がある」ことを示す推定結果ＫＹＲＥ８を取得したものとする。

次に、表示制御装置１００は、ステップＳ１４で取得した推定結果が表示されるような配信対象のページを生成する（ステップＳ１５）。図３の例では、表示制御装置１００は、推定結果ＫＹＲＥ８が表示されるような配信対象のページ（後述する路線案内ページＰ１１ａに対応）を生成する。また、図３の例では、表示制御装置１００は、推定結果ＫＹＲＥ８に関する詳細情報が表示されるような配信対象のページ（後述する結果詳細ページＰ１１ｂに対応）を生成する。推定結果ＫＹＲＥ８や詳細情報は、入出規制がかけられていると推定された駅（かかる例では、京都駅）に関する駅情報の一例である。また、このような駅情報が表示される配信対象のページを生成することは、駅情報が表示されるよう表示制御することと同義である。そして、表示制御装置１００は、生成した配信対象のページをユーザＵ１の端末装置１０に配信する（ステップＳ１６）。図３の例では、表示制御装置１００は、検索条件を送信したユーザＵ１の端末装置１０に配信対象のページを配信する。

ここまで、図３を用いて実施形態にかかる表示制御処理の大まかな流れについて説明した。以下では、ステップＳ１５での表示制御処理についてより詳細に説明してゆく。

〔２－１．表示制御処理の一例（１）〕
ステップＳ１５によると、表示制御装置１００は、推定結果が表示されるような配信対象のページ、および、結果詳細が表示されるような配信対象のページといった２つ配信対象のページを生成している。ここではまず、推定結果が表示されるような配信対象のページについて図５を用いて説明する。図５は、実施形態にかかる配信対象のページ（１）の一例を示す図である。

図５に示す通り、表示制御装置１００は、配信対象のページとして、検索条件に対応する検索結果としての路線案内が表示されるような路線案内ページＰ１１ａを生成する。図３に示した検索条件の例を用いると、路線案内ページＰ１１ａには、京都駅から西九条駅間の路線経路としては、「京都駅－大阪駅間を結ぶＡＡ線」と、「大阪駅－西九条駅間を結ぶＡＢ線」とによる路線経路が存在することが表示される。また、図３に示した検索条件の例を用いると、路線案内ページＰ１１ａには、京都駅から西九条駅間の路線において８時００分以降で利用可能な車両として、「京都駅－大阪駅間を結ぶＡＡ線」では京都駅「８時００分発」－大阪駅「８時２８分着」の「快速Ｋ１」が存在し、「大阪駅－西九条駅間を結ぶＡＢ線」では大阪駅「８時３８分発」－西九条駅「８時４３分着」の「快速Ｋ２」が存在することが表示される。

また、「８時００分」現在において、「京都駅」は入場規制されていると推定された上記例によれば、路線案内ページＰ１１ａには、図５に示すように、「京都駅は普段よりかなり混雑している可能性があるため、入場規制されている可能性がある」ことを示す推定結果ＫＹＲＥ８が表示される。具体的には、図５に示す路線案内ページＰ１１ａの例では、「京都」という単語表示の下部に、「入場規制の可能性あり」と表示されている。ここで、例えば、ユーザＵ１は、これから利用しようと考えている「京都駅」について自宅で検索していたとすると、自宅にいながらにして「京都駅」が入場規制されているかもしれないことを知ることができるため、他の駅の利用を検討する等の結果、効率的に駅を利用することができるようになる。

また、このような推定結果ＫＹＲＥ８には、推定結果ＫＹＲＥ８に関する詳細情報が表示されるような配信対象のページである結果詳細ページＰ１１ｂへと遷移可能なリンクが貼り付けられる。図５の例では、「入場規制の可能性あり」と表示には、リンクが貼り付けられることによりボタン化されている。このようなボタンを図５のようにボタンＷＡ２１とすると、ユーザＵ１は、ボタンＷＡ２１を押下することで、結果詳細ページＰ１１ｂへと遷移し推定結果ＫＹＲＥ８に関する詳細情報を閲覧することができるようになる。なお、このようなことから、表示制御装置１００は、ボタンＷＡ２１を押下された段階で結果詳細ページＰ１１ｂを生成してもよい。

〔２－２．表示制御処理の一例（２）〕
ここからは、結果詳細が表示されるような配信対象のページについて図６を用いて説明する。図６は、実施形態にかかる配信対象のページ（２）の一例を示す図である。図６に示す通り、表示制御装置１００は、配信対象のページとして、推定結果に関する詳細情報が表示されるような結果詳細ページＰ１１ｂを生成する。結果詳細ページＰ１１ｂは、入出規制がかけられていると推定された場合に、入出規制と推定されている駅を対象に生成される。したがって、以下で説明する詳細情報ＩＮＦ１１１、詳細情報ＩＮＦ１１２、および、詳細情報ＩＮＦ１１３は、入出規制がかけられていると推定された場合に表示される駅情報といえる。

図６の例では、結果詳細ページＰ１１ｂには、詳細情報ＩＮＦ１１１、詳細情報ＩＮＦ１１２、および、詳細情報ＩＮＦ１１３が表示されている。詳細情報ＩＮＦ１１１は、処理対象の駅に対する推定結果に対応する。図６の例では、詳細情報ＩＮＦ１１１は、「８時００分現在において京都駅に入場規制がかけられている」ことを示す推定結果ＫＹＲＥ８に対応する。

また、詳細情報ＩＮＦ１１２は、処理対象の駅での混雑状況の度合いを示す混雑度の変化であって、時刻経過（時間経過）に応じた変化を示すグラフ情報に対応する。図６の例では、詳細情報ＩＮＦ１１２は、京都駅での混雑状況の度合いを示す混雑度の変化であって、時刻経過（時間経過）に応じた変化を示すグラフ情報に対応する。より詳細には、詳細情報ＩＮＦ１１２は、「７時２０分」における「京都駅」での混雑度「レベル１」、「７時３０分」における「京都駅」での混雑度「レベル１」、「７時４０分」における「京都駅」での混雑度「レベル１」、「７時５０分」における「京都駅」での混雑度「レベル２」、「８時００分」における「京都駅」での混雑度「レベル４」、といった時刻経過に応じた混雑度の変化を示すグラフ情報に対応する。なお、ここで表示される混雑度は、上記説明した推定処理パターンＰＴ５の例で、「京都駅」に対して入場規制がかけられているか否かを推定する際に算出された混雑度である。

また、詳細情報ＩＮＦ１１３は、処理対象の駅周辺の駅情報に対応する。図６の例では、詳細情報ＩＮＦ１１３は、「京都駅」周辺の駅情報に対応する。また、詳細情報ＩＮＦ１１３には、「京都駅」周辺の駅であって、入場規制がかけれている可能性がある現時点において、「京都駅」以外に利用可能な周辺の駅に関する周辺駅情報ＩＮＦ１１３ａが含まれる。表示制御装置１００は、例えば、周辺駅情報ＩＮＦ１１３ａが押下された場合には、「京都駅」以外に利用可能な周辺の駅を解決策（入場規制や混雑を回避する回避策ともいえる）として提示する周辺駅情報を表示させることができる。また、詳細情報ＩＮＦ１１３には、「京都駅」周辺の路線であって、入場規制がかけれている可能性がある現時点において、検索条件に対応するＡＡ線であって、「京都駅」を含むＡＡ線以外に利用可能な周辺路線に関する周辺路線情報ＩＮＦ１１３ｂが含まれる。表示制御装置１００は、例えば、周辺路線情報ＩＮＦ１１３ｂが押下された場合には、ＡＡ線以外に利用可能な周辺路線を解決策として提示する周辺路線情報を表示させることができる。

このように、表示制御装置１００は、入出規制がかけられている可能性のある駅の周辺情報として、当該駅の代わりに利用可能な周辺の駅や路線を表示させる。これにより、表示制御装置１００は、入出規制に巻き込まれたユーザが移動の代替手段を効率的に検討できるよう支援することができる。

また、詳細情報ＩＮＦ１１３には、「京都駅」周辺の駅であって、入場規制がかけられている可能性がある現時点において、「京都駅」周辺で利用可能な施設（例えば、娯楽施設や図書館等）に関する施設情報ＩＮＦ１１３ｃが含まれる。表示制御装置１００は、例えば、施設情報ＩＮＦ１１３ｃが押下された場合には、「京都駅」周辺で利用可能な施設に関する施設情報を表示させることができる。また、詳細情報ＩＮＦ１１３には、「京都駅」周辺の駅であって、入場規制がかけられている可能性がある現時点において、「京都駅」周辺で利用可能なカフェに関するカフェ情報ＩＮＦ１１３ｄが含まれる。表示制御装置１００は、例えば、カフェ情報ＩＮＦ１１３ｄが押下された場合には、「京都駅」周辺で利用可能なカフェに関するカフェ情報を表示させることができる。また、詳細情報ＩＮＦ１１３には、「京都駅」周辺の駅であって、入場規制がかけられている可能性がある現時点において、「京都駅」周辺で利用可能なレストランに関するレストラン情報ＩＮＦ１１３ｅが含まれる。表示制御装置１００は、例えば、レストラン情報ＩＮＦ１１３ｅが押下された場合には、「京都駅」周辺で利用可能なレストランに関するレストラン情報を表示させることができる。

このように、表示制御装置１００は、入出規制がかけられている可能性のある駅の周辺情報として、当該駅の代わりに利用可能な周辺施設等を表示させる。これにより、表示制御装置１００は、入出規制に巻き込まれたユーザが時間をつなげるような場所を提示することができる。

〔３．表示制御処理にかかる効果〕
さて、これまで説明してきたように、実施形態にかかる表示制御装置１００は、処理対象の駅に関する所定の情報に基づいて、当該駅に対して入出規制がかけられているか否かを推定する。例えば、表示制御装置１００は、アプリＡＰにおける検索履歴、あるいは、サービスＳＡにおける投稿履歴に基づいて、処理対象の駅に対して入出規制がかけられているか否かを推定する。一例としては、表示制御装置１００は、検索履歴や投稿履歴を集計し、集計結果と基準値とを比較した場合の比較結果が乖離を示す場合には、処理対象の駅に入出規制がかけられていると推定する。そして、表示制御装置１００は、入出規制がかけられていると推定した場合には、当該入出規制がかけられていると推定された駅に関する駅情報を表示させる。例えば、表示制御装置１００は、検索条件に対応する路線案内ページ内に入出規制がかけられている可能性がある旨の推定結果を表示される。また、例えば、表示制御装置１００は、上記推定結果に対応する結果詳細ページ内に混雑度や周辺情報を表示させる。

これにより、表示制御装置１００は、ユーザが時間を無駄にすることなく効率的に駅を利用できるよう支援することができる。また、表示制御装置１００は、ユーザが混雑による二次災害に巻き込まれることを事前に防止することができる。また、表示制御装置１００は、入出規制を回避する回避策の模索にかかるユーザの労力を低減できるよう支援することができる。

〔４．表示制御装置の構成〕
次に、図８を用いて、実施形態にかかる表示制御装置１００について説明する。図８は、実施形態にかかる表示制御装置１００の構成例を示す図である。図８に示すように、表示制御装置１００は、通信部１１０と、記憶部１２０と、制御部１３０とを有する。例えば、表示制御装置１００は、図３～図６で説明した表示制御処理を行うサーバ装置である。

（通信部１１０について）
通信部１１０は、例えば、ＮＩＣ（Network Interface Card）等によって実現される。そして、通信部１１０は、ネットワークＮと有線または無線で接続され、例えば、端末装置１０、外部装置３０との間で情報の送受信を行う。

（記憶部１２０について）
記憶部１２０は、例えば、ＲＡＭ（Random Access Memory)、フラッシュメモリ等の半導体メモリ素子またはハードディスク、光ディスク等の記憶装置によって実現される。記憶部１２０は、時刻表情報記憶部１２１と、検索履歴記憶部１２２と、投稿履歴記憶部１２３とを有する。

（時刻表情報記憶部１２１について）
時刻表情報記憶部１２１は、時刻表に関する情報を記憶する。例えば、時刻表情報記憶部１２１は、路線に含まれる駅毎に、到着予定時刻と当該到着予定時刻に来る車両の車両種別とを対応付けて記憶する。ここで、図９に実施形態にかかる時刻表情報記憶部１２１の一例を示す。図９の例では、時刻表情報記憶部１２１は、「路線ＩＤ」、「路線名」、「時刻表情報」といった項目を有する。

「路線ＩＤ」は、路線を識別する識別情報を示す。「路線名」は、対応する「路線ＩＤ」によって識別される路線の路線名を示す。「時刻表情報」は、対応する「路線ＩＤ」によって識別される路線に含まれる駅毎に、到着予定時刻と当該到着予定時刻に来る車両の車両種別とが対応付けられた時刻テーブルである。

すなわち、図９の例では、路線ＩＤ「Ｌ１」によって識別されるＡＡ線での時刻表情報が「ＴＢＤＡ１」である例を示す。

（検索履歴記憶部１２２について）
検索履歴記憶部１２２は、路線に関する所定の検索サービスにおける検索履歴を記憶する。例えば、検索履歴記憶部１２２は、路線案内サービスを提供するアプリＡＰを利用した路線検索における検索履歴を記憶する。ここで、図１０に実施形態にかかる検索履歴記憶部１２２の一例を示す。図１０の例では、検索履歴記憶部１２２は、「ユーザＩＤ」、「日時情報」、「出発駅情報」、「検索情報」といった項目を有する。

「ユーザＩＤ」は、アプリＡＰを利用して検索を行ったユーザを識別する識別情報を示す。「日時情報」は、検索が行われた日時を示す。「出発駅情報」は、検索条件として指定された出発駅を示す。また、かかる出発駅は、ユーザに利用される可能性のある（例えば、ユーザがこれから向かおうとする）利用候補駅といえる。「検索情報」は、ユーザに指定された一連の検索条件を示す。また、「検索情報」は、１つの検索履歴といえる。

すなわち、図１０の例では、ユーザＩＤ「Ｕ１１」によって識別されるユーザ（ユーザＵ１１）が、日時「ＤＴ１１」において、検索情報「ＳＣＤＡ１」で示される検索条件で検索した例を示す。

（投稿履歴記憶部１２３について）
投稿履歴記憶部１２３は、所定の情報共有サービスにおける投稿履歴を記憶する。例えば、投稿履歴記憶部１２３は、サービスＳＡを利用した情報（コメントや画像）投稿による投稿履歴を記憶する。ここで、図１１に実施形態にかかる投稿履歴記憶部１２３の一例を示す。図１１の例では、投稿履歴記憶部１２３は、「ユーザＩＤ」、「日時情報」、「駅名」、「投稿情報」といった項目を有する。

「ユーザＩＤ」は、サービスＳＡを利用して投稿を行ったユーザを識別する識別情報を示す。「日時情報」は、投稿が行われた日時を示す。「駅名」は、対応する「投稿情報」に含まれる駅名を示す。また、かかる駅名が示す駅は、「投稿情報」は、ユーザに投稿された投稿情報を示す。「投稿情報」は、例えば、コメントや画像であり投稿内容を示すものである。また、「投稿情報」は、１つの投稿履歴といえる。

すなわち、図１１の例では、ユーザＩＤ「Ｕ２１」によって識別されるユーザ（ユーザＵ２１）が、日時「ＤＴ１１」において、投稿情報「ＰＴＤＡ１」で示される内容で投稿した例を示す。

（制御部１３０について）
図８に戻り、制御部１３０は、ＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）等によって、表示制御装置１００内部の記憶装置に記憶されている各種プログラムがＲＡＭを作業領域として実行されることにより実現される。また、制御部１３０は、例えば、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）等の集積回路により実現される。

図８に示すように、制御部１３０は、取得部１３１と、推定部１３２と、算出部１３３と、受信部１３４と、特定部１３５と、表示制御部１３６と、配信部１３７とを有し、以下に説明する情報処理の機能や作用を実現または実行する。なお、制御部１３０の内部構成は、図８に示した構成に限られず、後述する情報処理を行う構成であれば他の構成であってもよい。また、制御部１３０が有する各処理部の接続関係は、図８に示した接続関係に限られず、他の接続関係であってもよい。

（取得部１３１について）
取得部１３１は、各種情報を取得する。例えば、取得部１３１は、時刻の経過（時刻経過）に応じて随時更新される検索履歴を取得する。例えば、取得部１３１は、時刻経過に応じた所定の時間間隔（例えば、１０分間隔）毎に検索履歴を取得する。例えば、取得部１３１は、アプリＡＰに対応するサーバ装置から検索履歴を取得することができる。また、取得部１３１は、検索履歴を取得する度に取得した検索履歴を検索履歴記憶部１２２に格納することで検索履歴記憶部１２２を更新する。

また、取得部１３１は、時刻の経過（時刻経過）に応じて随時更新される投稿履歴を取得する。例えば、取得部１３１は、時刻経過に応じた所定の時間間隔（例えば、１０分間隔）毎に投稿履歴を取得する。例えば、取得部１３１は、サービスＳＡに対応するサーバ装置から投稿履歴を取得することができる。また、取得部１３１は、投稿履歴を取得する度に取得した投稿履歴を投稿履歴記憶部１２３に格納することで投稿履歴記憶部１２３を更新する。

（推定部１３２について）
推定部１３２は、駅に関する所定の情報に基づいて、当該駅に対して入出規制がかけられているか否かを推定する。例えば、推定部１３２は、随時更新される情報履歴を用いて、リアルタイムに処理対象の駅に対して入場規制がかけられているか否かを推定する。例えば、推定部１３２は、処理態様の駅毎に当該駅に関する履歴情報を用いて、処理対象の駅に対して入場規制がかけられているか否かを推定する。例えば、推定部１３２は、図４で説明した５つの推定処理を行うことができる。具体的には、推定部１３２は、推定処理パターンＰＴ１、ＰＴ２、ＰＴ３、ＰＴ４、ＰＴ５といった５つのバリ―ションの推定処理を行うことができる。

パターンＰＴ１によると、推定部１３２は、処理対象の駅に関する所定の情報として、路線に関する所定の検索サービスにおける検索履歴であって、処理対象の駅に関する検索履歴に基づいて、当該駅に対して入出規制がかけられているか否かを推定する。例えば、推定部１３２は、検索履歴を集計して得られた集計結果が所定の条件情報を満たす場合には、処理対象の駅に対して入出規制がかけられていると推定する。例えば、推定部１３２は、集計結果として、処理対象の駅に関して検索された検索数に関する情報、または、処理対象の駅に関して検索されたことによる検索サービスの使用率に基づく情報が、所定の条件情報を満たす場合には、当該駅に対して入出規制がかけられていると推定する。

例えば、推定部１３２は、所定の条件情報を満たす場合として、所定の基準値に対して集計結果が所定値以上の上昇を示す場合には、処理対象の駅に対して入出規制がかけられていると推定する。例えば、推定部１３２は、所定の時刻における所定の基準値に対して当該所定の時刻での集計結果が所定値以上の上昇を示す場合には、処理対象の駅に対して入出規制がかけられていると推定する。

また、例えば、推定部１３２は、処理対象の駅に関する所定の情報として、所定の情報共有サービスにおける投稿履歴であって、処理対象の駅に関する投稿履歴に基づいて、当該駅に対して入出規制がかけられているか否かを推定する。

また、パターンＰＴ２によると、推定部１３２は、所定の情報共有サービスにおける投稿履歴の中に、駅名とともに入出規制に関する文言が含まれる投稿情報が存在する場合には、当該駅名が示す駅に対して入出規制がかけられていると推定する。

また、パターンＰＴ３によると、推定部１３２は、所定の情報共有サービスにおける投稿履歴を集計して得られた集計結果が所定の条件情報を満たす場合には、駅に対して入出規制がかけられていると推定する。例えば、推定部１３２は、集計結果として、処理対象の駅に関する投稿情報の投稿数に基づく情報が、所定の条件情報を満たす場合には、当該駅に対して入出規制がかけられていると推定する。例えば、推定部１３２は、所定の条件情報を満たす場合として、所定の基準値に対して集計結果が所定値以上の上昇を示す場合には、処理対象の駅に対して入出規制がかけられていると推定する。

また、パターンＰＴ４によると、推定部１３２は、まず、パターンＰＴ１で処理対象の駅毎に入場規制がかけられているか否かを推定する。そして、推定部１３２は、処理対象の駅の中に入場規制がかけられていると推定した駅が存在する場合、この駅を対象として、パターンＰＴ２またはＰＴ３の推定処理を適用する。例えば、推定部１３２は、パターンＰＴ２またはＰＴ３でもこの駅に入場規制がかけられていると推定した場合には、この駅に入場規制がかけられているとの推定を確定させる。

また、パターンＰＴ５によると、推定部１３２は、処理対象の駅での混雑状況の度合いを示す混雑度に基づいて、処理対象の駅に対して入出規制がかけられているか否かを推定する。例えば、現在における時刻の経過に応じて当該時刻での混雑度が算出された場合には、推定部１３２は、現在の時刻での混雑度に基づいて、時刻毎に処理対象の駅に対して入出規制がかけられているか否かを推定する。例えば、推定部１３２は、混雑度が所定値以上の場合には、処理対象の駅に入場規制がかけられていると推定する。

（算出部１３３について）
算出部１３３は、処理対象の駅に関する所定の情報に基づいて、当該駅での混雑状況の度合いを示す混雑度を算出する。例えば、算出部１３３は、現在における時刻の経過に応じて当該時刻での混雑度を算出する。例えば、算出部１３３は、路線に関する所定の検索サービスにおける検索履歴であって、処理対象の駅に関する検索履歴に基づいて、混雑度を算出する。一例としては、算出部１３３は、検索履歴を集計することにより、集計結果に基づいて、集計結果に対応する処理対象の駅での人数を予測し、予測した人数に応じた混雑度を算出する。また、例えば、算出部１３３は、所定の情報共有サービスおける投稿履歴であって、処理対象の駅に関する投稿履歴に基づいて、混雑度を算出する。一例としては、算出部１３３は、投稿履歴を集計することにより、集計結果に基づいて、集計結果に対応する処理対象の駅での人数を予測し、予測した人数に応じた混雑度を算出する。

なお、算出部１３３は、集計結果だけでなく、投稿情報が示す投稿内容や投稿画像から得られた情報をさらに組み合わせることで、処理対象の駅での人数を予測することができる。例えば、算出部１３３は、「京都駅の改札前めっちゃ混雑して動けない」といったコメントともに、混雑の様子が映された画像を含む投稿情報を取得したとする。かかる場合、算出部１３３は、例えば、この投稿情報と、京都駅改札前のキャパシティとに基づいて、京都駅改札前の人数を予測することができる。また、算出部１３３は、処理対象の駅に設置されるカメラによる撮像情報を取得することで、取得した撮像映像から処理対象の駅での人数を予測することもできる。

（受信部１３４について）
受信部１３４は、各種情報を受信する。例えば、受信部１３４は、端末装置１０から路線検索のための検索条件を受信する。例えば、受信部１３４は、出発駅、到着駅、時刻を指定する検索条件を受信する。また、受信部１３４は、受信した検索条件を特定部１３５に出力する。

（特定部１３５について）
特定部１３５は、検索条件を用いて検索を行うことにより、検索条件を満たす情報を特定（検索）する。例えば、特定部１３５は、検索条件を用いた路線検索により、検索条件を満たす路線経路を特定する。また、特定部１３５は、特定した経路（特定経路）に含まれる各路線について、検索条件を満たす車両（車両種別）を特定する。図３の例では、特定部１３５は、検索条件を満たす路線経路として、京都駅－大阪駅間を結ぶ「ＡＡ線」と、大阪駅－西九条駅間を結ぶＡＢ線を特定している。また、特定部１３５は、検索条件を満たす車両として、ＡＡ線において京都駅「８時００分発」－大阪駅「８時２８分着」の「快速Ｋ１」と、ＡＢ線において大阪駅「８時３８分発」－西九条駅「８時４３分着」の「快速Ｋ２」とを特定している。

（表示制御部１３６について）
表示制御部１３６は、推定部１３２により入出規制がかけられていると推定された場合には、当該入出規制がかけられていると推定された駅に関する駅情報を表示させる。例えば、表示制御部１３６は、駅に関する駅情報として、入出規制がかけられていると推定された駅の混雑状況または当該駅に対する入出規制の状況を示す状況情報を表示させる。例えば、表示制御部１３６は、路線に関する所定の検索サービスにおける検索結果画面に状況情報を表示させる。

この一例として、表示制御部１３６は、入出規制がかけられていると推定された駅の混雑状況または当該駅に対する入出規制の状況を示す状況情報を表示されるような配信対象のページを生成する。例えば、表示制御部１３６は、検索条件が示す利用候補駅に対する推定部１３２による推定結果を取得し、取得した推定結果が表示されるような配信対象のページを生成する。図３および図５の例によると、表示制御部１３６は、推定結果ＫＹＲＥ８（状況情報の一例）が表示されるような配信対象のページとして、路線案内ページＰ１１ａを生成している。具体的には、表示制御部１３６は、「京都駅は普段よりかなり混雑している可能性があるため、入場規制されている可能性がある」ことを示す推定結果ＫＹＲＥ８が表示される路線案内ページＰ１１ａを生成している。

また、表示制御部１３６は、推定部１３２により入出規制がかけられていると推定された場合には、当該入出規制がかけられていると推定された駅に関する駅情報として、当該駅での混雑状況の度合いを示す混雑度の変化であって、時間経過に応じた変化を示すグラフを表示させる。また、表示制御部１３６は、推定部１３２により入出規制がかけられていると推定された場合には、当該入出規制がかけられていると推定された駅に関する駅情報として、当該駅の周辺情報を表示させる。

この一例として、表示制御部１３６は、混雑度の変化を示すグラフや周辺情報が表示されるような配信対象のページを生成する。例えば、表示制御部１３６は、利用候補駅に対する推定部１３２による推定結果に関する詳細情報が表示されるような配信対象のページを生成する。図３および図５の例によると、表示制御部１３６は、推定結果ＫＹＲＥ８に関する詳細情報が表示されるような配信対象のページとして、結果詳細ページＰ１１ｂを生成している。

例えば、表示制御部１３６は、入出規制がかけられていると推定された駅での混雑状況の度合いを示す混雑度の変化であって、時間経過に応じた変化を示すグラフを示す詳細情報ＩＮＦ１１２が表示される結果詳細ページＰ１１ｂを生成している。また、表示制御部１３６は、入出規制がかけられていると推定された駅周辺の周辺情報を示す詳細情報ＩＮＦ１１３が表示される結果詳細ページＰ１１ｂを生成している。

（配信部１３７について）
配信部１３７は、表示制御部１３６により表示制御（生成）されたページを端末装置１０に配信する。例えば、配信部１３７は、表示制御部１３６により表示制御（生成）された配信対象のページを、検索条件送信元の端末装置１０に配信する。

〔５．処理手順〕
次に、図１２を用いて、実施形態にかかる表示制御処理の手順について説明する。図１２は、実施形態にかかる表示制御処理手順を示すフローチャートである。

まず、推定部１３２は、処理対象の駅毎に、当該駅に関する所定の情報に基づいて、当該駅に入出規制がかけられているか否かを推定する（ステップＳ１０１）。例えば、推定部１３２は、検索サービスやＳＮＳサービスが利用される度に随時更新される履歴情報が取得部１３１により取得されると、検索サービスに対応する検索履歴であって処理対象の駅に関する投稿履歴、または、ＳＮＳサービスに対応する投稿履歴であって処理対象の駅に関する投稿履歴に基づいて、処理対象の駅毎に当該駅に入出規制がかけられているか否かを推定する。例えば、推定部１３２は、図４に示す５つの推定処理の少なくとも何れか１つの推定処理により、入出規制がかけられているか否かを推定することができる。

次に、受信部１３４は、検索条件を受信したか否かを判定する（ステップ１０２）。受信部１３４は、検索条件を受信していない場合には（ステップ１０２；Ｎｏ）、検索条件を受信するまで待機する。特定部１３５は、検索条件が受信された場合には（ステップ１０２；Ｙｅｓ）、検索条件を用いた検索による特定処理を行う（ステップＳ１０３）。例えば、特定部１３５は、検索条件を用いた路線検索により、検索条件を満たす路線経路を特定する。また、特定部１３５は、特定した経路（特定経路）に含まれる各路線について、検索条件を満たす車両（車両種別）を特定する。

次に、表示制御部１３６は、検索条件が示す利用候補駅に入出規制がかけられているか否かを判定する（ステップＳ１０４）。例えば、表示制御部１３６は、推定部１３２による推定結果を取得し、取得した推定結果のうち利用候補駅に対応する検索結果に基づいて、利用候補駅に入出規制がかけられているか否かを判定する。

次に、表示制御部１３６は、ステップＳ１０４での判定結果に応じた態様の路線案内（経路案内）ページを生成する（ステップＳ１０５）。例えば、表示制御部１３６は、利用候補駅に入出規制がかけられていないと判定した場合には、単に検索条件に対応する検索結果が経路線案内として表示される路線案内ページを生成する。検索条件に対応する検索結果とは、ステップＳ０１で特定された情報である。一方、表示制御部１３６は、利用候補駅に入出規制がかけられていると判定した場合には、検索条件に対応する検索結果が路線案内として表示され、かつ、利用候補駅に対応する推定結果、すなわち利用候補駅に対して入出規制がかけられている可能性があるとの推定結果が表示される路線案内ページを生成する。

なお、表示制御部１３６は、このとき推定結果に関する詳細情報（混雑度や周辺情報等）が表示される結果詳細ページも生成してよい。また、表示制御部１３６は、路線案内ページを介して結果詳細ページの配信要求（図５でいうところのボタンＷＡ２１の押下）を油浸した場合に、結果詳細ページを生成してもよい。

そして、配信部１３７は、表示制御部１３６により表示制御（生成）された路線案内ページを、検索条件送信元の端末装置１０に配信する（ステップＳ１０６）。

〔６．変形例〕
上記実施形態にかかる表示制御装置１００は、上記実施形態以外にも種々の異なる形態にて実施されてよい。そこで、以下では、表示制御装置１００の他の実施形態について説明する。

〔６－１．プッシュ通知〕
上記実施形態では、表示制御部１３６は、推定部１３２により入出規制がかけられていると推定された場合には、当該入出規制がかけられていると推定された駅に関する駅情報（例えば、入出規制がかけられている可能性があることを示す駅情報）が、路線案内ページ内に表示されるよう表示制御する例を示した。この場合、駅情報がユーザに通知されるトリガーは、これまでの説明の通り、ユーザから検索条件を受信することである。しかし、表示制御部１３６は、推定部１３２により入出規制がかけられていると推定された場合、すなわち入出規制がかけられていると推定された駅が存在する場合には、ユーザからの要求なしに、この駅に関する駅情報をユーザに通してもよい。要するに、表示制御部１３６は、入出規制がかけられていると推定された駅が存在する場合には、この駅に関する駅情報を生成し、生成した駅情報がユーザにプッシュ通知されるよう配信部１３７に指示する。

例えば、表示制御部１３６は、推定部１３２により入出規制がかけられていると推定された場合に、プッシュ通知すべきタイミングであるか否かを判定する。例えば、表示制御部１３６は、推定部１３２により入出規制がかけられていると推定された場合に、ユーザが情報を欲する時刻（例えば、通勤の時間帯）であるか否かを判定し、ユーザが情報を欲する時刻であれば、プッシュ通知すべきタイミングであると判定する。

そして、表示制御部１３６は、プッシュ通知すべきタイミングであると判定すると、入出規制がかけられていると推定された駅を日常的に利用するユーザを特定する。例えば、表示制御部１３６は、入出規制がかけられていると推定された駅を通勤で利用するユーザを特定する。例えば、表示制御部１３６は、表示制御装置１００を管理する事業者に対して会員登録しているユーザの登録情報、あるいは、かかるユーザの行動履歴に基づいて、入出規制がかけられていると推定された駅を通勤で利用するユーザを特定する。なお、このような特定は、表示制御部１３６以外の処理部で行われてもよい。そして、表示制御部１３６は、入出規制がかけられていると推定された駅に関する駅情報（例えば、入出規制がかけられている可能性があることを示す駅情報）を生成し、生成した駅情報が特定したユーザにプッシュ通知されるよう配信部１３７に指示する。

このように、実施形態にかかる表示制御装置１００は、入出規制がかけられていると推定された駅に関する駅情報をプッシュ通知する。これにより、表示制御装置１００は、入出規制がかけられている可能性があることをユーザが知る機会を増やすことができるため、ユーザの満足度を高めることができる。

〔６－２．収束時刻を推定〕
また、上記実施形態では、推定部１３２が、駅に関する所定の情報に基づいて、当該駅に対して入出規制がかけられているか否かを推定する例を示した。しかし、推定部１３２は、入出規制がかけられていると推定された駅について、当該駅に関する混雑の統計情報に基づいて、混雑の収束時刻をさらに推定（予測）してもよい。かかる場合、表示制御部１３６は、駅に関する駅情報として、推定部により推定された収束時刻も表示させる。以下、混雑の収束時刻の一例として、入場規制が解除される解除時刻を例に用いて説明する。

例えば、推定部１３２は、「８時００分」現在において「京都駅」に入場規制がかけられていると推定しているとする。かかる場合、推定部１３２は、「京都駅」では統計的にどれくらいの時間（例えば、２時間）で入場規制が解除されているかといった統計的に判明している入場規制の時間間隔を用いて、この後何時位に入場規制が解除される可能性があるかを予測する。例えば、推定部１３２は、「１０時００分」に入場規制が解除されると予測したとする。そうすると、表示制御部１３６は、例えば、入場規制解除予想時刻「１０時００分」といった情報を路線案内ページＰ１１ａ内にさらに表示させる。なお、表示制御部１３６は、例えば、統計的に判明している入場規制されるであろう時間（例えば、２時間）を表示させてもよい。

このように、実施形態にかかる表示制御装置１００は、駅での混雑の収束時刻をさらに推定しそれを表示させる。これにより、ユーザは、例えば、これから駅に向かえば混雑が解消している頃だから駅に向かっても問題ない、あるいは、当分混雑は解消される見込みはなさそうだから別の手段を考えよう等と判断することができるようになる。したがって、表示制御装置１００は、ユーザによる判断を効果的に支援することができる。

〔７．ハードウェア構成〕
また、上記実施形態にかかる表示制御装置１００は、例えば図１３に示すような構成のコンピュータ１０００によって実現される。図１３は、表示制御装置１００の機能を実現するコンピュータ１０００の一例を示すハードウェア構成図である。コンピュータ１０００は、ＣＰＵ１１００、ＲＡＭ１２００、ＲＯＭ１３００、ＨＤＤ１４００、通信インターフェイス（Ｉ／Ｆ）１５００、入出力インターフェイス（Ｉ／Ｆ）１６００、及びメディアインターフェイス（Ｉ／Ｆ）１７００を有する。

ＣＰＵ１１００は、ＲＯＭ１３００又はＨＤＤ１４００に格納されたプログラムに基づいて動作し、各部の制御を行う。ＲＯＭ１３００は、コンピュータ１０００の起動時にＣＰＵ１１００によって実行されるブートプログラムや、コンピュータ１０００のハードウェアに依存するプログラム等を格納する。

ＨＤＤ１４００は、ＣＰＵ１１００によって実行されるプログラム、および、かかるプログラムによって使用されるデータ等を格納する。通信インターフェイス１５００は、通信網５０を介して他の機器からデータを受信してＣＰＵ１１００へ送り、ＣＰＵ１１００が生成したデータを、通信網５０を介して他の機器へ送信する。

ＣＰＵ１１００は、入出力インターフェイス１６００を介して、ディスプレイやプリンタ等の出力装置、及び、キーボードやマウス等の入力装置を制御する。ＣＰＵ１１００は、入出力インターフェイス１６００を介して、入力装置からデータを取得する。また、ＣＰＵ１１００は、生成したデータを、入出力インターフェイス１６００を介して出力装置へ出力する。

メディアインターフェイス１７００は、記録媒体１８００に格納されたプログラム又はデータを読み取り、ＲＡＭ１２００を介してＣＰＵ１１００に提供する。ＣＰＵ１１００は、かかるプログラムを、メディアインターフェイス１７００を介して記録媒体１８００からＲＡＭ１２００上にロードし、ロードしたプログラムを実行する。記録媒体１８００は、例えばＤＶＤ（Digital Versatile Disc）、ＰＤ（Phase change rewritable Disk）等の光学記録媒体、ＭＯ（Magneto-Optical disk）等の光磁気記録媒体、テープ媒体、磁気記録媒体、または半導体メモリ等である。

例えば、コンピュータ１０００が実施形態にかかる表示制御装置１００として機能する場合、コンピュータ１０００のＣＰＵ１１００は、ＲＡＭ１２００上にロードされたプログラムを実行することにより、制御部１３０の機能を実現する。また、ＨＤＤ１４００には、記憶部１２０内のデータが格納される。コンピュータ１０００のＣＰＵ１１００は、これらのプログラムを、記録媒体１８００から読み取って実行するが、他の例として、他の装置から、通信網５０を介してこれらのプログラムを取得してもよい。

〔８．その他〕
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。

以上、本願の実施形態をいくつかの図面に基づいて詳細に説明したが、これらは例示であり、発明の開示の欄に記載の態様を始めとして、当業者の知識に基づいて種々の変形、改良を施した他の形態で本発明を実施することが可能である。

また、上述してきた「部（section、module、unit）」は、「手段」や「回路」などに読み替えることができる。例えば、取得部は、取得手段や取得回路に読み替えることができる。

１ 表示制御システム
１０ 端末装置
３０ 外部装置
１００ 表示制御装置
１２０ 記憶部
１２１ 時刻表情報記憶部
１２２ 検索履歴記憶部
１２３ 投稿履歴記憶部
１３０ 制御部
１３１ 取得部
１３２ 推定部
１３３ 算出部
１３４ 受信部
１３５ 特定部
１３６ 表示制御部
１３７ 配信部

Claims (22)

1. 駅に関する所定の情報に基づいて、当該駅に対して入出規制がかけられているか否かを推定する推定部と、
   前記推定部により入出規制がかけられていると推定された場合には、当該入出規制がかけられていると推定された駅に関する駅情報を表示させる表示制御部と
   を有し、
   前記推定部は、前記駅に関する所定の情報として、路線に関する所定の検索サービスにおける検索履歴であって、前記駅に関する検索履歴に基づいて、混雑の発生に関係なく、前記駅に対して入出規制がかけられているか否かを推定する
   ことを特徴とする表示制御装置。
2. 前記推定部は、前記駅に対して混雑の発生に起因しない入出規制がかけられているか否かを推定する
   ことを特徴とする請求項１に記載の表示制御装置。
3. 前記推定部は、前記検索履歴を集計して得られた集計結果が所定の条件情報を満たす場合には、前記駅に対して入出規制がかけられていると推定する
   ことを特徴とする請求項２に記載の表示制御装置。
4. 前記推定部は、前記集計結果として、前記駅に関して検索された検索数に関する情報、または、前記駅に関して検索されたことによる前記検索サービスの使用率に基づく情報が、前記所定の条件情報を満たす場合には、当該駅に対して入出規制がかけられていると推定する
   ことを特徴とする請求項３に記載の表示制御装置。
5. 前記推定部は、前記所定の条件情報を満たす場合として、所定の基準値に対して前記集計結果が所定値以上の上昇を示す場合には、前記駅に対して入出規制がかけられていると推定する
   ことを特徴とする請求項３または４に記載の表示制御装置。
6. 前記推定部は、所定の時刻における前記所定の基準値に対して当該所定の時刻での前記集計結果が所定値以上の上昇を示す場合には、前記駅に対して入出規制がかけられていると推定する
   ことを特徴とする請求項５に記載の表示制御装置。
7. 前記推定部は、前記駅に関する所定の情報として、所定の情報共有サービスにおける投稿履歴であって、前記駅に関する投稿履歴に基づいて、当該駅に対して入出規制がかけられているか否かを推定する
   ことを特徴とする請求項１～６のいずれか１つに記載の表示制御装置。
8. 前記推定部は、前記投稿履歴の中に、駅名とともに入出規制に関する文言が含まれる投稿情報が存在する場合には、当該駅名が示す駅に対して入出規制がかけられていると推定する
   ことを特徴とする請求項７に記載の表示制御装置。
9. 前記推定部は、前記投稿履歴を集計して得られた集計結果が所定の条件情報を満たす場合には、前記駅に対して入出規制がかけられていると推定する
   ことを特徴とする請求項７または８に記載の表示制御装置。
10. 前記推定部は、前記集計結果として、前記駅に関する投稿情報の投稿数に基づく情報が、前記所定の条件情報を満たす場合には、当該駅に対して入出規制がかけられていると推定する
    ことを特徴とする請求項９に記載の表示制御装置。
11. 前記推定部は、前記所定の条件情報を満たす場合として、所定の基準値に対して前記集計結果が所定値以上の上昇を示す場合には、前記駅に対して入出規制がかけられていると推定する
    ことを特徴とする請求項１０に記載の表示制御装置。
12. 前記駅に関する所定の情報に基づいて、当該駅での混雑状況の度合いを示す混雑度を算出する算出部をさらに有し、
    前記推定部は、前記算出部により算出された混雑度に基づいて、前記駅に対して入出規制がかけられているか否かを推定する
    ことを特徴とする請求項１～１１のいずれか１つに記載の表示制御装置。
13. 前記算出部は、現在における時刻の経過に応じて当該時刻での前記混雑度を算出し、
    前記推定部は、前記算出部により算出された混雑度に基づいて、前記時刻毎に前記駅に対して入出規制がかけられているか否かを推定する
    ことを特徴とする請求項１２に記載の表示制御装置。
14. 前記算出部は、路線に関する所定の検索サービスにおける検索履歴であって、前記駅に関する検索履歴に基づいて、前記混雑度を算出する
    ことを特徴とする請求項１２または１３に記載の表示制御装置。
15. 前記算出部は、所定の情報共有サービスおける投稿履歴であって、前記駅に関する投稿履歴に基づいて、前記混雑度を算出する
    ことを特徴とする請求項１２～１４のいずれか１つに記載の表示制御装置。
16. 前記表示制御部は、前記駅に関する駅情報として、当該駅の混雑状況または当該駅に対する入出規制の状況を示す状況情報を表示させる
    ことを特徴とする請求項１～１５のいずれか１つに記載の表示制御装置。
17. 前記表示制御部は、路線に関する所定の検索サービスにおける検索結果画面に前記状況情報を表示させる
    ことを特徴とする請求項１６に記載の表示制御装置。
18. 前記表示制御部は、前記駅に関する駅情報として、当該駅での混雑状況の度合いを示す混雑度の変化であって、時間経過に応じた変化を示すグラフを表示させる
    ことを特徴とする請求項１～１７のいずれか１つに記載の表示制御装置。
19. 前記表示制御部は、前記推定部により入出規制がかけられていると推定された場合には、当該入出規制がかけられていると推定された駅に関する駅情報として、当該駅の周辺情報を表示させる
    ことを特徴とする請求項１～１８のいずれか１つに記載の表示制御装置。
20. 前記推定部は、入出規制がかけられていると推定された駅について、当該駅に関する混雑の統計情報に基づいて、混雑の収束時刻をさらに予測し、
    前記表示制御部は、前記駅に関する駅情報として、前記収束時刻を表示させる
    ことを特徴とする請求項１～１７のいずれか１つに記載の表示制御装置。
21. 表示制御装置が実行する表示制御方法であって、
    駅に関する所定の情報に基づいて、当該駅に対して入出規制がかけられているか否かを推定する推定工程と、
    前記推定工程により入出規制がかけられていると推定された場合には、当該入出規制がかけられていると推定された駅に関する駅情報を表示させる表示制御工程と
    を含み、
    前記推定工程では、前記駅に関する所定の情報として、路線に関する所定の検索サービスにおける検索履歴であって、前記駅に関する検索履歴に基づいて、混雑の発生に関係なく、前記駅に対して入出規制がかけられているか否かを推定する
    ことを特徴とする表示制御方法。
22. 駅に関する所定の情報に基づいて、当該駅に対して入出規制がかけられているか否かを推定する推定手順と、
    前記推定手順により入出規制がかけられていると推定された場合には、当該入出規制がかけられていると推定された駅に関する駅情報を表示させる表示制御手順と
    をコンピュータに実行させ、
    前記推定手順では、前記駅に関する所定の情報として、路線に関する所定の検索サービスにおける検索履歴であって、前記駅に関する検索履歴に基づいて、混雑の発生に関係なく、前記駅に対して入出規制がかけられているか否かを推定する
    ことを特徴とする表示制御プログラム。

Images