• ポートフォリオ機能


ポートフォリオを新規に作成して保存
既存のポートフォリオに追加保存

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 一部無効 特36 条4項詳細な説明の記載不備  B25J
審判 一部無効 5項1、2号及び6項 請求の範囲の記載不備  B25J
管理番号 1263838
審判番号 無効2010-800126  
総通号数 155 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2012-11-30 
種別 無効の審決 
審判請求日 2010-07-21 
確定日 2012-10-11 
事件の表示 上記当事者間の特許第3542615号発明「複数ロボットの制御装置」の特許無効審判事件について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 審判費用は、請求人の負担とする。 
理由 第1.手続きの経緯
本件無効審判事件に関する手続の経緯は、以下のとおりである。

平成 5年 2月26日 本件特許出願(特願平5-38288号)
平成14年 2月 7日 拒絶理由通知
平成14年 4月15日 意見書・手続補正書の提出
平成15年 1月10日 拒絶理由通知
平成15年 3月24日 意見書・手続補正書の提出
平成15年12月26日 拒絶理由通知
平成16年 3月 3日 手続補正書の提出
平成16年 3月19日 特許査定
平成16年 4月 9日 特許登録(第3542615号)
平成22年 7月21日 無効審判請求(無効2010-800126号)
平成22年10月 8日 答弁書の提出
平成23年 1月 6日 口頭審理陳述要領書の提出(請求人、被請求人)
平成23年 1月20日 第1回口頭審理
平成23年 2月21日 上申書の提出

第2.本件発明について

本件発明は、平成15年3月24日付け手続補正書によって補正された特許請求の範囲の請求項1、2に記載のとおりのものと認められるところ、同記載は以下のとおりである。
「【請求項1】 複数のロボットを、これらロボットの駆動軸の総数以上の数のドライバーを有するコントローラにより制御する装置であって、
上記各ドライバーと上記複数のロボットの各駆動軸との対応関係を変更可能に設定する設定手段と、
上記対応関係の設定に基づいて各ドライバーに対応する駆動軸の属性を示すデータを書き換え可能に記憶する各軸属性記憶部と、
上記各ドライバーと上記各駆動軸との対応関係に応じてドライバーの処理条件を決定する処理条件決定手段と、
駆動すべきロボットおよび駆動軸を特定する駆動対象指定と移動位置を特定する移動位置指定とを含む移動命令を示すデータを入力する移動命令入力手段と、
上記移動命令入力手段により入力されたデータと上記各属性記憶手段から読み出したデータとの照合に基づき、上記移動命令を判別して駆動対象に対応するドライバーを選定する移動命令判別手段と、
上記移動命令判別手段により選定されたドライバーにつき、上記処理条件決定手段により決定される処理条件と上記移動命令で指定される移動位置とに基づいて処理内容を求め、この処理内容に従ってドライバーを制御する制御手段と
を備えたことを特徴とする複数ロボットの制御装置。
【請求項2】 上記複数のロボットのうちの少なくとも1つのロボットの駆動軸には、当該ロボットに付属する付加軸が含まれており、上記各軸属性記憶部に記憶されるデータおよび上記移動命令入力手段によって入力されるデータには付加軸を示すデータも含まれていることを特徴とする請求項1記載の複数ロボットの制御装置。」
(以下、請求項1に係る発明を「本件発明1」、請求項2に係る発明を「本件発明2」という。)

なお、本件発明1について、請求人が無効審判請求書で用いた構成要件の項分けを示すと以下のとおりである。
A 複数のロボットを、これらロボットの駆動軸の総数以上の数のドライバーを有するコントローラにより制御する装置であって、
B 上記各ドライバーと上記複数のロボットの各駆動軸との対応関係を変更可能に設定する設定手段と、
C 上記対応関係の設定に基づいて各ドライバーに対応する駆動軸の属性を示すデータを書き換え可能に記憶する各軸属性記億部と、
D 上記各ドライバーと上記各駆動軸との対応関係に応じてドライバーの処理条件を決定する処理条件決定手段と、
E 駆動すべきロボットおよび駆動軸を特定する駆動対象指定と移動位置を特定する移動位置指定とを含む移動命令を示すデータを入力する移動命令入力手段と、
F 上記移動命令入力手段により入力されたデータと上記各属性記憶手段から読み出したデータとの照合に基づき、上記移動命令を判別して駆動対象に対応するドライバーを選定する移動命令判別手段と、
G 上記移動命令判別手段により選定されたドライバーにつき、上記処理条件決定手段により決定される処理条件と上記移動命令で指定される移動位置とに基づいて処理内容を求め、この処理内容に従ってドライバーを制御する制御手段とを備えた
H ことを特徴とする複数ロボットの制御装置。」
以下、上記項分けにしたがって、各構成要件を「構成要件A」等という。

第3.請求の趣旨及び理由

