【事件の表示】
　特願２０１２−２５０７３０「データ統合装置、データ統合方法およびデータ統合プログラム」拒絶査定不服審判事件〔平成２５年　２月２１日出願公開、特開２０１３−　３７７２６〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
【第１】経緯  
　本願は、平成２４年１１月１４日の出願であって、
　２００６年（平成１８年）１月１８日を国際出願日とする特願２００７−５５４７７１号の一部を、新たに特願２０１１−１７５３５２号として出願し、さらに、その一部を、新たな特許出願としたものであり、
　平成２５年７月２４日付けで拒絶理由が通知され、これに対し、平成２５年９月３０日付けで手続補正がなされたが、平成２５年１０月１６日付けで拒絶査定がなされ、これに対し平成２６年１月２２日に拒絶査定不服の審判が請求されたものである。
　
【第２】本願発明
　本願の請求項１〜５に係る各発明は，出願当初の特許請求の範囲，明細書及び図面の記載，及び平成２５年９月３０日付け手続補正書の特許請求の範囲の記載からみて，それぞれ，同手続補正書の特許請求の範囲の請求項１〜５に記載した事項により特定されるとおりのものと認められるところ，そのうち，請求項１に係る発明（以下「本願発明」という。）は，下記のとおりのものである。
　　　　　　記（本願発明）
　　【請求項１】
　異なる複数のデータベースそれぞれのデータ構造を定義したデータモデル（以下「物理モデル」という）と、利用側アプリケーションごとに定義された、前記複数のデータベースのデータに関する、当該利用側アプリケーションから参照されるデータ構造を定義したデータモデル（以下「論理モデル」という）と、前記論理モデルと前記物理モデルとの前記データ構造の対応関係を定義したマッピング定義情報を記憶した記憶部と、
　前記利用側アプリケーションから前記論理モデルに対する検索条件を受信し、該受信した検索条件を前記物理モデル、前記論理モデル、および前記マッピング定義情報から物理モデルに対する検索条件に変換する第一変換部と、
　前記第一変換部によって変換された前記物理モデルへの検索条件に一致するデータを前記複数のデータベースから収集する収集部と、
　前記収集した物理モデルのデータを前記物理モデル、前記論理モデル、及び前記マッピング定義情報に基づいて論理モデルのデータに変換する第二変換部と、
　前記第二変換部によって変換された論理モデルのデータを出力する出力部と、
　を備えたことを特徴とするデータ統合装置。
　
【第３】当審の判断  
 　 
［１］引用刊行物の記載 
　原査定の拒絶の理由に引用された、本願の原出願の国際出願日前に頒布された刊行物である、特開２００１−１０９７５８号公報（以下、「刊行物１」という。）には、図面とともに、以下の事項（下線は，注目箇所を示すために当審で施したものである。）が記載されている。 
　
　〈特許請求の範囲、請求項２，１５〉
【請求項２】
アプリケーションを実行する少なくとも一つのクライアント
クライアントからの問合せを受け付け、該問合せに対する結果を該クライアントに返す問合せ処理システム
マッピングが可能な仮想項目名を保持して前記アプリケーションに提供する仮想表
表を管理する仮想表管理部
前記問合せを解析する問合せ解析部
該問合せ解析部で解析された問合せから、該仮想表の定義を用いて前記データベースを参照するデータベース参照問合せを生成する問合せ生成部
該問合せ生成部で生成された前記データベースへの問合せ処理を実行する問合せ実行部
　
【請求項１５】
  前記仮想表管理部は、前記仮想表の定義を行うインタフェース手段を有する請求項２記載の問合せ処理システム。
　
〈発明の属する技術分野〉
【０００１】
【発明の属する技術分野】本発明は、データ処理に関し、
特に、複数データベースへの統合アクセスを実現する問合せ処理システム
　
〈従来の技術〉
【０００２】
【従来の技術】企業内情報システムの再編、企業間提携をはじめとする社会情勢の急速な変化に対応可能な情報システムが求められるようになっている。通常企業内には多数のデータベースが存在し、それぞれのデータベースは膨大なデータを多数のファイルやテーブルに保持している。これらのデータは長い時間をかけて様々な状況下で作成されてきたという経緯から一貫性が無く、（
１）別々のデータにアクセスするためには個別のアプリケーションを使用せざるを得ない、（２）新業務の開始、業務内容変更にあたっては新規アプリケーション開発、アプリケーション変更を行わなければならないという問題が指摘されていた。個別データにアクセスするために個別アプリケーションを利用するアプローチは、アプリケーションの数および種類が多くなることに起因する管理の複雑化、多数のアプリケーションの開発および維持にかかるコスト増加、そしてアプリケーション開発に必要となる時間分の業務遅延に起因する非効率化等の数多くの欠点を持つのは明らかである
【０００３】
アプリケーションから複数のデータベースを隠蔽する目的で仮想的なテーブル（以下、仮想表と呼ぶ）を作成して該仮想表上の項目から実在するデータベース（以下、実データベースと呼ぶ）上の項目へのマッピングを用いることによって、複数の実データベースへの透過アクセスを実現する方式
これらの方式はいずれも仮想的なスキーマもしくは表から実データベースへのマッピングを用いて、ユーザもしくはアプリケーションから実データベースを隠蔽し、論理的な統合を実現していた
　
〈解決するための手段〉
【００１０】 
 【課題を解決するための手段】前記第１の目的を達成するため、本発明では
アプリケーションからの問合せを受け付けるデータ処理システム内に、複数データベースへの
マッピングが可能な仮想表を設ける
仮想表上の項目は実データベース上の表の項目、もしくは実データベース上のビューの項目
にマッピングされ、アプリケーションからは仮想表上の項目を参照し、データベース上の項目に対してではなく仮想表上の項目に対して問合せを発行する
アプリケーションから複数データベースへのアクセスを隠蔽できる
　
〈発明の実施の形態〉
 【００１３】 
 【発明の実施の形態】図１に、本発明による
