• ポートフォリオ機能


ポートフォリオを新規に作成して保存
既存のポートフォリオに追加保存

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 特許、登録しない。 G09B
審判 査定不服 5項独立特許用件 特許、登録しない。 G09B
管理番号 1124820
審判番号 不服2003-13313  
総通号数 72 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2002-02-20 
種別 拒絶査定不服の審決 
審判請求日 2003-07-11 
確定日 2005-10-11 
事件の表示 特願2000-240401「地図表示システム及び方法」拒絶査定不服審判事件〔平成14年 2月20日出願公開、特開2002- 55601〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由 第1 手続の経緯
本願は平成12年8月8日の出願であって、平成15年6月9日付けで拒絶の査定がされたため、これを不服として同年7月11日付けで本件審判請求がされるとともに、同年8月11日付けで明細書についての手続補正(平成14年改正前特許法17条の2第1項3号の規定に基づく手続補正であり、以下「本件補正」という。)がされたものである。

第2 補正の却下の決定
[補正の却下の決定の結論]
平成15年8月11日付けの手続補正を却下する。

[理由]
1.補正事項及び補正目的
本件補正前後の【請求項4】及び【請求項7】の記載を比較すると、本件補正は次の補正事項を含んでいる。
補正事項1:補正前請求項4記載の「ダウンロードした前記断片地図データから前記表示範囲の地図画像を描画して表示する」を「前記複数の地図サーバから分散してダウンロードした前記複数の断片地図データから前記表示範囲の地図画像を描画して表示する」と補正する。
補正事項2:補正前請求項7記載の「各断片地図データの地理的な位置座標に対する所定の数値演算により演算できるようになっており」を「各断片地図データの地理的な位置座標の緯度成分と経度成分をそれぞれ緯度方向と経度方向のファイル数又はフォルダ数で除算することにより得られるようになっており」と補正する。
補正事項2は、補正前の「所定の数値演算」を「緯度成分と経度成分をそれぞれ緯度方向と経度方向のファイル数又はフォルダ数で除算すること」と限定するものであるから、特許請求の範囲の限定的減縮(特許法17条の2第4項2号該当)を目的とするものと認める。
補正事項1は、「ダウンロードした前記断片地図データから前記表示範囲の地図画像を描画」を「前記複数の地図サーバから分散してダウンロードした前記複数の断片地図データから前記表示範囲の地図画像を描画」と限定するものであるから、特許請求の範囲の限定的減縮を目的とするものと一応認める。もっとも、複数の地図サーバから分散してダウンロードすること、及び複数の断片地図データから表示範囲の地図画像を描画することは、補正前請求項4にも「所望の表示範囲に必要な複数の断片地図データを、通信ネットワークを通じて、前記複数台の地図サーバから分散してダウンロードし」と記載されているから、実質的には【請求項4】を限定的に減縮せず、重複記載をしただけと解するべきかもしれないが、たといそうであってとしても次の3つの理由により審決の結論には影響を及ぼさない。
(ア)限定的減縮でないとすると、特許法17条の2第4項に違反する補正であるから、どのみち本件補正は却下されなければならず、後記請求項4に係る発明の認定に影響を及ぼさない。重複記載を「明りようでない記載」と解する余地があるとしても、補正前【請求項4】が明りようでない旨の拒絶理由は通知されていないだけでなく、補正前【請求項4】が明りようでなく、補正後【請求項4】が明りようであると解することもできない。
(イ)補正事項2は明らかに特許請求の範囲の限定的減縮を目的とするものであり、後記のとおり、本件補正後の請求項7に係る発明は独立特許要件を欠如するから、本件補正は却下されなければならず、後記請求項4に係る発明の認定に影響を及ぼさない。
(ウ)補正事項1が限定的減縮でないとすると、本件補正前後の請求項4に係る発明は実質的に同一発明であるから、請求項4に係る発明の進歩性の判断には影響を及ぼさない。
そこで、本件補正後の請求項4及び請求項7に係る発明(以下「補正発明4」及び「補正発明7」という。)が、特許出願の際独立して特許を受けることができるかどうか検討する。

