ポートフォリオを新規に作成して保存 |
|
|
既存のポートフォリオに追加保存 |
|
PDFをダウンロード |
審決分類 |
審判 査定不服 2項進歩性 特許、登録しない。 G06F 審判 査定不服 4項3号特許請求の範囲における誤記の訂正 特許、登録しない。 G06F 審判 査定不服 4号2号請求項の限定的減縮 特許、登録しない。 G06F 審判 査定不服 5項独立特許用件 特許、登録しない。 G06F 審判 査定不服 4項4号特許請求の範囲における明りょうでない記載の釈明 特許、登録しない。 G06F 審判 査定不服 4項1号請求項の削除 特許、登録しない。 G06F |
---|---|
管理番号 | 1312340 |
審判番号 | 不服2015-2406 |
総通号数 | 197 |
発行国 | 日本国特許庁(JP) |
公報種別 | 特許審決公報 |
発行日 | 2016-05-27 |
種別 | 拒絶査定不服の審決 |
審判請求日 | 2015-02-06 |
確定日 | 2016-03-09 |
事件の表示 | 特願2013-502763「共有リソースに対する認定要求レートの管理」拒絶査定不服審判事件〔平成23年10月 6日国際公開、WO2011/123467、平成25年 6月17日国内公表、特表2013-524343〕について、次のとおり審決する。 |
結論 | 本件審判の請求は、成り立たない。 |
理由 |
第1 手続の経緯 本件請求に係る出願(以下「本願」という。)は, 2010年3月29日(以下「優先日」という。)のアメリカ合衆国における出願を基礎とするパリ条約による優先権主張を伴った, 2011年3月29日を国際出願日とする出願であって, 平成24年9月26日付けで特許法第184条の5第1項に規定される書面が提出され, 同日付けで審査請求がなされ, 平成25年12月20日付けで拒絶理由通知(平成26年1月7日発送)がなされ, 平成26年4月7日付けで意見書が提出されるとともに, 同日付けで手続補正がなされ, 同年9月30日付けで拒絶査定(同年10月7日謄本発送・送達)がなされ, 平成27年2月6日付けで審判請求がされるとともに, 同日付けで手続補正がなされたものである。 なお,同年4月17日付けで特許法第164条第3項に定める報告(前置報告)がなされ, 同年6月12日付けで上申書が提出されている。 第2 平成27年2月6日付けの手続補正についての補正却下の決定 [補正却下の決定の結論] 平成27年2月6日付けの手続補正を却下する。 [理由] 1.補正の内容 平成27年2月6日付けの手続補正(以下,「本件補正」という。)の内容は,平成26年4月7日付けの手続補正により補正された特許請求の範囲の請求項1乃至14の記載 「 【請求項1】 共有コンピュータリソースの使用量を調節する,コンピュータが実行する方法であって, ある種類のリソースに関して,顧客に対して保証された1秒あたりの入力/出力操作の認定要求レートに対する要求を受信することであって,前記顧客が,前記ある種類のリソースに対する現在の認定要求レートを有し,前記顧客に対して保証され,かつ,前記顧客によって使用されていない前記ある種類のリソースの容量の一部は,少なくとも一人の別の顧客によって利用可能である,受信することと, 前記認定要求レートが,前記現在の認定要求レートよりも低い場合に,前記顧客のための前記ある種類のリソースの少なくとも1つのインスタンスに対する前記認定要求レートを減少させることと, 前記要求が,前記認定要求レートを増加させることに関連する場合に,前記認定要求レートを得るために,前記ある種類のリソースの少なくとも1つのインスタンスの利用可能な認定可能レート容量の少なくとも一部分を認定することと, 前記顧客に対する要求対処のレートの管理における使用のために,前記顧客に対する前記認定要求レートの情報を記憶することと,を含む方法。 【請求項2】 前記認定要求レートを減少させることは,より少数のインスタンスが,前記認定要求レートを提供するために利用可能な場合に,前記ある種類のリソースのインスタンス数を減少させて,前記顧客に前記認定要求レートを提供することを含む,請求項1に記載の方法。 【請求項3】 前記認定要求レートを増加させるか,または減少させることは,前記ある種類のリソースの異なるインスタンスによって,前記顧客に前記認定要求レートを提供することを含む,請求項1に記載の方法。 【請求項4】 前記少なくとも1つのインスタンスが,さらに,前記インスタンスに対する要求容量が追加のユーザを許容する場合,前記追加のユーザに前記リソースを共有させる能力がある,請求項1に記載の方法。 【請求項5】 ある種類のリソースに対する前記認定要求レートは,データサーバに対する1秒あたりの入力/出力操作(IOPS)の認定レートである,請求項1に記載の方法。 【請求項6】 それぞれのインスタンスは,複数の顧客に対する認定要求レートをサポートする能力があり,それぞれのインスタンスは,さらに,認定要求レートを有しない追加の顧客に対する要求をサポートする能力がある,請求項1に記載の方法。 【請求項7】 共有コンピュータリソースの使用量を調節するためのシステムであって, 少なくとも1つのプロセッサと, 前記少なくとも1つのプロセッサによって実行される際に,前記システムに, ある種類のリソースに関して,顧客に対して保証された1秒あたりの入力/出力操作の認定レートに対する要求を受信することであって,前記顧客が,前記ある種類のリソースに対する現在の認定レートを有し,前記顧客に対して保証され,かつ,前記顧客によって使用されていない前記ある種類のリソースの容量の一部は,少なくとも一人の別の顧客によって利用可能である,受信することと 前記認定レートが,前記現在の認定レートよりも低い場合に,前記顧客のための前記ある種類のリソースの少なくとも1つのインスタンスに対する前記認定レートを減少させることと, 前記要求が,前記認定レートを増加させることに関連する場合に,前記認定レートを得るために,前記ある種類のリソースの少なくとも1つのインスタンスの利用可能な認定可能レート容量の少なくとも一部分を認定することと, 前記顧客に対する要求対処のレートの管理における使用のために,前記顧客に対する前記認定レートの情報を記憶することと,を行わせる命令を含む,メモリと,を備えるシステム。 【請求項8】 前記認定レートを減少させることは,より少数のインスタンスが,前記認定レートを提供するために利用可能な場合に,前記ある種類のリソースのインスタンス数を減少させて,前記顧客に前記認定レートを提供することを含み, 前記認定レートを増加させるか,または減少させることは,前記ある種類のリソースの異なるインスタンスによって,前記顧客に前記認定レートを提供することを含む,請求項7に記載のシステム。 【請求項9】 共有コンピュータリソースの使用量を管理する,コンピュータが実行する方法であって, ある種類のリソースに対する,1秒あたりの入力/出力操作の認定使用レートの要求を受信することと, 前記要求された認定使用レートの少なくとも一部分を提供するように動作可能な前記ある種類のリソースの少なくとも1つのインスタンスを判定することと, 前記認定使用レートを提供する能力があると判定された少なくとも1つのインスタンスに,前記要求された認定使用レートの少なくとも一部分を割り付けることと,を含み, 前記少なくとも1つのインスタンスが,さらに,前記インスタンスの使用容量が追加のユーザを許容する場合,前記追加のユーザに前記リソースを共有させる能力がある方法。 【請求項10】 ある種類のリソースに対する前記認定使用レートは,データサーバに対する1秒あたりの入力/出力操作(IOPS)の認定レートである,請求項9に記載の方法。 【請求項11】 前記要求された認定使用レートの少なくとも一部分を提供するように動作可能な前記ある種類のリソースの少なくとも1つのインスタンスを判定することは,他のユーザに対して未認定の,そのインスタンスの前記容量の少なくとも許容可能な一部分を有する,少なくとも1つのインスタンスを判定することを含む,請求項9に記載の方法。 【請求項12】 前記要求に対応する前記認定使用レートを提供する能力があると判定されるインスタンスの組み合わせがない場合に,前記要求が拒否される,請求項9に記載の方法。 【請求項13】 共有コンピュータリソースの使用量を管理するためのシステムであって, 少なくとも1つのプロセッサと, 前記少なくとも1つのプロセッサによって実行される際,前記システムに, ある種類のリソースに対する,1秒あたりの入力/出力操作の認定使用レートの要求を受信することと, 前記要求された認定使用レートの少なくとも一部分を提供するように動作可能な前記ある種類のリソースの少なくとも1つのインスタンスを判定することと, 前記認定使用レートを提供する能力があると判定された少なくとも1つのインスタンスに,前記要求された認定使用レートの少なくとも一部分を割り付けることと,を行わせる命令を含む,メモリと,を備え, 前記少なくとも1つのインスタンスが,さらに,前記インスタンスの使用容量が追加のユーザを許容する場合に,前記追加のユーザに前記リソースを共有させる能力がある,システム。 【請求項14】 前記要求された認定使用レートの少なくとも一部分を提供するように動作可能な前記ある種類のリソースの少なくとも1つのインスタンスの判定することは,他のユーザに対して未認定の,そのインスタンスの前記容量の少なくとも許容可能な一部分を有する,少なくとも1つのインスタンスを判定することを含む,請求項13に記載のシステム。」(以下,この特許請求の範囲に記載された請求項を「補正前の請求項」という。)を, 「 【請求項1】 共有コンピュータリソースの使用量を調節する,コンピュータが実行する方法であって, ある種類のリソースに関して,顧客に対して保証された1秒あたりの入力/出力操作の認定要求レートに対する要求を受信することであって,前記顧客が,前記ある種類のリソースに対する現在の認定要求レートを有し,前記顧客に対して保証され,かつ,前記顧客によって使用されていない前記ある種類のリソースの容量の一部は,少なくとも一人の別の顧客によって利用可能である,受信することと, 前記認定要求レートが,前記現在の認定要求レートよりも低い場合に,前記顧客のための前記ある種類のリソースの少なくとも1つのインスタンスに対する前記認定要求レートを減少させることと, 前記要求が,前記認定要求レートを増加させることに関連する場合に,前記認定要求レートを得るために,前記ある種類のリソースの少なくとも1つのインスタンスの利用可能な認定可能レート容量の少なくとも一部分を認定することと, 前記顧客に対する要求対処のレートの管理における使用のために,前記顧客に対する前記認定要求レートの情報を記憶することと, より少数のインスタンスが前記認定要求レートを提供するために利用可能な場合に,前記より少数のインスタンスに前記認定要求レートを移動させ,統合することと,を含む方法。 【請求項2】 前記認定要求レートを減少させることは,より少数のインスタンスが,前記認定要求レートを提供するために利用可能な場合に,前記ある種類のリソースのインスタンス数を減少させて,前記顧客に前記認定要求レートを提供することを含む,請求項1に記載の方法。 【請求項3】 前記認定要求レートを増加させるか,または減少させることは,前記ある種類のリソースの異なるインスタンスによって,前記顧客に前記認定要求レートを提供することを含む,請求項1に記載の方法。 【請求項4】 前記少なくとも1つのインスタンスが,さらに,前記インスタンスに対する要求容量が追加のユーザを許容する場合,前記追加のユーザに前記リソースを共有させる能力がある,請求項1に記載の方法。 【請求項5】 ある種類のリソースに対する前記認定要求レートは,データサーバに対する1秒あたりの入力/出力操作(IOPS)の認定レートである,請求項1に記載の方法。 【請求項6】 それぞれのインスタンスは,複数の顧客に対する認定要求レートをサポートする能力があり,それぞれのインスタンスは,さらに,認定要求レートを有しない追加の顧客に対する要求をサポートする能力がある,請求項1に記載の方法。 【請求項7】 共有コンピュータリソースの使用量を調節するためのシステムであって, 少なくとも1つのプロセッサと, 前記少なくとも1つのプロセッサによって実行される際に,前記システムに, ある種類のリソースに関して,顧客に対して保証された1秒あたりの入力/出力操作の認定レートに対する要求を受信することであって,前記顧客が,前記ある種類のリソースに対する現在の認定レートを有し,前記顧客に対して保証され,かつ,前記顧客によって使用されていない前記ある種類のリソースの容量の一部は,少なくとも一人の別の顧客によって利用可能である,受信することと 前記認定レートが,前記現在の認定レートよりも低い場合に,前記顧客のための前記ある種類のリソースの少なくとも1つのインスタンスに対する前記認定レートを減少させることと, 前記要求が,前記認定レートを増加させることに関連する場合に,前記認定レートを得るために,前記ある種類のリソースの少なくとも1つのインスタンスの利用可能な認定可能レート容量の少なくとも一部分を認定することと, 前記顧客に対する要求対処のレートの管理における使用のために,前記顧客に対する前記認定レートの情報を記憶することと, より少数のインスタンスが前記認定レートを提供するために利用可能な場合に,前記より少数のインスタンスに前記認定レートを移動させ,統合すること,を行わせる命令を含む,メモリと,を備えるシステム。 【請求項8】 前記認定レートを減少させることは,より少数のインスタンスが,前記認定レートを提供するために利用可能な場合に,前記ある種類のリソースのインスタンス数を減少させて,前記顧客に前記認定レートを提供することを含み, 前記認定レートを増加させるか,または減少させることは,前記ある種類のリソースの異なるインスタンスによって,前記顧客に前記認定レートを提供することを含む,請求項7に記載のシステム。 【請求項9】 共有コンピュータリソースの使用量を管理する,コンピュータが実行する方法であって, ある種類のリソースに対する,1秒あたりの入力/出力操作の認定使用レートの要求を受信することと, 前記要求された認定使用レートの少なくとも一部分を提供するように動作可能な前記ある種類のリソースの少なくとも1つのインスタンスを判定することと, 前記認定使用レートを提供する能力があると判定された少なくとも1つのインスタンスに,前記要求された認定使用レートの少なくとも一部分を割り付けることと, より少数のインスタンスが前記認定使用レートを提供するために利用可能な場合に,前記より少数のインスタンスに前記認定使用レートを移動させ,統合することと,を含み, 前記少なくとも1つのインスタンスが,さらに,前記インスタンスの使用容量が追加のユーザを許容する場合,前記追加のユーザに前記リソースを共有させる能力がある方法。 【請求項10】 ある種類のリソースに対する前記認定使用レートは,データサーバに対する1秒あたりの入力/出力操作(IOPS)の認定レートである,請求項9に記載の方法。 【請求項11】 前記要求された認定使用レートの少なくとも一部分を提供するように動作可能な前記ある種類のリソースの少なくとも1つのインスタンスを判定することは,他のユーザに対して未認定の,そのインスタンスの前記容量の少なくとも許容可能な一部分を有する,少なくとも1つのインスタンスを判定することを含む,請求項9に記載の方法。 【請求項12】 前記要求に対応する前記認定使用レートを提供する能力があると判定されるインスタンスの組み合わせがない場合に,前記要求が拒否される,請求項9に記載の方法。 【請求項13】 共有コンピュータリソースの使用量を管理するためのシステムであって, 少なくとも1つのプロセッサと, 前記少なくとも1つのプロセッサによって実行される際,前記システムに, ある種類のリソースに対する,1秒あたりの入力/出力操作の認定使用レートの要求を受信することと, 前記要求された認定使用レートの少なくとも一部分を提供するように動作可能な前記ある種類のリソースの少なくとも1つのインスタンスを判定することと, 前記認定使用レートを提供する能力があると判定された少なくとも1つのインスタンスに,前記要求された認定使用レートの少なくとも一部分を割り付けることと, より少数のインスタンスが前記認定使用レートを提供するために利用可能な場合に,前記より少数のインスタンスに前記認定使用レートを移動させ,統合すること,を行わせる命令を含む,メモリと,を備え, 前記少なくとも1つのインスタンスが,さらに,前記インスタンスの使用容量が追加のユーザを許容する場合に,前記追加のユーザに前記リソースを共有させる能力がある,システム。 【請求項14】 前記要求された認定使用レートの少なくとも一部分を提供するように動作可能な前記ある種類のリソースの少なくとも1つのインスタンスの判定することは,他のユーザに対して未認定の,そのインスタンスの前記容量の少なくとも許容可能な一部分を有する,少なくとも1つのインスタンスを判定することを含む,請求項13に記載のシステム。」(当審注:下線は,出願人が付与したものである。以下,この特許請求の範囲に記載された請求項を「補正後の請求項」という。)に補正するものである。 そして,本件補正は,特許法184条の4第1項の国際出願日における国際特許出願の明細書,請求の範囲,及び図面(図面の中の説明に限る。)の日本語による翻訳文,又は,国際出願日における国際特許出願の図面(図面の中の説明を除く。)(以下,「翻訳文等」という。)に記載した事項の範囲内においてなされており,特許法第17条の2第3項の規定に適合している。 2.目的要件 本件補正が,特許法17条の2第5項の規定を満たすものであるか否か,すなわち,本件補正が,特許法第17条の2第5項に規定する請求項の削除,特許請求の範囲の減縮(特許法第36条第5項の規定により請求項に記載した発明を特定するために必要な事項を限定するものであって,その補正前の当該請求項に記載された発明とその補正後の当該請求項に記載される発明の産業上の利用分野及び解決しようとする課題が同一であるものに限る),誤記の訂正,或いは,明りょうでない記載の釈明(拒絶理由通知に係る拒絶の理由に示す事項についてするものに限る)の何れかを目的としたものであるかについて,以下に検討する。 (1)本件補正前の請求項と,本件補正後の請求項とを比較すると,本件補正後の請求項1?14は,それぞれ本件補正前の請求項1?14に対応することは明らかである。 ア.本件補正後の請求項1に係る補正は,下記の補正事項1よりなるものである。 <補正事項1> 本件補正前の請求項1の「方法」に 本件補正後の請求項1の「より少数のインスタンスが前記認定要求レートを提供するために利用可能な場合に,前記より少数のインスタンスに前記認定要求レートを移動させ,統合すること」を追加する補正。 イ.本件補正後の請求項7に係る補正は,下記の補正事項2よりなるものである。 <補正事項2> 本件補正前の請求項7の「メモリ」が含む「命令」に, 本件補正後の請求項7の「より少数のインスタンスが前記認定レートを提供するために利用可能な場合に,前記より少数のインスタンスに前記認定レートを移動させ,統合すること」を追加する補正。 ウ.本件補正後の請求項9に係る補正は,下記の補正事項3よりなるものである。 <補正事項3> 本件補正前の請求項9の「方法」に 本件補正後の請求項9の「より少数のインスタンスが前記認定使用レートを提供するために利用可能な場合に,前記より少数のインスタンスに前記認定使用レートを移動させ,統合すること」を追加する補正。 エ.本件補正後の請求項13に係る補正は,下記の補正事項4よりなるものである。 <補正事項4> 本件補正前の請求項13の「メモリ」が含む「命令」に, 本件補正後の請求項13の「より少数のインスタンスが前記認定使用レートを提供するために利用可能な場合に,前記より少数のインスタンスに前記認定使用レートを移動させ,統合すること」を追加する補正。 (2)当審の判断 上記補正事項1が追加する「より少数のインスタンスが前記認定要求レートを提供するために利用可能な場合に,前記より少数のインスタンスに前記認定要求レートを移動させ,統合すること」は, 本件補正前の請求項1が含む,いずれかの処理を限定する補正ではなく, 本件補正前の請求項1に新たな処理を追加する補正であると認められる。 したがって,上記補正事項1は,補正前の請求項1に記載した発明を特定するために必要な事項を限定したものではなく,特許法第17条の2第5項第2号の特許請求の範囲の減縮を目的とするものとは認められない。 また,上記補正事項1-1の目的が,特許法第17条の2第5項第1号の請求項の削除,第3号の誤記の訂正,第4号の明りょうでない記載の釈明に該当するものとも認められない。 補正事項2?4についても同様である。 (3)小括 上記補正事項1?4について検討したように,本件補正は,特許法第184条の12第2項により読み替える同法第17条の2第5項各号に掲げる事項を目的とするものに限られるものではない。 3.独立特許要件 以上のように,本件補正は,特許法第17条の2第5項各号に掲げる事項を目的とするものに限られるものではないものの,仮に,本件補正が,限定的減縮を目的とするものであったとして, 本件補正後の請求項1?14に記載された発明が特許出願の際独立して特許を受けることができるものであるか(特許法第17条の2第6項において準用する同法第126条第7項の規定に適合するか)以下に検討する。 3-1.特許法第36条第6項第2号について (1)請求項1?8 本件補正後の請求項1に記載の「より少数のインスタンスが前記認定要求レートを提供するために利用可能な場合に,前記より少数のインスタンスに前記認定要求レートを移動させ,統合すること」について, 「前記認定要求レート」が,前記されている何れの「認定要求レート」を指すのか不明確である。 例えば,受信された又は要求された「認定要求レート」を意味するのか,「現在の認定要求レート」を意味するのか特定されていない。 発明カテゴリを変更した請求項7に係る発明の「前記認定レート」についても同様である。 請求項1,7を引用する請求項2?6,8についても同様である。 よって,本件補正後の請求項1?8に係る発明は明確でない。 (2)請求項1?14 本件補正後の請求項1に記載の「より少数のインスタンスが前記認定要求レートを提供するために利用可能な場合に,前記より少数のインスタンスに前記認定要求レートを移動させ,統合すること」について, 「前記認定要求レート」の「移動」が,具体的にどのような処理を意味するのか不明確である。 例えば,「前記認定要求レート」が,要求時に最初から「より少数のインスタンス」を「判定」して「割り付ける」処理を意味するのか, 受信された「前記認定要求レート」の「要求された認定要求レート」をいずれかのインスタンスに一度割り付けた直後に割り付け先のインスタンスを変更することを意味するのか, 現在の要求ではなく,過去の要求の「認定要求レート」に割り付け先のインスタンスを変更してから現在の要求の「認定要求レート」を反映することを意味するのか不明であり,移動処理の対象や具体的手順が明確でない。 請求項7の「前記認定レート」の「移動」及び請求項9,13の「前記認定使用レート」の「移動」についても同様である。 請求項1,7,9,13を引用する請求項2?6,8,10?12,14についても同様である。 よって,本件補正後の請求項1?14に係る発明は明確でない。 (3)請求項1?14 本件補正後の請求項1に記載の「より少数のインスタンスが前記認定要求レートを提供するために利用可能な場合」について, 当該場合であることを,具体的にどのような手順で判定するのか不明確である。 請求項7の「より少数のインスタンスが前記認定レートを提供するために利用可能な場合」及び請求項9,13の「より少数のインスタンスが前記認定使用レートを提供するために利用可能な場合」についても同様である。 請求項1,7,9,13を引用する請求項2?6,8,10?12,14についても同様である。 よって,本件補正後の請求項1?14に係る発明は明確でない。 (4)よって,本件補正後の特許請求の範囲の記載は,特許法第36条第6項第2号に規定する要件を満たしておらず,本件補正後の請求項1?14に係る発明は,特許出願の際独立して特許を受けることができないものである。 3-2.特許法第29条第2項について (1)本件補正発明 上記「3-1.特許法第36条第6項第2号について」で検討したように,本件補正後の請求項1?14に係る発明は明確でないものの,仮に,本件補正後の請求項1?14に記載のとおりのものとして,以下の検討を行う。 本件補正発明は,上記平成27年2月6日付け手続補正書により補正された特許請求の範囲の請求項9に記載された以下のとおりのものと認める。 「共有コンピュータリソースの使用量を管理する,コンピュータが実行する方法であって, ある種類のリソースに対する,1秒あたりの入力/出力操作の認定使用レートの要求を受信することと, 前記要求された認定使用レートの少なくとも一部分を提供するように動作可能な前記ある種類のリソースの少なくとも1つのインスタンスを判定することと, 前記認定使用レートを提供する能力があると判定された少なくとも1つのインスタンスに,前記要求された認定使用レートの少なくとも一部分を割り付けることと, より少数のインスタンスが前記認定使用レートを提供するために利用可能な場合に,前記より少数のインスタンスに前記認定使用レートを移動させ,統合することと,を含み, 前記少なくとも1つのインスタンスが,さらに,前記インスタンスの使用容量が追加のユーザを許容する場合,前記追加のユーザに前記リソースを共有させる能力がある方法。」 (2)引用文献 ア.引用文献1に記載されている技術的事項及び引用発明 本願優先日前に頒布され,原審の拒絶査定の理由である上記平成25年12月20日付けの拒絶理由通知(以下,「原審拒絶理由」という。)において引用された,特開2002-24192号公報(平成14年1月25日出願公開,以下,「引用文献1」という。)には,関連する図面とともに,以下の技術的事項が記載されている。 (当審注:下線は,参考のために当審で付与したものである。) A.「【0006】ASP,ISP(インターネット・サービス・プロバイダ)業者とユーザの間ではサービスレベル契約を結ぶことが一般的になりつつある。接続性,可用性,レイテンシ性能などのサービスレベル保証を契約する。さらに保証レベル未達の場合の補償契約を結ぶ形態も多い。 ・・・(中略)・・・ 【0009】 【課題を解決するための手段】上記を解決するため,本発明では,データセンタの計算機資源およびストレージ資源をユーザ負荷変動に基づきリアルタイムにユーザ企業ごとに分割割当てする資源分割手段および方法を提供する。」 B.「【0030】図4は管理サーバC0の構成図である。T19はユーザ識別表であり,制御プログラムP20が図22のユーザ条件入力画面に基づき設定する。T20はユーザごとのサービスレベル契約内容表であり,制御プログラムP20が図23のサービスレベル条件入力画面に基づき設定する。この場合,ユーザ識別子#0のユーザに対してはwebサーバ,APサーバ,DBサーバいずれも最低2台を与え,与えたすべてのサーバでCPU稼働率50%未満でプログラムを動作させ,それに違反しそうな場合は8台まではサーバ数を増加する契約となっている。またユーザ識別子#1のユーザに対しては,webサーバ,APサーバ,DBサーバいずれも最低2台を与え,データセンタのからのアクセス返答スループットは秒あたり30件以上を維持し,それに違反しそうな場合は6台まではサーバ数を増加する契約となっている。制御プログラムP20はモニタリング結果とサービスレベル契約内容表T20を照合し,現在の資源割当てがサービスレベル契約を満たしているかを調べ,その結果をサービス履歴格納表T21に格納する。サービス履歴格納表T21には,たとえばユーザ識別子#0に与えたすべてのサーバのCPU稼働率履歴を記録する。制御プログラムP20はモニタリング結果がサービスレベル契約を満たしていない場合は,割当てサーバを増やす。そのためにどのユーザにどのサーバを与えたかを示すサーバ割当て管理表T22や,ユーザアプリケーションで認識しているサーバ名と与えた実サーバの対応表であるサーバアドレス対応表T23を保持している。・・・(後略)・・・」 C.「【0036】続いて以下に,制御プログラムP20が負荷増大時に資源割当てを変更する手順を図8を用いて説明する。 【0037】前述したように信号線L100,200,300,0を介してシステムの稼動情報をモニタし(1301),ユーザ識別子ごとに稼動情報を集計してサービス履歴格納表T21に格納し(1302),サービスレベル契約内容表T20と比較した後(1303),まずサービスレベル契約に照らしてサーバを削減できないか検討する(1304)。削減可能かどうかの判断方法としては,CPU稼働率とサーバ台数の積に対して比例計算を行う方法が挙げられる。たとえばユーザ#0のサービスレベル条件はCPU稼働率50%未満であるが,現在4台がwebサーバとして与えられており,いずれもCPU稼働率が25%未満であれば,単純な比例計算としてはwebサーバ数を2台まで削減してよいと判断できる。実際はこれに経験から与えられる種種の安全計数を掛けて判断する。削減可能であれば,削減対象であるサーバへの処理停止指示を信号線L100,200,300のいずれかを介して通知する。通知されたサーバはプログラムの処理を終了して,使用している資源を解放する。・・・(後略)・・・」 D.「【0038】図8の説明に戻ると,つづいてサーバ数を増強する必要があるかを検討する(1306)。何台増強すべきかの判断は,削減時と同様に比例計算で行えばよい。増強する必要があれば,webサーバ,APサーバ,DBサーバ群ごとに割り当てられる空きサーバがあるかをサーバ割当て管理表T22を参照して調査する(1307)。もし空きサーバがなければ運用管理者に通知する(1308)。空きサーバがあれば割当てサーバを選択し(1309),負荷分散装置d100?d300にサーバアドレス対応表T30?T32の変更を指示する。・・・(後略)・・・」 E.「【0067】 【発明の効果】以上述べたように,本発明ではユーザ企業ごとにユーザ識別子を与え,それに基づき計算資源を与えるとともに,計算機の稼動状況のモニタ結果に基づき自動的にユーザ識別子ごとにサービスレベル契約と比較して計算資源の量を増減できる。・・・(後略)・・・」 ここで,上記引用文献1に記載されている事項を検討する。 (ア)上記Aの「本発明では,データセンタの計算機資源およびストレージ資源をユーザ負荷変動に基づきリアルタイムにユーザ企業ごとに分割割当てする資源分割手段および方法を提供する。」との記載,上記Eの「本発明ではユーザ企業ごとにユーザ識別子を与え,それに基づき計算資源を与えるとともに,計算機の稼動状況のモニタ結果に基づき自動的にユーザ識別子ごとにサービスレベル契約と比較して計算資源の量を増減できる。」との記載,上記Bの「図4は管理サーバC0の構成図である。」,「そのためにどのユーザにどのサーバを与えたかを示すサーバ割当て管理表T22や,ユーザアプリケーションで認識しているサーバ名と与えた実サーバの対応表であるサーバアドレス対応表T23を保持している。」との記載からすると, 引用文献1に記載の「管理サーバ」は,ユーザごとのデータセンタの資源の量を増減し管理するものといえることから, 引用文献1には, “データセンタの資源の量を管理サーバにより管理する方法” が記載されていると解される。 (イ)上記Aの「ASP,ISP(インターネット・サービス・プロバイダ)業者とユーザの間ではサービスレベル契約を結ぶことが一般的になりつつある。接続性,可用性,レイテンシ性能などのサービスレベル保証を契約する。」との記載,上記Bの「図4は管理サーバC0の構成図である。」,「T20はユーザごとのサービスレベル契約内容表であり,制御プログラムP20が図23のサービスレベル条件入力画面に基づき設定する。」,「またユーザ識別子#1のユーザに対しては,webサーバ,APサーバ,DBサーバいずれも最低2台を与え,データセンタのからのアクセス返答スループットは秒あたり30件以上を維持し,それに違反しそうな場合は6台まではサーバ数を増加する契約となっている。」,「制御プログラムP20はモニタリング結果がサービスレベル契約を満たしていない場合は,割当てサーバを増やす。そのためにどのユーザにどのサーバを与えたかを示すサーバ割当て管理表T22や,ユーザアプリケーションで認識しているサーバ名と与えた実サーバの対応表であるサーバアドレス対応表T23を保持している。」との記載からすると, 制御プログラムは,サービスレベル条件入力画面を介して,サーバ数や秒あたりのアクセス件数(スループット)等の保証を示すサービスレベル条件が入力されているから, 引用文献1には, “ユーザに資源の量を保証する,秒あたりのアクセス件数を含むサービスレベル条件を入力されること” が記載されているといえる。 (ウ)上記Bの「またユーザ識別子#1のユーザに対しては,webサーバ,APサーバ,DBサーバいずれも最低2台を与え,データセンタのからのアクセス返答スループットは秒あたり30件以上を維持し,それに違反しそうな場合は6台まではサーバ数を増加する契約となっている。」,「制御プログラムP20はモニタリング結果がサービスレベル契約を満たしていない場合は,割当てサーバを増やす。」との記載,上記Dの「つづいてサーバ数を増強する必要があるかを検討する(1306)。何台増強すべきかの判断は,削減時と同様に比例計算で行えばよい。増強する必要があれば,webサーバ,APサーバ,DBサーバ群ごとに割り当てられる空きサーバがあるかをサーバ割当て管理表T22を参照して調査する(1307)。もし空きサーバがなければ運用管理者に通知する(1308)。空きサーバがあれば割当てサーバを選択し」との記載からすると, 引用文献1には, “前記入力されたサービスレベル条件を満たすための空きサーバがあれば,割当てサーバとして選択すること” が記載されているといえる。 (エ)上記Cの「ユーザ識別子ごとに稼動情報を集計してサービス履歴格納表T21に格納し(1302),サービスレベル契約内容表T20と比較した後(1303),まずサービスレベル契約に照らしてサーバを削減できないか検討する」,「たとえばユーザ#0のサービスレベル条件はCPU稼働率50%未満であるが,現在4台がwebサーバとして与えられており,いずれもCPU稼働率が25%未満であれば,単純な比例計算としてはwebサーバ数を2台まで削減してよいと判断できる。」,「削減可能であれば,削減対象であるサーバへの処理停止指示を信号線L100,200,300のいずれかを介して通知する。通知されたサーバはプログラムの処理を終了して,使用している資源を解放する」との記載からすると, 引用文献1には, “前記入力されたサービスレベル条件を満たす範囲で,サーバ数を削減できないか判断し,削減できる場合,削減されるサーバが使用している資源を解放してサーバ数を削減すること” が記載されているといえる。 (オ)以上,(ア)?(エ)で指摘した事項から,引用文献1には,次の発明(以下,「引用発明」という。)が記載されているものと認める。 「データセンタの資源の量を管理サーバにより管理する方法であって, ユーザに資源の量を保証する,秒あたりのアクセス件数を含むサービスレベル条件を入力されることと, 前記入力されたサービスレベル条件を満たすための空きサーバがあれば,割当てサーバとして選択することと, 前記入力されたサービスレベル条件を満たす範囲で,サーバ数を削減できないか判断し,削減できる場合,削減されるサーバが使用している資源を解放してサーバ数を削減することと, を含む方法」 イ.引用文献2に記載されている技術的事項 本願優先日前に頒布され,原審拒絶理由において引用された,特開2004-355638号公報(平成16年12月16日出願公開,以下,「引用文献2」という。)には,関連する図面とともに,以下の技術的事項が記載されている。(当審注:下線は,参考のために当審で付与したものである。) F.「【0079】 この処理は,ホスト計算機1′を使用するユーザ,またはホスト計算機1′で稼動するアプリケーションプログラムなどが新規にファイル領域を必要とするときに実施される。 【0080】 クライアントプログラム11′は,ユーザ,またはアプリケーションプログラムからの要求に応じて必要とするデバイスについての情報の指定を受け付ける。ここで取得する情報には,図4に示した第1の実施形態におけるステップ1001と同様に,必要とするデバイスの容量,性能条件,信頼性レベルなどの情報が含まれる(ステップ2001)。 【0081】 次に,クライアントプログラム11′は,ステップ2001で指定された容量,性能条件,信頼性レベルなどの情報を管理マネージャ93に送信し,新たなファイルシステムの領域を要求する。管理マネージャ93は,クライアントプログラム11′から受け取った情報に基づいて,割り当てることのできるデバイスの領域を検索して用意し,その結果をクライアントプログラム11′に返却する。このとき行われる管理マネージャ93の処理については後述する(ステップ2002)。」 ウ.引用文献3に記載されている技術的事項 本願優先日前に頒布され,原審拒絶理由において引用された,特開2008-293283号公報(平成20年12月4日出願公開,以下,「引用文献3」という。)には,関連する図面とともに,以下の技術的事項が記載されている。(当審注:下線は,参考のために当審で付与したものである。) G.「【0021】 図3は,本実施形態のコンピュータリソース管理支援システムのリソース割当部114における「リソース割当処理」(サブルーチン)の処理の流れを示すフローチャート図である。 以下,図9を参照しながら,図3に示すフローチャート図を用いてリソース割当部114における「リソース割当処理」(サブルーチン)の動作を説明する。なお,以後は,リソース割当処理及びリソース回収処理については図9を参照するが,後述するとおり,図9はリソースとして捉えられる各種の資源のうち,一例としてメモリについてその管理イメージを例示するものである。各々のリソースは個別に管理され,その管理方法は既存の技術を利用することができる。 ・・・(中略)・・・ 【0023】 ・・・(中略)・・・ ステップS23では,制御部は,利用可能リソースに余裕があるか判断する。より具体的には「未使用リソース量」>割当リソース量が成立していれば,利用可能リソースに余裕有りと判断されてステップS24に移り,さもなくて,「未使用リソース量」>割当リソース量が成立していなければ,利用可能リソースに余裕無しと判断されてステップS27に移る。 【0024】 ステップS24では,利用可能リソースに余裕がある場合の処理として,リソースを割り当て(図9(b)参照), ・・・(中略)・・・ ステップS27では,利用可能リソースに余裕が無い場合の処理として,回収済みであることを示す「回収済みFLG(フラグ)」がONか否かを検証し,「回収済みFLG(フラグ)」がONではない場合はステップS29に移り,「回収済みFLG(フラグ)」がONの場合はステップS28に進む。なお,初回は,「回収済みFLG(フラグ)」がONではない場合としてステップS29以下の処理を行うことになる。 【0025】 ステップS29では,「回収済みFLG(フラグ)」がONではない場合の処理として,「緊急フラグ」をONに設定し,次のステップS30にて,一斉回収部1152の「一斉回収処理」(図5に示すサブルーチン)を呼び出し,このサブルーチンでの処理を行った後,ステップS23以下の一連の処理に戻って,利用可能リソースの判断処理を続行する。 ・・・(後略)・・・」 H 「【0017】・・・(中略)・・・個別AP情報としては,ここでは,顧客名,システム名称,サービスレベル,料金単価,ミニマムリソース値,等のデータ項目を登録するものとする。なお,ミニマムリソース値については,事前稼動確認により設定しておくものとする。 ・・・(中略)・・・ 【0034】 図8は,本実施形態のコンピュータリソース管理支援システムのリソース割当部114が参照するSLA情報テーブルの1構成例を示す説明図である。 このSLA情報テーブルは,リソース割当部114の低サービスレベル用割当処理部1142と,リソース回収部115の一斉回収処理部1152と,が参照する個別AP情報であり,個別AP情報登録部1132によって作成され,個別AP情報DB13に登録される。」 I.「【0035】 図9は,仮想リソースプール40の1例としてのメモリイメージを示す説明図である。 図9(a)は,AP(ここではA?F)に割り当てられる最低限のリソースを示し,図9(b)は,空きリソース(即ち未使用リソース)に余裕が有る場合に,AP(ここではA?F)の各々の必要に応じてリソースが追加的に割り当てられるイメージを示し,図9(c)は,AP(ここではA?F)の各々の必要に応じてリソースが次々と追加的に割り当てられた状態のイメージを示すものであるが,同時に,図9(c)は,空きリソース(即ち未使用リソース)に余裕が無くなった場合に,APのAに対して追加リソースを割り当てるために,APのB?Fには追加割当を行わず,リソースを強制開放してAPのAに融通するイメージをも示している。」 エ.引用文献4に記載されている技術的事項 本願優先日前に頒布された特開2010-33292号公報(平成22年2月12日出願公開,以下,「引用文献4」という。)には,関連する図面とともに,以下の技術的事項が記載されている。(当審注:下線は,参考のために当審で付与したものである。) J.「【0028】 次に,仮想サーバリソース調整システムの動作概要について説明する。 図5?8は,高負荷発生時の仮想サーバリソース調整システムの動作概要を示す図である。 図5は,負荷がかかっていない仮想サーバ群からの空きリソース削減についての動作概要を示す図である。同図において,リソース調整装置1が,仮想サーバ群αに所属する仮想サーバAに高負荷が発生したことを検出したとする。リソース調整装置1は,仮想サーバ群αに所属する仮想サーバA,B,H以外の仮想サーバAA,BB,・・・,HHそれぞれについて,現在割当てられているリソース量から削減可能なリソース量である空きリソース量を算出し,この算出した各空きリソース量を合計して総空きリソース量URを算出する。リソース調整装置1は,総空きリソース量URを算出したのち,各仮想サーバから削減するリソース量を,当該仮想サーバが所属する仮想サーバ群にスケールアウト方式またはスケールアップ方式のいずれが採用されているかのリソース方式と,各仮想サーバの役割とに基づいて決定する。」 K.「【0033】 図9は,低負荷検出時の仮想サーバリソース調整システムの動作概要を示す図である。リソース調整装置1は,仮想サーバの低負荷状態を検出した場合,物理サーバ3の仮想サーバ配置状況の適正化と仮想サーバ群毎のリソース配分方式に沿ったリソースの適正化のために,低負荷が検出された仮想サーバ群全体の空きリソースを計算して,全仮想サーバを対象にした再配置や,仮想サーバ群毎のリソース配分方式に沿ったリソース調整を行う。 【0034】 例えば,リソース調整装置1が,仮想サーバ群αに所属する仮想サーバAの低負荷を検出した場合,仮想サーバ群αに所属する全仮想サーバA,B,Hそれぞれについて削減可能なリソース量である空きリソース量を算出し,この算出した各空きリソース量を合計して総空きリソース量を算出する。リソース調整装置1は,当該仮想サーバ群αにスケールアウト方式またはスケールアップ方式のうちいずれが採用されているかのリソース配分方式と,仮想サーバ群αに所属する仮想サーバA,B,Hの役割とに基づいて,合計が総空きリソース量となるように,リソースを削減すべき仮想サーバと,その仮想サーバにおいて削減するリソース量とを決定し,リソースを削減する。リソース調整装置1は,全仮想サーバを対象にして,全物理サーバ3上への再配置を決定し,物理サーバ3-1?3-n間で仮想サーバを稼動させながら移動して配置する。ここでは,物理サーバ3-nに配置されている仮想サーバHが物理サーバ3-1に,仮想サーバHHが物理サーバ3-2にそれぞれ配置され,物理サーバ3-nは仮想サーバが配置されていない状態になり,電源OFFが可能となる。」 L.「【0037】 なお,各種リソースとしてはCPU(Central Processing Unit),メモリ,ディスクI/O,ネットワークI/Oなどを用いるものとする。また,リソースの総合的な消費状況を表す指標となるスループット(単位時間当たりの処理件数)を,リソースの一種として用いる。なお,異なる物理サーバ3間においてもリソースの増減量を標準的に扱うため,各種リソースのリソース使用量の単位は標準化する。具体的には,CPUはコアやCPU数を考慮した総周波数を用いてHz(ヘルツ)単位で,メモリはメモリサイズとしてByte(バイト)単位で,ディスクI/Oはbps(bits per second)またはIOPS(Input Output per Second)単位で,ネットワークI/Oはbpsまたはpps(Packet Per Second)単位で扱うものとする。」 M.「【0061】 図23は,空きリソース量の算出について説明するための図である。 空きリソース計算部13は,負荷状況表記憶部21に記憶されている負荷状況表から,通常負荷群所属仮想サーバIDに対応した各種リソースの使用量及びアクセス負荷の情報を読み出し,さらに,閾値表記憶部23に記憶されている閾値表から,当該通常負荷群所属仮想サーバIDに対応したリソースID及び高負荷閾値の組みの情報を読み出すと,リソース毎にリソース使用量と高負荷閾値とを比較する。空きリソース計算部13は,リソース使用量と高負荷閾値とに差がある場合は,余分を見て高負荷閾値を下げることが可能であると判断する。この高負荷閾値を下げた分はリソース削減が可能となり,削減したリソース量が「空きリソース量」となる。」 N.「【0075】 [S120:空きリソースが十分かの判断] 追加リソース計算部14は,空きリソースが十分かを判断する。ステップS115において,高負荷検出仮想サーバにおける現状のアクセス負荷量が最大アクセス負荷量を超えていると判断した場合,リソースのいずれかについて,算出した必要リソース量NRが空きリソース量URより小さいと判断した場合,あるいは,リソースのいずれかについて,算出した必要リソース量NRと高負荷仮想サーバ群の使用リソース量(=高負荷閾値)との和が,全物理サーバ3の最大リソース量を超えた場合,空きリソースが十分ではないと判断する。各種リソース毎の全物理サーバ3の最大リソース量は,物理サーバ表記憶部28に記憶されている物理サーバ表から取得した,各物理サーバ3のリソース量を各種リソース毎に合計することにより得られる。 【0076】 [S125:リソース追加サーバの決定] 追加リソース計算部14は,総空きリソースURの全てを高負荷仮想サーバ群に所属する高負荷群所属仮想サーバに割り振る。 ・・・(後略)・・・」 P.「【0082】 ・・・(中略)・・・また,再配置における組み合わせ配置問題を解く際に,物理サーバ3の使用効率を上げるために,一つの物理サーバ3に仮想サーバ35を集約することを問題の制約条件に加えてもよい。」 (3)対比 ア.本件補正発明と引用発明とを対比する。 (ア)引用発明の「資源」は,データセンタの「資源」であり,データセンタがコンピュータで構成されることや,「リソース」が「資源」を意味することは技術常識であるから,本件補正発明の「共有コンピュータリソース」及び「ある種類のリソース」に相当する。 また,引用発明の「管理サーバ」は,コンピュータの一種であることは明らかであるから,引用発明の「方法」は,コンピュータにより実行される方法であるといえる。 したがって,引用発明の「データセンタの資源の量を管理サーバにより管理する方法」は,本件補正発明の「共有コンピュータリソースの使用量を管理する,コンピュータが実行する方法」に相当する。 (イ)引用発明の「ユーザに資源の量を保証する,秒あたりのアクセス件数を含むサービスレベル条件を入力されること」と,本件補正発明の「ある種類のリソースに対する,1秒あたりの入力/出力操作の認定使用レートの要求を受信すること」とを対比する。 前記(ア)で検討したように引用発明の「資源」は,本件補正発明の「ある種類のリソース」に相当する。 引用発明の「サービスレベル条件」は,ユーザが要求するリソースを示す情報といえる。 データが「入力されること」は,データを「受信すること」に相当することといえる。 引用発明の「秒あたりのアクセス件数」は,本件補正発明の「1秒あたりの入力/出力操作の認定使用レート」に相当する。 したがって,前記両者は,後記する点で相違するものの, “ある種類のリソースに対する,1秒あたりの入力/出力操作の認定使用レートを含む要求を受信すること”である点で共通しているといえる。 (ウ)引用発明の「前記入力されたサービスレベル条件を満たすための空きサーバがあれば,割当てサーバとして選択すること」と, 本件補正発明の「前記要求された認定使用レートの少なくとも一部分を提供するように動作可能な前記ある種類のリソースの少なくとも1つのインスタンスを判定すること」とを対比する。 引用発明の「サーバ」は,リソースを提供する装置であるから,本件補正発明の「インスタンス」に相当する。 引用発明の「サービスレベル条件」は,ユーザが要求するリソースを示す情報といえるから,引用発明の「サービスレベル条件を満たすための空きサーバ」とは,要求されたリソースを提供できるサーバといえる。 また引用発明の「入力されたサービスレベル条件」は,「秒あたりのアクセス件数」,すなわち,要求された「1秒あたりの入力/出力操作の認定使用レート」を含むものといえる。 そして,引用発明の「選択」は,空きサーバ,すなわち,要求されたリソースを提供できるサーバを「判定」するものといえる。 したがって,前記両者は,後記する点で相違するものの, “前記要求された認定使用レートの少なくとも一部分を提供するように動作可能な前記ある種類のリソースの少なくとも1つのインスタンスを判定すること”である点で共通しているといえる。 (エ)引用発明の「前記入力されたサービスレベル条件を満たす範囲で,サーバ数を削減できないか判断し,削減できる場合,削減されるサーバが使用している資源を解放してサーバ数を削減すること」と,本件補正発明の「より少数のインスタンスが前記認定使用レートを提供するために利用可能な場合に,前記より少数のインスタンスに前記認定使用レートを移動させ,統合すること」とを対比する。 引用発明の「前記入力されたサービスレベル条件を満たす範囲で」「サーバ数を削減すること」は,入力されたサービスレベル条件に対応付けられた複数のサーバに対して,入力されたサービスレベル条件,すなわち,要求されたリソースを利用できる,より少数のサーバが対応付けられるようにする処理である。 一方,本件補正発明の「前記より少数のインスタンスに前記認定使用レートを移動させ,統合すること」は,認定使用レートに対応付けられた複数のインスタンスに対して,「より少数のインスタンス」が対応付けられるようにする処理である。 また,引用発明の「サーバ数を削減できないか判断」することは,より少数のサーバでも,入力されたサービスレベル条件を満たせるか,すなわち,要求されたリソースを利用可能か否か判断するものといえる。 したがって,前記両者は,後記する点で相違するものの, “より少数のインスタンスが,要求された前記認定使用レートを提供するために利用可能な場合に,前記より少数のインスタンスにリソースを統合すること”である点で共通しているといえる。 イ.以上から,本件補正発明と引用発明とは,以下の点で一致し,また,以下の点で相違する。 (一致点) 「共有コンピュータリソースの使用量を管理する,コンピュータが実行する方法であって, ある種類のリソースに対する,1秒あたりの入力/出力操作の認定使用レートを含む要求を受信することと, 前記要求された認定使用レートの少なくとも一部分を提供するように動作可能な前記ある種類のリソースの少なくとも1つのインスタンスを判定することと, より少数のインスタンスが,要求された前記認定使用レートを提供するために利用可能な場合に,前記より少数のインスタンスにリソースを統合することと, を含む方法。」 (相違点1) 本件補正発明では,「前記認定使用レートを提供する能力があると判定された少なくとも1つのインスタンスに,前記要求された認定使用レートの少なくとも一部分を割り付けること」について特定されているのに対して, 引用発明では,サーバ(インスタンス)に,要求された認定使用レートを割り付けること,は特定されていない点 (相違点2) 「統合すること」に関し, 本件補正発明では,「前記認定使用レートを移動させ」るのに対して, 引用発明では,そのような点は特定されていない点。 (相違点3) 「前記少なくとも1つのインスタンス」に関し, 本件補正発明では,「前記インスタンスの使用容量が追加のユーザを許容する場合,前記追加のユーザに前記リソースを共有させる能力がある」のに対して, 引用発明では,そのような点は特定されていない点。 (4)当審の判断 上記相違点について検討する。 ア.相違点1について 引用発明は「前記入力されたサービスレベル条件を満たすための空きサーバがあれば,割当てサーバとして選択する」ところ, サーバに,ファイル領域の性能条件や,ディスクI/Oの単位時間当たりの処理件数のような,必要な1秒あたりの入力/出力操作レートを割り付けることは,例えば引用文献2(上記Fを参照),引用文献4(上記L,Nを参照)に記載されるように,本願の優先日前には情報処理の技術分野において適宜に採用されていた周知技術であった。 そうすると,引用発明に,上記周知技術を適用して,選択された「サーバ」において,1秒あたりの入力/出力操作レートを割り付けること,すなわち,相違点1に係る構成とすることは,当業者が容易に想到し得たことである。 イ.相違点2について 引用発明は「前記入力されたサービスレベル条件を満たす範囲で,サーバ数を削減できないか判断し,削減できる場合,削減されるサーバが使用している資源を解放してサーバ数を削減する」ところ, 複数のサーバ(インスタンス)で提供している機能を,より少数のサーバ(インスタンス)に移動し,集約するサーバ統合技術は,例えば引用文献4(上記J,K,Pを参照)に記載されるように,本願の優先日前には分散処理の技術分野において,適宜に採用されていた周知技術であった。 そうすると,引用発明に,上記周知技術を適用して,「サーバ数を削減する」際に,削減するサーバの資源を,より少数のサーバに移動すること,すなわち,相違点2に係る構成とすることは,当業者が容易に想到し得たことである。 ウ.相違点3について 未使用リソース,又は,既存の顧客や仮想サーバから削減して回収した空きリソースの量が十分であれば,他の顧客や仮想サーバに割り当てることは,例えば引用文献3(上記G?Iを参照),引用文献4(上記M,Nを参照)に記載されるように,本願の優先日前には分散処理の技術分野において,適宜に採用されていた周知技術であった。 そうすると,引用発明に,上記周知技術を適用して,サーバ(インスタンス)の資源(リソース)の使用量が,他の追加のユーザを許容するのに十分である場合,追加のユーザにサーバ(インスタンス)の資源(リソース)を割り当てることで,ユーザ間でリソースを共有させること,すなわち,相違点3に係る構成とすることは,当業者が容易に想到し得たことである。 エ.小括 上記で検討したごとく,相違点1?相違点3に係る構成は当業者が容易に想到し得たものであり,そして,これらの相違点を総合的に勘案しても,本件補正発明の奏する作用効果は,上記引用発明及び当該技術分野の周知技術の奏する作用効果から予測される範囲内のものにすぎず,格別顕著なものということはできない。 したがって,本件補正発明は,その出願前に日本国内又は外国において頒布された刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基づいて,その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから,特許法第29条第2項の規定により特許出願の際独立して特許を受けることができないものである。 4.補正却下むすび 以上のとおり,本件補正は,特許法第17条の2第5項に違反しており,仮に本件補正が目的要件を満たすものあったとしても,同法第17条の2第6項において準用する同法第126条第7項の規定に違反するので,同法第159条第1項の規定において読み替えて準用する同法第53条第1項の規定により却下すべきものである。 よって,上記補正却下の決定の結論のとおり決定する。 第3 本件審判請求の成否について 1.本願発明の認定 平成27年2月6日付けの手続補正は上記のとおり却下されたので,本件補正後の請求項1に対応する本件補正前の請求項に係る発明(以下,「本願発明」という。)は平成26年4月7日付けの手続補正により補正された特許請求の範囲の請求項9に記載された事項により特定される,以下のとおりのものである。 「共有コンピュータリソースの使用量を管理する,コンピュータが実行する方法であって, ある種類のリソースに対する,1秒あたりの入力/出力操作の認定使用レートの要求を受信することと, 前記要求された認定使用レートの少なくとも一部分を提供するように動作可能な前記ある種類のリソースの少なくとも1つのインスタンスを判定することと, 前記認定使用レートを提供する能力があると判定された少なくとも1つのインスタンスに,前記要求された認定使用レートの少なくとも一部分を割り付けることと,を含み, 前記少なくとも1つのインスタンスが,さらに,前記インスタンスの使用容量が追加のユーザを許容する場合,前記追加のユーザに前記リソースを共有させる能力がある方法。」 2.引用文献に記載されている技術的事項及び引用発明の認定 引用文献に記載されている技術的事項及び引用発明は,前記「第2 平成27年2月6日付けの手続補正についての補正却下の決定」の「3.独立特許要件」の「(2)引用文献」に記載したとおりである。 3.対比・判断 本願発明は,前記「第2 平成27年2月6日付けの手続補正についての補正却下の決定」の「3.独立特許要件」の「3-2.特許法第29条第2項について」で検討した本件補正発明の「方法」から「より少数のインスタンスが前記認定使用レートを提供するために利用可能な場合に,前記より少数のインスタンスに前記認定使用レートを移動させ,統合すること」を削除したものである。 したがって,前記削除された発明特定事項に対応する,前記「3.独立特許要件」の「3-2.特許法第29条第2項について」の「(3)対比」で検討した相違点2は,本願発明においては相違点とはならない。 そうすると,本願発明の発明特定事項を全て含む本件補正発明は,前記「第2 平成27年2月6日付けの手続補正についての補正却下の決定」の「3.独立特許要件」の「3-2.特許法第29条第2項について」の「(2)引用文献」乃至「(4)当審の判断」に記載したとおり,引用発明及び当該技術分野の周知技術に基づいて当業者が容易に発明をすることができたものであるから,上記特定の限定を省いた本願発明も同様の理由により,引用発明及び当該技術分野の周知技術に基づいて,当業者が容易に発明をすることができたものである。 4.平成27年6月12日付けの上申書について 審判請求人は,上記平成27年6月12日付けの上申書において補正案(以下,「上申補正案」という。)を提示している。 上申補正案では,本件補正後の請求項9に係る発明について,上記「より少数のインスタンスが前記認定使用レートを提供するために利用可能な場合に,前記より少数のインスタンスに前記認定使用レートを移動させ,統合することと」なる記載を, 「前記要求された認定使用レートの少なくとも一部分を割り付けることは,より少数のインスタンスが前記要求された認定使用レートを提供するために利用可能な場合に,前記より少数のインスタンスに前記要求された認定使用レートを移動させ,統合すること」なる記載に変更している。 上申補正案は,「統合すること」が「割り付けること」に含まれるように限定するものであり,移動される「認定使用レート」を「要求された認定使用レート」に限定するものである。 しかしながら,上記「第2 平成27年2月6日付けの手続補正についての補正却下の決定」の「3.独立特許要件」の「3-1.特許法第36条第6項第2号について」の(2)で検討したように,依然として移動処理の対象や具体的手順が明確でなく,「前記要求された認定使用レート」の「移動」が,具体的にどのような処理を意味するのか不明確である。 上申補正案の請求項9に記載の方法は,「認定使用レートの要求」を受信し,インスタンスに前記「要求された認定使用レート」を割り付ける際に,より少数のインスタンスに前記「要求された認定使用レート」を移動させている。 一方,本願明細書を参酌すると,例えば段落【0064】には「初期の要求を第1のリソースインスタンス502から移動させることによって,システムは,3つではなく2つのリソースインスタンスを使用して,要求されたレート認定を提供することができる。」と記載されており, 「初期の要求」と「要求されたレート認定」の2つが特定されており, 移動処理の対象は,現在受信した「要求」に係る「認定使用レート」ではなく,過去に受信した「初期の要求」に係る「認定使用レート」を移動させていると考えられる。 しかるに上申補正案の請求項9の記載では,「初期の要求」と現在受信した「要求」とを区別しておらず,本願明細書を参酌しても上申補正案の請求項9に記載の「移動」処理の具体的内容は不明確である。 また「3-1.特許法第36条第6項第2号について」の(3)で検討したように,本件補正後の請求項1に記載の「より少数のインスタンスが前記認定要求レートを提供するために利用可能な場合」であることを,具体的にどのような手順で判定するのか依然として不明確である。 上申補正案の請求項1?8,10?14についても同様である。 したがって,上申補正案の請求項1?14に係る発明は,特許法第36条第6項第2号の規定に違反するものであり,特許を受けることができないものである。 仮に上申補正案の請求項1?14に係る発明が特許法第36条第6項第2号の規定を満たすとして「3.独立特許要件」に関して特許法第29条第2項について検討しても, 帯域幅を貸し出すデータセンターにおいて,要求資源量の増減発生時に,サーバの余剰性能が小さくなるように資源を再割当てをすることは,例えば特開2009-217434号公報(平成21年9月24日出願公開)の段落【0003】,【0033】?【0036】,【0054】,【0085】?【0086】に記載されるように,本願の優先日前には情報処理の技術分野において適宜に採用されていた周知技術であり,引用発明に,上記周知技術を適用して,要求資源量の増減発生時,すなわち,新しい要求を受信した際に,帯域幅のような資源を再割当て,すなわち,移動することは,当業者が容易に想到し得たことである。 したがって,上申補正案の請求項9に係る発明は,特許法第29条第2項の規定に違反するものであるから,特許を受けることができないものである。 上記に示すとおり,上申補正案は,特許法第17条の2第6項に適合しておらず,仮に当該補正案どおり補正がなされたとしても,これは,同法第159条第1項の規定において読み替えて準用する同法第53条第1項の規定により却下すべきものとなる。よって,更なる補正の機会を設ける事に益は無い。 5.むすび 以上のとおり,本願の請求項1に係る発明は,特許法第29条第2項の規定により特許を受けることができないものであるから,その余の請求項に係る発明について検討するまでもなく,本願は拒絶すべきものである。 よって,結論のとおり審決する。 |
審理終結日 | 2015-10-09 |
結審通知日 | 2015-10-13 |
審決日 | 2015-10-27 |
出願番号 | 特願2013-502763(P2013-502763) |
審決分類 |
P
1
8・
574-
Z
(G06F)
P 1 8・ 573- Z (G06F) P 1 8・ 575- Z (G06F) P 1 8・ 572- Z (G06F) P 1 8・ 571- Z (G06F) P 1 8・ 121- Z (G06F) |
最終処分 | 不成立 |
前審関与審査官 | 井上 宏一 |
特許庁審判長 |
高木 進 |
特許庁審判官 |
石井 茂和 戸島 弘詩 |
発明の名称 | 共有リソースに対する認定要求レートの管理 |
代理人 | 特許業務法人 谷・阿部特許事務所 |