ソフトウェア特許記載の完全攻略：方法・装置・設備・媒体の四点セット、Aliceテストとai支援生成
CNIPA.AI Team
テクノロジーブログ
ソフトウェア方法特許（IPC G06クラス）は中国発明特許出願の最大カテゴリであり、全体の32%以上を占めています。しかし、ソフトウェア特許の記載には独自の課題があります：アルゴリズムやプロセスを特許法が求める技術的解決手段に「翻訳」するにはどうすればよいか？明細書においてアルゴリズムの詳細を記述しながら「知的活動の規則」という審査の落とし穴を回避するにはどうすればよいか？本稿はCNIPA『特許審査基準』第二部分第九章、Alice/Mayoテストのフレームワーク、および実際の審査実務に基づき、直接応用できる記載戦略を提供します。
ソフトウェア特許の客体：知的活動排除を回避するための根本的論理
四点セット構造を論じる前に、ソフトウェア特許にとって最も核心的な生死線、すなわち客体適格性を理解しなければなりません。
CNIPA『特許審査基準』第二部分第九章は、コンピュータプログラムに関する発明は方法の一形態または製品の一形態とすることができるが、純粋な知的活動の規則および方法、数学的概念または数学的規則であってはならないと規定しています。
客体リスク回避の核心要件：特許請求の範囲は全体として審査されなければなりません。アルゴリズムの特徴（抽象的な情報処理ロジック）は技術的特徴（具体的なコンピュータ処理ステップ、データ形式、システムコンポーネント）と機能的相互作用関係を有していなければなりません。アルゴリズムの特徴と技術的特徴を単純に切り離し、技術的特徴部分が公知技術を構成するとして拒絶することは許されません。
実務上の判断基準：以下の種類の特許請求の範囲は通常、客体審査を通過できます：
- 「特定の種類の物理データ（画像・信号・センサデータ）を処理する方法」——処理対象が技術的である
- 「特定の物理機器（ロボット・センサ・産業用制御システム）を制御する方法」——制御対象が技術的である
- 「特定の技術的手段（ニューラルネットワーク推論・特定の暗号化アルゴリズム・特定のデータ構造操作）によって技術的問題を解決する方法」——技術的手段が具体的である
以下の種類の特許請求の範囲は通常、客体リスクがあります：
- 純粋な商業的規則または数学的アルゴリズムであって、ステップの末尾に「コンピュータ上で実行する」と付け加えているだけのもの
- 純粋に情報の内容やデータの意味を記述しており、信号またはデータの処理過程を含まないもの
- 純粋な人間とコンピュータのインタラクション設計であって、具体的な情報処理技術を含まないもの
2025年に改訂されたCNIPA審査基準は、AI/機械学習モデル構築・学習類の発明に対して明細書記載要件を新たに追加しています：モデルのモジュール、層構造、接続関係、学習ステップおよびパラメータを記載しなければなりません。これはAI/機械学習類ソフトウェア特許における重要な新規定です。
四点セットの完全構造：各部の記載のポイント
第一件：方法の特許請求の範囲（核心的保護範囲）
方法の特許請求の範囲は四点セットの中核であり、その請求の範囲は通常最も広く、特許保護範囲の主要な源泉となります。標準的な書式：
一種のXXX方法であって、
以下のステップを含むことを特徴とする：
S1：XXXデータを取得／受信するステップ；
S2：前記XXXデータに基づき、YYYアルゴリズム／モデルによって処理を行い、ZZZを得るステップ；
ここで、前記YYYアルゴリズムは具体的に以下を含む：……[具体的な技術ステップ]；
S3：前記ZZZに基づき、WWWを実行／出力／生成するステップ。
記載のポイント：ステップ番号はS1/S2/S3または「ステップ一、ステップ二」を使用する；各ステップで入力、処理ロジック、出力を明確にする；重要なアルゴリズムのステップは機能描写にとどまらず具体的な技術的手段まで詳細化する；「インテリジェントに」「自動的に」などの曖昧な副詞の使用を避ける。
第二件：装置の特許請求の範囲（機能モジュールのマッピング）
装置の特許請求の範囲は、方法のステップを機械的に機能モジュールにマッピングし、各モジュールが一つの方法ステップに対応します：
一種のXXX装置であって、
以下を含むことを特徴とする：
取得モジュール、XXXデータを取得／受信するために用いられる；
処理モジュール、前記XXXデータに基づき、YYYアルゴリズムによって処理を行い、ZZZを得るために用いられる；
実行モジュール、前記ZZZに基づき、WWWを実行／出力／生成するために用いられる。
記載のポイント：モジュールの名称は方法のステップに対応させる（取得→取得モジュール、処理→処理モジュール）；各モジュールは「〜するために用いられる」によってその機能を記述する；モジュール間のデータの流れは機能の記述の中に含意させる（「前記取得モジュールが取得したXXXデータ」）。
第三件：設備の特許請求の範囲（ハードウェアアーキテクチャの記述）
設備の特許請求の範囲は、ソフトウェアを搭載するコンピュータハードウェアアーキテクチャを保護します：
一種のコンピュータ設備であって、
以下を含むことを特徴とする：
メモリ、前記メモリにはコンピュータプログラムが記憶されている；
プロセッサ、前記プロセッサは前記メモリに接続されており、
前記プロセッサが前記コンピュータプログラムを実行すると、以下のステップが実現される：
S1：XXXデータを取得／受信するステップ；
S2：……（方法ステップの繰り返し）
第四件：記憶媒体の特許請求の範囲（CRM請求項）
記憶媒体の特許請求の範囲は、中国では「コンピュータ可読記憶媒体」（Computer Readable Medium）と呼ばれ、CN（中国）のソフトウェア特許の標準的な構成要素です（米国ではCRM claimsと呼ばれます）：
一種のコンピュータ可読記憶媒体であって、
前記コンピュータ可読記憶媒体にはコンピュータプログラムが記憶されており、
前記コンピュータプログラムがプロセッサによって実行されると、以下のステップが実現されることを特徴とする：
S1：……（方法ステップの繰り返し）
記憶媒体の特許請求の範囲は、方法の特許請求の範囲のステップを引用することで繰り返しの記載を避けながら、プログラムを記憶する物理的媒体を独立して保護します。
従属請求項の展開戦略
独立請求項は最も広い保護範囲をカバーすべきであり、従属請求項は「ここで」「具体的には」「さらに」などの限定詞によって範囲を段階的に絞り込み、同時に主請求項を支持します（「特許請求の範囲が明細書に支持されていない」という拒絶を避けるため）。
ソフトウェア特許の従属請求項の典型的な展開方向：
| 展開方向 | 具体的な記載例 | 役割 |
|---|---|---|
| 重要なアルゴリズムステップの詳細化 | 「ここで、ステップS2における前記YYYアルゴリズムは具体的に……を含む」 | 具体的な技術的手段の落とし込み |
| 入力データ形式の限定 | 「ここで、前記XXXデータは[具体的な形式／種類]である」 | 請求項範囲の縮小、安定性の向上 |
| モデルパラメータの限定 | 「ここで、前記ニューラルネットワークモデルは[具体的な構造]である」 | 具体的な実施形態の保護 |
| 応用シナリオの導入 | 「ここで、前記方法は[具体的なシナリオ]に適用される」 | 保護ポイントの拡充 |
| 好ましい実施形態の追加 | 「ここで、ステップS2はさらに……を含む」 | 明細書の実施例への支持 |
標準的な従属請求項の数：CN（中国）のソフトウェア特許では、2〜3項の独立請求項（方法、装置、記憶媒体をカバー）に加えて7〜8項の従属請求項を推奨しており、合計9〜11項として、最も一般的な10項の追加費用閾値以内に収めます。
米国ソフトウェア特許のAliceテスト：CN第25条との異同
米国のソフトウェア特許が直面する客体適格性の課題は、35 USC 101＋Alice/Mayo二段階テストです。Aliceテストを理解することは、同一発明のCN-US双方向の特許ポートフォリオ構築にとって極めて重要です。
Alice二段階テストのフレームワーク：
第一段階（Alice Step 1）：特許請求の範囲は「抽象的概念」（数学的概念、人間の活動を組織化する特定の方法、精神的プロセスを含む）を指向しているか？
第二段階（Alice Step 2A/B）：もしそうであれば、主張する解決手段を抽象的概念そのものを著しく超えた内容に変換する「発明的概念」（inventive concept）が存在するか？2019年のUSPTO改訂審査基準はこれをさらに細分化しています：Step 2A Prong 1（実践的な応用に統合されているか）およびStep 2A Prong 2（抽象的概念を超える実質的な内容を提供しているか）。
Aliceテストを回避するための記載戦略：
| 戦略 | CN（中国）の書き方 | US（米国）の書き方 |
|---|---|---|
| 具体的な技術的効果の強調 | 「XXX処理効率を向上させた」 | 「improves the technical functioning of a computer」 |
| 特定のコンピュータ実装の限定 | 具体的なプロセッサ／メモリの相互作用を記述 | 「a specific machine or manufacture」 |
| 機能的な包括的表現の回避 | 「任意のXXXを実現するための装置」を避ける | 「means for performing」を避ける |
| 具体的なデータ変換の引用 | 具体的なデータ形式変換を記述 | 「transformation of data」 |
CN（中国）とUS（米国）の核心的な相違点：CN第25条の「知的活動の規則」排除基準は、Aliceテストの「抽象的概念」排除基準と論理的には類似していますが、運用の詳細は異なります。CNはアルゴリズムと技術的特徴の「機能的相互作用」をより重視し、USは特許請求の範囲全体が「抽象的概念を超えた発明的概念」を提供しているかをより重視します。同一発明のCNとUSの出願では、独立請求項の書き方について針対的な調整が必要であり、そのまま流用することはできません。
米国のソフトウェア特許にはCN（中国）にないCRM（Computer Readable Medium）請求項の形式があり、これは米国特有の記憶媒体請求項です。米国のCRM請求項と中国の記憶媒体請求項は論理的には等価ですが、具体的な書き方の規範が異なります。
ソフトウェア特許の図面戦略：フローチャート言語とMermaid
ソフトウェア特許の図面はフローチャートを中心とします。CNIPAの図面形式要件：白黒の線図、明確な参照番号（明細書と一致すること）、文章による説明を含まないこと（参照番号と必要な技術用語のみ）。
標準的なソフトウェア特許の核心図面リスト（10項の請求項を有する特許の例）：
| 図面の種類 | 内容 | 対応する請求項 | 必要性 |
|---|---|---|---|
| 方法のフローチャート | 主要な方法ステップの実行順序 | 方法の独立請求項 | 必須 |
| システムアーキテクチャ図 | システム全体の構造 | 技術的解決手段全体 | 必須 |
| 装置構造のブロック図 | 各機能モジュールの構成 | 装置の独立請求項 | 必須 |
| サブフローチャート | 重要なステップの詳細なフロー | 従属請求項 | 推奨 |
| データフロー図 | システム内でのデータの流れ | データ処理のサブステップ | 推奨 |
| シーケンス図 | モジュール間のインタラクション順序 | 複数コンポーネントのインタラクションシナリオ | 推奨（複数コンポーネントシステム） |
| モデル構造図 | ニューラルネットワーク／AIモデルのアーキテクチャ | AI関連の従属請求項 | 必須（AI類） |
Mermaid言語はソフトウェア特許の図面を生成するための理想的なツールです。Mermaidはフローチャート（flowchart）、シーケンス図（sequenceDiagram）、状態図（stateDiagram）、クラス図（classDiagram）など多様な図表タイプをサポートしており、テキストの記述から構造化された図表を自動生成できます。AI支援生成プロセスでの使用に適しています。
AI画像生成（Stable Diffusionなど）はUI画面の概略図には適していますが、構造化されたフローチャートには適していません——フローチャートにおいては構造的な正確さ（ステップの順序、判断分岐）が視覚的な美しさよりも重要であり、Mermaidの方が適しています。
AIを活用したソフトウェア特許生成の実践フロー
CNIPA.AIのAI記載機能は、ソフトウェア方法特許の分野的特性に特化して最適化されており、CNIPA審査基準第九章と実際の審査実務データに基づき、以下の自動化フローを実現しています：
第一ステップ：技術要素の抽出——AIが技術開示書からアルゴリズムの核心ステップ、入出力データの種類、重要な技術的特徴、および考えられる客体リスクポイントを識別します。AI/機械学習技術を含む発明に対しては、AIが特にモデルの種類、学習データ、モデル構造など、2025年の新審査基準が記載を求めている情報を抽出します。
第二ステップ：客体適格性の事前検査——特許請求の範囲を生成する前に、AIが技術的解決手段に客体リスクがあるかどうかを検査し、アルゴリズムと技術的効果との間の機能的相互作用関係を確立するためにどの技術的特徴を追加すべきかを提案します。
第三ステップ：四点セットの自動生成——方法→装置→設備→記憶媒体の順に4件の特許請求の範囲を自動生成し、技術的特徴の一対一対応マッピングを確保した上で、3〜5項の従属請求項を自動的に展開します。
第四ステップ：図面の計画と生成——特許請求の範囲で識別されたステップ、モジュール、データフローに基づき、図面リスト（必須タイプ＋推奨タイプ）を計画し、構造化されたフローチャートにはMermaidを優先して使用し、UI類の図面にはAI画像生成を使用します。
第五ステップ：明細書全文の生成——技術分野、背景技術（効率・精度不足の論述ロジック）、発明の内容（技術的問題-技術的解決手段-技術的効果の三段式）、図面の簡単な説明、発明を実施するための形態（複数の実施形態を含む）の五大章節を含みます。
| 工程 | 従来の人手作業（時間） | AI支援（分） | 削減率 |
|---|---|---|---|
| 技術要素の抽出と分析 | 1〜2時間 | 5〜10分 | 約90% |
| 四点セット特許請求の範囲の記載 | 2〜4時間 | 10〜15分 | 約92% |
| 従属請求項の展開 | 1〜2時間 | 5〜10分 | 約90% |
| 図面の計画と作成 | 2〜3時間 | 15〜30分 | 約85% |
| 明細書全文の記載 | 3〜5時間 | 15〜30分 | 約88% |
| 合計 | 9〜16時間 | 50〜95分 | 約88% |
AI生成の初稿は、社内審査版（企業の出願人）または弁理士の加筆・修正のベースとなるドラフト（特許事務所）として直接使用できます。弁理士の業務の重心は記載から審査へと移行します：技術要素の抽出が正確かどうか、客体リスクポイントが識別されているかどうか、特許請求の範囲の保護範囲が企業戦略に合致しているかどうかを確認します。
ソフトウェア特許の頻出拒絶理由と対応戦略
中国のソフトウェア特許審査において最もよく見られる四種類の拒絶理由と対応戦略：
客体の問題（特許法第25条第1款第2項）：知的活動の規則および方法と認定される。対応：特許請求の範囲を修正し、具体的な技術的特徴（入力する物理信号の種類、使用する具体的なアルゴリズムモジュール、出力する技術的効果）を追加する；アルゴリズムの特徴と技術的特徴の間の機能的相互作用関係を強調する；意見書において技術的解決手段が解決する技術的問題と達成する技術的効果を説明する。
進歩性の不足（特許法第22条第3款）：アルゴリズムの改善が当該技術分野における通常の技術的手段と認定される。対応：明細書において性能比較データ（処理速度、精度、リソース消費）を提供し、データによってアルゴリズムの改善が非自明な技術的効果をもたらしたことを証明する；意見書において引用文献の技術的問題が異なること、または重要な技術的特徴が開示されていないことを指摘する。
明細書の開示不十分（特許法第26条第3款）：アルゴリズムの記述が抽象的すぎて具体的な実施の詳細を欠いている。対応：明細書に疑似コード、アルゴリズムフローの詳細なステップ記述を補充する；AI/機械学習類については、モデルの層構造、学習データの種類、パラメータを補充する；この種の問題は原出願時に答弁によって修正することはできないため、初稿の段階で必ず回避しなければならない。
特許請求の範囲が明細書に支持されていない（特許法第26条第4款）：特許請求の範囲の機能的な概括の範囲が明細書に記載されている具体的な実施形態を超えている。対応：初稿の段階で各従属請求項に対応する具体的な実施例を明細書に準備する；独立請求項の上位概念的な概括は、明細書に十分な実施例による支持があることを前提とする。
これら四種類の拒絶理由への対応戦略を習得し、AI支援による初稿生成と組み合わせることが、現代のソフトウェア特許実務における標準的なワークフローです。