ア.請求人は、特許第3542615号発明の特許請求の範囲の請求項1に記載された発明についての特許を無効とする、審判費用は被請求人の負担とする、との審決を求めた。

イ.請求人の主張する無効理由は、以下の理由1ないし3である。

理由1、特許法第36条第4項違反

○分配設定手段に関する記載
本件特許明細書の発明の詳細な説明において、図2に示される「分配設定手段41」が構成要件Bの「設定手段」に対応するものと考えられるが、これについては、明細書の発明の詳細な説明には、「ドライバーとロボット軸との対応関係の設定手段である分配設定手段41」(【0017】)と構成要件Bの表現よりも簡単に記載されているのみで、具体的構成例についての説明は一切ない。
分配設定手段41の構成、作用または機能に僅かでも関係すると思われる明細書の発明の詳細な説明における上記以外の記載を拾ってみると次の通りである。
「上記各軸属性記憶部46には、各ドライバーに対応するロボット軸の属性が図3に示すような軸定義フラッグADFとして記憶されており、これによって前記分配設定手段41の機能が果たされるようになっている。」(【0018】。なお【0019】には軸定義フラッグについての説明がある。)
「このような軸定義フラッグADFは、準備段階で予め設定され、ドライバーとロボット軸との対応関係が変更された場合は、それに応じて書き換えられる。」(【0020】)
「ドライバーとロボット軸との対応関係の設定は種々変更可能であり、その対応関係に応じて、上記軸定義フラッグADFの中に含まれる分配記号が定められる。図5(a)?(d)は、ロボット軸の数などが異なる各種場合につき、各ドライバー(DR1,DR2,……)とメインロボット軸(M1、M2、……)、サブロボット軸(S1,S2,……)との対応関係、ならびに分配記号を例示している。」(【0025】。【0026】?【0027】に図5(a)?(d)の説明がある。)
「こうして、ドライバーとロボット軸との対応関係の変更に応じ、ドライバー制御時の処理用のデータも、対応関係に適合するように変更される。とくに、対応関係設定の段階で、上記軸定義フラッグADFの分配記号等を設定しておきさえすれば、ステップS14?S16により自動的に適切なデータが得られる。」(【0042】)
「【図5】(a)?(d)はロボット軸の数等が異なる各種場合におけるドライバーとロボット軸との対応関係ならびに分配記号を示す説明図である。」(【図面の簡単な説明】)

○「対応関係を設定する」とは
図5(a)?(d)がロボット軸の数などが異なる各種場合について、各ドライバーとメインロボット軸、サブロボット軸との対応関係、ならびに分配記号を例示するものであるから(【0025】、【図面の簡単な説明】)、各ドライバーと複数のロボット軸との対応関係の一例は、一応、「観念的」なものとして図5(a)?(d)に表わされているといえる。
一方、分配設定手段41はコントローラ3に含まれるものである(【0017】)。コントローラ3が各軸属性記憶部46、処理条件記憶部47、EXテーブル記憶部48等の記憶部を有し、移動命令入力からドライバーの制御までの図8、図9のフローチャートによって表わされる一連の制御を行うものであることを考慮すると、コントローラ3はプロセッサ、メモリ、入、出力機器等を含むコンピュータによって実現されるものであると想像される。仮にそのように考えたとすると、分配設定手段41も、プロセッサ、メモリ、入、出力機器等の一部によって実現されるものとなる。そして、分配設定手段41によって設定されるドライバーとロボット軸との対応関係も、「観念的」なものではなく、コンピュータ(コントローラ)による具体的な「設定のための処理」によってコンピュータ内のどこかに「設定」されているものでなければならないし、「設定」されているものであるならば、対応関係を表わす何物か(たとえばデータ)がコンピュータ内の「どこかに」存在しなければならない。
しかしながら、本件特許明細書の発明の詳細な説明にはコンピュータ(コントローラ)による具体的な「設定のための処理」は記載されていないし、その処理を表わすフローチャート(図8、図9のような)も開示されていない。また、ドライバーとロボット軸との対応関係を例示すると説明されている図5(a)?(d)は、「説明図」であって、メモリ内のデータを示すものであるとの説明はない(【図面の簡単な説明】)。そして本件明細書の発明の詳細な説明には、ドライバーとロボット軸との対応関係がコンピュータ(コントローラ)内の「どこに」、「どのような形態で」、「設定」されているのかについての説明も全くないのである。

