• ポートフォリオ機能


ポートフォリオを新規に作成して保存
既存のポートフォリオに追加保存

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 特許、登録しない。 G06F
審判 査定不服 特17条の2、3項新規事項追加の補正 特許、登録しない。 G06F
審判 査定不服 特174条1項 特許、登録しない。 G06F
審判 査定不服 5項独立特許用件 特許、登録しない。 G06F
管理番号 1304368
審判番号 不服2015-3127  
総通号数 190 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2015-10-30 
種別 拒絶査定不服の審決 
審判請求日 2015-02-18 
確定日 2015-08-13 
事件の表示 特願2013-273400「監視制御装置」拒絶査定不服審判事件〔平成26年 4月 3日出願公開,特開2014- 59918〕について,次のとおり審決する。 
結論 本件審判の請求は,成り立たない。 
理由 1.出願までの経緯
特願2011-208690号は,
平成23年9月26日を出願日とする出願であって,
これを原出願とする特許法第44条第1項の規定による新たな特許出願(以下,「分割出願」という。)として,
平成25年12月27日に本件請求に係る出願(以下,「本願」という。)が出願された。

2.原審の経緯
本願は上記のように,
平成23年9月26日を出願日とみなされる分割出願として,
平成25年12月27日に出願されたものであって,
同日付けで審査請求がなされ,
平成26年8月18日付けで拒絶理由通知(同年8月26日発送)がなされ,
同年10月16日付けで意見書が提出されるとともに,同日付けで手続補正書が提出され,
同年11月20日付けで拒絶査定(同年12月2日謄本発送)がなされたものである。

3.当審での経緯
本件審判請求は,
平成27年2月18日付けで「原査定を取り消す。本願の発明は特許すべきものとする,との審決を求める。」との趣旨でなされたもので,
同日付けで手続補正書が提出され,
同年3月13日付けで特許法第164条第3項に定める報告(前置報告)がなされ,
同年5月1日付けで上申書が提出されたものである。


4.補正の内容

(1)平成26年10月16日付け手続補正
上記平成26年10月16日付けの手続補正は特許請求の範囲を以下のとおりに補正しようとするものである。

「 【請求項1】
計算機資源の消費量を測定する測定部と,
前記測定部の測定により前記消費量が閾値以上の値となっていることが検出されると,前記消費量の制限を行い,その後,前記消費量が前記制限された値未満であることが検出されると前記制限を緩和する制御部と
を備える監視制御装置。
【請求項2】
前記制御部は,前記制限が緩和された後,前記消費量が,該制限が緩和された値以上,になったことが検出されると,再度該消費量を制限する,
請求項1に記載の監視制御装置。
【請求項3】
前記緩和された後に再度制限する値は,該緩和前に制限する値と同値である請求項2に記載の監視制御装置。」
(以下,この特許請求の範囲に記載された請求項を「本件補正前の請求項」という。)

(2)平成27年2月18日付け手続補正
上記平成27年2月18日付けの手続補正は特許請求の範囲を以下のとおりに補正しようとするものである。(下線は,補正事項を示すものとして請求人が付与したものである。)

「 【請求項1】
計算機資源の消費量を測定する測定部と,
前記測定部の測定により前記消費量が閾値以上の値となっていることが検出されると,前記消費量の制限を行い,その後,前記消費量が前記制限された値未満であることが検出されると直ちに前記制限を緩和する制御部と
を備える監視制御装置。
【請求項2】
前記制御部は,前記制限が緩和された後,前記消費量が,該制限が緩和された値以上,になったことが検出されると,再度該消費量を制限する,
請求項1に記載の監視制御装置。
【請求項3】
前記緩和された後に再度制限する値は,該緩和前に制限する値と同値である請求項2に記載の監視制御装置。」
(以下,この特許請求の範囲に記載された請求項を「本件補正後の請求項」という。)


第2.平成27年2月18日付けの手続補正についての補正却下の決定

[補正却下の決定の結論]

平成27年2月18日付けの手続補正を却下する。

[理由]

1.本件補正の内容

平成27年2月18日付けの手続補正(以下,「本件補正」という。)は,特許請求の範囲について,上記第1.4.(1)記載の特許請求の範囲から,上記第1.4.(2)記載の特許請求の範囲に補正しようとするものであり,これは次の補正事項よりなると言える。

<補正事項>
本件補正前の請求項1の「前記消費量が前記制限された値未満であることが検出されると前記制限を緩和する制御部」を,本件補正後の請求項1の「前記消費量が前記制限された値未満であることが検出されると直ちに前記制限を緩和する制御部」とする補正。

2.新規事項追加禁止要件

(1)上記補正事項によって本件補正後の請求項1に記載されることになった「前記消費量が前記制限された値未満であることが検出されると直ちに前記制限を緩和する制御部」という技術的事項は,願書に最初に添付した明細書,特許請求の範囲又は図面(以下,「当初明細書等」と記す。)には記載されておらず,また当初明細書等の記載からみて自明な事項でもない。

なお,平成27年5月1日付け上申書において,審判請求人は『明細書段落[0030]には,「図2(B)に示すような表データに記憶されるカウント値を用い,測定を行ない,キャップ値(あるいはキャップ値と所定の関係のある値(例えば,キャップ値の95%の値))を下回っていることが所定の回数検出されるかどうかにより判断することができる。」と記載を致しており,また,図2(B)において,区画2のカウント値が1であると記載致しておりますので,所定の回数は1,すなわち,一回の測定により区画の資源消費量の状態を判別する実施形態を開示しております。したがって,「前記消費量の制限を行い,その後,前記消費量が前記制限された値未満であることが検出されると直ちに前記制限を緩和する」とする本願発明は,明細書段落[0030],図2(B)などにおいて開示された発明であると思料致します。』と主張しているので,この点について検討する。

