• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 特36条4項詳細な説明の記載不備 特許、登録しない。 G06F
審判 査定不服 5項独立特許用件 特許、登録しない。 G06F
審判 査定不服 2項進歩性 特許、登録しない。 G06F
管理番号 1370721
審判番号 不服2019-15742  
総通号数 255 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2021-03-26 
種別 拒絶査定不服の審決 
審判請求日 2019-11-22 
確定日 2021-01-27 
事件の表示 特願2016-552966「リソース提供システム及び方法」拒絶査定不服審判事件〔平成27年8月27日国際公開,WO2015/127076,平成29年3月2日国内公表,特表2017-506394〕について,次のとおり審決する。 
結論 本件審判の請求は,成り立たない。 
理由 第1 手続の経緯

本願は,2015年2月19日(パリ条約による優先権主張外国庁受理2014年2月19日(以下,「優先日」という。),2014年10月20日 アメリカ合衆国)を国際出願日とする出願であって,平成28年8月16日に特許法第184条の5第1項に規定される書面の提出がなされ,同年10月13日付けで特許法第184条の4第1項の規定による国際出願日における明細書,請求の範囲,図面(図面の中の説明に限る。)及び要約の翻訳文の提出がなされ,平成30年2月7日付けで出願審査の請求がなされ,同年11月20日付けで審査官により拒絶理由が通知され,これに対して平成31年2月20日付けで意見書が提出されるとともに手続補正がなされ,令和1年7月16日付けで拒絶査定(以下,「原査定」という。)がなされ,これに対して同年11月22日付けで拒絶査定不服審判の請求がなされるとともに手続補正がなされ,令和2年2月20日付けで審査官により特許法第164条第3項に定める報告(前置報告)がなされ,同年4月22日付けで上申書が提出されたものである。

第2 令和1年11月22日にされた手続補正についての補正の却下の決定

[補正の却下の決定の結論]

令和1年11月22日にされた手続補正(以下,「本件補正」という。)を却下する。

[理由]

1 本件補正について(補正の内容)

(1)本件補正後の特許請求の範囲の記載

本件補正により,特許請求の範囲の請求項1乃至20の記載は,次のとおり補正された。
(下線部は,補正箇所である。以下,この特許請求の範囲に記載された請求項を「補正後の請求項」という。)

「 【請求項1】
1つ以上のハードウェアプロセッサを有するリソースマネージャを備えたシステムであって、前記リソースマネージャは、
実行プラットフォームによって実行される、複数のコンピュータ利用クエリソースから受信されたデータ処理要求、を監視することであって、前記データ処理要求は、複数の共有ストレージデバイス上に格納されたデータベースデータに向けられる、ことと、
前記実行プラットフォームの複数の実行ノードの現在の利用を監視することであって、各実行ノードは、ステートレスであり、且つ、プロセッサ及びローカルキャッシュを備え、前記ローカルキャッシュは前記複数の共有ストレージデバイスから取得されたデータを格納するように構成され、各実行ノードの前記プロセッサは、前記複数の共有ストレージデバイスから分離し且つ独立している、ことと、
前記データ処理要求と、前記複数の実行ノードの現在の利用とに基づいて、追加のデータストレージ容量又は追加の処理容量の少なくとも一方が必要であると判定することと、
前記判定に応じて、少なくとも1つの新規の実行ノードを前記実行プラットフォームに追加することにより、追加のデータストレージ容量又は追加の処理容量の少なくとも一方を割り当てることと、
を実行するように構成され、
前記複数の共有ストレージデバイスは前記データベースデータを纏めて格納し、前記実行プラットフォームは互いに独立にスケーリングされる、システム。
【請求項2】
前記リソースマネージャは、前記データベースデータに応じたクエリ応答速度を監視するように更に構成され、追加の処理容量が必要であるか否かを判定することは、前記クエリ応答速度に更に基づく、請求項1に記載のシステム。
【請求項3】
前記リソースマネージャは、前記データベースデータに応じたクエリ応答速度を監視するように更に構成され、追加のデータストレージ容量が必要であるか否かを判定することは、前記クエリ応答速度に更に基づく、請求項1に記載のシステム。
【請求項4】
前記リソースマネージャは、前記追加のデータストレージ容量がもう必要ないと判定するのに応じて、前記少なくとも1つの新規の実行ノードをリリースするように更に構成されている、請求項1に記載のシステム。
【請求項5】
前記リソースマネージャは、前記追加の処理容量がもう必要ないと判定するのに応じて、前記少なくとも1つの新規の実行ノードをリリースするように更に構成されている、請求項1に記載のシステム。
【請求項6】
前記リソースマネージャは、前記複数の共有トレージデバイスにおける現在のデータ割り当てを監視するように更に構成され、追加のデータストレージ容量が必要であるか否かを判定することは、前記複数の共有ストレージデバイスにおける前記現在のデータ割り当てに更に基づく、請求項1に記載のシステム。
【請求項7】
前記複数の実行ノードは、複数の仮想ウェアハウス内に配置されている、請求項1に記載のシステム。
【請求項8】
前記複数の仮想ウェアハウスは、複数の仮想ウェアハウスグループにグループ化され、前記複数の仮想ウェアハウスグループのそれぞれは、異なるユーザのグループと関連づけられる、請求項7に記載のシステム。
【請求項9】
前記複数の仮想ウェアハウスは、複数の仮想ウェアハウスグループにグループ化され、前記複数の仮想ウェアハウスグループのそれぞれは、異なるエンティティに関連づけられる、請求項7に記載のシステム。
【請求項10】
実行プラットフォームによって実行される、複数のコンピュータ利用クエリソースから受信されたデータ処理要求、を監視することであって、前記データ処理要求は、複数の共有ストレージデバイス上に格納されたデータベースデータに向けられる、ことと、
前記実行プラットフォームの複数の実行ノードの現在の利用を監視することであって、各実行ノードは、ステートレスであり、且つ、プロセッサ及びローカルキャッシュを備え、前記ローカルキャッシュは前記複数の共有ストレージデバイスから取得されたデータを格納するように構成され、各実行ノードの前記プロセッサは、前記複数の共有ストレージデバイスから分離し且つ独立している、ことと、
前記データ処理要求と、前記複数の実行ノードの現在の利用とに基づいて、追加のデータストレージ容量又は追加の処理容量の少なくとも一方が必要であると判定することと、
前記判定に応じて、少なくとも1つの新規の実行ノードを前記実行プラットフォームに追加することにより、追加のデータストレージ容量又は追加の処理容量の少なくとも一方を割り当てることと、
を含み、
前記複数の共有ストレージデバイスは前記データベースデータを纏めて格納し、前記実行プラットフォームは互いに独立にスケーリングされる、方法。
【請求項11】
前記データベースデータに応じたクエリ応答速度を監視することを更に含み、追加の処理容量が必要であるか否かを判定することは、前記クエリ応答速度に更に基づく、請求項10に記載の方法。
【請求項12】
前記追加のデータストレージ容量がもう必要ないと判定するのに応じて、前記少なくとも1つの新規の実行ノードをリリースすることを更に含む、請求項10に記載の方法。
【請求項13】
前記追加の処理容量がもう必要ないと判定するのに応じて、前記少なくとも1つの新規の実行ノードをリリースすることを更に含む、請求項10に記載の方法。
【請求項14】
前記複数の共有ストレージデバイス内の現在のデータ割り当てを監視することを更に含み、追加のデータストレージ容量が必要であるか否かを判定することは、前記複数の共有ストレージデバイス内の前記現在のデータ割り当てに更に基づく、請求項10に記載の方法。
【請求項15】
前記複数の実行ノードの各々は、複数の仮想ウェアハウス内に配置される、請求項10に記載の方法。
【請求項16】
前記複数の仮想ウェアハウスは、複数の仮想ウェアハウスグループにグループ化され、前記複数の仮想ウェアハウスグループのそれぞれは、異なるユーザのグループと関連づけられる、請求項15に記載の方法。
【請求項17】
特定のデータ処理要求を実行するために必要な時間を予測することと、
現在のクエリ処理遅延を判定することと、
前記現在のクエリ処理遅延が閾値を超えたと判定するのに応じて、新規の実行ノードを生成することであって、前記新規の実行ノードは、キャッシュとプロセッサとを含む、ことと、
を更に含む、請求項10に記載の方法。
【請求項18】
実行プラットフォームによって実行される、複数のコンピュータ利用クエリソースから受信されたデータ処理要求、を監視する手段であって、前記データ処理要求は、複数の共有ストレージデバイス上に格納されたデータベースデータに向けられる、手段と、
前記実行プラットフォームの複数の実行ノードの現在の利用を監視する手段であって、各実行ノードは、ステートレスであり、且つ、プロセッサ及びローカルキャッシュを備え、前記ローカルキャッシュは前記複数の共有ストレージデバイスから取得されたデータを格納するように構成され、各実行ノードの前記プロセッサは、前記複数の共有ストレージデバイスから分離し且つ独立している、手段と、
前記データ処理要求と、前記複数の実行ノードの現在の利用とに基づいて、追加のデータストレージ容量又は追加の処理容量の少なくとも一方が必要であると判定する手段と、
前記判定に応じて、少なくとも1つの新規の実行ノードを前記実行プラットフォームに追加することにより、追加のデータストレージ容量又は追加の処理容量の少なくとも一方を割り当てる手段と、
を備え、
前記複数の共有ストレージデバイスは前記データベースデータを纏めて格納し、前記実行プラットフォームは互いに独立にスケーリングされる、システム。
【請求項19】
前記追加のデータストレージ容量がもう必要ないと判定するのに応じて、前記少なくとも1つの新規の実行ノードをリリースする手段、を更に備える、請求項18に記載のシステム。
【請求項20】
前記追加の処理容量がもう必要ないと判定するのに応じて、前記少なくとも1つの新規の実行ノードをリリースする手段、を更に備える、請求項18に記載のシステム。」

