ワンタイムパスワード事件

投稿日: 2017/09/18 20:35:07

今日は、平成27年(ワ)第36981号 虚偽事実の告知・流布差止等本訴請求事件及び平成28年(ワ)第17527号 特許権侵害差止等反訴請求事件について検討します。平成27年(ワ)第36981号は実質的には債務不存在確認訴訟と同じような内容だと思います。原告である株式会社シー・エス・イーは、判決文によると、各種情報処理に関するシステム分析,開発及びプログラミング等を目的とする株式会社だそうです。一方、被告であるパスロジ株式会社はコンピュータに関するハードウェア・ソフトウェアの開発,製造,販売,リースならびに保守サービス等を目的とする株式会社だそうです。J-PlatPatで検索したところ、株式会社シー・エス・イーは10件、パスロジ株式会社は14件の特許を取得しています。

 

1.手続の時系列の整理

① 本事件は特許3件ですが2件は本件特許権3から分割したものです。

② 本件特許権2、3は非常に多くの閲覧を請求されています。ワンタイムパスワードに関する特許なので注目が高いのは理解できますが、J-PlatPatの審査書類情報照会でほとんどの審査過程の書類がダウンロードでき、またWIPOホームページで国際公開公報もダウンロードできるのに何故これほど閲覧請求が多いのか謎です。

2.本件発明の内容

2.1 本件発明1(特許第4455666号 請求項8)

1A:端末装置(13)と、前記端末装置(13)と通信回線を介して接続されたサーバ(12)とを含む、ユーザ認証に用いられるパスワードを導出するためのパスワード導出パターンの登録システムであって、

1B 前記端末装置(13)は、

1B-1:複数の要素から構成される所定のパターンの要素のそれぞれに所定のキャラクタを割り当てた提示用パターンを表示し、これにより、前記提示用パターンについての特定の要素に割り当てられたキャラクタの入力を促すための手段と、

1B-2:前記入力されたキャラクタに基づいてパスワード導出パターンが特定されるまで、新たな提示用パターンを表示する処理を繰り返し、

1B-3:これにより、前記新たな提示用パターンについての特定の要素に割り当てられたキャラクタの入力を促す処理を繰り返す手段と、を有し

1C:前記端末装置(13)と通信回線を介して接続されたサーバ、前記特定されたパスワード導出パターンを登録させるための手段を備える

1D:パスワード導出パターンの登録システム。

 

 

2.2 本件発明2(特許第4275080号 請求項1)

2A:ユーザ認証に用いられるパスワードを導出するためのパスワード導出パターンの登録方法であって、

2B:サーバが、複数の要素から構成される所定のパターンの要素のそれぞれに所定のキャラクタを割り当てた提示用パターンを生成する生成ステップと、

2C:サーバが、前記生成した提示用パターンを前記ユーザに提示して、前記提示パターンについての特定の要素に割り当てられたキャラクタの入力を促す入力ステップと、

2D:サーバが、前記入力されたキャラクタに基づいてパスワード導出パターンが特定されるまで、前記生成ステップおよび前記入力ステップを繰り返す特定ステップと、

2E:サーバが、前記特定したパスワード導出パターンを登録する登録ステップと、

2F:を備えることを特徴とするパスワード導出パターンの登録方法。

 

 

2.3 本件発明3(特許第3809441号 請求項26)

3A:コンピュータを、

3B:所定のパターンを構成する要素群の中から選択された特定の要素に基づくパスワード導出パターンを、ユーザに対応づけて登録する登録手段、

3C:前記ユーザの情報端末装置から送信された、利用対象システムに割り当てられたシステム識別情報を受け付ける受付手段、

3D:前記情報端末装置から前記システム識別情報を受け付けた場合に、前記所定のパターンを構成する要素群のそれぞれに所定のキャラクタを割り当てた提示用パターンを生成する生成手段、

3E:前記情報端末装置に、前記生成した提示用パターンを送信する送信手段、

3F:前記利用対象システムからキャラクタを受け付け、前記提示用パターンと前記ユーザのパスワード導出パターンとに基づいて、前記受け付けたキャラクタが正当であるか否かを判断する第1の判断手段、

3G:前記情報端末装置から受け付けたシステム識別情報に基づいて、前記キャラクタを受け付けた前記利用対象システムが正当であるか否かを判断する第2の判断手段、

3H:前記第1の判断手段が判断した結果を前記利用対象システムに通知する通知手段、

3I:として機能させるためのプログラム。

 