当初明細書等の段落【0030】,【0031】等には,制御部の処理として,図4のステップS402からステップS404の説明があり,「所定の時間の間,資源の消費量がキャップ値よりも小さいと判断した場合には,監視閾値を越えたのは一時的な現象であると判断される。」との記載から,キャップ値よりも資源の消費量が小さい状態であることを「所定の時間の間」続くことを確認しているものであることから,上記技術的事項のように「前記消費量が前記制限された値未満であることが検出されると直ちに前記制限を緩和する」ことは記載されておらず,これらの記載から,上記技術的事項が明らかであるともいえない。
また,段落【0025】には,「ステップS302の処理として,測定部107により,区画それぞれの資源の消費量を測定する。図3のフローチャートにおいては,ステップS303の処理として,測定の結果,監視閾値を越えている区画に対応するカウント値を増加させる。なお,区画に対応するカウント値は,例えば,図2(B)に示されるような表データとして格納することができる。区画の起動時に,区画の番号に対応するカウント値が0に初期化される。そして,区画それぞれの資源の消費量の測定の結果,監視閾値を越えていれば,カウント値を1増加させる。」と記載されており,これは,図2(B)の表が,「区画それぞれのカウント値を表データとして格納することができる」ことを示しているものである。
そして,段落【0027】で,「ステップS305の処理として,カウント値が所定の値を越えた区画に対してキャッピングを行なう。すなわち,図3に示すフローチャートにより,消費量が続けて監視閾値以上であることが検出されるとキャッピングが行なわれる。キャッピングの処理の具体的な内容は,図4を参照して説明する。」と記載されていることから,図2(B)の表データ内に格納されているカウント値が所定の値を越えた区画に対してキャッピングを行うものであり,図3がキャッピングを開始するまでの処理,図4がキャッピングを開始した後の処理に遷移するものであることが記載されている。つまり,図2(B)の区画_(2)が「所定の値を越えた区画」であることも,区画_(2)で「キャッピング」が行われるということも記載されてはおらず,図2(B)の表が,単に区画それぞれのカウント値を表データとして格納しているものであることから,審判請求人が上申書で主張しているように「キャッピングされた区画がキャップ値を下回ったことが検知されると直ちにキャッピング値の制限を緩和する」ことを示すものとは言えない。

したがって,本願の図2(B)は,区画それぞれに記憶されるカウント値を表データとして格納されたものを示すものに過ぎず,図2(B)において,カウント値が1であるものがあったとしても,審判請求人が,上申書で主張するような,「所定の回数は1,すなわち,一回の測定により区画の資源消費量の状態を判別する実施形態を開示」しているものとはいえない。そして,当初明細書等のその他の記載を考慮しても,補正事項のような特定事項については,開示がない。

(2)以上のとおりであるから,本件補正は,特許法第17条の2第3項の規定に違反するものである。

3.目的要件

本件補正が,特許法第17条の2第5項の規定を満たすものであるか否か,すなわち,本件補正が,特許法第17条の2第5項に規定する請求項の削除,特許請求の範囲の減縮(特許法第36条第5項の規定により請求項に記載した発明を特定するために必要な事項を限定するものであって,その補正前の当該請求項に記載された発明とその補正後の当該請求項に記載される発明の産業上の利用分野及び解決しようとする課題が同一であるものに限る。),誤記の訂正,或いは,明りょうでない記載の釈明(拒絶理由通知に係る拒絶の理由に示す事項についてするものに限る。)の何れかを目的としたものであるかについて,以下に検討する。

上記補正事項は「前記消費量が前記制限された値未満であることが検出されると直ちに前記制限を緩和する制御部」の下線部分の記載を新たに追加するものであり,これによって産業上の利用分野や解決しようとする課題が変更されるものではない。
したがって,本件補正は特許請求の範囲の減縮(第36条第5項の規定により請求項に記載した発明を特定するために必要な事項を限定するものであって,その補正前の当該請求項に記載された発明とその補正後の当該請求項に記載される発明の産業上の利用分野及び解決しようとする課題が同一であるものに限る。)(以下,「限定的減縮」と記す。)に該当するものともいえるので,本件補正は,特許法第17条の2第5項第2号に掲げられる事項を目的とするものであるとも解し得る。

4.独立特許要件

そこで,以上のように,限定的減縮を目的とする補正をした本件補正後の請求項1に記載された発明(以下,「本件補正発明」という。)が特許出願の際独立して特許を受けることができるものであるか(特許法第17条の2第6項において準用する同法第126条第7項の規定に適合するか)を以下に検討する。

<本件補正発明>

本件補正発明は,上記平成27年2月18日付け手続補正書により補正された特許請求の範囲,明細書及び図面の記載からみて,その特許請求の範囲の請求項1に記載された以下のとおりのものと認める。

「計算機資源の消費量を測定する測定部と,
前記測定部の測定により前記消費量が閾値以上の値となっていることが検出されると,前記消費量の制限を行い,その後,前記消費量が前記制限された値未満であることが検出されると直ちに前記制限を緩和する制御部と
を備える監視制御装置。」