2.補正発明の認定
補正発明4及び補正発明7は、本件補正により補正された明細書の特許請求の範囲【請求項4】及び【請求項7】に記載された事項によって特定される次のとおりのものと認める。
補正発明4:「多数の断片地図データに細分された全体地図データをそれぞれもつ複数台の地図サーバと、
所望の表示範囲に必要な複数の断片地図データを、通信ネットワークを通じて、前記複数台の地図サーバから分散してダウンロードし、前記複数の地図サーバから分散してダウンロードした前記複数の断片地図データから前記表示範囲の地図画像を描画して表示するクライアントと
を備える地図表示システム。」
補正発明7:「多数の断片地図データに細分された全体地図データをもち、
前記多数の断片地図データを階層構造のディレクトリにより管理しており、前記階層構造のディレクトリにおける各断片地図データへのパスが、各断片地図データの地理的な位置座標の緯度成分と経度成分をそれぞれ緯度方向と経度方向のファイル数又はフォルダ数で除算することにより得られるようになっており、
クライアントからの所望の断片地図データのパスを含んだダウンロードリクエストに応答して、前記ダウンロードリクエストに含まれるパスにより特定される断片地図データを、通信ネットワークを通じて前記クライアントに送信する
地図サーバ。」

3.引用刊行物の記載事項
原査定の拒絶の理由に引用された特開2000-48039号公報(以下「引用例1」という。)には、次のア〜キの記載が図示とともにある。
ア.「地図データが、表示する地図の表示密度に応じた複数のレベルの表示スケール層に分類され、各表示スケール層はその層の地図の表示を行なうための、川、鉄道、病院、行政区域、地名、駅名など地図上で表示するための最小要素で、各表示要素には表示スケール層のなかで表示される位置データが付加された表示単位により構成されており、地図管理プログラムにより地図データの表示単位が分類管理されているホストコンピュータの地図データベース、ユーザーの指示に応じて、表示スケールの階層と地域を指定してホストコンピュータより地図データをダウンロードして保持して地図データの表示を行なう地図表示プログラムを持つクライアントコンピュータの地図データの表示手段、ユーザーより新たな地図データの表示の変更の指示があった場合に、現在クライアントコンピュータが保持している地図データと、新たな地図データの表示を行なうために必要な地図データとの差分の地図データの表示単位を求める手段、差分の地図データの表示単位をホストコンピュータよりクライアントコンピュータにダウンロードする手段、ダウンロードされた差分の地図データの表示単位と現在クライアントコンピュータが保持している地図データの表示単位とを使用して新たな地図データの表示を行なう表示手段、よりなる地図情報のダウンロードシステム。」(【請求項5】)
イ.「最近、ISDN等のデジタル通信網の発展に伴い、インターネット等のコンピューターを使用した情報ネットワークが急速に普及しつつある。インターネット等の情報ネットワークでは、文字等のテキストデータだけでは無く、写真や地図などのイメージデータも使用されている。」(段落【0002】)
ウ.「地図情報のネットワークにおいては、地図情報を求めるユーザーは、クライアントコンピュータ20を使用してホストコンピュータ10にアクセスして、必要な地図情報をダウンロードして、表示装置21に表示して閲覧することにより地図情報を得るようにしている。」(段落【0004】)
エ.「図1において、DTは地図データーベースの表示スケール層を示す。DP0は、表示スケール層0の地図データの表示を行なうためのデータの表示プリムティブを示し、DP1は表示スケール層1の地図データの表示を行なうためのデータ表示プリムティブを示し、DP2表示スケール層2の地図データの表示を行なうためのデータ表示プリムティブを示す。」(段落【0008】)
オ.「ホストコンピュータの地図データベースのデーターは、表示する地図の表示密度に応じた複数のレベルの表示スケール層に分類されて保持されている。表示スケール層とは、例えば、地図を表示する際、「200万分の1」から「50万分の1」に適応する層を表示スケール0層とし、「50万分の1」から「12万5千分の1」に適応する層を表示スケール1層として、一定のスケールの大きさごとに層別に区分けしたものである。各表示スケール層はその層の地図の表示を行なうための適切な表示単位により構成されている。「地図データベース」は、各表示スケール層ごとに分類して地図データの表示単位が保存され、「地図管理プログラム」により地図データの表示単位が分類管理されている。」(段落【0009】)
カ.「表示単位とは、川、鉄道、病院、行政区域、地名、駅名など地図上で表示するための最小要素で、各表示要素には表示スケール層のなかで表示される位置データが付加されている。これを以降表示プリミティブと呼ぶ。表示スケール層0の表示プリムティブDP0は、その分割された各表示領域に対応した表示プリムティブ1,表示プリムティブ2,表示プリムティブ3を持っている。又、表示スケール層1の表示プリムティブDP1はその分割された各表示領域に対応した表示プリムティブ5,表示プリムティブ6,表示プリムティブ7を持っている。同様に、表示スケール層2の表示プリムティブDP2は、その分割された各表示領域に対応した表示プリムティブ8,表示プリムティブ9,表示プリムティブ10を持っている。」(段落【0010】)
キ.「地図情報のダウンロードは、表示したい地図の表示スケール層の領域に対応した特定の表示プリムティブを指定して行われる。図2は、本発明の地図情報のダウンロードシステムに使用される、ホストコンピュータの地図データーベースの各表示スケール層の分割領域と表示プリミティブの関係を説明するための図である。・・・表示スケール層0は、図2の(a)に示すように、例えば、01〜09の9個の領域に分割されている。9個に分割された表示スケール層0の領域の1つ1つが、図2の(b)に示すように、次の表示スケール層1に対応する。表示スケール層1は、表示スケール層0の領域分割数だけ概念上存在する。「概念上存在」の意味は、表示スケール層0のある領域において、表示プリミティブが下層の表示スケール層にも存在しない場合、この領域において表示スケール層は実装上存在しなくてもよく、架空の表示スケール層として存在する意味である。表示スケール層は、表示スケール層1以降も、図2の(c)に示すように、表示スケール層1と表示スケール層2の関係を表示スケール層の存在する数だけ繰り返す。」(段落【0011】)