2.4 本件発明4(特許第3809441号 請求項25)

4A:所定のパターンを構成する要素群の中から選択された特定の要素に基づくパスワード導出パターンを、ユーザに対応づけて登録する登録手段と、

4B:前記ユーザの情報端末装置から送信された、利用対象システムに割り当てられたシステム識別情報を受け付ける受付手段と、

4C:前記情報端末装置から前記システム識別情報を受け付けた場合に、前記所定のパターンを構成する要素群のそれぞれに所定のキャラクタを割り当てた提示用パターンを生成する生成手段と、

4D:前記情報端末装置に、前記生成した提示用パターンを送信する送信手段と、

4E:前記利用対象システムからキャラクタを受け付け、前記提示用パターンと前記ユーザのパスワード導出パターンとに基づいて、前記受け付けたキャラクタが正当であるか否かを判断する第1の判断手段と、

4F:前記情報端末装置から受け付けたシステム識別情報に基づいて、前記キャラクタを受け付けた前記利用対象システムが正当であるか否かを判断する第2の判断手段と、

4G:前記第1の判断手段が判断した結果を前記利用対象システムに通知する通知手段と、

4H:を備えることを特徴とするユーザ認証装置。

3.争点

【反訴について】

(1)原告製品は本件各発明の技術的範囲に属するか(争点1)

ア 本件登録システムは本件発明1の技術的範囲に属するか(争点1-1)

具体的には,構成要件1B-2,1B-3,1Cの充足性

イ 本件登録システム方法は本件発明2の技術的範囲に属するか(争点1-2)

具体的には,構成要件2B,2C,2D,2Fの充足性

ウ 本件ユーザ認証システムプログラムは本件発明3の技術的範囲に属するか(争点1-3)

具体的には,構成要件3C,3D,3E,3G,3Iの充足性

エ 本件ユーザ認証システム装置は本件発明4の技術的範囲に属するか(争点1-4)

具体的には,構成要件4B,4C,4D,4F及び4Hの充足性

(2)本件特許1の無効理由の有無(争点2)

ア 特許法29条の2違反(争点2-1)

イ 公然実施(争点2-2)

(3)原告による間接侵害の成否(争点3)

(4)直接侵害の教唆・幇助行為による原告の不法行為の成否(争点4)

(5)被告の損害額(争点5)

【本訴について】

(6)本件各書状及び本件メールの送付等は,原告の「営業上の信用を害する」ものか(争点6)

(7)本件各書状及び本件メールの内容は「虚偽」であるか(争点7)

(8)被告の行為の違法性・違法性阻却事由の有無(争点8)

(9)被告の過失の有無(争点9)

(10)原告の損害額(争点10)

(11)信用回復措置の必要性の有無(争点11)

4.裁判所の判断

【反訴について】

4.1 争点2(本件特許1の無効理由の有無)について

事案に鑑み,争点2から判断する。

(1)争点2-1(特許法29条の2違反)について

ア 本件発明1と甲11発明(特開2002-366517公報)の同一性について

(ア)被告は、当初、本件発明1と甲11発明が同一であることを認めていたが、後に、自白を撤回し、甲11発明に係る明細書の記載(【図4】)によれば、明細書記載の2回の入力(段落【0018】ないし【0021】)によってランダムパスワードの位置は確定されないから、甲11発明は、本件発明1の有する「パスワード導出パターンが特定されるまで、新たな提示用パターンを表示する処理を繰り返し」との構成を少なくとも有しない旨主張するに至った。

そこで、以下、甲11発明が「パスワード導出パターンが特定されるまで、新たな提示用パターンを表示する処理を繰り返し」との構成を有するか否かについて検討する。

(イ)甲11発明に係る明細書には、以下の記載がある。

「以下、ワンタイムパスワード発行の手順について説明する。最初に、端末装置1から前記ユーザ情報をデータベース45に登録する初期登録時点において、認証サーバ42は、ウエブサーバ43を介してアクセス元の端末装置1に初期ワンタイムパスワード情報登録URLを通知する電子メールを送信する。」(段落【0018】)

「端末装置1のユーザは、初期ワンタイムパスワード情報登録URLにおいて、認証サーバ42からウエブサーバ43を介して送られた図3のようなウエブページを見て、縦4個×横12個のランダムパスワードの中から例えば4つを選択し、選択したパスワードを図3の「パスワード」と表示された箇所に入力する。縦4個×横12個の各ランダムパスワードには、図4(a)に示すように、(A、1)から(D、12)までの座標が付与されている。」(段落【0019】)