4-1.特許法第36条(記載要件)について
(1)本件補正発明には,「前記消費量の制限を行い,その後,前記消費量が前記制限された値未満であることが検出されると直ちに前記制限を緩和する」と記載されている。
ここで,「直ちに」というのは,「(1)じかに。直接に。」又は「(2)時を移さず。すぐに。じきに。即座に。」[株式会社岩波書店 広辞苑第六版]という意味のうち,(2)を意図するものと認められるが,仮に「即座に」という意味であったとすると,本願図面の【図5】のt2?t3の間が0の値である,あるいは,限りなく0に値が近くなっていることを含むものと認められる。
しかしながら,そのような実施態様は本願の明細書に開示がなく,本件補正発明は発明の詳細な説明に記載されたものとは言えないものである。
また,段落【0033】には,「時間t1からt2の間,図3に示すフローチャートの処理により,ある区画の資源の消費量がThを越えていることが検出されたとする。すると,t2から図4に示すフローチャートの処理により,キャップ値C1へのキャッピングが行なわれる。これにより,その区画の資源の消費量の上限がC1となる。もし,その区画が不具合により無駄に資源を消費しているとすれば,資源の消費量がC1となりつづける。一方,一時的に資源の消費量が増加しているのであれば,そのうち,資源の消費量がキャップ値C1を下回ることになる。すなわち,時間t2からt3の間において,資源の消費量がC1を下回る。そそこで,時刻t3において,キャップ値をC2へ緩和する。(下線は,当審で参考のために付与したものである。)」と記載されており,制限の緩和がなされる時期が「そのうち」であることは読み取れるが,「直ちに」であるとは読み取れない。
さらに,段落【0043】には,「区画_(1)のキャッピングを緩和するために,CPU消費量がキャップ値未満である時間の長さをW_(1)分とすると・・・(中略)・・・,W_(1)は5分より大きな時間となる。したがって,キャッピングを緩和するための,CPU消費量がキャップ値未満である時間の長さは,5分より長くすればよいこととなる。」との記載からも,「直ちに前記制限を緩和する」のではなく,制限を緩和するために,キャップ値未満である状態が,ある程度の長さの期間続くことが必要ということが記載されているものであり,本件補正発明が当初明細書に裏付けられた発明であるとは認められない。
したがって,本件補正後の請求項1の記載は特許法第36条第6項第1号の規定を満たさない。

4-2.特許法第29条第2項(進歩性)について
仮に,本件補正発明が,特許法第36条第6項第1号の規定を満たしていたとして,特許法第29条第2項(進歩性)の要件を満たすかどうかを,次に検討する。

(1)引用文献1
(1-1) 引用文献1

ア 本願の出願日前に頒布または電気通信回線を通じて公衆に利用可能となり,原審の拒絶の査定の理由である上記平成26年8月18日付けの拒絶理由通知において引用された文献である,特開平9-81401号公報(平成9年3月28日出願公開。以下,「引用文献1」という。)には,関連する図面とともに,以下の技術的事項が記載されている。
(当審注:下線は,参考のために当審で付与したものである。)

A 「【0001】
【産業上の利用分野】本発明は,一台の実計算機システムの下で複数台の仮想計算機(VM:Virtual Machine)を同時に動かすことのできる仮想計算機システムのCPUスケジュール方式に関する。各仮想計算機は,該実計算機と同等の機能を持ち,実計算機上で動くのと同じOSを動作させることができる。この意味で,仮想計算機システムは一台の実計算機システムの下で複数台のOSを同時に動かすことのできるシステムであるとも云える。仮想計算機システムを動かす実計算機システムをホスト実計算機システムと呼ぶ。CPUスケジュール方式とは,同時に動作している各VMに,いつ,どの程度のCPUサービス量を与えるかということを決定する方式である。」

