図面 (/)

技術 電子メールによる経路探索システム、経路探索方法、コンピュータプログラム

出願人 株式会社ヴァル研究所
発明者 宮本雅臣岸本英昭
出願日 2009年3月4日 (11年9ヶ月経過) 出願番号 2009-050669
公開日 2010年6月17日 (10年6ヶ月経過) 公開番号 2010-134892
状態 特許登録済
技術分野 計算機間の情報転送 鉄道交通の監視、制御、保安 航行(Navigation) 検索装置 特定用途計算機
主要キーワード 多数パターン 複数路 拡張処理後 到達所要 運行コスト 読み出しキー 対応ルール 混合文
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2010年6月17日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (16)

課題

1回の電子メールにより得られる経路探索結果の情報量を多くする。

解決手段

ユーザ端末30から自然文で記述された経路探索依頼メールを受信すると、自然言語処理ツール12で自然文解析して交通機関経路探索条件を抽出する。経路探索ツール13は、経路探索条件に適合する経路候補ダイヤ情報を特定するとともに、この経路候補と同じ路線でその出発地における出発予定時刻よりも遅い時刻を当該出発地の出発予定時刻とする1又は複数の代替経路のダイヤ情報、又は、経路候補と同じ路線でその目的地における到着予定時刻よりも早い時刻を当該目的地の到着予定時刻とする代替経路のダイヤ情報を取得する。主制御部10は、経路候補及び代替経路のダイヤ情報をマージし、マージしたダイヤ情報をユーザ端末30の一つの画面表示可能な回答文編集し、編集した回答文を電子メールでユーザ端末30へ返信する。

概要

背景

列車等の交通機関における最適な運行経路の探索技術については、昭和時代に本願出願人により開発され、多くのユーザの支持を得た経路探索ソフト「すぱあと」(登録商標非特許文献1参照)の登場以来、複数の企業技術者の手により幾多の改良・改善が試みられてきた。交通機関の経路探索において、出発地及び目的地が指定されたときの探索処理は、概ね以下のように行われている。

出発地に繋がるすべての路線(交通機関が、ある地点から他地点に至る経路)、駅について、経路の運行コスト(時間、距離、運賃等)が最小となる次の駅の探索処理を連鎖的に繰り返すことで、水面に石を投げたときの波紋のような形態で経路探索を行う。探索過程で目的地が特定された場合、その目的地と出発地との間の経路をユーザが望む経路候補とするとともに、さらにそこから派生する経路候補を多数パターン探索して保持し、ユーザが指定した探索条件に応じてソート可能にする。例えばユーザが指定した探索条件が最短時間の経路である場合は、保持されているパターンを時間でソートし、最短時間となるパターンの経路を最適経路候補とし、さらに、この最適経路候補との比較で、妥当ないくつか派生する代替経路を特定し、これらの経路を表示装置に表示させる。

携帯電話等の携帯端末通信ネットワーク及び電子メールが普及した今日では、これらのインフラを利用して経路探索を行う仕組みも種々提案されている。例えば、特許文献1に記載された「出発情報お知らせシステム及び終電情報お知らせシステム」では、現在位置及び移動位置を携帯端末に搭載されたGPS(測位システム)で測位し、最寄駅に向かって出発すべき時刻移動経路最寄り駅の情報をその携帯端末に電子メールで告知する。このシステムでは、携帯端末の表示画面の大きさに限りがあるので、情報を分割して表示する必要がある(特許文献1の段落0016、図8等参照)。

また、特許文献2に記載された「経路情報配信システム」では、携帯端末の所定の入力画面を通じて出発地情報目的地情報送信要求が入力されると、サーバは、出発地情報と目的地情報に基づいて経路探索を実行し、探索結果を保存するとともに、携帯端末の電子メールアドレスに対して、経路情報を記録した「http://www.foobar.com/hogehge?ID=0123abcd 」のようなURLをメール本文に埋め込んで返信し、URLを通じて経路送信要求のあった携帯端末に対してその経路情報を送信する(特許文献2の段落0022、23等参照)。このシステムでは、経路情報は、インターネットに接続してWebサイトアクセスする必要があるため、条件入力から経路情報を得るまでに時間がかかるという課題が残る。

携帯端末におけるデータ入力環境がパーソナルコンピュータ等と比べて充分でない点を考慮し、特許文献3に記載された「携帯端末装置」のように、電子メール生成時に、位置情報に基づいて場所や時間の粒度を埋め込んだテンプレート提示し、テンプレートに基づいて電子メールを生成することも行われている。しかし、この携帯端末装置では、テンプレートを用意しておかなければならないため、事前準備が必要となり、汎用性に欠けるという課題が残る。

以上の技術は、電子メールを、経路探索の条件入力あるいは経路情報の伝達に利用するものであるが、条件入力及び結果の出力をすべて電子メールで行う技術も提案されている。例えば特許文献4に記載された「経路案内システム」では、端末から送信された電子メールに含まれる経路探索条件情報に基づいて経路探索を実行し、経路探索結果情報を電子メールで端末に送信するとともに、送信した経路探索結果に基づいて経路案内を実行する案内時刻を設定し、設定した案内時刻に経路案内情報を含む電子メールを端末に送信する。
経路探索の要求又は指示の内容は、電子メールの件名と本文とで判断する。件名が空欄で本文に経路探索条件があるときは新規の経路探索の要求、件名が「Re〜」で本文に経路案内メール引用の場合は経路案内の中止の指示、件名が「Re〜」で本文に経路探索結果が引用されている場合は同じ経路探索条件での別の経路の再探索の指示、件名が「Re〜」で本文が空欄の場合は、探索経路を削除して経路案内を実行しない旨の指示となる(段落0045〜47)。

特許文献4のシステムによれば、ユーザは、専用のソフトウェアを組み込んだり、専用の装置を準備しなくても、広く普及している電子メールを利用して経路探索要求し、その結果を電子メールで直ぐに受信できる利点がある。経路案内サービスを提供する事業者にとっても設備投資も抑えることができ、便利である(段落0063)。
しかし、特許文献4のシステムでは、経路探索の中止や別の経路の再探索の指示を行うときは、本文に経路案内メール又は経路探索結果を引用するので(段落0045〜47)、同じパケットが少なくとも1往復されることになり、通信回線を無駄に使うばかりでなく、サーバ側で本文の内容に変更があるかどうかを調べなければならないという課題がある。
また、経路探索結果に時刻の情報が多数存在する場合、ユーザがわざわざ電子メールを送信して指示しない限り、同じ経路についての経路情報を何度も端末に電子メールが送信されるという煩わしさがある。

概要

1回の電子メールにより得られる経路探索結果の情報量を多くする。ユーザ端末30から自然文で記述された経路探索の依頼メールを受信すると、自然言語処理ツール12で自然文解析して交通機関の経路探索条件を抽出する。経路探索ツール13は、経路探索条件に適合する経路候補のダイヤ情報を特定するとともに、この経路候補と同じ路線でその出発地における出発予定時刻よりも遅い時刻を当該出発地の出発予定時刻とする1又は複数の代替経路のダイヤ情報、又は、経路候補と同じ路線でその目的地における到着予定時刻よりも早い時刻を当該目的地の到着予定時刻とする代替経路のダイヤ情報を取得する。主制御部10は、経路候補及び代替経路のダイヤ情報をマージし、マージしたダイヤ情報をユーザ端末30の一つの画面表示可能な回答文編集し、編集した回答文を電子メールでユーザ端末30へ返信する。

