• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 特36条6項1、2号及び3号 請求の範囲の記載不備 取り消して特許、登録 G06F
審判 査定不服 2項進歩性 取り消して特許、登録 G06F
管理番号 1351805
審判番号 不服2018-4201  
総通号数 235 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2019-07-26 
種別 拒絶査定不服の審決 
審判請求日 2018-03-28 
確定日 2019-06-04 
事件の表示 特願2013-202118「仮想化シミュレーション・エンジンのための方法、システム、およびコンピュータ・プログラム」拒絶査定不服審判事件〔平成26年 5月19日出願公開、特開2014- 93080、請求項の数(15)〕について、次のとおり審決する。 
結論 原査定を取り消す。 本願の発明は、特許すべきものとする。 
理由 第1 手続の経緯
本件審判請求に係る出願(以下,「本願」という。)は,平成25年9月27日(パリ条約による優先権主張外国庁受理2012年10月31日(以下,「優先日」という。),米国)の出願であって,その手続の経緯は以下のとおりである。

平成29年 3月16日付け :拒絶理由の通知
平成29年 6月27日 :意見書,手続補正書の提出
平成29年11月22日付け :拒絶査定
平成30年 3月28日 :審判請求書,手続補正書の提出
平成30年11月30日付け :拒絶理由の通知(当審)
平成31年 2月 4日 :意見書,手続補正書の提出

第2 本願発明
本願請求項1-15に係る発明(以下,それぞれ「本願発明1」-「本願発明15」という。)は,平成31年2月4日付けの手続補正で補正された特許請求の範囲の請求項1-15に記載された事項により特定される発明であり,本願発明1は以下のとおりの発明である。

「 【請求項1】
1次サイトの障害をバックアップ・サイトで回復するのに必要なリソース使用量を示す障害回復容量を決定するための方法であって,
前記1次サイト,前記バックアップ・サイト,または3次サイトのバックグラウンドで実行可能な仮想サーバを提供するシミュレーション・ハイパーバイザによって1次サイトからストリーミング・メトリック・データを受信することであって,前記ストリーミング・メトリック・データは前記1次サイトの生成ワークロードを表す,前記1次サイトで実行中のアプリケーションのリソース使用量を含む,受信すること,
前記メトリック・データをバックアップ・サイトのリソース使用量を示す生成データと統合し,前記バックアップ・サイト上の優先度がより低いアプリケーションを休止状態と想定することにより,前記シミュレーション・ハイパーバイザによって前記バックアップ・サイト上の回復イベントにおけるリソース使用量をバックグラウンドでシミュレートすること,および,
前記シミュレートに基づいて,障害プランニングを実行することであって,前記バックアップ・サイトが前記回復イベントを処理するのに充分なリソースを有するかどうかを判定すること,
を含み,
前記受信することおよび前記シミュレートすること,それぞれがリアルタイムで実行される,障害回復容量を決定するための方法。」

なお,本願発明2-15の概要は以下のとおりである。

本願発明2-5は,本願発明1を減縮した発明である。

本願発明6は,本願発明1に対応する「システム」の発明であり,本願発明1とカテゴリ表現が異なるだけの発明である。

本願発明7-10は,本願発明6を減縮した発明である。

本願発明11は,本願発明1に対応する「コンピュータ・プログラム」の発明であり,本願発明1とカテゴリ表現が異なるだけの発明である。

本願発明12-15は,本願発明11を減縮した発明である。

第3 引用文献,引用発明等
1 引用文献1について
原査定の拒絶の理由に引用された引用文献1(特開2009-181249号公報)には,図面とともに次の事項が記載されている。
(当審注:下線は,参考のために当審で付与したものである。)

A 「【発明が解決しようとする課題】
【0008】
上述した本発明に関連する仮想マシンシステムでは,上記の特許文献1?3に記載されているように,仮想マシンを再配置する方法では,仮想マシン全体を移動させることになり,効率が悪くなるという問題がある。
【0009】
そこで,本発明の目的は上記の問題点を解消し,1つの仮想マシンの処理を複数のサーバで分散させることができ,システム全体の負荷を平均化することができる仮想マシンサーバ装置,仮想マシンシステム及びそれらに用いる仮想マシン分散方法並びにそのプログラムを提供することにある。」

