連邦巡回控訴裁判所、モバイルウォレットの請求が無期限であると認定
連邦巡回控訴裁判所は、Fintivが所有するモバイルウォレット決済システムに対する特許請求は、 35 U.S.C. 112(6)に基づき無期限として無効であるという地方裁判所の判決を支持しました。
この事件は 、Fintiv, Inc. v. PayPal Holdings, Inc. です。
Fintivは3つの特許を侵害したとしてPayPalを訴えた。地方裁判所は、主張された特許の特定のクレーム条件は35 U.S.C. § 112の対象であると判断し、主張されたクレームは無期限として無効であると判断しました。
フィンティフは控訴した。
米国特許商標庁(USPTO)が 説明しているように、
非仮実用新案特許出願には、次のような明細書を含める必要があります
– 説明および請求。
– 必要に応じて図面...
35 U.S. Code § 112 は、特許明細書を扱っています。
明細書には、本発明が属する技術分野の当業者または本発明と最も関連の深い技術分野の当業者が本発明を製造および使用できるような完全、明確、簡潔かつ正確な用語で、本発明ならびにその製造および使用の方法および工程を記述しなければならず、本発明者または共同発明者が意図した発明の実施に関する最善の方法を記述しなければなりません。
現在の法律の関連セクションは次のとおりです。
(b) 結論。
明細書は、発明者または共同発明者が発明と見なす主題を特に指摘し、明確に主張する1つまたは複数の請求項で締めくくられるものとする。
(f) 組み合わせの請求項の要素。組合せの請求項の要素は、構造、材料、またはそれを裏付ける行為の記述なしに、特定の機能を実行するための手段またはステップとして表現され、そのような請求項は、明細書およびその同等物に記載されている対応する構造、材料、または行為をカバーするように解釈されるものとします。
連邦巡回控訴裁判所が本件で説明したように、
主張された特許は一般に、「金融取引システム」、「モバイルウォレットプラットフォーム」、「モバイルウォレットプログラム」、「モバイルウォレット取引システム」、「モバイル金融サービス(mFS)プラットフォーム」、または「電子決済システム」とも呼ばれる「クラウドベースの取引システム」に関連しています。
主張された4つの特許すべての仕様は実質的に類似しており、次の例のように「支払いハンドラー」という用語が含まれています。
- 銀行、クレジットカードおよびデビットカード処理業者、請求書支払処理業者の1つ以上のAPIを含む、さまざまな決済処理業者の[アプリケーション・プログラミング・インターフェース(以下「API」)を使用するために動作可能な 決済ハンドラ ・サービス。
- 銀行、クレジットカードおよびデビットカードプロセッサ、および請求書支払プロセッサの 1 つ以上の API を含む、さまざまな支払プロセッサの API を使用するように構成された 支払ハンドラ 。
- さまざまな支払い処理業者と対話するための標準 API を公開する 支払いハンドラー 。
(中略）。
連邦巡回控訴裁判所は、「支払いハンドラーの用語は、その機能を実行するための十分な構造を引用せずに機能を引用している」という地方裁判所の意見に同意した。
裁判で、PayPalの専門家は、支払いハンドラーの条件は「空白のボックスを超えた構造を提供しておらず、重要なことに、[当業者(「POSA」)は、引用された機能の実装方法を理解していなかっただろう」と証言しました。
連邦巡回裁判所が説明したように、
地方裁判所は、「ハンドラー」をナンス用語「モジュール」と正しく類似させ、これは「特定の機能を実行するソフトウェアまたはハードウェアの単なる一般的な説明」であると判断しました。
(「ナンスワード」は、モジュール、コンポーネント、装置、要素、システム、デバイス、メンバーなどの一般的な言語構造です。
地方裁判所は、「『ハンドラー』という用語はいかなる構造も与えていない」と認定した。
たとえば、前のケースでは、
裁判所は、「接頭辞『ユーザー識別』」は「モジュールの機能、つまりユーザーを識別するための機能を記述するだけなので構造を与えない」ため、「クレーム言語はクレームされた機能を実行するための構造を提供していない」と推論した。
Fintivはまた、主張されたクレームに現れるクレームの接続用語である「その」、「操作可能」、「構成」は「非構造的な用語よりも構造的な用語で使用されることが多い」と主張した。
しかし、連邦巡回裁判所は次のように述べた。
Fintivは、これらの接続語が主張されたクレームの接続語と同一またはほぼ同一であると述べる以外に、異なる特許を扱うこれらの事件における接続語がここでどのように決定的であるかを意味のある説明にしていません。
これらは「魔法の言葉」ではない、と裁判所は示唆した。
私たちの判例法は、これらの接続語(つまり、「それ」、「操作可能」、「構成」)が用語が構造的であることを自動的に示唆するという包括的な規則を規定していません。
以前の事件と同様に、裁判所は次のように述べた。
支払ハンドラー条件がアクションを完了するように構成または操作されていることを暗唱する純粋に機能的な請求文言は、構造を提供しません。
裁判所は次のように指摘しています。
明細書に開示された構造は、本質的な証拠がその構造をクレームで引用された機能に明確にリンクまたは関連付ける場合、対応する構造として適格です。
汎用コンピュータが機能を実行する場合、仕様は、その機能を達成するためにコンピュータが実行するアルゴリズムを開示する必要があります。
裁判所は、「明細書が請求された機能を実行するための適切な対応する構造を開示していない場合」、クレームは無期限であると述べた。
連邦巡回控訴裁判所は、主張された請求項が
「銀行、クレジットカードおよびデビットカード処理業者、請求書支払処理業者の1つ以上のAPIを含む、さまざまな決済処理業者のAPIを使用する」機能を実行するための十分な構造を開示していないこと、および「異なる決済処理業者と対話するための共通のAPIを公開する」機能を実行することを怠っている。
特に、裁判所は次のように指摘した。
地方裁判所は、主張された特許の仕様には、引用された機能を実行するためのアルゴリズムが開示されていないと認定しました。
仕様は単に「API を翻訳する一般的なプロセス」に言及しているだけです。
裁判所はこう結論づけた。
明細書は、銀行、クレジットカードおよびデビットカード処理業者、請求書支払処理業者の1つ以上のAPIを含む、異なる決済処理業者のAPIを使用する機能を実行するためのアルゴリズムに関する詳細を提供せずに、一般的な用語を使用して支払ハンドラ用語の機能を引用する以外に追加の開示を提供し、異なる決済処理業者と対話するための共通のAPIを公開する。我々は、「不特定のアルゴリズムの動作の結果」を記述することは、汎用コンピュータの開示を§112を満たすのに十分な構造の開示に変換するのに十分ではないと判断しました。