目的

本発明は、かかる背景のもと、ユーザに不便を意識させない利用環境を実現可能にする電子メールによる経路探索の仕組みを提供する

効果

実績

技術文献被引用数
0件
牽制数
2件

この技術が所属する分野

(分野番号表示ON)※整理標準化データをもとに当社作成

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

ユーザ端末との間で電子メールの送受信を行う電子メール手段と、自然文で記述された交通機関経路探索依頼メールを前記電子メール手段が受信したときに当該依頼メールに対する自然文解析を行うことにより、当該依頼メールから出発地目的地及び時刻データを含む経路探索条件を抽出する自然言語処理ツールと、前記経路探索条件の入力を契機に、交通機関の路線情報及びダイヤ情報を含む運行情報を格納した運行情報DBにアクセスして前記経路探索を実行することにより、前記経路探索条件に適合する経路候補のダイヤ情報を取得するとともに、この経路候補と同じ路線でその出発地における出発時刻よりも遅い時刻を当該出発地の出発時刻とする1又は複数の代替経路のダイヤ情報、又は、前記経路候補と同じ路線で当該経路候補における目的地の到着時刻よりも早い時刻をその目的地の到着時刻とする代替経路のダイヤ情報を取得する経路探索ツールと、取得した前記経路候補のダイヤ情報と前記代替経路のダイヤ情報とをマージするとともに、マージしたダイヤ情報を、前記出発地と前記目的地との間に登場する途中地の情報と共に、当該経路候補毎に前記ユーザ端末の一つの画面表示可能な回答文編集し、編集した回答文を前記電子メール手段を通じて前記ユーザ端末へ返信する制御手段と、を有する運行経路探索システム

請求項2

前記自然言語処理ツールは、前記依頼メールにひらがなが含まれるときに、当該ひらがなが、ひらがな以外の文字表現される前記経路探索条件の構成文字に相当するかどうかを判定し、相当するときは当該ひらがなを当該構成文字に変換した後に前記自然文解析を行う、請求項1記載の経路探索システム

請求項3

ユーザが入力した特定の地域、場所又は施設を表すランドマーク名と、当該ランドマーク名の最寄り駅及びそこまでの到達所要時間とを当該ユーザの識別情報と関連付けて登録するランドマーク登録手段を有しており、前記自然言語処理ツールは、登録されたランドマーク名を前記経路探索条件の構成文字に含めて前記自然文解析を行う、請求項1又は2記載の経路探索システム。

請求項4

交通機関の正式の路線名毎に、ユーザが任意に指定した1又は複数の通称路線名を、当該ユーザの識別情報と関連付けて登録する通称路線名登録手段を有しており、前記自然言語処理ツールは、登録された通称路線名を前記経路探索条件と共に前記依頼メールから抽出し、前記経路探索ツールは、前記自然言語処理ツールにより抽出された通称路線名を前記経路候補が複数存在するときの絞り込み条件として使用する、請求項1又は2記載の経路探索システム。

請求項5

ユーザ端末と電子メールの送受信を行う装置が実行する方法であって、前記ユーザ端末から、自然文で記述された経路探索の依頼メールを受信する段階と、受信した依頼メールに対する自然文解析を行うことにより、前記依頼メールから出発値、目的地及び時刻データを含む経路探索条件を抽出する段階と、交通機関の路線情報及びダイヤ情報を含む運行情報を格納した運行情報DBにアクセスして、前記抽出した経路探索条件に適合する経路候補のダイヤ情報を取得するとともに、この経路候補と同じ路線でその出発地における出発時刻よりも遅い時刻を当該出発地の出発時刻とする1又は複数の代替経路のダイヤ情報、又は、前記経路候補と同じ路線で当該経路候補における目的地の到着時刻よりも早い時刻をその目的地の到着時刻とする代替経路のダイヤ情報を取得する段階と、取得した前記経路候補及び前記代替経路のダイヤ情報をマージするとともに、マージしたダイヤ情報を、前記出発地と前記目的地との間に登場する途中地の情報と共に、当該経路候補毎に前記ユーザ端末の一つの画面で表示可能な回答文に編集し、編集した回答文を前記電子メール手段を通じて前記ユーザ端末へ返信する段階と、を有する電子メールによる運行経路探索方法

請求項6

コンピュータを、ユーザ端末との間で電子メールの送受信を行う電子メール手段、自然文で記述された交通機関の経路探索の依頼メールを前記電子メール手段が受信したときに当該依頼メールに対する自然文解析を行うことにより、当該依頼メールから出発地、目的地及び時刻データを含む経路探索条件を抽出する自然言語処理ツール、前記経路探索条件の入力を契機に、交通機関の路線情報及びダイヤ情報を含む運行情報を格納した運行情報DBにアクセスして前記経路探索を実行することにより、前記経路探索条件に適合する経路候補のダイヤ情報を取得するとともに、この経路候補と同じ路線でその出発地における出発時刻よりも遅い時刻を当該出発地の出発時刻とする1又は複数の代替経路のダイヤ情報、又は、前記経路候補と同じ路線で当該経路候補における目的地の到着時刻よりも早い時刻をその目的地の到着時刻とする代替経路のダイヤ情報を取得する経路探索ツール、取得した前記経路候補及び前記代替経路のダイヤ情報をマージするとともに、マージしたダイヤ情報を、前記出発地と前記目的地との間に登場する途中地の情報と共に、当該経路候補毎に前記ユーザ端末の一つの画面で表示可能な回答文に編集し、編集した回答文を前記電子メール手段を通じて前記ユーザ端末へ返信する制御手段、として機能させるコンピュータプログラム

技術分野

0001

本発明は、ユーザにとって快適な交通機関経路探索環境を実現可能にする電子メールを用いた経路探索技術に関する。

背景技術

0002

列車等の交通機関における最適な運行経路の探索技術については、昭和時代に本願出願人により開発され、多くのユーザの支持を得た経路探索ソフト「すぱあと」(登録商標非特許文献1参照)の登場以来、複数の企業技術者の手により幾多の改良・改善が試みられてきた。交通機関の経路探索において、出発地及び目的地が指定されたときの探索処理は、概ね以下のように行われている。

0003

出発地に繋がるすべての路線(交通機関が、ある地点から他地点に至る経路)、駅について、経路の運行コスト(時間、距離、運賃等)が最小となる次の駅の探索処理を連鎖的に繰り返すことで、水面に石を投げたときの波紋のような形態で経路探索を行う。探索過程で目的地が特定された場合、その目的地と出発地との間の経路をユーザが望む経路候補とするとともに、さらにそこから派生する経路候補を多数パターン探索して保持し、ユーザが指定した探索条件に応じてソート可能にする。例えばユーザが指定した探索条件が最短時間の経路である場合は、保持されているパターンを時間でソートし、最短時間となるパターンの経路を最適経路候補とし、さらに、この最適経路候補との比較で、妥当ないくつか派生する代替経路を特定し、これらの経路を表示装置に表示させる。

0004

