Embedded Files
投稿日: 2017/09/18 20:35:07
今日は、平成２７年（ワ）第３６９８１号 虚偽事実の告知・流布差止等本訴請求事件及び平成２８年（ワ）第１７５２７号 特許権侵害差止等反訴請求事件について検討します。平成２７年（ワ）第３６９８１号は実質的には債務不存在確認訴訟と同じような内容だと思います。原告である株式会社シー・エス・イーは、判決文によると、各種情報処理に関するシステム分析，開発及びプログラミング等を目的とする株式会社だそうです。一方、被告であるパスロジ株式会社はコンピュータに関するハードウェア・ソフトウェアの開発，製造，販売，リースならびに保守サービス等を目的とする株式会社だそうです。J-PlatPatで検索したところ、株式会社シー・エス・イーは１０件、パスロジ株式会社は１４件の特許を取得しています。
１．手続の時系列の整理
① 本事件は特許３件ですが２件は本件特許権３から分割したものです。
② 本件特許権２、３は非常に多くの閲覧を請求されています。ワンタイムパスワードに関する特許なので注目が高いのは理解できますが、J-PlatPatの審査書類情報照会でほとんどの審査過程の書類がダウンロードでき、またWIPOホームページで国際公開公報もダウンロードできるのに何故これほど閲覧請求が多いのか謎です。
２．本件発明の内容
２．１ 本件発明１（特許第4455666号 請求項８）
１Ａ：端末装置（１３）と、前記端末装置（１３）と通信回線を介して接続されたサーバ（１２）とを含む、ユーザ認証に用いられるパスワードを導出するためのパスワード導出パターンの登録システムであって、
１Ｂ 前記端末装置（１３）は、
１Ｂ－１：複数の要素から構成される所定のパターンの要素のそれぞれに所定のキャラクタを割り当てた提示用パターンを表示し、これにより、前記提示用パターンについての特定の要素に割り当てられたキャラクタの入力を促すための手段と、
１Ｂ－２：前記入力されたキャラクタに基づいてパスワード導出パターンが特定されるまで、新たな提示用パターンを表示する処理を繰り返し、
１Ｂ－３：これにより、前記新たな提示用パターンについての特定の要素に割り当てられたキャラクタの入力を促す処理を繰り返す手段と、を有し、
１Ｃ：前記端末装置（１３）と通信回線を介して接続されたサーバは、前記特定されたパスワード導出パターンを登録させるための手段を備える、
１Ｄ：パスワード導出パターンの登録システム。
２．２ 本件発明２（特許第4275080号 請求項１）
２Ａ：ユーザ認証に用いられるパスワードを導出するためのパスワード導出パターンの登録方法であって、
２Ｂ：サーバが、複数の要素から構成される所定のパターンの要素のそれぞれに所定のキャラクタを割り当てた提示用パターンを生成する生成ステップと、
２Ｃ：サーバが、前記生成した提示用パターンを前記ユーザに提示して、前記提示パターンについての特定の要素に割り当てられたキャラクタの入力を促す入力ステップと、
２Ｄ：サーバが、前記入力されたキャラクタに基づいてパスワード導出パターンが特定されるまで、前記生成ステップおよび前記入力ステップを繰り返す特定ステップと、
２Ｅ：サーバが、前記特定したパスワード導出パターンを登録する登録ステップと、
２Ｆ：を備えることを特徴とするパスワード導出パターンの登録方法。
２．３ 本件発明３（特許第3809441号 請求項２６）
３Ａ：コンピュータを、
３Ｂ：所定のパターンを構成する要素群の中から選択された特定の要素に基づくパスワード導出パターンを、ユーザに対応づけて登録する登録手段、
３Ｃ：前記ユーザの情報端末装置から送信された、利用対象システムに割り当てられたシステム識別情報を受け付ける受付手段、
３Ｄ：前記情報端末装置から前記システム識別情報を受け付けた場合に、前記所定のパターンを構成する要素群のそれぞれに所定のキャラクタを割り当てた提示用パターンを生成する生成手段、
３Ｅ：前記情報端末装置に、前記生成した提示用パターンを送信する送信手段、
３Ｆ：前記利用対象システムからキャラクタを受け付け、前記提示用パターンと前記ユーザのパスワード導出パターンとに基づいて、前記受け付けたキャラクタが正当であるか否かを判断する第１の判断手段、
３Ｇ：前記情報端末装置から受け付けたシステム識別情報に基づいて、前記キャラクタを受け付けた前記利用対象システムが正当であるか否かを判断する第２の判断手段、
３Ｈ：前記第１の判断手段が判断した結果を前記利用対象システムに通知する通知手段、
３Ｉ：として機能させるためのプログラム。
２．４ 本件発明４（特許第3809441号 請求項２５）
４Ａ：所定のパターンを構成する要素群の中から選択された特定の要素に基づくパスワード導出パターンを、ユーザに対応づけて登録する登録手段と、
４Ｂ：前記ユーザの情報端末装置から送信された、利用対象システムに割り当てられたシステム識別情報を受け付ける受付手段と、
４Ｃ：前記情報端末装置から前記システム識別情報を受け付けた場合に、前記所定のパターンを構成する要素群のそれぞれに所定のキャラクタを割り当てた提示用パターンを生成する生成手段と、
４Ｄ：前記情報端末装置に、前記生成した提示用パターンを送信する送信手段と、
４Ｅ：前記利用対象システムからキャラクタを受け付け、前記提示用パターンと前記ユーザのパスワード導出パターンとに基づいて、前記受け付けたキャラクタが正当であるか否かを判断する第１の判断手段と、
４Ｆ：前記情報端末装置から受け付けたシステム識別情報に基づいて、前記キャラクタを受け付けた前記利用対象システムが正当であるか否かを判断する第２の判断手段と、
４Ｇ：前記第１の判断手段が判断した結果を前記利用対象システムに通知する通知手段と、
４Ｈ：を備えることを特徴とするユーザ認証装置。
３．争点
【反訴について】
（１）原告製品は本件各発明の技術的範囲に属するか（争点１）
ア 本件登録システムは本件発明１の技術的範囲に属するか（争点１－１）
具体的には，構成要件１Ｂ－２，１Ｂ－３，１Ｃの充足性
イ 本件登録システム方法は本件発明２の技術的範囲に属するか（争点１－２）
具体的には，構成要件２Ｂ，２Ｃ，２Ｄ，２Ｆの充足性
ウ 本件ユーザ認証システムプログラムは本件発明３の技術的範囲に属するか（争点１－３）
具体的には，構成要件３Ｃ，３Ｄ，３Ｅ，３Ｇ，３Ｉの充足性
エ 本件ユーザ認証システム装置は本件発明４の技術的範囲に属するか（争点１－４）
具体的には，構成要件４Ｂ，４Ｃ，４Ｄ，４Ｆ及び４Ｈの充足性
（２）本件特許１の無効理由の有無（争点２）
ア 特許法２９条の２違反（争点２－１）
イ 公然実施（争点２－２）
（３）原告による間接侵害の成否（争点３）
（４）直接侵害の教唆・幇助行為による原告の不法行為の成否（争点４）
（５）被告の損害額（争点５）
【本訴について】
（６）本件各書状及び本件メールの送付等は，原告の「営業上の信用を害する」ものか（争点６）
（７）本件各書状及び本件メールの内容は「虚偽」であるか（争点７）
（８）被告の行為の違法性・違法性阻却事由の有無（争点８）
（９）被告の過失の有無（争点９）
（１０）原告の損害額（争点１０）
（１１）信用回復措置の必要性の有無（争点１１）
４．裁判所の判断
【反訴について】
４．１ 争点２（本件特許１の無効理由の有無）について
事案に鑑み，争点２から判断する。
（１）争点２－１（特許法２９条の２違反）について
ア 本件発明１と甲１１発明（特開2002-366517公報）の同一性について
（ア）被告は、当初、本件発明１と甲１１発明が同一であることを認めていたが、後に、自白を撤回し、甲１１発明に係る明細書の記載（【図４】）によれば、明細書記載の２回の入力（段落【００１８】ないし【００２１】）によってランダムパスワードの位置は確定されないから、甲１１発明は、本件発明１の有する「パスワード導出パターンが特定されるまで、新たな提示用パターンを表示する処理を繰り返し」との構成を少なくとも有しない旨主張するに至った。
そこで、以下、甲１１発明が「パスワード導出パターンが特定されるまで、新たな提示用パターンを表示する処理を繰り返し」との構成を有するか否かについて検討する。
（イ）甲１１発明に係る明細書には、以下の記載がある。
「以下、ワンタイムパスワード発行の手順について説明する。最初に、端末装置１から前記ユーザ情報をデータベース４５に登録する初期登録時点において、認証サーバ４２は、ウエブサーバ４３を介してアクセス元の端末装置１に初期ワンタイムパスワード情報登録ＵＲＬを通知する電子メールを送信する。」（段落【００１８】）
「端末装置１のユーザは、初期ワンタイムパスワード情報登録ＵＲＬにおいて、認証サーバ４２からウエブサーバ４３を介して送られた図３のようなウエブページを見て、縦４個×横１２個のランダムパスワードの中から例えば４つを選択し、選択したパスワードを図３の「パスワード」と表示された箇所に入力する。縦４個×横１２個の各ランダムパスワードには、図４（ａ）に示すように、（Ａ、１）から（Ｄ、１２）までの座標が付与されている。」（段落【００１９】）
「端末装置１のユーザは、例えば座標（Ａ、３）、（Ｂ、７）、（Ｃ、４）、（Ｄ、９）を位置登録したい場合、これらの各座標位置に配置されているランダムパスワード、すなわち「６」、「３」、「４」、「１」を入力する。次に、認証サーバ４２からは図４（ｂ）に示すような２回目のランダムパスワードが送られる。端末装置１のユーザは、図４（ｂ）のランダムパスワードの配置を見て、前述の座標位置（Ａ、３）、（Ｂ、７）、（Ｃ、４）、（Ｄ、９）に配置されているランダムパスワード、すなわち「３」、「２」、「０」、「２」を入力する。認証サーバ４２は、２回の入力により、ユーザによって選択されたランダムパスワードの位置（Ａ、３）、（Ｂ、７）、（Ｃ、４）、（Ｄ、９）を確定し、確定した位置情報を前記ユーザ情報としてデータベース４５に登録する。」（段落【００２０】）
「最後に、認証サーバ４２は、アクセス元の端末装置１のユーザ毎及びアクセス先のサービス提供者装置３－１～３－３毎に異なる前記第１のＵＲＬを通知する電子メールを、ウエブサーバ４３を介してアクセス元の端末装置１に送信する。以上で、初期登録が終了する。」（段落【００２１】）
（ウ）上記（イ）の明細書の記載によれば、甲１１発明においては、認証サーバから２回のランダムパスワードが送られ、端末装置のユーザによる２回の入力によってユーザにより選択されたランダムパスワードの位置が確定し、確定した位置情報の登録を経てワンタイムパスワードの発行に係る初期登録が行われるものと解される。そして、上記明細書の記載において引用された【図４】は、認証サーバから送られるランダムパスワードについて、各座標位置に数字がランダム配置されていることを示す一例にすぎないというべきであるから、仮に、【図４】を前提に、２回の入力によって特定される座標が複数存在し得る結果になるとしても、直ちに上記初期登録の手順が否定されることにならないと解すべきである。
そうすると、甲１１発明は、ワンタイムパスワードの導出パターンの座標が特定されるために、２回にわたりパターン（ランダムパスワード）を表示する処理が行われているといえるから、甲１発明の有する「パスワード導出パターンが特定されるまで、新たな提示用パターンを表示する処理を繰り返し」との構成を有すると認められる。そして、他の構成においても、甲１発明と甲１１発明に異なる点はないから、両発明は同一であると認められる。
イ 本件発明１と甲１１発明の発明者の同一性について
（ア）後掲各証拠及び弁論の全趣旨によれば、以下の事実が認められる。
ａ Ａは、平成９年頃、ブラウザ画面上に表示されたマトリクス状の文字や数字から、あらかじめ登録した位置と順番で文字や数字を抜き出し、ワンタイムパスワードとして入力するシステム（パスロジック方式）を開発した。（乙１３、３７）
ｂ Ａが代表取締役を務めていたメディア社は、同年７月２８日、パスロジック方式を採用したパスワード認証システム「ＯＦＦＩＣ」の販売を開始し、その後、ＯＦＦＩＣ関連の事業はメディア社から被告に承継された。（乙１３、３７）
ｃ ＮＴＴコムによるモバイルコネクトサービスの開発に係るプロジェクト（本件プロジェクト）は、平成１１年頃に立ち上がり、同社従業員のＢが同プロジェクトチーム約２０名のトップの立場を務めた。（乙２７、２８）
ｄ ＮＴＴコムは、モバイルコネクトサービスのユーザ認証システムにＯＦＦＩＣを利用することを考え、同サービスの開発を分担していたベース社に開発を委託し、ベース社が被告に再委託し、開発が進められた。（乙２７、２８、３８）
本件プロジェクトの開発会議には、ＮＴＴ社のプロジェクトチームメンバーのほか、Ｃ（ベース社の代表取締役）やＡ（被告の代表取締役）も参加しており、Ｃが開発会議において、モバイルコネクトサービスに関するアイデアを提示することもあった。なお、ＮＴＴコムとベース社との契約により、モバイルコネクトサービスの開発に関するベース社のアイデアは、すべてＮＴＴコムに帰属することとなっていた。（乙２７、２８）
ｅ Ｃは、被告からＯＦＦＩＣのＰｅｒｌ言語のロジックの開示を受け、平成１２年１１月２２日付けで「モバイルプラットフォームプロジェクト ワンタイムパスワード：ＯＦＦＩＣ連携について」と題する文書（以下「本件Ｃ文書」という。）を作成した。同文書には、「２．初回の登録方式」として、以下の内容が記載されている。（乙５）
「方式（手順）
① ワンタイムパスワードを登録する為の、固定パスワードをユーザ数ランダムに発生させ、ＵＲＬと共にｅ－ｍａｉｌで利用者の携帯電話端末へ通知する。
② 各利用者は、ＵＲＬをアクセスし、固定パスワードを使って認証を通過する。
③ 認証後、ＯＦＦＩＣのワンタイムパスワードを登録する画面において、自分のパスワード位置と順序を指定し、確認後、登録する。
④ ワンタイムパスワード登録完了したことを、ＵＲＬと共にｅｍａｉｌで利用者の携帯端末へ通知する。（このＵＲＬは本番用）
⑤ 本番ＵＲＬへアクセスすると、ＯＦＦＩＣの乱数列が表示され、ワンタイムパスワードを入力して、本番アプリケーションに入る。
分担
ＳＰ（引用者注：被告）殿：②～④
ＢＴＩ（引用者注：ベース社）：①、⑤、ユーザＤＢ設計」
ｆ 被告の担当者であったＤは、同年１２月２６日頃、ＮＴＴコムに対し、被告作成名義の同月２２日付けの「ｉモードでのＯＦＦＩＣ利用開始手順案」（本件手順案）をメールで送信し、同手順案はＮＴＴコム内で回覧された。（乙７、８）
本件手順案には、「方式Ａ」から「方式Ｄ」までの４つの方式が記載されており、「方式Ｃ」の内容は、次のとおりである。（乙７）
「１． 利用者の携帯電話にメールを送付し、パスワード設定をするためのＵＲＬ（ＩＤ付き）を連絡する。
２． 利用者は、ＵＲＬにアクセスし、表示されたＯＦＦＩＣ画面（特定のパターンで数字が並んでいるもの）から、抜き出したい位置の数字を入力する。これを２回くりかえす。
３． サーバー側では、数字の変化から、入力位置を推察し、画面に抜き出しパターンを表示する。意図するものであれば、本登録をする。」
ｇ Ａは、平成１３年１月２２日、Ｃに対し、本件手順案をメールで送信した（乙３１の１及び２）。
ｈ その後、本件プロジェクトにおいて、本件手順案等の検討が進められ、ＮＴＴコムは、ビジネスモデル特許として、発明者をＢとし、甲１１発明について特許出願をした（甲１１、乙２７、３８）。
（イ）上記（ア）の認定事実によれば、本件プロジェクトには、ＮＴＴコムのプロジェクトチームメンバーの他、Ｃをはじめとするベース社のメンバーやＡをはじめとする被告のメンバーが関与し、Ａ以外の者（例えば、Ｃ）からも新たなパスワード登録方法に関するアイデアが出される中で、同プロジェクトの成果物として甲１１発明が完成し、発明者をＢとする特許出願がされたことが認められる。
そして、甲１１発明のパスワードの初期登録に係る部分は、①認証サーバがウェブサーバを介してアクセス元の端末装置に初期ワンタイムパスワード情報登録ＵＲＬを通知する電子メールを送信し、②端末装置のユーザは、上記ＵＲＬにおいて、認証サーバからウェブサーバを介して送られたウェブページを見て、縦４個×横１２個のランダムパスワードの中から選択し、選択したパスワードを入力し、③認証サーバから送られた２回目のランダムパスワードに対し、端末装置のユーザがランダムパスワードを入力し、④認証サーバが、２回の入力によりユーザにより選択されて確定されたランダムパスワードの位置情報をユーザ情報としてデータベースに登録し、⑤認証サーバが、ＵＲＬを通知する電子メールをウェブサーバを介してアクセス元の端末装置に送信する、というものであると認められる（甲１１発明に係る明細書の段落【００１８】ないし【００２１】参照）ところ、上記部分を具体的に着想、提示した主体（甲１１発明のパスワードの発明者）がＡのみであると認めるに足りる証拠はないから、本件発明１と甲１１発明の発明者が同一であるとは認められない。
（ウ）これに対し、被告は、甲１１発明の特徴的部分は「位置情報が確定されるまで、縦４個×横１２個の新たなランダムパスワードを端末装置１が表示する処理を繰り返し行い、これにより、縦４個×横１２個の新たなランダムパスワードについての特定の座標位置に配置されているパスワード（すなわち数字）の入力を促す処理を繰り返すこと」にあるところ、これと同一の特徴的部分を有する方式Ｃの記載された本件手順案をＡが作成し、ＮＴＴコムに送付したことに照らせば、甲１１発明の発明者はＡである旨主張する。
この点、本件手順案のデータに係るプロパティには作成者として「（省略）」と記載されている（乙３１の３）が、これをもって直ちにＡのみが本件手順案の内容を着想したと推認することはできず、かえって、本件手順案より前にＣにより作成された本件Ｃ文書にも、「③認証後、ＯＦＦＩＣのワンタイムパスワードを登録する画面において、自分のパスワード位置と順序を指定し、確認後、登録する。④ワンタイムパスワード登録完了したことを、ＵＲＬと共にｅ－ｍａｉｌで利用者の携帯端末へ通知する。（このＵＲＬは本番用）」といった記載があることによれば、本件手順案の内容の一部は、Ａが本件手順案を作成するよりも前に既に本件プロジェクト内において着想されていたものと認められる。したがって、被告の上記主張を採用することはできない。
ウ 小括
以上によれば、本件発明１は特許法２９条の２によって特許を受けられないから、本件特許１には無効理由が認められる。
（２）したがって、争点２－２（公然実施）について判断するまでもなく、本件特許１は無効とされるべきものである。
４．２ 争点１（原告製品は本件各発明の技術的範囲に属するか）について
（１）争点１－１（本件登録システムは本件発明１の技術的範囲に属するか）について
上記１のとおり、本件特許１には無効理由が認められるから、争点１－１（本件登録システムは本件発明１の技術的範囲に属するか）については判断を要しない。
（２）争点１－２（本件登録システム方法は本件発明２の技術的範囲に属するか）について
ア 構成要件２Ｃの充足性について
（ア）本件明細書２の記載
ａ 【課題を解決するための手段】
－省略－
ｂ 【発明を実施するための最良の形態】
－省略－
ｃ 本発明の一実施形態に係るパスワード導出パターンの登録方法の処理の流れを説明するためのフローチャート（【図１８】）は、次のとおりである。
－省略－
（イ）構成要件２Ｃの充足性について
本件発明２の構成要件２Ｂは、「サーバが、複数の要素から構成される所定のパターンの要素のそれぞれに所定のキャラクタを割り当てた提示用パターンを生成する生成ステップと、」というものであり、構成要件２Ｃは、「サーバが、前記生成した提示用パターンを前記ユーザに提示して、前記提示パターンについての特定の要素に割り当てられたキャラクタの入力を促す入力ステップと、」というものである。
これらの構成要件の文言を踏まえれば、上記構成要件２Ｃは、提示用パターンの生成主体がサーバであることを規定すると共に、サーバが自ら生成した提示用パターンをユーザに提示することを規定していると解するのが相当である。上記ア（ア）の本件明細書２の記載も上記解釈を裏付けるものである。
一方、原告による特許出願の内容（甲２５）及び弁論の全趣旨によれば、本件登録システム方法の構成は、別紙「本件登録システム方法の構成（原告主張）」のとおりであると認められる（この点、被告は、上記構成が別紙「本件登録システム方法の構成（被告主張）」のとおりであると主張するが、その内容は抽象的であるし、これを認めるに足りる証拠もない。）。
そして、別紙「本件登録システム方法の構成（原告主張）」の②ないし④記載のとおり、本件登録システム方法においては、次のとおりの構成が採られている。
「②クライアント端末は、「パスワード変更用ｓｅｅｄ」を受信すると同端末にインストールされたプログラムにより、ユーザが入力するユーザＩＤを同「パスワード変更用ｓｅｅｄ」と組み合わせ、ユニークで、且つ当該２回分への入力結果で「ワンタイムパスワード導出ルール」が特定される「パスワード変更用マトリクス」をクライアントにおいて発生規則に従って２回分同時に（「パスワード変更用マトリクス」１回目及び２回目）発生させる。③クライアント端末は、ユーザに「パスワード変更用マトリクス」（１回目）を提示し、ユーザが登録しようとする「ワンタイムパスワード導出ルール」に基づきマトリクス表のマス目に割り当てられた数字を入力するようにユーザに促す（１回目の提示。ユーザによる１回目の入力）。④ユーザによる１回目の数字入力終了後、クライアント端末は既に発生させている「パスワード変更用マトリクス」（２回目）をユーザに提示し、「ワンタイムパスワード導出ルール」に基づきマトリクス表のマス目に割り当てられた数字の入力を促す（２回目の提示。ユーザによる２回目の入力 → これにより「ワンタイムパスワード導出ルール」が特定される。）。」
そうすると、本件登録システム方法においては、クライアント端末は、ユーザが入力するユーザＩＤを、受信した「パスワード変更用ｓｅｅｄ」と組み合わせて、「パスワード変更用マトリクス」（１回目及び２回目）を発生させ、これをユーザに対して提示するものである。つまり、ユーザに対して提示用パターンに相当する「パスワード変更用マトリクス」（１回目及び２回目）を提示するのは、「ＳＭＸ認証サーバ」ではなく「クライアント端末」であるから、本件登録システム方法は、構成要件２Ｃを充足しないというべきである。
なお、被告は、サーバ自身が単体でユーザに対する提示用パターンの提示を行われければならないと解すべきではない旨主張するが、特許請求の範囲の記載や本件明細書２の記載（段落【００８３】ないし【００８５】）を見ても、そのような解釈を導くことはできず、他に上記主張を裏付ける根拠は見当たらないから、上記主張を採用することはできない。
イ 小括
以上によれば、その余の点について検討するまでもなく、本件登録システム方法は、本件発明２の技術的範囲に属すると認めることはできない。
（３）争点１－３（本件ユーザ認証システムプログラムは本件発明３の技術的範囲に属するか）について
ア 構成要件３Ｃの充足性について
（ア）構成要件３Ｃは、「前記ユーザの情報端末装置から送信された、利用対象システムに割り当てられたシステム識別情報を受け付ける受付手段、」というものであるところ、同構成要件の充足性については、①同構成要件における「情報端末装置」と「利用対象システム」が物理的に別個の端末であることが必要であるかという点、②本件ユーザ認証システムにおける「情報端末装置」と「利用対象システム」が物理的に別個であるかという点、③構成要件３Ｃの「システム識別情報」がシステム固有の情報である必要があると解すべきであるかという点において、当事者間に争いがある。
一方、構成要件３Ｃの「システム識別情報」が利用対象となるシステムを識別するための情報であると解されること、及び、原告ソフトウェアの本件ユーザ認証システムにおける認証サーバが、ユーザのマトリクス表取得クライアントから送信されたログインＩＤを受け付けるログインＩＤ情報受付部を有することについては、当事者間に争いがない。
（イ）そこで、まず、上記の当事者間に争いがない事実を前提に、本件ユーザ認証システムプログラムにおけるログインＩＤが、利用対象となるシステムを識別する「システム識別情報」に該当するか否かについて検討すると、本件全証拠を検討しても、本件ユーザ認証システムプログラムにおけるログインＩＤが利用対象システムを識別する機能を有していることを認めるに足りる証拠はないから、上記ログインＩＤは、構成要件３Ｃの「システム識別情報」に該当するとはいえない。
（ウ）この点、被告は、原告ソフトウェアの運用ガイド（乙３５、３６）には、①ユーザを識別するＵｓｅｒＩＤに対して、認証時に使用される最大１０個のＬｏｇｉｎＩＤを設定することができ、ＳＭＸ認証サーバに登録されていないＬｏｇｉｎＩＤを入力すると「ログインＩＤが登録されていません。」又はダミーマトリクス表が表示されること、②ＬｏｇｉｎＩＤ（エイリアス）を複数登録することによって「ＬｏｇｉｎＩＤ」を使い分けられ、ユーザは、利用対象システムごとにログインＩＤを付与することにより、複数の利用対象システムに対して異なるパスワードポリシーのマトリクス認証システムを用いられること、③ログインＩＤに利用対象システムを意味するレルムを付与すればログインＩＤのレルムによって利用対象システムを識別することができること、以上の点が記載されているから、ログインＩＤは利用対象システムを識別している旨主張する。
しかしながら、上記①については、上記運用ガイド（乙３６）には、「ダミーマトリクス機能は、攻撃者に対し、ＳＭＸのＬｏｇｉｎＩＤの登録有無を分からないようにするための機能となります。ダミーマトリクス機能を使用していない場合には、ＳＭＸに登録されていないＬｏｇｉｎＩＤを入力した際、「ログインＩＤが登録されていません。」と表示されますが、ダミーマトリクス機能を使用することにより、ＳＭＸに登録されていないＬｏｇｉｎＩＤが入力された場合でも、ダミーのマトリクス表が表示される動作となります。」との記載があり、ＳＭＸ認証サーバがログインＩＤの登録の有無を判断した上で「ログインＩＤが登録されていません。」との文言又はダミーマトリクス表を表示することは記載されているが、ログインＩＤにより利用対象システムの有無を識別することを裏付ける記載は見当たらない。上記②については、運用ガイド（乙３５）には、「ＬｏｇｉｎＩＤ（エイリアス）を複数登録することにより、場所や用途に応じてログインＩＤを使い分けることができます。ＬｏｇｉｎＩＤ（エイリアス）は、ＵｓｅｒＩＤ毎に最大１０個まで作成することが可能です。」との記載があるが、複数の利用対象システムに対して異なるログインＩＤを設定することができることを裏付ける記載は見当たらない。上記③については、運用ガイド（乙３５）には、ユーザ新規登録の「設定項目一覧」の「ＵｓｅｒＩＤ」欄に「ユーザのＩＤを入力します。レルム付きＵｓｅｒＩＤはシステムで一意の値である必要があります。レルム付きＵｓｅｒＩＤは『〔ＵｓｅｒＩＤ〕〔レルムセパレータ〕〔レルム〕』で構成されます。」との記載があり、また、「ＬｏｇｉｎＩＤ」欄に「ユーザのＬｏｇｉｎＩＤを入力します。ＬｏｇｉｎＩＤは認証時に使用されるＩＤです。レルム付きＬｏｇｉｎＩＤはシステムで一意の値である必要があります。レルム付きＬｏｇｉｎＩＤは『〔ＬｏｇｉｎＩＤ〕〔レルムセパレータ〕〔レルム〕』で構成されます。」との記載があるが、レルム付きＬｏｇｉｎＩＤ又はレルムが利用対象システムを識別することをうかがわせる記載は見当たらない。
したがって、被告の上記主張は採用できない。
イ 小括
上記アによれば、本件ユーザ認証システムプログラムは、構成要件３Ｃを充足しないから、その余の点について判断するまでもなく、本件ユーザ認証システムプログラムは、本件発明３の技術的範囲に属するとは認められない。
（４）争点１－４（本件ユーザ認証システム装置は本件発明４の技術的範囲に属するか）について
本件発明４は、本件発明３が「プログラム」に関する発明であるのに対し、「ユーザ認証装置」に関する発明であり、この点において本件発明３と相違するが、その他の構成要件は実質的に同一であるところ、上記（３）と同様の理由により、本件ユーザ認証システム装置は、本件発明４の構成要件４Ｂを充足しないから、本件発明４の技術的範囲に属するとは認められない。
４．３ 争点３（原告による間接侵害の成否）及び争点４（直接侵害の教唆・幇助行為による原告の不法行為の成否）について
上記１及び２で検討したところによれば、原告による間接侵害ないし直接侵害の教唆・幇助行為による不法行為はいずれも成立しない。
４．４ まとめ
以上のとおり、被告の反訴請求はいずれも理由がない。
【本訴について】
４．５ 争点６（本件各書状及び本件メールの送付等は、原告の「営業上の信用を害する」ものか）について
（１）本件書状１及び本件書状２について
本件書状１及び本件書状２の記載内容は、前記第２の１（前提事実）（７）ア及びイのとおりであり、被告の開発したマトリクス型ワンタイムパスワード「ＰａｓｓＬｏｇｉｃ®」製品及び同製品に採用されている代表的な特許技術の紹介、被告からライセンスを受けずに販売されている特許侵害品を利用した場合にはユーザも特許侵害に問われる可能性がある旨の特許侵害に関する一般的な指摘、並びに、ＰａｓｓＬｏｇｉｃの導入又は特許のライセンスに関する連絡先の案内を内容とするものである（甲６、７）。
このような上記各書状の記載内容に照らせば、上記各書状の送付先に原告のディストリビュータやユーザが含まれているとしても、上記各書状は、被告の製品に関する一般的な販促文書にすぎないと解すべきである。
したがって、上記各書状の送付は、原告の「営業上の信用を害する」ものとはいえない。
（２）本件書状３、本件書状４及び本件メールについて
本件書状３、本件書状４及び本件メールは、いずれも原告ソフトウェアのユーザであるニフティに対するものである。また、上記書状等の記載内容は、前記第２の１（前提事実）（７）ウないしオのとおり、いずれも、ニフティシステムの使用が本件特許権１を侵害する行為であって同社とのライセンス契約の締結を求めるというものである上、本件書状３には、上記侵害の事実が存在する旨の公証人作成の事実実験公正証書（甲８）が、本件書状４には同旨の弁理士作成の鑑定意見書（甲９）が添付されている。そして、ニフティシステムの使用は原告ソフトウェアの使用を意味する（弁論の全趣旨）。
上記各書状及び本件メールの送付先及びその内容に照らせば、これらの書状等に原告に関する直接的な記載が見当たらないことを考慮しても、当該書状等について、一般的な被告の製品の販促文書であると解することはできず、原告ソフトウェアの使用が本件特許権１などの特許権を侵害する旨を原告ソフトウェアのユーザに指摘する文書であると解するのが相当である。
したがって、上記各書状及び本件メールは、原告の「営業上の信用を害するもの」に該当する。
４．６ 争点７（本件各書状及び本件メールの内容は「虚偽」であるか）について
上記５のとおり、本件書状３、本件書状４及び本件メールは、原告ソフトウェアの使用が本件特許権１などの特許権を侵害する旨を原告ソフトウェアのユーザに指摘する文書であると解される。そして、被告は原告ソフトウェアにおける本件登録システムが本件発明１の技術的範囲に属する旨主張しているところ、前記１のとおり、本件発明１に係る本件特許１には無効理由があると認められるから、本件書状３、本件書状４及び本件メールの内容は「虚偽の事実」の告知に当たると認められる。
４．７ 争点８（被告の行為の違法性・違法性阻却事由の有無）について
被告は、複数の弁理士に特許権侵害の鑑定を依頼するなどしてニフティシステムの利用が特許権侵害であると確信した上で、ニフティに対し、ライセンス交渉を求めるために本件書状３、本件書状４及び本件メールを送付したのであり、その内容及び態様は、社会通念上必要と認められる範囲であるから、被告の行為には違法性がない、又は、正当な権利行使の一環として違法性が阻却される旨主張する。
しかしながら、証拠（甲８、９）によれば、被告が侵害鑑定依頼をした弁理士は被告の当時の代理人弁理士を含めて３名にすぎないと認められ、しかも、本件全証拠によっても、本件特許１の無効理由について調査した事実は認められないから、被告が特許権侵害の有無について十分な法的検討をした上で上記各書状等を送付したと認めることはできない。また、上記各書状等の内容は、専らニフティシステムの利用が特許権侵害に該当することを前提にライセンス契約の締結を求めるというものであり、少なくとも、本件書状４及び本件メールは、被告が、ニフティを自社製品の製造者ではなく原告ソフトウェアのユーザという第三者であることを確定的に認識した上で、同社に対して送付したものである。
このような上記各書状等の送付に至る経緯に照らせば、その内容及び態様が社会通念上必要と認められる範囲であるとも、正当な権利行使の一環であるとも認めることはできないから、被告の上記主張を採用することはできない。
４．８ 争点９（被告の過失の有無）について
上記７で説示したとおり、被告が本件書状３、本件書状４及び本件メールの送付に先立って侵害鑑定依頼をした弁理士は被告の当時の代理人弁理士を含めて３名にすぎず、しかも、被告が本件特許１の無効理由について調査した事実も認められないから、被告が、特許権侵害の有無について十分な法的検討をした上で上記各書状等を送付したと認めることはできない。したがって、被告には上記各書状等の送付につき過失があったと認められる。
４．９ 争点１０（原告の損害額）について
－省略－
４．１０ 争点１１（信用回復措置の必要性の有無）について
－省略－
４．１１ まとめ
以上によれば、原告の本訴請求は、原告ソフトウェアの開発、製造及び販売が本件特許権１を侵害する行為である旨の告知・流布の差止め、並びに損害賠償金３００万円及びこれに対する遅延損害金の支払を求める限度で理由がある。
５．検討
（１）本訴の方では気になった点は一つあります。この判決では本件発明２は提示用パターンの生成主体がサーバであるのに対して原告（実施者）の製品はクライアント端末であるので相違するという結論でした。もし、被告（特許権者）が均等侵害を主張したらどうなっていたか気になります。
（２）一方で反訴の方には気になった点がいくつかあります。まず、争点６ですが、被告が原告ソフトウェアのユーザに送った本件書状３（事実実験公正証書）、本件書状４（弁理士作成の鑑定書）及び本件メールが原告の「営業上の信用を害するもの」に該当する、と判断された点です。これらは全文を入手していないので詳細がわかりませんが、少なくとも各書状は一般的に他社に警告する場合に用意するものであると考えられます（むしろ鑑定書等が添付されていない方が多い？）。たとえ購入したソフトウェアを製品に組み込んで販売するユーザであっても侵害者の立場には変わりありません。その相手に送った書状等がそもそものソフトウェアを作成したメーカの営業上の信用を害するとされてしまうと、本件のように購入品を組み込んで自社製品を製造販売している相手に対して特許権者は直接警告できず、ソフトウェアメーカ（広く言えば部品製造メーカ）に警告するしか手がないことになると思います。
なお、争点８では「少なくとも、本件書状４及び本件メールは、被告が、ニフティを自社製品の製造者ではなく原告ソフトウェアのユーザという第三者であることを確定的に認識した上で、同社に対して送付したものである」と書いてありますが、争点６にはそのような記載がありません。したがって、争点６は特許権者が侵害品について購入品であることを知らない場合でも対象となりうる可能性があります。
（３）次に争点８、９ですが、判決では侵害鑑定依頼した弁理士の人数が３人では不十分であると述べています。裁判所はいったい何人に鑑定遺体すれば十分と考えているのでしょうか？不十分と判断する根拠が何も示されず、十分と判断する人数も示されないのでは困ってしまします。
（４）また、判決では無効理由についての調査も不十分である、と述べています。無審査制度の実用新案の場合は、権利行使する際に実用新案技術評価書を提示したうえで警告しなければならない、と定められています（実２９条の２）。一方、審査制度を採用している特許法にはそのような規定はありません。それにもかかわらず、無効理由調査を求める理由は何なのでしょうか？
もちろん、実際には特許権者は権利行使する前に無効理由調査することがよくあります。しかし、これは事前に無効理由をある程度調べておかないと、特許係争（当事者間の交渉や訴訟）に費やす金額や労力が無駄になる可能性が高いから、というのが主な理由だと思います。
Page updated
Report abuse