米国への特許出願では、101条について悩まされている人は多いだろう。

自分もその一人だ。

ここで備忘録として、101条違反を回避するための対策を整理しておく。

個人の所感で記載しているに過ぎないので、あくまで一意見として捉えていただきたい。

判断フロー

まずは、以下が特許適格性の基本的な判断フローとなる。

出展: MPEP §2106

Step 1

クレームが以下の法定カテゴリ(方法、装置、製造物、組成物)のいずれかに属していれば第一関門はクリア、Step 2Aに進む。

属していなければ、「特許不適格」と判断されて即終了。

日本ではプログラムクレームが認められるが、米国出願の場合は記録媒体クレームなどに修正しておく必要がある。

Step 2A

Step 2Aでは、右図の通り、以下のProng 1, 2で特許適格性が判断される。

Prong 1

以下の司法例外に言及しているかを判断される。

言及していなければ「特許適格」と判断され、言及していればProng 2に進む。

  • 抽象的アイデア
    • 数学的概念
    • 人間の活動を体系化する方法
    • 思考プロセス
  • 自然法則又は自然現象
Prong 2

クレームが上の司法例外を含んでいても、追加の要素が司法例外を実用的な応用に統合しているものであれば、「特許適格」と判断される。

Prong 2でも「特許適格」と認められなければ、Step 2Bへ進む。

Step 2B

クレームが発明概念を提供していれば、「特許適格」と判断される。

発明概念を提供していなければ、「特許不適格」と判断されて審査終了。

発明概念の有無は、司法例外を著しく超えて技術的に意味のある改善や実用性を示すものであるか(例えば、特定の技術分野の機能の向上や特定の技術的課題を解決する手段であるか)で評価される。

自分の実務経験上での話とはなるが、101条違反に対しては、ほぼStep 2A(Prong 1, 2)の中で戦っている感じである。

少なくとも自分の周りでは、Step 2Bで特許適格と判断された事例を見たことがない。Prong 2で特許適格が認められなければ、よりハードルの高い(と私は思っている)Step 2Bで特許適格が認められる可能性は極めて低いのではないだろうか?

そもそもStep 2Bの判断基準は、新規性や非自明性のような要素で判断されている印象なので、これが特許適格に関係してくるのがあまり腑に落ちない。

一応、USPTOの仮想事例に1件事例はあるのだが。

では、どうやって特許適格を主張するかを考えたい。

対応方針

Step 2AのProng 1では、抽象的アイデアが大きな障壁であり、特に「思考プロセス」というのが曲者である。

人の脳内で実現できるなら「思考プロセス」に当てはめられてしまうこととなる。

USPTOが公表しているGUIの仮想事例でも、所定期間における各アイコンの使用量を求めるのは、最も広い概念で捉えると思考プロセスであると認定されている。

内部処理に言及すれば良い?

一方、アイコンに関連付けられた各アプリケーションにどれだけのメモリが割り当てられたかをトラッキングするプロセッサを用いて、所定期間における各アイコンの使用量を特定する、となると、人の脳内で実施できないプロセッサの動作を含むため、思考プロセスでないと判断されている。

しかし、このような記載は装置やプログラムの内部処理に言及することになるため、特許の侵害発見容易性を著しく損なわせるものとなる。

もちろん発明のポイントとなる部分が内部処理自体にあるのなら問題ないが(公開せずにノウハウにしたほうが良いのでは?という議論はさておき)、そうでなければ個人的にはあまりクレームには記載したくない。

そこで現実的な対応となるのは、次のProng 2ではないかと思う。

Prong 2での権利化を目指す

GUIの仮想事例では、たとえアイコンの使用量を求めるステップが思考プロセスであっても、その使用量に基づき、最も使用量の多いアイコンを、GUI上のスタートアイコンに最も近い位置に自動的に移す(思考プロセス以外の追加要素)ことで、従来のシステムに対して特定の改善を提供していると評価している。

つまり、抽象的アイデアに言及されていても、そのアイデアによって得られた情報を使って、特定の技術課題の改善に繋がるよう、実際の装置でアウトプットを行う工程までクレームアップしてしまえば良いのである。

アウトプットなら何でも良い訳でなく、現実としてコンピュータの機能改良であったり、特定の技術分野での改善に繋がっている必要があることに注意したい。

単に結果を出力するという記載だけでは、一般的なコンピュータの機能を実行するだけであり、抽象的アイデアを適用する命令と変わらないので、より具体的な出力の特徴を言及したいところである。

実務上でのあるケースでは、得られた判定結果を用いて「警告を表示する」という要素(外部の物理的現実)を加えただけで101条違反が解消されるケースもあった。

警告表示により、〇〇の技術分野において問題の生じる可能性のあった状況をいち早くユーザが容易に把握できるようになった、と認められたということと推測する。

※警告表示の要素追加によって、常に101条違反が解消されることを保証する訳では無い。

まとめ

以上のように、明細書を作成する際には情報処理を行う工程だけでなく、

  • 得られた情報を用いて何らかのアウトプットを出す工程も含んだ実施例
  • そのアウトプットによって得られる技術課題の改善内容

を予め記載しておくと、101条違反を回避しつつ権利価値の低下を抑制できるのではないかと思う。

関連記事