インドのソフトウェア特許: 資格、セクション 3(k) および特許要件

ソフトウェアは、インドの特許法の下で保護できますが、それは、それが法定要件を満たしている場合に限られます。 ノベルティ、独創的なステップ、および産業への適用性「コンピュータ プログラム自体」に関するセクション 3(k) に基づく除外には該当しません。

インドは、すべてのソフトウェア関連の発明を禁止しているわけではありません。 除外は、主張されている主題が単なる抽象的なアルゴリズム、ビジネス方法、または実証可能な技術的効果のないコンピュータ プログラムである場合にのみ適用されます。 ソフトウェア主導の発明が、システム パフォーマンスの向上、データ処理アーキテクチャの強化、計算負荷の軽減、または物理デバイスの制御など、測定可能な技術的貢献を生み出す場合、特許保護を利用できます。

法的立場は、立法改正、特許庁の審査ガイドライン、および司法上の決定によって大きく進化しました。 その結果、ソフトウェアの特許資格を判断するには、次のような構造化された分析が必要です。

• 1970 年特許法に基づく法定枠組み
• 「コンピュータプログラム自体」の解釈
• 技術的影響要件
• 現在の試験練習
• 司法の前例
• 比較世界標準 (米国とヨーロッパ)
• 起草と起訴戦略

このガイドは、そのようなアプリケーションがどのように調査されるか、なぜ拒否されるのか、どのように強化できるかについての実践的な洞察など、インドにおけるソフトウェアの特許性に関する包括的な分析を提供します。

インド特許法はソフトウェアについて何と言っていますか?

インドにおけるソフトウェアの特許性は、「発明」を定義するセクション 2(1) (j) と、特定の主題を特許性から除外するセクション 3(k) との間の相互作用によって決定されます。 法的立場は、セクション 3(k) を単独で読むと理解できません。 両方の規定が一緒に機能します。

発明の定義 – セクション 2(1)(j)

セクション 2(1)(j) は、発明を新しい製品または本発明の工程を伴う工業的応用が可能なプロセスと定義しています。 これら 3 つの要件は、ソフトウェア駆動型システムを含むすべてのテクノロジに一様に適用されます。

したがって、ソフトウェア関連の発明は、最初に、新規性、独創的なステップ、および産業への適用性を満たさなければなりません。 これらの要件の範囲と司法解釈は、次の分析で詳細に検討されています。 新規、 独創的なステップ、および 産業への適用性 インドの特許法の下で。 この記事では、ソフトウェア ベースの発明に独自の影響を与える主題フィルターに焦点を当てています。

セクション 3(k) に基づく除外

セクション 3(k) は、「数学的またはビジネス的な方法またはコンピュータ プログラム自体またはアルゴリズム」を特許性から除外しています。 この規定は、ソフトウェア特許の全面的な禁止として誤解されることがよくあります。 そうではありません。

除外は、主張されている主題が単独でコンピューター プログラムに相当し、実証可能な技術的貢献がない場合にのみ適用されます。 純粋なアルゴリズム、抽象的な計算ロジック、およびソフトウェアによって実装されるビジネス手法は、通常、この除外に含まれます。

解釈上の重要性は、2002 年の修正によって導入された「それ自体」という言葉にあります。 これらの言葉を追加する法的意図は、コンピュータ プログラム自体は特許を取得できないものの、より大きな技術システムの一部としてコンピュータ プログラムを組み込む発明が適格である可能性があることを明確にすることでした。

実際には、抽象的な計算または財務自動化のみに向けられた主張は、セクション 3(k) の異議を引き付ける可能性があります。 対照的に、処理効率の向上、ネットワーク パフォーマンスの改善、リソース割り当ての最適化、物理デバイスの制御など、測定可能な技術的改善をもたらすプロセッサ実装システムは、さらに検討を進めることができます。

ソフトウェアの特許性の 2 層構造

インドのソフトウェア発明は、階層化された分析によって効果的に評価されます。 第 1 層は、セクション 3(k) に基づく主題の適格性に関するものです。 本発明が単なるコンピュータ プログラムであるか、または専門用語に偽装されたビジネス方法である場合、調査はこの段階で終了します。