(2)本件補正前の特許請求の範囲

本件補正前の,平成31年2月20日にされた手続補正により補正された特許請求の範囲の請求項1乃至20の記載は次のとおりである。
(以下,この特許請求の範囲に記載された請求項を「補正前の請求項」という。)

「 【請求項1】
1つ以上のハードウェアプロセッサを有するリソースマネージャを備えたシステムであって、前記リソースマネージャは、
実行プラットフォームによって実行される、複数のコンピュータ利用クエリソースから受信されたデータ処理要求、を監視することであって、前記データ処理要求は、複数の共有ストレージデバイス上に格納されたデータベースデータに向けられる、ことと、
前記実行プラットフォームの複数の実行ノードの現在の利用を監視することであって、各実行ノードはプロセッサ及びローカルキャッシュを備え、前記ローカルキャッシュは前記複数の共有ストレージデバイスから取得されたデータを格納するように構成される、ことと、
前記データ処理要求と、前記複数の実行ノードの現在の利用とに基づいて、追加のデータストレージ容量又は追加の処理容量の少なくとも一方が必要であると判定することと、
前記判定に応じて、少なくとも1つの新規の実行ノードを前記実行プラットフォームに追加することにより、追加のデータストレージ容量又は追加の処理容量の少なくとも一方を割り当てることと、
を実行するように構成され、
前記複数の共有ストレージデバイスは前記データベースデータを纏めて格納し、前記実行プラットフォームは互いに独立にスケーリングされる、システム。
【請求項2】
前記リソースマネージャは、前記データベースデータに応じたクエリ応答速度を監視するように更に構成され、追加の処理容量が必要であるか否かを判定することは、前記クエリ応答速度に更に基づく、請求項1に記載のシステム。
【請求項3】
前記リソースマネージャは、前記データベースデータに応じたクエリ応答速度を監視するように更に構成され、追加のデータストレージ容量が必要であるか否かを判定することは、前記クエリ応答速度に更に基づく、請求項1に記載のシステム。
【請求項4】
前記リソースマネージャは、前記追加のデータストレージ容量がもう必要ないと判定するのに応じて、前記少なくとも1つの新規の実行ノードをリリースするように更に構成されている、請求項1に記載のシステム。
【請求項5】
前記リソースマネージャは、前記追加の処理容量がもう必要ないと判定するのに応じて、前記少なくとも1つの新規の実行ノードをリリースするように更に構成されている、請求項1に記載のシステム。
【請求項6】
前記リソースマネージャは、前記複数の共有トレージデバイスにおける現在のデータ割り当てを監視するように更に構成され、追加のデータストレージ容量が必要であるか否かを判定することは、前記複数の共有ストレージデバイスにおける前記現在のデータ割り当てに更に基づく、請求項1に記載のシステム。
【請求項7】
前記複数の実行ノードは、複数の仮想ウェアハウス内に配置されている、請求項1に記載のシステム。
【請求項8】
前記複数の仮想ウェアハウスは、複数の仮想ウェアハウスグループにグループ化され、前記複数の仮想ウェアハウスグループのそれぞれは、異なるユーザのグループと関連づけられる、請求項7に記載のシステム。
【請求項9】
前記複数の仮想ウェアハウスは、複数の仮想ウェアハウスグループにグループ化され、前記複数の仮想ウェアハウスグループのそれぞれは、異なるエンティティに関連づけられる、請求項7に記載のシステム。
【請求項10】
実行プラットフォームによって実行される、複数のコンピュータ利用クエリソースから受信されたデータ処理要求、を監視することであって、前記データ処理要求は、複数の共有ストレージデバイス上に格納されたデータベースデータに向けられる、ことと、
前記実行プラットフォームの複数の実行ノードの現在の利用を監視することであって、各実行ノードはプロセッサ及びローカルキャッシュを備え、前記ローカルキャッシュは前記複数の共有ストレージデバイスから取得されたデータを格納するように構成される、ことと、
前記データ処理要求と、前記複数の実行ノードの現在の利用とに基づいて、追加のデータストレージ容量又は追加の処理容量の少なくとも一方が必要であると判定することと、
前記判定に応じて、少なくとも1つの新規の実行ノードを前記実行プラットフォームに追加することにより、追加のデータストレージ容量又は追加の処理容量の少なくとも一方を割り当てることと、
を含み、
前記複数の共有ストレージデバイスは前記データベースデータを纏めて格納し、前記実行プラットフォームは互いに独立にスケーリングされる、方法。
【請求項11】
前記データベースデータに応じたクエリ応答速度を監視することを更に含み、追加の処理容量が必要であるか否かを判定することは、前記クエリ応答速度に更に基づく、請求項10に記載の方法。
【請求項12】
前記追加のデータストレージ容量がもう必要ないと判定するのに応じて、前記少なくとも1つの新規の実行ノードをリリースすることを更に含む、請求項10に記載の方法。
【請求項13】
前記追加の処理容量がもう必要ないと判定するのに応じて、前記少なくとも1つの新規の実行ノードをリリースすることを更に含む、請求項10に記載の方法。
【請求項14】
前記複数の共有ストレージデバイス内の現在のデータ割り当てを監視することを更に含み、追加のデータストレージ容量が必要であるか否かを判定することは、前記複数の共有ストレージデバイス内の前記現在のデータ割り当てに更に基づく、請求項10に記載の方法。
【請求項15】
前記複数の実行ノードの各々は、複数の仮想ウェアハウス内に配置される、請求項10に記載の方法。
【請求項16】
前記複数の仮想ウェアハウスは、複数の仮想ウェアハウスグループにグループ化され、前記複数の仮想ウェアハウスグループのそれぞれは、異なるユーザのグループと関連づられる、請求項15に記載の方法。
【請求項17】
特定のデータ処理要求を実行するために必要な時間を予測することと、
現在のクエリ処理遅延を判定することと、
前記現在のクエリ処理遅延が閾値を超えたと判定するのに応じて、新規の実行ノードを生成することであって、前記新規の実行ノードは、キャッシュとプロセッサとを含む、ことと、
を更に含む、請求項10に記載の方法。
【請求項18】
実行プラットフォームによって実行される、複数のコンピュータ利用クエリソースから受信されたデータ処理要求、を監視する手段であって、前記データ処理要求は、複数の共有ストレージデバイス上に格納されたデータベースデータに向けられる、手段と、
前記実行プラットフォームの複数の実行ノードの現在の利用を監視する手段であって、各実行ノードはプロセッサ及びローカルキャッシュを備え、前記ローカルキャッシュは前記複数の共有ストレージデバイスから取得されたデータを格納するように構成される、手段と、
前記データ処理要求と、前記複数の実行ノードの現在の利用とに基づいて、追加のデータストレージ容量又は追加の処理容量の少なくとも一方が必要であると判定する手段と、
前記判定に応じて、少なくとも1つの新規の実行ノードを前記実行プラットフォームに追加することにより、追加のデータストレージ容量又は追加の処理容量の少なくとも一方を割り当てる手段と、
を備え、
前記複数の共有ストレージデバイスは前記データベースデータを纏めて格納し、前記実行プラットフォームは互いに独立にスケーリングされる、システム。
【請求項19】
前記追加のデータストレージ容量がもう必要ないと判定するのに応じて、前記少なくとも1つの新規の実行ノードをリリースする手段、を更に備える、請求項18に記載のシステム。
【請求項20】
前記追加の処理容量がもう必要ないと判定するのに応じて、前記少なくとも1つの新規の実行ノードをリリースする手段、を更に備える、請求項18に記載のシステム。」

