【事件の表示】
　平成　６年特許願第２５３７６４号「データ処理装置及び方法」拒絶査定不服審判事件〔平成　８年　５月　７日出願公開、特開平　８−１１５２２５〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願は、平成６年１０月１９日の出願であって、平成１６年８月３日に拒絶査定がなされ、同年９月９日に審判請求がなされ、平成１８年５月９日に当審より拒絶理由通知がなされ、同年７月１０日に意見書及び手続補正書が提出されたものであり、「データ処理装置及び方法」に関するものと認められる。
　
２．当審の拒絶理由について
　
２−１．当審の拒絶理由通知の概要
　当審における平成１８年５月９日付け拒絶理由通知では、次のように指摘している。
　
　この出願は、明細書及び図面の記載が下記の点で、特許法第３６条第４項並びに第５項第１号、第２号及び第６項に規定する要件を満たしていない。　
　　　　　　　　　　　　　　　　記
　
１．請求項１，２において、「プロセスの処理量」なる記載があるが、「処理量」とは処理に関わる何の量であり、どのように計測されるのかが不明である。（例えば処理に要する時間、あるいは消費メモリか？いずれにしてもそのように解釈できる根拠も不明である。「プロセスの処理量」の定義を明確にされたい。）
　
２．請求項１，２の、「前記プロセス処理量格納手段に格納された処理量を合計して平均を取った平均要求量を該現在平均要求量格納手段に格納する」という記載について、「平均を取る」とは、合計値を何らかの値で割るものと考えられるが、合計値を何で割っているのかが不明である。
　
３．【００１７】段落において、「処理量調整機構５は、処理単位６のプロセスの処理量をレジスタλの値に調整する（ステップＳ２４）処理量を増やす場合には、処理単位６のプロセスを新しく起動する。処理量を減らす場合には、処理単位６のプロセスを停止する。」との記載があるが、以下の点が不明である。
……（中略）……
（２）「処理単位６のプロセスの処理量をレジスタλの値に調整する」ためには、「処理単位６のプロセスの処理量」と「レジスタλの値」とを比較する必要があると考えられるが、その「処理単位６のプロセスの処理量」をどのように求めるのか不明である。（ここでいう「処理単位６のプロセスの処理量」の定義を明確にされたい。）
　
（３）上記（２）に関連して、「処理量を増やす場合には、処理単位６のプロセスを新しく起動する。処理量を減らす場合には、処理単位６のプロセスを停止する。」との記載について、どのように処理量を増やすべきか減らすべきか、あるいはそのままとするべきかを判断しているのかが不明である。
……（中略）……
６．請求項１，２における「プロセスの要求処理量」なる記載については、明細書の発明の詳細な説明【００１７】段落に記載される「プロセスの処理量」が、これに相当するものと考えられるが、用語が不統一であり、また、請求項では「プロセスの処理量」という用語が別にあることから、対応関係が不明瞭である。
　
７．請求項２において、「データ処理装置」と「平均要求量格納手段」等の各「手段」との関係が不明である。……（以下略）
　
２−２．当審の判断
　以下、上記拒絶理由において指摘した事項が解消されたか否か検討する。
　
（指摘１．について）
　請求人は平成１８年７月１０日付け意見書（以下、単に「意見書」とする。）において、「この『プロセスの処理量』とは、『当該プロセスが単位時間あたりに処理可能な又は処理した要求数（処理数）』と定義することができます。」と説明する。しかしながら、このような定義は、請求項、更に言えば、発明の詳細な説明にも記載されていない。「プロセスの処理量」という表現は、単にその字面を見た場合、個々のプロセスが処理しようとする量、個々のプロセスが処理した量、複数のプロセスが全体として処理しようとする量、複数のプロセスが全体として処理した量など、様々な解釈が考えられるものである。そのような中で、明確な記載がないにもかかわらず、「プロセスの処理量」の定義が「当該プロセスが単位時間あたりに処理可能な又は処理した要求数（処理数）」であると解することはできないから、請求人の意見書における説明は採用できず、「プロセスの処理量」の定義は依然として明確でない。
　また、請求人が説明する「定義」では、「プロセスの処理量」という用語に、「当該プロセスが単位時間あたりに処理可能な要求数」と、「当該プロセスが単位時間あたりに処理した要求数」という二つの全く異なる意味があることになるが、その結果、例えば請求項１，２における、「プロセスの処理量を調整する」という記載について、「当該プロセスが単位時間あたりに処理可能な要求数を調整する」（前者）という解釈と、「当該プロセスが単位時間あたりに処理した要求数を調整する」（後者）という解釈の二つができることになる。前者はプロセスの処理能力を調整するものと解されるのに対し、後者では、処理した要求数という結果の値を変更するもののように解され、両者は全く異なるものであるが、請求項１，２の記載からでは、いずれであるかが明確でない。よって、請求項１，２の記載は依然として不明確である。
　
（指摘２．について）
　請求人は意見書において、「『平均を取る』とは、段落００１５に、『１世代前の時刻ｔ−Ｔから現在の時刻ｔまでの間の平均要求量を採取、すなわち、プロセス処理量格納場所ｂに格納されているプロセスごとの処理量を合計して平均をとり』と記載されているように、『１世代前の時刻ｔ−Ｔから現在の時刻ｔまでに全プロセスで処理した要求数の合計をＴで割る』ことを意味します。
　即ち、『平均を取った平均要求量』は、時間間隔Ｔにおける単位時間あたりの全プロセスの平均要求処理量となります。その具体例が、段落００１８に説明され、計算式が示されています。」と説明する。しかしながら、ここで根拠として引用されるのは、いずれも発明の詳細な説明における実施例についての記載であり、請求項１，２にこのようなことは記載されていない。
　よって、請求人の意見書における説明は、請求項の記載に基づかないものであるから採用できず、請求項１，２の記載における「平均を取った」という処理は、何で割る処理なのか、つまり、何に関する平均なのか、依然として不明確である。
　
（指摘３．（２），（３）について）
　請求人は意見書において、定義表を用いた処理方法について説明しているが、このような内容は明細書の記載から読み取ることはできず、根拠が不明である。
　よって、請求人の意見書における説明は採用できず、「処理単位６のプロセスの処理量」をどのように求めるのか、及び、どのように処理量を増やすべきか減らすべきか、あるいはそのままとするべきかを判断しているのかが依然として不明である。
　
（指摘６．について）
　補正前の「プロセスの要求処理量」なる記載は、「プロセスの処理量」に補正され、拒絶理由で指摘した用語の不統一は解消した。しかしながら拒絶理由で併せて指摘しているように、請求項１，２では、「クライアントからの要求に従って処理されたプロセスの処理量」の記載において「プロセスの処理量」という用語が別にある。この「クライアントからの要求に従って処理されたプロセスの処理量」は、明細書の発明の詳細な説明【００１７】段落にある、プロセスの起動・停止によって調整される「プロセスの処理量」とは異なるものと解されるが、同一の用語となっているため、請求項の記載と発明の詳細な説明との対応関係が依然として不明りょうである。
　
（指摘７．について）
　補正された請求項２の記載を検討しても、「データ処理装置」と、「現在平均要求量格納手段」等の各「手段」との関係が何ら特定されておらず、その結果、例えば、「プロセスの処理量をプロセス処理量格納手段に格納する」という処理が、データ処理装置の内部処理なのか、データ処理装置と他の装置とのやりとりであるのかが不明であり、構成が明確でない。よって、請求項２の記載は依然として不明確である。
　
　よって、本願の特許請求の範囲の記載は、請求項１，２に係る発明について、依然として、発明の詳細な説明に記載したものでなく、また、不明確であるから、特許法第３６条第５項第１号、第２号及び第６項に規定する要件を満たしていない。
　また、本願明細書の発明の詳細な説明は、その発明の属する技術の分野における通常の知識を有する者がその実施をすることができる程度に明確かつ十分に、請求項１，２に係る発明の構成を記載していないから、特許法第３６条第４項に規定する要件を満たしていない。
　
３．原審における特許法第２９条第２項の拒絶理由について
　原審において、平成１６年５月１８日付けで通知された、特許法第２９条第２項の拒絶理由についても検討する。
　
３−１．本願発明
　本願の請求項１に係る発明（以下、「本願発明」という。）は、平成１８年７月１０日付けの手続補正書の特許請求の範囲の請求項１に記載された事項により特定される、以下のとおりのものである。
「プロセスの処理量を格納するプロセス処理量格納手段と、
　現在の平均要求量を格納する現在平均要求量格納手段と、
　過去の平均要求量を格納する過去平均要求量格納手段と、
　クライアントからの要求に従って処理された前記プロセスの処理量を前記プロセス処理量格納手段に格納する処理手段と、
　所定の時間間隔で、前記現在平均要求量格納手段に格納された平均要求量を前記過去平均要求量格納手段に退避し、前記プロセス処理量格納手段に格納されたプロセスごとの前記所定時間間隔内の処理量を合計して平均を取った平均要求量を該現在平均要求量格納手段に格納する要求量監視手段と、
　前記現在平均要求量格納手段に格納された平均要求量と前記過去平均要求量格納手段に格納された平均要求量とに基づいてプロセスの処理量を調整する処理量調整手段と
　を備えることを特徴とするデータ処理装置。」
　
３−２．引用例
　原査定の拒絶の理由に引用された、特開昭６２−２７９４３３号公報（以下、「引用例１」という。）には、図面とともに、以下の事項が記載されている。
　
「本発明はこのような従来の問題点を解決したもので、その目的は、システムの負荷に応じて、タスク数をシステムの運用中に動的に変更することにより、トランザクションの応答性とシステム資源の利用効率を高めることにある。」（第１頁右下欄１９行目〜第２頁左上欄３行目。）
　
「第１図は本発明の実施例のブロック図であり、１はトランザクション処理システム、２は端末、３はデータベースである。トランザクション処理システム１は、トランザクション監視手段11，タスク数変更判定手段12，タスク数変更手段13，トランザクション負荷情報格納領域16およびタスク数判定テーブル15を含むトランザクション処理管理部10を有し、また一例として３個のタスク16ａ，16ｂ，16ｃとが含められている。
　トランザクション処理管理部10は、端末２から要求のあったトランザクションを処理して応答を返すものであるが、タスク16ａ〜16ｃに空きがあれば要求のあったトランザクションをその上で動作させ、タスク16ａ〜16ｃに空きがなければ、そのトランザクションを待ち状態とする。第２図は、トランザクション処理システム１において、トランザクションＴＸ１，ＴＸ２，ＴＸ３がそれぞれタスク16ａ，16ｂ，16ｃ上で動作し、トランザクションＴＸ４，ＴＸ５，ＴＸ６がタスク16ａ〜16ｃのいずれかが空くのを待っている状況を示している。このような場合、従来は、例えば待ち状態となっているトランザクションの数が幾つになってもタスクの個数はシステム起動時に設定されたままである為、トランザクションの応答時間が遅くなるものであった。また、待ちタスクがなくタスク16ａ〜16ｃが常時空き状態であっても、タスク数は変更されず、タスクが存在することがら記憶領域等のシステム資源を占有したままとなっていた。
　本実施例では、上述のような問題点を除去するために、トランザクション処理管理部10に、トランザクション監視手段11と、タスク数変更判定手段12と、タスク数変更手段13と、トランザクション負荷情報格納領域14と、タスク数判定テーブル15とを設けている。ここで、トランザクション監視手段11はトランザクションの負荷を監視する手段であり、監視の結果は第４図に示すようにトランザクション負荷情報格納領域14に格納される。
　また、タスク数変更判定手段12はトランザクション監視手段11による監視の結果に基づき必要なタスク数を例えばタスク数判定テーブル15の内容を参照して取得し、この取得したタスク数と現在のタスク数との比較によりタスク数を変更する必要があるか否か、変更する場合、増加させるのか或いは減少させるのかを判定する手段である。更に、タスク数変更手段13は、タスク数変更判定手段12によってタスク数の変更が必要と判断された場合に、動的にタスク数を変更する手段である。これら各手段11，12，13の処理の一例を第３図に示す。以下、各図を参照して本実施例の動作を説明する。
　トランザクション監視手段11は、トランザクション処理システム１の運用中、ある一定時間内に発生したトランザクション数およびタスク待ちのトランザクション数を検知し（Ｓ31）、これを第４図に示すようにトランザクション負荷情報格納領域14に格納する（Ｓ32）。
　タスク数変更判定手段12は、トランザクション監視手段11で検知した一定時間内に発生した）トランザクション数及びタスク待ちのトランザクション数を、トランザクション負荷情報格納領域14から取出し、この情報と、タスク数判定テーブル15の内容とに基づき、必要タスク数を決定する（Ｓ33）。ここで、タスク数判定テーブル40には、トランザクション当たりの処理時間あるいはシステムで実行されるトランザクション当たりの平均タスク保留時間を基に、オンライン・システムの特定に合わせて予め決定された必要タスク数が設定されている。第５図はそのようなタスク数判定テーブル15の内容例を示し、横軸のＡ欄の各数値はタスク待ちのトランザクション数、縦軸のＢ欄の各数値は１秒間に発生したトランザクション数をそれぞれ示し、Ａ欄の数値とＢ欄の数値で特定されるＣ欄の各数値が必要タスク数である。
　さて、タスク数変更判定手段12は、上述のようにして必要タスク数を求めると、次に、この求めた必要タスク数と現在のタスク数とを比較して、タスク数の変更が必要か否か、および変更が必要な場合には増加させるのか、減少させるのかを判定する（Ｓ34，Ｓ35）。
　次にタスク数変更手段13は、タスク数変更判定手段12の判定結果を基に以下のような手続きによりタスク数の変更処理を行なう、先ず、現在のタスク数がトランザクションの負荷に対して不足している場合には、タスク生成用のマクロ命令を使って現在のタスク数と必要タスク数との差の数だけタスク数を増加する処理を行なう（Ｓ36）。また、現在のタスク数がトランザクションの負荷に対して過剰である場合には、その差だけのタスク数を削減する処理を行なう（Ｓ37）、更に、現在のタスク数に変更を要しない場合には、タスク数変更処理は、スキップされる。
　以上のような処理がオンライン・トランザクション処理中に一定周期で常時行なわれることにより、タスク数がシステムの運用中に動的に変更されることになる。」（第２頁右上欄６行目〜第３頁右上欄２０行目。）
　
　これらの記載から引用例１には、
　
　一定時間内に発生したトランザクション数を格納するトランザクション負荷情報格納領域と、
　一定周期で一定時間内に発生したトランザクション数を前記トランザクション負荷情報格納領域に格納するトランザクション監視手段と、
　必要タスク数が設定されたタスク数判定テーブルと、
　前記トランザクション負荷情報格納領域に格納された一定時間内に発生したトランザクション数に基づいてタスク数判定テーブルを参照して必要タスク数を決定するタスク数変更判定手段と、
　決定された必要タスク数に基づいて、トランザクションを処理するタスク数を変更して、トランザクションの応答性を変化させるタスク数変更手段と、
　を備えることを特徴とするトランザクション処理システム。
　
に関する発明が開示されているものと認める。（以下、これを「引用例１記載の発明」という。）
　
　また、同じく原査定の拒絶の理由に引用された、特開昭６２−１７５８３２号公報（以下、「引用例２」という。）には、図面とともに、以下の事項が記載されている。
　
「応答性に対する要求度が異なるジョブグループを複数個有する電子計算機システムでの応答性を重視されるジョブグループに属するジョブに対する資源の割り当て処理において、ジョブグループに対する資源の割り当て解放を行うグループ資源管理部と、このグループ資源管理部によりジョブグループに割り当てられた資源の中から実際にジョブに対して要求された資源の割り当てを行う資源管理部と、応答性の重視されるジョブグループの資源利用状況を収集する資源利用状況収集部と、この資源利用状況収集部により収集された資源利用状況のデータをもとに将来の必要量を予測し応答性の重視されるジョブグループに対する資源の予約を前記グループ資源管理部に要求する必要資源予測部と、一定時間毎に前記資源利用状況収集部と前記必要資源予測部を起動する収集予測起動部とを含むことを特徴とする資源管理方式。」（特許請求の範囲）
　
「以下に本発明による資源管理方式について説明する。
（１）、ジョブ16が資源管理部12に対して資源の割り当てを要求したとき、資源管理部12は、グループ資源管理表17中のそのジョブの属するグループに予約された資源の量を参照し、割り当てが可能であれば割り当てを行い、グループ資源管理表１７中の割り当て済みの資源の量を増す。割り当てが不可能であれば、グループ資源管理表７７中の割り当て待ちの資源の量を増し、待ち合わせを行う。
（２）、ジョブ16が資源管理部12に対して資源の解放を要求したとき、資源管理部12は、資源の解放を行い、グループ資源管理表17中の割り当て済みの資源の量を減らす。この後、資源待ちのジョブが存在するか否かを調べ、存在すればグループ資源管理表17中の割り当て待ちの資源の量を減らし割り当て処理を行う。
（３）、収集予測起動部15は一定時間ごとに資源利用状況収集部13と必要資源予測部14を呼び出す。
（４）、資源利用状況収集部13は収集予測起動部15から呼び出される都度グループ資源管理表17中の割り当て済みの資源の量と割り当て待ちの資源の量の和を現時刻の資源の必要量としてグループ資源利用履歴表18に登録する。このとき一番古い時刻のものは抹消する。
（５）、必要資源予測部14は、収集予測起動部15から呼び出されるとグループ資源利用履歴表18を参照し、現在および過去の資源の必要量から第２図のように将来の資源の必要量を予測する。
　必要資源予測部14は、応答性の重視されるジョブグループの資源の予約量が予測した値となるように、グループ資源管理部11に対し資源の予約量の増加または減少を要求する。
（６）、グループ資源管理部11は、必要資源予測部14からの要求に従いジョブのグループに対して資源を予約し、グループ資源管理表17中のジョブグループに予約された資源の量を更新する。予約量の増加の要求に対して、その資源が他のジョブグループに属するジョブで使用中の場合には、資源管理部11に対してそのジョブから資源を取り上げるよう要求する。」（第２頁右上欄２０行目〜右下欄２０行目。【審決注】丸付き数字は、括弧付き数字に置き換えて表記した。）
　
　これらの記載から引用例２には、
　
　電子計算機システムの資源管理方式において、一定時間ごとに、ジョブが属するジョブグループの資源の必要量をグループ資源管理表に格納し、該グループ資源管理表に格納された現在及び過去の資源の必要量に基づいてジョブグループの資源の量を変更する技術
　
　が開示されているものと認める。
　
３−３．対比
　本願発明と引用例１記載の発明とを比較する。
　まず、トランザクション処理は、データ処理の一種であるといえるから、引用例１記載の発明における「トランザクション処理システム」は、本願発明でいう「データ処理装置」に相当する。
　また、引用例１記載の発明における「一定時間内に発生したトランザクション数」は、該トランザクションを処理するトランザクション処理システムの負荷情報といえるものであり、一方、本願発明における「平均要求量」は、「プロセスごとの所定時間間隔内の処理量を合計して平均を取った」ものであるが、これは、データ処理システムに対する処理の要求が少なければ必然的に減少し、処理の要求が多ければ増加するものであるから、やはり、負荷情報といえるものである。したがって、引用例１記載の発明における「一定時間内に発生したトランザクション数」と、本願発明における「平均要求量」は、「負荷情報」である点で一致する。
　また、引用例１記載の発明における、「トランザクション負荷情報格納領域」は、「トランザクション監視手段」によって、一定周期で新たな負荷情報が格納されていることから、「現在の負荷情報」を格納するものであるということができる。してみると、引用例１記載の発明における、「トランザクション負荷情報格納領域」と、本願発明の「現在平均要求量格納手段」は、現在の負荷情報を格納する構成として一致するので、両者を「現在の負荷情報格納手段」と呼ぶことにする。
　次に、引用例１記載の発明における「一定周期で」とは、本願発明における「所定の時間間隔で」に相当する。そして、引用例１記載の発明における「トランザクション監視手段」と、本願発明における「要求量監視手段」とは、「所定の時間間隔で、負荷情報を現在の負荷情報格納手段に格納する監視手段」である点で一致する。
　また、引用例１記載の発明は、「タスクの数を変更」することによって、「トランザクションの応答性を変化」させている。そして、トランザクションの応答性が変化するということは、処理できるトランザクション量も変化するから、「タスクの数を変更」することは、タスクの処理量を調整するものであるといえる。
　また、引用例１記載の発明における「タスク」は、トランザクションという処理要求を処理するものであるから、本願発明の「プロセス」に相当する。
　してみると、引用例１記載の発明における「トランザクションを処理するタスク数を変更して、トランザクションの応答性を変化させる」ことは、本願発明における「プロセスの処理量を調整」することに相当する。
　そして、引用例１記載の発明における「タスク数変更判定手段」、「タスク数判定テーブル」及び「タスク数変更手段」は、これら全体で、負荷情報に基づいてプロセスの処理量を調整する手段であると見ることができ、本願発明における「処理量調整手段」とは、「現在の負荷情報格納手段に格納された負荷情報に基づいてプロセスの処理量を調整する調整手段」である点で共通する。
　
　してみると、本願発明と引用例１記載の発明は、
　
　現在の負荷情報を格納する現在の負荷情報格納手段と、
　所定の時間間隔で、負荷情報を現在の負荷情報格納手段に格納する監視手段と、
　現在の負荷情報格納手段に格納された負荷情報に基づいてプロセスの処理量を調整する調整手段と、
　を備えることを特徴とするデータ処理装置。
　
である点で一致し、以下の点で相違している。
（相違点１）
　本願発明では、「プロセスの処理量を格納するプロセス処理量格納手段」と、「クライアントからの要求に従って処理された前記プロセスの処理量を前記プロセス処理量格納手段に格納する処理手段」を有するのに対し、引用例１記載の発明では、これらに相当する構成がない点。
（相違点２）
　本願発明では、「過去平均要求量格納手段」を有するのに対し、引用例１記載の発明では、これに相当する構成がない点。
（相違点３）
　本願発明では、監視手段（要求量監視手段）が、所定の時間間隔で、現在の負荷情報格納手段に格納された負荷情報を、「過去平均要求量格納手段」に待避する機能を有しているのに対し、引用例１記載の発明では、監視手段（トランザクション監視手段）が、このような機能を有するとはされていない点。
（相違点４）
　本願発明では、調整手段（処理量調整手段）が、プロセスの処理量の調整を、「過去平均要求量格納手段」に格納された負荷情報にも基づいて行うものであるのに対し、引用例１記載の発明では、調整手段（タスク数変更判定手段、タスク数判定テーブル及びタスク数変更手段）が、プロセスの処理量の調整に、過去の負荷情報を用いるものとなっていない点。
（相違点５）
　本願発明では、負荷情報が、「プロセス処理量格納手段に格納されたプロセスごとの前記所定時間間隔内の処理量を合計して平均を取った平均要求量」であるのに対し、引用例１記載の発明では、負荷情報が、「一定時間内に発生したトランザクション数」である点。
　
３−４．当審の判断
（相違点１，５について）
　相違点１と相違点５は、負荷情報としてどのような値を用いるかに基づく相違なので、まとめて検討する。
　一般に、トランザクションの数が多いということは処理量が多いということであり、逆にトランザクションの数が少なければ処理量は少ないということであるから、トランザクションの数を計測することは処理量を計測しているといえる。してみると、引用例１記載の発明における「発生したトランザクション数」は、発生した処理量であるといえる。
　一方、本願発明における「処理されたプロセスの処理量」は、プロセスによって処理された処理量である。ここで、通常、発生した処理要求はいずれ処理されるのであるから、処理量を発生時に計測するのと、処理された時点で計測するのとで、システムの負荷を計測するという観点において格別な相違が生じるものとは認められない。してみると、どの時点で処理量を計測するかは、当業者が必要に応じて適宜選択すべき事項に過ぎない。
　また、本願発明において平均を取っていることについても、具体的にどのような平均であるのか、本願発明において何ら具体的に規定されてない以上、この点が格別のものであるとは認められない。
　そして、処理された時点で処理量を計測する際に、各プロセスごとの処理量を、処理手段がプロセス処理量格納手段に格納し、これを合計するといったことは、必然的といえる構成であって、格別のものではない。
　したがって、引用例１記載の発明において、「プロセスの処理量を格納するプロセス処理量格納手段」と、「クライアントからの要求に従って処理された前記プロセスの処理量を前記プロセス処理量格納手段に格納する処理手段」を設けること、及び、負荷情報として「一定時間内に発生したトランザクション数」に換えて、「プロセス処理量格納手段に格納されたプロセスごとの前記所定時間間隔内の処理量を合計して平均を取った平均要求量」を用いるよう構成することは、当業者が容易に想到し得たことである。
　
（相違点２，３，４について）
　相違点２〜４は、過去の負荷情報の取り扱いに基づく相違なので、まとめて検討する。
　引用例２の記載によれば、電子計算機システムの資源管理方式において、一定時間ごとに、ジョブが属するジョブグループの資源の必要量をグループ資源管理表に格納し、該グループ資源管理表に格納された現在及び過去の資源の必要量に基づいてジョブグループの資源の量を変更することが本願出願前公知である。
　ここで、上記「一定時間ごとに」は、本願発明における「所定の時間間隔で」に相当する。
　さらに、技術常識を参酌するに、「ジョブ」は、要求に従って処理を行うものであるから、本願発明の「プロセス」に相当するものである。また、「資源の必要量」は処理の負荷に応じて変化するものといえるから、負荷情報に相当し、また、ジョブグループの資源の量を変更すれば、該ジョブグループに属するジョブの処理能力が変化するから、「ジョブグループの資源の量を変更する」ことは、本願発明の「プロセスの処理量を調整」することに相当する。
　また、グループ資源管理表は、現在及び過去の負荷情報を格納するものであるから、現在の負荷情報格納手段、及び、「過去平均要求量格納手段」をあわせた構成であるといえる。なお、本願発明では現在の負荷情報格納手段と「過去平均要求量格納手段」が別々の構成となっているが、その点が格別のものとは認められない。また、本願発明において、監視手段が、現在の負荷情報格納手段に格納された負荷情報を、「過去平均要求量格納手段」に待避することは、現在の負荷情報格納手段と「過去平均要求量格納手段」を別々の構成としたことに伴う必然的なものであるから、この点も格別のものとは認められない。
　そして引用例１記載の発明と引用例２記載の発明は、いずれも計算機の負荷情報に基づく処理量の調整に係るものとして共通しているから、負荷情報に基づくプロセスの処理量の調整をより適切なものとするため、引用例１記載の発明に引用例２記載の発明を適用して、過去の負荷情報も考慮するようにすることに格別の困難性は認められない。
　してみると、引用例１記載の発明に引用例２記載の発明を適用して、現在の負荷情報格納手段に加えて「過去平均要求量格納手段」を設けること、監視手段が、所定の時間間隔で、現在の負荷情報格納手段に格納された負荷情報を、「過去平均要求量格納手段」に待避するようにすること、さらに、調整手段が、プロセスの処理量の調整を、「過去平均要求量格納手段」に格納された負荷情報にも基づいて行うようにすることは、当業者が容易に想到し得たことである。
　
　上記で検討したように、相違点１−５はいずれも格別のものではなく、これらの相違点により格別の効果が生じるものとも認められない。よって、本願補正発明は引用例１，２に記載された発明に基づいて当業者が容易に想到し得たものである。
　
　なお、請求人は審判請求書の【請求の理由】において、「引用文献２の利用履歴表を使用した方法は、ジョブの資源量のように長期的傾向を持つ場合には有効であるが、最近のオンラインシステムのように急激な変化に対応しなければならない場合には効果はない。したがって、本願発明のように、過去の一定時間の平均要求量を１つだけ保持する方式が必須となる。」といった主張をしているので、この点について検討する。本願発明では、「過去平均要求量格納手段」について、単に、「過去の平均要求量を格納する」としか規定しておらず、いくつの「過去の平均要求量」を格納するのかについて何ら規定していない。また、「要求量監視手段」についても、単に「現在平均要求量格納手段に格納された平均要求量を過去平均要求量格納手段に退避」するだけであって、待避の際に、それ以前に過去平均要求量格納手段に格納されていた平均要求量が削除されるといったことは規定されていない。したがって、本願発明には、「過去平均要求量格納手段」に、複数の「過去の平均要求量」を格納し、これに基づいてプロセスの処理量を調整するものも含まれると解される。したがって、請求人の主張は請求項の記載に基づいたものとはいえず、採用することはできない。
　また、引用例２では、実施例こそ第２図のように、時刻Ｔ（Ｎ−２），Ｔ（Ｎ−１），Ｔ（Ｎ）の３点、つまり、過去の２つの負荷情報と現在の負荷情報を参照して時刻Ｔ（Ｎ＋１）の負荷情報を予測しているが、特許請求の範囲の記載から明らかなように、過去の負荷情報が２つあることが必須なものではない。予測の手法としては２つの時点における情報からの線形予測なども例示するまでもなく周知であり、現在の負荷情報に加えて、過去の負荷情報を１つだけ用いて予測を行うことが格別のものであるとは認められない。
　
４．むすび
　以上の通りであるから、本願は、特許法第３６条第４項並びに第３６条第５項第１号、第２号及び第６項に規定する要件を満たしていない。
　また、本願発明は、引用例１及び２に記載された発明に基づいて当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることが出来ない。
　よって、結論のとおり審決する。