以下、本発明に係る実施形態について、図面を参照しながら具体的に説明する。なお、各図において同等の機能を有する構成要素には同一の符号を付し、同一符号の構成要素の詳しい説明は繰り返さない。
なお、以下の説明において、出発地とは、経路の出発地であり、また、目的地とは、経路の目的地であり、例えば、経路探索条件に設定された出発地と目的地である。また、経由地とは、経路上の地点のことであり、例えば、経路探索条件に設定された経由地点や、経路情報に含まれる交通機関の乗車場所や乗換場所を含む乗降場のことである。交通機関とは、例えば、公共交通機関のことである。
また、以下の実施形態の例においては、経路の説明として、主に乗り場を駅として列車に乗車する場合について説明するが、本発明は、列車に限られず、バスや船など任意の交通機関に適用可能である。乗り場は、例えば、交通機関がバスの場合は、停留所であり、交通機関が船の場合は、乗船場である。後述の経路は、交通機関が異なる複数の区間が混在したものでもよい。特に注意が無い限り、移動区間には、交通機関以外の徒歩、自転車等による移動も含まれるものとする。
(第1実施形態)
本実施形態に係る情報処理システム1は、例えば、出発地から目的地までの経路情報を探索し、探索された経路情報を出力する、総合探索アプリケーション(第1アプリケーション)を構成するシステムであり、経路内の移動区間に応じて他のアプリケーション(第2アプリケーション)をレコメンドするシステムである。この第2アプリケーションは、第1アプリケーションと連携するアプリケーションであって、当該移動区間について第1アプリケーションよりも利用するメリットが高いアプリケーションである。例えば、第2アプリケーションは、当該移動区間において第1アプリケーションよりも詳細な情報を備えている、あるいは、当該移動区間に対する情報について第1アプリケーションよりも使いやすいユーザインターフェースを有するアプリケーションである。
図1は、本実施形態に係る情報処理システム1の概略的な構成を示す図である。この図1に示すように、情報処理システム1は、端末装置2と、サーバ3とを備えている。端末装置2とサーバ3とは、インターネット等のネットワーク4を介して互いに通信可能に接続されている。ネットワーク4は、有線回線及び無線回線のいずれでもよく、回線の種類や形態は問わない。
端末装置2は、ユーザが使用するものであり、例えば、携帯電話、スマートホン、パソコン、タブレット端末等の情報処理端末である。この端末装置2は、制御部21と、通信部22と、記憶部23と、操作部24と、出力部25とを備えている。なお、端末装置2は、GPS(Global Positioning System)やWi-Fi(登録商標)測位などにより、端末装置2の現在位置を測位する測位手段(図示しない)を備えていてもよい。
ユーザの位置情報等に関する情報をサーバ3へと送信するか否かは、アプリケーションのインストール時や初期設定時にオプトイン又はオプトアウトにより設定するようにしてもよいし、随時環境設定により選択できるようにしてもよい。また、探索ごとに現在位置の送信の可/不可をユーザに選択させるようにしてもよい。当該情報を送信する場合、サーバ3内に当該情報を記憶してもよいか否かについても同様に選択できるようにしてもよい。不可である場合、当該情報の送信又は記憶をしないようにする。このようにすることによりユーザの個人情報を保護することができる一方で、情報を望んでいるユーザにはより適した情報を提供することができる。
制御部21は、経路探索条件を設定する探索条件設定部211と、出力部25において出力するための情報を出力する情報出力部212とを備えている。なお、制御部21の各部は、端末装置2内のプロセッサが所定のプログラムを実行してソフトウェアにより実現されるものであってもよい。
探索条件設定部211は、操作部24を介してユーザが設定した経路探索条件を取得し、経路探索条件を設定する。経路探索条件は、少なくとも出発地と目的地の情報を含む。出発地や目的地は、鉄道の駅には限られず、地点を特定可能な情報、例えば、住所、建物名、郵便番号、電話番号、自宅、会社、バスの停留所、空港、港、乗船場などであってもよい。出発地は、GPSやWi-Fi測位等の測位手段によって検出された現在位置であってもよい。また、経路探索条件には、出発地や目的地の他に経由地、使用路線、出発時刻、到着時刻、始発、終電等の条件が含まれて入れもよい。
なお、探索条件設定部211は、操作部24を介さずに経路探索条件の一部又は全部を取得し、設定してもよい。例えば、ユーザが時刻情報を入力しない場合、出発時刻として、端末装置2が有する時計(図示しない)若しくは外部のサーバから現在時刻を取得するようにしてもよい。また、過去の経路探索履歴に基づいて経路探索条件を取得してもよいし、ユーザが事前に登録したルート(通勤・通学ルート、お気に入りルート等)の情報、あるいはカレンダー等のアプリケーションに登録されたスケジュール情報等に基づいて経路探索条件を取得し、設定するようにしてもよい。
ユーザにより時刻情報が入力されない場合には、上記の例とは別の例として、後述するサーバ3の経路情報取得部311において、サーバ3内の時計の指す時刻を現在の出発時刻として経路探索を行うようにしてもよい。
情報出力部212は、サーバ3から受信した経路情報等を映像信号に変換して出力部25へと出力する。また、サーバ3から受信したデータをユーザが見やすくなるように情報出力部212において生成してもよい。なお、情報出力部212は、情報を音声信号へ変換して出力部25へと出力するようにしてもよい。
通信部22は、ネットワーク4を介して制御部21とサーバ3との間で情報を送受信するためのインターフェースである。記憶部23は、制御部21が動作するためのプログラムや制御部21が取り扱うデータ(ユーザ情報等)を記憶する。操作部24は、ユーザが端末装置2に情報を入力するためのインターフェースであり、例えば、キーボード、マウス、タッチパネル、ボタン、マイク、ダイヤルボタン等である。
出力部25は、端末装置2からユーザへ各種情報を出力するインターフェースであり、例えば、映像を表示する液晶ディスプレイ等の映像表示手段であり、端末装置2からユーザへ様々な情報を出力する。具体的には、出力部25は、ユーザからの操作を受け付けるためのGUI(Graphical User Interface)や、後述する経路情報などを表示する。あるいは、出力部25は、探索された経路情報や新着情報等を音声で出力するスピーカであってもよいし、新着情報がある場合に振動するバイブレータであってもよい。また、操作部24がタッチパネルの場合には、操作部24が出力部25を兼ねていてもよい。
なお、出力部25は、ユーザに情報を直接提示するものでなくてもよい。例えば、出力部25は、端末装置2の外部に接続される映像表示手段や音声出力手段に、映像信号や音声信号を出力するものであってもよいし、外部に接続される印刷装置にデータを出力するものであってもよいし、端末装置2内若しくは外部の記憶装置にデータを出力して記憶させるものであってもよい。
次に、サーバ3について説明する。サーバ3は、制御部31と、記憶部32と、ネットワーク4を介して外部と情報を送受信するインターフェースである通信部33とを備えている。
制御部31は、経路情報取得部311と、ニーズ要素抽出部312と、アプリ特定部313とを備えている。なお、これらの各部の機能は、サーバ3内のプロセッサが所定のプログラムを実行してソフトウェアにより実現されるものであってもよい。
経路情報取得部311は、ネットワーク4を介して端末装置2から送信された経路探索条件と、記憶部32内の経路情報データベース321に記憶されているデータとに基づいて経路探索を行った経路探索結果を経路情報として取得する。なお、経路探索は、図示しない経路情報探索部により実行されてもよいし、経路情報取得部311が経路探索条件に基づいて経路情報の探索を実行してもよい。以下の説明においては、特に明記しない限り、経路情報取得部311が経路情報の探索を実行するものとするが、この限りではない。
この経路情報取得部311により取得された経路情報は、出発地、目的地等の地点情報と、各地点情報同士の間の移動区間の情報を経路要素として備える。なお、経路情報には、経由地(乗り換え駅等を含む)の情報を含んでいてもよい。
ニーズ要素抽出部312は、経路情報取得部311が取得した経路要素を備える経路情報に基づいて、ユーザの潜在的なニーズ(潜在ニーズ)と、当該潜在ニーズを推定可能な経路要素である潜在ニーズ要素を抽出する。すなわち、ニーズ要素抽出部312は、ユーザの潜在的なニーズが存在すると推定される経路情報中の地点又は移動区間の情報を潜在ニーズ要素として抽出する。
アプリ特定部313は、第1アプリケーションと連携するアプリケーションであって、ニーズ要素抽出部312が抽出した潜在ニーズに対応する第2アプリケーションを、記憶部32内の連携アプリ情報データベース322から特定する。そして、特定された第2アプリケーションを通信部33及びネットワーク4を介して端末装置2へと出力する。
記憶部32は、各種データを記憶するデータベースであり、経路情報データベース321と、連携アプリ情報データベース322とを備える。記憶部32は、例えば、ハードディスク、不揮発性半導体メモリ(SSD等)等の任意の記憶装置により構成可能である。また、記憶部32は、図面においてサーバ3内にあるものとしているが、制御部31とは別のデータベースサーバや、ファイルサーバとして独立したサーバとして情報処理システム1内に通信可能に接続された別の装置内に備えられているものであってもよい。
経路情報データベース321は、公共交通機関の経路情報の探索、及び、徒歩、自転車等の道路情報に関わる経路情報の探索を実行する際に使用するデータベースである。この経路情報データベース321は、経路ネットワーク情報データベースを少なくとも備え、さらに、時刻表情報データベースと、地図データベースと、POI(Point of Interest)情報データベースのうち少なくとも1つをさらに備えていてもよい。例えば、第1アプリケーションが、総合的な経路探索を行うアプリケーションである場合、上述した全てのデータベースを備えていてもよい。
経路ネットワーク情報データベースは、経路探索に使用するデータベースであり、道路ネットワーク情報データベースと、交通ネットワーク情報データベースとを備える。道路ネットワーク情報は、道路のネットワーク情報であり、徒歩、自転車、バイク、自動車等といった移動手段ごとに別のデータとして記憶されていてもよい。交通ネットワーク情報は、公共交通機関のネットワーク情報であり、列車、バス、飛行機等といった移動手段ごとに記憶されている。
時刻表情報データベースは、時刻表を考慮した経路探索をする場合に利用されるデータベースであり、公共交通機関の移動手段ごとに記憶された時刻表情報のデータベースである。地図データベースは、地図情報を記憶するデータベースであり、主に表示や、移動経路探索といった地点探索に用いられるデータベースである。POIデータベースは、フリーワード探索やカテゴリ探索といった地点探索用に用いられるデータベースである。
これらのデータベースに記憶されている情報は、所定のタイミングでアップデートするようにしてもよい。
時刻を指定せずに経路探索をする平均探索のみを行う場合には時刻表情報データベースは備えられなくてもよいが、出発時刻や到達時刻といった時刻を指定した通常の探索をする場合には、時刻表情報データベースが備えられる。また、駅間のみの経路探索を行う場合には、地図データベースやPOIデータベースは備えられなくてもよいが、上述したように、住所、建物名等から探索を行う場合には、地図データベースやPOIデータベースが備えられる。これらのデータベースは図示しないが、適宜必要となる場合には、備えられる。
連携アプリ情報データベース322は、第1アプリケーションと連携しているアプリケーションの情報を記憶するデータベースである。例えば、第1アプリケーションが経路探索を行う総合探索アプリケーションである場合、連携するアプリケーションは、例えば、列車の時刻表、バスの時刻表、徒歩、自転車、バイク、自動車等の移動手段に関する情報に特化したアプリケーションや、観光地、口コミ情報等の地点又は地域に関する情報に特化したアプリケーションである。
アプリ特定部313は、ニーズ要素抽出部312により抽出された潜在ニーズ情報要素における第2アプリケーションの情報を、この連携アプリ情報データベース322に記憶された潜在ニーズに紐付けられているアプリケーションの情報を取得することにより特定する。
この連携アプリ情報データベース322には、これらの連携アプリケーションの情報と潜在ニーズとが紐付けられて記憶されている。すなわち、潜在ニーズに対応する第2アプリケーションの情報が、連携アプリ情報データベース322に記憶されている。例えば、第1アプリケーションにおいてバスの時刻表を望んだユーザの潜在ニーズは、バス、あるいは、バスの時刻表に関する情報である。この潜在ニーズに対応する第2アプリケーションの情報としてバスの時刻表に関するアプリケーションの情報が連携アプリ情報データベース322を参照することにより特定することが可能となる。
潜在ニーズと第2アプリケーションの情報との紐付け例としては、他に以下のような例が挙げられる。なお、以下に挙げる例は一例であり、この他にも紐付け関係があってもよい。また、ユーザのニーズ及びニーズ要素は、潜在的なものに限られず、以下のそれぞれに対してユーザの操作により顕在化したものであってもよい。
長時間の徒歩移動を避けたいというニーズに対しては、自転車に特化したアプリケーションが紐付けられ、歩くのであればポイントをためたいというニーズに対しては、ウォーキングに特化したアプリケーションが紐付けられる。旅行をしたいというニーズに対しては、観光案内アプリケーションが紐付けられる。重い荷物を持って歩きたくないというニーズに対しては、バス情報に特化したアプリケーション又はタクシー情報に特化したアプリケーションが紐付けられる。雨に濡れたくない、寒いのが苦手、汗をかきたくないというニーズに対しては、バス情報に特化したアプリケーションや、地域の地下道の情報に特化したアプリケーションが紐付けされる。健康に興味があるというニーズに対しては、ウォーキングに特化したアプリケーションが紐付けられる。
さらに、これらのニーズは、経路の地点又は移動区間のみの情報から推定されるだけではなく、これらの情報に加え、ユーザの過去又は現在の端末装置2の操作情報によって推定されるものであってもよい。前段落の例で言うと、徒歩区間が長い場合、長時間歩きたくない、又は、歩くのであればポイントをためたいという潜在ニーズが推定される。人気の旅行POIを選択した場合、旅行をしたいという潜在的又は顕在的なニーズが推定される。日用品や大型製品を販売する店舗に関するPOIを探索した場合、重い荷物を持って歩きたくないという潜在ニーズが推定される。天候が、雨、寒い、暑い等であって経路に徒歩区間がある場合には、雨に濡れたくない等の潜在ニーズが推定される。マッサージ店やスーパー銭湯をよく探索している場合には、健康に興味があるという潜在ニーズが推定される。
次に、本実施形態に係る情報処理システムの動作について説明する。図2は、本実施形態に係る情報処理システムの処理の流れを示すフローチャートである。以下、各実施形態又は変形例の説明においては、上記のニーズ及びニーズ要素は、ユーザの潜在的なニーズであるとして、潜在ニーズ及び潜在ニーズ要素として説明するが、ユーザの操作により顕在化されたニーズであってもよい。この場合、ニーズ及びニーズ要素は、ユーザの顕在的なニーズ及びニーズ要素である。
まず、探索条件設定部211は、ユーザが操作部24を介して入力した経路探索条件を取得し、通信部22を介してサーバ3へと送信する(ステップS10)。
次に、通信部33を介して経路探索条件を受信した経路情報取得部311は、経路探索条件にしたがい経路の探索を行い、探索された複数の経路情報をリストにして通信部33を介して端末装置2へと送信する(ステップS20)。経路情報取得部311は、経路探索条件に基づき、経路情報データベース321に備えられている各種データベースを用いて経路探索を行う。
この経路探索は、経路探索条件にしたがい、複数の候補経路を探索する。候補経路としては、例えば、目的地への到達時刻が早い経路、目的地までの運賃が安い経路、乗換回数が少ない経路、又は、目的地までの移動手段の混雑度が空いている経路等により探索される。経路情報取得部311は、これらの経路をリストにして端末装置2へと送信する。また、かならずしも複数の経路である必要は無く、ユーザの入力した条件、例えば、一番到達時刻が早い経路等により1つの経路だけを送信するようにしてもよい。この場合、1経路だけのリストを送信するようにしてもよいし、次のステップS11を省略して、詳細情報を送信するようにしてもよい。
次に、通信部22を介して経路探索結果のリストを受信した端末装置2の情報出力部212は、当該探索結果のリストを出力部25へと出力する。操作部24を介してユーザによりリスト内の1経路の詳細情報を取得する旨の要求があると、通信部22を介して当該要求がサーバ3へと送信される(ステップS11)。
次に、詳細情報を取得する旨の要求を受信したサーバ3の経路情報取得部311は、経路の詳細情報を端末装置2へと送信する(ステップS21)。経路の詳細情報は、ステップS20において探索され、取得されているものであってもよいし、ステップS21において探索され、取得されるものであってもよい。
次に、経路の詳細情報を受信した端末装置2の情報出力部212は、出力部25へ経路の詳細情報を出力する(ステップS12)。図3(a)は、経路の詳細情報を出力部25へと表示した一例を示す図である。この例において、ユーザは、○○三丁目バス停留所から、□□駅までの経路を探索している。
詳細表示においては、地点情報2500、2502、2504、2506と、移動区間情報2501、2503、2505が交互に配置されている。例えば、地点情報2500は、○○三丁目から☆☆バスの○×ルートのバスに乗車することを示す。☆☆バスに乗車すると、移動区間情報2501に示されるように、経由地である地点情報2502に示される○○神宮までには5個の停留所が存在し、乗車賃は100円であり、乗車時間が10分であることが示される。
以下同様に、地点情報2504には経由地が○×駅、地点情報2506には目的地が□□駅であることが示され、地点情報2502、2504の間の移動区間情報2503が徒歩であり、地点情報2504、2506の間の移動区間情報2505が△△線(列車)であることが示されている。
次に、経路の詳細情報からユーザが操作部24を介して移動区間の詳細状況を要求すると、当該要求はサーバ3へと送信される(ステップS13)。例えば、図3(a)の移動区間情報2501内の右端にある時計マークは、当該移動区間における時刻表を表示するための時刻表表示ボタン2507であり、この時刻表表示ボタン2507を選択することにより当該要求がサーバ3へと送信される。なお、ここで言う選択とは、例えば、タップ、タッチ、クリック、ダブルクリック、スワイプ、音声入力による判断等、操作部24を介して行いうる操作のことである。
次に、移動区間の詳細情報の要求を受信したサーバ3のニーズ要素抽出部312は、当該移動区間の詳細情報を探索し、取得する(ステップS22)。例えば、図3(a)における移動区間情報2501の移動手段がバスであるので、時刻表表示ボタン2507が選択されると、バスの時刻表の表示をユーザが望んでいることとなる。この場合、経路情報取得部311は、経路情報データベース321内の時刻表情報データベースからユーザが望んでいるバスの時刻表を探索し、取得する。
次に、ニーズ要素抽出部312は、当該移動区間に潜在ニーズがあるか否かを判断し、潜在ニーズがある場合には、当該潜在ニーズを抽出し、併せて当該移動区間を潜在ニーズ要素であると抽出する(ステップS23)。
次に、アプリ特定部313は、抽出された潜在ニーズに対応した連携アプリケーションの情報を、連携アプリ情報データベース322に記憶されているアプリケーションの情報から特定する(ステップS24)。このアプリ特定部313により特定されたアプリケーションが第1アプリケーションと連携するアプリケーションであって、かつ、潜在ニーズに対応する、第2アプリケーションとなる。
次に、制御部31は、取得した移動区間の詳細情報及び第2アプリケーションの情報を端末装置2へと送信する(ステップS25)。なお、ユーザが指定した移動区間が潜在ニーズ要素では無い場合、ステップS24を省略して移動区間の詳細情報を端末装置2へと送信するようにしてもよい。
次に、端末装置2の情報出力部212は、サーバ3から受信した移動区間の詳細情報及び第2アプリケーションの情報を出力部25へと出力する(ステップS15)。図3(b)は、図3(a)において移動区間情報2501内のバスの時刻表表示ボタン2507をユーザが選択した場合に出力部25に出力される表示の一例を示す図である。
この図3(b)に示すように、バスで移動する移動区間に対して、当該バスの時刻表情報が、時刻表表示情報2508のように表示される。この例においては、出発時間である12時27分以降のバスの簡易な時刻表情報が表示される。例えば、12時27分以降である、12時28分、12時43分、12時58分、13時13分、13時28分のバスが直近にあるという情報をユーザは取得することが可能となる。
このようなバスの移動区間について、時刻表表示を行うユーザは、一時的にバスの時刻表を閲覧するのみならず、潜在的にバスの時刻表を表示するアプリケーションを望んでいることもある。このようなユーザの潜在ニーズに対応するために、簡易な時刻表表示と併せて、第2アプリケーションの情報を、連携アプリ情報2509のように表示する。このようにすることにより、潜在ニーズに応えるアプリケーションを適切にレコメンドすることが可能となる。
この連携アプリ情報2509を選択することにより、ユーザの端末装置2へと第2アプリケーションをインストールする画面へと遷移する。ユーザは、ユーザ自身の意思により、第2アプリケーションをインストールするか否かを選択することができる。
レコメンドされた第2アプリケーションが既に端末装置2にインストールされている場合には、連携アプリ情報2509を選択することにより、第2アプリケーションを起動するようにしてもよい。このようにすることにより、ユーザは、端末装置2にインストールされている第2アプリケーションを第1アプリケーションの表示画面上から起動することができ、利便性が向上する。
また、潜在ニーズを推定する際に、ユーザの第1アプリケーションの利用ログを用いることもできる。例えば、当該ユーザが過去の経路探索において、経路の詳細情報についてのバスの時刻表に係る詳細情報を表示しようとしていた場合、当該ユーザについては、バスの時刻表情報が潜在ニーズであると推定する。そして、経路中の複数の移動区間のうち、移動手段がバスである移動区間が存在する場合に、当該移動区間を潜在ニーズ要素として抽出するようにしてもよい。この潜在ニーズの推定は、所定の回数(例えば2回)以上バスの時刻表情報を表示させたこと等を条件として推定するようにしてもよい。
なお、当該移動区間が潜在ニーズ要素では無い場合には、当該移動区間の詳細情報を表示し、連携アプリケーションの情報を表示しないようにする。このようにすることにより、出力部25の表示領域により多くの詳細情報を表示することが可能となる。また、過度なレコメンド表示を抑制することもでき、ユーザの満足度の向上を図ることができる。
以上のように、本実施形態によれば、ユーザが第1アプリケーションを利用して経路探索を実行し、移動経路の詳細情報を出力するためのユーザによる入力操作に基づいてニーズ要素を抽出する場合、すなわち、経路情報においてユーザが詳細情報を表示しようとした移動区間にユーザの潜在的又は顕在的にニーズがある場合、当該ニーズに適した第1アプリケーションと連携しているアプリケーションである第2アプリケーションをレコメンドすることが可能となる。
このようにレコメンドすることにより、ユーザのニーズにより適合したアプリケーションをレコメンドし、利便性を向上するとともに、事業者は、連携するアプリケーションにユーザをより適切に誘導することが可能となる。例えば、連携アプリケーション同士の場合、GUI等のユーザインターフェースが共通する場合が多く、レコメンドされたアプリケーションを使用する場合においてもユーザに過度の負担を生じさせず、必要な情報へとアクセスする手段を提供することが可能となる。さらに、第1アプリケーションにおいて記録したユーザ設定情報等やアプリケーションの設定情報等を同じ設定情報として第2アプリケーションへと自動的に設定することも可能となる。
(第2実施形態)
前述した第1実施形態においては、経路情報における移動区間を選択したタイミングでユーザのニーズ及びニーズ要素を抽出するようにしたが、これらの情報の抽出は、上記のタイミングには限られない。本実施形態においては、第1実施形態とは異なるタイミングでユーザのニーズ及びニーズ要素を抽出する例について説明する。
図4は、本実施形態における情報処理システム1の処理の流れを示すフローチャートである。全体的な処理の流れとしては、探索された複数の経路情報のリストからユーザが経路詳細を要求したタイミングにおいて、当該経路内のニーズ要素及び当該ニーズ要素におけるユーザのニーズを抽出する。以下、より詳しく説明する。
ユーザにより入力された経路探索条件を取得するステップ(ステップS10)からリスト化された経路情報から経路詳細の要求をするステップ(ステップS11)までは、上述した第1実施形態と同様である。
経路詳細の要求があった後、サーバ3のニーズ要素抽出部312は、潜在ニーズ要素の抽出を行う(ステップS23)。潜在ニーズ要素の抽出は、経路の要素である複数の移動区間又は複数の地点の情報から潜在ニーズが推定される要素を抽出することにより行われる。例えば、経路詳細が図3(a)に示されるものである場合、移動区間情報2501、2503、2505、又は、地点情報2500、2502、2504、2506のうち、潜在ニーズが推定される要素を抽出する。ここで、抽出する要素は1つであるとは限られず、複数の要素が抽出されてもよい。
ニーズ要素抽出部312は、各移動区間及び地点について潜在ニーズが存在するか否かを推定し、潜在ニーズがある要素を潜在ニーズ要素として抽出する。例えば、移動区間情報2501における移動手段はバスであるので、ニーズ要素抽出部312は、この区間の潜在ニーズがバスに関するものであると推定し、この移動区間を潜在ニーズ要素として抽出する。さらに、上記と併せて移動区間情報2503における潜在ニーズが徒歩に関するものであると推定し、この移動区間を潜在ニーズ要素として抽出してもよい。同じように、移動区間情報2505における潜在ニーズを電車に関するものであると推定し、この移動区間を潜在ニーズ要素として抽出してもよい。
このように、ニーズ要素抽出部312は、経路詳細の要求がされたタイミングにおいて経路を構成する各要素について潜在ニーズの推定を試み、潜在ニーズが推定可能である経路を構成する要素を潜在ニーズ要素として抽出する。なお、地点に関しても同様に潜在ニーズ要素として抽出することもできる。地点を抽出する具体例については後述する。
次に、抽出された各要素の潜在ニーズに基づいて、連携アプリ情報データベース322から第2アプリケーションの情報を特定する(ステップS24)。特定された第2アプリケーションの情報は、各潜在ニーズ要素と紐付けられている。続いて、探索された経路詳細と、抽出された潜在ニーズ要素及び各潜在ニーズ要素と紐付けられた第2アプリケーションの情報を端末装置2へと送信する(ステップS26)。なお、経路の詳細情報は、前述した第1実施形態と同様に、ステップS20において探索しておいてもよいし、ステップS23において、経路の詳細表示の要求を受信した後に(図示しないステップにおいて)探索するようにしてもよい。
次に、端末装置2の情報出力部212は、出力部25へと経路の詳細情報を出力する(ステップS12)。ユーザから移動区間の詳細情報の要求があった場合、探索条件設定部211は、サーバ3へと当該要求を送信する(ステップS13)。
次に、当該要求を受信した経路情報取得部311は、要求された移動区間の詳細情報を取得する(ステップS22)。そして、取得した詳細情報とともに、詳細情報を要求された移動区間が潜在ニーズ要素であった場合には、ステップS24で特定した当該潜在ニーズ要素に対応する第2アプリケーションの情報を端末装置2へと送信する(ステップS25)。
第2実施形態によれば、ユーザから移動区間の詳細情報の要求があった場合に、より迅速に第2アプリケーションの情報を出力部25へと出力することが可能となる。また、端末装置2とサーバ3との間の通信回数を減少させることも可能となる。さらに、第2実施形態によれば、経路の詳細表示へも第2アプリケーションをレコメンドすることが可能となる。例えば、図6では、経路情報のリストから経路情報を参照するタイミングにおいて、経路の詳細表示に第2アプリケーションがレコメンドされている。
(第3実施形態)
前述した第2実施形態においては、探索経路のリスト表示をするタイミングにおいて既に潜在ニーズ、潜在ニーズ要素の抽出、及び、第2アプリケーションの特定をしている例を説明したが、本実施形態はさらに端末装置2とサーバ3との間の通信回数を減らそうとするものである。
図5は、本実施形態に係る情報処理システム1の処理の流れを示すフローチャートである。本実施形態に係る情報処理システム1においては、端末装置2からサーバ3への経路探索条件の送信が行われた後に、探索経路のリストの作成、経路の詳細情報の取得、潜在ニーズの推定及び潜在ニーズ要素の抽出、並びに、第2アプリケーションの特定をサーバ3で行い、これらの探索、抽出、及び、特定した情報を端末装置2へと送信するものである。
まず、探索条件設定部211は、操作部24を介してユーザにより入力された経路探索条件を取得し、通信部22を介してサーバ3へと送信する(ステップS10)。
次に、探索条件を受信した経路情報取得部311は、経路探索条件にしたがい経路の探索を実行し、探索された経路を取得する(ステップS27)。この際、複数の経路探索結果がある場合には、これらの探索結果を簡易に表示するリスト化を行う。
次に、経路情報取得部311は、各経路の詳細情報を取得する(ステップS22)。続いて、ニーズ要素抽出部312は、探索された各経路の詳細情報に基づき、潜在ニーズが推定可能である潜在ニーズ要素を抽出する(ステップS23)。そして、アプリ特定部313は、第2アプリケーションを特定する(ステップS24)。
次に、このようにして探索、抽出、及び、特定された各情報を端末装置2へと送信する(ステップS28)。
各情報を受信した端末装置2の情報出力部212は、出力部25へと各情報を出力する(ステップS16)。例えば、最初に探索結果である複数の経路のリストを出力部25へと出力する。そして、ユーザの選択により、経路の詳細情報を出力したり、移動区間の詳細情報を出力したりする。選択した移動区間が潜在ニーズ要素である場合、移動区間の詳細情報を出力するタイミングで、上述した実施形態と同様に第2アプリケーションのレコメンド情報を併せて出力する。
このようにすることにより、端末装置2とサーバ3との間の通信回数を少なくすることが可能となり、ユーザが複数の経路の詳細情報を比較して閲覧しようとしている場合に、その度に通信を行うことなく詳細情報を閲覧することが可能となる。さらに、移動区間の詳細情報が選択され、当該移動区間が潜在ニーズ要素であった場合にも、サーバ3との通信を行うことなく第2アプリケーションをレコメンドすることが可能となる。
以下、いくつかの変形例を挙げ、それぞれについて詳しく説明する。なお、本発明の実施形態の具体例は、上述した実施形態及び下記に記載する変形例により限定されるものではない。
(第1変形例)
前述した実施形態についての説明においては、潜在ニーズ要素がバスの移動区間であり、潜在ニーズもバスに関するものであったが、この潜在ニーズ要素の移動手段と、潜在ニーズとは必ずしも一致するものではない。以下、潜在ニーズ要素の移動手段と、潜在ニーズとが一致しない例について説明する。
図6(a)及び図6(b)は、本変形例における経路の詳細表示の一部を示す図である。図6(a)は、比較例として、第2アプリケーションのレコメンドが無い場合を示す図である。この図6(a)に示すように、地点情報2510、2512、及び、移動区間情報2511を備えている。なお、これらの図は、表示画面の一部を切り取ったものであるので、駅に到着後に列車の経路情報が続いて示されていてもよい。
地点情報2510は、自宅の地点情報であり、例えば、第1アプリケーションにおいて登録してあるユーザの自宅の情報である。地点情報2512は、例えば、自宅の最寄り駅である○×駅の地点情報である。これらの地点情報2510、2512の間にある移動区間が移動区間情報2511で示される徒歩区間である。この徒歩区間の距離が1.4kmであり、標準的速度で歩いた場合に20分掛かることが移動区間情報2511に示されている。
図6(b)は、このような距離の徒歩区間がある場合に、自転車に特化した情報を備える第2アプリケーションをレコメンドするものである。この図6(b)に示すように、経路の詳細情報の移動区間情報2511内に、連携アプリ情報2513として表示される。上述した実施形態と異なるのは、移動区間の詳細情報を選択したタイミングではなく、経路の詳細情報の表示とともに第2アプリケーションの情報が表示される点である。
ここで表示されている連携アプリ情報2513は、例えば、自転車のルート探索をするためのアプリケーションである。この自転車のルート探索をするアプリケーションは、徒歩経路とは異なり、自転車で通行するのに適した経路を出力するアプリケーションである。
このように、移動区間に係る移動手段とは異なる移動手段に対応する第2アプリケーションをレコメンドすることも可能である。上記のように、徒歩区間が比較的長い場合、自転車の経路探索を行うアプリケーションをレコメンドすることもできる。ここで言う徒歩区間が比較的長いとは、例えば、徒歩距離が所定距離(例えば1km)を超える距離であり、又は、徒歩時間が所定時間(例えば15分)を超えるような距離である。なお、この1kmや15分の数値は例としてあげたものであり、本変形例の及ぶ範囲は、この数値に限られるものではない。
さらに、この数値は、ユーザの属性によって変化するものであってもよい。例えば、30代以下の男女の場合には、所定距離や所定時間を長めにしてもよい。一方で、50代以上の男女の場合には、所定距離や所定時間を短めにしてもよい。このユーザの属性は、例えば第1アプリケーションにおいて、ユーザが任意で登録できる情報であってもよい。
ユーザの過去の経路探索条件やインストール情報等の第1アプリケーション、又は、それに関連するログがあるような場合、さらにこのログの情報を参照することも可能である。例えば、上記では、自転車専用のアプリケーションをレコメンドするようにしたが、ユーザがバイクに乗ることが記録されている場合、バイク専用のアプリケーションをレコメンドするようにしてもよい。別の例としては、ユーザに健康志向がある場合に、徒歩専用、例えば、歩くことによりポイントがたまり、たまったポイントでサービスを受けられるようなアプリケーションをレコメンドするようにしてもよい。
上記のユーザの属性を、レコメンドする第2アプリケーションの種別に反映するようにしてもよい。例えば、上記の例において、20代の男女には、徒歩専用のアプリケーションをレコメンドし、60代の男女には、自転車専用のアプリケーションをレコメンドするようにしてもよい。また、別の例として、ニーズ要素抽出部312は、30代以下の男女に対してはこのような徒歩区間を潜在ニーズ要素として抽出しないようにしてもよい。
さらに別の例として、探索をしたタイミングにおける天候等の情報により潜在ニーズ要素の抽出や、第2アプリケーションのレコメンド内容を変化させるようにしてもよい。例えば、上記のように徒歩区間に対して連携アプリケーションをレコメンドする場合、晴れているときには上記のように自転車やバイクの情報に特化したアプリケーションをレコメンドする一方で、雨が降っている場合には、バスの情報に特化したアプリケーションをレコメンドするようにしてもよい。
さらに別の例として、探索を実行したタイミングにおける交通情報により潜在ニーズ要素の抽出や、第2アプリケーションのレコメンド内容を変化させるようにしてもよい。例えば、移動区間の移動手段が列車であって、当該列車が遅延しているという情報がある場合、当該移動区間に関する潜在ニーズを列車以外の移動手段であるとし、当該移動区間を潜在ニーズ要素として抽出するようにしてもよい。このように交通情報に応じて、別の移動手段に関連するアプリケーションを第2アプリケーションとしてレコメンドすることもできる。
交通情報は、上記のように列車の運行情報の他、一般道又は高速道における、運行又は通行止め情報、道路の混雑情報、道路を用いたイベント情報(例えばマラソン大会、デモ行進等)等であってもよい。この場合、移動手段の代替手段としては、例えば、列車、バス、タクシー、自動車、バイク、自転車、徒歩等が考えられ、これらの移動手段間において相互に第2アプリケーションとしてレコメンドするようにしてもよい。
また、上記のように交通情報に何らかの変化がある場合、このような交通情報に特化したアプリケーションを第2アプリケーションとしてレコメンドするようにしてもよい。例えば、ある移動区間の移動手段が自動車であるような場合において、当該移動区間に関する潜在ニーズを自動車の交通情報と推定し、当該移動区間を潜在ニーズ要素として抽出してもよい。
すなわち、第2アプリケーションは、必ずしも上述しているようにナビゲーション情報に特化したアプリケーションである必要は無く、交通情報に特化したアプリケーションであってもよい。例えば、第2アプリケーションは、移動手段が自動車やバイクである場合には、道路の交通情報、混雑情報に特化したアプリケーションであってもよく、移動手段が列車である場合には、列車の混雑情報に特化したアプリケーションであってもよい。
以上のように、移動区間に係る移動手段と異なる移動手段のナビゲーション等の情報に特化した第2アプリケーション、又は、移動区間に係る移動手段のナビゲーション情報とは異なる情報に特化した第2アプリケーションをレコメンドすることにより、ユーザの利便性を向上させることができる。これとともに、事業者は、関連するアプリケーションへとユーザをスムーズに誘導することが可能となる。
(第2変形例)
前述した実施形態及び変形例においては、移動区間に対する第2アプリケーションをレコメンドするものであったが、第2アプリケーションをレコメンドする要素は、移動区間には限られない。本変形例においては、移動区間ではない要素について第2アプリケーションをレコメンドする例を説明する。
図7(a)及び図7(b)は、経路の詳細情報における地点を潜在ニーズ要素とする一例を示す図である。これらの図では、東京都内から京都までの経路探索を実行した場合の経路詳細の一部が示されている。
図7(a)に示す比較例においては、経路の詳細情報には、地点情報2520、2522と、移動区間情報2521が備えられている。地点情報2520では品川駅での乗り換え、地点情報2522では京都駅への到着、そして、その間の移動区間情報2521は、新幹線での移動が示されている。
本変形例において、ニーズ要素抽出部312は、「京都」という地点を潜在ニーズとして推定し、地点情報2522を潜在ニーズ要素として抽出する。潜在ニーズは、例えば、地域の属性や地点又は地域の人気度により推定される。また、連携アプリケーション中に、当該地点又は地域の情報に特化したアプリケーションが存在するか否かを考慮してもよい。そして、アプリ特定部313は、この「京都」という地点情報又は地域情報に特化した情報を備える第2アプリケーションを特定する。
地域の属性とは、例えば、観光地、繁華街、神社仏閣が多い、ショッピングできる、公園、山、海、景色がよい、スポーツできる、等の属性を示す情報である。地点又は地域の人気度とは、一般的な人気度でもよいし、第1アプリケーションにおける探索回数によるものでもよいし、アンケート等その他の情報から割り出された人気度でもよい。
図7(b)は、当該経路における第2アプリケーションのレコメンドをしている一例を示す図である。この図7(b)に示すように、アプリ特定部313は、例えば、京都版観光案内アプリケーションをレコメンドする。さらには、代表的な観光地の画像を併せて表示してもよい。この代表的な観光地の画像は、複数枚用意しておき、ユーザの属性により変化させるようにしてもよい。観光地の画像は、動画等であってもよい。
以上のように、本変形例によれば、探索結果における地点又は地域の情報に基づいて潜在ニーズを推定し、これらの地点又は地域を潜在ニーズ要素として抽出することにより、ユーザに探索した出発地、目的地又は経由地の地点又は地域に特化した情報を備える連携アプリケーションをレコメンドすることができる。
(第3変形例)
前述した各実施形態及び各変形例においては、潜在ニーズと潜在ニーズ要素は、経路詳細情報中に複数ある地点情報及び移動区間情報のうち1の地点情報又は移動区間情報により推定され抽出されるものであったが、これには限られない。すなわち、複数の地点情報又は移動区間情報により潜在ニーズを推定し、1の潜在ニーズ要素を抽出するものであってもよい。
図8(a)及び図8(b)は、本変形例におけるレコメンドの一例を示す図である。これらの図では、○○デパートを出発地とし、自宅を目的地とした経路探索情報を示すものである。
図8(a)に示す比較例においては、経路の詳細情報には、地点情報2530、2532、2534、2536と、移動区間情報2531、2533、2535が備えられている。地点情報2530は○○デパート、地点情報2532は○○駅、地点情報2534は△△駅、地点情報2536は自宅であり、それぞれの地点の間に、徒歩の移動区間情報2531、列車を利用した移動区間情報2533、徒歩の移動区間情報2535が存在する。
ニーズ要素抽出部312は、まず、地点情報2530の情報から、○○デパートにおいてユーザが買い物したことを推定する。そして、移動区間情報2535における徒歩距離が1.4kmと比較的長いことから、買い物をした荷物を持って長距離を移動するのがユーザにとって楽では無いと推定する。
そこで、図8(b)に示すように、移動区間情報2535について、荷物を持っているユーザが長距離歩くことを無くすように、バスの情報に特化した第2アプリケーションをレコメンドする。このように、1つの地点又は移動区間の情報から1つの潜在ニーズを推定し、潜在ニーズ要素を抽出するのではなく、複数の地点又は移動区間の情報から1つの潜在ニーズを推定し、潜在ニーズ要素を抽出するようにしてもよい。
なお、本変形例においては、前述した第1変形例と比較して、徒歩での移動距離が短い場合にも第2アプリケーションをレコメンドするようにしてもよい。また、第2アプリケーションは、バスに関する情報に特化したものに限られず、例えば、タクシー情報に特化したアプリケーションであってもよい。
(第4変形例)
ユーザが経路探索を行った場合であって、探索された経路の詳細情報における移動区間の移動手段と異なる移動手段により移動していることが検知可能である場合にも、第2アプリケーションをレコメンドすることができる。ユーザの移動手段は、端末装置2に備えられているセンサ(図示しない)等により検知するようにしてもよい。この場合、センサ情報を第1アプリケーションで利用することについてあらかじめユーザに許可をもらうようにしておいてもよい。
例えば、探索結果において経路中のある移動区間が徒歩であったが、当該移動区間についてユーザが自転車で移動していることが所持している端末装置2により検知された場合、当該移動区間について自転車の情報に特化した第2アプリケーションをレコメンドする。すなわち、探索された経路において予定されていた移動手段と異なる移動手段によりユーザが移動していた場合、この探索結果の移動手段と実際の移動手段との差異に基づいて、アプリ特定部313は、第2アプリケーションを特定するようにしてもよい。
このようにすることにより、ユーザの実際の動向により適した第2アプリケーションをレコメンドすることが可能となり、よりユーザの利便性を向上することが可能となる。
以上、前述した各実施形態及び各変形例において説明したように、ニーズ要素抽出部312は、経路探索条件、天候、交通情報、地点の属性、地点の人気度、地点に対する情報の有無、移動区間の距離、第1アプリケーションの利用ログ、及び、ユーザの属性のうち少なくとも1つの情報に基づいて潜在ニーズを推定し、当該潜在ニーズが存在する移動区間又は地点を潜在ニーズ要素として抽出する。
アプリ特定部313は、潜在ニーズ要素として抽出された移動区間又は地点に関するナビゲーション情報、交通情報、混雑情報、地点若しくは地域の情報、及び、代替となる移動手段の情報の少なくとも1つに基づいてこれらの情報に特化した、すなわち、これらの情報について第1アプリケーションよりも詳しい情報又はこれらの情報について第1アプリケーションより利便性の高いインターフェース等を提供するアプリケーションを第2アプリケーションとして特定する。
前述した各実施形態において、第2アプリケーションのレコメンドは、前述した各実施形態のようにユーザが経路探索を行ったタイミングでレコメンドしてもよいし、又は、別のタイミングであってもよい。別のタイミングとは、例えば、移動中や、経路の経由地あるいは目的地到達後であってもよい。
例えば、ユーザがある移動区間を移動しているタイミングにおいて、当該移動区間より後の地点又は移動区間に対する第2アプリケーションのレコメンドをしてもよい。このようにすることにより、当該移動区間においてユーザはそれより後の地点又は移動区間に対する情報に特化した第2アプリケーションへとアクセスすることが可能となる。
また、ユーザがある移動区間を移動しているタイミングにおいて、当該移動区間や当該移動区間よりも前の地点又は移動区間に対する第2アプリケーションのレコメンドをしてもよい。このようにすることにより、将来的にユーザが同じ経路を利用する場合に、ユーザの利便性を向上させることに繋がる。
別の例として、第2アプリケーションのレコメンドをするタイミングは、経路中の地点に到達後であってもよい。経路における当該地点よりも後の地点若しくは移動区間、又は、当該地点に対する第2アプリケーションをレコメンドすることにより、ユーザにタイミングよく情報を提供することが可能となる。上述したものと同様に、当該地点よりも前の地点又は移動区間に対する第2アプリケーションであってもよい。さらに、目的地に到達後、経路上に存在する複数の潜在ニーズ要素についての第2アプリケーションをまとめてレコメンドするようにしてもよい。例えば、自転車、バイク、自動車で移動中であることを検知した場合には、通知をすることによりユーザの注意が通知にとらわれる可能性があるので、そのようなタイミングを避け、目的地に到着後にレコメンドをする。
なお、これらの場合、例えば、第1アプリケーションからのプッシュ通知、又は、第2アプリケーションが端末装置2にインストール済みであるときは第2アプリケーションからのプッシュ通知により、ユーザに第2アプリケーションをレコメンドするようにしてもよい。
なお、上述した実施形態において、ユーザのニーズに対応する第2アプリケーションは、1対1対応であるように記載したが、これには限られない。多対多対応、例えば、あるニーズに対応する第2アプリケーションの候補となるアプリケーションが複数あってもよいし、ある第2アプリケーションに対応するニーズが複数あってもよい。このような場合、ニーズに対して、ユーザの過去の探索結果等の動向、又は、第1アプリケーションによる探索の後に第2アプリケーションをインストールしたユーザ数等の情報(アプリケーションのインストール実績)により、レコメンドする第2アプリケーションの情報を切り替えるようにしてもよい。
例えば、第1アプリケーション及び連携アプリケーションにおけるユーザの過去の動向から各ユーザの好みをあらかじめ学習しておき、それにしたがってレコメンドするアプリケーションを切り替えるようにしてもよい。ユーザの過去の動向とは、アプリケーションのインストール状況、アプリケーションにおける経路探索条件、又は、ユーザの許可が得られている場合には、ユーザの過去の位置情報等である。これらの情報に基づいて複数の候補となる連携アプリケーションから第2アプリケーションを決定するようにしてもよい。また、別の方法として、複数のユーザにおけるインストール率が高いものを第2アプリケーションとしてもよいし、学習した結果、志向が似ていると判断されたユーザのインストール率が高いものを第2アプリケーションとしてもよい。
さらに、上述した実施形態において、第1アプリケーションは総合探索アプリケーションであるものとして説明したが、これには限られない。例えば、第1アプリケーションは、一般的なインターネットブラウザであってもよく、ブラウザ上で総合探索サイトから総合探索するようにしてもよい。この場合、連携するアプリケーションとは、ブラウザにて探索に用いているサイトと連携するアプリケーション、例えば、当該サイトを運営している事業者と同じ事業者により作成されたアプリケーションであってもよい。
また、上述した実施形態で説明した情報処理システムの少なくとも一部は、ハードウェアで構成してもよいし、ソフトウェアで構成してもよい。ソフトウェアで構成する場合には、情報処理システムの少なくとも一部の機能を実現するプログラムをフレキシブルディスクやCD-ROM等の記録媒体に収納し、コンピュータに読み込ませて実行させてもよい。記録媒体は、磁気ディスクや光ディスク等着脱可能なものに限定されず、ハードディスク装置やメモリなど固定型の記録媒体でもよい。
上述の情報処理システムの少なくとも一部の機能を実現するプログラムを、インターネット等の通信回線(無線通信も含む)を介して頒布してもよい。さらに、同プログラムを暗号化したり、変調を掛けたり、圧縮した状態で、インターネット等の有線回線や無線回線を介して、或いは記録媒体に収納して頒布してもよい。
さらに、1つ又は複数の情報処理装置によって情報処理システムを機能させてもよい。複数の情報処理装置を用いる場合、情報処理装置のうち1つをコンピュータとし、当該コンピュータが所定のプログラムを実行することにより情報処理システムの少なくとも1つの手段として機能が実現されてもよい。
上記の記載に基づいて、当業者であれば、本発明の追加や効果や種々の変形を想到できるかもしれないが、本発明の態様は、上述した個々の実施形態に限定されるものではない。特許請求の範囲に規定された内容及びその均等物から導き出される本発明の概念的な思想と趣旨を逸脱しない範囲で種々の追加、変更及び部分的削除が可能である。