JP7022983B2 - 情報処理システム、情報処理プログラムおよび情報処理方法 - Google Patents

Description

本発明は、情報処理システム、情報処理プログラムおよび情報処理方法に関する。

従来から、ユーザが端末装置を操作して経路探索条件の指定発着駅を入力すると、その指定発着駅を利用する候補経路を探索して出力するシステムが知られている。特許文献１には、端末装置での経路探索条件の入力時に、過去に経路探索に利用した頻度が高い順に候補地点を表示する技術が開示されている。

特開２００８－３０２８４４号公報

従来の経路探索システムでは、ユーザが推測した発着駅を経路探索条件として入力して経路探索を行うが、特に土地勘が無い場所の経路探索などにおいて、駅名が似ている駅が複数存在していたり、近い距離に複数の駅が存在していたりすると、ユーザは意図する経路結果を得るまでに、試行錯誤して指定発着駅を変更しながら何度も経路探索を繰り返してしまうことがある。

本発明は、以上のような点を考慮してなされたものである。本発明の目的は、経路探索時に再探索に係るユーザの負荷を低減できる情報処理システム、情報処理プログラムおよび情報処理方法を提供することにある。

本発明に係る情報処理システムは、
経路探索条件の指定発着駅を利用する候補経路を取得する第１経路取得手段と、
前記指定発着駅のうち少なくとも一方について変更候補の別駅を特定する別駅特定手段と、
前記指定発着駅のうち少なくとも一方を前記別駅へ変更して探索した経路である別ルートを取得する第２経路取得手段と、
前記指定発着駅を利用する候補経路と共に、前記別ルートを出力する出力制御手段と、
を備える。

本発明によれば、経路探索時に再探索に係るユーザの負荷を低減できる。

図１は、第１の実施形態に係る情報処理システムの概略的な構成を示す図である。 図２は、第１の実施形態に係る情報処理システムが有する経路探索ログデータベースの一例を示すテーブルである。 図３は、第１の実施形態に係る情報処理システムの動作の一例を示すフローチャートである。 図４は、第１の実施形態に係る情報処理システムにより表示される画面の一例を示す図である。 図５は、第１の実施形態の第１変形例に係る情報処理システムの動作の一例を示すフローチャートである。 図６は、第１の実施形態の第１変形例に係る情報処理システムにより表示される画面の一例を示す図である。 図７は、第１の実施形態の第１変形例に係る情報処理システムにより表示される画面の別例を示す図である。 図８は、第１の実施形態の第２変形例に係る情報処理システムの動作の一例を示すフローチャートである。 図９は、第１の実施形態の第２変形例に係る情報処理システムにより表示される画面の一例を示す図である。 図１０は、第１の実施形態の第３変形例に係る情報処理システムの動作の一例を示すフローチャートである。 図１１は、第１の実施形態の第３変形例に係る情報処理システムにより表示される画面の一例を示す図である。 図１２は、第２の実施形態に係る情報処理システムの概略的な構成を示す図である。

以下に、添付の図面を参照して、本発明の実施の形態を詳細に説明する。なお、各図において同等の機能を有する構成要素には同一の符号を付し、同一符号の構成要素の詳しい説明は繰り返さない。

（第１の実施形態）
第１の実施形態に係る情報処理システムについて説明する。図１は、第１の実施形態に係る情報処理システム１の概略的な構成を示す図である。なお、同図において、各機能を行う機能部は、それぞれ各機能を行う手段ということができる。

図１に示すように、情報処理システム１は、端末装置２と、サーバ３とを備えている。端末装置２とサーバ３とは、インターネット等のネットワーク４を介して互いに通信可能に接続されている。ネットワーク４は、有線回線と無線回線のいずれでもよく、回線の種類や形態は問わない。なお、端末装置２およびサーバ３の少なくとも一部は、コンピュータにより実現される。

端末装置２は、ユーザが使用するものであり、たとえば、スマートフォンやタブレット端末などのモバイル端末、ノートブックコンピュータ、またはデスクトップコンピュータなどの電子機器である

図１に示すように、端末装置２は、端末通信部２１と、端末制御部２２と、端末記憶部２３と、端末入力部２４と、端末出力部２５とを有している。各部は、バスを介して互いに通信可能に接続されている。

端末通信部２１は、端末装置２とネットワーク４との間の通信インターフェースである。端末通信部２１は、ネットワーク４を介して端末装置２とサーバ３との間で情報を送受信する。

端末制御部２２は、端末装置２の各種処理を行う制御手段である。端末制御部２２は、端末装置２内のプロセッサが所定のプログラムを実行することにより実現されてもよいし、ハードウェアで実装されてもよい。

端末記憶部２３は、たとえば内蔵メモリや外部メモリ（ＳＤメモリカード等）などのデータストレージである。端末記憶部２３には、端末制御部２２が取り扱う各種データが記憶される。端末記憶部２３は、必ずしも端末装置２内に設けられていなくてもよく、ネットワーク４を介して端末装置２と通信可能に接続された別の装置（たとえば、サーバ）内に設けられていてもよい。

端末入力部２４は、ユーザが端末装置２に情報を入力するためのインターフェースであり、たとえばモバイル端末におけるタッチパネルやマイクロフォン、ノートブックコンピュータにおけるタッチパッド、キーボードまたはマウスなどである。

端末出力部２５は、端末装置２からユーザに対して各種情報を出力するインターフェースであり、たとえば液晶ディスプレイ等の映像表示手段やスピーカ等の音声出力手段である。具体的には、たとえば、端末出力部２５は、ユーザからの操作を受け付けるためのＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）を表示してもよい。

