平成21年 (行ケ) 10068号審決取消請求事件

運営：アスタミューゼ株式会社

会員機能

判例データベース

審決データベース

ポートフォリオ機能

ポートフォリオを新規に作成して保存		追加
既存のポートフォリオに追加保存		追加

関連審決	不服2005-8203

この判例には、下記の判例・審決が関連していると思われます。

審判番号（事件番号）	データベース	権利
平成21行ケ10432審決取消請求事件	判例	特許
平成21行ケ10158審決取消請求事件	判例	特許
平成21行ケ10434審決取消請求事件	判例	特許
平成21行ケ10253審決取消請求事件	判例	特許
平成21行ケ10033審決取消請求事件	判例	特許

この判例の個人情報、企業機密に関する修正依頼をする

関連ワード	発明者 / 新規性 / インターネット / アクセス / 進歩性(29条2項) / 容易に発明 / 周知技術 / 29条の2(拡大された先願の地位) / 実質的同一 / 技術的範囲 / 同一の発明 / 技術常識 / 発明の詳細な説明 / 発明が明確 / 発明が不明確 / 実質的に同一 / 警告 / クレーム / 参酌 / 実質的同一性 / 容易に想到(容易想到性) / 特許発明 / 実施 / 交換 / 発明の範囲 / 拒絶査定 / 拒絶理由通知 / 請求の範囲 / 拡張 / 変更 / 特許協力条約 / 国際調査 / 国際予備審査 /

関連ワード

発明者 / 新規性 / インターネット / アクセス / 進歩性(29条2項) / 容易に発明 / 周知技術 / 29条の2(拡大された先願の地位) / 実質的同一 / 技術的範囲 / 同一の発明 / 技術常識 / 発明の詳細な説明 / 発明が明確 / 発明が不明確 / 実質的に同一 / 警告 / クレーム / 参酌 / 実質的同一性 / 容易に想到(容易想到性) / 特許発明 / 実施 / 交換 / 発明の範囲 / 拒絶査定 / 拒絶理由通知 / 請求の範囲 / 拡張 / 変更 / 特許協力条約 / 国際調査 / 国際予備審査 /

元本PDF	裁判所収録の全文PDFを見る

事件	平成 21年 (行ケ) 10068号審決取消請求事件
事件	原告有限会社バリアフリー被告特許庁長官指定代理人江嶋清仁同近藤聡同岩崎伸二同田村正明
裁判所	知的財産高等裁判所
判決言渡日	2010/03/08
権利種別	特許権
訴訟類型	行政訴訟
主文	１原告の請求を棄却する。２訴訟費用は原告の負担とする。

