【事件の表示】
　特願２０１３−２０２１１８「仮想化シミュレーション・エンジンのための方法、システム、およびコンピュータ・プログラム」拒絶査定不服審判事件〔平成２６年　５月１９日出願公開、特開２０１４−　９３０８０、請求項の数（１５）〕について、次のとおり審決する。
【結　論】
　原査定を取り消す。
　本願の発明は、特許すべきものとする。
【理　由】
第１　手続の経緯
　本件審判請求に係る出願（以下，「本願」という。）は，平成２５年９月２７日（パリ条約による優先権主張外国庁受理２０１２年１０月３１日（以下，「優先日」という。），米国）の出願であって，その手続の経緯は以下のとおりである。
　
　　平成２９年　３月１６日付け　：拒絶理由の通知
　　平成２９年　６月２７日　　　：意見書，手続補正書の提出
　　平成２９年１１月２２日付け　：拒絶査定
　　平成３０年　３月２８日　　　：審判請求書，手続補正書の提出
　　平成３０年１１月３０日付け　：拒絶理由の通知（当審）
　　平成３１年　２月　４日　　　：意見書，手続補正書の提出
第２　本願発明
　本願請求項１−１５に係る発明（以下，それぞれ「本願発明１」−「本願発明１５」という。）は，平成３１年２月４日付けの手続補正で補正された特許請求の範囲の請求項１−１５に記載された事項により特定される発明であり，本願発明１は以下のとおりの発明である。
「　　【請求項１】
　１次サイトの障害をバックアップ・サイトで回復するのに必要なリソース使用量を示す障害回復容量を決定するための方法であって，
　前記１次サイト，前記バックアップ・サイト，または３次サイトのバックグラウンドで実行可能な仮想サーバを提供するシミュレーション・ハイパーバイザによって１次サイトからストリーミング・メトリック・データを受信することであって，前記ストリーミング・メトリック・データは前記１次サイトの生成ワークロードを表す，前記１次サイトで実行中のアプリケーションのリソース使用量を含む，受信すること，
　前記メトリック・データをバックアップ・サイトのリソース使用量を示す生成データと統合し，前記バックアップ・サイト上の優先度がより低いアプリケーションを休止状態と想定することにより，前記シミュレーション・ハイパーバイザによって前記バックアップ・サイト上の回復イベントにおけるリソース使用量をバックグラウンドでシミュレートすること，および，
　前記シミュレートに基づいて，障害プランニングを実行することであって，前記バックアップ・サイトが前記回復イベントを処理するのに充分なリソースを有するかどうかを判定すること，
を含み，
　前記受信することおよび前記シミュレートすること，それぞれがリアルタイムで実行される，障害回復容量を決定するための方法。」
　なお，本願発明２−１５の概要は以下のとおりである。
　本願発明２−５は，本願発明１を減縮した発明である。
　本願発明６は，本願発明１に対応する「システム」の発明であり，本願発明１とカテゴリ表現が異なるだけの発明である。
　本願発明７−１０は，本願発明６を減縮した発明である。
　本願発明１１は，本願発明１に対応する「コンピュータ・プログラム」の発明であり，本願発明１とカテゴリ表現が異なるだけの発明である。
　本願発明１２−１５は，本願発明１１を減縮した発明である。
第３　引用文献，引用発明等
１　引用文献１について
　原査定の拒絶の理由に引用された引用文献１（特開２００９−１８１２４９号公報）には，図面とともに次の事項が記載されている。
　（当審注：下線は，参考のために当審で付与したものである。）
Ａ　「【発明が解決しようとする課題】
【０００８】
　上述した本発明に関連する仮想マシンシステムでは，上記の特許文献１〜３に記載されているように，仮想マシンを再配置する方法では，仮想マシン全体を移動させることになり，効率が悪くなるという問題がある。
【０００９】
　そこで，本発明の目的は上記の問題点を解消し，
１つの仮想マシンの処理を複数のサーバで分散させることができ，システム全体の負荷を平均化することができる
仮想マシン分散方法
Ｂ　「【００１５】
　次に，本発明の実施の形態について図面を参照して説明する。図１は本発明の第１の実施の形態による仮想マシンサーバの構成例を示すブロック図である。図１に示す
仮想マシンサーバ１は，
複数のＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ：中央処理装置）サーバ（図示せず）
に，専用のネットワーク（図示せず）を介して接続されている。
【００１６】
　また，
仮想マシンサーバ１は，自装置上で動作しかつ仮想マシンシステム全体の制御を行うスーパーハイパーバイザ１１を搭載している。スーパーハイパーバイザ１１は，仮想マシン稼働部１１１と，ＣＰＵサーバ負荷状況取得部１１２と，仮想ＣＰＵ処理割り振り部１１３とを備えている。
【００１７】
　
仮想マシン稼働部１１１は，ＣＰＵサーバを仮想マシンの仮想ＣＰＵとして，
それぞれ複数の仮想マシンを稼動させる。ＣＰＵサーバ負荷状況取得部１１２は，各ＣＰＵサーバの負荷状況を各ＣＰＵサーバ上で稼動するハイパーバイザ（図示せず）から取得する。
【００１８】
　
仮想ＣＰＵ処理割り振り部１１３は，ＣＰＵサーバ負荷状況取得部１１２で取得したＣＰＵサーバの負荷状況と仮想マシンの仮想ＣＰＵの負荷状況とに応じて，各仮想マシンの仮想ＣＰＵの処理を各ハイパーバイザに割り振る。
【００１９】
　図２は本発明の第１の実施の形態によるＣＰＵサーバの構成例を示すブロック図である。図２に示すＣＰＵサーバ２は，図１に示す仮想マシンサーバ１に接続されて仮想マシンシステムを構成しており，自装置上で動作するハイパーバイザ２１を搭載している。ハイパーバイザ２１は，負荷状況通知部２１１と，処理部２１２とを備えている。
【００２０】
　ここで，ハイパーバイザとは，仮想化されたＯＳ（Ｏｐｅｒａｔｉｎｇ　Ｓｙｓｔｅｍ）とハードウェアとの間に存在するレイヤであり，ＯＳとハードウェアとの間でアクセスを調停する手段として働いている。また，ハイパーバイザは，仮想マシンモニタ（ＶＭＭ：Ｖｉｒｔｕａｌ　Ｍａｃｈｉｎｅ　Ｍｏｎｉｔｏｒ）とも呼ばれる。」
Ｃ　「【００２３】
　仮想マシンサーバ１上のスーパーハイパーバイザ１１は，仮想マシン稼働部１１１によって，ＣＰＵサーバ情報を基に仮想ＣＰＵを作成し（図３ステップＳ１），仮想マシン情報を基にストレージ・ネットワークに仮想メモリを作成し（図３ステップＳ２），ストレージ・ネットワーク上の仮想ＨＤＤよりＯＳを起動する（図３ステップＳ３）。
【００２４】
　
スーパーハイパーバイザ１１は，ＣＰＵサーバ負荷状況取得部１１２によって，ハイパーバイザ２１よりＣＰＵサーバ２の負荷情報（ＣＰＵサーバ２の情報と所定時間毎の仮想ＣＰＵやメモリの負荷状況）を取得する（図３ステップＳ４）。
【００２５】
　さらに，スーパーハイパーバイザ１１は，仮想ＣＰＵ処理割り振り部１１３によって，各仮想マシンの仮想ＣＰＵ毎に処理をトランザクション（不可分の処理）として分割し，各ハイパーバイザに送信する（図３ステップＳ５）。スーパーハイパーバイザ１１は，上記の処理を，処理すべきトランザクションが存在しなくなるまで（図３ステップＳ６），繰り返し実行する。尚，本実施の形態では，分割した処理（仮想ＣＰＵ毎の処理）の結果を収集して元の処理の結果とするため，トランザクションとして分割している。」
Ｄ　「【００６３】
　図１６は本発明の第４の実施の形態による仮想マシンサーバ１ａの動作を示すフローチャートである。この図１６を参照して本発明の第４の実施の形態による仮想マシンサーバ１ａの動作について説明する。尚，図１６のステップＳ３１〜Ｓ３５，Ｓ４０の処理は図３に示す本発明の第１の実施の形態におけるステップＳ１〜Ｓ６の処理と同様であるので，その説明を省略する。
【００６４】
　
仮想マシンサーバ１ａ上のスーパーハイパーバイザ１１は，ＣＰＵサーバ２ａのサービスコントローラ２４より障害が報告された場合（図１６ステップＳ３６），当該ＣＰＵサーバ２ａで実行中のトランザクションを中断する（図１６ステップＳ３７）。スーパーハイパーバイザ１１は，実行中だった当該トランザクションを他のＣＰＵサーバで処理するようハイパーバイザ２１に依頼した後（図１６ステップＳ３８），仮想マシンシステムから当該ＣＰＵサーバの情報を切り離し（図１６ステップＳ３９），当該ＣＰＵサーバ２ａ以外で処理を続ける。
【００６５】
　このように，本実施の形態では，
ＣＰＵサーバ２ａに障害が発生した場合でも，動的にＣＰＵサーバ２ａの増減を行うことができるため，仮想マシンＡ〜Ｄでのサービスを停止する必要がなくなる
　したがって，上記引用文献１には次の発明（以下，「引用発明」という。）が記載されていると認められる。
「１つの仮想マシンの処理を複数のサーバで分散させることができ，システム全体の負荷を平均化することができる仮想マシン分散方法であって，
　仮想マシンサーバ１は，複数のＣＰＵサーバに，専用のネットワークを介して接続されており，自装置上で動作しかつ仮想マシンシステム全体の制御を行うスーパーハイパーバイザ１１を搭載し，
　前記スーパーハイパーバイザ１１は，仮想マシン稼働部１１１と，ＣＰＵサーバ負荷状況取得部１１２と，仮想ＣＰＵ処理割り振り部１１３とを備え，
　前記仮想マシン稼働部１１１は，ＣＰＵサーバを仮想マシンの仮想ＣＰＵとして，それぞれ複数の仮想マシンを稼動させ，
　前記ＣＰＵサーバ負荷状況取得部１１２は，各ＣＰＵサーバの負荷状況（ＣＰＵサーバの情報と所定時間毎の仮想ＣＰＵやメモリの負荷状況）を各ＣＰＵサーバ上で稼動するハイパーバイザから取得し，
　前記仮想ＣＰＵ処理割り振り部１１３は，前記ＣＰＵサーバ負荷状況取得部１１２で取得したＣＰＵサーバの負荷状況と仮想マシンの仮想ＣＰＵの負荷状況とに応じて，各仮想マシンの仮想ＣＰＵの処理を各ハイパーバイザに割り振ること，
　前記仮想マシンサーバ１上の前記スーパーハイパーバイザ１１は，ＣＰＵサーバ２ａのサービスコントローラ２４より障害が報告された場合，前記ＣＰＵサーバ２ａで実行中のトランザクションを中断し，実行中だった前記トランザクションを他のＣＰＵサーバで処理するようハイパーバイザ２１に依頼した後，仮想マシンシステムから前記ＣＰＵサーバ２ａの情報を切り離し，前記ＣＰＵサーバ２ａ以外で処理を続け，ＣＰＵサーバに障害が発生した場合でも，動的にＣＰＵサーバの増減を行うことができるため，仮想マシンＡ〜Ｄでのサービスを停止する必要がなくなること，
を含む方法。」
２　引用文献２について
　また，原査定の拒絶の理由に引用された引用文献２（国際公開第２０１１／０２２０９８号）には，図面とともに次の事項が記載されている。
（当審注：訳には，パテントファミリーである特表２０１３−５０２６４２号公報を参照した。下線は，参考のために当審で付与したものである。）
Ｅ　「
The various advantages and purposes of the present invention as described above and hereafter are achieved by providing, according to a first aspect of the invention, a method of decentralized load distribution in an event-driven system,
…（中略）…
wherein decentralized load migrations lead to overall system load distribution in the event-driven system and reduce cooling costs.」（２頁１１行−最終行）
（訳：　【０００７】
　
以上および以下に記載した通り，本発明の様々な利点および目的は，本発明の第１の態様により，イベント・ドリブン・システムにおける非集中負荷分散（decentralized load distribution）の方法を提供することによって達成され
…（中略）…　
非集中負荷移行がイベント・ドリブン・システムにおける全システムの負荷分散につながり，冷却コストを削減するステップとを含む。）
Ｆ　「
Before migrating a target task, the present computer-implemented method considers whether migration of the target task will be a good decision for the donor and target nodes by estimating, given some assumptions, the post-migration utilization of the donor and target nodes.
（訳：　【００３３】
　
ターゲット・タスクを移行する前に，コンピュータによって実行されるこの方法は，何らかの仮定の場合に，ドナー・ノードおよびターゲット・ノードの移行後の使用率を推定することにより，ターゲット・タスクの移行がドナー・ノードおよびターゲット・ノードにとって良い決定になるかどうかを考慮する。
　したがって，上記引用文献２には，「非集中負荷分散の方法に関して，ターゲット・タスクを移行する前に，ドナー・ノードおよびターゲット・ノードの移行後の使用率を推定することにより，ターゲット・タスクの移行がドナー・ノードおよびターゲット・ノードにとって良い決定になるかどうかを考慮する」という技術的事項が記載されていると認められる。
３　引用文献３−４について
　また，原査定の拒絶の理由に引用された引用文献３（特開２００８−１４０１２３号公報）の段落【００３０】−【００３８】，及び引用文献４（特開２００８−３３６３０号公報）の段落【００３２】−【００３５】には，
「リソースが不足する際に，優先順位が低いプログラムのリソースを少なくとも一部回収することによってリソース不足が解消するかどうかを，当該回収を実際に行う前に判断する」
という周知技術が記載されていると認められる。
第４　対比・判断
１　本願発明１について
（１）対比
　本願発明１と引用発明とを対比すると，次のことがいえる。
ア　引用発明は，「１つの仮想マシンの処理を複数のサーバで分散させることができ，システム全体の負荷を平均化することができる仮想マシン分散方法」であるところ，引用発明の「仮想マシン」は本願発明１の「仮想サーバ」に相当し，「１つの仮想マシンの処理を複数のサーバで分散させること」は“仮想サーバの処理を実行するための方法”であるといえる。
　一方，本願発明１は，「１次サイトの障害をバックアップ・サイトで回復するのに必要なリソース使用量を示す障害回復容量を決定するための方法」であって，「１次サイト」，「バックアップ・サイト」では「仮想サーバ」の処理が実行可能であると解される。
　そうすると，引用発明と本願発明１とは，後記する点で相違するものの，“仮想サーバの処理を実行するための方法”である点で共通するといえる。
イ　引用発明では，自装置上で動作しかつ仮想マシンシステム全体の制御を行う「スーパーハイパーバイザ１１」は，仮想マシンの処理が実行される複数の「ＣＰＵサーバ」とは異なる「仮想マシンサーバ１」に搭載されることから，引用発明の「スーパーハイパーバイザ１１」は本願発明１の「シミュレーション・ハイパーバイザ」に対応し，引用発明の「ＣＰＵサーバ」，「仮想マシンサーバ１」は，それぞれ本願発明１の「１次サイト」，「３次サイト」に相当するといえる。
　また，引用発明の「スーパーハイパーバイザ１１」は，「ＣＰＵサーバ負荷状況取得部１１２」を備え，「各ＣＰＵサーバの負荷状況（ＣＰＵサーバの情報と所定時間毎の仮想ＣＰＵやメモリの負荷状況）」を「ＣＰＵサーバ」から取得するところ，「ＣＰＵサーバ」の「仮想ＣＰＵやメモリの負荷状況」は“リソース使用量”であるといえるから，引用発明の「負荷状況」は，「ＣＰＵサーバ」の“生成ワークロード”を表すといえ，本願発明１の「ストリーミング・メトリック・データ」に相当するといえる。
　そうすると，引用発明は，“３次サイトで実行可能であり，仮想サーバを提供するシミュレーション・ハイパーバイザによって１次サイトからストリーミング・メトリック・データを受信する”といえる。
　したがって，引用発明と本願発明１とは，後記する点で相違するものの，“３次サイトで実行可能であり，仮想サーバを提供するシミュレーション・ハイパーバイザによって１次サイトからストリーミング・メトリック・データを受信することであって，前記ストリーミング・メトリック・データは前記１次サイトの生成ワークロードを表す，前記１次サイトのリソース使用量を含む，受信すること”である点で共通するといえる。
ウ　引用発明は，「前記仮想マシンサーバ１上の前記スーパーハイパーバイザ１１は，ＣＰＵサーバ２ａのサービスコントローラ２４より障害が報告された場合，前記ＣＰＵサーバ２ａで実行中のトランザクションを中断し，実行中だった前記トランザクションを他のＣＰＵサーバで処理するようハイパーバイザ２１に依頼した後，仮想マシンシステムから前記ＣＰＵサーバ２ａの情報を切り離し，前記ＣＰＵサーバ２ａ以外で処理を続け」るところ，「ＣＰＵサーバ２ａ」の障害を「他のＣＰＵサーバ」で回復すると解されるから，引用発明の「他のＣＰＵサーバ」は本願発明１の「バックアップ・サイト」に相当するといえる。
　そうすると，引用発明と本願発明１とは，後記する点で相違するものの，“１次サイトの障害をバックアップ・サイトで回復する”点で共通するといえる。
　したがって，本願発明１と引用発明との間には，次の一致点，相違点があるといえる。
（一致点）
「仮想サーバの処理を実行するための方法であって，
　３次サイトで実行可能であり，仮想サーバを提供するシミュレーション・ハイパーバイザによって１次サイトからストリーミング・メトリック・データを受信することであって，前記ストリーミング・メトリック・データは前記１次サイトの生成ワークロードを表す，前記１次サイトのリソース使用量を含む，受信すること，
　前記１次サイトの障害をバックアップ・サイトで回復すること，
を含む方法。」
（相違点）
（相違点１）
　本願発明１は，「１次サイトの障害をバックアップ・サイトで回復するのに必要なリソース使用量を示す障害回復容量を決定するための方法」であるのに対して，
　引用発明は，「１つの仮想マシンの処理を複数のサーバで分散させることができ，システム全体の負荷を平均化することができる仮想マシン分散方法」である点。
（相違点２）
　１次サイトからのストリーミング・メトリック・データの受信に関し，本願発明１は，「１次サイト，前記バックアップ・サイト，または３次サイトのバックグラウンドで実行可能な仮想サーバを提供するシミュレーション・ハイパーバイザによって１次サイトからストリーミング・メトリック・データを受信する」のに対して，
　引用発明では，「スーパーハイパーバイザ１１」は「仮想マシンサーバ１」に搭載され，「各ＣＰＵサーバの負荷状況（ＣＰＵサーバの情報と所定時間毎の仮想ＣＰＵやメモリの負荷状況）を各ＣＰＵサーバ上で稼動するハイパーバイザから取得」するものの，「スーパーハイパーバイザ１１」は「１次サイト，前記バックアップ・サイト，または３次サイトのバックグラウンドで実行可能」であるか不明な点。
（相違点３）
　本願発明１は，「メトリック・データをバックアップ・サイトのリソース使用量を示す生成データと統合し，前記バックアップ・サイト上の優先度がより低いアプリケーションを休止状態と想定することにより，前記シミュレーション・ハイパーバイザによって前記バックアップ・サイト上の回復イベントにおけるリソース使用量をバックグラウンドでシミュレートする」のに対して，
　引用発明は，「ＣＰＵサーバ２ａ」の障害を「他のＣＰＵサーバ」で回復するものの，シミュレーション・ハイパーバイザによる回復イベントにおけるリソース使用量をシミュレートすることは特定されていない点。
（相違点４）
　本願発明１は，「シミュレートに基づいて，障害プランニングを実行することであって，前記バックアップ・サイトが前記回復イベントを処理するのに充分なリソースを有するかどうかを判定する」のに対して，
　引用発明は，「ＣＰＵサーバ２ａ」の障害を「他のＣＰＵサーバ」で回復するものの，シミュレートに基づいて，障害プランニングを実行することは特定されていない点。
（相違点５）
　本願発明１は，「受信することおよび前記シミュレートすること，それぞれがリアルタイムで実行される」のに対して，
　引用発明は，各ＣＰＵサーバの負荷状況を各ＣＰＵサーバから取得するものの，そのように特定されていない点。
（２）相違点についての判断
ア　相違点３について
　事案に鑑みて，上記相違点３を先に検討すると，引用発明では，スーパーハイパーバイザ１１は，ＣＰＵサーバ２ａの障害が報告された場合，前記ＣＰＵサーバ２ａで実行中だったトランザクションを他のＣＰＵサーバで処理するよう回復を行うものであると解されるものの，スーパーハイパーバイザ１１によるバックアップ・サイトでの回復処理におけるリソース使用量をシミュレートすることは特定されておらず，そのように設計変更することの動機付けもない。
　また，仮想サーバシステムにおいて，シミュレーション・ハイパーバイザがバックグラウンドで動作し，１次サイトからのメトリック・データをバックアップ・サイトのリソース使用量を示す生成データと統合し，前記バックアップ・サイト上の優先度がより低いアプリケーションを休止状態と想定することにより，前記バックアップ・サイト上の回復イベントにおけるリソース使用量をシミュレートする旨の技術は，上記引用文献２−４には記載されておらず，本願の優先日前に当該技術分野において周知技術であったとまではいえず，当業者が適宜に選択し得た設計的事項であるとすることもできない。
　そうすると，引用発明において，１次サイトからのメトリック・データをバックアップ・サイトのリソース使用量を示す生成データと統合し，前記バックアップ・サイト上の優先度がより低いアプリケーションを休止状態と想定することにより，シミュレーション・ハイパーバイザによって前記バックアップ・サイト上の回復イベントにおけるリソース使用量をバックグラウンドでシミュレートすること，すなわち，本願発明１の上記相違点３に係る構成とすることは，当業者が適宜なし得たものであるとすることはできない。
イ　まとめ
　したがって，他の相違点について判断するまでもなく，本願発明１は，当業者であっても，引用発明，引用文献２−４に記載された技術的事項に基づいて容易に発明できたものとはいえない。
２　本願発明２−５について
　本願発明２−５は本願発明１を減縮した発明であり，本願発明１の
「前記メトリック・データをバックアップ・サイトのリソース使用量を示す生成データと統合し，前記バックアップ・サイト上の優先度がより低いアプリケーションを休止状態と想定することにより，前記シミュレーション・ハイパーバイザによって前記バックアップ・サイト上の回復イベントにおけるリソース使用量をバックグラウンドでシミュレートすること」（以下，「相違点３に係る構成」という。）
と同一の構成を備えるものであるから，本願発明１と同じ理由により，当業者であっても，引用発明，引用文献２−４に記載された技術的事項に基づいて容易に発明できたものとはいえない。
３　本願発明６−１０について
　本願発明６は本願発明１に対応する「システム」の発明であり，本願発明７−１０は本願発明６を減縮した発明であり，本願発明１の「相違点３に係る構成」と同一の構成を備えるものであるから，本願発明１と同じ理由により，当業者であっても，引用発明，引用文献２−４に記載された技術的事項に基づいて容易に発明できたものとはいえない。
４　本願発明１１−１５について
　本願発明１１は本願発明１に対応する「コンピュータ・プログラム」の発明であり，本願発明１２−１５は本願発明１１を減縮した発明であり，本願発明１の「相違点３に係る構成」と同一の構成を備えるものであるから，本願発明１と同じ理由により，当業者であっても，引用発明，引用文献２−４に記載された技術的事項に基づいて容易に発明できたものとはいえない。
第５　原査定の概要及び原査定についての判断
　原査定は，請求項１−１８について上記引用文献１−４に記載された発明及び周知技術に基づいて，当業者が容易に発明できたものであるから，特許法第２９条第２項の規定により特許を受けることができない，というものである。
　しかしながら，平成３１年２月４日付け手続補正により補正された請求項１−１５は，それぞれ「相違点３に係る構成」に対応する構成を有するものとなっており，
　上記のとおり，本願発明１−１５は，引用発明，引用文献２−４に記載された技術的事項に基づいて，当業者が容易に発明できたものではない。
　したがって，原査定を維持することはできない。
第６　当審拒絶理由について
（特許法第３６条第６項第２号について）
（１）当審では，請求項１−１５の「前記メトリック・データをバックアップ・サイトのリソース使用量を示す生成データと組み合わせることにより，前記バックアップ・サイト上の優先度がより低いアプリケーションを休止状態と想定して，」が特定する事項が不明確であるとの拒絶の理由を通知しているが，平成３１年２月４日付けの手続補正により，
「前記メトリック・データをバックアップ・サイトのリソース使用量を示す生成データと統合し，前記バックアップ・サイト上の優先度がより低いアプリケーションを休止状態と想定することにより，」
と補正された結果，この拒絶の理由は解消した。
（２）当審では，請求項１−１５の「前記シミュレートに基づいて，前記バックアップ・サイトが前記回復イベントを処理するのに充分なリソースを有するかどうかを判定する障害プランニングを実行すること」が特定する事項が不明確であるとの拒絶の理由を通知しているが，平成３１年２月４日付けの手続補正により，
「前記シミュレートに基づいて，障害プランニングを実行することであって，前記バックアップ・サイトが前記回復イベントを処理するのに充分なリソースを有するかどうかを判定すること」
と補正された結果，この拒絶の理由は解消した。
第７　むすび
　以上のとおり，本願発明１−１５は，当業者が引用発明，引用文献２−４に記載された技術的事項に基づいて容易に発明をすることができたものではない。
　したがって，原査定の理由によっては，本願を拒絶することはできない。
　また，他に本願を拒絶すべき理由を発見しない。
　よって，結論のとおり審決する。