「端末装置1のユーザは、例えば座標(A、3)、(B、7)、(C、4)、(D、9)を位置登録したい場合、これらの各座標位置に配置されているランダムパスワード、すなわち「6」、「3」、「4」、「1」を入力する。次に、認証サーバ42からは図4(b)に示すような2回目のランダムパスワードが送られる。端末装置1のユーザは、図4(b)のランダムパスワードの配置を見て、前述の座標位置(A、3)、(B、7)、(C、4)、(D、9)に配置されているランダムパスワード、すなわち「3」、「2」、「0」、「2」を入力する。認証サーバ42は、2回の入力により、ユーザによって選択されたランダムパスワードの位置(A、3)、(B、7)、(C、4)、(D、9)を確定し、確定した位置情報を前記ユーザ情報としてデータベース45に登録する。」(段落【0020】)

「最後に、認証サーバ42は、アクセス元の端末装置1のユーザ毎及びアクセス先のサービス提供者装置3-1~3-3毎に異なる前記第1のURLを通知する電子メールを、ウエブサーバ43を介してアクセス元の端末装置1に送信する。以上で、初期登録が終了する。」(段落【0021】)

(ウ)上記(イ)の明細書の記載によれば、甲11発明においては、認証サーバから2回のランダムパスワードが送られ、端末装置のユーザによる2回の入力によってユーザにより選択されたランダムパスワードの位置が確定し、確定した位置情報の登録を経てワンタイムパスワードの発行に係る初期登録が行われるものと解される。そして、上記明細書の記載において引用された【図4】は、認証サーバから送られるランダムパスワードについて、各座標位置に数字がランダム配置されていることを示す一例にすぎないというべきであるから、仮に、【図4】を前提に、2回の入力によって特定される座標が複数存在し得る結果になるとしても、直ちに上記初期登録の手順が否定されることにならないと解すべきである。

そうすると、甲11発明は、ワンタイムパスワードの導出パターンの座標が特定されるために、2回にわたりパターン(ランダムパスワード)を表示する処理が行われているといえるから、甲1発明の有する「パスワード導出パターンが特定されるまで、新たな提示用パターンを表示する処理を繰り返し」との構成を有すると認められる。そして、他の構成においても、甲1発明と甲11発明に異なる点はないから、両発明は同一であると認められる。

イ 本件発明1と甲11発明の発明者の同一性について

(ア)後掲各証拠及び弁論の全趣旨によれば、以下の事実が認められる。

a Aは、平成9年頃、ブラウザ画面上に表示されたマトリクス状の文字や数字から、あらかじめ登録した位置と順番で文字や数字を抜き出し、ワンタイムパスワードとして入力するシステム(パスロジック方式)を開発した。(乙13、37)

b Aが代表取締役を務めていたメディア社は、同年7月28日、パスロジック方式を採用したパスワード認証システム「OFFIC」の販売を開始し、その後、OFFIC関連の事業はメディア社から被告に承継された。(乙13、37)

c NTTコムによるモバイルコネクトサービスの開発に係るプロジェクト(本件プロジェクト)は、平成11年頃に立ち上がり、同社従業員のBが同プロジェクトチーム約20名のトップの立場を務めた。(乙27、28)

d NTTコムは、モバイルコネクトサービスのユーザ認証システムにOFFICを利用することを考え、同サービスの開発を分担していたベース社に開発を委託し、ベース社が被告に再委託し、開発が進められた。(乙27、28、38)

本件プロジェクトの開発会議には、NTT社のプロジェクトチームメンバーのほか、C(ベース社の代表取締役)やA(被告の代表取締役)も参加しており、Cが開発会議において、モバイルコネクトサービスに関するアイデアを提示することもあった。なお、NTTコムとベース社との契約により、モバイルコネクトサービスの開発に関するベース社のアイデアは、すべてNTTコムに帰属することとなっていた。(乙27、28)

e Cは、被告からOFFICのPerl言語のロジックの開示を受け、平成12年11月22日付けで「モバイルプラットフォームプロジェクト ワンタイムパスワード:OFFIC連携について」と題する文書(以下「本件C文書」という。)を作成した。同文書には、「2.初回の登録方式」として、以下の内容が記載されている。(乙5)

「方式(手順)

① ワンタイムパスワードを登録する為の、固定パスワードをユーザ数ランダムに発生させ、URLと共にe-mailで利用者の携帯電話端末へ通知する。

