• ポートフォリオ機能


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

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

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

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

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

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

[理由]

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

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

本件補正により,特許請求の範囲の請求項1乃至20の記載は,次のとおり補正された。(以下,この特許請求の範囲に記載された請求項を「補正後の請求項」という。)
(当審注:下線は,補正箇所を示すものとして,請求人が付与したものである。)

「 【請求項1】
複数のファイルを含むデータベースデータを纏めて格納する複数の共有ストレージデバイスと、
メモリに格納され且つ1つ以上のプロセッサによって実行されるソフトウェアプログラムを備えるリソースマネージャと、
を備え、
前記リソースマネージャは、
コンピュータ使用クエリソースによって前記データベースデータに向けられた少なくとも1つのデータベースクエリを受信することと、
前記少なくとも1つのデータベースクエリに応答して処理されるべき、前記データベースデータ内の前記複数のファイルのうちの1つ以上のファイルを特定することと、
前記複数のファイルのうちの前記1つ以上のファイルの処理を複数の別々のタスクに分割することと、
前記複数の別々のタスクのうちの異なるタスクを、実行プラットフォームの複数のノードのうちの異なるノードに割り当てることであって、前記リソースマネージャは、前記実行プラットフォームの前記複数のノードから独立し且つ分離されている、ことと、
を実行するように構成され、
前記実行プラットフォームは前記複数の別々のタスクを実行し、
前記実行プラットフォームの前記複数のノードの各ノードは、前記コンピュータ使用クエリソース及び前記複数の共有ストレージデバイスから独立しており、且つ、
前記データベースデータの少なくとも一部分をキャッシュするローカルキャッシュと、
前記リソースマネージャによって割り当てられた前記複数の別々のタスクのうちの1つ以上のタスクを実行するプロセッサと、
を備える、システム。
【請求項2】
前記少なくとも1つのデータベースクエリは、1つ以上のSQLステートメントの形式である、請求項1に記載のシステム。
【請求項3】
前記複数の別々のタスクのうちの少なくとも1つのタスクは、前記複数の共有ストレージデバイスからの1つ以上の読み出しを含む、請求項1に記載のシステム。
【請求項4】
前記複数の別々のタスクのうちの少なくとも1つのタスクは、前記複数の共有ストレージデバイスへの1つ以上の書き込みを含む、請求項1に記載のシステム。
【請求項5】
前記リソースマネージャは、更に、所定の時間の間、前記複数の共有ストレージデバイスへのアクセスを割り当てるように構成されている、請求項1に記載のシステム。
【請求項6】
前記リソースマネージャは、更に、受信されたSQLステートメントにおいて特定されているデータベースデータに関連付けられた、前記複数の共有ストレージデバイスのうちの少なくとも1つのストレージデバイスを特定するように構成されている、請求項1に記載のシステム。
【請求項7】
前記実行プラットフォームは複数の仮想ウェアハウスを備えている、請求項1に記載のシステム。
【請求項8】
前記複数の仮想ウェアハウスの各仮想ウェアハウスは、前記複数のノードのうちの少なくとも1つのノードを含む、請求項7に記載のシステム。
【請求項9】
前記複数のノードの各ノードの前記ローカルキャッシュは、前記複数の共有ストレージデバイスのうちのいずれかのデバイスからのデータベースデータを格納するように構成されている、請求項1に記載のシステム。
【請求項10】
前記複数のノードの各ノードは、
前記複数の共有ストレージデバイスのうちのいずれかのデバイスからデータベースデータを読み出し、
前記複数の共有ストレージデバイスのうちのいずれかのデバイスへデータベースデータを書き込む、
ように構成されている、請求項8に記載のシステム。
【請求項11】
各ノードは、前記データベースデータの必要とされる部分が前記ローカルキャッシュにキャッシュされているときにはいつでも、前記データベースデータの前記必要とされる部分を、前記複数の共有ストレージデバイスからではなく、前記データベースデータの前記必要とされる部分に応じた前記ローカルキャッシュから読み出すように構成されている、請求項8に記載のシステム。
【請求項12】
前記実行プラットフォームは、前記リソースマネージャからの命令に応じて、1つ以上の新規の仮想ウェアハウスを追加するように構成されている、請求項7に記載のシステム。
【請求項13】
前記実行プラットフォームは、更に、より多くの処理が必要である場合には、リアルタイムで1つ以上の新規の仮想ウェアハウスを追加するように構成されている、請求項12に記載のシステム。
【請求項14】
データベースデータを纏めて格納する複数の共有ストレージデバイスと、少なくとも1つのコンピュータ使用クエリソースとの間に、インターフェースシステムを配置させることであって、
前記インターフェースシステムはリソースマネージャ及び実行プラットフォームを備え、
前記リソースマネージャは、メモリに格納され且つ前記実行プラットフォームに接された1つ以上のプロセッサによって実行されるソフトウェアプログラムを備え、
前記実行プラットフォームは前記複数の共有ストレージデバイスから独立しており、
前記実行プラットフォームは前記少なくとも1つのコンピュータ使用クエリソースから独立しており、
前記実行プラットフォームは複数のノードを備え、各ノードは、少なくとも1つのプロセッサと、前記データベースデータの少なくとも一部分をキャッシュする少なくとも1つのローカルキャッシュとを備え、
前記リソースマネージャは、前記実行プラットフォームの前記複数のノードから独立し且つ分離されている、ことと、
前記少なくとも1つのコンピュータ使用クエリソースによって前記データベースデータに向けられた少なくとも1つのデータベースクエリを、前記リソースマネージャによって受信することと、
前記少なくとも1つのデータベースクエリに応答して実行されるべき複数のタスクを、前記リソースマネージャによって決定することと、
前記リソースマネージャによって、前記複数のタスクをその処理のために前記複数の実行ノードに分配することと、
前記複数のタスクの処理から得られた結果を、前記実行プラットフォームによって前記リソースマネージャへ提供することと、
前記リソースマネージャによって、前記結果を使用して、前記少なくとも1つのデータベースクエリに応答することと、
を含む方法。
【請求項15】
前記少なくとも1つのデータベースクエリは1つ以上のSQLステートメントを含む、請求項14に記載の方法。
【請求項16】
前記複数のノードは複数の仮想ウェアハウスへと編成されて、前記複数の仮想ウェアハウスの各仮想ウェアハウスは前記複数のノードのうちの幾つかのノードを備える、請求項14に記載の方法。
【請求項17】
前記複数のノードのそれぞれのノードによって、それに割り当てられた前記少なくとも1つのタスクを処理することを更に含み、該処理は、
前記少なくとも1つのタスクを処理するために必要な前記データベースデータの一部分が、それに応じた前記ローカルキャッシュにキャッシュされているか否かを判定することと、
前記データベースデータの前記一部分が前記ローカルキャッシュにキャッシュされていると判定された場合に、前記データベースデータの前記一部分を前記ローカルキャッシュから取得することと、
前記データベースデータの前記一部分が前記ローカルキャッシュにキャッシュされていないと判定された場合に、前記データベースデータの前記一部分を前記複数の共有ストレージデバイスから取得し、且つ、前記データベースデータの前記一部分を前記ローカルキャッシュにキャッシュすることと、
を含む、請求項14に記載の方法。
【請求項18】
データベースデータを格納する手段と、
少なくとも1つのコンピュータ使用クエリソースによって前記データベースデータに向けられた少なくとも1つのデータベースクエリを受信する手段と、
前記少なくとも1つのデータベースクエリに応答して前記データベースデータ内のどのファイルが処理されるべきかを判定する手段と、
前記ファイルの処理を複数の別々のタスクに分割する手段と、
前記複数の別々のタスクのうちの異なるタスクを、実行プラットフォームの複数のノードのうちの異なるノードに割り当てる手段と、
前記複数の別々のタスクを実行する前記実行プラットフォームと、
を備え、
前記複数のノードの各ノードは、前記少なくとも1つのコンピュータ使用クエリソースと、前記データベースデータを格納する手段とから独立しており、且つ、
前記割り当てる手段によって割り当てられた前記複数の別々のタスクのうちの1つ以上のタスクを実行する少なくとも1つのプロセッサと、
前記データベースデータの少なくとも一部分をキャッシュする少なくとも1つのローカルキャッシュと、
を備え、
前記少なくとも1つのデータベースクエリを受信する手段は、前記実行プラットフォームの前記複数のノードから独立し且つ分離されている、システム。
【請求項19】
前記複数のノードは、複数の仮想ウェアハウスとして編成されている、請求項18に記載のシステム。
【請求項20】
前記複数の仮想ウェアハウスの各仮想ウェアハウスは、前記複数のノードのうちの1つよりも多くのノードを含む、請求項19に記載のシステム。」

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

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

