【事件の表示】
　特願２０１２−５１４６５８「リソース管理方法、計算機システムおよびプログラム」拒絶査定不服審判事件〔平成２３年１１月１７日国際公開、ＷＯ２０１１／１４２０３１、請求項の数（１５）〕について、次のとおり審決する。
【結　論】
　原査定を取り消す。
　本願の発明は、特許すべきものとする。
【理　由】
第１　手続の経緯
　本件審判請求に係る出願（以下「本願」と記す。）は、２０１０年５月１４日を国際出願日とする出願であって、平成２４年９月１９日付けで特許法第１８４条の５第１項の規定による書面が提出され、同年１０月３日付けで審査請求がなされ、平成２５年７月４日付けで拒絶理由通知（同年７月９日発送）がなされ、同年７月８日付けで上申書が提出されると共に、同日付けで手続補正書が提出され、同年８月２７日付けで意見書が提出されると共に、同日付けで手続補正書が提出され、平成２６年２月２７日付けで拒絶査定（同年３月４日謄本送達）がなされたものである。 
 　これに対して、「原査定を取り消す。本願は特許すべきものである、との審決を求める。」ことを請求の趣旨として、平成２６年６月３日付けで審判請求がされるとともに、同日付けで手続補正書が提出され、同年８月１９日付けで特許法第１６４条第３項に定める報告がなされた。 
