• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 特36 条4項詳細な説明の記載不備 特許、登録しない(前置又は当審拒絶理由) G06F
審判 査定不服 5項1、2号及び6項 請求の範囲の記載不備 特許、登録しない(前置又は当審拒絶理由) G06F
管理番号 1082196
審判番号 審判1999-1317  
総通号数 46 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 1995-01-10 
種別 拒絶査定不服の審決 
審判請求日 1999-01-21 
確定日 2003-08-15 
事件の表示 平成 6年特許願第 34454号「マルチエージェント協調システム及びその方法」拒絶査定に対する審判事件[平成 7年 1月10日出願公開、特開平 7- 6142]について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由 1.本願は、特許法第41条に基づく優先権主張を伴う平成6年3月4日(優先日:平成5年4月20日、出願番号:特願平5-92684号)の出願であって、平成14年12月4日付けの手続補正書によって補正された明細書の特許請求の範囲に記載されたとおりの「マルチエージェント協調システム及びその方法」に関するものである。

2.当審が平成14年10月7日付けで通知した拒絶理由は、
「本件出願は、明細書及び図面の記載が下記の点で不明りょうであるので、特許法36条4項又は5項及び6項に規定する要件を満たしていない。

(1)明細書及び図面の記載では、従来の欠点をどのようにして解決するのかその具体的手段が明確でなく、本願発明は当業者が容易に実施できる程度に明細書及び図面が記載されているとは認められない。
(a)段落【0043】に、「【作用】この発明におけるマルチエージェント協調方法では、プランニングと資源割当とを分離して定義する手段と両問題を明確に分割された二つの処理段階で解く手段とにより、・・・システム全体の仕様が単純になる。」と記載されているが、「プラニング」と「資源割当て」を明確に分離するための具体的手段が、明細書及び図面を参照してもどのようなものか理解することができない。
(b)段落【0044】に、「また、協調動作を行うエージェントのメンバの集合とエージェント間の協調の手順に関する仕様を、要素機能の定義、プランの定義とは分離して定義する手段と、その定義にしたがってエージェントが協調動作を行なう手段により、協調の定義と処理が単純化され、協調に関して各エージェントの仕様やシステム全体の仕様が単純になる。」と記載されているが、「その定義にしたがってエージェントが協調動作を行なう手段」がどのようなものでどのようにして協調動作をおこなうのか、明細書及び図面を参照して理解できない。
(c)(省略)
(d)図2に示されるフィールドマネージャの具体的構成及びその動作が不明りょうである。特に、協調定義データベース6がどのようなものでどのようにしてそのデータを生成するのか明細書を参照しても明確でない。
(e)図3に示されるプラニングエージェントの具体的構成及びその動作が不明りょうである。特に、ルールベース9及び評価用データ格納部11がどのようなもので、どのようにしてこれらを生成するのか明細書を参照しても明確でない。
また、プラニング実行部10がどのようにしてプラニングを実行していくのか明細書を参照しても良く理解できない。
(f)(省略)
(2)特許請求の範囲の記載と発明の詳細な説明の記載との対応関係が明確でない。
(a)請求項1に「ユーザから要求されたサービスを達成する要素機能あるいは要素機能と結びつけられた資源の稼働状態若しくは負荷状況の均衡を保つように要素機能に対してサービスを達成するためのタスクを配分する問題である資源割当とを切り離し、ユーザからの要求に対して解くべき前記各問題を分割して処理する」と記載されているがこの記載は発明の詳細な説明及び図面のいずれの箇所の記載に基づくものか明りょうでない。
(b)請求項3に「保持したプランに関する定義に従いユーザからの要求に応じたサービスを実行するためのプランを生成し、その生成したプランに基づきサービスを実行するために必要な仕事を前記要素機能エージェントに割り振る能力を有する1ないし複数のプランニングエージェントと、」と記載されているが発明の詳細な説明及び図面を参照してもどのようにしてこの構成を実現するのか明確でない。また、「前記フィールドマネージャは、前記プランニングエージェントからのプラン及び前記要素機能エージェントからのプランに基づく仕事の負荷の評価に基づき総合評価を行うことで協調動作をさせる」と記載されているが発明の詳細な説明及び図面を参照してもどのようにしてこの構成を実現するのか明確でない。(以下、省略)」というものである。