B 「【0015】
次に,本発明の実施の形態について図面を参照して説明する。図1は本発明の第1の実施の形態による仮想マシンサーバの構成例を示すブロック図である。図1に示す仮想マシンサーバ1は,上記の請求項1に対応する装置であり,複数のCPU(Central Processing Unit:中央処理装置)サーバ(図示せず)及びストレージ・ネットワーク(図示せず)に,専用のネットワーク(図示せず)を介して接続されている。
【0016】
また,仮想マシンサーバ1は,自装置上で動作しかつ仮想マシンシステム全体の制御を行うスーパーハイパーバイザ11を搭載している。スーパーハイパーバイザ11は,仮想マシン稼働部111と,CPUサーバ負荷状況取得部112と,仮想CPU処理割り振り部113とを備えている。
【0017】
仮想マシン稼働部111は,CPUサーバを仮想マシンの仮想CPUとして,ストレージ・ネットワークを仮想マシンの仮想メモリや仮想HDD(Hard Disk Drive)として,それぞれ複数の仮想マシンを稼動させる。CPUサーバ負荷状況取得部112は,各CPUサーバの負荷状況を各CPUサーバ上で稼動するハイパーバイザ(図示せず)から取得する。
【0018】
仮想CPU処理割り振り部113は,CPUサーバ負荷状況取得部112で取得したCPUサーバの負荷状況と仮想マシンの仮想CPUの負荷状況とに応じて,各仮想マシンの仮想CPUの処理を各ハイパーバイザに割り振る。
【0019】
図2は本発明の第1の実施の形態によるCPUサーバの構成例を示すブロック図である。図2に示すCPUサーバ2は,図1に示す仮想マシンサーバ1に接続されて仮想マシンシステムを構成しており,自装置上で動作するハイパーバイザ21を搭載している。ハイパーバイザ21は,負荷状況通知部211と,処理部212とを備えている。
【0020】
ここで,ハイパーバイザとは,仮想化されたOS(Operating System)とハードウェアとの間に存在するレイヤであり,OSとハードウェアとの間でアクセスを調停する手段として働いている。また,ハイパーバイザは,仮想マシンモニタ(VMM:Virtual Machine Monitor)とも呼ばれる。」

C 「【0023】
仮想マシンサーバ1上のスーパーハイパーバイザ11は,仮想マシン稼働部111によって,CPUサーバ情報を基に仮想CPUを作成し(図3ステップS1),仮想マシン情報を基にストレージ・ネットワークに仮想メモリを作成し(図3ステップS2),ストレージ・ネットワーク上の仮想HDDよりOSを起動する(図3ステップS3)。
【0024】
スーパーハイパーバイザ11は,CPUサーバ負荷状況取得部112によって,ハイパーバイザ21よりCPUサーバ2の負荷情報(CPUサーバ2の情報と所定時間毎の仮想CPUやメモリの負荷状況)を取得する(図3ステップS4)。
【0025】
さらに,スーパーハイパーバイザ11は,仮想CPU処理割り振り部113によって,各仮想マシンの仮想CPU毎に処理をトランザクション(不可分の処理)として分割し,各ハイパーバイザに送信する(図3ステップS5)。スーパーハイパーバイザ11は,上記の処理を,処理すべきトランザクションが存在しなくなるまで(図3ステップS6),繰り返し実行する。尚,本実施の形態では,分割した処理(仮想CPU毎の処理)の結果を収集して元の処理の結果とするため,トランザクションとして分割している。」

D 「【0063】
図16は本発明の第4の実施の形態による仮想マシンサーバ1aの動作を示すフローチャートである。この図16を参照して本発明の第4の実施の形態による仮想マシンサーバ1aの動作について説明する。尚,図16のステップS31?S35,S40の処理は図3に示す本発明の第1の実施の形態におけるステップS1?S6の処理と同様であるので,その説明を省略する。
【0064】
仮想マシンサーバ1a上のスーパーハイパーバイザ11は,CPUサーバ2aのサービスコントローラ24より障害が報告された場合(図16ステップS36),当該CPUサーバ2aで実行中のトランザクションを中断する(図16ステップS37)。スーパーハイパーバイザ11は,実行中だった当該トランザクションを他のCPUサーバで処理するようハイパーバイザ21に依頼した後(図16ステップS38),仮想マシンシステムから当該CPUサーバの情報を切り離し(図16ステップS39),当該CPUサーバ2a以外で処理を続ける。
【0065】
このように,本実施の形態では,CPUサーバ2aに障害が発生した場合でも,動的にCPUサーバ2aの増減を行うことができるため,仮想マシンA?Dでのサービスを停止する必要がなくなるという効果が得られる。」

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