② 各利用者は、URLをアクセスし、固定パスワードを使って認証を通過する。

③ 認証後、OFFICのワンタイムパスワードを登録する画面において、自分のパスワード位置と順序を指定し、確認後、登録する。

④ ワンタイムパスワード登録完了したことを、URLと共にemailで利用者の携帯端末へ通知する。(このURLは本番用)

⑤ 本番URLへアクセスすると、OFFICの乱数列が表示され、ワンタイムパスワードを入力して、本番アプリケーションに入る。

分担

SP(引用者注:被告)殿:②~④

BTI(引用者注:ベース社):①、⑤、ユーザDB設計」

f 被告の担当者であったDは、同年12月26日頃、NTTコムに対し、被告作成名義の同月22日付けの「iモードでのOFFIC利用開始手順案」(本件手順案)をメールで送信し、同手順案はNTTコム内で回覧された。(乙7、8)

本件手順案には、「方式A」から「方式D」までの4つの方式が記載されており、「方式C」の内容は、次のとおりである。(乙7)

「1. 利用者の携帯電話にメールを送付し、パスワード設定をするためのURL(ID付き)を連絡する。

2. 利用者は、URLにアクセスし、表示されたOFFIC画面(特定のパターンで数字が並んでいるもの)から、抜き出したい位置の数字を入力する。これを2回くりかえす。

3. サーバー側では、数字の変化から、入力位置を推察し、画面に抜き出しパターンを表示する。意図するものであれば、本登録をする。」

g Aは、平成13年1月22日、Cに対し、本件手順案をメールで送信した(乙31の1及び2)。

h その後、本件プロジェクトにおいて、本件手順案等の検討が進められ、NTTコムは、ビジネスモデル特許として、発明者をBとし、甲11発明について特許出願をした(甲11、乙27、38)。

(イ)上記(ア)の認定事実によれば、本件プロジェクトには、NTTコムのプロジェクトチームメンバーの他、Cをはじめとするベース社のメンバーやAをはじめとする被告のメンバーが関与し、A以外の者(例えば、C)からも新たなパスワード登録方法に関するアイデアが出される中で、同プロジェクトの成果物として甲11発明が完成し、発明者をBとする特許出願がされたことが認められる。

そして、甲11発明のパスワードの初期登録に係る部分は、①認証サーバがウェブサーバを介してアクセス元の端末装置に初期ワンタイムパスワード情報登録URLを通知する電子メールを送信し、②端末装置のユーザは、上記URLにおいて、認証サーバからウェブサーバを介して送られたウェブページを見て、縦4個×横12個のランダムパスワードの中から選択し、選択したパスワードを入力し、③認証サーバから送られた2回目のランダムパスワードに対し、端末装置のユーザがランダムパスワードを入力し、④認証サーバが、2回の入力によりユーザにより選択されて確定されたランダムパスワードの位置情報をユーザ情報としてデータベースに登録し、⑤認証サーバが、URLを通知する電子メールをウェブサーバを介してアクセス元の端末装置に送信する、というものであると認められる(甲11発明に係る明細書の段落【0018】ないし【0021】参照)ところ、上記部分を具体的に着想、提示した主体(甲11発明のパスワードの発明者)がAのみであると認めるに足りる証拠はないから、本件発明1と甲11発明の発明者が同一であるとは認められない。

(ウ)これに対し、被告は、甲11発明の特徴的部分は「位置情報が確定されるまで、縦4個×横12個の新たなランダムパスワードを端末装置1が表示する処理を繰り返し行い、これにより、縦4個×横12個の新たなランダムパスワードについての特定の座標位置に配置されているパスワード(すなわち数字)の入力を促す処理を繰り返すこと」にあるところ、これと同一の特徴的部分を有する方式Cの記載された本件手順案をAが作成し、NTTコムに送付したことに照らせば、甲11発明の発明者はAである旨主張する。

この点、本件手順案のデータに係るプロパティには作成者として「(省略)」と記載されている(乙31の3)が、これをもって直ちにAのみが本件手順案の内容を着想したと推認することはできず、かえって、本件手順案より前にCにより作成された本件C文書にも、「③認証後、OFFICのワンタイムパスワードを登録する画面において、自分のパスワード位置と順序を指定し、確認後、登録する。④ワンタイムパスワード登録完了したことを、URLと共にe-mailで利用者の携帯端末へ通知する。(このURLは本番用)」といった記載があることによれば、本件手順案の内容の一部は、Aが本件手順案を作成するよりも前に既に本件プロジェクト内において着想されていたものと認められる。したがって、被告の上記主張を採用することはできない。

