• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 特許、登録しない(前置又は当審拒絶理由) G06F
管理番号 1339986
審判番号 不服2016-11756  
総通号数 222 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2018-06-29 
種別 拒絶査定不服の審決 
審判請求日 2016-08-04 
確定日 2018-05-09 
事件の表示 特願2013-511265「ローカライズされたデータアフィニティシステム及びハイブリッド法」拒絶査定不服審判事件〔平成23年11月24日国際公開、WO2011/146409、平成25年 6月24日国内公表、特表2013-526749〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由 1.手続の経緯
本願は,2011年5月16日(パリ条約による優先権主張外国庁受理2011年4月8日,米国,2010年5月17日(以下,「優先日」という。),米国)を国際出願日とする出願であって,平成27年7月30日付けの拒絶理由通知に対して平成27年10月19日付けで意見書が提出されるとともに手続補正がなされたが,平成28年3月29日付けで拒絶査定がなされ,これに対して平成28年8月4日に拒絶査定不服審判の請求がなされるとともに手続補正がなされ,平成28年10月25日付けで前置報告がなされ,平成29年6月29日付けの当審の拒絶理由通知(以下,「当審拒絶理由通知」という。)に対して,平成29年10月3日付けで意見書が提出されるとともに手続補正がなされたものである。

2.本願発明
本願の請求項1に係る発明(以下,「本願発明」という。)は,平成29年10月3日付けの手続補正により補正された特許請求の範囲の請求項1に記載された事項により特定される次のとおりのものである。

「【請求項1】
複数のプロセッサ上でデータベース内の記録を処理する方法であって,前記複数のプロセッサは前記データベースに結合されており,前記複数のプロセッサは各々が少なくとも一つのプロセッサを含む複数のプロセッサセットにグループ化されており,
前記方法は,
前記複数のプロセッサのうちの少なくとも1つのプロセッサ上で,各々が少なくとも一つの記録を含む複数の記録セットのうちの1つに,各記録を,各記録を識別するための記録数を予め定められた前記複数のプロセッサセットの数で除した後の余りに基づいて関連付けるステップであり,各記録は,前記余りと同じ識別子を有する前記記録セットに関連付けられており,各記録セットは,前記複数のプロセッサセットのうちの一つのプロセッサセットに関連付けられている,当該関連付けるステップと,
各記録が,それに関連しているプロセッサセットに関してはローカルに常駐するように,前記関連付けられた記録セットに基づいて,プロセッサセットに前記記録をルーティングするステップと,
前記記録について1つ以上のデータベース動作を前記複数の関連付けられているプロセッサセットでローカルに実行するであり,前記1つ以上のデータベース動作は前記記録数を用いた探索処理を含む,当該ローカルに実行するステップと,
を備える方法。」
(当審注:「ローカルに実行するであり」は,「ローカルに実行するステップであり」の誤記と認められる。)

3.引用例
(1)引用例1に記載されている技術的事項及び引用発明
ア 本願の優先日前に頒布又は電気通信回線を通じて公衆に利用可能となり,当審拒絶理由通知において引用された,特開2003-6021号公報(2003年1月10日公開,以下,「引用例1」という。)には,関連する図面とともに,以下の技術的事項が記載されている。(当審注:下線は,参考のために当審で付与したものである。)

A 「【0016】
【発明の実施の形態】以下,本発明の実施の形態を,図面により詳細に説明する。図1は,本発明に係わるデータベースシステムの構成例を示すブロック図であり,図2は,図1におけるデータベースシステムのハードウェア構成例を示すブロック図,図3は,図1におけるハッシュ関数値格納位置対応表の登録内容例を示す説明図,図4は,図1におけるデータベース管理システムによる再配置処理中のデータベース処理要求の受付と実行動作の第1の例を示す説明図である。
【0017】図2に示すように,本例のデータベースシステムを構成するデータベース管理システム(図中,「DBMS」と記載)300は,それぞれCPU(Central Processing Unit)や入力装置および表示装置等を具備してコンピュータ機能を有する複数のユーザ端末300a?300cからの要求に基づき,データの検索,更新,削除,挿入(追加)等のデータベース処理を行うものであり,ネットワーク301で相互結合されたそれぞれコンピュータ機能を有するDBMS受付けノード400とDBMS実行ノード410a?410cにより構成される。
【0018】DBMS受付けノード400は,CPU401と主記憶装置(図中「主記憶」と記載)402およびHDD(Hard Disk Drive)等からなる外部記憶装置318を具備し,メモリ402に格納されたDBMS受付部プログラム(図中「DBMS受付部PGM」と記載)310aをCPU401が実行することにより,図1のDBMS受付部310における各処理部の機能を構成し,DBMSの受け付け処理を行う。
【0019】DBMS実行ノード410a?410cのそれぞれは,CPU411a?CPU411cと主記憶装置(図中「主記憶」と記載)412a?412cおよびHDD等からなる外部記憶装置325a?325cを具備し,主記憶装置412a?412cに格納されたDBMS実行部プログラム(図中「DBMS実行部PGM」と記載)320a?320cをCPU411a?411cが実行することにより,図1のDBMS実行部320a?320cにおける各処理部の機能を構成し,DBMSの実行処理を行う。」

B 「【0024】そして,実行先決定部314により,生成した処理手順をどのDBMS実行部で実行させるかを決定し,実行要求・結果受取部315により,決定したDBMS実行部に実行要求を行い,DBMS実行部より実行結果を受け取る。受け取った結果を,返却部316により,ユーザに返却する。
(途中省略)
【0027】DBMS実行部320a?320cは,DBMS受付部310より実行要求を受け取ると,検索,更新,削除,挿入等の指示に対応して,検索部321a?321c,更新部322a?322c,削除部323a?323c,挿入部324a?324cを起動し,それぞれの処理手順を実行し,その実行結果を,DBMS受付部310に返却する。」

