ソフトウェア特許のフローチャート：コードロジックから §112 適合まで
アルゴリズム、機械学習パイプライン、分散システムを USPTO の Section 112 実施可能性審査に通る方法フローチャートに翻訳する実践ガイド。
結論（TL;DR）
- ソフトウェア特許が §112 実施可能性で拒絶される最大の原因は、技術力ではなくフローチャートがブラックボックス図になっており、独立した番号付き方法ステップが欠如していること。
- 適合するソフトウェア・フローチャートには 3つの必須要素 がある：順序付けされた方法ステップ、明細書の記載と紐づいた参照番号、菱形で表現された判断分岐——擬似コードを箱に詰めるのは絶対NG。
- 拒絶理由の表面が「過度な実験」「構造的詳細不足」に見えても、本質は クレームの問題に偽装された図面の問題 であることが多い。
ソフトウェア特許の生死はフローチャートに懸かる
ソフトウェア発明では、クレームが「何を所有するか」を述べ、図面が「実際に作ったこと」を証明する。35 USC §112(a) は、当業者（PHOSITA）が過度な実験なしに発明を実施できるよう明細書が記述されていることを要求する。
ソフトウェアでテキストだけがこの基準を満たすことはほぼない。アルゴリズムは文章化に弱い。30行の学習ループが「システムは損失関数に基づいてパラメータを反復更新する」と書かれた瞬間、内容は霧散する。フローチャートはこれを固定化する——入力形状、判断条件、出力型、ループ終了条件をひとつの図に可視化する。
審査官はまず図を読み、次にクレームを読む。図がマーケティングスライドに見えれば、クレームもマーケティング文句として読まれる。
ソフトウェア・フローチャートに必須の3要素
1. 独立した、番号付きの方法ステップ
各操作にはブロックを与え、各ブロックの参照番号は明細書本文に登場する必要がある。「ステップ102：入力ベクトルを受信」は実施可能性を満たす。「システムがデータを処理する」は満たさない。
実務的なルール：審査官の質問に答えるとき、図上のステップを指差せなければ、その図は失敗している。
2. 判断はif文ではなく菱形で
特許フローチャートは擬似コードではない。ANSI 標準シンボルを使う：
| シンボル | 用途 |
|---|---|
| 楕円 | 開始 / 終了 |
| 長方形 | 処理ステップ |
| 菱形 | 判断分岐 |
| 平行四辺形 | 入力 / 出力 |
| 円柱 | データストア |
審査官はこれらを一目で解釈する。コード片を箱に詰めると、彼らに翻訳作業を強いることになり、レビューが遅くなり誤読を招く。
3. システム構成図（通常 Figure 1）
ソフトウェア特許のほぼ全ては 2枚の図 が必要：システム構成図は「どこで動くか」（クラウド、エッジ、クライアント-サーバー）を示し、方法フローチャートは「何をするか」（ステップ）を示す。1枚しか出さないと拒絶の常連トリガーになる——審査官が方法を物理的・機能的環境に紐付けられない。
具体例：連合学習トレーニングパイプライン
連合学習の学習手順を出願するとする。弱い図は「ML トレーニングエンジン」と書いた長方形ひとつ。適合する図はそれを分解する：
- ステップ202 — N台のエッジ端末からローカルモデル重みを受信
- ステップ204 — 端末認証トークンを検証
-
ステップ206 — 判断：N件のレポートすべてがドリフト許容値ε内か？
- Yes → ステップ208（重み付き平均で集約）
- No → ステップ210（逸脱端末をフラグ、当該ラウンドから除外）
- ステップ212 — 新しいグローバル重みを計算
- ステップ214 — 更新済み重みをN端末にプッシュ
- ステップ216 — 判断：収束したか？継続または終了
各番号付きステップは、対応するロジックとともに明細書に登場する。審査官が「悪意ある端末をどう扱うか」と問えば、ステップ210 を指せる。「収束をどう判定するか」と問えば、ステップ216 を指せる。
これが実務における enablement の姿。
よくある失敗パターン（と検出法）
| 失敗パターン | 審査官の拒絶理由 | 修正法 |
|---|---|---|
| 単一の「AIモジュール」ブラックボックス | 構造的詳細が欠如、enablement 不足 | 4つ以上のサブステップに分解 |
| ボックス内の擬似コード | フローチャートではない | 動詞句記述に置換 |
| 明細書に番号が登場しない | 一致性の問題 | 明細書に追加 |
| システム図がない | 方法が環境を持たない | Figure 1 に構成図を追加 |
| 色分けレイヤー | 37 CFR 1.84 違反 | 白黒線画に変換 |
| 曲線・フリーハンド線 | 線幅不均一 | 直線、≥0.3 mm を使用 |
AIツールがループを変える
手作業でのフローチャート作成は歴史的にボトルネックだった：弁理士がステップを起草し、イラストレーターが Visio で清書し、ロジック1か所の変更で再度の修正サイクル。AI 特許ツールはこれを以下に圧縮する：
- 自然言語の方法記述を直接、構造化されたフローチャートに変換
- ステップ番号を自動付与し、複数図で番号を一致保持
- 欠落参照を検出（図にあって明細書にない、またはその逆）
- TIFF / PDF / SVG で出願用に出力
経済効果は実数値：6図のソフトウェア特許で、従来3〜5日のイラストレーター工数だったものが、起草・反復・出力まで 1時間未満 で完了する。
FAQ
なぜソフトウェア特許は機械特許より §112 で挑戦されやすいのか？
ソフトウェアアルゴリズムは抽象的で、曖昧に書ける。機械構造は物理的で、過小記述しにくい。よって審査官はソフトウェアに対して enablement 審査を強く適用し、図面が最も多い失敗点となる。
1枚のフローチャートでML系全体を網羅できる？
ほぼ不可能。ニューラルネット構造、学習ループ、推論パイプラインは異なる手続き上の関心事で、通常は3枚の別々の図が必要。強引に統合すると読めない巨大フローチャートになる。
システム図と方法フローチャートの両方が必要？
ソフトウェア特許ではほぼ常にYes。システム図は装置クレームの物理環境を確立し、フローチャートは方法クレームの手順を確立する。それぞれ異なるクレーム類型を支える。
各ステップはどれくらい詳細に書くべき？
明細書だけを読んだ有能なエンジニアが、そのステップを実装できるレベルで。「Transformer attention を適用」は曖昧すぎる。「次元 d_k のクエリ・キー・バリュー行列に対してスケーリング済み内積アテンションを計算」は enablement を満たす。
USPTOはAI生成のソフトウェア・フローチャートを受理する？
受理する。USPTOは図の起源を規制せず、形式を規制する。出力が 37 CFR 1.84（線画、線幅、マージン、参照番号）を満たす限り、生成ツールは問わない。
適合するフローチャートを生成する
方法記述を USPTO フォーマットのフローチャートに変換し、ステップ番号と判断菱形を自動付与：PatentFig ジェネレーターを開く。