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


追加

関連審決 無効2007-800243
関連ワード 方法の発明 /  使用方法 /  新規性 /  29条1項3号 /  電気通信回線 /  インターネット /  アクセス /  進歩性(29条2項) /  相違点の認定 /  寄せ集め /  周知技術 /  公知技術 /  技術常識 /  発明の詳細な説明 /  優先権 /  分割出願 /  警告 /  優先日 /  出願経過 /  容易に想到(容易想到性) /  特許発明 /  実施 /  間接侵害 /  構成要件 /  方法の使用 /  のみ用いる /  課題解決に不可欠(課題の解決に不可欠) /  業として /  具体的態様 /  差止請求(差止) /  侵害 /  不法行為(民法709条) /  同意 /  混同 /  拒絶理由通知 /  請求の範囲 /  減縮 /  変更 /  釈明 /  訂正要件 / 
元本PDF 裁判所収録の全文PDFを見る pdf
事件 平成 19年 (ワ) 2352号 特許権侵害差止等請求事件
東京都渋谷区＜以下略＞
原告 インターネットナンバー株式会社
同訴訟代理人弁護士熊倉禎男
同 飯田圭
同 奥村直樹
同補佐人弁理士中村佳正 東京都千代田区＜以下略＞
被告 株式会社ＮＥＴＰＩＡ
同訴訟代理人弁護士北村行夫
同 亀井弘泰
同 大井法子
同 杉浦尚子
同 雪丸真吾
同 芹澤繁
同 大藏隆子
同 村上弓恵
同 吉田朋
同 大島忠尚
同 杉田禎浩
同 近藤美智子
同補佐人弁理士樋口盛之助
同 原慎一郎
裁判所 東京地方裁判所
判決言渡日 2008/10/17
権利種別 特許権
訴訟類型 民事訴訟
主文 １原告の請求を棄却する。
２訴訟費用は原告の負担とする。
事実及び理由
全容
第1請求1被告は 「サービス」を提供してはならない。 ,JAddress2被告は 「」における「サーバー」及び「登録情報デー , Japan NLIA SystemNLIAタベース」を除却せよ。
3被告は,原告に対し,9170万円及びこれに対する平成19年2月15日から支払済みまで年5分の割合による金員を支払え。
第2事案の概要本件は 「インターネットサーバーのアクセス管理およびモニタシステム」につ ,いての特許を有する原告が,被告が実施する「サービス」という日本語イJAddressンターネットアドレスに関するサービスは同特許権を侵害すると主張して,特許法100条1項に基づく被告のサービスの差止め及び同条2項に基づく被告のサービスに供された「サーバー」等の除却,並びに民法709条,特許法102条NLIA2項に基づく損害賠償及び遅延損害金の支払を求めた事件である。
1前提事実( )当事者1ア原告は,インターネットを利用するシステムの開発・販売及びインターネットを利用した情報提供サービス業などを業とする株式会社である。
原告は,後記( )アの本件発明を実施して,インターネット等の利用者がパソコ2ンのウェブブラウザのアドレスバー等に電話番号等の「インターネットナンバー」を入力することで特定のウェブサイトにアクセスできるようにするサービスを提供している。
イ(ｱ)被告は,コンピュータシステムにおけるデータベースの構築・販売,情報処理サービス業及び情報提供サービス業,インターネットでの広告業務及び広告代理業,インターネットを利用する情報システム及び通信ネットワークの企画・設計・運用に関する受託等を業とする株式会社である。
(ｲ)被告は 韓国法人である株式会社ネッピアダッコム(以下 ネッピア という ) , 「」。
の関連日本法人である。
(以上,甲11,争いのない事実)( )本件特許権2ア原告は,次の特許権を有している。以下「本件特許権」といい,請求項1の特許発明を「本件発明 ,本件発明に係る特許を「本件特許 ,本件特許権に係 」 」る出願を「本件出願」とそれぞれいう。また,本件特許権に係る明細書及び図面を「本件明細書」といい,その特許公報(甲2)を別紙1として添付する。
特許番号第3762882号発明の名称インターネットサーバーのアクセス管理およびモニタシステム出願日平成8年6月3日(特願平9-503084(乙2)。優先権主張平成7年6月7日アメリカ合衆国)分割出願日平成13年7月9日(特願2001-208296)登録日平成18年1月20日特許請求の範囲(請求項1)本件明細書(別紙1)の該当欄に記載のとおり。
(争いのない事実)イ構成要件の分説本件発明を分説すると,次のとおりである(以下,各構成要件を「構成要件A」のようにいう。)。
Aインターネットよりなるコンピュータネットワークを介したクライアントからサーバーシステムへの情報ページに対するアクセスを提供する方法であって,B前記クライアントにおいて記述子を提供する段階と,Cディレクトリサーバーが,前記記述子を前記ディレクトリサーバーに存在する翻訳データベースを用いてURLにマッピングする段階と,D前記ディレクトリサーバーが,REDIRECTコマンド中の前記URLを前記クライアントに返送する段階と,E前記クライアントに前記URLを用いて情報を要求させる段階と,F前記URLにより識別されたページを前記クライアント側で表示する段階とGを備えた情報ページに対するアクセス方法。
(争いのない事実)ウ出願経過(ｱ)第1回拒絶理由通知特許庁審査官は,平成17年4月15日付けで,?@本件特許権の当時の請求項1ないし10に係る出願について,各動作の主体がどのハードウェア手段であるかが不明である,?A請求項3の「REDIRECTコマンド中のURLをクライアントに返送してクライアントにURLを用いて情報を要求させるサーバーシステムにト」 , ランザクションデータベースが常駐する なる記載の意味が不明である等の理由で拒絶理由を通知した。
(ｲ)第1回補正aこれを受けて,原告は,?@の点について,平成17年6月20日,当時の請求項1,3及び10を削除し,当時の請求項2に当時の請求項3及び10を併合して補正後の請求項1を次のとおりとした。
「 インターネットよりなるコンピュータ]ネットワークを介したクライアント [からサーバーシステムへの情報ページに対するアクセスを提供する方法であって,前記クライアント[において]記述子を提供する段階と [ディレクトリサーバー ,が ]前記記述子を[前記ディレクトリサーバーに存在する]翻訳データベースを ,用いて[URL]にマッピングする段階と [前記ディレクトリサーバーが,RE ,DIRECTコマンド中の前記URLを前記クライアントに返送して前記クライアントに前記URLを用いて情報を要求させる段階]と,前記[URL]により識別されたページを前記クライアント側で表示する段階とを備えた情報ページに対するアクセス方法」([]部分が補正部分)原告は,同日付けの意見書において,上記補正の理由について,次のとおり主張した。
「補正前の請求項1〜10に係る発明の,各動作の主体がどのハードウェア手段であるのかが不明である,に対しては,前述の補正後の請求項1のように補正して対処し,各動作の主体のハードウェア手段を明確にしております。すなわち,記述子を提供する段階はクライアントが行い,記述子をディレクトリサーバーに存在する翻訳データベースを用いてURLにマッピングする段階はディレクトリサーバーが行い,REDIRECTコマンド中のURLをクライアントに返送してクライアントにURLを用いて情報を要求させる段階はディレクトリサーバーが行い,UR。」 Lにより識別されたページを表示する段階はクライアントが行うものであります(2頁下から19行〜12行),「本願発明では,このような長く複雑なURLに代えて,このURLに対応して,, , 誰でも簡単かつ容易に入力できる電話番号 会社名 製品名などを入力するだけで目標とするURLのウェブサイトへアクセスできるようにしたものであります 」。
(1頁下から3行ないし2頁1行)b原告は,?Aの点について,同年6月20日付け意見書において 「…補正 ,前の請求項3の内容を明確にして,補正後の請求項1に併合しております。すなわち,ディレクトリサーバーが,REDIRECTコマンド中のURLをクライアントに返送してクライアントにURLを用いて情報を要求させるものであり … (2 , 」頁下から11行ないし8行目)との意見を述べ,同日付けの手続補正書において,補正後の請求項1の記載を「前記ディレクトリサーバーが,REDIRECTコマンド中の前記URLを前記クライアントに返送して前記クライアントに前記URLを用いて情報を要求させる段階と 」とした。,(ｳ)第2回拒絶理由通知特許庁審査官は,平成17年9月28日付けで,本件特許権の上記(ｲ)の第1回補正後の請求項1ないし7に係る出願について,進歩性欠如を理由とする拒絶理由を通知した。
(ｴ)第2回補正aこれを受けて,原告は,平成17年12月5日,請求項1中の「前記ディレクトリサーバーが,REDIRECTコマンド中の前記URLを前記クライアントに返送して前記クライアントに前記URLを用いて情報を要求させる段階と 」,を「前記ディレクトリサーバーが,REDIRECTコマンド中の前記URLを前記クライアントに返送する段階と,前記クライアントに前記URLを用いて情報を要求させる段階と 」に補正した。 ,原告は,同日付け意見書において,補正の理由について 「…1つの段階から, ,URLの返送段階と,そのURLを用いた情報要求段階との2つの段階に分けて表現し,記載の明瞭化を図りました 」(1頁下から17行〜16行)と主張した。 。
bまた,原告は,同意見書において,本件発明の特徴について 「本願発明 ,は,インターネット上において,ユーザが電話番号,会社名,製品名等を用いて商業サービスサイトにアクセスできる,インターネットよりなるコンピュータネットワークを介したクライアントからサーバーシステムへの情報ページに対するアクセス方法に関する技術であります すなわち 本願発明が適用するようなインターネッ 。,トの技術分野では,ウェブサイトへアクセスする際に,長く複雑なURLを入力する必要があるが,本願発明では,このような長く複雑なURLに代えて,このURLに対応して誰でも簡単かつ容易に入力できる電話番号,会社名,製品名等を入力するだけで,目標とするURLのウェブサイトへアクセスできるようにしたものであります 」(1頁下から6行〜2頁3行)と説明している。 。
c特許庁審査官は,平成18年1月5日,上記補正内容で特許査定した。
(以上,争いのない事実)エ無効審判等(ｱ)被告は,平成19年10月31日付け審判請求書(乙31)により,本件特許権(請求項1ないし7)について,無効審判を請求した(無効2007-800243)。
(ｲ)原告は,平成20年1月23日付け訂正請求書(甲42)により,本件明細書の特許請求の範囲の請求項1ないし7について,請求項1を次のとおり訂正する等の訂正を請求した(以下「本件訂正」といい,訂正後の本件発明を「本件訂正発明」という。理解の便宜のために,構成要件の分説の形で記載する。)。
「Aインターネットよりなるコンピュータネットワークを介したクライアントからサーバーシステムへの情報ページに対するアクセスを提供する方法であって,B前記クライアントにおいて[単一の目標URLに対応する]記述子を提供する段階と,Cディレクトリサーバーが,前記記述子を前記ディレクトリサーバーに存在する翻訳データベースを用いて[前記]URLにマッピングする段階と,D前記ディレクトリサーバーが,REDIRECTコマンド中の前記URLを前記クライアントに返送する段階と,E前記クライアントに前記URLを用いて情報を[自動的に]要求させる段階と,F前記URLにより識別されたページを前記クライアント側で表示する段階とGを備えた情報ページに対するアクセス方法(部分が訂正部分である) 。」 []。
(ｳ)特許庁審判官は,平成20年6月26日,本件訂正を認めたが,訂正後の請求項1ないし7の発明は 進歩性欠如を理由として無効とする旨の審決をした(乙 ,32)。
(ｴ)原告は,知的財産高等裁判所に対し,上記無効審決の取消しを求める訴えを提起した。
(以上,争いのない事実)( )被告の行為3ア被告サービスの開始被告は,平成18年2月ころ,その名称を「サービス」とする日本語インJAddressターネットアドレスに関するサービス(以下「被告サービス」といい,このサービスで採用されている方法を「被告方法」という。)を開設し,サイト運営者のトライアル登Test Operation Sunrise 録サービスを開始し 同年9月5日 その優先登録サービス 「」,,「」を開始した。
Operation(争いのない事実)イ被告方法(ｱ)被告サービスの概略a「 ()システム」は,インターネットにNative Language Internet AddressNLIA接続されたパソコンのユーザーに対し,当該パソコン(クライアントPC)のウェブブラウザ(インターネット上のウェブページを閲覧するためのアプリケーションソフト。
「ブラウザ」ともいう。)のアドレスバーに任意の文字を記述することで目的のウェブページのURL(又はIPアドレス)を取得することを可能とするソフトウェアを提供するものである。
被告サービスは,この「 ()システム」を日本にNative Language Internet Address NLIAおいて展開するものである。
b被告サービスの提供方法には,以下の2種類がある。
?@サーバー方式被告のDNS(:IPアドレスとドメインネームとを対応させるDomain Name System既存のシステム)サーバー内に付加したプログラムを利用する方式この方式は,ユーザーがクライアントPCにプログラムをプラグインする必要がない点において,後記?Aの方式よりも進化した方式である。
?Aプラグイン方式?@と同じ作用のプログラムをクライアントPCにプラグインする方式(争いのない事実)(ｲ)被告方法の構成被告方法の構成は,別紙2被告方法説明書記載のとおりであり,サーバー方式の構成C’-?U以外の構成は,当事者間に争いがない。
ウ構成要件の一部充足被告方法は,本件発明の構成要件A,D及びGを充足する。
(弁論の全趣旨)2争点( )争点1構成要件Bの充足1( )争点2構成要件Cの充足2( )争点3構成要件Eの充足3( )争点4構成要件Fの充足4( )争点5本件特許権の無効理由の存否 5ア争点5-1開示義務違反(特許法36条4項,6項1号,2号)イ争点5-2新規性の欠如ウ争点5-3進歩性の欠如( )争点6本件訂正による無効理由の解消の存否6ア争点6-1訂正要件及び充足イ争点6-2進歩性の欠如等( )争点7主体性7( )争点8損害の発生及び額83争点に関する当事者の主張( )争点1(構成要件B「前記クライアントにおいて記述子を提供する段階と」1の充足)(原告の主張)ア特許請求の範囲の解釈(ｱ)「クライアントにおいて…提供する」a解釈構成要件Bの「クライアントにおいて…提供する」とは,ハードウェア手段であるクライアントPC等が記述子を送信することを意味する。
記述子がディレクトリサーバーに受信される経路については,何ら限定はなく,アドレスバーに記入された記述子をDNSサーバーを介してディレクトリサーバーに送信する場合を含む。
b「クライアントにおいて」についての根拠( )本件明細書の記載a本件明細書の発明の詳細な説明には,次の記載がある。
「本発明は,クライアントからサーバーへのネットワークを介したサービス要求を処理する方法に関する 」(【0001】), 。
「インターネットサーバーは,ホスト上のファイルを要求するあらゆるコンピュータに情報を配布することができる。このような要求をするコンピュータは“クライアント”として知られ,これはインターネットに接続されたワークステーション,掲示板システムまたは家庭用パーソナルコンピュータ(PC))であり得る 」(【0003】 。
2頁26行〜29行)( )出願経過b前提事実( )ウ(ｲ)のとおり,原告は,平成17年4月15日付けの第1回拒絶理由2通知の「各動作の主体がどのハードウェア手段であるかが不明である」という拒絶理由に対し,同年6月20日付けの意見書において 「…記述子を提供する段階はクライ ,アントが行い…」との意見を述べた上,同日付けの手続補正書において,請求項1の記載を「クライアントにおいて記述子を提供する」と補正し,特許査定された。
( ) まとめc上記( )及び( )によると,構成要件B中の「クライアントにおいて」は,送信の主 ab体が「クライアントPC等」であることを意味する。
( )米国特許出願d後記被告の主張ア(ｱ)b( )一及び二は認め,三は否認する。 dc「提供する」についての根拠( )特許請求の範囲の記載a,, , 構成要件B及びCは 記述子について これを提供するのがクライアントでありこれをURLにマッピングするのがディレクトリサーバーであることを規定しているが,クライアントへの記述子の入力方法や記述子がディレクトリサーバーに受信される経路については,何ら限定していない。
( )本件明細書の記載b一本件明細書には,次の記載がある。
「ユーザはまた,他のウェブページにジャンプするため,既知のURLをウェブページ上のコマンドラインに直接書き込むことにより指定することができる( 0。」【006】3頁24行〜26行)「本発明は,ネットワークを介したクライアントからサーバーへのサービス要求を処理する方法に関する。とりわけ本発明は,ワールドワイドウェブ(ウェブ)のようなHTTP(ハイパーテキスト転送プロトコル)環境におけるクライアント要求を処理することに適する 」(【0011】4頁15行〜18行) 。
「好ましい構成では,クライアント要求は(URL)によりUniform Resource Locatorウェブブラウザから作られる 」(【0012】4頁26行〜27行) 。
二本件明細書の上記記載からすると 本件発明はクライアント要求 がウェ ,,「」ブブラウザ上で処理されることを当然に想定しており 「アドレスバー」に記述子を入 ,力する方法を排除しているものではない。
( )周知技術c一本件出願当時,ウェブブラウザ及びDNS自体は,周知技術であった。
二したがって,クライアントのウェブブラウザのアドレスバーへ記述子が入力され,そのままだと当該記述子が直接的にはDNSに送信されるような場合も想定されている。
三そのような場合に,クライアントにおいて記述子を認識させて直接ディレクトリサーバーに送信させるようにするか,DNSに記述子を認識させてディレクトリサーバーに送信させるようにするか,DNS兼ディレクトリサーバーに記述子を認識させて処理するようにするかは,当業者において適宜選択する設計事項にすぎない。
( )「NOTFOUND」d一本件明細書の【0041】には,一実施例として,NUMBERが入力された場合の処理について 「ブラウザは次いでNUMBERがユーザにより指定 ,http://directory.net/NUMBER された電話番号,またはその他の識別子である,書式“”のURLを構成する 」と記載されている。 。
二この記載は,NUMBERがHTTPプロトコルによりURLを構成して通信することを明らかにしており,この場合「NOTFOUND」が返されることはない。
三本件出願当時,という識別子は,URLにおいて使用されるプロトhttp://, , コルに関する識別子であり URL内において規定されているプロトコルとしてはHTTP以外に,や等多数のプロトコルが存在し,URLの先頭にコンftpgopherピュータプログラムにおいて判別可能な文字列として記述し,コンピュータプログラムにおいてはこれらを文字解析した上で適宜必要なプロトコルを選択して通信を行うように制御させる規約となっていたことは周知であった。
四したがって,上記に規定された体系()以外に,会社名,製品名,schemes電話番等等の記述子が入力された場合にも,何らかの体系を定めてDNSから「NOTFOUND」が返されないように処理を行うようにすること自体は,当業者であれば技術常識に基づき適宜なし得た事項である。
( ) 「提供する」の通常の意味等e一前提事実( )ウ(ｲ)のとおり,原告は,平成17年6月20日付け意見書にお 2いて 「補正前の請求項1〜10に係る発明の,各動作の主体がどのハードウェア ,手段であるのかが不明である,に対しては,前述の補正後の請求項1のように補正して対処し,各動作の主体のハードウェア手段を明確にしております。すなわち,記述子を提供する段階はクライアントが行い…」と述べた上,同日付けの手続補正書において,補正後の請求項1を「前記クライアントにおいて記述子を提供する段階と 」とし,特許査定されている。 ,二「提供」という用語は,プログラム等の送信行為を意味する(特許法2条3項1号「電気通信回線を通じた提供 ,商標法2条2項8号「電磁的方法により提供す 」る」等)。
三本件明細書の【0045】には 「サーバー602はウェブページをクライ ,アントに返送して,要求されたドキュメントに対して適切なリンクを提供する」として 「提供」の用語が送信行為を意味するものとして記載されている。 ,このように,本件明細書では 「提供」と「送信」とを厳密に区別してない。 ,四したがって 「記述子を提供する」段階が,動作の主体としてのハードウェ ,ア手段であるクライアントにおいてされるものである以上 「提供」の用語は,クライ ,アントが記述子を送信することを意味する。
(ｲ)「記述子」a解釈構成要件B中の「記述子」とは,電話番号,会社名,製品名等のURLとは異なる数字あるいは言葉であり,これに対応し,目標情報ページを識別する特定かつ唯一のURLへとマッピングされるものを意味する。
b根拠( )特許請求の範囲の記載a一構成要件Cでは 「ディレクトリサーバーが,前記記述子を前記ディレ ,クトリサーバーに存在する翻訳データベースを用いてURLにマッピングする」と記載されている。
二このように 「記述子」と「URL」とは,明確に区別されている。 ,( )発明の詳細な説明の記載b一本件明細書の【0047】には,発明の効果として 「…ユーザはUR ,Lについて知る必要がない 」と記載されている。 。
二仮に 「記述子」が「URL」を含むとすると,上記の本件発明の効果 ,を奏することができない。
( )出願経過c前提事実( )ウ(ｳ)及び(ｴ)のとおり,原告は,平成17年12月5日付け意見書 2で 「本願発明では,このような長く複雑なURLに代えて,このURLに対応し ,,, , て誰でも簡単かつ容易に入力できる電話番号 会社名 製品名等を入力するだけで目標とするURLのウェブサイトへアクセスできるようにしたものであります 」。
と主張し,その後 「記述子」については特に補正することなく特許査定された。 ,イ充足(ｱ)サーバー方式の場合a被告方法の構成B’によれば,被告方法は 「クライアント」に相当する「ク ,ライアントPC」から「ディレクトリサーバー」(構成要件C)の一部に相当する「DNSサーバー」に対し 「記述子」に相当する「日本語インターネットアドレス( )(正 ,2規)又は( ’)(非正規)」を「提供する」ことに相当する「送信する」ことを URL2URLしているので,構成要件Bを充足する。
bまた,仮に,クライアントからディレクトリサーバーへの送信方法が,直接送信する場合に限定されるとしても,被告方法は 「クライアント」に相当する「クラ ,」「」「」 イアントPC から ディレクトリサーバー (構成要件C)に相当するサーバーNLIAに対し,当初の日本語インターネットアドレスを直接送信する段階( )を備えているか 5ら,構成要件Bを充足する。
(ｲ)プラグイン方式の場合a被告方法の構成B”-?Vは,構成要件Bを充足する。
b非正規URLの場合,当該記述子を「サーバー」へのURL形式に変更NLIAした上,ブラウザの機能によって当該変更したURL( ”)をDNSサーバーに送信し 2てDNSサーバーの機能によって「サーバー」のIPアドレスをクライアントに NLIA送り返す段階( ’)という構成が行われているが,構成要件Bは,送信の前段階として 4,, クライアントがどのような動作を行うかについて何も規定していないから この点は構成要件Bを充足すると認めることの妨げとならない。
(被告の主張)ア特許請求の範囲の解釈(ｱ)「クライアントにおいて…提供する」a解釈原告の主張ア(ｱ)aは争う。
上記構成要件は,ユーザーがクライアントPC等において記述子を入力することを意味する。
また提供する が送信することを意味するとしても クライアントPCの ア ,「」 ,「ドレスバー」に記入された記述子をディレクトリサーバーに送信する場合を含まない。
b「クライアントにおいて」についての根拠( )本件明細書の記載a同b( )は認める。 a( )出願経過b同b( )は認める。 b( ) まとめc同b( )は否認する。 c( )米国特許出願d一本件発明は,米国出願における当初の請求項5に当たるが,そこには「 」と記載されている(乙6の1の1頁下から3行providing a descriptor at the client目)。
providing a descriptor comprising a telephone二補正後の請求項でも,同様に「」と記載されている(乙7の1?F1頁下から2行〜最終行)。
number at the client三したがって,構成要件Bの「クライアントにおいて」は 「クライアン ,トPCで」と,記述子を提供する場所を表すもの解するほかはない。
c「提供する」についての根拠( )特許請求の範囲の記載a同c( )は否認する。 a( )本件明細書の記載b同c( )のうち,一は認め,二は否認する。b( )周知技術c同c( )のうち,一は認め,二,三は否認する。c( )「NOTFOUND」d同c( )のうち,一は認め,その余は否認する。dアドレスバーを使用する場合は,記述子が正規のURLか否かの選別を行う段階が必要であるが,本件発明には,そのような段階を想定した記述はない。
原告主張のように「クライアントPCが送信する」と解すると,構成要件Cの記載及び本件明細書【0041】の「ディレクトリサーバー602に連絡し,メッセージ1で要求されたNUMBERを送信する」との記載からすると,クライアントがディレクトリサーバーに向けて直接「送信する」と解するほかはないが,原告は,受信経路は限定されていないと主張しており,矛盾している。
したがって,構成要件Bの「記述子を提供する」とは,クライアントPCの「アドレスバー」に記入された記述子をディレクトリサーバーに送信する場合を含まないと解すべきである。
( ) 「提供する」の通常の意味等e同c( )のうち,一ないし三は認め,四は否認する。e(ｲ)「記述子」a解釈同(ｲ)aは争う。
「記述子」は,任意のものを意味し,URLでないものに限定する理由はない。
b根拠( )特許請求の範囲の記載a同b( )のうち,一は認め,二は否認する。a( )発明の詳細な説明の記載b同b( )のうち,一は認め,二は否認する。bユーザーがURLを知る必要がないという本件発明の効果から 構成要件Bの 記 ,「述子」をURLとは異なるものであると限定する解釈は,当然には導かれない。
( )出願経過c同b( )は認める。 cイ充足原告の主張イは,いずれも否認する。
被告方法では 「アドレスバー」に入力された記述子はDNSサーバーに送られ ,ており,直接ディレクトリサーバーに送られていないから,構成要件Bを充足しない。
( )争点2(構成要件Cの充足)2(原告の主張)ア特許請求の範囲の解釈(ｱ)「前記記述子」前記( )(原告の主張)ア(ｲ)と同じ1(ｲ)「ディレクトリサーバー」a解釈構成要件Cの「ディレクトリサーバー」がどのような経路で当該「記述子」を受信するかについては,何ら限定はなく 「ディレクトリサーバー」がDNSとして ,の機能を併有してはならないという限定もない。
b根拠前記( )(原告の主張)ア(ｱ)cと同じ。
1イ充足(ｱ)サーバー方式の場合a被告方法は,別紙2被告方法説明書のC’-?T,C’-?U(原告の主張)及びC’-?Vのとおりである。
b同C’-?U(被告の主張)の構成( ’)及び( )は,実際には存在しない。
45すなわち,被告方法においては 「」と「サーバー」は,双 , NLIA Name ServerNLIA方ともに被告(又は韓国の親会社であるネッピア)によって管理運営されており(甲29,30),少なくとも物理的には両者とも1つのコンピュータ中に存在する。
クライアントPCから「」に送信された日本語インターネットアNLIA Name Serverドレスは 「」の付加プログラム?@によって非正規URLと選別され , NLIA Name Serverると,そのまま「」から「サーバー」へと送られる構成を有す NLIA Name ServerNLIAる(甲30)。
同構成C’-?U(被告の主張)の( ’)及び( )は,他のプロバイダー等によって管理45運営されているDNSサーバーにおいて被告との契約に基づき被告プログラム?@が付加されているような場合に実行され得るが,被告サービスとの関係では,被告との契約に基づき,自己が管理運営しているDNSサーバーにおいて付加プログラム?@を付加している他のプロバイダー等は存在しない。
c同構成C’-?U(原告の主張)及びC’-?Vによれば 「サーバー」が, ,NLIANLIANameクライアントPCから送信された日本語インターネットアドレスを「」から送信を受け,当該日本語インターネットアドレスに対応するURLを登録Server情報データベースから取得しているからディレクトリサーバー が 記述子 を 翻 ,「」 「」 「」「」,。 訳データベース を用いてURLに マッピング しており 構成要件Cを充足するなお,構成要件B及びCの「記述子」はURLを含まないから,被告方法において対比の必要があるのは,日本語インターネットアドレスが入力された場合の構成のみである。
,’ ,「」 , d仮に 同構成C -?U(被告の主張)を前提としてもサーバー がNLIAクライアントPCから送信された日本語インターネットアドレスに対応するURL,「」 を登録情報データベースから取得しており クライアントPCからNLIA Name Serverを介しているにすぎないから,いずれにしても構成要件Cを充足する。
(ｲ)プラグイン方式の場合同被告方法の構成C”は,構成要件Cを充足する。
(被告の主張)ア特許請求の範囲の解釈(ｱ)「前記記述子」前記( )(被告の主張)ア(ｲ)と同じ。
1構成要件Cの「前記記述子」も,アドレスバーに記載された記述子を含まない。
(ｲ)「ディレクトリサーバー」a解釈同(ｲ)aは争う。
b根拠前記( )(被告の主張)ア(ｱ)cと同じ1イ充足(ｱ)サーバー方式の場合a同イ(ｱ)aは否認する。
サーバー方式の被告方法は,別紙2被告方法説明書のC’-?T,C’-?U(被告の主張)及びC’-?Vのとおりである。
b同イ(ｱ)bは否認する。
「」と「サーバー」とは,IPアドレスが異なり,物理的にNLIA Name ServerNLIAも別のコンピューターに存在するものであり,実際にその間のインターネットの送信も行われている。
c同イ(ｱ)cは否認する。
,, , 被告方法は プラグイン方式を含め アドレスバーに記述子を記入しているから構成要件Cの「前記記述子」を充足しない。
仮に,構成要件Bの「記述子」に,アドレスバーに記入された記述子が含まれるとしても,被告方法では,アドレスバーに記入された記述子について,これが正規URLか否かを選別し,非正規URLと選別された記述子に限り 「サーバー」,NLIAに送られる。したがって,被告方法の構成C’-?V,C”でディレクトリサーバーに送られる日本語インターネットアドレスは,被告方法の構成B ,B”-?Tでクライア ’ントが提供する日本語インターネットアドレスと同義ではないから,被告方法は,構成要件Cの「前記記述子」を充足しない。
d同イ(ｱ)dは否認する。
(ｲ)プラグイン方式の場合同イ(ｲ)は否認する。
( )争点3(構成要件Eの充足)3(原告の主張)ア特許請求の範囲の解釈(ｱ)解釈「 」 構成要件Eにおける 前記クライアントに前記URLを用いて情報を要求させるとは,ディレクトリサーバーがクライアントにおいて送信された記述子に対応するURLをREDIRECTコマンドに含めて当該クライアントに返送すること(構成要件D)により,その後は,当該URLを含む当該REDIRECTコマンドにより,当該クライアントにおいて自動的に当該URLに対応するウェブに情報要求することを意味し,構成要件D及び構成要件Eがディレクトリサーバーの1つの行為でされる場合を含む。
(ｲ)根拠a本件明細書の記載( )本件明細書には 「認証サーバーは,次いでこのSIDが付加されたオリa ,ジナルURLから成る新しい要求を,REDIRECTによってクライアントに送出する。新しいURLにより形成された修正要求は,自動的にクライアントブラウザによりコンテンツサーバーに送出される 」(【0012】4頁37行〜40行 。
目)との記載がある。
( )上記記載は 「REDIRECT」コマンドと共にURLがクライアンb ,トに返送されると,クライアントが自動的に目的ページの接続要求を出すことを意味する。
b実施例及び図面の記載( )実施例3a本件明細書には,次の記載がある。
「メッセージ2では,ディレクトリサーバー602がREDIRECTをクライアント601に送信し,これには,データベース604から演算されたNUMBERに対する目標URLが記述されている。クライアントブラウザ601は続いて自動的にメッセージ3を送信し,このURLのコンテンツをGETする。商業用サーバー603はメッセージ4におけるこの情報を返送する。…サーバー602が最終的なURLに対する翻訳を行い,ページよりはむしろREDIRECTをクライアント601に送信するため,メッセージ4のドキュメントは最初のダイヤル入力以上のユーザの行為なしで入手される 」(【0045】10頁44行〜11頁2行 。
目)図6には 「3.“目標-URL”GET 「4.ページ送信」との記載があ , 」る。
「 ダイヤル”コマンドおよびその実施の利点の中には,従来の電話番号および “他の識別子と互換性を有する,インターネットにアクセスする改善された方法がある。商業者はコンタクト情報のインターネット特定書式を提供するための印刷物ま, 。」 たはテレビ広告を変更する必要がなく ユーザはURLについて知る必要がない(【0047】11頁9行〜12行目)。
( )これらの記載は,クライアントが自動的にURLを要求することを裏付bけている。
c出願経過後記被告の主張c( )は認め,( )は否認する。
ab上記補正は,ディレクトリサーバーがREDIRECTコマンド中のURLをクライアントパソコンに返送することによりクライアントパソコンの情報要求が自動的に行われるという構成要件の意義に何ら変更を加えるものではない。
イ充足被告方法の構成E’及び構成E”は,REDIRECTコマンドに含まれたURLが,クライアントPCに返されることにより,クライアントPCにおいて自動的にウェブページへ情報要求しているから,構成要件Eを充足する。
(被告の主張)ア特許請求の範囲の解釈(ｱ)解釈原告の主張ア(ｱ)は争う。
本件発明は,ディレクトリサーバーがURLを返送する段階(構成要件D)とディレクトリサーバーがURLを用いて情報を要求する段階(構成要件E)の2つの段階を含んでおり,方法の発明である以上,構成要件Dと構成要件Eとは,時系列的に異なる段階として行われる必要がある。
(ｲ)根拠a本件明細書の記載同(ｲ)aのうち,( )は認め,( )は否認する。
abb実施例及び図面の記載同(ｲ)bのうち,( )は認め,( )は否認する。
abc出願経過( )前提事実( )ウ(ｴ)のとおり,原告は,平成17年12月5日付けの手続a2補正において,請求項1を「前記ディレクトリサーバーが,REDIRECTコマンド中の前記URLを前記クライアントに返送する段階と,前記クライアントに前記URLを用いて情報を要求させる段階と 」と補正し,同日付けの意見書におい ,て,上記補正について 「1つの段階から,URLの返送段階と,そのURLを用 ,いた情報要求段階との2つの段階に分けて表現し,記載の明瞭化を図りました 」。
と述べた。
( )この事実は,構成要件Dと構成要件Eとは,時系列的に異なる段階としbて行われる必要があることを裏付ける。
イ充足同イ(ｱ)は否認する。
被告方法では,ディレクトリサーバーである「サーバー」が,構成要件DとNLIAは時系列的に異なる段階として,クライアントにURLを用いて情報を要求させる段階(構成要件E)を行っていない。殊に,被告方法では,同構成E’及び構成E”のと, , おり クライアントのブラウザのアドレスバーを利用した標準的なプロトコルを用い「サーバー」からアドレスバーに所期のURLを返しさえすれば,その後は,クNLIAライアントに備わっているブラウザが当該URLによって識別されたページを(DNSサーバーを介して)取得し,クライアントPCに表示するものであり,時系列的に異なる段階として,構成要件Eに当たる段階を有しないことは明らかである。
( )争点4(構成要件Fの充足)4(原告の主張)ア特許請求の範囲の解釈前記争点( )(原告の主張)アと同じ。
3イ充足被告方法の構成F’及び構成F”は 「REDIRECTコマンド」に含まれたU ,RLがクライアントPCに返されることにより,クライアントPCにおいて自動的にウェブページへ情報要求し(構成E’及び構成E”),ウェブページへ接続する(構成F’及び構成F”)から,構成要件Fを充足する。
(被告の主張)ア特許請求の範囲の解釈前記争点( )(被告の主張)アと同じ。
3イ充足原告の主張イは否認する。
被告方法は,上記( )(被告の主張)イのとおり,構成要件Eの段階を有しないか3ら,構成要件Fも充足しない。
( )争点5(本件特許の無効理由の存否)5ア争点5-1(開示義務違反(特許法36条4項,6項1号,2号))(被告の主張)(ｱ)記載不明瞭a構成要件A及びG構成要件Aの「アクセスを提供する方法 ,構成要件Gの「アクセス方法」は, 」「アクセス」する主体が異なっており 「アクセス 「アクセスを提供する 「アク ,」」セスする」が具体的に何をする行為を意味するのかが不明瞭である。
b構成要件B( )クライアントによる記述子の提供方法を特定していない。
a( )被告方法のように,クライアントがアドレスバーに記述子を入力した場 b合は,正規のURLか否かを選別する段階がなければ 「ディレクトリサーバー」 ,に記述子が送られることはない。
しかし,本件発明には,上記の選別する段階について何も記載されていない。
c構成要件C( )「ディレクトリサーバー」という文言が不明瞭である。
a( )クライアントが提供した記述子を「ディレクトリサーバー」が受け取る b方法を特定していない。
(ｲ)まとめ,, , よって 本件発明は 平成14年法律第24号による改正前の特許法36条4項6項1号,2号に違反し,本件特許は,同法123条1項4号の規定により無効とされるべきである。
(原告の主張)(ｱ)記載不明瞭等a構成要件A及びG被告の主張(ｱ)aは否認する。
構成要件Aの「アクセスを提供する方法」とは,本件発明の実施主体が「アクセスを提供する」ものであり,発明の実施行為自体は究極的に発明実施主体である人によって行われることを明らかとしつつ,そのための具体的構成である要件BないしGはさまざまなハードウェアによって実現されていくものであることを表現したものである。構成要件Gの「アクセス方法」は,構成要件Aの「アクセスの提供」を実現するために発明の構成要件として,ハードウェアであるクライアントがアクセスすることを要することを意味する。
b構成要件B( )同(ｱ)b( )は否認する。
aa構成要件Bは,本件発明が全体として機能するために最低限必要なデータ送信行為を規定しているにすぎず,データ送信方法の具体的態様まで限定的に規定する必要はない。
( )同(ｱ)b( )は否認する。
bbクライアントのウェブブラウザのアドレスバーへ記述子が入力され,DNSサーバーに送信されるような場合に,クライアントにおいて記述子を認識させて直接ディレクトリサーバーに送信させるようにするか,DNSにおいて記述子を認識させた上でディレクトリサーバーに送信させるようにするか,それともDNS兼ディレクトリサーバーにおいて記述子を認識させて処理するようにするかは,本件発明, 。 を具体的に実施するに当たり 当業者が適宜選択すれば足りる設計事項にすぎないc構成要件C( )同(ｱ)c( )は否認する。
aa本件発明において 「ディレクトリサーバー」は 「記述子」を「翻訳データベー , ,スを用いてURLにマッピング」し(構成要件C) 「REDIRECTコマンド中 ,の前記URLを前記クライアントに返送する」(構成要件D)サーバーであることを要するとともに,これで足りるものであり,DNSの機能を併用してもよく,不明瞭という問題は存しない。
( )同(ｱ)c( )は否認する。
bb構成要件Cは,本件発明が全体として機能するための最低限必要なデータ受信を前提としているにすぎず,データ受信の具体的態様まで限定的に規定する必要はない。
(ｲ)まとめ同(ｲ)は否認する。
イ争点5-2(新規性の欠如)(被告の主張)(ｱ)乙24発明論文集「 」のうComputer Communication ReviewVolume 17, Number 5 Special Issueち「 」(著。昭和63 A Yellow-Pages Service for a Local-Area NetworkLarry L. Peterson年,ACM(アメリカ計算機学会)出版発行。乙24の1。以下 「乙24刊行物」 ,といい,これに記載された発明を「乙24発明」という。)には,次の構成が開示されている。
A’インターネットの至る所からクライアントがサービスを提供するローカル・サーバーにアクセスできるようにする方法である。
B’クライアントは,サービス名およびサーバーが持つべき任意の属性を指定して,イエローページ・サービスにサーバーのアドレスを問い合わせる。
C’イエローページ・サーバーは,使用可能なサービスおよびサーバーに関する情報のデータベースを備え,前記サービス名およびサーバーが持つべき任意の属性をサーバーのアドレスにマッピングする。
D’イエローページ・サービスは,クライアントの要求を満たす1あるいは2以上のサーバーのアドレスを返送する。
フラグシップ・ホストが,クライアントに対して,サーバー・ホストのアドレスを返送するとともに,そのパケットをそのサーバー・ホストにリダイレクトする必要があると知らせる。
G’クライアントが,ローカル・サーバーにアクセスする方法(ｲ)「情報ページ」(構成要件A及びG)a乙24発明には,アクセス先がサーバーシステムに備わる「情報ページ」であることが明示されていない。
b( )しかし,乙24発明において「ローカル・サーバーにアクセス」するaとは,単にサーバーコンピュータにアクセスすることではなく,そのサーバーコンピュータが提供する情報サービスにアクセスすることを意味する。
( )また,乙28(「InｔeｒneｔUｓeｒ1995年2月号」19b, , 95年2月1日 ソフトバンク株式会社発行)の118〜119頁図1〜図4にはウェブ・ブラウザが情報ページを表示することが示されている。
cしたがって,乙24発明の構成A ,G’と本件発明の構成要件A,Gと ’は一致する。
(ｳ)「記述子」(構成要件B)a「」とは 「(情報処理):記述子,デスクリプター(情報の類別・descriptor ,索引に用いる語句)」(リーダーズ英和辞典第2版)を意味する。記述子は,このように,索引のみならず情報の「類別」(類ごとの中身は通常複数)にも使用されるものであるから,記述子という単語の意味を根拠として 「記述子」=「特定かつ ,唯一」の対象を識別するものと決定付けることはできない。
したがって,構成要件Bの「記述子」は,任意の記述子を意味し,URLを除いたり,目標情報ページを識別する特定かつ唯一のURLへとマッピングされるものに限定されるものとはいえない。
原告の主張は 「翻訳データベース」の構築の問題と 「記述子」という言葉の , ,定義の問題とを混同するものである。
b乙24発明の サービス名およびサーバーが持つべき任意の属性 は記 「 」 ,「述子」の内容を具体的に説明しているにすぎない。
c仮に 「目標情報ページを識別する特定かつ唯一のURLへとマッピング ,されるもの」という原告の限定解釈によったとしても,乙24発明の「サービス名およびサーバーが持つべき任意の属性」は 「特定かつ唯一のURL」に結び付く ,ものであることは,後記(ｵ)(「翻訳データベース」)のとおりである。
(ｴ)「ディレクトリサーバー」(構成要件C)a( )乙30(CCITTブルーブック第?U巻?U・6「勧告F.500」平成a3年9月4日,財団法人日本ITU協会発行)には,以下の記載がある。
「H.イエローページ“分類された情報”を参照 」(199頁)107 。
「H.分類された情報ディレクトリにおいては,ディレクトリ情報群は“17ホワイトページ“イエローページ”として現在知られている 」(189頁) ”, 。
「H.ディレクトリディレクトリサービスを提供するための協同動作する24開放型システムの集合 」(190頁)。
( )これらの記載からすると イエローページは ディレクトリにおけるディb ,,レクトリ情報群として周知のものである。
bしたがって 「イエローページ・サーバー」が「ディレクトリサーバー」 ,であることは自明であり,相違点ではない。
(ｵ)「翻訳データベース」(構成要件C)a( )乙25(CCITTブルーブック第?[巻?[-6,8「勧告.500」 a X平成3年11月1日,財団法人日本ITU協会発行)には,以下の記載がある。
「ディレクトリによって保持されている情報は,ディレクトリ情報ベース(DIB)と総称され 」(244頁4行〜5行) ,「DIBは,オブジェクトについての情報で構成されている。DIBは(ディレクトリ)エントリで,各エントリは一つのオブジェクトに関する情報の集合で構成。, 。 される 各エントリは属性で 各属性は一つのタイプと一つ以上の値で構成されるあるエントリに存在する属性のタイプは,そのエントリが記述するオブジェクトのクラスに依存する 」(247頁下から4行〜最終行) 。
「DIBのエントリは,木構造,つまり節点がエントリであるディレクトリ情報木(DIT)にまとめられる 」(248頁1行) 。
( )一本件明細書において 「ディレクトリサーバー」や「翻訳データベーb ,ス」の構成について格別の説明はない。
二したがって,1つの記述子に対し1つのURLをマッピングするにして, , , も どのようなデータベースとして構築し どのような演算結果を出力させるかは適宜選択可能な設計事項であり,原告主張のように,データベースの構造が1対1に対応付けたものに限られると解する理由はない。
( )したがって,構成要件Cにいう「ディレクトリサーバーに存在する 「翻c 」訳データベース」とは,ディレクトリ情報ベースのことであり,ディレクトリ情報木の構成を有するデータベースを意味する。
b( )乙24発明の構成C のイエローページ・サービスのイエローページ・a ’データベースは,ディレクトリ情報ベースと同じ構成を開示している。
( )一乙24刊行物の設計の問題点 (訳文11頁)には イエローペーb5.2 「」,ジ・サービスの構成に関し 「クライアントではなくサーバーにおいて選択アルゴ ,リズムを関与させる 構成を有する旨が明記されており選択アルゴリズムはデー 」 ,「タベースと同じホスト上で実行し,相対的に小さい回答?サーバー・アドレス?が返される」と述べられている。
二すなわち,乙24刊行物には,イエローページ・サーバーに提供された名前に対し返された値は,同サーバー上で稼動する選択アルゴリズムによって演算され抽出選択されたものであること,選択アルゴリズムの設定次第で,1つのUR, 。 Lのみを抽出選択するようにすることは 極めて容易であることが開示されている三しかも,後記(ｷ)b( )のとおり,乙24刊行物には,本件発明の「REbDIRECTコマンド」と同じ「リダイレクト」が開示されているから,乙24発明において「リダイレクト」する場合,選択アルゴリズムを1つのURLのみを抽出選択するように設定するなどすれば,当然1つのURLを選択することになる。
四したがって,乙24発明(被告が引用するのは 「リダイレクト」を使用 ,する態様のものである。)は,特定かつ唯一のURLを選択することを開示している。
c仮に,本件発明の「翻訳データベース」が1対1の対応付けしか行わないデータベースであるとしても,それは,上記ディレクトリ情報ベースのディレクトリ情報木の段階を1段階にしているということにすぎない。情報木の段階を複数段階とすることまで想定した技術が,1段階とする技術を含んでいることは明らかである。よって,乙24発明におけるイエローページ・データベースは,乙24発明のものよりも進歩性を欠く態様の本件発明の「翻訳データベース」の技術も開示している。
dしたがって,乙24発明の構成C’は,本件発明の構成要件Cと一致するか,本件発明の構成要件Cのように構成することは,当業者が容易に想到することができたことである。
(ｶ)「URLにマッピングする」(構成要件C)a( )乙27(「UNIXMAGAZINE1994年2月号」)の33a頁左欄「TCP/IPの基本機能とDNS」には 「現在のインターネットを支え ,る基本技術のなかで,TCP/IPのアプリケーションとして一番大きな役割をもつのはDNSでしょう 」との記載があり,同欄「DNS」には 「DNSは,階 。 ,層的ドメイン名とIPアドレスのマッピングのほかに電子メールに関する情報を管理しています 」との記載がある。 。
乙27の34頁左欄「」には 「…インターネット上のUniform Resource Locators ,分散したリソースに対して,統一的な名前の付け方を決めてユーザー・インターフェイスを向上させる試みがあります。それがURL()でUniform Resource Locatorsす 」との記載がある。 。
( )これらの記載からすると,インターネット上のリソース(情報ページ)のb所在(アドレス)を統一的に特定するものがURLであることが,本件出願当時,当業者に自明であったことが明らかであり 「URL」と「アドレス」とはインター ,ネットを前提に論ずる上では,ほぼ同義であった。
b( )したがって,乙24発明の構成C’の「サーバーのアドレスにマッピaングする」とは,構成要件Cの「URLにマッピングする」ことを意味する。
( )原告は,乙24発明の構成D’は 「フラグシップ・ホスト」の「アドb ,レス」を返すものにすぎない旨主張する。
しかし,原告の上記指摘部分は,目的の情報ページのアドレスを取得する前段階, 。, として 一旦フラグシップ・ホストに接続される際の説明部分である したがってこの段階で目的の情報ページのアドレスが返されるわけでないのは当然である。そして,その後の「転送」又は「リダイレクト」により,マッピングにより得られた情報が送られているものである。
cまた,後記(ｷ)の「REDIRECTコマンド」の意義からすると,乙24発明の構成D’の「サーバーのアドレスを返送する」構成は,構成要件Dの「URLを返送する」構成を開示している。
(ｷ)「REDIRECTコマンド中の前記URLを前記クライアントに返送する」(構成要件D)並びに構成要件E及びFa乙24発明の構成D’は,本件発明の「REDIRECTコマンド」をクライアントに返送する構成を開示している。
b( )乙26(「UNIXUSER1994年12月号」平成6年12月a1日,ソフトバンク株式会社発行)には,以下の記載がある。
Map 一「●マッピング変換指定?@〜変換のルールを指定する。すなわち,URL中にというパス(で始まる/a/b/*/a/b/任意のパス)が現れたとすると,それはに変換される。他に変換ルールが /X/Y/Z/*あれば,続いてチェックされる 」(134頁右欄) 。
Redirect 二「●他のURLに変換〜に指定したパターンにマッチした場合は,指定したURLにリクエストRedirectがそのままフォワードされる。サーバーが引っ越したような場合に用いる。URLは『ホスト名 』から書かなければならない 」(135頁左欄),http:/// 。
「例:」(135頁右欄)Redirect /a/b/* URL( )上記記載からすると 「REDIRECTコマンド」とは,クライアン b ,トから要求を受けたサーバーが該クライアントに対して発するもので,REDIRECT中に指定されたあて先へ該要求を再指向させるよう指令するものであること,クライアントは,REDIRECT指令に従って,該サーバーからの返信をREDIRECT中のURLで指定された再指向先へとそのままフォワード(自動的に転送)することは,本件特許の優先日の技術常識である。
( )さらに,乙24刊行物には 「リダイレクト」と記載されているだけでなc ,く,それに続けて,その挙動が「接続指向プロトコル(例えばTCP)のケースでは妥当である」(乙24の2の12頁下から7行)との記載がある。そして,インターネット及びそこで用いられるプロトコルであるTCP/IPやHTTPは,1970年代から80年代に既に確立していた(乙20の50頁)。
cしたがって,乙24発明の構成D’は,構成要件Dと一致する。
d周知技術である「REDIRECT」の内容に照らせば,同構成D’は,構成要件E及びFの構成を記載しているに等しい事項である。
(ｸ)まとめ, ,,。 そうすると 乙24発明と本件発明は すべての点で一致し 相違点を有しない,, , よって 本件発明には 新規性欠如の無効理由があり(特許法123条1項2号平成11年法律第41号による改正前の特許法29条1項3号),原告は,その権利を行使することができない。
(原告の主張)(ｱ)乙24発明被告の主張(ｱ)は明らかに争わない。
(ｲ)「情報ページ」(構成要件A及びG)同(ｲ)のうち,aは認め,b( )は明らかに争わず,b( ),cは否認する。
b a(ｳ)「記述子」(構成要件B)a同(ｳ)aは争う。
本件発明の「記述子」とは,電話番号・会社名・製品名等のURLとは異なる数字あるいは言葉であり,かつ,当該「記述子」に対応し,目標情報ページを識別する特定かつ唯一のURLに結び付けられるものを意味する。
b同(ｳ)bは否認する。
乙24発明の「サービス名およびサーバーが持つべき任意の属性」とは,クライアントがサーバーに対して求めるサービスの内容(印刷サービス プロセッササー ,ビス,トークサービス)やその質(属性,属性,属性等)といった条件speedresarchを指定するものであり 「任意の属性」から特定かつ唯一のサーバーへと対応付け ,られるものではない。
c同(ｳ)cは否認する。
(ｴ)「ディレクトリサーバー」(構成要件C)同(ｴ)は明らかに争わない。
(ｵ)「翻訳データベース」(構成要件C)a同(ｵ)aのうち,( )は明らかに争わず,( )及び( )は争う。
abcb同(ｵ)bのうち,( )は明らかに争わず,( )は否認する。 ab本件発明は,人間に理解しやすい「電話番号・会社名・製品名等のURLとは異なる数字あるいは言葉」をインターネット上の規約である「URL」に1対1又は多対1に対応付けして翻訳するものである。これに対し,乙24発明は,指定条件を満足するサーバーを検索するものであって,検索の結果,1つのサーバーが選択される場合があるとしても,検索条件による絞り込みの結果にすぎず,本件発明の翻訳データベース による1対1の対応付けとは技術思想が全く異なる したがっ 「」 。
て,1対1の対応付けとすることは,設計事項ではない。
c同(ｵ)cは否認する。
d同(ｵ)dは否認する。
(ｶ)「URLにマッピングする」(構成要件C)a同(ｶ)aは明らかに争わない。
b( )同(ｶ)b( )は否認する。
aa( )乙24発明の構成D’は 「フラグシップ・ホスト」の「アドレス」を b ,,’ 「 。」 返すものにすぎないから 同構成C の サーバーのアドレスにマッピングするは「URLにマッピングする」ことを意味するものとはいえない。
同構成C’及びD’における「サーバーのアドレス」は,ローカルネットワーク内において各サーバーがどの位置にあるかを示すものにすぎず,インターネット上の規約である「URL」を開示も示唆もするものではない。
したがって,同構成C’は,構成要件Cの「URLにマッピングする」構成を開示していない。
c同(ｶ)cは否認する。
(ｷ)「REDIRECTコマンド中の前記URLを前記クライアントに返送する」(構成要件D)並びに構成要件E及びFa同(ｷ)aは否認する。
b( )同(ｷ)b( )は認め,( )及び( )は否認する。
aabc( )乙26は,仮想的なディレクトリ指定をファイルシステムにおけるパス b, 「」, に変換するルールを規定したものであり被告の主張(ｷ)b( )二のは aRedirect単に“”というパスをURLへと変換するものにすぎず,その結果「指定した/a/bURLにリクエストがそのままフォワード」されるものである。すなわち,乙26における「REDIRECT」は 「REDIRECT」自体がURLを含むもの ,ではなく 「URL」へとリクエストを送るものであり,クライアントをして自動 ,的に情報要求させるものでもない。したがって,乙26における「REDIRECT」は,本件発明の「REDIRECTコマンド」とは全く異なる。
「REDIRECTコマンド」の意義は,一義的に明確とはいえない(乙5)。
( )乙24発明には 「リダイレクト」が,ローカルエリアネットワークではc ,なく インターネット環境の場合にどのように適用されるか そもそもインターネッ , ,ト環境の場合にも「リダイレクト」を適用して修正ができるかについて,全く開示がない。
c同(ｷ)cは否認する。
乙24発明は 「フラグシップ・ホスト」から「クライアント」に対して「リダ ,イレクトする必要があると知らせる」のみであり 「リダイレクト」によりクライ ,アントがどのような動作を要求されるか,そもそも「リダイレクト」にURLが含まれているのかについて,何ら開示していない。
d同(ｷ)dは否認する。
(ｸ)まとめ同(ｸ)は否認する。
本件発明は 「記述子」と「URL」とを1対1(ないしは多対1)で対応付け, ,「 」 。 さらに REDIRECTコマンド を利用したことをその本質的特徴としているこれに対し,乙24発明は,一定条件を満たす不特定のサーバーを探す単なる条件検索サービスであり,技術思想は全く異なる。
また,本件発明が前提とする「ウェブ」が創設されたのは平成3年(本件明細書【0005】)であるのに対し,乙24発明を開示した刊行物(乙24の1)が発行されたのは昭和63年であるから,両者は,インターネットについて前提とする技術背景を全く異にする。
ウ争点5-3(進歩性の欠如)(被告の主張)(ｱ)主引用例(乙24発明)前記イ(被告の主張)(ｱ)と同じ。
(ｲ)一致点及び相違点の認定a相違点1(「URLにマッピングする」構成要件C)乙24発明の構成C’は「サーバーのアドレスにマッピングする」のに対し,本件発明の構成要件Cは「URLにマッピングする」点で異なる。
b相違点2(「REDIRECTコマンド中の前記URLを前記クライアントに返送する」構成要件D)同構成D’は,構成要件Dの「REDIRECTコマンド中の前記URLを…返送する」構成を明示していない。
c相違点3(構成要件E及びF)乙24発明は,本件発明の構成要件E及びFの構成を明示していない。
d一致点乙24発明と本件発明とは,その余の点において一致する。
e相違点4(「情報ページ」構成要件A及びG)前記イ(被告の主張)(ｲ)のとおりであり,相違点ではない。
f相違点5(「記述子」構成要件B)前記イ(被告の主張)(ｳ)のとおりであり,相違点ではない。
g相違点6(「翻訳データベース」構成要件C)前記イ(被告の主張)(ｵ)のとおりであり,相違点ではない。
(ｳ)容易想到性a相違点1(「URLにマッピングする」)(構成要件C)前記イ(被告の主張)(ｶ)のとおり。
b相違点2(「REDIRECTコマンド中の前記URLを前記クライアントに返送する」構成要件D)及び相違点3(構成要件E及びF)( )副引用例(乙26発明)a前記イ(被告の主張)(ｷ)bのとおり。
( )容易想到性b一技術分野の同一性本件発明と乙24発明,乙26発明は,いずれもインターネットを含む電気通信ネットワークに関するものであり,技術分野が共通する。
二課題の自明性本件発明と乙24発明とは,インターネットを介して情報ページにアクセスする際のネットワークユーザの便宜を図るものであり,解決すべき課題が共通である。
本件発明と乙24発明とは,複雑な文字列によって識別されるインターネット上のリソースに対して簡易な記述子の提供をもって到達できるとの共通した作用・効果を有し,さらに,これを実現させるための翻訳データベース,マッピング,リダイレクトの各機能を用いる点で共通する。
三組合せの容易性本件発明は,乙24,乙26に開示された技術事項を適宜選択し,あるいは単に寄せ集めたにすぎず,または,これらの公知技術を組み合わせることについて,動機付けとなり得る記載が多数認められる。
技術的な阻害要因は一切なく,公知技術と比較して,予想の範囲を超える有利な効果も認められない。
したがって,本件発明は,出願時の技術水準に基づき当業者が容易に想到できたものである。
(ｴ)まとめよって,本件特許は,特許法29条2項の規定に違反し,同法123条1項2号の規定により無効とされるべきである。
(原告の主張)(ｱ)主引用例(乙24発明)被告の主張(ｱ)は明らかに争わない。
(ｲ)一致点及び相違点の認定a相違点1(「URLにマッピングする」構成要件C)被告の主張(ｲ)aは認める。
b相違点2(「REDIRECTコマンド中の前記URLを前記クライアントに返送する」構成要件D)同(ｲ)bは認める。
c相違点3(構成要件E及びF)同(ｲ)cは認める。
d一致点同(ｲ)d(一致点)は否認する。
乙24発明と本件発明とは,次のeないしgの点においても相違する。
e相違点4(「情報ページ」構成要件A及びG)乙24発明には,アクセス先がサーバーシステムに備わる「情報ページ」であることが開示されていない。
f相違点5(「記述子」構成要件B)前記イ(原告の主張)(ｳ)bのとおり。
g相違点6(「翻訳データベース」構成要件C)前記イ(原告の主張)(ｵ)bのとおり。
(ｳ)容易想到性a相違点1前記イ(原告の主張)(ｶ)bのとおりb相違点2及び3( )副引用例(乙26発明)a前記イ(原告の主張)(ｷ)cのとおり。
( )容易想到性b一被告の主張(ｳ)b( )はいずれも否認する。 b二本件発明は 「記述子」と「URL」とを1対1(又は多対1)で対応付 ,け,さらに「REDIRECTコマンド」を利用したことをその本質的特徴としているのに対して,乙24発明は,一定条件を満たす不特定のサーバーを探す単なる条件検索サービスであり,技術思想は全く異なる。
乙24発明が,検索条件による絞り込みの結果,たまたま条件を満たすサーバーが1件になった場合と,記述子に対応するURLがそもそも特定の1つに定められており,検索条件や絞り込みという概念を入れる余地がない本件発明とは異なる。
(ｴ)まとめ同(ｴ)は争う。
( )争点6(訂正による無効理由の解消の存否)6ア争点6-1(訂正要件及び充足)(原告の主張)(ｱ)本件訂正(前提事実( )エ(ｲ))は,特許請求の範囲の減縮又は明りょうでな2い記載の釈明であり,かつ,他の訂正要件も満たしている。
(ｲ)被告方法は,本件訂正発明の構成要件を充足する。
(被告の主張)(ｱ)原告の主張(ｱ)は明らかに争わない。
(ｲ)同(ｲ)は否認する。
イ争点6-2(進歩性欠如等)(被告の主張)本件訂正発明には,前記( )アないしウの各被告の主張のとおり,依然として開5示義務違反,新規性の欠如及び進歩性の欠如の無効理由が存在するから,無効理由は解消されていない。
(原告の主張)被告の主張は否認する。
( )争点7(主体性)7(原告の主張)ア道具理論(ｱ)まとめ被告は,クライアントPCを使用するユーザーの行為を道具として利用することにより,被告方法を使用し,本件発明を直接侵害しているから,差止め及び除却請求の相手方となる。
(ｲ)外形的・即物的行為の管理a被告は,前提事実( )アのとおり,被告サービスを開設し,そのトライアル登3録サービス「」を開始し,その優先登録サービス「」を Test Operation Sunrise Operation開始した。さらに,被告は,登録された日本語インターネットアドレスを管理する(甲4の4の1)などし,被告サービスを提供している。
b被告は,被告サービスが実現されるために用いられる「サーバー」及びNLIA「」を所有ないし管理している。 NLIA Name Serverc被告は,利用者に対して被告サービス利用の積極的勧誘行為を行っている。
d被告は,被告サービスの使用方法について,自身が開設したウェブサイト上で詳細な解説を行っており,利用者はかかる解説を参照して被告サービスを利用している。
eウェブページへの接続は,最終的に「サーバー」からクライアントPCNLIAに返送される「REDIRECTコマンド」に含まれたURLによって自動的に行われる。
f上記aないしeの事実からすると,被告は,侵害行為の前提となる外形的・即物的行為を管理し得る立場にある。
(ｳ)利益の帰属被告は,日本語インターネットアドレス()登録を受け付け,キーワード登録JAddressを行った者から登録料収入を得ており(甲10),被告サービスの運営を通じて得られる営業上の利益を享受しようとしている。
イ共同侵害行為(ｱ)まとめ仮に,アが認められないとしても,被告は,クライアントPCを使用するユーザーと共同して,被告方法を使用し,本件発明を直接侵害しているから,差止め及び除却請求の相手方となる。
(ｲ)客観的要件NLIANLIA ユーザーのクライアントPCと 被告が所有・管理するサーバー 及び ,「」「」との共同行為によって,本件発明が実施されている。
Name Serverしたがって,客観的要件を充足する。
(ｳ)主観的要件a被告の認識被告は,ユーザーのクライアントPCに対する日本語インターネットアドレスの入力・送信を契機として被告方法が実施されることを認識し,クライアントPCのユーザーに対して,積極的に被告サービスの利用を促している。
したがって,被告には,クライアントPCの動作を利用する意思が存在する。
bユーザーの認識( )ユーザー側のクライアントPCは,通常のコンピュータ機器にすぎず,現代a社会においてはだれもが備えているものであり,また,かかるコンピュータ機器がインターネットに接続されていることも高度情報化した現代社会において今や当然の状況である。
したがって,インターネットに接続されたユーザー側のクライアントPCは,本件, 。 発明が前提とする一般的な環境にすぎず ユーザー側の主観的共同意思は不要である( )仮に,ユーザー側において主観的共同意思が必要であると解したとしても,bユーザーはクライアントPCに日本語インターネットアドレスを入力・送信するだけで,目的とする情報ページにクライアントPCが導かれることを充分認識しており,ユーザーには実施内容と結果の認識程度のシステムを利用する共同行為の認識が存在する。
(ｴ)「業として」の要件被告において,自ら被告方法の一部を実施しつつ,クライアントPCのユーザーによる被告方法の残部の実施を利用して自己の一部実施を補充しており,これを業として行っている以上,仮にクライアントPCのユーザーに個人ユーザーが含まれていたとしても,少なくとも被告について共同直接侵害が成立する。
ウ間接侵害(ｱ)まとめ少なくとも,被告は,被告方法を使用して,本件発明を間接侵害しているから,差止め及び除却請求の相手方となる。
(ｲ)101条4号a被告方法の構成D’の「サーバー』が,当該URLを,REDIRE 『NLIACTコマンドを利用して,クライアントPCに送信する段階」におけるURLを含んだREDIRECTコマンドは,本件発明に係る「方法の使用にのみ用いる物」であり,かかる「REDIRECTコマンド」をユーザーのクライアントPCに提供する被告の行為は 「方法の使用にのみ用いる物」を「譲渡」する行為に該当し,特許法1 ,01条4号に定める間接侵害行為に該当する。
b「URLを含んだREDIRECTコマンド」という無体物の送信であっても 「物」の「譲渡」に該当する。 ,cURLを含むREDIRECTコマンドは,被告方法の使用以外の用途に用いられている事実は存在せず,ユーザーにおける被告方法の実施にのみ用いられている。
(ｳ)101条5号aURLを含んだREDIRECTコマンドは 特許法101条5号にいう 発 , 「明による課題の解決に不可欠なもの」に該当する。
b被告は,遅くとも原告から警告状(甲13)を受領した時点で 「発明が特許発 ,明であること及びその物がその発明の実施に用いられること」を確定的に知った。
(被告の主張)ア道具理論(ｱ)まとめ原告の主張ア(ｱ)は否認する。
被告方法を使用しているのは,パソコンのユーザーであって,被告ではない。
(ｲ)外形的・即物的行為の管理同ア(ｲ)は否認する。
(ｳ)利益の帰属同ア(ｳ)は否認する。
イ共同侵害行為同イは否認する。
ウ間接侵害同ウは否認する。
( )争点8(損害の発生及び額)8(原告の主張)ア特許法102条2項の損害(ｱ)売上げ, 「」 a被告は 平成18年9月5日から日本語インターネットアドレスJAddressの優先登録サービス「」を開始しただけでなく(前提事実( )ア),同年 Sunrise Operation 311月からその商用登録サービス「」を開始し,同年12月末日 Commercial Operationまでに,少なくとも4000件の登録を得た。
b被告は,登録したサイト運営者から,登録料金として,1件当たり少なくとも3万1500円を受領し,少なくとも1億2600万円の売上げを上げた。
3万1500円×4000件=1億2600万円(ｲ)利益率被告サービスにおける利益率は,少なくとも70%を下らない。
(ｳ)まとめよって,被告は,少なくとも8820万円の利益を得たものであり,原告は,特許法102条2項に基づき,同額の損害を被ったものと推定される。
1億2600万円×70%=8820万円イ弁護士費用相当額の損害(ｱ)本件事案の性質・内容から,原告は弁護士である原告代理人らに本件訴訟提起を依頼せざるを得なかった。
(ｲ)その結果,原告は原告代理人らに弁護士費用の支払を約し,少なくとも350万円の弁護士費用相当額の損害を被った。
ウまとめよって,原告は,被告に対し,民法709条,特許法102条2項に基づき,9170万円及びこれに対する平成19年2月15日から支払済みまで民法所定の年5分の割合による遅延損害金の支払を求める。
(被告の主張)ア特許法102条2項の損害(ｱ)売上げ原告の主張ア(ｱ)は否認する。
被告は,当初,平成18年11月から商用登録サービスを開始する予定であったが,その開始を延期し,現在に至っており,登録料等一切の利益を得ていない。
(ｲ)利益率同ア(ｲ)は否認する。
(ｳ)まとめ同ア(ｳ)は否認する。
イ弁護士費用相当額の損害同イは否認する。
ウまとめ同ウは否認する。
第3当裁判所の判断1争点5-3(進歩性の欠如)について( )乙24発明1ア乙24の1及び2によれば,乙24刊行物(昭和63年にACM(アメリカCOMPUTER COMMUNICATION REVIEW 計算機学会)出版から発行された論文集「Volume17, Number5 Special IssuePart 8. RESOURCE SHARING IN 」のうち 「,DISTRIBUTED SYSTEMSLarry L. PetersonA Yellow-Pages Service 」 「 の中の執筆の論文」)には,以下の記載があることが認められる(一部は,当for a Local-Area Network事者間に争いがない。)。
In addition to describing the implementation of the yellow-pages service within a (ｱ)「local-area network, we show how the service can be integrated with the available internetcommunication protocols to enable clients from throughout the internet to access local」(訳文「イエローページ・サービスのローカルエリア・ネットワーク内で servers.の実施の説明だけでなく,インターネットの至る所からクライアントがローカル・サーバーにアクセスできるようにするために,本サービスが,使用可能なインターネット通信プロトコルとどのように統合できるかを示す 」)(235頁左欄7行〜 。
12行)This paper describes a yellow-pages service that maps the name of a service into (ｲ)「」(訳文「この論文では,サービスthe address of a server willing to provide the serviceを提供しようとするサーバーのアドレスにサービス名をマッピングするイエローページ・サービスについて説明する 」)(235頁左欄14行〜16行) 。
A client that wishes to engage a service queries the yellow-pages service for the (ｳ)「address 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 the」(訳文「サービスを受けたいクライアントは,サービス名およ client's requirements.びサーバーが持つべき任意の属性を指定して,イエローページ・サービスにサーバーのアドレスを問い合わせる。イエローページ・サービスは,クライアントの要求を満たす1あるいは2以上のサーバーのアドレスを返送する 」)(235頁左欄 。
下から2行〜右欄4行)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 an」(訳文「クライアントは,フラグシップ・ホス actual server that provides the service., 。, ト上でサーバーを使用できるかのように フラグシップ・ホストに接続する 次にフラグシップ・ホスト上で動作する転送メカニズムが,実際にそのサービスを提供するサーバーにクライアントを接続させる 」)(235頁右欄10行〜14行) 。
A set of servers implement the yellow-pages service. Each server maintains a (ｵ)「」(訳文「サーバーのセッdatabase of information about the available services and servers.トが,イエローページ・サービスを実施する。各サーバーは,使用可能なサービス及びサーバーに関する情報のデータベースを維持する 」)(235頁右欄下から7 。
行〜5行)An attribute is a syntactic object that denotes a property or characteristic of a (ｶ)「」(訳文「属性は,サーバーのプロパティまたは特徴を示す統語的要素であserver.る 」)(236頁左欄2行〜3行) 。
Clients submit a set of attributes when querying the yellow-pages for a server that 「」(訳文「クライアントは,ある特定のサービスを提供すprovides a particular service.るサーバーについてイエローページに問い合わせる際,属性のセットを送信する 」)(236頁左欄11行〜13行) 。
Associated with each yellow-pages server is a database of information about the (ｷ)「services available in the system. The database contains bindings of each service to a set of」(訳文「各イエローページ・サーバーには,システム servers that provide the service.内で使用できるサービスについての情報のデータベースが関連付けられる。データベースには,各サービスとそのサービスを提供するサーバーのセットとを結び付けたものが格納される 」)(236頁左欄下から4行〜最終行) 。
Clients query the yellow-pages service for the address of one or more servers that (ｸ)「(訳文 クライアントは 以下のオペレーショprovide a given service with the operation 」「,ンによって,イエローページ・サービスに対し,ある所定のサービスを提供する1あるいは2以上のサーバーのアドレスを問い合わせる 」)(237頁左欄2行〜4 。
行)As another example, suppose the client wishes to retrieve the address of the (ｹ)「printer based on its location: e.g., " the printer in Rick's office". In this case, the client invokesthe lookupoperation with the mandatory attribute loc=rick. Any number of optional()」(訳文attributes are ignored because the mandatory attribute loc=rick selects a single server.「別の例として,クライアントが場所,例えば「のオフィスのプリンタ」な Rickどに基づいてプリンタのアドレスを取得したいとする。この場合,クライアントはloc=ricklookup loc=rick 必須属性をとして()オペレーションを要求する。必須属性によって唯一のサーバーが選択されるので,オプション属性がいくつあってもすべて無視される 」)(238頁右欄20行〜26行) 。
This section describes how the yellow-pages service is integrated with the internet (ｺ)「transport protocols, therby allowing clients from throughout the internet to access servers」(訳文「このセクションでは,イエローページ・サー within an autonomous system.ビスがどのようにしてインターネット・トランスポート・プロトコルに統合され,それによって,クライアントがインターネットの至る所から自立システム内のサーバーにアクセスできるのかを説明する。)(239頁右欄15行〜18行)「 」(訳文「ローカルA single host in the local system is designated as the flagship host;システム内の1つのホストが,フラグシップ・ホストとして指定される。)(239頁右欄23行〜24行)The system advertizes the flagship as offering a set of services to Internet clients by 「registering a set of resource recordspotentially one for each servicewith the domain - -」(訳文「システムは,1つのセットのリソース・レコード(リソーnaming system.ス・レコードは,潜在的には各サービスにつき1つである。)をドメイン名システムに登録することによって,サービスのセットをインターネット・クライアントに提供するものとして,フラグシップを広告する 」(239頁右欄25行〜29行。 。
注は省略)A client consults the domain name server to learn the address of a host at the (ｻ)「system 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 the」(訳文「クライアントは,システムにおいて特定のサービスを addresses of servers.提供するホストのアドレスを取得するためにドメイン名サーバーに問い合わせ,フラグシップ・ホストのアドレスが返される。その後,クライアントは,フラグシップ・ホスト上のウェルノウンポートあてに1あるいは2以上のパケットを送信することによって サーバーに接続する すると フラグシップ・ホストは そのパケッ ,。, ,トをシステム内のサーバーに転送する。このように,転送メカニズムは,ウェルノ。, ウンポートにおいてサーバーにアクセスする戦略と類似している フラグシップはシステムに対して 『ウェルノウンホスト』の役割を果たす。 ,転送メカニズムがTCP内でどのように実施されるかを更に詳細に検討する。フラグシップ・ホスト上で動作するTCPモジュールが,転送メカニズムを含むように変更される。転送メカニズムには,ウェルノウンポートをサーバーのアドレスに結び付けるテーブルが関連付けられる 」)(239頁右欄31行〜240頁左欄1 。
4行)When a packet arrives at the TCP module addressed for some port, the forwarding (ｼ) 「mechanism 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 mechanism」(訳文「あ sets the packet's destination address to the server's address and resends packet.るポートあてのパケットがTCPモジュールに到着すると,そのポートへの転送が行われるべきか,すなわち,テーブルにエントリが存在するかについて,転送メカニズムが問い合わせられる。そのパケットが新しいクライアントからである場合,フォワード・サーバーがランダムに入手可能なサーバーの1つを選択し,パケットをそのサーバーに転送する。すなわち,転送メカニズムは,パケットの宛先のアドレスをそのサーバーのアドレスに設定し,パケットを再送信する 」)(240頁左 。
欄18行〜25行)Subsequent packets sent on the same connection are forwarded to the same (ｽ)「」(訳文「同一の接続上で送信される後続のパケットは,同一のサーバーにserver.転送される 」)(240頁左欄29行〜30行) 。
by engaging the selection algorithm at the server rather than the client, the (ｾ)「yellow-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 a--(訳文「クライアントではな relatively small answera server addressis returned. 」くサーバーにおいて選択アルゴリズムを関与させることにより,イエローページ・サービスは「機能にデータ」よりむしろ「データに機能」を効果的に移動する。すなわち,選択アルゴリズムはデータベースと同じホスト上で実行し,相対的に小さい回答-サーバー・アドレス-が返される(241頁左欄下から13行〜8行) 。)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 this()」(訳文「転送 might be reasonable in the case of a connection oriented protocol e.g., TCPメカニズムはクライアントとサーバー間の仲介人の機能を果たす。これは,クライアントが間接参照から守られているため,トランスポートプロトコルに対してあらゆる変更を要求しないという優位点を有する。対照的に,プロトコルは,フラッグシップ・ホストがクライアントに対して,そのパケットをサーバー・ホストにリダイレクトする必要があると知らせるように修正できるであろう。これは接続指向プロトコル(例えばTCP)のケースでは妥当である可能性があるが 」)(241頁右 ,欄下から12行〜5行)イ上記各記載によれば,乙24刊行物(乙24の1)には,以下の構成(乙24発明)が開示されている(一部は,当事者間に争いがない。)。
A’インターネットの至る所からクライアントがローカル・サーバーにアクセスできるようにする方法である(235頁左欄9行〜12行)。
フラグシップ・ホスト上で動作する転送メカニズム()が,実forwarding mechanism際にそのサービスを提供するサーバーにクライアントを接続させる()(235 patch頁右欄10行〜14行)。
B’サービスを受けたいクライアントは,サービス名およびサーバーが持つべき任意の属性を指定して,イエローページ・サービスにサーバーのアドレスを問い合わせる(235頁左欄下から2行〜右欄2行)。
クライアントは,システムにおいて特定のサービスを提供するホストのアドレスを取得するためにドメイン名サーバーに問い合わせ,フラグシップ・ホストのアドレスが返される(239頁右欄31行〜240頁左欄2行)。
イエローページ・サーバーに提供されたサービス名等に対し返されたアドレスは,同サーバー上で稼動する選択アルゴリズムによって演算され抽出選択されたものであり,選択アルゴリズムの設定次第で,1つのサーバーのアドレスのみを抽出選択するようにできる(241頁左欄下から13行〜8行,弁論の全趣旨)。
’, 。, C サーバーのセットが イエローページ・サービスを実施する 各サーバーは使用可能なサービスおよびサーバーに関する情報のデータベースを維持する(235頁右欄下から7行〜5行)。
各イエローページ・サーバーには,システム内で使用できるサービスについての情報のデータベースが関連付けられる。データベースには,各サービスとそのサービスを提供するサーバーのセットとを結び付けたものが格納される 」)(236頁 。
左欄下から4行〜最終行)イエローページ・サービスは,サービス名をサーバーのアドレスにマッピングする(235頁左欄14行〜16行)。
D’イエローページ・サービスは,クライアントの要求を満たす1あるいは2以上のサーバーのアドレスを返送する(235頁右欄2行〜4行)。
クライアントは,ローカルシステム内のフラグシップ・ホスト上のウェルノウンポートあてに1あるいは2以上のパケットを送信する。
フラグシップ・ホストは,そのパケットをシステム内のサーバーに転送する(以上,240頁左欄2行〜5行)。
転送メカニズムは,パケットの宛先のアドレスをそのサーバーのアドレスに設定し,パケットを再送信する(240頁左欄23行〜25行)。
プロトコルは,フラグシップ・ホストがクライアントに対して,そのパケットをサーバー・ホストにリダイレクトする必要があると知らせるように修正できる(241頁右欄下から8行〜6行)。
G’クライアントが,ローカル・サーバーを使用できるように,フラグシップ・ホストに接続する方法( )一致点と相違点2ア一致点乙24発明と本件発明とを対比すると,両者は,下記イないしキの点で一応相違するが,その余の点で一致すると認められる。
イ相違点1(「URLにマッピングする」構成要件C)本件発明は「翻訳データベースを用いてURLにマッピングする」(構成要件C)ものであるが,乙24発明の構成C’は 「サービス名を(サービスを提供しよう ,とする)サーバーのアドレスにマッピングする」ものであり 「サーバーのアドレ ,ス」が「URL」に対応するか否かが明らかではない。
ウ相違点2(「REDIRECTコマンド中の前記URLを前記クライアントに返送する」構成要件D)本件発明は「REDIRECTコマンド中の前記URLを前記クライアントに返送する」(構成要件D)ものであるが,乙24発明は 「フラグシップ・ホストが, ,クライアントに対して,サーバー・ホストのアドレスを返送するとともに,そのパ」, ケットをサーバー・ホストにリダイレクトする必要があると知らせる ものであり?@「サーバー・ホストのアドレス」が「URL」に対応するか否かが明らかではなく(上記イの相違点1と同じ。),?A「リダイレクトする必要があると知らせる」ことが,本件発明の「REDIRECTコマンド」に相当するか否かが明らかではない。
エ相違点3(構成要件E及びF)乙24発明は,本件発明の構成要件E(「前記クライアントに前記URLを用いて情報を要求させ」),構成要件F(「前記URLにより識別されたページを前記クライアント側で表示する」)段階を有するか否かが明らかではない。
オ相違点4(「情報ページ」構成要件A及びG)乙24発明には,アクセス先がサーバーシステムに備わる「情報ページ」であることが明示されていない。
カ相違点5(「記述子」構成要件B)’ 「 」 , 乙24発明の構成B の サービス名およびサーバーが持つべき任意の属性 が本件発明の構成要件Bの「記述子」に相当するか明らかではない。
キ相違点6(「翻訳データベース」構成要件C)乙24発明の構成C’の「データベース」が本件発明の構成要件Cの「翻訳データベース」であるか否かが明らかではない。
なお原告は翻訳データベースの点は争うが乙24発明のイエローペー ,,「」,「ジ・サーバー」が構成要件C及びDの「ディレクトリサーバー」に相当することについては争わないものと認められるから,この点は自白したものとみなす。
( )相違点についての判断3ア相違点1(「URLにマッピングする」構成要件C)(ｱ)a乙28及び弁論の全趣旨によれば,乙28刊行物(「InｔeｒneｔUｓeｒ1995年2月号 1995年2月1日 ソフトバンク株式会社発行) 」,は,インターネット関連の一般の情報誌であるが,その「WWWサーバーで情報を発信するHTML攻略法」との項目の記事中に,以下の記載があることが認められる。
「インターネットにはさまざまな資源があり,従来,それらはやなどftptelnetのプログラムを使って利用されてきた。やなどのプログラムを使った資源 ftptelnetの利用法には,次のような2つの問題がある。
?@利用する資源に応じてさまざまなプログラムの利用法を習得する必要があること?Aそれぞれの資源どうしの間に関連付けがないこと, 。 WWW()は 上記の2つの問題を解決するためのアイデアである World Wide Webhttpつまり,WWWではURLという形式でインターネット上の資源を指示し,というプロトコルとというマークアップ言語によってインターネット上のHTML資源を有機的につなぎ合わせ,有効に利用することができるのである 」(117 。
頁右欄3行〜15行。注は省略)( )は WWWの中核となるプロトコルである(1 「 , 。」http HyperText Transfer Protocol17頁右欄下から6行〜5行)「URLはインターネット上の資源を統一的に示す方法で,WWWブラウザを使, 。」 うときや HTML形式の文章でインターネット上の資源を示すときに使われる(118頁左欄16行〜18行)「ホスト名はドメイン形式で記述するURLの書き方の中で,ホスト名とはWWWサービスを行っているホストの名前のことである 」(118頁右欄12行〜14行) 。
「?@WWWブラウザは,ホスト名をIPアドレスに変換してから利用する?Aインターネットでは,この変換にネーム・サーバーを使う?Bネーム・サーバーに問い合わせるときには ドメイン名がなくてはならない (1 , 」19頁左欄3行〜7行)bこれらの記載によれば,インターネット上のサービスとしてHTTPによるWWWサービスがあり,このWWWサービスを行っているホスト(サーバー)にアクセスするには,ドメイン名を含むURLを用いることは,本件出願当時,周知の技術であったと認められる。
(ｲ)したがって,インターネット上でサービスを提供する乙24発明において上記WWWサービスを採用することは,当業者が容易になし得たことであり,WWWサービスを採用した場合,サーバーのアドレスとして「URL」を選択するものにすることも,当業者が容易になし得たことと認められる。
イ相違点4(「情報ページ」構成要件A及びG)(ｱ)乙24発明において ローカル・サーバーにアクセス するとは 単にサー 「 」,バーコンピュータにアクセスすることではなく,そのサーバーコンピュータが提供する情報サービスにアクセスすることを意味すること,並びに乙28(「InｔeｒneｔUｓeｒ1995年2月号」1995年2月1日,ソフトバンク株式会社発行)の118〜119頁図1〜図4には,ウェブ・ブラウザが情報ページを表示することが示されていることは,原告において明らかに争わないから,これを自白したものとみなす。
(ｲ)したがって,インターネット上のサーバーシステムとしてWWWサービスを採用した乙24発明を「情報ページ」を表示するように構成することは,当業者が容易に想到し得たことであると認められる。
ウ相違点2(「REDIRECTコマンド中の前記URLを前記クライアントに返送する」構成要件D)及び相違点3(構成要件E及びF)(ｱ)本件明細書に 「REDIRECTコマンド」に関して,以下の記載があ ,ることは,当事者間に争いがない。
「メッセージ2では,ディレクトリサーバー602がREDIRECTをクライアント601に送信し,これには,データベース604から演算されたNUMBERに対する目標URLが記述されている。クライアントブラウザ601は続いて自動的にメッセージ3を送信し,このURLのコンテンツをGETする。商業者サーバー603はメッセージ4におけるこの情報を返送する 」(【0045】) 。
この記載によれば,本件発明の「REDIRECTコマンド」とは,サーバーからクライアントに送信され,クライアントが前記サーバーとは別のサーバーへ自動的に送信する命令であると認められる。
,’「」, (ｲ)前記( )イのとおり乙24発明の構成Dにおけるリダイレクトは1「フラグシップ・ホストがクライアントに対して,そのパケットをサーバー・ホストにリダイレクトする必要があると知らせる」ものである。
,「 」 (ｳ)a乙26によれば 乙26( UNIXUSER1994年12月号平成6年12月1日,ソフトバンク株式会社発行)には 「新インターネット構築 ,術第16回その4WWWサーバー用データ記述言語HTMWorld Wide WebL応用編 「今回は,WWWサーバーによる情報提供の応用的な仕掛けについて 」解説する 」(129頁)として,次の記載があることが認められる。 。
「…スクリプトからの出力として,ドキュメントの内容自身を出力する以CGILocation外に 別のドキュメントの位置を返すということもできる このためには , 。,:ヘッダーを用いて,:目的のドキュメントのURLLocationという形式の情報(ヘッダー)を返せばよい。これによって,既存のドキュメントをダイナミックに選択して表示できる 」(130頁左欄14行〜20行) 。
また,129頁の図1には,サーバーとクライアントがHTTPにおいて交互に送信する旨の記載がある。
bこれらの記載によると,HTTPにおいてURLを含む「REDIRECTコマンド」をクライアントに送信してクライアントにおいて自動的に情報ページを表示することは,本件出願当時,周知の技術であったと認められる。なお,被告Redirect は,同号証135頁左欄下から10行以下の「●他のURLに変換〜に指定したパターンにマッチした場合は,指定したURLにリクエストがRedirectそのままフォワードされる。サーバーが引っ越したような場合に用いる。URLは『ホスト名 』から書かなければならない 」との記載を指摘するが,上記記http:/// 。
載中の動作は,の動作を規定するの一部であり,サーバー側で実行httpdhttpd.confされるものであって,クライアントに別のドキュメントの位置を返送するものではなく,本件発明の「REDIRECTコマンド」とは異なるものと認められる。
したがって,HTTP上のものではない乙24発明において,HTTPによるWWWサービス(乙28)を採用してサービスを提供する際に,プロトコルによる相互接続性を保つため,乙24発明の「リダイレクト」に代えて,乙26に記載されているHTTPにおけるリダイレクト機能に関する周知技術を適用することにより,URLを含むREDIRECTコマンドをクライアントに送信して,クライアントにおいて自動的に情報ページを表示させるようにすること(構成要件D,E及びF)は,当業者が容易に想到し得たことと認められる。
cなお,乙24発明において,ローカルエリア・ネットワーク内でイエローページ・サービスを提供するイエローページ・サーバーとインターネット上でクライアントと接続されて転送メカニズムを実現するフラグシップ・ホストは,同一のものとは記載されていない。しかし,コンピュータの汎用性と高能力化の進展にかんがみると,両者を物理的に1つのサーバーで実現することは単なる設計的事項というべきであり,インターネット上で動作可能なプロトコルであるHTTPを前提とすれば,その具体的設計も当業者には自明のことであると認められる。
エ相違点5(「記述子」構成要件B)(ｱ)a原告は,本件発明の構成要件Bの「記述子」とは,電話番号・会社名・製品名等のURLとは異なる数字あるいは言葉であって,目標情報ページを識別する「特定かつ唯一のURL」と結び付くものであるが,乙24発明の「サービス名およびサーバーが持つべき任意の属性」は 「特定かつ唯一のURL」と結び付く ,ものではないから,本件発明の「記述子」とは異なる旨主張する。
b確かに,本件発明(請求項1)が 「記述子」と「URL」を書き分けてい ,ることからすると,構成要件Bの「記述子」は,電話番号・会社名・製品名等の数字あるいは言葉であり,URLを含まないと解することはできる。
cしかし 「特定かつ唯一のURL」と結び付く点については,本件明細書 ,には,本件発明の「記述子」の意味を「特定かつ唯一のURL」と結び付く何か特別の限定を伴ったものと解釈すべきことを窺わせる記載は認められない。それ自体は「特定かつ唯一のURL」と結び付かない「記述子」の送信に対し 「特定かつ ,唯一のURL」が返信されるのは 「翻訳データベース」の構成の問題であると考 ,えられる(この点は,本件訂正後であっても同様である。)。
(ｲ)乙24発明の構成B’は 「サービス名およびサーバーが持つべき任意の ,属性」を指定して,イエローページ・サービスにサーバーのアドレスを問い合わせるものであるから 「サービス名およびサーバーが持つべき任意の属性」は,UR ,Lを含んでおらず,本件発明の「記述子」に相当すると認められる。
よって,この点を相違点と認めることはできない。
オ相違点6(「翻訳データベース」構成要件C)(ｱ)前記ウのとおり,乙24発明において周知のリダイレクト機能を採用した, , 以上 REDIRECTコマンドに含まれるURLは1つでなければならないからURLを1つとするために,REDIRECTコマンドの送信前に,ユーザーに複数の候補の中から選択させるか,複数の候補の中からの選択の段階を省略するために,マッピングにより出力されてくるURLを1つとしなければならないことは,当然である。
したがって,URLを1つとするために,ユーザーに複数の候補の中から選択させるか,それともマッピングにより出力されてくるURLを1つとするかは,その長所,短所を総合して選択する設計事項であると認められる(例えば,選択の段階を省略すれば,複数の会社が同名であり,それぞれURLを有する場合に不都合が生じ得るが,大部分の場合に速やかに目指す情報ページに到達し得ることになる。)。したがって,複数の候補の中から選択させる段階を採用せず,マッピングにより出力されてくるURLを1つとした点は,当業者が容易に想到し得たことであると認められる。
(ｲ)a原告は,本件発明は,会社名等とURLを1対1に対応付けしたものであり,乙24発明とはこの点でも相違する旨主張する。
しかしながら,本件発明(請求項1)は 「翻訳データベースを用いてURLにマッ ,ピングする」(構成要件C)と規定するだけで,翻訳データベースの構造等につきそれ以上の限定はない(この点は [単一の目標URLに対応する]記述子を提供する段 ,階と限定した本件訂正発明においても同様であると考えられる。)。本件明細書の発明の詳細な説明等の中にも,原告主張のように限定して解釈すべきことを正当化する記載は見いだせない。
b前記( )イによれば,乙24発明のB’において,イエローページ・サー1バーに提供されたサービス名等に対し返されたアドレスは,同サーバー上で稼動する選択アルゴリズムによって演算され抽出選択されたものであり,選択アルゴリズムの設定次第で,1つのサーバーのアドレスのみを抽出選択するようにできるものである。
したがって,乙24発明が,どのようなデータベースとして構築するかの点で,本件発明と相違すると認めることはできない。
c仮に,本件発明が会社名等とURLを1対1に対応付けした構成を有するとしても,そのようにデータベースを構築することは,例えば,複数の会社が同名であり,それぞれURLを有する場合などに不都合が生じ得るが,他面で,データベースの検索アルゴリズムや構造を単純化し,ユーザーによる選択処理を省略したため処理速度が向上するなどの効果が得られることを総合衡量して決定される設計事項にすぎず,当業者にとって容易に想到し得たことと認められる。
カまとめ本件発明の奏する効果も,本件発明のように構成することから予想される範囲のものであり,格別のものとは認められない。
以上によれば,乙24発明を主引用例として本件発明のように構成することは当業者に容易に推考することができたことであり,本件発明は進歩性を欠き,本件特許は無効とされるべきものである。
よって,原告は,被告に対して本件特許を行使することができない(特許法104条の3)。
2争点6(訂正による無効理由の解消の存否)( )争点6-1(訂正要件及び充足)1原告の主張(ｱ)(訂正要件)は,被告において明らかに争わないからこれを自白したものとみなす。
( )争点6-2(進歩性の欠如等) 2ア追加の相違点の有無本件訂正により,前記1の争点5-3についての判断に加えて判断されるべき新たな相違点は生じていないから,前記1の争点5-3についての判断がそのまま本件訂正発明の進歩性の判断にも当てはまる。
イまとめしたがって,本件訂正発明は,依然として進歩性を欠くから,本件発明の無効理由は解消していない。
3結論以上によれば,原告の請求は,その余の点について判断するまでもなくいずれも理由がないから,棄却することとし,主文のとおり判決する。
追加
(別紙2)被告方法説明書【サーバー方式】1概要後記2項に記載の構成を備えた,インターネットに接続されたパソコンのユーザーに対し,当該パソコンのウェブブラウザのアドレスバーに任意の文字を記述することで目的のウェブページのURLを取得させ,当該ウェブページへのアクセスを提供する「()」に係る方法。サービス名はJapanNLIANativeLanguageInternetAddressSystem「」である。JAddressなお,()内の数字は,別紙図面1の番号に対応する。
2構成A’インターネットよりなるコンピュータネットワークを介してクライアントが情報ページに対してアクセスする際目的の情報ページのURLを取得する方法であっ,て,B’ユーザーがクライアントPCのウェブブラウザのアドレスバーに任意の日本語インターネットアドレス()を入力して(),同日本語インターネットアドレJAddress1ス()(正規URL)又は(’)(非正規URL)を予めプログラム?@の付加されたDNS22サーバー()に提供する段階()又は(’)と,NLIANameServer22C’-?T内において,付加プログラム?@が,クライアントPCNLIANameServerから送信された日本語インターネットアドレスが正規URLであるか否かを選別し(),正規URLの場合(),DNSサーバーの機能によって対応するIPアドレスを34クライアントPCに送り返し(),9C’-?U(原告の主張)正規URLでない場合「」から「サーバー」へとユーザー,NLIANameServerNLIAが入力した日本語インターネットアドレスを送信する段階と,(被告の主張)正規URLでない場合「サーバー」のIPアドレスをクライアントに送り返,NLIAす段階(’)と,4クライアントPCが,取得したIPアドレスの「サーバー」に向けて当初ユーNLIAザーが入力した日本語インターネットアドレスを問い合わせる段階()と,5’-?V日本語インターネットアドレスの送信を受けた「サーバー」が,当CNLIA該日本語インターネットアドレスに対応するURLを登録情報データベースから取得する段階()と,6’「」,,,DNLIAサーバーが当該URLをREDIRECTコマンドを利用してクライアントPCに送信する段階()と,7E’クライアントPCが,取得したURLを一旦DNSサーバーを経由して(),8対応するIPアドレスを取得し(),目的の情報ページの情報を要求する段階()と,910F’クライアントPCが,目的の情報ページを表示する段階と(),11G’以上の段階を備える情報ページのURLを取得する方法【プラグイン方式】1概要後記2項に記載の構成を備えた,インターネットに接続されたパソコンのユーザーに対し,当該パソコンのウェブブラウザのアドレスバーに任意の文字を記述することで目的のウェブページのURLを取得させ,当該ウェブページへのアクセスを提供す「」。「」る()に係る方法サービス名はJapanNLIANativeLanguageInternetSystemJAddressである。
なお,()内の数字は,別紙図面2の番号に対応する。
2構成A”インターネットよりなるコンピュータネットワークを介してクライアントが情報ページに対してアクセスする際目的の情報ページのURLを取得する方法であっ,て,B”-?TユーザーがクライアントPCのウェブブラウザのアドレスバーに任意の日本語インターネットアドレスを入力し(),予めクライアントに付加されたプログラ1ム?Aが,同日本語インターネットアドレス()(正規URL)又は(’)(非正規URL)22を正規URLであるか否かを選別する段階()と,3B”-?U入力された日本語インターネットアドレスが正規URLの場合(),ブラ2ウザの機能によって当該正規URLをDNSサーバーに送信してDNSサーバーの機能によって対応するIPアドレスをクライアントに送り返し()(),49正規URLでない場合(’),当該日本語インターネットアドレスをサーバー2NLIAへのURL形式に変更した上,ブラウザの機能によって当該変更したURL(”)をD2NSサーバーに送信して,DNSサーバーの機能によってサーバーのIPアドNLIAレスをクライアントPCに送り返す段階(’)と,4”,,B-?VクライアントPCが取得したIPアドレスのサーバーに向けてNLIA当初ユーザーが入力した日本語インターネットアドレスを問い合わせる段階()と,5C”問い合わせを受けたサーバーが,当該日本語インターネットアドレスNLIAに対応するURLを登録情報データベースから取得する段階()と,6D”サーバーが,当該URLを,REDIRECTコマンドを利用して,クNLIAライアントPCに送信する段階()と,7E”クライアントPCが,取得したURLを一旦DNSサーバーを経由して(),8対応するIPアドレスを取得し(),目的の情報ページの情報を要求する段階()と,910F”クライアントPCが,目的の情報ページを表示する段階と(),11G”以上の段階を備える情報ページのURLを取得する方法以上
裁判長裁判官 市川正巳
裁判官 大竹優子
裁判官 中村恭
すごい知財EXPO'22