C 「【0030】ここで,DBMS300におけるデータの分割動作について説明する。本例では,データを分割して格納する場合,格納対象データにハッシュ関数を適用し「0」から「9」の値を生成し,その値により格納先を振り分ける。
【0031】図3にその詳細を示すハッシュ関数格納位置対応表317は,ハッシュ関数値より格納位置を決定するための情報で,本例においては,データの分割を「最大10分割」までとし,各分割数時にハッシュ関数値のデータが何処に格納されるかを示す情報が格納される。
【0032】例えば,二つの記憶装置に分割して格納する場合,ハッシュ関数格納位置対応表317における2分割時の「領域0」と「領域1」の項目のように,ハッシュ関数値「0,4,6,7,9」となるデータを「領域0」に格納し,ハッシュ関数値「1,2,3,5,8」となるデータを「領域1」に格納する。」

D 「【0055】図5に示すデータベースシステムのデータベース管理システムにおけるDBMS受付部600とDBMS実行部610a?610cは,それぞれ,図1に示すデータベース管理システム300におけるDBMS受付部310とDBMS実行部320a?320cと実質的に同じ機能を有するものである。
【0056】DBMS受付部600に接続する記憶装置d630には,図3に示したハッシュ関数値格納位置対応表317と同じ内容のハッシュ関数値格納位置対応表635と,表毎に定義される表定義情報631が格納される。この表定義情報631には,表が何処に格納されているかを示す格納領域情報(図中,「格納領域」と記載)632と,表に領域を追加した場合に何処の領域を追加したかを示す追加領域情報(図中,「追加領域」と記載)633,および,再配置処理実行中を示す再配置処理中フラグ634を格納する。
【0057】DBMS実行部610a,DBMS実行部610bそれぞれに接続する各記憶装置A620a,記憶装置B620bには,在庫表である格納データ621,622がデータベースとして格納され,DBMS受付部600の指示により検索,更新,削除,挿入等の操作が実行される。
【0058】本例においては,最大分割数を10とし,分割に使用するハッシュ関数は,格納データ621,622における各商品の識別番号(商品コード)を,最大分割数「10」で割った余りの値としている。
【0059】図6に示すように,本例で取り扱うデータベースは,衣料関係の在庫表500であり,商品コード510,商品名520,色530,単価540,在庫量550の各項目からなる。
【0060】図6に示す在庫表500を図5のデータベースシステムに適用し,商品コード510における値を用いて,記憶装置A620a,記憶装置B620bに分割格納する場合,商品コード510における値に対して算出されるハッシュ関数値に,ハッシュ関数値格納位置対応表635,すなわち,図3に示すハッシュ関数値格納位置対応表317の2分割時の振分けを適用する。
【0061】この結果,ハッシュ関数値「0,9,4,6,7」となる値のデータは記憶装置A620aに格納し,ハッシュ関数値「1,8,5,2,3」となる値のデータは記憶装置B620bに格納する。また,記憶装置d630内における表定義情報631の格納領域情報632に,記憶装置A,記憶装置Bが定義されている。」

E 「【0068】また,図5におけるデータベース管理システムに挿入要求が行われると,DBMS受付部600は,上述した要求受付部601,解析部602,処理手順生成部603による各処理,および,実行先決定部604による,挿入先となる実行先の決定を行う。
【0069】この実行先決定部604による挿入実行先の決定処理の詳細は,図9に示すように,まず,図5の記憶装置d630の表定義情報631における再配置処理中フラグ634の値を参照し,再配置処理実行中か否かをチェックする(ステップS721)。
【0070】再配置中でない場合には,挿入するデータよりハッシュ関数値を計算し,ハッシュ関数値格納位置対応表635(図1および図3のハッシュ関数値格納位置対応表317)を参照して,ハッシュ関数値より,格納領域情報632に定義された領域から挿入実行先を選択する(ステップS722)。尚,ステップS721でのチェック結果が再配置処理実行中の場合の動作は後述する。
【0071】図5に示す例では,挿入データの商品コードの値を参照し,ハッシュ関数値を求める。ハッシュ関数値が「0,9,4,6,7」となる場合は記憶装置A620aを選択し,また,ハッシュ関数値が「1,8,5,2,3」となる場合は記憶装置B620bを選択する。
【0072】このようにして選択した挿入先に対して,DBMS受付部600は,実行要求・結果受取部605により,挿入実行要求を行い,その結果を受け取り,最後に受け取った結果を,返却部606により返却する。」

F 「 【図1】



G 「 【図2】



H 「 【図3】



I 「 【図5】



J 「 【図6】



イ ここで,上記引用例1に記載されている事項を検討する。

