ポートフォリオ機能| 関連審決 | 無効2007-800243 |
|---|
この判例には、下記の判例・審決が関連していると思われます。
| 審判番号（事件番号） | データベース | 権利 |
|---|---|---|
| 平成21ネ10055特許権侵害差止等請求控訴事件 | 判例 | 特許 |
| 平成19ワ2352特許権侵害差止等請求事件 | 判例 | 特許 |
| 平成18ネ10077特許権侵害差止請求控訴事件 | 判例 | 特許 |
| 平成20ネ10019特許権侵害差止等請求控訴事件 | 判例 | 特許 |
| 平成17ネ10005損害賠償等請求控訴事件 | 判例 | 特許 |
| 関連ワード | 方法の発明 / 新規性 / インターネット / アクセス / 進歩性(29条2項) / 容易に発明 / 引用発明の認定 / 発明特定事項 / 周知技術 / 技術的範囲 / 同一の発明 / 実施可能要件 / 発明の詳細な説明 / 発明が明確 / 発明の概要 / パリ条約 / 優先権 / 分割出願 / 実施料相当額 / 商標権 / 原出願日 / 出願経過 / 技術的意義 / 特許発明 / 実施 / 構成要件 / 差止請求(差止) / 侵害 / 損害額 / 乗じた額 / 実施料 / 不法行為(民法709条) / 同意 / 拒絶理由通知 / 請求の範囲 / 変更 / 訂正要件 / 取消判決 / |
|---|
| 元本PDF |
裁判所収録の全文PDFを見る
 |