データ処理システム
アプリケーション１（１０２）を実行するクライアント１（１０１）、アプリケーション２（１０４）を実行するクライアント２（１０３）はネットワーク１２１を介してデータ処理システム１０５に接続される
データ処理システムは、ネットワーク１２２を介して実データベースを管理するサーバ（１２６、１２７）に接続されている
 　 
【００１４】今
アプリケーション２がデータ処理システム上の仮想表１１９上の項目を参照する問合せ処理要求１２６を発行したとする
本マッピングによる仮想表定義
マッピング記述例では仮想表ＶＴの項目である支店と貯蓄平均に対して、貯蓄平均表の項目をマッピングしたＶＭＡＰ１と、顧客貯蓄残高表から得た集計値をマッピングしたＶＭＡＰ２が定義されている
　
【００１６】図１に戻って、
データ処理システム１０５内のアプリケーションマネージャ１０６はアプリケーション２から発行された問合せをネットワーク経由のクライアントからの問合せ処理要求を受け付ける
受け付けられた問合せは問合せ解析部１０７で解析され、問合せ最適化部１０８に転送される。データ処理システムにおける問合せ処理の流れを図１および図１１および図１３を用いて説明する
問合せ最適化部では、まず受け付けた問合せを図１３の１３０１に示すような選言標準形（ｄｉｓｊｕｎｃｔｉｖｅ  ｎｏｒｍａｌ  ｆｏｒｍ）に変形する（１１０２）
【００１７】
データ処理システム内の問合せ最適化部１０８では問合せを選言標準形に変形した後、部分レプリカ管理部１１３で管理される部分レプリカ情報を利用して、部分問合せ単位でデータ処理システム内のストレージ１２０に格納された部分レプリカ１２５を利用できるか否かを判定する
　
【００２３】問合せ最適化部で、全ての部分問合せが部分レプリカを用いて処理可能であると判定された場合、すなわちステップ１１０３でＹｅｓが選択された場合には、問合せは部分レプリカに対して適用される（１１０７）。この場合、問合せは問合せ生成部１０９で部分レプリカを参照するように書き換えられ、問合せ実行部１１０がローカルデータベースアクセス部１１６を介してストレージ１２０に格納されている部分レプリカ１２５を用いて問合せ処理を行い、得られたデータを結果１２７としてアプリケーションマネージャ経由でクライアントに返して問合せ処理を終了する（１１０８）。
問合せ最適化部で、全ての部分問合せは部分レプリカを用いて処理できないと判定された場合、
一つの部分問合せも部分レプリカを用いて処理できない場合、すなわちステップ１１０４でＮｏが選択された場合には、問合せ全体を実データベースで処理する必要があるため、問合せ生成部で該部分問合せを実データベースを参照する問合せに書き換え
問合せ実行部が必要に応じて問合せの構文を構文変換部１１５を用いて変換し、リモートデータベースアクセス部１１１を介して実データベース（１１７、１１８）に対して問合せ処理を実行する（１１０５）。実データベースから得られたデータは、必要に応じてデータ型、値変換部１１４でデータをクライアントの要求する形式に変換し、結果１２７としてクライアントに返して問合せ処理を終了する（１１０８
【００２４】問合せ最適化部で部分レプリカの使用可否を判定した後、選言標準形に変形された問合せは問合せ生成部１０９に転送される。
問合せ生成部では
実データベースを参照する問合せに書き替える
【００２５】
実データベースに対する問合せは問合せ生成部で連言標準形
に変形される（１２０２
ステップ１２０３でＹｅｓが選択された場合には、該問合せは該実データベース内のデータのみを用いて処理できるため
問合せ生成部１０９は該選言問合せ処理を該実データベース１１７で実行するように処理をプッシュダウンする問合せ書き替えを行う
例えば、図７に示すような仮想表と実データベースが存在する環境を仮定する。図７に示す環境では、７２５に示される仮想表定義でサーバ１（７１１）に接続されているデータベース１（７１５）内のテーブルＴ１（７２３）と、サーバ１とは異なるサーバ２（７１２）に接続されているデータベース２（７１６）内のテーブルＴ２（７２４）の項目が仮想表７０２にマッピングされている。この時、図９に示した問合せ１（９０１）が投入されたとすると、２つの条件ｉｃ２＜＝１０とｉｃ４＞＝１０はそれぞれデータベース１、データベース２にプッシュダウンでき、各々のデータベースのデータをデータ処理システムに転送してから該２つの条件を適用するよりもネットワーク７１０を転送されるデータ量は遥かに小さくなる
【００２６】問合せ１と同様に問合せ３（９０３）も本発明の問合せ最適化が有効な例である。問合せ３は選言標準形のままでは条件をプッシュダウン可能かどうかは判定できないが、該問合せを連言標準形に変形すると９０４のようになる。まず、選言問合せ９０５はｉｃ２だけを参照する条件であり、仮想表定義７２５によればｉｃ２はｃ２にマッピングされるので、該選言問合せはデータベース１（７１５）にプッシュダウンできる。また、選言問合せ９０８はｉｃ４だけを参照する条件であり、前記仮想表定義によればｉｃ４はｃ５にマッピングされるされるため、該選言問合せはデータベース２にプッシュダウンされる。選言問合せ９０６および９０７はデータベース１もしくはデータベース２にプッシュダウンできないが、問合せが連言標準形に変換されているため、前記プッシュダウンされた９０５および９０８の適用によって削減されたデータに対してのみ、データ処理システム内で選言問合せ９０６および９０７を適用すればよく、データ転送量削減の効果が得られる。
　
【００３９】最後に図１の構文変換部１１５、およびデータ型、値変換部１１４について説明する。構文変換部はＤＢＭＳ毎に問合せ構文が異なる場合に必要となる構文変換を実現する。具体的には構文変換部はデータ処理システムで規定する標準構文と、各ＤＢＭＳの構文との対応表を保持し、変換が必要な構文は該対応表を用いて置き換えを行い、各ＤＢＭＳ向けに変換する。次にデータ型の変換に関しても構文変換部と同様に、データ処理システムのデータ型と各ＤＢＭＳのデータ型の対応表を管理し、実データベースからデータ処理システムにデータが転送される際に前記対応表を参照して適切な型変換プログラムモジュールを起動し型変換を実行する。・・・（以下略）
　
【００４１】型、値変換部における値の変換とは、例えば図７の結合処理においてｃ３、ｃ４が共に整数値で性別を表している項目であっても、ｃ３では男性が０、女性が１であるのに対して、ｃ４では逆に女性が０、男性が１であるように値の意味的な変換が必要となる場合に行う処理である。型変換の場合と同様に、値変換の場合も図１６に示す値変換対応表１６０１を値変換部が管理し、値変換プラグインモジュールを値変換時に適用することによって実現する。例えば、図７の例では、仮想表ＶＴ１上の項目ｉｃ３では男性が１、女性が０で表されており、ｃ３とは逆であるので、値の変換のためにプラグインモジュールＩｎｖｅｒｓｅＩｎｔ（）を用いることである。
　
　〈図面〉
　図１には「データ処理システム１０５」が、「仮想表１１９」、「仮想表管理部１１２」、「問合せ解析部１０７」、「問合せ生成部１０９」、「問合せ実行部１１０」及び「データ型、値変換部１１４」を有していることが示されている。 
　
　図７には「仮想表定義７２５」として， 
 「ＣＲＥＡＴＥ　ＭＡＰＰＩＮＧ　ＶＴ１（ｉｃ１　ＩＮＴ，　ｉｃ２　ＩＮＴ，　ｉｃ３　ＩＮＴ，　ｉｃ４　ＩＮＴ，　ｉｃ５　ＩＮＴ）　ＡＳ
 　ＳＥＬＥＣＴ　ｃ１，ｃ２，ｃ３，ｃ５，ｃ６ 
 　ＦＲＯＭ　Ｔ１，Ｔ２　ＷＨＥＲＥ　ｃ３＝ｃ４ 
 　ＭＡＰＮＡＭＥ　ＶＭＡＰ３；」 
 と記載されている。 （次ページに示す）