本発明がこのしきい値を生き延びた場合、第 2 層には、セクション 2(1)(j) に基づく標準的な特許性基準が含まれます。 セクション 3(k) フィルターを通過した後でのみ、アプリケーションは実質的な調査に移行します。

この構造は、ソフトウェア関連のファイリングにおいて起草がしばしば決定的な理由を説明しています。 発明は技術的に革新的かもしれませんが、ソフトウェア ロジックによって達成される技術的ソリューションではなく、ソフトウェア ロジックを分離する方法で主張されていれば失敗します。

法定の位置 要約

インドの特許法は、ソフトウェア特許を禁止していません。 技術的な貢献のない抽象的なプログラムまたはアルゴリズムに限定された主張のみを除外します。 ソフトウェア ベースの発明が技術的な問題に対する技術的解決策を提供する場合、特許性は、法律の一般的な基準の下で検討することができます。

インド特許庁がソフトウェアと AI の発明をどのように扱うか

ソフトウェア中心の発明は、通常、 を通じて検討されます セクション 3(k) インド特許法には、「数学的またはビジネス的方法またはコンピュータ プログラム自体またはアルゴリズム」を除外しています。 実際には、調査の焦点は、ソフトウェアのみの存在ではなく、主張されている主題がそうであるかどうかです。 のみ プログラム/アルゴリズム/ビジネス方法、または本発明がフレームに組み込まれてサポートされているかどうか 技術的な問題に対する技術的解決策。

インドの特許庁の観点から、クレームと仕様が証明する場合、ソフトウェアの発明は特許保護を考慮される可能性が高くなります。 技術的な貢献 コンピュータ システム、ネットワーク、デバイス、または産業プロセスの機能の具体的な改善など、抽象的な処理を超えて。 「技術的効果」分析は、通常、システム アーキテクチャ、大規模なデータ処理、信号処理、デバイス制御、リソース最適化、待ち時間短縮、セキュリティ メカニズム、またはコンピューティングまたはハードウェア操作に関連するその他の測定可能な改善などの機能に反映されます。

インド特許庁も コンピュータ関連発明 (CRIS) の調査に関するガイドライン、2025 年これは、コンピュータ プログラム自体、ビジネス方法、および AI/ML 関連の主張にアプローチする方法についてコントローラーを導きます。 これらのガイドラインは、法律、規則、および進化するインドの判例法に沿って適用されます。 セクション 3(k) の詳細な取り扱いには、クレーム形式の戦略、例、およびコントローラー スタイルの推論が必要なため、セクション 3(k) (ここからリンク) の専用記事では、実用的な「ハウツー」を詳しく説明しますが、この柱は全体的な特許性に関するマスター ガイドのままです。

本発明にソフトウェア/AI 要素がある場合、セクション 3(k) のリスクを取り除くための最速の方法は、クレーム ファーストの適格性チェックであり、各要素をテクニカル エフェクトと仕様サポートにマッピングしてファイリングする前にマッピングします。

インドの裁判所がソフトウェアの特許性について明確にしてきたこと

司法解釈は、セクション 3(k) の範囲を明確にする上で決定的な役割を果たしてきました。 法律は「コンピュータ プログラム自体」を除外していますが、裁判所は、この除外を機械的に適用できないことを一貫して強調してきました。 クレームされた発明の技術的貢献に焦点を当てなければなりません。

技術的影響は、統治原則です

Ferid Allani v. Union of India 事件において、デリー高等裁判所は、セクション 3(k) に基づく法廷弁護士は、コンピュータ プログラムにのみ適用されることを明らかにしました。 それ自体 また、ソフトウェアを組み込んだすべての発明に向けたものではありません。 裁判所は、人工知能やデジタル システムを含む現代の技術革新は、多くの場合、ソフトウェア主導であることを認識していました。 コードが関係しているという理由だけでそれらを拒否することは、技術の現実と矛盾します。

裁判所は、コンピュータベースの発明が、 技術的効果または技術的貢献、ソフトウェアを介して実装されているという理由だけで除外することはできません。 この決定は、インドの特許法学における技術的効果の教義を大幅に強化しました。

ハードウェアは必ずしも必須ではありません