ウ 小括

以上によれば、本件発明1は特許法29条の2によって特許を受けられないから、本件特許1には無効理由が認められる。

(2)したがって、争点2-2(公然実施)について判断するまでもなく、本件特許1は無効とされるべきものである。

4.2 争点1(原告製品は本件各発明の技術的範囲に属するか)について

(1)争点1-1(本件登録システムは本件発明1の技術的範囲に属するか)について

上記1のとおり、本件特許1には無効理由が認められるから、争点1-1(本件登録システムは本件発明1の技術的範囲に属するか)については判断を要しない。

(2)争点1-2(本件登録システム方法は本件発明2の技術的範囲に属するか)について

ア 構成要件2Cの充足性について

(ア)本件明細書2の記載

a 【課題を解決するための手段】

-省略-

b 【発明を実施するための最良の形態】

-省略-

c 本発明の一実施形態に係るパスワード導出パターンの登録方法の処理の流れを説明するためのフローチャート(【図18】)は、次のとおりである。

-省略-

(イ)構成要件2Cの充足性について

本件発明2の構成要件2Bは、「サーバが、複数の要素から構成される所定のパターンの要素のそれぞれに所定のキャラクタを割り当てた提示用パターンを生成する生成ステップと、」というものであり、構成要件2Cは、「サーバが、前記生成した提示用パターンを前記ユーザに提示して、前記提示パターンについての特定の要素に割り当てられたキャラクタの入力を促す入力ステップと、」というものである。

これらの構成要件の文言を踏まえれば、上記構成要件2Cは、提示用パターンの生成主体がサーバであることを規定すると共に、サーバが自ら生成した提示用パターンをユーザに提示することを規定していると解するのが相当である。上記ア(ア)の本件明細書2の記載も上記解釈を裏付けるものである。

一方、原告による特許出願の内容(甲25)及び弁論の全趣旨によれば、本件登録システム方法の構成は、別紙「本件登録システム方法の構成(原告主張)」のとおりであると認められる(この点、被告は、上記構成が別紙「本件登録システム方法の構成(被告主張)」のとおりであると主張するが、その内容は抽象的であるし、これを認めるに足りる証拠もない。)。

そして、別紙「本件登録システム方法の構成(原告主張)」の②ないし④記載のとおり、本件登録システム方法においては、次のとおりの構成が採られている。

「②クライアント端末は、「パスワード変更用seed」を受信すると同端末にインストールされたプログラムにより、ユーザが入力するユーザIDを同「パスワード変更用seed」と組み合わせ、ユニークで、且つ当該2回分への入力結果で「ワンタイムパスワード導出ルール」が特定される「パスワード変更用マトリクス」をクライアントにおいて発生規則に従って2回分同時に(「パスワード変更用マトリクス」1回目及び2回目)発生させる。③クライアント端末は、ユーザに「パスワード変更用マトリクス」(1回目)を提示し、ユーザが登録しようとする「ワンタイムパスワード導出ルール」に基づきマトリクス表のマス目に割り当てられた数字を入力するようにユーザに促す(1回目の提示。ユーザによる1回目の入力)。④ユーザによる1回目の数字入力終了後、クライアント端末は既に発生させている「パスワード変更用マトリクス」(2回目)をユーザに提示し、「ワンタイムパスワード導出ルール」に基づきマトリクス表のマス目に割り当てられた数字の入力を促す(2回目の提示。ユーザによる2回目の入力 → これにより「ワンタイムパスワード導出ルール」が特定される。)。」

そうすると、本件登録システム方法においては、クライアント端末は、ユーザが入力するユーザIDを、受信した「パスワード変更用seed」と組み合わせて、「パスワード変更用マトリクス」(1回目及び2回目)を発生させ、これをユーザに対して提示するものである。つまり、ユーザに対して提示用パターンに相当する「パスワード変更用マトリクス」(1回目及び2回目)を提示するのは、「SMX認証サーバ」ではなく「クライアント端末」であるから、本件登録システム方法は、構成要件2Cを充足しないというべきである。

なお、被告は、サーバ自身が単体でユーザに対する提示用パターンの提示を行われければならないと解すべきではない旨主張するが、特許請求の範囲の記載や本件明細書2の記載(段落【0083】ないし【0085】)を見ても、そのような解釈を導くことはできず、他に上記主張を裏付ける根拠は見当たらないから、上記主張を採用することはできない。

