【事件の表示】
　特願２０１６−５５２９６６「リソース提供システム及び方法」拒絶査定不服審判事件〔平成２７年８月２７日国際公開，ＷＯ２０１５／１２７０７６，平成２９年３月２日国内公表，特表２０１７−５０６３９４〕について，次のとおり審決する。
【結　論】
　本件審判の請求は，成り立たない。
【理　由】
第１　手続の経緯 
　本願は，２０１５年２月１９日（パリ条約による優先権主張外国庁受理２０１４年２月１９日（以下，「優先日」という。），２０１４年１０月２０日　アメリカ合衆国）を国際出願日とする出願であって，平成２８年８月１６日に特許法第１８４条の５第１項に規定される書面の提出がなされ，同年１０月１３日付けで特許法第１８４条の４第１項の規定による国際出願日における明細書，請求の範囲，図面（図面の中の説明に限る。）及び要約の翻訳文の提出がなされ，平成３０年２月７日付けで出願審査の請求がなされ，同年１１月２０日付けで審査官により拒絶理由が通知され，これに対して平成３１年２月２０日付けで意見書が提出されるとともに手続補正がなされ，令和１年７月１６日付けで拒絶査定（以下，「原査定」という。）がなされ，これに対して同年１１月２２日付けで拒絶査定不服審判の請求がなされるとともに手続補正がなされ，令和２年２月２０日付けで審査官により特許法第１６４条第３項に定める報告（前置報告）がなされ，同年４月２２日付けで上申書が提出されたものである。
第２　令和１年１１月２２日にされた手続補正についての補正の却下の決定
［補正の却下の決定の結論］ 
　令和１年１１月２２日にされた手続補正（以下，「本件補正」という。）を却下する。 
［理由］ 
１　本件補正について（補正の内容） 
（１）本件補正後の特許請求の範囲の記載 
　本件補正により，特許請求の範囲の請求項１乃至２０の記載は，次のとおり補正された。
（下線部は，補正箇所である。以下，この特許請求の範囲に記載された請求項を「補正後の請求項」という。）
「　【請求項１】
　１つ以上のハードウェアプロセッサを有するリソースマネージャを備えたシステムであって、前記リソースマネージャは、
　実行プラットフォームによって実行される、複数のコンピュータ利用クエリソースから受信されたデータ処理要求、を監視することであって、前記データ処理要求は、複数の共有ストレージデバイス上に格納されたデータベースデータに向けられる、ことと、
　前記実行プラットフォームの複数の実行ノードの現在の利用を監視することであって、各実行ノードは
、ステートレスであり、且つ、
、各実行ノードの前記プロセッサは、前記複数の共有ストレージデバイスから分離し且つ独立している
　前記データ処理要求と、前記複数の実行ノードの現在の利用とに基づいて、追加のデータストレージ容量又は追加の処理容量の少なくとも一方が必要であると判定することと、
　前記判定に応じて、少なくとも１つの新規の実行ノードを前記実行プラットフォームに追加することにより、追加のデータストレージ容量又は追加の処理容量の少なくとも一方を割り当てることと、
　を実行するように構成され、
　前記複数の共有ストレージデバイスは前記データベースデータを纏めて格納し、前記実行プラットフォームは互いに独立にスケーリングされる、システム。
　　【請求項２】
　前記リソースマネージャは、前記データベースデータに応じたクエリ応答速度を監視するように更に構成され、追加の処理容量が必要であるか否かを判定することは、前記クエリ応答速度に更に基づく、請求項１に記載のシステム。
　　【請求項３】
　前記リソースマネージャは、前記データベースデータに応じたクエリ応答速度を監視するように更に構成され、追加のデータストレージ容量が必要であるか否かを判定することは、前記クエリ応答速度に更に基づく、請求項１に記載のシステム。
　　【請求項４】
　前記リソースマネージャは、前記追加のデータストレージ容量がもう必要ないと判定するのに応じて、前記少なくとも１つの新規の実行ノードをリリースするように更に構成されている、請求項１に記載のシステム。
　　【請求項５】
　前記リソースマネージャは、前記追加の処理容量がもう必要ないと判定するのに応じて、前記少なくとも１つの新規の実行ノードをリリースするように更に構成されている、請求項１に記載のシステム。
　　【請求項６】
　前記リソースマネージャは、前記複数の共有トレージデバイスにおける現在のデータ割り当てを監視するように更に構成され、追加のデータストレージ容量が必要であるか否かを判定することは、前記複数の共有ストレージデバイスにおける前記現在のデータ割り当てに更に基づく、請求項１に記載のシステム。
　　【請求項７】
　前記複数の実行ノードは、複数の仮想ウェアハウス内に配置されている、請求項１に記載のシステム。
　　【請求項８】
　前記複数の仮想ウェアハウスは、複数の仮想ウェアハウスグループにグループ化され、前記複数の仮想ウェアハウスグループのそれぞれは、異なるユーザのグループと関連づけられる、請求項７に記載のシステム。
　　【請求項９】
　前記複数の仮想ウェアハウスは、複数の仮想ウェアハウスグループにグループ化され、前記複数の仮想ウェアハウスグループのそれぞれは、異なるエンティティに関連づけられる、請求項７に記載のシステム。
　　【請求項１０】
　実行プラットフォームによって実行される、複数のコンピュータ利用クエリソースから受信されたデータ処理要求、を監視することであって、前記データ処理要求は、複数の共有ストレージデバイス上に格納されたデータベースデータに向けられる、ことと、
　前記実行プラットフォームの複数の実行ノードの現在の利用を監視することであって、各実行ノードは
、ステートレスであり、且つ、
、各実行ノードの前記プロセッサは、前記複数の共有ストレージデバイスから分離し且つ独立している
　前記データ処理要求と、前記複数の実行ノードの現在の利用とに基づいて、追加のデータストレージ容量又は追加の処理容量の少なくとも一方が必要であると判定することと、
　前記判定に応じて、少なくとも１つの新規の実行ノードを前記実行プラットフォームに追加することにより、追加のデータストレージ容量又は追加の処理容量の少なくとも一方を割り当てることと、
　を含み、
　前記複数の共有ストレージデバイスは前記データベースデータを纏めて格納し、前記実行プラットフォームは互いに独立にスケーリングされる、方法。
　　【請求項１１】
　前記データベースデータに応じたクエリ応答速度を監視することを更に含み、追加の処理容量が必要であるか否かを判定することは、前記クエリ応答速度に更に基づく、請求項１０に記載の方法。
　　【請求項１２】
　前記追加のデータストレージ容量がもう必要ないと判定するのに応じて、前記少なくとも１つの新規の実行ノードをリリースすることを更に含む、請求項１０に記載の方法。
　　【請求項１３】
　前記追加の処理容量がもう必要ないと判定するのに応じて、前記少なくとも１つの新規の実行ノードをリリースすることを更に含む、請求項１０に記載の方法。
　　【請求項１４】
　前記複数の共有ストレージデバイス内の現在のデータ割り当てを監視することを更に含み、追加のデータストレージ容量が必要であるか否かを判定することは、前記複数の共有ストレージデバイス内の前記現在のデータ割り当てに更に基づく、請求項１０に記載の方法。
　　【請求項１５】
　前記複数の実行ノードの各々は、複数の仮想ウェアハウス内に配置される、請求項１０に記載の方法。
　　【請求項１６】
　前記複数の仮想ウェアハウスは、複数の仮想ウェアハウスグループにグループ化され、前記複数の仮想ウェアハウスグループのそれぞれは、異なるユーザのグループと関連づけられる、請求項１５に記載の方法。
　　【請求項１７】
　特定のデータ処理要求を実行するために必要な時間を予測することと、
　現在のクエリ処理遅延を判定することと、
　前記現在のクエリ処理遅延が閾値を超えたと判定するのに応じて、新規の実行ノードを生成することであって、前記新規の実行ノードは、キャッシュとプロセッサとを含む、ことと、
　を更に含む、請求項１０に記載の方法。
　　【請求項１８】
　実行プラットフォームによって実行される、複数のコンピュータ利用クエリソースから受信されたデータ処理要求、を監視する手段であって、前記データ処理要求は、複数の共有ストレージデバイス上に格納されたデータベースデータに向けられる、手段と、
　前記実行プラットフォームの複数の実行ノードの現在の利用を監視する手段であって、各実行ノードは
、ステートレスであり、且つ、
、各実行ノードの前記プロセッサは、前記複数の共有ストレージデバイスから分離し且つ独立している
　前記データ処理要求と、前記複数の実行ノードの現在の利用とに基づいて、追加のデータストレージ容量又は追加の処理容量の少なくとも一方が必要であると判定する手段と、
　前記判定に応じて、少なくとも１つの新規の実行ノードを前記実行プラットフォームに追加することにより、追加のデータストレージ容量又は追加の処理容量の少なくとも一方を割り当てる手段と、
　を備え、
　前記複数の共有ストレージデバイスは前記データベースデータを纏めて格納し、前記実行プラットフォームは互いに独立にスケーリングされる、システム。
　　【請求項１９】
　前記追加のデータストレージ容量がもう必要ないと判定するのに応じて、前記少なくとも１つの新規の実行ノードをリリースする手段、を更に備える、請求項１８に記載のシステム。
　　【請求項２０】
　前記追加の処理容量がもう必要ないと判定するのに応じて、前記少なくとも１つの新規の実行ノードをリリースする手段、を更に備える、請求項１８に記載のシステム。」
（２）本件補正前の特許請求の範囲 
　本件補正前の，平成３１年２月２０日にされた手続補正により補正された特許請求の範囲の請求項１乃至２０の記載は次のとおりである。
（以下，この特許請求の範囲に記載された請求項を「補正前の請求項」という。）
「　【請求項１】
　１つ以上のハードウェアプロセッサを有するリソースマネージャを備えたシステムであって、前記リソースマネージャは、
　実行プラットフォームによって実行される、複数のコンピュータ利用クエリソースから受信されたデータ処理要求、を監視することであって、前記データ処理要求は、複数の共有ストレージデバイス上に格納されたデータベースデータに向けられる、ことと、
　前記実行プラットフォームの複数の実行ノードの現在の利用を監視することであって、各実行ノードはプロセッサ及びローカルキャッシュを備え、前記ローカルキャッシュは前記複数の共有ストレージデバイスから取得されたデータを格納するように構成される、ことと、
　前記データ処理要求と、前記複数の実行ノードの現在の利用とに基づいて、追加のデータストレージ容量又は追加の処理容量の少なくとも一方が必要であると判定することと、
　前記判定に応じて、少なくとも１つの新規の実行ノードを前記実行プラットフォームに追加することにより、追加のデータストレージ容量又は追加の処理容量の少なくとも一方を割り当てることと、
　を実行するように構成され、
　前記複数の共有ストレージデバイスは前記データベースデータを纏めて格納し、前記実行プラットフォームは互いに独立にスケーリングされる、システム。
　　【請求項２】
　前記リソースマネージャは、前記データベースデータに応じたクエリ応答速度を監視するように更に構成され、追加の処理容量が必要であるか否かを判定することは、前記クエリ応答速度に更に基づく、請求項１に記載のシステム。
　　【請求項３】
　前記リソースマネージャは、前記データベースデータに応じたクエリ応答速度を監視するように更に構成され、追加のデータストレージ容量が必要であるか否かを判定することは、前記クエリ応答速度に更に基づく、請求項１に記載のシステム。
　　【請求項４】
　前記リソースマネージャは、前記追加のデータストレージ容量がもう必要ないと判定するのに応じて、前記少なくとも１つの新規の実行ノードをリリースするように更に構成されている、請求項１に記載のシステム。
　　【請求項５】
　前記リソースマネージャは、前記追加の処理容量がもう必要ないと判定するのに応じて、前記少なくとも１つの新規の実行ノードをリリースするように更に構成されている、請求項１に記載のシステム。
　　【請求項６】
　前記リソースマネージャは、前記複数の共有トレージデバイスにおける現在のデータ割り当てを監視するように更に構成され、追加のデータストレージ容量が必要であるか否かを判定することは、前記複数の共有ストレージデバイスにおける前記現在のデータ割り当てに更に基づく、請求項１に記載のシステム。
　　【請求項７】
　前記複数の実行ノードは、複数の仮想ウェアハウス内に配置されている、請求項１に記載のシステム。
　　【請求項８】
　前記複数の仮想ウェアハウスは、複数の仮想ウェアハウスグループにグループ化され、前記複数の仮想ウェアハウスグループのそれぞれは、異なるユーザのグループと関連づけられる、請求項７に記載のシステム。
　　【請求項９】
　前記複数の仮想ウェアハウスは、複数の仮想ウェアハウスグループにグループ化され、前記複数の仮想ウェアハウスグループのそれぞれは、異なるエンティティに関連づけられる、請求項７に記載のシステム。
　　【請求項１０】
　実行プラットフォームによって実行される、複数のコンピュータ利用クエリソースから受信されたデータ処理要求、を監視することであって、前記データ処理要求は、複数の共有ストレージデバイス上に格納されたデータベースデータに向けられる、ことと、
　前記実行プラットフォームの複数の実行ノードの現在の利用を監視することであって、各実行ノードはプロセッサ及びローカルキャッシュを備え、前記ローカルキャッシュは前記複数の共有ストレージデバイスから取得されたデータを格納するように構成される、ことと、
　前記データ処理要求と、前記複数の実行ノードの現在の利用とに基づいて、追加のデータストレージ容量又は追加の処理容量の少なくとも一方が必要であると判定することと、
　前記判定に応じて、少なくとも１つの新規の実行ノードを前記実行プラットフォームに追加することにより、追加のデータストレージ容量又は追加の処理容量の少なくとも一方を割り当てることと、
　を含み、
　前記複数の共有ストレージデバイスは前記データベースデータを纏めて格納し、前記実行プラットフォームは互いに独立にスケーリングされる、方法。
　　【請求項１１】
　前記データベースデータに応じたクエリ応答速度を監視することを更に含み、追加の処理容量が必要であるか否かを判定することは、前記クエリ応答速度に更に基づく、請求項１０に記載の方法。
　　【請求項１２】
　前記追加のデータストレージ容量がもう必要ないと判定するのに応じて、前記少なくとも１つの新規の実行ノードをリリースすることを更に含む、請求項１０に記載の方法。
　　【請求項１３】
　前記追加の処理容量がもう必要ないと判定するのに応じて、前記少なくとも１つの新規の実行ノードをリリースすることを更に含む、請求項１０に記載の方法。
　　【請求項１４】
　前記複数の共有ストレージデバイス内の現在のデータ割り当てを監視することを更に含み、追加のデータストレージ容量が必要であるか否かを判定することは、前記複数の共有ストレージデバイス内の前記現在のデータ割り当てに更に基づく、請求項１０に記載の方法。
　　【請求項１５】
　前記複数の実行ノードの各々は、複数の仮想ウェアハウス内に配置される、請求項１０に記載の方法。
　　【請求項１６】
　前記複数の仮想ウェアハウスは、複数の仮想ウェアハウスグループにグループ化され、前記複数の仮想ウェアハウスグループのそれぞれは、異なるユーザのグループと関連づられる、請求項１５に記載の方法。
　　【請求項１７】
　特定のデータ処理要求を実行するために必要な時間を予測することと、
　現在のクエリ処理遅延を判定することと、
　前記現在のクエリ処理遅延が閾値を超えたと判定するのに応じて、新規の実行ノードを生成することであって、前記新規の実行ノードは、キャッシュとプロセッサとを含む、ことと、
　を更に含む、請求項１０に記載の方法。
　　【請求項１８】
　実行プラットフォームによって実行される、複数のコンピュータ利用クエリソースから受信されたデータ処理要求、を監視する手段であって、前記データ処理要求は、複数の共有ストレージデバイス上に格納されたデータベースデータに向けられる、手段と、
　前記実行プラットフォームの複数の実行ノードの現在の利用を監視する手段であって、各実行ノードはプロセッサ及びローカルキャッシュを備え、前記ローカルキャッシュは前記複数の共有ストレージデバイスから取得されたデータを格納するように構成される、手段と、
　前記データ処理要求と、前記複数の実行ノードの現在の利用とに基づいて、追加のデータストレージ容量又は追加の処理容量の少なくとも一方が必要であると判定する手段と、
　前記判定に応じて、少なくとも１つの新規の実行ノードを前記実行プラットフォームに追加することにより、追加のデータストレージ容量又は追加の処理容量の少なくとも一方を割り当てる手段と、
　を備え、
　前記複数の共有ストレージデバイスは前記データベースデータを纏めて格納し、前記実行プラットフォームは互いに独立にスケーリングされる、システム。
　　【請求項１９】
　前記追加のデータストレージ容量がもう必要ないと判定するのに応じて、前記少なくとも１つの新規の実行ノードをリリースする手段、を更に備える、請求項１８に記載のシステム。
　　【請求項２０】
　前記追加の処理容量がもう必要ないと判定するのに応じて、前記少なくとも１つの新規の実行ノードをリリースする手段、を更に備える、請求項１８に記載のシステム。」
２　補正の適否 
　本件補正は，補正前の請求項１，１０，１８に記載の「各実行ノード」に関して，「ステートレスであり」との限定，及び，「各実行ノードの前記プロセッサは、前記複数の共有ストレージデバイスから分離し且つ独立している」との限定を付加するものであって，補正前の請求項１に記載された発明と補正後の請求項１に記載された発明の産業上の利用分野及び解決しようとする課題が同一であるから，特許法第１７条の２第５項第２号の特許請求の範囲の減縮を目的とするものに該当する。
　そこで，本件補正後の請求項１に記載される発明（以下「本件補正発明」という。）が同条第６項において準用する同法第１２６条第７項の規定に適合するか（特許出願の際独立して特許を受けることができるものであるか）について，以下，検討する。　　　  
２−１　実施可能要件について
（１）本件補正発明
　本件補正発明は，上記１（１）の【請求項１】に記載したとおりのものである。
　ここで，本件補正発明において，「各実行ノードが、ステートレスであり」なる発明特定事項について、特許法第３６条第４項第１号に規定する要件（実施可能要件）に適合するか否かについて，以下，検討する。
（２）本願明細書の記載
　本件補正発明における「各実行ノードが、ステートレスであり」に関して，本願明細書には，以下の記載がある。
「【００３５】
　幾つかの実施形態においては、図３に示される実行ノードは、実行ノードがキャッシュしているデータについて、ステートレスである。例えば、これらの実行ノードは、実行ノードについての状態情報、または、特定の状態ノードによってキャッシュされているデータについての状態情報を格納しないか、さもなくば、これらを保持しない。従って、実行ノードエラーの場合、エラーが出たノードは、透過的（トランスペアレント）に、他のノードに置き換えられることが出来る。エラーが出た実行ノードに関連した状態情報が無いので、新規の（置き換えの）実行ノードは、特定の状態を再生成するという懸念なしに、エラーが出たノードを容易に置き換えることが出来る。」
（３）判断
　本願明細書の上記記載によれは，実行ノードが「ステートレス」であるとは，「実行ノードがキャッシュしているデータについて、ステートレス」であって，「これらの実行ノードは、実行ノードについての状態情報、または、特定の状態ノードによってキャッシュされているデータについての状態情報を格納しないか、さもなくば、これらを保持しない」ものであると認められる。
　しかしながら，上記「実行ノードについての状態情報」，及び「特定の状態ノードによってキャッシュされているデータについての状態情報」とは，具体的にどのような情報であるのか，キャッシュされているデータそのものとは異なり，どのようにして，どのような状態を表す情報であるのか，その具体的な情報の態様については，一切開示されておらず，技術常識を考慮しても明らかであるとはいえない。
　この点に関し，上記（２）で引用する本願明細書の記載中に，「従って、実行ノードエラーの場合、エラーが出たノードは、透過的（トランスペアレント）に、他のノードに書き換えることが出来る。エラーが出た実行ノードに関連した状態情報が無いので、新規の（置き換えの）実行ノードは、特定の状態を再生成するという懸念なしに、エラーが出たノードを容易に置き換えることが出来る。」との記載があり，当該記載の内容と整合的に理解しようとすると，上記「実行ノードについての状態情報」は，「実行ノードにおいて実行中の処理のその時点での実行状態に関する情報（処理の進捗状態，アクセス中のリソースに関する情報等）」であるように解されなくもないが，このように解する場合，現在処理を行っている実行ノードは，かような実行状態に関する情報を持たないため，そもそも処理の実行を行い得ないこととなり矛盾する。また，「特定の状態ノードによってキャッシュされているデータについての状態情報」については，キャッシュデータの有無にかかわらず，「新規の（置き換えの）実行ノードは、特定の状態を再生成するという懸念なしに、エラーが出たノードを容易に置き換えることが出来る」ことになるので，当該記載との整合性を手がかりにしても，「特定の状態ノードによってキャッシュされているデータについての状態情報」が具体的にどのような情報であるのかを理解することができない。
　また，本願明細書，及び図面の記載全体，さらに，本願優先日における技術常識を参酌しても，上記「実行ノードについての状態情報」，及び「特定の状態ノードによってキャッシュされているデータについての状態情報」とは，具体的にどのような情報であるのか，かかる「状態情報」を保持しないことが，なにゆえ「エラーが出たノードを容易に置き換えることが出来る」ことにつながるのか，その技術的根拠が明らかであるとはいえない。
（４）小括
　よって，本件補正発明における「各実行ノードが，ステートレスであり」なる発明特定事項に関して，発明の詳細な説明の記載は，特許法第３６条第４項第１号に規定する要件を満たしておらず，本件補正発明は，特許出願の際独立して特許を受けることができない。
２−２　進歩性について
（１）本件補正発明 
　本件補正発明は，上記１（１）の【請求項１】に記載した以下のとおりのものである（再掲）。 
「　【請求項１】
　１つ以上のハードウェアプロセッサを有するリソースマネージャを備えたシステムであって、前記リソースマネージャは、
　実行プラットフォームによって実行される、複数のコンピュータ利用クエリソースから受信されたデータ処理要求、を監視することであって、前記データ処理要求は、複数の共有ストレージデバイス上に格納されたデータベースデータに向けられる、ことと、
　前記実行プラットフォームの複数の実行ノードの現在の利用を監視することであって、各実行ノードは
、ステートレスであり、且つ、
、各実行ノードの前記プロセッサは、前記複数の共有ストレージデバイスから分離し且つ独立している
　前記データ処理要求と、前記複数の実行ノードの現在の利用とに基づいて、追加のデータストレージ容量又は追加の処理容量の少なくとも一方が必要であると判定することと、
　前記判定に応じて、少なくとも１つの新規の実行ノードを前記実行プラットフォームに追加することにより、追加のデータストレージ容量又は追加の処理容量の少なくとも一方を割り当てることと、
　を実行するように構成され、
　前記複数の共有ストレージデバイスは前記データベースデータを纏めて格納し、前記実行プラットフォームは互いに独立にスケーリングされる、システム。」
（２）引用文献等に記載された事項及び引用発明
（２−１）引用文献１に記載された事項及び引用発明
ア　本願の優先日前に頒布又は電気通信回線を通じて公衆に利用可能となり，原査定の拒絶の理由である平成３０年１１月１４日付けの拒絶理由通知において引用された，特開２００５−５６０７７号公報（平成１７年３月３日公開，以下，「引用文献１」という。）には，以下の事項が記載されている。
（当審注：下線は，参考のために当審で付与したものである。以下同様。） 
Ａ　「【０００１】
　本発明は、データベース、特に無共有型のデータベース処理をするホストの台数またはデータベースのデータを保存するディスクの追加または削減に関する。
【背景技術】
【０００２】
　データベース（以下、ＤＢ）処理（検索など）性能を向上する方法として、複数のＣＰＵと複数のディスクを同時に使用し、処理を並列化することが良く用いられる。この並列化を実現するアーキテクチャの一つとして、図６に示す無共有型（Shared−nothing）データベースがある。
無共有型データベースは、複数のホスト１１〜１４（
ＣＰＵを持つ情報処理装置）と複数のディスク８１〜８４からなる。各ホストは、データベース処理を行う一つまたは複数のＤＢプロセス（処理を行うジョブ）２０〜２３を実行する。（本発明では、「データベース」を
情報処理装置、ネットワーク、ストレージからなりデータベース処理を行うシステムという意味で使用する
【０００３】
　無共有型データベースの特長として、各ホスト１１〜１４はそれぞれのホストに属するディスクのみをアクセスする。例えば、ホスト１１はディスク８１をアクセスするが、ディスク８２〜８４をアクセスしない。必要な場合、ホスト１１〜１４はホスト１１〜１４の間でデータを交換してデータベース処理をする（このデータ交換は図示しない）。これで各ホストを同期させることが少なくなり、データベースのスケーラビリティを向上する。
【０００４】
　
無共有型データベースのＤＢ管理機構１１０は、データベースをアクセスするクライアントのクエリー
を受け、処理をホスト１１〜１４に分配し、ホスト１１〜１４の処理結果をまとめ、クエリーの結果をクライアント
に返す。
Ｂ　「【００２８】
  