次に、サーバ３について説明する。図１に示すように、サーバ３は、サーバ通信部３１と、サーバ制御部３２と、サーバ記憶部３３とを有している。各部は、バスを介して互いに通信可能に接続されている。

このうちサーバ通信部３１は、サーバ３とネットワーク４との間の通信インターフェースである。サーバ通信部３１は、ネットワーク４を介して端末装置２とサーバ３との間で情報を送受信する。

サーバ制御部３２は、第１経路取得部３２ａと、第２経路取得部３２ｂと、出力制御部３２ｃと、別駅特定部３２ｄとを有している。これらの各部は、サーバ３内のプロセッサが所定のプログラムを実行することにより実現されてもよいし、ハードウェアで実装されてもよい。

第１経路取得部３２ａは、端末入力部２４に対する経路探索条件の入力に応じて、たとえば後述する経路ネットワーク情報データベース３３ａを参照して、経路探索条件を満たすような候補経路（すなわち、経路探索条件の指定発着駅を利用する候補経路）を取得する。

別駅特定部３２ｄは、たとえば後述する経路探索ログデータベース３３ｃを参照して、経路探索条件の指定発着駅がよく再探索される発着駅の組み合わせ（すなわち、再探索される可能性が高い発着駅の組み合わせ）か否かを判定し、よく再探索される発着駅の組み合わせであると判定した場合には、指定発着駅の少なくとも一方について変更候補の駅（以下「別駅」ともいう。）を特定する。

別駅特定部３２ｄは、経路探索ログデータベース３３ｃにてデータベース化された複数のユーザの経路探索ログのうち、所定期間内（たとえば５分以内）に発着駅の少なくとも一方を変更して再探索を実行したログに基づいて、前記別駅を特定してもよい。

また、よく再探索される発着駅の組み合わせか否かを判定する際、および、前記別駅の特定する際に、別駅特定部３２ｄは、経路探索ログデータベース３３ｃにてデータベース化された複数のユーザの経路探索ログのうち、ユーザ属性または利用傾向が類似するユーザのログのみを対象として利用してもよい。あるいは、別駅特定部３２ｄは、経路探索ログデータベース３３ｃにてデータベース化された複数のユーザの経路探索ログのうち、終電検索した後に再探索を実行したログのみを対象として利用してもよい。

別駅特定部３２ｄにより前記別駅が特定された後、第２経路取得部３２ｂは、指定発着駅のうち少なくとも一方を前記別駅へ変更して探索した経路である別ルートを、たとえば後述する経路ネットワーク情報データベース３３ａを参照して取得する。

出力制御部３２ｃは、第１経路取得部３２ａにより取得された、指定発着駅を利用する候補経路を、端末装置２の端末出力部２５を介して出力する。また、出力制御部３２ｃは、第２経路取得部３２ｂにより別ルートが取得されている場合には、指定発着駅を利用する候補経路と共に当該別ルートを、端末装置２の端末出力部２５を介して出力する。

出力制御部３２ｃは、たとえば後述する経路探索ログデータベース３３ｃを参照して、別ルートの推奨理由ないし別ルートと候補経路との関係性を説明する補足情報を取得し、別ルートと併せて端末装置２の端末出力部２５に出力してもよい。ここで、「別ルートと候補経路との関係性を説明する補足情報」は、変更元の駅と変更先の駅との間の距離に関する情報、他のユーザによる再探索の発生の有無に関する情報、再探索回数（他のユーザによって再探索されている件数）に関する情報、候補経路と別ルートとの位置関係に関する情報、候補経路と別ルートの移動手段の関連性（たとえば、変更元の駅と変更先の駅がどちらも新幹線の停車駅であることなど）に関する情報、候補経路と別ルートの時間帯に関する情報、および候補経路と別ルートの終電に関する情報、候補経路と別ルートとの料金の差分に関する情報（たとえば、新幹線利用の場合「東京駅まで行っても＋５００円です」「上野駅で降りれば１０００円安いです」など）のうちの少なくとも１つであってもよい。

サーバ記憶部３３は、たとえばハードディスク等の固定型データストレージである。サーバ記憶部３３には、サーバ制御部３２が取り扱う各種データが記憶される。たとえば、サーバ記憶部３３は、交通ネットワーク情報を含む経路ネットワーク情報データベース３３ａと、地図情報を含む地図情報データベース３３ｂと、経路探索ログデータベース３３ｃとを含んでいる。

交通ネットワーク情報は、鉄道やバス等の交通網や道路網を規定する情報である。交通網の情報としては、交通機関の路線情報、時刻表情報、料金情報等を含む。道路網の情報は、例えば交差点等の道路網表現上の結節点であるノードのデータと、ノード間の道路区間であるリンクのデータとの組み合わせによって表現される。地図情報および経路ネットワーク情報は、渋滞状況の予測や経路探索に用いられる。

地図情報は、全国および各地方の道路地図などの地図データと、地図データに対応付けられた地図オブジェクト情報を含む。地図オブジェクト情報とは、地図上に表示される施設の形状についての形状情報、地図上に表示される注記についての注記情報、地図上に表示される記号についての記号情報などである。また、地図情報は公共交通機関の路線図に関する路線図情報を含んでいてもよい。

上記の交通ネットワーク情報および地図情報は、所定のタイミングでアップデートされてもよい。

経路探索ログデータベース３３ｃには、複数のユーザの経路探索ログがデータベース化されている。図２は、経路探索ログデータベース３３ｃに含まれるデータの一例を示している。