○「変更可能に設定する設定手段」とは
コントローラ3は、文字通り、制御するための装置ないしは機器であって実体的に存在するものである。ドライバーとロボット軸との対応関係を設定する「分配設定手段41」もまたコントローラ3の構成の一部としてコントローラ3内に実在するものでなければならない。
なるほど、「本発明の一実施例による制御装置の構成を示すブロック図である」図2には「分配設定手段41」のブロックが描かれているが、その実体は以下に示すように、全く不明である。
上に引用した明細書の発明の詳細な説明の文章を拾ってみていくと、軸定義フラッグADF「によって前記分配設定手段41の機能が果たされるようになって」(【0018】)おり、「軸定義フラッグADFは、準備段階で予め設定され、ドライバーとロボット軸との対応関係が変更された場合は、それに応じて書き換えられる。」(【0020】)ものであり、「ドライバーとロボット軸との対応関係の設定は種々変更可能であり、その対応関係に応じて、上記軸定義フラッグADFの中に含まれる分配記号が定められる。」(【0025】)とされており、「ドライバーとロボット軸との対応関係の変更に応じ、ドライバー制御時の処理用のデータも、対応関係に適合するように変更される。とくに、対応関係設定の段階で、上記軸定義フラッグADFの分配記号等を設定しておきさえすれば、ステップS14?S16により自動的に適切なデータが得られる。」(【0042】)と記載されている。このように、分配設定手段41または対応関係について、観念的な記載しかないのである。
他方、「設定手段」に関連して作用および発明の効果の項には次のような記載がある。
「【作用】
上記構成によると、準備段階で上記各ドライバーと上記各駆動軸との対応関係が設定され、コントローラに接続される複数のロボットの軸数、組合せ等に変更があった場合は、この設定において対応関係が調整される。」(【0010】)。
「コントローラに接続される複数のロボットの軸数、組合せ等が変わった場合にも、それに応じた調整が上記対応関係の設定によって行われることにより、適切な制御を行うことができる。」(【0045】)。
以上の文章からは、準備段階で対応関係の設定が行なわれるものと理解されるが、その準備段階で行なわれる処理または制御は、図8、図9のフローチャートには示されていない。上述したように対応関係の設定という動作(処理、制御、操作)は明細書または図面には開示されていないのである。また、「対応関係の設定は種々変更可能であり、」(【0025】)、「この設定において対応関係が調整される」(【0010】)等の記載はあるが、「変更可能に設定する」のはユーザなのか、「設定手段」(分配設定手段41)なのか、全く説明がない。そして、上述したように設定された「対応関係」が何によって具現化されるのかが不明なのであり、そのような「対応関係」を「変更可能に設定する設定手段」の具体的構成も全く不明といわざるを得ないのである。

以上の通り、「上記各ドライバーと上記複数のロボットの各駆動軸との対応関係を変更可能に設定する設定手段」(構成要件B)に関連して、本件特許明細書の発明の詳細な説明には当業者が容易に実施をすることができる程度に発明の構成が記載されていないから、本件特許明細書の発明の詳細な説明は平成2年改正特許法第36条第4項の要件を満たしていない。

理由2、第36条第5項第1号違反
以上の通り、構成要件Bに対応すると考えられる「分配設定手段41」に関連して、本件特許明細書の発明の詳細な説明には、当業者が容易に実施をすることができる程度に、発明の構成が記載されていない。すなわち、発明の詳細な説明には構成要件Bをサポートする記載がない。
したがって、構成要件Bは発明の詳細な説明に記載したものではないから、特許請求の範囲の記載は平成2年改正特許法第36条第5項第1号に規定する要件を満たしていない。

理由3、第36条第5項第2号違反

○構成要件Bに関して
理由1のとおり、構成要件Bに記載の事項を明確に把握することはできない。

○構成要件Cに関して
構成要件Cは次の通りである。
「上記対応関係の設定に基づいて各ドライバーに対応する駆動軸の属性を示すデータを書き換え可能に記憶する各軸属性記憶部と、」
第1に、上述したように構成要件Bに記載の「対応関係」の実体が不明なのであるから、構成要件Cの「上記対応関係の設定に基づいて」を明確に把握することはできない。
第2に、「上記対応関係の設定に基づいて」がどこにかかるのか日本語として理解できない。
仮に、「上記対応関係の設定に基づいて」「‥‥データを書き換え可能に記憶する」と読んだとすると、各軸属性記憶部が主体的に「‥‥に基づいて」「データを書き換え可能に記憶する」という意味になるのか、不明である。また、記憶部が書き換え可能に記憶するとはどのような意味なのか、不明である。