4.引用例1記載の発明の認定
引用例1の上記記載によれば、「ホストコンピュータの地図データベース」は、地図データを複数のレベルの表示スケール層に分類して保持し、各表示スケール層は複数の表示領域に分割され、各表示領域に対応した表示プリムティブ(表示単位ともいう。)が保存されている。
したがって、引用例1にはクライアントコンピュータとネットワーク接続されたホストコンピュータとして、次のようなものが記載されていると認めることができる。
「クライアントコンピュータとネットワーク接続されたホストコンピュータであって、地図データを複数のレベルの表示スケール層に分類して保持し、各表示スケール層は複数の表示領域に分割され、各表示領域に対応した表示プリムティブを保存した地図データベースを有するホストコンピュータ。」(以下「引用発明A]という。)

また、引用発明Aとクライアントコンピュータからなる「地図情報のダウンロードシステム」としては、次のようなものが記載されていると認めることができる。
「クライアントコンピュータ及びそれとネットワーク接続されたホストコンピュータからなる地図情報のダウンロードシステムであって、
ホストコンピュータは、地図データを複数のレベルの表示スケール層に分類して保持し、各表示スケール層は複数の表示領域に分割され、各表示領域に対応した表示プリムティブを保存した地図データベースを有し、
クライアントコンピュータは、表示スケールの階層と地域を指定してホストコンピュータより地図データをダウンロードして保持して地図データの表示を行なう地図表示プログラムを持つ地図データの表示手段を有する地図情報のダウンロードシステム。」(以下「引用発明B]という。)

5.補正発明4と引用発明Bとの一致点及び相違点の認定
以下、本審決では「発明を特定するための事項」という意味で「構成」との用語を用いることがある。
引用発明Bの「表示プリムティブ」は補正発明4の「断片地図データ」に相当し、引用発明Bにおいてそれが多数存在すること、それら多数の表示プリムティブが「全体地図データ」を細分したものであることは自明である。
引用発明Bにおいて「表示スケールの階層と地域を指定」することは、補正発明4の「所望の表示範囲」を画定することと異ならない。
引用発明Bは「地図情報のダウンロードシステム」の発明であるが、「クライアントコンピュータ」は「地図データの表示を行なう地図表示プログラムを持つ地図データの表示手段」を有するのだから、「地図表示システム」の発明ということもできる。
引用発明Bでは「クライアントコンピュータ」と「ホストコンピュータ」がネットワーク接続されており、クライアントコンピュータとネットワーク接続されダウンロード対象となるデータを保持したものを「ホストコンピュータ」というか「サーバ」というかは表現上の相違にすぎないから、引用発明Bの「クライアントコンピュータ」は「所望の表示範囲に必要な複数の断片地図データを、通信ネットワークを通じて、地図サーバからダウンロードし、ダウンロードした前記複数の断片地図データから前記表示範囲の地図画像を描画して表示する」点で補正発明4の「クライアント」と一致する。
したがって、補正発明4と引用発明Bとは、
「多数の断片地図データに細分された全体地図データをもつ地図サーバと、
所望の表示範囲に必要な複数の断片地図データを、通信ネットワークを通じて、前記地図サーバからダウンロードし、前記地図サーバからダウンロードした前記複数の断片地図データから前記表示範囲の地図画像を描画して表示するクライアントと
を備える地図表示システム。」である点で一致し、次の点で相違する。
〈相違点1〉補正発明4が「地図サーバ」を複数台備え、クライアントが「複数の断片地図データ」を取得するに当たり、「複数台の地図サーバから分散」してダウンロードし、地図画像描画の基となる「複数の断片地図データ」が「複数の地図サーバから分散してダウンロードした」ものであるのに対し、引用発明Bでは全体地図データももつ「ホストコンピュータ」を複数そなえてはおらず、当然「複数の断片地図データ」を取得するに当たり、「複数台の地図サーバから分散」してダウンロードすることがない点。

