【知財高判平成22年3月24日平20(ネ)10085号[Japan NLIA System事件]】

【要旨】
 本判決は、ソフトウェア特許の侵害訴訟において、特許権者が勝訴した事例である。

【キーワード】
ソフトウェア特許、充足論、特許発明の技術的範囲、特許請求の範囲基準の原則、明細書参酌の原則、特許法70条

1 特許発明の内容1

特許番号  第3762882号
出 願 日 平成8年6月3日
優 先 日 平成7年6月7日(アメリカ合衆国)

A インターネットよりなるコンピュータネットワークを介したクライアントからサーバーシステムへの情報ページに対するアクセスを提供する方法であって,
B 前記クライアントにおいて記述子を提供する段階と,
C ディレクトリサーバーが,前記記述子を前記ディレクトリサーバーに存在する翻訳データベースを用いてURLにマッピングする段階と,
D 前記ディレクトリサーバーが,REDIRECTコマンド中の前記URLを前記クライアントに返送する段階と,
E 前記クライアントに前記URLを用いて情報を要求させる段階と,
F 前記URLにより識別されたページを前記クライアント側で表示する段階
G を備えた情報ページに対するアクセス方法。

2 充足性に関する争点

① 構成要件B「記述子」の充足性
② 構成要件C「ディレクトリサーバーが,前記記述子を前記ディレクトリサーバーに存在する翻訳データベースを用いてURLにマッピングする段階」の充足性
③ 構成要件E「前記クライアントに前記URLを用いて情報を要求させる段階」及び構成要件F「前記URLにより識別されたページを前記クライアント側で表示する段階」の充足性

3 構成要件B「記述子」の充足性

⑴ 被控訴人の主張

 「記述子」は,任意のものを意味し,URLでないものに限定する理由はない。
・・・
 ユーザーがURLを知る必要がないという本件発明の効果から,構成要件Bの「記述子」をURLとは異なるものであると限定する解釈は,当然には導かれない。
・・・
 被告方法では,『アドレスバー』に入力された記述子はDNSサーバーに送られており,直接ディレクトリサーバーに送られていないから,構成要件Bを充足しない。

⑵ 判旨

(1)  構成要件B
ア 構成要件Bは,「前記クライアントにおいて記述子を提供する段階と,」と規定するものである。
 そして,特許請求の範囲の記載によると,本件発明において,「記述子」は翻訳データベースによりURLにマッピングされ,そのURLがクライアントに返送され,返送されたURLを用いてクライアントは情報を要求することになるのであるから,構成要件Bにおける「記述子」がURLを含まないことは明らかである。
 しかしながら,本件特許出願に係る明細書(以下「本件明細書」という。)の発明の詳細な説明には,「【0041】本発明の一構成では,商業者のサービスにアクセスするためにユーザが従来の電話番号,またはその他の識別子を利用できるようにする便が設けられている。」,「【0042】別の実施形態では,従来のブラウザを備えた形で,クライアント601が“ダイヤル”コマンドの場所に電話番号,またはその他の識別子を入れることを促すディレクトリサーバー602により提供された書式ページを用いる。」及び「【0044】別の実施形態では,数字以外の識別子を設けることができる。例えば,ユーザは会社名または製品名を不正確なつづりで記入することがある。このような場合“soundex”または他の音声マッピングが同じ目標URLに対するマップと類似して響く語を許容するため用いることができる。また,製品名または内線と組み合わせた電話番号のような複数の識別子も使用可能である。」との記載があるところ,これらの記載がクライアントが提供する「記述子」を特定の種類のものに限定する趣旨のものとは解されない。
 そうすると,構成要件Bにおける「記述子」は,URLそのものを含まないと解されるほかには,特段の限定がないものと解されるべきである。
