【事件の表示】
　上記当事者間の特許第３７６２８８２号「インターネットサーバーのアクセス管理およびモニタシステム」の特許無効審判事件についてされた平成２０年　６月２６日付け審決に対し、知的財産高等裁判所において審決取消の判決（平成２０年（行ケ）第１０２９７号平成２１年１１月　５日判決言渡）があったので、さらに審理のうえ、次のとおり審決する。
【結　論】
　訂正を認める。
　本件審判の請求は、成り立たない。
　審判費用は、請求人の負担とする。
【理　由】
第１　手続の経緯
　本件特許第３７６２８８２号は，平成８年６月３日（優先権主張外国庁受理１９９５年６月７日，米国）を国際出願日とする特願平９−５０３０８４号の一部を平成１３年７月９日に新たな特許出願としたものであって，平成１８年１月２０日に本件特許の設定登録がなされた。
　その後，請求人株式会社ＮＥＴＰＩＡより平成１９年１１月１日に，本件特許の請求項１ないし７について無効とすることを求める本件無効審判の請求があった。これに対し，被請求人インターネットナンバー株式会社は，平成２０年１月２３日に訂正請求書及び審判事件答弁書を提出したところ，請求人は平成２０年３月４日に審判事件弁駁書を提出した。さらにその後，平成２０年５月２０日に口頭審理が行われ，口頭審理調書によれば審判請求人は，審判請求書の無効理由のうち，特許法第２９条第１項第３号の主張は取下げ，被請求人はこれに同意し，なお，当該主張における甲第１号証及び甲第２号証の記載に係る主張は，特許法第２９条第２項の主張に援用するとされた。そして，平成２０年６月２６日に「訂正を認める。特許第３７６２８８２号の請求項１−７に係る発明についての特許を無効とする。」との審決がなされた。
　これに対して，訂正後の発明について特許法第２９条第２項の規定に違反して無効とすべきであるとした審決の判断の誤りを取消理由として審決取消の訴が被請求人によりなされ，知的財産高等裁判所において平成２０年（行ケ）第１０２９７号として審理され，平成２１年１１月５日に「特許庁が無効２００７−８００２４３号事件について平成２０年６月２６日にした審決を取り消す。」との判決が言い渡された。
　請求人は，上記判決を不服として最高裁判所に上告及び上告受理の申立をしたが，最高裁判所により平成２２年３月１１日に「１　本件上告を棄却する。２　本件を上告審として受理しない。３　上告費用及び申立費用は上告人兼申立人の負担とする。」との決定がなされて，上記判決は確定した。
　その後，請求人より平成２２年４月１９日付けで上申書が提出された。
　
第２　訂正の適否
　被請求人は平成２０年１月２３日に訂正請求書を提出して特許請求の範囲の減縮及び明りょうでない記載の釈明を目的として請求項１の訂正（以下，「本件訂正」という。）を求めた。 
　
１．訂正の内容 
（１）訂正事項ａ 
　請求項１において，「前記クライアントにおいて記述子を提供する段階と，」を「前記クライアントにおいて単一の目標ＵＲＬに対応する記述子を提供する段階と，」と訂正する。 
　
（２）訂正事項ｂ 
　請求項１において，「翻訳データベースを用いてＵＲＬにマッピングする段階と，」を「翻訳データベースを用いて前記ＵＲＬにマッピングする段階と，」と訂正する。 
　
（３）訂正事項ｃ 
　請求項１において，「情報を要求させる段階と，」を「情報を自動的に要求させる段階と，」と訂正する。 
　
２．被請求人の主張する訂正理由の概要 
（１）訂正事項ａについて 
　訂正事項ａは，記述子に「単一の目標ＵＲＬに対応する」という事項を追加するものであって，特許請求の範囲を減縮しつつ明りょうでない記載の釈明を目的とするものである。この追加事項は，明細書の段落【００４３】，【００４５】等の記載に基づくものである。 
　「目標ＵＲＬ」が「単一」であることについても，特許請求の範囲の記載上，「ＵＲＬ」には何ら「複数のＵＲＬ」などの文言が付されておらず，用語の通常の用法として「ＵＲＬ」は単独のものであると解され，特許請求の範囲には「ディレクトリサーバーが，前記記述子を前記ディレクトリサーバーに存在する翻訳データベースを用いてＵＲＬにマッピングする段階」，「ディレクトリサーバーが，ＲＥＤＩＲＥＣＴコマンド中の前記ＵＲＬを前記クライアントに返送する段階と，」，「前記クライアントに前記ＵＲＬを用いて情報を要求させる段階と，」，「前記ＵＲＬにより識別されたページを前記クライアント側で表示する段階…」という記載が存在し，「前記ＵＲＬにより識別されたページ」が「前記クライアント側で表示」されるものであることを考慮すると，当然「前記ＵＲＬ」も単独であると解されるものである（仮に，複数の「ＵＲＬ」がマッピングされているとすれば，「前記ＵＲＬ」の中から特定の一つの「ＵＲＬ」を選択する過程を経なければ，「クライアント側」でページを表示することは不可能となってしまうにも関わらず，特許請求の範囲の記載上，何らＵＲＬを選別する過程は示されていない）。 
　したがって，上記の訂正は，特許法第１３４条の２第１項第１号の「特許請求の範囲の減縮」及び同項第３号の「明りょうでない記載の釈明」に該当し，同規定を充足する。これにより，上記の訂正は特許法第１３４条の２第５項で準用する同法第１２６条第３項，第４項を充足する。 
　
（２）訂正事項ｂについて 
　上記の訂正は，請求項１において，「翻訳データベースを用いてＵＲＬにマッピングする段階と，」を「翻訳データベースを用いて前記ＵＲＬにマッピングする段階と，」として，「ＵＲＬ」が上記訂正事項ａに基づく「単一の目標ＵＲＬ」を指すものであることを明りようにするものであるから明りょうでない記載の釈明を目的とするものである。したがって，上記の訂正は，特許法第１３４条の２第１項第３号の「明りょうでない記載の釈明」に該当し，同規定を充足する。 
　
（３）訂正事項ｃについて 
　上記の訂正は，請求項１において，「情報を要求させる段階と，」を「情報を自動的に要求させる段階と，」として「自動的に」という事項を追加するものであるから特許請求の範囲を減縮しつつ明りょうでない記載の釈明を目的とするものである。 
　この追加事項は，明細書の段落【００１２】，【００２９】，【００３２】，【００４５】等に基づくものである。したがって，上記の訂正は，特許法第１３４条の２第５項で準用する同法第１２６条第３項，第４項を充足する。 
　
３．訂正請求に対する審判請求人の主張の概要 
　訂正事項ａにおける「単一の目標ＵＲＬに対応する」の構成は，本件明細書全文および図面中に記載のない事項であって直ちにその追加を認められるものではない。 
　「単一の」の語に関しては少なくとも本件明細書全文において一切記載のない新規な文言であるため，特許法第１３４条の２第５項で準用する同法第１２６条第３項を具備せず，本件訂正は認められるべきでない。 
　もっとも，本件特許発明における「マッピング」や「ＲＥＤＩＲＥＣＴコマンド」がいずれも甲第１号証や甲第２号証の引用発明から明らかな単一のＵＲＬを処理するものであるとの技術常識に照らせば，自ずと本件発明における「ＵＲＬ」も単一のものと把握することができるが，上記訂正事項ａが当初明細書の記載の範囲内として認められるとするならば，それは甲第１号証ないし甲第２号証の技術常識を参酌する結果であって，本件発明が甲第１号証記載の発明と同一，または甲第１号証と甲第２号証記載の発明から容易に想到できることを意味するに他ならない。 
　
４．訂正請求に対する当審の判断 
（１）訂正事項ａについて 
　訂正事項ａは請求項１において，「前記クライアントにおいて記述子を提供する段階と，」とあるのを「前記クライアントにおいて単一の目標ＵＲＬに対応する記述子を提供する段階と，」と訂正するものであるが，「記述子」と「目標ＵＲＬ」の関係について発明の詳細な説明には，以下のような記載がある。 
（ｉ）「一旦ＮＵＭＢＥＲがディレクトリサーバー６０２により受信されると，ディレクトリサーバーはデータベース６０４を用いて，ＮＵＭＢＥＲに対応するサービスを実施する商業サーバーおよびドキュメントを記述する目標ＵＲＬにＮＵＭＢＥＲを翻訳する。」（段落【００４３】）
（ｉｉ）「メッセージ２では，ディレクトリサーバー６０２がＲＥＤＩＲＥＣＴをクライアント６０１に送信し，これには，データベース６０４から演算されたＮＵＭＢＥＲに対する目標ＵＲＬが記述されている。クライアントブラウザ６０１は続いて自動的にメッセージ３を送信し，このＵＲＬのコンテンツをＧＥＴする。」（段落【００４５】）
　上記（ｉ）（ｉｉ）の記載によれば，記述子に相当する「ＮＵＭＢＥＲ」から目標ＵＲＬを求めることが記載されている。これら（ｉ），（ｉｉ）の記載から，クライアントにおいて提供される記述子は「目標ＵＲＬ」に対応したものであると認められる。 
　また，「記述子」と「（目標）ＵＲＬ」との対応関係について本件明細書には更に以下の記載がある。 
（ｉｉｉ）「ディレクトリサーバーが，前記記述子を前記ディレクトリサーバーに存在する翻訳データベースを用いてＵＲＬにマッピングする段階と， 前記ディレクトリサーバーが，ＲＥＤＩＲＥＣＴコマンド中の前記ＵＲＬを前記クライアントに返送する段階と， 前記クライアントに前記ＵＲＬを用いて情報を要求させる段階と， 前記ＵＲＬにより識別されたページを前記クライアント側で表示する段階」（請求項１） 
（ｉｖ）「本発明の一構成では，商業者のサービスにアクセスするためにユーザが従来の電話番号，またはその他の識別子を利用できるようにする便が設けられている。これらの商業者サービスはＳＩＤを用いて任意に保護され得る。好ましい実施形態では，図６に示されるように，ウェブブラウザクライアント６０１がユーザからの電話番号を受理するため“ダイヤル”アイコン上をクリックし，キーボードを介して電話番号を入力することのような“ダイヤル”コマンドを提供する。ブラウザは次いでＮＵＭＢＥＲがユーザにより指定された電話番号，またはその他の識別子である，書式“ｈｔｔｐ：／／ｄｉｒｅｃｔｏｒｙ．ｎｅｔ／ＮＵＭＢＥＲ”のＵＲＬを構成する。ブラウザは次いでこのＵＲＬにより指定されたドキュメントのＧＥＴを行い，ディレクトリサーバー６０２に連絡し，メッセージ１で要求されたＮＵＭＢＥＲを送信する。」（段落【００４１】） 
（ｖ）「メッセージ２では，ディレクトリサーバー６０２がＲＥＤＩＲＥＣＴをクライアント６０１に送信し，これには，データベース６０４から演算されたＮＵＭＢＥＲに対する目標ＵＲＬが記述されている。クライアントブラウザ６０１は続いて自動的にメッセージ３を送信し，このＵＲＬのコンテンツをＧＥＴする。商業者サーバー６０３はメッセージ４におけるこの情報を返送する。」（段落【００４５】） 
　
　これらの記載（ｉｉｉ）〜（ｖ）には記述子が複数のＵＲＬに対応することが記載されているわけではなく，仮に記述子が複数のＵＲＬに対応するとした場合には，「ＵＲＬにより識別されたページを前記クライアント側で表示する段階」において複数のＵＲＬから特定のＵＲＬを選択することが必要であるが，そのようなことは記載はされておらず，むしろ，「翻訳データベースを用いてＵＲＬにマッピング」することや「ブラウザは次いでこのＵＲＬにより指定されたドキュメントのＧＥＴ」を行うこと，「データベース６０４から演算されたＮＵＭＢＥＲに対する目標ＵＲＬが記述され」「クライアントブラウザ６０１は続いて自動的にメッセージ３を送信し，このＵＲＬのコンテンツをＧＥＴ」することを通常の意味に解釈すれば，記述子は単一のＵＲＬに対応するものと解される。 
　以上のことから，「前記クライアントにおいて記述子を提供する段階と，」とあるのを「前記クライアントにおいて単一の目標ＵＲＬに対応する記述子を提供する段階と，」とする訂正事項ａは，願書に最初に添付した明細書，特許請求の範囲又は図面に記載した事項の範囲内においてしたものである。そして，該訂正事項ａが特許請求の範囲を減縮するものであり，実質上特許請求の範囲を拡張し又は変更するものではないことは明らかである。 
　
（２）訂正事項ｂについて 
　請求項１の記載によれば，「クライアントにおいて記述子を提供する段階」，「ディレクトリサーバーが，前記記述子を前記ディレクトリサーバーに存在する翻訳データベースを用いてＵＲＬにマッピングする段階」，「前記ディレクトリサーバーが，ＲＥＤＩＲＥＣＴコマンド中の前記ＵＲＬを前記クライアントに返送する段階」，「前記クライアントに前記ＵＲＬを用いて情報を要求させる段階」，及び「前記ＵＲＬにより識別されたページを前記クライアント側で表示する段階」の各段階を経てクライアントは情報ページに対してアクセスをすることができる。ここで，「クライアントにおいて記述子を提供する段階」は訂正事項ａにおいて，「クライアントにおいて単一の目標ＵＲＬに対応する記述子を提供する段階」との訂正がなされた。 
　訂正事項ｂは，請求項１において，「翻訳データベースを用いてＵＲＬにマッピングする段階と，」を「翻訳データベースを用いて前記ＵＲＬにマッピングする段階と，」と訂正するものである。
　そして，「クライアントにおいて単一の目標ＵＲＬに対応する記述子を提供する段階」を経て，「ディレクトリサーバーが，前記記述子を前記ディレクトリサーバーに存在する翻訳データベースを用いてＵＲＬにマッピングする段階」が行われるのであるから，「翻訳データベースを用いてＵＲＬにマッピングする段階」における「ＵＲＬ」が，「クライアントにおいて単一の目標ＵＲＬに対応する記述子を提供する段階」の「単一の目標ＵＲＬ」を意味することは当然のことであり，「前記ＵＲＬ」は「ＵＲＬ」が「単一の目標ＵＲＬ」であることを明りょうにするものである。よって，訂正事項ｂは，明りょうでない記載の釈明を目的としたものであって，願書に最初に添付した明細書，特許請求の範囲又は図面に記載した事項の範囲内においてしたものである。そして，実質上特許請求の範囲を拡張し又は変更するものではないことは明らかである。 
　
（３）訂正事項ｃについて 
　「情報を要求させる段階」について，発明の詳細な説明には以下の記載がある。 
　「メッセージ２では，ディレクトリサーバー６０２がＲＥＤＩＲＥＣＴをクライアント６０１に送信し，これには，データベース６０４から演算されたＮＵＭＢＥＲに対する目標ＵＲＬが記述されている。クライアントブラウザ６０１は続いて自動的にメッセージ３を送信し，このＵＲＬのコンテンツをＧＥＴする。」（段落【００４５】） 
　この記載から「情報を要求させる段階」について要求は自動的になされることは明らかである。よって，訂正事項ｃは，願書に最初に添付した明細書，特許請求の範囲又は図面に記載した事項の範囲内においてしたものであり，特許請求の範囲の減縮を目的としたものであって，実質上特許請求の範囲を拡張し又は変更するものではないことは明らかである。 
　
（４）本件訂正についてのまとめ
　以上のとおりであるから，本件訂正（訂正事項ａ〜ｃ）は，願書に最初に添付した明細書，特許請求の範囲又は図面に記載した事項の範囲内においてしたものであり，特許請求の範囲の減縮，及び明りょうでない記載の釈明を目的とするものである。また，これらの訂正は実質上特許請求の範囲を拡張し又は変更するものではない。 
 　したがって，本件訂正は，特許法第１３４条の２第１項第１号の「特許請求の範囲の減縮」及び同項第３号の「明りょうでない記載の釈明」に該当し，同条第５項で準用する同法第１２６条第３項及び第４項の規定に適合するので本件訂正を認める。 
　
