平成19(ワ)2352特許権侵害差止等請求事件

平成２０年１０月１７日判決言渡 同日原本領収 裁判所書記官

平成１９年(ﾜ)第２３５２号 特許権侵害差止等請求事件

口頭弁論終結日 平成２０年７月２２日

判 決

東京都渋谷区＜以下略＞

原告 インターネットナンバー株式会社

同訴訟代理人弁護士 熊倉禎男

同 飯田圭

同 奥村直樹

同補佐人弁理士 中村佳正

東京都千代田区＜以下略＞

被告 株式会社ＮＥＴＰＩＡ

同訴訟代理人弁護士 北村行夫

同 亀井弘泰

同 大井法子

同 杉浦尚子

同 雪丸真吾

同 芹澤繁

同 大藏隆子

同 村上弓恵

同 吉田朋

同 大島忠尚

同 杉田禎浩

同 近藤美智子

同補佐人弁理士 樋口盛之助

同 原慎一郎

主 文

１ 原告の請求を棄却する。

２ 訴訟費用は原告の負担とする。

事実及び理由

第１ 請求

１ 被告は， JAddress サービス」を提供してはならない。「２ 被告は， Japan NLIA System」における「 NLIA サーバー」及び「登録情報デー「タベース」を除却せよ。３ 被告は，原告に対し，９１７０万円及びこれに対する平成１９年２月１５日から支払済みまで年５分の割合による金員を支払え。

第２ 事案の概要

本件は ，「インターネットサーバーのアクセス管理およびモニタシステム」についての特許を有する原告が，被告が実施する「 JAddress サービス」という日本語インターネットアドレスに関するサービスは同特許権を侵害すると主張して，特許法条１項に基づく被告のサービスの差止め及び同条２項に基づく被告のサービスに供された「NLIA サーバー」等の除却，並びに民法７０９条，特許法１０２条項に基づく損害賠償及び遅延損害金の支払を求めた事件である。１ 前提事実(1 ) 当事者ア 原告は，インターネットを利用するシステムの開発・販売及びインターネットを利用した情報提供サービス業などを業とする株式会社である。原告は，後記( 2)アの本件発明を実施して，インターネット等の利用者がパソコンのウェブブラウザのアドレスバー等に電話番号等の「インターネットナンバー」を入力することで特定のウェブサイトにアクセスできるようにするサービスを提供している。イ(ｱ) 被告は，コンピュータシステムにおけるデータベースの構築・販売，情報処理サービス業及び情報提供サービス業，インターネットでの広告業務及び広告代理業，インターネットを利用する情報システム及び通信ネットワークの企画・設計・運用に関する受託等を業とする株式会社である。(ｲ) 被告は，韓国法人である株式会社ネッピアダッコム(以下 ネッピア」「 という。)の関連日本法人である。(以上，甲１１，争いのない事実)(2 ) 本件特許権ア 原告は，次の特許権を有している。以下「本件特許権」といい，請求項１の特許発明を「本件発明 」，本件発明に係る特許を「本件特許 」，本件特許権に係る出願を「本件出願」とそれぞれいう。また，本件特許権に係る明細書及び図面を「本件明細書」といい，その特許公報(甲２)を別紙１として添付する。特許番号 第３７６２８８２号発明の名称 インターネットサーバーのアクセス管理およびモニタシステム出願日 平成８年６月３日(特願平９−５０３０８４(乙２)。優先権主張平成７年６月７日アメリカ合衆国)分割出願日 平成１３年７月９日(特願２００１−２０８２９６)登録日 平成１８年１月２０日特許請求の範囲(請求項１) 本件明細書(別紙１)の該当欄に記載のとおり。(争いのない事実)イ 構成要件の分説本件発明を分説すると，次のとおりである(以下，各構成要件を「構成要件Ａ」のようにいう。)。Ａ インターネットよりなるコンピュータネットワークを介したクライアントからサーバーシステムへの情報ページに対するアクセスを提供する方法であって，Ｂ 前記クライアントにおいて記述子を提供する段階と，Ｃ ディレクトリサーバーが，前記記述子を前記ディレクトリサーバーに存在する翻訳データベースを用いてＵＲＬにマッピングする段階と，Ｄ 前記ディレクトリサーバーが，ＲＥＤＩＲＥＣＴコマンド中の前記ＵＲＬを前記クライアントに返送する段階と，Ｅ 前記クライアントに前記ＵＲＬを用いて情報を要求させる段階と，Ｆ 前記ＵＲＬにより識別されたページを前記クライアント側で表示する段階とＧ を備えた情報ページに対するアクセス方法。(争いのない事実)ウ 出願経過(ｱ) 第１回拒絶理由通知特許庁審査官は，平成１７年４月１５日付けで，①本件特許権の当時の請求項１ないし１０に係る出願について，各動作の主体がどのハードウェア手段であるかが不明である，②請求項３の「ＲＥＤＩＲＥＣＴコマンド中のＵＲＬをクライアントに返送してクライアントにＵＲＬを用いて情報を要求させるサーバーシステムにトランザクションデータベースが常駐する 」なる記載の意味が不明である等の理由で ，拒絶理由を通知した。(ｲ) 第１回補正ａ これを受けて，原告は，①の点について，平成１７年６月２０日，当時の請求項１，３及び１０を削除し，当時の請求項２に当時の請求項３及び１０を併合して補正後の請求項１を次のとおりとした。「 インターネットよりなるコンピュータ］ネットワークを介したクライアント［からサーバーシステムへの情報ページに対するアクセスを提供する方法であって，前記クライアント［において］記述子を提供する段階と ，［ディレクトリサーバーが，］前記記述子を［前記ディレクトリサーバーに存在する］翻訳データベースを用いて［ＵＲＬ］にマッピングする段階と ，［前記ディレクトリサーバーが，ＲＥＤＩＲＥＣＴコマンド中の前記ＵＲＬを前記クライアントに返送して前記クライアントに前記ＵＲＬを用いて情報を要求させる段階］と，前記［ＵＲＬ］により識別されたページを前記クライアント側で表示する段階とを備えた情報ページに対するアクセス方法」(［］部分が補正部分)原告は，同日付けの意見書において，上記補正の理由について，次のとおり主張した。「補正前の請求項１∼１０に係る発明の，各動作の主体がどのハードウェア手段であるのかが不明である，に対しては，前述の補正後の請求項１のように補正して対処し，各動作の主体のハードウェア手段を明確にしております。すなわち，記述子を提供する段階はクライアントが行い，記述子をディレクトリサーバーに存在する翻訳データベースを用いてＵＲＬにマッピングする段階はディレクトリサーバーが行い，ＲＥＤＩＲＥＣＴコマンド中のＵＲＬをクライアントに返送してクライアントにＵＲＬを用いて情報を要求させる段階はディレクトリサーバーが行い，ＵＲＬにより識別されたページを表示する段階はクライアントが行うものであります 。」(２頁下から１９行∼１２行)，「本願発明では，このような長く複雑なＵＲＬに代えて，このＵＲＬに対応して誰でも簡単かつ容易に入力できる電話番号 ，会社名 ，製品名などを入力するだけで ，目標とするＵＲＬのウェブサイトへアクセスできるようにしたものであります 。」(１頁下から３行ないし２頁１行)ｂ 原告は，②の点について，同年６月２０日付け意見書において ，「…補正前の請求項３の内容を明確にして，補正後の請求項１に併合しております。すなわち，ディレクトリサーバーが，ＲＥＤＩＲＥＣＴコマンド中のＵＲＬをクライアントに返送してクライアントにＵＲＬを用いて情報を要求させるものであり ，… 」(２頁下から１１行ないし８行目)との意見を述べ，同日付けの手続補正書において，補正後の請求項１の記載を「前記ディレクトリサーバーが，ＲＥＤＩＲＥＣＴコマンド中の前記ＵＲＬを前記クライアントに返送して前記クライアントに前記ＵＲＬを用いて情報を要求させる段階と ，」とした。(ｳ) 第２回拒絶理由通知特許庁審査官は，平成１７年９月２８日付けで，本件特許権の上記(ｲ)の第１回補正後の請求項１ないし７に係る出願について，進歩性欠如を理由とする拒絶理由を通知した。(ｴ) 第２回補正ａ これを受けて，原告は，平成１７年１２月５日，請求項１中の「前記ディレクトリサーバーが，ＲＥＤＩＲＥＣＴコマンド中の前記ＵＲＬを前記クライアントに返送して前記クライアントに前記ＵＲＬを用いて情報を要求させる段階と ，」を「前記ディレクトリサーバーが，ＲＥＤＩＲＥＣＴコマンド中の前記ＵＲＬを前記クライアントに返送する段階と，前記クライアントに前記ＵＲＬを用いて情報を要求させる段階と ，」に補正した。原告は，同日付け意見書において，補正の理由について ，「…１つの段階から，ＵＲＬの返送段階と，そのＵＲＬを用いた情報要求段階との２つの段階に分けて表現し，記載の明瞭化を図りました 。」(１頁下から１７行∼１６行)と主張した。ｂ また，原告は，同意見書において，本件発明の特徴について ，「本願発明は，インターネット上において，ユーザが電話番号，会社名，製品名等を用いて商業サービスサイトにアクセスできる，インターネットよりなるコンピュータネットワークを介したクライアントからサーバーシステムへの情報ページに対するアクセス方法に関する技術であります 。すなわち ，本願発明が適用するようなインターネットの技術分野では，ウェブサイトへアクセスする際に，長く複雑なＵＲＬを入力する必要があるが，本願発明では，このような長く複雑なＵＲＬに代えて，このＵＲＬに対応して誰でも簡単かつ容易に入力できる電話番号，会社名，製品名等を入力するだけで，目標とするＵＲＬのウェブサイトへアクセスできるようにしたものであります 。」(１頁下から６行∼２頁３行)と説明している。ｃ 特許庁審査官は，平成１８年１月５日，上記補正内容で特許査定した。(以上，争いのない事実)エ 無効審判等(ｱ) 被告は，平成１９年１０月３１日付け審判請求書(乙３１)により，本件特許権(請求項１ないし７)について，無効審判を請求した(無効２００７−８００２)。(ｲ) 原告は，平成２０年１月２３日付け訂正請求書(甲４２)により，本件明細書の特許請求の範囲の請求項１ないし７について，請求項１を次のとおり訂正する等の訂正を請求した(以下「本件訂正」といい，訂正後の本件発明を「本件訂正発明」という。理解の便宜のために，構成要件の分説の形で記載する。)。「Ａ インターネットよりなるコンピュータネットワークを介したクライアントからサーバーシステムへの情報ページに対するアクセスを提供する方法であって，Ｂ 前記クライアントにおいて［単一の目標ＵＲＬに対応する］記述子を提供する段階と，Ｃ ディレクトリサーバーが，前記記述子を前記ディレクトリサーバーに存在する翻訳データベースを用いて［前記］ＵＲＬにマッピングする段階と，Ｄ 前記ディレクトリサーバーが，ＲＥＤＩＲＥＣＴコマンド中の前記ＵＲＬを前記クライアントに返送する段階と，Ｅ 前記クライアントに前記ＵＲＬを用いて情報を［自動的に］要求させる段階と，Ｆ 前記ＵＲＬにより識別されたページを前記クライアント側で表示する段階とＧ を備えた情報ページに対するアクセス方法 。 (［］部分が訂正部分である 。)」(ｳ) 特許庁審判官は，平成２０年６月２６日，本件訂正を認めたが，訂正後の請求項１ないし７の発明は ，進歩性欠如を理由として無効とする旨の審決をした(乙)。(ｴ) 原告は，知的財産高等裁判所に対し，上記無効審決の取消しを求める訴えを提起した。(以上，争いのない事実)(3 ) 被告の行為ア 被告サービスの開始被告は，平成１８年２月ころ，その名称を「 JAddress サービス」とする日本語インターネットアドレスに関するサービス(以下「被告サービス」といい，このサービスで採用されている方法を「被告方法」という。)を開設し，サイト運営者のトライアル登録サービス「Test Operation」を開始し，同年９月５日，その優先登録サービス「SunriseOperation」を開始した。(争いのない事実)イ 被告方法(ｱ) 被告サービスの概略ａ 「 Native Language Internet Address (NLIA)システム」は，インターネットに接続されたパソコンのユーザーに対し，当該パソコン(クライアントＰＣ)のウェブブラウザ(インターネット上のウェブページを閲覧するためのアプリケーションソフト。「ブラウザ」ともいう。)のアドレスバーに任意の文字を記述することで目的のウェブページのＵＲＬ(又はＩＰアドレス)を取得することを可能とするソフトウェアを提供するものである。被告サービスは，この「 Native Language Internet Address (NLIA)システム」を日本において展開するものである。ｂ 被告サービスの提供方法には，以下の２種類がある。

① サーバー方式被告のＤＮＳ(Domain Name System：ＩＰアドレスとドメインネームとを対応させる既存のシステム)サーバー内に付加したプログラムを利用する方式この方式は，ユーザーがクライアントＰＣにプログラムをプラグインする必要がない点において，後記②の方式よりも進化した方式である。

② プラグイン方式

