• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 取り消して特許、登録 G06F
管理番号 1304400
審判番号 不服2014-10357  
総通号数 190 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2015-10-30 
種別 拒絶査定不服の審決 
審判請求日 2014-06-03 
確定日 2015-09-01 
事件の表示 特願2012-514658「リソース管理方法、計算機システムおよびプログラム」拒絶査定不服審判事件〔平成23年11月17日国際公開、WO2011/142031、請求項の数(15)〕について、次のとおり審決する。 
結論 原査定を取り消す。 本願の発明は、特許すべきものとする。 
理由 第1 手続の経緯

本件審判請求に係る出願(以下「本願」と記す。)は、2010年5月14日を国際出願日とする出願であって、平成24年9月19日付けで特許法第184条の5第1項の規定による書面が提出され、同年10月3日付けで審査請求がなされ、平成25年7月4日付けで拒絶理由通知(同年7月9日発送)がなされ、同年7月8日付けで上申書が提出されると共に、同日付けで手続補正書が提出され、同年8月27日付けで意見書が提出されると共に、同日付けで手続補正書が提出され、平成26年2月27日付けで拒絶査定(同年3月4日謄本送達)がなされたものである。
これに対して、「原査定を取り消す。本願は特許すべきものである、との審決を求める。」ことを請求の趣旨として、平成26年6月3日付けで審判請求がされるとともに、同日付けで手続補正書が提出され、同年8月19日付けで特許法第164条第3項に定める報告がなされた。

第2 本願発明

本願の請求項1-15に係る発明は、平成26年6月3日付けの手続補正で補正された特許請求の範囲の請求項1-15に記載された事項により特定されるものと認められるところ、本願の請求項1に係る発明(以下、「本願発明」という。)は以下のとおりである。

「実行物理サーバに仮想的に割当てられ、複数のバッチアプリケーションを実行する複数の実行仮想サーバと、前記バッチアプリケーションの配置に必要な、前記実行物理サーバにおけるリソース量の計算を行なうリソース管理装置と、を備える計算機システムのリソース管理方法であって、
前記計算機システムは、
処理が完了している各バッチアプリケーションの処理データ件数であるロット毎に処理履歴を管理し、
所定の契機で、ロット単位の前記処理履歴をグルーピングし、
前記グルーピングされた処理履歴を基に、処理対象となっている前記バッチアプリケーションについて、現在までに完了している前記ロットの件数を、当該バッチアプリケーションが行なう、すべての前記ロットの件数で除算した処理進捗率と、要求処理時間内に前記バッチアプリケーションを終了するため、現在までに行なわれているべき処理の進捗率である必要進捗率と、を前記バッチアプリケーション毎に算出し、
前記処理進捗率が前記必要進捗率に達していない前記バッチアプリケーションがあるか否かを判定し、
前記判定の結果、前記必要進捗率に達していない前記バッチアプリケーションがある場合、前記必要進捗率および前記処理進捗率を基に、当該バッチアプリケーションについて、前記要求処理時間内の将来の所定時刻までに完了していると推定される前記ロットの件数を、当該バッチアプリケーションが行なう、すべての前記ロットの件数で除算した推定処理進捗率が、前記将来の所定時刻において行なわれているべき処理の進捗率である推定必要進捗率に達するために必要な前記リソース量を算出し、
前記算出したリソース量に従って、前記バッチアプリケーションを実行している前記実行仮想サーバに割当てる前記リソースを変化させる
ことを特徴とするリソース管理方法。」

第3 原査定の理由の概要

1.平成25年7月4日付け拒絶理由通知

平成25年7月4日付けで拒絶理由が通知されたが,その内容は下記のとおりである。

「1.この出願の下記の請求項に係る発明は、その出願前に日本国内又は外国において、頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。

2.この出願は、特許請求の範囲の記載が下記の点で、特許法第36条第6項第2号に規定する要件を満たしていない。

記

[引用文献等一覧]
1.特開2009- 25939号公報
2.特開2009- 86733号公報