第２　本願発明
　本願の請求項１−１５に係る発明は、平成２６年６月３日付けの手続補正で補正された特許請求の範囲の請求項１−１５に記載された事項により特定されるものと認められるところ、本願の請求項１に係る発明（以下、「本願発明」という。）は以下のとおりである。
「実行物理サーバに仮想的に割当てられ、複数のバッチアプリケーションを実行する複数の実行仮想サーバと、前記バッチアプリケーションの配置に必要な、前記実行物理サーバにおけるリソース量の計算を行なうリソース管理装置と、を備える計算機システムのリソース管理方法であって、
　前記計算機システムは、
　処理が完了している各バッチアプリケーションの処理データ件数であるロット毎に処理履歴を管理し、
　所定の契機で、ロット単位の前記処理履歴をグルーピングし、
　前記グルーピングされた処理履歴を基に、処理対象となっている前記バッチアプリケーションについて、現在までに完了している前記ロットの件数を、当該バッチアプリケーションが行なう、すべての前記ロットの件数で除算した処理進捗率と、要求処理時間内に前記バッチアプリケーションを終了するため、現在までに行なわれているべき処理の進捗率である必要進捗率と、を前記バッチアプリケーション毎に算出し、
　前記処理進捗率が前記必要進捗率に達していない前記バッチアプリケーションがあるか否かを判定し、
　前記判定の結果、前記必要進捗率に達していない前記バッチアプリケーションがある場合、前記必要進捗率および前記処理進捗率を基に、当該バッチアプリケーションについて、前記要求処理時間内の将来の所定時刻までに完了していると推定される前記ロットの件数を、当該バッチアプリケーションが行なう、すべての前記ロットの件数で除算した推定処理進捗率が、前記将来の所定時刻において行なわれているべき処理の進捗率である推定必要進捗率に達するために必要な前記リソース量を算出し、
　前記算出したリソース量に従って、前記バッチアプリケーションを実行している前記実行仮想サーバに割当てる前記リソースを変化させる
　ことを特徴とするリソース管理方法。」
第３　原査定の理由の概要
１．平成２５年７月４日付け拒絶理由通知  
 　 
　平成２５年７月４日付けで拒絶理由が通知されたが，その内容は下記のとおりである。
「１．この出願の下記の請求項に係る発明は、その出願前に日本国内又は外国において、頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
２．この出願は、特許請求の範囲の記載が下記の点で、特許法第３６条第６項第２号に規定する要件を満たしていない。
　　　　　　　　　　　　　　　　　記
［引用文献等一覧］
１．特開２００９−　２５９３９号公報
２．特開２００９−　８６７３３号公報
［理由１］
［請　求　項］１−１６
［引用文献等］１、２
［備考］
　引用文献１には、アプリケーションソフトウェアタスクの実行を制御するタスク制御方法において、アプリケーションソフトウェアタスクの処理の経過時間から進捗状況を判断し、進捗状況が遅れている場合に、進捗の遅れを挽回するために、タスクが利用するリソースを制御するタスク制御方法が記載されている（段落【００３２】−【００３８】、第２図等）。
　引用文献２には、アプリケーションの進捗度に応じて、ＣＰＵ時間の割り当てを変更する情報処理装置において、処理したループカウント値を総ループ回数で除した結果を、進捗度とし、現在までに実行した時間と進捗度から実行中のアプリケーションの実行処理に要するＣＰＵ時間を予測し、ＣＰＵ時間が不足する場合には、追加のＣＰＵ時間を割り当てる技術が開示されている（段落【００７２】−【００８２】等）。
　したがって、本願の請求項１−１６に係る発明は、引用文献１、２に記載された発明に基づいて、当業者が容易に推考できたものである。
［理由２］
［請　求　項］１−１６
イ）請求項１に記載の、「前記判定の結果、前記必要な進捗率に達していない場合、前記必要進捗率および前記処理進捗率の差分である遅延回復対象進捗率と、リソースの情報と、を基に、前記要求処理時間前に前記処理進捗率が前記必要進捗率に達するために必要なリソースを算出する」は、何らかの情報を基に算出等の処理を行う際には、算出のために用いる情報およびその関係や、具体的な算出の処理内容に応じて、得られる構成が異なってくることが、技術常識であるところ、単に、「・・・遅延回復対象進捗率と、リソースの情報と、を基に、・・・ために必要なリソースを算出する」では、「リソースの情報」が何を意味するのか不明であるし、リソースを算出するための基礎となる情報およびその関係や、具体的な算出の処理内容等が不明であり、発明の構成が明確でない。
　また、「前記要求処理時間前に前記処理進捗率が前記必要進捗率に達するために必要なリソース」は、「要求処理時間前に」とする時期・条件についての比較の基準又は程度が不明瞭であるし、「前記処理進捗率」は、「現在時刻における処理の進捗率」を意味するとしても、「現在時刻における処理の進捗率」が、「前記必要進捗率に達する」とは、いつの時点の処理の進捗率が、どのようになることを意味するのか明瞭に把握できず、どのようなリソースの算出をするのか明確でない。
ロ）請求項５に記載の、「前記必要処理件数」は、前記されていない。
ハ）請求項７に記載の、「予め設定しておいた予備のリソースに前記バッチアプリケーションを割当てたときのリソース量を算出する」は、予備のリソースにアプリケーションを割当てることと、リソース量を算出することとの関連が日本語としても技術内容としても不明であり、発明の構成を把握できない。また、当該リソース量を算出することを、いずれの構成要素が如何なる事項間の関連により、どのような量を算出するのかも不明である。
　請求項９に記載の、アプリケーションを置換することと、リソース量を算出することとの関連、当該リソース量を算出することについても同様である。
ニ）請求項８に記載の、「前記バッチアプリケーションの割当てに必要な時間を考慮する」は、「バッチアプリケーションの割当てに必要な時間」とは、割当てに関する如何なる観点での必要な時間を意味するのか、特段の定義もなく、また、それを一義に理解する技術常識もなく不明であり、また、「・・・を考慮する」は、人為的な処理であり、技術内容として何れの構成要素による如何なる処理・動作を意味するのか不明であり、発明の構成が明確でない。
　請求項１０についても同様である。
　上記イ）−ハ）で検討した点について、請求項１１−１６の対応する事項・記
載についても同様である。
　よって、本願の請求項１−１６に係る発明は明確でない。 」
２．平成２６年２月２７日付け拒絶査定  
 　 
　平成２６年２月２７日付けで拒絶査定がなされたが，その内容は下記のとおりである。
「　この出願については、平成２５年　７月　４日付け拒絶理由通知書に記載した理由１によって、拒絶をすべきものです。
　なお、意見書並びに手続補正書の内容を検討しましたが、拒絶理由を覆すに足りる根拠が見いだせません。
［備考］
　出願人は、補正書で補正後の請求項１において、処理進捗率を、「処理対象となっている前記バッチアプリケーションについて、現在までに完了している前記ロットの件数を、当該バッチアプリケーションが行うすべての前記ロットの件数で除算した処理進捗率」と補正するとともに、意見書において、「本願請求項１に係る発明は、アプリケーションが処理するデータを中間処理単位データであるロット単位のデータに分割し、ロット単位で進捗状況を判断しています。このため遅延の状況を判断するのが容易であり、追加のＣＰＵ数などのリソース量を見積もるのが容易となります。」と主張している。
　上記の点について検討する。
　処理の進捗を、処理済みの件数を全体の件数で除算した進捗率で把握することは、例えば、文献Ａ（段落【００２９】等）等にも記載されているように、広く行われていることであり、格別の事項ではない。
　そして、引用文献１に記載の発明は、処理の進捗状況を、チェックポイントの経過状況で判断しており、チェックポイントは、タスクに予め埋め込まれたポイントであり、タスク全体に対する部分的な処理単位といえ、中間処理単位を意味するものと解される。したがって、引用文献１に記載の発明において、チェックポイントの経過状況で処理の進捗状況を判断することは、本願発明におけるロット単位での進捗状況を判断することと格別に相違するものではないから、出願人の主張は採用できない。
　したがって、本願の請求項１−１５に係る発明は、上記拒絶理由通知書及び上記備考で検討したとおり、引用文献１、２に記載された発明及び周知・慣用技術に基づいて、当業者が容易に推考できたものであるから、依然として、上記拒絶理由通知書に記載した理由は解消されていない。
［引用文献等一覧］
１．特開２００９−　２５９３９号公報
２．特開２００９−　８６７３３号公報
Ａ．特開２００８−１２３２０５号公報」
第４　当審の判断 
 　 
１．引用文献　 
 　 
（１）引用文献１に記載されている技術的事項及び引用発明 
 　 
　本願の出願日前に頒布又は電気通信回線を通じて公衆に利用可能となった、原審の平成２５年７月４日付けの拒絶理由通知において引用された、特開２００９−２５９３９号公報（平成２１年２月５日出願公開、以下、「引用文献１」という。）には、以下の技術的事項が記載されている。 （当審注：下線は、参考のために当審で付与したものである。）
Ａ　「【００２７】
  上記