6.補正発明7と引用発明Aとの一致点及び相違点の認定
5.で述べたことを踏まえると、引用発明Aの「クライアントコンピュータ」、「ネットワーク」、「ホストコンピュータ」及び「表示プリムティブ」は、補正発明7の「クライアント」、「通信ネットワーク」、「地図サーバ」及び「断片地図データ」のそれぞれに相当し、引用発明Aの「ホストコンピュータ」は「多数の断片地図データに細分された全体地図データ」を有している。
また、引用発明Aの「表示プリムティブ」はネットワーク接続された「クライアントコンピュータ」にダウンロードされることが当然の前提であるから、「クライアントからの所望の断片地図データのパスを含んだダウンロードリクエストに応答して、前記ダウンロードリクエストに含まれるパスにより特定される断片地図データを、通信ネットワークを通じて前記クライアントに送信する」ものと認めることができる(記載キの「地図情報のダウンロードは、表示したい地図の表示スケール層の領域に対応した特定の表示プリムティブを指定して行われる。」との記載も参照されたい。)。
したがって、補正発明7と引用発明Aとは、
「多数の断片地図データに細分された全体地図データをもち、
クライアントからの所望の断片地図データのパスを含んだダウンロードリクエストに応答して、前記ダウンロードリクエストに含まれるパスにより特定される断片地図データを、通信ネットワークを通じて前記クライアントに送信する
地図サーバ。」である点で一致し、次の点で相違する。
〈相違点2〉補正発明7では「多数の断片地図データを階層構造のディレクトリにより管理しており、前記階層構造のディレクトリにおける各断片地図データへのパスが、各断片地図データの地理的な位置座標の緯度成分と経度成分をそれぞれ緯度方向と経度方向のファイル数又はフォルダ数で除算することにより得られるようになって」いるのに対し、引用発明Aでは、「地図データを複数のレベルの表示スケール層に分類して保持し、各表示スケール層は複数の表示領域に分割され、各表示領域に対応した表示プリムティブを保存」しているものの、補正発明7の上記構成を有するとはいえない点。