「1つの仮想マシンの処理を複数のサーバで分散させることができ,システム全体の負荷を平均化することができる仮想マシン分散方法であって,
仮想マシンサーバ1は,複数のCPUサーバに,専用のネットワークを介して接続されており,自装置上で動作しかつ仮想マシンシステム全体の制御を行うスーパーハイパーバイザ11を搭載し,
前記スーパーハイパーバイザ11は,仮想マシン稼働部111と,CPUサーバ負荷状況取得部112と,仮想CPU処理割り振り部113とを備え,
前記仮想マシン稼働部111は,CPUサーバを仮想マシンの仮想CPUとして,それぞれ複数の仮想マシンを稼動させ,
前記CPUサーバ負荷状況取得部112は,各CPUサーバの負荷状況(CPUサーバの情報と所定時間毎の仮想CPUやメモリの負荷状況)を各CPUサーバ上で稼動するハイパーバイザから取得し,
前記仮想CPU処理割り振り部113は,前記CPUサーバ負荷状況取得部112で取得したCPUサーバの負荷状況と仮想マシンの仮想CPUの負荷状況とに応じて,各仮想マシンの仮想CPUの処理を各ハイパーバイザに割り振ること,
前記仮想マシンサーバ1上の前記スーパーハイパーバイザ11は,CPUサーバ2aのサービスコントローラ24より障害が報告された場合,前記CPUサーバ2aで実行中のトランザクションを中断し,実行中だった前記トランザクションを他のCPUサーバで処理するようハイパーバイザ21に依頼した後,仮想マシンシステムから前記CPUサーバ2aの情報を切り離し,前記CPUサーバ2a以外で処理を続け,CPUサーバに障害が発生した場合でも,動的にCPUサーバの増減を行うことができるため,仮想マシンA?Dでのサービスを停止する必要がなくなること,
を含む方法。」

2 引用文献2について
また,原査定の拒絶の理由に引用された引用文献2(国際公開第2011/022098号)には,図面とともに次の事項が記載されている。
(当審注:訳には,パテントファミリーである特表2013-502642号公報を参照した。下線は,参考のために当審で付与したものである。)

E 「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, the method including the steps of receiving a data flow to be processed by a plurality of tasks at a plurality of nodes in the event-driven system having stateful and stateless event processing components,
…(中略)…
wherein decentralized load migrations lead to overall system load distribution in the event-driven system and reduce cooling costs.」(2頁11行-最終行)
(訳: 【0007】
以上および以下に記載した通り,本発明の様々な利点および目的は,本発明の第1の態様により,イベント・ドリブン・システムにおける非集中負荷分散(decentralized load distribution)の方法を提供することによって達成され,この方法は,ステートフルおよびステートレス・イベント処理コンポーネントを有するイベント・ドリブン・システム内の複数のノードで複数のタスクによって処理すべきデータ・フローを受信するステップであって,
…(中略)…
非集中負荷移行がイベント・ドリブン・システムにおける全システムの負荷分散につながり,冷却コストを削減するステップとを含む。)

F 「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. In addition to utilization, the present computer-implemented method in an embodiment of the present invention can also estimate the post migration inlet temperature of the donor and recipient nodes, and thus provide reductions in cooling costs by advocating load migrations that would lower the temperature of a donor node without increasing the temperature of a recipient node above an acceptable threshold.」(11頁下4行-12頁上4行)
(訳: 【0033】
ターゲット・タスクを移行する前に,コンピュータによって実行されるこの方法は,何らかの仮定の場合に,ドナー・ノードおよびターゲット・ノードの移行後の使用率を推定することにより,ターゲット・タスクの移行がドナー・ノードおよびターゲット・ノードにとって良い決定になるかどうかを考慮する。使用率に加えて,本発明の一実施形態におけるコンピュータによって実行されるこの方法は,ドナー・ノードおよび受信側ノードの移行後の入口温度も推定することができ,したがって,受信側ノードの温度を許容できるしきい値以上に上昇させずにドナー・ノードの温度を低下させると思われる負荷移行を擁護することにより冷却コストの削減を提供することができる。)