「 【請求項1】
複数のファイルを含むデータベースデータを纏めて格納する複数の共有ストレージデバイスと、
メモリに格納され且つ1つ以上のプロセッサによって実行されるソフトウェアプログラムを備えるリソースマネージャと、
を備え、
前記リソースマネージャは、
コンピュータ使用クエリソースによって前記データベースデータに向けられた少なくとも1つのデータベースクエリを受信することと、
前記少なくとも1つのデータベースクエリに応答して処理されるべき、前記データベースデータ内の前記複数のファイルのうちの1つ以上のファイルを特定することと、
前記複数のファイルのうちの前記1つ以上のファイルの処理を複数の別々のタスクに分割することと、
前記複数の別々のタスクのうちの異なるタスクを、実行プラットフォームの複数のノードのうちの異なるノードに割り当てることと、
を実行するように構成され、
前記実行プラットフォームは前記複数の別々のタスクを実行し、
前記実行プラットフォームの前記複数のノードの各ノードは、前記コンピュータ使用クエリソース及び前記複数の共有ストレージデバイスから独立しており、且つ、
前記データベースデータの少なくとも一部分をキャッシュするローカルキャッシュと、
前記リソースマネージャによって割り当てられた前記複数の別々のタスクのうちの1つ以上のタスクを実行するプロセッサと、
を備える、システム。
【請求項2】
前記少なくとも1つのデータベースクエリは、1つ以上のSQLステートメントの形式である、請求項1に記載のシステム。
【請求項3】
前記複数の別々のタスクのうちの少なくとも1つのタスクは、前記複数の共有ストレージデバイスからの1つ以上の読み出しを含む、請求項1に記載のシステム。
【請求項4】
前記複数の別々のタスクのうちの少なくとも1つのタスクは、前記複数の共有ストレージデバイスへの1つ以上の書き込みを含む、請求項1に記載のシステム。
【請求項5】
前記リソースマネージャは、更に、所定の時間の間、前記複数の共有ストレージデバイスへのアクセスを割り当てるように構成されている、請求項1に記載のシステム。
【請求項6】
前記リソースマネージャは、更に、受信されたSQLステートメントにおいて特定されているデータベースデータに関連付けられた、前記複数の共有ストレージデバイスのうちの少なくとも1つのストレージデバイスを特定するように構成されている、請求項1に記載のシステム。
【請求項7】
前記実行プラットフォームは複数の仮想ウェアハウスを備えている、請求項1に記載のシステム。
【請求項8】
前記複数の仮想ウェアハウスの各仮想ウェアハウスは、前記複数のノードのうちの少なくとも1つのノードを含む、請求項7に記載のシステム。
【請求項9】
前記複数のノードの各ノードの前記ローカルキャッシュは、前記複数の共有ストレージデバイスのうちのいずれかのデバイスからのデータベースデータを格納するように構成されている、請求項1に記載のシステム。
【請求項10】
前記複数のノードの各ノードは、
前記複数の共有ストレージデバイスのうちのいずれかのデバイスからデータベースデータを読み出し、
前記複数の共有ストレージデバイスのうちのいずれかのデバイスへデータベースデータを書き込む、
ように構成されている、請求項8に記載のシステム。
【請求項11】
各ノードは、前記データベースデータの必要とされる部分が前記ローカルキャッシュにキャッシュされているときにはいつでも、前記データベースデータの前記必要とされる部分を、前記複数の共有ストレージデバイスからではなく、前記データベースデータの前記必要とされる部分に応じた前記ローカルキャッシュから読み出すように構成されている、請求項8に記載のシステム。
【請求項12】
前記実行プラットフォームは、前記リソースマネージャからの命令に応じて、1つ以上の新規の仮想ウェアハウスを追加するように構成されている、請求項7に記載のシステム。
【請求項13】
前記実行プラットフォームは、更に、より多くの処理が必要である場合には、リアルタイムで1つ以上の新規の仮想ウェアハウスを追加するように構成されている、請求項12に記載のシステム。
【請求項14】
データベースデータを纏めて格納する複数の共有ストレージデバイスと、少なくとも1つのコンピュータ使用クエリソースとの間に、インターフェースシステムを配置させることであって、
前記インターフェースシステムはリソースマネージャ及び実行プラットフォームを備え、
前記リソースマネージャは、メモリに格納され且つ前記実行プラットフォームに接続された1つ以上のプロセッサによって実行されるソフトウェアプログラムを備え、
前記実行プラットフォームは前記複数の共有ストレージデバイスから独立しており、
前記実行プラットフォームは前記少なくとも1つのコンピュータ使用クエリソースから独立しており、
前記実行プラットフォームは複数のノードを備え、各ノードは、少なくとも1つのプロセッサと、前記データベースデータの少なくとも一部分をキャッシュする少なくとも1つのローカルキャッシュとを備え、
前記リソースマネージャは、前記実行プラットフォームの前記複数のノードから独立している、ことと、
前記少なくとも1つのコンピュータ使用クエリソースによって前記データベースデータに向けられた少なくとも1つのデータベースクエリを、前記リソースマネージャによって受信することと、
前記少なくとも1つのデータベースクエリに応答して実行されるべき複数のタスクを、前記リソースマネージャによって決定することと、
前記リソースマネージャによって、前記複数のタスクをその処理のために前記複数の実行ノードに分配することと、
前記複数のタスクの処理から得られた結果を、前記実行プラットフォームによって前記リソースマネージャへ提供することと、
前記リソースマネージャによって、前記結果を使用して、前記少なくとも1つのデータベースクエリに応答することと、
を含む方法。
【請求項15】
前記少なくとも1つのデータベースクエリは1つ以上のSQLステートメントを含む、
請求項14に記載の方法。
【請求項16】
前記複数のノードは複数の仮想ウェアハウスへと編成されて、前記複数の仮想ウェアハウスの各仮想ウェアハウスは前記複数のノードのうちの幾つかのノードを備える、
請求項14に記載の方法。
【請求項17】
前記複数のノードのそれぞれのノードによって、それに割り当てられた前記少なくとも1つのタスクを処理することを更に含み、該処理は、
前記少なくとも1つのタスクを処理するために必要な前記データベースデータの一部分が、それに応じた前記ローカルキャッシュにキャッシュされているか否かを判定することと、
前記データベースデータの前記一部分が前記ローカルキャッシュにキャッシュされていると判定された場合に、前記データベースデータの前記一部分を前記ローカルキャッシュから取得することと、
前記データベースデータの前記一部分が前記ローカルキャッシュにキャッシュされていないと判定された場合に、前記データベースデータの前記一部分を前記複数の共有ストレージデバイスから取得し、且つ、前記データベースデータの前記一部分を前記ローカルキャッシュにキャッシュすることと、
を含む、請求項14に記載の方法。
【請求項18】
データベースデータを格納する手段と、
少なくとも1つのコンピュータ使用クエリソースによって前記データベースデータに向けられた少なくとも1つのデータベースクエリを受信する手段と、
前記少なくとも1つのデータベースクエリに応答して前記データベースデータ内のどのファイルが処理されるべきかを判定する手段と、
前記ファイルの処理を複数の別々のタスクに分割する手段と、
前記複数の別々のタスクのうちの異なるタスクを、実行プラットフォームの複数のノードのうちの異なるノードに割り当てる手段と、
前記複数の別々のタスクを実行する前記実行プラットフォームと、
を備え、
前記複数のノードの各ノードは、前記少なくとも1つのコンピュータ使用クエリソースと、前記データベースデータを格納する手段とから独立しており、且つ、
前記割り当てる手段によって割り当てられた前記複数の別々のタスクのうちの1つ以上のタスクを実行する少なくとも1つのプロセッサと、
前記データベースデータの少なくとも一部分をキャッシュする少なくとも1つのローカルキャッシュと、
を備え、
前記少なくとも1つのデタベースクエリを受信する手段は、前記実行プラットフォームの前記複数のノードから独立している、システム。
【請求項19】
前記複数のノードは、複数の仮想ウェアハウスとして編成されている、請求項18に記載のシステム。
【請求項20】
前記複数の仮想ウェアハウスの各仮想ウェアハウスは、前記複数のノードのうちの1つよりも多くのノードを含む、請求項19に記載のシステム。」

