知財コラム
CONTENTS
CONTACT

特許業務法人
HARAKENZO
WORLD PATENT & TRADEMARK


大阪本部    

〒530-0041
大阪市北区天神橋2丁目北
2番6号  大和南森町ビル
TEL:06-6351-4384(代表)
FAX:06-6351-5664(代表)
E-Mail:

東京本部    

〒105-6121
東京都港区浜松町2-4-1
世界貿易センタービル21 階
TEL:03-3433-5810(代表)
FAX:03-3433-5281(代表)
E-Mail:

広島事務所 

〒730-0032
広島市中区立町2-23
野村不動産広島ビル4 階
TEL:082-545-3680(代表)
FAX:082-243-4130(代表)
E-Mail:


上記トレードマークの背景地図は、1991年当時の特許登録件数を陸地の大きさと形状に擬態化して、地図状に表現したものです。

プライバシーポリシー


サイトマップ
知財コラム
知財教室のバナー
コラムインデックスへ

発明者のためのコンピュータ・ソフトウェア関連発明(ビジネス関連発明を含む)の説明書の書き方

2002年3月26日
特許業務法人HARAKENZO WORLD PATENT & TRADEMARK
(文責:児島)

1.発明の把握

①効果を出発点にして、発明を把握する。発明の効果は発明の課題の裏返しになる。
②システムを運用する際のプロセスを大まかに区分する。
③各処理ごとに、その処理の主体が人間かコンピュータかをはっきりさせる。
・「△△△のためのデータ処理システム」として解釈すればよいのでは
・「△△△のための支援システム」(完全自動化できない場合)
なお、発明の名称を上記のようにする必要はない。

2.開示する程度

①明細書および図面には、発明を当業者が実施できる程度に、十分に開示する(実施可能要件)。ここでいう当業者には、進歩性の判断基準である発明者レベルの者だけでなく、そのレベルに達していない一般の当業者も含まれる。
②コンピュータ・ソフトウェア関連発明(以下「CS発明」という)の場合、データ処理システムを作ることができ、かつ、使用できる程度に、どのようにコンピュータのハードウェアやソフトウェアが構成されているかを記載する。特に、ビジネス関連発明(以下「BM発明」という)の場合、ビジネスアイデアだけを詳細に説明するだけでは明確かつ十分に記載したとはいえない。
③本当に保護を必要としているビジネス態様を具体的かつ十分に説明する。(なお、ノウハウ等の公開すべきでない事項については、必ずご指摘頂きますようお願いします。)

3.効果(先行技術の検討を含む)

①一般に、従前に類似する手法がない場合には、類似するとまでは言えなくとも、最も近い手法と比較して、メリットを見い出す。
②BM発明では、先行技術として人間によるビジネスプロセスを検討する必要がある。
③一般に、公知例に対する進歩性を主張するためには、「技術的効果」が有効である。よって、CS発明では、“ユーザの操作性”、“取引の安全性”や“通信コストの低下”などの「技術に少しでも近い効果」を見出して記載する。これに加えて、BM発明では、“適切な情報提供と選択”、“簡略化(利便性)”、“効率向上”、“販売の向上”などの「商業的・経済的な効果」を副次的に記載する。また、技術水準から予測できない効果があることや、商業的な成功等も参酌されるので記載しておく。
④ただし、コンピュータによってシステム化することにより得られる、“速く処理できる”、“大量のデータを処理できる”、“誤りを少なくできる”、“均一な結果が得られる”などの一般的な効果は、システム化に伴う当然の効果であることが多く、通常は、技術水準から予測できない効果とはいえない。
⑤特許事務所においては、権利範囲をどこまで広げられるかを考える。そのためには、公知と未公知の境界が明確である必要がある。それゆえ、先行技術の特定は不可欠である。

4.効果をもたらした工夫・特許を取得したいポイント(請求考案)
①できれば、1つの効果ごとにそれに必要な構成をあげる。構成の記載は箇条書きでよい。
例:「第nに、○○○○○という効果が得られる。そのために必要な構成は、
△△(構成1)△△; ・・・(構成1の説明)
△△(構成2)△△; ・・・(構成2の説明)
△△(構成3)△△; ・・・(構成3の説明)
である。」
②発明の本質部分(効果をもたらした工夫)と、発明者自身が権利を取得したいと考えた部分とが、ずれた場合には、権利を取得したい部分(工夫・特徴)をあわせて記載する。なお、CS発明では、発明のアイデアと、アイデアを具体化するための工夫とが直接的には一致しないことが多い。

5.実施の形態

(1)人間とハードウェアとの役割の明確化
ビジネス方法を詳しく記述する際、ビジネス方法における人とハードウェアとの関係を明確に示す。そうすることによって、人とハードウェアとが混在するBM発明において、人の行為とハードウェアの機能との切り分けが明確になり、結果としてビジネス方法がより理解されることになる。また、請求項に係る発明がより詳細に説明されることになるので、審査官の理解を助け、実施可能要件をクリアし、権利化の確実性が増す。

(2)ビジネス方法の説明
ビジネス方法が複雑な場合、システムのハードウェアおよびソフトウェアの説明に先立って、ビジネス方法を独立して説明した方が、ビジネスを中心に捉えることができるようになり、理解が容易になる。
そこで、〔発明の実施の形態〕の項目の最初に、ハードウェアにこだわらない“純粋なビジネス方法”を概念図を用いて説明し、その後に、ビジネス方法を実現するシステムのハードウェアおよびソフトウェアの技術的な説明を記載するとよい。

