おける中間対応で「対応不要(諦め)」というクライアントからの指示が増えたことが印象的でした。あれから3年、審査実務はある程度の落ち着きを取り戻しつつも、米国101条対応は未だに注目すべき話題であり続けているようです。この3年、ソフトウェアに明るい弁理士の有志により継続して勉強会を開催して対応指針を探ってきたのですが、ある程度判例の検討結果も蓄積され、進むべき道筋が見えてきた気がするのでまとめを少々。「コーディング可能なレベルまで、技術的な仕様や意義を明確に」ということかと。・中身は内緒だよ♪この3つが書いてあるだけで、実際の技術は何ら開示されていないペラッペラなものが本当にあります。それが審査でちゃんと弾かれていれば問題ないのですが、「それが開示されている文献が無い」という理由で特許になってしまうからタチが悪い。単なる「願望」を書いただけの特許出願が特許として登録されてしまう。その結果、世の中に対してなんら「新たな技術」を提供していないにも関わらず、その「願望」を叶えているソフトウエアやシステムに対する権利行使が起こってしまうという理不尽な事態に。それに対する警鐘としての判決がアリス判決ですね。「それが開示されている文献が無い」という理由で特許になってしまうのであれば、その前段階、「そもそも特許として認められるべき対象なのか否か」を判断し、「抽象的な概念」は特許されるべき対象ではないという判断で弾こうというのがアリス判決の趣旨。何かを変える必要はないという事。上記の通り、アリス判決の趣旨は、「願望だけが書いてあるようなうっすい特許出願を適切に弾く」こと。対して、(少なくとも自分にとっての)ソフトウエア関連発明における特許出願のセオリーは、システムのアーキテクチャ、情報の意味、処理の内容を詳細に記述して、その結果得られる技術的なメリットを明確化すること。このセオリーが守られている限り、アリス判決以降の審査でも恐れる事は無いというのが基本です。逆に、それを技術的視点で書けないのであれば、それは特許されるべきものではない単なる「願望」か、エンジニアへのヒアリングが足りないかです。審査の現場も混乱していて、ちゃんと技術的に記述できるものであっても、審査官のキャラクターによっては強硬に拒絶されてしまう場合もあるのが困りもの。そんな時には、「この判決ではこう言ってる」という形で反論するわけで、やはり101条関連の判例知識が重要になってくるわけですね。Enfishなんかの有名判決はネット上にあまた転がっている他の記事に任せるとして、自分が勉強会で担当した判決についてざっと書いておこうかと。Inc.>特許の内容はこちら3Dモデルを自動的にアニメーションさせる技術についての訴訟。rules;前記第一規則群に対して前記複数のサブシーケンスを評価することにより、出力された形態重みセットの中間ストリーム及び隣接する二つの形態重みセット間の複数の遷移パラメータを生成するという要素により、従来技術に対する技術的な改善が明確化されていると判断。「3Dモデルのアニメーションを自動化したい」という要求に対する解決策に対しての技術的権利を先取りするような、広過ぎる記載にはなっていないと判断。面白いことに権利者側が、「ほら、他の方法でもできる」と、特許を回避可能な技術をデモンストレーションするという事までやっています。特許出願に際してちょっと実務をかじった担当者は「とにかく広く」と馬鹿の一つ覚えのように言うわけですが、それに対するアンチテーゼ。新たに世の中に開示する技術、それによって得られるメリット、その権利を的確に主張すべし、という事ですね。Inc.>特許の内容はこちら特に明細書の記載が詳しく参照され、それにより従来技術に対する技術的な改善が認められた事例。前まで、「米国特許出願では構成のみを単純に書いて、効果は書くな」といった風潮がありましたが、少なくともソフトウエア関連発明においては技術的な意義を明確化すべきことが示された感じ。請求項中の「enhance」という一単語に対する意義の認定が強過ぎる気がしないでもない。PHI;という形で不正アクセス検知のためのルールが特定されていたものの、それは抽象的概念であると判断。データ分析に関する特許というのも普通にあり得るもの。こんな感じの特許を書いたことも過去ありそうな気がします。データ分析に関するルールが一概に特許適格性を否定されるかというとそうでもないはず。environment.」と指摘されており、今回は提示されたルール自体が古臭かったという事もあります。情報の種類や構成に対して目新しい処理を提示できれば可能性はあるのではないかと。それって、101条の問題なのかな?101条の問題と102条、103条、112条辺りの問題との境界が事件によって揺れ動いてしまっているのが現状かと。CORPORATION,>特許の内容はこちら異なる種類のプロセッサを接続可能なメモリシステムに関する発明。「102条,103条若しくは112条の問題と101条とは別で、101条の問題としてはこの程度の記載で十分。「この程度の記載では、実際に技術を実現するためにプログラマーによる革新的なコーディングが必要であり、101条をクリアできていない程度に抽象的である」という反対意見が示された。101条の判断においてクレームではなく明細書(やマイクロフィッシュ)を参照することが本当に適切か?という疑問はありつつ、ソフトウエア関連発明に関する101条問題の終着点はこの判決に現れているのではないかと感じた判例です。自分がソフトウエア関連特許の明細書を書く際に考えていた事を改めて整理できた判例もありました。自分でプログラミングできる程度に技術が明確化されているか?という事。いざ、特許出願された技術に基づいてシステムを組もうとした際に、「技術情報が足りなくて組めない」という状態では、その特許出願が世の中に提示したのは「願望」や「概念」であって、「技術」ではありませんね。そこは、コーディングを行うエンジニアの能力や発想力によってしまう部分でもあるので、一概に線引きできることでもなく難しいのですが。自分が特許出願の打ち合わせを行う際、「情報が足りない。これでは実装できない」と思えば、そこは遠慮なくガンガン突っ込みます。他方、そんなディスカッションを通じてエンジニアと信頼関係を築けた時の嬉しさはひとしお。プライドばかりのエンジニアから嫌われる事の残念さを一掃してくれるほどに大きなものです。こないだも、ニューラルネットワークに関する特許を書いたのですが、その特許の発明者以外の人がその特許の明細書に基づいてプロトタイプを作るということになりました。「これは明細書のデキを測るいい機会だ」と感じていたのですが、その結果は、、、良好。「コレじゃ動かない」と感じた心に従い、実装面の事まで詳しくヒアリングして反映した甲斐があったというものです。それをわかってくれる人なんてそうそういないので多くの場合は自己満足なんですけどね。そんな自慢話はさておき、「ソフトウエア関連の特許を書く弁理士はプログラムを書けなきゃだめだ」という持論に対して、米国101条関連の判決が説得力を与えてくれたというオハナシ。・プログラミング実装可能な程度に具体的に・その技術により得られるメリットを明確にというところかと。コメントをキャンセルメールアドレスが公開されることはありません。