7.相違点についての判断及び補正発明4,7の独立特許要件の判断
(1)相違点1について
本願出願当時、サーバと多数のクライアントがネットワーク接続されている場合、クライアントからのダウンロード要求が集中すること、並びにそれが原因となってダウンロードが円滑に実行されないことを避けるため、同一のデータベースを有するサーバを複数設け、特定のサーバにダウンロード要求が集中しないように要求を分散することは、例えば、
特開平5-173919号公報に「【発明が解決しようとする課題】従来の技術では、複数のホストコンピュータが複数の通信処理装置に対して通信処理装置プログラムおよびネットワーク構成テーブルをダウンロードするときは、ある特定のホストコンピュータが全ての通信処理装置に対してダウンロードを行っていたため、複数の通信処理装置およびネットワーク構成テーブルをダウンロードするには一つのホストコンピュータ内の通信制御手段にだけに負荷がかかり、高速にダウンロードができない欠点がある。」(段落【0004】)及び「本発明は、このような欠点を除去するもので、通信処理装置プログラムおよびネットワーク構成テーブルの通信処理装置に対するダウンロードを複数のホストコンピュータから分散して行うことを可能にし、通信処理装置に対して高速にダウンロードを行うことができるオンライン情報処理システムを提供することを目的とする。」(段落【0005】)と、
特開平6-52119号公報に「特定の共用ファイルが頻繁にアクセスされるとそのファイルサーバに要求が集中し、分散データ処理システム全体の性能上のボトルネックとなる可能性がある。そこでこのファイルのコピーを第2のファイルサーバにも置き、このファイルへのアクセス要求の一部を第2のファイルサーバで処理することにより、2つのファイルサーバの間で負荷分散し、前記のボトルネックの解消を図ることが行われる。」(段落【0003】)と、
特開2000-101628号公報に「複数のサーバに同一のファイルデータが蓄積されているネットワークにおいて、クライアントから要求されたファイルデータを蓄積し、かつファイルデータの送信に必要な転送時間が最小となるサーバを選択できるようにして、サーバ及びネットワークの負荷分散を図ることを目的とする。」(段落【0006】)、「クライアント1は、・・・該当するファイルデータを蓄積していて性能条件も満足しているサーバの中から、現在のサーバの負荷が軽く、ネットワーク経路のトラフィックも少ない最適なサーバを検出し、そのサーバ(図2の場合ではサーバC)に対してファイルデータそのものの転送を要求する(S13)。サーバCは、クライアント1からの転送要求を受信すると、要求されたファイルデータをクライアント1に対して送信を開始する(S14)。」(段落【0016】)、「データ転送開始後は、・・・一定時間ごとに要求コンテンツ属性を再送し(S15)、その返答までの応答時間などから現在の時点でサーバの負荷が軽く、ネットワーク経路のトラフィックも少ない最適なサーバを検出する(S16)。」(段落【0017】)及び「最適なサーバが例えばサーバAに変化していた場合には、・・・サーバAは、ファイルデータの送信要求を受け取ると、該当するファイルデータの継続部分からクライアント1に対して送信を開始する(S18)。」(段落【0019】)と、
特開2000-29813号公報に「混雑を解消する為にミラーサーバが複数用意されていることもある。このミラーサーバは、元のサーバと全く同じ機能と情報を持たせたサーバであり、元のサーバのコピーであるといえる。」(段落【0009】)及び「ユーザは、・・・適していると考える接続サーバを複数のサーバから選択することができる。この様にユーザの接続を複数のサーバに分散することにより、サーバ及びネットワークの負荷を分散、軽減することができる様になっている。」(段落【0010】)と、
国際公開パンフレットWO98/31107に、「クライエントコンピュータをサーバに自動的に向けさせる幾つかの既知の解決策は、例えば、多数のサーバ間で負荷のバランスをとるよう試みるために多数のサーバレプリカの1つへユーザを向けるラウンドロビンDNS及び負荷バランスDNSを含む。マルチプルホストネームと称する別の解決策では、各々個別のホストネームを有する多数のサーバにわたって内容が分散される。ユーザに返送されるウェブページは、負荷バランスの問題及びレプリカの内容事項に基づいてユーザに対して選択されたレプリカを指すリンクを含む。インターネット負荷バランシングと称する別の解決策では、ハードウェア要素が、単一のIPアドレスへ送られるユーザ要求を多数のサーバレプリカの1つへ自動的に分配して、負荷のバランスをとる。」(1頁15〜28行。訳文は対応日本国出願の公表公報である特表2001-508258号公報8頁13〜22行による。)とそれぞれ記載があるとおり周知である。
引用例1の記載イにあるように、引用発明Bのネットワークはインターネットを想定したものであり、ホストコンピュータ(サーバ)は多数のクライアントとネットワーク接続されることが当然予定されているものと認める。そうであれば、引用発明Bにおいて、ダウンロード要求が集中した場合に備えて上記周知技術を採用、すなわち相違点1に係る補正発明4の構成を採用することは当業者にとって想到容易である。
なお、本願明細書には出願当初から一貫して「複数のサーバによる負荷分散の形態には、上記以外にも色々なものが採用し得る。例えば、地域毎にサーバを分けても良い。」(段落【0073】)との記載があるから、補正発明4の「多数の断片地図データに細分された全体地図データ」が複数の地図サーバに共通であるとまでは認めることができず、そのため補正発明4の「分散してダウンロード」を、必ず複数のサーバからダウンロードするとの趣旨に解することはできないが、仮にその趣旨であるとしても設計事項にすぎない。なぜなら、前掲国際公開パンフレットWO98/31107にあるように「単一のIPアドレスへ送られるユーザ要求を多数のサーバレプリカの1つへ自動的に分配」すれば必ず複数のサーバからダウンロードすることになるばかりか、複数のサーバを設けることの趣旨がダウンロード要求の集中回避にあり、特開平11-345161号公報に「処理対象となる個々のデータは、データサーバ装置A,B,Cのいずれかに格納されることになる。」(段落【0014】)及び「データサーバを複数台のコンピュータで構成するようにすれば、・・・データ処理装置からのアクセスが複数のサーバに分散するため、サーバ用コンピュータにかかる負荷も分散し、より効率的な運用が可能になる。」(段落【0015】)と記載されているとおり、複数のサーバにアクセスすることが、負荷分散や効率的運用に資することは当業者には自明であるからである。

