ALICE判決以降の米国101条判断に関する一考

「ソフトウエアは特許にならない!?」

そんな極端な風説まで飛び回り米国におけるソフトウエア関連特許の審査に混乱を巻き起こしたAlice Corp. v. CLS Bank International事件(通称:アリス判決,2014年,米国最高裁)

当時、自分はまだ特許事務所にて大企業の特許業務を中心に対応していましたが、この判決以降、米国特許出願における中間対応で「対応不要(諦め)」というクライアントからの指示が増えたことが印象的でした。

あれから3年、審査実務はある程度の落ち着きを取り戻しつつも、米国101条対応は未だに注目すべき話題であり続けているようです。

この3年、ソフトウェアに明るい弁理士の有志により継続して勉強会を開催して対応指針を探ってきたのですが、ある程度判例の検討結果も蓄積され、進むべき道筋が見えてきた気がするのでまとめを少々。

自分なりに一言でいえば、

「コーディング可能なレベルまで、技術的な仕様や意義を明確に」

ということかと。

 

ソフトウエア関連の特許出願で酷い状態のものを簡潔に言い表すと、

・こんなこっとイイナ♪でっきたらイイナ♪
・はい!それができるパソコン~♪
・中身は内緒だよ♪

この3つが書いてあるだけで、実際の技術は何ら開示されていないペラッペラなものが本当にあります。

それが審査でちゃんと弾かれていれば問題ないのですが、「それが開示されている文献が無い」という理由で特許になってしまうからタチが悪い。
単なる「願望」を書いただけの特許出願が特許として登録されてしまう。

その結果、世の中に対してなんら「新たな技術」を提供していないにも関わらず、その「願望」を叶えているソフトウエアやシステムに対する権利行使が起こってしまうという理不尽な事態に。

それに対する警鐘としての判決がアリス判決ですね。

「それが開示されている文献が無い」という理由で特許になってしまうのであれば、その前段階、「そもそも特許として認められるべき対象なのか否か」を判断し、「抽象的な概念」は特許されるべき対象ではないという判断で弾こうというのがアリス判決の趣旨。

これは、「技術的に優れているか否か」を判断する能力の乏しさに対する「逃げ」ともとれる対応で、考えようによっては非常に残念なのですが、、、

 

で、以降の101条関連の判決について有志の勉強会で諸々と検討してきた結果の印象としては、

特に何かを変える必要はない

という事。

上記の通り、アリス判決の趣旨は、「願望だけが書いてあるようなうっすい特許出願を適切に弾く」こと。

対して、(少なくとも自分にとっての)ソフトウエア関連発明における特許出願のセオリーは、システムのアーキテクチャ、情報の意味、処理の内容を詳細に記述して、その結果得られる技術的なメリットを明確化すること。

このセオリーが守られている限り、アリス判決以降の審査でも恐れる事は無いというのが基本です。

逆に、それを技術的視点で書けないのであれば、それは特許されるべきものではない単なる「願望」か、エンジニアへのヒアリングが足りないかです。

ただし、審査の現場も混乱していて、ちゃんと技術的に記述できるものであっても、審査官のキャラクターによっては強硬に拒絶されてしまう場合もあるのが困りもの。
そんな時には、「この判決ではこう言ってる」という形で反論するわけで、やはり101条関連の判例知識が重要になってくるわけですね。

Enfishなんかの有名判決はネット上にあまた転がっている他の記事に任せるとして、自分が勉強会で担当した判決についてざっと書いておこうかと。

<1.MCRO, Inc. v. Bandai Namco Games America Inc.

特許の内容はこちら

3Dモデルを自動的にアニメーションさせる技術についての訴訟。

generating an intermediate stream of output morph weight sets and a plurality of transition parameters between two adjacent morph weight sets by evaluating said plurality of sub-sequences against said first set of rules;

前記第一規則群に対して前記複数のサブシーケンスを評価することにより、出力された形態重みセットの中間ストリーム及び隣接する二つの形態重みセット間の複数の遷移パラメータを生成する

という要素により、従来技術に対する技術的な改善が明確化されていると判断。
更に、「3Dモデルのアニメーションを自動化したい」という要求に対する解決策に対しての技術的権利を先取りするような、広過ぎる記載にはなっていないと判断。

面白いことに権利者側が、「ほら、他の方法でもできる」と、特許を回避可能な技術をデモンストレーションするという事までやっています。

つまり、
特許出願に際してちょっと実務をかじった担当者は「とにかく広く」と馬鹿の一つ覚えのように言うわけですが、それに対するアンチテーゼ。

新たに世の中に開示する技術、それによって得られるメリット、その権利を的確に主張すべし、という事ですね。

