【事件の表示】
　平成　５年特許願第　８９８０２号「知識獲得装置及びその方法」拒絶査定に対する審判事件［平成　６年　２月　４日出願公開、特開平　６−　２８１８９］について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
　本願は、平成　５年　４月１６日（パリ条約による優先権主張１９９２年４月１６日，米国）の出願であって、その請求項１乃至１９に係る発明は、平成８年４月３０日付けの手続補正書により補正された明細書及び図面の記載からみて、その特許請求の範囲の請求項１乃至１９に記載された事項により特定されるとおりのものであると認める。
　これに対して、当審において、平成１３年　８月　８日付けで次のとおりの拒絶理由を通知し、期間を指定して意見書を提出する機会を与えた。
　
「本件出願の下記の請求項に係る発明は、その出願前日本国内または外国において頒布された刊行物に記載された発明に基づいて、その出願前にその発明の属する技術分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　　　　　　　　　　記　
１．手続きの経緯・請求項１乃至１９に係る発明
　本願は、平成５年４月１６日（優先権主張１９９２年４月１６日、米国）の出願であって、その出願の請求項１乃至１９に係る発明は、平成８年４月３０日付けで補正された明細書及び図面の記載からみて（平成８年１１月１３日付けの手続補正は却下された）、その特許請求の範囲の請求項１乃至１９に記載されたとおりのものと認められるところ、その請求項１の記載は次のとおりである。（以下、請求項１に係る発明という）
「問題の解決に当たって知識を供給する知識ベースを構築する知識獲得装置において、
　知識構造化手段と、関連づけ手段と、知識集約手段と、モジュール接続手段とを具備し、
　知識構造化手段が問題を細分して、モジュール及び知識源をそれぞれ複数個形成し、各モジュールが知識源の一つを問題の解決作業の一部に適用することに関する入出力関係から成り、
　関連づけ手段が特定の述語を入出力関係に関連づけ、
　知識集約手段がモジュールに解決させるテスト・ケース及びモジュールがテスト・ケースを解決する際に使用する知識成分を知識源から繰り返し取り出し、
　モジュール接続手段がモジュール相互を接続して、モジュール間の情報の流れ及びモジュールの実行順序を制御し、
　モジュールを相互に接続する前に個々のモジュールが生成する解決が正しいか否かの検証に複数個のテスト・ケースを使用するだけでなく、モジュールを相互に接続した後に相互接続されたモジュシュールが全体として生成する解決が正しいか否かの検証にも複数個のテスト・ケースを使用する知識獲得装置。」
　
２．引用例
　特開平４−１１１１２８号公報 （引用例１という。）には、〈作用〉の欄に、全体の知識を部分知識に分割し、それに適した方法で知識を表現するというモデルに従って知識ベースを構築してゆく。このようにして全体の知識を部分知識分割してその外部インタフェースを定めることにより、モジュール性と保守性のよい知識ベースを構築することができると記載され、第１図に発明の原理フローが示され、〈問題を解決するための手段〉の欄に、次のように記載されている。
（１）適当な部分問題を選択する。ただし、最初は問題全体について考える。
（２）外部仕様概要設計を行なう。すなわち、上記（１）で選択した部分問題をその性質および構造に応じて更に部分問題に分割し、依存関係を明らかにする。・・・
（３）分割された部分問題の内の適当な部分問題を選択する。
（４）外部仕様詳細設計を行なう。すなわち、前記（３）で選択した部分問題について、その問題の依存関係に対応させ、実現を考慮し外部インタフェースを定める。・・・
（５）外部仕様詳細設計を終えた部分問題の中から適当な部分問題を選択する。
（６）内部実現概要設計を行なう。すなわち、実現形態を規定する。このとき、他の部分問題にメッセージを送る場合、その外部インタフェースが規定されない場合は前記（４）へ戻る。・・・
（７）内部実現詳細設計を行なう。すなわち、部分的にエディット・実行・テストを行い、その問題の完成度を高める。・・・
（８）内部実現詳細設計が完成していない部分問題がある場合は（３）に戻りすべてが完成していれば終了する。
　
　特開平３−１２５２２５号公報（引用例２という。）には、前記引用例１に記載された発明と同様の部分を含む発明が記載されている。引用例２の［発明が解決しようとする課題］の項に、
「・・・本発明においては、知識ベースの構築を２段階に分けて考え、まず最初にビルディングブロックとよぶモジュールを作成しておき、さらにビルディングブロックを組合せて全体を構築するという考えをシステム化している。さらに、これを効率よく行なうために、個々のビルディングブロックの検証と、組合せを対話型で行なえるようにしている。」と記載され、
［実施例］の項には、次のように記載されている。
「・・・第１図に示すプロトタイピング指向ＡＩツールは、ビルディングブロック（以下ＢＢと省略する）を構築するビルディングブロック構築システム１、ＢＢを検証するビルディングブロック検証システム２、ＢＢを登録するビルディングブロックデータベース３、対話型にＢＢを組合せ、かつ組合せた結果の検証を行なうビルダー４と、全体の制御を行なう制御システム５からなる。
　ＢＢは、第２図に示すようなオブジェクトである。これから分るように、ＢＢとは推論を行なう最小単位であり、推論メソッドと推論に使用する知識ベースのアドレスが記述されている。このＢＢで持たれるのは知識と推論方法だけであり、推論に使用するデータや問題は、自分自身で抱え込むことも出来るし、また他のＢＢからメッセージとして受け取ることもできるため、ブロックの汎用性が高くなっている。従って、あるＢＢの振舞は、自分自身で規定することもできるし、他のＢＢから規定することもできる。以下では、ＢＢの要素の詳細を説明する。
　まず、知識ベースであるが、ルールとフレームと手続きが記述できる。これらを混合して記述することはできない。従って、知識ベースの種類が異なれば、別のＢＢとして記述しなければならない。同一種類の知識ベースは複数個指定することができ、さらに知識ベース制御スロットにその使用法を定義できる。逐次型と定義すると、推論メソッドに書かれている推論方法が、知識ベーススロットに定義された順に知識ベースに適用される。並列型を指定すると一括して推論が適用される。適用される推論には、前向き推論、後向き推論・・（中略）・・標準的なものである。問題スロットには、たとえば後向き推論である事象が検証されるか否かといったようなものがはいる。
　ビルディングブロック構築システム１はＢＢを開発するためのシステムである。・・（中略）・・上に述べた知識ベースや、推論メソッドを埋めていけば、自動的に計算機に扱えるような形式になり、更に、ビルディングブロックデータベース３に登録される。また、ユーザにより指定されたＢＢがすでにビルディングブロックデータベース中に存在していれば、修正動作の要求とみなして、ビルディングブロックデータベースから読んできた内容をシート上に予め表示し、ユーザにそれを修正させる。・・（中略）・・
　ビルディングブロック検証システム２は、ＢＢの検証を行なう環境である。ユーザがこのシステムにはいり、ＢＢ名を指定すると、自動的にＢＢが実行される（第６図）。この結果が正しいかどうかの判断はユーザに委ねられる。また、メッセージなどで与えられる項目については、実行中に不足データの擬似発生をユーザに要求する。
　例えばビルディングブロックがプラントから信号を取り込んできて、異常診断をおこなうようなものであったとする。
　このとき検証システムにはその信号がないので、その信号の解析結果（例えば温度の時系列から、温度が上昇しているという事象を作る）を疑似的にユーザに求める。
　具体的にはシステムは、このような事象の一覧を画面上に表示し、ユーザに選択させるという方法をとる。
　このシステムには、個々の推論を段階的に実行したり、メッセージの評価や推論過程をトレースする機能を持つ。
　個々のＢＢの検証が終わると、ビルダー４を用いて全体の組立てを行なう。
　ビルダー４は第７図のような構造を持つ。ビルダー４は対話型にＢＢを実行するという役割を果たすが、それは対話を司る対話型ビルディングブロックシュミレータ８、各ＢＢに当てられたメッセージを格納しているメッセージストッカ９、およびＢＢを実行するビルディングブロックインタプリタ１０から構成される。ビルダーの動作を具体的に示すと以下のようになる。まずユーザは対話型ビルディングブロックシュミレータ８を起動し、実行するＢＢを決定する。すると、シミュレータ８がデータベース３より当該ブロックを検索して取り出してくる。ここで、ＢＢにはそのブロックに対して外部（別のブロック）からの信号（メッセージ）が送られたときどのように振舞うかが記述されている。メッセージには、受信ＢＢに対するブロックに対する伝達情報がかかれている。つぎに、シミュレータ８はメッセージストッカ９を参照し、当該ブロックに当てられたメッセージ（すなわち受信ＢＢが当該ＢＢのメッセージ）を捜し出し、伝達情報を取り出す。メッセージストッカは第８図のメッセージ名、発信ＢＢ、受信ＢＢ、メッセージ内容、タグからなる。・・・これだけのデータが揃うと、そのデータはビルディングブロックインタプリタ１０に渡される。インタプリタはブロックの内容に伝達情報を適用し（これはプログラムにデータを適用するイメージ）、ブロックを実行する。ブロックの結果を他のブロックに反映させるのは、メッセージを介して行われる。すなわち、ブロックは実行結果をメッセージとし、シミュレータに渡す。シミュレータはこれを受取り、発信ＢＢ、受信ＢＢ、メッセージの種分けして、・・・メッセージストッカに収納する。
　動作がうまくいかないときには、シミュレータ１０からユーザがメッセージストッカの内容を一時的に書替え、シミュレーションすることも可能である。
　ビルダーでは、この繰返しにより、メッセージ交信を擬似的に模擬し、シミュレーションを行なう。対話型ブロックビルディングシミュレータでメッセージの修正をした場合には、満足のいく結果が得られたのち、再びビルディングブロック構築システムに戻り、ビルディングブロックを修正し、検証する。」
　また、第２図にはＢＢの構成を示す次の記載が見られる。
ＢＢ名　　　　　ビルディングブロックの名前
知識ベース　　　当該ビルディングブロックで扱う知識ベース
　　　　　　　　ルール／フレーム／手続きが書かれる
推論メソッド　　当該ビルディングブロックで行なう推論の種類
　　　　　　　　前向き推論／後向き推論／双方向推論／仮説推論／フレーム検索があ　　　　　　　　　る
メソッド　　　　推論が終了したときに、実行するメソッドを記述する
　　　　　　　　メソッドは、次の二つに大別できる。
　　　　　　　　（１）自己を制御する
　　　　　　　　（２）他のビルディングブロックにメッセージを送る
知識ベース制御　知識ベースをどのように推論に使っていくかを示す
　　　　　　　　逐次型と並列型がある
問題　　　　　　当該ビルディングブロックで解決される問題が記述される
　
３．対比・判断
　　請求項１に係る発明と引用例２に記載された発明とを対比する。
　引用例２に記載された発明は、最初にビルディングブロックとよぶモジュール（以下、引用例２のビルディングブロックはモジュールという表現に統一する。）を作成しておき、さらにモジュールを組合せて全体を構築するものであって、知識ベースの設計をモジュール化できるので、全体を見通しながら、モジュール単位のプロトタイピングが可能となっており、前記モジュールを組み合わせて全体を構築する場合に、全体としての問題の解決に当たって構築されることは通常の技術的事項（例えば、引用例１参照。他に、必要なら特開平３−４６０３０号公報参照。この公報第１頁右下欄１５行〜第２頁左上欄９行には、ＡＩツールは、問題解決における思考プロセスを単位化し、各単位プロセスの問題に対して専用的に知識を表現し・・・ライブラリを統合し、問題解決のシナリオを作成する旨記載されている。）であって、引用例２に示されているに等しい事項であり、また、モジュール構築システム１は、モジュールを開発するためのシステムであり、シートを用いて知識を入力乃至修正入力する旨の記載があることから、これは知識の獲得をしているといえるので、引用例２に記載された発明は、請求項１に係る発明の「問題の解決に当たって知識を供給する知識ベースを構築する知識獲得装置において」に相当する要件を備えている。
　また、引用例２に記載された発明は、前記のように全体の問題解決に当たって複数のモジュールに分けられると解され、各モジュールは、第２図に示すようなオブジェクトであり、各モジュールにはそのモジュールに対して外部（別のモジュール）からの信号（メッセージ）が送られたとき（入力されたとき）どのように振舞うかが記述されていて、モジュールに持たれている知識と推論方法による推論がされて、つまり問題の一部が解決されて、次のモジュールにその推論結果が出力されると解され、このモジュールにおいては、第２図の知識ベース（ルール／フレーム／手続き；属性、述語に対応する。）が記述されていて、当該モジュールへの入力に対して推論メソッドに書かれている推論種類の方法が特定の知識ベースに適用され前記入力と知識ベースとが関連付けられることを含むと解されるので、請求項１に係る発明の「知識構造化手段と、関連づけ手段とを具備し」の要件、「知識構造化手段が問題を細分して、モジュール及び知識源をそれぞれ複数個形成し、各モジュールが知識源の一つを問題の解決作業の一部に適用することに関する入出力関係から成り」の要件、及び「関連づけ手段が特定の述語を入出力関係に関連づけ」の要件を備えている。
　また、引用例２に記載された発明は、個々の推論を段階的に実行したり、メッセージの評価や推論過程をトレースする機能を持つモジュール検証システム２を備え、個々のモジュールの検証が終わると、ビルダー４を用いて全体の組立が行われる。ビルダー４では、モジュールの内容に伝達情報を適用してモジュールの実行を行い、実行結果を他のモジュールに反映させ、これは、メッセージを介して発信モジュール、受信モジュールを指定してメッセージを交信して行い（この指定、交信はモジュールが接続されていることに相当）、このような動作を繰り返してモジュールの実行結果を受信モジュールに送り（モジュールの実行順序を制御することに相当）、対話型モジュールシミュレータでメッセージの修正をした場合には、満足のいく結果が得られたのち、再びモジュール構築システムに戻り、モジュールを修正し、検証する。そして、引用例２に記載された発明は、前記のように、個々のモジュールに対してモジュール構築システムにより知識の入力修正ができるとともに、モジュールの組立られた全体に対する一種の試験であるシミュレーションによる結果をみて、モジュール構築システムにより知識の入力修正が可能であると解されるので、請求項１に係る発明の「知識集約手段と、モジュール接続手段とを具備し、」の要件、「モジュール接続手段がモジュール相互を接続して、モジュール間の情報の流れ及びモジュールの実行順序を制御し、」の要件、及び「モジュールを相互に接続する前に個々のモジュールが生成する解決が正しいか否かの検証だけでなく、モジュールを相互に接続した後に相互接続されたモジュシュールが全体として生成する解決が正しいか否かの検証をする知識獲得装置」の要件を備えている。
　したがって、請求項１に係る発明と引用例２に記載された発明とは、
「問題の解決に当たって知識を供給する知識ベースを構築する知識獲得装置において、
　知識構造化手段と、関連づけ手段と、知識集約手段と、モジュール接続手段とを具備し、
　知識構造化手段が問題を細分して、モジュール及び知識源をそれぞれ複数個形成し、各モジュールが知識源の一つを問題の解決作業の一部に適用することに関する入出力関係から成り、
　関連づけ手段が特定の述語を入出力関係に関連づけ、
　モジュール接続手段がモジュール相互を接続して、モジュール間の情報の流れ及びモジュールの実行順序を制御し、
　モジュールを相互に接続する前に個々のモジュールが生成する解決が正しいか否かの検証だけでなく、モジュールを相互に接続した後に相互接続されたモジュシュールが全体として生成する解決が正しいか否かの検証にもする知識獲得装置。」
である点で一致し、次の（１）、（２）の点で相違する。
相違点
（１）請求項１に係る発明は、知識集約手段がモジュールに解決させるテスト・ケース及びモジュールがテスト・ケースを解決する際に使用する知識成分を知識源から繰り返し取り出すのに対し、引用例１のモジュール構築システムとモジュール検証システムはそれがない点。
（２）個々のモジュールが生成する解決が正しいか否かの検証と、モジュールを相互に接続した後に相互接続されたモジュシュールが全体として生成する解決が正しいか否かの検証に関して、請求項１に係る発明は、複数個のテスト・ケースを使用するのに対し、引用例１にはそのようなテストケースの使用は記載されていない点。
 当審判断
