2021-013715

第１ 手続の経緯

本願は，令和２年９月８日の出願であって，その手続の経緯は，概略，以下のとおりである。

第２ 令和４年８月１６日にされた手続補正（以下，「本件補正」という。）についての補正の却下の決定

［補正の却下の決定の結論］

令和４年８月１６日にされた手続補正を却下する。

［補正の却下の決定の理由］

１ 本件補正について

（１）本件補正後の特許請求の範囲

本件補正により，特許請求の範囲の請求項１の記載は，次のとおり補正された（下線部は，補正箇所である。）。

「出発駅及び到着駅を示す旅程情報の入力を受け付ける入力受付部と，

位置と混雑度とが関連付けられた混雑情報を受信する混雑情報受信部と，

前記出発駅から前記到着駅までの経路と鉄道の利用時刻とに関連付けて前記混雑情報に基づく混雑度を示す第１画面と，地図に関連付けて前記混雑情報に基づく混雑度を示す第２画面とを切り替え可能に表示部に表示させる表示制御部と，

を備え，

前記入力受付部は，前記第１画面と前記第２画面とを切り替えるための切替操作を更に受け付け，

前記表示制御部は，前記第１画面を表示中に前記第２画面への切替操作を前記入力受付部が受け付けた場合に，前記第１画面に表示されている前記出発駅から前記到着駅までの経路が全て含まれる範囲の地図の混雑度を示す第２画面を表示し，

前記第１画面において示される前記混雑度と前記第２画面において示される前記混雑度とは，複数のエリア内の携帯端末の数に基づいて特定される共通の前記混雑情報を用いて表示される，情報端末。」

（２）本件補正前の特許請求の範囲

本件補正前の，令和３年５月２６日の手続補正による特許請求の範囲の請求項１の記載は次のとおりである。

「出発駅及び到着駅を示す旅程情報の入力を受け付ける入力受付部と，

位置と混雑度とが関連付けられた混雑情報を受信する混雑情報受信部と，

前記出発駅から前記到着駅までの経路に関連付けて前記混雑情報に基づく混雑度を示す第１画面と，地図に関連付けて前記混雑情報に基づく混雑度を示す第２画面とを切り替え

可能に表示部に表示させる表示制御部と，

を備え，

前記第１画面において示される前記混雑度と前記第２画面において示される前記混雑度とは，複数のエリア内の携帯端末の数に基づいて特定される共通の前記混雑情報を用いて表示される，情報端末。」

（３）補正の目的

上記補正は，補正前の請求項１に記載された発明を特定するために必要な事項である「第１画面」に示す「混雑情報に基づく混雑度」について，「鉄道の利用時刻」と関連付けて示すとの限定を付加し，「入力受付部」について，「前記入力受付部は，前記第１画面と前記第２画面とを切り替えるための切替操作を更に受け付け」るとの限定を付加し，「表示制御部」について「前記表示制御部は，前記第１画面を表示中に前記第２画面への切替操作を前記入力受付部が受け付けた場合に，前記第１画面に表示されている前記出発駅から前記到着駅までの経路が全て含まれる範囲の地図の混雑度を示す第２画面を表示」するとの限定を付加するものであって，補正前の請求項１に記載された発明と補正後の請求項１に記載される発明の産業上の利用分野及び解決しようとする課題が同一であるから，特許法１７条の２第５項２号の特許請求の範囲の減縮を目的とするものに該当する。

２ 補正の適否

本件補正後の請求項１に記載される発明（以下「本件補正発明」という。）が特許法１７条の２第６項において準用する同法第１２６条第７項の規定に適合するか（特許出願の際独立して特許を受けることができるものであるか）について，以下，検討する。

（１）本件補正発明

本件補正発明は，上記１（１）に記載したとおりのものである。

（２）引用文献

ア 引用文献１

引用文献１には，図面とともに次の事項が記載されている（下線は，当審が付加した。以下同様。）。

（ア）「【技術分野】

【０００１】

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

【背景技術】

続きを表示（全17行）

【０００２】

従来，パソコンやスマートフォン等の電子機器のユーザが設定した探索条件に基づいて経路探索を行い，その結果を電子機器に表示する経路探索システムが広く利用されている。この経路探索システムには，交通機関の混雑状況を考慮して経路探索を行うものがある。

【０００３】

従来の経路探索システムの一つとして，交通機関の混雑状況に応じて乗換時間を含んだ交通経路を探索する交通経路案内システムが知られている（特許文献１）。

【先行技術文献】

【特許文献】

【０００４】

【特許文献１】 特開２００７－１８３８８０号公報

【発明の概要】

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

【０００５】

しかしながら，従来の経路探索システムは，混雑する駅を利用する経路を提供することがあり，ユーザに対して適切な経路を提供できない場合があった。

本発明は，混雑する駅の利用を回避する代替経路をユーザに提供することができる情報処理システム，情報処理プログラム，情報処理装置，および情報処理方法を提供する。」

（イ）図１

［図：0001393636000001.jpg］

（ウ）「【００１０】

（第１の実施形態）

本発明の第１の実施形態に係る情報処理システム１について説明する。本実施形態に係る情報処理システム１は，モバイル端末（スマートフォン，携帯電話，タブレット端末等）やパソコン等の電子機器の使用者（以下，単に「ユーザ」ともいう）に対して経路を提供するシステムである。

【００１１】

続きを表示（全91行）

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

【００１２】

端末装置２は，経路を探索するためにユーザが使用するものであり，例えば，スマートフォンやタブレット端末等のモバイル端末である。なお，端末装置２は，デスクトップ型のパソコンであってもよい。

【００１３】

端末装置２は，図１に示すように，通信部２１と，制御部２２と，入力部２３と，出力部２４とを有する。まず，端末装置２の構成要素のうち，制御部２２以外の構成要素，即ち，通信部２１，入力部２３および出力部２４について説明する。

【００１４】

通信部２１は，ネットワークを介して制御部２２とサーバ３との間で情報を送受信するためのインターフェースである。

【００１５】

入力部２３は，ユーザが端末装置２に情報を入力するためのインターフェースであり，例えばモバイル端末におけるタッチパネルやマイクロフォン，デスクトップ型のパソコンにおけるキーボード，タッチパッドもしくはダイヤルボタンであってもよい。

【００１６】

出力部２４は，端末装置２からユーザに対して各種情報を出力するインターフェースであり，例えば液晶ディスプレイ等の映像表示手段である。具体的には，出力部２４は，ユーザからの操作を受け付けるためのＧＵＩ（Graphical User Interface）や，後述する移動経路情報などを表示する。あるいは，出力部２４は移動経路情報などを音声で出力するスピーカであってもよい。

【００１７】

