見出し画像

SaaS企業こそマジメに特許を考えた方が良い理由

なぜ書こうと思ったか

先週、グローバル・ブレインさんのこのブログを読んでいて、そういえばSaaS界隈であまり特許や知財の話は出てこないなと。

SaaSに限らずソフトウェアビジネスは参入障壁を作りづらいことが多く、技術面・機能面のキャッチアップが急速に進んでいくため、むしろ特許などの知財戦略が大事になる局面が多いと感じています。先ほどのブログでも、以下のように説明されています。

『技術的に模倣が容易なプロダクトの場合こそMoatが必要であり、重要な機能で特許取得できたときのインパクトは大きいと考えられます』

ご参考までに、amptalkもいくつかの特許を保有しています。

出所: J-PlatPat
  • チャットツールから生成AIへの指示を出して情報を取得する特許

  • Zoomなどビデオ会議への入室時に質問項目への入力を求める特許

  • オンライン商談や電話の内容を解析し、特定の条件に応じてチャットツールに通知を飛ばす特許  など

ということで、今回は特許や知財についてどのように考えているかについて書いてみます。ちなみに私は法律の専門家ではありませんし(学部時代に学びましたが全ては忘却の彼方に…)、あくまでビジネスサイドとしてどう考えるか、という観点で書きます。

過去事例

よく参照されるのは、2016年にfreeeがマネーフォワードを相手取った特許侵害訴訟だと思います。

以下、ChatGPTによる概要まとめ。
[訴訟の概要]
freee株式会社は、マネーフォワード株式会社が提供する「MFクラウド会計」が、自社の保有する「会計処理装置、会計処理方法及び会計処理プログラム」に関する特許を侵害していると主張し、2016年に東京地方裁判所に特許権侵害訴訟を提起しました。

[裁判の主な争点]
freeeの主張: MFクラウド会計がfreeeの特許に含まれるアルゴリズムを使用していると主張しました。このアルゴリズムは、取引内容に含まれるキーワードに基づいて自動的に勘定科目を割り当てるというものでした​​。
マネーフォワードの主張: 自社のアルゴリズムは機械学習に基づいており、freeeの特許とは異なると主張しました。裁判では、具体的な仕訳の事例やキーワードの優先順位ルールの有無などが検討されました。

[判決の内容]
東京地方裁判所は、マネーフォワードの主張を認め、freeeの請求を棄却しました。裁判所は、MFクラウド会計のアルゴリズムがfreeeの特許に含まれるアルゴリズムとは異なると判断しました​​。

freeeが持っていた「自動仕訳機能」の特許をマネーフォワードが侵害したかどうかが争われましたが、裏側のアルゴリズムが異なるため、特許侵害に当たらないという判決になっています。

お使いの方はお分かりかと思いますが、「自動仕訳機能」は会計ソフトにおいて記帳業務を自動化する優れもので、freeeとしてこの機能を守れていたかどうかは、当時の競争環境においてかなり大きな意味を持っていたはずです。

この事例は「特許を取ったけど守れなかった」というケースですが、そもそも特許化していなければ相手に真似され放題です。自社が発明した技術を必要に応じて守っていくこと、そして守るならきちんと守ること、その積み上げが技術的な優位性をつくり上げていく一助になると思います。

参考までですが、『最強』と言われる任天堂法務部が作り上げるパテントマップはこんな感じです。

『これ、特許にした方が良いの?』

スタートアップにとっては重要な問いだと思います。極端な話、無限にリソースがあれば、あらゆる発明を特許にしていけば良いかもしれません。事実、ソフトバンクの孫さんは生成AI関連の特許を数ヶ月で1万件以上出願しています(出典)。

ということで、どういう時に特許にした方が良いかという問いに答えてみます。

そもそも、特許にできるかどうかは以下の5つの要件を満たす必要があると特許法で定められています。