マルチプロセッサシステムには、特に制限されないが、二つの汎用プロセッサ（ＣＰＵ）１００，１０１
が含まれる。
・・・（中略）・・・
【００２９】
  
ＣＰＵ１００に搭載するソフトウェアは、
アプリケーションタスク（ＡＰＰＬ）１１３から構成する。
ＣＰＵ１０１に搭載するソフトウェアは、
ＡＰＰＬ１１８である。
・・・（中略）・・・
【００３１】
  
ＣＲＭ１０３は、共有リソースコントローラ専用のＣＰＵであるＳＣＰＵ１２１、ＳＣＰＵ１２１上に搭載する
共有リソースコントローラ（ＣＲＣＬ）１２３から構成される。
Ｂ　「【００３２】
  ＜マルチプロセッサシステムにおける制御の流れ＞
  次に、図２及び図３を参照しながら、上記マルチプロセッサシステムにおける制御の流れを説明する。
【００３３】
  図２の一番上のＣＰＵ１００の欄には、ローカルリソースコントローラＬＲＣＬの流れが示され、上から三番目のＣＲＭ１０３の欄には、共有リソースコントローラＣＲＣＬ１２３の流れが示される。
【００３４】
  まず、ＬＲＣＬ１１２は、
ＡＰＰＬ１１３のあるチェックポイントの予定経過時間に、実行状況を問い合わせ（
、現在経過したチェックポイントの通知を受ける
【００３５】
  チェックポイント（ＣＰ）は、ＡＰＰＬ１１３に予め埋め込んであり、図３の３０３に示されるように、各ＣＰに対して、事前に予算、すなわち予定経過時間が定められている。ここで、ＳはＳｔａｒｔ、ＥはＥｎｄを表し、ＣＰの特殊な形である。例えば、図３において、ＣＰ２の予定経過時間は、３０１からΔｔ１＋Δｔ２３であることがわかる。この時間に実行状況を問い合わせると（２００）、ＣＰ１しか経過していないことが判明する（２０１）。すなわち、３００が現在の経過状況となる。この結果を受取り、ＬＲＣＬ１１２は、