第３　本件訂正発明 
　本件特許の請求項１−７に係る発明は，訂正された特許請求の範囲の請求項１−７に記載された事項により特定される，次のとおりのものである。 
　
【請求項１】 
Ａ．インターネットよりなるコンピュータネットワークを介したクライアントからサーバーシステムへの情報ページに対するアクセスを提供する方法であって， 
Ｂ．前記クライアントにおいて単一の目標ＵＲＬに対応する記述子を提供する段階と， 
Ｃ．ディレクトリサーバーが，前記記述子を前記ディレクトリサーバーに存在する翻訳データベースを用いて前記ＵＲＬにマッピングする段階と， 
Ｄ．前記ディレクトリサーバーが，ＲＥＤＩＲＥＣＴコマンド中の前記ＵＲＬを前記クライアントに返送する段階と， 
Ｅ．前記クライアントに前記ＵＲＬを用いて情報を自動的に要求させる段階と， 
Ｆ．前記ＵＲＬにより識別されたページを前記クライアント側で表示する段階と 
Ｇ．を備えた情報ページに対するアクセス方法。 
【請求項２】 
請求項１において，前記記述子が電話番号を備えた情報ページに対するアクセス方法。 
【請求項３】 
請求項１において，前記記述子が記述項目を備えた情報ページに対するアクセス方法。 
【請求項４】 
請求項３において，前記記述項目が会社名を含む情報ページに対するアクセス方法。 
【請求項５】 
請求項３において，前記記述項目が製品名を含む情報ページに対するアクセス方法。 
【請求項６】 
請求項３において，前記記述項目が音声により識別される情報ページに対するアクセス方法。 
【請求項７】 
請求項１において，前記ＵＲＬにより識別されたページが管理ページである情報ページに対するアクセス方法。 
　
 （請求項１の構成要件を分説し，符号Ａ〜Ｇを当審で付した（以下，「構成要件Ａ」〜「構成要件Ｇ」という。）。以下，「請求項１」「請求項２」・・・「請求項７」に係る発明を「本件訂正発明１」「本件訂正発明２」・・・「本件訂正発明７」という。）
　