2 補正の適否

本件補正は,願書に最初に添付した明細書,特許請求の範囲又は図面に記載した事項の範囲内においてなされており,特許法第17条の2第3項の規定に適合している。

また,本件補正は,特別な技術的特徴を変更(シフト補正)しようとするものではなく,特許法第17条の2第4項の規定に適合している。

そして,本件補正は,補正前の請求項1に記載の「リソースマネージャ」について,「前記リソースマネージャは、前記実行プラットフォームの前記複数のノードから独立し且つ分離されている」との限定を付加し,
補正前の請求項14に記載の「リソースマネージャ」について,「且つ分離されている」との限定を付加し,
補正前の請求項18に記載の「少なくとも1つのデタベースクエリを受信する手段」について,「データベースクエリ」と誤記を訂正し,「且つ分離されている」との限定を付加することを含むものである。
そして,本件補正前の請求項1に記載された発明と本件補正後の請求項1に記載される発明の産業上の利用分野及び解決しようとする課題が同一であるから,特許法第17条の2第5項第2号の特許請求の範囲の減縮を目的とするものに該当する。

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

(1)本件補正発明

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

「 【請求項1】
複数のファイルを含むデータベースデータを纏めて格納する複数の共有ストレージデバイスと、
メモリに格納され且つ1つ以上のプロセッサによって実行されるソフトウェアプログラムを備えるリソースマネージャと、
を備え、
前記リソースマネージャは、
コンピュータ使用クエリソースによって前記データベースデータに向けられた少なくとも1つのデータベースクエリを受信することと、
前記少なくとも1つのデータベースクエリに応答して処理されるべき、前記データベースデータ内の前記複数のファイルのうちの1つ以上のファイルを特定することと、
前記複数のファイルのうちの前記1つ以上のファイルの処理を複数の別々のタスクに分割することと、
前記複数の別々のタスクのうちの異なるタスクを、実行プラットフォームの複数のノードのうちの異なるノードに割り当てることであって、前記リソースマネージャは、前記実行プラットフォームの前記複数のノードから独立し且つ分離されている、ことと、
を実行するように構成され、
前記実行プラットフォームは前記複数の別々のタスクを実行し、
前記実行プラットフォームの前記複数のノードの各ノードは、前記コンピュータ使用クエリソース及び前記複数の共有ストレージデバイスから独立しており、且つ、
前記データベースデータの少なくとも一部分をキャッシュするローカルキャッシュと、
前記リソースマネージャによって割り当てられた前記複数の別々のタスクのうちの1つ以上のタスクを実行するプロセッサと、
を備える、システム。」