(ア)上記Aの段落【0017】の「図2に示すように,本例のデータベースシステムを構成するデータベース管理システム(図中,「DBMS」と記載)300は,・・・複数のユーザ端末300a?300cからの要求に基づき,データの検索,更新,削除,挿入(追加)等のデータベース処理を行うものであり,ネットワーク301で相互結合されたそれぞれコンピュータ機能を有するDBMS受付けノード400とDBMS実行ノード410a?410cにより構成される。」との記載,及び上記Gで引用した図2の記載から,
“DBMS受付けノード400とDBMS実行ノード410a?410cとがネットワーク301で相互結合されたデータベース管理システム300”において,“データの検索,更新,削除,挿入等のデータベース処理を行う”ことが読み取れるから,引用例1には,
“DBMS受付けノードと複数のDBMS実行ノードとがネットワークで相互結合されたデータベース管理システムにおいて,データの検索,更新,削除,挿入等のデータベース処理を行う方法”が記載されていると認められる。
また,上記Aの段落【0018】の「DBMS受付けノード400は,CPU401と主記憶装置(図中「主記憶」と記載)402およびHDD(Hard Disk Drive)等からなる外部記憶装置318を具備し,メモリ402に格納されたDBMS受付部プログラム(図中「DBMS受付部PGM」と記載)310aをCPU401が実行することにより,図1のDBMS受付部310における各処理部の機能を構成し,DBMSの受け付け処理を行う。」との記載,上記Fで引用した図1の記載,及び上記Gで引用した図2の記載から,
“DBMS受付けノード400”が,“CPU401を具備”することが読み取れ,
“DBMS受付けノード400”は,CPU401がDBMS受付部プログラム310aを実行することで,“DBMS受付部310”として機能するものであるから,図2の“DBMS受付けノード400”が図1の“DBMS受付部310”に対応する構成であることが読み取れる。
また,上記Aの段落【0019】の「DBMS実行ノード410a?410cのそれぞれは,CPU411a?CPU411cと主記憶装置(図中「主記憶」と記載)412a?412cおよびHDD等からなる外部記憶装置325a?325cを具備し,主記憶装置412a?412cに格納されたDBMS実行部プログラム(図中「DBMS実行部PGM」と記載)320a?320c(当審注:「320a?320c」は「420a?420c」の誤記と認められる。)をCPU411a?411cが実行することにより,図1のDBMS実行部320a?320cにおける各処理部の機能を構成し,DBMSの実行処理を行う。」との記載,上記Fで引用した図1の記載,及び上記Gで引用した図2の記載から,
“DBMS実行ノード410a?410c”は,それぞれ“CPU411a?CPU411c”を具備するとともに“外部記憶装置325a?325c”が接続されていることが読み取れ,
“DBMS実行ノード410a?410c”は,CPU411a?411cがDBMS実行部プログラム420a?420cを実行することで,“DBMS実行部320a?320c”として機能するものであるから,図2の“DBMS実行ノード410a?410c”が,図1のDBMS実行部320a?320c”に対応する構成であることが読み取れる。
また,上記Bの段落【0027】の「DBMS実行部320a?320cは,DBMS受付部310より実行要求を受け取ると,検索,更新,削除,挿入等の指示に対応して,検索部321a?321c,更新部322a?322c,削除部323a?323c,挿入部324a?324cを起動し,それぞれの処理手順を実行し」との記載から,
“DBMS実行部320a?320c”は,DBMS受付部310より実行要求を受け取ると,“検索,更新,削除,挿入等”の“処理手順を実行”することが読み取れる。

以上の検討から,引用例1には,
“CPUを具備するDBMS受付部と,CPUを具備するとともに外部記憶装置が接続される複数のDBMS実行部とがネットワークで相互結合されたデータベース管理システムにおいて,DBMS実行部がDBMS受付部より実行要求を受け取ると,DBMS実行部がデータの検索,更新,削除,挿入等のデータベース処理を行う方法”が記載されていると認められる。

(イ)上記Dの段落【0057】の「DBMS実行部610a,DBMS実行部610bそれぞれに接続する各記憶装置A620a,記憶装置B620bには,在庫表である格納データ621,622がデータベースとして格納され」との記載から,“DBMS実行部に接続される記憶装置A及び記憶装置Bには,在庫表がデータベースとして格納されて”いることが読み取れる。
ここで,上記Fで引用した図1の記載と,上記Iで引用した図5の記載を対比すると,図5の記憶装置A(620a)及び記憶装置B(620b)は,それぞれ,図1の外部記憶装置(325a)及び外部記憶装置(325b)に対応するものであることが読み取れる。
また,上記Dの段落【0058】の「本例においては,最大分割数を10とし,分割に使用するハッシュ関数は,格納データ621,622における各商品の識別番号(商品コード)を,最大分割数「10」で割った余りの値としている。」との記載,同じく上記Dの段落【0059】の「図6に示すように,本例で取り扱うデータベースは,衣料関係の在庫表500であり,商品コード510,商品名520,色530,単価540,在庫量550の各項目からなる。」との記載,及び上記Jで引用した図6の記載から,
“商品コード”は,“商品の識別番号”であって,データベースである在庫表における商品コード,商品名,色,単価,在庫量の各項目からなる“データ”を“識別”する“番号”であることが読み取れる。
してみれば,引用例1には,
“DBMS実行部に接続される外部記憶装置には,商品コードで識別されるデータがデータベースに格納されて”いることが記載されていると認められる。

(ウ)上記Eの段落【0068】の「図5におけるデータベース管理システムに挿入要求が行われると,DBMS受付部600は,上述した要求受付部601,解析部602,処理手順生成部603による各処理,および,実行先決定部604による,挿入先となる実行先の決定を行う。」との記載,同じく上記Eの段落【0070】の「挿入するデータよりハッシュ関数値を計算し,ハッシュ関数値格納位置対応表635(図1および図3のハッシュ関数値格納位置対応表317)を参照して,ハッシュ関数値より,格納領域情報632に定義された領域から挿入実行先を選択する(ステップS722)。」との記載,及び同じく上記Eの段落【0071】の「図5に示す例では,挿入データの商品コードの値を参照し,ハッシュ関数値を求める。」との記載から,
“データベース管理システムにデータの挿入要求が行われると,DBMS受付部は,挿入データの商品コードの値を参照してハッシュ関数値を計算し,ハッシュ関数値格納位置対応表を参照して,挿入実行先を決定すること”が読み取れる。