2 補正の適否

本件補正は,補正前の請求項1,10,18に記載の「各実行ノード」に関して,「ステートレスであり」との限定,及び,「各実行ノードの前記プロセッサは、前記複数の共有ストレージデバイスから分離し且つ独立している」との限定を付加するものであって,補正前の請求項1に記載された発明と補正後の請求項1に記載された発明の産業上の利用分野及び解決しようとする課題が同一であるから,特許法第17条の2第5項第2号の特許請求の範囲の減縮を目的とするものに該当する。

そこで,本件補正後の請求項1に記載される発明(以下「本件補正発明」という。)が同条第6項において準用する同法第126条第7項の規定に適合するか(特許出願の際独立して特許を受けることができるものであるか)について,以下,検討する。

2-1 実施可能要件について

(1)本件補正発明
本件補正発明は,上記1(1)の【請求項1】に記載したとおりのものである。
ここで,本件補正発明において,「各実行ノードが、ステートレスであり」なる発明特定事項について、特許法第36条第4項第1号に規定する要件(実施可能要件)に適合するか否かについて,以下,検討する。

(2)本願明細書の記載
本件補正発明における「各実行ノードが、ステートレスであり」に関して,本願明細書には,以下の記載がある。

「【0035】
幾つかの実施形態においては、図3に示される実行ノードは、実行ノードがキャッシュしているデータについて、ステートレスである。例えば、これらの実行ノードは、実行ノードについての状態情報、または、特定の状態ノードによってキャッシュされているデータについての状態情報を格納しないか、さもなくば、これらを保持しない。従って、実行ノードエラーの場合、エラーが出たノードは、透過的(トランスペアレント)に、他のノードに置き換えられることが出来る。エラーが出た実行ノードに関連した状態情報が無いので、新規の(置き換えの)実行ノードは、特定の状態を再生成するという懸念なしに、エラーが出たノードを容易に置き換えることが出来る。」

(3)判断
本願明細書の上記記載によれは,実行ノードが「ステートレス」であるとは,「実行ノードがキャッシュしているデータについて、ステートレス」であって,「これらの実行ノードは、実行ノードについての状態情報、または、特定の状態ノードによってキャッシュされているデータについての状態情報を格納しないか、さもなくば、これらを保持しない」ものであると認められる。
しかしながら,上記「実行ノードについての状態情報」,及び「特定の状態ノードによってキャッシュされているデータについての状態情報」とは,具体的にどのような情報であるのか,キャッシュされているデータそのものとは異なり,どのようにして,どのような状態を表す情報であるのか,その具体的な情報の態様については,一切開示されておらず,技術常識を考慮しても明らかであるとはいえない。
この点に関し,上記(2)で引用する本願明細書の記載中に,「従って、実行ノードエラーの場合、エラーが出たノードは、透過的(トランスペアレント)に、他のノードに書き換えることが出来る。エラーが出た実行ノードに関連した状態情報が無いので、新規の(置き換えの)実行ノードは、特定の状態を再生成するという懸念なしに、エラーが出たノードを容易に置き換えることが出来る。」との記載があり,当該記載の内容と整合的に理解しようとすると,上記「実行ノードについての状態情報」は,「実行ノードにおいて実行中の処理のその時点での実行状態に関する情報(処理の進捗状態,アクセス中のリソースに関する情報等)」であるように解されなくもないが,このように解する場合,現在処理を行っている実行ノードは,かような実行状態に関する情報を持たないため,そもそも処理の実行を行い得ないこととなり矛盾する。また,「特定の状態ノードによってキャッシュされているデータについての状態情報」については,キャッシュデータの有無にかかわらず,「新規の(置き換えの)実行ノードは、特定の状態を再生成するという懸念なしに、エラーが出たノードを容易に置き換えることが出来る」ことになるので,当該記載との整合性を手がかりにしても,「特定の状態ノードによってキャッシュされているデータについての状態情報」が具体的にどのような情報であるのかを理解することができない。
また,本願明細書,及び図面の記載全体,さらに,本願優先日における技術常識を参酌しても,上記「実行ノードについての状態情報」,及び「特定の状態ノードによってキャッシュされているデータについての状態情報」とは,具体的にどのような情報であるのか,かかる「状態情報」を保持しないことが,なにゆえ「エラーが出たノードを容易に置き換えることが出来る」ことにつながるのか,その技術的根拠が明らかであるとはいえない。

(4)小括
よって,本件補正発明における「各実行ノードが,ステートレスであり」なる発明特定事項に関して,発明の詳細な説明の記載は,特許法第36条第4項第1号に規定する要件を満たしておらず,本件補正発明は,特許出願の際独立して特許を受けることができない。

2-2 進歩性について

(1)本件補正発明

本件補正発明は,上記1(1)の【請求項1】に記載した以下のとおりのものである(再掲)。

「 【請求項1】
1つ以上のハードウェアプロセッサを有するリソースマネージャを備えたシステムであって、前記リソースマネージャは、
実行プラットフォームによって実行される、複数のコンピュータ利用クエリソースから受信されたデータ処理要求、を監視することであって、前記データ処理要求は、複数の共有ストレージデバイス上に格納されたデータベースデータに向けられる、ことと、
前記実行プラットフォームの複数の実行ノードの現在の利用を監視することであって、各実行ノードは、ステートレスであり、且つ、プロセッサ及びローカルキャッシュを備え、前記ローカルキャッシュは前記複数の共有ストレージデバイスから取得されたデータを格納するように構成され、各実行ノードの前記プロセッサは、前記複数の共有ストレージデバイスから分離し且つ独立している、ことと、
前記データ処理要求と、前記複数の実行ノードの現在の利用とに基づいて、追加のデータストレージ容量又は追加の処理容量の少なくとも一方が必要であると判定することと、
前記判定に応じて、少なくとも1つの新規の実行ノードを前記実行プラットフォームに追加することにより、追加のデータストレージ容量又は追加の処理容量の少なくとも一方を割り当てることと、
を実行するように構成され、
前記複数の共有ストレージデバイスは前記データベースデータを纏めて格納し、前記実行プラットフォームは互いに独立にスケーリングされる、システム。」

(2)引用文献等に記載された事項及び引用発明

(2-1)引用文献1に記載された事項及び引用発明

ア 本願の優先日前に頒布又は電気通信回線を通じて公衆に利用可能となり,原査定の拒絶の理由である平成30年11月14日付けの拒絶理由通知において引用された,特開2005-56077号公報(平成17年3月3日公開,以下,「引用文献1」という。)には,以下の事項が記載されている。
(当審注:下線は,参考のために当審で付与したものである。以下同様。)