[理由1]
[請 求 項]1-16
[引用文献等]1、2
[備考]
引用文献1には、アプリケーションソフトウェアタスクの実行を制御するタスク制御方法において、アプリケーションソフトウェアタスクの処理の経過時間から進捗状況を判断し、進捗状況が遅れている場合に、進捗の遅れを挽回するために、タスクが利用するリソースを制御するタスク制御方法が記載されている(段落【0032】-【0038】、第2図等)。
引用文献2には、アプリケーションの進捗度に応じて、CPU時間の割り当てを変更する情報処理装置において、処理したループカウント値を総ループ回数で除した結果を、進捗度とし、現在までに実行した時間と進捗度から実行中のアプリケーションの実行処理に要するCPU時間を予測し、CPU時間が不足する場合には、追加のCPU時間を割り当てる技術が開示されている(段落【0072】-【0082】等)。
したがって、本願の請求項1-16に係る発明は、引用文献1、2に記載された発明に基づいて、当業者が容易に推考できたものである。


[理由2]
[請 求 項]1-16
イ)請求項1に記載の、「前記判定の結果、前記必要な進捗率に達していない場合、前記必要進捗率および前記処理進捗率の差分である遅延回復対象進捗率と、リソースの情報と、を基に、前記要求処理時間前に前記処理進捗率が前記必要進捗率に達するために必要なリソースを算出する」は、何らかの情報を基に算出等の処理を行う際には、算出のために用いる情報およびその関係や、具体的な算出の処理内容に応じて、得られる構成が異なってくることが、技術常識であるところ、単に、「・・・遅延回復対象進捗率と、リソースの情報と、を基に、・・・ために必要なリソースを算出する」では、「リソースの情報」が何を意味するのか不明であるし、リソースを算出するための基礎となる情報およびその関係や、具体的な算出の処理内容等が不明であり、発明の構成が明確でない。
また、「前記要求処理時間前に前記処理進捗率が前記必要進捗率に達するために必要なリソース」は、「要求処理時間前に」とする時期・条件についての比較の基準又は程度が不明瞭であるし、「前記処理進捗率」は、「現在時刻における処理の進捗率」を意味するとしても、「現在時刻における処理の進捗率」が、「前記必要進捗率に達する」とは、いつの時点の処理の進捗率が、どのようになることを意味するのか明瞭に把握できず、どのようなリソースの算出をするのか明確でない。

ロ)請求項5に記載の、「前記必要処理件数」は、前記されていない。

ハ)請求項7に記載の、「予め設定しておいた予備のリソースに前記バッチアプリケーションを割当てたときのリソース量を算出する」は、予備のリソースにアプリケーションを割当てることと、リソース量を算出することとの関連が日本語としても技術内容としても不明であり、発明の構成を把握できない。また、当該リソース量を算出することを、いずれの構成要素が如何なる事項間の関連により、どのような量を算出するのかも不明である。
請求項9に記載の、アプリケーションを置換することと、リソース量を算出することとの関連、当該リソース量を算出することについても同様である。

ニ)請求項8に記載の、「前記バッチアプリケーションの割当てに必要な時間を考慮する」は、「バッチアプリケーションの割当てに必要な時間」とは、割当てに関する如何なる観点での必要な時間を意味するのか、特段の定義もなく、また、それを一義に理解する技術常識もなく不明であり、また、「・・・を考慮する」は、人為的な処理であり、技術内容として何れの構成要素による如何なる処理・動作を意味するのか不明であり、発明の構成が明確でない。
請求項10についても同様である。

上記イ)-ハ)で検討した点について、請求項11-16の対応する事項・記
載についても同様である。

よって、本願の請求項1-16に係る発明は明確でない。 」

2.平成26年2月27日付け拒絶査定

平成26年2月27日付けで拒絶査定がなされたが,その内容は下記のとおりである。

「 この出願については、平成25年 7月 4日付け拒絶理由通知書に記載した理由1によって、拒絶をすべきものです。
なお、意見書並びに手続補正書の内容を検討しましたが、拒絶理由を覆すに足りる根拠が見いだせません。