Accenture Global Services GmbH v. Assistant Controller of Patents では、法律は、特許を取得できるようにするために、ソフトウェアに新しいハードウェアの変更を必要としないことが明らかになりました。 特別なハードウェアの適応がなくても、セクション 3(k) が自動的にトリガーされるわけではありません。 本発明が技術的進歩をもたらすかどうかは、決定的な問題が残る。

この解釈は、「それ自体」という言葉の挿入の背後にある法的意図と一致しています。 除外は抽象的なプログラムに向けられていますが、コンピューターで実装された発明ではありません。

ビジネス方法は除外されます

同時に、裁判所と上訴当局は、ビジネス方法を専門用語で起草するだけでは特許を取得できないと主張してきた。 Yahoo v. Controller of Patents では、ターゲットを絞った広告メカニズムに向けられたクレームは、テクノロジーに具現化されたビジネス方法として扱われました。 ソフトウェアの実装は、本発明の本質的な特徴を変えるものではありませんでした。

この原則は、重要な境界を強化します。技術的な実装は、ビジネス アイデアを技術的発明に変えません。

技術システムに統合されたアルゴリズム

Telefonaktiebolaget LM Ericsson v. Lava International Ltd. において、裁判所は、アルゴリズムについて言及しただけでは発明が特許を取ることができないと述べました。 アルゴリズムがより大きな技術システム内で動作し、実用的な技術的成果に寄与する場合、セクション 3(k) は自動的に適用されません。

このアプローチは、CRI ガイドラインの下での試験の実践と密接に一致しています。 調査とは、本発明の範囲内にソフトウェアが存在するかどうかではなく、特許請求の範囲に記載されている発明が技術的な問題に対する技術的解決策を提供するかどうかです。

合同司法の地位

司法の前例をまとめると、次の 4 つの指針が確立されます。

第 1 に、セクション 3(k) に基づく除外は狭く、コンピュータ プログラム自体にのみ適用されます。
第二に、技術的効果または技術的貢献が適格性の決定要因です。
第三に、ソフトウェアを介して実装されたとしても、ビジネス方法は除外されます。
第 4 に、アルゴリズムの存在は、技術システムに統合された場合に特許性を自動的に妨げるものではありません。

これらの原則は、解釈の安定性を提供し、インドの法律が形態ではなく実体を評価することを強化します。

セクション 3(k) の拒否を回避するためにソフトウェアの特許を起草する方法

ソフトウェア関連の発明では、適格性は、多くの場合、根底にあるイノベーションよりも、本発明がどのように構成され、構造化され、主張されているかに影響を与えます。 セクション 3(k) は主題フィルターとして機能するため、アプリケーションが実質的な調査に進むかどうかを決定する際には、起草戦略が決定的な役割を果たします。

技術的な問題と技術的解決策に焦点を当てます

すべてのソフトウェア特許出願は、明確に明確にする必要があります 技術的な問題 および対応する テクニカル ソリューション. 仕様は、ソフトウェアが機能的またはビジネス上の用語で何をするかを単に説明するべきではありません。 本発明がコンピュータ システムの機能をどのように改善するか、または技術的環境内で技術的な問題を解決するかを説明する必要があります。

たとえば、「顧客のオンボーディングの自動化」に向けられたクレームは、ビジネス方法として特徴付けられるリスクがあります。 対照的に、新しいメモリ割り当て手法によって認証の待ち時間を短縮する特定のプロセッサ レベルのアーキテクチャを定義する主張は、技術的な貢献に重点を置きます。

違いは、商業的利点ではなく、測定可能な技術的改善を特定することにあります。

ロジックだけでなく、システム アーキテクチャを定義します

セクション 3(k) の精査を生き延びたアプリケーションは、通常、次のように説明します。

• 関連するシステム コンポーネント。
• ハードウェアとソフトウェアの要素の間の相互作用。
• データ フローと処理シーケンス。
• パフォーマンスが技術的に強化される方法。

「命令を実行するように構成されたプロセッサ」などの一般的な朗読は、クレームされた命令自体が技術的な効果を生み出さない限り、不十分です。 審査官は、アーキテクチャがシステム パフォーマンスまたは技術運用に有意義に貢献するかどうかを評価します。