イ 小括

以上によれば、その余の点について検討するまでもなく、本件登録システム方法は、本件発明2の技術的範囲に属すると認めることはできない。

(3)争点1-3(本件ユーザ認証システムプログラムは本件発明3の技術的範囲に属するか)について

ア 構成要件3Cの充足性について

(ア)構成要件3Cは、「前記ユーザの情報端末装置から送信された、利用対象システムに割り当てられたシステム識別情報を受け付ける受付手段、」というものであるところ、同構成要件の充足性については、①同構成要件における「情報端末装置」と「利用対象システム」が物理的に別個の端末であることが必要であるかという点、②本件ユーザ認証システムにおける「情報端末装置」と「利用対象システム」が物理的に別個であるかという点、③構成要件3Cの「システム識別情報」がシステム固有の情報である必要があると解すべきであるかという点において、当事者間に争いがある。

一方、構成要件3Cの「システム識別情報」が利用対象となるシステムを識別するための情報であると解されること、及び、原告ソフトウェアの本件ユーザ認証システムにおける認証サーバが、ユーザのマトリクス表取得クライアントから送信されたログインIDを受け付けるログインID情報受付部を有することについては、当事者間に争いがない。

(イ)そこで、まず、上記の当事者間に争いがない事実を前提に、本件ユーザ認証システムプログラムにおけるログインIDが、利用対象となるシステムを識別する「システム識別情報」に該当するか否かについて検討すると、本件全証拠を検討しても、本件ユーザ認証システムプログラムにおけるログインIDが利用対象システムを識別する機能を有していることを認めるに足りる証拠はないから、上記ログインIDは、構成要件3Cの「システム識別情報」に該当するとはいえない。

(ウ)この点、被告は、原告ソフトウェアの運用ガイド(乙35、36)には、①ユーザを識別するUserIDに対して、認証時に使用される最大10個のLoginIDを設定することができ、SMX認証サーバに登録されていないLoginIDを入力すると「ログインIDが登録されていません。」又はダミーマトリクス表が表示されること、②LoginID(エイリアス)を複数登録することによって「LoginID」を使い分けられ、ユーザは、利用対象システムごとにログインIDを付与することにより、複数の利用対象システムに対して異なるパスワードポリシーのマトリクス認証システムを用いられること、③ログインIDに利用対象システムを意味するレルムを付与すればログインIDのレルムによって利用対象システムを識別することができること、以上の点が記載されているから、ログインIDは利用対象システムを識別している旨主張する。

しかしながら、上記①については、上記運用ガイド(乙36)には、「ダミーマトリクス機能は、攻撃者に対し、SMXのLoginIDの登録有無を分からないようにするための機能となります。ダミーマトリクス機能を使用していない場合には、SMXに登録されていないLoginIDを入力した際、「ログインIDが登録されていません。」と表示されますが、ダミーマトリクス機能を使用することにより、SMXに登録されていないLoginIDが入力された場合でも、ダミーのマトリクス表が表示される動作となります。」との記載があり、SMX認証サーバがログインIDの登録の有無を判断した上で「ログインIDが登録されていません。」との文言又はダミーマトリクス表を表示することは記載されているが、ログインIDにより利用対象システムの有無を識別することを裏付ける記載は見当たらない。上記②については、運用ガイド(乙35)には、「LoginID(エイリアス)を複数登録することにより、場所や用途に応じてログインIDを使い分けることができます。LoginID(エイリアス)は、UserID毎に最大10個まで作成することが可能です。」との記載があるが、複数の利用対象システムに対して異なるログインIDを設定することができることを裏付ける記載は見当たらない。上記③については、運用ガイド(乙35)には、ユーザ新規登録の「設定項目一覧」の「UserID」欄に「ユーザのIDを入力します。レルム付きUserIDはシステムで一意の値である必要があります。レルム付きUserIDは『〔UserID〕〔レルムセパレータ〕〔レルム〕』で構成されます。」との記載があり、また、「LoginID」欄に「ユーザのLoginIDを入力します。LoginIDは認証時に使用されるIDです。レルム付きLoginIDはシステムで一意の値である必要があります。レルム付きLoginIDは『〔LoginID〕〔レルムセパレータ〕〔レルム〕』で構成されます。」との記載があるが、レルム付きLoginID又はレルムが利用対象システムを識別することをうかがわせる記載は見当たらない。