(2)引用文献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がバックエンドサーバである。」

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 「図4



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


F 「図5



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


イ 上記Bの段落【0031】に記載されている「プラグラム」は「プログラム」の誤記であると認められる。

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

「無共有型データベースであって,
本発明でいう「データベース」は,情報処理装置,ネットワーク,ストレージからなりデータベース処理を行うシステムという意味で使用するものであり,
無共有型データベースは,複数のホスト11?14(CPUを持つ情報処理装置)と複数のディスクからなり,
各ホストは,データベース処理を行う一つまたは複数のDBプロセス(処理を行うジョブ)を実行するものであり,
これらのディスクは,ストレージ装置に収装されるものであり,
無共有型データベースのDB管理機構は,データベースをアクセスするクライアントのクエリーを受け,処理をホスト11?14に分配し,ホスト11?14の処理結果をまとめ,クエリーの結果をクライアントに返すものであり,クライアントからのリクエストを受けて,実際に処理を行うDBプロセスまたはディスク(またはボリューム)を決定するものであり,所定のハードウェア(サーバ等)上で機能するプログラムなどで構成されるものであり,
ホスト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のキャッシュを持つ,
無共有型データベース。」

(3)対比

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

(ア)引用発明は「無共有型データベース」であるところ,「複数のディスク」を備えており,「これらのディスクは,ストレージ装置に収装されるもの」である。ここで,前記「複数のディスク」は“複数のストレージデバイス”であるといえ,データベースのデータを格納するものであることは明らかであるから,引用発明は“データベースデータを格納する複数のストレージデバイス”を備えているといえる。
よって,本件補正発明と引用発明とは,後記の点で相違するものの,“データベースデータを格納する複数のストレージデバイスを備える”点で一致している。