①と同じ作用のプログラムをクライアントＰＣにプラグインする方式(争いのない事実)(ｲ) 被告方法の構成被告方法の構成は，別紙２被告方法説明書記載のとおりであり，サーバー方式の構成Ｃ’−Ⅱ以外の構成は，当事者間に争いがない。ウ 構成要件の一部充足被告方法は，本件発明の構成要件Ａ，Ｄ及びＧを充足する。(弁論の全趣旨)２ 争点(1 ) 争点１ 構成要件Ｂの充足(2 ) 争点２ 構成要件Ｃの充足(3 ) 争点３ 構成要件Ｅの充足(4 ) 争点４ 構成要件Ｆの充足(5 ) 争点５ 本件特許権の無効理由の存否ア 争点５−１ 開示義務違反(特許法３６条４項，６項１号，２号)イ 争点５−２ 新規性の欠如ウ 争点５−３ 進歩性の欠如(6 ) 争点６ 本件訂正による無効理由の解消の存否ア 争点６−１ 訂正要件及び充足イ 争点６−２ 進歩性の欠如等(7 ) 争点７ 主体性(8 ) 争点８ 損害の発生及び額３ 争点に関する当事者の主張( 1) 争点１(構成要件Ｂ「前記クライアントにおいて記述子を提供する段階と」の充足)(原告の主張)ア 特許請求の範囲の解釈(ｱ) 「クライアントにおいて…提供する」ａ 解釈構成要件Ｂの「クライアントにおいて…提供する」とは，ハードウェア手段であるクライアントＰＣ等が記述子を送信することを意味する。記述子がディレクトリサーバーに受信される経路については，何ら限定はなく，アドレスバーに記入された記述子をＤＮＳサーバーを介してディレクトリサーバーに送信する場合を含む。ｂ 「クライアントにおいて」についての根拠

(a) 本件明細書の記載本件明細書の発明の詳細な説明には，次の記載がある。「本発明は，クライアントからサーバーへのネットワークを介したサービス要求を処理する方法に関する 。」(【０００１】)，「インターネットサーバーは，ホスト上のファイルを要求するあらゆるコンピュータに情報を配布することができる。このような要求をするコンピュータは“クライアント”として知られ，これはインターネットに接続されたワークステーション，掲示板システムまたは家庭用パーソナルコンピュータ(ＰＣ))であり得る。」(【０００３】頁２６行∼２９行)

(b) 出願経過前提事実( 2)ウ(ｲ)のとおり，原告は，平成１７年４月１５日付けの第１回拒絶理由通知の「各動作の主体がどのハードウェア手段であるかが不明である」という拒絶理由に対し，同年６月２０日付けの意見書において，「…記述子を提供する段階はクライアントが行い…」との意見を述べた上，同日付けの手続補正書において，請求項１の記載を「クライアントにおいて記述子を提供する」と補正し，特許査定された。

(c) まとめ上記(a)及び( b)によると，構成要件Ｂ中の「クライアントにおいて」は，送信の主体が「クライアントＰＣ等」であることを意味する。

(d) 米国特許出願後記被告の主張ア(ｱ)ｂ( d)一及び二は認め，三は否認する。ｃ 「提供する」についての根拠

(a) 特許請求の範囲の記載構成要件Ｂ及びＣは ，記述子について ，これを提供するのがクライアントであり ，これをＵＲＬにマッピングするのがディレクトリサーバーであることを規定しているが，クライアントへの記述子の入力方法や記述子がディレクトリサーバーに受信される経路については，何ら限定していない。( b) 本件明細書の記載一 本件明細書には，次の記載がある。「ユーザはまた，他のウェブページにジャンプするため，既知のＵＲＬをウェブページ上のコマンドラインに直接書き込むことにより指定することができる 。 ( ０」【】３頁２４行∼２６行)「本発明は，ネットワークを介したクライアントからサーバーへのサービス要求を処理する方法に関する。とりわけ本発明は，ワールドワイドウェブ(ウェブ)のようなＨＴＴＰ(ハイパーテキスト転送プロトコル)環境におけるクライアント要求を処理することに適する 。」(【００１１】４頁１５行∼１８行)「好ましい構成では，クライアント要求は Uniform Resource Locator(ＵＲＬ)によりウェブブラウザから作られる。」(【００１２】４頁２６行∼２７行)二 本件明細書の上記記載からすると，本件発明は， クライアント要求」がウェ「ブブラウザ上で処理されることを当然に想定しており，「アドレスバー」に記述子を入力する方法を排除しているものではない。

(c) 周知技術一 本件出願当時，ウェブブラウザ及びＤＮＳ自体は，周知技術であった。二 したがって，クライアントのウェブブラウザのアドレスバーへ記述子が入力され，そのままだと当該記述子が直接的にはＤＮＳに送信されるような場合も想定されている。三 そのような場合に，クライアントにおいて記述子を認識させて直接ディレクトリサーバーに送信させるようにするか，ＤＮＳに記述子を認識させてディレクトリサーバーに送信させるようにするか，ＤＮＳ兼ディレクトリサーバーに記述子を認識させて処理するようにするかは，当業者において適宜選択する設計事項にすぎない。

(d) 「ＮＯＴ ＦＯＵＮＤ」一 本件明細書の【００４１】には，一実施例として，ＮＵＭＢＥＲが入力された場合の処理について ，「ブラウザは次いでＮＵＭＢＥＲがユーザにより指定された電話番号，またはその他の識別子である，書式“ http://directory.net/NUMBER”のＵＲＬを構成する 。」と記載されている。二 この記載は，ＮＵＭＢＥＲがＨＴＴＰプロトコルによりＵＲＬを構成して通信することを明らかにしており，この場合「ＮＯＴ ＦＯＵＮＤ」が返されることはない。三 本件出願当時， http://という識別子は，ＵＲＬにおいて使用されるプロトコルに関する識別子であり ，ＵＲＬ内において規定されているプロトコルとしては ，ＨＴＴＰ以外に， ftp や gopher 等多数のプロトコルが存在し，ＵＲＬの先頭にコンピュータプログラムにおいて判別可能な文字列として記述し，コンピュータプログラムにおいてはこれらを文字解析した上で適宜必要なプロトコルを選択して通信を行うように制御させる規約となっていたことは周知であった。四 したがって，上記に規定された体系( schemes)以外に，会社名，製品名，電話番等等の記述子が入力された場合にも，何らかの体系を定めてＤＮＳから「ＮＯＴ ＦＯＵＮＤ」が返されないように処理を行うようにすること自体は，当業者であれば技術常識に基づき適宜なし得た事項である。

(e) 「提供する」の通常の意味等一 前提事実(2)ウ(ｲ)のとおり，原告は，平成１７年６月２０日付け意見書において ，「補正前の請求項１∼１０に係る発明の，各動作の主体がどのハードウェア手段であるのかが不明である，に対しては，前述の補正後の請求項１のように補正して対処し，各動作の主体のハードウェア手段を明確にしております。すなわち，記述子を提供する段階はクライアントが行い…」と述べた上，同日付けの手続補正書において，補正後の請求項１を「前記クライアントにおいて記述子を提供する段階と，」とし，特許査定されている。二 「提供」という用語は，プログラム等の送信行為を意味する(特許法２条３項１号「電気通信回線を通じた提供 」，商標法２条２項８号「電磁的方法により提供する」等)。三 本件明細書の【００４５】には，「サーバー６０２はウェブページをクライアントに返送して，要求されたドキュメントに対して適切なリンクを提供する」として，「提供」の用語が送信行為を意味するものとして記載されている。このように，本件明細書では，「提供」と「送信」とを厳密に区別してない。四 したがって，「記述子を提供する」段階が，動作の主体としてのハードウェア手段であるクライアントにおいてされるものである以上 ，「提供」の用語は，クライアントが記述子を送信することを意味する。(ｲ) 「記述子」ａ 解釈構成要件Ｂ中の「記述子」とは，電話番号，会社名，製品名等のＵＲＬとは異なる数字あるいは言葉であり，これに対応し，目標情報ページを識別する特定かつ唯一のＵＲＬへとマッピングされるものを意味する。ｂ 根拠

(a) 特許請求の範囲の記載一 構成要件Ｃでは ，「ディレクトリサーバーが，前記記述子を前記ディレクトリサーバーに存在する翻訳データベースを用いてＵＲＬにマッピングする」と記載されている。二 このように ，「記述子」と「ＵＲＬ」とは，明確に区別されている。( b) 発明の詳細な説明の記載一 本件明細書の【００４７】には，発明の効果として ，「…ユーザはＵＲＬについて知る必要がない 。」と記載されている。二 仮に ，「記述子」が「ＵＲＬ」を含むとすると，上記の本件発明の効果を奏することができない。

(c) 出願経過前提事実( 2)ウ(ｳ)及び(ｴ)のとおり，原告は，平成１７年１２月５日付け意見書で，「本願発明では，このような長く複雑なＵＲＬに代えて，このＵＲＬに対応して誰でも簡単かつ容易に入力できる電話番号 ，会社名 ，製品名等を入力するだけで ，目標とするＵＲＬのウェブサイトへアクセスできるようにしたものであります 。」と主張し，その後 ，「記述子」については特に補正することなく特許査定された。イ 充足(ｱ) サーバー方式の場合ａ 被告方法の構成Ｂ’によれば，被告方法は，「クライアント」に相当する「クライアントＰＣ」から「ディレクトリサーバー」(構成要件Ｃ)の一部に相当する「ＤＮＳサーバー」に対し，「記述子」に相当する「日本語インターネットアドレス(2)(正規 URL)又は(2’)(非正規 URL)」を「提供する」ことに相当する「送信する」ことをしているので，構成要件Ｂを充足する。ｂ また，仮に，クライアントからディレクトリサーバーへの送信方法が，直接送信する場合に限定されるとしても，被告方法は，「クライアント」に相当する「クライアントＰＣ」 「ディレクトリサーバー」から (構成要件Ｃ)に相当する NLIA サーバー」「に対し，当初の日本語インターネットアドレスを直接送信する段階( 5)を備えているから，構成要件Ｂを充足する。(ｲ) プラグイン方式の場合ａ 被告方法の構成Ｂ”−Ⅲは，構成要件Ｂを充足する。ｂ 非正規ＵＲＬの場合，当該記述子を「NLIA サーバー」へのＵＲＬ形式に変更した上，ブラウザの機能によって当該変更したＵＲＬ(2”)をＤＮＳサーバーに送信してＤＮＳサーバーの機能によって「NLIA サーバー」のＩＰアドレスをクライアントに送り返す段階(4’)という構成が行われているが，構成要件Ｂは，送信の前段階としてクライアントがどのような動作を行うかについて何も規定していないから，この点は，構成要件Ｂを充足すると認めることの妨げとならない。(被告の主張)ア 特許請求の範囲の解釈(ｱ) 「クライアントにおいて…提供する」ａ 解釈原告の主張ア(ｱ)ａは争う。上記構成要件は，ユーザーがクライアントＰＣ等において記述子を入力することを意味する。また ， 提供する 」が送信することを意味するとしても ，クライアントＰＣの「 ア「ドレスバー」に記入された記述子をディレクトリサーバーに送信する場合を含まない。ｂ 「クライアントにおいて」についての根拠

(a) 本件明細書の記載同ｂ( a)は認める。

(b) 出願経過同ｂ(b)は認める。

(c) まとめ同ｂ( c)は否認する。( d) 米国特許出願一 本件発明は ，米国出願における当初の請求項５に当たるが，そ こ には「 providing a descriptor at the client」 と記載されている(乙６の１の１頁下から３行目)。二 補正後の請求項でも，同様に「 providing a descriptor comprising a telephonenumber at the client」と記載されている(乙７の１⑦１頁下から２行∼最終行)。三 したがって，構成要件Ｂの「クライアントにおいて」は ，「クライアントＰＣで」と，記述子を提供する場所を表すもの解するほかはない。ｃ 「提供する」についての根拠

(a) 特許請求の範囲の記載同ｃ( a)は否認する。( b) 本件明細書の記載同ｃ( b)のうち，一は認め，二は否認する。

(c) 周知技術同ｃ( c)のうち，一は認め，二，三は否認する。

(d) 「ＮＯＴ ＦＯＵＮＤ」同ｃ( d)のうち，一は認め，その余は否認する。アドレスバーを使用する場合は，記述子が正規のＵＲＬか否かの選別を行う段階が必要であるが，本件発明には，そのような段階を想定した記述はない。原告主張のように「クライアントＰＣが送信する」と解すると，構成要件Ｃの記載及び本件明細書【００４１】の「ディレクトリサーバー６０２に連絡し，メッセージで要求されたＮＵＭＢＥＲを送信する」との記載からすると，クライアントがディレクトリサーバーに向けて直接「送信する」と解するほかはないが，原告は，受信経路は限定されていないと主張しており，矛盾している。したがって，構成要件Ｂの「記述子を提供する」とは，クライアントＰＣの「アドレスバー」に記入された記述子をディレクトリサーバーに送信する場合を含まないと解すべきである。

(e) 「提供する」の通常の意味等同ｃ( e)のうち，一ないし三は認め，四は否認する。(ｲ) 「記述子」ａ 解釈同(ｲ)ａは争う。「記述子」は，任意のものを意味し，ＵＲＬでないものに限定する理由はない。ｂ 根拠

(a) 特許請求の範囲の記載同ｂ( a)のうち，一は認め，二は否認する。( b) 発明の詳細な説明の記載同ｂ( b)のうち，一は認め，二は否認する。ユーザーがＵＲＬを知る必要がないという本件発明の効果から ，構成要件Ｂの 記「述子」をＵＲＬとは異なるものであると限定する解釈は，当然には導かれない。