　図９には、「問合せ１　９０１」として、　
　「ＳＥＬＥＣＴ　ｉｃ１，ｉｃ４，ｉｃ５　ＦＲＯＭ　ＶＴ１　ＷＨＥＲＥ　ｉｃ２＜＝１０　ＡＮＤ　ｉｃ４＞＝１０；」と記載されている。
　
［２］刊行物１に記載された発明（以下，「引用発明」という。）の認定
　
　ア　刊行物１には、「
アプリケーションを実行する
問合せ処理システム
　「
問合せ処理システム
　アプリケーションに提供する仮想表と、
　前記仮想表の定義を行うインタフェース手段を有し、該仮想表を管理する仮想表管理部と、
　前記問合せを解析する問合せ解析部と、
　該問合せ解析部で解析された問合せから、仮想表の定義を用いて前記データベースを参照するデータベース参照問合せを生成する問合せ生成部と、該問合せ生成部で生成された前記データベースへの問合せ処理を実行する問合せ実行部とを有している（請求項２，請求項１５，図１等）。
　
　イ　実施の形態
　請求項２の上記「
問合せ処理システム
データ処理システム
　実施の形態として、特に、【0025】に記載される、
図７の環境において
図９の「問合せ１　９０１」が投入された時に「データ処理システム」が行う処理
　
　〈
図７の環境における図９の「問合せ１　９０１」の投入
　図７の環境は、図１において、データ処理システム（１０５）がデータ処理システム７０１とされ、仮想表（１１９）が仮想表７０２とされ、
　「
図７に示すような仮想表と実データベースが存在する環境
仮想表定義７２５（図７
仮想表７０２にマッピングされている
　そして、同環境において図９の「問合せ１　９０１」が投入されることは、「
アプリケーションから
仮想表上の項目を参照し、データベース上の項目に対してではなく仮想表上の項目に対して
アプリケーションから複数データベースへのアクセスを隠蔽できる
　
　当該処理は、【0016】，【0023】，【0025】，図１１，図１２によれば、
　図１１のステップ１１０４でＮｏで、「全ての部分問合せは部分レプリカを用いて処理できないと判定された場合」の処理であって、
　その処理は、概略、
　「
問合せ生成部
問合せ実行部
　その「実データベースに対する問合せ」（図１２）では、（「該問合せは該実データベース内のデータのみを用いて処理できる」と判断されて、）問合せ生成部１０９は選言問合せ処理を該実データベースで実行するように処理をプッシュダウンする問合せ書き替えを行い（１２０６、【0025】）、
　
問合せ実行部
　
　〈仮想表定義７２５（図７）〉
　「仮想表定義７２５（図７）」、すなわち、「ＣＲＥＡＴＥ　ＭＡＰＰＩＮＧ　ＶＴ１（ｉｃ１　ＩＮＴ，　ｉｃ２　ＩＮＴ，　ｉｃ３　ＩＮＴ，　ｉｃ４　ＩＮＴ，　ｉｃ５　ＩＮＴ）　ＡＳ　
　ＳＥＬＥＣＴ　ｃ１，ｃ２，ｃ３，ｃ５，ｃ６　
　ＦＲＯＭ　Ｔ１，Ｔ２　ＷＨＥＲＥ　ｃ３＝ｃ４　
　ＭＡＰＮＡＭＥ　ＶＭＡＰ３；」は、
　図２を参照した【0014】の「
仮想表定義
本マッピングによる仮想表定義
　マッピングを定義すると共に、マッピングによって仮想表を定義するものと理解される。
　すなわち、「仮想表定義７２５」は、
　
マッピング定義情報
マッピングによる仮想表の定義情報
　
マッピング定義情報
　マップ名（MAPNAME）がＶＭＡＰ３であるマッピングが、
　実データベース１のテーブルＴ１及び実データベース２のテーブルＴ２から表名が「ＶＴ１」である仮想表へのマッピングであって、
　仮想表「ＶＴ１」の項目「ｉｃ１」〜「ｉｃ５」（ＩＮＴ型）は、それぞれ、実データベース１のテーブルＴ１の項目「ｃ１」〜「ｃ３」及び実データベース２のテーブルＴ２の項目「ｃ４」〜「ｃ６」と対応するようにマッピングされること、を定義するとともに、
　
マッピングによる仮想表の定義情報
　（マップ名（MAPNAME）がＶＭＡＰ３というマッピングにより定義されるものであって、）
　表名が「ＶＴ１」、項目が「ｉｃ１」〜「ｉｃ５」（ＩＮＴ型）である仮想表（「仮想表７０２（図７）」）であること、を定義している
　と理解される。
　
　〈具体的処理〉
　以上のことと、
図９の「問合せ１　９０１
問合せ生成部１０９は該選言問合せ処理を該実データベース１１７で実行するように処理をプッシュダウンする問合せ書き替えを行う
この時、図９に示した問合せ１（９０１）が投入されたとすると、２つの条件ｉｃ２＜＝１０とｉｃ４＞＝１０はそれぞれデータベース１、データベース２にプッシュダウンでき、各々のデータベースのデータをデータ処理システムに転送してから該２つの条件を適用するよりもネットワーク７１０を転送されるデータ量は遥かに小さくなる
　
図７の環境において図９の「問合せ１　９０１」が投入された時の処理
　
　
アプリケーション
　
問合せ生成部
マッピングの定義情報
 　問合せ実行部の問合せ処理の実行によって実データベース１，２から得られたデータは、必要に応じてデータ型、値変換部１１４でデータをクライアントの要求する形式に変換し、結果１２７としてクライアントに返して問合せ処理を終了する。
