【事件の表示】
　特願２０１３−２７３４００「監視制御装置」拒絶査定不服審判事件〔平成２６年　４月　３日出願公開，特開２０１４−　５９９１８〕について，次のとおり審決する。
【結　論】
　本件審判の請求は，成り立たない。
【理　由】
１．出願までの経緯
　特願２０１１−２０８６９０号は，
平成２３年９月２６日を出願日とする出願であって，
これを原出願とする特許法第４４条第１項の規定による新たな特許出願（以下，「分割出願」という。）として，
平成２５年１２月２７日に本件請求に係る出願（以下，「本願」という。）が出願された。
　
２．原審の経緯
　本願は上記のように，
平成２３年９月２６日を出願日とみなされる分割出願として，
平成２５年１２月２７日に出願されたものであって，
同日付けで審査請求がなされ，
平成２６年８月１８日付けで拒絶理由通知（同年８月２６日発送）がなされ，
同年１０月１６日付けで意見書が提出されるとともに，同日付けで手続補正書が提出され，
同年１１月２０日付けで拒絶査定（同年１２月２日謄本発送）がなされたものである。
　
３．当審での経緯
　本件審判請求は，
平成２７年２月１８日付けで「原査定を取り消す。本願の発明は特許すべきものとする，との審決を求める。」との趣旨でなされたもので，
同日付けで手続補正書が提出され，
同年３月１３日付けで特許法第１６４条第３項に定める報告（前置報告）がなされ，
同年５月１日付けで上申書が提出されたものである。
　
　
４．補正の内容
（１）平成２６年１０月１６日付け手続補正
  上記平成２６年１０月１６日付けの手続補正は特許請求の範囲を以下のとおりに補正しようとするものである。
「　【請求項１】
　計算機資源の消費量を測定する測定部と，
　前記測定部の測定により前記消費量が閾値以上の値となっていることが検出されると，前記消費量の制限を行い，その後，前記消費量が前記制限された値未満であることが検出されると前記制限を緩和する制御部と
を備える監視制御装置。
　　【請求項２】
　前記制御部は，前記制限が緩和された後，前記消費量が，該制限が緩和された値以上，になったことが検出されると，再度該消費量を制限する，
請求項１に記載の監視制御装置。
　　【請求項３】
　前記緩和された後に再度制限する値は，該緩和前に制限する値と同値である請求項２に記載の監視制御装置。」
（以下，この特許請求の範囲に記載された請求項を「本件補正前の請求項」という。）
（２）平成２７年２月１８日付け手続補正
  上記平成２７年２月１８日付けの手続補正は特許請求の範囲を以下のとおりに補正しようとするものである。（下線は，補正事項を示すものとして請求人が付与したものである。）