(2)相違点2について
引用例1の記載キ及び【図2】によれば、表示スケール層0が3×3の9個の表示領域に分割されており、表示スケール層0の各表示領域が表示スケール層1で縦横に分割された複数(縦分割数と横分割数の積)の表示領域に対応し、表示スケール層1の各表示領域が表示スケール層2で縦横に分割された複数(縦分割数と横分割数の積)の表示領域に対応している。引用発明Aにおいて、各表示スケールの表示領域には上記のとおりの対応関係があり、各表示スケールの各表示領域に表示プリムティブが保存されているのだから、各表示スケールの各表示領域は階層構造をなしているいうことができる。そして、階層構造をなす場合に、それぞれの表示領域をフォルダとして、階層構造のディレクトリにより管理することは設計事項というべきである。
ところで、補正発明7の「階層構造のディレクトリにおける各断片地図データへのパスが、各断片地図データの地理的な位置座標の緯度成分と経度成分をそれぞれ緯度方向と経度方向のファイル数又はフォルダ数で除算することにより得られる」の意味は必ずしも明確ではないから、発明の詳細な説明を参酌する。
本願明細書には出願当初から一貫して、「地図がカバーする全体地域は緯度と経度の方向に細分された多数のメッシュに分割されている。」(段落【0023】)及び「各メッシュには、各メッシュの全体地図上での位置座標に相当するメッシュ番号が割り当てられている。図3に示すように、各メッシュのメッシュ番号は、経度方向の座標値(経度方向のメッシュ番号)Xiと、緯度方向の座標値(緯度方向のメッシュ番号)Yjとのセット(Xi、Yj)で表される。そして、図3に示すように、ポリゴンレイヤ210に含まれるメッシュごとのポリゴンファイル211、211、…、線レイヤ220に含まれるメッシュごとの線ファイル221、221、…、及び文字レイヤ230に含まれるメッシュごとの文字ファイル231、231、…には、それぞれのメッシュのメッシュ番号(Xi、Yj)と同じファイル名「XiYj」が付けられている。」(段落【0024】)との記載があるから、「地理的な位置座標の緯度成分と経度成分」とは、絶対的な緯度値・経度値に限られず、これら記載中の「メッシュ番号」であってもよい。また、本願明細書の「図4(B)に示す各フォルダ132のフォルダ名(ディレクトリ名)は、各フォルダに格納された64個のメッシュファイル131、131、…のファイル名「XiYj」の経度成分「Xi」と緯度成分「Yj」をそれぞれ経度方向と緯度方向のファイル数「8」で除算した商で表した名称・・・となっている。」(段落【0028】〜【0029】)及び「図4(B)に示すような連続的なフォルダ名(つまり図4(C)に示した8×8メッシュ区域の位置座標)をもつ8×8配列の64個の第2階層のフォルダ132、132、…を1群に纏めて、図4(A)に示す更に1階層上(第1階層)のフォルダ133、133、…の一つに格納してある。そして、図4(A)に示す各フォルダ133のフォルダ名(ディレクトリ名)は、各フォルダ133に格納された64個のフォルダ132、132、…のフォルダ名の経度成分「Xi/8」と緯度成分「Yj/8」をそれぞれ経度方向と緯度方向のフォルダ数「8」で除算した商で表した名称・・・となっている。」(段落【0030】〜【0031】)との記載によれば、「緯度方向と経度方向のファイル数又はフォルダ数」とは、全体地図データにおける「緯度方向と経度方向のファイル数又はフォルダ数」ではなく、階層構造のディレクトリにより管理した際に上位階層の1つのフォルダに含まれる下位階層の「緯度方向と経度方向のファイル数又はフォルダ数」の意味に解さなければならず、それは上位階層の1つのメッシュに含まれる下位階層の緯度方向と経度方向のメッシュ数でもある。