○構成要件Dに関して
構成要件Dは次の通りである。
「上記各ドライバーと上記各駆動軸との対応関係に応じてドライバーの処理条件を決定する処理条件決定手段と、」
構成要件Dの処理条件決定手段に対応する「処理条件決定手段42」については、明細書の発明の詳細な説明には、「分配記号等に基づき上記EXテーブルを用いて処理条件記憶部47から処理条件を選定」(【0030】)するものとして記載され、このEXテーブルを用いて処理条件を選定する処理は図9のS14、S15、S16として表現され、その説明が【0036】?【0041】に記載されている。
これらの処理をする(すなわち、EXテーブルを用いて処理条件記憶部47から処理条件を選定する)ためには、その前提としてドライバーを選定することが必要である(図9のS11?S13の処理および【0034】?【0035】の記載)。
すなわち、明細書の発明の詳細な説明の記載によると、ドライバーの処理条件を決定するためには、その前提としてドライバーを選定することが必要であり、それ以外のドライバーの処理条件の決定の具体例は発明の詳細な説明には記載されていない。したがって、構成要件Dはその構成要件内において、ドライバーの処理条件を決定するための必要条件であるドライバーの選定が規定されていなければ理解ができないものである。
そして、ドライバーの選定それ自体は、本件特許の出願時点において技術常識であったとも自明であったともいえないから、ドライバーの選定に関して何ら規定していない構成要件Dの表現では発明を明確に把握することはできない。
構成要件Dの処理条件決定手段に対応するものとして本件特許明細書の発明の詳細な説明に開示されているものは「処理条件決定手段42」であるが、これは「上記対応関係に応じた処理条件を決定する処理条件決定手段42」(【0017】)と概念的に記載されているだけであるからその具体的な作用についての記述をさらに本件特許明細書に求めると、ドライバーとロボット軸との「対応関係に応じて、上記軸定義フラッグADFの中に含まれる分配記号が定められ」(【0025】)、「前記処理条件決定手段42は、分配記号等に基づき上記EXテーブルを用いて処理条件記億部47から処理条件を選定し、」(【0030】)と記載されている。したがって、構成要件Dの処理条件決定手段が各ドライバーと各駆動軸との対応関係に応じてドライバーの処理条件を決定するためには分配記号、EXテーブル(またはこれらに相当するもの)および処理条件記憶部が必要とされるのである。構成要件Dは、これらの分配記号、EXテーブルおよび処理条件記憶部に言及していないので(これらは本件特許の出願時において技術常識であるとも自明であるともいえない)、特許を受けようとする発明が明確に把握できない。

前述したように、構成要件Bの「設定手段」はその実体が不明であるから、このように実体が不明な「設定手段」によって設定される「上記各ドライバーと上記駆動軸との対応関係に応じて」どのように「ドライバーの処理条件を決定する」のか、不明であるといわざるを得ない。

○構成要件Fに関して
構成要件Fの記載は次の通りである。
「上記移動命令入力手段により入力されたデータと上記各属性記憶手段から読み出したデータとの照合に基づき、上記移動命令を判別して駆動対象に対応するドライバーを選定する移動命令判別手段と、」

「上記各属性記憶手段」については、「上記」とあるが、それよりも上に「各属性記憶手段」なる用語は存在しないから、不明瞭である。

以上の通り、構成要件B、C、DおよびFに関して、特許請求の範囲の請求項1の記載は不明瞭な部分を含み、特許を受けようとする発明を明確に把握することができないから、請求項1は特許を受けようとする発明の構成に欠くことができない事項のみを記載した項に区分してあるとはいえず、平成2年改正特許法36条第5項第2号に規定する要件を満たしていない。

ウ.証拠

請求人は、提出した甲第1号証の1?1号証の10、甲第2号証?甲第9号証を、参考資料とした(第1回口頭審理調書参照。)。

第4.被請求人の主張

