特にコンピュータに特化した特許クレームを書く際のヒントを3つの記事に分けて紹介していきます。コンピュータに限らず、一般的なクレームにも十分応用できるものがたくさんあるので、参考にしていただけたら幸いです。（パート２，３はTLC限定公開中です。）
特許ポートフォリオに付加価値を与える特許を取得するために、許容されるクレームを取得するための一般的なヒントをご紹介します。101の特許適格性の問題に関するアドバイスもあり。
一般と101のヒント：技術上の問題を解決する発明コンセプトを特定する
第１に、指差すことができる発明的概念、および任意のサブ概念を特定することでです。本発明の概念またはサブ概念が、特にその問題がコンピュータの動作に関するものである場合には、その発明の概念またはサブ概念が、当該技術における問題を具体的にどのように解決するかを示すべきです。そのような問題は、一般的に背景に明確に示されるべきであり、その問題に対する先行技術の解決策は注記され、具体的に非難されるべきです。発明または発明的概念自体が問題の認識または先行技術解決策の欠陥に部分的に関連している場合、例えば、認識から見て解決策が些細なものである可能性がある場合、先行技術と先行技術解決策との問題の認識は、認識が進歩的解決策自体の一部であることを示すために、発明セクションの要約の中で行われるべきであることに注意してください。 請求項は、発明の概念をカバーするようにドラフトされるべきです。
101のヒント： 発明のコンセプトは、アクション指向であるべきである
さらに、本発明の概念は、常に、実行されるあらゆる計算の結果として実行される実世界での動作の観点から記述され、主張されるべきです。単に結果を計算するだけでは、一般的に不十分であり、ほとんどの場合、拒絶されます。これを避けるためには、クレームは、その結果で有用な何かを「行う」必要があります。別の言い方をすれば、クレームは「対応」を持つべきであるということである。 例えば、サイバーセキュリティ攻撃を検出するだけでは不十分です。しかし、このような攻撃を検出したときに緩和を実行することは、通常、101 の拒絶を回避するのに十分です。この点で、明細書には、実行される可能性のある少なくとも１つの、好ましくは複数の緩和動作が記載されているべきです。
101 のヒント： 方法クレームは、それが実行される環境を記載する必要がある
また、どのような方法の請求項においても、その方法が実行される環境を想起させるのがよいです。例えば、コンピュータ、ネットワークの配置などが挙げられます。これは、特に、本発明がその効果を達成するためには、コンピュータやネットワーク通信の速度で動作しなければならない場合、例えば、数百万パケットを処理しなければならない場合に、１０１の拒絶を回避するのに役立ちます。これにより、請求された発明がコンピュータ技術から生まれたものであり、人が心の中で方法を実行することができなかったことを示すことができるので、方法は人でもできるという１０１の拒絶を回避することができます。
解説
問題を具体的にどのように解決するかは、どの分野の発明であっても重要です。そこをうまく説明できていないと、権利化できても「使えない」特許になってしまう可能性があります。特に、ソフトウェア特許の場合、問題解決の具体例の詳細で101の特許適格性が判断される場合が多いので、特にソフトウェア特許の場合、問題解決の具体例をなるべく多く示すといいと思います。
ソフトウェア特許で避けたいのが抽象化です。計算して終わりだと抽象的すぎます。具体的にその計算から「何をするのか？」が問われています。そう言った意味で、計算から得られた情報からどのような「対応」をするのかを明確に示すのは重要です。この行動を意識してクレームを書くだけでクレームの質は大きく向上すると思います。
方法クレームには環境を示すことで人間ができる作業と差別化できることもあります。あと、TLCメンバーのBrian曰く、方法クレームを書くなら必ずフローチャートを書け！とのことです。
このほかにもまだたくさんクレーム作成のポイントがるので、パート2，3もぜひ読んでみてください。（パート２，３はTLC限定公開中です。）
TLCにおける議論
この話題は会員制コミュニティのTLCでまず最初に取り上げました。TLC内では現地プロフェッショナルのコメントなども見れてより多面的に内容が理解できます。また、TLCではOLCよりも多くの情報を取り上げています。
TLCはアメリカの知財最新情報やトレンドはもちろん、現地で日々実務に携わる弁護士やパテントエージェントの生の声が聞け、気軽にコミュニケーションが取れる今までにない新しい会員制コミュニティです。
現在第二期メンバー募集中です。詳細は以下の特設サイトに書かれているので、よかったら一度見てみて下さい。
まとめ作成者：野口剛史
元記事著者：Michael Ben-Shimon and Eugene Rosenthal. M&B IP Analysts, LLC（元記事を見る）