図２に示す例では、経路探索ログデータベース３３ｃには、経路探索条件として指定された出発駅および到着駅と、再探索時に指定された出発駅および到着駅と、そのような再探索が行われた件数と、再探索の理由とが互いに関連付けて記憶されている。

具体的には、たとえば、図２に示すテーブルの１行目では、経路探索条件の出発駅として「新宿」駅、到着駅として「後楽園」駅が指定されて経路探索が行われた場合であって、所定期間内（たとえば５分以内）に、出発駅は「新宿」駅のまま、到着駅が「水道橋」駅に変更されて再探索された件数が、これまで１２３件あったことが記憶されている。また、到着駅の「後楽園」駅と「水道橋」駅との間の距離が近いこと（さらには、どちらの駅もドーム球場に近いこと）が再探索の理由として記憶されている。

図２に示すテーブルの２行目では、経路探索条件の出発駅として「東京」駅、到着駅として「大阪」駅が指定されて経路探索が行われた場合であって、所定期間内（たとえば５分以内）に、出発駅は「新宿」駅のまま、到着駅が「新大阪」駅に変更されて再探索された件数が、これまで４５６件あったことが記憶されている。また、到着駅の「大阪」駅と「新大阪」駅の駅名が似ていることが再探索の理由として記憶されている。

図２に示すテーブルの３行目では、経路探索条件の出発駅として「八王子」駅、到着駅として「新宿」駅が指定されて経路探索が行われた場合であって、所定期間内（たとえば５分以内）に、到着駅は「新宿」駅のまま、出発駅が「京王八王子」駅に変更されて再探索された件数が、これまで７８件あったことが記憶されている。また、出発駅の「八王子」駅と「京王八王子」駅の駅名が似ていることが再探索の理由として記憶されている。

図２に示すテーブルの４行目では、経路探索条件の出発駅として「新大阪」駅、到着駅として「東京」駅が指定されて経路探索が行われた場合であって、所定期間内（たとえば５分以内）に、出発駅は「新大阪」駅のまま、出発駅が「品川」駅に変更されて再探索された件数が、これまで９０件あったことが記憶されている。また、到着駅の「東京」駅と「品川」駅がどちらも新幹線の停車駅であって距離が近いことが再探索の理由として記憶されている。

経路探索ログデータベース３３ｃの「再探索の理由」については、変更元の駅と変更先の駅との間の距離が所定距離（たとえば直線１ｋｍ）以下であるか否か、または変更元の駅と変更先の駅の駅名が似ているか（たとえば駅名の一部が一致しているか）否かを、サーバ制御部３２が地図情報データベース３３等を参照して機械的に判断し、その判断結果を再探索の理由として経路探索ログデータベース３３ｃに記憶してもよい。あるいは、データベースの管理者が、変更元の駅名と変更先の駅名とを目視で確認し、管理者の知見に基づいて推測される再探索の理由を、経路探索ログデータベース３３ｃに手動で入力して記憶してもよい。また、経路探索ログデータベース３３ｃにおいて「再探索の理由」の欄は、必ずしも必須ではなく、省略されていてもよい。

経路探索ログデータベース３３ｃにおいて、経路探索ログが時間帯や曜日、特定の期間、季節などに基づいて分類され、データベース化されてもよい。この場合、別駅特定部３２ｄは、経路探索リクエストに含まれる日時条件が上記分類に該当するかに基づいて対象として用いるログを特定し、当該ログに基づいて変更候補の別駅を特定してもよい。

なお、サーバ記憶部３３は、必ずしもサーバ３内に設けられなくてもよく、ネットワーク４を介してサーバ３と通信可能に接続された別の装置内に設けられてもよい。

（動作の一例）
次に、図３および図４を参照して、情報処理システム１の動作の一例について説明する。図３は、情報処理システム１の動作の一例を示すフローチャートである。図４は、情報処理システム１により表示される画面の一例を示す図である。

まず、図３に示すように、端末装置２のユーザが、経路探索条件の指定発着駅を端末入力部２４に入力する（ステップＳ１０）。入力された経路探索条件は、端末通信部２１からネットワーク４を介してサーバ通信部３１へと送信される。

第１経路取得部３２ａは、端末装置２から取得した経路探索条件を満たすような候補経路（すなわち、指定発着駅を利用する候補経路）を、経路ネットワーク情報データベース３３ａを参照して取得する（ステップＳ１１）。

また、別駅特定部３２ｄは、指定発着駅がよく再探索される発着駅の組み合わせか否かを、経路探索ログデータベース３３ｃを参照して判定する（ステップＳ１３）。具体的には、たとえば、別駅特定部３２ｄは、経路探索条件の指定発着駅にて経路探索が行われた後に指定発着駅の少なくとも一方が変更されて再探索された件数が所定数（たとえば５０件）以上あるか否かを、経路探索ログデータベース３３ｃを参照して判定する。そして、別駅特定部３２ｄは、再探索された件数が所定数（たとえば５０件）以上あった場合には、よく再探索される発着駅の組み合わせであると判定し、再探索された件数が所定数（たとえば５０件）未満であった場合には、よく再探索される発着駅の組み合わせではないと判定する。

経路探索条件の指定発着駅がよく再探索される発着駅の組み合わせではないと判定される場合には（ステップＳ１２：ＮＯ）、出力制御部３２ｃは、第１経路取得部３２ａにより取得された候補経路を、サーバ通信部３１からネットワーク４を介して端末通信部２１へと送信し、端末出力部２５にて候補経路のみを出力させる（ステップＳ１３）。