(イ)引用発明は「無共有型データベース」であるところ,引用発明における「データベース」は,「情報処理装置,ネットワーク,ストレージからなりデータベース処理を行うシステムという意味で使用するもの」であるから,本件補正発明と引用発明とは“システム”である点で一致している。
そして,引用発明の「DB管理機構」は,データベースを管理するものであって,前述したように,引用発明における「データベース」はデータベース処理を行うシステムの意味であるから,システムを管理するものといえ,システムを管理することには,システムのリソースを管理することも含まれるのが通常であるから,“リソースマネージャ”の一種であるといえる。
さらに,引用発明の「DB管理機構」は,「所定のハードウェア(サーバ等)上で機能するプログラムなどで構成される」ものであり,当該プログラムは,“メモリに格納され1つ以上のプロセッサによって実行されるソフトウェアプログラム”であることは明らかである。
よって,本件補正発明と引用発明とは,“メモリに格納され且つ1つ以上のプロセッサによって実行されるソフトウェアプログラムを備えるリソースマネージャを備える”点で一致している。

(ウ)引用発明の「DB管理機構」は,「データベースをアクセスするクライアントのクエリーを受け」るものである。ここで,引用発明の「クエリー」は,本件補正発明の“データベースクエリ”に相当するものであり,引用発明では,「クライアント」のコンピュータから,データベースのデータに向けられた「クエリー」を受信していることは明らかであって,かかる「クエリー」を発する「クライアント」は,“コンピュータ使用クエリソース”といえるから,結局,引用発明の「DB管理機構」は,“コンピュータ使用クエリソース”から“データベースデータに向けられたデータベースクエリ”を受信しているといえる。
よって,上記(イ)の検討結果も踏まえると,本件補正発明の「リソースマネージャ」と引用発明の「DB管理機構」とは,“コンピュータ使用クエリソースによって前記データベースデータに向けられた少なくとも1つのデータベースクエリを受信する”点で一致している。