3.これに対して、審判請求人は、平成14年12月4日付けで意見書及手続補正書を提出し、これによって記載不備は解消した旨の主張をしている。そこで、意見書の主張及び手続補正書の補正内容を参酌して拒絶理由で通知した記載不備が解消されたか否かを検討する。
.(1)(a)で指摘した記載不備について
審判請求人は、意見書において、「まず、上記(1a)に記載したご指摘に関してですが、「プランニング」と「資源割当」とは、予め分割して定義されていることは前述したとおりです。従いまして、「プランニング」と「資源割当」を明確に分離するための具体的手段は存在しないことが明確になるように第0044段落を補正致しました。」と主張している。しかしながら、意見書の主張及び明細書の記載によっても、「プラニングエージェント」と「要素機能エージェント」とがどのようにして「プラニング」問題と「資源割当」問題を全く独立して処理していくのか明りょうでない。この点に関して、審判請求人が本願発明をより分かり易くするために意見書で挙げた具体例(プロジェクト会議の開催)の、「(s6)各会議設定エージェントは、各要素機能エージェントからの回答に基づき結果が得られればプランを生成して会議設定フィールドへ返す。」の記載では、「各会議設定エージェント」(本願発明の「プラニングエージェント」に相当)は、会議のプランだけでなく、会議室の割当て(本願発明の「資源割当」に相当)のプランも立てているものと認められるので、本願発明が、「プランニング」の問題処理と「資源割当」の問題処理を別々のエージェントで行なえる構成となっていることの説明とはなっていない。また、「(s7)会議設定フィールドは、会議設定エージェントA,Bから返されてきたプランを受け取る。返されてくるプランは複数なので、会議設定フィールドは、自分の持つ評価基準あるいはユーザに問い合わせることにより評価結果を得て、評価の高いプランを決定します。」の記載では、会議設定フィールド(本願発明の「フィールドマネージャ」に相当)が最終的な決定を行っているので、資源割当ての問題処理は、会議設定フィールド(本願発明の「フィールドマネージャ」に相当)と会議設定エージェント(本願発明のプラニングエージェント」に相当)が行っていることになり、各機能要素エージェント(本願発明の「要素機能エージェント」に相当)が資源割当ての問題処理を行っているとは認められない。
したがって、拒絶理由通知書の(1)(a)で指摘した記載不備は依然として解消していない。

.(1)(b)で指摘した記載不備について
審判請求人は、意見書において、「次に、上記(1b)に記載したご指摘に関してですが、本発明においては、協調動作を行うエージェントのメンバの集合とエージェント間の協調の手順に関する仕様の定義にしたがってプランニングエージェントと要素機能エージェントとに協調動作を行わせるのはフィールドマネージャです。(第0056段落、第0063段落第3行乃至第6行)。仕様の定義には、エージェント間の協調の手順が記述されているので、フィールドマネージャは、ユーザからの要求に応じたサービスを提供する際に、この定義内容に従い協調動作を行わせるプランニングエージェントと要素機能エージェントとを特定し、協調動作を行わせます。今回は、この点が明確になるように第0044段落を補正致しました。」と主張すると共に、明細書の0044段落を「【0044】また、協調動作を行うエージェントのメンバの集合とエージェント間の協調の手順に関する仕様を、要素機能の定義、プランの定義とは分離して定義されており、フィールドマネージャは、ユーザからの要求に応じたサービスを提供する際に、その定義にしたがってエージェントに協調動作を行なわせるようにしたので、協調の定義と処理が単純化され、協調に関して各エージェントの仕様やシステム全体の仕様が単純になる。」と補正した。
しかしながら、上記意見書の主張及び明細書の補正では、どのようにして協調の手順に関する仕様を決めるのか不明りょうであって、結局フィールドマネージャーはどの様な条件の下で、どの様にして、プラニングエージェントと要素機能エージェントに協調動作を行わせるのかが明りょうでない。したがって、拒絶理由通知書の(1)(b)で指摘した記載不備は依然として解消していない。