遅れの深刻さや、終了までの残り時間と残った処理量との対比から進捗状況を把握する
【００３６】
  次に、上記進捗状況を受けて遅れを挽回するため、ＣＰＵ１００専用のローカルリソースを制御する（２０３）。例えば２０３ではＣＰＵ１００用のクロックを変更する。具体的には、図１の信号１１４を介して、ＣＫＧＥＮ１０２内のＣＫＤＩＶ１１９の分周比を変更して、ＣＰＵ１００用のクロック周波数を変更する。
【００３７】
  一方、
共有リソースを制御するために、進捗状況をＣＲＭ１０３に通知する
【００３８】
  ＣＰＵ１０１での動作もＣＰＵ１００と同様である。ＣＲＭ１０３の
ＣＲＣＬ１２３は、
ＣＰＵ１００とＣＰＵ１０１の進捗状況を比較して、２０７により、遅れがより顕著なプロセッサの共有リソースの優先度を上げる。
　ここで、上記引用文献１に記載されている事項を検討する。
ア　上記Ａの「マルチプロセッサシステムには、特に制限されないが、二つの汎用プロセッサ（ＣＰＵ）１００，１０１・・・が含まれる」及び「ＣＰＵ１００に搭載するソフトウェアは・・・アプリケーションタスク（ＡＰＰＬ）１１３から構成する。・・・ＣＰＵ１０１に搭載するソフトウェアは・・・ＡＰＰＬ１１８である」より、ＣＰＵ１００及びＣＰＵ１０１は、それぞれアプリケーションタスクを実行することは自明であるから、引用文献１には「それぞれアプリケーションタスクを実行する複数のプロセッサ」が記載されているものと解される。
イ　上記Ａの「ＣＲＭ１０３は、共有リソースコントローラ専用のＣＰＵであるＳＣＰＵ１２１、ＳＣＰＵ１２１上に搭載する・・・共有リソースコントローラ（ＣＲＣＬ）１２３から構成される」及び上記Ｂの「共有リソースを制御するために、進捗状況をＣＲＭ１０３に通知する」、「ＣＲＣＬ１２３は・・・ＣＰＵ１００とＣＰＵ１０１の進捗状況を比較して、２０７により、遅れがより顕著なプロセッサの共有リソースの優先度を上げる。」より、リソースコントローラはプロセッサの進捗状況を把握してリソースを制御していることから、引用文献１には「プロセッサの進捗状況を把握し、リソース制御するリソースコントローラ」が記載されているものと解される。
ウ　上記ア、イより引用文献１には「それぞれアプリケーションタスクを実行する複数のプロセッサと、プロセッサの進捗状況を把握し、リソース制御するリソースコントローラとからなる、マルチプロセッサシステムのリソース制御方法」が記載されていると認められる。
エ　上記Ｂの「ＡＰＰＬ１１３のあるチェックポイントの予定経過時間に、実行状況を問い合わせ・・・現在経過したチェックポイントの通知を受ける」、「遅れの深刻さや、終了までの残り時間と残った処理量との対比から進捗状況を把握する・・・共有リソースを制御するために、進捗状況をＣＲＭ１０３に通知する」より、引用文献１には「チェックポイントの予定経過時間において経過したチェックポイントの通知を受け、遅れの深刻さや、終了までの残り時間と残った処理量との対比から進捗状況を把握」することが記載されているものと解される。
オ　上記Ｂの「ＣＲＣＬ１２３は・・・ＣＰＵ１００とＣＰＵ１０１の進捗状況を比較して、２０７により、遅れがより顕著なプロセッサの共有リソースの優先度を上げる」より、引用文献１には「遅れがより顕著なプロセッサに割り当てるリソースを変化させる」ことが記載されているものと解される。
　してみると、引用文献１には次の発明（以下、「引用発明」という。）が記載されているものと認められる。
「それぞれアプリケーションタスクを実行する複数のプロセッサと、プロセッサの進捗状況を把握し、リソース制御するリソースコントローラとからなる、マルチプロセッサシステムのリソース制御方法において、
　チェックポイントの予定経過時間において経過したチェックポイントの通知を受け、遅れの深刻さや、終了までの残り時間と残った処理量との対比から進捗状況を把握し、
　遅れがより顕著なプロセッサに割り当てるリソースを変化させる、方法。」
（２）引用文献２に記載されている技術的事項
　本願の出願日前に頒布又は電気通信回線を通じて公衆に利用可能となった、原審の平成２５年７月４日付けの拒絶理由通知において引用された、特開２００９−８６７３３号公報（平成２１年４月２３日出願公開、以下、「引用文献２」という。）には、以下の技術的事項が記載されている。（当審注：下線は、参考のために当審で付与したものである。）
Ｃ　「【００７２】
  まず、ＣＰＵ１２Ｂは、