A 「【0001】
本発明は、データベース、特に無共有型のデータベース処理をするホストの台数またはデータベースのデータを保存するディスクの追加または削減に関する。
【背景技術】
【0002】
データベース(以下、DB)処理(検索など)性能を向上する方法として、複数のCPUと複数のディスクを同時に使用し、処理を並列化することが良く用いられる。この並列化を実現するアーキテクチャの一つとして、図6に示す無共有型(Shared-nothing)データベースがある。無共有型データベースは、複数のホスト11?14(サーバ等の、CPUを持つ情報処理装置)と複数のディスク81?84からなる。各ホストは、データベース処理を行う一つまたは複数のDBプロセス(処理を行うジョブ)20?23を実行する。(本発明では、「データベース」を表などのデータでなく、情報処理装置、ネットワーク、ストレージからなりデータベース処理を行うシステムという意味で使用する)。
【0003】
無共有型データベースの特長として、各ホスト11?14はそれぞれのホストに属するディスクのみをアクセスする。例えば、ホスト11はディスク81をアクセスするが、ディスク82?84をアクセスしない。必要な場合、ホスト11?14はホスト11?14の間でデータを交換してデータベース処理をする(このデータ交換は図示しない)。これで各ホストを同期させることが少なくなり、データベースのスケーラビリティを向上する。
【0004】
無共有型データベースのDB管理機構110は、データベースをアクセスするクライアントのクエリー(問い合わせ)を受け、処理をホスト11?14に分配し、ホスト11?14の処理結果をまとめ、クエリーの結果をクライアント(図示省略)に返す。」

B 「【0028】
これらのディスク51?54は、システム管理機構70によって制御されるストレージ装置30に収装される。そして、このストレージ装置30は、ストレージエリアネットワーク(以下、SAN)60を介して各ホスト11?14に接続される。なお、SAN60も、システム管理機構70によって制御されるもので、複数のスイッチやループ型接続で構成される。
【0029】
SAN60及びストレージ装置30は、DBプロセス間のディスク(またはボリューム)共有手段としてとして機能する。
【0030】
ホスト11、12は、データベース管理機構(以下、DB管理機構)10からの指令を受けて、データベース処理を行うものである。このDB管理機構10は、クライアント90からのリクエストを受けて、実際に処理を行うDBプロセスまたはディスク(またはボリューム)を決定する。そして、DB管理機構10は、各DBプロセスからのデータベース処理結果をクライアント90へ返信する。
【0031】
なお、DB管理機構10は、例えば、所定のハードウェア(サーバ等)上で機能するプラグラムなどで構成され、換言すれば、DB管理機構10がフロントエンドサーバであり、ホスト11?14がバックエンドサーバである。
【0032】
DB管理機構10は、データベースシステム全体を監視し、管理するシステム管理機構70によって制御される。システム管理機構70は、上述の「JP1」等のようにデータベースなどのシステムの各コンポーネントの性能や可用性をモニタリングし、システム管理者が指定したポリシーにより各コンポーネントを制御する。
【0033】
例えば、システム管理機構70は、各ホスト11、12の処理負荷を監視し、処理負荷が大きくなるとDB管理機構10にホストの追加を指令したり、SAN60やストレージ装置30に対して各DBプロセス24?27に割り当てるディスク51?54の変更を指令する。なお、システム管理機構70による各ホスト11、12の処理負荷の検出は、DB管理機構10を介して検出したり、あるいは各ホスト11、12から直接検出しても良い。」

C 「【0052】
図4にストレージ仮想化を採用した無共有型データベースの一例を示す。なお、図4は図3と同じ状態を示すが、ストレージ装置30が仮想化を使用している点で相違する。
【0053】
ホスト11?14は、ストレージ装置30の仮想化エンジン31が作成した仮想ディスク41?44をアクセスする(仮想ディスクを点線で示す)。そして仮想化エンジン31は仮想ディスク41?44のデータを物理ディスク51?54にマッピングして記録する(このマッピングを、仮想ディスク41?44と物理ディスク51?54の間の点線で示す)。
【0054】
次に、ストレージ最適化は性能を向上するために、仮想ディスク41?44と物理ディスク51?54とのマッピングを変更する方法である。この機能の例として、日立CruiseControl(Hitachi Data Systems社、「Hitachi CruiseControl」を参照)、そしてEMC社のSymmetrix Optimizer(EMC社、「EMC ControlCenter Symmetrix Optimizer」を参照)、特開平9-069031号公報等がある。
【0055】
ストレージ最適化は仮想ディスク41?44の内容を変更しない(物理ディスク51?54の内容のみを変更する)。このため、最適化は仮想ディスク41?44をアクセスしているホスト11?14(とDBプロセス24?29等のプロセス)にはトランスペアレントであり、ホスト11?14から物理ディスク51?54を透過的に読み書きすることができる。
【0056】
次に、物理ディスクを追加/削減するとき、上述のストレージ仮想化と最適化を活用する。
【0057】
この例として、図5では図4の状態から2つの物理ディスク55、56を追加して、最適化を行った結果を示す。具体的には、最適化はディスク51、52のデータの一部をディスク55に、ディスク53、54のデータの一部をディスク56に移動またはコピーする。
【0058】
ディスクの性能(ReadまたはWriteの速度)は物理ディスク51?56の数に比例するため、最適化が仮想ディスク41?44のデータを4台(物理ディスク51?54)から6台(物理ディスク51?56)の物理ディスクに再配分することでストレージの性能が向上し、この結果、データベース処理能力が向上する。」

D 「【0086】
(変形例9) DBプロセス24?29がそれぞれディスク51?56のキャッシュを持つ。このため、ホスト追加/削減の場合、あるディスク(例えば、ディスク52)を使用しているDBプロセス11?14を切り換えるとき(この例では、DBプロセス25からDBプロセス28)、ディスクを受ける側のDBプロセス(DBプロセス28)のキャッシュは受けたディスク(ディスク52)のデータを持たない。その結果、このDBプロセス(DBプロセス28)の性能がしばらく低下し、データベース全体の性能が低下する。」

E 「図1



(図1は,無共有型データベースの一例を示すものであって,”DBプロセス25に物理ディスク52に対応付けられている”態様が読み取れる。
また,”ホスト11?14が複数の物理ディスク51?54から分離している”態様が読み取れる。)


F 「図2


(図2は,データベースシステムの再構成の第二ステップを示すものであって,ホスト13が追加され,”ホスト13でDBプロセス28が起動し,ホスト11のDBプロセス25の代わりに処理を行う際に,ディスクを受ける側のDBプロセス28が,DBプロセス25に対応付けられている物理ディスク52に対応付けられていない”態様が読み取れる。
また,システム管理機構10,及び物理ディスク51?54が追加されることなくホスト13が追加されていることから,”ホストの追加が,システム管理機構,及び複数の物理ディスクとは別個になされる”態様が読み取れる。)

G 「図4


(図4は,ストレージ仮想化を採用した無共有型データベースの一例を示すものであって,”ホスト11は仮想ディスク41にアクセスし,仮想ディスク41は物理ディスク51,52にマッピングされている”態様,及び,”ホスト12は仮想ディスク42にマッピングされ,仮想ディスク42は物理ディスク51,52にマッピングされている”態様が読み取れる。)

H 「図5


(図5は,図4の状態から2つの物理ディスク55,56を追加して,最適化を行った結果を示すものであって,”ホスト11?14が,それぞれ仮想ディスク41?44にアクセスする状態のまま,物理ディスクのみが,4つの物理ディスク51?54から,6つの物理ディスク51?56に追加されている”態様が読み取れる。)

イ 上記A乃至Hの記載から,上記引用文献1には次の発明(以下,「引用発明」という。)が記載されているといえる。

