【事件の表示】
　平成　６年特許願第　３４４５４号「マルチエージェント協調システム及びその方法」拒絶査定に対する審判事件［平成　７年　１月１０日出願公開、特開平　７−　　６１４２］について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１.本願は、特許法第４１条に基づく優先権主張を伴う平成６年３月４日（優先日：平成５年４月２０日、出願番号：特願平５−９２６８４号）の出願であって、平成１４年１２月４日付けの手続補正書によって補正された明細書の特許請求の範囲に記載されたとおりの「マルチエージェント協調システム及びその方法」に関するものである。
　
２.当審が平成１４年１０月７日付けで通知した拒絶理由は、
「本件出願は、明細書及び図面の記載が下記の点で不明りょうであるので、特許法３６条４項又は５項及び６項に規定する要件を満たしていない。
　　　　　　　　　　　　　　　　　　記
（１）明細書及び図面の記載では、従来の欠点をどのようにして解決するのかその具体的手段が明確でなく、本願発明は当業者が容易に実施できる程度に明細書及び図面が記載されているとは認められない。
（ａ）段落【００４３】に、「【作用】この発明におけるマルチエージェント協調方法では、プランニングと資源割当とを分離して定義する手段と両問題を明確に分割された二つの処理段階で解く手段とにより、・・・システム全体の仕様が単純になる。」と記載されているが、「プラニング」と「資源割当て」を明確に分離するための具体的手段が、明細書及び図面を参照してもどのようなものか理解することができない。
（ｂ）段落【００４４】に、「また、協調動作を行うエージェントのメンバの集合とエージェント間の協調の手順に関する仕様を、要素機能の定義、プランの定義とは分離して定義する手段と、その定義にしたがってエージェントが協調動作を行なう手段により、協調の定義と処理が単純化され、協調に関して各エージェントの仕様やシステム全体の仕様が単純になる。」と記載されているが、「その定義にしたがってエージェントが協調動作を行なう手段」がどのようなものでどのようにして協調動作をおこなうのか、明細書及び図面を参照して理解できない。
（ｃ）（省略）
（ｄ）図２に示されるフィールドマネージャの具体的構成及びその動作が不明りょうである。特に、協調定義データベース６がどのようなものでどのようにしてそのデータを生成するのか明細書を参照しても明確でない。
（ｅ）図３に示されるプラニングエージェントの具体的構成及びその動作が不明りょうである。特に、ルールベース９及び評価用データ格納部１１がどのようなもので、どのようにしてこれらを生成するのか明細書を参照しても明確でない。
 また、プラニング実行部１０がどのようにしてプラニングを実行していくのか明細書を参照しても良く理解できない。
