ソフトウェア、アルゴリズム、AIモデルは特許にできる？

ソフトウェアは特許にできるのか。ネットで調べると、「抽象的だから無理」と「ソフトウェア特許は多数あるから可能」という二つの断定的な答えが見つかります。

どちらも単純化しすぎていて、実務には役立ちません。

創業者やエンジニアにまず知ってほしいのは、特許が通常守るのはコードそのものではないという点です。書いたコードの表現は著作権で保護されます。一方、特許は技術的特徴で説明され、請求項で範囲が定められた発明を守り得ます。競合がまったく別のコードで同じ技術的特徴を実装しても同じです。

そのため、よくある 3 つの質問に対する正直な答えはすべて「時々」です。

• ソフトウェアは特許を取得できますか?時々。
• アルゴリズムは特許を取得できますか?場合によっては、それが抽象メソッド以上の一部である場合もあります。
• AI モデルは特許を取得できますか?場合によっては、請求項された発明が結果に付けられる「AI」というラベルではなく、具体的な技術的解決策である場合もあります。

「時々」では満足のいく答えではないことは承知しています。しかし、それは有用な質問につながります: 発明はどのような技術的問題を解決しますか?それをどのように解決しますか?そして特許は正確に何を主張しますか?

人々が混同し続ける 3 つのこと

これら 3 つの層は簡単に 1 つに崩れてしまいます。

コード は、作成した関数、変数名、構造、実装などの特定のソース テキストです。著作権はその表現を保護できますが、通常、同じ機能を実行する別のコードを誰かが独自に作成することを阻止することはできません。

アルゴリズムは、論理または数学的手順です。並べ替えルール、スコア公式、最適化手法、またはニューラル ネットワーク アーキテクチャは、知的に印象的で商業的に価値がある場合があります。ただし、抽象的には、数学的手法や抽象的なアイデアは通常、特許の保護から除外されます。

コンピュータ実装発明 は、技術的結果を生み出すために定義された技術システム内で動作するアルゴリズムです。それは、予測される劣化に応じてバッテリーの充電を変更するコントローラー、センサーの歪みを補正する画像処理パイプライン、通信ネットワークの混雑を軽減するスケジューリング方法などです。

通常、第 3 層は、信頼できる特許訴訟が始まるところです。コードは実装の 1 つです。本発明は、その根底にある技術的教示である。

米国では「コンピュータ上」を追加しても何も変わりません

米国では、ソフトウェアまたは AI の特許請求は、まず 35 U.S.C. に基づく特許適格主題に適合する必要があります。 101. 裁判所は、抽象的な概念、自然法則、自然現象に対して例外を設けています。つまり、抽象的なビジネス ルールに「コンピュータの使用」を追加しても、それが自動的に発明になるわけではありません。

USPTO の現在の 主題適格性ガイダンス では、とりわけ、特許請求が司法上の例外を対象としているかどうか、またその例外を実際の応用に組み込むかどうかが問われています。その AI の例では、単に数学的概念を列挙するだけの特許請求項と、それらを具体的な用途で使用する特許請求項を意図的に対比しています。

参加資格は第一関門のみです。発明は依然として新しく、有用であり、自明ではないものでなければならず、出願ではそれを適切に説明しなければなりません。特許請求は完全に「技術的」であるにもかかわらず、以前の特許または論文ですでに開示されていたために失敗する場合があります。また、アプリケーションがその機能を実現する方法を教えずにその機能を約束するため、失敗する可能性もあります。

ソフトウェアの特許性が命名法ではないのはこのためです。 「AI 搭載」、「クラウドベース」、「プロセッサによる実装」は、アプリケーションがその根底にあるエンジニアリングを説明していない限り、装飾的なものにすぎません。

欧州は貢献が技術的なものかどうか尋ねる

ヨーロッパでは異なる言語が使用されていますが、関連する実際的な課題に到達しています。欧州特許条約では、コンピューター プログラムおよび数学的手法「それ自体」は除外されます。それでも、関連する特徴が発明の技術的特徴に貢献し、技術的問題の解決に役立つ場合、コンピュータで実装される発明は特許を受けることができます。