一方、経路探索条件の指定発着駅がよく再探索される発着駅の組み合わせであると判定される場合には（ステップＳ１２：ＹＥＳ）、別駅特定部３２ｄは、指定発着駅の少なくとも一方について変更候補の別駅を、経路探索ログデータベース３３ｃを参照して特定する（ステップＳ１４）。具体的には、たとえば、経路探索条件の指定出発駅が「新宿」駅であり、指定到着駅が「後楽園」駅である場合、別駅特定部３２ｄは、図２の経路探索ログデータベース３３ｃを参照し、変更候補の到着駅として「水道橋」駅を特定する。

そして、第２経路取得部３２ｂは、経路探索条件の指定発着駅の少なくとも一方を、ステップＳ１４にて特定された別駅へと変更し、変更後の経路探索条件を満たすような別ルート（候補経路とは別の経路）を、経路ネットワーク情報データベース３３ａを参照して取得する（ステップＳ１５）。

出力制御部３２ｃは、第１経路取得部３２ａにより取得された候補経路と、第２経路取得部３２ｂにより取得された別ルートの両方を、サーバ通信部３１からネットワーク４を介して端末通信部２１へと送信し、図４に示すように、端末出力部２５にて候補経路４１、４２とともに別ルート５１を出力させる（ステップＳ１６）。図４に示す例では、指定出発駅の「新宿」駅から指定到着駅の「後楽園」駅までの２つの候補経路４１、４２とともに、よく再探索されるルートして、指定出発駅の「新宿駅」から「水道橋」駅までの別ルート５１が、端末出力部２５に表示される。

ところで、発明が解決しようとする課題の欄でも言及したように、従来の経路探索システムでは、特に土地勘が無い場所の経路探索などにおいて、駅名が似ている駅が複数存在していたり、近い距離に複数の駅が存在していたりすると、ユーザは意図する経路結果を得るまでに、指定発着駅を変更しながら何度も経路探索を繰り返してしまうことがあった。

これに対し、本実施の形態によれば、第２経路取得部３２ｂが、指定発着駅のうち少なくとも一方を別駅へ変更して探索した経路である別ルートを取得し、出力制御部３２ｃが、指定発着駅を利用する候補経路ととともに別ルートを出力するため、ユーザは自ら再探索の操作をしなくても、再探索したのと同様な情報を受け取ることができる。したがって、ユーザが再探索を行う手間を省くことができ、利便性が大幅に向上する。また、端末装置２からサーバ３に対する再探索リクエスト数を削減でき、サーバ３への負荷を軽減できる。

（第１の変形例）
第１の実施形態の第１の変形例について、図５～図７を参照して説明する。図５は、第１の変形例に係る情報処理システム１の動作の一例を示すフローチャートである。図６は、第１の変形例に係る情報処理システム１により表示される画面の一例を示す図である。図７は、第１の変形例に係る情報処理システム１により表示される画面の別例を示す図である。第１の変形例において、ステップＳ１０～Ｓ１６は、上述した実施の形態と同様であり、説明を省略する。

図５に示すように、第１の変形例では、ステップＳ１６の後、出力制御部３２ｃが、経路探索ログデータベース３３ｃを参照して、別ルートの推奨理由、または別ルートと候補経路との関係性を説明する補足情報を取得する（ステップＳ１７）。次いで、出力制御部３２ｃは、図６に示すように、取得した推奨理由または補足情報５２を、別ルート５１と併せて端末出力部３５に出力する（ステップＳ１８）。

具体的には、たとえば、図２および図６を参照し、経路探索条件の指定出発駅が「新宿」駅であり、指定到着駅が「後楽園」駅である場合には、ステップＳ１７において、出力制御部３２ｃは、「ドーム球場に近い」という再探索の理由を、別ルートの推奨理由ないし補足情報として取得する。そして、ステップＳ１８において、出力制御部３２ｃは、指定出発駅の「新宿」駅から「水道橋」駅までの別ルート５１と併せて、「ドーム球場に行くならこのルートも便利です」という別ルートの推奨理由ないし補足情報５２を、端末出力部２５に出力する。図６に示す例のように、出力制御部３２ｃは、「ドアｔｏドアの検索はこちら」などの次に推奨される操作を案内する表示５３を、別ルート５１と併せて出力してもよい。

また、たとえば、図２および図７を参照し、経路探索条件の指定出発駅が「新大阪」駅であり、指定到着駅が「東京」駅である場合には、ステップＳ１５において、第２経路取得部３２ｂが、指定出発駅の「新大阪」駅から「品川」駅までの経路を別ルートして取得し、ステップＳ１７において、出力制御部３２ｃは、図２を参照し、「距離が近い新幹線の停車駅」という再探索の理由を、別ルートの推奨理由ないし補足情報として取得する。そして、ステップＳ１８において、出力制御部３２ｃは、指定出発駅の「新大阪」駅から「品川」駅までの別ルート５１と併せて、「新幹線利用の場合、このルートもよく検索されています」という別ルートの推奨理由ないし補足情報５４を、端末出力部２５に出力する。

以上のような第１の変形例によれば、出力制御部３２ｃが、別ルートの推奨理由ないし別ルートと候補経路との関係性を説明する補足情報５２、５４を、別ルート５１と併せて端末出力部２５に出力するため、当該別ルート５１の信用性が高まり、ユーザが当該別ルート５１に納得してそれを採用する可能性が高まる。したがって、ユーザが再探索を行う手間をさらに省くことができ、利便性がさらに向上する。