（ｆ）（省略）
（２）特許請求の範囲の記載と発明の詳細な説明の記載との対応関係が明確でない。
（ａ）請求項１に「ユーザから要求されたサービスを達成する要素機能あるいは要素機能と結びつけられた資源の稼働状態若しくは負荷状況の均衡を保つように要素機能に対してサービスを達成するためのタスクを配分する問題である資源割当とを切り離し、ユーザからの要求に対して解くべき前記各問題を分割して処理する」と記載されているがこの記載は発明の詳細な説明及び図面のいずれの箇所の記載に基づくものか明りょうでない。
（ｂ）請求項３に「保持したプランに関する定義に従いユーザからの要求に応じたサービスを実行するためのプランを生成し、その生成したプランに基づきサービスを実行するために必要な仕事を前記要素機能エージェントに割り振る能力を有する１ないし複数のプランニングエージェントと、」と記載されているが発明の詳細な説明及び図面を参照してもどのようにしてこの構成を実現するのか明確でない。また、「前記フィールドマネージャは、前記プランニングエージェントからのプラン及び前記要素機能エージェントからのプランに基づく仕事の負荷の評価に基づき総合評価を行うことで協調動作をさせる」と記載されているが発明の詳細な説明及び図面を参照してもどのようにしてこの構成を実現するのか明確でない。（以下、省略）」というものである。
　
３.これに対して、審判請求人は、平成１４年１２月４日付けで意見書及手続補正書を提出し、これによって記載不備は解消した旨の主張をしている。そこで、意見書の主張及び手続補正書の補正内容を参酌して拒絶理由で通知した記載不備が解消されたか否かを検討する。
　．（１）（ａ）で指摘した記載不備について
  審判請求人は、意見書において、「まず、上記（１ａ）に記載したご指摘に関してですが、「プランニング」と「資源割当」とは、予め分割して定義されていることは前述したとおりです。従いまして、「プランニング」と「資源割当」を明確に分離するための具体的手段は存在しないことが明確になるように第００４４段落を補正致しました。」と主張している。しかしながら、意見書の主張及び明細書の記載によっても、「プラニングエージェント」と「要素機能エージェント」とがどのようにして「プラニング」問題と「資源割当」問題を全く独立して処理していくのか明りょうでない。この点に関して、審判請求人が本願発明をより分かり易くするために意見書で挙げた具体例（プロジェクト会議の開催）の、「(s６)各会議設定エージェントは、各要素機能エージェントからの回答に基づき結果が得られればプランを生成して会議設定フィールドへ返す。」の記載では、「各会議設定エージェント」（本願発明の「プラニングエージェント」に相当）は、会議のプランだけでなく、会議室の割当て（本願発明の「資源割当」に相当）のプランも立てているものと認められるので、本願発明が、「プランニング」の問題処理と「資源割当」の問題処理を別々のエージェントで行なえる構成となっていることの説明とはなっていない。また、「(ｓ７)会議設定フィールドは、会議設定エージェントＡ，Ｂから返されてきたプランを受け取る。返されてくるプランは複数なので、会議設定フィールドは、自分の持つ評価基準あるいはユーザに問い合わせることにより評価結果を得て、評価の高いプランを決定します。」の記載では、会議設定フィールド（本願発明の「フィールドマネージャ」に相当）が最終的な決定を行っているので、資源割当ての問題処理は、会議設定フィールド（本願発明の「フィールドマネージャ」に相当）と会議設定エージェント（本願発明のプラニングエージェント」に相当）が行っていることになり、各機能要素エージェント（本願発明の「要素機能エージェント」に相当）が資源割当ての問題処理を行っているとは認められない。