なお，出力部２４は，ユーザに情報を直接提示するものでなくてもよい。例えば，出力部２４は，端末装置２の外部に接続される映像表示手段や音声出力手段に，映像信号や音声信号を出力するものであってもよいし，外部に接続される印刷装置にデータを出力するものであってもよいし，端末装置２内もしくは外部の記憶装置にデータを出力して記憶させるものであってもよい。

【００１８】

次に，端末装置２の制御部２２について説明する。制御部２２は，図１に示すように，探索条件取得部２２１と，情報提示部２２２とを有する。これら各部は，端末装置２内のプロセッサが所定のプログラムを実行することによって実現されてもよい。

【００１９】

探索条件取得部２２１は，経路探索用の探索条件を取得する。探索条件は，出発地および目的地のうち少なくともいずれか一方を含む。出発地や目的地は，鉄道駅に限られず，例えば，バスの停留所，水上バスの乗降船場，空港，港，自宅，会社，あるいは，ＧＰＳやＷｉｆｉ測位等の測位手段によって検出された現在位置などであってもよい。

【００２０】

探索条件は，出発地や目的地の他，経由地（鉄道の場合は乗換駅や通過駅等），使用路線，出発時刻，到着時刻等を含んでもよい。

【００２１】

探索条件取得部２２１は，入力部２３を介して探索条件を取得する他，入力部２３を介さずに探索条件の少なくとも一部を取得してもよい。例えば，出発地として，端末装置２が有する測位手段（図示せず）から現在位置を取得してもよいし，出発時刻として，端末装置２が有する計時手段（図示せず）もしくは外部のサーバから現在時刻を取得してもよいし，目的地や到着時刻等の情報をスケジューラアプリから取得してもよい。

【００２２】

情報提示部２２２は，移動経路等に関する各種情報を，出力部２４を介してユーザに提示する。

【００２３】

なお，出力部２４が映像表示手段である場合，情報提示部２２２は，提示すべき情報を映像信号に変換して出力部２４に出力し，出力部２４が音声出力手段である場合には，情報提示部２２２は，提示すべき情報を音声信号に変換して出力部２４に出力する。

【００２４】

次に，サーバ３について説明する。図１に示すように，サーバ３は，通信部３１と，制御部３２と，記憶部３３とを有する。制御部３２について説明する前に，通信部３１および記憶部３３について説明する。

【００２５】

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

【００２６】

記憶部３３は，例えばハードディスク等の固定型データストレージであり，後述の各種データベースを格納する。なお，記憶部３３は，必ずしもサーバ３内に設けられなくてもよく，ネットワークを介してサーバ３と通信可能に接続された別の装置内に設けられてもよい。

【００２７】

記憶部３３は，経路ネットワークデータベース３３１と，混雑情報データベース３３２とを有する。

【００２８】

経路ネットワークデータベース３３１は，経路探索用のデータベースであり，経路ネットワーク情報として，例えば地図情報，および交通ネットワーク情報を含む。地図情報は，全国または各地方の道路地図などの地図データを含み，地図データに対応付けられた地図オブジェクト情報（施設情報，注記情報，記号情報等）を含んでよい。交通ネットワーク情報は，鉄道やバスや船舶（例えば水上バスやフェリー）等の交通網や道路網を規定する情報である。交通網の種類としては，交通機関の路線情報，時刻表情報，料金情報等を含む。道路網の情報は，例えば交差点等の道路網表現上の結節点（ノード）のデータと，結節点間の道路区間であるリンクのデータとの組み合わせによって表現される。

【００２９】

混雑情報データベース３３２は，駅の混雑状況を示す混雑情報のデータベースである。ここで，駅とは，移動手段（交通機関）が乗客を乗り降りさせるために停留する場所を意味し，例えば，移動手段が鉄道の場合には鉄道駅，移動手段がバスの場合には停留所，移動手段が船舶の場合には港（乗降船場），移動手段が飛行機の場合には空港，移動手段がタクシーの場合はタクシー乗り場である。

【００３０】

混雑情報は，駅の混雑状況を示すものであり，後述する混雑情報取得部３２２が選択的に取得し得るものであれば，その具体的な態様は特に限定されない。例えば混雑情報は，駅の現在の混雑状況を示すリアルタイム情報および駅の将来の混雑状況を示す予測情報の少なくとも一方であってもよい。例えば，リアルタイム情報および予測情報の両方を用いることで，ユーザが駅に到着した時点での混雑状況をより正確に判断することができる。

【００３１】

具体的には，リアルタイム情報は，例えば鉄道駅における駅や電車の混み具合のレベルをユーザからの投稿を元に示す電車混雑リポート情報であってもよい。また，駅またはその周辺において使用中の端末装置２から取得される該端末装置２の位置等を示す端末プローブ情報の数，駅の公式発表データ等であってもよい。また，予測情報は，上記各リアルタイム情報，駅の周囲のイベント情報，駅を検索した地点検索ログ，駅を出発地とした経路検索ログ等から推定する任意時点での駅の混雑状況に関する情報であってもよい。

【００３２】

なお，イベント情報は，イベントの開催場所（地図上の座標），開催時間（例えば，開始時刻，終了時刻），規模（例えば，参加人数や会場面積），混雑するイベントか否かを示すフラグなどを含む情報であってもよい。

【００３３】

混雑情報には，駅の混雑状況だけでなく，駅の周辺の領域の混雑状況を示す情報が含まれていてもよい。

【００３４】

混雑情報の少なくとも一部（例えば，駅の公式発表データ等）は，混雑情報データベース３３２ではなく，外部サーバのデータベースが管理するものであってもよい。

【００３５】

次に，サーバ３の制御部３２について説明する。制御部３２は，図１に示すように，利用駅候補抽出部３２１と，混雑情報取得部３２２と，代替経路取得部３２３とを有する。これら各部は，サーバ３内のプロセッサが所定のプログラムを実行することにより実現されてもよい。

【００３６】

利用駅候補抽出部３２１は，探索条件や現在位置等に基づいて，ユーザが利用する可能性のある駅（以下，単に「利用駅候補」ともいう）を抽出する。

【００３７】

利用駅候補は，例えば，現在位置の最寄駅や，現在位置もしくは最寄駅を中心とした所定距離の半径の円形領域内に存在する駅，ユーザが端末装置２を用いて指定した駅等であってもよい。利用駅候補は，探索条件に含まれる出発地や経由地等であってもよい。利用駅候補が探索条件に含まれる場合，利用駅候補抽出部３２１は，探索条件に基づいて利用駅候補を抽出してもよい。

【００３８】

利用駅候補の個数は限定されず，単数および複数のいずれであってもよい。例えば利用駅候補は，出発駅および乗換駅の双方を含んでもよく，また，乗換駅の個数は，単数および複数のいずれであってもよい。

【００３９】

混雑情報取得部３２２は，利用駅候補抽出部３２１が抽出した利用駅候補の混雑情報を取得する。

【００４０】