「　【請求項１】
　計算機資源の消費量を測定する測定部と，
　前記測定部の測定により前記消費量が閾値以上の値となっていることが検出されると，前記消費量の制限を行い，その後，前記消費量が前記制限された値未満であることが検出されると
直ちに
を備える監視制御装置。
　　【請求項２】
　前記制御部は，前記制限が緩和された後，前記消費量が，該制限が緩和された値以上，になったことが検出されると，再度該消費量を制限する，
請求項１に記載の監視制御装置。
　　【請求項３】
　前記緩和された後に再度制限する値は，該緩和前に制限する値と同値である請求項２に記載の監視制御装置。」
（以下，この特許請求の範囲に記載された請求項を「本件補正後の請求項」という。）
第２．平成２７年２月１８日付けの手続補正についての補正却下の決定 
［補正却下の決定の結論］ 
　平成２７年２月１８日付けの手続補正を却下する。
［理由］ 
１．本件補正の内容
　平成２７年２月１８日付けの手続補正（以下，「本件補正」という。）は，特許請求の範囲について，上記第１．４．（１）記載の特許請求の範囲から，上記第１．４．（２）記載の特許請求の範囲に補正しようとするものであり，これは次の補正事項よりなると言える。
＜補正事項＞
　本件補正前の請求項１の「前記消費量が前記制限された値未満であることが検出されると前記制限を緩和する制御部」を，本件補正後の請求項１の「前記消費量が前記制限された値未満であることが検出されると
直ちに
２．新規事項追加禁止要件
（１）上記補正事項によって本件補正後の請求項１に記載されることになった「前記消費量が前記制限された値未満であることが検出されると
直ちに
　なお，平成２７年５月１日付け上申書において，審判請求人は『明細書段落［００３０］には，「図２（Ｂ）に示すような表データに記憶されるカウント値を用い，測定を行ない，キャップ値（あるいはキャップ値と所定の関係のある値（例えば，キャップ値の９５％の値））を下回っていることが所定の回数検出されるかどうかにより判断することができる。」と記載を致しており，また，図２（Ｂ）において，区画２のカウント値が１であると記載致しておりますので，所定の回数は１，すなわち，一回の測定により区画の資源消費量の状態を判別する実施形態を開示しております。したがって，「前記消費量の制限を行い，その後，前記消費量が前記制限された値未満であることが検出されると直ちに前記制限を緩和する」とする本願発明は，明細書段落［００３０］，図２（Ｂ）などにおいて開示された発明であると思料致します。』と主張しているので，この点について検討する。
　当初明細書等の段落【００３０】，【００３１】等には，制御部の処理として，図４のステップＳ４０２からステップＳ４０４の説明があり，「所定の時間の間，資源の消費量がキャップ値よりも小さいと判断した場合には，監視閾値を越えたのは一時的な現象であると判断される。」との記載から，キャップ値よりも資源の消費量が小さい状態であることを「所定の時間の間」続くことを確認しているものであることから，上記技術的事項のように「前記消費量が前記制限された値未満であることが検出されると
直ちに
　また，段落【００２５】には，「ステップＳ３０２の処理として，測定部１０７により，区画それぞれの資源の消費量を測定する。図３のフローチャートにおいては，ステップＳ３０３の処理として，測定の結果，監視閾値を越えている区画に対応するカウント値を増加させる。なお，区画に対応するカウント値は，例えば，図２（Ｂ）に示されるような表データとして格納することができる。区画の起動時に，区画の番号に対応するカウント値が０に初期化される。そして，区画それぞれの資源の消費量の測定の結果，監視閾値を越えていれば，カウント値を１増加させる。」と記載されており，これは，図２（Ｂ）の表が，「区画それぞれのカウント値を表データとして格納することができる」ことを示しているものである。
　そして，段落【００２７】で，「ステップＳ３０５の処理として，カウント値が所定の値を越えた区画に対してキャッピングを行なう。すなわち，図３に示すフローチャートにより，消費量が続けて監視閾値以上であることが検出されるとキャッピングが行なわれる。キャッピングの処理の具体的な内容は，図４を参照して説明する。」と記載されていることから，図２（Ｂ）の表データ内に格納されているカウント値が所定の値を越えた区画に対してキャッピングを行うものであり，図３がキャッピングを開始するまでの処理，図４がキャッピングを開始した後の処理に遷移するものであることが記載されている。つまり，図２（Ｂ）の区画２が「所定の値を越えた区画」であることも，区画２で「キャッピング」が行われるということも記載されてはおらず，図２（Ｂ）の表が，単に区画それぞれのカウント値を表データとして格納しているものであることから，審判請求人が上申書で主張しているように「キャッピングされた区画がキャップ値を下回ったことが検知されると直ちにキャッピング値の制限を緩和する」ことを示すものとは言えない。
　したがって，本願の図２（Ｂ）は，区画それぞれに記憶されるカウント値を表データとして格納されたものを示すものに過ぎず，図２（Ｂ）において，カウント値が１であるものがあったとしても，審判請求人が，上申書で主張するような，「所定の回数は１，すなわち，一回の測定により区画の資源消費量の状態を判別する実施形態を開示」しているものとはいえない。そして，当初明細書等のその他の記載を考慮しても，補正事項のような特定事項については，開示がない。
（２）以上のとおりであるから，本件補正は，特許法第１７条の２第３項の規定に違反するものである。
３．目的要件
　本件補正が，特許法第１７条の２第５項の規定を満たすものであるか否か，すなわち，本件補正が，特許法第１７条の２第５項に規定する請求項の削除，特許請求の範囲の減縮（特許法第３６条第５項の規定により請求項に記載した発明を特定するために必要な事項を限定するものであって，その補正前の当該請求項に記載された発明とその補正後の当該請求項に記載される発明の産業上の利用分野及び解決しようとする課題が同一であるものに限る。），誤記の訂正，或いは，明りょうでない記載の釈明（拒絶理由通知に係る拒絶の理由に示す事項についてするものに限る。）の何れかを目的としたものであるかについて，以下に検討する。
　上記補正事項は「前記消費量が前記制限された値未満であることが検出されると
直ちに
　したがって，本件補正は特許請求の範囲の減縮（第３６条第５項の規定により請求項に記載した発明を特定するために必要な事項を限定するものであって，その補正前の当該請求項に記載された発明とその補正後の当該請求項に記載される発明の産業上の利用分野及び解決しようとする課題が同一であるものに限る。）（以下，「限定的減縮」と記す。）に該当するものともいえるので，本件補正は，特許法第１７条の２第５項第２号に掲げられる事項を目的とするものであるとも解し得る。
４．独立特許要件
　
　そこで，以上のように，限定的減縮を目的とする補正をした本件補正後の請求項１に記載された発明（以下，「本件補正発明」という。）が特許出願の際独立して特許を受けることができるものであるか（特許法第１７条の２第６項において準用する同法第１２６条第７項の規定に適合するか）を以下に検討する。
　
＜本件補正発明＞
　
　本件補正発明は，上記平成２７年２月１８日付け手続補正書により補正された特許請求の範囲，明細書及び図面の記載からみて，その特許請求の範囲の請求項１に記載された以下のとおりのものと認める。　
「計算機資源の消費量を測定する測定部と，
　前記測定部の測定により前記消費量が閾値以上の値となっていることが検出されると，前記消費量の制限を行い，その後，前記消費量が前記制限された値未満であることが検出されると直ちに前記制限を緩和する制御部と
を備える監視制御装置。」
４−１．特許法第３６条（記載要件）について
（１）本件補正発明には，「前記消費量の制限を行い，その後，前記消費量が前記制限された値未満であることが検出されると直ちに前記制限を緩和する」と記載されている。
　ここで，「直ちに」というのは，「（１）じかに。直接に。」又は「（２）時を移さず。すぐに。じきに。即座に。」[株式会社岩波書店 広辞苑第六版]という意味のうち，（２）を意図するものと認められるが，仮に「即座に」という意味であったとすると，本願図面の【図５】のｔ２〜ｔ３の間が０の値である，あるいは，限りなく０に値が近くなっていることを含むものと認められる。
　しかしながら，そのような実施態様は本願の明細書に開示がなく，本件補正発明は発明の詳細な説明に記載されたものとは言えないものである。
　また，段落【００３３】には，「時間ｔ１からｔ２の間，図３に示すフローチャートの処理により，ある区画の資源の消費量がＴｈを越えていることが検出されたとする。すると，ｔ２から図４に示すフローチャートの処理により，キャップ値Ｃ１へのキャッピングが行なわれる。これにより，その区画の資源の消費量の上限がＣ１となる。もし，その区画が不具合により無駄に資源を消費しているとすれば，資源の消費量がＣ１となりつづける。一方，一時的に資源の消費量が増加しているのであれば，
そのうち
　さらに，段落【００４３】には，「区画１のキャッピングを緩和するために，ＣＰＵ消費量がキャップ値未満である時間の長さをＷ１分とすると・・・（中略）・・・，Ｗ１は５分より大きな時間となる。したがって，キャッピングを緩和するための，ＣＰＵ消費量がキャップ値未満である時間の長さは，５分より長くすればよいこととなる。」との記載からも，「直ちに前記制限を緩和する」のではなく，制限を緩和するために，キャップ値未満である状態が，ある程度の長さの期間続くことが必要ということが記載されているものであり，本件補正発明が当初明細書に裏付けられた発明であるとは認められない。
　したがって，本件補正後の請求項１の記載は特許法第３６条第６項第１号の規定を満たさない。
　
４−２．特許法第２９条第２項（進歩性）について
　仮に，本件補正発明が，特許法第３６条第６項第１号の規定を満たしていたとして，特許法第２９条第２項（進歩性）の要件を満たすかどうかを，次に検討する。
　
（１）引用文献１
（１−１）　引用文献１
ア　本願の出願日前に頒布または電気通信回線を通じて公衆に利用可能となり，原審の拒絶の査定の理由である上記平成２６年８月１８日付けの拒絶理由通知において引用された文献である，特開平９−８１４０１号公報（平成９年３月２８日出願公開。以下，「引用文献１」という。）には，関連する図面とともに，以下の技術的事項が記載されている。
（当審注：下線は，参考のために当審で付与したものである。）
Ａ　「【０００１】
【産業上の利用分野】本発明は，一台の実計算機システムの下で
複数台の仮想計算機（ＶＭ：Ｖirtual Ｍachine）を同時に動かすことのできる仮想計算機システムのＣＰＵスケジュール方式に関する。
Ｂ　「【０００２】
【従来の技術】仮想計算機システムの普及に伴い，その性能を向上させるために，いろいろなハードウェアによる支援機構が適用されてきた。仮想計算機システムは，ハイパバイザと呼ばれる制御プログラムを含む。ハイパバイザは，システムの主記憶，ＣＰＵ，Ｉ／Ｏ系というシステムリソースを各ＶＭに与え，各ＶＭを同時に動かすためにＣＰＵスケジュールを行う。すなわち，ハイパバイザは，そのＣＰＵスケジュールにおいて，各ＶＭの状態を管理し，それをいつ動かすか，それにどのくらいのＣＰＵサービス量を与えるかを決定する。
・・・（中略）・・・
【０００５】従来技術において，各ＶＭにサービス率を指定する機能がある。この機能は，以下のとおりである。たとえば，ＶＭ1，ＶＭ2，・・・・ＶＭN というN台（Nは１以上）の仮想計算機が同時に動作しているとしよう。その各々にサービス率Ｓ1，Ｓ2，・・・・，ＳN を指定したとする。各サービス率Ｓiは，0以上である。このサービス率Ｓ1，Ｓ2，・・・・，ＳNは，各仮想計算機ＶＭ1，ＶＭ2，・・・・ＶＭNに割り当てるCPUサービス量を表す。さらに正確に云えば，各ＶＭは，待ち状態になることなく，ＣＰＵを与えられれば，いつでも，それを使い続けることができる状態（これをReady状態という）にあるとした場合，このサービス率指定は，各ＶＭ1，ＶＭ2，・・・・ＶＭNに与えられるＣＰＵサービス量の比がＳ1，Ｓ2，・・・・，ＳNとなるようにスケジュールすることを要求するものである。
【０００６】さらに従来技術においては，リソースキャッピング（resource capping）という機能がある。これについて以下に説明する。  サービス率制御においては，各ＶＭが常にReady状態かまたは走行状態であるとき，そのサービス量の比が，指定サービス率の比になるように制御するものである。しかし，実際は，各ＶＭは，待ち状態になり得る。例えば，ＶＭ上のＯＳがＩ／Ｏ動作を要求し，その完了を待って待ち状態になる場合が，これに該当する。たとえば,今,ＶＭ1が，サービス率Ｓ1により規定されるサービス量Ａ1 に達すること無く，待ち状態になったとしよう。そうすると，本来ＶＭ1に与えられるべきＣＰＵサービスが，特に他の指定も無い場合は，他のＶＭ2，・・・・ＶＭNに割当らることになる。そうすると，その  ＶＭ2，・・・・ＶＭNの中でＣＰＵを大量に使う負荷を持つもの（例えば，ＶＭ2とする）は，指定サービス率Ｓ2によって規定されるＣＰＵサービス量Ａ2を越えてサービスされることになる。
【０００７】たとえば，リソースキャッピングの例を，２台の仮想計算機ＶＭ1，ＶＭ2について考える。各サービス量をＳ1＝60，Ｓ2＝40とする。ホスト実計算機システムでの実プロセッサ台数を２台とし，その全処理能力を200としたとき，ＶＭ1 に与えられる規定ＣＰＵサービス量Ａ1は，ＣＰＵ利用率にして２台の実プロセッサ合計で120%（すなわち１台の実プロセッサ当たり平均60%），ＶＭ2 に与えられる規定ＣＰＵサービス量Ａ2は，ＣＰＵ利用率にして２台の実プロセッサ合計で80%（すなわち１台の実プロセッサ当たり平均40%），ということになる。  しかし，もし，ＶＭ2が 待ち時間が多くて，ＣＰＵ利用率が，２台の実ＣＰＵ全体で 50% にしか達せず，ＶＭ1が常にReady状態，または，走行状態の負荷を持つとすると，本来ＶＭ2に 与えられるべき 30%  のＣＰＵ利用率が，ＶＭ1に与えられ，そのＣＰＵ利用率が 150% に達することとなる。 これは，システム全体の性能向上としては，当然の処理方式であるが，ＶＭ1 のユーザとしてはＣＰＵ利用率120%分の費用しか支払わないという契約を結んで使用したいというユーザもいる。このようなユーザに対しては，システムとして，ＶＭ1のＣＰＵ利用率を120%以下に制限する必要がある。この制限機能が，リソースキャッピングと呼ばれるものである。
【０００８】この従来のリソースキャッピングの問題点について以下に述べる。  あるＶＭのＣＰＵ利用率を 規定値  Ａ% （Ａは0より大きな値とする）以下に抑えるということは，正確に考えると，二つの意味，すなわち，局所的に抑えると云う意味と，大域的に抑えると云う意味がある。この違いを図３９，図４０，図４１を用いて説明する。図３９は，あるＶＭのある負荷の本来のＣＰＵ利用率を実時間の経過を横軸にとって表したものである。９０がそのＣＰＵ利用率の推移を表す。値Ａ（９１）（％）が目的とする制御値であるとする。この負荷は時刻T0を境として，T0までは制御値Ａより，そのＣＰＵ利用率が低く，T0から移行は制御値Ａより高いとする。局所的に抑えるということは，観測時間（T1）（例えば１時間）を各小区間（例えば1秒）に分割した場合，全ての小区間での  ＣＰＵ利用率を  Ａ% 以下に抑えるということである。したがて，この局所的リソースキャッピングを適用すると，この負荷のＣＰＵ利用率の経過は図４０に示すようになる。即ち時刻T0移行は制御値Ａで抑えられることになる。時刻T0より前では，元々，制御値Ａより低いので，そのまま低いままである。これを全体の観測時間T1で見るとこの負荷の全体のＣＰＵ利用率は，制御値Ａよりかなり低い値になってしまう。 一方，大域的に抑えるということは，
局所的にＡ％を越えることがあっても良いが，長期の観測時間全体において  ＣＰＵ利用率を  Ａ%  以下に抑えるということである。
・・・（中略）・・・
【００１０】
【発明が解決しようとする課題】本発明の目的は，あるＶＭのＣＰＵ利用率を，ユーザの指定量に抑える方式であるリソースキャッピングにおいて，短期（秒のオーダ）の実時間ではなく，長期の実時間（分または時間のオーダ）において，該ＶＭのＣＰＵ利用率を該指定量に抑えるという方式を提供することである。各短期の区間においては，該指定量を越えることが有っても良い。この方式を大域的なリソースキャッピングと呼ぶ。」
Ｃ　「【００１３】
【課題を解決するための手段】実時間において，小区間（例えば1秒）ごとに，ハイパバイザに割り込みを入れる手段，各小区間毎に，
各ＶＭのＣＰＵ使用時間を測定する手段
各ＶＭのＣＰＵ利用率の制限値を動的に指定する手段
各小区間において各ＶＭのＣＰＵ利用率を該制限値以下に制限する手段
　
Ｄ　「【００１５】
【実施例】・・・（中略）・・・
各論理プロセッサタスク制御ブロックLGPBには，論理プロセッサのリソースデータ（レジスタや，PSWなど）の他に，命令プロセッサのサービスを受けた割合を表す値（Ｕ：これをＣＰＵサービス量と呼ぶ）と，リソースキャッピングの指定により，各論理プロセッサに対して決定された該サービス量の上限値ＡとＢが含まれる。これらを制御値Ａ，Ｂと呼ぶ。
【００１６】制御値Ａは，初期制御値であり，ユーザの指定値，アクティブな論理プロセッサの台数により，ＶＭのアクティベイト時に計算され，その後，新たに，ＶＭがアクティベイトまたはディアクティベイトされない限り一定である。一方
制御量Ｂは，動的に変動する値
【００１７】この４０６の制御方法が，従来の方法と異なり，新方式を与え，本発明の主要部分を構成するものである。すなわち，各論理プロセッサのサービス量Ｕは，走行中の論理プロセッサが何らかの理由で中断されて，線４５５または線４５６が示すようにコントロールがスケジューラ４０２に移ったとき，スケジューラ４０２は，該中断された論理プロセッサのＣＰＵサービス量Ｕを計算し直す。このためにスケジューラ４０２は，サービス量計算部４０４をコールする。４０４は，中断されるまでに走行した命令プロセッサによるサービス時間を加算して，現在までのＣＰＵサービス量Ｕを該論理プロセッサについて求め，その制御ブロックLGPBに設定し直す。さらに，ある論理プロセッサが中断されて，コントロールがスケジューラ４０２に移ったとき，そのサービス量Ｕを上記のように更新した後，スケジューラ４０２は，キュー操作部４０５をコールする。キュー操作部４０５は，該制御ブロックLGPB内の現在の該ＣＰＵサービス量Ｕを該制御値Ｂと比較する。キュー操作部４０５は，このときＵ＜Ｂであれば，いまだ制限値Ｂに達していないので，該論理プロセッサタスク制御ブロックLGPBをレディキューにキューイングする。この制御ブロックLGPBの動きを表したものが線４６０であり，この動きを制御する働きが線４６５である。キュー操作部４０５は，そうでないとき，すなわち
サービス量Ｕが制御値Ｂ以上となったとき，該論理プロセッサのサービス量は制御値Ｂに達したので，該論理プロセッサをアウトサービス状態とする。
【００１８】 Ｂ＝Ａ＋（Ｂ−Ｕ）
この更新はレディーキュー４１０の全ての論理プロセッサタスク制御ブロックLGPBについて実行される。さらに，この更新は，アウトサービスキュー４２０の全ての論理プロセッサタスク制御ブロックLGPBについて実行される。さらに，この更新はウェイト・キュー４３０の全ての論理プロセッサタスク制御ブロックLGPBについても実行される。走行中の論理プロセッサは，この周期タイマ割り込み発生により，中断されて，スケジューラ４０２により，上記中断処理をされ，サービス量Ｕが更新され，さらに，更新後のサービス量Ｕと制御値Ｂとの比較により，レディーキュー４１０か，アウトサービスキュー４２０にキューイングされる。そのあと，上記の制御値Ｂの設定部４０６の処理が行われる。制御値ＡとＢは，該各区間における制御値を表すものであり，したがって，上記のＢの更新が終わった後，Ｕは０に設定される。この更新が終わった後，スケジューラ４０２は，キュー操作部４０５をコールし，アウトサービスキューの全ての論理プロセッサタスク制御ブロックLGPBをレディキュー４１０にキューイングし，それらの制御ブロックLGPBに対応する論理プロセッサを，次の該実時間の区間において，ディスパッチの対象とする。線４６１がこのデータの動きを表し，線４６６がこのキュー操作の制御の働きを表す。
【００１９】この発明の特徴は，制御値Ｂ設定部４０６の働きである。ここで，
各論理プロセッサのサービス量の上限値である制御値Ｂを区間毎に変動させることにより，長期観測実時間において，ＣＰＵサービス量がＡ以下となるように制御することができる。
Ｅ　「【００５５】図２７，２８，２９の説明：  このようにして，論理プロセッサが実の命令プロセッサ上で走行させられる。走行中の論理プロセッサは，いろいろな要因で中断される。そのひとつは，ホストの割込みである。たとえば，ホストのクロック・コンパレータの割込みや，ホストのCPUタイマの割込みがそうである。ホスト・クロック・コンパレータ割込みは，図１８に示す，ホスト・クロック・コンパレータ・レジスタ ３０２の値が，図１５に示すシステム共通レジスタ６００の現在時刻TODの値を越えたときに発生する。これは，従来通りである。ホストＣＰＵタイマの割込みは，図１８に示すホストＣＰＵタイマ・レジスタ３００の値が負になったときに発生する。これも従来通りである。図２１に示すスケジューラタイマ同期処理により，全命令プロセッサで同時にスケジューラタイマ用のホスト・クロック・コンパレータの割込みが発生する。また，図２６に示す，ディスパッチ処理でホストＣＰＵタイマ・レジスタ３００に残りのタイム・スライスTS(p,q)（論理プロセッサ(p,q)用のタイムスライス）を設定したことにより（７１３ー３），該当の論理プロセッサが，そのタイム・スライスを使い切るとホストＣＰＵタイマ割込みが発生する。これを，タイムスライスエンドの割込みという。これらの制御は，従来通りである。これらのホスト割込み処理の後，図２７，２８，２９に示す論理プロセッサの中断処理が呼ばれる。ここでは，先ず，走行中であった論理プロセッサの制御ブロックLGPBのアドレスをレジスタ３０７から求める。今それをLGPB_Rとする（８００ー２）。このLGPB_Rから現ＶＭ番号p,論理プロセッサ番号q  を求める（８００ー３）。これは，LGPB_Rの場所１１２から読み出してくればよい（図７参照）。次に，LGPB_Rの統計データ不当インディケータsinv(p,q)=1であるかを判断する。そうである場合は，該LGPB_R内の種々の統計データを更新する必要があるので，８００ー４へ行く。そうでない場合は，すでに更新済みであるので，ただちにリターンする。次に，該
論理プロセッサのＣＰＵ消費時間を計算する
u = (TS_R) - (TS_R')
によって求められる（８００ー６）。このuμsecは，最後のディスパッチから，最初の中断までの論理プロセッサの消費したＣＰＵ時間である。次に，該論理プロセッサ(p,q)の累計のＣＰＵ消費時間を計算する。これは，以下の式による。
【００５６】すなわち，LGPB_Rの場所１１４ー３ーＲの値C(p,q)_Rを読み出す。これは，該論理プロセッサの区間におけるＣＰＵ消費時間の累計を表す。そこで，
C(p,q)_R = C(p,q)_R + u
とし，更新されたC(p,q)_Rの値を該LGPB_Rの１１４ー３ーＲに格納する（８００ー７）。次に，該論理プロセッサの区間におけるＣＰＵ利用率U(p,q)_R (%) を求める。システムデータ領域５００から区間の長さΔtμsecを得る。さらに，８００ー７で更新したC(p,q)_R（これは，区間における該論理プロセッサのＣＰＵ消費時間）を用いて，
U(p,q)_R = (C(p,q)_R/Δt)*100   (%)
これを，
該論理プロセッサの区間ＣＰＵ利用率として，該LGPB_Rの１１４ー６ーＲに格納する（８００ー８）。次に，この区間ＣＰＵ利用率が制御値を越えるかどうかを判断する。
(U(p,q)_R)  (B(p,q)_R)
かどうかを判断する（８００ー９）。もし，そうであるならば，まだ，現区間においては，制御値に達していないので，再びレディキューにキューイングしてディスパッチするために８００ー１０へ行く。もし，そうでないときは，すでに制御値に達したのでアウトサービスキューへキューイングするために８００ー１２へ行く。先ず，８００ー１０から説明する。ここでは，区間における該論理プロセッサ(p,q)のＣＰＵ充足度(D(p,q)_R (%))を計算する。」
　
イ　引用発明
　
　してみると，引用文献１には，「計算機の性能を向上させるために計算機資源の割当て・キャッピングをスケジュールする（上記Ｂより）」ことを目的とした，次の発明（引用発明）が記載されている。
「各ＶＭのＣＰＵ使用時間を測定する手段（上記Ｃより）と，
　該ＣＰＵ使用時間と制限値とを比較し，制限値を越えていれば，制限をかけて，各ＶＭのＣＰＵ使用率を制限値以下にする手段（上記Ｃより）と，
　制限値を変動させる手段（上記Ｄより）と
を備えた仮想計算機システム。（上記Ａより）」
（１−２）引用文献２
ア　本願の出願日前に頒布または電気通信回線を通じて公衆に利用可能となり，原審の拒絶の査定の理由である上記平成２６年８月１８日付けの拒絶理由通知において引用された文献である，特表２００５−５１６３０３号公報（平成１７年６月２日公表。以下，「引用文献２」という。）には，関連する図面とともに，以下の技術的事項が記載されている。
（当審注：下線は，参考のために当審で付与したものである。）
Ｆ　「【発明が解決しようとする課題】
【０００４】
　本発明の目的は，実行の処理集約型(processing-intensive)スレッドによって引き起こされる性能の問題を軽減するのに用いられ，請求項1，10および11それぞれの前提条件による方法，マルチプログラミングコンピュータシステムおよびコンピュータプログラムを提供することである。
【課題を解決するための手段】
【０００５】
　従って，本発明は，
優先スケジューリングを備えたマルチプログラミングコンピュータシステムにおける優先レベルを設定する
それらの測定された相対的使用量が所定のエスカレーション閾値を上回る場合，１またはそれ以上の実行のスレッドの優先レベルが低くされる
・・・（中略）・・・
【０００７】
  好ましくは，エスカレーション時間の間，その処理の前記スレッドによる全相対的使用量がエスカレーション閾値を上回る場合，１つの処理に属する実行の全スレッドの優先レベルは低くされる。
【０００８】
  従って，マルチスレッドされたコードを実行可能なコンピュータシステムにおいて，他より極めて多くの実行のスレッドを備えた処理は検出を逃れられない。ユーザは，一般的に処理が遅いことに気付くだけである。それらによって用いられた全処理手続き容量が閾値を上回る場合に，処理の実行の全スレッドの優先度を低くさせることは，他の処理をより応答しやすくさせる。
【０００９】
  好ましくは，少なくとも１つのスレッドの優先レベルは，可能な値(possible value)の範囲内で最低レベルまで低くされる。
【００１０】
  従って，効果が即座に現れる。いくつかの時間に渡って優先度を除々に減らす必要はない。エスカレーション時間の使用と相まって，前記方法は安定しており，さらにユーザ側のもどかしさを避けるのに充分な応答性がある。
【００１１】
  好ましくは，試験時間(probation time period)の間，相対的使用量が試験閾値より低い場合，低くされた優先レベルは標準的な優先レベルに戻される。」
Ｇ　「【００２５】
　マルチスレッド(multithread)されたシステムでは，各処理は，１またはそれ以上の実行のスレッドを有することができる。図２の例では，図２の前記第１処理13は，第１スレッド15および第２スレッド16を有する。前記第２処理14もまた，２つのスレッド17を有する。実行のスレッドは，CPU2上での実行に対してスケジュール化されたもの(entity)である。各スレッド15，16，17は，その進捗を示すプログラムカウンタと，その最新の作業変数(working variables)を保持するレジスタと，スタックとを有する。
前記第１処理13の実行のスレッド15，16は，その処理13のアドレス空間，オープンファイルおよび他のリソースを共有する。
Ｈ　「【００３８】
　図３を参照すると，前記第１処理13による前記CPU2の前記相対的使用量が示されている。グラフは，本発明による方法を用いるシステムから得られる。前記相対的使用量は，処理時間の割合として表現されるが，おおむね演算数のようないくつかの他の基準(measure)が用いられる。この例では，前記エスカレーション閾値が80%に設定されている。時間T0点で，前記第１処理13による前記プロセッサの前記相対的使用量は，前記エスカレーション閾値を上回る。実際，それは実質的に100%となる。時間間隔ΔT1の間中，前記相対的使用量が80%より上のままであるので，前記第１処理13は，より低い処理優先度クラスへ移動される。前記’CPU-hungry’スレッドを備えている前記処理13の両方のスレッド15，16の優先レベルもまた，その結果として低くされる。結果として，前記相対的使用量は，甚だしい妨害なく，前記第２処理が進行するのに充分な95%近傍まで低くされる。
【００３９】
　前記時間間隔ΔT1の長さは，前記コンピュータシステムのユーザの忍耐量に大きく依存する。図３の前記グラフから明らかなように，時間間隔ΔT1の間，他の処理が実行を効果的に妨げられる可能性がある。勿論，前記第１処理13の前記優先レベルが低くされた後，’CPU-hungry’スレッドの優先レベルが前記第２処理14の全てのスレッドのそれ(優先レベル)より依然として高い場合，長さΔT1の他の時間間隔が経過するまでは何も生じない。このことは受け入れられないであろう。
【００４０】
　従って，優先レベルは，T1における許容値の範囲内で最低レベルまで低くされる。例示のシステムでは，前記処理優先度クラスは，最低限の可能なレベルまで下げられる。しかしながら，本発明の範囲内で，処理の全てのスレッドのスレッド優先度クラスは，最低限の可能なレベルまで低くされる。その後，前記第１処理13の両方のスレッド15,16はレベルP0になる。
【００４１】
　多くの場合，処理またはスレッドは，一時的にのみ，過度にプロセッサ容量を消費する。例示的な状況は，２人のユーザが１台のマシン上でワードプロセッシングアプリケーションを実行しているものである。２つの処理のそれぞれが同一の基本優先レベルにある。１人のユーザがマクロの実行を決定するかもしれない。この時点で，ユーザの処理は，他の処理が影響を受けるほど大きなプロセッサ容量を消費するかもしれない。従って，マクロを実行する処理の前記優先レベルが低くされる。それより後の時点で，他のユーザがマクロを実行する場合，他のユーザの処理の前記優先レベルは低くされる。いずれの処理も，今度は最低優先レベルとなる。一方の処理が再び優勢になり始めると，何の救済措置も残されていない。
【００４２】
　前記相対的使用量が試験閾値より低い場合，低くされた優先レベルが標準的な優先レベルに戻されるため，この好ましくない状況が回避される。図３では，前記試験閾値は，40%に設定される。
【００４３】
　勿論，前記CPU使用量が，前記試験閾値を一時的に割ることもあり得る。前記優先レベルが標準的な優先レベルへすぐに戻される場合，そのとき基本優先レベルがほぼ毎秒変化する極めて不安定なシステムになってしまう。
【００４４】
　このことは，
所定の長さΔT2の試験時間の間，前記相対的使用量が試験閾値より低くされる場合に，優先レベルを標準的な優先レベルへ戻す
（２）　対比
　本件補正発明と引用発明とを対比する。
（２−１）
　引用文献１における上記Ｅの「論理プロセッサのＣＰＵ消費時間を計算する」及び「該論理プロセッサの区間ＣＰＵ利用率として，該LGPB_Rの１１４ー６ーＲに格納する（８００ー８）。次に，この区間ＣＰＵ利用率が制御値を越えるかどうかを判断する。」との記載等を踏まえると，引用発明では，ＣＰＵ消費時間を計算して，ＣＰＵ利用率を計算している。その際，当然ＣＰＵの消費量に相当する値を測定していることは明らかなので，引用発明における「ＣＰＵ使用時間を測定」することは，本件補正発明の「計算機資源の消費量を測定する測定部」に相当する。                  １
（２−２）
　引用発明の「該ＣＰＵ使用時間と制限値とを比較し，制限値を越えていれば，制限をかけて，各ＶＭのＣＰＵ使用率を制限値以下にする手段」は，ＣＰＵ使用時間が制限値以上の値となっていることを検出しているといえるので，本件補正発明の「前記測定部の測定により前記消費量が閾値以上の値となっていることが検出されると，前記消費量の制限を行い」に相当する。
（２−３）
　引用発明の「制限値を変動させる」ことと本件補正発明の「前記制限を緩和する」こととは，制限値を変動させるものである点で共通する。
（２−４）
　よって，本件補正発明は，下記の一致点で引用発明と一致し，下記の相違点で引用発明と相違する。
＜一致点＞
「計算機資源の消費量を測定する測定部と，
　前記測定部の測定により前記消費量が閾値以上の値となっていることが検出されると，前記消費量の制限を行い，その後，制限値を変動させる制御部と
を備える監視制御装置。」
＜相違点＞　　
　本件補正発明では，「消費量の制限を行い」，「その後，前記消費量が前記制限された値未満であることが検出されると直ちに前記制限を緩和する」のに対して，引用発明では，制限されている状態から，制限値を変動させるものの，「制限された値未満であることが検出されると直ちに前記制限を緩和する」ことに言及がない点。
　
（３）  当審の判断
　
　一般的に，処理手段のパフォーマンスはより高い方が望ましいことは，説示する迄も無い技術常識であるから，何らかの原因でパフォーマンスを抑制した際に，当該原因がなくなれば可能な限り早めに元のパフォーマンスに復帰させることは，当業者ならずとも当然に想到する事項にほかならない（例えば，引用文献１では，段落【０００８】の「局所的に抑えるということは，観測時間（T1）（例えば１時間）を各小区間（例えば1秒）に分割した場合，全ての小区間での  ＣＰＵ利用率を  Ａ% 以下に抑えるということである。」との記載から，制限開始時刻（T0）から，観測時間（T1）の間はＣＰＵ利用率を過ぎるとＣＰＵ利用率を抑制しないようにすることが読みとれ，引用文献２に記載のものにおいては，段落【０００７】〜【００１１】に，閾値を上回ると，優先レベルを低くし，所定の期間，相対的使用量が試験閾値よりも低くくなった場合に，低くされた優先レベルを標準的な優先レベルに戻すことが記載されている。）。
　してみると，引用発明においても「その後，前記消費量が前記制限された値未満であることが検出されると直ちに前記制限を緩和する」ものとすること，すなわち上記相違点に係る事項を採用することは，当業者であれば，当然の如く採用する設計的事項に過ぎないものである。
　したがって，本件補正発明の構成は当業者が引用発明から容易に想到し得るものであり，その作用効果も当業者が当然に予測し得る程度のものであって格別顕著なものでもない。
　したがって，本件補正発明は，引用発明及び引用文献２に記載の発明から，当業者が容易に想到しうるものである。
４−３．独立特許要件のまとめ
　したがって，本件補正後の特許請求の範囲の記載は，特許法第３６条第６項第１号の規定を満たしておらず，しかも，本件補正発明は特許法第２９条第２項の規定により特許を受けることができないものであるから，本件補正発明は，独立して特許することができないものである。
５．むすび
 
　上記２．のとおり，本件補正は，特許法第１７条の２第３項の規定に違反するので，同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　また，上記４．のとおり，本件補正は，特許法第１７条の２第６項において準用する同法第１２６条第７項の規定に違反するので，同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　よって，上記補正却下の決定の結論のとおり決定する。
第３．本願発明について
 
１．本願発明の認定 
　平成２７年２月１８日付けの手続補正は上記のとおり却下されたので，本件補正後の請求項１に対応する本件補正前の請求項に係る発明（以下，「本願発明」という。）は，平成２６年１０月１６日付けの手続補正により補正された特許請求の範囲の請求項１に記載された事項により特定される，以下のとおりのものである。
 
「計算機資源の消費量を測定する測定部と，
　前記測定部の測定により前記消費量が閾値以上の値となっていることが検出されると，前記消費量の制限を行い，その後，前記消費量が前記制限された値未満であることが検出されると前記制限を緩和する制御部と
を備える監視制御装置。」
２．引用文献１，２に記載されている技術的事項及び引用発明の認定
　引用文献１，２の記載事項及び引用発明は，上記「第２．平成２７年２月１８日付けの手続補正についての補正却下の決定」の「４．独立特許要件」の「（１）　引用文献」に記載したとおりである。
３．対比及び当審の判断
　本願発明は，前記「第２　平成２７年２月１８日付けの手続補正についての補正の却下の決定」の「４−２．特許法第２９条第２項（進歩性）について」で検討した本件補正発明から，「直ちに」との限定を削除したものである。
　
　そうすると，本願発明の構成要件を全て含み，さらに特定の構成要件に限定要件を付加したものに相当する本件補正発明が，前記「第２　平成２７年２月１８日付けの手続補正についての補正の却下の決定」の「４−２．特許法第２９条第２項（進歩性）について」の「（１）引用文献」〜「（３）当審の判断」に記載したとおり，引用発明，引用文献２に記載のごとき周知慣用技術に基づいて，当業者が容易に発明をすることができたものであるから，本願発明も，同様の理由により，当該引用発明及び周知慣用技術に基づいて，当業者が容易に発明をすることができたものである。
　そして，本願発明の奏する作用効果は，上記引用発明，引用文献２に記載の技術の奏する作用効果から予測される範囲内のものにすぎず，格別顕著なものということはできない。
４．むすび 
　以上のとおり，本願の請求項１に係る発明は，特許法第２９条第２項の規定により特許を受けることができないものであるから，その余の請求項に係る発明について検討するまでもなく，本願は拒絶すべきものである。 
　よって，結論のとおり審決する。