明細書を作成するには、発明に関する情報を収集し、それを特許法の要求する様式に合う情報として分析し、それを明細書様式に合わせて文章化する必要があります。発明をどのように記載するかにあたり、以下のことを知っていただく必要があります。
ソフトウェア関連発明は、前記@やAの場面で開発されることが多く、Bの場合は少ないようですが、最近は趣味的にコンピュータに精通しシステムあるいはプログラム開発を行って、職場の業務改善を行う者も増えているようですので、Bの場合の発明もあり得ます。
ソフトウェア関連発明では、上記いずれの場合でも、何が発明であったのかを評価しずらいという特性があるので、発明の抽出作業が重要となります。
また、上記Aの場合、プログラム開発委託契約などにおいて、開発に伴う権利関係を明確にしておく必要があります。
別紙「権利解釈方法と明細書」で説明しているように、権利解釈の大原則として「権利一体の原則」があります。この原則は発明の発掘・認識の上で極めて重要です。この原則を利用した発明の発掘方法を以下説明します。
例えば、
@ Ａと、
Ｂと、
Ｃとを備えた装置
という発明や公知技術がすでにあったとします。
これに対し、
A Ａと、
Ｂと、
Ｃと、
Ｄとを備えた装置
あるいは、
B Ａと、
Ｂと、
Ｄとを備えた装置
を新たに開発したとします。これらA、Bの発明は、@の発明と構成が異なるので別発明として特許され得ます。但し、Aの発明は@の発明のすべての構成要素を備えているので、いわゆる利用発明といいます。
このように、従来技術、先行発明などに新たな構成を付加したり、構成を交換することで新たな発明とすることが可能です。
ところで、第３者が、構成要素Ａ、Ｂ、Ｃからなる装置を実施したら権利関係はどうなるでしょうか？
この実施は、@の発明の特許権を侵害します。すべての構成を実施しているからです。
しかし、Aの発明の特許権を侵害することにはなりません。Ｄの構成を実施していないからです。このように、権利に抵触しているというためには、すべての構成要素を備えていることが必要であることを「権利一体の原則」といいます。
この観点からすると、ＡＢＣＤからなる発明の実施は、Aの発明のみならず、@の発明の特許侵害となります。この点はAの発明の特許権者も同様であり、Aの発明者は特許は取得できても実施すると@の特許発明を侵害する結果となります。これを解決するため、特許法ではクロスライセンス制度を設け、権利調整をしています。
また、ＡＢのみの実施はいずれの特許発明にも抵触しません。従って、構成要素の少ない発明の方が、権利範囲が広いということが言えます。
この権利一体の原則に基づき、構成の組み合わせを選択することで容易に発明が可能となるのです。
ソフトウェア開発者は通常、技術的思想を創作しようとか、創作したという意識がないのが通常です。なぜなら、プログラム開発者は、公知のプログラム言語、開発モジュール等を使用し、通常公知のハードウェア資源を利用してシステムを構築するのが通常で、何らかの思想を具現化したという実感を伴わないからです。
従って、特許的な目を通じて、自己の開発したプログラム等をソフトウェア発明として見直す必要があります。
なお、許されるのであれば、発明提案の日を設け、弁理士などの専門家を交え、複数の技術者で特定の技術につきブレーンストーミングを行って、発明の発掘をするというのも有効な手段であります。
ＩＮＤＥＸに戻る
このソフトウェア開発工程でどのように発明を発見するかが問題となります。ソフトウェア関連発明においても、発明を発見するためには「機能」を発見すればよいことは同様です。前に述べたように、ソフトウェア発明は、機能・作用を中心に発明の構成が特定されます。この点が他の分野の発明と大きくことなり、ソフトウェア発明の特質となっています。
そこで、ソフトウェア発明を抽出するには、最小単位の「機能」でくくっていくことにより、「機能実現手段」あるいは「手順」を認識していくことが必要となります。
この認識された「機能実現手段」自体が新しい機能を提供するとき、その部分を特徴とした発明が認識されますが、ソフトウェアの場合通常、個々の「機能実現手段」自体は公知である場合が多いかもしれません。しかし、それら公知の「機能実現手段」を複数組み合わせることで、新たな機能を生じるのであれば、それをもって発明として認識することが可能です。
☆新たな機能が存在するところに必ず発明あり、ということです。
このような「機能実現手段」を注出するため、具体的には、前記した開発工程の中で、明細書作成に必要な情報として、以下の情報を注出する必要があります。
〔１〕要求定義の過程で作成したソフトの目的、機能、性能、環境などの決定事項を記載したドキュメント
〔２〕基本設計の過程で作成したドキュメント類、特に、プログラム用ドキュメントとしてのフローチャート、このフローチャートによるソフト実行の動作説明を特にソフトの特徴的機能を必ず網羅するように記載
〔３〕プログラム・リストは必要なし。
〔４〕出願しようとするソフトについて機能・仕様の変更がある場合は、その変更箇所を示すドキュメント
〔５〕 その他、ソフトウェアによる情報処理手段として用いられる場合等、ソフトを利用した具体例を少なくとも一つ挙げることが望ましい。
〔６〕ソフトが実現する機能を、一つずつ機能ブロック図として表現する。各機能ブロックがコンピュータのどの部分で実現されるのかも示すとよい。
以上の観点からすれば、基本設計（アイデア）段階で発明の認識が可能であり、明細書を作成することができます。この段階で出願を検討するのがよろしいでしょう。
次に、ソフトウェア関連発明は、
@研究テーマを掲げ、その結果生まれる発明（開発部における発明）
A他社からのシステム開発依頼に基づく発明
である場合が多く、
B改善提案制度による発明（従来型ＱＣ運動、あるいは発明啓蒙キャンペーン等の中から生まれる発明）
の場合は少ないようですが、最近は趣味的にコンピュータに精通しシステムあるいはプログラム開発を行って、職場の業務改善を行う者も増えているようですので、Bの場合の発明もあり得ます。
ソフトウェア関連発明では、上記いずれの場合でも、何が発明であったのかを評価しずらいという特性があるので、発明の抽出作業が重要となります。
また、上記Aの場合、プログラム開発委託契約などにおいて、開発に伴う権利関係を明確にしておく必要があります。
先に説明したように（発明の種類の項）、ソフトウェア関連発明では、大きくわけて
(1) コンピュータの外部ハードウェアに対する制御
(2) コンピュータの内部ハードウェアに対する制御
(3) ハードウェアの存在を意識できない発明
として発現する場合があります。
このような分け方で捉えると、現場での実際にマッチししかも産業上利用性を満たす発明として明細書に記載しやすくなるというメリットがあります。
なお、(1)と(2)については、制御対象に対して何をしているのか？という観点から発明の構成（特徴点）を捉えることが比較的容易にできますが、(3)の場合は、どのような構成を備えているのかなかなか捉えにくいという特徴があります。
しかし、いずれの場合でも、「機能」からその構成を特定していくことで、発明の全体が見えてきます。