<2.Amdocs (Israel) Limited v. Openet Telecom, Inc.

特許の内容はこちら

特に明細書の記載が詳しく参照され、それにより従来技術に対する技術的な改善が認められた事例。

少し前まで、「米国特許出願では構成のみを単純に書いて、効果は書くな」といった風潮がありましたが、少なくともソフトウエア関連発明においては技術的な意義を明確化すべきことが示された感じ。

ただし、請求項中の「enhance」という一単語に対する意義の認定が強過ぎる気がしないでもない。

<3.FAIRWARNING IP, LLC, v. IATRIC SYSTEMS, INC.

特許の内容はこちら

不正アクセスの検知に関する特許出願

the rule comprising at least one criterion related to accesses in excess of a specific volume,accesses during a pre-determined time interval,accesses by a specific user, that is indicative of improper access of the patient’s PHI by an authorized user wherein the improper access is an indication of potential snooping or identity theft of the patient’s PHI, the authorized user having a pre-defined role comprising authorized computer access to the patient’s PHI;

という形で不正アクセス検知のためのルールが特定されていたものの、それは抽象的概念であると判断。

データ分析に関する特許というのも普通にあり得るもの。
正直、こんな感じの特許を書いたことも過去ありそうな気がします。

但し、データ分析に関するルールが一概に特許適格性を否定されるかというとそうでもないはず。
判決文でも「FairWarning’s claims merely implement an old practice in a new environment.」と指摘されており、今回は提示されたルール自体が古臭かったという事もあります。

情報の種類や構成に対して目新しい処理を提示できれば可能性はあるのではないかと。

でもそれって、101条の問題なのかな?

101条の問題と102条、103条、112条辺りの問題との境界が事件によって揺れ動いてしまっているのが現状かと。

<4.VISUAL MEMORY LLC, v. NVIDIA CORPORATION,

特許の内容はこちら

異なる種類のプロセッサを接続可能なメモリシステムに関する発明。

「102条,103条若しくは112条の問題と101条とは別で、101条の問題としてはこの程度の記載で十分。ただし、102条,103条若しくは112条によって特許が無効である可能性は否定しない」という多数派の意見に対し、

「この程度の記載では、実際に技術を実現するためにプログラマーによる革新的なコーディングが必要であり、101条をクリアできていない程度に抽象的である」という反対意見が示された。

101条の判断においてクレームではなく明細書(やマイクロフィッシュ)を参照することが本当に適切か?という疑問はありつつ、ソフトウエア関連発明に関する101条問題の終着点はこの判決に現れているのではないかと感じた判例です。

 

そして、自分がソフトウエア関連特許の明細書を書く際に考えていた事を改めて整理できた判例もありました。

それは、

自分でプログラミングできる程度に技術が明確化されているか?

という事。

いざ、特許出願された技術に基づいてシステムを組もうとした際に、「技術情報が足りなくて組めない」という状態では、その特許出願が世の中に提示したのは「願望」や「概念」であって、「技術」ではありませんね。

そこは、コーディングを行うエンジニアの能力や発想力によってしまう部分でもあるので、一概に線引きできることでもなく難しいのですが。

 

自分が特許出願の打ち合わせを行う際、「情報が足りない。これでは実装できない」と思えば、そこは遠慮なくガンガン突っ込みます。

その結果、実力よりもプライドが先に立つようなエンジニアからは嫌われてしまうのですが、、、

他方、そんなディスカッションを通じてエンジニアと信頼関係を築けた時の嬉しさはひとしお。
プライドばかりのエンジニアから嫌われる事の残念さを一掃してくれるほどに大きなものです。

こないだも、ニューラルネットワークに関する特許を書いたのですが、その特許の発明者以外の人がその特許の明細書に基づいてプロトタイプを作るということになりました。

「これは明細書のデキを測るいい機会だ」

と感じていたのですが、その結果は、、、良好。

「コレじゃ動かない」と感じた心に従い、実装面の事まで詳しくヒアリングして反映した甲斐があったというものです。

まぁ、それをわかってくれる人なんてそうそういないので多くの場合は自己満足なんですけどね。

 

とまぁそんな自慢話はさておき、「ソフトウエア関連の特許を書く弁理士はプログラムを書けなきゃだめだ」という持論に対して、米国101条関連の判決が説得力を与えてくれたというオハナシ。

そして、米国101条に対する実務の指針として自分が思うところは、

・プログラミング実装可能な程度に具体的に
・その技術により得られるメリットを明確に

というところかと。

そしてこれは「日本の特許出願において兼ねてより言われている事と大差ないな」というのが率直な感想。

「日本特許実務最強論」を提唱します。

コメントを残す

メールアドレスが公開されることはありません。