【事件の表示】
　特願２０１０−２３７３１７「ナビゲーション装置，ナビゲーションシステム，ナビゲーションサーバ，ナビゲーション方法，および，プログラム」拒絶査定不服審判事件〔平成２４年　５月１０日出願公開，特開２０１２−　８８２７１〕について，次のとおり審決する。
【結　論】
　本件審判の請求は，成り立たない。
【理　由】
１．手続の経緯・本願の発明
　本願は，平成２２年１０月２２日の特許出願であって，平成２５年１０月１８日付けで手続補正書が提出され，平成２６年　７月１１日付けで拒絶理由が通知され（発送日：平成２６年　７月２２日），同年　９月１９日付けで意見書が提出されたものの，同年１１月１３日付けで拒絶査定（発送日：同年１１月１８日）がなされ，この査定を不服として，平成２７年　２月１８日に本件審判が請求された。
　この出願の請求項１〜１８に係る発明は，平成２５年１０月１８日付け手続補正書により補正された特許請求の範囲の請求項１〜１８に記載された事項により特定されるものと認められるところ，その請求項１に係る発明（以下，「本願発明」という。）は，次のとおりのものである。
「【請求項１】
　交通網を規定するネットワーク情報を記憶するネットワーク情報記憶手段と，
　交通機関の運行情報を含む交通情報を記憶する交通情報記憶手段と，
　少なくとも出発地と目的地と出発時刻または到着時刻とを含む経路探索条件を満たす上記出発地から上記目的地までの案内経路を，少なくとも上記ネットワーク情報記憶手段に記憶された上記ネットワーク情報を用いて探索し，当該案内経路に関する経路情報を生成する案内経路探索手段と，
　上記案内経路上に，経路探索を要求するリルート地点を設定するリルート地点設定手段と，
　上記リルート地点設定手段により設定された上記リルート地点において上記案内経路が有効に利用できる期限である有効時刻を設定する有効時刻設定手段と，
　端末装置の利用者の現在位置情報を取得する現在位置情報取得手段と，
　上記経路情報を少なくとも含む経路案内情報を上記端末装置の出力部を介して出力させることにより，経路案内を実行する経路案内情報出力手段と，
　上記現在位置情報取得手段により取得された上記現在位置情報に基づく上記端末装置の上記利用者の現在位置と，上記リルート地点設定手段により設定された上記リルート地点と，が一致するか否か判定するリルート地点判定手段と，
　上記リルート地点判定手段により上記端末装置の利用者の現在位置と，上記リルート地点と，が一致すると判定された場合，現在時刻を取得する時刻取得手段と，
　上記時刻取得手段により取得された上記現在時刻が，上記有効時刻設定手段により設定された上記有効時刻を経過しているか否か判定する時刻判定手段と，
　上記時刻判定手段により上記現在時刻が上記有効時刻を経過していると判定された場合，当該リルート地点から上記目的地までの上記案内経路を，上記交通情報記憶手段に記憶された上記交通情報に基づいて，上記ネットワーク情報記憶手段に記憶された上記ネットワーク情報を用いて探索し，当該案内経路に関する上記経路情報を生成するリルート経路探索手段と，
　を備えたことを特徴とする，ナビゲーションシステム。」
２．刊行物とその記載事項　
　原査定の拒絶の理由に引用された本願出願前に頒布された刊行物である特開２００７−２０５９４６号公報（以下，「引用例」という。）には，「経路案内システム」に関し，図面とともに次の事項が記載されている（下線部は，当審により付与した。）。
・「【特許請求の範囲】
【請求項１】
　
ユーザからの指定に従って経路を探索し，案内する経路案内システムであって，
　通行可能な道路をノード，リンクで表したネットワークデータを参照するネットワークデータ参照部と，
　出発地，目的地の指定を入力する地点入力部と，
　経路探索を行う際の条件として，経路を通行する時刻に応じて経路探索結果に影響を与え得る時刻依存性のある時刻依存条件，および経路探索を行う際の基準時刻，ユーザの想定移動速度を含む探索条件を特定する探索条件特定部と，
  前記探索条件に従って，前記ネットワークデータに基づき前記出発地から目的地までの経路探索を行う経路探索部と，
  ユーザの現在位置を入力し，該現在位置に応じて前記探索された経路の経路案内を行う経路案内部とを有し，
　該経路案内部は，前記経路案内中の所定のタイミングにおけるユーザの現在位置および現在時刻に基づいて，前記経路探索によって得られた経路が前記時刻依存条件を満たさない状態にあると判断される時には，前記現在位置を前記出発地とし，前記現在時刻を前記基準時刻として前記経路探索部に前記経路探索を再試行させる再探索制御部を備える経路案内システム。
【請求項２】
　請求項１記載の経路案内システムであって，
　
前記時刻依存条件は，前記目的地または該目的地に至るまでの所定の地点への到着希望時刻である
・・・
【請求項６】
　請求項１〜５記載の経路案内システムであって，
  