　なお、「問合わせ１　９０１」だけでなく図９の「
問合わせ３　９０３
　
　ウ　引用発明
　以上のことを総合勘案すれば、引用発明（刊行物１記載された発明）として，下記の発明を認めることができる。
　
　　　　　　　記（引用発明）
ｐ　：アプリケーションを実行するクライアントからの問合せを受け付け、該問合せに対する結果を該クライアントに返す問合せ処理システム、特に、複数データベースヘの統合アクセスを実現する問合せ処理システム（データ処理システム）であって、
　データ処理システムは、
ｑ　：アプリケーションに提供する仮想表と、
ｒ　：前記仮想表の定義を行うインタフェース手段を有し、該仮想表を管理する仮想表管理部と、
ｓ　：前記問合せを解析する問合せ解析部と、
ｔ　：該問合せ解析部で解析された問合せから、仮想表の定義を用いて前記データベースを参照するデータベース参照問合せを生成する問合せ生成部と、
ｕ　：問合せ生成部で生成された前記データベースへの問合せ処理を実行する問合せ実行部と、
ｖ　：データ型、値変換部とを有し、
ｗ　：仮想表と実データベースが存在する図７の環境であって、仮想表定義７２５でサーバ１に接続されている実データベース１内のテーブルＴ１と、サーバ１とは異なるサーバ２に接続されている実データベース２内のテーブルＴ２の項目が仮想表７０２にマッピングされている環境において、
ｘ　：アプリケーションからは仮想表上の項目を参照し、データベース上の項目に対してではなく仮想表上の項目に対して、問い合わせ処理要求として「問合わせ１　９０１」を発行しこれにより、アプリケーションから複数データベースへのアクセスを隠蔽できるようになっており、
ｔ１：問合せ生成部は選言問合せ処理を該実データベースで実行するように処理をプッシュダウンする問合せ書き替えを行うものであり、
ｔ２：「問合せ１　９０１」：「ＳＥＬＥＣＴ　ｉｃ１，ｉｃ４，ｉｃ５　ＦＲＯＭ　ＶＴ１　ＷＨＥＲＥ　ｉｃ２＜＝１０　ＡＮＤ　ｉｃ４＞＝１０；」が投入されたとすると、
　問合せ生成部は、この「問合せ１　９０１」の条件「ｉｃ２＜＝１０」と「ｉｃ４＞＝１０」を、仮想表定義７２５によって定義されるマッピングの定義情報に従って、実データベース１のテーブルＴ１の項目ｃ２に対する「ｃ２＜＝１０」と実データベース２のテーブルＴ２の項目ｃ５に対する「ｃ５＞＝１０」にプッシュダウンし、
ｙ　：問合せ実行部の問合せ処理の実行によって実データベース１，２から得られたデータは、必要に応じてデータ型、値変換部１１４でデータをクライアントの要求する形式に変換し、結果１２７としてクライアントに返して問合せ処理を終了する問合せ処理システム。
　
ｗ１　：但し、仮想表定義７２５は、
  「ＣＲＥＡＴＥ　ＭＡＰＰＩＮＧ　ＶＴ１（ｉｃ１　ＩＮＴ，　ｉｃ２　ＩＮＴ，　ｉｃ３　ＩＮＴ，　ｉｃ４　ＩＮＴ，　ｉｃ５　ＩＮＴ）　ＡＳ