「無共有型データベースであって,
データベースとは,情報処理装置,ネットワーク,ストレージからなりデータベース処理を行うシステムという意味で使用するものであり,
無共有型データベースは,複数のホスト11?14(CPUを持つ情報処理装置)と複数のディスクからなり,
各ホストは,データベース処理を行う一つまたは複数のDBプロセス(処理を行うジョブ)を実行するものであり,
これらのディスクは,システム管理機構によって制御されるストレージ装置に収装されるものであり,
無共有型データベースのDB管理機構は,データベースをアクセスするクライアントのクエリーを受け,処理をホスト11?14に分配し,ホスト11?14の処理結果をまとめ,クエリーの結果をクライアントに返すものであり,
DB管理機構は,データベースシステム全体を監視し,管理するシステム管理機構によって制御されるものであり,
システム管理機構は,各ホストの処理負荷を監視し,処理負荷が大きくなるとDB管理機構にホストの追加を指令したり,SANやストレージ装置に対して各DBプロセスに割り当てるディスク51?54の変更を指令するものであり,
ホスト11?14は,ストレージ装置の仮想化エンジンが作成した仮想ディスク41?44をアクセスし,仮想化エンジンは仮想ディスク41?44のデータを物理ディスク51?54にマッピングして記録するものであり,
ストレージ最適化は性能を向上するために,仮想ディスク41?44と物理ディスク51?54とのマッピングを変更する方法であり,
ストレージ最適化は仮想ディスク41?44の内容を変更しない(物理ディスク51?54の内容のみを変更する)ものであり,最適化は仮想ディスク41?44をアクセスしているホスト11?14(とDBプロセス24?29等のプロセス)にはトランスペアレントであり,ホスト11?14から物理ディスク51?54を透過的に読み書きすることができるものであり,
物理ディスクを追加して最適化を行うことができるものであり,
DBプロセス24?29がそれぞれディスク51?56のキャッシュを持つものであり,ホスト追加/削減の場合,あるディスク(例えば,ディスク52)を使用しているDBプロセス11?14を切り換えるとき(この例では,DBプロセス25からDBプロセス28),ディスクを受ける側のDBプロセス(DBプロセス28)のキャッシュは受けたディスク(ディスク52)のデータを持たない,
無共有型データベース。」

(2-2)引用文献2に記載された事項及び技術

ア 本願の優先日前に頒布又は電気通信回線を通じて公衆に利用可能となり,原査定の拒絶の理由である平成30年11月20日付けの拒絶理由通知において引用された,特表2009-527056号公報(平成21年7月23日公表,以下,「引用文献2」という。)には,以下の事項が記載されている。

I 「【0009】
クエリ処理方法の一例は、クエリをネットワークに送出するステップと、そのネットワーク内のそれぞれのサーバにそのクエリを送信するステップと、各サーバが、ネットワーク内の、その特定のクエリを処理する第1の責任を有するサーバを、ルックアップテーブルで検索するステップとを備える。ネットワーク内のクエリの処理は、全てのネットワークサーバによって、モニタされる。クエリ結果はユーザに送信されてもよく、それにより、処理が完了する。
【0010】
サーバの作業負荷を再平衡化する方法の一例は、ネットワークの全体のクエリ応答率を決定するステップと、そのネットワークの全体のクエリ応答率を、目標とする(target)全体のクエリ応答率と比較するステップと、そのネットワーク内の各サーバについて、クエリ応答率を決定するステップと、そのネットワーク内の全てのサーバについて、クエリ応答率を比較するステップと、を含む。この方法に基づいて、一以上のデータセグメントに対する第1の責任を、そのネットワーク内で比較的低いクエリ応答率を有するサーバから、そのネットワーク内で比較的速いネットワーク応答率を有するサーバへと、移動することが可能となる。この方法は、マニュアルで、または任意の(オプショナル)プログラムロジックコントローラの支援によって、実行可能である。サーバの作業量が再平衡化されなかった場合のために、本発明のさらなる実施例は、ネットワークに追加サーバを導入する方法を含む。」

イ 上記Iの記載から,引用文献2には次の技術が記載されているといえる。

「クエリ処理におけるサーバの作業負荷を再平衡化する方法であって,
特定のクエリを処理する第1の責任を,そのネットワーク内で比較的低いクエリ応答率を有するサーバから,そのネットワーク内で比較的速いネットワーク応答率を有するサーバへと,移動する方法」

(2-3)参考文献に記載された事項及び技術

ア 本願の優先日前に頒布又は電気通信回線を通じて公衆に利用可能となった,特開2013-210683号公報(平成25年10月10日公開,以下,「参考文献」という。)には,以下の事項が記載されている。

J 「【0010】
1態様では,オートスケーリング方法では,要求された処理を複数のコンピュータノードに分散して実行するシステムにおいて,該システムで実行するタスクの管理を行うコンピュータノードが,納期が指定された処理要求を受け付けた際に,記憶部に記憶されたシステムが備えるコンピュータノードが実行するタスクを管理する管理情報を参照して,該処理要求のタスクをコンピュータノードに割り当てるシミュレーションを実行し,割り当てのシミュレーションにより,処理要求のタスクを納期内に処理終了可能なコンピュータノードがなく,さらに他のコンピュータノードでも納期内に処理終了可能なタスクを移動しても処理要求のタスクを納期内に処理終了可能なコンピュータノードを用意できないと判定された場合に,システムにコンピュータノードを増設する処理を実行する。」

イ 上記Jの記載から,参考文献には次の技術が記載されているといえる。

「オートスケーリング方法であって,
要求された処理を複数のコンピュータノードに分散して実行するシステムにおいて,該システムで実行するタスクの管理を行うコンピュータノードが,納期が指定された処理要求を受け付けた際に,
処理要求のタスクを納期内に処理終了可能なコンピュータノードがなく,さらに他のコンピュータノードでも納期内に処理終了可能なタスクを移動しても処理要求のタスクを納期内に処理終了可能なコンピュータノードを用意できないと判定された場合に,システムにコンピュータノードを増設する処理を実行する方法。」

(3)対比

ア 本件補正発明と引用発明とを対比する。

(ア)引用発明は「無共有型データベース」であるところ,引用発明では,「データベースとは,情報処理装置,ネットワーク,ストレージからなりデータベース処理を行うシステムという意味で使用するもの」であるから,引用発明は“システム”であるといえる。
そして,引用発明の「システム管理機構」は,「各ホストの処理負荷を監視し,処理負荷が大きくなるとDB管理機構にホストの追加を指令したり,SANやストレージ装置に対して各DBプロセスに割り当てるディスクの変更を指令するもの」であるところ,「ホストの追加を指令したり」,「ディスクの変更を指令する」ことは,ホスト,ディスクというシステムのリソースを管理することであるといえるから,“リソースマネージャ”であるといえる。また,「システム管理機構」による「指令」は,何らかのハードウェアプロセッサを用いた情報処理によって行われることは明らかであって,「システム管理機構」が,“1つ以上のハードウェアプロセッサを有する”ことは明らかである。
よって,本件補正発明と引用発明とは,後記の点で相違するものの,“1つ以上のハードウェアプロセッサを有するリソースマネージャを備えたシステム”点で一致している。

(イ)引用発明は,「DB管理機構は,データベースをアクセスするクライアントのクエリーを受け」るものである。ここで,「クエリー」は“データ処理要求”であるといえ,「クエリー」を発する「クライアント」のコンピュータは,“コンピュータ使用クエリソース”といえる。
そして,引用発明において「データベースをアクセスする」ことは,「ストレージ装置に収装される」「複数のディスク」に格納されているデータベースのデータにアクセスすることを示すものであって,前記「ストレージ装置に収装される」「複数のディスク」は,“複数のストレージデバイス”といえ,前記「クエリー」は,データベースのデータに向けられていることは明らかであるから,引用発明の「クエリー」に関して,“コンピュータ利用クエリソースから受信されたデータ処理要求は,複数のストレージデバイス上に格納されたデータベースデータに向けられる”といえる。
さらに,引用発明では,前記「クエリー」を「複数のホスト11?14」が処理するところ,前記「複数のホスト11?14」は,「データベース処理を行う一つまたは複数のDBプロセス(処理を行うジョブ)を実行する」ものであるから,「複数のホスト11?14」は,全体として,データベース処理を行う“実行プラットフォーム”であるといえ,前記「クエリー」を”実行プラットフォーム”が実行するといえる。
以上のことから,本件補正発明の「データ処理要求」と引用発明の「クエリー」とは,後記の点で相違するものの,“実行プラットフォームによって実行される,コンピュータ利用クエリソースから受信されたデータ処理要求は,複数のストレージデバイス上に格納されたデータベースデータに向けられる”点で一致している。