したがって,上記引用文献2には,「非集中負荷分散の方法に関して,ターゲット・タスクを移行する前に,ドナー・ノードおよびターゲット・ノードの移行後の使用率を推定することにより,ターゲット・タスクの移行がドナー・ノードおよびターゲット・ノードにとって良い決定になるかどうかを考慮する」という技術的事項が記載されていると認められる。

3 引用文献3-4について
また,原査定の拒絶の理由に引用された引用文献3(特開2008-140123号公報)の段落【0030】-【0038】,及び引用文献4(特開2008-33630号公報)の段落【0032】-【0035】には,
「リソースが不足する際に,優先順位が低いプログラムのリソースを少なくとも一部回収することによってリソース不足が解消するかどうかを,当該回収を実際に行う前に判断する」
という周知技術が記載されていると認められる。

第4 対比・判断
1 本願発明1について
(1)対比
本願発明1と引用発明とを対比すると,次のことがいえる。
ア 引用発明は,「1つの仮想マシンの処理を複数のサーバで分散させることができ,システム全体の負荷を平均化することができる仮想マシン分散方法」であるところ,引用発明の「仮想マシン」は本願発明1の「仮想サーバ」に相当し,「1つの仮想マシンの処理を複数のサーバで分散させること」は“仮想サーバの処理を実行するための方法”であるといえる。
一方,本願発明1は,「1次サイトの障害をバックアップ・サイトで回復するのに必要なリソース使用量を示す障害回復容量を決定するための方法」であって,「1次サイト」,「バックアップ・サイト」では「仮想サーバ」の処理が実行可能であると解される。
そうすると,引用発明と本願発明1とは,後記する点で相違するものの,“仮想サーバの処理を実行するための方法”である点で共通するといえる。

イ 引用発明では,自装置上で動作しかつ仮想マシンシステム全体の制御を行う「スーパーハイパーバイザ11」は,仮想マシンの処理が実行される複数の「CPUサーバ」とは異なる「仮想マシンサーバ1」に搭載されることから,引用発明の「スーパーハイパーバイザ11」は本願発明1の「シミュレーション・ハイパーバイザ」に対応し,引用発明の「CPUサーバ」,「仮想マシンサーバ1」は,それぞれ本願発明1の「1次サイト」,「3次サイト」に相当するといえる。
また,引用発明の「スーパーハイパーバイザ11」は,「CPUサーバ負荷状況取得部112」を備え,「各CPUサーバの負荷状況(CPUサーバの情報と所定時間毎の仮想CPUやメモリの負荷状況)」を「CPUサーバ」から取得するところ,「CPUサーバ」の「仮想CPUやメモリの負荷状況」は“リソース使用量”であるといえるから,引用発明の「負荷状況」は,「CPUサーバ」の“生成ワークロード”を表すといえ,本願発明1の「ストリーミング・メトリック・データ」に相当するといえる。
そうすると,引用発明は,“3次サイトで実行可能であり,仮想サーバを提供するシミュレーション・ハイパーバイザによって1次サイトからストリーミング・メトリック・データを受信する”といえる。
したがって,引用発明と本願発明1とは,後記する点で相違するものの,“3次サイトで実行可能であり,仮想サーバを提供するシミュレーション・ハイパーバイザによって1次サイトからストリーミング・メトリック・データを受信することであって,前記ストリーミング・メトリック・データは前記1次サイトの生成ワークロードを表す,前記1次サイトのリソース使用量を含む,受信すること”である点で共通するといえる。

ウ 引用発明は,「前記仮想マシンサーバ1上の前記スーパーハイパーバイザ11は,CPUサーバ2aのサービスコントローラ24より障害が報告された場合,前記CPUサーバ2aで実行中のトランザクションを中断し,実行中だった前記トランザクションを他のCPUサーバで処理するようハイパーバイザ21に依頼した後,仮想マシンシステムから前記CPUサーバ2aの情報を切り離し,前記CPUサーバ2a以外で処理を続け」るところ,「CPUサーバ2a」の障害を「他のCPUサーバ」で回復すると解されるから,引用発明の「他のCPUサーバ」は本願発明1の「バックアップ・サイト」に相当するといえる。
そうすると,引用発明と本願発明1とは,後記する点で相違するものの,“1次サイトの障害をバックアップ・サイトで回復する”点で共通するといえる。