[備考]
出願人は、補正書で補正後の請求項1において、処理進捗率を、「処理対象となっている前記バッチアプリケーションについて、現在までに完了している前記ロットの件数を、当該バッチアプリケーションが行うすべての前記ロットの件数で除算した処理進捗率」と補正するとともに、意見書において、「本願請求項1に係る発明は、アプリケーションが処理するデータを中間処理単位データであるロット単位のデータに分割し、ロット単位で進捗状況を判断しています。このため遅延の状況を判断するのが容易であり、追加のCPU数などのリソース量を見積もるのが容易となります。」と主張している。
上記の点について検討する。
処理の進捗を、処理済みの件数を全体の件数で除算した進捗率で把握することは、例えば、文献A(段落【0029】等)等にも記載されているように、広く行われていることであり、格別の事項ではない。
そして、引用文献1に記載の発明は、処理の進捗状況を、チェックポイントの経過状況で判断しており、チェックポイントは、タスクに予め埋め込まれたポイントであり、タスク全体に対する部分的な処理単位といえ、中間処理単位を意味するものと解される。したがって、引用文献1に記載の発明において、チェックポイントの経過状況で処理の進捗状況を判断することは、本願発明におけるロット単位での進捗状況を判断することと格別に相違するものではないから、出願人の主張は採用できない。
したがって、本願の請求項1-15に係る発明は、上記拒絶理由通知書及び上記備考で検討したとおり、引用文献1、2に記載された発明及び周知・慣用技術に基づいて、当業者が容易に推考できたものであるから、依然として、上記拒絶理由通知書に記載した理由は解消されていない。

[引用文献等一覧]
1.特開2009- 25939号公報
2.特開2009- 86733号公報
A.特開2008-123205号公報」

第4 当審の判断

1.引用文献

(1)引用文献1に記載されている技術的事項及び引用発明

本願の出願日前に頒布又は電気通信回線を通じて公衆に利用可能となった、原審の平成25年7月4日付けの拒絶理由通知において引用された、特開2009-25939号公報(平成21年2月5日出願公開、以下、「引用文献1」という。)には、以下の技術的事項が記載されている。 (当審注:下線は、参考のために当審で付与したものである。)

A 「【0027】
上記マルチプロセッサシステムには、特に制限されないが、二つの汎用プロセッサ(CPU)100,101、クロック生成回路(CKGEN)102、共有リソース管理モジュール(CRM)103、バスとその調停を行うバス調停回路(BUS_ARB)104、プロセッサ間の共有メモリ(CM)105、ブート時にプロセッサにロードする各種ソフトウェアを格納するフラッシュメモリ(FLSH)106、リアルタイムオペレーティングシステム(RTOS)111,116の各種サービスコールの実行に用いる割り込みコントローラ(InｔC)107とタイマ(Timeｒ)108が含まれる。尚、FLSH106には、本例におけるタスク制御方法を実現するタスク制御プログラムも格納される。
・・・(中略)・・・
【0029】
CPU100に搭載するソフトウェアは、RTOS111、CPU100にのみ関連するクロック周波数などのパラメータを制御するLRCL112、及びアプリケーションタスク(APPL)113から構成する。同様にして、CPU101に搭載するソフトウェアは、RTOS116、LRCL117、及びAPPL118である。
・・・(中略)・・・
【0031】
CRM103は、共有リソースコントローラ専用のCPUであるSCPU121、SCPU121上に搭載するRTOS122と共有リソースコントローラ(CRCL)123から構成される。BUS_ARB104は、後で述べるバスを利用する優先順位の設定がCRM103を通して実施できる。」

B 「【0032】
＜マルチプロセッサシステムにおける制御の流れ＞
次に、図2及び図3を参照しながら、上記マルチプロセッサシステムにおける制御の流れを説明する。
【0033】
図2の一番上のCPU100の欄には、ローカルリソースコントローラLRCLの流れが示され、上から三番目のCRM103の欄には、共有リソースコントローラCRCL123の流れが示される。
【0034】
まず、LRCL112は、APPL113のあるチェックポイントの予定経過時間に、実行状況を問い合わせ(200)、現在経過したチェックポイントの通知を受ける(201)。
【0035】
チェックポイント(CP)は、APPL113に予め埋め込んであり、図3の303に示されるように、各CPに対して、事前に予算、すなわち予定経過時間が定められている。ここで、SはSｔaｒｔ、EはEndを表し、CPの特殊な形である。例えば、図3において、CP2の予定経過時間は、301からΔｔ1+Δｔ23であることがわかる。この時間に実行状況を問い合わせると(200)、CP1しか経過していないことが判明する(201)。すなわち、300が現在の経過状況となる。この結果を受取り、LRCL112は、遅れの深刻さや、終了までの残り時間と残った処理量との対比から進捗状況を把握する(202)。
【0036】
次に、上記進捗状況を受けて遅れを挽回するため、CPU100専用のローカルリソースを制御する(203)。例えば203ではCPU100用のクロックを変更する。具体的には、図1の信号114を介して、CKGEN102内のCKDIV119の分周比を変更して、CPU100用のクロック周波数を変更する。
【0037】
一方、共有リソースを制御するために、進捗状況をCRM103に通知する(204)。
【0038】
CPU101での動作もCPU100と同様である。CRM103のCRCL123は、CPU100とCPU101から進捗状況の通知を受けて(204,205)、共有リソースの制御を行う。基本クロックを変更する必要があるなら、206により、CKGEN102を制御する。また、CPU100とCPU101の進捗状況を比較して、207により、遅れがより顕著なプロセッサの共有リソースの優先度を上げる。図1のブロック図では、共有リソースとして、BUS_ARB104が該当するため、104に対して優先度変更の制御を行う。」