第４　審判請求人の主張の概要
　請求人は，特許第３７６２８８２号の特許を無効とする，審判費用は被請求人の負担とする，との審決を求め，平成１９年１０月３１日付け審判請求書と共に甲第１号証〜甲第２４号証を提出した。さらに，平成２０年３月３日付け弁駁書を提出し，訂正が認められたとしても訂正後の特許請求の範囲は訂正前と同様に新規性ないし進歩性を欠き，本件特許の記載には不備があり，訂正にも不備があると主張した。その後，平成２０年５月２０日口頭審理（平成２０年５月２０付け口頭審理陳述要領書を提出）にて陳述し，平成２２年４月１９日付けで上申書と共に資料の提出を行った。なお，口頭審理において特許法第２９条第１項第３号の主張は取り下げられ，当該主張における甲第１号証及び甲第２号証の記載に係る主張は，特許法第２９条第２項の主張に援用されることとなった。請求人の主張する無効理由は，特許法第３６条第６項第２号に規定する要件をみたしておらず，特許法第３６条第４項に規定する要件をみたしておらず，特許法第２９条第２項の規定により特許を受けることができないとするものであって，これらを整理すると請求人の主張は次のようである。
　
１．本件特許は，特許請求の範囲の記載が明確でないので，特許法第３６条第６項第１号及び第２号に規定する要件を満たしていない。 
　
（１）構成要件Ａ，Ｇについて 
　構成要件Ａにおける「情報ページに対するアクセスを提供する方法」と構成要件Ｇの「情報ページに対するアクセス方法」の意味が不明瞭である。 
　「アクセスを提供する方法」とは「クライアントに対して，別の主体が，目的のウェブページへの接続を提供する（接続してあげる）方法」と解される一方，「アクセス方法」とは「クライアントが，目的のウェブページに接続する方法」と解されるから，二つの「方法」は主体が異なる方法であるが，文頭の構成要件Ａにおいて「アクセスを提供する方法」と明確に断定したにもかかわらず，文末の構成要件Ｇでは「アクセス方法」と，（被請求人も自認するとおり）異なる意味に翻って結ばれておりいずれが当該発明の内容か把握できない。　
　この点については「発明の詳細な説明」に明確な記載を見出すことができないので，本件特許発明の「特許請求の範囲」の記載は特許を受けようとする発明の記載が不明瞭である。 
　
（２）構成要件Ｂについて 
　構成要件Ｂにおける「前記クライアントにおいて記述子を提供する段階」の記載は，「記述子を提供する」の技術的な意味，並びに「提供」する主体及びその「提供」先が明確でない。 
　本件発明１の黙示の実施主体としてユーザを念頭に置けば，構成要件Ｂは「ユーザが，クライアントＰＣに記述子を入力する段階」と解釈するのが自然であり，つづく構成要件Ｃの記載に拠れば，前記「記述子」は「提供」の結果として「ディレクトリサーバー」に到った，すなわち「送信」されたと解することも不可能ではない。 
　ところが，「特許請求の範囲」には「クライアントからディレクトリサーバーへ記述子を送信する段階」（あるいは，「ディレクトリサーバーがクライアントから記述子を受信する段階」）の記載が無いため，構成要件Ｃにおいて前記記述子が既に「ディレクトリサーバー」に場所を移していることとの整合が取れず，不合理である。 
　また，被請求人は，本件特許発明は「上記記述子をクライアントが直接的に何処へ『提供』するかなどということは何ら限定していない」と述べているが，限定していないというならば，本件特許は，特許請求の範囲において発明を成立させるに必須の構成要件を欠如しており，発明が不明確である。 
　被請求人は，答弁書に限らず出願審査中から，クライアントは記述子の提供行為の「行為主体」であると主張していたが，答弁書に至って，被請求人は「クライアント」は記述子を提供する「主体」であり，かつ「場所」であるというのである。要するに被請求人は「提供＝ユーザによる記述子の入力行為（クライアントはそれを行う「場所」）」，「提供＝記述子の送信行為（クライアントはそれを行う「主体」）」という２つの解釈を被請求人の都合に合わせて混同している。被請求人自身が混乱するほどに，構成要件Ｂの記載は不明瞭である。 
　
（３）構成要件Ｃ，Ｄについて 
　構成要件Ｃ，Ｄにいう「ディレクトリサーバー」とは具体的に何であるか不明確である。　
　「ディレクトリサーバー」の記載は，「ディレクトリサービスを提供するコンピュータ」ほどの意味合いに理解することが自然であるが，ここにいう「ディレクトリサービス」とはイエローページ・サービスのような一般的ディレクトリサービスを想起してよいのか否か，「発明の詳細な説明に一切の説明がないため不明瞭である。 
　したがって，構成要件Ｃ，Ｄは，動作主体の「ディレクトリサーバー」について具体的でないため，特許を受けようとする発明が明確でなく，かつ明細書においてもその十分な裏付けがなされていない。 
　もっとも，被請求人の答弁が，ディレクトリサーバーとは何かについては当時の技術常識から明らかであるという趣旨であれば，それは首肯できる。「ディレクトリ」ないし「ディレクトリサービス」とは何かについて，出願当時の公知資料たる甲第６号証によれば，「ディレクトリによって保持されている情報は，ディレクトリ情報ベース（ＤＩＢ）と総称され」，「ＤＩＢは，オブジェクトについての情報で構成されている。ＤＩＢは（ディレクトリ）エントリで，各エントリは一つのオブジェクトに関する情報の集合で構成される。各エントリは属性で，各属性は一つのタイプと一つ以上の値で構成される。あるエントリに存在する属性のタイプは，そのエントリが記述するオブジェクトのクラスに依存する。」，「ＤＩＢのエントリは，木構造，つまり節点がエントリであるディレクトリ情報木（ＤＩＴ）にまとめられる。」等と説明される。 
　このような技術常識からすれば，「ディレクトリサーバー」は，ディレクトリ情報ベースを有するサーバー，あるいはディレクトリサービスに用いられるサーバーを意味すると解釈するほかはない。そして，それは，甲第１号証の引用発明に開示されたイエローページ・サービス（これがディレクトリサービスとして当時知られていた）のイエローページ・サーバーと同じサーバーに他ならない。 
　
（４）請求項２−７の記載について 
　請求項２−７の記載は，記載に不備を有する請求項１の従属項であるから，各請求項ともにその記載が不明瞭である。 
　
２．本件特許は，明細書及び図面の記載が明確でないので，特許法第３６条第４項に規定する構成要件を満たしていない。 
　
（１）本件明細書には，クライアントにおいて提供された記述子をどのような手段で翻訳データベースの存在するディレクトリサーバーに送るか又は受け取るか，「“ダイヤル”コマンド」とは何か，「“ダイヤル”コマンド」以外に記述子を入力し送信する方法はあるのか，標準的なプロトコルは利用できるのか，ウェブクライアントでなくディレクトリクライアントから利用できるのかについて説明されていないから，発明の詳細な説明及び図面の記載は当業者が実施可能な程度に発明の内容が開示されているとはいえない。
　
３．特許法第２９条第２項
　本件の請求項１−７に係る発明は，その優先日前日本国内又は外国において頒布された刊行物に記載された発明に基いて，その優先日前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許を受けることができず，本件特許は同法第１２３条第１項第２号の規定により無効とされるべきである。
　
 （１）請求項１について 
　本件特許の請求項１の構成要件Ａ「インターネットよりなるコンピュータネットワークを介したクライアントからサーバーシステムへの情報ページに対するアクセスを提供する方法であって，」について，甲第１号証には，「インターネットの至る所からクライアントがローカル・サーバーにアクセスできるようにする」旨が記載され，「フラグシップ・ホスト上で動作する転送メカニズムが，実際にそのサービスを提供するサーバーにクライアントを接続させる」旨が記載されており，かつ，甲第１号証において「ローカル・サーバーにアクセス」を「サーバーコンピュータが提供する情報サービスにアクセスする」ようにすることは容易であるから，前記構成要件Ａは甲第１号証から当業者が容易に想到し得るものである。 
　本件特許の請求項１の構成要件Ｂ「前記クライアントにおいて記述子を提供する段階と，」について，甲第１号証には，「サービスを受けたいクライアントは，サービス名およびサーバーが持つべき任意の属性を指定して，イエローページ・サービスにサーバーのアドレスを問い合わせる。」旨が記載されているから，前記構成要件Ｂは甲第１号証から当業者が容易に想到し得るものである。 
　本件特許の請求項１の構成要件Ｃ「ディレクトリサーバーが，前記記述子を前記ディレクトリサーバーに存在する翻訳データベースを用いてＵＲＬにマッピングする段階と，」について，甲第１号証には，「各イエローページ・サーバーには，システム内で使用できるサービスについての情報のデータベースが関連付けられる。データベースには，各サービスとそのサービスを提供するサーバーのセットとがバインディングされて格納される。」旨が記載され，「サービス名をサーバーのアドレスにマッピングするイエローページ・サービスを紹介する。」旨が記載されており，かつ，甲第５号証にはイエローページとはディレクトリ情報群であることが記載され，甲第２号証には仮想的なディレクトリを物理的なファイル・システムにおけるパスへと変換するコマンドとしてマッピングが記載され，甲第３号証には「インターネット上の分散したリソースに対して，統一的な名前の付け方を決めてユーザー・インターフェイスを向上させる試みがあります。それがＵＲＬです。」と記載されているから，前記構成要件Ｃは甲第１号証及び甲第２号証に記載された発明，並びに甲第３号証及び甲第５号証に記載された周知技術から当業者が容易に想到し得るものである。 
　本件特許の請求項１の構成要件Ｄ「前記ディレクトリサーバーが，ＲＥＤＩＲＥＣＴコマンド中の前記ＵＲＬを前記クライアントに返送する段階と，」について，甲第１号証には，「イエローページ・サービスは，クライアントの要求を満たす一或いは二以上のサーバーのアドレスを返送する」旨が記載され，「対照的に，プロトコルは，フラッグシップ・ホストがクライアントに対して，そのパケットをリダイレクトする必要があると知らせるように修正できるであろう。」旨が記載されており，かつ，甲第２号証には，「Ｒｅｄｉｒｅｃｔに指定したパターンにマッチした場合は，指定したＵＲＬにリクエストがそのままフォワードされる。」と記載されているから，前記構成要件Ｄは甲第１号証及び甲第２号証から当業者が容易に想到し得るものである。 
　本件特許の請求項１の構成要件Ｅ「前記クライアントに前記ＵＲＬを用いて情報を要求させる段階と，」について，甲第１号証には「対照的に，プロトコルは，フラッグシップ・ホストがクライアントに対して，そのパケットをリダイレクトする必要があると知らせるように修正できるであろう。」旨が記載され，かつ，甲第３号証には「インターネット上の分散したリソースに対して，統一的な名前の付け方を決めてユーザー・インターフェイスを向上させる試みがあります。それがＵＲＬです。」と記載されているように，情報ページの存在を特定するものがＵＲＬであることは周知技術であるから，前記構成要件Ｅは甲第１号証に記載された発明，及び前記周知技術から当業者が容易に想到し得るものである。 
 　本件特許の請求項１の構成要件Ｆ「前記ＵＲＬにより識別されたページを前記クライアント側で表示する段階と」について，甲第１号証には「インターネットの至る所からクライアントがローカル・サーバーにアクセスできるようにする」旨が記載され，「フラグシップ・ホスト上で動作する転送メカニズムが，実際にそのサービスを提供するサーバーにクライアントを接続させる」旨が記載されており，かつ，甲第４号証にあるようにアクセス先のサーバーにＵＲＬで指定される情報ページが備わることは周知技術であるから，前記構成要件Ｆは甲第１号証に記載された発明，及び前記周知技術から当業者が容易に想到し得るものである。 
