戻る

平成２２年３月８日判決言渡
平成２１年（行ケ）第１００６８号審決取消請求事件
口頭弁論終結日平成２２年３月１日
判決
原告有限会社バリアフリー
被告特許庁長官
指定代理人江嶋清仁
同近藤聡
同岩崎伸二
同田村正明
主文
１原告の請求を棄却する。
２訴訟費用は原告の負担とする。
事実及び理由
第１請求
特許庁が不服２００５−８２０３号事件について平成２１年１月２６日にし
た審決を取り消す。
第２事案の概要
本件は，原告が名称を「機能拡張装置および機能拡張方法ならびに機能拡張
プログラムを記録した記録媒体」とする発明につき平成１０年６月２６日付け
で特許出願をしたところ，拒絶査定を受けたので，これを不服として審判請求
をしたが，特許庁から請求不成立の審決を受けたことから，その取消しを求め
た事案である。
第３当事者の主張
１請求の原因
(1)特許庁における手続の経緯
原告は，平成１０年６月２６日，名称を「機能拡張装置および機能拡張方
法ならびに機能拡張プログラムを記録した記録媒体」とする発明について特
許出願（特願平１０−１９５１０８号，請求項の数１５，以下「本願」とい
う。公開公報は特開２０００−２０４４４号〔甲１０〕）をしたが，特許庁
から拒絶査定を受けたので，これに対する不服の審判請求をした。
特許庁は，同請求を不服２００５−８２０３号事件として審理した上，平
成２１年１月２６日，「本件審判の請求は，成り立たない。」との審決をし，
その謄本は同年２月１４日原告に送達された。
(2)発明の内容
本願の内容は，以下のとおりである。
・【請求項１】
既存WWWサーバがURLを処理するに際して意図的にエラーを誘発するエラ
ー誘発手段と，前記既存WWWサーバが記憶手段に保持するデータのうち少
なくともURLパス部を利用して処理を行う文字列処理手段と，前記エラー
誘発手段によりエラーが発生した時に前記既存WWWサーバから前記文字列
処理手段へと処理を分岐させる分岐手段とを備える機能拡張装置。
・【請求項２】
既存WWWサーバがURLを処理するに際して意図的にエラーを誘発するエラ
ー誘発手段と，前記既存WWWサーバが記憶手段に保持するデータのうち少
なくともURLパス部を利用して処理を行う文字列処理手段と，前記エラー
誘発手段によりエラーが発生した時に前記既存WWWサーバから前記文字列
処理手段へと処理を分岐させる分岐手段とを備える機能拡張装置であって，
前記エラー誘発手段により発生するエラーの程度またはタイミング等を変
更するための条件変更手段を備える機能拡張装置。
・【請求項３】
前記エラー誘発手段，前記文字列処理手段，ならびに前記分岐手段のう
ちの１または２以上の手段を，前記既存WWWサーバの固定的部位を何ら変
更することなく備える請求項１または請求項２記載の機能拡張装置。
・【請求項４】
前記URLパス部を含むURLは，WWWクライアントのURL入力表示欄で入力さ
れたクライアント側入力文字列に由来し，前記文字列処理手段はWWWサー
バに対してどのような形式をもっても伝達されない箇所以外は前記クライ
アント側入力文字列が入力された形式の表記にて獲得する獲得手段を備え
る請求項１または請求項２記載の機能拡張装置。
・【請求項５】
前記URLパス部を含むURLは，WWWクライアントのURL入力表示欄で入力す
る以外の方法で入力されたまたは設定されたクライアント側入力文字列に
由来し，前記文字列処理手段はWWWサーバに対してどのような形式をもっ
ても伝達されない箇所以外は前記クライアント側入力文字列が入力された
形式の表記にて獲得する獲得手段を備える請求項１または請求項２記載の
機能拡張装置。
・【請求項６】
前記URLパス部は漢字，ひらがなまたはカタカナを含み，CGIプログラム
等へのパラメータ伝達を指示するものであるとRFCにより定義された文字
列をその定義の通りに用いる用途では含まない請求項４または請求項５記
載の機能拡張装置。
・【請求項７】
前記URLパス部は(1)日本語や他の国または地域の言語の語句を含むか，
(2)特定の学術分野等で用いられている記号類を用いた表記を含むか，また
は，(3)コンピュータ言語の命令やデータを含むかのいずれかあるいはそれ
らの２以上の組合せである請求項４または請求項５記載の機能拡張装置。
・【請求項８】
前記URLパス部は検索を指示する文字列が含まれている請求項４または
請求項５記載の機能拡張装置。
・【請求項９】
前記文字列処理手段は，(1)RFCにより特別の意味が設定されている文字
列のうちの少なくとも１についてこれを本来の文字そのままのデータとし
て処理する特別文字列普通解釈手段か，または，(2)予め定義されたまた
は随時定義する文字列をRFCにより特別の意味が設定されている文字列と
同等に処理する普通文字列特別解釈手段のうちの少なくとも一方を備える
請求項４または請求項５記載の機能拡張装置。
・【請求項１０】
既存情報処理手段が情報処理するに際して意図的にエラーを誘発するエ
ラー誘発手段処理ステップと，前記既存情報処理手段における情報処理結
果の一部または全部を利用して前記既存情報処理手段の外で処理を行う外
部情報処理手段と，前記エラー誘発手段によりエラーが発生した時に前記
既存情報処理手段から外部情報処理手段へと処理を分岐させる分岐手段と
を備える機能拡張装置。
・【請求項１１】
前記エラー誘発手段により発生するエラーの程度またはタイミング等を
変更するための条件変更手段を備えている請求項１０記載の機能拡張装置。
・【請求項１２】
既存WWWサーバがURLを処理するに際して意図的にエラーを誘発するエラ
ー誘発設定ステップと，前記既存WWWサーバが記憶部に保持するデータの
うち少なくともURLパス部を利用して処理を行う文字列処理ステップと，
前記エラー誘発設定ステップによりエラーが発生した時に前記既存WWWサ
ーバから前記文字列処理ステップへと処理を分岐させる分岐処理ステップ
とを備える機能拡張方法。
・【請求項１３】
既存WWWサーバがURLを処理するに際して意図的にエラーを誘発するエラ
ー誘発設定ステップと，前記既存WWWサーバが記憶部に保持するデータの
うち少なくともURLパス部を利用して処理を行う文字列処理ステップと，
前記エラー誘発設定ステップによりエラーが発生した時に前記既存WWWサ
ーバから前記文字列処理ステップへと処理を分岐させる分岐処理ステップ
とを備える機能拡張プログラムを記録した記録媒体。
・【請求項１４】
既存情報処理手段が情報処理するに際して前記既存情報処理手段におけ
る情報処理結果の一部または全部を利用して前記既存情報処理手段の外で
処理を行う外部情報処理手段と，エラーが発生した時に前記既存情報処理
手段から外部情報処理手段へと処理を分岐させる分岐手段とを備える機能
拡張装置。
・【請求項１５】
既存WWWサーバがURLを処理するに際して前記既存WWWサーバが記憶手段
に保持するデータの一部または全部を利用して処理を行う文字列処理手段
と，エラーが発生した時に前記既存WWWサーバから前記文字列処理手段へ
と処理を分岐させる分岐手段とを備える機能拡張装置。
(3)審決の内容
審決の内容は，別添審決写しのとおりであり，審決で引用された拒絶理由
は別添拒絶理由通知書写し（一部省略）のとおりである。
その理由の要点は，本願の請求項１∼１５に係る発明は明確でない（特許
法３６条６項２号），請求項１∼１５に係る発明(本願各発明）は引用文献
１∼９に記載された発明との関係で進歩性を有しない（特許法２９条２項），
請求項１・１０・１２∼１５に記載された発明は引用文献９に記載された先
願発明と実質的に同一である（特許法２９条の２）等，である。
記
・引用文献１：下村昭彦「つこてなんぼのＦｒｅｅＢＳＤ第４回」，株式会
社技術評論社，ＳｏｆｔｗａｒｅＤｅｓｉｇｎ，第８１号，１３４頁∼１
４５頁，１９９７年（平成９年）７月１８日発行
・引用文献２：豊福剛「LittleScriptPages［3］」，株式会社翔泳社，ＤＤ
ＪＤｒ．Ｄｏｂｂ’sＪｏｕｒｎａｌＪａｐａｎ，６巻１０号１２７頁
∼１３４頁，１９９７年（平成９年）９月１日発行
・引用文献３：特開平９−６６６７号公報（発明の名称「プロファイルおよび
トピックを使用したハイパーテキストの情報検索」，出願人サン・マイク
ロシステムズ・インコーポレーテッド，公開日平成９年１月１０日。）
・引用文献４：特開平６−８９３０４号公報（発明の名称「テキスト処理シス
テムにより使用されるテキストを準備する方法及び装置」，出願人サン・
マイクロシステムズ・インコーポレーテッド，公開日平成６年３月２９
日。）
・引用文献５：特開平３−１５９８０号公報（発明の名称「文字列検索のため
の異表記及び同義語展開方法」，出願人株式会社日立製作所，公開日平
成３年１月２４日。）
・引用文献６：特開平１０−６３５９７号公報（発明の名称「クライアント側，
サーバ側および協調部で実行するＵＲＬのスペルチェック」，出願人サン
マイクロシステムズインコーポレイテッド，公開日平成１０年３月６
日。）
・引用文献７：米国特許５７６１６８３号公報（発明の名称「TECHNIQUESFO
RCHANGINGTHEBEHAVIOROFALINKINAHYPERTEXTDOCUMENT〔ハイパー
テキスト・ドキュメント中のリンクの動作を変更するための技術〕」，権
利者MicrotouchSystems,Inc.,公報発行日１９９６年〔平成８年〕２月
１３日。）
・引用文献８：特開平１０−７８９２８号公報（発明の名称「インターネット
へのアクセス方法およびシステム，ならびにインターネットへのアクセス
処理を記憶した記憶媒体」，出願人ディアンドアイシステムズ株式会社，
公開日平成１０年３月２４日。）
・引用文献９：特開平１１−３２８０７６号公報（特願平１０−１５２０３１
号の願書に最初に添付した明細書及び図面，発明の名称「インターネット
へのアクセス方法およびシステム」，出願人株式会社アテックス，出願日
平成１０年５月１４日，公開日平成１１年１１月３０日。）
(4)審決の取消事由
しかしながら，審決には，以下に述べるとおり誤りがあるので，審決は違
法として取り消されるべきである。
ア取消事由１
審決に表示された拒絶理由通知（甲１１）は，「（理由４）進歩性」
欄において，本願の請求項１，３，１０，１２∼１５に係る発明（以下
「本願発明１，３，１０，１２∼１５」等という。）に関し，「・・・サ
ーバの設定がエラーを発生させるような状態に設定されていれば，エラー
を誘発させ，サーバでの処理を分岐させ，文字列処理を行わせることに格
別の困静性は認められない。」（５頁１２行∼１４行）とした。
しかし，一般のサーバ運用者又はその管理者は，サーバのエラーをでき
るだけ発生させずに運用することを望むものであり，不本意にも発生して
しまったエラーについては，エラーログを参照するなどしてその原因を発
見・除去して正常化させる（リカバーする）とするのが一般の運用である。
したがって，一般のサーバ運用者にとって，サーバのエラーを発生させる
ような状態に設定することへの動機はない。
また，引用文献１及び引用文献２には，サーバエラー発生時のリカバー
についての記載はあるが，その逆については記載はない。
そして，サーバエラー発生時に既存のＵＲＬの処理をリカバーするので
はなく，新たな発展的有効活用を図る処理を行うことは，視点を異にする
ものである。
イ取消事由２
審決に表示された拒絶理由通知（甲１１）は，「（理由４）進歩性」
欄において，本願発明６∼９に関し，「一般にＷＷＷブラウザにおいて，
ＵＲＬパス部に漢字等の非アスキー文字を含むこと，または，含ませるこ
とを排除するものではない。」（５頁３１行∼３１行）とした。
しかし，ＷＷＷサーバとＷＷＷクライアント（ＷＷＷブラウザを含む）
との間の通信規約はＲＦＣなる文書群により「ＨＴＴＰ」なる名称でルー
ルが定められているところ，そのルールの一部として，ある者は「ブラウ
ザに表示させるＵＲＬに日本語を使うことはできません。」としており
（甲１５），ある者は「Ｗｅｂページを参照するためのＵＲＬ（Ｕｎｉｆ
ｏｒｍＲｅｓｏｕｒｃｅＬｏｃａｔｏｒ）は，本来１ｂｙｔｅ文字の英
数字のみが使用できる。」等としているから（甲１７，３０，３１），上
記認定は誤りである。
ウ取消事由３
審決に表示された拒絶理由通知（甲１１）は，「（理由７）新規性」
欄において，本願発明１，１０，１２∼１５は引用文献９（甲９）に記載
された発明と同一である旨認定した。
しかし，上記認定は誤りであり，その理由は次のとおりである。
(ｱ)引用文献９には「・・・ＵＲＬを構成する文字列は半角の英数字であ
るため，日本語をローマ字や英語で表さなければならない」（段落【０
００５】）と記載されていること。
(ｲ)引用文献９の段落【００２４】の１行∼５行目の記載によれば，引用
文献９に記載された発明の実施の形態における処理手順では，全角文字
や半角カタカナを含む文字列をＵＲＬとみなしておらず，これと反対の
立場に立つ本願発明１，１０，１２∼１５とは違いがあること。
(ｳ)引用文献９の段落【００１８】３行目の記載によれば，引用文献９記
載の発明の実施の形態では，「クライアント側」において「文字列変換
プログラムを介」する必要があるが，本願発明１，１０，１２∼１５で
は不要であること。
(ｴ)文字列変換プログラム（一般に「プラグイン」と称される。）をサー
バ側に置く場合でも，処理対象文字列をクライアント側での普通の取扱
いを変更してクライアント側からサーバ側へと伝達する，いわば「無変
換パススループログラム」（プラグインの一種といえる。）を介する必
要がある点に留意する必要があること。
なお，原告は，本願の早期審査に関する事情説明書（甲１７）におい
て，「ホームページのアドレス（ＵＲＬ）において漢字やひらがな等の
利用を可能にする新しい技術（仮称：「漢字ＵＲＬ」）」の概要の１つ
として，「ウェブブラウザ（閲覧ソフト）側には特殊な設定は不要。現
行のブラウザをそのまま利用可能。」としており，同技術においてクラ
イアント側でのプラグインが不要である旨表示している。
(ｵ)引用文献９における文字列変換は，入力：ＵＲＬでない文字列（例え
ば首相官邸），出力：ＲＦＣ準拠文字列，介在者：プラグインである一
方，本願発明１，１０，１２∼１５では，入力：ＲＦＣ非準拠ＵＲＬ
（http://RURL.NET/首相官邸），出力：ＲＦＣ準拠ＵＲＬ，介在者なし
であり，両者の構成は異なる。
エ取消事由４
審決に表示された拒絶理由通知（甲１１）は，「（理由６）進歩性」
欄において，本願発明１，１０，１２∼１５は引用文献８（甲８）に記載
された発明に基づいて容易に発明をすることができたとしたが，誤りであ
る。
その理由は次のとおりである。
(ｱ)引用文献８の段落【００１２】の記載によれば，「アクセス機器」か
ら入力された番号はクライアント側又はクライアント側から「番号変換
サーバ」側へと伝達した後，サーバ側で「ＵＲＬに逆変換」する。よっ
て，クライアント側において何らかのプラグインが必要であるが，本願
発明１，１０，１２∼１５では不要である。
(ｲ)引用文献８に記載された発明は，本願各発明に関する国際調査報告
（甲１２）で関連文献の１つとして評価済みであり，その評価結果は
「Ａ」カテゴリー，すなわち「特に関連のある文献ではなく一般的技術
水準を示すもの」に止まる。
オ取消事由５
審決に表示された拒絶理由通知（甲１１）は，「（理由５）進歩性」
欄において，本願発明１，３，１０，１２∼１５は「ＷＷＷクライアント
において，英語以外の漢字，カタカナ，ひらがななどの言語の文字列が入
力された場合にも，処理を分岐させて文字列処理をすることは，例えば引
用文献４，５等に示されるように周知技術である。」と認定しているが，
誤りである。なぜなら，被告は，「クライアント側において何らかのプラ
グインが必要である」ことの要否の検討を欠いているからである。
カ取消事由６
本件審決で表示された拒絶理由通知（甲１１）は，「（理由１）記載
不備」，「（理由２）記載不備」，および「（理由３）記載不備」欄
にて記載不備をいうが，誤りである。その理由は次のとおりである。
(ｱ)請求項１中の「意図的に」なる記載が明確でないとの指摘は当たら
ない。「意図的に」は「わざと」と換言できる。後者の語を用いると
請求項１中の「意図的にエラーを誘発する」は「わざとエラーを引き
起こす」と変形することができる。これと同様の表現は他の文献（雑
誌「OPENDESIGN」２００２年２月号，第９巻第２号，２００２年（平
成１４年）２月１日発行，甲１６）にも見ることができ，難無く解釈
でき，不明確ではない。また，「意図的に」の具体的内容は，本願明
細書の段落【０１５０】【０１６７】【０１７１】に記載がある。
請求項２，１３についても同様である。
(ｲ)請求項１中の「機能拡張装置」における「機能拡張」の技術的範囲
が不明であるとの指摘は当たらない。請求項１は「既存WWWサーバがUR
Lを処理するに際して意図的にエラーを誘発するエラー誘発手段と，前
記既存WWWサーバが記憶手段に保持するデータのうち少なくともURLパ
ス部を利用して処理を行う文字列処理手段と，前記エラー誘発手段に
よりエラーが発生した時に前記既存WWWサーバから前記文字列処理手段
へと処理を分岐させる分岐手段とを備える」「装置」をクレームして
いる。そして当該「装置」を「機能拡張装置」と称しているにすぎな
い。同請求項中の「意図的にエラーを誘発するエラー誘発手段」と同
様の表現である。
他の請求項中の「機能拡張装置」，「機能拡張方法」，「機能拡張
プログラム」の各語についても同様である。
(ｳ)請求項３中の「固定的部位を何ら変更することなく備える」が日本
語として明確でないとの指摘は当たらない。「固定的部位」について
は本願明細書段落【００３８】に記載がある。
(ｴ)審決は，請求項４，５中の「以外」なる記載は範囲をあいまいにす
る表現である結果，発明の範囲が不明確であるとするが，その指摘は
当たらない。例えば，「整数のうちの奇数以外」は即ち「整数のうち
の偶数」である。「以外」の語の利用のみをもって前記発明が発明の
範囲が不明確であるとはいえない。
(ｵ)請求項６中の「用いる用途では含まない」なる記載が日本語として
明確でないとの指摘は当たらない。ＵＲＬパス部について「ＣＧＩプ
ログラム等へのパラメータ伝達を指示するものであるとＲＦＣにより
定義された文字列をその定義の通りに用いる用途では含まない」につ
いては本願明細書【００５６】に記載がある。
(ｶ)請求項９中の「随時定義」なる記載が具体的にどのような手段によ
りどのように定義するのか明確でないとの指摘は当たらない。その前
後も含めて示せばこの記載は，「予め定義されたまたは随時定義する
文字列」である。この表現の中には「予め定義された文字列（静的な
もの）」と「随時定義する文字列（動的なもの）」とが含まれる。後
者は「予め定義されるのではない文字列（静的ではないもの）」の言
い換えであり，表現として明確である。
(ｷ)請求項９中の「同等に処理」なる記載中の「同等」が明確でないと
の指摘は当たらない。その前後も含めて示せばこの記載は，「予め定
義された又は随時定義する文字列をＲＦＣにより特別の意味が設定さ
れている文字列と同等に処理する普通文字列特別解釈手段」である。
一部を記号化して整理すれば「文字列Ｘを文字列Ｙと同等に処理する
手段Ｚ」（「実際には文字列Ｙとは異なる文字列Ｘを，文字列Ｙと等
価なものとして処理する，手段Ｚ」）となる。
(ｸ)請求項１０中の「エラー誘発手段処理ステップ」なる記載が明確で
ないとの指摘は当たらない。その前方も含めて示せばこの記載は，
「意図的にエラーを誘発するエラー誘発手段処理ステップ」である。
ここでは「意図的にエラーを誘発するステップ」が説明部である。そ
して当該「ステップ」を「エラー誘発手段処理ステップ」と称してい
るに過ぎない。請求項１２，１３中の「エラー誘発設定ステップ」に
ついても同様である。
(ｹ)請求項６中の「（ＣＧＩ）プログラム等」が明確でないとの指摘は
当たらない。「等」を削除して「ＣＧＩプログラム」と限定すべきで
はない。本願各発明出願当時，当業者においてはＣＧＩプログラムと
類似の技術は知られていた。今後も新たなＣＧＩプログラム類似技術
は生じうるのだから，「ＣＧＩプログラム等」の表現は適当である。
また，ＵＲＬの構文については，本願明細書の段落【００２３】にお
いて，「正確な意味はＵＲＬに関するＲＦＣを参照されたい。」と記
載しているが，本願各発明出願当時の規約であるＲＦＣ１７３８及び
その更新版であるＲＦＣ２３９６には，ＵＲＬパス部に係る外部情報
処理手段についてＣＧＩプログラムに限定する旨の記載は無い。
請求項７中の「（特定の）学術分野等（で用いられている記号
類）」について明確でないとの指摘は当たらない。この部分は，本願
明細書中の用語「ＦｘＵＲＬ」で表現可能な「記号類」である。
請求項２，１１中の「（発生するエラーの程度または）タイミング
等（を変更するための条件変更手段）」について明確でないとの指摘
は当たらない。この「条件変更手段」については，本願明細書段落
【００３５】において，「エラーを誘発するための条件を変更する条
件変更手段」と記載されている。加えて，変更の対象は限定されてい
るが，変更の内容は特に限定されていない（本願明細書段落【０１５
４】及び図７参照）。よって，前記「タイミング等」中の「等」の有
無でこれらの請求項に係る発明の外延が不明瞭になることはない。
(ｺ)請求項１，２，７，９，１２，１３，１５中の「データ」は具体的
にどのようなデータを意味するのか明確でないとの指摘は当たらない。
請求項１，２，１５では「前記既存WWWサーバが記憶手段に保持するデ
ータ」と記載している。請求項１２，１３では「前記既存WWWサーバが
記憶部に保持するデータ」と記載している。請求項７では「コンピュ
ータ言語の命令やデータ」と記載している。前者はコンピュータ言語
において演算を指定する表現であり，後者はコンピュータ言語におけ
る演算の対象である。請求項９では「RFCにより特別の意味が設定され
ている文字列のうちの少なくとも１についてこれを本来の文字そのま
まのデータとして」と記載している。ここで「本来の文字そのままの
データとして」は，「本来の文字そのままで，すなわち，RFCにより設
定されている特別の意味を解除して」の意であり，表現は明確である。
(ｻ)請求項１∼３，１０∼１５中の「エラー」は具体的にどのようなエ
ラーを意味するのか明確でないとの指摘は当たらない。無用の限定を
する必要はない。仮に，現バージョンのＨＴＴＰのステータスコード
に則して限定した場合，将来バージョンのＨＴＴＰにおける「エラ
ー」を対象外としてしまう危険がある。加えて請求項１０，１１，１
４ではＨＴＴＰ以外のプロトコル（例：ＳＭＴＰ，ＤＮＳ，ＦＴＰ）
についても適用関係がある（本願明細書段落【００９６】∼【０１０
１】，【０１３２】及び図３参照）から，ＨＴＴＰステータスコード
による限定は無理がある。
(ｼ)請求項２，１１中の「エラーの程度またはタイミング等を変更する
ための条件変更手段」なる記載につき，発明の詳細な説明においても，
それ以上の具体的な記載がないとの指摘は当たらない。請求項２は
「＜請求項１＞＋＜条件変更手段＞」と模式化できる。この＜条件変
更手段＞は本願明細書の段落【０１５４】，【０１５８】，【０１７
８】，【０１９９】及び図７（とりわけ条件変更部７０８）に記載済
みである。これらの記載を基礎により広くて明瞭な表現にすべきだっ
たのを怠った点は認める。実際には，本願明細書段落【００３５】及
び【００３６】の内容に引きずられた結果，請求項２を不明瞭にした。
また，前記「機能拡張装置」と同様の表現でこの＜条件変更手段＞を
表現できなかった。請求項１１についても同様である。
(ｽ)請求項４，５中の「由来し」なる記載が，発明の詳細な説明におけ
るどの記載のことを意味するのか明確でないとの指摘は当たらない。
その前方も含めて示せばこの記載は，「ＷＷＷクライアントのＵＲＬ
入力表示欄で入力されたクライアント側入力文字列に由来し」である。
この＜○○側に由来し＞なる表現はＷＷＷ中継処理装置（２０６）の
存在を念頭に置いたものであり，本願明細書の段落【００４１】∼
【００４３】及び図２に記載がある。
(ｾ)請求項４，５中の「形式」なる記載が発明の詳細な説明におけるど
の記載のことを意味するのか明確でないとの指摘は当たらない。この
点は本願明細書の段落【００４４】∼【００４６】に記載がある。
(ｿ)請求項５中の「以外の方法」なる記載が発明の詳細な説明における
どの記載のことを意味するのか明確でないとの指摘は当たらない。そ
の前方も含めて示せばこの記載は，「ＷＷＷクライアントのＵＲＬ入
力表示欄で入力する以外の方法で入力された」である。この記載の否
定形に相当する入力方法は「ＷＷＷクライアントのＵＲＬ入力表示欄
で入力するという方法で入力された」である。これら２点の表現はい
ずれも明確である。これら２点については相違点も含めて本願明細書
の段落【００５０】∼【００５５】に記載がある。
(ﾀ)請求項７中の「２以上の組合せ」なる記載が発明の詳細な説明にお
けるどの記載のことを意味するのか明確でないとの指摘は当たらない。
本願明細書中の用語「ＦｘＵＲＬ」の定義から，当然に「２以上の組
合せ」がありうる(本願明細書段落【００６２】及び図１４参照）。
(ﾁ)請求項９中の「少なくとも一方を備える」なる記載に関連して「両
方を備える場合」が発明の詳細な説明におけるどの記載のことを意味
するのか明確でないとの指摘は当たらない。機能の異なる文字列処理
手段を複数多種準備してこれらを活用する点については，本願明細書
の段落【００３６】，【００３７】，【００９６】に記載がある。
２請求原因に対する認否
請求原因(1)(2)(3)の各事実は認めるが，(4)は争う。
３被告の反論
審決の認定判断に誤りはなく，原告主張の取消事由は理由がない。
(1)本願発明１４は引用発明１との関係で進歩性がない
ア(ｱ)引用文献１(甲１）には，以下の記載がある。
・「インターネットやイントラネットでWWWサーバを立ち上げるには，H
TTPサーバであるhttpdを利用します．今回はhttpd（Apache）のインス
トールと活用について解説します．」（１３４頁左欄１行∼４行）
・「現在主に使われているhttpdの１つにApacheがあります．これは，注１
NCSA版httpdの改良から始まったhttpdで，NCSAhttpdverl.3（およ
びverl.4）と完全互換であり，さらにさまざまな機能拡張などを施し
たものです．また，NCSAhttpdより高速なhttpdでもあります．
Apacheの特徴の１つにモジュールによる機能拡張があります．サー
バの機能をモジュールという形で与えることで，機能の追加／削除が
簡単に行えます．モジュール集はhttp://www.zyzzyva.com/server/mod
ule_registry/などから手に入ります．
今回は，このApacheをmake，インストールしてみることにしまし
た．」（１３４頁右欄３行∼１６行）
・「apache_1.1.3.tar.gzをmake，インストールします．これはApach注２
eのサポートサイト（http://www.apache.org/）から入手できます．ま
た，日本語サイトhttp://apache.maizuru-ct.ac.jp/からミラーサイト
が辿れます．
まず，アーカイブを解くとapache_1.1.3/というディレクトリができ
ます．ここに必要なファイルがすべて入っています．適当なディレク
トリへ展開してください．筆者は/srcに展開しました．各ディレクト
リ構成は表１のようになっています．」（１３４頁右欄１８行∼１３
５頁左欄１２行）
・「●表１ディレクトリ構成（apache_1.1.3/以下）
cgi-bin/ＣＧＩプログラム
conf/設定ファイル，最初はサンプルが入っている
htdocs/ＨＴＭＬのサンプルが入っている
icons/Fancylconで使うアイコンが入っている
logs/ログ
src/httpdのソースが入っている
support/サポートプログラム，最初はサポートプログラムの
ソースが入っている」（１３５頁左欄１行∼９行）
・「apache_1.1.3/conf/以下のファイルを編集します．デフォルトで
は，サーバルートが/usr/1oca1/etc/httpd/以下になっているので，こ
れらのファイルをディレクトリごとコピーします．
#cp-r/src/apache_1.1.3/??*/usr/local/etc/httpd/
設定ファイルを自分の環境にふさわしいように書き換えます．http
d.confとsrm.conf，そしてaccess.confの３つを設定すれば，WWWサ
ーバとして動作するようになります（それぞれ，表３のような役割
をもちます）．」（１３５頁右欄１７行∼２６行）
・「●表３Apacheの設定ファイル
ファイル名役割見本ファイル
access.confアクセス制限についての設定access.conf-dist
httpd.confサーバの動作についての設定httpd.conf-dist
srm.conf各ディレクトリやファイル名についての設定srm.conf-d
ist」
（１３６頁１行目∼５行）
・１３８頁右欄からsrm.confの設定についての記載があり，１４０頁
左欄から右欄に「ErrorDocument」のタイトルで以下の記載がある。
「ErrorDocument
エラードキュメントをカスタマイズできます．エラードキユメント
とは，誤ったＵＲＬを指定した場合などにクライアント上に表示され
るドキュメントのことです．ここでカスタマイズすると，他のサーバ
上にあるエラードキュメン卜を表示したり，ＣＧＩを使ったものを表
示させたりすることができるようになります．
エラードキュメントをプレーンテキストで表示するときには「”」
の後に続けて，表示したいテキストを記述します．ローカルのファイ
ルを表示させる場合には，そのファイルが存在するパスを絶対パスで
記述します．ローカルのＣＧＩの場合も同様に指定します．リモート
にあるファイルを表示させるには，そのファイルの存在するＵＲＬを
記述します．
ErrorDocument500"Theservermadeabooboo.
ErrorDocument404/missing.html
ErrorDocument404/cgi-bin/missing_handler.pl
ErrorDocument402http://other.server.com/subscription_info.htm
l｣
(ｲ)以上の記載から引用文献１には以下の発明（引用発明１）が記載され
ていることが認められる。
「ＨＴＴＰサーバであるApacheがインストールされ，
cgi-binディレクトリにはＣＧＩプログラムを格納し，
設定ファイルsrm.confには，誤ったＵＲＬを指定した場合にクライア
ント上に表示されるエラードキュメントをカスタマイズして設定でき，
上記設定は，エラードキュメントをプレーンテキストで表示するとき
には「”」の後に続けて，表示したいテキストを記述し，ローカルのフ
ァイルを表示させる場合には，そのファイルが存在するパスを絶対パス
で記述し，リモートにあるファイルを表示させるには，そのファイルの
存在するＵＲＬを記述し，ローカルのＣＧＩの場合も同様に指定し，Ｃ
ＧＩを使ったものを表示させることができるようにし，リモートにある
ファイルを表示させるには，そのファイルの存在するＵＲＬを記述する
ようにした，
ＷＷＷサーバ」
イ対比・判断
(ｱ)本願発明１４を引用発明１と比較する。
引用発明１であるＷＷＷサーバは既存情報処理手段に相当し，ＷＷＷ
サーバにはApacheがインストールされて情報処理を行っていることは明
白である。引用発明１は誤ったＵＲＬを指定するとＣＧＩプログラムを
使ったものを表示しているから，誤ったＵＲＬを指定した時にＣＧＩプ
ログラムに処理を分岐しているといえる。そして，誤ったＵＲＬを指定
することは「エラーが発生した時」に相当し，ＣＧＩプログラムによる
処理をすることは別の情報処理手段に処理を分岐させることに相当する。
また，ＣＧＩプログラムに処理を分岐するのは，ＷＷＷサーバが情報処
理を行い，誤ったＵＲＬを指定したことを検出したときと解されるから，
引用発明１においても既存情報処理手段における情報処理結果の一部ま
たは全部を利用しているといえる。
以上から，両者の一致点，相違点は次のとおりである。
＜一致点＞
「既存情報処理手段が情報処理するに際して前記既存情報処理手段に
おける情報処理結果の一部または全部を利用して処理を行う情報処理
手段と，エラーが発生した時に前記既存情報処理手段から別の情報処
理手段へと処理を分岐させる分岐手段とを備える装置」
＜相違点１＞
本願発明１４においては，既存情報処理手段に対して，その外に外部
情報処理手段があるのに対して，引用発明１では，既存情報処理手段に
相当するＷＷＷサーバが，別の情報処理手段に相当するＣＧＩプログラ
ムを備えている点。
＜相違点２＞
本願発明１４は「機能拡張装置」の発明であるのに対して，引用発明
１はＷＷＷサーバである点。
(ｲ)次に相違点について検討する。
・＜相違点１＞について
引用発明１は，誤ったＵＲＬを指定したときにＣＧＩプログラムへ
分岐し，このＣＧＩプログラムが作動してエラードキュメントを表示
しているところ，このＣＧＩプログラムは，ＷＷＷサーバに対して付
加的な情報処理手段を構成しているから，既存情報処理手段に対して
外部情報処理手段といえるものである。また，情報処理分野において，
付加的な情報処理手段を既存の情報処理手段に対して外部の情報処理
手段として構成することは，何ら格別なことではなく，適宜に設計し
得る事項である。
よって，引用発明１のＣＧＩプログラムを，既存情報処理手段に相
当するＷＷＷサーバに対して外部情報処理手段として構成することは，
当業者が容易に想到し得る事項である。
・＜相違点２＞について
前記のとおり，引用発明１のＣＧＩプログラムは，ＷＷＷサーバに
対して付加的な情報処理手段を構成し，ＣＧＩプログラムに記述され
た処理を行うものであるから，ＷＷＷサーバに対して機能を拡張して
いるといえる。そして，原告の主張によれば，既存のＷＷＷサーバ以
外の処理手段を指すものを「機能拡張装置」と「称しているにすぎな
い」ものであるから，引用発明１においてＣＧＩプログラムによる処
理を行う構成は，本願発明１４の機能拡張装置に相当するといえるも
のである。
よって，相違点２は格別のものではない。
・以上から，相違点１及び２は格別のものではなく，本願発明１４は
引用発明１から当業者が容易に想到することができたものである。
(2)本願発明１４は先願発明９との関係で新規性がない
ア(ｱ)引用文献９(甲９）には，以下の記載がある。
・「【０００４】ところが，このＵＲＬの入力はユーザにとっては思
わぬ障害となっている。その理由はＵＲＬを構成する文字列が長く，
しかも複雑な仕組みを持つことである。たとえばＡ株式会社のＵＲＬ
はそのホームページがどの管理下にあるかでhttp://www.a.co.jp/，h
ttp://www.a.com/，http://www.x.or.jp/a/，http://www.x.ne.jp/a/，
http://www2.x.or.jp/a/，http://a.x.or.jp/のように変わり，その
組み合わせは無限といえるほどである。このような複雑な仕組みを持
つＵＲＬは入力を１字間違えただけでアクセスできず，しかも間違い
の原因や箇所などを指摘する手段もないため，コンピュータやインタ
ーネットに精通したユーザ以外の利用は困難を極めている。」
・「【０００５】さらに，ＵＲＬを構成する文字列は半角の英数字で
あるため，日本語をローマ字や英語で表さなければならないが，その
際にもユーザにとって次のような障害がある。たとえば日本の通商産
業省のホームページはMinistryofInternationalTradeandIndust
ryの略であるMITIを用いてhttp://www.miti.go.jp/となっているが，
果たして通商産業省からmitiを想像することのできるユーザがどれほ
どいるであろうか。また，首相官邸のホームページはhttp://www.kan
tei.go.jp/と，今度は「官邸」をローマ字で表したＵＲＬが用いられ
ている。このように，会社名，団体名，組織名，法人名，個人名，商
品名，サービス名称，地名といったユーザになじみのある名称を元に
ＵＲＬが決められているのではないため，目的の情報資源へたどりつ
くためには「ｙａｈｏｏ」や「ｇｏｏ」といった検索エンジンに頼ら
ざるを得ない状況となっている。」
・「【００１９】まず，図１の説明図によりクライアント側のＷＷＷ
ブラウザから文字列変換プログラムを介してインターネットへアクセ
スする方法を説明する。クライアント側のＷＷＷブラウザ１１のアド
レス欄に入力された文字列は，文字列変換プログラム１２によってＵ
ＲＬ変換データベース１３の中に入力された文字列と同一の文字列が
あるかが検査され，同一の文字列に対応するＵＲＬを取得し，取得さ
れたＵＲＬをもってインターネット１４へアクセスする。」
・「【００２０】前記文字列の入力には一般的なキーボードを用いる
他に，マウスやペン，タッチパネルといったポインティングデバイス
や，スキャナ，デジタルカメラ，ＯＣＲなどの光学的読みとり装置や，
テレビなどの操作に用いるリモコン類や，音声で入力する音声認識イ
ンターフェースなどを用いることができる。」
・「【００２１】前記文字列変換プログラムはクライアント側にイン
ストールする他に，ＬＡＮ環境などではサーバ側に置くことも可能で，
プロバイダ業者がユーザへのサービスとして本発明を利用するような
環境では，プロバイダ業者の管理するサーバ側に置くことも可能であ
る。」
・「【００２２】前記ＵＲＬ変換データベースは前記文字列変換プロ
グラムと同一の場所に置くことも可能な他，たとえば前記文字列変換
プログラムをクライアント側に置き，前記ＵＲＬ変換データベースを
サーバ側に置くことも可能である。」
・「【００２３】次に，図２と図３，図４の説明図によりクライアン
ト側のＷＷＷブラウザへの文字列入力からインターネットへのアクセ
スに至るまでの処理手順を説明する。」
・「【００２４】ユーザが前記入力手段で入力した文字列を，全角文
字や半角カタカナを含むか，あるいは図３のＵＲＬの構成に沿ったも
のであるかを調査し，全角文字や半角カタカナを含まず，かつ図３の
ＵＲＬの構成に沿ったものであれば入力された文字列をＵＲＬと見な
して変換せずにインターネットへの探査を行う。前記文字列はプロト
コル３１，ＤＮＳ３２，ディレクトリ３３，ファイル名３４のいずれ
にあっても抽出が可能で，または入力が前記文字列だけであっても抽
出が可能である。入力された文字列が図３のＵＲＬの構成に沿ったも
のでないか，全角文字や半角カタカナを含む場合は，入力された文字
列で図４のＵＲＬデータベースを検索し，一致するＵＲＬを取得して
インターネットへの探査を行う。図４のＵＲＬ変換データベースに一
致する文字列が見つからなければその旨のエラーメッセージを画面上
に表示する。」
(ｲ)以上の記載から，引用文献９に係る特許出願の願書に最初に添付した
明細書又は図面には次の発明（以下「先願発明９」という。）が記載さ
れている。
「クライアント側のＷＷＷブラウザ１１のアドレス欄にユーザは文字
列を入力し，
ユーザが入力手段で入力した文字列を，全角文字や半角カタカナを含
むか，あるいはＵＲＬの構成に沿ったものであるかを調査し，
全角文字や半角カタカナを含まず，かつＵＲＬの構成に沿ったもので
あれば入力された文字列をＵＲＬと見なして変換せずにインターネット
への探査を行い，
文字列はプロトコル３１，ＤＮＳ３２，ディレクトリ３３，ファイル
名３４のいずれにあっても抽出が可能で，または入力が前記文字列だけ
であっても抽出が可能であり，
入力された文字列がＵＲＬの構成に沿ったものでないか，全角文字や
半角カタカナを含む場合は，入力された文字列でＵＲＬデータベースを
検索し，一致するＵＲＬを取得してインターネットへの探査を行い，
ＵＲＬ変換データベースに一致する文字列が見つからなければその旨
のエラーメッセージを画面上に表示する，
インターネットへのアクセスシステム。」
イ対比・判断
本願発明１４と先願発明９とを対比する。
先願発明９において，ユーザはクライアント側のブラウザのアドレス欄
に文字列を入力しており，該文字列はアドレスとして扱われる点でＵＲＬ
に相当し，通常のＵＲＬを入力した時は文字列変換をしないでインターネ
ットへの探査を行うことは既存情報処理手段が作動することに相当し，ユ
ーザが入力したＵＲＬに全角文字や半角カタカナが含まれていたときは，
エラーが発生した時に相当し，ＵＲＬデータベースを検索する処理を行う
ことは外部情報処理手段へ処理を分岐させることに相当する。
よって，本願発明１４は先願発明９と実質的に同一の発明である。
(3)取消事由１及び２に対し
ア原告は，審決で表示された拒絶理由通知の「サーバの設定がエラーを
発生させるような状態に設定されていれば，エラーを誘発させ，サーバ
での処理を分岐させ，文字処理を行わせることに格別の困難性は認めら
れない。」（５頁１２行∼１４行）との認定は誤りであると主張する。
しかし，本願各発明におけるエラー発生は，ＵＲＬ処理において，漢字
等がＵＲＬに使用された場合に対する文字列処理を行わせるために，通常
のＵＲＬ処理から別処理に分岐させるための便法の一つとして採用したも
のであり，該分岐処理を行わせ得る手法であればエラー発生に限定される
ものではなく，エラー発生が不可欠といえるものではない。また，例えば
一般のサーバでの処理において，サーバの特定ファイルへのアクセスや特
定ユーザからのサーバへのアクセスを制限するようなケースは，通常の運
用において当然想定されるものであり，そのような制限に該当するならば，
あたかもそれをエラー発生のように取扱って通常の処理とは別の処理に移
行させ，それに応じてエラー頁を表示させるようにすることも運用上ごく
普通に行われていることであるから，エラーを発生させるような設定は必
要に応じて適宜に行われることである。そして，エラーを発生させるよう
な設定を行うことは，当然処理態様として通常処理とは別処理を行うこと
に他ならず，すなわちサーバでの処理が分岐処理となることは容易に首肯
し得る。
してみると，審決が拒絶理由通知を引用して「サーバの設定がエラーを
発生させるような状態に設定されていれば，エラーを誘発させ，サーバで
の処理を分岐させ，文字処理を行わせることに格別の困難性は認められな
い。」と認定したことに誤りはない。
イ原告は，ＷＷＷサーバとＷＷＷクライアントとの間の通信規約に定めら
れたルールの一部を引用して，ブラウザに表示させるＵＲＬに日本語を使
うことはできない旨主張する。
確かに，本願明細書（甲１０）の段落【００１６】に記載があるように，
雑誌(「日経コミュニケーション」第２６８号，１９９８年（平成１０
年）４月２０日発行，甲１５）の記事中に「ブラウザに表示させるＵＲＬ
に日本語を使うことはできません。」の記載があるが，本願明細書におい
て，続く段落【００１７】から段落【００１８】に記載されているように，
ＵＲＬ入力として漢字等を入力することは可能であるところ，入力した漢
字等がＵＲＬとして機能を果たすか否かに問題があり，上記雑誌の記事は，
それがＵＲＬとして機能を果たさないから「日本語を使うことはできませ
ん」としたまでのことで，日本語を使うこと自体が全く排除されていたわ
けではない。
してみると，審決が拒絶理由通知を引用して「一般にＷＷＷブラウザに
おいて，ＵＲＬパス部に漢字等の非アスキー文字を含むこと，または含ま
せることを排除するものではない。」と認定したことに誤りはない。
(4)取消事由３に対し
引用文献９(甲９）には，段落【００１９】に「クライアント側のＷＷＷ
ブラウザ１１のアドレス欄に入力された文字列は，文字列変換プログラム１
２によってＵＲＬ変換データベース１３の中に入力された文字列と同一の文
字列があるかが検査され，同一の文字列に対応するＵＲＬを取得し，取得さ
れたＵＲＬをもってインターネット１４へアクセスする。」，段落【００２
４】に「ユーザが前記入力手段で入力した文字列を，全角文字や半角カタカ
ナを含むか，あるいは図３のＵＲＬの構成に沿ったものであるかを調査し，
全角文字や半角カタカナを含まず，かつ図３のＵＲＬの構成に沿ったもので
あれば入力された文字列をＵＲＬと見なして変換せずにインターネットへの
探査を行う。」及び「入力された文字列が図３のＵＲＬの構成に沿ったもの
でないか，全角文字や半角カタカナを含む場合は，入力された文字列で図４
のＵＲＬデータベースを検索し，一致するＵＲＬを取得してインターネット
への探査を行う。」との記載があり，引用文献９においてブラウザに入力さ
れる文字列は半角英数字に限定されておらず，全角文字や半角カタカナを含
む文字列を入力でき，全角文字や半角カタカナを含む場合はＵＲＬデータベ
ースを検索することが記載されているものであるから，引用文献９において
プラグインについての検討をする必要はない。また，原告は，「本願発明で
は，ウェブブラウザ側には特殊な設定は不要で，クライアント側でのプラグ
インが不要である。」と主張しているが，上記主張は，本願の明細書及び図
面の記載に基づかない。
よって，原告の主張は理由がない。
(5)取消事由４に対し
引用文献８(甲８）の段落【０１０５】に記載されているように，クライ
アント側は入力された番号をウェブサーバに送る機能を有するものであるか
ら，引用文献８においてプラグインについての検討をする必要はないし，ま
た，クライアントからの入力が原告の主張するようなブラウザによるとして
も，日本語を入力することが排除されているわけではないので，原告の主張
は理由がない。
また，原告は，引用文献８が国際調査報告においてカテゴリーＡ相当の刊
行物であったと主張しているが，そのことが本件における拒絶査定のように，
進歩性を否定するための引例として引用文献８を引用することを拘束するも
のではない。国際調査報告の作成後に関連分野の技術水準や周知技術に関す
る知見を得ることにより，当該刊行物に対する評価が変化することは十分に
想定されることであり，国際調査報告時の評価がそのまま各国審査段階時の
評価に踏襲されるものではない。また，特許協力条約３３条に記載されてい
るように，国際予備審査は予備的かつ拘束力のない見解を示すものである。
(6)取消事由５に対し
本願明細書（甲１０）の段落【００１６】∼【００１８】に記載されてい
るように，WWWクライアントにおいて日本語を入力することが排除されてい
るわけではないし，引用文献４∼引用文献７（甲４∼７）に記載された文字
列処理や分岐処理は，いろいろな種類の文字を受け付けて処理する機能を有
するものであるから，プラグインの必要性についての検討を欠くとの原告の
主張は理由がない。
(7)取消事由６に対し
ア原告は，請求項１等に記載した「意図的に」は「わざと」と換言でき，
同様の表現を他の文献（甲１６）にも見ることができるから，難無く解釈
でき，不明確ではない旨主張する。
しかし，特許請求の範囲の記載は，この記載に基づいて特許発明の技術
的範囲が定められ，新規性・進歩性の特許要件等の判断がなされるという
点において重要な意義を有するものであり，一の請求項から発明が明確に
把握されることが必要であることはいうまでもないが，原告が主張するよ
うに，「意図的に」が「わざと」と同じ意味であることは分かるとしても，
「意図的に」あるいは「わざと」の表現を用いることで実現（具現）する
構成が不明確であり，技術的範囲も不明確である。
イ原告は，請求項１等に記載した「機能拡張装置」等における「機能拡
張」の技術的範囲が不明であるとの指摘は当たらない旨主張する。
しかし，「機能拡張装置」という以上，基となる装置に対して機能を
追加するものを意図していると理解するのが合理であるところ，単に
「機能拡張装置」のみでは，既存ＷＷＷサーバに対して追加する装置の
構成が既存のサーバの機能に対してどのような機能の拡張を特定するも
のであるのか不明であるから，請求項１等で使っている「機能拡張」の
技術的範囲が不明である。
ウ原告は，請求項３中の「固定的部位を何ら変更することなく備える」
が明確でないとの指摘は当たらない旨主張する。
しかし，本件明細書（甲１０）の段落【００３８】の記載を参酌する
と，「固定的部位」とは変更がなされない部位をいうと解される。その
ような「固定的部位」を「何ら変更することなく」とあえて修飾するこ
とは「固定的部位」が変更できることを想定していると解されることに
なり，明細書の記載と矛盾する。そうすると，そのような変更が可能な
「固定的部位」とは何を意図しているのか不明であるので，「・・・備
える」とする構成が不明確である。
エ原告は，「以外」の語の利用のみをもって明確でないとするのは当た
らない旨主張する。
しかし，請求項４，５中の「以外」を解釈する上において，原告が例
示する奇数と偶数のような二者択一の関係に帰着できるものではなく，
また，「どのような形式をもっても伝達されない箇所」の記載表現がど
こを指すのかも不明であるから，結局，請求項４，５中の「以外」なる
記載はどの範囲を指すのか不明である。
オ原告は，請求項６中の「用いる用途では含まない」が明確でないとの
指摘は当たらない旨主張する。
しかし，請求項６に記載された「ＣＧＩプログラム等へのパラメータ
伝達を指示するものであるとＲＦＣにより定義された文字列をその定義
の通りに用いる用途では含まない」における「ＣＧＩプログラム等への
パラメータ伝達を指示するものであるとＲＦＣにより定義された」は
「文字列を」にかかる。そして，「含まない」の目的語は「文字列を」
であるから，「文字列を」「含まない」と解釈できる。そうすると「含
まない」の直前部分は，通常は，何を含まないのかあるいはどこに含ま
ないのかを意味することになるが，直前部分には「その定義の通りに用
いる用途では」と記載されているから，どこに「含まない」のか不明で
ある。
カ原告は，請求項９中の「随時定義」は「予め定義されるのではない文
字列（静的ではないもの）」の言い換えであり，表現は明確である旨主
張する。
しかし，拒絶理由通知書（甲１１）における「具体的にどのような手
段によりどのように定義するのか明確でない」とは，装置内でどのよう
に随時に定義を設定しているのか不明であると指摘しているのであって，
随時定義の意味を不明確と指摘している訳ではない。
キ原告は，請求項９中の「同等に処理」の前後も含めた記載「予め定義
された・・・文字列を・・・特別の意味が設定されている文字列と同等
に処理する普通文字列特別解釈手段」の表現は明確であり，より具体的
な説明も記載済み（本願明細書段落【００８９】）であるから，「同
等」が明確でないとの指摘は当たらない旨主張する。
しかし，「同等」とは程度が同じという意味であり，同程度の処理の
意味とは何か（どのような内容の処理であるのか）が不明確である。
ク原告は，請求項１０中の「エラー誘発手段処理ステップ」なる記載が
明確でないとの指摘は当たらない旨主張する（請求項１２，１３中の
「エラー誘発設定ステップ」についても同様）。
しかし，請求項１０では，「エラー誘発手段処理ステップ」では手段
とステップが混在しており，両者の関係が不明であり，また，請求項１
２，１３の「エラー誘発設定ステップ」は「エラー誘発手段」との関係
が不明である。
ケ原告は，請求項１，２，７，９，１２，１３，１５中の「データ」な
る記載は，各請求項の記載及び対応する本願明細書の記載から明確であ
るから，明確でないとの指摘は当たらない旨主張する。
しかし，請求項１に記載された「WWWサーバが記憶手段に保持するデー
タのうち少なくともURLパス部を利用して処理を行う文字列処理手段」に
おいて，WWWサーバには多くの種類のデータが記憶されているところ，こ
この「データ」がどのようなデータを意味するのか不明確であるといわ
ざるを得ない。また，請求項２，１２，１３，１５も請求項１と同じ理
由により不明確であるといわざるを得ない。請求項７には「コンピュー
タ言語の命令やデータ」と記載されているところ，「コンピュータ言語
の」「データ」が演算の対象となるデータであるとすると，そのような
データにはあらゆる種類のデータが含まれるので，文字列処理を要しな
い普通のＵＲＬも含まれることになるから，発明が不明確であるといわ
ざるを得ない。請求項９の「データ」についても，請求項９が引用する
請求項４または５がさらに引用する請求項１または２に記載された「デ
ータ」が不明確であり，かつ，請求項１または２に記載された「デー
タ」と請求項９に記載された「データ」との関係が不明であるから，不
明確である。
コ原告は，「エラー」なる記載が明確でないとの指摘は当たらず，無用
の限定をする必要はない旨主張する。
しかし，拒絶理由通知書（甲１１）は，請求項１∼３，１０∼１５に
対して特許法３６条６項２号による記載不備を指摘した。この条文の趣
旨は，特許請求の範囲の記載は，特許権の権利範囲がこれによって確定
されるという点において重要な意義を有するものであるから，その記載
は明確でなければならないことにある。請求項１∼３，１０∼１５に記
載の「エラー」は一般的な用語にすぎないからから，特許法３６条６項
２号違反に当たると指摘したものである。
また，請求項１４，１５に対しては，特許法３６条６項１号による記
載不備も併せて指摘した。この条文の趣旨は，特許請求の範囲の記載に
は，発明の詳細な説明に記載の範囲を超えて記載してはならない旨を規
定したものである。請求項１４，１５には単に「エラーが発生した時
に」との記載があるが，「エラー」という語は一般的な用語であるから，
請求項１４，１５の記載では本願の明細書中に記載された意味での「エ
ラー」の範囲を超えるものを当該請求項に記載しているとして，特許法
３６条６項１号違反に当たると指摘した。
サ原告は，請求項２，１１中の「エラーの程度またはタイミング等を変
更するための条件変更手段」なる記載を非難するが，その指摘は当たら
ない旨主張する。
しかし，請求項２，１１に記載された「エラーの程度またはタイミン
グ等を変更するための条件変更手段」に対して，発明の詳細な説明には
「【００３５】請求項２の機能拡張装置は，どのようなURLパス部の到来
に対してエラーを誘発するのか（あるいは逆に誘発しないのか）やどの
ような時間帯にエラーを誘発するのか等の，エラーを誘発するための条
件を変更する条件変更手段を備えている。」と記載されているように，
請求項２，１１に記載された「条件変更手段」と詳細な説明に記載され
た「条件変更手段」とは対応していない。
シ原告は，請求項４，５中の「由来し」なる記載が明確でないとの指摘
は当たらず，「この＜○○側に由来し＞なる表現はWWW中継処理装置（２
０６)の存在を念頭に置いたものであり，記載済みである（本願明細書段
落【００４１】∼【００４３】および図２参照）。」と主張する。
しかし，原告が指摘する段落【００４１】∼【００４３】にも発明の
詳細な説明の他の箇所にも「由来し」という記載はなく，「由来し」が
どのようなことを意味するのか不明である。
ス原告は，請求項４，５中の「形式」なる記載が明確でないとの指摘は
当たらず，本願明細書段落【００４４】∼【００４６】に記載がある旨
主張する。
確かに，段落【００４４】には，「・・・たとえネットワーク（２０
８）中においてどのような表記形式で伝送されようとも文字列１と見た
目上（つまり印刷した際に）同一の文字列をWWWサーバにて獲得する獲得
手段を備えるとしている。」と記載されており，請求項４，５の「形
式」は一応「表記形式」のことと把握されるところ，請求項４には，
「・・・文字列処理手段はWWWサーバに対してどのような形式をもっても
伝達されない箇所以外は」とあり，常識的に考えて「表記形式」がどの
ような形式であっても伝達されない箇所があるような「表記形式」とは
何かが不明であるから，結局，請求項４の「形式」が「表記形式」に対
応するのかは不明である。
セ原告は，請求項５における「以外の方法」の前方の記載を含めるとその
表現は明確であって，記載が明確でないとの指摘は当たらない旨主張する。
しかし，「WWWクライアントのＵＲＬ入力表示欄で入力する方法」は明
確といえるが，それ「以外の方法」とは「ＵＲＬ入力表示欄で入力する」
以外のあらゆる方法と解されるから，技術的範囲が不明確である。そして，
特許法３６条６項１号の趣旨は先のとおりであるところ，本願発明の詳細
な説明には，「WWWクライアントのURL入力表示欄で入力する以外の方法」
として「telnet」と「プログラム」による例が挙がっているだけであり，
発明の詳細な説明に開示された内容を超えるような「以外の方法」という
あらゆることを含む技術的範囲までとすることは，特許法３６条６項１号
の趣旨に反することは明らかである。
ソ原告は，請求項９中の「少なくとも一方を備える」なる記載に関連して
「両方を備える場合」が明確でないとの指摘は当たらず，機能の異なる文
字列処理手段を複数多種準備してこれらを活用する点については，本願明
細書段落【００３６】，【００３７】，【００９６】に記載がある旨主張
する。
しかし，原告が指摘した箇所以外の発明の詳細な説明を参照しても，
「特別文字列普通解釈手段」と「普通文字列特別解釈手段」を備える場合
については記載されていない。
タ原告は，請求項２中の「（発生するエラーの程度または）タイミング等
（を変更するための条件変更手段）」について明確でないとの指摘は当た
らない旨主張する。
そこで，請求項２に記載された「タイミング等」について検討する。発
明の詳細な説明には「タイミング」という用語は記載されていない。類似
と思われる記載として発明の詳細な説明の段落【００３５】に「時間帯に
エラーを誘発する」との記載はあるが，「タイミング」を時間帯の意味で
用いられることは一般的ではないから，請求項２の「タイミング等」が何
を意味するのか不明確である。
次に「（ＣＧＩ）プログラム等」を検討する。「（ＣＧＩ）プログラム
等」について，発明の詳細な説明中にはそれに類する記載も示唆もないか
ら，「（CGI）プログラム等」に類するものが何であるのか不明である。
同様に「学術分野等」に関しても，「学術分野」に類する範囲として何
が含まれるのか不明である。この点につき，原告は，請求項７中の「（特
定の）学術分野等（で用いられる記号類）」について，本願明細書中の用
語「ＦｘＵＲＬ」で表現可能な「記号類」と記載，指定されている旨主張
するが，発明の詳細な説明を参酌しても「ＦｘＵＲＬ」で表現可能な「記
号類」の種類が何であるのか不明である。
第４当裁判所の判断
１請求原因(1)（特許庁における手続の経緯），(2)（発明の内容），(3)（審
決の内容）の各事実は，いずれも当事者間に争いがない。
ところで，原告のなした本件特許出願（本願）の特許請求の範囲は，前記の
とおり請求項１∼１５から成り，審決の内容・原告主張の取消事由・被告の反
論のいずれも，上記各請求項全般に亘ってなされているが，特許法３６条によ
れば，複数の請求項に亘るものであっても特許出願としては一個不可分のもの
であるから，出願に係る請求項１∼１５のうち一つでも特許法の定める要件を
満たさないものがあるときは，その余の請求項について判断するまでもなく，
当該特許出願全体が拒絶されるべきことになる。
そこで，被告が重点的に主張している本願請求項１４（本願発明１４）につ
いて，まず検討する。
２本願発明１４の進歩性（特許法２９条２項）の有無について
(1)本願発明１４の意義
ア本願明細書（甲１０）には，以下の記載がある。
・【請求項１】∼【請求項１５】
前記第３，１(2)記載のとおり。
・【発明の属する技術分野】
「この発明は，既存の情報処理手段の機能を拡張する装置，方法なら
びにこの方法を備えたプログラムに関し，特にWWWサーバにおけるURLの
解釈を柔軟に行うことによりURLの表現力や利用価値を高めることに関
する。」（段落【０００１】）
・【発明が解決しようとする課題】
「しかしながら，HTTPやURLの規約に準拠したこれまでのURL（このよ
うなURLを以降，『TrURL』（TraditionalURL）と言う。）ではURLパス
部に漢字等の全角文字を含むことができなかった。そのため，本当は○
×商会が図９のURL入力表示欄（９０１）に示す表現方法に代えて図１
０のURL入力表示欄（１００１），（１００７），（１００９）に示す
ような漢字，ひらがら，カタカナを含むURL（このようなURLを以降，
『KURL』（KanjiURL）と言う。）を用いたくてもできなかった（また
はできないと考えられていた）。（段落【００１５】）
・「少なくとも資料１（出典は後述）の雑誌の記事は，『ブラウザに表示
させるURLに日本語を使うことはできません。』としている。当該雑誌
の次号以降で訂正等がなされていないことを考え併せれば，これがイン
ターネット関連業界の標準的認識と考えてほぼ良いであろう。すべての
ブラウザがHTTPの規約どおり実装されていればこの記述は妥当である。
ところが実際の状況はやや異なる。」（段落【００１６】）
・「発明者が実験した範囲では，HTTPには反するかもしれないものの，開
発者またはバージョンが異なる２以上のブラウザにおいて，URL入力表
示欄（５０２）に漢字等を入力することは可能である。ただし，それ
（漢字等を含んだKURL）をWWWサーバに伝達する際の処理方法は異なっ
ている。」（段落【００１７】）
・「このため，通信するWWWクライアント（２０２）とWWWサーバ（２１
０）の双方が同一の漢字コード体系を用いているケースや下記のような
対処を行ったケースでは，KURLがあたかも正常に使えているように処理
することが可能である。」（段落【００１８】）
・「すなわち，（他の方法もあるかもしれないがここで説明するのは，）
利用されうる漢字コード体系の別をP，HTTPに基づくエンコード処理の
有無やエンコード処理後の文字列の相違の別をQとする時，P×Q=R通り
の表記によるファイルをディレクトリ領域（図８Ａ参照）に設定する；
という対処方法である。仮にP=3，Q=2とした場合，１のURLに対して６
のファイルを用意することになる。」（段落【００１９】）
・「ただし前記の方法には欠点がある。WWWサーバが動作しているコンピ
ュータにおけるOS（オペレーティングシステム）の種類によっては，特
定の漢字コード体系における特定の文字を含む場合は，対応するファイ
ルを設定できない可能性がある。それは──漢字等の全角文字は多くの
場合２バイト（１６ビット）が１文字に対応する。前記の方法では，外
見上は漢字等を用いたファイル名が設定できているように見えながら，
実は，２の１バイト文字（ここで『１バイト文字』は７ビットまたは８
ビットの空間を持つ文字コード集合。例えばASCIIコード。）をただ連
ねただけで（それ以外の配慮をせずに）１の全角文字を疑似的に実現し
ている場合がある。このような漢字処理方法においては，当該OSがファ
イル名には用いないとしている１バイト文字（例えばあるOSにおいては
「/」（スラッシュ））を含むような全角文字は正しく取り扱うことが
できないおそれがある。」（段落【００２０】）
・「仮に上記のような現象が発生する可能性が低いとしてこれを許容する
としても，１のURLに対して６のファイルを用意するのにはファイルの
設置や管理に手間が掛かる。それに，もしもKURLの処理方式の異なるブ
ラウザの数が増えてQ=5となった場合には，P=3のままとして，１のKURL
に対して１５ものファイルを用意しなければならない。PやQは将来の増
加の可能性があるので，このような場当たり的な対処方法は運用面で大
変手間の掛かる方法であると言える。しかも，上述したような不完全性
を備えている。」（段落【００２１】）
・「TrURLには漢字等の全角文字以外にも表記上の制限がある。まず，TrU
RLで使用可能な文字コード集合は最大でも７ビットの文字コード集合で
あるASCIIコードだけである。上述した全角文字を含め，２バイト以上
の領域を用いる日本語，韓国語，中国語等用の多バイトのコード体系は
使えない。ヨーロッパを中心に用いられている『ISO8859-1』なるコー
ド体系をはじめとする８ビット（１バイト）の文字コード集合も使えな
い。」（段落【００２２】）
・「TrURLには更に制限がある。ASCII文字コード集合のうち利用者側の意
志で自由に使えない文字（コード）が複数存在する。具体的には，
(1)『非図形文字』である文字群（１１０２），
(2)『Unsafe』である文字群（１１０４）
(3)『Reserved』である文字群（１１０６）
がある。正確な意味はURLに関するRFCを参照されたい。以下では例を用
いて説明する。（段落【００２３】）
・「そこでこの発明は，WWWクライアントからWWWサーバに伝達されたURL
の中のURLパス部を柔軟に解釈して多様な文字列処理をすることを可能
にすべく，既存のWWWサーバに取り付け可能な機能拡張装置および機能
拡張方法ならびに前記機能を備えた機能拡張プログラムを記録した記録
媒体を提供することを目的とする。」（段落【００３１】）
・【課題を解決するための手段】
「請求項１の機能拡張装置は，意図的にエラーの発生を誘うエラー
誘発手段を用いてURLに関する処理を既存のWWWサーバから既存のWWWサ
ーバ以外の処理手段である文字列処理手段（この文字列処理手段はこ
の発明により新規に用意する手段である。）へと移している。その際，
既存のWWWサーバが情報処理した結果として記憶された記憶手段の情報
を利用している。」（段落【００３２】）
・「これにより，既存のWWWサーバでは実現が困難であったURLパス部の柔
軟な解釈が可能となる。この発明の一実施形態による機能拡張手段等を
備えたWWWサーバの処理の流れを図１に示す。」（段落【００３３】）
・「この発明による機能拡張装置を利用するためには，対象となる装置が
(1)例外事象発生時の処理手段を呼び出す仕組みと(2)その処理手段とし
て所望のものを設定可能という２の条件を満たしていれば良い。たとえ
ば『CPU』は『WWWサーバ』ではないが，CPUはこれらの条件を満たして
いるものが多い。」（段落【００９７】）
・「このことを熟考すれば，請求項１が機能拡張の対象としている装置を
WWWサーバにのみ限定していることについて疑問が生じて来る。『この
限定を取り払うとどういうことになるのか？』発明者は自問自答し
た。」（段落【００９８】）
・「コンピュータのファイル等のデータを『資源』と捉えるならば，URL
はインターネットにおける資源の同定用文字列と言える。実際，『UR
L』の正式名称である『UniformResourceLocators』がそれを示してい
る。そして，資源の所在を指し示す文字列を『アドレッシング用文字
列』と呼び直してみると，(1)URLと並んでインターネットにおいて頻繁
に利用されている文字列である『電子メールアドレス』や(2)URLと電子
メールアドレスに共通の要素である『ドメイン名』等も『アドレッシン
グ用文字列』と言って良いだろう。」（段落【００９９】）
・「ここまで考えを進めるとこの発明は，アドレッシング用文字列を処理
するサーバ全般に適用できそうだとの推測が付く。具体的には，(1)電
子メールの配送等を行うための手段である電子メールサーバや，(2)ド
メイン名からIPアドレスを得るための（またはその逆の用途のための）
手段であるDNS(Domainnamesystem)サーバにも適用できそうなことが
推測できる。FTP(filetransferprotocol)サーバにも適用できるであ
ろう。すなわち，電子メールサーバ（『sendmail』という名称のプログ
ラムが有名である。）を例に採れば，次のような請求項を設けることが
可能である。」（段落【０１００】）
・「既存電子メールサーバが電子メールのアドレスを処理するに際して意
図的にエラーを誘発するエラー誘発手段と，前記既存電子メールサーバ
が記憶手段に記憶させたデータのうち少なくとも電子メールアドレスの
ユーザID部を利用して処理を行う文字列処理手段と，前記エラー誘発に
よりエラーが発生した時に前記既存電子メールサーバから前記文字列処
理手段へと処理を分岐させる分岐手段とから成る機能拡張装置。」（段
落【０１０１】）
・「更に考えを推し進めれば，この発明は，インターネット以外の領域に
も適用できそうなことが推測できる。例えば，電話通信網における電話
番号に基づく回線交換システムにも適用可能であろう。」（段落【０１
０２】）
・「このように考えるうちに，これらの適用可能な用途をすべて個別に列
記して請求項として記述する方法では限界があると発明者は考えた。そ
こでこの発明の本質を抽出し，新たな請求項とした。それが請求項１０
と請求項１１である。」（段落【０１０３】）
・「発明者が更に考えを推し進めたところ，エラー誘発手段は必ずしも機
能拡張装置の構成要素として含まれる必要はないであろうとの知見を得
たため，請求項１４としてこの発明を記述した。また，請求項１４にお
ける『既存情報処理手段』をWWWサーバに限定した場合の発明を請求項
１５として記述した。」（段落【０１０８】）
・「図７に示した各部を備えた処理手段をCPU（１７０６）を用いた装置
のハードウェア構成の一例を図１７に示す。なお，図７に示した各部分
の全部または一部はCPUを用いずにハードウェアロジックにより構成し
てもよい。」（段落【０１７９】）
・「図１７において，CPU（１７０６）には，ネットワークインターフェ
ース（１７０２），メモリ（１７０８），ディスプレイ（１７１０），
キーボード（１７１２），CD-ROMドライブ（１７１６），ハードディス
ク（１７１８）が接続されている。」（段落【０１８０】）
・「ハードディスク（１７１８）には，OS（１７２０），WWWサーバ装置
に必須のプログラムであるhttpdプログラム（１７２２），httpdプログ
ラムが動作中に各種設定情報や変数等が格納されるhttpdプログラム用
ワークエリア（１７２４），httpdプログラムがWWWクライアントからの
HTTPリクエストに応じて随時提供する情報等を格納した公開用ファイル
（１７２６）が記憶されている。これらがWWWサーバの基本的要素であ
る。」（段落【０１８１】）
・「ハードディスク（１７１８）にはまた，この発明を用いたWWWサーバ
にだけ存在する機能拡張プログラム（１７２８）と機能拡張プログラム
用ワークエリア（１７３０）も記憶されている。これがWWWサーバの拡
張的要素である。」（段落【０１８２】）
・「加えてこの発明を実施するWWWサーバのうち請求項２を満たすものは，
分岐先情報保持部（７０４）の内容を変更するための手段として条件変
更部（７０８）を備える。条件変更部（７０８）は前記アクセスコント
ロールファイルまたは同等機能を提供するファイル等における分岐先情
報保持部（７０４）またはこれに相当する箇所を修正するためのもので
ある。」（【０１９９】）
・【発明の効果】
「これまでに説明から明らかなように，WWWサーバにおけるURLの解釈
を柔軟に行うことによりURLの表現力や利用価値を大幅に高めることが
できる。同時に，インターネットのサービスを利用する際の障壁を下げ
る効果もある。これらの相乗効果により現在のインターネット利用者に
も将来のインターネット利用者にもメリットをもたらすサービスが提供
可能である。また，WWWサーバ以外にも応用可能であるため多分野に渡
り効果を得ることができる。」（段落【０２０１】）
・【図１】（この発明の一実施形態による機能拡張手段等を備えたＷＷＷ
サーバの処理の流れを示す図）
・【図７】（この発明の一実施形態による機能拡張手段等を備えたＷＷＷ
サーバの構成要素を示すブロック図）
・【図１７】（この発明の一実施形態による機能拡張手段等を備えたＷＷ
Ｗサーバ処理装置の構成要素を示す図）
イ上記記載によれば，本願発明１∼９，１２，１３，１５はインターネッ
トにおけるウェブサイトの閲覧におけるＵＲＬの処理に関するものであり，
半角英数字のみならず，漢字，ひらがな等の全角文字を含ませることによ
り，ＵＲＬの表現力や利用価値を高めるとともにインターネットサービス
を利用する際の障壁を下げることを目的とし，その解決手段として，従来
のＷＷＷサーバに文字列処理手段等を備えた機能拡張装置を備えるもので
あり，本願発明１０，１１，１４はこれをインターネット以外の領域にま
で広げた上，本願発明１４は意図的なエラー誘発手段を構成要素としない
発明であることが認められる。
(2)引用発明１の意義
ア引用文献１(甲１）には，以下の記載がある。
(ｱ)「インターネットやイントラネットでWWWサーバを立ち上げるには，H
TTPサーバであるhttpdを利用します．今回はhttpd（Apache）のインス
トールと活用について解説します．
httpd(HyperTextTranferProtocolDeamon)はハイパーテキスト
の転送を行うデーモン（すなわちサーバ）です．通常，NetscapeNavig
atorやInternetExprolerなどのブラウザからの要求を受けて，ホーム
ページのＨＴＭＬファイルなどを転送したりＣＧＩスクリプトを実行さ
せたりします．」（１３４頁左欄１行∼１０行）
(ｲ)「現在主に使われているhttpdの１つにApacheがあります．これは，注１
NCSA版httpdの改良から始まったhttpdで，NCSAhttpdverl.3（および
verl.4）と完全互換であり，さらにさまざまな機能拡張などを施したも
のです．また，NCSAhttpdより高速なhttpdでもあります．
Apacheの特徴の１つにモジュールによる機能拡張があります．サー
バの機能をモジュールという形で与えることで，機能の追加／削除が
簡単に行えます．モジュール集はhttp://www.zyzzyva.com/server/mod
ule_registry/などから手に入ります．
今回は，このApacheをmake，インストールしてみることにしまし
た．」（１３４頁右欄３行∼１６行）
(ｳ)「apache_1.1.3.tar.gzをmake，インストールします．これはApach注２
eのサポートサイト（http://www.apache.org/）から入手できます．ま
た，日本語サイトhttp://apache.maizuru-ct.ac.jp/からミラーサイト
が辿れます．
まず，アーカイブを解くとapache_1.1.3/というディレクトリができ
ます．ここに必要なファイルがすべて入っています．適当なディレク
トリへ展開してください．筆者は/srcに展開しました．各ディレクト
リ構成は表１のようになっています．」（１３４頁右欄１８行∼１３
５頁左欄１２行）
(ｴ)「●表１ディレクトリ構成（apache_1.1.3/以下）
cgi-bin/ＣＧＩプログラム
conf/設定ファイル，最初はサンプルが入っている
htdocs/ＨＴＭＬのサンプルが入っている
icons/Fancylconで使うアイコンが入っている
logs/ログ
src/httpdのソースが入っている
support/サポートプログラム，最初はサポートプログラムの
ソースが入っている」（１３５頁左欄１行∼９行）
(ｵ)「apache_1.1.3/conf/以下のファイルを編集します．デフォルトでは，
サーバルートが/usr/1oca1/etc/httpd/以下になっているので，これ
らのファイルをディレクトリごとコピーします．
#cp-r/src/apache_1.1.3/??*/usr/local/etc/httpd/
設定ファイルを自分の環境にふさわしいように書き換えます．http
d.confとsrm.conf，そしてaccess.confの３つを設定すれば，WWWサ
ーバとして動作するようになります（それぞれ，表３のような役割
をもちます）．」（１３５頁右欄１７行∼２６行）
(ｶ)「●表３Apacheの設定ファイル
ファイル名役割見本ファイル
access.confアクセス制限についての設定access.conf-dist
httpd.confサーバの動作についての設定httpd.conf-dist
srm.conf各ディレクトリやファイル名についての設定srm.conf-di
st」
（１３６頁１行目∼５行）
(ｷ)１３８頁右欄からsrm.confの設定についての記載があり，１４０頁左
欄に「ScriptAlias」のタイトルで以下の記載がある。
「●ScriptAlias
ＣＧＩを置くディレクトリの別名を指定します。
ScriptAlias/cgi-bin//usr/Local/etc/httpd/cgi-bin/
また，１４０頁左欄から右欄に「ErrorDocument」のタイトルで以下
の記載がある。
「●ErrorDocument
エラードキュメントをカスタマイズできます．エラードキユメント
とは，誤ったＵＲＬを指定した場合などにクライアント上に表示され
るドキュメントのことです．ここでカスタマイズすると，他のサーバ
上にあるエラードキュメン卜を表示したり，ＣＧＩを使ったものを表
示させたりすることができるようになります．
エラードキュメントをプレーンテキストで表示するときには「”」
の後に続けて，表示したいテキストを記述します．ローカルのファイ
ルを表示させる場合には，そのファイルが存在するパスを絶対パスで
記述します．ローカルのＣＧＩの場合も同様に指定します．リモート
にあるファイルを表示させるには，そのファイルの存在するＵＲＬを
記述します．
ErrorDocument500"Theservermadeabooboo.
ErrorDocument404/missing.html
ErrorDocument404/cgi-bin/missing_handler.pl
ErrorDocument402http://other.server.com/subscription_info.htm
l｣
イ①上記(ｱ)，(ｲ)の記載から，「ＨＴＴＰサーバであるＡｐａｃｈｅ」は
通常「ブラウザからの要求を受けて，ホームページのＨＴＭＬファイルな
どを転送する」こと，②上記(ｳ)∼(ｷ)の記載から，cgi-binディレクトリ
等にＣＧＩプログラムを格納すること，③上記(ｳ)∼(ｷ)の記載から，
「誤ったＵＲＬを指定した場合」にクライアント上に表示されるエラード
キュメントをカスタマイズできること，具体的には「ＣＧＩを使った」も
のを表示させられること，④上記(ｱ)の記載から，ＨＴＴＰサーバ（Ａｐ
ａｃｈｅ）を利用する「ＷＷＷサーバ」が記載されていることを認めるこ
とができる。
そうすると，引用文献１には，以下の発明（引用発明１）が記載されて
いると認めることができる。
「ＨＴＴＰサーバであるＡｐａｃｈｅが，通常，ブラウザからの要求を
受けて，ホームページのＨＴＭＬファイルなどを転送し，
cgi-binディレクトリにはＣＧＩプログラムを格納し，
設定ファイルには，誤ったＵＲＬを指定した場合に，クライアント上
に表示されるエラードキュメントをカスタマイズして設定でき，
上記設定は，ＥｒｒｏｒＤｏｃｕｍｅｎｔに指定することで，ＣＧＩ
を使ったものを表示させることができるようにした，
ＷＷＷサーバ。」
(3)対比・判断
ア「ＨＴＴＰサーバであるＡｐａｃｈｅ」が，通常，ブラウザからの要求
を受けてホームページのＨＴＭＬファイルなどを転送することは，「既存
情報処理手段」が「情報処理」することに相当する。
引用発明１の「誤ったＵＲＬを指定した場合」は，「エラーが発生した
時」に相当する。
引用発明１で「誤ったＵＲＬを指定した場合」，ＣＧＩを使ったものを
表示させるためには，当然にErrorDocumentで指定されたＣＧＩプログラ
ムを実行しているものであって，このＣＧＩプログラムの実行はＨＴＴＰ
サーバであるＡｐａｃｈｅ(そのhttpdプログラム)とは別の情報処理手段
に処理を分岐させることに相当する。
また，ＣＧＩプログラムを実行させるのは，ＨＴＴＰサーバであるＡｐ
ａｃｈｅが誤ったＵＲＬの指定を検出した場合と解されるから，引用発明
１も既存情報処理手段における情報処理結果の一部または全部を利用して
いるといえる。
以上から，両者の一致点，相違点は次のとおりである。
＜一致点＞
「既存情報処理手段が情報処理するに際して前記既存情報処理手段に
おける情報処理結果の一部または全部を利用して処理を行う別の情報
処理手段と，エラーが発生した時に前記既存情報処理手段から別の情
報処理手段へと処理を分岐させる分岐手段とを備える装置」
＜相違点１＞
本願発明１４においては，既存情報処理手段に対して，その外に外部
情報処理手段があるのに対して，引用発明１では，既存情報処理手段に
相当するＷＷＷサーバが，別の情報処理手段に相当するＣＧＩプログラ
ムを備えている点。
＜相違点２＞
本願発明１４は「機能拡張装置」の発明であるのに対して，引用発明
１はＷＷＷサーバである点。
イ＜相違点１＞についての判断
誤ったＵＲＬを指定した場合に実行されるＣＧＩプログラムは，既存情
報処理手段であるＨＴＴＰサーバであるＡｐａｃｈｅ(そのhttpdプログラ
ム)によりその実行を制御される別のプログラムであって，エラードキュ
メントの表示に関して付加的な情報処理手段を構成しているから，既存情
報処理手段に対して外部情報処理手段といえるものである。
また，情報処理分野において，付加的な情報処理手段を既存の情報処理
手段に対して外部の情報処理手段として構成することは，何ら格別なこと
ではなく適宜の設計事項である。
よって，引用発明１のＣＧＩプログラムを既存情報処理手段に相当する
ＷＷＷサーバに対して外部情報処理手段として構成することは，当業者
（その発明の属する技術の分野における通常の知識を有する者）が容易に
想到し得ることである。
ウ＜相違点２＞についての判断
前記のとおり，引用発明１のＣＧＩプログラムは，ＨＴＴＰサーバであ
るＡｐａｃｈｅ(そのhttpdプログラム)に対して付加的な情報処理手段を
構成し，ＣＧＩプログラムに記述された処理を行い，所定の表示をする機
能を付加するものであるから，ＨＴＴＰサーバであるＡｐａｃｈｅ(そのh
ttpdプログラム)に対して機能を拡張しているといえる。よって，引用発
明１においてＣＧＩプログラムによる処理を行う構成は，本願発明１４の
機能拡張装置に相当するといえるものである。
エ以上によれば，本願発明１４は引用発明１から当業者が容易に想到する
ことができたものであると認めるのが相当である。したがって，本願発明
１４は引用発明１に基づいて当業者が容易に発明することができるとした
審決の判断に誤りはない。
(4)原告の主張に対する補足的判断
ア原告は，一般のサーバ運用者にとって，サーバのエラーを発生させるよ
うな状態に設定することへの動機はない旨主張するが（取消事由１），か
かる主張は「エラー誘発手段」の存在を前提とする主張であるところ，本
願発明１４には「エラー誘発手段」は存在しない。したがって，引用発明
１にエラーを発生させるような状態に設定することへの動機がないとして
も，引用発明１から本願発明１４を容易に想到できるか否かの判断に影響
を与えるものではないと解されるから，原告の上記主張は採用することが
できない。
なお，本願発明１∼１３との関係について付言すると，たしかに通常の
サーバの利用に対しては利用者に不便を与えないため，エラーは避けるの
が技術常識であると考えられる。
しかし，特開平１０−６３５９７号公報（発明の名称「クライアント側，
サーバ側および協調部で実行するＵＲＬのスペルチェック」，出願人サ
ンマイクロシステムズインコーポレイテッド，公開日平成１０年３月
６日。甲６）の段落【００１８】，【００５２】及び図１１には，「隠し
ファイル」のＵＲＬと類似のＵＲＬが入力され，この類似のＵＲＬのスペ
ルミスを自動修正した結果「隠しファイル」のＵＲＬと一致してしまう場
合には，最初から正しい隠しファイルのＵＲＬを入力できた利用者だけに，
隠しファイルを表示させるためＵＲＬの自動修正機能をキャンセルし，そ
の結果，スペル修正の候補がなくなれば「文書が見つかりません」のエラ
ーメッセージを表示すること（ステップ１１１５）が記載されており，本
願の出願当時（平成１０年６月２６日），セキュリティ上，意図的にエラ
ーを発生させる場合があることが認められる。
また，引用文献７（乙１）の１欄５０∼５７行（訳文２頁１６∼２１
行），１７欄２４∼２７行（訳文２３頁１４∼１６行），１８欄２６行∼
３０行（訳文２４頁２３行∼２６行）の記載によれば，キオスク端末から
のネット接続に関して，ユーザの独り占めを防ぐため，閲覧するコンテン
ツの制限に加え閲覧時間も制限すること，ある時間が超過したらユーザが
希望した情報を表示することに代えて，所定の警告メッセージを表示し，
ＨＴＭＬ文書を書き直してリンクを不能にすることが記載されているとこ
ろ，このような利用時間を超過した場合の警告表示等は，意図的なエラー
発生と同視できる。
そうすると，本願出願当時（平成１０年６月２６日），不適切なサーバ
の利用に対しては，サーバやサーバ上のデータを保護する観点からエラー
を意図的に発生させるべき場合があることが認識されていたことが認めら
れ，引用発明１にエラーを発生させる動機付けがないとはいえない。
したがって，サーバの設定がエラーを発生させるような状態に設定され
ていれば，エラーを誘発させ，サーバでの処理を分岐させ，文字列処理を
行わせることに格別の困難性は認められないとした審決の判断に誤りがあ
るということはできない。
イ次に原告は，取消事由２として，ＷＷＷサーバとＷＷＷクライアントと
の間の通信規約に定められたルールの一部を引用して，ブラウザに表示さ
せるＵＲＬに日本語を使うことはできない旨主張する。
しかし，原告の上記主張は請求項６∼９に関するものであるところ，上
記のとおり，請求項１に進歩性が認められない以上，取消事由２を検討す
るまでもなく，これに従属する請求項６∼９にも進歩性は認められない。
３本願発明１４の先願発明との実質的同一性（特許法２９条の２）の有無につ
いて
審理の経緯に鑑み，本願発明１４の先願発明との実質的同一性（特許法２９
条の２）の有無について（取消事由３）も検討する。
(1)先願発明９の意義
ア引用文献９（甲９）には，以下の記載がある。
・【請求項１】
「インターネット上に置かれている情報提供サーバに蓄積された情報
資源をアクセスするためのＵＲＬを用いたインターネットへのアクセス
方法であって，予めＵＲＬに対応する任意の文字列を割り当て，この割
り当てられた文字列をクライアント側のインターネットへのアクセス機
器から入力し，この入力された文字列をクライアント側またはサーバ側
の文字列変換プログラムによって，割り当てられた文字列とＵＲＬとの
対応関係を示す記憶テーブルを用いてＵＲＬに変換し，この変換された
ＵＲＬでインターネット上の探査を行い，該当するデータをクライアン
ト側の画面上に表示または記憶装置に取得することを特徴とするインタ
ーネットへのアクセス方法。」
・【発明の詳細な説明】
「ところが，このＵＲＬの入力はユーザにとっては思わぬ障害となっ
ている。その理由はＵＲＬを構成する文字列が長く，しかも複雑な仕組
みを持つことである。たとえばＡ株式会社のＵＲＬはそのホームページ
がどの管理下にあるかでhttp://www.a.co.jp/，http://www.a.com/，ht
tp://www.x.or.jp/a/，http://www.x.ne.jp/a/，http://www2.x.or.jp/
a/，http://a.x.or.jp/のように変わり，その組み合わせは無限といえ
るほどである。このような複雑な仕組みを持つＵＲＬは入力を１字間違
えただけでアクセスできず，しかも間違いの原因や箇所などを指摘する
手段もないため，コンピュータやインターネットに精通したユーザ以外
の利用は困難を極めている。」（段落【０００４】）
・「さらに，ＵＲＬを構成する文字列は半角の英数字であるため，日本語
をローマ字や英語で表さなければならないが，その際にもユーザにとっ
て次のような障害がある。たとえば日本の通商産業省のホームページは
MinistryofInternationalTradeandIndustryの略であるMITIを用い
てhttp://www.miti.go.jp/となっているが，果たして通商産業省からmi
tiを想像することのできるユーザがどれほどいるであろうか。また，首
相官邸のホームページはhttp://www.kantei.go.jp/と，今度は「官邸」
をローマ字で表したＵＲＬが用いられている。このように，会社名，団
体名，組織名，法人名，個人名，商品名，サービス名称，地名といった
ユーザになじみのある名称を元にＵＲＬが決められているのではないた
め，目的の情報資源へたどりつくためには「ｙａｈｏｏ」や「ｇｏｏ」
といった検索エンジンに頼らざるを得ない状況となっている。」（段落
【０００５】）
・「そこで，本発明の目的は，１回の入力に対して必ず唯一の結果を検索
可能とし，かつキーボードに不慣れなユーザに長く複雑な文字列のＵＲ
Ｌを意識させることなく，このＵＲＬに対応する会社名，団体名，組合
名，個人名，商品名，サービス名称，地名，電話番号あるいは任意の文
字列を入力するだけでインターネットにアクセスすることができるイン
ターネットへのアクセス技術を提供することにある。」（段落【０００
９】）
・「まず，図１の説明図によりクライアント側のＷＷＷブラウザから文字
列変換プログラムを介してインターネットへアクセスする方法を説明す
る。クライアント側のＷＷＷブラウザ１１のアドレス欄に入力された文
字列は，文字列変換プログラム１２によってＵＲＬ変換データベース１
３の中に入力された文字列と同一の文字列があるかが検査され，同一の
文字列に対応するＵＲＬを取得し，取得されたＵＲＬをもってインター
ネット１４へアクセスする。」（段落【００１９】）
・「前記文字列の入力には一般的なキーボードを用いる他に，マウスやペ
ン，タッチパネルといったポインティングデバイスや，スキャナ，デジ
タルカメラ，ＯＣＲなどの光学的読みとり装置や，テレビなどの操作に
用いるリモコン類や，音声で入力する音声認識インターフェースなどを
用いることができる。」（段落【００２０】）
・「前記文字列変換プログラムはクライアント側にインストールする他に，
ＬＡＮ環境などではサーバ側に置くことも可能で，プロバイダ業者がユ
ーザへのサービスとして本発明を利用するような環境では，プロバイダ
業者の管理するサーバ側に置くことも可能である。」（段落【００２
１】）
・「前記ＵＲＬ変換データベースは前記文字列変換プログラムと同一の
場所に置くことも可能な他，たとえば前記文字列変換プログラムをクラ
イアント側に置き，前記ＵＲＬ変換データベースをサーバ側に置くこと
も可能である。」(段落【００２２】)
・「次に，図２と図３，図４の説明図によりクライアント側のＷＷＷブラ
ウザへの文字列入力からインターネットへのアクセスに至るまでの処理
手順を説明する。」（段落【００２３】）
・「ユーザが前記入力手段で入力した文字列を，全角文字や半角カタカナ
を含むか，あるいは図３のＵＲＬの構成に沿ったものであるかを調査し，
全角文字や半角カタカナを含まず，かつ図３のＵＲＬの構成に沿ったも
のであれば入力された文字列をＵＲＬと見なして変換せずにインターネ
ットへの探査を行う。前記文字列はプロトコル３１，ＤＮＳ３２，ディ
レクトリ３３，ファイル名３４のいずれにあっても抽出が可能で，また
は入力が前記文字列だけであっても抽出が可能である。入力された文字
列が図３のＵＲＬの構成に沿ったものでないか，全角文字や半角カタカ
ナを含む場合は，入力された文字列で図４のＵＲＬデータベースを検索
し，一致するＵＲＬを取得してインターネットへの探査を行う。図４の
ＵＲＬ変換データベースに一致する文字列が見つからなければその旨の
エラーメッセージを画面上に表示する。」（段落【００２４】）
・「ユーザがクライアント側のインターネットへのアクセス機器から入力
した文字列を，任意の長さの漢字４１，任意の長さのかな４２，任意の
長さの英字４３の順に検索し，一致する場合は任意の長さのＵＲＬ４４
を得てインターネットの探査を行う。このデータベース構成を格納する
媒体は，クライアント側のハードディスクの他に，高速な検索を可能に
するためのキャッシュとしてクライアント側のメモリーに持つことも可
能で，さらに大量のデータを扱うためにCD-ROMやサーバ側のハードディ
スクに持つことも可能である。」（段落【００２６】）
・【図１】（本発明の実施の形態であるインターネットへのアクセス方
法において，クライアント側のＷＷＷブラウザから文字列変換プロ
グラムを介してインターネットへアクセスする方法を示す説明図）
・【図２】（本発明の実施の形態であるインターネットへのアクセス方法
において，クライアント側のＷＷＷブラウザへの文字列入力からイン
ターネットへのアクセスに至るまでの処理手順を示すフロー図）
・【図３】（本発明の実施の形態であるインターネットへのアクセス方法
において，ＵＲＬの構成を示す説明図）
イ上記記載から，引用文献９は，半角英数字であるＵＲＬに対応するユー
ザになじみのある文字列を用いたインターネットへのアクセス技術を提供
することを目的とするものであることが認められる。そして，同文献９に
おいて，「ＷＷＷブラウザに入力された文字列」を利用して「サーバ側」
のデータベースを用いて検索を行うことは，「既存情報処理手段における
情報処理結果の一部または全部」を利用して「前記既存情報処理手段の
外」で「処理」を行うことに相当する。また，同文献９における「入力さ
れた文字列が全角文字や半角カタカナを含む場合」（図２のステップ２２
（No），２３（Yes)の分岐）に「データベース検索」を行うことは，入力
された文字列がＵＲＬとして通常想定される半角英数字と異なる文字列を
含む時の処理であって，データベースに一致する文字列が見つからなけれ
ば「エラー」メッセージを表示する（図２のステップ２６）ものであるか
ら，「エラーが発生した時」に「外部情報処理手段へと処理を分岐させ
る」ことに相当する。また，「データベース検索」という機能拡張をする
ものである。
そうすると引用文献９には次の発明（引用発明９）が記載されているこ
とが認められる。
「クライアント側のＷＷＷブラウザ１１のアドレス欄に，ユーザが入力
手段で入力した文字列を，全角文字や半角カタカナを含むか，あるいは
ＵＲＬの構成に沿ったものであるかを調査し，
全角文字や半角カタカナを含まず，かつＵＲＬの構成に沿ったもので
ある場合，入力された文字列をＵＲＬと見なして変換せずにインターネ
ットへの探査を行い，
入力された文字列がＵＲＬの構成に沿ったものでないか，全角文字や
半角カタカナを含む場合，入力された文字列でＵＲＬデータベースを検
索し，一致するＵＲＬを取得してインターネットへの探査を行い，
ＵＲＬ変換データベースに一致する文字列が見つからなければその旨
のエラーメッセージを画面上に表示する，
インターネットへのアクセスシステム。」
(2)対比・判断
上記のとおり，先願発明９は，ブラウザに入力された文字列がＵＲＬと見
なせる場合，入力された文字列を変換せずインターネットを探索する処理を
行うものであり，この場合にインターネット上に置かれている情報提供サー
バに蓄積された情報資源をアクセスするための一連の動作は，既存情報処理
手段による情報処理に相当する。一方，ブラウザに入力された文字列がＵＲ
Ｌと見なせない場合，入力された文字列でＵＲＬ変換データベースを検索し
て一致するＵＲＬを取得し，もし一致する文字列がなければエラーメッセー
ジを表示するものであり，入力された文字列がＵＲＬの構成に沿ったもので
ないか，全角文字や半角カタカナを含む場合は「エラーが発生した時」に相
当し，その際ＵＲＬ変換データベースを検索する処理を行うことは，既存情
報処理手段における情報処理結果の一部又は全部を利用して既存情報処理手
段とは別の情報処理手段へ処理を分岐さた上，「ＵＲＬデータベース検索」
という機能拡張をして処理を行うことに相当する。
したがって，本願発明は，引用発明２と実質的に同一の発明である。
(3)原告の主張に対する補足的判断
ア原告は，引用文献９（甲９）には「ＵＲＬを構成する文字列は半角の
英数字であるため，日本語をローマ字や英語で表さなければならない」
（段落【０００５】）と記載されていることを根拠に，本願発明１４と
先願発明９は同一の発明ではないと主張する。
しかし，引用文献９の上記記載は先願発明９が解決しようとする課題の
一部であって先願発明の内容自体に関するものではない。そして，「・・
・入力された文字列が図３のＵＲＬの構成に沿ったものでないか，全角文
字や半角カタカナを含む場合は，入力された文字列で図４のＵＲＬデータ
ベースを検索し，一致するＵＲＬを取得してインターネットへの探査を行
う。・・・」（段落【００２４】）と記載されていることからすれば，ブ
ラウザに入力される文字列は半角英数文字に限定されないことが認められ
る。
したがって，原告の上記主張は引用文献９を正解しないものであり，採
用することができない。
イ次に，原告は，引用文献９の段落【００２４】の１行∼５行目の記載に
よれば，引用文献９では，全角文字や半角カタカナを含む文字列をＵＲＬ
とみなしておらず，これと反対の立場に立つ本願発明１，１０，１２∼１
５とは異なると主張する。
しかし，全角文字等を含む文字列を「ＵＲＬ」に含むか否かは，何を
「ＵＲＬ」とするかの「定義」の相違にすぎない。そして，前記のとおり，
先願発明９は，「ＵＲＬ」に該当しない全角文字等であっても，ＵＲＬに
変換することにより処理できるものであってインターネットにアクセスで
きることを内容とする発明である。原告の上記主張は採用することができ
ない。
ウ次に，原告は，引用文献９の段落【００１８】の記載によれば，先願発
明９では「クライアント側」において「文字列変換プログラムを介」する
必要があるが，本願発明１，１０，１２∼１５では不要であると主張する。
しかし，原告が指摘する段落【００１８】の記載及び図１には，文字列
変換プログラムの位置が「クライアント側」との記載は存在せず，むしろ，
請求項１及び段落【００２１】には，文字列変換プログラムを「サーバ
側」に設置できることが記載されている。よって，原告の上記主張はその
前提において採用することができない。そもそも請求項１４に各手段の位
置は記載がなく，原告の主張は請求項の記載に基づかない主張である。
エ次に，原告は，文字列変換プログラム（一般に「プラグイン」と称され
る。）をサーバ側に置く場合でも，処理対象文字列をクライアント側での
普通の取扱いを変更してクライアント側からサーバ側へと伝達する，いわ
ば「無変換パススループログラム」（プラグインの一種といえる。）を介
する必要がある点に留意する必要があると主張する。
しかし，引用文献９に「プラグイン」の用語自体の記載はなく，当然に
プラグインが必要であることの記載もない。むしろ，段落【００２４】の
記載によれば，ブラウザに半角英数字以外を入力できるから，プラグイン
の検討は不要である。一方，本願の請求項１４にプラグインを用いないこ
との記載はない。むしろ，本願明細書の段落【００６９】に，ビジュアル
ＵＲＬ（ＶＵＲＬ）と呼ばれる点字や画像データをＵＲＬに含ませる実施
例についての記載ではあるが，ブラウザ側で「プラグイン」を利用する記
載があると認められる。よって，「プラグイン」の利用の有無は，本願発
明との相違点となり得ず，原告の上記主張は採用することができない。
４結論
以上によれば，その余について判断するまでもなく，請求不成立とした審決
の結論に誤りはない。
よって，原告の請求を棄却することとして，主文のとおり判決する。
知的財産高等裁判所第２部
裁判長裁判官中野哲弘
裁判官今井弘晃
裁判官真辺朋子

戻る