イ 他方,被控訴人方法のうち,サーバー方式は,構成B’「ユーザーがクライアントPCのウェブブラウザのアドレスバーに任意の日本語インターネットアドレス(JAddress)を入力して(1),同日本語インターネットアドレス(2)(正規URL)又は(2’)(非正規URL)を予めプログラム①の付加されたDNSサーバー(NLIA Name Server)に提供する段階(2)又は(2’)と,」を備えるものであり,また,プラグイン方式は,同B”-Ⅰ「ユーザーがクライアントPCのウェブブラウザのアドレスバーに任意の日本語インターネットアドレスを入力し(1),予めクライアントに付加されたプログラム②が,同日本語インターネットアドレス(2)(正規URL)又は(2’)(非正規URL)を正規URLであるか否かを選別する段階(3)と,」を備えるものである。
 そうすると,被控訴人方法は,いずれもユーザーがクライアントPCにおいて任意の日本語インターネットアドレスを入力するという段階を含むところ,日本語インターネットアドレス(2)には,正規URLと非正規URLとが含まれることが想定され得るが,被控訴人方法において非正規URLが提供される場合が存在する以上,被控訴人方法はクライアントにおいても「記述子」を提供する段階を含むものというべきである。
ウ 被控訴人は,本件発明における記述子の提供方法について,被控訴人方法のようにクライアントPCのウェブブラウザのアドレスバーに入力する方法によるものは含まれないと主張するが,構成要件Bが記述子の「提供の方法」を限定するものでないことは上記アのとおりであるから,被控訴人の主張を採用することはできない。
エ したがって,被控訴人方法は,本件発明の構成要件Bを充足する。

4 構成要件C「ディレクトリサーバーが,前記記述子を前記ディレクトリサーバーに存在する翻訳データベースを用いてURLにマッピングする段階」の充足性

⑴ 被控訴人の主張

 被告方法は,プラグイン方式を含め,アドレスバーに記述子を記入しているから,構成要件Cの「前記記述子」を充足しない。
 仮に,構成要件Bの「記述子」に,アドレスバーに記入された記述子が含まれるとしても,被告方法では,アドレスバーに記入された記述子について,これが正規URLか否かを選別し,非正規URLと選別された記述子に限り,「NLIA サーバー」に送られる。したがって,被告方法の構成C’-Ⅲ,C”でディレクトリサーバーに送られる日本語インターネットアドレスは,被告方法の構成B’,B”-Ⅰでクライアントが提供する日本語インターネットアドレスと同義ではないから,被告方法は,構成要件Cの「前記記述子」を充足しない。

⑵ 判旨