相違点（１）に対して
  エキスパートシステムなどのルール型システムにおいて、ルール獲得手段（知識集約手段）がオブジェクト（モジュール）に対していろいろなサンプルケース（テスト・ケース）を与えて実際に推論させ、ユーザ知識（ユーザやシステム構築者が提供する知識は知識源に相当する）によるルール（知識成分）の追加、質問・応答の入力、データ入力方式の設定などが行われ、この作業を多くのサンプルケースについて十分繰り返す（繰り返し取り出す）ことにより、ルールを獲得すること（特開平３−２８６２２７号公報第２頁左下欄７〜右下欄４行に記載の内容を要約）乃至、ルール獲得部１０１がパラメータ表現定義記憶部１０９の情報に基づき一般化し自動的にルールを作成すること（特開平２ー１１８７３０号公報第４頁左上欄１７〜１９行）は公知の技術であって、しかも、ルール型システムにおいて知識獲得の機能を付加するのは普通の発想にすぎず、知識獲得の機能を付加することに何ら阻害される要因があるわけでなく、引用例２のモジュール構築システムとモジュール検証システムを有するシステムにおいて、前記公知のサンプルケースを用いる技術を参酌することにより、知識集約手段がモジュールに解決させるテスト・ケース及びモジュールがテスト・ケースを解決する際に使用する知識成分を知識源から繰り返し取り出すようにすることは当業者が容易になし得ることである。