したがって,本願発明1と引用発明との間には,次の一致点,相違点があるといえる。

(一致点)
「仮想サーバの処理を実行するための方法であって,
3次サイトで実行可能であり,仮想サーバを提供するシミュレーション・ハイパーバイザによって1次サイトからストリーミング・メトリック・データを受信することであって,前記ストリーミング・メトリック・データは前記1次サイトの生成ワークロードを表す,前記1次サイトのリソース使用量を含む,受信すること,
前記1次サイトの障害をバックアップ・サイトで回復すること,
を含む方法。」

(相違点)
(相違点1)
本願発明1は,「1次サイトの障害をバックアップ・サイトで回復するのに必要なリソース使用量を示す障害回復容量を決定するための方法」であるのに対して,
引用発明は,「1つの仮想マシンの処理を複数のサーバで分散させることができ,システム全体の負荷を平均化することができる仮想マシン分散方法」である点。

(相違点2)
1次サイトからのストリーミング・メトリック・データの受信に関し,本願発明1は,「1次サイト,前記バックアップ・サイト,または3次サイトのバックグラウンドで実行可能な仮想サーバを提供するシミュレーション・ハイパーバイザによって1次サイトからストリーミング・メトリック・データを受信する」のに対して,
引用発明では,「スーパーハイパーバイザ11」は「仮想マシンサーバ1」に搭載され,「各CPUサーバの負荷状況(CPUサーバの情報と所定時間毎の仮想CPUやメモリの負荷状況)を各CPUサーバ上で稼動するハイパーバイザから取得」するものの,「スーパーハイパーバイザ11」は「1次サイト,前記バックアップ・サイト,または3次サイトのバックグラウンドで実行可能」であるか不明な点。

(相違点3)
本願発明1は,「メトリック・データをバックアップ・サイトのリソース使用量を示す生成データと統合し,前記バックアップ・サイト上の優先度がより低いアプリケーションを休止状態と想定することにより,前記シミュレーション・ハイパーバイザによって前記バックアップ・サイト上の回復イベントにおけるリソース使用量をバックグラウンドでシミュレートする」のに対して,
引用発明は,「CPUサーバ2a」の障害を「他のCPUサーバ」で回復するものの,シミュレーション・ハイパーバイザによる回復イベントにおけるリソース使用量をシミュレートすることは特定されていない点。

(相違点4)
本願発明1は,「シミュレートに基づいて,障害プランニングを実行することであって,前記バックアップ・サイトが前記回復イベントを処理するのに充分なリソースを有するかどうかを判定する」のに対して,
引用発明は,「CPUサーバ2a」の障害を「他のCPUサーバ」で回復するものの,シミュレートに基づいて,障害プランニングを実行することは特定されていない点。

(相違点5)
本願発明1は,「受信することおよび前記シミュレートすること,それぞれがリアルタイムで実行される」のに対して,
引用発明は,各CPUサーバの負荷状況を各CPUサーバから取得するものの,そのように特定されていない点。

(2)相違点についての判断
ア 相違点3について
事案に鑑みて,上記相違点3を先に検討すると,引用発明では,スーパーハイパーバイザ11は,CPUサーバ2aの障害が報告された場合,前記CPUサーバ2aで実行中だったトランザクションを他のCPUサーバで処理するよう回復を行うものであると解されるものの,スーパーハイパーバイザ11によるバックアップ・サイトでの回復処理におけるリソース使用量をシミュレートすることは特定されておらず,そのように設計変更することの動機付けもない。
また,仮想サーバシステムにおいて,シミュレーション・ハイパーバイザがバックグラウンドで動作し,1次サイトからのメトリック・データをバックアップ・サイトのリソース使用量を示す生成データと統合し,前記バックアップ・サイト上の優先度がより低いアプリケーションを休止状態と想定することにより,前記バックアップ・サイト上の回復イベントにおけるリソース使用量をシミュレートする旨の技術は,上記引用文献2-4には記載されておらず,本願の優先日前に当該技術分野において周知技術であったとまではいえず,当業者が適宜に選択し得た設計的事項であるとすることもできない。
そうすると,引用発明において,1次サイトからのメトリック・データをバックアップ・サイトのリソース使用量を示す生成データと統合し,前記バックアップ・サイト上の優先度がより低いアプリケーションを休止状態と想定することにより,シミュレーション・ハイパーバイザによって前記バックアップ・サイト上の回復イベントにおけるリソース使用量をバックグラウンドでシミュレートすること,すなわち,本願発明1の上記相違点3に係る構成とすることは,当業者が適宜なし得たものであるとすることはできない。

