運営：アスタミューゼ株式会社
パナソニックで一緒に知財の仕事しませんか？
  • ポートフォリオ機能


追加

関連審決 審判1995-20192
この判例には、下記の判例・審決が関連していると思われます。
審判番号（事件番号） データベース 権利
平成17ワ1199特許権侵害差止等請求事件 判例 特許
平成16ワ24626特許権侵害差止等請求事件 判例 特許
平成18ワ19307特許権侵害差止等請求事件 判例 特許
平成17ワ 785特許権侵害差止等請求事件 判例 特許
平成16ワ4339損害賠償請求事件 判例 特許
関連ワード 冒認出願(冒認) /  承継 /  発明者 /  自然法則 /  技術的思想 /  創作性(創作) /  物の発明 /  方法の発明 /  新規性 /  公然知られ(29条1項1号) /  守秘義務 /  秘密保持義務 /  公然実施(29条1項2号) /  29条1項3号 /  頒布された刊行物 /  公開性 /  頒布性 /  進歩性(29条2項) /  周知技術 /  公知技術 /  技術的範囲 /  実施可能要件 /  技術常識 /  発明の詳細な説明 /  発明が不明確 /  実質的に同一 /  共有 /  実施料相当額 /  ライセンス /  援用権(援用) /  優先日 /  出願経過 /  参酌 /  文言解釈 /  技術的意義 /  容易に想到(容易想到性) /  意識的除外(意識的に除外) /  不存在 /  信義則 /  禁反言 /  特許発明 /  実施 /  先使用権(先使用) /  加工 /  交換 /  構成要件 /  差止請求(差止) /  侵害 /  実施料 /  不法行為(民法709条) /  営業秘密 /  同意 /  実施権 /  専用実施権 /  通常実施権 /  設定登録 /  混同 /  移転登録 /  拒絶査定不服審判 /  拒絶査定 /  拒絶理由通知 /  請求の範囲 /  変更 /  釈明 / 
元本PDF 裁判所収録の全文PDFを見る pdf
事件 平成 16年 (ワ) 17929号 特許権侵害差止請求権不存在確認請求事件
平成 16年 (ワ) 20404号 特許権侵害差止等請求事件
平成 17年 (ワ) 16706号 損害賠償請求事件
東京都千代田区＜以下略＞ 第１事件被告らの承継参加人兼第２事件原告（以下「参加人」 という ）。 株式会社ペンタくん（） 旧旧商号・滋賀丸石自転車工業株式会社（旧商号・株式会社丸石サイクル） 那覇市＜以下略＞ 第１事件脱退被 告株式会社沖縄デジタルセンター
上記２名訴訟代理人弁護士長谷川純
同 藤井陽子 東京都千代田区＜以下略＞ 第１事件脱退被 告丸石デジタル株式会社沖縄県浦添市＜以下略＞ 第３事件原 告（以下「原告Ａ」という）。 Ａ沖縄県浦添市＜以下略＞ 第３事件原 告（以下「原告会社」という）。 有限会社エン企画
上記２名訴訟代理人弁護士野口明男
同 岡田淳
同 三好豊
同 飯塚卓也 東京都目黒区＜以下略＞ 第１事件原告兼第２事件被告兼第３事件被告（以下「被告」と いう ）。 株式会社パスコ
同訴訟代理人弁護士上谷清
同 宇井正一
同 萩尾保繁
同 笹本摂
同 山口健司
同 補佐人弁理 士水谷好男第３事件被告訴訟代理人弁護士永井紀昭
同 薄葉健司
裁判所 東京地方裁判所
判決言渡日 2007/03/29
権利種別 特許権
訴訟類型 民事訴訟
主文 １参加人は，特許第２７７００９７号特許権に基づき，被告が別紙イ号方法目録@記載の方法を用いて地図データを作成することを差し止める権利，及び，被告が別紙ロ号物件目録@記載の地図データ作成装置を使用することを差し止める権利を有しないことを確認する。
２参加人及び第３事件原告らの請求をいずれも棄却する。
３訴訟費用は，参加人と被告との間においては，全部参加人の負担とし，第３事件原告らと被告との間においては，全部第３事件原告らの負担とする。
事実及び理由
全容
第1請求の趣旨1第1事件主文第1項同旨2第2事件( ) 被告は,別紙イ号方法目録A記載の作成方法若しくは別紙ロ号物件目録A1記載の装置を利用して,地図データを作成してはならない。
( ) 被告は,別紙イ号方法目録A記載の作成方法により作成された地図データ2及び別紙ロ号物件目録A記載の装置を利用・販売・頒布してはならない。
( ) 被告は,別紙イ号方法目録A記載の方法により作成された地図データ及び3別紙ロ号物件目録A記載の装置を廃棄せよ。
3第3事件( )被告は,原告Aに対し,金3億円及びこれに対する平成11年11月112日から支払済みまで年5分の割合による金員を支払え。
( ) 被告は,原告会社に対し,金7億円及びこれに対する平成16年1月222日から支払済みまで年5分の割合による金員を支払え。
第2事案の概要本件は,被告が,参加人に対し,参加人が権利者である「地図データ作成方法及びその装置」に係る特許権に基づき,被告の地図データ作成方法及び同装置を使用することを差し止める権利を有しないことの確認を求め(第1事件。
なお,第2事件とは請求の対象が異なるので,訴えの利益が認められる,。)参加人が,被告に対し,前記特許権に基づき,被告の地図データ作成方法及び装置の使用差止め等を求め(第2事件 ,第3事件原告らが,被告に対し,第 )3事件原告らが前記特許権の権利者であった期間について,特許権侵害に基づく損害賠償を求めた(第3事件)事案である。
被告は,被告の地図データ作成方法及びその装置が前記特許権の技術的範囲に含まれず,また,前記特許権には記載不備,新規性・進歩性欠如又は冒認出願の無効理由が存するので権利行使が許されず,また,被告の使用する方法及び装置について先使用権か自由技術の抗弁が成立すると主張して,前記特許権に基づく差止請求権が存しないことの確認を求めるとともに(第1事件 ,特)許権侵害に基づく差止請求(第2事件)及び損害賠償請求(第3事件)を争っている。
( , 。) 1前提となる事実 当事者間に争いがないか 後掲各証拠によって認められる( ) 当事者1原告Aは,後記特許権の発明者である。
原告会社は,原告Aを代表取締役とし,特許権の取得,保有,運用等を業とする有限会社である。
参加人は,建物・構築物の増改築等を業とする株式会社である。なお,原告A,原告会社及び参加人を総称して,以下「原告ら」といい,第3事件原告らが第3事件において提出した書証を単に「甲号証」と,参加人が第1事件及び第2事件で提出した書証を単に「丙号証」と表記する。
被告は,測量,地理情報取得,データ解析,加工,販売,地図編纂等を業とする株式会社である。被告が第3事件で提出した書証を単に「乙号証」と表記する。
( ) 原告Aの発明に係る特許権(甲1)2ア原告Aは,下記の特許権に係る発明を特許出願し,特許登録を得た(甲1。以下「本件特許」及び「本件特許権」といい,請求項1に係る発明を「本件発明1 ,請求項2に係る発明を「本件発明2」といい,本件発明 」1と本件発明2とを併せて「本件発明」という。。)特 許 番 号第2770097号登録日平成10年4月17日出 願 番 号特願平4-48706出願日平成4年3月5日優先日平成3年6月24日公 開 番 号特開平5-73659公開日平成5年3月26日発明の名称地図データ作成方法及びその装置イ原告Aは,本件特許権の登録日である平成10年4月17日から,原告会社に対する移転登録日の前日である平成11年11月11日までの間,本件特許権を保有していた(甲3 。)原告会社は,原告Aから本件特許権を譲り受け,移転登録日である平成, (, 11年11月12日から 第1事件脱退被告丸石デジタル株式会社 以下「第1事件脱退被告丸石デジタル」という )に対する移転登録日の前日 。
, ()。 である平成16年1月21日までの間 本件特許権を保有していた 甲3第1事件脱退被告丸石デジタルは,原告会社から,本件特許権を譲り受け,これを平成16年1月22日登録し,参加人(当時の商号・滋賀丸石自転車工業株式会社)は,第1事件脱退被告丸石デジタルから,本件特許権を譲り受け,同年9月29日その移転登録を受けた(甲3 。)第1事件脱退被告株式会社沖縄デジタルセンター(以下 「第1事件脱,退被告沖縄デジタルセンター というは 原告会社から専用実施権 以 」。) ,(下 「本件専用実施権」という )の設定を受け,平成14年5月8日登 , 。
録した 訴外ソブリンアセットマネジメントジャパン株式会社 以下訴 。 (,「外会社」という )は,第1事件脱退被告沖縄デジタルセンターから,本 。
,,。 件専用実施権を譲り受け 平成16年9月22日 その移転登録を受けたそして,参加人は,訴外会社から,本件専用実施権を譲り受け,同年12月7日,その移転登録を受けた。本件専用実施権は,混同を原因として,平成17年1月13日抹消登録された(甲3 。)( ) 本件特許出願の願書に添付した明細書の特許請求の範囲の記載3本件特許に係る明細書(平成12年12月12日付け審決(甲2)による訂正後のもの 以下本件明細書 という 本判決末尾添付の特許公報 甲 。,「」。 (1。以下 「本件公報」という )及び審決(甲2)参照 )の特許請求の範 ,。。
囲の請求項1及び2の記載は次のとおりである。
ア請求項1(本件発明1)「地形図等の原図を読み取って得られるラスターデータからベクトルデータを作成した後,該ベクトルデータを線端を示す点データを含む二次元の線データに変換し,それらの二次元線データを座標上の線分に変換し,該線分を所定方向に接続し,終点が始点と一致したときはそれらの線分からなる面データの閉領域データを自動的に作成し,終点が始点と一致しないときはそれらの線分からなる面データを自動的に作成して,該面データの前記不連続となる始点及び終点を報知表示し,該不連続点から任意の点又は線へ接続する線データを入力に基づいて生成することにより該面データに対応する閉領域データを作成し,上記各閉領域データに属性データを付与可能にして該閉領域データを記憶,表示又は印刷する地図データ作成方法 」。
イ請求項2(本件発明2)「地形図等の原図を読み取って得られるラスターデータからベクトルデータを作成するベクトルデータ作成手段と,該ベクトルデータ作成手段により出力されるベクトルデータを線端を示す点データを含む二次元の線データに変換する二次元線データ作成手段と,該二次元線データ作成手段により出力される二次元線データを座標上の線分に変換する線分作成手段と,該線分作成手段により出力される線分を所定方向に接続し,終点が始点と一致したときはそれらの線分からなる面データの閉領域データを自動的に作成し,終点が始点と一致しないときはそれらの線分からなる面データを自動的に作成する面データ作成手段と,該面データ作成手段が作成した面データの不連続となる前記始点及び終点を報知表示する不連続点報知表示手段と,該不連続点報知表示手段による報知表示に基づいて前記始点及び終点から任意の点又は線へ接続する線データを生成すべく該接続線データを入力する入力装置と,該入力装置による入力に基づいて前記不連続となる始点及び終点を有する面データに対応する閉領域データを作成し,上記各閉領域データに属性データを付与可能にして該閉領域データを記憶,表示又は印刷する記憶表示印刷手段と,を有することを特徴とする地図データ作成装置 」。
( ) 構成要件の分説4本件発明を構成要件に分説すると,次のとおりである(以下,それぞれを「構成要件1A」のようにいう。。)ア本件発明11A地形図等の原図を読み取って得られるラスターデータからベクトルデータを作成した後,1B該ベクトルデータを線端を示す点データを含む二次元の線データに変換し,1Cそれらの二次元線データを座標上の線分に変換し,1D該線分を所定方向に接続し,終点が始点と一致したときはそれらの線分からなる面データの閉領域データを自動的に作成し,終点が始点と一致しないときはそれらの線分からなる面データを自動的に作成して,1E該面データの前記不連続となる始点及び終点を報知表示し,1F該不連続点から任意の点又は線へ接続する線データを入力に基づいて生成することにより該面データに対応する閉領域データを作成し,1G上記各閉領域データに属性データを付与可能にして該閉領域データを記憶,表示又は印刷する1H地図データ作成方法。
イ本件発明22A地形図等の原図を読み取って得られるラスターデータからベクトルデータを作成するベクトルデータ作成手段と,2B該ベクトルデータ作成手段により出力されるベクトルデータを線端を示す点データを含む二次元の線データに変換する二次元線データ作成手段と,2C該二次元線データ作成手段により出力される二次元線データを座標上の線分に変換する線分作成手段と,2D該線分作成手段により出力される線分を所定方向に接続し,終点が始点と一致したときはそれらの線分からなる面データの閉領域データを自動的に作成し,終点が始点と一致しないときはそれらの線分からなる面データを自動的に作成する面データ作成手段と,2E該面データ作成手段が作成した面データの不連続となる前記始点及び終点を報知表示する不連続点報知表示手段と,2F該不連続点報知表示手段による報知表示に基づいて前記始点及び終点から任意の点又は線へ接続する線データを生成すべく該接続線データを入力する入力装置と,2G該入力装置による入力に基づいて前記不連続となる始点及び終点を有する面データに対応する閉領域データを作成し,上記各閉領域データに属性データを付与可能にして該閉領域データを記憶,表示又は印刷する記憶表示印刷手段と,2Hを有することを特徴とする地図データ作成装置。
( ) 本件特許権の出願経過等5ア原告Aは,平成4年3月5日,本件発明に係る特許出願をした(特願平4-48706。乙11 。)上記特許出願について,平成6年9月30日,拒絶理由通知がされた。
これを受けて,原告Aは,同年12月7日,意見書(乙1)及び手続補正書を提出したものの,平成7年8月15日,拒絶査定がされた。
イ原告Aは,平成7年9月21日,拒絶査定不服審判を請求した(平7-20192 。)原告Aは,同年10月23日,手続補正書(乙2)及び理由補充書(乙3)を提出したが,同手続補正書は,平成8年1月5日,不受理処分を受けた。その後,平成10年1月29日,特許法36条違反を理由とする拒,,,()。 絶理由通知がされ 原告Aは 前同日 手続補正書 乙10 を提出した特許庁は,同年2月23日,請求を成立させる旨の審決をし,同年4月17日,特許登録された。
ウ本件特許については,平成10年12月25日,特許異議が申し立てられた。その後,平成13年3月29日,特許を維持する旨の決定がなされた。
エ被告及び訴外日本コンピュータグラフィック株式会社外3名は,平成10年12月26日,本件特許について無効審判を請求した(平10-35672 (以下「本件無効審判事件」という。 ) 。)原告Aは,平成11年4月20日,答弁書(乙6)及び訂正請求書(乙9)を提出した。また,原告Aから本件特許権を承継した原告会社は,平成12年4月25日,意見書(乙12)を提出した。
特許庁は,平成12年12月12日,請求を不成立とする旨の審決をした(甲2 。)( ) 被告の使用する地図データ作成方法(以下「イ号方法」という )及び同6 。
作成装置(以下「ロ号物件」という )の本件発明の充足性 。
イ号方法が本件発明1の構成要件1G及び1Hを充足することには争いがない。
ロ号物件が本件発明2の構成要件2G及び2Hを充足することには争いがない。
2本件における争点( ) 被告の使用する地図データ作成方法(イ号方法)及び同作成装置(ロ号物1件)の具体的構成(争点1)( ) 被告の使用する地図データ作成方法(イ号方法)及び同作成装置(ロ号物2件)が本件発明を充足するか。
アイ号方法が構成要件1Aを充足するか(争点2-1 。)イイ号方法が構成要件1Bを充足するか(争点2-2 。)ウイ号方法が構成要件1Cを充足するか(争点2-3 。)エイ号方法が構成要件1Dを充足するか(争点2-4 。)オイ号方法が構成要件1Eを充足するか(争点2-5 。)カイ号方法が構成要件1Fを充足するか(争点2-6 。)キロ号物件が構成要件2Aないし2Fを充足するか(争点2-7 。)( ) 本件発明が特許無効審判により無効にされるべきものと認められるとし3て,特許法104条の3により権利行使が許されないものであるか。
ア本件発明が明細書の記載不備又は実施可能要件違反の無効理由を有するか(争点3-1 。)()。 イ本件発明が新規性又は進歩性欠如の無効理由を有するか 争点3-2ウ本件発明が冒認出願であるか(争点3-3 。)( ) 先使用の抗弁又は自由技術の抗弁の成否(争点4)4( ) 損害の額(争点5)5第3争点に関する当事者の主張1争点1 被告の使用する地図データ作成方法 イ号方法 及び同作成装置 ロ ( ()(号物件)の具体的構成)について( ) 被告の主張1アイ号方法の具体的構成は別紙イ号方法構成目録@記載のとおりであり(以下,被告の主張するイ号方法の構成を「イ号方法@」といい,同目録記載の (以下「社」という )Environmental Systems Research InstituteESRI 。
社製の地図を編集・加工・解析するソフトウェアを「」といARC/INFOう,ロ号物件の具体的構成は別紙ロ号物件構成目録@記載のとおりで 。)ある(以下,被告の主張するロ号物件の構成を「ロ号物件@」という。。)イ参加人の主張するイ号方法の構成(以下「イ号方法A」という )につ。
いて,以下のとおり認否する。
)構成1aないし1c,1e及び1ha認める。
)構成1db@「アークを所定方向に接続する方法によってポリゴンを作成し」は知らない。
A始点と終点が一致した場合にポリゴントポロジー,すなわち,ポリ(, ゴンの境界を構成するアークのリストを作成することは認める なお「ポリゴン(面データ)の作成」と「ポリゴントポロジー(ポリゴン)」, の境界を構成するアークのリスト の作成 では技術的意味が異なり構成要件1Dが示すのは「ポリゴン(面データ 」作成のアルゴリズ)ムであって 「ポリゴントポロジーの作成」については何ら開示して ,いない。。)B「ポリゴン作成を開始した最後のアークの終点と最初のアークの始点が一致しない場合には,その一本以上のアークのシリーズを自動的に作成する」ことは否認する 「一本以上のアークのシリーズ」とは 。
におけるポリゴントポロジー(ポリゴンの境界を構成するARC/INFO),, アークのリストないしシリーズ と解されるところでは ARC/INFO終点と始点が一致していない限り,ポリゴントポロジーは作成されない。
)構成1fc@「当該不連続点から任意のノード又はアークへ接続するアークを入力に基づき生成して当該不連続点を解消」することは認める。
A「ポリゴントポロジーを作成」することは認める(なお 「ポリゴ,ン(面データ)の作成」と「ポリゴントポロジー(ポリゴンの境界を構成するアークのリスト)の作成」では技術的意味が異なり,本件発「 」 。)。 明は ポリゴントポロジーの作成 については何ら開示していないBポリゴンに内部番号を付与することは認めるものの,内部番号が,本件発明の構成要件と対比する上で,どのように関わってくるのか不明である。
)構成1gd認める。ただし,イ号方法は,最初からラベルポイントを手動で入力しておき,コマンドは使わない方法も可能である。
CREATELABELSウ参加人の主張するロ号物件の構成(以下「ロ号物件A」という )につ。
いて,以下のとおり認否する。
社製のソフトウェアである「」と,社AUTODESK Auto Desk MapESRI製のソフトウェアである「」又は「」を利用した,地図 ARC/INFOArcGISデータ作成装置であることは認める。それが,イ号方法Aの方法を組み込んだものであることは否認する。
(「」。) エ第3事件原告らの主張するイ号方法の構成 以下 イ号方法B というについて,以下のとおり認否する。
)構成1aa認める。
)構成1b b認める。
)構成1cc認める。ただし,イ号方法において同構成が実施されるのは,未入力の交点が存在する場合に限られる。
)構成1ddイ号方法がのコマンドを用いることは認める。 ARC/INFOCLEANイ号方法が「線分を所定方向に接続」しているか否かは知らない。
のポリゴン作成の具体的アルゴリズムは,社の企業秘ARC/INFO ESRI密であり,被告にも開示されていない。
構成1dのその余は否認ないし争う。なお,イ号方法は,終点と始点が一致したときにのみポリゴン(面データ)を作成し,終点と始点が一致しないときは,ポリゴン(面データ)は作成されない。
)構成1eeイ号方法がのコマンド又はの ARC/INFONODEERRORSARCEDITコマンドを用いて,ダングリングノード(不連 DRAWENVIRONMENT続で接続されていない端点)を報知表示することは認め,その余は否認ないし争う。
)構成1ffイ号方法がの用意した修正用のコマンドを用いて,不連続 ARCEDIT点(ダングリングノード)から任意の点又は線へ接続する線データを入力に基づいて生成すること,及び,のコマンドを用ARC/INFOCLEANいることは認め,その余は否認ないし争う。
)構成1ggイ号方法がのコマンドを用いることは ARC/INFOCREATELABELS認め,その余は否認ないし争う。
(「」。) オ第3事件原告らの主張するロ号物件の構成 以下 ロ号物件B というについての認否は,イ号方法Bについての認否と同様である。
( ) 参加人の主張2ア被告は,別紙イ号方法目録A記載の地図データ作成方法(イ号方法A)を使用するとともに,別紙ロ号物件目録A記載の地図データ作成装置(ロ号物件A)を使用している。その具体的構成は,別紙イ号方法目録A及び別紙ロ号物件目録A記載のとおりである。
イ被告主張のイ号方法の構成(イ号方法@)について,以下のとおり認否する。
)構成1aないし1c,1e及び1ha認める。
)構成1db否認する。
@のマニュアルに 「アークを所定方向に接続する方法」ARC/INFO ,を採用していることが記載されている。
Aアークのシリーズでポリゴンを形成しようとするとき,その最後のアークの終点と最初のアークの始点が一致しない場合であっても,最初のアークから最後のアークの終点が一致しないことを確認するために,アークを所定方向に接続することで,面データ自体の作成が試みられるのであって,たまたま未完に終わった面データを属性情報を記憶するためのテーブルに保存していないということにすぎない。
)構成1fcのコマンド又はコマンドを用いてトポロ ARC/INFOCLEANBUILDジーを形成し,その境界のアークのシリーズでポリゴンを定義しているのであって,ラベルポイントでポリゴンを定義しているわけではない。
)構成1gd否認する。
構成1fの認否で主張したとおり,イ号方法ではラベルポイントでポリゴンを定義しているわけではないので,1fまでの段階でラベルポイントの入力を必要としない。したがって,イ号方法@の構成1gの「ラベルポイントが未入力の場合には」との表現は,予めラベルポイントが入力されていることを前提とするもので,イ号方法の構成と矛盾する。
ウ被告主張のロ号物件の構成(ロ号物件@)についての認否は,前記イと同様である。
( ) 第3事件原告らの主張3被告は,遅くとも本件特許権が設定登録された平成10年4月17日までに,別紙イ号方法目録B記載の地図データ作成方法(イ号方法B)を使用す, 。 るとともに 別紙ロ号物件目録B記載の地図データ作成装置を使用しているその具体的構成は,別紙イ号方法目録B及び別紙ロ号物件構成目録B記載のとおりである。
2争点2-1(イ号方法が構成要件1Aを充足するか)について( ) 原告らの主張1アベクトルデータの入力方法について)ベクトルデータの入力方法には,以下の方法がある。
a@デジタイザによる入力予め人手により,アーク番号,ノード番号,ポリゴンID及び補間点等を指定した計測基図を作成し,その計測基図をデジタイザに貼り付けて,入力者が計測基図に沿ってデジタイザカーソルをノード上や補間点上に移動し,アーク番号とノード番号,ポリゴンIDを入力しながら,手作業により一つ一つ閉じた面データを入力する手法Aオンスクリーン入力図面をスキャナーで読み込むことによって得られたラスターデータをディスプレイ画面上に表示させ,地図データの端点・頂点等をクリックすることによってデータ入力する手法(面データの作成を伴わない )。
B半自動入力方式図面をスキャナーで読み込むことによって得られたラスターデータをディスプレイ画面上に表示させ,地図データ上の入力したいラインの開始点等をクリックすることにより,コンピュータがラスターデータのラインを自動的に識別し,当該ラインの点を適当な間隔で自動的に取得する方法(面データの作成を伴わない )。
C自動入力方式図面をスキャナーで読み込むことによって得られたラスターデータをコンピュータ処理によって自動的にベクトルデータに変換する方法(面データの作成を伴わない )。
)オンスクリーン入力とデジタイザによる入力の相違点bオンスクリーン入力とデジタイザによる入力とは以下の点で大きく異なっている。
@デジタイザによる入力においては,データ入力に先立ち,入力に使用する複雑な計測基図を正確に作成することが必要とされ,この計測基図の作成に多額の人件費を要する。これに対し,オンスクリーン入力によるデータ入力においては,デジタイザ入力のような複雑な計測基図の作成はなされておらず,原図とほぼ同様の図面がラスターデータとして用いられている。なお,デジタイザによる入力に際し予め計測基図を作成するのは,ノードの入力やノード番号・ポリゴンID等の様々な情報の入力が必要とされる(ただし,デジタイザの種類により若干違いがあり得る )ために,データ入力を行う作業者が円滑に 。
作業できるようにするためである。これに対し,オンスクリーン入力に際しては,ラスターデータをクリックすれば足り,デジタイザによる入力のようなノード番号やライン番号,ポリゴンIDのような情報の入力は不要であるから,複雑な計測基図の作成は必要とされない。
Aまた,データ入力に際し,デジタイザによる入力では,各ノードに, , つきノード番号の入力が必要とされ また各ラインにつきライン番号始点・終点のノード番号,ラインの左右に位置するポリゴンのIDといった様々な情報の入力が必要とされる(ただし,デジタイザの種類により若干違いがあり得る。これに対し,オンスクリーン入力は 。)単にラスターデータのマップフィーチャーの頂点等の上にマウスカーソルを移動させた上でマウスをクリックすれば足り,ノード番号等の情報の入力を必要としない。
これらの相違点により,オンスクリーン入力は,従来技術として本件発明の技術的範囲から除外されるデジタイザによる入力よりも飛躍的に簡便なデータ入力方式となっており,デジタイザによる入力とは全く異なるデータ入力方式である。
イ構成要件1Aにおけるラスターデータからベクトルデータを作成する手法には,自動入力方式のみならず半自動入力方式及びオンスクリーン入力も当然に含まれる。なお,従来技術であるデジタイザによる入力は,これに含まれない。
)請求項の文言上,構成要件1Aにはオンスクリーン入力が含まれるこaとについて構成要件1Aの「作成」という用語の通常の語義からして,ラスターデータからベクトルデータを作成する手法は自動入力方式に限定されない。すなわち 「作成」の意味は「つくりあげること」程度の意味であ ,るにすぎず(広辞苑 ,その手法について何らかの限定を加える意味は )存在しない。
さらに,本件特許権の請求項において 「作成」と「変換 ・ 自動的 ,」「に作成」とは区別して用いられており,これらの語の使用法に着目すれば,構成要件1Aが手動によるオンスクリーン入力を除外するものでないことは明らかである。
, , すなわち 本件特許権の請求項に記載された各データ処理過程のうち作業者による手作業の介在なくコンピュータにより自動的に処理されることが予定されたデータ処理過程については 「変換」ないし「自動的 ,に作成」の語が用いられている(構成要件1B「ベクトルデータを・・」,「 」, ・二次元の線データに変換同1C 線データを座標上の線分に変換同1D「閉領域データを自動的に作成。これらに対し,構成要件1 」)Aには「作成」の語が用いられているのみであり,データ入力方式を自動入力方式に限定する余地はない。
実際,構成要件1Aと同様にデータ処理過程に手作業が介在することがあり得る構成要件1Dには「該不連続点から任意の点又は線へ接続する線データを入力に基づいて生成することにより面データに対応する閉領域データを作成して 」と記載されている。この点からも 「変換 , , ,」「自動的に作成」及び「作成」の用語は区別して使用されていることが明らかであり,構成要件1Aの文言解釈ないし文理解釈として,データ入力方法は自動入力方式に限定されると解することはできない。
このように,請求項において 「作成」という用語は 「変換」ない ,,し「自動的に作成」という用語と明確に区別して使用されていることは明らかであり,作業者による手作業が介在し得ることも予定されている場合に,単なる「作成」という用語が使用されるのである。
したがって,構成要件1Aにおいても作業者の手作業が介在することも予定されているのであって 「ラスターデータからベクトルデータを ,作成」する手法にはオンスクリーン入力も含まれるというべきである。
)当業者の認識について b@加えて,構成要件1Aに接した当業者は,構成要件1Aをオンスクリーン入力をも予定したものとして理解する。なぜなら,本件発明の出願時においても,オンスクリーン入力も当業者にとってラスターデータからベクトルデータを作成するための一般的手法の一つだったのであり 「ラスターデータからベクトルデータを作成」との記載を見 ,た当業者であれば,オンスクリーン入力による実施を除外して解釈することはあり得ないからである。
, , Aまた ラスターデータからベクトルデータを取得する方法としては自動入力方式,半自動入力方式及びオンスクリーン入力等が相互に併用ないし一環として利用されるのが通常であるところ 「ラスターデ,ータからベクトルデータを作成」する手法をことさらに分類・区別した上で,あえて自動入力方式のみに限定されると解釈することは,当業者にとっても極めて不合理な解釈である。
すなわち,自動入力方式,半自動入力方式及びオンスクリーン入力方式の各方法はそれぞれ長所,短所を有しているため,出願当時はもとより,現在においてもなお,ラスターデータからベクトルデータを作成するにあたりこれらのいずれかだけを単独で用いることはむしろ少なく,相互補完的に併用されるのが通常である。例えば,自動入力方式のみによってエラーのないベクトルデータを得ることは未だにほぼ不可能であり,通常は,得られたベクトルデータに含まれるエラーを,例えば自動入力方式のシステムに組み込まれたオンスクリーン入力装置等によって修正する作業が当然に行われている。このように,自動入力方式は,半自動入力方式及びオンスクリーン入力と相互に併用して,あるいはこれらと組み合わされた一つのシステムとして地図作成に利用されることが通常であることは当業者の一般認識である。
オンスクリーン入力方式を含め各方式を相互に併用することが通常であるとの当業者の一般認識からすれば,構成要件1Aの「ラスターデータからベクトルデータを作成」との文言は,いわゆるラスターデータからベクトルデータを取得する方法全般を指すものと解されるはずであり,自動入力方式のみによるデータ入力を意味するものとは解されない。
実質的に考えても,ラスターデータからベクトルデータを作成する手法は,ラスターデータを用いてベクトルデータを作成する点を共通項とする以外はその区別もごく相対的なものにすぎず,厳密にどこまでが自動でどこからが半自動であり,あるいは手動かなどを区別すること自体不可能ですらある。
したがって,構成要件1Aを「ラスターデータから自動的にベクトルデータを作成する」との意味に限定解釈することは,文言に反するのみならず,当業者の常識に照らしても不自然というほかない。
ウイ号方法の構成1aはオンスクリーン入力に他ならないので,構成要件1Aを充足する。
( ) 被告の主張2アベクトルデータの入力方法についてベクトルデータの入力方法を「デジタイザによる入力「オンスクリ」,ーン入力「半自動入力方式」及び「自動入力方式」の四つに分類する 」,ことは認め,各入力方法の定義については否認する。特に,原告らによる「デジタイザによる入力」の定義は明らかに虚偽ないし誤解を含んだものであり,到底認められない。デジタイザによる入力とオンスクリーン入力とで異なる点は,トレースする対象が紙の地図かラスターデータかという点のみである。
)オンスクリーン入力の場合にも,デジタイザによる入力の場合と同程a度の計測基図の作成が必要である(なお,その際に,ノード番号,ライン番号等の情報の記載は不要である。ちなみに,自動入力方式及び 。)半自動入力方式についても,計測基図の作成を要する。
デジタイザ入力の場合には計測基図をそのままデジタイザ板に貼り付けてトレース作業を行うのに対し,オンスクリーン入力の場合には該計測基図を一旦ラスターデータとして取り込み,スクリーン上に表示した当該ラスターデータに対してトレース作業を行う点で異なるのみである。
)データ入力の際にいかなる情報を入力する必要があるか(その前提とbして,計測基図にいかなる情報を書き込んでおく必要があるか)は,デジタイザによる入力かオンスクリーン入力にかによって異なってくるものではなく,地図データの加工・編集・解析用ソフトとしてどのソフトウェアを用いるかによるものである。そして,を地図データARC/INFOの加工・編集・解析用ソフトとして用いた場合には,入力方法としてデジタイザ入力を選んだとしても,少なくとも原告らが例示するノード番号,各ラインにつきライン番号,始点,終点のノード番号,及びラインの左右に位置するポリゴンのIDの入力は不要である。
)オンスクリーン入力は,トレース作業をかける対象をスクリーン上にc表示されたラスターデータとすることによって,基図と入力データの双方を見ながら入力する必要をなくしたことによって入力効率を上げようという発想である。一方,本件発明は,トレース作業自体を省こうという発想であって,両者は技術的思想が全く異なる。したがって,本件発明からみれば,オンスクリーン入力も,デジタイザ入力と同様に,本件発明によって克服すべき課題(トレースという手数のかかる手作業が必要であるという課題)を依然包含したままの従来技術にすぎないから,, , 本件発明との対比の上では デジタイザ入力とオンスクリーン入力とは実質的に同一と評価されるものである。
イ構成要件1Aの「ラスターデータからベクトルデータを作成」との文言は,本件明細書の記載及び本件特許権の出願経過における出願人の意見などを参酌すれば 「ラスターデータから自動的にベクトルデータを作成す ,る」ことを意味しているとしか解せないものであり,少なくとも,デジタイザ入力やイ号方法のようなオンスクリーン入力のように,手動でトレースする作業が必要なベクトルデータの入力方法は,本件発明の技術的範囲から意識的に除外されているものである。
)@本件明細書の記載をみれば,構成要件1Aの「ラスターデータからaベクトルデータを作成」は自動入力方式に限定されることは明らかである。
すなわち,本件明細書の発明の詳細な説明は,手動入力方式について「上述のデジタイザによる面データの入力作業は熟練を要し,極めて手数のかかる作業である。従って,人件費が地図情報作成コストの50%以上,ときには90%以上を占めるとさえいわれ,その総体的費用は極めて高価である( 0006 )と述べ,従来技術の問題 。」【】点を「このように,従来は,地図データの輪郭線データを手作業で入力しなければならず ・・・一貫して自動的に地図情報を作成する方 ,法も装置も存在しなかった 」とし( 0008,本発明の目的を 。【】)「本発明は,上記従来の実情に鑑みてなされたものであり,その目的とするところは,地域や地点毎に属性を付与可能なように保存した地図情報を大幅に効率良く自動的に作成することが容易にできる地図データ作成方法及び装置を提供することである 」とし( 0009, 。【】)本発明の効果を「本発明によれば,地形図等の原図を読み取って自動的に作成されたベクトル線データを面データに変換し,その不連続部を修正して閉領域データを作成することが迅速かつ容易にできるので ・・・地図情報制作の費用を大幅に削減することが可能となる 」 , 。
と記載している( 0046。このとおり,本件明細書の記載は, 【】)「 」 地形図等の原図を読み取って自動的に作成されたベクトル線データ( 0046,すなわち「自動入力方式」により取得されたベクト 【】)ルデータから面データを作成することを当然の前提としているのである。また,実施例には自動入力方式の記載しかなく( 0012,【】)オンスクリーン入力や半自動入力の記載が一切ない。
上記の明細書の記載からすれば,本件発明の目的及び効果が,膨大な手間のかかるデジタイズという手作業を排除して,地図情報作成費を削減する点にあることは明白であるから 「手動入力方式」が本件 ,発明の技術的範囲に含まれると解釈することは,本件明細書の記載にある発明の目的・効果と完全に矛盾するので,そのような解釈は採り得ないのである。
Aデジタイザ入力であろうが,オンスクリーン入力であろうが,自動入力であろうが,ベクトルデータを取得した後の処理は,本件発明の出願時以前から,全く同じである(少なくともARC/INFOではそうである。ARC/INFOを用いた場合には,どの入力方法を用いた場合であっても,ベクトルデータをカバレッジとして取り込んだ後は,CLEANの実行など同じ処理をすることになる。人手による作業量が異なるの 。), 。, は ベクトルデータを入力する段階しかないのである そうであれば本件明細書の「自動的」との用語は,ベクトルデータを入力する過程についての言及としか考えられない。
したがって,本件明細書の「自動的」との用語は,デジタイザによる入力(及びオンスクリーン入力)において必要なトレース作業(x,y座標を取得する点を1点1点カーソルないしマウスでクリックする) 。 作業 を必要としない状態を表しているとしか解することができないB本件明細書には,自動入力方式を前提とした実施例の記載( 00【12 )があるのみで,それ以外の入力方式が本件発明に適用できる 】ことを具体的に示した記載は存在しない。他の入力方法を適用した場合と自動入力方式を適用した場合との効果の相違を比較した記載も,当然存在しない。このとおり,本件には,自動入力方式以外の入力方式を適用した場合の記載及びそれと自動入力方式を適用した場合との効果の相違についての記載は存在しないのであるから,本件明細書の【発明の効果】欄の記載( 0046 )が「本件発明と自動入力方 【】式とを組み合わせた際に最も大きな効果を発揮するという趣旨」であるはずがない。
加えて,一部の実施例のみが奏する効果を特許発明そのものの効果として主張できないことは当然であることからしても,本件発明そのものの効果を記す本件明細書の【発明の効果】欄の記載が 「本件発,明と自動入力方式とを組み合わせた際に最も大きな効果を発揮するという趣旨」であるはずがない。
C本件明細書には,出願時のデジタイザ入力の状況( 0004,【】)出願時の自動入力の状況( 0005,出願時のデジタイザ入力の 【】)問題点( 0006,出願時の自動入力の問題点( 0007, 【】) 【】)両入力方法の状況・問題点,従来存在しなかった方法(一貫して自動的に地図情報を作成する方法)の提示( 0008,本件発明の目 【】)的(上記従来存在しなかった方法の提供 ( 0009 )が記載され )【】ている。
上記のとおり,本件発明は,従来のデジタイザ入力の欠点(手作業であること)と,従来の自動入力の欠点(属性付与ができないこと)を同時に解決したもの,すなわち 「自動入力で,且つ,属性付与可 ,能な面データを作成できる方法」を開示するものであることは明らかである。
Dデジタイザ入力との関係のみで本件発明を見れば,本件発明はデジタイザ入力の「手作業で地図上の区域や地点の縁に沿って入力端末を移動させ,この入力端末の移動データを区域や地点の輪郭線を表す面データとしてコンピュータに入力」する状況( 0004「地図【】),の輪郭線データを手作業で入力しなければなら」なかった状況( 0【008 )を改善したものであり,本件発明の本質が,この点にある 】ことは明白である。
そして 【0004】のいう「手作業で地図上の区域や地点の縁に ,沿って入力端末を移動」する作業,及び 【0008】のいう「地図 ,データの輪郭線データを手作業で入力」する作業とは,まさに「トレース作業(マップフィーチャーの座標を取得する点を1点1点カx,yーソルないしマウスでクリックする作業 」のことを指していること )も,明らかである。
このとおり,本件発明の本質は,自動入力を用いて属性付与可能な面データを作成できる方法を提示した点にあり,すなわち,デジタイザ入力で必要とされたトレース作業を排した点にあることは明らかである。
E原告は 「本件発明は,従来不可能であったベクトルデータから面 ,データへの自動的なデータ変換を可能にすることにより,デジタイザによる面データ入力作業を経ずに面データの入力ができるようにしたものであり,本件発明の本質はこの点にある 」と主張する。。
しかし 本件明細書にはそのような記載は存しない そもそもベ , 。,「クトルデータから面データへの自動的なデータ変換」という点は,本件特許権の優先日前から,ARC/INFOが実現していた点である。すなわち 「ベクトルデータから面データへの自動的なデータ変換」とは, ,構成要件1Bないし1Dに対応するものであり,構成要件1BはARC/INFOのDXFARCコマンド等,構成要件1C及び1DはARC/INFOのCLEANコマンドで,既に実現済みである。
このように,従来技術において既に実現されていた点が,新規な技術上の創作であるべき特許発明の本質になり得るはずがない。
)平成6年9月30日付拒絶理由通知書に対する出願人の平成6年12b月7日付意見書において,出願人(原告A)は,本件発明は「イメージスキャナから得られるラスターデータから自動的に二次元のベクトル線データ及び点データを作成」するものであると説明している。
同意見書は,@本件発明が「デジタイザによる煩雑な入力や原図をトレースする手数をかけることなく,面データを作成」するものであると明確に述べており,さらに,A本件発明において人手を要する作業についてはその旨をきちんと説明している( この表示に基づいてオペレー 「タが正しい接続線を入力し」との記載参照 。これらの点を踏まえて同 )意見書の上記記載を読めば 同記載における 自動的に との文言が 全 ,「」「く人手(デジタイズないしトレースする作業)を介さないで」という意味であり,また,同記載全体の意味が「ラスターデータから(ベクトルデータを作成し,それから)二次元のベクトルデータを作成するまでの全過程を 『自動的に ,すなわちデジタイズないしトレースするとい ,』う手作業を介することなく作成する」という意味であることは明白である。
)拒絶査定不服審判(平成7年審判第20192号)における平成7年c10月23日付手続補正書及び同日付審判理由補充書においても,出願人(原告A)は,本件発明は「人手によりトレース入力することなく自動的に作成する」ものであると説明している。
前記審判理由補充書が引用する「経済的な地図情報システムにむけての**の挑戦」には 「ディジタイザの上に入力原稿を張り付ける替わ ,, 」 りにスキャナーで入力し ディスプレイ上でディジタイズするシステムが紹介されているところ,このシステムの入力方式は,まさにイ号方法と同じである。この入力方式に対して,出願人(原告A)は 「本願発,明は,原図をトレースするものではありません 」と述べ,本件発明の 。
入力方法とは異なる旨述べているのである。
このとおり,少なくともイ号方法のような入力方式(ディスプレイ上のラスターデータをデジタイズする入力方式)が本件発明の技術的範囲から意識的に除外されていることは明らかである。
,()d)福岡高裁平成14年(ネ)第31号事件は 当該事件の被告 被控訴人の地図データ作成方法が,本件特許権を侵害するか否かにつき,当該事件の被告と原告会社との間で争われた事件である。この事件において,原告会社は,当該事件の被告(被控訴人)のベクトルデータの購入先である株式会社きもとの使用した製品は「スキャナ読込みによる面データ自動作成の機能を備えているものであり,これが株式会社きもとの ,」データ入力方法である旨主張していた。これに対し,福岡高裁平成15年11月25日判決は 「株式会社きもとが原告会社主張の方法(スキ ,ャナを用いて原図から読み取ったラスターデータをベクトルデータに自動的に変換する方法)を使用していたとの事実を認めるに足りる証拠はない 」と判示している。上記原告会社の主張は,本件発明のデータ入 。
力方法が「ラスターデータをベクトルデータに自動的に変換する方法」であることを前提とするものであり,また上記判決も同様である。
また,上記判決の認定するように,本件発明の本質は 「デジタイズ,(トレース)という熟練を要する手作業を排して地図作成の時間を短縮した」点にあるのであるから,本件発明の技術的範囲に,イ号方法のようなデジタイズないしトレースという手作業を要する入力方式を用いるものが含まれると解釈するのは背理である。
)原告Aが,本件無効審判事件において,本件発明の効果を証する証拠eとして提出した「乙第3号証:地図データの入力方式」は 「地理情報,システムの問題点」を「いかに安い経費で地図を入力するかが地理情報システムの問題となっている 」と述べた上で(4頁 ,現在使用され 。)ている地図入力の方式として「手動入力方式「半自動入力方式「自 」,」,動入力方式」を各々説明し(5ないし7頁 ,それから「N方式」を説 )明し(8頁 ,前三者を「現行方式」とまとめた上で「N方式」との工 )程を比較した表を示し(9頁 ,続いて4方式の作業時間を比較し 「N ) ,方式は,現行方式に比較して作業時間が劇的に減少している 」と述べ。
(10頁 ,さらに現行方式と「西方式 (N方式)の経費を比較し, ) 」現行方式円,西方式円と算定した上(11頁 ,最後1,500,00070,200 )に結論として「地図入力の経費のほとんどは人件費である。したがって入力経費を削減するには人的な作業時間を減らすことである。当然『手動入力『半自動入力『自動入力』の順で作業時間は減少する。つ 』,』,まり,地図入力の経費削減の方法として『自動入力』が有効である。しかしながら,現在『自動入力』を実作業に取り入れているところは以下。。『』 のような基本的な問題を抱えている ・・・ N方式は 自動入力方式の基本的な問題点をすべて解決している。N方式と現在の自動入力方式との相違点は以下の3点である ・・・。以上,N方式は従来方式に比 。
『』『』 。」()。 較して 経費精度 ともに格段の進歩があると述べる 12頁上記「N方式」ないし「西方式」の「N」及び「西」が本件発明の発明者である原告Aを示していることは明らかであること,上記書面の示す「地図データ入力にかかる経費の削減」という課題が本件発明の解決すべき課題と同じであること( 0006,及び,上記書面では 「N 【】),方式」ないし「西方式」を採用したことで同課題が解決したとされていることからすれば,上記書面の「N方式」ないし「西方式」は,本件発明の一実施例などではなく,本件発明そのものを意味していること,及び,本件無効審判事件当時の本件特許権者も 「N方式」が本件発明そ ,のものを意味することを前提に上記書面を提出したことは明白である(そもそも,上記書面の「N方式」の説明は,一実施例というにはあまりに記載が抽象的である。。)そして,上記書面の記載により,本件発明は従来の自動入力方式の問題点を改善したものであるという本件発明の位置づけが明らかにされて, , いるので 本件発明の構成要件1Aが自動入力方式に限定されることは上記書面からも明らかである。
)「発明」の定義に照らせば,自動入力方式を規定したものと解さざるfを得ない。
「発明」とは 「自然法則を利用した技術的思想の創作のうち高度の ,もの」をいう。したがって 「人間の精神活動」に該当するものは 「自 , ,然法則を利用したもの」とはいえず 「発明」に該当しない。 ,仮に,構成要件1Aに,自動入力のみならず手動入力及び半自動入力も含まれるとすれば,本件発明は単なる「人間の精神活動」ということになり 「発明」に該当しないことになる。なぜなら,手動入力も半自 ,動入力も,ベクトルデータを作成するに当たってオペレーターの判断が介在するものだからである。
)本件発明2は,装置の発明(物の発明)である以上,そこに人間の精g神活動が介在してはならないはずである。よって,構成要件2Aの「地形図等の原図を読み取って得られるラスターデータからベクトルデータを作成する手段」は,明らかに自動入力方式のみを規定していることになる。このことは,同手段に相当する実施例の説明( 0012 )が【】自動入力方式の説明をしていることからも明らかである。
したがって,構成要件2Aにそのまま対応する本件発明1の構成要件1Aも,自動入力方式しか含まれないことは明らかである。
以上のとおりであるから,構成要件1Aは「ラスターデータから自動的にベクトルデータを作成」すること,すなわち自動入力方式に限定されることは明らかである。これと異なる解釈を原告らが主張することは,出願, 。 経過における出願人の意見等に照らせば 禁反言の法理に反し許されないまた,仮に自動入力のみならず,手動入力及び半自動入力をも含むとすれば,本件特許権は記載不備により無効である。
ウ構成要件1Aは自動入力方式に限定されるものであるから,自動入力方式でないイ号方法の構成1aは,同構成要件を充足しない。
( ) 被告の主張に対する原告らの反論3ア「ラスターデータからベクトルデータを作成」との文言を「ラスターデータから自動的にベクトルデータを作成する」との意味に限定解釈すべきとの被告の解釈は誤りである。
)本件明細書の【0001【0008【0009【0046】のa 】,】,】,,「 」 記載は いずれも ラスターデータからベクトルデータを作成する方法(構成要件1A)を限定するものではない。
@本件発明の最大の画期性は,座標点列にすぎないベクトルデータを「アーク・ノード構造」を有する線データに変換してなARC/INFOどに処理させることにより,面データの作成をベクトルデータの段階から大幅な自動化をもって一貫してできるようになったという点にある。すなわち,本件発明は,ラスターデータからベクトルデータを作成する従来技術と,において見られたポリゴン作成機能のARC/INFO技術を架橋し,ベクトルデータから二次元の線データの変換を自動化するという,当時存在しなかった発想及び技術に基づき完成したのである。
したがって,本件明細書においては,デジタイザを利用して原図を人手によりトレースし,アーク,ノード,ポリゴンユーザIDをのカバレッジデータとして直接入力するような従来技術とARC/INFO本件発明を対比するために 「自動的」との用語を総括的に用いてい ,るのであり,地図データ作成のすべての工程において人手による作業を含まないことを意味するものではない。現に,被告指摘にかかる本件明細書の前記各記載をみても,従来技術である「ラスターデータからベクトルデータを作成する方法」そのものを自動入力方式に限定するような記載は一切存在しない。
A本件明細書の【0001【0008【0009】に記載され 】,】,「」,「 」 た 自動的 の文言はラスターデータからベクトルデータを作成する手段については何ら述べておらず,ベクトルデータ作成の手法を限定する根拠とはならない。すなわち,当該「自動的」の文言は「地図情報の作成」に係っていることから明らかなとおり,原図の読み取りから閉領域データの作成・記憶に至るまでの一連の作業について述べたものである。本件明細書では,かかる一連の作業について,従来技術であるデジタイザを用いた手作業による面データの入力と本件発明の手法とを対比する趣旨で「自動的」との用語が用いられているのであり,ラスターデータからベクトルデータを作成する個別的な過程について何ら述べるものではない。また 【0046】には,ベクト ,ルデータを「自動的に」作成するものと記載されている。しかし,これは本件発明と自動入力方式とを組み合わせた際に最も大きな効果を発揮するという趣旨で「発明の効果」として挙げたものであるから,やはり本件発明の権利範囲が自動入力方式に限定されることを示したものではなく,被告の主張は失当である。
B本件発明は,従来行われてきたデジタイザによる面データの入力が非常に手間のかかる入力方法であったことを踏まえ,面データの入力に要する労力を軽減することを目的とする( 0009。このこと 【】)は,本件明細書上,従来技術の問題点として面データの入力作業が手数のかかる作業であることが明確に指摘されていることからも明らかである( 0006。【】)そして,かかる目的実現の手段として,本件発明は,デジタイザによる面データの入力を経ずにベクトルデータから自動的に面データを発生させることを可能にしたものである( 0010。すなわち, 【】)本件発明は,従来不可能であったベクトルデータから面データへの自動的なデータ変換を可能にすることにより,デジタイザによる面データ入力作業を経ずに面データの入力ができるようにしたものであり,本件発明の本質は 「ベクトルデータから面データへの自動変換」を ,可能にしたことにある。したがって,自動入力方式を利用しようが,「オンスクリーン入力」を利用しようが 「ベクトルデータから面デ ,ータへの自動的なデータ変換」という本件発明の本質を利用する以上は,その技術的な範囲に含まれるものである。
これに対し,被告はトレース作業を排したことが本件発明の本質で。, , ある旨主張する しかし 本件明細書にそのような記載は全くないしトレース作業を排しつつベクトルデータを取得する方法は従来から確立されていた技術であって( 0005,そのような点が本件発明 【】)の本質となるはずがない。
以上より,本件発明の本質に照らしても,構成要件1Aは「オンスクリーン入力」を除外するものではない。
)平成6年9月30日付拒絶理由通知書に対する出願人の平成6年12b月7日付意見書の記載における「イメージスキャナから得られるラスターデータから自動的に二次元のベクトル線データ及び点データを作成した上で」との記載は,限定解釈の根拠とならない。
上記記載は,その文言からも明らかなとおり 「二次元のベクトル線 ,データ」が自動的に作成されることを示しているのであって,構成要件1Aで示されている「一次元のベクトルデータ」を作成する手法については何ら述べていない。したがって,上記記載を根拠に「一次元のベクトルデータ」を作成する手法が自動入力方式に限定されると解釈することは不可能である。
また,同意見書の「本件発明は原図をトレースするものではありません 」との記載は,本件明細書で従来技術として示されたデジタイザに 。
よる入力との比較による進歩性を述べたものであるところ,そこで用いられた「原図をトレース」の語は,デジタイザによる入力にあたって必要な計測基図の作成作業を意味する趣旨で用いられたものである。すなわち,デジタイザによる入力にあたって計測基図の作成行為は「トレース」作業と称されており,上記記載は,あくまでデジタイザによる入力の場合に必要とされていた複雑な計測基図の作成が本件発明により不要になったことを意味している。
被告は 「本件発明において人手を要する作業を示す際には,人手を ,要する旨をきちんと説明している 」旨主張する。しかし,不連続点の 。
修正作業につき人手を要する旨が説明されているからといって,説明のないそれ以外の作業がすべて人手を介さないで行われると解釈することはできない。
)拒絶査定不服審判(平成7年審判第20192号)における平成7年c10月23日付手続補正書及び同日付審判理由補充書における,本件発明が「人手によりトレース入力することなく自動的に作成する」ものであるとの記載は,限定解釈の根拠とならない。
上記記載は,その前の「紙面に印刷された原図をディジタイザでなぞって個々の閉領域面データを入力していた作業を,表示画面上の線描画をトレースして行うようにしたもの」に引き続く記述であり,当該記述から明らかなとおり,該当部分を含む一連の記述は「閉領域面データの入力」方法につき述べたものである。すなわち,被告の指摘する記述の趣旨は 「本願発明は,原図をトレースする(ことにより閉領域面デー ,タを入力する)ものではありません 」というものであり(なお,本件 。
発明では後の処理で面データが自動作成される,ベクトルデータの。)作成方法には何ら言及していないから,当該記述を根拠にベクトルデータの作成方法を限定解釈することは許されない。
)福岡高裁平成14年(ネ)第31号判決は,デジタイザを利用して原図dを人手によりトレースし,アーク,ノード,ポリゴンユーザIDをのカバレッジデータとして直接入力するような場合が本件発ARC/INFO明に該当しないという当然の事実を明らかにしたものにすぎず,同判決中に本件発明の構成要件1Aの限定解釈を認める記載は一切存在しない。
)本件明細書及び地理情報システム構築支援事業研究委員会作成に係るe「地図データの入力方式」には,本件発明が「地図データの入力方式」に記載されている「N方式」に限定されるなどという記載は一切存在しない 「N方式」は本件発明の一実施例にすぎないのであって,本件発 。
明が「N方式」のみに限定されることはない。原告は,本件無効審判事件において,本件発明を最も効果的な形で(自動入力方式と組み合わせて)利用すれば,相場の22分の1の破格の低価格を実現することができるという事実を強調するために前記文書を提出したのであって,本件発明の構成がN方式に限定されると主張する趣旨でないことは明らかである。
)特許庁の審査基準第U部第1章1.1.( )は 「発明を特定するためf 4 ,の事項に自然法則を利用していない部分があっても,請求項に係る発明,, が全体として自然法則を利用していると判断されるときは その発明は自然法則を利用したものとなる 」と規定し,全体として自然法則を利 。
用していると評価できればむしろ発明性が存在することを明確にしている。
したがって,本件発明の一部を構成する構成要件1Aに手動入力及び半自動入力が含まれると解した場合であっても,構成要件1Aないし1Hからなる本件発明が全体として自然法則を利用しており,発明性が失われるわけではないことは明らかである。
以上のとおりであるから,構成要件1Aは,作成方法が完全に自動的であると,半自動的であると,手動であるとを問わず,いずれの入力方式も含むものである(なお,デジタイザを利用して原図を人手によりトレースし,アーク,ノード,ポリゴンユーザIDをのカバレッジデARC/INFOータとして直接入力するような場合は含まれない。。)3争点2-2(イ号方法が構成要件1Bを充足するか)について( ) 原告らの主張1ア構成要件1Bは,座標点列の形式をとる一次元ベクトルデータを,アーク・ノード構造化が可能な形式のファイルに書き込み二次元のベクトルデータを作成することを意味する。ここで,アーク・ノード構造とは,ノード(点)がアーク(線)を構成するように,ノード,アークの各データが関係付けられたデータ構造である。そして 「二次元の線データ」とは, ,アーク・ノード構造化が可能なデータ構造を有するファイルに書き込まれた線データの意味である。
記載不備を述べる被告の主張に対しては,後記9,( )ア)のとおり反2b論する。
また,Dファイルは,本件発明の一実施例にすぎず,ファイルはDLG(【】,【】)。, さらに当該実施例の一例にすぎない00110018そして本件明細書は 実施例であるDファイルの構成を明確に示すとともに0 , (【018 ,図2 ,さらに具体例として当業者にとって周知なファイル形 】)式であるファイルを挙げることにより( 0018,当業者としDLG 【】)てはDファイルに相当する任意のファイル形式(Dファイルと同一とは限らない )を選択して,本件発明を実施することが可能となっている。 。
したがって,構成要件1Bにおける「二次元の線データ」のファイル構。 造がDファイルないしファイルの各構造に限定されるものではないDLGイ )イ号方法の構成1bは,から出力された形式のベ a AutoDeskMapDXFARC/INFODXFARCARC/INFOクトルデータを,のコマンドを用いて,が読み取り可能なデータ(カバレッジ)に変換するというものである。
から出力されたデータは,単なるXY座標の座標AutoDeskMapDXF点を列挙したデータにすぎず,この段階では,線の端点にノードが設けられていないことは明らかである。
() このデータをが読み取り可能なデータ カバレッジDXFARC/INFOARC/INFODXFARCDXFARCに変換するのがのコマンドである また。,コマンドに引き続きコマンドを実施することが可能となっていBUILDることから,コマンドによって作成されたデータには,点デ DXFARCータ部をも構造として有していることが明らかである。なぜなら,点データ部を構造として有しない限り,ノードを介してアークを接続するコマンドを実行することは不可能だからである。
BUILD)本件明細書は 「二次元の線データ」に関する一実施例である「Dフ b ,」, , ァイル につき ファイル構成を示すデータを格納するヘッダー部2b-1折れ線の頂点や線端を示す点データを格納する点データ部,閉領 2b-2域の少なくとも1つの属性を示すデータを格納する領域データ部, 2b-3及び,線データを格納する線データ部からなる構成を開示してい 2b-4る( 0018。また,本件明細書は 「Dファイル」の一例として 【】),DLG DLG 「ファイル」の存在を開示しているところ( 0018,【】)ファイルとは,米国地質調査所(USGS)が位置情報の標準ファイルとして作成した世界的な標準モデルである。
イ号方法の構成1bにおける「が読み取り可能なデータ」ARC/INFO(カバレッジ)は,アーク・ノード構造化の可能な形式のファイルであり,その構成は 「二次元の線データ」の実施例である「Dファイル」 ,ないし「ファイル」の構成と共通している。すなわち,@DファDLGイルの「線データ部」とファイルの「ラインレコード」とイ号方 DLGARC DLG法 カバレッジ のファイル ADファイルの 点データ部 と (),「」ARC ALT ファイルのノードレコードとイ号方法カバレッジの 「」(),ファイル,BDファイルの「領域データ部」とファイルの「エリDLGアレコード」とイ号方法(カバレッジ)の,,ファイル PATLABPALの各構成は共通している。
したがって,構成1bは構成要件1Bを充足する。
( ) 被告の主張2,「,『』 原告らは構成要件1Bは ベクトルデータから アーク・ノード構造を有するデータを作成するために,まず,前記ベクトルデータを構成する座標点列データを,アーク・ノード構造化の可能な形式のファイルに書き込むことを意味する 」と主張する。しかし,そのような解釈を許す記載は,本 。
件明細書のどこにも存在せず(特に 「アーク・ノード構造」ないし「アー ,ク・ノードの構造化」という言葉は,本件明細書のどこにも登場しない,。)失当である。
構成要件1Bは,@そもそも意味不明であり,記載不備の無効理由を構成し,A記載不備でないとしても 「二次元の線データ」の意味は「Dファイ ,ルに格納されたデータ」の意味に限定されるべきであり,さらに「Dファイル」は 「ファイル」の意味に限定されるべきである。 , DLGア記載不備について)「二次元の線データ」の意味が本件明細書の記載を参酌しても不明でaあるから,そもそも記載不備である。
「ベクトルデータ」という用語は,地図データ作成の技術分野においては,一般に,二次元又は三次元のデータを意味する。加えて,点データ,線データ又は面データを意味する。したがって,二次元で,線データであるベクトルデータは 「二次元の線データ」と同義である。 ,一方,本件明細書における「ベクトルデータ」は 【0016】等の,記載を勘案すると,線データを表すと理解される。線データは二次元であることを勘案すると,結局,構成要件1Bは「二次元のベクトルデータを二次元のベクトルデータに変換すること」を意味することになり,その技術的意義は不明である。
なお,請求項上 「二次元の線データ」には「線端を示す点データを ,含む」との修飾がある。当該修飾部分は,平成11年4月20日付訂正請求書において訂正されたものである。この訂正につき,特許権者は,訂正の根拠を図2及びDファイルの説明(例えば 【0018 )に基,】づくとしている。しかし 【0018】には 「二次元の線データ」と ,,いう文言はどこにも現れず,これが「線端を示す点データを含む」ことは何ら示唆も記載もされていない。したがって,この訂正は,明細書に基づかない訂正であり,許されない。
また 【0013】の「折線,交点等を認識して二次元の線データに ,変換し「点データ及び二次元の線データ」という記載も,拒絶査定 」,不服審判の段階で行った補正で追加されたもので,出願当初明細書に記載した事項の範囲内においてされたものではないから,この補正も許されるものではない。よって,これらの記載は構成要件1Bの「二次元の線データ」の解釈に参酌されるものではない。
)【0018】の記載はいまだ抽象的であり,当該記載のみで各部にいbかなる情報が具体的に記載されるのかは不明である。
また 【0018】の記載のみでは,少なくとも「面データ」ないし ,「閉領域データ」の位置情報(面データの各座標又は面データを構x,y成する線分のリスト)を格納する部位が不明である。ちなみにDファイルの「領域データ部」は,面データの位置情報を格納する部位で2b-3はない。領域データ部は,面データないし閉領域データの属性情 2b-3報(畑,住宅地,工場地帯等の別など 【0002】参照)を格納する 。
(【】, 部位であることが本件明細書に記載されているからである0018【0030】参照 。)よって 【0018】の記載のみでは,当業者はDファイルを構成す ,ることができない。
)DLGファイルの構成と【0018】等におけるDファイルの各部のc説明とは,矛盾する。
@ファイルのノードレコードは,Dファイルの「折れ線の頂点DLGや線端を示す点データを格納する点データ部( 0018 )と 2b-2 」【】は,明らかに格納するデータが異なっている。
Aファイルのエリアレコードは,Dファイルの「領域データ部DLG」とは,明らかに格納するデータが異なっている。 2b-3以上のとおり,ファイルの構成と【0018】等におけるDフ DLGァイルの各部の説明とは矛盾するものであるから,ファイルを参 DLG照すれば,Dファイルの構成は一層不明確となり,当業者はDファイルを構成することができない。
以上のとおり,構成要件1Bは,その「二次元の線データ」の意義が不明であるから,記載不備である。
イ限定解釈について仮に,記載不備とはならず 「二次元の線データ」に何らかの意味を与 ,えるものとしても,本件明細書には「二次元の線データ」と関連すると思「」(【】【】) われる記載は Dファイル に関する記載0013 及び 0018しかない。さらに 「Dファイル」に関しては 「例えばファイルと , ,DLG同様な構成になっている 」こと,Dファイルが「ヘッダー部「点デー 。 」,タ部「領域データ部「線データ部」からなることは記載されている 」,」,ものの,それ以上に具体的な構成の開示はない( 0018】参照 。【)以上を考慮すれば 「二次元の線データ」の意味は 「Dファイルに格 , ,納されたデータ」の意味に限定されるべきであり,さらに「Dファイル」は「ファイル」の意味に限定されるべきである。
DLGウイ号方法との対比について構成要件1Bの意義は不明であるから,そもそもイ号方法と対比することは不可能である。仮に構成要件1Bに意味を与えるとしても 「二次元,の線データ」の意味は 「ファイルに格納されたデータ」の意味に限 ,DLG定されるべきである。そうであれば,イ号方法はファイルを用いて DLGいないので,イ号方法は構成要件1Bを充足しない。
4争点2-3(イ号方法が構成要件1Cを充足するか)について( ) 原告らの主張1ア構成要件1Cは,構成要件1Bにおいてアーク・ノード構造化の可能な線データとして書き込まれた線データを解析し,他の線データとの接点や交点があれば接点や交点で分割して途中に交点を持たない線データにして線データ部に書き込むとともに,その線端点(始点及び終点/ノード)を点データ部に記録し,各線分に線分番号を付与することである。
このように,各線分を接点や交点のない線分として,それぞれの線分について,座標点列データを線データ部に書き込み,かつ線データとは別に線分の始点と終点を示す線端点(ノード)に関する情報(ノード番号等)を点データ部に書き込むことにより,ノードを介して各線分間の相対的な関係をコンピュータが判読することが可能になり,次の工程である線分を所定方向に接続すること(構成要件1D)が可能になる。
記載不備を述べる被告の主張に対しては,後記9,( )ア )のとおり反2c論する。
また,実施可能要件を満たさない旨の被告の主張は,線分間の接続関係を示すデータの構築方法は明細書上明確に開示されているから,失当である。すなわち 「Dファイル2bは・・・例えばファイルと同様な ,DLG構成となっている との記載 本件公報・ 0018を参酌すれば線 」(【】),「分間の接続関係を示すデータ」は容易に構築可能である。なぜなら,Dファイルの点データ部には,ファイルと同様に,各ノードに接続されDLGるアークのリストが記録されるのであって,このリストこそが「線分間の接続関係を示すデータ」にほかならないからである。よって,当業者は,本件明細書により,容易に線分間の接続関係を示すデータを構築することが可能であり,本件発明は当業者であれば実施可能である。
イイ号方法においては,コマンドによって,接点や交点でもノーCLEANドを作成し,交点を持たない線分を作成してアークデータとノードデータを書き込み,各線分に線分番号を付加している。したがって,構成要件1Cを充足する。
ウ被告は,原告Aの審判事件答弁書14頁の記載を根拠として,原告らが構成要件1Cの該当性を主張することは禁反言の法理により許されないと主張する。
原告Aが同答弁書において構成要件1Cとの相違を主張したのはコマンドであって,イ号方法の構成1cで被告がINTERSECTARCS ADD使用するコマンドではない。すなわち,本構成要件による線分の CLEAN分割は,一定方向に線分を接続して面データを形成するための前処理として行うものであるのに対し,コマンドによる分割は,INTERSECTARCS面データを構成する線分を接続するための処理ではない。同答弁書における主張は,この点を指摘したものである。これに対しコマンドにCLEANよる線分の分割は,線分を接続してポリゴントポロジーを形成するためになされるものであり,本構成要件と機能を同じくするものであるから,禁反言の主張は当たらない。
さらに,被告を含む無効審判請求人は,平成12年9月27日,特許庁に対し,本件無効審判事件におけるマニュアル類を 「日本語版が出版さ,れ公知となった事実を証明することが困難」であるとの理由により証拠撤回している。したがって,当該証拠に関する双方の主張はそもそも特許庁における審判対象となっていないことから禁反言の対象とはなり得ないのみならず,特許庁に対して証拠を撤回した被告自身が,当該証拠に対する原告Aの反論のみを片面的に援用して禁反言の主張を行うことこそが信義則に反するというべきである。
, 。 したがって 原告らの主張は禁反言の法理により遮断されることはない( ) 被告の主張2ア記載不備について「座標上の線分に変換」の意味が全く不明である 「座標上の線分」な。
る用語は地図データの業界用語ではないので,文言自体からその意味を解釈することは不可能である。そこで,本件明細書の記載をみても 「座標,上の線分」なる用語を定義した記載どころか 「座標上の線分」という用 ,語それ自体 発明の詳細な説明欄には一度も出てこない このとおり座 , 。,「標上の線分に変換」の意味が本件明細書の記載を参酌しても不明であるから,記載不備である。
イ禁反言について)原告Aは,本件無効審判事件において,によるアークの分 a ARC/INFO割と本件発明の「座標上の線分に変換」する処理とは異なる旨主張している。したがって,原告らが,を用いる被告のイ号方法が,ARC/INFO構成要件1Cを充足すると主張することは,禁反言の法理により許されない。
)コマンドとは,コマンドの機能(アークへbCLEANINTERSECTARCSの分割設定機能)とコマンドの機能(トポロジー構築機能)の BUILD両方を併せ持ったコマンドであり(さらにファージートレーランス機能等もある,アークへの分割機能だけを取り出して見れば, 。)コマンドと,その目的も機能も全く同一のものであINTERSECTARCSる。したがって,禁反言が成立する。
原告らは,本件無効審判事件における提出証拠を被告が撤回し,双方の主張が特許庁の審判対象となっていないことも,禁反言が成立しない理由として主張する。しかし,禁反言とは,過去の自分の言動を信頼した者を保護するために,該言動と矛盾する言動を禁止する法理であるから,過去の言動(主張)が判断者に審理されたか否かは,禁反言の法理とは本来無関係のものである。さらに特許権は独占権である以上,特許発明の技術的範囲の解釈は,第三者の予測可能性を担保すべく,客観的に定まってしかるべきものであり,時と場合によってその解釈を変えてよい性質のものではないから,特許発明の技術的範囲の解釈に関する主張は,他の主張よりも,禁反言の法理が一層強く要請される主張というべきである。
ウ実施可能要件について構成要件1C,及びその裏付けとして原告らが挙げる本件明細書の【0023【0024】の記載を当業者がみても,次の工程である線分を 】,所定方向に接続することを可能にするデータの構築は不可能であるから,実施可能要件に欠ける。
本件明細書の【0018】及び【0024】には,線分(アーク)の始「」,「( )」, 点及び終点の 点種すなわち 孤立点 他の線データへの接続なし「分岐点(接点,又は「中間点(折れ線の頂角 」のいずれであったか )」 )を記憶することは記載されている。しかし,該点種データからは,アークの始点ないし終点が 「他のアークと接続しているか否か」ということし ,(「」 , か判明せず孤立点 の場合には他の線分との接続はないことが分かり「接点」の場合には他の線分と接続していることだけが分かる,具体。)的に「どの線分が何本接続しているのか」ということについては,該点種データからは判明しない(また 「中間点」を点種の一つとしている意図 ,が不明である。途中に接点や交点を持たない線分の始点又は終点が「中間」 。,, 点 であることは考えられないからである このように 本件明細書には意味不明な記載が多数存在する。。)以上のとおり 【0018】及び【0024】の記載のみでは,線分を ,所定方向へ接続するという次の処理を実施するために必要なアーク間の接続関係を示すためのデータの構築は達成されないので,本件明細書は実施可能要件(特許法36条4項)を欠き,記載不備である。
5争点2-4(イ号方法が構成要件1Dを充足するか)について( ) 原告らの主張1ア構成要件1Dは,座標上の線分を一定方向に接続し,その結果始端と終端が一致したときは,接続された複数の線分からなる閉領域データとしての面データが形成され,始端と終端が一致しないときは閉領域でない面データが形成されることを意味する。
「面データ」とは 「線分を所定方向に接続することによって構成され ,る一本以上の線分の組合せ」である。本件明細書の【0027】には「接続された一連の線分によって構成された面データ」との記載があり,面データを上記の意義に捉えていることが分かる。
構成要件1Dにいう面データの「作成」とは,コンピュータによる処理の過程において (線分の組合せとしての)面データが一時的にでもメモ ,リ中に存在することになれば足り,作成された面データがハードディスク等の記憶媒体に格納されなければならないものではない 本件明細書の 0。【027】は実施例について述べたものにすぎない。
イ )イ号方法は線分を「所定方向に接続」していることについてaまず,GIS上多く用いられるアーク・ノード構造は,点,線,領域の3種類の地図データをノード,アーク,ポリゴンの関係で表すデータ。 , 構造である このアーク・ノード構造を有するファイルの処理においてアークを接続してポリゴンデータを作成する場合,時計回り(あるいは反時計回り)といった一定方向が指定され,この一定方向に従って複数,, 。 の線分が接続されることは 現在 当業者の間で技術常識となっているこの技術常識に従って線分が接続された場合,ポリゴンデータに記憶されるアークIDは時計回り(反時計回り)の順に並ぶことになる。そして,アーク・ノード構造でポリゴンデータを作成するのARC/INFOコマンドも同様のアルゴリズムを採用していることは間違いな CLEANい。実際,の製作会社である社は「各ポリゴンを構成 ARC/INFOESRIするアークのリストは,使用するアークの内部順番号を時計回りに順に並べたものです 」と説明している。。
したがって,のコマンドは「線分を所定方向に接ARC/INFOCLEAN続」している。
)コマンドの実行によりアークの接続が完了した時点で「面デbCLEANータ」が「作成」されることについて「面データ」が「作成」されたとは,コンピュータによる処理の過程において,線分の組合せとしての面データが一時的にでもメモリ中に存在することとなったことをいう。そして,コマンドが実行され CLEANることにより,コンピュータ内でアークを接続する処理が行われ,接続されたアークの集合はコンピュータのメモリ内に逐次蓄積されていくのであるから,アークの接続が完了した段階で「面データ」が「作成」されたものといえる。
なお,仮にデータが「格納」されて初めて「作成」されるとの被告主張を前提としても,結論は同様である。すなわち,は,アーARC/INFOクを接続する際にテンポラリーディスクスペースを使用し,ここには作成中の面データも記録される。したがって,完成した閉じていない面データはいずれ破棄されるとしても,少なくとも完成直後にはテンポラリーディスクスペースに「格納」されるといえる。さもないと,始点と終点が合致しているか否か(閉じていない面データか否か)を判断しようがない。
ウ )被告が主張するように「面データ」がポリゴンを意味するのであれaば閉領域でない面データ という概念が発生し得ないはずである 閉 ,「」 (領域でないポリゴンなどという概念は一般的に存在しない。本構成。)要件が閉領域データのほかに閉領域でない面データの存在を規定しているという事実自体からも明らかなとおり 「面データ」はポリゴンを意 ,味するのではなく,単に線分を所定方向に接続することによって構成される一本以上の線分の組合せといった程度の意味を有するにすぎない。
なお,本件明細書の【0004】における「面データ」は,より狭義の 「閉面を構成する面データ」を意味するにすぎず,また従来技術に ,おける面データ作成を概念的に説明したものであって,本件発明のポリゴン作成方法について述べたものではない。
したがって,構成要件1Dにおける「面データ」とは,単に線分を所定方向に接続することによって構成される一本以上の線分の組合せを意味する。
また 「面データ」の意義からも明らかなとおり,構成要件1Dは, ,線分の接続によって生じる結果として閉領域データや閉領域でない一本以上の線分の組合せが二者択一で生じることを意味するのみであるから,作成されたデータをどこかに格納しなければならないことを意味しないことは明らかである。
)被告は,イ号方法では閉じた面データしか作成されず,線分の始端とb。, 終端が一致しない場合には面データは作成されないと主張する しかし被告は,前提としての「面データ」の解釈を誤っている。イ号方法においても,線分の始端と終端が一致するか否かにかかわらず,その結果として「一本以上の線分の組合せ」が作成されることは事実として明らかである。
)被告は,原告Aの審判事件答弁書15頁の記載を根拠として,原告らcが構成要件1Dの該当性を主張することは禁反言の法理により許されないと主張する。
のマニュアル類における「各ポリゴンを定義するアークのARC/INFOリストを確認して,自動的にポリゴンを発生します 」との記載は,本。
件発明の技術思想を前提とすれば,所定方向に接続するアルゴリズムを利用していることが分かるものの,前記マニュアル類の記載のみから本件発明の技術的意義が読み取れるわけではない。
さらに,前記のとおり,被告を含む無効審判請求人は,平成12年9月27日,特許庁に対し,本件無効審判事件におけるマニュアル類を,「日本語版が出版され公知となった事実を証明することが困難」であるとの理由により証拠撤回している。したがって,当該証拠に関する双方の主張はそもそも特許庁における審判対象となっていないことから禁反言の対象とはなり得ないのみならず,特許庁に対して証拠を撤回した被告自身が,当該証拠に対する原告Aの反論のみを片面的に援用して禁反言の主張を行うことこそが信義則に反するというべきである。
( )被告の主張2,「」, ア構成要件1Dの文言から明らかなとおり 本件発明の 面データ には「終点が始点と一致したときはそれらの線分からなる面データ (閉じた」面データ)と「終点が始点と一致しないときはそれらの線分からなる面データ (閉じていない面データ)が存在する。 」原告Aも,本件無効審判事件において 「本構成要件の技術的意義は, ,閉じた面データ又は閉じていない面データを自動的に作成することである 」と説明している。。
ところで 「面データ」とは,イ号方法が用いるではポリゴ ,ARC/INFOンとも呼ばれるものであり,マップフィーチャーのうち,エリアフィーチャー(家屋等)の位置情報及び属性情報を記憶・保存するためのベクトルデータを意味するものである。
この定義に該当するベクトルデータはすべて「面データ (ポリゴン)」であり,逆にそうでないベクトルデータは「面データ」ではない。
「」 。 ちなみに線データはではアークと呼ばれるものであるARC/INFOこれは,マップフィーチャーのうち,ラインフィーチャー(道路,等高線等)の位置情報及び属性情報を記憶・保存するためのベクトルデータを意味する(さらに,では,ポリゴンの定義にも用いられる。当ARC/INFO 。)然 「線データ(アーク 」と「面データ(ポリゴン 」は異なるものであ ,) )る(なお,では,アークの属性テーブルはファイルであARC/INFO AATり,ポリゴンの属性テーブルはファイルである。 PAT 。)イ前記アのとおり,構成要件1Dでは 「閉じた面データ」と「閉じてい ,ない面データ」の2種類の「面データ」が作成される。
これに対して,イ号方法が用いるで編集・加工されたベクARC/INFOトルデータには,以下に述べるとおり 「面データ(ポリゴン 」は,終 ,)点と始点が一致したもの(すなわち「閉じた面データ )しか作成されな」い。
前記アのとおり 「面データ」とは 「エリアフィーチャー(家屋等) ,,」。 の位置情報及び属性情報を記憶・保存するためのベクトルデータ であるそして,イ号方法()では,ポリゴンの位置情報は,アークとARC/INFOのトポロジーを利用して,境界を構成するアーク(とポリゴン内のラベル)。, , ポイント によって定義される つまり トポロジーが形成されない限りポリゴンの位置情報は記憶されないので,ではポリゴン(面デARC/INFOータ)が作成されたことにはならない。
また,では,ポリゴン(面データ)の属性情報は「ファARC/INFO PATイル」に記憶される。前記アのとおり 「面データ」とは 「エリアフィ ,,ーチャー(家屋等)の位置情報及び属性情報を記憶・保存するためのベクトルデータ」であるから,エリアフィーチャーを表すためのベクトルデータに,その属性情報を保存するためのテーブルが作成されなければ 「面,データ(ポリゴン 」が作成されたとはいえない。つまり,で )ARC/INFO, 「」 はエリアフィーチャーを表すためのベクトルデータにファイル PATが生成されて,初めてポリゴン(面データ)が生成されたことになる。
ところで,において,ポリゴン・トポロジーの生成及びポリARC/INFOPATCLEANゴン用フィーチャー属性テーブルであるファイルの生成は,ないしコマンドを実行することで初めて生成される。しかし,こBUILDれらのコマンドを実行しても,エリアフィーチャーを表すためのベクトルデータの終点と始点が一致していなければエラーとなり,それらを生成することはできない(なお,コマンドの場合は,補正許容範囲内のCLEAN不一致であれば,自動的に終点と始点を一致させる機能がある。つま。)り,終点と始点が一致していない限り,ではポリゴン(面デーARC/INFOタ)は作成されないのである。
以上のとおり,を用いるイ号方法では 「閉じていない面デARC/INFO ,ータ」は作成されないので,イ号方法は構成要件1Dを充足しない。
ウそもそも,原告Aは,本件無効審判事件において,イ号方法が用いるのポリゴン自動作成と,本件発明とは 「根本的に異なる」とARC/INFO ,述べているのであるから,原告らが,を用いる被告のイ号方法ARC/INFOが構成要件1Dを充足すると主張することは,禁反言の法理により許されない。
エ )原告らは 「面データ」の定義を「線分を所定方向に接続することにa ,よって構成される一本以上の線分の組合せ」と主張するようであるが,全く失当である。本件明細書の【0004】における「面データ」が被告の主張する意味で用いられていることは明らかであり,一方,原告らの主張する定義では,その記載の意味が全く通じなくなる。明細書の用語は,明細書全体を通じて統一して使用されるものであるから(特許法施行規則様式29備考8 ,構成要件1Dの「面データ」の意義を原告 )らの主張するように解することは許されない。
原告らは,本件明細書の【0027】に「接続された一連の線分によって構成された面データ」との記載があることをもって,自説の「面データ」の意義の根拠とするが,失当である。上記記載の「接続された一連の線分によって構成された」の部分は「面データ」の修飾語であり,「」 。 修飾される 面データ は別の意味を有することが明らかだからである線分を接続する処理をした結果としてのデータを,一時的にでもどこかに記憶・格納しておかなければ,コンピュータは,せっかく接続処理をしたにもかかわらず,その接続の結果を利用できないことになる。つまり,何も処理しなかったのと変わらない状態ということである。そのような状態をもって,面データを「作成」したというのは無理がある。
また,本件明細書の【0026】及び【0027】には,線分を接続した結果を面データとして格納することが明記されている。
イ号方法()においては,少なくとも,終点と始点が一致ARC/INFOしないときには,原告らの主張する「面データ (線分を所定方向に接 」続することによって構成される一本以上の線分の組合せ)は一時的にも作成されない 原告らは テンポラリーディスクスペースに作成中の 面 。, 「データ(線分を所定方向に接続することによって構成される一本以上の線分の組合せ 」も記憶される旨主張するが,そのような事実はない。 )以上のとおり,構成要件1Dは,線分を所定方向に接続した結果を,終点が一致した場合もしていない場合も同様に 「面データ(エリアフ ,ィーチャーの位置情報及び属性情報を記憶・保存するためのベクトルデータ 」として,記憶・格納することを要求している。そして,イ号方 )法では,終点と始点が一致しなかった場合には 「面データ (閉じて ,」いない面データ)は作成(記憶・格納)されないので,構成要件1Dを充足しない。
)本件明細書の【0006】の「面データを表す輪郭線が画面表示上でbは視覚的に閉じている場合であっても,コンピュータ内部のデータとしては開いており,不連続となっていれば,この面データに与えた属性がこの不連続点から周囲に漏洩して不都合を生ずる 」との記載は 「閉。,領域でない面データ」という概念を肯定している。
本件明細書の「単なる線データをコンピュータに記憶させても,面データを作成することができないと,上述した地域や地点毎の属性を付与することができない( 0007「本発明は,上記従来の実情に 。」【】),鑑みてなされたものであり,その目的とするところは,地域や地点毎に属性を付与可能に保存した地図情報を大幅に効率よく自動的に作成することが容易にできる地図データ作成方法及び装置を提供することである( 0009 )等の記載から明らかなとおり,本件発明のそもそ 。」【】もの目的は 「地域や地点毎に属性を付与可能に保存した地図情報」を ,大幅に自動的に効率よく作成することにある。この「地域や地点毎に属性を付与可能に保存した地図情報」が「面データ」を指していることは明らかであろう。
6争点2-5(イ号方法が構成要件1Eを充足するか)について( ) 原告らの主張1ア構成要件1Eは,構成要件1Dにおいて,終端が始端と一致しなかった場合における面データの不連続となる始端及び終端を報知表示することを意味する。その方法が自動であるか,手動であるかを問わない。
イイ号方法においては,の コマンド実ARCEDITDRAWENVIRONMENT行後の画面において,ダングルエラーが報知表示される。したがって,構成要件1Eを充足する。
ウ )被告は イ号方法におけるダングリングノードの報知表示機能は面a , ,「データ」ではなく「線データ」の不連続点を表示するものであると主張する。
しかし,前記のとおり,被告は,前提としての「面データ」の解釈を誤っている。イ号方法が「一本以上の線分の組合せ」の不連続点を報知表示していることは事実として明らかである。
)被告は,原告Aの審判事件答弁書17頁の記載を根拠として,原告らbが構成要件1Eの該当性を主張することは禁反言の法理により許されないと主張する。
原告Aが同答弁書において指摘したのは,のマニュアル類ARC/INFOにはコマンドの詳細な意義が開示されていないため,NODEERRORS単に「はカバレッジのエラーの可能性のあるすべてのノNODEERRORS(),。」, ード アーク終点 を検出し リストしますとの文言のみからでは最終的に残された,始点と終点が一致しないものについて報知表示を行うという構成要件1Eの技術的意義が読み取れないという事実である。
さらに,前記のとおり,被告を含む無効審判請求人は,平成12年9月27日,特許庁に対し,本件無効審判事件におけるマニュアル類を,「日本語版が出版され公知となった事実を証明することが困難」であるとの理由により証拠撤回している。したがって,当該証拠に関する双方の主張はそもそも特許庁における審判対象となっていないことから禁反言の対象とはなり得ないのみならず,特許庁に対して証拠を撤回した被告自身が,当該証拠に対する原告Aの反論のみを片面的に援用して禁反言の主張を行うことこそが信義則に反するというべきである。
( ) 被告の主張2アイ号方法においては,ダングリングノードを報知表示するという機能があるものの,これは 「線データ(アーク 」の不連続点を表示するもの ,)であり 「面データ(ポリゴン 」の不連続点を報知表示するものではな ,)い。そもそも,前記5で述べたとおり,イ号方法では,エリアフィーチャーを表すためのベクトルデータの終点が始点と一致していない限り,面データ(ポリゴン)は作成されないので 「面データ(ポリゴン 」に存在 ,)する不連続点を表示するということは,イ号方法においてはあり得ない。
ARC/INFO イ原告Aは,本件無効審判事件において,イ号方法の用いるのダングリングノードの報知表示機能を,本件発明とは異なる旨述べた。
よって,原告らが,を用いる被告のイ号方法が本件発明の構成ARC/INFO要件1Eを充足すると主張することは,禁反言の法理により許されない。
なお 「最終的に残された,始点と終点が一致しないものについて報知 ,表示を行う 」ことと,の「エラーの可能性のあるすべて 。
NODEERRORSのノード(アーク終点)を検出し,リストすること」は同義である。
7争点2-6(被告の使用する地図データ作成方法が構成要件1Fを充足するか)について( ) 原告らの主張1ア構成要件1Fは,不連続点から任意の点又は線へ接続する線データを入力に基づいて生成することにより,終点を始点と一致させて面データに対応する閉領域データを作成することを意味する。
イイ号方法は,構成要件1Fを充足する。
ウ被告は,イ号方法では「面データ」ではなく「線データ」の始点と終点。,,, を一致させているにすぎないと主張する しかし 前記のとおり 被告は前提としての「面データ」の解釈を誤っている。イ号方法が「一本以上の線分の組合せ」の不連続点を報知表示していることは事実として明らかである。
( ) 被告の主張2構成要件1Fは,構成要件1Dで作成された「閉じていない面データ」に存在する不連続点から,任意の点又は線へ接続する処理である。
これに対し,イ号方法でも,端点から任意のノード又は線データへ接続す。,, る線データを入力に基づいて生成することはできる しかし イ号方法ではあくまでも「線データ(アーク 」の終点と始点を一致させているだけであ )って,本件発明のように 「面データ」の終点と始点を一致させているわけ ,ではない。すなわち,イ号方法では,必ず線データの終点と始点を最初に(又はコマンドを実行する前に)閉じておく。それから,面CLEANBUILDデータ(すべて閉じた面データ)を作成する。これに対し,本件発明では,線データの終点と始点が閉じていようがいまいが,とにかく面データ(閉じた面データと閉じていない面データの両方)を作成する。その上で,閉じていない面データの終点と始点を入力に基づき一致させて,閉じた面データに(,「」 。)。 する修正を行う これは面データ のデータ内容を修正する作業であるつまり,両者は,一致していない終点と始点を入力に基づいて一致させる修正を行うという点では共通するものの,イ号方法では線データの状態で当該修正を行うのに対し,本件発明では面データの状態で当該修正を行うという相違がある。
よって,イ号方法は,構成要件1Fを充足しない。
8争点2-7(被告の使用する地図データ作成装置が構成要件2Aないし2Fを充足するか)について( ) 原告らの主張1イ号方法において述べたのと同様の理由により,ロ号物件は,構成要件2Aないし2Fを充足する。
( ) 被告の主張2イ号方法において述べたのと同様の理由により,ロ号物件は,構成要件2Aないし2Fを充足しない。
9争点3-1(本件発明が明細書の記載不備又は実施可能要件違反の無効理由を有するか)について( ) 被告の主張1ア発明が不明確ないし発明の詳細な説明に記載したものでないこと(特許法〔平成2年法〕36条5項1号,2号)a)構成要件1Aについて構成要件1Aの「ラスターデータからベクトルデータを作成」とは,「ラスターデータから自動的にベクトルデータを作成」すると解すべきものである。
しかし,仮にそうではなく,構成要件1Aの上記文言がベクトルデータの自動入力方式のみならず,手動入力方式ないし半自動入力方式をも含むものであるとすれば,既に述べたとおり,本件明細書には,そのような入力方式が本件発明の技術的範囲に含まれる旨を開示・示唆する記載は全く存在しないので,本件発明は 「発明の詳細な説明に記載した ,もの (特許法〔平成2年法〕36条5項1号)ではないということに 」なる。
b)構成要件1Bについて既に述べたとおり 「二次元の線データ」の意味が不明であるから, ,構成要件1Bは,構成要件が明確でなく,発明の詳細な説明に記載されたものともいえないので,特許法〔平成2年法〕36条5項1号,2号の要件を満たしていない。
)構成要件1Cについてc,「」 , 既に述べたとおり座標上の線分に変換 の意味が不明であるから構成要件1Cは,構成要件が明確でなく,発明の詳細な説明に記載されたものともいえないので,特許法〔平成2年法〕36条5項1号,2号の要件を満たしていない。
イ当業者がその実施をすることができる程度に明確かつ十分に記載されていないこと(特許法〔平成2年法〕36条4項))「Lファイル」の構成が不明であることa@Lファイルのヘッダー部を構成するクラス部,コード部につき,本,, ,, 件明細書は クラス部は レコードの区分を示すもので コード部はレコードが示す線の形状等を示すとして( 0016,さらにレコ 【】)ードの先頭部の要素種データ(クラス部,コード部)を読み出し,レジスタjに格納し,次にレジスタjの値を判別すると記載している( 0021。次に 「値が「1」〜「7」であれば,それぞれス 【】),,」(【】),「「」「」 テップ…に進み0021レジスタjの値は1〜7まで,それぞれ直線,1点折れ線,2点折れ線・・・7点折れ線,及び8点以上折れ線を示している ( 0022 )としている。 」【】これらの記載によれば,レジスタjの値は,ヘッダー部を構成するクラス部,コード部の値である。しかし,クラス部,コード部は,上記のとおり,レコードの区分を示したり,レコードが示す線の形状等を示したりするものであるから,値が「1」〜「7」であることと,どのような関係があるのか不明であり,したがって,Lファイルを構成することは不可能である。
Aなお,本件無効審判事件における平成12年4月25日付意見書11頁12ないし14行において,クラス部21-1について「レコードに格納されるデータの区分(種類:例えば,線データ,注記データ等)を示すものである」とするが,そのようなことを示唆する記載は本件。,, 明細書に存在しない コード部21-2についても 縷々説明しているが後出しの説明であって,明細書に基づかないものである。
B特許権者は,前記Aの意見書で 【0021】について,本件明細 ,書の「要素数」とは,ステップ2に係る「要素数」は要素レコード数を意味し,要素レコード及び図2における「要素数」は座標点数を意味すると釈明する。しかし,明細書に使用される用語は「明細全体を通じて統一的に使用」されなければならないものであるから(特許法施行規則様式29備考8「要素数」という一つの用語に二つの意 ),味を含ませる解釈は採り得ない。
そうすると,本件明細書の「要素数」は,要素レコード数か,座標点数のいずれかの意味で統一して用いることになる。しかし,特許権者も自認するとおり,技術的に全く意味不明となるのであるから,本件発明は実施不能である。
なお,上記釈明は,全体ファイルを管理する「グループヘッダレコード」なるものの存在を前提としたものであり,本件明細書にそのようなものの存在を示唆する記載は皆無であるから,上記釈明は採用できない。
C以上のとおり,本件明細書の記載は,Lファイルの構成が不明であ, 。 るから 当業者が実施できる程度に明確かつ十分に記載されていないb)折れ線,交点を認識して二次元の線データに変換する方法が不明であること,「, 」 本件明細書は折れ線 交点を認識して二次元の線データに変換し( 0013 )としている。しかし,図4のフローと折れ線・交点の 【】認識とは,どのような関係があるのか不明である。図4のフローは,線データの各座標を読み出しその座標をDファイルに書き出していくことが記載されているのみで,折れ線や交点の認識方法については全く記載されていない。
よって,本件明細書の記載では「折れ線,交点を認識して二次元の線データに変換」する方法が不明であるから,当業者が実施できる程度に明確かつ十分に記載されていない。
c)LファイルからDファイルへデータを入力するフロー及びDファイルの構成が不明であること@本件明細書には,Dファイルが,ヘッダー部,点データ部,領域データ部,線データ部から構成されることは説明されている( 001【8。また,DファイルとLファイルとの関係につき 「・・・要素 】) ,レコードiの要素種データに続いて格納されている座標データ(・・・)を読み出して,その読み出した座標データを・・・Dファイル2bの線データ部2b-4に転送して所定位置に書き込む( 002。」【1 )と記載されている。 】これらの記載によれば,Lファイルから読み出したデータは,Dファイルの線データ部に格納されることになる。しかし,Dファイルのヘッダー部,点データ部,領域データ部には,何が記憶されているのか明確でない。また,Lデータとこれら各部がどのような関係を有するのか不明であって,Dファイルを作成することができない。
Aなお,図4のフローについて 「ステップS5では,要素レコード ,iを読み出し,その要素iの先頭部の要素種データ(すなわちクラス21-1及びコード21-2)を読み出しレジスタjに格納する。続, 。,「」 いて ステップS6でレジスタjの値を判別する そして 値が 1〜「7」であれば,それぞれステップS7〜ステップS13に進み,要素レコードiの要素種データに続いて格納されている座標データ( )」(【】), すなわち要素数22-1〜22-n を読み出して0021「上記レジスタjの値は「1」〜「7」まで,それぞれ直線,1点折れ線,2点折れ線・・・7点折れ線,及び8点以上折れ線を示している ・・・ ( 0022 )と説明されている。しかし,レジスタj 。」【】に格納される,要素種データであるクラス,コードがS7以降の折線のn点(n=1〜7)の座標をDファイルに書き込むこととどのように関係するのか不明である。
Bなお,Dファイルはファイルと同様な構成になっていると記DLG載されているとはいえ,本件明細書は,ヘッダー部,点データ部,領域データ部,線データ部というファイル構成を有する点につき同様と説明しているのであって,Dファイルのヘッダー部,点データ部,領域データ部,線データ部の具体的構成,各部に格納されるデータのフォーマットまで同一であるという趣旨でないことは明らかである。なぜなら,ファイルにつき 「例えばファイル・・・」としDLG DLG ,て,一例として挙げているからである。
C以上のとおり,本件明細書の記載は,LファイルからDファイルへデータを入力するフロー及びDファイルの構成が不明であるから,当業者が実施できる程度に明確かつ十分に記載されていない。
d)線データを線分に分割する方法が不明であること本件明細書は「Dファイル2bに作成した線データを読み出して,線分に分解する」という( 0023。しかし,具体的にどのように, 【】)線データを,他の線データとの接点,交点で分割して,途中に接点や交点を持たない線分に細分するのか,具体的な手順が不明である。
e)ポリゴンを自動的に作成する方法が,当業者に実施可能な程度に明記されていないこと@本件発明は,線データ(線分)からポリゴンを自動的に作成する方法として 「線分を所定方向に接続し,終点が始点と一致したときは ,それらの線分からなる面データの閉領域データを自動的に作成 (構」成要件1D)する方法を開示する。同方法は,本件明細書の発明の詳【】【】 , 細な説明欄の 0025 及び 0026 に説明されているもののその説明だけでは,複数のポリゴンを一括して自動的に作成することは不可能である。
Aまず,線分を所定方向に接続する前提として,線分(アーク)間の接続関係を示すデータを構築しておくことが必要不可欠である。しかし 【0024】の記載では,当該データを構築できず,他に当該デ ,ータを構築する具体的方法を開示した記載もないので,本件明細書では,当業者が線分を所定方向に接続する処理を実施することが不可能である。
Bまた,本件発明の接続方法は,線分(交点を有しない線データ)を「所定方向 ,すなわち,接続方向を時計回りか反時計回りのいずれ 」でもよいが,とにかく一定方向に予め定めておくだけの方法である( 0025】参照 。【)この方法だと,同じ線分を境界として共有する複数の面データを同時に作成する場合(共通する境界を持つ面データがある場合)に,対応できない場合が生じる。
Cさらに,本件明細書の説明のみでは,ある線分の終点に,他の線分の終点しか接続していない場合にどのように処理して線分を接続するのかが不明である 【0025】は,ある線分の終点に他の線分の始 。
点が接続している場合の説明であり,線分の終点しか接続していない場合にどのように処理するかについては,何ら説明されていない。
D以上のとおり,本件明細書の説明のみでは,当業者が線データ(線) 。 分 からポリゴンを自動作成することを実施することは不可能であるEポリゴンを自動的に作成する方法について,本件明細書は,線分の接続方向を指示するのみで 「接続方向に最小面を形成するように」 ,とか「角度が最小となる線分を選択」といった,線分(アーク)同士が形成する角度に着目して接続する線分を選択する思想は,一切開示・示唆されていない。
本件明細書の「線分を所定方向に接続」の「所定方向」を 「線分,同士の角度を測る方向」と解することは不可能である。なぜなら,線分の「接続方向」と,線分同士の「角度を測る方向」とは,全く異なる概念だからである。このことは,線分同士の角度を測る方向と線分の接続方向とは逆になること,及び,角度を測る方向を一定にしてもラインの接続方向は常に一定とはならないことから,明らかである。
本件無効審判事件で提出された「情報処理学会第33回(昭和61年後期)全国大会論文集,第〜頁」には 「地図認識入力14791488 ,システム(乙29。以下「文献」といい,同文献にMARISMARIS 」記載された発明を「」という )が掲載され,ベクトルデータMARIS 。
の境界追跡方法が開示されている。同追跡方法は,最初に注目したブランチ(線分)を,開始特徴点(線端)から終了特徴点(線端)へと追跡し,該終了特徴点の近傍を,反時計回りに検査して2番目に検出されるブランチを新たな注目ブランチとし(1番目に検出されるのは元の注目ブランチである,同様の追跡を繰り返すというものであ 。)る。これは,まさに「反時計回りで角度が最小の線分を,次に接続すべき線分として選択する方法」すなわち,原告らが,本件明細書が開示している線分接続方法であると主張している方法である。したがって,かかる本件無効審判事件での主張を踏まえれば,本件発明の線分接続方法がの境界追跡と同様の方法であると主張することMARISは,禁反言の法理に反し,許されない。
)に利用可能なコンピュータ用地図データを作成するためには,レfGISイヤー毎にベクトルデータを作成する必要がある。しかし,本件発明において,ラスターデータから,どのようにしてレイヤー別ベクトルデータを生成できるのか明らかでない。
)本訴における記載不備の主張は,そのほとんどが,本件無効審判事件gにおいて審理された主張とは全く別の主張である。Lファイルの構成についての主張は本件無効審判事件におけるものと同一であるとはいえ,この主張を排斥した審決の判断は誤っている。
また,財団法人日本測量調査技術協会に属するBは,独自にポリゴン生成プログラム作成を試みたのであり,本件発明を追試したものではない。
( ) 原告らの主張2ア記載不備について)構成要件1Aについてaラスターデータからベクトルデータを作成する方法は従来技術であることに加え,単なる実施例としてオンスクリーン方式ないし半自動入力方式を挙げなかったからといって,オンスクリーン方式ないし半自動入力方式を排除する意図があるということにはならない。
したがって,構成要件1Aの意義は本件明細書によって明確に記載されている。
)構成要件1Bについて b@「二次元の線データ」の意義について「二次元の線データ」とは,アーク・ノード構造化が可能な形式のファイル(このファイルの一例がファイルである )に書き込DLG 。
。,「」, まれた線データを意味する これに対し一次元の線データ とは座標点列としての線データを意味する(のポリラインなどがこDXFれにあたる。。)「一次元「二次元」の意味につき敷衍すれば,まず,座標点列 」,としての線データはアーク・ノード構造を有しないことから,コンピュータは複数の線データを所定方向に接続することができない。このため,コンピュータは線データの集合を面として認識することができず,直線あるいは折れ線としての認識が可能であるにとどまる。
これに対し,アーク・ノード構造を有するデータの場合,コンピュータはアーク・ノードのトポロジーを介して複数の線データを所定方向に接続していくことができるため,線データの集合を面として認識することが可能となる。
「座標点列としての線データ「アーク・ノード構造を有する線 」,データ」はそれぞれ上記のような性質を有することから 「線として,認識されるにとどまるデータ「面としての認識が可能なデータ」 」,であることを強調する趣旨で線 と 面 の違いを端的に表す 一 ,「」 「」「次元 「二次元」の語を用いたものであることは容易に理解できる。 」ADファイルに関する説明が明確であることについてDファイルの例示としてファイルが挙げられていることからDLG(本件公報・ 0018,何ら記載不備ではない。そして,閉領域 【】)の位置情報も領域に関するデータである以上,領域データ部に格納す, 。 ることは当然であり そのことはファイルにも記載されているDLG領域データ部には閉領域の属性情報が格納されるとの説明(本件公報・ 0018【0030 )は例示にすぎず,これ以外の情報を格 【】,】納することも当然可能である。
BDファイルの説明とファイルの構成が矛盾しないことについDLGてファイルはDファイルの一例にすぎないのであるから,DフDLGァイルに格納されるデータとファイルに格納されるデータとが DLG厳密に一致しなければならないものではない。したがって,被告の主張は理由がない。
)構成要件1Cについてc「座標上の線分に変換」とは,アーク・ノード構造化が可能な形式のファイルに実際に線データ及び点データを書き込み,アーク・ノード構造を具体的に構築することを意味する。
本件明細書は,本件発明の一実施例として 「上記面データの作成処 ,理について,図5に示すフローチャートを用いて説明する。先ずステップS51で,上記閉面データ画像処理用Dファイル2bに作成した線データを読み出して,線分に分解する。この線分への分解処理は,上記読み出した線データを,他の線データとの接点,交点で分割して,途中に接点や交点を持たない線分に細分し,それらの各線分に線分番号を付与する処理である 」ということ( 0023,及び,線データを細分 。【】)する際,以降のステップにおいて線分を接続する基点となる各線端点に関する情報を記録すること( 0024 )をそれぞれ開示しており, 【】これを参考にしてアーク・ノード構造を構築することは当業者にとって十分可能である。
したがって 「座標上の線分に変換」の意義は本件明細書によって明 ,確に記載されている。
イ実施可能要件について)Lファイルの構成についてa本件明細書は 【0013【0016】及び図2( )において「Lフ ,】, aァイル」の構成を具体的に開示している。
本件明細書の【0021】における「要素数」の意義についての被告の主張は,既に特許庁において審理済みであり,審決において排斥されている。すなわち 【0022】に「要素レコードi」との記載が複数 ,回にわたり用いられておりレジスタiに格納されるデータが要素レコード数であることは明らかである 「要素」という用語は 「アイテム , 。,」「項目」等と同様にデータを構成する個々の部分を示す一般的な用語であり,明細書の記載において 「要素」という用語を必ずしも特定の種 ,類のデータに対してのみ利用しなければならないということはない。本件無効審判事件における釈明は,明細書の理解を助けるために 「要素,数」という一般的な用語で示されていたレジスタiの内容を「厳密に言えば要素レコード数」であると説明したにすぎない。したがって,明細書に要素数が複数の意味で用いられているとしてもLファイルの構成は明確であり,このために当業者による実施が不可能であるということはない。
したがって,Lファイルの構成は本件明細書によって明確に記載されている。
)折れ線・交点を認識して二次元の線データに変換する方法b本件明細書は,一実施例として,Lファイルの線データを解析してDファイルの点データ及び二次元の線データとして出力するに至る一連の過程を具体的に開示している(本件公報・ 0016】ないし【002 【2。】)まず,折れ線の認識方法は【0021】に明確に記載されている。次に,交点の認識方法には様々な方法があるとはいえ,線分の交点を認識して交点にノードを置く技術は周知の技術であり,当業者であればその方法は容易に想到し得る。
したがって,折れ線・交点を認識して二次元の線データに変換する方法は本件明細書によって明確に記載されている。
)LファイルからDファイルへデータを入力するフロー及びDファイルcの構成本件明細書は,LファイルからDファイルへデータを入力するフローに関する一連の過程を具体的に開示している(本件公報・ 0016】【ないし【0022。】)また,前記アの)のとおり,本件明細書は「Dファイル」の構成をb具体的に開示するとともに,その一例として「ファイル」の構成 DLGを開示しているのであって,二次元の線データのファイル構造を設計することは当業者にとって十分可能である。
したがって,LファイルからDファイルへデータを入力するフロー及びDファイルの構成は本件明細書によって明確に記載されている。
)線データを線分に分解する方法d前記アの )のとおり,本件明細書の【0023】及び【0024】 cは,線データを線分に分解する方法を明確に記載している。当業者が明細書の記載を見れば,線データ同士の交点を認識し,交点のノードデータを作成するとともに,もとの線データを二つに分割するような操作を行うアルゴリズムを容易に構築できる。
)ポリゴンを自動的に作成する方法e@「所定方向に接続」するためのアルゴリズムは,当業者であれば本件明細書の記載から容易に理解可能である。すなわち,まず任意の第一の線分を選択して,次に第一の線分の終端と同一の点を始端又は終端とする線分の組を抽出し,その線分の組の中から決められた接続方向に最小面を形成するように,すなわち,時計回りの方向(又は反時計回りの方向)に第一の線分との角度が最小となる線分を選択する。
以下,選択された線分の終端が第一の線分の始端と一致するまで(又は一致しないときまで)同様の操作を繰り返す。
したがって,線分に接続するラインが2つ以上あったとしても,次に接続すべき線分は必然的に1つ,すなわち所定方向に最小面を形成する線分,に定まる。
Aそもそも,本件発明の構成要件1Dには「該線分を所定方向に接続し」と記載されているのみで,ある線分の終端が必ず次に接続する線分の始端となっていることを必要としていない。本件明細書の【0025】はあくまで実施例であって,複数の線分の接続点がいずれも線分の終端である場合を排除するものではない。前記のとおり,線分の接続処理を実施するアルゴリズムは,当業者であれば容易に理解可能であり,接続点が各線分の終端であっても,接続する方向が一義的に定まっていれば接続処理は可能である。
B一つの線分に接続する線分が複数ある場合に,いずれの線分を次に接続するかの判断に際しては,線分同士の角度に着目するのが従来技術であり,本件明細書中に開示がなかったとしても当業者は容易に理解可能である。また,そもそも次に接続する線分を選択するに際し,線分同士の角度以外の判断基準を考えつくことの方が困難であり,普通に考えれば角度に着目することになるはずである。
C原告会社は,審判官の認定が誤っていることを指摘するために,の境界追跡が線データの一次元的な関係を利用しているにすMARISぎないことを陳述したにすぎないのであって,の境界追跡と MARIS本件発明の線分接続方法とが異なるとの陳述を行ったことはない。
したがって,構成要件1Dにかかる方法は本件明細書によって明確に記載されている。
)小括f以上のとおり,本件明細書はいずれの点についても当業者がその実施。, をすることができる程度に明確かつ十分に記載されている このことは既に特許庁における本件無効審判事件の審決においても確認されている。
なお,本件発明が当業者にとって十分実施可能であることは,当業者である財団法人日本測量調査技術協会に属するBも確認しているところである。
10争点3-2(本件発明が新規性又は進歩性欠如の無効理由を有するか)について( ) 被告の主張1仮に,を用いるイ号方法が本件発明の技術的範囲に属するものARC/INFOであるとすれば,本件発明は新規性・進歩性を欠き,無効である。
アのマニュアル類が「刊行物 (特許法29条1項3号)に該ARC/INFO 」当することについて被告他審判請求人らは,本件無効審判事件において,審判長より,のマニュアル類(日本語版)の日付の特定ができないので撤回ARC/INFOするように強く示唆され,他の証拠で本件特許を十分無効にできると判断したため,これらを撤回したにすぎないのであって,被告自身が刊行された日付を特定できないと考えていたのではない。
特許法29条1項3号の「刊行物」というためには,不特定又は多数の者を対象としているという「公開性」と,対象物が本来的に配布する目的であるという「頒布性」が必要である。のマニュアル類は,少ARC/INFO,「」 なくともライセンシーに配布することを目的とする文書であり頒布性の要件を満たす。また,ディストリビューター契約第2条及び第4条から明らかなとおり,のディストリビューターたる被告は,独立のARC/INFO立場で不特定の第三者に対してのライセンスを付与すること ARC/INFOができ,また,ライセンシーはすべからくの各種マニュアル ARC/INFOの配布を受けるのであるから,の各種マニュアルは,いずれも ARC/INFO「公開性」を満たす。
仮に,社とのライセンス契約に規定される秘密保持条項の存在にESRIよりライセンシー間で秘密が保たれている間は「公開性」を充たさないとの解釈が採用されたとしても,C元オハイオ州立大学地理学教授らの宣誓供述書(乙41ないし44)が示すとおり,既にその秘密性は破られてい,, 「」 るため この場合であってもの各種マニュアル類は 公開性ARC/INFOを充たす。
現に,のマニュアル類は,本件発明の出願前から,日本国内ARC/INFOのみならず,社によって世界中で広く頒布されていた。被告におい ESRIて確認したところ,海外におけるのライセンシーの数は,本 ARC/INFO件発明の優先日前である平成3年(1991年)5月の時点で約3400社であり,日本国内におけるのライセンシーの数は,本件発ARC/INFO明の優先日直後の平成3年(1991年)10月の時点で約80社であった。当然,各ライセンシー内の複数の社内関係者がのマニュARC/INFOアル類に触れることになるので,数千,数万という規模の人間が,のマニュアル類に触れていた計算になる。
ARC/INFO被告はのディストリビューターとして,営業宣伝のためにARC/INFO及びマニュアル類を第三者にデモンストレーションをする権利 ARC/INFOを有するものであり,実際,被告は,の営業にあたって,何ら ARC/INFO守秘義務を負わない売り込み先の第三者に対し,の実演及びマ ARC/INFOニュアル類に基づいたの説明を行ってきたのであるから, ARC/INFOマニュアル類に記載された発明は,被告の営業活動によって, ARC/INFO本件出願優先日当時,既に公知・公用の発明である。よって,仮に,ARC/INFO ARC/INFO マニュアル類の 刊行物性 が否定されたとしても 「」,マニュアル類に記載された発明によって本件発明が無効になるとの結論に変わりはない。
イ平成元年(1989年)に発行された(以下ARC/INFO Version 5ARC/INFO Users Guide「V5」という )のユーザーズガイドである 。
(,。
ARC/INFO Volume 1Version5.0 , Volume 2Version 5.0.1 ・・乙13 14以下「マニュアルV5」という )には,以下のとおり,構成ARC/INFO 。
要件1Aないし1C,1Dの前半,1Eないし1Hに相当する構成が開示されている。
()()aARC/INFO)マニュアルV5 乙13 の4-6頁 甲11の4-6頁には 地図 ラスターデータに相当 を読み取って一連の座標に変換 ラ ,() (スターベクトル変換)することが記載されている。このベクトルデータを用いてポリゴン化処理を行うので,上記記載は構成要件1Aに相当する。
((),bARC/INFO)マニュアルV5 乙13の1-4頁 乙31の1-4頁乙13の4-7頁(甲11の4-7頁 ,乙14のコマンドの )DXFARC説明(甲19の209ないし215頁)及びF,乙14の Appendixコマンドの説明(乙30の192ないし200頁)及び DLGARCD,乙14の 等の AppendixSCITEXLINE, SCITEXPOINT, SCITEXPOLY( ), 各コマンドの説明 乙30の481ないし487頁 及びG Appendix乙14のの7頁(甲19の119頁 ,同の11頁(甲1 Build CLEAN )9の135頁 )には,本件出願優先日当時,既に公知のファイルフォ )ーマットであるファイル,ファイル,ファイル等にDXFDLGSCITEX格納されたベクトルデータを,のカバレッジに変換すること ARC/INFOが開示されている。さらに,のカバレッジが,アーク・ノー ARC/INFOド構造化が可能なファイルフォーマットであること,その具体的なアーク・ノード・トポロジーのデータ例も開示されている。
原告らの主張によれば 「二次元の線データ」とは「アーク・ノード ,構造化が可能な形式のファイルに書き込まれた線データ」を意味し,また,ファイルデータは「一次元の線データ」であるとのことであDXFるから,マニュアルV5(乙13,14)には,構成要件1 ARC/INFOBに相当する構成が記載されている。
)マニュアルV5(乙14のコマンドの説明(甲1cARC/INFO CLEAN9の126頁,128頁 )には,コマンドがアークの交点に ) CLEANノードを生成すること,また,カバレッジ・ノードとポリゴンを明確にするためにカバレッジ・アークとラベル点に幾何学的解析を実行してポリゴン及びアーク・ノード・トポロジーを構築することが記載されている。
原告らの主張によれば 「座標上の線分に変換」とは 「アーク・ノ , ,ード構造化が可能な形式のファイルに実際に線データ及び点データを書き込み,アーク・ノード構造を具体的に構築することを意味する」とのことであるが,そうであるとすれば,マニュアルV5(乙1ARC/INFO4)には,構成要件1Cに相当する構成が記載されている。
)マニュアルV5(乙14のの説明(甲19の12dARC/INFO CLEAN8頁 ,の説明(甲19の113頁 ,乙13の5-7頁(乙3 ) ) BUILD1の5-7頁 )には,コマンドがポリゴントポロジー ) CLEAN, BUILDを作成することが記載されている またマニュアルV5 乙 。, ( ARC/INFO13の5-7頁(乙31の5-7頁 )のポリゴントポロジーの例を見 )れば,アークを右回り方向に接続することによりポリゴンを作成していることが示唆されている。マニュアルV5(乙13の10-ARC/INFO4頁(甲11の10-4頁 ,乙14のの説明(甲19の12 ) CLEAN7頁,114頁,118頁 )によれば,コマンドは一 ) CLEAN, BUILD連のアークを閉じていることを前提にポリゴンを作成しており,アークが閉じていない限りポリゴンは作成されないことが記載されている。
よって,マニュアルV5(乙14)には,構成要件1D前ARC/INFO半の「該線分を所定方向に接続し,終点が始点と一致したときはそれらの線分からなる面データの閉領域データを自動的に作成」に相当する構成が開示されている。
)マニュアルV5(乙13の「ステップ3:デジタイジングeARC/INFO」( ), エラーの発見及び訂正 の項 甲11の10-4頁ないし10-6頁「ステップ4:フィーチャーの定義及びトポロジーの生成」の項(甲11の10-7頁ないし10-14頁 )には,ダングリングノードによ )りポリゴンが正しく閉じていないことをエラーとし,閉じていないポリゴンと接続していないラインをエラーとして表示することが記載されている。
よって,マニュアルV5(乙13)には構成要件1Eに相ARC/INFO当する構成が開示されている。
)マニュアルV5(乙13の「ステップ5:トポロジーエラfARC/INFO」( ), ーの発見及び訂正 の項 甲11の10-10頁ないし10-14頁「ステップ2:カバレッジのデジタイザー入力」の項(甲11の10-3頁,10-4頁 )には,によるデジタイザー入力によりエ )ARCEDITCLEANBUILDラー訂正すること,アークを編集した後に再度若しくはコマンドを実行し,トポロジーを更新することが記載されている。
上記記載により,では,又は後に,ダングARC/INFOCLEANBUILDリングノード等のエラーを発見したら,によるデジタイザー ARCEDIT入力(すなわち手動入力)等で訂正し,その後,又はで CLEANBUILD再びポリゴンを作成することが分かる。よって,マニュアル ARC/INFOV5(乙13)には,構成要件1Fに相当する構成が開示されている。
)マニュアルV5(乙13の「ステップ4:フィーチャーのgARC/INFO定義及びトポロジーの生成」の項(甲11の10-7頁ないし10-10頁 ,乙14のの説明(甲19の113頁,125頁 ,乙1 ) )BUILD3の1-4頁(乙31の1-4頁 )には,又はコマン ) CLEANBUILDドにより各フィーチャーの属性を記憶するためのフィーチャー属性テーブルを作成すること,が地理データの「入力「解析「デARC/INFO 」,」,ータ管理「表示と変換」に利用されることが記載されている。 」,よって,マニュアルV5(乙13)には構成要件1Gに相ARC/INFO当する構成が開示されている。
(())hARC/INFO)マニュアルV5 乙13の1-1頁 乙31の1-1頁には,が地理データの入力,処理,解析,表示に利用されるARC/INFOことが記載されている。
よって,マニュアルV5(乙13)には,構成要件1HにARC/INFO相当する構成が開示されている。
ウ昭和61年10月2日に発表された文献(乙29)には,以下MARISのとおり,構成要件1Aないし1Hに相当する構成が開示されている。
)文献(乙29)の1479頁には,スキャナーから国土基本aMARIS図(ラスターデータに相当)を読み取り,線幅測定,細線化,ベクトル化し,線幅付きベクトルを作成することが記載されている。
よって,文献(乙29)には構成要件1Aに相当する構成がMARIS開示されている。
(),,,bMARIS)文献乙29 の1479頁 1483頁 1484頁には細線化により得られた線幅付きベクトルデータから,ブランチとの接続情報を有する特徴点テーブル,ブランチテーブル等のベクトル管理テーブルを作成することが記載されている 「ブランチ」とは 「途中に接 。,ARC/INFO 点や交点を持たない線分本件公報・ 0024であり 」(【】),の「アーク」に相当する。また 「特徴点」は「ブランチ」の始点又は ,終点ということになるから,の「ノード」に相当する 「特ARC/INFO 。
徴点テーブル」及び「ブランチテーブル」は,ブランチ(アーク)と特徴点(ノード)の接続情報(どのブランチがどの特徴点に接続しているか,ある特徴点に何本のブランチが接続しているか,どの方向に接続しARC/INFO ているか を格納しているから これらのデータテーブルは ), ,のアーク・ノード・トポロジーに相当し,また原告らの主張する「アーク・ノード構造」に相当する。
上記のとおり,文献(乙29)は,スキャナーにより得られMARISたイメージデータを細線化・ベクトル化した「線幅付きベクトル」を,アーク・ノード構造を持つベクトルデータに変換することを,具体的に開示している。その変換の前提として,アーク・ノード構造を保有できるデータ形式を使用することは,当然の前提となっている。
よって,文献(乙29)には構成要件1B及び1Cに相当すMARISる構成が開示されている。
(),,,cMARIS)文献乙29 の1484頁1485頁 1487頁には建物認識等のために,注目ブランチから正方向又は逆方向にブランチを追跡し,一つ又は複数のアーク(連結したベクトル列で,端点の開いているもの)あるいはポリゴン(閉ループをなした連結ベクトル列)としてベクトル列を抽出することが記載されている。ここでいう「アーク」は,原告らの主張する定義(線分を所定方向に接続することによって構成される一本以上の線分の組合せ)によれば「面データ」に相当する。
よって,文献(乙29)には,構成要件1D前半「該線分をMARIS所定方向に接続し,終点が始点と一致したときはそれらの線分からなる面データの閉領域データを自動的に作成」及び後半「終点が始点と一致しないときはそれらの線分からなる面データを自動的に作成」に相当する構成が開示されている。
)文献(乙29)の1488頁左欄1行ないし14行には,連dMARIS結ベクトル列が閉ループを構成していない場合に,検出されたブランチ列を強調表示することが記載されている。全ブランチ列を強調表示するか,始点・終点のみを強調表示するかは,単なる設計事項である。
よって,文献(乙29)には構成要件1Eに相当する構成がMARIS開示されている。
)文献(乙29)の1487頁には,会話型コマンドを用いてeMARISアーク型データ(連結したベクトル列で,端点の開いているもの)にアーク型データを入力により接続し,ポリゴン型データ(閉ループをなした連結ベクトル列)とすることが記載されている。
よって,文献(乙29)には構成要件1Fに相当する構成がMARIS開示されている。
)文献(乙29)の1487頁には,地図要素を建物,道路等fMARISの分類に応じて認識セグメントとして管理することが記載されている。
地図要素には建物等の閉領域データが含まれており,また分類は属性データに相当する。
よって,文献(乙29)には構成要件1G及び1Hに相当すMARISる構成が開示されている。
(。 エ平成元年11月14日に公開された特開平1-282685号 甲44以下「甲44公報」という )には,以下のとおり,構成要件1Aないし 。
1C,1D前半,1G及び1Hに相当する構成が開示されている。
)甲44公報の3頁右上欄6行ないし11行には,ラスターイメージをa二次元平面の始点/終点座標を結ぶ線としてベクトルデータに変換することが記載されている。
よって,甲44公報には構成要件1Aに相当する構成が開示されている。
)甲44公報の3頁ないし4頁には,ベクトルデータを認識処理し,得bられた一次ベクトルの始点/終点座標,他のベクトルとの接続情報や属「」(, 性等からなる 二次ベクトルデータ 及び論理的特異点 オープン端点分岐点等)から接続するベクトルを追跡することにより得られる「アークデータ」を主記憶部に格納することが記載されている。二次ベクトルデータは他のベクトルとの接続情報を有しており,アークは「途中に接点や交点を持たない線分」に相当する。
これらの「二次ベクトルデータ」及び「アークデータ」は,原告らのいう「アーク・ノード構造」に相当するのであって,甲44公報には構成要件1B及び1Cに相当する構成が開示されている。
)甲44公報の5頁ないし6頁には,現在追跡中のアーク(現アーク)cの終端ベクトルに対して,最も右に折れるベクトルを始端ベクトルとするアークを追跡し,先頭アークの始端と現アーク(最終アーク)の終端の座標が一致する場合に閉ループを抽出することが記載されている。
よって,甲44公報には構成要件1D前半「該線分を所定方向に接続し,終点が始点と一致したときはそれらの線分からなる面データの閉領域データを自動的に作成」に相当する構成が開示されている。
)甲44公報の2頁,4頁には,抽出閉ループをフロッピィディスク等dの外部記憶に出力することが記載され,閉ループに配管,配線,建屋,シンボル等の属性を付与することが前提とされている。
よって,甲44公報には構成要件1G及び1Hに相当する構成が開示されている。
オ平成元年11月2日に公開された特開平1-274285号(甲42。
以下「甲42公報」という )には,以下のとおり,構成要件1C,1D 。
前半及び1Hに相当する構成が開示されている。
)甲42公報の3頁には,発生したすべての線を交点,接点において分a割し,ベクトル線分を生成し,これらのベクトルを所定方向に検索することにより生成したポリゴンを記憶部に格納することが記載されている。
よって,甲42公報には構成要件1Cに相当する構成が開示されている。
)甲42公報の3頁には,任意のベクトルを選択し,該ベクトルを基準b,, として予め設定した方向に接続ベクトルを検索し ポリゴン化すること接続ベクトルが複数存在する場合には,接続角度によりベクトルを選択することが記載されている。
よって,甲42公報には,構成要件1D前半「該線分を所定方向に接続し,終点と始点と一致したときはそれらの線分からなる面データの閉領域データを自動的に作成」に相当する構成が開示されている。
)甲42公報の1頁には,市,区,町等の各境界を示す図形をポリゴンc化することが記載されている。
よって,甲42公報には,構成要件1Hに相当する構成が開示されている。
カ平成2年発行の「 (乙3Geographic Information Systems An introduction 」9,訳文として乙40。以下「乙39文献」という )は,平成2年当時。
における地理情報システム分野の入門編であり,大学学部高学年か大学初年度段階程度のものを提供している( はじめに」A頁参照 。同書には, 「)構成要件1Aないし1C,1Eないし1Hが当業者の周知技術であることが示されている。
)乙39文献には,地理情報システムにおける代表的なデータベース型aとして,全ポリゴン構造,アーク・ノード構造等があること( 4.2「ベクトルデータ構造,ではデータ構造間での相互変換が必要な 」)GISこと( 6.1.1データ構造変換,ラスターデータをベクトルデ 「 」)ータに変換し,構成要素や位相関係を構築するためにベクトルデータベースを構築すること( 6.1.2データ媒体変換 )等が記載され 「 」ている。
「6.1.2データ媒体変換」の記載によれば,構成要件1Aは周知技術である。
また,構成要件1B,1Cの「二次元の線データへの変換「座標」,上の線分への変換」は,原告らの主張によれば,要するに,ラスターデータから取得したベクトルデータを,アーク・ノード構造データ(又はリレーショナル構造データ)に変換することである。それらが周知技術であったことは,上記各記載から明らかである。特に 「前処理された,ラスターデータは,ベクトルデータに変換される。そして最終的なデータで必要とされるあらゆる構成要素(たとえば,線分の結合としてのチェイン)や位相関係(たとえば,内包や隣接)を構築するために,ベクトルデータベースが構築される」との記載( 6.1.2データ媒体 「変換 )は,構成要件1B,1Cの構成を,直接開示ないし示唆するも 」のといえる。
原告らは,構成要件1B,1Cは,座標点列としての線データ(一次元線データ)をアーク・ノード構造データに変換する旨を主張する。乙39文献の「6.1.1データ構造変換」には,座標点列データである「全ポリゴン構造」データを「アーク・ノード構造」データに変換することも,そのアルゴリズムの示唆とともに,開示されている。原告らが,本件発明の「二次元の線データ」の一例であるとするファイDLGルデータについても,乙39文献の「4.2.5ディジタル線グラフ構造」のとおり,が本件出願優先日に周知の標準ベクトルファイ DLGル形式であったこと,同じく周知のアーク・ノード構造,リレーショナル構造と類似の構造であること等が記載されている。
これらの記載により,構成要件1Aないし1Cが,当業者にとって周知慣用の技術であることは明らかである。
)乙39文献には,ポリゴンの境界線は連続でなければならず,ソフトbウェアはポリゴンが閉じていない場合にこれを発見しなければならないことが記載され,また,見出しに「編集」とあるように,発見したエラーを編集し,閉じたポリゴンに修正することは当然の前提とされている( 6.3エラーの検出と編集。 「 」)これらの記載により,構成要件1E及び1Fが,当業者にとって周知慣用の技術であることは明らかである。
)乙39文献には,地図データに属性を付与することが記載されているc( 4.2ベクトルデータ構造」等 。 「 )これらの記載により,構成要件1G及び1Hが,当業者にとって周知慣用の技術であることは明らかである。
キV5を主引例とする主張ARC/INFO)本件発明とV5とを対比すると,構成要件1D後半「終 aARC/INFO点が始点と一致しないときはそれらの線分からなる面データを自動的に作成」のほかはマニュアルV5(乙13,14)に開示さARC/INFOれている。
線分を接続していって,開始線分の始点と終了線分の終点が一致しないときに,それらの線分の組合せを「面データ」として格納するか,それとも単なるエラーとして処理する つまり それらの線分からなる 面 (,「」。), 。, データ は作成しないかは 当業者の単なる設計事項である 実際においては,終点と始点が一致していないベクトル列も「アーMARISク」型認識セグメントとして抽出する。
よって,本件発明は,新規性又は進歩性に欠ける。
)仮に,マニュアルV5(乙13,14)に構成要件1BがbARC/INFO開示されていないとしても,構成要件1Bは,当業者に周知・慣用の技術である。すなわち,構成要件1Bは,原告らの主張によれば 「座標,点列としての線データを,アーク・ノード構造化の可能な形式のファイ」。,(), ルに書き込む ことを意味する かかる変換は文献 乙29MARIS甲44公報,乙39文献に記載された周知・慣用の技術である。
)仮に,マニュアルV5(乙13,14)に構成要件1DにcARC/INFOおける「面データ」作成アルゴリズムが開示されていないとしても,上記アルゴリズムは,文献(乙29 ,甲44公報,甲42公報にMARIS )記載された周知のものである。
クを主引例とする主張MARIS本件発明ととを対比すると,構成要件1Eのほかは文 MARIS MARIS献(乙29)に開示されている。そして,閉ループとなるべき図形のベクトルデータすべてを強調するのか,閉じていない端点のみを強調するのかは,単なる設計事項にすぎない。
よって,本件発明は,新規性又は進歩性に欠ける。
ケ甲44公報記載の発明を主引例とする主張,,,, 本件発明と甲44公報とを対比すると 構成要件1D後半 1E 1Fすなわち,閉じていないポリゴンがあったときのエラーの検出方法,修正。,, 方法のほかは甲44公報に開示されている そして 乙39文献によれば閉じていないポリゴンを発見する手段を設けることは分野にとってGIS周知・慣用の技術であり,エラー表示・修正手段(構成要件1E,1F)は単なる設計事項にすぎない。
よって,本件発明は,新規性又は進歩性に欠ける。
コ乙39文献記載の発明を主引例とする主張本件発明と乙39文献とを対比すると,構成要件1Dのほかは乙39文MARIS 献に開示されている構成要件1Dは甲42公報甲44公報 。,,,文献(乙29)に開示されているように,当業者にとって周知・慣用の技術である。
( ) 第3事件原告らの主張2アマニュアルV5は新規性及び進歩性欠如の証拠たり得ないこARC/INFOと)被告を含む無効審判請求人は,平成12年9月27日,本件無効審判a事件において,特許庁に対し,証拠として提出したのマニ ARC/INFOュアル類等を「日本語版が出版され公知となった事実を証明することが困難」であるとの理由により撤回しているのであって,これらが「特許出願前に日本国内において公然知られた発明「特許出願前に日本国 」,内において公然実施をされた発明 (平成11年法律第41号による改 」正前の特許法29条1項1,2号)に該当しないことは明らかである。
また,上記マニュアル類(日本語版及び英語版)は,いずれも「特許出願前に日本国内又は外国において頒布された刊行物 (特許法29条」1項3号)に該当しない。なぜなら,同号にいう「頒布」とは当該刊行物が一般大衆により閲覧可能な状態で配布されていることを要し 「刊,行物」とは頒布により公開されることを目的として複製された文書や図面の情報伝達媒体を指すところ,上記マニュアル類はのラARC/INFOイセンシーに限り配布されるものであって,いずれの要件も満たさないものだからである。この事実は,被告が社との間で締結したディESRIストリビュータ合意書によれば,ディストリビュータはソフトウェアパッケージ(ソフトウェアをサポートするための図解,説明書,文書を含む:第3条)に関する秘密保持義務を課されていること(第11条 ,)及び沖縄県が社との間で締結した間接的ライセンス合意書におい ESRIてもライセンシーは同様の秘密保持義務を課されていることからも明らかである(第9条 。)したがって,被告が挙げる証拠はいずれも新規性・進歩性欠如の主張の根拠たり得ない。
)被告が,営業活動の過程で上記マニュアル類に基づいた説明を行ったb,「」 。 としても マニュアルに記載された 発明 が公知となるものではない顧客への説明に用いた上記マニュアル類に記載されているというだけ, 「」 で 当該マニュアル類に記載された技術事項のすべてが 公然知られた状態になるものではない。すなわち,仮に,営業活動における説明の過程で顧客に知得された技術的事項があったとしても,公知となり得る事項はあくまでもそこで現実に説明された事項のみに限られる。したがって,マニュアル類に基づく説明を行っているという一事をもって,マニュアル類に記載されている事項がすべて「公知」となることはない。
また,ある発明の公然実施があったといえるためには,少なくとも,秘密保持義務を有しない者が発明内容を知り得る状態で特許法2条3項所定の実施行為を行うことを要するところ,被告が営業活動においての実演や機能説明を顧客に対して行ったとしても,実際に実ARC/INFO演された機能以外の機能まで公然実施されたとはいえないし,そもそもデータ処理のアルゴリズムの内容を知り得る状態での実施がなされることもあり得ない(なお,被告の主張によれば,アルゴリズムは社ESRIの営業秘密に該当するとされている(乙28。)。)加えて,仮に,本件特許出願がなされる以前において,被告がの実演や上記マニュアルによる説明を顧客に行ったことがあARC/INFOったとしても,それはデジタイザを用いたデータ入力方法に関する範囲であって,本件発明に類する技術が実演されたり,説明されたとは考えられない 「沖縄県森林情報システム御提案書 (甲30)は,本件特 。 」許出願の優先日(平成3年6月24日)直後の平成3年7月に被告が沖縄県に対して提出した提案書であるが,その7項の「地図情報の入力工程」および「作業内容 ,ならびに9項の「ハードウェア構成」の項目 」における各記載からも明らかなとおり,被告は当時なお,デジタイザによるデータ入力方法を前提とする営業活動を行っていた事実が認められ,オンスクリーン入力を含む他の入力方法については,同提案書中で一切触れられていない。
イマニュアルV5(乙13,14)に本件発明は記載されていARC/INFOないことについてマニュアルV5(乙13,14)には,当業者において発明ARC/INFOの実施が可能となるような具体的な開示はなされておらず,当該マニュアルは何ら本件発明を開示するものではない。そもそも社は,ESRIのユーザーにもマニュアル等の技術資料について秘密保持義務 ARC/INFOを課しているほか,本件訴訟においても,被告からの問い合わせに対してすらのアルゴリズム等が営業秘密に該当するとして,開示をARC/INFO拒んでいる。かかる姿勢に鑑みれば,社としては,のア ESRIARC/INFOルゴリズムを営業秘密として保護するという方針を採用しているとしか考えられず,当業者がの技術を実施できることとなるような記ARC/INFO述を,マニュアルに記載することは考えられない。
特許法29条1項3号の刊行物として記載があるとされるためには,当業者が特別の思考を要することなく実施することが可能な程度に開示があることを要すると解されているが,以下に述べるとおり,マニARC/INFOュアルV5(乙13,14)に本件発明を実施できるような開示があるとは認められない。
)本件発明とマニュアルV5(乙13,14)に記載されaARC/INFOた発明との対比について@構成要件1A本件発明の本質は,ラスターデータから取得したベクトルデータを「二次元の線データ」及び「座標上の線分」に変換した上,これを接続することにより,アーク・ノード構造を利用した面データを自動的に作成することにある。したがって,構成要件1Aの「ベクトルデータ」は面データ作成に向けた自動的なデータ変換がなされることが予定されたものである。
, () これに対し被告が指摘するマニュアルV5乙13ARC/INFOの4-6頁において記載されている「スキャニング」は,本件発明が内容とする自動的な面データ作成に用いられるベクトルデータではなく,手動でノードや中間点の別を付加するために取得されるものであって,本件発明とは無関係のものである。
スキャナーから読み込んだベクトルデータから面データの作成を自動的に行えるようになったのは,本件特許出願後に開発された別売プログラムである等を使用できるようになって以降であり,そArcScanれ以前にスキャニングしたベクトルデータから面データの作成を自動的に行うことはできなかった。
すなわち,のシステムで面データを作成するためには,ARC/INFO折れ線の頂点のXY座標のデータのほか 「キーの値」が入力される ,必要がある。ここで「キーの値」とは,折れ線の頂点の種類を示すデータであり,具体的には,アークの始点・終点については「2 ,ア」ークの中間点は「1」のデータが入力されなければならないというのが,の一貫した技術思想である(甲55の18頁下から6ARC/INFO行目以下 。したがって,ファイルから座標を読み込む場合にも,そ )れらは「キーの値」とXY座標がペアで構成されていなければならないのである(甲55の32頁 。)ところが,このキーの値はスキャナから読み取ることができるものではない。したがって,スキャニング等によりベクトルデータを取得したとしても,結局は取得後にユーザーは各ノード又はアークの中間点につき1点ごとに手作業でキーの値( 1」ないし「2 )を入力 「」しなければならない。しかし,もしもそのような作業を行おうとすれば,数万にも及ぶ座標点の一つ一つにつき,ノードが中間点かを,画面の座標数値と基図とを目視して判断しながらキー値を入れてゆくほかなく,到底現実的な作業とは思われず,デジタイザ入力の方がはるかに容易である。それ故にこそ,ではデジタイザ入力しかARC/INFO行われていなかったのである。
このように,マニュアルに記載されている,スキャニンARC/INFOグによって得られるベクトルデータは,同システムで自動的にデータ変換することにより面データの作成を行うことを予定しているものではないから,構成要件1Aの「ベクトルデータ」に含まれない。
よって,マニュアルV5(乙13)の記載は,何ら構成ARC/INFO要件1Aを開示するものではない。
A構成要件1B刊行物に発明が記載されているといえるためには,当業者がその刊行物を見れば,特別の思考を要することなく実施し得る程度にその内容が開示されている必要がある。
ところが,マニュアルV5では,コマンド,ARC/INFODXFARCコマンド,並びにコマンド,コ DLGARCSCITEXLINESCITEXPOINTマンド及びコマンドという,いわばブラックボックス SCITEXPOLYであるそれぞれのコマンドの機能が説明されているにすぎず,具体的にいかなるデータがいかなるアルゴリズムによりいかなるデータへとESRIDXFARC変換されているのかの説明は全くない すなわち社は。,コマンド等のブラックボックスをブラックボックスのまま説明しているにすぎず,何ら自社の技術を開示してはいない。
のマニュアルの記載がこの程度の記載にとどまる以上,ARC/INFOARC/INFO DXFDLG当業者がの記載を参照したとしてもファイル,,ファイル又はファイルからのカバレッジへのデーSCITEXARC/INFOタ変換プログラムを構築することは不可能である。
現に,原告Aが本件発明を行った開発に関与する際に被告が沖縄県と合意した書面には,では図形データの入力がサポートさARC/INFOれずそのためデータ変換ソフトを用意することとした旨が記載されている。さらに,平成元年に被告が関与した東京都都市計画地図情報システムの計画の報告書(71頁から5行目,72頁下から8行目)では,スキャナではラスターデータからベクトルデータへの変換はできるものの,このベクトルデータは構造化されていないため面的な認識もできず,さらに属性データの付与もできないため,単なる背景としてしか利用できないという趣旨の記載があるほか,平成3年3月に被告が提案した沖縄県森林情報システムの提案書では,被告はデジタイザを用いた多額の入力費用を要する従来技術を提案している事実が認められる。これらの事実は,まさにスキャナから取得したベクトルデータをに読み取り可能なデータ(カバレッジ)に変換すARC/INFOることは被告においても不可能であったという事実を示している。
よって,当業者がマニュアルV5を見れば特別の思考ARC/INFOを要することなく構成要件1Bを実施し得る程度の開示があるということはできず,当該マニュアルに構成要件1Bが記載されているとはいえない。
B構成要件1C構成要件1Cの「座標上の線分に変換」するとは,アークの交点でアークを分割するとともにアークの接点,交点及び線端点にノードを付して,これらのデータを線データ部及び点データ部に書き込むことによってアーク・ノード構造を完成させることをいう。
これに対し,被告の指摘するマニュアルV5の記載にARC/INFOおいては,アークの交点にノードを付してアークノードトポロジーを構築することは記載されているものの,コマンドによってアCLEANークの接点及び線端点にノードを付することについては何ら記載されていない。
そして,マニュアルV5の他の記載を参照すると,アーARC/INFOクの接点及び線端点のノードは,コマンド実行前に既に付さ CLEANれていることが記載されている。これは,が,デジタイザ ARC/INFO等による入力の際にアークの接点及び線端点にノードが付されていることを前提としているためである。
したがって,当該マニュアルの記載を見た当業者は,アークの交点にノードを付することは認識できても,アークの接点及び線端点にノードを付することについては認識し得ない。
これに対し,本件発明は,アーク・ノード構造を有しないベクトルデータから自動的にアーク・ノード構造を有した面データを作成するため,構成要件1Cにおいて交点のみならずアークの接点及び線端点のすべてにノードを付する処理を行う点において特徴があり,マニュアルV5(乙14)の開示とはこの点で相違する。
ARC/INFOよって,アークの接点及び線端点にノードを付することについてマニュアルV5に記載があるとはいえず,構成要件1CのARC/INFO「座標上の線分に変換」する処理は開示されていない。
C構成要件1D被告が指摘するマニュアルV5(乙13)5頁ないし ARC/INFO7頁の記載は,あくまでアークが右回り順に格納されていることを示すのみであり,アークを「所定方向に接続」するというアルゴリズムを開示するものではないし,示唆するものでもない。本件発明に関する知識を有しない当業者がアークが右回り順に格納されたリストを見たとしても,線分を所定方向に接続して面データを作成することを推知することはできない。
のみならず,構成要件1Dは,線分を所定方向に接続した結果として,閉領域の面データと,閉じられない面データができることを内容とし,その後の処理を選択するものであるのに対し,マニARC/INFOュアルV5には,アークを接続した結果,終点と始点とが一致しないときの処理については記載されていない。
, , 被告は 接続した線分からなる組合せを面データとして格納するか単なるエラーとして処理するかは,当業者の設計事項にすぎないと主張する。しかし,構成要件1Dの処理が周知であったという事情もない以上,マニュアルV5の記載により構成要件1Dの処理ARC/INFOが実質上開示されているものということは不可能である。
以上のとおり,マニュアルV5(乙13,14)には,ARC/INFO線分を所定方向に接続すること,及び,線分接続の始点と終点が一致しない場合における構成要件1Dの処理が記載されておらず,同マニュアルは,構成要件1Dを開示するものではない。
D構成要件1E被告の指摘するマニュアルV5における程度の記載でARC/INFOは,面データの不連続点を報知表示する構成要件1Eの開示としては不十分であり,マニュアルV5は構成要件1Eを十分に開ARC/INFO示するものではない。
すなわち,構成要件1Eは,アーク・ノード構造を利用して面データを作成するなかで発見された面データの不連続点を報知表示することにより,閉じている面データとして構成できなかった面データの不連続点を報知表示することを可能にしたものである。したがって,当業者が構成要件1Eの意義を十分に理解してこれを実施できる程度の記載というためには,構成要件1Eの処理が,線分を所定方向に接続した結果として閉じていない面データが生じ,その面データにおける端点ノードを表示するという技術思想が開示されている必要がある。
ところが,マニュアルV5では,等のコARC/INFONODEERRORSマンドがブラックボックスのまま提供された上,ダングリングノードを報知表示するというそれぞれのコマンドの機能が説明されているにすぎない。すなわち,それぞれのコマンドがいかにしてダングリングノードを認識し,また,いかにしてこれを報知表示するかを何ら開示していないのであり,ダングリングノードの認識・報知表示の処理と面データ作成処理との関係は何ら説明されていない。
したがって,当業者は,マニュアルV5の記載から,構ARC/INFO成要件1Eの意義を理解してこれを実施することはできず,結局はブラックボックスであるそれぞれのコマンドの使用に頼るしかない。よって,マニュアルV5には,当業者が特別の思考を要するARC/INFOことなく構成要件1Eを実施し得る程度の開示があるということはで, 。 きず 当該マニュアルに構成要件1Eが記載されているとはいえない以上のとおり,マニュアルV5の記載は,構成要件1EARC/INFOの開示としては不十分である。
E構成要件1G構成要件1Gは,フィーチャー属性テーブルの作成やデータがデータベースに格納されることとは全く別の意味を有する。
構成要件1Gで示された「属性データを付与可能」にすることは,( 。) 面データの識別番号ではポリゴンユーザーIDを指すARC/INFOを付与することを意味する。作成される面データの位置情報と属性情報とは分離して管理されるのが一般であるところ,これら2つのデータの関連づけにこの識別番号が利用されるのであり,識別番号の付与がなければ面データに属性を付与することはできない。そして,構成要件1Gは,この識別番号を作成されたすべての面データに一括して付与するものであり,これによって面データの位置情報と属性情報とが関係付けられるとともに,面データに属性を付与することが可能になる。
これに対し,マニュアルV5に記載されたフィーチャーARC/INFO属性テーブルの作成は,識別番号(ポリゴンユーザーID)の付与とは全く別のことを指す。マニュアルV5も「はポARC/INFOBUILDリゴン用を生成しポリゴンユーザーIDを使って既存追加属性 PATを結合する」と説明しており,ポリゴン属性テーブルの作成に当たっては,既にポリゴンユーザーIDが付与されていることが前提とされているのであり,このことからもフィーチャー属性テーブルの作成と識別番号の付与が別のことであることは明らかである。
また,データがデータベースに格納されるとのマニュARC/INFOアルV5の記載も,構成要件1Gとは無関係である。位置情報のデータベースと属性情報のデータベースとを関係付けて属性情報を付与可能にすることが構成要件1Gの処理であり,上記マニュアルの記載から構成要件1Gの内容を読み取ることはできない。
以上のとおり,被告が指摘するマニュアルV5の記載ARC/INFOと構成要件1Gの内容とは全く異なるものでありマニュ ARC/INFOアルV5は何ら構成要件1Gを開示するものではない。
)マニュアルV5(乙13,14)と他の引用例との組合せ bARC/INFOについて被告は,マニュアルV5(乙13,14)に構成要件1BARC/INFO,(), 又は1Dが開示されていないとしても これらは文献 乙29 MARIS甲44公報,乙39文献及び甲42公報に記載された周知・慣用の技術であるから,本件発明は進歩性に欠けると主張する。
しかし,後記のとおり,文献(乙29 ,甲44公報,乙39MARIS )文献及び甲42公報には構成要件1B又は1Dに相当する構成は記載されていない。
さらに,マニュアルV5は,アーク・ノード構造を利用しARC/INFOた面データを作成するための技術であるのに対し,後記のとおり,文献(乙29 ,甲44公報及び甲42公報は閉ループ構造を有MARIS )する面データの作成に関する文献にすぎず,その目的及び作用効果の点において大きく相違する。アーク・ノード構造を利用した面データを作成するために,閉ループ構造を有する面データの作成に関する技術を組み合わせること自体不可能である。このように,目的や作用効果が大きく異なっている技術を組み合わせることには大きな阻害要因がある。したがって,マニュアルV5に,文献(乙29 ,甲4ARC/INFOMARIS )4公報及び甲42公報に記載された技術を組み合わせることはできない。
ウ文献(乙29)に記載されていないことについてMARIS)の技術は,閉ループ構造で閉領域を認識する技術であって, aMARIS本件発明とは作成される面データの構造が根本的に異なることについて面の認識方法ないし面データの構造としては,@各ポリゴンを囲むループを閉ベクトルとして捉え,これを閉じた座標点列,又は閉じたベクトル列として記録する方法(以下,この方法により記録された面データを「閉ループ構造を有する面データ」という )と,Aアーク及びノー 。
ドにより構成されるポリゴンの,構成アークのリストとして記録する方法(以下,この方法により記録された面データを「アーク・ノード構造を利用した面データ」という )とがある。アーク・ノード構造を利用 。
した面データは,閉ループ構造を有する面データに比して,@データの修正が容易であり,データ量も少なくて済むこと,Aデータ解析が可能であることの点において,大きく優れている。
本件発明は,アーク・ノード構造を利用した面データを作成する技術であるのに対し,が作成するのは,閉ループ構造を有する面デMARISータにすぎない。
)本件発明ととの対比についてbMARIS@構成要件1A構成要件1Aの「ベクトルデータ」は座標点列としてのベクトルデータである。構成要件1B及び1Cでデータの構造化(線分同士の接続関係を構築すること)が行われ,構成要件1Aはその処理の前置処,「」 理としてなされるものである以上 構成要件1Aの ベクトルデータは,未だ構造化されていないデータが予定されている。
一方,では,ラスターデータから座標点列としてのベクトMARISルデータが生成される段階で既にブランチテーブル及び特徴点テーブルの構築が完了しており,ベクトルデータは初めから構造化された形で生成される。このように構造化されたベクトルデータは,アーク・ノード構造ではないものの,ベクトルデータと特徴点とが関連付けられているという点で構造化されたものであって,構成要件1Aの「ベクトルデータ」ではない。
よって,文献(乙29)の1479頁に記載された「ベクMARISトル」は構成要件1Aの「ベクトルデータ」とは全く異なるものであ, () 。 り 構成要件1Aは文献 乙29 に何ら記載されていない MARISA構成要件1Bそもそもにおいては,構成要件1Aの「ベクトルデータ」MARIS, 。 が作成されないのであるから 構成要件1Bも何ら記載されていないまた,構成要件1Bの「二次元の線データ」とは,アーク・ノード。, 構造化が可能な形式のファイルに書き込まれた線データである 一方において 「アーク」に相当するデータは,ベクトルテーブルMARIS ,記載のデータ(個々のベクトル)であるところ,ベクトルの両端に特徴点が配置されるという関係に立たない。アーク・ノード構造は各アークの両端点にノードが配置されることを本質的要素とするものであるから,のデータ構造は,アーク・ノード構造とは全く異なMARISるものである。
被告は,のブランチがアークに相当すると主張する。しかMARISし,アーク・ノード構造においては,アークの線データ部が座標点列のデータを直接に有することによって,修正の際に当該線データの座標点列のみを修正すれば足りるという優位性が得られるものであるところ,のブランチテーブルには,ブランチを構成する座標点MARIS列のデータは記録されていないから,ブランチがアーク・ノード構造におけるアークであるとはいえない。
よって,文献(乙29)には,構成要件1Bの「ベクトルMARISデータ」も「二次元の線データ」も記載されていない。
B構成要件1C,「」 そもそもにおいては 構成要件1Bの 二次元の線データMARISは存在しないのであるから,構成要件1Cは何ら記載されていない。
また,構成要件1Cの「座標上の線分」とは,線データ及び点データを書き込み,アーク・ノード構造を有するデータとして完成させたデータをいうところ,のデータは,前記Aのとおり,アーク MARIS・ノード構造を取るものではないから 「座標上の線分」が作成され ,ることはあり得ない。
よって,文献(乙29)には,構成要件1Cの「それらのMARIS二次元線データ」も「座標上の線分」も存在しないのであるから,構成要件1Cは何ら記載されていない。
C構成要件1D構成要件1Dの「該線分」は構成要件1Cの「座標上の線分」を指す。前記Bのとおり,においては「座標上の線分」は存在せMARISず,したがって「該線分」も存在しない。
において,ベクトルデータを追跡して面データを作成してMARISいく作業は,線データのいわば「抽出」とでもいうべきものであり,構成要件1Dの「接続」とは全く異なる。
まず,本件発明では,アーク・ノード構造を利用した面データが作成されるから,面データは,一つの最小面データを構成するアークのIDのリストとして定義される。すなわち,本件発明の面データは,面を構成するアーク(線データ)により定義されるという関係にあるのであり,構成要件1Dが「該線分を・・・接続」の語を用い,あるいは「それらの線分からなる面データ」という語を用いているのは,面データと線データとの間にこのようなトポロジーが存在するからである。
これに対し,では,閉面領域を構成するブランチを構成すMARISるベクトル列をベクトルテーブルから読み込んで個々の面データ毎に閉ループ構造を有する面データが作成されるのであり,面データと線データとの間にトポロジーは存在しない。すなわち,においMARISて面データは,線データに含まれる個々の直線ベクトルを読み出し,これをベクトル列として線データとは別個に記録することによって作成されるから,線データによって面データを定義するという関係にないのである。したがって,の面データ作成方法は,線データMARISから閉ループのベクトル列を抽出ないし検索して面データを記録するものであって,線データを「接続」して面データを定義するものではない。このため,データ量は本件発明に比して増大する。
MARIS 線データを所定方向に接続するアルゴリズムも 本件発明と,とでは全く異なる。すなわち,は,特定のブランチの終了特MARIS徴点において,ラスターデータである近傍画素を用いて次に追跡するベクトルを選択するものである。このような方法の場合,その判断の精度及びベクトル化が特徴点の近傍画素の数によって制限されるという限界がある。これに対し,本件発明は,近傍画素を利用して次に接続するアークを選択するものではないから,上記の精度上及びベクト, 。 ル化の限界といったものはなくよりも優れた特徴を有するMARISさらに,本件発明はアーク・ノード構造を利用した面データを自動的に作成する技術であるから,構成要件1Dの「面データ」はアーク・ノード構造を利用した面データに限られる。そして,によMARISって作成される面データは閉ループ構造を有する面データであって,アーク・ノード構造を利用した面データではないから,構成要件1Dの「面データ」とは明らかに異なるものである。
なお,被告は,一致点を認定するに際し,構成要件1Dを前半と後半に分けている。しかし,構成要件1D前半の処理は同後半の処理の前提としてなされるものであり,前半と後半とは不可分一体的に捉えるべきものである。したがって,構成要件1D全体が同一の刊行物に記載されて,初めて構成要件1Dの開示があるというべきである。
以上のとおり,においては,構成要件1Dの「該線分 「面MARIS 」データ」は存在しないし,また,は線分を「接続」するもの MARISではないから,構成要件1Dは何ら文献(乙29)に記載さ MARISれていない。
D構成要件1E被告は,構成要件1Eととの差異は,単なる設計事項にすMARISぎないと主張する。しかし,の手法(閉ループとなるべき図 MARIS形の全ブランチ列を強調表示する )の場合,どのベクトルデータが 。
修正を必要とするかは判明しても,当該ベクトルデータのどの点を修正すべきかは容易には判明しない。なぜなら,ベクトルデータの不連続点はわずか1ドットの大きさであることが往々にしてあり得,そのような場合,目視による不連続点の発見は必ずしも容易でないからである。これに対し,本件発明の手法(閉じていない端点のみを強調する )では,修正が必要となる不連続点を容易に知ることができる。 。
両者の手法は全く異なる手法である。
このように,文献(乙29)に記載された技術と構成要件MARIS1Eとは全く異なる技術であり,構成要件1Eが文献(乙2 MARISMARIS9 に実質的に開示されているものとは評価し得ない よって ) 。,文献(乙29)は構成要件1Eを何ら開示するものではない。
E構成要件1F構成要件1Fの「線データ」は,アーク・ノード構造化された一本の線データであるのに対し,における補間入力で入力されるMARIS「アーク型データ」はベクトル列のデータであり,アーク・ノード構造化された線データではない。
また,構成要件1Fの「閉領域データ」は,アーク・ノード構造を利用した面データをいうのに対し,文献(乙29)で開示さMARISれたポリゴンは閉ループ構造を有する面データであり,アーク・ノード構造を利用した面データではない。
よって,においては,構成要件1Fの「線データ 「閉領域MARIS 」データ」は存在しないから,構成要件1Fは何ら文献(乙2MARIS9)に記載されていない。
F構成要件1G構成要件1Gの「閉領域データ」は,構成要件1Fの「閉領域デー」, , タ と同様 アーク・ノード構造を利用した面データをいうのに対し文献(乙29)で開示されたポリゴンは閉ループ構造を有すMARIS, 。 る面データであり アーク・ノード構造を利用した面データではないよって,においては,構成要件1Gの「閉領域データ」はMARIS存在しないから,構成要件1Gは何ら文献(乙29)に記載 MARISされていない。
)結論cしたがって,本件発明の新規性が(乙29)によって否定さ MARISれるものではないことは明らかである。なお,本件無効審判事件において,本件発明の進歩性が(乙29)によって否定されるものでMARISないとの判断が示され,同審判は確定している。
エ特開平1-282685号(甲44公報)を主引例とする主張について)甲44公報記載の技術は閉ループ構造で閉領域を認識する発明であっaて,本件発明とは作成される面データの構造が根本的に異なることについて本件発明は,アーク・ノード構造を利用した面データを作成する技術であるのに対し,甲44公報記載の発明は,閉ループ構造を有する面データを作成するものであって,両者の相違は非常に大きい。
)本件発明と甲44公報記載の発明との対比についてb@構成要件1B構成要件1Bの「二次元の線データ」とは,アーク・ノード構造化が可能な形式のファイルに書き込まれた線データである。一方,甲44公報は,そもそもアーク・ノード構造を有するデータを作成するも, 「」 のではないから かかるデータ構造を前提とする 二次元の線データは作成されない。すなわち,甲44公報の技術で作成されるデータの構造は甲44公報の第1図(その1)に記載されているところ,同図の記載から明らかなとおり,ノードに関するデータを格納する「点データ部」に相当するデータ構造は存在しない。このように,甲44公報の技術により作成されるデータには点データ部が存在しない以上,甲44公報のデータはアーク・ノード構造を採るものではない。
被告は,甲44公報の「二次ベクトルデータ「アークデータ」」,がアーク・ノード構造に相当するものと主張する。しかし,本件発明にいう「点データ部」といえるためには特定のノードに接続しているアークのリストが記録される必要があり,オープン端点,分岐点,屈曲点の別の記録だけでは点データ部のデータと評価することはできない。すなわち,本件発明が点データ部のデータを必要とするのは,特定のノードに接続しているアークがどのアークであるかを把握することにより,線分を迅速に所定方向に接続していくことを可能にするた, ,,, めであるところ かかる把握をするためには オープン端点 分岐点屈曲点の別の記録だけでは不十分である。したがって,点データ部が存在するものというためには,ノードに接続しているアークのIDのリストが記録される必要があるところ,甲44公報には点データに関する情報を書き込む構造を有するファイルの線データ部にベクトルデータを書き込むことは開示されていない。
よって,甲44公報の発明で「二次元の線データ」が作成されることはあり得ず,甲44公報には「二次元の線データ」に関する記載はない。したがって,構成要件1Bは何ら甲44公報に開示されていない。
A構成要件1Cそもそも甲44公報においては,構成要件1Bの「二次元の線データ」は作成されないのであるから,構成要件1Cの「それらの二次元線データ」も作成されない。
また,構成要件1Cの「座標上の線分」とは,線データ及び点データを書き込み,アーク・ノード構造を有するデータとして完成させたデータをいうところ,甲44公報では,前記@のとおり,アーク・ノード構造を有するデータは構築されない以上 「座標上の線分」が作 ,成されることはあり得ない。
よって,甲44公報で「二次元線データ「座標上の線分」が作 」,成されることはあり得ないから,甲44公報には構成要件1Cは何ら開示されていない。
B構成要件1D構成要件1Dの「該線分」は構成要件1Cの「座標上の線分」を差す。前記Aのとおり,甲44公報においては「座標上の線分」は作成されない以上 「該線分」も作成されない。 ,また,甲44公報は閉ループ構造を有する面データを作成する技術であり,アーク・ノード構造を利用した面データを作成する技術ではないから,前記ウ・ )Cでについて述べたのと同様,面デーbMARISタを作成する処理は,線データの座標の抽出ないし検索というべきものであって,線分を「接続」する処理とは異なる。
以上のとおり,甲44公報では「該線分」は存在せず,また,甲44公報は線分を「接続」するものではなく,さらに面データ作成処理(構成要件1D後半)は全く記載がない。
よって,構成要件1Dは,甲44公報に何ら開示されていない。
C構成要件1G構成要件1Gの「閉領域データ」は,アーク・ノード構造を利用した面データをいうのに対し,甲44公報で作成される面データは閉ループ構造を有する面データであり,アーク・ノード構造を利用した面データではない。
よって,構成要件1Gは甲44公報に何ら開示されていない。
)乙39文献との組合せについてc後記のとおり,乙39文献には,構成要件1E及び1Fは何ら開示されていない。
また,甲44公報記載の技術では,線データに切れ等の不連続点があった場合,当該線データは「終点がオープン端点のアーク」として,そもそも追跡の対象から除外されてしまう。そのため,そのような不連続点のある線データを含むポリゴンについては追跡作業が放棄される。したがって,同技術においては開いた面データが作成されることはなく,当該面データの不連続点を報知表示することも不可能である。換言すれば,甲44公報は面データの不連続点を報知表示することが理論的に不可能な追跡アルゴリズムを採用しているのであり,甲44公報をいかなる資料と組み合わせたとしても,構成要件1E及び1Fが容易に想到し得ることにはならない。
オ「入門地理情報システム (乙39文献)を主引例とする主張について 」)本件発明と乙39文献記載の発明との対比についてa@構成要件1B及び1C被告は 「 前処理されたラスターデータは,ベクトルデータに変 ,『換される そして最終的なデータで必要とされるあらゆる構成要素 た 。 (とえば,線分の結合としてのチェイン)や位相関係(たとえば,内包や隣接)を構築するために,ベクトルデータベースが構築される』との記載( 6.1.2データ媒体変換 )は,構成要件1B,1C 「 」の構成を,直接開示ないし示唆するものといえる 」と主張する。。
しかし,上記記載は単にベクトルデータから「ベクトルデータベース」なる最終的なデータ構造が構築されることを述べたにとどまり,ベクトルデータを「二次元の線データ」に変換することを開示したものでも 「二次元の線データ」を「座標上の線分」に変換することを ,開示したものでもない。また,乙39文献には,ベクトルデータをどのように変換するのかについて全く記載されておらず,かかる記載によって何らかの技術の開示されたものと評価することは到底不可能で。,「」 , ある さらにベクトルデータベース の言葉の意味も不明であり「二次元の線データ」を指すのか 「座標上の線分」を指すのか,あ ,るいは「面データ」を指すのか全く不明である。よって,乙39文献の上記記載は何ら構成要件1B及び1Cを開示するものではない。
また,被告は 「座標点列データである『全ポリゴン構造』データ ,を『アーク・ノード構造』データに変換することも,そのアルゴリズムの示唆とともに ・・・開示されている 」と主張する。 ,。
しかし,乙39文献の記載は 「全ポリゴン構造」を有するデータ ,をアーク・ノード構造を利用した面データへと変換することを述べたにとどまり,座標点列データとしてのベクトルデータを 「二次元の,線データ」及び「座標上の線分」を経て面データへと変換することは全く開示がない。また,被告はデータ変換のアルゴリズムが示唆されていると主張するものの,乙39文献では「複雑な検索操作が必要となる」などと記載されているのみであって,データ変換のアルゴリズムは全く示唆すらされていない(座標点列データであるベクトルデータを,アーク・ノード構造化データへ自動変換する技術は,本件発明により初めて確立されたのであるから,乙39文献がこのような曖昧な記載にとどまるのは当然である。さらに,乙39文献は,全ポ 。)リゴン構造データからアーク・ノード構造データへの変換が自動的なものであることは何ら開示していない。
以上のとおり,乙39文献には,ベクトルデータを「二次元の線データ」に自動変換する処理も 「二次元の線データ」を「座標上の線 ,分」に自動変換する処理も記載されておらず,構成要件1B又は1Cは何ら開示されていない。
A構成要件1E及び1F乙39文献は,構成要件1E及び1Fの課題を示したものにとどまり,課題を達成するための構成は全く示されていない。このような課題の記載のみによって構成要件1E及び1Fが開示されたものと評価することは不可能である。
よって,構成要件1E及び1Fは,乙39文献に何ら記載されていない。
B構成要件1Gアーク・ノード構造やリレーショナル構造が属性情報を格納し得るデータ構造であることはもとより当然なのであって,構成要件1Gはこのことを前提としつつ,属性情報の付与を現実に可能とするために各閉領域データに識別番号を付与するものである。この識別番号はそれぞれの閉領域データと属性情報とを結び付ける働きをするものであり,これが付与されなければ,アーク・ノード構造を利用した面データを作成したとしても当該面データに属性情報を付与することはできない。
よって,アーク・ノード構造データやリレーショナル構造データが属性情報を格納できるということと,地図データに属性情報を付与可能にするということは全く異なり,構成要件1Gは乙39文献に何ら記載されていない。
)甲42公報,甲44公報に記載された発明及び(乙29)とb MARISの組合せについてbb MARIS 前記ウ・ )C及びエ・ )Bで述べたとおり,甲44公報及び文献(乙29)には,構成要件1Dが何ら記載されていない。
甲42公報は,その第3図の記載から明らかなとおり,この技術により作成される面データは,面データの境界線においてデータを二重に記録するものである。これは,閉ループ構造を有する面データの大きな特徴である。したがって,甲42公報はアーク・ノード構造を前提とする技術ではなく,アーク・ノード構造を有するデータである構成要件1D「」。, , の 該線分 は作成されない また 前記ウ・ )Cと同様の理由によりb面データの作成処理も,線分の座標データを「抽出」して行うのであって,構成要件1Dのように線分を「接続」するものではない。さらに,構成要件1Dの「面データ」はアーク・ノード構造を利用した面データであるところ,甲42公報ではかかる意味での「面データ」は作成されない。
MARIS 以上のとおり,構成要件1Dは甲42公報,甲44公報又は文献(乙29)のいずれにも記載されていないのであるから,これをいかに組み合わせたとしても容易に想到し得るものではない。
( ) 参加人の主張3アマニュアルV5は新規性及び進歩性欠如の証拠たり得ないこ ARC/INFOと前記( )・アの主張を援用する。
2イ本件発明の技術的意義本件発明の意義は,アーク・ノード構造を作成した上で,アークを所定方向に接続するというアルゴリズムを用いれば,ラインデータのみからポリゴントポロジーを作成することが可能であるという技術思想に至ったことにある。
,,, , すなわち 従来技術では 構造化の技術は 既に存在している点データ線データ,面データというベクトル図形データを相互に関係付けて,これ, 。, を表の形式で処理し 関係付けるという技術でしかなかった これに対し,, , , 本件発明では 発想を転換し 線データのみを入力することによって 点線,面といったベクトル図形データ自体をその構造化と同時一体的に自動的に作成することを可能としたことに,その技術の最大の特徴がある。このことによって,GISの従来技術では構造化されたデータを作成するために,その構造化すべき要素図形データを手動で,かつ,煩雑を極めた処理規則に準拠した入力方法によって作成するしかなかったものを,自動的・半自動的に作成したベクトル線データのみから,それらの同一の図形データの作成と共に,その構造化が,同時的な処理において自動的に実現することが可能となったものである。つまり,それらのベクトル線データ相互に内在的な幾何学的な法則的関係が存在することから,こうした幾何学的な法則的関係を利用するものである。このようなベクトル線データ自体に内在する幾何学的な法則的関係を利用することで,利用の軌跡がそのまま直接的・自動的に,点データ,線データ,面データ及びラベルポイントの構造化された図形データを作成することになるため,地図データの作成方法において飛躍的な自動化及び効率化を実現したものである。したがって,本件発明の新規性,進歩性は明らかである。
なお,第3事件原告らは,本件発明について 「本件発明の最大の画期 ,性は,座標点列にすぎないベクトルデータを『アーク・ノード構造』を有する線データに変換してなどに処理させることにより,面デARC/INFOータの作成をベクトルデータの段階から大幅な自動化をもって一貫してできるようになったという点にある。すなわち,本件発明は,ラスターデータからベクトルデータを作成する従来技術と,において見られARC/INFOたポリゴン作成機能の技術を架橋し,ベクトルデータから二次元の線データの変換を自動化するという,当時存在しなかった発想及び技術に基づき完成したのである 」と主張する。しかし,これは,本件発明当時の一実 。
施例に即した主張であり,本件発明の技術的意義はこれに尽きるものではない。本件発明の技術内容は,明細書の記載内容からのみ解釈されるべきであり,本件発明の技術的意義は,上記のとおり,ベクトル線データ自体に内在する幾何学的な法則的関係を利用することによってラスターデータからアーク・ノード構造に構造化され,属性付与可能なポリゴンを作成する論理全体にあるというべきである。
ウ本件発明と引用例との対比本件発明の技術的意義が,上記のとおり,体系的かつ一貫的なものである以上,引用発明も属性付与可能なポリゴンを作成する技術として対比するべきである。
したがって,本件発明の上記各構成の一つ一つが新規であるか,新規でないかを議論しても本質的に意味はない。仮に,各構成の一つ一つが新規ではなく,刊行物等によって開示されていたとしても,各構成によって構成された本件発明全体が新規であれば,本件発明は新規なものだからである。
被告は,各構成要件毎にその構成が引用発明に開示されているかどうかを主張する。しかし,このような主張は,本件発明の目的,構成,効果を隠ぺいするものであって誤導的である。本件発明の全体についての技術思想が引用発明に開示されているか,あるいは,当業者にとって容易に想到可能かという点が問題なのであり,議論の論旨が誤っている。
そこで,本件発明と引用発明を対比すると,)マニュアルV5(乙13,乙14)について aARC/INFOマニュアルV5(乙13,乙14)は,ユーザーズマニュ ARC/INFOアルであって,必ずしもポリゴン作成方法を明示したものではない。しかし,被告はこの当時のポリゴン作成方法を自白しているので,これに, (, 基づいて判断すると本件発明とマニュアルV5乙13ARC/INFO乙14)とは,初期データの入力方法,ポリゴンの定義の方法が異なる,,, (, ので 同一のものではなく かつマニュアルV5 乙13ARC/INFO14)から本件発明を容易に想到することはできない。
なお,被告は,本件発明の各構成について,マニュアルVARC/INFO5(乙13,14)に記載がある旨主張する。しかし,いずれも部分的かつ抽象的な記載で,本件発明の技術内容を開示若しくは示唆するものではない。
)文献(乙29)についてbMARIS第3事件原告らが主張するとおり,本件発明の技術内容を開示若しくは示唆するものではない。
)甲42公報記載の発明についてc第3事件原告らが主張するとおり,本件発明の技術内容を開示若しくは示唆するものではない。
)甲44公報記載の発明についてd第3事件原告らが主張するとおり,本件発明の技術内容を開示若しくは示唆するものではない。
エ仮に,本件発明の技術的意義が第3事件原告らの主張するとおりのものであるとすれば,無効論に関する第3事件原告らの主張を援用する。
11争点3-3(本件発明が冒認出願であるか)について( ) 被告の主張1仮に,を用いるイ号方法が本件発明の技術的範囲に属するものARC/INFOであるとすれば,本件特許の出願は明らかに冒認出願ということになる。
ア原告らも認めるとおり,被告は,の開発者である社のARC/INFOESRI日本におけるディストリビューターでもある。そして,これも原告らが認めるとおり,被告が過去にを導入した先には,沖縄県庁があARC/INFOった。被告は同庁に対し,昭和62年12月に「沖縄県地理情報システムの導入実施計画書」を提出している。
このときの沖縄県庁側の担当者の一人が,当時,同庁の土地利用対策課に勤めていた,本件発明の発明者である原告Aであった。の導ARC/INFO入に際し,沖縄県を代表して平成元年12月18日にライセンス契約書に署名したのも原告Aである。
上記事業に関連して,被告は,平成2年6月1日,沖縄県庁情報管理課DARC/INFO D の宛てにのユーザーガイド1巻 2巻等を送付している , ,。
は,本件特許権の出願に係る拒絶査定不服審判(平成7年審判第20192号)の際に行われた審判官との面接に,発明者の原告Aと共に参加した人物である。
以上の事実から明らかなとおり,原告Aは,本件発明の出願前に,の技術内容を熟知していた人物である。
ARC/INFO仮に,イ号方法が本件発明の技術的範囲に属するとすれば,それはと本件発明が同じであることを意味するから,原告Aは,被告ARC/INFOから情報を得たの技術内容をそのまま本件発明として出願し ARC/INFOたということになる。これは冒認出願以外の何物でもない。
イ原告らは,アークとの対応関係を伴わない単なる点列座標の組合せのベクトルデータを,が読み込み可能なデータに変換すること(一ARC/INFO次元データを二次元データに変換すること。構成要件1B)が,本件発明の本質的部分(新規性及び進歩性を有する部分)であると主張するものと解される。しかし,当該部分についても,何ら新規性ないし進歩性があるものではない。
( ) 原告らの主張2本件発明と当時のの技術は異なるものであり,その後に被告 ARC/INFOが実施しているイ号方法と当時のの技術も異なるものである。 ARC/INFO原告は,本件発明当時被告が使用していたと同様の構成が本件 ARC/INFO発明に該当すると主張しているのではないのだから,被告の主張は単なる誤解に基づくものである。
12争点4(先使用の抗弁又は自由技術の抗弁の成否)について( ) 被告の主張1ア被告は,を本件特許の出願前から使用しているものであるか ARC/INFOら,先使用による通常実施権を有する。
)被告は,昭和61年(1986年)以来,を用いて地図作a ARC/INFO成業務を行っている。被告が,昭和61年当時に使用していたバージョARC/INFO Version3 ArcGIS 8.3 ンはであり現在使用しているのは 「」,「(の」であるとはいうものの,の基礎的ArcInfo Workstation ARC/INFO )。「」 な原理やコマンドは変わっていない 被告が現在使用しているArcGISには,従前の「()」と基本的に同じソフトである ARC/INFO ArcInfo「」 , 「」 ArcInfo WorkstationGUI ArcGIS Desktop と入力を可能にするソフトの双方が含まれている。
)被告の地図データ作成方法の中で,本件特許の出願前と現在とで変わbった点は,ベクトルデータの入力方法である。
@被告は,昭和61年当時はデジタイザーを用いて紙の原図をトレースする方法でベクトルデータを手動入力していた。その後,平成元年から平成2年にかけての時期に,現在の入力方法,すなわちラスターデータを画面上に表示し,表示画面上のラスターデータをマウスでトレースしてベクトルデータを入力する方法を採用している。
しかし,両者の入力方法は,紙の原図を直接トレースするかラスターデータをトレースするかの相違しかなく,手動でトレースして入力するというデジタルデータの入力方法の原理に相違はない。少なくとも本件発明との対比の上では,本質的な相違ではない。
Aは,スキャナーで取得したラスターデータを自動的にベARC/INFOクトルデータに変換して入力する方法(自動入力方式)にも,本件発明の出願時以前から既に対応可能であった。
さらに,イ号方法のようにディスプレイ上に表示されたラスターデータの地形をカーソルでなぞり,座標値を取得したい点でボタンx,yをクリックしてベクトルデータを入力する方法も,本件発明の出願時以前から,では対応可能であったものであり,そのこともARC/INFOユーザーズガイドには記載されていた。
ARC/INFO このとおり,被告が本件特許の出願前から使用しているにおいて,出願前に既に対応可能であった入力方式に変更しても,先使用権の成立は,何ら妨げられるものではない。
Bそもそも,ベクトルデータの入力は,構成要件1Aに相当する部分であり,原告A自らが従来技術と認めている部分である。従来技術から従来技術への変更は,先使用権の成否を判断するに当たっては,実質的に同一と評価されるべきものである。
イ自由技術の抗弁, , 被告が用いるイ号方法は出願時既に公知技術であったとARC/INFO同じく公知技術であったラスターデータをトレースしてベクトルデータを入力する方法である。
本件特許の出願前からは上記の入力方法にも対応可能であARC/INFOったのであるから,被告が用いるイ号方法は,特許発明の特許出願時における公知技術と同一又は当業者がこれからその出願時に容易に推考できたものであることは明らかである。
したがって,被告は,本件特許の出願時に公知であった自由技術を用いているにすぎないから,本件特許権を侵害することはあり得ない。
( ) 原告らの主張2本件発明と当時のの技術は異なるものであり,その後に被告 ARC/INFOが実施しているイ号方法と当時のの技術も異なるものである。 ARC/INFOしたがって,先使用の抗弁及び自由技術の抗弁は,いずれも成り立たない。
13争点5(損害の額)について( ) 第3事件原告らの主張1被告は,イ号方法により作成した地図データの販売等を行うとともに,ロ号物件の製造販売等を行うことにより,本件特許権を侵害した。
被告の情報システム事業領域における売上高は1年当たり平均100億円を優に超えているから,被告が本件特許権を侵害したことにより,平成10年4月17日から平成16年1月21日までの間に得た売上高は,少なくとも600億円を下らない。
第3事件原告らは,かかる侵害行為によって実施料相当額の損害を被ったものであり(特許法102条3項 ,その金額は,売上高相当額の15%で )ある90億円を下らない。
したがって,原告Aは,平成10年4月17日から平成11年11月11日までの間に被った損害の一部請求として,少なくとも3億円を,原告会社は,平成11年11月12日から平成16年1月21日までの間に被った損害として,少なくとも7億円を,それぞれ不法行為又は不当利得に基づき,被告に対して請求することができる(なお,原告会社は,平成14年5月8日付けで第1事件脱退被告沖縄デジタルセンターに専用実施権( 事業利益「の50%」を従量実施料としている )を設定しているものの,それ以降平 。
成16年1月21日までの期間においても,同専用実施権者が被告から得るべき金額の50%に相当する金額を被告に対して請求することができる。。)( ) 被告の主張2第3事件原告らの主張を否認ないし争う。
第4争点に対する判断当裁判所は,本件発明は,マニュアルV5に記載された発明からARC/INFO当業者が容易に想到し得たものであり,進歩性欠如の無効理由を有すると判断するものである。その理由は,次のとおりである。
1マニュアルV5が「日本国内又は外国において,頒布された刊行ARC/INFO物 (特許法29条2項,1項3号)に該当するかについて 」( ) 証拠(乙17,18,21,22,37,38,41ないし44)によれ1ば,次の事実が認められる。
のマニュアル類は,社により作成されたものであり,ラARC/INFOESRIイセンシーに配布することを目的とする文書である。被告と社との間 ESRIのディストリビュータ契約によれば,のディストリビュータであ ARC/INFOる被告は,ソフトウェアパッケージ(ソフトウェアをサポートするための図解,説明書,文書を含む )に関する秘密保持義務を課され,ディストリビ 。
ュータの顧客も,ソフトウエアパッケージについて秘密保持義務を負い,顧客が一時に保有することのできるソフトウェアのコピーは3部に制限されている(乙17の11条 。また,被告は,ソフトウェアパッケージを実演し )ESRI 販売するため,ライセンシーとなることに同意した顧客から,事前に社が定めるライセンス契約書を徴求し,社の承認の後に,ライセンスESRI対象プログラム及び必要なマニュアル類を配布することになっている(乙17の4条,6条 。)のライセンシーの数は 本件発明の優先日前である平成2年 1ARC/INFO , () ,, 990年 末の時点で約2700システムであり 日本国内に限ってみても平成3年(1991年)3月の時点で約80システム(ライセンス)であった。
のライセンシーは,米国及び60以上の諸外国の森林・自然資ARC/INFO源機関,水管理機関,連邦諸機関,中央・地方政府,コンサルタント会社,石油会社,測量・地図会社及び大学等である。
ライセンシーののマニュアル類の使用実態は,次のとおりでARC/INFOある(乙41ないし44 。)オハイオ州立大学の地理学コースでは,のすべてのバージョンARC/INFO(1987年から1991年)を受領しており,バージョン3及びバージョン5のマニュアル類もその都度受領していた。そして,及び同マARC/INFOニュアル類は,地理情報システム研究室に出入りする教職員及び学生の利用に公然と供されていた。また,同研究室の教職員は,時々,社発行のESRIマニュアルの全部又は一部をコピーし,教材として学生に配布していた。また,教職員や学生が使用する目的等のために,追加の部数のマニュアルを社に求めたことが幾度かあり,それらを無料で受領している。
ESRIカリフォルニア州立大学ノースリッジ校地理学部においても,遅くとも1987年ころには,とそのマニュアルが教師及び学生により利用ARC/INFOされており,その一部が学生に参考資料として,秘密保持義務を伴うことなしに,配付されていた。
, ,ESRI 社の販売店及び販売員は 1980年代から1990年代にかけて販売現場で,ソフトウェアの性能を説明するために,将来の顧客及びビジネスパートナーに対し,上記マニュアル類(のマニュアルバージョARC/INFOン3及び5)を継続的に使用して説明し,必要に応じ,秘密保持義務を課すことなく,その抜粋(写し)を提供していた。社は,マーケティングESRI活動において顧客となる可能性がある者に上記マニュアル類を提供することを被告にも推奨しており,被告のみならず,社も,マーケティング活ESRI動において,何らの秘密保持義務を課すことなく,マニュアル類の抜粋を顧客となる可能性がある者に提供する場合があった。
( ) 前記認定の事実によれば,のマニュアル類は,マニ2 ARC/INFOARC/INFOュアルV5も含め,多数のライセンシーとその社員,従業員,学生など不特定多数の人に頒布され,その内容が公開されていること,マニュアル類自体には,ソースコード等の開示はなく(乙13,14 ,高度の秘密情報が記 )載されているものではないこと,の営業活動においては,当該マARC/INFOニュアル類が実際には厳格に秘密として管理されておらず,契約条項において定められている秘密保持条項は,実際には,ソフトウエアを念頭に置かれたものであり,マニュアルについては営業政策上厳格な秘密保持義務を課しARC/INFO ていたとまでみることはできないことが認められ 以上によれば,,マニュアルV5を含む上記マニュアル類は「日本国内又は外国において頒布された刊行物」に該当するものと認められる。
, ,「 , したがってマニュアルV5は日本国内又は外国においてARC/INFO頒布された刊行物」として,進歩性を判断する資料となるものである。
2本件発明1の各構成要件中,以下に述べるものは,いずれもその意味するところが一義的に明らかではないので,本件明細書の発明の詳細な説明を参酌して,その要旨を認定する。
( ) 構成要件1Aの「ラスターデータからベクトルデータを作成」について1ア本件明細書には次のとおり記載されている(甲1)。
)発明の技術分野a「本発明は,地域や地点毎に属性を付与された地図情報を自動的に作成する地図データ作成装置に関する( 0001 )。」【】)従来の技術b「上記地域や地点毎に属性を付与した地図情報をコンピュータに記憶させるには,先ず,デジタイザ等を用い,手作業で地図上の区域や地点の縁に沿って入力端末を移動させ,この入力端末の移動データを区域や地点の輪郭線を表す面データとしてコンピュータに入力したのち,その面データに属性を付与していた( 0004 )。」【】「また,等高線による地形のみを描いた地図等も,土木・測量用として広く使用されている。このような地図は,ときに応じて修正・更新を行う必要がある。このような地図もコンピュータに読み取らせ,図形の歪みを自動的に直す等の補正を行っている。このような場合のコンピュータ処理では,上記のような面データの概念がなく,単に線を表すベクトルデータとして取り扱われ,説明文等を付加して表示することはできても,図形データに属性を付与するということはできない。又,線データの「切れ」などの自動検出が出来ず,又,家形のような直角部を有するベクトル認識対象にあっては,例えば当該家形が6画形であれば6本の線データに分解されて,一本の折れ線データに一括して自動的にベクトル化する事は出来ない為,地形図のような大量かつ重畳的な原図データから直接ベクトル処理した後で家形や道路等を種別分けする作業は著しく困難であり,予め各々のトレース図の作成を必要とする状況にある( 0005 )。」【】)従来技術の問題点c「・・・これらの面データの入力は上述したように全て手作業によって入力されるものであるが,コンピュータ処理において,上述のようにして入力された一つ一つの面データに,後の処理で属性を割り当てるためには,それぞれの面データが閉面を構成していなければならない。面データの表す輪郭線が画面表示上では視覚的に閉じている場合であっても,コンピュータ内部のデータとしては開いており,不連続となっていれば,この面データに与えた属性がこの不連続点から周囲に漏洩して不都合を生ずる。このため,上述のデジタイザによる面データの入力作業は熟練を要し,極めて手数のかかる作業である。従って,人件費が地図情報作成コストの50%以上,ときには90%を占めるとさえいわれ,・・・ ( 0006 )」【】「このように,従来は,地図の輪郭線データを手作業で入力しなければならず,また,線データを自動的に読み取ることができるものは,その後の属性付与の処理ができないという状態であり,又,線の「切れ」の自動検出や,直角部を有するベクトル化対象物の一本の折れ線への自動一括長ベクトル化も出来ないという状況であり,一貫して自動的に地図情報を作成する方法も装置も存在しなかった( 0008 )。」【】d)発明の目的「本発明は,上記従来の実情に鑑みてなされたものであり,その目的とするところは,地域や地点毎に属性を付与可能なように保存した地図情報を大幅に効率良く自動的に作成することが容易にできる地図データ作成方法及び装置を提供することである( 0009 )。」【】e)実施例「・・・図1は本発明に係わる一実施例の構成図である。同図において,画像ベクトル線データ発生装置1は,地形図等の原図,あるいは,例えば図6(a)に示すような回路配線画像等を自動的に読み込んで画像に対応する電気信号を発生するイメージスキャナ1-1,そのイメージスキャナ1-1から入力される電気信号からディジタル・イメージ信号を生成するパターン認識モジュール1-2,パターン認識モジュール1-2により生成されたディジタル・イメージ信号から細線データを抽出しベクトルデータを作成して,例えば図6(b)に示す線データ画像作成処理を行う線データ画像処理装置1-3,及びその線データ画像処理装置1-3により作成されたベクトルデータを後述する線データ画像処理()。」 用Lファイル2aとして記憶するRAM I 1-4からなっている( 0011【0012 ) 【】,】f)発明の効果「本発明によれば,地形図等の原図を読みとって自動的に作成されたベクトル線データを面データに変換し,その不連続部を修正して閉領域データを作成することが迅速かつ容易にできるので,地図の各部を特定して属性を与える地図情報の制作が容易となるため,地図情報制作の費用を大幅に削減することが可能となる。さらに,地図情報を短期間に作成することができるため,地図情報を変化に即応できる管理資料として十分に活用可能となる( 0046 )。」【】イ本件明細書の上記記載について本件明細書に記載された従来技術とその問題点の記載によれば,従来技術として,@デジタイザ等を用い,手作業で地図上の区域や地点の縁に沿って入力端末を移動させ,この入力端末の移動データを区域や地点の輪郭線を表す面データとしてコンピュータに入力したのち,その面データに属性を付与する方法と,Aコンピュータにより自動的に地図の輪郭線データを読み取らせる入力とがあった。@の場合,この入力はすべて手作業によって行われていたところ,コンピュータ処理において,入力された一つ一つの面データに属性を割り当てるためには,それぞれの面データが閉面を構成していなければならず,視覚的に閉じている場合であっても,コンピ。, ュータ内部のデータとして開いている場合には不都合を生じる そのため, 。, 入力作業は熟練を要し 極めて手数のかかる作業とされていた Aの場合面データの概念がなく,単に線を表すベクトルデータとして取り扱われる, 。, ことから 図形データに属性を付与することができなかった このように@の場合,地図の輪郭線データを手作業で入力しなければならず,また,, , Aの場合 地図の輪郭線データを自動的に読み取ることができたとしてもその後の属性付与の処理ができないという状況にあった。そこで,本件発明は,属性を付与可能なように保存した地図情報を大幅に効率良く自動的に作成することが容易にできる地図データ作成方法及び装置として発明されたものである。
したがって,本件発明の課題は,地図情報を,属性付与が可能である閉鎖された面データとして入力する作業を効率良く行うことにある。このような課題の解決は,@地図情報をベクトルデータとして入力する作業の省力化,Aベクトルデータから閉じた面データを作成する作業の省力化によって達成されるものである。
このような課題のうち,課題@は構成要件1Aに,課題Aは構成要件1Bないし1Fに対応するものである。そして,二つの課題のすべてを自動化しなくても効率よく自動的に作成することを容易にするという発明の目的を達成することは可能であることからすれば,請求項1及び2に規定されている本件発明が両方の課題を共に自動化により解決する手段を提供したものと解すべき必然性はない。特に,構成要件1Aの文言が,構成要件1Dと異なり,ベクトルデータの作成方法について「自動的に」との限定を加えていないことからすれば,構成要件1Aが課題@を自動化により解決した構成を規定したものと解する理由はなく,本件発明は2,課題Aを自動化により解決した発明と解するのが合理的である。
なお,本件明細書の実施例にはラスターデータを読み込んで自動的にベクトルデータを作成する工程しか開示されていないこと,発明の効果欄には 「原図を読み取って自動的に作成されたベクトル線データを面データ ,に変換し 」との記載がある。,しかし,上記のとおり,原図を自動的に読み取って得られるラスターデータからベクトルデータを作成する過程において,オンスクリーン入力方式という手作業の介在する手法を採用することは,従来技術として記載されているデジタイザー方式と対比すれば,本件発明の課題@を解決する有効な手段の一つということができ,実施例にベクトルデータの自動作成方式しか記載されていないからといって,課題を解決する手段がベクトルデ,, ータの自動作成方式に限定されるものと解することはできないこと 及び発明の効果欄における「自動的に作成されたベクトル線データを面データに変換し」における「ベクトル線データ」とは,構成要件1Bの「二次元」 ,, の線データ を指すものと解するのが相当であり 当該記載を考慮しても構成要件1Aの「ベクトルデータの作成」が自動的に行われることを要するものと解することはできない。
ウ以上のとおりであるから,構成要件1Aの「ラスターデータからベクトルデータを作成」については自動作成方式に限定されるものではなく,オンスクリーン入力方式によるものも含むと解すべきである。
( )構成要件1Bについて2構成要件1Bは 「線端を示す点データを含む二次元の線データに変換」 ,というものであり 「二次元の線データ」の意味を具体的に特定する記載は ,ない。
ア本件明細書には次の記載がある(甲1 。)「図2( )は,上記画像ベクトル線データ発生装置1のRAM(I)1a-4に格納される線データ画像処理用Lファイル2aの構成図,同図( ) bは,上記閉領域属性データ作成装置3のRAM(U)3-2に格納される閉面データ画像処理用Dファイル2bの構成図である。
同図( )の線データ画像処理用Lファイル2aは,それぞれ独立して画a像の輪郭を示す線を表す1レコードのデータからなり,1レコードがヘッダー部21及びデータ部22からなっている。ヘッダー部21は,レコードの区分を示すクラス部21-1,レコードが示す線の形状等を示すコード部21-2,及びデータ部22の長さを示すリスト部21-3からなっている。そして,データ部22は,線を表す座標データを格納するパラメータ部(@)22-@(@=1,2・・・n)から構成される。これらの線データは,例えば図14( )に示す十字の画像を,点()と点 a x a-0, y a-0x a-1, y a-1 x b-0, y b-0x b-1,( (),(( )とを結ぶ線A 1レコード及び点)と点() ,y b-1 )とを結ぶ線B 1レコード の2本の線データとして表してもよくまた同図( )に示すように,上記十字の交点で線を分割し,A,B,C及bびDの4本の線データ(4レコード)として表してもよい。さらに,1点折れ線AB及び1点折れ線DCと表すこともできる( 0015【0。」【】,016 )】「また,図2( )の閉面データ画像処理用Dファイル2bは,同図( )のb a線データ画像処理用Lファイル2aとは全く異なるファイル構成であり,閉領域データを取り扱うための,例えばDLGファイルと同様な構成になっている。すなわち,ファイル構成を示すデータを格納するヘッダー部2b-1,折れ線の頂点や線端を示す点データを格納する点データ部2b-2,閉領域の少なくとも1つの属性を示すデータを格納する領域データ部,, 。」 2b-3 及び 線データを格納する線データ部2b-4からなっている( 0018 )【】「次に,上記線データ画像処理用Lファイル2aのデータを閉面データ画像処理用Dファイル2bに変換するCPU31の処理動作を図4及び図5のフローチャートを用いて説明する。なお,この処理は特には図示しないレジスタi及びjを用いて行われる。
図4は,データ変換装置2の1例を示すものであり,先ずステップS1で線データ画像処理用Lファイル2aを読み込む。次にステップS2で,ファイルヘッダー部21のリスト部21-3から要素数を読み出しレジスタiに格納する。続いてレジスタiの値を判別し 「0」でなければ読む ,べき要素があるのでステップS5に進む。ステップS5では,要素レコードiを読み出し,その要素iの先頭部の要素種データ(すなわちクラス21-1及びコード21-2)を読み出しレジスタjに格納する。続いて,ステップS6でレジスタjの値を判別する。そして,値が「1」〜「7」であれば,それぞれステップS7〜ステップS13に進み,要素レコードiの要素種データに続いて格納されている座標データ(すなわち要素数22-1〜22-n)を読み出して,その読み出した座標データを閉面データ画像処理用Dファイル2bの線データ部2b-4に転送して所定位置に書き込む。
「」 「」,,, 上記レジスタjの値は 1 〜 7 まで それぞれ直線 1点折れ線2点折れ線・・・7点折れ線,及び8点以上折れ線を示している。また,上記ステップS6で,レジスタjの値が「7」より大であれば,要素の種類は線以外のデータを表しており,この場合はただちにステップS14に進む。次に,上記ステップS3で,レジスタiの値が「0」ならば,要素レコードはすべて読み出して1図形分の処理が終了しているのでステップS15に進み,面データの作成を行って処理を終了する( 0020】。」【ないし【0022 )】イ前記アのとおり,本件明細書の実施例には,構成要件1Aの「ベクトルデータ」に相当するLファイルと,構成要件1Bの「二次元の線データ」に相当するDファイルが記載されている。そして,Dファイルは「Lファイル2aとは全く異なるファイル構成であり,閉領域データを取り扱うための,例えばDLGファイルと同様な構成になっている 」と説明されて。
いる。このような記載によれば,構成要件1Bの「二次元の線データ」とは,閉領域データを取り扱うための線データであり,その一例としてDLGファイルが示されているものと解するのが相当である。
このように,構成要件1Bの「二次元の線データ」とは,閉領域データを構成し得ない単なるベクトルデータ(構成要件1A)とは異なり,閉領域データを構成し得る線データを指すものと解釈することができる。そして,Dファイル及びDLGファイルは,このような閉領域データを構成し得る線データの一例として挙げられているにすぎないものと解すべきである。
( ) 構成要件1Cについて3構成要件1Cの「二次元線データを座標上の線分に変換」の意味が一義的に明らかではないので,これについて判断する。
ア本件明細書には次の記載がある(甲1 。)「次に,上記面データの作成処理について,図5に示すフローチャートを用いて説明する。先ずステップS51で,上記閉面データ画像処理用Dファイル2bに作成した線データを読み出して,線分に分解する。この線分への分解処理は,上記読み出した線データを,他の線データとの接点,交点で分割して,途中に接点や交点を持たない線分に細分し,それらの各線分に線分番号を付与する処理である( 0023 )。」【】「」 , , イ構成要件1Aの ベクトルデータ は 交点で線を分割されていようとされていまいと,どちらでも構わないものである( 0016。このよ【】)うな「ベクトルデータ」を構成要件1Bの「二次元の線データ」に変換した場合,交点が存するものと存しないものとのいずれも含むものと考えられる。このように 「二次元の線データ」には交点が存するものと存しな ,いものとがあるところからすれば,構成要件1Cの「二次元線データを座標上の線分に変換」とは 【0023】に説明されているように,二次元 ,の線データを,途中に接点や交点を持たない線分に細分する工程であるものと解するのが相当である。
( ) 構成要件1Dについて4構成要件1Dの「終点が始点と一致したときはそれらの線分からなる面データ (閉じた面データ)と「終点が始点と一致しないときはそれらの線分 」からなる面データ (閉じていない面データ)の意味が一義的に明らかでは 」ないので,これについて判断する。
ア本件明細書には次の記載がある(甲1 。)「次に,ステップS53で,それらの線分を始点及び終点に基づいてソートし,続いてステップS54で,それらソートした線分を一定方向に接続していく。この接続方向は,時計回り,逆時計回りいずれでもよい。線分の終点が分岐点であった場合,接続される同一始点を有する線分が複数存在する。上記接続方向が予めいずれか一定方向へ定められていることにより,それらの複数の線分の中から,共に面データを構成する線分を自動的に選択して接続することができる。
そして,ステップS55では,接続された線分の終点の点種を判別し,最初の線分の始点と同一の座標であるか,または次に接続する線分がない孤立点であった場合は,接続処理を終了してステップS56に進む。
ステップS56では,接続された一連の線分によって構成された面データに面データ番号を付与して閉面データ画像処理用Dファイル2bに再格納する。
上記ステップS55で,接続された線分の終点の点種が最初の線分の始点と同一の座標ではなく,また,孤立点でもないときはステップS54に戻って次の線分を接続する( 0025】ないし【0027 ) 。」【 】イ本件明細書の上記記載によれば,構成要件1Dの工程は,座標上の線分に変換された二次元線データを,一定の方向に接続していって,終点が始点と一致したときは,それらの線分からなる面データの閉領域データを自動的に作成し,一方,終点が始点と一致しないときはそれらの面データを自動的に作成するというものである(構成要件1Eにおいてその不連続と。)。,「」 なる始点及び終点を報知表示することになるしたがって面データは,単に線分を所定方向に接続することによって構成される一本以上の線分の組合せを意味するにすぎないと解するのが相当である。
なお,本件発明にいう「面データ」とは,ポリゴンのことであり 「面,データ」には「閉じた面データ」と「閉じていない面データ」とがあるとの解釈は 「閉じていない」ポリゴンという概念は一般的に存在しないも ,のであるから採用し得ない。本件明細書の【0004】の記載は,従来技術を説明するものであって,本件発明において作成される「面データ」の内容を説明するものではない。本件明細書の【0025】ないし【0027】の上記記載に照らせば,構成要件1Dの「面データ」とは,上記のとおり,一本以上の線分の組合せを意味するにすぎないと解するのが相当である。
( ) 構成要件1Eについて5「 」 構成要件1Eは 該面データの前記不連続となる始点及び終点を報知表示するものである。既に述べた「面データ」の定義からすれば,構成要件1Eは,一本以上の線分の組合せが不連続となっている始点及び終点を報知表示することを意味することになる。
( ) 構成要件1Fについて6構成要件1Fは「該不連続点から任意の点又は線へ接続する線データを入力に基づいて生成することにより該面データに対応する閉領域データを作成」するというものである。構成要件1D及び1Eからすれば,構成要件1Fは,不連続となっている面データ(一本以上の線分の組合せ)について,任意の点又は線へ接続する線データを入力して面データの閉領域データを作成することを意味することが明らかである。
3マニュアルV5における記載についてARC/INFO( ) 証拠(乙13,14。訳文は甲11,19,乙30,31 )によれば, 1 。
平成元年(1989年)に発行されたのユーザーズガARC/INFO Version 5イドであるマニュアルV5( ・ ARC/INFOUsers Guide ARC/INFO Volume 1・)には,次の記載がある。 Version 5.0, Volume 2Version 5.0.1ア冒頭「は,地理データの入力,処理,解析,表示に利用される地 ARC/INFO理情報システム(GIS)です(乙13・乙31の1-1頁) 。」イの機能ARC/INFO「地理情報システムは,ディジタル形式で地理データを処理するために利用されます。地理情報システムによって実行できる機能は,4つのカテゴリーに大きく分類されます。 )入力, )解析, )データ管理, )表示と1234変換,,, 。 入力は データのデジタイジング 編集 フォーマット変換を含みますARC/INFO 入力操作の目的は,電子式又は光学式で,データを取り込み,が利用できる形式に変換することです。へデータを入力する方ARC/INFO法には,デジタイジング,スキャニング,法規制及びトラバース測量のデータを入力するために座標幾何学を利用する方法,他の様式からデータを変換する方法があります (例えば,画像とグリッドのファイル,コンピ 。
CADDLG ュータ・エイデッド・ドラフティング&デザイン()ファイル,データファイル,データ,ファイルなど(乙13・乙31DEMDIME 。)」の1-4頁)ウ座標の入力と変換「 , , , デジタイジングデジタイザー上の図形をなぞることにより 点 線ポリゴン外周を入力することができます。デジタイザーカーソルのボタンが押される度毎に,カーソルのｘ,ｙ座標が図形の部分として記録されます。ｘ,ｙ座標は,テーブル座標でも実測座標でも良いです(乙13。」・甲11の4-4頁)「() ,() スキャニング 走査地図をスキャニングして ラスター値ON/OFFを一連の座標に変換する(ラスターベクトル変換です)装置によって実行されます。はそのような座標を,デジタイザーで入力された座ARC/INFO標と同じように取り扱います(乙13・甲11の4-6頁) 。」「 。 多種の産業標準及び政府支援フォーマットからのデータを変換します多種の産業標準及び政府支援フォーマットへデータを変換します ・・・。
ファイル・・・製図交換ファイル(・・・USGS DLGAutoCADDXF )及び地図印刷・出版のための2進法ファイル・・・」ScitexDIGIT Scitex(乙13・甲11の4-7頁)エ隣接関係「マップカバレッジのエリアフィーチャー間の隣接関係は,アークトポロジーを用いて表現されます。ポリゴンの境界線の各アークには向きがあり,左側ポリゴン,右側ポリゴンの値を持つので,どのポリゴンが隣接しているかは,容易に知ることができます。では,以下のようにARC/INFO隣接関係が実行されます。
すべてのアークに,1から順次,番号がふられます。
すべてのアークには 向きがあります すべてのアークは1つのノード 起 ,。 (点ノード)から始まり,別のノード(終点ノード)で終わります。
ポリゴンが作成される時に(つまり,各ポリゴンを定義するアークのリストが作成される時に ,各ポリゴンに順次番号がふられます (この番号 ) 。
は,ポリゴン内部番号と呼ばれます )。
各アークには向きがあり,その両側にポリゴンをもつので,左側ポリゴン番号と右側ポリゴン番号のリストができます(乙13・乙31の5- 。」8頁)オアークノードトポロジー「ノードは,アークの端点です。各アークには,始点ノード(アークの始まる点)と終点ノード(アークの終わる点)があります。これは,アークの向きを明確に格納するのに役立ちます。各アークは,向きを持ち,各ノードで出会うアークのリストが示されるので,アークのネットワークを通る経路は,容易に発見できます。では,以下のように接続関ARC/INFO係が実行されます。
すべてのアークは,1から順次,番号をふられます。
すべてのノード(アークの端点)も,また,順次,番号をふられます。各アークにおいて,最初のバーテックスが始点ノードであり,最後のバーテックスが終点ノードです(乙13・乙31の5-9頁) 。」カポリゴントポロジー「アークは,ラインを定義するｘ,ｙ座標の順序づけられたシリーズ・・・として格納されます。アークに関して格納される座標の順序は,アークの方向を定義します。
, , 各アークのユーザーIDの他に マップカバレッジのすべてのアークに1から順次,番号がふられます (この番号は,内部アーク番号と呼ばれ 。
ます )。
ポリゴンは,その境界線を形成するアークの番号と,アークのリストによって定義されます ・・・。。
は,自動的にポリゴンアークリストを作成し,更新しCLEAN, BUILDます (つまり。ポリゴントポロジーを生成します(乙13・乙31 。 。)」の5-7頁)また,ポリゴントポロジーの具体例では,アークのリストを作成してポリゴンを生成している(乙13・乙31の5-7頁 。この具体例につい)ては,次のとおり理解することが可能である。すなわち,特開平1-274285号公報(甲42)には 「任意のベクトルを選択し ・・・,そ , ,のベクトルを基準にして接続するベクトルを検索し,第3の回路部13でポリゴン化する。検索する方向は予め設定しておく。接続するベクトルが複数存在する場合には,接続する角度により選択を行い,ポリゴン同士が重ならないようにする(3頁右下欄5行ないし11行 」との記載があ 。」 )り,特開平1-282685号公報(甲44)には 「追跡の開始アーク,, ,, をA1とするとき 現アークA1の終端において 次の追跡候補アークはA2(正方向)及びA4(逆方向)であるが,現アークA1に対して最も右に折れる接続ベクトルを持つアークA4を選択する(6頁右上欄2。」0行ないし左下欄4行)との記載があり,これらの線分を一定の方向に選択・接続する技術は周知技術であると認められる。そして,この周知技術とマニュアルV5における上記説明からすれば,当業者は,ARC/INFO同マニュアルにおける上記具体例をアークを右回り方向に接続することによりポリゴンを作成しているものと理解することができるのである。
キ物理的ハードウェアにグラフィック端末(タブレットが接続されている )が接ARC/INFO 。
続された使用態様,にデジタイザーが接続された使用態様が図ARC/INFO示されている(乙13・甲11の8-2頁 。)「・・・デジタイザー上のマップを登録するために,デジタイザートランスフォーメーションカバレッジが使用されている場合は,がARC/INFO受け取ったデジタイザーの座標は,自動的にカバレッジ座標に変換されます。
デジタイザーは,典型的にカバレッジフィーチャーのデジタイジングおよび編集というような高い精度が要求される作業に使われます。フィーチャーの位置の入力が必要とされる全てのカバレッジの自動入力は,精度を保つために,デジタイザーで行う必要があります(乙13・甲11の。」8-4頁)クカバレッジの作成手順「におけるカバレッジの作成手順の7つのステップを以下にARC/INFO示します。
1.デジタイジングのためのマップシートを用意します。
2.カバレッジをデジタイザー入力します。
3.デジタイジングエラーを発見して訂正します。
4.フィーチャーを定義し,トポロジーを生成します。
5.トポロジーエラーを発見して訂正します。
6.カバレッジフィーチャーに属性を付与します。
7.属性コーディングミスを発見して訂正します(乙13・甲11の。」10-2頁))ステップ2:カバレッジのデジタイザー入力a「カバレッジのデジタイザー入力は,アークフィーチャーとラベルポイントフィーチャーに関する一組のコーディングファイルに,X,Y座標のレコードを追加するプロセスです。デジタイザーカーソルを使用して,各マップフィーチャーを正確にトレースします。デジタイザーのカーソルボタンを押す度に,新しいｘ,ｙ座標(バーテックス)がフィーチャーに追加されます。アークをデジタイザー入力するには,トレース。(, する時にアークに沿ってとびとびにカーソルキーを押しますつまり‘点を接続します。各ラベルポイントは,単一のバーテックスとし ’)て入力します。デジタイザー入力の目標は,可能な限り正確に,カバレッジにアークおよびラベルポイントを加えることです ・・・ (乙1。」3・甲11の10-3頁,10-4頁))ステップ3:デジタイジングエラーの発見及び訂正b「このステップでは,アーク及びラベルポイントの位置が正確にデジタイズされているかを確認します。デジタイズされたマップシートの正確な縮尺で確認のためのプロットを,作成します。次に,その2つを比較し,以下の事柄について確認します。
デジタイジングの時に,アークは正確にトレースされましたか (地図。
はうまく重なり合いますか )。
アークまたはラベルポイントが抜けていませんか。
アークの終点(ノード)は正確に一致していますか。また,アークが接続するべき位置に,ダングリングノードがありますか(乙13・甲。」11の10-4頁)「・・・ダングリングノードは,ダングリングアークのノードで,どこにも接続していません。通例,ダングリングノードによりポリゴンが正しく閉じていないこと(アンダーシュート ,アークが正しく接続し )ていないこと,アークが他のアークとの交点を通過してデジタイズされたこと(オーバーシュート)等が確認できます ・・・以外。
EDITPLOTに, でも,ダングリングノードは,ディスADS, ARCPLOT, ARCEDITプレイされます。ダングリングノードは,常に四角形マークで示されます。のコマンドでも,カバレッジに存在するダンARCNODEERRORSグリングノードはリスト表示されます(乙13・甲11の10-6 。」頁))ステップ4:フィーチャーの定義及びトポロジーの生成c「全てのデジタイジングエラーを訂正し終ったら,コマンド BUILDとコマンドを使用して,フィーチャートポロジーと最小限度の CLEANフィーチャー属性テーブルを作成します。しかし,,の BUILDCLEANうちどちらのコマンドを使うべきかを知っている必要があります ・・。
・ (乙13・甲11の10-7頁ないし10-14頁) 」)ステップ5:トポロジーエラーの発見及び訂正d「フィーチャートポロジーが生成されると,2つのタイプのエラーを調べることができます。閉じていてポリゴン(判決注:閉じていないポリゴンの誤記と認める )と接続しないライン(アンダーシュートとオ 。
ーバーシュート)を確認するために,ノードエラーをプロットすることができます。これらについては ‘ステップ2 (判決注:ステップ3 ,’の誤記と認める )で説明しています。また,ポリゴンについては,ラ 。
ベルポイントエラーを確認することができます。すなわち,複数のラベルポイントを持つポリゴンと,ラベルポイントを持たないポリゴンを確認することができます 」。
「エラーを発見したら,エラーを訂正するために,多数のコマARCンドを使用することができます。ノードエラーを訂正するためには。,ARCEDIT のプログラム・・・を使用します ラベルエラーについては及びを使用します。しばしば,エラーを訂ARCEDITCREATELABELS正するためには,アークを何本か削除して,それらをデジタイズし直すしか方法がない場合があります。カバレッジにそのような編集を行った後には,ほとんどの場合,フィーチャートポロジーも更新する必要があります ・・・トポロジーエラーを訂正するためにアークを編集した場 。
合は,トポロジーを更新するために若しくはのどちらCLEANBUILDを使うかを決める必要があります ・・・ (乙13・甲11の10- 。」10頁ないし10-14頁)ケコマンドについてaBUILD)BUILD 「カバレッジの要素属性テーブルを作成または更新します。
のオプションを指定したときは,ポリゴンとアーク・ノード・POLYトポロジーを定義し,オプションを指定したときはアーク・ノー LINEド・トポロジーを定義します。ポイント要素とその属性はオプ POINTションで作成します(乙14・甲19の113頁) 。」「とは類似したコマンドで,どちらもカバレッジ・トBUILDCLEANCLEANポロジーを定義します 基本的な違いは カバレッジの処理時に 。,ではファジー許容範囲が使用されるのに対し,では使用されなBUILDいということです。これはが交点を検出し,作成できるのに対 CLEANし,はそれができないことを意味します。しかし,ではBUILD BUILDファジー許容範囲が使用されないため,トポロジーの作成時には座標が調整されません(乙14・甲19の114頁) 。」「は座標エラーのあるカバレッジに実行してはなりません。
BUILD, BUILDPOLY にオプションを指定したときは問題の生じるエラーには交差するアーク(交点にノードが定義されていない ,閉じていないポ), 。 リゴンまたは一致するノードのないノード 細長いポリゴンがありますカバレッジ要素の座標をコマンドで修正してください(乙ARCEDIT 。」14・甲19の118頁)のカバレッジのファイルのデータ例が具体的に記載ARC/INFOAATされ,ファイルには,アーク・ノード・トポロジーが格納されてAATいることが示されている(乙14の7頁・甲19の119頁 。)bCLEAN)「正しいポリゴンまたはアーク・ノード・トポロジをもつカバレッジを作成します。このためには幾何学的な座標の誤りを修正・訂CLEAN正し,アークをポリゴンに組み立て,各ポリゴンまたはアークの要素属性情報を作成します(つまり,またはを作成します(乙PATAAT )。」14・甲19の125頁)「はカバレッジ・ノードとポリゴンを明確にするためにカバCLEANレッジ・アークとラベル点に幾何学的解析を実行してポリゴンおよびアーク・ノード・トポロジーを構築します。によって行われる具CLEAN体的な幾何学的解析は次のとおりです。
はアーク間の交点を見つけ,アークを分析し,交点にノードCLEAN(アークの終点)を作成します。
の実行時に,2つ以上のアーク座標が互いにファジー許容範CLEAN囲内にあるときはそれらが1つにされます(同じ座標点になる 。)・・・はアークで囲まれる領域を明確にしてポリゴンおよびアーク CLEAN・ノード・トポロジーを作成し,各ポリゴンの境界を定義するアークのリストを作成します。はまたノードに番号をつけ,各アークのCLEAN開始ノードと終了ノード,各アークの右右の内部ポリゴン番号を設定します(乙14・甲19の126頁ないし128頁) 。」のカバレッジのファイルのデータ例が具体的に記載ARC/INFOAATされ,ファイルには,アーク・ノード・トポロジーが格納されてAATいることが示されている(乙14の11頁・甲19の135頁 。)cNODEERRORS)「カバレッジの中で潜在的エラーのあるノードをリストします(乙。」14・甲19の373頁)dCREATELABELS)「カバレッジ・ポリゴンのラベル点を作成します。新しいラベル点のユーザIDｓは自動的に割り当てられます ・・・(乙14・甲19 。。」の165ないし167頁)eDLGARC)「標準または任意形式のデジタル・ライン・グラフ()ファイDLGルを一組のカバレッジに変換します ・・・ (乙14とそ ARC/INFO 。」のD・乙30の192ないし200頁)AppendixfDXFARC)「図面交換ファイル()をカバレッジAutoCADASCIIDXFARC/INFOに変換します ・・・ (乙14とそのF・甲19の209な 。」 Appendixいし215頁)gSCITEXLINE, SCITEXPOINT, SCITEXPOLYAppendix ) (乙14とそのG・乙30の481ないし487頁)「・・・ファイルをラインSCITEXLINESCITEXDIGITARC/INFO・カバレッジに変換します 」。
SCITEXPOINTSCITEXSYMPLACEARC/INFO 「・・・ファイルをポイント・カバレッジに変換します 」。
「・・・ファイルをポリゴSCITEXPOLYSCITEXDIGITARC/INFOン・カバレッジに変換します 」。
( )に開示されている構成について2ARC/INFO Version 5上記認定事実によれば,マニュアルV5には以下の構成が開示 ARC/INFOされている(以下 「構成A′」のようにいう。 , 。)A′地形図等の原図をスキャニングして得られるラスター値を,ラスター・ベクトル変換により一連の座標に変換する(乙13の4-6頁 ,)B′該ベクトルデータを,のカバレッジに変換し(乙13・ARC/INFO乙31の1-4頁,4-7頁,乙14とそのF・甲19 Appendixの209ないし215頁,乙14とそのD・乙30の1 Appendix92ないし200頁,乙14とそのG・乙30の481 Appendixないし487頁,乙14の7頁・甲19の119頁,乙14の11頁・甲19の135頁)C′コマンドによってアークの交点にノードを付してアークノCLEANードトポロジーを構築し,アークの接点及び線端点にも同様の処理を行い(乙14・甲19の126頁ないし128頁 ,)D′アークを右回り方向に接続し,アークが閉じている場合にはポリゴンを作成し(乙14・甲19の127頁・128頁・113頁,乙13・乙31の5-7頁,乙13・甲11の10-4頁,乙14・甲19の114頁,118頁)E′コマンドやによって 「閉じていないポNODEERRORSARCEDIT ,リゴン」と「接続していないライン」をダングリングノードとしてエラー表示し(乙13・甲11の10-4頁ないし10-6頁,10-7頁ないし10-14頁)F′ダングリングノード等のエラーを発見したら,によるデARCEDITジタイザー入力によりエラー訂正し,アークを編集した後に再度若しくはコマンドを実行して,トポロジーを更新しCLEANBUILD(乙13・甲11の10-3頁,10-4頁,10-10頁ないし10-14頁 ,)G′若しくはコマンドにより各フィーチャーの属性を記CLEANBUILD憶するためのフィーチャー属性テーブルを作成し 地図データの 解,「析「データ管理「表示と変換」及び印刷等を行う(乙13・ 」,」,乙31の1-4頁)H′地図データ作成方法(乙13・乙31の1-1頁 。)4本件発明1とマニュアルに開示されている発明との対比ARC/INFOV5( ) 両者を対比すると,次のとおりである。 1ア構成要件1A構成要件1Aは 「原図を読み取って得られるラスターデータからベク ,トルデータを作成」するものであり,ラスターデータからベクトルデータを作成するに当たっては,自動的に作成されるものに限られないことは,既に述べたとおりである。これに対し,構成A′は,地図をスキャニングして得られるラスターデータをベクトルデータに変換するものである。したがって,構成A′は構成要件1Aと一致する。
原告らは,マニュアルV5に記載されている,スキャニングARC/INFOによって得られるベクトルデータは,自動的にデータ変換することにより面データの作成を行うことを予定しているものではない,すなわち,では,折れ線の頂点のXY座標のデータのほか,折れ線の頂点ARC/INFOの種類を示す キーの値 が手作業により入力される必要があるからキ 「」 ,「ーの値」が入力される前の「ベクトルデータ」は,自動的にデータ変換す「」 ることにより面データの作成が行われる構成要件1Aの ベクトルデータARC/INFOARC/INFO ではないと主張する。しかし,マニュアルV5に 「,はそのような座標を,デジタイザーで入力された座標と同じように取り扱います(乙13・甲11の4-6頁)と記載されていることからすれ 。」ば,そもそも手作業で「キーの値」を入力する必要があるか否かは疑わしく,また,仮に,その必要があったとしても,既に述べたとおり,本件発明1においても,ラスターデータからベクトルデータを作成する過程は自動作成に限られず,オンスクリーン入力などの手作業が介在する場合をも含むのであるから,構成A′は構成要件1Aと一致することに変わりはないのである。
イ構成要件1B構成要件1Bは,既に述べたとおり 「ベクトルデータ」を閉領域デー ,タを構成し得る線データである「二次元の線データ」に変換するものである。これに対し,構成B′は,ベクトルデータを,のカバレッARC/INFOジに変換することであり,マニュアルV5には,の ARC/INFOARC/INFOカバレッジがアーク・ノード構造化が可能なファイルフォーマットであることが開示されていることは前記のとおりである。したがって,構成B′は構成要件1Bと一致する。
原告らは,マニュアルV5においては,コマンドARC/INFO DXFARC等のコマンドの説明があるだけで,これからは,例えばファイルか DXFらカバレッジへのデータ変換プログラムを構築することは不 ARC/INFO可能であり,同マニュアルには,構成要件1Bを実施し得る程度の開示があるということはできず,当該マニュアルに構成要件1Bが記載されているとはいえないと主張する。
しかし,構成要件1Bは「該ベクトルデータを線端を示す点データを含む二次元の線データに変換」するというものであって,具体的なアルゴリズムが発明内容を特定するものではないのであるから,マニュARC/INFOアルV5には,構成要件1Bと共通する構成が記載されているものと認められる(仮に,具体的なアルゴリズムを構成することの困難さに本件発明の特許性が認められるのであれば,本件明細書は,かかる具体的なアルゴリズムを当業者が実施し得る程度に開示するものではないので,記載不備又は実施可能要件違反の無効理由を有するものというべきである。。)ウ構成要件1C構成要件1Cの「二次元データを座標上の線分に変換」とは 「二次元,の線データを途中に接点や交点を持たない線分に細分する工程である」とCLEAN 解すべきことは 前記のとおりであるこれに対し 構成C′も ,。,,コマンドによってアークの交点にノードを生成するものである。したがって,構成C′は構成要件1Cと一致する。
原告らは,マニュアルV5には,コマンドにより,ARC/INFOCLEANアークの交点にノードを付してアークノードトポロジーを構築することは記載されているものの,コマンドによってアークの接点及び線端CLEAN点にノードを付することについては何ら記載されておらず,構成要件1Cの「座標上の線分に変換」する処理のうち,アークの接点及び線端点にノードを付する構成は開示されていないと主張する。しかし,マARC/INFOニュアルV5の記載によれば,コマンドはノードに番号をつけ, CLEANアークの開始ノードと終了ノードを設定するのであるから,接点や端点についても,交点と同様の処理がされているものと認められる。原告らの主張は採用し得ない。
エ構成要件1D構成要件1Dは,座標上の線分に変換された二次元データを,一定の方向に接続していって 「終点が始点と一致したときは,それらの線分から ,なる面データの閉領域データを自動的に作成し,終点が始点と一致しないときにはそれらの面データを自動的に作成」するというものである。これに対し,構成D′は,アークを右回り方向に接続し,アークが閉じている場合にポリゴンを作成するものである。したがって,構成D′は,構成要件1Dの前半部分「該線分を所定方向に接続し,終点が始点と一致したときはそれらの線分からなる面データの閉領域データを自動的に作成し 」,と一致する。
原告らは,マニュアルV5の記載は,アークを「所定方向にARC/INFO接続」するというアルゴリズムを開示するものではないし,示唆するものでもないと主張する。しかし,構成要件1Dの前半部分は「該線分を所定方向に接続し,終点が始点と一致したときはそれらの線分からなる面データの閉領域データを自動的に作成」するという手法を示すものであって,具体的なアルゴリズムによって発明内容を特定するものではないし 「所,」, , 定方向に接続 についても 右回り順に格納する方法が開示されていれば左回り順に格納する方法は容易に想到し得る単なる設計事項であるものと認められる(甲42ないし44参照 。したがって,上記マニュアルに開 )示された構成は 構成要件1Dの前半部分と一致するものと認められる な , (お,仮に,具体的なアルゴリズムを構成することの困難さに本件発明の特許性が認められるのであれば,本件明細書は,かかる具体的なアルゴリズムを当業者が実施し得る程度に開示するものではないので,記載不備又は実施可能要件違反の無効理由を有するものというべきである。。)オ構成要件1E構成要件1Eは 「該面データの前記不連続となる始点及び終点を報知 ,表示」するものである。これに対し,構成E′は,コマンNODEERRORSドやによって 「閉じていないポリゴン」と「接続していないARCEDIT ,ライン をダングリングノードとしてエラー表示するものである この 閉 」 。「じていないポリゴン」と「接続していないライン」とは,構成D′で「ポリゴン」が構成されなかった場合,すなわち,一本以上の線分の組合せが。, 閉領域データを構成しなかった場合を指すものと認められる したがって構成E′は,構成要件1Eと一致する。
原告らは,構成要件1Eは,閉じていない面データの不連続点の報知表示という意味があるのであり,マニュアルV5の記載では,面ARC/INFOデータの不連続点を報知表示する構成要件1Eの開示としては不十分であると主張する。しかし,マニュアルV5には,コマンARC/INFOBUILDド又はコマンドを使用して,フィーチャートポロジーと最小限度CLEANのフィーチャー属性テーブルを作成すること(ステップ4 ,フィーチャ)ートポロジーを生成した後,コマンド等によってトポロジNODEERRORS() ーエラーをダングリングノードとして表示して発見すること ステップ5が記載されている。構成要件1Eは 「該面データの前記不連続となる始 ,点及び終点を報知表示」するというもので,具体的なアルゴリズムが発明内容を特定するものではないのであるから,マニュアルV5にARC/INFOおけるステップ4及びステップ5に関する一連の記載には,構成要件1Eと共通する構成が記載されているものと認められ,原告らの主張は理由がない。
カ構成要件1FARCEDIT 構成F′は,ダングリングノード等のエラーを発見したら,によるデジタイザー入力によりエラー訂正し,アークを編集した後に再度若しくはコマンドを実行して,トポロジーを更新するものCLEANBUILDである。したがって,構成F′は構成要件1Fと一致することは明らかである。
キ構成要件1G構成G′は,若しくはコマンドにより各フィーチャーのCLEANBUILD属性を記憶するためのフィーチャー属性テーブルを作成し,その上で,が地図データの解析,データ管理,表示と変換及び印刷等を行ARC/INFOうものであり,構成要件1Gの「閉領域データに属性データを付与可能にして該閉領域データを記憶,表示又は印刷する」と一致する。
原告らは,構成要件1Gの「属性データを付与可能」にすることとは,「面データの識別番号 (ではポリゴンユーザーID)を付与 」ARC/INFOすることを意味するのであって,フィーチャー属性テーブルの作成とは全く異なると主張する。しかし,構成要件1Gの「属性データを付与可能」の意味が「面データの識別番号」を付与することであるとしても 「フィ,ーチャー属性テーブルの作成」のためにも 「面データの識別番号」に相 ,当するものは必要である。そして,マニュアルV5のARC/INFOコマンドの項には,前記のとおり,カバレッジ・ポリゴ CREATELABELSンのラベル点に新しいユーザーズIDｓを自動的に割り当てることが記載されていることからすれば 「面データの識別番号」は,マニ ,ARC/INFOュアルV5においても開示されているということができる。
,,,,,,,,, ( ) 以上によれば 構成A′ B′ C′ D′ E′ F′ G′ H′は2本件発明の構成要件1A,1B,1C,1Dの前半,1E,1F,1G,1Hにそれぞれ一致する。
これに対し,構成要件1Dの後半部分である「終点が始点と一致しないときはそれらの線分からなる面データを自動的に作成して」はマARC/INFOニュアルV5には開示されていない(以下「相違点」という。。)5( ) 相違点の容易想到性について1構成要件1Dの「面データ」は,既に述べたとおり,単に線分を所定方向に接続することによって構成される一本以上の線分の組合せを意味するにすぎない。
の構成D′は「アークを右回り方向に接続し,アークが閉じてARC/INFOいる場合にはポリゴンを作成し」というものである。面データの閉領域データを作成するに際し,所定方向に線分を接続していく構成を採用した場合,所定方向への線分の接続を複数回行って終点が始点と一致するか否かを検証することとなる。この場合,終点と始点が一致した場合には,当該線分の組合せがそのまま面データの閉領域データとして保存されるところ,このような作業の目標が達成されるか否かは工程の途中では不明であるから,終点と始点が一致しない場合にも,始点と終点が一致しないということが判明するARC/INFO までは,当該線分の組合せを一時的に保存しているはずである。
では,始点と終点が一致しない場合には,ポリゴンを作成しないのであるから,その場合,一時的に保存していた線分の組合せを削除するか,削除せずに何らかの形で保存するかのいずれかである。そして,証拠(甲11の7-11頁)によれば,マニュアルV5には 「テンポラリーディスARC/INFO ,クスペースPOLYオプションで,を使う時や,オーバーCLEANBUILDレイのコマンドを使う時には,しばしば,多量の一時作業領域が必要となります ・・・。一時作業ファイルは,アークの交差点の計算や,フィーチャ 。
ートポロジーの構築などに役立つ位置に関する情報を保有します。一時作業ファイルは,そのコマンドの実行の終了時に削除されます 」との記載があ。
ることが認められる。この記載からすれば,においては,一時保ARC/INFO。,, 存データを削除しているものと推認される しかしにおいても ARC/INFO構成E′において 「閉じていないポリゴン」と「接続していないライン」 ,をダングリングノードとしてエラー表示し,構成F′において,ダングリングノード等のエラーを発見したら,によるデジタイザー入力によARCEDITりエラーを訂正し,再度,若しくはコマンドを実行し,トポ CLEANBUILDロジーを更新することからすれば,始点と終点が一致しない場合には,一時的に保存していた線分の組合せを何らかのファイルとして保存し,上記のコマンド実行の際に利用するか,一時的に保存していたものを削除し,上記コマンド実行の際に改めて所定方向に線分を接続していくかは,そのいずれでも当業者が適宜選択し得る単なる設計事項にすぎないというべきである。
よって,上記相違点にかかる構成は,単なる設計的事項であり,当業者が容易に相当し得る構成にすぎない。
( ) 結論2したがって,本件発明は,マニュアルV5に開示された ARC/INFOの構成から容易に想到することができたものであるから,進歩性 ARC/INFO欠如の無効理由を有する。
6本件発明2の進歩性の有無について請求項2を請求項1と比較すれば明らかなように,本件発明2は,方法の発明である本件発明1を物の発明として構成したものである。したがって,前記5で述べたのと同様に,本件発明2は,マニュアルV5に開示されARC/INFOた発明に基づき,当業者が容易に想到し得るものであり,進歩性欠如の無効理由を有することは明らかである。
7結論よって,本件発明は進歩性欠如のため無効審判により無効にされるものと認められるのであって,本件発明に係る特許権を行使することはできないのであるから,その余の点について判断するまでもなく,第1事件に係る被告の請求は理由があるからこれを認容し,第2事件に係る参加人の請求及び第3事件に係る第3事件原告らの請求はいずれも理由がないのでこれを棄却することとし,主文のとおり判決する。
追加
設樂隆一裁判長裁判官古河謙一裁判官吉川泉裁判官別紙イ号方法目録@AUTODESKCADAutoDeskMapEnvironmentalSystems社製ソフトウェア及び「」社製の地図を編集・加工・解析するソフトウェア「」又ResearchInstituteARC/INFOは「」を組み込んだ装置を使用する地図データ作成方法ArcGIS別紙ロ号物件目録@AUTODESKCADAutoDeskMapEnvironmentalSystems社製ソフトウェア及び「」社製の地図を編集・加工・解析するソフトウェア「」又ResearchInstituteARC/INFOは「」を組み込んだ地図データ作成装置ArcGIS別紙イ号方法構成目録@1a社製ソフトウェア「」を用いて,ディスプレAUTODESKCADAutoDeskMapイ画面上に地形図等の原図を読み取って得られるラスターデータを表示させ,該画面上のカーソルをマウスで動かして,該ラスターデータ上の各マップフィーチャーを正確にトレースすることによってベクトルデータを入力し,形式で該ベクトルデータを保存し,DXF,,1bのコマンドを用いて形式で保存した該データをARC/INFODXFARCDXFが読み取り可能なデータ〔カバレッジ〕に変換し,ARC/INFO1c該変換したデータにおいて,線データ〔アーク〕が他の線データ〔アーク〕と交差しているにもかかわらず,当該交点のx,y座標が未入力の場合には,のコマンドを用いて,当該交点に点データ〔ノード〕をARC/INFOCLEAN,,〔〕,生成しアークを分割して交点のない複数の線データアークに変換し1dのコマンド又はコマンドを用いて,ARC/INFOCLEANBUILD()エリアフィーチャーを表現するための(複数の)アークの終点と始点が一1致している場合には,トポロジーを形成し,その境界を囲むアークのシリーズとラベルポイントでポリゴンを定義してその位置データを記憶すると同時に,ポリゴンの属性情報を記憶するためのテーブル〔PATファイル〕を生成し(すなわち,面データ〔ポリゴン〕を作成し,)(2)エリアフィーチャーを表現するための(複数の)アークの終点と始点が一致していない場合には,トポロジーの形成及びポリゴンの位置データは記憶,,〔〕せずまたポリゴンの属性情報を記憶するためのテーブルPATファイルも生成しないで(すなわち,面データ〔ポリゴン〕を作成しないで,)1eのコマンド又はのARC/INFONODEERRORSARCEDITコマンドを用いて,上記1dの場合の不連続の終点DRAWENVIRONMENTと始点(ダングリングノード)を報知表示させ,1fの用意した修正用のコマンドを用いて,該不連続点から任意のノARCEDITード又はアークへ接続するアークを入力に基づき生成し,エリアフィーチャARC/INFOーを表現するための複数のアークの終点と始点を一致させて(),のコマンド又はコマンドを用いて,トポロジーを形成し,CLEANBUILDその境界を囲むアークのシリーズとラベルポイントでポリゴンを定義してその位置データを記憶すると同時に,ポリゴンの属性情報を記憶するためのテーブル〔PATファイル〕を生成し(すなわち,面データ〔ポリゴン〕を作成し,)ARC/INFOCREATELABELS1gラベルポイントが未入力であった場合には,のコマンドを用いて,ポリゴンにラベルポイントを発生させる,1h地図データ作成方法。
別紙ロ号物件構成目録@2aディスプレイ画面上に地形図等の原図を読み取って得られるラスターデータを表示させ,該画面上のカーソルをマウスで動かして,該ラスターデータ上の各マップフィーチャーを正確にトレースすることによってベクトルデータDXFAUTODESKCADを入力し,形式で該ベクトルデータを保存する社製ソフトウェア「」と,AutoDeskMap2b形式で保存した該データを,が読み取り可能なデータ〔カDXFARC/INFOバレッジ〕に変換するのコマンドと,ARC/INFODXFARC2c該変換したデータにおいて,線データ〔アーク〕が他の線データ〔アーク〕と交差しているにもかかわらず,当該交点のx,y座標が未入力の場合には,当該交点に点データ〔ノード〕を生成し,アークを分割して,交点のない複数の線データ〔アーク〕に変換するのコマンドと,ARC/INFOCLEAN2d()エリアフィーチャーを表現するための(複数の)アークの終点と始点が一1致している場合には,トポロジーを形成し,その境界を囲むアークのシリーズとラベルポイントでポリゴンを定義してその位置データを記憶すると同時に,ポリゴンの属性情報を記憶するためのテーブル〔PATファイル〕を生成し(すなわち,面データ〔ポリゴン〕を作成し,)(2)エリアフィーチャーを表現するための(複数の)アークの終点と始点が一致していない場合には,トポロジーの形成及びポリゴンの位置データは記憶,,〔〕せずまたポリゴンの属性情報を記憶するためのテーブルPATファイルも生成しない(すなわち,面データ〔ポリゴン〕を作成しない,)2e上記2()の場合の場合の不連続の終点と始点(ダングリングノード)をd2報知表示させる,のコマンド又はのARC/INFONODEERRORSARCEDITコマンドと,DRAWENVIRONMENT2f該不連続点から任意のノード又はアークへ接続するアークを入力に基づき生成し,エリアフィーチャーを表現するための(複数の)アークの終点と始点を一致させるの用意した修正用のコマンドと,トポロジーを形成ARCEDITし,その境界を囲むアークのシリーズとラベルポイントでポリゴンを定義してその位置データを記憶すると同時に,ポリゴンの属性情報を記憶するためのテーブル〔PATファイル〕を生成する(すなわち,面データ〔ポリゴン〕を作成する,のコマンド又はコマンドと,)ARC/INFOCLEANBUILD2gラベルポイントが未入力であった場合には,ポリゴンにラベルポイントを発生させるのコマンドと,ARC/INFOCREATELABELS2hを有することを特徴とする地図データ作成装置。
別紙イ号方法目録A1a社製のソフトウェア「」を用いて,ディスプAUTODESKCADAutoDeskMapレイ画面上にラスターデータを表示させ,該画面上のカーソルをマウスで動かして,該ラスターデータ上の各マップフィーチャーを正確にトレースすることによってベクトルデータを入力し,形式で該ベクトルデータを保DXF存し,1bを用いて,形式で保存したベクトルデータを,がARC/INFODXFARC/INFO読み取り可能なカバレッジデータに変換し,1c線データ(アーク)が他の線データ(アーク)と交差しているにもかかわらず,当該交点で分割されていない場合には,CLEANコマンドを用いて,当該交点で分割した上で,当該交点にノードを生成し,すべてのアークを始点・終点でノードを持つものに変換し,1d()同じくコマンドの処理によってアークを所定方向に接続する方法1CLEANによってポリゴンを作成し,接続を開始したアークの始点と最後のアークの終点が一致する場合には,それらの線分からなるポリゴントポロジーを自動,,的に作成しポリゴンの属性情報を記憶するためのファイルを形成しPAT()上記方法によってポリゴン作成を開始した最後のアークの終点と最初のア2ークの始点が一致しない場合には,その一本以上のアークのシリーズを自動的に作成するが,ポリゴンの属性情報を記憶するためのファイルを形PAT成せず,1e前記1d()の場合,アークの終点と始点が一致しないが,の2ARC/INFO,NODEERRORSARCEDITDRAWENVIRONMENT又はのコマンドを用いてオペレーターの意思でその不連続点を報知表示し,1f当該不連続点から任意のノード又はアークへ接続するアークを入力に基づき生成して当該不連続点を解消し,再びコマンドによって当該アークCLEANの修正に対応してポリゴントポロジーを作成し,各ポリゴンにポリゴンインターナルナンバーを付与し,1gのコマンドを用いて,ラベルポイントを自動的ARC/INFOCREATELABELSに一括発生させて,上記ポリゴンである各閉領域データに属性データを付与可能にして,1h該ポリゴンである閉領域データを記憶,表示又は印刷する地図データ作成方法。
別紙ロ号物件目録AAUTODESKAutoDeskMapEnvironmentalSystem社製のソフトウェアであると「」,社製のソフトウェアである「」又は「」を利用しResearchInstituteARC/INFOArcGISた,別紙イ号方法目録A記載の方法を組み込んだ地図データ作成装置別紙イ号方法目録B1a社製ソフトウェア「」を用いて,ディスプレAUTODESKCADAutoDeskMapイ画面上に地形図等の原図を読み取って得られるラスターデータを表示させ,該画面上のカーソルをマウスで動かして,該ラスターデータ上の各マップフィーチャーを正確にトレースすることによってベクトルデータを入力し,形式で該ベクトルデータを保存し,DXFARC/INFODXFARCARC/INFO1bのコマンドを用いて,該ベクトルデータを,が読み取り可能なデータに変換し,1cのコマンドを用いて,そのデータを他の線データとの接ARC/INFOCLEAN点交点で分割して,途中に接点や交点を持たないものにして,それぞれの線分を始点終点(ノード)で定義し,線データに線分番号を付与し,1dのコマンドを用いて,該線分を所定方向に接続し,接続ARC/INFOCLEANを開始した線分の始端と最後の線分の終端が一致する一本以上の線分の組合せ若しくは始端と終端が一致しない一本以上の線分の組合せが自動的になされ,1eの又はのコマARC/INFONODEERRORSARCEDITDRAWENVIRONMENTンドを用いて,該面データ(1dの一本以上の線分の組合せ)の前記不連続となる始端及び終端(ダングリングノード)を報知表示し,1fの用意した修正用のコマンドを用いて,該不連続点から任意の点ARCEDITARC/INFOCLEAN又は線へ接続する線データを入力に基づいて生成し,の,,コマンドを用いて始端と終端が一致する一本以上の線分の組合せを作成し1gのコマンドを用いて,上記の始端と終端が一致ARC/INFOCREATELABELする一本以上の線分の組合せに番号等の識別標識を自動的に一括的に付与し,これらを記憶する1h地図データ作成方法。
別紙ロ号物件目録BAUTODESKAutoDeskMapEnvironmentalSystem社製のソフトウェア()と,社製のソフトウェア(又は)を利用した地図ResearchInstituteARC/INFOArcGISデータ作成装置別紙ロ号物件構成目録B2a地形図等の原図を読みとって得られるラスターデータから,画面上に表示された各マップフィーチャーを正確にトレースすることによってベクトルデータを作成する社製ソフトウェア「」と,AUTODESKCADAutoDeskMapARC/INFO2b該ベクトルデータ作成手段により出力されるベクトルデータをが読み取り可能なデータに変換するのコマンドと,ARC/INFODXFARC2cのコマンドにより出力されるが読み取り可ARC/INFODXFARCARC/INFO能なデータを他の線データとの接点交点で分割して,途中に接点や交点を持たないものにして,それぞれの線分を始点終点(ノード)で定義し,線データに線分番号を付与するのコマンドと,ARC/INFOCLEAN2dこれにより出力される線分を所定方向に接続し,接続を開始した線分の始端と最後の線分の終端が一致する一本以上の線分の組合せ若しくは当該始端と終端が一致しない一本以上の線分の組合せを自動的に行うのARC/INFOコマンドと,CLEAN2eのコマンドが作成した該面データ(2dの一本以上の線ARC/INFOCLEAN分の組合せ)の不連続となる前記始端及び終端(ダングリングノード)を報知表示するの又はのARC/INFONODEERRORSARCEDITコマンドと,DRAWENVIRONMENT2fの又はのコマARC/INFONODEERRORSARCEDITDRAWENVIRONMENTンドによる報知表示に基づいて前記始端及び終端から任意の点又は線へ接続する線データを生成すべく該接続線データを入力するの用意したARCEDIT修正用のコマンドと,2gの用意した修正用のコマンドによる入力に基づいて始端と終端がARCEDIT一致する一本以上の線分の組合せを作成するのコマンドARC/INFOCLEANと,上記の始端と終端が一致する一本以上の線分の組合せに番号等の識別標識を自動的に一括的に付与し,これらを記憶するのARC/INFOコマンドと,CREATELABEL2hを有することを特徴とする地図データ作成装置。
(特許公報第2770097号省略)(審決省略)
すごい知財EXPO'22