電子メールによる経路探索システム、経路探索方法、コンピュータプログラム
【課題】１回の電子メールにより得られる経路探索結果の情報量を多くする。
【解決手段】ユーザ端末３０から自然文で記述された経路探索の依頼メールを受信すると、自然言語処理ツール１２で自然文解析して交通機関の経路探索条件を抽出する。経路探索ツール１３は、経路探索条件に適合する経路候補のダイヤ情報を特定するとともに、この経路候補と同じ路線でその出発地における出発予定時刻よりも遅い時刻を当該出発地の出発予定時刻とする１又は複数の代替経路のダイヤ情報、又は、経路候補と同じ路線でその目的地における到着予定時刻よりも早い時刻を当該目的地の到着予定時刻とする代替経路のダイヤ情報を取得する。主制御部１０は、経路候補及び代替経路のダイヤ情報をマージし、マージしたダイヤ情報をユーザ端末３０の一つの画面で表示可能な回答文に編集し、編集した回答文を電子メールでユーザ端末３０へ返信する。
【解決手段】ユーザ端末３０から自然文で記述された経路探索の依頼メールを受信すると、自然言語処理ツール１２で自然文解析して交通機関の経路探索条件を抽出する。経路探索ツール１３は、経路探索条件に適合する経路候補のダイヤ情報を特定するとともに、この経路候補と同じ路線でその出発地における出発予定時刻よりも遅い時刻を当該出発地の出発予定時刻とする１又は複数の代替経路のダイヤ情報、又は、経路候補と同じ路線でその目的地における到着予定時刻よりも早い時刻を当該目的地の到着予定時刻とする代替経路のダイヤ情報を取得する。主制御部１０は、経路候補及び代替経路のダイヤ情報をマージし、マージしたダイヤ情報をユーザ端末３０の一つの画面で表示可能な回答文に編集し、編集した回答文を電子メールでユーザ端末３０へ返信する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ユーザにとって快適な交通機関の経路探索環境を実現可能にする電子メールを用いた経路探索技術に関する。
【背景技術】
【０００２】
列車等の交通機関における最適な運行経路の探索技術については、昭和時代に本願出願人により開発され、多くのユーザの支持を得た経路探索ソフト「駅すぱあと」(登録商標、非特許文献１参照）の登場以来、複数の企業技術者の手により幾多の改良・改善が試みられてきた。交通機関の経路探索において、出発地及び目的地が指定されたときの探索処理は、概ね以下のように行われている。
【０００３】
出発地に繋がるすべての路線（交通機関が、ある地点から他地点に至る経路）、駅について、経路の運行コスト（時間、距離、運賃等）が最小となる次の駅の探索処理を連鎖的に繰り返すことで、水面に石を投げたときの波紋のような形態で経路探索を行う。探索過程で目的地が特定された場合、その目的地と出発地との間の経路をユーザが望む経路候補とするとともに、さらにそこから派生する経路候補を多数パターン探索して保持し、ユーザが指定した探索条件に応じてソート可能にする。例えばユーザが指定した探索条件が最短時間の経路である場合は、保持されているパターンを時間でソートし、最短時間となるパターンの経路を最適経路候補とし、さらに、この最適経路候補との比較で、妥当ないくつか派生する代替経路を特定し、これらの経路を表示装置に表示させる。
【０００４】
携帯電話等の携帯端末、通信ネットワーク及び電子メールが普及した今日では、これらのインフラを利用して経路探索を行う仕組みも種々提案されている。例えば、特許文献１に記載された「出発情報お知らせシステム及び終電情報お知らせシステム」では、現在位置及び移動位置を携帯端末に搭載されたＧＰＳ（測位システム）で測位し、最寄駅に向かって出発すべき時刻、移動経路、最寄り駅の情報をその携帯端末に電子メールで告知する。このシステムでは、携帯端末の表示画面の大きさに限りがあるので、情報を分割して表示する必要がある（特許文献１の段落００１６、図８等参照）。
【０００５】
また、特許文献２に記載された「経路情報配信システム」では、携帯端末の所定の入力画面を通じて出発地情報と目的地情報、送信要求が入力されると、サーバは、出発地情報と目的地情報に基づいて経路探索を実行し、探索結果を保存するとともに、携帯端末の電子メールアドレスに対して、経路情報を記録した「http://www.foobar.com/hogehge?ID=0123abcd 」のようなＵＲＬをメール本文に埋め込んで返信し、ＵＲＬを通じて経路送信要求のあった携帯端末に対してその経路情報を送信する（特許文献２の段落００２２、２３等参照）。このシステムでは、経路情報は、インターネットに接続してＷｅｂサイトにアクセスする必要があるため、条件入力から経路情報を得るまでに時間がかかるという課題が残る。
【０００６】
携帯端末におけるデータ入力環境がパーソナルコンピュータ等と比べて充分でない点を考慮し、特許文献３に記載された「携帯端末装置」のように、電子メール生成時に、位置情報に基づいて場所や時間の粒度を埋め込んだテンプレートを提示し、テンプレートに基づいて電子メールを生成することも行われている。しかし、この携帯端末装置では、テンプレートを用意しておかなければならないため、事前準備が必要となり、汎用性に欠けるという課題が残る。
【０００７】
以上の技術は、電子メールを、経路探索の条件入力あるいは経路情報の伝達に利用するものであるが、条件入力及び結果の出力をすべて電子メールで行う技術も提案されている。例えば特許文献４に記載された「経路案内システム」では、端末から送信された電子メールに含まれる経路探索条件情報に基づいて経路探索を実行し、経路探索結果情報を電子メールで端末に送信するとともに、送信した経路探索結果に基づいて経路案内を実行する案内時刻を設定し、設定した案内時刻に経路案内情報を含む電子メールを端末に送信する。
経路探索の要求又は指示の内容は、電子メールの件名と本文とで判断する。件名が空欄で本文に経路探索条件があるときは新規の経路探索の要求、件名が「Ｒｅ〜」で本文に経路案内メール引用の場合は経路案内の中止の指示、件名が「Ｒｅ〜」で本文に経路探索結果が引用されている場合は同じ経路探索条件での別の経路の再探索の指示、件名が「Ｒｅ〜」で本文が空欄の場合は、探索経路を削除して経路案内を実行しない旨の指示となる（段落００４５〜４７）。
【０００８】
特許文献４のシステムによれば、ユーザは、専用のソフトウェアを組み込んだり、専用の装置を準備しなくても、広く普及している電子メールを利用して経路探索要求し、その結果を電子メールで直ぐに受信できる利点がある。経路案内サービスを提供する事業者にとっても設備投資も抑えることができ、便利である（段落００６３）。
しかし、特許文献４のシステムでは、経路探索の中止や別の経路の再探索の指示を行うときは、本文に経路案内メール又は経路探索結果を引用するので（段落００４５〜４７）、同じパケットが少なくとも１往復されることになり、通信回線を無駄に使うばかりでなく、サーバ側で本文の内容に変更があるかどうかを調べなければならないという課題がある。
また、経路探索結果に時刻の情報が多数存在する場合、ユーザがわざわざ電子メールを送信して指示しない限り、同じ経路についての経路情報を何度も端末に電子メールが送信されるという煩わしさがある。
【先行技術文献】
【非特許文献】
【０００９】
【非特許文献１】「駅すぱあと」風雲録 柏崎ほか 日経ＢＰ社 ２００６年３月２０日発行
【特許文献】
【００１０】
【特許文献１】特開２００２−１３１０７５号公報
【特許文献２】特開２００２−２９６０６７号公報
【特許文献３】特開２００８−０４６８４０号公報
【特許文献４】特開２００７−２３２４４１号公報
【発明の概要】
【発明が解決しようとする課題】
【００１１】
Webのような双方向の媒体の場合、経路探索のための条件入力やその変更は、対話的に得ることができるため容易であるが、基本的に一方向の情報しか得られない電子メールでは、それは難しい。特許文献４についての上記問題は、媒体が電子メールであるために生じる問題である。この問題は、１回の返信メールに多くの情報をまとめて詰め込むことにより緩和される期待がある。
本発明は、かかる背景のもと、ユーザに不便を意識させない利用環境を実現可能にする電子メールによる経路探索の仕組みを提供することを主たる課題とする。
【課題を解決するための手段】
【００１２】
上記課題を解決するため、本発明は、経路探索システム、経路探索方法及びコンピュータプログラムを提供する。
本発明の経路探索システムは、ユーザ端末との間で電子メールの送受信を行う電子メール手段と、自然文で記述された交通機関の経路探索の依頼メールを前記電子メール手段が受信したときに当該依頼メールに対する自然文解析を行うことにより、当該依頼メールから出発地、目的地及び時刻データを含む経路探索条件を抽出する自然言語処理ツールと、前記経路探索条件の入力を契機に、交通機関の路線情報及びダイヤ情報を含む運行情報を格納した運行情報ＤＢにアクセスして前記経路探索を実行することにより、前記経路探索条件に適合する経路候補のダイヤ情報を取得するとともに、この経路候補と同じ路線でその出発地における出発時刻よりも遅い時刻を当該出発地の出発時刻とする１又は複数の代替経路のダイヤ情報、又は、前記経路候補と同じ路線で当該経路候補における目的地の到着時刻よりも早い時刻をその目的地の到着時刻とする代替経路のダイヤ情報を取得する経路探索ツールと、取得した前記経路候補のダイヤ情報と前記代替経路のダイヤ情報とをマージするとともに、マージしたダイヤ情報を、前記出発地と前記目的地との間に登場する途中地の情報と共に、当該経路候補毎に前記ユーザ端末の一つの画面で表示可能な回答文に編集し、編集した回答文を前記電子メール手段を通じて前記ユーザ端末へ返信する制御手段と、を有する。
【００１３】
ユーザ端末から自然文で依頼メールを発信すると、経路探索システムは、自然言語処理ツールでその依頼メールに記述されている経路探索条件を抽出し、経路探索ツールでその経路探索条件に基づく経路候補及びその前後の代替経路のダイヤ情報をマージし、制御手段で、マージしたダイヤ情報を前記ユーザ端末の一つの画面で表示可能な回答文に編集し、編集した回答文を電子メール手段を通じてユーザ端末へ返信するので、ユーザは、経路探索条件を自然文で記述した依頼メールを送信するだけで、経路候補のダイヤ情報と、その経路候補の前後の時間帯の代替経路のダイヤ情報とがマージされた回答文を電子メールで受け取ることができ、１回の電子メールの送受信だけで、数回文の経路探索の結果の受け渡しが可能となる。
【００１４】
自然言語処理ツールは、前記依頼メールにひらがなが含まれるときに、当該ひらがなが、ひらがな以外の文字で表現される前記経路探索条件の構成文字に相当するかどうかを判定し、相当するときは当該ひらがなを当該構成文字に変換した後に前記自然文解析を行う。これにより、ユーザは、ひらがなによる依頼メールを出すことができるので、漢字等への変換作業が不要となり、ユーザの操作負担が軽減される。
【００１５】
ある実施の態様では、ユーザが入力した特定の地域、場所又は施設を表すランドマーク名と、当該ランドマーク名の最寄り駅及びそこまでの到達所要時間とを当該ユーザの識別情報と関連付けて登録するランドマーク登録手段を有しており、前記自然言語処理ツールは、登録されたランドマーク名を前記経路探索条件の構成文字に含めて自然文解析を行う。これにより、駅から離れた場所での経路探索が可能になる。
【００１６】
ある実施の態様では、交通機関の正式の路線名毎に、ユーザが任意に指定した１又は複数の通称路線名を、当該ユーザの識別情報と関連付けて登録する通称路線名登録手段を有しており、前記自然言語処理ツールは、登録された通称路線名を前記経路探索条件と共に前記依頼メールから抽出し、前記経路探索ツールは、前記自然言語処理ツールにより抽出された通称路線名を前記経路候補が複数存在するときの絞り込み条件として使用する。これにより、経路探索結果が複数路線になるときの絞り込みが容易になる。
【００１７】
本発明の経路探索方法は、ユーザ端末と電子メールの送受信を行う装置が実行する方法であって、前記ユーザ端末から、自然文で記述された経路探索の依頼メールを受信する段階と、受信した依頼メールに対する自然文解析を行うことにより、前記依頼メールから出発値、目的地及び時刻データを含む経路探索条件を抽出する段階と、交通機関の路線情報及びダイヤ情報を含む運行情報を格納した運行情報ＤＢにアクセスして、前記抽出した経路探索条件に適合する経路候補のダイヤ情報を取得するとともに、この経路候補と同じ路線でその出発地における出発時刻よりも遅い時刻を当該出発地の出発時刻とする１又は複数の代替経路のダイヤ情報、又は、前記経路候補と同じ路線で当該経路候補における目的地の到着時刻よりも早い時刻をその目的地の到着時刻とする代替経路のダイヤ情報を取得する段階と、取得した前記経路候補及び前記代替経路のダイヤ情報をマージするとともに、マージしたダイヤ情報を、前記出発地と前記目的地との間に登場する途中地の情報と共に、当該経路候補毎に前記ユーザ端末の一つの画面で表示可能な回答文に編集し、編集した回答文を前記電子メール手段を通じて前記ユーザ端末へ返信する段階と、を有する電子メールによる運行経路探索方法である。
【００１８】
本発明のコンピュータプログラムは、コンピュータを、ユーザ端末との間で電子メールの送受信を行う電子メール手段、自然文で記述された交通機関の経路探索の依頼メールを前記電子メール手段が受信したときに当該依頼メールに対する自然文解析を行うことにより、当該依頼メールから出発地、目的地及び時刻データを含む経路探索条件を抽出する自然言語処理ツール、前記経路探索条件の入力を契機に、交通機関の路線情報及びダイヤ情報を含む運行情報を格納した運行情報ＤＢにアクセスして前記経路探索を実行することにより、前記経路探索条件に適合する経路候補のダイヤ情報を取得するとともに、この経路候補と同じ路線でその出発地における出発時刻よりも遅い時刻を当該出発地の出発時刻とする１又は複数の代替経路のダイヤ情報、又は、前記経路候補と同じ路線で当該経路候補における目的地の到着時刻よりも早い時刻をその目的地の到着時刻とする代替経路のダイヤ情報を取得する経路探索ツール、取得した前記経路候補及び前記代替経路のダイヤ情報をマージするとともに、マージしたダイヤ情報を、前記出発地と前記目的地との間に登場する途中地の情報と共に、当該経路候補毎に前記ユーザ端末の一つの画面で表示可能な回答文に編集し、編集した回答文を前記電子メール手段を通じて前記ユーザ端末へ返信する制御手段、として機能させるコンピュータプログラムである。
【発明の効果】
【００１９】
本発明によれば、経路候補毎に、その前後に利用できる列車のダイヤ情報がマージされた回答文がユーザ端末に返信されるので、対話的なインタフェースを持たない場合であっても、経路候補を通るダイヤ情報と、その列車に乗り遅れた場合や余裕を持って移動したい場合の代替ダイヤ情報を１つの乗り換えリストとしてまとめて提示することができ、一方向の情報伝達媒体である電子メールを使用した場合の課題を解決することができる。
すなわち、従来の経路探索サービス／アプリケーションでは、最適乗換情報の提供や、別の列車を使った乗り換え時刻の提供を行うことができたが、これらは経路と列車が独立したダイヤ情報の形で利用者に提供されていた。本発明によれば、これらを有機的に１つの情報としてまとめることができるので、伝達する情報の密度が上がり、電子メールのような一度に限られた対話しかできないインタフェースでも効率的に情報を提供できるようになる。また、従来の経路探索サービス／アプリケーションでは、ユーザが明示的に代替列車を探す必要があったが、本発明によれば、代替列車が最適経路と同時に提供されるため、ユーザは、１回の探索で、代替列車のある安心な経路情報を得ることができる。
代替列車の情報を得る手段として時刻表があるが、目的地までの乗り換え方法を含む路線の情報が得られない。本発明によれば、このような情報も同時に得ることができる。
【図面の簡単な説明】
【００２０】
【図１】本発明を適用した経路探索システムの全体構成図。
【図２】自然言語処理ツールによる自然文解析処理の手順説明図。
【図３】通称路線名を指定して経路候補を絞り込む場合の手順説明図。
【図４】経路候補が絞り込まれた状態を示した説明図。
【図５】ダイヤ検索の手順説明図（概要）。
【図６】ダイヤ検索の手順説明図（時刻バリエーションの拡張処理）。
【図７】ユーザが依頼メールにより経路探索を依頼し、その結果を返信メールで受け取るまでの主制御部の制御手順を示した図。
【図８】ユーザがＷｅｂアクセスにより経路探索の条件を修正して経路探索結果を再取得するときの主制御部の制御手順を示した図。
【図９】経路候補（第１経路）とその代替経路の例を示した図。
【図１０】図９の２つの経路をマージした状態を示した図。
【図１１】依頼メールに含まれる依頼文の例を示した図。
【図１２】携帯端末の表示画面に表示される［経路１］についての経路候補とその代替経路のダイヤ情報を含む回答文の例を示した図。
【図１３】携帯端末の表示画面に表示される［経路２］についての経路候補とその代替経路のダイヤ情報を含む回答文の例を示した図。
【図１４】携帯端末の表示画面に表示される［経路３］についての経路候補とその代替経路のダイヤ情報を含む回答文の例を示した図。
【図１５】Ｗｅｂアクセスにより携帯端末の表示画面に表示される経路探索条件の入力画面。
【発明を実施するための形態】
【００２１】
本発明を、携帯端末向けの交通機関の経路探索サービスを可能にするネットワーク型の経路探索システムに適用した場合の実施の形態例を説明する。
［全体構成］
図１は、この実施形態の経路探索システムの全体構成図であり、特徴的な部分のみを掲示してある。本実施形態では、携帯電話網Ｎ１及びインターネットＮ２に接続され、電子メールとＷｅｂ通信の併用による列車の経路探索サービスを実現する経路探索システム１の例を示す。ユーザは、メール機能及びＷｅｂブラウザ機能を備えた携帯端末３０、例えば携帯電話で、経路探索システム１にアクセスする。
【００２２】
この経路探索システム１は、記憶装置を備えたサーバ本体を有し、このサーバ本体が本発明のコンピュータプログラムを実行することにより、サーバ本体を、主制御部１０、メール送受信部１１、自然言語処理ツール１２、経路探索ツール１３、自然文編集ツール１４、登録ツール１５、通信制御部１６として機能させるとともに、記憶装置内に、ルールＤＢ（ＤＢはデータベースの略、以下同じ）２１、ユーザ情報ＤＢ２２、運行情報ＤＢ２３、駅名候補ＤＢ２４、ランドマークＤＢ２５及び通称路線ＤＢ２６を構築する。
【００２３】
ルールＤＢ２１には、自然言語処理ツール１２が参照する文法ファイル、各種辞書ファイル及び意味解析のための知識ベースと、経路探索条件の候補となる複数の条件候補データを抽出するための抽出ルール及び複数の条件候補データの中から最適条件候補データを選定するための候補選定ルールとが格納されている。条件候補データ及び最適条件候補データは、いずれも経路探索ツール１３に入力する経路探索条件の一つとなり得るものである。
【００２４】
経路探索条件は、複数の構成文字を組み合わせたもの、すなわち、出発地、目的地、経由地、時刻データ、後述するランドマーク名及び路線名（後述する通称路線名を含む）の組み合わせたものである。但し、これらをすべて含んだものが経路探索条件となるのではなく、通常は、一部の組み合わせとなる。必須となるのは、出発地と目的地の組み合わせである。
便宜上、この実施形態において、条件候補データは、出発地、目的地又は経由地となり得る駅名候補データ及びランドマーク名、時刻データ、路線名であるものとする。
【００２５】
条件候補データの抽出ルールは、例えばひらがな／片仮名／ローマ字／混合文字に対応する正式表現名の対応ルール、同名他駅に対応する候補表現（例えば「中野」に対する中野(東京都)、中野(群馬県)、中野(長野県)、中野坂上、中野栄・・・）の対応ルール、経路探索実行依頼と共に経路探索ツール１３に伝えるときの探索条件ルール、すなわち２つの駅名候補データだけ入力されたときは駅間の平均経路の探索と解釈する等である。また、出発地と目的地とを区別する以下のようなルールも抽出ルールに含まれる。
・固有名詞間の助詞
「渋谷から新宿まで」→出発地：渋谷、目的地：新宿
・固有名詞の位置関係
「渋谷新宿」→出発地：渋谷、目的地：新宿
・日本語の係り受け関係
「渋谷を１１時に出発、新宿は到着駅」→出発地：渋谷、目的地：新宿
・名詞間の記号類
「出発：渋谷、到着：新宿」→出発地：渋谷、目的地：新宿
「新宿←渋谷」→出発地：渋谷、目的地：新宿
・他の駅の確定内容に基づく他の駅
「新宿まで、渋谷」→出発地：渋谷、目的地：新宿
・文節の位置関係による強制解決
「渋谷は到着、新宿は到着」→出発地：渋谷、目的地：新宿
「渋谷は出発、新宿から」→出発地：渋谷、目的地：新宿
「池袋から中野まで」→出発地：「池袋」、目的地：「中野(東京都)」
【００２６】
候補選定ルールは、以下のようなものである。
・運行コストが最小となる駅の組み合わせであること
「中野池袋」→「中野」と「池袋」に分断され、「中野」からは「中野(東京都)」、「中野(群馬県)」、「中野(長野県)」、「中野坂上」、「中野栄」が導出されるが、運行コストが最小となるのは、出発地：「中野(東京都)」、到着地：「池袋」である。
・過去に参照した履歴がある場合はそれを利用
「長野の中野から池袋まで」→「中野」は「中野(長野県)」
・鉄道同士、空港同士を最優先
・県同士が最も近い駅の組み合わせを最優先
【００２７】
ユーザ情報ＤＢ２２には、ユーザの固有情報、登録メールアドレス、利用ログ等が、ユーザＩＤ等により相互に関連付けて格納される。
【００２８】
運行情報ＤＢ２３には、交通機関（鉄道／バス／航空機）の路線、ダイヤ情報（時刻情報）、運賃情報、駅リストを含む、運行経路の探索に必要なすべての運行情報が格納される。この運行情報は、随時更新される。
【００２９】
駅名候補ＤＢ２４には、自然言語処理ツール１２による自然文解析により特定されたすべての駅名候補データが格納される。これらのデータは、携帯端末３０から電子メールを受信したときに採番される探索ＩＤと関連付けて格納される。読み出すときは、この探索ＩＤを読み出しキーとして用いる。
【００３０】
ランドマークＤＢ２５には、ユーザが任意に選定した場所、施設等をランドマーク名で表し、そこからの最寄駅及びそこまでの移動所要時間が、ユーザの固有情報と関連付けて格納される。例えば、株式会社ヴァル研究所の固有情報と関連付けて「ヴァル」というランドマーク名を登録し、この「ヴァル」について、最寄駅が高円寺駅、そこまでの移動所要時間が徒歩６分という情報を登録する。ランドマーク名は、経路探索時に、駅名候補データと同様に扱われ、最寄駅からの距離が長いときの総所要時間、最寄駅が複数あるときの最適経路の選択等のために用いられる。
【００３１】
通称路線ＤＢ２６には、正式な路線名（例えば「ＪＲ中央・青梅線青梅特快」）と、ユーザが覚えやすい任意の通称名（例えば「ＪＲ線」又は「青梅線」）とをユーザの固有情報と関連付けて格納される。携帯端末３０では、表示画面上に多くの経路を表示できないため、使用したい路線のイメージがあっても、その経路を見つけるのが困難となる。路線名を経路探索条件（絞り込みの条件）として指定したい場合であっても、正式な路線名（表示される路線名）をユーザが正確に入力するのは難しい。そこで、一つの正式な路線名に対して、その路線名を簡略化した通称路線名を複数件対応付けて登録しておき、一つの正式路線名を様々な名前で指定できるようにした。通称路線名はシステム中、一意でなくても良い。ユーザが指定した通称路線名から複数の正式路線名を対等に扱うことで、経路探索結果の絞り込みを容易にすることができる。
【００３２】
主制御部１０は、経路探索に関する各種処理を実現するために以下の各機能ブロック１１〜１６の起動を含む動作の制御を行う。制御手順については、後述する。
【００３３】
メール送受信部１１は、携帯電話網Ｎ１を介して携帯端末３０との間で、登録メールアドレスを用いた電子メールの受け渡しを行う。以後、経路探索の依頼文を含む電子メールを依頼メール、その回答文を含む電子メールを返信メールとする。
受信時は、依頼メールのヘッダ部からユーザの登録メールアドレスを抽出し、これを図示しないアドレステーブルに一時的に記録する。返信時は、このアドレステーブルに記録されている登録メールアドレス宛に返信メールを送信する。通信制御部１６は、後述する権限情報に基づきインターネットＮ２を介してアクセスした携帯端末３０に対してＷｅｂサービスを提供するための制御を行う。
【００３４】
自然言語処理ツール１２は、メール送受信部１１で受信した依頼メールの例えば本文部に記述されている依頼文に対してルールＤＢ２１に格納されている文法ファイル、辞書ファイル、知識ベース、各種ルールに基づき、自然文解析処理を施し、複数の駅名候補データ、時刻データ等を抽出する。
【００３５】
［自然文解析処理］
図２は、自然言語処理ツール１２による自然文解析処理の手順説明図である。ここでは「３時に東京からヴァル」という自然文（一部半角文字、登録されたランドマーク有り）が入力されたものとする。
自然言語処理ツール１２は、まず、前処理で表記統制を行う。表記統制は、半角文字を全角文字にしたり、バイナリや改行を削除したり、文字数を指定文字数でカットする処理である。これにより、構文解析の文法を簡易なものにすることができる。
【００３６】
その後、ひらがなクエリー判定を行う。この処理は、依頼文をクエリー（コンピュータが認識できる要求コマンド）とし、ひらがなのクエリーを駅名（又はランドマーク）を表す構成文字として解釈する（抽出する）処理である。また、抽出した駅名候補データが１個の場合は用途不明、駅名候補データが２個の場合は出発地と目的地があると解釈する。駅名候補データが３個の場合は出発地、経由地、目的地があると解釈する。ひらがなクエリー判定後、ランドマーク名変換を行う。ランドマーク変換は、クエリーからランドマーク名を探し、そのランドマーク名を形態素解析用の文字列に変換する処理である。
【００３７】
以上の一連の処理を終えた後、日本語解析を行う。日本語解析は、クエリーの文章を日本語の形態素と文節の並びに変換する処理である。本実施形態では、形態素を語句ＩＤに変換して図示しないメモリ領域に記憶する。その結果、日本語解析の結果は、語句ＩＤの並びとなる。語句ＩＤとは、ルールＤＢ２１に格納されている文法ファイルに出現する語句に対し、出現順に数値を割り当てたものである。ＩＤ化して扱うことにより、非常に大きな負荷がかかる駅名候補データの抽出処理を高速に行うことができる。
【００３８】
日本語解析を終えると、自然言語処理ツール１２は、共に日本語解析結果を取得し、ルールＤＢ２１の辞書ファイルを用いて格候補抽出を行う。「格」は形態素や文節に意味を与えるためのものであり（「彼が」はガ格、「彼を」はヲ格）、「格候補」は「格」を形成し得る文節のまとまりをすべての可能性に対して抽出したデータの構造をいう。候補として扱うため、最終的に「格」として選択されないものも抽出する。例えば、「東京」は場所名のほか「東京駅」とも解釈され得るため、２つの格候補が抽出される。３時は「ｈ＝３」のように表現を統一する。
【００３９】
格候補抽出後は、署名格候補を削除する。署名は電子メールの本文部の最後に記載される定型文である。「品川太郎」のように、駅名ともとれる人名又は住所表記があると駅名候補データと誤認識するおそれがあるため、署名と思われる行から格候補を削除する。その後、格候補最適化を行う。すなわち、抽出した格候補をどのように組み合わせれば、一文全体で最適な解釈となるかを総当たりで評価する。このようにして確定した格候補について、意味解析を行う。ここでは、特に、時刻と日付の解釈を行い、具体的な日時を数値で表現する。その結果、自然言語処理ツール１２からは、図右側上段の出力が得られる。
【００４０】
このようにして、依頼メールに含まれる語、語句、文を抽出し、抽出した語、語句又は文とルールＤＢ２１に格納されている条件候補の抽出ルールに基づいて、複数の駅名候補データを抽出する。路線名や時刻データが含まれているときは、これらも抽出する。また、ルールＤＢ２１に格納されている候補選定ルールに基づいて複数の駅名候補データの組み合わせ（路線、時刻データが含まれている場合はこれらも加えた組み合わせ）のうち、上記条件選定ルールに従えば最もあり得るいずれか一組を、ユーザの意図を反映していると推定される最適な駅名候補データの組み合わせである経路探索条件として選定する。
【００４１】
［経路探索］
経路探索ツール１３は、経路探索条件の入力を契機に、運行情報ＤＢ２３、ランドマークＤＢ２５及び通称路線ＤＢ２６に蓄積されている情報をもとに、交通機関による運行コストが最も小さい次の駅（又はランドマーク名）の探索処理を、水面に石を投げたときの波紋のように連鎖的に繰り返すことにより、経路探索条件に従う経路候補及びそのダイヤ情報を特定する。運行コストは通常は時間を対象とするが、距離、運賃を用いても良く、あるいは、これらの組み合わせを対象としても良い。経路探索ツール１３は、推論エンジンも搭載しており、探索途中で現実的でない経路となることが判明した場合は、その経路についての次の駅以降の探索を止める。なお、経路探索ツール１３のうち、経路探索機能の部分は、例えば本願出願人が提供している経路探索ソフトウエア「駅すぱあと」（登録商標）のものを使用することができる。
【００４２】
本実施形態では、自然言語処理ツール１２が、上記のようにして依頼文から抽出した複数の駅名候補データ（存在する場合は路線名や時刻データを含む）のうち、最適な組み合わせを経路探索条件として、経路探索ツール１３に入力するが、経路候補が多数になる場合は、通称路線名で経路候補を絞り込む。
【００４３】
このことを図３及び図４を参照して詳しく説明する。
通称名称ＤＢ２６には、予め表示に使用する正式な路線名称から通称路線名を複数個登録しておくことは、上述の通りである。ユーザは、経路探索を行うときに、図３に示すように、出発地、目的地のほかに、使いたい路線名を通称路線名で指定する（ステップＳ１１）。経路探索ツール１３は、経路探索を行い（ステップＳ１２）、複数の経路候補を特定する過程で（ステップＳ１３）、通称路線ＤＢ２６へアクセスして通称路線名検索を行い（ステップＳ１４）、ユーザが指定した通称路線名に一致した通称路線名に関連付けられたすべての正式路線名を取得する（ステップＳ１５）。そして、ステップＳ１３で特定した複数の経路候補を、取得した正式路線名を含む経路候補のみに絞り込み（ステップＳ１６）、絞り込んだ経路候補を探索結果として出力する（ステップＳ１７）。
【００４４】
図４の例でいえば、ユーザが通称路線名Ａを指定したとすると、通称路線ＤＢ２６から通称路線名Ａに関連付けられた正式路線名＃１と正式路線名＃２とを取得する。経路探索結果として「経路＃１」、「経路＃２」、「経路＃３」が特定され、「経路＃１」には正式路線名＃３と正式路線名＃４が含まれ、「経路＃２」には正式路線名＃１と正式路線名＃５が含まれ、「経路＃３」には正式路線名＃６が含まれていたとすると、絞り込みにより、「経路＃２」のみが探索結果として出力される。
なお、以上は、ユーザが指定した経路候補を使用する場合の例であるが、指定した経路候補を使用しない場合には、正式路線名を含む経路候補を出力しないようにすれば良い。
【００４５】
経路候補及びそのダイヤ情報を特定すると、経路探索ツール１３は、その経路候補の代替経路についてのダイヤ検索を行う。このダイヤ検索の手順を図５及び図６を参照して説明する。
図５を参照すると、経路探索ツール１３は、経路候補のダイヤ検索結果を取得する（ステップＳ１）。検索結果の最後の経路まで処理した場合は終了する（ステップＳ２：Yes）。検索結果の最後の経路まで処理していない場合は（ステップＳ２：No）、処理済の路線かどうかを判定し、処理済であればステップＳ２の処理に移る（ステップＳ３：Yes）。処理済の路線でなければ、時刻バリエーションの拡張処理を行う（ステップＳ３：No、Ｓ４）。
【００４６】
時刻バリエーションの拡張処理は、図６の手順で行われる。
すなわち、元の経路、つまり上述した経路候補と同一の路線における一つ前の最適ダイヤ（到着時刻−１分以前、−６０分までに到着できる効率的なダイヤ）、または、次の最適ダイヤ（出発時刻＋１分以降、＋６０分までに出発する効率的なダイヤ）となるようなダイヤ検索結果を取得し、これを代替経路のダイヤ情報とする（ステップＳ４１）。元の経路（経路候補）より取得したダイヤ検索結果の最後の列車まで処理したかどうかを判定し、処理した場合、つまり、代替経路が無い場合は終了する（ステップＳ４２：Yes）。最後の列車まで処理していない場合は、代替経路があることを意味するので、マージ（ダイヤ情報の統合）の対象になるかどうかを判定する（ステップＳ４２：Yes、Ｓ４３）。
マージ対象となるのは、料金、通過駅一覧（停車するかどうかを問わず）、営業距離が一致し、且つ、初めの出発時刻から６０分以内であることが条件となる。マージ対象となる場合は、元の経路である経路候補に代替経路のダイヤ情報をマージする（ステップＳ４３：Yes、Ｓ４４）。他方、マージ対象とならない場合は、新たに見つかった別経路（別の行き方）としてこのダイヤ情報を保持する（ステップＳ４３：No、Ｓ４５）。
以上の手順を表示時刻数分のダイヤ情報が揃うまで繰り返し（ステップＳ４６：No）、揃った場合は終了する（ステップＳ４６：Yes）。
【００４７】
図５に戻り、時刻バリエーションの拡張処理後は、予め設定された表示経路数分のダイヤ情報が揃ったかどうかを判定する（ステップＳ５）。揃った場合は終了する（ステップＳ５：Yes）。揃わない場合は、時刻バリエーション拡張処理で新たに別経路が見つかったかどうかを調べる（ステップＳ５：No、Ｓ６）。見つかっていない場合はステップＳ２の処理に戻る（ステップＳ６：No）。見つかった場合は、ダイヤ検索結果の経路に新たに見つかった別経路を追加してステップＳ２の処理に戻る（ステップＳ６：Yes、Ｓ７）。
これにより、最適経路とその１本前又は１本後のように、幅のあるダイヤ情報を、電子メールという一方向の情報伝達媒体を使用する場合においても利用者にとって違和感のない形で提供することができる。
【００４８】
経路探索の結果、出発地と目的地とが同じであっても、ダイヤ構築の関係上、常に同じ経路にならず、経路候補が複数になる場合がある。この場合は、運行コストが小さい順に「経路１」、「経路２」、「経路３」のように特定し、各々の経路において上記代替経路のダイヤ情報を特定する。例えば、新宿から横浜に行く場合の例を挙げる。利用者は、出発時間帯、予算、好みなどに応じて、以下の数通りの経路を選択することができる。
新宿→(ＪＲ)→横浜
新宿→(ＪＲ)→渋谷→(東急)→横浜
新宿→(ＪＲ)→品川→(京急)→横浜
新宿→(ＪＲ)→東京→(ＪＲ)→横浜
新宿→(ＪＲ)→東京→(特急)→横浜
本実施形態では、これらの経路の各々を経路候補とし、各経路候補のそれぞれについて、上述した代替経路のダイヤ情報を特定する。
【００４９】
自然文編集ツール１４は、経路探索ツール１３により特定された経路候補及び代替経路のダイヤ情報を一つのダイヤ情報にマージする。
ここで、マージの意味合いを具体的に説明する。便宜上、東京発、沼津到着の例を挙げる。図９左側は経路候補、右側はその代替経路（便宜上、その１本後の列車とする）である。図９の例では、「ＪＲ快速アクティー・熱海行き」と「ＪＲ東海道本線」は、利用者は同じ路線と認識するが、従前の経路探索技術では、１本違うだけの列車であっても別経路と認識する。そのため、これらを単純に一つの画面に表示することはできない。仮に一つの画面に表示できたとしても、利用者の感覚からすれば、違和感のある探索結果となる場合があり、この場合は実用性が低下するおそれがある。
本実施形態では、上述したマージ対象かどうかの基準に従い、各ダイヤ情報を経路候補毎にマージするとともに、マージしたダイヤ情報を、出発駅と目的駅との間に登場する途中駅の情報と共に、経路候補毎に一つの画面で表示できるように編集する。通過駅については表示されないようにする。その結果、図９の２つの経路のダイヤ情報は、図１０のようにマージされる。
経路候補が複数となる場合は、それぞれの経路候補のダイヤ情報について代替経路のダイヤ情報とマージし、それらを一つの画面で表示することができるようにする。これにより、情報の網羅性についての利点がある。このマージされた各情報を初期探索結果とする。
【００５０】
その後、初期探索結果、探索ＩＤ、及び、依頼メールの発信元が経路探索ツール１３に事後的にＷｅｂ通信によりアクセスするための権限情報を、携帯端末３０の一つの画面に表示させる回答文として編集し、この回答文を含む返信メールを作成する。このとき、携帯端末３０のディスプレイは小さいし、解像度も低いので、余分な情報を取り除き、なるべく少ないパケット数で且つなるべく一画面で表示することができ、しかし必要な情報は盛り込むように編集する。この返信メールは、メール送受信部１１から依頼メールの発信元に返信される。
【００５１】
登録ツール１５は、ユーザの固有情報、メールアドレス、ランドマーク名、通称路線名、各種ルール、サービス条件設定等の登録を受け付ける。登録したユーザの固有情報は、ユーザ情報ＤＢ２２に格納される。登録されたメールアドレスが登録メールアドレスとなる。ランドマーク名はランドマークＤＢ２５に格納される。通称路線名は通称路線ＤＢ２６に格納される。
【００５２】
［運用形態］
次に、上記のように構成される経路探索システム１の運用形態例を説明する。
【００５３】
ユーザは、登録メールアドレスを用いて経路探索システム１の専用アドレスに依頼メールを発信することによって、経路探索システム１は動作を開始する。本例では、図１１に示すように、ユーザが、「ヴァル つくばエクスプレス 浅草」のような依頼文を記述した依頼メールを発信したものとする。「ヴァル」は、ＪＲの高円寺駅までの移動所要時間が５分の株式会社ヴァル研究所のランドマーク名、つくばエクスプレスは路線である。このランドマーク名も駅名候補データの一つとして扱われる。
【００５４】
主制御部１０は、図７の手順で制御動作を開始する。すなわち、この依頼メールを受信すると（ステップＳ１０１：Yes）、発信元の登録メールアドレスをアドレスメモリ（図示省略）に記録する（ステップＳ１０２）。また、その依頼メールに対して探索ＩＤを採番し（ステップＳ１０３）、この探索ＩＤを駅名候補ＤＢ２４に格納する（ステップＳ１０４）。
【００５５】
探索ＩＤを格納すると、主制御部１０は、自然言語処理ツール１２を起動する。自然言語処理ツール１２は、依頼メールに記述されている依頼文に対して自然文解析を行うことにより、複数の駅名候補データを抽出する。そして、抽出した複数の駅名候補データを、駅名候補ＤＢ２４に格納されている探索ＩＤと関連付けて保存する（ステップ１０５）。保存が終了すると、自然言語処理ツール１２は、複数の駅名候補データの組み合わせのうち、最適条件候補データとなる一組の駅名候補データを選定する。
【００５６】
本例の場合、最適条件候補データは、出発地が「ヴァル（ランドマーク名）」、路線が「つくばエクスプレス」、目的地が「浅草駅」として選定される。最適条件候補データが選定されると、駅名候補ＤＢ２４に記憶されている駅名候補データのうち、該当する駅名候補データに選定済のタグを付与するとともに、最適条件候補データを経路探索条件として経路探索ツール１３に入力する（ステップＳ１０６）。タグは、例えば「ヴァル」が出発地として再度選定されないようにするためものであるが、不可欠なものではない。
【００５７】
経路探索ツール１３から経路探索結果を受け取ると（ステップＳ１０７:Yes）、主制御部１０は、自然文編集ツール１４を起動する。自然文編集ツール１４は、経路探索結果に含まれる経路候補及び代替経路のダイヤ情報をマージしたものと、ユーザ端末３０からＷｅｂ通信により経路探索ツール１３にアクセスするための権限情報及び探索ＩＤと共に、メール用の回答文として編集する（ステップＳ１０８）。権限情報は、登録されたユーザの固有情報及び上記の探索ＩＤをパラメータ化し、これを経路探索ツール１３のＵＲＬ（Uniform Resource Locator）とセットにしたものを用いる。
【００５８】
自然文編集ツール１４により回答文が編集されると、主制御部１０は、メール送受信部１１を制御し、発信元の登録メールアドレスを読み出し（ステップＳ１０９）、回答文を発信元の登録メールアドレス宛に返信する（ステップＳ１１０）。
【００５９】
返信メールに含まれる回答文は、図１２〜図１４に例示されるものとなる。図１２の例では、携帯端末３０の表示画面５０に、［経路１］についての経路候補とその代替経路のダイヤ情報が示されている。図１３は［経路２］についての経路候補とその代替経路のダイヤ情報、図１４は［経路３］についての経路候補とその代替経路のダイヤ情報である。ユーザの意図に沿わない経路探索条件であったかどうかは、［経路１］についての探索結果で直ちにわかるので、最初の表示画面５０の最下部に、権限情報５２が記述されている。
【００６０】
ユーザは、図１２〜図１４の表示画面が自分の意図したものであった場合は、何のアクションを起こさずとも、経路探索のための一連の処理は完結する。つまり、ユーザによる自然文による１回の電子メールの送信及びそれに因る自動応答による返信メールにより、ユーザの目的は達成されるので、例えば特許文献４のシステムのように、本文に経路案内メールを引用して返信する必要がなくなり、操作が簡略化されるだけでなく、通信リソースの浪費も回避される。
【００６１】
他方、意図しない探索結果であったときは、図１２の表示画面５０の最下段に記述されている権限情報５２の部分にカーソルを合わせ、クリックすることにより、ネットワークＮ２及び通信制御部１６を介して経路探索ツール１３に、シームレスにＷｅｂアクセスすることができる。図８は、Ｗｅｂアクセス時の主制御部１０の処理手順図である。
【００６２】
図８において、主制御部１０は、携帯端末３０からのアクセス（Ｗｅｂアクセス）を検知すると（ステップＳ２０１：Yes）、経路探索条件の入力画面を携帯端末３０の画面に表示させる（ステップＳ２０２）。このとき、駅名候補ＤＢ２４に記憶され、探索ＩＤにより特定される駅名候補データを駅名候補ＤＢ２４より読み出し、これらを出発地別、経由地別、目的地別、路線別に、それぞれカーソルで選択できるようにする（ステップＳ２０３）。
【００６３】
図１５は、経路探索条件の入力画面例である。表示画面５０には、４つの入力領域が形成されている。各入力領域からは、既に抽出された駅名候補データ（ランドマーク名を含む）や路線を選択できるようになっている。デフォルトとして、先頭データすなわち最適な駅名候補データが自動的に記入される。経由地及び路線については必須入力条件ではないので、「指定せず」が含まれている。「指定せず」が選択されたときはその条件は無いものとして扱われる。
【００６４】
ユーザが、カーソル操作で、各入力領域について目的の駅名候補データを一つ選択し、表示画面５０の実行ボタン画像５５をクリックして指示すると（ステップＳ２０４：Yes）、主制御部１０は、変更された経路探索条件を経路探索ツール１３に入力する（ステップＳ２０５）。その後、主制御部１０は、Ｗｅｂ通信（Ｗｅｂアクセス）を終了させる（ステップＳ２０６）。その後の処理手順は、図７のステップＳ１０７以降と同じとなる。つまり、ユーザは、自分の意図通りの経路探索結果を、図１２〜図１４のような回答文をその内容とする返信メールにより受け取ることができる。
なお、条件変更後の経路探索結果を再度の返信メールではなく、Ｗｅｂ通信を維持した状態で表示画面５０に表示させるようにしても良い。
【００６５】
このように、本実施形態の経路探索システム１では、ユーザにとって使い方が曖昧である日本語の自然文であっても、駅名候補データが得られた段階ですべての駅名候補データを駅名候補ＤＢ２４へ保存しておき、自然言語処理ツール１２の解釈が誤っていた場合に、Ｗｅｂ通信を使ってユーザが本来意図していた駅名候補データを選択できるようにしたので、電子メールによる経路探索の利便性をＷｅｂ通信により補完することができる。現在確立されている自然言語処理技術では必ずしも完全な結果が得られないが、本実施形態によれば、返信メールを受け取った後に、さらに解釈を変更できるという、従来技術からは得られない効果が期待される。
【００６６】
本実施形態では、また、自然言語処理ツール１２が、ひらがなクエリー判定を行うことで、依頼メールにひらがなが含まれるときであっても、当該ひらがなを漢字等の本来表現の文字に変換した後に自然文解析を行うようにしたので、依頼文の作成に際して文字変換の作業が軽減される。
【００６７】
本実施形態では、また、経路候補とその前後に利用できる代替経路のダイヤ情報が１つの表示画面５０でマージされて表示されるので、対話的なインタフェースを持たない場合においても、経路案内情報を効率的に提供することができる。
【００６８】
本実施形態では、また、ユーザが入力した特定の地域、場所又は施設を表すランドマーク名と、ランドマーク名の最寄り駅及びそこまでの到達所要時間とを当該ユーザの識別情報と関連付けてランドマークＤＢ２５を備え、自然言語処理ツール１２が、登録されたランドマーク名を出発地、経由地又は目的地の一つに含めて自然文解析を行うようにしたので、依頼文にユーザ独自の施設名等を含めた条件の指定を迅速に行うことができる。携帯端末３０の場合、文字を入力する行為そのものが煩わしく、できるだけ短い語で経路探索の条件を入力することが望ましいが、本実施形態によれば、それが可能となる。ランドマーク名は、自宅、会社、友人宅などのプライベートな施設であっても良いので、ユーザに特化した経路探索が可能となる。
【００６９】
本実施形態では、さらに、交通機関の正式の路線名毎に、ユーザが任意に指定した１又は複数の通称路線名を、当該ユーザの識別情報と関連付けて通称路線ＤＢ２６に登録しておき、経路探索ツール１３が、登録されたいずれかの通称路線名を経路候補が複数存在するときの絞り込み条件として使用するようにしたので、ユーザの好みに応じた探索結果の「絞り込み」が可能となる。特に携帯端末３０の場合、操作環境が充分でなく、かつ、表示画面５０に多くの経路を表示できないので、使用したい路線のイメージがあっても、その経路を見つけるのは困難であるが、本実施形態によれば、それが容易となる。
【００７０】
なお、本実施形態では、曖昧性を持つ自然文の解釈が１つに定まらないという問題を解消する手段であることを前提として説明したが、依頼メールからの語句の切り出し領域のずれ等により、駅名以外の文字が誤って駅名候補データと認識された場合についても、正しい駅名候補データに解釈を変更する手続きとして、本発明を適用することもできる。
【００７１】
また、本実施形態では、条件候補データの一つとして駅名候補データを用いた場合の例を示したが、交通機関としてバスを組み込む場合は、駅名候補データはバス停候補データとなり、航空機をも組み込む場合は、駅名候補データは空港名候補データとなる。
【００７２】
また、本実施形態では、携帯端末３０の電子メールを用いて経路探索サービスを提供する場合の例を説明したが、パーソナルコンピュータによる電子メールを用いることもできる。
【符号の説明】
【００７３】
１・・・経路探索システム、１０・・・主制御部、１１・・・メール送受信部、１２・・・自然言語処理ツール、１３・・・経路探索ツール、１４・・・自然文編集ツール、１５・・・登録ツール、１６・・・通信制御部、２１・・・ルールＤＢ、２２・・・ユーザ情報ＤＢ、２３・・・運行情報ＤＢ、２４・・・駅名候補ＤＢ、２５・・・ランドマークＤＢ、２６・・・通称路線ＤＢ、３０・・・携帯端末、５０・・・表示画面、５２・・・権限情報、５５・・・実行ボタン画像、Ｎ１・・・携帯電話網、Ｎ２・・・インターネット。
【技術分野】
【０００１】
本発明は、ユーザにとって快適な交通機関の経路探索環境を実現可能にする電子メールを用いた経路探索技術に関する。
【背景技術】
【０００２】
列車等の交通機関における最適な運行経路の探索技術については、昭和時代に本願出願人により開発され、多くのユーザの支持を得た経路探索ソフト「駅すぱあと」(登録商標、非特許文献１参照）の登場以来、複数の企業技術者の手により幾多の改良・改善が試みられてきた。交通機関の経路探索において、出発地及び目的地が指定されたときの探索処理は、概ね以下のように行われている。
【０００３】
出発地に繋がるすべての路線（交通機関が、ある地点から他地点に至る経路）、駅について、経路の運行コスト（時間、距離、運賃等）が最小となる次の駅の探索処理を連鎖的に繰り返すことで、水面に石を投げたときの波紋のような形態で経路探索を行う。探索過程で目的地が特定された場合、その目的地と出発地との間の経路をユーザが望む経路候補とするとともに、さらにそこから派生する経路候補を多数パターン探索して保持し、ユーザが指定した探索条件に応じてソート可能にする。例えばユーザが指定した探索条件が最短時間の経路である場合は、保持されているパターンを時間でソートし、最短時間となるパターンの経路を最適経路候補とし、さらに、この最適経路候補との比較で、妥当ないくつか派生する代替経路を特定し、これらの経路を表示装置に表示させる。
【０００４】
携帯電話等の携帯端末、通信ネットワーク及び電子メールが普及した今日では、これらのインフラを利用して経路探索を行う仕組みも種々提案されている。例えば、特許文献１に記載された「出発情報お知らせシステム及び終電情報お知らせシステム」では、現在位置及び移動位置を携帯端末に搭載されたＧＰＳ（測位システム）で測位し、最寄駅に向かって出発すべき時刻、移動経路、最寄り駅の情報をその携帯端末に電子メールで告知する。このシステムでは、携帯端末の表示画面の大きさに限りがあるので、情報を分割して表示する必要がある（特許文献１の段落００１６、図８等参照）。
【０００５】
また、特許文献２に記載された「経路情報配信システム」では、携帯端末の所定の入力画面を通じて出発地情報と目的地情報、送信要求が入力されると、サーバは、出発地情報と目的地情報に基づいて経路探索を実行し、探索結果を保存するとともに、携帯端末の電子メールアドレスに対して、経路情報を記録した「http://www.foobar.com/hogehge?ID=0123abcd 」のようなＵＲＬをメール本文に埋め込んで返信し、ＵＲＬを通じて経路送信要求のあった携帯端末に対してその経路情報を送信する（特許文献２の段落００２２、２３等参照）。このシステムでは、経路情報は、インターネットに接続してＷｅｂサイトにアクセスする必要があるため、条件入力から経路情報を得るまでに時間がかかるという課題が残る。
【０００６】
携帯端末におけるデータ入力環境がパーソナルコンピュータ等と比べて充分でない点を考慮し、特許文献３に記載された「携帯端末装置」のように、電子メール生成時に、位置情報に基づいて場所や時間の粒度を埋め込んだテンプレートを提示し、テンプレートに基づいて電子メールを生成することも行われている。しかし、この携帯端末装置では、テンプレートを用意しておかなければならないため、事前準備が必要となり、汎用性に欠けるという課題が残る。
【０００７】
以上の技術は、電子メールを、経路探索の条件入力あるいは経路情報の伝達に利用するものであるが、条件入力及び結果の出力をすべて電子メールで行う技術も提案されている。例えば特許文献４に記載された「経路案内システム」では、端末から送信された電子メールに含まれる経路探索条件情報に基づいて経路探索を実行し、経路探索結果情報を電子メールで端末に送信するとともに、送信した経路探索結果に基づいて経路案内を実行する案内時刻を設定し、設定した案内時刻に経路案内情報を含む電子メールを端末に送信する。
経路探索の要求又は指示の内容は、電子メールの件名と本文とで判断する。件名が空欄で本文に経路探索条件があるときは新規の経路探索の要求、件名が「Ｒｅ〜」で本文に経路案内メール引用の場合は経路案内の中止の指示、件名が「Ｒｅ〜」で本文に経路探索結果が引用されている場合は同じ経路探索条件での別の経路の再探索の指示、件名が「Ｒｅ〜」で本文が空欄の場合は、探索経路を削除して経路案内を実行しない旨の指示となる（段落００４５〜４７）。
【０００８】
特許文献４のシステムによれば、ユーザは、専用のソフトウェアを組み込んだり、専用の装置を準備しなくても、広く普及している電子メールを利用して経路探索要求し、その結果を電子メールで直ぐに受信できる利点がある。経路案内サービスを提供する事業者にとっても設備投資も抑えることができ、便利である（段落００６３）。
しかし、特許文献４のシステムでは、経路探索の中止や別の経路の再探索の指示を行うときは、本文に経路案内メール又は経路探索結果を引用するので（段落００４５〜４７）、同じパケットが少なくとも１往復されることになり、通信回線を無駄に使うばかりでなく、サーバ側で本文の内容に変更があるかどうかを調べなければならないという課題がある。
また、経路探索結果に時刻の情報が多数存在する場合、ユーザがわざわざ電子メールを送信して指示しない限り、同じ経路についての経路情報を何度も端末に電子メールが送信されるという煩わしさがある。
【先行技術文献】
【非特許文献】
【０００９】
【非特許文献１】「駅すぱあと」風雲録 柏崎ほか 日経ＢＰ社 ２００６年３月２０日発行
【特許文献】
【００１０】
【特許文献１】特開２００２−１３１０７５号公報
【特許文献２】特開２００２−２９６０６７号公報
【特許文献３】特開２００８−０４６８４０号公報
【特許文献４】特開２００７−２３２４４１号公報
【発明の概要】
【発明が解決しようとする課題】
【００１１】
Webのような双方向の媒体の場合、経路探索のための条件入力やその変更は、対話的に得ることができるため容易であるが、基本的に一方向の情報しか得られない電子メールでは、それは難しい。特許文献４についての上記問題は、媒体が電子メールであるために生じる問題である。この問題は、１回の返信メールに多くの情報をまとめて詰め込むことにより緩和される期待がある。
本発明は、かかる背景のもと、ユーザに不便を意識させない利用環境を実現可能にする電子メールによる経路探索の仕組みを提供することを主たる課題とする。
【課題を解決するための手段】
【００１２】
上記課題を解決するため、本発明は、経路探索システム、経路探索方法及びコンピュータプログラムを提供する。
本発明の経路探索システムは、ユーザ端末との間で電子メールの送受信を行う電子メール手段と、自然文で記述された交通機関の経路探索の依頼メールを前記電子メール手段が受信したときに当該依頼メールに対する自然文解析を行うことにより、当該依頼メールから出発地、目的地及び時刻データを含む経路探索条件を抽出する自然言語処理ツールと、前記経路探索条件の入力を契機に、交通機関の路線情報及びダイヤ情報を含む運行情報を格納した運行情報ＤＢにアクセスして前記経路探索を実行することにより、前記経路探索条件に適合する経路候補のダイヤ情報を取得するとともに、この経路候補と同じ路線でその出発地における出発時刻よりも遅い時刻を当該出発地の出発時刻とする１又は複数の代替経路のダイヤ情報、又は、前記経路候補と同じ路線で当該経路候補における目的地の到着時刻よりも早い時刻をその目的地の到着時刻とする代替経路のダイヤ情報を取得する経路探索ツールと、取得した前記経路候補のダイヤ情報と前記代替経路のダイヤ情報とをマージするとともに、マージしたダイヤ情報を、前記出発地と前記目的地との間に登場する途中地の情報と共に、当該経路候補毎に前記ユーザ端末の一つの画面で表示可能な回答文に編集し、編集した回答文を前記電子メール手段を通じて前記ユーザ端末へ返信する制御手段と、を有する。
【００１３】
ユーザ端末から自然文で依頼メールを発信すると、経路探索システムは、自然言語処理ツールでその依頼メールに記述されている経路探索条件を抽出し、経路探索ツールでその経路探索条件に基づく経路候補及びその前後の代替経路のダイヤ情報をマージし、制御手段で、マージしたダイヤ情報を前記ユーザ端末の一つの画面で表示可能な回答文に編集し、編集した回答文を電子メール手段を通じてユーザ端末へ返信するので、ユーザは、経路探索条件を自然文で記述した依頼メールを送信するだけで、経路候補のダイヤ情報と、その経路候補の前後の時間帯の代替経路のダイヤ情報とがマージされた回答文を電子メールで受け取ることができ、１回の電子メールの送受信だけで、数回文の経路探索の結果の受け渡しが可能となる。
【００１４】
自然言語処理ツールは、前記依頼メールにひらがなが含まれるときに、当該ひらがなが、ひらがな以外の文字で表現される前記経路探索条件の構成文字に相当するかどうかを判定し、相当するときは当該ひらがなを当該構成文字に変換した後に前記自然文解析を行う。これにより、ユーザは、ひらがなによる依頼メールを出すことができるので、漢字等への変換作業が不要となり、ユーザの操作負担が軽減される。
【００１５】
ある実施の態様では、ユーザが入力した特定の地域、場所又は施設を表すランドマーク名と、当該ランドマーク名の最寄り駅及びそこまでの到達所要時間とを当該ユーザの識別情報と関連付けて登録するランドマーク登録手段を有しており、前記自然言語処理ツールは、登録されたランドマーク名を前記経路探索条件の構成文字に含めて自然文解析を行う。これにより、駅から離れた場所での経路探索が可能になる。
【００１６】
ある実施の態様では、交通機関の正式の路線名毎に、ユーザが任意に指定した１又は複数の通称路線名を、当該ユーザの識別情報と関連付けて登録する通称路線名登録手段を有しており、前記自然言語処理ツールは、登録された通称路線名を前記経路探索条件と共に前記依頼メールから抽出し、前記経路探索ツールは、前記自然言語処理ツールにより抽出された通称路線名を前記経路候補が複数存在するときの絞り込み条件として使用する。これにより、経路探索結果が複数路線になるときの絞り込みが容易になる。
【００１７】
本発明の経路探索方法は、ユーザ端末と電子メールの送受信を行う装置が実行する方法であって、前記ユーザ端末から、自然文で記述された経路探索の依頼メールを受信する段階と、受信した依頼メールに対する自然文解析を行うことにより、前記依頼メールから出発値、目的地及び時刻データを含む経路探索条件を抽出する段階と、交通機関の路線情報及びダイヤ情報を含む運行情報を格納した運行情報ＤＢにアクセスして、前記抽出した経路探索条件に適合する経路候補のダイヤ情報を取得するとともに、この経路候補と同じ路線でその出発地における出発時刻よりも遅い時刻を当該出発地の出発時刻とする１又は複数の代替経路のダイヤ情報、又は、前記経路候補と同じ路線で当該経路候補における目的地の到着時刻よりも早い時刻をその目的地の到着時刻とする代替経路のダイヤ情報を取得する段階と、取得した前記経路候補及び前記代替経路のダイヤ情報をマージするとともに、マージしたダイヤ情報を、前記出発地と前記目的地との間に登場する途中地の情報と共に、当該経路候補毎に前記ユーザ端末の一つの画面で表示可能な回答文に編集し、編集した回答文を前記電子メール手段を通じて前記ユーザ端末へ返信する段階と、を有する電子メールによる運行経路探索方法である。
【００１８】
本発明のコンピュータプログラムは、コンピュータを、ユーザ端末との間で電子メールの送受信を行う電子メール手段、自然文で記述された交通機関の経路探索の依頼メールを前記電子メール手段が受信したときに当該依頼メールに対する自然文解析を行うことにより、当該依頼メールから出発地、目的地及び時刻データを含む経路探索条件を抽出する自然言語処理ツール、前記経路探索条件の入力を契機に、交通機関の路線情報及びダイヤ情報を含む運行情報を格納した運行情報ＤＢにアクセスして前記経路探索を実行することにより、前記経路探索条件に適合する経路候補のダイヤ情報を取得するとともに、この経路候補と同じ路線でその出発地における出発時刻よりも遅い時刻を当該出発地の出発時刻とする１又は複数の代替経路のダイヤ情報、又は、前記経路候補と同じ路線で当該経路候補における目的地の到着時刻よりも早い時刻をその目的地の到着時刻とする代替経路のダイヤ情報を取得する経路探索ツール、取得した前記経路候補及び前記代替経路のダイヤ情報をマージするとともに、マージしたダイヤ情報を、前記出発地と前記目的地との間に登場する途中地の情報と共に、当該経路候補毎に前記ユーザ端末の一つの画面で表示可能な回答文に編集し、編集した回答文を前記電子メール手段を通じて前記ユーザ端末へ返信する制御手段、として機能させるコンピュータプログラムである。
【発明の効果】
【００１９】
本発明によれば、経路候補毎に、その前後に利用できる列車のダイヤ情報がマージされた回答文がユーザ端末に返信されるので、対話的なインタフェースを持たない場合であっても、経路候補を通るダイヤ情報と、その列車に乗り遅れた場合や余裕を持って移動したい場合の代替ダイヤ情報を１つの乗り換えリストとしてまとめて提示することができ、一方向の情報伝達媒体である電子メールを使用した場合の課題を解決することができる。
すなわち、従来の経路探索サービス／アプリケーションでは、最適乗換情報の提供や、別の列車を使った乗り換え時刻の提供を行うことができたが、これらは経路と列車が独立したダイヤ情報の形で利用者に提供されていた。本発明によれば、これらを有機的に１つの情報としてまとめることができるので、伝達する情報の密度が上がり、電子メールのような一度に限られた対話しかできないインタフェースでも効率的に情報を提供できるようになる。また、従来の経路探索サービス／アプリケーションでは、ユーザが明示的に代替列車を探す必要があったが、本発明によれば、代替列車が最適経路と同時に提供されるため、ユーザは、１回の探索で、代替列車のある安心な経路情報を得ることができる。
代替列車の情報を得る手段として時刻表があるが、目的地までの乗り換え方法を含む路線の情報が得られない。本発明によれば、このような情報も同時に得ることができる。
【図面の簡単な説明】
【００２０】
【図１】本発明を適用した経路探索システムの全体構成図。
【図２】自然言語処理ツールによる自然文解析処理の手順説明図。
【図３】通称路線名を指定して経路候補を絞り込む場合の手順説明図。
【図４】経路候補が絞り込まれた状態を示した説明図。
【図５】ダイヤ検索の手順説明図（概要）。
【図６】ダイヤ検索の手順説明図（時刻バリエーションの拡張処理）。
【図７】ユーザが依頼メールにより経路探索を依頼し、その結果を返信メールで受け取るまでの主制御部の制御手順を示した図。
【図８】ユーザがＷｅｂアクセスにより経路探索の条件を修正して経路探索結果を再取得するときの主制御部の制御手順を示した図。
【図９】経路候補（第１経路）とその代替経路の例を示した図。
【図１０】図９の２つの経路をマージした状態を示した図。
【図１１】依頼メールに含まれる依頼文の例を示した図。
【図１２】携帯端末の表示画面に表示される［経路１］についての経路候補とその代替経路のダイヤ情報を含む回答文の例を示した図。
【図１３】携帯端末の表示画面に表示される［経路２］についての経路候補とその代替経路のダイヤ情報を含む回答文の例を示した図。
【図１４】携帯端末の表示画面に表示される［経路３］についての経路候補とその代替経路のダイヤ情報を含む回答文の例を示した図。
【図１５】Ｗｅｂアクセスにより携帯端末の表示画面に表示される経路探索条件の入力画面。
【発明を実施するための形態】
【００２１】
本発明を、携帯端末向けの交通機関の経路探索サービスを可能にするネットワーク型の経路探索システムに適用した場合の実施の形態例を説明する。
［全体構成］
図１は、この実施形態の経路探索システムの全体構成図であり、特徴的な部分のみを掲示してある。本実施形態では、携帯電話網Ｎ１及びインターネットＮ２に接続され、電子メールとＷｅｂ通信の併用による列車の経路探索サービスを実現する経路探索システム１の例を示す。ユーザは、メール機能及びＷｅｂブラウザ機能を備えた携帯端末３０、例えば携帯電話で、経路探索システム１にアクセスする。
【００２２】
この経路探索システム１は、記憶装置を備えたサーバ本体を有し、このサーバ本体が本発明のコンピュータプログラムを実行することにより、サーバ本体を、主制御部１０、メール送受信部１１、自然言語処理ツール１２、経路探索ツール１３、自然文編集ツール１４、登録ツール１５、通信制御部１６として機能させるとともに、記憶装置内に、ルールＤＢ（ＤＢはデータベースの略、以下同じ）２１、ユーザ情報ＤＢ２２、運行情報ＤＢ２３、駅名候補ＤＢ２４、ランドマークＤＢ２５及び通称路線ＤＢ２６を構築する。
【００２３】
ルールＤＢ２１には、自然言語処理ツール１２が参照する文法ファイル、各種辞書ファイル及び意味解析のための知識ベースと、経路探索条件の候補となる複数の条件候補データを抽出するための抽出ルール及び複数の条件候補データの中から最適条件候補データを選定するための候補選定ルールとが格納されている。条件候補データ及び最適条件候補データは、いずれも経路探索ツール１３に入力する経路探索条件の一つとなり得るものである。
【００２４】
経路探索条件は、複数の構成文字を組み合わせたもの、すなわち、出発地、目的地、経由地、時刻データ、後述するランドマーク名及び路線名（後述する通称路線名を含む）の組み合わせたものである。但し、これらをすべて含んだものが経路探索条件となるのではなく、通常は、一部の組み合わせとなる。必須となるのは、出発地と目的地の組み合わせである。
便宜上、この実施形態において、条件候補データは、出発地、目的地又は経由地となり得る駅名候補データ及びランドマーク名、時刻データ、路線名であるものとする。
【００２５】
条件候補データの抽出ルールは、例えばひらがな／片仮名／ローマ字／混合文字に対応する正式表現名の対応ルール、同名他駅に対応する候補表現（例えば「中野」に対する中野(東京都)、中野(群馬県)、中野(長野県)、中野坂上、中野栄・・・）の対応ルール、経路探索実行依頼と共に経路探索ツール１３に伝えるときの探索条件ルール、すなわち２つの駅名候補データだけ入力されたときは駅間の平均経路の探索と解釈する等である。また、出発地と目的地とを区別する以下のようなルールも抽出ルールに含まれる。
・固有名詞間の助詞
「渋谷から新宿まで」→出発地：渋谷、目的地：新宿
・固有名詞の位置関係
「渋谷新宿」→出発地：渋谷、目的地：新宿
・日本語の係り受け関係
「渋谷を１１時に出発、新宿は到着駅」→出発地：渋谷、目的地：新宿
・名詞間の記号類
「出発：渋谷、到着：新宿」→出発地：渋谷、目的地：新宿
「新宿←渋谷」→出発地：渋谷、目的地：新宿
・他の駅の確定内容に基づく他の駅
「新宿まで、渋谷」→出発地：渋谷、目的地：新宿
・文節の位置関係による強制解決
「渋谷は到着、新宿は到着」→出発地：渋谷、目的地：新宿
「渋谷は出発、新宿から」→出発地：渋谷、目的地：新宿
「池袋から中野まで」→出発地：「池袋」、目的地：「中野(東京都)」
【００２６】
候補選定ルールは、以下のようなものである。
・運行コストが最小となる駅の組み合わせであること
「中野池袋」→「中野」と「池袋」に分断され、「中野」からは「中野(東京都)」、「中野(群馬県)」、「中野(長野県)」、「中野坂上」、「中野栄」が導出されるが、運行コストが最小となるのは、出発地：「中野(東京都)」、到着地：「池袋」である。
・過去に参照した履歴がある場合はそれを利用
「長野の中野から池袋まで」→「中野」は「中野(長野県)」
・鉄道同士、空港同士を最優先
・県同士が最も近い駅の組み合わせを最優先
【００２７】
ユーザ情報ＤＢ２２には、ユーザの固有情報、登録メールアドレス、利用ログ等が、ユーザＩＤ等により相互に関連付けて格納される。
【００２８】
運行情報ＤＢ２３には、交通機関（鉄道／バス／航空機）の路線、ダイヤ情報（時刻情報）、運賃情報、駅リストを含む、運行経路の探索に必要なすべての運行情報が格納される。この運行情報は、随時更新される。
【００２９】
駅名候補ＤＢ２４には、自然言語処理ツール１２による自然文解析により特定されたすべての駅名候補データが格納される。これらのデータは、携帯端末３０から電子メールを受信したときに採番される探索ＩＤと関連付けて格納される。読み出すときは、この探索ＩＤを読み出しキーとして用いる。
【００３０】
ランドマークＤＢ２５には、ユーザが任意に選定した場所、施設等をランドマーク名で表し、そこからの最寄駅及びそこまでの移動所要時間が、ユーザの固有情報と関連付けて格納される。例えば、株式会社ヴァル研究所の固有情報と関連付けて「ヴァル」というランドマーク名を登録し、この「ヴァル」について、最寄駅が高円寺駅、そこまでの移動所要時間が徒歩６分という情報を登録する。ランドマーク名は、経路探索時に、駅名候補データと同様に扱われ、最寄駅からの距離が長いときの総所要時間、最寄駅が複数あるときの最適経路の選択等のために用いられる。
【００３１】
通称路線ＤＢ２６には、正式な路線名（例えば「ＪＲ中央・青梅線青梅特快」）と、ユーザが覚えやすい任意の通称名（例えば「ＪＲ線」又は「青梅線」）とをユーザの固有情報と関連付けて格納される。携帯端末３０では、表示画面上に多くの経路を表示できないため、使用したい路線のイメージがあっても、その経路を見つけるのが困難となる。路線名を経路探索条件（絞り込みの条件）として指定したい場合であっても、正式な路線名（表示される路線名）をユーザが正確に入力するのは難しい。そこで、一つの正式な路線名に対して、その路線名を簡略化した通称路線名を複数件対応付けて登録しておき、一つの正式路線名を様々な名前で指定できるようにした。通称路線名はシステム中、一意でなくても良い。ユーザが指定した通称路線名から複数の正式路線名を対等に扱うことで、経路探索結果の絞り込みを容易にすることができる。
【００３２】
主制御部１０は、経路探索に関する各種処理を実現するために以下の各機能ブロック１１〜１６の起動を含む動作の制御を行う。制御手順については、後述する。
【００３３】
メール送受信部１１は、携帯電話網Ｎ１を介して携帯端末３０との間で、登録メールアドレスを用いた電子メールの受け渡しを行う。以後、経路探索の依頼文を含む電子メールを依頼メール、その回答文を含む電子メールを返信メールとする。
受信時は、依頼メールのヘッダ部からユーザの登録メールアドレスを抽出し、これを図示しないアドレステーブルに一時的に記録する。返信時は、このアドレステーブルに記録されている登録メールアドレス宛に返信メールを送信する。通信制御部１６は、後述する権限情報に基づきインターネットＮ２を介してアクセスした携帯端末３０に対してＷｅｂサービスを提供するための制御を行う。
【００３４】
自然言語処理ツール１２は、メール送受信部１１で受信した依頼メールの例えば本文部に記述されている依頼文に対してルールＤＢ２１に格納されている文法ファイル、辞書ファイル、知識ベース、各種ルールに基づき、自然文解析処理を施し、複数の駅名候補データ、時刻データ等を抽出する。
【００３５】
［自然文解析処理］
図２は、自然言語処理ツール１２による自然文解析処理の手順説明図である。ここでは「３時に東京からヴァル」という自然文（一部半角文字、登録されたランドマーク有り）が入力されたものとする。
自然言語処理ツール１２は、まず、前処理で表記統制を行う。表記統制は、半角文字を全角文字にしたり、バイナリや改行を削除したり、文字数を指定文字数でカットする処理である。これにより、構文解析の文法を簡易なものにすることができる。
【００３６】
その後、ひらがなクエリー判定を行う。この処理は、依頼文をクエリー（コンピュータが認識できる要求コマンド）とし、ひらがなのクエリーを駅名（又はランドマーク）を表す構成文字として解釈する（抽出する）処理である。また、抽出した駅名候補データが１個の場合は用途不明、駅名候補データが２個の場合は出発地と目的地があると解釈する。駅名候補データが３個の場合は出発地、経由地、目的地があると解釈する。ひらがなクエリー判定後、ランドマーク名変換を行う。ランドマーク変換は、クエリーからランドマーク名を探し、そのランドマーク名を形態素解析用の文字列に変換する処理である。
【００３７】
以上の一連の処理を終えた後、日本語解析を行う。日本語解析は、クエリーの文章を日本語の形態素と文節の並びに変換する処理である。本実施形態では、形態素を語句ＩＤに変換して図示しないメモリ領域に記憶する。その結果、日本語解析の結果は、語句ＩＤの並びとなる。語句ＩＤとは、ルールＤＢ２１に格納されている文法ファイルに出現する語句に対し、出現順に数値を割り当てたものである。ＩＤ化して扱うことにより、非常に大きな負荷がかかる駅名候補データの抽出処理を高速に行うことができる。
【００３８】
日本語解析を終えると、自然言語処理ツール１２は、共に日本語解析結果を取得し、ルールＤＢ２１の辞書ファイルを用いて格候補抽出を行う。「格」は形態素や文節に意味を与えるためのものであり（「彼が」はガ格、「彼を」はヲ格）、「格候補」は「格」を形成し得る文節のまとまりをすべての可能性に対して抽出したデータの構造をいう。候補として扱うため、最終的に「格」として選択されないものも抽出する。例えば、「東京」は場所名のほか「東京駅」とも解釈され得るため、２つの格候補が抽出される。３時は「ｈ＝３」のように表現を統一する。
【００３９】
格候補抽出後は、署名格候補を削除する。署名は電子メールの本文部の最後に記載される定型文である。「品川太郎」のように、駅名ともとれる人名又は住所表記があると駅名候補データと誤認識するおそれがあるため、署名と思われる行から格候補を削除する。その後、格候補最適化を行う。すなわち、抽出した格候補をどのように組み合わせれば、一文全体で最適な解釈となるかを総当たりで評価する。このようにして確定した格候補について、意味解析を行う。ここでは、特に、時刻と日付の解釈を行い、具体的な日時を数値で表現する。その結果、自然言語処理ツール１２からは、図右側上段の出力が得られる。
【００４０】
このようにして、依頼メールに含まれる語、語句、文を抽出し、抽出した語、語句又は文とルールＤＢ２１に格納されている条件候補の抽出ルールに基づいて、複数の駅名候補データを抽出する。路線名や時刻データが含まれているときは、これらも抽出する。また、ルールＤＢ２１に格納されている候補選定ルールに基づいて複数の駅名候補データの組み合わせ（路線、時刻データが含まれている場合はこれらも加えた組み合わせ）のうち、上記条件選定ルールに従えば最もあり得るいずれか一組を、ユーザの意図を反映していると推定される最適な駅名候補データの組み合わせである経路探索条件として選定する。
【００４１】
［経路探索］
経路探索ツール１３は、経路探索条件の入力を契機に、運行情報ＤＢ２３、ランドマークＤＢ２５及び通称路線ＤＢ２６に蓄積されている情報をもとに、交通機関による運行コストが最も小さい次の駅（又はランドマーク名）の探索処理を、水面に石を投げたときの波紋のように連鎖的に繰り返すことにより、経路探索条件に従う経路候補及びそのダイヤ情報を特定する。運行コストは通常は時間を対象とするが、距離、運賃を用いても良く、あるいは、これらの組み合わせを対象としても良い。経路探索ツール１３は、推論エンジンも搭載しており、探索途中で現実的でない経路となることが判明した場合は、その経路についての次の駅以降の探索を止める。なお、経路探索ツール１３のうち、経路探索機能の部分は、例えば本願出願人が提供している経路探索ソフトウエア「駅すぱあと」（登録商標）のものを使用することができる。
【００４２】
本実施形態では、自然言語処理ツール１２が、上記のようにして依頼文から抽出した複数の駅名候補データ（存在する場合は路線名や時刻データを含む）のうち、最適な組み合わせを経路探索条件として、経路探索ツール１３に入力するが、経路候補が多数になる場合は、通称路線名で経路候補を絞り込む。
【００４３】
このことを図３及び図４を参照して詳しく説明する。
通称名称ＤＢ２６には、予め表示に使用する正式な路線名称から通称路線名を複数個登録しておくことは、上述の通りである。ユーザは、経路探索を行うときに、図３に示すように、出発地、目的地のほかに、使いたい路線名を通称路線名で指定する（ステップＳ１１）。経路探索ツール１３は、経路探索を行い（ステップＳ１２）、複数の経路候補を特定する過程で（ステップＳ１３）、通称路線ＤＢ２６へアクセスして通称路線名検索を行い（ステップＳ１４）、ユーザが指定した通称路線名に一致した通称路線名に関連付けられたすべての正式路線名を取得する（ステップＳ１５）。そして、ステップＳ１３で特定した複数の経路候補を、取得した正式路線名を含む経路候補のみに絞り込み（ステップＳ１６）、絞り込んだ経路候補を探索結果として出力する（ステップＳ１７）。
【００４４】
図４の例でいえば、ユーザが通称路線名Ａを指定したとすると、通称路線ＤＢ２６から通称路線名Ａに関連付けられた正式路線名＃１と正式路線名＃２とを取得する。経路探索結果として「経路＃１」、「経路＃２」、「経路＃３」が特定され、「経路＃１」には正式路線名＃３と正式路線名＃４が含まれ、「経路＃２」には正式路線名＃１と正式路線名＃５が含まれ、「経路＃３」には正式路線名＃６が含まれていたとすると、絞り込みにより、「経路＃２」のみが探索結果として出力される。
なお、以上は、ユーザが指定した経路候補を使用する場合の例であるが、指定した経路候補を使用しない場合には、正式路線名を含む経路候補を出力しないようにすれば良い。
【００４５】
経路候補及びそのダイヤ情報を特定すると、経路探索ツール１３は、その経路候補の代替経路についてのダイヤ検索を行う。このダイヤ検索の手順を図５及び図６を参照して説明する。
図５を参照すると、経路探索ツール１３は、経路候補のダイヤ検索結果を取得する（ステップＳ１）。検索結果の最後の経路まで処理した場合は終了する（ステップＳ２：Yes）。検索結果の最後の経路まで処理していない場合は（ステップＳ２：No）、処理済の路線かどうかを判定し、処理済であればステップＳ２の処理に移る（ステップＳ３：Yes）。処理済の路線でなければ、時刻バリエーションの拡張処理を行う（ステップＳ３：No、Ｓ４）。
【００４６】
時刻バリエーションの拡張処理は、図６の手順で行われる。
すなわち、元の経路、つまり上述した経路候補と同一の路線における一つ前の最適ダイヤ（到着時刻−１分以前、−６０分までに到着できる効率的なダイヤ）、または、次の最適ダイヤ（出発時刻＋１分以降、＋６０分までに出発する効率的なダイヤ）となるようなダイヤ検索結果を取得し、これを代替経路のダイヤ情報とする（ステップＳ４１）。元の経路（経路候補）より取得したダイヤ検索結果の最後の列車まで処理したかどうかを判定し、処理した場合、つまり、代替経路が無い場合は終了する（ステップＳ４２：Yes）。最後の列車まで処理していない場合は、代替経路があることを意味するので、マージ（ダイヤ情報の統合）の対象になるかどうかを判定する（ステップＳ４２：Yes、Ｓ４３）。
マージ対象となるのは、料金、通過駅一覧（停車するかどうかを問わず）、営業距離が一致し、且つ、初めの出発時刻から６０分以内であることが条件となる。マージ対象となる場合は、元の経路である経路候補に代替経路のダイヤ情報をマージする（ステップＳ４３：Yes、Ｓ４４）。他方、マージ対象とならない場合は、新たに見つかった別経路（別の行き方）としてこのダイヤ情報を保持する（ステップＳ４３：No、Ｓ４５）。
以上の手順を表示時刻数分のダイヤ情報が揃うまで繰り返し（ステップＳ４６：No）、揃った場合は終了する（ステップＳ４６：Yes）。
【００４７】
図５に戻り、時刻バリエーションの拡張処理後は、予め設定された表示経路数分のダイヤ情報が揃ったかどうかを判定する（ステップＳ５）。揃った場合は終了する（ステップＳ５：Yes）。揃わない場合は、時刻バリエーション拡張処理で新たに別経路が見つかったかどうかを調べる（ステップＳ５：No、Ｓ６）。見つかっていない場合はステップＳ２の処理に戻る（ステップＳ６：No）。見つかった場合は、ダイヤ検索結果の経路に新たに見つかった別経路を追加してステップＳ２の処理に戻る（ステップＳ６：Yes、Ｓ７）。
これにより、最適経路とその１本前又は１本後のように、幅のあるダイヤ情報を、電子メールという一方向の情報伝達媒体を使用する場合においても利用者にとって違和感のない形で提供することができる。
【００４８】
経路探索の結果、出発地と目的地とが同じであっても、ダイヤ構築の関係上、常に同じ経路にならず、経路候補が複数になる場合がある。この場合は、運行コストが小さい順に「経路１」、「経路２」、「経路３」のように特定し、各々の経路において上記代替経路のダイヤ情報を特定する。例えば、新宿から横浜に行く場合の例を挙げる。利用者は、出発時間帯、予算、好みなどに応じて、以下の数通りの経路を選択することができる。
新宿→(ＪＲ)→横浜
新宿→(ＪＲ)→渋谷→(東急)→横浜
新宿→(ＪＲ)→品川→(京急)→横浜
新宿→(ＪＲ)→東京→(ＪＲ)→横浜
新宿→(ＪＲ)→東京→(特急)→横浜
本実施形態では、これらの経路の各々を経路候補とし、各経路候補のそれぞれについて、上述した代替経路のダイヤ情報を特定する。
【００４９】
自然文編集ツール１４は、経路探索ツール１３により特定された経路候補及び代替経路のダイヤ情報を一つのダイヤ情報にマージする。
ここで、マージの意味合いを具体的に説明する。便宜上、東京発、沼津到着の例を挙げる。図９左側は経路候補、右側はその代替経路（便宜上、その１本後の列車とする）である。図９の例では、「ＪＲ快速アクティー・熱海行き」と「ＪＲ東海道本線」は、利用者は同じ路線と認識するが、従前の経路探索技術では、１本違うだけの列車であっても別経路と認識する。そのため、これらを単純に一つの画面に表示することはできない。仮に一つの画面に表示できたとしても、利用者の感覚からすれば、違和感のある探索結果となる場合があり、この場合は実用性が低下するおそれがある。
本実施形態では、上述したマージ対象かどうかの基準に従い、各ダイヤ情報を経路候補毎にマージするとともに、マージしたダイヤ情報を、出発駅と目的駅との間に登場する途中駅の情報と共に、経路候補毎に一つの画面で表示できるように編集する。通過駅については表示されないようにする。その結果、図９の２つの経路のダイヤ情報は、図１０のようにマージされる。
経路候補が複数となる場合は、それぞれの経路候補のダイヤ情報について代替経路のダイヤ情報とマージし、それらを一つの画面で表示することができるようにする。これにより、情報の網羅性についての利点がある。このマージされた各情報を初期探索結果とする。
【００５０】
その後、初期探索結果、探索ＩＤ、及び、依頼メールの発信元が経路探索ツール１３に事後的にＷｅｂ通信によりアクセスするための権限情報を、携帯端末３０の一つの画面に表示させる回答文として編集し、この回答文を含む返信メールを作成する。このとき、携帯端末３０のディスプレイは小さいし、解像度も低いので、余分な情報を取り除き、なるべく少ないパケット数で且つなるべく一画面で表示することができ、しかし必要な情報は盛り込むように編集する。この返信メールは、メール送受信部１１から依頼メールの発信元に返信される。
【００５１】
登録ツール１５は、ユーザの固有情報、メールアドレス、ランドマーク名、通称路線名、各種ルール、サービス条件設定等の登録を受け付ける。登録したユーザの固有情報は、ユーザ情報ＤＢ２２に格納される。登録されたメールアドレスが登録メールアドレスとなる。ランドマーク名はランドマークＤＢ２５に格納される。通称路線名は通称路線ＤＢ２６に格納される。
【００５２】
［運用形態］
次に、上記のように構成される経路探索システム１の運用形態例を説明する。
【００５３】
ユーザは、登録メールアドレスを用いて経路探索システム１の専用アドレスに依頼メールを発信することによって、経路探索システム１は動作を開始する。本例では、図１１に示すように、ユーザが、「ヴァル つくばエクスプレス 浅草」のような依頼文を記述した依頼メールを発信したものとする。「ヴァル」は、ＪＲの高円寺駅までの移動所要時間が５分の株式会社ヴァル研究所のランドマーク名、つくばエクスプレスは路線である。このランドマーク名も駅名候補データの一つとして扱われる。
【００５４】
主制御部１０は、図７の手順で制御動作を開始する。すなわち、この依頼メールを受信すると（ステップＳ１０１：Yes）、発信元の登録メールアドレスをアドレスメモリ（図示省略）に記録する（ステップＳ１０２）。また、その依頼メールに対して探索ＩＤを採番し（ステップＳ１０３）、この探索ＩＤを駅名候補ＤＢ２４に格納する（ステップＳ１０４）。
【００５５】
探索ＩＤを格納すると、主制御部１０は、自然言語処理ツール１２を起動する。自然言語処理ツール１２は、依頼メールに記述されている依頼文に対して自然文解析を行うことにより、複数の駅名候補データを抽出する。そして、抽出した複数の駅名候補データを、駅名候補ＤＢ２４に格納されている探索ＩＤと関連付けて保存する（ステップ１０５）。保存が終了すると、自然言語処理ツール１２は、複数の駅名候補データの組み合わせのうち、最適条件候補データとなる一組の駅名候補データを選定する。
【００５６】
本例の場合、最適条件候補データは、出発地が「ヴァル（ランドマーク名）」、路線が「つくばエクスプレス」、目的地が「浅草駅」として選定される。最適条件候補データが選定されると、駅名候補ＤＢ２４に記憶されている駅名候補データのうち、該当する駅名候補データに選定済のタグを付与するとともに、最適条件候補データを経路探索条件として経路探索ツール１３に入力する（ステップＳ１０６）。タグは、例えば「ヴァル」が出発地として再度選定されないようにするためものであるが、不可欠なものではない。
【００５７】
経路探索ツール１３から経路探索結果を受け取ると（ステップＳ１０７:Yes）、主制御部１０は、自然文編集ツール１４を起動する。自然文編集ツール１４は、経路探索結果に含まれる経路候補及び代替経路のダイヤ情報をマージしたものと、ユーザ端末３０からＷｅｂ通信により経路探索ツール１３にアクセスするための権限情報及び探索ＩＤと共に、メール用の回答文として編集する（ステップＳ１０８）。権限情報は、登録されたユーザの固有情報及び上記の探索ＩＤをパラメータ化し、これを経路探索ツール１３のＵＲＬ（Uniform Resource Locator）とセットにしたものを用いる。
【００５８】
自然文編集ツール１４により回答文が編集されると、主制御部１０は、メール送受信部１１を制御し、発信元の登録メールアドレスを読み出し（ステップＳ１０９）、回答文を発信元の登録メールアドレス宛に返信する（ステップＳ１１０）。
【００５９】
返信メールに含まれる回答文は、図１２〜図１４に例示されるものとなる。図１２の例では、携帯端末３０の表示画面５０に、［経路１］についての経路候補とその代替経路のダイヤ情報が示されている。図１３は［経路２］についての経路候補とその代替経路のダイヤ情報、図１４は［経路３］についての経路候補とその代替経路のダイヤ情報である。ユーザの意図に沿わない経路探索条件であったかどうかは、［経路１］についての探索結果で直ちにわかるので、最初の表示画面５０の最下部に、権限情報５２が記述されている。
【００６０】
ユーザは、図１２〜図１４の表示画面が自分の意図したものであった場合は、何のアクションを起こさずとも、経路探索のための一連の処理は完結する。つまり、ユーザによる自然文による１回の電子メールの送信及びそれに因る自動応答による返信メールにより、ユーザの目的は達成されるので、例えば特許文献４のシステムのように、本文に経路案内メールを引用して返信する必要がなくなり、操作が簡略化されるだけでなく、通信リソースの浪費も回避される。
【００６１】
他方、意図しない探索結果であったときは、図１２の表示画面５０の最下段に記述されている権限情報５２の部分にカーソルを合わせ、クリックすることにより、ネットワークＮ２及び通信制御部１６を介して経路探索ツール１３に、シームレスにＷｅｂアクセスすることができる。図８は、Ｗｅｂアクセス時の主制御部１０の処理手順図である。
【００６２】
図８において、主制御部１０は、携帯端末３０からのアクセス（Ｗｅｂアクセス）を検知すると（ステップＳ２０１：Yes）、経路探索条件の入力画面を携帯端末３０の画面に表示させる（ステップＳ２０２）。このとき、駅名候補ＤＢ２４に記憶され、探索ＩＤにより特定される駅名候補データを駅名候補ＤＢ２４より読み出し、これらを出発地別、経由地別、目的地別、路線別に、それぞれカーソルで選択できるようにする（ステップＳ２０３）。
【００６３】
図１５は、経路探索条件の入力画面例である。表示画面５０には、４つの入力領域が形成されている。各入力領域からは、既に抽出された駅名候補データ（ランドマーク名を含む）や路線を選択できるようになっている。デフォルトとして、先頭データすなわち最適な駅名候補データが自動的に記入される。経由地及び路線については必須入力条件ではないので、「指定せず」が含まれている。「指定せず」が選択されたときはその条件は無いものとして扱われる。
【００６４】
ユーザが、カーソル操作で、各入力領域について目的の駅名候補データを一つ選択し、表示画面５０の実行ボタン画像５５をクリックして指示すると（ステップＳ２０４：Yes）、主制御部１０は、変更された経路探索条件を経路探索ツール１３に入力する（ステップＳ２０５）。その後、主制御部１０は、Ｗｅｂ通信（Ｗｅｂアクセス）を終了させる（ステップＳ２０６）。その後の処理手順は、図７のステップＳ１０７以降と同じとなる。つまり、ユーザは、自分の意図通りの経路探索結果を、図１２〜図１４のような回答文をその内容とする返信メールにより受け取ることができる。
なお、条件変更後の経路探索結果を再度の返信メールではなく、Ｗｅｂ通信を維持した状態で表示画面５０に表示させるようにしても良い。
【００６５】
このように、本実施形態の経路探索システム１では、ユーザにとって使い方が曖昧である日本語の自然文であっても、駅名候補データが得られた段階ですべての駅名候補データを駅名候補ＤＢ２４へ保存しておき、自然言語処理ツール１２の解釈が誤っていた場合に、Ｗｅｂ通信を使ってユーザが本来意図していた駅名候補データを選択できるようにしたので、電子メールによる経路探索の利便性をＷｅｂ通信により補完することができる。現在確立されている自然言語処理技術では必ずしも完全な結果が得られないが、本実施形態によれば、返信メールを受け取った後に、さらに解釈を変更できるという、従来技術からは得られない効果が期待される。
【００６６】
本実施形態では、また、自然言語処理ツール１２が、ひらがなクエリー判定を行うことで、依頼メールにひらがなが含まれるときであっても、当該ひらがなを漢字等の本来表現の文字に変換した後に自然文解析を行うようにしたので、依頼文の作成に際して文字変換の作業が軽減される。
【００６７】
本実施形態では、また、経路候補とその前後に利用できる代替経路のダイヤ情報が１つの表示画面５０でマージされて表示されるので、対話的なインタフェースを持たない場合においても、経路案内情報を効率的に提供することができる。
【００６８】
本実施形態では、また、ユーザが入力した特定の地域、場所又は施設を表すランドマーク名と、ランドマーク名の最寄り駅及びそこまでの到達所要時間とを当該ユーザの識別情報と関連付けてランドマークＤＢ２５を備え、自然言語処理ツール１２が、登録されたランドマーク名を出発地、経由地又は目的地の一つに含めて自然文解析を行うようにしたので、依頼文にユーザ独自の施設名等を含めた条件の指定を迅速に行うことができる。携帯端末３０の場合、文字を入力する行為そのものが煩わしく、できるだけ短い語で経路探索の条件を入力することが望ましいが、本実施形態によれば、それが可能となる。ランドマーク名は、自宅、会社、友人宅などのプライベートな施設であっても良いので、ユーザに特化した経路探索が可能となる。
【００６９】
本実施形態では、さらに、交通機関の正式の路線名毎に、ユーザが任意に指定した１又は複数の通称路線名を、当該ユーザの識別情報と関連付けて通称路線ＤＢ２６に登録しておき、経路探索ツール１３が、登録されたいずれかの通称路線名を経路候補が複数存在するときの絞り込み条件として使用するようにしたので、ユーザの好みに応じた探索結果の「絞り込み」が可能となる。特に携帯端末３０の場合、操作環境が充分でなく、かつ、表示画面５０に多くの経路を表示できないので、使用したい路線のイメージがあっても、その経路を見つけるのは困難であるが、本実施形態によれば、それが容易となる。
【００７０】
なお、本実施形態では、曖昧性を持つ自然文の解釈が１つに定まらないという問題を解消する手段であることを前提として説明したが、依頼メールからの語句の切り出し領域のずれ等により、駅名以外の文字が誤って駅名候補データと認識された場合についても、正しい駅名候補データに解釈を変更する手続きとして、本発明を適用することもできる。
【００７１】
また、本実施形態では、条件候補データの一つとして駅名候補データを用いた場合の例を示したが、交通機関としてバスを組み込む場合は、駅名候補データはバス停候補データとなり、航空機をも組み込む場合は、駅名候補データは空港名候補データとなる。
【００７２】
また、本実施形態では、携帯端末３０の電子メールを用いて経路探索サービスを提供する場合の例を説明したが、パーソナルコンピュータによる電子メールを用いることもできる。
【符号の説明】
【００７３】
１・・・経路探索システム、１０・・・主制御部、１１・・・メール送受信部、１２・・・自然言語処理ツール、１３・・・経路探索ツール、１４・・・自然文編集ツール、１５・・・登録ツール、１６・・・通信制御部、２１・・・ルールＤＢ、２２・・・ユーザ情報ＤＢ、２３・・・運行情報ＤＢ、２４・・・駅名候補ＤＢ、２５・・・ランドマークＤＢ、２６・・・通称路線ＤＢ、３０・・・携帯端末、５０・・・表示画面、５２・・・権限情報、５５・・・実行ボタン画像、Ｎ１・・・携帯電話網、Ｎ２・・・インターネット。
【特許請求の範囲】
【請求項１】
ユーザ端末との間で電子メールの送受信を行う電子メール手段と、
自然文で記述された交通機関の経路探索の依頼メールを前記電子メール手段が受信したときに当該依頼メールに対する自然文解析を行うことにより、当該依頼メールから出発地、目的地及び時刻データを含む経路探索条件を抽出する自然言語処理ツールと、
前記経路探索条件の入力を契機に、交通機関の路線情報及びダイヤ情報を含む運行情報を格納した運行情報ＤＢにアクセスして前記経路探索を実行することにより、前記経路探索条件に適合する経路候補のダイヤ情報を取得するとともに、この経路候補と同じ路線でその出発地における出発時刻よりも遅い時刻を当該出発地の出発時刻とする１又は複数の代替経路のダイヤ情報、又は、前記経路候補と同じ路線で当該経路候補における目的地の到着時刻よりも早い時刻をその目的地の到着時刻とする代替経路のダイヤ情報を取得する経路探索ツールと、
取得した前記経路候補のダイヤ情報と前記代替経路のダイヤ情報とをマージするとともに、マージしたダイヤ情報を、前記出発地と前記目的地との間に登場する途中地の情報と共に、当該経路候補毎に前記ユーザ端末の一つの画面で表示可能な回答文に編集し、編集した回答文を前記電子メール手段を通じて前記ユーザ端末へ返信する制御手段と、
を有する運行経路探索システム。
【請求項２】
前記自然言語処理ツールは、前記依頼メールにひらがなが含まれるときに、当該ひらがなが、ひらがな以外の文字で表現される前記経路探索条件の構成文字に相当するかどうかを判定し、相当するときは当該ひらがなを当該構成文字に変換した後に前記自然文解析を行う、
請求項１記載の経路探索システム。
【請求項３】
ユーザが入力した特定の地域、場所又は施設を表すランドマーク名と、当該ランドマーク名の最寄り駅及びそこまでの到達所要時間とを当該ユーザの識別情報と関連付けて登録するランドマーク登録手段を有しており、
前記自然言語処理ツールは、登録されたランドマーク名を前記経路探索条件の構成文字に含めて前記自然文解析を行う、
請求項１又は２記載の経路探索システム。
【請求項４】
交通機関の正式の路線名毎に、ユーザが任意に指定した１又は複数の通称路線名を、当該ユーザの識別情報と関連付けて登録する通称路線名登録手段を有しており、
前記自然言語処理ツールは、登録された通称路線名を前記経路探索条件と共に前記依頼メールから抽出し、
前記経路探索ツールは、前記自然言語処理ツールにより抽出された通称路線名を前記経路候補が複数存在するときの絞り込み条件として使用する、
請求項１又は２記載の経路探索システム。
【請求項５】
ユーザ端末と電子メールの送受信を行う装置が実行する方法であって、
前記ユーザ端末から、自然文で記述された経路探索の依頼メールを受信する段階と、
受信した依頼メールに対する自然文解析を行うことにより、前記依頼メールから出発値、目的地及び時刻データを含む経路探索条件を抽出する段階と、
交通機関の路線情報及びダイヤ情報を含む運行情報を格納した運行情報ＤＢにアクセスして、前記抽出した経路探索条件に適合する経路候補のダイヤ情報を取得するとともに、この経路候補と同じ路線でその出発地における出発時刻よりも遅い時刻を当該出発地の出発時刻とする１又は複数の代替経路のダイヤ情報、又は、前記経路候補と同じ路線で当該経路候補における目的地の到着時刻よりも早い時刻をその目的地の到着時刻とする代替経路のダイヤ情報を取得する段階と、
取得した前記経路候補及び前記代替経路のダイヤ情報をマージするとともに、マージしたダイヤ情報を、前記出発地と前記目的地との間に登場する途中地の情報と共に、当該経路候補毎に前記ユーザ端末の一つの画面で表示可能な回答文に編集し、編集した回答文を前記電子メール手段を通じて前記ユーザ端末へ返信する段階と、
を有する電子メールによる運行経路探索方法。
【請求項６】
コンピュータを、
ユーザ端末との間で電子メールの送受信を行う電子メール手段、
自然文で記述された交通機関の経路探索の依頼メールを前記電子メール手段が受信したときに当該依頼メールに対する自然文解析を行うことにより、当該依頼メールから出発地、目的地及び時刻データを含む経路探索条件を抽出する自然言語処理ツール、
前記経路探索条件の入力を契機に、交通機関の路線情報及びダイヤ情報を含む運行情報を格納した運行情報ＤＢにアクセスして前記経路探索を実行することにより、前記経路探索条件に適合する経路候補のダイヤ情報を取得するとともに、この経路候補と同じ路線でその出発地における出発時刻よりも遅い時刻を当該出発地の出発時刻とする１又は複数の代替経路のダイヤ情報、又は、前記経路候補と同じ路線で当該経路候補における目的地の到着時刻よりも早い時刻をその目的地の到着時刻とする代替経路のダイヤ情報を取得する経路探索ツール、
取得した前記経路候補及び前記代替経路のダイヤ情報をマージするとともに、マージしたダイヤ情報を、前記出発地と前記目的地との間に登場する途中地の情報と共に、当該経路候補毎に前記ユーザ端末の一つの画面で表示可能な回答文に編集し、編集した回答文を前記電子メール手段を通じて前記ユーザ端末へ返信する制御手段、
として機能させるコンピュータプログラム。
【請求項１】
ユーザ端末との間で電子メールの送受信を行う電子メール手段と、
自然文で記述された交通機関の経路探索の依頼メールを前記電子メール手段が受信したときに当該依頼メールに対する自然文解析を行うことにより、当該依頼メールから出発地、目的地及び時刻データを含む経路探索条件を抽出する自然言語処理ツールと、
前記経路探索条件の入力を契機に、交通機関の路線情報及びダイヤ情報を含む運行情報を格納した運行情報ＤＢにアクセスして前記経路探索を実行することにより、前記経路探索条件に適合する経路候補のダイヤ情報を取得するとともに、この経路候補と同じ路線でその出発地における出発時刻よりも遅い時刻を当該出発地の出発時刻とする１又は複数の代替経路のダイヤ情報、又は、前記経路候補と同じ路線で当該経路候補における目的地の到着時刻よりも早い時刻をその目的地の到着時刻とする代替経路のダイヤ情報を取得する経路探索ツールと、
取得した前記経路候補のダイヤ情報と前記代替経路のダイヤ情報とをマージするとともに、マージしたダイヤ情報を、前記出発地と前記目的地との間に登場する途中地の情報と共に、当該経路候補毎に前記ユーザ端末の一つの画面で表示可能な回答文に編集し、編集した回答文を前記電子メール手段を通じて前記ユーザ端末へ返信する制御手段と、
を有する運行経路探索システム。
【請求項２】
前記自然言語処理ツールは、前記依頼メールにひらがなが含まれるときに、当該ひらがなが、ひらがな以外の文字で表現される前記経路探索条件の構成文字に相当するかどうかを判定し、相当するときは当該ひらがなを当該構成文字に変換した後に前記自然文解析を行う、
請求項１記載の経路探索システム。
【請求項３】
ユーザが入力した特定の地域、場所又は施設を表すランドマーク名と、当該ランドマーク名の最寄り駅及びそこまでの到達所要時間とを当該ユーザの識別情報と関連付けて登録するランドマーク登録手段を有しており、
前記自然言語処理ツールは、登録されたランドマーク名を前記経路探索条件の構成文字に含めて前記自然文解析を行う、
請求項１又は２記載の経路探索システム。
【請求項４】
交通機関の正式の路線名毎に、ユーザが任意に指定した１又は複数の通称路線名を、当該ユーザの識別情報と関連付けて登録する通称路線名登録手段を有しており、
前記自然言語処理ツールは、登録された通称路線名を前記経路探索条件と共に前記依頼メールから抽出し、
前記経路探索ツールは、前記自然言語処理ツールにより抽出された通称路線名を前記経路候補が複数存在するときの絞り込み条件として使用する、
請求項１又は２記載の経路探索システム。
【請求項５】
ユーザ端末と電子メールの送受信を行う装置が実行する方法であって、
前記ユーザ端末から、自然文で記述された経路探索の依頼メールを受信する段階と、
受信した依頼メールに対する自然文解析を行うことにより、前記依頼メールから出発値、目的地及び時刻データを含む経路探索条件を抽出する段階と、
交通機関の路線情報及びダイヤ情報を含む運行情報を格納した運行情報ＤＢにアクセスして、前記抽出した経路探索条件に適合する経路候補のダイヤ情報を取得するとともに、この経路候補と同じ路線でその出発地における出発時刻よりも遅い時刻を当該出発地の出発時刻とする１又は複数の代替経路のダイヤ情報、又は、前記経路候補と同じ路線で当該経路候補における目的地の到着時刻よりも早い時刻をその目的地の到着時刻とする代替経路のダイヤ情報を取得する段階と、
取得した前記経路候補及び前記代替経路のダイヤ情報をマージするとともに、マージしたダイヤ情報を、前記出発地と前記目的地との間に登場する途中地の情報と共に、当該経路候補毎に前記ユーザ端末の一つの画面で表示可能な回答文に編集し、編集した回答文を前記電子メール手段を通じて前記ユーザ端末へ返信する段階と、
を有する電子メールによる運行経路探索方法。
【請求項６】
コンピュータを、
ユーザ端末との間で電子メールの送受信を行う電子メール手段、
自然文で記述された交通機関の経路探索の依頼メールを前記電子メール手段が受信したときに当該依頼メールに対する自然文解析を行うことにより、当該依頼メールから出発地、目的地及び時刻データを含む経路探索条件を抽出する自然言語処理ツール、
前記経路探索条件の入力を契機に、交通機関の路線情報及びダイヤ情報を含む運行情報を格納した運行情報ＤＢにアクセスして前記経路探索を実行することにより、前記経路探索条件に適合する経路候補のダイヤ情報を取得するとともに、この経路候補と同じ路線でその出発地における出発時刻よりも遅い時刻を当該出発地の出発時刻とする１又は複数の代替経路のダイヤ情報、又は、前記経路候補と同じ路線で当該経路候補における目的地の到着時刻よりも早い時刻をその目的地の到着時刻とする代替経路のダイヤ情報を取得する経路探索ツール、
取得した前記経路候補及び前記代替経路のダイヤ情報をマージするとともに、マージしたダイヤ情報を、前記出発地と前記目的地との間に登場する途中地の情報と共に、当該経路候補毎に前記ユーザ端末の一つの画面で表示可能な回答文に編集し、編集した回答文を前記電子メール手段を通じて前記ユーザ端末へ返信する制御手段、
として機能させるコンピュータプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【公開番号】特開２０１０−１３４８９２（Ｐ２０１０−１３４８９２Ａ）
【公開日】平成２２年６月１７日（２０１０．６．１７）
【国際特許分類】
【出願番号】特願２００９−５０６６９（Ｐ２００９−５０６６９）
【出願日】平成２１年３月４日（２００９．３．４）
【特許番号】特許第４３６４３００号（Ｐ４３６４３００）
【特許公報発行日】平成２１年１１月１１日（２００９．１１．１１）
【出願人】（５９６１３０１８５）株式会社 ヴァル研究所 (14)
【Ｆターム（参考）】
【公開日】平成２２年６月１７日（２０１０．６．１７）
【国際特許分類】
【出願日】平成２１年３月４日（２００９．３．４）
【特許番号】特許第４３６４３００号（Ｐ４３６４３００）
【特許公報発行日】平成２１年１１月１１日（２００９．１１．１１）
【出願人】（５９６１３０１８５）株式会社 ヴァル研究所 (14)
【Ｆターム（参考）】
[ Back to top ]