(エ)引用発明の「DB管理機構」は,「クライアントのクエリーを受け」るものであって,「クライアントからのリクエストを受けて,実際に処理を行う」「ディスク(またはボリューム)を決定する」ものであるから,クライアントからのクエリーに応答して,処理の対象となるボリュームを特定するものである。
そして,クエリーは,データベース内のデータにアクセスするために発されるものであり,また,データベースのデータのボリュームには,一般に,データはファイルの形式で格納され,データベースには複数のファイルが纏めて格納されるものであるところ,引用発明における上記のボリュームを決定することは,クエリーによりアクセスしようとするデータを格納するファイルを,纏めて格納されている複数のファイルのうちから特定するために行っているといえるので,引用発明の「DB管理機構」も,クライアントからのクエリーに応答して処理されるべき,データベース内の複数のファイルのうちの1つ以上のファイルを特定しているといえる。
よって,上記(ア)乃至(ウ)の検討結果も踏まえると,本件補正発明と引用発明とは,”複数のファイルを含む”データベースデータを”纏めて”格納する複数の共有ストレージデバイスを備える点で一致しており,且つ,本件補正発明の「リソースマネージャ」と引用発明の「DB管理機構」とは,後記の点で相違するものの,“少なくとも1つのデータベースクエリに応答して処理されるべき,データベースデータ内の複数のファイルのうちの1つ以上のファイルを特定することを実行する”点で一致している。

(オ)引用発明の「DB管理機構」は,「データベースをアクセスするクライアントのクエリーを受け,処理をホスト11?14に分配」するものであって,「各ホストは,データベース処理を行う一つまたは複数のDBプロセス(処理を行うジョブ)を実行する」ものである。
ここで,引用発明の「複数のホスト11?14」は,「データベース処理を行う一つまたは複数のDBプロセス(処理を行うジョブ)を実行する」ものであるから,前記「複数のホスト11?14」は,全体として,データベース処理を行う“実行プラットフォーム”であるといえ,「各ホスト」は,かかる実行プラットフォームの“各ノード”であるといえる。また,「複数のDBプロセス(処理を行うジョブ)」は,“複数の別々のタスク”であるといえる。
そして,上記(エ)で検討したように,「DB管理機構」は,“少なくとも1つのデータベースクエリに応答して処理されるべき,データベースデータ内の複数のファイルのうちの1つ以上のファイルを特定する”ところ,「処理をホスト11?14に分配」することは,処理されるべき1つ以上のファイルの処理を複数の別々のタスクに分割して,ホスト11?14のそれぞれに分配する,すなわち,“実行プラットフォームの複数のノードのうちの異なるノードに割り当てる”ことに他ならない。
よって,本件補正発明の「リソースマネージャ」と引用発明の「DB管理機構」とは,後記の点で相違するものの,“複数のファイルのうちの1つ以上のファイルの処理を複数の別々のタスクに分割する”点,“前記複数の別々のタスクのうちの異なるタスクを,実行プラットフォームの複数のノードのうちの異なるノードに割り当てる”点で一致している。