ここで、上記引用文献1に記載されている事項を検討する。

ア 上記Aの「マルチプロセッサシステムには、特に制限されないが、二つの汎用プロセッサ(CPU)100,101・・・が含まれる」及び「CPU100に搭載するソフトウェアは・・・アプリケーションタスク(APPL)113から構成する。・・・CPU101に搭載するソフトウェアは・・・APPL118である」より、CPU100及びCPU101は、それぞれアプリケーションタスクを実行することは自明であるから、引用文献1には「それぞれアプリケーションタスクを実行する複数のプロセッサ」が記載されているものと解される。

イ 上記Aの「CRM103は、共有リソースコントローラ専用のCPUであるSCPU121、SCPU121上に搭載する・・・共有リソースコントローラ(CRCL)123から構成される」及び上記Bの「共有リソースを制御するために、進捗状況をCRM103に通知する」、「CRCL123は・・・CPU100とCPU101の進捗状況を比較して、207により、遅れがより顕著なプロセッサの共有リソースの優先度を上げる。」より、リソースコントローラはプロセッサの進捗状況を把握してリソースを制御していることから、引用文献1には「プロセッサの進捗状況を把握し、リソース制御するリソースコントローラ」が記載されているものと解される。

ウ 上記ア、イより引用文献1には「それぞれアプリケーションタスクを実行する複数のプロセッサと、プロセッサの進捗状況を把握し、リソース制御するリソースコントローラとからなる、マルチプロセッサシステムのリソース制御方法」が記載されていると認められる。

エ 上記Bの「APPL113のあるチェックポイントの予定経過時間に、実行状況を問い合わせ・・・現在経過したチェックポイントの通知を受ける」、「遅れの深刻さや、終了までの残り時間と残った処理量との対比から進捗状況を把握する・・・共有リソースを制御するために、進捗状況をCRM103に通知する」より、引用文献1には「チェックポイントの予定経過時間において経過したチェックポイントの通知を受け、遅れの深刻さや、終了までの残り時間と残った処理量との対比から進捗状況を把握」することが記載されているものと解される。

オ 上記Bの「CRCL123は・・・CPU100とCPU101の進捗状況を比較して、207により、遅れがより顕著なプロセッサの共有リソースの優先度を上げる」より、引用文献1には「遅れがより顕著なプロセッサに割り当てるリソースを変化させる」ことが記載されているものと解される。

してみると、引用文献1には次の発明(以下、「引用発明」という。)が記載されているものと認められる。

「それぞれアプリケーションタスクを実行する複数のプロセッサと、プロセッサの進捗状況を把握し、リソース制御するリソースコントローラとからなる、マルチプロセッサシステムのリソース制御方法において、
チェックポイントの予定経過時間において経過したチェックポイントの通知を受け、遅れの深刻さや、終了までの残り時間と残った処理量との対比から進捗状況を把握し、
遅れがより顕著なプロセッサに割り当てるリソースを変化させる、方法。」

(2)引用文献2に記載されている技術的事項

本願の出願日前に頒布又は電気通信回線を通じて公衆に利用可能となった、原審の平成25年7月4日付けの拒絶理由通知において引用された、特開2009-86733号公報(平成21年4月23日出願公開、以下、「引用文献2」という。)には、以下の技術的事項が記載されている。(当審注:下線は、参考のために当審で付与したものである。)

