ポートフォリオ機能| 関連審決 | 無効2007-800243 |
|---|
この判例には、下記の判例・審決が関連していると思われます。
| 審判番号（事件番号） | データベース | 権利 |
|---|---|---|
| 平成20行ケ10368審決取消請求事件 | 判例 | 特許 |
| 平成20行ケ10479審決取消請求事件 | 判例 | 特許 |
| 平成20行ケ10291審決取消請求事件 | 判例 | 特許 |
| 平成21行ケ10064審決取消請求事件 | 判例 | 特許 |
| 平成21行ケ10003審決取消請求事件 | 判例 | 特許 |
| 関連ワード | インターネット / アクセス / 進歩性(29条2項) / 容易に発明 / 発明特定事項 / 一致点の認定 / 相違点の判断 / 周知技術 / 上位概念 / 技術常識 / パリ条約 / 優先権 / 分割出願 / 原出願日 / 参酌 / 技術的意義 / 容易に想到(容易想到性) / 特許発明 / 実施 / 交換 / 設定登録 / 請求の範囲 / 変更 / 国際公開 / |
|---|
| 元本PDF |
裁判所収録の全文PDFを見る
 |
|---|
| 事件 |
平成
20年
(行ケ)
10297号
審決取消請求事件
|
|---|---|
|
原告インターネットナンバー株式会社 同訴訟代理人弁護士熊倉禎男 飯田圭 奥村直樹 同弁理士西島孝喜 中村佳正 被告株 式会社ＮＥＴＰＩＡ 同訴訟代理人弁護士北村行夫 亀井弘泰 大井法子 杉浦尚子 雪丸真吾 芹澤繁 大藏隆子 村上弓恵 政岡史郎 吉田朋 杉田禎浩 近藤美智子 同 補佐人弁理 士樋口盛之助原慎一郎 |
|
| 裁判所 | 知的財産高等裁判所 |
| 判決言渡日 | 2009/11/05 |
| 権利種別 | 特許権 |
| 訴訟類型 | 行政訴訟 |
| 主文 |
- 2 -１特許庁が無効２００７−８００２４３号事件について平成２０年６月２６日にした審決を取り消す。 ２訴訟費用は被告の負担とする。 |
| 事実及び理由 | |
|---|---|
|
全容
第1請求主文1項同旨第2事案の概要本件は,原告が,下記1のとおりの手続において,原告の本件特許に係る発明のうち,下記2の本件訂正後の請求項1ないし7の発明に係る特許に対する被告の無効審判請求について,特許庁が同請求を認め当該特許を無効とした別紙審決書(写し)の本件審決(その理由の要旨は下記3のとおり)には,下記4の取消事由があると主張して,その取消しを求める事案である。 1特許庁における手続の経緯(1)本件特許発明の名称:インターネットサーバーのアクセス管理およびモニタシステム原出願日:平成8年6月3日パリ条約による優先権主張日:平成7年(1995年)6月7日(米国)(以下「本件優先権主張日」という。)本件出願(分割出願)日:平成13年7月9日出願番号:特願2001-208296号設定登録日:平成18年1月20日登録番号:特許第3762882号(2)本件手続審判請求日:平成19年11月1日訂正請求日:平成20年1月23日(以下,同日付けの訂正を「本件訂正」という。)審決日:平成20年6月26日本件審決の結論:訂正を認める。特許第3762882号の請求項1ないし7に係る発明についての特許を無効とする。 審決謄本送達日:平成20年7月8日(原告に対する送達日)2発明の要旨本件発明の要旨は,本件訂正後の明細書(以下「本件明細書」という。)の特許請求の範囲の請求項1ないし7に記載された次のとおりのもの(以下,請求項の番号に従って,「本件発明1」などという。)である。 【請求項1】インターネットよりなるコンピュータネットワークを介したクライアントからサーバーシステムへの情報ページに対するアクセスを提供する方法であって,前記クライアントにおいて単一の目標URLに対応する記述子を提供する段階と,ディレクトリサーバーが,前記記述子を前記ディレクトリサーバーに存在する翻訳データベースを用いて前記URLにマッピングする段階と,前記ディレクトリサーバーが,REDIRECTコマンド中の前記URLを前記クライアントに返送する段階と,前記クライアントに前記URLを用いて情報を自動的に要求させる段階と,前記URLにより識別されたページを前記クライアント側で表示する段階とを備えた情報ページに対するアクセス方法。 【請求項2】請求項1において,前記記述子が電話番号を備えた情報ページに対するアクセス方法。 【請求項3】請求項1において,前記記述子が記述項目を備えた情報ページに対するアクセス方法。 【請求項4】請求項3において,前記記述項目が会社名を含む情報ページに対するアクセス方法。 【請求項5】請求項3において,前記記述項目が製品名を含む情報ページに対するアクセス方法。 【請求項6】請求項3において,前記記述項目が音声により識別される情報ページに対するアクセス方法。 【請求項7】請求項1において,前記URLにより識別されたページが管理ページである情報ページに対するアクセス方法。 3本件審決の理由の要旨(1)本件審決の理由は,要するに,本件発明1ないし7は,いずれも,下記の引用例記載の発明(以下「引用発明」という。)及び周知技術に基づいて,本件優先権主張日当時の当該発明の属する技術の分野における通常の知識を有する者(以下「当業者」という。)が容易に発明することができたものであって,本件発明1ないし7に係る特許は,特許法29条2項の規定に違反してされたものであるから,同法123条1項2号の規定により無効とされる,というものである。 引用例:Larry L. Peterson,"A Yellow-Pages Service for a Local-AreaNetwork",COMPUTER COMMUNICATION REVIEW,Volume 17,Number 5,Special Issue,ACMPress,1988,p.235-242(2)本件審決が認定した引用発明,本件発明1と引用発明との一致点及び相違点は,以下のとおりである。なお,同相違点はいずれも,本件発明2ないし7と引用発明との相違点に共通して含まれるものである。 引用発明:インターネットの至る所からクライアントがローカル・サーバーにアクセスする方法であって,サーバーのセットが,イエローページ・サービスを実施し,各サーバーは,使用可能なサービスおよびサーバーに関する情報のデータベースを維持し,各イエローページ・サーバーには,システム内で使用できるサービスについての情報のデータベースが関連付けられ,データベースには,各サービスとそのサービスを提供するサーバーのセットとが結びつけて格納され,クライアントは,サービス名およびサーバーが持つべき任意の属性を指定して,イエローページ・サービスにサーバーのアドレスを問い合わせ,イエローページ・サービスは,サービス名を,サービスを提供しようとするサーバーのアドレスにマッピングし,イエローページ・サービスは,クライアントの要求を満たす一或いは二以上のサーバーのアドレスを返送し,転送メカニズムでは,ウェルノウンポートをサーバーのアドレスに結びつけるテーブルが関連付けられ,クライアントは,フラグシップ・ホスト上のウェルノウンポート宛に一或いは二以上のパケットを送信することによって,サーバーに接続し,フラグシップ・ホストは,そのパケットをシステム内のサーバーに転送し,転送メカニズムと対照的に,フラグシップ・ホストがクライアントに対して,そのパケットをサーバー・ホストにリダイレクトする必要があると知らせるように修正できる,クライアントがローカル・サーバーにアクセスする方法。 一致点:「インターネットよりなるコンピュータネットワークを介したクライアントからサーバーシステムへのアクセスを提供する方法であって,前記クライアントにおいて記述子を提供する段階と,サーバーが,前記記述子を前記サーバーに存在するデータベースを用いてアドレスにマッピングする段階と,前記サーバーが,前記アドレスを前記クライアントに返送する段階と,を備えたアクセス方法。」である点。 相違点1:本件発明1では,サーバーが「ディレクトリサーバー」であり,データベースが「翻訳データベース」であり,「前記クライアントにおいて単一の目標URLに対応する記述子を提供する段階」,及び「ディレクトリサーバーが,前記記述子を前記ディレクトリサーバーに存在する翻訳データベースを用いて前記URLにマッピングする段階」を有するのに対して,引用発明では,イエローページ・サービスのサーバーが「ディレクトリサーバー」であるか,そのサーバーの「データベース」が「翻訳データベース」であるか明らかでなく,記述子は「単一の目標URL」に対応するか明らかでなく,「サービス名を,サービスを提供しようとするサーバーのアドレスにマッピング」している点。 相違点2:本件発明1は,サーバーシステムへのアクセスが「情報ページ」に対してであり,ディレクトリサーバーが「REDIRECTコマンド中の前記URL」をクライアントに返送しており,かつ,「前記クライアントに前記URLを用いて情報を自動的に要求させる段階」,及び「前記URLにより識別されたページを前記クライアント側で表示する段階」を有するのに対して,引用発明では,「情報ページ」に対してアクセスするか明らかでなく,サーバーはクライアントに「サービスを提供するサーバーのアドレス」を返送しており,かつ,「前記クライアントに前記URLを用いて情報を自動的に要求させる段階」,及び「前記URLにより識別されたページを前記クライアント側で表示する段階」を有するか明らかでない点。 4取消事由(1)一致点の認定の誤り(取消事由1)(2)相違点2についての判断の誤り(取消事由2)(3)相違点1についての判断の誤り(取消事由3)第3当事者の主張1取消事由1(一致点の認定の誤り)について〔原告の主張〕本件審決は,引用発明についての理解を誤った結果,以下の各点において本件発明1と引用発明との一致点の認定を誤り,その相違点を看過したものであるから,取消しを免れない。 (1)「URL」と「アドレス」本件審決は,本件発明1の「URL」と引用発明の「アドレス」は,上位概念である「アドレス」において一致すると認定したが,本件発明1における「URL」は,インターネット上のサーバーなどの資源の所在地を意味するものであるのに対して,引用発明の「アドレス」とは,あるサーバーのローカルエリアネットワーク内における所在を示すものといった程度の理解しかできないから,両者は相違する。 さらに,引用例に開示されているイエローページ・サービスとインターネット上の遠隔クライアントの接続は,TCPプロトコルにより実現されるものであるところ,引用例の「転送対リダイレクション」の項において言及されている「リダイレクション」も,当然にTCPプロトコルが用いられるものである。そして,TCPプロトコルは「配信先の特定」と「正確な電文の受け渡し」という処理を行うものであり,本来的に「送信元ポート番号」及び「宛先ポート番号」の2点間を指定するものであって,再接続先を含めた3点間を指定するものではない。また,引用例においては,TCPプロトコルを修正する転送メカニズムが開示されているが,これもTCPセグメントフォーマットにおいて「送(発)信元ポート番号」及び「宛先ポート番号」に割り振られているそれぞれ16ビットの情報フィールドを修正して指定されるものであり,技術的に転送先のアドレスまで指定することは困難である。仮に,TCPヘッダを更に修正してフラグシップ・ホスト↑クライアント↑サーバーという流れで再接続を実現しようとした場合でも,インターネットの至る所から到達可能なシステムを構築するためには,取り扱うことのできる情報量が著しく減少することになるから,このような修正を行う動機付けが存在せず,むしろ阻害要因が存在するというべきである。 引用例には,「プロトコルは,フラグシップ・ホストがクライアントに対して,そのパケットをサーバー・ホストにリダイレクトする必要があると知らせるように修正できるであろう」との記載があるが,同記載は,結局のところ,そのようにする理論上の可能性がゼロとまではいえないという程度の意味であり,引用例の他の記載と併せ読めば,引用例において,「イエローページ・サービス」とインターネット上の遠隔クライアントとの接続においては「転送メカニズム」の構成が必須であり,実質的には「リダイレクション」は採用するに値しない技術であると考えられていたというべきである。そうであるからこそ,引用例には,「リダイレクション」の場合におけるイエローページ・サービスの仕様変更についても何ら説明されていないのである。 したがって,引用発明における「リダイレクト」(リダイレクション)によって,フラグシップ・ホストが,インターネット上の遠隔クライアントに送信されたパケットをサーバーへと再接続することはできないから,引用発明における「アドレス」がインターネット上のサーバーの所在地を意味する「URL」となることもあり得ないというべきであり,本件審決による一致点の認定はこの点においても誤っている。 (2)「記述子」と「サービス名」本件審決は,引用発明の「サービス名」はサービスを識別する「識別子」であることは明らかであり,本件発明1の「記述子」は「識別子」を含む上位概念であるとして,両者は「記述子」において一致すると認定したが,そもそも引用発明は「サービス名」のみではなく,「サービス名」及び複数の「属性」によってサーバーのアドレスを照会しているものであるのに対して,本件発明1は請求項1の記載から明らかなように「単一の目標URLに対応」するものであるから,両者は相違する。 〔被告の主張〕以下のとおり,原告の主張はいずれも失当であり,取消事由1は理由がない。 (1)「URL」と「アドレス」本件審決は,本件発明1の「URL」は「アドレス」という上位概念に含まれるとした上,引用発明と本件発明1とは「サーバーが,前記識別子を前記ディレクトリサーバーに存在するデータベースを用いてアドレスにマッピング」する点で一致すると認定したのであって,これは,「アドレス」と「URL」が相違することを前提として,引用発明がインターネットに関する発明であって,引用例にサーバーのアドレスを返送することが開示されていることから,本件特許出願に係る本件優先権主張日当時の技術常識を参酌して,インターネットアドレス,すなわち「URL」の返送も開示されていると解釈したものであるから,原告の主張は前提を誤ったものであり,本件審決の一致点の認定に誤りはない。 さらに,原告は,引用例に記載された「リダイレクト」(リダイレクション)によって,フラグシップ・ホストが,インターネット上の遠隔クライアントに送信されたパケットをサーバーへと再接続することはできないと主張する。ここで,引用例に開示された技術においては,フラグシップ・ホスト内にロード・マネージャが存在し,ローカル・サーバーの負荷バランスについてのテーブルを常に更新しているのであり,クライアントから送られた属性の指定はロードマネージャが認識するが,これを更新している転送メカニズム・テーブルによってバインディングされたローカル・サーバーに転送する。この転送はTCP内でTCPプロトコルの本来的機能として行われるから,遠隔クライアントが特定の属性のセットを直接に転送先のサーバーに指定するのではなく,ロードマネージャが遠隔クライアントからの問合せに応じて,その指定を満足する最適なサーバーを決定し,TCPプロトコルによって,仲介者として,目的のサーバーに転送するのである。引用例には「ロード・マネージャのみが,イエローページ・サービスのクライアントとなる。」とあるのは,このことを指すものであり,遠隔クライアントが転送によってローカル・サーバーと接続されることは何ら否定されていない。また,引用例の他の記載からも,引用発明は,転送メカニズムによって,クライアントとその要求を満たすサーバーを直接に接続する技術であることは疑問の余地がない。したがって,原告の主張は失当である。 (2)「記述子」と「サービス名」本件審決は,本件発明1の「記述子」は「識別子」を含む上位概念であり,引用発明と本件発明1とは,「前記クライアントにおいて記述子を提供」する点で一致すると認定したものであって,単に「記述子」と「サービス名」を対比し,両者が「記述子」において一致するとしたものではない。そして,原告が指摘する「属性」については,引用発明において属性の指定は「0」(指定しない)場合もあり得るのであるから,引用発明において「サービス名」及び複数の「属性」によってサーバーのアドレスを照会していることを前提とする原告の主張は誤りである。 なお,本件明細書には,本件発明1の「記述子」が「特定かつ唯一のURL」と結びつくという限定を伴ったものであると解釈する根拠となる記載は存在せず,本件発明1において,それ自体は「特定かつ唯一のURL」と結びつかない「記述子」の送信に対して「特定かつ唯一のURL」が返送されるのは,「記述子」の問題ではなく,「翻訳データベース」の構成の問題である。 2取消事由2(相違点2についての判断の誤り)について〔原告の主張〕本件審決は,引用発明に基づいて本件発明1の相違点2に係る構成とすることは当業者にとって容易であると判断したが,この判断は,以下の各点において誤っており,本件審決は取消しを免れない。 (1)「REDIRECTコマンド」と「リダイレクト」との共通性本件審決は,本件発明1の「REDIRECTコマンド」と引用発明の「リダイレクト」は「REDIRECT」に関する命令である点で共通であるとしたが,本件発明1の「REDIRECTコマンド」は同コマンド中の特定,かつ,唯一のURLがクライアントへと返送されることによって自動的にクライアントをして特定,かつ,唯一のURLに対応するウェブへと情報要求させるものであるのに対して,引用例には「リダイレクト」に関して「パケットをサーバー・ホストにリダイレクトする必要があると知らせるように修正できる」との開示しか存在しないのであり,「リダイレクト」が何を意味するのか明らかではないから,用語にのみ着目して上記のとおり共通であるとした本件審決の認定は誤りである。 また,本件発明1の「REDIRECTコマンド」については,本件特許出願の審査の段階において,国際公開第94/06251号パンフレットに「公衆ネットワークを利用したクライアントからの接続要求に対し,サーバ12において,翻訳データベースを用いてアクセス先のアドレスにマッピングし,該アドレスをREDIRECTコマンドを用いてクライアントに返送することが記載されている。」として拒絶理由(甲40)が通知された際,意見書(甲41)において「REDIRECTの機能についても,本願発明が,記述子(電話番号,会社名,製品名等)にマッピングされたURLを返送する際のコマンドであるのに対して,引用文献1(判決注:上記国際公開パンフレットのこと)では,信号経路の確立の再指向において,最適な経路を選定するために使用されるメッセージであり,機能的にも明らかに異なる技術であります」との意見を述べ,これが受け容れられて特許査定されたという経緯があることに照らしても,単に用語それ自体として一致するという理由によって,両者が共通であるという前提に立つことはできない。 さらに,上記1〔原告の主張〕(1)のとおり,そもそも引用発明の「リダイレクト」(リダイレクション)においては,フラグシップ・ホストからインターネット上の遠隔クライアントへ送信されたパケットに基づき,サーバーへ再接続することはできないというべきであるから,本件発明1の「REDIRECTコマンド」と引用発明の「リダイレクト」は明らかに異なるものである。 (2)「REDIRECTコマンド中の…URL」の開示ア本件審決は,引用例における「パケットをサーバーホストにリダイレクトする必要があると知らせるように修正できる」との記載を根拠として,「イエローページ・サーバーがクライアントに対して『REDIRECTコマンド中のURL』を送信し…のように構成することは当業者が容易に想到し得ることである」と判断した。 しかしながら,本件発明1においては,その「REDIRECTコマンド」が単一の目標URLを含むため,「REDIRECTコマンド」が返送された側のクライアントにおいて当該コマンド中のURLを用いて自動的に情報要求することが可能となるのに対して,引用発明については,引用例中に上記記載が存するのみであって,クライアントに返される「リダイレクト」中に「URL」はもちろん「アドレス」が含まれているのかどうかさえ明らかではない。 したがって,引用例における上記記載を根拠として,「REDIRECTコマンド中のURL」を送信するとの構成に想到することが容易であるとの本件審決の判断には,論理の飛躍がある。 イまた,そもそも引用例において「リダイレクト」の対象として開示されているのは「パケット」であり,本件特許に係る本件優先権主張日における当業者の技術常識に照らすと,この「リダイレクト」は「ICMPリダイレクト」を意味するものであって,これはインターネットにおいて通信経路選択を行うための機能を指すものと理解すべきところ,OSI基本参照モデルのネットワーク層(第3層)又はトランスポート層(第4層)において実現されるものであるのに対して,本件発明1の「REDIRECTコマンド」は,コマンド中にウェブ(WWW)で使用されるHTTPプロトコル(OSI基本参照モデルの第7層)において規定されるURLを含めることができるものである。 OSI基本参照モデルの7つの層は,それぞれが明確に機能分担された階層モデルであるところ,異なる層に属する技術同士は互いに機能が異なるものであり,第1層から第4層まで(下位4階層)は主に通信機能の規約であり,第5層から第7層(上位3階層)は送受するデータ処理に関する規約であるとされている(甲49)ことから,下位4階層において機能する引用発明の「リダイレクト」にURLを含ませるようにし,上位3階層において機能する本件発明1の「REDIRECTコマンド」と同様のものとすることは,当業者にとって技術的に不可能なことというべきである。 ウまた,本件審決においては,周知技術(甲3)として「クライアントがURLを用いて情報を要求し,前記URLにより識別された情報ページを前記クライアント側で表示すること」を摘示するが,この周知技術はクライアントがURLを得た後の動作についてのものであるから,そもそもクライアントが「アドレス」を取得していない引用発明に適用することはできない。 エさらに,上記1〔原告の主張〕(1)のとおり,引用発明の「リダイレクト」(リダイレクション)に係る構成では,フラグシップ・ホストからクライアントに対して送信されたパケットに基づき,サーバーへ再接続させることは技術的に不可能であるから,引用発明において「リダイレクト」の構成を採用した場合,引用発明はインターネットへの適用可能性を欠くというべきであり,「リダイレクト」にURLを含めることも不可能である。 (3)「クライアントに返送する」との構成の容易想到性本件審決は,本件発明1の「ディレクトリサーバー」に対応する構成として,引用発明の「イエローページ・サーバー」を認定しているところ,本件発明1において「REDIRECTコマンド」をクライアントに返送する主体が「ディレクトリサーバー」であることは特許請求の範囲の記載から明らかであるのに対して,引用発明においてクライアントに対して「リダイレクトする必要がある」と知らせる主体は「フラグシップ・ホスト」であって,「イエローページ・サーバー」でないことも明らかである。そして,引用例において「フラグシップ・ホスト」の代わりに「ディレクトリサーバー」が「リダイレクトする必要がある」ように修正できることを開示又は示唆する記載は存在しない。 そうすると,本件審決は,本件発明1の「REDIRECTコマンド」と引用発明の「リダイレクト」の主体についての相違を無視して,単に「REDIRECTに関する命令である点で共通する」ことのみによって,相違点2に係る構成とすることが容易であるとの結論を導いたものであり,少なくとも,相違点2のうち,ディレクトリサーバーが「REDIRECTコマンド中の前記URL」をクライアントに返送するとの本件発明1に係る構成とすることが容易であるということはできないから,本件審決の相違点2についての判断は誤りである。 〔被告の主張〕以下のとおり,原告の主張はいずれも失当であり,取消事由2は理由がない。 (1)「REDIRECTコマンド」と「リダイレクト」の共通性本件審決は,本件明細書の記載から,「REDIRECTコマンド」の具体的意義について「サーバーからクライアントに送信され,クライアントが前記サーバーとは別のサーバーへ自動的に送信する命令」のことであると認定する一方,引用発明の「リダイレクト」について「フラグシップ・ホストがクライアントに対して,そのパケットをサーバー・ホストにリダイレクトする必要があると知らせる」ものであると認定し,これらを比較した上で両者が「REDIRECTに関する命令である点で共通する」とまとめたのであって,原告の主張は,本件審決を正解しない的外れなものである。 さらに,上記1〔被告の主張〕(1)のとおり,引用発明の「リダイレクト」(リダイレクション)においては,フラグシップ・ホストからインターネット上の遠隔クライアントへ送信されたパケットに基づき,サーバーへ再接続することはできないとの原告の主張は失当である。 (2)「REDIRECTコマンド中の…URL」の開示ア引用発明は「イエローページ・サービスは,クライアントの要求を満たす1あるいは2以上のサーバーのアドレスを返送する」ことを内容としているところ,ネットワーク上のデータ送受信方法であるパケット交換技術によって,送受信されるデータは一旦「パケット」単位に分割されるから,当然,返送される「アドレス」も「パケット」の形で送受信されるのであり,「パケット」であるから「アドレス」や「URL」ではないなどということはできない。 イまた,原告は,OSI基本参照モデルについて指摘するが,同モデルは,ネットワーク上でのデータ処理の過程を説明するために考え出された通信モデルであり,1個のコンピュータネットワーク通信の構造を役割・機能から7つの階層に分けることを標準化したものであり,確かに,パケットの経路選択を行う機能は第3層に分類されているが,上位層のメッセージもデータ処理の過程で一旦パケットという形態になるのである。 そして,引用発明のイエローページ・サービスは,ディレクトリサービスの1つとして知られていたものであり,ディレクトリサービスはOSI基本参照モデルお上位層に分類されるOSIアプリケーションであるし,ディレクトリサービスにアクセスするプロトコルである「LDAP」(又はDAP)がアプリケーション層(第7層)のものであることも明らかである。 また,引用例における「これは接続指向プロトコル(例えばTCP)のケースでは妥当である可能性があるが…」との記載は第4層のプロトコル(TCP)にも言及している。 したがって,引用発明の「リダイレクト」の説明部分に「パケット」との記載があるからといって,それだけでその部分が第3層又は第4層に限定した技術についての説明であると解することにはならないばかりか,引用例は,全体としてイエローページ・サービス(=ディレクトリサービス=第7層)に関する文献であるというべきであるから,引用発明の「リダイレクト」もアプリケーション層について述べたものと解される。 なお,本件優先権主張日当時において,「リダイレクト」が「ICMPリダイレクト」を意味するものであるとの技術常識は存在しないし,そもそも「ICMPリダイレクト」はルータが指示するICMPの命令であるところ,引用発明の「リダイレクト」は,「フラグシップ・ホスト」が主体となるものであって,「ホスト」は「IPアドレスが付けられているが経路制御(ルーティング)を行わない機器」をいうものであるから,引用発明の「リダイレクト」が「ICMPリダイレクト」と同義であると解釈することはできない。 ウ仮に,引用発明の「リダイレクト」が第7層のものでなかったとしても,本件優先権主張日当時において,「Redirect」の設定においてURLは「http://ホスト名」から書かなければならないことは周知の技術事項であり,引用発明をHTTPによるWWWサービスに適用するに当たってURLを含む「Redirect」を用いることは当業者にとって自明のことというべきであるから,引用発明に周知の技術事項を適用して「REDIRECTコマンド中の…URL」の構成とすることは当業者にとって容易であり,本件審決の判断に誤りはない。 エさらに,上記1〔被告の主張〕(1)のとおり,引用発明の「リダイレクト」(リダイレクション)においては,フラグシップ・ホストからインターネット上の遠隔クライアントへ送信されたパケットに基づき,サーバーへ再接続することはできないとの主張は失当である。そして,引用例には「転送対リダイレクション」の項において,接続指向プロトコル(例えばTCP)においてはむしろリダイレクトの方が妥当である可能性があると述べているのであり,本件優先権主張日当時において周知であったHTTPのリダイレクトを引用例に記載された引用発明に適用することは当業者であれば容易なことである。 (3)「クライアントに返送する」との構成の容易想到性引用例には「テストベッドは,DARPAインターネット内のローカルエリア・ネットワークなので,遠隔クライアントがアクセスできるサーバーは,一或いは二以上のシステムのホスト上にあり,よく知られているポートで待機するサーバーに限定される。ローカル・システム内の唯一のホストが,フラグシップ・ホストとして指定される。」との記載があるように,イエローページ・サービスにおいて,クライアントがアクセスするイエローページ・サーバーがシステムのホスト上に存在し,そのホストの1つがフラグシップ・ホストとして指定されるのであるから,フラグシップ・ホスト上にはイエローページ・サーバーが存在すると解することができる。 そして,イエローページ・サーバーはディレクトリサーバーであると理解することができるから,引用発明の「リダイレクト」の送信主体を「ディレクトリサーバー」と構成することは当業者にとって容易である。 仮に,フラグシップ・ホストがイエローページ・サーバーそのものではないことを重視したとしても,コンピュータの汎用性と高能力化の進展にかんがみると,両者を物理的に1つのサーバーで実現することは単なる設計事項というべきであるから,インターネット上で動作可能なプロトコルであるHTTPを前提とすれば,その具体的な設計も当業者には自明のことであるというべきである。 以上によると,原告が主張する「REDIRECTコマンド」の返送主体と「リダイレクトする必要がある」と知らせる主体の相違を考慮しても,本件発明1の相違点2に係る構成とすることは当業者にとって容易であるというべきであり,本件審決の判断に誤りはない。 3取消事由3(相違点1についての判断の誤り)について〔原告の主張〕また,本件審決は,相違点1についても,同相違点のうち,「記述子は『単一の目標URL』に対応するか明らかでなく」の点に関し,「そのようにするため,記述子を単一の目標URLにマッピングするように代え(る)」ことは容易であると判断しているが,この判断は以下のとおり誤りであり,本件審決は,この点においても,取消しを免れない。 (1)「目標URL」と「単一のアドレス」との相違本件発明1の「目標URL」はユーザーによって意図される特定のURLを意味することは一義的に明らかであって,記述子との関係において,1対1又は多対1で対応するものである。 これに対して,引用発明は「サービス名及び任意の属性」という検索条件が与えられた結果,その条件を満足するサーバーのアドレスを返送する検索システムにすぎないのであり,そこで検索されるアドレスは元来不特定なものである。また,引用発明においては,検索条件である mode の設定いかんによって単一アドレスのみが返送されるように構成すること自体は不可能ではないが,そのような単一アドレスも,あくまで検索条件に適合する複数のサーバーの中からランダムに選択される不特定のアドレスのうちの1つにすぎない。さらに,そのような単一アドレスの選択は"atrandom"(出任せ,行き当たりばったり)に行われるものであって,同一,かつ,特定のアドレスが必ず返送されるものではない。 そうすると,引用例には,本件発明1の「目標URL」に相当する構成の開示が存在しないのであり,この点を無視して,引用発明に基づいて相違点1に係る構成とすることが容易であるとした本件審決は,相違点1について実質的に判断していないともいうことができる。 (2)「目標URL」の構成とするための変更の要否上記(1)のとおり,本件発明1の「目標URL」はユーザーによって意図される特定のURLを意味するから,引用発明がこのような「目標URL」に相当する構成を有するようにするためには,引用発明において「サービス名」及び「サーバーが持つべき任意の属性」と特定の「サーバー」とがひも付けされるようにする必要がある。 しかしながら,引用例には,不特定の検索結果が返されるシステムから,常に単一,かつ,特定のアドレスが返されるシステムへと変更することについての示唆は何ら存在しないし,そのような変更が本件優先権主張日において周知技術であったことを示す証拠も存在しない。 しかも,仮に,引用発明において無作為に選択される不特定の単一サーバーのアドレスを,常に特定のものにしようとするのであれば,クライアントが与える「属性」及び「サービス名」の設定方法等,引用発明の他の構成において必然的に大幅に変更しなければならないにも関わらず,それらの構成をどのように変更するかについては,引用例に何らの開示も示唆も存在しない。 (3)「単一の」と「一或いは二以上の」との相違本件発明1は「クライアントにおいて単一の目標URLに対応する記述子を提供する」構成を有するものであり,この「単一」とは「一のみ」を意味するものであって,「一以上」と区別されるものであることは明らかである。 他方,引用発明は,あくまでも「一或いは二以上の」サーバーアドレスを返すものであり,「一」のサーバーアドレスが返される場合と「二以上」のサーバーアドレスが返される場合とを別個の発明として区別しているものではないのである。 したがって,引用発明のうち,「一」のみのサーバーアドレスが返される構成を恣意的に切り出した上,本件発明1の「単一の…URL」と一致すると認定したこと自体がそもそも誤りであるというべきであり,本件審決の相違点1についての判断は,このような恣意的な対比を前提とするものである点においても失当である。 〔被告の主張〕以下のとおり,原告の主張はいずれも失当であり,取消事由2は理由がない。 (1)「目標URL」と「単一のアドレス」との相違本件審決は,引用発明の「アドレス」がデータベースによってマッピングされることにより特定されたアドレスであることを認定し,「一或いは二以上の」サーバーのアドレスが「単一のURL」を含むものと技術的に解釈することができることを示した上,これらをまとめて「記述子を単一の目標URLにマッピングするように代え(る)」ことは当業者にとって容易であると判断したものであり,本件審決が「目標URL」についての判断を行っていないということはできない。 (2)「目標URL」の構成とするための変更の要否原告は,本件発明1の「目標URL」はユーザーによって意図される特定のURLを意味するから,引用発明がこのような「目標URL」に相当する構成を有するようにするためには,クライアントが与える「属性」及び「サービス名」の設定方法等,引用発明の他の構成において必然的に大幅に変更しなければならないと主張するが,どのような記述子に対してどのようなURLを返送するかはデータベースの構成の問題であり,選択アルゴリズムの設定次第で,1つのサーバーのアドレスのみを抽出選択するようにできるというべきである。 (3)「単一の」と「一或いは二以上の」との相違上記(1)のとおり,本件審決は,相違点1についての判断の前提として,引用発明における「一或いは二以上の」サーバーのアドレスが,「単一のURL」を含むものと技術的に解釈することができることを示しており,上記(2)のとおり,どのような記述子に対してどのようなURLを返送するかはデータベースの構成の問題であるということができるから,本件審決による相違点1についての判断に誤りはない。 第4当裁判所の判断1取消事由1(一致点の認定の誤り)について原告は,本件審決が,本件発明1の「URL」と引用発明の「アドレス」は上位概念である「アドレス」において一致するとした点は誤りであると主張するが,その内容は,本件発明1の構成とすることについて阻害要因が存在するというものであり,実質的には相違点の判断についての誤りの主張である。 また,原告は,本件審決が,本件発明1の「記述子」と引用発明の「サービス名」は上位概念である「記述子」において一致するとした点は誤りであると主張するが,その内容は,引用発明においては,「サービス名」及び複数の「属性」によってサーバーのアドレスを照会しているのであって,本件発明1とはこの点において相違するというものである。 しかしながら,本件審決による相違点1の認定は,前記第2の3(2)のとおりであり,本件審決は,引用発明において「記述子が『単一の目標URL』に対応するか明らかでなく,『サービス名を,サービスを提供しようとするサーバーのアドレスにマッピング』している点」を本件発明1と引用発明との相違点1として認定しているのであるから,原告主張に係る点は,同相違点についての判断において検討されるべきであるということはできるが,そのことから直ちに,本件発明1と引用発明の特定の要素が上位概念において一致するとした本件審決の認定に誤りがあるということはできないというべきである。 したがって,取消事由1は理由がない。 2取消事由2(相違点2についての判断の誤り)について(1)引用例の記載引用例(甲1)には,以下の各記載がある。 ア「摘要サービス名をサーバーのアドレスにマッピングするイエローページ・サービスを紹介する。このサービスは,属性のセットを各サーバーに関連づけるという点で新規なものである。クライアントは,サービスを要求する際にサーバーが所有すべき属性を指定し,イエローページ・サービスは,どのサーバーが要求を満たすかを判断する。イエローページ・サービスのローカルエリア・ネットワーク内での実施の説明だけでなく,インターネットの至る所からクライアントがローカル・サーバーにアクセスできるようにするために,本サービスが,使用可能なインターネット通信プロトコルとどのように統合できるかを示す。」(訳文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行)(2)引用例に開示された事項上記引用例の記載から,引用例には以下の事項が開示されていると認められる。 ア引用例の主題引用例は昭和63年(1988年)に米国で発表された論文であり,ローカルエリア・ネットワーク内における「イエローページ・サービス」の実施について説明するとともに,クライアントが,インターネットの至るところからローカル・サーバーにアクセスし,「イエローページ・サービス」を使用するために,「イエローページ・サービス」を使用可能なインターネット通信プロトコルとどのように統合することができるかを示すことを内容とするものである。 イイエローページ・サービス引用例において説明される「イエローページ・サービス」は,サーバーのセットにより実施されるものであり,各サーバーは使用可能なサービス及びサーバーに関する情報のデータベースを維持する。 そして,「イエローページ・サービス」において,サーバーに関する情報は,サーバーに関連付けられる属性(静的・動的,絶対的・相対的)としてデータベースに記録されており,ローカルエリア・ネットワーク内のクライアントがあるサービスを提供するサーバーを問い合わせる際,属性のセットを送信すると,上記データベースと関連付けられたイエローページ・サーバーはクライアントが指定した属性条件のセットを満たすサーバーのアドレスがクライアントに返送される。 ウ転送メカニズムクライアントがインターネットの至る所から,ローカルエリアネットワーク内にあるイエローページ・サーバーを含むすべてのサーバーにアクセス可能とし,上記イのようなイエローページ・サービスを利用するために,転送メカニズムを採用する。 ローカルエリア・ネットワーク内の唯一のホストが,「フラグシップ・ホスト」として指定され,フラグシップ・ホストが提供するサービスのセット,すなわち,ローカルエリア・ネットワークに含まれるサーバーが提供することができるサービスのセットをドメイン名システムに登録し,インターネット・クライアントに対して広告する。 クライアントが,特定のサービスを提供するサーバー(ホスト)のアドレスをドメイン名システム(domain naming system)に問い合わせると,フラグシップ・ホストのアドレスが返送され,クライアントはフラグシップ・ホストに対して,例えば,メール・サービスなどの提供を求めるサービスを1あるいは2以上のパケットにより送信する。 フラグシップ・ホストは,クライアントが求めるサービスを提供するサーバーのうち使用可能なサーバーをランダムに1つ選択して,そのサーバーに対してパケットを転送するが,フラグシップ・ホスト上で動作するロード・マネージャは,ローカル・サーバーの負荷のバランスをとるために,イエローページ・サーバーに定期的に負荷の状況を問い合わせ,転送メカニズムのテーブルを適宜更新している。 転送を受けたサーバーは,パケットの送信元のアドレスをフラグシップ・ホストのアドレスに設定してからクライアントに対して直接応答するため,クライアントは転送が行われていることを認識することはない。 ただし,上記の転送メカニズムは,TCP に組み込まれているため,クライアントは,ローカルエリア・ネットワーク内においてイエローページ・サービスを利用する場合のように,特定の属性のセットを満足するサーバーを要求することはできない。 エリダイレクション転送メカニズムによると,トランスポートプロトコルを変更する必要がないが,プロトコル自体を,フラグシップ・ホストが,クライアントに対して,そのパケットをサーバー・ホストにリダイレクトするように修正することができる。 (3)相違点2についての判断ア本件審決の判断の構造本件審決は,相違点2について判断するに当たって,本件発明1の「REDIRECTコマンド」とは,サーバーからクライアントに送信され,クライアントが前記サーバーとは別のサーバーへ自動的に送信する命令のことであると認定する一方,引用発明の「リダイレクト」も「フラグシップ・ホストがクライアントに対して,そのパケットをサーバー・ホストにリダイレクトする必要があると知らせるものであるから,本件発明の「REDIRECTコマンド」と引用発明の「リダイレクト」とは,REDIRECTに関する命令である点で共通すると説示した上,引用発明において,イエローページ・サービスがクライアントにサービスを提供するサーバーのアドレスを送信し,その後クライアントが前記サービスを提供するサーバーにアクセスしてサービスを実行する場合に,リダイレクトを採用すること及びその際にアクセスを自動的に行うことに格別の困難性はないとした。 その上で,本件審決は,「クライアントがURLを用いて情報を要求し,前記URLにより識別された情報ページを前記クライアント側で表示することは,当業者にとって周知技術である。」と認定した上,相違点2に関して,引用発明において,上記認定に係る周知技術のように,クライアントがURLを用いて情報を要求し,前記URLにより識別された情報ページを前記クライアント側で表示することができるように,イエローページ・サーバーがクライアントに対して「REDIRECTコマンド中のURL」を送信し,クライアントが自動的にサービスを提供するサーバーの「情報ページ」に対してアクセスできるようにし,「前記クライアントに前記URLを用いて情報を自動的に要求させる段階」及び「前記URLにより識別されたページを前記クライアント側で表示する段階」を設けて本件発明のように構成することは容易であると判断している。 本件審決の上記判断は,引用発明の「リダイレクト」と本件発明1の「REDIRECTコマンド」の共通性を前提として,引用発明において,「イエローページ・サービス」が「リダイレクト」を採用することについて容易であるとしたものと理解することができる。 イ引用例における「リダイレクト」上記(2)で認定したところによると,引用例に開示された「リダイレクト」に関して,次のようにいうことができる。 引用例には,「イエローページ・サービス」が開示されるとともに,「インターネットの至る所」からのクライアントが「イエローページ・サービス」を含むローカルエリア・ネットワーク内のサーバーが提供するサービスを利用することができるようにするために,フラグシップ・ホストによってクライアントから送信されたパケットを転送して,ローカルエリア・ネットワーク内のサーバーにアクセスする方法の技術が開示されている。 そして,「インターネットの至る所」からのクライアントは,フラグシップ・ホストに対して,ローカルエリア・ネットワーク内においてイエローページ・サービスを利用する場合のように特定の属性のセットを満足するサーバーを要求することはできないとされているから,引用例におけるフラグシップ・ホストとイエローページ・サーバーを同視することができないことは明らかである。 他方,フラグシップ・ホストは,「インターネットの至る所」からのクライアントが求めるサービスを提供するローカルエリア・ネットワーク内の複数のサーバーの中から,負荷が一定レベル以下のものを選択してクライアントのアクセスを確立するために,イエローページ・サーバーに負荷の状況を定期的に問い合わせ,テーブルを更新するという機能を有するものである。 引用例においては,以上のような転送メカニズムによるアクセスの方法を前提として,プロトコルを,「フラグシップ・ホストが,クライアントに対して,そのパケットをサーバー・ホストにリダイレクトする」ように修正することができるとしているのであり,このことは,プロトコルを修正することによって,例えば,「インターネットの至る所」からのクライアントがイエローページ・サービス(メール・サービス)を利用したいと考えて,パケットを送信することによりイエローページ・サーバー(メール・サーバー)へのアクセスを要求した場合(ただし,上記のとおり,特定の属性のセットを満足するサーバーを要求することはできない。),これを受け取ったフラグシップ・ホストが,パケットを特定のイエローページ・サーバー(メール・サーバー)に転送する代わりに,負荷の高くないイエローページ・サーバー(メール・サーバー)のアドレスを指定して,直接アクセスするように命令するようにするということを意味している。 そうすると,引用発明における「リダイレクト」は,引用例におけるアクセス方法の技術についての上記のような開示の中で理解されるべきものであって,あくまでも,ローカルエリア・ネットワーク内のサーバーが提供するイエローページ・サービスなどのサービスについて,「インターネットの至る所」からのクライアントが利用することができるようにする場合において,同ネットワーク内の負荷を調整するために,同ネットワーク内の唯一のホストであるフラグシップ・ホストによって行われるものである。 ウ本件発明1の「REDIRECTコマンド」本件明細書の特許請求の範囲の請求項1の記載は上記第2の2のとおりであるところ,その記載から,本件発明1の「REDIRECTコマンド」は,ディレクトリサーバーが,クライアントに対して返送するものであって,クライアントにおいて提供した記述子に対応する単一の目標URLを含み,同コマンドを受信したクライアントにおいて,同URLを用いて情報を自動的に要求させるものであり,その結果同URLによって識別されたページがクライアント側で表示される,というものであることは明らかである。 エ本件審決による判断の当否上記イ及びウによると,本件発明1の「REDIRECTコマンド」がクライアントにおいて情報ページを自動的に表示させるためのコマンドであって,ディレクトリサーバーによって行われるものであるのに対して,引用発明の「リダイレクト」は,ローカルエリア・ネットワーク内のサーバーに対する「インターネットの至る所」からのクライアントによるアクセスを確立する方法であって,このようなクライアントに対してローカルエリア・ネットワーク内で唯一のホストとなるフラグシップ・ホストによって行われるものであるということができる。 そして,一貫してインターネットにおけるアクセスを念頭に置く本件発明1は,ローカルエリア・ネットワーク内のサーバーとのアクセスを実現するためのフラグシップ・ホストに相当するサーバーの存在及びその機能としての「リダイレクト」によって,その技術的課題を解決しようとするものではないのであり,本件発明1の存在を知らない当業者がこのような引用例の記載に接したとしても,フラグシップ・ホストを必要としないインターネットのアクセス方法において,このような「リダイレクト」の構成を採用して,本件発明1のディレクトリサーバーによる「REDIRECTコマンド」に係る構成とするように動機付けられるということはできないし,引用例において,フラグシップ・ホストの機能から離れて「リダイレクト」の機能を採用しようと動機付ける記載も存在しない。そして,仮に,引用例に開示された事項についての技術的意義を離れて,「リダイレクト」という用語の抽象的な意義のみに基づいて本件発明1の「REDIRECTコマンド」と対比することを前提とするならば,排除されるべき「後知恵」の混入を避けることはできないといわなければならない。 なお,例えば,インターネットの分野において,膨大な情報を処理するためのサーバーの集合体を管理する手法として,同集合体中の特定のサーバーを代表サーバーとし,集合体を構成する他のサーバーにおいて役割を分担し,各サーバーの負荷を調整する技術があり得るとしても,このような技術と,集合体の外に存在する特定のサーバーや情報ページにアクセスする技術とは,その課題においても構成においても異なるものであるから,このような観点からも,引用発明の「リダイレクト」から本件発明1の「REDIRECTコマンド」に係る構成とすることを動機付けられることはないというべきである。 また,本件審決が周知技術とする内容が甲3のみから認定することができるかどうかは措くとしても,本件審決が認定したのは「クライアントがURLを用いて情報を要求し,前記URLにより識別された情報ページを前記クライアント側で表示すること」であって,これは,「サービスを提供するサーバーを特定することができるクライアント」の存在を前提とし,このようなクライアントに対して,引用発明のような「フラグシップ・ホストが転送したパケットへのサーバー応答やフラグシップ・ホストによるリダイレクトの方法によって,特定されたサーバーへのアクセスを確立すること」に対応するものであって,本件発明1のディレクトリサーバーと対比される引用発明のイエローページ・サーバーの機能とは何ら関係しないものというべきであるから,そもそも,本件審決の認定した周知技術を適用することによって,相違点2に係る構成とすることはできないといわざるを得ない。 さらに,引用発明のフラグシップ・ホストとイエローページ・サーバーを同一のサーバー上に設けることにより,主体についての相違が問題とならない構成とすることも理論的には想定することができるが,上記(2)のとおり,引用例において,イエローページ・サービスを提供するイエローページ・サーバーと転送メカニズムを担うフラグシップ・ホストが別々のサーバーとして明確に書き分けられた上,インターネットの至る所からのクライアントがフラグシップ・ホストによる転送メカニズムを通じてイエローページ・サーバーを利用することができることが明示的に記載されているにもかかわらず,このようなフラグシップ・ホストとイエローページ・サーバーの関係と関わりなく,これらのサーバーがそれぞれ有する機能的な構成だけを組み合わせて本件発明1の相違点に係る構成とすることに何らかの動機付けがあるということはできないから,このような観点からも,本件審決の相違点2についての判断を是認することはできない。 したがって,引用発明に基づいて相違点2に係る構成とすることが当業者にとって容易であるとした本件審決の判断は誤りであるといわざるを得ない。 (4)小括以上によると,本件発明1は引用発明に基づいて本件優先権主張日における当業者が容易に発明をすることができたということはできないから,取消事由2は理由があるというべきである。 そして,本件発明2ないし7は,いずれも本件発明1の発明特定事項を含み,これを更に限定するものであるから,本件発明2ないし7についても,当業者が容易に発明をすることができたということはできない。 3結論以上の次第であるから,原告主張の取消事由3について判断するまでもなく,本件審決は取り消されるべきものである。 |
| 裁判長裁判官 | 滝澤孝臣 |
|---|---|
| 裁判官 | 高部眞規子 |
| 裁判官 | 杜下弘記 |