運行経路探索装置及びシステム、運行経路探索方法、コンピュータプログラム
【課題】公共交通機関の経路探索を行うときの無駄なリソースの費消を回避する。
【解決手段】出発地、目的地を含む経路探索条件の入力を契機に、出発地を起点とする経路の運行コストが最も小さい次の駅の探索処理を連鎖的に繰り返すことにより、経路探索条件に従う最適経路候補を特定する経路探索ツール１１０を備えた経路探索サーバ１０において、同名となる複数の駅について、その名称を各駅からの運行コストがゼロとなる仮想ランドマークとして設定して、仮想ランドマークＤＢ１２２に、経路探索ツール１１０による検索可能に予め登録しておき、登録した仮想ランドマークを出発地又は目的地として経路探索ツール１１０に認識させる仮想ランドマーク登録ツール１２０を設け、同名となる複数の駅間の運行コストの比較を迅速に行えるようにした。
【解決手段】出発地、目的地を含む経路探索条件の入力を契機に、出発地を起点とする経路の運行コストが最も小さい次の駅の探索処理を連鎖的に繰り返すことにより、経路探索条件に従う最適経路候補を特定する経路探索ツール１１０を備えた経路探索サーバ１０において、同名となる複数の駅について、その名称を各駅からの運行コストがゼロとなる仮想ランドマークとして設定して、仮想ランドマークＤＢ１２２に、経路探索ツール１１０による検索可能に予め登録しておき、登録した仮想ランドマークを出発地又は目的地として経路探索ツール１１０に認識させる仮想ランドマーク登録ツール１２０を設け、同名となる複数の駅間の運行コストの比較を迅速に行えるようにした。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、同名の複数の駅又は停留所が存在することによるシステム側の問題を解消し、利用者にとっても快適な経路探索環境を実現可能にする運行経路探索の技術に関する。
【背景技術】
【０００２】
電車等の公共交通網における最適な運行経路の探索技術については、昭和時代に本願出願人により開発され、多くの利用者の支持を得た運行経路探索ソフト「駅すぱあと」(登録商標、非特許文献１参照）の登場以来、複数の企業技術者の手により幾多の改良・改善が試みられてきた。携帯端末やインターネット技術等に代表されるネットワーク技術が普及した今日では、ホームページを通じて経路案内を行う技術（特許文献１参照）、携帯メールを通じて経路探索及び乗換案内を行う技術（特許文献２参照）等も提案されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００１−３３１６０４号公報
【特許文献２】特開２００６−３２３６５６号公報
【特許文献３】特開２００１−１４３３１号公報
【非特許文献】
【０００４】
【非特許文献１】「駅すぱあと」風雲録 柏崎ほか 日経ＢＰ社 ２００６年３月２０日発行
【発明の開示】
【発明が解決しようとする課題】
【０００５】
公共交通機関の運行経路探索において、出発地（出発駅）及び目的地（目的駅）が指定されたときの探索処理は、概ね以下のように行われている。
出発地となる駅に繋がるすべての路線、駅について、経路の運行コスト（例えば時間）が最小となる次の駅の探索処理を連鎖的に繰り返すことで、水面に石を投げたときの波紋のような形態で経路探索を行う。この波紋のような探索過程で、所定の基準に満たない経路は、逐次除外される。路線は必ずどこかの駅で繋がっているため、すべての駅間の組み合わせの運行コストを演算することは現実的でないためである。
探索過程で目的駅が特定された場合、その目的駅と出発駅との間の経路を利用者が望む経路候補とするとともに、さらにそこから派生する経路候補を多数パターン探索して保持し、利用者が指定した探索条件に応じてソート可能にする。例えば利用者が指定した探索条件が最短時間の経路である場合は、保持されているパターンを時間でソートし、最短時間となるパターンの経路を最適経路候補とし、さらに、この最適経路候補との比較で、妥当ないくつかの派生経路を特定し、これらをディスプレイに表示させる。
【０００６】
上記の探索過程において、実行負荷を増大させる原因の一つに、同名の駅並びに抽象名の駅の存在がある。
例えば全国規模では、「府中」（東京都、広島県、徳島県）、「神戸」（愛知県、群馬県、兵庫県）、「日本橋」（大阪府、東京都）、「こどもの国」（愛知県、神奈川県）、ときわ台（東京都、大阪府）、「浦安」（千葉県、鳥取県）のような同名の駅がある。比較的近郊の運行経路探索に絞っても、例えば「九条」（京都府、大阪府、奈良県）の例もある。日本には、その地方では独自と思われても他にしっかり存在するこのような同名の駅が、本願の出願時点で、鉄道駅だけで約９８００駅中、約１０００件存在する（約１０％）。鉄道（路面電車を含む）駅の中には「球場前」（岡山県、高知県）、「競馬場前」(北海道、福岡県)のように同名であるばかりでなく、土地の固有名詞がつかない抽象名の駅、例えば「県庁前」（愛媛県ほか６県）、「市役所前」（愛知県ほか９県）も多々存在する。地方のバス停では、このような抽象名の停留所が存在することの方が自然であるから、運行経路探索にバス路線を含めると、探索対象となる同名の駅や停留所の数は、飛躍的に増加する（約３８０００停留所中、約１０３００件（約２７％））。
そのため、運行経路探索を行う際に、出発地（駅／停留所）及び目的地（駅／停留所）を利用者に指定させるだけでは、必ずしも利用者が望む経路を特定できない場合がある一方、同名でありながら抽象名の駅を何とか探索しなければならないため、実際には不要かも知れない経路の探索に多大なリソースを費消してしまい、システムの実行効率が低下するという重大な問題があった。
【０００７】
例えば、新宿から「府中」までを指定した探索処理を例に挙げる。
この探索処理では、以下の手順で探索処理が行われる場合がある。
（１）新宿から東京都の「府中」を探索する。
（２）新宿から徳島県の「府中」を探索する。
（３）新宿から広島県の「府中」を探索する。
（４）これらの探索結果の中から、最小コストの経路を選択する。
この場合は探索処理を３回実行（通常２つの探索パターンは無駄になる）することになって、システムの実行効率が著しく低下する。一般に、出発地の同名の駅又は停留所の数をｍ、目的地の同名の駅又は停留所の数をｎとすると、同名の駅又は停留所が無い場合と比較して、実行効率は、１／（ｍ＊ｎ）となる。
【０００８】
このような問題を解決するため、多くの経路探索システムでは、出発地（駅／停留所）や目的地（駅／停留所）を利用者に入力させ、同名であるが実は異なる駅（以下、「同名異駅」という場合がある）や同名であるが異なる停留所（以下、「同名異停」という場合がある）が存在することが判明したときは、その旨を利用者に伝えて、いずれか一つを絞り込ませ、絞り込み完了の意思確認を行った後に経路探索を実行している（例えば特許文献３参照）。
【０００９】
しかしながら、特許文献３のような問題の解決手法は、経路探索システムと利用者との間で、経路探索条件の入力確定までにインタラクティブな意思確認がとれない、あるいはとりにくい利用環境のシステムでは、著しく無力となる。
利用者は同名異駅や同名異停の存在を知らないのが通常であるから、本来的には、上記の問題を利用者に意識させない簡易な利用環境の方が、この種の経路探索システムの利用を促進する観点からは望ましい。
【００１０】
本発明は、かかる背景のもと、同名異駅や同名異停の存在に伴う問題点を解消し、経路探索の際の無駄なリソースの費消を回避しつつ、利用者に快適となる利用環境を実現可能にする運行経路探索の仕組みを提供することを主たる課題とする。
【課題を解決するための手段】
【００１１】
上記課題を解決するため、本発明は、運行経路探索装置、システム、運行経路探索方法及びコンピュータプログラムを提供する。
本発明の運行経路探索装置は、出発地及び目的地の少なくとも一方と、出発時刻、到着時刻、探索範囲の一つ又は複数の組み合わせとを含む経路探索条件の入力を契機に、前記出発地又は前記目的地を起点とする経路の運行コストが最も小さい次の駅又は停留所の探索処理を連鎖的に繰り返すことにより、前記経路探索条件に従う最適経路候補を特定する経路探索ツールと、同名となる複数の駅又は停留所について、その名称を当該駅又は停留所からの運行コストがゼロとなる仮想ランドマークとして設定して、所定の記憶手段に、前記経路探索ツールによる検索可能に予め登録する登録手段を有し、登録した仮想ランドマークを前記出発地又は前記目的地として前記経路探索ツールに認識させる仮想ランドマーク登録ツールと、を備えた装置である。
「仮想ランドマーク」は、実際には存在しない目標を、あたかも存在するかの如く扱うためのものであるが、利用者の便宜を図る観点からは、実際に常用されている駅名であることが望ましい。「設定」は、少なくとも経路探索ツールが認識できる時間、所定のメモリ領域に存在させることをいう。「ツール」は、コンピュータのハードウエア資源をプログラムが制御することによって、そのコンピュータ資源特有の性質を利用して形成される機能実現体である。
【００１２】
仮想ランドマークを経路探索ツールに出発地等として認識させることにより、経路探索処理中、その仮想ランドマークを媒介として、直ちに、実際の複数の同名異駅または同名異停を経路に含む運行コストを比較できるので、探索範囲の無駄な拡がりを防止することができる。また、同名異駅、同名異停の存在を考慮する必要がなくなることから、システム設計（例えば、プログラム開発、必要なハードウエアの準備等）も簡素化され、経路探索条件の自動認識・自動実行の環境実現が可能となるし、利用者にとっても、きわめて操作性に優れた運行経路探索装置とすることができる。
【００１３】
本発明の他の運行経路探索装置は、上記の運行経路探索装置において、さらに、利用者が操作する情報端末との通信を可能にするインタフェース手段と、前記インタフェース手段を通じて受信した、自然言語から成る依頼文に対して自然言語処理を行うことにより、その依頼文に含まれる語又は語句を抽出して、抽出した語又は語句を、予め定めた語又は語句と前記経路探索ツールが認識可能な前記経路探索条件との対応ルールに従って前記経路探索条件に変換する探索条件入力手段と、前記探索条件入力手段で変換した経路端末条件を、利用者による操作を要することなく前記経路探索ツールに入力し、これにより特定された最適経路候補を前記経路探索ツールより受け取り、受け取った最適経路候補を前記インタフェース手段を通じて前記情報端末において表示可能にする制御手段と、を有する装置である。
【００１４】
自然言語処理は、人間が日常的に使っている自然言語の内容を認識することにより意味のある語又は語句を抽出する処理である。このような自然言語の依頼文で経路探索を依頼する程度の簡単な手法によっても、探索条件入力手段によりシステム側でその依頼文に含まれる語又は語句を抽出して経路探索条件に変換し、経路探索ツールから経路探索結果を受け取れるので、利用者にとって快適となる経路探索の利用環境を、具体的且つ現実に、実現することができる。
なお、依頼文は、テキスト文、ＨＴＭＬ等、システム側でその意味内容を解析できる文であれば、どのようなデータ構造のものであっても良い。利用者が経路探索ツールから受け取る情報にも、自然言語から成る文が含まれるようにすることが望ましい。
【００１５】
本発明の運行経路探索システムは、複数の情報端末及びメールサーバによるアクセスが可能なネットワークに接続される運行経路探索システムであって、第１サーバ及び１又は複数の第２サーバを含んで構成される。
前記第１サーバは、上述した経路探索ツール及び仮想ランドマーク登録ツールを有するものであり、前記第２サーバは、上述したインタフェース手段、探索条件入力手段、及び、制御手段とを有するものである。
このような運行経路探索システムでは、例えば、第１サーバにおける経路探索に伴う実行負荷と、利用者からの窓口としての第２サーバの実行負荷並びに依頼文の受信数との最適化を図ることで、効率的な運行経路の探索環境を実現することができる。
【００１６】
本発明の運行経路探索方法は、上述した経路探索ツールと、同名となる複数の駅又は停留所について、その名称を当該駅又は停留所からの運行コストがゼロとなる仮想ランドマークとして設定して登録された記憶手段と、利用者が操作する情報端末とのインタフェース手段とを備えた装置で実行する運行経路探索方法であって、前記記憶手段に登録された前記仮想ランドマークを前記出発地又は前記目的地として前記経路探索ツールに認識させる過程と、利用者が情報端末を通じて自然言語で入力した依頼文を前記インタフェース手段を通じて受信したときに、受信したテキスト文に対して自然言語処理ツールで自然言語処理を行うことにより、その依頼文に含まれる語又は語句を抽出する過程と、抽出された語又は語句を、予め定めた語又は語句と前記経路探索条件との対応ルールに従って前記経路探索条件に変換する過程と、変換された経路端末条件を、前記利用者による操作を要することなく前記経路探索ツールに入力し、これにより特定された最適経路候補を前記経路探索ツールより受け取り、受け取った最適経路候補を、前記インタフェース手段を介して前記情報端末に表示可能な形態で伝達する過程とを有する、運行経路探索方法である。
【００１７】
本発明のコンピュータプログラムは、コンピュータを、上述した経路探索ツール及び仮想ランドマーク登録ツールとして機能させる、運行経路探索用のコンピュータプログラムである。
【発明の効果】
【００１８】
本発明によれば、仮想ランドマークを設定し、これを経路探索ツールにおいて出発地等として認識させることで、同名異駅や同名異停の存在に伴う問題点が解消される。また、出発地等に同名異駅や同名異停が含まれるときに、利用者にどれか一つを絞り込ませる必要がなくなり、システム設計の簡素化も可能となる。さらに、経路探索の際の無駄なリソースの費消が回避されるので、経路探索時の実行負荷が格段に軽減される。同名異駅や同名異停の存在に伴う問題点が解消されるので、利用者に快適となる利用環境、例えば自然言語によるテキスト文での経路探索も具体的に実現可能となる。
【図面の簡単な説明】
【００１９】
【図１】本発明を適用した運行経路探索システムの全体構成図。
【図２】経路探索ツールによる駅間探索の仕方の説明図。
【図３】経路探索ツールにおいて仮想ランドマークを用いた場合の手順を説明する図であり、（ａ）は仮想ランドマーク（「府中」）を出発地として認識させた場合の例、（ｂ）はそれを目的地として認識させた場合の例である。
【図４】ルールテーブルの内容説明図。
【図５】携帯経路探索サービスを提供する場合のサービス制御部の制御手順説明図。
【図６】（ａ）は携帯経路探索サービスを電子メールで依頼するときのテキスト文の内容例を示した図、（ｂ）はこのテキスト文に対して運行経路探索サービスから返信される経路探索結果情報の説明図。
【発明を実施するための形態】
【００２０】
以下、本発明を、携帯端末向けの経路探索サービスを可能にするネットワーク型の運行経路探索システムに適用した場合の実施の形態例を説明する。
【００２１】
図１は、この実施形態の運行経路探索システムの全体構成図であり、特徴的な部分のみを掲示してある。この運行経路探索システムは、インターネット等のディジタルネットワークＮに接続される経路探索サーバ１０と、１又は複数の携帯サービスサーバ２０（図示の例では一つ）とを含んで構成される。ディジタルネットワークＮには、メールサーバ６０や情報端末の一例となるパーソナルコンピュータ(ＰＣ)も接続可能になっている。情報端末の他の例となる携帯端末５０は、データ通信及びデータ処理機能を有する場合はダイレクトに、メール機能のみであればメールサーバ６０を通じて、それぞれディジタルネットワークＮに接続することができるものとする。
【００２２】
[経路探索サーバ]
経路探索サーバ１０は、サーバ本体と本発明のコンピュータプログラムとの協働により実現される。すなわち、サーバ本体が、コンピュータプログラムを読み込んで実行することにより、そのサーバ本体を、データ通信用インタフェース１００、経路探索ツール１１０、及び、仮想ランドマーク登録ツール１２０として機能させ、経路探索のための情報処理を実行可能にする。
【００２３】
データ通信用インタフェース１００はデータ通信及びデータ処理機能を有する携帯端末５０やＰＣ７０との双方向通信を可能にするとともに、これらの情報端末が閲覧可能な階層ページ画面を提供する。この階層ページ画面では、運行経路探索のＷｅｂサービスを行うためのもので、経路探索条件の精緻な指定をシステム側と利用者との間でインタラクティブに行うことにより、利用者が満足する経路探索を行う環境を提供する。経路探索の結果情報の表示も、このページ画面で行うことができる。
【００２４】
経路探索ツール１１０は、交通機関（鉄道／バス）の路線、時刻表等のデータを蓄積した運行情報ＤＢ（ＤＢはデータベースの略、以下同じ）１１１と、経路探索エンジン１１２とを含み、経路探索条件の入力を契機に、運行情報ＤＢ１１１に蓄積されている情報をもとに経路探索エンジン１１２が経路の運行コストが最も小さい次の駅又は停留所の探索処理を、水面に石を投げたときの波紋のように連鎖的に繰り返すことにより、経路探索条件に従う最適経路候補を特定する。「運行コスト」は通常は時間を対象とするが、距離、運賃を用いても良く、あるいは、これらの組み合わせを対象としても良い。経路探索ツール１１０は、推論エンジンも搭載しており、探索途中で現実的でない経路となることが判明した場合は、その経路についての次の駅以降の探索を止める。
【００２５】
経路探索条件としては、出発地と目的地との間の最適経路候補の特定、出発地から一定範囲内に存する駅又は停留所の特定、目的地に所定時間内に到達する駅又は停留所の特定、出発時刻、到着時刻、探索範囲等の組み合わせである。この経路探索ツール１１０の基本機能部分は、例えば本願出願人が提供している経路探索ソフトウエア「駅すぱあと」（登録商標）のものを使用することができる。
【００２６】
図２は、経路探索ツール１１０による最も一般的な探索処理、すなわち出発地と目的地との間の最適経路候補の特定を行う場合の探索の様子を示した図である。図示の例は、東京都の東高円寺駅と高円寺駅との間のごく短い区間であるが、このような短い区間の中でも、膨大な数の経路が存在することを表している。
【００２７】
仮想ランドマーク登録ツール１２０は、駅又は停留所の中で、同名異駅（鉄道路線の場合）及び同名異停（バス路線の場合）のその駅名又は停留所名を仮想ランドマークとして設定し、これを出発地又は目的地として経路探索ツール１１０に認識させるものである。実際には存在しないものであるため、仮想ランドマークから各駅又は停留所までの運行コストをそれぞれゼロ、すなわち運行コストを時間とみる場合は、徒歩０分と設定する。
仮想ランドマーク登録ツール１２０は、経路探索ツール１１０が経路探索を行っている過程で同名異駅等を検出したときに、その指示のもとに起動して、その都度、仮想ランドマークを設定するが、外部からの設定の登録を受け付ける登録部１２１を介して仮想ランドマークＤＢ１２２に予め登録しておき、経路探索エンジン１１２によって随時検索して、これにより得たものを設定するようにしても良い。その都度設定する場合、一度新規に設定した仮想ランドマークは、仮想ランドマークＤＢ１２２に登録しておくようにする。
【００２８】
一例として、上述の「府中」を仮想ランドマークとし、実在する東京都の府中駅、広島県の府中駅、徳島県の府中駅から徒歩０分と設定して、これを経路探索ツール１１０で出発地又は目的地として扱うことの経路探索上の意味をより詳しく説明する。
【００２９】
図３（ａ）は、出発地として仮想ランドマーク（「府中」）を認識させる場合の例を示す。この出発地からの所要時間内となる駅又は停留所を探索する範囲探索でも良いが、ここでは、目的地として東京都の「高円寺」が認識されているものとする。
この場合、経路探索ツール１１０は、運行コストゼロ（徒歩０分）で関連付けられている東京都の府中駅、徳島県の府中駅、広島県の府中駅を起点とした次の駅までの運行コストを、まず計算する。東京都の府中駅を除く他の２駅を起点とした場合の次の駅以降の運行コストは、この時点で「高円寺」までの運行時間が数十時間を越えるため、現実的な経路ではないとして直ちに探索すべき経路候補から除外される（図示の破線）。そのため、それ以上無駄にリソースを費消することなく、東京都の府中駅に繋がる次の以降の経路探索のみに移行することができる。駅の数は膨大なので、仮想ランドマークがない場合に徳島県の府中駅及び広島県の府中駅に繋がる次の駅以降の探索をも繰り返す従来型の手法と比べて軽減されるリソースは、計り知れないほど大きい。
【００３０】
この特徴は、図３（ｂ）のように、目的地として仮想ランドマーク（「府中」）を認識させる場合に、より顕著となる。すなわち、経路探索の直前区間と東京都の府中駅、徳島県の府中駅、広島県の府中駅との運行コストを比較するだけで、直ちに後者２駅に繋がる経路が除外される。
【００３１】
このように、運行経路探索において、仮想ランドマークを通じて直ちに実在の複数の駅又は停留所間の運行コストの比較が行えるため、利用者が必要としている可能性が最も高い経路を迅速に特定して、利用者に返すことができる。システム設計も、同名異駅等のどの駅を特定するのかをその都度利用者に確認する必要がないから著しく簡素化され、利用者にとっても、他の地域に存在する同名の駅等を意識することなく、常用されている駅名等を指定することができるので、利用者との間で経路探索条件の入力確定までにインタラクティブな意思確認がとれない、あるいはとりにくい利用環境であっても、運行経路探索が実行できるようになる。経路探索条件の自動入力・自動実行の環境も、この運行コストゼロの仮想ランドマークを使用することにより実現が可能となる。
【００３２】
なお、仮想ランドマークは、実際には存在しない駅、停留所等の目標（ランドマーク）を存在するとみせかけて探索処理を行わせる点で、多くの経路探索システムで採用されているランドマーク登録機能で扱うランドマークとは異なる点に留意すべきである。公知のランドマーク登録機能は、実在する施設等をランドマークとし、そこに最寄駅及び徒歩等の交通手段を関連付けて予め登録しておくもので、最寄駅からの距離が長いときの総所要時間、最寄駅が複数あるときの最適経路の選択等のために用いられるものである。
【００３３】
［携帯サービスサーバ］
携帯サービスサーバ２０は、本実施形態による経路探索サーバ１０が経路探索条件の自動入力・自動実行のための環境を有することから、この経路探索サーバ１０と連携して、携帯端末５０を利用した任意の場所からの経路探索サービス、特に電子メールを伝達媒体とする自然言語による経路探索サービスを実現するものである。
【００３４】
携帯サービスサーバ２０は、経路探索サーバ１０同様、サーバ本体とコンピュータプログラムとの協働により実現される。すなわち、サーバ本体がコンピュータプログラムを読み込んで実行することにより、サーバ本体を、携帯端末用インタフェース２００、編集部２１１を有するサービス制御部２１０、探索条件入力部２２０として機能させる。探索条件入力部２２０は、ルールテーブル２２１、自然言語処理ツール２２２及び変換ツール２２３を有する。
【００３５】
携帯端末用インタフェース２００は、ディジタルネットワークＮに接続されているメールサーバ６０を介して携帯端末５０との電子メールによる双方向通信を可能にするものである。電子メールのみを受け付けるようにした点で、データ通信用インタフェース１００とは区別される。
【００３６】
探索条件入力部２２０において、ルールテーブル２２１には、語又は語句と経路探索ツール１１０が認識可能な経路探索条件との対応ルールが記録されている。ここにいう対応ルールは、図４にその一部を例示するように、例えば「○○（駅）から」とか「○○（駅）を」という語句に対する出発地が「○○」という如きものである。目的地、出発時刻、到着時刻、所要時間、所要距離について、それぞれ同様のルールテーブルを用意しておく。また、実行依頼と共に経路探索ツール１１０に伝える条件ルール、すなわち２つの駅名だけ入力のときは駅間の平均経路の探索、２つの駅名と出発時刻の組み合わせのときは各経路の通過時刻の探索、２つの駅名と到着時刻の組み合わせのときはその到着時刻以前に到着するときの各経路の時刻の探索、一つの駅名と所要時間のときはその駅を出発駅としたときの範囲探索（出発駅からその所要時間内に到着可能な駅の探索）の探索・・・も対応ルールとして用意しておく。
【００３７】
自然言語処理ツール２２２は、携帯端末用インタフェース２００を通じて受信した、自然言語から成る依頼文に対して自然言語処理を施すことにより、その依頼文に含まれる語又は語句を抽出する。この自然言語処理ツール２２２としては、例えば、ＳＥＴソフトウエア株式会社が販売する「Ｌ−ｎａｖｉ（自然言語インタフェース組込型開発キット）」を使用することができる。
変換ツール２２３は、自然言語処理ツール２２２で抽出した語又は語句をルールテーブル２２１に従って経路探索条件に変換する。
【００３８】
サービス制御部２１０は、携帯サービスサーバ２０全体における各種動作を制御する。例えば、携帯端末５０から電子メールを受信したことを携帯端末用インタフェース２００が検知したときに、探索条件入力部２２０を制御して電子メール中の依頼文から経路探索条件を含む部分を抽出させ、抽出された経路探索条件を利用者による操作を要することなく経路探索ツール１１０に入力させる。つまり、自動入力・自動実行依頼である。経路探索ツール１１０で最適経路候補が特定されたときは、これを経路探索ツール１１０より受け取り、受け取った最適経路候補を編集部２１１で携帯端末５０のディスプレイで表示可能なサイズの電子情報に編集する。そして、携帯端末用インタフェース２００を制御することにより、編集した電子情報をメールサーバ６０を介して電子メールの送信元である携帯端末５０に返信し、表示させる。電子情報は、自然言語から成る文を含む。この文はテキスト文、ＨＴＭＬその他、利用者が容易に理解できるデータ構造のものである。画像入りであっても良い。テキスト文やＨＴＭＬのみとする場合は、処理の負荷が軽くなるので、より迅速な応答が可能になる。
【００３９】
［運用形態］
次に、本実施形態の運行経路探索システムの運用形態例を説明する。
ここでは、利用者に携帯経路探索サービスを提供する場合の例を説明する。携帯経路探索サービスは、利用者が携帯端末５０を操作して電子メールで運行経路探索のサービスを受けられるようにするサービスである。このサービスは、携帯サービスサーバ２０が主導的に動作する。
【００４０】
図５は、携帯サービスサーバ２０におけるサービス制御部２１０の制御手順を示した図である。
利用者は、電子メールで経路探索を依頼する。ここでは、一例として、図６（ａ）に示すように、「大宮から新宿を経由して清里まで１２月２５日、１３時着の経路を教えてください。」という内容の依頼文を、電子メールで、運行経路探索システムの専用アドレスに発信したとする。
【００４１】
サービス制御部２１０は、この電子メールを受信すると（ステップＳ１０１：Yes）、発信元のメールアドレスをアドレスメモリ（図示省略）に記録する（ステップＳ１０２）。自然言語処理ツール２２２を起動し、メール文（依頼文）の解析と自然言語処理による語句抽出とを行う（ステップ１０３）。なお、図示の例では同名異駅や同名異停が存在しないが、仮に依頼文にこれらが含まれている場合は、その名称のまま抽出する。変換ツール２２３を起動して、抽出された語句とルールテーブル２２１とに基づいて経路探索条件を生成する（ステップＳ１０４）。生成された経路探索条件を経路探索ツール１１０に自動入力し、且つ自動実行を依頼する（ステップＳ１０５）。
【００４２】
経路探索ツール１１０は、この経路探索条件及び自動実行依頼を受け付け、経路探索条件に従う最適経路候補を探索するための処理を開始する。「最適経路」ではなく「最適経路候補」とするのは、最適かどうかを判断するのは、利用者であることによる。経路探索条件の中には、出発地又は目的地の少なくともいずれかが含まれているので、経路探索ツール１１０は、探索開始に際して仮想ランドマークＤＢ１２２を参照し、出発地等について仮想ランドマークが登録されているかどうかをチェックする。
本例の場合は、同名異駅等は存在しないが、仮に存在し、それが仮想ランドマークとして登録されている場合は、それを出発地等として認識する。存在しなくとも探索開始時にそれが同名異駅等であることが判明したときは、仮想ランドマークを設定し、設定後はそれを仮想ランドマークＤＢ１２２に登録する。
【００４３】
経路探索ツール１１０から探索結果を受信すると（ステップＳ１０６：Yes）、サービス制御部２１０は、その経路探索結果を含む情報を携帯端末宛のメール用に編集する（ステップＳ１０７）。すなわち、ＰＣ７０等のディスプレイと異なり、携帯端末５０のディスプレイは小さいし、解像度も低いので、余分な情報を取り除き、なるべく少ないパケット数で且つなるべく１画面で表示することができ、しかし必要な情報は盛り込むように編集する。その後、発信元のメールアドレスを読み出し（ステップＳ１０８）、編集済の経路探索結果情報を発信元のメールアドレス宛に発信する（ステップＳ１０９）。
【００４４】
携帯端末５０は、このようにして編集された経路探索結果情報をディスプレイに表示させる。本例の場合に表示される内容例を示したのが図６（ｂ）である。図示されるように、この例では、情報量が多いので、テキスト文に編集されているが、情報量に応じて、あるいは利用者による明示の指定があった場合に、画像ないし図形を含めることは、可能である。
【００４５】
このように、本実施形態の運行経路探索システムでは、経路探索サーバ１０で仮想ランドマークを設定する機能を持たせ、無駄なリソースの費消の回避と利用者に同名異駅のどの駅なのかの確認を不要にした仕組みを実現したので、経路探索条件の自動入力・自動実行が可能となった。また、この仕組みを利用し、利用者が、例えば携帯端末５０のような比較的簡易な情報端末を用い、自然言語で、しかも電子メールで経路探索依頼を行うだけで、探索結果情報が得られるようにしたので、利用者に快適となる経路探索の利用環境を提供することができる。電子メールなので、携帯端末の機種を代えても不都合なくこのサービスを利用することができる。もちろん、ＰＣを使用してこのサービスを使用することもできる。
【００４６】
従来のこの種の運行経路探索システム（例えば特許文献２参照）で、データ処理機能を有する携帯端末からネットワークを介して経路探索を行う同種のサービスを実現しようとする場合に以下の手順が不可欠となることを考えると、本実施形態の運行経路探索システムが利用者に与えるインパクトの大きさは、容易に理解されよう。
（ａ）利用者が、経路探索サービスのサイトにアクセスする。または、経路探索アプリケーションを起動する。ここで一定の時間がかかる。
（ｂ）利用者が、出発駅と到着駅とを指定する。同名異駅の場合は、それが存在する複数の都道府県と共に表示されるので、その中から一つを選択する。確定するかどうかの確認を必要とする。そのため、ここでも時間がかかり、携帯端末の通信料も余分にかかる。
（ｃ）経路探索が実行される。同名異駅等が含まれている場合は、現実にあり得ない経路が最適経路候補として、しかもより上位に特定される可能性がある。この場合、次の経路を表示させるまで時間と通信料がかかる。
（ｄ）探索結果を得、画面に表示させる。
【００４７】
なお、本実施形態では、経路探索サーバ１０と携帯サービスサーバ２０とをそれぞれ別のサーバ本体で実現した場合の例を示した。これは、経路探索サーバ１０の実行負荷が携帯サービスサーバ２０に比べて大きく、他方、携帯サービスサーバ２０の数が多いほど携帯サービスの利用者に対する窓口が多くなるため、分散させた方がシステム運用の最適化を図る上で好ましいことが主たる理由である。しかし、常にこのような形態で運用しなければならないというわけではなく、各サーバ１０，２０の機能を一つのサーバに統合する実施の形態も可能である。この場合は、本発明の機能を実現するためのコンピュータプログラムが一つで足りるという利点がある。
【００４８】
また、このような一つのコンピュータプログラムをＰＣ等の汎用コンピュータにインストールすることにより、そのコンピュータを単独の運行経路探索装置として動作させることができる。
【００４９】
また、本実施形態では、携帯経路探索サービスを提供する場合の例を中心に説明したが、このサービスによらず、時間及び手間がかかっても、探索条件を精緻に指定した経路探索を望む場合は、携帯端末５０のデータ処理機能を利用して、経路探索サーバ１０のデータ通信用インタフェース１００にアクセスし、これによって経路探索エンジン１１０を操作するという利用形態も可能である。
【産業上の利用可能性】
【００５０】
本発明は、鉄道、バス等の公共交通機関による最適経路探索に用いることは勿論であるが、仮想ランドマークを用いた機能は、カーナビゲーション等にも広く応用が可能である。
【符号の説明】
【００５１】
１０・・・経路探索サーバ、２０・・・携帯サービスサーバ、５０・・・携帯端末、６０・・・メールサーバ、７０・・・ＰＣ、１００・・・データ通信用インタフェース、１１０・・・経路探索ツール、１２０・・・仮想ランドマーク登録ツール、２００・・・携帯端末用インタフェース、２１０・・・サービス制御部、２２０・・・探索条件入力部、Ｎ・・・ディジタルネットワーク。
【技術分野】
【０００１】
本発明は、同名の複数の駅又は停留所が存在することによるシステム側の問題を解消し、利用者にとっても快適な経路探索環境を実現可能にする運行経路探索の技術に関する。
【背景技術】
【０００２】
電車等の公共交通網における最適な運行経路の探索技術については、昭和時代に本願出願人により開発され、多くの利用者の支持を得た運行経路探索ソフト「駅すぱあと」(登録商標、非特許文献１参照）の登場以来、複数の企業技術者の手により幾多の改良・改善が試みられてきた。携帯端末やインターネット技術等に代表されるネットワーク技術が普及した今日では、ホームページを通じて経路案内を行う技術（特許文献１参照）、携帯メールを通じて経路探索及び乗換案内を行う技術（特許文献２参照）等も提案されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００１−３３１６０４号公報
【特許文献２】特開２００６−３２３６５６号公報
【特許文献３】特開２００１−１４３３１号公報
【非特許文献】
【０００４】
【非特許文献１】「駅すぱあと」風雲録 柏崎ほか 日経ＢＰ社 ２００６年３月２０日発行
【発明の開示】
【発明が解決しようとする課題】
【０００５】
公共交通機関の運行経路探索において、出発地（出発駅）及び目的地（目的駅）が指定されたときの探索処理は、概ね以下のように行われている。
出発地となる駅に繋がるすべての路線、駅について、経路の運行コスト（例えば時間）が最小となる次の駅の探索処理を連鎖的に繰り返すことで、水面に石を投げたときの波紋のような形態で経路探索を行う。この波紋のような探索過程で、所定の基準に満たない経路は、逐次除外される。路線は必ずどこかの駅で繋がっているため、すべての駅間の組み合わせの運行コストを演算することは現実的でないためである。
探索過程で目的駅が特定された場合、その目的駅と出発駅との間の経路を利用者が望む経路候補とするとともに、さらにそこから派生する経路候補を多数パターン探索して保持し、利用者が指定した探索条件に応じてソート可能にする。例えば利用者が指定した探索条件が最短時間の経路である場合は、保持されているパターンを時間でソートし、最短時間となるパターンの経路を最適経路候補とし、さらに、この最適経路候補との比較で、妥当ないくつかの派生経路を特定し、これらをディスプレイに表示させる。
【０００６】
上記の探索過程において、実行負荷を増大させる原因の一つに、同名の駅並びに抽象名の駅の存在がある。
例えば全国規模では、「府中」（東京都、広島県、徳島県）、「神戸」（愛知県、群馬県、兵庫県）、「日本橋」（大阪府、東京都）、「こどもの国」（愛知県、神奈川県）、ときわ台（東京都、大阪府）、「浦安」（千葉県、鳥取県）のような同名の駅がある。比較的近郊の運行経路探索に絞っても、例えば「九条」（京都府、大阪府、奈良県）の例もある。日本には、その地方では独自と思われても他にしっかり存在するこのような同名の駅が、本願の出願時点で、鉄道駅だけで約９８００駅中、約１０００件存在する（約１０％）。鉄道（路面電車を含む）駅の中には「球場前」（岡山県、高知県）、「競馬場前」(北海道、福岡県)のように同名であるばかりでなく、土地の固有名詞がつかない抽象名の駅、例えば「県庁前」（愛媛県ほか６県）、「市役所前」（愛知県ほか９県）も多々存在する。地方のバス停では、このような抽象名の停留所が存在することの方が自然であるから、運行経路探索にバス路線を含めると、探索対象となる同名の駅や停留所の数は、飛躍的に増加する（約３８０００停留所中、約１０３００件（約２７％））。
そのため、運行経路探索を行う際に、出発地（駅／停留所）及び目的地（駅／停留所）を利用者に指定させるだけでは、必ずしも利用者が望む経路を特定できない場合がある一方、同名でありながら抽象名の駅を何とか探索しなければならないため、実際には不要かも知れない経路の探索に多大なリソースを費消してしまい、システムの実行効率が低下するという重大な問題があった。
【０００７】
例えば、新宿から「府中」までを指定した探索処理を例に挙げる。
この探索処理では、以下の手順で探索処理が行われる場合がある。
（１）新宿から東京都の「府中」を探索する。
（２）新宿から徳島県の「府中」を探索する。
（３）新宿から広島県の「府中」を探索する。
（４）これらの探索結果の中から、最小コストの経路を選択する。
この場合は探索処理を３回実行（通常２つの探索パターンは無駄になる）することになって、システムの実行効率が著しく低下する。一般に、出発地の同名の駅又は停留所の数をｍ、目的地の同名の駅又は停留所の数をｎとすると、同名の駅又は停留所が無い場合と比較して、実行効率は、１／（ｍ＊ｎ）となる。
【０００８】
このような問題を解決するため、多くの経路探索システムでは、出発地（駅／停留所）や目的地（駅／停留所）を利用者に入力させ、同名であるが実は異なる駅（以下、「同名異駅」という場合がある）や同名であるが異なる停留所（以下、「同名異停」という場合がある）が存在することが判明したときは、その旨を利用者に伝えて、いずれか一つを絞り込ませ、絞り込み完了の意思確認を行った後に経路探索を実行している（例えば特許文献３参照）。
【０００９】
しかしながら、特許文献３のような問題の解決手法は、経路探索システムと利用者との間で、経路探索条件の入力確定までにインタラクティブな意思確認がとれない、あるいはとりにくい利用環境のシステムでは、著しく無力となる。
利用者は同名異駅や同名異停の存在を知らないのが通常であるから、本来的には、上記の問題を利用者に意識させない簡易な利用環境の方が、この種の経路探索システムの利用を促進する観点からは望ましい。
【００１０】
本発明は、かかる背景のもと、同名異駅や同名異停の存在に伴う問題点を解消し、経路探索の際の無駄なリソースの費消を回避しつつ、利用者に快適となる利用環境を実現可能にする運行経路探索の仕組みを提供することを主たる課題とする。
【課題を解決するための手段】
【００１１】
上記課題を解決するため、本発明は、運行経路探索装置、システム、運行経路探索方法及びコンピュータプログラムを提供する。
本発明の運行経路探索装置は、出発地及び目的地の少なくとも一方と、出発時刻、到着時刻、探索範囲の一つ又は複数の組み合わせとを含む経路探索条件の入力を契機に、前記出発地又は前記目的地を起点とする経路の運行コストが最も小さい次の駅又は停留所の探索処理を連鎖的に繰り返すことにより、前記経路探索条件に従う最適経路候補を特定する経路探索ツールと、同名となる複数の駅又は停留所について、その名称を当該駅又は停留所からの運行コストがゼロとなる仮想ランドマークとして設定して、所定の記憶手段に、前記経路探索ツールによる検索可能に予め登録する登録手段を有し、登録した仮想ランドマークを前記出発地又は前記目的地として前記経路探索ツールに認識させる仮想ランドマーク登録ツールと、を備えた装置である。
「仮想ランドマーク」は、実際には存在しない目標を、あたかも存在するかの如く扱うためのものであるが、利用者の便宜を図る観点からは、実際に常用されている駅名であることが望ましい。「設定」は、少なくとも経路探索ツールが認識できる時間、所定のメモリ領域に存在させることをいう。「ツール」は、コンピュータのハードウエア資源をプログラムが制御することによって、そのコンピュータ資源特有の性質を利用して形成される機能実現体である。
【００１２】
仮想ランドマークを経路探索ツールに出発地等として認識させることにより、経路探索処理中、その仮想ランドマークを媒介として、直ちに、実際の複数の同名異駅または同名異停を経路に含む運行コストを比較できるので、探索範囲の無駄な拡がりを防止することができる。また、同名異駅、同名異停の存在を考慮する必要がなくなることから、システム設計（例えば、プログラム開発、必要なハードウエアの準備等）も簡素化され、経路探索条件の自動認識・自動実行の環境実現が可能となるし、利用者にとっても、きわめて操作性に優れた運行経路探索装置とすることができる。
【００１３】
本発明の他の運行経路探索装置は、上記の運行経路探索装置において、さらに、利用者が操作する情報端末との通信を可能にするインタフェース手段と、前記インタフェース手段を通じて受信した、自然言語から成る依頼文に対して自然言語処理を行うことにより、その依頼文に含まれる語又は語句を抽出して、抽出した語又は語句を、予め定めた語又は語句と前記経路探索ツールが認識可能な前記経路探索条件との対応ルールに従って前記経路探索条件に変換する探索条件入力手段と、前記探索条件入力手段で変換した経路端末条件を、利用者による操作を要することなく前記経路探索ツールに入力し、これにより特定された最適経路候補を前記経路探索ツールより受け取り、受け取った最適経路候補を前記インタフェース手段を通じて前記情報端末において表示可能にする制御手段と、を有する装置である。
【００１４】
自然言語処理は、人間が日常的に使っている自然言語の内容を認識することにより意味のある語又は語句を抽出する処理である。このような自然言語の依頼文で経路探索を依頼する程度の簡単な手法によっても、探索条件入力手段によりシステム側でその依頼文に含まれる語又は語句を抽出して経路探索条件に変換し、経路探索ツールから経路探索結果を受け取れるので、利用者にとって快適となる経路探索の利用環境を、具体的且つ現実に、実現することができる。
なお、依頼文は、テキスト文、ＨＴＭＬ等、システム側でその意味内容を解析できる文であれば、どのようなデータ構造のものであっても良い。利用者が経路探索ツールから受け取る情報にも、自然言語から成る文が含まれるようにすることが望ましい。
【００１５】
本発明の運行経路探索システムは、複数の情報端末及びメールサーバによるアクセスが可能なネットワークに接続される運行経路探索システムであって、第１サーバ及び１又は複数の第２サーバを含んで構成される。
前記第１サーバは、上述した経路探索ツール及び仮想ランドマーク登録ツールを有するものであり、前記第２サーバは、上述したインタフェース手段、探索条件入力手段、及び、制御手段とを有するものである。
このような運行経路探索システムでは、例えば、第１サーバにおける経路探索に伴う実行負荷と、利用者からの窓口としての第２サーバの実行負荷並びに依頼文の受信数との最適化を図ることで、効率的な運行経路の探索環境を実現することができる。
【００１６】
本発明の運行経路探索方法は、上述した経路探索ツールと、同名となる複数の駅又は停留所について、その名称を当該駅又は停留所からの運行コストがゼロとなる仮想ランドマークとして設定して登録された記憶手段と、利用者が操作する情報端末とのインタフェース手段とを備えた装置で実行する運行経路探索方法であって、前記記憶手段に登録された前記仮想ランドマークを前記出発地又は前記目的地として前記経路探索ツールに認識させる過程と、利用者が情報端末を通じて自然言語で入力した依頼文を前記インタフェース手段を通じて受信したときに、受信したテキスト文に対して自然言語処理ツールで自然言語処理を行うことにより、その依頼文に含まれる語又は語句を抽出する過程と、抽出された語又は語句を、予め定めた語又は語句と前記経路探索条件との対応ルールに従って前記経路探索条件に変換する過程と、変換された経路端末条件を、前記利用者による操作を要することなく前記経路探索ツールに入力し、これにより特定された最適経路候補を前記経路探索ツールより受け取り、受け取った最適経路候補を、前記インタフェース手段を介して前記情報端末に表示可能な形態で伝達する過程とを有する、運行経路探索方法である。
【００１７】
本発明のコンピュータプログラムは、コンピュータを、上述した経路探索ツール及び仮想ランドマーク登録ツールとして機能させる、運行経路探索用のコンピュータプログラムである。
【発明の効果】
【００１８】
本発明によれば、仮想ランドマークを設定し、これを経路探索ツールにおいて出発地等として認識させることで、同名異駅や同名異停の存在に伴う問題点が解消される。また、出発地等に同名異駅や同名異停が含まれるときに、利用者にどれか一つを絞り込ませる必要がなくなり、システム設計の簡素化も可能となる。さらに、経路探索の際の無駄なリソースの費消が回避されるので、経路探索時の実行負荷が格段に軽減される。同名異駅や同名異停の存在に伴う問題点が解消されるので、利用者に快適となる利用環境、例えば自然言語によるテキスト文での経路探索も具体的に実現可能となる。
【図面の簡単な説明】
【００１９】
【図１】本発明を適用した運行経路探索システムの全体構成図。
【図２】経路探索ツールによる駅間探索の仕方の説明図。
【図３】経路探索ツールにおいて仮想ランドマークを用いた場合の手順を説明する図であり、（ａ）は仮想ランドマーク（「府中」）を出発地として認識させた場合の例、（ｂ）はそれを目的地として認識させた場合の例である。
【図４】ルールテーブルの内容説明図。
【図５】携帯経路探索サービスを提供する場合のサービス制御部の制御手順説明図。
【図６】（ａ）は携帯経路探索サービスを電子メールで依頼するときのテキスト文の内容例を示した図、（ｂ）はこのテキスト文に対して運行経路探索サービスから返信される経路探索結果情報の説明図。
【発明を実施するための形態】
【００２０】
以下、本発明を、携帯端末向けの経路探索サービスを可能にするネットワーク型の運行経路探索システムに適用した場合の実施の形態例を説明する。
【００２１】
図１は、この実施形態の運行経路探索システムの全体構成図であり、特徴的な部分のみを掲示してある。この運行経路探索システムは、インターネット等のディジタルネットワークＮに接続される経路探索サーバ１０と、１又は複数の携帯サービスサーバ２０（図示の例では一つ）とを含んで構成される。ディジタルネットワークＮには、メールサーバ６０や情報端末の一例となるパーソナルコンピュータ(ＰＣ)も接続可能になっている。情報端末の他の例となる携帯端末５０は、データ通信及びデータ処理機能を有する場合はダイレクトに、メール機能のみであればメールサーバ６０を通じて、それぞれディジタルネットワークＮに接続することができるものとする。
【００２２】
[経路探索サーバ]
経路探索サーバ１０は、サーバ本体と本発明のコンピュータプログラムとの協働により実現される。すなわち、サーバ本体が、コンピュータプログラムを読み込んで実行することにより、そのサーバ本体を、データ通信用インタフェース１００、経路探索ツール１１０、及び、仮想ランドマーク登録ツール１２０として機能させ、経路探索のための情報処理を実行可能にする。
【００２３】
データ通信用インタフェース１００はデータ通信及びデータ処理機能を有する携帯端末５０やＰＣ７０との双方向通信を可能にするとともに、これらの情報端末が閲覧可能な階層ページ画面を提供する。この階層ページ画面では、運行経路探索のＷｅｂサービスを行うためのもので、経路探索条件の精緻な指定をシステム側と利用者との間でインタラクティブに行うことにより、利用者が満足する経路探索を行う環境を提供する。経路探索の結果情報の表示も、このページ画面で行うことができる。
【００２４】
経路探索ツール１１０は、交通機関（鉄道／バス）の路線、時刻表等のデータを蓄積した運行情報ＤＢ（ＤＢはデータベースの略、以下同じ）１１１と、経路探索エンジン１１２とを含み、経路探索条件の入力を契機に、運行情報ＤＢ１１１に蓄積されている情報をもとに経路探索エンジン１１２が経路の運行コストが最も小さい次の駅又は停留所の探索処理を、水面に石を投げたときの波紋のように連鎖的に繰り返すことにより、経路探索条件に従う最適経路候補を特定する。「運行コスト」は通常は時間を対象とするが、距離、運賃を用いても良く、あるいは、これらの組み合わせを対象としても良い。経路探索ツール１１０は、推論エンジンも搭載しており、探索途中で現実的でない経路となることが判明した場合は、その経路についての次の駅以降の探索を止める。
【００２５】
経路探索条件としては、出発地と目的地との間の最適経路候補の特定、出発地から一定範囲内に存する駅又は停留所の特定、目的地に所定時間内に到達する駅又は停留所の特定、出発時刻、到着時刻、探索範囲等の組み合わせである。この経路探索ツール１１０の基本機能部分は、例えば本願出願人が提供している経路探索ソフトウエア「駅すぱあと」（登録商標）のものを使用することができる。
【００２６】
図２は、経路探索ツール１１０による最も一般的な探索処理、すなわち出発地と目的地との間の最適経路候補の特定を行う場合の探索の様子を示した図である。図示の例は、東京都の東高円寺駅と高円寺駅との間のごく短い区間であるが、このような短い区間の中でも、膨大な数の経路が存在することを表している。
【００２７】
仮想ランドマーク登録ツール１２０は、駅又は停留所の中で、同名異駅（鉄道路線の場合）及び同名異停（バス路線の場合）のその駅名又は停留所名を仮想ランドマークとして設定し、これを出発地又は目的地として経路探索ツール１１０に認識させるものである。実際には存在しないものであるため、仮想ランドマークから各駅又は停留所までの運行コストをそれぞれゼロ、すなわち運行コストを時間とみる場合は、徒歩０分と設定する。
仮想ランドマーク登録ツール１２０は、経路探索ツール１１０が経路探索を行っている過程で同名異駅等を検出したときに、その指示のもとに起動して、その都度、仮想ランドマークを設定するが、外部からの設定の登録を受け付ける登録部１２１を介して仮想ランドマークＤＢ１２２に予め登録しておき、経路探索エンジン１１２によって随時検索して、これにより得たものを設定するようにしても良い。その都度設定する場合、一度新規に設定した仮想ランドマークは、仮想ランドマークＤＢ１２２に登録しておくようにする。
【００２８】
一例として、上述の「府中」を仮想ランドマークとし、実在する東京都の府中駅、広島県の府中駅、徳島県の府中駅から徒歩０分と設定して、これを経路探索ツール１１０で出発地又は目的地として扱うことの経路探索上の意味をより詳しく説明する。
【００２９】
図３（ａ）は、出発地として仮想ランドマーク（「府中」）を認識させる場合の例を示す。この出発地からの所要時間内となる駅又は停留所を探索する範囲探索でも良いが、ここでは、目的地として東京都の「高円寺」が認識されているものとする。
この場合、経路探索ツール１１０は、運行コストゼロ（徒歩０分）で関連付けられている東京都の府中駅、徳島県の府中駅、広島県の府中駅を起点とした次の駅までの運行コストを、まず計算する。東京都の府中駅を除く他の２駅を起点とした場合の次の駅以降の運行コストは、この時点で「高円寺」までの運行時間が数十時間を越えるため、現実的な経路ではないとして直ちに探索すべき経路候補から除外される（図示の破線）。そのため、それ以上無駄にリソースを費消することなく、東京都の府中駅に繋がる次の以降の経路探索のみに移行することができる。駅の数は膨大なので、仮想ランドマークがない場合に徳島県の府中駅及び広島県の府中駅に繋がる次の駅以降の探索をも繰り返す従来型の手法と比べて軽減されるリソースは、計り知れないほど大きい。
【００３０】
この特徴は、図３（ｂ）のように、目的地として仮想ランドマーク（「府中」）を認識させる場合に、より顕著となる。すなわち、経路探索の直前区間と東京都の府中駅、徳島県の府中駅、広島県の府中駅との運行コストを比較するだけで、直ちに後者２駅に繋がる経路が除外される。
【００３１】
このように、運行経路探索において、仮想ランドマークを通じて直ちに実在の複数の駅又は停留所間の運行コストの比較が行えるため、利用者が必要としている可能性が最も高い経路を迅速に特定して、利用者に返すことができる。システム設計も、同名異駅等のどの駅を特定するのかをその都度利用者に確認する必要がないから著しく簡素化され、利用者にとっても、他の地域に存在する同名の駅等を意識することなく、常用されている駅名等を指定することができるので、利用者との間で経路探索条件の入力確定までにインタラクティブな意思確認がとれない、あるいはとりにくい利用環境であっても、運行経路探索が実行できるようになる。経路探索条件の自動入力・自動実行の環境も、この運行コストゼロの仮想ランドマークを使用することにより実現が可能となる。
【００３２】
なお、仮想ランドマークは、実際には存在しない駅、停留所等の目標（ランドマーク）を存在するとみせかけて探索処理を行わせる点で、多くの経路探索システムで採用されているランドマーク登録機能で扱うランドマークとは異なる点に留意すべきである。公知のランドマーク登録機能は、実在する施設等をランドマークとし、そこに最寄駅及び徒歩等の交通手段を関連付けて予め登録しておくもので、最寄駅からの距離が長いときの総所要時間、最寄駅が複数あるときの最適経路の選択等のために用いられるものである。
【００３３】
［携帯サービスサーバ］
携帯サービスサーバ２０は、本実施形態による経路探索サーバ１０が経路探索条件の自動入力・自動実行のための環境を有することから、この経路探索サーバ１０と連携して、携帯端末５０を利用した任意の場所からの経路探索サービス、特に電子メールを伝達媒体とする自然言語による経路探索サービスを実現するものである。
【００３４】
携帯サービスサーバ２０は、経路探索サーバ１０同様、サーバ本体とコンピュータプログラムとの協働により実現される。すなわち、サーバ本体がコンピュータプログラムを読み込んで実行することにより、サーバ本体を、携帯端末用インタフェース２００、編集部２１１を有するサービス制御部２１０、探索条件入力部２２０として機能させる。探索条件入力部２２０は、ルールテーブル２２１、自然言語処理ツール２２２及び変換ツール２２３を有する。
【００３５】
携帯端末用インタフェース２００は、ディジタルネットワークＮに接続されているメールサーバ６０を介して携帯端末５０との電子メールによる双方向通信を可能にするものである。電子メールのみを受け付けるようにした点で、データ通信用インタフェース１００とは区別される。
【００３６】
探索条件入力部２２０において、ルールテーブル２２１には、語又は語句と経路探索ツール１１０が認識可能な経路探索条件との対応ルールが記録されている。ここにいう対応ルールは、図４にその一部を例示するように、例えば「○○（駅）から」とか「○○（駅）を」という語句に対する出発地が「○○」という如きものである。目的地、出発時刻、到着時刻、所要時間、所要距離について、それぞれ同様のルールテーブルを用意しておく。また、実行依頼と共に経路探索ツール１１０に伝える条件ルール、すなわち２つの駅名だけ入力のときは駅間の平均経路の探索、２つの駅名と出発時刻の組み合わせのときは各経路の通過時刻の探索、２つの駅名と到着時刻の組み合わせのときはその到着時刻以前に到着するときの各経路の時刻の探索、一つの駅名と所要時間のときはその駅を出発駅としたときの範囲探索（出発駅からその所要時間内に到着可能な駅の探索）の探索・・・も対応ルールとして用意しておく。
【００３７】
自然言語処理ツール２２２は、携帯端末用インタフェース２００を通じて受信した、自然言語から成る依頼文に対して自然言語処理を施すことにより、その依頼文に含まれる語又は語句を抽出する。この自然言語処理ツール２２２としては、例えば、ＳＥＴソフトウエア株式会社が販売する「Ｌ−ｎａｖｉ（自然言語インタフェース組込型開発キット）」を使用することができる。
変換ツール２２３は、自然言語処理ツール２２２で抽出した語又は語句をルールテーブル２２１に従って経路探索条件に変換する。
【００３８】
サービス制御部２１０は、携帯サービスサーバ２０全体における各種動作を制御する。例えば、携帯端末５０から電子メールを受信したことを携帯端末用インタフェース２００が検知したときに、探索条件入力部２２０を制御して電子メール中の依頼文から経路探索条件を含む部分を抽出させ、抽出された経路探索条件を利用者による操作を要することなく経路探索ツール１１０に入力させる。つまり、自動入力・自動実行依頼である。経路探索ツール１１０で最適経路候補が特定されたときは、これを経路探索ツール１１０より受け取り、受け取った最適経路候補を編集部２１１で携帯端末５０のディスプレイで表示可能なサイズの電子情報に編集する。そして、携帯端末用インタフェース２００を制御することにより、編集した電子情報をメールサーバ６０を介して電子メールの送信元である携帯端末５０に返信し、表示させる。電子情報は、自然言語から成る文を含む。この文はテキスト文、ＨＴＭＬその他、利用者が容易に理解できるデータ構造のものである。画像入りであっても良い。テキスト文やＨＴＭＬのみとする場合は、処理の負荷が軽くなるので、より迅速な応答が可能になる。
【００３９】
［運用形態］
次に、本実施形態の運行経路探索システムの運用形態例を説明する。
ここでは、利用者に携帯経路探索サービスを提供する場合の例を説明する。携帯経路探索サービスは、利用者が携帯端末５０を操作して電子メールで運行経路探索のサービスを受けられるようにするサービスである。このサービスは、携帯サービスサーバ２０が主導的に動作する。
【００４０】
図５は、携帯サービスサーバ２０におけるサービス制御部２１０の制御手順を示した図である。
利用者は、電子メールで経路探索を依頼する。ここでは、一例として、図６（ａ）に示すように、「大宮から新宿を経由して清里まで１２月２５日、１３時着の経路を教えてください。」という内容の依頼文を、電子メールで、運行経路探索システムの専用アドレスに発信したとする。
【００４１】
サービス制御部２１０は、この電子メールを受信すると（ステップＳ１０１：Yes）、発信元のメールアドレスをアドレスメモリ（図示省略）に記録する（ステップＳ１０２）。自然言語処理ツール２２２を起動し、メール文（依頼文）の解析と自然言語処理による語句抽出とを行う（ステップ１０３）。なお、図示の例では同名異駅や同名異停が存在しないが、仮に依頼文にこれらが含まれている場合は、その名称のまま抽出する。変換ツール２２３を起動して、抽出された語句とルールテーブル２２１とに基づいて経路探索条件を生成する（ステップＳ１０４）。生成された経路探索条件を経路探索ツール１１０に自動入力し、且つ自動実行を依頼する（ステップＳ１０５）。
【００４２】
経路探索ツール１１０は、この経路探索条件及び自動実行依頼を受け付け、経路探索条件に従う最適経路候補を探索するための処理を開始する。「最適経路」ではなく「最適経路候補」とするのは、最適かどうかを判断するのは、利用者であることによる。経路探索条件の中には、出発地又は目的地の少なくともいずれかが含まれているので、経路探索ツール１１０は、探索開始に際して仮想ランドマークＤＢ１２２を参照し、出発地等について仮想ランドマークが登録されているかどうかをチェックする。
本例の場合は、同名異駅等は存在しないが、仮に存在し、それが仮想ランドマークとして登録されている場合は、それを出発地等として認識する。存在しなくとも探索開始時にそれが同名異駅等であることが判明したときは、仮想ランドマークを設定し、設定後はそれを仮想ランドマークＤＢ１２２に登録する。
【００４３】
経路探索ツール１１０から探索結果を受信すると（ステップＳ１０６：Yes）、サービス制御部２１０は、その経路探索結果を含む情報を携帯端末宛のメール用に編集する（ステップＳ１０７）。すなわち、ＰＣ７０等のディスプレイと異なり、携帯端末５０のディスプレイは小さいし、解像度も低いので、余分な情報を取り除き、なるべく少ないパケット数で且つなるべく１画面で表示することができ、しかし必要な情報は盛り込むように編集する。その後、発信元のメールアドレスを読み出し（ステップＳ１０８）、編集済の経路探索結果情報を発信元のメールアドレス宛に発信する（ステップＳ１０９）。
【００４４】
携帯端末５０は、このようにして編集された経路探索結果情報をディスプレイに表示させる。本例の場合に表示される内容例を示したのが図６（ｂ）である。図示されるように、この例では、情報量が多いので、テキスト文に編集されているが、情報量に応じて、あるいは利用者による明示の指定があった場合に、画像ないし図形を含めることは、可能である。
【００４５】
このように、本実施形態の運行経路探索システムでは、経路探索サーバ１０で仮想ランドマークを設定する機能を持たせ、無駄なリソースの費消の回避と利用者に同名異駅のどの駅なのかの確認を不要にした仕組みを実現したので、経路探索条件の自動入力・自動実行が可能となった。また、この仕組みを利用し、利用者が、例えば携帯端末５０のような比較的簡易な情報端末を用い、自然言語で、しかも電子メールで経路探索依頼を行うだけで、探索結果情報が得られるようにしたので、利用者に快適となる経路探索の利用環境を提供することができる。電子メールなので、携帯端末の機種を代えても不都合なくこのサービスを利用することができる。もちろん、ＰＣを使用してこのサービスを使用することもできる。
【００４６】
従来のこの種の運行経路探索システム（例えば特許文献２参照）で、データ処理機能を有する携帯端末からネットワークを介して経路探索を行う同種のサービスを実現しようとする場合に以下の手順が不可欠となることを考えると、本実施形態の運行経路探索システムが利用者に与えるインパクトの大きさは、容易に理解されよう。
（ａ）利用者が、経路探索サービスのサイトにアクセスする。または、経路探索アプリケーションを起動する。ここで一定の時間がかかる。
（ｂ）利用者が、出発駅と到着駅とを指定する。同名異駅の場合は、それが存在する複数の都道府県と共に表示されるので、その中から一つを選択する。確定するかどうかの確認を必要とする。そのため、ここでも時間がかかり、携帯端末の通信料も余分にかかる。
（ｃ）経路探索が実行される。同名異駅等が含まれている場合は、現実にあり得ない経路が最適経路候補として、しかもより上位に特定される可能性がある。この場合、次の経路を表示させるまで時間と通信料がかかる。
（ｄ）探索結果を得、画面に表示させる。
【００４７】
なお、本実施形態では、経路探索サーバ１０と携帯サービスサーバ２０とをそれぞれ別のサーバ本体で実現した場合の例を示した。これは、経路探索サーバ１０の実行負荷が携帯サービスサーバ２０に比べて大きく、他方、携帯サービスサーバ２０の数が多いほど携帯サービスの利用者に対する窓口が多くなるため、分散させた方がシステム運用の最適化を図る上で好ましいことが主たる理由である。しかし、常にこのような形態で運用しなければならないというわけではなく、各サーバ１０，２０の機能を一つのサーバに統合する実施の形態も可能である。この場合は、本発明の機能を実現するためのコンピュータプログラムが一つで足りるという利点がある。
【００４８】
また、このような一つのコンピュータプログラムをＰＣ等の汎用コンピュータにインストールすることにより、そのコンピュータを単独の運行経路探索装置として動作させることができる。
【００４９】
また、本実施形態では、携帯経路探索サービスを提供する場合の例を中心に説明したが、このサービスによらず、時間及び手間がかかっても、探索条件を精緻に指定した経路探索を望む場合は、携帯端末５０のデータ処理機能を利用して、経路探索サーバ１０のデータ通信用インタフェース１００にアクセスし、これによって経路探索エンジン１１０を操作するという利用形態も可能である。
【産業上の利用可能性】
【００５０】
本発明は、鉄道、バス等の公共交通機関による最適経路探索に用いることは勿論であるが、仮想ランドマークを用いた機能は、カーナビゲーション等にも広く応用が可能である。
【符号の説明】
【００５１】
１０・・・経路探索サーバ、２０・・・携帯サービスサーバ、５０・・・携帯端末、６０・・・メールサーバ、７０・・・ＰＣ、１００・・・データ通信用インタフェース、１１０・・・経路探索ツール、１２０・・・仮想ランドマーク登録ツール、２００・・・携帯端末用インタフェース、２１０・・・サービス制御部、２２０・・・探索条件入力部、Ｎ・・・ディジタルネットワーク。
【特許請求の範囲】
【請求項１】
出発地及び目的地の少なくとも一方を含む経路探索条件の入力を契機に、前記出発地又は前記目的地を起点とする経路の運行コストが最も小さい次の駅又は停留所の探索処理を連鎖的に繰り返すことにより、前記経路探索条件に従う最適経路候補を特定する経路探索ツールと、
同名となる複数の駅又は停留所について、その名称を当該駅又は停留所からの運行コストがゼロとなる仮想ランドマークとして設定して、所定の記憶手段に、前記経路探索ツールによる検索可能に予め登録する登録手段を有し、登録した仮想ランドマークを前記出発地又は前記目的地として前記経路探索ツールに認識させる仮想ランドマーク登録ツールと、を備えて成る、
運行経路探索装置。
【請求項２】
利用者が操作する情報端末との通信を可能にするインタフェース手段と、
前記インタフェース手段を通じて受信した、自然言語から成る依頼文に対して自然言語処理を行うことにより、その依頼文に含まれる語又は語句を抽出して、抽出した語又は語句を、予め定めた語又は語句と前記経路探索ツールが認識可能な前記経路探索条件との対応ルールに従って前記経路探索条件に変換する探索条件入力手段と、
前記探索条件入力手段で変換した経路端末条件を、利用者による操作を要することなく前記経路探索ツールに入力し、これにより特定された最適経路候補を前記経路探索ツールより受け取り、受け取った最適経路候補を前記インタフェース手段を通じて前記情報端末において表示可能にする制御手段と、をさらに有する、
請求項１記載の運行経路探索装置。
【請求項３】
前記情報端末は、ディスプレイを備えた携帯端末であり、
前記インタフェース手段は、前記携帯端末からの電子メールにより前記依頼文を受信し、
前記制御手段は、前記経路探索ツールにより特定された最適経路候補を前記ディスプレイで表示可能なサイズの電子情報に編集し、編集した電子情報を前記インタフェース手段を介して前記電子メールの送信元に返信する、
請求項２記載の運行経路探索装置。
【請求項４】
前記編集した電子情報が自然言語から成る文を含む、
請求項３記載の運行経路探索装置。
【請求項５】
複数の情報端末及びメールサーバによるアクセスが可能なネットワークに接続される運行経路探索システムであって、第１サーバ及び１又は複数の第２サーバを含んで構成されており、
前記第１サーバは、
出発地及び目的地の少なくとも一方を含む経路探索条件の入力を契機に、前記出発地又は前記目的地を起点とする経路の運行コストが最も小さい次の駅又は停留所の探索処理を連鎖的に繰り返すことにより、前記経路探索条件に従う最適経路候補を特定する経路探索ツールと、
同名となる複数の駅又は停留所について、その名称を当該駅又は停留所からの運行コストがゼロとなる仮想ランドマークとして設定して、所定の記憶手段に、前記経路探索ツールによる検索可能に予め登録する登録手段を有し、登録した仮想ランドマークを前記出発地又は前記目的地として前記経路探索ツールに認識させる仮想ランドマーク登録ツールとを有しており、
前記第２サーバは、
前記情報端末又はメールサーバとの通信を可能にするインタフェース手段と、
前記インタフェース手段を通じて受信した、自然言語から成る依頼文に対して自然言語処理を行うことにより、その依頼文に含まれる語又は語句を抽出して、抽出した語又は語句を、予め定めた語又は語句と前記経路探索ツールが認識可能な前記経路探索条件との対応ルールに従って前記経路探索条件に変換する探索条件入力手段と、
この変換ツールで変換された経路端末条件を、前記利用者による操作を要することなく前記第１サーバの経路探索ツールに入力し、これにより特定された最適経路候補を前記経路探索ツールより受け取り、受け取った最適経路候補を前記インタフェース手段を通じて前記情報端末において表示可能にする制御手段とを有している、
運行経路探索システム。
【請求項６】
出発地及び目的地の少なくとも一方を含む経路探索条件の入力を契機に、前記出発地又は前記目的地を起点とする経路の運行コストが最も小さい次の駅又は停留所の探索処理を連鎖的に繰り返すことにより、前記経路探索条件に従う最適経路候補を特定する経路探索ツールと、同名となる複数の駅又は停留所について、その名称を当該駅又は停留所からの運行コストがゼロとなる仮想ランドマークとして設定して登録された記憶手段と、利用者が操作する情報端末とのインタフェース手段とを備えた装置で実行する運行経路探索方法であって、
前記記憶手段に登録された前記仮想ランドマークを前記出発地又は前記目的地として前記経路探索ツールに認識させる過程と、
利用者が情報端末を通じて自然言語で入力した依頼文を前記インタフェース手段を通じて受信したときに、受信した依頼文に対して自然言語処理ツールで自然言語処理を行うことにより、その依頼文に含まれる語又は語句を抽出する過程と、
抽出された語又は語句を、予め定めた語又は語句と前記経路探索条件との対応ルールに従って前記経路探索条件に変換する過程と、
変換された経路端末条件を、前記利用者による操作を要することなく前記経路探索ツールに入力し、これにより特定された最適経路候補を前記経路探索ツールより受け取り、受け取った最適経路候補を、前記インタフェース手段を介して前記情報端末に表示可能な形態で伝達する過程とを有する、
運行経路探索方法。
【請求項７】
コンピュータを、出発地及び目的地の少なくとも一方を含む経路探索条件の入力を契機に、前記出発地又は前記目的地を起点とする経路の運行コストが最も小さい次の駅又は停留所の探索処理を連鎖的に繰り返すことにより、前記経路探索条件に従う最適経路候補を特定する経路探索ツール、及び、
同名となる複数の駅又は停留所について、その名称を当該駅又は停留所からの運行コストがゼロとなる仮想ランドマークとして設定して、所定の記憶手段に、前記経路探索ツールによる検索可能に予め登録する登録手段を有し、登録した仮想ランドマークを前記出発地又は前記目的地として前記経路探索ツールに認識させる仮想ランドマーク登録ツールとして機能させる、運行経路探索用のコンピュータプログラム。
【請求項１】
出発地及び目的地の少なくとも一方を含む経路探索条件の入力を契機に、前記出発地又は前記目的地を起点とする経路の運行コストが最も小さい次の駅又は停留所の探索処理を連鎖的に繰り返すことにより、前記経路探索条件に従う最適経路候補を特定する経路探索ツールと、
同名となる複数の駅又は停留所について、その名称を当該駅又は停留所からの運行コストがゼロとなる仮想ランドマークとして設定して、所定の記憶手段に、前記経路探索ツールによる検索可能に予め登録する登録手段を有し、登録した仮想ランドマークを前記出発地又は前記目的地として前記経路探索ツールに認識させる仮想ランドマーク登録ツールと、を備えて成る、
運行経路探索装置。
【請求項２】
利用者が操作する情報端末との通信を可能にするインタフェース手段と、
前記インタフェース手段を通じて受信した、自然言語から成る依頼文に対して自然言語処理を行うことにより、その依頼文に含まれる語又は語句を抽出して、抽出した語又は語句を、予め定めた語又は語句と前記経路探索ツールが認識可能な前記経路探索条件との対応ルールに従って前記経路探索条件に変換する探索条件入力手段と、
前記探索条件入力手段で変換した経路端末条件を、利用者による操作を要することなく前記経路探索ツールに入力し、これにより特定された最適経路候補を前記経路探索ツールより受け取り、受け取った最適経路候補を前記インタフェース手段を通じて前記情報端末において表示可能にする制御手段と、をさらに有する、
請求項１記載の運行経路探索装置。
【請求項３】
前記情報端末は、ディスプレイを備えた携帯端末であり、
前記インタフェース手段は、前記携帯端末からの電子メールにより前記依頼文を受信し、
前記制御手段は、前記経路探索ツールにより特定された最適経路候補を前記ディスプレイで表示可能なサイズの電子情報に編集し、編集した電子情報を前記インタフェース手段を介して前記電子メールの送信元に返信する、
請求項２記載の運行経路探索装置。
【請求項４】
前記編集した電子情報が自然言語から成る文を含む、
請求項３記載の運行経路探索装置。
【請求項５】
複数の情報端末及びメールサーバによるアクセスが可能なネットワークに接続される運行経路探索システムであって、第１サーバ及び１又は複数の第２サーバを含んで構成されており、
前記第１サーバは、
出発地及び目的地の少なくとも一方を含む経路探索条件の入力を契機に、前記出発地又は前記目的地を起点とする経路の運行コストが最も小さい次の駅又は停留所の探索処理を連鎖的に繰り返すことにより、前記経路探索条件に従う最適経路候補を特定する経路探索ツールと、
同名となる複数の駅又は停留所について、その名称を当該駅又は停留所からの運行コストがゼロとなる仮想ランドマークとして設定して、所定の記憶手段に、前記経路探索ツールによる検索可能に予め登録する登録手段を有し、登録した仮想ランドマークを前記出発地又は前記目的地として前記経路探索ツールに認識させる仮想ランドマーク登録ツールとを有しており、
前記第２サーバは、
前記情報端末又はメールサーバとの通信を可能にするインタフェース手段と、
前記インタフェース手段を通じて受信した、自然言語から成る依頼文に対して自然言語処理を行うことにより、その依頼文に含まれる語又は語句を抽出して、抽出した語又は語句を、予め定めた語又は語句と前記経路探索ツールが認識可能な前記経路探索条件との対応ルールに従って前記経路探索条件に変換する探索条件入力手段と、
この変換ツールで変換された経路端末条件を、前記利用者による操作を要することなく前記第１サーバの経路探索ツールに入力し、これにより特定された最適経路候補を前記経路探索ツールより受け取り、受け取った最適経路候補を前記インタフェース手段を通じて前記情報端末において表示可能にする制御手段とを有している、
運行経路探索システム。
【請求項６】
出発地及び目的地の少なくとも一方を含む経路探索条件の入力を契機に、前記出発地又は前記目的地を起点とする経路の運行コストが最も小さい次の駅又は停留所の探索処理を連鎖的に繰り返すことにより、前記経路探索条件に従う最適経路候補を特定する経路探索ツールと、同名となる複数の駅又は停留所について、その名称を当該駅又は停留所からの運行コストがゼロとなる仮想ランドマークとして設定して登録された記憶手段と、利用者が操作する情報端末とのインタフェース手段とを備えた装置で実行する運行経路探索方法であって、
前記記憶手段に登録された前記仮想ランドマークを前記出発地又は前記目的地として前記経路探索ツールに認識させる過程と、
利用者が情報端末を通じて自然言語で入力した依頼文を前記インタフェース手段を通じて受信したときに、受信した依頼文に対して自然言語処理ツールで自然言語処理を行うことにより、その依頼文に含まれる語又は語句を抽出する過程と、
抽出された語又は語句を、予め定めた語又は語句と前記経路探索条件との対応ルールに従って前記経路探索条件に変換する過程と、
変換された経路端末条件を、前記利用者による操作を要することなく前記経路探索ツールに入力し、これにより特定された最適経路候補を前記経路探索ツールより受け取り、受け取った最適経路候補を、前記インタフェース手段を介して前記情報端末に表示可能な形態で伝達する過程とを有する、
運行経路探索方法。
【請求項７】
コンピュータを、出発地及び目的地の少なくとも一方を含む経路探索条件の入力を契機に、前記出発地又は前記目的地を起点とする経路の運行コストが最も小さい次の駅又は停留所の探索処理を連鎖的に繰り返すことにより、前記経路探索条件に従う最適経路候補を特定する経路探索ツール、及び、
同名となる複数の駅又は停留所について、その名称を当該駅又は停留所からの運行コストがゼロとなる仮想ランドマークとして設定して、所定の記憶手段に、前記経路探索ツールによる検索可能に予め登録する登録手段を有し、登録した仮想ランドマークを前記出発地又は前記目的地として前記経路探索ツールに認識させる仮想ランドマーク登録ツールとして機能させる、運行経路探索用のコンピュータプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図２】
【図３】
【図４】
【図５】
【図６】
【公開番号】特開２０１２−１２３８２２（Ｐ２０１２−１２３８２２Ａ）
【公開日】平成２４年６月２８日（２０１２．６．２８）
【国際特許分類】
【出願番号】特願２０１２−１８０１２（Ｐ２０１２−１８０１２）
【出願日】平成２４年１月３１日（２０１２．１．３１）
【分割の表示】特願２００７−２４５６６２（Ｐ２００７−２４５６６２）の分割
【原出願日】平成１９年９月２１日（２００７．９．２１）
【出願人】（５９６１３０１８５）株式会社 ヴァル研究所 (14)
【Ｆターム（参考）】
【公開日】平成２４年６月２８日（２０１２．６．２８）
【国際特許分類】
【出願日】平成２４年１月３１日（２０１２．１．３１）
【分割の表示】特願２００７−２４５６６２（Ｐ２００７−２４５６６２）の分割
【原出願日】平成１９年９月２１日（２００７．９．２１）
【出願人】（５９６１３０１８５）株式会社 ヴァル研究所 (14)
【Ｆターム（参考）】
[ Back to top ]