事実及び理由
全容第1請求特許庁が不服2005-8203号事件について平成21年1月26日にした審決を取り消す。第2事案の概要本件は,原告が名称を「機能拡張装置および機能拡張方法ならびに機能拡張プログラムを記録した記録媒体」とする発明につき平成10年6月26日付けで特許出願をしたところ,拒絶査定を受けたので,これを不服として審判請求をしたが,特許庁から請求不成立の審決を受けたことから,その取消しを求めた事案である。第3当事者の主張1請求の原因(1)特許庁における手続の経緯原告は,平成10年6月26日,名称を「機能拡張装置および機能拡張方法ならびに機能拡張プログラムを記録した記録媒体」とする発明について特許出願(特願平10-195108号,請求項の数15,以下「本願」という。公開公報は特開2000-20444号〔甲10〕)をしたが,特許庁から拒絶査定を受けたので,これに対する不服の審判請求をした。特許庁は,同請求を不服2005-8203号事件として審理した上,平成21年1月26日,「本件審判の請求は,成り立たない。」との審決をし,その謄本は同年2月14日原告に送達された。 (2)発明の内容本願の内容は,以下のとおりである。・【請求項1】既存WWWサーバがURLを処理するに際して意図的にエラーを誘発するエラー誘発手段と,前記既存WWWサーバが記憶手段に保持するデータのうち少なくともURLパス部を利用して処理を行う文字列処理手段と,前記エラー誘発手段によりエラーが発生した時に前記既存WWWサーバから前記文字列処理手段へと処理を分岐させる分岐手段とを備える機能拡張装置。・【請求項2】既存WWWサーバがURLを処理するに際して意図的にエラーを誘発するエラー誘発手段と,前記既存WWWサーバが記憶手段に保持するデータのうち少なくともURLパス部を利用して処理を行う文字列処理手段と,前記エラー誘発手段によりエラーが発生した時に前記既存WWWサーバから前記文字列処理手段へと処理を分岐させる分岐手段とを備える機能拡張装置であって,前記エラー誘発手段により発生するエラーの程度またはタイミング等を変更するための条件変更手段を備える機能拡張装置。・【請求項3】前記エラー誘発手段,前記文字列処理手段,ならびに前記分岐手段のうちの1または2以上の手段を,前記既存WWWサーバの固定的部位を何ら変更することなく備える請求項1または請求項2記載の機能拡張装置。・【請求項4】前記URLパス部を含むURLは,WWWクライアントのURL入力表示欄で入力されたクライアント側入力文字列に由来し,前記文字列処理手段はWWWサーバに対してどのような形式をもっても伝達されない箇所以外は前記クライアント側入力文字列が入力された形式の表記にて獲得する獲得手段を備える請求項1または請求項2記載の機能拡張装置。・【請求項5】前記URLパス部を含むURLは,WWWクライアントのURL入力表示欄で入力する以外の方法で入力されたまたは設定されたクライアント側入力文字列に由来し,前記文字列処理手段はWWWサーバに対してどのような形式をもっても伝達されない箇所以外は前記クライアント側入力文字列が入力された形式の表記にて獲得する獲得手段を備える請求項1または請求項2記載の機能拡張装置。・【請求項6】前記URLパス部は漢字,ひらがなまたはカタカナを含み,CGIプログラム等へのパラメータ伝達を指示するものであるとRFCにより定義された文字列をその定義の通りに用いる用途では含まない請求項4または請求項5記載の機能拡張装置。・【請求項7】前記URLパス部は(1)日本語や他の国または地域の言語の語句を含むか,(2)特定の学術分野等で用いられている記号類を用いた表記を含むか,または,(3)コンピュータ言語の命令やデータを含むかのいずれかあるいはそれらの2以上の組合せである請求項4または請求項5記載の機能拡張装置。・【請求項8】前記URLパス部は検索を指示する文字列が含まれている請求項4または請求項5記載の機能拡張装置。・【請求項9】前記文字列処理手段は,(1)RFCにより特別の意味が設定されている文字列のうちの少なくとも1についてこれを本来の文字そのままのデータとして処理する特別文字列普通解釈手段か,または,(2)予め定義されたまたは随時定義する文字列をRFCにより特別の意味が設定されている文字列と同等に処理する普通文字列特別解釈手段のうちの少なくとも一方を備える請求項4または請求項5記載の機能拡張装置。・【請求項10】既存情報処理手段が情報処理するに際して意図的にエラーを誘発するエラー誘発手段処理ステップと,前記既存情報処理手段における情報処理結果の一部または全部を利用して前記既存情報処理手段の外で処理を行う外部情報処理手段と,前記エラー誘発手段によりエラーが発生した時に前記既存情報処理手段から外部情報処理手段へと処理を分岐させる分岐手段とを備える機能拡張装置。・【請求項11】前記エラー誘発手段により発生するエラーの程度またはタイミング等を変更するための条件変更手段を備えている請求項10記載の機能拡張装置。・【請求項12】既存WWWサーバがURLを処理するに際して意図的にエラーを誘発するエラー誘発設定ステップと,前記既存WWWサーバが記憶部に保持するデータのうち少なくともURLパス部を利用して処理を行う文字列処理ステップと,前記エラー誘発設定ステップによりエラーが発生した時に前記既存WWWサーバから前記文字列処理ステップへと処理を分岐させる分岐処理ステップとを備える機能拡張方法。・【請求項13】既存WWWサーバがURLを処理するに際して意図的にエラーを誘発するエラー誘発設定ステップと,前記既存WWWサーバが記憶部に保持するデータのうち少なくともURLパス部を利用して処理を行う文字列処理ステップと,前記エラー誘発設定ステップによりエラーが発生した時に前記既存WWWサーバから前記文字列処理ステップへと処理を分岐させる分岐処理ステップとを備える機能拡張プログラムを記録した記録媒体。・【請求項14】既存情報処理手段が情報処理するに際して前記既存情報処理手段における情報処理結果の一部または全部を利用して前記既存情報処理手段の外で処理を行う外部情報処理手段と,エラーが発生した時に前記既存情報処理手段から外部情報処理手段へと処理を分岐させる分岐手段とを備える機能拡張装置。・【請求項15】既存WWWサーバがURLを処理するに際して前記既存WWWサーバが記憶手段に保持するデータの一部または全部を利用して処理を行う文字列処理手段と,エラーが発生した時に前記既存WWWサーバから前記文字列処理手段へと処理を分岐させる分岐手段とを備える機能拡張装置。 (3)審決の内容審決の内容は,別添審決写しのとおりであり,審決で引用された拒絶理由は別添拒絶理由通知書写し(一部省略)のとおりである。その理由の要点は,本願の請求項1～15に係る発明は明確でない(特許法36条6項2号),請求項1～15に係る発明(本願各発明)は引用文献1～9に記載された発明との関係で進歩性を有しない(特許法29条2項),請求項1・10・12～15に記載された発明は引用文献9に記載された先願発明と実質的に同一である(特許法29条の2)等,である。記・引用文献1:下村昭彦「つこてなんぼのFｒeeBSD第4回」,株式会社技術評論社,SｏfｔｗaｒeDeｓign,第81号,134頁～145頁,1997年(平成9年)7月18日発行・引用文献2:豊福剛「Little Script Pages[3]」,株式会社翔泳社,DDJ Dｒ.Dｏbb’s Jｏｕｒnal Jaｐan,6巻10号127頁～134頁,1997年(平成9年)9月1日発行・引用文献3:特開平9-6667号公報(発明の名称「プロファイルおよびトピックを使用したハイパーテキストの情報検索」,出願人サン・マイクロシステムズ・インコーポレーテッド,公開日平成9年1月10日。)・引用文献4:特開平6-89304号公報(発明の名称「テキスト処理システムにより使用されるテキストを準備する方法及び装置」,出願人サン・マイクロシステムズ・インコーポレーテッド,公開日平成6年3月29日。)・引用文献5:特開平3-15980号公報(発明の名称「文字列検索のための異表記及び同義語展開方法」,出願人株式会社日立製作所,公開日平成3年1月24日。)・引用文献6:特開平10-63597号公報(発明の名称「クライアント側,サーバ側および協調部で実行するURLのスペルチェック」,出願人サンマイクロシステムズインコーポレイテッド,公開日平成10年3月6日。)・引用文献7:米国特許5761683号公報(発明の名称「TECHNIQUES FOR CHANGING THE BEHAVIOR OF A LINK IN A HYPERTEXT DOCUMENT〔ハイパーテキスト・ドキュメント中のリンクの動作を変更するための技術〕」,権利者 Microtouch Systems,Inc., 公報発行日 1996年〔平成8年〕2月13日。)・引用文献8:特開平10-78928号公報(発明の名称「インターネットへのアクセス方法およびシステム,ならびにインターネットへのアクセス処理を記憶した記憶媒体」,出願人ディアンドアイシステムズ株式会社,公開日平成10年3月24日。)・引用文献9:特開平11-328076号公報(特願平10-152031号の願書に最初に添付した明細書及び図面,発明の名称「インターネットへのアクセス方法およびシステム」,出願人株式会社アテックス,出願日平成10年5月14日,公開日平成11年11月30日。)(4)審決の取消事由しかしながら,審決には,以下に述べるとおり誤りがあるので,審決は違法として取り消されるべきである。ア取消事由1審決に表示された拒絶理由通知(甲11)は,「(理由4)進歩性」欄において,本願の請求項1,3,10,12～15に係る発明(以下「本願発明1,3,10,12～15」等という。)に関し,「・・・サーバの設定がエラーを発生させるような状態に設定されていれば,エラーを誘発させ,サーバでの処理を分岐させ,文字列処理を行わせることに格別の困静性は認められない。」(5頁12行～14行)とした。しかし,一般のサーバ運用者又はその管理者は,サーバのエラーをできるだけ発生させずに運用することを望むものであり,不本意にも発生してしまったエラーについては,エラーログを参照するなどしてその原因を発見・除去して正常化させる(リカバーする)とするのが一般の運用である。したがって,一般のサーバ運用者にとって,サーバのエラーを発生させるような状態に設定することへの動機はない。また,引用文献1及び引用文献2には,サーバエラー発生時のリカバーについての記載はあるが,その逆については記載はない。そして,サーバエラー発生時に既存のURLの処理をリカバーするのではなく,新たな発展的有効活用を図る処理を行うことは,視点を異にするものである。イ取消事由2審決に表示された拒絶理由通知(甲11)は,「(理由4)進歩性」欄において,本願発明6～9に関し,「一般にWWWブラウザにおいて,URLパス部に漢字等の非アスキー文字を含むこと,または,含ませることを排除するものではない。」(5頁31行～31行)とした。しかし,WWWサーバとWWWクライアント(WWWブラウザを含む)との間の通信規約はRFCなる文書群により「HTTP」なる名称でルールが定められているところ,そのルールの一部として,ある者は「ブラウザに表示させるURLに日本語を使うことはできません。」としており(甲15),ある者は「Webページを参照するためのURL(Unifｏｒm Reｓｏｕｒce Lｏcaｔｏｒ)は,本来1bｙｔe文字の英数字のみが使用できる。」等としているから(甲17,30,31),上記認定は誤りである。ウ取消事由3審決に表示された拒絶理由通知(甲11)は,「(理由7)新規性」欄において,本願発明1,10,12～15は引用文献9(甲9)に記載された発明と同一である旨認定した。しかし,上記認定は誤りであり,その理由は次のとおりである。 (ｱ)引用文献9には「・・・URLを構成する文字列は半角の英数字であるため,日本語をローマ字や英語で表さなければならない」(段落【0005】)と記載されていること。 (ｲ)引用文献9の段落【0024】の1行～5行目の記載によれば,引用文献9に記載された発明の実施の形態における処理手順では,全角文字や半角カタカナを含む文字列をURLとみなしておらず,これと反対の立場に立つ本願発明1,10,12～15とは違いがあること。 (ｳ)引用文献9の段落【0018】3行目の記載によれば,引用文献9記載の発明の実施の形態では,「クライアント側」において「文字列変換プログラムを介」する必要があるが,本願発明1,10,12～15では不要であること。 (ｴ)文字列変換プログラム(一般に「プラグイン」と称される。)をサーバ側に置く場合でも,処理対象文字列をクライアント側での普通の取扱いを変更してクライアント側からサーバ側へと伝達する,いわば「無変換パススループログラム」(プラグインの一種といえる。)を介する必要がある点に留意する必要があること。なお,原告は,本願の早期審査に関する事情説明書(甲17)において,「ホームページのアドレス(URL)において漢字やひらがな等の利用を可能にする新しい技術(仮称:「漢字URL」)」の概要の1つとして,「ウェブブラウザ(閲覧ソフト)側には特殊な設定は不要。現行のブラウザをそのまま利用可能。」としており,同技術においてクライアント側でのプラグインが不要である旨表示している。 (ｵ)引用文献9における文字列変換は,入力:URLでない文字列(例えば首相官邸),出力:RFC準拠文字列,介在者:プラグインである一方,本願発明1,10,12～15では,入力:RFC非準拠URL(http://RURL.NET/首相官邸),出力:RFC準拠URL,介在者なしであり,両者の構成は異なる。エ取消事由4審決に表示された拒絶理由通知(甲11)は,「(理由6)進歩性」欄において,本願発明1,10,12～15は引用文献8(甲8)に記載された発明に基づいて容易に発明をすることができたとしたが,誤りである。その理由は次のとおりである。 (ｱ)引用文献8の段落【0012】の記載によれば,「アクセス機器」から入力された番号はクライアント側又はクライアント側から「番号変換サーバ」側へと伝達した後,サーバ側で「URLに逆変換」する。よって,クライアント側において何らかのプラグインが必要であるが,本願発明1,10,12～15では不要である。 (ｲ)引用文献8に記載された発明は,本願各発明に関する国際調査報告(甲12)で関連文献の1つとして評価済みであり,その評価結果は「A」カテゴリー,すなわち「特に関連のある文献ではなく一般的技術水準を示すもの」に止まる。オ取消事由5審決に表示された拒絶理由通知(甲11)は,「(理由5)進歩性」欄において,本願発明1,3,10,12～15は「WWWクライアントにおいて,英語以外の漢字,カタカナ,ひらがななどの言語の文字列が入力された場合にも,処理を分岐させて文字列処理をすることは,例えば引用文献4,5等に示されるように周知技術である。」と認定しているが,誤りである。なぜなら,被告は,「クライアント側において何らかのプラグインが必要である」ことの要否の検討を欠いているからである。カ取消事由6本件審決で表示された拒絶理由通知(甲11)は,「(理由1)記載不備」,「(理由2)記載不備」,および「(理由3)記載不備」欄にて記載不備をいうが,誤りである。その理由は次のとおりである。 (ｱ)請求項1中の「意図的に」なる記載が明確でないとの指摘は当たらない。「意図的に」は「わざと」と換言できる。後者の語を用いると請求項1中の「意図的にエラーを誘発する」は「わざとエラーを引き起こす」と変形することができる。これと同様の表現は他の文献(雑誌「OPEN DESIGN」2002年2月号,第9巻第2号,2002年(平成14年)2月1日発行,甲16)にも見ることができ,難無く解釈でき,不明確ではない。また,「意図的に」の具体的内容は,本願明細書の段落【0150】【0167】【0171】に記載がある。請求項2,13についても同様である。 (ｲ)請求項1中の「機能拡張装置」における「機能拡張」の技術的範囲が不明であるとの指摘は当たらない。請求項1は「既存WWWサーバがURLを処理するに際して意図的にエラーを誘発するエラー誘発手段と,前記既存WWWサーバが記憶手段に保持するデータのうち少なくともURLパス部を利用して処理を行う文字列処理手段と,前記エラー誘発手段によりエラーが発生した時に前記既存WWWサーバから前記文字列処理手段へと処理を分岐させる分岐手段とを備える」「装置」をクレームしている。そして当該「装置」を「機能拡張装置」と称しているにすぎない。同請求項中の「意図的にエラーを誘発するエラー誘発手段」と同様の表現である。他の請求項中の「機能拡張装置」,「機能拡張方法」,「機能拡張プログラム」の各語についても同様である。 (ｳ)請求項3中の「固定的部位を何ら変更することなく備える」が日本語として明確でないとの指摘は当たらない。「固定的部位」については本願明細書段落【0038】に記載がある。 (ｴ)審決は,請求項4,5中の「以外」なる記載は範囲をあいまいにする表現である結果,発明の範囲が不明確であるとするが,その指摘は当たらない。例えば,「整数のうちの奇数以外」は即ち「整数のうちの偶数」である。「以外」の語の利用のみをもって前記発明が発明の範囲が不明確であるとはいえない。 (ｵ)請求項6中の「用いる用途では含まない」なる記載が日本語として明確でないとの指摘は当たらない。URLパス部について「CGIプログラム等へのパラメータ伝達を指示するものであるとRFCにより定義された文字列をその定義の通りに用いる用途では含まない」については本願明細書【0056】に記載がある。 (ｶ)請求項9中の「随時定義」なる記載が具体的にどのような手段によりどのように定義するのか明確でないとの指摘は当たらない。その前後も含めて示せばこの記載は,「予め定義されたまたは随時定義する文字列」である。この表現の中には「予め定義された文字列(静的なもの)」と「随時定義する文字列(動的なもの)」とが含まれる。後者は「予め定義されるのではない文字列(静的ではないもの)」の言い換えであり,表現として明確である。 (ｷ)請求項9中の「同等に処理」なる記載中の「同等」が明確でないとの指摘は当たらない。その前後も含めて示せばこの記載は,「予め定義された又は随時定義する文字列をRFCにより特別の意味が設定されている文字列と同等に処理する普通文字列特別解釈手段」である。一部を記号化して整理すれば「文字列Xを文字列Yと同等に処理する手段Z」(「実際には文字列Yとは異なる文字列Xを,文字列Yと等価なものとして処理する,手段Z」)となる。 (ｸ)請求項10中の「エラー誘発手段処理ステップ」なる記載が明確でないとの指摘は当たらない。その前方も含めて示せばこの記載は,「意図的にエラーを誘発するエラー誘発手段処理ステップ」である。ここでは「意図的にエラーを誘発するステップ」が説明部である。そして当該「ステップ」を「エラー誘発手段処理ステップ」と称しているに過ぎない。請求項12,13中の「エラー誘発設定ステップ」についても同様である。 (ｹ)請求項6中の「(CGI)プログラム等」が明確でないとの指摘は当たらない。「等」を削除して「CGIプログラム」と限定すべきではない。本願各発明出願当時,当業者においてはCGIプログラムと類似の技術は知られていた。今後も新たなCGIプログラム類似技術は生じうるのだから,「CGIプログラム等」の表現は適当である。また,URLの構文については,本願明細書の段落【0023】において,「正確な意味はURLに関するRFCを参照されたい。」と記載しているが,本願各発明出願当時の規約であるRFC1738及びその更新版であるRFC2396には,URLパス部に係る外部情報処理手段についてCGIプログラムに限定する旨の記載は無い。請求項7中の「(特定の)学術分野等(で用いられている記号類)」について明確でないとの指摘は当たらない。この部分は,本願明細書中の用語「FｘURL」で表現可能な「記号類」である。請求項2,11中の「(発生するエラーの程度または)タイミング等(を変更するための条件変更手段)」について明確でないとの指摘は当たらない。この「条件変更手段」については,本願明細書段落【0035】において,「エラーを誘発するための条件を変更する条件変更手段」と記載されている。加えて,変更の対象は限定されているが,変更の内容は特に限定されていない(本願明細書段落【0154】及び図7参照)。よって,前記「タイミング等」中の「等」の有無でこれらの請求項に係る発明の外延が不明瞭になることはない。 (ｺ)請求項1,2,7,9,12,13,15中の「データ」は具体的にどのようなデータを意味するのか明確でないとの指摘は当たらない。請求項1,2,15では「前記既存WWWサーバが記憶手段に保持するデータ」と記載している。請求項12,13では「前記既存WWWサーバが記憶部に保持するデータ」と記載している。請求項7では「コンピュータ言語の命令やデータ」と記載している。前者はコンピュータ言語において演算を指定する表現であり,後者はコンピュータ言語における演算の対象である。請求項9では「RFCにより特別の意味が設定されている文字列のうちの少なくとも1についてこれを本来の文字そのままのデータとして」と記載している。ここで「本来の文字そのままのデータとして」は,「本来の文字そのままで,すなわち,RFCにより設定されている特別の意味を解除して」の意であり,表現は明確である。 (ｻ)請求項1～3,10～15中の「エラー」は具体的にどのようなエラーを意味するのか明確でないとの指摘は当たらない。無用の限定をする必要はない。仮に,現バージョンのHTTPのステータスコードに則して限定した場合,将来バージョンのHTTPにおける「エラー」を対象外としてしまう危険がある。加えて請求項10,11,14ではHTTP以外のプロトコル(例:SMTP,DNS,FTP)についても適用関係がある(本願明細書段落【0096】～【0101】,【0132】及び図3参照)から,HTTPステータスコードによる限定は無理がある。 (ｼ)請求項2,11中の「エラーの程度またはタイミング等を変更するための条件変更手段」なる記載につき,発明の詳細な説明においても,それ以上の具体的な記載がないとの指摘は当たらない。請求項2は「<請求項1>+<条件変更手段>」と模式化できる。この<条件変更手段>は本願明細書の段落【0154】,【0158】,【0178】,【0199】及び図7(とりわけ条件変更部708)に記載済みである。これらの記載を基礎により広くて明瞭な表現にすべきだったのを怠った点は認める。実際には,本願明細書段落【0035】及び【0036】の内容に引きずられた結果,請求項2を不明瞭にした。また,前記「機能拡張装置」と同様の表現でこの<条件変更手段>を表現できなかった。請求項11についても同様である。 (ｽ)請求項4,5中の「由来し」なる記載が,発明の詳細な説明におけるどの記載のことを意味するのか明確でないとの指摘は当たらない。その前方も含めて示せばこの記載は,「WWWクライアントのURL入力表示欄で入力されたクライアント側入力文字列に由来し」である。この<○○側に由来し>なる表現はWWW中継処理装置(206)の存在を念頭に置いたものであり,本願明細書の段落【0041】～【0043】及び図2に記載がある。 (ｾ)請求項4,5中の「形式」なる記載が発明の詳細な説明におけるどの記載のことを意味するのか明確でないとの指摘は当たらない。この点は本願明細書の段落【0044】～【0046】に記載がある。 (ｿ)請求項5中の「以外の方法」なる記載が発明の詳細な説明におけるどの記載のことを意味するのか明確でないとの指摘は当たらない。その前方も含めて示せばこの記載は,「WWWクライアントのURL入力表示欄で入力する以外の方法で入力された」である。この記載の否定形に相当する入力方法は「WWWクライアントのURL入力表示欄で入力するという方法で入力された」である。これら2点の表現はいずれも明確である。これら2点については相違点も含めて本願明細書の段落【0050】～【0055】に記載がある。 (ﾀ)請求項7中の「2以上の組合せ」なる記載が発明の詳細な説明におけるどの記載のことを意味するのか明確でないとの指摘は当たらない。本願明細書中の用語「FｘURL」の定義から,当然に「2以上の組合せ」がありうる(本願明細書段落【0062】及び図14参照)。 (ﾁ)請求項9中の「少なくとも一方を備える」なる記載に関連して「両方を備える場合」が発明の詳細な説明におけるどの記載のことを意味するのか明確でないとの指摘は当たらない。機能の異なる文字列処理手段を複数多種準備してこれらを活用する点については,本願明細書の段落【0036】,【0037】,【0096】に記載がある。 2請求原因に対する認否請求原因(1)(2)(3)の各事実は認めるが,(4)は争う。 3被告の反論審決の認定判断に誤りはなく,原告主張の取消事由は理由がない。 (1)本願発明14は引用発明1との関係で進歩性がないア(ｱ)引用文献1(甲1)には,以下の記載がある。・「インターネットやイントラネットでWWWサーバを立ち上げるには,HTTPサーバであるhttpdを利用します.今回はhttpd(Apache)のインストールと活用について解説します.」(134頁左欄1行～4行)・「現在主に使われているhttpdの1つにApacheがあります.これは,注1NCSA版httpdの改良から始まったhttpdで,NCSA httpd verl.3 (およびverl.4)と完全互換であり,さらにさまざまな機能拡張などを施したものです.また,NCSA httpdより高速なhttpdでもあります.Apacheの特徴の1つにモジュールによる機能拡張があります.サーバの機能をモジュールという形で与えることで,機能の追加/削除が簡単に行えます.モジュール集はhttp://www.zyzzyva.com/server/module_registry/などから手に入ります.今回は,このApacheをmake,インストールしてみることにしました.」(134頁右欄3行～16行)・「apache_1.1.3.tar.gzをmake,インストールします.これはApach注2eのサポートサイト(http://www.apache.org/)から入手できます.また,日本語サイトhttp://apache.maizuru-ct.ac.jp/からミラーサイトが辿れます.まず,アーカイブを解くとapache_1.1.3/というディレクトリができます.ここに必要なファイルがすべて入っています.適当なディレクトリへ展開してください.筆者は/srcに展開しました.各ディレクトリ構成は表1のようになっています.」(134頁右欄18行～135頁左欄12行)・「●表1ディレクトリ構成(apache_1.1.3/以下)cgi-bin/CGIプログラムconf/設定ファイル,最初はサンプルが入っているhtdocs/HTMLのサンプルが入っているicons/Fancylconで使うアイコンが入っているlogs/ログsrc/httpdのソースが入っているsupport/サポートプログラム,最初はサポートプログラムのソースが入っている」(135頁左欄1行～9行)・「apache_1.1.3/conf/以下のファイルを編集します.デフォルトでは,サーバルートが/usr/1oca1/etc/httpd/以下になっているので,これらのファイルをディレクトリごとコピーします.# cp -r /src/apache_1.1.3/??* /usr/local/etc/httpd/設定ファイルを自分の環境にふさわしいように書き換えます.httpd.confとsrm.conf,そしてaccess.confの3つを設定すれば,WWWサーバとして動作するようになります(それぞれ,表3のような役割をもちます).」(135頁右欄17行～26行)・「●表3Apacheの設定ファイルファイル名役割見本ファイルaccess.confアクセス制限についての設定access.conf-disthttpd.confサーバの動作についての設定httpd.conf-distsrm.conf各ディレクトリやファイル名についての設定srm.conf-dist」(136頁1行目～5行)・138頁右欄からsrm.confの設定についての記載があり,140頁左欄から右欄に「ErrorDocument」のタイトルで以下の記載がある。「ErrorDocumentエラードキュメントをカスタマイズできます.エラードキユメントとは,誤ったURLを指定した場合などにクライアント上に表示されるドキュメントのことです.ここでカスタマイズすると,他のサーバ上にあるエラードキュメン卜を表示したり,CGIを使ったものを表示させたりすることができるようになります.エラードキュメントをプレーンテキストで表示するときには「”」の後に続けて,表示したいテキストを記述します.ローカルのファイルを表示させる場合には,そのファイルが存在するパスを絶対パスで記述します.ローカルのCGIの場合も同様に指定します.リモートにあるファイルを表示させるには,そのファイルの存在するURLを記述します.ErrorDocument 500 "The server made a boo boo.ErrorDocument 404 /missing.htmlErrorDocument 404 /cgi-bin/missing_handler.plErrorDocument 402 http://other.server.com/subscription_info.html｣(ｲ)以上の記載から引用文献1には以下の発明(引用発明1)が記載されていることが認められる。「HTTPサーバであるApacheがインストールされ,cgi-binディレクトリにはCGIプログラムを格納し,設定ファイルsrm.confには,誤ったURLを指定した場合にクライアント上に表示されるエラードキュメントをカスタマイズして設定でき,上記設定は,エラードキュメントをプレーンテキストで表示するときには「”」の後に続けて,表示したいテキストを記述し,ローカルのファイルを表示させる場合には,そのファイルが存在するパスを絶対パスで記述し,リモートにあるファイルを表示させるには,そのファイルの存在するURLを記述し,ローカルのCGIの場合も同様に指定し,CGIを使ったものを表示させることができるようにし,リモートにあるファイルを表示させるには,そのファイルの存在するURLを記述するようにした,WWWサーバ」イ対比・判断(ｱ)本願発明14を引用発明1と比較する。引用発明1であるWWWサーバは既存情報処理手段に相当し,WWWサーバにはApacheがインストールされて情報処理を行っていることは明白である。引用発明1は誤ったURLを指定するとCGIプログラムを使ったものを表示しているから,誤ったURLを指定した時にCGIプログラムに処理を分岐しているといえる。そして,誤ったURLを指定することは「エラーが発生した時」に相当し,CGIプログラムによる処理をすることは別の情報処理手段に処理を分岐させることに相当する。また,CGIプログラムに処理を分岐するのは,WWWサーバが情報処理を行い,誤ったURLを指定したことを検出したときと解されるから,引用発明1においても既存情報処理手段における情報処理結果の一部または全部を利用しているといえる。以上から,両者の一致点,相違点は次のとおりである。 <一致点>「既存情報処理手段が情報処理するに際して前記既存情報処理手段における情報処理結果の一部または全部を利用して処理を行う情報処理手段と,エラーが発生した時に前記既存情報処理手段から別の情報処理手段へと処理を分岐させる分岐手段とを備える装置」<相違点1>本願発明14においては,既存情報処理手段に対して,その外に外部情報処理手段があるのに対して,引用発明1では,既存情報処理手段に相当するWWWサーバが,別の情報処理手段に相当するCGIプログラムを備えている点。 <相違点2>本願発明14は「機能拡張装置」の発明であるのに対して,引用発明1はWWWサーバである点。 (ｲ)次に相違点について検討する。・<相違点1>について引用発明1は,誤ったURLを指定したときにCGIプログラムへ分岐し,このCGIプログラムが作動してエラードキュメントを表示しているところ,このCGIプログラムは,WWWサーバに対して付加的な情報処理手段を構成しているから,既存情報処理手段に対して外部情報処理手段といえるものである。また,情報処理分野において,付加的な情報処理手段を既存の情報処理手段に対して外部の情報処理手段として構成することは,何ら格別なことではなく,適宜に設計し得る事項である。よって,引用発明1のCGIプログラムを,既存情報処理手段に相当するWWWサーバに対して外部情報処理手段として構成することは,当業者が容易に想到し得る事項である。・<相違点2>について前記のとおり,引用発明1のCGIプログラムは,WWWサーバに対して付加的な情報処理手段を構成し,CGIプログラムに記述された処理を行うものであるから,WWWサーバに対して機能を拡張しているといえる。そして,原告の主張によれば,既存のWWWサーバ以外の処理手段を指すものを「機能拡張装置」と「称しているにすぎない」ものであるから,引用発明1においてCGIプログラムによる処理を行う構成は,本願発明14の機能拡張装置に相当するといえるものである。よって,相違点2は格別のものではない。・以上から,相違点1及び2は格別のものではなく,本願発明14は引用発明1から当業者が容易に想到することができたものである。 (2)本願発明14は先願発明9との関係で新規性がないア(ｱ)引用文献9(甲9)には,以下の記載がある。・「【0004】ところが,このURLの入力はユーザにとっては思わぬ障害となっている。その理由はURLを構成する文字列が長く,しかも複雑な仕組みを持つことである。たとえばA株式会社のURLはそのホームページがどの管理下にあるかでhttp://www.a.co.jp/,http://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/のように変わり,その組み合わせは無限といえるほどである。このような複雑な仕組みを持つURLは入力を1字間違えただけでアクセスできず,しかも間違いの原因や箇所などを指摘する手段もないため,コンピュータやインターネットに精通したユーザ以外の利用は困難を極めている。」・「【0005】さらに,URLを構成する文字列は半角の英数字であるため,日本語をローマ字や英語で表さなければならないが,その際にもユーザにとって次のような障害がある。たとえば日本の通商産業省のホームページはMinistry of International Trade and Industryの略であるMITIを用いてhttp://www.miti.go.jp/となっているが,果たして通商産業省からmitiを想像することのできるユーザがどれほどいるであろうか。また,首相官邸のホームページはhttp://www.kantei.go.jp/と,今度は「官邸」をローマ字で表したURLが用いられている。このように,会社名,団体名,組織名,法人名,個人名,商品名,サービス名称,地名といったユーザになじみのある名称を元にURLが決められているのではないため,目的の情報資源へたどりつくためには「ｙahｏｏ」や「gｏｏ」といった検索エンジンに頼らざるを得ない状況となっている。」・「【0019】まず,図1の説明図によりクライアント側のWWWブラウザから文字列変換プログラムを介してインターネットへアクセスする方法を説明する。クライアント側のWWWブラウザ11のアドレス欄に入力された文字列は,文字列変換プログラム12によってURL変換データベース13の中に入力された文字列と同一の文字列があるかが検査され,同一の文字列に対応するURLを取得し,取得されたURLをもってインターネット14へアクセスする。」・「【0020】前記文字列の入力には一般的なキーボードを用いる他に,マウスやペン,タッチパネルといったポインティングデバイスや,スキャナ,デジタルカメラ,OCRなどの光学的読みとり装置や,テレビなどの操作に用いるリモコン類や,音声で入力する音声認識インターフェースなどを用いることができる。」・「【0021】前記文字列変換プログラムはクライアント側にインストールする他に,LAN環境などではサーバ側に置くことも可能で,プロバイダ業者がユーザへのサービスとして本発明を利用するような環境では,プロバイダ業者の管理するサーバ側に置くことも可能である。」・「【0022】前記URL変換データベースは前記文字列変換プログラムと同一の場所に置くことも可能な他,たとえば前記文字列変換プログラムをクライアント側に置き,前記URL変換データベースをサーバ側に置くことも可能である。」・「【0023】次に,図2と図3,図4の説明図によりクライアント側のWWWブラウザへの文字列入力からインターネットへのアクセスに至るまでの処理手順を説明する。」・「【0024】ユーザが前記入力手段で入力した文字列を,全角文字や半角カタカナを含むか,あるいは図3のURLの構成に沿ったものであるかを調査し,全角文字や半角カタカナを含まず,かつ図3のURLの構成に沿ったものであれば入力された文字列をURLと見なして変換せずにインターネットへの探査を行う。前記文字列はプロトコル31,DNS32,ディレクトリ33,ファイル名34のいずれにあっても抽出が可能で,または入力が前記文字列だけであっても抽出が可能である。入力された文字列が図3のURLの構成に沿ったものでないか,全角文字や半角カタカナを含む場合は,入力された文字列で図4のURLデータベースを検索し,一致するURLを取得してインターネットへの探査を行う。図4のURL変換データベースに一致する文字列が見つからなければその旨のエラーメッセージを画面上に表示する。」(ｲ)以上の記載から,引用文献9に係る特許出願の願書に最初に添付した明細書又は図面には次の発明(以下「先願発明9」という。)が記載されている。「クライアント側のWWWブラウザ11のアドレス欄にユーザは文字列を入力し,ユーザが入力手段で入力した文字列を,全角文字や半角カタカナを含むか,あるいはURLの構成に沿ったものであるかを調査し,全角文字や半角カタカナを含まず,かつURLの構成に沿ったものであれば入力された文字列をURLと見なして変換せずにインターネットへの探査を行い,文字列はプロトコル31,DNS32,ディレクトリ33,ファイル名34のいずれにあっても抽出が可能で,または入力が前記文字列だけであっても抽出が可能であり,入力された文字列がURLの構成に沿ったものでないか,全角文字や半角カタカナを含む場合は,入力された文字列でURLデータベースを検索し,一致するURLを取得してインターネットへの探査を行い,URL変換データベースに一致する文字列が見つからなければその旨のエラーメッセージを画面上に表示する,インターネットへのアクセスシステム。」イ対比・判断本願発明14と先願発明9とを対比する。先願発明9において,ユーザはクライアント側のブラウザのアドレス欄に文字列を入力しており,該文字列はアドレスとして扱われる点でURLに相当し,通常のURLを入力した時は文字列変換をしないでインターネットへの探査を行うことは既存情報処理手段が作動することに相当し,ユーザが入力したURLに全角文字や半角カタカナが含まれていたときは,エラーが発生した時に相当し,URLデータベースを検索する処理を行うことは外部情報処理手段へ処理を分岐させることに相当する。よって,本願発明14は先願発明9と実質的に同一の発明である。 (3)取消事由1及び2に対しア原告は,審決で表示された拒絶理由通知の「サーバの設定がエラーを発生させるような状態に設定されていれば,エラーを誘発させ,サーバでの処理を分岐させ,文字処理を行わせることに格別の困難性は認められない。」(5頁12行～14行)との認定は誤りであると主張する。しかし,本願各発明におけるエラー発生は,URL処理において,漢字等がURLに使用された場合に対する文字列処理を行わせるために,通常のURL処理から別処理に分岐させるための便法の一つとして採用したものであり,該分岐処理を行わせ得る手法であればエラー発生に限定されるものではなく,エラー発生が不可欠といえるものではない。また,例えば一般のサーバでの処理において,サーバの特定ファイルへのアクセスや特定ユーザからのサーバへのアクセスを制限するようなケースは,通常の運用において当然想定されるものであり,そのような制限に該当するならば,あたかもそれをエラー発生のように取扱って通常の処理とは別の処理に移行させ,それに応じてエラー頁を表示させるようにすることも運用上ごく普通に行われていることであるから,エラーを発生させるような設定は必要に応じて適宜に行われることである。そして,エラーを発生させるような設定を行うことは,当然処理態様として通常処理とは別処理を行うことに他ならず,すなわちサーバでの処理が分岐処理となることは容易に首肯し得る。してみると,審決が拒絶理由通知を引用して「サーバの設定がエラーを発生させるような状態に設定されていれば,エラーを誘発させ,サーバでの処理を分岐させ,文字処理を行わせることに格別の困難性は認められない。」と認定したことに誤りはない。イ原告は,WWWサーバとWWWクライアントとの間の通信規約に定められたルールの一部を引用して,ブラウザに表示させるURLに日本語を使うことはできない旨主張する。確かに,本願明細書(甲10)の段落【0016】に記載があるように,雑誌(「日経コミュニケーション」第268号,1998年(平成10年)4月20日発行,甲15)の記事中に「ブラウザに表示させるURLに日本語を使うことはできません。」の記載があるが,本願明細書において,続く段落【0017】から段落【0018】に記載されているように,URL入力として漢字等を入力することは可能であるところ,入力した漢字等がURLとして機能を果たすか否かに問題があり,上記雑誌の記事は,それがURLとして機能を果たさないから「日本語を使うことはできません」としたまでのことで,日本語を使うこと自体が全く排除されていたわけではない。してみると,審決が拒絶理由通知を引用して「一般にWWWブラウザにおいて,URLパス部に漢字等の非アスキー文字を含むこと,または含ませることを排除するものではない。」と認定したことに誤りはない。 (4)取消事由3に対し引用文献9(甲9)には,段落【0019】に「クライアント側のWWWブラウザ11のアドレス欄に入力された文字列は,文字列変換プログラム12によってURL変換データベース13の中に入力された文字列と同一の文字列があるかが検査され,同一の文字列に対応するURLを取得し,取得されたURLをもってインターネット14へアクセスする。」,段落【0024】に「ユーザが前記入力手段で入力した文字列を,全角文字や半角カタカナを含むか,あるいは図3のURLの構成に沿ったものであるかを調査し,全角文字や半角カタカナを含まず,かつ図3のURLの構成に沿ったものであれば入力された文字列をURLと見なして変換せずにインターネットへの探査を行う。」及び「入力された文字列が図3のURLの構成に沿ったものでないか,全角文字や半角カタカナを含む場合は,入力された文字列で図4のURLデータベースを検索し,一致するURLを取得してインターネットへの探査を行う。」との記載があり,引用文献9においてブラウザに入力される文字列は半角英数字に限定されておらず,全角文字や半角カタカナを含む文字列を入力でき,全角文字や半角カタカナを含む場合はURLデータベースを検索することが記載されているものであるから,引用文献9においてプラグインについての検討をする必要はない。また,原告は,「本願発明では,ウェブブラウザ側には特殊な設定は不要で,クライアント側でのプラグインが不要である。」と主張しているが,上記主張は,本願の明細書及び図面の記載に基づかない。よって,原告の主張は理由がない。 (5)取消事由4に対し引用文献8(甲8)の段落【0105】に記載されているように,クライアント側は入力された番号をウェブサーバに送る機能を有するものであるから,引用文献8においてプラグインについての検討をする必要はないし,また,クライアントからの入力が原告の主張するようなブラウザによるとしても,日本語を入力することが排除されているわけではないので,原告の主張は理由がない。また,原告は,引用文献8が国際調査報告においてカテゴリーA相当の刊行物であったと主張しているが,そのことが本件における拒絶査定のように,進歩性を否定するための引例として引用文献8を引用することを拘束するものではない。国際調査報告の作成後に関連分野の技術水準や周知技術に関する知見を得ることにより,当該刊行物に対する評価が変化することは十分に想定されることであり,国際調査報告時の評価がそのまま各国審査段階時の評価に踏襲されるものではない。また,特許協力条約 33条に記載されているように,国際予備審査は予備的かつ拘束力のない見解を示すものである。 (6)取消事由5に対し本願明細書(甲10)の段落【0016】～【0018】に記載されているように,WWWクライアントにおいて日本語を入力することが排除されているわけではないし,引用文献4～引用文献7(甲4～7)に記載された文字列処理や分岐処理は,いろいろな種類の文字を受け付けて処理する機能を有するものであるから,プラグインの必要性についての検討を欠くとの原告の主張は理由がない。 (7)取消事由6に対しア原告は,請求項1等に記載した「意図的に」は「わざと」と換言でき,同様の表現を他の文献(甲16)にも見ることができるから,難無く解釈でき,不明確ではない旨主張する。しかし,特許請求の範囲の記載は,この記載に基づいて特許発明の技術的範囲が定められ,新規性・進歩性の特許要件等の判断がなされるという点において重要な意義を有するものであり,一の請求項から発明が明確に把握されることが必要であることはいうまでもないが,原告が主張するように,「意図的に」が「わざと」と同じ意味であることは分かるとしても,「意図的に」あるいは「わざと」の表現を用いることで実現(具現)する構成が不明確であり,技術的範囲も不明確である。イ原告は,請求項1等に記載した「機能拡張装置」等における「機能拡張」の技術的範囲が不明であるとの指摘は当たらない旨主張する。しかし,「機能拡張装置」という以上,基となる装置に対して機能を追加するものを意図していると理解するのが合理であるところ,単に「機能拡張装置」のみでは,既存WWWサーバに対して追加する装置の構成が既存のサーバの機能に対してどのような機能の拡張を特定するものであるのか不明であるから,請求項1等で使っている「機能拡張」の技術的範囲が不明である。ウ原告は,請求項3中の「固定的部位を何ら変更することなく備える」が明確でないとの指摘は当たらない旨主張する。しかし,本件明細書(甲10)の段落【0038】の記載を参酌すると,「固定的部位」とは変更がなされない部位をいうと解される。そのような「固定的部位」を「何ら変更することなく」とあえて修飾することは「固定的部位」が変更できることを想定していると解されることになり,明細書の記載と矛盾する。そうすると,そのような変更が可能な「固定的部位」とは何を意図しているのか不明であるので,「・・・備える」とする構成が不明確である。エ原告は,「以外」の語の利用のみをもって明確でないとするのは当たらない旨主張する。しかし,請求項4,5中の「以外」を解釈する上において,原告が例示する奇数と偶数のような二者択一の関係に帰着できるものではなく,また,「どのような形式をもっても伝達されない箇所」の記載表現がどこを指すのかも不明であるから,結局,請求項4,5中の「以外」なる記載はどの範囲を指すのか不明である。オ原告は,請求項6中の「用いる用途では含まない」が明確でないとの指摘は当たらない旨主張する。しかし,請求項6に記載された「CGIプログラム等へのパラメータ伝達を指示するものであるとRFCにより定義された文字列をその定義の通りに用いる用途では含まない」における「CGIプログラム等へのパラメータ伝達を指示するものであるとRFCにより定義された」は「文字列を」にかかる。そして,「含まない」の目的語は「文字列を」であるから,「文字列を」「含まない」と解釈できる。そうすると「含まない」の直前部分は,通常は,何を含まないのかあるいはどこに含まないのかを意味することになるが,直前部分には「その定義の通りに用いる用途では」と記載されているから,どこに「含まない」のか不明である。カ原告は,請求項9中の「随時定義」は「予め定義されるのではない文字列(静的ではないもの)」の言い換えであり,表現は明確である旨主張する。しかし,拒絶理由通知書(甲11)における「具体的にどのような手段によりどのように定義するのか明確でない」とは,装置内でどのように随時に定義を設定しているのか不明であると指摘しているのであって,随時定義の意味を不明確と指摘している訳ではない。キ原告は,請求項9中の「同等に処理」の前後も含めた記載「予め定義された・・・文字列を・・・特別の意味が設定されている文字列と同等に処理する普通文字列特別解釈手段」の表現は明確であり,より具体的な説明も記載済み(本願明細書段落【0089】)であるから,「同等」が明確でないとの指摘は当たらない旨主張する。しかし,「同等」とは程度が同じという意味であり,同程度の処理の意味とは何か(どのような内容の処理であるのか)が不明確である。ク原告は,請求項10中の「エラー誘発手段処理ステップ」なる記載が明確でないとの指摘は当たらない旨主張する(請求項12,13中の「エラー誘発設定ステップ」についても同様)。しかし,請求項10では,「エラー誘発手段処理ステップ」では手段とステップが混在しており,両者の関係が不明であり,また,請求項12,13の「エラー誘発設定ステップ」は「エラー誘発手段」との関係が不明である。ケ原告は,請求項1,2,7,9,12,13,15中の「データ」なる記載は,各請求項の記載及び対応する本願明細書の記載から明確であるから,明確でないとの指摘は当たらない旨主張する。しかし,請求項1に記載された「WWWサーバが記憶手段に保持するデータのうち少なくともURLパス部を利用して処理を行う文字列処理手段」において,WWWサーバには多くの種類のデータが記憶されているところ,ここの「データ」がどのようなデータを意味するのか不明確であるといわざるを得ない。また,請求項2,12,13,15も請求項1と同じ理由により不明確であるといわざるを得ない。請求項7には「コンピュータ言語の命令やデータ」と記載されているところ,「コンピュータ言語の」「データ」が演算の対象となるデータであるとすると,そのようなデータにはあらゆる種類のデータが含まれるので,文字列処理を要しない普通のURLも含まれることになるから,発明が不明確であるといわざるを得ない。請求項9の「データ」についても,請求項9が引用する請求項4または5がさらに引用する請求項1または2に記載された「データ」が不明確であり,かつ,請求項1または2に記載された「データ」と請求項9に記載された「データ」との関係が不明であるから,不明確である。コ原告は,「エラー」なる記載が明確でないとの指摘は当たらず,無用の限定をする必要はない旨主張する。しかし,拒絶理由通知書(甲11)は,請求項1～3,10～15に対して特許法36条6項2号による記載不備を指摘した。この条文の趣旨は,特許請求の範囲の記載は,特許権の権利範囲がこれによって確定されるという点において重要な意義を有するものであるから,その記載は明確でなければならないことにある。請求項1～3,10～15に記載の「エラー」は一般的な用語にすぎないからから,特許法36条6項2号違反に当たると指摘したものである。また,請求項14,15に対しては,特許法36条6項1号による記載不備も併せて指摘した。この条文の趣旨は,特許請求の範囲の記載には,発明の詳細な説明に記載の範囲を超えて記載してはならない旨を規定したものである。請求項14,15には単に「エラーが発生した時に」との記載があるが,「エラー」という語は一般的な用語であるから,請求項14,15の記載では本願の明細書中に記載された意味での「エラー」の範囲を超えるものを当該請求項に記載しているとして,特許法36条6項1号違反に当たると指摘した。サ原告は,請求項2,11中の「エラーの程度またはタイミング等を変更するための条件変更手段」なる記載を非難するが,その指摘は当たらない旨主張する。しかし,請求項2,11に記載された「エラーの程度またはタイミング等を変更するための条件変更手段」に対して,発明の詳細な説明には「【0035】請求項2の機能拡張装置は,どのようなURLパス部の到来に対してエラーを誘発するのか(あるいは逆に誘発しないのか)やどのような時間帯にエラーを誘発するのか等の,エラーを誘発するための条件を変更する条件変更手段を備えている。」と記載されているように,請求項2,11に記載された「条件変更手段」と詳細な説明に記載された「条件変更手段」とは対応していない。シ原告は,請求項4,5中の「由来し」なる記載が明確でないとの指摘は当たらず,「この<○○側に由来し>なる表現はWWW中継処理装置(206)の存在を念頭に置いたものであり,記載済みである(本願明細書段落【0041】～【0043】および図2参照)。」と主張する。しかし,原告が指摘する段落【0041】～【0043】にも発明の詳細な説明の他の箇所にも「由来し」という記載はなく,「由来し」がどのようなことを意味するのか不明である。ス原告は,請求項4,5中の「形式」なる記載が明確でないとの指摘は当たらず,本願明細書段落【0044】～【0046】に記載がある旨主張する。確かに,段落【0044】には,「・・・たとえネットワーク(208)中においてどのような表記形式で伝送されようとも文字列1と見た目上(つまり印刷した際に)同一の文字列をWWWサーバにて獲得する獲得手段を備えるとしている。」と記載されており,請求項4,5の「形式」は一応「表記形式」のことと把握されるところ,請求項4には,「・・・文字列処理手段はWWWサーバに対してどのような形式をもっても伝達されない箇所以外は」とあり,常識的に考えて「表記形式」がどのような形式であっても伝達されない箇所があるような「表記形式」とは何かが不明であるから,結局,請求項4の「形式」が「表記形式」に対応するのかは不明である。セ原告は,請求項5における「以外の方法」の前方の記載を含めるとその表現は明確であって,記載が明確でないとの指摘は当たらない旨主張する。しかし,「WWWクライアントのURL入力表示欄で入力する方法」は明確といえるが,それ「以外の方法」とは「URL入力表示欄で入力する」以外のあらゆる方法と解されるから,技術的範囲が不明確である。そして,特許法36条6項1号の趣旨は先のとおりであるところ,本願発明の詳細な説明には,「WWWクライアントのURL入力表示欄で入力する以外の方法」として「telnet」と「プログラム」による例が挙がっているだけであり,発明の詳細な説明に開示された内容を超えるような「以外の方法」というあらゆることを含む技術的範囲までとすることは,特許法36条6項1号の趣旨に反することは明らかである。ソ原告は,請求項9中の「少なくとも一方を備える」なる記載に関連して「両方を備える場合」が明確でないとの指摘は当たらず,機能の異なる文字列処理手段を複数多種準備してこれらを活用する点については,本願明細書段落【0036】,【0037】,【0096】に記載がある旨主張する。しかし,原告が指摘した箇所以外の発明の詳細な説明を参照しても,「特別文字列普通解釈手段」と「普通文字列特別解釈手段」を備える場合については記載されていない。タ原告は,請求項2中の「(発生するエラーの程度または)タイミング等(を変更するための条件変更手段)」について明確でないとの指摘は当たらない旨主張する。そこで,請求項2に記載された「タイミング等」について検討する。発明の詳細な説明には「タイミング」という用語は記載されていない。類似と思われる記載として発明の詳細な説明の段落【0035】に「時間帯にエラーを誘発する」との記載はあるが,「タイミング」を時間帯の意味で用いられることは一般的ではないから,請求項2の「タイミング等」が何を意味するのか不明確である。次に「(CGI)プログラム等」を検討する。「(CGI)プログラム等」について,発明の詳細な説明中にはそれに類する記載も示唆もないから,「(CGI)プログラム等」に類するものが何であるのか不明である。同様に「学術分野等」に関しても,「学術分野」に類する範囲として何が含まれるのか不明である。この点につき,原告は,請求項7中の「(特定の)学術分野等(で用いられる記号類)」について,本願明細書中の用語「FｘURL」で表現可能な「記号類」と記載,指定されている旨主張するが,発明の詳細な説明を参酌しても「FｘURL」で表現可能な「記号類」の種類が何であるのか不明である。第4当裁判所の判断1請求原因(1)(特許庁における手続の経緯),(2)(発明の内容),(3)(審決の内容)の各事実は,いずれも当事者間に争いがない。ところで,原告のなした本件特許出願(本願)の特許請求の範囲は,前記のとおり請求項1～15から成り,審決の内容・原告主張の取消事由・被告の反論のいずれも,上記各請求項全般に亘ってなされているが,特許法36条によれば,複数の請求項に亘るものであっても特許出願としては一個不可分のものであるから,出願に係る請求項1～15のうち一つでも特許法の定める要件を満たさないものがあるときは,その余の請求項について判断するまでもなく,当該特許出願全体が拒絶されるべきことになる。そこで,被告が重点的に主張している本願請求項14(本願発明14)について,まず検討する。 2本願発明14の進歩性(特許法29条2項)の有無について(1)本願発明14の意義ア本願明細書(甲10)には,以下の記載がある。・【請求項1】～【請求項15】前記第3,1(2)記載のとおり。・【発明の属する技術分野】「この発明は,既存の情報処理手段の機能を拡張する装置,方法ならびにこの方法を備えたプログラムに関し,特にWWWサーバにおけるURLの解釈を柔軟に行うことによりURLの表現力や利用価値を高めることに関する。」(段落【0001】)・【発明が解決しようとする課題】「しかしながら,HTTPやURLの規約に準拠したこれまでのURL(このようなURLを以降,『TrURL』(Traditional URL)と言う。)ではURLパス部に漢字等の全角文字を含むことができなかった。そのため,本当は○×商会が図9のURL入力表示欄(901)に示す表現方法に代えて図10のURL入力表示欄(1001),(1007),(1009)に示すような漢字,ひらがら,カタカナを含むURL(このようなURLを以降,『KURL』(Kanji URL)と言う。)を用いたくてもできなかった(またはできないと考えられていた)。(段落【0015】)・「少なくとも資料1(出典は後述)の雑誌の記事は,『ブラウザに表示させるURLに日本語を使うことはできません。』としている。当該雑誌の次号以降で訂正等がなされていないことを考え併せれば,これがインターネット関連業界の標準的認識と考えてほぼ良いであろう。すべてのブラウザがHTTPの規約どおり実装されていればこの記述は妥当である。ところが実際の状況はやや異なる。」(段落【0016】)・「発明者が実験した範囲では,HTTPには反するかもしれないものの,開発者またはバージョンが異なる2以上のブラウザにおいて,URL入力表示欄(502)に漢字等を入力することは可能である。ただし,それ(漢字等を含んだKURL)をWWWサーバに伝達する際の処理方法は異なっている。」(段落【0017】)・「このため,通信するWWWクライアント(202)とWWWサーバ(210)の双方が同一の漢字コード体系を用いているケースや下記のような対処を行ったケースでは,KURLがあたかも正常に使えているように処理することが可能である。」(段落【0018】)・「すなわち,(他の方法もあるかもしれないがここで説明するのは,)利用されうる漢字コード体系の別をP,HTTPに基づくエンコード処理の有無やエンコード処理後の文字列の相違の別をQとする時,P×Q=R通りの表記によるファイルをディレクトリ領域(図8A参照)に設定する;という対処方法である。仮にP=3,Q=2とした場合,1のURLに対して6のファイルを用意することになる。」(段落【0019】)・「ただし前記の方法には欠点がある。WWWサーバが動作しているコンピュータにおけるOS(オペレーティングシステム)の種類によっては,特定の漢字コード体系における特定の文字を含む場合は,対応するファイルを設定できない可能性がある。それは──漢字等の全角文字は多くの場合2バイト(16ビット)が1文字に対応する。前記の方法では,外見上は漢字等を用いたファイル名が設定できているように見えながら,実は,2の1バイト文字(ここで『1バイト文字』は7ビットまたは8ビットの空間を持つ文字コード集合。例えばASCIIコード。)をただ連ねただけで(それ以外の配慮をせずに)1の全角文字を疑似的に実現している場合がある。このような漢字処理方法においては,当該OSがファイル名には用いないとしている1バイト文字(例えばあるOSにおいては「/」(スラッシュ))を含むような全角文字は正しく取り扱うことができないおそれがある。」(段落【0020】)・「仮に上記のような現象が発生する可能性が低いとしてこれを許容するとしても,1のURLに対して6のファイルを用意するのにはファイルの設置や管理に手間が掛かる。それに,もしもKURLの処理方式の異なるブラウザの数が増えてQ=5となった場合には,P=3のままとして,1のKURLに対して15ものファイルを用意しなければならない。PやQは将来の増加の可能性があるので,このような場当たり的な対処方法は運用面で大変手間の掛かる方法であると言える。しかも,上述したような不完全性を備えている。」(段落【0021】)・「TrURLには漢字等の全角文字以外にも表記上の制限がある。まず,TrURLで使用可能な文字コード集合は最大でも7ビットの文字コード集合であるASCIIコードだけである。上述した全角文字を含め,2バイト以上の領域を用いる日本語,韓国語,中国語等用の多バイトのコード体系は使えない。ヨーロッパを中心に用いられている『ISO 8859-1』なるコード体系をはじめとする8ビット(1バイト)の文字コード集合も使えない。」(段落【0022】)・「TrURLには更に制限がある。ASCII文字コード集合のうち利用者側の意志で自由に使えない文字(コード)が複数存在する。具体的には,(1)『非図形文字』である文字群(1102),(2)『Unsafe』である文字群(1104)(3)『Reserved』である文字群(1106)がある。正確な意味はURLに関するRFCを参照されたい。以下では例を用いて説明する。(段落【0023】)・「そこでこの発明は,WWWクライアントからWWWサーバに伝達されたURLの中のURLパス部を柔軟に解釈して多様な文字列処理をすることを可能にすべく,既存のWWWサーバに取り付け可能な機能拡張装置および機能拡張方法ならびに前記機能を備えた機能拡張プログラムを記録した記録媒体を提供することを目的とする。」(段落【0031】)・【課題を解決するための手段】「請求項1の機能拡張装置は,意図的にエラーの発生を誘うエラー誘発手段を用いてURLに関する処理を既存のWWWサーバから既存のWWWサーバ以外の処理手段である文字列処理手段(この文字列処理手段はこの発明により新規に用意する手段である。)へと移している。その際,既存のWWWサーバが情報処理した結果として記憶された記憶手段の情報を利用している。」(段落【0032】)・「これにより,既存のWWWサーバでは実現が困難であったURLパス部の柔軟な解釈が可能となる。この発明の一実施形態による機能拡張手段等を備えたWWWサーバの処理の流れを図1に示す。」(段落【0033】)・「この発明による機能拡張装置を利用するためには,対象となる装置が(1)例外事象発生時の処理手段を呼び出す仕組みと(2)その処理手段として所望のものを設定可能という2の条件を満たしていれば良い。たとえば『CPU』は『WWWサーバ』ではないが,CPUはこれらの条件を満たしているものが多い。」(段落【0097】)・「このことを熟考すれば,請求項1が機能拡張の対象としている装置をWWWサーバにのみ限定していることについて疑問が生じて来る。『この限定を取り払うとどういうことになるのか?』発明者は自問自答した。」(段落【0098】)・「コンピュータのファイル等のデータを『資源』と捉えるならば,URLはインターネットにおける資源の同定用文字列と言える。実際,『URL』の正式名称である『Uniform Resource Locators』がそれを示している。そして,資源の所在を指し示す文字列を『アドレッシング用文字列』と呼び直してみると,(1)URLと並んでインターネットにおいて頻繁に利用されている文字列である『電子メールアドレス』や(2)URLと電子メールアドレスに共通の要素である『ドメイン名』等も『アドレッシング用文字列』と言って良いだろう。」(段落【0099】)・「ここまで考えを進めるとこの発明は,アドレッシング用文字列を処理するサーバ全般に適用できそうだとの推測が付く。具体的には,(1)電子メールの配送等を行うための手段である電子メールサーバや,(2)ドメイン名からIPアドレスを得るための(またはその逆の用途のための)手段であるDNS (Domain name system)サーバにも適用できそうなことが推測できる。FTP (file transfer protocol)サーバにも適用できるであろう。すなわち,電子メールサーバ(『sendmail』という名称のプログラムが有名である。)を例に採れば,次のような請求項を設けることが可能である。」(段落【0100】)・「既存電子メールサーバが電子メールのアドレスを処理するに際して意図的にエラーを誘発するエラー誘発手段と,前記既存電子メールサーバが記憶手段に記憶させたデータのうち少なくとも電子メールアドレスのユーザID部を利用して処理を行う文字列処理手段と,前記エラー誘発によりエラーが発生した時に前記既存電子メールサーバから前記文字列処理手段へと処理を分岐させる分岐手段とから成る機能拡張装置。」(段落【0101】)・「更に考えを推し進めれば,この発明は,インターネット以外の領域にも適用できそうなことが推測できる。例えば,電話通信網における電話番号に基づく回線交換システムにも適用可能であろう。」(段落【0102】)・「このように考えるうちに,これらの適用可能な用途をすべて個別に列記して請求項として記述する方法では限界があると発明者は考えた。そこでこの発明の本質を抽出し,新たな請求項とした。それが請求項10と請求項11である。」(段落【0103】)・「発明者が更に考えを推し進めたところ,エラー誘発手段は必ずしも機能拡張装置の構成要素として含まれる必要はないであろうとの知見を得たため,請求項14としてこの発明を記述した。また,請求項14における『既存情報処理手段』をWWWサーバに限定した場合の発明を請求項15として記述した。」(段落【0108】)・「図7に示した各部を備えた処理手段をCPU(1706)を用いた装置のハードウェア構成の一例を図17に示す。なお,図7に示した各部分の全部または一部はCPUを用いずにハードウェアロジックにより構成してもよい。」(段落【0179】)・「図17において,CPU(1706)には,ネットワークインターフェース(1702),メモリ(1708),ディスプレイ(1710),キーボード(1712),CD-ROMドライブ(1716),ハードディスク(1718)が接続されている。」(段落【0180】)・「ハードディスク(1718)には,OS(1720),WWWサーバ装置に必須のプログラムであるhttpdプログラム(1722),httpdプログラムが動作中に各種設定情報や変数等が格納されるhttpdプログラム用ワークエリア(1724),httpdプログラムがWWWクライアントからのHTTPリクエストに応じて随時提供する情報等を格納した公開用ファイル(1726)が記憶されている。これらがWWWサーバの基本的要素である。」(段落【0181】)・「ハードディスク(1718)にはまた,この発明を用いたWWWサーバにだけ存在する機能拡張プログラム(1728)と機能拡張プログラム用ワークエリア(1730)も記憶されている。これがWWWサーバの拡張的要素である。」(段落【0182】)・「加えてこの発明を実施するWWWサーバのうち請求項2を満たすものは,分岐先情報保持部(704)の内容を変更するための手段として条件変更部(708)を備える。条件変更部(708)は前記アクセスコントロールファイルまたは同等機能を提供するファイル等における分岐先情報保持部(704)またはこれに相当する箇所を修正するためのものである。」(【0199】)・【発明の効果】「これまでに説明から明らかなように,WWWサーバにおけるURLの解釈を柔軟に行うことによりURLの表現力や利用価値を大幅に高めることができる。同時に,インターネットのサービスを利用する際の障壁を下げる効果もある。これらの相乗効果により現在のインターネット利用者にも将来のインターネット利用者にもメリットをもたらすサービスが提供可能である。また,WWWサーバ以外にも応用可能であるため多分野に渡り効果を得ることができる。」(段落【0201】)・【図1】(この発明の一実施形態による機能拡張手段等を備えたWWWサーバの処理の流れを示す図)・【図7】(この発明の一実施形態による機能拡張手段等を備えたWWWサーバの構成要素を示すブロック図)・【図17】(この発明の一実施形態による機能拡張手段等を備えたWWWサーバ処理装置の構成要素を示す図)イ上記記載によれば,本願発明1～9,12,13,15はインターネットにおけるウェブサイトの閲覧におけるURLの処理に関するものであり,半角英数字のみならず,漢字,ひらがな等の全角文字を含ませることにより,URLの表現力や利用価値を高めるとともにインターネットサービスを利用する際の障壁を下げることを目的とし,その解決手段として,従来のWWWサーバに文字列処理手段等を備えた機能拡張装置を備えるものであり,本願発明10,11,14はこれをインターネット以外の領域にまで広げた上,本願発明14は意図的なエラー誘発手段を構成要素としない発明であることが認められる。 (2)引用発明1の意義ア引用文献1(甲1)には,以下の記載がある。 (ｱ)「インターネットやイントラネットでWWWサーバを立ち上げるには,HTTPサーバであるhttpdを利用します.今回はhttpd(Apache)のインストールと活用について解説します.httpd(Hyper Text Tranfer Protocol Deamon)はハイパーテキストの転送を行うデーモン(すなわちサーバ)です.通常,Netscape NavigatorやInternet Exprolerなどのブラウザからの要求を受けて,ホームページのHTMLファイルなどを転送したりCGIスクリプトを実行させたりします.」(134頁左欄1行～10行)(ｲ)「現在主に使われているhttpdの1つにApacheがあります.これは,注1NCSA版httpdの改良から始まったhttpdで,NCSA httpd verl.3 (およびverl.4)と完全互換であり,さらにさまざまな機能拡張などを施したものです.また,NCSA httpdより高速なhttpdでもあります.Apacheの特徴の1つにモジュールによる機能拡張があります.サーバの機能をモジュールという形で与えることで,機能の追加/削除が簡単に行えます.モジュール集はhttp://www.zyzzyva.com/server/module_registry/などから手に入ります.今回は,このApacheをmake,インストールしてみることにしました.」(134頁右欄3行～16行)(ｳ)「apache_1.1.3.tar.gzをmake,インストールします.これはApach注2eのサポートサイト(http://www.apache.org/)から入手できます.また,日本語サイトhttp://apache.maizuru-ct.ac.jp/からミラーサイトが辿れます.まず,アーカイブを解くとapache_1.1.3/というディレクトリができます.ここに必要なファイルがすべて入っています.適当なディレクトリへ展開してください.筆者は/srcに展開しました.各ディレクトリ構成は表1のようになっています.」(134頁右欄18行～135頁左欄12行)(ｴ)「●表1ディレクトリ構成(apache_1.1.3/以下)cgi-bin/CGIプログラムconf/設定ファイル,最初はサンプルが入っているhtdocs/HTMLのサンプルが入っているicons/Fancylconで使うアイコンが入っているlogs/ログsrc/httpdのソースが入っているsupport/サポートプログラム,最初はサポートプログラムのソースが入っている」(135頁左欄1行～9行)(ｵ) 「apache_1.1.3/conf/以下のファイルを編集します.デフォルトでは,サーバルートが/usr/1oca1/etc/httpd/以下になっているので,これらのファイルをディレクトリごとコピーします.# cp -r /src/apache_1.1.3/??* /usr/local/etc/httpd/設定ファイルを自分の環境にふさわしいように書き換えます.httpd.confとsrm.conf,そしてaccess.confの3つを設定すれば,WWWサーバとして動作するようになります(それぞれ,表3のような役割をもちます).」(135頁右欄17行～26行)(ｶ)「●表3Apacheの設定ファイルファイル名役割見本ファイルaccess.confアクセス制限についての設定access.conf-disthttpd.confサーバの動作についての設定httpd.conf-distsrm.conf各ディレクトリやファイル名についての設定srm.conf-dist」(136頁1行目～5行)(ｷ)138頁右欄からsrm.confの設定についての記載があり,140頁左欄に「ScriptAlias」のタイトルで以下の記載がある。「●ScriptAliasCGIを置くディレクトリの別名を指定します。 ScriptAlias /cgi-bin/ /usr/Local/etc/httpd/cgi-bin/また,140頁左欄から右欄に「ErrorDocument」のタイトルで以下の記載がある。「●ErrorDocumentエラードキュメントをカスタマイズできます.エラードキユメントとは,誤ったURLを指定した場合などにクライアント上に表示されるドキュメントのことです.ここでカスタマイズすると,他のサーバ上にあるエラードキュメン卜を表示したり,CGIを使ったものを表示させたりすることができるようになります.エラードキュメントをプレーンテキストで表示するときには「”」の後に続けて,表示したいテキストを記述します.ローカルのファイルを表示させる場合には,そのファイルが存在するパスを絶対パスで記述します.ローカルのCGIの場合も同様に指定します.リモートにあるファイルを表示させるには,そのファイルの存在するURLを記述します.ErrorDocument 500 "The server made a boo boo.ErrorDocument 404 /missing.htmlErrorDocument 404 /cgi-bin/missing_handler.plErrorDocument 402 http://other.server.com/subscription_info.html｣イ?上記(ｱ),(ｲ)の記載から,「HTTPサーバであるAｐache」は通常「ブラウザからの要求を受けて,ホームページのHTMLファイルなどを転送する」こと,?上記(ｳ)～(ｷ)の記載から,cgi-binディレクトリ等にCGIプログラムを格納すること,?上記(ｳ)～(ｷ)の記載から,「誤ったURLを指定した場合」にクライアント上に表示されるエラードキュメントをカスタマイズできること,具体的には「CGIを使った」ものを表示させられること,?上記(ｱ)の記載から,HTTPサーバ(Aｐache)を利用する「WWWサーバ」が記載されていることを認めることができる。そうすると,引用文献1には,以下の発明(引用発明1)が記載されていると認めることができる。「HTTPサーバであるAｐacheが,通常,ブラウザからの要求を受けて,ホームページのHTMLファイルなどを転送し,cgi-binディレクトリにはCGIプログラムを格納し,設定ファイルには,誤ったURLを指定した場合に,クライアント上に表示されるエラードキュメントをカスタマイズして設定でき,上記設定は,EｒｒｏｒDｏcｕmenｔに指定することで,CGIを使ったものを表示させることができるようにした,WWWサーバ。」(3)対比・判断ア「HTTPサーバであるAｐache」が,通常,ブラウザからの要求を受けてホームページのHTMLファイルなどを転送することは,「既存情報処理手段」が「情報処理」することに相当する。引用発明1の「誤ったURLを指定した場合」は,「エラーが発生した時」に相当する。引用発明1で「誤ったURLを指定した場合」,CGIを使ったものを表示させるためには,当然にErrorDocumentで指定されたCGIプログラムを実行しているものであって,このCGIプログラムの実行はHTTPサーバであるAｐache(そのhttpdプログラム)とは別の情報処理手段に処理を分岐させることに相当する。また,CGIプログラムを実行させるのは,HTTPサーバであるAｐacheが誤ったURLの指定を検出した場合と解されるから,引用発明1も既存情報処理手段における情報処理結果の一部または全部を利用しているといえる。以上から,両者の一致点,相違点は次のとおりである。 <一致点>「既存情報処理手段が情報処理するに際して前記既存情報処理手段における情報処理結果の一部または全部を利用して処理を行う別の情報処理手段と,エラーが発生した時に前記既存情報処理手段から別の情報処理手段へと処理を分岐させる分岐手段とを備える装置」<相違点1>本願発明14においては,既存情報処理手段に対して,その外に外部情報処理手段があるのに対して,引用発明1では,既存情報処理手段に相当するWWWサーバが,別の情報処理手段に相当するCGIプログラムを備えている点。 <相違点2>本願発明14は「機能拡張装置」の発明であるのに対して,引用発明1はWWWサーバである点。イ<相違点1>についての判断誤ったURLを指定した場合に実行されるCGIプログラムは,既存情報処理手段であるHTTPサーバであるAｐache(そのhttpdプログラム)によりその実行を制御される別のプログラムであって,エラードキュメントの表示に関して付加的な情報処理手段を構成しているから,既存情報処理手段に対して外部情報処理手段といえるものである。また,情報処理分野において,付加的な情報処理手段を既存の情報処理手段に対して外部の情報処理手段として構成することは,何ら格別なことではなく適宜の設計事項である。よって,引用発明1のCGIプログラムを既存情報処理手段に相当するWWWサーバに対して外部情報処理手段として構成することは,当業者(その発明の属する技術の分野における通常の知識を有する者)が容易に想到し得ることである。ウ<相違点2>についての判断前記のとおり,引用発明1のCGIプログラムは,HTTPサーバであるAｐache(そのhttpdプログラム)に対して付加的な情報処理手段を構成し,CGIプログラムに記述された処理を行い,所定の表示をする機能を付加するものであるから,HTTPサーバであるAｐache(そのhttpdプログラム)に対して機能を拡張しているといえる。よって,引用発明1においてCGIプログラムによる処理を行う構成は,本願発明14の機能拡張装置に相当するといえるものである。エ以上によれば,本願発明14は引用発明1から当業者が容易に想到することができたものであると認めるのが相当である。したがって,本願発明14は引用発明1に基づいて当業者が容易に発明することができるとした審決の判断に誤りはない。 (4)原告の主張に対する補足的判断ア原告は,一般のサーバ運用者にとって,サーバのエラーを発生させるような状態に設定することへの動機はない旨主張するが(取消事由1),かかる主張は「エラー誘発手段」の存在を前提とする主張であるところ,本願発明14には「エラー誘発手段」は存在しない。したがって,引用発明1にエラーを発生させるような状態に設定することへの動機がないとしても,引用発明1から本願発明14を容易に想到できるか否かの判断に影響を与えるものではないと解されるから,原告の上記主張は採用することができない。なお,本願発明1～13との関係について付言すると,たしかに通常のサーバの利用に対しては利用者に不便を与えないため,エラーは避けるのが技術常識であると考えられる。しかし,特開平10-63597号公報(発明の名称「クライアント側,サーバ側および協調部で実行するURLのスペルチェック」,出願人サンマイクロシステムズインコーポレイテッド,公開日平成10年3月6日。甲6)の段落【0018】,【0052】及び図11には,「隠しファイル」のURLと類似のURLが入力され,この類似のURLのスペルミスを自動修正した結果「隠しファイル」のURLと一致してしまう場合には,最初から正しい隠しファイルのURLを入力できた利用者だけに,隠しファイルを表示させるためURLの自動修正機能をキャンセルし,その結果,スペル修正の候補がなくなれば「文書が見つかりません」のエラーメッセージを表示すること(ステップ1115)が記載されており,本願の出願当時(平成10年6月26日),セキュリティ上,意図的にエラーを発生させる場合があることが認められる。また,引用文献7(乙1)の1欄50～57行(訳文2頁16～21行),17欄24～27行(訳文23頁14～16行),18欄26行～30行(訳文24頁23行～26行)の記載によれば,キオスク端末からのネット接続に関して,ユーザの独り占めを防ぐため,閲覧するコンテンツの制限に加え閲覧時間も制限すること,ある時間が超過したらユーザが希望した情報を表示することに代えて,所定の警告メッセージを表示し,HTML文書を書き直してリンクを不能にすることが記載されているところ,このような利用時間を超過した場合の警告表示等は,意図的なエラー発生と同視できる。そうすると,本願出願当時(平成10年6月26日),不適切なサーバの利用に対しては,サーバやサーバ上のデータを保護する観点からエラーを意図的に発生させるべき場合があることが認識されていたことが認められ,引用発明1にエラーを発生させる動機付けがないとはいえない。したがって,サーバの設定がエラーを発生させるような状態に設定されていれば,エラーを誘発させ,サーバでの処理を分岐させ,文字列処理を行わせることに格別の困難性は認められないとした審決の判断に誤りがあるということはできない。イ次に原告は,取消事由2として,WWWサーバとWWWクライアントとの間の通信規約に定められたルールの一部を引用して,ブラウザに表示させるURLに日本語を使うことはできない旨主張する。しかし,原告の上記主張は請求項6～9に関するものであるところ,上記のとおり,請求項1に進歩性が認められない以上,取消事由2を検討するまでもなく,これに従属する請求項6～9にも進歩性は認められない。 3本願発明14の先願発明との実質的同一性(特許法29条の2)の有無について審理の経緯に鑑み,本願発明14の先願発明との実質的同一性(特許法29条の2)の有無について(取消事由3)も検討する。 (1)先願発明9の意義ア引用文献9(甲9)には,以下の記載がある。・【請求項1】「インターネット上に置かれている情報提供サーバに蓄積された情報資源をアクセスするためのURLを用いたインターネットへのアクセス方法であって,予めURLに対応する任意の文字列を割り当て,この割り当てられた文字列をクライアント側のインターネットへのアクセス機器から入力し,この入力された文字列をクライアント側またはサーバ側の文字列変換プログラムによって,割り当てられた文字列とURLとの対応関係を示す記憶テーブルを用いてURLに変換し,この変換されたURLでインターネット上の探査を行い,該当するデータをクライアント側の画面上に表示または記憶装置に取得することを特徴とするインターネットへのアクセス方法。」・【発明の詳細な説明】「ところが,このURLの入力はユーザにとっては思わぬ障害となっている。その理由はURLを構成する文字列が長く,しかも複雑な仕組みを持つことである。たとえばA株式会社のURLはそのホームページがどの管理下にあるかでhttp://www.a.co.jp/,http://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/のように変わり,その組み合わせは無限といえるほどである。このような複雑な仕組みを持つURLは入力を1字間違えただけでアクセスできず,しかも間違いの原因や箇所などを指摘する手段もないため,コンピュータやインターネットに精通したユーザ以外の利用は困難を極めている。」(段落【0004】)・「さらに,URLを構成する文字列は半角の英数字であるため,日本語をローマ字や英語で表さなければならないが,その際にもユーザにとって次のような障害がある。たとえば日本の通商産業省のホームページはMinistry of International Trade and Industryの略であるMITIを用いてhttp://www.miti.go.jp/となっているが,果たして通商産業省からmitiを想像することのできるユーザがどれほどいるであろうか。また,首相官邸のホームページはhttp://www.kantei.go.jp/と,今度は「官邸」をローマ字で表したURLが用いられている。このように,会社名,団体名,組織名,法人名,個人名,商品名,サービス名称,地名といったユーザになじみのある名称を元にURLが決められているのではないため,目的の情報資源へたどりつくためには「ｙahｏｏ」や「gｏｏ」といった検索エンジンに頼らざるを得ない状況となっている。」(段落【0005】)・「そこで,本発明の目的は,1回の入力に対して必ず唯一の結果を検索可能とし,かつキーボードに不慣れなユーザに長く複雑な文字列のURLを意識させることなく,このURLに対応する会社名,団体名,組合名,個人名,商品名,サービス名称,地名,電話番号あるいは任意の文字列を入力するだけでインターネットにアクセスすることができるインターネットへのアクセス技術を提供することにある。」(段落【0009】)・「まず,図1の説明図によりクライアント側のWWWブラウザから文字列変換プログラムを介してインターネットへアクセスする方法を説明する。クライアント側のWWWブラウザ11のアドレス欄に入力された文字列は,文字列変換プログラム12によってURL変換データベース13の中に入力された文字列と同一の文字列があるかが検査され,同一の文字列に対応するURLを取得し,取得されたURLをもってインターネット14へアクセスする。」(段落【0019】)・「前記文字列の入力には一般的なキーボードを用いる他に,マウスやペン,タッチパネルといったポインティングデバイスや,スキャナ,デジタルカメラ,OCRなどの光学的読みとり装置や,テレビなどの操作に用いるリモコン類や,音声で入力する音声認識インターフェースなどを用いることができる。」(段落【0020】)・「前記文字列変換プログラムはクライアント側にインストールする他に,LAN環境などではサーバ側に置くことも可能で,プロバイダ業者がユーザへのサービスとして本発明を利用するような環境では,プロバイダ業者の管理するサーバ側に置くことも可能である。」(段落【0021】)・「前記URL変換データベースは前記文字列変換プログラムと同一の場所に置くことも可能な他,たとえば前記文字列変換プログラムをクライアント側に置き,前記URL変換データベースをサーバ側に置くことも可能である。」(段落【0022】)・「次に,図2と図3,図4の説明図によりクライアント側のWWWブラウザへの文字列入力からインターネットへのアクセスに至るまでの処理手順を説明する。」(段落【0023】)・「ユーザが前記入力手段で入力した文字列を,全角文字や半角カタカナを含むか,あるいは図3のURLの構成に沿ったものであるかを調査し,全角文字や半角カタカナを含まず,かつ図3のURLの構成に沿ったものであれば入力された文字列をURLと見なして変換せずにインターネットへの探査を行う。前記文字列はプロトコル31,DNS32,ディレクトリ33,ファイル名34のいずれにあっても抽出が可能で,または入力が前記文字列だけであっても抽出が可能である。入力された文字列が図3のURLの構成に沿ったものでないか,全角文字や半角カタカナを含む場合は,入力された文字列で図4のURLデータベースを検索し,一致するURLを取得してインターネットへの探査を行う。図4のURL変換データベースに一致する文字列が見つからなければその旨のエラーメッセージを画面上に表示する。」(段落【0024】)・「ユーザがクライアント側のインターネットへのアクセス機器から入力した文字列を,任意の長さの漢字41,任意の長さのかな42,任意の長さの英字43の順に検索し,一致する場合は任意の長さのURL44を得てインターネットの探査を行う。このデータベース構成を格納する媒体は,クライアント側のハードディスクの他に,高速な検索を可能にするためのキャッシュとしてクライアント側のメモリーに持つことも可能で,さらに大量のデータを扱うためにCD-ROMやサーバ側のハードディスクに持つことも可能である。」(段落【0026】)・【図1】(本発明の実施の形態であるインターネットへのアクセス方法において,クライアント側のWWWブラウザから文字列変換プログラムを介してインターネットへアクセスする方法を示す説明図)・【図2】(本発明の実施の形態であるインターネットへのアクセス方法において,クライアント側のWWWブラウザへの文字列入力からインターネットへのアクセスに至るまでの処理手順を示すフロー図)・【図3】(本発明の実施の形態であるインターネットへのアクセス方法において,URLの構成を示す説明図)イ上記記載から,引用文献9は,半角英数字であるURLに対応するユーザになじみのある文字列を用いたインターネットへのアクセス技術を提供することを目的とするものであることが認められる。そして,同文献9において,「WWWブラウザに入力された文字列」を利用して「サーバ側」のデータベースを用いて検索を行うことは,「既存情報処理手段における情報処理結果の一部または全部」を利用して「前記既存情報処理手段の外」で「処理」を行うことに相当する。また,同文献9における「入力された文字列が全角文字や半角カタカナを含む場合」(図2のステップ22(No),23(Yes)の分岐)に「データベース検索」を行うことは,入力された文字列がURLとして通常想定される半角英数字と異なる文字列を含む時の処理であって,データベースに一致する文字列が見つからなければ「エラー」メッセージを表示する(図2のステップ26)ものであるから,「エラーが発生した時」に「外部情報処理手段へと処理を分岐させる」ことに相当する。また,「データベース検索」という機能拡張をするものである。そうすると引用文献9には次の発明(引用発明9)が記載されていることが認められる。「クライアント側のWWWブラウザ11のアドレス欄に,ユーザが入力手段で入力した文字列を,全角文字や半角カタカナを含むか,あるいはURLの構成に沿ったものであるかを調査し,全角文字や半角カタカナを含まず,かつURLの構成に沿ったものである場合,入力された文字列をURLと見なして変換せずにインターネットへの探査を行い,入力された文字列がURLの構成に沿ったものでないか,全角文字や半角カタカナを含む場合,入力された文字列でURLデータベースを検索し,一致するURLを取得してインターネットへの探査を行い,URL変換データベースに一致する文字列が見つからなければその旨のエラーメッセージを画面上に表示する,インターネットへのアクセスシステム。」(2)対比・判断上記のとおり,先願発明9は,ブラウザに入力された文字列がURLと見なせる場合,入力された文字列を変換せずインターネットを探索する処理を行うものであり,この場合にインターネット上に置かれている情報提供サーバに蓄積された情報資源をアクセスするための一連の動作は,既存情報処理手段による情報処理に相当する。一方,ブラウザに入力された文字列がURLと見なせない場合,入力された文字列でURL変換データベースを検索して一致するURLを取得し,もし一致する文字列がなければエラーメッセージを表示するものであり,入力された文字列がURLの構成に沿ったものでないか,全角文字や半角カタカナを含む場合は「エラーが発生した時」に相当し,その際URL変換データベースを検索する処理を行うことは,既存情報処理手段における情報処理結果の一部又は全部を利用して既存情報処理手段とは別の情報処理手段へ処理を分岐さた上,「URLデータベース検索」という機能拡張をして処理を行うことに相当する。したがって,本願発明は,引用発明2と実質的に同一の発明である。 (3)原告の主張に対する補足的判断ア原告は,引用文献9(甲9)には「URLを構成する文字列は半角の英数字であるため,日本語をローマ字や英語で表さなければならない」(段落【0005】)と記載されていることを根拠に,本願発明14と先願発明9は同一の発明ではないと主張する。しかし,引用文献9の上記記載は先願発明9が解決しようとする課題の一部であって先願発明の内容自体に関するものではない。そして,「・・・入力された文字列が図3のURLの構成に沿ったものでないか,全角文字や半角カタカナを含む場合は,入力された文字列で図4のURLデータベースを検索し,一致するURLを取得してインターネットへの探査を行う。・・・」(段落【0024】)と記載されていることからすれば,ブラウザに入力される文字列は半角英数文字に限定されないことが認められる。したがって,原告の上記主張は引用文献9を正解しないものであり,採用することができない。イ次に,原告は,引用文献9の段落【0024】の1行～5行目の記載によれば,引用文献9では,全角文字や半角カタカナを含む文字列をURLとみなしておらず,これと反対の立場に立つ本願発明1,10,12～15とは異なると主張する。しかし,全角文字等を含む文字列を「URL」に含むか否かは,何を「URL」とするかの「定義」の相違にすぎない。そして,前記のとおり,先願発明9は,「URL」に該当しない全角文字等であっても,URLに変換することにより処理できるものであってインターネットにアクセスできることを内容とする発明である。原告の上記主張は採用することができない。ウ次に,原告は,引用文献9の段落【0018】の記載によれば,先願発明9では「クライアント側」において「文字列変換プログラムを介」する必要があるが,本願発明1,10,12～15では不要であると主張する。しかし,原告が指摘する段落【0018】の記載及び図1には,文字列変換プログラムの位置が「クライアント側」との記載は存在せず,むしろ,請求項1及び段落【0021】には,文字列変換プログラムを「サーバ側」に設置できることが記載されている。よって,原告の上記主張はその前提において採用することができない。そもそも請求項14に各手段の位置は記載がなく,原告の主張は請求項の記載に基づかない主張である。エ次に,原告は,文字列変換プログラム(一般に「プラグイン」と称される。)をサーバ側に置く場合でも,処理対象文字列をクライアント側での普通の取扱いを変更してクライアント側からサーバ側へと伝達する,いわば「無変換パススループログラム」(プラグインの一種といえる。)を介する必要がある点に留意する必要があると主張する。しかし,引用文献9に「プラグイン」の用語自体の記載はなく,当然にプラグインが必要であることの記載もない。むしろ,段落【0024】の記載によれば,ブラウザに半角英数字以外を入力できるから,プラグインの検討は不要である。一方,本願の請求項14にプラグインを用いないことの記載はない。むしろ,本願明細書の段落【0069】に,ビジュアルURL(VURL)と呼ばれる点字や画像データをURLに含ませる実施例についての記載ではあるが,ブラウザ側で「プラグイン」を利用する記載があると認められる。よって,「プラグイン」の利用の有無は,本願発明との相違点となり得ず,原告の上記主張は採用することができない。 4結論以上によれば,その余について判断するまでもなく,請求不成立とした審決の結論に誤りはない。よって,原告の請求を棄却することとして,主文のとおり判決する。

事実及び理由

全容
第1請求特許庁が不服2005-8203号事件について平成21年1月26日にした審決を取り消す。
第2事案の概要本件は,原告が名称を「機能拡張装置および機能拡張方法ならびに機能拡張プログラムを記録した記録媒体」とする発明につき平成10年6月26日付けで特許出願をしたところ,拒絶査定を受けたので,これを不服として審判請求をしたが,特許庁から請求不成立の審決を受けたことから,その取消しを求めた事案である。
第3当事者の主張1請求の原因(1)特許庁における手続の経緯原告は,平成10年6月26日,名称を「機能拡張装置および機能拡張方法ならびに機能拡張プログラムを記録した記録媒体」とする発明について特許出願(特願平10-195108号,請求項の数15,以下「本願」という。公開公報は特開2000-20444号〔甲10〕)をしたが,特許庁から拒絶査定を受けたので,これに対する不服の審判請求をした。
特許庁は,同請求を不服2005-8203号事件として審理した上,平成21年1月26日,「本件審判の請求は,成り立たない。」との審決をし,その謄本は同年2月14日原告に送達された。
(2)発明の内容本願の内容は,以下のとおりである。
・【請求項1】既存WWWサーバがURLを処理するに際して意図的にエラーを誘発するエラー誘発手段と,前記既存WWWサーバが記憶手段に保持するデータのうち少なくともURLパス部を利用して処理を行う文字列処理手段と,前記エラー誘発手段によりエラーが発生した時に前記既存WWWサーバから前記文字列処理手段へと処理を分岐させる分岐手段とを備える機能拡張装置。
・【請求項2】既存WWWサーバがURLを処理するに際して意図的にエラーを誘発するエラー誘発手段と,前記既存WWWサーバが記憶手段に保持するデータのうち少なくともURLパス部を利用して処理を行う文字列処理手段と,前記エラー誘発手段によりエラーが発生した時に前記既存WWWサーバから前記文字列処理手段へと処理を分岐させる分岐手段とを備える機能拡張装置であって,前記エラー誘発手段により発生するエラーの程度またはタイミング等を変更するための条件変更手段を備える機能拡張装置。
・【請求項3】前記エラー誘発手段,前記文字列処理手段,ならびに前記分岐手段のうちの1または2以上の手段を,前記既存WWWサーバの固定的部位を何ら変更することなく備える請求項1または請求項2記載の機能拡張装置。
・【請求項4】前記URLパス部を含むURLは,WWWクライアントのURL入力表示欄で入力されたクライアント側入力文字列に由来し,前記文字列処理手段はWWWサーバに対してどのような形式をもっても伝達されない箇所以外は前記クライアント側入力文字列が入力された形式の表記にて獲得する獲得手段を備える請求項1または請求項2記載の機能拡張装置。
・【請求項5】前記URLパス部を含むURLは,WWWクライアントのURL入力表示欄で入力する以外の方法で入力されたまたは設定されたクライアント側入力文字列に由来し,前記文字列処理手段はWWWサーバに対してどのような形式をもっても伝達されない箇所以外は前記クライアント側入力文字列が入力された形式の表記にて獲得する獲得手段を備える請求項1または請求項2記載の機能拡張装置。
・【請求項6】前記URLパス部は漢字,ひらがなまたはカタカナを含み,CGIプログラム等へのパラメータ伝達を指示するものであるとRFCにより定義された文字列をその定義の通りに用いる用途では含まない請求項4または請求項5記載の機能拡張装置。
・【請求項7】前記URLパス部は(1)日本語や他の国または地域の言語の語句を含むか,(2)特定の学術分野等で用いられている記号類を用いた表記を含むか,または,(3)コンピュータ言語の命令やデータを含むかのいずれかあるいはそれらの2以上の組合せである請求項4または請求項5記載の機能拡張装置。
・【請求項8】前記URLパス部は検索を指示する文字列が含まれている請求項4または請求項5記載の機能拡張装置。
・【請求項9】前記文字列処理手段は,(1)RFCにより特別の意味が設定されている文字列のうちの少なくとも1についてこれを本来の文字そのままのデータとして処理する特別文字列普通解釈手段か,または,(2)予め定義されたまたは随時定義する文字列をRFCにより特別の意味が設定されている文字列と同等に処理する普通文字列特別解釈手段のうちの少なくとも一方を備える請求項4または請求項5記載の機能拡張装置。
・【請求項10】既存情報処理手段が情報処理するに際して意図的にエラーを誘発するエラー誘発手段処理ステップと,前記既存情報処理手段における情報処理結果の一部または全部を利用して前記既存情報処理手段の外で処理を行う外部情報処理手段と,前記エラー誘発手段によりエラーが発生した時に前記既存情報処理手段から外部情報処理手段へと処理を分岐させる分岐手段とを備える機能拡張装置。
・【請求項11】前記エラー誘発手段により発生するエラーの程度またはタイミング等を変更するための条件変更手段を備えている請求項10記載の機能拡張装置。
・【請求項12】既存WWWサーバがURLを処理するに際して意図的にエラーを誘発するエラー誘発設定ステップと,前記既存WWWサーバが記憶部に保持するデータのうち少なくともURLパス部を利用して処理を行う文字列処理ステップと,前記エラー誘発設定ステップによりエラーが発生した時に前記既存WWWサーバから前記文字列処理ステップへと処理を分岐させる分岐処理ステップとを備える機能拡張方法。
・【請求項13】既存WWWサーバがURLを処理するに際して意図的にエラーを誘発するエラー誘発設定ステップと,前記既存WWWサーバが記憶部に保持するデータのうち少なくともURLパス部を利用して処理を行う文字列処理ステップと,前記エラー誘発設定ステップによりエラーが発生した時に前記既存WWWサーバから前記文字列処理ステップへと処理を分岐させる分岐処理ステップとを備える機能拡張プログラムを記録した記録媒体。
・【請求項14】既存情報処理手段が情報処理するに際して前記既存情報処理手段における情報処理結果の一部または全部を利用して前記既存情報処理手段の外で処理を行う外部情報処理手段と,エラーが発生した時に前記既存情報処理手段から外部情報処理手段へと処理を分岐させる分岐手段とを備える機能拡張装置。
・【請求項15】既存WWWサーバがURLを処理するに際して前記既存WWWサーバが記憶手段に保持するデータの一部または全部を利用して処理を行う文字列処理手段と,エラーが発生した時に前記既存WWWサーバから前記文字列処理手段へと処理を分岐させる分岐手段とを備える機能拡張装置。
(3)審決の内容審決の内容は,別添審決写しのとおりであり,審決で引用された拒絶理由は別添拒絶理由通知書写し(一部省略)のとおりである。
その理由の要点は,本願の請求項1～15に係る発明は明確でない(特許法36条6項2号),請求項1～15に係る発明(本願各発明)は引用文献1～9に記載された発明との関係で進歩性を有しない(特許法29条2項),請求項1・10・12～15に記載された発明は引用文献9に記載された先願発明と実質的に同一である(特許法29条の2)等,である。
記・引用文献1:下村昭彦「つこてなんぼのFｒeeBSD第4回」,株式会社技術評論社,SｏfｔｗaｒeDeｓign,第81号,134頁～145頁,1997年(平成9年)7月18日発行・引用文献2:豊福剛「Little Script Pages[3]」,株式会社翔泳社,DDJ Dｒ.Dｏbb’s Jｏｕｒnal Jaｐan,6巻10号127頁～134頁,1997年(平成9年)9月1日発行・引用文献3:特開平9-6667号公報(発明の名称「プロファイルおよびトピックを使用したハイパーテキストの情報検索」,出願人サン・マイクロシステムズ・インコーポレーテッド,公開日平成9年1月10日。)・引用文献4:特開平6-89304号公報(発明の名称「テキスト処理システムにより使用されるテキストを準備する方法及び装置」,出願人サン・マイクロシステムズ・インコーポレーテッド,公開日平成6年3月29日。)・引用文献5:特開平3-15980号公報(発明の名称「文字列検索のための異表記及び同義語展開方法」,出願人株式会社日立製作所,公開日平成3年1月24日。)・引用文献6:特開平10-63597号公報(発明の名称「クライアント側,サーバ側および協調部で実行するURLのスペルチェック」,出願人サンマイクロシステムズインコーポレイテッド,公開日平成10年3月6日。)・引用文献7:米国特許5761683号公報(発明の名称「TECHNIQUES FOR CHANGING THE BEHAVIOR OF A LINK IN A HYPERTEXT DOCUMENT〔ハイパーテキスト・ドキュメント中のリンクの動作を変更するための技術〕」,権利者 Microtouch Systems,Inc., 公報発行日 1996年〔平成8年〕2月13日。)・引用文献8:特開平10-78928号公報(発明の名称「インターネットへのアクセス方法およびシステム,ならびにインターネットへのアクセス処理を記憶した記憶媒体」,出願人ディアンドアイシステムズ株式会社,公開日平成10年3月24日。)・引用文献9:特開平11-328076号公報(特願平10-152031号の願書に最初に添付した明細書及び図面,発明の名称「インターネットへのアクセス方法およびシステム」,出願人株式会社アテックス,出願日平成10年5月14日,公開日平成11年11月30日。)(4)審決の取消事由しかしながら,審決には,以下に述べるとおり誤りがあるので,審決は違法として取り消されるべきである。
ア取消事由1審決に表示された拒絶理由通知(甲11)は,「(理由4)進歩性」欄において,本願の請求項1,3,10,12～15に係る発明(以下「本願発明1,3,10,12～15」等という。)に関し,「・・・サーバの設定がエラーを発生させるような状態に設定されていれば,エラーを誘発させ,サーバでの処理を分岐させ,文字列処理を行わせることに格別の困静性は認められない。」(5頁12行～14行)とした。
しかし,一般のサーバ運用者又はその管理者は,サーバのエラーをできるだけ発生させずに運用することを望むものであり,不本意にも発生してしまったエラーについては,エラーログを参照するなどしてその原因を発見・除去して正常化させる(リカバーする)とするのが一般の運用である。
したがって,一般のサーバ運用者にとって,サーバのエラーを発生させるような状態に設定することへの動機はない。
また,引用文献1及び引用文献2には,サーバエラー発生時のリカバーについての記載はあるが,その逆については記載はない。
そして,サーバエラー発生時に既存のURLの処理をリカバーするのではなく,新たな発展的有効活用を図る処理を行うことは,視点を異にするものである。
イ取消事由2審決に表示された拒絶理由通知(甲11)は,「(理由4)進歩性」欄において,本願発明6～9に関し,「一般にWWWブラウザにおいて,URLパス部に漢字等の非アスキー文字を含むこと,または,含ませることを排除するものではない。」(5頁31行～31行)とした。
しかし,WWWサーバとWWWクライアント(WWWブラウザを含む)との間の通信規約はRFCなる文書群により「HTTP」なる名称でルールが定められているところ,そのルールの一部として,ある者は「ブラウザに表示させるURLに日本語を使うことはできません。」としており(甲15),ある者は「Webページを参照するためのURL(Unifｏｒm Reｓｏｕｒce Lｏcaｔｏｒ)は,本来1bｙｔe文字の英数字のみが使用できる。」等としているから(甲17,30,31),上記認定は誤りである。
ウ取消事由3審決に表示された拒絶理由通知(甲11)は,「(理由7)新規性」欄において,本願発明1,10,12～15は引用文献9(甲9)に記載された発明と同一である旨認定した。
しかし,上記認定は誤りであり,その理由は次のとおりである。
(ｱ)引用文献9には「・・・URLを構成する文字列は半角の英数字であるため,日本語をローマ字や英語で表さなければならない」(段落【0005】)と記載されていること。
(ｲ)引用文献9の段落【0024】の1行～5行目の記載によれば,引用文献9に記載された発明の実施の形態における処理手順では,全角文字や半角カタカナを含む文字列をURLとみなしておらず,これと反対の立場に立つ本願発明1,10,12～15とは違いがあること。
(ｳ)引用文献9の段落【0018】3行目の記載によれば,引用文献9記載の発明の実施の形態では,「クライアント側」において「文字列変換プログラムを介」する必要があるが,本願発明1,10,12～15では不要であること。
(ｴ)文字列変換プログラム(一般に「プラグイン」と称される。)をサーバ側に置く場合でも,処理対象文字列をクライアント側での普通の取扱いを変更してクライアント側からサーバ側へと伝達する,いわば「無変換パススループログラム」(プラグインの一種といえる。)を介する必要がある点に留意する必要があること。
なお,原告は,本願の早期審査に関する事情説明書(甲17)において,「ホームページのアドレス(URL)において漢字やひらがな等の利用を可能にする新しい技術(仮称:「漢字URL」)」の概要の1つとして,「ウェブブラウザ(閲覧ソフト)側には特殊な設定は不要。現行のブラウザをそのまま利用可能。」としており,同技術においてクライアント側でのプラグインが不要である旨表示している。
(ｵ)引用文献9における文字列変換は,入力:URLでない文字列(例えば首相官邸),出力:RFC準拠文字列,介在者:プラグインである一方,本願発明1,10,12～15では,入力:RFC非準拠URL(http://RURL.NET/首相官邸),出力:RFC準拠URL,介在者なしであり,両者の構成は異なる。
エ取消事由4審決に表示された拒絶理由通知(甲11)は,「(理由6)進歩性」欄において,本願発明1,10,12～15は引用文献8(甲8)に記載された発明に基づいて容易に発明をすることができたとしたが,誤りである。
その理由は次のとおりである。
(ｱ)引用文献8の段落【0012】の記載によれば,「アクセス機器」から入力された番号はクライアント側又はクライアント側から「番号変換サーバ」側へと伝達した後,サーバ側で「URLに逆変換」する。よって,クライアント側において何らかのプラグインが必要であるが,本願発明1,10,12～15では不要である。
(ｲ)引用文献8に記載された発明は,本願各発明に関する国際調査報告(甲12)で関連文献の1つとして評価済みであり,その評価結果は「A」カテゴリー,すなわち「特に関連のある文献ではなく一般的技術水準を示すもの」に止まる。
オ取消事由5審決に表示された拒絶理由通知(甲11)は,「(理由5)進歩性」欄において,本願発明1,3,10,12～15は「WWWクライアントにおいて,英語以外の漢字,カタカナ,ひらがななどの言語の文字列が入力された場合にも,処理を分岐させて文字列処理をすることは,例えば引用文献4,5等に示されるように周知技術である。」と認定しているが,誤りである。なぜなら,被告は,「クライアント側において何らかのプラグインが必要である」ことの要否の検討を欠いているからである。
カ取消事由6本件審決で表示された拒絶理由通知(甲11)は,「(理由1)記載不備」,「(理由2)記載不備」,および「(理由3)記載不備」欄にて記載不備をいうが,誤りである。その理由は次のとおりである。
(ｱ)請求項1中の「意図的に」なる記載が明確でないとの指摘は当たらない。「意図的に」は「わざと」と換言できる。後者の語を用いると請求項1中の「意図的にエラーを誘発する」は「わざとエラーを引き起こす」と変形することができる。これと同様の表現は他の文献(雑誌「OPEN DESIGN」2002年2月号,第9巻第2号,2002年(平成14年)2月1日発行,甲16)にも見ることができ,難無く解釈でき,不明確ではない。また,「意図的に」の具体的内容は,本願明細書の段落【0150】【0167】【0171】に記載がある。
請求項2,13についても同様である。
(ｲ)請求項1中の「機能拡張装置」における「機能拡張」の技術的範囲が不明であるとの指摘は当たらない。請求項1は「既存WWWサーバがURLを処理するに際して意図的にエラーを誘発するエラー誘発手段と,前記既存WWWサーバが記憶手段に保持するデータのうち少なくともURLパス部を利用して処理を行う文字列処理手段と,前記エラー誘発手段によりエラーが発生した時に前記既存WWWサーバから前記文字列処理手段へと処理を分岐させる分岐手段とを備える」「装置」をクレームしている。そして当該「装置」を「機能拡張装置」と称しているにすぎない。同請求項中の「意図的にエラーを誘発するエラー誘発手段」と同様の表現である。
他の請求項中の「機能拡張装置」,「機能拡張方法」,「機能拡張プログラム」の各語についても同様である。
(ｳ)請求項3中の「固定的部位を何ら変更することなく備える」が日本語として明確でないとの指摘は当たらない。「固定的部位」については本願明細書段落【0038】に記載がある。
(ｴ)審決は,請求項4,5中の「以外」なる記載は範囲をあいまいにする表現である結果,発明の範囲が不明確であるとするが,その指摘は当たらない。例えば,「整数のうちの奇数以外」は即ち「整数のうちの偶数」である。「以外」の語の利用のみをもって前記発明が発明の範囲が不明確であるとはいえない。
(ｵ)請求項6中の「用いる用途では含まない」なる記載が日本語として明確でないとの指摘は当たらない。URLパス部について「CGIプログラム等へのパラメータ伝達を指示するものであるとRFCにより定義された文字列をその定義の通りに用いる用途では含まない」については本願明細書【0056】に記載がある。
(ｶ)請求項9中の「随時定義」なる記載が具体的にどのような手段によりどのように定義するのか明確でないとの指摘は当たらない。その前後も含めて示せばこの記載は,「予め定義されたまたは随時定義する文字列」である。この表現の中には「予め定義された文字列(静的なもの)」と「随時定義する文字列(動的なもの)」とが含まれる。後者は「予め定義されるのではない文字列(静的ではないもの)」の言い換えであり,表現として明確である。
(ｷ)請求項9中の「同等に処理」なる記載中の「同等」が明確でないとの指摘は当たらない。その前後も含めて示せばこの記載は,「予め定義された又は随時定義する文字列をRFCにより特別の意味が設定されている文字列と同等に処理する普通文字列特別解釈手段」である。
一部を記号化して整理すれば「文字列Xを文字列Yと同等に処理する手段Z」(「実際には文字列Yとは異なる文字列Xを,文字列Yと等価なものとして処理する,手段Z」)となる。
(ｸ)請求項10中の「エラー誘発手段処理ステップ」なる記載が明確でないとの指摘は当たらない。その前方も含めて示せばこの記載は,「意図的にエラーを誘発するエラー誘発手段処理ステップ」である。
ここでは「意図的にエラーを誘発するステップ」が説明部である。そして当該「ステップ」を「エラー誘発手段処理ステップ」と称しているに過ぎない。請求項12,13中の「エラー誘発設定ステップ」についても同様である。
(ｹ)請求項6中の「(CGI)プログラム等」が明確でないとの指摘は当たらない。「等」を削除して「CGIプログラム」と限定すべきではない。本願各発明出願当時,当業者においてはCGIプログラムと類似の技術は知られていた。今後も新たなCGIプログラム類似技術は生じうるのだから,「CGIプログラム等」の表現は適当である。
また,URLの構文については,本願明細書の段落【0023】において,「正確な意味はURLに関するRFCを参照されたい。」と記載しているが,本願各発明出願当時の規約であるRFC1738及びその更新版であるRFC2396には,URLパス部に係る外部情報処理手段についてCGIプログラムに限定する旨の記載は無い。
請求項7中の「(特定の)学術分野等(で用いられている記号類)」について明確でないとの指摘は当たらない。この部分は,本願明細書中の用語「FｘURL」で表現可能な「記号類」である。
請求項2,11中の「(発生するエラーの程度または)タイミング等(を変更するための条件変更手段)」について明確でないとの指摘は当たらない。この「条件変更手段」については,本願明細書段落【0035】において,「エラーを誘発するための条件を変更する条件変更手段」と記載されている。加えて,変更の対象は限定されているが,変更の内容は特に限定されていない(本願明細書段落【0154】及び図7参照)。よって,前記「タイミング等」中の「等」の有無でこれらの請求項に係る発明の外延が不明瞭になることはない。
(ｺ)請求項1,2,7,9,12,13,15中の「データ」は具体的にどのようなデータを意味するのか明確でないとの指摘は当たらない。
請求項1,2,15では「前記既存WWWサーバが記憶手段に保持するデータ」と記載している。請求項12,13では「前記既存WWWサーバが記憶部に保持するデータ」と記載している。請求項7では「コンピュータ言語の命令やデータ」と記載している。前者はコンピュータ言語において演算を指定する表現であり,後者はコンピュータ言語における演算の対象である。請求項9では「RFCにより特別の意味が設定されている文字列のうちの少なくとも1についてこれを本来の文字そのままのデータとして」と記載している。ここで「本来の文字そのままのデータとして」は,「本来の文字そのままで,すなわち,RFCにより設定されている特別の意味を解除して」の意であり,表現は明確である。
(ｻ)請求項1～3,10～15中の「エラー」は具体的にどのようなエラーを意味するのか明確でないとの指摘は当たらない。無用の限定をする必要はない。仮に,現バージョンのHTTPのステータスコードに則して限定した場合,将来バージョンのHTTPにおける「エラー」を対象外としてしまう危険がある。加えて請求項10,11,14ではHTTP以外のプロトコル(例:SMTP,DNS,FTP)についても適用関係がある(本願明細書段落【0096】～【0101】,【0132】及び図3参照)から,HTTPステータスコードによる限定は無理がある。
(ｼ)請求項2,11中の「エラーの程度またはタイミング等を変更するための条件変更手段」なる記載につき,発明の詳細な説明においても,それ以上の具体的な記載がないとの指摘は当たらない。請求項2は「<請求項1>+<条件変更手段>」と模式化できる。この<条件変更手段>は本願明細書の段落【0154】,【0158】,【0178】,【0199】及び図7(とりわけ条件変更部708)に記載済みである。これらの記載を基礎により広くて明瞭な表現にすべきだったのを怠った点は認める。実際には,本願明細書段落【0035】及び【0036】の内容に引きずられた結果,請求項2を不明瞭にした。
また,前記「機能拡張装置」と同様の表現でこの<条件変更手段>を表現できなかった。請求項11についても同様である。
(ｽ)請求項4,5中の「由来し」なる記載が,発明の詳細な説明におけるどの記載のことを意味するのか明確でないとの指摘は当たらない。
その前方も含めて示せばこの記載は,「WWWクライアントのURL入力表示欄で入力されたクライアント側入力文字列に由来し」である。
この<○○側に由来し>なる表現はWWW中継処理装置(206)の存在を念頭に置いたものであり,本願明細書の段落【0041】～【0043】及び図2に記載がある。
(ｾ)請求項4,5中の「形式」なる記載が発明の詳細な説明におけるどの記載のことを意味するのか明確でないとの指摘は当たらない。この点は本願明細書の段落【0044】～【0046】に記載がある。
(ｿ)請求項5中の「以外の方法」なる記載が発明の詳細な説明におけるどの記載のことを意味するのか明確でないとの指摘は当たらない。その前方も含めて示せばこの記載は,「WWWクライアントのURL入力表示欄で入力する以外の方法で入力された」である。この記載の否定形に相当する入力方法は「WWWクライアントのURL入力表示欄で入力するという方法で入力された」である。これら2点の表現はいずれも明確である。これら2点については相違点も含めて本願明細書の段落【0050】～【0055】に記載がある。
(ﾀ)請求項7中の「2以上の組合せ」なる記載が発明の詳細な説明におけるどの記載のことを意味するのか明確でないとの指摘は当たらない。
本願明細書中の用語「FｘURL」の定義から,当然に「2以上の組合せ」がありうる(本願明細書段落【0062】及び図14参照)。
(ﾁ)請求項9中の「少なくとも一方を備える」なる記載に関連して「両方を備える場合」が発明の詳細な説明におけるどの記載のことを意味するのか明確でないとの指摘は当たらない。機能の異なる文字列処理手段を複数多種準備してこれらを活用する点については,本願明細書の段落【0036】,【0037】,【0096】に記載がある。
2請求原因に対する認否請求原因(1)(2)(3)の各事実は認めるが,(4)は争う。
3被告の反論審決の認定判断に誤りはなく,原告主張の取消事由は理由がない。
(1)本願発明14は引用発明1との関係で進歩性がないア(ｱ)引用文献1(甲1)には,以下の記載がある。
・「インターネットやイントラネットでWWWサーバを立ち上げるには,HTTPサーバであるhttpdを利用します.今回はhttpd(Apache)のインストールと活用について解説します.」(134頁左欄1行～4行)・「現在主に使われているhttpdの1つにApacheがあります.これは,注1NCSA版httpdの改良から始まったhttpdで,NCSA httpd verl.3 (およびverl.4)と完全互換であり,さらにさまざまな機能拡張などを施したものです.また,NCSA httpdより高速なhttpdでもあります.Apacheの特徴の1つにモジュールによる機能拡張があります.サーバの機能をモジュールという形で与えることで,機能の追加/削除が簡単に行えます.モジュール集はhttp://www.zyzzyva.com/server/module_registry/などから手に入ります.今回は,このApacheをmake,インストールしてみることにしました.」(134頁右欄3行～16行)・「apache_1.1.3.tar.gzをmake,インストールします.これはApach注2eのサポートサイト(http://www.apache.org/)から入手できます.また,日本語サイトhttp://apache.maizuru-ct.ac.jp/からミラーサイトが辿れます.まず,アーカイブを解くとapache_1.1.3/というディレクトリができます.ここに必要なファイルがすべて入っています.適当なディレクトリへ展開してください.筆者は/srcに展開しました.各ディレクトリ構成は表1のようになっています.」(134頁右欄18行～135頁左欄12行)・「●表1ディレクトリ構成(apache_1.1.3/以下)cgi-bin/CGIプログラムconf/設定ファイル,最初はサンプルが入っているhtdocs/HTMLのサンプルが入っているicons/Fancylconで使うアイコンが入っているlogs/ログsrc/httpdのソースが入っているsupport/サポートプログラム,最初はサポートプログラムのソースが入っている」(135頁左欄1行～9行)・「apache_1.1.3/conf/以下のファイルを編集します.デフォルトでは,サーバルートが/usr/1oca1/etc/httpd/以下になっているので,これらのファイルをディレクトリごとコピーします.# cp -r /src/apache_1.1.3/??* /usr/local/etc/httpd/設定ファイルを自分の環境にふさわしいように書き換えます.httpd.confとsrm.conf,そしてaccess.confの3つを設定すれば,WWWサーバとして動作するようになります(それぞれ,表3のような役割をもちます).」(135頁右欄17行～26行)・「●表3Apacheの設定ファイルファイル名役割見本ファイルaccess.confアクセス制限についての設定access.conf-disthttpd.confサーバの動作についての設定httpd.conf-distsrm.conf各ディレクトリやファイル名についての設定srm.conf-dist」(136頁1行目～5行)・138頁右欄からsrm.confの設定についての記載があり,140頁左欄から右欄に「ErrorDocument」のタイトルで以下の記載がある。
「ErrorDocumentエラードキュメントをカスタマイズできます.エラードキユメントとは,誤ったURLを指定した場合などにクライアント上に表示されるドキュメントのことです.ここでカスタマイズすると,他のサーバ上にあるエラードキュメン卜を表示したり,CGIを使ったものを表示させたりすることができるようになります.エラードキュメントをプレーンテキストで表示するときには「”」の後に続けて,表示したいテキストを記述します.ローカルのファイルを表示させる場合には,そのファイルが存在するパスを絶対パスで記述します.ローカルのCGIの場合も同様に指定します.リモートにあるファイルを表示させるには,そのファイルの存在するURLを記述します.ErrorDocument 500 "The server made a boo boo.ErrorDocument 404 /missing.htmlErrorDocument 404 /cgi-bin/missing_handler.plErrorDocument 402 http://other.server.com/subscription_info.html｣(ｲ)以上の記載から引用文献1には以下の発明(引用発明1)が記載されていることが認められる。
「HTTPサーバであるApacheがインストールされ,cgi-binディレクトリにはCGIプログラムを格納し,設定ファイルsrm.confには,誤ったURLを指定した場合にクライアント上に表示されるエラードキュメントをカスタマイズして設定でき,上記設定は,エラードキュメントをプレーンテキストで表示するときには「”」の後に続けて,表示したいテキストを記述し,ローカルのファイルを表示させる場合には,そのファイルが存在するパスを絶対パスで記述し,リモートにあるファイルを表示させるには,そのファイルの存在するURLを記述し,ローカルのCGIの場合も同様に指定し,CGIを使ったものを表示させることができるようにし,リモートにあるファイルを表示させるには,そのファイルの存在するURLを記述するようにした,WWWサーバ」イ対比・判断(ｱ)本願発明14を引用発明1と比較する。
引用発明1であるWWWサーバは既存情報処理手段に相当し,WWWサーバにはApacheがインストールされて情報処理を行っていることは明白である。引用発明1は誤ったURLを指定するとCGIプログラムを使ったものを表示しているから,誤ったURLを指定した時にCGIプログラムに処理を分岐しているといえる。そして,誤ったURLを指定することは「エラーが発生した時」に相当し,CGIプログラムによる処理をすることは別の情報処理手段に処理を分岐させることに相当する。
また,CGIプログラムに処理を分岐するのは,WWWサーバが情報処理を行い,誤ったURLを指定したことを検出したときと解されるから,引用発明1においても既存情報処理手段における情報処理結果の一部または全部を利用しているといえる。
以上から,両者の一致点,相違点は次のとおりである。
<一致点>「既存情報処理手段が情報処理するに際して前記既存情報処理手段における情報処理結果の一部または全部を利用して処理を行う情報処理手段と,エラーが発生した時に前記既存情報処理手段から別の情報処理手段へと処理を分岐させる分岐手段とを備える装置」<相違点1>本願発明14においては,既存情報処理手段に対して,その外に外部情報処理手段があるのに対して,引用発明1では,既存情報処理手段に相当するWWWサーバが,別の情報処理手段に相当するCGIプログラムを備えている点。
<相違点2>本願発明14は「機能拡張装置」の発明であるのに対して,引用発明1はWWWサーバである点。
(ｲ)次に相違点について検討する。
・<相違点1>について引用発明1は,誤ったURLを指定したときにCGIプログラムへ分岐し,このCGIプログラムが作動してエラードキュメントを表示しているところ,このCGIプログラムは,WWWサーバに対して付加的な情報処理手段を構成しているから,既存情報処理手段に対して外部情報処理手段といえるものである。また,情報処理分野において,付加的な情報処理手段を既存の情報処理手段に対して外部の情報処理手段として構成することは,何ら格別なことではなく,適宜に設計し得る事項である。
よって,引用発明1のCGIプログラムを,既存情報処理手段に相当するWWWサーバに対して外部情報処理手段として構成することは,当業者が容易に想到し得る事項である。
・<相違点2>について前記のとおり,引用発明1のCGIプログラムは,WWWサーバに対して付加的な情報処理手段を構成し,CGIプログラムに記述された処理を行うものであるから,WWWサーバに対して機能を拡張しているといえる。そして,原告の主張によれば,既存のWWWサーバ以外の処理手段を指すものを「機能拡張装置」と「称しているにすぎない」ものであるから,引用発明1においてCGIプログラムによる処理を行う構成は,本願発明14の機能拡張装置に相当するといえるものである。
よって,相違点2は格別のものではない。
・以上から,相違点1及び2は格別のものではなく,本願発明14は引用発明1から当業者が容易に想到することができたものである。
(2)本願発明14は先願発明9との関係で新規性がないア(ｱ)引用文献9(甲9)には,以下の記載がある。
・「【0004】ところが,このURLの入力はユーザにとっては思わぬ障害となっている。その理由はURLを構成する文字列が長く,しかも複雑な仕組みを持つことである。たとえばA株式会社のURLはそのホームページがどの管理下にあるかでhttp://www.a.co.jp/,http://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/のように変わり,その組み合わせは無限といえるほどである。このような複雑な仕組みを持つURLは入力を1字間違えただけでアクセスできず,しかも間違いの原因や箇所などを指摘する手段もないため,コンピュータやインターネットに精通したユーザ以外の利用は困難を極めている。」・「【0005】さらに,URLを構成する文字列は半角の英数字であるため,日本語をローマ字や英語で表さなければならないが,その際にもユーザにとって次のような障害がある。たとえば日本の通商産業省のホームページはMinistry of International Trade and Industryの略であるMITIを用いてhttp://www.miti.go.jp/となっているが,果たして通商産業省からmitiを想像することのできるユーザがどれほどいるであろうか。また,首相官邸のホームページはhttp://www.kantei.go.jp/と,今度は「官邸」をローマ字で表したURLが用いられている。このように,会社名,団体名,組織名,法人名,個人名,商品名,サービス名称,地名といったユーザになじみのある名称を元にURLが決められているのではないため,目的の情報資源へたどりつくためには「ｙahｏｏ」や「gｏｏ」といった検索エンジンに頼らざるを得ない状況となっている。」・「【0019】まず,図1の説明図によりクライアント側のWWWブラウザから文字列変換プログラムを介してインターネットへアクセスする方法を説明する。クライアント側のWWWブラウザ11のアドレス欄に入力された文字列は,文字列変換プログラム12によってURL変換データベース13の中に入力された文字列と同一の文字列があるかが検査され,同一の文字列に対応するURLを取得し,取得されたURLをもってインターネット14へアクセスする。」・「【0020】前記文字列の入力には一般的なキーボードを用いる他に,マウスやペン,タッチパネルといったポインティングデバイスや,スキャナ,デジタルカメラ,OCRなどの光学的読みとり装置や,テレビなどの操作に用いるリモコン類や,音声で入力する音声認識インターフェースなどを用いることができる。」・「【0021】前記文字列変換プログラムはクライアント側にインストールする他に,LAN環境などではサーバ側に置くことも可能で,プロバイダ業者がユーザへのサービスとして本発明を利用するような環境では,プロバイダ業者の管理するサーバ側に置くことも可能である。」・「【0022】前記URL変換データベースは前記文字列変換プログラムと同一の場所に置くことも可能な他,たとえば前記文字列変換プログラムをクライアント側に置き,前記URL変換データベースをサーバ側に置くことも可能である。」・「【0023】次に,図2と図3,図4の説明図によりクライアント側のWWWブラウザへの文字列入力からインターネットへのアクセスに至るまでの処理手順を説明する。」・「【0024】ユーザが前記入力手段で入力した文字列を,全角文字や半角カタカナを含むか,あるいは図3のURLの構成に沿ったものであるかを調査し,全角文字や半角カタカナを含まず,かつ図3のURLの構成に沿ったものであれば入力された文字列をURLと見なして変換せずにインターネットへの探査を行う。前記文字列はプロトコル31,DNS32,ディレクトリ33,ファイル名34のいずれにあっても抽出が可能で,または入力が前記文字列だけであっても抽出が可能である。入力された文字列が図3のURLの構成に沿ったものでないか,全角文字や半角カタカナを含む場合は,入力された文字列で図4のURLデータベースを検索し,一致するURLを取得してインターネットへの探査を行う。図4のURL変換データベースに一致する文字列が見つからなければその旨のエラーメッセージを画面上に表示する。」(ｲ)以上の記載から,引用文献9に係る特許出願の願書に最初に添付した明細書又は図面には次の発明(以下「先願発明9」という。)が記載されている。
「クライアント側のWWWブラウザ11のアドレス欄にユーザは文字列を入力し,ユーザが入力手段で入力した文字列を,全角文字や半角カタカナを含むか,あるいはURLの構成に沿ったものであるかを調査し,全角文字や半角カタカナを含まず,かつURLの構成に沿ったものであれば入力された文字列をURLと見なして変換せずにインターネットへの探査を行い,文字列はプロトコル31,DNS32,ディレクトリ33,ファイル名34のいずれにあっても抽出が可能で,または入力が前記文字列だけであっても抽出が可能であり,入力された文字列がURLの構成に沿ったものでないか,全角文字や半角カタカナを含む場合は,入力された文字列でURLデータベースを検索し,一致するURLを取得してインターネットへの探査を行い,URL変換データベースに一致する文字列が見つからなければその旨のエラーメッセージを画面上に表示する,インターネットへのアクセスシステム。」イ対比・判断本願発明14と先願発明9とを対比する。
先願発明9において,ユーザはクライアント側のブラウザのアドレス欄に文字列を入力しており,該文字列はアドレスとして扱われる点でURLに相当し,通常のURLを入力した時は文字列変換をしないでインターネットへの探査を行うことは既存情報処理手段が作動することに相当し,ユーザが入力したURLに全角文字や半角カタカナが含まれていたときは,エラーが発生した時に相当し,URLデータベースを検索する処理を行うことは外部情報処理手段へ処理を分岐させることに相当する。
よって,本願発明14は先願発明9と実質的に同一の発明である。
(3)取消事由1及び2に対しア原告は,審決で表示された拒絶理由通知の「サーバの設定がエラーを発生させるような状態に設定されていれば,エラーを誘発させ,サーバでの処理を分岐させ,文字処理を行わせることに格別の困難性は認められない。」(5頁12行～14行)との認定は誤りであると主張する。
しかし,本願各発明におけるエラー発生は,URL処理において,漢字等がURLに使用された場合に対する文字列処理を行わせるために,通常のURL処理から別処理に分岐させるための便法の一つとして採用したものであり,該分岐処理を行わせ得る手法であればエラー発生に限定されるものではなく,エラー発生が不可欠といえるものではない。また,例えば一般のサーバでの処理において,サーバの特定ファイルへのアクセスや特定ユーザからのサーバへのアクセスを制限するようなケースは,通常の運用において当然想定されるものであり,そのような制限に該当するならば,あたかもそれをエラー発生のように取扱って通常の処理とは別の処理に移行させ,それに応じてエラー頁を表示させるようにすることも運用上ごく普通に行われていることであるから,エラーを発生させるような設定は必要に応じて適宜に行われることである。そして,エラーを発生させるような設定を行うことは,当然処理態様として通常処理とは別処理を行うことに他ならず,すなわちサーバでの処理が分岐処理となることは容易に首肯し得る。
してみると,審決が拒絶理由通知を引用して「サーバの設定がエラーを発生させるような状態に設定されていれば,エラーを誘発させ,サーバでの処理を分岐させ,文字処理を行わせることに格別の困難性は認められない。」と認定したことに誤りはない。
イ原告は,WWWサーバとWWWクライアントとの間の通信規約に定められたルールの一部を引用して,ブラウザに表示させるURLに日本語を使うことはできない旨主張する。
確かに,本願明細書(甲10)の段落【0016】に記載があるように,雑誌(「日経コミュニケーション」第268号,1998年(平成10年)4月20日発行,甲15)の記事中に「ブラウザに表示させるURLに日本語を使うことはできません。」の記載があるが,本願明細書において,続く段落【0017】から段落【0018】に記載されているように,URL入力として漢字等を入力することは可能であるところ,入力した漢字等がURLとして機能を果たすか否かに問題があり,上記雑誌の記事は,それがURLとして機能を果たさないから「日本語を使うことはできません」としたまでのことで,日本語を使うこと自体が全く排除されていたわけではない。
してみると,審決が拒絶理由通知を引用して「一般にWWWブラウザにおいて,URLパス部に漢字等の非アスキー文字を含むこと,または含ませることを排除するものではない。」と認定したことに誤りはない。
(4)取消事由3に対し引用文献9(甲9)には,段落【0019】に「クライアント側のWWWブラウザ11のアドレス欄に入力された文字列は,文字列変換プログラム12によってURL変換データベース13の中に入力された文字列と同一の文字列があるかが検査され,同一の文字列に対応するURLを取得し,取得されたURLをもってインターネット14へアクセスする。」,段落【0024】に「ユーザが前記入力手段で入力した文字列を,全角文字や半角カタカナを含むか,あるいは図3のURLの構成に沿ったものであるかを調査し,全角文字や半角カタカナを含まず,かつ図3のURLの構成に沿ったものであれば入力された文字列をURLと見なして変換せずにインターネットへの探査を行う。」及び「入力された文字列が図3のURLの構成に沿ったものでないか,全角文字や半角カタカナを含む場合は,入力された文字列で図4のURLデータベースを検索し,一致するURLを取得してインターネットへの探査を行う。」との記載があり,引用文献9においてブラウザに入力される文字列は半角英数字に限定されておらず,全角文字や半角カタカナを含む文字列を入力でき,全角文字や半角カタカナを含む場合はURLデータベースを検索することが記載されているものであるから,引用文献9においてプラグインについての検討をする必要はない。また,原告は,「本願発明では,ウェブブラウザ側には特殊な設定は不要で,クライアント側でのプラグインが不要である。」と主張しているが,上記主張は,本願の明細書及び図面の記載に基づかない。
よって,原告の主張は理由がない。
(5)取消事由4に対し引用文献8(甲8)の段落【0105】に記載されているように,クライアント側は入力された番号をウェブサーバに送る機能を有するものであるから,引用文献8においてプラグインについての検討をする必要はないし,また,クライアントからの入力が原告の主張するようなブラウザによるとしても,日本語を入力することが排除されているわけではないので,原告の主張は理由がない。
また,原告は,引用文献8が国際調査報告においてカテゴリーA相当の刊行物であったと主張しているが,そのことが本件における拒絶査定のように,進歩性を否定するための引例として引用文献8を引用することを拘束するものではない。国際調査報告の作成後に関連分野の技術水準や周知技術に関する知見を得ることにより,当該刊行物に対する評価が変化することは十分に想定されることであり,国際調査報告時の評価がそのまま各国審査段階時の評価に踏襲されるものではない。また,特許協力条約 33条に記載されているように,国際予備審査は予備的かつ拘束力のない見解を示すものである。
(6)取消事由5に対し本願明細書(甲10)の段落【0016】～【0018】に記載されているように,WWWクライアントにおいて日本語を入力することが排除されているわけではないし,引用文献4～引用文献7(甲4～7)に記載された文字列処理や分岐処理は,いろいろな種類の文字を受け付けて処理する機能を有するものであるから,プラグインの必要性についての検討を欠くとの原告の主張は理由がない。
(7)取消事由6に対しア原告は,請求項1等に記載した「意図的に」は「わざと」と換言でき,同様の表現を他の文献(甲16)にも見ることができるから,難無く解釈でき,不明確ではない旨主張する。
しかし,特許請求の範囲の記載は,この記載に基づいて特許発明の技術的範囲が定められ,新規性・進歩性の特許要件等の判断がなされるという点において重要な意義を有するものであり,一の請求項から発明が明確に把握されることが必要であることはいうまでもないが,原告が主張するように,「意図的に」が「わざと」と同じ意味であることは分かるとしても,「意図的に」あるいは「わざと」の表現を用いることで実現(具現)する構成が不明確であり,技術的範囲も不明確である。
イ原告は,請求項1等に記載した「機能拡張装置」等における「機能拡張」の技術的範囲が不明であるとの指摘は当たらない旨主張する。
しかし,「機能拡張装置」という以上,基となる装置に対して機能を追加するものを意図していると理解するのが合理であるところ,単に「機能拡張装置」のみでは,既存WWWサーバに対して追加する装置の構成が既存のサーバの機能に対してどのような機能の拡張を特定するものであるのか不明であるから,請求項1等で使っている「機能拡張」の技術的範囲が不明である。
ウ原告は,請求項3中の「固定的部位を何ら変更することなく備える」が明確でないとの指摘は当たらない旨主張する。
しかし,本件明細書(甲10)の段落【0038】の記載を参酌すると,「固定的部位」とは変更がなされない部位をいうと解される。そのような「固定的部位」を「何ら変更することなく」とあえて修飾することは「固定的部位」が変更できることを想定していると解されることになり,明細書の記載と矛盾する。そうすると,そのような変更が可能な「固定的部位」とは何を意図しているのか不明であるので,「・・・備える」とする構成が不明確である。
エ原告は,「以外」の語の利用のみをもって明確でないとするのは当たらない旨主張する。
しかし,請求項4,5中の「以外」を解釈する上において,原告が例示する奇数と偶数のような二者択一の関係に帰着できるものではなく,また,「どのような形式をもっても伝達されない箇所」の記載表現がどこを指すのかも不明であるから,結局,請求項4,5中の「以外」なる記載はどの範囲を指すのか不明である。
オ原告は,請求項6中の「用いる用途では含まない」が明確でないとの指摘は当たらない旨主張する。
しかし,請求項6に記載された「CGIプログラム等へのパラメータ伝達を指示するものであるとRFCにより定義された文字列をその定義の通りに用いる用途では含まない」における「CGIプログラム等へのパラメータ伝達を指示するものであるとRFCにより定義された」は「文字列を」にかかる。そして,「含まない」の目的語は「文字列を」であるから,「文字列を」「含まない」と解釈できる。そうすると「含まない」の直前部分は,通常は,何を含まないのかあるいはどこに含まないのかを意味することになるが,直前部分には「その定義の通りに用いる用途では」と記載されているから,どこに「含まない」のか不明である。
カ原告は,請求項9中の「随時定義」は「予め定義されるのではない文字列(静的ではないもの)」の言い換えであり,表現は明確である旨主張する。
しかし,拒絶理由通知書(甲11)における「具体的にどのような手段によりどのように定義するのか明確でない」とは,装置内でどのように随時に定義を設定しているのか不明であると指摘しているのであって,随時定義の意味を不明確と指摘している訳ではない。
キ原告は,請求項9中の「同等に処理」の前後も含めた記載「予め定義された・・・文字列を・・・特別の意味が設定されている文字列と同等に処理する普通文字列特別解釈手段」の表現は明確であり,より具体的な説明も記載済み(本願明細書段落【0089】)であるから,「同等」が明確でないとの指摘は当たらない旨主張する。
しかし,「同等」とは程度が同じという意味であり,同程度の処理の意味とは何か(どのような内容の処理であるのか)が不明確である。
ク原告は,請求項10中の「エラー誘発手段処理ステップ」なる記載が明確でないとの指摘は当たらない旨主張する(請求項12,13中の「エラー誘発設定ステップ」についても同様)。
しかし,請求項10では,「エラー誘発手段処理ステップ」では手段とステップが混在しており,両者の関係が不明であり,また,請求項12,13の「エラー誘発設定ステップ」は「エラー誘発手段」との関係が不明である。
ケ原告は,請求項1,2,7,9,12,13,15中の「データ」なる記載は,各請求項の記載及び対応する本願明細書の記載から明確であるから,明確でないとの指摘は当たらない旨主張する。
しかし,請求項1に記載された「WWWサーバが記憶手段に保持するデータのうち少なくともURLパス部を利用して処理を行う文字列処理手段」において,WWWサーバには多くの種類のデータが記憶されているところ,ここの「データ」がどのようなデータを意味するのか不明確であるといわざるを得ない。また,請求項2,12,13,15も請求項1と同じ理由により不明確であるといわざるを得ない。請求項7には「コンピュータ言語の命令やデータ」と記載されているところ,「コンピュータ言語の」「データ」が演算の対象となるデータであるとすると,そのようなデータにはあらゆる種類のデータが含まれるので,文字列処理を要しない普通のURLも含まれることになるから,発明が不明確であるといわざるを得ない。請求項9の「データ」についても,請求項9が引用する請求項4または5がさらに引用する請求項1または2に記載された「データ」が不明確であり,かつ,請求項1または2に記載された「データ」と請求項9に記載された「データ」との関係が不明であるから,不明確である。
コ原告は,「エラー」なる記載が明確でないとの指摘は当たらず,無用の限定をする必要はない旨主張する。
しかし,拒絶理由通知書(甲11)は,請求項1～3,10～15に対して特許法36条6項2号による記載不備を指摘した。この条文の趣旨は,特許請求の範囲の記載は,特許権の権利範囲がこれによって確定されるという点において重要な意義を有するものであるから,その記載は明確でなければならないことにある。請求項1～3,10～15に記載の「エラー」は一般的な用語にすぎないからから,特許法36条6項2号違反に当たると指摘したものである。
また,請求項14,15に対しては,特許法36条6項1号による記載不備も併せて指摘した。この条文の趣旨は,特許請求の範囲の記載には,発明の詳細な説明に記載の範囲を超えて記載してはならない旨を規定したものである。請求項14,15には単に「エラーが発生した時に」との記載があるが,「エラー」という語は一般的な用語であるから,請求項14,15の記載では本願の明細書中に記載された意味での「エラー」の範囲を超えるものを当該請求項に記載しているとして,特許法36条6項1号違反に当たると指摘した。
サ原告は,請求項2,11中の「エラーの程度またはタイミング等を変更するための条件変更手段」なる記載を非難するが,その指摘は当たらない旨主張する。
しかし,請求項2,11に記載された「エラーの程度またはタイミング等を変更するための条件変更手段」に対して,発明の詳細な説明には「【0035】請求項2の機能拡張装置は,どのようなURLパス部の到来に対してエラーを誘発するのか(あるいは逆に誘発しないのか)やどのような時間帯にエラーを誘発するのか等の,エラーを誘発するための条件を変更する条件変更手段を備えている。」と記載されているように,請求項2,11に記載された「条件変更手段」と詳細な説明に記載された「条件変更手段」とは対応していない。
シ原告は,請求項4,5中の「由来し」なる記載が明確でないとの指摘は当たらず,「この<○○側に由来し>なる表現はWWW中継処理装置(206)の存在を念頭に置いたものであり,記載済みである(本願明細書段落【0041】～【0043】および図2参照)。」と主張する。
しかし,原告が指摘する段落【0041】～【0043】にも発明の詳細な説明の他の箇所にも「由来し」という記載はなく,「由来し」がどのようなことを意味するのか不明である。
ス原告は,請求項4,5中の「形式」なる記載が明確でないとの指摘は当たらず,本願明細書段落【0044】～【0046】に記載がある旨主張する。
確かに,段落【0044】には,「・・・たとえネットワーク(208)中においてどのような表記形式で伝送されようとも文字列1と見た目上(つまり印刷した際に)同一の文字列をWWWサーバにて獲得する獲得手段を備えるとしている。」と記載されており,請求項4,5の「形式」は一応「表記形式」のことと把握されるところ,請求項4には,「・・・文字列処理手段はWWWサーバに対してどのような形式をもっても伝達されない箇所以外は」とあり,常識的に考えて「表記形式」がどのような形式であっても伝達されない箇所があるような「表記形式」とは何かが不明であるから,結局,請求項4の「形式」が「表記形式」に対応するのかは不明である。
セ原告は,請求項5における「以外の方法」の前方の記載を含めるとその表現は明確であって,記載が明確でないとの指摘は当たらない旨主張する。
しかし,「WWWクライアントのURL入力表示欄で入力する方法」は明確といえるが,それ「以外の方法」とは「URL入力表示欄で入力する」以外のあらゆる方法と解されるから,技術的範囲が不明確である。そして,特許法36条6項1号の趣旨は先のとおりであるところ,本願発明の詳細な説明には,「WWWクライアントのURL入力表示欄で入力する以外の方法」として「telnet」と「プログラム」による例が挙がっているだけであり,発明の詳細な説明に開示された内容を超えるような「以外の方法」というあらゆることを含む技術的範囲までとすることは,特許法36条6項1号の趣旨に反することは明らかである。
ソ原告は,請求項9中の「少なくとも一方を備える」なる記載に関連して「両方を備える場合」が明確でないとの指摘は当たらず,機能の異なる文字列処理手段を複数多種準備してこれらを活用する点については,本願明細書段落【0036】,【0037】,【0096】に記載がある旨主張する。
しかし,原告が指摘した箇所以外の発明の詳細な説明を参照しても,「特別文字列普通解釈手段」と「普通文字列特別解釈手段」を備える場合については記載されていない。
タ原告は,請求項2中の「(発生するエラーの程度または)タイミング等(を変更するための条件変更手段)」について明確でないとの指摘は当たらない旨主張する。
そこで,請求項2に記載された「タイミング等」について検討する。発明の詳細な説明には「タイミング」という用語は記載されていない。類似と思われる記載として発明の詳細な説明の段落【0035】に「時間帯にエラーを誘発する」との記載はあるが,「タイミング」を時間帯の意味で用いられることは一般的ではないから,請求項2の「タイミング等」が何を意味するのか不明確である。
次に「(CGI)プログラム等」を検討する。「(CGI)プログラム等」について,発明の詳細な説明中にはそれに類する記載も示唆もないから,「(CGI)プログラム等」に類するものが何であるのか不明である。
同様に「学術分野等」に関しても,「学術分野」に類する範囲として何が含まれるのか不明である。この点につき,原告は,請求項7中の「(特定の)学術分野等(で用いられる記号類)」について,本願明細書中の用語「FｘURL」で表現可能な「記号類」と記載,指定されている旨主張するが,発明の詳細な説明を参酌しても「FｘURL」で表現可能な「記号類」の種類が何であるのか不明である。
第4当裁判所の判断1請求原因(1)(特許庁における手続の経緯),(2)(発明の内容),(3)(審決の内容)の各事実は,いずれも当事者間に争いがない。
ところで,原告のなした本件特許出願(本願)の特許請求の範囲は,前記のとおり請求項1～15から成り,審決の内容・原告主張の取消事由・被告の反論のいずれも,上記各請求項全般に亘ってなされているが,特許法36条によれば,複数の請求項に亘るものであっても特許出願としては一個不可分のものであるから,出願に係る請求項1～15のうち一つでも特許法の定める要件を満たさないものがあるときは,その余の請求項について判断するまでもなく,当該特許出願全体が拒絶されるべきことになる。
そこで,被告が重点的に主張している本願請求項14(本願発明14)について,まず検討する。
2本願発明14の進歩性(特許法29条2項)の有無について(1)本願発明14の意義ア本願明細書(甲10)には,以下の記載がある。
・【請求項1】～【請求項15】前記第3,1(2)記載のとおり。
・【発明の属する技術分野】「この発明は,既存の情報処理手段の機能を拡張する装置,方法ならびにこの方法を備えたプログラムに関し,特にWWWサーバにおけるURLの解釈を柔軟に行うことによりURLの表現力や利用価値を高めることに関する。」(段落【0001】)・【発明が解決しようとする課題】「しかしながら,HTTPやURLの規約に準拠したこれまでのURL(このようなURLを以降,『TrURL』(Traditional URL)と言う。)ではURLパス部に漢字等の全角文字を含むことができなかった。そのため,本当は○×商会が図9のURL入力表示欄(901)に示す表現方法に代えて図10のURL入力表示欄(1001),(1007),(1009)に示すような漢字,ひらがら,カタカナを含むURL(このようなURLを以降,『KURL』(Kanji URL)と言う。)を用いたくてもできなかった(またはできないと考えられていた)。(段落【0015】)・「少なくとも資料1(出典は後述)の雑誌の記事は,『ブラウザに表示させるURLに日本語を使うことはできません。』としている。当該雑誌の次号以降で訂正等がなされていないことを考え併せれば,これがインターネット関連業界の標準的認識と考えてほぼ良いであろう。すべてのブラウザがHTTPの規約どおり実装されていればこの記述は妥当である。
ところが実際の状況はやや異なる。」(段落【0016】)・「発明者が実験した範囲では,HTTPには反するかもしれないものの,開発者またはバージョンが異なる2以上のブラウザにおいて,URL入力表示欄(502)に漢字等を入力することは可能である。ただし,それ(漢字等を含んだKURL)をWWWサーバに伝達する際の処理方法は異なっている。」(段落【0017】)・「このため,通信するWWWクライアント(202)とWWWサーバ(210)の双方が同一の漢字コード体系を用いているケースや下記のような対処を行ったケースでは,KURLがあたかも正常に使えているように処理することが可能である。」(段落【0018】)・「すなわち,(他の方法もあるかもしれないがここで説明するのは,)利用されうる漢字コード体系の別をP,HTTPに基づくエンコード処理の有無やエンコード処理後の文字列の相違の別をQとする時,P×Q=R通りの表記によるファイルをディレクトリ領域(図8A参照)に設定する;という対処方法である。仮にP=3,Q=2とした場合,1のURLに対して6のファイルを用意することになる。」(段落【0019】)・「ただし前記の方法には欠点がある。WWWサーバが動作しているコンピュータにおけるOS(オペレーティングシステム)の種類によっては,特定の漢字コード体系における特定の文字を含む場合は,対応するファイルを設定できない可能性がある。それは──漢字等の全角文字は多くの場合2バイト(16ビット)が1文字に対応する。前記の方法では,外見上は漢字等を用いたファイル名が設定できているように見えながら,実は,2の1バイト文字(ここで『1バイト文字』は7ビットまたは8ビットの空間を持つ文字コード集合。例えばASCIIコード。)をただ連ねただけで(それ以外の配慮をせずに)1の全角文字を疑似的に実現している場合がある。このような漢字処理方法においては,当該OSがファイル名には用いないとしている1バイト文字(例えばあるOSにおいては「/」(スラッシュ))を含むような全角文字は正しく取り扱うことができないおそれがある。」(段落【0020】)・「仮に上記のような現象が発生する可能性が低いとしてこれを許容するとしても,1のURLに対して6のファイルを用意するのにはファイルの設置や管理に手間が掛かる。それに,もしもKURLの処理方式の異なるブラウザの数が増えてQ=5となった場合には,P=3のままとして,1のKURLに対して15ものファイルを用意しなければならない。PやQは将来の増加の可能性があるので,このような場当たり的な対処方法は運用面で大変手間の掛かる方法であると言える。しかも,上述したような不完全性を備えている。」(段落【0021】)・「TrURLには漢字等の全角文字以外にも表記上の制限がある。まず,TrURLで使用可能な文字コード集合は最大でも7ビットの文字コード集合であるASCIIコードだけである。上述した全角文字を含め,2バイト以上の領域を用いる日本語,韓国語,中国語等用の多バイトのコード体系は使えない。ヨーロッパを中心に用いられている『ISO 8859-1』なるコード体系をはじめとする8ビット(1バイト)の文字コード集合も使えない。」(段落【0022】)・「TrURLには更に制限がある。ASCII文字コード集合のうち利用者側の意志で自由に使えない文字(コード)が複数存在する。具体的には,(1)『非図形文字』である文字群(1102),(2)『Unsafe』である文字群(1104)(3)『Reserved』である文字群(1106)がある。正確な意味はURLに関するRFCを参照されたい。以下では例を用いて説明する。(段落【0023】)・「そこでこの発明は,WWWクライアントからWWWサーバに伝達されたURLの中のURLパス部を柔軟に解釈して多様な文字列処理をすることを可能にすべく,既存のWWWサーバに取り付け可能な機能拡張装置および機能拡張方法ならびに前記機能を備えた機能拡張プログラムを記録した記録媒体を提供することを目的とする。」(段落【0031】)・【課題を解決するための手段】「請求項1の機能拡張装置は,意図的にエラーの発生を誘うエラー誘発手段を用いてURLに関する処理を既存のWWWサーバから既存のWWWサーバ以外の処理手段である文字列処理手段(この文字列処理手段はこの発明により新規に用意する手段である。)へと移している。その際,既存のWWWサーバが情報処理した結果として記憶された記憶手段の情報を利用している。」(段落【0032】)・「これにより,既存のWWWサーバでは実現が困難であったURLパス部の柔軟な解釈が可能となる。この発明の一実施形態による機能拡張手段等を備えたWWWサーバの処理の流れを図1に示す。」(段落【0033】)・「この発明による機能拡張装置を利用するためには,対象となる装置が(1)例外事象発生時の処理手段を呼び出す仕組みと(2)その処理手段として所望のものを設定可能という2の条件を満たしていれば良い。たとえば『CPU』は『WWWサーバ』ではないが,CPUはこれらの条件を満たしているものが多い。」(段落【0097】)・「このことを熟考すれば,請求項1が機能拡張の対象としている装置をWWWサーバにのみ限定していることについて疑問が生じて来る。『この限定を取り払うとどういうことになるのか?』発明者は自問自答した。」(段落【0098】)・「コンピュータのファイル等のデータを『資源』と捉えるならば,URLはインターネットにおける資源の同定用文字列と言える。実際,『URL』の正式名称である『Uniform Resource Locators』がそれを示している。そして,資源の所在を指し示す文字列を『アドレッシング用文字列』と呼び直してみると,(1)URLと並んでインターネットにおいて頻繁に利用されている文字列である『電子メールアドレス』や(2)URLと電子メールアドレスに共通の要素である『ドメイン名』等も『アドレッシング用文字列』と言って良いだろう。」(段落【0099】)・「ここまで考えを進めるとこの発明は,アドレッシング用文字列を処理するサーバ全般に適用できそうだとの推測が付く。具体的には,(1)電子メールの配送等を行うための手段である電子メールサーバや,(2)ドメイン名からIPアドレスを得るための(またはその逆の用途のための)手段であるDNS (Domain name system)サーバにも適用できそうなことが推測できる。FTP (file transfer protocol)サーバにも適用できるであろう。すなわち,電子メールサーバ(『sendmail』という名称のプログラムが有名である。)を例に採れば,次のような請求項を設けることが可能である。」(段落【0100】)・「既存電子メールサーバが電子メールのアドレスを処理するに際して意図的にエラーを誘発するエラー誘発手段と,前記既存電子メールサーバが記憶手段に記憶させたデータのうち少なくとも電子メールアドレスのユーザID部を利用して処理を行う文字列処理手段と,前記エラー誘発によりエラーが発生した時に前記既存電子メールサーバから前記文字列処理手段へと処理を分岐させる分岐手段とから成る機能拡張装置。」(段落【0101】)・「更に考えを推し進めれば,この発明は,インターネット以外の領域にも適用できそうなことが推測できる。例えば,電話通信網における電話番号に基づく回線交換システムにも適用可能であろう。」(段落【0102】)・「このように考えるうちに,これらの適用可能な用途をすべて個別に列記して請求項として記述する方法では限界があると発明者は考えた。そこでこの発明の本質を抽出し,新たな請求項とした。それが請求項10と請求項11である。」(段落【0103】)・「発明者が更に考えを推し進めたところ,エラー誘発手段は必ずしも機能拡張装置の構成要素として含まれる必要はないであろうとの知見を得たため,請求項14としてこの発明を記述した。また,請求項14における『既存情報処理手段』をWWWサーバに限定した場合の発明を請求項15として記述した。」(段落【0108】)・「図7に示した各部を備えた処理手段をCPU(1706)を用いた装置のハードウェア構成の一例を図17に示す。なお,図7に示した各部分の全部または一部はCPUを用いずにハードウェアロジックにより構成してもよい。」(段落【0179】)・「図17において,CPU(1706)には,ネットワークインターフェース(1702),メモリ(1708),ディスプレイ(1710),キーボード(1712),CD-ROMドライブ(1716),ハードディスク(1718)が接続されている。」(段落【0180】)・「ハードディスク(1718)には,OS(1720),WWWサーバ装置に必須のプログラムであるhttpdプログラム(1722),httpdプログラムが動作中に各種設定情報や変数等が格納されるhttpdプログラム用ワークエリア(1724),httpdプログラムがWWWクライアントからのHTTPリクエストに応じて随時提供する情報等を格納した公開用ファイル(1726)が記憶されている。これらがWWWサーバの基本的要素である。」(段落【0181】)・「ハードディスク(1718)にはまた,この発明を用いたWWWサーバにだけ存在する機能拡張プログラム(1728)と機能拡張プログラム用ワークエリア(1730)も記憶されている。これがWWWサーバの拡張的要素である。」(段落【0182】)・「加えてこの発明を実施するWWWサーバのうち請求項2を満たすものは,分岐先情報保持部(704)の内容を変更するための手段として条件変更部(708)を備える。条件変更部(708)は前記アクセスコントロールファイルまたは同等機能を提供するファイル等における分岐先情報保持部(704)またはこれに相当する箇所を修正するためのものである。」(【0199】)・【発明の効果】「これまでに説明から明らかなように,WWWサーバにおけるURLの解釈を柔軟に行うことによりURLの表現力や利用価値を大幅に高めることができる。同時に,インターネットのサービスを利用する際の障壁を下げる効果もある。これらの相乗効果により現在のインターネット利用者にも将来のインターネット利用者にもメリットをもたらすサービスが提供可能である。また,WWWサーバ以外にも応用可能であるため多分野に渡り効果を得ることができる。」(段落【0201】)・【図1】(この発明の一実施形態による機能拡張手段等を備えたWWWサーバの処理の流れを示す図)・【図7】(この発明の一実施形態による機能拡張手段等を備えたWWWサーバの構成要素を示すブロック図)・【図17】(この発明の一実施形態による機能拡張手段等を備えたWWWサーバ処理装置の構成要素を示す図)イ上記記載によれば,本願発明1～9,12,13,15はインターネットにおけるウェブサイトの閲覧におけるURLの処理に関するものであり,半角英数字のみならず,漢字,ひらがな等の全角文字を含ませることにより,URLの表現力や利用価値を高めるとともにインターネットサービスを利用する際の障壁を下げることを目的とし,その解決手段として,従来のWWWサーバに文字列処理手段等を備えた機能拡張装置を備えるものであり,本願発明10,11,14はこれをインターネット以外の領域にまで広げた上,本願発明14は意図的なエラー誘発手段を構成要素としない発明であることが認められる。
(2)引用発明1の意義ア引用文献1(甲1)には,以下の記載がある。
(ｱ)「インターネットやイントラネットでWWWサーバを立ち上げるには,HTTPサーバであるhttpdを利用します.今回はhttpd(Apache)のインストールと活用について解説します.httpd(Hyper Text Tranfer Protocol Deamon)はハイパーテキストの転送を行うデーモン(すなわちサーバ)です.通常,Netscape NavigatorやInternet Exprolerなどのブラウザからの要求を受けて,ホームページのHTMLファイルなどを転送したりCGIスクリプトを実行させたりします.」(134頁左欄1行～10行)(ｲ)「現在主に使われているhttpdの1つにApacheがあります.これは,注1NCSA版httpdの改良から始まったhttpdで,NCSA httpd verl.3 (およびverl.4)と完全互換であり,さらにさまざまな機能拡張などを施したものです.また,NCSA httpdより高速なhttpdでもあります.Apacheの特徴の1つにモジュールによる機能拡張があります.サーバの機能をモジュールという形で与えることで,機能の追加/削除が簡単に行えます.モジュール集はhttp://www.zyzzyva.com/server/module_registry/などから手に入ります.今回は,このApacheをmake,インストールしてみることにしました.」(134頁右欄3行～16行)(ｳ)「apache_1.1.3.tar.gzをmake,インストールします.これはApach注2eのサポートサイト(http://www.apache.org/)から入手できます.また,日本語サイトhttp://apache.maizuru-ct.ac.jp/からミラーサイトが辿れます.まず,アーカイブを解くとapache_1.1.3/というディレクトリができます.ここに必要なファイルがすべて入っています.適当なディレクトリへ展開してください.筆者は/srcに展開しました.各ディレクトリ構成は表1のようになっています.」(134頁右欄18行～135頁左欄12行)(ｴ)「●表1ディレクトリ構成(apache_1.1.3/以下)cgi-bin/CGIプログラムconf/設定ファイル,最初はサンプルが入っているhtdocs/HTMLのサンプルが入っているicons/Fancylconで使うアイコンが入っているlogs/ログsrc/httpdのソースが入っているsupport/サポートプログラム,最初はサポートプログラムのソースが入っている」(135頁左欄1行～9行)(ｵ) 「apache_1.1.3/conf/以下のファイルを編集します.デフォルトでは,サーバルートが/usr/1oca1/etc/httpd/以下になっているので,これらのファイルをディレクトリごとコピーします.# cp -r /src/apache_1.1.3/??* /usr/local/etc/httpd/設定ファイルを自分の環境にふさわしいように書き換えます.httpd.confとsrm.conf,そしてaccess.confの3つを設定すれば,WWWサーバとして動作するようになります(それぞれ,表3のような役割をもちます).」(135頁右欄17行～26行)(ｶ)「●表3Apacheの設定ファイルファイル名役割見本ファイルaccess.confアクセス制限についての設定access.conf-disthttpd.confサーバの動作についての設定httpd.conf-distsrm.conf各ディレクトリやファイル名についての設定srm.conf-dist」(136頁1行目～5行)(ｷ)138頁右欄からsrm.confの設定についての記載があり,140頁左欄に「ScriptAlias」のタイトルで以下の記載がある。
「●ScriptAliasCGIを置くディレクトリの別名を指定します。
ScriptAlias /cgi-bin/ /usr/Local/etc/httpd/cgi-bin/また,140頁左欄から右欄に「ErrorDocument」のタイトルで以下の記載がある。
「●ErrorDocumentエラードキュメントをカスタマイズできます.エラードキユメントとは,誤ったURLを指定した場合などにクライアント上に表示されるドキュメントのことです.ここでカスタマイズすると,他のサーバ上にあるエラードキュメン卜を表示したり,CGIを使ったものを表示させたりすることができるようになります.エラードキュメントをプレーンテキストで表示するときには「”」の後に続けて,表示したいテキストを記述します.ローカルのファイルを表示させる場合には,そのファイルが存在するパスを絶対パスで記述します.ローカルのCGIの場合も同様に指定します.リモートにあるファイルを表示させるには,そのファイルの存在するURLを記述します.ErrorDocument 500 "The server made a boo boo.ErrorDocument 404 /missing.htmlErrorDocument 404 /cgi-bin/missing_handler.plErrorDocument 402 http://other.server.com/subscription_info.html｣イ?上記(ｱ),(ｲ)の記載から,「HTTPサーバであるAｐache」は通常「ブラウザからの要求を受けて,ホームページのHTMLファイルなどを転送する」こと,?上記(ｳ)～(ｷ)の記載から,cgi-binディレクトリ等にCGIプログラムを格納すること,?上記(ｳ)～(ｷ)の記載から,「誤ったURLを指定した場合」にクライアント上に表示されるエラードキュメントをカスタマイズできること,具体的には「CGIを使った」ものを表示させられること,?上記(ｱ)の記載から,HTTPサーバ(Aｐache)を利用する「WWWサーバ」が記載されていることを認めることができる。
そうすると,引用文献1には,以下の発明(引用発明1)が記載されていると認めることができる。
「HTTPサーバであるAｐacheが,通常,ブラウザからの要求を受けて,ホームページのHTMLファイルなどを転送し,cgi-binディレクトリにはCGIプログラムを格納し,設定ファイルには,誤ったURLを指定した場合に,クライアント上に表示されるエラードキュメントをカスタマイズして設定でき,上記設定は,EｒｒｏｒDｏcｕmenｔに指定することで,CGIを使ったものを表示させることができるようにした,WWWサーバ。」(3)対比・判断ア「HTTPサーバであるAｐache」が,通常,ブラウザからの要求を受けてホームページのHTMLファイルなどを転送することは,「既存情報処理手段」が「情報処理」することに相当する。
引用発明1の「誤ったURLを指定した場合」は,「エラーが発生した時」に相当する。
引用発明1で「誤ったURLを指定した場合」,CGIを使ったものを表示させるためには,当然にErrorDocumentで指定されたCGIプログラムを実行しているものであって,このCGIプログラムの実行はHTTPサーバであるAｐache(そのhttpdプログラム)とは別の情報処理手段に処理を分岐させることに相当する。
また,CGIプログラムを実行させるのは,HTTPサーバであるAｐacheが誤ったURLの指定を検出した場合と解されるから,引用発明1も既存情報処理手段における情報処理結果の一部または全部を利用しているといえる。
以上から,両者の一致点,相違点は次のとおりである。
<一致点>「既存情報処理手段が情報処理するに際して前記既存情報処理手段における情報処理結果の一部または全部を利用して処理を行う別の情報処理手段と,エラーが発生した時に前記既存情報処理手段から別の情報処理手段へと処理を分岐させる分岐手段とを備える装置」<相違点1>本願発明14においては,既存情報処理手段に対して,その外に外部情報処理手段があるのに対して,引用発明1では,既存情報処理手段に相当するWWWサーバが,別の情報処理手段に相当するCGIプログラムを備えている点。
<相違点2>本願発明14は「機能拡張装置」の発明であるのに対して,引用発明1はWWWサーバである点。
イ<相違点1>についての判断誤ったURLを指定した場合に実行されるCGIプログラムは,既存情報処理手段であるHTTPサーバであるAｐache(そのhttpdプログラム)によりその実行を制御される別のプログラムであって,エラードキュメントの表示に関して付加的な情報処理手段を構成しているから,既存情報処理手段に対して外部情報処理手段といえるものである。
また,情報処理分野において,付加的な情報処理手段を既存の情報処理手段に対して外部の情報処理手段として構成することは,何ら格別なことではなく適宜の設計事項である。
よって,引用発明1のCGIプログラムを既存情報処理手段に相当するWWWサーバに対して外部情報処理手段として構成することは,当業者(その発明の属する技術の分野における通常の知識を有する者)が容易に想到し得ることである。
ウ<相違点2>についての判断前記のとおり,引用発明1のCGIプログラムは,HTTPサーバであるAｐache(そのhttpdプログラム)に対して付加的な情報処理手段を構成し,CGIプログラムに記述された処理を行い,所定の表示をする機能を付加するものであるから,HTTPサーバであるAｐache(そのhttpdプログラム)に対して機能を拡張しているといえる。よって,引用発明1においてCGIプログラムによる処理を行う構成は,本願発明14の機能拡張装置に相当するといえるものである。
エ以上によれば,本願発明14は引用発明1から当業者が容易に想到することができたものであると認めるのが相当である。したがって,本願発明14は引用発明1に基づいて当業者が容易に発明することができるとした審決の判断に誤りはない。
(4)原告の主張に対する補足的判断ア原告は,一般のサーバ運用者にとって,サーバのエラーを発生させるような状態に設定することへの動機はない旨主張するが(取消事由1),かかる主張は「エラー誘発手段」の存在を前提とする主張であるところ,本願発明14には「エラー誘発手段」は存在しない。したがって,引用発明1にエラーを発生させるような状態に設定することへの動機がないとしても,引用発明1から本願発明14を容易に想到できるか否かの判断に影響を与えるものではないと解されるから,原告の上記主張は採用することができない。
なお,本願発明1～13との関係について付言すると,たしかに通常のサーバの利用に対しては利用者に不便を与えないため,エラーは避けるのが技術常識であると考えられる。
しかし,特開平10-63597号公報(発明の名称「クライアント側,サーバ側および協調部で実行するURLのスペルチェック」,出願人サンマイクロシステムズインコーポレイテッド,公開日平成10年3月6日。甲6)の段落【0018】,【0052】及び図11には,「隠しファイル」のURLと類似のURLが入力され,この類似のURLのスペルミスを自動修正した結果「隠しファイル」のURLと一致してしまう場合には,最初から正しい隠しファイルのURLを入力できた利用者だけに,隠しファイルを表示させるためURLの自動修正機能をキャンセルし,その結果,スペル修正の候補がなくなれば「文書が見つかりません」のエラーメッセージを表示すること(ステップ1115)が記載されており,本願の出願当時(平成10年6月26日),セキュリティ上,意図的にエラーを発生させる場合があることが認められる。
また,引用文献7(乙1)の1欄50～57行(訳文2頁16～21行),17欄24～27行(訳文23頁14～16行),18欄26行～30行(訳文24頁23行～26行)の記載によれば,キオスク端末からのネット接続に関して,ユーザの独り占めを防ぐため,閲覧するコンテンツの制限に加え閲覧時間も制限すること,ある時間が超過したらユーザが希望した情報を表示することに代えて,所定の警告メッセージを表示し,HTML文書を書き直してリンクを不能にすることが記載されているところ,このような利用時間を超過した場合の警告表示等は,意図的なエラー発生と同視できる。
そうすると,本願出願当時(平成10年6月26日),不適切なサーバの利用に対しては,サーバやサーバ上のデータを保護する観点からエラーを意図的に発生させるべき場合があることが認識されていたことが認められ,引用発明1にエラーを発生させる動機付けがないとはいえない。
したがって,サーバの設定がエラーを発生させるような状態に設定されていれば,エラーを誘発させ,サーバでの処理を分岐させ,文字列処理を行わせることに格別の困難性は認められないとした審決の判断に誤りがあるということはできない。
イ次に原告は,取消事由2として,WWWサーバとWWWクライアントとの間の通信規約に定められたルールの一部を引用して,ブラウザに表示させるURLに日本語を使うことはできない旨主張する。
しかし,原告の上記主張は請求項6～9に関するものであるところ,上記のとおり,請求項1に進歩性が認められない以上,取消事由2を検討するまでもなく,これに従属する請求項6～9にも進歩性は認められない。
3本願発明14の先願発明との実質的同一性(特許法29条の2)の有無について審理の経緯に鑑み,本願発明14の先願発明との実質的同一性(特許法29条の2)の有無について(取消事由3)も検討する。
(1)先願発明9の意義ア引用文献9(甲9)には,以下の記載がある。
・【請求項1】「インターネット上に置かれている情報提供サーバに蓄積された情報資源をアクセスするためのURLを用いたインターネットへのアクセス方法であって,予めURLに対応する任意の文字列を割り当て,この割り当てられた文字列をクライアント側のインターネットへのアクセス機器から入力し,この入力された文字列をクライアント側またはサーバ側の文字列変換プログラムによって,割り当てられた文字列とURLとの対応関係を示す記憶テーブルを用いてURLに変換し,この変換されたURLでインターネット上の探査を行い,該当するデータをクライアント側の画面上に表示または記憶装置に取得することを特徴とするインターネットへのアクセス方法。」・【発明の詳細な説明】「ところが,このURLの入力はユーザにとっては思わぬ障害となっている。その理由はURLを構成する文字列が長く,しかも複雑な仕組みを持つことである。たとえばA株式会社のURLはそのホームページがどの管理下にあるかでhttp://www.a.co.jp/,http://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/のように変わり,その組み合わせは無限といえるほどである。このような複雑な仕組みを持つURLは入力を1字間違えただけでアクセスできず,しかも間違いの原因や箇所などを指摘する手段もないため,コンピュータやインターネットに精通したユーザ以外の利用は困難を極めている。」(段落【0004】)・「さらに,URLを構成する文字列は半角の英数字であるため,日本語をローマ字や英語で表さなければならないが,その際にもユーザにとって次のような障害がある。たとえば日本の通商産業省のホームページはMinistry of International Trade and Industryの略であるMITIを用いてhttp://www.miti.go.jp/となっているが,果たして通商産業省からmitiを想像することのできるユーザがどれほどいるであろうか。また,首相官邸のホームページはhttp://www.kantei.go.jp/と,今度は「官邸」をローマ字で表したURLが用いられている。このように,会社名,団体名,組織名,法人名,個人名,商品名,サービス名称,地名といったユーザになじみのある名称を元にURLが決められているのではないため,目的の情報資源へたどりつくためには「ｙahｏｏ」や「gｏｏ」といった検索エンジンに頼らざるを得ない状況となっている。」(段落【0005】)・「そこで,本発明の目的は,1回の入力に対して必ず唯一の結果を検索可能とし,かつキーボードに不慣れなユーザに長く複雑な文字列のURLを意識させることなく,このURLに対応する会社名,団体名,組合名,個人名,商品名,サービス名称,地名,電話番号あるいは任意の文字列を入力するだけでインターネットにアクセスすることができるインターネットへのアクセス技術を提供することにある。」(段落【0009】)・「まず,図1の説明図によりクライアント側のWWWブラウザから文字列変換プログラムを介してインターネットへアクセスする方法を説明する。クライアント側のWWWブラウザ11のアドレス欄に入力された文字列は,文字列変換プログラム12によってURL変換データベース13の中に入力された文字列と同一の文字列があるかが検査され,同一の文字列に対応するURLを取得し,取得されたURLをもってインターネット14へアクセスする。」(段落【0019】)・「前記文字列の入力には一般的なキーボードを用いる他に,マウスやペン,タッチパネルといったポインティングデバイスや,スキャナ,デジタルカメラ,OCRなどの光学的読みとり装置や,テレビなどの操作に用いるリモコン類や,音声で入力する音声認識インターフェースなどを用いることができる。」(段落【0020】)・「前記文字列変換プログラムはクライアント側にインストールする他に,LAN環境などではサーバ側に置くことも可能で,プロバイダ業者がユーザへのサービスとして本発明を利用するような環境では,プロバイダ業者の管理するサーバ側に置くことも可能である。」(段落【0021】)・「前記URL変換データベースは前記文字列変換プログラムと同一の場所に置くことも可能な他,たとえば前記文字列変換プログラムをクライアント側に置き,前記URL変換データベースをサーバ側に置くことも可能である。」(段落【0022】)・「次に,図2と図3,図4の説明図によりクライアント側のWWWブラウザへの文字列入力からインターネットへのアクセスに至るまでの処理手順を説明する。」(段落【0023】)・「ユーザが前記入力手段で入力した文字列を,全角文字や半角カタカナを含むか,あるいは図3のURLの構成に沿ったものであるかを調査し,全角文字や半角カタカナを含まず,かつ図3のURLの構成に沿ったものであれば入力された文字列をURLと見なして変換せずにインターネットへの探査を行う。前記文字列はプロトコル31,DNS32,ディレクトリ33,ファイル名34のいずれにあっても抽出が可能で,または入力が前記文字列だけであっても抽出が可能である。入力された文字列が図3のURLの構成に沿ったものでないか,全角文字や半角カタカナを含む場合は,入力された文字列で図4のURLデータベースを検索し,一致するURLを取得してインターネットへの探査を行う。図4のURL変換データベースに一致する文字列が見つからなければその旨のエラーメッセージを画面上に表示する。」(段落【0024】)・「ユーザがクライアント側のインターネットへのアクセス機器から入力した文字列を,任意の長さの漢字41,任意の長さのかな42,任意の長さの英字43の順に検索し,一致する場合は任意の長さのURL44を得てインターネットの探査を行う。このデータベース構成を格納する媒体は,クライアント側のハードディスクの他に,高速な検索を可能にするためのキャッシュとしてクライアント側のメモリーに持つことも可能で,さらに大量のデータを扱うためにCD-ROMやサーバ側のハードディスクに持つことも可能である。」(段落【0026】)・【図1】(本発明の実施の形態であるインターネットへのアクセス方法において,クライアント側のWWWブラウザから文字列変換プログラムを介してインターネットへアクセスする方法を示す説明図)・【図2】(本発明の実施の形態であるインターネットへのアクセス方法において,クライアント側のWWWブラウザへの文字列入力からインターネットへのアクセスに至るまでの処理手順を示すフロー図)・【図3】(本発明の実施の形態であるインターネットへのアクセス方法において,URLの構成を示す説明図)イ上記記載から,引用文献9は,半角英数字であるURLに対応するユーザになじみのある文字列を用いたインターネットへのアクセス技術を提供することを目的とするものであることが認められる。そして,同文献9において,「WWWブラウザに入力された文字列」を利用して「サーバ側」のデータベースを用いて検索を行うことは,「既存情報処理手段における情報処理結果の一部または全部」を利用して「前記既存情報処理手段の外」で「処理」を行うことに相当する。また,同文献9における「入力された文字列が全角文字や半角カタカナを含む場合」(図2のステップ22(No),23(Yes)の分岐)に「データベース検索」を行うことは,入力された文字列がURLとして通常想定される半角英数字と異なる文字列を含む時の処理であって,データベースに一致する文字列が見つからなければ「エラー」メッセージを表示する(図2のステップ26)ものであるから,「エラーが発生した時」に「外部情報処理手段へと処理を分岐させる」ことに相当する。また,「データベース検索」という機能拡張をするものである。
そうすると引用文献9には次の発明(引用発明9)が記載されていることが認められる。
「クライアント側のWWWブラウザ11のアドレス欄に,ユーザが入力手段で入力した文字列を,全角文字や半角カタカナを含むか,あるいはURLの構成に沿ったものであるかを調査し,全角文字や半角カタカナを含まず,かつURLの構成に沿ったものである場合,入力された文字列をURLと見なして変換せずにインターネットへの探査を行い,入力された文字列がURLの構成に沿ったものでないか,全角文字や半角カタカナを含む場合,入力された文字列でURLデータベースを検索し,一致するURLを取得してインターネットへの探査を行い,URL変換データベースに一致する文字列が見つからなければその旨のエラーメッセージを画面上に表示する,インターネットへのアクセスシステム。」(2)対比・判断上記のとおり,先願発明9は,ブラウザに入力された文字列がURLと見なせる場合,入力された文字列を変換せずインターネットを探索する処理を行うものであり,この場合にインターネット上に置かれている情報提供サーバに蓄積された情報資源をアクセスするための一連の動作は,既存情報処理手段による情報処理に相当する。一方,ブラウザに入力された文字列がURLと見なせない場合,入力された文字列でURL変換データベースを検索して一致するURLを取得し,もし一致する文字列がなければエラーメッセージを表示するものであり,入力された文字列がURLの構成に沿ったものでないか,全角文字や半角カタカナを含む場合は「エラーが発生した時」に相当し,その際URL変換データベースを検索する処理を行うことは,既存情報処理手段における情報処理結果の一部又は全部を利用して既存情報処理手段とは別の情報処理手段へ処理を分岐さた上,「URLデータベース検索」という機能拡張をして処理を行うことに相当する。
したがって,本願発明は,引用発明2と実質的に同一の発明である。
(3)原告の主張に対する補足的判断ア原告は,引用文献9(甲9)には「URLを構成する文字列は半角の英数字であるため,日本語をローマ字や英語で表さなければならない」(段落【0005】)と記載されていることを根拠に,本願発明14と先願発明9は同一の発明ではないと主張する。
しかし,引用文献9の上記記載は先願発明9が解決しようとする課題の一部であって先願発明の内容自体に関するものではない。そして,「・・・入力された文字列が図3のURLの構成に沿ったものでないか,全角文字や半角カタカナを含む場合は,入力された文字列で図4のURLデータベースを検索し,一致するURLを取得してインターネットへの探査を行う。・・・」(段落【0024】)と記載されていることからすれば,ブラウザに入力される文字列は半角英数文字に限定されないことが認められる。
したがって,原告の上記主張は引用文献9を正解しないものであり,採用することができない。
イ次に,原告は,引用文献9の段落【0024】の1行～5行目の記載によれば,引用文献9では,全角文字や半角カタカナを含む文字列をURLとみなしておらず,これと反対の立場に立つ本願発明1,10,12～15とは異なると主張する。
しかし,全角文字等を含む文字列を「URL」に含むか否かは,何を「URL」とするかの「定義」の相違にすぎない。そして,前記のとおり,先願発明9は,「URL」に該当しない全角文字等であっても,URLに変換することにより処理できるものであってインターネットにアクセスできることを内容とする発明である。原告の上記主張は採用することができない。
ウ次に,原告は,引用文献9の段落【0018】の記載によれば,先願発明9では「クライアント側」において「文字列変換プログラムを介」する必要があるが,本願発明1,10,12～15では不要であると主張する。
しかし,原告が指摘する段落【0018】の記載及び図1には,文字列変換プログラムの位置が「クライアント側」との記載は存在せず,むしろ,請求項1及び段落【0021】には,文字列変換プログラムを「サーバ側」に設置できることが記載されている。よって,原告の上記主張はその前提において採用することができない。そもそも請求項14に各手段の位置は記載がなく,原告の主張は請求項の記載に基づかない主張である。
エ次に,原告は,文字列変換プログラム(一般に「プラグイン」と称される。)をサーバ側に置く場合でも,処理対象文字列をクライアント側での普通の取扱いを変更してクライアント側からサーバ側へと伝達する,いわば「無変換パススループログラム」(プラグインの一種といえる。)を介する必要がある点に留意する必要があると主張する。
しかし,引用文献9に「プラグイン」の用語自体の記載はなく,当然にプラグインが必要であることの記載もない。むしろ,段落【0024】の記載によれば,ブラウザに半角英数字以外を入力できるから,プラグインの検討は不要である。一方,本願の請求項14にプラグインを用いないことの記載はない。むしろ,本願明細書の段落【0069】に,ビジュアルURL(VURL)と呼ばれる点字や画像データをURLに含ませる実施例についての記載ではあるが,ブラウザ側で「プラグイン」を利用する記載があると認められる。よって,「プラグイン」の利用の有無は,本願発明との相違点となり得ず,原告の上記主張は採用することができない。
4結論以上によれば,その余について判断するまでもなく,請求不成立とした審決の結論に誤りはない。
よって,原告の請求を棄却することとして,主文のとおり判決する。

裁判長裁判官	中野哲弘
裁判官	今井弘晃
裁判官	真辺朋子

ページ上部へ