混雑情報取得部３２２は，混雑情報データベース３３２内の各駅の混雑情報のうち，例えば利用駅候補と同一の座標に対応付けられた混雑情報や，利用駅候補と同一の識別情報や経路ネットワーク情報に対応付けられた駅の混雑情報を，利用駅候補の混雑情報として取得してもよい。利用駅候補の混雑情報は，リアルタイム情報および予測情報のいずれであってもよい。また，混雑情報取得部３２２は，探索条件等に基づいて利用駅候補の利用時刻を考慮し，利用時刻に適合した時刻に対応する混雑情報を混雑情報データベース３３２から取得してもよい。

【００４１】

また，混雑情報取得部３２２は，現在位置（出発地）から利用駅候補までの混雑情報を取得してもよい。

【００４２】

代替経路取得部３２３は，利用駅候補が混雑する場合は，代替経路を取得する。一方，代替経路取得部３２３は，利用駅候補が混雑しない場合は，代替経路を取得しなくてもよい。

【００４３】

ここで，代替経路とは，代替利用駅を利用する経路を示す移動経路情報である。代替利用駅とは，混雑する利用駅候補（以下，「混雑駅」ともいう）に代替可能な駅である。

【００４４】

例えば，本実施形態において，代替利用駅は，現在位置の周辺の駅であって混雑駅の移動手段である第１移動手段とは異なる第２移動手段の駅であり，代替経路は，当該第２移動手段の駅を利用する経路である。現在位置の周辺とは，現在位置の周囲の所定の領域内の位置であれば特に限定されず，例えば，現在位置を中心とした所定距離の半径（例えば，半径５００ｍ等）を有する円形領域内の位置や，現在位置から徒歩で所定時間内に到達できる領域内の位置等であってもよい。

【００４５】

なお，代替利用駅は，出発地の周辺の第２移動手段の駅であってもよい。出発地の具体的な態様は特に限定されず，例えば出発駅等であってもよい。出発地の周辺は，現在位置の周辺と同様に，出発地の周囲の所定の領域内の位置であってもよい。

【００４６】

また，代替利用駅は，混雑駅の周辺の第２移動手段の駅であってもよい。混雑駅の周辺は，現在位置の周辺と同様に，混雑駅の周囲の所定の領域内の位置であってもよい。

【００４７】

なお，混雑情報がそれ自体で混雑の発生を示す情報である場合（すなわち，混雑が発生していないと取得されない情報である場合）がある。この場合には，代替経路取得部３２３は，混雑情報取得部３２２による混雑情報の取得を契機として，混雑の有無を判定せず直ちに代替経路を取得してもよい。一方，混雑情報が，混雑の有無を示す情報や混雑の有無の判定に利用可能な情報である場合がある。この場合には，代替経路取得部３２３は，混雑情報に基づいて利用駅候補の混雑の有無を判定したうえで，混雑が発生していると判断した場合に，代替経路を取得してよい。

【００４８】

代替経路取得部３２３は，代替経路だけでなく，利用駅候補を利用する移動経路（通常のコスト計算に基づいた移動経路）を取得してもよい。利用駅候補を利用する移動経路は，混雑の有無を問わなくてよい。

【００４９】

サーバ３の通信部３１は，代替経路取得部３２３が取得した代替経路を端末装置２に送信する。これにより，端末装置２の情報提示部２２２は，代替経路を出力することができる。

【００５０】

ここで，もし，駅の混雑状況を駅における所要時間のコストに反映させて経路探索を行う場合，混雑する駅のコストが上昇したために，別の駅を利用する経路が探索される可能性はある。しかるに，そのようなコスト計算による経路探索では，混雑する駅の利用を回避する経路を高い確度で取得できるとは限らない。なぜならば，コスト計算においては，所要時間以外にも，運賃，乗換回数など種々の要素が考慮され得るからである。

【００５１】

これに対して，代替経路取得部３２３によれば，代替利用駅が存在する場合には，この代替利用駅を利用する代替経路を確実に取得してユーザに提供できる。具体的には，第１移動手段の混雑駅の利用を回避する第２移動手段の代替経路を提供することができる。より具体的には，混雑情報がリアルタイム情報である場合には，ユーザの現在位置の近くの混雑駅の利用回避に有効な代替経路を提供することができる。また，混雑情報が予測情報である場合には，ユーザの現在位置から遠距離の混雑駅または将来的な混雑駅の利用回避にも有効な代替経路を提供することができる。なお，混雑情報としての予測情報に基づいて当初の経路探索時は混雑駅でないと判断された利用駅候補が，不意に発生した交通機関の遅延等によって，実際に利用駅候補に赴いたタイミングで混雑駅になっている場合がある。しかるに，この場合には，再探索によって混雑駅の周辺の第２移動手段の駅を代替利用駅とした代替経路を探すことで，不意に発生した混雑に速やかに対応することができる。

【００５２】

また，サーバ３の通信部３１は，端末装置２の情報提示部２２２において混雑駅を利用する移動経路の情報（以下，「混雑経路」ともいう）と代替経路とを識別可能および／または比較可能に出力し得るように，代替経路とともに混雑経路を送信してよい。これにより，情報提示部２２２は，混雑経路と代替経路とを識別可能および／または比較可能に出力できる。このようにして出力された混雑経路および代替経路によれば，ユーザは，代替経路の利用の是非を容易に判断し得る。

【００５３】

なお，代替経路取得部３２３は，代替経路，および利用駅候補を利用する移動経路（混雑経路となるものを含む）を，例えば，経路探索の結果や予め探索済みの経路（例えば，履歴や予め登録済みの経路であるMyルート等）に基づいて取得してよい。代替経路，および利用駅候補を利用する移動経路を経路探索の結果によって取得する場合，当該経路探索は，代替経路取得部３２３およびその他の経路探索手段（例えば外部サーバ等）のいずれが行ってもよい。代替経路を探索する場合，その過程で代替利用駅を抽出することになるが，代替利用駅の抽出は，現在地の最寄の利用駅候補の抽出と同様のロジックで行ってもよい。一方，代替経路，および利用駅候補を利用する移動経路を予め探索済みの経路に基づいて取得する場合，予め探索済みの経路は，サーバ３の記憶部３３およびその他の記憶手段（例えば外部サーバの記憶部等）のいずれに記憶されていてもよい。

【００５４】

また，利用駅候補を利用する移動経路が予め探索済みの経路に基づいて取得された場合，利用駅候補抽出部３２１は，当該移動経路中の出発駅を抽出し，混雑情報取得部３２２は，該出発駅の混雑情報を取得してもよい。そして，代替経路取得部３２３は，該混雑情報が混雑を示すもの否かを判定し，該混雑情報が混雑を示すものであると判定されると，代替経路を探索してもよい。」

（エ）図２

［図：0001393636000002.jpg］

（オ）「【００５５】

次に，図２および図３を参照して，上記の構成を有する情報処理システム１の処理動作の一例について説明する。

