2-5.サポート要件
サポート要件は、上位概念化(発明概念の抽象度)の限界(特許法36条6項1号)を画する。
請求項の記載と詳細な説明の統一性が要求される( 36条6項1号 )
請求項に係る発明が、「発明の課題が解決できることを当業者が認識できるように記載された範囲」を超えていると判断された場合は、請求項に係る発明と、発明の詳細な説明に発明として記載されたものとが、実質的に対応しているとはいえず、特許請求の範囲の記載はサポート要件を満たしていないことになる。
サポート要件違反の類型として、審査基準は以下の4つの場合を示している。
(1) 請求項に記載されている事項が、発明の詳細な説明中に記載も示唆もされて いない場合
(2) 請求項及び発明の詳細な説明に記載された用語が不統一であり、その結果、両者の対応関係が不明瞭となる場合
(3) 出願時の技術常識に照らしても、請求項に係る発明の範囲まで、発明の詳細な説明に開示された内容を拡張ないし一般化できるとはいえない場合
(4) 請求項において、発明の詳細な説明に記載された、発明の課題を解決するための手段が反映されていないため、発明の詳細な説明に記載した範囲を超えて特許を請求することになる場合
以上から、クレームは、明細書でサポートされる範囲において上位概念化が可能といえる。
https://gyazo.com/3b572501000437fd3bd824f5a45dcad9
出願人は、権利範囲を広くしようとして、やみくもに発明特定事項を上位概念化、抽象化しようとする傾向がある。しかも、特許法36条5項は、表現形式の自由を認めていることから、なおさらである。
しかし、特許法は、発明の機能や作用・効果そのものを保護するものではなく、それらを提供してくれる発明の構成・機能実現手段を保護するものである。ただ、それを具体的技術そのものではなく技術的思想として保護するわけであるから、表現としての幅が許容されてしかるべきである。
そこで問題となるのが、その抽象度の問題である。抽象度を高めれば高めるほど、機能的・作用的・方法的になっていかざるを得ない。
この問題を担保するのが、「特許を受けようとする発明が発明の詳細な説明に記載したものであること」(特許法36条6項1号)とするいわゆるサポート要件で、開示範囲を超えて発明を保護するものではないという特許法の目的(第1条)を具現化するものである。
https://gyazo.com/1b3b7afb503f19928cb174c60b74400b
特許請求の範囲において、発明は、特許明細書に開示された発明の範囲内で特定されなければならないのである。
ここでは、クレーム記載の発明の範囲まで、発明の詳細な説明に開示された内容を拡張ないし一般化できるか否かが判断される(審査基準:第II部 第2章 第2節 サポート要件)
権利範囲を広くしようとして、クレームの記載を抽象化して拡張ないし一般化することを試みるのは必要なことであるが、あまりにも抽象度が高すぎると、時に本来の発明の本質からはずれたり、意味不明となったりもする。クレームの記載を実効あらしめるために、発明概念を広げるにあたり、出願人、発明者は、多種多様な実施例を開示する一方、クレーム作成者は、開示された実施例の最大公約数的に表現を吟味する必要があろう。
また、権利範囲を広げようとするがあまり、発明特定事項をそぎ落とし、初期の効果の再現も不可能となってしまう事態もあることに気がつかなければならない。上位概念化した後は、サポート要件を満たすかを検討すると同時に、上記した第2の基準・・発明再現性要件に従い、当該、上位概念化された発明特定事項のみで、当該発明の効果が生じるのかを再度検証する必要があろう。
https://gyazo.com/d3f1c1bd11809fd70bae6fc446c6b970
上位概念化と発明該当性
上位概念化しすぎて、クレーム表現が抽象的になりすぎ、発明特定事項に技術的な不備が無意識の内に生じてしまったり(明確性違反)、ひいては、発明成立性(特許法29条柱書でいう発明該当性)を失ってしまうおそれがあることに注意。
とりわけ、ソフトウェア関連発明においては、以下をチェック。
「ソフトウエアとハードウエア資源とが協働した具体的手段」によって、
「使用目的に応じた特有の情報処理装置(機械)又はその動作方法が構築され」ているか。これは、「使用目的に応じた情報の演算又は加工を実現しているか」の判断による。