なお、第１の変形例において、図５を参照し、ステップＳ１７は、ステップＳ１６の後に行われることは必ずしも必須ではなく、ステップＳ１５とステップＳ１６との間に行われてもよいし、ステップＳ１４とステップＳ１５との間に行われてもよい。

（第２の変形例）
第２の変形例について、図８および図９を参照して説明する。以下では、経路探索の際に経路探索条件としてユーザが終電検索（または始発検索）を指定できる場合を前提に説明するが、終電検索（または始発検索）を指定した経路探索要求の他、経路探索要求に含まれる日時条件が深夜時間帯（または早朝時間帯）に含まれる日時条件である場合も同様である。図８は、第２の変形例に係る情報処理システム１の動作の一例を示すフローチャートである。図９は、第２の変形例に係る情報処理システム１により表示される画面の一例を示す図である。

まず、図８に示すように、端末装置２のユーザが、経路探索条件の指定発着駅を端末入力部２４に入力するとともに、経路探索条件として終電検索（または始発検索）を指定する（ステップＳ１０’）。入力された経路探索条件は、端末通信部２１からネットワーク４を介してサーバ通信部３１へと送信される。

第１経路取得部３２ａは、端末装置２から取得した経路探索条件を満たすような候補経路（すなわち、終電検索時においては、ユーザが指定する出発駅から目的駅までの経路であって、最終電車を利用する経路など、出発時刻が営業日の中で最も遅い経路、始発検索時においては、ユーザが指定する出発駅から目的駅までの経路であって、一番電車を利用する経路など、出発時刻が営業日の中で最も早い経路）を、経路ネットワーク情報データベース３３ａを参照して取得する（ステップＳ１１’）。第１経路取得部３２ａは、利用する路線が異なる経路のバリエーションごとに複数の候補経路を取得してもよい。

次に、第２経路取得部３２ｂは、以後の処理で利用する経路探索ログを決定する（ステップＳ１９）。たとえば、第２経路取得部３２ｂは、複数のユーザの経路探索ログのうち、終電検索（または始発検索）した後に再探索したログのみを対象として利用することを決定する。

そして、第２経路取得部３２ｂは、指定発着駅がよく再探索される発着駅の組み合わせか否かを、経路探索ログデータベース３３ｃのうち、ステップＳ１９にて利用することが決定された経路探索ログのみを参照して判定する（ステップＳ１３）。具体的には、たとえば、第２経路取得部３２ｂは、経路探索条件の指定発着駅にて終電検索（または始発検索）が行われた後所定時間内に同一ユーザにより指定発着駅の少なくとも一方が変更されて再度終電検索（または始発検索）された件数が所定数（たとえば５０件）以上あるか否かを、経路探索ログデータベース３３ｃを参照して判定する。そして、第２経路取得部３２ｂは、再度終電検索（または始発検索）された件数が所定数（たとえば５０件）以上あった場合には、指定発着駅がよく再探索される発着駅の組み合わせであると判定し、再度終電検索（または始発検索）された件数が所定数（たとえば５０件）未満であった場合には、指定発着駅がよく再探索される発着駅の組み合わせではないと判定する。

経路探索条件の指定発着駅がよく再探索される発着駅の組み合わせではないと判定される場合には（ステップＳ１２：ＮＯ）、上述した実施の形態と同様に、出力制御部３２ｃは、第１経路取得部３２ａにより取得された候補経路を、サーバ通信部３１からネットワーク４を介して端末通信部２１へと送信し、端末出力部２５にて候補経路を出力させる（ステップＳ１３）。

一方、経路探索条件の指定発着駅がよく再探索される発着駅の組み合わせであると判定される場合には（ステップＳ１２：ＹＥＳ）、第２経路取得部３２ｂは、指定発着駅の少なくとも一方について変更候補の別の駅を、経路探索ログデータベース３３ｃのうち、ステップＳ１９にて利用することが決定された経路探索ログのみを参照して特定する（ステップＳ１４）。具体的には、たとえば、経路探索条件の指定出発駅が「新宿」駅であり、指定到着駅が「後楽園」駅である場合には、第２経路取得部３２ｂは、経路探索ログデータベース３３ｃのうち終電検索（または始発検索）した後に再検索したログのみを参照して、変更候補の到着駅として「水道橋」駅を特定する。

そして、第２経路取得部３２ｂは、経路探索条件の指定発着駅の少なくとも一方を、ステップＳ１４にて特定した別駅へと変更し、変更後の経路探索条件を満たすような別ルート（候補経路とは別の経路）を、経路ネットワーク情報データベース３３ａを参照して取得する（ステップＳ１５）。

出力制御部３２ｃは、第１経路取得部３２ａにより取得された候補経路と、第２経路取得部３２ｂにより取得された別ルートの両方を、サーバ通信部３１からネットワーク４を介して端末通信部２１へと送信し、図９に示すように、端末出力部２５にて候補経路４１、４２とともに別ルート５１を出力させる（ステップＳ１６）。図９に示す例では、指定出発駅の「新宿」駅から指定到着駅の「後楽園」駅までの２つの候補経路４１、４２とともに、終電検索時によく再探索されているルートして、指定出発駅の「新宿駅」から「水道橋」駅までの別ルート５１が、端末出力部２５に一覧で表示される。なお、出力制御部３２ｃは、終電検索時の「よく再探索されるルート」の出力時においては、候補経路よりも別ルートの方が出発時刻が遅い場合のみ、別ルートを出力するように制御してもよい。同様に、出力制御部３２ｃは、始発検索時の「よく再探索されるルート」の出力時においては、候補経路よりも別ルートの方が到着時刻が早い場合のみ、別ルートを出力するように制御してもよい。

