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