被請求人の主張は、概略、以下のとおりである。
「(1) 第36条第4項違反について
(1-1)構成要件Bに関して
ア 構成要件Bの「設定手段」の具体的構成例について
発明の詳細な説明において,【0017】には,「ドライバーとロボット軸との対応関係の設定手段である分配設定手段41」との記載があり,【0018】には,「上記各軸属性記憶部46には,各ドライバーに対応するロボット軸の属性が図3に示すような軸定義フラッグADFとして記憶されており,これによって前記分配設定手段41の機能が果たされるようになっている。」との記載があり,【0019】には,8つのドライバーを有するコントローラにおいて,うち5つのドライバーがメインロボットに属する駆動軸の制御を担い,うち2つのドライバーがサブロボットに属する駆動軸の制御を担うように対応関係が設定された例を挙げて,軸定義フラッグADFについての説明がある。このように,構成要件Bの「設定手段」の一例として「分配設定手段」の説明があり,「分配設定手段」の具体的な機能について説明されていることから,その具体的構成例が明らかである。
イ 「対応関係を設定する」について
例えば,図3に示されている軸定義フラッグADFの場合には,下位8ビットが各ドライバー自身を区別し,上位4ビットが駆動軸の所属を示すとされ,その他2ビットが対応関係に応じた処理のためのものとして例示されている(本件明細書【0019】段落)。
つまり,下位8ビットがドライバーを特定し,上位4ビットのうち2番目,3番目のビットが,駆動軸が所属するロボット(例えばメインロボット,サブロボット)を特定するものとなり,上位7,8ビットが処理を行うためのものとなる。従って,この軸定義フラッグADFのように,各ドライバー自身を区別し,各ドライバーに対する駆動軸の属性を示すビット等を含むデータが設定されることで,各ドライバーと複数ロボットの各駆動軸との対応関係が設定される例として理解される。
ウ 「変更可能に設定する設定手段」について
上記対応関係がどのように設定されるかという点に関しては,【0010】に,「上記構成によると,準備段階で上記各ドライバーと上記各駆動軸との対応関係が設定され,コントローラに接続される複数のロボットの軸数,組合せ等に変更があった場合は,この設定において対応関係が調整される。」との記載があり,また,【0020】に,「このような軸定義フラッグADFは,準備段階で予め設定され,ドライバーとロボット軸との対応関係が変更された場合は,それに応じて書き換えられる。」との記載がある。
これらの記載から各ドライバーと各駆動軸との対応関係を設定する処理として,準備段階で,例えば,軸定義フラッグADFのような,ドライバー自身を区別するビットや各ドライバーに対する駆動軸属性を示すビットを含むデータが設定されることが解る。
ここでいう「軸定義フラッグADFが設定される」とは,上記軸定義フラッグADFが作成されてコントローラ内のメモリ(各軸属性記億部)に書き込まれることであり,「変更可能に」とは,【0020】にも説明があるようにロボットの組み合わせ等に変更があった場合には,それに応じた新たな対応関係に基づく上記データが作成されて,コントローラ内のメモリに書き込むことで変更できるという意味である。このような処理が,入力操作等に応じてコントローラにより行われる。
このような処理は,上述の【0010】,【0017】,【0018】,【0019】,【0020】,【0025】等の記載から,当業者であれば当然に理解し得るものである。
すなわち,構成要件Bの「設定手段」は,設定される対象である,「上記各ドライバーと上記複数のロボットの各駆動軸との対応関係」に技術的な特徴があるのであって,コントローラ内のメモリにデータを書き込むこと自体は,ごく一般的な技術であるから,当業者であれば,上記の本件明細書の記載から,平易に理解する事項であり,容易に実施することができる。
従って,構成要件Bに関し,特許法第36条第4項に違反するものではない。
(2) 第36条第5項第1号違反について
前述の第36条第4項違反に対する反論での説明から明らかなように,発明の詳細な説明には構成要件Bをサポートする記載があり,第36条第5項第1号に違反するものではない。
(3) 第36条第5項第2号について
(3-1)構成要件Bに関して
前述の第36条第4項違反に対する反論での説明から明らかなように,構成要件Bに記載の事項は明確に把握できる。
(3-2)構成要件Cに関して
前述のように構成要件Bに記載の「対応関係」の実体は,【0017】?【0020】等の記載から明確であるので,構成要件Cの「上記対応関係に基づいて」も明確に把握することができる。
また,「上記対応関係の設定に基づいて」は,「データを書き換え可能に記憶する」にかかることは明らかである。
具体的に説明すると,前述のように,実施形態では,準備段階で各ドライバーと各駆動軸との対応関係を設定する処理として,軸定義フラッグADFのような,ドライバー自身を区別するビット及び駆動軸の所属を特定するビットを含むデータ(【0018】,【0019】,図3等参照)が設定され,コントローラによりそのようなデータが設定されるという処理が,設定手段としての機能を果たすものである。
従って,「上記対応関係の設定に基づいて……データを書き換え可能に記憶する」とは,実施形態によれば,コントローラにより軸定義フラッグADFのようなドライバー自身を区別するビットや駆動軸の所属を特定するビットを含むデータが設定されるという処理に基づき,各軸属性記憶部に当該データが記憶されるということであり,何ら不明な点はない。
(3-3)構成要件Dに関して
ア ドライバーが選定されることが明確である
そもそも,本件発明は,装置発明であって,方法発明ではないから,時系列的に記載する必要はなく,構成要件AないしHの各構成要件を備えた技術的思想として明確である。
すなわち,構成要件Dの「ドライバーの処理条件」という文言自体,駆動対象に対応するドライバーの存在を前提としているところ,駆動対象に対応するドライバーの選定については,構成要件F「移動命令を判別して駆動対象に対応するドライバーを選定する」と規定され,構成要件G「上記移動命令判別手段により選定されたドライバーにつき,上記処理条件決定手段により決定される処理条件と上記移動命令で指定される移動位置とに基づいて処理内容を求め,この処理内容に従ってドライバーを制御する制御手段」と規定されている。
このような各構成要素間の関係及び文言から,構成要件Dは,移動命令判別手段により選定されたドライバーの処理条件を決定することが明白である。
さらに,明細書の記載をみれば,【図9】のフローチャートに示す例では,S14?S16で,処理条件決定手段としての処理が行なわれる。また,S11?S13で,移動命令を判別して駆動対象に対応するドライバーを選定する処理(移動命令判別手段としての処理)が行われる。
この例では,駆動対象に対応するドライバーを選定してから,選定したドライバーについて処理条件を決定している。そして,S17で,処理用データと移動位置指定とに基づいて決定した処理内容でドライバーを制御する処理(制御手段としての処理)を行っている。
すなわち,移動命令判別手段でドライバーが選定されると,そのドライバーの情報を入手した制御手段が,その選定されたドライバーにつき,処理条件決定手段により決定された処理条件を入手して,この処理条件と移動位置指定とに基づいて処理内容を求める。このように駆動対象に対応するドライバーが移動命令判別手段により選定された上で,処理条件決定手段がドライバーの処理条件を決定している。
このことは,本件発明1の構成要件G「上記移動命令判別手段により選定されたドライバーにつき,上記処理条件決定手段により決定される処理条件と上記移動命令で指定される移動位置とに基づいて処理内容を求め」という記載からも明らかである。
よって,ドライバーの選定について何ら不明なことはなく,特許法第36条第5項第2号に違反するものではない。
イ 分配記号及びEXテーブルは一例に過ぎない
実施形態では,分配記号に基づきEXテーブルを用いて処理条件記憶部47から処理条件を読み出しているが,これは処理条件を決定する手法の一例であり,処理条件決定手段による処理条件の決定は,この例に限定されるものではない。
すなわち,どのドライバーによりどの駆動軸が駆動されるかという対応関係に応じて,適用すべきドライバーの処理条件は異なる。そこで,ドライバーと駆動軸の各種組み合わせについて処理条件を予め記憶し,その中から上記対応関係に応じて処理条件を読み出すことにより,当該組み合わせに応じた処理条件を決定し得る(【0021】)。この場合,一般に,予め記憶されている多数のデータの中から必要なデータを読み出す手法は種々考えられるところである。
例えば,当業者であれば,本件明細書の記載から,次頁に示すようなデータの読み出し手法を容易に採用することができる。図5’は,本件明細書の図5から分配記号を省略し,ドライバーと駆動軸との対応関係を図示したものである。
上記の例によると,本件明細書の【図5】と同様に,メイン6軸,サブ2軸の場合(図5’(a))はDR1?DR6とM1?M6,DR7,DR8とS1,S2がそれぞれ対応し,メイン4軸,サブ4軸の場合(図5’(b))はDR1?DR4とM1?M4,DR5?DR8とS1?S4がそれぞれ対応し,メイン3軸,サブ3軸の場合(図5’(c))はDR1?DR3とM1?M3,DR4?DR6とS1?S3がそれぞれ対応し,メイン2軸,サブ2軸の場合(図5’(d))はDR1,DR2とM1,M2,DR3,DR4とS1,S2がそれぞれ対応する。
次に,本件明細書の【図3】の「分配記号」に代えて,図5’(a)に示すドライバーと駆動軸との対応関係を軸定義フラッグADFに設定すると,図3’となる。
また,本件明細書の【図6】の「番地」に代えて,図5'(a)?(d)に示すドライバーと駆動軸との対応関係をデータ内容に対応付けて処理条件記億部の内容を作成すると,図6’となる。
上記の例では,例えば,ドライバーDR2が選定されたとき,図3’のドライバーDR2の対応関係は「M2←DR2」であるから,図6’の対応関係「M2←DR2」を選定し,選定された対応関係「M2←DR2」に対応付けて記憶されているデータDATA_(DR2M2)(DR2がM2の駆動を行う場合のデータ)を処理用データとして自動的に読み出すことができる。
一方,本件明細書記載の実施例では,ドライバーとロボット軸との各種組み合わせに応じて,分配記号を設定し(【図3】,【図5】),この分配記号を変数として,ステップS14で呼び出し符号を設定し(【図9】),呼び出し符号(CALL)を用いて,ドライバーとロボット軸との組み合わせに応じた処理条件が格納されている番地から処理条件を読み取るという複数の段階を経ている(【図9】,S15,S16,【0041】)。
しかし,このように複数のステップを踏む例を挙げているのは,出願当時は,現在に比べて,メモリの容量に大幅な制約があったために,極力,ビット数の少ない手法をとろうとしたことによるものに過ぎない。
従って,メモリ容量を考慮せずに,本件発明の思想を実現する単純な例を示すならば,各ドライバーに対し,ロボット軸との組み合わせに応じた番号を決めておき,これを予め軸属性記憶部にすることで(図3”には,本件明細書記載のステップS14で求められる呼び出し符号と同じ値を記載した。),当該番号によって,処理条件を呼びだす方法を挙げることができる。
この場合,例えば,ドライバー3にメインロボットの軸3が接続されているときには,呼び出し符号+4が,ドライバー3にサブロボットの軸1が接続されているときには,呼び出し符号+6が定められており,当該組み合わせに応じた処理条件が呼びだされる。
上記のデータの読み出し手法により,構成要件Dの文言通り,各ドライバーと各駆動軸との対応関係に応じてドライバーの処理条件を決定することができ,この場合,分配記号,EXテーブルは何ら必要とされず,処理条件記億部のみが必要とされる。
また,上記のデータの読み出し手法は,本件明細書に記載されている実施例を特許請求の範囲の記載に合わせて単に簡略化したものであるから,本件明細書の実施例の単なる設計変更にすぎないものである。
そもそも,本件発明1の出願当時においては,1つのコントローラで複数のロボットを制御するという発想及び1つのコントローラでドライバーと駆動軸との種々の対応関係に応じて処理条件を自動的に決定するという構成そのものが奇抜であり,これらの構成により制御装置を大きく進化させたものである。
すなわち,本件発明1は,「従来のこの種のロボット制御装置においては,1つのロボットに対して1つのコントローラが設けられてい」たことに対して,「1つのコントローラで複数のロボットを制御す」ることを目的としている(【0004】)。
たとえば,1つのロボットが6軸を有する場合には,「移動命令でPTP(ポイントツーポイント)による移動位置が指定されると,その移動位置(例えばP1)に応じてコントローラ内でP1=(P1a,P2b,P3c,P4d,P5e,P6f)というように6軸分の移動量が求められ,それに応じた各ドライバーの制御が一括的に行われる。」(【0005】)。
ところが,仮に4軸を有するロボット1と2軸を有するロボット2をコントローラに接続し制御しようとした場合,従来のコントローラでは,1つのロボットを制御するように設計されていることから,6軸分の移動量に従い,6軸全部を動かそうとするため,ロボット1の4軸のみならず,余分なロボット2の2軸を動かしてしまうという事態が生じる。従って,従来のコントローラにおいて,このような事態を回避しようとすれば,移動命令入力の際にロボット1の各軸毎に個別に移動を指定することになる。しかし,ロボットが実用されている場面では,ロボットの動作プログラムのステップ数は,膨大である。従って,膨大なステップ数を入力する過程で,誤って隣接する軸の移動指定データを入力してしまうといった誤入力が生じやすくなるという問題があった(【0005】)。
また,従来のコントローラでは,1つのコントローラで1台のロボットしか制御しなかったために,1台のロボットの各駆動軸が接続されていれば,全ての駆動軸を一括制御するかもしくは各駆動軸の個別毎の制御しかできなかった。
これに対し,本件特許発明では,1つのコントローラで複数のロボットを接続することを目的とし,1つのコントローラに複数のロボットの駆動軸が接続されていても,各駆動軸に対して個別に制御するのみならず,また接続された全軸一括制御するのではなく,ある群としてロボット単位で制御することを目的としている。
また,1つのコントローラに複数のロボットの駆動軸を接続する際に,1つのコントローラの複数のドライバーと複数のロボットの駆動軸の接続を固定化させるのではなく,例えば,2軸を有するロボット1はそのままにして,2軸を有するロボット2と1軸を有するロボット3を入れ替えたり,2軸を有するロボット1と同じく2軸を有するロボット2を入れ替えたりすることができ,「制御する複数のロボットの軸数,組合せ等が種々変わった場合にも汎用すること」を目的としている(【0006】)。
上記本件特許発明の目的との関係では,呼び出し方法自体は,対応関係に応じた処理条件を読み出すことができさえすればよいのであって,分配記号およびEXテーブルを用いた処理条件の決定方法は,このような本件発明1の実施形態の一例にすぎない。
従って,構成要件Dにおいて,下位概念の一例に過ぎない分配記号およびEXテーブルに言及しないのは当然であって,特許法第36条第5項第2号に違反するものではない。
(3-4)構成要件Fに関して
構成要件F中の「上記各属性記憶手段」は,当然に構成要件Cの「各軸属性記憶部」を意味する。これは,発明の詳細な説明の中の「上記各軸属性記億部46には,各ドライバーに対応するロボット軸の属性が図3に示すような軸定義フラッグADFとして記憶されており,」(【0018】)との記載,および「そして,前記移動命令判別手段44により,上記軸選択フラッグASFと軸定義フラッグADFとの照合等に基づいて移動命令が判別されるようになっている。」(【0024】)との記載から明らかである。

