「良い特許」と「短いクレーム」（霜降り肉にする方法の発明）

一般にクレームは短いほど良いというのは確かだと思います。ただ、分野によっては特に弁理士が努力しなくても必然的に短くなるクレームはあります。例えば用途発明の分野では、物質名○○と効能△△を示す「○○を含有する△△剤」とか「○○を投与することにより△△する方法」という形にすれば特許できるので、必然的に短くなります。

   「牛の肉質の改善方法（霜降り肉にする方法）」の発明に関する特許第3433212号もこのパターンで、その請求項１は次のとおりです。

   「牛にビタミンＣを投与することにより肉の脂肪交雑等級を改善する方法。」

   牛にビタミンＣを投与して霜降り肉にする（牛の肉の脂肪交雑（霜降り）の等級を上げる）という発明で、極めて短くて単純な内容ですが、これだけで特許されています。

   この特許のポイントは２つあって、(i)「牛にビタミンＣを投与する」と(ii)「肉の脂肪交雑等級を改善する」との２つです。特許侵害だと認定するためには、(i)だけではダメで、(ii)も必要です。

   だから、「お前は、霜降り肉にするためのビタミンＣを牛に投与している（あるいは、霜降り肉にするための牛用のビタミン剤を販売している）ようだが、それは特許侵害だから中止しろ。」と警告しても、その相手方から「いや、オレは、牛のストレスを解消して健康を維持させるためにビタミンＣを投与しているのであって、牛の霜降りの等級を上げるためにビタミンＣを投与しているのではない（あるいは、牛のストレス解消用のビタミン剤を販売しているだけだ）。」と反論されると、お手上げになる可能性があります。牛に与える「飼料」には薬事法が適用されないというのがポイントです（後述）。

   つまり、上記の(ii)の効用は発明の目的・作用効果に直結するものなのですが、特許侵害行為としてこの(ii)を立証できるかどうかが訴訟の勝敗の分かれ目になります。その意味では、上記の特許クレームは、確かにすごく「短い」けれども、すごく「良い特許」かというと、そうでもないとなるのかもしれません。

   つまり、「良い特許」とは、「広い特許」で且つ「強い特許」である必要があるのですが、この特許クレームは極めて短いだけに「広い特許」にはなっているけれども「強い特許」とは言えないのではないか、ということです。

   一般的に、用途発明では、短いクレームでもこのような限界は付きものと思います。例えば「ミノキシジルを有効成分とする育毛剤」という特許を取っていたとしても、「同じミノキシジルを有効成分とする血圧降下剤」には効力が及ばないからです。つまり、薬剤の分野において、用途発明が、事実上、強い効力を持っているように見えるのは、純粋な特許権の力によるのではなく、薬事法の力によるところが大きいのではないかと思います（成分から薬剤を製造して販売するときは必ず薬効とセットにして売り出すしかなく、また薬剤によっては医師の処方箋などが必要とされているため）。
 

アマゾンのワンクリック特許が日本で成立

ビジネスモデル特許として有名なアマゾンのワンクリック特許が2件(第4937434号、第4959817号)、出願から14年目に、日本でも登録されたようです(日経記事、及び、栗原弁理士のブログ)。
まだ特許公報は出てませんが、IPDLで特許査定直前の補正書などから特許になった請求項を把握できます。
この2件の中、権利範囲がより広いと思われる特許第4959817号の出願は、当初の出願(親出願)を分割した子出願をさらに分割した孫出願(追記:特開2010-160799)のようです。
この特許第4959817号の請求項１は、上記補正書より、次のとおりです。（１）（２）・・・などは私が入れました。