(エ)上記Dの段落【0058】の「本例においては,最大分割数を10とし,分割に使用するハッシュ関数は,格納データ621,622における各商品の識別番号(商品コード)を,最大分割数「10」で割った余りの値としている。」との記載から,
“ハッシュ関数は,商品コードを,最大分割数「10」で割った余りの値であること”が読み取れる。
また,上記Cの段落【0030】の「本例では,データを分割して格納する場合,格納対象データにハッシュ関数を適用し「0」から「9」の値を生成し,その値により格納先を振り分ける。」との記載,同じく上記Cの段落【0031】の「図3にその詳細を示すハッシュ関数格納位置対応表317は,ハッシュ関数値より格納位置を決定するための情報で,本例においては,データの分割を「最大10分割」までとし,各分割数時にハッシュ関数値のデータが何処に格納されるかを示す情報が格納される。」との記載から,
“データの最大分割数「10」は,データを分割して格納する場合の最大数であること”が読み取れる。
そうすると,引用例1には,“ハッシュ関数は,商品コードをデータを分割して格納する場合の最大数である最大分割数「10」で割った余りの値であること”が記載されていると認められる。

(オ)上記(ウ)及び(エ)の検討から,引用例1には,
“データベース管理システムにデータの挿入要求が行われると,DBMS受付部は,挿入データの商品コードの値を参照して,商品コードをデータを分割して格納する場合の最大数である最大分割数「10」で割った余りの値であるハッシュ関数値を計算し,ハッシュ関数値格納位置対応表を参照して,挿入実行先を決定すること”が記載されていると認められる。

(カ)上記Bの段落【0024】の「実行先決定部314により,生成した処理手順をどのDBMS実行部で実行させるかを決定し,実行要求・結果受取部315により,決定したDBMS実行部に実行要求を行い,DBMS実行部より実行結果を受け取る。」との記載,及び上記Eの段落【0072】の「このようにして選択した挿入先に対して,DBMS受付部600は,実行要求・結果受取部605により,挿入実行要求を行い,その結果を受け取り,最後に受け取った結果を,返却部606により返却する。」との記載から,
“DBMS受付部は,決定した挿入先のDBMS実行部に対して,挿入実行要求を行”うことが読み取れる。

(キ)上記Dの段落【0060】の「図6に示す在庫表500を図5のデータベースシステムに適用し,商品コード510における値を用いて,記憶装置A620a,記憶装置B620bに分割格納する場合,商品コード510における値に対して算出されるハッシュ関数値に,ハッシュ関数値格納位置対応表635,すなわち,図3に示すハッシュ関数値格納位置対応表317の2分割時の振分けを適用する。」との記載,同じく上記Dの段落【0061】の「この結果,ハッシュ関数値「0,9,4,6,7」となる値のデータは記憶装置A620aに格納し,ハッシュ関数値「1,8,5,2,3」となる値のデータは記憶装置B620bに格納する。」との記載,及び上記Hで引用した図3の記載から,
“同じハッシュ関数値を有するデータ群は同じ外部記憶装置に格納されること”が読み取れる。

ウ 以上の(ア)?(キ)の検討から,引用例1には,次のとおりの発明(以下,「引用発明」という。)が記載されていると認められる。

「CPUを具備するDBMS受付部と,CPUを具備するとともに外部記憶装置が接続される複数のDBMS実行部とがネットワークで相互結合されたデータベース管理システムにおいて,DBMS実行部がDBMS受付部より実行要求を受け取ると,DBMS実行部がデータの検索,更新,削除,挿入等のデータベース処理を行う方法であって,
DBMS実行部に接続される外部記憶装置には,商品コードで識別されるデータがデータベースに格納されており,
データベース管理システムにデータの挿入要求が行われると,DBMS受付部は,挿入データの商品コードの値を参照して,商品コードをデータを分割して格納する場合の最大数である最大分割数「10」で割った余りの値であるハッシュ関数値を計算し,ハッシュ関数値格納位置対応表を参照して,挿入実行先を決定し,
DBMS受付部は,決定した挿入先のDBMS実行部に対して,挿入実行要求を行い,
同じハッシュ関数値を有するデータ群は同じ外部記憶装置に格納される,
方法。」

(2)引用例2に記載されている技術的事項
ア 本願の優先日前に頒布又は電気通信回線を通じて公衆に利用可能となり,当審拒絶理由通知において引用された,特開平6-314299号公報(1994年11月8日公開,以下,「引用例2」という。)には,関連する図面とともに,以下の技術的事項が記載されている。(当審注:下線は,参考のために当審で付与したものである。)