B 「【0002】
【従来の技術】仮想計算機システムの普及に伴い,その性能を向上させるために,いろいろなハードウェアによる支援機構が適用されてきた。仮想計算機システムは,ハイパバイザと呼ばれる制御プログラムを含む。ハイパバイザは,システムの主記憶,CPU,I/O系というシステムリソースを各VMに与え,各VMを同時に動かすためにCPUスケジュールを行う。すなわち,ハイパバイザは,そのCPUスケジュールにおいて,各VMの状態を管理し,それをいつ動かすか,それにどのくらいのCPUサービス量を与えるかを決定する。
・・・(中略)・・・
【0005】従来技術において,各VMにサービス率を指定する機能がある。この機能は,以下のとおりである。たとえば,VM1,VM2,・・・・VMN というN台(Nは1以上)の仮想計算機が同時に動作しているとしよう。その各々にサービス率S1,S2,・・・・,SN を指定したとする。各サービス率Siは,0以上である。このサービス率S1,S2,・・・・,SNは,各仮想計算機VM1,VM2,・・・・VMNに割り当てるCPUサービス量を表す。さらに正確に云えば,各VMは,待ち状態になることなく,CPUを与えられれば,いつでも,それを使い続けることができる状態(これをReady状態という)にあるとした場合,このサービス率指定は,各VM1,VM2,・・・・VMNに与えられるCPUサービス量の比がS1,S2,・・・・,SNとなるようにスケジュールすることを要求するものである。
【0006】さらに従来技術においては,リソースキャッピング(resource capping)という機能がある。これについて以下に説明する。 サービス率制御においては,各VMが常にReady状態かまたは走行状態であるとき,そのサービス量の比が,指定サービス率の比になるように制御するものである。しかし,実際は,各VMは,待ち状態になり得る。例えば,VM上のOSがI/O動作を要求し,その完了を待って待ち状態になる場合が,これに該当する。たとえば,今,VM1が,サービス率S1により規定されるサービス量A1 に達すること無く,待ち状態になったとしよう。そうすると,本来VM1に与えられるべきCPUサービスが,特に他の指定も無い場合は,他のVM2,・・・・VMNに割当らることになる。そうすると,その VM2,・・・・VMNの中でCPUを大量に使う負荷を持つもの(例えば,VM2とする)は,指定サービス率S2によって規定されるCPUサービス量A2を越えてサービスされることになる。
【0007】たとえば,リソースキャッピングの例を,2台の仮想計算機VM1,VM2について考える。各サービス量をS1=60,S2=40とする。ホスト実計算機システムでの実プロセッサ台数を2台とし,その全処理能力を200としたとき,VM1 に与えられる規定CPUサービス量A1は,CPU利用率にして2台の実プロセッサ合計で120%(すなわち1台の実プロセッサ当たり平均60%),VM2 に与えられる規定CPUサービス量A2は,CPU利用率にして2台の実プロセッサ合計で80%(すなわち1台の実プロセッサ当たり平均40%),ということになる。 しかし,もし,VM2が 待ち時間が多くて,CPU利用率が,2台の実CPU全体で 50% にしか達せず,VM1が常にReady状態,または,走行状態の負荷を持つとすると,本来VM2に 与えられるべき 30% のCPU利用率が,VM1に与えられ,そのCPU利用率が 150% に達することとなる。 これは,システム全体の性能向上としては,当然の処理方式であるが,VM1 のユーザとしてはCPU利用率120%分の費用しか支払わないという契約を結んで使用したいというユーザもいる。このようなユーザに対しては,システムとして,VM1のCPU利用率を120%以下に制限する必要がある。この制限機能が,リソースキャッピングと呼ばれるものである。
【0008】この従来のリソースキャッピングの問題点について以下に述べる。 あるVMのCPU利用率を 規定値 A% (Aは0より大きな値とする)以下に抑えるということは,正確に考えると,二つの意味,すなわち,局所的に抑えると云う意味と,大域的に抑えると云う意味がある。この違いを図39,図40,図41を用いて説明する。図39は,あるVMのある負荷の本来のCPU利用率を実時間の経過を横軸にとって表したものである。90がそのCPU利用率の推移を表す。値A(91)(%)が目的とする制御値であるとする。この負荷は時刻T0を境として,T0までは制御値Aより,そのCPU利用率が低く,T0から移行は制御値Aより高いとする。局所的に抑えるということは,観測時間(T1)(例えば1時間)を各小区間(例えば1秒)に分割した場合,全ての小区間での CPU利用率を A% 以下に抑えるということである。したがて,この局所的リソースキャッピングを適用すると,この負荷のCPU利用率の経過は図40に示すようになる。即ち時刻T0移行は制御値Aで抑えられることになる。時刻T0より前では,元々,制御値Aより低いので,そのまま低いままである。これを全体の観測時間T1で見るとこの負荷の全体のCPU利用率は,制御値Aよりかなり低い値になってしまう。 一方,大域的に抑えるということは,局所的にA%を越えることがあっても良いが,長期の観測時間全体において CPU利用率を A% 以下に抑えるということである。この負荷に大域的リソースキャッピングを適用した場合のCPU利用率の経過を図41に示す。ここでは,T0までが制御値Aより低いので,その不足分をT0移降の制御値に加算することにより,T0以降では,制御値Aを越えることを許しているが,全体の観測時間T1で見れば,全体のCPU利用率はAで抑えられ,しかも,かなりAに近い値にまで達することができる。このように局所的な意味で指定するか,大域的な意味で指定するかは,ユーザによるところである。しかし,従来のリソースキャッピングは,局所的な意味でしか指定できなかった。この局所的なリソースキャッピングについては,以下のような問題点がある。
・・・(中略)・・・
【0010】
【発明が解決しようとする課題】本発明の目的は,あるVMのCPU利用率を,ユーザの指定量に抑える方式であるリソースキャッピングにおいて,短期(秒のオーダ)の実時間ではなく,長期の実時間(分または時間のオーダ)において,該VMのCPU利用率を該指定量に抑えるという方式を提供することである。各短期の区間においては,該指定量を越えることが有っても良い。この方式を大域的なリソースキャッピングと呼ぶ。」

C 「【0013】
【課題を解決するための手段】実時間において,小区間(例えば1秒)ごとに,ハイパバイザに割り込みを入れる手段,各小区間毎に,各VMのCPU使用時間を測定する手段,各小区間において各VMのCPU利用率の制限値を動的に指定する手段,各小区間において各VMのCPU利用率を該制限値以下に制限する手段からなる。」