これらのディスク５１〜５４は、システム管理機構７０によって制御されるストレージ装置３０に収装される
【００２９】
  ＳＡＮ６０及びストレージ装置３０は、ＤＢプロセス間のディスク（またはボリューム）共有手段としてとして機能する。
【００３０】
　ホスト１１、１２は、データベース管理機構（以下、ＤＢ管理機構）１０からの指令を受けて、データベース処理を行うものである。このＤＢ管理機構１０は、クライアント９０からのリクエストを受けて、実際に処理を行うＤＢプロセスまたはディスク（またはボリューム）を決定する。そして、ＤＢ管理機構１０は、各ＤＢプロセスからのデータベース処理結果をクライアント９０へ返信する。
【００３１】
　なお、ＤＢ管理機構１０は、例えば、所定のハードウェア（サーバ等）上で機能するプラグラムなどで構成され、換言すれば、ＤＢ管理機構１０がフロントエンドサーバであり、ホスト１１〜１４がバックエンドサーバである。
【００３２】
　
ＤＢ管理機構１０は、データベースシステム全体を監視し、管理するシステム管理機構７０によって制御される。
【００３３】
　例えば、
システム管理機構７０は、各ホスト１１、１２の処理負荷を監視し、処理負荷が大きくなるとＤＢ管理機構１０にホストの追加を指令したり、ＳＡＮ６０やストレージ装置３０に対して各ＤＢプロセス２４〜２７に割り当てるディスク５１〜５４の変更を指令する。
Ｃ　「【００５２】
　
図４にストレージ仮想化を採用した無共有型データベースの一例を示す
【００５３】
　
ホスト１１〜１４は、ストレージ装置３０の仮想化エンジン３１が作成した仮想ディスク４１〜４４をアクセスする
仮想化エンジン３１は仮想ディスク４１〜４４のデータを物理ディスク５１〜５４にマッピングして記録する
【００５４】
　次に、
ストレージ最適化は性能を向上するために、仮想ディスク４１〜４４と物理ディスク５１〜５４とのマッピングを変更する方法である。
【００５５】
　
ストレージ最適化は仮想ディスク４１〜４４の内容を変更しない（物理ディスク５１〜５４の内容のみを変更する）。このため、最適化は仮想ディスク４１〜４４をアクセスしているホスト１１〜１４（とＤＢプロセス２４〜２９等のプロセス）にはトランスペアレントであり、ホスト１１〜１４から物理ディスク５１〜５４を透過的に読み書きすることができる。
【００５６】
　次に、物理ディスクを追加／削減するとき、上述のストレージ仮想化と最適化を活用する。
【００５７】
　この例として、
図５では図４の状態から
物理ディスク５５、５６を追加して、最適化を行った結果を示す。
【００５８】
　ディスクの性能（ReadまたはWriteの速度）は物理ディスク５１〜５６の数に比例するため、最適化が仮想ディスク４１〜４４のデータを４台（物理ディスク５１〜５４）から６台（物理ディスク５１〜５６）の物理ディスクに再配分することでストレージの性能が向上し、この結果、データベース処理能力が向上する。」
Ｄ　「【００８６】
（変形例９） 
ＤＢプロセス２４〜２９がそれぞれディスク５１〜５６のキャッシュを持つ。
ホスト追加／削減の場合、あるディスク（例えば、ディスク５２）を使用しているＤＢプロセス１１〜１４を切り換えるとき（この例では、ＤＢプロセス２５からＤＢプロセス２８）、ディスクを受ける側のＤＢプロセス（ＤＢプロセス２８）のキャッシュは受けたディスク（ディスク５２）のデータを持たない。
Ｅ　「図１
 