K 「【0025】
【実施例】本発明に係るデータベース管理システムは,ネットワークに接続した複数のプロセッサにより,各プロセッサに接続された外部記憶装置に,表のデータを分割する。
【0026】本実施例に係るデータベース管理システムのハードウエアを図2ないし図4に示す。
【0027】図2において,本発明に係るデータベース管理システムの最小構成単位は,プロセッサ12,プロセッサ12に接続された外部記憶装置14からなり,これをノード15と呼ぶ。ノードを構成するプロセッサは1台だけでなく,密結合された複数プロセッサであることもある。また,プロセッサ12に接続される外部記憶装置14も複数台接続されることがある。ノードは,ネットワーク10に接続される。ノードを最小構成単位とする処理装置を複数ノードの集合としてみなしたものをクラスタ16とする。さらに,図3及び図4では,クラスタ16を複数まとめたものをクラスタグループ18とする。クラスタ16およびクラスタグループ18は,論理的なシステムの構成単位であり,特別なハードウエアを指し示すものではない。本発明に係るデータベース管理システムは,ノード15,クラスタ16およびクラスタグループを単位としたシステムの構成変更を可能とする。
【0028】次に,図2ないし図4で示したハードウエア構成により,本発明に係るデータベース管理システムのシステム構成を図5に示す。
【0029】図5において,本発明に係るデータベース管理システムの各処理部(以後サーバと呼ぶ)の構成と,サーバと資源の対応関連,ノード構成,通信路(ネットワーク)の位置付けを示す。フロントエンド・サーバ103(以下FESと略す)はアプリケーション・プログラム104(以下APと略す)からの問い合わせを受信し,処理手順を生成する。バックエンド・サーバ101(以下BESと略す)はFESからの処理手順を受信して,データベース102(以下DBと略す)をアクセスしてデータを取得しFESに渡す。ジャーナル・サーバ107(以下JSと略す)はFESやBESが発生するデータベースの変更履歴情報やトランザクションの状態情報を記録する。データディクショナリ・サーバ105(以下DDSと略す)はFESやBES(またはJS)が利用するメタ情報,例えば,リレーショナルデータベースにおける表定義情報や各表の列情報をデータディクショナリ(以後DDと略す)に保持する。図5における項番15は図2で示したノードである。また,項番10は,図2で示したネットワークであり,ノード間の通信を行うための通信バックボーンである。ノードには,そのノード固有のノード・アドレスが付与される。ノード・アドレスは,物理的なノード識別子であり,ネットワーク上ではこのノードアドレスを指定した通信を行う。」

L 「【0035】図9は本発明に係る表の分割情報に基づいて,表に対するデータの挿入処理がどのように実施されるかを示す。図9において,挿入処理解析処理40は図5におけるデータベース管理システムの構成において,AP104からSQLのINSERT文によってFES103に要求が渡され,処理を開始する。データの挿入対象となる表の分割格納場所を決定するために,図8に示した三つのテーブルを参照する。三つのテーブルの参照の際は,FES103からDDS105に対してテーブル情報の取得要求を送信し,受信したDDS105は要求された表の分割情報を検索した結果を要求元のFES103に返す。まず,クラスタグループ管理テーブル32を参照し,表の分割情報を取得する(ステップ410)。そこで,クラスタグループにおける分割情報があれば(ステップ412),データを挿入するべきクラスタグループおよびクラスタを決定する(ステップ414)。次に,クラスタグループにおける分割情報がないか,先に決定したクラスタ情報に基づいて,クラスタ管理テーブル34を参照し,表のクラスタにおける分割情報を取得する(ステップ416)。
【0036】そこで,クラスタにおける分割情報があれば(ステップ418),データを挿入するべきクラスタおよびノードを決定する(ステップ420)。次に,クラスタにおける分割情報がないか,先に決定したノード情報に基づいて,ノード管理テーブル36を参照し,表のノードにおける分割情報を取得する(ステップ422)。
【0037】そこで,ノードにおける分割情報があれば(ステップ424),データを挿入するべきノードを決定する(ステップ426)。さらに,ノードが決定されるとノード内のディスク分割情報を参照し,挿入すべきディスクを決定する(ステップ428)。こうして決定された表のデータの挿入場所(どのクラスタグループのどのクラスタのどのノードのどのディスク)に基づいて,データの挿入要求を該当するサーバ(図5におけるBES101)に送信する(ステップ430)。」

M 「 【図2】



N 「 【図5】



イ 上記K,Lの記載,及び上記M,Nに引用した図2及び図5の記載から,引用例2には,次の事項(以下,「引用例2記載事項」という。)が記載されていると認められる。

「ネットワークに接続した複数のプロセッサにより,各プロセッサに接続された外部記憶装置に,表のデータを分割するデータベース管理システムであって,データベース管理システムの最小構成単位であるノードが,複数のプロセッサと,当該複数のプロセッサに接続された外部記憶装置とからなるデータベース管理システムにおいて,表に対するデータの挿入処理が,ノード内のフロントエンド・サーバ(FES),バックエンド・サーバ(BES),及びデータディクショナリ・サーバ(DDS)を用いて実行されて表のデータの挿入場所(どのクラスタグループのどのクラスタのどのノードのどのディスク)が決定され,決定された表のデータの挿入場所に基づいて,データの挿入要求を該当するサーバに送信する」

4.対比
本願発明と引用発明とを対比する。

(1)引用発明の「データベース」「(データベース内の)データ」がそれぞれ本願発明の「データベース」「データベース内の記録」に相当するから,引用発明の「データベース処理を行う方法」が本願発明の「データベース内の記録を処理する方法」に相当する。
引用発明の「CPU」が本願発明の「プロセッサ」に相当し,引用発明の「データベース管理システム」の複数のDBMS実行部は,それぞれがCPUを具備しているから,引用発明の「データベース管理システム」は,「複数のCPU」を具備しているといえるので,引用発明の「データベース管理システムにおいて」DBMS実行部がデータベース処理を行うことは,“複数のCPU上で”データベース処理を行うことであるといえる。
してみれば,引用発明の「CPUを具備するDBMS受付部と,CPUを具備するとともに外部記憶装置が接続される複数のDBMS実行部とがネットワークで相互結合されたデータベース管理システムにおいて,DBMS実行部がDBMS受付部より実行要求を受け取ると,DBMS実行部がデータの検索,更新,削除,挿入等のデータベース処理を行う方法」が本願発明の「複数のプロセッサ上でデータベース内の記録を処理する方法」に相当する。