前記再探索制御部は，ユーザが，案内すべき経路上に予め設定されたチェックポイントに至った時点で稼働する
・「【技術分野】
【０００１】
　本発明は，ユーザからの指定に従って経路を探索し，案内する経路案内システムに関し，詳しくは経路を通行する時刻に依存した探索条件を反映して経路探索および案内を行う経路案内システムに関する。」
・「【発明が解決しようとする課題】
【０００６】
　経路を探索する際には，目的地への到着希望時刻など，時刻に依存する探索条件（以下，「時刻依存条件」という。）を指定することも可能である。このような探索条件が指定された時には，経路案内システムは，ユーザの移動速度などについて予め用意された想定値を用いて探索条件に合致する経路を探索する。
【０００７】
　しかし，時刻依存条件が指定された場合，探索された経路を案内通りに通行していても探索時には予測できなかった状況変化が起き，探索された経路が，結果として探索条件を満たさなくなることがある。例えば，目的地への到着希望時刻が指定された場合，探索時よりもユーザの移動速度が遅い時には，案内された経路を通行していたとしても指定された到着希望時刻に遅れてしまうことが生じ得る。また，直射日光を避ける経路を指定した場合も，ユーザの移動速度が遅ければ，案内された経路は日陰から日向に変わっていることが起こり得るし，ユーザの移動速度が速ければ，逆にまだ日陰になっていないということも起こり得る。これらの状況は，ユーザの移動速度が経路探索時の想定速度よりも速すぎたり，遅すぎたりした場合だけでなく，ユーザの出発時刻が経路探索時の想定時刻とずれたり，案内途中でユーザが寄り道をしたり，案内途中で事故その他の事情により通行に支障が生じたりした場合などにも生じ得る。経路案内時の状況が経路探索時に想定した状況に完全に適合していることは稀であるから，上述の状況は，かなりの頻度で生じ得る。従って，従来の経路案内システムでは，時刻依存条件を指定した場合，十分に実用的な経路案内を行うことはできてはいなかった。本発明は，かかる課題に鑑み，経路案内システムにおいて，時刻に依存する探索条件を満足できるようにすることを目的とする。
【課題を解決するための手段】
【０００８】
　本発明は，ユーザからの指定に従って経路を探索し，案内する経路案内システムとして構成することができる。本発明の経路案内システムは，通行可能な道路をノード，リンクで表したネットワークデータを参照し，指定された出発地，目的地間で経路探索を行う。出発地については，ユーザからの指定としてもよいし，ユーザの現在位置をデフォルトの指定として用いるようにしてもよい。経路探索は，ユーザからの入力，プログラムでの既定値，予め用意されたデータベースからの読込などの方法で特定された探索条件に基づいて行う。この探索条件には，経路を通行する時刻に応じて経路探索結果に影響を与え得る時刻依存性のある時刻依存条件，および経路探索を行う際の基準時刻，ユーザの想定移動速度が含まれる。
時刻依存条件には
目的地に至るまでの所定の地点への到着希望時刻，
が含まれる。基準時刻としては，現在時刻や出発予定時刻などを用いることができる。
【０００９】
　経路案内システムは，経路探索の他，ユーザの現在位置を入力し，現在位置に応じて探索された経路の経路案内を行う。
経路案内中には，所定のタイミングで，ユーザの現在位置および現在時刻を入力し，現在位置および現在時刻が，案内すべき経路についての時刻依存条件を満たすか否かを判定する。そして，時刻依存条件が満たされないと判断される場合には，現在位置を出発地とし，現在時刻を基準時刻として経路探索を再試行する。
【００１０】
　本発明の経路案内システムは，歩行者を対象とする時に，より有用性が高い。時刻に依存する探索条件は，歩行者を対象とする経路探索では，より重視される傾向にあるからである。例えば，
歩行者を対象とする経路探索では，目的地への到着希望時刻は，駅や停留所を目的地とする経路探索において，交通機関のダイヤを踏まえて設定されることが多い。このような場合には，到着希望時刻に遅れてしまうとユーザが望んでいた電車，バスに乗り遅れることになってしまう。
【００１１】
　
時刻依存条件は，
目的地に至るまでの所定の地点への到着希望時刻とすることができる。
到着希望時刻の指定が有用となる一例として，例えば，交通機関のダイヤを踏まえて駅や停留所への到着希望時刻を指定する場合や，時間帯に応じて一方通行その他の交通規制が変動する箇所が経路上に含まれる場合などが挙げられる。
・「【００１５】
　
経路探索の再試行を行うか否かは種々のタイミングで判断することができる。例えば，ユーザが，案内すべき経路上に予め設定されたチェックポイントに至った時点でこの判断を行うようにしてもよい。
・「【００１８】
Ａ．システム構成：
　図１は実施例としての経路案内システムの構成を示す説明図である。本実施例では，歩行者用の経路案内システムとしての構成例を示すが，車両用の経路案内システムとして構成することもできる。経路案内システムは，携帯電話を利用した端末１００とサーバ２００とをネットワークＩＮＴで接続して構成されている。ネットワークＩＮＴは無線通信を利用したネットワークであり，ＬＡＮやイントラネットのように限定的なものであってもよいし，インターネットのように広域的なものであってもよい。端末１００は，携帯電話の他，いわゆる車両用のナビゲーション装置やＰＤＡ，ネットワーク通信機能を有するパーソナルコンピュータなどを利用することができる。歩行者用の経路案内システムとして構成する場合，車両用のナビゲーション装置は，車両から取り外して携帯可能としておくことが望ましい。
【００１９】
　端末１００は，ユーザの操作に応じて，経路探索および経路案内に必要な指示をサーバ２００に送信するための機能を奏する。図中には，端末１００の機能ブロックを併せて示した。端末１００は，ＣＰＵ，ＲＡＭ，ＲＯＭを備えたマイクロコンピュータを制御装置として内蔵しており，このＣＰＵはＲＯＭに記憶されたソフトウェアを実行することで，図示する各機能ブロックを構成する。これらの機能ブロックは，このようにソフトウェア的に構成する他，ハードウェア的に構成することも可能である。
【００２０】
　通信部１２０は，ネットワークＩＮＴを介してサーバ２００と通信する機能を奏する。
ＧＰＳ１４０は，全地球測位システム（Global Positioning System）を利用して，端末１００の現在位置の緯度，経度を検出する。コマンド入力部１３０は，スイッチ等に対するユーザ操作に基づいて，経路探索や経路案内に関するコマンドを入力する。コマンドとしては，図示した通り，経路探索の目的地の指定，探索条件の指定などが挙げられる。表示制御部１５０は，端末１００のディスプレイに，これらのコマンド入力用のメニューを表示したり，サーバ２００から受信した経路案内データに基づいて地図を表示させたりする。
【００２１】
　
サーバ２００は，端末１００からのコマンドに基づいて，種々のデータベースを参照しながら，経路探索を行ったり，経路案内を行ったりする。
【００２２】
　
サーバ２００が利用するデータベースは地図ＤＢ２５０，時刻表ＤＢ２５２
である。地図ＤＢ２５０は，通路をノード，リンクで表したネットワークデータ，および地図描画用のポリゴンや文字データからなる描画データを有している。
この規制条件としては，例えば，出発時刻が規定されている公共交通機関，所定時刻になると閉鎖される駅構内の通路などが挙げられる。時刻表ＤＢ２５２は，この規制条件を記録するデータベースである。
【００２３】
　ユーザＤＢ２５４は，ユーザＩＤ，氏名などの書誌的な登録情報と共に，ユーザが歩行する際の移動速度に関する設定や，距離優先／時間優先などの経路探索に関する要望事項を格納している。図中にはユーザＤＢ２５４の内容として移動速度に関する登録内容を例示した。本実施例では，移動速度は，移動可能な距離と組み合わせて登録されている。図中の例では，通常利用される移動速度（以下，「通常速度」と呼ぶこともある）は「４ｋｍ／ｈ」であり，移動可能な距離には制約がないことを表している。やや早足の「５ｋｍ／ｈ」では，３ｋｍまで移動可能であり，駆け足の「１０ｋｍ／ｈ」では０．５ｋｍまで移動可能であることを表している。これらの情報は，ユーザが端末１００を操作して登録，変更可能である。図中の例では，３通りの移動速度が登録されているが，更に多くの移動速度を登録可能としてもよい。
【００２４】
　通信部２２０は，端末１００とのネットワークＩＮＴ経由での通信を制御する。経路探索部２３０は，上述の３種類のデータベースを参照して，ユーザから指定された出発地，目的地間の経路を探索する。
経路探索部２３０は，ユーザからの指示に応じて，地図ＤＢ２５０および時刻表ＤＢ２５２を参照して，経路探索を行う。
【００２５】
　
経路案内部２４０は，探索された経路を地図上に表示して案内するための経路案内データを生成し，端末１００に送信する。経路案内部２４０は，経路案内の過程で，ユーザから指定された探索条件を満たしているか否かを判定し，探索条件が満たされていないと判断する場合には，経路探索部２３０に経路探索を再試行するよう指示する。
【００２６】
Ｂ．データ構造：
　図２は地図ＤＢ２５０および時刻表ＤＢ２５２のデータ構造を示す説明図である。
地図ＤＢ２５０については，経路探索用のネットワークデータの構造のみを例示した。図の中央に例示するように，ネットワークデータは，ノードＮ１〜Ｎ８およびリンクＬ１〜Ｌ９等で構成される。
【００２７】
　
地図ＤＢ２５０は，上述のノード，リンクに関するデータを，それぞれノードデータ２５０Ｎ，リンクデータ２５０Ｌとして格納し，地物に関するデータを地物データ２５０Ｂとして格納している。
【００２８】
　リンクデータ２５０Ｌの内容は，任意に設定可能であり，これらの情報の一部を省略してもよいし，ここに例示していない種々の属性情報を格納するようにしてもよい。例えば，階段や坂道などの経路種別や，ガードレールや街灯などの設備の有無等を属性情報として格納することができる。かかる属性情報が用意されている場合には，「階段を避けたい」，「ガードレールが整備されている経路を優先したい」などの経路に対する要望事項を反映した経路探索を実行することが可能となる。例えば，「階段を避けたい」という要望が出されている場合には，「階段」という属性情報が記録されているリンクのコストを増加させることによって，階段が選択される可能性を抑制することが可能となり，要望に沿った経路を探索することが可能となる。
【００２９】
　ノードデータ２５０Ｎには，図示するようにノードＩＤ，位置，時刻表，通行規制などの情報が記録される。「喫茶店」，「コンビニエンスストア」，「銀行」，「郵便局」などノードの種別を表す情報を含めてもよい。ノードの位置は，緯度，経度の座標で記録される。座標には，高さを表す情報を含めても良い。時刻表は，リンクデータ２５０Ｌと同様，時刻表ＤＢ２５２に格納されている情報へのリンクを表している。通行規制とは，右左折禁止など，時刻に応じて変化しない固定的な通行規制である。例えば，図中のノードＮ４について，Ｎ３方向から来てＮ６方向へ左折する通行が禁止される場合には，通行規制欄には，「Ｎ３→Ｎ４→Ｎ６」という形でデータを格納すればよい。通行規制情報の記録方法は，これに限らず，種々の形式を採用することができる。
【００３０】
　地物データ２５０Ｂには，図示するように地物ＩＤ，形状，高さ，属性などの情報が記録される。形状は，地物の平面形状を表すポリゴンの各頂点の緯度，経度の座標で記録される。形状の他，地物の代表点の緯度，経度を記録するようにしてもよい。高さは，本実施例では，建物の階数で表すものとしたが，高さの計測値を記録するようにしてもよい。属性は，ビル，ホテル，家屋など，地物の種別を表している。
【００３１】
　
時刻表ＤＢ２５２には，時刻表ＩＤ，規制，時刻，開始遅れ，終了遅れなどの情報が格納されている。
【００３２】
　時刻表ＤＢ２５２には，上述のような「通行止め」の規制の他，種々の規制が格納可能である。例えば，
本実施例では，電車などの交通機関の出発時刻も，その路線を通行可能な時間帯が限られているという意味で規制条件の一種とみなし，時刻表ＤＢ２５２で管理するものとした。
・「【００３７】
　図３（ｄ）は経路案内時の画面例である。案内すべき経路が，図３（ｃ）と異なり，目的地Ｇへの最短経路となっている。
本実施例では，経路案内の過程で，ユーザから指定された到着希望時刻の要求を満たさないと判断される状態になった場合には，再度経路探索を実行し，案内すべき経路を変更する機能を有している（以下，このように再度，経路探索を実行する機能を「リルート」と言う。）。
【００３８】
　
リルートは，種々のタイミングで実行することができる。
本実施例では，予め設定されたチェックポイントを通過する時点でリルートを行うようにした。
【００３９】
　
図４はリルートのチェックポイント設定例を示す説明図である。
【００４０】
　
モードＢは交差点にチェックポイントを設定するモードである。交差点は経路の分岐であるから，モードＢは経路を変更可能な最小限の箇所でリルートの要否を判断するモードであると言える。従って，モードＢによれば，リルートの要否の判断およびリルートに要する処理負担を軽減することができる利点がある。
【００４１】
　
モードＣは交通機関の乗降場所にチェックポイントを設定するモードである。図中では，バス停にチェックポイントが設定された例を示した。このモードによれば，経路案内の途中で，徒歩で移動するか，交通機関を利用するかの変更を効率的に行うことができる利点がある。
・・・
【００４３】
　
チェックポイントは図４に例示した他，種々の方法で設定することができる。図４に示した各モードは単独で用いる必要はなく，例えば，モードＢとモードＣとを組み合わせるなど，適宜，複数のモードを組み合わせて用いるようにしてもよい。
・「【００４４】
Ｄ．経路案内〜全体処理：
　図５は経路案内システムの全体処理のフローチャートである。サーバ２００が実行する処理のみを示した。図示を省略したが，この処理の過程で，サーバ２００は必要に応じて端末１００と通信しており，端末１００では，サーバ２００に情報を授受するための処理が稼働している。
【００４５】
　サーバ２００は，まず経路探索処理を実行する（ステップＳ１００）。この処理では，
サーバ２００は，ユーザから出発地，目的地，探索条件等の指定を受け付け，出発地から目的地に至る経路を探索する。
【００４６】
　次に，
サーバ２００は，探索された経路上に，チェックポイントを設定する
【００４７】
　その後，サーバ２００はユーザに対して経路を案内するための処理を開始する。まず，
端末１００から現在位置を入力し（ステップＳ１３２），チェックポイントにいるか否かを判断する（ステップＳ１３４）。ユーザが，チェックポイントに到達している場合には，時刻依存条件をクリアするか否か，つまり時刻依存条件を満たすか否かの判定を行う（ステップＳ１３６）。
【００４８】
　時刻依存条件をクリアしている場合には，サーバ２００は経路案内処理を行う（ステップＳ１３８）。ユーザがチェックポイントに至っていない場合にも（ステップＳ１３４），同様である。
経路案内処理では，端末１００に地図，現在位置，および案内すべき経路を表示する。
【００４９】
Ｅ．経路探索処理：
　図６は経路探索処理のフローチャートである。サーバ２００が実行する処理であり，図５で示した全体処理のステップＳ１００に相当する処理である。
サーバ２００は，ユーザからの指定に基づき最初に経路探索をする場合には（ステップＳ１０２），ユーザＩＤ，出発地，目的地，探索条件，出発時刻を入力する（ステップＳ１０４）。
【００５０】
　チェックポイントにおいて時刻依存条件がクリアできないと判定された場合に行われる再探索（図５のステップ１３６，Ｓ１００参照）の時には（図６のステップＳ１０４），ユーザＩＤ等の条件は入力不要なので，ステップＳ１０４はスキップする。ただし，本実施例では，再探索時にはユーザの移動速度を変更することとした（ステップＳ１０６）。ここで，移動速度は，種々の方法で変更可能である。例えば，移動速度を所定値ずつ，または所定比率で増減させてもよい。また，出発地からチェックポイントに至るまでの従前の平均移動速度を用いるようにしてもよい。
【００５１】
　こうして，経路探索に必要なデータの入力，設定が完了すると，サーバ２００は時刻依存条件を考慮して経路探索を実行する（ステップＳ１１０）。本実施例では，以下に示す通り，ダイクストラ法を用いて経路探索を行うものとした。時刻依存条件を考慮するため，ここでは所要時間をコストとして用いる。コストとしては，各リンクの距離を移動速度で除した値を用いることができる。ダイクストラ法は周知の手法であるため，詳細な説明は省略するが，本実施例に特徴的な部分についてのみ概要を説明する。
【００５２】
　ステップＳ１１０の処理では，サーバ２００は，地図ＤＢ２５０に格納されたノード，リンクのデータを参照して，出発地からリンク単位で経路を延伸して経路候補を設定する（ステップＳ１１２）。そして，この経路候補について，コストの総和を求めるとともに，各ノードへの到達時刻を予測する（ステップＳ１１４）。通行規制などが付されている箇所では，待ち時間が生じる場合もある。例えば，通行止めが一定の時間帯においてのみ解除される場合には，サーバ２００は，この待ち時間を次のリンクのコストへ反映した上で（ステップＳ１１６），最小コストとなる経路を選択する（ステップＳ１１８）。
【００５３】
　図中に，待ち時間が生じた場合の処理例を示した。この例は，ノードＢ，Ｃ，Ｄと通行する経路を表している。ＢＣ間のコストは８，ＣＤ間のコストは２０である。ＣＤ間には２０：００〜６：００は通行止めとなる通行規制が設定されている。この状態で，ノードＣへの到着希望時刻が５：３０と想定される場合，ノードＣでは，待ち時間が３０分生じる。ステップＳ１１６の処理では，この待ち時間３０分をノードＣに続くリンク，即ちＣＤ間のリンクに反映させ，ＣＤのコストを５０（＝２０＋３０）として処理をするのである。こうすることにより，ＣＤ間に迂回路が存在する場合には，その迂回路を通る経路を設定することも可能となる。
【００５４】
　ステップＳ１１４では，ユーザから指定された探索条件もコストに反映させることができる。例えば，階段を回避する探索条件が指定されている時は，階段に相当するリンクのコストを所定値または所定比率で増加させる。こうすることで，階段を通る経路が選択される可能性を抑制することができる。この他，気象条件に基づく探索条件を反映させる場合も同様である。気象条件に基づく探索条件を反映する際のコストの演算方法については，後述する。
【００５５】
　サーバ２００は，以上の処理を到達時刻までに目的地に至る経路が探索されるまで繰り返し実行する（ステップＳ１２０）。かかる経路が得られない場合には，探索条件を変更して（ステップＳ１２２），経路探索を再試行する（ステップＳ１１０）。図３に示したように，本実施例では，探索条件について優先順位が設定されているため，サーバは，ステップＳ１２２において，優先順位が最も低い条件を除外して経路探索を再試行するのである。この再試行でも経路が得られなかった場合には，サーバ２００は，ステップＳ１２２において，残った探索条件のうち優先順位が最も低い条件を除外して経路探索を更に試行することになる。」
・「【００６９】
Ｇ．リルート例：
（１）到着希望時刻を時刻依存条件とする場合：
　図９はリルートを行った例を示す説明図である。出発地から目的地まで向かう経路を案内する場合を例示した。途中の地点ＡＢ間では，バスまたは電車を利用するものとする。バスは所要時間５０分と短いが，３０００円の運賃が必要となる。電車は，運賃は２０００円と定額であるが，所要時間は７０分とバスよりも長い。電車およびバスは，ダイヤに従って運行されるため，出発時刻が限られる。本実施例では，図中に実線および破線で示す通り，それぞれ９時半，１０時，１０時半にＡ地点を出発するものとする。また，Ｂ地点から目的地までは，徒歩であれば所要時間１０分であり，タクシーを利用すれば運賃１０００円がかかるものの所要時間３分で済む。
【００７０】
　上述の状況で，１１時半を到着希望時刻として指定し，９時５０分を出発時刻とする場合の経路探索，案内結果を示す。この例では，実施例（図５）と同様，到着希望時刻が時刻依存条件に該当する。当初は，９時５０分に出発した後，実線で示すように移動し，Ａ地点から１０時発の電車を利用してＢ地点に到着した後，Ｂ地点から徒歩で目的地に向かう経路が探索されたとし，案内時には実際のユーザの移動速度が想定よりも遅く図中に破線で示すように移動したとする。
【００７１】
　サーバ２００は，この状態では１０時発の電車に乗ることができないと判断し，途中でスケジュール変更，即ちリルートを行う。この例では，徒歩でそのままＡ地点まで移動し，１０時半発のバスを利用し，Ｂ地点からはタクシーで移動することにより，到着希望時刻までに目的地に到達できる経路が得られるため，サーバ２００は，この経路をユーザに案内する。ユーザは当初予定されていた電車に乗れないことが分かっても，到着希望時刻に目的地に到達することができるため，経路案内に従って，安心して移動することができる。」
・「【００７６】
　図１０の例において，到着希望時刻を併せて考慮してもよい。つまり，日陰優先および到着希望時刻の双方を時刻依存条件として扱ってもよい。例えば，図１０の例において到着希望時刻が１３：００であったとする。分岐点に１１：４５に到着した時点で時刻依存条件を判定すると，Ａルートは，午後には日向になるから日陰優先という条件は満たされない。また，ＡルートとＢルートの距離が同一であるとすれば，Ａルートを経由した場合の到着時刻は１４：００と推定されることになり，到着希望時刻も満たされない。つまり，Ａルートは，日陰優先および到着希望時刻という２つの時刻依存条件のいずれも満たさない経路となる。  これに対し，Ｂルートは日陰優先という条件は満たすが，到着希望時刻は満たさない経路となる。
【００７７】
　図示したＡルート，Ｂルートの他に，Ｃルートが存在したものとする。Ｃルートは，近道または交通機関を利用した経路であり，Ｃルートを経由すれば，ユーザは目的地に到着希望時刻１３：００までに到着できるとする。Ｃルートが日陰優先という条件を満たす経路である場合には，Ａ〜Ｃルートのうち，Ｃルートのみが時刻依存条件を全て満たす経路となるから，サーバ２００はユーザに対してＣルートを案内することになる。
【００７８】
　Ｃルートが日陰優先という条件を満たさない経路である場合には，時刻依存条件間の優先順位に応じてＢルートまたはＣルートが選択される。日陰優先を到着希望時刻よりも優先する場合にはＢルートが選択され，到着希望時刻を日陰優先よりも優先する場合にはＣルートが選択される。時刻依存条件間の優先順位は，予め固定としてもよいし，図３（ｂ）に示した入力画面で，到着希望時刻も含めて優先順位を指定可能としてもよい。
【００７９】
　以上で説明した実施例の経路案内システムによれば，経路探索時の想定と実際の経路案内時の状況とが異なることにより，ユーザから指定された時刻依存条件が満たされない状況になった場合に，経路の再探索を行うことができる。この結果，時刻依存条件を満たす実用的な経路案内を実現することができる。  
【００８０】
Ｈ．変形例：
　実施例では，ユーザの移動速度が経路探索時の想定よりも遅い場合を例にとって，リルート要否の判断方法およびリルート処理の例について説明した。経路探索時の想定と異なる状況が生じる原因としては，ユーザの移動速度に限らず，出発時刻が遅れた場合，移動中に寄り道をした場合，交通機関が遅れた場合，事故などによって移動に支障が生じた場合など種々の原因が挙げられる。ユーザの心拍数や呼吸数などを検出し，これに基づいて移動速度の変化を予測して，経路探索時の想定と異なる状況が生じるか否かを予測するようにしてもよい。
【００８１】
　実施例の経路案内システムは，リルートに際し，種々の外部情報を利用してもよい。例えば，渋滞情報，天候の変化，事件・事故情報，商店のタイムサービス情報などを，ネットワーク上の他のサーバから取得し，これをリルートに活用してもよい。」
・段落【００２２】，【００３２】の記載事項からみて，経路案内システムが「通路をノード，リンクで表したネットワークデータを有している地図ＤＢ２５０と，交通機関の出発時刻を含む規制条件を記録する時刻表ＤＢ２５２」を有することは明らかである。
・段落【００２５】には，経路案内部２４０が経路案内データを生成し端末１００に送信することが記載されている。
・段落【００４４】〜【００４６】の記載事項からみて，経路案内システムが「探索された経路上にチェックポイントを設定する手段」を有することは明らかである。
・段落【００４４】，【００４７】の記載事項からみて，経路案内システムのサーバ２００は，端末１００から現在位置を入力し，チェックポイントにいるか否かを判断し，ユーザがチェックポイントに到達している場合には，時刻依存条件を満たすか否かの判定を行うものである。そして，時刻依存条件をクリアしないと判断される場合には，再度，経路探索処理を実行するものである。
　そうすると，特許請求の範囲の請求項１を引用する請求項２の発明と，該発明を引用する請求項６に記載された発明に着目しつつ，これらの記載事項及び図示内容を総合すると，引用例には，以下の発明（以下，「引用発明」という。）が記載されていると認められる。
「ユーザからの指定に従って経路を探索し，案内する経路案内システムであって，
　通路をノード，リンクで表したネットワークデータを有している地図ＤＢ２５０と，
　交通機関の出発時刻を含む規制条件を記録する時刻表ＤＢ２５２と
　出発地，目的地の指定を入力する地点入力部と，
　経路探索を行う際の条件として，経路を通行する時刻に応じて経路探索結果に影響を与え得る時刻依存性のある時刻依存条件，および経路探索を行う際の基準時刻，ユーザの想定移動速度を含む探索条件を特定する探索条件特定部と，
　前記探索条件に従って，前記ネットワークデータに基づき前記出発地から目的地までの経路探索を行う経路探索部２３０と，
　探索された経路上にチェックポイントを設定する手段と，
　端末１００の現在位置を検出するＧＰＳ１４０と，  
　ユーザの現在位置を入力し，該現在位置に応じて前記探索された経路の経路案内データを生成し端末１００に送信する経路案内部２４０と，端末１００のディスプレイに経路案内データに基づいて地図を表示させる表示制御部１５０とを有し，
　端末１００から現在位置を入力し，チェックポイントにいるか否かを判断し，ユーザがチェックポイントに到達している場合には，時刻依存条件を満たすか否かの判定を行い，
　該経路案内部２４０は，前記経路案内中の所定のタイミングにおけるユーザの現在位置および現在時刻に基づいて，前記経路探索によって得られた経路が前記時刻依存条件を満たさない状態にあると判断される時には，前記現在位置を前記出発地とし，前記現在時刻を前記基準時刻として前記経路探索部に前記経路探索を再試行させる再探索制御部を備える経路案内システムであって，
　前記時刻依存条件は，前記目的地または前記目的地に至るまでの所定の地点への到着希望時刻であり，
　前記再探索制御部は，ユーザが，案内すべき経路上に予め設定されたチェックポイントに至った時点で稼働する経路案内システム。」
３．発明の対比　
　本願発明と引用発明とを対比すると，後者の「通路をノード，リンクで表したネットワークデータ」は前者の「交通網を規定するネットワーク情報」に相当し，以下同様に，「ネットワークデータを有している地図ＤＢ２５０」は「ネットワーク情報を記憶するネットワーク情報記憶手段」に，「出発時刻」は「運行情報」に，「時刻表ＤＢ２５２」は「交通情報記憶手段」に，「経路探索を行う際の条件」及び「探索条件」は「経路探索条件」に，「ユーザの現在位置」は「端末装置の利用者の現在位置情報」に，「経路案内データ」は「経路案内情報」に，「端末１００」は「端末装置」に，「ディスプレイ」は「出力部」に，「表示制御部１５０」は「経路案内情報出力手段」に，「経路探索部２３０」と「経路案内部２４０」を合わせたものは「案内経路探索手段」に，それぞれ相当する。
　後者の「交通機関の出発時刻を含む規制条件を記録する時刻表ＤＢ２５２」は前者の「交通機関の運行情報を含む交通情報を記録する交通情報記憶手段」に相当する。
　後者の「時刻依存条件」は，「前記目的地または前記目的地に至るまでの所定の地点への到着希望時刻であ」り，後者の「経路探索を行う際の基準時刻」としては段落【０００８】に記載されるように「現在時刻や出発予定時刻」は当然含まれているから，後者の「出発地，目的地の指定を入力する地点入力部と，経路探索を行う際の条件として，経路を通行する時刻に応じて経路探索結果に影響を与え得る時刻依存性のある時刻依存条件，および経路探索を行う際の基準時刻，ユーザの想定移動速度を含む探索条件を特定する探索条件特定部と，前記探索条件に従って，前記ネットワークデータに基づき前記出発地から目的地までの経路探索を行う経路探索部２３０」及び「ユーザの現在位置を入力し，該現在位置に応じて前記探索された経路の経路案内データを生成し端末１００に送信する経路案内部２４０と，端末１００のディスプレイに経路案内データに基づいて地図を表示させる表示制御部１５０」は，前者の「少なくとも出発地と目的地と出発時刻または到着時刻とを含む経路探索条件を満たす上記出発地から上記目的地までの案内経路を，少なくとも上記ネットワーク情報記憶手段に記憶された上記ネットワーク情報を用いて探索し，当該案内経路に関する経路情報を生成する案内経路探索手段」及び「上記経路情報を少なくとも含む経路案内情報を上記端末装置の出力部を介して出力させることにより，経路案内を実行する経路案内情報出力手段」に相当する。
　後者において，再探索制御部は，ユーザが，案内すべき経路上に予め設定されたチェックポイントに至った時点で稼働するものであるから，後者の「チェックポイント」は前者の「リルート地点」に相当し，後者の「探索された経路上にチェックポイントを設定する手段」は前者の「上記案内経路上に，経路探索を要求するリルート地点を設定するリルート地点設定手段」に相当する。
　後者の「端末１００の現在位置を検出するＧＰＳ１４０」は前者の「端末装置の利用者の現在位置情報を取得する現在位置情報取得手段」に相当し，後者の「端末１００から現在位置を入力し，チェックポイントにいるか否かを判断し，ユーザがチェックポイントに到達している場合には，時刻依存条件を満たすか否かの判定を行」う手段と，前者の「上記現在位置情報取得手段により取得された上記現在位置情報に基づく上記端末装置の上記利用者の現在位置と，上記リルート地点設定手段により設定された上記リルート地点と，が一致すると判定された場合，現在時刻を取得する時刻取得手段と，上記時刻取得手段により取得された上記現在時刻が，上記有効時刻設定手段により設定された上記有効時刻を経過しているか否か判定する時刻判定手段」とは，「上記現在位置情報取得手段により取得された上記現在位置情報に基づく上記端末装置の上記利用者の現在位置と，上記リルート地点設定手段により設定された上記リルート地点と，が一致すると判定された場合，時刻に関する判定を行う手段」において一致する。
　後者において，再探索を行う現在位置は「リルート地点」であって，再探索を行うことは，「当該リルート地点から上記目的地までの上記案内経路を，上記交通情報記憶手段に記憶された上記交通情報に基づいて，上記ネットワーク情報記憶手段に記憶された上記ネットワーク情報を用いて探索し，当該案内経路に関する上記経路情報を生成するリルート経路探索手段」を有することになるから，後者の「該経路案内部２４０は，前記経路案内中の所定のタイミングにおけるユーザの現在位置および現在時刻に基づいて，前記経路探索によって得られた経路が前記時刻依存条件を満たさない状態にあると判断される時には，前記現在位置を前記出発地とし，前記現在時刻を前記基準時刻として前記経路探索部に前記経路探索を再試行させる再探索制御部」と，前者の「現在時刻を取得する時刻取得手段と，上記時刻取得手段により取得された上記現在時刻が，上記有効時刻設定手段により設定された上記有効時刻を経過しているか否か判定する時刻判定手段と，上記時刻判定手段により上記現在時刻が上記有効時刻を経過していると判定された場合，当該リルート地点から上記目的地までの上記案内経路を，上記交通情報記憶手段に記憶された上記交通情報に基づいて，上記ネットワーク情報記憶手段に記憶された上記ネットワーク情報を用いて探索し，当該案内経路に関する上記経路情報を生成するリルート経路探索手段」とは，「現在時刻を取得する時刻取得手段と，前記時刻に関する判定を行う手段と，前記時刻に関する判定を行う手段が条件を満たさない場合，当該リルート地点から上記目的地までの上記案内経路を，上記交通情報記憶手段に記憶された上記交通情報に基づいて，上記ネットワーク情報記憶手段に記憶された上記ネットワーク情報を用いて探索し，当該案内経路に関する上記経路情報を生成するリルート経路探索手段」の点で一致する。
　そして，後者の「ユーザからの指定に従って経路を探索し，案内する経路案内システム」は前者の「ナビゲーションシステム」に相当する。
　そうすると，両者は，
「交通網を規定するネットワーク情報を記憶するネットワーク情報記憶手段と，
　交通機関の運行情報を含む交通情報を記録する交通情報記憶手段と，
　少なくとも出発地と目的地と出発時刻または到着時刻とを含む経路探索条件を満たす上記出発地から上記目的地までの案内経路を，少なくとも上記ネットワーク情報記憶手段に記憶された上記ネットワーク情報を用いて探索し，当該案内経路に関する経路情報を生成する案内経路探索手段と，
　上記案内経路上に，経路探索を要求するリルート地点を設定するリルート地点設定手段と，
　端末装置の利用者の現在位置情報を取得する現在位置情報取得手段と，
　上記経路情報を少なくとも含む経路案内情報を上記端末装置の出力部を介して出力させることにより，経路案内を実行する経路案内情報出力手段と，
　上記現在位置情報取得手段により取得された上記現在位置情報に基づく上記端末装置の上記利用者の現在位置と，上記リルート地点設定手段により設定された上記リルート地点と，が一致すると判定された場合，現在時刻を取得する時刻取得手段と，時刻に関する判定を行う手段と，前記時刻に関する判定を行う手段が条件を満たさない場合，当該リルート地点から上記目的地までの上記案内経路を，上記交通情報記憶手段に記憶された上記交通情報に基づいて，上記ネットワーク情報記憶手段に記憶された上記ネットワーク情報を用いて探索し，当該案内経路に関する上記経路情報を生成するリルート経路探索手段と，
　を備えた，ナビゲーションシステム。」
の点で一致し，以下の点で相違する。
＜相違点＞
　本願発明では，「上記リルート地点設定手段により設定された上記リルート地点において上記案内経路が有効に利用できる期限である有効時刻を設定する有効時刻設定手段」を備えると共に，時刻に関する何らかの判定を行う手段が，「上記時刻取得手段により取得された上記現在時刻が，上記有効時刻設定手段により設定された上記有効時刻を経過しているか否か判定する時刻判定手段」であって，前記時刻に関する判定を行う手段が条件を満たさない場合が，「上記時刻判定手段により上記現在時刻が上記有効時刻を経過していると判定された場合」であるのに対して，引用発明では，そのような特定はなされていない点。
４．相違点についての判断
　引用発明では，時刻に関する判定を行うための「時刻依存条件」に関して，「時刻依存条件は，前記目的地または該目的地に至るまでの所定の地点への到着希望時刻である」とされており，明らかに「時間依存条件」を「目的地に至るまでの所定の地点への到着希望時刻」とすることを含んだものである。
　引用発明において，当該「目的地に至るまでの所定の地点」を，リルートを行う「チェックポイント」，つまり，本願発明における「リルート地点」とすること自体は，当業者にとって適宜採用し得ることである。
　そして，例えば，引用例における図９の場合に，段落【００４１】の記載のように「リルート地点」を交通機関の乗降場所であるＡ地点とすると，１０時（到着希望時間）までにＡ地点に到着できない場合には，当初に乗車予定であった１０時発のバスに乗れなくなるため，この当該到着希望時間（１０時）は，本願発明の「リルート地点において案内経路が有効に利用できる期限である有効時刻」に相当するものと解せる。
　さらに，この場合には，前記時刻に関する判定を行う手段は，「リルート地点に到着した時刻（現在時刻）が有効時刻設定手段により設定された有効時刻を経過しているか否か判定する」ことになり，かつ，前記時刻に関する判定を行う手段により条件（時間依存条件）を満たさないと判定された場合は，「上記時刻判定手段により上記現在時刻が上記有効時刻を経過していると判定された場合」に相当するものと解せる。
　そうしてみると，上記相違点に係る本願発明の発明特定事項は，引用発明において，当業者が容易に採用し得た域を出るものではない。
　そして，本願発明の効果も，引用発明からみて格別なものとはいえない。
５．むすび
　以上のとおりであるから，本願発明は，引用発明に基づいて，当業者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許を受けることができない。
　そうすると，本願は，他の請求項に係る発明について検討するまでもなく，拒絶されるべきものである。
　よって，結論のとおり審決する。