(3)システムの説明
①最も好ましいと思われるシステムの形態、あるいは既にシステムの概要設計がある場合にはそれに基づいた形態を説明する。その後、バリエーション(変形例)を記載する。
②まず、システム全体を概観図を用いて説明し、次に、システムを運用する際のプロセスを大まかな区分ごとに順に説明する。
③CS発明では、データ(生成・入力・処理・出力・削除)に着目して説明する。これに加えて、BM発明では、物品(購入品、調達品等)や金銭(データの一種といえる)の動きに着目して、ビジネス方法全体を意識して実施の形態を説明する。

6.図面
請求項にあげる構成は、図面のどこかに明示されていることが原則である。

(1)純粋なビジネス方法の説明図[図1]
 ・ハードウェアやソフトウェアにこだわらない“純粋なビジネス方法”が俯瞰できる概念図。

(2)システムの説明図

①システムが備えるハードウェアの概観図[図2]
・システム全体の概観図。システムが小規模である場合、次の機能ブロック図があれば省略できる。

②各装置の機能ブロック図[図3]
・各装置の機能的特徴をブロック化したシステム図であり、ハードウェアの機能、すなわちソフトウェアを明確化するために必要。これが発明の概略を示す代表図面となる。
・できるだけ、1機能/1ブロックとなるようにブロック化する。プロセス等の説明中に登場するブロックを追加する。機能をどこまで細分割化するかは、請求項の記載による。少なくとも、従属項で外的に付加される機能は、主ブロック(46,37)と外部で接続されるブロック(33)として、また、従属項で内的に付加される機能は、主ブロック(24)の内部に含まれるブロック(28)として、図示されるべきである。
・機能ブロック図を用いれば、システムの内部構成、および内部構成レベルでの動作の説明が容易になる。すなわち、システム内部でのデータフローおよびデータ構造を参照しながら、内部構成レベルでのデータの入力/出力をなぞることで、システムの内部動作を分かりやすく説明できる。また、システム内部の各ブロックを主語にして説明できる。
・説明書では、システムの動作においてデータの処理に直接関わる機能ブロック(モジュールやサブルーティンのレベル)および入力/出力データをご説明ください。
・クライアントでブラウザが動作する場合、サーバから送信されたプログラム等がブラウザ上に展開された状態での機能ブロックを記載する。
・メモリやハードディスク等には、記憶するデータの名称を示す。
●システムを運用する場合の処理を大まかに区分し、区分した各プロセスごとに3点セット図面(「フローチャート」、「データ」、「画面」)を用意する。常に、これらの図面が必要十分であるとは限らないが、これら3点セットを用意すれば良いことが多いと思われる。もちろん、実施態様に応じて、その他の説明に必要な図面(状態遷移図等)を用意する。

③プロセスを示す図[図4、図5]
・複数の装置のプロセスを捉えたフローチャートであるシーケンス図。1つの装置にとどまらず、各装置の関係を視覚的に捉えるため。
・装置(サーバ/クライアントの機能ブロック)が行う処理を装置を主体として示す。その際、対応する機能ブロックが無い場合には、機能ブロック図に追加する。
・使用方法等をユーザの動作のフローチャートで示す場合、できるだけ装置のプロセスとは別図(あるいは別系統のライン)にする。すなわち、人間による処理とシステムによる処理とを分ける。

④画面イメージを示す図[図6(a)]
・プロセスの過程での画面イメージ。ユーザとハードウェアとの関係が明確になり、結果としてビジネス方法がより理解されることになる。
・画面イメージの遷移(処理内容に基づく画面の変化)も作成する。複数の画面イメージを提示することで、プロセスの流れを具体的なものとして理解しやすくなる。「マピオン」特許の図面[図7]が参考になる。処理フローと表示画面を組み合わせた図面は、表示画面が多い場合に適している。

⑤データ(データ構造)を示す図[図8、図9]
・動作説明で必要となるデータ構造を示す。どの程度まで詳細に示すかは発明の内容によって異なる。
・データを具体例で示す場合、画面イメージとデータの内容とを対応させる[図6(a)(b)]。

(3)変形例を示す図
・変形例の構成の概略を視覚的に捉えられる図面。変形例ごとに図示すると、装置の数や各装置の相互関係の変化が明確となる。
・重要な変形例には、機能ブロック図および3点セット図面が望ましい

(4)先行技術の図
・発明の機能ブロック図(代表図面)と対応する図面が理想的。

7.変形例
①ビジネスモデルを構成する各要素について、その変形例(構成要素の追加/削除/代替)を検討する必要がある。多様な変形例を記載しておけば、多様な視点からの請求項をサポートできる。変形例の検討が十分でないと、簡単に特許破りをされるような穴だらけの特許になる。
②例えば、
・ビジネス分野(電子商取引、金融、証券、保険、広告、流通等)
・通信手段(インターネット、e-mail 、LAN、ダイアルアップ、携帯電話等)
・決済手段(クレジットカード、デビットカード、電子マネー等)
③BM発明は抽象的であるため、明細書という形でビジネスモデルが具体化されると、それをたたき台にして、さらに考えが発展することがある。よって、変形例の検討は、出願原稿のチェック時にも行うことが望ましい。


【図1】
図1
【図2】
図2
【図3】
図3
【図4】
図4
【図5】
図5
【図6】
図6
【図7】
図7
【図8】
図8
【図9】
図9

コラムインデックスへ
このページのトップへ