ポートフォリオを新規に作成して保存 |
|
|
既存のポートフォリオに追加保存 |
|
PDFをダウンロード |
審決分類 |
審判 査定不服 特36条6項1、2号及び3号 請求の範囲の記載不備 取り消して特許、登録 G06F 審判 査定不服 特36条4項詳細な説明の記載不備 取り消して特許、登録 G06F 審判 査定不服 2項進歩性 取り消して特許、登録 G06F |
---|---|
管理番号 | 1354590 |
審判番号 | 不服2018-6857 |
総通号数 | 238 |
発行国 | 日本国特許庁(JP) |
公報種別 | 特許審決公報 |
発行日 | 2019-10-25 |
種別 | 拒絶査定不服の審決 |
審判請求日 | 2018-05-21 |
確定日 | 2019-09-10 |
事件の表示 | 特願2015-517481「クラウドインフラストラクチャ内のインフラストラクチャ欠陥を自動的に検出及び解決する方法及びシステム」拒絶査定不服審判事件〔平成25年12月19日国際公開、WO2013/188883、平成27年 7月 9日国内公表、特表2015-519676、請求項の数(6)〕について、次のとおり審決する。 |
結論 | 原査定を取り消す。 本願の発明は、特許すべきものとする。 |
理由 |
第1 手続の経緯 本願は,2013年6月17日(パリ条約による優先権主張外国庁受理2012年6月15日,米国)を国際出願日とする出願であって,平成27年1月27日に特許法184条の4第1項の規定による明細書,請求の範囲,及び,図面(図面の中の説明に限る)の日本語による翻訳文が提出され,平成28年6月17日に手続補正書が提出され,同年9月30日付けで拒絶の理由が通知され,平成29年4月4日に意見書とともに手続補正書が提出され,同年6月29日付けで拒絶の理由が通知され,同年10月16日に意見書とともに手続補正書が提出され,平成30年1月15日付けで拒絶査定(謄本送達日同年1月19日)がなされ,これに対して同年5月21日に審判請求がなされると共に手続補正がなされ,同年7月31日付けで審査官により特許法164条3項の規定に基づく報告がなされ,平成31年3月27日付けで当審により拒絶の理由が通知され,令和元年5月31日に意見書とともに手続補正書が提出されたものである。 第2 原査定の概要 原査定(平成30年1月15日付け拒絶査定)の概要は次のとおりである。 この出願の下記の請求項に係る発明は、その出願前に日本国内又は外国において、頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。 記 (引用文献等については引用文献等一覧参照) ・請求項 1-6 ・引用文献等 1-4 <引用文献等一覧> 1.特開2012-22555号公報 2.中田 敦,「クローズアップ APIでクラウドの利便性高める 運用自動化やサービス連携を実現」,日経コンピュータ,日経BP社,2011年 8月18日,第789号,pp.68-75(周知技術を示す文献) 3.特開2011-253212号公報(周知技術を示す文献;新たに引用された文献) 4.香川 康介,外4名,「OSSを構成するプライベートクラウド運用管理システムの実用化」,電子情報通信学会技術研究報告,社団法人電子情報通信学会,2011年11月 3日,第111巻,第279号,pp.13-18,ICM2011-22 情報通信マネジメント (周知技術を示す文献;新たに引用された文献) 第3 本願発明 本願請求項1乃至6に係る発明(以下「本願発明1」乃至「本願発明6」という。)は,令和元年5月31日付けの手続補正書によって補正された特許請求の範囲の請求項1乃至6に記載された,次のとおりのものと認める。 「 【請求項1】 ユーザ用のクラウド内の1つ以上のリソースの集合をコンピュータが検証する方法であって、前記1つ以上のリソースの集合は、アプリケーションプログラミングインタフェース(API)呼出(call)を利用して受け取られ、該方法は、 前記1つ以上のリソースの集合に含まれるインフラストラクチャに対し、予め定義されたチェック及びユーザが定義したチェックを含むチェックを実行し、前記インフラストラクチャを不能にする欠陥を検出するステップと、 検出された前記欠陥を解決するステップと、 前記欠陥が解決された前記インフラストラクチャをユーザに提供するリソースの集合であるサービスクラスタに含ませるステップと、 前記サービスクラスタに含まれる欠陥がなく機能しているリソースのみをユーザに提供するステップと、 を含み、 前記コンピュータが、欠陥を有するインフラストラクチャの検出法及び解決法を、先行/後続するAPI呼出の間に登録し、それにより、エンドユーザが前記欠陥に対処する必要性をなくすことを特徴とする方法。 【請求項2】 前記欠陥を解決するステップは、ユーザに提供するリソースから、前記欠陥が検出されたインフラストラクチャを除外することを含む請求項1記載の方法。 【請求項3】 前記欠陥を解決するステップは、ユーザに提供するリソースから、前記欠陥が検出されたインフラストラクチャを修正することを含む請求項1記載の方法。 【請求項4】 コンピュータに請求項1?3のいずれか1項に記載の方法を実行させるプログラム。 【請求項5】 クラウド内のリソースを検証する管理サーバが、無欠陥リソースのリストを維持するために実行する方法であって、 (a)サーバにログインできるかを検査するステップと、 (b)前記サーバ内のファイルシステムにアクセスできるかを検査するステップと、 (c)前記ステップ(a)及び(b)の結果を前記管理サーバ、又は、アプリケーションプログラミングインタフェース(API)呼出(call)を利用して前記クラウドにアクセスするクライアントの少なくとも1つに通知するステップと、 を有し、 前記ステップ(a)乃至(c)の何れかにおいて欠陥が検出された場合、(d)検査のために前記欠陥が検出されたリソースをホールドするステップ、(e)前記欠陥が検出されたリソースが再び取得されないことを確実にするステップ及び(f)機能しているリソースのみがユーザに提供されるように、リソースをシャットダウンするステップのうちの少なくとも1つを実行し、 前記管理サーバが、欠陥を有するインフラストラクチャの検出法及び解決法を、先行/後続するAPI呼出の間に登録し、それにより、エンドユーザが前記欠陥に対処する必要性をなくすことを特徴とする、方法。 【請求項6】 前記ステップ(a)乃至(c)の何れにおいても欠陥が検出されなかった場合、前記サーバを、クライアントに提供するリソースの集合であるサーバクラスタに含ませるステップを更に有する請求項5記載の方法。」 第4 引用例 1 引用例1に記載された事項及び引用発明 原審の平成29年6月29日付けの拒絶理由(以下,「原審拒絶理由」という。)及び,平成31年3月27日付け当審拒絶理由(以下,単に「当審拒絶理由」という。)において引用した,本願の第一国出願前に既に公知である,特開2012-22555号公報(平成24年2月2日公開。以下,これを「引用例1」という。)には,関連する図面と共に,次の事項が記載されている。(なお,下線は当審で説明のために付加。以下同様。) A 「【0010】 近年、IaaS(Infrastructure as a Service)、PaaS(Platform as a Service)と呼ばれるような、クラウド基盤を提供するサービスが普及している。これまでWAN又はLANに構成されたイントラネット上で提供されていた情報システムを、前述のクラウド基盤提供サービスを利用して、構築する例が増えている。 【0011】 クラウド基盤提供サービスを利用して情報システムを構築する場合、情報システムの利用者は、クラウド基盤提供サービスが提供する、サーバ、仮想サーバ、ネットワーク、及び、ストレージ等のサービス提供品質を吟味し、その全部又は一部を利用することによって、情報システムを構築する。しかし、クラウド基盤提供サービスが提供するサーバ、仮想サーバ、ネットワーク、及び、ストレージの性能は、他のユーザの利用状況などによって変化することが多い。そのため、情報システムを利用する利用者が、一定のサービス提供品質を維持しながら利用しようとしても、利用者の体感品質が悪化する可能性がある。」 B 「【0022】 本実施形態のサーバ構成管理システムは、クライアント100、管理サーバ200、運用サーバ300、及び、複数のデータセンタ400(400-1、400-2)を備え、各々の要素は、ネットワーク600を介して接続される。」 C 「【0038】 利用者は、クライアント100を利用して、後述するサーバ420にリクエストを送信する。そして利用者は、クライアント100を介して、各サーバ420から処理結果を受信する。この際、リクエストを送信するサーバ420を特定するため、通信プログラム130は、いずれかの通信制御部110にリクエストを送信する。」 D 「【0044】 なお、管理サーバ200及び運用サーバ300のハードウェア構成は、図2に示すクライアント100のハードウェア構成と同じく、一般的なサーバと同じである。また、クライアント100、管理サーバ200、運用サーバ300は、すべて又は一部を仮想化され、一つ又は複数の計算機によって実装されてもよい。」 E 「【0049】 (運用サーバ300) さらに、運用サーバ300の機能を説明する。運用サーバ300は、サービスを管理するためのサーバである。運用サーバ300は、サーバ420を含むデータセンタ400及びネットワーク600のリソース(例えば、サーバ420、サーバ420に備わるCPU424若しくはストレージ425等、又は、ネットワーク600に備わる回線等)の利用状況及び稼動状況を示す運用情報を取得し、運用情報に基づいて、リソースの起動又は停止等をする。」 F 「【0054】 また、運用サーバ300は、データセンタ400において起動するサーバ420、仮想サーバのイメージ(サーバテンプレート)の変更及び管理を行う。また、データセンタ400において動作するサーバ420(仮想サーバを含む)の状況を、データセンタ400の管理APIから取得する。」 G 「【0056】 まず利用者は、特定のサービスを利用する要求を、クライアント100に入力する(800)。例えば、サーバ420が一般的なWEBアプリケーションを保持する場合、クライアント100上の通信プログラム130は、WEBブラウザである。この時利用者は、ブラウザ画面を起動させ、キーボードによって文字を入力したり、又は、マウスによってブラウザ画面上のボタンをクリックするなどの操作によって、利用要求をクライアント100に入力する。」 H 「【0060】 受信されたリクエストがサーバ420-1によって処理された後、サーバ420-1は、サーバ420-1による処理結果に、測定用の情報を付加する(803)。付加される測定用の情報とは、サーバ420-1が保持する情報である。 【0061】 測定用の情報には、サーバ420-1を一意に示すサーバID、サーバ420-1までの経路を示す経路情報、サーバ420-1がリクエストを処理するために要する時間を示す処理時間、リクエストを処理した時刻を示す処理時刻、ネットワーク600におけるスループット、リクエストに関する利用者認証情報、及び、サーバ420-1において発生したエラー等を示す情報などが含まれる。 【0062】 シーケンス803の後、処理結果と測定用の情報とは、通信制御部110-1へ返信される(804)。通信制御部110-1は、クライアント100へ処理結果と測定用の情報とを送信する(805)。 【0063】 クライアント100は、処理結果と測定用の情報とを受信した後、処理結果を画面に表示するなど、リクエストに対応する処理を行う。また性能測定部120は、サーバ420-1からクライアント100までの経路情報、エラー情報、検証用情報、クライアント100の情報、サーバ420-1にリクエストしたサービス名、アクセスしたURI、受信したデータ量、処理時間、及び、タイムスタンプ(クライアント100が処理を開始又は終了した時刻)などをさらに測定する。そして、クライアント100によって測定された情報に、サーバ420-1から送られた測定用の情報を付加する。そして、クライアント100によって測定された情報と、サーバ420-1から送られた測定用の情報とを含む測定用の情報を、測定結果141に格納する(806)。」 I 「【0078】 いずれかの通信制御部110において、管理サーバ200によって提供された対応情報と相違する内容が検出された場合、例えば、サーバ420が特定のサービスを提供しないことによって、通信を中継したサーバ420からエラー応答が返答された場合、通信制御部110は、構成管理部230に対応情報の取得を指示する。 【0079】 そして、構成管理部230は、エラーが発生しているサーバ420の状況を運用サーバ300、又は、データセンタ400に備わる図示しない管理装置に問い合わせ、サーバ420の状況を取得する。そして、構成管理部230は、取得した結果を構成情報242に格納し、対応情報の取得を指示した通信制御部110に、対応情報を送信する。」 J 「【0088】 なお、運用サーバ300が、サーバ420等の性能をテストしてもよい。この場合、運用サーバ300によって、サーバ420等のテスト結果が管理サーバ200に送られ、テスト情報244に格納される。 【0089】 また、前述の通り、運用サーバ300は、サーバ420を含むデータセンタ400及びネットワーク600の運用情報を取得している。このため、管理サーバ200は、運用サーバ300からサーバ420等の運用情報を取得し、ストレージ240の運用情報245に格納する。そして、取得した運用情報245に従って、サーバリソースの構成を決定してもよい。 【0090】 例えば、取得した運用情報245が、サービスを提供可能なサーバ420が停止していることを示す場合、管理サーバ200は、サービスを提供可能な別のサーバ420をサーバリソースの構成に決定してもよい。」 K 「【0098】 また、構成管理部230は、前述のように算出されたサーバ420の通信完了時間と、ストレージ240に格納される情報のうちの経路情報と、課金情報243とに基づいて、通信に対する利用コストを算出する。さらに構成管理部230は、これらの算出された利用コストの情報を、利用するサーバリソースのパターンごとに取得し、利用者へ提供する総コストを算出する。 【0099】 次に、前述のように算出されたサービス品質と利用コストとを、サーバリソースのパターンごとに取得し、あらかじめ定められたポリシー(例えば、「利用コストが最低である」、「あるサービス品質ができる限り高く、かつ、利用コストが最低の場合と比較し1.3倍以内である」、「すべてのサービス品質が定められた範囲内である」、又は、「あるサービス品質が最も高い」など)に従って、特定のサービスを提供するために最適なシステムの構成が抽出される。」 上記記載事項A乃至Kから,引用例1には,次の発明(以下,「引用発明」という。)が記載されているといえる。 「クライアント100,管理サーバ200,運用サーバ300,及び,複数のデータセンタ400(400-1,400-2)を備えるサーバ構成管理システムで実施される方法であって, 前記サーバ構成管理システムの利用者は,IaaS,PaaSと呼ばれるような,クラウド基盤提供サービスが提供する,サーバ,仮想サーバ,ネットワーク,及び,ストレージ等のサービス提供品質を吟味し,その全部又は一部を利用することによって,情報システムを構築するものであって, 前記利用者は,クライアント100を利用して,サーバ420にリクエストを送信し, クライアント100,管理サーバ200,運用サーバ300は,すべて又は一部を仮想化され,一つ又は複数の計算機によって実装されてもよく, 運用サーバ300は,サービスを管理するためのサーバであって,サーバ420を含むデータセンタ400及びネットワーク600のリソース(例えば,サーバ420,サーバ420に備わるCPU424若しくはストレージ425等,又は,ネットワーク600に備わる回線等)の利用状況及び稼動状況を示す運用情報を取得し,運用情報に基づいて,リソースの起動又は停止等をし,データセンタ400において起動するサーバ420,仮想サーバのイメージ(サーバテンプレート)の変更及び管理を行い,データセンタ400において動作するサーバ420(仮想サーバを含む)の状況を,データセンタ400の管理APIから取得し, 利用者は,特定のサービスを利用する要求を,クライアント100に入力するため,ブラウザ画面を起動させ,キーボードによって文字を入力したり,又は,マウスによってブラウザ画面上のボタンをクリックするなどの操作によって,利用要求をクライアント100に入力し, 受信されたリクエストに,測定用の情報を付加し,付加される測定用の情報とは,サーバ420-1が保持する情報であり,測定用の情報には,サーバ420-1において発生したエラー等を示す情報などが含まれ, クライアント100は,処理結果と測定用の情報とを受信した後,処理結果を画面に表示し,サーバ420-1からクライアント100までの経路情報,エラー情報,検証用情報,クライアント100の情報,サーバ420-1にリクエストしたサービス名,アクセスしたURI,受信したデータ量,処理時間,及び,タイムスタンプ(クライアント100が処理を開始又は終了した時刻)などをさらに測定し, サーバ420が特定のサービスを提供しないことによって,通信を中継したサーバ420からエラー応答が返答された場合,通信制御部110は,構成管理部230に対応情報の取得を指示し, 構成管理部230は,エラーが発生しているサーバ420の状況を運用サーバ300,又は,データセンタ400に備わる管理装置に問い合わせ,サーバ420の状況を取得し,通信に対する利用コストを算出し,算出されたサービス品質と利用コストとを,サーバリソースのパターンごとに取得し,あらかじめ定められたポリシー(例えば,「利用コストが最低である」,「あるサービス品質ができる限り高く,かつ,利用コストが最低の場合と比較し1.3倍以内である」,「すべてのサービス品質が定められた範囲内である」,又は,「あるサービス品質が最も高い」など)に従って,特定のサービスを提供するために最適なシステムの構成が抽出され, 運用サーバ300が,サーバ420等の性能をテストしてもよく,管理サーバ200は,運用サーバ300からサーバ420等の運用情報を取得し,ストレージ240の運用情報245に格納し,取得した運用情報245に従って,サーバリソースの構成を決定してもよく,取得した運用情報245が,サービスを提供可能なサーバ420が停止していることを示す場合,管理サーバ200は,サービスを提供可能な別のサーバ420をサーバリソースの構成に決定してもよい 方法。」 2 引用例2に記載された事項 原審拒絶理由及び,当審拒絶理由において引用された,本願の第一国出願前に既に公知である,中田 敦,「クローズアップ APIでクラウドの利便性高める 運用自動化やサービス連携を実現」,日経コンピュータ,日経BP社,2011年 8月18日,第789号,pp.68-75(以下,これを「引用例2」という。)には,関連する図面と共に,次の事項が記載されている。 L 「クラウドの管理用APIとは、仮想マシンの作成や終了、仮想ディスクの管理などを、プログラムから操作できるようにするものだ。こうした操作は通常、ユーザーが管理コンソールを使って行う。管理用APIを使うと、それらをプログラムからでも実行できるようになる。」(68ページ右欄12乃至20行) M 「クラウドの管理用APIを使うと、○1(当審注:○の中に数字の1。以下同様。)プログラムやスクリプトを用いた運用の自動化、○2標準以外の管理ツールの活用、○3異なるクラウド間の連携-などが可能になる。」(70ページ左欄11乃至16行) N 「障害復旧を自動化 システム監視と管理用APIを組み合わせることで、障害復旧処理も自動化できる。監視ツールで仮想マシンの異常などを検出した場合に、それをトリガーに、自動化プログラムを実行するのだ。…(中略)…仮想マシンの稼働状況は、OSSの運用監視ツール「Nagios」で監視する。クラスター内のサーバーが1台故障した場合に、新しいサーバーを自動起動し、管理用APIを使って代替サーバーをロードバランサーに追加する。仮想マシンの稼働状況に応じて仮想マシンの台数を増やしたり減らしたりする「オートスケーリング」も、運用監視と管理用APIを組み合わせることで実現する。」(71ページ左欄下から11行乃至右欄下から1行) 3 引用例3に記載された事項 原審拒絶理由において引用された,本願の第一国出願前に既に公知である,特開2011-253212号公報(平成23年12月15日公開。以下,これを「引用例3」という。)には,関連する図面と共に,次の事項が記載されている。 O 「【0026】 図4に示したネットワークシステムの構成は、物理マシンであるサーバpm11?13が仮想マシンプログラムを実行することで仮想マシンVM11?16として動作し、仮想マシン上でApp11?16が動作し、サービスSv11が提供されるクラウド環境である。」 P 「【0046】 ・処理動作の説明 図6は、異常の起点候補の評価に関する処理を説明するフローチャートである。図6に示したように、まず、ネットワークの状態を監視する装置が自ドメインの異常を検知する(S101)。異常を検知する装置は、探索装置であってもよいし、他の監視装置であっても良い。異常を検知した装置は、検知結果を自ドメインの障害DBに登録する。 【0047】 つぎに、探索装置が自ドメインの障害DBを参照し、異常起点調査処理(S102)を行って、結果を集計し(S103)、出力する(S104)。 【0048】 なお、異常検知(S101)は、随時行うことが望ましい。また、異常起点調査処理(S102)は、ユーザが指定したタイミングで行なっても良いし、定期的に実行しても良い。また、異常の検知と連動して実行することとしても良い。」 4 引用例4に記載された事項 原審拒絶理由において引用された,本願の第一国出願前に既に公知である,香川 康介,外4名,「OSSを構成するプライベートクラウド運用管理システムの実用化」,電子情報通信学会技術研究報告,社団法人電子情報通信学会,2011年11月 3日,第111巻,第279号,pp.13-18,ICM2011-22 情報通信マネジメント(以下,これを「引用例4」という。)には,関連する図面と共に,次の事項が記載されている。 Q 「3.1.OSSを実現するD3Aとは 本アーキテクチャを図3に示す.本アーキテクチャは,以下に示す,6つの機能から構成される. ○1物理エレメント(PE:Physical Element) ○2論理エレメント(LE:Logical Element) ○3論理経路データ(LPD:Logical Path Data) ○4LPDドライバ(LPDD:LPD Driver) ○5LPDマネージャ(LPDM:LPD Manager) ○6エレメント構成マネージャ (ECM: Element Configuration Manager)」(14ページ右欄15乃至24行) R 「5.1.PE/LE障害箇所の位置特定 PE/LE障害箇所の位置特定方式について説明する. 5.1.1 PE障害検出方式 PEの監視方式を図4に示す. 図4 PE監視方式 PEのリソースや障害を監視するリソース監視LEを各PEに配備する.リソース監視LEの実現機能について説明する. …(中略)… これらのことにより,ハードウェアやミドルウェアの障害箇所の特定を可能とし,異常を検出したリソース監視LEは,障害状況を一元管理するECMに対して障害内容および該当PEのIPアドレス情報を通知する.システム管理者は,この障害状況を確認することで,どのPEがどのような障害となっているかを確実に知ることができる.」(15ページ右欄下から6行乃至16ページ左欄27行) S 「5.1.2 LE障害検出方式 LE(HLE)の監視方式を図5に示す. 図5 LE監視方式 …(中略)… システム管理者は,ECMで管理される障害情報を確認することで,どのHLEが異常なのか確実に知ることができる.」(16ページ左欄下から4行乃至右欄12行) 第5 対比・判断 1 本願発明1について (1) 対比 本願発明1と引用発明とを対比する。 (あ)引用発明は,「クライアント100,管理サーバ200,運用サーバ300,及び,複数のデータセンタ400(400-1,400-2)を備えるサーバ構成管理システムで実施される方法」であって,当該「サーバ構成管理システム」は,「前記サーバ構成管理システムの利用者」が「IaaS,PaaSと呼ばれるような,クラウド基盤提供サービスが提供する,サーバ,仮想サーバ,ネットワーク,及び,ストレージ等のサービス提供品質を吟味し,その全部又は一部を利用することによって,情報システムを構築する」際のシステムに関するものである。また引用発明の「リソース」は,「例えば,サーバ420,サーバ420に備わるCPU424若しくはストレージ425等,又は,ネットワーク600に備わる回線等」であって,これらは「1つ以上のリソースの集合」といい得,「運用サーバ300」は,「サービスを管理するためのサーバであって,サーバ420を含むデータセンタ400及びネットワーク600のリソース(例えば,サーバ420,サーバ420に備わるCPU424若しくはストレージ425等,又は,ネットワーク600に備わる回線等)の利用状況及び稼動状況を示す運用情報を取得し,運用情報に基づいて,リソースの起動又は停止等をし,データセンタ400において起動するサーバ420,仮想サーバのイメージ(サーバテンプレート)の変更及び管理を行」う一方,「利用者」は,「特定のサービスを利用する要求を,クライアント100に入力」し,「受信されたリクエストに,測定用の情報を付加し,付加される測定用の情報とは,サーバ420-1が保持する情報であり,測定用の情報には,サーバ420-1において発生したエラー等を示す情報などが含まれ」,当該「クライアント100」は,「処理結果と測定用の情報とを受信した後,処理結果を画面に表示」するシステムであるから,引用発明と本願発明1とは“ユーザ用のクラウド内の1つ以上のリソースの集合をコンピュータが検証する方法”である点で一致するといえる。 (い)引用発明は,「利用者」が「特定のサービスを利用する要求を,クライアント100に入力するため,ブラウザ画面を起動させ,キーボードによって文字を入力したり,又は,マウスによってブラウザ画面上のボタンをクリックするなどの操作によって,利用要求をクライアント100に入力」するものであり,また「運用サーバ300」は,「データセンタ400において動作するサーバ420(仮想サーバを含む)の状況を,データセンタ400の管理APIから取得」することから,上記(あ)の認定も踏まえると,引用発明と本願発明1とは,“前記1つ以上のリソースの集合は,アプリケーションプログラミングインタフェース(API)呼出(call)を利用して受け取られ”る点で一致するといえる。 (う)引用発明は,「運用サーバ300が,サーバ420等の性能をテストしてもよく」,「取得した運用情報245が,サービスを提供可能なサーバ420が停止していることを示す場合,管理サーバ200は,サービスを提供可能な別のサーバ420をサーバリソースの構成に決定してもよい」ものであることから,引用発明と本願発明1とは,“検出された前記欠陥を解決するステップ”を有する点,及び“前記欠陥が解決された前記インフラストラクチャをユーザに提供するリソースの集合であるサービスクラスタに含ませるステップ”を有する点で一致するといえる。 (え)上記(う)の認定により,引用発明は,「取得した運用情報245が,サービスを提供可能なサーバ420が停止していることを示す場合,管理サーバ200は,サービスを提供可能な別のサーバ420をサーバリソースの構成に決定」するものであり,ユーザに対しては,「欠陥がなく機能しているリソースのみをユーザに提供」しているともいえることから,引用発明と本願発明1とは,“前記サービスクラスタに含まれる欠陥がなく機能しているリソースのみをユーザに提供するステップ”を有する点で一致するといえる。 (お)以上,(あ)乃至(え)の検討から,引用発明と本願発明1とは,次の一致点及び相違点を有する。 〈一致点〉 ユーザ用のクラウド内の1つ以上のリソースの集合をコンピュータが検証する方法であって,前記1つ以上のリソースの集合は,アプリケーションプログラミングインタフェース(API)呼出(call)を利用して受け取られ,該方法は, 検出された前記欠陥を解決するステップと, 前記欠陥が解決された前記インフラストラクチャをユーザに提供するリソースの集合であるサービスクラスタに含ませるステップと, 前記サービスクラスタに含まれる欠陥がなく機能しているリソースのみをユーザに提供するステップと, を含む方法。 〈相違点1〉 本願発明1が,「前記1つ以上のリソースの集合に含まれるインフラストラクチャに対し、予め定義されたチェック及びユーザが定義したチェックを含むチェックを実行し、前記インフラストラクチャを不能にする欠陥を検出するステップ」を含むのに対し,引用発明は,そのようなステップを含むことが特定されていない点。 〈相違点2〉 本願発明1が,「前記コンピュータが、欠陥を有するインフラストラクチャの検出法及び解決法を、先行/後続するAPI呼出の間に登録し、それにより、エンドユーザが前記欠陥に対処する必要性をなくすことを特徴とする」ものであるのに対し,引用発明は,そのような構成が特定されていない点。 (2) 相違点についての判断 事案に鑑み,先に相違点2について検討する。 引用発明は,「構成管理部230」が,「エラーが発生しているサーバ420の状況を運用サーバ300,又は,データセンタ400に備わる管理装置に問い合わせ,サーバ420の状況を取得し,通信に対する利用コストを算出し,算出されたサービス品質と利用コストとを,サーバリソースのパターンごとに取得し,あらかじめ定められたポリシー(例えば,「利用コストが最低である」,「あるサービス品質ができる限り高く,かつ,利用コストが最低の場合と比較し1.3倍以内である」,「すべてのサービス品質が定められた範囲内である」,又は,「あるサービス品質が最も高い」など)に従って,特定のサービスを提供するために最適なシステムの構成が抽出され」るものであったり,「運用サーバ300が,サーバ420等の性能をテスト」するよう構成され,「取得した運用情報245が,サービスを提供可能なサーバ420が停止していることを示す場合,管理サーバ200は,サービスを提供可能な別のサーバ420をサーバリソースの構成に決定」するものでもあるが,本願発明1の「欠陥を有するインフラストラクチャの検出法及び解決法」に対応する具体的な手法を提供するものではなく,当該「欠陥を有するインフラストラクチャの検出法及び解決法」を,「欠陥を検出するために、特定の属性が所定のチェック基準を満たすものか否かで欠陥の判定する」「通常使用されている検出手法」であったと解したとしても,さらに,「先行/後続するAPI呼出の間に登録」すること,すなわち,本願発明1の相違点2に係る構成とすることは当業者にとって容易であったとまではいえず,また「欠陥を有するインフラストラクチャの検出法及び解決法を、先行/後続するAPI呼出の間に登録」することは,その他引用例2乃至引用例4の上記記載事項L乃至Sにおいても記載乃至示唆は認められない。 したがって,上記その余の相違点について判断するまでもなく,本願発明1は,当業者であっても,引用発明及び引用例2乃至4に記載された技術的事項に基づいて容易に発明できたものとはいえない。 2 本願発明2乃至4について 本願発明2乃至4は,本願発明1をさらに限定するものであり,本願発明1と同じ理由により,当業者であっても,引用発明及び引用例2乃至4に記載された技術的事項に基づいて容易に発明できたものとはいえない。 3 本願発明5について 本願発明5は,本願発明1と同じく,「欠陥を有するインフラストラクチャの検出法及び解決法を、先行/後続するAPI呼出の間に登録し、それにより、エンドユーザが前記欠陥に対処する必要性をなくすことを特徴とする」との構成を有するものであり,本願発明1と同じ理由により,当業者であっても,引用発明及び引用例2乃至4に記載された技術的事項に基づいて容易に発明できたものとはいえない。 4 本願発明6について 本願発明6は,本願発明5をさらに限定するものであり,本願発明5と同じ理由により,当業者であっても,引用発明及び引用例2乃至4に記載された技術的事項に基づいて容易に発明できたものとはいえない。 第6 当審拒絶理由の概要 1 特許法36条6項2号及び4項1号について 当審より,下記(1)乃至(7)の点につき,特許請求の範囲の記載が不明確であり,また本願明細書の発明の詳細な説明の記載は,当業者が本願発明1乃至本願発明6を実施できる程度の記載ではない旨通知したが,上記第3に示すとおり補正され,(4)及び(6)については不備が解消され,令和元年5月31日付け意見書において,(1),(2)及び(5)については,「欠陥を検出するために、特定の属性が所定のチェック基準を満たすものか否かで欠陥の判定することが通常行われているところである。本願発明も、このような通常使用されている検出手法を採用しており、特異な検出法を用いるものではない。」旨,(3)については,「「無欠陥リソースのリスト」とは、欠陥ではないと判定されたリソース(インフラストラクチャ等)の情報を集積したリストという意味で用いて」いる旨,(7)については,「判定の結果、欠陥ありと判定されたインフラストラクチャであっても、治癒可能なものは欠陥を治癒した上で、サービスクラスタに含ませるようにしている。他方、欠陥の程度が重く治癒が不可能なインフラストラクチャは、サービスクラスタに含ませることはなく、ユーザに提供するリソースから除外されることになる」旨釈明され,上記拒絶理由は解消した。 2 特許法29条2項について 当審より,本願発明1乃至6は,上記引用例1及び2に記載された発明に基づいて当業者が容易になし得たものであり,特許法29条2項の規定により特許することができない旨通知したが,令和元年5月31日付け手続補正書によって,上記第3のとおり補正されたことにより,上記第5に示したとおり上記拒絶理由は解消した。 第7 原査定についての判断 令和元年5月31日付けの補正により,上記第3に示したとおりに補正された。そして,「欠陥を有するインフラストラクチャの検出法及び解決法を、先行/後続するAPI呼出の間に登録し、それにより、エンドユーザが前記欠陥に対処する必要性をなくすことを特徴とする」ことは,原査定における引用文献1乃至4(上記第4における,引用例1乃至4)には記載されておらず,本願優先日前における周知技術でもないので,本願発明1乃至6は,当業者であっても,原査定における引用文献1乃至4に基づいて容易に発明できたものではない。したがって,原査定を維持することはできない。 第8 むすび 以上のとおり,原査定の理由によっては,本願を拒絶することはできない。 また,他に本願を拒絶すべき理由を発見しない。 よって,結論のとおり審決する。 |
審決日 | 2019-08-29 |
出願番号 | 特願2015-517481(P2015-517481) |
審決分類 |
P
1
8・
121-
WY
(G06F)
P 1 8・ 537- WY (G06F) P 1 8・ 536- WY (G06F) |
最終処分 | 成立 |
前審関与審査官 | 井上 宏一 |
特許庁審判長 |
辻本 泰隆 |
特許庁審判官 |
山崎 慎一 松平 英 |
発明の名称 | クラウドインフラストラクチャ内のインフラストラクチャ欠陥を自動的に検出及び解決する方法及びシステム |
代理人 | 宮前 徹 |
代理人 | 中西 基晴 |
代理人 | 上田 忠 |
代理人 | 山本 修 |
代理人 | 小野 新次郎 |