(2) 構成要件C
ア 構成要件Cは「ディレクトリサーバーが,前記記述子を前記ディレクトリサーバーに存在する翻訳データベースを用いてURLにマッピングする段階と,」と規定するものである。なお,「前記記述子」は,上記(1)において説示したとおり,URLを含まないものと解される。
イ 他方,被控訴人方法の構成のうち,クライアントによって入力される日本語インターネットアドレスが正規URLでない場合について,被控訴人の主張に沿ってみてみると,サーバー方式は,構成C’-Ⅰ「NLIA Name Server内において,付加プログラム①が,クライアントPCから送信された日本語インターネットアドレスが正規URLであるか否かを選別し(3),」,同C’-Ⅱ「正規URLでない場合,「NLIA サーバー」のIPアドレスをクライアントに送り返す段階(4’)と,クライアントPCが,取得したIPアドレスの「NLIA サーバー」に向けて当初ユーザーが入力した日本語インターネットアドレスを問い合わせる段階(5)と,」及び同C’-Ⅲ「日本語インターネットアドレスの送信を受けた「NLIA サーバー」が,当該日本語インターネットアドレスに対応するURLを登録情報データベースから取得する段階(6)と,」を備えるものであり,また,プラグイン方式は,構成B”-Ⅱ「入力された日本語インターネットアドレスが…正規URLでない場合(2’),当該日本語インターネットアドレスをNLIA サーバーへのURL形式に変更した上,ブラウザの機能によって当該変更したURL(2”)をDNSサーバーに送信して,DNSサーバーの機能によってNLIA サーバーのIPアドレスをクライアントPCに送り返す段階(4’)と,」,同B”-Ⅲ「クライアントPCが,取得したIPアドレスのNLIA サーバーに向けて,当初ユーザーが入力した日本語インターネットアドレスを問い合わせる段階(5)と,」及び同C”「問い合わせを受けたNLIA サーバーが,当該日本語インターネットアドレスに対応するURLを登録情報データベースから取得する段階(6)と,」を備えるものである。
ウ しかるところ,被控訴人方法は,いずれも登録情報データベースから非正規URLである日本語インターネットアドレスに対応するURLを取得する段階を備えるものであるから,被控訴人方法は本件発明の構成要件Cを充足することになる。
 この点について,被控訴人は,被控訴人方法の構成は,正規URLと非正規URLとを選別する段階を必須とするものであり,非正規URLであると選別された記述子に限って「NLIA」サーバーに送られ,サーバー方式において上記選別の段階を担う「NLIA Name Server」は「NLIA サーバー」とは別のサーバーであると主張するが,本件発明における「記述子」が正規URLを含まないものであることは上記(1)のとおりであり,本件発明の構成要件をすべて充足するアクセス方法に正規URLの処理に関する機能が加わったり,途中にクライアントPCを介する処理が加わったりしても,そのアクセス方法が本件発明の技術的範囲に含まれなくなるものではないから,被控訴人の主張は失当である。
 そうすると,本件発明との対比において必要となる被控訴人方法の構成は,別紙構成一覧に記載したものに尽きるのであり,被控訴人方法のサーバー方式に係るものは,少なくとも同記載のC’-Ⅱの構成を備えるものとして認定することができる。
 また,被控訴人は,被控訴人方法は,記述子をアドレスバーに入力するものであるから,構成要件Cの「前記記述子」を充足しないとも主張するが,この主張を採用することができないことは上記(1)のとおりである。

5 構成要件E「前記クライアントに前記URLを用いて情報を要求させる段階」及び構成要件F「前記URLにより識別されたページを前記クライアント側で表示する段階」の充足性

⑴ 被控訴人の主張

(ア) 解釈
ア 特許請求の範囲の解釈
(ア) 解釈
 原告の主張ア(ア)は争う
 本件発明は,ディレクトリサーバーがURLを返送する段階(構成要件D)とディレクトリサーバーがURLを用いて情報を要求する段階(構成要件E)の2つの段階を含んでおり,方法の発明である以上,構成要件Dと構成要件Eとは,時系列的に異なる段階として行われる必要がある。
・・・
イ 充足
 同イ(ア)は否認する。
 被告方法では,ディレクトリサーバーである「NLIA サーバー」が,構成要件Dとは時系列的に異なる段階として,クライアントにURLを用いて情報を要求させる段階(構成要件E)を行っていない。殊に,被告方法では,同構成E’及び構成E”のとおり,クライアントのブラウザのアドレスバーを利用した標準的なプロトコルを用い,「NLIA サーバー」からアドレスバーに所期のURLを返しさえすれば,その後は,クライアントに備わっているブラウザが当該URLによって識別されたページを(DNSサーバーを介して)取得し,クライアントPCに表示するものであり,時系列的に異なる段階として,構成要件Eに当たる段階を有しないことは明らかである。

⑵ 判旨

