戻る

平成２１年１１月５日判決言渡同日原本領収裁判所書記官
平成２０年（行ケ）第１０２９７号審決取消請求事件
口頭弁論終結日平成２１年１０月２２日
判決
原告インターネットナンバー株式会社
同訴訟代理人弁護士熊倉禎男
飯田圭
奥村直樹
同弁理士西島孝喜
中村佳正
被告株式会社ＮＥＴＰＩＡ
同訴訟代理人弁護士北村行夫
亀井弘泰
大井法子
杉浦尚子
雪丸真吾
芹澤繁
大藏隆子
村上弓恵
政岡史郎
吉田朋
杉田禎浩
近藤美智子
同補佐人弁理士樋口盛之助
原慎一郎
主文
１特許庁が無効２００７−８００２４３号事件につい
て平成２０年６月２６日にした審決を取り消す。
２訴訟費用は被告の負担とする。
事実及び理由
第１請求
主文１項同旨
第２事案の概要
本件は，原告が，下記１のとおりの手続において，原告の本件特許に係る発明の
うち，下記２の本件訂正後の請求項１ないし７の発明に係る特許に対する被告の無
効審判請求について，特許庁が同請求を認め当該特許を無効とした別紙審決書（写
し）の本件審決（その理由の要旨は下記３のとおり）には，下記４の取消事由があ
ると主張して，その取消しを求める事案である。
１特許庁における手続の経緯
(1)本件特許
発明の名称：インターネットサーバーのアクセス管理およびモニタシステム
原出願日：平成８年６月３日
パリ条約による優先権主張日：平成７年（１９９５年）６月７日（米国）（以下
「本件優先権主張日」という。）
本件出願（分割出願）日：平成１３年７月９日
出願番号：特願２００１−２０８２９６号
設定登録日：平成１８年１月２０日
登録番号：特許第３７６２８８２号
(2)本件手続
審判請求日：平成１９年１１月１日
訂正請求日：平成２０年１月２３日（以下，同日付けの訂正を「本件訂正」とい
う。）
審決日：平成２０年６月２６日
本件審決の結論：訂正を認める。特許第３７６２８８２号の請求項１ないし７に
係る発明についての特許を無効とする。
審決謄本送達日：平成２０年７月８日（原告に対する送達日）
２発明の要旨
本件発明の要旨は，本件訂正後の明細書（以下「本件明細書」という。）の特許
請求の範囲の請求項１ないし７に記載された次のとおりのもの（以下，請求項の番
号に従って，「本件発明１」などという。）である。
【請求項１】インターネットよりなるコンピュータネットワークを介したクライア
ントからサーバーシステムへの情報ページに対するアクセスを提供する方法であっ
て，
前記クライアントにおいて単一の目標ＵＲＬに対応する記述子を提供する段階と，
ディレクトリサーバーが，前記記述子を前記ディレクトリサーバーに存在する翻
訳データベースを用いて前記ＵＲＬにマッピングする段階と，
前記ディレクトリサーバーが，ＲＥＤＩＲＥＣＴコマンド中の前記ＵＲＬを前記
クライアントに返送する段階と，
前記クライアントに前記ＵＲＬを用いて情報を自動的に要求させる段階と，
前記ＵＲＬにより識別されたページを前記クライアント側で表示する段階と
を備えた情報ページに対するアクセス方法。
【請求項２】請求項１において，前記記述子が電話番号を備えた情報ページに対す
るアクセス方法。
【請求項３】請求項１において，前記記述子が記述項目を備えた情報ページに対す
るアクセス方法。
【請求項４】請求項３において，前記記述項目が会社名を含む情報ページに対する
アクセス方法。
【請求項５】請求項３において，前記記述項目が製品名を含む情報ページに対する
アクセス方法。
【請求項６】請求項３において，前記記述項目が音声により識別される情報ページ
に対するアクセス方法。
【請求項７】請求項１において，前記ＵＲＬにより識別されたページが管理ページ
である情報ページに対するアクセス方法。
３本件審決の理由の要旨
(1)本件審決の理由は，要するに，本件発明１ないし７は，いずれも，下記の
引用例記載の発明（以下「引用発明」という。）及び周知技術に基づいて，本件優
先権主張日当時の当該発明の属する技術の分野における通常の知識を有する者（以
下「当業者」という。）が容易に発明することができたものであって，本件発明１
ないし７に係る特許は，特許法２９条２項の規定に違反してされたものであるから，
同法１２３条１項２号の規定により無効とされる，というものである。
引用例：LarryL.Peterson,"AYellow-PagesServiceforaLocal-Area
Network",COMPUTERCOMMUNICATIONREVIEW,Volume17,Number5,SpecialIssue,ACM
Press,1988,p.235-242
(2)本件審決が認定した引用発明，本件発明１と引用発明との一致点及び相違
点は，以下のとおりである。なお，同相違点はいずれも，本件発明２ないし７と引
用発明との相違点に共通して含まれるものである。
引用発明：インターネットの至る所からクライアントがローカル・サーバーにア
クセスする方法であって，サーバーのセットが，イエローページ・サービスを実施
し，各サーバーは，使用可能なサービスおよびサーバーに関する情報のデータベー
スを維持し，各イエローページ・サーバーには，システム内で使用できるサービス
についての情報のデータベースが関連付けられ，データベースには，各サービスと
そのサービスを提供するサーバーのセットとが結びつけて格納され，
クライアントは，サービス名およびサーバーが持つべき任意の属性を指定して，
イエローページ・サービスにサーバーのアドレスを問い合わせ，
イエローページ・サービスは，サービス名を，サービスを提供しようとするサー
バーのアドレスにマッピングし，
イエローページ・サービスは，クライアントの要求を満たす一或いは二以上のサ
ーバーのアドレスを返送し，
転送メカニズムでは，ウェルノウンポートをサーバーのアドレスに結びつけるテ
ーブルが関連付けられ，クライアントは，フラグシップ・ホスト上のウェルノウン
ポート宛に一或いは二以上のパケットを送信することによって，サーバーに接続し，
フラグシップ・ホストは，そのパケットをシステム内のサーバーに転送し，
転送メカニズムと対照的に，フラグシップ・ホストがクライアントに対して，そ
のパケットをサーバー・ホストにリダイレクトする必要があると知らせるように修
正できる，
クライアントがローカル・サーバーにアクセスする方法。
一致点：「インターネットよりなるコンピュータネットワークを介したクライア
ントからサーバーシステムへのアクセスを提供する方法であって，
前記クライアントにおいて記述子を提供する段階と，
サーバーが，前記記述子を前記サーバーに存在するデータベースを用いてアドレ
スにマッピングする段階と，
前記サーバーが，前記アドレスを前記クライアントに返送する段階と，
を備えたアクセス方法。」である点。
相違点１：本件発明１では，サーバーが「ディレクトリサーバー」であり，デー
タベースが「翻訳データベース」であり，「前記クライアントにおいて単一の目標
ＵＲＬに対応する記述子を提供する段階」，及び「ディレクトリサーバーが，前記
記述子を前記ディレクトリサーバーに存在する翻訳データベースを用いて前記ＵＲ
Ｌにマッピングする段階」を有するのに対して，引用発明では，イエローページ・
サービスのサーバーが「ディレクトリサーバー」であるか，そのサーバーの「デー
タベース」が「翻訳データベース」であるか明らかでなく，記述子は「単一の目標
ＵＲＬ」に対応するか明らかでなく，「サービス名を，サービスを提供しようとす
るサーバーのアドレスにマッピング」している点。
相違点２：本件発明１は，サーバーシステムへのアクセスが「情報ページ」に対
してであり，ディレクトリサーバーが「ＲＥＤＩＲＥＣＴコマンド中の前記ＵＲ
Ｌ」をクライアントに返送しており，かつ，「前記クライアントに前記ＵＲＬを用
いて情報を自動的に要求させる段階」，及び「前記ＵＲＬにより識別されたページ
を前記クライアント側で表示する段階」を有するのに対して，引用発明では，「情
報ページ」に対してアクセスするか明らかでなく，サーバーはクライアントに「サ
ービスを提供するサーバーのアドレス」を返送しており，かつ，「前記クライアン
トに前記ＵＲＬを用いて情報を自動的に要求させる段階」，及び「前記ＵＲＬによ
り識別されたページを前記クライアント側で表示する段階」を有するか明らかでな
い点。
４取消事由
(1)一致点の認定の誤り（取消事由１）
(2)相違点２についての判断の誤り（取消事由２）
(3)相違点１についての判断の誤り（取消事由３）
第３当事者の主張
１取消事由１（一致点の認定の誤り）について
〔原告の主張〕
本件審決は，引用発明についての理解を誤った結果，以下の各点において本件発
明１と引用発明との一致点の認定を誤り，その相違点を看過したものであるから，
取消しを免れない。
(1)「ＵＲＬ」と「アドレス」
本件審決は，本件発明１の「ＵＲＬ」と引用発明の「アドレス」は，上位概念で
ある「アドレス」において一致すると認定したが，本件発明１における「ＵＲＬ」
は，インターネット上のサーバーなどの資源の所在地を意味するものであるのに対
して，引用発明の「アドレス」とは，あるサーバーのローカルエリアネットワーク
内における所在を示すものといった程度の理解しかできないから，両者は相違する。
さらに，引用例に開示されているイエローページ・サービスとインターネット上
の遠隔クライアントの接続は，ＴＣＰプロトコルにより実現されるものであるとこ
ろ，引用例の「転送対リダイレクション」の項において言及されている「リダイレ
クション」も，当然にＴＣＰプロトコルが用いられるものである。そして，ＴＣＰ
プロトコルは「配信先の特定」と「正確な電文の受け渡し」という処理を行うもの
であり，本来的に「送信元ポート番号」及び「宛先ポート番号」の２点間を指定す
るものであって，再接続先を含めた３点間を指定するものではない。また，引用例
においては，ＴＣＰプロトコルを修正する転送メカニズムが開示されているが，こ
れもＴＣＰセグメントフォーマットにおいて「送（発）信元ポート番号」及び「宛
先ポート番号」に割り振られているそれぞれ１６ビットの情報フィールドを修正し
て指定されるものであり，技術的に転送先のアドレスまで指定することは困難であ
る。仮に，ＴＣＰヘッダを更に修正してフラグシップ・ホスト→クライアント→サ
ーバーという流れで再接続を実現しようとした場合でも，インターネットの至る所
から到達可能なシステムを構築するためには，取り扱うことのできる情報量が著し
く減少することになるから，このような修正を行う動機付けが存在せず，むしろ阻
害要因が存在するというべきである。
引用例には，「プロトコルは，フラグシップ・ホストがクライアントに対して，
そのパケットをサーバー・ホストにリダイレクトする必要があると知らせるように
修正できるであろう」との記載があるが，同記載は，結局のところ，そのようにす
る理論上の可能性がゼロとまではいえないという程度の意味であり，引用例の他の
記載と併せ読めば，引用例において，「イエローページ・サービス」とインターネ
ット上の遠隔クライアントとの接続においては「転送メカニズム」の構成が必須で
あり，実質的には「リダイレクション」は採用するに値しない技術であると考えら
れていたというべきである。そうであるからこそ，引用例には，「リダイレクショ
ン」の場合におけるイエローページ・サービスの仕様変更についても何ら説明され
ていないのである。
したがって，引用発明における「リダイレクト」（リダイレクション）によって，
フラグシップ・ホストが，インターネット上の遠隔クライアントに送信されたパケ
ットをサーバーへと再接続することはできないから，引用発明における「アドレ
ス」がインターネット上のサーバーの所在地を意味する「ＵＲＬ」となることもあ
り得ないというべきであり，本件審決による一致点の認定はこの点においても誤っ
ている。
(2)「記述子」と「サービス名」
本件審決は，引用発明の「サービス名」はサービスを識別する「識別子」である
ことは明らかであり，本件発明１の「記述子」は「識別子」を含む上位概念である
として，両者は「記述子」において一致すると認定したが，そもそも引用発明は
「サービス名」のみではなく，「サービス名」及び複数の「属性」によってサーバ
ーのアドレスを照会しているものであるのに対して，本件発明１は請求項１の記載
から明らかなように「単一の目標ＵＲＬに対応」するものであるから，両者は相違
する。
〔被告の主張〕
以下のとおり，原告の主張はいずれも失当であり，取消事由１は理由がない。
(1)「ＵＲＬ」と「アドレス」
本件審決は，本件発明１の「ＵＲＬ」は「アドレス」という上位概念に含まれる
とした上，引用発明と本件発明１とは「サーバーが，前記識別子を前記ディレクト
リサーバーに存在するデータベースを用いてアドレスにマッピング」する点で一致
すると認定したのであって，これは，「アドレス」と「ＵＲＬ」が相違することを
前提として，引用発明がインターネットに関する発明であって，引用例にサーバー
のアドレスを返送することが開示されていることから，本件特許出願に係る本件優
先権主張日当時の技術常識を参酌して，インターネットアドレス，すなわち「ＵＲ
Ｌ」の返送も開示されていると解釈したものであるから，原告の主張は前提を誤っ
たものであり，本件審決の一致点の認定に誤りはない。
さらに，原告は，引用例に記載された「リダイレクト」（リダイレクション）に
よって，フラグシップ・ホストが，インターネット上の遠隔クライアントに送信さ
れたパケットをサーバーへと再接続することはできないと主張する。ここで，引用
例に開示された技術においては，フラグシップ・ホスト内にロード・マネージャが
存在し，ローカル・サーバーの負荷バランスについてのテーブルを常に更新してい
るのであり，クライアントから送られた属性の指定はロードマネージャが認識する
が，これを更新している転送メカニズム・テーブルによってバインディングされた
ローカル・サーバーに転送する。この転送はＴＣＰ内でＴＣＰプロトコルの本来的
機能として行われるから，遠隔クライアントが特定の属性のセットを直接に転送先
のサーバーに指定するのではなく，ロードマネージャが遠隔クライアントからの問
合せに応じて，その指定を満足する最適なサーバーを決定し，ＴＣＰプロトコルに
よって，仲介者として，目的のサーバーに転送するのである。引用例には「ロード
・マネージャのみが，イエローページ・サービスのクライアントとなる。」とある
のは，このことを指すものであり，遠隔クライアントが転送によってローカル・サ
ーバーと接続されることは何ら否定されていない。また，引用例の他の記載からも，
引用発明は，転送メカニズムによって，クライアントとその要求を満たすサーバー
を直接に接続する技術であることは疑問の余地がない。したがって，原告の主張は
失当である。
(2)「記述子」と「サービス名」
本件審決は，本件発明１の「記述子」は「識別子」を含む上位概念であり，引用
発明と本件発明１とは，「前記クライアントにおいて記述子を提供」する点で一致
すると認定したものであって，単に「記述子」と「サービス名」を対比し，両者が
「記述子」において一致するとしたものではない。そして，原告が指摘する「属
性」については，引用発明において属性の指定は「０」（指定しない）場合もあり
得るのであるから，引用発明において「サービス名」及び複数の「属性」によって
サーバーのアドレスを照会していることを前提とする原告の主張は誤りである。
なお，本件明細書には，本件発明１の「記述子」が「特定かつ唯一のＵＲＬ」と
結びつくという限定を伴ったものであると解釈する根拠となる記載は存在せず，本
件発明１において，それ自体は「特定かつ唯一のＵＲＬ」と結びつかない「記述
子」の送信に対して「特定かつ唯一のＵＲＬ」が返送されるのは，「記述子」の問
題ではなく，「翻訳データベース」の構成の問題である。
２取消事由２（相違点２についての判断の誤り）について
〔原告の主張〕
本件審決は，引用発明に基づいて本件発明１の相違点２に係る構成とすることは
当業者にとって容易であると判断したが，この判断は，以下の各点において誤って
おり，本件審決は取消しを免れない。
(1)「ＲＥＤＩＲＥＣＴコマンド」と「リダイレクト」との共通性
本件審決は，本件発明１の「ＲＥＤＩＲＥＣＴコマンド」と引用発明の「リダイ
レクト」は「ＲＥＤＩＲＥＣＴ」に関する命令である点で共通であるとしたが，本
件発明１の「ＲＥＤＩＲＥＣＴコマンド」は同コマンド中の特定，かつ，唯一のＵ
ＲＬがクライアントへと返送されることによって自動的にクライアントをして特定，
かつ，唯一のＵＲＬに対応するウェブへと情報要求させるものであるのに対して，
引用例には「リダイレクト」に関して「パケットをサーバー・ホストにリダイレク
トする必要があると知らせるように修正できる」との開示しか存在しないのであり，
「リダイレクト」が何を意味するのか明らかではないから，用語にのみ着目して上
記のとおり共通であるとした本件審決の認定は誤りである。
また，本件発明１の「ＲＥＤＩＲＥＣＴコマンド」については，本件特許出願の
審査の段階において，国際公開第９４／０６２５１号パンフレットに「公衆ネット
ワークを利用したクライアントからの接続要求に対し，サーバ１２において，翻訳
データベースを用いてアクセス先のアドレスにマッピングし，該アドレスをＲＥＤ
ＩＲＥＣＴコマンドを用いてクライアントに返送することが記載されている。」と
して拒絶理由（甲４０）が通知された際，意見書（甲４１）において「ＲＥＤＩＲ
ＥＣＴの機能についても，本願発明が，記述子（電話番号，会社名，製品名等）に
マッピングされたＵＲＬを返送する際のコマンドであるのに対して，引用文献１
（判決注：上記国際公開パンフレットのこと）では，信号経路の確立の再指向にお
いて，最適な経路を選定するために使用されるメッセージであり，機能的にも明ら
かに異なる技術であります」との意見を述べ，これが受け容れられて特許査定され
たという経緯があることに照らしても，単に用語それ自体として一致するという理
由によって，両者が共通であるという前提に立つことはできない。
さらに，上記１〔原告の主張〕(1)のとおり，そもそも引用発明の「リダイレク
ト」（リダイレクション）においては，フラグシップ・ホストからインターネット
上の遠隔クライアントへ送信されたパケットに基づき，サーバーへ再接続すること
はできないというべきであるから，本件発明１の「ＲＥＤＩＲＥＣＴコマンド」と
引用発明の「リダイレクト」は明らかに異なるものである。
(2)「ＲＥＤＩＲＥＣＴコマンド中の…ＵＲＬ」の開示
ア本件審決は，引用例における「パケットをサーバーホストにリダイレクトす
る必要があると知らせるように修正できる」との記載を根拠として，「イエローペ
ージ・サーバーがクライアントに対して『ＲＥＤＩＲＥＣＴコマンド中のＵＲＬ』
を送信し…のように構成することは当業者が容易に想到し得ることである」と判断
した。
しかしながら，本件発明１においては，その「ＲＥＤＩＲＥＣＴコマンド」が単
一の目標ＵＲＬを含むため，「ＲＥＤＩＲＥＣＴコマンド」が返送された側のクラ
イアントにおいて当該コマンド中のＵＲＬを用いて自動的に情報要求することが可
能となるのに対して，引用発明については，引用例中に上記記載が存するのみであ
って，クライアントに返される「リダイレクト」中に「ＵＲＬ」はもちろん「アド
レス」が含まれているのかどうかさえ明らかではない。
したがって，引用例における上記記載を根拠として，「ＲＥＤＩＲＥＣＴコマン
ド中のＵＲＬ」を送信するとの構成に想到することが容易であるとの本件審決の判
断には，論理の飛躍がある。
イまた，そもそも引用例において「リダイレクト」の対象として開示されてい
るのは「パケット」であり，本件特許に係る本件優先権主張日における当業者の技
術常識に照らすと，この「リダイレクト」は「ＩＣＭＰリダイレクト」を意味する
ものであって，これはインターネットにおいて通信経路選択を行うための機能を指
すものと理解すべきところ，ＯＳＩ基本参照モデルのネットワーク層（第３層）又
はトランスポート層（第４層）において実現されるものであるのに対して，本件発
明１の「ＲＥＤＩＲＥＣＴコマンド」は，コマンド中にウェブ（ＷＷＷ）で使用さ
れるＨＴＴＰプロトコル（ＯＳＩ基本参照モデルの第７層）において規定されるＵ
ＲＬを含めることができるものである。
ＯＳＩ基本参照モデルの７つの層は，それぞれが明確に機能分担された階層モデ
ルであるところ，異なる層に属する技術同士は互いに機能が異なるものであり，第
１層から第４層まで（下位４階層）は主に通信機能の規約であり，第５層から第７
層（上位３階層）は送受するデータ処理に関する規約であるとされている（甲４
９）ことから，下位４階層において機能する引用発明の「リダイレクト」にＵＲＬ
を含ませるようにし，上位３階層において機能する本件発明１の「ＲＥＤＩＲＥＣ
Ｔコマンド」と同様のものとすることは，当業者にとって技術的に不可能なことと
いうべきである。
ウまた，本件審決においては，周知技術(甲３）として「クライアントがＵＲ
Ｌを用いて情報を要求し，前記ＵＲＬにより識別された情報ページを前記クライア
ント側で表示すること」を摘示するが，この周知技術はクライアントがＵＲＬを得
た後の動作についてのものであるから，そもそもクライアントが「アドレス」を取
得していない引用発明に適用することはできない。
エさらに，上記１〔原告の主張〕(1)のとおり，引用発明の「リダイレクト」
(リダイレクション）に係る構成では，フラグシップ・ホストからクライアントに
対して送信されたパケットに基づき，サーバーへ再接続させることは技術的に不可
能であるから，引用発明において「リダイレクト」の構成を採用した場合，引用発
明はインターネットへの適用可能性を欠くというべきであり，「リダイレクト」に
ＵＲＬを含めることも不可能である。
(3)「クライアントに返送する」との構成の容易想到性
本件審決は，本件発明１の「ディレクトリサーバー」に対応する構成として，引
用発明の「イエローページ・サーバー」を認定しているところ，本件発明１におい
て「ＲＥＤＩＲＥＣＴコマンド」をクライアントに返送する主体が「ディレクトリ
サーバー」であることは特許請求の範囲の記載から明らかであるのに対して，引用
発明においてクライアントに対して「リダイレクトする必要がある」と知らせる主
体は「フラグシップ・ホスト」であって，「イエローページ・サーバー」でないこ
とも明らかである。そして，引用例において「フラグシップ・ホスト」の代わりに
「ディレクトリサーバー」が「リダイレクトする必要がある」ように修正できるこ
とを開示又は示唆する記載は存在しない。
そうすると，本件審決は，本件発明１の「ＲＥＤＩＲＥＣＴコマンド」と引用発
明の「リダイレクト」の主体についての相違を無視して，単に「ＲＥＤＩＲＥＣＴ
に関する命令である点で共通する」ことのみによって，相違点２に係る構成とする
ことが容易であるとの結論を導いたものであり，少なくとも，相違点２のうち，デ
ィレクトリサーバーが「ＲＥＤＩＲＥＣＴコマンド中の前記ＵＲＬ」をクライアン
トに返送するとの本件発明１に係る構成とすることが容易であるということはでき
ないから，本件審決の相違点２についての判断は誤りである。
〔被告の主張〕
以下のとおり，原告の主張はいずれも失当であり，取消事由２は理由がない。
(1)「ＲＥＤＩＲＥＣＴコマンド」と「リダイレクト」の共通性
本件審決は，本件明細書の記載から，「ＲＥＤＩＲＥＣＴコマンド」の具体的意
義について「サーバーからクライアントに送信され，クライアントが前記サーバー
とは別のサーバーへ自動的に送信する命令」のことであると認定する一方，引用発
明の「リダイレクト」について「フラグシップ・ホストがクライアントに対して，
そのパケットをサーバー・ホストにリダイレクトする必要があると知らせる」もの
であると認定し，これらを比較した上で両者が「ＲＥＤＩＲＥＣＴに関する命令で
ある点で共通する」とまとめたのであって，原告の主張は，本件審決を正解しない
的外れなものである。
さらに，上記１〔被告の主張〕(1)のとおり，引用発明の「リダイレクト」（リ
ダイレクション）においては，フラグシップ・ホストからインターネット上の遠隔
クライアントへ送信されたパケットに基づき，サーバーへ再接続することはできな
いとの原告の主張は失当である。
(2)「ＲＥＤＩＲＥＣＴコマンド中の…ＵＲＬ」の開示
ア引用発明は「イエローページ・サービスは，クライアントの要求を満たす１
あるいは２以上のサーバーのアドレスを返送する」ことを内容としているところ，
ネットワーク上のデータ送受信方法であるパケット交換技術によって，送受信され
るデータは一旦「パケット」単位に分割されるから，当然，返送される「アドレ
ス」も「パケット」の形で送受信されるのであり，「パケット」であるから「アド
レス」や「ＵＲＬ」ではないなどということはできない。
イまた，原告は，ＯＳＩ基本参照モデルについて指摘するが，同モデルは，ネ
ットワーク上でのデータ処理の過程を説明するために考え出された通信モデルであ
り，１個のコンピュータネットワーク通信の構造を役割・機能から７つの階層に分
けることを標準化したものであり，確かに，パケットの経路選択を行う機能は第３
層に分類されているが，上位層のメッセージもデータ処理の過程で一旦パケットと
いう形態になるのである。
そして，引用発明のイエローページ・サービスは，ディレクトリサービスの１つ
として知られていたものであり，ディレクトリサービスはＯＳＩ基本参照モデルお
上位層に分類されるＯＳＩアプリケーションであるし，ディレクトリサービスにア
クセスするプロトコルである「ＬＤＡＰ」（又はＤＡＰ）がアプリケーション層
（第７層）のものであることも明らかである。
また，引用例における「これは接続指向プロトコル（例えばＴＣＰ）のケースで
は妥当である可能性があるが…」との記載は第４層のプロトコル（ＴＣＰ）にも言
及している。
したがって，引用発明の「リダイレクト」の説明部分に「パケット」との記載が
あるからといって，それだけでその部分が第３層又は第４層に限定した技術につい
ての説明であると解することにはならないばかりか，引用例は，全体としてイエロ
ーページ・サービス（＝ディレクトリサービス＝第７層）に関する文献であるとい
うべきであるから，引用発明の「リダイレクト」もアプリケーション層について述
べたものと解される。
なお，本件優先権主張日当時において，「リダイレクト」が「ＩＣＭＰリダイレ
クト」を意味するものであるとの技術常識は存在しないし，そもそも「ＩＣＭＰリ
ダイレクト」はルータが指示するＩＣＭＰの命令であるところ，引用発明の「リダ
イレクト」は，「フラグシップ・ホスト」が主体となるものであって，「ホスト」
は「ＩＰアドレスが付けられているが経路制御（ルーティング）を行わない機器」
をいうものであるから，引用発明の「リダイレクト」が「ＩＣＭＰリダイレクト」
と同義であると解釈することはできない。
ウ仮に，引用発明の「リダイレクト」が第７層のものでなかったとしても，本
件優先権主張日当時において，「Redirect」の設定においてＵＲＬは「http://ホ
スト名」から書かなければならないことは周知の技術事項であり，引用発明をＨＴ
ＴＰによるＷＷＷサービスに適用するに当たってＵＲＬを含む「Redirect」を用い
ることは当業者にとって自明のことというべきであるから，引用発明に周知の技術
事項を適用して「ＲＥＤＩＲＥＣＴコマンド中の…ＵＲＬ」の構成とすることは当
業者にとって容易であり，本件審決の判断に誤りはない。
エさらに，上記１〔被告の主張〕(1)のとおり，引用発明の「リダイレクト」
（リダイレクション）においては，フラグシップ・ホストからインターネット上の
遠隔クライアントへ送信されたパケットに基づき，サーバーへ再接続することはで
きないとの主張は失当である。そして，引用例には「転送対リダイレクション」の
項において，接続指向プロトコル（例えばＴＣＰ）においてはむしろリダイレクト
の方が妥当である可能性があると述べているのであり，本件優先権主張日当時にお
いて周知であったＨＴＴＰのリダイレクトを引用例に記載された引用発明に適用す
ることは当業者であれば容易なことである。
(3)「クライアントに返送する」との構成の容易想到性
引用例には「テストベッドは，ＤＡＲＰＡインターネット内のローカルエリア・
ネットワークなので，遠隔クライアントがアクセスできるサーバーは，一或いは二
以上のシステムのホスト上にあり，よく知られているポートで待機するサーバーに
限定される。ローカル・システム内の唯一のホストが，フラグシップ・ホストとし
て指定される。」との記載があるように，イエローページ・サービスにおいて，ク
ライアントがアクセスするイエローページ・サーバーがシステムのホスト上に存在
し，そのホストの１つがフラグシップ・ホストとして指定されるのであるから，フ
ラグシップ・ホスト上にはイエローページ・サーバーが存在すると解することがで
きる。
そして，イエローページ・サーバーはディレクトリサーバーであると理解するこ
とができるから，引用発明の「リダイレクト」の送信主体を「ディレクトリサーバ
ー」と構成することは当業者にとって容易である。
仮に，フラグシップ・ホストがイエローページ・サーバーそのものではないこと
を重視したとしても，コンピュータの汎用性と高能力化の進展にかんがみると，両
者を物理的に１つのサーバーで実現することは単なる設計事項というべきであるか
ら，インターネット上で動作可能なプロトコルであるＨＴＴＰを前提とすれば，そ
の具体的な設計も当業者には自明のことであるというべきである。
以上によると，原告が主張する「ＲＥＤＩＲＥＣＴコマンド」の返送主体と「リ
ダイレクトする必要がある」と知らせる主体の相違を考慮しても，本件発明１の相
違点２に係る構成とすることは当業者にとって容易であるというべきであり，本件
審決の判断に誤りはない。
３取消事由３（相違点１についての判断の誤り）について
〔原告の主張〕
また，本件審決は，相違点１についても，同相違点のうち，「記述子は『単一の
目標ＵＲＬ』に対応するか明らかでなく」の点に関し，「そのようにするため，記
述子を単一の目標ＵＲＬにマッピングするように代え（る）」ことは容易であると
判断しているが，この判断は以下のとおり誤りであり，本件審決は，この点におい
ても，取消しを免れない。
(1)「目標ＵＲＬ」と「単一のアドレス」との相違
本件発明１の「目標ＵＲＬ」はユーザーによって意図される特定のＵＲＬを意味
することは一義的に明らかであって，記述子との関係において，１対１又は多対１
で対応するものである。
これに対して，引用発明は「サービス名及び任意の属性」という検索条件が与え
られた結果，その条件を満足するサーバーのアドレスを返送する検索システムにす
ぎないのであり，そこで検索されるアドレスは元来不特定なものである。また，引
用発明においては，検索条件であるmodeの設定いかんによって単一アドレスのみ
が返送されるように構成すること自体は不可能ではないが，そのような単一アドレ
スも，あくまで検索条件に適合する複数のサーバーの中からランダムに選択される
不特定のアドレスのうちの１つにすぎない。さらに，そのような単一アドレスの選
択は"atrandom"（出任せ，行き当たりばったり）に行われるものであって，同一，
かつ，特定のアドレスが必ず返送されるものではない。
そうすると，引用例には，本件発明１の「目標ＵＲＬ」に相当する構成の開示が
存在しないのであり，この点を無視して，引用発明に基づいて相違点１に係る構成
とすることが容易であるとした本件審決は，相違点１について実質的に判断してい
ないともいうことができる。
(2)「目標ＵＲＬ」の構成とするための変更の要否
上記(1)のとおり，本件発明１の「目標ＵＲＬ」はユーザーによって意図される
特定のＵＲＬを意味するから，引用発明がこのような「目標ＵＲＬ」に相当する構
成を有するようにするためには，引用発明において「サービス名」及び「サーバー
が持つべき任意の属性」と特定の「サーバー」とがひも付けされるようにする必要
がある。
しかしながら，引用例には，不特定の検索結果が返されるシステムから，常に単
一，かつ，特定のアドレスが返されるシステムへと変更することについての示唆は
何ら存在しないし，そのような変更が本件優先権主張日において周知技術であった
ことを示す証拠も存在しない。
しかも，仮に，引用発明において無作為に選択される不特定の単一サーバーのア
ドレスを，常に特定のものにしようとするのであれば，クライアントが与える「属
性」及び「サービス名」の設定方法等，引用発明の他の構成において必然的に大幅
に変更しなければならないにも関わらず，それらの構成をどのように変更するかに
ついては，引用例に何らの開示も示唆も存在しない。
(3)「単一の」と「一或いは二以上の」との相違
本件発明１は「クライアントにおいて単一の目標ＵＲＬに対応する記述子を提供
する」構成を有するものであり，この「単一」とは「一のみ」を意味するものであ
って，「一以上」と区別されるものであることは明らかである。
他方，引用発明は，あくまでも「一或いは二以上の」サーバーアドレスを返すも
のであり，「一」のサーバーアドレスが返される場合と「二以上」のサーバーアド
レスが返される場合とを別個の発明として区別しているものではないのである。
したがって，引用発明のうち，「一」のみのサーバーアドレスが返される構成を
恣意的に切り出した上，本件発明１の「単一の…ＵＲＬ」と一致すると認定したこ
と自体がそもそも誤りであるというべきであり，本件審決の相違点１についての判
断は，このような恣意的な対比を前提とするものである点においても失当である。
〔被告の主張〕
以下のとおり，原告の主張はいずれも失当であり，取消事由２は理由がない。
(1)「目標ＵＲＬ」と「単一のアドレス」との相違
本件審決は，引用発明の「アドレス」がデータベースによってマッピングされる
ことにより特定されたアドレスであることを認定し，「一或いは二以上の」サーバ
ーのアドレスが「単一のＵＲＬ」を含むものと技術的に解釈することができること
を示した上，これらをまとめて「記述子を単一の目標ＵＲＬにマッピングするよう
に代え（る）」ことは当業者にとって容易であると判断したものであり，本件審決
が「目標ＵＲＬ」についての判断を行っていないということはできない。
(2)「目標ＵＲＬ」の構成とするための変更の要否
原告は，本件発明１の「目標ＵＲＬ」はユーザーによって意図される特定のＵＲ
Ｌを意味するから，引用発明がこのような「目標ＵＲＬ」に相当する構成を有する
ようにするためには，クライアントが与える「属性」及び「サービス名」の設定方
法等，引用発明の他の構成において必然的に大幅に変更しなければならないと主張
するが，どのような記述子に対してどのようなＵＲＬを返送するかはデータベース
の構成の問題であり，選択アルゴリズムの設定次第で，１つのサーバーのアドレス
のみを抽出選択するようにできるというべきである。
(3)「単一の」と「一或いは二以上の」との相違
上記(1)のとおり，本件審決は，相違点１についての判断の前提として，引用発
明における「一或いは二以上の」サーバーのアドレスが，「単一のＵＲＬ」を含む
ものと技術的に解釈することができることを示しており，上記(2)のとおり，どの
ような記述子に対してどのようなＵＲＬを返送するかはデータベースの構成の問題
であるということができるから，本件審決による相違点１についての判断に誤りは
ない。
第４当裁判所の判断
１取消事由１（一致点の認定の誤り）について
原告は，本件審決が，本件発明１の「ＵＲＬ」と引用発明の「アドレス」は上位
概念である「アドレス」において一致するとした点は誤りであると主張するが，そ
の内容は，本件発明１の構成とすることについて阻害要因が存在するというもので
あり，実質的には相違点の判断についての誤りの主張である。
また，原告は，本件審決が，本件発明１の「記述子」と引用発明の「サービス
名」は上位概念である「記述子」において一致するとした点は誤りであると主張す
るが，その内容は，引用発明においては，「サービス名」及び複数の「属性」によ
ってサーバーのアドレスを照会しているのであって，本件発明１とはこの点におい
て相違するというものである。
しかしながら，本件審決による相違点１の認定は，前記第２の３(2)のとおりで
あり，本件審決は，引用発明において「記述子が『単一の目標ＵＲＬ』に対応する
か明らかでなく，『サービス名を，サービスを提供しようとするサーバーのアドレ
スにマッピング』している点」を本件発明１と引用発明との相違点１として認定し
ているのであるから，原告主張に係る点は，同相違点についての判断において検討
されるべきであるということはできるが，そのことから直ちに，本件発明１と引用
発明の特定の要素が上位概念において一致するとした本件審決の認定に誤りがある
ということはできないというべきである。
したがって，取消事由１は理由がない。
２取消事由２（相違点２についての判断の誤り）について
(1)引用例の記載
引用例（甲１）には，以下の各記載がある。
ア「摘要サービス名をサーバーのアドレスにマッピングするイエローページ
・サービスを紹介する。このサービスは，属性のセットを各サーバーに関連づける
という点で新規なものである。クライアントは，サービスを要求する際にサーバー
が所有すべき属性を指定し，イエローページ・サービスは，どのサーバーが要求を
満たすかを判断する。イエローページ・サービスのローカルエリア・ネットワーク
内での実施の説明だけでなく，インターネットの至る所からクライアントがローカ
ル・サーバーにアクセスできるようにするために，本サービスが，使用可能なイン
ターネット通信プロトコルとどのように統合できるかを示す。」（訳文１頁６∼１
３行）
イ「我々の設計は，従来のネーム・サーバー…とは，２つの点で異なる。
第１に，サーバーの特徴およびプロパティを記述する属性（attribute）のセッ
トが各サーバーに関連付けられる。サービスを受けたいクライアントは，サービス
名およびサーバーが持つべき任意の属性を指定して，イエローページ・サービスに
サーバーのアドレスを問い合わせる。イエローページ・サービスは，クライアント
の要求を満たす一或いは二以上のサーバーのアドレスを返送する。
第２に，インターネットの至る所からのクライアントは，適切なサーバーを選択
するために，中間エージェントを通じて，自律システム内で使用可能なイエローペ
ージ・サービスを使用するサーバーに問い合わせる。具体的には，ローカル・シス
テム内のフラッグシップ（flagship）・ホストは，システムが提供するサービスの
セットをインターネット・ネーミング・サービスによって通知する。クライアント
は，そのホスト上でサーバーを使用できるかのように，フラグシップ・ホストに接
続する。次に，フラグシップ・ホスト上で動作する転送メカニズム（forwarding
mechanism）が，実際にそのサービスを提供するサーバーにクライアントを接続さ
せる（patch）。転送メカニズムは，イエローページに，サービスを提供するサー
バーのうち，最も負荷の軽いサーバーのアドレスを判断するよう問い合わせる。転
送メカニズムを通じた間接参照および適切なサーバーの選択は，遠隔クライアント
からは隠される。」（訳文１頁２３行∼２頁５行）
ウ「２．アーキテクチャ
サーバーのセットが，イエローページ・サービスを実施する。各サーバーは，使
用可能なサービスおよびサーバーに関する情報のデータベースを維持する。システ
ム内のクライアントは，SunRemoteProcedureCallメカニズム…を使用して，一
或いは二以上のサーバー上の動作を要求する。…
２．１属性
属性は，サーバーのプロパティまたは特徴を示す統語的要素である。…
…ある所定のサーバーに関連付けられる属性は，イエローページ・データベース
に記録される。クライアントは，ある特定のサービスを提供するサーバーについて
イエローページに問い合わせる際，属性のセットを送信する。
属性は，二つの次元に沿って分類される。一つの次元に沿って，属性は，静的
（static）であるかまたは動的（dynamic）であるかに基づいて区別される。静的
属性は，サーバーの固定のプロパティ，例えば，プリンタの速度やプロセッサのア
ーキテクチャに該当する。静的属性は，例えばアップグレードなどによって変わる
場合もあるが，かかる変更は，稀であり，イエローページ・データベースへの更新
によって簡単に追跡できる。これに対し，動的属性は，例えば，プロセッサの負荷
や印刷キューのジョブ数のように絶えず変化する。動的属性の重要な特徴は，イエ
ローページ・サービスが属性に基づく判断を要求されるよりもはるかにより頻繁に
変化することである。従って，実用的な理由から，サーバーの動的属性は，要求が
あった場合にのみ計算されるべきである。
もう一つの次元に沿って，属性は，絶対的（absolute）であるかまたは相対的
（relative）であるかに従って区別される。絶対的な属性は，他の全てのサーバー
とは関係なく決定することができるサーバーの性質，例えば，サーバーのアーキテ
クチャや負荷などに該当する。これに対し，相対的属性は，サーバーのセットにつ
いて計算されるもので，負荷が最小のプロセッサや出力率が最大のプリンタなどで
ある。
クライアントは，ある所定のサービスを提供する一或いは二以上のサーバーのア
ドレスを取得するためにイエローページ・サーバーに問い合わせる。クライアント
は，サービス名の指定だけでなく，指定した属性条件のセットを満たすサーバーが
サービスを提供するものとして選択されることを要求する。…」（訳文２頁１４行
∼３頁１３行）
エ「２．２データベース
各イエローページ・サーバーには，システム内で使用できるサービスについての
情報のデータベースが関連付けられる。データベースには，各サービスとそのサー
ビスを提供するサーバーのセットとがバインディングされて（結びつけて）格納さ
れる。
service───>{server,server,...server}12n
つぎに，サーバーは，以下のように定義される。
server≡
ここで，addressは，クライアントにとって意味のある文字列であり，─例えば，
印刷サーバーのアドレスは，単に，プリンタ装置の名称によって指定され，─また，
registered_attrは，サーバーに関連付けられる，静的，絶対的属性の組であ
る。」（訳文３頁２１∼３０行）
オ「４．転送（forwarding）メカニズム
このセクションでは，イエローページ・サービスがどのようにしてインターネッ
ト・トランスポート・プロトコルに統合され，それによって，クライアントがイン
ターネットの至る所から自律システム内のサーバーにアクセスできるのかを説明す
る。テストベッドは，DARPAインターネット内のローカルエリア・ネットワークな
ので，遠隔クライアントがアクセスできるサーバーは，一或いは二以上のシステム
のホスト上にあり，よく知られているポートで待機するサーバーに限定される…。
ローカル・システム内の唯一のホストが，フラグシップ・ホストとして指定され
る。例えば，arizona.eduという名前のホストが，アリゾナ大学のフラグシップ・
ホストである。システムは，ドメイン名システム（domainnamingsystem）…によ
って，リソース・レコード−サービスごとにひとつある可能性がある−のセットを
登録することによって，フラグシップがサービスのセットをインターネット・クラ
イアントに提供するものとして広告する。例えば，MXリソース・レコードは，シ
ステムのためのメール・サービスがフラグシップ・ホスト…で使用できることを示
す。クライアントは，システムにおいて特定のサービスを提供するホストのアドレ
スを取得するためにドメイン名サーバーに問い合わせ，フラグシップ・ホストのア
ドレスが返される。その後，クライアントは，フラグシップ・ホスト上のウェルノ
ウンポート宛に一或いは二以上のパケットを送信することによって，サーバーに問
い合わせる。すると，フラグシップ・ホストは，そのパケットをシステム内のサー
バーに転送する。このように，転送メカニズムは，ウェルノウンポートにおいてサ
ーバーにアクセスする戦略と類似している。フラグシップは，システムに対して，
『ウェルノウンホスト』の役割を果たす。
転送メカニズムがTCP内でどのように実施されるかを更に詳細に検討する。フラ
グシップ・ホスト上で動作するTCPモジュールが，転送メカニズムを含むように変
更される。転送メカニズムには，ウェルノウンをサーバーのアドレスにバインディ
ングするテーブルが関連付けられる。そのテーブルには，以下のフォームのバイン
ディングが含まれる。
well-known-port───>{addr,addr,...addr}12m
ここで，各サーバーのアドレスは，ポート，ホスト・アドレスの対で指定される。
あるポート宛のパケットがTCPモジュールに到着すると，そのポートへの転送が行
われるべきか，すなわち，テーブルにエントリが存在するかについて，転送メカニ
ズムが問い合わせられる。パケットが新規クライアントからの場合，転送サーバー
は，使用可能なサーバーをランダムにひとつ選択し，パケットをそのサーバーに転
送する。すなわち，転送メカニズムは，パケットの宛先のアドレスをそのサーバー
のアドレスに設定し，パケットを再送信する。これにより，以下の対が，接続に通
常関連付けられるプロトコル・コントロール・ブロック（protocolcontrol
block）に記録される。
->clientclientserverserver
同一の接続上で送信される後続のパケットは，同一のサーバーに転送される。
サーバー・ホスト上でTCPモジュールは，転送が行われていることを認識し，全
ての応答メッセージを直接クライアントに送信する。サーバー・ホスト上のTCPは，
パケットのソース・アドレスをフラグシップ・ホストのアドレスに設定し，それに
よってクライアントには，クライアントがまだフラグシップ・ホストと通信してい
るかのように見える。従って，転送が行われていることをクライアントが認識する
ことはない。
…
フラグシップ・ホスト上で動作するロード・マネージャは，転送メカニズム・テ
ーブル内のウェルノウンポートのそれぞれをサーバーのセットにバインディングす
る。ロード・マネージャの目的は，ローカル・サーバーの負荷のバランスをとるた
めに，遠隔作業をローカル・サーバーに分配することである。メール・サービスな
どの，一般的に使用可能なサービスの場合，負荷がある閾値以下の全てのプロセッ
サ・サーバーを定期的に問い合わせることによって，マネージャは，イエローペー
ジ・サービスのクライアントとなる。そして，マネージャは，転送メカニズムのテ
ーブルを適宜更新する。ただし，転送メカニズムは，TCPに組み込まれているので，
遠隔クライアントは，特定の属性のセットを満足するサーバーを要求することはで
きず，ロード・マネージャのみが，イエローページ・サービスのクライアントとな
る。」（訳文８頁８行∼１０頁９行）
カ「統合
イエローページ・サービスは，転送メカニズム及びロード・マネージャによって
インターネット・トランスポート・プロトコルと統合されている。遠隔クライアン
トがシステムのイエローページ・サーバーの１つに直接的に接触できない根本的な
理由はないが，転送メカニズムがわずかなコストでクライアントによって要求され
るサービスを考えられる最新の瞬間−接続確立中−のサーバーに結び付けることが
できることを留意することが重要である。直感的に，これは，遠隔クライアントと
システム間の『距離』がシステムの『直径』より桁違いに大きいインターネットに
おいて重要である。すなわち，この方式は，サービスを提供するサーバーのセット
を変更するよりも，サーバーに接続を確立するために長い時間がかかる環境には適
切である。
また，この方式は，自律システム抽象化の背後にサーバーについての情報を隠す
ために魅力的である。言い換えると，サービスを提供するシステムの中のホストは，
サーバーを実現するホスト上のプロセスがサーバーを呼び出すクライアントの目に
見えないのと同じように，サービスを要求するクライアントの目には見えない。こ
のような情報の非表示は，インターネット命名機構に対する負担を軽減し，したが
ってさらに多くのサービス及びサーバーがインターネット全体で使用できるように
なるために十分拡大縮小する（scales）。」（訳文１２頁５∼２１行）
キ「転送対リダイレクション
転送メカニズムはクライアントとサーバー間の仲介人の機能を果たす。これは，
クライアントが間接参照から守られているため，トランスポートプロトコルに対す
るあらゆる変更を要求しないという優位点を有する。対照的に，プロトコルは，フ
ラグシップ・ホストがクライアントに対して，そのパケットをサーバー・ホストに
リダイレクトする必要があると知らせるように修正できるであろう。これは接続指
向プロトコル（例えばTCP）のケースでは妥当である可能性があるが，コネクショ
ンレス・プロトコル（例えばUDP）のケースでは単にパケットをサーバー・ホスト
に転送する方がより費用効率が高い。この考え方は，VMTP［１］によって提供され
ている転送メカニズムでも一貫している。」（訳文１２頁２２∼３０行）
(2)引用例に開示された事項
上記引用例の記載から，引用例には以下の事項が開示されていると認められる。
ア引用例の主題
引用例は昭和６３年（１９８８年）に米国で発表された論文であり，ローカルエ
リア・ネットワーク内における「イエローページ・サービス」の実施について説明
するとともに，クライアントが，インターネットの至るところからローカル・サー
バーにアクセスし，「イエローページ・サービス」を使用するために，「イエロー
ページ・サービス」を使用可能なインターネット通信プロトコルとどのように統合
することができるかを示すことを内容とするものである。
イイエローページ・サービス
引用例において説明される「イエローページ・サービス」は，サーバーのセット
により実施されるものであり，各サーバーは使用可能なサービス及びサーバーに関
する情報のデータベースを維持する。
そして，「イエローページ・サービス」において，サーバーに関する情報は，サ
ーバーに関連付けられる属性（静的・動的，絶対的・相対的）としてデータベース
に記録されており，ローカルエリア・ネットワーク内のクライアントがあるサービ
スを提供するサーバーを問い合わせる際，属性のセットを送信すると，上記データ
ベースと関連付けられたイエローページ・サーバーはクライアントが指定した属性
条件のセットを満たすサーバーのアドレスがクライアントに返送される。
ウ転送メカニズム
クライアントがインターネットの至る所から，ローカルエリアネットワーク内に
あるイエローページ・サーバーを含むすべてのサーバーにアクセス可能とし，上記
イのようなイエローページ・サービスを利用するために，転送メカニズムを採用す
る。
ローカルエリア・ネットワーク内の唯一のホストが，「フラグシップ・ホスト」
として指定され，フラグシップ・ホストが提供するサービスのセット，すなわち，
ローカルエリア・ネットワークに含まれるサーバーが提供することができるサービ
スのセットをドメイン名システムに登録し，インターネット・クライアントに対し
て広告する。
クライアントが，特定のサービスを提供するサーバー（ホスト）のアドレスをド
メイン名システム（domainnamingsystem）に問い合わせると，フラグシップ・ホ
ストのアドレスが返送され，クライアントはフラグシップ・ホストに対して，例え
ば，メール・サービスなどの提供を求めるサービスを１あるいは２以上のパケット
により送信する。
フラグシップ・ホストは，クライアントが求めるサービスを提供するサーバーの
うち使用可能なサーバーをランダムに１つ選択して，そのサーバーに対してパケッ
トを転送するが，フラグシップ・ホスト上で動作するロード・マネージャは，ロー
カル・サーバーの負荷のバランスをとるために，イエローページ・サーバーに定期
的に負荷の状況を問い合わせ，転送メカニズムのテーブルを適宜更新している。
転送を受けたサーバーは，パケットの送信元のアドレスをフラグシップ・ホスト
のアドレスに設定してからクライアントに対して直接応答するため，クライアント
は転送が行われていることを認識することはない。
ただし，上記の転送メカニズムは，TCPに組み込まれているため，クライアント
は，ローカルエリア・ネットワーク内においてイエローページ・サービスを利用す
る場合のように，特定の属性のセットを満足するサーバーを要求することはできな
い。
エリダイレクション
転送メカニズムによると，トランスポートプロトコルを変更する必要がないが，
プロトコル自体を，フラグシップ・ホストが，クライアントに対して，そのパケッ
トをサーバー・ホストにリダイレクトするように修正することができる。
(3)相違点２についての判断
ア本件審決の判断の構造
本件審決は，相違点２について判断するに当たって，本件発明１の「ＲＥＤＩＲ
ＥＣＴコマンド」とは，サーバーからクライアントに送信され，クライアントが前
記サーバーとは別のサーバーへ自動的に送信する命令のことであると認定する一方，
引用発明の「リダイレクト」も「フラグシップ・ホストがクライアントに対して，
そのパケットをサーバー・ホストにリダイレクトする必要があると知らせるもので
あるから，本件発明の「ＲＥＤＩＲＥＣＴコマンド」と引用発明の「リダイレク
ト」とは，ＲＥＤＩＲＥＣＴに関する命令である点で共通すると説示した上，引用
発明において，イエローページ・サービスがクライアントにサービスを提供するサ
ーバーのアドレスを送信し，その後クライアントが前記サービスを提供するサーバ
ーにアクセスしてサービスを実行する場合に，リダイレクトを採用すること及びそ
の際にアクセスを自動的に行うことに格別の困難性はないとした。
その上で，本件審決は，「クライアントがＵＲＬを用いて情報を要求し，前記Ｕ
ＲＬにより識別された情報ページを前記クライアント側で表示することは，当業者
にとって周知技術である。」と認定した上，相違点２に関して，引用発明において，
上記認定に係る周知技術のように，クライアントがＵＲＬを用いて情報を要求し，
前記ＵＲＬにより識別された情報ページを前記クライアント側で表示することがで
きるように，イエローページ・サーバーがクライアントに対して「ＲＥＤＩＲＥＣ
Ｔコマンド中のＵＲＬ」を送信し，クライアントが自動的にサービスを提供するサ
ーバーの「情報ページ」に対してアクセスできるようにし，「前記クライアントに
前記ＵＲＬを用いて情報を自動的に要求させる段階」及び「前記ＵＲＬにより識別
されたページを前記クライアント側で表示する段階」を設けて本件発明のように構
成することは容易であると判断している。
本件審決の上記判断は，引用発明の「リダイレクト」と本件発明１の「ＲＥＤＩ
ＲＥＣＴコマンド」の共通性を前提として，引用発明において，「イエローページ
・サービス」が「リダイレクト」を採用することについて容易であるとしたものと
理解することができる。
イ引用例における「リダイレクト」
上記(2)で認定したところによると，引用例に開示された「リダイレクト」に関
して，次のようにいうことができる。
引用例には，「イエローページ・サービス」が開示されるとともに，「インター
ネットの至る所」からのクライアントが「イエローページ・サービス」を含むロー
カルエリア・ネットワーク内のサーバーが提供するサービスを利用することができ
るようにするために，フラグシップ・ホストによってクライアントから送信された
パケットを転送して，ローカルエリア・ネットワーク内のサーバーにアクセスする
方法の技術が開示されている。
そして，「インターネットの至る所」からのクライアントは，フラグシップ・ホ
ストに対して，ローカルエリア・ネットワーク内においてイエローページ・サービ
スを利用する場合のように特定の属性のセットを満足するサーバーを要求すること
はできないとされているから，引用例におけるフラグシップ・ホストとイエローペ
ージ・サーバーを同視することができないことは明らかである。
他方，フラグシップ・ホストは，「インターネットの至る所」からのクライアン
トが求めるサービスを提供するローカルエリア・ネットワーク内の複数のサーバー
の中から，負荷が一定レベル以下のものを選択してクライアントのアクセスを確立
するために，イエローページ・サーバーに負荷の状況を定期的に問い合わせ，テー
ブルを更新するという機能を有するものである。
引用例においては，以上のような転送メカニズムによるアクセスの方法を前提と
して，プロトコルを，「フラグシップ・ホストが，クライアントに対して，そのパ
ケットをサーバー・ホストにリダイレクトする」ように修正することができるとし
ているのであり，このことは，プロトコルを修正することによって，例えば，「イ
ンターネットの至る所」からのクライアントがイエローページ・サービス（メール
・サービス）を利用したいと考えて，パケットを送信することによりイエローペー
ジ・サーバー（メール・サーバー）へのアクセスを要求した場合（ただし，上記の
とおり，特定の属性のセットを満足するサーバーを要求することはできない。），
これを受け取ったフラグシップ・ホストが，パケットを特定のイエローページ・サ
ーバー（メール・サーバー）に転送する代わりに，負荷の高くないイエローページ
・サーバー（メール・サーバー）のアドレスを指定して，直接アクセスするように
命令するようにするということを意味している。
そうすると，引用発明における「リダイレクト」は，引用例におけるアクセス方
法の技術についての上記のような開示の中で理解されるべきものであって，あくま
でも，ローカルエリア・ネットワーク内のサーバーが提供するイエローページ・サ
ービスなどのサービスについて，「インターネットの至る所」からのクライアント
が利用することができるようにする場合において，同ネットワーク内の負荷を調整
するために，同ネットワーク内の唯一のホストであるフラグシップ・ホストによっ
て行われるものである。
ウ本件発明１の「ＲＥＤＩＲＥＣＴコマンド」
本件明細書の特許請求の範囲の請求項１の記載は上記第２の２のとおりであると
ころ，その記載から，本件発明１の「ＲＥＤＩＲＥＣＴコマンド」は，ディレクト
リサーバーが，クライアントに対して返送するものであって，クライアントにおい
て提供した記述子に対応する単一の目標ＵＲＬを含み，同コマンドを受信したクラ
イアントにおいて，同ＵＲＬを用いて情報を自動的に要求させるものであり，その
結果同ＵＲＬによって識別されたページがクライアント側で表示される，というも
のであることは明らかである。
エ本件審決による判断の当否
上記イ及びウによると，本件発明１の「ＲＥＤＩＲＥＣＴコマンド」がクライア
ントにおいて情報ページを自動的に表示させるためのコマンドであって，ディレク
トリサーバーによって行われるものであるのに対して，引用発明の「リダイレク
ト」は，ローカルエリア・ネットワーク内のサーバーに対する「インターネットの
至る所」からのクライアントによるアクセスを確立する方法であって，このような
クライアントに対してローカルエリア・ネットワーク内で唯一のホストとなるフラ
グシップ・ホストによって行われるものであるということができる。
そして，一貫してインターネットにおけるアクセスを念頭に置く本件発明１は，
ローカルエリア・ネットワーク内のサーバーとのアクセスを実現するためのフラグ
シップ・ホストに相当するサーバーの存在及びその機能としての「リダイレクト」
によって，その技術的課題を解決しようとするものではないのであり，本件発明１
の存在を知らない当業者がこのような引用例の記載に接したとしても，フラグシッ
プ・ホストを必要としないインターネットのアクセス方法において，このような
「リダイレクト」の構成を採用して，本件発明１のディレクトリサーバーによる
「ＲＥＤＩＲＥＣＴコマンド」に係る構成とするように動機付けられるということ
はできないし，引用例において，フラグシップ・ホストの機能から離れて「リダイ
レクト」の機能を採用しようと動機付ける記載も存在しない。そして，仮に，引用
例に開示された事項についての技術的意義を離れて，「リダイレクト」という用語
の抽象的な意義のみに基づいて本件発明１の「ＲＥＤＩＲＥＣＴコマンド」と対比
することを前提とするならば，排除されるべき「後知恵」の混入を避けることはで
きないといわなければならない。
なお，例えば，インターネットの分野において，膨大な情報を処理するためのサ
ーバーの集合体を管理する手法として，同集合体中の特定のサーバーを代表サーバ
ーとし，集合体を構成する他のサーバーにおいて役割を分担し，各サーバーの負荷
を調整する技術があり得るとしても，このような技術と，集合体の外に存在する特
定のサーバーや情報ページにアクセスする技術とは，その課題においても構成にお
いても異なるものであるから，このような観点からも，引用発明の「リダイレク
ト」から本件発明１の「ＲＥＤＩＲＥＣＴコマンド」に係る構成とすることを動機
付けられることはないというべきである。
また，本件審決が周知技術とする内容が甲３のみから認定することができるかど
うかは措くとしても，本件審決が認定したのは「クライアントがＵＲＬを用いて情
報を要求し，前記ＵＲＬにより識別された情報ページを前記クライアント側で表示
すること」であって，これは，「サービスを提供するサーバーを特定することがで
きるクライアント」の存在を前提とし，このようなクライアントに対して，引用発
明のような「フラグシップ・ホストが転送したパケットへのサーバー応答やフラグ
シップ・ホストによるリダイレクトの方法によって，特定されたサーバーへのアク
セスを確立すること」に対応するものであって，本件発明１のディレクトリサーバ
ーと対比される引用発明のイエローページ・サーバーの機能とは何ら関係しないも
のというべきであるから，そもそも，本件審決の認定した周知技術を適用すること
によって，相違点２に係る構成とすることはできないといわざるを得ない。
さらに，引用発明のフラグシップ・ホストとイエローページ・サーバーを同一の
サーバー上に設けることにより，主体についての相違が問題とならない構成とする
ことも理論的には想定することができるが，上記(2)のとおり，引用例において，
イエローページ・サービスを提供するイエローページ・サーバーと転送メカニズム
を担うフラグシップ・ホストが別々のサーバーとして明確に書き分けられた上，イ
ンターネットの至る所からのクライアントがフラグシップ・ホストによる転送メカ
ニズムを通じてイエローページ・サーバーを利用することができることが明示的に
記載されているにもかかわらず，このようなフラグシップ・ホストとイエローペー
ジ・サーバーの関係と関わりなく，これらのサーバーがそれぞれ有する機能的な構
成だけを組み合わせて本件発明１の相違点に係る構成とすることに何らかの動機付
けがあるということはできないから，このような観点からも，本件審決の相違点２
についての判断を是認することはできない。
したがって，引用発明に基づいて相違点２に係る構成とすることが当業者にとっ
て容易であるとした本件審決の判断は誤りであるといわざるを得ない。
(4)小括
以上によると，本件発明１は引用発明に基づいて本件優先権主張日における当業
者が容易に発明をすることができたということはできないから，取消事由２は理由
があるというべきである。
そして，本件発明２ないし７は，いずれも本件発明１の発明特定事項を含み，こ
れを更に限定するものであるから，本件発明２ないし７についても，当業者が容易
に発明をすることができたということはできない。
３結論
以上の次第であるから，原告主張の取消事由３について判断するまでもなく，本
件審決は取り消されるべきものである。
知的財産高等裁判所第４部
裁判長裁判官滝澤孝臣
裁判官高部眞規子
裁判官杜下弘記

戻る