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