測定可能な技術的効果を示します

CRI の枠組みと司法の前例は、一貫して技術的効果を強調しています。 したがって、アプリケーションは、どのような技術的改善が達成されるかを明確に説明する必要があります。 これには、処理効率の改善、リソース消費の削減、プロトコル レベルでのセキュリティの強化、通信の信頼性の向上、またはハードウェア制御の最適化などがあります。

この説明では、改善がどのように達成されるか、どのような技術的パラメーターが影響を受けるかを指定せずに、「効率を向上させる」などの抽象的なステートメントを避ける必要があります。

Pure Automation としてのフレーミングは避けてください

拒絶されることが多い原因は、既存の手動または商用ワークフローの自動化としての発明の提示である。 高度なコードによって実装されたとしても、管理プロセスまたは財務プロセスの自動化がビジネス メソッドの除外に含まれる可能性があります。

主な貢献がトランザクション管理ロジック、価格設定戦略、または顧客のセグメンテーション ルールの最適化にある場合、アプリケーションは、貢献がビジネスの推論ではなく、技術的な実装にあることを証明する必要があります。

十分な技術的開示を確保してください

資格を超えて、仕様は十分な技術的詳細を提供する必要があります。 アーキテクチャの説明のない高レベルの機能言語は、セクション 3(k) だけでなく、明確さと十分性の規定の下でも異議を唱える可能性があります。

よく描かれたソフトウェアの特許明細書には、通常、次のものが含まれます。

• システム コンポーネントの詳細な説明。
• フロー図またはアーキテクチャ図。
• シーケンスの処理;
• 発明の影響を受ける技術的パラメータ。
• 技術的バリエーションを示す代替実施形態。

このレベルの開示は、適格性と独創的なステップ分析の両方をサポートします。

実際の観察

実際には、テクニカル アーキテクチャを明確に定義し、システム コンポーネント間の相互作用を指定し、測定可能な技術的改善を明確にするアプリケーションは、セクション 3(k) のしきい値を超える可能性が高くなります。

逆に、高度な抽象化に基づいた主張、特に金融論理、データの分類、または管理処理に焦点を当てた主張は、多くの場合、初期の反対意見を引き付けます。

中心的な原理は一貫しています。本発明は、技術的な問題に対する技術的な解決策を提示する必要があります。 仕様とクレームの両方でその接続が明白な場合、セクション 3(k) を克服する可能性が大幅に高まります。

一般的な理由 インドでは、ソフトウェアの特許出願が却下されます

インドの多くのソフトウェア関連の特許出願は、主題の段階自体で異議を唱えています。 多くの場合、拒絶は目新しさの欠如から生じるのではなく、セクション 3(k) に基づく適格性のしきい値を満たさないことから生じます。

一般的な拒否パターンを理解することは、申請者が主張と仕様をより効果的に構成するのに役立ちます。

本発明は、純粋なアルゴリズムとして構成されています

主に計算ロジック、式、または数学モデリングに焦点を当てたアプリケーションは、すぐに異議を唱えることがよくあります。 主張された貢献が技術システムに統合されずに抽象的なアルゴリズムに完全に存在する場合、それ自体がコンピューター プログラムとして扱われる可能性があります。

専門用語が存在するだけでは、この評価は変わりません。 審査官は、使用される語彙ではなく、主張の内容を評価します。

主な貢献はビジネス方法です

本発明が財務処理、マーケティング戦略、リスクスコアリング、トランザクション ルーティング、または顧客管理システムに関連する場合、多くの拒否が発生します。 技術的な実装が単に商業的ルールまたはビジネス ロジックを実行するだけである場合、本発明は、セクション 3(k) に基づく「ビジネス方法」の除外に該当する可能性があります。

ハードウェア要素を追加したり、メソッドを「コンピュータ実装」として提示しても、ビジネス アイデアが技術的発明に自動的に変換されるわけではありません。

明らかな技術的影響はありません

