【事件の表示】
　特願２００９−１２３３７１「並行処理プロファイラを実装するシステム及び方法」拒絶査定不服審判事件〔平成２２年　６月１０日出願公開、特開２０１０−１２９０７９〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願は、平成２１年５月２１日を出願日（優先権主張日：２００８年１１月２５日、米国）とする出願であって、平成２３年１０月２５日付けで拒絶理由通知がなされ、平成２４年１月２７日付けで意見書の提出とともに手続補正がなされたが、同年７月６日付けで拒絶査定がなされ、これに対して平成２４年９月３日付けで拒絶査定不服審判請求がなされるとともに同日付けで手続補正がなされ、平成２５年２月１４日付けの当審の前置報告を引用した審尋に対して同年４月２５日に回答がなされ、当審において平成２６年１月２７日付けで、上記平成２４年９月３日付け手続補正の却下の決定とともに、拒絶理由通知がなされ、平成２６年４月１６日付けで意見書の提出とともに手続補正がなされたものである。 
　
２．平成２６年１月２７日付の拒絶理由通知の概要
　当審において通知した拒絶理由通知の概要は以下のとおりである。
『Ａ　この出願の下記の請求項に係る発明は、その出願前に日本国内又は外国において、頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明であるから、特許法第２９条第１項第３号に該当し、特許を受けることができない。
　　（・・・途中略・・・）
Ｂ　この出願の下記の請求項に係る発明は、その出願前に日本国内又は外国において、頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。 
 　　 
 　　　　　記　　　（引用文献等については引用文献等一覧参照）
 〔請求項１、１３、１７（引用文献１−６）〕 
　引用文献１には、Ｗｅｂ、サーブレット、ＥＪＢなどを適用して構築したシステムにおいて、ソフトウェアに内在するボトルネック箇所の特定のためにデータ収集を行う方法であって（【０００８】〜【００１０】）、コンパイラによりサーバ実行ファイルを生成する際にソースコードをプリプロセッサで処理して処理開始時刻及び処理終了時刻を取得するためのソースコードである品質測定部を埋め込み（【００４２】〜【００４９】）、試験入力データ生成部に入力引数データを与えてＨＴＴＰリクエストの準備をさせておき（【００３２】、【００３３】）、試験・運用管理実行条件管理部により所定の条件でサーバ及び試験用クライアントを起動させてＨＴＴＰリクエストをサーバに送出させるとサーバ内で実行させる処理についての処理性能データや応答性能データが取得され（【００５０】〜【００５５】）、レポートを出力する（【００６２】）ものであり、この処理性能データには各コンポーネントで実行した処理について処理開始時刻、処理終了時刻、処理名（メソッド名）、処理実行サーバ名あるいはそのサーバがコンポーネントである場合はそのクラス名を含み、そのデータを基に処理実行時間や処理実行頻度などのデータが算出され蓄積されること（【００５５】）が記載されている。 
　そして、上記理由Ａで示したように、これは請求項１に係る発明の「実行パラメータ」として「通し時間パラメータ」を選択することに相当するものである。 
　なお、ここで「実行パラメータ」の他のパラメータについても検討する。
（イ）「スループットパラメータ」、「極限スループットパラメータ」及び「利用パラメータ」について
　引用文献１の第【００３５】段落には、「さらに、単位時間あたりの実行開始した処理の数を処理実行頻度として定期的に算出する。・・・」と記載されているように、この「処理実行頻度」もいわゆるスループットである。
　また、引用文献２には、ボトルネックを識別するためにコンピュータシステムの性能情報を収集することが記載されており、その計量対象として、第【００２２】段落には「容量は、現時点におけるサービスの最大スループットの指示である。容量は、外部要因および内部構成により時間にわたり変化する。」（本願の「極限スループットパラメータ」に相当する。）と、また、第【００２３】段落には「スループットは、サービストランザクションレートである。現時点においてサービスによってどのくらいの仕事が行われているかの指示である。通常、適切な収集間隔にわたる平均である。」（本願の「スループットパラメータ」に相当する。）と、また、第【００２４】段落には「サービス時間は、トランザクションごとの、平均の現在のクロック時間である。」（本願の「通し時間パラメータ」に相当する。）と、また、第【００２６】段落には「利用度は、サービスがその容量に関係する場合におけるサービスの現在のスループットのパーセント表示である。」（本願の「利用パラメータ」に相当する。）と記載されているから、引用文献１の処理性能データとして引用文献２に記載の上記各計量対象を採用することに格別の技術的困難性はない。 
（ロ）「並行パラメータ」について 
　この「並行パラメータ」（並行［Ｐ］）は、本願明細書の第【００４５】段落及び【００４６】段落によると、「極限スループット」の算出に使用されるものと思われる。 
　この点について、一般にコンピュータシステムにおける性能評価に使用されるスループットが、単純ではないにしても多重度（本願でいう「並行［Ｐ］」に相当する。）に比例することは、例えば引用文献３（例えば第【００４８】段落等）及び引用文献４（例えば第【００４０】段落等）などに記載されているように周知であるし、また、引用文献５の第【０００３】段落にはスループット性能の算出式として、多重度である「ＣＰＵ数」倍とすることが記載されている。
　そうすると、引用文献１の処理性能データとして引用文献２に記載の「最大スループット」を採用する際に多重度も考慮することは当業者であれば容易に想到しえたことである。
（なお、後記の理由Ｃで示すように、本願の「並行パラメータ」に関して具体的にどのようなデータが生成されるのかは不明であるが、例えばコンピュータシステムの並列処理数を測定するものであるとしても、引用文献６にはサービスを並列に処理している数を検出すること（例えば第【００４０】、【００５６】段落など参照）が記載されているから、仮にこの場合であっても進歩性はない。）
 　　 
　したがって、請求項１に係る発明は、「実行パラメータ」としてどのパラメータを選択したとしても、引用文献１−６に基づいて当業者が容易になしえたものである。
　また、請求項１３の「装置」及び請求項１７の「コンピュータ読取可能な媒体」についても、上記請求項１と同様の理由により進歩性はない。
　　（・・・途中略・・・）
Ｃ　この出願は、発明の詳細な説明の記載が下記の点で、特許法第３６条第４項第１号及び特許法第３６条第６項第１号に規定する要件を満たしていない。 
 　 
 　　　　　　　　　　　　　　　　　記 