原査定の拒絶の理由に引用された特開平11-232433号公報(以下「引用例2」という。)には、次のク〜サの記載が図示とともにある。
ク.「サーバー4は、クライアント端末1からの地図データの要求に対し、記憶装置5に格納したメッシュ・レイヤーインデックスファイルを参照して地図データベースから地図データを抽出し、これをクライアント端末1へ送信するものである。これらの処理を行うものとして、サーバー4は、例えば地図要求受付部21、地図範囲確定処理部22、地図データ抽出処理部23、地図データ送信処理部24を有する。そして、クライアント端末1からの地図データの要求に対し、地図要求受付部21によりその受付処理を行い、地図範囲確定処理部22によりデータ種別、データ領域、地図データの表示倍率、最小表示サイズからメッシュ・レイヤーインデックスファイルを参照して地図データの抽出範囲を確定することにより、地図データ抽出処理部23により地図データベースから地図データの要求に対応した地図データの抽出を行い、地図データ送信処理部24により抽出した地図データをクライアント端末1に送信する。」(段落【0011】)
ケ.「地図データベースは、クライアント端末1からの地図データの要求に対して高速にデータ抽出を実現するため、地図の範囲を複数のデータ領域(メッシュ)に分割し、かつ複数のデータ種別(レイヤー)に分割したデータ構造を持つ。すなわち、メッシュ・レイヤーインデックスファイルには、地図を作成するとき、縦×横を指定範囲、例えば10km×l.5Kmといった範囲の領域にメッシュ分割したデータ領域の情報と、データの種類を区別する情報で分割したデータ種別の情報を持つインデックス情報を作成し、クライアント端末1からの地図データの要求に対して、即時に送信すべき地図データを抽出できるようにしている。」(段落【0012】)
コ.「クライアント端末に設定される管理テーブルのうち、データ領域管理テーブルは、例えば図2に示すように地図データを表示する領域(メッシュ)が識別できるデータ領域のメッシュ番号、データの種類を区別するデータ種別ごとに固有のレイヤー番号、表示頻度、表示フラグ、地図データブロック位置、地図データ数の各情報を有するものである。」(段落【0014】)
サ.「メッシュ番号は、地図のデータの範囲を含む矩形領域を任意の矩形サイズで分割した領域に振られる番号であり、例えば北海道の地図データを作成する場合の、メッシュ番号の採番状況を示したのが図9である。1データの表示領域の指定には、メッシュ・レイヤーインデックスファイルで管理するこのメッシュ番号を指定する。このことにより、表示領域を直ちに指示することが可能となる。座標単位は、任意に決定されるマクロ座標であるが、原点位置(座標0,0)の緯度・経度とメッシュの矩形サイズ(距離)は地図データ作成時に指定するため、各メッシュ原点(左下座標)の緯度・経度は計算により求められる。」(段落【0026】)
これら記載(特に記載サ)及び【図9】によれば、地図データの範囲はメッシュに分割されており、各メッシュには左下を(00-00)として、縦横(一方が緯度方向で、他方が経度方向)の連続整数番号が付されている。上述したように、引用発明Aにおいても各表示スケール層は、縦横(一方が緯度方向で、他方が経度方向)に分割された表示領域からなっており、この表示領域と引用例2記載のデータ領域(メッシュ)は格別異なるものではない。
そうであれば、引用発明Aの各表示スケール層の各表示領域に対して、引用例2同様に左下を(00-00)として縦横(一方が緯度方向で、他方が経度方向である。)の連続整数番号を付すことは当業者が容易に想到できるといわなければならない。その場合、緯度方向を例にあげれば、表示スケール層0の表示領域の緯度方向番号が0〜aであり、該表示領域に含まれる表示スケール層1の緯度方向の表示領域数がMであるとすると、表示スケール層1の表示領域には、緯度方向の番号として0〜Maが付されることになる。そして、表示スケール層1の表示領域の緯度方向番号をnM+k(ただし、0≦k<M)とすると、それをMで除した商はnであり、同表示領域に対応する表示スケール層0の表示領域の緯度方向番号もnである。経度方向についても同様であり、表示領域に付された連続整数番号は補正発明7の「各断片地図データの地理的な位置座標の緯度成分と経度成分」と異ならないから、引用発明Aの各表示スケール層の各表示領域に対して、左下を(00-00)として縦横(一方が緯度方向で、他方が経度方向)の連続整数番号を付したものは、各断片地図データの地理的な位置座標の緯度成分と経度成分をそれぞれ緯度方向と経度方向のフォルダ数で除算することにより得られるものと異ならない。さらに、引用例2の記載サにあるとおり、メッシュ番号指定により表示領域を指示するのであるから、表示領域を1つのフォルダとして管理するに当たり、その名称としてメッシュ番号をそのまま用いることは設計事項に属し、かかる名称を用いれば補正発明7の「前記階層構造のディレクトリにおける各断片地図データへのパスが、各断片地図データの地理的な位置座標の緯度成分と経度成分をそれぞれ緯度方向と経度方向のファイル数又はフォルダ数で除算することにより得られる」との構成に至ることは明らかである。なお、補正発明7は「地図サーバ」の発明であり、「各断片地図データへのパスが、各断片地図データの地理的な位置座標の緯度成分と経度成分をそれぞれ緯度方向と経度方向のファイル数又はフォルダ数で除算することにより得」る機能自体はクライアントが有する機能にすぎないから、「地図サーバ」としては、そのような機能を有するクライアントによって指定されたパスに対応するようにデータベースが構築されていることだけが要件とされており、同要件を採用することには上記のとおり困難性はない。
したがって、相違点2に係る補正発明7の構成を採用することは、当業者にとって想到容易といわなければならない。

