【事件の表示】
　特願２０１５−５１７４８１「クラウドインフラストラクチャ内のインフラストラクチャ欠陥を自動的に検出及び解決する方法及びシステム」拒絶査定不服審判事件〔平成２５年１２月１９日国際公開、ＷＯ２０１３／１８８８８３、平成２７年　７月　９日国内公表、特表２０１５−５１９６７６、請求項の数（６）〕について、次のとおり審決する。
【結　論】
　原査定を取り消す。
　本願の発明は、特許すべきものとする。
【理　由】
第１　手続の経緯
　本願は，２０１３年６月１７日（パリ条約による優先権主張外国庁受理２０１２年６月１５日，米国）を国際出願日とする出願であって，平成２７年１月２７日に特許法１８４条の４第１項の規定による明細書，請求の範囲，及び，図面（図面の中の説明に限る）の日本語による翻訳文が提出され，平成２８年６月１７日に手続補正書が提出され，同年９月３０日付けで拒絶の理由が通知され，平成２９年４月４日に意見書とともに手続補正書が提出され，同年６月２９日付けで拒絶の理由が通知され，同年１０月１６日に意見書とともに手続補正書が提出され，平成３０年１月１５日付けで拒絶査定（謄本送達日同年１月１９日）がなされ，これに対して同年５月２１日に審判請求がなされると共に手続補正がなされ，同年７月３１日付けで審査官により特許法１６４条３項の規定に基づく報告がなされ，平成３１年３月２７日付けで当審により拒絶の理由が通知され，令和元年５月３１日に意見書とともに手続補正書が提出されたものである。
第２　原査定の概要
　原査定（平成３０年１月１５日付け拒絶査定）の概要は次のとおりである。
　この出願の下記の請求項に係る発明は、その出願前に日本国内又は外国において、頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　　　　　記　　　（引用文献等については引用文献等一覧参照）
・請求項　１−６
・引用文献等　１−４
＜引用文献等一覧＞
１．特開２０１２−２２５５５号公報
２．中田　敦，「クローズアップ　ＡＰＩでクラウドの利便性高める　運用自動化やサービス連携を実現」，日経コンピュータ，日経ＢＰ社，２０１１年　８月１８日，第７８９号，ｐｐ．６８−７５（周知技術を示す文献）
３．特開２０１１−２５３２１２号公報（周知技術を示す文献；新たに引用された文献）
４．香川　康介，外４名，「ＯＳＳを構成するプライベートクラウド運用管理システムの実用化」，電子情報通信学会技術研究報告，社団法人電子情報通信学会，２０１１年１１月　３日，第１１１巻，第２７９号，ｐｐ．１３−１８，ＩＣＭ２０１１−２２　情報通信マネジメント　（周知技術を示す文献；新たに引用された文献）
第３　本願発明
　本願請求項１乃至６に係る発明（以下「本願発明１」乃至「本願発明６」という。）は，令和元年５月３１日付けの手続補正書によって補正された特許請求の範囲の請求項１乃至６に記載された，次のとおりのものと認める。
「　　【請求項１】
　ユーザ用のクラウド内の１つ以上のリソースの集合をコンピュータが検証する方法であって、前記１つ以上のリソースの集合は、アプリケーションプログラミングインタフェース（API）呼出（call）を利用して受け取られ、該方法は、
　前記１つ以上のリソースの集合に含まれるインフラストラクチャに対し、予め定義されたチェック及びユーザが定義したチェックを含むチェックを実行し、前記インフラストラクチャを不能にする欠陥を検出するステップと、
　検出された前記欠陥を解決するステップと、
　前記欠陥が解決された前記インフラストラクチャをユーザに提供するリソースの集合であるサービスクラスタに含ませるステップと、
　前記サービスクラスタに含まれる欠陥がなく機能しているリソースのみをユーザに提供するステップと、
　を含み、
　前記コンピュータが、欠陥を有するインフラストラクチャの検出法及び解決法を、先行／後続するAPI呼出の間に登録し、それにより、エンドユーザが前記欠陥に対処する必要性をなくすことを特徴とする方法。
　　【請求項２】
　前記欠陥を解決するステップは、ユーザに提供するリソースから、前記欠陥が検出されたインフラストラクチャを除外することを含む請求項１記載の方法。
　　【請求項３】
　前記欠陥を解決するステップは、ユーザに提供するリソースから、前記欠陥が検出されたインフラストラクチャを修正することを含む請求項１記載の方法。
　　【請求項４】
　コンピュータに請求項１〜３のいずれか1項に記載の方法を実行させるプログラム。
　　【請求項５】
　クラウド内のリソースを検証する管理サーバが、無欠陥リソースのリストを維持するために実行する方法であって、
　（ａ）サーバにログインできるかを検査するステップと、
　（ｂ）前記サーバ内のファイルシステムにアクセスできるかを検査するステップと、
　（ｃ）前記ステップ（ａ）及び（ｂ）の結果を前記管理サーバ、又は、アプリケーションプログラミングインタフェース（API）呼出（call）を利用して前記クラウドにアクセスするクライアントの少なくとも１つに通知するステップと、
　を有し、
　前記ステップ（ａ）乃至（ｃ）の何れかにおいて欠陥が検出された場合、（ｄ）検査のために前記欠陥が検出されたリソースをホールドするステップ、（ｅ）前記欠陥が検出されたリソースが再び取得されないことを確実にするステップ及び（ｆ）機能しているリソースのみがユーザに提供されるように、リソースをシャットダウンするステップのうちの少なくとも１つを実行し、
　前記管理サーバが、欠陥を有するインフラストラクチャの検出法及び解決法を、先行／後続するAPI呼出の間に登録し、それにより、エンドユーザが前記欠陥に対処する必要性をなくすことを特徴とする、方法。
　　【請求項６】
　前記ステップ（ａ）乃至（ｃ）の何れにおいても欠陥が検出されなかった場合、前記サーバを、クライアントに提供するリソースの集合であるサーバクラスタに含ませるステップを更に有する請求項５記載の方法。」
第４　引用例
１　引用例１に記載された事項及び引用発明
　原審の平成２９年６月２９日付けの拒絶理由（以下，「原審拒絶理由」という。）及び，平成３１年３月２７日付け当審拒絶理由（以下，単に「当審拒絶理由」という。）において引用した，本願の第一国出願前に既に公知である，特開２０１２−２２５５５号公報（平成２４年２月２日公開。以下，これを「引用例１」という。）には，関連する図面と共に，次の事項が記載されている。（なお，下線は当審で説明のために付加。以下同様。）
Ａ　「【００１０】
　近年、
ＩａａＳ（Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ　ａｓ　ａ　Ｓｅｒｖｉｃｅ）、ＰａａＳ（Ｐｌａｔｆｏｒｍ　ａｓ　ａ　Ｓｅｒｖｉｃｅ）と呼ばれるような、クラウド基盤を提供するサービス
【００１１】
　クラウド基盤提供サービスを利用して情報システムを構築する場合、
情報システムの利用者は、クラウド基盤提供サービスが提供する、サーバ、仮想サーバ、ネットワーク、及び、ストレージ等のサービス提供品質を吟味し、その全部又は一部を利用することによって、情報システムを構築
Ｂ　「【００２２】
　本実施形態の
サーバ構成管理システムは、クライアント１００、管理サーバ２００、運用サーバ３００、及び、複数のデータセンタ４００（４００−１、４００−２）を備え
Ｃ　「【００３８】
　
利用者は、クライアント１００を利用して、
サーバ４２０にリクエストを送信
Ｄ　「【００４４】
　なお、管理サーバ２００及び運用サーバ３００のハードウェア構成は、図２に示すクライアント１００のハードウェア構成と同じく、一般的なサーバと同じである。また、
クライアント１００、管理サーバ２００、運用サーバ３００は、すべて又は一部を仮想化され、一つ又は複数の計算機によって実装されてもよい
Ｅ　「【００４９】
　（運用サーバ３００）
　さらに、運用サーバ３００の機能を説明する。
運用サーバ３００は、サービスを管理するためのサーバ
運用サーバ３００は、サーバ４２０を含むデータセンタ４００及びネットワーク６００のリソース（例えば、サーバ４２０、サーバ４２０に備わるＣＰＵ４２４若しくはストレージ４２５等、又は、ネットワーク６００に備わる回線等）の利用状況及び稼動状況を示す運用情報を取得し、運用情報に基づいて、リソースの起動又は停止等をする
Ｆ　「【００５４】
　また、
運用サーバ３００は、データセンタ４００において起動するサーバ４２０、仮想サーバのイメージ（サーバテンプレート）の変更及び管理を行う
データセンタ４００において動作するサーバ４２０（仮想サーバを含む）の状況を、データセンタ４００の管理ＡＰＩから取得する
Ｇ　「【００５６】
　まず
利用者は、特定のサービスを利用する要求を、クライアント１００に入力する
利用者は、ブラウザ画面を起動させ、キーボードによって文字を入力したり、又は、マウスによってブラウザ画面上のボタンをクリックするなどの操作によって、利用要求をクライアント１００に入力する
Ｈ　「【００６０】
　
受信されたリクエスト
測定用の情報を付加する
付加される測定用の情報とは、サーバ４２０−１が保持する情報
【００６１】
　
測定用の情報には、
サーバ４２０−１において発生したエラー等を示す情報などが含まれ
【００６２】
　シーケンス８０３の後、処理結果と測定用の情報とは、通信制御部１１０−１へ返信される（８０４）。通信制御部１１０−１は、クライアント１００へ処理結果と測定用の情報とを送信する（８０５）。
【００６３】
　
クライアント１００は、処理結果と測定用の情報とを受信した後、処理結果を画面に表示する
サーバ４２０−１からクライアント１００までの経路情報、エラー情報、検証用情報、クライアント１００の情報、サーバ４２０−１にリクエストしたサービス名、アクセスしたＵＲＩ、受信したデータ量、処理時間、及び、タイムスタンプ（クライアント１００が処理を開始又は終了した時刻）などをさらに測定
Ｉ　「【００７８】
　いずれかの通信制御部１１０において、管理サーバ２００によって提供された対応情報と相違する内容が検出された場合、例えば、
サーバ４２０が特定のサービスを提供しないことによって、通信を中継したサーバ４２０からエラー応答が返答された場合、通信制御部１１０は、構成管理部２３０に対応情報の取得を指示
【００７９】
　そして、
構成管理部２３０は、エラーが発生しているサーバ４２０の状況を運用サーバ３００、又は、データセンタ４００に備わる
管理装置に問い合わせ、サーバ４２０の状況を取得
Ｊ　「【００８８】
　なお、
運用サーバ３００が、サーバ４２０等の性能をテストしてもよい
【００８９】
　また、前述の通り、運用サーバ３００は、サーバ４２０を含むデータセンタ４００及びネットワーク６００の運用情報を取得している。このため、
管理サーバ２００は、運用サーバ３００からサーバ４２０等の運用情報を取得し、ストレージ２４０の運用情報２４５に格納する。そして、取得した運用情報２４５に従って、サーバリソースの構成を決定してもよい
【００９０】
　例えば、
取得した運用情報２４５が、サービスを提供可能なサーバ４２０が停止していることを示す場合、管理サーバ２００は、サービスを提供可能な別のサーバ４２０をサーバリソースの構成に決定してもよい
Ｋ　「【００９８】
　また、
構成管理部２３０は
通信に対する利用コストを算出
【００９９】
　次に、
前述のように算出されたサービス品質と利用コストとを、サーバリソースのパターンごとに取得し、あらかじめ定められたポリシー（例えば、「利用コストが最低である」、「あるサービス品質ができる限り高く、かつ、利用コストが最低の場合と比較し１．３倍以内である」、「すべてのサービス品質が定められた範囲内である」、又は、「あるサービス品質が最も高い」など）に従って、特定のサービスを提供するために最適なシステムの構成が抽出される
　上記記載事項Ａ乃至Ｋから，引用例１には，次の発明（以下，「引用発明」という。）が記載されているといえる。
「クライアント１００，管理サーバ２００，運用サーバ３００，及び，複数のデータセンタ４００（４００−１，４００−２）を備えるサーバ構成管理システムで実施される方法であって，
　前記サーバ構成管理システムの利用者は，ＩａａＳ，ＰａａＳと呼ばれるような，クラウド基盤提供サービスが提供する，サーバ，仮想サーバ，ネットワーク，及び，ストレージ等のサービス提供品質を吟味し，その全部又は一部を利用することによって，情報システムを構築するものであって，
　前記利用者は，クライアント１００を利用して，サーバ４２０にリクエストを送信し，
　クライアント１００，管理サーバ２００，運用サーバ３００は，すべて又は一部を仮想化され，一つ又は複数の計算機によって実装されてもよく，
　運用サーバ３００は，サービスを管理するためのサーバであって，サーバ４２０を含むデータセンタ４００及びネットワーク６００のリソース（例えば，サーバ４２０，サーバ４２０に備わるＣＰＵ４２４若しくはストレージ４２５等，又は，ネットワーク６００に備わる回線等）の利用状況及び稼動状況を示す運用情報を取得し，運用情報に基づいて，リソースの起動又は停止等をし，データセンタ４００において起動するサーバ４２０，仮想サーバのイメージ（サーバテンプレート）の変更及び管理を行い，データセンタ４００において動作するサーバ４２０（仮想サーバを含む）の状況を，データセンタ４００の管理ＡＰＩから取得し，
　利用者は，特定のサービスを利用する要求を，クライアント１００に入力するため，ブラウザ画面を起動させ，キーボードによって文字を入力したり，又は，マウスによってブラウザ画面上のボタンをクリックするなどの操作によって，利用要求をクライアント１００に入力し，
　受信されたリクエストに，測定用の情報を付加し，付加される測定用の情報とは，サーバ４２０−１が保持する情報であり，測定用の情報には，サーバ４２０−１において発生したエラー等を示す情報などが含まれ，
　クライアント１００は，処理結果と測定用の情報とを受信した後，処理結果を画面に表示し，サーバ４２０−１からクライアント１００までの経路情報，エラー情報，検証用情報，クライアント１００の情報，サーバ４２０−１にリクエストしたサービス名，アクセスしたＵＲＩ，受信したデータ量，処理時間，及び，タイムスタンプ（クライアント１００が処理を開始又は終了した時刻）などをさらに測定し，
　サーバ４２０が特定のサービスを提供しないことによって，通信を中継したサーバ４２０からエラー応答が返答された場合，通信制御部１１０は，構成管理部２３０に対応情報の取得を指示し，
　構成管理部２３０は，エラーが発生しているサーバ４２０の状況を運用サーバ３００，又は，データセンタ４００に備わる管理装置に問い合わせ，サーバ４２０の状況を取得し，通信に対する利用コストを算出し，算出されたサービス品質と利用コストとを，サーバリソースのパターンごとに取得し，あらかじめ定められたポリシー（例えば，「利用コストが最低である」，「あるサービス品質ができる限り高く，かつ，利用コストが最低の場合と比較し１．３倍以内である」，「すべてのサービス品質が定められた範囲内である」，又は，「あるサービス品質が最も高い」など）に従って，特定のサービスを提供するために最適なシステムの構成が抽出され，
　運用サーバ３００が，サーバ４２０等の性能をテストしてもよく，管理サーバ２００は，運用サーバ３００からサーバ４２０等の運用情報を取得し，ストレージ２４０の運用情報２４５に格納し，取得した運用情報２４５に従って，サーバリソースの構成を決定してもよく，取得した運用情報２４５が，サービスを提供可能なサーバ４２０が停止していることを示す場合，管理サーバ２００は，サービスを提供可能な別のサーバ４２０をサーバリソースの構成に決定してもよい
　方法。」
２　引用例２に記載された事項
　原審拒絶理由及び，当審拒絶理由において引用された，本願の第一国出願前に既に公知である，中田　敦，「クローズアップ　ＡＰＩでクラウドの利便性高める　運用自動化やサービス連携を実現」，日経コンピュータ，日経ＢＰ社，２０１１年　８月１８日，第７８９号，ｐｐ．６８−７５（以下，これを「引用例２」という。）には，関連する図面と共に，次の事項が記載されている。
Ｌ　「
クラウドの管理用ＡＰＩとは、仮想マシンの作成や終了、仮想ディスクの管理などを、プログラムから操作できるようにするもの
Ｍ　「
クラウドの管理用ＡＰＩを使うと、○１（当審注：○の中に数字の１。以下同様。）プログラムやスクリプトを用いた運用の自動化、○２標準以外の管理ツールの活用、○３異なるクラウド間の連携−などが可能になる
Ｎ　「障害復旧を自動化
　
システム監視と管理用ＡＰＩを組み合わせることで、障害復旧処理も自動化できる
監視ツールで仮想マシンの異常などを検出した場合に、それをトリガーに、自動化プログラムを実行する
３　引用例３に記載された事項
　原審拒絶理由において引用された，本願の第一国出願前に既に公知である，特開２０１１−２５３２１２号公報（平成２３年１２月１５日公開。以下，これを「引用例３」という。）には，関連する図面と共に，次の事項が記載されている。
Ｏ　「【００２６】
　図４に示した
ネットワークシステム
クラウド環境
Ｐ　「【００４６】
・処理動作の説明
　図６は、異常の起点候補の評価に関する処理を説明するフローチャートである。図６に示したように、まず、ネットワークの状態を監視する装置が自ドメインの異常を検知する（Ｓ１０１）。
異常を検知する装置は、探索装置であってもよいし、他の監視装置であっても良い
【００４７】
　つぎに、探索装置が自ドメインの障害ＤＢを参照し、異常起点調査処理（Ｓ１０２）を行って、結果を集計し（Ｓ１０３）、出力する（Ｓ１０４）。
【００４８】
　なお、
異常検知（Ｓ１０１）は、随時行うことが望ましい。また、異常起点調査処理（Ｓ１０２）は、ユーザが指定したタイミングで行なっても良いし、定期的に実行しても良い。また、異常の検知と連動して実行することとしても良い
４　引用例４に記載された事項
　原審拒絶理由において引用された，本願の第一国出願前に既に公知である，香川　康介，外４名，「ＯＳＳを構成するプライベートクラウド運用管理システムの実用化」，電子情報通信学会技術研究報告，社団法人電子情報通信学会，２０１１年１１月　３日，第１１１巻，第２７９号，ｐｐ．１３−１８，ＩＣＭ２０１１−２２　情報通信マネジメント（以下，これを「引用例４」という。）には，関連する図面と共に，次の事項が記載されている。
Ｑ　「３．１．ＯＳＳを実現するＤ３Ａとは
　本アーキテクチャを図３に示す．本アーキテクチャは，以下に示す，６つの機能から構成される．
○１物理エレメント（ＰＥ：Ｐｈｙｓｉｃａｌ  Ｅｌｅｍｅｎｔ）
○２論理エレメント（ＬＥ：Ｌｏｇｉｃａｌ  Ｅｌｅｍｅｎｔ）
○３論理経路データ（ＬＰＤ：Ｌｏｇｉｃａｌ  Ｐａｔｈ  Ｄａｔａ）
○４ＬＰＤドライバ（ＬＰＤＤ：ＬＰＤ  Ｄｒｉｖｅｒ）
○５ＬＰＤマネージャ（ＬＰＤＭ：ＬＰＤ  Ｍａｎａｇｅｒ）
○６エレメント構成マネージャ
（ＥＣＭ：  Ｅｌｅｍｅｎｔ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ  Ｍａｎａｇｅｒ）」（１４ページ右欄１５乃至２４行）
Ｒ　「５．１．ＰＥ／ＬＥ障害箇所の位置特定
　ＰＥ／ＬＥ障害箇所の位置特定方式について説明する．
５．１．１　ＰＥ障害検出方式
　ＰＥの監視方式を図４に示す．
図４　ＰＥ監視方式
ＰＥのリソースや障害を監視するリソース監視ＬＥを各ＰＥに配備する．リソース監視ＬＥの実現機能について説明する．
…（中略）…
これらのことにより，ハードウェアやミドルウェアの障害箇所の特定を可能とし，
異常を検出したリソース監視ＬＥは，障害状況を一元管理するＥＣＭに対して障害内容および該当ＰＥのＩＰアドレス情報を通知する．システム管理者は，この障害状況を確認することで，どのＰＥがどのような障害となっているかを確実に知ることができる
Ｓ　「５．１．２　ＬＥ障害検出方式
　ＬＥ（ＨＬＥ）の監視方式を図５に示す．
図５　ＬＥ監視方式
…（中略）…
システム管理者は，ＥＣＭで管理される障害情報を確認することで，どのＨＬＥが異常なのか確実に知ることができる
第５　対比・判断
１　本願発明１について
（１）　対比
　本願発明１と引用発明とを対比する。
（あ）引用発明は，「クライアント１００，管理サーバ２００，運用サーバ３００，及び，複数のデータセンタ４００（４００−１，４００−２）を備えるサーバ構成管理システムで実施される方法」であって，当該「サーバ構成管理システム」は，「前記サーバ構成管理システムの利用者」が「ＩａａＳ，ＰａａＳと呼ばれるような，クラウド基盤提供サービスが提供する，サーバ，仮想サーバ，ネットワーク，及び，ストレージ等のサービス提供品質を吟味し，その全部又は一部を利用することによって，情報システムを構築する」際のシステムに関するものである。また引用発明の「リソース」は，「例えば，サーバ４２０，サーバ４２０に備わるＣＰＵ４２４若しくはストレージ４２５等，又は，ネットワーク６００に備わる回線等」であって，これらは「１つ以上のリソースの集合」といい得，「運用サーバ３００」は，「サービスを管理するためのサーバであって，サーバ４２０を含むデータセンタ４００及びネットワーク６００のリソース（例えば，サーバ４２０，サーバ４２０に備わるＣＰＵ４２４若しくはストレージ４２５等，又は，ネットワーク６００に備わる回線等）の利用状況及び稼動状況を示す運用情報を取得し，運用情報に基づいて，リソースの起動又は停止等をし，データセンタ４００において起動するサーバ４２０，仮想サーバのイメージ（サーバテンプレート）の変更及び管理を行」う一方，「利用者」は，「特定のサービスを利用する要求を，クライアント１００に入力」し，「受信されたリクエストに，測定用の情報を付加し，付加される測定用の情報とは，サーバ４２０−１が保持する情報であり，測定用の情報には，サーバ４２０−１において発生したエラー等を示す情報などが含まれ」，当該「クライアント１００」は，「処理結果と測定用の情報とを受信した後，処理結果を画面に表示」するシステムであるから，引用発明と本願発明１とは“ユーザ用のクラウド内の１つ以上のリソースの集合をコンピュータが検証する方法”である点で一致するといえる。
（い）引用発明は，「利用者」が「特定のサービスを利用する要求を，クライアント１００に入力するため，ブラウザ画面を起動させ，キーボードによって文字を入力したり，又は，マウスによってブラウザ画面上のボタンをクリックするなどの操作によって，利用要求をクライアント１００に入力」するものであり，また「運用サーバ３００」は，「データセンタ４００において動作するサーバ４２０（仮想サーバを含む）の状況を，データセンタ４００の管理ＡＰＩから取得」することから，上記（あ）の認定も踏まえると，引用発明と本願発明１とは，“前記１つ以上のリソースの集合は，アプリケーションプログラミングインタフェース（API）呼出（call）を利用して受け取られ”る点で一致するといえる。
（う）引用発明は，「運用サーバ３００が，サーバ４２０等の性能をテストしてもよく」，「取得した運用情報２４５が，サービスを提供可能なサーバ４２０が停止していることを示す場合，管理サーバ２００は，サービスを提供可能な別のサーバ４２０をサーバリソースの構成に決定してもよい」ものであることから，引用発明と本願発明１とは，“検出された前記欠陥を解決するステップ”を有する点，及び“前記欠陥が解決された前記インフラストラクチャをユーザに提供するリソースの集合であるサービスクラスタに含ませるステップ”を有する点で一致するといえる。
（え）上記（う）の認定により，引用発明は，「取得した運用情報２４５が，サービスを提供可能なサーバ４２０が停止していることを示す場合，管理サーバ２００は，サービスを提供可能な別のサーバ４２０をサーバリソースの構成に決定」するものであり，ユーザに対しては，「欠陥がなく機能しているリソースのみをユーザに提供」しているともいえることから，引用発明と本願発明１とは，“前記サービスクラスタに含まれる欠陥がなく機能しているリソースのみをユーザに提供するステップ”を有する点で一致するといえる。
（お）以上，（あ）乃至（え）の検討から，引用発明と本願発明１とは，次の一致点及び相違点を有する。
〈一致点〉
　ユーザ用のクラウド内の１つ以上のリソースの集合をコンピュータが検証する方法であって，前記１つ以上のリソースの集合は，アプリケーションプログラミングインタフェース（API）呼出（call）を利用して受け取られ，該方法は，
　検出された前記欠陥を解決するステップと，
　前記欠陥が解決された前記インフラストラクチャをユーザに提供するリソースの集合であるサービスクラスタに含ませるステップと，
　前記サービスクラスタに含まれる欠陥がなく機能しているリソースのみをユーザに提供するステップと，
　を含む方法。
〈相違点１〉
　本願発明１が，「前記１つ以上のリソースの集合に含まれるインフラストラクチャに対し、予め定義されたチェック及びユーザが定義したチェックを含むチェックを実行し、前記インフラストラクチャを不能にする欠陥を検出するステップ」を含むのに対し，引用発明は，そのようなステップを含むことが特定されていない点。
〈相違点２〉
　本願発明１が，「前記コンピュータが、欠陥を有するインフラストラクチャの検出法及び解決法を、先行／後続するAPI呼出の間に登録し、それにより、エンドユーザが前記欠陥に対処する必要性をなくすことを特徴とする」ものであるのに対し，引用発明は，そのような構成が特定されていない点。
（２）　相違点についての判断
　事案に鑑み，先に相違点２について検討する。
　引用発明は，「構成管理部２３０」が，「エラーが発生しているサーバ４２０の状況を運用サーバ３００，又は，データセンタ４００に備わる管理装置に問い合わせ，サーバ４２０の状況を取得し，通信に対する利用コストを算出し，算出されたサービス品質と利用コストとを，サーバリソースのパターンごとに取得し，あらかじめ定められたポリシー（例えば，「利用コストが最低である」，「あるサービス品質ができる限り高く，かつ，利用コストが最低の場合と比較し１．３倍以内である」，「すべてのサービス品質が定められた範囲内である」，又は，「あるサービス品質が最も高い」など）に従って，特定のサービスを提供するために最適なシステムの構成が抽出され」るものであったり，「運用サーバ３００が，サーバ４２０等の性能をテスト」するよう構成され，「取得した運用情報２４５が，サービスを提供可能なサーバ４２０が停止していることを示す場合，管理サーバ２００は，サービスを提供可能な別のサーバ４２０をサーバリソースの構成に決定」するものでもあるが，本願発明１の「欠陥を有するインフラストラクチャの検出法及び解決法」に対応する具体的な手法を提供するものではなく，当該「欠陥を有するインフラストラクチャの検出法及び解決法」を，「欠陥を検出するために、特定の属性が所定のチェック基準を満たすものか否かで欠陥の判定する」「通常使用されている検出手法」であったと解したとしても，さらに，「先行／後続するAPI呼出の間に登録」すること，すなわち，本願発明１の相違点２に係る構成とすることは当業者にとって容易であったとまではいえず，また「欠陥を有するインフラストラクチャの検出法及び解決法を、先行／後続するAPI呼出の間に登録」することは，その他引用例２乃至引用例４の上記記載事項Ｌ乃至Ｓにおいても記載乃至示唆は認められない。
　したがって，上記その余の相違点について判断するまでもなく，本願発明１は，当業者であっても，引用発明及び引用例２乃至４に記載された技術的事項に基づいて容易に発明できたものとはいえない。
２　本願発明２乃至４について
　本願発明２乃至４は，本願発明１をさらに限定するものであり，本願発明１と同じ理由により，当業者であっても，引用発明及び引用例２乃至４に記載された技術的事項に基づいて容易に発明できたものとはいえない。
３　本願発明５について
　本願発明５は，本願発明１と同じく，「欠陥を有するインフラストラクチャの検出法及び解決法を、先行／後続するAPI呼出の間に登録し、それにより、エンドユーザが前記欠陥に対処する必要性をなくすことを特徴とする」との構成を有するものであり，本願発明１と同じ理由により，当業者であっても，引用発明及び引用例２乃至４に記載された技術的事項に基づいて容易に発明できたものとはいえない。
４　本願発明６について
　本願発明６は，本願発明５をさらに限定するものであり，本願発明５と同じ理由により，当業者であっても，引用発明及び引用例２乃至４に記載された技術的事項に基づいて容易に発明できたものとはいえない。
第６　当審拒絶理由の概要
１　特許法３６条６項２号及び４項１号について
　当審より，下記（１）乃至（７）の点につき，特許請求の範囲の記載が不明確であり，また本願明細書の発明の詳細な説明の記載は，当業者が本願発明１乃至本願発明６を実施できる程度の記載ではない旨通知したが，上記第３に示すとおり補正され，（４）及び（６）については不備が解消され，令和元年５月３１日付け意見書において，（１），（２）及び（５）については，「欠陥を検出するために、特定の属性が所定のチェック基準を満たすものか否かで欠陥の判定することが通常行われているところである。本願発明も、このような通常使用されている検出手法を採用しており、特異な検出法を用いるものではない。」旨，（３）については，「「無欠陥リソースのリスト」とは、欠陥ではないと判定されたリソース（インフラストラクチャ等）の情報を集積したリストという意味で用いて」いる旨，（７）については，「判定の結果、欠陥ありと判定されたインフラストラクチャであっても、治癒可能なものは欠陥を治癒した上で、サービスクラスタに含ませるようにしている。他方、欠陥の程度が重く治癒が不可能なインフラストラクチャは、サービスクラスタに含ませることはなく、ユーザに提供するリソースから除外されることになる」旨釈明され，上記拒絶理由は解消した。
２　特許法２９条２項について
　当審より，本願発明１乃至６は，上記引用例１及び２に記載された発明に基づいて当業者が容易になし得たものであり，特許法２９条２項の規定により特許することができない旨通知したが，令和元年５月３１日付け手続補正書によって，上記第３のとおり補正されたことにより，上記第５に示したとおり上記拒絶理由は解消した。
第７　原査定についての判断
　令和元年５月３１日付けの補正により，上記第３に示したとおりに補正された。そして，「欠陥を有するインフラストラクチャの検出法及び解決法を、先行／後続するAPI呼出の間に登録し、それにより、エンドユーザが前記欠陥に対処する必要性をなくすことを特徴とする」ことは，原査定における引用文献１乃至４（上記第４における，引用例１乃至４）には記載されておらず，本願優先日前における周知技術でもないので，本願発明１乃至６は，当業者であっても，原査定における引用文献１乃至４に基づいて容易に発明できたものではない。したがって，原査定を維持することはできない。
第８　むすび
　以上のとおり，原査定の理由によっては，本願を拒絶することはできない。
　また，他に本願を拒絶すべき理由を発見しない。
　よって，結論のとおり審決する。