【００５６】

まず，図２に示すように，端末装置２の探索条件取得部２２１が，経路探索用の探索条件を取得する（ステップＳ２１）。そして，端末装置２の通信部２１が当該探索条件をサーバ３に送信し（ステップＳ２２），サーバ３の通信部３１が当該探索条件を受信する（ステップＳ３１）。

【００５７】

次に，サーバ３の利用駅候補抽出部３２１が，ステップＳ３１において受信された探索条件に基づいて，利用駅候補を抽出する（ステップＳ３２）。そして，サーバ３の代替経路取得部３２３が，ステップＳ３２において抽出された利用駅候補（第１移動手段）を利用する経路を探索する（ステップＳ３３）。なお，利用駅候補を利用する経路は，該利用駅候補が混雑駅である場合には，混雑経路となる。次に，サーバ３の混雑情報取得部３２２が，利用駅候補の混雑情報を取得する（ステップＳ３４）。」

（カ）図３

［図：0001393636000003.jpg］

（キ）「【００５８】

次に，図３に示すように，サーバ３の代替経路取得部３２３が，ステップＳ３４において取得された混雑情報に基づいて，利用駅候補が混雑しているか否かを判定する（ステップＳ３５）。

【００５９】

例えば，混雑情報が電車混雑リポート情報である場合，電車混雑リポート情報が示す利用駅候補でのレベルが，「乗れない」に相当するレベルであれば，混雑有りと判定し，該レベルよりも低いレベルであれば，混雑無しと判定してもよい。また，混雑情報が駅またはその周辺の端末プローブ情報の数である場合，この数が閾値を超えるのであれば，混雑有りと判定し，閾値以下であれば，混雑無しと判定してもよい。また，混雑情報がイベント情報である場合，利用駅候補の周囲で大きなイベントが開催されているのであれば，混雑有りと判定し，開催されていないのであれば，混雑無しと判定してもよい。また，混雑情報が地点／経路検索ログである場合，検索数が閾値を超えるのであれば，混雑有りと判定し，閾値以下であれば，混雑無しと判定してもよい。

【００６０】

そして，利用駅候補が混雑している場合には（ステップＳ３５：Ｙｅｓ），代替経路取得部３２３が，第２移動手段の駅を利用する代替経路を探索して取得する（ステップＳ３６１）。一方，利用駅候補が混雑していない場合には（ステップＳ３５：Ｎｏ），代替経路取得部３２３は，代替経路を探索しない。

【００６１】

なお，ステップＳ３５の判定は，ステップＳ３２とステップＳ３３の間すなわち，経路探索前に行ってもよい。」

（ク）図４

［図：0001393636000004.jpg］

（ケ）「【００６２】

ここで，図４は，ステップＳ３６１の実行によって取得される経路の一例を模式的に示す経路図である。図４に示すように，本実施形態においては，利用駅候補としての現在位置の最寄駅が，第１移動手段の混雑駅である場合，混雑経路Ｒ１と，第２移動手段を利用する代替経路Ｒ２とを取得することができる。

【００６３】

具体的には，図４の混雑経路Ｒ１は，現在位置から目的地である第１移動手段の到着駅Ｇまで移動する経路である。より具体的には，混雑経路Ｒ１は，現在位置から第１移動手段の混雑駅Ｓまでの徒歩ルートＲ１１と，混雑駅Ｓから目的地Ｇまで第１移動手段を利用するルートＲ１２とによって構成されている。

【００６４】

また，図４の代替経路Ｒ２は，現在位置から目的地Ｇまでの第２移動手段を利用した経路である。より具体的には，代替経路Ｒ２は，現在位置周辺の代替利用駅Ｓ’までの徒歩ルートＲ２１と，代替利用駅Ｓ’から目的地Ｇに最寄りの第２移動手段の到着駅Ｇ’まで第２移動手段を利用するルートＲ２２と，当該到着駅Ｇ’から目的地Ｇまでの徒歩ルートＲ２３とによって構成されている。

【００６５】

次に，図３に示すように，サーバ３の通信部３１が，代替経路取得部３２３の経路探索結果を端末装置２に送信する（ステップＳ３７）。このとき，代替経路が取得されている場合（ステップＳ３６１を経た場合）には，通信部３１は，代替経路と混雑経路とを端末装置２に送信する。一方，代替経路が取得されていない場合（ステップＳ３６１を経ていない場合）には，通信部３１は，第１移動手段の最寄駅（混雑駅ではない）を利用する経路のみを端末装置２に送信する。

【００６６】

次に，端末装置２の通信部２１は，ステップＳ３７において送信された経路探索結果を受信する（ステップＳ２３）。そして，端末装置２の情報提示部２２２は，当該経路探索結果を，出力部２４を介してユーザに提示する。」

（コ）図５

［図：0001393636000005.jpg］

（サ）「【００６７】

ここで，図５は，ステップＳ２４において提示される端末装置２の表示画面（経路探索結果の表示画面）の第２の例である。図５の表示画面では，第１移動手段としての電車と，徒歩とを利用した混雑経路Ｒ１と，第２移動手段としての水上バスと，徒歩とを利用した代替経路Ｒ２とが，簡易一覧表示の態様で識別可能かつ比較可能に表示されている。

【００６８】

具体的には，図５の混雑経路Ｒ１は，「駅混３０分」等の混雑状況に応じた遅延時間が表示されているので，ユーザは，混雑経路Ｒ１を一目で識別することができる。なお，図５の混雑経路Ｒ１は，徒歩および電車のイラストが表示されているので，ユーザは，混雑経路Ｒ１が電車を利用する経路であることを一目で把握することができる。

【００６９】

一方，図５の代替経路Ｒ２は，「混雑回避」と表示されているので，ユーザは，代替経路Ｒ２を一目で識別することができる。なお，図５の代替経路Ｒ２は，徒歩および船のイラストが表示されているので，ユーザは，代替経路Ｒ２が水上バスを利用する経路であることを一目で把握することができる。

【００７０】

また，図５の混雑経路Ｒ１，代替経路Ｒ２は，出発地から目的地までの所要時間と，混雑状況に応じた遅延時間とが表示されているので，ユーザは，両経路の実質的な所要時間を容易に比較することができる。その他，ユーザは，運賃，乗換の有無なども比較することができる。」

（シ）引用発明

上記（ア）～（サ）より，特に，下線部に着目すると，引用文献１には，以下の発明（以下，「引用発明」という。）が記載されていると認められる。

「混雑する駅の利用を回避する代替経路をユーザに提供することができる情報処理システムであって，

端末装置２と，サーバ３とを備えており，端末装置２とサーバ３とは，インターネット等のネットワークを介して互いに通信可能に接続されている情報処理システム１において，

端末装置２は，経路を探索するためにユーザが使用するものであり，例えば，スマートフォンやタブレット端末等のモバイル端末であり，