|---|
| 事件 |
平成
20年
(ネ)
10085号
特許権侵害差止等請求控訴事件
|
|---|---|
| 当事者の表示別紙当事者目録記載のとおり | |
| 裁判所 | 知的財産高等裁判所 |
| 判決言渡日 | 2010/03/24 |
| 権利種別 | 特許権 |
| 訴訟類型 | 民事訴訟 |
| 主文 |
１原判決を次のとおり変更する。 (1)被控訴人は，別紙サービス目録記載のサービスを提供してはならない。 (2)被控訴人は，上記(1)のサービスの「Japan NLIASystem」における「NLIA サーバー」を除却し，「登録情報データベース」を消去せよ。 (3)被控訴人は，控訴人に対し，１４００万円及びこれに対する平成１９年２月１５日から支払済みまで年５分の割合による金員を支払え。 (4)控訴人のその余の請求を棄却する。 ２訴訟費用は，第１審，２審を通じ，これを５分し，その１を控訴人の，その余を被控訴人の各負担とする。 ３この判決は，第１項の(1)及び(3)に限り，仮に執行することができる。 |
| 事実及び理由 | |
|---|---|
|
全容
第1控訴の趣旨1原判決を取り消す。 (1)被控訴人は,「JAddress サービス」を提供してはならない。 (2)被控訴人は,「Japan NLIA System」における「NLIA サーバー」及び「登録情報データベース」を除却せよ。 (3)被控訴人は,控訴人に対し,9170万円及びこれに対する平成19年2月15日から支払済みまで年5分の割合による金員を支払え。 2訴訟費用は,第1,2審とも,被控訴人の負担とする。 第2事案の概要1本件は,控訴人が,被控訴人による別紙サービス目録記載のサービス(以下「被控訴人サービス」という。)の提供行為は,控訴人の有する第3762882号特許権(以下「本件特許権」といい,その特許請求の範囲の請求項1に係る発明及び同発明に係る特許を「本件発明」及び「本件特許」という。)を侵害するものであると主張して,?特許法100条1項に基づく被控訴人サービスの差止め,?同条2項に基づく同サービスに供された「NLIAサーバー」及び「登録情報データベース」の除却,?民法709条に基づく損害賠償及び遅延損害金の支払を請求する事案である。 2原判決は,本件特許に係る発明は,下記の引用例に記載された発明(以下「引用発明」という。)及び周知の技術に基づいて当業者が容易に発明をすることができたものであり,本件特許は特許無効審判により無効にされるべきものと認められるから,特許法104条の3により,控訴人が本件特許権を行使することはできないと判示して,控訴人の請求を棄却したため,控訴人がこれを不服として控訴した。 引用例:昭和63年にACM(アメリカ計算機学会)出版から発行された論文集「COMPUTER COMMUNICATION REVIEW Volume17,Number5 Special Issue」の「Part 8.RESOURCE SHARING IN DISTRIBUTED SYSTEMS」におけるLarry L.Peterson執筆に係る論文「A Yellow-Pages Service for a Local-Area Network」(乙24の1。訳文は乙24の2)3控訴人の本訴請求を判断する前提となる事実は,以下のとおりである。 (1)当事者控訴人は,インターネットを利用するシステムの開発・販売及びインターネットを利用した情報提供サービス業などを業とする株式会社である。 控訴人は,本件発明を実施して,インターネット等の利用者がパソコンのウェブブラウザのアドレスバー等に電話番号等の「インターネットナンバー」を入力することで特定のウェブサイトにアクセスすることができるようにするサービスを提供している。 被控訴人は,コンピュータシステムにおけるデータベースの構築・販売,情報処理サービス業及び情報提供サービス業,インターネットでの広告業務及び広告代理業,インターネットを利用する情報システム及び通信ネットワークの企画,設計・運用に関する受託等を業とする株式会社である。 被控訴人は,韓国法人である株式会社ネッピアダッコムの関連日本法人である。 (2)本件特許権ア控訴人は,以下の本件特許権を有している。 特許番号:第3762882号発明の名称:インターネットサーバーのアクセス管理およびモニタシステム原出願日:平成8年6月3日(特願平9-503084号)パリ条約による優先権主張日:平成7年6月7日(米国)分割出願日:平成13年7月9日登録日:平成18年1月20日特許請求の範囲の請求項1の記載:別紙特許請求の範囲の記載2のとおりイ本件発明の構成要件を分説すると,以下のAないしG(以下,順に「構成要件A」ないし「構成要件G」という。)のとおりである。 Aインターネットよりなるコンピュータネットワークを介したクライアントからサーバーシステムへの情報ページに対するアクセスを提供する方法であって,B前記クライアントにおいて記述子を提供する段階と,Cディレクトリサーバーが,前記記述子を前記ディレクトリサーバーに存在する翻訳データベースを用いてURLにマッピングする段階と,D前記ディレクトリサーバーが,REDIRECTコマンド中の前記URLを前記クライアントに返送する段階と,E前記クライアントに前記URLを用いて情報を要求させる段階と,F前記URLにより識別されたページを前記クライアント側で表示する段階とGを備えた情報ページに対するアクセス方法。 ウ本件特許の出願後の経過は,以下のとおりである。 (ア)第1回拒絶理由通知特許庁審査官は,平成17年4月15日付けで,?本件特許権の当時の請求項1ないし10に係る出願について,各動作の主体がどのハードウェア手段であるかが不明である,?請求項3の「REDIRECTコマンド中のURLをクライアントに返送してクライアントにURLを用いて情報を要求させるサーバーシステムにトランザクションデータベースが常駐する」なる記載の意味が不明である等の理由で,拒絶理由を通知した。 (イ)第1回補正控訴人は,上記(ア)の?の点については,平成17年6月20日,請求項1,3及び10を削除し,請求項2に請求項3及び10を併合して補正後の請求項1を別紙特許請求の範囲の記載1のとおりとする補正をした。 なお,控訴人は,同日付けの意見書において,上記補正の理由について,次のとおり主張した。 「補正前の請求項1〜10に係る発明の,各動作の主体がどのハードウェア手段であるのかが不明である,に対しては,前述の補正後の請求項1のように補正して対処し,各動作の主体のハードウェア手段を明確にしております。すなわち,記述子を提供する段階はクライアントが行い,記述子をディレクトリサーバーに存在する翻訳データベースを用いてURLにマッピングする段階はディレクトリサーバーが行い,REDIRECTコマンド中のURLをクライアントに返送してクライアントにURLを用いて情報を要求させる段階はディレクトリサーバーが行い,URLにより識別されたページを表示する段階はクライアントが行うものであります。」,「本願発明では,このような長く複雑なURLに代えて,このURLに対応して誰でも簡単かつ容易に入力できる電話番号,会社名,製品名などを入力するだけで,目標とするURLのウェブサイトへアクセスできるようにしたものであります。」また,控訴人は,上記(ア)の?の点については,同意見書において,「補正前の請求項3の内容を明確にして,補正後の請求項1に併合しております。すなわち,ディレクトリサーバーが,REDIRECTコマンド中のURLをクライアントに返送してクライアントにURLを用いて情報を要求させるものであり,」との意見を述べ,同日付けの手続補正書において,補正後の請求項1の記載を「前記ディレクトリサーバーが,REDIRECTコマンド中の前記URLを前記クライアントに返送して前記クライアントに前記URLを用いて情報を要求させる段階と,」と補正した。 (ウ)第2回拒絶理由通知特許庁審査官は,平成17年9月28日付けで,本件特許権の上記(イ)の第1回補正後の請求項1ないし7に係る出願について,進歩性欠如を理由とする拒絶理由を通知した。 (エ)第2回補正控訴人は,平成17年12月5日,請求項1を別紙特許請求の範囲の記載2のとおりとする補正をした。 なお,控訴人は,同日付け意見書において,補正の理由について,「1つの段階から,URLの返送段階と,そのURLを用いた情報要求段階との2つの段階に分けて表現し,記載の明瞭化を図りました。」と主張した。 また,控訴人は,同意見書において,本件発明の特徴について,「本願発明は,インターネット上において,ユーザが電話番号,会社名,製品名等を用いて商業サービスサイトにアクセスできる,インターネットよりなるコンピュータネットワークを介したクライアントからサーバーシステムへの情報ページに対するアクセス方法に関する技術であります。すなわち,本願発明が適用するようなインターネットの技術分野では,ウェブサイトへアクセスする際に,長く複雑なURLを入力する必要があるが,本願発明では,このような長く複雑なURLに代えて,このURLに対応して誰でも簡単かつ容易に入力できる電話番号,会社名,製品名等を入力するだけで,目標とするURLのウェブサイトへアクセスできるようにしたものであります。」と説明している。 (オ) 特許査定特許庁審査官は,平成18年1月5日,上記補正内容で特許査定した。 エ本件特許に対する無効審判請求及びその後の経過は,以下のとおりである。 (ア)無効審判請求被控訴人は,平成19年10月31日付け審判請求書(乙31)により,本件特許(請求項1ないし7)について,無効審判を請求した(無効2007-800243)。 (イ)訂正請求控訴人は,平成20年1月23日付け訂正請求書(甲42)により,本件明細書の特許請求の範囲の請求項1を別紙特許請求の範囲の記載3のとおり訂正する等の訂正(以下「本件訂正」といい,訂正後の発明を「本件訂正発明」という。)を請求した。 (ウ)無効審決特許庁審判官は,平成20年6月26日,本件訂正を認めたが,訂正後の請求項1ないし7の発明は,進歩性欠如を理由として無効とする旨の審決をした(乙32)。 (エ)審決取消判決控訴人は,知的財産高等裁判所に対し,上記無効審決の取消しを求める訴えを提起した。同裁判所は,平成21年11月5日,同審決を取り消す旨の判決をし,同事件の被告である被控訴人は,同年11月19日,同判決を不服として上告及び上告受理の申立てをした。 (3)被控訴人の行為ア被控訴人サービスの開始被控訴人は,平成18年2月ころ,被控訴人サービス(なお,同サービスにおいて採用されている方法を「被控訴人方法」という。)を開設した上,サイト運営者のトライアル登録サービス「Test Operation」を開始し,同年9月5日,その優先登録サービス「Sunrise Operation」を開始したが,これらによる総登録件数は,13万6826件である。 イ被控訴人方法被控訴人方法にはサーバー方式及びプラグイン方式とがあるところ,これらの構成は,別紙構成一覧の1及び2にそれぞれ記載のとおりである。 ただし,サーバー方式のC’-?について,控訴人が別紙構成一覧記載のとおりであると主張するのに対し,被控訴人は「正規URLでない場合,『NLIAサーバー』のIPアドレスをクライアントに送り返す段階(4’)と,クライアントPCが,取得したIPアドレスの『NLIA サーバー』に向けて当初ユーザーが入力した日本語インターネットアドレスを問い合わせる段階(5)と,」であると主張しており,この点については理由中において判断する。 ウ構成要件の一部充足(弁論の全趣旨)被控訴人方法は,本件発明の構成要件のうち,少なくとも構成要件A,D及びGを充足する。 4本件訴訟の争点は,下記(1)ないし(8)のとおりである。 (1)争点1:構成要件Bの充足(2)争点2:構成要件Cの充足(3)争点3:構成要件Eの充足(4)争点4:構成要件Fの充足(5)争点5:本件特許の無効理由の存否ア争点5-1:開示義務違反(特許法36条4項,同条6項1号及び2号)イ争点5-2:新規性の欠如ウ争点5-3:進歩性の欠如(6)争点6:本件訂正による無効理由の解消の成否ア争点6-1:訂正要件及び充足イ争点6-2:進歩性の欠如等(7)争点7:被控訴人の侵害主体性(8)争点8:損害の発生及び額第3当事者の主張【原審における主張】当事者の原審における主張は,原判決中の略称を本判決の略称に読み替え,「争点5:本件特許権の無効理由の存否」(原判決9頁14行)を「争点5:本件特許の無効理由の存否」と,「争点6:本件訂正による無効理由の解消の存否」(同9頁18行及び39頁17行)を「争点6:本件訂正による無効理由の解消の成否」を改めるほか,原判決「3争点に関する当事者の主張」(原判決9頁23行〜43頁21行。ただし,争点8については当審において撤回されているため,これを除く。)のとおりであるから,これを引用する。 【当審における主張】1争点6-2(進歩性の欠如等)について〔控訴人の主張〕(1)進歩性について原判決は,乙24を主引例として本件発明の進歩性を否定した上,本件訂正発明についても同様であるとし,本件特許は特許無効審判により無効にされるべきものと認められると判断したが,この判断は誤りである。 ア乙24の主引例としての適格性本件訂正発明は,クライアントにおいて提供されるある記述子と特定かつ単一のURLとを結びつけ,同URLにより特定される情報ページにアクセスしようとするものであるのに対して,引用発明は,職業別電話帳(Yellow Pages)に由来するタイトルからもわかるとおり,クライアントが要求する「サービス名及び属性」という条件に適合するサーバーのアドレスをイントラネット上で検索し,返された検索結果からクライアントが任意のアドレスを選択するものにすぎない。 つまり,本件訂正発明が「記述子」と特定の「URL」とを1対1又は多対1で対応付け,「REDIRECTコマンド」を利用することによって,クライアントが自動的に目標とする情報サイトへアクセスすることができるようにしたことを本質的特徴とするのに対し,引用発明はサービス名及び属性条件という一定の条件を満たす不特定のサーバーを探す検索サービスであり,これらの技術思想は異なる。 したがって,そもそも乙24を主引例として進歩性の判断を行った点において原判決は誤っている。 イ引用発明の認定の誤り原判決は,乙24の記載から「1つのサーバーのアドレスのみを抽出選択」する場合を切り出すとともに,「サービス名をサーバーのアドレスにマッピング」するものを引用発明として認定しているが,乙24に記載された発明はあくまでも「サービス名及び属性」という条件を充足する1又は2以上の不特定のサーバーのアドレスが返されるものであることを前提としており,ここから上記のように限定された発明を認定することはできない。 ウ本件訂正発明と引用発明との相違点についての判断の誤り(ア)「アドレス」と「URL」原判決は,引用発明の「アドレス」から,本件訂正発明の「URL」は容易想到であると判断したが,引用発明はイントラネットに関する発明にすぎないものであって,サーバーがインターネットへ直接接続されることを想定していない引用発明における「アドレス」から,インターネット上の,特にWorld-Wide-Webに係る規約である「URL」を選択することが容易であるということはできない。また,乙24が発行された1988年は,World-Wide-Webが発表される1991年以前であり,乙24は「アドレス」としてWorld-Wide-Webに係る「URL」を想定していない。 (イ)データベースの設計原判決は,引用発明の「データベース」を「サービス名及び属性」と特定かつ単一の「アドレス」とを結びつけたデータベースへと構成を変更することは設計事項にすぎないと判断したが,引用発明のように,不特定のサーバーについてユーザーが求める条件を入力し,検索結果としてサーバーのアドレスが返されるか,あるいは,本件訂正発明のように,当初から特定の目標を意図してその結果として特定かつ単一のURLが返されるかは,技術思想としての相違というべきである。 (ウ)「REDIRECTコマンド中の前記URL」原判決は,相違点2及び3の判断に関して,乙26の記載及び図1を引用した上,本件訂正発明の「REDIRECTコマンド中の前記URL」を用いることは容易想到であったと判断した。 しかしながら,引用発明における「リダイレクション」に係る構成において,遠隔クライアントが,イエローページ・サービスを実現する「ローカル・サーバー」へと直接アクセスすることはできない。また,乙24に記載されるようにTCPプロトコルを前提とする引用発明において,フラッグシップ・ホストからクライアントへと送信されるパケット情報に基づき,クライアントがサーバー・ホストへ再接続することはできない。したがって,乙26に記載されたリダイレクト機能に関する周知技術を引用発明に適用することはできない。 他方,乙26の「Locationヘッダー」に基づいて「REDIRECTコマンド中の前記URL」という構成が容易想到であるということもできない。 さらに,原判決は,実質的に乙26を引用例として認定するものであるところ,被控訴人は乙26を引用例として主張していない。 (エ)1つのサーバーによる実現原判決は,相違点2及び3の判断に関して,コンピュータの汎用性と高能力化の進展にかんがみると,フラッグシップ・ホストとイエローページ・サーバーとを物理的に1つのサーバーで実現することは単なる設計的事項であると判断しているが,コンピュータ・ネットワークの世界における「サーバー」とは「クライアントからの要求に対して何らかのサービスを提供するシステムのこと」を意味するものであって,「サーバー」が1つであるか複数であるかはそのクライアントに提供する機能に着目して区別されるものであるから,上記判断は誤りである。 (オ)小括以上のとおり,原判決による本件訂正発明と引用発明との相違点についての判断は誤りであり,本件訂正発明は引用発明に基づいて当業者が容易に発明をすることができたものではない。 (2)構成要件の充足本件訂正発明の構成要件は第2の3(2)エ(イ)のとおりであり,被控訴人方法の構成は別紙構成一覧1及び2記載のとおりであるところ,被控訴人方法の当該各構成は本件訂正発明の各構成要件を充足するから,同方法は本件訂正発明の技術的範囲に属する。 〔被控訴人の主張〕(1)進歩性について以下のとおり,控訴人の主張は失当であり,原判決による本件訂正発明の進歩性についての判断に誤りはない。 ア乙24の主引例としての適格性乙24の記載から,同記載の発明に係る技術がローカルエリア・ネットワーク内に限ったものでないことは明らかであり,また,ネットワーク外の目的のサーバーに転送又はリダイレクトする技術であることも明らかであるから,本件訂正発明と引用発明とでその技術思想が異なるとの控訴人の主張は失当である。 イ引用発明の認定の誤り控訴人は,原判決による乙24に基づく引用発明の認定を論難するが,乙24に1つのサーバーのアドレスを抽出選択する構成が開示されていることは明白であり,「サーバーのアドレスにサービス名をマッピングする」と明記されているから,控訴人の主張はいずれも失当である。 ウ本件訂正発明と引用発明との相違点についての判断の誤り(ア)「アドレス」と「URL」本件特許出願時の公知刊行物である乙28に「URLはインターネット上の資源を統一的に示す方法で,WWWブラウザを使うときや,HTML形式の文章でインターネット上の資源を示すときに使われる」との記載があるように,本件特許出願時においてインターネット上のサービスとしてHTTPによるWWWがあり,このWWWにおいてサーバーにアクセスするためにURLを用いることは,当業者に周知の技術であったから,乙24におけるアドレスがURLを意識していたかどうかに関わりなく,引用発明におけるアドレスを,すでにサーバーの住所を表すものとして周知になっていたURLで表記することは,当業者に自明であったものであり,控訴人の主張は失当である。 (イ)データベースの設計「記述子」が単一の目標URLに対応するものであるとしても,クライアントから提供されるものであることに変わりはなく,いかなる「記述子」がクライアントから示された場合にいかなるURLを対応させて返送するかは,ひとえにデータベースをどのように構築し,どのような記述子とURLを登録するか次第であるから,引用発明の「データベース」を「サービス名及び属性」と特定かつ単一の「アドレス」とを結びつけたデータベースへと構成を変更することは設計事項にすぎないとした原判決の判断に誤りはない。 (ウ)「REDIRECTコマンド中の前記URL」控訴人は,引用発明において,クライアントがローカル・サーバーに直接接続される技術ではないと主張するが,引用発明は,転送されたサーバーとクライアントとが直接に接続される技術であって,全体として当然にアプリケーション層を含めたコンピュータ通信に関する技術であり,ここで示されたリダイレクトが,TCPのみに限定された技術と理解すべき必然性はどこにもないから,控訴人の主張は失当である。 また,本件発明における「REDIRECTコマンド」とは「サーバーからクライアントに送信され,クライアントが前記サーバーとは別のサーバーへ自動的に送信する命令」と認められるところ,乙26には,目的のドキュメントを表示するためにそのURLを含んだLocationヘッダーを返せばよいことが記載されており,これは,それ以外の作業を必要とせずに(自動的に)目的のドキュメントが表示されることを意味するから,この挙動は「REDIRECTコマンド」のものと同じであり,「REDIRECTコマンド中の前記URL」という構成が容易想到であるとの原判決の判断に誤りはなく,控訴人の主張は失当である。 さらに,乙26は,REDIRECTコマンドに関する周知の技術を説明するために被控訴人が提出した証拠であり,この証拠から原判決が周知の技術を認定することに何ら問題はない。 (エ)1つのサーバーによる実現控訴人が主張するとおり,「サーバー」が「クライアントからの要求に対して何らかのサービスを提供するシステム」を意味することは否定しないが,単に「サーバー」といったときは,サーバーソフトウェアを指す場合も,サーバーコンピュータを指す場合もある。原判決は,イエローページ・サーバーの機能とフラッグシップ・ホストの機能とを併せた機能を提供するハードウェアとしての1つのサーバーとすることが単なる設計的事項であるという当然のことを判示したにすぎず,この点に誤りはないのであり,控訴人の主張は失当である。 (オ)小括以上のとおり,控訴人の主張はいずれも失当であり,本件訂正発明は引用発明に基づいて当業者が容易に発明をすることができたとの原判決の判断に誤りはない。 (2)構成要件の充足被控訴人方法は本件訂正発明の技術的範囲に属しない。 2争点8(損害の発生及び額)について〔控訴人の主張〕控訴人の損害は,特許法102条3項に基づいて,以下のとおり算定されるべきである。 (1)被控訴人は,過去において本件発明を実施していただけでなく,現在においても実施しているものであり,仮に,被控訴人サービス(JAddress)が商用サービスに移行していないなどの事情により被控訴人が現実には登録申請・受付及び/又は登録によって売上げを上げていないとしても,損害が発生していることに変わりはない。 (2)被控訴人の13万6826件の登録件数のうち,無料登録件数3件を除いた13万6823件が仮登録であって,現実の売上げが発生していないとの事情を前提としても,特許法102条3項にいう「特許発明の実施に対し受けるべき金銭の額に相当する額」は,無料登録件数3件について1件当たりの登録料金である3万1500円に通常の実施料率4%を乗じた額,仮登録件数13万6823件について通常の実施料率の半分である2%を乗じた額に基づいて,それぞれ登録件数を乗じた額である(3万1500円×2%×13万6823件+3万1500円×4%×3件=)8620万2270円と算定すべきである。 〔被控訴人の主張〕(1)被控訴人は,本件紛争が発生したため,被控訴人サービスの商用的な実施には至っておらず,被控訴人に利益がないことはもちろん,控訴人に損害は発生していない。 (2)被控訴人における登録件数が13万6826件であることは認めるが,その余の控訴人の主張についてはいずれも争う。 第4当裁判所の判断1構成要件の充足性(争点1ないし4)について(1)構成要件Bア構成要件Bは,「前記クライアントにおいて記述子を提供する段階と,」と規定するものである。 そして,特許請求の範囲の記載によると,本件発明において,「記述子」は翻訳データベースによりURLにマッピングされ,そのURLがクライアントに返送され,返送されたURLを用いてクライアントは情報を要求することになるのであるから,構成要件Bにおける「記述子」がURLを含まないことは明らかである。 しかしながら,本件特許出願に係る明細書(以下「本件明細書」という。)の発明の詳細な説明には,「【0041】本発明の一構成では,商業者のサービスにアクセスするためにユーザが従来の電話番号,またはその他の識別子を利用できるようにする便が設けられている。」,「【0042】別の実施形態では,従来のブラウザを備えた形で,クライアント601が“ダイヤル”コマンドの場所に電話番号,またはその他の識別子を入れることを促すディレクトリサーバー602により提供された書式ページを用いる。」及び「【0044】別の実施形態では,数字以外の識別子を設けることができる。例えば,ユーザは会社名または製品名を不正確なつづりで記入することがある。このような場合“soundex”または他の音声マッピングが同じ目標URLに対するマップと類似して響く語を許容するため用いることができる。また,製品名または内線と組み合わせた電話番号のような複数の識別子も使用可能である。」との記載があるところ,これらの記載がクライアントが提供する「記述子」を特定の種類のものに限定する趣旨のものとは解されない。 そうすると,構成要件Bにおける「記述子」は,URLそのものを含まないと解されるほかには,特段の限定がないものと解されるべきである。 イ他方,被控訴人方法のうち,サーバー方式は,構成B’「ユーザーがクライアントPCのウェブブラウザのアドレスバーに任意の日本語インターネットアドレス(JAddress)を入力して(1),同日本語インターネットアドレス(2)(正規URL)又は(2’)(非正規URL)を予めプログラム?の付加されたDNSサーバー(NLIA NameServer)に提供する段階(2)又は(2’)と,」を備えるものであり,また,プラグイン方式は,同B”-?「ユーザーがクライアントPCのウェブブラウザのアドレスバーに任意の日本語インターネットアドレスを入力し(1),予めクライアントに付加されたプログラム?が,同日本語インターネットアドレス(2)(正規URL)又は(2’)(非正規URL)を正規URLであるか否かを選別する段階(3)と,」を備えるものである。 そうすると,被控訴人方法は,いずれもユーザーがクライアントPCにおいて任意の日本語インターネットアドレスを入力するという段階を含むところ,日本語インターネットアドレス(2)には,正規URLと非正規URLとが含まれることが想定され得るが,被控訴人方法において非正規URLが提供される場合が存在する以上,被控訴人方法はクライアントにおいても「記述子」を提供する段階を含むものというべきである。 ウ被控訴人は,本件発明における記述子の提供方法について,被控訴人方法のようにクライアントPCのウェブブラウザのアドレスバーに入力する方法によるものは含まれないと主張するが,構成要件Bが記述子の「提供の方法」を限定するものでないことは上記アのとおりであるから,被控訴人の主張を採用することはできない。 エしたがって,被控訴人方法は,本件発明の構成要件Bを充足する。 (2)構成要件Cア構成要件Cは「ディレクトリサーバーが,前記記述子を前記ディレクトリサーバーに存在する翻訳データベースを用いてURLにマッピングする段階と,」と規定するものである。なお,「前記記述子」は,上記(1)において説示したとおり,URLを含まないものと解される。 イ他方,被控訴人方法の構成のうち,クライアントによって入力される日本語インターネットアドレスが正規URLでない場合について,被控訴人の主張に沿ってみてみると,サーバー方式は,構成C’-?「NLIA Name Server内において,付加プログラム?が,クライアントPCから送信された日本語インターネットアドレスが正規URLであるか否かを選別し(3),」,同C’-?「正規URLでない場合,「NLIAサーバー」のIPアドレスをクライアントに送り返す段階(4’)と,クライアントPCが,取得したIPアドレスの「NLIA サーバー」に向けて当初ユーザーが入力した日本語インターネットアドレスを問い合わせる段階(5)と,」及び同C’-?「日本語インターネットアドレスの送信を受けた「NLIA サーバー」が,当該日本語インターネットアドレスに対応するURLを登録情報データベースから取得する段階(6)と,」を備えるものであり,また,プラグイン方式は,構成B”-?「入力された日本語インターネットアドレスが…正規URLでない場合(2’),当該日本語インターネットアドレスをNLIA サーバーへのURL形式に変更した上,ブラウザの機能によって当該変更したURL(2”)をDNSサーバーに送信して,DNSサーバーの機能によってNLIA サーバーのIPアドレスをクライアントPCに送り返す段階(4’)と,」,同B”-?「クライアントPCが,取得したIPアドレスのNLIAサーバーに向けて,当初ユーザーが入力した日本語インターネットアドレスを問い合わせる段階(5)と,」及び同C”「問い合わせを受けたNLIAサーバーが,当該日本語インターネットアドレスに対応するURLを登録情報データベースから取得する段階(6)と,」を備えるものである。 ウしかるところ,被控訴人方法は,いずれも登録情報データベースから非正規URLである日本語インターネットアドレスに対応するURLを取得する段階を備えるものであるから,被控訴人方法は本件発明の構成要件Cを充足することになる。 この点について,被控訴人は,被控訴人方法の構成は,正規URLと非正規URLとを選別する段階を必須とするものであり,非正規URLであると選別された記述子に限って「NLIA」サーバーに送られ,サーバー方式において上記選別の段階を担う「NLIA Name Server」は「NLIAサーバー」とは別のサーバーであると主張するが,本件発明における「記述子」が正規URLを含まないものであることは上記(1)のとおりであり,本件発明の構成要件をすべて充足するアクセス方法に正規URLの処理に関する機能が加わったり,途中にクライアントPCを介する処理が加わったりしても,そのアクセス方法が本件発明の技術的範囲に含まれなくなるものではないから,被控訴人の主張は失当である。 そうすると,本件発明との対比において必要となる被控訴人方法の構成は,別紙構成一覧に記載したものに尽きるのであり,被控訴人方法のサーバー方式に係るものは,少なくとも同記載のC’-?の構成を備えるものとして認定することができる。 また,被控訴人は,被控訴人方法は,記述子をアドレスバーに入力するものであるから,構成要件Cの「前記記述子」を充足しないとも主張するが,この主張を採用することができないことは上記(1)のとおりである。 エしたがって,被控訴人方法の構成は別紙構成一覧に記載のとおりのものであり,被控訴人方法は,本件発明の構成要件Cを充足するものである。 (3)構成要件E及びFア本件発明の構成要件Eは「前記クライアントに前記URLを用いて情報を要求させる段階と,」と規定し,同Fは「前記URLにより識別されたページを前記クライアント側で表示する段階と」と規定する。 イ他方,被控訴人方法のうち,サーバー方式は,構成E’「クライアントPCが,取得したURLを一旦DNSサーバーを経由して(8),対応するIPアドレスを取得し(9),目的の情報ページの情報を要求する段階(10)と,」及び同F’「クライアントPCが,目的の情報ページを表示する段階と(11),」を備えるものであり,また,プラグイン方式は,構成E”「クライアントPCが,取得したURLを一旦DNSサーバーを経由して(8),対応するIPアドレスを取得し(9),目的の情報ページの情報を要求する段階(10)と,」及び同F”「クライアントPCが,目的の情報ページを表示する段階と(11),」を備えるものである。 ウそして,被控訴人方法における「取得したURLを一旦DNSサーバーを経由して(8),対応するIPアドレスを取得し(9),」とは,クライアントが情報を要求する前提として,ディレクトリサーバーから返送されたURLを用いていることにほかならず,被控訴人方法においては,このIPアドレスによって「目的の情報ページの情報を要求する」ものであるから,被控訴人方法は本件発明の構成要件Eを充足することになる。 また,本件発明の構成要件Fにおける「URLにより識別されたページ」とは,URLによって特定されたクライアントが目指すページを意味することは特許請求の範囲の記載から明らかであるところ,被控訴人方法の構成F’及びF”における「目的の情報ページ」とは,正にこのような「URLにより識別されたページ」であるから,このようなページが「クライアントPC」,すなわち「クライアント側」で表示される段階を備える被控訴人方法は,本件発明の構成要件Fを充足するものである。 エ被控訴人は,構成要件Eの充足性に関し,本件発明は方法の発明であり,出願経過における控訴人の意見書の記載からも,構成要件Eの段階は,構成要件Dの段階である「前記ディレクトリサーバーが,REDIRECTコマンド中の前記URLを前記クライアントに返送する段階」と時系列的に異なる段階として行われる必要があるものと解釈すべきであるとした上,被控訴人方法においては,クライアントのブラウザのアドレスバーを利用した標準的なプロトコルを用いて,「NLIAサーバー」からアドレスバーに所期のURLを返しさえすれば,その後は,クライアントに備わっているブラウザが当該URLによって識別されたページを(DNSサーバーを介して)取得し,クライアントPCに表示するものであり,本件発明のように構成要件Dに相当する段階と別の段階として構成要件Eに相当する段階を備えているものではないと主張する。 しかしながら,本件明細書の発明の詳細な説明をみると,本件発明の概要について「【0012】認証サーバーは,次いでこのSIDが付加されたオリジナルURLから成る新しい要求を,REDIRECTによってクライアントに送出する。新しいURLにより形成された修正要求は,自動的にクライアントブラウザによりコンテンツサーバーに送出される。」との記載があるほか,実施形態について「【0045】メッセージ2では,ディレクトリサーバー602がREDIRECTをクライアント601に送信し,これには,データベース604から演算されたNUMBERに対する目標URLが記述されている。クライアントブラウザ601は続いて自動的にメッセージ3を送信し,このURLのコンテンツをGETする。サーバー602が最終的なURLに対する翻訳を行い,ページよりはむしろREDIRECTをクライアント601に送信するため,メッセージ4のドキュメントは最初のダイヤル入力以上のユーザーの行為なしで入手される。」及び「【0047】“ダイヤル”コマンドおよびその実施の利点の中には,従来の電話番号および他の識別子と互換性を有する,インターネットにアクセスする改善された方法がある。商業者はコンタクト情報のインターネット特定書式を提供するための印刷物またはテレビ広告を変更する必要がなく,ユーザはURLについて知る必要がない。」との記載があるのであって,この記載によると,本件発明においても,REDIRECTを送信し,この送信されるデータ中に目標URLが記述されているのであり,アクセス方法の段階としては,構成要件Dの段階と同Eの段階とは論理的に順次発生するものである。 他方,被控訴人方法においても,サーバー方式の構成D’及び同E’,プラグイン方式の構成D”及び同E”において,それぞれREDIRECTコマンドを利用してURLを送信する段階とURLに基づいて情報を要求する段階を実現しているのであり,これらの段階が順次発生するものであることは論理的に明らかであるから,被控訴人方法も,これらの順次発生する段階を備えているというべきである。 なお,被控訴人の主張が被控訴人方法が構成要件Eの段階のみを実現する独立の構成を備えていないという趣旨であるとしても,一般に,デジタル通信においては,複数のデータを同時に送信することが可能であり,これら複数のデータを命令の形式で構成することも可能であるところ,本件明細書における上記各記載によると,本件発明は,REDIRECTコマンドとともにクライアントに返送されたURLに基づいて,自動的にクライアントに情報を要求させ(,同要求に係るURLによって識別されたページを自動的にクライアント側において表示す)るものを含むと解することに支障はなく,上記のとおり,そのようなものも構成要件Dの段階と同Eの段階を順次発生させるものと解すべきであるから,被控訴人方法は本件発明の構成要件D及び同Eを充足することになる。 控訴人は,本件特許の出願経過において,構成要件D及びEを別々の段階として書き分けることを内容とする平成17年12月5日付け手続補正書による補正についての意見書において,「1つの段階から,URLの返送段階と,そのURLを用いた情報要求段階との2つの段階に分けて表現し,記載の明瞭化を図りました。」と記載しているが,この記載は,本件発明が備えるべき段階を書き分けることによって発明特定事項を明瞭にするものと理解することができるものであり,上記に説示したところによると,上記補正によって,本件発明が,構成要件Dに相当する段階と同Eに相当する段階が時系列的に別の段階としてそれぞれ独立して存在するものに限定されると理解することはできない。 したがって,被控訴人の主張を採用することはできない。 また,被控訴人は,構成要件Fについても,上記と同様の主張をするが,これを採用することができないことは,上記のとおりである。 (4)小括以上のとおり,被控訴人方法は本件発明の構成要件B,C,E及びFを充足するところ,前記第2の3(3)ウのとおり,被控訴人方法は本件発明の構成要件A,D及びGを充足するから,被控訴人方法は本件発明の技術的範囲に属するものといわなければならない。 なお,本件訂正発明においては,本件発明の構成要件Bにおける「記述子」が「単一の目標URLに対応する記述子」と,同Eにおける「情報を要求する段階」が「情報を自動的に要求する段階」と,それぞれ訂正されている。これらのうち,前者は,「記述子」がURLを含まないものであることを前提として,これを「単一の目標URLに対応する」ものに限定するものであるところ,被控訴人方法は,「日本語インターネットアドレスに対応するURLを登録情報データベースから取得する段階」を備えるものであり,その後の段階において,更にURLの選別が行われるものではないから,登録情報データベースにおいて日本語インターネットアドレスと単一のURLが対応付けられているということができる。また,後者は情報の要求が「自動的に」行われることを明示するものであるところ,被控訴人方法においても,目的の情報ページの情報の要求は,ユーザーによるクライアントPCについての特段の操作を要しないで行われるものであるから,自動的に行われるものであるということができる。したがって,被控訴人方法は,将来,本件訂正が確定したとしても,本件訂正発明の技術的範囲に属するということができる。 2本件特許の無効理由の存否(争点5)について(1)開示義務違反(特許法36条4項,同条6項1号及び2号)被控訴人は,本件発明が明確でなく,実施可能要件及びサポート要件を満たすものでもないというべきであるから,本件特許は特許無効審判により無効とされるべきであると主張するので,まず,この点について検討する。 ア「アクセス」について被控訴人は,本件発明の構成要件Aにおける「アクセスを提供する方法」及び同Gにおける「アクセス方法」の主体が異なっており,「アクセス」,「アクセスを提供する」及び「アクセスする」が具体的に何を意味するのか不明瞭であり,発明が明確でないと主張する。 しかしながら,「アクセス」が「インターネットよりなるコンピュータネットワークを介したクライアント」による「サーバーシステムの情報ページ」に対するものであることは構成要件Aの記載自体から明らかであり,本件発明がそのような「アクセス」を提供する方法の発明であることも明らかである。そして,提供される「アクセス方法」が,構成要件BないしFにおいて特定された段階を備えるものであることが特定されており,これが「ディレクトリサーバー」を基点とする情報処理の各段階を特定するものであることは,特許請求の範囲の記載から容易に理解することができるのであり,アクセスを提供する主体として,本件発明における「ディレクトリサーバー」に相当するサーバーの管理者が想定されていることについても同様である。 したがって,当業者にとって,「アクセス」,「アクセスを提供する」及び「アクセスする」の行為がどのようなものであるかについての疑義はないというべきであり,被控訴人の主張を採用することはできない。 イ「記述子」の提供方法について被控訴人は,本件発明の構成要件Bはクライアントの記述子の提供方法を特定していないところ,控訴人方法のようにクライアントがアドレスバーに記述子を入力する場合には,正規URLかどうかを選別する段階がなければ,「ディレクトリサーバー」に記述子が送られることはないにもかかわらず,本件発明ではこのような選別の段階について発明特定事項とされておらず,発明が明確ではないと主張する。 しかしながら,本件発明は特定の段階を備えたアクセス方法を提供するものであって,クライアントによる記述子の提供方法を問わないものであることは,上記1(1)のとおりであり,この点で発明が明確でないということはできない。また,アクセス方法の提供に際して,特定の記述子の提供方法を採用することによって,これに対応して特定の情報処理のための段階を設ける必要が生じるとしても,そのことによって,本件発明における発明特定事項が明確でなくなるものではなく,上記必要な情報処理のための段階を加えるかどうかは,本件発明を実施するに際して当業者が適宜選択することができる設計的事項ということができるのであるから,これをもって本件発明が明確でないということはできないし,実施可能でないということもできない。 したがって,被控訴人の主張を採用することはできない。 ウ「ディレクトリサーバー」について被控訴人は,本件発明の構成要件Cにおける「ディレクトリサーバー」の語が不明瞭であり,クライアントが提供した記述子を「ディレクトリサーバー」が受け取る方法について特定していないと主張する。 しかしながら,本件発明の構成要件において,「ディレクトリサーバー」は,「記述子をURLにマッピングするための翻訳データベース」を備えるものであって,「REDIRECTコマンド中のURLをクライアントに返送する」という機能を有するサーバーとして特定されており,それ以上の限定を加えられるものではないという限度において明確であり,記述子を受け取る方法についても限定がないものとして理解すべきである。そして,被控訴人は,これらの点を特定しない限り,本件発明を実施することができないことを指摘するものではない。 したがって,被控訴人の主張を採用することはできない。 エ小括以上のとおり,本件発明が明確でないとの被控訴人の主張を採用することができないから,この主張に基づく実施可能要件違反及びサポート要件違反の主張についても採用することができない。 (2)新規性及び進歩性の欠如被控訴人は,本件発明は,引用例に記載された発明と同一又は同発明に基づいて当業者が容易に発明をすることができたものであり,特許無効審判において無効とされるべきものであると主張するので,次に,この点について検討する。 ア引用例の記載引用例には,以下の記載(なお,括弧内は訳文である乙24の2における記載箇所を示す。)がある。 (ア)「摘要サービス名をサーバーのアドレスにマッピングするイエローページ・サービスを紹介する。このサービスは,属性のセットを各サーバーに関連づけるという点で新規なものである。クライアントは,サービスを要求する際にサーバーが所有すべき属性を指定し,イエローページ・サービスは,どのサーバーが要求を満たすかを判断する。イエローページ・サービスのローカルエリア・ネットワーク内での実施の説明だけでなく,インターネットの至る所からクライアントがローカル・サーバーにアクセスできるようにするために,本サービスが,使用可能なインターネット通信プロトコルとどのように統合できるかを示す。」(1頁6〜13行)(イ)「我々の設計は,従来のネーム・サーバー…とは,2つの点で異なる。 第1に,サーバーの特徴およびプロパティを記述する属性(attribute)のセットが各サーバーに関連付けられる。サービスを受けたいクライアントは,サービス名およびサーバーが持つべき任意の属性を指定して,イエローページ・サービスにサーバーのアドレスを問い合わせる。イエローページ・サービスは,クライアントの要求を満たす一或いは二以上のサーバーのアドレスを返送する。 第2に,インターネットの至る所からのクライアントは,適切なサーバーを選択するために,中間エージェントを通じて,自律システム内で使用可能なイエローページ・サービスを使用するサーバーに問い合わせる。具体的には,ローカル・システム内のフラッグシップ(flagship)・ホストは,システムが提供するサービスのセットをインターネット・ネーミング・サービスによって通知する。クライアントは,そのホスト上でサーバーを使用できるかのように,フラグシップ・ホストに接続する。次に,フラグシップ・ホスト上で動作する転送メカニズム(forwardingmechanism)が,実際にそのサービスを提供するサーバーにクライアントを接続させる(patch)。転送メカニズムは,イエローページに,サービスを提供するサーバーのうち,最も負荷の軽いサーバーのアドレスを判断するよう問い合わせる。転送メカニズムを通じた間接参照および適切なサーバーの選択は,遠隔クライアントからは隠される。」(1頁23行〜2頁5行)(ウ)「2.アーキテクチャサーバーのセットが,イエローページ・サービスを実施する。各サーバーは,使用可能なサービスおよびサーバーに関する情報のデータベースを維持する。システム内のクライアントは,Sun Remote Procedure Callメカニズム…を使用して,一或いは二以上のサーバー上の動作を要求する。 2.1属性属性は,サーバーのプロパティまたは特徴を示す統語的要素である。 ある所定のサーバーに関連付けられる属性は,イエローページ・データベースに記録される。クライアントは,ある特定のサービスを提供するサーバーについてイエローページに問い合わせる際,属性のセットを送信する。 属性は,二つの次元に沿って分類される。一つの次元に沿って,属性は,静的(static)であるかまたは動的(dynamic)であるかに基づいて区別される。静的属性は,サーバーの固定のプロパティ,例えば,プリンタの速度やプロセッサのアーキテクチャに該当する。静的属性は,例えばアップグレードなどによって変わる場合もあるが,かかる変更は,稀であり,イエローページ・データベースへの更新によって簡単に追跡できる。これに対し,動的属性は,例えば,プロセッサの負荷や印刷キューのジョブ数のように絶えず変化する。動的属性の重要な特徴は,イエローページ・サービスが属性に基づく判断を要求されるよりもはるかにより頻繁に変化することである。従って,実用的な理由から,サーバーの動的属性は,要求があった場合にのみ計算されるべきである。 もう一つの次元に沿って,属性は,絶対的(absolute)であるかまたは相対的(relative)であるかに従って区別される。絶対的な属性は,他の全てのサーバーとは関係なく決定することができるサーバーの性質,例えば,サーバーのアーキテクチャや負荷などに該当する。これに対し,相対的属性は,サーバーのセットについて計算されるもので,負荷が最小のプロセッサや出力率が最大のプリンタなどである。 クライアントは,ある所定のサービスを提供する一或いは二以上のサーバーのアドレスを取得するためにイエローページ・サーバーに問い合わせる。クライアントは,サービス名の指定だけでなく,指定した属性条件のセットを満たすサーバーがサービスを提供するものとして選択されることを要求する。」(2頁14行〜3頁13行)(エ)「2.2データベース各イエローページ・サーバーには,システム内で使用できるサービスについての情報のデータベースが関連付けられる。データベースには,各サービスとそのサービスを提供するサーバーのセットとがバインディングされて(結びつけて)格納される。 service ───>{server ,server ,...server }1 2 nつぎに,サーバーは,以下のように定義される。 server? ローカル・システム内の唯一のホストが,フラグシップ・ホストとして指定される。例えば,arizona.eduという名前のホストが,アリゾナ大学のフラグシップ・ホストである。システムは,ドメイン名システム(domain naming system)…によって,リソース・レコード-サービスごとにひとつある可能性がある-のセットを登録することによって,フラグシップがサービスのセットをインターネット・クライアントに提供するものとして広告する。例えば,MXリソース・レコードは,システムのためのメール・サービスがフラグシップ・ホスト…で使用できることを示す。 クライアントは,システムにおいて特定のサービスを提供するホストのアドレスを取得するためにドメイン名サーバーに問い合わせ,フラグシップ・ホストのアドレスが返される。その後,クライアントは,フラグシップ・ホスト上のウェルノウンポート宛に一或いは二以上のパケットを送信することによって,サーバーに問い合わせる。すると,フラグシップ・ホストは,そのパケットをシステム内のサーバーに転送する。このように,転送メカニズムは,ウェルノウンポートにおいてサーバーにアクセスする戦略と類似している。フラグシップは,システムに対して,『ウェルノウンホスト』の役割を果たす。 転送メカニズムがTCP内でどのように実施されるかを更に詳細に検討する。フラグシップ・ホスト上で動作するTCPモジュールが,転送メカニズムを含むように変更される。転送メカニズムには,ウェルノウンをサーバーのアドレスにバインディングするテーブルが関連付けられる。そのテーブルには,以下のフォームのバインディングが含まれる。 well-known-port───>{addr ,addr ,...addr }1 2 mここで,各サーバーのアドレスは,ポート,ホスト・アドレスの対で指定される。 あるポート宛のパケットがTCPモジュールに到着すると,そのポートへの転送が行われるべきか,すなわち,テーブルにエントリが存在するかについて,転送メカニズムが問い合わせられる。パケットが新規クライアントからの場合,転送サーバーは,使用可能なサーバーをランダムにひとつ選択し,パケットをそのサーバーに転送する。すなわち,転送メカニズムは,パケットの宛先のアドレスをそのサーバーのアドレスに設定し,パケットを再送信する。これにより,以下の対が,接続に通常関連付けられるプロトコル・コントロール・ブロック(protocol controlblock)に記録される。 サーバー・ホスト上でTCPモジュールは,転送が行われていることを認識し,全ての応答メッセージを直接クライアントに送信する。サーバー・ホスト上のTCPは,パケットのソース・アドレスをフラグシップ・ホストのアドレスに設定し,それによってクライアントには,クライアントがまだフラグシップ・ホストと通信しているかのように見える。従って,転送が行われていることをクライアントが認識することはない。 フラグシップ・ホスト上で動作するロード・マネージャは,転送メカニズム・テーブル内のウェルノウンポートのそれぞれをサーバーのセットにバインディングする。ロード・マネージャの目的は,ローカル・サーバーの負荷のバランスをとるために,遠隔作業をローカル・サーバーに分配することである。メール・サービスなどの,一般的に使用可能なサービスの場合,負荷がある閾値以下の全てのプロセッサ・サーバーを定期的に問い合わせることによって,マネージャは,イエローページ・サービスのクライアントとなる。そして,マネージャは,転送メカニズムのテーブルを適宜更新する。ただし,転送メカニズムは,TCPに組み込まれているので,遠隔クライアントは,特定の属性のセットを満足するサーバーを要求することはできず,ロード・マネージャのみが,イエローページ・サービスのクライアントとなる。」(8頁8行〜10頁9行)(カ)「統合イエローページ・サービスは,転送メカニズム及びロード・マネージャによってインターネット・トランスポート・プロトコルと統合されている。遠隔クライアントがシステムのイエローページ・サーバーの1つに直接的に接触できない根本的な理由はないが,転送メカニズムがわずかなコストでクライアントによって要求されるサービスを考えられる最新の瞬間-接続確立中-のサーバーに結び付けることができることを留意することが重要である。直感的に,これは,遠隔クライアントとシステム間の『距離』がシステムの『直径』より桁違いに大きいインターネットにおいて重要である。すなわち,この方式は,サービスを提供するサーバーのセットを変更するよりも,サーバーに接続を確立するために長い時間がかかる環境には適切である。 また,この方式は,自律システム抽象化の背後にサーバーについての情報を隠すために魅力的である。言い換えると,サービスを提供するシステムの中のホストは,サーバーを実現するホスト上のプロセスがサーバーを呼び出すクライアントの目に見えないのと同じように,サービスを要求するクライアントの目には見えない。このような情報の非表示は,インターネット命名機構に対する負担を軽減し,したがってさらに多くのサービス及びサーバーがインターネット全体で使用できるようになるために十分拡大縮小する(scales)。」(12頁5〜21行)(キ)「転送対リダイレクション転送メカニズムはクライアントとサーバー間の仲介人の機能を果たす。これは,クライアントが間接参照から守られているため,トランスポートプロトコルに対するあらゆる変更を要求しないという優位点を有する。対照的に,プロトコルは,フラグシップ・ホストがクライアントに対して,そのパケットをサーバー・ホストにリダイレクトする必要があると知らせるように修正できるであろう。これは接続指向プロトコル(例えばTCP)のケースでは妥当である可能性があるが,コネクションレス・プロトコル(例えばUDP)のケースでは単にパケットをサーバー・ホストに転送する方がより費用効率が高い。この考え方は,VMTP[1]によって提供されている転送メカニズムでも一貫している。」(12頁22〜30行)イ引用例に開示された事項上記アの引用例の記載によると,引用例においては以下の事項が開示されていると認められる。 (ア)引用例の主題引用例は昭和63年(1988年)に米国で発表された論文であり,ローカルエリア・ネットワーク内における「イエローページ・サービス」の実施について説明するとともに,クライアントが,インターネットの至るところからローカル・サーバーにアクセスし,「イエローページ・サービス」を使用するために,「イエローページ・サービス」を使用可能なインターネット通信プロトコルとどのように統合することができるかを示すことを内容とするものである。 (イ)イエローページ・サービス引用例において説明される「イエローページ・サービス」は,サーバーのセットにより実施されるものであり,各サーバーは使用可能なサービス及びサーバーに関する情報のデータベースを維持する。 そして,「イエローページ・サービス」において,サーバーに関する情報は,サーバーに関連付けられる属性(静的・動的,絶対的・相対的)としてデータベースに記録されており,ローカルエリア・ネットワーク内のクライアントがあるサービスを提供するサーバーを問い合わせる際,属性のセットを送信すると,上記データベースと関連付けられたイエローページ・サーバーはクライアントが指定した属性条件のセットを満たすサーバーのアドレスがクライアントに返送される。 (ウ)転送メカニズムクライアントがインターネットの至る所から,ローカルエリアネットワーク内にあるイエローページ・サーバーを含むすべてのサーバーにアクセス可能とし,上記(イ)のようなイエローページ・サービスを利用するために,転送メカニズムを採用する。 ローカルエリア・ネットワーク内の唯一のホストが,「フラグシップ・ホスト」として指定され,フラグシップ・ホストが提供するサービスのセット,すなわち,ローカルエリア・ネットワークに含まれるサーバーが提供することができるサービスのセットをドメイン名システムに登録し,インターネット・クライアントに対して広告する。 クライアントが,特定のサービスを提供するサーバー(ホスト)のアドレスをドメイン名システム(domain naming system)に問い合わせると,フラグシップ・ホストのアドレスが返送され,クライアントはフラグシップ・ホストに対して,例えば,メール・サービスなどの提供を求めるサービスのための1あるいは2以上のパケットを送信する。 フラグシップ・ホストは,クライアントが求めるサービスを提供するサーバーのうち使用可能なサーバーをランダムに1つ選択して,そのサーバーに対してパケットを転送するが,フラグシップ・ホスト上で動作するロード・マネージャは,ローカル・サーバーの負荷のバランスをとるために,イエローページ・サーバーに定期的に負荷の状況を問い合わせ,転送メカニズムのテーブルを適宜更新している。 転送を受けたサーバーは,パケットの送信元のアドレスをフラグシップ・ホストのアドレスに設定してからクライアントに対して直接応答するため,クライアントは転送が行われていることを認識することはない。 ただし,上記の転送メカニズムは,TCPに組み込まれているため,クライアントは,ローカルエリア・ネットワーク内においてイエローページ・サービスを利用する場合のように,特定の属性のセットを満足するサーバーを要求することはできない。 (エ)リダイレクション転送メカニズムによると,トランスポートプロトコルを変更する必要がないが,プロトコル自体を,フラグシップ・ホストが,クライアントに対して,そのパケットをサーバー・ホストにリダイレクトするように修正することができる。 ウ引用発明引用例に開示された上記イの事項によると,引用例には,引用発明に係る各構成として以下の記載があると認められる。 aインターネットの至る所からクライアントがサービスを提供するローカル・サーバーにアクセスできるようにする方法であって,bクライアントが,サービス名及びサーバーが持つべき任意の属性を指定して,イエローページ・サービスにサーバーのアドレスを問い合わせ,cイエローページ・サーバーは,使用可能なサービス及びサーバーに関する情報のデータベースを備え,前記サービス名及びサーバーが持つべき任意の属性をサーバーのアドレスにマッピングし,dイエローページ・サービスは,クライアントの要求を満たす1又は2以上のサーバーのアドレスを返送するとともに,フラグシップ・ホストが,クライアントに対して,サーバー・ホストのアドレスを返送するとともに,そのパケットをそのサーバー・ホストにリダイレクトする必要があると知らせるeクライアントが,ローカル・サーバーにアクセスする方法エ本件発明と引用発明との相違点本件発明の構成要件と上記ウの引用発明に係る構成を対比すると,本件発明と引用発明とは,少なくとも,以下の点(以下「本件相違点」という。)において相違するものと認められる。 本件発明は,「ディレクトリサーバー」が,REDIRECTコマンド中の前記URLを前記クライアントに返送する段階を備えるのに対して,引用発明においては,「フラグシップ・ホスト」が,クライアントに対して,サーバー・ホストのアドレスを返送するとともに,そのパケットをそのサーバー・ホストにリダイレクトする必要があると知らせるものである点したがって,本件発明が,引用発明と同一の発明であり,新規性を欠くとの被控訴人の主張を採用することはできない。 オ本件相違点についての検討(ア)引用発明における「リダイレクト」について上記イで認定した引用例に開示された事項によると,引用発明の「リダイレクト」に関して,次のようにいうことができる。 引用例には,「イエローページ・サービス」が開示されるとともに,「インターネットの至る所」からのクライアントが「イエローページ・サービス」を含むローカルエリア・ネットワーク内のサーバーが提供するサービスを利用することができるようにするために,フラグシップ・ホストによってクライアントから送信されたパケットを転送して,ローカルエリア・ネットワーク内のサーバーにアクセスする方法の技術が開示されている。 そして,「インターネットの至る所」からのクライアントは,フラグシップ・ホストに対して,ローカルエリア・ネットワーク内においてイエローページ・サービスを利用する場合のように特定の属性のセットを満足するサーバーを要求することはできないとされているから,引用例におけるフラグシップ・ホストとイエローページ・サーバーを同視することができないことは明らかである。 他方,フラグシップ・ホストは,「インターネットの至る所」からのクライアントが求めるサービスを提供するローカルエリア・ネットワーク内の複数のサーバーの中から,負荷が一定レベル以下のものを選択してクライアントのアクセスを確立するために,イエローページ・サーバーに負荷の状況を定期的に問い合わせ,テーブルを更新するという機能を有するものである。 引用例においては,以上のような転送メカニズムによるアクセスの方法を前提として,プロトコルを,「フラグシップ・ホストが,クライアントに対して,そのパケットをサーバー・ホストにリダイレクトする」ように修正することができるとしているのであり,このことは,プロトコルを修正することによって,例えば,「インターネットの至る所」からのクライアントがイエローページ・サービス(メール・サービス)を利用したいと考えて,パケットを送信することによりイエローページ・サーバー(メール・サーバー)へのアクセスを要求した場合(ただし,上記のとおり,特定の属性のセットを満足するサーバーを要求することはできない。),これを受け取ったフラグシップ・ホストが,パケットを特定のイエローページ・サーバー(メール・サーバー)に転送する代わりに,負荷の高くないイエローページ・サーバー(メール・サーバー)のアドレスを指定して,直接アクセスするように命令するようにするということを意味している。 そうすると,引用発明における「リダイレクト」は,引用例におけるアクセス方法の技術についての上記イのような開示の中で理解されるべきものであって,あくまでも,ローカルエリア・ネットワーク内のサーバーが提供するイエローページ・サービスなどのサービスについて,「インターネットの至る所」からのクライアントが利用することができるようにする場合において,同ネットワーク内の負荷を調整するために,同ネットワーク内の唯一のホストであるフラグシップ・ホストによって行われるものである。 (イ)本件発明における「REDIRECTコマンド」について本件発明の「REDIRECTコマンド」は,ディレクトリサーバーが,クライアントに対して返送するものであって,クライアントにおいて提供した記述子に対応するURLを含み,同コマンドを受信したクライアントにおいて,同URLを用いて情報を要求させるものであり,その結果同URLによって識別されたページがクライアント側で表示される,というものである。 (ウ)相違点についての判断上記(ア)及び(イ)によると,本件発明の「REDIRECTコマンド」がクライアントにおいて情報ページを自動的に表示させるためのコマンドであって,ディレクトリサーバーによって行われるものであるのに対して,引用発明の「リダイレクト」は,ローカルエリア・ネットワーク内のサーバーに対する「インターネットの至る所」からのクライアントによるアクセスを確立する方法であって,このようなクライアントに対してローカルエリア・ネットワーク内で唯一のホストとなるフラグシップ・ホストによって行われるものであるということができる。 そして,一貫してインターネットにおけるアクセスを念頭に置く本件発明は,ローカルエリア・ネットワーク内のサーバーとのアクセスを実現するためのフラグシップ・ホストに相当するサーバーの存在及びその機能としての「リダイレクト」によって,その技術的課題を解決しようとするものではないのであり,本件発明の存在を知らない当業者がこのような引用例の記載に接したとしても,フラグシップ・ホストを必要としないインターネットのアクセス方法において,このような「リダイレクト」の構成を採用して,本件発明のディレクトリサーバーによる「REDIRECTコマンド」に係る構成とするように動機付けられるということはできないし,引用例において,フラグシップ・ホストの機能から離れて「リダイレクト」の機能を採用しようと動機付ける記載も存在しない。そして,仮に,引用例に開示された事項についての技術的意義を離れて,「リダイレクト」という用語の抽象的な意義のみに基づいて本件発明の「REDIRECTコマンド」と対比することを前提とするならば,排除されるべき「後知恵」の混入を避けることはできないといわなければならない。 また,平成6年12月1日発行の雑誌「UNIXUSER」(乙26)には「他のURLに変換〜Redirect」との項目において,「Redirectに指定したパターンにマッチした場合は,指定したURLにリクエストがそのままフォワードされる。 サーバーが引っ越したような場合に用いる。URLは『http://ホスト名/』から書かなければならない。」(135頁左欄19〜23行)と記載されており,ここに「Redirect」として紹介されている技術はいわゆる転送の技術であり,クライアントに別のドキュメントの位置を返送するものではないから,上記記載の技術が当業者に周知であったと認められるとしても,引用発明にこの技術を適用することによって本件発明の相違点に係る構成とすることができないことは明らかである。なお,上記記載は,本件特許出願時において,「リダイレクト」として認識される技術としては,本件発明における「REDIRECTコマンド」とは異なる転送の技術を意味する場合があったとさえ認定することができる。 他方,上記雑誌には,「CGIスクリプトからの出力として,ドキュメントの内容自身を出力する以外に,別のドキュメントの位置を返すこともできる。このためには,Location:ヘッダーを用いて,Location:目的のドキュメントのURLという形式の情報(ヘッダー)を返せばよい。これによって,既存のドキュメントをダイナミックに選択して表示できる。」(130ページ左欄14〜20行)と記載されており,この技術は,本件発明の「REDIRECTコマンド」と同様のリダイレクトの技術を意味するものと認められるところ,これを前提としつつ,引用発明における「フラグシップ・ホスト」と「イエローページ・サーバー」を1個のサーバーと理解することができる場合には,フラグシップ・ホストとイエローページ・サーバーとの間のやり取りを捨象した上,フラグシップ・ホストの機能とイエローページ・サーバーの機能を加えた別のサーバーを想定し,このようなサーバーがクライアントに対してリダイレクトの命令を発すると理解することによって,本件相違点を解消することは論理的には可能である。 しかしながら,上記イにおいて認定したとおり,引用例において,イエローページ・サービスを提供するイエローページ・サーバーと転送メカニズムを担うフラグシップ・ホストが別々のサーバーとして明確に書き分けられた上,インターネットの至る所からのクライアントがフラグシップ・ホストによる転送メカニズムを通じてイエローページ・サーバーを利用することができることが明示的に記載されており,このようなフラグシップ・ホストとイエローページ・サーバーの関係と関わりなく,これらを統合したような別のサーバーが存在することを想定することはできないのであり,仮に,フラグシップ・ホストとイエローページ・サーバーがそれぞれ有する機能的な構成だけを取り出して組み合せ,これを1つのサーバーとして構成するとすれば,これはすでに引用例に記載された発明に基づく当業者の思考ではないといわざるを得ない。 カしたがって,本件発明は,引用発明に基づいて当業者が容易に発明をすることができたものということはできないから,進歩性を欠如するものとは認められない。 (3)小括以上によると,本件発明に係る本件特許は特許無効審判により無効にされるべきものとは認められない。 3被控訴人の侵害主体性(争点7)について(1)まず,被控訴人が本件特許権の侵害主体であるか否かについて検討する。 本件特許に係る発明の名称は「インターネットサーバーのアクセス管理およびモニタシステム」とされており,上記2(1)アのとおり,本件発明に係る特許請求の範囲の記載から,本件発明における「アクセス」が「インターネットよりなるコンピュータネットワークを介したクライアント」による「サーバーシステムの情報ページ」に対するものであることが明らかである上,構成要件BないしFに規定される各段階は,本件発明において提供される「アクセス」が備える段階を特定するものであると解されるから,このような本件発明の実施主体は,上記のような「アクセスを提供する方法」の実施主体であって,被控訴人方法を提供して被控訴人サービスを実施する被控訴人であると解するのが相当である。 (2)この点について,被控訴人は,被控訴人方法を使用しているのはパソコンのユーザーであって,被控訴人ではないから,被控訴人は本件発明の実施主体ではないとして,本件特許権を侵害していないと主張するが,その主張は,要するに,「アクセス」はクライアント(ユーザーのパソコン)によって行われる行為であるから,本件発明の実施主体は,インターネットよりなるコンピュータネットワークのユーザーであるクライアントであって,被控訴人ではないという趣旨に解される。 しかしながら,上記のとおり,本件発明は「アクセス」の発明ではなく,「アクセスを提供する方法」の発明であって,具体的にクライアントによるアクセスがなければ本件発明に係る特許権を侵害することができないものではない。また,本件発明に係る「アクセスを提供する方法」が提供されている限り,クライアントは,被控訴人方法として提供されるアクセス方法の枠内において目的の情報ページにアクセスすることができるにとどまるのであり,クライアントの主体的行為によって,クライアントによる個別のアクセスが本件発明の技術的範囲に属するものとなったり,ならなかったりするものではないから,クライアントの個別の行為を待って初めて「アクセスを提供する方法」の発明である本件発明の実施行為が完成すると解すべきでもない。 そうすると,被控訴人による「アクセスを提供する方法」が本件発明の技術的範囲に属するのである以上,被控訴人による被控訴人方法の提供行為が本件発明の実施行為と評価されるべきものである。 (3)そして,甲60及び弁論の全趣旨によると,平成21年10月19日の時点において,被控訴人は現に被控訴人方法を実施していることが認められるから,被控訴人は本件特許権を侵害する者であると認められる。 したがって,控訴人は,被控訴人に対し,特許法100条1項に基づき,被控訴人方法による被控訴人サービスの提供の停止を請求するとともに,同条2項に基づき,被控訴人サービスに供された「NLIAサーバー」の除却及び「登録情報データベース」の消去を請求することができるといわなければならない。なお,控訴人は「NLIAサーバー」及び「登録情報データベース」のいずれについても除却を求めているが,「NLIAサーバー」について,これが除却の対象となり得るかどうかは同サーバーの設置・管理の状況によるものであり,共用サーバーの一部が当該サーバーとして利用されている場合,サーバー全体の除却ではなく,当該利用部分がその機能を果たさなくなるようにプログラムを削除したり消去したりすることによって対応すべきものである。上記において「NLIAサーバー」の除却とは,上記のような意味を含むものである。また,「登録情報データベース」については,「データベース」の性質上,除却の対象になじまないと考えられるところ,控訴人の請求はデータベースの機能を喪失させることを求めるものと解されるから,上記のとおり,同データベースの消去を認めるのが相当である。 4損害の発生及び額(争点8)について(1)控訴人は,被控訴人が,過去において本件発明を実施していただけでなく,現在においても実施しているものであり,被控訴人サービスの提供によって被控訴人が現実に売上げを計上していないとしても,控訴人に損害が発生していることに変わりはないとして,被控訴人による登録件数に従って本件発明の実施に対し受けるべき金銭の額に相当する額の金銭が控訴人の受けた損害の額であると主張する。 (2)控訴人が本件において適用があると主張する特許法102条3項は,「特許権者…は,故意又は過失により自己の特許権…を侵害した者に対し,その特許発明の実施に対し受けるべき金銭の額に相当する額の金銭を,自己が受けた損害の額としてその賠償を請求することができる。」と規定するところ,同規定は,特許権侵害に係る損害の額の立証が容易でないことにかんがみて設けられたものであり,特許権の侵害行為によって特許権者に何らかの損害が発生していることを前提として,「特許発明の実施に対し受けるべき金銭の額に相当する額」をもって,自己が受けた損害の額として損害賠償を請求することができるとした規定である。 (3)そして,特許法102条3項にいう「特許発明の実施に対し受けるべき金銭」として,例えば,特許発明の実施品の販売に対する売上金に基づいて算定される実施料相当額を想定することができるところ,本件特許は「アクセスを提供する方法」の発明についてのものであり,本件発明の実施は,構成要件を充足するアクセス方法の提供によって行われるが,甲3の1ないし甲12及び甲20の1ないし甲27の2によると,本件発明の実施者は,アクセスの提供自体又はアクセスの利用自体によって金銭を受けるものではなく,アクセス方法によって検索される対象となり得るキーワードの登録者が支払う登録料金を受領するというのである。 (4)ところで,被控訴人方法の登録件数が13万6826件であることには当事者間に争いはないところ,甲7の3の1及び2並びに甲22の1の1によると,これらの登録は,キーワードの実勢調査を行うためのマーケティングデータ収集を目的とする「Test Operation」を経て,登録料金が発生する商用サービス開始期間前に商標権者からビジネス・キーワードアドレスの登録申請を受け付け,優先登録権を与えるための「Sunrise Operation」における登録であって,いずれも登録料金の支払を伴わないものであり,乙37,38及び弁論の全趣旨によると,被控訴人は本件紛争の発生に伴って,その後に予定されていた商用サービスである「Commercial Operation」への移行を行っていないものと認められるから,被控訴人は,被控訴人サービスへの登録について登録者から金銭を受領しているということはできないし,ほかに被控訴人が本件発明の実施に相当する被控訴人サービスの提供に関して金銭を受領したことを示す証拠はない。 他方,上記「Sunrise Operation」における登録を無料としているのは,検索の可能性が高い商標権者については,サービスの利用率を高めるために無料で登録をさせる意味があると考えての措置であると認められるから,一般のユーザーによる有料のキーワード登録を加えて被控訴人サービスを開始するための前提となるものである。 (5)そして,特許権者が特許発明の実施を許諾する場合において,特許権者と被許諾者との間に特許発明の実施を無償で許諾することがあり得るような特別の関係があるような場合であれば格別,特許権の侵害行為に該当する特許発明の実施について,特許権者が無償でこれを許諾することは通常考えられないところ,被控訴人方法の実施が本件特許権を侵害するとして同方法の差止め及び損害賠償を求める本件において,互いに争っている控訴人と被控訴人との間に,上記のような特別の関係があるといえないことは明らかであり,被控訴人方法の実施によって,控訴人には上記の意味における損害が発生しているといわざるを得ない。 (6)しかしながら,上記(3)及び(4)のような被控訴人方法の実施に関する実情に照らすと,控訴人の損害額を立証するために必要な事実を立証することは,その性質上極めて困難であるというべきであるところ,上記のとおり,被控訴人方法の登録件数は約14万件に上っていること,これらはいずれも無料の登録に係るものではあるが,そのうち「Sunrise Operation」に係る登録については,被控訴人サービスを開始するための前提となるものであると理解すべきことのほか,甲10の2によると,被控訴人は,被控訴人方法を「Commercial Operation」に移行させた後は,キーワード登録1つ当たり1年間3万1500円の登録料を徴収する予定であったと認められること,さらに,前記第2の3(3)ア及び甲60によると,被控訴人は,遅くとも平成18年中にはサービス開始に向けた前提条件を整えており,ユーザーによって被控訴人サービスを利用することができる状態が作出されていたと認められることを総合的に考慮すると,控訴人の損害額は1400万円を下らないと解するのが相当である。 5結論以上の次第であるから,原判決を,控訴人の請求のうち,被控訴人方法を利用した被控訴人サービスの差止め並びに同サービスに供された「NLIAサーバー」及び「登録情報データベース」の除却等を求める請求については,いずれもこれを認容し,損害賠償を求める請求については,前記1400万円及び遅延損害金の支払を求める限度でこれを認容するとおりに変更することとして,民事訴訟法259条1項を適用して主文のとおり判決する。 |
|
| 追加 | |
|
(別紙)当事者目録控訴人インターネットナンバー株式会社同訴訟代理人弁護士熊倉禎男飯田圭奥村直樹同補佐人弁理士西島孝喜中村佳正被控訴人株式会社NETPIA同訴訟代理人弁護士北村行夫亀井弘泰大井法子杉浦尚子雪丸真吾芹澤繁大藏隆子村上弓恵政岡史郎吉田朋杉田禎治近藤美智子同補佐人弁理士樋口盛之助原慎一郎(別紙)サービス目録サービス名:「JAddress」サービスに係る方法の概要:別紙構成一覧記載の構成を備えた,インターネットに接続されたパソコンのユーザーに対し,当該パソコンのウェブブラウザのアドレスバーに任意の文字を記述することで目的のウェブページのURLを取得させ,当該ウェブページへのアクセスを提供する「JapanNLIA(NativeLanguageInternetAddress)System」に係る方法。 以上(別紙)構成一覧1サーバー方式A’インターネットよりなるコンピュータネットワークを介してクライアントが情報ページに対してアクセスする際,目的の情報ページのURLを取得する方法であって,B’ユーザーがクライアントPCのウェブブラウザのアドレスバーに任意の日本語インターネットアドレス(JAddress)を入力して(1),同日本語インターネットアドレス(2)(正規URL)又は(2’)(非正規URL)を予めプログラム?の付加されたDNSサーバー(NLIANameServer)に提供する段階(2)又は(2’)と,C’-?NLIANameServer内において,付加プログラム?が,クライアントPCから送信された日本語インターネットアドレスが正規URLであるか否かを選別し(3),正規URLの場合(4),DNSサーバーの機能によって対応するIPアドレスをクライアントPCに送り返し(9),C’-?正規URLでない場合,「NLIANameServer」から「NLIAサーバー」へとユーザーが入力した日本語インターネットアドレスを送信する段階と,C’-?日本語インターネットアドレスの送信を受けた「NLIAサーバー」が,当該日本語インターネットアドレスに対応するURLを登録情報データベースから取得する段階(6)と,D’「NLIAサーバー」が,当該URLを,REDIRECTコマンドを利用して,クライアントPCに送信する段階(7)と,E’クライアントPCが,取得したURLを一旦DNSサーバーを経由して(8),対応するIPアドレスを取得し(9),目的の情報ページの情報を要求する段階(10)と,F’クライアントPCが,目的の情報ページを表示する段階と(11),G’以上の段階を備える情報ページのURLを取得する方法2プラグイン方式A”インターネットよりなるコンピュータネットワークを介してクライアントが情報ページに対してアクセスする際,目的の情報ページのURLを取得する方法であって,B”-?ユーザーがクライアントPCのウェブブラウザのアドレスバーに任意の日本語インターネットアドレスを入力し(1),予めクライアントに付加されたプログラム?が,同日本語インターネットアドレス(2)(正規URL)又は(2’)(非正規URL)を正規URLであるか否かを選別する段階(3)と,B”-?入力された日本語インターネットアドレスが正規URLの場合(2),ブラウザの機能によって当該正規URLをDNSサーバーに送信してDNSサーバーの機能によって対応するIPアドレスをクライアントに送り返し(4)(9),正規URLでない場合(2’),当該日本語インターネットアドレスをNLIAサーバーへのURL形式に変更した上,ブラウザの機能によって当該変更したURL(2”)をDNSサーバーに送信して,DNSサーバーの機能によってNLIAサーバーのIPアドレスをクライアントPCに送り返す段階(4’)と,B”-?クライアントPCが,取得したIPアドレスのNLIAサーバーに向けて,当初ユーザーが入力した日本語インターネットアドレスを問い合わせる段階(5)と,C”問い合わせを受けたNLIAサーバーが,当該日本語インターネットアドレスに対応するURLを登録情報データベースから取得する段階(6)と,D”NLIAサーバーが,当該URLを,REDIRECTコマンドを利用して,クライアントPCに送信する段階(7)と,E”クライアントPCが,取得したURLを一旦DNSサーバーを経由して(8),対応するIPアドレスを取得し(9),目的の情報ページの情報を要求する段階(10)と,F”クライアントPCが,目的の情報ページを表示する段階と(11),G”以上の段階を備える情報ページのURLを取得する方法以上(別紙)特許請求の範囲の記載1第1回補正後の請求項1の記載(ただし,下線部分は補正箇所である。)インターネットよりなるコンピュータネットワークを介したクライアントからサーバーシステムへの情報ページに対するアクセスを提供する方法であって,前記クライアントにおいて記述子を提供する段階と,ディレクトリサーバーが,前記記述子を前記ディレクトリサーバーに存在する翻訳データベースを用いてURLにマッピングする段階と,前記ディレクトリサーバーが,REDIRECTコマンド中の前記URLを前記クライアントに返送して前記クライアントに前記URLを用いて情報を要求させる段階と,前記URLにより識別されたページを前記クライアント側で表示する段階とを備えた情報ページに対するアクセス方法。 2第2回補正後の請求項1の記載(ただし,下線部分は補正箇所である。)インターネットよりなるコンピュータネットワークを介したクライアントからサーバーシステムへの情報ページに対するアクセスを提供する方法であって,前記クライアントにおいて記述子を提供する段階と,ディレクトリサーバーが,前記記述子を前記ディレクトリサーバーに存在する翻訳データベースを用いてURLにマッピングする段階と,前記ディレクトリサーバーが,REDIRECTコマンド中の前記URLを前記クライアントに返送する段階と,前記クライアントに前記URLを用いて情報を要求させる段階と,前記URLにより識別されたページを前記クライアント側で表示する段階とを備えた情報ページに対するアクセス方法。 3本件訂正後の請求項1の記載(ただし,下線部分は訂正箇所である。)インターネットよりなるコンピュータネットワークを介したクライアントからサーバーシステムへの情報ページに対するアクセスを提供する方法であって,前記クライアントにおいて単一の目標URLに対応する記述子を提供する段階と,ディレクトリサーバーが,前記記述子を前記ディレクトリサーバーに存在する翻訳データベースを用いて前記URLにマッピングする段階と,前記ディレクトリサーバーが,REDIRECTコマンド中の前記URLを前記クライアントに返送する段階と,前記クライアントに前記URLを用いて情報を自動的に要求させる段階と,前記URLにより識別されたページを前記クライアント側で表示する段階とを備えた情報ページに対するアクセス方法。 |
| 裁判長裁判官 | 滝澤孝臣 |
|---|---|
| 裁判官 | 高部眞規子 |
| 裁判官 | 杜下弘記 |