第5.無効理由についての当審の判断

ア.無効理由1について

「各ドライバーと複数のロボットの各駆動軸との対応関係」自体は、各ドライバーが各駆動軸のモータに対応していることを示すものであり、各ドライバーが各駆動軸のモータに個々に接続され、軸駆動の電力を供給していることを鑑みれば、もとより自明な事項である。そして、軸定義フラッグADFに関して、発明の詳細な説明に、上記対応関係が書き換え可能に記録されていると記載されている点(明細書の【0018】?【0020】)をみれば、「対応関係を変更可能に設定する設定手段」は、上記対応関係が記録され、その記録された対応関係が対応関係の変更に応じて、書換え作業が手作業にしろ自動設定であるにしろ、書き換え可能であることを示すのは明らかであって、構成要件Bに関して、本件明細書に、当業者にとって実施することができない程の記載不備はない。
請求人は「対応関係を変更可能に設定する」という文言をとらえ、各ドライバーと各駆動軸のモータの個々の接続関係を変更することに関して、本件特許明細書の記載が当業者が容易に実施することができる程度に記載されていないと主張しているが、本件発明の複数ロボットの制御装置が、上記接続関係自体を変更することを意図したものでなく、対応関係を制御装置内に設定しているものであることは明らかである。
したがって、特許請求の範囲の記載は、構成要件Bに関して、特許法第36条第4項に規定する要件を満たしていないとすることはできない。