また、出力制御部３２ｃは、経路探索ログデータベース３３ｃのうち、ステップＳ１９にて利用することが決定された経路探索ログのみを参照して、別ルートの推奨理由、または別ルートと候補経路との関係性を説明する補足情報を取得する（ステップＳ１７）。具体的には、たとえば、経路探索条件の指定出発駅が「新宿」駅であり、指定到着駅が「後楽園」駅であって終電検索が指定されている場合において、出力制御部３２ｃは、「距離が近く、終電が遅い」という再探索の理由を、別ルートの推奨理由ないし補足情報として取得する。

次いで、出力制御部３２ｃは、図９に示すように、取得した推奨理由または補足情報５５を、別ルート５１と併せて端末出力部３５に出力する（ステップＳ１８）。図９に示す例では、出力制御部３２ｃは、指定出発駅の「新宿」駅から「水道橋」駅までの別ルート５１と併せて、「終電が遅い別ルートです。（徒歩距離８００ｍ）」という別ルートの推奨理由ないし補足情報５５を、端末出力部２５に出力する。なお、出力制御部３２ｃは、別ルートの品質を保つために、ステップＳ１６とＳ１７の順番を逆転させたうえ、別ルートと候補経路との関係性が所定条件を満たす場合（たとえば、出発時刻の差、徒歩距離の差などが所定以内の場合）のみ、別ルートを出力するように制御してもよい。また、図９に示す例のように、出力制御部３２ｃは、「到着駅を変えてもっとみる」などの次に推奨される操作を案内する表示５６を、別ルート５１と併せて出力してもよい。

以上のような第２の変形例によれば、複数のユーザの経路探索ログのうち、終電検索（または始発検索）した後に再探索したログのみを対象として利用するため、終電検索（または始発検索）を行うユーザにとってより適切な（再探索する可能性の高い）別ルート５１を、第２経路取得部３２ｂが取得するとともに、出力制御部３２ｃが出力することができる。これにより、終電検索（または始発検索）を行うユーザにとって、出力される別ルート５１の信用性はより高いものとなり、ユーザが当該別ルート５１に納得してそれを採用する可能性がさらに高まる。したがって、ユーザが再探索を行う手間をさらに省くことができ、利便性がさらに向上する。

なお、上述した第２の変形例では、ステップＳ１９において、第２経路取得部３２ｂが、複数のユーザの経路探索ログのうち、終電検索（または始発検索）した後に再探索したログのみを対象として利用することを決定したが、これに限られるものではなく、たとえば、第２経路取得部３２ｂは、ユーザの属性（たとえば、性別、年齢、生活地域など）または利用傾向が類似するユーザのログのみを対象として利用することを決定してもよい。この場合であっても、ユーザにとって、より適切な（再探索する可能性の高い）別ルート５１を、第２経路取得部３２ｂが取得するとともに、出力制御部３２ｃが出力することができるから、ユーザにとって、出力される別ルート５１の信用性はより高いものとなり、ユーザが当該別ルート５１に納得してそれを採用する可能性がさらに高まる。したがって、ユーザが再探索を行う手間をさらに省くことができ、利便性がさらに向上する。

（第３の変形例）
第１の実施形態の第３の変形例について、図１０および図１１を参照して説明する。図１０は、第３の変形例に係る情報処理システム１の動作の一例を示すフローチャートである。図１１は、第３の変形例に係る情報処理システム１により表示される画面の一例を示す図である。第３の変形例において、ステップＳ１０～Ｓ１４は、上述した実施の形態と同様であり、説明を省略する。

図１０に示すように、第３の変形例では、ステップＳ１４の後、出力制御部３２ｃが、経路探索条件の指定発着駅の少なくとも一方を、ステップＳ１４にて特定された別駅へと変更した変更後の経路探索条件（以下、別探索条件という）を、第１経路取得部３２ａにより取得された候補経路とともに、サーバ通信部３１からネットワーク４を介して端末通信部２１へと送信し、図１１に示すように、端末出力部２５にて候補経路４１、４２とともに別探索条件６０を出力させる（ステップＳ２０）。図１１に示す例では、指定出発駅の「新宿」駅から指定到着駅の「後楽園」駅までの２つの候補経路４１、４２とともに、指定到着駅を「水道橋」駅に変更した別探索条件６０が、端末出力部２５に表示される。端末出力部２５は、当初の指定出発駅とは異なる駅については、別の色で表示する等、識別しやすい態様で表示してもよい。

端末装置２のユーザが、端末出力部２５に表示された別探索条件６０を選択すると、別探索条件６０にかかる情報が端末装置２からサーバ３へと送信される。

サーバ３の第２経路取得部３２ｂは、端末装置２のユーザにより別探索条件が選択されたか否かを判定する（ステップＳ２１）。別探索条件が選択されたと判定されない場合には（ステップＳ２１：ＮＯ）、第２経路取得部３２ｂは処理を終了する。

一方、別探索条件が選択されたと判定された場合には（ステップＳ２１：ＹＥＳ）、第２経路取得部３２ｂは、経路探索条件の指定発着駅の少なくとも一方を、ステップＳ１４にて特定された別駅へと変更した経路探索条件（すなわち別探索条件）を満たすような別ルート（候補経路とは別の経路）を、経路ネットワーク情報データベース３３ａを参照して取得する（ステップＳ２２）。

出力制御部３２ｃは、第２経路取得部３２ｂにより取得された別ルートを、サーバ通信部３１からネットワーク４を介して端末通信部２１へと送信し、端末出力部２５にて候補経路４１、４２とともに別ルート５１を出力させる（ステップＳ２３）。