D 「【0015】
【実施例】・・・(中略)・・・
各論理プロセッサタスク制御ブロックLGPBには,論理プロセッサのリソースデータ(レジスタや,PSWなど)の他に,命令プロセッサのサービスを受けた割合を表す値(U:これをCPUサービス量と呼ぶ)と,リソースキャッピングの指定により,各論理プロセッサに対して決定された該サービス量の上限値AとBが含まれる。これらを制御値A,Bと呼ぶ。
【0016】制御値Aは,初期制御値であり,ユーザの指定値,アクティブな論理プロセッサの台数により,VMのアクティベイト時に計算され,その後,新たに,VMがアクティベイトまたはディアクティベイトされない限り一定である。一方制御量Bは,動的に変動する値である。406は,制御値B設定部であり,周期的に,この制御値Bを計算し直すプログラムである。
【0017】この406の制御方法が,従来の方法と異なり,新方式を与え,本発明の主要部分を構成するものである。すなわち,各論理プロセッサのサービス量Uは,走行中の論理プロセッサが何らかの理由で中断されて,線455または線456が示すようにコントロールがスケジューラ402に移ったとき,スケジューラ402は,該中断された論理プロセッサのCPUサービス量Uを計算し直す。このためにスケジューラ402は,サービス量計算部404をコールする。404は,中断されるまでに走行した命令プロセッサによるサービス時間を加算して,現在までのCPUサービス量Uを該論理プロセッサについて求め,その制御ブロックLGPBに設定し直す。さらに,ある論理プロセッサが中断されて,コントロールがスケジューラ402に移ったとき,そのサービス量Uを上記のように更新した後,スケジューラ402は,キュー操作部405をコールする。キュー操作部405は,該制御ブロックLGPB内の現在の該CPUサービス量Uを該制御値Bと比較する。キュー操作部405は,このときU<Bであれば,いまだ制限値Bに達していないので,該論理プロセッサタスク制御ブロックLGPBをレディキューにキューイングする。この制御ブロックLGPBの動きを表したものが線460であり,この動きを制御する働きが線465である。キュー操作部405は,そうでないとき,すなわちサービス量Uが制御値B以上となったとき,該論理プロセッサのサービス量は制御値Bに達したので,該論理プロセッサをアウトサービス状態とする。さらに,アウトサービス状態の論理プロセッサの制御ブロックLGPBは,ディスパッチの対象からはずすために,アウトサービスキュー420にキューイングする。このデータの動きが線459で表現される。さらに,このキューイングを制御する働きを線467で表す。制御ブロックLGPBである420ー1,420ー2,420ー3は,このアウトサービスキュー420内の制御ブロックLGPBである。403は,周期タイマ割り込み発生部であり,実時間を区間(一秒程度)に分割して,その区間が経過する度にタイマ割り込みを発生させる。これを,スケジューラタイマ割り込みという。このスケジューラタイマ割り込みの発生により,コントロールが線451が示すようにスケジューラ402に移る。スケジューラ402は,制御値Bを以下の式により更新する。
【0018】 B=A+(B-U)
この更新はレディーキュー410の全ての論理プロセッサタスク制御ブロックLGPBについて実行される。さらに,この更新は,アウトサービスキュー420の全ての論理プロセッサタスク制御ブロックLGPBについて実行される。さらに,この更新はウェイト・キュー430の全ての論理プロセッサタスク制御ブロックLGPBについても実行される。走行中の論理プロセッサは,この周期タイマ割り込み発生により,中断されて,スケジューラ402により,上記中断処理をされ,サービス量Uが更新され,さらに,更新後のサービス量Uと制御値Bとの比較により,レディーキュー410か,アウトサービスキュー420にキューイングされる。そのあと,上記の制御値Bの設定部406の処理が行われる。制御値AとBは,該各区間における制御値を表すものであり,したがって,上記のBの更新が終わった後,Uは0に設定される。この更新が終わった後,スケジューラ402は,キュー操作部405をコールし,アウトサービスキューの全ての論理プロセッサタスク制御ブロックLGPBをレディキュー410にキューイングし,それらの制御ブロックLGPBに対応する論理プロセッサを,次の該実時間の区間において,ディスパッチの対象とする。線461がこのデータの動きを表し,線466がこのキュー操作の制御の働きを表す。
【0019】この発明の特徴は,制御値B設定部406の働きである。ここで,各論理プロセッサのサービス量の上限値である制御値Bを区間毎に変動させることにより,長期観測実時間において,CPUサービス量がA以下となるように制御することができる。たとえばある区間におけるCPUサービス量が現在の制御値B_(0)(制御値Bの初期値はAである)より,10%少ない場合は,次の該実時間の区間における制御値B_(1)は,A+10にする。この動的な制御値により,いくつかの区間においては,制御値Aを越えることがあっても,長期観測実時間における平均CPUサービス量をA以下とするという大域的なリソースキャッピングを実現することができる。また,制御値設定部406において制御値を常にAとすれば,該各区間全てにおいて,CPUサービス量がA以下となるので,従来の局所的リソースキャッピングを実現することもできる。さらに,VM毎に制御値設定部406の働きを変えることにより,VM毎に大域的リソースキャッピングと局所的リソースキャッピングとを別々に実現することもできる。」