(2)引用発明の「複数のDBMS実行部」は,「外部記憶装置」に「接続され」ており,当該「外部記憶装置」には,「商品コードで識別されるデータがデータベースに格納されて」いることから,「複数のDBMS実行部」に含まれている「複数のCPU」は,「データベース」に「結合」されているといえる。
してみれば,引用発明と本願発明とは,「複数のプロセッサはデータベースに結合されて」いる点で一致する。

(3)引用発明の「DBMS実行部」は,「CPUを具備する」ものであるから,「少なくとも一つのCPU」を「含む」点で,本願発明の「少なくとも一つのプロセッサを含むプロセッサセット」と共通する。
また,引用発明の「DBMS実行部」は,DBMS受付部より実行要求を受け取ると,データの検索,更新,削除,挿入等のデータベース処理を行う「処理単位」であるから,引用発明の「DBMS実行部」と本願発明の「プロセッサセット」とは,データベース処理を実行する「処理単位」である点で共通する。
そして,引用発明の「複数のDBMS実行部」に含まれている「複数のCPU」は,各々のDBMS実行部に「分けられて」いるといえる。
してみれば,引用発明と本願発明とは,「複数のプロセッサは各々が少なくとも一つのプロセッサを含む複数の処理単位に分けられて」いる点で共通する。

(4)ア 上記(1)に記載したように,引用発明の「(データベース内の)データ」が本願発明の「記録」に相当するから,引用発明の,データベース内の「データ」を識別する「商品コード」が本願発明の「記録を識別するための記録数」に相当する。
イ 引用発明の「データの最大分割数「10」」は,「データを分割して格納する場合の最大数」であって,この数が予め定められたものであることは明らかであるから,引用発明の「データの最大分割数「10」」は,「予め定められた」「数」に他ならない。
また,データを「10」分割して格納するために外部記憶装置の数を「10」とする場合には,これに対応する「DBMS実行部」(処理単位)の数も「10」となり,引用発明の「データの最大分割数「10」」は,データを「10」分割して格納する場合の「複数の処理単位の数」であるということができる。
してみれば,引用発明の「データの最大分割数「10」」と本願発明の「予め定められた複数のプロセッサセットの数」とは,「予め定められた複数の処理単位の数」である点で共通する。
ウ 上記ア及びイの検討から,引用発明の「商品コードをデータを分割して格納する場合の最大数である最大分割数「10」で割った余りの値であるハッシュ関数値」と本願発明の「記録を識別するための記録数を予め定められた複数のプロセッサセットの数で除した後の余り」とは,「記録を識別するための記録数を予め定められた複数の処理単位の数で除した後の余り」である点で共通する。
エ 引用発明では,「データベース管理システムにデータの挿入要求が行われると,DBMS受付部は,挿入データの商品コードの値を参照して,商品コードをデータを分割して格納する場合の最大数である最大分割数「10」で割った余りの値であるハッシュ関数値を計算し,ハッシュ関数値格納位置対応表を参照して,挿入実行先を決定し」ているところ,挿入要求される「各」「データ」は新たにデータベースに挿入されるデータである点で本願発明の「各記録」に相当する。
また,引用発明の「同じハッシュ関数値を有するデータ群」は,ハッシュ関数値が「0」?「9」のいずれであるかによって分類される10個のデータ群のうちの一つである点で,本願発明の「各々が少なくとも一つの記録を含む複数の記録セットのうちの一つ」に相当し,引用発明では,挿入要求される「各」「データ」(各記録)を,「同じハッシュ関数値を有するデータ群は同じ外部記憶装置に格納され」るようにするために,ハッシュ関数値(記録を識別するための記録数を予め定められた複数の処理単位の数で除した後の余り)に基づいて,同じハッシュ関数値を有するデータ群(各々が少なくとも一つの記録を含む複数の記録セットのうちの一つ)に“関連付けている”ということができる。
オ 上記ア?エの検討から,引用発明と本願発明とは,「各々が少なくとも一つの記録を含む複数の記録セットのうちの1つに,各記録を,各記録を識別するための記録数を予め定められた前記複数の処理単位の数で除した後の余りに基づいて関連付けるステップ」を備える点で共通する。

(5)ア 上記(4)エにおける検討から,引用発明の「同じハッシュ関数値を有するデータ群」が本願発明の「記録セット」に相当し,また,同じく上記(4)エの検討から,引用発明において,「各」「データ」(各記録)は,「同じハッシュ関数値を有するデータ群」(記録セット)に“関連付けられている”といえるものである。
そして,引用発明のハッシュ関数値は,「余りの値」であり,引用発明の「同じハッシュ関数値を有するデータ群」は,「同じ余りを有するデータ群」であるといえるから,「余りと同じ識別子を有するデータ群」とみることができる。
そうすると,引用発明の「同じハッシュ関数値を有するデータ群」が本願発明の「余りと同じ識別子を有する記録セット」に相当するから,引用発明と本願発明とは,「各記録は,余りと同じ識別子を有する記録セットに関連付けられて」いる点で一致する。
イ また,引用発明では,「同じハッシュ関数値を有するデータ群は同じ外部記憶装置に格納され」るものであるから,「同じハッシュ関数値を有するデータ群」(記録セット)は,一つの外部記憶装置に“関連付けられている”といえ,その結果,一つの外部記憶装置に接続されている“一つのDBMS実行部”(一つの処理単位)に“関連付けられている”ということができる。
ウ 上記ア及びイの検討から,引用発明と本願発明とは,「各記録は,余りと同じ識別子を有する記録セットに関連付けられており,各記録セットは,複数の処理単位のうちの一つの処理単位に関連付けられている」点で共通する。