端末装置２は，通信部２１と，制御部２２と，入力部２３と，出力部２４とを有しており，

続きを表示（全25行）

通信部２１は，ネットワークを介して制御部２２とサーバ３との間で情報を送受信するためのインターフェースであり，

入力部２３は，ユーザが端末装置２に情報を入力するためのインターフェースであり，

出力部２４は，端末装置２からユーザに対して各種情報を出力するインターフェースであり，例えば液晶ディスプレイ等の映像表示手段であり，

制御部２２は，探索条件取得部２２１と，情報提示部２２２とを有しており，これら各部は，端末装置２内のプロセッサが所定のプログラムを実行することによって実現されてもよく，

探索条件取得部２２１は，経路探索用の探索条件を取得しており，探索条件は，出発地および目的地を含んでおり，出発地や目的地は，鉄道駅に限られず，例えば，バスの停留所，水上バスの乗降船場，空港，港，自宅，会社，あるいは，ＧＰＳやＷｉｆｉ測位等の測位手段によって検出された現在位置などであってもよく，

情報提示部２２２は，移動経路等に関する各種情報を，出力部２４を介してユーザに提示しており，

サーバ３は，通信部３１と，制御部３２と，記憶部３３とを有しており，

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

記憶部３３は，経路ネットワークデータベース３３１と，混雑情報データベース３３２とを有しており，

経路ネットワークデータベース３３１は，経路探索用のデータベースであり，経路ネットワーク情報として，例えば地図情報，および交通ネットワーク情報を含んでおり，

混雑情報データベース３３２は，駅の混雑状況を示す混雑情報のデータベースであり，混雑情報は，駅の現在の混雑状況を示すリアルタイム情報および駅の将来の混雑状況を示す予測情報の少なくとも一方であってもよく，リアルタイム情報および予測情報の両方を用いることで，ユーザが駅に到着した時点での混雑状況をより正確に判断することができ，リアルタイム情報は，例えば鉄道駅における駅や電車の混み具合のレベルをユーザからの投稿を元に示す電車混雑リポート情報であってもよく，また，駅またはその周辺において使用中の端末装置２から取得される該端末装置２の位置等を示す端末プローブ情報の数，駅の公式発表データ等であってもよく，混雑情報には，駅の混雑状況だけでなく，駅の周辺の領域の混雑状況を示す情報が含まれていてもよく，

サーバ３の制御部３２は，利用駅候補抽出部３２１と，混雑情報取得部３２２と，代替経路取得部３２３とを有しており，

混雑情報取得部３２２は，利用駅候補抽出部３２１が抽出した利用駅候補の混雑情報を取得しており，混雑情報取得部３２２は，現在位置（出発地）から利用駅候補までの混雑情報を取得してもよい，

情報処理システム１の処理動作において，

端末装置２の探索条件取得部２２１が，経路探索用の探索条件を取得して，端末装置２の通信部２１が当該探索条件をサーバ３に送信し，

サーバ３の通信部３１が当該探索条件を受信し，サーバ３の利用駅候補抽出部３２１が，受信された探索条件に基づいて，利用駅候補を抽出し，

サーバ３の混雑情報取得部３２２が，利用駅候補の混雑情報を取得し，

サーバ３の通信部３１が，経路探索結果を端末装置２に送信し，

端末装置２の通信部２１は，経路探索結果を受信し，

端末装置２の情報提示部２２２は，当該経路探索結果を，出力部２４を介してユーザに提示しており，端末装置２の表示画面（経路探索結果の表示画面）の例では，第１移動手段としての電車と，徒歩とを利用した混雑経路Ｒ１と，第２移動手段としての水上バスと，徒歩とを利用した代替経路Ｒ２とが，簡易一覧表示の態様で識別可能かつ比較可能に表示されており，混雑経路Ｒ１は，「駅混３０分」等の混雑状況に応じた遅延時間が表示されているので，ユーザは，混雑経路Ｒ１を一目で識別することができる

情報処理システム。」

（３）対比

ア 対比

本件補正発明は，「情報端末」の発明であり，引用発明（情報処理システム）における「端末装置２」が，本件補正発明の「情報端末」に対応するから，以下では，引用発明（情報処理システム）における「端末装置２」と，本件補正発明とを対比する。

（ア）引用発明において，「端末装置２は，経路を探索するためにユーザが使用するものであり，例えば，スマートフォンやタブレット端末等のモバイル端末であり，端末装置２は，通信部２１と，制御部２２と，入力部２３と，出力部２４とを有しており，」「入力部２３は，ユーザが端末装置２に情報を入力するためのインターフェースであり，」「制御部２２は，探索条件取得部２２１と，情報提示部２２２とを有しており，」「探索条件取得部２２１は，経路探索用の探索条件を取得しており，探索条件は，出発地および目的地を含んでおり，出発地や目的地は，鉄道駅に限ら」ないとされている。

ここで，引用発明の「経路探索用の」「探索条件は，出発地および目的地を含んでおり，出発地や目的地は，鉄道駅に限ら」ないから，出発地や目的地として，すくなくとも鉄道駅が予定されているといえる。この場合，引用発明の「探索条件」の「出発地」としての「鉄道駅」は，本件補正発明の「出発駅」に相当し，引用発明の「探索条件」の「目的地」としての「鉄道駅」は，本件補正発明の「到着駅」に相当する。

そして，引用発明において，「探索条件」の「出発地」および「目的地」をいずれも「鉄道駅」とした「探索条件」は，本件補正発明の「出発駅及び到着駅を示す旅程情報」に相当する。

また，引用発明の「ユーザが端末装置２に情報を入力するためのインターフェースであ」る「入力部２３」は，本件補正発明の「情報の入力を受け付ける入力受付部」に相当するといえる。

したがって，本件補正発明と，引用発明とは，「出発駅及び到着駅を示す旅程情報の入力を受け付ける入力受付部」「を備え」る点で共通しているといえる。

（イ）引用発明において，「サーバ３」が「有して」いる「混雑情報データベース３３２は，駅の混雑状況を示す混雑情報のデータベースであり，混雑情報は，駅の現在の混雑状況を示すリアルタイム情報および駅の将来の混雑状況を示す予測情報の少なくとも一方であってもよ」いとされており，「端末装置２」の「通信部２１は，ネットワークを介して制御部２２とサーバ３との間で情報を送受信するためのインターフェースであり，」「端末装置２の通信部２１は，経路探索結果を受信し，端末装置２の情報提示部２２２は，当該経路探索結果を，出力部２４を介してユーザに提示しており，端末装置２の表示画面（経路探索結果の表示画面）の例では，第１移動手段としての電車と，徒歩とを利用した混雑経路Ｒ１と，第２移動手段としての水上バスと，徒歩とを利用した代替経路Ｒ２とが，簡易一覧表示の態様で識別可能かつ比較可能に表示されており，混雑経路Ｒ１は，「駅混３０分」等の混雑状況に応じた遅延時間が表示されている」とされている。