E 「【0055】図27,28,29の説明: このようにして,論理プロセッサが実の命令プロセッサ上で走行させられる。走行中の論理プロセッサは,いろいろな要因で中断される。そのひとつは,ホストの割込みである。たとえば,ホストのクロック・コンパレータの割込みや,ホストのCPUタイマの割込みがそうである。ホスト・クロック・コンパレータ割込みは,図18に示す,ホスト・クロック・コンパレータ・レジスタ 302の値が,図15に示すシステム共通レジスタ600の現在時刻TODの値を越えたときに発生する。これは,従来通りである。ホストCPUタイマの割込みは,図18に示すホストCPUタイマ・レジスタ300の値が負になったときに発生する。これも従来通りである。図21に示すスケジューラタイマ同期処理により,全命令プロセッサで同時にスケジューラタイマ用のホスト・クロック・コンパレータの割込みが発生する。また,図26に示す,ディスパッチ処理でホストCPUタイマ・レジスタ300に残りのタイム・スライスTS(p,q)(論理プロセッサ(p,q)用のタイムスライス)を設定したことにより(713ー3),該当の論理プロセッサが,そのタイム・スライスを使い切るとホストCPUタイマ割込みが発生する。これを,タイムスライスエンドの割込みという。これらの制御は,従来通りである。これらのホスト割込み処理の後,図27,28,29に示す論理プロセッサの中断処理が呼ばれる。ここでは,先ず,走行中であった論理プロセッサの制御ブロックLGPBのアドレスをレジスタ307から求める。今それをLGPB_Rとする(800ー2)。このLGPB_Rから現VM番号p,論理プロセッサ番号q を求める(800ー3)。これは,LGPB_Rの場所112から読み出してくればよい(図7参照)。次に,LGPB_Rの統計データ不当インディケータsinv(p,q)=1であるかを判断する。そうである場合は,該LGPB_R内の種々の統計データを更新する必要があるので,800ー4へ行く。そうでない場合は,すでに更新済みであるので,ただちにリターンする。次に,該論理プロセッサのCPU消費時間を計算するために,現命令プロセッサのホストCPUタイマレジスタ300の値を読み出す。今,その値をTS_R'とする(800ー4)。次に該LGPB_Rの残りのタイムスライスデータを114ー2ーRから読み出す。今,その値をTS_Rとする(800ー5)。これは,該論理プロセッサのディスパッチ時のホストCPUタイマの値がTS_Rμsecであり,それが1μsecごとにビット51から1が減算されて行き(図18の300参照),今処理している論理プロセッサの中断時にTS_R'μsecとなったことを意味する。したがって,該論理プロセッサのCPU消費時間 u μsecは,
u = (TS_R) - (TS_R')
によって求められる(800ー6)。このuμsecは,最後のディスパッチから,最初の中断までの論理プロセッサの消費したCPU時間である。次に,該論理プロセッサ(p,q)の累計のCPU消費時間を計算する。これは,以下の式による。
【0056】すなわち,LGPB_Rの場所114ー3ーRの値C(p,q)_Rを読み出す。これは,該論理プロセッサの区間におけるCPU消費時間の累計を表す。そこで,
C(p,q)_R = C(p,q)_R + u
とし,更新されたC(p,q)_Rの値を該LGPB_Rの114ー3ーRに格納する(800ー7)。次に,該論理プロセッサの区間におけるCPU利用率U(p,q)_R (%) を求める。システムデータ領域500から区間の長さΔtμsecを得る。さらに,800ー7で更新したC(p,q)_R(これは,区間における該論理プロセッサのCPU消費時間)を用いて,
U(p,q)_R = (C(p,q)_R/Δt)*100 (%)
これを,該論理プロセッサの区間CPU利用率として,該LGPB_Rの114ー6ーRに格納する(800ー8)。次に,この区間CPU利用率が制御値を越えるかどうかを判断する。すなわち,800ー8で計算した区間CPU利用率U(p,q)_R(これは,該論理プロセッサのCPU利用率)と,該LGPB_Rの場所114ー5ーRに格納されている制御値B(p,q)_R(これも該論理プロセッサに関する値)を用いて,
(U(p,q)_R) < (B(p,q)_R)
かどうかを判断する(800ー9)。もし,そうであるならば,まだ,現区間においては,制御値に達していないので,再びレディキューにキューイングしてディスパッチするために800ー10へ行く。もし,そうでないときは,すでに制御値に達したのでアウトサービスキューへキューイングするために800ー12へ行く。先ず,800ー10から説明する。ここでは,区間における該論理プロセッサ(p,q)のCPU充足度(D(p,q)_R (%))を計算する。」

イ 引用発明

してみると,引用文献1には,「計算機の性能を向上させるために計算機資源の割当て・キャッピングをスケジュールする(上記Bより)」ことを目的とした,次の発明(引用発明)が記載されている。
「各VMのCPU使用時間を測定する手段(上記Cより)と,
該CPU使用時間と制限値とを比較し,制限値を越えていれば,制限をかけて,各VMのCPU使用率を制限値以下にする手段(上記Cより)と,
制限値を変動させる手段(上記Dより)と
を備えた仮想計算機システム。(上記Aより)」

(1-2)引用文献2

ア 本願の出願日前に頒布または電気通信回線を通じて公衆に利用可能となり,原審の拒絶の査定の理由である上記平成26年8月18日付けの拒絶理由通知において引用された文献である,特表2005-516303号公報(平成17年6月2日公表。以下,「引用文献2」という。)には,関連する図面とともに,以下の技術的事項が記載されている。
(当審注:下線は,参考のために当審で付与したものである。)

F 「【発明が解決しようとする課題】
【0004】
本発明の目的は,実行の処理集約型(processing-intensive)スレッドによって引き起こされる性能の問題を軽減するのに用いられ,請求項1,10および11それぞれの前提条件による方法,マルチプログラミングコンピュータシステムおよびコンピュータプログラムを提供することである。
【課題を解決するための手段】
【0005】
従って,本発明は,優先スケジューリングを備えたマルチプログラミングコンピュータシステムにおける優先レベルを設定する方法であって,各処理の実行のスレッドが標準的な優先レベルを有し,処理の実行のスレッドによってシステム内の1またはそれ以上のプロセッサの相対的使用量(relative use)を測定する段階を備え,エスカレーション時間(escalation time period)の間,それらの測定された相対的使用量が所定のエスカレーション閾値を上回る場合,1またはそれ以上の実行のスレッドの優先レベルが低くされる方法を提供する。
・・・(中略)・・・
【0007】
好ましくは,エスカレーション時間の間,その処理の前記スレッドによる全相対的使用量がエスカレーション閾値を上回る場合,1つの処理に属する実行の全スレッドの優先レベルは低くされる。
【0008】
従って,マルチスレッドされたコードを実行可能なコンピュータシステムにおいて,他より極めて多くの実行のスレッドを備えた処理は検出を逃れられない。ユーザは,一般的に処理が遅いことに気付くだけである。それらによって用いられた全処理手続き容量が閾値を上回る場合に,処理の実行の全スレッドの優先度を低くさせることは,他の処理をより応答しやすくさせる。
【0009】
好ましくは,少なくとも1つのスレッドの優先レベルは,可能な値(possible value)の範囲内で最低レベルまで低くされる。
【0010】
従って,効果が即座に現れる。いくつかの時間に渡って優先度を除々に減らす必要はない。エスカレーション時間の使用と相まって,前記方法は安定しており,さらにユーザ側のもどかしさを避けるのに充分な応答性がある。
【0011】
好ましくは,試験時間(probation time period)の間,相対的使用量が試験閾値より低い場合,低くされた優先レベルは標準的な優先レベルに戻される。」

G 「【0025】
マルチスレッド(multithread)されたシステムでは,各処理は,1またはそれ以上の実行のスレッドを有することができる。図2の例では,図2の前記第1処理13は,第1スレッド15および第2スレッド16を有する。前記第2処理14もまた,2つのスレッド17を有する。実行のスレッドは,CPU2上での実行に対してスケジュール化されたもの(entity)である。各スレッド15,16,17は,その進捗を示すプログラムカウンタと,その最新の作業変数(working variables)を保持するレジスタと,スタックとを有する。前記第1処理13の実行のスレッド15,16は,その処理13のアドレス空間,オープンファイルおよび他のリソースを共有する。前記第2処理14の前記スレッド17にも同じことが当てはまる。」

H 「【0038】
図3を参照すると,前記第1処理13による前記CPU2の前記相対的使用量が示されている。グラフは,本発明による方法を用いるシステムから得られる。前記相対的使用量は,処理時間の割合として表現されるが,おおむね演算数のようないくつかの他の基準(measure)が用いられる。この例では,前記エスカレーション閾値が80%に設定されている。時間T0点で,前記第1処理13による前記プロセッサの前記相対的使用量は,前記エスカレーション閾値を上回る。実際,それは実質的に100%となる。時間間隔ΔT1の間中,前記相対的使用量が80%より上のままであるので,前記第1処理13は,より低い処理優先度クラスへ移動される。前記’CPU-hungry’スレッドを備えている前記処理13の両方のスレッド15,16の優先レベルもまた,その結果として低くされる。結果として,前記相対的使用量は,甚だしい妨害なく,前記第2処理が進行するのに充分な95%近傍まで低くされる。
【0039】
前記時間間隔ΔT1の長さは,前記コンピュータシステムのユーザの忍耐量に大きく依存する。図3の前記グラフから明らかなように,時間間隔ΔT1の間,他の処理が実行を効果的に妨げられる可能性がある。勿論,前記第1処理13の前記優先レベルが低くされた後,’CPU-hungry’スレッドの優先レベルが前記第2処理14の全てのスレッドのそれ(優先レベル)より依然として高い場合,長さΔT1の他の時間間隔が経過するまでは何も生じない。このことは受け入れられないであろう。
【0040】
従って,優先レベルは,T1における許容値の範囲内で最低レベルまで低くされる。例示のシステムでは,前記処理優先度クラスは,最低限の可能なレベルまで下げられる。しかしながら,本発明の範囲内で,処理の全てのスレッドのスレッド優先度クラスは,最低限の可能なレベルまで低くされる。その後,前記第1処理13の両方のスレッド15,16はレベルP0になる。
【0041】
多くの場合,処理またはスレッドは,一時的にのみ,過度にプロセッサ容量を消費する。例示的な状況は,2人のユーザが1台のマシン上でワードプロセッシングアプリケーションを実行しているものである。2つの処理のそれぞれが同一の基本優先レベルにある。1人のユーザがマクロの実行を決定するかもしれない。この時点で,ユーザの処理は,他の処理が影響を受けるほど大きなプロセッサ容量を消費するかもしれない。従って,マクロを実行する処理の前記優先レベルが低くされる。それより後の時点で,他のユーザがマクロを実行する場合,他のユーザの処理の前記優先レベルは低くされる。いずれの処理も,今度は最低優先レベルとなる。一方の処理が再び優勢になり始めると,何の救済措置も残されていない。
【0042】
前記相対的使用量が試験閾値より低い場合,低くされた優先レベルが標準的な優先レベルに戻されるため,この好ましくない状況が回避される。図3では,前記試験閾値は,40%に設定される。
【0043】
勿論,前記CPU使用量が,前記試験閾値を一時的に割ることもあり得る。前記優先レベルが標準的な優先レベルへすぐに戻される場合,そのとき基本優先レベルがほぼ毎秒変化する極めて不安定なシステムになってしまう。
【0044】
このことは,所定の長さΔT2の試験時間の間,前記相対的使用量が試験閾値より低くされる場合に,優先レベルを標準的な優先レベルへ戻すことによってのみ回避される。従って,図3では,前記第1処理13のスレッド15,16の優先レベルは,T3におけるそれらの標準的なレベルに戻される。」

(2) 対比

本件補正発明と引用発明とを対比する。

(2-1)
引用文献1における上記Eの「論理プロセッサのCPU消費時間を計算する」及び「該論理プロセッサの区間CPU利用率として,該LGPB_Rの114ー6ーRに格納する(800ー8)。次に,この区間CPU利用率が制御値を越えるかどうかを判断する。」との記載等を踏まえると,引用発明では,CPU消費時間を計算して,CPU利用率を計算している。その際,当然CPUの消費量に相当する値を測定していることは明らかなので,引用発明における「CPU使用時間を測定」することは,本件補正発明の「計算機資源の消費量を測定する測定部」に相当する。 1

(2-2)
引用発明の「該CPU使用時間と制限値とを比較し,制限値を越えていれば,制限をかけて,各VMのCPU使用率を制限値以下にする手段」は,CPU使用時間が制限値以上の値となっていることを検出しているといえるので,本件補正発明の「前記測定部の測定により前記消費量が閾値以上の値となっていることが検出されると,前記消費量の制限を行い」に相当する。

(2-3)
引用発明の「制限値を変動させる」ことと本件補正発明の「前記制限を緩和する」こととは,制限値を変動させるものである点で共通する。

(2-4)
よって,本件補正発明は,下記の一致点で引用発明と一致し,下記の相違点で引用発明と相違する。

<一致点>
「計算機資源の消費量を測定する測定部と,
前記測定部の測定により前記消費量が閾値以上の値となっていることが検出されると,前記消費量の制限を行い,その後,制限値を変動させる制御部と
を備える監視制御装置。」

<相違点>
本件補正発明では,「消費量の制限を行い」,「その後,前記消費量が前記制限された値未満であることが検出されると直ちに前記制限を緩和する」のに対して,引用発明では,制限されている状態から,制限値を変動させるものの,「制限された値未満であることが検出されると直ちに前記制限を緩和する」ことに言及がない点。

(3) 当審の判断

一般的に,処理手段のパフォーマンスはより高い方が望ましいことは,説示する迄も無い技術常識であるから,何らかの原因でパフォーマンスを抑制した際に,当該原因がなくなれば可能な限り早めに元のパフォーマンスに復帰させることは,当業者ならずとも当然に想到する事項にほかならない(例えば,引用文献1では,段落【0008】の「局所的に抑えるということは,観測時間(T1)(例えば1時間)を各小区間(例えば1秒)に分割した場合,全ての小区間での CPU利用率を A% 以下に抑えるということである。」との記載から,制限開始時刻(T0)から,観測時間(T1)の間はCPU利用率を過ぎるとCPU利用率を抑制しないようにすることが読みとれ,引用文献2に記載のものにおいては,段落【0007】?【0011】に,閾値を上回ると,優先レベルを低くし,所定の期間,相対的使用量が試験閾値よりも低くくなった場合に,低くされた優先レベルを標準的な優先レベルに戻すことが記載されている。)。
してみると,引用発明においても「その後,前記消費量が前記制限された値未満であることが検出されると直ちに前記制限を緩和する」ものとすること,すなわち上記相違点に係る事項を採用することは,当業者であれば,当然の如く採用する設計的事項に過ぎないものである。

したがって,本件補正発明の構成は当業者が引用発明から容易に想到し得るものであり,その作用効果も当業者が当然に予測し得る程度のものであって格別顕著なものでもない。

したがって,本件補正発明は,引用発明及び引用文献2に記載の発明から,当業者が容易に想到しうるものである。

4-3.独立特許要件のまとめ

したがって,本件補正後の特許請求の範囲の記載は,特許法第36条第6項第1号の規定を満たしておらず,しかも,本件補正発明は特許法第29条第2項の規定により特許を受けることができないものであるから,本件補正発明は,独立して特許することができないものである。

5.むすび

上記2.のとおり,本件補正は,特許法第17条の2第3項の規定に違反するので,同法第159条第1項において読み替えて準用する同法第53条第1項の規定により却下すべきものである。

また,上記4.のとおり,本件補正は,特許法第17条の2第6項において準用する同法第126条第7項の規定に違反するので,同法第159条第1項において読み替えて準用する同法第53条第1項の規定により却下すべきものである。

よって,上記補正却下の決定の結論のとおり決定する。


第3.本願発明について

1.本願発明の認定

平成27年2月18日付けの手続補正は上記のとおり却下されたので,本件補正後の請求項1に対応する本件補正前の請求項に係る発明(以下,「本願発明」という。)は,平成26年10月16日付けの手続補正により補正された特許請求の範囲の請求項1に記載された事項により特定される,以下のとおりのものである。

「計算機資源の消費量を測定する測定部と,
前記測定部の測定により前記消費量が閾値以上の値となっていることが検出されると,前記消費量の制限を行い,その後,前記消費量が前記制限された値未満であることが検出されると前記制限を緩和する制御部と
を備える監視制御装置。」

2.引用文献1,2に記載されている技術的事項及び引用発明の認定

引用文献1,2の記載事項及び引用発明は,上記「第2.平成27年2月18日付けの手続補正についての補正却下の決定」の「4.独立特許要件」の「(1) 引用文献」に記載したとおりである。

3.対比及び当審の判断

本願発明は,前記「第2 平成27年2月18日付けの手続補正についての補正の却下の決定」の「4-2.特許法第29条第2項(進歩性)について」で検討した本件補正発明から,「直ちに」との限定を削除したものである。

そうすると,本願発明の構成要件を全て含み,さらに特定の構成要件に限定要件を付加したものに相当する本件補正発明が,前記「第2 平成27年2月18日付けの手続補正についての補正の却下の決定」の「4-2.特許法第29条第2項(進歩性)について」の「(1)引用文献」?「(3)当審の判断」に記載したとおり,引用発明,引用文献2に記載のごとき周知慣用技術に基づいて,当業者が容易に発明をすることができたものであるから,本願発明も,同様の理由により,当該引用発明及び周知慣用技術に基づいて,当業者が容易に発明をすることができたものである。

そして,本願発明の奏する作用効果は,上記引用発明,引用文献2に記載の技術の奏する作用効果から予測される範囲内のものにすぎず,格別顕著なものということはできない。

4.むすび

以上のとおり,本願の請求項1に係る発明は,特許法第29条第2項の規定により特許を受けることができないものであるから,その余の請求項に係る発明について検討するまでもなく,本願は拒絶すべきものである。

よって,結論のとおり審決する。
 
審理終結日 2015-06-10 
結審通知日 2015-06-16 
審決日 2015-06-30 
出願番号 特願2013-273400(P2013-273400)
審決分類 P 1 8・ 575- Z (G06F)
P 1 8・ 55- Z (G06F)
P 1 8・ 561- Z (G06F)
P 1 8・ 121- Z (G06F)
最終処分 不成立  
前審関与審査官 漆原 孝治  
特許庁審判長 山崎 達也
特許庁審判官 辻本 泰隆
木村 貴俊
発明の名称 監視制御装置  
代理人 特許業務法人高橋・林アンドパートナーズ  
  • この表をプリントする

プライバシーポリシー   セキュリティーポリシー   運営会社概要   サービスに関しての問い合わせ