　ＳＥＬＥＣＴ　ｃ１，ｃ２，ｃ３，ｃ５，ｃ６　
　ＦＲＯＭ　Ｔ１，Ｔ２　ＷＨＥＲＥ　ｃ３＝ｃ４　
　ＭＡＰＮＡＭＥ　ＶＭＡＰ３；」であって
ｗ２：マッピング定義情報と、マッピングによる仮想表の定義情報とを含み、
　マッピング定義情報として、
　マップ名（MAPNAME）がＶＭＡＰ３であるマッピングが、
　実データベース１のテーブルＴ１及び実データベース２のテーブルＴ２から表名が「ＶＴ１」である仮想表へのマッピングであって、
　仮想表「ＶＴ１」の項目「ｉｃ１」〜「ｉｃ５」（ＩＮＴ型）は、それぞれ、実データベース１のテーブルＴ１の項目「ｃ１」〜「ｃ３」及び実データベース２のテーブルＴ２の項目「ｃ４」〜「ｃ６」と対応するようにマッピングされること、を定義するとともに、
　マッピングによる仮想表の定義情報として、
　（マップ名（MAPNAME）がＶＭＡＰ３というマッピングにより定義されるものであって、）
　表名が「ＶＴ１」、項目が「ｉｃ１」〜「ｉｃ５」（ＩＮＴ型）である仮想表（「仮想表７０２（図７）」）であること、を定義するものである。
　
［３］本願発明と引用発明との対比（対応関係）  
　
　（１）本願発明（構成要件の分説）
　
　本願発明は，以下のように要件Ａ〜Ｇに分説することができる。
　　　　　本願発明（分説）
Ａ　異なる複数のデータベースそれぞれのデータ構造を定義したデータモデル（以下「物理モデル」という）と、利用側アプリケーションごとに定義された、前記複数のデータベースのデータに関する、当該利用側アプリケーションから参照されるデータ構造を定義したデータモデル（以下「論理モデル」という）と、前記論理モデルと前記物理モデルとの前記データ構造の対応関係を定義したマッピング定義情報を記憶した記憶部と、
Ｂ　前記利用側アプリケーションから前記論理モデルに対する検索条件を受信し、該受信した検索条件を前記物理モデル、前記論理モデル、および前記マッピング定義情報から物理モデルに対する検索条件に変換する第一変換部と、
Ｃ　前記第一変換部によって変換された前記物理モデルへの検索条件に一致するデータを前記複数のデータベースから収集する収集部と、
Ｄ　前記収集した物理モデルのデータを前記物理モデル、前記論理モデル、及び前記マッピング定義情報に基づいて論理モデルのデータに変換する第二変換部と、
Ｅ　前記第二変換部によって変換された論理モデルのデータを出力する出力部と、
　を備えたことを特徴とする
Ｆ　データ統合装置。
　
　（２）本願発明と引用発明との対比（対応関係） 
　
　本願発明の各構成要件について，引用発明と対応する。
　
　対比の前に、本願発明の「
データベース
データ構造を定義したデータモデル
物理
論理
　・請求項１の従属項である請求項２には、「前記物理
モデル
データ構造に基づいて定義される表の名前（以下「表名」という）
項目を示すデータ列の名前（以下「列名」という）と当該項目のデータ値の型（以下「データ型」という）から構成されるデータモデル
モデル
表の構造として、表名ごとに列名とデータ型から構成されるデータモデル
　明細書には、「図３は、
表の構造
スキーマ
表名＝表Ａ
各列の列名
型
制約
物理モデル１１１の表および列
論理モデル１１２の表および列
　・上記「表名」のような「（どの表か）表を識別する情報」と、例えば、その表の列項目名（列名）や型のような「その表を構成する列の属性情報」が分かれば特定の表が特定の構造であることがわかる、つまり、「表を識別する情報」と「その表を構成する列の属性情報」からなるデータは、「
表のデータ構造を定義した
　からすれば、
　本願発明の上記「
データベース
　上記「
データ構造を定義したデータモデル
　
　そして、「
物理
論理
表の実体
仮想的な表
実体の表
仮想表
　
　また、「異なる複数のデータベースそれぞれのデータ構造を定義したデータモデル（以下「物理モデル」という）」（を記憶した記憶部）は、
　・その「それぞれのデータ構造を定義したデータモデル」との記載ぶり、
　・明細書の【0037】〜【0044】中の「物理モデル１１１」、特に【0044】「物理モデル１１１の各テーブル２４１〜２４３」（【0044】）と図２−１に照らせば、
　１つの「データモデル」が、異なる複数のデータベースのデータ構造の定義情報（上記アから、「表を識別する情報とその表を構成する列の属性情報とからなる型データ」と解される。）を有していて、これを記憶部に記憶することを特定するものと解される。
　つまり、「異なる複数のデータベースそれぞれのデータ構造を定義したデータモデル（以下「物理モデル」という）」は、「異なる複数のデータベースそれぞれのデータ構造を定義した
１の
　
　さらに、「該受信した検索条件を前記物理モデル、前記論理モデル、および前記マッピング定義情報から物理モデルに対する検索条件に変換する第一変換部」については、次のように解される。
　すなわち、「第一変換部」についての上記記載は、その字義からすれば、検索条件の変換は、「前記物理モデル」と「前記論理モデル」と「前記マッピング定義情報」とから行われると読めるが、
　「マッピング定義情報」は、そもそも、要件Ａで「前記論理モデルと前記物理モデルとの前記データ構造の対応関係を定義した」ものであって、「物理モデル」のデータ構造と「論理モデル」のデータ構造（情報）を含んでいるものであるから、「マッピング定義情報」に基づいて行われれば、自ずと、「物理モデル」と「論理モデル」に基づいて行われることにもなっていると解される。
　また、このことは、【0061】に「 図５は、統合エンジンのアーキテクチャ（マッピングの定義）を示す説明図である。マッピングの定義は、たとえば図１に示したメタ情報整備機能１１７のオペーレーションとして実行される。
マッピングの定義は、定義済みの物理モデルに基づいて、論理モデルを定義するものである
マッピングの定義
物理モデル
　明細書の段落【0079】に「 図１２のフローチャートにおいて、まず、論理モデルに対する検索式とマッピング定義によって、物理モデルの検索式を作成する（ステップＳ１２０１）。」とあることからも、理解されることである。
　
　以上を踏まえて、以下、対比する。
　
　ア　要件Ａについて
　
　ア-１　要件Ａの「異なる複数のデータベースそれぞれのデータ構造を定義したデータモデル（以下「物理モデル」という）」（を記憶した記憶部を備える）について
　
　引用発明の「問合せ処理システム（データ処理システム）」は、
  ｑ「アプリケーションに提供する仮想表」と、ｒ「前記仮想表の定義を行うインタフェース手段を有し、該仮想表を管理する仮想表管理部」を有するものであるから、ｗ、ｗ１、ｗ２の「仮想表定義７２５」を