　本件特許の請求項１の構成要件Ｇ「を備えた情報ページに対するアクセス方法。」について，甲第１号証には「クライアントは，そのホスト上でサーバーを使用できるかのように，フラグシップ・ホストに接続する。」旨が記載されており，かつ，甲第４号証にあるようにアクセス先のサーバーに情報ページが備わることは周知技術であるから，前記構成要件Ｇは甲第１号証に記載された発明，及び前記周知技術から当業者が容易に想到し得るものである。 
　したがって，請求項１に係る発明は，甲第１，２号証に開示された技術事項を適宜選択し或いは寄集めたにすぎず，またこれらの公知技術を組合せることについては動機付けとなり得る記載が多数認められる一方で技術的な阻害要因は一切なく，しかも公知技術と比較しても予想の範囲を超える有利な効果も認められないことから，結局，出願時の技術水準に基づき当業者をして容易に想到できたものである。 
　
（２）請求項２について 
　本件特許の請求項２の構成要件「前記記述子が電話番号を備えた」について，甲第８号証には，電話番号を翻訳データベースを用いてアクセス先のアドレスにマッピングし，該アドレスをＲＥＤＩＲＥＣＴコマンドを用いてクライアントに返送する旨が記載され，甲第９号証には，「ＦＡＸをある人に送信するためにはその人の電話番号を知るだけでよい」旨が記載され，甲第５号証には，ディレクトリサービスにおける属性の例示として電話番号が記載されており，記述子として電話番号は周知技術であるから，請求項２に係る発明は甲第１号証及び甲第２号証に記載された発明，並びに前記周知技術から当業者が容易に想到し得るものである。 
　
（３）請求項３について 
 　本件特許の請求項３の構成要件「前記記述子が記述項目を備えた」について，「記述項目」とは，「記述的又は説明的な言葉ないしは用語」ほどの意味であると理解され，甲第５号証にあるように記述項目を記述してサービスを問い合わせることは周知技術であるから，請求項３に係る発明は甲第１号証及び甲第２号証に記載された発明，並びに前記周知技術から当業者が容易に想到し得るものである。 
　
（４）請求項４について 
 　本件特許の請求項４の構成要件「前記記述項目が会社名を含む」について，甲第６号証には識別子として組織が記載され，甲第１３号証には会社名を記述子として情報検索を行う旨が記載され，甲第５号証には属性の例示の中に組織名＝会社名が記載されており，記述項目として会社名は周知技術であるから，請求項４に係る発明は甲第１号証及び甲第２号証に記載された発明，並びに前記周知技術から当業者が容易に想到し得るものである。
　
