戻る

平成２２年３月２４日判決言渡同日原本領収裁判所書記官
平成２０年（ネ）第１００８５号特許権侵害差止等請求控訴事件（原審・東京地
方裁判所平成１９年（ワ）第２３５２号）
口頭弁論終結日平成２２年３月３日
判決
当事者の表示別紙当事者目録記載のとおり
主文
１原判決を次のとおり変更する。
(1)被控訴人は，別紙サービス目録記載のサービスを
提供してはならない。
(2)被控訴人は，上記(1)のサービスの「JapanNLIA
System」における「NLIAサーバー」を除却し，
「登録情報データベース」を消去せよ。
(3)被控訴人は，控訴人に対し，１４００万円及びこ
れに対する平成１９年２月１５日から支払済みまで
年５分の割合による金員を支払え。
(4)控訴人のその余の請求を棄却する。
２訴訟費用は，第１審，２審を通じ，これを５分し，
その１を控訴人の，その余を被控訴人の各負担とす
る。
３この判決は，第１項の(1)及び(3)に限り，仮に執行
することができる。
事実及び理由
第１控訴の趣旨
１原判決を取り消す。
(1)被控訴人は，「JAddressサービス」を提供してはならない。
(2)被控訴人は，「JapanNLIASystem」における「NLIAサーバー」及び「登録
情報データベース」を除却せよ。
(3)被控訴人は，控訴人に対し，９１７０万円及びこれに対する平成１９年２
月１５日から支払済みまで年５分の割合による金員を支払え。
２訴訟費用は，第１，２審とも，被控訴人の負担とする。
第２事案の概要
１本件は，控訴人が，被控訴人による別紙サービス目録記載のサービス（以下
「被控訴人サービス」という。）の提供行為は，控訴人の有する第３７６２８８２
号特許権（以下「本件特許権」といい，その特許請求の範囲の請求項１に係る発明
及び同発明に係る特許を「本件発明」及び「本件特許」という。）を侵害するもの
であると主張して，①特許法１００条１項に基づく被控訴人サービスの差止め，②
同条２項に基づく同サービスに供された「NLIAサーバー」及び「登録情報データ
ベース」の除却，③民法７０９条に基づく損害賠償及び遅延損害金の支払を請求す
る事案である。
２原判決は，本件特許に係る発明は，下記の引用例に記載された発明（以下
「引用発明」という。）及び周知の技術に基づいて当業者が容易に発明をすること
ができたものであり，本件特許は特許無効審判により無効にされるべきものと認め
られるから，特許法１０４条の３により，控訴人が本件特許権を行使することはで
きないと判示して，控訴人の請求を棄却したため，控訴人がこれを不服として控訴
した。
引用例：昭和６３年にＡＣＭ（アメリカ計算機学会）出版から発行された論文集
「COMPUTERCOMMUNICATIONREVIEWVolume17,Number5SpecialIssue」の「Part8.
RESOURCESHARINGINDISTRIBUTEDSYSTEMS」におけるLarryL.Peterson執筆に係る
論文「AYellow-PagesServiceforaLocal-AreaNetwork」（乙２４の１。訳文は乙
２４の２）
３控訴人の本訴請求を判断する前提となる事実は，以下のとおりである。
(1)当事者
控訴人は，インターネットを利用するシステムの開発・販売及びインターネット
を利用した情報提供サービス業などを業とする株式会社である。
控訴人は，本件発明を実施して，インターネット等の利用者がパソコンのウェブ
ブラウザのアドレスバー等に電話番号等の「インターネットナンバー」を入力する
ことで特定のウェブサイトにアクセスすることができるようにするサービスを提供
している。
被控訴人は，コンピュータシステムにおけるデータベースの構築・販売，情報処
理サービス業及び情報提供サービス業，インターネットでの広告業務及び広告代理
業，インターネットを利用する情報システム及び通信ネットワークの企画，設計・
運用に関する受託等を業とする株式会社である。
被控訴人は，韓国法人である株式会社ネッピアダッコムの関連日本法人である。
(2)本件特許権
ア控訴人は，以下の本件特許権を有している。
特許番号：第３７６２８８２号
発明の名称：インターネットサーバーのアクセス管理およびモニタシステム
原出願日：平成８年６月３日（特願平９−５０３０８４号）
パリ条約による優先権主張日：平成７年６月７日（米国）
分割出願日：平成１３年７月９日
登録日：平成１８年１月２０日
特許請求の範囲の請求項１の記載：別紙特許請求の範囲の記載２のとおり
イ本件発明の構成要件を分説すると，以下のＡないしＧ（以下，順に「構成要
件Ａ」ないし「構成要件Ｇ」という。）のとおりである。
Ａインターネットよりなるコンピュータネットワークを介したクライアントか
らサーバーシステムへの情報ページに対するアクセスを提供する方法であって，
Ｂ前記クライアントにおいて記述子を提供する段階と，
Ｃディレクトリサーバーが，前記記述子を前記ディレクトリサーバーに存在す
る翻訳データベースを用いてＵＲＬにマッピングする段階と，
Ｄ前記ディレクトリサーバーが，ＲＥＤＩＲＥＣＴコマンド中の前記ＵＲＬを
前記クライアントに返送する段階と，
Ｅ前記クライアントに前記ＵＲＬを用いて情報を要求させる段階と，
Ｆ前記ＵＲＬにより識別されたページを前記クライアント側で表示する段階と
Ｇを備えた情報ページに対するアクセス方法。
ウ本件特許の出願後の経過は，以下のとおりである。
(ア)第１回拒絶理由通知
特許庁審査官は，平成１７年４月１５日付けで，①本件特許権の当時の請求項１
ないし１０に係る出願について，各動作の主体がどのハードウェア手段であるかが
不明である，②請求項３の「ＲＥＤＩＲＥＣＴコマンド中のＵＲＬをクライアント
に返送してクライアントにＵＲＬを用いて情報を要求させるサーバーシステムにト
ランザクションデータベースが常駐する」なる記載の意味が不明である等の理由で，
拒絶理由を通知した。
(イ)第１回補正
控訴人は，上記(ア)の①の点については，平成１７年６月２０日，請求項１，３
及び１０を削除し，請求項２に請求項３及び１０を併合して補正後の請求項１を別
紙特許請求の範囲の記載１のとおりとする補正をした。
なお，控訴人は，同日付けの意見書において，上記補正の理由について，次のと
おり主張した。
「補正前の請求項１∼１０に係る発明の，各動作の主体がどのハードウェア手段
であるのかが不明である，に対しては，前述の補正後の請求項１のように補正して
対処し，各動作の主体のハードウェア手段を明確にしております。すなわち，記述
子を提供する段階はクライアントが行い，記述子をディレクトリサーバーに存在す
る翻訳データベースを用いてＵＲＬにマッピングする段階はディレクトリサーバー
が行い，ＲＥＤＩＲＥＣＴコマンド中のＵＲＬをクライアントに返送してクライア
ントにＵＲＬを用いて情報を要求させる段階はディレクトリサーバーが行い，ＵＲ
Ｌにより識別されたページを表示する段階はクライアントが行うものでありま
す。」，「本願発明では，このような長く複雑なＵＲＬに代えて，このＵＲＬに対
応して誰でも簡単かつ容易に入力できる電話番号，会社名，製品名などを入力する
だけで，目標とするＵＲＬのウェブサイトへアクセスできるようにしたものであり
ます。」
また，控訴人は，上記(ア)の②の点については，同意見書において，「補正前の
請求項３の内容を明確にして，補正後の請求項１に併合しております。すなわち，
ディレクトリサーバーが，ＲＥＤＩＲＥＣＴコマンド中のＵＲＬをクライアントに
返送してクライアントにＵＲＬを用いて情報を要求させるものであり，」との意見
を述べ，同日付けの手続補正書において，補正後の請求項１の記載を「前記ディレ
クトリサーバーが，ＲＥＤＩＲＥＣＴコマンド中の前記ＵＲＬを前記クライアント
に返送して前記クライアントに前記ＵＲＬを用いて情報を要求させる段階と，」と
補正した。
(ウ)第２回拒絶理由通知
特許庁審査官は，平成１７年９月２８日付けで，本件特許権の上記(イ)の第１回
補正後の請求項１ないし７に係る出願について，進歩性欠如を理由とする拒絶理由
を通知した。
(エ)第２回補正
控訴人は，平成１７年１２月５日，請求項１を別紙特許請求の範囲の記載２のと
おりとする補正をした。
なお，控訴人は，同日付け意見書において，補正の理由について，「１つの段階
から，ＵＲＬの返送段階と，そのＵＲＬを用いた情報要求段階との２つの段階に分
けて表現し，記載の明瞭化を図りました。」と主張した。
また，控訴人は，同意見書において，本件発明の特徴について，「本願発明は，
インターネット上において，ユーザが電話番号，会社名，製品名等を用いて商業サ
ービスサイトにアクセスできる，インターネットよりなるコンピュータネットワー
クを介したクライアントからサーバーシステムへの情報ページに対するアクセス方
法に関する技術であります。すなわち，本願発明が適用するようなインターネット
の技術分野では，ウェブサイトへアクセスする際に，長く複雑なＵＲＬを入力する
必要があるが，本願発明では，このような長く複雑なＵＲＬに代えて，このＵＲＬ
に対応して誰でも簡単かつ容易に入力できる電話番号，会社名，製品名等を入力す
るだけで，目標とするＵＲＬのウェブサイトへアクセスできるようにしたものであ
ります。」と説明している。
(オ)特許査定
特許庁審査官は，平成１８年１月５日，上記補正内容で特許査定した。
エ本件特許に対する無効審判請求及びその後の経過は，以下のとおりである。
(ア)無効審判請求
被控訴人は，平成１９年１０月３１日付け審判請求書（乙３１）により，本件特
許（請求項１ないし７）について，無効審判を請求した（無効２００７−８００２
４３）。
(イ)訂正請求
控訴人は，平成２０年１月２３日付け訂正請求書（甲４２）により，本件明細書
の特許請求の範囲の請求項１を別紙特許請求の範囲の記載３のとおり訂正する等の
訂正（以下「本件訂正」といい，訂正後の発明を「本件訂正発明」という。）を請
求した。
(ウ)無効審決
特許庁審判官は，平成２０年６月２６日，本件訂正を認めたが，訂正後の請求項
１ないし７の発明は，進歩性欠如を理由として無効とする旨の審決をした（乙３
２）。
(エ)審決取消判決
控訴人は，知的財産高等裁判所に対し，上記無効審決の取消しを求める訴えを提
起した。同裁判所は，平成２１年１１月５日，同審決を取り消す旨の判決をし，同
事件の被告である被控訴人は，同年１１月１９日，同判決を不服として上告及び上
告受理の申立てをした。
(3)被控訴人の行為
ア被控訴人サービスの開始
被控訴人は，平成１８年２月ころ，被控訴人サービス（なお，同サービスにおい
て採用されている方法を「被控訴人方法」という。）を開設した上，サイト運営者
のトライアル登録サービス「TestOperation」を開始し，同年９月５日，その優先
登録サービス「SunriseOperation」を開始したが，これらによる総登録件数は，
１３万６８２６件である。
イ被控訴人方法
被控訴人方法にはサーバー方式及びプラグイン方式とがあるところ，これらの構
成は，別紙構成一覧の１及び２にそれぞれ記載のとおりである。
ただし，サーバー方式のＣ’−Ⅱについて，控訴人が別紙構成一覧記載のとおり
であると主張するのに対し，被控訴人は「正規ＵＲＬでない場合，『NLIAサーバ
ー』のＩＰアドレスをクライアントに送り返す段階(4’)と，クライアントＰＣが，
取得したＩＰアドレスの『NLIAサーバー』に向けて当初ユーザーが入力した日本語
インターネットアドレスを問い合わせる段階(5)と，」であると主張しており，この
点については理由中において判断する。
ウ構成要件の一部充足（弁論の全趣旨）
被控訴人方法は，本件発明の構成要件のうち，少なくとも構成要件Ａ，Ｄ及びＧ
を充足する。
４本件訴訟の争点は，下記(1)ないし(8)のとおりである。
(1)争点１：構成要件Ｂの充足
(2)争点２：構成要件Ｃの充足
(3)争点３：構成要件Ｅの充足
(4)争点４：構成要件Ｆの充足
(5)争点５：本件特許の無効理由の存否
ア争点５−１：開示義務違反（特許法３６条４項，同条６項１号及び２号）
イ争点５−２：新規性の欠如
ウ争点５−３：進歩性の欠如
(6)争点６：本件訂正による無効理由の解消の成否
ア争点６−１：訂正要件及び充足
イ争点６−２：進歩性の欠如等
(7)争点７：被控訴人の侵害主体性
(8)争点８：損害の発生及び額
第３当事者の主張
【原審における主張】
当事者の原審における主張は，原判決中の略称を本判決の略称に読み替え，「争
点５：本件特許権の無効理由の存否」（原判決９頁１４行）を「争点５：本件特許
の無効理由の存否」と，「争点６：本件訂正による無効理由の解消の存否」（同９
頁１８行及び３９頁１７行）を「争点６：本件訂正による無効理由の解消の成否」
を改めるほか，原判決「３争点に関する当事者の主張」（原判決９頁２３行∼４
３頁２１行。ただし，争点８については当審において撤回されているため，これを
除く。）のとおりであるから，これを引用する。
【当審における主張】
１争点６−２（進歩性の欠如等）について
〔控訴人の主張〕
(1)進歩性について
原判決は，乙２４を主引例として本件発明の進歩性を否定した上，本件訂正発明
についても同様であるとし，本件特許は特許無効審判により無効にされるべきもの
と認められると判断したが，この判断は誤りである。
ア乙２４の主引例としての適格性
本件訂正発明は，クライアントにおいて提供されるある記述子と特定かつ単一の
ＵＲＬとを結びつけ，同ＵＲＬにより特定される情報ページにアクセスしようとす
るものであるのに対して，引用発明は，職業別電話帳（YellowPages）に由来する
タイトルからもわかるとおり，クライアントが要求する「サービス名及び属性」と
いう条件に適合するサーバーのアドレスをイントラネット上で検索し，返された検
索結果からクライアントが任意のアドレスを選択するものにすぎない。
つまり，本件訂正発明が「記述子」と特定の「ＵＲＬ」とを１対１又は多対１で
対応付け，「ＲＥＤＩＲＥＣＴコマンド」を利用することによって，クライアント
が自動的に目標とする情報サイトへアクセスすることができるようにしたことを本
質的特徴とするのに対し，引用発明はサービス名及び属性条件という一定の条件を
満たす不特定のサーバーを探す検索サービスであり，これらの技術思想は異なる。
したがって，そもそも乙２４を主引例として進歩性の判断を行った点において原
判決は誤っている。
イ引用発明の認定の誤り
原判決は，乙２４の記載から「１つのサーバーのアドレスのみを抽出選択」する
場合を切り出すとともに，「サービス名をサーバーのアドレスにマッピング」する
ものを引用発明として認定しているが，乙２４に記載された発明はあくまでも「サ
ービス名及び属性」という条件を充足する１又は２以上の不特定のサーバーのアド
レスが返されるものであることを前提としており，ここから上記のように限定され
た発明を認定することはできない。
ウ本件訂正発明と引用発明との相違点についての判断の誤り
(ア)「アドレス」と「ＵＲＬ」
原判決は，引用発明の「アドレス」から，本件訂正発明の「ＵＲＬ」は容易想到
であると判断したが，引用発明はイントラネットに関する発明にすぎないものであ
って，サーバーがインターネットへ直接接続されることを想定していない引用発明
における「アドレス」から，インターネット上の，特にWorld-Wide-Webに係る規約
である「ＵＲＬ」を選択することが容易であるということはできない。また，乙２
４が発行された１９８８年は，World-Wide-Webが発表される１９９１年以前であり，
乙２４は「アドレス」としてWorld-Wide-Webに係る「ＵＲＬ」を想定していない。
(イ)データベースの設計
原判決は，引用発明の「データベース」を「サービス名及び属性」と特定かつ単
一の「アドレス」とを結びつけたデータベースへと構成を変更することは設計事項
にすぎないと判断したが，引用発明のように，不特定のサーバーについてユーザー
が求める条件を入力し，検索結果としてサーバーのアドレスが返されるか，あるい
は，本件訂正発明のように，当初から特定の目標を意図してその結果として特定か
つ単一のＵＲＬが返されるかは，技術思想としての相違というべきである。
(ウ)「ＲＥＤＩＲＥＣＴコマンド中の前記ＵＲＬ」
原判決は，相違点２及び３の判断に関して，乙２６の記載及び図１を引用した上，
本件訂正発明の「ＲＥＤＩＲＥＣＴコマンド中の前記ＵＲＬ」を用いることは容易
想到であったと判断した。
しかしながら，引用発明における「リダイレクション」に係る構成において，遠
隔クライアントが，イエローページ・サービスを実現する「ローカル・サーバー」
へと直接アクセスすることはできない。また，乙２４に記載されるようにＴＣＰプ
ロトコルを前提とする引用発明において，フラッグシップ・ホストからクライアン
トへと送信されるパケット情報に基づき，クライアントがサーバー・ホストへ再接
続することはできない。したがって，乙２６に記載されたリダイレクト機能に関す
る周知技術を引用発明に適用することはできない。
他方，乙２６の「Locationヘッダー」に基づいて「ＲＥＤＩＲＥＣＴコマンド中
の前記ＵＲＬ」という構成が容易想到であるということもできない。
さらに，原判決は，実質的に乙２６を引用例として認定するものであるところ，
被控訴人は乙２６を引用例として主張していない。
(エ)１つのサーバーによる実現
原判決は，相違点２及び３の判断に関して，コンピュータの汎用性と高能力化の
進展にかんがみると，フラッグシップ・ホストとイエローページ・サーバーとを物
理的に１つのサーバーで実現することは単なる設計的事項であると判断しているが，
コンピュータ・ネットワークの世界における「サーバー」とは「クライアントから
の要求に対して何らかのサービスを提供するシステムのこと」を意味するものであ
って，「サーバー」が１つであるか複数であるかはそのクライアントに提供する機
能に着目して区別されるものであるから，上記判断は誤りである。
(オ)小括
以上のとおり，原判決による本件訂正発明と引用発明との相違点についての判断
は誤りであり，本件訂正発明は引用発明に基づいて当業者が容易に発明をすること
ができたものではない。
(2)構成要件の充足
本件訂正発明の構成要件は第２の３(2)エ(イ)のとおりであり，被控訴人方法の
構成は別紙構成一覧１及び２記載のとおりであるところ，被控訴人方法の当該各構
成は本件訂正発明の各構成要件を充足するから，同方法は本件訂正発明の技術的範
囲に属する。
〔被控訴人の主張〕
(1)進歩性について
以下のとおり，控訴人の主張は失当であり，原判決による本件訂正発明の進歩性
についての判断に誤りはない。
ア乙２４の主引例としての適格性
乙２４の記載から，同記載の発明に係る技術がローカルエリア・ネットワーク内
に限ったものでないことは明らかであり，また，ネットワーク外の目的のサーバー
に転送又はリダイレクトする技術であることも明らかであるから，本件訂正発明と
引用発明とでその技術思想が異なるとの控訴人の主張は失当である。
イ引用発明の認定の誤り
控訴人は，原判決による乙２４に基づく引用発明の認定を論難するが，乙２４に
１つのサーバーのアドレスを抽出選択する構成が開示されていることは明白であり，
「サーバーのアドレスにサービス名をマッピングする」と明記されているから，控
訴人の主張はいずれも失当である。
ウ本件訂正発明と引用発明との相違点についての判断の誤り
(ア)「アドレス」と「ＵＲＬ」
本件特許出願時の公知刊行物である乙２８に「ＵＲＬはインターネット上の資源
を統一的に示す方法で，ＷＷＷブラウザを使うときや，ＨＴＭＬ形式の文章でイン
ターネット上の資源を示すときに使われる」との記載があるように，本件特許出願
時においてインターネット上のサービスとしてＨＴＴＰによるＷＷＷがあり，この
ＷＷＷにおいてサーバーにアクセスするためにＵＲＬを用いることは，当業者に周
知の技術であったから，乙２４におけるアドレスがＵＲＬを意識していたかどうか
に関わりなく，引用発明におけるアドレスを，すでにサーバーの住所を表すものと
して周知になっていたＵＲＬで表記することは，当業者に自明であったものであり，
控訴人の主張は失当である。
(イ)データベースの設計
「記述子」が単一の目標ＵＲＬに対応するものであるとしても，クライアントか
ら提供されるものであることに変わりはなく，いかなる「記述子」がクライアント
から示された場合にいかなるＵＲＬを対応させて返送するかは，ひとえにデータベ
ースをどのように構築し，どのような記述子とＵＲＬを登録するか次第であるから，
引用発明の「データベース」を「サービス名及び属性」と特定かつ単一の「アドレ
ス」とを結びつけたデータベースへと構成を変更することは設計事項にすぎないと
した原判決の判断に誤りはない。
(ウ)「ＲＥＤＩＲＥＣＴコマンド中の前記ＵＲＬ」
控訴人は，引用発明において，クライアントがローカル・サーバーに直接接続さ
れる技術ではないと主張するが，引用発明は，転送されたサーバーとクライアント
とが直接に接続される技術であって，全体として当然にアプリケーション層を含め
たコンピュータ通信に関する技術であり，ここで示されたリダイレクトが，ＴＣＰ
のみに限定された技術と理解すべき必然性はどこにもないから，控訴人の主張は失
当である。
また，本件発明における「ＲＥＤＩＲＥＣＴコマンド」とは「サーバーからクラ
イアントに送信され，クライアントが前記サーバーとは別のサーバーへ自動的に送
信する命令」と認められるところ，乙２６には，目的のドキュメントを表示するた
めにそのＵＲＬを含んだLocationヘッダーを返せばよいことが記載されており，こ
れは，それ以外の作業を必要とせずに（自動的に）目的のドキュメントが表示され
ることを意味するから，この挙動は「ＲＥＤＩＲＥＣＴコマンド」のものと同じで
あり，「ＲＥＤＩＲＥＣＴコマンド中の前記ＵＲＬ」という構成が容易想到である
との原判決の判断に誤りはなく，控訴人の主張は失当である。
さらに，乙２６は，ＲＥＤＩＲＥＣＴコマンドに関する周知の技術を説明するた
めに被控訴人が提出した証拠であり，この証拠から原判決が周知の技術を認定する
ことに何ら問題はない。
(エ)１つのサーバーによる実現
控訴人が主張するとおり，「サーバー」が「クライアントからの要求に対して何
らかのサービスを提供するシステム」を意味することは否定しないが，単に「サー
バー」といったときは，サーバーソフトウェアを指す場合も，サーバーコンピュー
タを指す場合もある。原判決は，イエローページ・サーバーの機能とフラッグシッ
プ・ホストの機能とを併せた機能を提供するハードウェアとしての１つのサーバー
とすることが単なる設計的事項であるという当然のことを判示したにすぎず，この
点に誤りはないのであり，控訴人の主張は失当である。
(オ)小括
以上のとおり，控訴人の主張はいずれも失当であり，本件訂正発明は引用発明に
基づいて当業者が容易に発明をすることができたとの原判決の判断に誤りはない。
(2)構成要件の充足
被控訴人方法は本件訂正発明の技術的範囲に属しない。
２争点８（損害の発生及び額）について
〔控訴人の主張〕
控訴人の損害は，特許法１０２条３項に基づいて，以下のとおり算定されるべき
である。
(1)被控訴人は，過去において本件発明を実施していただけでなく，現在にお
いても実施しているものであり，仮に，被控訴人サービス（JAddress）が商用サー
ビスに移行していないなどの事情により被控訴人が現実には登録申請・受付及び／
又は登録によって売上げを上げていないとしても，損害が発生していることに変わ
りはない。
(2)被控訴人の１３万６８２６件の登録件数のうち，無料登録件数３件を除い
た１３万６８２３件が仮登録であって，現実の売上げが発生していないとの事情を
前提としても，特許法１０２条３項にいう「特許発明の実施に対し受けるべき金銭
の額に相当する額」は，無料登録件数３件について１件当たりの登録料金である３
万１５００円に通常の実施料率４％を乗じた額，仮登録件数１３万６８２３件につ
いて通常の実施料率の半分である２％を乗じた額に基づいて，それぞれ登録件数を
乗じた額である（３万１５００円×２％×１３万６８２３件＋３万１５００円×４
％×３件＝）８６２０万２２７０円と算定すべきである。
〔被控訴人の主張〕
(1)被控訴人は，本件紛争が発生したため，被控訴人サービスの商用的な実施
には至っておらず，被控訴人に利益がないことはもちろん，控訴人に損害は発生し
ていない。
(2)被控訴人における登録件数が１３万６８２６件であることは認めるが，そ
の余の控訴人の主張についてはいずれも争う。
第４当裁判所の判断
１構成要件の充足性（争点１ないし４）について
(1)構成要件Ｂ
ア構成要件Ｂは，「前記クライアントにおいて記述子を提供する段階と，」と
規定するものである。
そして，特許請求の範囲の記載によると，本件発明において，「記述子」は翻訳
データベースによりＵＲＬにマッピングされ，そのＵＲＬがクライアントに返送さ
れ，返送されたＵＲＬを用いてクライアントは情報を要求することになるのである
から，構成要件Ｂにおける「記述子」がＵＲＬを含まないことは明らかである。
しかしながら，本件特許出願に係る明細書（以下「本件明細書」という。）の発
明の詳細な説明には，「【００４１】本発明の一構成では，商業者のサービスにア
クセスするためにユーザが従来の電話番号，またはその他の識別子を利用できるよ
うにする便が設けられている。」，「【００４２】別の実施形態では，従来のブラ
ウザを備えた形で，クライアント６０１が“ダイヤル”コマンドの場所に電話番号，
またはその他の識別子を入れることを促すディレクトリサーバー６０２により提供
された書式ページを用いる。」及び「【００４４】別の実施形態では，数字以外の
識別子を設けることができる。例えば，ユーザは会社名または製品名を不正確なつ
づりで記入することがある。このような場合“soundex”または他の音声マッピン
グが同じ目標ＵＲＬに対するマップと類似して響く語を許容するため用いることが
できる。また，製品名または内線と組み合わせた電話番号のような複数の識別子も
使用可能である。」との記載があるところ，これらの記載がクライアントが提供す
る「記述子」を特定の種類のものに限定する趣旨のものとは解されない。
そうすると，構成要件Ｂにおける「記述子」は，ＵＲＬそのものを含まないと解
されるほかには，特段の限定がないものと解されるべきである。
イ他方，被控訴人方法のうち，サーバー方式は，構成Ｂ’「ユーザーがクライ
アントＰＣのウェブブラウザのアドレスバーに任意の日本語インターネットアドレ
ス(JAddress)を入力して(1)，同日本語インターネットアドレス(2)(正規ＵＲＬ)又
は(2’)(非正規ＵＲＬ)を予めプログラム①の付加されたＤＮＳサーバー(NLIAName
Server)に提供する段階(2)又は(2’)と，」を備えるものであり，また，プラグイ
ン方式は，同Ｂ”−Ⅰ「ユーザーがクライアントＰＣのウェブブラウザのアドレス
バーに任意の日本語インターネットアドレスを入力し(1)，予めクライアントに付加
されたプログラム②が，同日本語インターネットアドレス(2)(正規ＵＲＬ)又は(2
’)(非正規ＵＲＬ)を正規ＵＲＬであるか否かを選別する段階(3)と，」を備えるも
のである。
そうすると，被控訴人方法は，いずれもユーザーがクライアントＰＣにおいて任
意の日本語インターネットアドレスを入力するという段階を含むところ，日本語イ
ンターネットアドレス(2)には，正規ＵＲＬと非正規ＵＲＬとが含まれることが想定
され得るが，被控訴人方法において非正規ＵＲＬが提供される場合が存在する以上，
被控訴人方法はクライアントにおいても「記述子」を提供する段階を含むものとい
うべきである。
ウ被控訴人は，本件発明における記述子の提供方法について，被控訴人方法の
ようにクライアントＰＣのウェブブラウザのアドレスバーに入力する方法によるも
のは含まれないと主張するが，構成要件Ｂが記述子の「提供の方法」を限定するも
のでないことは上記アのとおりであるから，被控訴人の主張を採用することはでき
ない。
エしたがって，被控訴人方法は，本件発明の構成要件Ｂを充足する。
(2)構成要件Ｃ
ア構成要件Ｃは「ディレクトリサーバーが，前記記述子を前記ディレクトリサ
ーバーに存在する翻訳データベースを用いてＵＲＬにマッピングする段階と，」と
規定するものである。なお，「前記記述子」は，上記(1)において説示したとおり，
ＵＲＬを含まないものと解される。
イ他方，被控訴人方法の構成のうち，クライアントによって入力される日本語
インターネットアドレスが正規ＵＲＬでない場合について，被控訴人の主張に沿っ
てみてみると，サーバー方式は，構成Ｃ’−Ⅰ「NLIANameServer内において，付
加プログラム①が，クライアントＰＣから送信された日本語インターネットアドレ
スが正規ＵＲＬであるか否かを選別し(3)，」，同Ｃ’−Ⅱ「正規ＵＲＬでない場合，
「NLIAサーバー」のＩＰアドレスをクライアントに送り返す段階(4’)と，クライ
アントＰＣが，取得したＩＰアドレスの「NLIAサーバー」に向けて当初ユーザーが
入力した日本語インターネットアドレスを問い合わせる段階(5)と，」及び同Ｃ’−
Ⅲ「日本語インターネットアドレスの送信を受けた「NLIAサーバー」が，当該日本
語インターネットアドレスに対応するＵＲＬを登録情報データベースから取得する
段階(6)と，」を備えるものであり，また，プラグイン方式は，構成Ｂ”−Ⅱ「入力
された日本語インターネットアドレスが…正規ＵＲＬでない場合(2’)，当該日本語
インターネットアドレスをNLIAサーバーへのＵＲＬ形式に変更した上，ブラウザの
機能によって当該変更したＵＲＬ(2”)をＤＮＳサーバーに送信して，ＤＮＳサーバ
ーの機能によってNLIAサーバーのＩＰアドレスをクライアントＰＣに送り返す段階
(4’)と，」，同Ｂ”−Ⅲ「クライアントＰＣが，取得したＩＰアドレスのNLIAサ
ーバーに向けて，当初ユーザーが入力した日本語インターネットアドレスを問い合
わせる段階(5)と，」及び同Ｃ”「問い合わせを受けたNLIAサーバーが，当該日本
語インターネットアドレスに対応するＵＲＬを登録情報データベースから取得する
段階(6)と，」を備えるものである。
ウしかるところ，被控訴人方法は，いずれも登録情報データベースから非正規
ＵＲＬである日本語インターネットアドレスに対応するＵＲＬを取得する段階を備
えるものであるから，被控訴人方法は本件発明の構成要件Ｃを充足することになる。
この点について，被控訴人は，被控訴人方法の構成は，正規ＵＲＬと非正規ＵＲ
Ｌとを選別する段階を必須とするものであり，非正規ＵＲＬであると選別された記
述子に限って「NLIA」サーバーに送られ，サーバー方式において上記選別の段階を
担う「NLIANameServer」は「NLIAサーバー」とは別のサーバーであると主張する
が，本件発明における「記述子」が正規ＵＲＬを含まないものであることは上記
(1)のとおりであり，本件発明の構成要件をすべて充足するアクセス方法に正規Ｕ
ＲＬの処理に関する機能が加わったり，途中にクライアントＰＣを介する処理が加
わったりしても，そのアクセス方法が本件発明の技術的範囲に含まれなくなるもの
ではないから，被控訴人の主張は失当である。
そうすると，本件発明との対比において必要となる被控訴人方法の構成は，別紙
構成一覧に記載したものに尽きるのであり，被控訴人方法のサーバー方式に係るも
のは，少なくとも同記載のＣ’−Ⅱの構成を備えるものとして認定することができ
る。
また，被控訴人は，被控訴人方法は，記述子をアドレスバーに入力するものであ
るから，構成要件Ｃの「前記記述子」を充足しないとも主張するが，この主張を採
用することができないことは上記(1)のとおりである。
エしたがって，被控訴人方法の構成は別紙構成一覧に記載のとおりのものであ
り，被控訴人方法は，本件発明の構成要件Ｃを充足するものである。
(3)構成要件Ｅ及びＦ
ア本件発明の構成要件Ｅは「前記クライアントに前記ＵＲＬを用いて情報を要
求させる段階と，」と規定し，同Ｆは「前記ＵＲＬにより識別されたページを前記
クライアント側で表示する段階と」と規定する。
イ他方，被控訴人方法のうち，サーバー方式は，構成Ｅ’「クライアントＰＣ
が，取得したＵＲＬを一旦ＤＮＳサーバーを経由して(8)，対応するＩＰアドレスを
取得し(9)，目的の情報ページの情報を要求する段階(10)と，」及び同Ｆ’「クライ
アントＰＣが，目的の情報ページを表示する段階と(11)，」を備えるものであり，
また，プラグイン方式は，構成Ｅ”「クライアントＰＣが，取得したＵＲＬを一旦
ＤＮＳサーバーを経由して(8)，対応するＩＰアドレスを取得し(9)，目的の情報ペ
ージの情報を要求する段階(10)と，」及び同Ｆ”「クライアントＰＣが，目的の情
報ページを表示する段階と(11)，」を備えるものである。
ウそして，被控訴人方法における「取得したＵＲＬを一旦ＤＮＳサーバーを経
由して(8)，対応するＩＰアドレスを取得し(9)，」とは，クライアントが情報を要
求する前提として，ディレクトリサーバーから返送されたＵＲＬを用いていること
にほかならず，被控訴人方法においては，このＩＰアドレスによって「目的の情報
ページの情報を要求する」ものであるから，被控訴人方法は本件発明の構成要件Ｅ
を充足することになる。
また，本件発明の構成要件Ｆにおける「ＵＲＬにより識別されたページ」とは，
ＵＲＬによって特定されたクライアントが目指すページを意味することは特許請求
の範囲の記載から明らかであるところ，被控訴人方法の構成Ｆ’及びＦ”における
「目的の情報ページ」とは，正にこのような「ＵＲＬにより識別されたページ」で
あるから，このようなページが「クライアントＰＣ」，すなわち「クライアント
側」で表示される段階を備える被控訴人方法は，本件発明の構成要件Ｆを充足する
ものである。
エ被控訴人は，構成要件Ｅの充足性に関し，本件発明は方法の発明であり，出
願経過における控訴人の意見書の記載からも，構成要件Ｅの段階は，構成要件Ｄの
段階である「前記ディレクトリサーバーが，ＲＥＤＩＲＥＣＴコマンド中の前記Ｕ
ＲＬを前記クライアントに返送する段階」と時系列的に異なる段階として行われる
必要があるものと解釈すべきであるとした上，被控訴人方法においては，クライア
ントのブラウザのアドレスバーを利用した標準的なプロトコルを用いて，「NLIAサ
ーバー」からアドレスバーに所期のＵＲＬを返しさえすれば，その後は，クライア
ントに備わっているブラウザが当該ＵＲＬによって識別されたページを（ＤＮＳサ
ーバーを介して）取得し，クライアントＰＣに表示するものであり，本件発明のよ
うに構成要件Ｄに相当する段階と別の段階として構成要件Ｅに相当する段階を備え
ているものではないと主張する。
しかしながら，本件明細書の発明の詳細な説明をみると，本件発明の概要につい
て「【００１２】認証サーバーは，次いでこのＳＩＤが付加されたオリジナルＵＲ
Ｌから成る新しい要求を，ＲＥＤＩＲＥＣＴによってクライアントに送出する。新
しいＵＲＬにより形成された修正要求は，自動的にクライアントブラウザによりコ
ンテンツサーバーに送出される。」との記載があるほか，実施形態について「【０
０４５】メッセージ２では，ディレクトリサーバー６０２がＲＥＤＩＲＥＣＴをク
ライアント６０１に送信し，これには，データベース６０４から演算されたＮＵＭ
ＢＥＲに対する目標ＵＲＬが記述されている。クライアントブラウザ６０１は続い
て自動的にメッセージ３を送信し，このＵＲＬのコンテンツをＧＥＴする。サーバ
ー６０２が最終的なＵＲＬに対する翻訳を行い，ページよりはむしろＲＥＤＩＲＥ
ＣＴをクライアント６０１に送信するため，メッセージ４のドキュメントは最初の
ダイヤル入力以上のユーザーの行為なしで入手される。」及び「【００４７】“ダ
イヤル”コマンドおよびその実施の利点の中には，従来の電話番号および他の識別
子と互換性を有する，インターネットにアクセスする改善された方法がある。商業
者はコンタクト情報のインターネット特定書式を提供するための印刷物またはテレ
ビ広告を変更する必要がなく，ユーザはＵＲＬについて知る必要がない。」との記
載があるのであって，この記載によると，本件発明においても，ＲＥＤＩＲＥＣＴ
を送信し，この送信されるデータ中に目標ＵＲＬが記述されているのであり，アク
セス方法の段階としては，構成要件Ｄの段階と同Ｅの段階とは論理的に順次発生す
るものである。
他方，被控訴人方法においても，サーバー方式の構成Ｄ’及び同Ｅ’，プラグイ
ン方式の構成Ｄ”及び同Ｅ”において，それぞれＲＥＤＩＲＥＣＴコマンドを利用
してＵＲＬを送信する段階とＵＲＬに基づいて情報を要求する段階を実現している
のであり，これらの段階が順次発生するものであることは論理的に明らかであるか
ら，被控訴人方法も，これらの順次発生する段階を備えているというべきである。
なお，被控訴人の主張が被控訴人方法が構成要件Ｅの段階のみを実現する独立の
構成を備えていないという趣旨であるとしても，一般に，デジタル通信においては，
複数のデータを同時に送信することが可能であり，これら複数のデータを命令の形
式で構成することも可能であるところ，本件明細書における上記各記載によると，
本件発明は，ＲＥＤＩＲＥＣＴコマンドとともにクライアントに返送されたＵＲＬ
に基づいて，自動的にクライアントに情報を要求させ（，同要求に係るＵＲＬによ
って識別されたページを自動的にクライアント側において表示す）るものを含むと
解することに支障はなく，上記のとおり，そのようなものも構成要件Ｄの段階と同
Ｅの段階を順次発生させるものと解すべきであるから，被控訴人方法は本件発明の
構成要件Ｄ及び同Ｅを充足することになる。
控訴人は，本件特許の出願経過において，構成要件Ｄ及びＥを別々の段階として
書き分けることを内容とする平成１７年１２月５日付け手続補正書による補正につ
いての意見書において，「１つの段階から，ＵＲＬの返送段階と，そのＵＲＬを用
いた情報要求段階との２つの段階に分けて表現し，記載の明瞭化を図りました。」
と記載しているが，この記載は，本件発明が備えるべき段階を書き分けることによ
って発明特定事項を明瞭にするものと理解することができるものであり，上記に説
示したところによると，上記補正によって，本件発明が，構成要件Ｄに相当する段
階と同Ｅに相当する段階が時系列的に別の段階としてそれぞれ独立して存在するも
のに限定されると理解することはできない。
したがって，被控訴人の主張を採用することはできない。
また，被控訴人は，構成要件Ｆについても，上記と同様の主張をするが，これを
採用することができないことは，上記のとおりである。
(4)小括
以上のとおり，被控訴人方法は本件発明の構成要件Ｂ，Ｃ，Ｅ及びＦを充足する
ところ，前記第２の３(3)ウのとおり，被控訴人方法は本件発明の構成要件Ａ，Ｄ
及びＧを充足するから，被控訴人方法は本件発明の技術的範囲に属するものといわ
なければならない。
なお，本件訂正発明においては，本件発明の構成要件Ｂにおける「記述子」が
「単一の目標ＵＲＬに対応する記述子」と，同Ｅにおける「情報を要求する段階」
が「情報を自動的に要求する段階」と，それぞれ訂正されている。これらのうち，
前者は，「記述子」がＵＲＬを含まないものであることを前提として，これを「単
一の目標ＵＲＬに対応する」ものに限定するものであるところ，被控訴人方法は，
「日本語インターネットアドレスに対応するＵＲＬを登録情報データベースから取
得する段階」を備えるものであり，その後の段階において，更にＵＲＬの選別が行
われるものではないから，登録情報データベースにおいて日本語インターネットア
ドレスと単一のＵＲＬが対応付けられているということができる。また，後者は情
報の要求が「自動的に」行われることを明示するものであるところ，被控訴人方法
においても，目的の情報ページの情報の要求は，ユーザーによるクライアントＰＣ
についての特段の操作を要しないで行われるものであるから，自動的に行われるも
のであるということができる。したがって，被控訴人方法は，将来，本件訂正が確
定したとしても，本件訂正発明の技術的範囲に属するということができる。
２本件特許の無効理由の存否（争点５）について
(1)開示義務違反（特許法３６条４項，同条６項１号及び２号）
被控訴人は，本件発明が明確でなく，実施可能要件及びサポート要件を満たすも
のでもないというべきであるから，本件特許は特許無効審判により無効とされるべ
きであると主張するので，まず，この点について検討する。
ア「アクセス」について
被控訴人は，本件発明の構成要件Ａにおける「アクセスを提供する方法」及び同
Ｇにおける「アクセス方法」の主体が異なっており，「アクセス」，「アクセスを
提供する」及び「アクセスする」が具体的に何を意味するのか不明瞭であり，発明
が明確でないと主張する。
しかしながら，「アクセス」が「インターネットよりなるコンピュータネットワ
ークを介したクライアント」による「サーバーシステムの情報ページ」に対するも
のであることは構成要件Ａの記載自体から明らかであり，本件発明がそのような
「アクセス」を提供する方法の発明であることも明らかである。そして，提供され
る「アクセス方法」が，構成要件ＢないしＦにおいて特定された段階を備えるもの
であることが特定されており，これが「ディレクトリサーバー」を基点とする情報
処理の各段階を特定するものであることは，特許請求の範囲の記載から容易に理解
することができるのであり，アクセスを提供する主体として，本件発明における
「ディレクトリサーバー」に相当するサーバーの管理者が想定されていることにつ
いても同様である。
したがって，当業者にとって，「アクセス」，「アクセスを提供する」及び「ア
クセスする」の行為がどのようなものであるかについての疑義はないというべきで
あり，被控訴人の主張を採用することはできない。
イ「記述子」の提供方法について
被控訴人は，本件発明の構成要件Ｂはクライアントの記述子の提供方法を特定し
ていないところ，控訴人方法のようにクライアントがアドレスバーに記述子を入力
する場合には，正規ＵＲＬかどうかを選別する段階がなければ，「ディレクトリサ
ーバー」に記述子が送られることはないにもかかわらず，本件発明ではこのような
選別の段階について発明特定事項とされておらず，発明が明確ではないと主張する。
しかしながら，本件発明は特定の段階を備えたアクセス方法を提供するものであ
って，クライアントによる記述子の提供方法を問わないものであることは，上記１
(1)のとおりであり，この点で発明が明確でないということはできない。また，ア
クセス方法の提供に際して，特定の記述子の提供方法を採用することによって，こ
れに対応して特定の情報処理のための段階を設ける必要が生じるとしても，そのこ
とによって，本件発明における発明特定事項が明確でなくなるものではなく，上記
必要な情報処理のための段階を加えるかどうかは，本件発明を実施するに際して当
業者が適宜選択することができる設計的事項ということができるのであるから，こ
れをもって本件発明が明確でないということはできないし，実施可能でないという
こともできない。
したがって，被控訴人の主張を採用することはできない。
ウ「ディレクトリサーバー」について
被控訴人は，本件発明の構成要件Ｃにおける「ディレクトリサーバー」の語が不
明瞭であり，クライアントが提供した記述子を「ディレクトリサーバー」が受け取
る方法について特定していないと主張する。
しかしながら，本件発明の構成要件において，「ディレクトリサーバー」は，
「記述子をＵＲＬにマッピングするための翻訳データベース」を備えるものであっ
て，「ＲＥＤＩＲＥＣＴコマンド中のＵＲＬをクライアントに返送する」という機
能を有するサーバーとして特定されており，それ以上の限定を加えられるものでは
ないという限度において明確であり，記述子を受け取る方法についても限定がない
ものとして理解すべきである。そして，被控訴人は，これらの点を特定しない限り，
本件発明を実施することができないことを指摘するものではない。
したがって，被控訴人の主張を採用することはできない。
エ小括
以上のとおり，本件発明が明確でないとの被控訴人の主張を採用することができ
ないから，この主張に基づく実施可能要件違反及びサポート要件違反の主張につい
ても採用することができない。
(2)新規性及び進歩性の欠如
被控訴人は，本件発明は，引用例に記載された発明と同一又は同発明に基づいて
当業者が容易に発明をすることができたものであり，特許無効審判において無効と
されるべきものであると主張するので，次に，この点について検討する。
ア引用例の記載
引用例には，以下の記載（なお，括弧内は訳文である乙２４の２における記載箇
所を示す。）がある。
(ア)「摘要サービス名をサーバーのアドレスにマッピングするイエローペー
ジ・サービスを紹介する。このサービスは，属性のセットを各サーバーに関連づけ
るという点で新規なものである。クライアントは，サービスを要求する際にサーバ
ーが所有すべき属性を指定し，イエローページ・サービスは，どのサーバーが要求
を満たすかを判断する。イエローページ・サービスのローカルエリア・ネットワー
ク内での実施の説明だけでなく，インターネットの至る所からクライアントがロー
カル・サーバーにアクセスできるようにするために，本サービスが，使用可能なイ
ンターネット通信プロトコルとどのように統合できるかを示す。」（１頁６∼１３
行）
(イ)「我々の設計は，従来のネーム・サーバー…とは，２つの点で異なる。
第１に，サーバーの特徴およびプロパティを記述する属性（attribute）のセッ
トが各サーバーに関連付けられる。サービスを受けたいクライアントは，サービス
名およびサーバーが持つべき任意の属性を指定して，イエローページ・サービスに
サーバーのアドレスを問い合わせる。イエローページ・サービスは，クライアント
の要求を満たす一或いは二以上のサーバーのアドレスを返送する。
第２に，インターネットの至る所からのクライアントは，適切なサーバーを選択
するために，中間エージェントを通じて，自律システム内で使用可能なイエローペ
ージ・サービスを使用するサーバーに問い合わせる。具体的には，ローカル・シス
テム内のフラッグシップ（flagship）・ホストは，システムが提供するサービスの
セットをインターネット・ネーミング・サービスによって通知する。クライアント
は，そのホスト上でサーバーを使用できるかのように，フラグシップ・ホストに接
続する。次に，フラグシップ・ホスト上で動作する転送メカニズム（forwarding
mechanism）が，実際にそのサービスを提供するサーバーにクライアントを接続さ
せる（patch）。転送メカニズムは，イエローページに，サービスを提供するサー
バーのうち，最も負荷の軽いサーバーのアドレスを判断するよう問い合わせる。転
送メカニズムを通じた間接参照および適切なサーバーの選択は，遠隔クライアント
からは隠される。」（１頁２３行∼２頁５行）
(ウ)「２．アーキテクチャ
サーバーのセットが，イエローページ・サービスを実施する。各サーバーは，使
用可能なサービスおよびサーバーに関する情報のデータベースを維持する。システ
ム内のクライアントは，SunRemoteProcedureCallメカニズム…を使用して，一或
いは二以上のサーバー上の動作を要求する。
２．１属性
属性は，サーバーのプロパティまたは特徴を示す統語的要素である。
ある所定のサーバーに関連付けられる属性は，イエローページ・データベースに
記録される。クライアントは，ある特定のサービスを提供するサーバーについてイ
エローページに問い合わせる際，属性のセットを送信する。
属性は，二つの次元に沿って分類される。一つの次元に沿って，属性は，静的
（static）であるかまたは動的（dynamic）であるかに基づいて区別される。静的
属性は，サーバーの固定のプロパティ，例えば，プリンタの速度やプロセッサのア
ーキテクチャに該当する。静的属性は，例えばアップグレードなどによって変わる
場合もあるが，かかる変更は，稀であり，イエローページ・データベースへの更新
によって簡単に追跡できる。これに対し，動的属性は，例えば，プロセッサの負荷
や印刷キューのジョブ数のように絶えず変化する。動的属性の重要な特徴は，イエ
ローページ・サービスが属性に基づく判断を要求されるよりもはるかにより頻繁に
変化することである。従って，実用的な理由から，サーバーの動的属性は，要求が
あった場合にのみ計算されるべきである。
もう一つの次元に沿って，属性は，絶対的（absolute）であるかまたは相対的
（relative）であるかに従って区別される。絶対的な属性は，他の全てのサーバー
とは関係なく決定することができるサーバーの性質，例えば，サーバーのアーキテ
クチャや負荷などに該当する。これに対し，相対的属性は，サーバーのセットにつ
いて計算されるもので，負荷が最小のプロセッサや出力率が最大のプリンタなどで
ある。
クライアントは，ある所定のサービスを提供する一或いは二以上のサーバーのア
ドレスを取得するためにイエローページ・サーバーに問い合わせる。クライアント
は，サービス名の指定だけでなく，指定した属性条件のセットを満たすサーバーが
サービスを提供するものとして選択されることを要求する。」（２頁１４行∼３頁
１３行）
(エ)「２．２データベース
各イエローページ・サーバーには，システム内で使用できるサービスについての
情報のデータベースが関連付けられる。データベースには，各サービスとそのサー
ビスを提供するサーバーのセットとがバインディングされて（結びつけて）格納さ
れる。
service───>{server,server,...server}12n
つぎに，サーバーは，以下のように定義される。
server≡
ここで，addressは，クライアントにとって意味のある文字列であり，─例えば，
印刷サーバーのアドレスは，単に，プリンタ装置の名称によって指定され，─また，
registered_attrは，サーバーに関連付けられる静的，絶対的属性の組である。」
（３頁２１∼３０行）
(オ)「４．転送（forwarding）メカニズム
このセクションでは，イエローページ・サービスがどのようにしてインターネッ
ト・トランスポート・プロトコルに統合され，それによって，クライアントがイン
ターネットの至る所から自律システム内のサーバーにアクセスできるのかを説明す
る。テストベッドは，DARPAインターネット内のローカルエリア・ネットワークな
ので，遠隔クライアントがアクセスできるサーバーは，一或いは二以上のシステム
のホスト上にあり，よく知られているポートで待機するサーバーに限定される…。
ローカル・システム内の唯一のホストが，フラグシップ・ホストとして指定され
る。例えば，arizona.eduという名前のホストが，アリゾナ大学のフラグシップ・
ホストである。システムは，ドメイン名システム（domainnamingsystem）…によ
って，リソース・レコード−サービスごとにひとつある可能性がある−のセットを
登録することによって，フラグシップがサービスのセットをインターネット・クラ
イアントに提供するものとして広告する。例えば，MXリソース・レコードは，シス
テムのためのメール・サービスがフラグシップ・ホスト…で使用できることを示す。
クライアントは，システムにおいて特定のサービスを提供するホストのアドレスを
取得するためにドメイン名サーバーに問い合わせ，フラグシップ・ホストのアドレ
スが返される。その後，クライアントは，フラグシップ・ホスト上のウェルノウン
ポート宛に一或いは二以上のパケットを送信することによって，サーバーに問い合
わせる。すると，フラグシップ・ホストは，そのパケットをシステム内のサーバー
に転送する。このように，転送メカニズムは，ウェルノウンポートにおいてサーバ
ーにアクセスする戦略と類似している。フラグシップは，システムに対して，『ウ
ェルノウンホスト』の役割を果たす。
転送メカニズムがTCP内でどのように実施されるかを更に詳細に検討する。フラ
グシップ・ホスト上で動作するTCPモジュールが，転送メカニズムを含むように変
更される。転送メカニズムには，ウェルノウンをサーバーのアドレスにバインディ
ングするテーブルが関連付けられる。そのテーブルには，以下のフォームのバイン
ディングが含まれる。
well-known-port───>{addr,addr,...addr}12m
ここで，各サーバーのアドレスは，ポート，ホスト・アドレスの対で指定される。
あるポート宛のパケットがTCPモジュールに到着すると，そのポートへの転送が行
われるべきか，すなわち，テーブルにエントリが存在するかについて，転送メカニ
ズムが問い合わせられる。パケットが新規クライアントからの場合，転送サーバー
は，使用可能なサーバーをランダムにひとつ選択し，パケットをそのサーバーに転
送する。すなわち，転送メカニズムは，パケットの宛先のアドレスをそのサーバー
のアドレスに設定し，パケットを再送信する。これにより，以下の対が，接続に通
常関連付けられるプロトコル・コントロール・ブロック（protocolcontrol
block）に記録される。
->clientclientserverserver
同一の接続上で送信される後続のパケットは，同一のサーバーに転送される。
サーバー・ホスト上でTCPモジュールは，転送が行われていることを認識し，全
ての応答メッセージを直接クライアントに送信する。サーバー・ホスト上のTCPは，
パケットのソース・アドレスをフラグシップ・ホストのアドレスに設定し，それに
よってクライアントには，クライアントがまだフラグシップ・ホストと通信してい
るかのように見える。従って，転送が行われていることをクライアントが認識する
ことはない。
フラグシップ・ホスト上で動作するロード・マネージャは，転送メカニズム・テ
ーブル内のウェルノウンポートのそれぞれをサーバーのセットにバインディングす
る。ロード・マネージャの目的は，ローカル・サーバーの負荷のバランスをとるた
めに，遠隔作業をローカル・サーバーに分配することである。メール・サービスな
どの，一般的に使用可能なサービスの場合，負荷がある閾値以下の全てのプロセッ
サ・サーバーを定期的に問い合わせることによって，マネージャは，イエローペー
ジ・サービスのクライアントとなる。そして，マネージャは，転送メカニズムのテ
ーブルを適宜更新する。ただし，転送メカニズムは，TCPに組み込まれているので，
遠隔クライアントは，特定の属性のセットを満足するサーバーを要求することはで
きず，ロード・マネージャのみが，イエローページ・サービスのクライアントとな
る。」（８頁８行∼１０頁９行）
(カ)「統合
イエローページ・サービスは，転送メカニズム及びロード・マネージャによって
インターネット・トランスポート・プロトコルと統合されている。遠隔クライアン
トがシステムのイエローページ・サーバーの１つに直接的に接触できない根本的な
理由はないが，転送メカニズムがわずかなコストでクライアントによって要求され
るサービスを考えられる最新の瞬間−接続確立中−のサーバーに結び付けることが
できることを留意することが重要である。直感的に，これは，遠隔クライアントと
システム間の『距離』がシステムの『直径』より桁違いに大きいインターネットに
おいて重要である。すなわち，この方式は，サービスを提供するサーバーのセット
を変更するよりも，サーバーに接続を確立するために長い時間がかかる環境には適
切である。
また，この方式は，自律システム抽象化の背後にサーバーについての情報を隠す
ために魅力的である。言い換えると，サービスを提供するシステムの中のホストは，
サーバーを実現するホスト上のプロセスがサーバーを呼び出すクライアントの目に
見えないのと同じように，サービスを要求するクライアントの目には見えない。こ
のような情報の非表示は，インターネット命名機構に対する負担を軽減し，したが
ってさらに多くのサービス及びサーバーがインターネット全体で使用できるように
なるために十分拡大縮小する（scales）。」（１２頁５∼２１行）
(キ)「転送対リダイレクション
転送メカニズムはクライアントとサーバー間の仲介人の機能を果たす。これは，
クライアントが間接参照から守られているため，トランスポートプロトコルに対す
るあらゆる変更を要求しないという優位点を有する。対照的に，プロトコルは，フ
ラグシップ・ホストがクライアントに対して，そのパケットをサーバー・ホストに
リダイレクトする必要があると知らせるように修正できるであろう。これは接続指
向プロトコル（例えばTCP）のケースでは妥当である可能性があるが，コネクショ
ンレス・プロトコル（例えばUDP）のケースでは単にパケットをサーバー・ホスト
に転送する方がより費用効率が高い。この考え方は，VMTP［１］によって提供され
ている転送メカニズムでも一貫している。」（１２頁２２∼３０行）
イ引用例に開示された事項
上記アの引用例の記載によると，引用例においては以下の事項が開示されている
と認められる。
(ア)引用例の主題
引用例は昭和６３年（１９８８年）に米国で発表された論文であり，ローカルエ
リア・ネットワーク内における「イエローページ・サービス」の実施について説明
するとともに，クライアントが，インターネットの至るところからローカル・サー
バーにアクセスし，「イエローページ・サービス」を使用するために，「イエロー
ページ・サービス」を使用可能なインターネット通信プロトコルとどのように統合
することができるかを示すことを内容とするものである。
(イ)イエローページ・サービス
引用例において説明される「イエローページ・サービス」は，サーバーのセット
により実施されるものであり，各サーバーは使用可能なサービス及びサーバーに関
する情報のデータベースを維持する。
そして，「イエローページ・サービス」において，サーバーに関する情報は，サ
ーバーに関連付けられる属性（静的・動的，絶対的・相対的）としてデータベース
に記録されており，ローカルエリア・ネットワーク内のクライアントがあるサービ
スを提供するサーバーを問い合わせる際，属性のセットを送信すると，上記データ
ベースと関連付けられたイエローページ・サーバーはクライアントが指定した属性
条件のセットを満たすサーバーのアドレスがクライアントに返送される。
(ウ)転送メカニズム
クライアントがインターネットの至る所から，ローカルエリアネットワーク内に
あるイエローページ・サーバーを含むすべてのサーバーにアクセス可能とし，上記
(イ)のようなイエローページ・サービスを利用するために，転送メカニズムを採用
する。
ローカルエリア・ネットワーク内の唯一のホストが，「フラグシップ・ホスト」
として指定され，フラグシップ・ホストが提供するサービスのセット，すなわち，
ローカルエリア・ネットワークに含まれるサーバーが提供することができるサービ
スのセットをドメイン名システムに登録し，インターネット・クライアントに対し
て広告する。
クライアントが，特定のサービスを提供するサーバー（ホスト）のアドレスをド
メイン名システム（domainnamingsystem）に問い合わせると，フラグシップ・ホ
ストのアドレスが返送され，クライアントはフラグシップ・ホストに対して，例え
ば，メール・サービスなどの提供を求めるサービスのための１あるいは２以上のパ
ケットを送信する。
フラグシップ・ホストは，クライアントが求めるサービスを提供するサーバーの
うち使用可能なサーバーをランダムに１つ選択して，そのサーバーに対してパケッ
トを転送するが，フラグシップ・ホスト上で動作するロード・マネージャは，ロー
カル・サーバーの負荷のバランスをとるために，イエローページ・サーバーに定期
的に負荷の状況を問い合わせ，転送メカニズムのテーブルを適宜更新している。
転送を受けたサーバーは，パケットの送信元のアドレスをフラグシップ・ホスト
のアドレスに設定してからクライアントに対して直接応答するため，クライアント
は転送が行われていることを認識することはない。
ただし，上記の転送メカニズムは，TCPに組み込まれているため，クライアント
は，ローカルエリア・ネットワーク内においてイエローページ・サービスを利用す
る場合のように，特定の属性のセットを満足するサーバーを要求することはできな
い。
(エ)リダイレクション
転送メカニズムによると，トランスポートプロトコルを変更する必要がないが，
プロトコル自体を，フラグシップ・ホストが，クライアントに対して，そのパケッ
トをサーバー・ホストにリダイレクトするように修正することができる。
ウ引用発明
引用例に開示された上記イの事項によると，引用例には，引用発明に係る各構成
として以下の記載があると認められる。
ａインターネットの至る所からクライアントがサービスを提供するローカル・
サーバーにアクセスできるようにする方法であって，
ｂクライアントが，サービス名及びサーバーが持つべき任意の属性を指定して，
イエローページ・サービスにサーバーのアドレスを問い合わせ，
ｃイエローページ・サーバーは，使用可能なサービス及びサーバーに関する情
報のデータベースを備え，前記サービス名及びサーバーが持つべき任意の属性をサ
ーバーのアドレスにマッピングし，
ｄイエローページ・サービスは，クライアントの要求を満たす１又は２以上の
サーバーのアドレスを返送するとともに，フラグシップ・ホストが，クライアント
に対して，サーバー・ホストのアドレスを返送するとともに，そのパケットをその
サーバー・ホストにリダイレクトする必要があると知らせる
ｅクライアントが，ローカル・サーバーにアクセスする方法
エ本件発明と引用発明との相違点
本件発明の構成要件と上記ウの引用発明に係る構成を対比すると，本件発明と引
用発明とは，少なくとも，以下の点（以下「本件相違点」という。）において相違
するものと認められる。
本件発明は，「ディレクトリサーバー」が，ＲＥＤＩＲＥＣＴコマンド中の前記
ＵＲＬを前記クライアントに返送する段階を備えるのに対して，引用発明において
は，「フラグシップ・ホスト」が，クライアントに対して，サーバー・ホストのア
ドレスを返送するとともに，そのパケットをそのサーバー・ホストにリダイレクト
する必要があると知らせるものである点
したがって，本件発明が，引用発明と同一の発明であり，新規性を欠くとの被控
訴人の主張を採用することはできない。
オ本件相違点についての検討
(ア)引用発明における「リダイレクト」について
上記イで認定した引用例に開示された事項によると，引用発明の「リダイレク
ト」に関して，次のようにいうことができる。
引用例には，「イエローページ・サービス」が開示されるとともに，「インター
ネットの至る所」からのクライアントが「イエローページ・サービス」を含むロー
カルエリア・ネットワーク内のサーバーが提供するサービスを利用することができ
るようにするために，フラグシップ・ホストによってクライアントから送信された
パケットを転送して，ローカルエリア・ネットワーク内のサーバーにアクセスする
方法の技術が開示されている。
そして，「インターネットの至る所」からのクライアントは，フラグシップ・ホ
ストに対して，ローカルエリア・ネットワーク内においてイエローページ・サービ
スを利用する場合のように特定の属性のセットを満足するサーバーを要求すること
はできないとされているから，引用例におけるフラグシップ・ホストとイエローペ
ージ・サーバーを同視することができないことは明らかである。
他方，フラグシップ・ホストは，「インターネットの至る所」からのクライアン
トが求めるサービスを提供するローカルエリア・ネットワーク内の複数のサーバー
の中から，負荷が一定レベル以下のものを選択してクライアントのアクセスを確立
するために，イエローページ・サーバーに負荷の状況を定期的に問い合わせ，テー
ブルを更新するという機能を有するものである。
引用例においては，以上のような転送メカニズムによるアクセスの方法を前提と
して，プロトコルを，「フラグシップ・ホストが，クライアントに対して，そのパ
ケットをサーバー・ホストにリダイレクトする」ように修正することができるとし
ているのであり，このことは，プロトコルを修正することによって，例えば，「イ
ンターネットの至る所」からのクライアントがイエローページ・サービス（メール
・サービス）を利用したいと考えて，パケットを送信することによりイエローペー
ジ・サーバー（メール・サーバー）へのアクセスを要求した場合（ただし，上記の
とおり，特定の属性のセットを満足するサーバーを要求することはできない。），
これを受け取ったフラグシップ・ホストが，パケットを特定のイエローページ・サ
ーバー（メール・サーバー）に転送する代わりに，負荷の高くないイエローページ
・サーバー（メール・サーバー）のアドレスを指定して，直接アクセスするように
命令するようにするということを意味している。
そうすると，引用発明における「リダイレクト」は，引用例におけるアクセス方
法の技術についての上記イのような開示の中で理解されるべきものであって，あく
までも，ローカルエリア・ネットワーク内のサーバーが提供するイエローページ・
サービスなどのサービスについて，「インターネットの至る所」からのクライアン
トが利用することができるようにする場合において，同ネットワーク内の負荷を調
整するために，同ネットワーク内の唯一のホストであるフラグシップ・ホストによ
って行われるものである。
(イ)本件発明における「ＲＥＤＩＲＥＣＴコマンド」について
本件発明の「ＲＥＤＩＲＥＣＴコマンド」は，ディレクトリサーバーが，クライ
アントに対して返送するものであって，クライアントにおいて提供した記述子に対
応するＵＲＬを含み，同コマンドを受信したクライアントにおいて，同ＵＲＬを用
いて情報を要求させるものであり，その結果同ＵＲＬによって識別されたページが
クライアント側で表示される，というものである。
(ウ)相違点についての判断
上記(ア)及び(イ)によると，本件発明の「ＲＥＤＩＲＥＣＴコマンド」がクライ
アントにおいて情報ページを自動的に表示させるためのコマンドであって，ディレ
クトリサーバーによって行われるものであるのに対して，引用発明の「リダイレク
ト」は，ローカルエリア・ネットワーク内のサーバーに対する「インターネットの
至る所」からのクライアントによるアクセスを確立する方法であって，このような
クライアントに対してローカルエリア・ネットワーク内で唯一のホストとなるフラ
グシップ・ホストによって行われるものであるということができる。
そして，一貫してインターネットにおけるアクセスを念頭に置く本件発明は，ロ
ーカルエリア・ネットワーク内のサーバーとのアクセスを実現するためのフラグシ
ップ・ホストに相当するサーバーの存在及びその機能としての「リダイレクト」に
よって，その技術的課題を解決しようとするものではないのであり，本件発明の存
在を知らない当業者がこのような引用例の記載に接したとしても，フラグシップ・
ホストを必要としないインターネットのアクセス方法において，このような「リダ
イレクト」の構成を採用して，本件発明のディレクトリサーバーによる「ＲＥＤＩ
ＲＥＣＴコマンド」に係る構成とするように動機付けられるということはできない
し，引用例において，フラグシップ・ホストの機能から離れて「リダイレクト」の
機能を採用しようと動機付ける記載も存在しない。そして，仮に，引用例に開示さ
れた事項についての技術的意義を離れて，「リダイレクト」という用語の抽象的な
意義のみに基づいて本件発明の「ＲＥＤＩＲＥＣＴコマンド」と対比することを前
提とするならば，排除されるべき「後知恵」の混入を避けることはできないといわ
なければならない。
また，平成６年１２月１日発行の雑誌「ＵＮＩＸＵＳＥＲ」（乙２６）には
「他のＵＲＬに変換∼Redirect」との項目において，「Redirectに指定したパター
ンにマッチした場合は，指定したＵＲＬにリクエストがそのままフォワードされる。
サーバーが引っ越したような場合に用いる。ＵＲＬは『http://ホスト名/』から書
かなければならない。」（１３５頁左欄１９∼２３行）と記載されており，ここに
「Redirect」として紹介されている技術はいわゆる転送の技術であり，クライアン
トに別のドキュメントの位置を返送するものではないから，上記記載の技術が当業
者に周知であったと認められるとしても，引用発明にこの技術を適用することによ
って本件発明の相違点に係る構成とすることができないことは明らかである。なお，
上記記載は，本件特許出願時において，「リダイレクト」として認識される技術と
しては，本件発明における「ＲＥＤＩＲＥＣＴコマンド」とは異なる転送の技術を
意味する場合があったとさえ認定することができる。
他方，上記雑誌には，「ＣＧＩスクリプトからの出力として，ドキュメントの内
容自身を出力する以外に，別のドキュメントの位置を返すこともできる。このため
には，Location:ヘッダーを用いて，Location:目的のドキュメントのＵＲＬという
形式の情報（ヘッダー）を返せばよい。これによって，既存のドキュメントをダイ
ナミックに選択して表示できる。」（１３０ページ左欄１４∼２０行）と記載され
ており，この技術は，本件発明の「ＲＥＤＩＲＥＣＴコマンド」と同様のリダイレ
クトの技術を意味するものと認められるところ，これを前提としつつ，引用発明に
おける「フラグシップ・ホスト」と「イエローページ・サーバー」を１個のサーバ
ーと理解することができる場合には，フラグシップ・ホストとイエローページ・サ
ーバーとの間のやり取りを捨象した上，フラグシップ・ホストの機能とイエローペ
ージ・サーバーの機能を加えた別のサーバーを想定し，このようなサーバーがクラ
イアントに対してリダイレクトの命令を発すると理解することによって，本件相違
点を解消することは論理的には可能である。
しかしながら，上記イにおいて認定したとおり，引用例において，イエローペー
ジ・サービスを提供するイエローページ・サーバーと転送メカニズムを担うフラグ
シップ・ホストが別々のサーバーとして明確に書き分けられた上，インターネット
の至る所からのクライアントがフラグシップ・ホストによる転送メカニズムを通じ
てイエローページ・サーバーを利用することができることが明示的に記載されてお
り，このようなフラグシップ・ホストとイエローページ・サーバーの関係と関わり
なく，これらを統合したような別のサーバーが存在することを想定することはでき
ないのであり，仮に，フラグシップ・ホストとイエローページ・サーバーがそれぞ
れ有する機能的な構成だけを取り出して組み合せ，これを１つのサーバーとして構
成するとすれば，これはすでに引用例に記載された発明に基づく当業者の思考では
ないといわざるを得ない。
カしたがって，本件発明は，引用発明に基づいて当業者が容易に発明をするこ
とができたものということはできないから，進歩性を欠如するものとは認められな
い。
(3)小括
以上によると，本件発明に係る本件特許は特許無効審判により無効にされるべき
ものとは認められない。
３被控訴人の侵害主体性（争点７）について
(1)まず，被控訴人が本件特許権の侵害主体であるか否かについて検討する。
本件特許に係る発明の名称は「インターネットサーバーのアクセス管理およびモ
ニタシステム」とされており，上記２(1)アのとおり，本件発明に係る特許請求の
範囲の記載から，本件発明における「アクセス」が「インターネットよりなるコン
ピュータネットワークを介したクライアント」による「サーバーシステムの情報ペ
ージ」に対するものであることが明らかである上，構成要件ＢないしＦに規定され
る各段階は，本件発明において提供される「アクセス」が備える段階を特定するも
のであると解されるから，このような本件発明の実施主体は，上記のような「アク
セスを提供する方法」の実施主体であって，被控訴人方法を提供して被控訴人サー
ビスを実施する被控訴人であると解するのが相当である。
(2)この点について，被控訴人は，被控訴人方法を使用しているのはパソコン
のユーザーであって，被控訴人ではないから，被控訴人は本件発明の実施主体では
ないとして，本件特許権を侵害していないと主張するが，その主張は，要するに，
「アクセス」はクライアント（ユーザーのパソコン）によって行われる行為である
から，本件発明の実施主体は，インターネットよりなるコンピュータネットワーク
のユーザーであるクライアントであって，被控訴人ではないという趣旨に解される。
しかしながら，上記のとおり，本件発明は「アクセス」の発明ではなく，「アク
セスを提供する方法」の発明であって，具体的にクライアントによるアクセスがな
ければ本件発明に係る特許権を侵害することができないものではない。また，本件
発明に係る「アクセスを提供する方法」が提供されている限り，クライアントは，
被控訴人方法として提供されるアクセス方法の枠内において目的の情報ページにア
クセスすることができるにとどまるのであり，クライアントの主体的行為によって，
クライアントによる個別のアクセスが本件発明の技術的範囲に属するものとなった
り，ならなかったりするものではないから，クライアントの個別の行為を待って初
めて「アクセスを提供する方法」の発明である本件発明の実施行為が完成すると解
すべきでもない。
そうすると，被控訴人による「アクセスを提供する方法」が本件発明の技術的範
囲に属するのである以上，被控訴人による被控訴人方法の提供行為が本件発明の実
施行為と評価されるべきものである。
(3)そして，甲６０及び弁論の全趣旨によると，平成２１年１０月１９日の時
点において，被控訴人は現に被控訴人方法を実施していることが認められるから，
被控訴人は本件特許権を侵害する者であると認められる。
したがって，控訴人は，被控訴人に対し，特許法１００条１項に基づき，被控訴
人方法による被控訴人サービスの提供の停止を請求するとともに，同条２項に基づ
き，被控訴人サービスに供された「NLIAサーバー」の除却及び「登録情報データ
ベース」の消去を請求することができるといわなければならない。なお，控訴人は
「NLIAサーバー」及び「登録情報データベース」のいずれについても除却を求め
ているが，「NLIAサーバー」について，これが除却の対象となり得るかどうかは
同サーバーの設置・管理の状況によるものであり，共用サーバーの一部が当該サー
バーとして利用されている場合，サーバー全体の除却ではなく，当該利用部分がそ
の機能を果たさなくなるようにプログラムを削除したり消去したりすることによっ
て対応すべきものである。上記において「NLIAサーバー」の除却とは，上記のよ
うな意味を含むものである。また，「登録情報データベース」については，「デー
タベース」の性質上，除却の対象になじまないと考えられるところ，控訴人の請求
はデータベースの機能を喪失させることを求めるものと解されるから，上記のとお
り，同データベースの消去を認めるのが相当である。
４損害の発生及び額（争点８）について
(1)控訴人は，被控訴人が，過去において本件発明を実施していただけでなく，
現在においても実施しているものであり，被控訴人サービスの提供によって被控訴
人が現実に売上げを計上していないとしても，控訴人に損害が発生していることに
変わりはないとして，被控訴人による登録件数に従って本件発明の実施に対し受け
るべき金銭の額に相当する額の金銭が控訴人の受けた損害の額であると主張する。
(2)控訴人が本件において適用があると主張する特許法１０２条３項は，「特
許権者…は，故意又は過失により自己の特許権…を侵害した者に対し，その特許発
明の実施に対し受けるべき金銭の額に相当する額の金銭を，自己が受けた損害の額
としてその賠償を請求することができる。」と規定するところ，同規定は，特許権
侵害に係る損害の額の立証が容易でないことにかんがみて設けられたものであり，
特許権の侵害行為によって特許権者に何らかの損害が発生していることを前提とし
て，「特許発明の実施に対し受けるべき金銭の額に相当する額」をもって，自己が
受けた損害の額として損害賠償を請求することができるとした規定である。
(3)そして，特許法１０２条３項にいう「特許発明の実施に対し受けるべき金
銭」として，例えば，特許発明の実施品の販売に対する売上金に基づいて算定され
る実施料相当額を想定することができるところ，本件特許は「アクセスを提供する
方法」の発明についてのものであり，本件発明の実施は，構成要件を充足するアク
セス方法の提供によって行われるが，甲３の１ないし甲１２及び甲２０の１ないし
甲２７の２によると，本件発明の実施者は，アクセスの提供自体又はアクセスの利
用自体によって金銭を受けるものではなく，アクセス方法によって検索される対象
となり得るキーワードの登録者が支払う登録料金を受領するというのである。
(4)ところで，被控訴人方法の登録件数が１３万６８２６件であることには当
事者間に争いはないところ，甲７の３の１及び２並びに甲２２の１の１によると，
これらの登録は，キーワードの実勢調査を行うためのマーケティングデータ収集を
目的とする「TestOperation」を経て，登録料金が発生する商用サービス開始期間
前に商標権者からビジネス・キーワードアドレスの登録申請を受け付け，優先登録
権を与えるための「SunriseOperation」における登録であって，いずれも登録料
金の支払を伴わないものであり，乙３７，３８及び弁論の全趣旨によると，被控訴
人は本件紛争の発生に伴って，その後に予定されていた商用サービスである
「CommercialOperation」への移行を行っていないものと認められるから，被控訴
人は，被控訴人サービスへの登録について登録者から金銭を受領しているというこ
とはできないし，ほかに被控訴人が本件発明の実施に相当する被控訴人サービスの
提供に関して金銭を受領したことを示す証拠はない。
他方，上記「SunriseOperation」における登録を無料としているのは，検索の
可能性が高い商標権者については，サービスの利用率を高めるために無料で登録を
させる意味があると考えての措置であると認められるから，一般のユーザーによる
有料のキーワード登録を加えて被控訴人サービスを開始するための前提となるもの
である。
(5)そして，特許権者が特許発明の実施を許諾する場合において，特許権者と
被許諾者との間に特許発明の実施を無償で許諾することがあり得るような特別の関
係があるような場合であれば格別，特許権の侵害行為に該当する特許発明の実施に
ついて，特許権者が無償でこれを許諾することは通常考えられないところ，被控訴
人方法の実施が本件特許権を侵害するとして同方法の差止め及び損害賠償を求める
本件において，互いに争っている控訴人と被控訴人との間に，上記のような特別の
関係があるといえないことは明らかであり，被控訴人方法の実施によって，控訴人
には上記の意味における損害が発生しているといわざるを得ない。
(6)しかしながら，上記(3)及び(4)のような被控訴人方法の実施に関する実情
に照らすと，控訴人の損害額を立証するために必要な事実を立証することは，その
性質上極めて困難であるというべきであるところ，上記のとおり，被控訴人方法の
登録件数は約１４万件に上っていること，これらはいずれも無料の登録に係るもの
ではあるが，そのうち「SunriseOperation」に係る登録については，被控訴人サ
ービスを開始するための前提となるものであると理解すべきことのほか，甲１０の
２によると，被控訴人は，被控訴人方法を「CommercialOperation」に移行させた
後は，キーワード登録１つ当たり１年間３万１５００円の登録料を徴収する予定で
あったと認められること，さらに，前記第２の３(3)ア及び甲６０によると，被控
訴人は，遅くとも平成１８年中にはサービス開始に向けた前提条件を整えており，
ユーザーによって被控訴人サービスを利用することができる状態が作出されていた
と認められることを総合的に考慮すると，控訴人の損害額は１４００万円を下らな
いと解するのが相当である。
５結論
以上の次第であるから，原判決を，控訴人の請求のうち，被控訴人方法を利用し
た被控訴人サービスの差止め並びに同サービスに供された「NLIAサーバー」及び
「登録情報データベース」の除却等を求める請求については，いずれもこれを認容
し，損害賠償を求める請求については，前記１４００万円及び遅延損害金の支払を
求める限度でこれを認容するとおりに変更することとして，民事訴訟法２５９条１
項を適用して主文のとおり判決する。
知的財産高等裁判所第４部
裁判長裁判官滝澤孝臣
裁判官高部眞規子
裁判官杜下弘記
（別紙）
当事者目録
控訴人インターネットナンバー株式会社
同訴訟代理人弁護士熊倉禎男
飯田圭
奥村直樹
同補佐人弁理士西島孝喜
中村佳正
被控訴人株式会社ＮＥＴＰＩＡ
同訴訟代理人弁護士北村行夫
亀井弘泰
大井法子
杉浦尚子
雪丸真吾
芹澤繁
大藏隆子
村上弓恵
政岡史郎
吉田朋
杉田禎治
近藤美智子
同補佐人弁理士樋口盛之助
原慎一郎
（別紙)
サービス目録
サービス名：「JAddress」
サービスに係る方法の概要：別紙構成一覧記載の構成を備えた，インターネット
に接続されたパソコンのユーザーに対し，当該パソコンのウェブブラウザのアドレ
スバーに任意の文字を記述することで目的のウェブページのＵＲＬを取得させ，当
該ウェブページへのアクセスを提供する「JapanNLIA(NativeLanguageInternet
Address)System」に係る方法。
以上
（別紙）
構成一覧
１サーバー方式
Ａ’インターネットよりなるコンピュータネットワークを介してクライアント
が情報ページに対してアクセスする際，目的の情報ページのＵＲＬを取得する方法
であって，
Ｂ’ユーザーがクライアントＰＣのウェブブラウザのアドレスバーに任意の日
本語インターネットアドレス(JAddress)を入力して(1)，同日本語インターネットア
ドレス(2)(正規ＵＲＬ)又は(2’)(非正規ＵＲＬ)を予めプログラム①の付加された
ＤＮＳサーバー(NLIANameServer)に提供する段階(2)又は(2’)と，
Ｃ’−ⅠNLIANameServer内において，付加プログラム①が，クライアントＰＣ
から送信された日本語インターネットアドレスが正規ＵＲＬであるか否かを選別し
(3)，正規ＵＲＬの場合(4)，ＤＮＳサーバーの機能によって対応するＩＰアドレス
をクライアントＰＣに送り返し(9)，
Ｃ’−Ⅱ
正規ＵＲＬでない場合，「NLIANameServer」から「NLIAサーバー」へとユーザ
ーが入力した日本語インターネットアドレスを送信する段階と，
Ｃ’−Ⅲ日本語インターネットアドレスの送信を受けた「NLIAサーバー」が，
当該日本語インターネットアドレスに対応するＵＲＬを登録情報データベースから
取得する段階(6)と，
Ｄ’「NLIAサーバー」が，当該ＵＲＬを，ＲＥＤＩＲＥＣＴコマンドを利用し
て，クライアントＰＣに送信する段階(7)と，
Ｅ’クライアントＰＣが，取得したＵＲＬを一旦ＤＮＳサーバーを経由して(8)，
対応するＩＰアドレスを取得し(9)，目的の情報ページの情報を要求する段階(10)と，
Ｆ’クライアントＰＣが，目的の情報ページを表示する段階と(11)，
Ｇ’以上の段階を備える情報ページのＵＲＬを取得する方法
２プラグイン方式
Ａ”インターネットよりなるコンピュータネットワークを介してクライアント
が情報ページに対してアクセスする際，目的の情報ページのＵＲＬを取得する方法
であって，
Ｂ”−ⅠユーザーがクライアントＰＣのウェブブラウザのアドレスバーに任意
の日本語インターネットアドレスを入力し(1)，予めクライアントに付加されたプロ
グラム②が，同日本語インターネットアドレス(2)(正規ＵＲＬ)又は(2’)(非正規Ｕ
ＲＬ)を正規ＵＲＬであるか否かを選別する段階(3)と，
Ｂ”−Ⅱ入力された日本語インターネットアドレスが正規ＵＲＬの場合(2)，ブ
ラウザの機能によって当該正規ＵＲＬをＤＮＳサーバーに送信してＤＮＳサーバー
の機能によって対応するＩＰアドレスをクライアントに送り返し(4)(9)，
正規ＵＲＬでない場合(2’)，当該日本語インターネットアドレスをNLIAサーバ
ーへのＵＲＬ形式に変更した上，ブラウザの機能によって当該変更したＵＲＬ(2”)
をＤＮＳサーバーに送信して，ＤＮＳサーバーの機能によってNLIAサーバーのＩＰ
アドレスをクライアントＰＣに送り返す段階(4’)と，
Ｂ”−ⅢクライアントＰＣが，取得したＩＰアドレスのNLIAサーバーに向けて，
当初ユーザーが入力した日本語インターネットアドレスを問い合わせる段階(5)と，
Ｃ”問い合わせを受けたNLIAサーバーが，当該日本語インターネットアドレス
に対応するＵＲＬを登録情報データベースから取得する段階(6)と，
Ｄ”NLIAサーバーが，当該ＵＲＬを，ＲＥＤＩＲＥＣＴコマンドを利用して，
クライアントＰＣに送信する段階(7)と，
Ｅ”クライアントＰＣが，取得したＵＲＬを一旦ＤＮＳサーバーを経由して(8)，
対応するＩＰアドレスを取得し(9)，目的の情報ページの情報を要求する段階(10)と，
Ｆ”クライアントＰＣが，目的の情報ページを表示する段階と(11)，
Ｇ”以上の段階を備える情報ページのＵＲＬを取得する方法
以上
（別紙）
特許請求の範囲の記載
１第１回補正後の請求項１の記載（ただし，下線部分は補正箇所である。）
インターネットよりなるコンピュータネットワークを介したクライアントからサ
ーバーシステムへの情報ページに対するアクセスを提供する方法であって，前記ク
ライアントにおいて記述子を提供する段階と，ディレクトリサーバーが，前記記述
子を前記ディレクトリサーバーに存在する翻訳データベースを用いてＵＲＬにマッ
ピングする段階と，前記ディレクトリサーバーが，ＲＥＤＩＲＥＣＴコマンド中の
前記ＵＲＬを前記クライアントに返送して前記クライアントに前記ＵＲＬを用いて
情報を要求させる段階と，前記ＵＲＬにより識別されたページを前記クライアント
側で表示する段階とを備えた情報ページに対するアクセス方法。
２第２回補正後の請求項１の記載（ただし，下線部分は補正箇所である。）
インターネットよりなるコンピュータネットワークを介したクライアントからサ
ーバーシステムへの情報ページに対するアクセスを提供する方法であって，前記ク
ライアントにおいて記述子を提供する段階と，ディレクトリサーバーが，前記記述
子を前記ディレクトリサーバーに存在する翻訳データベースを用いてＵＲＬにマッ
ピングする段階と，前記ディレクトリサーバーが，ＲＥＤＩＲＥＣＴコマンド中の
前記ＵＲＬを前記クライアントに返送する段階と，前記クライアントに前記ＵＲＬ
を用いて情報を要求させる段階と，前記ＵＲＬにより識別されたページを前記クラ
イアント側で表示する段階とを備えた情報ページに対するアクセス方法。
３本件訂正後の請求項１の記載（ただし，下線部分は訂正箇所である。）
インターネットよりなるコンピュータネットワークを介したクライアントからサ
ーバーシステムへの情報ページに対するアクセスを提供する方法であって，前記ク
ライアントにおいて単一の目標ＵＲＬに対応する記述子を提供する段階と，ディレ
クトリサーバーが，前記記述子を前記ディレクトリサーバーに存在する翻訳データ
ベースを用いて前記ＵＲＬにマッピングする段階と，前記ディレクトリサーバーが，
ＲＥＤＩＲＥＣＴコマンド中の前記ＵＲＬを前記クライアントに返送する段階と，
前記クライアントに前記ＵＲＬを用いて情報を自動的に要求させる段階と，前記Ｕ
ＲＬにより識別されたページを前記クライアント側で表示する段階とを備えた情報
ページに対するアクセス方法。

戻る