C 「【0072】
まず、CPU12Bは、ループカウンタ値を総ループ回数で除算した結果を、進捗度とする(ステップS201)。
【0073】
次に、CPU12Bは、現在までにアプリケーションの実行処理に要したCPU時間を、進捗度で除算した結果を、実行中のアプリケーションの実行処理に要すると予想されるCPU時間(以下、予想総CPU時間と呼ぶ)とする(ステップS202)。なお、CPU12Bは、OS1に従って、現在までにアプリケーションの実行処理に要したCPU時間を管理しているものとする。
【0074】
次に、CPU12Bは、予想総CPU時間から、現在の周期において割り当てられたCPU時間(以下、現周期の割当CPU時間と呼ぶ)を減算した結果を、アプリケーションの実行処理を行うにあたって不足するCPU時間(以下、不足時間と呼ぶ)とする(ステップS203)。
【0075】
不足時間が“0”以下であれば(ステップS204のいいえ)、CPU12Bは、実行中のアプリケーションの実行処理が、現周期の割当CPU時間内に、完了すると判定する(ステップS205)。
【0076】
一方、不足時間が“0”より大きければ(ステップS204のはい)、CPU12Bは、実行中のアプリケーションの実行処理が、現周期の割当CPU時間内に、完了しないと判定する(ステップS206)。
【0077】
図13は、図4のステップS107?S109において、CPU12Aが、スケジューラ2の割当コード2-1に従って、現周期の未割当CPU時間から、アプリケーションに対してCPU時間の再割当を行う際の動作を示すフローチャートである。
【0078】
まず、CPU12Aは、CPU12Bから、CPU時間の再割当要求として、アプリケーションの種別と、そのアプリケーションの実行に不足する不足時間とを受信する。
【0079】
次に、CPU12Aは、不足時間が現周期の未割当CPU時間よりも大きいか否かを判定する(ステップS301)。なお、不足時間は、CPU12Bが、図12のステップS203において、進捗管理コード3b-2にしたがって算出したものである。
【0080】
不足時間が現周期の未割当CPU時間よりも大きいと判定された場合(ステップS301のはい)、CPU12Aは、アプリケーションに対してCPU時間の再割当を行う際に、追加するCPU時間(以下、追加割当時間と呼ぶ)を、現周期の未割当CPU時間の残りすべてとする(ステップS302)。
【0081】
一方、不足時間が現周期の未割当CPU時間より大きくないと判定された場合(ステップS301のいいえ)、CPU12Aは、追加割当時間を不足時間とする(ステップS303)。
【0082】
次に、CPU12Aは、現周期の未割当CPU時間から追加割当時間を減算した減算結果へ、現周期の未割当CPU時間を更新する(ステップS304)。」

(3)引用文献3に記載されている技術的事項

本願の出願日前に頒布又は電気通信回線を通じて公衆に利用可能となった、原審の平成26年2月27日付けの拒絶査定において周知文献として引用された、特開2008-123205号公報(平成20年5月29日出願公開、以下、「引用文献3」という。)には、以下の技術的事項が記載されている。(当審注:下線は、参考のために当審で付与したものである。)

D 「【0029】
図3に、記憶装置114に設定されているノード管理テーブル300のデータ構成の1例を示す。ノード管理テーブル300は、各ノードでのジョブ処理の実行状況を管理するテーブルなので、次のような項目についてのデータを含む。ノード名の欄にはノードIDのようなノードを一意に識別できる名称のデータを格納する。図3にはノード1及びノード2が代表的に示されている。終了ジョブ割合の欄には各ノードでの現時点で処理したタスクの割合を示すデータを格納する。各ノードではタスクが一つ一つ処理されるので、タスクを処理するたびに処理されたタスク数をカウントしてジョブの全タスク数と比較することにより、終了ジョブ割合は算出され得る。図3の(A)に示されるように、ジョブ実行開始直後の所定時間にノード1では2%のタスクが終了し、ノード2ではタスクの処理はまだ行われていない。しかし、図3の(B)に示されるように、ノード1でのジョブの分割と移動後には、ノード1では3%のタスクが終了し、ノード2では1%のタスクが終了している。リソース使用率の欄には各ノードでのCPU、メモリ等計算機資源の使用率のデータを格納する。各ノードのOSコマンド(UNIX(R)であればvmstat等)を利用することにより、リソース使用率のデータを取得することができる。ジョブ実行開始直後の所定時間にノード1では80%のリソースが使用されている。しかし、ノード1でのタスクの分割と移動後にはノード1では50%のリソースが使用され、ノード2では60%のリソースが使用されている。移動先ノードリストの欄には各ノードから他ノードへタスクが移動した場合の移動先ノード名のデータを格納する。ノード1でのジョブの分割と移動後にはノード1からノード2へタスクが分割されて移動している。これらの項目のデータは、ノード名の欄を除いて適宜更新される。」