(カ)上記(オ)で検討したように,引用発明の「複数のホスト11?14」は,全体として,データベース処理を行う“実行プラットフォーム”であるといえるところ,各ホストが「別々のDBプロセス(処理を行うジョブ)」,すなわち,“別々のタスク”を実行するものである。
よって,本件補正発明と引用発明とは,後記の点で相違するものの,“実行プラットフォームは複数の別々のタスクを実行する”点で一致している。

(キ)引用発明は,「各ホストは,データベース処理を行う一つまたは複数のDBプロセス(処理を行うジョブ)を実行する」ものであり,「DBプロセス24?29がそれぞれディスク51?56のキャッシュを持つ」ものである。
ここで,「DBプロセス24?29がそれぞれディスク51?56のキャッシュを持つ」ことは,かかるDBプロセス24?29を実行する「各ホスト」が,データベースの少なくとも一部分をキャッシュするローカルキャッシュを持つことに他ならない。
そして,引用発明の「複数のホスト11?14」は「CPUを持つ情報処理装置」であるところ,上記(オ)で検討したように,「複数のDBプロセス」は,“複数の別々のタスク”といえ,また,「CPU」は“プロセッサ”といえるから,引用発明の「各ホスト」は,“複数の別々のタスク”のうちの1つ以上のタスクを実行する“プロセッサ”を備えることは明らかである。
よって,上記(オ)の検討結果も踏まえると,本件補正発明の「各ノード」と引用発明の「各ホスト」とは,後記の点で相違するものの,“データベースデータの少なくとも一部分をキャッシュするローカルキャッシュと,リソースマネージャによって割り当てられた複数の別々のタスクのうちの1つ以上のタスクを実行するプロセッサとを備える”点で一致している。

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

<一致点>

「複数のファイルを含むデータベースデータを纏めて格納する複数のストレージデバイスと,
メモリに格納され且つ1つ以上のプロセッサによって実行されるソフトウェアプログラムを備えるリソースマネージャと,
を備え,
前記リソースマネージャは,
コンピュータ使用クエリソースによって前記データベースデータに向けられた少なくとも1つのデータベースクエリを受信することと,
前記少なくとも1つのデータベースクエリに応答して処理されるべき,前記データベースデータ内の前記複数のファイルのうちの1つ以上のファイルを特定することと,
前記複数のファイルのうちの前記1つ以上のファイルの処理を複数の別々のタスクに分割することと,
前記複数の別々のタスクのうちの異なるタスクを,実行プラットフォームの複数のノードのうちの異なるノードに割り当てることと,
を実行するように構成され,
前記実行プラットフォームは前記複数の別々のタスクを実行し,
前記実行プラットフォームの前記複数のノードの各ノードは,
前記データベースデータの少なくとも一部分をキャッシュするローカルキャッシュと,
前記リソースマネージャによって割り当てられた前記複数の別々のタスクのうちの1つ以上のタスクを実行するプロセッサと,
を備える,システム。」

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

<相違点2>
本件補正発明では,「前記リソースマネージャは、前記実行プラットフォームの前記複数のノードから独立し且つ分離されている」のに対して,引用発明では,DB管理機構が各ホストから独立しかつ分離されているとは特定してない点。

<相違点3>
本件補正発明では,「前記実行プラットフォームの前記複数のノードの各ノードは、前記コンピュータ使用クエリソース及び前記複数の共有ストレージデバイスから独立して」いるのに対して,引用発明では,各ホストがクライアント及び複数の物理ディスクから独立しているとは特定されていない点。

(4)当審の判断

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