ループカウンタ値を総ループ回数で除算した結果を、進捗度とする
【００７３】
  次に、ＣＰＵ１２Ｂは、現在までにアプリケーションの実行処理に要したＣＰＵ時間を、進捗度で除算した結果を、実行中のアプリケーションの実行処理に要すると予想されるＣＰＵ時間（以下、予想総ＣＰＵ時間と呼ぶ）とする（ステップＳ２０２）。なお、ＣＰＵ１２Ｂは、ＯＳ１に従って、現在までにアプリケーションの実行処理に要したＣＰＵ時間を管理しているものとする。
【００７４】
  次に、ＣＰＵ１２Ｂは、予想総ＣＰＵ時間から、現在の周期において割り当てられたＣＰＵ時間（以下、現周期の割当ＣＰＵ時間と呼ぶ）を減算した結果を、アプリケーションの実行処理を行うにあたって不足するＣＰＵ時間（以下、不足時間と呼ぶ）とする（ステップＳ２０３）。
【００７５】
  不足時間が“０”以下であれば（ステップＳ２０４のいいえ）、ＣＰＵ１２Ｂは、実行中のアプリケーションの実行処理が、現周期の割当ＣＰＵ時間内に、完了すると判定する（ステップＳ２０５）。
【００７６】
  一方、不足時間が“０”より大きければ（ステップＳ２０４のはい）、ＣＰＵ１２Ｂは、実行中のアプリケーションの実行処理が、現周期の割当ＣＰＵ時間内に、完了しないと判定する（ステップＳ２０６）。
【００７７】
  図１３は、図４のステップＳ１０７〜Ｓ１０９において、ＣＰＵ１２Ａが、スケジューラ２の割当コード２−１に従って、現周期の未割当ＣＰＵ時間から、アプリケーションに対してＣＰＵ時間の再割当を行う際の動作を示すフローチャートである。
【００７８】
  まず、ＣＰＵ１２Ａは、ＣＰＵ１２Ｂから、ＣＰＵ時間の再割当要求として、アプリケーションの種別と、そのアプリケーションの実行に不足する不足時間とを受信する。
【００７９】
  次に、ＣＰＵ１２Ａは、不足時間が現周期の未割当ＣＰＵ時間よりも大きいか否かを判定する（ステップＳ３０１）。なお、不足時間は、ＣＰＵ１２Ｂが、図１２のステップＳ２０３において、進捗管理コード３ｂ−２にしたがって算出したものである。
【００８０】
  不足時間が現周期の未割当ＣＰＵ時間よりも大きいと判定された場合（ステップＳ３０１のはい）、ＣＰＵ１２Ａは、アプリケーションに対してＣＰＵ時間の再割当を行う際に、追加するＣＰＵ時間（以下、追加割当時間と呼ぶ）を、現周期の未割当ＣＰＵ時間の残りすべてとする（ステップＳ３０２）。
【００８１】
  一方、不足時間が現周期の未割当ＣＰＵ時間より大きくないと判定された場合（ステップＳ３０１のいいえ）、ＣＰＵ１２Ａは、追加割当時間を不足時間とする（ステップＳ３０３）。
【００８２】
  次に、ＣＰＵ１２Ａは、現周期の未割当ＣＰＵ時間から追加割当時間を減算した減算結果へ、現周期の未割当ＣＰＵ時間を更新する（ステップＳ３０４）。」