【請求項１】
　アイテムを注文するためのクライアント・システムにおける方法であって、
（１）前記クライアント・システムのクライアント識別子を、前記クライアント・システムのコンピュータによりサーバ・システムから受信すること、
（２）前記クライアント・システムで前記クライアント識別子を永続的にストアすること、
（３）複数のアイテムの各々のアイテムについて、前記アイテムを特定する情報と、前記特定されたアイテムを注文するのに実行すべきシングル・アクションの指示部分とを、前記クライアント・システムのディスプレイに表示することであって、前記シングル・アクションは、前記特定のアイテムの注文を完成させるために前記クライアント・システムに要求される唯一のアクションであり、前記クライアント・システムに対して前記シングル・アクションの実行に続いて前記注文の確認を要求しないこと、および
（４）前記シングル・アクションが実行されることに応答して、前記特定されたアイテムの注文要求と前記クライアント識別子とを、前記サーバ・システムに送信することであって、前記注文要求は、前記シングル・アクションによって示されたシングル・アクション注文要求であり、前記クライアント識別子は、ユーザのアカウント情報を特定することを備え、
（５）前記サーバ・システムが、前記シングル・アクションによって示されたシングル・アクション注文要求と、前記クライアント識別子に関連付けられた１または複数の以前のシングル・アクション注文要求とを組み合わせ、１つの注文に結合することを特徴とする方法。

出願当初の請求項とは大きく異なっていますが、かなり広い内容で、良い特許だと思います。
おそらく、次のような内容です。
（１）と（２）・・・クライアント端末が、サーバーシステムからユーザーIDを受信してクッキーなどに保存する。
（３）・・・クライアント端末が、ユーザーが商品を指示するためのアイコンと、ユーザーがワンクリック(後で注文の確認を要求しないシングル・アクション)を指示するためのボタン(＝シングル・アクションの指示部分)を、自らの画面に表示する。
（４）・・・クライアント端末が、ユーザーがワンクリック・ボタンを押したとき、それに応答して、指示された商品の注文要求とユーザーIDとをサーバーシステムに送信する。
（５）・・・サーバーシステムが、前記ワンクリックによる注文要求と、それ以前のワンクリックによる注文要求であって同じユーザーIDに関連付けられている注文要求とを、纏めて「１つの注文」として結合する。
上記（１）〜（４）はクライアント端末の動作、（５）はサーバーシステムの動作として構成されています。
上記（５）が特徴(進歩性)のある部分だとして特許が認められたのだと思います。上記（５）により、既に受け付けたワンクリック注文の発送を未だしていない間に同じユーザーから次のワンクリック注文があれば、それらを１つの注文として纏めて発送することにより、運送料が節約できるというメリットがあるからです。
追記：上記の請求項１は、主としてクライアントシステムの側からアイテムを注文するための方法を規定するものです(請求項１中の（５）はサーバーシステムの動作として規定していますが)。これに対して、同じ特許(第4959817号)の請求項９は、主としてサーバーシステムの側からアイテムの注文を受け付ける方法を規定しています。請求項の書き方がクライアント側からかサーバー側からかが違うだけで、発明の実質は全く同じです。参考までに、次に引用しておきます。

【請求項９】
　アイテムの注文を受け付けるサーバ・システムにおける方法であって、
　前記サーバ・システムからクライアント・システムのコンピュータへ、前記クライアント・システムで永続的にストアしておくための前記クライアント・システムのクライアント識別子を送信すること、
　複数のアイテムの各々のアイテムについて、前記アイテムを特定する情報と、前記特定されたアイテムを注文するのに実行すべきシングル・アクションの指示部分とを、前記クライアント・システムのディスプレイに表示することであって、前記シングル・アクションは、前記特定のアイテムの注文を完成させるために前記クライアント・システムに要求される唯一のアクションであり、前記クライアント・システムに対して前記シングル・アクションの実行に続いて前記注文の確認を要求しないこと、および
　前記クライアント・システムで前記シングル・アクションが実行されることに応答して、前記特定されたアイテムの注文要求と前記クライアント識別子とを受信することであって、前記注文要求は、前記シングル・アクションによって示されたシングル・アクション注文要求であり、前記クライアント識別子は、ユーザのアカウント情報を特定すること、および
　前記シングル・アクション注文要求を受信すると、前記サーバ・システムにおいて、前記シングル・アクションによって示されたシングル・アクション注文要求と、前記クライアント識別子に関連付けられた１または複数の以前のシングル・アクション注文要求とを組み合わせ、１つの注文に結合すること
を備えたことを特徴とする方法。