技術的パラメーターを指定せずに、効率の向上やパフォーマンスの向上など、一般的な利点を述べると、しばしば異議が生じます。 審査官は、処理時間の短縮、ネットワーク スループットの向上、メモリ使用量の最適化、プロトコル レベルでのシステム セキュリティの強化、または物理デバイスの制御の改善など、測定可能または識別可能な技術的成果を求めます。

仕様がクレームされた機能を具体的な技術的改善に結び付けていない場合、適格性の問題が発生します。

一般的なハードウェアの朗読

もう 1 つの一般的な問題は、プロセッサー、サーバー、またはメモリー ユニットなどの一般的なコンポーネントが、技術的に意味のある方法でどのように相互作用するかを示していないことです。 ハードウェアが単に命令の定期的な実行を実行するだけである場合でも、本発明は、それ自体がソフトウェアとして特徴付けられる場合があります。

正式な請求構造ではなく、技術的な貢献に重点が置かれています。

高レベルの機能的主張

システム アーキテクチャ、処理ステップ、またはコンポーネント間の相互作用を定義せずに、幅広い関数型言語で起草された主張は、抽象化に対する反対意見を引き付けることがよくあります。 本発明が技術的メカニズムではなく、望ましい結果の観点からのみ説明されている場合、拒絶のリスクが高まる。

データ フロー、システム構成、および技術処理ロジックを明確に表現すると、このリスクが大幅に軽減されます。

実用的な考慮事項

実際には、多くのセクション 3(k) の異議が最初の試験報告書で提起されます。 構造化された技術的な物語を提示するアプリケーションは、建築の詳細と測定可能な改善によってサポートされており、適格段階を超えて実質的な調査に移行する可能性が高くなります。

ソフトウェア特許の適格性は、発明がどのように構成され、どのように主張されているかに大きく依存するため、出願前に技術的な貢献とクレーム アーキテクチャを評価することで、潜在的なセクション 3(k) の脆弱性を早い段階で特定することができます。

インドでのソフトウェア特許取得のタイムライン

ソフトウェア関連の特許出願の手続き枠は、特許法および特許規則に基づく他の技術と同じです。 このようなアプリケーションでの主要な課題は、セクション 3(k) の下で発生することがよくありますが、法定のタイムラインは構造化され、期限切れのままです。

各段階の詳細な説明は、 インドでの特許出願プロセス. 文脈については、重要な法定マイルストーンを以下にまとめます。

タイムラインの概要

手続き構造は均一ですが、ソフトウェア アプリケーションは、最初の試験報告段階で主題に異議を唱えることがよくあります。 セクション 3(k) の問題が起訴中に取り扱われる方法は、全体的なタイムラインに大きな影響を与えます。

真の境界: 技術革新と抽象コード

インドにおけるソフトウェアの特許性は、発明がプログラミングを伴うかどうかによって決まるものではありません。 これは、本発明が a を提供するかどうかによって決定されます 技術的な問題に対する技術的解決策。

セクション 2(1)(J) および 3(k) では、CRI のガイドラインと司法の前例とともに、構造化されたしきい値を確立します。 抽象的なアルゴリズム、ビジネス ロジック、および単独で主張されているコンピューター プログラムは除外されます。 ただし、明らかに技術的パフォーマンスを向上させ、システム アーキテクチャを最適化し、ハードウェア インタラクションを強化するか、測定可能な技術的成果を生み出すソフトウェア駆動システムは、引き続き検討対象となります。

区別はセマンティックではありません。 それは実質にあります。

主張された貢献が計算の抽象化にある場合、セクション 3(k) に基づく異議が出る可能性があります。 本発明が技術的システムの機能を改善する場合、特許性は未開のままであり、新規性、独創的なステップ、および産業上の適用性に左右される。

実際には、適格性は、技術的貢献がいかに明確に特定されているか、また、クレームがその貢献をどの程度正確に反映しているかを明らかにすることがよくあります。 除外と保護の境界は、ソフトウェアの存在ではなく、技術の進歩の存在によって定義されます。

アドバイザリーノート

ソフトウェア主導のイノベーションが戦略的なビジネス資産である場合、出願前に技術的貢献と主張のアーキテクチャを評価することで、セクション 3(k) の異議を予測し、審査段階での適用を強化することができます。

インドのソフトウェア特許に関するよくある質問