(c) 出願経過同ｂ( c)は認める。イ 充足原告の主張イは，いずれも否認する。被告方法では ，「アドレスバー」に入力された記述子はＤＮＳサーバーに送られており，直接ディレクトリサーバーに送られていないから，構成要件Ｂを充足しない。(2 ) 争点２(構成要件Ｃの充足)(原告の主張)ア 特許請求の範囲の解釈(ｱ) 「前記記述子」前記( 1)(原告の主張)ア(ｲ)と同じ(ｲ) 「ディレクトリサーバー」ａ 解釈構成要件Ｃの「ディレクトリサーバー」がどのような経路で当該「記述子」を受信するかについては，何ら限定はなく ，「ディレクトリサーバー」がＤＮＳとしての機能を併有してはならないという限定もない。ｂ 根拠前記( 1)(原告の主張)ア(ｱ)ｃと同じ。イ 充足(ｱ) サーバー方式の場合ａ 被告方法は，別紙２被告方法説明書のＣ’−Ⅰ，Ｃ’−Ⅱ(原告の主張)及びＣ’−Ⅲのとおりである。ｂ 同Ｃ’−Ⅱ(被告の主張)の構成(4’)及び(5)は，実際には存在しない。すなわち，被告方法においては， NLIA Name Server」と「NLIA サーバー」は，双「方ともに被告(又は韓国の親会社であるネッピア)によって管理運営されており(甲２，３０)，少なくとも物理的には両者とも１つのコンピュータ中に存在する。クライアントＰＣから「NLIA Name Server」に送信された日本語インターネットアドレスは， NLIA Name Server」の付加プログラム①によって非正規ＵＲＬと選別され「ると，そのまま「NLIA Name Server」から「NLIA サーバー」へと送られる構成を有する(甲３０)。同構成Ｃ’−Ⅱ(被告の主張)の(4’)及び(5)は，他のプロバイダー等によって管理運営されているＤＮＳサーバーにおいて被告との契約に基づき被告プログラム①が付加されているような場合に実行され得るが，被告サービスとの関係では，被告との契約に基づき，自己が管理運営しているＤＮＳサーバーにおいて付加プログラム①を付加している他のプロバイダー等は存在しない。ｃ 同構成Ｃ’−Ⅱ(原告の主張)及びＣ’−Ⅲによれば， NLIA サーバー」が，「クライアントＰＣから送信された日本語インターネットアドレスを「 NLIA NameServer」から送信を受け，当該日本語インターネットアドレスに対応するＵＲＬを登録情報データベースから取得しているから， ディレクトリサーバー」が「記述子」を「翻「訳データベース」を用いてＵＲＬに「マッピング」しており，構成要件Ｃを充足する 。なお，構成要件Ｂ及びＣの「記述子」はＵＲＬを含まないから，被告方法において対比の必要があるのは，日本語インターネットアドレスが入力された場合の構成のみである。ｄ 仮に ，同構成Ｃ ’−Ⅱ(被告の主張)を前提としても ， NLIA サーバー」が，「クライアントＰＣから送信された日本語インターネットアドレスに対応するＵＲＬを登録情報データベースから取得しており，クライアントＰＣから NLIA Name Server」「を介しているにすぎないから，いずれにしても構成要件Ｃを充足する。(ｲ) プラグイン方式の場合同被告方法の構成Ｃ”は，構成要件Ｃを充足する。(被告の主張)ア 特許請求の範囲の解釈(ｱ) 「前記記述子」前記( 1)(被告の主張)ア(ｲ)と同じ。構成要件Ｃの「前記記述子」も，アドレスバーに記載された記述子を含まない。(ｲ) 「ディレクトリサーバー」ａ 解釈同(ｲ)ａは争う。ｂ 根拠前記( 1)(被告の主張)ア(ｱ)ｃと同じイ 充足(ｱ) サーバー方式の場合ａ 同イ(ｱ)ａは否認する。サーバー方式の被告方法は，別紙２被告方法説明書のＣ’−Ⅰ，Ｃ’−Ⅱ(被告の主張)及びＣ’−Ⅲのとおりである。ｂ 同イ(ｱ)ｂは否認する。「NLIA Name Server」と「NLIA サーバー」とは，ＩＰアドレスが異なり，物理的にも別のコンピューターに存在するものであり，実際にその間のインターネットの送信も行われている。ｃ 同イ(ｱ)ｃは否認する。被告方法は ，プラグイン方式を含め ，アドレスバーに記述子を記入しているから ，構成要件Ｃの「前記記述子」を充足しない。仮に，構成要件Ｂの「記述子」に，アドレスバーに記入された記述子が含まれるとしても，被告方法では，アドレスバーに記入された記述子について，これが正規ＵＲＬか否かを選別し，非正規ＵＲＬと選別された記述子に限り ， NLIA サーバー」「に送られる。したがって，被告方法の構成Ｃ’−Ⅲ，Ｃ”でディレクトリサーバーに送られる日本語インターネットアドレスは，被告方法の構成Ｂ’，Ｂ”−Ⅰでクライアントが提供する日本語インターネットアドレスと同義ではないから，被告方法は，構成要件Ｃの「前記記述子」を充足しない。ｄ 同イ(ｱ)ｄは否認する。(ｲ) プラグイン方式の場合同イ(ｲ)は否認する。(3 ) 争点３(構成要件Ｅの充足)(原告の主張)ア 特許請求の範囲の解釈(ｱ) 解釈構成要件Ｅにおける 前記クライアントに前記ＵＲＬを用いて情報を要求させる 」「とは，ディレクトリサーバーがクライアントにおいて送信された記述子に対応するＵＲＬをＲＥＤＩＲＥＣＴコマンドに含めて当該クライアントに返送すること(構成要件Ｄ)により，その後は，当該ＵＲＬを含む当該ＲＥＤＩＲＥＣＴコマンドにより，当該クライアントにおいて自動的に当該ＵＲＬに対応するウェブに情報要求することを意味し，構成要件Ｄ及び構成要件Ｅがディレクトリサーバーの１つの行為でされる場合を含む。(ｲ) 根拠ａ 本件明細書の記載( a) 本件明細書には ，「認証サーバーは，次いでこのＳＩＤが付加されたオリジナルＵＲＬから成る新しい要求を，ＲＥＤＩＲＥＣＴによってクライアントに送出する。新しいＵＲＬにより形成された修正要求は，自動的にクライアントブラウザによりコンテンツサーバーに送出される 。」(【００１２】４頁３７行∼４０行目)との記載がある。( b) 上記記載は ，「ＲＥＤＩＲＥＣＴ」コマンドと共にＵＲＬがクライアントに返送されると，クライアントが自動的に目的ページの接続要求を出すことを意味する。ｂ 実施例及び図面の記載

(a) 実施例３本件明細書には，次の記載がある。「メッセージ２では，ディレクトリサーバー６０２がＲＥＤＩＲＥＣＴをクライアント６０１に送信し，これには，データベース６０４から演算されたＮＵＭＢＥＲに対する目標ＵＲＬが記述されている。クライアントブラウザ６０１は続いて自動的にメッセージ３を送信し，このＵＲＬのコンテンツをＧＥＴする。商業用サーバー６０３はメッセージ４におけるこの情報を返送する。…サーバー６０２が最終的なＵＲＬに対する翻訳を行い，ページよりはむしろＲＥＤＩＲＥＣＴをクライアント６０１に送信するため，メッセージ４のドキュメントは最初のダイヤル入力以上のユーザの行為なしで入手される 。」(【００４５】１０頁４４行∼１１頁２行目)図６には ，「３． “目標−ＵＲＬ”ＧＥＴ 」「４．ページ送信」との記載がある。「 ダイヤル”コマンドおよびその実施の利点の中には，従来の電話番号および“他の識別子と互換性を有する，インターネットにアクセスする改善された方法がある。商業者はコンタクト情報のインターネット特定書式を提供するための印刷物またはテレビ広告を変更する必要がなく ，ユーザはＵＲＬについて知る必要がない 。」(【００４７】１１頁９行∼１２行目)。( b) これらの記載は，クライアントが自動的にＵＲＬを要求することを裏付けている。ｃ 出願経過後記被告の主張ｃ(a)は認め，( b)は否認する。上記補正は，ディレクトリサーバーがＲＥＤＩＲＥＣＴコマンド中のＵＲＬをクライアントパソコンに返送することによりクライアントパソコンの情報要求が自動的に行われるという構成要件の意義に何ら変更を加えるものではない。イ 充足被告方法の構成Ｅ’及び構成Ｅ”は，ＲＥＤＩＲＥＣＴコマンドに含まれたＵＲＬが，クライアントＰＣに返されることにより，クライアントＰＣにおいて自動的にウェブページへ情報要求しているから，構成要件Ｅを充足する。(被告の主張)ア 特許請求の範囲の解釈(ｱ) 解釈原告の主張ア(ｱ)は争う。本件発明は，ディレクトリサーバーがＵＲＬを返送する段階(構成要件Ｄ)とディレクトリサーバーがＵＲＬを用いて情報を要求する段階(構成要件Ｅ)の２つの段階を含んでおり，方法の発明である以上，構成要件Ｄと構成要件Ｅとは，時系列的に異なる段階として行われる必要がある。(ｲ) 根拠ａ 本件明細書の記載同(ｲ)ａのうち，( a)は認め，(b)は否認する。ｂ 実施例及び図面の記載同(ｲ)ｂのうち，( a)は認め，(b)は否認する。ｃ 出願経過( a) 前提事実( 2)ウ(ｴ)のとおり，原告は，平成１７年１２月５日付けの手続補正において，請求項１を「前記ディレクトリサーバーが，ＲＥＤＩＲＥＣＴコマンド中の前記ＵＲＬを前記クライアントに返送する段階と，前記クライアントに前記ＵＲＬを用いて情報を要求させる段階と ，」と補正し，同日付けの意見書において，上記補正について ，「１つの段階から，ＵＲＬの返送段階と，そのＵＲＬを用いた情報要求段階との２つの段階に分けて表現し，記載の明瞭化を図りました 。」と述べた。( b) この事実は，構成要件Ｄと構成要件Ｅとは，時系列的に異なる段階として行われる必要があることを裏付ける。イ 充足同イ(ｱ)は否認する。被告方法では，ディレクトリサーバーである「NLIA サーバー」が，構成要件Ｄとは時系列的に異なる段階として，クライアントにＵＲＬを用いて情報を要求させる段階(構成要件Ｅ)を行っていない。殊に，被告方法では，同構成Ｅ’及び構成Ｅ”のとおり，クライアントのブラウザのアドレスバーを利用した標準的なプロトコルを用い，「NLIA サーバー」からアドレスバーに所期のＵＲＬを返しさえすれば，その後は，クライアントに備わっているブラウザが当該ＵＲＬによって識別されたページを(ＤＮＳサーバーを介して)取得し，クライアントＰＣに表示するものであり，時系列的に異なる段階として，構成要件Ｅに当たる段階を有しないことは明らかである。(4 ) 争点４(構成要件Ｆの充足)(原告の主張)ア 特許請求の範囲の解釈前記争点( 3)(原告の主張)アと同じ。イ 充足被告方法の構成Ｆ’及び構成Ｆ”は ，「ＲＥＤＩＲＥＣＴコマンド」に含まれたＵＲＬがクライアントＰＣに返されることにより，クライアントＰＣにおいて自動的にウェブページへ情報要求し(構成Ｅ’及び構成Ｅ”)，ウェブページへ接続する(構成Ｆ’及び構成Ｆ”)から，構成要件Ｆを充足する。(被告の主張)ア 特許請求の範囲の解釈前記争点( 3)(被告の主張)アと同じ。イ 充足原告の主張イは否認する。被告方法は，上記( 3)(被告の主張)イのとおり，構成要件Ｅの段階を有しないから，構成要件Ｆも充足しない。(5 ) 争点５(本件特許の無効理由の存否)ア 争点５−１(開示義務違反(特許法３６条４項，６項１号，２号))(被告の主張)(ｱ) 記載不明瞭ａ 構成要件Ａ及びＧ構成要件Ａの「アクセスを提供する方法 」，構成要件Ｇの「アクセス方法」は，「アクセス」する主体が異なっており ，「アクセス 」「アクセスを提供する 」「アクセスする」が具体的に何をする行為を意味するのかが不明瞭である。ｂ 構成要件Ｂ

(a) クライアントによる記述子の提供方法を特定していない。( b) 被告方法のように，クライアントがアドレスバーに記述子を入力した場合は，正規のＵＲＬか否かを選別する段階がなければ ，「ディレクトリサーバー」に記述子が送られることはない。しかし，本件発明には，上記の選別する段階について何も記載されていない。ｃ 構成要件Ｃ

(a) 「ディレクトリサーバー」という文言が不明瞭である。( b) クライアントが提供した記述子を「ディレクトリサーバー」が受け取る方法を特定していない。(ｲ) まとめよって ，本件発明は ，平成１４年法律第２４号による改正前の特許法３６条４項 ，項１号，２号に違反し，本件特許は，同法１２３条１項４号の規定により無効とされるべきである。(原告の主張)(ｱ) 記載不明瞭等ａ 構成要件Ａ及びＧ被告の主張(ｱ)ａは否認する。構成要件Ａの「アクセスを提供する方法」とは，本件発明の実施主体が「アクセスを提供する」ものであり，発明の実施行為自体は究極的に発明実施主体である人によって行われることを明らかとしつつ，そのための具体的構成である要件ＢないしＧはさまざまなハードウェアによって実現されていくものであることを表現したものである。構成要件Ｇの「アクセス方法」は，構成要件Ａの「アクセスの提供」を実現するために発明の構成要件として，ハードウェアであるクライアントがアクセスすることを要することを意味する。ｂ 構成要件Ｂ