以上のような第３の変形例によれば、別駅特定部３２ｄが、指定発着駅のうち少なくとも一方について変更候補の別駅を特定し、出力制御部３２ｃが、指定発着駅を利用する候補経路ととともに、指定発着駅のうち少なくとも一方を別駅へと変更した探索条件を出力するため、たとえば土地勘が無い場所の経路探索などにおいて、ユーザが再探索にあたって変更候補の別駅の駅名を知らない場合であっても、悩むことなく再探索を行うことが可能となり、再探索に係るユーザの負荷を大幅に低減できる。

（第２の実施形態）
上述した実施の形態およびその変形例では、複数のユーザの経路探索ログが経路探索ログデータベース３３ｃにてデータベース化されており、第２経路取得部３２ｂは、経路探索ログデータベース３３ｃを参照することで、指定発着駅がよく再探索される発着駅の組み合わせか否かを判定し（ステップＳ１２）、また、よく再探索される発着駅の組み合わせであると判定した場合、指定発着駅の少なくとも一方について変更候補の別駅を特定したが（ステップＳ１４）、本発明はこれに限定されるものではない。

図１２は、第２の実施形態に係る情報処理システム１の概略的な構成を示す図である。第２の実施形態では、第２経路取得部３２ｂは、複数のユーザの経路探索ログを機械学習する機械学習部３２ｂ１を有しており、サーバ記憶部３３には、経路探索ログデータベース３３ｃの代わりに、機械学習部３２ｂ１による経路探索ログの学習済みモデル３３ｄが記憶されている。

このような第２の実施形態では、第２経路取得部３２ｂは、ステップＳ１２において、経路探索条件の指定発着駅がよく再探索される発着駅の組み合わせか否かを、機械学習部３２ｂ１の学習結果に基づいて判定する（すなわち、経路探索ログの学習済みモデル３３ｄを利用して予測する）。そして、よく再探索される発着駅の組み合わせであると判定（予測）された場合、第２経路取得部３２ｂは、ステップＳ１４において、指定発着駅の少なくとも一方について変更候補の別駅を、機械学習部３２ｂ１の学習結果に基づいて特定する（すなわち、経路探索ログの学習済みモデル３３ｄを利用して予測する）。

以上のような第２の実施形態によれば、たとえば、経路探索条件の指定発着駅が新駅であったり駅名変更されたばかりであったりして、その経路探索条件で経路探索されたログの絶対数が少なく、データベース化が難しい場合であっても、第２経路取得部３２ｂは、機械学習部３２ｂ１の学習結果に基づいて、経路探索条件の指定発着駅が再探索される可能性が高い組み合わせか否かを予測することができ、また、再探索される可能性が高い組み合わせであると予測した場合、指定発着駅の少なくとも一方について変更候補の別駅を、機械学習部３２ｂ１の学習結果に基づいて予測することができる。したがって、より広範囲な経路探索条件に対応可能となり、利便性がさらに向上する。

なお、上述した実施形態において「駅」は、鉄道駅に限定されるものでなく、バス停留所であってもよいし、空港であってもよい。たとえば、第１経路取得部３２ａが、経路探索条件の指定発着駅（＝鉄道駅）を利用する候補経路（＝電車を利用する経路）を取得するとともに、第２経路取得部３２ｂが、指定発着駅のうち少なくとも一方を別駅（＝バス停留所または空港）へ変更して探索した経路である別ルート（＝バスまたは飛行機を利用する経路）を取得し、出力制御部３２ｃが、電車を利用する候補経路と共に、別ルートとしてバスまたは飛行機を利用する経路を出力してもよい。あるいは、第１経路取得部３２ａが、経路探索条件の指定発着駅（＝バス停留所または空港）を利用する候補経路（＝バスまたは飛行機を利用する経路）を取得するとともに、第２経路取得部３２ｂが、指定発着駅のうち少なくとも一方を別駅（＝鉄道駅）へ変更して探索した経路である別ルート（＝電車を利用する経路）を取得し、出力制御部３２ｃが、バスまたは飛行機を利用する候補経路と共に、別ルートとして電車を利用する経路を出力してもよい。

なお、上述した実施形態で説明した情報処理システム１の少なくとも一部は、ハードウェアで構成してもよいし、ソフトウェアで構成してもよい。ハードウェアで構成する場合には、情報処理システム１の少なくとも一部の機能を実現するプログラムをフレキシブルディスクやＣＤ－ＲＯＭ等の記録媒体に収納し、コンピュータに読み込ませて実行させてもよい。記録媒体は、磁気ディスクや光ディスク等の着脱可能なものに限定されず、ハードディスク装置やメモリなどの固定型の記録媒体でもよい。

また、情報処理システム１の少なくとも一部の機能を実現するプログラムを、インターネット等の通信回線（無線通信も含む）を介して頒布してもよい。さらに、同プログラムを暗号化したり、変調をかけたり、圧縮した状態で、インターネット等の有線回線や無線回線を介して、あるいは記録媒体に収納して頒布してもよい。

さらに、一つまたは複数の情報処理装置によって情報処理システム１を機能させてもよい。複数の情報処理装置を用いる場合、情報処理装置のうちの１つをコンピュータとし、当該コンピュータが所定のプログラムを実行することにより情報処理システム１の少なくとも１つの手段として機能が実現されてもよい。

また、方法の発明においては、全ての工程（ステップ）をコンピュータによって自動制御で実現するようにしてもよい。また、各工程をコンピュータに実施させながら、工程間の進行制御を人の手によって実施するようにしてもよい。また、さらには、全工程のうちの少なくとも一部を人の手によって実施するようにしてもよい。