(3)補正発明4及び補正発明7の独立特許要件の判断
相違点1に係る補正発明4の構成及び相違点2に係る補正発明7の構成は、いずれも当業者にとって想到容易であり、これら構成を採用したことによる格別の作用効果を認めることもできない。
したがって、補正発明4は引用発明B及び周知技術に基づいて、補正発明7は引用発明A及び引用例2記載の発明に基づいて、それぞれ当業者が容易に発明をすることができたものであるから、特許法29条2項の規定により特許出願の際独立して特許を受けることができない。

[補正の却下の決定のむすび]
以上のとおり、補正前請求項4,7を限定的に減縮した補正発明4及び補正発明7が特許出願の際独立して特許を受けることができないから、本件補正は平成15年改正前特許法17条2第5項で準用する同法126条4項の規定に違反している。
したがって、本件補正は平成14年改正前特許法159条1項で読み替えて準用する同法53条1項の規定により却下されなければならない。
よって、補正の却下の決定の結論のとおり決定する。

第3 本件審判請求についての当審の判断
1.本願発明の認定
本件補正が却下されたから、本願の請求項4に係る発明(以下「本願発明4」という。)及び請求項7に係る発明(以下「本願発明7」という。)は、平成15年1月30日付けで補正された明細書の特許請求の範囲【請求項4】及び【請求項7】に記載された事項によって特定される次のとおりのものと認める。
本願発明4:「多数の断片地図データに細分された全体地図データをそれぞれもつ複数台の地図サーバと、
所望の表示範囲に必要な複数の断片地図データを、通信ネットワークを通じて、前記複数台の地図サーバから分散してダウンロードし、ダウンロードした前記断片地図データから前記表示範囲の地図画像を描画して表示するクライアントとを備える地図表示システム。」
本願発明7:「多数の断片地図データに細分された全体地図データをもち、
前記多数の断片地図データを階層構造のディレクトリにより管理しており、前記階層構造のディレクトリにおける各断片地図データへのパスが、各断片地図データの地理的な位置座標に対する所定の数値演算により演算できるようになっており、
クライアントからの所望の断片地図データのパスを含んだダウンロードリクエストに応答して、前記ダウンロードリクエストに含まれるパスにより特定される断片地図データを、通信ネットワークを通じて前記クライアントに送信する
地図サーバ。」

2.本願発明4及び本願発明7の進歩性の判断
本願発明4を限定的に減縮した補正発明4が引用発明B及び周知技術に基づいて当業者が容易に発明をすることができたものである以上、本願発明4も引用発明B及び周知技術に基づいて当業者が容易に発明をすることができたものであることが明らかである。
本願発明7を限定的に減縮した補正発明7が引用発明A及び引用例2記載の発明に基づいて当業者が容易に発明をすることができたものである以上、本願発明7も引用発明A及び引用例2記載の発明に基づいて当業者が容易に発明をすることができたものであることが明らかである。
したがって、本願発明4及び本願発明7は特許法29条2項の規定により特許を受けることができない。

第4 むすび
本件補正は却下されなければならず、本願発明4及び本願発明7が特許を受けることができない以上、本願のその余の請求項に係る発明について検討するまでもなく、本願は拒絶を免れない。
よって、結論のとおり審決する。
 
審理終結日 2005-08-18 
結審通知日 2005-08-19 
審決日 2005-08-31 
出願番号 特願2000-240401(P2000-240401)
審決分類 P 1 8・ 575- Z (G09B)
P 1 8・ 121- Z (G09B)
最終処分 不成立  
前審関与審査官 松川 直樹  
特許庁審判長 津田 俊明
特許庁審判官 谷山 稔男
番場 得造
発明の名称 地図表示システム及び方法  
代理人 上村 輝之  
  • この表をプリントする

プライバシーポリシー   セキュリティーポリシー   運営会社概要   サービスに関しての問い合わせ