【事件の表示】
　特願２０００−１０３５７１「コンポーネントの動的置換装置及びコンピュータ読み取り可能な記憶媒体」拒絶査定不服審判事件〔平成１３年１０月１９日出願公開、特開２００１−２９０６３７〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯・請求項１に係る発明
　本願は、平成１２年４月５日の出願であって、平成１５年１０月２０日付けで拒絶査定がなされ、これに対し、同年１１月２０日に審判請求及び手続補正がなされたが、平成１８年６月１６日付けで当審より前記手続補正の却下の決定がなされると共に拒絶理由が通知され、これに対し、同年８月２１日に手続補正がなされたものであり、その請求項１に係る発明は、特許請求の範囲の請求項１に記載された事項により特定される次のとおりのものと認める。
　
　「それぞれコンポーネントが割り当てられる複数のスレッドを有するアプリケーションプロセスにおける上記コンポーネントを新コンポーネントに動的置換する
マルチプロセス・マルチスレッド構成されたシステムにおけるコンポーネントの動的置換装置であって、
　アプリケーションプロセス内のスレッド数を格納するスレッド数格納領域と、
　置換要求受付カウンタと、
　動的置換要求に基づいて、動作中のスレッドの動作終了を待って処理終了後に、置換要求受付カウンタを１増加させてこのスレッドを待機させ、動作中でないスレッドはそのまま待機させて、置換要求受付カウンタを１増加させ、スレッド数格納領域と置換要求受付カウンタとの値の比較を行う制御手段と、
　スレッド数格納領域と置換要求受付カウンタとの値が一致したとき、上記全てのスレッドが待機状態となったとして、上記コンポーネントをアンロードし、新コンポーネントのロードを行い、新コンポーネントへの置換処理を行う置換処理手段とを設けたことを特徴とするコンポーネントの動的置換装置。」
　
２．当審の拒絶理由
　当審の拒絶理由の趣旨は、本件出願は、明細書及び図面の記載が下記の点で不備のため、特許法第３６条第４項並びに第６項第１号及び第２号に規定する要件を満たしていない、というものであり、具体的には、次のとおりの指摘事項がなされている。
　
「明細書及び図面の記載は全体として不明確である。特に、
（１）図２及び図５に記載のフローチャートにおける各処理は、図１に記載のどの機構（手段又はソフトウェア）が実行しているのか、発明の詳細な説明の記載を参酌しても不明確である。（意見書において、前記フローチャート中の各処理を、図１に記載のどの機構が実行しているのかについて説明すると共に、その根拠が、出願当初の明細書のどこに記載されているかを具体的に示されたい。）
　よって、請求項１乃至３に係る発明の「制御手段」、「置換処理手段」及び「業務実行制御手段」は、例えば図１に記載のどの機構（手段又はソフトウェア）に対応したものであるのか不明である。また、請求項４乃至６に係る発明の各処理は、実際にはどの機構（手段又はソフトウェア）に対応しているのか不明である。
　逆に言えば、発明の詳細な説明及び図面は、請求項１乃至６に係る発明を実現するための手段について、明確かつ十分に記載していない。
（２）請求項１に記載の「それぞれコンポーネントがロードされる複数のスレッド」において、「複数のスレッド」にロードされる各「コンポーネント」は、同じものであるのか異なるものであるのか不明である。また、「各スレッド全て」は、特定のアプリケーションプロセス内のスレッドのみを指しているのか、全てのアプリケーションプロセス内の全てのスレッドを指しているのか不明である。
　したがって、請求項１乃至３に係る発明は、ａ）全てのアプリケーションプロセス内の全スレッド内に同じコンポーネントがロードされていることが前提となっているのか、又は、ｂ）スレッド毎に異なるコンポーネントがロードされる態様を許容するのか、そして、動的置換要求は、ｃ）全てのアプリケーションプロセス内の全てのスレッドに対して行われるのか、または、ｄ）特定のアプリケーションプロセス内の全てのスレッドに対してのみ行われるのか不明である。
　明細書の段落【００３１】の記載「全アプリケーションプロセス１３０において新コンポーネント１６０のロードを行う（ステップＡ１３）。」の記載からすると、上記ａ）とｃ）の態様が正しいと考えられるが、そうすると、システム内の全てのスレッドが同じコンポーネントを実行することとなるが、そのようなシステムとしてどのような業務システムを想定しているのか不明である。
　また、通常、同じプロセス内の複数のスレッドは同じアドレス空間に存在し、メモリ空間を共有することを考慮すれば、本願では、同じプロセス（アドレス空間）内に同じコンポーネントが複数個ロードされることとなり、このような態様にどのような技術上の意義があるのか不明である。（実際、原査定で引用された特開平７−１５２５５１号公報では、複数のスレッドは、一つの関数を共有しており、関数は、メモリ空間に１つしか存在していないので、スレッド毎に関数をロードする必要はない。）
　なお、仮に、上記ｂ）のごとく、スレッド毎に異なるコンポーネントがロードされ得る場合、置換すべきコンポーネントがどのスレッドに存在するかを識別し、スレッド毎に置換処理を行わなければならないが、この制御をどのように実現するのか不明である。
　また、請求項４乃至６に係る発明も、発明の前提となるシステムが不明確であるので同様に不明である。
（３）…（以下略）」
　
３．検討
　前記拒絶理由において、指摘事項（１）及び（２）が解消したか否かについて検討する。
（１）指摘事項（１）について
　請求項１の記載によると、「制御手段」は、置換要求受付カウンタに関する制御と、スレッドの待機制御の２つの機能を有しており、「置換処理手段」は、コンポーネントのアンロード／ロードによる置換処理を行う機能を有している。
　上記各機能が、発明の詳細な説明のどこに記載されているかについて検討する。
　まず、置換要求受付カウンタに関する制御については、明細書の段落【００２７】の記載「この動的置換要求を受けて動作するスレッド１３１では、コンポーネント管理機構１３２で置換要求受付カウンタ１４１を増やす（ステップＡ５）。この時、置換要求受付カウンタ１４１とスレッド格納域１４２のスレッド１３１数とを比較する（ステップＡ６）。」からすると、「コンポーネント管理機構」が行っている。
　スレッドの待機制御については、明細書の段落【００２８】の記載「両者が同じでなければ、まだ業務実行中のスレッド１３１があって動的置換要求が受け取れないということなので、そのスレッド１３１は新コンポーネント１６０のロード完了イベント待ち合わせに入る（ステップＡ７）。同様に、処理を行っていないスレッド１３１は、ステップＡ２で発行されたことによりメッセージキュー制御機構１２０に溜まった動的置換要求を一つずつ受け取り、ステップＡ７で待ち合わせる。」及び段落【００３６】の記載「スレッド１・１３１−３１とスレッド２・１３１−３２はそれぞれ待ち合わせ機構１３３−３１１、待ち合わせ機構１３３−３２１によってステップＡ７の待ち合わせに入る」からすると、スレッドは、他の制御に依らず、自らが有している待ち合わせ機構により自らの判断で待機を行っている。
　つまり、発明の詳細な説明の記載によると、置換要求受付カウンタに関する制御とスレッドの待機制御は、異なる機構、すなわち異なる２つの手段により実現されており、一の「制御手段」により実現されている請求項１の記載と対応していない。
　また、置換処理を行う機能については、明細書の段落【００１３】の記載「アプリケーションプロセス１３０内で最後に要求を受け付けたコンポーネント管理機構１３２がコンポーネント１３４のアンロードを行い置換処理を行う。」からすると、「コンポーネント管理機構」のうち、最後に要求を受け付けたものが置換処理を実行することとなっている。つまり、発明の詳細な説明の記載によると、どの「コンポーネント管理機構」が置換処理を行うかが予め定められてはいない。
　一方、請求項１の記載「制御手段と、…置換処理手段とを設けた」からすると、「制御手段」や「スレッド」とは別に「置換処理手段」が設けられていると解釈することが合理的であり、前記「制御手段」の一部（コンポーネント管理機構）のうち、最後に要求を受け付けたものが「置換処理手段」になるという発明の詳細な説明に記載された態様と対応していない。
　このように、特に「制御手段」及び「置換処理手段」に関する構成に関し、請求項１の記載は、発明の詳細な説明に記載された態様と対応していないから、請求項１の記載は、発明の詳細な説明に記載したものではなく、また、発明の詳細な説明は、請求項１に係る発明を、当業者が実施できる程度に明確かつ十分に記載されていない。
　
　なお、請求人は、平成１８年８月２１日付けの意見書において、指摘事項（１）に関し、次のように主張している。
「（ア）　指摘事項（１）について
　「制御手段」は、コンポーネント管理機構１３２に該当します。段落００２７には、「この動的置換要求を受けて動作するスレッド１３１では、コンポーネント管理機構１３２で置換要求受付カウンタ１４１を１増やす（ステップＡ５）。この時、置換要求受付カウンタ１４１とスレッド数格納域１４２のスレッド１３１数とを比較する（ステップＡ６）。」旨が記載されています。
　また、「置換処理手段」は、スレッド１３１に該当します。アプリケーションプロセスにおいて、スレッドがその動作の主体となります。よって、コンポーネントのアンロード、ロードも、アプリケーションプロセス内のいずれかのスレッドが行います。もっとも、本願発明では、スレッドは順次待ち合わせ状態に入り、ロード完了イベントが無ければ解除されません（段落００２８）。よって、コンポーネントのアンロード、ロードは、アプリケーションプロセス内の複数のスレッドのうち、待ち合わせ状態に入っていない最後に残ったスレッドが行います。
　なお、出願人は、本日付けで提出した手続補正書において、特許請求の範囲の請求項２乃至６を削除いたしました。」
　
　当該主張によると、請求項１に記載の「制御手段」は、「コンポーネント管理機構」に、そして、「置換処理手段」は、「待ち合わせ状態に入っていない最後に残ったスレッド」に相当するものである。
　しかしながら、「スレッド」自体が、「置換処理」を行うことは、発明の詳細な説明には記載されていない。また、請求項１には、「スレッド」と「置換処理手段」との関係については何ら言及しておらず、その記載からすると、「スレッド」と「置換処理手段」とは別のものであると解釈することが合理的であるので、「置換処理手段」が「スレッド」であると解釈することはできない。
　よって、請求人の当該主張は、明細書の記載に基づかないものであるので採用することができない。
　以上のとおり、請求項１の記載は、依然として不明確であり、発明の詳細な説明に記載したものではなく、かつ、発明の詳細な説明は、請求項１に係る発明を当業者が実施できる程度に明確且つ十分に記載されてない。
　したがって、指摘事項（１）に係る拒絶理由は依然として解消していない。
　
（２）指摘事項（２）について
　請求項１には、「マルチプロセス・マルチスレッド構成されたシステムにおけるコンポーネントの動的置換装置」と記載されていることから、請求項１に係る「コンポーネント」は、「マルチプロセス・マルチスレッド」、すなわち、複数のプロセス及び複数のスレッドにおいて使用されるものであることを前提としている。
　しかしながら、請求項１には、「それぞれコンポーネントが割り当てられる複数のスレッドを有するアプリケーションプロセス」としか記載がなく、一の「コンポーネント」が、全てのアプリケーションプロセスの全てのスレッドの全てに使用されるのか、特定のアプリケーションプロセスの全てのスレッドに使用されるのか、又は、一のスレッドのみで使用されるのか特定されていないから、コンポーネントを置換する対象が、全てのアプリケーションプロセスの全てのスレッドであるのか、特定のアプリケーションの全てのスレッドであるのか、又は、ある特定のスレッドのみであるのか依然として不明である。
　
　なお、請求人は、上記意見書において、指摘事項（２）に関し、次のように述べている。
「イ）　指摘事項（２）について
　本願発明の出願当初の明細書の発明の詳細な説明の欄には、「アプリケーションプロセス１３０は、スレッド数管理テーブル１４０（１５０）と複数のスレッド１３１から成り、コンポーネント管理機構１３２とコンポーネント１３４をロードして各スレッド１３１に割り当てる」（段落００２２）と記載されています。すなわち、本願発明では、１つのアプリケーションプロセス１３０が１つのコンポーネント１３４をロードし、アプリケーションプロセス１３０内の各スレッド１３１に割り当てます。出願人は、本日付けで提出した手続補正書において、上記記載に基づき、特許請求の範囲の請求項１の「それぞれコンポーネントがロードされる複数のスレッド」という誤記を、「それぞれコンポーネントが割り当てられる複数のスレッド」と補正いたしました。
　また、本願発明において、動的置換要求は、全てのアプリケーションプロセス内の全てのスレッドに対し発行されます。この点は、発明の詳細な説明の欄の００２７段落に、「メッセージキュー制御機構１２０は通信制御機構１１０からの全スレッド１３１数分の動的置換要求を受け、各アプリケーションプロセス１３０の各スレッド１３１の全てに対して動的置換要求発行する」として記載されています。」
　
　請求人の主張によると、一のコンポーネントは、一のアプリケーションプロセスにロードされ、その中の各スレッド、つまり、全てのスレッドに割り当てられるから、一のアプリケーションプロセスにロードされるコンポーネントは、通常、他のアプリケーションプロセスに使用されていないこととなる。そして、請求人の当該主張が正しいとすれば、あるコンポーネントを置換する場合、当該コンポーネントを使用する特定のアプリケーションプロセスにおいてのみ置換を行えばよく、他のアプリケーションプロセスにおいて置換処理を実行する必要はない。
　一方、明細書の段落【００３０】の記載「次の処理として新コンポーネント１６０への置換を行うのであるが（ステップＡ１０）、置換が成功しなかった場合、まだ他のアプリケーションプロセス１３０におけるコンポーネント１３４のアンロードが終了していないということなので、そのアプリケーションプロセス１３０は新コンポーネント１６０の置換完了イベント待ち合わせに入る（ステップＡ１１）。」及び段落【００３８】の記載「もしシングルプロセスであればステップＡ８、ステップＡ９の処理後置換可能であるが、マルチプロセスであれば他のアプリケーションプロセス１３０のスレッド１３１の状況により、ステップＡ１１の処理に入る。」からすると、新コンポーネントのロードは、他のアプリケーションにおける旧コンポーネントのアンロードの終了を待っているから、複数のアプリケーションプロセスにおいて、置換処理がなされる構成となっているから、前記請求人の主張と矛盾する。仮に、複数の（全てではない）アプリケーションプロセスにおいて置換の対象となるコンポーネントが使用されていると仮定すると、その特定のアプリケーションプロセスにおいてのみ置換処理を行えば足りるが、どのアプリケーションプロセスにおいて置換処理を行うべきか、及び、置換処理を行うべきアプリケーションプロセス全てにおけるアンロード終了したかをどのように判断するのか、発明の詳細な説明には一切記載されていない。
　よって、請求人の主張は、明細書の記載に基づいたものではないので採用することができない。
　また、請求人の主張が誤りであるとすると、（ア）一の「コンポーネント」が、全てのアプリケーションプロセスの全てのスレッドの全てに使用される、又は（イ）一のスレッドのみで使用される、のいずれかであるが、（ア）の場合は、全てのアプリケーションプロセスの全てのプロセスで同じコンポーネント、つまり、同じ処理が実行されることとなるが、このようなシステムがどのような分野で使用されるのかを具体的に想定することができないので、本願の技術上の意義が不明である。また、（イ）の場合は、そのスレッドが置換対象のコンポーネントを使用しているのかをどのように管理し、置換対象に応じた適切な置換処理をどのように行うのか発明の詳細な説明には記載されていない。
　以上のとおり、請求項１の記載は、コンポーネントと、アプリケーションプロセス及びスレッドとの関係が不明確であり、また、いずれの関係であったとしても、発明の詳細な説明には、当業者が発明を実施できる程度に明確かつ十分に記載されていない。
　したがって、指摘事項（２）に係る拒絶理由は依然として解消していない。
　
４．むすび
　したがって、本件出願は、明細書及び図面の記載が、特許法第３６条第４項及び第６項第１号及び第２号に規定する要件を満たしていない。
　よって、結論のとおり審決する。