携帯電話等の携帯端末通信ネットワーク及び電子メールが普及した今日では、これらのインフラを利用して経路探索を行う仕組みも種々提案されている。例えば、特許文献1に記載された「出発情報お知らせシステム及び終電情報お知らせシステム」では、現在位置及び移動位置を携帯端末に搭載されたGPS(測位システム)で測位し、最寄駅に向かって出発すべき時刻移動経路最寄り駅の情報をその携帯端末に電子メールで告知する。このシステムでは、携帯端末の表示画面の大きさに限りがあるので、情報を分割して表示する必要がある(特許文献1の段落0016、図8等参照)。

0005

また、特許文献2に記載された「経路情報配信システム」では、携帯端末の所定の入力画面を通じて出発地情報目的地情報送信要求が入力されると、サーバは、出発地情報と目的地情報に基づいて経路探索を実行し、探索結果を保存するとともに、携帯端末の電子メールアドレスに対して、経路情報を記録した「http://www.foobar.com/hogehge?ID=0123abcd 」のようなURLをメール本文に埋め込んで返信し、URLを通じて経路送信要求のあった携帯端末に対してその経路情報を送信する(特許文献2の段落0022、23等参照)。このシステムでは、経路情報は、インターネットに接続してWebサイトアクセスする必要があるため、条件入力から経路情報を得るまでに時間がかかるという課題が残る。

0006

携帯端末におけるデータ入力環境がパーソナルコンピュータ等と比べて充分でない点を考慮し、特許文献3に記載された「携帯端末装置」のように、電子メール生成時に、位置情報に基づいて場所や時間の粒度を埋め込んだテンプレート提示し、テンプレートに基づいて電子メールを生成することも行われている。しかし、この携帯端末装置では、テンプレートを用意しておかなければならないため、事前準備が必要となり、汎用性に欠けるという課題が残る。

0007

以上の技術は、電子メールを、経路探索の条件入力あるいは経路情報の伝達に利用するものであるが、条件入力及び結果の出力をすべて電子メールで行う技術も提案されている。例えば特許文献4に記載された「経路案内システム」では、端末から送信された電子メールに含まれる経路探索条件情報に基づいて経路探索を実行し、経路探索結果情報を電子メールで端末に送信するとともに、送信した経路探索結果に基づいて経路案内を実行する案内時刻を設定し、設定した案内時刻に経路案内情報を含む電子メールを端末に送信する。
経路探索の要求又は指示の内容は、電子メールの件名と本文とで判断する。件名が空欄で本文に経路探索条件があるときは新規の経路探索の要求、件名が「Re〜」で本文に経路案内メール引用の場合は経路案内の中止の指示、件名が「Re〜」で本文に経路探索結果が引用されている場合は同じ経路探索条件での別の経路の再探索の指示、件名が「Re〜」で本文が空欄の場合は、探索経路を削除して経路案内を実行しない旨の指示となる(段落0045〜47)。

0008

特許文献4のシステムによれば、ユーザは、専用のソフトウェアを組み込んだり、専用の装置を準備しなくても、広く普及している電子メールを利用して経路探索要求し、その結果を電子メールで直ぐに受信できる利点がある。経路案内サービスを提供する事業者にとっても設備投資も抑えることができ、便利である(段落0063)。
しかし、特許文献4のシステムでは、経路探索の中止や別の経路の再探索の指示を行うときは、本文に経路案内メール又は経路探索結果を引用するので(段落0045〜47)、同じパケットが少なくとも1往復されることになり、通信回線を無駄に使うばかりでなく、サーバ側で本文の内容に変更があるかどうかを調べなければならないという課題がある。
また、経路探索結果に時刻の情報が多数存在する場合、ユーザがわざわざ電子メールを送信して指示しない限り、同じ経路についての経路情報を何度も端末に電子メールが送信されるという煩わしさがある。

0009

「駅すぱあと」風録 柏崎ほか 日経BP社2006年3月20日発行

先行技術

0010

特開2002−131075号公報
特開2002−296067号公報
特開2008−046840号公報
特開2007−232441号公報

発明が解決しようとする課題

0011

Webのような双方向の媒体の場合、経路探索のための条件入力やその変更は、対話的に得ることができるため容易であるが、基本的に一方向の情報しか得られない電子メールでは、それは難しい。特許文献4についての上記問題は、媒体が電子メールであるために生じる問題である。この問題は、1回の返信メールに多くの情報をまとめて詰め込むことにより緩和される期待がある。
本発明は、かかる背景のもと、ユーザに不便を意識させない利用環境を実現可能にする電子メールによる経路探索の仕組みを提供することを主たる課題とする。

課題を解決するための手段

0012

上記課題を解決するため、本発明は、経路探索システム経路探索方法及びコンピュータプログラムを提供する。
本発明の経路探索システムは、ユーザ端末との間で電子メールの送受信を行う電子メール手段と、自然文で記述された交通機関の経路探索の依頼メールを前記電子メール手段が受信したときに当該依頼メールに対する自然文解析を行うことにより、当該依頼メールから出発地、目的地及び時刻データを含む経路探索条件を抽出する自然言語処理ツールと、前記経路探索条件の入力を契機に、交通機関の路線情報及びダイヤ情報を含む運行情報を格納した運行情報DBにアクセスして前記経路探索を実行することにより、前記経路探索条件に適合する経路候補のダイヤ情報を取得するとともに、この経路候補と同じ路線でその出発地における出発時刻よりも遅い時刻を当該出発地の出発時刻とする1又は複数の代替経路のダイヤ情報、又は、前記経路候補と同じ路線で当該経路候補における目的地の到着時刻よりも早い時刻をその目的地の到着時刻とする代替経路のダイヤ情報を取得する経路探索ツールと、取得した前記経路候補のダイヤ情報と前記代替経路のダイヤ情報とをマージするとともに、マージしたダイヤ情報を、前記出発地と前記目的地との間に登場する途中地の情報と共に、当該経路候補毎に前記ユーザ端末の一つの画面表示可能な回答文編集し、編集した回答文を前記電子メール手段を通じて前記ユーザ端末へ返信する制御手段と、を有する。

0013

ユーザ端末から自然文で依頼メールを発信すると、経路探索システムは、自然言語処理ツールでその依頼メールに記述されている経路探索条件を抽出し、経路探索ツールでその経路探索条件に基づく経路候補及びその前後の代替経路のダイヤ情報をマージし、制御手段で、マージしたダイヤ情報を前記ユーザ端末の一つの画面で表示可能な回答文に編集し、編集した回答文を電子メール手段を通じてユーザ端末へ返信するので、ユーザは、経路探索条件を自然文で記述した依頼メールを送信するだけで、経路候補のダイヤ情報と、その経路候補の前後の時間帯の代替経路のダイヤ情報とがマージされた回答文を電子メールで受け取ることができ、1回の電子メールの送受信だけで、数回文の経路探索の結果の受け渡しが可能となる。

0014

自然言語処理ツールは、前記依頼メールにひらがなが含まれるときに、当該ひらがなが、ひらがな以外の文字表現される前記経路探索条件の構成文字に相当するかどうかを判定し、相当するときは当該ひらがなを当該構成文字に変換した後に前記自然文解析を行う。これにより、ユーザは、ひらがなによる依頼メールを出すことができるので、漢字等への変換作業が不要となり、ユーザの操作負担が軽減される。