相違点（２）に対して
　引用例２に記載された発明は、前記３．対比・判断の項で言及したように、個々のモジュールが生成する解決が正しいか否かの検証と、モジュールを相互に接続した後に相互接続されたモジュシュールが全体として生成する解決が正しいか否かの検証を行うものであり、前記相違点（１）におけるモジュールの検証につきサンプルケースを用いる技術を参酌するのと同様に、モジュールを相互に接続した後の相互接続されたモジュールに対して行う検証にサンプルケースを用いることに何ら阻害される要因はなく、引用例２において、前記公知のサンプルケースを用いる技術を参酌して、個々のモジュールが生成する解決が正しいか否かの検証と、モジュールを相互に接続した後に相互接続されたモジュシュールが全体として生成する解決が正しいか否かの検証に、複数個のテスト・ケースを使用することは当業者が容易になし得ることである。
　
 請求項２乃至６に係る発明に対して
　知識源として、前向き／後向き連鎖規則、典型例、木構造、ニューラルネットワークは本願出願前既知であり当業者が適宜採用し得ることである。
　
請求項７に係る発明に対して
　引用例１には適宜テストすることが示されている。所定の間隔でモジュールにテスト・ケースを供給する手段をさらに具備することは当業者が適宜採用し得ることである。その効果も当然予想される範囲内のものと認められる。
　
請求項８、９に係る発明に対して
　引用例２には、対話型ブロックビルディングシミュレータでメッセージの修正をしながらメッセージ交信を擬似的に模擬し、繰返し、満足のいく結果が得られたのち、再びビルディングブロック構築システムに戻り、ビルディングブロックを修正し、検証する旨説明されており、モジュール相互接続関係を試験することが記載されているといえ、また、検証は必要な部分に必要な時行えばよいことであるので、試験を知識集約手段が一連のテスト・ケースにより試験するとすることは当業者が適宜なし得ることである。
　また、知識源はデータから得られる知識である点は、前記のように特開平２−１１８７３０号公報に、ルール獲得部１０１がパラメータ表現定義記憶部１０９の情報に基づき一般化し自動的にルールを作成することが示されていることから既知であり当業者が適宜採用し得る事項である。
請求項１０に係る発明に対して
　テストケースを自動的に生成する手段は既知と認められる。
　
請求項１１乃至１８に係る方法の発明に対して　
  請求項１乃至１０に係る装置の発明と同様のことがいえるので、前記引用例から当業者が容易になし得る。
　
請求項１９に係る発明に対して
　知識ベースをモジュールに分解する点は、引用例１乃至２に、異なるモジュールに異なる推論エンジンを持たせることが可能なことは引用例２に（これは特開昭６３−６２０３８号公報の［概要］の欄にも記載されている様に既知）、モジュールに分解して各モジュールに対してテストケースを適用する点も引用例１乃至２に示されている。
　請求項１９に係る装置の発明に対しては、請求項１と同様のことがいえ、格別な技術思想をともなう構成もなく、当業者が容易になし得る。」
　しかしながら、請求人からは何らの応答もない。
　そして、上記の拒絶理由は妥当なものと認められるので、本願は、この拒絶理由によって拒絶すべきものである。
よって、結論のとおり審決する。