イ.無効理由2について

無効理由1についての判断で示したように、特許請求の範囲の記載は構成要件Bに関して、発明の詳細な説明に記載(明細書の【0018】?【0020】)したものである。
したがって、特許請求の範囲の記載は、構成要件Bに関して、特許法第3
6条第5項第1号に規定する要件を満たしていないとすることはできない。

ウ.無効理由3について

構成要件Bに関して、特許請求の範囲の記載は、無効理由1についての判断で示したと同様に、対応関係を変更可能に設定する点に関して明確である。
構成要件Cに関して、特許請求の範囲の記載は、「上記対応関係の設定」が表す点は、「ア.無効理由1について」で述べたように明らかである。また、「各ドライバーに対応する駆動軸の属性を示すデータ」は、上記対応関係が変更されればドライバーに対応する駆動軸も変更され、駆動軸の属性もそれに応じて変更されるものであることは明らかであるから、その変更に応じて、軸属性記億部が各軸の属性を「書き換え可能に」記憶するということであり、明確である。
構成要件Dに関して、特許請求の範囲の記載は、ドライバーの処理条件を決定する処理条件決定手段が、構成要件Bで設定されたドライバーと駆動軸の対応関係の変更に応じて、すなわち、分配設定手段41の変更に対応してドライバーの処理条件を決定するというものであり、ドライバーの処理条件を決定する点に関して、明確である。
構成要件Fについて、特許請求の範囲の記載は、移動命令判別手段がドライバーを選定するにあたって、読み出したドライバーの属性に関するデータと移動命令入力手段により入力されたデータと照合するものであるから、同記載の「各属性記憶手段」が示すのは、本件特許の明細書の【0024】の記載、及び、図面の図2の記載から、構成要件Cの「上記対応関係の設定に基づいて各ドライバーに対応する駆動軸の属性を示すデータを書き換え可能に記憶する各軸属性記億部と、」で示される「各軸属性記憶部」であることは、明らかであり、構成要件Fの「各属性記憶手段」は「各軸属性記憶部」の明らかな誤記である。(第一回口頭審理調書参照。)