0015

ある実施の態様では、ユーザが入力した特定の地域、場所又は施設を表すランドマーク名と、当該ランドマーク名の最寄り駅及びそこまでの到達所要時間とを当該ユーザの識別情報と関連付けて登録するランドマーク登録手段を有しており、前記自然言語処理ツールは、登録されたランドマーク名を前記経路探索条件の構成文字に含めて自然文解析を行う。これにより、駅から離れた場所での経路探索が可能になる。

0016

ある実施の態様では、交通機関の正式の路線名毎に、ユーザが任意に指定した1又は複数の通称路線名を、当該ユーザの識別情報と関連付けて登録する通称路線名登録手段を有しており、前記自然言語処理ツールは、登録された通称路線名を前記経路探索条件と共に前記依頼メールから抽出し、前記経路探索ツールは、前記自然言語処理ツールにより抽出された通称路線名を前記経路候補が複数存在するときの絞り込み条件として使用する。これにより、経路探索結果が複数路線になるときの絞り込みが容易になる。

0017

本発明の経路探索方法は、ユーザ端末と電子メールの送受信を行う装置が実行する方法であって、前記ユーザ端末から、自然文で記述された経路探索の依頼メールを受信する段階と、受信した依頼メールに対する自然文解析を行うことにより、前記依頼メールから出発値、目的地及び時刻データを含む経路探索条件を抽出する段階と、交通機関の路線情報及びダイヤ情報を含む運行情報を格納した運行情報DBにアクセスして、前記抽出した経路探索条件に適合する経路候補のダイヤ情報を取得するとともに、この経路候補と同じ路線でその出発地における出発時刻よりも遅い時刻を当該出発地の出発時刻とする1又は複数の代替経路のダイヤ情報、又は、前記経路候補と同じ路線で当該経路候補における目的地の到着時刻よりも早い時刻をその目的地の到着時刻とする代替経路のダイヤ情報を取得する段階と、取得した前記経路候補及び前記代替経路のダイヤ情報をマージするとともに、マージしたダイヤ情報を、前記出発地と前記目的地との間に登場する途中地の情報と共に、当該経路候補毎に前記ユーザ端末の一つの画面で表示可能な回答文に編集し、編集した回答文を前記電子メール手段を通じて前記ユーザ端末へ返信する段階と、を有する電子メールによる運行経路探索方法である。

0018

本発明のコンピュータプログラムは、コンピュータを、ユーザ端末との間で電子メールの送受信を行う電子メール手段、自然文で記述された交通機関の経路探索の依頼メールを前記電子メール手段が受信したときに当該依頼メールに対する自然文解析を行うことにより、当該依頼メールから出発地、目的地及び時刻データを含む経路探索条件を抽出する自然言語処理ツール、前記経路探索条件の入力を契機に、交通機関の路線情報及びダイヤ情報を含む運行情報を格納した運行情報DBにアクセスして前記経路探索を実行することにより、前記経路探索条件に適合する経路候補のダイヤ情報を取得するとともに、この経路候補と同じ路線でその出発地における出発時刻よりも遅い時刻を当該出発地の出発時刻とする1又は複数の代替経路のダイヤ情報、又は、前記経路候補と同じ路線で当該経路候補における目的地の到着時刻よりも早い時刻をその目的地の到着時刻とする代替経路のダイヤ情報を取得する経路探索ツール、取得した前記経路候補及び前記代替経路のダイヤ情報をマージするとともに、マージしたダイヤ情報を、前記出発地と前記目的地との間に登場する途中地の情報と共に、当該経路候補毎に前記ユーザ端末の一つの画面で表示可能な回答文に編集し、編集した回答文を前記電子メール手段を通じて前記ユーザ端末へ返信する制御手段、として機能させるコンピュータプログラムである。

発明の効果

0019

本発明によれば、経路候補毎に、その前後に利用できる列車のダイヤ情報がマージされた回答文がユーザ端末に返信されるので、対話的なインタフェースを持たない場合であっても、経路候補を通るダイヤ情報と、その列車に乗り遅れた場合や余裕を持って移動したい場合の代替ダイヤ情報を1つの乗り換えリストとしてまとめて提示することができ、一方向の情報伝達媒体である電子メールを使用した場合の課題を解決することができる。
すなわち、従来の経路探索サービスアプリケーションでは、最適乗換情報の提供や、別の列車を使った乗り換え時刻の提供を行うことができたが、これらは経路と列車が独立したダイヤ情報の形で利用者に提供されていた。本発明によれば、これらを有機的に1つの情報としてまとめることができるので、伝達する情報の密度上がり、電子メールのような一度に限られた対話しかできないインタフェースでも効率的に情報を提供できるようになる。また、従来の経路探索サービス/アプリケーションでは、ユーザが明示的に代替列車を探す必要があったが、本発明によれば、代替列車が最適経路と同時に提供されるため、ユーザは、1回の探索で、代替列車のある安心な経路情報を得ることができる。
代替列車の情報を得る手段として時刻表があるが、目的地までの乗り換え方法を含む路線の情報が得られない。本発明によれば、このような情報も同時に得ることができる。

図面の簡単な説明

0020

本発明を適用した経路探索システムの全体構成図。
自然言語処理ツールによる自然文解析処理手順説明図。
通称路線名を指定して経路候補を絞り込む場合の手順説明図。
経路候補が絞り込まれた状態を示した説明図。
ダイヤ検索の手順説明図(概要)。
ダイヤ検索の手順説明図(時刻バリエーション拡張処理)。
ユーザが依頼メールにより経路探索を依頼し、その結果を返信メールで受け取るまでの主制御部の制御手順を示した図。
ユーザがWebアクセスにより経路探索の条件を修正して経路探索結果を再取得するときの主制御部の制御手順を示した図。
経路候補(第1経路)とその代替経路の例を示した図。
図9の2つの経路をマージした状態を示した図。
依頼メールに含まれる依頼文の例を示した図。
携帯端末の表示画面に表示される[経路1]についての経路候補とその代替経路のダイヤ情報を含む回答文の例を示した図。
携帯端末の表示画面に表示される[経路2]についての経路候補とその代替経路のダイヤ情報を含む回答文の例を示した図。
携帯端末の表示画面に表示される[経路3]についての経路候補とその代替経路のダイヤ情報を含む回答文の例を示した図。
Webアクセスにより携帯端末の表示画面に表示される経路探索条件の入力画面。

実施例

0021

本発明を、携帯端末向けの交通機関の経路探索サービスを可能にするネットワーク型の経路探索システムに適用した場合の実施の形態例を説明する。
[全体構成]
図1は、この実施形態の経路探索システムの全体構成図であり、特徴的な部分のみを掲示してある。本実施形態では、携帯電話網N1及びインターネットN2に接続され、電子メールとWeb通信の併用による列車の経路探索サービスを実現する経路探索システム1の例を示す。ユーザは、メール機能及びWebブラウザ機能を備えた携帯端末30、例えば携帯電話で、経路探索システム1にアクセスする。

0022