　したがって、拒絶理由通知書の（１）（ａ）で指摘した記載不備は依然として解消していない。
　
　．（１）（ｂ）で指摘した記載不備について
　審判請求人は、意見書において、「次に、上記（１ｂ）に記載したご指摘に関してですが、本発明においては、協調動作を行うエージェントのメンバの集合とエージェント間の協調の手順に関する仕様の定義にしたがってプランニングエージェントと要素機能エージェントとに協調動作を行わせるのはフィールドマネージャです。（第００５６段落、第００６３段落第３行乃至第６行）。仕様の定義には、エージェント間の協調の手順が記述されているので、フィールドマネージャは、ユーザからの要求に応じたサービスを提供する際に、この定義内容に従い協調動作を行わせるプランニングエージェントと要素機能エージェントとを特定し、協調動作を行わせます。今回は、この点が明確になるように第００４４段落を補正致しました。」と主張すると共に、明細書の００４４段落を「【００４４】また、協調動作を行うエージェントのメンバの集合とエージェント間の協調の手順に関する仕様を、要素機能の定義、プランの定義とは分離して定義されており、フィールドマネージャは、ユーザからの要求に応じたサービスを提供する際に、その定義にしたがってエージェントに協調動作を行なわせるようにしたので、協調の定義と処理が単純化され、協調に関して各エージェントの仕様やシステム全体の仕様が単純になる。」と補正した。
　しかしながら、上記意見書の主張及び明細書の補正では、どのようにして協調の手順に関する仕様を決めるのか不明りょうであって、結局フィールドマネージャーはどの様な条件の下で、どの様にして、プラニングエージェントと要素機能エージェントに協調動作を行わせるのかが明りょうでない。したがって、拒絶理由通知書の（１）（ｂ）で指摘した記載不備は依然として解消していない。
　
　．（１）（ｄ）で指摘した記載不備について
　審判請求人は、意見書において、「次に、上記（１ｄ）に記載したご指摘に関してですが、フィールドマネージャに関する具体的構成は、第００５６段落及び図２に示しています。本発明では、協調するエージェントのメンバの集合とエージェント間の協調の手順に関する仕様の定義（以下、単に「仕様の定義」）、要素機能の定義及びプランの定義をそれぞれ分離して定義することを特徴の一つとしておりますが（第００６０段落）、協調定義データベース６は、このうちの仕様の定義を格納するものです（第００５６段落）。また、協調定義データベース６に格納される仕様の定義は、予め生成されていることは前述したとおりです。また、フィールドマネージャにおける動作は、上記具体例により明確になっていると確信しています。本願明細書においては、図５に示したとおりであり、ユーザからのサービス要求をユーザインタフェースを介して受け取り（ステップ２１）、プランニングエージェント３に対して協調に関する指示を付加してサービス要求を渡し（ステップ２２）、プランニングエージェント３および要素機能エージェント４が返してきた上記評価結果を総合評価し（ステップ２７）、フィールドマネージャ２が上記総合評価の結果から実際にサービスを達成するための仕事を依頼するプランニングエージェント３を決定し通知します（ステップ２８）。」と主張している。
　しかしながら、審判請求人が本願発明をより分かり易くするために挙げた具体例（プロジェクト会議の開催）を参照しても、フィールドマネージャ２内の協調定義データベースがどのようなもので、どの様にしてそのデータベースを生成するのか不明りょうであって、拒絶理由通知書の（１）（ｄ）で指摘した記載不備は依然として解消していない。
  