　請求項１において、「実行パラメータ」として「並行パラメータ」を選択した場合に、請求項１に係る発明は、要するに修正された複数のコードブロックを実行することにより、実行パラメータ、すなわち並行パラメータに関し、複数のコードブロックを実行することから生じるインストラメンテーションデータを生成し、生成されたインストラメンテーションデータを出力するという構成を備えたものである。
　そして、この構成に関して、明細書には以下のように記載されている。
（ａ）「【００３０】 
　ステップ２０８において、修正されたコードブロックがステップ２０６で実行されると、インストラメンテーションデータが生成される。インストラメンテーションデータは、実行パラメータに対応し、修正されたコードブロックの実行によって生じる。インストラメンテーションデータは、位置識別子、スレッド識別子、モニタ識別子、入力時間、及び終了時間のような各ボトルネックに関する情報を含んでもよい。インストラメンテーションデータは、スループット測定、通し時間測定、極限スループット測定、及び利用測定のようなパフォーマンス情報を含んでもよい。」
（ｂ）「【００４１】
　以下のメトリクスが定義される。並行［Ｐ］、スループット［Ｔ］、通し時間［Δｔ］、極限スループット［μＴ］、及び利用［Ｕ］。
【００４２】
　並行［Ｐ］は、ボトルネック内で動作可能な最大ルーチン数である。メトリックは、コンピュータプログラム論理から暗示され、ハードウェア又は負荷に依存する必要がない。上記例において、１つの要求のみが時間内のある時点で接続に働きかけることができるので［Ｐ］＝１である。Ｎ個の接続を有する場合、並行は、Ｎに等しくなる。故に、並行は、負荷に依存しないがボトルネックデザインに依存する。」
（ｃ）「【００５０】
　図４は、これらボトルネックメトリクスを示す。通し時間［Δｔ］は、ボトルネック４００の高さによって表される。並行［Ｐ］は、ボトルネック４００の部分間の幅によって表される。スループット［Ｔ］は、ボトルネック４００を通過するルーチン（矢印４０２）によって表される。
【００５１】 
　実施形態によると、並行処理プロファイラ１３０は、存在する全てのボトルネックと同数の利用を計算するために、上記定義されたメトリクスを測定する。並行処理プロファイラ１３０は、各コードブロックをインストラメント（instrument）し、一つ以上の以下の情報を記録する。
　位置：これは、階級、方法、及びボトルネックの線番号である。
　スレッド：これは、スレッド識別子である（ルーチン識別子）。
　モニタ：これは、ルーチンが努めるリソースである（例えば、同期モニタ又はロック）。
　入力時間：これは、スレッドがボトルネックに入る時間である。
　終了時間：これは、スレッドがボトルネックから出る時間である。」
（ｄ）第【００５５】段落の【表１】には、出力される情報の例として、「位置」、「スループット／ｓ」、「通し時間（ｍｓ）」、「極限スループット／ｓ」、「利用％」の測定値が表として示されている。
 　　 
　しかしながら、上記（ａ）乃至（ｄ）によると、確かに第【００５１】段落にはコードブロックの実行により記録される各種情報が示されているものの、請求項１に係る発明でいう並行パラメータ（並行［Ｐ］）に関してどのようなデータを具体的にどのように生成するのかは全く記載されていない。
　また、上記（ｄ）で示した出力される情報の例についてみても、上記（ｂ）のスループット［Ｔ］、通し時間［Δｔ］、極限スループット［μＴ］、及び利用［Ｕ］に対応して、「スループット／ｓ」、「通し時間（ｍｓ）」、「極限スループット／ｓ」及び「利用％」は出力されているものの、並行［Ｐ］についてどのような情報が出力されるのかも全く記載されていない。
　したがって、請求項１に係る発明は当業者ががその実施をすることができる程度に明確かつ十分に記載したものであるとはいえず、また、発明の詳細な説明に記載したものであるともいえないものである。
　また、請求項１３の「装置」及び請求項１７の「コンピュータ読取可能な媒体」についても、上記請求項１と同様のことがいえる。
 　　 
　よって、この出願の発明の詳細な説明は、当業者が請求項１−１９に係る発明を実施することができる程度に明確かつ十分に記載されたものでなく、また、発明の詳細な説明に記載したものでもない。
 　 
 　　　　　　　　　　　引　用　文　献　等　一　覧 
 １．特開２００２−８２９２６号公報 
 ２．特開２００２−３４２１２８号公報 
 ３．特開２００４−３０２５２５号公報 
 ４．特開２００５−９９９７３号公報 
 ５．特開２００８−７１２３７号公報 
 ６．特開２００５−２２２３３２号公報 』
　　