イ 相違点2について
上記「(2)引用文献1に記載された事項及び引用発明」のEから,”DB管理機構とホスト11?14とは別の構成として分離されている”態様が読み取れ,この態様は,本願の図1に示される「リソースマネージャ102」と「実行プラットフォーム112」とが別の構成として分離されて図示されている態様と同様であることから,引用発明においても「DB管理機構」は「ホスト11?14」から「分離されている」といえ,リソースマネージャを「複数のノードから独立し且つ分離されている」とすることは,当業者が適宜なし得る程度の事項に過ぎないと認められる。

ウ 相違点3について
引用発明は,「ホスト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)引用文献1に記載された事項及び引用発明」のFから,”ホスト11?14が,それぞれ仮想ディスク41?44にアクセスする状態のまま,物理ディスクのみが,4つの物理ディスク51?54から,6つの物理ディスク51?56に追加されている”態様が読み取れる。
してみると,引用発明では,ストレージ仮想化を採用した場合は,ホスト11?14と関係なく物理ディスクを追加して最適化できるものであり,また,かかる物理ディスクの追加による最適化自体が,ホスト11?14にはトランスペアレントである,すなわち,ホスト11?14からは物理ディスクの追加が見えないものであって,さらに,マッピングによってアクセスする物理ディスクは動的に変更されるものと解されるから,引用発明においても,“ホスト11?14は複数の物理ディスクから独立している”といえる。
また,引用発明では,「DB管理機構」が,「データベースをアクセスするクライアントのクエリーを受け,処理をホスト11?14に分配」するものであるから,ホスト11?14はクライアントから直接クエリーを受け取るものではなく,DB管理機構によってクライアントから分離されており,“ホスト11?14はクエリーを発するクライアントから独立している”といえる。

よって,引用発明は,“ホスト11?14は複数の物理ディスクから独立している”,及び“ホスト11?14はクエリーを発するクライアントから独立している”といえ,まとめると,“ホスト11?14は複数の物理ディスク及びクエリーを発するクライアントから独立している”といえる。
ここで,上記「(3)対比 ア(ウ)(オ)」で検討したように,引用発明の「クエリーを発するクライアント」は“コンピュータ使用クエリソース”といえ,「ホスト11?14」は“実行プラットフォーム”であるといえ,「各ホスト」は,かかる実行プラットフォームの“各ノード”であるといえ,また,上記アで検討したように,引用発明の「物理ディスク」は“共有ストレージデバイス”といえるので,前述の“ホスト11?14は複数の物理ディスク及びクエリーを発するクライアントから独立している”こととは,「実行プラットフォームの各ノードが複数の共有ストレージデバイス及びコンピュータ使用クエリソースから独立している」ことに他ならない。
以上のことから,上記相違点3は,実質的な相違点であるとはいえない。

オ 小括

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

したがって,本件補正発明は,引用発明に基づいて,当業者が容易に発明をすることができたものであり,特許法第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つのデータベースクエリを受信することと、
前記少なくとも1つのデータベースクエリに応答して処理されるべき、前記データベースデータ内の前記複数のファイルのうちの1つ以上のファイルを特定することと、
前記複数のファイルのうちの前記1つ以上のファイルの処理を複数の別々のタスクに分割することと、
前記複数の別々のタスクのうちの異なるタスクを、実行プラットフォームの複数のノードのうちの異なるノードに割り当てることと、
を実行するように構成され、
前記実行プラットフォームは前記複数の別々のタスクを実行し、
前記実行プラットフォームの前記複数のノードの各ノードは、前記コンピュータ使用クエリソース及び前記複数の共有ストレージデバイスから独立しており、且つ、
前記データベースデータの少なくとも一部分をキャッシュするローカルキャッシュと、
前記リソースマネージャによって割り当てられた前記複数の別々のタスクのうちの1つ以上のタスクを実行するプロセッサと、
を備える、システム。」

2 原査定の拒絶の理由

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

引用文献1:特開2005-56077号公報

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

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

4 対比・判断

本願発明は,上記「第2 令和1年11月22日付けの手続補正についての補正却下の決定」の「2 補正の適否」で検討した本件補正発明から「前記リソースマネージャは、前記実行プラットフォームの前記複数のノードから独立し且つ分離されている」との発明特定事項を削除したものである。

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

第4 むすび

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

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

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

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