1. 産業上利用できる発明であること(産業上の利用可能性)
2. 新しいものであること(新規性)
3. 容易に考え出すことができないこと(進歩性)
4. 先に出願されていないこと(先願)
5. 公序良俗を害さないこと

基本的には2.新規性と3.進歩性を満たせるかどうかを調査検討することになります。本論ではないのでそれぞれの説明は割愛しますが、要するに同じ発明がまだ世にないこと、今世にある情報を元にして容易に思い付かない発明であること、が必要です。

スタートアップが特許出願を検討するとき、大前提として(少なくとも分かる範囲では)上記は満たしていることが多いと思います。その上で、時間とお金をかけてでも出願する価値があるかどうかを判断することになります。

限られたリソースの中で、優先順位を付けつつ特許化していくのであれば、以下のように整理するのが一案です。

2つの判断軸

まず一つの軸は言うまでもなく、事業におけるその技術の重要性です。競合に特許化されてしまった場合の事業への影響、反対に自社が特許化できた場合の競合優位性の大きさなどを想像することになります。
先ほどのfreeeとマネーフォワードの例における『自動仕訳機能』は、今や両者ともプロダクトや機能の数が相当増えたので相対的に重要性は下がっていそうですが、少なくとも当時においては競合に対するmoatになり得る重要な機能だったことは間違いありません。

もう一つの判断軸は、ソフトウェアに特有ですが、外から見て分かるかどうかです。仮に特許を侵害された場合、侵害された事実を証明しないといけませんが、例えば裏側のアルゴリズムの特許の場合、ソースコード等まで見ないと侵害しているかどうかが分かりません。内部リークなどがない限り、証明のハードルは相当高いと思われます。
さっきのfreeeの例では、両者とも自動仕訳機能を持っていることは間違いありませんでしたが、争点となったfreee特許の請求項では裏側のアルゴリズムを『対応テーブルを参照して』『優先キーワードを用いて』と指定していました。マネーフォワードはそれとは異なる方式で自動仕訳を行なっていたために、侵害には該当しないと判断されました。
これが、外から見てその技術/機能が侵害されていると判断できるかどうかが、ソフトウェア特許において一つの判断軸になる理由です。

※ちなみに、freee側は争点となった特許以外に機械学習による仕訳の特許も持っており、こちらで争っていればマネーフォワードの侵害が認められた可能性もありそうです。この辺の判断の難しさも外形的に判別がつかない技術ゆえです。

あえて公開/秘匿するのも戦略のうち

先ほどの2軸で四象限に分けると以下のようになります。

特許化アクションのフレームワーク

右上: 事業上重要で、かつ外形的に侵害を判別しやすい技術/機能であれば、積極的に特許出願することを検討しても良いと思います。

左上: 逆に、事業上重要ではあるものの、外から見てわかりにくいアルゴリズム等の技術であれば、敢えて出願せず秘匿するのも一案です。先ほどの例のように外形的に侵害を判別しづらいので、特許化できたとしても有効なmoatにならないこともありえます。また、当然ですが、特許出願すれば情報は公開されるので、他社に技術開発上の重要なヒントを与えることにもなりかねません。リスクとリターンのバランスをよく吟味して判断する必要があります。

右下: 事業上重要でないのであればリソースを使って特許化する必要性は低いと思います。一方で、他社に特許化されてしまうのも得策ではないため、この場合はむしろ積極的に公開してしまった方が良いです。機能リリースなどの形で公知情報となってしまえば、当然ながら他社はその機能を特許化できなくなります(新規性が否定されるため)。

いかがだったでしょうか。SaaSやToCサービスなど、競合とのキャッチアップのスピードが早い業界ほど、特許戦略を真面目に考えてみても良いかもしれません。

ではまた次回👋

【宣伝】amptalkは全ポジションで積極採用中です!

▼カジュアル面談はこちらから
▼ご応募はこちらから

この記事が気に入ったらサポートをしてみませんか?