【事件の表示】
　特願２００７−　３４８８５「コンテインメントフレームワーク環境で資源を管理する装置および方法」拒絶査定不服審判事件〔平成１９年　９月　６日出願公開、特開２００７−２２６７９０〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１　手続の経緯・本願発明
　本件審判の請求に係る特許願（以下、「本願」という。）は、平成１９年２月１５日（パリ条約による優先権主張外国庁受理２００６年２月２１日、大韓民国）を出願日とする出願であって、平成２１年９月１８日付けで拒絶の理由が通知され、平成２２年１月８日付けで意見書が提出されるとともに手続補正がなされ、同年６月１０日付けで拒絶査定がなされた。これに対し、同年１０月１５日付けで拒絶査定に対する審判請求がなされるとともに手続補正がなされ、平成２３年２月２５日付けで審査官から前置報告がなされ、同年４月２２日付けで当審より審尋がなされ、同年７月２６日付けで回答書が提出されたものである。
　そして、特許請求の範囲の請求項９に係る発明（以下「本願発明」という。）は、平成２２年１０月１５日付け手続補正書の特許請求の範囲の請求項９に記載された以下のとおりのものと認める。
「（ａ）所定の資源が割当てられたアプリケーションの固有識別子を生成するステップと、
（ｂ）前記資源と前記固有識別子との間の連結を締結または解除するステップと、
（ｃ）前記連結が締結された場合は前記資源使用に対するカウンタをリアルタイムで増加させ、前記連結が解除された場合は前記資源使用に対するカウンタをリアルタイムで減少させるステップと、
（ｄ）前記カウンタが０である場合は前記資源の解除を行うステップとを含み、
　前記（ｃ）ステップは、１つのアプリケーションに割当てられたすべての資源に対する前記カウンタの増加または減少を行うステップを含むコンテインメントフレームワーク環境で資源を管理する方法。」
　
２　引用例
（１）原査定の拒絶の理由に引用された特開平１１−４５１８７号公報（以下、「引用例」という。）には、図面とともに次の記載がある。（下線は参考のために当審にて付した。）
　
ア　「【０００１】
【発明の属する技術分野】本発明は、一般に、コンピューターシステムのためのガーベッジコレクションに関し、更に詳しくは、
リファレンスと結合し、あるいは関連しているリソースを収集するための耐故障性の分散ガーベッジコレクションの方法
　
イ　『【００３２】（Ａ．総括）
分散処理システム中にある各コンピュータに配置されている方法呼出要素（以下、「ＭＩ要素」という）が、本発明に係る分散ガーベッジコレクション機構を実行する。ＭＩ要素は、好ましくは、プログラム言語ＪＡＶＡ（登録商標）によって書かれた多くのソフトウェアモジュールからなっている。
【００３３】一般に、
分散処理システム中のアプリケーションが、分散リソースに対するリファレンスを、ネームの索引あるいは他の方法によって、ある他のコールに対するリターン値として取得し、そのリソースへのアクセスをシークする時はいつでも、そのアプリケーションは、そのリソースに対し、あるいはそのリソースを管理するＭＩ要素に対してコールを行う。
【００３４】マネージングＭＩ要素と呼ばれるこのＭＩ要素は、そのリソースに対して突出しているリファレンス数のトラックをキープする。あるリソースに対するリファレンスの数がゼロの時は、マネージングＭＩ要素は、そのリソースをリクレームすることができる。あるリソースに対するリファレンス数のカウントは、一般に、「リファレンスカウント」と呼ばれており、リファレンスカウントを増加させるコールは、「ダーティーコール」と称される。
【００３５】アプリケーションが、もはや分散リソースを要求しない時は、アプリケーションは、そのリソースに対しあるいはマネージングＭＩ要素に対して、異なるコールを送信する。このコールの受信に基づき、マネージングＭＩ要素は、そのリソースのリファレンスカウントを減少させる。このリファレンスを落とすためのコールは、「クリーンコール」と称される。』
　
ウ　「【００３８】（１．アプリケーションコールプロセッサー）図１は、分散処理システム中に配置されている同一又は他のＭＩ要素によって管理されるリソースに対するリファレンスのためのアプリケーションの要求を取り扱うために、ＭＩ要素のアプリケーションプロセッサーが使用する手順１００のフロー図を示したものである。
【００３９】
アプリケーションがあるリソースに対するリファレンスを取得した後、アプリケーションコールプロセッサーは、リソースのリファレンス及び要求されたリース期間を含むダーティーコールを、そのリソースのためのマネージングＭＩ要素に対して送信する
・・・（中略）・・・
【００４１】アプリケーションコールプロセッサーは、アプリケーションによるそのリファレンスの使用を監視し、そのアプリケーションが、アプリケーションコールプロセッサーに対し、そのリファレンスがもはや要求されないということを明確に知らせた時、又は、そのアプリケーションプロセッサーが、自分自身でその決定を下したの時のいずれかの時（ステップ１３０）には、アプリケーションコールプロセッサーは、マネージングＭＩ要素に対してクリーンコールを送信する（ステップ１４０）。ダーティーコールに用いられた方法と同様の方法により、クリーンコールは、リファレンスされたリソースに向けられ、マネージングＭＩ要素は、クリーンコールを処理する。続いて、アプリケーションコールプロセッサーは、アプリケーションによって使用されているリファレンスのリストからそのリファレンスを削除する（ステップ１５０）。」
　
エ　「【００４４】（ｉ．ダーティーコール）図２は、ＭＩソフトウェア要素が管理するリファレンスされたリソースに対する要求、すなわちダーティーコールを処理するために、ＭＩ要素のサーバーコールプロセッサーが使用する手順２００のフロー図である。これらの要求は、分散処理システム中にあるＭＩ要素のアプリケーションコールプロセッサーからくるものであり、そのアプリケーションコールプロセッサーには、要求を処理するサーバーコールプロセッサーと同じＭＩ要素中のアプリケーションコールプロセッサーも含まれている。
【００４５】最初に、
サーバーコールプロセッサーは、ダーティーコールを受信する
【００４６】
リソースがダーティーコールのリファレンスにより未だ割り当てられていないとサーバーコールプロセッサーが判断した時（ステップ２３０）には、サーバーコールプロセッサーは、要求されたリソースを割り当てる（ステップ２４０）。
【００４７】次いで、
サーバーコールプロセッサーは、ダーティーコールのリファレンスに対応するリファレンスカウントを増加させ（ステップ２５０）、
　
オ　「【００４９】（ｉｉ．クリーンコール）ＭＩ要素のサーバーコールプロセッサーは、また、アプリケーションコールプロセッサーから入ってくるクリーンコールも処理する。分散処理システム中の
アプリケーションがもはやリソースに対するリファレンスを要求しない時は、アプリケーションは、そのリソースが再使用のためにリクレームされるように、そのリファレンスのためのリソースを管理するＭＩ要素に知らせる。図３は、ＭＩ要素のサーバーコールプロセッサーがクリーンコールを処理する
【００５０】
サーバーコールプロセッサーが、ＭＩ要素が管理するリソースに対するリファレンスと共にクリーンコールを受信した時（ステップ３１０）は、サーバーコールプロセッサーは、対応するリファレンスカウントを減少させる（ステップ３２０）。
　
カ　「【００５２】
サーバーコールプロセッサーは、リファレンスカウント
を監視し、ＭＩ要素によって管理されているあるリソースについてリファレンスカウントがゼロであるか否か、あるいはあるリファレンスのための承認期間が終了したか否かを決定する（ステップ４１０）。いずれかの条件が存在するときは、サーバーコールプロセッサーは、そのリソースのガーベッジコレクションを起動する（ステップ４２０）
　
キ　【図２】には、リソースが割り当てられたか否かの判断を行い（ステップ２３０）、ステップ２３０でリソースが割り当てられてなければ新しいリソースを割り当てて（ステップ２４０）リファレンスカウンタを直ちに増加（ステップ２５０）させ、又は、ステップ２３０でリソースが割り当てられていればリファレンスカウンタを直ちに増加させるフロー図が記載されている。
　
ク　【図３】には、クリーンコールを受信すると（ステップ３１０）、リファレンスカウントを直ちに減少させる（ステップ３２０）フロー図が記載されている。
　
ケ　【図４】には、リファレンスカウントが０になっているか否かの判断を行い（ステップ４１０）、リファレンスカウントが０になってればガーベッジコレクション起動を行う（ステップ４２０）フロー図が記載されている。
　
　イの「分散処理システム中のアプリケーションが、分散リソースに対するリファレンスを、ネームの索引あるいは他の方法によって、ある他のコールに対するリターン値として取得し、そのリソースへのアクセスをシークする時はいつでも、そのアプリケーションは、そのリソースに対し、あるいはそのリソースを管理するＭＩ要素に対してコールを行う。」との記載、ウの「アプリケーションがあるリソースに対するリファレンスを取得した後、アプリケーションコールプロセッサーは、リソースのリファレンス及び要求されたリース期間を含むダーティーコールを、そのリソースのためのマネージングＭＩ要素に対して送信する」との記載、エの「サーバーコールプロセッサーは、ダーティーコールを受信する・・・（中略）・・・リソースがダーティーコールのリファレンスにより未だ割り当てられていないとサーバーコールプロセッサーが判断した時（ステップ２３０）には、サーバーコールプロセッサーは、要求されたリソースを割り当てる」との記載から、引用例には、アプリケーションは、リソースに対してコールを行い、サーバーコールプロセッサは要求されたリソースを割り当てるステップが記載されている。
　オの「アプリケーションがもはやリソースに対するリファレンスを要求しない時は、アプリケーションは、そのリソースが再使用のためにリクレームされるように、そのリファレンスのためのリソースを管理するＭＩ要素に知らせる。図３は、ＭＩ要素のサーバーコールプロセッサーがクリーンコールを処理する」の記載から、サーバーコールプロセッサーはクリーンコールを処理することによってリソースのリクレームしているといえるので、引用例には、アプリケーションがもはやリソースに対するリファレンスを要求しない時は、そのリソースのリクレームを行い、サーバーコールプロセッサーは当該リソースをアプリケーションからリクレームするステップが記載されている。
　イの「アプリケーションは、そのリソースに対し、あるいはそのリソースを管理するＭＩ要素に対してコール」との記載、エの「サーバーコールプロセッサーは、要求されたリソースを割り当てる（ステップ２４０）。・・・（中略）・・・サーバーコールプロセッサーは、ダーティーコールのリファレンスに対応するリファレンスカウントを増加させ（ステップ２５０）」との記載、オの「アプリケーションがもはやリソースに対するリファレンスを要求しない時は、アプリケーションは、そのリソースが再使用のためにリクレームされるように、そのリファレンスのためのリソースを管理するＭＩ要素に知らせる。図３は、ＭＩ要素のサーバーコールプロセッサーがクリーンコールを処理する・・・（中略）・・・サーバーコールプロセッサーは、対応するリファレンスカウントを減少させ」との記載、及び、【図２】及び【図３】のフローを参照し（キ及びクにフローの記載内容を示した。）、記載内容を検討する。【図２】のフローによれば、リソースが割り当てられたか否かの判断を行い（ステップ２３０）、ステップ２３０でリソースが割り当てられてなければ新しいリソースを割り当てて（ステップ２４０）リファレンスカウンタを増加（ステップ２５０）させ、又は、ステップ２３０でリソースが割り当てられていればリファレンスカウンタを増加（ステップ２５０）させている。ここで、ステップ２３０又はステップ２４０の直後のステップ２５０にてリファレンスカウンタを増加させているので、このフローでは、リソースの割り当てがなされていると直ちにリファレンスカウンタを増加させているといえる。また、【図３】のフローによれば、クリーンコールを受信（ステップ３１０）した直後のステップにてリファレンスカウントを減少（ステップ３２０）させているので、このフローでは、クリーンコールを受信すると直ちにリファレンスカウントを減少させているといえる。そして、これらを踏まえると、引用例には、アプリケーションからのコールによってリソースを割り当てると、直ちにリソースに対応するリファレンスカウントを増加させ、かつ、リソースがリクレームされると、直ちにリソースに対応するリファレンスカウントを減少させるステップが記載されている。
　ここで、引用例では、アプリケーションがコールしたリソースについて、サーバーコールプロセッサが割り当て又はリクレームを行った後に、そのリソースに対するリファレンスカウンタを増加又は減少させている。そして、アプリケーションがコールしてサーバーコールプロセッサーが割り当てたリソースは、アプリケーションがコールした対象であるすべてのリソースを含むので、アプリケーションに割り当てられたすべての資源といえる。よって、引用例には、１つのアプリケーションに割り当てられたすべての資源に対するリファレンスカウントの増加又は減少を行うステップが記載されている。
　カの「サーバーコールプロセッサーは、リファレンスカウント・・・（中略）・・・を監視し、ＭＩ要素によって管理されているあるリソースについてリファレンスカウントがゼロであるか否か・・・（中略）・・・いずれかの条件が存在するときは、サーバーコールプロセッサーは、そのリソースのガーベッジコレクションを起動する」との記載及び【図４】のフローを参照すると（ケにフローの記載内容を示した。）、引用例には、リファレンスカウントがゼロであれば、サーバーコールプロセッサーはそのリソースのガーベッジコレクションを起動するステップが記載されている。
　イの「分散処理システム中にある各コンピュータに配置されている方法呼出要素（以下、「ＭＩ要素」という）が、本発明に係る分散ガーベッジコレクション機構を実行する。ＭＩ要素は、好ましくは、プログラム言語ＪＡＶＡ（登録商標）によって書かれた多くのソフトウェアモジュールからなっている。」との記載、及び、アの「リファレンスと結合し、あるいは関連しているリソースを収集するための耐故障性の分散ガーベッジコレクションの方法」との記載から、引用例のリソースを収集するための分散ガーベッジコレクションの方法は、分散処理環境でリソースを管理する方法を意味することを考慮すれば、引用例には、ＪＡＶＡ言語で書かれたアプリケーションに所定のリソースを割り当てられる分散処理環境でリソースを管理する方法が記載されている。
　
　したがって、上記ア〜ケにおける記載及びその関連する図面からすると、引用例には、以下の発明（以下「引用発明」という）が記載されていると認められる。
　
　ＪＡＶＡ言語で書かれたアプリケーションに所定のリソースを割り当てられる分散処理環境において、
（１）前記アプリケーションは、リソースに対してコールを行い、サーバーコールプロセッサーは要求されたリソースをアプリケーションに割り当てるステップと、
（２）前記アプリケーションがもはやリソースに対するリファレンスを要求しない時は、サーバーコールプロセッサーは当該リソースをアプリケーションからリクレームするステップと、
（３）前記アプリケーションからのコールによってリソースを割り当てると、直ちにリソースに対応するリファレンスカウントを増加させ、かつ、リソースがリクレームされると、直ちにリソースに対応するリファレンスカウントを減少させるステップと、
（４）リファレンスカウントがゼロであれば、サーバーコールプロセッサーはそのリソースのガーベッジコレクションを起動するステップとを含み、
　前記（３）ステップは、１つのアプリケーションに割り当てられたすべてのリソースに対するリファレンスカウントの増加又は減少を行うステップを含む分散処理環境でリソースを管理する方法
　
３　対比
　本願発明と引用発明を比較する。
ア　引用発明の「リソース」は本願発明の「資源」に相当し、以下同様に、「割り当てる」は「連結を締結」することに、「リクレーム」することは「連結を」「解除」することに、それぞれ相当する。
　そして、引用発明の「（１）前記アプリケーションは、リソースに対してコールを行い、サーバーコールプロセッサーは要求されたリソースをアプリケーションに割り当てるステップ」と、本願発明の「前記資源と前記固有識別子との間の連結を締結」を比較すると、引用発明は、本願発明のように資源との連結を締結する対象をアプリケーションの固有識別子に限定していないものの、アプリケーションが要求した資源とアプリケーションの間の連結を締結するものであるといえるので、引用発明と本願発明は「資源とアプリケーションとの間の連結を締結」するものである点で共通する。
　次に、引用発明の「（２）前記アプリケーションがもはやリソースに対するリファレンスを要求しない時は、当該リソースのリクレームを行い、サーバーコールプロセッサは当該リソースをアプリケーションからリクレームするステップ」と、本願発明の「（ｂ）前記資源と前記固有識別子との間の連結を」「解除」を比較すると、引用発明は、本願発明のように資源との連結を解除する対象をアプリケーションの固有識別子に限定していないものの、アプリケーションが資源を要求しないときは資源とアプリケーションの間の連結を解除するものであるといえるので、引用発明と本願発明は「資源とアプリケーションとの間の連結を解除」するものである点で共通する。
　したがって、引用発明の「（１）前記アプリケーションは、リソースに対してコールを行い、サーバーコールプロセッサーは要求されたリソースをアプリケーションに割り当てるステップと、（２）前記アプリケーションがもはやリソースに対するリファレンスを要求しない時は、当該リソースのリクレームを行い、サーバーコールプロセッサーは当該リソースをアプリケーションからリクレームするステップ」と、本願発明の「（ｂ）前記資源と前記固有識別子との間の連結を締結または解除するステップ」とは、「（ｂ）資源とアプリケーションとの間の連結を締結または解除するステップ」である点で共通する。
イ　引用発明の「（３）前記アプリケーションからのコールによってリソースを割り当てると、直ちにリソースに対応するリファレンスカウントを増加させ、かつ、リソースがリクレームされると、直ちにリソースに対応するリファレンスカウントを減少させるステップ」及び「前記（３）ステップは、１つのアプリケーションに割り当てられたすべてのリソースに対するリファレンスカウントの増加又は減少を行うステップ」において、引用発明の「リファレンスカウント」、「直ちに」は、本願発明の「カウンタ」、「リアルタイム」に各々相当する。
　したがって、引用発明の「（３）前記アプリケーションからのコールによってリソースを割り当てると、直ちにリソースに対応するリファレンスカウントを増加させ、かつ、リソースがリクレームされると、直ちにリソースに対応するリファレンスカウントを減少させるステップ」及び「前記（３）ステップは、１つのアプリケーションに割り当てられたすべてのリソースに対するリファレンスカウントの増加又は減少を行うステップ」は、本願発明の「（ｃ）前記連結が締結された場合は前記資源使用に対するカウンタをリアルタイムで増加させ、前記連結が解除された場合は前記資源使用に対するカウンタをリアルタイムで減少させるステップ」及び「前記（ｃ）ステップは、１つのアプリケーションに割当てられたすべての資源に対する前記カウンタの増加または減少を行うステップを含む」に相当する。
ウ　引用発明の「（４）リファレンスカウントがゼロであれば、サーバーコールプロセッサはそのリソースのガーベッジコレクションを起動するステップ」において、引用発明におけるガーベッジコレクションはリクレームされたリソースを収集する機能であるから、引用発明の「サーバーコールプロセッサはそのリソースのガベージコレクションを起動する」ステップは、本願発明の「資源の解除」を行うステップに相当する。
　したがって、引用発明の「（４）リファレンスカウントがゼロであれば、サーバーコールプロセッサはそのリソースのガーベッジコレクションを起動するステップ」は、本願発明の「（ｄ）前記カウンタが０である場合は前記資源の解除を行うステップ」に相当する。
エ　引用発明の「アプリケーションに所定のリソースを割り当てられる分散処理環境において」、「分散処理環境でリソースを管理する方法」と、本願発明の「コンテインメントフレームワーク環境で資源を管理する方法」とは、両者とも資源を管理する方法といえるので、両者は「資源を管理する方法」である点で共通する。
　
　したがって、本願発明と引用発明とは、以下の点で一致し、以下の点で相違する。
［一致点］
（ｂ）資源とアプリケーションとの間の連結を締結または解除するステップと、
（ｃ）前記連結が締結された場合は前記資源使用に対するカウンタをリアルタイムで増加させ、前記連結が解除された場合は前記資源使用に対するカウンタをリアルタイムで減少させるステップと、
（ｄ）前記カウンタが０である場合は前記資源の解除を行うステップとを含み、
　前記（ｃ）ステップは、１つのアプリケーションに割当てられたすべての資源に対する前記カウンタの増加または減少を行うステップを含む資源を管理する方法。
　
［相違点１］
　本願発明は、「（ａ）所定の資源が割当てられたアプリケーションの固有識別子を生成するステップ」を含むのに対し、引用例にはこのステップについて特段の記載がない点。
　
［相違点２］
　本願発明は、「（ｂ）前記資源と前記固有識別子との間の連結を締結または解除するステップ」を含むものであるのに対し、引用発明は、資源とアプリケーションとの間の連結を締結又は解除するものではあるものの、資源と連結する対象がアプリケーションの固有識別子に限定されていない点。
　
［相違点３］
　本願発明は、「コンテインメントフレームワーク環境」を対象とした資源を管理する方法であるのに対し、引用発明は「ＪＡＶＡ言語で書かれたアプリケーションに所定のリソースを割り当てられる分散処理環境」を対象とした資源を管理する方法である点。
　
４　判断
　上記相違点について検討する。
（１）［相違点１］及び［相違点２］について
　アプリケーションに対応した固有識別子を生成する点、及びアプリケーションからの要求に対して資源を確保又は回収する際に、資源と固有識別子との間の連結を締結又は解除することは、当業者にとって周知技術（以下、「周知技術１」という。）にすぎない（例えば、特開２００２−２５９１４６号公報（以下、「周知例１」という。）の段落【００２０】、【００２１】、【００２７】には、識別子提供部１３ｃを呼び出し、資源を要求したアプリケーションの識別子を取得し、取得したアプリケーション識別子と確保した資源の資源名を組にしてテーブルに保持し、資源の回収処理の際には資源のアプリケーション識別子を取得してテーブルから当該組を削除する技術が記載されている。ここで、周知例１記載の「アプリケーションの識別子」は、本願発明の「アプリケーションの固有識別子」に相当する。さらに、周知例１記載の「取得したアプリケーション識別子と確保した資源の資源名を組にしてテーブルに保持」することは、本願発明の「資源と固有識別子との間の連結」に相当するので、周知例１記載の資源を確保することと資源を回収処理することは、各々、本願発明の「資源と固有識別子との間の連結を締結」、「資源と固有識別子との間の連結を解除」に相当する。また、周知例１ではアプリケーションの識別子を取得していることから、アプリケーションの識別子を生成していることは当業者に自明であって、アプリケーションの識別子を生成することは、本願発明の「（ａ）所定の資源が割当てられたアプリケーションの固有識別子を生成するステップ」に相当する。）。
　したがって、引用発明において当該周知技術１を適用し、「（ａ）所定の資源が割当てられたアプリケーションの固有識別子を生成するステップ」を設け、かつ、「（ｂ）資源とアプリケーションとの間の連結」を、本願発明の「（ｂ）前記資源と前記固有識別子との間の連結」とすることは、当業者が上記周知技術１に基づいて適宜なし得る程度のことにすぎない。
　
（２）［相違点３］について
　ＪＡＶＡ言語のためのフレームワークとしてコンテインメントフレームワーク環境は当業者にとって周知技術（以下、「周知技術２」という。）にすぎない（例えば、特表２００３−５０２７３０号の段落【０００６】〜【００１０】には、包括フレームワーク（コンテインメントフレームワーク）に関する記載がある。）。
　したがって、引用発明の「ＪＡＶＡ言語で書かれたアプリケーションに所定のリソースを割り当てられる分散処理環境」を、周知のコンテインメントフレームワークにおいて構成することは、上記周知技術２に基づいて当業者が適宜なし得る程度の事項にすぎない。
　
（３）まとめ
　したがって、本願発明は、引用発明、周知技術１及び周知技術２に基づいて、当業者が容易に発明をすることができたものである。そして、本願発明の構成によってもたらされる効果も、当業者であれば当然に予測可能なものにすぎず格別なものとは認められない。
　
５　むすび
　以上のとおりであって、本願発明は、引用発明、周知技術１及び周知技術２に基づいて当業者が発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　したがって、本願は、その余の請求項について論及するまでもなく、拒絶すべきものである。
　
　よって、結論のとおり審決する。