(a) 同(ｱ)ｂ(a)は否認する。構成要件Ｂは，本件発明が全体として機能するために最低限必要なデータ送信行為を規定しているにすぎず，データ送信方法の具体的態様まで限定的に規定する必要はない。( b) 同(ｱ)ｂ( b)は否認する。クライアントのウェブブラウザのアドレスバーへ記述子が入力され，ＤＮＳサーバーに送信されるような場合に，クライアントにおいて記述子を認識させて直接ディレクトリサーバーに送信させるようにするか，ＤＮＳにおいて記述子を認識させた上でディレクトリサーバーに送信させるようにするか，それともＤＮＳ兼ディレクトリサーバーにおいて記述子を認識させて処理するようにするかは，本件発明を具体的に実施するに当たり ，当業者が適宜選択すれば足りる設計事項にすぎない 。ｃ 構成要件Ｃ

(a) 同(ｱ)ｃ(a)は否認する。本件発明において ，「ディレクトリサーバー」は ，「記述子」を「翻訳データベースを用いてＵＲＬにマッピング」し(構成要件Ｃ) ，「ＲＥＤＩＲＥＣＴコマンド中の前記ＵＲＬを前記クライアントに返送する」(構成要件Ｄ)サーバーであることを要するとともに，これで足りるものであり，ＤＮＳの機能を併用してもよく，不明瞭という問題は存しない。( b) 同(ｱ)ｃ( b)は否認する。構成要件Ｃは，本件発明が全体として機能するための最低限必要なデータ受信を前提としているにすぎず，データ受信の具体的態様まで限定的に規定する必要はない。(ｲ) まとめ同(ｲ)は否認する。イ 争点５−２(新規性の欠如)(被告の主張)(ｱ) 乙２４発明論文集「 Computer Communication Review Volume 17, Number 5 Special Issue」 のうち「 A Yellow-Pages Service for a Local-Area Network」 (Larry L. Peterson 著。昭和６３年，ＡＣＭ(アメリカ計算機学会)出版発行。乙２４の１。以下 ，「乙２４刊行物」といい，これに記載された発明を「乙２４発明」という。)には，次の構成が開示されている。Ａ’インターネットの至る所からクライアントがサービスを提供するローカル・サーバーにアクセスできるようにする方法である。Ｂ’クライアントは，サービス名およびサーバーが持つべき任意の属性を指定して，イエローページ・サービスにサーバーのアドレスを問い合わせる。Ｃ’イエローページ・サーバーは，使用可能なサービスおよびサーバーに関する情報のデータベースを備え，前記サービス名およびサーバーが持つべき任意の属性をサーバーのアドレスにマッピングする。Ｄ’イエローページ・サービスは，クライアントの要求を満たす１あるいは２以上のサーバーのアドレスを返送する。フラグシップ・ホストが，クライアントに対して，サーバー・ホストのアドレスを返送するとともに，そのパケットをそのサーバー・ホストにリダイレクトする必要があると知らせる。Ｇ’クライアントが，ローカル・サーバーにアクセスする方法(ｲ) 「情報ページ」(構成要件Ａ及びＧ)ａ 乙２４発明には，アクセス先がサーバーシステムに備わる「情報ページ」であることが明示されていない。ｂ( a) しかし，乙２４発明において「ローカル・サーバーにアクセス」するとは，単にサーバーコンピュータにアクセスすることではなく，そのサーバーコンピュータが提供する情報サービスにアクセスすることを意味する。( b) また，乙２８(「Ｉｎｔｅｒｎｅｔ Ｕｓｅｒ １９９５年２月号」１９年２月１日 ，ソフトバンク株式会社発行)の１１８∼１１９頁図１∼図４には ，ウェブ・ブラウザが情報ページを表示することが示されている。ｃ したがって，乙２４発明の構成Ａ ’，Ｇ’と本件発明の構成要件Ａ，Ｇとは一致する。(ｳ) 「記述子」(構成要件Ｂ)ａ 「 descriptor」とは ，「(情報処理)：記述子，デスクリプター(情報の類別・索引に用いる語句)」(リーダーズ英和辞典 第２版)を意味する。記述子は，このように，索引のみならず情報の「類別」(類ごとの中身は通常複数)にも使用されるものであるから，記述子という単語の意味を根拠として ，「記述子」＝「特定かつ唯一」の対象を識別するものと決定付けることはできない。したがって，構成要件Ｂの「記述子」は，任意の記述子を意味し，ＵＲＬを除いたり，目標情報ページを識別する特定かつ唯一のＵＲＬへとマッピングされるものに限定されるものとはいえない。原告の主張は ，「翻訳データベース」の構築の問題と ，「記述子」という言葉の定義の問題とを混同するものである。ｂ 乙２４発明の「 サービス名およびサーバーが持つべき任意の属性 」は ， 記「述子」の内容を具体的に説明しているにすぎない。ｃ 仮に ，「目標情報ページを識別する特定かつ唯一のＵＲＬへとマッピングされるもの」という原告の限定解釈によったとしても，乙２４発明の「サービス名およびサーバーが持つべき任意の属性」は ，「特定かつ唯一のＵＲＬ」に結び付くものであることは，後記(ｵ)(「翻訳データベース」)のとおりである。(ｴ) 「ディレクトリサーバー」(構成要件Ｃ)ａ( a) 乙３０(ＣＣＩＴＴブルーブック第Ⅱ巻Ⅱ・６「勧告Ｆ．５００」平成年９月４日，財団法人日本ＩＴＵ協会発行)には，以下の記載がある。「Ｈ． 107 イエローページ “分類された情報”を参照 。」(１９９頁)「Ｈ． 17 分類された情報 ディレクトリにおいては，ディレクトリ情報群は“ホワイトページ ” “イエローページ”として現在知られている 。， 」(１８９頁)「Ｈ． 24 ディレクトリ ディレクトリサービスを提供するための協同動作する開放型システムの集合 。」(１９０頁)( b) これらの記載からすると ，イエローページは ，ディレクトリにおけるディレクトリ情報群として周知のものである。ｂ したがって ，「イエローページ・サーバー」が「ディレクトリサーバー」であることは自明であり，相違点ではない。(ｵ) 「翻訳データベース」(構成要件Ｃ)ａ( a) 乙２５(ＣＣＩＴＴブルーブック第Ⅷ巻Ⅷ−６，８「勧告 X．５００」平成３年１１月１日，財団法人日本ＩＴＵ協会発行)には，以下の記載がある。「ディレクトリによって保持されている情報は，ディレクトリ情報ベース(ＤＩＢ)と総称され ，」(２４４頁４行∼５行)「ＤＩＢは，オブジェクトについての情報で構成されている。ＤＩＢは(ディレクトリ)エントリで，各エントリは一つのオブジェクトに関する情報の集合で構成される 。各エントリは属性で ，各属性は一つのタイプと一つ以上の値で構成される 。あるエントリに存在する属性のタイプは，そのエントリが記述するオブジェクトのクラスに依存する 。」(２４７頁下から４行∼最終行)「ＤＩＢのエントリは，木構造，つまり節点がエントリであるディレクトリ情報木(ＤＩＴ)にまとめられる 。」(２４８頁１行)( b)一 本件明細書において ，「ディレクトリサーバー」や「翻訳データベース」の構成について格別の説明はない。二 したがって，１つの記述子に対し１つのＵＲＬをマッピングするにしても，どのようなデータベースとして構築し ，どのような演算結果を出力させるかは ，適宜選択可能な設計事項であり，原告主張のように，データベースの構造が１対１に対応付けたものに限られると解する理由はない。

(c) したがって，構成要件Ｃにいう「ディレクトリサーバーに存在する 」「翻訳データベース」とは，ディレクトリ情報ベースのことであり，ディレクトリ情報木の構成を有するデータベースを意味する。ｂ( a) 乙２４発明の構成Ｃ ’のイエローページ・サービスのイエローページ・データベースは，ディレクトリ情報ベースと同じ構成を開示している。