この経路探索システム1は、記憶装置を備えたサーバ本体を有し、このサーバ本体が本発明のコンピュータプログラムを実行することにより、サーバ本体を、主制御部10、メール送受信部11、自然言語処理ツール12、経路探索ツール13、自然文編集ツール14、登録ツール15、通信制御部16として機能させるとともに、記憶装置内に、ルールDB(DBはデータベースの略、以下同じ)21、ユーザ情報DB22、運行情報DB23、駅名候補DB24、ランドマークDB25及び通称路線DB26を構築する。

0023

ルールDB21には、自然言語処理ツール12が参照する文法ファイル、各種辞書ファイル及び意味解析のための知識ベースと、経路探索条件の候補となる複数の条件候補データを抽出するための抽出ルール及び複数の条件候補データの中から最適条件候補データ選定するための候補選定ルールとが格納されている。条件候補データ及び最適条件候補データは、いずれも経路探索ツール13に入力する経路探索条件の一つとなり得るものである。

0024

経路探索条件は、複数の構成文字を組み合わせたもの、すなわち、出発地、目的地、経由地、時刻データ、後述するランドマーク名及び路線名(後述する通称路線名を含む)の組み合わせたものである。但し、これらをすべて含んだものが経路探索条件となるのではなく、通常は、一部の組み合わせとなる。必須となるのは、出発地と目的地の組み合わせである。
便宜上、この実施形態において、条件候補データは、出発地、目的地又は経由地となり得る駅名候補データ及びランドマーク名、時刻データ、路線名であるものとする。

0025

条件候補データの抽出ルールは、例えばひらがな/片仮名/ローマ字混合文字に対応する正式表現名の対応ルール、同名他駅に対応する候補表現(例えば「中野」に対する中野(東京都)、中野(群県)、中野(長野県)、中野上、中野栄・・・)の対応ルール、経路探索実行依頼と共に経路探索ツール13に伝えるときの探索条件ルール、すなわち2つの駅名候補データだけ入力されたときは駅間の平均経路の探索と解釈する等である。また、出発地と目的地とを区別する以下のようなルールも抽出ルールに含まれる。
固有名詞間の助詞
谷から新宿まで」→出発地:渋谷、目的地:新宿
・固有名詞の位置関係
「渋谷新宿」→出発地:渋谷、目的地:新宿
日本語係り受け関係
「渋谷を11時に出発、新宿は到着駅」→出発地:渋谷、目的地:新宿
名詞間記号類
「出発:渋谷、到着:新宿」→出発地:渋谷、目的地:新宿
「新宿←渋谷」→出発地:渋谷、目的地:新宿
・他の駅の確定内容に基づく他の駅
「新宿まで、渋谷」→出発地:渋谷、目的地:新宿
文節の位置関係による強制解決
「渋谷は到着、新宿は到着」→出発地:渋谷、目的地:新宿
「渋谷は出発、新宿から」→出発地:渋谷、目的地:新宿
「池袋から中野まで」→出発地:「池袋」、目的地:「中野(東京都)」

0026

候補選定ルールは、以下のようなものである。
・運行コストが最小となる駅の組み合わせであること
「中野池袋」→「中野」と「池袋」に分断され、「中野」からは「中野(東京都)」、「中野(群馬県)」、「中野(長野県)」、「中野坂上」、「中野栄」が導出されるが、運行コストが最小となるのは、出発地:「中野(東京都)」、到着地:「池袋」である。
・過去に参照した履歴がある場合はそれを利用
「長野の中野から池袋まで」→「中野」は「中野(長野県)」
鉄道同士、空港同士を最優先
・県同士が最も近い駅の組み合わせを最優先

0027

ユーザ情報DB22には、ユーザの固有情報登録メールアドレス利用ログ等が、ユーザID等により相互に関連付けて格納される。

0028

運行情報DB23には、交通機関(鉄道/バス航空機)の路線、ダイヤ情報(時刻情報)、運賃情報、駅リストを含む、運行経路の探索に必要なすべての運行情報が格納される。この運行情報は、随時更新される。

0029

駅名候補DB24には、自然言語処理ツール12による自然文解析により特定されたすべての駅名候補データが格納される。これらのデータは、携帯端末30から電子メールを受信したときに採番される探索IDと関連付けて格納される。読み出すときは、この探索IDを読み出しキーとして用いる。

0030

ランドマークDB25には、ユーザが任意に選定した場所、施設等をランドマーク名で表し、そこからの最寄駅及びそこまでの移動所要時間が、ユーザの固有情報と関連付けて格納される。例えば、株式会社ヴァル研究所の固有情報と関連付けて「ヴァル」というランドマーク名を登録し、この「ヴァル」について、最寄駅が高円駅、そこまでの移動所要時間が徒歩6分という情報を登録する。ランドマーク名は、経路探索時に、駅名候補データと同様に扱われ、最寄駅からの距離が長いときの総所要時間、最寄駅が複数あるときの最適経路の選択等のために用いられる。

0031

通称路線DB26には、正式な路線名(例えば「JR中央・青梅線青梅特快」)と、ユーザが覚えやすい任意の通称名(例えば「JR線」又は「青梅線」)とをユーザの固有情報と関連付けて格納される。携帯端末30では、表示画面上に多くの経路を表示できないため、使用したい路線のイメージがあっても、その経路を見つけるのが困難となる。路線名を経路探索条件(絞り込みの条件)として指定したい場合であっても、正式な路線名(表示される路線名)をユーザが正確に入力するのは難しい。そこで、一つの正式な路線名に対して、その路線名を簡略化した通称路線名を複数件対応付けて登録しておき、一つの正式路線名を様々な名前で指定できるようにした。通称路線名はシステム中、一意でなくても良い。ユーザが指定した通称路線名から複数の正式路線名を対等に扱うことで、経路探索結果の絞り込みを容易にすることができる。

0032

主制御部10は、経路探索に関する各種処理を実現するために以下の各機能ブロック11〜16の起動を含む動作の制御を行う。制御手順については、後述する。

0033

メール送受信部11は、携帯電話網N1を介して携帯端末30との間で、登録メールアドレスを用いた電子メールの受け渡しを行う。以後、経路探索の依頼文を含む電子メールを依頼メール、その回答文を含む電子メールを返信メールとする。
受信時は、依頼メールのヘッダ部からユーザの登録メールアドレスを抽出し、これを図示しないアドレステーブルに一時的に記録する。返信時は、このアドレステーブルに記録されている登録メールアドレス宛に返信メールを送信する。通信制御部16は、後述する権限情報に基づきインターネットN2を介してアクセスした携帯端末30に対してWebサービスを提供するための制御を行う。

0034

自然言語処理ツール12は、メール送受信部11で受信した依頼メールの例えば本文部に記述されている依頼文に対してルールDB21に格納されている文法ファイル、辞書ファイル、知識ベース、各種ルールに基づき、自然文解析処理を施し、複数の駅名候補データ、時刻データ等を抽出する。

0035

[自然文解析処理]
図2は、自然言語処理ツール12による自然文解析処理の手順説明図である。ここでは「3時に東京からヴァル」という自然文(一部半角文字、登録されたランドマーク有り)が入力されたものとする。
自然言語処理ツール12は、まず、前処理で表記統制を行う。表記統制は、半角文字を全角文字にしたり、バイナリ改行を削除したり、文字数指定文字数カットする処理である。これにより、構文解析文法簡易なものにすることができる。

0036