(4)引用文献4に記載されている技術的事項

本願の出願日前に頒布又は電気通信回線を通じて公衆に利用可能となった、特表2007-529812号公報(平成19年10月25日公表、以下、「引用文献4」という。)には、以下の技術的事項が記載されている。(当審注:下線は、参考のために当審で付与したものである。)

E 「【0022】
段100では、第1の回路110が入力ビデオ信号(IVS)を受信し、第2の回路120が出力ビデオ信号(OVS)を供給する。調節ループ130が次いで、段100に関連付けられる。段100では、第3の回路30(PM(進捗測定の略))によって、進捗と呼ばれ、入力信号の処理データの数と、割り当て期間(例えば、フレーム期間)において処理されなければならない総データ量との比によって実際に定められる表現を測定することが可能になる。上記回路30は例えば、示標ｐを供給することができる。更に段100では、第4の回路(RM(リソース測定の略))によって、少なくとも1つの、メディア特有の使用リソースを測定することが可能になる。上記回路40は、処理アルゴリズムによって使用される、実際の、蓄積されるリソース数である数Rｒを供給する。回路30の出力信号ｐは第5の回路50(ERC(「期待リソース利用度」の算出の略))によって受信され、回路40の出力信号Rｒは第6の回路60(RDC(「リソース偏差算出」の略))によって受信される。回路30及び40は、測定期間の開始時にリセットするための入力RESETを有する。」

2.対比

本願発明と引用発明とを対比する。

(1)引用発明の「それぞれアプリケーションタスクを実行する複数のプロセッサと、プロセッサの進捗状況を把握し、リソース制御するリソースコントローラとからなる、マルチプロセッサシステムのリソース制御方法」において、リソース制御の際に何らかのリソース量の計算を行うことは自明であり、またリソースを「制御」することはリソースを「管理」するものであるとも言えるから、引用発明は本願発明と「アプリケーションを実行する複数のサーバと、サーバにおけるリソース量の計算を行うリソース管理装置と、を備える計算機システムのリソース管理方法」において共通するものである。

(2)引用発明の「遅れの深刻さや、終了までの残り時間と残った処理量との対比から進捗状況を把握」することは、本願発明と「(サーバにおける)処理の進捗状況を算出する」点において共通するものである。

(3)引用発明の「遅れがより顕著なプロセッサに割り当てるリソースを変化させる」ことは、本願発明と「アプリケーションを実行するサーバに割り当てるリソースを変化させる」点において共通するものである。

よって、本願発明と引用発明とは、以下の点で一致し、また、以下の点で相違する。

(一致点)
「アプリケーションを実行する複数のサーバと、サーバにおけるリソース量の計算を行うリソース管理装置と、を備える計算機システムのリソース管理方法において、
サーバにおける処理の進捗状況を算出し、
アプリケーションを実行するサーバに割り当てるリソースを変化させる、
ことを特徴とする方法。」

(相違点1)
本願発明では、実行物理サーバに仮想的に複数の実行仮想サーバを割り当てているのに対し、引用発明には仮想サーバに関する言及がない点。

(相違点2)
本願発明は「各バッチアプリケーションの処理データ件数であるロット毎に処理履歴を管理し、所定の契機で、ロット単位の前記処理履歴をグルーピング」するのに対し、引用発明には、処理データ件数であるロット毎に処理履歴を管理すること、さらにロット単位の処理履歴をグルーピングする点について、言及がない点。

(相違点3)
本願発明は「処理対象となっている前記バッチアプリケーションについて、現在までに完了している前記ロットの件数を、当該バッチアプリケーションが行なう、すべての前記ロットの件数で除算した処理進捗率と、要求処理時間内に前記バッチアプリケーションを終了するため、現在までに行なわれているべき処理の進捗率である必要進捗率と、を前記バッチアプリケーション毎に算出」するのに対し、引用発明には、「遅れの深刻さや、終了までの残り時間と残った処理量との対比から進捗状況を把握」するとの記載はあるものの、「管理用している前記ロットの件数を・・・すべての前記ロットの件数で除算した処理進捗率」及び「現在までに行なわれているべき処理の進捗率である必要進捗率」の算出について言及されていない点。