ここで，引用発明の「端末装置２」の「通信部２１」は，「サーバ３」から「経路探索結果を受信し」ており，「経路探索結果」には，「「駅混３０分」等の混雑状況に応じた遅延時間」のような「駅の」「混雑状況を示す」「混雑情報」が含まれているから，引用発明の「端末装置２」の「通信部２１」も，本件補正発明と同様に「混雑情報を受信」しているといえる。

したがって，本件補正発明の「位置と混雑度とが関連付けられた混雑情報を受信する混雑情報受信部」と，引用発明の「端末装置２」の「通信部２１」とは，「混雑情報を受信する混雑情報受信部」「を有し」ている点で共通するといえる。

しかし，本件補正発明の「混雑情報」は「位置と混雑度とが関連付けられた」ものであるのに対して，引用発明の「混雑情報」は，「「駅混３０分」等の混雑状況に応じた遅延時間」のような「駅の」「混雑状況を示す」ものである点で相違している。

（ウ）引用発明において，「端末装置２は，（中略）制御部２２と，（中略）出力部２４とを有しており，」「出力部２４は，端末装置２からユーザに対して各種情報を出力するインターフェースであり，例えば液晶ディスプレイ等の映像表示手段であり，」「制御部２２は，（中略）情報提示部２２２とを有しており，これら各部は，端末装置２内のプロセッサが所定のプログラムを実行することによって実現されてもよく，」「端末装置２の情報提示部２２２は，当該経路探索結果を，出力部２４を介してユーザに提示しており，端末装置２の表示画面（経路探索結果の表示画面）の例では，（中略）混雑経路Ｒ１と，（中略）代替経路Ｒ２とが，簡易一覧表示の態様で識別可能かつ比較可能に表示されており，混雑経路Ｒ１は，「駅混３０分」等の混雑状況に応じた遅延時間が表示されている」とされている。

ここで，引用発明において，「探索条件」の「出発地」および「目的地」をいずれも「鉄道駅」とした場合の「混雑経路Ｒ１」，「「駅混３０分」等の混雑状況に応じた遅延時間が表示され」た「表示画面（経路探索結果の表示画面）」，「液晶ディスプレイ等の映像表示手段であ」ある「出力部２４」は，それぞれ，本件補正発明の「前記出発駅から前記到着駅までの経路」，「混雑情報」「を示す第１画面」，「表示部」に対応する。

したがって，本件補正発明の「前記出発駅から前記到着駅までの経路に関連付けて前記混雑情報に基づく混雑度を示す第１画面と，地図に関連付けて前記混雑情報に基づく混雑度を示す第２画面とを切り替え可能に表示部に表示させる表示制御部」と，引用発明の「情報提示部２２２とを有し」た「制御部２２」とは，「前記出発駅から前記到着駅までの経路に関連付けて前記混雑情報」「を示す第１画面」「を」「表示部に表示させる表示制御部」である点で共通するといえる。

しかし，本件補正発明の「第１画面」には，混雑情報に基づく混雑度」が鉄道の利用時刻に関連付けて表示されているのに対して，引用発明の「第１画面」には，「「駅混３０分」等の混雑状況に応じた遅延時間」のような「駅の」「混雑状況を示す」ものが表示されており，鉄道の利用時刻に関連付けていない点で相違している。

また，本件補正発明の「表示制御部」は，「第１画面と，地図に関連付けて前記混雑情報に基づく混雑度を示す第２画面とを切り替え可能に」「表示」しているのに対して，引用発明の「表示制御部」は，「地図に関連付けて前記混雑情報に基づく混雑度を示す第２画面」を表示していない点で相違している。

さらに，本件補正発明では，「入力受付部」が，「前記第１画面と前記第２画面とを切り替えるための切替操作を更に受け付け」るものであり，「表示制御部は，前記第１画面を表示中に前記第２画面への切替操作を前記入力受付部が受け付けた場合に，前記第１画面に表示されている前記出発駅から前記到着駅までの経路が全て含まれる範囲の地図の混雑度を示す第２画面を表示し」ているのに対し，引用発明では，「入力受付部」が，「前記第１画面と前記第２画面とを切り替えるための切替操作を更に受け付け」ておらず，「表示制御部は，前記第１画面を表示中に前記第２画面への切替操作を前記入力受付部が受け付けた場合に，前記第１画面に表示されている前記出発駅から前記到着駅までの経路が全て含まれる範囲の地図の混雑度を示す第２画面を表示し」ていない点で相違している。

（エ）引用発明において，「混雑情報は，駅の現在の混雑状況を示すリアルタイム情報および駅の将来の混雑状況を示す予測情報の少なくとも一方であってもよく，リアルタイム情報および予測情報の両方を用いることで，ユーザが駅に到着した時点での混雑状況をより正確に判断することができ，リアルタイム情報は，例えば鉄道駅における駅や電車の混み具合のレベルをユーザからの投稿を元に示す電車混雑リポート情報であってもよく，また，駅またはその周辺において使用中の端末装置２から取得される該端末装置２の位置等を示す端末プローブ情報の数，駅の公式発表データ等であってもよ」いとされている。

ここで，引用発明における「混雑情報」（その内の「リアルタイム情報」）として，「駅またはその周辺において使用中の端末装置２から取得される該端末装置２の位置等を示す端末プローブ情報の数」が例示されているところ，引用発明の「駅またはその周辺において使用中の端末装置２から取得される該端末装置２の位置等を示す端末プローブ情報の数」は，本件補正発明の「複数のエリア内の携帯端末の数」に相当するから，引用発明の「駅またはその周辺において使用中の端末装置２から取得される該端末装置２の位置等を示す端末プローブ情報の数」に基づいて定められる「混雑情報」は，本件補正発明の「複数のエリア内の携帯端末の数に基づいて特定される」「混雑情報」であるといえる。

したがって，本件補正発明の「前記第１画面において示される前記混雑度と前記第２画面において示される前記混雑度とは，複数のエリア内の携帯端末の数に基づいて特定される共通の前記混雑情報を用いて表示される」と引用発明の「混雑情報」とは，「前記第１画面において示される前記混雑」情報「は，複数のエリア内の携帯端末の数に基づいて特定される」「前記混雑情報を用いて表示される」ものである点で共通するといえる。

しかし，本件補正発明では，「混雑情報を用いて表示」する際に，「第１画面」と「第２画面」とで，「共通の前記混雑情報を用いて表示」しているのに対して，引用発明では，「第２画面」を表示していない点で相違している。

イ 一致点および相違点

本件補正発明と，引用発明とは，以下（ア）の点で一致し，以下（イ）の点で相違する。

（ア）一致点

「出発駅及び到着駅を示す旅程情報の入力を受け付ける入力受付部と，

混雑情報を受信する混雑情報受信部と，