その後、ひらがなクエリー判定を行う。この処理は、依頼文をクエリー(コンピュータが認識できる要求コマンド)とし、ひらがなのクエリーを駅名(又はランドマーク)を表す構成文字として解釈する(抽出する)処理である。また、抽出した駅名候補データが1個の場合は用途不明、駅名候補データが2個の場合は出発地と目的地があると解釈する。駅名候補データが3個の場合は出発地、経由地、目的地があると解釈する。ひらがなクエリー判定後、ランドマーク名変換を行う。ランドマーク変換は、クエリーからランドマーク名を探し、そのランドマーク名を形態素解析用の文字列に変換する処理である。

0037

以上の一連の処理を終えた後、日本語解析を行う。日本語解析は、クエリーの文章を日本語の形態素と文節の並びに変換する処理である。本実施形態では、形態素を語句IDに変換して図示しないメモリ領域に記憶する。その結果、日本語解析の結果は、語句IDの並びとなる。語句IDとは、ルールDB21に格納されている文法ファイルに出現する語句に対し、出現順に数値割り当てたものである。ID化して扱うことにより、非常に大きな負荷がかかる駅名候補データの抽出処理高速に行うことができる。

0038

日本語解析を終えると、自然言語処理ツール12は、共に日本語解析結果を取得し、ルールDB21の辞書ファイルを用いて格候補抽出を行う。「格」は形態素や文節に意味を与えるためのものであり(「彼が」はガ格、「彼を」はヲ格)、「格候補」は「格」を形成し得る文節のまとまりをすべての可能性に対して抽出したデータの構造をいう。候補として扱うため、最終的に「格」として選択されないものも抽出する。例えば、「東京」は場所名のほか「東京駅」とも解釈され得るため、2つの格候補が抽出される。3時は「h=3」のように表現を統一する。

0039

格候補抽出後は、署名格候補を削除する。署名は電子メールの本文部の最後に記載される定型文である。「品川太郎」のように、駅名ともとれる人名又は住所表記があると駅名候補データと誤認識するおそれがあるため、署名と思われる行から格候補を削除する。その後、格候補最適化を行う。すなわち、抽出した格候補をどのように組み合わせれば、一文全体で最適な解釈となるかを総当たりで評価する。このようにして確定した格候補について、意味解析を行う。ここでは、特に、時刻と日付の解釈を行い、具体的な日時を数値で表現する。その結果、自然言語処理ツール12からは、図右側上段の出力が得られる。

0040

このようにして、依頼メールに含まれる語、語句、文を抽出し、抽出した語、語句又は文とルールDB21に格納されている条件候補の抽出ルールに基づいて、複数の駅名候補データを抽出する。路線名や時刻データが含まれているときは、これらも抽出する。また、ルールDB21に格納されている候補選定ルールに基づいて複数の駅名候補データの組み合わせ(路線、時刻データが含まれている場合はこれらも加えた組み合わせ)のうち、上記条件選定ルールに従えば最もあり得るいずれか一組を、ユーザの意図を反映していると推定される最適な駅名候補データの組み合わせである経路探索条件として選定する。

0041

[経路探索]
経路探索ツール13は、経路探索条件の入力を契機に、運行情報DB23、ランドマークDB25及び通称路線DB26に蓄積されている情報をもとに、交通機関による運行コストが最も小さい次の駅(又はランドマーク名)の探索処理を、水面に石を投げたときの波紋のように連鎖的に繰り返すことにより、経路探索条件に従う経路候補及びそのダイヤ情報を特定する。運行コストは通常は時間を対象とするが、距離、運賃を用いても良く、あるいは、これらの組み合わせを対象としても良い。経路探索ツール13は、推論エンジンも搭載しており、探索途中現実的でない経路となることが判明した場合は、その経路についての次の駅以降の探索を止める。なお、経路探索ツール13のうち、経路探索機能の部分は、例えば本願出願人が提供している経路探索ソフトウエア「駅すぱあと」(登録商標)のものを使用することができる。

0042

本実施形態では、自然言語処理ツール12が、上記のようにして依頼文から抽出した複数の駅名候補データ(存在する場合は路線名や時刻データを含む)のうち、最適な組み合わせを経路探索条件として、経路探索ツール13に入力するが、経路候補が多数になる場合は、通称路線名で経路候補を絞り込む。

0043

このことを図3及び図4を参照して詳しく説明する。
通称名称DB26には、予め表示に使用する正式な路線名称から通称路線名を複数個登録しておくことは、上述の通りである。ユーザは、経路探索を行うときに、図3に示すように、出発地、目的地のほかに、使いたい路線名を通称路線名で指定する(ステップS11)。経路探索ツール13は、経路探索を行い(ステップS12)、複数の経路候補を特定する過程で(ステップS13)、通称路線DB26へアクセスして通称路線名検索を行い(ステップS14)、ユーザが指定した通称路線名に一致した通称路線名に関連付けられたすべての正式路線名を取得する(ステップS15)。そして、ステップS13で特定した複数の経路候補を、取得した正式路線名を含む経路候補のみに絞り込み(ステップS16)、絞り込んだ経路候補を探索結果として出力する(ステップS17)。

0044

図4の例でいえば、ユーザが通称路線名Aを指定したとすると、通称路線DB26から通称路線名Aに関連付けられた正式路線名#1と正式路線名#2とを取得する。経路探索結果として「経路#1」、「経路#2」、「経路#3」が特定され、「経路#1」には正式路線名#3と正式路線名#4が含まれ、「経路#2」には正式路線名#1と正式路線名#5が含まれ、「経路#3」には正式路線名#6が含まれていたとすると、絞り込みにより、「経路#2」のみが探索結果として出力される。
なお、以上は、ユーザが指定した経路候補を使用する場合の例であるが、指定した経路候補を使用しない場合には、正式路線名を含む経路候補を出力しないようにすれば良い。

0045

経路候補及びそのダイヤ情報を特定すると、経路探索ツール13は、その経路候補の代替経路についてのダイヤ検索を行う。このダイヤ検索の手順を図5及び図6を参照して説明する。
図5を参照すると、経路探索ツール13は、経路候補のダイヤ検索結果を取得する(ステップS1)。検索結果の最後の経路まで処理した場合は終了する(ステップS2:Yes)。検索結果の最後の経路まで処理していない場合は(ステップS2:No)、処理済の路線かどうかを判定し、処理済であればステップS2の処理に移る(ステップS3:Yes)。処理済の路線でなければ、時刻バリエーションの拡張処理を行う(ステップS3:No、S4)。

0046

時刻バリエーションの拡張処理は、図6の手順で行われる。
すなわち、元の経路、つまり上述した経路候補と同一の路線における一つ前の最適ダイヤ(到着時刻−1分以前、−60分までに到着できる効率的なダイヤ)、または、次の最適ダイヤ(出発時刻+1分以降、+60分までに出発する効率的なダイヤ)となるようなダイヤ検索結果を取得し、これを代替経路のダイヤ情報とする(ステップS41)。元の経路(経路候補)より取得したダイヤ検索結果の最後の列車まで処理したかどうかを判定し、処理した場合、つまり、代替経路が無い場合は終了する(ステップS42:Yes)。最後の列車まで処理していない場合は、代替経路があることを意味するので、マージ(ダイヤ情報の統合)の対象になるかどうかを判定する(ステップS42:Yes、S43)。
マージ対象となるのは、料金、通過駅一覧(停車するかどうかを問わず)、営業距離が一致し、且つ、初めの出発時刻から60分以内であることが条件となる。マージ対象となる場合は、元の経路である経路候補に代替経路のダイヤ情報をマージする(ステップS43:Yes、S44)。他方、マージ対象とならない場合は、新たに見つかった別経路(別の行き方)としてこのダイヤ情報を保持する(ステップS43:No、S45)。
以上の手順を表示時刻数分のダイヤ情報が揃うまで繰り返し(ステップS46:No)、揃った場合は終了する(ステップS46:Yes)。

