戻る

平成２０年１０月１７日判決言渡同日原本領収裁判所書記官
平成１９年(ﾜ)第２３５２号特許権侵害差止等請求事件
口頭弁論終結日平成２０年７月２２日
判決
東京都渋谷区＜以下略＞
原告インターネットナンバー株式会社
同訴訟代理人弁護士熊倉禎男
同飯田圭
同奥村直樹
同補佐人弁理士中村佳正
東京都千代田区＜以下略＞
被告株式会社ＮＥＴＰＩＡ
同訴訟代理人弁護士北村行夫
同亀井弘泰
同大井法子
同杉浦尚子
同雪丸真吾
同芹澤繁
同大藏隆子
同村上弓恵
同吉田朋
同大島忠尚
同杉田禎浩
同近藤美智子
同補佐人弁理士樋口盛之助
同原慎一郎
主文
１原告の請求を棄却する。
２訴訟費用は原告の負担とする。
事実及び理由
第１請求
１被告は「サービス」を提供してはならない。，JAddress
２被告は「」における「サーバー」及び「登録情報デー，JapanNLIASystemNLIA
タベース」を除却せよ。
３被告は，原告に対し，９１７０万円及びこれに対する平成１９年２月１５日
から支払済みまで年５分の割合による金員を支払え。
第２事案の概要
本件は「インターネットサーバーのアクセス管理およびモニタシステム」につ，
いての特許を有する原告が，被告が実施する「サービス」という日本語イJAddress
ンターネットアドレスに関するサービスは同特許権を侵害すると主張して，特許法
１００条１項に基づく被告のサービスの差止め及び同条２項に基づく被告のサービ
スに供された「サーバー」等の除却，並びに民法７０９条，特許法１０２条NLIA
２項に基づく損害賠償及び遅延損害金の支払を求めた事件である。
１前提事実
()当事者1
ア原告は，インターネットを利用するシステムの開発・販売及びインターネッ
トを利用した情報提供サービス業などを業とする株式会社である。
原告は，後記()アの本件発明を実施して，インターネット等の利用者がパソコ2
ンのウェブブラウザのアドレスバー等に電話番号等の「インターネットナンバー」
を入力することで特定のウェブサイトにアクセスできるようにするサービスを提供
している。
イ(ｱ)被告は，コンピュータシステムにおけるデータベースの構築・販売，情報
処理サービス業及び情報提供サービス業，インターネットでの広告業務及び広告代理
業，インターネットを利用する情報システム及び通信ネットワークの企画・設計・運
用に関する受託等を業とする株式会社である。
(ｲ)被告は韓国法人である株式会社ネッピアダッコム(以下ネッピアという)，「」。
の関連日本法人である。
(以上，甲１１，争いのない事実)
()本件特許権2
ア原告は，次の特許権を有している。以下「本件特許権」といい，請求項１
の特許発明を「本件発明，本件発明に係る特許を「本件特許，本件特許権に係」」
る出願を「本件出願」とそれぞれいう。また，本件特許権に係る明細書及び図面を
「本件明細書」といい，その特許公報(甲２)を別紙１として添付する。
特許番号第３７６２８８２号
発明の名称インターネットサーバーのアクセス管理およびモニタシステム
出願日平成８年６月３日(特願平９−５０３０８４(乙２)。優先権主張
平成７年６月７日アメリカ合衆国)
分割出願日平成１３年７月９日(特願２００１−２０８２９６)
登録日平成１８年１月２０日
特許請求の範囲(請求項１)本件明細書(別紙１)の該当欄に記載のとおり。
(争いのない事実)
イ構成要件の分説
本件発明を分説すると，次のとおりである(以下，各構成要件を「構成要件Ａ」
のようにいう。)。
Ａインターネットよりなるコンピュータネットワークを介したクライアントから
サーバーシステムへの情報ページに対するアクセスを提供する方法であって，
Ｂ前記クライアントにおいて記述子を提供する段階と，
Ｃディレクトリサーバーが，前記記述子を前記ディレクトリサーバーに存在する
翻訳データベースを用いてＵＲＬにマッピングする段階と，
Ｄ前記ディレクトリサーバーが，ＲＥＤＩＲＥＣＴコマンド中の前記ＵＲＬを前
記クライアントに返送する段階と，
Ｅ前記クライアントに前記ＵＲＬを用いて情報を要求させる段階と，
Ｆ前記ＵＲＬにより識別されたページを前記クライアント側で表示する段階と
Ｇを備えた情報ページに対するアクセス方法。
(争いのない事実)
ウ出願経過
(ｱ)第１回拒絶理由通知
特許庁審査官は，平成１７年４月１５日付けで，①本件特許権の当時の請求項１
ないし１０に係る出願について，各動作の主体がどのハードウェア手段であるかが
不明である，②請求項３の「ＲＥＤＩＲＥＣＴコマンド中のＵＲＬをクライアント
に返送してクライアントにＵＲＬを用いて情報を要求させるサーバーシステムにト
」，ランザクションデータベースが常駐するなる記載の意味が不明である等の理由で
拒絶理由を通知した。
(ｲ)第１回補正
ａこれを受けて，原告は，①の点について，平成１７年６月２０日，当時の
請求項１，３及び１０を削除し，当時の請求項２に当時の請求項３及び１０を併合
して補正後の請求項１を次のとおりとした。
「インターネットよりなるコンピュータ］ネットワークを介したクライアント［
からサーバーシステムへの情報ページに対するアクセスを提供する方法であって，
前記クライアント［において］記述子を提供する段階と［ディレクトリサーバー，
が］前記記述子を［前記ディレクトリサーバーに存在する］翻訳データベースを，
用いて［ＵＲＬ］にマッピングする段階と［前記ディレクトリサーバーが，ＲＥ，
ＤＩＲＥＣＴコマンド中の前記ＵＲＬを前記クライアントに返送して前記クライア
ントに前記ＵＲＬを用いて情報を要求させる段階］と，前記［ＵＲＬ］により識別
されたページを前記クライアント側で表示する段階とを備えた情報ページに対する
アクセス方法」(［］部分が補正部分)
原告は，同日付けの意見書において，上記補正の理由について，次のとおり主張
した。
「補正前の請求項１∼１０に係る発明の，各動作の主体がどのハードウェア手段
であるのかが不明である，に対しては，前述の補正後の請求項１のように補正して
対処し，各動作の主体のハードウェア手段を明確にしております。すなわち，記述
子を提供する段階はクライアントが行い，記述子をディレクトリサーバーに存在す
る翻訳データベースを用いてＵＲＬにマッピングする段階はディレクトリサーバー
が行い，ＲＥＤＩＲＥＣＴコマンド中のＵＲＬをクライアントに返送してクライア
ントにＵＲＬを用いて情報を要求させる段階はディレクトリサーバーが行い，ＵＲ
。」Ｌにより識別されたページを表示する段階はクライアントが行うものであります
(２頁下から１９行∼１２行)，
「本願発明では，このような長く複雑なＵＲＬに代えて，このＵＲＬに対応して
，，，誰でも簡単かつ容易に入力できる電話番号会社名製品名などを入力するだけで
目標とするＵＲＬのウェブサイトへアクセスできるようにしたものであります」。
(１頁下から３行ないし２頁１行)
ｂ原告は，②の点について，同年６月２０日付け意見書において「…補正，
前の請求項３の内容を明確にして，補正後の請求項１に併合しております。すなわ
ち，ディレクトリサーバーが，ＲＥＤＩＲＥＣＴコマンド中のＵＲＬをクライアン
トに返送してクライアントにＵＲＬを用いて情報を要求させるものであり…(２，」
頁下から１１行ないし８行目)との意見を述べ，同日付けの手続補正書において，
補正後の請求項１の記載を「前記ディレクトリサーバーが，ＲＥＤＩＲＥＣＴコマ
ンド中の前記ＵＲＬを前記クライアントに返送して前記クライアントに前記ＵＲＬ
を用いて情報を要求させる段階と」とした。，
(ｳ)第２回拒絶理由通知
特許庁審査官は，平成１７年９月２８日付けで，本件特許権の上記(ｲ)の第１回
補正後の請求項１ないし７に係る出願について，進歩性欠如を理由とする拒絶理由
を通知した。
(ｴ)第２回補正
ａこれを受けて，原告は，平成１７年１２月５日，請求項１中の「前記ディ
レクトリサーバーが，ＲＥＤＩＲＥＣＴコマンド中の前記ＵＲＬを前記クライアン
トに返送して前記クライアントに前記ＵＲＬを用いて情報を要求させる段階と」，
を「前記ディレクトリサーバーが，ＲＥＤＩＲＥＣＴコマンド中の前記ＵＲＬを前
記クライアントに返送する段階と，前記クライアントに前記ＵＲＬを用いて情報を
要求させる段階と」に補正した。，
原告は，同日付け意見書において，補正の理由について「…１つの段階から，，
ＵＲＬの返送段階と，そのＵＲＬを用いた情報要求段階との２つの段階に分けて表
現し，記載の明瞭化を図りました」(１頁下から１７行∼１６行)と主張した。。
ｂまた，原告は，同意見書において，本件発明の特徴について「本願発明，
は，インターネット上において，ユーザが電話番号，会社名，製品名等を用いて商
業サービスサイトにアクセスできる，インターネットよりなるコンピュータネット
ワークを介したクライアントからサーバーシステムへの情報ページに対するアクセ
ス方法に関する技術でありますすなわち本願発明が適用するようなインターネッ。，
トの技術分野では，ウェブサイトへアクセスする際に，長く複雑なＵＲＬを入力す
る必要があるが，本願発明では，このような長く複雑なＵＲＬに代えて，このＵＲ
Ｌに対応して誰でも簡単かつ容易に入力できる電話番号，会社名，製品名等を入力
するだけで，目標とするＵＲＬのウェブサイトへアクセスできるようにしたもので
あります」(１頁下から６行∼２頁３行)と説明している。。
ｃ特許庁審査官は，平成１８年１月５日，上記補正内容で特許査定した。
(以上，争いのない事実)
エ無効審判等
(ｱ)被告は，平成１９年１０月３１日付け審判請求書(乙３１)により，本件特
許権(請求項１ないし７)について，無効審判を請求した(無効２００７−８００２
４３)。
(ｲ)原告は，平成２０年１月２３日付け訂正請求書(甲４２)により，本件明細
書の特許請求の範囲の請求項１ないし７について，請求項１を次のとおり訂正する
等の訂正を請求した(以下「本件訂正」といい，訂正後の本件発明を「本件訂正発
明」という。理解の便宜のために，構成要件の分説の形で記載する。)。
「Ａインターネットよりなるコンピュータネットワークを介したクライアントか
らサーバーシステムへの情報ページに対するアクセスを提供する方法であって，
Ｂ前記クライアントにおいて［単一の目標ＵＲＬに対応する］記述子を提供す
る段階と，
Ｃディレクトリサーバーが，前記記述子を前記ディレクトリサーバーに存在す
る翻訳データベースを用いて［前記］ＵＲＬにマッピングする段階と，
Ｄ前記ディレクトリサーバーが，ＲＥＤＩＲＥＣＴコマンド中の前記ＵＲＬを
前記クライアントに返送する段階と，
Ｅ前記クライアントに前記ＵＲＬを用いて情報を［自動的に］要求させる段階
と，
Ｆ前記ＵＲＬにより識別されたページを前記クライアント側で表示する段階と
Ｇを備えた情報ページに対するアクセス方法(部分が訂正部分である)。」［］。
(ｳ)特許庁審判官は，平成２０年６月２６日，本件訂正を認めたが，訂正後の
請求項１ないし７の発明は進歩性欠如を理由として無効とする旨の審決をした(乙，
３２)。
(ｴ)原告は，知的財産高等裁判所に対し，上記無効審決の取消しを求める訴え
を提起した。
(以上，争いのない事実)
()被告の行為3
ア被告サービスの開始
被告は，平成１８年２月ころ，その名称を「サービス」とする日本語インJAddress
ターネットアドレスに関するサービス(以下「被告サービス」といい，このサービスで
採用されている方法を「被告方法」という。)を開設し，サイト運営者のトライアル登
TestOperationSunrise録サービスを開始し同年９月５日その優先登録サービス「」，，「
」を開始した。Operation
(争いのない事実)
イ被告方法
(ｱ)被告サービスの概略
ａ「()システム」は，インターネットにNativeLanguageInternetAddressNLIA
接続されたパソコンのユーザーに対し，当該パソコン(クライアントＰＣ)のウェブブ
ラウザ(インターネット上のウェブページを閲覧するためのアプリケーションソフト。
「ブラウザ」ともいう。)のアドレスバーに任意の文字を記述することで目的のウェブ
ページのＵＲＬ(又はＩＰアドレス)を取得することを可能とするソフトウェアを提供
するものである。
被告サービスは，この「()システム」を日本にNativeLanguageInternetAddressNLIA
おいて展開するものである。
ｂ被告サービスの提供方法には，以下の２種類がある。
①サーバー方式
被告のＤＮＳ(：ＩＰアドレスとドメインネームとを対応させるDomainNameSystem
既存のシステム)サーバー内に付加したプログラムを利用する方式
この方式は，ユーザーがクライアントＰＣにプログラムをプラグインする必要がな
い点において，後記②の方式よりも進化した方式である。
②プラグイン方式
①と同じ作用のプログラムをクライアントＰＣにプラグインする方式
(争いのない事実)
(ｲ)被告方法の構成
被告方法の構成は，別紙２被告方法説明書記載のとおりであり，サーバー方式の
構成Ｃ’−Ⅱ以外の構成は，当事者間に争いがない。
ウ構成要件の一部充足
被告方法は，本件発明の構成要件Ａ，Ｄ及びＧを充足する。
(弁論の全趣旨)
２争点
()争点１構成要件Ｂの充足1
()争点２構成要件Ｃの充足2
()争点３構成要件Ｅの充足3
()争点４構成要件Ｆの充足4
()争点５本件特許権の無効理由の存否5
ア争点５−１開示義務違反(特許法３６条４項，６項１号，２号)
イ争点５−２新規性の欠如
ウ争点５−３進歩性の欠如
()争点６本件訂正による無効理由の解消の存否6
ア争点６−１訂正要件及び充足
イ争点６−２進歩性の欠如等
()争点７主体性7
()争点８損害の発生及び額8
３争点に関する当事者の主張
()争点１(構成要件Ｂ「前記クライアントにおいて記述子を提供する段階と」1
の充足)
(原告の主張)
ア特許請求の範囲の解釈
(ｱ)「クライアントにおいて…提供する」
ａ解釈
構成要件Ｂの「クライアントにおいて…提供する」とは，ハードウェア手段であ
るクライアントＰＣ等が記述子を送信することを意味する。
記述子がディレクトリサーバーに受信される経路については，何ら限定はなく，
アドレスバーに記入された記述子をＤＮＳサーバーを介してディレクトリサーバー
に送信する場合を含む。
ｂ「クライアントにおいて」についての根拠
()本件明細書の記載a
本件明細書の発明の詳細な説明には，次の記載がある。
「本発明は，クライアントからサーバーへのネットワークを介したサービス要求
を処理する方法に関する」(【０００１】)，。
「インターネットサーバーは，ホスト上のファイルを要求するあらゆるコンピュー
タに情報を配布することができる。このような要求をするコンピュータは“クライア
ント”として知られ，これはインターネットに接続されたワークステーション，掲示
板システムまたは家庭用パーソナルコンピュータ(ＰＣ))であり得る」(【０００３】。
２頁２６行∼２９行)
()出願経過b
前提事実()ウ(ｲ)のとおり，原告は，平成１７年４月１５日付けの第１回拒絶理由2
通知の「各動作の主体がどのハードウェア手段であるかが不明である」という拒絶理
由に対し，同年６月２０日付けの意見書において「…記述子を提供する段階はクライ，
アントが行い…」との意見を述べた上，同日付けの手続補正書において，請求項１の
記載を「クライアントにおいて記述子を提供する」と補正し，特許査定された。
()まとめc
上記()及び()によると，構成要件Ｂ中の「クライアントにおいて」は，送信の主ab
体が「クライアントＰＣ等」であることを意味する。
()米国特許出願d
後記被告の主張ア(ｱ)ｂ()一及び二は認め，三は否認する。d
ｃ「提供する」についての根拠
()特許請求の範囲の記載a
，，，構成要件Ｂ及びＣは記述子についてこれを提供するのがクライアントであり
これをＵＲＬにマッピングするのがディレクトリサーバーであることを規定してい
るが，クライアントへの記述子の入力方法や記述子がディレクトリサーバーに受信
される経路については，何ら限定していない。
()本件明細書の記載b
一本件明細書には，次の記載がある。
「ユーザはまた，他のウェブページにジャンプするため，既知のＵＲＬをウェブ
ページ上のコマンドラインに直接書き込むことにより指定することができる(０。」【
００６】３頁２４行∼２６行)
「本発明は，ネットワークを介したクライアントからサーバーへのサービス要求
を処理する方法に関する。とりわけ本発明は，ワールドワイドウェブ(ウェブ)のよ
うなＨＴＴＰ(ハイパーテキスト転送プロトコル)環境におけるクライアント要求を
処理することに適する」(【００１１】４頁１５行∼１８行)。
「好ましい構成では，クライアント要求は(ＵＲＬ)によりUniformResourceLocator
ウェブブラウザから作られる」(【００１２】４頁２６行∼２７行)。
二本件明細書の上記記載からすると本件発明はクライアント要求がウェ，，「」
ブブラウザ上で処理されることを当然に想定しており「アドレスバー」に記述子を入，
力する方法を排除しているものではない。
()周知技術c
一本件出願当時，ウェブブラウザ及びＤＮＳ自体は，周知技術であった。
二したがって，クライアントのウェブブラウザのアドレスバーへ記述子が
入力され，そのままだと当該記述子が直接的にはＤＮＳに送信されるような場合も
想定されている。
三そのような場合に，クライアントにおいて記述子を認識させて直接ディ
レクトリサーバーに送信させるようにするか，ＤＮＳに記述子を認識させてディレ
クトリサーバーに送信させるようにするか，ＤＮＳ兼ディレクトリサーバーに記述
子を認識させて処理するようにするかは，当業者において適宜選択する設計事項に
すぎない。
()「ＮＯＴＦＯＵＮＤ」d
一本件明細書の【００４１】には，一実施例として，ＮＵＭＢＥＲが入力
された場合の処理について「ブラウザは次いでＮＵＭＢＥＲがユーザにより指定，
http://directory.net/NUMBERされた電話番号，またはその他の識別子である，書式“
”のＵＲＬを構成する」と記載されている。。
二この記載は，ＮＵＭＢＥＲがＨＴＴＰプロトコルによりＵＲＬを構成し
て通信することを明らかにしており，この場合「ＮＯＴＦＯＵＮＤ」が返される
ことはない。
三本件出願当時，という識別子は，ＵＲＬにおいて使用されるプロトhttp://
，，コルに関する識別子でありＵＲＬ内において規定されているプロトコルとしては
ＨＴＴＰ以外に，や等多数のプロトコルが存在し，ＵＲＬの先頭にコンftpgopher
ピュータプログラムにおいて判別可能な文字列として記述し，コンピュータプログ
ラムにおいてはこれらを文字解析した上で適宜必要なプロトコルを選択して通信を
行うように制御させる規約となっていたことは周知であった。
四したがって，上記に規定された体系()以外に，会社名，製品名，schemes
電話番等等の記述子が入力された場合にも，何らかの体系を定めてＤＮＳから「Ｎ
ＯＴＦＯＵＮＤ」が返されないように処理を行うようにすること自体は，当業者
であれば技術常識に基づき適宜なし得た事項である。
()「提供する」の通常の意味等e
一前提事実()ウ(ｲ)のとおり，原告は，平成１７年６月２０日付け意見書にお2
いて「補正前の請求項１∼１０に係る発明の，各動作の主体がどのハードウェア，
手段であるのかが不明である，に対しては，前述の補正後の請求項１のように補正
して対処し，各動作の主体のハードウェア手段を明確にしております。すなわち，
記述子を提供する段階はクライアントが行い…」と述べた上，同日付けの手続補正
書において，補正後の請求項１を「前記クライアントにおいて記述子を提供する段階
と」とし，特許査定されている。，
二「提供」という用語は，プログラム等の送信行為を意味する(特許法２条３
項１号「電気通信回線を通じた提供，商標法２条２項８号「電磁的方法により提供す」
る」等)。
三本件明細書の【００４５】には「サーバー６０２はウェブページをクライ，
アントに返送して，要求されたドキュメントに対して適切なリンクを提供する」とし
て「提供」の用語が送信行為を意味するものとして記載されている。，
このように，本件明細書では「提供」と「送信」とを厳密に区別してない。，
四したがって「記述子を提供する」段階が，動作の主体としてのハードウェ，
ア手段であるクライアントにおいてされるものである以上「提供」の用語は，クライ，
アントが記述子を送信することを意味する。
(ｲ)「記述子」
ａ解釈
構成要件Ｂ中の「記述子」とは，電話番号，会社名，製品名等のＵＲＬとは異な
る数字あるいは言葉であり，これに対応し，目標情報ページを識別する特定かつ唯
一のＵＲＬへとマッピングされるものを意味する。
ｂ根拠
()特許請求の範囲の記載a
一構成要件Ｃでは「ディレクトリサーバーが，前記記述子を前記ディレ，
クトリサーバーに存在する翻訳データベースを用いてＵＲＬにマッピングする」と
記載されている。
二このように「記述子」と「ＵＲＬ」とは，明確に区別されている。，
()発明の詳細な説明の記載b
一本件明細書の【００４７】には，発明の効果として「…ユーザはＵＲ，
Ｌについて知る必要がない」と記載されている。。
二仮に「記述子」が「ＵＲＬ」を含むとすると，上記の本件発明の効果，
を奏することができない。
()出願経過c
前提事実()ウ(ｳ)及び(ｴ)のとおり，原告は，平成１７年１２月５日付け意見書2
で「本願発明では，このような長く複雑なＵＲＬに代えて，このＵＲＬに対応し，
，，，て誰でも簡単かつ容易に入力できる電話番号会社名製品名等を入力するだけで
目標とするＵＲＬのウェブサイトへアクセスできるようにしたものであります」。
と主張し，その後「記述子」については特に補正することなく特許査定された。，
イ充足
(ｱ)サーバー方式の場合
ａ被告方法の構成Ｂ’によれば，被告方法は「クライアント」に相当する「ク，
ライアントＰＣ」から「ディレクトリサーバー」(構成要件Ｃ)の一部に相当する「Ｄ
ＮＳサーバー」に対し「記述子」に相当する「日本語インターネットアドレス()(正，2
規)又は(’)(非正規)」を「提供する」ことに相当する「送信する」ことをURL2URL
しているので，構成要件Ｂを充足する。
ｂまた，仮に，クライアントからディレクトリサーバーへの送信方法が，直接
送信する場合に限定されるとしても，被告方法は「クライアント」に相当する「クラ，
」「」「」イアントＰＣからディレクトリサーバー(構成要件Ｃ)に相当するサーバーNLIA
に対し，当初の日本語インターネットアドレスを直接送信する段階()を備えているか5
ら，構成要件Ｂを充足する。
(ｲ)プラグイン方式の場合
ａ被告方法の構成Ｂ”−Ⅲは，構成要件Ｂを充足する。
ｂ非正規ＵＲＬの場合，当該記述子を「サーバー」へのＵＲＬ形式に変更NLIA
した上，ブラウザの機能によって当該変更したＵＲＬ(”)をＤＮＳサーバーに送信し2
てＤＮＳサーバーの機能によって「サーバー」のＩＰアドレスをクライアントにNLIA
送り返す段階(’)という構成が行われているが，構成要件Ｂは，送信の前段階として4
，，クライアントがどのような動作を行うかについて何も規定していないからこの点は
構成要件Ｂを充足すると認めることの妨げとならない。
(被告の主張)
ア特許請求の範囲の解釈
(ｱ)「クライアントにおいて…提供する」
ａ解釈
原告の主張ア(ｱ)ａは争う。
上記構成要件は，ユーザーがクライアントＰＣ等において記述子を入力すること
を意味する。
また提供するが送信することを意味するとしてもクライアントＰＣのア，「」，「
ドレスバー」に記入された記述子をディレクトリサーバーに送信する場合を含まな
い。
ｂ「クライアントにおいて」についての根拠
()本件明細書の記載a
同ｂ()は認める。a
()出願経過b
同ｂ()は認める。b
()まとめc
同ｂ()は否認する。c
()米国特許出願d
一本件発明は，米国出願における当初の請求項５に当たるが，そこには
「」と記載されている(乙６の１の１頁下から３行providingadescriptorattheclient
目)。
providingadescriptorcomprisingatelephone二補正後の請求項でも，同様に「
」と記載されている(乙７の１⑦１頁下から２行∼最終行)。numberattheclient
三したがって，構成要件Ｂの「クライアントにおいて」は「クライアン，
トＰＣで」と，記述子を提供する場所を表すもの解するほかはない。
ｃ「提供する」についての根拠
()特許請求の範囲の記載a
同ｃ()は否認する。a
()本件明細書の記載b
同ｃ()のうち，一は認め，二は否認する。b
()周知技術c
同ｃ()のうち，一は認め，二，三は否認する。c
()「ＮＯＴＦＯＵＮＤ」d
同ｃ()のうち，一は認め，その余は否認する。d
アドレスバーを使用する場合は，記述子が正規のＵＲＬか否かの選別を行う段階が
必要であるが，本件発明には，そのような段階を想定した記述はない。
原告主張のように「クライアントＰＣが送信する」と解すると，構成要件Ｃの記載
及び本件明細書【００４１】の「ディレクトリサーバー６０２に連絡し，メッセージ
１で要求されたＮＵＭＢＥＲを送信する」との記載からすると，クライアントがディ
レクトリサーバーに向けて直接「送信する」と解するほかはないが，原告は，受信経
路は限定されていないと主張しており，矛盾している。
したがって，構成要件Ｂの「記述子を提供する」とは，クライアントＰＣの「ア
ドレスバー」に記入された記述子をディレクトリサーバーに送信する場合を含まな
いと解すべきである。
()「提供する」の通常の意味等e
同ｃ()のうち，一ないし三は認め，四は否認する。e
(ｲ)「記述子」
ａ解釈
同(ｲ)ａは争う。
「記述子」は，任意のものを意味し，ＵＲＬでないものに限定する理由はない。
ｂ根拠
()特許請求の範囲の記載a
同ｂ()のうち，一は認め，二は否認する。a
()発明の詳細な説明の記載b
同ｂ()のうち，一は認め，二は否認する。b
ユーザーがＵＲＬを知る必要がないという本件発明の効果から構成要件Ｂの記，「
述子」をＵＲＬとは異なるものであると限定する解釈は，当然には導かれない。
()出願経過c
同ｂ()は認める。c
イ充足
原告の主張イは，いずれも否認する。
被告方法では「アドレスバー」に入力された記述子はＤＮＳサーバーに送られ，
ており，直接ディレクトリサーバーに送られていないから，構成要件Ｂを充足しな
い。
()争点２(構成要件Ｃの充足)2
(原告の主張)
ア特許請求の範囲の解釈
(ｱ)「前記記述子」
前記()(原告の主張)ア(ｲ)と同じ1
(ｲ)「ディレクトリサーバー」
ａ解釈
構成要件Ｃの「ディレクトリサーバー」がどのような経路で当該「記述子」を受
信するかについては，何ら限定はなく「ディレクトリサーバー」がＤＮＳとして，
の機能を併有してはならないという限定もない。
ｂ根拠
前記()(原告の主張)ア(ｱ)ｃと同じ。1
イ充足
(ｱ)サーバー方式の場合
ａ被告方法は，別紙２被告方法説明書のＣ’−Ⅰ，Ｃ’−Ⅱ(原告の主張)及び
Ｃ’−Ⅲのとおりである。
ｂ同Ｃ’−Ⅱ(被告の主張)の構成(’)及び()は，実際には存在しない。45
すなわち，被告方法においては「」と「サーバー」は，双，NLIANameServerNLIA
方ともに被告(又は韓国の親会社であるネッピア)によって管理運営されており(甲２
９，３０)，少なくとも物理的には両者とも１つのコンピュータ中に存在する。
クライアントＰＣから「」に送信された日本語インターネットアNLIANameServer
ドレスは「」の付加プログラム①によって非正規ＵＲＬと選別され，NLIANameServer
ると，そのまま「」から「サーバー」へと送られる構成を有すNLIANameServerNLIA
る(甲３０)。
同構成Ｃ’−Ⅱ(被告の主張)の(’)及び()は，他のプロバイダー等によって管理45
運営されているＤＮＳサーバーにおいて被告との契約に基づき被告プログラム①が付
加されているような場合に実行され得るが，被告サービスとの関係では，被告との契
約に基づき，自己が管理運営しているＤＮＳサーバーにおいて付加プログラム①を付
加している他のプロバイダー等は存在しない。
ｃ同構成Ｃ’−Ⅱ(原告の主張)及びＣ’−Ⅲによれば「サーバー」が，，NLIA
NLIANameクライアントＰＣから送信された日本語インターネットアドレスを「
」から送信を受け，当該日本語インターネットアドレスに対応するＵＲＬを登録Server
情報データベースから取得しているからディレクトリサーバーが記述子を翻，「」「」「
」「」，。訳データベースを用いてＵＲＬにマッピングしており構成要件Ｃを充足する
なお，構成要件Ｂ及びＣの「記述子」はＵＲＬを含まないから，被告方法におい
て対比の必要があるのは，日本語インターネットアドレスが入力された場合の構成
のみである。
，’，「」，ｄ仮に同構成Ｃ−Ⅱ(被告の主張)を前提としてもサーバーがNLIA
クライアントＰＣから送信された日本語インターネットアドレスに対応するＵＲＬ
，「」を登録情報データベースから取得しておりクライアントＰＣからNLIANameServer
を介しているにすぎないから，いずれにしても構成要件Ｃを充足する。
(ｲ)プラグイン方式の場合
同被告方法の構成Ｃ”は，構成要件Ｃを充足する。
(被告の主張)
ア特許請求の範囲の解釈
(ｱ)「前記記述子」
前記()(被告の主張)ア(ｲ)と同じ。1
構成要件Ｃの「前記記述子」も，アドレスバーに記載された記述子を含まない。
(ｲ)「ディレクトリサーバー」
ａ解釈
同(ｲ)ａは争う。
ｂ根拠
前記()(被告の主張)ア(ｱ)ｃと同じ1
イ充足
(ｱ)サーバー方式の場合
ａ同イ(ｱ)ａは否認する。
サーバー方式の被告方法は，別紙２被告方法説明書のＣ’−Ⅰ，Ｃ’−Ⅱ(被告の主
張)及びＣ’−Ⅲのとおりである。
ｂ同イ(ｱ)ｂは否認する。
「」と「サーバー」とは，ＩＰアドレスが異なり，物理的にNLIANameServerNLIA
も別のコンピューターに存在するものであり，実際にその間のインターネットの送信
も行われている。
ｃ同イ(ｱ)ｃは否認する。
，，，被告方法はプラグイン方式を含めアドレスバーに記述子を記入しているから
構成要件Ｃの「前記記述子」を充足しない。
仮に，構成要件Ｂの「記述子」に，アドレスバーに記入された記述子が含まれると
しても，被告方法では，アドレスバーに記入された記述子について，これが正規ＵＲ
Ｌか否かを選別し，非正規ＵＲＬと選別された記述子に限り「サーバー」，NLIA
に送られる。したがって，被告方法の構成Ｃ’−Ⅲ，Ｃ”でディレクトリサーバーに
送られる日本語インターネットアドレスは，被告方法の構成Ｂ，Ｂ”−Ⅰでクライア’
ントが提供する日本語インターネットアドレスと同義ではないから，被告方法は，構
成要件Ｃの「前記記述子」を充足しない。
ｄ同イ(ｱ)ｄは否認する。
(ｲ)プラグイン方式の場合
同イ(ｲ)は否認する。
()争点３(構成要件Ｅの充足)3
(原告の主張)
ア特許請求の範囲の解釈
(ｱ)解釈
「」構成要件Ｅにおける前記クライアントに前記ＵＲＬを用いて情報を要求させる
とは，ディレクトリサーバーがクライアントにおいて送信された記述子に対応する
ＵＲＬをＲＥＤＩＲＥＣＴコマンドに含めて当該クライアントに返送すること(構
成要件Ｄ)により，その後は，当該ＵＲＬを含む当該ＲＥＤＩＲＥＣＴコマンドに
より，当該クライアントにおいて自動的に当該ＵＲＬに対応するウェブに情報要求
することを意味し，構成要件Ｄ及び構成要件Ｅがディレクトリサーバーの１つの行
為でされる場合を含む。
(ｲ)根拠
ａ本件明細書の記載
()本件明細書には「認証サーバーは，次いでこのＳＩＤが付加されたオリa，
ジナルＵＲＬから成る新しい要求を，ＲＥＤＩＲＥＣＴによってクライアントに送
出する。新しいＵＲＬにより形成された修正要求は，自動的にクライアントブラウ
ザによりコンテンツサーバーに送出される」(【００１２】４頁３７行∼４０行。
目)との記載がある。
()上記記載は「ＲＥＤＩＲＥＣＴ」コマンドと共にＵＲＬがクライアンb，
トに返送されると，クライアントが自動的に目的ページの接続要求を出すことを意
味する。
ｂ実施例及び図面の記載
()実施例３a
本件明細書には，次の記載がある。
「メッセージ２では，ディレクトリサーバー６０２がＲＥＤＩＲＥＣＴをクライ
アント６０１に送信し，これには，データベース６０４から演算されたＮＵＭＢＥ
Ｒに対する目標ＵＲＬが記述されている。クライアントブラウザ６０１は続いて自
動的にメッセージ３を送信し，このＵＲＬのコンテンツをＧＥＴする。商業用サー
バー６０３はメッセージ４におけるこの情報を返送する。…サーバー６０２が最終
的なＵＲＬに対する翻訳を行い，ページよりはむしろＲＥＤＩＲＥＣＴをクライア
ント６０１に送信するため，メッセージ４のドキュメントは最初のダイヤル入力以
上のユーザの行為なしで入手される」(【００４５】１０頁４４行∼１１頁２行。
目)
図６には「３．“目標−ＵＲＬ”ＧＥＴ「４．ページ送信」との記載があ，」
る。
「ダイヤル”コマンドおよびその実施の利点の中には，従来の電話番号および“
他の識別子と互換性を有する，インターネットにアクセスする改善された方法があ
る。商業者はコンタクト情報のインターネット特定書式を提供するための印刷物ま
，。」たはテレビ広告を変更する必要がなくユーザはＵＲＬについて知る必要がない
(【００４７】１１頁９行∼１２行目)。
()これらの記載は，クライアントが自動的にＵＲＬを要求することを裏付b
けている。
ｃ出願経過
後記被告の主張ｃ()は認め，()は否認する。ab
上記補正は，ディレクトリサーバーがＲＥＤＩＲＥＣＴコマンド中のＵＲＬをク
ライアントパソコンに返送することによりクライアントパソコンの情報要求が自動
的に行われるという構成要件の意義に何ら変更を加えるものではない。
イ充足
被告方法の構成Ｅ’及び構成Ｅ”は，ＲＥＤＩＲＥＣＴコマンドに含まれたＵＲ
Ｌが，クライアントＰＣに返されることにより，クライアントＰＣにおいて自動的に
ウェブページへ情報要求しているから，構成要件Ｅを充足する。
(被告の主張)
ア特許請求の範囲の解釈
(ｱ)解釈
原告の主張ア(ｱ)は争う。
本件発明は，ディレクトリサーバーがＵＲＬを返送する段階(構成要件Ｄ)とディレ
クトリサーバーがＵＲＬを用いて情報を要求する段階(構成要件Ｅ)の２つの段階を含
んでおり，方法の発明である以上，構成要件Ｄと構成要件Ｅとは，時系列的に異な
る段階として行われる必要がある。
(ｲ)根拠
ａ本件明細書の記載
同(ｲ)ａのうち，()は認め，()は否認する。ab
ｂ実施例及び図面の記載
同(ｲ)ｂのうち，()は認め，()は否認する。ab
ｃ出願経過
()前提事実()ウ(ｴ)のとおり，原告は，平成１７年１２月５日付けの手続a2
補正において，請求項１を「前記ディレクトリサーバーが，ＲＥＤＩＲＥＣＴコマ
ンド中の前記ＵＲＬを前記クライアントに返送する段階と，前記クライアントに前
記ＵＲＬを用いて情報を要求させる段階と」と補正し，同日付けの意見書におい，
て，上記補正について「１つの段階から，ＵＲＬの返送段階と，そのＵＲＬを用，
いた情報要求段階との２つの段階に分けて表現し，記載の明瞭化を図りました」。
と述べた。
()この事実は，構成要件Ｄと構成要件Ｅとは，時系列的に異なる段階としb
て行われる必要があることを裏付ける。
イ充足
同イ(ｱ)は否認する。
被告方法では，ディレクトリサーバーである「サーバー」が，構成要件ＤとNLIA
は時系列的に異なる段階として，クライアントにＵＲＬを用いて情報を要求させる段
階(構成要件Ｅ)を行っていない。殊に，被告方法では，同構成Ｅ’及び構成Ｅ”のと
，，おりクライアントのブラウザのアドレスバーを利用した標準的なプロトコルを用い
「サーバー」からアドレスバーに所期のＵＲＬを返しさえすれば，その後は，クNLIA
ライアントに備わっているブラウザが当該ＵＲＬによって識別されたページを(ＤＮＳ
サーバーを介して)取得し，クライアントＰＣに表示するものであり，時系列的に異な
る段階として，構成要件Ｅに当たる段階を有しないことは明らかである。
()争点４(構成要件Ｆの充足)4
(原告の主張)
ア特許請求の範囲の解釈
前記争点()(原告の主張)アと同じ。3
イ充足
被告方法の構成Ｆ’及び構成Ｆ”は「ＲＥＤＩＲＥＣＴコマンド」に含まれたＵ，
ＲＬがクライアントＰＣに返されることにより，クライアントＰＣにおいて自動的に
ウェブページへ情報要求し(構成Ｅ’及び構成Ｅ”)，ウェブページへ接続する(構成Ｆ
’及び構成Ｆ”)から，構成要件Ｆを充足する。
(被告の主張)
ア特許請求の範囲の解釈
前記争点()(被告の主張)アと同じ。3
イ充足
原告の主張イは否認する。
被告方法は，上記()(被告の主張)イのとおり，構成要件Ｅの段階を有しないか3
ら，構成要件Ｆも充足しない。
()争点５(本件特許の無効理由の存否)5
ア争点５−１(開示義務違反(特許法３６条４項，６項１号，２号))
(被告の主張)
(ｱ)記載不明瞭
ａ構成要件Ａ及びＧ
構成要件Ａの「アクセスを提供する方法，構成要件Ｇの「アクセス方法」は，」
「アクセス」する主体が異なっており「アクセス「アクセスを提供する「アク，」」
セスする」が具体的に何をする行為を意味するのかが不明瞭である。
ｂ構成要件Ｂ
()クライアントによる記述子の提供方法を特定していない。a
()被告方法のように，クライアントがアドレスバーに記述子を入力した場b
合は，正規のＵＲＬか否かを選別する段階がなければ「ディレクトリサーバー」，
に記述子が送られることはない。
しかし，本件発明には，上記の選別する段階について何も記載されていない。
ｃ構成要件Ｃ
()「ディレクトリサーバー」という文言が不明瞭である。a
()クライアントが提供した記述子を「ディレクトリサーバー」が受け取るb
方法を特定していない。
(ｲ)まとめ
，，，よって本件発明は平成１４年法律第２４号による改正前の特許法３６条４項
６項１号，２号に違反し，本件特許は，同法１２３条１項４号の規定により無効と
されるべきである。
(原告の主張)
(ｱ)記載不明瞭等
ａ構成要件Ａ及びＧ
被告の主張(ｱ)ａは否認する。
構成要件Ａの「アクセスを提供する方法」とは，本件発明の実施主体が「アクセ
スを提供する」ものであり，発明の実施行為自体は究極的に発明実施主体である人
によって行われることを明らかとしつつ，そのための具体的構成である要件Ｂない
しＧはさまざまなハードウェアによって実現されていくものであることを表現した
ものである。構成要件Ｇの「アクセス方法」は，構成要件Ａの「アクセスの提供」
を実現するために発明の構成要件として，ハードウェアであるクライアントがアク
セスすることを要することを意味する。
ｂ構成要件Ｂ
()同(ｱ)ｂ()は否認する。aa
構成要件Ｂは，本件発明が全体として機能するために最低限必要なデータ送信行
為を規定しているにすぎず，データ送信方法の具体的態様まで限定的に規定する必
要はない。
()同(ｱ)ｂ()は否認する。bb
クライアントのウェブブラウザのアドレスバーへ記述子が入力され，ＤＮＳサー
バーに送信されるような場合に，クライアントにおいて記述子を認識させて直接
ディレクトリサーバーに送信させるようにするか，ＤＮＳにおいて記述子を認識さ
せた上でディレクトリサーバーに送信させるようにするか，それともＤＮＳ兼ディ
レクトリサーバーにおいて記述子を認識させて処理するようにするかは，本件発明
，。を具体的に実施するに当たり当業者が適宜選択すれば足りる設計事項にすぎない
ｃ構成要件Ｃ
()同(ｱ)ｃ()は否認する。aa
本件発明において「ディレクトリサーバー」は「記述子」を「翻訳データベー，，
スを用いてＵＲＬにマッピング」し(構成要件Ｃ)「ＲＥＤＩＲＥＣＴコマンド中，
の前記ＵＲＬを前記クライアントに返送する」(構成要件Ｄ)サーバーであることを
要するとともに，これで足りるものであり，ＤＮＳの機能を併用してもよく，不明
瞭という問題は存しない。
()同(ｱ)ｃ()は否認する。bb
構成要件Ｃは，本件発明が全体として機能するための最低限必要なデータ受信を
前提としているにすぎず，データ受信の具体的態様まで限定的に規定する必要はな
い。
(ｲ)まとめ
同(ｲ)は否認する。
イ争点５−２(新規性の欠如)
(被告の主張)
(ｱ)乙２４発明
論文集「」のうComputerCommunicationReviewVolume17,Number5SpecialIssue
ち「」(著。昭和６３AYellow-PagesServiceforaLocal-AreaNetworkLarryL.Peterson
年，ＡＣＭ(アメリカ計算機学会)出版発行。乙２４の１。以下「乙２４刊行物」，
といい，これに記載された発明を「乙２４発明」という。)には，次の構成が開示
されている。
Ａ’インターネットの至る所からクライアントがサービスを提供するローカル・
サーバーにアクセスできるようにする方法である。
Ｂ’クライアントは，サービス名およびサーバーが持つべき任意の属性を指定し
て，イエローページ・サービスにサーバーのアドレスを問い合わせる。
Ｃ’イエローページ・サーバーは，使用可能なサービスおよびサーバーに関する
情報のデータベースを備え，前記サービス名およびサーバーが持つべき任意の属性
をサーバーのアドレスにマッピングする。
Ｄ’イエローページ・サービスは，クライアントの要求を満たす１あるいは２以
上のサーバーのアドレスを返送する。
フラグシップ・ホストが，クライアントに対して，サーバー・ホストのアドレス
を返送するとともに，そのパケットをそのサーバー・ホストにリダイレクトする必
要があると知らせる。
Ｇ’クライアントが，ローカル・サーバーにアクセスする方法
(ｲ)「情報ページ」(構成要件Ａ及びＧ)
ａ乙２４発明には，アクセス先がサーバーシステムに備わる「情報ページ」
であることが明示されていない。
ｂ()しかし，乙２４発明において「ローカル・サーバーにアクセス」するa
とは，単にサーバーコンピュータにアクセスすることではなく，そのサーバーコン
ピュータが提供する情報サービスにアクセスすることを意味する。
()また，乙２８(「ＩｎｔｅｒｎｅｔＵｓｅｒ１９９５年２月号」１９b
，，９５年２月１日ソフトバンク株式会社発行)の１１８∼１１９頁図１∼図４には
ウェブ・ブラウザが情報ページを表示することが示されている。
ｃしたがって，乙２４発明の構成Ａ，Ｇ’と本件発明の構成要件Ａ，Ｇと’
は一致する。
(ｳ)「記述子」(構成要件Ｂ)
ａ「」とは「(情報処理)：記述子，デスクリプター(情報の類別・descriptor，
索引に用いる語句)」(リーダーズ英和辞典第２版)を意味する。記述子は，この
ように，索引のみならず情報の「類別」(類ごとの中身は通常複数)にも使用される
ものであるから，記述子という単語の意味を根拠として「記述子」＝「特定かつ，
唯一」の対象を識別するものと決定付けることはできない。
したがって，構成要件Ｂの「記述子」は，任意の記述子を意味し，ＵＲＬを除い
たり，目標情報ページを識別する特定かつ唯一のＵＲＬへとマッピングされるもの
に限定されるものとはいえない。
原告の主張は「翻訳データベース」の構築の問題と「記述子」という言葉の，，
定義の問題とを混同するものである。
ｂ乙２４発明のサービス名およびサーバーが持つべき任意の属性は記「」，「
述子」の内容を具体的に説明しているにすぎない。
ｃ仮に「目標情報ページを識別する特定かつ唯一のＵＲＬへとマッピング，
されるもの」という原告の限定解釈によったとしても，乙２４発明の「サービス名
およびサーバーが持つべき任意の属性」は「特定かつ唯一のＵＲＬ」に結び付く，
ものであることは，後記(ｵ)(「翻訳データベース」)のとおりである。
(ｴ)「ディレクトリサーバー」(構成要件Ｃ)
ａ()乙３０(ＣＣＩＴＴブルーブック第Ⅱ巻Ⅱ・６「勧告Ｆ．５００」平成a
３年９月４日，財団法人日本ＩＴＵ協会発行)には，以下の記載がある。
「Ｈ．イエローページ“分類された情報”を参照」(１９９頁)107。
「Ｈ．分類された情報ディレクトリにおいては，ディレクトリ情報群は“17
ホワイトページ“イエローページ”として現在知られている」(１８９頁)”，。
「Ｈ．ディレクトリディレクトリサービスを提供するための協同動作する24
開放型システムの集合」(１９０頁)。
()これらの記載からするとイエローページはディレクトリにおけるディb，，
レクトリ情報群として周知のものである。
ｂしたがって「イエローページ・サーバー」が「ディレクトリサーバー」，
であることは自明であり，相違点ではない。
(ｵ)「翻訳データベース」(構成要件Ｃ)
ａ()乙２５(ＣＣＩＴＴブルーブック第Ⅷ巻Ⅷ−６，８「勧告．５００」aX
平成３年１１月１日，財団法人日本ＩＴＵ協会発行)には，以下の記載がある。
「ディレクトリによって保持されている情報は，ディレクトリ情報ベース(ＤＩ
Ｂ)と総称され」(２４４頁４行∼５行)，
「ＤＩＢは，オブジェクトについての情報で構成されている。ＤＩＢは(ディレ
クトリ)エントリで，各エントリは一つのオブジェクトに関する情報の集合で構成
。，。される各エントリは属性で各属性は一つのタイプと一つ以上の値で構成される
あるエントリに存在する属性のタイプは，そのエントリが記述するオブジェクトの
クラスに依存する」(２４７頁下から４行∼最終行)。
「ＤＩＢのエントリは，木構造，つまり節点がエントリであるディレクトリ情報
木(ＤＩＴ)にまとめられる」(２４８頁１行)。
()一本件明細書において「ディレクトリサーバー」や「翻訳データベーb，
ス」の構成について格別の説明はない。
二したがって，１つの記述子に対し１つのＵＲＬをマッピングするにして
，，，もどのようなデータベースとして構築しどのような演算結果を出力させるかは
適宜選択可能な設計事項であり，原告主張のように，データベースの構造が１対１
に対応付けたものに限られると解する理由はない。
()したがって，構成要件Ｃにいう「ディレクトリサーバーに存在する「翻c」
訳データベース」とは，ディレクトリ情報ベースのことであり，ディレクトリ情報
木の構成を有するデータベースを意味する。
ｂ()乙２４発明の構成Ｃのイエローページ・サービスのイエローページ・a’
データベースは，ディレクトリ情報ベースと同じ構成を開示している。
()一乙２４刊行物の設計の問題点(訳文１１頁)にはイエローペーb5.2「」，
ジ・サービスの構成に関し「クライアントではなくサーバーにおいて選択アルゴ，
リズムを関与させる構成を有する旨が明記されており選択アルゴリズムはデー」，「
タベースと同じホスト上で実行し，相対的に小さい回答―サーバー・アドレス―が
返される」と述べられている。
二すなわち，乙２４刊行物には，イエローページ・サーバーに提供された
名前に対し返された値は，同サーバー上で稼動する選択アルゴリズムによって演算
され抽出選択されたものであること，選択アルゴリズムの設定次第で，１つのＵＲ
，。Ｌのみを抽出選択するようにすることは極めて容易であることが開示されている
三しかも，後記(ｷ)ｂ()のとおり，乙２４刊行物には，本件発明の「ＲＥb
ＤＩＲＥＣＴコマンド」と同じ「リダイレクト」が開示されているから，乙２４発
明において「リダイレクト」する場合，選択アルゴリズムを１つのＵＲＬのみを抽
出選択するように設定するなどすれば，当然１つのＵＲＬを選択することになる。
四したがって，乙２４発明(被告が引用するのは「リダイレクト」を使用，
する態様のものである。)は，特定かつ唯一のＵＲＬを選択することを開示してい
る。
ｃ仮に，本件発明の「翻訳データベース」が１対１の対応付けしか行わない
データベースであるとしても，それは，上記ディレクトリ情報ベースのディレクト
リ情報木の段階を１段階にしているということにすぎない。情報木の段階を複数段
階とすることまで想定した技術が，１段階とする技術を含んでいることは明らかで
ある。よって，乙２４発明におけるイエローページ・データベースは，乙２４発明
のものよりも進歩性を欠く態様の本件発明の「翻訳データベース」の技術も開示し
ている。
ｄしたがって，乙２４発明の構成Ｃ’は，本件発明の構成要件Ｃと一致する
か，本件発明の構成要件Ｃのように構成することは，当業者が容易に想到すること
ができたことである。
(ｶ)「ＵＲＬにマッピングする」(構成要件Ｃ)
ａ()乙２７(「ＵＮＩＸＭＡＧＡＺＩＮＥ１９９４年２月号」)の３３a
頁左欄「ＴＣＰ／ＩＰの基本機能とＤＮＳ」には「現在のインターネットを支え，
る基本技術のなかで，ＴＣＰ／ＩＰのアプリケーションとして一番大きな役割をも
つのはＤＮＳでしょう」との記載があり，同欄「ＤＮＳ」には「ＤＮＳは，階。，
層的ドメイン名とＩＰアドレスのマッピングのほかに電子メールに関する情報を管
理しています」との記載がある。。
乙２７の３４頁左欄「」には「…インターネット上のUniformResourceLocators，
分散したリソースに対して，統一的な名前の付け方を決めてユーザー・インター
フェイスを向上させる試みがあります。それがＵＲＬ()でUniformResourceLocators
す」との記載がある。。
()これらの記載からすると，インターネット上のリソース(情報ページ)のb
所在(アドレス)を統一的に特定するものがＵＲＬであることが，本件出願当時，当
業者に自明であったことが明らかであり「ＵＲＬ」と「アドレス」とはインター，
ネットを前提に論ずる上では，ほぼ同義であった。
ｂ()したがって，乙２４発明の構成Ｃ’の「サーバーのアドレスにマッピa
ングする」とは，構成要件Ｃの「ＵＲＬにマッピングする」ことを意味する。
()原告は，乙２４発明の構成Ｄ’は「フラグシップ・ホスト」の「アドb，
レス」を返すものにすぎない旨主張する。
しかし，原告の上記指摘部分は，目的の情報ページのアドレスを取得する前段階
，。，として一旦フラグシップ・ホストに接続される際の説明部分であるしたがって
この段階で目的の情報ページのアドレスが返されるわけでないのは当然である。そ
して，その後の「転送」又は「リダイレクト」により，マッピングにより得られた
情報が送られているものである。
ｃまた，後記(ｷ)の「ＲＥＤＩＲＥＣＴコマンド」の意義からすると，乙２
４発明の構成Ｄ’の「サーバーのアドレスを返送する」構成は，構成要件Ｄの「Ｕ
ＲＬを返送する」構成を開示している。
(ｷ)「ＲＥＤＩＲＥＣＴコマンド中の前記ＵＲＬを前記クライアントに返送す
る」(構成要件Ｄ)並びに構成要件Ｅ及びＦ
ａ乙２４発明の構成Ｄ’は，本件発明の「ＲＥＤＩＲＥＣＴコマンド」をク
ライアントに返送する構成を開示している。
ｂ()乙２６(「ＵＮＩＸＵＳＥＲ１９９４年１２月号」平成６年１２月a
１日，ソフトバンク株式会社発行)には，以下の記載がある。
Map一「●マッピング変換指定①∼
変換のルールを指定する。すなわち，ＵＲＬ中にというパス(で始まる/a/b/*/a/b/
任意のパス)が現れたとすると，それはに変換される。他に変換ルールが/X/Y/Z/*
あれば，続いてチェックされる」(１３４頁右欄)。
Redirect二「●他のＵＲＬに変換∼
に指定したパターンにマッチした場合は，指定したＵＲＬにリクエストRedirect
がそのままフォワードされる。サーバーが引っ越したような場合に用いる。ＵＲＬ
は『ホスト名』から書かなければならない」(１３５頁左欄)，http:///。
「例：」(１３５頁右欄)Redirect/a/b/*URL
()上記記載からすると「ＲＥＤＩＲＥＣＴコマンド」とは，クライアンb，
トから要求を受けたサーバーが該クライアントに対して発するもので，ＲＥＤＩＲ
ＥＣＴ中に指定されたあて先へ該要求を再指向させるよう指令するものであるこ
と，クライアントは，ＲＥＤＩＲＥＣＴ指令に従って，該サーバーからの返信をＲ
ＥＤＩＲＥＣＴ中のＵＲＬで指定された再指向先へとそのままフォワード(自動的
に転送)することは，本件特許の優先日の技術常識である。
()さらに，乙２４刊行物には「リダイレクト」と記載されているだけでなc，
く，それに続けて，その挙動が「接続指向プロトコル(例えばＴＣＰ)のケースでは
妥当である」(乙２４の２の１２頁下から７行)との記載がある。そして，インター
ネット及びそこで用いられるプロトコルであるＴＣＰ／ＩＰやＨＴＴＰは，１９７
０年代から８０年代に既に確立していた(乙２０の５０頁)。
ｃしたがって，乙２４発明の構成Ｄ’は，構成要件Ｄと一致する。
ｄ周知技術である「ＲＥＤＩＲＥＣＴ」の内容に照らせば，同構成Ｄ’は，
構成要件Ｅ及びＦの構成を記載しているに等しい事項である。
(ｸ)まとめ
，，，。そうすると乙２４発明と本件発明はすべての点で一致し相違点を有しない
，，，よって本件発明には新規性欠如の無効理由があり(特許法１２３条１項２号
平成１１年法律第４１号による改正前の特許法２９条１項３号)，原告は，その権
利を行使することができない。
(原告の主張)
(ｱ)乙２４発明
被告の主張(ｱ)は明らかに争わない。
(ｲ)「情報ページ」(構成要件Ａ及びＧ)
同(ｲ)のうち，ａは認め，ｂ()は明らかに争わず，ｂ()，ｃは否認する。ba
(ｳ)「記述子」(構成要件Ｂ)
ａ同(ｳ)ａは争う。
本件発明の「記述子」とは，電話番号・会社名・製品名等のＵＲＬとは異なる数
字あるいは言葉であり，かつ，当該「記述子」に対応し，目標情報ページを識別す
る特定かつ唯一のＵＲＬに結び付けられるものを意味する。
ｂ同(ｳ)ｂは否認する。
乙２４発明の「サービス名およびサーバーが持つべき任意の属性」とは，クラ
イアントがサーバーに対して求めるサービスの内容(印刷サービスプロセッササー，
ビス，トークサービス)やその質(属性，属性，属性等)といった条件speedresarch
を指定するものであり「任意の属性」から特定かつ唯一のサーバーへと対応付け，
られるものではない。
ｃ同(ｳ)ｃは否認する。
(ｴ)「ディレクトリサーバー」(構成要件Ｃ)
同(ｴ)は明らかに争わない。
(ｵ)「翻訳データベース」(構成要件Ｃ)
ａ同(ｵ)ａのうち，()は明らかに争わず，()及び()は争う。abc
ｂ同(ｵ)ｂのうち，()は明らかに争わず，()は否認する。ab
本件発明は，人間に理解しやすい「電話番号・会社名・製品名等のＵＲＬとは異
なる数字あるいは言葉」をインターネット上の規約である「ＵＲＬ」に１対１又は
多対１に対応付けして翻訳するものである。これに対し，乙２４発明は，指定条件
を満足するサーバーを検索するものであって，検索の結果，１つのサーバーが選択
される場合があるとしても，検索条件による絞り込みの結果にすぎず，本件発明の
翻訳データベースによる１対１の対応付けとは技術思想が全く異なるしたがっ「」。
て，１対１の対応付けとすることは，設計事項ではない。
ｃ同(ｵ)ｃは否認する。
ｄ同(ｵ)ｄは否認する。
(ｶ)「ＵＲＬにマッピングする」(構成要件Ｃ)
ａ同(ｶ)ａは明らかに争わない。
ｂ()同(ｶ)ｂ()は否認する。aa
()乙２４発明の構成Ｄ’は「フラグシップ・ホスト」の「アドレス」をb，
，’「。」返すものにすぎないから同構成Ｃのサーバーのアドレスにマッピングする
は「ＵＲＬにマッピングする」ことを意味するものとはいえない。
同構成Ｃ’及びＤ’における「サーバーのアドレス」は，ローカルネットワー
ク内において各サーバーがどの位置にあるかを示すものにすぎず，インターネット
上の規約である「ＵＲＬ」を開示も示唆もするものではない。
したがって，同構成Ｃ’は，構成要件Ｃの「ＵＲＬにマッピングする」構成を開
示していない。
ｃ同(ｶ)ｃは否認する。
(ｷ)「ＲＥＤＩＲＥＣＴコマンド中の前記ＵＲＬを前記クライアントに返送す
る」(構成要件Ｄ)並びに構成要件Ｅ及びＦ
ａ同(ｷ)ａは否認する。
ｂ()同(ｷ)ｂ()は認め，()及び()は否認する。aabc
()乙２６は，仮想的なディレクトリ指定をファイルシステムにおけるパスb
，「」，に変換するルールを規定したものであり被告の主張(ｷ)ｂ()二のはaRedirect
単に“”というパスをＵＲＬへと変換するものにすぎず，その結果「指定した/a/b
ＵＲＬにリクエストがそのままフォワード」されるものである。すなわち，乙２６
における「ＲＥＤＩＲＥＣＴ」は「ＲＥＤＩＲＥＣＴ」自体がＵＲＬを含むもの，
ではなく「ＵＲＬ」へとリクエストを送るものであり，クライアントをして自動，
的に情報要求させるものでもない。したがって，乙２６における「ＲＥＤＩＲＥＣ
Ｔ」は，本件発明の「ＲＥＤＩＲＥＣＴコマンド」とは全く異なる。
「ＲＥＤＩＲＥＣＴコマンド」の意義は，一義的に明確とはいえない(乙５)。
()乙２４発明には「リダイレクト」が，ローカルエリアネットワークではc，
なくインターネット環境の場合にどのように適用されるかそもそもインターネッ，，
ト環境の場合にも「リダイレクト」を適用して修正ができるかについて，全く開示
がない。
ｃ同(ｷ)ｃは否認する。
乙２４発明は「フラグシップ・ホスト」から「クライアント」に対して「リダ，
イレクトする必要があると知らせる」のみであり「リダイレクト」によりクライ，
アントがどのような動作を要求されるか，そもそも「リダイレクト」にＵＲＬが含
まれているのかについて，何ら開示していない。
ｄ同(ｷ)ｄは否認する。
(ｸ)まとめ
同(ｸ)は否認する。
本件発明は「記述子」と「ＵＲＬ」とを１対１(ないしは多対１)で対応付け，，
「」。さらにＲＥＤＩＲＥＣＴコマンドを利用したことをその本質的特徴としている
これに対し，乙２４発明は，一定条件を満たす不特定のサーバーを探す単なる条
件検索サービスであり，技術思想は全く異なる。
また，本件発明が前提とする「ウェブ」が創設されたのは平成３年(本件明細書
【０００５】)であるのに対し，乙２４発明を開示した刊行物(乙２４の１)が発行
されたのは昭和６３年であるから，両者は，インターネットについて前提とする技
術背景を全く異にする。
ウ争点５−３(進歩性の欠如)
(被告の主張)
(ｱ)主引用例(乙２４発明)
前記イ(被告の主張)(ｱ)と同じ。
(ｲ)一致点及び相違点の認定
ａ相違点１(「ＵＲＬにマッピングする」構成要件Ｃ)
乙２４発明の構成Ｃ’は「サーバーのアドレスにマッピングする」のに対し，本
件発明の構成要件Ｃは「ＵＲＬにマッピングする」点で異なる。
ｂ相違点２(「ＲＥＤＩＲＥＣＴコマンド中の前記ＵＲＬを前記クライアン
トに返送する」構成要件Ｄ)
同構成Ｄ’は，構成要件Ｄの「ＲＥＤＩＲＥＣＴコマンド中の前記ＵＲＬを…返
送する」構成を明示していない。
ｃ相違点３(構成要件Ｅ及びＦ)
乙２４発明は，本件発明の構成要件Ｅ及びＦの構成を明示していない。
ｄ一致点
乙２４発明と本件発明とは，その余の点において一致する。
ｅ相違点４(「情報ページ」構成要件Ａ及びＧ)
前記イ(被告の主張)(ｲ)のとおりであり，相違点ではない。
ｆ相違点５(「記述子」構成要件Ｂ)
前記イ(被告の主張)(ｳ)のとおりであり，相違点ではない。
ｇ相違点６(「翻訳データベース」構成要件Ｃ)
前記イ(被告の主張)(ｵ)のとおりであり，相違点ではない。
(ｳ)容易想到性
ａ相違点１(「ＵＲＬにマッピングする」)(構成要件Ｃ)
前記イ(被告の主張)(ｶ)のとおり。
ｂ相違点２(「ＲＥＤＩＲＥＣＴコマンド中の前記ＵＲＬを前記クライアン
トに返送する」構成要件Ｄ)及び相違点３(構成要件Ｅ及びＦ)
()副引用例(乙２６発明)a
前記イ(被告の主張)(ｷ)ｂのとおり。
()容易想到性b
一技術分野の同一性
本件発明と乙２４発明，乙２６発明は，いずれもインターネットを含む電気通信
ネットワークに関するものであり，技術分野が共通する。
二課題の自明性
本件発明と乙２４発明とは，インターネットを介して情報ページにアクセスする
際のネットワークユーザの便宜を図るものであり，解決すべき課題が共通である。
本件発明と乙２４発明とは，複雑な文字列によって識別されるインターネット上
のリソースに対して簡易な記述子の提供をもって到達できるとの共通した作用・効
果を有し，さらに，これを実現させるための翻訳データベース，マッピング，リダ
イレクトの各機能を用いる点で共通する。
三組合せの容易性
本件発明は，乙２４，乙２６に開示された技術事項を適宜選択し，あるいは単に
寄せ集めたにすぎず，または，これらの公知技術を組み合わせることについて，動
機付けとなり得る記載が多数認められる。
技術的な阻害要因は一切なく，公知技術と比較して，予想の範囲を超える有利な
効果も認められない。
したがって，本件発明は，出願時の技術水準に基づき当業者が容易に想到できた
ものである。
(ｴ)まとめ
よって，本件特許は，特許法２９条２項の規定に違反し，同法１２３条１項２号
の規定により無効とされるべきである。
(原告の主張)
(ｱ)主引用例(乙２４発明)
被告の主張(ｱ)は明らかに争わない。
(ｲ)一致点及び相違点の認定
ａ相違点１(「ＵＲＬにマッピングする」構成要件Ｃ)
被告の主張(ｲ)ａは認める。
ｂ相違点２(「ＲＥＤＩＲＥＣＴコマンド中の前記ＵＲＬを前記クライアン
トに返送する」構成要件Ｄ)
同(ｲ)ｂは認める。
ｃ相違点３(構成要件Ｅ及びＦ)
同(ｲ)ｃは認める。
ｄ一致点
同(ｲ)ｄ(一致点)は否認する。
乙２４発明と本件発明とは，次のｅないしｇの点においても相違する。
ｅ相違点４(「情報ページ」構成要件Ａ及びＧ)
乙２４発明には，アクセス先がサーバーシステムに備わる「情報ページ」である
ことが開示されていない。
ｆ相違点５(「記述子」構成要件Ｂ)
前記イ(原告の主張)(ｳ)ｂのとおり。
ｇ相違点６(「翻訳データベース」構成要件Ｃ)
前記イ(原告の主張)(ｵ)ｂのとおり。
(ｳ)容易想到性
ａ相違点１
前記イ(原告の主張)(ｶ)ｂのとおり
ｂ相違点２及び３
()副引用例(乙２６発明)a
前記イ(原告の主張)(ｷ)ｃのとおり。
()容易想到性b
一被告の主張(ｳ)ｂ()はいずれも否認する。b
二本件発明は「記述子」と「ＵＲＬ」とを１対１(又は多対１)で対応付，
け，さらに「ＲＥＤＩＲＥＣＴコマンド」を利用したことをその本質的特徴として
いるのに対して，乙２４発明は，一定条件を満たす不特定のサーバーを探す単なる
条件検索サービスであり，技術思想は全く異なる。
乙２４発明が，検索条件による絞り込みの結果，たまたま条件を満たすサーバー
が１件になった場合と，記述子に対応するＵＲＬがそもそも特定の１つに定められ
ており，検索条件や絞り込みという概念を入れる余地がない本件発明とは異なる。
(ｴ)まとめ
同(ｴ)は争う。
()争点６(訂正による無効理由の解消の存否)6
ア争点６−１(訂正要件及び充足)
(原告の主張)
(ｱ)本件訂正(前提事実()エ(ｲ))は，特許請求の範囲の減縮又は明りょうでな2
い記載の釈明であり，かつ，他の訂正要件も満たしている。
(ｲ)被告方法は，本件訂正発明の構成要件を充足する。
(被告の主張)
(ｱ)原告の主張(ｱ)は明らかに争わない。
(ｲ)同(ｲ)は否認する。
イ争点６−２(進歩性欠如等)
(被告の主張)
本件訂正発明には，前記()アないしウの各被告の主張のとおり，依然として開5
示義務違反，新規性の欠如及び進歩性の欠如の無効理由が存在するから，無効理由
は解消されていない。
(原告の主張)
被告の主張は否認する。
()争点７(主体性)7
(原告の主張)
ア道具理論
(ｱ)まとめ
被告は，クライアントＰＣを使用するユーザーの行為を道具として利用することに
より，被告方法を使用し，本件発明を直接侵害しているから，差止め及び除却請求の
相手方となる。
(ｲ)外形的・即物的行為の管理
ａ被告は，前提事実()アのとおり，被告サービスを開設し，そのトライアル登3
録サービス「」を開始し，その優先登録サービス「」をTestOperationSunriseOperation
開始した。さらに，被告は，登録された日本語インターネットアドレスを管理する(甲
４の４の１)などし，被告サービスを提供している。
ｂ被告は，被告サービスが実現されるために用いられる「サーバー」及びNLIA
「」を所有ないし管理している。NLIANameServer
ｃ被告は，利用者に対して被告サービス利用の積極的勧誘行為を行っている。
ｄ被告は，被告サービスの使用方法について，自身が開設したウェブサイト上
で詳細な解説を行っており，利用者はかかる解説を参照して被告サービスを利用して
いる。
ｅウェブページへの接続は，最終的に「サーバー」からクライアントＰＣNLIA
に返送される「ＲＥＤＩＲＥＣＴコマンド」に含まれたＵＲＬによって自動的に行わ
れる。
ｆ上記ａないしｅの事実からすると，被告は，侵害行為の前提となる外形的・
即物的行為を管理し得る立場にある。
(ｳ)利益の帰属
被告は，日本語インターネットアドレス()登録を受け付け，キーワード登録JAddress
を行った者から登録料収入を得ており(甲１０)，被告サービスの運営を通じて得られ
る営業上の利益を享受しようとしている。
イ共同侵害行為
(ｱ)まとめ
仮に，アが認められないとしても，被告は，クライアントＰＣを使用するユーザー
と共同して，被告方法を使用し，本件発明を直接侵害しているから，差止め及び除却
請求の相手方となる。
(ｲ)客観的要件
NLIANLIAユーザーのクライアントＰＣと被告が所有・管理するサーバー及び，「」「
」との共同行為によって，本件発明が実施されている。NameServer
したがって，客観的要件を充足する。
(ｳ)主観的要件
ａ被告の認識
被告は，ユーザーのクライアントＰＣに対する日本語インターネットアドレスの入
力・送信を契機として被告方法が実施されることを認識し，クライアントＰＣのユー
ザーに対して，積極的に被告サービスの利用を促している。
したがって，被告には，クライアントＰＣの動作を利用する意思が存在する。
ｂユーザーの認識
()ユーザー側のクライアントＰＣは，通常のコンピュータ機器にすぎず，現代a
社会においてはだれもが備えているものであり，また，かかるコンピュータ機器がイ
ンターネットに接続されていることも高度情報化した現代社会において今や当然の状
況である。
したがって，インターネットに接続されたユーザー側のクライアントＰＣは，本件
，。発明が前提とする一般的な環境にすぎずユーザー側の主観的共同意思は不要である
()仮に，ユーザー側において主観的共同意思が必要であると解したとしても，b
ユーザーはクライアントＰＣに日本語インターネットアドレスを入力・送信するだけ
で，目的とする情報ページにクライアントＰＣが導かれることを充分認識しており，
ユーザーには実施内容と結果の認識程度のシステムを利用する共同行為の認識が存在
する。
(ｴ)「業として」の要件
被告において，自ら被告方法の一部を実施しつつ，クライアントＰＣのユーザーに
よる被告方法の残部の実施を利用して自己の一部実施を補充しており，これを業とし
て行っている以上，仮にクライアントＰＣのユーザーに個人ユーザーが含まれていた
としても，少なくとも被告について共同直接侵害が成立する。
ウ間接侵害
(ｱ)まとめ
少なくとも，被告は，被告方法を使用して，本件発明を間接侵害しているから，差
止め及び除却請求の相手方となる。
(ｲ)１０１条４号
ａ被告方法の構成Ｄ’の「サーバー』が，当該ＵＲＬを，ＲＥＤＩＲＥ『NLIA
ＣＴコマンドを利用して，クライアントＰＣに送信する段階」におけるＵＲＬを含ん
だＲＥＤＩＲＥＣＴコマンドは，本件発明に係る「方法の使用にのみ用いる物」であ
り，かかる「ＲＥＤＩＲＥＣＴコマンド」をユーザーのクライアントＰＣに提供する
被告の行為は「方法の使用にのみ用いる物」を「譲渡」する行為に該当し，特許法１，
０１条４号に定める間接侵害行為に該当する。
ｂ「ＵＲＬを含んだＲＥＤＩＲＥＣＴコマンド」という無体物の送信であって
も「物」の「譲渡」に該当する。，
ｃＵＲＬを含むＲＥＤＩＲＥＣＴコマンドは，被告方法の使用以外の用途に用
いられている事実は存在せず，ユーザーにおける被告方法の実施にのみ用いられてい
る。
(ｳ)１０１条５号
ａＵＲＬを含んだＲＥＤＩＲＥＣＴコマンドは特許法１０１条５号にいう発，「
明による課題の解決に不可欠なもの」に該当する。
ｂ被告は，遅くとも原告から警告状(甲１３)を受領した時点で「発明が特許発，
明であること及びその物がその発明の実施に用いられること」を確定的に知った。
(被告の主張)
ア道具理論
(ｱ)まとめ
原告の主張ア(ｱ)は否認する。
被告方法を使用しているのは，パソコンのユーザーであって，被告ではない。
(ｲ)外形的・即物的行為の管理
同ア(ｲ)は否認する。
(ｳ)利益の帰属
同ア(ｳ)は否認する。
イ共同侵害行為
同イは否認する。
ウ間接侵害
同ウは否認する。
()争点８(損害の発生及び額)8
(原告の主張)
ア特許法１０２条２項の損害
(ｱ)売上げ
，「」ａ被告は平成１８年９月５日から日本語インターネットアドレスJAddress
の優先登録サービス「」を開始しただけでなく(前提事実()ア)，同年SunriseOperation3
１１月からその商用登録サービス「」を開始し，同年１２月末日CommercialOperation
までに，少なくとも４０００件の登録を得た。
ｂ被告は，登録したサイト運営者から，登録料金として，１件当たり少なくと
も３万１５００円を受領し，少なくとも１億２６００万円の売上げを上げた。
３万１５００円×４０００件＝１億２６００万円
(ｲ)利益率
被告サービスにおける利益率は，少なくとも７０％を下らない。
(ｳ)まとめ
よって，被告は，少なくとも８８２０万円の利益を得たものであり，原告は，特許
法１０２条２項に基づき，同額の損害を被ったものと推定される。
１億２６００万円×７０％＝８８２０万円
イ弁護士費用相当額の損害
(ｱ)本件事案の性質・内容から，原告は弁護士である原告代理人らに本件訴訟提
起を依頼せざるを得なかった。
(ｲ)その結果，原告は原告代理人らに弁護士費用の支払を約し，少なくとも３５
０万円の弁護士費用相当額の損害を被った。
ウまとめ
よって，原告は，被告に対し，民法７０９条，特許法１０２条２項に基づき，９１
７０万円及びこれに対する平成１９年２月１５日から支払済みまで民法所定の年５分
の割合による遅延損害金の支払を求める。
(被告の主張)
ア特許法１０２条２項の損害
(ｱ)売上げ
原告の主張ア(ｱ)は否認する。
被告は，当初，平成１８年１１月から商用登録サービスを開始する予定であった
が，その開始を延期し，現在に至っており，登録料等一切の利益を得ていない。
(ｲ)利益率
同ア(ｲ)は否認する。
(ｳ)まとめ
同ア(ｳ)は否認する。
イ弁護士費用相当額の損害
同イは否認する。
ウまとめ
同ウは否認する。
第３当裁判所の判断
１争点５−３(進歩性の欠如)について
()乙２４発明1
ア乙２４の１及び２によれば，乙２４刊行物(昭和６３年にＡＣＭ(アメリカ
COMPUTERCOMMUNICATIONREVIEW計算機学会)出版から発行された論文集「
Volume17,Number5SpecialIssuePart8.RESOURCESHARINGIN」のうち「，
DISTRIBUTEDSYSTEMSLarryL.PetersonAYellow-PagesService」「の中の執筆の論文
」)には，以下の記載があることが認められる(一部は，当foraLocal-AreaNetwork
事者間に争いがない。)。
Inadditiontodescribingtheimplementationoftheyellow-pagesservicewithina(ｱ)「
local-areanetwork,weshowhowtheservicecanbeintegratedwiththeavailableinternet
communicationprotocolstoenableclientsfromthroughouttheinternettoaccesslocal
」(訳文「イエローページ・サービスのローカルエリア・ネットワーク内でservers.
の実施の説明だけでなく，インターネットの至る所からクライアントがローカル・
サーバーにアクセスできるようにするために，本サービスが，使用可能なインター
ネット通信プロトコルとどのように統合できるかを示す」)(２３５頁左欄７行∼。
１２行)
Thispaperdescribesayellow-pagesservicethatmapsthenameofaserviceinto(ｲ)「
」(訳文「この論文では，サービスtheaddressofaserverwillingtoprovidetheservice
を提供しようとするサーバーのアドレスにサービス名をマッピングするイエロー
ページ・サービスについて説明する」)(２３５頁左欄１４行∼１６行)。
Aclientthatwishestoengageaservicequeriestheyellow-pagesserviceforthe(ｳ)「
addressofaserver,specifyingthenameoftheserviceandanyattributestheservershould
possess.Theyellow-pagesservicereturnstheaddressofoneormoreserversthatsatisfythe
」(訳文「サービスを受けたいクライアントは，サービス名およclient'srequirements.
びサーバーが持つべき任意の属性を指定して，イエローページ・サービスにサー
バーのアドレスを問い合わせる。イエローページ・サービスは，クライアントの要
求を満たす１あるいは２以上のサーバーのアドレスを返送する」)(２３５頁左欄。
下から２行∼右欄４行)
Clientsconnecttotheflagshiphostasthoughtheserverisavailableonthathost.(ｴ)「
Aforwardingmechanismrunningontheflagshiphostthen"patches"theclientthroughtoan
」(訳文「クライアントは，フラグシップ・ホスactualserverthatprovidestheservice.
，。，ト上でサーバーを使用できるかのようにフラグシップ・ホストに接続する次に
フラグシップ・ホスト上で動作する転送メカニズムが，実際にそのサービスを提供
するサーバーにクライアントを接続させる」)(２３５頁右欄１０行∼１４行)。
Asetofserversimplementtheyellow-pagesservice.Eachservermaintainsa(ｵ)「
」(訳文「サーバーのセッdatabaseofinformationabouttheavailableservicesandservers.
トが，イエローページ・サービスを実施する。各サーバーは，使用可能なサービス
及びサーバーに関する情報のデータベースを維持する」)(２３５頁右欄下から７。
行∼５行)
Anattributeisasyntacticobjectthatdenotesapropertyorcharacteristicofa(ｶ)「
」(訳文「属性は，サーバーのプロパティまたは特徴を示す統語的要素であserver.
る」)(２３６頁左欄２行∼３行)。
Clientssubmitasetofattributeswhenqueryingtheyellow-pagesforaserverthat「
」(訳文「クライアントは，ある特定のサービスを提供すprovidesaparticularservice.
るサーバーについてイエローページに問い合わせる際，属性のセットを送信す
る」)(２３６頁左欄１１行∼１３行)。
Associatedwitheachyellow-pagesserverisadatabaseofinformationaboutthe(ｷ)「
servicesavailableinthesystem.Thedatabasecontainsbindingsofeachservicetoasetof
」(訳文「各イエローページ・サーバーには，システムserversthatprovidetheservice.
内で使用できるサービスについての情報のデータベースが関連付けられる。データ
ベースには，各サービスとそのサービスを提供するサーバーのセットとを結び付け
たものが格納される」)(２３６頁左欄下から４行∼最終行)。
Clientsquerytheyellow-pagesservicefortheaddressofoneormoreserversthat(ｸ)「
(訳文クライアントは以下のオペレーショprovideagivenservicewiththeoperation」「，
ンによって，イエローページ・サービスに対し，ある所定のサービスを提供する１
あるいは２以上のサーバーのアドレスを問い合わせる」)(２３７頁左欄２行∼４。
行)
Asanotherexample,supposetheclientwishestoretrievetheaddressofthe(ｹ)「
printerbasedonitslocation:e.g.,"theprinterinRick'soffice".Inthiscase,theclientinvokes
thelookupoperationwiththemandatoryattributeloc=rick.Anynumberofoptional()
」(訳文attributesareignoredbecausethemandatoryattributeloc=rickselectsasingleserver.
「別の例として，クライアントが場所，例えば「のオフィスのプリンタ」なRick
どに基づいてプリンタのアドレスを取得したいとする。この場合，クライアントは
loc=ricklookuploc=rick必須属性をとして()オペレーションを要求する。必須属性
によって唯一のサーバーが選択されるので，オプション属性がいくつあってもすべ
て無視される」)(２３８頁右欄２０行∼２６行)。
Thissectiondescribeshowtheyellow-pagesserviceisintegratedwiththeinternet(ｺ)「
transportprotocols,therbyallowingclientsfromthroughouttheinternettoaccessservers
」(訳文「このセクションでは，イエローページ・サーwithinanautonomoussystem.
ビスがどのようにしてインターネット・トランスポート・プロトコルに統合され，
それによって，クライアントがインターネットの至る所から自立システム内のサー
バーにアクセスできるのかを説明する。)(２３９頁右欄１５行∼１８行)
「」(訳文「ローカルAsinglehostinthelocalsystemisdesignatedastheflagshiphost;
システム内の１つのホストが，フラグシップ・ホストとして指定される。)(２３９
頁右欄２３行∼２４行)
ThesystemadvertizestheflagshipasofferingasetofservicestoInternetclientsby「
registeringasetofresourcerecordspotentiallyoneforeachservicewiththedomain−−
」(訳文「システムは，１つのセットのリソース・レコード(リソーnamingsystem.
ス・レコードは，潜在的には各サービスにつき１つである。)をドメイン名システ
ムに登録することによって，サービスのセットをインターネット・クライアントに
提供するものとして，フラグシップを広告する」(２３９頁右欄２５行∼２９行。。
注は省略)
Aclientconsultsthedomainnameservertolearntheaddressofahostatthe(ｻ)「
systemthatoffersaparticularserviceandtheaddressoftheflagshiphostisreturned.The
clientthencontactstheserverbysendingoneormorepacketsaddressedtothewell-known
portontheflagshiphost.Theflagshiphost,inturn,forwardsthepacketstoaserverwithinthe
system.Thus,theforwardingmechanismisanalogoustothestrategyofaccessingaserverat
well-knownport:Theflagshipservesasthe"well-knownhost"forthesystem.
ConsiderhowtheforwardingmechanismisimplementedwithinTCPinmoredetail.The
TCPmodulerunningontheflagshiphostismodifiedtoincludetheforwardingmechanism.
Associatedwiththeforwardingmechanismisatablethatbindswell-knownportstothe
」(訳文「クライアントは，システムにおいて特定のサービスをaddressesofservers.
提供するホストのアドレスを取得するためにドメイン名サーバーに問い合わせ，フ
ラグシップ・ホストのアドレスが返される。その後，クライアントは，フラグシッ
プ・ホスト上のウェルノウンポートあてに１あるいは２以上のパケットを送信する
ことによってサーバーに接続するするとフラグシップ・ホストはそのパケッ，。，，
トをシステム内のサーバーに転送する。このように，転送メカニズムは，ウェルノ
。，ウンポートにおいてサーバーにアクセスする戦略と類似しているフラグシップは
システムに対して『ウェルノウンホスト』の役割を果たす。，
転送メカニズムがＴＣＰ内でどのように実施されるかを更に詳細に検討する。フ
ラグシップ・ホスト上で動作するＴＣＰモジュールが，転送メカニズムを含むよう
に変更される。転送メカニズムには，ウェルノウンポートをサーバーのアドレスに
結び付けるテーブルが関連付けられる」)(２３９頁右欄３１行∼２４０頁左欄１。
４行)
WhenapacketarrivesattheTCPmoduleaddressedforsomeport,theforwarding(ｼ)「
mechanismisconsultedtoseeifforwardingistotakeplaceforthatport;i.e.,ifthereisan
entryinthetable.Ifthepacketisfromanewclient,theforwardserverrandomlyselectsone
oftheavailableserversandforwardsthepacketontoit.Thatis,theforwardingmechanism
」(訳文「あsetsthepacket'sdestinationaddresstotheserver'saddressandresendspacket.
るポートあてのパケットがＴＣＰモジュールに到着すると，そのポートへの転送が
行われるべきか，すなわち，テーブルにエントリが存在するかについて，転送メカ
ニズムが問い合わせられる。そのパケットが新しいクライアントからである場合，
フォワード・サーバーがランダムに入手可能なサーバーの１つを選択し，パケット
をそのサーバーに転送する。すなわち，転送メカニズムは，パケットの宛先のアド
レスをそのサーバーのアドレスに設定し，パケットを再送信する」)(２４０頁左。
欄１８行∼２５行)
Subsequentpacketssentonthesameconnectionareforwardedtothesame(ｽ)「
」(訳文「同一の接続上で送信される後続のパケットは，同一のサーバーにserver.
転送される」)(２４０頁左欄２９行∼３０行)。
byengagingtheselectionalgorithmattheserverratherthantheclient,the(ｾ)「
yellow-pagesserviceeffectivelymovesthe"functiontothedata"ratherthanthe"datatothe
function".Thatis,theselectionalgorithmexecutesonthesamehostasthedatabaseanda
−−（訳文「クライアントではなrelativelysmallansweraserveraddressisreturned.」
くサーバーにおいて選択アルゴリズムを関与させることにより，イエローページ・
サービスは「機能にデータ」よりむしろ「データに機能」を効果的に移動する。す
なわち，選択アルゴリズムはデータベースと同じホスト上で実行し，相対的に小さ
い回答−サーバー・アドレス−が返される（２４１頁左欄下から１３行∼８行）。）
Theforwardingmechanismactsasanintermediarybetweentheclientandserver.(ｿ)「
Thishastheadvantageofnotrequiringanychangestothetransportprotocolbecausethe
clientisshieldedfromtheindirection.Incontrast,theprotocolcouldbemodifiedsuchthatthe
flagshiphostinformstheclientthatitshouldredirectitspacketstotheserverhost.Whilethis
()」(訳文「転送mightbereasonableinthecaseofaconnectionorientedprotocole.g.,TCP
メカニズムはクライアントとサーバー間の仲介人の機能を果たす。これは，クライ
アントが間接参照から守られているため，トランスポートプロトコルに対してあら
ゆる変更を要求しないという優位点を有する。対照的に，プロトコルは，フラッグ
シップ・ホストがクライアントに対して，そのパケットをサーバー・ホストにリダ
イレクトする必要があると知らせるように修正できるであろう。これは接続指向プ
ロトコル(例えばＴＣＰ)のケースでは妥当である可能性があるが」)(２４１頁右，
欄下から１２行∼５行)
イ上記各記載によれば，乙２４刊行物(乙２４の１)には，以下の構成(乙２４
発明)が開示されている(一部は，当事者間に争いがない。)。
Ａ’インターネットの至る所からクライアントがローカル・サーバーにアクセス
できるようにする方法である(２３５頁左欄９行∼１２行)。
フラグシップ・ホスト上で動作する転送メカニズム()が，実forwardingmechanism
際にそのサービスを提供するサーバーにクライアントを接続させる()(２３５patch
頁右欄１０行∼１４行)。
Ｂ’サービスを受けたいクライアントは，サービス名およびサーバーが持つべき
任意の属性を指定して，イエローページ・サービスにサーバーのアドレスを問い合
わせる(２３５頁左欄下から２行∼右欄２行)。
クライアントは，システムにおいて特定のサービスを提供するホストのアドレス
を取得するためにドメイン名サーバーに問い合わせ，フラグシップ・ホストのアド
レスが返される(２３９頁右欄３１行∼２４０頁左欄２行)。
イエローページ・サーバーに提供されたサービス名等に対し返されたアドレス
は，同サーバー上で稼動する選択アルゴリズムによって演算され抽出選択されたも
のであり，選択アルゴリズムの設定次第で，１つのサーバーのアドレスのみを抽出
選択するようにできる(２４１頁左欄下から１３行∼８行，弁論の全趣旨)。
’，。，Ｃサーバーのセットがイエローページ・サービスを実施する各サーバーは
使用可能なサービスおよびサーバーに関する情報のデータベースを維持する(２３
５頁右欄下から７行∼５行)。
各イエローページ・サーバーには，システム内で使用できるサービスについての
情報のデータベースが関連付けられる。データベースには，各サービスとそのサー
ビスを提供するサーバーのセットとを結び付けたものが格納される」)(２３６頁。
左欄下から４行∼最終行)
イエローページ・サービスは，サービス名をサーバーのアドレスにマッピングす
る(２３５頁左欄１４行∼１６行)。
Ｄ’イエローページ・サービスは，クライアントの要求を満たす１あるいは２以
上のサーバーのアドレスを返送する(２３５頁右欄２行∼４行)。
クライアントは，ローカルシステム内のフラグシップ・ホスト上のウェルノウン
ポートあてに１あるいは２以上のパケットを送信する。
フラグシップ・ホストは，そのパケットをシステム内のサーバーに転送する(以
上，２４０頁左欄２行∼５行)。
転送メカニズムは，パケットの宛先のアドレスをそのサーバーのアドレスに設定
し，パケットを再送信する(２４０頁左欄２３行∼２５行)。
プロトコルは，フラグシップ・ホストがクライアントに対して，そのパケットを
サーバー・ホストにリダイレクトする必要があると知らせるように修正できる(２
４１頁右欄下から８行∼６行)。
Ｇ’クライアントが，ローカル・サーバーを使用できるように，フラグシップ・
ホストに接続する方法
()一致点と相違点2
ア一致点
乙２４発明と本件発明とを対比すると，両者は，下記イないしキの点で一応相違
するが，その余の点で一致すると認められる。
イ相違点１(「ＵＲＬにマッピングする」構成要件Ｃ)
本件発明は「翻訳データベースを用いてＵＲＬにマッピングする」(構成要件Ｃ)
ものであるが，乙２４発明の構成Ｃ’は「サービス名を(サービスを提供しよう，
とする)サーバーのアドレスにマッピングする」ものであり「サーバーのアドレ，
ス」が「ＵＲＬ」に対応するか否かが明らかではない。
ウ相違点２(「ＲＥＤＩＲＥＣＴコマンド中の前記ＵＲＬを前記クライアント
に返送する」構成要件Ｄ)
本件発明は「ＲＥＤＩＲＥＣＴコマンド中の前記ＵＲＬを前記クライアントに返
送する」(構成要件Ｄ)ものであるが，乙２４発明は「フラグシップ・ホストが，，
クライアントに対して，サーバー・ホストのアドレスを返送するとともに，そのパ
」，ケットをサーバー・ホストにリダイレクトする必要があると知らせるものであり
①「サーバー・ホストのアドレス」が「ＵＲＬ」に対応するか否かが明らかではな
く(上記イの相違点１と同じ。)，②「リダイレクトする必要があると知らせる」こ
とが，本件発明の「ＲＥＤＩＲＥＣＴコマンド」に相当するか否かが明らかではな
い。
エ相違点３(構成要件Ｅ及びＦ)
乙２４発明は，本件発明の構成要件Ｅ(「前記クライアントに前記ＵＲＬを用い
て情報を要求させ」)，構成要件Ｆ(「前記ＵＲＬにより識別されたページを前記ク
ライアント側で表示する」)段階を有するか否かが明らかではない。
オ相違点４(「情報ページ」構成要件Ａ及びＧ)
乙２４発明には，アクセス先がサーバーシステムに備わる「情報ページ」である
ことが明示されていない。
カ相違点５(「記述子」構成要件Ｂ)
’「」，乙２４発明の構成Ｂのサービス名およびサーバーが持つべき任意の属性が
本件発明の構成要件Ｂの「記述子」に相当するか明らかではない。
キ相違点６(「翻訳データベース」構成要件Ｃ)
乙２４発明の構成Ｃ’の「データベース」が本件発明の構成要件Ｃの「翻訳デー
タベース」であるか否かが明らかではない。
なお原告は翻訳データベースの点は争うが乙２４発明のイエローペー，，「」，「
ジ・サーバー」が構成要件Ｃ及びＤの「ディレクトリサーバー」に相当することに
ついては争わないものと認められるから，この点は自白したものとみなす。
()相違点についての判断3
ア相違点１(「ＵＲＬにマッピングする」構成要件Ｃ)
(ｱ)ａ乙２８及び弁論の全趣旨によれば，乙２８刊行物(「Ｉｎｔｅｒｎｅｔ
Ｕｓｅｒ１９９５年２月号１９９５年２月１日ソフトバンク株式会社発行)」，
は，インターネット関連の一般の情報誌であるが，その「ＷＷＷサーバーで情報を
発信するＨＴＭＬ攻略法」との項目の記事中に，以下の記載があることが認めら
れる。
「インターネットにはさまざまな資源があり，従来，それらはやなどftptelnet
のプログラムを使って利用されてきた。やなどのプログラムを使った資源ftptelnet
の利用法には，次のような２つの問題がある。
①利用する資源に応じてさまざまなプログラムの利用法を習得する必要があるこ
と
②それぞれの資源どうしの間に関連付けがないこと
，。ＷＷＷ()は上記の２つの問題を解決するためのアイデアであるWorldWideWeb
httpつまり，ＷＷＷではＵＲＬという形式でインターネット上の資源を指示し，
というプロトコルとというマークアップ言語によってインターネット上のHTML
資源を有機的につなぎ合わせ，有効に利用することができるのである」(１１７。
頁右欄３行∼１５行。注は省略)
()はＷＷＷの中核となるプロトコルである(１「，。」httpHyperTextTransferProtocol
１７頁右欄下から６行∼５行)
「ＵＲＬはインターネット上の資源を統一的に示す方法で，ＷＷＷブラウザを使
，。」うときやＨＴＭＬ形式の文章でインターネット上の資源を示すときに使われる
(１１８頁左欄１６行∼１８行)
「ホスト名はドメイン形式で記述する
ＵＲＬの書き方の中で，ホスト名とはＷＷＷサービスを行っているホストの名前
のことである」(１１８頁右欄１２行∼１４行)。
「①ＷＷＷブラウザは，ホスト名をＩＰアドレスに変換してから利用する
②インターネットでは，この変換にネーム・サーバーを使う
③ネーム・サーバーに問い合わせるときにはドメイン名がなくてはならない(１，」
１９頁左欄３行∼７行)
ｂこれらの記載によれば，インターネット上のサービスとしてＨＴＴＰによ
るＷＷＷサービスがあり，このＷＷＷサービスを行っているホスト(サーバー)にア
クセスするには，ドメイン名を含むＵＲＬを用いることは，本件出願当時，周知の
技術であったと認められる。
(ｲ)したがって，インターネット上でサービスを提供する乙２４発明において
上記ＷＷＷサービスを採用することは，当業者が容易になし得たことであり，ＷＷ
Ｗサービスを採用した場合，サーバーのアドレスとして「ＵＲＬ」を選択するもの
にすることも，当業者が容易になし得たことと認められる。
イ相違点４(「情報ページ」構成要件Ａ及びＧ)
(ｱ)乙２４発明においてローカル・サーバーにアクセスするとは単にサー「」，
バーコンピュータにアクセスすることではなく，そのサーバーコンピュータが提供
する情報サービスにアクセスすることを意味すること，並びに乙２８(「Ｉｎｔｅ
ｒｎｅｔＵｓｅｒ１９９５年２月号」１９９５年２月１日，ソフトバンク株式
会社発行)の１１８∼１１９頁図１∼図４には，ウェブ・ブラウザが情報ページを
表示することが示されていることは，原告において明らかに争わないから，これを
自白したものとみなす。
(ｲ)したがって，インターネット上のサーバーシステムとしてＷＷＷサービス
を採用した乙２４発明を「情報ページ」を表示するように構成することは，当業者
が容易に想到し得たことであると認められる。
ウ相違点２(「ＲＥＤＩＲＥＣＴコマンド中の前記ＵＲＬを前記クライアント
に返送する」構成要件Ｄ)及び相違点３(構成要件Ｅ及びＦ)
(ｱ)本件明細書に「ＲＥＤＩＲＥＣＴコマンド」に関して，以下の記載があ，
ることは，当事者間に争いがない。
「メッセージ２では，ディレクトリサーバー６０２がＲＥＤＩＲＥＣＴをクライ
アント６０１に送信し，これには，データベース６０４から演算されたＮＵＭＢＥ
Ｒに対する目標ＵＲＬが記述されている。クライアントブラウザ６０１は続いて自
動的にメッセージ３を送信し，このＵＲＬのコンテンツをＧＥＴする。商業者サー
バー６０３はメッセージ４におけるこの情報を返送する」(【００４５】)。
この記載によれば，本件発明の「ＲＥＤＩＲＥＣＴコマンド」とは，サーバーか
らクライアントに送信され，クライアントが前記サーバーとは別のサーバーへ自動
的に送信する命令であると認められる。
，’「」，(ｲ)前記()イのとおり乙２４発明の構成Ｄにおけるリダイレクトは1
「フラグシップ・ホストがクライアントに対して，そのパケットをサーバー・ホス
トにリダイレクトする必要があると知らせる」ものである。
，「」(ｳ)ａ乙２６によれば乙２６(ＵＮＩＸＵＳＥＲ１９９４年１２月号
平成６年１２月１日，ソフトバンク株式会社発行)には「新インターネット構築，
術第１６回その４ＷＷＷサーバー用データ記述言語ＨＴＭWorldWideWeb
Ｌ応用編「今回は，ＷＷＷサーバーによる情報提供の応用的な仕掛けについて」
解説する」(１２９頁)として，次の記載があることが認められる。。
「…スクリプトからの出力として，ドキュメントの内容自身を出力する以CGI
Location外に別のドキュメントの位置を返すということもできるこのためには，。，
：ヘッダーを用いて，
：目的のドキュメントのＵＲＬLocation
という形式の情報(ヘッダー)を返せばよい。これによって，既存のドキュメントを
ダイナミックに選択して表示できる」(１３０頁左欄１４行∼２０行)。
また，１２９頁の図１には，サーバーとクライアントがＨＴＴＰにおいて交互に
送信する旨の記載がある。
ｂこれらの記載によると，ＨＴＴＰにおいてＵＲＬを含む「ＲＥＤＩＲＥＣ
Ｔコマンド」をクライアントに送信してクライアントにおいて自動的に情報ページ
を表示することは，本件出願当時，周知の技術であったと認められる。なお，被告
Redirectは，同号証１３５頁左欄下から１０行以下の「●他のＵＲＬに変換∼
に指定したパターンにマッチした場合は，指定したＵＲＬにリクエストがRedirect
そのままフォワードされる。サーバーが引っ越したような場合に用いる。ＵＲＬは
『ホスト名』から書かなければならない」との記載を指摘するが，上記記http:///。
載中の動作は，の動作を規定するの一部であり，サーバー側で実行httpdhttpd.conf
されるものであって，クライアントに別のドキュメントの位置を返送するものでは
なく，本件発明の「ＲＥＤＩＲＥＣＴコマンド」とは異なるものと認められる。
したがって，ＨＴＴＰ上のものではない乙２４発明において，ＨＴＴＰによるＷ
ＷＷサービス(乙２８)を採用してサービスを提供する際に，プロトコルによる相互
接続性を保つため，乙２４発明の「リダイレクト」に代えて，乙２６に記載されて
いるＨＴＴＰにおけるリダイレクト機能に関する周知技術を適用することにより，
ＵＲＬを含むＲＥＤＩＲＥＣＴコマンドをクライアントに送信して，クライアント
において自動的に情報ページを表示させるようにすること(構成要件Ｄ，Ｅ及びＦ)
は，当業者が容易に想到し得たことと認められる。
ｃなお，乙２４発明において，ローカルエリア・ネットワーク内でイエロー
ページ・サービスを提供するイエローページ・サーバーとインターネット上でクラ
イアントと接続されて転送メカニズムを実現するフラグシップ・ホストは，同一の
ものとは記載されていない。しかし，コンピュータの汎用性と高能力化の進展にか
んがみると，両者を物理的に１つのサーバーで実現することは単なる設計的事項と
いうべきであり，インターネット上で動作可能なプロトコルであるＨＴＴＰを前提
とすれば，その具体的設計も当業者には自明のことであると認められる。
エ相違点５(「記述子」構成要件Ｂ)
(ｱ)ａ原告は，本件発明の構成要件Ｂの「記述子」とは，電話番号・会社名・
製品名等のＵＲＬとは異なる数字あるいは言葉であって，目標情報ページを識別す
る「特定かつ唯一のＵＲＬ」と結び付くものであるが，乙２４発明の「サービス名
およびサーバーが持つべき任意の属性」は「特定かつ唯一のＵＲＬ」と結び付く，
ものではないから，本件発明の「記述子」とは異なる旨主張する。
ｂ確かに，本件発明(請求項１)が「記述子」と「ＵＲＬ」を書き分けてい，
ることからすると，構成要件Ｂの「記述子」は，電話番号・会社名・製品名等の数
字あるいは言葉であり，ＵＲＬを含まないと解することはできる。
ｃしかし「特定かつ唯一のＵＲＬ」と結び付く点については，本件明細書，
には，本件発明の「記述子」の意味を「特定かつ唯一のＵＲＬ」と結び付く何か特
別の限定を伴ったものと解釈すべきことを窺わせる記載は認められない。それ自体
は「特定かつ唯一のＵＲＬ」と結び付かない「記述子」の送信に対し「特定かつ，
唯一のＵＲＬ」が返信されるのは「翻訳データベース」の構成の問題であると考，
えられる(この点は，本件訂正後であっても同様である。)。
(ｲ)乙２４発明の構成Ｂ’は「サービス名およびサーバーが持つべき任意の，
属性」を指定して，イエローページ・サービスにサーバーのアドレスを問い合わせ
るものであるから「サービス名およびサーバーが持つべき任意の属性」は，ＵＲ，
Ｌを含んでおらず，本件発明の「記述子」に相当すると認められる。
よって，この点を相違点と認めることはできない。
オ相違点６(「翻訳データベース」構成要件Ｃ)
(ｱ)前記ウのとおり，乙２４発明において周知のリダイレクト機能を採用した
，，以上ＲＥＤＩＲＥＣＴコマンドに含まれるＵＲＬは１つでなければならないから
ＵＲＬを１つとするために，ＲＥＤＩＲＥＣＴコマンドの送信前に，ユーザーに複
数の候補の中から選択させるか，複数の候補の中からの選択の段階を省略するため
に，マッピングにより出力されてくるＵＲＬを１つとしなければならないことは，
当然である。
したがって，ＵＲＬを１つとするために，ユーザーに複数の候補の中から選択さ
せるか，それともマッピングにより出力されてくるＵＲＬを１つとするかは，その
長所，短所を総合して選択する設計事項であると認められる(例えば，選択の段階
を省略すれば，複数の会社が同名であり，それぞれＵＲＬを有する場合に不都合が
生じ得るが，大部分の場合に速やかに目指す情報ページに到達し得ることにな
る。)。したがって，複数の候補の中から選択させる段階を採用せず，マッピング
により出力されてくるＵＲＬを１つとした点は，当業者が容易に想到し得たことで
あると認められる。
(ｲ)ａ原告は，本件発明は，会社名等とＵＲＬを１対１に対応付けしたもので
あり，乙２４発明とはこの点でも相違する旨主張する。
しかしながら，本件発明(請求項１)は「翻訳データベースを用いてＵＲＬにマッ，
ピングする」(構成要件Ｃ)と規定するだけで，翻訳データベースの構造等につきそれ
以上の限定はない(この点は［単一の目標ＵＲＬに対応する］記述子を提供する段，
階と限定した本件訂正発明においても同様であると考えられる。)。本件明細書の発明
の詳細な説明等の中にも，原告主張のように限定して解釈すべきことを正当化する記
載は見いだせない。
ｂ前記()イによれば，乙２４発明のＢ’において，イエローページ・サー1
バーに提供されたサービス名等に対し返されたアドレスは，同サーバー上で稼動す
る選択アルゴリズムによって演算され抽出選択されたものであり，選択アルゴリズ
ムの設定次第で，１つのサーバーのアドレスのみを抽出選択するようにできるもの
である。
したがって，乙２４発明が，どのようなデータベースとして構築するかの点で，
本件発明と相違すると認めることはできない。
ｃ仮に，本件発明が会社名等とＵＲＬを１対１に対応付けした構成を有する
としても，そのようにデータベースを構築することは，例えば，複数の会社が同名
であり，それぞれＵＲＬを有する場合などに不都合が生じ得るが，他面で，データ
ベースの検索アルゴリズムや構造を単純化し，ユーザーによる選択処理を省略した
ため処理速度が向上するなどの効果が得られることを総合衡量して決定される設計
事項にすぎず，当業者にとって容易に想到し得たことと認められる。
カまとめ
本件発明の奏する効果も，本件発明のように構成することから予想される範囲の
ものであり，格別のものとは認められない。
以上によれば，乙２４発明を主引用例として本件発明のように構成することは当
業者に容易に推考することができたことであり，本件発明は進歩性を欠き，本件特
許は無効とされるべきものである。
よって，原告は，被告に対して本件特許を行使することができない(特許法１０
４条の３)。
２争点６(訂正による無効理由の解消の存否)
()争点６−１(訂正要件及び充足)1
原告の主張(ｱ)(訂正要件)は，被告において明らかに争わないからこれを自白し
たものとみなす。
()争点６−２(進歩性の欠如等)2
ア追加の相違点の有無
本件訂正により，前記１の争点５−３についての判断に加えて判断されるべき新
たな相違点は生じていないから，前記１の争点５−３についての判断がそのまま本
件訂正発明の進歩性の判断にも当てはまる。
イまとめ
したがって，本件訂正発明は，依然として進歩性を欠くから，本件発明の無効理
由は解消していない。
３結論
以上によれば，原告の請求は，その余の点について判断するまでもなくいずれも
理由がないから，棄却することとし，主文のとおり判決する。
東京地方裁判所民事第４０部
裁判長裁判官
市川正巳
裁判官
大竹優子
裁判官
中村恭
(別紙２)
被告方法説明書
【サーバー方式】
１概要
後記２項に記載の構成を備えた，インターネットに接続されたパソコンのユーザー
に対し，当該パソコンのウェブブラウザのアドレスバーに任意の文字を記述すること
で目的のウェブページのＵＲＬを取得させ，当該ウェブページへのアクセスを提供す
る「()」に係る方法。サービス名はJapanNLIANativeLanguageInternetAddressSystem
「」である。JAddress
なお，()内の数字は，別紙図面１の番号に対応する。
２構成
Ａ’インターネットよりなるコンピュータネットワークを介してクライアントが
情報ページに対してアクセスする際目的の情報ページのＵＲＬを取得する方法であっ，
て，
Ｂ’ユーザーがクライアントＰＣのウェブブラウザのアドレスバーに任意の日本
語インターネットアドレス()を入力して()，同日本語インターネットアドレJAddress1
ス()(正規ＵＲＬ)又は(’)(非正規ＵＲＬ)を予めプログラム①の付加されたＤＮＳ22
サーバー()に提供する段階()又は(’)と，NLIANameServer22
Ｃ’−Ⅰ内において，付加プログラム①が，クライアントＰＣNLIANameServer
から送信された日本語インターネットアドレスが正規ＵＲＬであるか否かを選別し
()，正規ＵＲＬの場合()，ＤＮＳサーバーの機能によって対応するＩＰアドレスを34
クライアントＰＣに送り返し()，9
Ｃ’−Ⅱ
(原告の主張)
正規ＵＲＬでない場合「」から「サーバー」へとユーザー，NLIANameServerNLIA
が入力した日本語インターネットアドレスを送信する段階と，
(被告の主張)
正規ＵＲＬでない場合「サーバー」のＩＰアドレスをクライアントに送り返，NLIA
す段階(’)と，4
クライアントＰＣが，取得したＩＰアドレスの「サーバー」に向けて当初ユーNLIA
ザーが入力した日本語インターネットアドレスを問い合わせる段階()と，5
’−Ⅲ日本語インターネットアドレスの送信を受けた「サーバー」が，当CNLIA
該日本語インターネットアドレスに対応するＵＲＬを登録情報データベースから取得
する段階()と，6
’「」，，，DNLIAサーバーが当該ＵＲＬをＲＥＤＩＲＥＣＴコマンドを利用して
クライアントＰＣに送信する段階()と，7
Ｅ’クライアントＰＣが，取得したＵＲＬを一旦ＤＮＳサーバーを経由して()，8
対応するＩＰアドレスを取得し()，目的の情報ページの情報を要求する段階()と，910
Ｆ’クライアントＰＣが，目的の情報ページを表示する段階と()，11
Ｇ’以上の段階を備える情報ページのＵＲＬを取得する方法
【プラグイン方式】
１概要
後記２項に記載の構成を備えた，インターネットに接続されたパソコンのユーザー
に対し，当該パソコンのウェブブラウザのアドレスバーに任意の文字を記述すること
で目的のウェブページのＵＲＬを取得させ，当該ウェブページへのアクセスを提供す
「」。「」る()に係る方法サービス名はJapanNLIANativeLanguageInternetSystemJAddress
である。
なお，()内の数字は，別紙図面２の番号に対応する。
２構成
Ａ”インターネットよりなるコンピュータネットワークを介してクライアントが
情報ページに対してアクセスする際目的の情報ページのＵＲＬを取得する方法であっ，
て，
Ｂ”−ⅠユーザーがクライアントＰＣのウェブブラウザのアドレスバーに任意の
日本語インターネットアドレスを入力し()，予めクライアントに付加されたプログラ1
ム②が，同日本語インターネットアドレス()(正規ＵＲＬ)又は(’)(非正規ＵＲＬ)22
を正規ＵＲＬであるか否かを選別する段階()と，3
Ｂ”−Ⅱ入力された日本語インターネットアドレスが正規ＵＲＬの場合()，ブラ2
ウザの機能によって当該正規ＵＲＬをＤＮＳサーバーに送信してＤＮＳサーバーの機
能によって対応するＩＰアドレスをクライアントに送り返し()()，49
正規ＵＲＬでない場合(’)，当該日本語インターネットアドレスをサーバー2NLIA
へのＵＲＬ形式に変更した上，ブラウザの機能によって当該変更したＵＲＬ(”)をＤ2
ＮＳサーバーに送信して，ＤＮＳサーバーの機能によってサーバーのＩＰアドNLIA
レスをクライアントＰＣに送り返す段階(’)と，4
”，，Ｂ−ⅢクライアントＰＣが取得したＩＰアドレスのサーバーに向けてNLIA
当初ユーザーが入力した日本語インターネットアドレスを問い合わせる段階()と，5
Ｃ”問い合わせを受けたサーバーが，当該日本語インターネットアドレスNLIA
に対応するＵＲＬを登録情報データベースから取得する段階()と，6
Ｄ”サーバーが，当該ＵＲＬを，ＲＥＤＩＲＥＣＴコマンドを利用して，クNLIA
ライアントＰＣに送信する段階()と，7
Ｅ”クライアントＰＣが，取得したＵＲＬを一旦ＤＮＳサーバーを経由して()，8
対応するＩＰアドレスを取得し()，目的の情報ページの情報を要求する段階()と，910
Ｆ”クライアントＰＣが，目的の情報ページを表示する段階と()，11
Ｇ”以上の段階を備える情報ページのＵＲＬを取得する方法
以上

戻る