前記出発駅から前記到着駅までの経路に関連付けて前記混雑情報を示す第１画面を表示部に表示させる表示制御部と，

を備え，

前記第１画面において示される前記混雑情報は，複数のエリア内の携帯端末の数に基づいて特定される前記混雑情報を用いて表示される，

情報端末。」

（イ）相違点

ａ ＜相違点１＞

本件補正発明の「第１画面」には，混雑情報に基づく混雑度」が鉄道の利用時刻に関連付けて表示されているのに対して，引用発明の「第１画面」には，「「駅混３０分」等の混雑状況に応じた遅延時間」のような「駅の」「混雑状況を示す」ものが表示されており，鉄道の利用時刻に関連付けていない点。

ｂ ＜相違点２＞

本件補正発明の「表示制御部」は，「第１画面と，地図に関連付けて前記混雑情報に基づく混雑度を示す第２画面とを切り替え可能に」「表示」しているのに対して，引用発明の「表示制御部」は，「地図に関連付けて前記混雑情報に基づく混雑度を示す第２画面」を表示していない点。

ｃ ＜相違点３＞

本件補正発明では，「入力受付部」が，「前記第１画面と前記第２画面とを切り替えるための切替操作を更に受け付け」るものであり，「表示制御部は，前記第１画面を表示中に前記第２画面への切替操作を前記入力受付部が受け付けた場合に，前記第１画面に表示されている前記出発駅から前記到着駅までの経路が全て含まれる範囲の地図の混雑度を示す第２画面を表示し」ているのに対し，引用発明では，「入力受付部」が，「前記第１画面と前記第２画面とを切り替えるための切替操作を更に受け付け」ておらず，「表示制御部は，前記第１画面を表示中に前記第２画面への切替操作を前記入力受付部が受け付けた場合に，前記第１画面に表示されている前記出発駅から前記到着駅までの経路が全て含まれる範囲の地図の混雑度を示す第２画面を表示し」ていない点。

ｄ ＜相違点４＞

本件補正発明では，「混雑情報を用いて表示」する際に，「第１画面」と「第２画面」とで，「共通の前記混雑情報を用いて表示」しているのに対して，引用発明では，「第２画面」を表示していない点。

（４）判断

以下，相違点について検討する。

ア ＜相違点１＞について

経路探索技術の分野において，駅などの混雑情報として，駅構内の位置における混雑度を用いる技術は，本願出願前に周知の技術であった（例えば，引用文献２の段落００１３および図５ならびに図６等を参照されたい。）。

また，経路探索技術の分野において，駅などの混雑情報を表示する際に，鉄道の利用時刻とに関連付けて表示する技術も，本願出願前に周知の技術であった（例えば，原査定の引用文献７の以下の記載等を参照されたい。）。

［図：0001393636000006.jpg］

スマートフォンやタブレット端末等のモバイル端末である引用発明の端末装置２において，ユーザの操作性や利便性を考慮して，様々な周知技術の適用を試みながら画面に表示する情報を検討することは，当該技術分野における当業者が行う通常の創作活動の範囲内であり，また，当該周知技術を引用発明に適用するに際して特段の阻害要因も認められないから，引用発明において当該周知技術を採用することに格別の困難性は認められない。

したがって，引用発明において，混雑情報として，位置における混雑度を用いる当該周知技術を採用して，「混雑情報」を「位置と混雑度とが関連付けられた」ものとし，「混雑情報」として「混雑度」を「鉄道の利用時刻とに関連付けて」表示する本件補正発明の＜相違点１＞に係る構成とすることは，当業者が容易に想到し得たものである。

イ ＜相違点２＞について

引用発明において，「混雑情報には，駅の混雑状況だけでなく，駅の周辺の領域の混雑状況を示す情報が含まれていてもよく」との開示がある。

引用文献３には，混雑情報として，地図上に（駅周辺を含めた）ルート上の混雑情報を表示する画面をスマートフォンの表示部に切り替え表示する技術が記載されている。

［図：0001393636000007.jpg］

引用発明の上記「混雑情報には，駅の混雑状況だけでなく，駅の周辺の領域の混雑状況を示す情報が含まれていてもよ」いとの示唆に基づいて，「駅周辺の領域の混雑状況を示す情報」表示する際に，引用文献３に記載されているように，地図上に（駅周辺を含めた）ルート上の混雑情報を表示する画面をスマートフォンの表示部に切り替え表示する構成を採用することは，経路探索技術の分野における当業者が行う通常の創作活動の範囲内であり，また，当該公知技術を引用発明に適用するに際して特段の阻害要因も認められないから，引用発明において当該公知技術を採用することに格別の困難性は認められない。

したがって，引用発明において，引用文献３に記載の，地図上に（駅周辺を含めた）ルート上の混雑情報を表示する画面をスマートフォンの表示部に切り替え表示する技術を採用して，地図に関連付けて前記混雑情報に基づく混雑度を示す第２画面とを切り替え可能に表示部に表示させる本件補正発明の＜相違点２＞に係る構成とすることは，当業者が容易に想到し得たものである。

ウ ＜相違点３＞について

経路探索技術の分野において，経路探索結果画面に，切り替え操作を受け付けるリンクを設けて，当該リンクをタップすることで，経路地図画面表示に切り替えて，経路探索結果の経路を出発駅および到着駅まで含めてすべて地図上に表示する技術は，本願出願前に周知の技術であった（例えば，当審拒絶理由の引用文献５（原査定の引用文献６）の段落００７４－００７５，図８および図１３（「ヒートマップを見る」リンクLk3）等を参照されたい。）。

［図：0001393636000008.jpg］

また，上記イで述べたように，引用文献３には，混雑情報として，地図上に（駅周辺を含めた）ルート上の混雑情報を表示する画面をスマートフォンの表示部に切り替え表示する技術が記載されている。

［図：0001393636000009.jpg］

引用発明の「混雑情報には，駅の混雑状況だけでなく，駅の周辺の領域の混雑状況を示す情報が含まれていてもよ」いとの示唆に基づいて，「駅周辺の領域の混雑状況を示す情報」表示する際に，引用文献３に記載されているように，地図上に（駅周辺を含めた）ルート上の混雑情報を表示する画面をスマートフォンの表示部に切り替え表示する構成を採用し，上記周知技術のように、経路探索結果画面に，切り替え操作を受け付けるリンクを設けて，当該リンクをタップすることで，経路地図画面表示に切り替えて，経路探索結果の経路を出発駅および到着駅まで含めてすべて地図上に表示する構成とすることは，経路探索技術の分野における当業者が行う通常の創作活動の範囲内であり，また，当該公知技術および上記周知技術を引用発明に適用するに際して特段の阻害要因も認められないから，引用発明において当該公知技術および上記周知技術を採用することに格別の困難性は認められない。