（５）請求項５について 
　本件特許の請求項５の構成要件「前記記述項目が製品名を含む」について，甲第６号証には識別子として「一般名＝レーザプリンタ」や「一般名＝ファクス端末」が記載され，甲第１３号証には製品カテゴリー名を記述子として情報検索を行う旨が記載されており，記述項目として製品名は周知技術であるから，請求項５に係る発明は甲第１号証及び甲第２号証に記載された発明，並びに前記周知技術から当業者が容易に想到し得るものである。
　
（６）請求項６について 
　本件特許の請求項６の構成要件「前記記述項目が音声により識別される」について，甲第１４号証には音声認識機構（ｓｏｕｎｄｅｘ　ａｎｄ　ｐｈｏｎｉｘ）について記載し，甲第１５号証には音声検索機能について記載しており，記述項目が音声により識別されることは周知技術であるから，請求項６に係る発明は甲第１号証及び甲第２号証に記載された発明，並びに前記周知技術から当業者が容易に想到し得るものである。 
　
（７）請求項７について 
　本件特許の請求項７の構成要件「前記ＵＲＬにより識別されたページが管理ページである」について，「管理ページ」とはクライアントからのアクセスが制御されたページであると解釈でき，一方，甲第２号証には，サーバーへのアクセス管理の方法について記載し，甲第６号証には，ユーザ認証を行うことについて記載し，甲第５号証には「認証」「承認」などのアクセス管理について記載しており，ＵＲＬにより識別されたページが管理ページであることは周知技術であるから，請求項７に係る発明は甲第１号証及び甲第２号証に記載された発明，並びに前記周知技術から当業者が容易に想到し得るものである。 
　
４．証拠方法
甲第一号証の一　　　　COMPUTER COMMUNICATION REVIEW １７巻５号
　　　　　　　　　　　「A Yellow-Page Service for a Local Area
　　　　　　　　　　　 Network」(1988年出版)
甲第一号証の二　　　　甲第一号証の一の翻訳文
甲第二号証　　　　　　『UNIX USER』Vol.3 No.12(1994.12.1発行)
甲第三号証　　　　　　『UNIXMAGAZINE』1994 2月号
甲第四号証　　　　　　『Internet User』Vol.1 No.2(1995.2.1発行)
甲第五号証　　　　　　CCITT(BLUE BOOK)第２巻２−６
　　　　　　　　　　　Ｆシリーズ勧告「勧告F.500」　
甲第六号証　　　　　　CCITT（BLUE B00K）第VIII巻　VIII−6，8
　　　　　　　　　　　Xシリーズ勧告「勧告X．500」及び「勧告X．518」
甲第七号証　　　　　　ＷＩＤＥプロジェクト１９９２年度研究報告書
甲第八号証　　　　　　特表平８−５００７０８号公報
甲第九号証　　　　　　特開平６−８５９２４号公報
甲第十号証の一　　　　Configuration File  of  CERN h t t pd
甲第十号証の二　　　　甲第十号証の一の翻訳文
甲第十一号証の一　　　Rules　In The　Configuration  File
甲第十一号証の二　　　甲第十一号証の一の翻訳文
甲第十二号証の一　　　Directory Browsing
甲第十二号証の二　　　甲第十二号証の一の翻訳文
甲第十三号証の一　　　Newsbytes Nov 9, 1994 (Menefee)
甲第十三号証の二　　　甲第十三号証の一の抄訳文
甲第十四号証の一　　　Digital Systems Journal　Sept-Oct 1994 (Buh1e)
甲第十四号証の二　　　甲第十四号証の一の抄訳文
甲第十五号証の一　　　X．500 Implementation Description Page
甲第十五号証の二　　　甲第十五号証の一の翻訳文
甲第十六号証の一　　　米国特許第５２９７２４９号公報（BERNSTEIN）
甲第十六号証の二　　　甲第十六号証の一の抄訳文
甲第十七号証　　　　　ＷＩＤＥプロジェクト１９８９年度研究報告書
甲第十八号証　　　　　米国特許出願第０８／４８６７９７号書面
甲第十九号証の一　　　米国特許出願第０８／４８６７９７号審査経過
甲第十九号証の二　　　甲第十九号証の一の翻訳文
甲第二〇号証　　　　　米国特許第５８１２７７６号公報
甲第二一号証の一　　　米国特許第５５３０８５２号公報(Meske)
甲第二一号証の二　　　甲第二一号証の一の抄訳文
甲第二二号証の一　　　ｍａｘ．５００ウェブサイト出力
甲第二二号証の二　　　甲第二二号証の一の翻訳文
甲第二三号証の一　　　RFC１６３２
甲第二三号証の二　　　甲第二三号証の一の翻訳文
甲第二四号証　　　　　本件出願に対する拒絶理由通知書
　
第５　被請求人の主張の概要
　被請求人の主張の概要は次のとおりである。 
　
１．本件訂正発明１−７に，特許法第３６条第６項第１号及び第２号の規定に違反する不備は存在しない。 
　
（１）構成要件Ａ，Ｇについて 
　構成要件Ａとして「アクセスを提供する方法」と規定するとともに，構成要件Ｇとして「アクセス方法」と規定することにより，本件特許発明の特徴が，クライアントがＵＲＬとは異なる数字あるいは言葉である記述子を提供した場合（構成要件Ｂ）であっても，構成要件ＣないしＥによって具体的に記載される「アクセスを提供する方法」（構成要件Ａ）によって，該クライアントが目的の情報ページ（ウェブページ）にアクセスすることを可能にする方法，すなわち「情報ページに対するアクセス方法」（構成要件Ｇ）であることが，特許請求の範囲として明確にされている。両者の規定を区別した理由は，２つの「方法」が性質の異なる段階であることを明確にするためのものである。 
　すなわち，構成要件Ａの「アクセスを提供する方法」とは，本件発明１の実施主体が「アクセスを提供する」ものであり，その具体的構成は以下に続く構成要件ＢないしＧによって実現されるものであり，これに対して，構成要件Ｇの「アクセス方法」は，構成要件Ａの「アクセスを提供」を実現するために，発明の構成要件としてハードウェアであるクライアントがアクセスすることを要することを意味するものである。 
　換言すると，本件特許の特許請求の範囲の記載は，発明の実施行為自体は究極的に発明実施主体である人によって行われる（構成要件Ａ）ことをクレームのおいて書きで明らかとしつつ，そのための各構成要件は様々なハードウェア（クライアント，サーバー等）によって実現されていくことを明確にした（構成要件ＢないしＧ）ものである。 
　
（２）構成要件Ｂについて 
　構成要件Ｂにおける「クライアントにおいて記述子を提供する」とは，「記述子」が，クライアントから送信されることを意味し，上記「記述子」のクライアントへの入力方法それ自体を何ら規定するものではないことが明瞭であるから，何ら記載不明瞭の問題は存しない。請求項１においては，「記述子」について，これを「提供」するハードウェアとしての主体がクライアントであることを明確に規定されている。 
　特許法においては，物の発明に関する実施行為の定義として，「譲渡等（譲渡及び貸渡しをいい，その物がプログラム等である場合には，電気通信回線を通じた提供を含む。以下同じ。）」（特許法第２条第３項第１号）と規定されているように特許法を始めとする知的財産法自体が，インターネットにおける「提供」という用語が送信行為を意味することを当然の理解としている。 
　また，上記記述子をクライアントが直接的に何処へ「提供」するかなどということは何ら限定していない。 
　したがって，本件特許請求の範囲の記載上，構成要件Ｂが上記のような意義を有することが明確であり，何ら記載不明瞭の問題を生じるものではない。 
　
　また，本件特許明細書の発明の詳細な説明の記載においても，「本発明は，クライアントからサーバーへのネットワークを介したサービス要求を処理する方法に関する。」（【０００１】【発明の属する技術分野】）として本件特許発明が「クライアントから」の「サービス要求を処理する方法」であることを明記しており，構成要件Ｂが「クライアント」からの「記述子」送信行為であることを明確としている。 
　本件特許明細書の実施例では，「本発明の一構成では，商業者のサービスにアクセスするためにユーザが従来の電話番号，またはその他の識別子を利用できるようにする便が設けられている。…（中略）…好ましい実施形態では，図６に示されるように，ウェブブラウザクライアント６０１がユーザからの電話番号を受理するため“ダイヤル”アイコン上をクリックし，キーボードを介して電話番号を入力することのような“ダイヤル”コマンドを提供する。ブラウザは次いでＮＵＭＢＥＲがユーザにより指定された電話番号，またはその他の識別子である，書式“ｈｔｔｐ：／／ｄｉｒｅｃｔｏｒｙ．ｎｅｔ／ＮＵＭＢＥＲ”のＵＲＬを構成する。ブラウザは次いでこのＵＲＬにより指定されたドキュメントのＧＥＴを行い，ディレクトリサーバー６０２に連絡し，メッセージ１で要求されたＮＵＭＢＥＲを送信する。」（段落【００４１】）とされているところ，請求項１の「クライアントにおいて記述子を提供する」との構成要件Ｂは，「ブラウザは次いでこのＵＲＬにより指定されたドキュメントのＧＥＴを行い，ディレクトリサーバー６０２に連絡し，メッセージ１で要求されたＮＵＭＢＥＲを送信する。」との記載に基づいて特許請求の範囲に規定されたものである。 
　このように，実施例中の上記記載も，構成要件Ｂにおける「記述子を提供する」との用語が，クライアントからの「記述子」送信行為を意味することを明確にしている。 
　さらに，本件特許出願人は，乙第２号証（平成１７年６月２０日付け意見書）で「すなわち，記述子を提供する段階はクライアントが行い」との意見を述べて，同日付の手続補正書において，請求項１を現在のとおり「前記クライアントにおいて記述子を提供する段階へ」と補正し，その結果特許が付与されている。 
　
（３）構成要件Ｃ，Ｄについて 
　審判請求人は，「構成要件Ｃ，Ｄにいう『ディレクトリサーバー』とは具体的に何であるか不明確である。」と主張するが，構成要件Ｃは，クライアントから送信された「記述子」を受信した「ディレクトリサーバー」がその翻訳データベースを用いて該「記述子」に対応するＵＲＬを検出することを意味するに留まるものである。また，「ディレクトリサーバー」は，該ＵＲＬをＲＥＤＩＲＥＣＴコマンドに含めて該クライアントに返送するものである（構成要件Ｄ）。このように，本件特許発明において，「ディレクトリサーバー」は，上記「記述子」を「翻訳データベースを用いてＵＲＬにマッピング」し，「ＲＥＤＩＲＥＣＴコマンド中の前記ＵＲＬを前記クライアントに返送する」サーバーであることを要するとともに，これで足りるものであり，ＤＮＳとしての機能を併有してもよく，何ら記載不明瞭の問題は存しない。 
　
２．本件訂正発明１−７に，特許法第３６条第４項の規定に違反する不備は存在しない。　
（１）本件特許発明の特徴は，「本願発明が適用するようなインターネットの技術分野では，ウェブサイトヘアクセスする際に，長く複雑なＵＲＬを入力する必要があるが，本願発明では，このような長く複雑なＵＲＬに代えて，このＵＲＬに対応して誰でも簡単かつ容易に入力できる電話番号，会社名，製品名などを入力するだけで，目標とするＵＲＬのウェブサイトヘアクセスできるようにしたもの」（乙第２号証（平成１７年６月２０日付け意見書），乙第３号証（同年１２月５日付け意見書））である。そして，かかる特徴及び効果を奏するものとして特許されたものである。 
　したがって，「標準的なプロトコルは利用することができるのか」，「ウェブクライアントでなくディレクトリクライアントからは利用できるのか」，「できるとすれば如何なる態様によるのか」といった事項は，当業者が実際に本件特許発明を実施するにあたって適宜設計すべき事項に過ぎず，本件特許明細書にそれらについての詳細な説明が仮にないとしても何ら実施不能の問題を生じるような事項ではない。発明の実施の形態について，特許出願人が最良と思うものを記載するという点は，特許法第３６条第４項により求められている要件ではなく，特許出願人が最良と思うものを記載していないことが明らかであっても，拒絶理由等にはならない。 
　以上のとおりであるから，本件特許明細書の発明の詳細な説明は，特許法第３６条第４項が定める要件を十分満たしている。 
　
３．本件訂正発明１−７は，甲第１号証及び甲第２号証に記載された発明に基づいて，当業者が容易に発明をすることができたものではない。 
　
（１）請求項１について，本件特許は，ＴＣＰ／ＩＰ上で作動するＨＴＴＰのＵＲＬ指定とユーザに馴染みのある会社名等の言葉（ないし数字）である「記述子」とを対応させ，当該「記述子」を与えるだけで，自動的に目標とする情報サイトへアクセスできるようにしたものである。甲第１号証の発明は，クライアントが受けたいサービスの名前や属性条件を指定し，該当サービスを提供可能なサーバーの検索結果を返答させるものである。 
　
　本件特許の「記述子」とは，電話番号，会社名，製品名等のユーザーに理解可能なＵＲＬとは異なる数字あるいは言葉であり，かつ，当該「記述子」に対応し，目標情報ページを識別する特定かつ唯一の「ＵＲＬ」へとマッピングされる。甲第１号証の発明はクライアントがサーバーに対して求めるサービスの内容やその質といった条件を指定するものであり，特定かつ唯一のサーバーへと対応付けられるものではない。よって，甲第１号証の「サービス名およびサーバーが持つべき任意の属性」は，本件特許の「記述子」に相当しない。 
　
　本件特許の「翻訳データベース」は，人間が理解する電話番号，会社名，製品名等の「記述子」をコンピュータネットワーク上の特定の資源（サーバーなど）を指し示す「ＵＲＬ」へと翻訳を行うものである。甲第１号証の「データベース」は，クライアントによって指定された条件をみたすサーバーを検索するものにすぎない。 
　
　本件特許の「ＵＲＬ」は「記述子」に対応する特定かつ唯一のものであって目標とする「情報ページ」を識別するものである。甲第１号証は「フラグシップ・ホスト」の「アドレス」が「クライアント」に返されるものである。 
　
　本件特許の「ＲＥＤＩＲＥＣＴコマンド」はＲＥＤＩＲＥＣＴコマンド中の特定かつ唯一のＵＲＬがクライアントへと返信されることによって自動的に，クライアントをして特定かつ唯一のＵＲＬに対応するウエッブへと情報要求させるものである。甲第１号証において「リダイレクト」によりクライアントがどのような動作を要求されるか開示も示唆もない。また「イエローページ・サービスは，クライアントの要求を満たす一或いは二以上のサーバーのアドレスを返送する」と，「対照的に，プロトコルは，フラグシップ・ホストがクライアントに対して，そのパケットをサーバー・ホストにリダイレクトする必要があると知らせるように修正できる」とを，同時あるいは連続して行うよう結びつけることについて開示も示唆もない。 
　
（２）請求項２−７に係る発明は，特許性を有する請求項１の従属項であるから，同様に特許性を有する。 
　
４．証拠方法
乙第１号証　　　　本件特許明細書（特許第３７６２８８２号）
乙第２号証　　　　本件出願の平成１７年６月２０付意見書
乙第３号証　　　　本件出願の平成１７年１２月５日付意見書
　
第６　甲１号証について
　甲第１号証（Ｌａｒｒｙ　Ｌ．　Ｐｅｔｅｒｓｏｎ，“Ａ　Ｙｅｌｌｏｗ−Ｐａｇｅｓ　Ｓｅｒｖｉｃｅ　ｆｏｒ　ａ　Ｌｏｃａｌ−Ａｒｅａ　Ｎｅｔｗｏｒｋ”，ＣＯＭＰＵＴＥＲ　ＣＯＭＭＵＮＩＣＡＴＩＯＮ　ＲＥＶＩＥＷ，Ｖｏｌｕｍｅ　１７，Ｎｕｍｂｅｒ　５，Ｓｐｅｃｉａｌ　Ｉｓｓｕｅ，ＡＣＭ　Ｐｒｅｓｓ，１９８８，ｐ．２３５−２４２）には，次の事項が記載されている。（以下，甲第１号証の１の翻訳文を併記する。）
　
（１）第２３５頁左欄第７−１２行「In addition to describing the implementation of the yellow-pages service within a local-area network, we show how the service can be integrated with the available internet communication protocols to enable clients from throughout the internet to access local servers.」（翻訳文「イエローページ・サービスのローカルエリア・ネットワーク内での実施の説明だけでなく，インターネットの至る所からクライアントがローカル・サーバーにアクセスできるようにするために，本サービスが，使用可能なインターネット通信プロトコルとどのように統合できるかを示す。」） 
　
（２）第２３５頁左欄第１４−１６行「This paper describes a yellow-pages service that maps the name of a service into the address of a server willing to provide the service.」（翻訳文「この論文では，サービスを提供しようとするサーバーのアドレスにサービス名をマッピングするイエローページ・サービスについて説明する。」） 
　
（３）第２３５頁左欄第２８行−右欄第４行「A client that wishes to engage a service queries the yellow-pages service for the address of a server, specifying the name of the service and any attributes the server should possess. The yellow-pages service returns the address of one or more servers that satisfy the client's requirements.」（翻訳文「サービスを受けたいクライアントは，サービス名およびサーバーが持つべき任意の属性を指定して，イエローページ・サービスにサーバーのアドレスを問い合わせる。イエローページ・サービスは，クライアントの要求を満たす一或いは二以上のサーバーのアドレスを返送する。」） 
　
（４）第２３５頁右欄第１０−１４行「Clients connect to the flagship host as though the server is available on that host. A forwarding mechanism running on the flagship host then patches the client through to an actual server that provides the service.」（翻訳文「クライアントは，そのホスト上でサーバーを使用できるかのように，フラグシップ・ホストに接続する。次に，フラグシップ・ホスト上で動作する転送メカニズムが，実際にそのサービスを提供するサーバーにクライアントを接続させる。」） 
　
（５）第２３５頁右欄第３２−３４行「A set of servers implement the yellow-pages service. Each server maintains a database of information about the available services and servers.」（翻訳文「サーバーのセットが，イエローページ・サービスを実施する。各サーバーは，使用可能なサービスおよびサーバーに関する情報のデータベースを維持する。」） 
　
（６）第２３６頁左欄第２−３行，同欄第１１−１３行「An attribute is a sytactic object that denotes a property or characteristic of a server.」「Clients submit a set of attributes when querying the yellow-pages for a server that provides a particular service.」（翻訳文「属性は，サーバーのプロパティまたは特徴を示す統語的要素である。」「クライアントは，ある特定のサービスを提供するサーバーについてイエローページに問い合わせる際，属性のセットを送信する。」） 
　
（７）第２３６頁左欄第５３−５６行「Associated with each yellow-pages server is a database of information about the services available in the system. The database contains bindings of each service to a set of servers that provide the service.」（翻訳文「各イエローページ・サーバーには，システム内で使用できるサービスについての情報のデータベースが関連付けられる。データベースには，各サービスとそのサービスを提供するサーバーのセットとが結びつけて格納される。」） 
　
（８）第２３７頁左欄第２−４行「Clients query the yellow-pages service for the address of one or more servers that provide a given service with the operation」（翻訳文「クライアントは，以下のオペレーションによって，イエローページ・サービスに対し，ある所定のサービスを提供する一或いは二以上のサーバーのアドレスを問い合わせる。」） 
　
（９）第２３８頁右欄第２０−２６行「As another example, suppose the client wishes to retrieve the address of the printer based on its location: e.g.,the printer in Rick's office. In the case, the client invokes the lookup() operation with the mandatory attibute loc=rick. Any number of optional attributes are ignored because the mandatory attribute loc=rick selects a single server.」（翻訳文「別の例として，クライアントが場所，例えば「Rickのオフィスのプリンタ」などに基づいてプリンタのアドレスを取得したいとする。この場合，クライアントは，必須属性をloc=rickとしてlookup()オペレーションを要求する。必須属性loc=rickによって唯一のサーバーが選択されるので，オプション属性がいくつあってもすべて無視される。」）
　
（１０）第２３９頁右欄第２４−２８行「The system advertizes the flagship as offering a set of services to Internet clients by registering a set of resource records - potentially one for each service - with the domain naming system.」（翻訳文「システムは，ドメイン名システム（domain naming system）によって，一つのセットのリソース・レコード−サービスごとにひとつある可能性がある−を登録することによって，フラグシップがサービスのセットをインターネット・クライアントに提供するものとして広告する。」） 
　
（１１）第２３９頁右欄第３０行−第２４０頁左欄第１４行「A client consults the domain name server to learn the address of a host at the system that offers a particular service and the address of the flagship host is returned. The client then contacts the server by sending one or more packets addressed to the well-known port on the flagship host. The flagship host, in turn, forwards the packets to a server within the system. Thus, the forwarding mechanism is analogous to the strategy of accessing a server at well-known port: The flagship serves as the well-known host for the system. Consider how the forwarding mechanism is implemented within TCP in more detail. The TCP module running on the flagship host is modified to include the forwarding mechanism. Associated with the forwarding mechanism is a table that binds well-known ports to the address of servers.」（翻訳文「クライアントは，システムにおいて特定のサービスを提供するホストのアドレスを取得するためにドメイン名サーバーに問い合わせ，フラグシップ・ホストのアドレスが返される。その後，クライアントは，フラグシップ・ホスト上のウェルノウンポート宛に一或いは二以上のパケットを送信することによって，サーバーに接続する。すると，フラグシップ・ホストは，そのパケットをシステム内のサーバーに転送する。このように，転送メカニズムは，ウェルノウンポートにおいてサーバーにアクセスする戦略と類似している。フラグシップは，システムに対して，「ウェルノウンホスト」の役割を果たす。転送メカニズムがＴＣＰ内でどのように実施されるかを更に詳細に検討する。フラグシップ・ホスト上で動作するＴＣＰモジュールが，転送メカニズムを含むように変更される。転送メカニズムには，ウェルノウンポートをサーバーのアドレスに結びつけるテーブルが関連付けられる。」） 
　
 （１２）第２４０頁左欄第１７−２４行「When a packet arrives at the TCP module addressed for some port, the forwarding mechanism is consulted to see if forwarding is to take place for that port; i.e., if there is an entry in the table. If the packet is from a new client, the forward server randomly selects one of the available servers and forwards the packet's destination address to the server's address and resends packet.」（翻訳文「あるポート宛のパケットがＴＣＰモジュールに到着すると，そのポートへの転送が行われるべきか，すなわち，テーブルにエントリが存在するかについて，転送メカニズムが問い合わせられる。パケットが新規クライアントからの場合，転送サーバーは，使用可能なサーバーをランダムにひとつ選択し，パケットをそのサーバーに転送する。すなわち，転送メカニズムは，パケットの宛先のアドレスをそのサーバーのアドレスに設定し，パケットを再送信する。」） 
　