EPO の 2026 年ガイダンスでは、AI と機械学習モデルは [本質的にそれ自体抽象的な数学的性質] であると述べています(https://www.epo.org/en/legal/guidelines-epc/2026/g_ii_3_3_1.html)。これらを使用したからといって、自動的に発明が特許対象外になるわけではありません。これらは、技術的な目的に適用される場合、または特定の技術的な実装に適応される場合に貢献できます。

EPO は有益な例を示しています。不規則な心拍を識別するために心臓監視装置で使用されるニューラル ネットワークは、技術的に貢献できる可能性があります。低レベル信号の特徴に基づいて画像、ビデオ、オーディオ、または音声を分類することも可能です。対照的に、言語的内容のみによってテキストを分類することは、自動的に技術的な目的にはなりません。

世界共通の「ソフトウェア特許」ルールはありません。それは不便ですが、製図の教訓は簡単です。さまざまな法的枠組みが理解できるように、実際のエンジニアリングを徹底的に説明することです。

違いを明らかにする 4 つの文

これらのペアを比較してください。

弱者：「AIを活用してエネルギー消費量を削減する」

この声明には目標とファッショナブルなツールが含まれていますが、発明は含まれていません。何がエネルギーを消費するのでしょうか？どの信号が観測されるのか?モデルは何を予測しますか?どの物理的な操作が変化しますか?なぜその変化は単に報告するのではなく、消費を減らすのでしょうか?

より強力: 産業用冷却システムの適応制御

システムは、温度、圧力、流量、およびコンプレッサーの状態データを受け取ります。短期的な熱負荷予測を生成します。機器の制限に従って予測を制限します。また、コンプレッサーのシーケンスを変更して、定義された温度範囲を維持しながらピーク需要を削減します。モデル、制御ループ、制約、および機器の相互作用を検索して記述できるようになりました。

弱み: 「最良のサプライヤーをランク付けするアルゴリズム」

これは商業的には役立つかもしれませんが、商業データからビジネス オプションをランク付けすることは、抽象的な意思決定プロセスにはるかに近いように見えます。

より強力: 変化する無線干渉下でのネットワーク ルーティング

この方法では、定義された間隔でチャネル状態を測定し、リンクレベルのデータから輻輳推定を生成し、遅延制約の下でルート全体にパケットを割り当て、しきい値を超えたときにルーティング テーブルを更新します。特許請求はもはや「最良の選択肢を選択する」ものではありません。それは通信システムの運用に関係しています。

どちらのより強力な例も特許が保証されているわけではありません。彼らは単にスローガンからメカニズムへの一線を越えただけであり、特許の問題が問う価値があるのはそこである。

「ニューラルネットワークを使用している」は開示ではない

AI アプリケーションには、製図に関する特定の罠があります。つまり、モデルは正確な文の中でブラック ボックスになり、そこですべての興味深い作業が行われます。同じショートカットが常に表示されます。

「モデルが最適化された出力を生成する」ということは、読者にほとんど何も伝えません。有用な草案には、以下の説明が必要になる場合があります。

• 入力が何を表し、それがどのように取得されるのか。
• 前処理と特徴の構築。
• 関連するモデル アーキテクチャまたは処理段階。
• トレーニングと推論がどのように実行されるか。
• 制約、しきい値、フィードバック、または後処理。
• アウトプットが技術システムをどのように変えるか。そして
• どの代替案が同じ技術的効果を生み出すか。

すべてのアプリケーションにソース コード、正確な重み、または完全なトレーニング データセットが必要なわけではありません。ただし、その効果が特定のデータセットの特性に依存する場合は、それらの特性を開示する必要がある場合があります。 EPOは、技術的効果を再現するために必要なトレーニングデータの特徴は、当業者が過度の負担なしに判断できない場合には説明されるべきであると特に指摘している。

同じ原則が AI の外部にも当てはまります。「自動的に」という言葉の背後にある進歩性を隠さないでください。

モデル自体が発明になり得るでしょうか?

申請者は、トレーニング済みモデルを、それを使用するシステムとは別のオブジェクトとして保護したい場合があります。これは難しいかもしれません。

モデルは、数学的パラメータ、データ構造、コンピュータ可読実装、トレーニング方法、推論方法、またはより大きなデバイスの一部として特徴付けられる場合があります。これらは互換性のある特許請求戦略ではありません。彼らの扱いも管轄区域によって異なります。

実際的には、通常、次のいずれかを説明できれば、主張はより強力になります。

• モデルの特定の技術的用途。
• 技術的な制約に適応したモデル アーキテクチャ。
• 実証可能な技術的効果を生み出すトレーニングプロセス。
• ハードウェアまたは別の技術システムの動作を改善する特定の導入。または
• メモリ使用量、処理分散、セキュリティ、遅延、リソース消費などのコンピュータ レベルの改善。

EPO の数学的手法に関するガイダンスでは、異常に具体的な例を挙げています。実装でコンピューティング プラットフォームのアーキテクチャを利用する場合、データ集約型のトレーニング ステップを GPU に割り当て、準備ステップを CPU に割り当てることが技術的特徴に寄与する可能性があります。 「AIの高速化」というのは曖昧です。改善を達成するためにハードウェアを使用する定義された方法は、はるかに便利です。

AIを使った発明では、発明者の整理も忘れない

AI に関する 2 つ目の問題は、そのテクノロジーが適格であるかどうかとは関係ありません。それは誰が発明したのかということです。

USPTO の 2025 年 11 月改訂ガイダンス では、発明者として指名できるのは自然人のみです。 AI システムはツールとして扱われ、請求項された発明を思いついた人間には通常の法的基準が適用されます。

研究または開発中に AI を使用しても、自動的に特許が妨げられるわけではありません。それはドキュメントを合理的なものにします。チームが特定した技術的問題、人々が下した決定、提案された出力が受け入れられたか拒否されたか、主張された解決策がどのように形になったかを記録してください。

特許がすべてのプロンプトの日記になってはなりません。同社は、特許請求の背後にある人間の概念をまだ説明できるはずだ。

製品名以外の検索も可能

ソフトウェア創設者は、自社の製品カテゴリの名前を検索しても何も見つからず、安心することがよくあります。不審に思うでしょう。関連する特許の先行技術では、まったく異なる市場で同じメカニズムが説明されている可能性があります。

クラウド ジョブのキュー管理手法は、電気通信で使用されるスケジューリングに似ている場合があります。不正検出機能は、産業用センサーの障害検出とアーキテクチャを共有する場合があります。レコメンデーション モデルは小売業界では斬新に見えるかもしれませんが、メディア ランキングではよく知られています。

技術的なメカニズムをいくつかのレベルで検索します。

1. 結果。 システムは何を達成しますか?
2. 方法。 その結果を生み出すシーケンスまたはモデルは何ですか?
3. アーキテクチャ。 どのコンポーネントがどのデータを交換するか?
4. 制約。 どのような技術的制限が克服されていますか?
5. その効果 より速く、より安全に、より正確に、リソースの消費が少なくなり、物理的に何が変わるのでしょうか?

Patenta を使用すると、そのメカニズムを通常の言語で説明し、管轄区域を超えて意味によって特許文書を検索できます。最も近いシステムを見つけたら、その機能を自分のシステムと比較し、白紙の文書からやり直すのではなく、その違いを構造化されたドラフトに反映させることができます。

特許データベースは先行技術の世界のすべてではありません。ソフトウェアと AI の場合、論文、標準、ドキュメント、会議資料、オープンソース リポジトリ、および初期の公開製品も重要になる場合があります。特許検索は、他に何も存在しないという約束ではなく、強力な出発点として使用してください。

何が特許に含まれるか、何が特許に含まれないかを決定する

特許はソフトウェア製品を保護する唯一の方法ではありません。

• 著作権 は、基礎となる関数ではなく、ソース コードおよびその他のオリジナルの表現を保護します。
• 企業秘密保護は、機密性を維持できるモデルの重み、内部評価方法、データクリーニングプロセス、またはサーバー側の技術に適している場合があります。
• 特許は、競合他社が異なるコードを作成した場合でも、主張された技術的方法またはシステムを保護する場合があります。

ビジネス上の問題は、開示が潜在的な権利に値するかどうかです。プロセスがサーバー上で目に見えず、外部から検出するのが難しい場合は、プロセスを秘密にしておくことがより強力な手段となる可能性があります。発明が製品、規格、API の動作、またはデバイスで可視化される場合、特許保護の価値はさらに高まる可能性があります。

答えは、外部的に意味のある技術アーキテクチャの特許を取得し、チューニング方法と運用データの機密性を保ち、コード自体の著作権に依存するという組み合わせである可能性があります。

出願書類を作る前の実践チェックリスト

ソフトウェアまたは AI の特許草案を書き始める前に、次のことを書き留めてください。

1. 技術的な問題。 ビジネス目標のみを説明することは避けてください。
2. システム コンテキスト。 関連するデバイス、サービス、センサー、プロセッサ、ネットワーク、またはストレージを特定します。
3. 処理パス 入力から技術出力までデータを追跡します。
4. 本発明の区別。 最も近い特許の従来技術では教示されていないことがここで何が起こるかを述べます。
5. 技術的効果。 運用上の改善と、主張されている機能によってどのように改善がもたらされるかを説明します。
6. 実装。 重要なステップがブラックボックスにならないように、十分な詳細を含めてください。
7. 代替案。 さまざまなアーキテクチャ、モデル、しきい値、展開の取り決めを記録します。
8. 証拠。 持っていない結果をでっち上げることなく、ベンチマーク、シミュレーション、設計推論を保存します。
9. 人間の貢献。 AI ツールが開発に参加したときの実際的な発明者としての記録を保管します。

有意義な検索と最初のドラフトを開始するには、これで十分です。この草案を見ると、説明がまだエンジニアリングではなくラベルに依存している部分が、あまり外交的ではなくてもわかります。

結論

ソフトウェア、アルゴリズム、AI モデルは、完全に特許制度の外側にあるわけではありません。また、単に新しいコードであるという理由だけで特許を取得できるわけでもありません。

最も有力な候補は具体的な技術的解決策です。システムまたは方法として説明でき、先行技術と区別でき、技術的効果に結びつけ、実装に十分な詳細を開示できるものです。

「AI を使用しています」ということから始めないでください。問題、メカニズム、そしてメカニズムが生み出す変化から始めます。

ソフトウェアやAIシステムに特許になり得る技術的発明があると思いますか？ Patentaに仕組みを記述し、最も近い先行技術を調べ、残った技術的な違いを構造化された初稿へつなげましょう。