CAFC Update19

2005.4.22 

Leon STAMBLER
PlaintiffAppellant,
vs.
RSA SECURITY, INC. and VERISIGN, INC.
Defendant-Cross Appellant.

電子商取引に用いられるSSLの特許侵害

1.概要

 個人発明家Leon Stambler(以下、原告)は電子商取引において取引相手の身元を確証し、安全な取引を確保する技術に関し、1992年から1993年にかけて多数の特許出願を行い、多数の特許を成立させた。原告は所有する特許の一つであるU.S. Patent No.5,793,302(以下、302特許)を武器に攻勢をかけた。2001年2月1日、原告はRSA社及びVeriSign社(以下、被告)が使用するSSL3.0(Secure Sockets Layer version 3.0) *1が302特許クレーム34*2を侵害するとしてデラウェア連邦地方裁判所に提訴した。地裁では特許の有効性と侵害の有無とが分けて争われた。2003年4月21日地裁は、特許は有効であると判断したが、侵害に関しては非侵害と判断した*3。原告はこれを不服としてCAFCへ控訴した。CAFCではクレーム34の文言「credential(信用証明書)」が、SSL3.0におけるデジタル証明書*4に該当するか否かが争点となった。CAFCは、「credential(信用証明書)」が、SSL3.0におけるデジタル証明書に該当しないと判断した地裁の判断を支持する判決をなした。

2.背景

 SSL3.0はインターネットでの安全な通信を行うための標準的な方法として広く利用されている。SSL3.0プロトコルは、インターネットを介して通信する当事者が双方の身元を確証し、また、当事者間の通信が第3者に傍受、解読されることがないよう保証するものである。原告は「取引に関連する情報を安全にする方法」に関する302特許を1998年に成立させた。2001年2月1日、原告は被告が使用するSSL3.0が302特許クレーム34*2を侵害するとしてデラウェア連邦地方裁判所に提訴した。
 地裁では、SSL3.0プロトコルのデジタル証明書が、クレーム34にいう「credential(信用証明書)」に該当するか否かが争点となった。地裁は、明細書の記載に基づき、「信用証明書」を、「当事者の身元を確証(establish)するために転送され、または、示される信用機関から得られる文書または情報」を意味すると解釈した。被告は、デジタル証明書が提示または転送された時点では証明書の送信者の身元を認証せず、単に証明書の信憑性を確証(establish)するに過ぎないので、デジタル証明書はクレーム34にいう信用証明書ではないと反論した。地裁は被告の主張を認めSSL3.0におけるデジタル証明書は、クレーム34における信用証明書には該当せず非侵害との判決をなした。原告はこれを不服として控訴した。

3.CAFCの争点

デジタル証明書が身元を確証する「信用証明書」に該当するか?
 ユーザとWebサイトとがSSL3.0プロトコルで通信する場合、Webサイトからデジタル証明書がユーザに送信される。SSL3.0プロトコルにおいて、このデジタル証明書の提示時にWebサイトの身元を確証(establish)するか否かが問題となった。

4.CAFCの判断

デジタル証明書が提示または転送されるとき、Webサイトの身元はSSL3.0において確証されない。
 被告の専門家は争点であるクレームの文言「credential(信用証明書)」に関して証言を行った。被告の専門家は地裁のクレーム解釈を取り上げ、なぜイ号装置がクレームの文言に合致しないかに関し詳細な証言を行った。地裁では、明細書の記載から「信用証明書」を、「当事者の身元を確証(establish)するために転送され、または、示される信用機関から得られる文書または情報」を意味すると解釈した。被告の専門家は、SSL3.0は、デジタル証明書が提示または転送された時点では証明書の送信者の身元を認証しないと証言し、またデジタル証明書の送信時は単に証明書の信憑性を確証するに過ぎないので、デジタル証明書はクレーム34にいう信用証明書ではないと述べた。CAFCは被告の専門家の証言を採用し、SSL3.0におけるデジタル証明書はクレーム34における信用証明書には該当しないと結論付け、特許非侵害とする地裁の判決を支持した。

5.結論

 CAFCは、デジタル証明書の提示・転送時には、Webサイトの身元はSSL3.0において確証されないことから、クレーム34における「信用証明書」には該当しないと結論付け、特許非侵害とする地裁の判決を支持した。

6.コメント

(1)以下に、SSL3.0プロトコルの手順を説明すると共にCAFCが上記結論に至った理由を補足しておく。
SSL3.0は、ハンドシェイクプロトコルを用いており、以下のステップからなる。
ステップ1:コンピュータユーザはWebサイトと通信を開始する。その間に、第1乱数がユーザ側からWebサイトへ送信される。
ステップ2:Webサイトは第2乱数及び認証局により発行されたWebサイトのデジタル証明書を送信することにより応答する。デジタル証明書はWebサイトの身元情報(Webサイト名、Webアドレスなど)、Webサイトの公開鍵及びデジタル署名*5を含んでいる。デジタル署名以外のデジタル証明書に記載される全ての情報(公開鍵含む)は、ハッシュ関数*6によりメッセージダイジェストに変換される。メッセージダイジェストは認証局の秘密鍵により暗号化される。
ステップ3:ユーザはWebサイトのデジタル署名を復号するためにユーザのブラウザに格納されている認証局の公開鍵を用いる。復号されたデジタル署名と、デジタル証明書の内容をハッシュ関数によりメッセージ・ダイジェストに変換したものとを比較することにより、ユーザは、デジタル証明書が本物であると実証する。このデジタル証明書が提示されたステップの終わりに、ユーザは、証明書及び対応するWebサイトの公開鍵は本物(authentic)であると判断できる。
 すなわち、デジタル証明書は、デジタル署名解析用の公開鍵が真正であり、またこのデジタル証明書が本当に認証局により発行されたものであるかを示すに過ぎず、この段階ではそれが本物のソースから受信したとは判断できない。このデジタル証明書の提示段階においては、クレーム34におけるようにWebサイトの身元を確証しない。
 地裁ではこの点について、簡単な例を挙げている。「これは運転免許書に似ている。運転免許書を所持している人物が本当の所有者であるかを決定しなくとも、運転免許書は本物(authentic)であると決定することは可能である。」
 以上のことから、CAFCはSSL3.0におけるデジタル証明書はクレーム34における信用証明書には該当しないと判断したのである。なお、SSL3.0プロトコルのこれ以降の処理については省略する。