３．本願発明について
　平成２６年４月１６日付けの手続補正書により、特許請求の範囲の請求項１は以下のように補正された。
＜補正前＞
「【請求項１】
　ハードウェアクライアント−サーバ環境で実装されるコンピュータプログラムのボトルネックを測定するコンピュータ実装方法であって、
　測定するために実行パラメータを定義し、
　インストラメンテーションコードを含むために複数のコードブロックの各コードブロックを修正し、インストラメンテーションコードは、実行パラメータに関し、
　修正された複数のコードブロックを実行し、
　実行パラメータに関し、複数のコードブロックを実行することから生じるインストラメンテーションデータを生成し、
　生成されたインストラメンテーションデータを出力する
ことからなり、
　前記実行パラメータは、並行パラメータ、スループットパラメータ、通し時間パラメータ、極限スループットパラメータ、及び利用パラメータのうち少なくとも一つを含むことを特徴とするコンピュータ実装方法。」
　　
＜補正後＞
「【請求項１】
　ハードウェアクライアント−サーバ環境で実装されるコンピュータプログラムのボトルネックを測定するコンピュータ実装方法であって、
　測定するために実行パラメータを定義し、
　インストラメンテーションコードを含むために複数のコードブロックの各コードブロックを修正し、インストラメンテーションコードは、実行パラメータに関し、
　修正された複数のコードブロックを実行し、
　実行パラメータに関し、複数のコードブロックを実行することから生じるインストラメンテーションデータを生成し、
　生成されたインストラメンテーションデータを出力する
　ことからなり、
　前記実行パラメータは、並行パラメータを含み、前記並行パラメータは、
ボトルネック内で動作可能な最大ルーチン数であり、ボトルネックの部分間の幅である
（なお、下線は補正箇所を示すものとして審判請求人が付与したものである。）
   　
４．当審の判断
［１］特許法第３６条第４項第１号及び特許法第３６条第６項第１号について
（１）上記平成２６年４月１６日付けの手続補正書による補正により、上記拒絶理由が解消したか否かについて検討する。
　上記拒絶理由通知における理由Ｃは、請求項１について、「実行パラメータ」が「並行パラメータ」の場合に、修正された複数のコードブロックを実行することにより、実行パラメータ、すなわち並行パラメータに関し、複数のコードブロックを実行することから生じるインストラメンテーションデータを生成し、生成されたインストラメンテーションデータを出力するという構成を備えたものであるのに対し、明細書には該「並行パラメータ（並行［Ｐ］）」に関してどのようなデータを具体的にどのように生成するのかは全く記載されておらず、また、その他の「実行パラメータ」である「スループット［Ｔ］」、「通し時間［Δｔ］」、「極限スループット［μＴ］」、及び「利用［Ｕ］」については、それぞれに対応して、「スループット／ｓ」、「通し時間（ｍｓ）」、「極限スループット／ｓ」及び「利用％」は出力されているものの、「並行［Ｐ］」についてどのような情報が出力されるのかも全く記載されていないから、請求項１に係る発明は当業者がその実施をすることができる程度に明確かつ十分に記載したものであるとはいえず、また、発明の詳細な説明に記載したものであるともいえないものである、というものである。
　これに対し、上記補正は補正前の「実行パラメータは、並行パラメータ、スループットパラメータ、通し時間パラメータ、極限スループットパラメータ、及び利用パラメータのうち少なくとも一つを含む」との記載を「実行パラメータは、並行パラメータを含み」とするとともに、「前記並行パラメータは、ボトルネック内で動作可能な最大ルーチン数であり、ボトルネックの部分間の幅である」との限定を加えたものである。（なお、この「ボトルネックの部分間の幅である」との記載について、明細書の第【００５０】段落に「図４は、これらボトルネックメトリクスを示す。通し時間［Δｔ］は、ボトルネック４００の高さによって表される。並行［Ｐ］は、ボトルネック４００の部分間の幅によって表される。スループット［Ｔ］は、ボトルネック４００を通過するルーチン（矢印４０２）によって表される。」と記載され、図４にはその概念図として、「並行［Ｐ］」が「ボトルネック４００の部分間の幅」によって表され、並行度が増せばその幅が広くなり、通過できるルーチンの数が増える様子が示されているが、当該記載は結局「ボトルネック内で動作可能な最大ルーチン数」である並行度についての概念を説明したものでしかない。）
　しかしながら、当該補正は、「実行パラメータ」である「並行パラメータ」の定義を特定したに過ぎず、それは明細書の記載から明らかであって、当該定義が特定されたとしても、「並行パラメータ」に関し、「複数のコードブロックを実行することから生じるインストラメンテーションデータを生成し」でいう「インストラメンテーションデータ」自体がどのような情報であり、具体的にどのように生成されるものであるのかは、依然として不明である。
　したがって、当該補正によっても上記拒絶理由は解消されず、依然として請求項１に係る発明は当業者がその実施をすることができる程度に明確かつ十分に記載したものであるとはいえず、また、発明の詳細な説明に記載したものであるともいえないものである。
（２）審判請求人の主張について
　平成２６年４月１６日付けの意見書において、審判請求人は以下のように主張している。
「（４−１）並行パラメータに関してどのようなデータを具体的にどのように生成するのかは全く記載されていない。また、本願の表１には、並行パラメータについてどのような情報が出力されるのかも全く記載されていない。
　この点につきましては、本願明細書の段落００３９〜００４９には、ボトルネックメトリクスの定義が記載されています。
　また、本願明細書の段落００４２には、「上記例において、１つの要求のみが時間内のある時点で接続に働きかけることができるので［Ｐ］＝１である。Ｎ個の接続を有する場合、並行は、Ｎに等しくなる。」と記載されています。」
　しかしながら、明細書の段落００３９〜００４９に記載の「ボトルネックメトリクスの定義」は、上記（１−１）で示したように、「実行パラメータ」である「スループット［Ｔ］」、「通し時間［Δｔ］」、「極限スループット［μＴ］」、及び「利用［Ｕ］」のそれぞれに対応して、「スループット／ｓ」、「通し時間（ｍｓ）」、「極限スループット／ｓ」及び「利用％」の各種「ボトルネックメトリクス」が生成されて出力されるのであって、「並行［Ｐ］」についてどのような情報が出力されるのかは全く記載されていないのであるから、上記主張を採用することはできない。
（３）まとめ
　以上のとおりであるから、請求項１に係る発明は、当業者がその実施をすることができる程度に明確かつ十分に記載したものであるとはいえず、また、発明の詳細な説明に記載したものであるともいえないものであるから、特許法第３６条第４項第１号及び特許法第３６条第６項第１号に規定する要件を満たしていないものである。
　　
［２］特許法第２９条第２項について
　上記［１］で示したように、請求項１に係る発明（以下、「本願発明」という）は、「並行パラメータ」に関し、「複数のコードブロックを実行することから生じるインストラメンテーションデータを生成し」でいう「インストラメンテーションデータ」自体がどのような情報であるのか不明ではあるが、本願明細書の第【００３０】段落には「ステップ２０８において、修正されたコードブロックがステップ２０６で実行されると、インストラメンテーションデータが生成される。インストラメンテーションデータは、実行パラメータに対応し、修正されたコードブロックの実行によって生じる。インストラメンテーションデータは、位置識別子、スレッド識別子、モニタ識別子、入力時間、及び終了時間のような各ボトルネックに関する情報を含んでもよい。インストラメンテーションデータは、スループット測定、通し時間測定、極限スループット測定、及び利用測定のようなパフォーマンス情報を含んでもよい。」と一応記載されていることから、本願発明における「インストラメンテーションデータ」もこれらの情報のいずれか任意のものでよいと仮定して判断する。
（１）引用例
（１−１）当審の拒絶の理由に引用された、特開２００２−８２９２６号公報（以下、「引用例１」という。）には、図面とともに、次の事項が記載されている。（なお、下線は当審において付加したものである。）
（ａ）「【０００８】
【発明が解決しようとする課題】しかし、
Web、サーブレット、EJB、CORBAなどの技術を適用して構築し、分散配備して運用する分散ＡＰの信頼性や性能といった品質を測定し、信頼性や処理時間あるいは応答時間が悪化したときに、そのボトルネックとなっているサーバを分散ＡＰ構成要素の中から特定することで分散ＡＰの品質を評価・検証することを支援し
【０００９】電子商取引などの競争の激しい分野で他事業者との差別化を図るためには、サービス提供前の試験により品質の評価検証を行い、必要に応じて実装改善や運用対処などにより品質改善を図ることで品質の確保されたサービスをサービスユーザ提供することが有効である。また、サービス導入後でユーザがサービスを利用するときに所定の品質が確保されているかを測定し、必要に応じて実装改善や運用対処を行いサービス品質の確保を図ることが必要である。今後はEJBコンポーネントなど流通しているコンポーネントを組み合わせ、必要に応じて追加拡張して所望のサービスを提供するＡＰの構築を行うＡＰ開発手法が主流になると予想されるが、コンポーネントベースのＡＰで、サービス利用時にサービスユーザから見たＡＰの品質が低下したときに品質劣化の主要因となっているコンポーネントやサーバプロセスを特定する機構が未だに確立されていない。現状では、コンポーネント技術を用いてＡＰを迅速に開発できても、その品質劣化を検出したときに、ＡＰソフトウェアに内在するボトルネック個所を特定するのに未だ多くの時間と労力が費やされている。ＡＰ試験・運用中におけるサービス品質劣化時にＡＰを構成するサーバ群の品質の測定を行い、どのコンポーネントやサーバプロセスについて実装改善や運用対処を行えばよいかを判断するための正確な情報を迅速に提供する機構(システム)が望まれる。
【００１０】本発明の目的は、
ＡＰを構成する個々のサーバの品質を測定しデータ収集してＡＰ(構成要素であるサーバ群全体)としての品質の評価・検証を行い、ＡＰの品質確保のボトルネックとなるサーバを迅速かつ正確に特定
（ｂ）「【００２１】(３)　
試験・運用管理実行条件管理部
以下のデータを格納し要求者に提供する。
【００２２】
(3-1)　
コンポーネント管理オプション
どのコンポーネントに対してポーリングを行うか、
どのコンポーネントの処理実行時間や処理実行頻度などの性能に関するデータについてどの程度の時間問隔で収集するか
のデータ
　（・・・途中略・・・）
【００２８】(3-4)　
レポートフォーマット
テキスト形式及びHTML形式に加工され格納される、処理実行時間、処理実行頻度、
などの品質測定結果データの表示フォーマットを指定するデータ
（ｃ）「【００３２】
(5)　試験入力データ生成部(図１、204、図２、302)
Webサーバプロセス(図１、241,244、図２、341)が扱うHTMLファイル群の内容からHTTPリクエスト発行に関与するURL (Unified　Resource　Locator)を検索・抽出し、さらに試験実行者から与えられた入力引数データを参照して試験用URLのリスト(図１、251)を生成する。
【００３３】
(6)
試験用クライアント部
試験入力データ生成部(図１、204、図２、302)が生成した試験用URLリスト(図１、251)を参照してWebサーバプロセス(図１、241,244、図２、341)に対してHTTPリクエストを発行する
【００３４】
(7)
品質測定部
試験用クライアント部(図１、213, 図２、310)から試験用HTTPリクエストが発行され、それに続きＡＰ実行にあたりWebサーバプロセス、サーブレット、EJBコンポーネントなどのサーバヘ処理要求が渡されたとき及び処理結果が返されるとき(測定タイミングは、後述のプリプロセッサ部が品質測定用のソースコードを埋め込んだ場所に依存する)、それらのサーバ実行される個々の処理についての処理開始時刻、処理終了時刻、処理実行サーバ名、処理名(メソッド名)などの処理性能データを取得し保持する。このとき、処理終了時刻から処理開始時刻を引くことにより処理実行時間を算出する
【００３５】さらに、
単位時間あたりの実行開始した処理の数を処理実行頻度として定期的に算出する。
（ｄ）「【００４２】
(12)
プリプロセッサ部
上記の品質測定部(図１、205-210、図２、313,316,319)をアプリケーション開発者の作成した各種サーバ実行ファイルに組み込む
【００４３】以上の構成部を用いて、上記目的を実現する。
【００４４】［実施の形態の動作］ＡＰ試験・運用管理者は、以下の実施手順に従って分散ＡＰの試験・運用管理を行う。
【００４５】
(1)　
サーバ実行ファイルヘの品質測定部の組み込み
ＡＰ開発者が作成したソースコードファイル群や分散ＡＰプラットフォームあるいはＡＰサーバが自動生成したソースコードファイル群へ品質測定部を埋め込み、その後にそれらのソースコードファイルをコンパイラに通して、サーバプロセスを起動・動作させるために必要なサーバ実行ファイルを作成する
【００４６】この手順に従いサーブレットの処理性能を計測するための品質測定部を埋め込む場合は、(a)ＡＰ開発者の作成したサーブレットのソースコードでの各々のメソッド記述の先頭部分に処理開始時刻を取得するためのソースコードを挿入するとともに、最終部分に処理終了時刻を取得するためのソースコードを挿入する(図６中の「パターン1」の方法)か、あるいは(b)スケルトンのソースコードがＡＰ開発者の作成したコードを呼び出す直前の部分に処理開始時刻を取得するためのソースコードを挿入するとともに、直後の部分に処理終了時刻を取得するためのソースコードを挿入する(図６中の「パターン2」の方法)。その後にコンパイラを用いてサーバ実行ファイルを作成する。
【００４７】また、この手順に従いEJBコンポーネントの処理性能を計測するための品質測定部を埋め込む場合は、(ｃ)アプリケーションサーバ製品付属のツールが作成したソースコードファイルのEJBコンテナ記述中にある、EJBコンポーネントのメソッドを呼び出す記述の直前に処理開始時刻を取得するためのソースコードを、直後に処理終了時刻を取得するためのソースコードを挿入する(図６の「パターン2」の方法)か、(d)スケルトンのソースコードがEJBコンテナあるいはEJBコンポーネントを呼び出す直前の部分に処理開始時刻を取得するためのソースコードを、直後の部分に処理終了時刻を取得するためのソースコードを挿入する(図６中の「パターン2」の方法)か、あるいは(e)ＡＰ開発者の作成したEJBコンポーネントのソースコードでの各々のメソッド記述の先頭部分に処理開始時刻を取得するためのソースコードを、最終部分に処理終了時刻を取得するためのソースコードを挿入する(図６中の「パターン1」の方法)。その後にコンパイラを用いてサーバ実行ファイルを作成する。
【００４８】また、この手順に従いサーブレットが要求した処理に関する応答性能を計測するための品質測定部を埋め込む場合は、(a)ＡＰ開発者の作成したサーブレットのソースコードで処理要求を起動する直前に処理要求発行時刻を取得するためのソースコードを埋め込むとともに、直後に処理結果受信時刻を取得するためのソースコードを埋め込む(図６中の「パターン2」の方法)か、あるいは(b)EJBコンポーネントが呼び出すスタブのソースコードでの各メソッド記述の先頭部分に処理開始時刻を取得するためのソースコードを、最終部分に処理終了時刻を取得するためのソースコードを挿入する(図６中の「パターン1」の方法)。その後にコンパイラを用いてサーバ実行ファイルを作成する。
【００４９】この手順に従いEJBコンポーネントが要求した処理に関する応答性能を計測するための品質測定部を埋め込む場合は、(a)ＡＰ開発者の作成したEJBコンポーネントのソースコードで処理要求を起動する直前に処理要求発行時刻を取得するためのソースコードを、直後に処理結果受信時刻を取得するためのソースコードを埋め込む(図６中の「パターン2」の方法)か、あるいは(b)EJBコンポーネントが呼び出すスタブのソースコードでの各メソッド記述の先頭部分に処理開始時刻を取得するためのソースコードを、最終部分に処理終了時刻を取得するためのソースコードを挿入する(図６中の「パターン1」の方法)。その後にコンパイラを用いてサーバ実行ファイルを作成する。」
（ｅ）「【００５０】
(2)　サーバエントリ及びＡＰエントリの設定
ＡＰ試験・運用開発者は、GUI部を介してサーバエントリとＡＰエントリをＡＰライフサイクル管理部に登録する(図２、361)。
【００５１】
(3)　
コンポーネント監視条件や性能データ取得条件の設定ＡＰ試験・運用開発者は、GUI部を介してコンポーネント管理オプション情報を試験・運用管理実行条件管理部に登録する
【００５２】
(4)　試験・運用管理ポリシの設定
ＡＰ試験・運用開発者は、GUI部を介して試験・運用合理ポリシ情報を試験・運用管理実行条件管理部に登録する(図２、361)。
【００５３】
(5)　ＡＰ起動
ＡＰ試験・運用開発者は、GUI部でＡＰエントリ名を指定し、試験・運用管理コーディネータ部を通してドメインマネージャに存在するＡＰライフサイクル管理部にＡＰ起動を要求する(図２、361)。ドメインマネージャに存在するＡＰライフサイクル管理部は、指定された名前のＡＰエントリを参照し、そのＡＰエントリを構成する個々のサーバエントリを確認し、それらのサーバエントリ毎に、サーバマネージャに存在するＡＰライフサイクル管理部にサーバプロセスの起動を要求する(図２、363、364、366、368)。サーバマネージャに存在するＡＰライフサイクル管理部は、指定されたホストで指定されたサーバ実行ファイルを用いてサーバプロセスを起動する(図２、377-379)。サーバプロセスが起動されたとき、この手続きによりＡＰを構成するサーバがすべて起動され、結果的にＡＰが起動されたことになる。
【００５４】
(6)　試験用クライアント起動
ＡＰの試験を行うにあたり、試験実行者は、GUI部を介して試験・運用管理コーディネータ部に試験用クライアントの起動を要求する(図２、361)。
起動された試験用クライアントは、試験用HTTPリクエストを指定された時間間隔でWebサーバプロセスヘ送出する(図２、380)
【００５５】
(7)　性能データ取得
Webサーバプロセスが試験用クライアント(試験時)やサービスユーザが用いるブラウザ(運用時)からHTTPリクエストを受ける(図２、370,380)と、WebサーバプロセスあるいはEJBサーバプロセスで起動されたサーブレットからEJBコンポーネントヘ(図２、371)、あるいはEJBコンポーネントから他EJBコンポーネントヘRMI/IIOPリクエストが送られ(図２、372)、その結果コンポーネント全体でサービス実行処理が進められる。各コンポーネントにて要求された処理が実行されるとき、品質測定部にて、各コンポーネントで実行した処理について処理開始時刻、処理終了時刻、処理名（メソッド名）、処理実行サーバ名あるいはそのサーバがコンポーネントである場合はそのクラス名を含む処理性能データが取得され(図２、373-375)、そのデータを基に処理実行時間(履歴、平均とも)や処理実行頻度などのデータが算出され蓄積される。また、各コンポーネントが他のコンポーネントに処理の実行を要求し処理結果を受けるときに、品質測定部にて、各コンポーネントから発行した処理要求について、その処理要求発行時刻と処理結果受信時刻、処理名（メソッド名）、及びその処理要求発行先のサーバ名あるいはそのサーバがコンポーネントである場合はそのクラス名を含む応答性能データが取得され（図２、３７３−３７５）、そのデータを元に応答時間（履歴、平均とも）などのデータが算出され蓄積される
（ｆ）「【００６２】
(9)　
信頼性・性能データ集計とレポート作成
ＡＰの試験・運用を行っているときに、品質データ収集部が・品質データ測定部からＡＰを構成する個々のコンポーネントの性能データを収集し
レポート作成部が、品質データ文集部が収集したデータを基に
性能のレポートを作成する
　　
　以上、（ａ）乃至（ｆ）の記載によれば、引用例１には以下の発明（以下、「引用発明」という）が記載されていると認められる。
「Web、サーブレット、EJB、CORBAなどの技術を適用して構築し、分散配備して運用する分散ＡＰの信頼性や性能といった品質を測定し、信頼性や処理時間あるいは応答時間が悪化したときに、そのボトルネックとなっているサーバを分散ＡＰ構成要素の中から特定することで分散ＡＰの品質を評価・検証することを支援するための方法であって、
　試験・運用管理実行条件管理部には、コンポーネント管理オプションとして、どのコンポーネントの処理実行時間や処理実行頻度などの性能に関するデータについてどの程度の時間間隔で収集するかなどについてのデータが、また、レポートフォーマットとして、テキスト形式及びHTML形式に加工され格納される、処理実行時間、処理実行頻度などの品質測定結果データの表示フォーマットを指定するデータが格納されており、
　試験用クライアント部は、試験入力データ生成部が生成した試験用URLリストを参照してWebサーバプロセスに対してHTTPリクエストを発行するものであり、
　品質測定部は、試験用クライアント部から試験用HTTPリクエストが発行され、それに続きＡＰ実行にあたりWebサーバプロセス、サーブレット、EJBコンポーネントなどのサーバヘ処理要求が渡されたとき及び処理結果が返されるとき(測定タイミングは、後述のプリプロセッサ部が品質測定用のソースコードを埋め込んだ場所に依存する)、それらのサーバ実行される個々の処理についての処理開始時刻、処理終了時刻、処理実行サーバ名、処理名(メソッド名)などの処理性能データを取得し保持し、処理終了時刻から処理開始時刻を引くことにより処理実行時間を算出し、さらに、単位時間あたりの実行開始した処理の数を処理実行頻度として定期的に算出するものであり、
　プリプロセッサ部は、上記の品質測定部をアプリケーション開発者の作成した各種サーバ実行ファイルに組み込むものであり、
　サーバ実行ファイルヘの品質測定部の組み込みは、ＡＰ開発者が作成したソースコードファイル群や分散ＡＰプラットフォームあるいはＡＰサーバが自動生成したソースコードファイル群へ品質測定部を埋め込み、その後にそれらのソースコードファイルをコンパイラに通して、サーバプロセスを起動・動作させるために必要なサーバ実行ファイルを作成することで行われ、
　ＡＰ試験・運用開発者は、GUI部を介してコンポーネント管理オプション情報を試験・運用管理実行条件管理部に登録し、
　ＡＰの試験を行うにあたり、試験実行者は、GUI部を介して試験・運用管理コーディネータ部に試験用クライアントの起動を要求すると、起動された試験用クライアントは、試験用HTTPリクエストを指定された時間間隔でWebサーバプロセスヘ送出し、
　Webサーバプロセスが試験用クライアント(試験時)やサービスユーザが用いるブラウザ(運用時)からHTTPリクエストを受けると、WebサーバプロセスあるいはEJBサーバプロセスで起動されたサーブレットからEJBコンポーネントヘ、あるいはEJBコンポーネントから他EJBコンポーネントヘRMI/IIOPリクエストが送られ、その結果コンポーネント全体でサービス実行処理が進められ、各コンポーネントにて要求された処理が実行されるとき、品質測定部にて、各コンポーネントで実行した処理について処理開始時刻、処理終了時刻、処理名（メソッド名）、処理実行サーバ名あるいはそのサーバがコンポーネントである場合はそのクラス名を含む処理性能データが取得され、そのデータを基に処理実行時間(履歴、平均とも)や処理実行頻度などのデータが算出され蓄積され、また、各コンポーネントが他のコンポーネントに処理の実行を要求し処理結果を受けるときに、品質測定部にて、各コンポーネントから発行した処理要求について、その処理要求発行時刻と処理結果受信時刻、処理名（メソッド名）、及びその処理要求発行先のサーバ名あるいはそのサーバがコンポーネントである場合はそのクラス名を含む応答性能データが取得され、そのデータを元に応答時間（履歴、平均とも）などのデータが算出され蓄積され、
　ＡＰの試験・運用を行っているときに、品質データ収集部が品質データ測定部からＡＰを構成する個々のコンポーネントの性能データを収集し、レポート作成部が、品質データ収集部が収集したデータを基に性能のレポートを作成する、方法。」
       　
（１−２）当審の拒絶の理由に引用された、特開２００４−３０２５２５号公報（以下、「引用例２」という。）には、図面とともに、次の事項が記載されている。（なお、下線は当審において付加したものである。）
（ｇ）「【００４８】
図４に示すように、
処理の多重度を上げるとスループット（単位時間内に処理できるトランザクションの数）は初期の段階では上がるが次第に横ばい状態になる。一方、レスポンスについては、処理の多重度を上げると一般的にレスポンスは単調に下がる
   　
（１−３）当審の拒絶の理由に引用された、特開２００５−９９９７３号公報（以下、「引用例３」という。）には、図面とともに、次の事項が記載されている。（なお、下線は当審において付加したものである。）
（ｈ）「【００４０】
　図７は、応答時間とスループットの算出結果一例を示す。多重度７０１は運用管理対象システム１０１において業務を同時に実行する人数、応答時間７０２は多重度７０１を変化したときの応答時間（秒）、
スループット７０３は多重度７０１を変化したときのスループット（件／秒）を示す。
一方スループット７０３は、変曲値７０５までは多重度７０１に比例して増加し、変曲値７０５を越えると一定値（限界スループット７０４）に近づく。
   　
（１−４）当審の拒絶の理由に引用された、特開２００８−７１２３７号公報（以下、「引用例４」という。）には、図面とともに、次の事項が記載されている。（なお、下線は当審において付加したものである。）
（ｊ）「【０００３】
　一般に、サーバのトランザクション処理のスループットは以下の式で求められる。
（スループット性能）＝（ＣＰＵ数×ＣＰＵ周波数×定数）÷（ＣＰＵの実行ステップ数×ＣＰＩ）
　ここで、上記定数はスループットの値を単位時間当たり、あるいは単位秒あたりに変換する数を指す。CPIは、ＣＰＵの１命令あたりの実行サイクル数のことである。
性能を改善するためには、ＣＰＵ数
大きくし
   　
（２）対比
　そこで、本願発明と引用発明とを比較する。
（ア）引用発明の「Web、サーブレット、EJB、CORBAなどの技術を適用して構築し、分散配備して運用する分散ＡＰの信頼性や性能といった品質を測定し、信頼性や処理時間あるいは応答時間が悪化したときに、そのボトルネックとなっているサーバを分散ＡＰ構成要素の中から特定することで分散ＡＰの品質を評価・検証することを支援するための方法」は、サーバにおいて実装されるアプリケーションプログラムである分散ＡＰ構成要素の中からボトルネックを特定するために、性能を測定するものである。
　また、引用発明の「試験用クライアント部は、試験入力データ生成部が生成した試験用URLリストを参照してWebサーバプロセスに対してHTTPリクエストを発行するものであり」及び「ＡＰの試験を行うにあたり、試験実行者は、GUI部を介して試験・運用管理コーディネータ部に試験用クライアントの起動を要求すると、起動された試験用クライアントは、試験用HTTPリクエストを指定された時間間隔でWebサーバプロセスヘ送出し」との記載からも明らかなように、いわゆるハードウェアであるクライアントとサーバ環境において実装されるアプリケーションを測定の対象とするものである。
　そうすると、本願発明と引用発明は、後記する点で相違するものの、
「ハードウェアクライアント−サーバ環境で実装されるコンピュータプログラムのボトルネックを測定するコンピュータ実装方法」
である点で共通している。
（イ）引用発明の「試験・運用管理実行条件管理部には、コンポーネント管理オプションとして、どのコンポーネントの処理実行時間や処理実行頻度などの性能に関するデータについてどの程度の時間間隔で収集するかなどについてのデータが、また、レポートフォーマットとして、テキスト形式及びHTML形式に加工され格納される、処理実行時間、処理実行頻度などの品質測定結果データの表示フォーマットを指定するデータが格納されており」及び「ＡＰ試験・運用開発者は、GUI部を介してコンポーネント管理オプション情報を試験・運用管理実行条件管理部に登録し」との記載によると、性能に関するデータを収集するのに際し、「どのコンポーネントの処理実行時間や処理実行頻度などの性能に関するデータについてどの程度の時間間隔で収集するかなどのデータ」や、「処理実行時間、処理実行頻度などの品質測定結果データの表示フォーマットを指定するデータ」が事前に登録、すなわち定義されており、これらのデータも性能に関するデータの収集実行時のパラメータであるといえるから、これらのデータは本願発明の「実行パラメータ」に対応するものである。
　そうすると、本願発明と引用発明は、後記する点で相違するものの、
「測定するために実行パラメータを定義し」
ている点で共通している。
（ウ）引用発明の「品質測定部は、試験用クライアント部から試験用HTTPリクエストが発行され、それに続きＡＰ実行にあたりWebサーバプロセス、サーブレット、EJBコンポーネントなどのサーバヘ処理要求が渡されたとき及び処理結果が返されるとき(測定タイミングは、後述のプリプロセッサ部が品質測定用のソースコードを埋め込んだ場所に依存する)、それらのサーバ実行される個々の処理についての処理開始時刻、処理終了時刻、処理実行サーバ名、処理名(メソッド名)などの処理性能データを取得し保持し、処理終了時刻から処理開始時刻を引くことにより処理実行時間を算出し、さらに、単位時間あたりの実行開始した処理の数を処理実行頻度として定期的に算出するものであり」、「プリプロセッサ部は、上記の品質測定部をアプリケーション開発者の作成した各種サーバ実行ファイルに組み込むものであり」、及び「サーバ実行ファイルヘの品質測定部の組み込みは、ＡＰ開発者が作成したソースコードファイル群や分散ＡＰプラットフォームあるいはＡＰサーバが自動生成したソースコードファイル群へ品質測定部を埋め込み、その後にそれらのソースコードファイルをコンパイラに通して、サーバプロセスを起動・動作させるために必要なサーバ実行ファイルを作成することで行われ」との記載によると、プリプロセッサ部により、測定対象とするＡＰのソースコードファイル群（複数であることは自明）に対して、品質測定用のソースコードを埋め込む処理、すなわちの複数のコードブロックを修正する処理が行われていることから、引用発明の「品質測定用のソースコード」は本願発明の「インストラメンテーションコード」に相当するものである。
　また、引用発明の「品質測定用のソースコード」も、上記（イ）で示したパラメータに関するデータを測定するためのものである。
　そうすると、本願発明と引用発明は、後記する点で相違するものの、
「インストラメンテーションコードを含むために複数のコードブロックの各コードブロックを修正し、インストラメンテーションコードは、実行パラメータに関し」
を備える点で共通している。
（エ）引用発明の「ＡＰの試験を行うにあたり、試験実行者は、GUI部を介して試験・運用管理コーディネータ部に試験用クライアントの起動を要求すると、起動された試験用クライアントは、試験用HTTPリクエストを指定された時間間隔でWebサーバプロセスヘ送出し」及び「Webサーバプロセスが試験用クライアント(試験時)やサービスユーザが用いるブラウザ(運用時)からHTTPリクエストを受けると、WebサーバプロセスあるいはEJBサーバプロセスで起動されたサーブレットからEJBコンポーネントヘ、あるいはEJBコンポーネントから他EJBコンポーネントヘRMI/IIOPリクエストが送られ、その結果コンポーネント全体でサービス実行処理が進められ、各コンポーネントにて要求された処理が実行されるとき、品質測定部にて、各コンポーネントで実行した処理について処理開始時刻、処理終了時刻、処理名（メソッド名）、処理実行サーバ名あるいはそのサーバがコンポーネントである場合はそのクラス名を含む処理性能データが取得され、そのデータを基に処理実行時間(履歴、平均とも)や処理実行頻度などのデータが算出され蓄積され、また、各コンポーネントが他のコンポーネントに処理の実行を要求し処理結果を受けるときに、品質測定部にて、各コンポーネントから発行した処理要求について、その処理要求発行時刻と処理結果受信時刻、処理名（メソッド名）、及びその処理要求発行先のサーバ名あるいはそのサーバがコンポーネントである場合はそのクラス名を含む応答性能データが取得され、そのデータを元に応答時間（履歴、平均とも）などのデータが算出され蓄積され」との記載によると、起動された試験用クライアントは、試験用HTTPリクエストを指定された時間間隔でWebサーバプロセスヘ送出し、その結果コンポーネント全体でサービス実行処理が進められ、各コンポーネントにて要求された処理が実行されるとき、品質測定部にて、各コンポーネントで実行した処理について処理開始時刻、処理終了時刻、処理名（メソッド名）、処理実行サーバ名あるいはそのサーバがコンポーネントである場合はそのクラス名を含む処理性能データが取得され、そのデータを基に処理実行時間(履歴、平均とも)や処理実行頻度などのデータが算出され蓄積されるものであり、ここで生じた処理開始時刻、処理終了時刻、処理名（メソッド名）、処理実行サーバ名、処理実行時間、処理実行頻度は、本願発明の「インストラメンテーションデータ」に相当することは明らかである。
　そうすると、本願発明と引用発明は、後記する点で相違するものの、
「修正された複数のコードブロックを実行し、実行パラメータに関し、複数のコードブロックを実行することから生じるインストラメンテーションデータを生成し」
を備える点で共通している。
（オ）引用発明の「ＡＰの試験・運用を行っているときに、品質データ収集部が品質データ測定部からＡＰを構成する個々のコンポーネントの性能データを収集し、レポート作成部が、品質データ収集部が収集したデータを基に性能のレポートを作成する」によると、引用発明は上記（エ）で収集された各種性能データを基にレポートを作成するもの、すなわち生成された各種性能データを出力するものである。
　そうすると、本願発明と引用発明は、後記する点で相違するものの、
「生成されたインストラメンテーションデータを出力する」
を備える点で共通している。
（カ）以上の（ア）乃至（オ）から、本願発明と引用発明は、
「ハードウェアクライアント−サーバ環境で実装されるコンピュータプログラムのボトルネックを測定するコンピュータ実装方法であって、
　測定するために実行パラメータを定義し、
　インストラメンテーションコードを含むために複数のコードブロックの各コードブロックを修正し、インストラメンテーションコードは、実行パラメータに関し、
　修正された複数のコードブロックを実行し、
　実行パラメータに関し、複数のコードブロックを実行することから生じるインストラメンテーションデータを生成し、
　生成されたインストラメンテーションデータを出力する
　ことを特徴とするコンピュータ実装方法」
である点で一致し、以下の点で相違している。
　　
［相違点］
　本願発明では、「前記実行パラメータは、並行パラメータを含み、前記並行パラメータは、ボトルネック内で動作可能な最大ルーチン数であり、ボトルネックの部分間の幅である」のに対し、引用発明ではそのようになっていない点。
　　
（３）当審の判断
　上記相違点における「ボトルネックの部分間の幅である」との記載は、前記４．［１］（１）で述べたように、単に並行度についての概念を説明したものでしかなく、ここでの「並行パラメータ」は、「ボトルネック内で動作可能な最大ルーチン数」であり、いわゆる並行度や多重度を意味するものである。
　この点について、一般にコンピュータシステムにおける性能評価に使用されるスループットが、単純ではないにしても多重度に比例することは、例えば引用例２の（ｇ）及び引用例３の（ｈ）などに記載されており、また、引用例４にもスループット性能の算出式として、多重度である「ＣＰＵ数」倍とすることが記載されており、コンピュータシステムにおける性能評価のパラメータとして並行度や多重度を使用することは周知の技術であるといえる。
　そして、引用発明もサーバにおける各種性能データを測定して性能を評価するものであり、また、引用発明における「単位時間あたりの実行開始した処理の数」である「処理実行頻度」もスループットを算出しているといえることから、上記周知技術を引用発明に適用し、性能評価のパラメータとして並行度や多重度も使用して各種性能データを算出することにより上記相違点に係る構成とすることは、当業者であれば容易に想到し得たことである。
　　
（４）まとめ
　以上のとおりであるから、請求項１に係る発明は、引用発明及び引用例２乃至４に記載の周知技術に基づいて当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができないものである。
　そして、請求項１に係る発明の作用効果も、引用発明及び引用例２乃至４に記載の周知技術から当業者が予測できる範囲のものである。
　　
５．むすび
　以上のとおり、請求項１に係る発明は、当業者がその実施をすることができる程度に明確かつ十分に記載したものであるとはいえず、また、発明の詳細な説明に記載したものであるともいえないものであるから、特許法第３６条第４項第１号及び特許法第３６条第６項第１号に規定により特許を受けることができないものであり、また、引用発明及び引用例２乃至４に記載の周知技術に基づいて当業者が容易に発明をすることができたものであり、特許法第２９条第２項の規定により特許を受けることができないものでもあるから、その余の請求項について検討するまでもなく、本願は拒絶すべきものである。
　　　
　よって、結論のとおり審決する。