（３）引用文献３に記載されている技術的事項
　本願の出願日前に頒布又は電気通信回線を通じて公衆に利用可能となった、原審の平成２６年２月２７日付けの拒絶査定において周知文献として引用された、特開２００８−１２３２０５号公報（平成２０年５月２９日出願公開、以下、「引用文献３」という。）には、以下の技術的事項が記載されている。（当審注：下線は、参考のために当審で付与したものである。） 
Ｄ　「【００２９】
図３に、記憶装置１１４に設定されているノード管理テーブル３００のデータ構成の１例を示す。ノード管理テーブル３００は、各ノードでのジョブ処理の実行状況を管理するテーブルなので、次のような項目についてのデータを含む。ノード名の欄にはノードＩＤのようなノードを一意に識別できる名称のデータを格納する。図３にはノード１及びノード２が代表的に示されている。
終了ジョブ割合の欄には各ノードでの現時点で処理したタスクの割合を示すデータを格納する。
タスクを処理するたびに処理されたタスク数をカウントしてジョブの全タスク数と比較することにより、終了ジョブ割合は算出され得る。
（４）引用文献４に記載されている技術的事項
　本願の出願日前に頒布又は電気通信回線を通じて公衆に利用可能となった、特表２００７−５２９８１２号公報（平成１９年１０月２５日公表、以下、「引用文献４」という。）には、以下の技術的事項が記載されている。（当審注：下線は、参考のために当審で付与したものである。） 
Ｅ　「【００２２】
  段１００では、第１の回路１１０が入力ビデオ信号（ＩＶＳ）を受信し、第２の回路１２０が出力ビデオ信号（ＯＶＳ）を供給する。調節ループ１３０が次いで、段１００に関連付けられる。段１００では、第３の回路３０（ＰＭ（進捗測定の略））によって、
進捗と呼ばれ、入力信号の処理データの数と、割り当て期間（例えば、フレーム期間）において処理されなければならない総データ量との比
２．対比
　本願発明と引用発明とを対比する。
（１）引用発明の「それぞれアプリケーションタスクを実行する複数のプロセッサと、プロセッサの進捗状況を把握し、リソース制御するリソースコントローラとからなる、マルチプロセッサシステムのリソース制御方法」において、リソース制御の際に何らかのリソース量の計算を行うことは自明であり、またリソースを「制御」することはリソースを「管理」するものであるとも言えるから、引用発明は本願発明と「アプリケーションを実行する複数のサーバと、サーバにおけるリソース量の計算を行うリソース管理装置と、を備える計算機システムのリソース管理方法」において共通するものである。
（２）引用発明の「遅れの深刻さや、終了までの残り時間と残った処理量との対比から進捗状況を把握」することは、本願発明と「（サーバにおける）処理の進捗状況を算出する」点において共通するものである。
（３）引用発明の「遅れがより顕著なプロセッサに割り当てるリソースを変化させる」ことは、本願発明と「アプリケーションを実行するサーバに割り当てるリソースを変化させる」点において共通するものである。
　よって、本願発明と引用発明とは、以下の点で一致し、また、以下の点で相違する。
（一致点）
「アプリケーションを実行する複数のサーバと、サーバにおけるリソース量の計算を行うリソース管理装置と、を備える計算機システムのリソース管理方法において、
　サーバにおける処理の進捗状況を算出し、
　アプリケーションを実行するサーバに割り当てるリソースを変化させる、
ことを特徴とする方法。」
 