0047

図5戻り、時刻バリエーションの拡張処理後は、予め設定された表示経路数分のダイヤ情報が揃ったかどうかを判定する(ステップS5)。揃った場合は終了する(ステップS5:Yes)。揃わない場合は、時刻バリエーション拡張処理で新たに別経路が見つかったかどうかを調べる(ステップS5:No、S6)。見つかっていない場合はステップS2の処理に戻る(ステップS6:No)。見つかった場合は、ダイヤ検索結果の経路に新たに見つかった別経路を追加してステップS2の処理に戻る(ステップS6:Yes、S7)。
これにより、最適経路とその1本前又は1本後のように、幅のあるダイヤ情報を、電子メールという一方向の情報伝達媒体を使用する場合においても利用者にとって違和感のない形で提供することができる。

0048

経路探索の結果、出発地と目的地とが同じであっても、ダイヤ構築の関係上、常に同じ経路にならず、経路候補が複数になる場合がある。この場合は、運行コストが小さい順に「経路1」、「経路2」、「経路3」のように特定し、各々の経路において上記代替経路のダイヤ情報を特定する。例えば、新宿から横に行く場合の例を挙げる。利用者は、出発時間帯予算、好みなどに応じて、以下の数通りの経路を選択することができる。
新宿→(JR)→横浜
新宿→(JR)→渋谷→(東急)→横浜
新宿→(JR)→品川→(京急)→横浜
新宿→(JR)→東京→(JR)→横浜
新宿→(JR)→東京→(特急)→横浜
本実施形態では、これらの経路の各々を経路候補とし、各経路候補のそれぞれについて、上述した代替経路のダイヤ情報を特定する。

0049

自然文編集ツール14は、経路探索ツール13により特定された経路候補及び代替経路のダイヤ情報を一つのダイヤ情報にマージする。
ここで、マージの意味合いを具体的に説明する。便宜上、東京発、津到着の例を挙げる。図9左側は経路候補、右側はその代替経路(便宜上、その1本後の列車とする)である。図9の例では、「JR快速アクティー・熱海行き」と「JR東海道本線」は、利用者は同じ路線と認識するが、従前の経路探索技術では、1本違うだけの列車であっても別経路と認識する。そのため、これらを単純に一つの画面に表示することはできない。仮に一つの画面に表示できたとしても、利用者の感覚からすれば、違和感のある探索結果となる場合があり、この場合は実用性が低下するおそれがある。
本実施形態では、上述したマージ対象かどうかの基準に従い、各ダイヤ情報を経路候補毎にマージするとともに、マージしたダイヤ情報を、出発駅目的駅との間に登場する途中駅の情報と共に、経路候補毎に一つの画面で表示できるように編集する。通過駅については表示されないようにする。その結果、図9の2つの経路のダイヤ情報は、図10のようにマージされる。
経路候補が複数となる場合は、それぞれの経路候補のダイヤ情報について代替経路のダイヤ情報とマージし、それらを一つの画面で表示することができるようにする。これにより、情報の網羅性についての利点がある。このマージされた各情報を初期探索結果とする。

0050

その後、初期探索結果、探索ID、及び、依頼メールの発信元が経路探索ツール13に事後的にWeb通信によりアクセスするための権限情報を、携帯端末30の一つの画面に表示させる回答文として編集し、この回答文を含む返信メールを作成する。このとき、携帯端末30のディスプレイは小さいし、解像度も低いので、余分な情報を取り除き、なるべく少ないパケット数で且つなるべく一画面で表示することができ、しかし必要な情報は盛り込むように編集する。この返信メールは、メール送受信部11から依頼メールの発信元に返信される。

0051

登録ツール15は、ユーザの固有情報、メールアドレス、ランドマーク名、通称路線名、各種ルール、サービス条件設定等の登録を受け付ける。登録したユーザの固有情報は、ユーザ情報DB22に格納される。登録されたメールアドレスが登録メールアドレスとなる。ランドマーク名はランドマークDB25に格納される。通称路線名は通称路線DB26に格納される。

0052

運用形態
次に、上記のように構成される経路探索システム1の運用形態例を説明する。

0053

ユーザは、登録メールアドレスを用いて経路探索システム1の専用アドレスに依頼メールを発信することによって、経路探索システム1は動作を開始する。本例では、図11に示すように、ユーザが、「ヴァル つくばエクスプレス浅草」のような依頼文を記述した依頼メールを発信したものとする。「ヴァル」は、JRの高円寺駅までの移動所要時間が5分の株式会社ヴァル研究所のランドマーク名、つくばエクスプレスは路線である。このランドマーク名も駅名候補データの一つとして扱われる。

0054

主制御部10は、図7の手順で制御動作を開始する。すなわち、この依頼メールを受信すると(ステップS101:Yes)、発信元の登録メールアドレスをアドレスメモリ(図示省略)に記録する(ステップS102)。また、その依頼メールに対して探索IDを採番し(ステップS103)、この探索IDを駅名候補DB24に格納する(ステップS104)。

0055

探索IDを格納すると、主制御部10は、自然言語処理ツール12を起動する。自然言語処理ツール12は、依頼メールに記述されている依頼文に対して自然文解析を行うことにより、複数の駅名候補データを抽出する。そして、抽出した複数の駅名候補データを、駅名候補DB24に格納されている探索IDと関連付けて保存する(ステップ105)。保存が終了すると、自然言語処理ツール12は、複数の駅名候補データの組み合わせのうち、最適条件候補データとなる一組の駅名候補データを選定する。

0056

本例の場合、最適条件候補データは、出発地が「ヴァル(ランドマーク名)」、路線が「つくばエクスプレス」、目的地が「浅草駅」として選定される。最適条件候補データが選定されると、駅名候補DB24に記憶されている駅名候補データのうち、該当する駅名候補データに選定済のタグを付与するとともに、最適条件候補データを経路探索条件として経路探索ツール13に入力する(ステップS106)。タグは、例えば「ヴァル」が出発地として再度選定されないようにするためものであるが、不可欠なものではない。

0057

経路探索ツール13から経路探索結果を受け取ると(ステップS107:Yes)、主制御部10は、自然文編集ツール14を起動する。自然文編集ツール14は、経路探索結果に含まれる経路候補及び代替経路のダイヤ情報をマージしたものと、ユーザ端末30からWeb通信により経路探索ツール13にアクセスするための権限情報及び探索IDと共に、メール用の回答文として編集する(ステップS108)。権限情報は、登録されたユーザの固有情報及び上記の探索IDをパラメータ化し、これを経路探索ツール13のURL(Uniform Resource Locator)とセットにしたものを用いる。