(6)上記(4)及び(5)の検討から,引用発明と本願発明とは,後記する点で相違するものの,「各々が少なくとも一つの記録を含む複数の記録セットのうちの1つに,各記録を,各記録を識別するための記録数を予め定められた複数の処理単位の数で除した後の余りに基づいて関連付けるステップであり,各記録は,前記余りと同じ識別子を有する前記記録セットに関連付けられており,各記録セットは,前記複数の処理単位のうちの一つの処理単位に関連付けられている,当該関連付けるステップ」を備える点で共通する。

(7)引用発明において,「DBMS受付部」が,「決定した挿入先のDBMS実行部に対して,挿入実行要求を行」う際には,まず,挿入要求される「各」「データ」(各記録)が,そのハッシュ関数値に応じて「同じハッシュ関数値を有するデータ群」(記録セット)に関連付けられ,この“関連付けられた記録セットに基づいて”,当該「関連付けられた記録セット」に関連付けられたDBMS実行部(処理単位)に「各」「データ」(各記録)を“分配”していることは明らかである。
また,引用発明の“挿入先として決定されたDBMS実行部”は,“挿入要求される「各」「データ」(各記録)に関連している”ものであるから,本願発明の「それに関連している処理単位」に対応する。
そして,挿入要求される「各」「データ」(各記録)が,当該データのハッシュ関数値に応じて,一つの外部記憶装置に格納されることは,当該外部記憶装置に接続されるDBMS実行部(処理単位)からみれば,自身の外部記憶装置のみに“ローカルに常駐”しているということができるから,引用発明において,“挿入要求される「各」「データ」(各記録)を,当該データのハッシュ関数値に応じて,一つの外部記憶装置に格納されるように分配すること”は,「各記録が,それに関連している処理単位に関してはローカルに常駐するように,前記記録を送信すること」である点で,本願発明の「各記録が,それに関連しているプロセッサセットに関してはローカルに常駐するように,前記記録をルーティングすること」と共通する。
してみれば,引用発明と本願発明とは,「各記録が,それに関連している処理単位に関してはローカルに常駐するように,前記関連付けられた記録セットに基づいて,処理単位に前記記録を送信するステップ」を備える点で共通する。

そうすると,本願発明と引用発明とは,
「複数のプロセッサ上でデータベース内の記録を処理する方法であって,前記複数のプロセッサは前記データベースに結合されており,前記複数のプロセッサは各々が少なくとも一つのプロセッサを含む複数の処理単位に分けられており,
前記方法は,
各々が少なくとも一つの記録を含む複数の記録セットのうちの1つに,各記録を,各記録を識別するための記録数を予め定められた前記複数の処理単位の数で除した後の余りに基づいて関連付けるステップであり,各記録は,前記余りと同じ識別子を有する前記記録セットに関連付けられており,各記録セットは,前記複数の処理単位のうちの一つの処理単位に関連付けられている,当該関連付けるステップと,
各記録が,それに関連している処理単位に関してはローカルに常駐するように,前記関連付けられた記録セットに基づいて,処理単位に前記記録を送信するステップと,
を備える方法。」

の点で一致し,次の点で相違する。

[相違点1]
データベース処理の“処理単位”が,
本願発明では,“複数のプロセッサ”が“グループ化”された“プロセッサセット”であるのに対して,
引用発明では,DBMS実行部である点。

[相違点2]
“複数の記録セットのうちの1つに,各記録を関連付けるステップ”が,
本願発明では,グループ化されたプロセッサセットに含まれる「複数のプロセッサのうちの少なくとも1つのプロセッサ上で」実行されているのに対して,
引用発明では,DBMS受付部で実行されている点。

[相違点3]
本願発明では,記録とプロセッサセットとの関連付け処理を実行したプロセッサセットが,記録と関連付けられたプロセッサセットに,記録を「ルーティング」しているのに対して,引用発明では,DBMS受付部が,データと関連付けられたDBMS実行部に,データを「分配」している点。

[相違点4]
本願発明では,「記録について1つ以上のデータベース動作を複数の関連付けられているプロセッサセットでローカルに実行するステップであり,前記1つ以上のデータベース動作は記録数を用いた探索処理を含む,当該ローカルに実行するステップ」を備えているのに対して,
引用発明は,そのようなステップを備えていない点。

5.当審の判断
上記相違点について検討する。