(2)個人発明家Leon Stambler氏は1992年から1993年にかけて電子商取引に関する多数の特許出願を行い、6年間の間に多数の特許を成立させた。その一方でNetscape Communications社はSSLの開発を進めてきた。今やインターネットにおける商取引でSSLは欠かせない。Stambler氏はこれらの特許をもとにライセンス交渉を各社と行った。例えばFirst Data Corp.は約4億円を支払った。次いで本件被告らを提訴したが、特許非侵害の判決となった。302特許がSSL特許をカバーできなかったのは、本特許はもともとATM(automatic teller machine)での認証を意図していたからである*7

判決 2005年2月11日

以 上

【関連事項】

判決の全文は下記のジョージタウン大学Law Centerのライブラリから閲覧することができます[PDFファイル]。

http://www.ll.georgetown.edu/federal/judicial/fed/opinions/04opinions/04-1129.pdf

【注釈】

*1 Netscape Communications社が開発した、インターネット上で情報を暗号化して送受信するプロトコル。現在インターネットで広く使われているWWWやFTPなどのデータを暗号化し、プライバシーに関わる情報やクレジットカード番号、企業秘密などを安全に送受信することができる。SSLは公開鍵暗号や秘密鍵暗号、デジタル証明書、ハッシュ関数などのセキュリティ技術を組み合わせ、データの盗聴や改ざん、なりすましを防ぐことができる。OSI参照モデルではセッション層(第5層)とトランスポート層(第4層)の境界で動作し、HTTPやFTPなどの上位のプロトコルを利用するアプリケーションソフトからは、特に意識することなく透過的に利用することができる。SSL 3.0をもとに若干の改良が加えられたTLS 1.0がRFC 2246としてIETFで標準化されている。(IT用語辞典http://www.itmedia.co.jp/dict/
*2 302特許クレーム34はクレーム33の従属クレームでありその内容は以下のとおり。

33. A method for authenticating a first party by using information stored in a credential, the credential being previously issued to the first party by a second party, wherein information previously stored in the credential comprises at least a non-secret variable authentication number (VAN) and other non-secret credential information, the method comprising:
previously generating a first error detection code (EDC1) by using at least a portion of the other non-secret credential information;
previously coding the first error detection code (EDC1) with first information associated with the second party to derive a variable authentication number (VAN);
previously storing the VAN and the other non-secret credential information in the credential;
retrieving the VAN and the other non-secret credential information stored in the credential;
deriving a second error detection code (EDC2) by using at least a portion of the retrieved other non-secret credential information;
retrieving second information associated with the second party previously stored in a storage means associated with at least one of the parties;
uncoding the VAN using the second information associated with the second party to derive a third error detection code (EDC3);
and authenticating the first party and at least a portion of the non-secret information stored in the credential if the second error detection code (EDC2) corresponds to the third error detection code (EDC3).
34 The method of claim 33 wherein the first information associated with the second party comprises a public key, and the second information associated with the second party comprises a non-secret key.
*3 Stambler v. RSA Security, No. 01-0065-SLR (D.Del.2003)
*4 認証局(CA)が発行する、デジタル署名解析用の公開鍵が真正であることを証明するデータ。デジタル署名単独では公開鍵が本人のものであるか確認できないが、デジタル証明書をデジタル署名に付属させることにより、データが改ざんされていないこととともに(この機能はデジタル署名単独で実現できる)、データの作成者を認証局を通して証明することができる。デジタル証明書は誰でも作成できるが、デジタル証明書の信頼性は認証局の信頼性に依存する。したがって、特に本人確認が重要となる用途では、信頼のある認証局にデジタル証明書を発行してもらうことによって、データの出所を確実にすることが求められる。(前掲IT用語辞典)
*5 デジタル文書の正当性を保証するために付けられる暗号化された署名情報。公開鍵暗号方式の応用によって、文書の作成者を証明し、かつその文書が改竄されていないことを保証する。署名者は、自身の秘密鍵を用いて暗号化した署名を文書に付加して送る。受取人は、署名者の公開鍵を用いて署名を復号し、正しい内容かどうか確認する。第三者による偽造防止の他、署名者がその文書を作成したことの証明にも用いることができるのが特徴。(前掲IT用語辞典)
*6 与えられた原文から固定長の疑似乱数を生成する演算手法。生成した値は「ハッシュ値」と呼ばれる。「要約関数」「メッセージダイジェスト」とも呼ばれる。通信回線を通じてデータを送受信する際に、経路の両端でデータのハッシュ値を求めて両者を比較すれば、データが通信途中で改ざんされていないか調べることができる。不可逆な一方向関数を含むため、ハッシュ値から原文を再現することはできず、また同じハッシュ値を持つ異なるデータを作成することは極めて困難である。通信の暗号化の補助や、ユーザ認証やデジタル署名などに応用されている。(前掲IT用語辞典)
*7 Steven M. Cherry 「Web Only News」
(http://www.spectrum.ieee.org/WEBONLY/wonews/mar03/stambler3.html)


Copyright 2005 KOHNO PATENT OFFICE