0058

自然文編集ツール14により回答文が編集されると、主制御部10は、メール送受信部11を制御し、発信元の登録メールアドレスを読み出し(ステップS109)、回答文を発信元の登録メールアドレス宛に返信する(ステップS110)。

0059

返信メールに含まれる回答文は、図12図14に例示されるものとなる。図12の例では、携帯端末30の表示画面50に、[経路1]についての経路候補とその代替経路のダイヤ情報が示されている。図13は[経路2]についての経路候補とその代替経路のダイヤ情報、図14は[経路3]についての経路候補とその代替経路のダイヤ情報である。ユーザの意図に沿わない経路探索条件であったかどうかは、[経路1]についての探索結果で直ちにわかるので、最初の表示画面50の最下部に、権限情報52が記述されている。

0060

ユーザは、図12図14の表示画面が自分の意図したものであった場合は、何のアクションを起こさずとも、経路探索のための一連の処理は完結する。つまり、ユーザによる自然文による1回の電子メールの送信及びそれに因る自動応答による返信メールにより、ユーザの目的は達成されるので、例えば特許文献4のシステムのように、本文に経路案内メールを引用して返信する必要がなくなり、操作が簡略化されるだけでなく、通信リソースの浪費も回避される。

0061

他方、意図しない探索結果であったときは、図12の表示画面50の最下段に記述されている権限情報52の部分にカーソルを合わせ、クリックすることにより、ネットワークN2及び通信制御部16を介して経路探索ツール13に、シームレスにWebアクセスすることができる。図8は、Webアクセス時の主制御部10の処理手順図である。

0062

図8において、主制御部10は、携帯端末30からのアクセス(Webアクセス)を検知すると(ステップS201:Yes)、経路探索条件の入力画面を携帯端末30の画面に表示させる(ステップS202)。このとき、駅名候補DB24に記憶され、探索IDにより特定される駅名候補データを駅名候補DB24より読み出し、これらを出発地別、経由地別、目的地別、路線別に、それぞれカーソルで選択できるようにする(ステップS203)。

0063

図15は、経路探索条件の入力画面例である。表示画面50には、4つの入力領域が形成されている。各入力領域からは、既に抽出された駅名候補データ(ランドマーク名を含む)や路線を選択できるようになっている。デフォルトとして、先頭データすなわち最適な駅名候補データが自動的に記入される。経由地及び路線については必須入力条件ではないので、「指定せず」が含まれている。「指定せず」が選択されたときはその条件は無いものとして扱われる。

0064

ユーザが、カーソル操作で、各入力領域について目的の駅名候補データを一つ選択し、表示画面50の実行ボタン画像55をクリックして指示すると(ステップS204:Yes)、主制御部10は、変更された経路探索条件を経路探索ツール13に入力する(ステップS205)。その後、主制御部10は、Web通信(Webアクセス)を終了させる(ステップS206)。その後の処理手順は、図7のステップS107以降と同じとなる。つまり、ユーザは、自分の意図通りの経路探索結果を、図12図14のような回答文をその内容とする返信メールにより受け取ることができる。
なお、条件変更後の経路探索結果を再度の返信メールではなく、Web通信を維持した状態で表示画面50に表示させるようにしても良い。

0065

このように、本実施形態の経路探索システム1では、ユーザにとって使い方が曖昧である日本語の自然文であっても、駅名候補データが得られた段階ですべての駅名候補データを駅名候補DB24へ保存しておき、自然言語処理ツール12の解釈が誤っていた場合に、Web通信を使ってユーザが本来意図していた駅名候補データを選択できるようにしたので、電子メールによる経路探索の利便性をWeb通信により補完することができる。現在確立されている自然言語処理技術では必ずしも完全な結果が得られないが、本実施形態によれば、返信メールを受け取った後に、さらに解釈を変更できるという、従来技術からは得られない効果が期待される。

0066

本実施形態では、また、自然言語処理ツール12が、ひらがなクエリー判定を行うことで、依頼メールにひらがなが含まれるときであっても、当該ひらがなを漢字等の本来表現の文字に変換した後に自然文解析を行うようにしたので、依頼文の作成に際して文字変換の作業が軽減される。

0067

本実施形態では、また、経路候補とその前後に利用できる代替経路のダイヤ情報が1つの表示画面50でマージされて表示されるので、対話的なインタフェースを持たない場合においても、経路案内情報を効率的に提供することができる。

0068

本実施形態では、また、ユーザが入力した特定の地域、場所又は施設を表すランドマーク名と、ランドマーク名の最寄り駅及びそこまでの到達所要時間とを当該ユーザの識別情報と関連付けてランドマークDB25を備え、自然言語処理ツール12が、登録されたランドマーク名を出発地、経由地又は目的地の一つに含めて自然文解析を行うようにしたので、依頼文にユーザ独自の施設名等を含めた条件の指定を迅速に行うことができる。携帯端末30の場合、文字を入力する行為そのものが煩わしく、できるだけ短い語で経路探索の条件を入力することが望ましいが、本実施形態によれば、それが可能となる。ランドマーク名は、自宅、会社、友人宅などのプライベートな施設であっても良いので、ユーザに特化した経路探索が可能となる。

0069

本実施形態では、さらに、交通機関の正式の路線名毎に、ユーザが任意に指定した1又は複数の通称路線名を、当該ユーザの識別情報と関連付けて通称路線DB26に登録しておき、経路探索ツール13が、登録されたいずれかの通称路線名を経路候補が複数存在するときの絞り込み条件として使用するようにしたので、ユーザの好みに応じた探索結果の「絞り込み」が可能となる。特に携帯端末30の場合、操作環境が充分でなく、かつ、表示画面50に多くの経路を表示できないので、使用したい路線のイメージがあっても、その経路を見つけるのは困難であるが、本実施形態によれば、それが容易となる。

0070

なお、本実施形態では、曖昧性を持つ自然文の解釈が1つに定まらないという問題を解消する手段であることを前提として説明したが、依頼メールからの語句の切り出し領域のずれ等により、駅名以外の文字が誤って駅名候補データと認識された場合についても、正しい駅名候補データに解釈を変更する手続きとして、本発明を適用することもできる。

0071

また、本実施形態では、条件候補データの一つとして駅名候補データを用いた場合の例を示したが、交通機関としてバスを組み込む場合は、駅名候補データはバス停候補データとなり、航空機をも組み込む場合は、駅名候補データは空港名候補データとなる。

0072

また、本実施形態では、携帯端末30の電子メールを用いて経路探索サービスを提供する場合の例を説明したが、パーソナルコンピュータによる電子メールを用いることもできる。

0073

1・・・経路探索システム、10・・・主制御部、11・・・メール送受信部、12・・・自然言語処理ツール、13・・・経路探索ツール、14・・・自然文編集ツール、15・・・登録ツール、16・・・通信制御部、21・・・ルールDB、22・・・ユーザ情報DB、23・・・運行情報DB、24・・・駅名候補DB、25・・・ランドマークDB、26・・・通称路線DB、30・・・携帯端末、50・・・表示画面、52・・・権限情報、55・・・実行ボタン画像、N1・・・携帯電話網、N2・・・インターネット。

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

(分野番号表示ON)※整理標準化データをもとに当社作成

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