したがって，引用発明において，引用文献３に記載の技術及び上記周知技術を採用して，「入力受付部」が，「前記第１画面と前記第２画面とを切り替えるための切替操作を更に受け付け」るものであり，「表示制御部は，前記第１画面を表示中に前記第２画面への切替操作を前記入力受付部が受け付けた場合に，前記第１画面に表示されている前記出発駅から前記到着駅までの経路が全て含まれる範囲の地図の混雑度を示す第２画面を表示」させる本件補正発明の＜相違点３＞に係る構成とすることは，当業者が容易に想到し得たものである。

エ ＜相違点４＞について

引用発明において，「駅の現在の混雑状況を示すリアルタイム情報」として，「駅またはその周辺において使用中の端末装置２から取得される該端末装置２の位置等を示す端末プローブ情報の数」が例示されている。

上記例示から，駅周辺の混雑情報として，「使用中の端末装置２から取得される該端末装置２の位置等を示す端末プローブ情報の数」が示唆されているといえる。

したがって，駅構内の混雑情報と同様に，駅周辺の混雑情報も「端末装置２の位置等を示す端末プローブ情報の数」に基づいて特定し，「混雑情報を用いて表示」する際に，「第１画面」と「第２画面」とで，「共通の前記混雑情報を用いて表示」する本件補正発明の＜相違点４＞に係る構成とすることは，当業者が容易に想到し得たものである。

オ 小括

以上から，本件補正後の特許請求の範囲の請求項１に係る発明は，当業者にとって，容易に想到し得たものであるから，特許法第２９条第２項に基づいて，特許を受けることができない。

カ 請求人の主張について

請求人は，令和４年８月１６日提出の意見書において，引用文献３に記載された一番右側の画面ではルート上の混雑情報を地図上において表示する点が開示されているものの，第１画面を表示中に、第２画面への切替操作を入力受付部が受け付けた場合に、第１画面に表示されている出発駅から到着駅までの経路が全て含まれる範囲の地図の混雑度を示す第２画面を表示するという構成が引用文献３には記載も示唆もされていない旨主張している。

しかし，上記ウで述べたように，引用文献３には，混雑情報として，地図上に（駅周辺を含めた）ルート上の混雑情報を表示する画面をスマートフォンの表示部に切り替え表示する技術が記載されており，経路探索技術の分野において，経路探索結果画面に，切り替え操作を受け付けるリンクを設けて，当該リンクをタップすることで，経路地図画面表示に切り替えて，経路探索結果の経路を出発駅および到着駅まで含めてすべて地図上に表示する技術は，本願出願前に周知の技術であった（例えば，当審拒絶理由の引用文献５（原査定の引用文献６）から，当業者であれば，引用発明において，引用文献３に記載の技術及び上記周知技術を採用して，第１画面を表示中に、第２画面への切替操作を入力受付部が受け付けた場合に、第１画面に表示されている出発駅から到着駅までの経路が全て含まれる範囲の地図の混雑度を示す第２画面を表示するという構成を想到し得たものであり，請求人の上記主張は採用できない。

３ 本件補正についてのむすび

以上から，本件補正は，特許法１７条の２第６項において準用する同法１２６条７項の規定に違反するので，同法１５９条１項の規定において読み替えて準用する同法５３条１項の規定により却下すべきものである。

よって，上記補正の却下の決定の結論のとおり決定する。

第３ 本願発明について

１ 本願発明

令和４年８月１６日にされた手続補正は，上記のとおり却下されたので，本願の請求項に係る発明は，令和３年５月２６日にされた手続補正により補正された特許請求の範囲の請求項１ないし１０に記載された事項により特定されるものであるところ，その請求項１に係る発明（以下「本願発明」という。）は，その請求項１に記載された事項により特定される，前記第２［補正の却下の決定の理由］１（２）に記載のとおりのものである。

２ 当審拒絶理由の概要

令和４年６月１４日付けで当審が通知した拒絶理由（以下「当審拒絶理由」という。）の理由１は概ね，次のとおりのものである。

本願の特許請求の範囲の請求項１ないし６，９および１０に係る発明は，以下の引用文献１に記載された発明及び引用文献２ならびに３に記載された事項に基づいて，その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであり，

本願の特許請求の範囲の請求項７および８に係る発明は，以下の引用文献１に記載された発明，及び，引用文献２ないし５に記載された事項に基づいて，その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから，特許法第２９条第２項に基づいて，特許を受けることができない。

１.特開２０１６－０８０６６５号公報（原査定の引用文献２）

２.特開２００６－２４４０６９号公報（周知例）

３.『NAVITIME』にて「混雑エリアマップ」を提供開始，日本，

株式会社ナビタイムジャパン，２０２０年 ６月１８日，

［ＵＲＬ：

https://corporate.navitime.co.jp/topics/pr/202006/18_5260.html］

（原査定の引用文献１）

４．Yahoo! MAP，「混雑レーダー」の混雑状況の表示を最短２時間前から

最短２０分前にアップデート，日本，ヤフー株式会社，

２０２０年 ５月２５日，

［ＵＲＬ：https://about.yahoo.co.jp/pr/release/2020/05/25b/］

（原査定の引用文献５，周知例）

５．特開２０１７－３３４４０号公報（原査定の引用文献６，周知例）

３ 引用文献

当審拒絶理由で引用された引用文献１ないし３及びその記載事項は，前記第２の［補正の却下の決定の理由］２（２）に記載したとおりである。

４ 対比・判断

本願発明は，前記第２の［補正の却下の決定の理由］２で検討した本件補正発明から，発明を特定するために必要な事項である「第１画面」に示す「混雑情報に基づく混雑度」について，「鉄道の利用時刻」と関連付けて示すとの限定事項を削除し，「入力受付部」について，「前記入力受付部は，前記第１画面と前記第２画面とを切り替えるための切替操作を更に受け付け」るとの限定事項を削除し，「表示制御部」について「前記表示制御部は，前記第１画面を表示中に前記第２画面への切替操作を前記入力受付部が受け付けた場合に，前記第１画面に表示されている前記出発駅から前記到着駅までの経路が全て含まれる範囲の地図の混雑度を示す第２画面を表示」するとの限定事項を削除したものである。

そうすると，本願発明の発明特定事項を全て含み，さらに他の事項を付加したものに相当する本件補正発明が，前記第２の［補正の却下の決定の理由］２（３），（４）に記載したとおり，引用発明および引用文献２ならびに３に記載された事項に基づいて，当業者が容易に発明をすることができたものであるから，本願発明も，引用発明および引用文献２ならびに３に記載された事項に基づいて，当業者が容易に発明をすることができたものであり，本願発明は，特許法２９条２項の規定により特許を受けることができない。

第４ むすび

以上のとおり，本願発明は，特許法２９条２項の規定により特許を受けることができないから，他の請求項に係る発明について検討するまでもなく，本願は拒絶されるべきものである。

よって，結論のとおり審決する。