したがって、被告の上記主張は採用できない。

イ 小括

上記アによれば、本件ユーザ認証システムプログラムは、構成要件3Cを充足しないから、その余の点について判断するまでもなく、本件ユーザ認証システムプログラムは、本件発明3の技術的範囲に属するとは認められない。

(4)争点1-4(本件ユーザ認証システム装置は本件発明4の技術的範囲に属するか)について

本件発明4は、本件発明3が「プログラム」に関する発明であるのに対し、「ユーザ認証装置」に関する発明であり、この点において本件発明3と相違するが、その他の構成要件は実質的に同一であるところ、上記(3)と同様の理由により、本件ユーザ認証システム装置は、本件発明4の構成要件4Bを充足しないから、本件発明4の技術的範囲に属するとは認められない。

4.3 争点3(原告による間接侵害の成否)及び争点4(直接侵害の教唆・幇助行為による原告の不法行為の成否)について

上記1及び2で検討したところによれば、原告による間接侵害ないし直接侵害の教唆・幇助行為による不法行為はいずれも成立しない。

4.4 まとめ

以上のとおり、被告の反訴請求はいずれも理由がない。

 

【本訴について】

4.5 争点6(本件各書状及び本件メールの送付等は、原告の「営業上の信用を害する」ものか)について

(1)本件書状1及び本件書状2について

本件書状1及び本件書状2の記載内容は、前記第2の1(前提事実)(7)ア及びイのとおりであり、被告の開発したマトリクス型ワンタイムパスワード「PassLogic®」製品及び同製品に採用されている代表的な特許技術の紹介、被告からライセンスを受けずに販売されている特許侵害品を利用した場合にはユーザも特許侵害に問われる可能性がある旨の特許侵害に関する一般的な指摘、並びに、PassLogicの導入又は特許のライセンスに関する連絡先の案内を内容とするものである(甲6、7)。

このような上記各書状の記載内容に照らせば、上記各書状の送付先に原告のディストリビュータやユーザが含まれているとしても、上記各書状は、被告の製品に関する一般的な販促文書にすぎないと解すべきである。

したがって、上記各書状の送付は、原告の「営業上の信用を害する」ものとはいえない。

(2)本件書状3、本件書状4及び本件メールについて

本件書状3、本件書状4及び本件メールは、いずれも原告ソフトウェアのユーザであるニフティに対するものである。また、上記書状等の記載内容は、前記第2の1(前提事実)(7)ウないしオのとおり、いずれも、ニフティシステムの使用が本件特許権1を侵害する行為であって同社とのライセンス契約の締結を求めるというものである上、本件書状3には、上記侵害の事実が存在する旨の公証人作成の事実実験公正証書(甲8)が、本件書状4には同旨の弁理士作成の鑑定意見書(甲9)が添付されている。そして、ニフティシステムの使用は原告ソフトウェアの使用を意味する(弁論の全趣旨)。

上記各書状及び本件メールの送付先及びその内容に照らせば、これらの書状等に原告に関する直接的な記載が見当たらないことを考慮しても、当該書状等について、一般的な被告の製品の販促文書であると解することはできず、原告ソフトウェアの使用が本件特許権1などの特許権を侵害する旨を原告ソフトウェアのユーザに指摘する文書であると解するのが相当である。

したがって、上記各書状及び本件メールは、原告の「営業上の信用を害するもの」に該当する。

4.6 争点7(本件各書状及び本件メールの内容は「虚偽」であるか)について

上記5のとおり、本件書状3、本件書状4及び本件メールは、原告ソフトウェアの使用が本件特許権1などの特許権を侵害する旨を原告ソフトウェアのユーザに指摘する文書であると解される。そして、被告は原告ソフトウェアにおける本件登録システムが本件発明1の技術的範囲に属する旨主張しているところ、前記1のとおり、本件発明1に係る本件特許1には無効理由があると認められるから、本件書状3、本件書状4及び本件メールの内容は「虚偽の事実」の告知に当たると認められる。

4.7 争点8(被告の行為の違法性・違法性阻却事由の有無)について

被告は、複数の弁理士に特許権侵害の鑑定を依頼するなどしてニフティシステムの利用が特許権侵害であると確信した上で、ニフティに対し、ライセンス交渉を求めるために本件書状3、本件書状4及び本件メールを送付したのであり、その内容及び態様は、社会通念上必要と認められる範囲であるから、被告の行為には違法性がない、又は、正当な権利行使の一環として違法性が阻却される旨主張する。