[相違点1]?[相違点3]について
例えば,上記「3.引用例」の「(2)引用例2に記載されている技術的事項」で引用した引用例2に「ネットワークに接続した複数のプロセッサにより,各プロセッサに接続された外部記憶装置に,表のデータを分割するデータベース管理システムであって,データベース管理システムの最小構成単位であるノードが,複数のプロセッサと,当該複数のプロセッサに接続された外部記憶装置とからなるデータベース管理システムにおいて,表に対するデータの挿入処理が,ノード内のフロントエンド・サーバ(FES),バックエンド・サーバ(BES),及びデータディクショナリ・サーバ(DDS)を用いて実行されて表のデータの挿入場所(どのクラスタグループのどのクラスタのどのノードのどのディスク)が決定され,決定された表のデータの挿入場所に基づいて,データの挿入要求を該当するサーバに送信する」との事項(引用例2記載事項)が記載されているように,
データベース管理システムのプロセッサを,各々が“複数のプロセッサ”を含む最小の“処理単位”であるノードに“グループ化”し,当該ノードのいずれかにおいて,データベースに対するデータの挿入先の決定処理を実行させ,また,当該決定処理によって決定されたデータの挿入場所(どのクラスタグループのどのクラスタのどのノードのどのディスク)に基づいて,データの挿入要求を該当するノードのサーバに送信することは,本願の優先日前に,当該技術分野における周知技術であったと認められる。
そして,引用発明と上記周知技術とは,ともにデータベース管理システムに関する技術である点で共通していることから,引用発明のデータベース管理システムに,当該技術分野における上記周知技術を適用して,
データベース処理の“処理単位”を,“複数のプロセッサ”が“グループ化”された“ノード(プロセッサセット)”で構成し,当該ノード(プロセッサセット)を構成する「複数のプロセッサのうちの少なくとも1つのプロセッサ上で」,挿入先の決定処理,すなわち,“複数の記録セットのうちの1つに,各記録を関連付けるステップ”を実行させ,当該関連付け処理を実行したノード(プロセッサセット)から,挿入先のノード(プロセッサセット)にデータ(記録)を“ルーティング”するように構成すること,すなわち,上記相違点1?相違点3に係る構成とすることは,当業者が容易に想到し得たことである。

[相違点4]について
上記「3.引用例」の「(2)引用例2に記載されている技術的事項」で引用した引用例2に「ネットワークに接続した複数のプロセッサにより,各プロセッサに接続された外部記憶装置に,表のデータを分割するデータベース管理システムであって,データベース管理システムの最小構成単位であるノードが,複数のプロセッサと,当該複数のプロセッサに接続された外部記憶装置とからなるデータベース管理システムにおいて,表に対するデータの挿入処理が,ノード内のフロントエンド・サーバ(FES),バックエンド・サーバ(BES),及びデータディクショナリ・サーバ(DDS)を用いて実行されて表のデータの挿入場所(どのクラスタグループのどのクラスタのどのノードのどのディスク)が決定され,決定された表のデータの挿入場所に基づいて,データの挿入要求を該当するサーバに送信する」との事項(引用例2記載事項)が記載されているように,複数のプロセッサが,ノード(プロセッサセット)にグループ化されてデータベースに結合されたデータベース管理システムにおいて,表に対するデータの挿入処理のような「データベース動作」を実行する際に,挿入場所の決定処理,及び実際のデータ挿入処理を各ノード(プロセッサセット)で“ローカルに”実行するように構成することは周知技術である。
そして,引用発明は,データの挿入処理において,挿入データを識別する商品コード(データの識別子)に基づいて決定される挿入実行先のDBMS実行部(プロセッサセット)に対して挿入実行要求を行い,挿入実行先のDBMS実行部(プロセッサセット)において挿入処理をローカルに実行しているものであるところ,引用発明のデータベース管理システムにおいて,データの識別子を用いた探索処理を実行する際に,上記周知技術を適用して,複数のノード(プロセッサセット)のうちのいずれかのノード(プロセッサセット)においてデータの識別子に基づいた探索処理実行先の決定処理をローカルに実行し,決定された探索処理実行先のノード(プロセッサセット)に対して探索実行要求を行い,当該探索実行要求を受けたノード(プロセッサセット)が識別子を用いた探索処理をローカルに実行するように構成すること,すなわち,上記相違点4に係る構成とすることは,当業者が容易に想到し得たことである。

そして,本願発明の作用効果も,引用発明及び周知技術から当業者が予測できる範囲のものである。

したがって,本願発明は,引用発明及び周知技術に基づいて,当業者が容易に発明をすることができたものである。

6.審判請求人の主張について
審判請求人は,平成29年10月3日付けの意見書において,
「これに対し,引用発明のDBMS実行部の数は,拒絶理由通知書でもご認定いただいていますように,表データの分割数が決められたときにはじめて定まるものです。具体的に,引用発明は,記憶装置が追加されるごとに分割数を増やしていくという構成になっていますが(引用文献1の段落0033,0034,図3等を参照),この構成は,新たな記憶装置の追加に伴う際に生じる種々の問題を解決することを課題とする(段落0013)引用発明においては重要な前提条件です。分割数が決められたときにはじめて定められるべきDBMS実行部の数をはじめから10に固定しておくことを,引用発明は全く想定していません。このような引用発明に接した当業者が上記相違点に係る要件を容易に着想し得るとは到底思えません。」
と主張している。
しかしながら,上記「4.対比」の(4)イにおいて判断したように,引用発明の「データの最大分割数「10」」は本願発明の「予め定められた複数のプロセッサセットの数」に相当するといえるものであって,審判請求人の意見書における上記主張は,請求項の記載に基づくものとはいえない。
したがって,審判請求人の上記主張は,採用することができない。

7.むすび
以上のとおり,本願発明は,引用発明及び周知技術に基づいて,当業者が容易に発明をすることができたものであるから,特許法第29条第2項の規定により特許を受けることができない。
したがって,本願は他の請求項について検討するまでもなく拒絶されるべきものである。

よって,結論のとおり審決する。
 
審理終結日 2017-11-21 
結審通知日 2017-11-28 
審決日 2017-12-13 
出願番号 特願2013-511265(P2013-511265)
審決分類 P 1 8・ 121- WZ (G06F)
最終処分 不成立  
前審関与審査官 漆原 孝治  
特許庁審判長 石井 茂和
特許庁審判官 佐久 聖子
須田 勝巳
発明の名称 ローカライズされたデータアフィニティシステム及びハイブリッド法  
代理人 山口 和弘  
代理人 野田 雅一  
代理人 酒巻 順一郎  
代理人 阿部 寛  
代理人 池田 成人  

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