.(1)(d)で指摘した記載不備について
審判請求人は、意見書において、「次に、上記(1d)に記載したご指摘に関してですが、フィールドマネージャに関する具体的構成は、第0056段落及び図2に示しています。本発明では、協調するエージェントのメンバの集合とエージェント間の協調の手順に関する仕様の定義(以下、単に「仕様の定義」)、要素機能の定義及びプランの定義をそれぞれ分離して定義することを特徴の一つとしておりますが(第0060段落)、協調定義データベース6は、このうちの仕様の定義を格納するものです(第0056段落)。また、協調定義データベース6に格納される仕様の定義は、予め生成されていることは前述したとおりです。また、フィールドマネージャにおける動作は、上記具体例により明確になっていると確信しています。本願明細書においては、図5に示したとおりであり、ユーザからのサービス要求をユーザインタフェースを介して受け取り(ステップ21)、プランニングエージェント3に対して協調に関する指示を付加してサービス要求を渡し(ステップ22)、プランニングエージェント3および要素機能エージェント4が返してきた上記評価結果を総合評価し(ステップ27)、フィールドマネージャ2が上記総合評価の結果から実際にサービスを達成するための仕事を依頼するプランニングエージェント3を決定し通知します(ステップ28)。」と主張している。
しかしながら、審判請求人が本願発明をより分かり易くするために挙げた具体例(プロジェクト会議の開催)を参照しても、フィールドマネージャ2内の協調定義データベースがどのようなもので、どの様にしてそのデータベースを生成するのか不明りょうであって、拒絶理由通知書の(1)(d)で指摘した記載不備は依然として解消していない。