(ウ)引用発明の「システム管理機構」は,「各ホストの処理負荷を監視」するところ,上記(イ)で検討したように,「複数のホスト11?14」は,全体として,データベース処理を行う“実行プラットフォーム”といえ,「各ホスト」は,かかる実行プラットフォームの“各実行ノード”であるといえ,さらに,「処理負荷」とは,CPUの現在の利用に基づく処理負荷であって“現在の利用”といえるので,結局,前記「各ホストの処理負荷を監視」することは,“実行プラットフォームの複数の実行ノードの現在の利用を監視する”ことに他ならない。
そして,引用発明の「複数のホスト11?14」は「CPUを持つ情報処理装置」であって,「各ホストは,データベース処理を行う一つまたは複数のDBプロセス(処理を行うジョブ)を実行する」ところ,「DBプロセス24?29がそれぞれディスク51?56のキャッシュを持つ」ものであるから,結局,DBプロセスを実行する「各ホスト」,すなわち,”各実行ノード”が「CPU」と「キャッシュ」を備えているものである。ここで,前記「CPU」は“プロセッサ”といえ,前記「キャッシュ」は,「複数のディスク」,すなわち,“複数のストレージデバイス”から取得されたデータを格納する“ローカルキャッシュ”といえるものである。
よって,本件補正発明の「リソースマネージャ」と引用発明の「システム管理機構」とは,後記の点で相違するものの,“実行プラットフォームの複数の実行ノードの現在の利用を監視することであって,各実行ノードは,プロセッサ及びローカルキャッシュを備え,前記ローカルキャッシュは複数のストレージデバイスから取得されたデータを格納するように構成され”ている点で一致している。

(エ)引用発明の「システム管理機構」は,「各ホストの処理負荷を監視し,処理負荷が大きくなるとDB管理機構にホストの追加を指令したり,SANやストレージ装置に対して各DBプロセスに割り当てるディスクの変更を指令するもの」である。
上記(ウ)で検討したように,「各ホストの処理負荷」は“複数の実行ノードの現在の利用”といえるので,「処理負荷が大きくなるとDB管理機構にホストの追加を指令したり,SANやストレージ装置に対して各DBプロセスに割り当てるディスクの変更を指令する」ことは,“複数の実行ノードの現在の利用”に基づいて,「ホストの追加」,「ディスクの変更」を指令することに他ならない。そして,「ホストの追加」は,“処理容量の追加”といえ,「ディスクの変更」として「物理ディスクを追加して最適化を行うことができる」ものであるから,前記「ディスクの変更」には,ディスクの追加,すなわち“ストレージ容量の追加”が含まれるものである。
引用発明の「システム管理機構」は,かかる“処理容量の追加”,“ストレージ容量の追加”の指令を,前述したように“複数の実行ノードの現在の利用”に基づいて指令するものであるから,かかる追加の指令を発する際には,“複数の実行ノードの現在の利用”に基づいて,“処理容量の追加”又は“ストレージ容量の追加”の“少なくとも一方が必要であると判定”したことによって指令を発していることは明らかである。
よって,本件補正発明の「リソースマネージャ」と引用発明の「システム管理機構」とは,後記の点で相違するものの,“複数の実行ノードの現在の利用に基づいて,追加のデータストレージ容量又は追加の処理容量の少なくとも一方が必要であると判定する”点で一致している。

(オ)引用発明の「システム管理機構」は,「各ホストの処理負荷を監視し,処理負荷が大きくなるとDB管理機構にホストの追加を指令したり,SANやストレージ装置に対して各DBプロセスに割り当てるディスク51?54の変更を指令する」ものである。ここで,上記(イ)(ウ)で検討したように,「複数のホスト11?14」は,全体として,データベース処理を行う“実行プラットフォーム”といえ,「各ホスト」は,かかる実行プラットフォームの“複数のノード”であるといえるところ,「ホストの追加」とは,少なくとも1つの新規の実行ノードを実行プラットフォームに追加することを意味するから,“少なくとも1つの新規の実行ノードを前記実行プラットフォームに追加する”ことに他ならず,その結果,“追加のデータストレージ容量又は追加の処理容量”のうち“追加の処理容量”が割り当てられるものである。
したがって,上記(エ)の検討結果も踏まえると,本件補正発明の「リソースマネージャ」と引用発明の「システム管理機構」とは,“前記判定に応じて,少なくとも1つの新規の実行ノードを実行プラットフォームに追加することにより,追加のデータストレージ容量又は追加の処理容量の少なくとも一方を割り当てる”点で一致している。

(カ)上記(イ)で検討したように,引用発明の「ストレージ装置に収装される」「複数のディスク」は,“複数のストレージデバイス”といえるところ,かかる「複数のディスク」は,データベースのデータを格納していることは明らかであって,通常,データベースのデータは”纏めて”格納されるものである。
よって,本件補正発明の「ストレージデバイス」と引用発明の「複数のディスク」とは,後記の点で相違するものの,”複数のストレージデバイスはデータベースデータを纏めて格納する“点で一致している。

イ 上記(ア)乃至(カ)の検討により,本件補正発明と引用発明とは,以下の点で一致し,また,以下の点で相違する。

<一致点>

「1つ以上のハードウェアプロセッサを有するリソースマネージャを備えたシステムであって,前記リソースマネージャは,
実行プラットフォームによって実行される,コンピュータ利用クエリソースから受信されたデータ処理要求は,複数のストレージデバイス上に格納されたデータベースデータに向けられる,ことと,
前記実行プラットフォームの複数の実行ノードの現在の利用を監視することであって,各実行ノードは,プロセッサ及びローカルキャッシュを備え,前記ローカルキャッシュは前記複数のストレージデバイスから取得されたデータを格納するように構成される,ことと,
前記複数の実行ノードの現在の利用に基づいて,追加のデータストレージ容量又は追加の処理容量の少なくとも一方が必要であると判定することと,
前記判定に応じて,少なくとも1つの新規の実行ノードを前記実行プラットフォームに追加することにより,追加のデータストレージ容量又は追加の処理容量の少なくとも一方を割り当てることと,
を実行するように構成され,
前記複数のストレージデバイスは前記データベースデータを纏めて格納する,システム。」

<相違点1>
コンピュータ利用クエリソースに関して,本件補正発明では,「複数の」コンピュータ利用クエリソースとしているのに対して,引用発明では,そのように特定していない点。

<相違点2>
「ストレージデバイス」に関して,本件補正発明は,「共有」ストレージデバイスであるのに対し,引用発明は,「無共有型」データベースのストレージデバイスである点。

<相違点3>
本件補正発明では,リソースマネージャが「データ処理要求」を「監視する」ものであって,監視された「前記データ処理要求」と,前記複数の実行ノードの現在の利用とに基づいて,追加のデータストレージ容量又は追加の処理容量の少なくとも一方が必要であると判定するものであるのに対して,引用発明では,DB管理機構がクエリー,すなわち,データ処理要求を受けるものの,DB管理機構を制御するシステム管理機構が,かかるデータ処理要求を「監視する」とはしておらず,よって,データ処理要求に基づいて,追加のデータストレージ容量又は追加の処理容量が必要であると判定することもしていない点。

<相違点4>
本件補正発明では,実行ノードが「ステートレス」であるのに対して,引用発明では,ホストがステートレスであるとは特定しない点。

<相違点5>
本件補正発明では,「各実行ノードの前記プロセッサは、前記複数の共有ストレージデバイスから分離し且つ独立している」のに対して,引用発明では,各ホストのCPUが複数の物理ディスクから分離し且つ独立しているとは特定していない点。

<相違点6>
本件補正発明では,「前記実行プラットフォームは互いに独立にスケーリングされる」のに対して,引用発明では,そのような特定がなされていない点。

(4)当審の判断

ア 相違点1について
データベースシステムにおいて,複数のクライアントコンピュータからクエリーを受けることは極めて一般的に行われていることである。
引用発明において,クエリーを発するクライアントのコンピュータを「複数」設けること,すなわち,「複数の」コンピュータ利用クエリソースとすることは,当業者であれば適宜なし得る事項に過ぎない。

イ 相違点2について
引用発明は,「ホスト11?14は,ストレージ装置の仮想化エンジンが作成した仮想ディスク41?44をアクセスし,仮想化エンジンは仮想ディスク41?44のデータを物理ディスク51?54にマッピングして記録する」ものである。
ここで,上記「(2)(2-1)引用文献1に記載された事項及び引用発明」のGから,”ホスト11は仮想ディスク41にアクセスし,仮想ディスク41は物理ディスク51,52にマッピングされている”態様,及び,”ホスト12は仮想ディスク42にマッピングされ,仮想ディスク42は物理ディスク51,52にマッピングされている”態様が読み取れる。
すなわち,ホスト11,12は,それぞれ仮想ディスク41,42を介して,ともに物理ディスク51,52にアクセスしており,物理ディスク51,52は,ホスト11,12に共有されている。
してみると,引用発明の「物理ディスク」,すなわち,”ストレージデバイス”も,ストレージ仮想化を採用した場合,ストレージデバイスを構成する物理ディスクが複数のホストに共有されるものであるから,引用発明も「物理ディスク」に関しては,「共有」ストレージデバイスであるといえる。
よって,相違点2は,実質的な相違点であるとはいえない。

