知財レポート

事案の内容

【手続の経緯】

・平成２２年　６月２８日　本願特許出願（特願２０１０－１４５７３５号）
・平成２６年　４月２５日　設定登録（特許第５５２７０４５号。本件特許）
　その後、本件訴訟提起

【本件特許権の内容（請求項９）】

※以下、下線は筆者追記
Ａ 所定のアプリケーションを記憶する記憶手段と、前記アプリケーションで提供されるサービスに関する情報を管理する管理手段とを少なくとも備える情報処理装置に、他の装置から、前記サービスを登録するためのデータを受信した場合、そのデータに基づき、前記アプリケーションの処理により前記サービスを登録し、
Ｂ 登録された前記サービスに関する情報を前記他の装置から供給されるデータに基づき生成し、
Ｃ 生成された前記情報で、前記管理手段に管理されている前記情報を更新する
Ｄ ステップを含む処理を実行させるコンピュータが読み取り可能なプログラム。

【裁判所の判断】

１ 本件明細書の記載事項
２ 争点１－１（構成要件Ａの充足性）について
⑴ 「前記アプリケーションで提供されるサービス」の意義
ア 構成要件Ａは、「所定のアプリケーションを記憶する記憶手段と、前記アプリケーションで提供されるサービスに関する情報を管理する管理手段とを少なくとも備える情報処理装置に、他の装置から、前記サービスを登録するためのデータを受信した場合、そのデータに基づき、前記アプリケーションの処理により前記サービスを登録し、」と規定しているところ、本件発明の構成要件において、これ以外に「アプリケーション」と「サービス」の関係等についての記載はない。そして、本件明細書には、「アプリケーション」と「サービス」の関係に関する記載として、「ＵＩＣＣハードウェア１０１の上に、ＵＩＣＣ内のアプリケーションマネージャ１０２があり、この上に、アプリケーション１０３、アプリケーション１０４、アプリケーション１０５が管理されている。アプリケーション１０３は、例えば、クレジットカードの機能を実現するサービスを提供するためのアプリケーションである。アプリケーション１０４は、例えば、交通機関に乗り降りするときの料金の支払いなどのときに用いられるトランスポート系のサービスを提供するためのアプリケーションである。」（【００１２】）、「アプリケーション１０５は、総合サービスを提供するためのアプリケーションであり、サービス１０６－１、サービス１０６－２、サービス１０６－３を提供する。例えば、サービス１０６－１は、クレジットの機能を実現するサービスであり、サービス１０６－２は、トランスポート系のサービスを提供するサービスであり、サービス１０６－３は、クーポンを提供するサービスである。」（【００１４】）、「また例えば、第３アプリケーション２５６は、総合サービスを提供するためのアプリケーションである。後述するように、第３アプリケーション２５６は、クレジットの機能を実現するサービス、トランスポート系のサービス、クーポンを提供するサービスなど、複数のサービスを提供するためのアプリケーションである。」（【００３６】）、「サービスの存在確認が行えるようになれば、必要時に対向のアプリケーションの追加を行うことが可能となる。」（【０３４６】）との記載があることが認められ、これらの記載は、アプリケーションがサービスとされる機能を提供するものであり、他のサービスを利用する場合には当該サービスに対応するアプリケーションの追加が必要であることを示すものであると理解することができる。そうすると、構成要件Ａにおいて「前記アプリケーションで提供されるサービス」とあるのも、アプリケーション自体がサービスとされる機能そのものを提供する場合を指すものであると解するのが相当である。
イ これに対し、原告は、本件発明における「サービス」は、アプリケーションに当初から備わっているサービスに限られないことは本件明細書の【００３６】や【００８５】の記載から明らかであり、アプリケーションに当初は登録されていなくても、その後、アプリケーションの処理により追加で登録されるようなサービスも当然に技術的範囲に属することが前提とされ、当該サービスを提供する際、第三者であるサービスプロバイダーサーバと連携することは当然の前提とされているのであるから、そのような連携が行われるサービスであることをもって「前記アプリケーションで提供されるサービス」の充足性は左右されない旨主張する。
　しかしながら、【００３６】や【００８５】には、ＵＩＣＣにサービスが追加で登録され得ることが記載されているにすぎず、アプリケーションとサービスの関係を定めるものではないことからすれば、これらの本件明細書の記載をもって、構成要件Ａの「前記アプリケーションで提供されるサービス」について、実際のサービスは第三者のサービスプロバイダーサーバと連携して、当該サーバにより提供されるものを含むものであると解釈すべきであるとはいえず、原告の上記主張は採用することができない。
⑵ 被告プログラムの充足性
　証拠（甲５ないし１０、２８）及び弁論の全趣旨によれば、被告プログラムは、ＧＯ Ｐａｙと呼ばれるタクシー料金の決済機能を有しているところ、ＧＯ Ｐａｙは、ｄ払いと連携することによりｄ払いを利用することが可能となるものの、ｄ払いはＮＴＴドコモが提供する決済機能であって、ＧＯＰａｙは個々のタクシー料金の決済手段として連携したｄ払いを利用するものであると認められる。そうすると、ｄ払いは、被告プログラムが備えるアプリケーションであるＧＯ Ｐａｙ自体がサービスとして提供するものであるとはいえないことから、被告プログラムは構成要件Ａの「前記アプリケーションで提供されるサービス」を充足しない。
３ 小括
　以上によれば、被告プログラムは構成要件Ａを充足しないから、その余の点について検討するまでもなく、被告プログラムが本件発明の技術的範囲に属し、被告による被告プログラムの作成等が本件特許権を侵害すると認めることはできない。
第４ 結論
　よって、原告の請求はいずれも理由がないから棄却することとして、主文のとおり判決する。

【所感】

　裁判所の判断はやや厳しいが妥当と考える。
　明細書中には、サービスの提供主体を広げるような直接的な記載はなく、実施例もアプリケーション自体がサービスの提供主体であることを前提とした記載ぶりに読める。そのため、「アプリケーションで提供されるサービス」が「アプリケーションが提供するサービス」のように解釈されたことは妥当と考える。サービスの提供主体を限定しない意図が出願当初からあったなら、提供主体を限定しないような定義を明細書中に記載しておく、実施例を充実させておく、などの対処が必要であったと考える。
　なお、「アプリケーションを使用することで利用可能なサービス」のようなクレーム文言を採用することも限定解釈の抑制に繋がると考えるが、本事案の場合、結局は明細書中でのサポートが必要になると考える。