（１３）第２４０頁左欄第２９−３５行「The TCP module runnning on teh server host is aware that forwarding is taking place and sends all reply messages directly to the client. TCP on the server host sets the packet's source address to the client as though it is still communicating with the flagship host.The client,therefore, is never aware that the forwarding is taking place」（翻訳文「サーバー・ホスト上で動作するTCPモジュールは，転送が行われていることを認識し，すべての応答メッセージを直接クライアントに送信する。サーバー・ホスト上のTCPは，パケットのソース・アドレスをフラッグシップ・ホストのアドレスに設定し，それによって，クライアントには，クライアントがまだフラッグシップ・ホストと通信しているかのように見える。従って，転送が行われていることをクライアントが認識することはない。）
　
（１４）第２４０頁右欄第１２−２５行「A load manager executing on the flagship host is responsible for binding each well-known port to a set of servers in the forwarding mechanism's table The load manager's objective is to distribute remote work over the local servers so as to balance their load In the case of generally available services, such as the mail service, the manager becomes a client of the yellow-pages service by periodically querying for all processor serviers with a load under a certain threshold. The manager then updates the forwarding mechanism's table accordingly. Note that becauze the forwarding mechanism is embedded in TCP remote client are not able to request servers that satisfy a particular set of attributea; only the load manager is a client of the yellow-pagea service.」（翻訳文「フラッグシップ・ホスト上で動作するロード・マネージャは，転送メカニズム・テーブル内のウェルノウンポートのそれぞれをサーバーのセットにバインディングする。ロード・マネージャの目的は，ローカル・サーバーの負荷のバランスをとるために，遠隔作業をローカル・サーバーに分配することである。メール・サービスさどの，一般的に使用可能なサービスの場合，負荷がある閾値以下のすべてのプロセッサ・サーバーを定期的に問い合わせることによって，マネージャは，イエローページ・サービスのクライアントとなる。そして，マネージャは，転送メカニズムのテーブルを適宜更新する。ただし，転送メカニズムは，TCPに組み込まれているので，遠隔クライアントは，特定の属性のセットを満足するサーバーを要求することはできず，ロード・マネージャのみが，イエローページ・サービスのクライアントとなる。）
　
（１５）第２４１頁右欄第４５−５１行「The forwarding mechanism acts as an intermediary between the client and server. This has the advantage of not requiring any changes to the transport protocol because the client is shielded from indirection. In contrast, the protocol could be modified such that the flagship host informs the client that it should redirect its packets to the server host.」（翻訳文「転送メカニズムはクライアントとサーバー間の仲介人の機能を果たす。これは，クライアントが間接参照から守られているため，トランスポートプロトコルに対するあらゆる変更を要求しないという優位点を有する。対照的に，プロトコルは，フラッグシップ・ホストがクライアントに対して，そのパケットをサーバー・ホストにリダイレクトする必要があると知らせるように修正できるであろう。」） 
　
　以上から，甲第１号証には次の発明が記載されている。
「インターネットの至る所からクライアントがローカル・サーバーにアクセスする方法であって，サーバーのセットが，イエローページ・サービスを実施し，各サーバーは，使用可能なサービスおよびサーバーに関する情報のデータベースを維持し，各イエローページ・サーバーには，システム内で使用できるサービスについての情報のデータベースが関連付けられ，データベースには，各サービスとそのサービスを提供するサーバーのセットとが結びつけて格納され， 
　クライアントは，サービス名およびサーバーが持つべき任意の属性を指定して，イエローページ・サービスにサーバーのアドレスを問い合わせ， 
　イエローページ・サービスは，サービス名を，サービスを提供しようとするサーバーのアドレスにマッピングし， 
　イエローページ・サービスは，クライアントの要求を満たす一或いは二以上のサーバーのアドレスを返送し， 
　転送メカニズムでは，クライアントは，フラグシップ・ホスト上のウェルノウンポート宛に一或いは二以上のパケットを送信することによって，サーバーに接続し，フラグシップ・ホストは，そのパケットをシステム内のサーバーに転送し，
　サーバー・ホスト上で動作するTCPモジュールは，転送が行われていることを認識し，サーバー・ホスト上のTCPは，パケットのソース・アドレスをフラッグシップ・ホストのアドレスに設定し，すべての応答メッセージを直接クライアントに送信し，
　転送メカニズムと対照的に，フラグシップ・ホストがクライアントに対して，そのパケットをサーバー・ホストにリダイレクトする必要があると知らせるように修正できる， 
クライアントがローカル・サーバーにアクセスする方法。」
　
第７　当審の判断
　
１．特許法第３６条第６項第１号及び第２号について
（１）構成要件Ａ，Ｇについて 
　審判請求人は，「アクセスを提供する方法」とは「クライアントに対して，別の主体が，目的のウェブページへの接続を提供する（接続してあげる）方法」と解される一方，「アクセス方法」とは「クライアントが，目的のウェブページに接続する方法」と解されるから，二つの「方法」は主体が異なる方法であるが，文頭の構成要件Ａにおいて「アクセスを提供する方法」と明確に断定したにもかかわらず，文末の構成要件Ｇでは「アクセス方法」と，（被請求人も自認するとおり）異なる意味に翻って結ばれておりいずれが当該発明の内容か把握できないと主張している。 
　しかし，「アクセス」が，構成要件Ａの「インターネットよりなるコンピュータネットワークを介したクライアント」による「サーバーシステムヘの情報ページ」に対するものであることは本件訂正発明１の自体の記載から明らかであり，本件訂正発明１がそのような「アクセス」方法を提供する発明であることも明らかである。そして提供されるアクセス方法は構成要件Ｂ〜Ｆの各段階を備えており，これら各段階の記載から，各段階の処理はディレクトリサーバー側で行われることが想定されていることは明らかである。
　また，本件明細書の段落【００４１】〜【００４５】には次の記載がある。
　
【００４１】
本発明の一構成では，商業者のサービスにアクセスするためにユーザが従来の電話番号，またはその他の識別子を利用できるようにする便が設けられている。これらの商業者サービスはＳＩＤを用いて任意に保護され得る。好ましい実施形態では，図６に示されるように，ウェブブラウザクライアント６０１がユーザからの電話番号を受理するため“ダイヤル”アイコン上をクリックし，キーボードを介して電話番号を入力することのような“ダイヤル”コマンドを提供する。ブラウザは次いでＮＵＭＢＥＲがユーザにより指定された電話番号，またはその他の識別子である，書式“ｈｔｔｐ：／／ｄｉｒｅｃｔｏｒｙ．ｎｅｔ／ＮＵＭＢＥＲ”のＵＲＬを構成する。ブラウザは次いでこのＵＲＬにより指定されたドキュメントのＧＥＴを行い，ディレクトリサーバー６０２に連絡し，メッセージ１で要求されたＮＵＭＢＥＲを送信する。
【００４２】
別の実施形態では，従来のブラウザを備えた形で，クライアント６０１が“ダイヤル”コマンドの場所に電話番号，またはその他の識別子を入れることを促すディレクトリサーバー６０２により提供された書式ページを用いる。メッセージ１はこの書式ページにより指定されたＵＲＬに対するＰＯＳＴメッセージである。
【００４３】
一旦ＮＵＭＢＥＲがディレクトリサーバー６０２により受信されると，ディレクトリサーバーはデータベース６０４を用いて，ＮＵＭＢＥＲに対応するサービスを実施する商業サーバーおよびドキュメントを記述する目標ＵＲＬにＮＵＭＢＥＲを翻訳する。この翻訳は番号の句読法を無視する可能性があり，従って埋め込まれた括弧またはダッシュは意味を持たない。
【００４４】
別の実施形態では，数字以外の識別子を設けることができる。例えば，ユーザは会社名または製品名を不正確なつづりで記入することがある。このような場合“soundex ”または他の音声マッピングが同じ目標ＵＲＬに対するマップと類似して響く語を許容するため用いることができる。また，製品名または内線と組み合わせた電話番号のような複数の識別子も使用可能である。
【００４５】
メッセージ２では，ディレクトリサーバー６０２がＲＥＤＩＲＥＣＴをクライアント６０１に送信し，これには，データベース６０４から演算されたＮＵＭＢＥＲに対する目標ＵＲＬが記述されている。クライアントブラウザ６０１は続いて自動的にメッセージ３を送信し，このＵＲＬのコンテンツをＧＥＴする。商業者サーバー６０３はメッセージ４におけるこの情報を返送する。サーバー６０２はウェブページをクライアントに返送して，要求されたドキュメントに対して適切なリンクを提供する。しかしながら，サーバー６０２が最終的なＵＲＬに対する翻訳を行い，ページよりはむしろＲＥＤＩＲＥＣＴをクライアント６０１に送信するため，メッセージ４のドキュメントは最初のダイヤル入力以上のユーザの行為なしで入手される。
　
　段落【００４１】の「商業者のサービスにアクセスするためにユーザが従来の電話番号，またはその他の識別子を利用できるようにする便が設けられている」こと，段落【００４３】の「一旦ＮＵＭＢＥＲがディレクトリサーバー６０２により受信されると，ディレクトリサーバーはデータベース６０４を用いて，ＮＵＭＢＥＲに対応するサービスを実施する商業サーバーおよびドキュメントを記述する目標ＵＲＬにＮＵＭＢＥＲを翻訳する。」こと，段落【００４５】の「ディレクトリサーバー６０２がＲＥＤＩＲＥＣＴをクライアント６０１に送信し，これには，データベース６０４から演算されたＮＵＭＢＥＲに対する目標ＵＲＬが記述されている。クライアントブラウザ６０１は続いて自動的にメッセージ３を送信し，このＵＲＬのコンテンツをＧＥＴする。」ことから，ユーザが商業者のサービスにアクセスするための方法を理解することができる。
　したがって，「アクセス」に関する構成要件Ａ，構成要件Ｇの記載及び相互の関係は明りょうであり，発明の詳細な説明にも記載されている。 
　
（２）構成要件Ｂについて 
　審判請求人は，構成要件Ｂにおける「前記クライアントにおいて単一の目標ＵＲＬに対応する記述子を提供する段階」の記載は，「記述子を提供する」の技術的な意味，並びに「提供」する主体及びその「提供」先が明確でないと主張している。 
　審判請求人は更に，構成要件Ｂは「ユーザがクライアントＰＣに記述子を入力する段階」と解釈することが文言上は自然であるが，特許請求の範囲には「クライアントからディレクトリサーバーへ記述子を送信する段階」（あるいは，「ディレクトリサーバーがクライアントから記述子を受信する段階」）の記載が無いため，構成要件Ｃにおいて前記記述子が既に「ディレクトリサーバー」に場所を移していることとの整合が取れず，不合理であると主張している。 
　しかし，発明の詳細な説明の段落【００４１】−【００４４】の記載によれば，記述子はユーザがクライアントに入力するものであり，クライアントに入力された記述子はディレクトリサーバーに送信されることが理解できる。 
　そして，審判請求人が主張するとおり，特許請求の範囲には「クライアントからディレクトリサーバーへ記述子を送信する段階」（あるいは，「ディレクトリサーバーがクライアントから記述子を受信する段階」）の記載はないが，クライアントにおいて記述子が提供され（構成要件Ｂ），ディレクトリサーバーにおいて前記記述子がＵＲＬにマッピング（構成要件Ｄ）されているから，「記述子を送信する段階」や「記述子を受信する段階」が明記されていなくても，請求項１において，構成要件Ｄにおける記述子が構成要件Ｂにおいてクライアントにおいて提供された記述子であることは明確に理解することができる。 
　したがって，構成要件Ｂの記載は明りょうである。 
　
（３）構成要件Ｃ，Ｄについて 
　審判請求人は，構成要件Ｃ，Ｄにいう「ディレクトリサーバー」とは具体的に何であるか不明確であると主張している。しかしながら，「ディレクトリサーバー」は，構成要件Ｃに記載されているように「前記記述子を前記ディレクトリサーバーに存在する翻訳データベースを用いて前記ＵＲＬにマッピングする段階と，ＲＥＤＩＲＥＣＴコマンド中の前記ＵＲＬを前記クライアントに返送する段階と」を有するサーバであって，それ自体意味は明らかである。 
 　そして，この点に関し，発明の詳細な説明の段落【００４３】には，「一旦ＮＵＭＢＥＲがディレクトリサーバー６０２により受信されると，ディレクトリサーバーはデータベース６０４を用いて，ＮＵＭＢＥＲに対応するサービスを実施する商業サーバーおよびドキュメントを記述する目標ＵＲＬにＮＵＭＢＥＲを翻訳する。」と記載され，段落【００４５】には，「ディレクトリサーバー６０２がＲＥＤＩＲＥＣＴをクライアント６０１に送信し，これには，データベース６０４から演算されたＮＵＭＢＥＲに対する目標ＵＲＬが記述されている。」と記載されており，ディレクトリサーバーは構成要件Ｃ，Ｄに記載されているように「前記記述子を前記ディレクトリサーバーに存在する翻訳データベースを用いて前記ＵＲＬにマッピングする段階と，ＲＥＤＩＲＥＣＴコマンド中の前記ＵＲＬを前記クライアントに返送する段階と」を有するサーバであって，その意味は明らかであり，発明の詳細な説明にも記載されている。
　