作成している
　その作成には、前提として、「問合せ処理システム」が、「実データベース１のテーブルＴ１」を識別できることと、「実データベース１のテーブルＴ１」が「ｃ１」、「ｃ２」，「ｃ３」という項目名の列を有していることを知識として有していることが必要であることは明らかである。したがって、上記「問合せ処理システム」が、「実データベース１のテーブルＴ１」についての「表を識別する情報とその表を構成する列の属性情報」を知識として有していることは明らかである。そして、これらを合わせた情報が表の構造を定義するデータモデルを示していることは、当業者に明らかである。そして、知識として有しているのであるから、これを（当然に備えているといえる）記憶部に記憶していると普通に想定される。
　すなわち、引用発明は、データベース（Ｔ１）のデータ構造を定義したデータモデル（物理モデル）を記憶部に記憶しているということができる。
　このことは、「実データベース２のテーブルＴ２」についても同様であり、かつ、テーブルＴ１とテーブルＴ２は実体のある異なる複数の表であることは明らかであるから、引用発明は、データベース（Ｔ１）とは異なるデータベース（Ｔ２）のデータ構造を定義したデータモデル（物理モデル）も記憶部に記憶しているということができる。
　もっとも、それらデータモデルは、実体の表ごとに
別異
　つまり、引用発明は、異なる複数のデータベースそれぞれのデータ構造を定義した、それぞれ
別異
　そうすると、本願発明と引用発明は、
　「異なる複数のデータベースそれぞれのデータ構造を定義した
（１つ又はそれぞれ別異の）データモデル（以下「物理モデル」という）
　記憶部に記憶する上記
（１つ又はそれぞれ別異の）データモデル（以下「物理モデル」という）
　本願発明では、１つのデータモデル（物理モデル）であるのに対して、
　引用発明では、それぞれ別異のデータモデル（物理モデル）である点で相違する。
　
　ア-２　要件Ａの「利用側アプリケーションごとに定義された、前記複数のデータベースのデータに関する、当該利用側アプリケーションから参照されるデータ構造を定義したデータモデル（以下「論理モデル」という）」（を記憶した記憶部を備える）について
　
　上記Ａのデータモデル（論理モデル）が、「利用側アプリケーションごとに定義された、前記複数の「表」のデータに関する、当該利用側アプリケーションから参照される「表を識別する情報とその表を構成する列の属性情報とからなる仮想表のデータモデル」（を記憶した記憶部）を含むと解されるのは上記のとおりである。
　
　引用発明の「問合せ処理システム（データ処理システム）」は、
  ｑ「アプリケーションに提供する仮想表」を有し、ｗ「仮想表と実データベースが存在する図７の環境であって、仮想表定義７２５でサーバ１に接続されている実データベース１内のテーブルＴ１と、サーバ１とは異なるサーバ２に接続されている実データベース２内のテーブルＴ２の項目が仮想表７０２にマッピングされている環境」であることから、当然、ｗ１、ｗ２の「仮想表定義７２５」を記憶する記憶部を備えているといえるところ、