」
（図１は，無共有型データベースの一例を示すものであって，”ＤＢプロセス２５に物理ディスク５２に対応付けられている”態様が読み取れる。
　また，”ホスト１１〜１４が複数の物理ディスク５１〜５４から分離している”態様が読み取れる。）
Ｆ　「図２
」
（図２は，データベースシステムの再構成の第二ステップを示すものであって，ホスト１３が追加され，”ホスト１３でＤＢプロセス２８が起動し，ホスト１１のＤＢプロセス２５の代わりに処理を行う際に，ディスクを受ける側のＤＢプロセス２８が，ＤＢプロセス２５に対応付けられている物理ディスク５２に対応付けられていない”態様が読み取れる。
　また，システム管理機構１０，及び物理ディスク５１〜５４が追加されることなくホスト１３が追加されていることから，”ホストの追加が，システム管理機構，及び複数の物理ディスクとは別個になされる”態様が読み取れる。）
Ｇ　「図４
」
（図４は，ストレージ仮想化を採用した無共有型データベースの一例を示すものであって，”ホスト１１は仮想ディスク４１にアクセスし，仮想ディスク４１は物理ディスク５１，５２にマッピングされている”態様，及び，”ホスト１２は仮想ディスク４２にマッピングされ，仮想ディスク４２は物理ディスク５１，５２にマッピングされている”態様が読み取れる。）
Ｈ　「図５
」
（図５は，図４の状態から２つの物理ディスク５５，５６を追加して，最適化を行った結果を示すものであって，”ホスト１１〜１４が，それぞれ仮想ディスク４１〜４４にアクセスする状態のまま，物理ディスクのみが，４つの物理ディスク５１〜５４から，６つの物理ディスク５１〜５６に追加されている”態様が読み取れる。） 
イ　上記Ａ乃至Ｈの記載から，上記引用文献１には次の発明（以下，「引用発明」という。）が記載されているといえる。 
「無共有型データベースであって，
　データベースとは，情報処理装置，ネットワーク，ストレージからなりデータベース処理を行うシステムという意味で使用するものであり，
　無共有型データベースは，複数のホスト１１〜１４（ＣＰＵを持つ情報処理装置）と複数のディスクからなり，
　各ホストは，データベース処理を行う一つまたは複数のＤＢプロセス（処理を行うジョブ）を実行するものであり，
　これらのディスクは，システム管理機構によって制御されるストレージ装置に収装されるものであり，
　無共有型データベースのＤＢ管理機構は，データベースをアクセスするクライアントのクエリーを受け，処理をホスト１１〜１４に分配し，ホスト１１〜１４の処理結果をまとめ，クエリーの結果をクライアントに返すものであり，
　ＤＢ管理機構は，データベースシステム全体を監視し，管理するシステム管理機構によって制御されるものであり，
　システム管理機構は，各ホストの処理負荷を監視し，処理負荷が大きくなるとＤＢ管理機構にホストの追加を指令したり，ＳＡＮやストレージ装置に対して各ＤＢプロセスに割り当てるディスク５１〜５４の変更を指令するものであり，
　ホスト１１〜１４は，ストレージ装置の仮想化エンジンが作成した仮想ディスク４１〜４４をアクセスし，仮想化エンジンは仮想ディスク４１〜４４のデータを物理ディスク５１〜５４にマッピングして記録するものであり，
　ストレージ最適化は性能を向上するために，仮想ディスク４１〜４４と物理ディスク５１〜５４とのマッピングを変更する方法であり，
　ストレージ最適化は仮想ディスク４１〜４４の内容を変更しない（物理ディスク５１〜５４の内容のみを変更する）ものであり，最適化は仮想ディスク４１〜４４をアクセスしているホスト１１〜１４（とＤＢプロセス２４〜２９等のプロセス）にはトランスペアレントであり，ホスト１１〜１４から物理ディスク５１〜５４を透過的に読み書きすることができるものであり，
　物理ディスクを追加して最適化を行うことができるものであり，
　ＤＢプロセス２４〜２９がそれぞれディスク５１〜５６のキャッシュを持つものであり，ホスト追加／削減の場合，あるディスク（例えば，ディスク５２）を使用しているＤＢプロセス１１〜１４を切り換えるとき（この例では，ＤＢプロセス２５からＤＢプロセス２８），ディスクを受ける側のＤＢプロセス（ＤＢプロセス２８）のキャッシュは受けたディスク（ディスク５２）のデータを持たない，
　無共有型データベース。」
（２−２）引用文献２に記載された事項及び技術 
ア　本願の優先日前に頒布又は電気通信回線を通じて公衆に利用可能となり，原査定の拒絶の理由である平成３０年１１月２０日付けの拒絶理由通知において引用された，特表２００９−５２７０５６号公報（平成２１年７月２３日公表，以下，「引用文献２」という。）には，以下の事項が記載されている。
Ｉ　「【０００９】
　
クエリ処理
特定のクエリを処理する第１の責任
【００１０】
　
サーバの作業負荷を再平衡化する方法
第１の責任を、そのネットワーク内で比較的低いクエリ応答率を有するサーバから、そのネットワーク内で比較的速いネットワーク応答率を有するサーバへと、移動する
イ　上記Ｉの記載から，引用文献２には次の技術が記載されているといえる。
「クエリ処理におけるサーバの作業負荷を再平衡化する方法であって，
　特定のクエリを処理する第１の責任を，そのネットワーク内で比較的低いクエリ応答率を有するサーバから，そのネットワーク内で比較的速いネットワーク応答率を有するサーバへと，移動する方法」
（２−３）参考文献に記載された事項及び技術
ア　本願の優先日前に頒布又は電気通信回線を通じて公衆に利用可能となった，特開２０１３−２１０６８３号公報（平成２５年１０月１０日公開，以下，「参考文献」という。）には，以下の事項が記載されている。
Ｊ　「【００１０】
　１態様では，
オートスケーリング方法では，要求された処理を複数のコンピュータノードに分散して実行するシステムにおいて，該システムで実行するタスクの管理を行うコンピュータノードが，納期が指定された処理要求を受け付けた際に，
処理要求のタスクを納期内に処理終了可能なコンピュータノードがなく，さらに他のコンピュータノードでも納期内に処理終了可能なタスクを移動しても処理要求のタスクを納期内に処理終了可能なコンピュータノードを用意できないと判定された場合に，システムにコンピュータノードを増設する処理を実行する。
イ　上記Ｊの記載から，参考文献には次の技術が記載されているといえる。
「オートスケーリング方法であって，
　要求された処理を複数のコンピュータノードに分散して実行するシステムにおいて，該システムで実行するタスクの管理を行うコンピュータノードが，納期が指定された処理要求を受け付けた際に，
　処理要求のタスクを納期内に処理終了可能なコンピュータノードがなく，さらに他のコンピュータノードでも納期内に処理終了可能なタスクを移動しても処理要求のタスクを納期内に処理終了可能なコンピュータノードを用意できないと判定された場合に，システムにコンピュータノードを増設する処理を実行する方法。」
（３）対比 
ア　本件補正発明と引用発明とを対比する。 
（ア）引用発明は「無共有型データベース」であるところ，引用発明では，「データベースとは，情報処理装置，ネットワーク，ストレージからなりデータベース処理を行うシステムという意味で使用するもの」であるから，引用発明は“システム”であるといえる。
　そして，引用発明の「システム管理機構」は，「各ホストの処理負荷を監視し，処理負荷が大きくなるとＤＢ管理機構にホストの追加を指令したり，ＳＡＮやストレージ装置に対して各ＤＢプロセスに割り当てるディスクの変更を指令するもの」であるところ，「ホストの追加を指令したり」，「ディスクの変更を指令する」ことは，ホスト，ディスクというシステムのリソースを管理することであるといえるから，“リソースマネージャ”であるといえる。また，「システム管理機構」による「指令」は，何らかのハードウェアプロセッサを用いた情報処理によって行われることは明らかであって，「システム管理機構」が，“１つ以上のハードウェアプロセッサを有する”ことは明らかである。
　よって，本件補正発明と引用発明とは，後記の点で相違するものの，“１つ以上のハードウェアプロセッサを有するリソースマネージャを備えたシステム”点で一致している。
（イ）引用発明は，「ＤＢ管理機構は，データベースをアクセスするクライアントのクエリーを受け」るものである。ここで，「クエリー」は“データ処理要求”であるといえ，「クエリー」を発する「クライアント」のコンピュータは，“コンピュータ使用クエリソース”といえる。
　そして，引用発明において「データベースをアクセスする」ことは，「ストレージ装置に収装される」「複数のディスク」に格納されているデータベースのデータにアクセスすることを示すものであって，前記「ストレージ装置に収装される」「複数のディスク」は，“複数のストレージデバイス”といえ，前記「クエリー」は，データベースのデータに向けられていることは明らかであるから，引用発明の「クエリー」に関して，“コンピュータ利用クエリソースから受信されたデータ処理要求は，複数のストレージデバイス上に格納されたデータベースデータに向けられる”といえる。
　さらに，引用発明では，前記「クエリー」を「複数のホスト１１〜１４」が処理するところ，前記「複数のホスト１１〜１４」は，「データベース処理を行う一つまたは複数のＤＢプロセス（処理を行うジョブ）を実行する」ものであるから，「複数のホスト１１〜１４」は，全体として，データベース処理を行う“実行プラットフォーム”であるといえ，前記「クエリー」を”実行プラットフォーム”が実行するといえる。
　以上のことから，本件補正発明の「データ処理要求」と引用発明の「クエリー」とは，後記の点で相違するものの，“実行プラットフォームによって実行される，コンピュータ利用クエリソースから受信されたデータ処理要求は，複数のストレージデバイス上に格納されたデータベースデータに向けられる”点で一致している。
（ウ）引用発明の「システム管理機構」は，「各ホストの処理負荷を監視」するところ，上記（イ）で検討したように，「複数のホスト１１〜１４」は，全体として，データベース処理を行う“実行プラットフォーム”といえ，「各ホスト」は，かかる実行プラットフォームの“各実行ノード”であるといえ，さらに，「処理負荷」とは，ＣＰＵの現在の利用に基づく処理負荷であって“現在の利用”といえるので，結局，前記「各ホストの処理負荷を監視」することは，“実行プラットフォームの複数の実行ノードの現在の利用を監視する”ことに他ならない。
　そして，引用発明の「複数のホスト１１〜１４」は「ＣＰＵを持つ情報処理装置」であって，「各ホストは，データベース処理を行う一つまたは複数のＤＢプロセス（処理を行うジョブ）を実行する」ところ，「ＤＢプロセス２４〜２９がそれぞれディスク５１〜５６のキャッシュを持つ」ものであるから，結局，ＤＢプロセスを実行する「各ホスト」，すなわち，”各実行ノード”が「ＣＰＵ」と「キャッシュ」を備えているものである。ここで，前記「ＣＰＵ」は“プロセッサ”といえ，前記「キャッシュ」は，「複数のディスク」，すなわち，“複数のストレージデバイス”から取得されたデータを格納する“ローカルキャッシュ”といえるものである。
　よって，本件補正発明の「リソースマネージャ」と引用発明の「システム管理機構」とは，後記の点で相違するものの，“実行プラットフォームの複数の実行ノードの現在の利用を監視することであって，各実行ノードは，プロセッサ及びローカルキャッシュを備え，前記ローカルキャッシュは複数のストレージデバイスから取得されたデータを格納するように構成され”ている点で一致している。
（エ）引用発明の「システム管理機構」は，「各ホストの処理負荷を監視し，処理負荷が大きくなるとＤＢ管理機構にホストの追加を指令したり，ＳＡＮやストレージ装置に対して各ＤＢプロセスに割り当てるディスクの変更を指令するもの」である。
　上記（ウ）で検討したように，「各ホストの処理負荷」は“複数の実行ノードの現在の利用”といえるので，「処理負荷が大きくなるとＤＢ管理機構にホストの追加を指令したり，ＳＡＮやストレージ装置に対して各ＤＢプロセスに割り当てるディスクの変更を指令する」ことは，“複数の実行ノードの現在の利用”に基づいて，「ホストの追加」，「ディスクの変更」を指令することに他ならない。そして，「ホストの追加」は，“処理容量の追加”といえ，「ディスクの変更」として「物理ディスクを追加して最適化を行うことができる」ものであるから，前記「ディスクの変更」には，ディスクの追加，すなわち“ストレージ容量の追加”が含まれるものである。
　引用発明の「システム管理機構」は，かかる“処理容量の追加”，“ストレージ容量の追加”の指令を，前述したように“複数の実行ノードの現在の利用”に基づいて指令するものであるから，かかる追加の指令を発する際には，“複数の実行ノードの現在の利用”に基づいて，“処理容量の追加”又は“ストレージ容量の追加”の“少なくとも一方が必要であると判定”したことによって指令を発していることは明らかである。
　よって，本件補正発明の「リソースマネージャ」と引用発明の「システム管理機構」とは，後記の点で相違するものの，“複数の実行ノードの現在の利用に基づいて，追加のデータストレージ容量又は追加の処理容量の少なくとも一方が必要であると判定する”点で一致している。
（オ）引用発明の「システム管理機構」は，「各ホストの処理負荷を監視し，処理負荷が大きくなるとＤＢ管理機構にホストの追加を指令したり，ＳＡＮやストレージ装置に対して各ＤＢプロセスに割り当てるディスク５１〜５４の変更を指令する」ものである。ここで，上記（イ）（ウ）で検討したように，「複数のホスト１１〜１４」は，全体として，データベース処理を行う“実行プラットフォーム”といえ，「各ホスト」は，かかる実行プラットフォームの“複数のノード”であるといえるところ，「ホストの追加」とは，少なくとも１つの新規の実行ノードを実行プラットフォームに追加することを意味するから，“少なくとも１つの新規の実行ノードを前記実行プラットフォームに追加する”ことに他ならず，その結果，“追加のデータストレージ容量又は追加の処理容量”のうち“追加の処理容量”が割り当てられるものである。
　したがって，上記（エ）の検討結果も踏まえると，本件補正発明の「リソースマネージャ」と引用発明の「システム管理機構」とは，“前記判定に応じて，少なくとも１つの新規の実行ノードを実行プラットフォームに追加することにより，追加のデータストレージ容量又は追加の処理容量の少なくとも一方を割り当てる”点で一致している。
（カ）上記（イ）で検討したように，引用発明の「ストレージ装置に収装される」「複数のディスク」は，“複数のストレージデバイス”といえるところ，かかる「複数のディスク」は，データベースのデータを格納していることは明らかであって，通常，データベースのデータは”纏めて”格納されるものである。
　よって，本件補正発明の「ストレージデバイス」と引用発明の「複数のディスク」とは，後記の点で相違するものの，”複数のストレージデバイスはデータベースデータを纏めて格納する“点で一致している。
イ　上記（ア）乃至（カ）の検討により，本件補正発明と引用発明とは，以下の点で一致し，また，以下の点で相違する。 
＜一致点＞　 
「１つ以上のハードウェアプロセッサを有するリソースマネージャを備えたシステムであって，前記リソースマネージャは，
　実行プラットフォームによって実行される，コンピュータ利用クエリソースから受信されたデータ処理要求は，複数のストレージデバイス上に格納されたデータベースデータに向けられる，ことと，
　前記実行プラットフォームの複数の実行ノードの現在の利用を監視することであって，各実行ノードは，プロセッサ及びローカルキャッシュを備え，前記ローカルキャッシュは前記複数のストレージデバイスから取得されたデータを格納するように構成される，ことと，
　前記複数の実行ノードの現在の利用に基づいて，追加のデータストレージ容量又は追加の処理容量の少なくとも一方が必要であると判定することと，
　前記判定に応じて，少なくとも１つの新規の実行ノードを前記実行プラットフォームに追加することにより，追加のデータストレージ容量又は追加の処理容量の少なくとも一方を割り当てることと，
　を実行するように構成され，
　前記複数のストレージデバイスは前記データベースデータを纏めて格納する，システム。」 
＜相違点１＞ 
　コンピュータ利用クエリソースに関して,本件補正発明では，「複数の」コンピュータ利用クエリソースとしているのに対して,引用発明では,そのように特定していない点。
＜相違点２＞ 
　「ストレージデバイス」に関して，本件補正発明は，「共有」ストレージデバイスであるのに対し，引用発明は，「無共有型」データベースのストレージデバイスである点。
＜相違点３＞
　本件補正発明では，リソースマネージャが「データ処理要求」を「監視する」ものであって，監視された「前記データ処理要求」と，前記複数の実行ノードの現在の利用とに基づいて，追加のデータストレージ容量又は追加の処理容量の少なくとも一方が必要であると判定するものであるのに対して，引用発明では，ＤＢ管理機構がクエリー，すなわち，データ処理要求を受けるものの，ＤＢ管理機構を制御するシステム管理機構が，かかるデータ処理要求を「監視する」とはしておらず，よって，データ処理要求に基づいて，追加のデータストレージ容量又は追加の処理容量が必要であると判定することもしていない点。
＜相違点４＞
　本件補正発明では，実行ノードが「ステートレス」であるのに対して，引用発明では，ホストがステートレスであるとは特定しない点。
＜相違点５＞
　本件補正発明では，「各実行ノードの前記プロセッサは、前記複数の共有ストレージデバイスから分離し且つ独立している」のに対して，引用発明では，各ホストのＣＰＵが複数の物理ディスクから分離し且つ独立しているとは特定していない点。
＜相違点６＞
　本件補正発明では，「前記実行プラットフォームは互いに独立にスケーリングされる」のに対して，引用発明では，そのような特定がなされていない点。
（４）当審の判断 
ア　相違点１について
　データベースシステムにおいて，複数のクライアントコンピュータからクエリーを受けることは極めて一般的に行われていることである。
　引用発明において，クエリーを発するクライアントのコンピュータを「複数」設けること，すなわち，「複数の」コンピュータ利用クエリソースとすることは，当業者であれば適宜なし得る事項に過ぎない。
イ　相違点２について 
　引用発明は，「ホスト１１〜１４は，ストレージ装置の仮想化エンジンが作成した仮想ディスク４１〜４４をアクセスし，仮想化エンジンは仮想ディスク４１〜４４のデータを物理ディスク５１〜５４にマッピングして記録する」ものである。
　ここで，上記「（２）（２−１）引用文献１に記載された事項及び引用発明」のＧから,”ホスト１１は仮想ディスク４１にアクセスし，仮想ディスク４１は物理ディスク５１，５２にマッピングされている”態様，及び，”ホスト１２は仮想ディスク４２にマッピングされ，仮想ディスク４２は物理ディスク５１，５２にマッピングされている”態様が読み取れる。
　すなわち，ホスト１１，１２は，それぞれ仮想ディスク４１，４２を介して，ともに物理ディスク５１，５２にアクセスしており，物理ディスク５１，５２は，ホスト１１，１２に共有されている。
　してみると，引用発明の「物理ディスク」，すなわち，”ストレージデバイス”も，ストレージ仮想化を採用した場合，ストレージデバイスを構成する物理ディスクが複数のホストに共有されるものであるから，引用発明も「物理ディスク」に関しては，「共有」ストレージデバイスであるといえる。
　よって，相違点２は，実質的な相違点であるとはいえない。
ウ　相違点３について 
　上記「（２）（２−２）引用文献２に記載された事項及び技術　イ」に示されるように，上記引用文献２には，以下の技術が記載されている（再掲）。
「クエリ処理におけるサーバの作業負荷を再平衡化する方法であって，
　特定のクエリを処理する第１の責任を，そのネットワーク内で比較的低いクエリ応答率を有するサーバから，そのネットワーク内で比較的速いネットワーク応答率を有するサーバへと，移動する方法」
　引用文献２に記載の上記技術は，クエリ処理の責任を「クエリ応答率」が低いサーバから速いサーバに移すことによってサーバの作業負荷を再平衡化するクエリ処理技術を示すものである。ここで，「クエリ応答率」は，処理が要求されるクエリの量に依存することは明らかであって，「クエリ」は“データ処理要求”といえ，「サーバ」は“実行ノード”といえるから，引用文献２には，各実行ノードの作業負荷を再平衡化する際に，“データ処理要求”を作業負荷の指標として用いることが開示されているといえる。
　また，上記「（２）（２−３）参考文献に記載された事項及び技術　イ」に示したとおり，上記参考文献には，以下の技術が記載されている（再掲）。
「オートスケーリング方法であって，
　要求された処理を複数のコンピュータノードに分散して実行するシステムにおいて，該システムで実行するタスクの管理を行うコンピュータノードが，納期が指定された処理要求を受け付けた際に，
　処理要求のタスクを納期内に処理終了可能なコンピュータノードがなく，さらに他のコンピュータノードでも納期内に処理終了可能なタスクを移動しても処理要求のタスクを納期内に処理終了可能なコンピュータノードを用意できないと判定された場合に，システムにコンピュータノードを増設する処理を実行する方法。」
　参考文献に記載の上記技術は，要求された処理を複数のコンピュータノードに分散して実行するシステムにおいて，コンピュータノードが指定された納期内に処理要求のタスクを実行できない場合に，システムにコンピュータノードを増設する技術を示すものである。ここで，「要求された処理」は“データ処理要求”といえ，「コンピュータノード」は“実行ノード”といえるから，参考文献には，実行ノードの増設を行う際に，“データ処理要求”を増設の指標として用いることが開示されているといえる。
　してみると，上記引用文献２及び参考文献には，いずれも，実行ノードに対して再平衡化や増設等の作業管理を行う際に，“データ処理要求”を作業管理の指標として用いる技術が開示されているといえ，このことから，実行ノードの作業管理を行う際に，“データ処理要求”を指標として用いることは，本願の優先日前において，通常行われている技術に過ぎないといえる。
　一方，引用発明は，上記「（３）対比　ア（エ）」で検討したように，「システム管理機構」が，“前記複数の実行ノードの現在の利用に基づいて，追加のデータストレージ容量又は追加の処理容量の少なくとも一方が必要であると判定する”ものである。ここで，“実行ノードの現在の利用”は，実行ノードに発生する作業負担を示す指標であるといえるところ，実行ノードの処理能力，実行ノードの個数の他に，実行ノードに対して要求される“データ処理要求”にも依存するものであることは明らかであるから，“実行ノードの現在の利用”は，“データ処理要求”と関連性を有する指標であるといえる。
　引用発明と，引用文献２及び参考文献に記載の上記技術とは，実行ノードに発生する作業負担に応じて，システムのリソースを管理するという機能において共通するものであって，前述したように，引用発明の“実行ノードの現在の利用”は“データ処理要求”と関連性を有する指標であるから，引用発明の「システム管理機構」において，“実行ノードの現在の利用”の監視に加えて，当該システム管理機構の制御対象であるデータ管理機構が受ける“データ処理要求”も監視するものとし，監視された「前記データ処理要求」と，複数の実行ノードの現在の利用とに基づいて，追加のデータストレージ容量又は追加の処理容量の少なくとも一方が必要であると判定するように構成することは，引用文献２及び参考文献に記載の，“データ処理要求”を指標として用いる上記技術に基づいて，当業者であれば容易になし得たものである。
エ　相違点４について 
　上記「２−１　実施可能要件について」の「（３）判断」で検討したように，本件補正発明における，実行ノードが「ステートレス」である点に関して，本願明細書を参照してもその意味する技術事項が明らかではないが，上記段落【００３５】における「これらの実行ノードは，実行ノードについての状態情報，または，特定の状態ノードによってキャッシュされているデータについての状態情報を格納しないか，さもなくば，これらを保持しない」なる記載からすると，実行ノードが「ステートレス」であるとは，「状態情報」が具体的にどのような情報であるかは明らかではないものの，実行ノードが，実行ノードについての何らかの状態情報，または，キャッシュされているデータについての何らかの状態情報を格納しないものと推測することができる。
　一方，引用発明は，「ＤＢプロセス２４〜２９がそれぞれディスク５１〜５６のキャッシュを持つものであり，ホスト追加／削減の場合，あるディスク（例えば，ディスク５２）を使用しているＤＢプロセス１１〜１４を切り換えるとき（この例では，ＤＢプロセス２５からＤＢプロセス２８），ディスクを受ける側のＤＢプロセス（ＤＢプロセス２８）のキャッシュは受けたディスク（ディスク５２）のデータを持たない」ものである。
　この点に関して，上記「（２）（２−１）引用文献１に記載された事項及び引用発明」のＥから，”ＤＢプロセス２５に物理ディスク５２に対応付けられている”態様が読み取れ，上記「（２）（２−１）引用文献１に記載された事項及び引用発明」のＦから，”ホスト１３でＤＢプロセス２８が起動し，ホスト１１のＤＢプロセス２５の代わりに処理を行う際に，ディスクを受ける側のＤＢプロセス２８が，ＤＢプロセス２５に対応付けられている物理ディスク５２に対応付けられていない”態様が読み取れる。
　引用発明では，ホスト１３におけるＤＢプロセス２８の起動に伴うこのような態様の結果として，上記「（２）（２−１）引用文献１に記載された事項及び引用発明」のＤに記載されているように，「その結果，このＤＢプロセス（ＤＢプロセス２８）の性能がしばらく低下し，データベース全体の性能が低下する」ものである。
　してみると，引用発明において，前記「あるディスク（例えば，ディスク５２）を使用しているＤＢプロセス１１〜１４を切り換えるとき（この例では，ＤＢプロセス２５からＤＢプロセス２８），ディスクを受ける側のＤＢプロセス（ＤＢプロセス２８）のキャッシュは受けたディスク（ディスク５２）のデータを持たない」とは，ＤＢプロセスを切り換えるとき，ＤＢプロセスのキャッシュは，かかる切り換えの前後でデータを引き継がないことを意味するものである。そして，ＤＢプロセスの切り換えの前後でキャッシュのデータを引き継がない以上，キャッシュのデータに関するいかなる「状態情報」も引き継ぐ必要は無く，そもそも，かかる「状態情報」自体を予め格納しておく必要も無いものと推察される。
　よって，引用発明において，各ＤＢプロセスを実行するホストが，そもそもキャッシュに関する状態情報を格納しないとすること，すなわち，実行ノードを「ステートレス」とすることは，引用発明においてＤＢプロセスの切り換えの前後でキャッシュのデータを引き継がないという前記技術事項を参酌すれば，当業者であれば適宜なし得る事項と認められる。
　
オ　相違点５について
　引用発明は，「ホスト１１〜１４は，ストレージ装置の仮想化エンジンが作成した仮想ディスク４１〜４４をアクセスし，仮想化エンジンは仮想ディスク４１〜４４のデータを物理ディスク５１〜５４にマッピングして記録する」ものであって，「性能を向上するために，仮想ディスク４１〜４４と物理ディスク５１〜５４とのマッピングを変更」して「ストレージ最適化」できるものである。
　そして，「ストレージ最適化」とは，「仮想ディスク４１〜４４の内容を変更しない（物理ディスク５１〜５４の内容のみを変更する）ものであり，最適化は仮想ディスク４１〜４４をアクセスしているホスト１１〜１４（とＤＢプロセス２４〜２９等のプロセス）にはトランスペアレントであり，ホスト１１〜１４から物理ディスク５１〜５４を透過的に読み書きすることができるものであり，物理ディスクを追加して最適化を行うことができる」ものである。
　ここで，上記「（２）（２−１）引用文献１に記載された事項及び引用発明」のＨから，”ホスト１１〜１４が，それぞれ仮想ディスク４１〜４４にアクセスする状態のまま，物理ディスクのみが，４つの物理ディスク５１〜５４から，６つの物理ディスク５１〜５６に追加されている”態様が読み取れる。 
　してみると，引用発明では，上記「（２）（２−１）引用文献１に記載された事項及び引用発明」のＥから，”ホスト１１〜１４が複数の物理ディスク５１〜５４から分離している”ことが読み取れるところ，ストレージ仮想化を採用した場合は，ホストを追加することなく物理ディスクを追加して最適化できるものであり，また，「最適化は仮想ディスク４１〜４４をアクセスしているホスト１１〜１４（とＤＢプロセス２４〜２９等のプロセス）にはトランスペアレントであ」る，すなわち，ホストからは物理ディスクの追加が見えないものであって，ホストが，物理ディスクの個数を意識することなく，追加された物理ディスクを含めた複数の物理ディスクにアクセスするものであるから，“ホストは複数の物理ディスクから分離し且つ独立している”といえる。
　そして，引用発明の「複数のホスト１１〜１４」は「ＣＰＵを持つ情報処理装置」であって，上記「（３）対比　ア（ウ）」で検討したように，「各ホスト」は“各実行ノード”といえ，「ＣＰＵ」は”プロセッサ”といえ，上記イで検討したように，引用発明の「物理ディスク」は“共有ストレージデバイス”といえるから，結局，引用発明において，“ホストは複数の物理ディスクから分離し且つ独立している”ことは，「各実行ノードの前記プロセッサは、前記複数の共有ストレージデバイスから分離し且つ独立している」ことといえる。
　以上のことから，上記相違点５は，実質的な相違点であるとはいえない。
カ　相違点６について
　本件補正発明の「前記実行プラットフォームは互いに独立にスケーリングされる」なる記載に関して，「互いに独立」とは，何と何とが「互いに独立」しているのか必ずしも明らかではないが，本願明細書の段落【００２２】における，
「更に、リソースマネージャ１０２、メタデータ１１０、実行プラットフォーム１１２、及びストレージプラットフォーム１１４のそれぞれは、ユーザ１０４〜１０８から受信する要求に対する変更及びデータ処理プラットフォーム１００のニーズの変化に依存して、（相互に独立に）スケールアップまたはスケールダウンされることが出来る。」
　なる記載を参酌すると，本件補正発明の上記記載は，実行プラットフォームが，リソースマネージャ，ストレージプラットフォームから独立してスケーリングされることを意味するものと解される。
　一方，引用発明においても，上記「（２）（２−１）引用文献１に記載された事項及び引用発明」のＦから，ホストの追加はシステム管理機構を追加することなく行われることが読み取れ，さらに，上記オで検討したように，“ホスト１１〜１４は複数の物理ディスクから分離し且つ独立している”ものであるから，結局，ホストは，システム管理機構，物理ディスクから独立して追加されているといえ，引用発明も，「前記実行プラットフォームは互いに独立にスケーリングされる」といえる。
　よって，上記相違点６は，実質的な相違点であるとはいえない。
キ　小括 
　上記で検討したごとく，相違点１乃６に係る構成は当業者が容易に想到し得たものであり，そして，これらの相違点を総合的に勘案しても，本件補正発明の奏する作用効果は，引用発明，及び上記技術の奏する作用効果から予測される範囲内のものにすぎず，格別顕著なものということはできない。
　したがって，本件補正発明は，引用発明，及び上記技術に基づいて，当業者が容易に発明をすることができたものであり，特許法第２９条第２項の規定により，特許出願の際独立して特許を受けることができない。
３　本件補正についてのむすび 
　よって，本件補正は，特許法第１７条の２第６項において準用する同法第１２６条第７項の規定に違反するので，同法第１５９条第１項の規定において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　よって，上記補正の却下の決定の結論のとおり決定する。 
第３　本願発明について 
１　本願発明の認定 
　令和１年１１月２２日付けでなされた手続補正は，上記のとおり却下されたので，本願の請求項に係る発明は，平成３１年２月２０日付けでなされた手続補正により補正された特許請求の範囲の請求項１乃至２０に記載された事項により特定されるものであるところ，その請求項１に係る発明（以下，「本願発明」という。）は，その請求項１に記載された事項により特定される，以下のとおりのものである。
「　【請求項１】
　１つ以上のハードウェアプロセッサを有するリソースマネージャを備えたシステムであって、前記リソースマネージャは、
　実行プラットフォームによって実行される、複数のコンピュータ利用クエリソースから受信されたデータ処理要求、を監視することであって、前記データ処理要求は、複数の共有ストレージデバイス上に格納されたデータベースデータに向けられる、ことと、
　前記実行プラットフォームの複数の実行ノードの現在の利用を監視することであって、各実行ノードはプロセッサ及びローカルキャッシュを備え、前記ローカルキャッシュは前記複数の共有ストレージデバイスから取得されたデータを格納するように構成される、ことと、
　前記データ処理要求と、前記複数の実行ノードの現在の利用とに基づいて、追加のデータストレージ容量又は追加の処理容量の少なくとも一方が必要であると判定することと、
　前記判定に応じて、少なくとも１つの新規の実行ノードを前記実行プラットフォームに追加することにより、追加のデータストレージ容量又は追加の処理容量の少なくとも一方を割り当てることと、
　を実行するように構成され、
　前記複数の共有ストレージデバイスは前記データベースデータを纏めて格納し、前記実行プラットフォームは互いに独立にスケーリングされる、システム。」
２　原査定の拒絶の理由 
　原査定の拒絶の理由は，この出願の請求項１に係る発明は，本願の出願日前に頒布された又は電気通信回線を通じて公衆に利用可能となった下記の引用文献１及び引用文献２に記載された発明に基づいて，その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許を受けることができない，というものである。
　引用文献１：特開２００５−５６０７７号公報
　引用文献２：特表２００９−５２７０５６号公報
３　引用文献に記載されている技術的事項及び引用発明の認定
　原査定の拒絶の理由に引用された，引用文献１及び引用文献２とその記載事項は，上記「第２　令和１年１１月２２日付けの手続補正についての補正却下の決定」の「２　補正の適否」の「２−２　進歩性について」の「（２）（２−１）引用文献１に記載された事項及び引用発明」及び「（２）（２−２）引用文献２に記載された事項及び技術」に記載したとおりである。
４　対比・判断 
　本願発明は，上記「第２　令和１年１１月２２日付けの手続補正についての補正却下の決定」の「２　補正の適否」の「２−２　進歩性について」で検討した本件補正発明から，「各実行ノードは，ステートレスであり」との限定事項を削除し，「各実行ノードの前記プロセッサは，前記複数の共有ストレージデバイスから分離し且つ独立している」との限定事項を削除したものである。
　そうすると，本願発明の発明特定事項を全て含む本件補正発明が，上記「第２　令和１年１１月２２日付けの手続補正についての補正却下の決定」の「２　補正の適否」の「２−２　進歩性について」の「（３）対比」及び「（４）当審の判断」に記載したとおり，引用発明，及び上記技術に基づいて当業者が容易に発明をすることができたものであるから，上記特定の限定を省いた本願発明も同様の理由により，引用発明，及び上記技術に基づいて，当業者が容易に発明をすることができたものである。
第４　むすび 
　以上のとおり，本願の請求項１に係る発明は，特許法第２９条第２項の規定により特許を受けることができないものであるから，その余の請求項に係る発明について検討するまでもなく，本願は拒絶すべきものである。
　よって，結論のとおり審決する。