（４）請求項２−７の記載について 
　審判請求人は，請求項２−７の記載は，記載に不備を有する請求項１の従属項であるから，各請求項ともにその記載が不明瞭であると主張しているが，請求項１の記載が明確であることは前記のとおりであり，請求項１を引用して記載された請求項２−７にはその他に不明りょうな記載は見当たらないから，請求項２−７の記載は明りょうである。 
　
　以上のとおりであるから，本件特許の特許請求の範囲は，特許法第３６条第６項第１号及び第２号に規定する要件を満たしている。 
　
２．特許法第３６条第４項について
　審判請求人が不明確であると主張する特許請求の範囲の記載が，明細書の記載との関係において明確であることは前記のとおりである。 
　そして，審判請求人の主張する「記述子をどのような手段で翻訳データベースの存在するディレクトリサーバーに送るか又は受取るか」，「「“ダイヤル”コマンド」とは具体的には何なのか」，「「“ダイヤル”コマンド」以外に記述子を入力し送信する具体的な方法はあるのか否か，あるとすればどのような方法か」，「標準的なプロトコルは利用することができるのか」，「ウェブクライアントでなくディレクトリクライアントからは利用できるのか，できるとすれば如何なる態様によるのか」などの点が不明であっても，記述子をクライアントにおいて提供することが実施可能であることは明らかであるし，そのために情報処理の段階を設ける必要が生じても，実施にあたって適宜選択し得る設計的事項にすぎないから，本件特許の明細書は当業者が本件訂正発明１−７を実施できる程度に明確かつ十分に記載されている。 
　
　よって，本件特許の明細書及び図面の記載は，特許法第３６条第４項に規定する要件を満たしている。 
　
３．特許法第２９条第２項について
（１）本件訂正発明１について
　本件訂正発明１と上記「第６」の引用発明を対比すると，少なくとも，以下の点において相違（以下，「相違点」という。）するものと認められる。
　
　本件訂正発明１は，「ディレクトリサーバー」が，ＲＥＤＩＲＥＣＴコマンド中の前記ＵＲＬを前記クライアントに返送する段階を備えるのに対して，引用発明においては，サーバー・ホスト上で動作するTCPモジュールは，転送が行われていることを認識し，サーバー・ホスト上のTCPは，パケットのソース・アドレスをフラッグシップ・ホストのアドレスに設定し，すべての応答メッセージを直接クライアントに送信し，フラッグシップ・ホストがクライアントに対して，そのパケットをサーバー・ホストにリダイレクトする必要があると知らせるものである点
　
（２）相違点についての検討
（２−１）引用発明における「リダイレクト」について
　上記「第６」に摘記した甲第１号証に記載された事項によると，引用発明の「リダイレクト」に関して，次のようにいうことができる。
　甲第１号証には，「イエローページ・サービス」が開示されるとともに，「インターネットの至る所」からのクライアントが「イエローページ・サービス」を含むローカルエリア・ネットワーク内のサーバーが提供するサービスを利用することができるようにするために，フラグシップ・ホストによってクライアントから送信されたパケットを転送して，ローカルエリア・ネットワーク内のサーバーにアクセスする方法が開示されている。
　そして，「インターネットの至る所」からのクライアントは，フラグシップ・ホストに対して，特定の属性のセットを満足するサーバーを要求することはできないとされている。
　他方，フラグシップ・ホストは，「インターネットの至る所」からのクライアントが求めるサービスを提供するローカルエリア・ネットワーク内の複数のサーバーの中から，負荷が一定レベル以下のものを選択してクライアントのアクセスを確立するために，イエローページ・サーバーに負荷の状況を定期的に問い合わせ，テーブルを更新するという機能を有するものである。
　甲第１号証においては，以上のような転送メカニズムによるアクセスの方法を前提として，「フラグシップ・ホストが，クライアントに対して，そのパケットをサーバー・ホストにリダイレクトする」ようにできるとしている。この意味は，「インターネットの至る所」からのクライアントがイエローページ・サービス（メール・サービス）を利用したいと考えて，パケットを送信することによりイエローページ・サーバー（メール・サーバー）へのアクセスを要求した場合，これを受け取ったフラグシップ・ホストが，パケットを，負荷の高くないイエローページ・サーバー（メール・サーバー）のアドレスを指定して，直接アクセスするように命令するようにするということである。
　そうすると，引用発明における「リダイレクト」は，ローカルエリア・ネットワーク内のサーバーが提供するイエローページ・サービスなどのサービスについて，「インターネットの至る所」からのクライアントが利用することができるようにする場合において，同ネットワーク内の負荷を調整するために，同ネットワーク内の唯一のホストであるフラグシップ・ホストによって行われるものである。
　
(２−２)本件訂正発明１における「ＲＥＤＩＲＥＣＴコマンド」について
　本件訂正発明１の「ＲＥＤＩＲＥＣＴコマンド」は，ディレクトリサーバーが，クライアントに対して返送するものであって，クライアントにおいて提供した記述子に対応するＵＲＬを含み，同コマンドを受信したクライアントにおいて，同ＵＲＬを用いて情報を要求させるものであり，その結果同ＵＲＬによって識別されたページがクライアント側で表示される，というものである。
　
(２−３)相違点についての判断
　上記(２−１)及び(２−２)によると，本件訂正発明１の「ＲＥＤＩＲＥＣＴコマンド」がクライアントにおいて情報ページを自動的に表示させるためのコマンドであって，ディレクトリサーバーによって行われるものであるのに対して，引用発明の「リダイレクト」は，ローカルエリア・ネットワーク内のサーバーに対する「インターネットの至る所」からのクライアントによるアクセスを確立する方法であって，このようなクライアントに対してローカルエリア・ネットワーク内の唯一のホストであるフラグシップ・ホストによって行われるものであるということができる。
　そうすると，インターネットにおけるアクセスが行われたときに，要求のあった記述子に対応するＵＲＬへリダイレクトさせる本件訂正発明１と，ローカルエリア・ネットワーク内のサーバーとのアクセスを実現するためのフラグシップ・ホストによる「リダイレクト」を行うことは技術的課題も目的も異なるものであって，通常のインターネットにおいてディレクトリ・サーバーへアクセスする方法において，フラッグシップ・ホストによる「リダイレクト」の構成を採用するような動機付けは発生する余地がないし，甲第１号証にはそのような示唆もない。
　また，甲第２号証（平成６年１２月１日発行の雑誌「ＵＮＩＸ ＵＳＥＲ」）には「他のＵＲＬに変換〜Redirect」との項目において，「Redirectに指定したパターンにマッチした場合は，指定したＵＲＬにリクエストがそのままフォワードされる。サーバーが引っ越したような場合に用いる。ＵＲＬは『http://ホスト名/』から書かなければならない。」（１３５頁左欄１９〜２３行）と記載されており，ここに「Redirect」として紹介されている技術はいわゆる転送の技術であり，上記記載の技術が当業者に周知であったと認められ，フラッグシップホストを必要とする引用発明にこの技術を適用することによっても，フラグシップ・ホストは，パケットを，負荷の高くないイエローページ・サーバー（メール・サーバー）のアドレスを指定して，直接アクセスするように命令するようにしたにとどまり，本件訂正発明１のような構成とすることができないことは明らかである。
　そして，引用発明においてはクライアントは，フラグシップ・ホストに対して，特定の属性のセットを満足するサーバーを要求することはできないとされていること，そもそも引用発明のフラッグシップ・ホストはパケットをサーバーにリダイレクトする必要があると知らせるように修正できるのであるが，クライアントが記述子を提供し，ディレクトリ・サーバが記述子をＵＲＬにマッピングして，クライアントに提供するような構成を備えていない。よって，クライアントがＵＲＬを用いて情報を提供するサーバーを特定することが周知であったとしても，上記周知技術を引用発明に適用しても本件訂正発明１のような構成を想到できないことは明らかである。
　さらに，フラッグシップ・ホストとイエローページ・サーバーを同一サーバー，仮にフラッグシップ・サーバーと成すことを想定するとフラッグシップ・サーバーにアクセスするクライアントはリダイレクトにより所定のサーバーへアクセスできることになるが，そもそも引用発明は，インターネットの至る所からクライアントが，フラッグシップ・ホストによる転送メカニズムによってイエローページ・サーバーを利用することができるものであるから，引用発明において何のためにフラッグシップ・ホストとイエローページ・サーバーを同一のサーバー上に設けるかという動機付けが存在しない。
　
（２−４）平成２２年４月１９日付け上申書について
　請求人は平成２２年４月１９日付け上申書において主に次の３点について主張している。
ａ．本件発明ＲＥＤＩＲＥＣＴコマンドが意味する技術は優先日当時は公知であったこと。
ｂ．ｈｔｔｐリダイレクトは本件優先日当時すでに公知であったこと。
ｃ．ＬＡＮからインターネットへの容易想到性
　そこで，上記ａ〜ｃについて以下，検討する。
　
ａ，ｂについて
　上記（２−３）に記載したとおり，甲第２号証（平成６年１２月１日発行の雑誌「ＵＮＩＸ ＵＳＥＲ」）には「他のＵＲＬに変換〜Redirect」との項目において，「Redirectに指定したパターンにマッチした場合は，指定したＵＲＬにリクエストがそのままフォワードされる。サーバーが引っ越したような場合に用いる。ＵＲＬは『http://ホスト名/』から書かなければならない。」（１３５頁左欄１９〜２３行）と記載されており，ここに「Redirect」として紹介されている技術はいわゆる転送の技術であり，上記記載の技術が当業者に周知であったと認められるが，フラッグシップ・ホストを必要とする引用発明にこの技術を適用することによっても，フラグシップ・ホストは，パケットを，負荷の高くないイエローページ・サーバー（メール・サーバー）のアドレスを指定し，直接アクセスするように命令するようにしたにとどまり，本件訂正発明１のような構成とすることができないことは明らかである。そして同様に，本件訂正発明１のＲＥＤＩＲＥＣＴコマンドあるいはｈｔｔｐリダイレクトが意味する技術が優先日当時は公知であったとしても，フラグシップ・ホストは，パケットを，負荷の高くないイエローページ・サーバー（メール・サーバー）のアドレスを指定し，直接アクセスするように命令するようにできるだけであって，甲第１号証のリダイレクトに適用して本件訂正発明１のように構成できないことは明らかである。
　
ｃ．について
　ＬＡＮとインターネットがＴＣＰ／ＩＰによって統一的に相互に接続されていることを前提としても，引用発明は，フラグシップ・ホストは，パケットを，負荷の高くないイエローページ・サーバー（メール・サーバー）のアドレスを指定し，直接アクセスするように命令するにとどまり，クライアントが記述子を提供し，ディレクトリ・サーバが記述子をＵＲＬにマッピングし，ディレクトリ・サーバがＲＥＤＩＲＥＣＴコマンド中のＵＲＬをクライアントに返送する，本件訂正発明１の構成とは全く異にするものである。よって，甲第１号証に記載されたＬＡＮでのイエローページサービスに関する技術とインターネットからイエローページサービスを受けることに関する技術から構成を適宜抽出しても本件訂正発明１とするような動機はないから，本件訂正発明１を想到できないことは明らかである。
　よって，上記上申書による主張も採用できない。
　
（３）請求項２〜７に係る発明について
　本件訂正発明２〜７は，本件訂正発明１を引用してさらに限定するものであるから，本件訂正発明１が引用発明及び周知技術に基づいて，当業者が容易に発明することができたものではない以上，本件訂正発明２〜７もまた当業者が容易に発明することができたものではない。
　
　以上，他の相違点について検討するまでもなく，本件訂正発明１〜７は引用発明に基づいて当業者が容易に発明をすることができたものということはできない。
　
第８　むすび
　以上のとおりであるから，請求人が主張する無効理由によっては本件特許の請求項１〜７に係る特許を無効とすることはできない。
　
　審判に関する費用については，特許法第１６９条第２項で準用する民事訴訟法第６１条の規定により，審判請求人が負担すべきものとする。
　
　よって，結論のとおり審決する。