この記事のポイント
ソフトウェア・プログラムの特許出願方法を解説。特許適格性の判断基準、クレームの書き方、審査対応のポイントから、オープンソースとの関係まで実務的に網羅します。
はじめに
ソフトウェアやプログラムは、適切な出願戦略を取れば特許で保護することが可能です。しかし、「プログラムは著作権で十分では？」「どこまでが特許の対象になるのか？」という疑問を持つ開発者やスタートアップは少なくありません。本記事では、ソフトウェア特許の基礎から実務的な出願テクニックまでを体系的に解説します。
ソフトウェア特許の基礎知識
著作権との違い
ソフトウェアの保護手段として、著作権と特許権にはそれぞれ異なる特徴があります。
| 比較項目 | 著作権 | 特許権 |
|---|---|---|
| 保護対象 | コード（表現）そのもの | 技術的なアイデア・仕組み |
| 登録の要否 | 不要（創作時に自動発生） | 出願・審査・登録が必要 |
| 保護期間 | 著作者の死後70年 | 出願日から20年 |
| 侵害の判断 | 実質的にコピーしたか | 同一の技術思想を実施しているか |
| 独自開発の抗弁 | 不可（ただし独立創作は非侵害） | 不可（独自開発でも侵害） |
特許はアイデアレベルで保護するため、異なるプログラミング言語で再実装されても権利行使が可能な点が最大の強みです。
日本におけるソフトウェア特許の要件
日本の特許法では、ソフトウェア関連発明が特許を受けるには以下の要件を満たす必要があります。
- ハードウェア資源との協働: CPUやメモリなどのハードウェアを利用した処理であること
- 技術的思想の創作: 自然法則を利用していること
- 新規性・進歩性: 公知技術から容易に想到できないこと
クレーム作成の実践
3つのクレームカテゴリ
ソフトウェア特許では、以下の3つのカテゴリでクレームを作成するのが一般的です。
1. 装置クレーム（システムクレーム）
プロセッサと記憶部を備える情報処理装置であって、
前記プロセッサが、
入力データを取得するステップと、
前記入力データに基づいて所定の処理を実行するステップと、
処理結果を出力するステップと、
を実行する情報処理装置。
2. 方法クレーム
処理の手順をステップとして記載します。プロセスに特徴がある場合に有効です。
3. プログラムクレーム
日本では2002年法改正により、プログラム自体を「物の発明」として出願できるようになりました。これにより、ソフトウェアの配布行為にも権利行使が可能です。
機能的記載のテクニック
ソフトウェア特許のクレームでは、機能的記載（「〜する手段」「〜する部」）を効果的に使用します。
| 記載方法 | 例 | メリット | リスク |
|---|---|---|---|
| 機能的記載 | 「認証処理部」 | 権利範囲が広い | サポート要件違反の可能性 |
| 構成的記載 | 「パスワードとトークンを照合するプロセッサ」 | 明確で安定 | 権利範囲が狭い |
| ハイブリッド | 「認証トークンに基づいて認証処理を実行するプロセッサ」 | バランスが良い | クレーム解釈に注意 |
審査対応のポイント
よくある拒絶理由と対策
- 進歩性欠如（29条2項）: 引用文献との技術的差異と効果を具体的に主張
- 発明の明確性（36条6項2号）: 機能的記載に対応する具体的な処理を明細書に記載
- 記載不備（36条4項1号）: フローチャートやシーケンス図を活用して実施可能に
オープンソースと特許の関係
OSS利用時の注意点
オープンソースライセンスの中には、特許権の行使を制限する条項を含むものがあります。
- Apache License 2.0: 特許ライセンスの付与条項あり
- GPL v3: 明示的な特許ライセンス条項を含む
- MIT License: 特許に関する明示的な条項なし
自社のソフトウェア特許戦略とOSS活用方針の整合性を事前に確認することが重要です。
SaaS・クラウドサービスの特許戦略
SaaSモデルでは、サーバーサイドの処理がユーザーの目に触れないため、侵害の検出が困難です。以下の対策が有効です。
- API仕様に着目したクレーム: リクエスト・レスポンスの構造を特定
- ユーザー端末側の処理に着目したクレーム: クライアントアプリの動作を特定
- システム全体のクレーム: サーバーとクライアントの協働処理として記載
まとめ
ソフトウェア特許は、適切な戦略を取れば強力な事業防衛手段となります。著作権だけでは保護できないアルゴリズムやビジネスロジックを権利化し、競争優位を確立しましょう。出願時には装置・方法・プログラムの3カテゴリでクレームを作成し、オープンソースとの整合性も確認することが成功の鍵です。