　「仮想表定義７２５」は、「
マッピングによる仮想表の定義情報
　表名が「ＶＴ１」、項目が「ｉｃ１」〜「ｉｃ５」（ＩＮＴ型）である仮想表（「仮想表７０２（図７）」）であること、を定義するもの」を
含んで
　すなわち、その「
ＶＴ１
項目「ｉｃ１」〜「ｉｃ５」（ＩＮＴ型）
　
　また、引用発明において、ｘ「
アプリケーション
アプリケーション
ＶＴ１」、項目「ｉｃ１」〜「ｉｃ５」（ＩＮＴ型）
　また、それらは、「実データベース１のテーブルＴ１の項目「ｃ１」〜「ｃ３」及び実データベース２のテーブルＴ２の項目「ｃ４」〜「ｃ６」」に関するものであるから、要件Ａの「前記複数のデータベース（表）のデータに関する」ものである。
　
　そうすると、引用発明も、要件Ａの上記「前記複数のデータベースのデータに関する、利用側アプリケーションから参照されるデータ構造を定義したデータモデル（以下「論理モデル」という）」「を記憶した記憶部を備える」といえ、この点において、本願発明と相違しない。
　もっとも、引用発明では、「利用側アプリケーションごとに定義された、」とはしておらず、この点、本願発明とは相違する。
　
　ア-３　「前記論理モデルと前記物理モデルとの前記データ構造の対応関係を定義したマッピング定義情報を記憶した記憶部と」（を備える）について
　
　要件Ａの「前記論理モデルと前記物理モデルとの前記データ構造の対応関係を定義したマッピング定義情報」は、
　明細書の【0100】の「物理モデル１１１の
表および列
表および列
物理
論理
　「実体の表のデータモデルの表および列から、これに対応する仮想表のデータモデルの表及び列への対応関係を定義する」情報とを含むと解されるところ、
　引用発明のｗ１の「仮想表定義７２５」が含むｗ２の
マッピング定義情報
　したがって、引用発明も、要件Ａの上記「前記論理モデルと前記物理モデルとの前記データ構造の対応関係を定義したマッピング定義情報」「を記憶した記憶部を備える」といえ、この点において、本願発明と相違しない。
　
　ア-４　まとめ（要件Ａ）
　以上によれば、
　本願発明と引用発明とは、
　異なる複数のデータベースそれぞれのデータ構造を定義した
１つ又はそれぞれ別異のデータモデル（以下「物理モデル」という）
利用側アプリケーションから参照されるデータ構造を定義したデータモデル（以下「論理モデル」という）
　記憶部に記憶する上記
１つ又はそれぞれ別異のデータモデル（以下「物理モデル」という）
　本願発明では、１つのデータモデル（物理モデル）であるのに対して、
　引用発明では、それぞれ別異のデータモデル（物理モデル）である点、
　および、　
　上記
利用側アプリケーションから参照されるデータ構造を定義したデータモデル（以下「論理モデル」という）
　本願発明では、利用側アプリケーションごとに定義されたデータモデル、とするのに対して、
　引用発明では、そうとはしていない点
で相違する。
　
　イ　要件Ｂについて
　要件Ｂ「前記利用側アプリケーションから前記論理モデルに対する検索条件を受信し、該受信した検索条件を前記物理モデル、前記論理モデル、および前記マッピング定義情報から物理モデルに対する検索条件に変換する第一変換部と、」
　
　イ-１　「前記利用側アプリケーションから前記論理モデルに対する検索条件を受信し」とする構成について
　
　引用発明のｘ「
アプリケーション
　ｔ２の「問合せ１　９０１」：「ＳＥＬＥＣＴ　ｉｃ１，ｉｃ４，ｉｃ５　ＦＲＯＭ　ＶＴ１　ＷＨ
ＥＲＥ　ｉｃ２＜＝１０　ＡＮＤ　ｉｃ４＞＝１０；」が投入される」構成は、
　上記イ-１の「前記利用側アプリケーションから前記論理モデルに対する検索条件を受信し」に相当する構成ということができることは、これまでの検討から明らかである。
　
　イ-２　「該受信した検索条件を前記物理モデル、前記論理モデル、および前記マッピング定義情報から物理モデルに対する検索条件に変換する第一変換部と、」について
　
　引用発明のｔ１「問合せ生成部は選言問合せ処理を該実データベースで実行するように処理をプッシュダウンする問合せ書き替えを行うものであり」、ｔ２の「問合せ生成部は、この「問合せ１　９０１」の条件「ｉｃ２＜＝１０」と「ｉｃ４＞＝１０」を、
仮想表定義７２５によって定義されるマッピングの定義情報に従って、実データベース１のテーブルＴ１の項目ｃ２に対する「ｃ２＜＝１０」と実データベース２のテーブルＴ２の項目ｃ５に対する「ｃ５＞＝１０」にプッシュダウンし
　上記イ-２の「該受信した検索条件を」「前記マッピング定義情報から」実体の表の「表を識別する情報」と「その表を構成する列の属性情報」からなるデータモデル（物理モデル）に対する検索条件に変換する」ものであるといえるところ、その変換は、上記のとおり、自ずと「物理モデル」と「論理モデル」に基づいて行われることにもなっていると解される。
　そうすると、引用発明は、上記イ-２の「該受信した検索条件を前記物理モデル、前記論理モデル、および前記マッピング定義情報から物理モデルに対する検索条件に変換する第一変換部」に相当する構成を備えている。
　
　イ-３　まとめ
　以上によれば、要件Ｂにおいて、引用発明は本願発明と相違しない。
　
　ウ　要件Ｃ、Ｄ，Ｅついて
　要件Ｃ「前記第一変換部によって変換された前記物理モデルへの検索条件に一致するデータを前記複数のデータベースから収集する収集部と、」
　要件Ｄ「前記収集した物理モデルのデータを前記物理モデル、前記論理モデル、及び前記マッピング定義情報に基づいて論理モデルのデータに変換する第二変換部と、」
　要件Ｅ「前記第二変換部によって変換された論理モデルのデータを出力する出力部と、
　を備えた」について
　
　引用発明のｙの「問合せ実行部の問合せ処理の実行によって実データベース１，２から」「データ」を得る構成は、上記要件Ｃ「前記第一変換部・・・収集部」に相当する構成ということができる。
　引用発明のｙの上記により「得られたデータは、必要に応じてデータ型、値変換部１１４でデータをクライアントの要求する形式に変換」する構成は、「前記収集した物理モデルのデータを」「前記
マッピング定義情報に基づいて
前記物理モデル、前記論理モデル、及び前記マッピング定義情報に基づいて
　引用発明のｙの、「変換」したデータを「結果１２７としてクライアントに返」す構成は、要件Ｅ「前記第二変換部によって変換された論理モデルのデータを出力する出力部」に相当する構成ということができる。
　以上、要件Ｃ，Ｄ，Ｅにおいて、本願発明と引用発明とは相違しない。
　
　エ　要件Ｆ「データ統合装置」について
　引用発明の「問合せ処理システム（データ処理システム）」が、「データ統合装置」といい得ることは、ｐの「複数データベースヘの
統合アクセスを実現する
　
［４］一致点，相違点 
　以上の対比結果によれば，本願発明と引用発明との一致点，相違点は次のとおりであることが認められる。 
　
　［一致点］ 
Ａ’異なる複数のデータベースそれぞれのデータ構造を定義した
（１つ又はそれぞれ別異の）データモデル（以下「物理モデル」という）
利用側アプリケーションから参照されるデータ構造を定義したデータモデル（以下「論理モデル」という）
Ｂ　前記利用側アプリケーションから前記論理モデルに対する検索条件を受信し、該受信した検索条件を前記物理モデル、前記論理モデル、および前記マッピング定義情報から物理モデルに対する検索条件に変換する第一変換部と、
Ｃ　前記第一変換部によって変換された前記物理モデルへの検索条件に一致するデータを前記複数のデータベースから収集する収集部と、
Ｄ　前記収集した物理モデルのデータを前記物理モデル、前記論理モデル、及び前記マッピング定義情報に基づいて論理モデルのデータに変換する第二変換部と、
Ｅ　前記第二変換部によって変換された論理モデルのデータを出力する出力部と、
　を備えたことを特徴とする
Ｆ　データ統合装置。
　
　［相違点］
　［相違点１］
　Ａ’の「記憶部」に記憶する「異なる複数のデータベースそれぞれのデータ構造を定義した
１つ又はそれぞれ別異のデータモデル（以下「物理モデル」という）
　本願発明では、１つのデータモデル（物理モデル）であるのに対して、
　引用発明では、それぞれ別異のデータモデル（物理モデル）である点、
　［相違点２］
　Ａ’の「記憶部」に記憶する「
利用側アプリケーションから参照されるデータ構造を定義したデータモデル（以下「論理モデル」という）
　本願発明では、利用側アプリケーションごとに定義されたデータモデル、とするのに対して、
　引用発明では、そうとはしていない点
　
　［５］相違点等の判断
　
　（１）［相違点の克服］
　引用発明を出発点とし，
　引用発明の、「記憶部」に記憶する「異なる複数のデータベースそれぞれのデータ構造を定義した
それぞれ別異の
１つの
　引用発明の、「
利用側アプリケーションから参照されるデータ構造を定義したデータモデル（以下「論理モデル」という）
　
　（２）［相違点の克服］の容易性判断
　
　ア　［相違点１の克服］について
　引用発明は、複数のデータベース（実データベース１のテーブルＴ１と実データベース２のテーブルＴ２）を（仮想的に）統合する「仮想表定義７２５」を作成するものであるところ、その作成上、統合すべき又は統合が想定される複数のデータベースのデータ構造はまとめて１つのモデルとして記憶する方が便利であることは明らかであることからすれば、上記［相違点１の克服］は、当業者が容易に想到し得ることである。
　さらに、異なる複数の表（データベース）の構造定義を１つのデータモデルに格納することはごく普通のことにすぎない｛例えば、下記周知例１（図４，【0005】〜【0014】，特に【0013】【0014】），周知例２（図４，【0037】〜【0045】）参照｝ことからみても、上記［相違点１の克服］は、当業者が容易に想到し得ることである。
　
　イ　［相違点２の克服］について
　以下の事情からすれば、上記［相違点２の克服］も、当業者が容易に想到し得ることである。
　引用発明では、「仮想表定義７２５」によってＴ１とＴ２を仮想的に統合しているが、Ｔ１とＴ２の組み合わせとは異なる複数のデータベースを統合しようとすることも当業者にごく普通に想定されるところ、
　仮想表定義を用いるデータベースの統合技術は、そもそも、複数の個別データベースにアクセスするために個別アプリケーションを利用する欠点を解消するために考案されたものであること（刊行物１の段落【0002】，【0003】）からすれば、
１の
１の
　このことからすれば、上記のようにＴ１とＴ２の組み合わせとは異なる複数の個別データベースを統合しようとする際には、別の仮想表定義を用いる別のアプリケーションとすることが、まず想起される。
　また、アプリケーション毎に「表」を定義することは、ごく一般的である（例えば、下記周知例２の【0047】〜【0049】、特に【0047】参照）。
　これらのことからすれば、上記［相違点２の克服］も、当業者が容易に想到し得ることであるというべきである。
　
　　　　記（周知例）
　○周知例１：特開平９−２４５０４８号公報（【0013】【0014】のみ摘示）
【0013】データの定義とは、リレーショナルデータモデルを構成する表を定義することをいう。
表は図４に符号７ａ，７ｂ，７ｃ，…で示すように、リレーショナルデータモデル３に格納されており
【0014】
データの定義では、上記個々の表を定義する。具体的には、表の構造を定義することであり、表の名前、各項目の属性名、データ型の割り当て、インデックスの作成等を指定する（ＣＲＥＡＴＥ文）
　
　○周知例２：特開２００２−７１７７号公報
【0037】
図４は，マルチデータベース定義手段1のデータモデルを表す説明図である
【0038】
マルチデータベース定義手段1は，統合スキーマ12を定義するためのソフトウェアであるので，統合スキーマ12をデータモデルの階層のトップに置く。統合スキーマ12は，それぞれ複数のコンバータ情報150とDBシステム情報160とAPシステム情報170を包含する
【0040】DBシステム情報160は，マルチデータベースサーバ10がDBにアクセスするために必要な情報を保持するデータ項目であり，統合スキーマ12内でユニークなDB名，DBの所在，DBへのログイン識別子，DBMSの種別などの属性を保持する。また，
DBシステム情報160は，複数のDB表161を包含する構成である
【0041】
DB表161は，DBシステム情報160が包含する表に関するデータ項目であり，表名やDB表宣言名164などの属性を保持する
【0042】DB表カラム162は，DB表161が包含するカラムに関するデータ項目であり，DB表内でユニークなカラム名，カラムのデータ型，データ長，データのスケール（位取り），NULL可であるか，主キーであるか，外部キーであるか，といった属性を持つ。また，DB表カラム162は，一つの共通DB表カラム163を包含する構成である。
【0043】共通DB表カラム163は，DB表カラム162をマルチデータベースサーバ10のデータ型（以下，共通データ型と呼ぶ）に対応付けるための情報を保持するデータ項目である。
DB表カラム162は，各DBMSごとに異なるデータ型（以下，要素データ型と呼ぶ）を持つ
【0045】
要素スキーマ24は，
，各DBシステム情報160単位に管理される
【0047】APシステム情報170は，
マルチデータベースサーバ10がAPごとに外部スキーマ44を管理する
　
　ウ　まとめ
　以上によれば、引用発明を出発点とし，
　引用発明の、「記憶部」に記憶する「異なる複数のデータベースそれぞれのデータ構造を定義した
それぞれ別異の
１つの
　引用発明の、「
利用側アプリケーションから参照されるデータ構造を定義したデータモデル（以下「論理モデル」という）
　
　エ　補足（予備的検討）
　上記［３］対比の（２）「イ-２」において、引用発明の「
仮想表定義７２５
マッピングによる仮想表の定義情報
　仮に、「
仮想表定義７２５
マッピングによる仮想表の定義情報
　仮にそうであったとしても、上記「イ-２」でも言及したように、引用発明では、ｘ「アプリケーションからは仮想表上の項目を参照しデータベース上の項目に対してではなく仮想表上の項目に対して、問い合わせ処理要求として「問合わせ１　９０１」を発行しこれにより、アプリケーションから複数データベースへのアクセスを隠蔽できるようになって」いて、アプリケーションからは、実データベースは遮蔽され「仮想表」と仮想表上の「項目」だけから、希望する「問合わせ」（引用発明の「問合わせ１　９０１」や「問合わせ３　９０３」（刊行物１【0026】）が発行されるようになっているのであるから、マッピング定義や実データベースの情報も含まれる「仮想表定義７２５」とは別に、仮想表とその項目を特定する「仮想表の定義情報」（「ＶＴ１」と項目「ｉｃ１」〜「ｉｃ５」（ＩＮＴ型））を用意し提供するようにすることは自然でありかつ便利であることは当業者に自明である。
　すなわち、当業者であれば、アプリケーションから参照される仮想表定義情報（論理モデル）を、マッピング定義や実データベースの情報も含まれる「仮想表定義７２５」とは別に具備する構成とすることは容易に想到し得ることと言うべきである。
　したがって、仮に、上記のように「仮想表定義７２５に含まれる・・・本願発明の「論理モデル」とはいえない」といえたとしても、このことにより、本願発明が進歩性があるとはできない。
　
　（３）まとめ（相違点等の判断）
　以上，引用発明を出発点として，上記［相違点の克服］をすることで，本願発明に構成に達するところ，同克服は，刊行物１及び周知事項に基づいて当業者が容易になし得ることである。
　効果についてみても，構成の採用に伴って予測し得ない格別顕著なものがあるとも認められない。
　
【第４】むすび 
　
　以上のとおり，本願の請求項１に係る発明は，上記刊行物１に記載された発明及び技術常識に基づいて当業者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許を受けることができない。 
　それ故，本願の他の請求項について検討するまでもなく，本願は拒絶すべきものである。
　
　よって，結論のとおり審決する。