以上のとおり、特許請求の範囲の記載に関し、特許法第36条第5項第2号に規定する要件を満たしていないとすることはできない。

第6.むすび
したがって、本件発明1は、平成2年改正特許法第36条第4項、同第36条第5項第1号、同第36条第5項第2号の規定によっては特許を受けことができないものとすることはできない。
審判に関する費用については、特許法第169条第2項の規定で準用する民事訴訟法第61条の規定により、請求人が負担すべきものとする。
よって、結論のとおり審決する。
 
審理終結日 2011-03-08 
結審通知日 2011-03-14 
審決日 2011-03-28 
出願番号 特願平5-38288
審決分類 P 1 123・ 534- Y (B25J)
P 1 123・ 531- Y (B25J)
最終処分 不成立  
前審関与審査官 八木 誠  
特許庁審判長 野村 亨
特許庁審判官 菅澤 洋二
遠藤 秀明
登録日 2004-04-09 
登録番号 特許第3542615号(P3542615)
発明の名称 複数ロボットの制御装置  
代理人 曽根 翼  
代理人 牛久 健司  
代理人 大月 伸介  
代理人 山崎 道雄  
代理人 椙山 敬士  
代理人 藤野 睦子  
代理人 小松 陽一郎  
代理人 大澤 恒夫  
代理人 福田 あやこ  
代理人 宇田 浩康  
代理人 片山 史英  
代理人 小谷 昌崇  
代理人 樋口 次郎  
代理人 市川 穣  
代理人 辻村 和彦  
代理人 小谷 悦司  
代理人 島野 美伊智  
代理人 佐藤 興  
  • この表をプリントする

プライバシーポリシー   セキュリティーポリシー   運営会社概要   サービスに関しての問い合わせ