ソフトウェア利用発明
(01/06/02改訂）
ソフトウェア利用発明の明細書の書き方も、他の分野と基本的には同様ですが、ソフトウェア関連発明の特許はその特殊性から難しいと考えられている面があるようです。
今回は、ソフトウェア関連発明の捉え方・明細書の作成方法等をその特殊性に応じて説明し、特許法上でのソフトウェアの位置づけを検討したいと思います。
なお、本書は、特許庁から平成１２年１２月２８日に出された、特定技術分野の審査基準（コンピュータ・ソフトウエア関連発明）に沿ったものです。
明細書が、以下の３つの工程に従って作成されることは、ソフトウェアにおいても同様です。
■発明情報の収集工程（入力）
■発明の分析工程 （分析）
■明細書作成工程 （出力）
＜発明情報の収集＞
ソフトウェアの分野は、新しい分野であってしかも特許になじみが少ないためか、ソフトウェアを発明として捉えることに不慣れな方が多いようです。そこで、どのようにすれば「発明」をすることができるか。できたとしてもどのようにそれを見い出すかが問題となります。この点から、ソフトウェア発明に意識を向けること、日常業務の中からソフトウェア発明を抽出することが必要となるでしょう。
ソフトウェア関連発明の発現形態も、一般の発明と同様ですが、ソフトウェア関連発明では、何が発明であったのかを評価しずらいという特性があるので、発明の抽出作業が重要となります。また、プログラム開発委託契約などが開発に絡む場合もあり、そのような場合、開発に伴う権利関係を明確にしておく必要があります。
ソフトウェア開発者は通常、「自然法則を利用した技術的思想の創作のうち高度のもの」（特許法第２条①）を創作しようとか、創作したという意識がないのが通常です。なぜなら、プログラム開発者は、公知のプログラム言語、開発モジュール等を使用し、通常公知のハードウェア資源を利用してシステムを構築するのが通常で、何らかの思想を具現化したという実感を伴わないからです。
従って、特許的な目を通じて、ソフトウェア発明として自己の開発したプログラム等を見直す必要があります。
☆その場合、総論で述べたと同様に「発明を発見する」という感覚でプログラム等を見直すのが、よいと言えます。
では、どうすれば「発明を発見」できるかです。
前に述べたように、ソフトウェア発明は、機能・作用を中心に発明の構成が特定されます。この点が他の分野の発明と大きくことなり、ソフトウェア発明の特質となっています。
そこで、ソフトウェア発明を抽出するには、最小単位の「機能」でくくっていくことにより、「機能実現手段」あるいは「手順」を認識していくことが必要となります。
この認識された「機能実現手段」自体が新しい機能を提供するとき、その部分を特徴とした発明が認識されますが、ソフトウェアの場合通常、個々の「機能実現手段」自体は公知である場合が多いかもしれません。しかし、それら公知の「機能実現手段」を複数組み合わせることで、新たな機能を生じるのであれば、それをもって発明として認識することが可能です。ここでも、「権利一体の原則」により、「機能」＝「構成」の組み合わせを選択することで容易に発明が可能となるのです。
これら発明の発掘は、たとえば、プログラム開発のシステム設計書を作成しながら行うと良いでしょう。
＜ソフトウェアの開発工程と発明＞
ソフトウェアにつき例えば以下のような開発工程であったとします。
１） 要求定義
２） 基本設計
３） 詳細設計
４） コーディング
５） テスト
６） 運用・保守
このソフトウェア開発工程でどのように発明を発見するかが問題となります。ソフトウェア関連発明においても、発明を発見するためには「機能」を発見すればよいことは同様です。前に述べたように、ソフトウェア発明は、機能・作用を中心に発明の構成が特定されます。この点が他の分野の発明と大きくことなり、ソフトウェア発明の特質となっています。
そこで、ソフトウェア発明を抽出するには、最小単位の「機能」でくくっていくことにより、「機能実現手段」あるいは「手順」を認識していくことが必要となります。
この認識された「機能実現手段」自体が新しい機能を提供するとき、その部分を特徴とした発明が認識されますが、ソフトウェアの場合通常、個々の「機能実現手段」自体は公知である場合が多いかもしれません。しかし、それら公知の「機能実現手段」を複数組み合わせることで、新たな機能を生じるのであれば、それをもって発明として認識することが可能です。
☆新たな機能が存在するところに必ず発明あり、ということです。
このような「機能実現手段」を注出するため、具体的には、前記した開発工程の中で、明細書作成に必要な情報として、以下の情報を抽出する必要があります。
〔１〕要求定義の過程で作成したソフトの目的、機能、性能、環境などの決定事項を記載したドキュメント
〔２〕基本設計の過程で作成したドキュメント類、特に、プログラム用ドキュメントとしてのフローチャート、このフローチャートによるソフト実行の動作説明を特にソフトの特徴的機能を必ず網羅するように記載
〔３〕プログラム・リストは必要なし。
〔４〕出願しようとするソフトについて機能・仕様の変更がある場合は、その変更箇所を示すドキュメント
〔５〕 その他、ソフトウェアによる情報処理手段として用いられる場合等、ソフトを利用した具体例を少なくとも一つ挙げることが望ましい。
〔６〕ソフトが実現する機能を、一つずつ機能ブロック図として表現する。各機能ブロックがコンピュータのどの部分で実現されるのかも示すとよい。
以上の観点からすれば、基本設計（アイデア）段階で発明の認識が可能であり、明細書を作成することができます。この段階で出願を検討するのがよろしいでしょう。
次に、ソフトウェア関連発明は、
①研究テーマを掲げ、その結果生まれる発明（開発部における発明）
②他社からのシステム開発依頼に基づく発明
である場合が多く、
③改善提案制度による発明（従来型ＱＣ運動、あるいは発明啓蒙キャンペーン等の中から生まれる発明）
の場合は少ないようですが、最近は趣味的にコンピュータに精通しシステムあるいはプログラム開発を行って、職場の業務改善を行う者も増えているようですので、③の場合の発明もあり得ます。
ソフトウェア関連発明では、上記いずれの場合でも、何が発明であったのかを評価しずらいという特性があるので、発明の抽出作業が重要となります。
また、上記②の場合、プログラム開発委託契約などにおいて、開発に伴う権利関係を明確にしておく必要があります。
＜開発現場でのソフトウェア関連発明の発現形態＞
ソフトウェア関連発明が、ソフトウェアの開発現場でどのように発現・認識されるのかを予め知っておくことは、ソフトウェア関連発明を把握し、発掘し、さらに明細書を作成するにあたって、極めて重要です。
ソフトウェア関連発明をどのように捉えるかにあたっては、「ハードウェアとの関連を重視する」と発明を捉えやすいので、そのような観点からソフトウェア関連発明を分類してみますと以下のようになります。
(1) 外在的ハードに対するコンピュータ制御
(2) 内在的ハードに対するコンピュータ制御
(3) 見かけ上ハードに依存していないソフトウェア
として発現する場合があります。
このような分け方で捉えると、実際に目で見え、観念しやすいハードを通じて、ソフトウェアを捉えることができるので、発明を把握しやすいということと、ソフトウェア関連発明が、ハードウェアとの関連の程度でその特許性が認められるようになって来たという歴史的背景にマッチするという２つの点でメリットがあります。特に後者については、後記する産業上利用できる発明として明細書に記載しやすくなるというメリットがあります。
ただし、(1)と(2)については、ハードが明確に存在するので、制御対象に対して何をしているのか？という観点から発明の構成（特徴点）を捉えることが比較的容易にできますが、(3)の場合は、どのような構成を備えているのかなかなか捉えにくいという特徴があります。
しかし、いずれの場合でも、「機能」からその構成を特定していくことで、発明の全体が見えてきます。
以下、これらを説明します。
■外在的ハードに対するコンピュータ制御
例えば、「エンジンのコンピュータ制御」や「製造ラインのコンピュータ制御」など、すでに外部に制御対象が存在し、その制御対象についてコンピュータで制御するものです。このような発明は、発明の特徴点が理解しやすいのが通例です。すなわち、対象のハードが明確で、そのハードに対しどのような制御を行っているのかを理解すればよいからです。また、ハード自体新しく開発された場合が多いでしょう。このような発明では、外在するハードを機械の明細書のように特定し、それら機械的構成にコンピュータによりどのような制御を行っているかを記載すればよいでしょう。また、制御対象であるハードが存在するので、自然法則利用性が否定されることもないでしょう。
■内在的ハードに対するコンピュータ制御
例えば、「仮想記憶方式」や「メモリ管理方式」、「パイプライン処理」など、コンピュータ内部における処理に特徴を有する発明では、コンピュータのハード自体には特徴がなく、その処理の仕方に特徴がある場合ですので、発明の特定が若干容易でないという側面があります。
しかし、そのソフトウェアの行っている機能が、コンピュータ上でどのように実現されているかを見つめれば、処理の対象であるハードが見えてくるので、あとは比較的容易に発明の特定が容易となります。また、この場合もハードが存在するので、自然法則利用性が否定されることはないでしょう。
■見かけ上ハードに依存していないソフト
制御対象としてハードが存在せず、処理の内容がもっぱら何らかの演算であったりすると、その処理内容の中にハードウェアが意識されない場合があります。
例えば、円の描画方法、かな漢字変換方法、カーソル制御方法、などでは、ハードを制御しているという意識はかなり薄くなります。よって、発明を捉えずらく、また、表現もしにくい場合が多くあります。このようなソフトウェアの場合、できるだその機能に着目し、その機能がコンピュータ上どのように実現されていくのかを考えることで、特定が可能となっていくように思えます。また、この種の発明では、自然法則の利用性が否定される可能性もあるので、表現には注意を要します。
以上のような捉えかたは、特許法上（審査基準上）認められる発明の概念とは異なる切り口です。そこで、上記のように捉えた発明を明細書に記載し、特許請求の範囲に特定する上で、特許法上（審査基準上）保護される発明の概念との整合性を確保する必要があります。
そこで、２０００年１２月２８日に発表された、特定技術分野（コンピュータ・ソフトウェア関連発明）の審査基準を参照しつつ、説明したいと思います。
＜発明の種類＞
上記のように、ソフトウェア関連発明を、
(1) 外在的ハードに対するコンピュータ制御
(2) 内在的ハードに対するコンピュータ制御
(3) 見かけ上ハードに依存していないソフトウェア
が分けましたが、
これらはそれぞれ、特許法上では、
① 方法の発明
② 物の発明
に分けられ、
さらに、審査基準では、
③ 物の発明に属するものとして、「媒体発明（プログラムを記録した記録媒体）」が認められ（１９９７年４月１日以降）、「プログラム発明」も認められております（２００１年１月１０日以降）。
また、特に審査基準等では言及されておりませんが、
④ 方法の発明に属するものとして、物を生産する方法のソフトウェア関連発明も当然存在します。
すなわち、物の生産のためのソフトウェアであって、前記審査基準いう方法のカテゴリーに該当する発明であれば、それは物を生産する方法として捉えることができます。
以上に加え、ソフトウェア関連発明で特に多いのは、実務上認められ、特許法上は装置発明とみなされる、
⑤ また、方式（システム）発明が存在します。
方式とは何かについて具体的な定義はありませんが、通常、発明の構成要素が、空間的に２ヶ所以上にまたがるとき、これをシステムとして捉えることが多いようです。
例えば、銀行における預貯金確認システムとして、
「各支店あるいは顧客に設置した端末と、本店に配置したホストコンピュータと、前記端末とホストコンピュータとを接続するネットワークとを備え、
前記端末は、口座番号を入力する口座番号入力手段と、
前記口座番号入力手段で口座番号が入力された後にホストコンピュータにアクセスを可能にする識別符号を入力する識別符号入力手段と、
この識別符号入力手段で入力された識別符号が前記口座番号入力手段で入力された口座番号に対応して予め設定された識別符号に一致するか否かを判定し一致したときにホストコンピュータと端末とを接続する通信手段と、
を有し、
前記ホストコンピュータは、前記端末からの要求に応じて、前記口座番号の口座ファイルを検索するファイル検索手段と、
ファイル検索手段で検索されたファイル内容を前記端末に前記ネットワークを通じて送信することを特徴とする預貯金確認システム。」
このようなシステム発明の場合、構成要素が、前記例では銀行とその取引上の顧客等、複数の主体にまたがることが多く、その結果、その主体が実施しても特許発明の直接侵害とならないこととなり、間接侵害しか成立しないので、権利保護の実効性が弱いという欠点があります。
上記の場合、端末を販売する者は直接侵害者として訴求できません。もし、特許法１０１条の「のみ」に該当する場合は間接侵害となりますが、端末が、他の機能を有し、前記預貯金確認用以外の用途にも使用できるなら、間接侵害となりません。特に端末自体、パーソナルコンピュータであったりすると、他の用途に十分使用できるので、侵害訴訟の場合不利です。
従って、各構成要素からシステムを見込んで発明を捉えることが重要でしょう。
例えば、上記例に
「本店に配置したホストコンピュータに、ネットワークを介して接続される預貯金確認用端末であり、
口座番号を入力する口座番号入力手段と、
前記口座番号入力手段で口座番号が入力された後にホストコンピュータにアクセスを可能にする識別符号を入力する識別符号入力手段と、
この識別符号入力手段で入力された識別符号が前記口座番号入力手段で入力された口座番号に対応して予め設定された識別符号に一致するか否かを判定し一致したときにホストコンピュータと端末とを接続する通信手段と、
を有し、
前記通信手段で前記ホストコンピュータに送信した要求に応じて、前記口座番号の口座ファイルから得られたファイル内容を前記ネットワークを通じてホストコンピュータから受信することを特徴とする預貯金確認用端末。」
とすれば、端末を販売する者を直接侵害者として訴求できます。
＜コンピュータ・アーキテクチャとソフトウェア関連発明の発現形態＞
ソフトウェア関連発明は、既存のハードウェア（コンピュータ）の上で動くものです。従って、発明を把握するとともに、産業上利用可能性を満足する発明として明細書に記載する上で、開発したソフトウェアがコンピュータのハードすなわちアーキテクチャにどのような関わりをもっているのかを認識しておくことは重要です。
特に、■内在的ハードに対するコンピュータ制御の発明、■見かけ上ハードに依存していないソフトウェアについては、コンピュータ・アーキテクチャとの関連を示すことで、より特許性を出しやすくなります。
＜先行技術情報＞
発明に関する情報とは、発明自体の技術内容のみならず、先行技術が何かということも含まれます。
先行技術との関係では、特に、新規性と進歩性が問題となります。ソフトウェア関連発明が特許されるために新規性・進歩性を有しなければならないのは他の発明の場合と同様で、これら判断は、機能・作用の異同を中心に行われます。
＜ソフトウェアと新規性＞
ソフトウェアの開発過程においては、新規性に関連して以下の点を注意する必要がありましょう。
①開発前のマーケティング段階
プログラム開発前に、自らの企画しているソフトウェアが、市場の要求を満たす機能を実現しているのか調査する場合があります。
このような場合、調査の仕方によっては開発しようとしているソフトウェアの内容が不特定多数に知られる場合があるので注意を要します。
②いわゆるベータ版の配布
開発が一応終了し、ベータ版が完成し、ビジネスショウなどで公表した場合、その機能が開示される限り、新規性は喪失したとされると思われます。
③CD-ROM等によるプログラムの配布とHELP機能
CD-ROM等によりプログラムが配布された場合、そのような媒体は「刊行物」といってよく、新規性喪失の要因となるとみてよいでしょう。また、HELP機能はソフトウェアの機能を説明していることが多いので、その限りでソフトウェアの新規性を喪失させるものといってよいでしょう。
＜ソフトウェア関連発明の進歩性＞
ソフトウェア関連発明の進歩性については、審査基準2.3項に詳しいのでこれを参照して下さい。
ソフトウェア発明は、「機能」を命とするもので、その機能を実現するために、既存のプログラム言語を使用し、既存のプログラム開発モジュールを使用するのが通常です。そして、上記のように機能を開示しただけで、新規性を失う可能性が大きいと思われます。
このような点を考慮すると、出願されたソフトウェア関連発明であって、単に機能実現手段を特定しただけのクレームである場合、すでに同一機能のソフトが市販されているなら、その存在をもって、拒絶すべきものといえましょう。
但し、機能を実現するためのアルゴリズム自体が新規であり、そのようなアルゴリズムを用いた機能実現手段としてクレームを限定するならば、公知のソフトに同一機能が単に存在するからといって、拒絶されるものではないでしょう。
このような、新規性・進歩性は、発明分析の後、どの構成をもって特許請求の範囲に記載する発明を特定するかにあたって考慮されます。
＜発明の分析＞
（発明に関する情報を入手し、明細書の様式に従って分析する）
以上の説明により、コンピュータ・関連発明としてどのようなものが存在しうるかが理解されたと思います。そこで、認識された発明を明細書に著し、特許出願をするわけですが、発明を前記明細書に著すについては、発明に関する情報を分析し、明細書の形式に合わせてどのように表現するかを検討しなければなりません。
発明の分析方法は、総論で述べた方法と同一です。
＜静的分析＞
☆ソフトウェアの場合、動作手順を順次説明する。フローチャート図、タイミングチャート図で示すとよい。
＜動的分析＞
☆ソフトウェアの場合、静的分析で示したフローチャト等から、機能ごとに「機能ブロック図」を作成してみる。
☆目的達成する上で不要な機能ブロックがあるか？→不要なものは必須構成要件ではない。
＜明細書への出力工程（発明の文章化技術）＞
請求範囲の表現形式
ソフトウェア関連発明においては、ｍｅａｎｓ＋ｆｕｎｃｔｉｏｎ形式で発明を特定せざるを得ない側面があります。機能を実現するハード構成はＣＰＵでしかないからです。
このｍｅａｎｓ＋ｆｕｎｃｔｉｏｎ型に具体的なハードウェア資源を取り込んだ特定手法も可能です。
この特定手法では、機能で特定するため、権利範囲を広くカバーできる反面、具体的な機能実現手段を数多く例示しないと、権利範囲が事実上限定されると考えられます。特に米国では１１２条第６パラグラフで、このクレーム形式の権利範囲は、実施例とその均等物の範囲とされている。
詳細な説明の表現方法
請求項に記載した機能実現手段が、実際のコンピュータ上でどのように実現されているか、記載することが必要です。
明細書、特に、特許請求の範囲の記載と自然法則の利用
特許法上、発明とは、「自然法則を利用した技術的思想の創作のうち高度のもの」（特許法第２条①）と定義されています。ここで、自然法則とは、自然の領域（自然界）において経験によって見い出される法則を言います。
人間の推理力その他、純知能的・精神的活動により発見され案出された法則（数学又は論理学上の法則、例えば、計算方法、作図法、暗号作成方法）、金融保険制度、課税方法、遊技方法などの人為的取り決め、経済学上の法則、広告方法などは自然法則でないので発明ではありません。また、人間の心理現象に基づく経験則、すなわち心理法則は一般に自然法則でないと解されています。
しかし、これらもコンピュータという「魔法の箱」を利用することで、自然法則を利用した発明として特許される可能性がでて来ております。
この点は、添付した、（１）「産業上利用することができる発明」の審査基準の実例と、（２）ソフトウェア関連発明に関する審査基準 (特定技術分野の審査基準）の実例を参照されたい。
＜ソフトウェア関連発明のクレーム解釈方法と明細書＞
ソフトウェア関連発明で問題となるのでは、機能的クレームの解釈でしょう。
ソフトウェア関連発明では、しばしば、機能実現手段で発明を特定する手法がとられます。これは、米国での means + function クレームと同様のクレーム形式です。米国ではこのクレーム形式の取り扱いが法律上で規定されています（米国特許法第１１２条第６項）。すなわち、 means + function クレームの保護範囲は、実施例記載の構成＋その均等の範囲に限定されるという規定です。
これに対し、我国で、その法的取り扱いについては定めはありません。この点、我が国における機能的クレーム解釈のこれまでの傾向から、米国と同様に解釈されるであろうことは、当然予想されることであります。
よって、発明の保護の範囲をできるだけ広くかつ確実にするためには、以下のような点を考慮して明細書を作成する必要があるといってよいでしょう。
① 実施例を踏まえ、できるだけ客観的な構成でクレームを記載する。
② 構成を機能に置き換え、機能実現手段等の機能的表現でのクレームを作成する。
③ 前記実施例の他に機能実現手段の具体例が他にないか検討し、できるだけ多くの具体的実施例を列挙する。なお、実施例はできるだけ具体的に記載する。
④ 機能的クレームと構成によるクレームとの中間に位置する中間概念のクレームが存在しうるか検討する。
＜ソフトウェア明細書作成と経済環境＞
ソフトウェア関連発明の保護のあり方は、ソフトウェア産業の発達に従って進展してきました。媒体特許の話もまさに社会におけるソフトウェア流通の現状と法律とのギャップから生じた問題です。
ソフトウェアを取り巻く環境は、革命のごとく変革しており、その保護のあり方がその変革を後追いする形となっております。例えば、最近では、インターネットの話題がつきませんが、インターネットでアクセスした米国の通信販売元が、日本の特許を侵害するソフトウェアをインターネットを通じて販売する用意があるとの申し出をしていた場合、日本の特許権侵害となるのでしょうか？
まさに、コンピュータは世界の国境をなくし、知的財産権における属地主義を崩壊させようとしております。
明細書を書く場合も、また、特許戦略を考える場合も、急速に変化するソフトウェア文化、その流通形態を常に意識しておく必要があるでしょう。
出願の目的を考える必要があるのは、ソフトウェアの場合も同様です。さらにソフトウェアの場合、流通形態は、ＣＤ－ＲＯＭなどの記憶媒体に記録されて配布される場合、パソコン通信や、インターネットで配布される場合があり、それら流通形態を考慮した保護を図る必要があります。
また、ハード＋ソフトの組み合わせのシステムで販売していたところ、サードパーティによりソフトのみを改良して配布されることもありうるので、その点を注意する必要があるでしょう。