ウ 相違点3について
上記「(2)(2-2)引用文献2に記載された事項及び技術 イ」に示されるように,上記引用文献2には,以下の技術が記載されている(再掲)。

「クエリ処理におけるサーバの作業負荷を再平衡化する方法であって,
特定のクエリを処理する第1の責任を,そのネットワーク内で比較的低いクエリ応答率を有するサーバから,そのネットワーク内で比較的速いネットワーク応答率を有するサーバへと,移動する方法」

引用文献2に記載の上記技術は,クエリ処理の責任を「クエリ応答率」が低いサーバから速いサーバに移すことによってサーバの作業負荷を再平衡化するクエリ処理技術を示すものである。ここで,「クエリ応答率」は,処理が要求されるクエリの量に依存することは明らかであって,「クエリ」は“データ処理要求”といえ,「サーバ」は“実行ノード”といえるから,引用文献2には,各実行ノードの作業負荷を再平衡化する際に,“データ処理要求”を作業負荷の指標として用いることが開示されているといえる。

また,上記「(2)(2-3)参考文献に記載された事項及び技術 イ」に示したとおり,上記参考文献には,以下の技術が記載されている(再掲)。

「オートスケーリング方法であって,
要求された処理を複数のコンピュータノードに分散して実行するシステムにおいて,該システムで実行するタスクの管理を行うコンピュータノードが,納期が指定された処理要求を受け付けた際に,
処理要求のタスクを納期内に処理終了可能なコンピュータノードがなく,さらに他のコンピュータノードでも納期内に処理終了可能なタスクを移動しても処理要求のタスクを納期内に処理終了可能なコンピュータノードを用意できないと判定された場合に,システムにコンピュータノードを増設する処理を実行する方法。」

参考文献に記載の上記技術は,要求された処理を複数のコンピュータノードに分散して実行するシステムにおいて,コンピュータノードが指定された納期内に処理要求のタスクを実行できない場合に,システムにコンピュータノードを増設する技術を示すものである。ここで,「要求された処理」は“データ処理要求”といえ,「コンピュータノード」は“実行ノード”といえるから,参考文献には,実行ノードの増設を行う際に,“データ処理要求”を増設の指標として用いることが開示されているといえる。

してみると,上記引用文献2及び参考文献には,いずれも,実行ノードに対して再平衡化や増設等の作業管理を行う際に,“データ処理要求”を作業管理の指標として用いる技術が開示されているといえ,このことから,実行ノードの作業管理を行う際に,“データ処理要求”を指標として用いることは,本願の優先日前において,通常行われている技術に過ぎないといえる。

一方,引用発明は,上記「(3)対比 ア(エ)」で検討したように,「システム管理機構」が,“前記複数の実行ノードの現在の利用に基づいて,追加のデータストレージ容量又は追加の処理容量の少なくとも一方が必要であると判定する”ものである。ここで,“実行ノードの現在の利用”は,実行ノードに発生する作業負担を示す指標であるといえるところ,実行ノードの処理能力,実行ノードの個数の他に,実行ノードに対して要求される“データ処理要求”にも依存するものであることは明らかであるから,“実行ノードの現在の利用”は,“データ処理要求”と関連性を有する指標であるといえる。

引用発明と,引用文献2及び参考文献に記載の上記技術とは,実行ノードに発生する作業負担に応じて,システムのリソースを管理するという機能において共通するものであって,前述したように,引用発明の“実行ノードの現在の利用”は“データ処理要求”と関連性を有する指標であるから,引用発明の「システム管理機構」において,“実行ノードの現在の利用”の監視に加えて,当該システム管理機構の制御対象であるデータ管理機構が受ける“データ処理要求”も監視するものとし,監視された「前記データ処理要求」と,複数の実行ノードの現在の利用とに基づいて,追加のデータストレージ容量又は追加の処理容量の少なくとも一方が必要であると判定するように構成することは,引用文献2及び参考文献に記載の,“データ処理要求”を指標として用いる上記技術に基づいて,当業者であれば容易になし得たものである。

エ 相違点4について
上記「2-1 実施可能要件について」の「(3)判断」で検討したように,本件補正発明における,実行ノードが「ステートレス」である点に関して,本願明細書を参照してもその意味する技術事項が明らかではないが,上記段落【0035】における「これらの実行ノードは,実行ノードについての状態情報,または,特定の状態ノードによってキャッシュされているデータについての状態情報を格納しないか,さもなくば,これらを保持しない」なる記載からすると,実行ノードが「ステートレス」であるとは,「状態情報」が具体的にどのような情報であるかは明らかではないものの,実行ノードが,実行ノードについての何らかの状態情報,または,キャッシュされているデータについての何らかの状態情報を格納しないものと推測することができる。

一方,引用発明は,「DBプロセス24?29がそれぞれディスク51?56のキャッシュを持つものであり,ホスト追加/削減の場合,あるディスク(例えば,ディスク52)を使用しているDBプロセス11?14を切り換えるとき(この例では,DBプロセス25からDBプロセス28),ディスクを受ける側のDBプロセス(DBプロセス28)のキャッシュは受けたディスク(ディスク52)のデータを持たない」ものである。
この点に関して,上記「(2)(2-1)引用文献1に記載された事項及び引用発明」のEから,”DBプロセス25に物理ディスク52に対応付けられている”態様が読み取れ,上記「(2)(2-1)引用文献1に記載された事項及び引用発明」のFから,”ホスト13でDBプロセス28が起動し,ホスト11のDBプロセス25の代わりに処理を行う際に,ディスクを受ける側のDBプロセス28が,DBプロセス25に対応付けられている物理ディスク52に対応付けられていない”態様が読み取れる。
引用発明では,ホスト13におけるDBプロセス28の起動に伴うこのような態様の結果として,上記「(2)(2-1)引用文献1に記載された事項及び引用発明」のDに記載されているように,「その結果,このDBプロセス(DBプロセス28)の性能がしばらく低下し,データベース全体の性能が低下する」ものである。

してみると,引用発明において,前記「あるディスク(例えば,ディスク52)を使用しているDBプロセス11?14を切り換えるとき(この例では,DBプロセス25からDBプロセス28),ディスクを受ける側のDBプロセス(DBプロセス28)のキャッシュは受けたディスク(ディスク52)のデータを持たない」とは,DBプロセスを切り換えるとき,DBプロセスのキャッシュは,かかる切り換えの前後でデータを引き継がないことを意味するものである。そして,DBプロセスの切り換えの前後でキャッシュのデータを引き継がない以上,キャッシュのデータに関するいかなる「状態情報」も引き継ぐ必要は無く,そもそも,かかる「状態情報」自体を予め格納しておく必要も無いものと推察される。

よって,引用発明において,各DBプロセスを実行するホストが,そもそもキャッシュに関する状態情報を格納しないとすること,すなわち,実行ノードを「ステートレス」とすることは,引用発明においてDBプロセスの切り換えの前後でキャッシュのデータを引き継がないという前記技術事項を参酌すれば,当業者であれば適宜なし得る事項と認められる。

オ 相違点5について
引用発明は,「ホスト11?14は,ストレージ装置の仮想化エンジンが作成した仮想ディスク41?44をアクセスし,仮想化エンジンは仮想ディスク41?44のデータを物理ディスク51?54にマッピングして記録する」ものであって,「性能を向上するために,仮想ディスク41?44と物理ディスク51?54とのマッピングを変更」して「ストレージ最適化」できるものである。
そして,「ストレージ最適化」とは,「仮想ディスク41?44の内容を変更しない(物理ディスク51?54の内容のみを変更する)ものであり,最適化は仮想ディスク41?44をアクセスしているホスト11?14(とDBプロセス24?29等のプロセス)にはトランスペアレントであり,ホスト11?14から物理ディスク51?54を透過的に読み書きすることができるものであり,物理ディスクを追加して最適化を行うことができる」ものである。
ここで,上記「(2)(2-1)引用文献1に記載された事項及び引用発明」のHから,”ホスト11?14が,それぞれ仮想ディスク41?44にアクセスする状態のまま,物理ディスクのみが,4つの物理ディスク51?54から,6つの物理ディスク51?56に追加されている”態様が読み取れる。