イ まとめ
したがって,他の相違点について判断するまでもなく,本願発明1は,当業者であっても,引用発明,引用文献2-4に記載された技術的事項に基づいて容易に発明できたものとはいえない。

2 本願発明2-5について
本願発明2-5は本願発明1を減縮した発明であり,本願発明1の
「前記メトリック・データをバックアップ・サイトのリソース使用量を示す生成データと統合し,前記バックアップ・サイト上の優先度がより低いアプリケーションを休止状態と想定することにより,前記シミュレーション・ハイパーバイザによって前記バックアップ・サイト上の回復イベントにおけるリソース使用量をバックグラウンドでシミュレートすること」(以下,「相違点3に係る構成」という。)
と同一の構成を備えるものであるから,本願発明1と同じ理由により,当業者であっても,引用発明,引用文献2-4に記載された技術的事項に基づいて容易に発明できたものとはいえない。

3 本願発明6-10について
本願発明6は本願発明1に対応する「システム」の発明であり,本願発明7-10は本願発明6を減縮した発明であり,本願発明1の「相違点3に係る構成」と同一の構成を備えるものであるから,本願発明1と同じ理由により,当業者であっても,引用発明,引用文献2-4に記載された技術的事項に基づいて容易に発明できたものとはいえない。

4 本願発明11-15について
本願発明11は本願発明1に対応する「コンピュータ・プログラム」の発明であり,本願発明12-15は本願発明11を減縮した発明であり,本願発明1の「相違点3に係る構成」と同一の構成を備えるものであるから,本願発明1と同じ理由により,当業者であっても,引用発明,引用文献2-4に記載された技術的事項に基づいて容易に発明できたものとはいえない。

第5 原査定の概要及び原査定についての判断
原査定は,請求項1-18について上記引用文献1-4に記載された発明及び周知技術に基づいて,当業者が容易に発明できたものであるから,特許法第29条第2項の規定により特許を受けることができない,というものである。
しかしながら,平成31年2月4日付け手続補正により補正された請求項1-15は,それぞれ「相違点3に係る構成」に対応する構成を有するものとなっており,
上記のとおり,本願発明1-15は,引用発明,引用文献2-4に記載された技術的事項に基づいて,当業者が容易に発明できたものではない。
したがって,原査定を維持することはできない。

第6 当審拒絶理由について
(特許法第36条第6項第2号について)
(1)当審では,請求項1-15の「前記メトリック・データをバックアップ・サイトのリソース使用量を示す生成データと組み合わせることにより,前記バックアップ・サイト上の優先度がより低いアプリケーションを休止状態と想定して,」が特定する事項が不明確であるとの拒絶の理由を通知しているが,平成31年2月4日付けの手続補正により,
「前記メトリック・データをバックアップ・サイトのリソース使用量を示す生成データと統合し,前記バックアップ・サイト上の優先度がより低いアプリケーションを休止状態と想定することにより,」
と補正された結果,この拒絶の理由は解消した。

(2)当審では,請求項1-15の「前記シミュレートに基づいて,前記バックアップ・サイトが前記回復イベントを処理するのに充分なリソースを有するかどうかを判定する障害プランニングを実行すること」が特定する事項が不明確であるとの拒絶の理由を通知しているが,平成31年2月4日付けの手続補正により,
「前記シミュレートに基づいて,障害プランニングを実行することであって,前記バックアップ・サイトが前記回復イベントを処理するのに充分なリソースを有するかどうかを判定すること」
と補正された結果,この拒絶の理由は解消した。

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

よって,結論のとおり審決する。
 
審決日 2019-05-21 
出願番号 特願2013-202118(P2013-202118)
審決分類 P 1 8・ 537- WY (G06F)
P 1 8・ 121- WY (G06F)
最終処分 成立  
前審関与審査官 圓道 浩史  
特許庁審判長 仲間 晃
特許庁審判官 辻本 泰隆
山崎 慎一
発明の名称 仮想化シミュレーション・エンジンのための方法、システム、およびコンピュータ・プログラム  
代理人 太佐 種一  
代理人 上野 剛史  

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