(3) 構成要件E及びF
ア 本件発明の構成要件Eは「前記クライアントに前記URLを用いて情報を要求させる段階と,」と規定し,同Fは「前記URLにより識別されたページを前記クライアント側で表示する段階と」と規定する。
イ 他方,被控訴人方法のうち,サーバー方式は,構成E’「クライアントPCが,取得したURLを一旦DNSサーバーを経由して(8),対応するIPアドレスを取得し(9),目的の情報ページの情報を要求する段階(10)と,」及び同F’「クライアントPCが,目的の情報ページを表示する段階と(11),」を備えるものであり,また,プラグイン方式は,構成E”「クライアントPCが,取得したURLを一旦DNSサーバーを経由して(8),対応するIPアドレスを取得し(9),目的の情報ページの情報を要求する段階(10)と,」及び同F”「クライアントPCが,目的の情報ページを表示する段階と(11),」を備えるものである。
ウ そして,被控訴人方法における「取得したURLを一旦DNSサーバーを経由して(8),対応するIPアドレスを取得し(9),」とは,クライアントが情報を要求する前提として,ディレクトリサーバーから返送されたURLを用いていることにほかならず,被控訴人方法においては,このIPアドレスによって「目的の情報ページの情報を要求する」ものであるから,被控訴人方法は本件発明の構成要件Eを充足することになる。
 また,本件発明の構成要件Fにおける「URLにより識別されたページ」とは,URLによって特定されたクライアントが目指すページを意味することは特許請求の範囲の記載から明らかであるところ,被控訴人方法の構成F’及びF”における「目的の情報ページ」とは,正にこのような「URLにより識別されたページ」であるから,このようなページが「クライアントPC」,すなわち「クライアント側」で表示される段階を備える被控訴人方法は,本件発明の構成要件Fを充足するものである。
エ 被控訴人は,構成要件Eの充足性に関し,本件発明は方法の発明であり,出願経過における控訴人の意見書の記載からも,構成要件Eの段階は,構成要件Dの段階である「前記ディレクトリサーバーが,REDIRECTコマンド中の前記URLを前記クライアントに返送する段階」と時系列的に異なる段階として行われる必要があるものと解釈すべきであるとした上,被控訴人方法においては,クライアントのブラウザのアドレスバーを利用した標準的なプロトコルを用いて,「NLIA サーバー」からアドレスバーに所期のURLを返しさえすれば,その後は,クライアントに備わっているブラウザが当該URLによって識別されたページを(DNSサーバーを介して)取得し,クライアントPCに表示するものであり,本件発明のように構成要件Dに相当する段階と別の段階として構成要件Eに相当する段階を備えているものではないと主張する。
 しかしながら,本件明細書の発明の詳細な説明をみると,本件発明の概要について「【0012】認証サーバーは,次いでこのSIDが付加されたオリジナルURLから成る新しい要求を,REDIRECTによってクライアントに送出する。新しいURLにより形成された修正要求は,自動的にクライアントブラウザによりコンテンツサーバーに送出される。」との記載があるほか,実施形態について「【0045】メッセージ2では,ディレクトリサーバー602がREDIRECTをクライアント601に送信し,これには,データベース604から演算されたNUMBERに対する目標URLが記述されている。クライアントブラウザ601は続いて自動的にメッセージ3を送信し,このURLのコンテンツをGETする。サーバー602が最終的なURLに対する翻訳を行い,ページよりはむしろREDIRECTをクライアント601に送信するため,メッセージ4のドキュメントは最初のダイヤル入力以上のユーザーの行為なしで入手される。」及び「【0047】“ダイヤル”コマンドおよびその実施の利点の中には,従来の電話番号および他の識別子と互換性を有する,インターネットにアクセスする改善された方法がある。商業者はコンタクト情報のインターネット特定書式を提供するための印刷物またはテレビ広告を変更する必要がなく,ユーザはURLについて知る必要がない。」との記載があるのであって,この記載によると,本件発明においても,REDIRECTを送信し,この送信されるデータ中に目標URLが記述されているのであり,アクセス方法の段階としては,構成要件Dの段階と同Eの段階とは論理的に順次発生するものである。
 他方,被控訴人方法においても,サーバー方式の構成D’及び同E’,プラグイン方式の構成D”及び同E”において,それぞれREDIRECTコマンドを利用してURLを送信する段階とURLに基づいて情報を要求する段階を実現しているのであり,これらの段階が順次発生するものであることは論理的に明らかであるから,被控訴人方法も,これらの順次発生する段階を備えているというべきである。
 なお,被控訴人の主張が被控訴人方法が構成要件Eの段階のみを実現する独立の構成を備えていないという趣旨であるとしても一般に,デジタル通信においては,複数のデータを同時に送信することが可能であり,これら複数のデータを命令の形式で構成することも可能であるところ,本件明細書における上記各記載によると,本件発明は,REDIRECTコマンドとともにクライアントに返送されたURLに基づいて,自動的にクライアントに情報を要求させ(,同要求に係るURLによって識別されたページを自動的にクライアント側において表示す)るものを含むと解することに支障はなく,上記のとおり,そのようなものも構成要件Dの段階と同Eの段階を順次発生させるものと解すべきであるから,被控訴人方法は本件発明の構成要件D及び同Eを充足することになる。
 控訴人は,本件特許の出願経過において,構成要件D及びEを別々の段階として書き分けることを内容とする平成17年12月5日付け手続補正書による補正についての意見書において,「1つの段階から,URLの返送段階と,そのURLを用いた情報要求段階との2つの段階に分けて表現し,記載の明瞭化を図りました。」と記載しているが,この記載は,本件発明が備えるべき段階を書き分けることによって発明特定事項を明瞭にするものと理解することができるものであり,上記に説示したところによると,上記補正によって,本件発明が,構成要件Dに相当する段階と同Eに相当する段階が時系列的に別の段階としてそれぞれ独立して存在するものに限定されると理解することはできない。
 したがって,被控訴人の主張を採用することはできない。
 また,被控訴人は,構成要件Fについても,上記と同様の主張をするが,これを採用することができないことは,上記のとおりである。