　.（１）（ｅ）で指摘した記載不備について
　審判請求人は、意見書において、「次に、上記（１ｅ）に記載したご指摘に関してですが、プランニングエージェントに関する具体的構成は、第００５７段落及び図３に示しています。本発明では、仕様の定義、要素機能の定義及びプランの定義をそれぞれ分離して定義することを特徴の一つとしておりますが（第００６０段落）、ルールベース９は、このうちのプランの定義（プランを生成するための規則）を格納するものです（第００５７段落）。プランの定義が予め生成されていることについては、前述したとおりです。プランの定義の具体的内容は、依頼される仕事の処理手順（上記例のプラン（１）〜（５）によって異なってくるものであり、いずれにせよ、予め生成しておくことになります。また、評価用データ格納部１１は、フィールドマネージャ２からのメッセージに含まれた依頼を評価するための評価基準を格納するものです。評価基準については、第００６４段落に記載しており、上記具体例においては（ｓ３）で評価基準を使用しています。評価基準は予め設定されていることも上記（４）から明らかです。更に、プランニング実行部１０においてどのようにしてプランニングを実行していくかは、上記具体例により明確になっていると確信しています。本願明細書においては、図５に示したとおりであり、サービス要求とフィールドマネージャからの指示に従いプランニングを行い（ステップ２３）、評価結果が規定の基準に達しさらにプランが得られたかを判定し（ステップ２４）、要素機能エージェント４に対して負荷に関する評価を依頼し（ステップ２５）、フィールドマネージャ２が総合評価（ステップ２７）を行うために要素機能エージェントによる評価をフィールドマネージャ２へ返し、依頼を受けたときに生成したプランに従って要素機能エージェント４と処理を実行します（ステップ２９）。」と主張している。
　しかしながら、段落００５７，段落００６０の記載及び審判請求人が本願発明の説明を分かり易く説明するために挙げた具体例（プロジェクト会議の開催）を参照しても、プランニングエージェント内のルールベース９及び評価用データ格納部１１がどのようなもので、どのようにしてこれらを生成するのか不明りょうであって、拒絶理由通知書の（１）（ｅ）で指摘した記載不備は依然として解消していない。
　
　.（２）（ａ）で指摘した記載不備について
　審判請求人は、意見書において、「次に、上記（２ａ）に記載したご指摘に関してですが、請求項１の引用された記載箇所は、第００５９，００６０段落、図５並びに図５を説明した第００６１段落乃至第００６３段落に基づきます。」と主張している。
　しかしながら、明細書の段落００５９には、「ここで、プランニングとは、ユーザから要求されたサービスを達成するための機能の組み合わせと機能間で授受されるデータとそれらを実行する順序であるプランを求める問題をいう。また、資源割当とは、プランを達成する要素機能あるいは要素機能と結びつけられた資源の稼働状態若しくは負荷状況の均衡を保つように要素機能に対してサービスを達成するためのタスクを配分する問題をいう。」と記載され、また、段落００６０には、「本実施例において特徴的なことは、上記プランニングと上記資源割当とを切り離して、前記各問題毎に分割された二段階からなる処理で前記問題を解くことである。更に、協調する上記エージェントのメンバの集合と前記エージェント間の協調の手順に関する仕様の定義、要素機能の定義及びプランの定義をそれぞれ分離して定義し、その定義にしたがって前記エージェントが協調動作を行うことである。これにより、アプリケーションの記述、各定義の変更等が容易に行うことができる。」と記載され、また、段落００６１には、「次に、本実施例におけるエージェントの協調動作を図に基づいて説明する。図５は、本実施例におけるエージェントの協調動作を表すフローチャートである。エージェントの協調動作は、フィールドマネージャ２がユーザからのサービス要求をユーザインタフェース１を介して受け取るステップ２１と、フィールドマネージャ２がプランニングエージェント３に対して協調に関する指示を付加して上記サービス要求を渡すステップ２２と、プランニングエージェント３が上記サービス要求と上記指示に従い評価およびプランニングを行なうステップ２３と、プランニングエージェント３が評価結果が規定の基準に達しさらにプランが得られたかを判定するステップ２４と、プランニングエージェント３が要素機能エージェント４に対して負荷に関する評価を依頼するステップ２５と、要素機能エージェント４が負荷を評価してその評価結果を返すステップ２６と、フィールドマネージャ２がプランニングエージェント３および要素機能エージェント４が返してきた上記評価結果を総合評価するステップ２７と、フィールドマネージャ２が上記総合評価の結果から実際にサービスを達成するための仕事を依頼するプランニングエージェント３を決定し通知するステップ２８と、上記依頼を受けたプランニングエージェント３が上記プランに従って要素機能エージェント４と処理を実行するステップ２９と、からなる。」と記載され、また、段落００６２には、「以下、図５を用いて協調動作の詳細について説明する。」と記載され、また、段落００６３には、「ステップ２１において、フィールドマネージャ２は、ユーザがユーザインターフェース１から入力したサービス要求を通信部５を介して受け取る。ステップ２２において、フィールドマネージャ２は、協調定義データベース６の記述に従って協調動作実行部７が生成した指示を上記ユーザからのサービス要求に付加した情報を通信部５を介してメンバである複数の適当なプランニングエージェント３に対して送る。次にステップ２３において、プランニングエージェント３は、通信部８を介して受けとった上記情報の指示に従い、評価用データ格納部１１の内容に従って評価部１２において上記ユーザから要求されたサービスの仕様を評価し、ルールベース９の内容に従ってプランニング実行部１０において要求されたサービスを実行するためのプランを生成する。次にステップ２４において、プランニングエージェント３は、上記評価の結果が規定の基準に達したかどうか、プランが得られたかどうかを判定する。その結果、評価基準を満たさないか、あるいはプランが得られなければそのプランニングエージェント３は動作を終了する。そうでない場合はステップ２５においてプランニングエージェント３は生成したプランに従って必要な要素機能エージェント４に通信部８を介して負荷やその要素機能エージェント４に付随する装置の位置などに関する評価を依頼する。この時依頼とともに評価のために必要な情報を送る。次にステップ２６において、要素機能エージェント４は、上記依頼を通信部１３を介して受け取り、評価用データおよびプロファイル格納部１６の内容に従って受け取った情報を評価しその結果を通信部１３を介してプランニングエージェント３に返す。次にステップ２８において、フィールドマネージャ２は、上記総合評価の結果に基づいて実際にサービスを達成するための仕事を依頼するプランニングエージェント３を決定し、処理依頼を行なう。次にステップ２９において、依頼を受けたプランニングエージェント３は、上記プランに従い適当な要素機能エージェント４と共に上記仕事を処理していく。」と記載されているだけであって、これらの記載では、請求項１に記載されている「ユーザから要求されたサービスを達成する要素機能あるいは要素機能と結びつけられた資源の稼働状態若しくは負荷状況の均衡を保つように要素機能に対してサービスを達成するためのタスクを配分する問題である資源割当」をどの様にして実現するのか、その具体的手段が発明の詳細な説明に記載されているとは認められない。なお、この点に関して、審判請求人が本願発明をより分かり易くするために意見書で挙げた具体例（プロジェクト会議の開催）に、「(S3)２つの会議設定エージェントＡ，Ｂは、それぞれ持つプランに関する定義に従って、予め設定された評価基準（第００６４段落）に基づき各要素機能エージェント（２つの個人スケジュール管理エージェント、２つの会議室予約エージェント）に要求を投げる（図５のステップ２５）。この処理を詳細に説明すると、以下のようになります。
　例えば、会議設定エージェントＡであれば、プラン(1)に従い個人スケジュール管理エージェントＡ，Ｂ，Ｃそれぞれに要求を投げます。続いて、プラン（２）に従い会議室予約エージェントＡ，Ｂ，Ｃそれぞれに要求を投げます。
　このようにして、会議設定エージェント（プランニングエージェント）は、プランニングという問題を処理します。なお、資源割当は処理していません。この動作は、上記（ｃ）の「保持したプランに関する定義に従いユーザからの要求に応じたサービスの実行に必要な仕事を、・・・前記要素機能エージェントに割り振ることによって、ユーザからの要求に応じたサービスを提供するためにプランニングという問題のみを処理する」に相当します。」の記載がなされ、また、「(ｓ４)各要素機能エージェントは、前述したそれぞれの要素機能を提供することによって、資源割当という問題を処理します。具体的には、個人スケジュール管理エージェントＡであれば、要素機能（１）の「参加者甲のスケジュールを答える」を処理し、会議室予約エージェントＡであれば、要素機能（１）の「Ｘ棟の会議室の予約状況や会議室の特徴を答える。」を処理します。何を実行する、つまり、要素機能（１）を処理すると言うことは、プランニングエージェントと各要素機能エージェントとの間で授受される要求の内容に従い特定できます。なお、要求等の情報交換自体は、マルチエージェント協調システムにおける周知技術により実現されるものです。ここでは、資源割当という処理を実行するだけで、プランニングは処理していません。これ動作は、上記（ｂ）の「要素機能を提供することによってユーザからの要求に応じたサービスを提供するために資源割当という問題のみを処理する」に相当します。」の記載がなされているが、上記（ｓ４）の各要素機能エージェントの回答は、現状の資源の稼働状況に関するものであり、審判請求人が挙げた具体例では、「資源の稼働状態若しくは負荷状況の均衡を保つように要素機能に対してサービスを達成するためのタスクを配分する問題である資源割当」の問題をどの様に処理するかの説明にはなっていない。
　したがって、拒絶理由通知書の（２）（ａ）で指摘した記載不備は依然として解消していない。
　
　.（２）（ｂ）で指摘した記載不備について　
　審判請求人は、意見書において、「最後に、上記（２ｂ）に記載したご指摘に関してですが、フィールドマネージャに関する構成は、第００５６段落及び図２に示しています。フィールドマネージャにおけるご指摘された動作は、上記例の(s7)に該当します。本発明では、プランニングと資源割当という問題を分離していることで、それぞれを定義するときのテンプレート（定義の雛形）やインタプリタ（定義を解釈して実行するための処理プログラム）を単純化できるという有利な効果を奏します。その一方では、プランニングと資源割当という問題を分離したために、資源割当を参照していないプランが生成されることになるので、その生成されたプランが必ずしも最適であるという保証はありません。上記例に従えば、２日後に条件を満たす会議室が存在しても６日後に開催するというプランを作成してしまう可能性があります。そこで、本発明におけるフィールドマネージャは、複数のプランニングエージェントから送られてきたプランを収集して、そのプランの仕事の負荷等を総合評価し、その中から最適と考えられるプランを決定できるようにしました。上記例に従えば、会議設定エージェントＡが６日後、会議設定エージェントＢが２日後というプランをそれぞれ生成したとすると、会議設定フィールド（フィールドマネージャ）は、最適と考えられる２日後に会議を開催することを決定できます。本発明のフィールドマネージャは、以上のように作用するように構成しています。」と主張すると共に、請求項３の記載を「【請求項３】ユーザから要求されたサービスを達成するための機能の組み合わせと機能間で授受されるデータとそれらを実行する順序であるプランを求める問題であるプランニングと、ユーザから要求されたサービスを達成する要素機能あるいは要素機能と結びつけられた資源の稼働状態若しくは負荷状況の均衡を保つように要素機能に対してサービスを達成するためのタスクを配分する問題である資源割当とを、複数のエージェントによる協調動作により処理することで、ユーザからの要求に応じたサービスを提供するマルチエージェント協調システムにおいて、
　要素機能を提供することによってユーザからの要求に応じたサービスを提供するために資源割当という問題のみを処理する１乃至複数の要素機能エージェントと、
　保持したプランに関する定義に従いユーザからの要求に応じたサービスの実行に必要な仕事を、予め設定された評価基準に基づき前記要素機能エージェントに割り振ることによって、ユーザからの要求に応じたサービスを提供するためにプランニングという問題のみを処理する複数のプランニングエージェントと、
　１乃至複数の前記要素機能エージェントと前記プランニングエージェントを介して接続され、前記プランニングエージェントと前記要素機能エージェントとの２種のエージェントのメンバの集合及びエージェント間の協調の手順に関する定義を有し、エージェント間の協調動作を管理するフィールドマネージャと、
　を有し、
　前記フィールドマネージャは、ユーザからの要求に応じたサービスを実行するためのプランの生成を、予め設定された評価基準に基づきメンバである複数の前記プランニングエージェントへ指示すると共に、その指示に応じて複数の前記プランニングエージェントから返されてきた各プランにおける仕事の負荷を総合評価することによって複数のプランの中から一のプランを決定し、その決定したプランを返した前記プランニングエージェントに対してユーザからの要求に応じたサービスを提供するための仕事を依頼することを特徴とするマルチエージェント協調システム。」と補正した。
　しかしながら、審判請求人が本願発明をより分かり易くするために挙げた具体例（プロジェクト会議の開催）を参照しても、複数のエージェントに対して、どの様にうにして協調動作を行なわせるのかその具体的手段が明りょうでないので、請求項３に記載されている「ユーザから要求されたサービスを達成する要素機能あるいは要素機能と結びつけられた資源の稼働状態若しくは負荷状況の均衡を保つように要素機能に対してサービスを達成するためのタスクを配分する問題である資源割当とを、複数のエージェントによる協調動作により処理する」ことをどの様にして実現するのか、その具体的手段が発明の詳細な説明に記載されているとは認められず、拒絶理由通知書の（２）（ｂ）で指摘した記載不備は依然として解消していない。
　
４．以上のとおりであるので、本件出願の発明の詳細な説明及び図面には、その発明の属する技術の分野における通常の知識を有する者がその実施をすることができる程度に、その発明の構成及びその動作が明確かつ十分に記載されているとは認められず、また、特許を受けようとする発明が発明の詳細な説明に記載されているとは認められないから、本願は、特許法第３６条第４項及び第５項に規定する要件を満たしていないので、拒絶をすべきものである。
　よって、結論の通り審決する。