してみると,引用発明では,上記「(2)(2-1)引用文献1に記載された事項及び引用発明」のEから,”ホスト11?14が複数の物理ディスク51?54から分離している”ことが読み取れるところ,ストレージ仮想化を採用した場合は,ホストを追加することなく物理ディスクを追加して最適化できるものであり,また,「最適化は仮想ディスク41?44をアクセスしているホスト11?14(とDBプロセス24?29等のプロセス)にはトランスペアレントであ」る,すなわち,ホストからは物理ディスクの追加が見えないものであって,ホストが,物理ディスクの個数を意識することなく,追加された物理ディスクを含めた複数の物理ディスクにアクセスするものであるから,“ホストは複数の物理ディスクから分離し且つ独立している”といえる。
そして,引用発明の「複数のホスト11?14」は「CPUを持つ情報処理装置」であって,上記「(3)対比 ア(ウ)」で検討したように,「各ホスト」は“各実行ノード”といえ,「CPU」は”プロセッサ”といえ,上記イで検討したように,引用発明の「物理ディスク」は“共有ストレージデバイス”といえるから,結局,引用発明において,“ホストは複数の物理ディスクから分離し且つ独立している”ことは,「各実行ノードの前記プロセッサは、前記複数の共有ストレージデバイスから分離し且つ独立している」ことといえる。
以上のことから,上記相違点5は,実質的な相違点であるとはいえない。

カ 相違点6について
本件補正発明の「前記実行プラットフォームは互いに独立にスケーリングされる」なる記載に関して,「互いに独立」とは,何と何とが「互いに独立」しているのか必ずしも明らかではないが,本願明細書の段落【0022】における,
「更に、リソースマネージャ102、メタデータ110、実行プラットフォーム112、及びストレージプラットフォーム114のそれぞれは、ユーザ104?108から受信する要求に対する変更及びデータ処理プラットフォーム100のニーズの変化に依存して、(相互に独立に)スケールアップまたはスケールダウンされることが出来る。」
なる記載を参酌すると,本件補正発明の上記記載は,実行プラットフォームが,リソースマネージャ,ストレージプラットフォームから独立してスケーリングされることを意味するものと解される。
一方,引用発明においても,上記「(2)(2-1)引用文献1に記載された事項及び引用発明」のFから,ホストの追加はシステム管理機構を追加することなく行われることが読み取れ,さらに,上記オで検討したように,“ホスト11?14は複数の物理ディスクから分離し且つ独立している”ものであるから,結局,ホストは,システム管理機構,物理ディスクから独立して追加されているといえ,引用発明も,「前記実行プラットフォームは互いに独立にスケーリングされる」といえる。
よって,上記相違点6は,実質的な相違点であるとはいえない。

キ 小括

上記で検討したごとく,相違点1乃6に係る構成は当業者が容易に想到し得たものであり,そして,これらの相違点を総合的に勘案しても,本件補正発明の奏する作用効果は,引用発明,及び上記技術の奏する作用効果から予測される範囲内のものにすぎず,格別顕著なものということはできない。

したがって,本件補正発明は,引用発明,及び上記技術に基づいて,当業者が容易に発明をすることができたものであり,特許法第29条第2項の規定により,特許出願の際独立して特許を受けることができない。

3 本件補正についてのむすび

よって,本件補正は,特許法第17条の2第6項において準用する同法第126条第7項の規定に違反するので,同法第159条第1項の規定において読み替えて準用する同法第53条第1項の規定により却下すべきものである。

よって,上記補正の却下の決定の結論のとおり決定する。

第3 本願発明について

1 本願発明の認定

令和1年11月22日付けでなされた手続補正は,上記のとおり却下されたので,本願の請求項に係る発明は,平成31年2月20日付けでなされた手続補正により補正された特許請求の範囲の請求項1乃至20に記載された事項により特定されるものであるところ,その請求項1に係る発明(以下,「本願発明」という。)は,その請求項1に記載された事項により特定される,以下のとおりのものである。

「 【請求項1】
1つ以上のハードウェアプロセッサを有するリソースマネージャを備えたシステムであって、前記リソースマネージャは、
実行プラットフォームによって実行される、複数のコンピュータ利用クエリソースから受信されたデータ処理要求、を監視することであって、前記データ処理要求は、複数の共有ストレージデバイス上に格納されたデータベースデータに向けられる、ことと、
前記実行プラットフォームの複数の実行ノードの現在の利用を監視することであって、各実行ノードはプロセッサ及びローカルキャッシュを備え、前記ローカルキャッシュは前記複数の共有ストレージデバイスから取得されたデータを格納するように構成される、ことと、
前記データ処理要求と、前記複数の実行ノードの現在の利用とに基づいて、追加のデータストレージ容量又は追加の処理容量の少なくとも一方が必要であると判定することと、
前記判定に応じて、少なくとも1つの新規の実行ノードを前記実行プラットフォームに追加することにより、追加のデータストレージ容量又は追加の処理容量の少なくとも一方を割り当てることと、
を実行するように構成され、
前記複数の共有ストレージデバイスは前記データベースデータを纏めて格納し、前記実行プラットフォームは互いに独立にスケーリングされる、システム。」

2 原査定の拒絶の理由

原査定の拒絶の理由は,この出願の請求項1に係る発明は,本願の出願日前に頒布された又は電気通信回線を通じて公衆に利用可能となった下記の引用文献1及び引用文献2に記載された発明に基づいて,その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから,特許法第29条第2項の規定により特許を受けることができない,というものである。

引用文献1:特開2005-56077号公報
引用文献2:特表2009-527056号公報

3 引用文献に記載されている技術的事項及び引用発明の認定

原査定の拒絶の理由に引用された,引用文献1及び引用文献2とその記載事項は,上記「第2 令和1年11月22日付けの手続補正についての補正却下の決定」の「2 補正の適否」の「2-2 進歩性について」の「(2)(2-1)引用文献1に記載された事項及び引用発明」及び「(2)(2-2)引用文献2に記載された事項及び技術」に記載したとおりである。

4 対比・判断

本願発明は,上記「第2 令和1年11月22日付けの手続補正についての補正却下の決定」の「2 補正の適否」の「2-2 進歩性について」で検討した本件補正発明から,「各実行ノードは,ステートレスであり」との限定事項を削除し,「各実行ノードの前記プロセッサは,前記複数の共有ストレージデバイスから分離し且つ独立している」との限定事項を削除したものである。

そうすると,本願発明の発明特定事項を全て含む本件補正発明が,上記「第2 令和1年11月22日付けの手続補正についての補正却下の決定」の「2 補正の適否」の「2-2 進歩性について」の「(3)対比」及び「(4)当審の判断」に記載したとおり,引用発明,及び上記技術に基づいて当業者が容易に発明をすることができたものであるから,上記特定の限定を省いた本願発明も同様の理由により,引用発明,及び上記技術に基づいて,当業者が容易に発明をすることができたものである。

第4 むすび

以上のとおり,本願の請求項1に係る発明は,特許法第29条第2項の規定により特許を受けることができないものであるから,その余の請求項に係る発明について検討するまでもなく,本願は拒絶すべきものである。

よって,結論のとおり審決する。

 
別掲
 
審理終結日 2020-08-26 
結審通知日 2020-09-01 
審決日 2020-09-14 
出願番号 特願2016-552966(P2016-552966)
審決分類 P 1 8・ 121- Z (G06F)
P 1 8・ 575- Z (G06F)
P 1 8・ 536- Z (G06F)
最終処分 不成立  
前審関与審査官 漆原 孝治  
特許庁審判長 田中 秀人
特許庁審判官 月野 洋一郎
▲はま▼中 信行
発明の名称 リソース提供システム及び方法  
代理人 青木 宏義  
代理人 大菅 義之  
代理人 天田 昌行  
  • この表をプリントする

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