しかしながら、証拠(甲8、9)によれば、被告が侵害鑑定依頼をした弁理士は被告の当時の代理人弁理士を含めて3名にすぎないと認められ、しかも、本件全証拠によっても、本件特許1の無効理由について調査した事実は認められないから、被告が特許権侵害の有無について十分な法的検討をした上で上記各書状等を送付したと認めることはできない。また、上記各書状等の内容は、専らニフティシステムの利用が特許権侵害に該当することを前提にライセンス契約の締結を求めるというものであり、少なくとも、本件書状4及び本件メールは、被告が、ニフティを自社製品の製造者ではなく原告ソフトウェアのユーザという第三者であることを確定的に認識した上で、同社に対して送付したものである。

このような上記各書状等の送付に至る経緯に照らせば、その内容及び態様が社会通念上必要と認められる範囲であるとも、正当な権利行使の一環であるとも認めることはできないから、被告の上記主張を採用することはできない。

4.8 争点9(被告の過失の有無)について

上記7で説示したとおり、被告が本件書状3、本件書状4及び本件メールの送付に先立って侵害鑑定依頼をした弁理士は被告の当時の代理人弁理士を含めて3名にすぎず、しかも、被告が本件特許1の無効理由について調査した事実も認められないから、被告が、特許権侵害の有無について十分な法的検討をした上で上記各書状等を送付したと認めることはできない。したがって、被告には上記各書状等の送付につき過失があったと認められる。

4.9 争点10(原告の損害額)について

-省略-

4.10 争点11(信用回復措置の必要性の有無)について

-省略-

4.11 まとめ

以上によれば、原告の本訴請求は、原告ソフトウェアの開発、製造及び販売が本件特許権1を侵害する行為である旨の告知・流布の差止め、並びに損害賠償金300万円及びこれに対する遅延損害金の支払を求める限度で理由がある。

5.検討

(1)本訴の方では気になった点は一つあります。この判決では本件発明2は提示用パターンの生成主体がサーバであるのに対して原告(実施者)の製品はクライアント端末であるので相違するという結論でした。もし、被告(特許権者)が均等侵害を主張したらどうなっていたか気になります。

(2)一方で反訴の方には気になった点がいくつかあります。まず、争点6ですが、被告が原告ソフトウェアのユーザに送った本件書状3(事実実験公正証書)、本件書状4(弁理士作成の鑑定書)及び本件メールが原告の「営業上の信用を害するもの」に該当する、と判断された点です。これらは全文を入手していないので詳細がわかりませんが、少なくとも各書状は一般的に他社に警告する場合に用意するものであると考えられます(むしろ鑑定書等が添付されていない方が多い?)。たとえ購入したソフトウェアを製品に組み込んで販売するユーザであっても侵害者の立場には変わりありません。その相手に送った書状等がそもそものソフトウェアを作成したメーカの営業上の信用を害するとされてしまうと、本件のように購入品を組み込んで自社製品を製造販売している相手に対して特許権者は直接警告できず、ソフトウェアメーカ(広く言えば部品製造メーカ)に警告するしか手がないことになると思います。

なお、争点8では「少なくとも、本件書状4及び本件メールは、被告が、ニフティを自社製品の製造者ではなく原告ソフトウェアのユーザという第三者であることを確定的に認識した上で、同社に対して送付したものである」と書いてありますが、争点6にはそのような記載がありません。したがって、争点6は特許権者が侵害品について購入品であることを知らない場合でも対象となりうる可能性があります。

(3)次に争点8、9ですが、判決では侵害鑑定依頼した弁理士の人数が3人では不十分であると述べています。裁判所はいったい何人に鑑定遺体すれば十分と考えているのでしょうか?不十分と判断する根拠が何も示されず、十分と判断する人数も示されないのでは困ってしまします。

(4)また、判決では無効理由についての調査も不十分である、と述べています。無審査制度の実用新案の場合は、権利行使する際に実用新案技術評価書を提示したうえで警告しなければならない、と定められています(実29条の2)。一方、審査制度を採用している特許法にはそのような規定はありません。それにもかかわらず、無効理由調査を求める理由は何なのでしょうか?

もちろん、実際には特許権者は権利行使する前に無効理由調査することがよくあります。しかし、これは事前に無効理由をある程度調べておかないと、特許係争(当事者間の交渉や訴訟)に費やす金額や労力が無駄になる可能性が高いから、というのが主な理由だと思います。