上記の記載に基づいて、当業者であれば、本発明の追加の効果や様々の変形を想到できるかもしれないが、本発明の態様は、上述した個々の実施形態に限定されるものではない。特許請求の範囲に規定された内容およびその均等物から導き出される本発明の概念的な思想と趣旨を逸脱しない範囲で種々の追加、変更および部分的削除が可能である。

１ 情報処理システム
２ 端末装置
２１ 端末通信部
２２ 端末制御部
２３ 端末記憶部
２４ 端末入力部
２５ 端末出力部
３ サーバ
３１ サーバ通信部
３２ サーバ制御部
３２ａ 第１経路取得部
３２ｂ 第２経路取得部
３２ｂ１ 機械学習部
３２ｃ 出力制御部
３３ サーバ記憶部
３３ａ 経路ネットワーク情報データベース
３３ｂ 地図情報データベース
３３ｃ 経路探索ログデータベース
３３ｄ 経路探索ログの学習済みモデル
４ ネットワーク
４１、４２ 指定発着駅を利用する候補経路
５１ 別ルート
５２、５４、５５ 別ルートの推奨理由ないし補足情報

Claims (13)

1. 経路探索条件の指定発着駅を利用する候補経路を取得する第１経路取得手段と、
   前記指定発着駅のうち少なくとも一方について変更候補の別駅を特定する別駅特定手段と、
   前記指定発着駅のうち少なくとも一方を前記別駅へ変更して探索した経路である別ルートを取得する第２経路取得手段と、
   前記指定発着駅を利用する候補経路と共に、前記別ルートを出力する出力制御手段と、
   を備えた情報処理システム。
2. 経路探索条件の指定発着駅を利用する候補経路を取得する第１経路取得手段と、
   前記指定発着駅のうち少なくとも一方について変更候補の別駅を特定する別駅特定手段と、
   前記指定発着駅を利用する候補経路と共に、前記指定発着駅のうち少なくとも一方を前記別駅へ変更した探索条件を出力する出力制御手段と、
   を備えた情報処理システム。
3. 前記別駅特定手段は、複数のユーザの経路探索ログに基づいて前記別駅を特定する、
   請求項１または２に記載の情報処理システム。
4. 前記別駅特定手段は、複数のユーザが所定期間内に発着駅の少なくとも一方を変更して再探索を実行したログに基づいて前記別駅を特定する、
   請求項３に記載の情報処理システム。
5. 前記別駅特定手段は、複数のユーザの検索探索ログを機械学習し、経路探索条件の指定発着駅の少なくとも一方について変更候補の駅を学習結果に基づいて予測し、前記別駅として特定する、
   請求項３または４に記載の情報処理システム。
6. 前記別駅特定手段は、複数のユーザの経路探索ログのうち、ユーザ属性または利用傾向が類似するユーザのログのみを対象として用いる、
   請求項３～５のいずれかに記載の情報処理システム。
7. 前記別駅特定手段は、複数のユーザの経路探索ログのうち、終電検索した後に再探索したログのみを対象として用いる、
   請求項３～５のいずれかに記載の情報処理システム。
8. 前記出力制御手段は、前記別ルートの推奨理由または前記別ルートと前記候補経路との関係性を説明する補足情報を、前記別ルートと併せて出力する
   請求項１に記載の情報処理システム。
9. 前記補足情報は、変更元駅と変更先駅との間の距離、再探索回数、候補経路と別ルートとの位置関係、候補経路と別ルートの時間帯に関する情報、および候補経路と別ルートの終電に関する情報のうちの少なくとも１つである、
   請求項８に記載の情報処理システム。
10. コンピュータを、
    経路探索条件の指定発着駅を利用する候補経路を取得する第１経路取得手段、
    前記指定発着駅のうち少なくとも一方について変更候補の別駅を特定する別駅特定手段、
    前記指定発着駅のうち少なくとも一方を前記別駅へ変更して探索した経路である別ルートを取得する第２経路取得手段、
    前記指定発着駅を利用する候補経路と共に、前記別ルートを出力する出力制御手段、
    として機能させる情報処理プログラム。
11. コンピュータを、
    経路探索条件の指定発着駅を利用する候補経路を取得する第１経路取得手段、
    前記指定発着駅のうち少なくとも一方について変更候補の別駅を特定する別駅特定手段、
    前記指定発着駅を利用する候補経路と共に、前記指定発着駅のうち少なくとも一方を前記別駅へ変更した探索条件を出力する出力制御手段、
    として機能させる情報処理プログラム。
12. 第１経路取得手段が、経路探索条件の指定発着駅を利用する候補経路を取得するステップと、
    別駅特定手段が、前記指定発着駅のうち少なくとも一方について変更候補の別駅を特定するステップと、
    第２経路取得手段が、前記指定発着駅のうち少なくとも一方を前記別駅へ変更して探索した経路である別ルートを取得するステップと、
    出力制御手段が、前記指定発着駅を利用する候補経路と共に、前記別ルートを出力するステップと、
    を備えた情報処理方法。
13. 第１経路取得手段が、経路探索条件の指定発着駅を利用する候補経路を取得するステップと、
    別駅特定手段が、前記指定発着駅のうち少なくとも一方について変更候補の別駅を特定するステップと、
    出力制御手段が、前記指定発着駅を利用する候補経路と共に、前記指定発着駅のうち少なくとも一方を前記別駅へ変更した探索条件を出力するステップと、
    を備えた情報処理方法。

Images