(b)一 乙２４刊行物の「 5.2 設計の問題点 」(訳文１１頁)には ，イエローページ・サービスの構成に関し ，「クライアントではなくサーバーにおいて選択アルゴリズムを関与させる 」構成を有する旨が明記されており ， 選択アルゴリズムはデー「タベースと同じホスト上で実行し，相対的に小さい回答―サーバー・アドレス―が返される」と述べられている。二 すなわち，乙２４刊行物には，イエローページ・サーバーに提供された名前に対し返された値は，同サーバー上で稼動する選択アルゴリズムによって演算され抽出選択されたものであること，選択アルゴリズムの設定次第で，１つのＵＲＬのみを抽出選択するようにすることは ，極めて容易であることが開示されている 。三 しかも，後記(ｷ)ｂ( b)のとおり，乙２４刊行物には，本件発明の「ＲＥＤＩＲＥＣＴコマンド」と同じ「リダイレクト」が開示されているから，乙２４発明において「リダイレクト」する場合，選択アルゴリズムを１つのＵＲＬのみを抽出選択するように設定するなどすれば，当然１つのＵＲＬを選択することになる。四 したがって，乙２４発明(被告が引用するのは ，「リダイレクト」を使用する態様のものである。)は，特定かつ唯一のＵＲＬを選択することを開示している。ｃ 仮に，本件発明の「翻訳データベース」が１対１の対応付けしか行わないデータベースであるとしても，それは，上記ディレクトリ情報ベースのディレクトリ情報木の段階を１段階にしているということにすぎない。情報木の段階を複数段階とすることまで想定した技術が，１段階とする技術を含んでいることは明らかである。よって，乙２４発明におけるイエローページ・データベースは，乙２４発明のものよりも進歩性を欠く態様の本件発明の「翻訳データベース」の技術も開示している。ｄ したがって，乙２４発明の構成Ｃ’は，本件発明の構成要件Ｃと一致するか，本件発明の構成要件Ｃのように構成することは，当業者が容易に想到することができたことである。(ｶ) 「ＵＲＬにマッピングする」(構成要件Ｃ)ａ( a) 乙２７(「ＵＮＩＸ ＭＡＧＡＺＩＮＥ １９９４年２月号」)の３３頁左欄「ＴＣＰ／ＩＰの基本機能とＤＮＳ」には ，「現在のインターネットを支える基本技術のなかで，ＴＣＰ／ＩＰのアプリケーションとして一番大きな役割をもつのはＤＮＳでしょう 。」との記載があり，同欄「ＤＮＳ」には ，「ＤＮＳは，階層的ドメイン名とＩＰアドレスのマッピングのほかに電子メールに関する情報を管理しています 。」との記載がある。乙２７の３４頁左欄「 Uniform Resource Locators」には ，「…インターネット上の分散したリソースに対して，統一的な名前の付け方を決めてユーザー・インターフェイスを向上させる試みがあります。それがＵＲＬ(Uniform Resource Locators)です。」との記載がある。( b) これらの記載からすると，インターネット上のリソース(情報ページ)の所在(アドレス)を統一的に特定するものがＵＲＬであることが，本件出願当時，当業者に自明であったことが明らかであり ，「ＵＲＬ」と「アドレス」とはインターネットを前提に論ずる上では，ほぼ同義であった。ｂ( a) したがって，乙２４発明の構成Ｃ’の「サーバーのアドレスにマッピングする」とは，構成要件Ｃの「ＵＲＬにマッピングする」ことを意味する。( b) 原告は，乙２４発明の構成Ｄ’は ，「フラグシップ・ホスト」の「アドレス」を返すものにすぎない旨主張する。しかし，原告の上記指摘部分は，目的の情報ページのアドレスを取得する前段階として ，一旦フラグシップ・ホストに接続される際の説明部分である 。したがって ，この段階で目的の情報ページのアドレスが返されるわけでないのは当然である。そして，その後の「転送」又は「リダイレクト」により，マッピングにより得られた情報が送られているものである。ｃ また，後記(ｷ)の「ＲＥＤＩＲＥＣＴコマンド」の意義からすると，乙２発明の構成Ｄ’の「サーバーのアドレスを返送する」構成は，構成要件Ｄの「ＵＲＬを返送する」構成を開示している。(ｷ) 「ＲＥＤＩＲＥＣＴコマンド中の前記ＵＲＬを前記クライアントに返送する」(構成要件Ｄ)並びに構成要件Ｅ及びＦａ 乙２４発明の構成Ｄ’は，本件発明の「ＲＥＤＩＲＥＣＴコマンド」をクライアントに返送する構成を開示している。ｂ( a) 乙２６(「ＵＮＩＸ ＵＳＥＲ １９９４年１２月号」平成６年１２月日，ソフトバンク株式会社発行)には，以下の記載がある。一 「●マッピング変換指定①∼ Map変換のルールを指定する。すなわち，ＵＲＬ中に /a/b/*というパス( /a/b/で始まる任意のパス)が現れたとすると，それは /X/Y/Z/*に変換される。他に変換ルールがあれば，続いてチェックされる 。」(１３４頁右欄)二 「●他のＵＲＬに変換∼ RedirectRedirect に指定したパターンにマッチした場合は，指定したＵＲＬにリクエストがそのままフォワードされる。サーバーが引っ越したような場合に用いる。ＵＲＬは『 http://ホスト名 /』から書かなければならない 。」(１３５頁左欄)，「例： Redirect /a/b/* URL」(１３５頁右欄)( b) 上記記載からすると ，「ＲＥＤＩＲＥＣＴコマンド」とは，クライアントから要求を受けたサーバーが該クライアントに対して発するもので，ＲＥＤＩＲＥＣＴ中に指定されたあて先へ該要求を再指向させるよう指令するものであること，クライアントは，ＲＥＤＩＲＥＣＴ指令に従って，該サーバーからの返信をＲＥＤＩＲＥＣＴ中のＵＲＬで指定された再指向先へとそのままフォワード(自動的に転送)することは，本件特許の優先日の技術常識である。( c) さらに，乙２４刊行物には ，「リダイレクト」と記載されているだけでなく，それに続けて，その挙動が「接続指向プロトコル(例えばＴＣＰ)のケースでは妥当である」(乙２４の２の１２頁下から７行)との記載がある。そして，インターネット及びそこで用いられるプロトコルであるＴＣＰ／ＩＰやＨＴＴＰは，１９７年代から８０年代に既に確立していた(乙２０の５０頁)。ｃ したがって，乙２４発明の構成Ｄ’は，構成要件Ｄと一致する。ｄ 周知技術である「ＲＥＤＩＲＥＣＴ」の内容に照らせば，同構成Ｄ’は，構成要件Ｅ及びＦの構成を記載しているに等しい事項である。(ｸ) まとめそうすると ，乙２４発明と本件発明は ，すべての点で一致し ，相違点を有しない 。よって ，本件発明には ，新規性欠如の無効理由があり(特許法１２３条１項２号 ，平成１１年法律第４１号による改正前の特許法２９条１項３号)，原告は，その権利を行使することができない。(原告の主張)(ｱ) 乙２４発明被告の主張(ｱ)は明らかに争わない。(ｲ) 「情報ページ」(構成要件Ａ及びＧ)同(ｲ)のうち，ａは認め，ｂ(b)は明らかに争わず，ｂ( a)，ｃは否認する。(ｳ) 「記述子」(構成要件Ｂ)ａ 同(ｳ)ａは争う。本件発明の「記述子」とは，電話番号・会社名・製品名等のＵＲＬとは異なる数字あるいは言葉であり，かつ，当該「記述子」に対応し，目標情報ページを識別する特定かつ唯一のＵＲＬに結び付けられるものを意味する。ｂ 同(ｳ)ｂは否認する。乙２４発明の「サービス名およびサーバーが持つべき任意の属性」とは，クライアントがサーバーに対して求めるサービスの内容(印刷サービス ，プロセッササービス，トークサービス)やその質( speed 属性， res 属性， arch 属性等)といった条件を指定するものであり ，「任意の属性」から特定かつ唯一のサーバーへと対応付けられるものではない。ｃ 同(ｳ)ｃは否認する。(ｴ) 「ディレクトリサーバー」(構成要件Ｃ)同(ｴ)は明らかに争わない。(ｵ) 「翻訳データベース」(構成要件Ｃ)ａ 同(ｵ)ａのうち，( a)は明らかに争わず，( b)及び( c)は争う。ｂ 同(ｵ)ｂのうち，( a)は明らかに争わず，( b)は否認する。本件発明は，人間に理解しやすい「電話番号・会社名・製品名等のＵＲＬとは異なる数字あるいは言葉」をインターネット上の規約である「ＵＲＬ」に１対１又は多対１に対応付けして翻訳するものである。これに対し，乙２４発明は，指定条件を満足するサーバーを検索するものであって，検索の結果，１つのサーバーが選択される場合があるとしても，検索条件による絞り込みの結果にすぎず，本件発明の「 翻訳データベース 」による１対１の対応付けとは技術思想が全く異なる 。したがって，１対１の対応付けとすることは，設計事項ではない。ｃ 同(ｵ)ｃは否認する。ｄ 同(ｵ)ｄは否認する。(ｶ) 「ＵＲＬにマッピングする」(構成要件Ｃ)ａ 同(ｶ)ａは明らかに争わない。ｂ( a) 同(ｶ)ｂ( a)は否認する。( b) 乙２４発明の構成Ｄ’は ，「フラグシップ・ホスト」の「アドレス」を返すものにすぎないから ，同構成Ｃ ’の「 サーバーのアドレスにマッピングする 。」は「ＵＲＬにマッピングする」ことを意味するものとはいえない。同構成Ｃ’及びＤ’における「サーバーのアドレス」は，ローカルネットワーク内において各サーバーがどの位置にあるかを示すものにすぎず，インターネット上の規約である「ＵＲＬ」を開示も示唆もするものではない。したがって，同構成Ｃ’は，構成要件Ｃの「ＵＲＬにマッピングする」構成を開示していない。ｃ 同(ｶ)ｃは否認する。(ｷ) 「ＲＥＤＩＲＥＣＴコマンド中の前記ＵＲＬを前記クライアントに返送する」(構成要件Ｄ)並びに構成要件Ｅ及びＦａ 同(ｷ)ａは否認する。ｂ( a) 同(ｷ)ｂ( a)は認め，(b)及び( c)は否認する。( b) 乙２６は，仮想的なディレクトリ指定をファイルシステムにおけるパスに変換するルールを規定したものであり ，被告の主張(ｷ)ｂ( a)二の「 Redirect」 は ，単に“ /a/b”というパスをＵＲＬへと変換するものにすぎず，その結果「指定したＵＲＬにリクエストがそのままフォワード」されるものである。すなわち，乙２６における「ＲＥＤＩＲＥＣＴ」は ，「ＲＥＤＩＲＥＣＴ」自体がＵＲＬを含むものではなく ，「ＵＲＬ」へとリクエストを送るものであり，クライアントをして自動的に情報要求させるものでもない。したがって，乙２６における「ＲＥＤＩＲＥＣＴ」は，本件発明の「ＲＥＤＩＲＥＣＴコマンド」とは全く異なる。「ＲＥＤＩＲＥＣＴコマンド」の意義は，一義的に明確とはいえない(乙５)。

(c) 乙２４発明には ，「リダイレクト」が，ローカルエリアネットワークではなく ，インターネット環境の場合にどのように適用されるか ，そもそもインターネット環境の場合にも「リダイレクト」を適用して修正ができるかについて，全く開示がない。ｃ 同(ｷ)ｃは否認する。乙２４発明は ，「フラグシップ・ホスト」から「クライアント」に対して「リダイレクトする必要があると知らせる」のみであり ，「リダイレクト」によりクライアントがどのような動作を要求されるか，そもそも「リダイレクト」にＵＲＬが含まれているのかについて，何ら開示していない。ｄ 同(ｷ)ｄは否認する。(ｸ) まとめ同(ｸ)は否認する。本件発明は ，「記述子」と「ＵＲＬ」とを１対１(ないしは多対１)で対応付け，さらに ＲＥＤＩＲＥＣＴコマンド 」「 を利用したことをその本質的特徴としている 。これに対し，乙２４発明は，一定条件を満たす不特定のサーバーを探す単なる条件検索サービスであり，技術思想は全く異なる。また，本件発明が前提とする「ウェブ」が創設されたのは平成３年(本件明細書【０００５】)であるのに対し，乙２４発明を開示した刊行物(乙２４の１)が発行されたのは昭和６３年であるから，両者は，インターネットについて前提とする技術背景を全く異にする。ウ 争点５−３(進歩性の欠如)(被告の主張)(ｱ) 主引用例(乙２４発明)前記イ(被告の主張)(ｱ)と同じ。(ｲ) 一致点及び相違点の認定ａ 相違点１(「ＵＲＬにマッピングする」構成要件Ｃ)乙２４発明の構成Ｃ’は「サーバーのアドレスにマッピングする」のに対し，本件発明の構成要件Ｃは「ＵＲＬにマッピングする」点で異なる。ｂ 相違点２(「ＲＥＤＩＲＥＣＴコマンド中の前記ＵＲＬを前記クライアントに返送する」構成要件Ｄ)同構成Ｄ’は，構成要件Ｄの「ＲＥＤＩＲＥＣＴコマンド中の前記ＵＲＬを…返送する」構成を明示していない。ｃ 相違点３(構成要件Ｅ及びＦ)乙２４発明は，本件発明の構成要件Ｅ及びＦの構成を明示していない。ｄ 一致点乙２４発明と本件発明とは，その余の点において一致する。ｅ 相違点４(「情報ページ」構成要件Ａ及びＧ)前記イ(被告の主張)(ｲ)のとおりであり，相違点ではない。ｆ 相違点５(「記述子」構成要件Ｂ)前記イ(被告の主張)(ｳ)のとおりであり，相違点ではない。ｇ 相違点６(「翻訳データベース」構成要件Ｃ)前記イ(被告の主張)(ｵ)のとおりであり，相違点ではない。(ｳ) 容易想到性ａ 相違点１(「ＵＲＬにマッピングする」)(構成要件Ｃ)前記イ(被告の主張)(ｶ)のとおり。ｂ 相違点２(「ＲＥＤＩＲＥＣＴコマンド中の前記ＵＲＬを前記クライアントに返送する」構成要件Ｄ)及び相違点３(構成要件Ｅ及びＦ)

(a) 副引用例(乙２６発明)前記イ(被告の主張)(ｷ)ｂのとおり。( b) 容易想到性一 技術分野の同一性本件発明と乙２４発明，乙２６発明は，いずれもインターネットを含む電気通信ネットワークに関するものであり，技術分野が共通する。二 課題の自明性本件発明と乙２４発明とは，インターネットを介して情報ページにアクセスする際のネットワークユーザの便宜を図るものであり，解決すべき課題が共通である。本件発明と乙２４発明とは，複雑な文字列によって識別されるインターネット上のリソースに対して簡易な記述子の提供をもって到達できるとの共通した作用・効果を有し，さらに，これを実現させるための翻訳データベース，マッピング，リダイレクトの各機能を用いる点で共通する。三 組合せの容易性本件発明は，乙２４，乙２６に開示された技術事項を適宜選択し，あるいは単に寄せ集めたにすぎず，または，これらの公知技術を組み合わせることについて，動機付けとなり得る記載が多数認められる。技術的な阻害要因は一切なく，公知技術と比較して，予想の範囲を超える有利な効果も認められない。したがって，本件発明は，出願時の技術水準に基づき当業者が容易に想到できたものである。(ｴ) まとめよって，本件特許は，特許法２９条２項の規定に違反し，同法１２３条１項２号の規定により無効とされるべきである。(原告の主張)(ｱ) 主引用例(乙２４発明)被告の主張(ｱ)は明らかに争わない。(ｲ) 一致点及び相違点の認定ａ 相違点１(「ＵＲＬにマッピングする」構成要件Ｃ)被告の主張(ｲ)ａは認める。ｂ 相違点２(「ＲＥＤＩＲＥＣＴコマンド中の前記ＵＲＬを前記クライアントに返送する」構成要件Ｄ)同(ｲ)ｂは認める。ｃ 相違点３(構成要件Ｅ及びＦ)同(ｲ)ｃは認める。ｄ 一致点同(ｲ)ｄ(一致点)は否認する。乙２４発明と本件発明とは，次のｅないしｇの点においても相違する。ｅ 相違点４(「情報ページ」構成要件Ａ及びＧ)乙２４発明には，アクセス先がサーバーシステムに備わる「情報ページ」であることが開示されていない。ｆ 相違点５(「記述子」構成要件Ｂ)前記イ(原告の主張)(ｳ)ｂのとおり。ｇ 相違点６(「翻訳データベース」構成要件Ｃ)前記イ(原告の主張)(ｵ)ｂのとおり。(ｳ) 容易想到性ａ 相違点１前記イ(原告の主張)(ｶ)ｂのとおりｂ 相違点２及び３

(a) 副引用例(乙２６発明)前記イ(原告の主張)(ｷ)ｃのとおり。( b) 容易想到性一 被告の主張(ｳ)ｂ(b)はいずれも否認する。二 本件発明は ，「記述子」と「ＵＲＬ」とを１対１(又は多対１)で対応付け，さらに「ＲＥＤＩＲＥＣＴコマンド」を利用したことをその本質的特徴としているのに対して，乙２４発明は，一定条件を満たす不特定のサーバーを探す単なる条件検索サービスであり，技術思想は全く異なる。乙２４発明が，検索条件による絞り込みの結果，たまたま条件を満たすサーバーが１件になった場合と，記述子に対応するＵＲＬがそもそも特定の１つに定められており，検索条件や絞り込みという概念を入れる余地がない本件発明とは異なる。(ｴ) まとめ同(ｴ)は争う。(6 ) 争点６(訂正による無効理由の解消の存否)ア 争点６−１(訂正要件及び充足)(原告の主張)(ｱ) 本件訂正(前提事実( 2)エ(ｲ))は，特許請求の範囲の減縮又は明りょうでない記載の釈明であり，かつ，他の訂正要件も満たしている。(ｲ) 被告方法は，本件訂正発明の構成要件を充足する。(被告の主張)(ｱ) 原告の主張(ｱ)は明らかに争わない。(ｲ) 同(ｲ)は否認する。イ 争点６−２(進歩性欠如等)(被告の主張)本件訂正発明には，前記( 5)アないしウの各被告の主張のとおり，依然として開示義務違反，新規性の欠如及び進歩性の欠如の無効理由が存在するから，無効理由は解消されていない。(原告の主張)被告の主張は否認する。(7 ) 争点７(主体性)(原告の主張)ア 道具理論(ｱ) まとめ被告は，クライアントＰＣを使用するユーザーの行為を道具として利用することにより，被告方法を使用し，本件発明を直接侵害しているから，差止め及び除却請求の相手方となる。(ｲ) 外形的・即物的行為の管理ａ 被告は，前提事実( 3)アのとおり，被告サービスを開設し，そのトライアル登録サービス「Test Operation」を開始し，その優先登録サービス「Sunrise Operation」を開始した。さらに，被告は，登録された日本語インターネットアドレスを管理する(甲の４の１)などし，被告サービスを提供している。ｂ 被告は，被告サービスが実現されるために用いられる「NLIA サーバー」及び「NLIA Name Server」を所有ないし管理している。ｃ 被告は，利用者に対して被告サービス利用の積極的勧誘行為を行っている。ｄ 被告は，被告サービスの使用方法について，自身が開設したウェブサイト上で詳細な解説を行っており，利用者はかかる解説を参照して被告サービスを利用している。ｅ ウェブページへの接続は，最終的に「NLIA サーバー」からクライアントＰＣに返送される「ＲＥＤＩＲＥＣＴコマンド」に含まれたＵＲＬによって自動的に行われる。ｆ 上記ａないしｅの事実からすると，被告は，侵害行為の前提となる外形的・即物的行為を管理し得る立場にある。(ｳ) 利益の帰属被告は，日本語インターネットアドレス(JAddress)登録を受け付け，キーワード登録を行った者から登録料収入を得ており(甲１０)，被告サービスの運営を通じて得られる営業上の利益を享受しようとしている。イ 共同侵害行為(ｱ) まとめ仮に，アが認められないとしても，被告は，クライアントＰＣを使用するユーザーと共同して，被告方法を使用し，本件発明を直接侵害しているから，差止め及び除却請求の相手方となる。(ｲ) 客観的要件ユーザーのクライアントＰＣと，被告が所有・管理する NLIA サーバー」 「NLIA「 及びName Server」との共同行為によって，本件発明が実施されている。したがって，客観的要件を充足する。(ｳ) 主観的要件ａ 被告の認識被告は，ユーザーのクライアントＰＣに対する日本語インターネットアドレスの入力・送信を契機として被告方法が実施されることを認識し，クライアントＰＣのユーザーに対して，積極的に被告サービスの利用を促している。したがって，被告には，クライアントＰＣの動作を利用する意思が存在する。ｂ ユーザーの認識

(a) ユーザー側のクライアントＰＣは，通常のコンピュータ機器にすぎず，現代社会においてはだれもが備えているものであり，また，かかるコンピュータ機器がインターネットに接続されていることも高度情報化した現代社会において今や当然の状況である。したがって，インターネットに接続されたユーザー側のクライアントＰＣは，本件発明が前提とする一般的な環境にすぎず，ユーザー側の主観的共同意思は不要である。( b) 仮に，ユーザー側において主観的共同意思が必要であると解したとしても，ユーザーはクライアントＰＣに日本語インターネットアドレスを入力・送信するだけで，目的とする情報ページにクライアントＰＣが導かれることを充分認識しており，ユーザーには実施内容と結果の認識程度のシステムを利用する共同行為の認識が存在する。(ｴ) 「業として」の要件被告において，自ら被告方法の一部を実施しつつ，クライアントＰＣのユーザーによる被告方法の残部の実施を利用して自己の一部実施を補充しており，これを業として行っている以上，仮にクライアントＰＣのユーザーに個人ユーザーが含まれていたとしても，少なくとも被告について共同直接侵害が成立する。ウ 間接侵害(ｱ) まとめ少なくとも，被告は，被告方法を使用して，本件発明を間接侵害しているから，差止め及び除却請求の相手方となる。(ｲ) １０１条４号ａ 被告方法の構成Ｄ’の「『NLIA サーバー』が，当該ＵＲＬを，ＲＥＤＩＲＥＣＴコマンドを利用して，クライアントＰＣに送信する段階」におけるＵＲＬを含んだＲＥＤＩＲＥＣＴコマンドは，本件発明に係る「方法の使用にのみ用いる物」であり，かかる「ＲＥＤＩＲＥＣＴコマンド」をユーザーのクライアントＰＣに提供する被告の行為は，「方法の使用にのみ用いる物」を「譲渡」する行為に該当し，特許法１条４号に定める間接侵害行為に該当する。ｂ 「ＵＲＬを含んだＲＥＤＩＲＥＣＴコマンド」という無体物の送信であっても，「物」の「譲渡」に該当する。ｃ ＵＲＬを含むＲＥＤＩＲＥＣＴコマンドは，被告方法の使用以外の用途に用いられている事実は存在せず，ユーザーにおける被告方法の実施にのみ用いられている。(ｳ) １０１条５号ａ ＵＲＬを含んだＲＥＤＩＲＥＣＴコマンドは，特許法１０１条５号にいう「発明による課題の解決に不可欠なもの」に該当する。ｂ 被告は，遅くとも原告から警告状(甲１３)を受領した時点で，「発明が特許発明であること及びその物がその発明の実施に用いられること」を確定的に知った。(被告の主張)ア 道具理論(ｱ) まとめ原告の主張ア(ｱ)は否認する。被告方法を使用しているのは，パソコンのユーザーであって，被告ではない。(ｲ) 外形的・即物的行為の管理同ア(ｲ)は否認する。(ｳ) 利益の帰属同ア(ｳ)は否認する。イ 共同侵害行為同イは否認する。ウ 間接侵害同ウは否認する。(8 ) 争点８(損害の発生及び額)(原告の主張)ア 特許法１０２条２項の損害(ｱ) 売上げａ 被告は ，平成１８年９月５日から日本語インターネットアドレス JAddress」「の優先登録サービス「Sunrise Operation」を開始しただけでなく(前提事実(3)ア)，同年月からその商用登録サービス「Commercial Operation」を開始し，同年１２月末日までに，少なくとも４０００件の登録を得た。ｂ 被告は，登録したサイト運営者から，登録料金として，１件当たり少なくとも３万１５００円を受領し，少なくとも１億２６００万円の売上げを上げた。３万１５００円×４０００件＝１億２６００万円(ｲ) 利益率被告サービスにおける利益率は，少なくとも７０％を下らない。(ｳ) まとめよって，被告は，少なくとも８８２０万円の利益を得たものであり，原告は，特許法１０２条２項に基づき，同額の損害を被ったものと推定される。１億２６００万円×７０％＝８８２０万円イ 弁護士費用相当額の損害(ｱ) 本件事案の性質・内容から，原告は弁護士である原告代理人らに本件訴訟提起を依頼せざるを得なかった。(ｲ) その結果，原告は原告代理人らに弁護士費用の支払を約し，少なくとも３５万円の弁護士費用相当額の損害を被った。ウ まとめよって，原告は，被告に対し，民法７０９条，特許法１０２条２項に基づき，９１万円及びこれに対する平成１９年２月１５日から支払済みまで民法所定の年５分の割合による遅延損害金の支払を求める。(被告の主張)ア 特許法１０２条２項の損害(ｱ) 売上げ原告の主張ア(ｱ)は否認する。被告は，当初，平成１８年１１月から商用登録サービスを開始する予定であったが，その開始を延期し，現在に至っており，登録料等一切の利益を得ていない。(ｲ) 利益率同ア(ｲ)は否認する。(ｳ) まとめ同ア(ｳ)は否認する。イ 弁護士費用相当額の損害同イは否認する。ウ まとめ同ウは否認する。

第３ 当裁判所の判断

１ 争点５−３(進歩性の欠如)について

(1 ) 乙２４発明ア 乙２４の１及び２によれば，乙２４刊行物(昭和６３年にＡＣＭ(アメリカ計算機学会)出版から発行された論文集「 COMPUTER COMMUNICATION REVIEWVolume17, Number5 Special Issue」 のうち ， Part 8. RESOURCE SHARING IN「DISTRIBUTED SYSTEMS」の中の Larry L. Peterson 執筆の論文 A Yellow-Pages Service「for a Local-Area Network」)には，以下の記載があることが認められる(一部は，当事者間に争いがない。)。(ｱ) 「 In addition to describing the implementation of the yellow-pages service within alocal-area network, we show how the service can be integrated with the available internetcommunication protocols to enable clients from throughout the internet to access localservers.」(訳文「イエローページ・サービスのローカルエリア・ネットワーク内での実施の説明だけでなく，インターネットの至る所からクライアントがローカル・サーバーにアクセスできるようにするために，本サービスが，使用可能なインターネット通信プロトコルとどのように統合できるかを示す 。」)(２３５頁左欄７行∼行)(ｲ) 「 This paper describes a yellow-pages service that maps the name of a service intothe address of a server willing to provide the service」 (訳文「この論文では，サービスを提供しようとするサーバーのアドレスにサービス名をマッピングするイエローページ・サービスについて説明する 。」)(２３５頁左欄１４行∼１６行)(ｳ) 「 A client that wishes to engage a service queries the yellow-pages service for theaddress of a server, specifying the name of the service and any attributes the server shouldpossess.The yellow-pages service returns the address of one or more servers that satisfy theclient's requirements.」(訳文「サービスを受けたいクライアントは，サービス名およびサーバーが持つべき任意の属性を指定して，イエローページ・サービスにサーバーのアドレスを問い合わせる。イエローページ・サービスは，クライアントの要求を満たす１あるいは２以上のサーバーのアドレスを返送する 。」)(２３５頁左欄下から２行∼右欄４行)(ｴ) 「 Clients connect to the flagship host as though the server is available on that host.A forwarding mechanism running on the flagship host then "patches" the client through to anactual server that provides the service. 」 (訳文「クライアントは，フラグシップ・ホスト上でサーバーを使用できるかのように ，フラグシップ・ホストに接続する 。次に ，フラグシップ・ホスト上で動作する転送メカニズムが，実際にそのサービスを提供するサーバーにクライアントを接続させる 。」)(２３５頁右欄１０行∼１４行)(ｵ) 「 A set of servers implement the yellow-pages service. Each server maintains adatabase of information about the available services and servers.」 (訳文「サーバーのセットが，イエローページ・サービスを実施する。各サーバーは，使用可能なサービス及びサーバーに関する情報のデータベースを維持する 。」)(２３５頁右欄下から７行∼５行)(ｶ) 「 An attribute is a syntactic object that denotes a property or characteristic of aserver.」(訳文「属性は，サーバーのプロパティまたは特徴を示す統語的要素である。」)(２３６頁左欄２行∼３行)「 Clients submit a set of attributes when querying the yellow-pages for a server thatprovides a particular service.」(訳文「クライアントは，ある特定のサービスを提供するサーバーについてイエローページに問い合わせる際，属性のセットを送信する。」)(２３６頁左欄１１行∼１３行)(ｷ) 「 Associated with each yellow-pages server is a database of information about theservices available in the system. The database contains bindings of each service to a set ofservers that provide the service. 」 (訳文「各イエローページ・サーバーには，システム内で使用できるサービスについての情報のデータベースが関連付けられる。データベースには，各サービスとそのサービスを提供するサーバーのセットとを結び付けたものが格納される 。」)(２３６頁左欄下から４行∼最終行)(ｸ) 「 Clients query the yellow-pages service for the address of one or more servers thatprovide a given service with the operation」(訳文 クライアントは ，「 以下のオペレーションによって，イエローページ・サービスに対し，ある所定のサービスを提供する１あるいは２以上のサーバーのアドレスを問い合わせる 。」)(２３７頁左欄２行∼４行)(ｹ) 「 As another example, suppose the client wishes to retrieve the address of theprinter based on its location: e.g., " the printer in Rick's office". In this case, the client invokesthe lookup() operation with the mandatory attribute loc=rick. Any number of optionalattributes are ignored because the mandatory attribute loc=rick selects a single server.」 (訳文「別の例として，クライアントが場所，例えば「 Rick のオフィスのプリンタ」などに基づいてプリンタのアドレスを取得したいとする。この場合，クライアントは必須属性を loc=rick として lookup()オペレーションを要求する。必須属性 loc=rickによって唯一のサーバーが選択されるので，オプション属性がいくつあってもすべて無視される 。」)(２３８頁右欄２０行∼２６行)(ｺ) 「 This section describes how the yellow-pages service is integrated with the internettransport protocols, therby allowing clients from throughout the internet to access serverswithin an autonomous system.」 (訳文「このセクションでは，イエローページ・サービスがどのようにしてインターネット・トランスポート・プロトコルに統合され，それによって，クライアントがインターネットの至る所から自立システム内のサーバーにアクセスできるのかを説明する。)(２３９頁右欄１５行∼１８行)「 A single host in the local system is designated as the flagship host; 」 (訳文「ローカルシステム内の１つのホストが，フラグシップ・ホストとして指定される。)(２３９頁右欄２３行∼２４行)「 The system advertizes the flagship as offering a set of services to Internet clients byregistering a set of resource records − potentially one for each service − with the domainnaming system.」(訳文「システムは，１つのセットのリソース・レコード(リソース・レコードは，潜在的には各サービスにつき１つである。)をドメイン名システムに登録することによって，サービスのセットをインターネット・クライアントに提供するものとして，フラグシップを広告する 。」(２３９頁右欄２５行∼２９行。注は省略)(ｻ) 「 A client consults the domain name server to learn the address of a host at thesystem that offers a particular service and the address of the flagship host is returned. Theclient then contacts the server by sending one or more packets addressed to the well-knownport on the flagship host. The flagship host, in turn, forwards the packets to a server within thesystem. Thus, the forwarding mechanism is analogous to the strategy of accessing a server atwell-known port: The flagship serves as the "well-known host" for the system.Consider how the forwarding mechanism is implemented within TCP in more detail. TheTCP module running on the flagship host is modified to include the forwarding mechanism.Associated with the forwarding mechanism is a table that binds well-known ports to theaddresses of servers.」(訳文「クライアントは，システムにおいて特定のサービスを提供するホストのアドレスを取得するためにドメイン名サーバーに問い合わせ，フラグシップ・ホストのアドレスが返される。その後，クライアントは，フラグシップ・ホスト上のウェルノウンポートあてに１あるいは２以上のパケットを送信することによって ，サーバーに接続する 。すると ，フラグシップ・ホストは ，そのパケットをシステム内のサーバーに転送する。このように，転送メカニズムは，ウェルノウンポートにおいてサーバーにアクセスする戦略と類似している 。フラグシップは ，システムに対して ，『ウェルノウンホスト』の役割を果たす。転送メカニズムがＴＣＰ内でどのように実施されるかを更に詳細に検討する。フラグシップ・ホスト上で動作するＴＣＰモジュールが，転送メカニズムを含むように変更される。転送メカニズムには，ウェルノウンポートをサーバーのアドレスに結び付けるテーブルが関連付けられる 。」)(２３９頁右欄３１行∼２４０頁左欄１行)(ｼ) 「 When a packet arrives at the TCP module addressed for some port, the forwardingmechanism is consulted to see if forwarding is to take place for that port; i.e., if there is anentry in the table. If the packet is from a new client, the forward server randomly selects oneof the available servers and forwards the packet on to it. That is, the forwarding mechanismsets the packet's destination address to the server's address and resends packet.」 (訳文「あるポートあてのパケットがＴＣＰモジュールに到着すると，そのポートへの転送が行われるべきか，すなわち，テーブルにエントリが存在するかについて，転送メカニズムが問い合わせられる。そのパケットが新しいクライアントからである場合，フォワード・サーバーがランダムに入手可能なサーバーの１つを選択し，パケットをそのサーバーに転送する。すなわち，転送メカニズムは，パケットの宛先のアドレスをそのサーバーのアドレスに設定し，パケットを再送信する 。」)(２４０頁左欄１８行∼２５行)(ｽ) 「 Subsequent packets sent on the same connection are forwarded to the sameserver.」(訳文「同一の接続上で送信される後続のパケットは，同一のサーバーに転送される 。」)(２４０頁左欄２９行∼３０行)(ｾ) 「 by engaging the selection algorithm at the server rather than the client, theyellow-pages service effectively moves the "function to the data" rather than the " data to thefunction". That is, the selection algorithm executes on the same host as the database and arelatively small answer − a server address − is returned.」（訳文「クライアントではなくサーバーにおいて選択アルゴリズムを関与させることにより，イエローページ・サービスは「機能にデータ」よりむしろ「データに機能」を効果的に移動する。すなわち，選択アルゴリズムはデータベースと同じホスト上で実行し，相対的に小さい回答−サーバー・アドレス−が返される 。 （２４１頁左欄下から１３行∼８行））(ｿ) 「 The forwarding mechanism acts as an intermediary between the client and server.This has the advantage of not requiring any changes to the transport protocol because theclient is shielded from the indirection. In contrast, the protocol could be modified such that theflagship host informs the client that it should redirect its packets to the server host.While thismight be reasonable in the case of a connection oriented protocol( e.g., TCP )」(訳文「転送メカニズムはクライアントとサーバー間の仲介人の機能を果たす。これは，クライアントが間接参照から守られているため，トランスポートプロトコルに対してあらゆる変更を要求しないという優位点を有する。対照的に，プロトコルは，フラッグシップ・ホストがクライアントに対して，そのパケットをサーバー・ホストにリダイレクトする必要があると知らせるように修正できるであろう。これは接続指向プロトコル(例えばＴＣＰ)のケースでは妥当である可能性があるが ，」)(２４１頁右欄下から１２行∼５行)イ 上記各記載によれば，乙２４刊行物(乙２４の１)には，以下の構成(乙２４発明)が開示されている(一部は，当事者間に争いがない。)。Ａ’インターネットの至る所からクライアントがローカル・サーバーにアクセスできるようにする方法である(２３５頁左欄９行∼１２行)。フラグシップ・ホスト上で動作する転送メカニズム(forwarding mechanism)が，実際にそのサービスを提供するサーバーにクライアントを接続させる( patch)(２３５頁右欄１０行∼１４行)。Ｂ’サービスを受けたいクライアントは，サービス名およびサーバーが持つべき任意の属性を指定して，イエローページ・サービスにサーバーのアドレスを問い合わせる(２３５頁左欄下から２行∼右欄２行)。クライアントは，システムにおいて特定のサービスを提供するホストのアドレスを取得するためにドメイン名サーバーに問い合わせ，フラグシップ・ホストのアドレスが返される(２３９頁右欄３１行∼２４０頁左欄２行)。イエローページ・サーバーに提供されたサービス名等に対し返されたアドレスは，同サーバー上で稼動する選択アルゴリズムによって演算され抽出選択されたものであり，選択アルゴリズムの設定次第で，１つのサーバーのアドレスのみを抽出選択するようにできる(２４１頁左欄下から１３行∼８行，弁論の全趣旨)。Ｃ’サーバーのセットが ，イエローページ・サービスを実施する 。各サーバーは ，使用可能なサービスおよびサーバーに関する情報のデータベースを維持する(２３頁右欄下から７行∼５行)。各イエローページ・サーバーには，システム内で使用できるサービスについての情報のデータベースが関連付けられる。データベースには，各サービスとそのサービスを提供するサーバーのセットとを結び付けたものが格納される 。」)(２３６頁左欄下から４行∼最終行)イエローページ・サービスは，サービス名をサーバーのアドレスにマッピングする(２３５頁左欄１４行∼１６行)。Ｄ’イエローページ・サービスは，クライアントの要求を満たす１あるいは２以上のサーバーのアドレスを返送する(２３５頁右欄２行∼４行)。クライアントは，ローカルシステム内のフラグシップ・ホスト上のウェルノウンポートあてに１あるいは２以上のパケットを送信する。フラグシップ・ホストは，そのパケットをシステム内のサーバーに転送する(以上，２４０頁左欄２行∼５行)。転送メカニズムは，パケットの宛先のアドレスをそのサーバーのアドレスに設定し，パケットを再送信する(２４０頁左欄２３行∼２５行)。プロトコルは，フラグシップ・ホストがクライアントに対して，そのパケットをサーバー・ホストにリダイレクトする必要があると知らせるように修正できる(２頁右欄下から８行∼６行)。Ｇ’クライアントが，ローカル・サーバーを使用できるように，フラグシップ・ホストに接続する方法(2 ) 一致点と相違点ア 一致点乙２４発明と本件発明とを対比すると，両者は，下記イないしキの点で一応相違するが，その余の点で一致すると認められる。イ 相違点１(「ＵＲＬにマッピングする」構成要件Ｃ)本件発明は「翻訳データベースを用いてＵＲＬにマッピングする」(構成要件Ｃ)ものであるが，乙２４発明の構成Ｃ’は ，「サービス名を(サービスを提供しようとする)サーバーのアドレスにマッピングする」ものであり ，「サーバーのアドレス」が「ＵＲＬ」に対応するか否かが明らかではない。ウ 相違点２(「ＲＥＤＩＲＥＣＴコマンド中の前記ＵＲＬを前記クライアントに返送する」構成要件Ｄ)本件発明は「ＲＥＤＩＲＥＣＴコマンド中の前記ＵＲＬを前記クライアントに返送する」(構成要件Ｄ)ものであるが，乙２４発明は ，「フラグシップ・ホストが，クライアントに対して，サーバー・ホストのアドレスを返送するとともに，そのパケットをサーバー・ホストにリダイレクトする必要があると知らせる 」ものであり ，

①「サーバー・ホストのアドレス」が「ＵＲＬ」に対応するか否かが明らかではな

く(上記イの相違点１と同じ。)，②「リダイレクトする必要があると知らせる」ことが，本件発明の「ＲＥＤＩＲＥＣＴコマンド」に相当するか否かが明らかではない。エ 相違点３(構成要件Ｅ及びＦ)乙２４発明は，本件発明の構成要件Ｅ(「前記クライアントに前記ＵＲＬを用いて情報を要求させ」)，構成要件Ｆ(「前記ＵＲＬにより識別されたページを前記クライアント側で表示する」)段階を有するか否かが明らかではない。オ 相違点４(「情報ページ」構成要件Ａ及びＧ)乙２４発明には，アクセス先がサーバーシステムに備わる「情報ページ」であることが明示されていない。カ 相違点５(「記述子」構成要件Ｂ)乙２４発明の構成Ｂ ’ 「 サービス名およびサーバーが持つべき任意の属性 」が ，の本件発明の構成要件Ｂの「記述子」に相当するか明らかではない。キ 相違点６(「翻訳データベース」構成要件Ｃ)乙２４発明の構成Ｃ’の「データベース」が本件発明の構成要件Ｃの「翻訳データベース」であるか否かが明らかではない。なお ，原告は ， 翻訳データベース 」の点は争うが ，乙２４発明の「 イエローペー「ジ・サーバー」が構成要件Ｃ及びＤの「ディレクトリサーバー」に相当することについては争わないものと認められるから，この点は自白したものとみなす。(3 ) 相違点についての判断ア 相違点１(「ＵＲＬにマッピングする」構成要件Ｃ)(ｱ)ａ 乙２８及び弁論の全趣旨によれば，乙２８刊行物(「ＩｎｔｅｒｎｅｔＵｓｅｒ １９９５年２月号 」１９９５年２月１日 ，ソフトバンク株式会社発行)は，インターネット関連の一般の情報誌であるが，その「ＷＷＷサーバーで情報を発信する ＨＴＭＬ攻略法」との項目の記事中に，以下の記載があることが認められる。「インターネットにはさまざまな資源があり，従来，それらは ftp や telnet などのプログラムを使って利用されてきた。 ftp や telnet などのプログラムを使った資源の利用法には，次のような２つの問題がある。

① 利用する資源に応じてさまざまなプログラムの利用法を習得する必要があるこ

と

② それぞれの資源どうしの間に関連付けがないこと

ＷＷＷ( World Wide Web)は ，上記の２つの問題を解決するためのアイデアである 。つまり，ＷＷＷではＵＲＬという形式でインターネット上の資源を指示し， httpというプロトコルと HTML というマークアップ言語によってインターネット上の資源を有機的につなぎ合わせ，有効に利用することができるのである 。」(１１７頁右欄３行∼１５行。注は省略)「 http(HyperText Transfer Protocol)は ，ＷＷＷの中核となるプロトコルである 。 (１」頁右欄下から６行∼５行)「ＵＲＬはインターネット上の資源を統一的に示す方法で，ＷＷＷブラウザを使うときや ，ＨＴＭＬ形式の文章でインターネット上の資源を示すときに使われる 。」(１１８頁左欄１６行∼１８行)「ホスト名はドメイン形式で記述するＵＲＬの書き方の中で，ホスト名とはＷＷＷサービスを行っているホストの名前のことである 。」(１１８頁右欄１２行∼１４行)「①ＷＷＷブラウザは，ホスト名をＩＰアドレスに変換してから利用する

②インターネットでは，この変換にネーム・サーバーを使う

③ネーム・サーバーに問い合わせるときには ，ドメイン名がなくてはならない 」(１

頁左欄３行∼７行)ｂ これらの記載によれば，インターネット上のサービスとしてＨＴＴＰによるＷＷＷサービスがあり，このＷＷＷサービスを行っているホスト(サーバー)にアクセスするには，ドメイン名を含むＵＲＬを用いることは，本件出願当時，周知の技術であったと認められる。(ｲ) したがって，インターネット上でサービスを提供する乙２４発明において上記ＷＷＷサービスを採用することは，当業者が容易になし得たことであり，ＷＷＷサービスを採用した場合，サーバーのアドレスとして「ＵＲＬ」を選択するものにすることも，当業者が容易になし得たことと認められる。イ 相違点４(「情報ページ」構成要件Ａ及びＧ)(ｱ) 乙２４発明において ローカル・サーバーにアクセス 」「 するとは ，単にサーバーコンピュータにアクセスすることではなく，そのサーバーコンピュータが提供する情報サービスにアクセスすることを意味すること，並びに乙２８(「Ｉｎｔｅｒｎｅｔ Ｕｓｅｒ １９９５年２月号」１９９５年２月１日，ソフトバンク株式会社発行)の１１８∼１１９頁図１∼図４には，ウェブ・ブラウザが情報ページを表示することが示されていることは，原告において明らかに争わないから，これを自白したものとみなす。(ｲ) したがって，インターネット上のサーバーシステムとしてＷＷＷサービスを採用した乙２４発明を「情報ページ」を表示するように構成することは，当業者が容易に想到し得たことであると認められる。ウ 相違点２(「ＲＥＤＩＲＥＣＴコマンド中の前記ＵＲＬを前記クライアントに返送する」構成要件Ｄ)及び相違点３(構成要件Ｅ及びＦ)(ｱ) 本件明細書に ，「ＲＥＤＩＲＥＣＴコマンド」に関して，以下の記載があることは，当事者間に争いがない。「メッセージ２では，ディレクトリサーバー６０２がＲＥＤＩＲＥＣＴをクライアント６０１に送信し，これには，データベース６０４から演算されたＮＵＭＢＥＲに対する目標ＵＲＬが記述されている。クライアントブラウザ６０１は続いて自動的にメッセージ３を送信し，このＵＲＬのコンテンツをＧＥＴする。商業者サーバー６０３はメッセージ４におけるこの情報を返送する 。」(【００４５】)この記載によれば，本件発明の「ＲＥＤＩＲＥＣＴコマンド」とは，サーバーからクライアントに送信され，クライアントが前記サーバーとは別のサーバーへ自動的に送信する命令であると認められる。(ｲ) 前記(1)イのとおり ，乙２４発明の構成Ｄ ’における「 リダイレクト 」は ，「フラグシップ・ホストがクライアントに対して，そのパケットをサーバー・ホストにリダイレクトする必要があると知らせる」ものである。(ｳ)ａ 乙２６によれば ，乙２６(「 ＵＮＩＸ ＵＳＥＲ １９９４年１２月号 」平成６年１２月１日，ソフトバンク株式会社発行)には ，「新インターネット構築術 第１６回 World Wide Web その４ ＷＷＷサーバー用データ記述言語ＨＴＭＬ 応用編 」「今回は，ＷＷＷサーバーによる情報提供の応用的な仕掛けについて解説する 。」(１２９頁)として，次の記載があることが認められる。「… CGI スクリプトからの出力として，ドキュメントの内容自身を出力する以外に ，別のドキュメントの位置を返すということもできる 。このためには ，Location：ヘッダーを用いて，Location： 目的のドキュメントのＵＲＬという形式の情報(ヘッダー)を返せばよい。これによって，既存のドキュメントをダイナミックに選択して表示できる 。」(１３０頁左欄１４行∼２０行)また，１２９頁の図１には，サーバーとクライアントがＨＴＴＰにおいて交互に送信する旨の記載がある。ｂ これらの記載によると，ＨＴＴＰにおいてＵＲＬを含む「ＲＥＤＩＲＥＣＴコマンド」をクライアントに送信してクライアントにおいて自動的に情報ページを表示することは，本件出願当時，周知の技術であったと認められる。なお，被告は， 同号証１３５頁左欄下から １０行以下の「●他のＵＲＬに変換∼ RedirectRedirect に指定したパターンにマッチした場合は，指定したＵＲＬにリクエストがそのままフォワードされる。サーバーが引っ越したような場合に用いる。ＵＲＬは『 http://ホスト名 /』から書かなければならない 。」との記載を指摘するが，上記記載中の動作は， httpd の動作を規定する httpd.conf の一部であり，サーバー側で実行されるものであって，クライアントに別のドキュメントの位置を返送するものではなく，本件発明の「ＲＥＤＩＲＥＣＴコマンド」とは異なるものと認められる。したがって，ＨＴＴＰ上のものではない乙２４発明において，ＨＴＴＰによるＷＷＷサービス(乙２８)を採用してサービスを提供する際に，プロトコルによる相互接続性を保つため，乙２４発明の「リダイレクト」に代えて，乙２６に記載されているＨＴＴＰにおけるリダイレクト機能に関する周知技術を適用することにより，ＵＲＬを含むＲＥＤＩＲＥＣＴコマンドをクライアントに送信して，クライアントにおいて自動的に情報ページを表示させるようにすること(構成要件Ｄ，Ｅ及びＦ)は，当業者が容易に想到し得たことと認められる。ｃ なお，乙２４発明において，ローカルエリア・ネットワーク内でイエローページ・サービスを提供するイエローページ・サーバーとインターネット上でクライアントと接続されて転送メカニズムを実現するフラグシップ・ホストは，同一のものとは記載されていない。しかし，コンピュータの汎用性と高能力化の進展にかんがみると，両者を物理的に１つのサーバーで実現することは単なる設計的事項というべきであり，インターネット上で動作可能なプロトコルであるＨＴＴＰを前提とすれば，その具体的設計も当業者には自明のことであると認められる。エ 相違点５(「記述子」構成要件Ｂ)(ｱ)ａ 原告は，本件発明の構成要件Ｂの「記述子」とは，電話番号・会社名・製品名等のＵＲＬとは異なる数字あるいは言葉であって，目標情報ページを識別する「特定かつ唯一のＵＲＬ」と結び付くものであるが，乙２４発明の「サービス名およびサーバーが持つべき任意の属性」は ，「特定かつ唯一のＵＲＬ」と結び付くものではないから，本件発明の「記述子」とは異なる旨主張する。ｂ 確かに，本件発明(請求項１)が ，「記述子」と「ＵＲＬ」を書き分けていることからすると，構成要件Ｂの「記述子」は，電話番号・会社名・製品名等の数字あるいは言葉であり，ＵＲＬを含まないと解することはできる。ｃ しかし ，「特定かつ唯一のＵＲＬ」と結び付く点については，本件明細書には，本件発明の「記述子」の意味を「特定かつ唯一のＵＲＬ」と結び付く何か特別の限定を伴ったものと解釈すべきことを窺わせる記載は認められない。それ自体は「特定かつ唯一のＵＲＬ」と結び付かない「記述子」の送信に対し ，「特定かつ唯一のＵＲＬ」が返信されるのは ，「翻訳データベース」の構成の問題であると考えられる(この点は，本件訂正後であっても同様である。)。(ｲ) 乙２４発明の構成Ｂ’は ，「サービス名およびサーバーが持つべき任意の属性」を指定して，イエローページ・サービスにサーバーのアドレスを問い合わせるものであるから ，「サービス名およびサーバーが持つべき任意の属性」は，ＵＲＬを含んでおらず，本件発明の「記述子」に相当すると認められる。よって，この点を相違点と認めることはできない。オ 相違点６(「翻訳データベース」構成要件Ｃ)(ｱ) 前記ウのとおり，乙２４発明において周知のリダイレクト機能を採用した以上 ，ＲＥＤＩＲＥＣＴコマンドに含まれるＵＲＬは１つでなければならないから ，ＵＲＬを１つとするために，ＲＥＤＩＲＥＣＴコマンドの送信前に，ユーザーに複数の候補の中から選択させるか，複数の候補の中からの選択の段階を省略するために，マッピングにより出力されてくるＵＲＬを１つとしなければならないことは，当然である。したがって，ＵＲＬを１つとするために，ユーザーに複数の候補の中から選択させるか，それともマッピングにより出力されてくるＵＲＬを１つとするかは，その長所，短所を総合して選択する設計事項であると認められる(例えば，選択の段階を省略すれば，複数の会社が同名であり，それぞれＵＲＬを有する場合に不都合が生じ得るが，大部分の場合に速やかに目指す情報ページに到達し得ることになる。)。したがって，複数の候補の中から選択させる段階を採用せず，マッピングにより出力されてくるＵＲＬを１つとした点は，当業者が容易に想到し得たことであると認められる。(ｲ)ａ 原告は，本件発明は，会社名等とＵＲＬを１対１に対応付けしたものであり，乙２４発明とはこの点でも相違する旨主張する。しかしながら，本件発明(請求項１)は ，「翻訳データベースを用いてＵＲＬにマッピングする」(構成要件Ｃ)と規定するだけで，翻訳データベースの構造等につきそれ以上の限定はない(この点は ，［単一の目標ＵＲＬに対応する］記述子を提供する段階と限定した本件訂正発明においても同様であると考えられる。)。本件明細書の発明の詳細な説明等の中にも，原告主張のように限定して解釈すべきことを正当化する記載は見いだせない。ｂ 前記( 1)イによれば，乙２４発明のＢ’において，イエローページ・サーバーに提供されたサービス名等に対し返されたアドレスは，同サーバー上で稼動する選択アルゴリズムによって演算され抽出選択されたものであり，選択アルゴリズムの設定次第で，１つのサーバーのアドレスのみを抽出選択するようにできるものである。したがって，乙２４発明が，どのようなデータベースとして構築するかの点で，本件発明と相違すると認めることはできない。ｃ 仮に，本件発明が会社名等とＵＲＬを１対１に対応付けした構成を有するとしても，そのようにデータベースを構築することは，例えば，複数の会社が同名であり，それぞれＵＲＬを有する場合などに不都合が生じ得るが，他面で，データベースの検索アルゴリズムや構造を単純化し，ユーザーによる選択処理を省略したため処理速度が向上するなどの効果が得られることを総合衡量して決定される設計事項にすぎず，当業者にとって容易に想到し得たことと認められる。カ まとめ本件発明の奏する効果も，本件発明のように構成することから予想される範囲のものであり，格別のものとは認められない。以上によれば，乙２４発明を主引用例として本件発明のように構成することは当業者に容易に推考することができたことであり，本件発明は進歩性を欠き，本件特許は無効とされるべきものである。よって，原告は，被告に対して本件特許を行使することができない(特許法１０条の３)。

２ 争点６(訂正による無効理由の解消の存否)

(1 ) 争点６−１(訂正要件及び充足)

（原告の主張）

(ｱ)(訂正要件)は，被告において明らかに争わないからこれを自白したものとみなす。(2 ) 争点６−２(進歩性の欠如等)ア 追加の相違点の有無本件訂正により，前記１の争点５−３についての判断に加えて判断されるべき新たな相違点は生じていないから，前記１の争点５−３についての判断がそのまま本件訂正発明の進歩性の判断にも当てはまる。イ まとめしたがって，本件訂正発明は，依然として進歩性を欠くから，本件発明の無効理由は解消していない。

３ 結論

以上によれば，原告の請求は，その余の点について判断するまでもなくいずれも理由がないから，棄却することとし，主文のとおり判決する。東京地方裁判所民事第４０部裁判長裁判官市 川 正 巳裁判官大 竹 優 子裁判官中 村 恭(別紙２)被告方法説明書【サーバー方式】概要後記２項に記載の構成を備えた，インターネットに接続されたパソコンのユーザーに対し，当該パソコンのウェブブラウザのアドレスバーに任意の文字を記述することで目的のウェブページのＵＲＬを取得させ，当該ウェブページへのアクセスを提供する「Japan NLIA(Native Language Internet Address) System」に係る方法。サービス名は「JAddress」である。なお，( )内の数字は，別紙図面１の番号に対応する。構成Ａ’ インターネットよりなるコンピュータネットワークを介してクライアントが情報ページに対してアクセスする際，目的の情報ページのＵＲＬを取得する方法であって，Ｂ’ ユーザーがクライアントＰＣのウェブブラウザのアドレスバーに任意の日本語インターネットアドレス( JAddress)を入力して(1)，同日本語インターネットアドレス( 2)(正規ＵＲＬ)又は( 2’)(非正規ＵＲＬ)を予めプログラム①の付加されたＤＮＳサーバー(NLIA Name Server)に提供する段階(2)又は(2’)と，Ｃ’−Ⅰ NLIA Name Server 内において，付加プログラム①が，クライアントＰＣから送信された日本語インターネットアドレスが正規ＵＲＬであるか否かを選別し

(3)，正規ＵＲＬの場合(4)，ＤＮＳサーバーの機能によって対応するＩＰアドレスを

クライアントＰＣに送り返し(9)，Ｃ’−Ⅱ

（原告の主張）

正規ＵＲＬでない場合， NLIA Name Server」から「NLIA サーバー」へとユーザー「が入力した日本語インターネットアドレスを送信する段階と，

（被告の主張）

正規ＵＲＬでない場合， NLIA サーバー」のＩＰアドレスをクライアントに送り返「す段階(4’)と，クライアントＰＣが，取得したＩＰアドレスの「NLIA サーバー」に向けて当初ユーザーが入力した日本語インターネットアドレスを問い合わせる段階(5)と，C’−Ⅲ 日本語インターネットアドレスの送信を受けた「NLIA サーバー」が，当該日本語インターネットアドレスに対応するＵＲＬを登録情報データベースから取得する段階(6)と，D’ 「NLIA サーバー」が，当該ＵＲＬを，ＲＥＤＩＲＥＣＴコマンドを利用して ，クライアントＰＣに送信する段階(7)と，Ｅ’ クライアントＰＣが，取得したＵＲＬを一旦ＤＮＳサーバーを経由して( 8)，対応するＩＰアドレスを取得し(9)，目的の情報ページの情報を要求する段階(10)と，Ｆ’ クライアントＰＣが，目的の情報ページを表示する段階と(11)，Ｇ’ 以上の段階を備える情報ページのＵＲＬを取得する方法【プラグイン方式】概要後記２項に記載の構成を備えた，インターネットに接続されたパソコンのユーザーに対し，当該パソコンのウェブブラウザのアドレスバーに任意の文字を記述することで目的のウェブページのＵＲＬを取得させ，当該ウェブページへのアクセスを提供する Japan NLIA(Native Language Internet System)」「 に係る方法。サービス名は JAddress」「である。なお，( )内の数字は，別紙図面２の番号に対応する。構成Ａ” インターネットよりなるコンピュータネットワークを介してクライアントが情報ページに対してアクセスする際，目的の情報ページのＵＲＬを取得する方法であって，Ｂ”−Ⅰ ユーザーがクライアントＰＣのウェブブラウザのアドレスバーに任意の日本語インターネットアドレスを入力し(1)，予めクライアントに付加されたプログラム②が，同日本語インターネットアドレス( 2)(正規ＵＲＬ)又は( 2’)(非正規ＵＲＬ)を正規ＵＲＬであるか否かを選別する段階(3)と，Ｂ”−Ⅱ 入力された日本語インターネットアドレスが正規ＵＲＬの場合(2)，ブラウザの機能によって当該正規ＵＲＬをＤＮＳサーバーに送信してＤＮＳサーバーの機能によって対応するＩＰアドレスをクライアントに送り返し(4)(9)，正規ＵＲＬでない場合(2’)，当該日本語インターネットアドレスを NLIA サーバーへのＵＲＬ形式に変更した上，ブラウザの機能によって当該変更したＵＲＬ(2”)をＤＮＳサーバーに送信して，ＤＮＳサーバーの機能によって NLIA サーバーのＩＰアドレスをクライアントＰＣに送り返す段階(4’)と，Ｂ”−Ⅲ クライアントＰＣが，取得したＩＰアドレスの NLIA サーバーに向けて，当初ユーザーが入力した日本語インターネットアドレスを問い合わせる段階(5)と，Ｃ” 問い合わせを受けた NLIA サーバーが，当該日本語インターネットアドレスに対応するＵＲＬを登録情報データベースから取得する段階(6)と，Ｄ” NLIA サーバーが，当該ＵＲＬを，ＲＥＤＩＲＥＣＴコマンドを利用して，クライアントＰＣに送信する段階(7)と，Ｅ” クライアントＰＣが，取得したＵＲＬを一旦ＤＮＳサーバーを経由して( 8)，対応するＩＰアドレスを取得し(9)，目的の情報ページの情報を要求する段階(10)と，Ｆ” クライアントＰＣが，目的の情報ページを表示する段階と(11)，Ｇ” 以上の段階を備える情報ページのＵＲＬを取得する方法以 上