（相違点１）
　本願発明では、実行物理サーバに仮想的に複数の実行仮想サーバを割り当てているのに対し、引用発明には仮想サーバに関する言及がない点。
（相違点２）
　本願発明は「各バッチアプリケーションの処理データ件数であるロット毎に処理履歴を管理し、所定の契機で、ロット単位の前記処理履歴をグルーピング」するのに対し、引用発明には、処理データ件数であるロット毎に処理履歴を管理すること、さらにロット単位の処理履歴をグルーピングする点について、言及がない点。
（相違点３）
　本願発明は「処理対象となっている前記バッチアプリケーションについて、現在までに完了している前記ロットの件数を、当該バッチアプリケーションが行なう、すべての前記ロットの件数で除算した処理進捗率と、要求処理時間内に前記バッチアプリケーションを終了するため、現在までに行なわれているべき処理の進捗率である必要進捗率と、を前記バッチアプリケーション毎に算出」するのに対し、引用発明には、「遅れの深刻さや、終了までの残り時間と残った処理量との対比から進捗状況を把握」するとの記載はあるものの、「管理用している前記ロットの件数を・・・すべての前記ロットの件数で除算した処理進捗率」及び「現在までに行なわれているべき処理の進捗率である必要進捗率」の算出について言及されていない点。
（相違点４）
　本願発明は「前記必要進捗率に達していない前記バッチアプリケーションがある場合、前記必要進捗率および前記処理進捗率を基に、当該バッチアプリケーションについて、前記要求処理時間内の将来の所定時刻までに完了していると推定される前記ロットの件数を、当該バッチアプリケーションが行なう、すべての前記ロットの件数で除算した推定処理進捗率が、前記将来の所定時刻において行なわれているべき処理の進捗率である推定必要進捗率に達するために必要な前記リソース量を算出」するのに対し、
引用発明には「推定処理進捗率」及び「推定必要進捗率」について言及がない点。
３．判断
　上記相違点について検討する。
（１）相違点１について
　仮想計算機は周知技術にすぎないから、引用発明のマルチプロセッサシステムに周知の仮想計算機の技術を適用することは、当業者が必要に応じて適宜なし得たものである。
（２）相違点２について
　引用発明では、処理データ件数であるロット毎に処理履歴を管理すること、さらにロット単位の処理履歴をグルーピングする点について言及がない点で、本願発明と相違することは上記のとおりである。
　しかしながら、引用文献２乃至４には、処理データ件数であるロット毎に処理履歴を管理すること、ロット単位の処理履歴をグルーピングする点については何ら記載されておらず、引用発明のマルチプロセッサシステムのリソース制御方法に適用する動機付けも見い出すことができないから、これを当業者が容易に想到し得たものとはいえない。
（３）相違点３について
　引用発明では、「管理用している前記ロットの件数を・・・すべての前記ロットの件数で除算した処理進捗率」及び「現在までに行なわれているべき処理の進捗率である必要進捗率」の算出について言及されていない点で、本願発明と相違することは上記のとおりである。
　引用文献２には、上記Ｃのとおり、ループカウンタ値を総ループ回数で除算した結果を、進捗度とすることが記載されている。
　また、引用文献３には、上記Ｄのとおり、処理されたタスク数をカウントしてジョブの全タスクと比較することにより、終了ジョブ割合を算出することが記載されている。
　また、引用文献４には、上記Ｅのとおり、処理データの数と総データ量との比を進捗としていることが記載されている。
　しかしながら、引用文献２乃至４には、ロットの件数を用いて処理進捗率を算出すること、また必要進捗率を算出することについては何ら記載されておらず、引用発明のマルチプロセッサシステムのリソース制御方法に適用する動機付けも見い出すことができないから、これを当業者が容易に想到し得たものとはいえない。
（４）相違点４について
　引用発明では、「推定処理進捗率」及び「推定必要進捗率」について言及されていない点で、本願発明と相違することは上記のとおりである。
　そして、引用文献２乃至４にも、「推定処理進捗率」及び「推定必要進捗率」については何ら記載されておらず、引用発明のマルチプロセッサシステムのリソース制御方法に適用する動機付けも見い出すことができないから、これを当業者が容易に想到し得たものとはいえない。
４．まとめ
　以上のとおりであるから、本願発明は、引用発明及び引用文献２−４に記載の技術的事項に基づいて、当業者が容易に発明をすることができたとはいえない。
５．請求項２乃至１５に係る発明について 
  
　本願の請求項２−９に係る発明は，本願発明をさらに限定したものであるから、本願発明と同様に、当業者が容易に発明をすることができたとはいえない。
　また、本願の請求項１０に係る発明は，請求項１に係る発明をシステムの発明として記載したものであり、請求項１１−１２に係る発明は請求項１０に係る発明をさらに限定したものであるから、本願発明と同様に、当業者が容易に発明をすることができたとはいえない。
　本願の請求項１３に係る発明も，請求項１に係る発明をプログラムの発明として記載したものであり、請求項１４−１５に係る発明は、請求項１３に係る発明をさらに限定したものであるから、本願発明と同様に、当業者が容易に発明をすることができたとはいえない。 
第５　むすび
　以上のとおり、本願の請求項１−１５に係る発明は、いずれも、当業者が引用発明及び引用文献２−４に記載の技術的事項に基づいて容易に発明をすることができたものではないから、原査定の理由によっては、本願を拒絶することはできない。
　また、他に拒絶すべき理由を発見しない。
　よって、結論のとおり審決する。