6 検討

⑴ ソフトウェア特許の侵害訴訟において、請求が認容された事例は、これまでに3件存在するが2、本件はそのうちの1件である。また、特許権侵害訴訟において、地裁における原告の勝訴率が22%であるのに対し、ソフトウェア特許における原告の勝訴率は1.9%であり、原告にとって勝訴し難いとのデータが存在する3。このような中で本件は、ソフトウェア特許の侵害訴訟において、原告が勝訴した貴重な事例であるといえるが、被控訴人方法が、本件特許の実施例とほぼ同じ事案であり、充足性が肯定されるのは当然の結果と位置付けられる。
 なお、原審の東京地判平成20年10月17日平19(ワ)2352号は、充足性は判断せず、進歩性違反を理由に、請求を棄却していた。

⑵ 本判決の争点の中では、判決における「記述子」に関する判断が参考になる。「記述子」の文言は抽象的な文言であるため、明細書を参酌し、限定解釈がされると、被控訴人方法の「非正規URL」が充足するかが問題になり得る。
 しかし、本件では、「記述子」がURLのマッピングに用いられているという技術的意義や、明細書には「識別子」を実施例に記載された電話番号等に限定せず、それ以外のものも識別子に含まれることを補強する記載があることから、実施例に記載がない「非正規URL」も「記述子」に含むとの判断がなされた。

⑶ また、他の争点としては、構成要件Bの判断については、記述子を提供する先のサーバーの種類に限定がなく、サーバー間に中継サーバーが入った場合にクレームから除外される記載はないと思われることから、充足性を肯定した判決の認定は当然のものといえる。
 構成要件Cの判断については、被控訴人方法は、特許請求の範囲に記載されていない付加的な処理(正規化URLの処理)、付加的な構成(複数のサーバー)が加わったとしても充足性を肯定するものであるが、かかる判決の認定も当然のものといえる。

⑷ 以上のとおり、本件は、ソフトウェア特許の侵害訴訟において、原告が勝訴した貴重な事例であるといえるが、被控訴人方法が、本件特許の実施例とほぼ同じ事案であることから、ソフトウェア特許の侵害訴訟におけるクレーム解釈に関し、特に先例性があるという判決ではない。

以上
(文責)弁護士・弁理士 杉尾雄一


1 請求項1を分節。特許権設定登録時の内容。
2 李思思「侵害訴訟にみるソフトウェア特許‐特許庁と裁判所の『連携プレイ』と裁判所の『単独プレイ』による保護範囲の限定の状況」知的財産法政策学研究51号160-161頁(2018年)。
3 前掲李。