(相違点4)
本願発明は「前記必要進捗率に達していない前記バッチアプリケーションがある場合、前記必要進捗率および前記処理進捗率を基に、当該バッチアプリケーションについて、前記要求処理時間内の将来の所定時刻までに完了していると推定される前記ロットの件数を、当該バッチアプリケーションが行なう、すべての前記ロットの件数で除算した推定処理進捗率が、前記将来の所定時刻において行なわれているべき処理の進捗率である推定必要進捗率に達するために必要な前記リソース量を算出」するのに対し、
引用発明には「推定処理進捗率」及び「推定必要進捗率」について言及がない点。

3.判断

上記相違点について検討する。

(1)相違点1について
仮想計算機は周知技術にすぎないから、引用発明のマルチプロセッサシステムに周知の仮想計算機の技術を適用することは、当業者が必要に応じて適宜なし得たものである。

(2)相違点2について
引用発明では、処理データ件数であるロット毎に処理履歴を管理すること、さらにロット単位の処理履歴をグルーピングする点について言及がない点で、本願発明と相違することは上記のとおりである。
しかしながら、引用文献2乃至4には、処理データ件数であるロット毎に処理履歴を管理すること、ロット単位の処理履歴をグルーピングする点については何ら記載されておらず、引用発明のマルチプロセッサシステムのリソース制御方法に適用する動機付けも見い出すことができないから、これを当業者が容易に想到し得たものとはいえない。

(3)相違点3について
引用発明では、「管理用している前記ロットの件数を・・・すべての前記ロットの件数で除算した処理進捗率」及び「現在までに行なわれているべき処理の進捗率である必要進捗率」の算出について言及されていない点で、本願発明と相違することは上記のとおりである。
引用文献2には、上記Cのとおり、ループカウンタ値を総ループ回数で除算した結果を、進捗度とすることが記載されている。
また、引用文献3には、上記Dのとおり、処理されたタスク数をカウントしてジョブの全タスクと比較することにより、終了ジョブ割合を算出することが記載されている。
また、引用文献4には、上記Eのとおり、処理データの数と総データ量との比を進捗としていることが記載されている。
しかしながら、引用文献2乃至4には、ロットの件数を用いて処理進捗率を算出すること、また必要進捗率を算出することについては何ら記載されておらず、引用発明のマルチプロセッサシステムのリソース制御方法に適用する動機付けも見い出すことができないから、これを当業者が容易に想到し得たものとはいえない。

(4)相違点4について
引用発明では、「推定処理進捗率」及び「推定必要進捗率」について言及されていない点で、本願発明と相違することは上記のとおりである。
そして、引用文献2乃至4にも、「推定処理進捗率」及び「推定必要進捗率」については何ら記載されておらず、引用発明のマルチプロセッサシステムのリソース制御方法に適用する動機付けも見い出すことができないから、これを当業者が容易に想到し得たものとはいえない。

4.まとめ

以上のとおりであるから、本願発明は、引用発明及び引用文献2-4に記載の技術的事項に基づいて、当業者が容易に発明をすることができたとはいえない。

5.請求項2乃至15に係る発明について

本願の請求項2-9に係る発明は,本願発明をさらに限定したものであるから、本願発明と同様に、当業者が容易に発明をすることができたとはいえない。
また、本願の請求項10に係る発明は,請求項1に係る発明をシステムの発明として記載したものであり、請求項11-12に係る発明は請求項10に係る発明をさらに限定したものであるから、本願発明と同様に、当業者が容易に発明をすることができたとはいえない。
本願の請求項13に係る発明も,請求項1に係る発明をプログラムの発明として記載したものであり、請求項14-15に係る発明は、請求項13に係る発明をさらに限定したものであるから、本願発明と同様に、当業者が容易に発明をすることができたとはいえない。

第5 むすび

以上のとおり、本願の請求項1-15に係る発明は、いずれも、当業者が引用発明及び引用文献2-4に記載の技術的事項に基づいて容易に発明をすることができたものではないから、原査定の理由によっては、本願を拒絶することはできない。
また、他に拒絶すべき理由を発見しない。

よって、結論のとおり審決する。
 
審決日 2015-08-18 
出願番号 特願2012-514658(P2012-514658)
審決分類 P 1 8・ 121- WY (G06F)
最終処分 成立  
前審関与審査官 井上 宏一  
特許庁審判長 高木 進
特許庁審判官 辻本 泰隆
浜岸 広明
発明の名称 リソース管理方法、計算機システムおよびプログラム  
復代理人 多田 悦夫  
代理人 磯野 道造  

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