.(1)(e)で指摘した記載不備について
審判請求人は、意見書において、「次に、上記(1e)に記載したご指摘に関してですが、プランニングエージェントに関する具体的構成は、第0057段落及び図3に示しています。本発明では、仕様の定義、要素機能の定義及びプランの定義をそれぞれ分離して定義することを特徴の一つとしておりますが(第0060段落)、ルールベース9は、このうちのプランの定義(プランを生成するための規則)を格納するものです(第0057段落)。プランの定義が予め生成されていることについては、前述したとおりです。プランの定義の具体的内容は、依頼される仕事の処理手順(上記例のプラン(1)〜(5)によって異なってくるものであり、いずれにせよ、予め生成しておくことになります。また、評価用データ格納部11は、フィールドマネージャ2からのメッセージに含まれた依頼を評価するための評価基準を格納するものです。評価基準については、第0064段落に記載しており、上記具体例においては(s3)で評価基準を使用しています。評価基準は予め設定されていることも上記(4)から明らかです。更に、プランニング実行部10においてどのようにしてプランニングを実行していくかは、上記具体例により明確になっていると確信しています。本願明細書においては、図5に示したとおりであり、サービス要求とフィールドマネージャからの指示に従いプランニングを行い(ステップ23)、評価結果が規定の基準に達しさらにプランが得られたかを判定し(ステップ24)、要素機能エージェント4に対して負荷に関する評価を依頼し(ステップ25)、フィールドマネージャ2が総合評価(ステップ27)を行うために要素機能エージェントによる評価をフィールドマネージャ2へ返し、依頼を受けたときに生成したプランに従って要素機能エージェント4と処理を実行します(ステップ29)。」と主張している。
しかしながら、段落0057,段落0060の記載及び審判請求人が本願発明の説明を分かり易く説明するために挙げた具体例(プロジェクト会議の開催)を参照しても、プランニングエージェント内のルールベース9及び評価用データ格納部11がどのようなもので、どのようにしてこれらを生成するのか不明りょうであって、拒絶理由通知書の(1)(e)で指摘した記載不備は依然として解消していない。

.(2)(a)で指摘した記載不備について
審判請求人は、意見書において、「次に、上記(2a)に記載したご指摘に関してですが、請求項1の引用された記載箇所は、第0059,0060段落、図5並びに図5を説明した第0061段落乃至第0063段落に基づきます。」と主張している。
しかしながら、明細書の段落0059には、「ここで、プランニングとは、ユーザから要求されたサービスを達成するための機能の組み合わせと機能間で授受されるデータとそれらを実行する順序であるプランを求める問題をいう。また、資源割当とは、プランを達成する要素機能あるいは要素機能と結びつけられた資源の稼働状態若しくは負荷状況の均衡を保つように要素機能に対してサービスを達成するためのタスクを配分する問題をいう。」と記載され、また、段落0060には、「本実施例において特徴的なことは、上記プランニングと上記資源割当とを切り離して、前記各問題毎に分割された二段階からなる処理で前記問題を解くことである。更に、協調する上記エージェントのメンバの集合と前記エージェント間の協調の手順に関する仕様の定義、要素機能の定義及びプランの定義をそれぞれ分離して定義し、その定義にしたがって前記エージェントが協調動作を行うことである。これにより、アプリケーションの記述、各定義の変更等が容易に行うことができる。」と記載され、また、段落0061には、「次に、本実施例におけるエージェントの協調動作を図に基づいて説明する。図5は、本実施例におけるエージェントの協調動作を表すフローチャートである。エージェントの協調動作は、フィールドマネージャ2がユーザからのサービス要求をユーザインタフェース1を介して受け取るステップ21と、フィールドマネージャ2がプランニングエージェント3に対して協調に関する指示を付加して上記サービス要求を渡すステップ22と、プランニングエージェント3が上記サービス要求と上記指示に従い評価およびプランニングを行なうステップ23と、プランニングエージェント3が評価結果が規定の基準に達しさらにプランが得られたかを判定するステップ24と、プランニングエージェント3が要素機能エージェント4に対して負荷に関する評価を依頼するステップ25と、要素機能エージェント4が負荷を評価してその評価結果を返すステップ26と、フィールドマネージャ2がプランニングエージェント3および要素機能エージェント4が返してきた上記評価結果を総合評価するステップ27と、フィールドマネージャ2が上記総合評価の結果から実際にサービスを達成するための仕事を依頼するプランニングエージェント3を決定し通知するステップ28と、上記依頼を受けたプランニングエージェント3が上記プランに従って要素機能エージェント4と処理を実行するステップ29と、からなる。」と記載され、また、段落0062には、「以下、図5を用いて協調動作の詳細について説明する。」と記載され、また、段落0063には、「ステップ21において、フィールドマネージャ2は、ユーザがユーザインターフェース1から入力したサービス要求を通信部5を介して受け取る。ステップ22において、フィールドマネージャ2は、協調定義データベース6の記述に従って協調動作実行部7が生成した指示を上記ユーザからのサービス要求に付加した情報を通信部5を介してメンバである複数の適当なプランニングエージェント3に対して送る。次にステップ23において、プランニングエージェント3は、通信部8を介して受けとった上記情報の指示に従い、評価用データ格納部11の内容に従って評価部12において上記ユーザから要求されたサービスの仕様を評価し、ルールベース9の内容に従ってプランニング実行部10において要求されたサービスを実行するためのプランを生成する。次にステップ24において、プランニングエージェント3は、上記評価の結果が規定の基準に達したかどうか、プランが得られたかどうかを判定する。その結果、評価基準を満たさないか、あるいはプランが得られなければそのプランニングエージェント3は動作を終了する。そうでない場合はステップ25においてプランニングエージェント3は生成したプランに従って必要な要素機能エージェント4に通信部8を介して負荷やその要素機能エージェント4に付随する装置の位置などに関する評価を依頼する。この時依頼とともに評価のために必要な情報を送る。次にステップ26において、要素機能エージェント4は、上記依頼を通信部13を介して受け取り、評価用データおよびプロファイル格納部16の内容に従って受け取った情報を評価しその結果を通信部13を介してプランニングエージェント3に返す。次にステップ28において、フィールドマネージャ2は、上記総合評価の結果に基づいて実際にサービスを達成するための仕事を依頼するプランニングエージェント3を決定し、処理依頼を行なう。次にステップ29において、依頼を受けたプランニングエージェント3は、上記プランに従い適当な要素機能エージェント4と共に上記仕事を処理していく。」と記載されているだけであって、これらの記載では、請求項1に記載されている「ユーザから要求されたサービスを達成する要素機能あるいは要素機能と結びつけられた資源の稼働状態若しくは負荷状況の均衡を保つように要素機能に対してサービスを達成するためのタスクを配分する問題である資源割当」をどの様にして実現するのか、その具体的手段が発明の詳細な説明に記載されているとは認められない。なお、この点に関して、審判請求人が本願発明をより分かり易くするために意見書で挙げた具体例(プロジェクト会議の開催)に、「(S3)2つの会議設定エージェントA,Bは、それぞれ持つプランに関する定義に従って、予め設定された評価基準(第0064段落)に基づき各要素機能エージェント(2つの個人スケジュール管理エージェント、2つの会議室予約エージェント)に要求を投げる(図5のステップ25)。この処理を詳細に説明すると、以下のようになります。
例えば、会議設定エージェントAであれば、プラン(1)に従い個人スケジュール管理エージェントA,B,Cそれぞれに要求を投げます。続いて、プラン(2)に従い会議室予約エージェントA,B,Cそれぞれに要求を投げます。
このようにして、会議設定エージェント(プランニングエージェント)は、プランニングという問題を処理します。なお、資源割当は処理していません。この動作は、上記(c)の「保持したプランに関する定義に従いユーザからの要求に応じたサービスの実行に必要な仕事を、・・・前記要素機能エージェントに割り振ることによって、ユーザからの要求に応じたサービスを提供するためにプランニングという問題のみを処理する」に相当します。」の記載がなされ、また、「(s4)各要素機能エージェントは、前述したそれぞれの要素機能を提供することによって、資源割当という問題を処理します。具体的には、個人スケジュール管理エージェントAであれば、要素機能(1)の「参加者甲のスケジュールを答える」を処理し、会議室予約エージェントAであれば、要素機能(1)の「X棟の会議室の予約状況や会議室の特徴を答える。」を処理します。何を実行する、つまり、要素機能(1)を処理すると言うことは、プランニングエージェントと各要素機能エージェントとの間で授受される要求の内容に従い特定できます。なお、要求等の情報交換自体は、マルチエージェント協調システムにおける周知技術により実現されるものです。ここでは、資源割当という処理を実行するだけで、プランニングは処理していません。これ動作は、上記(b)の「要素機能を提供することによってユーザからの要求に応じたサービスを提供するために資源割当という問題のみを処理する」に相当します。」の記載がなされているが、上記(s4)の各要素機能エージェントの回答は、現状の資源の稼働状況に関するものであり、審判請求人が挙げた具体例では、「資源の稼働状態若しくは負荷状況の均衡を保つように要素機能に対してサービスを達成するためのタスクを配分する問題である資源割当」の問題をどの様に処理するかの説明にはなっていない。
したがって、拒絶理由通知書の(2)(a)で指摘した記載不備は依然として解消していない。

.(2)(b)で指摘した記載不備について
審判請求人は、意見書において、「最後に、上記(2b)に記載したご指摘に関してですが、フィールドマネージャに関する構成は、第0056段落及び図2に示しています。フィールドマネージャにおけるご指摘された動作は、上記例の(s7)に該当します。本発明では、プランニングと資源割当という問題を分離していることで、それぞれを定義するときのテンプレート(定義の雛形)やインタプリタ(定義を解釈して実行するための処理プログラム)を単純化できるという有利な効果を奏します。その一方では、プランニングと資源割当という問題を分離したために、資源割当を参照していないプランが生成されることになるので、その生成されたプランが必ずしも最適であるという保証はありません。上記例に従えば、2日後に条件を満たす会議室が存在しても6日後に開催するというプランを作成してしまう可能性があります。そこで、本発明におけるフィールドマネージャは、複数のプランニングエージェントから送られてきたプランを収集して、そのプランの仕事の負荷等を総合評価し、その中から最適と考えられるプランを決定できるようにしました。上記例に従えば、会議設定エージェントAが6日後、会議設定エージェントBが2日後というプランをそれぞれ生成したとすると、会議設定フィールド(フィールドマネージャ)は、最適と考えられる2日後に会議を開催することを決定できます。本発明のフィールドマネージャは、以上のように作用するように構成しています。」と主張すると共に、請求項3の記載を「【請求項3】ユーザから要求されたサービスを達成するための機能の組み合わせと機能間で授受されるデータとそれらを実行する順序であるプランを求める問題であるプランニングと、ユーザから要求されたサービスを達成する要素機能あるいは要素機能と結びつけられた資源の稼働状態若しくは負荷状況の均衡を保つように要素機能に対してサービスを達成するためのタスクを配分する問題である資源割当とを、複数のエージェントによる協調動作により処理することで、ユーザからの要求に応じたサービスを提供するマルチエージェント協調システムにおいて、
要素機能を提供することによってユーザからの要求に応じたサービスを提供するために資源割当という問題のみを処理する1乃至複数の要素機能エージェントと、
保持したプランに関する定義に従いユーザからの要求に応じたサービスの実行に必要な仕事を、予め設定された評価基準に基づき前記要素機能エージェントに割り振ることによって、ユーザからの要求に応じたサービスを提供するためにプランニングという問題のみを処理する複数のプランニングエージェントと、
1乃至複数の前記要素機能エージェントと前記プランニングエージェントを介して接続され、前記プランニングエージェントと前記要素機能エージェントとの2種のエージェントのメンバの集合及びエージェント間の協調の手順に関する定義を有し、エージェント間の協調動作を管理するフィールドマネージャと、
を有し、
前記フィールドマネージャは、ユーザからの要求に応じたサービスを実行するためのプランの生成を、予め設定された評価基準に基づきメンバである複数の前記プランニングエージェントへ指示すると共に、その指示に応じて複数の前記プランニングエージェントから返されてきた各プランにおける仕事の負荷を総合評価することによって複数のプランの中から一のプランを決定し、その決定したプランを返した前記プランニングエージェントに対してユーザからの要求に応じたサービスを提供するための仕事を依頼することを特徴とするマルチエージェント協調システム。」と補正した。
しかしながら、審判請求人が本願発明をより分かり易くするために挙げた具体例(プロジェクト会議の開催)を参照しても、複数のエージェントに対して、どの様にうにして協調動作を行なわせるのかその具体的手段が明りょうでないので、請求項3に記載されている「ユーザから要求されたサービスを達成する要素機能あるいは要素機能と結びつけられた資源の稼働状態若しくは負荷状況の均衡を保つように要素機能に対してサービスを達成するためのタスクを配分する問題である資源割当とを、複数のエージェントによる協調動作により処理する」ことをどの様にして実現するのか、その具体的手段が発明の詳細な説明に記載されているとは認められず、拒絶理由通知書の(2)(b)で指摘した記載不備は依然として解消していない。

4.以上のとおりであるので、本件出願の発明の詳細な説明及び図面には、その発明の属する技術の分野における通常の知識を有する者がその実施をすることができる程度に、その発明の構成及びその動作が明確かつ十分に記載されているとは認められず、また、特許を受けようとする発明が発明の詳細な説明に記載されているとは認められないから、本願は、特許法第36条第4項及び第5項に規定する要件を満たしていないので、拒絶をすべきものである。
よって、結論の通り審決する。
 
審理終結日 2003-06-06 
結審通知日 2003-06-17 
審決日 2003-06-30 
出願番号 特願平6-34454
審決分類 P 1 8・ 531- WZ (G06F)
P 1 8・ 534- WZ (G06F)
最終処分 不成立  
前審関与審査官 石井 茂和  
特許庁審判長 徳永 民雄
特許庁審判官 村上 友幸
斎藤 操
発明の名称 マルチエージェント協調システム及びその方法  
代理人 石田 純  
代理人 吉田 研二  

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