【事件の表示】
　特願２００７−５５４７７１「データ統合装置、データ統合方法およびデータ統合プログラムを記録したコンピュータ読み取り可能な記録媒体」拒絶査定不服審判事件〔平成１９年　７月２６日国際公開、ＷＯ２００７／０８３３７１〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１　出願の経緯
　本願は、２００６年１月１８日を国際出願日とする出願であって、平成２２年１２月１日付けで拒絶理由が通知され、これに対し、平成２３年２月７日付けで手続補正がなされたが、平成２３年５月９日付けで拒絶査定がなされ、これに対し平成２３年８月１０日に拒絶査定不服の審判が請求され、同時に手続補正がなされたものである。
　
第２　平成２３年８月１０日付けの手続補正についての補正却下の決定
　［補正却下の決定の結論］
　平成２３年８月１０日付けの手続補正（以下、「本件補正」という。）を却下する。
［理由］
１．本件補正前及び本件補正後の本願発明
　本件補正は、特許請求の範囲についてするもので、請求項１については、
（１）本件補正前の「情報源に対応する各情報源側のデータモデル（以下「物理モデル」という）」を、「情報源のデータ構造に基づいて定義される表の名前（以下「表名」という）ごとに、項目を示すデータ列の名前（以下「列名」という）と当該項目のデータ値の型（以下「データ型」という）から構成されるデータモデル（以下「物理モデル」という）」と限定し、
（２）本件補正前の「統合されたデータの利用側アプリケーションごとに定義したデータモデル（以下「論理モデル」という）」を、「利用側アプリケーションごとに定義した統合された表の構造として、表名ごとに列名とデータ型から構成されるデータモデル（以下「論理モデル」という）」と限定し、
（３）本件補正前の「前記論理モデルに対応して前記物理モデルまたは前記論理モデルのデータ列間の対応関係を定義したマッピング定義情報」を「前記論理モデルの表名に対応して前記物理モデルまたは前記論理モデルのデータ列間の対応関係をＦＲＯＭとＴＯの組として定義したマッピング定義情報」と限定し、さらに、本件補正前の「検索条件」を「論理モデルの表名を含む」と限定するとともに、本件補正前の「受信した前記検索条件に含まれる前記論理モデルに対応するマッピング定義情報から検索条件項目と一致するデータ列を抽出し、抽出した前記データ列に対応する物理モデルの検索条件項目から、前記物理モデルへの検索条件に変換する変換部」を「受信した前記検索条件に含まれる前記論理モデルの表名に対応するマッピング定義情報のＴＯ列から検索条件項目を検索し、前記ＴＯ列に対応するＦＲＯＭ列に対する前記物理モデルへの検索条件に変換する変換部」と限定する、
　ものである。
　よって、本件補正は、請求項１については、特許法第１７条の２第４項第２号（特許請求の範囲の減縮）に掲げる事項を目的とするものである。
　そこで、本件補正後における特許請求の範囲に記載された事項により特定される発明が、特許出願の際独立して特許を受けることができるものであるか（特許法第１７条の２第５項において準用する同法第１２６条第５項に規定する要件を満たすか）否かを、請求項１に係る発明（以下、「本願補正発明」という。）について以下に検討する。
　
　本願補正発明は、次のとおりのものである。
「【請求項１】
　異なるシステムにおいて管理されている複数の情報源に存在するデータを収集して統合するデータ統合装置であって、
　前記情報源のデータ構造に基づいて定義される表の名前（以下「表名」という）ごとに、項目を示すデータ列の名前（以下「列名」という）と当該項目のデータ値の型（以下「データ型」という）から構成されるデータモデル（以下「物理モデル」という）と、利用側アプリケーションごとに定義した統合された表の構造として、表名ごとに列名とデータ型から構成されるデータモデル（以下「論理モデル」という）と、前記論理モデルの表名に対応して前記物理モデルまたは前記論理モデルのデータ列間の対応関係をＦＲＯＭとＴＯの組として定義したマッピング定義情報を記憶した記憶部と、
　前記利用側アプリケーションから論理モデルに対する検索条件項目と論理モデルの表名を含む検索条件を受信し、受信した前記検索条件に含まれる前記論理モデルの表名に対応するマッピング定義情報のＴＯ列から検索条件項目を検索し、前記ＴＯ列に対応するＦＲＯＭ列に対する前記物理モデルへの検索条件に変換する変換部と、
　前記変換部によって変換された前記物理モデルへの検索条件に一致するデータを前記情報源から収集する収集部と、
　前記収集部によって収集された前記物理モデルのデータを前記マッピング定義情報に基づいて前記論理モデルのデータに変換して出力する出力部と、
　を備えたことを特徴とするデータ統合装置。」
　
２．引用例
　原査定の拒絶の理由に引用された、本願の国際出願日前に頒布された刊行物である、特開２００１−１０９７５８号公報（以下、「引用例」という。）には、図面とともに、以下の技術事項が記載されている。
（ア）「【課題】（１）アクセス対象データの変更に柔軟に対応可能な情報システムを構築する基盤となるデータ処理システムを提供する。さらに、（２）分散問合せ処理を必要とする前記データ処理システムの性能を向上する機構を提供する。
【解決手段】（１）アプリケーションからの問合せを受け付けるデータ処理システム内に、複数データベースへの多重マッピングが可能な仮想表を設ける。（２）仮想表上の一部のデータのコピーである部分レプリカを作成し、問合せの全部もしくは一部を部分レプリカを利用して処理する。また、部分レプリカを利用できない問合せ単位については、適切な分散ジョイン方式の選択と、処理を可能な限り実データベースにプッシュダウンする最適化を用いる。」（第１頁左下欄）
　
（イ）「【請求項２】アプリケーションを実行する少なくとも一つのクライアントと、それぞれにデータベースを備え、アクセス要求にしたがって該データベースを検索する少なくとも一つのサーバとにネットワークで接続され、前記クライアントからの問合せを受け付け、該問合せに対する結果を該クライアントに返す問合せ処理システムであって、前記少なくとも一つのデータベース上の項目、もしくは前記項目に対する演算結果の多重マッピングが可能な仮想項目名を保持して前記アプリケーションに提供する仮想表と、該仮想表を管理する仮想表管理部と、前記問合せを解析する問合せ解析部と、該問合せ解析部で解析された問合せから、該仮想表の定義を用いて前記データベースを参照するデータベース参照問合せを生成する問合せ生成部と、該問合せ生成部で生成された前記データベースへの問合せ処理を実行する問合せ実行部と、を有することを特徴とする問合せ処理システム。」（第１欄第９〜２４行）
　
（ウ）「【０００１】
【発明の属する技術分野】本発明は、データ処理に関し、特に、複数データベースへの統合アクセスを実現する問合せ処理システム及び方法に関する。」（第５欄第２９〜３２行）
　
（エ）「【００１０】
【課題を解決するための手段】前記第１の目的を達成するため、本発明ではアプリケーションからの問合せを受け付けるデータ処理システム内に、複数データベースへの多重マッピングが可能な仮想表を設ける。仮想表上の項目は実データベース上の表の項目、もしくは実データベース上のビューの項目、もしくは他の仮想表の項目（以下、単にデータベース上の項目と呼ぶ）、もしくはこれらの項目に対する演算結果にマッピングされ、アプリケーションからは仮想表上の項目を参照し、データベース上の項目に対してではなく仮想表上の項目に対して問合せを発行する。これにより、アプリケーションから複数データベースへのアクセスを隠蔽できる。本発明のデータ処理システムにおける多重マッピングとは、一つの仮想表が異なる条件の複数のマッピングを保持できることを意味する。」（第９欄第２０〜３５行）
　
（オ）「【００１３】
【発明の実施の形態】図１に、本発明によるデータ処理システムの好適な実現例を示す。アプリケーション１（１０２）を実行するクライアント１（１０１）、アプリケーション２（１０４）を実行するクライアント２（１０３）はネットワーク１２１を介してデータ処理システム１０５に接続される。ネットワーク１２１は、イーサネット、光ファイバ、ＦＤＤＩで接続されるローカルエリアネットワーク（ＬＡＮ）、もしくはＬＡＮよりも低速なインターネットを含んだワイドエリアネットワーク（ＷＡＮ）でも差し支えない。クライアントは（株）日立製作所のＨｉｔａｃｈｉＦＬＯＲＡなどのパーソナルコンピュータ、（株）日立製作所のＨｉｔａｃｈｉ  ３５００ワークステーションなどの任意のコンピュータシステムでよい。データ処理システムは、ネットワーク１２２を介して実データベースを管理するサーバ（１２６、１２７）に接続されている。ネットワーク１２２はネットワーク１２１と同様に、ＬＡＮ、もしくはＷＡＮで差し支えなく、サーバはその上でデータベースマネージメントシステム（ＤＢＭＳ）（１２３、１２４）が稼働する任意の計算機で差し支えない。ＤＢＭＳは（株）日立製作所のデータベースシステムＨｉＲＤＢや、Ｏｒａｃｌｅ社のＯｒａｃｌｅ８、ＩＢＭ社のＤＢ２などの汎用のＤＢＭＳ製品でよい。」（第１０欄第２６〜４９行）
　
（カ）「問合せ最適化部で、全ての部分問合せは部分レプリカを用いて処理できないと判定された場合、すなわちステップ１１０３でＮｏが選択された場合には、部分問合せのうち少なくとも一つが部分レプリカを用いて処理可能かどうかをチェックする（１１０４）。一つの部分問合せも部分レプリカを用いて処理できない場合、すなわちステップ１１０４でＮｏが選択された場合には、問合せ全体を実データベースで処理する必要があるため、問合せ生成部で該部分問合せを実データベースを参照する問合せに書き換え、問合せ実行部が必要に応じて問合せの構文を構文変換部１１５を用いて変換し、リモートデータベースアクセス部１１１を介して実データベース（１１７、１１８）に対して問合せ処理を実行する（１１０５）。実データベースから得られたデータは、必要に応じてデータ型、値変換部１１４でデータをクライアントの要求する形式に変換し、結果１２７としてクライアントに返して問合せ処理を終了する（１１０８）。」（第１４欄第５０行〜第１５欄第１７行）
　
（キ）「【００２４】問合せ最適化部で部分レプリカの使用可否を判定した後、選言標準形に変形された問合せは問合せ生成部１０９に転送される。問合せ生成部では、該問合せを前述したように部分レプリカを参照する問合せと実データベースを参照する問合せに書き替える。部分レプリカを参照する問合せに関してはローカルに書き換えた問合せをストレージ１２０に転送し、結果を得ることができるが、図８に示すように、クライアント８０１上のアプリケーション８０２からの仮想表に対する問合せ８０３がネットワーク８０７を介した異なる実データベース８１０、８１２間の結合処理８０８を必要とする場合である。この場合にはデータベース１（８１０）およびデータベース２（８１２）から取得するデータ量やネットワーク（８０７）の帯域幅、および結合結果の大きさの見積り等から、最適な実行方式を決定する必要があり、処理ステップは複雑になる。そこで、図１および図１２および図１３を用いて具体的なステップを説明する。
【００２５】実データベースに対する問合せは問合せ生成部で連言標準形（ｃｏｎｊｕｎｃｔｉｖｅ  ｎｏｒｍａｌ  ｆｏｒｍ）に変形される（１２０２）。連言標準形とは図１３の１３０３に示されるように、外側がＡＮＤ、内側がＯＲで結合される形であり、選言標準形と同様に任意の論理式は連言標準形に変形できる。変換方法は選言標準形の場合と同様に、文献７の第２章４節に示されている。連言標準形の内部のＯＲで結合された部分１３０４を選言問合せと呼ぶ。選言問合せが一つの実データベース（１１７）に対する問合せである場合、すなわちステップ１２０３でＹｅｓが選択された場合には、該問合せは該実データベース内のデータのみを用いて処理できるため、問合せ生成部１０９は該選言問合せ処理を該実データベース１１７で実行するように処理をプッシュダウンする問合せ書き替えを行う。問合せのプッシュダウンは、データ転送量を削減するために効果が大きい。例えば、図７に示すような仮想表と実データベースが存在する環境を仮定する。図７に示す環境では、７２５に示される仮想表定義でサーバ１（７１１）に接続されているデータベース１（７１５）内のテーブルＴ１（７２３）と、サーバ１とは異なるサーバ２（７１２）に接続されているデータベース２（７１６）内のテーブルＴ２（７２４）の項目が仮想表７０２にマッピングされている。この時、図９に示した問合せ１（９０１）が投入されたとすると、２つの条件ｉｃ２＜＝１０とｉｃ４＞＝１０はそれぞれデータベース１、データベース２にプッシュダウンでき、各々のデータベースのデータをデータ処理システムに転送してから該２つの条件を適用するよりもネットワーク７１０を転送されるデータ量は遥かに小さくなる。
【００２６】問合せ１と同様に問合せ３（９０３）も本発明の問合せ最適化が有効な例である。問合せ３は選言標準形のままでは条件をプッシュダウン可能かどうかは判定できないが、該問合せを連言標準形に変形すると９０４のようになる。まず、選言問合せ９０５はｉｃ２だけを参照する条件であり、仮想表定義７２５によればｉｃ２はｃ２にマッピングされるので、該選言問合せはデータベース１（７１５）にプッシュダウンできる。また、選言問合せ９０８はｉｃ４だけを参照する条件であり、前記仮想表定義によればｉｃ４はｃ５にマッピングされるされるため、該選言問合せはデータベース２にプッシュダウンされる。選言問合せ９０６および９０７はデータベース１もしくはデータベース２にプッシュダウンできないが、問合せが連言標準形に変換されているため、前記プッシュダウンされた９０５および９０８の適用によって削減されたデータに対してのみ、データ処理システム内で選言問合せ９０６および９０７を適用すればよく、データ転送量削減の効果が得られる。」（第１５欄第４５行〜第１７欄第１０行）
　
（ク）「【００３９】最後に図１の構文変換部１１５、およびデータ型、値変換部１１４について説明する。構文変換部はＤＢＭＳ毎に問合せ構文が異なる場合に必要となる構文変換を実現する。具体的には構文変換部はデータ処理システムで規定する標準構文と、各ＤＢＭＳの構文との対応表を保持し、変換が必要な構文は該対応表を用いて置き換えを行い、各ＤＢＭＳ向けに変換する。次にデータ型の変換に関しても構文変換部と同様に、データ処理システムのデータ型と各ＤＢＭＳのデータ型の対応表を管理し、実データベースからデータ処理システムにデータが転送される際に前記対応表を参照して適切な型変換プログラムモジュールを起動し型変換を実行する。」（第２１欄第２３〜３４行）
　
（ケ）「【００４１】型、値変換部における値の変換とは、例えば図７の結合処理においてｃ３、ｃ４が共に整数値で性別を表している項目であっても、ｃ３では男性が０、女性が１であるのに対して、ｃ４では逆に女性が０、男性が１であるように値の意味的な変換が必要となる場合に行う処理である。型変換の場合と同様に、値変換の場合も図１６に示す値変換対応表１６０１を値変換部が管理し、値変換プラグインモジュールを値変換時に適用することによって実現する。例えば、図７の例では、仮想表ＶＴ１上の項目ｉｃ３では男性が１、女性が０で表されており、ｃ３とは逆であるので、値の変換のためにプラグインモジュールＩｎｖｅｒｓｅＩｎｔ（）を用いることである。」（第２２欄第２４〜３６行）
　
　また、引用例１図１には「データ処理システム１０５」が、「仮想表１１９」、「仮想表管理部１１２」、「問合せ解析部１０７」、「問合せ生成部１０９」、「問合せ実行部１１０」及び「データ型、値変換部１１４」を有していることが示されている。
　
　次に、引用例図７（仮想表定義７２５を除く）には、
と記載されている。
　また、引用例１図７には「仮想表定義７２５」として，
「ＣＲＥＡＴＥ　ＭＡＰＰＩＮＧ　ＶＴ１（ｉｃ１　ＩＮＴ，　ｉｃ２　ＩＮＴ，　ｉｃ３　ＩＮＴ，　ｉｃ４　ＩＮＴ，　ｉｃ５　ＩＮＴ）　ＡＳ
　ＳＥＬＥＣＴ　ｃ１，ｃ２，ｃ３，ｃ５，ｃ６　
　ＦＲＯＭ　Ｔ１，Ｔ２　ＷＨＥＲＥ　ｃ３＝ｃ４　
　ＭＡＰＮＡＭＥ　ＶＭＡＰ３；」
と記載されている。
　
　次に、引用例図９には、「問合せ１　９０１」として、
「ＳＥＬＥＣＴ　ｉｃ１，ｉｃ４，ｉｃ５　ＦＲＯＭ　ＶＴ１　ＷＨＥＲＥ　ｉｃ２＜＝１０　ＡＮＤ　ｉｃ４＞＝１０；」
と記載されている。
　
　また、図１６には、
と記載されている。
　
　図７の「仮想表定義７２５」及び図１６の記載より、図７の仮想表７０２の「仮想表名」が「ＶＴ１」であり、仮想表７０２の「ｉｃ１」〜「ｉｃ５」が「仮想表項目名」であり、データベース１のテーブルＴ１の「ｃ１」〜「ｃ３」及びデータベース２のテーブルＴ２の「ｃ４」〜「ｃ６」が、「実データベース項目名」であることがわかる。さらに図７の「仮想表定義７２５」より、データベース１のテーブルＴ１の項目「ｃ１」〜「ｃ３」及びデータベース２のテーブルＴ２の項目「ｃ５」、「ｃ６」が、それぞれ仮想表７０２（仮想表名ＶＴ１）の項目「ｉｃ１」〜「ｉｃ５」（ＩＮＴ型）に　「ＭＡＰＰＩＮＧ」（以下、「マッピング」という。）されていることは明らかである（なお、用語の混乱を避けるため、「仮想表定義７２５」を、以下、「仮想表定義（ＭＡＰＰＩＮＧ）」と記載する。）。
　
　よって、引用例記載事項及び図面を総合勘案すると、引用例には、次の発明（以下、「引用発明」という。）が記載されていると認められる。
「クライアントからの問合せを受け付け、該問合せに対する結果を該クライアントに返す問合せ処理システム、特に、複数データベースヘの統合アクセスを実現する問合せ処理システムであって、
　データ処理システムは、アプリケーションに提供する仮想表と、該仮想表を管理する仮想表管理部と、前記問合せを解析する問合せ解析部と、該問合せ解析部で解析された問合せから、仮想表定義（ＭＡＰＰＩＮＧ）を用いて前記データベースを参照するデータベース参照問合せを生成する問合せ生成部と、該問合せ生成部で生成された前記データベースへの問合せ処理を実行する問合せ実行部と、データ型、値変換部とを有し、
　仮想表は、仮想表名（ＶＴ１）と、仮想表項目名（ｉｃ１〜ｉｃ５）の項目からなり、データベース１及びデータベース２は、それぞれＲＤＢＭＳ１が稼働するサーバ計算機１及びＲＤＢＭＳ２が稼働するサーバ計算機２にて管理される実データベースであり、データベース１のテーブルＴ１は、実デ−タベース項目名（ｃ１〜ｃ３）の項目からなり、データベース２のテーブルＴ２は、実データベース項目名（ｃ４〜ｃ６）の項目からなり、
　仮想表定義（ＭＡＰＰＩＮＧ）は、データベース１のテーブルＴ１の項目（ｃ１〜ｃ３）及びデータベース２のテーブルＴ２の項目（ｃ５、ｃ６）を、それぞれ、仮想表名（ＶＴ１）の仮想表の項目（ｉｃ１〜ｉｃ５）にマッピングするものであり、
　アプリケーションからは仮想表上の項目を参照し、データベース上の項目に対してではなく仮想表上の項目に対して問合せを発行し、これにより、アプリケーションから複数データベースヘのアクセスを隠蔽でき、
　問合せ生成部は選言問合せ処理を該実データベースで実行するように処理をプッシュダウンする問合せ書き替えを行ない、例えば、問合せ１「ＳＥＬＥＣＴ　ｉｃ１、ｉｃ４、ｉｃ５　ＦＲＯＭ　ＶＴ１　ＷＨＥＲＥ　ｉｃ２＜＝１０　ＡＮＤ　ｉｃ４＞＝１０；」が投入されたとすると、２つの条件「ｉｃ２＜＝１０」と「ｉｃ４＞＝１０」は、それぞれデータベース１、データベース２にプッシュダウンされ、
　データ型、値変換部１１４では、実データベースからデータ処理システムにデータが転送される際に、型変換を実行する、
　問合せ処理システム。」
　
３．対比
　本願補正発明を引用発明と比較する。
　引用発明の「データベース１及びデータベース２」は、「それぞれＲＤＢＭＳ１が稼働するサーバ計算機１及びＲＤＢＭＳ２が稼働するサーバ計算機２にて管理される実データベースであ」るから、本願補正発明の「異なるシステムにおいて管理されている複数の情報源」に相当する。
　次に、引用発明の「データ処理システム」は、「前記クライアントからの問合せを受け付け、該問合せに対する結果を該クライアントに返す問合せ処理システムであって、特に、複数データベースヘの統合アクセスを実現する問合せ処理システム」であるから、本願補正発明の「異なるシステムにおいて管理されている複数の情報源に存在するデータを収集して統合するデータ統合装置」に相当する。
　次に引用発明の「データ処理システム」が、「仮想表定義（ＭＡＰＰＩＮＧ）」を行ったり（引用例第４欄第６〜８行の【請求項１５】参照。）、「複数データベースヘの統合アクセスを実現する」ためには、
（１）「データベース１のテーブルＴ１」が、「実データベース項目名（ｃ１〜ｃ３）」の項目から構成されていることの情報（一般に、データベースの構造の定義は「スキーマ」と呼ばれているので、以下、「テーブル１のスキーマ」という。）、及び、「データベース２のテーブルＴ２」が「実データベース項目名（ｃ４〜ｃ６）」の項目から構成されていることの情報（以下、「テーブル２のスキーマ」という。）
（２）「仮想表名（ＶＴ１）」の「仮想表」が「仮想表項目名」（ｉｃ１〜ｉｃ５）の項目から構成されていることの情報（以下、「仮想表ＶＴ１のスキーマ」という。）
　を用いていることは明らかである。
　よって、引用発明の「テーブル１のスキーマ」及び「テーブル２のスキーマ」と、本願補正発明の「前記情報源のデータ構造に基づいて定義される表の名前（以下「表名」という）ごとに、項目を示すデータ列の名前（以下「列名」という）と当該項目のデータ値の型（以下「データ型」という）から構成されるデータモデル（以下「物理モデル」という）」とは、「前記情報源のデータ構造に基づいて定義される表の名前（以下「表名」という）ごとに、項目を示すデータ列の名前（以下「列名」という）を含んで構成されるデータモデル」の点で共通する。
　次に、引用発明の「仮想表」は、「仮想表定義（ＭＡＰＰＩＮＧ）」にあるとおり、「データベース１のテーブルＴ１」と「データベース２のテーブルＴ２」とを統合しているから、本願補正発明の「統合された表」に相当する。
　次に、引用発明の「アプリケーションに提供」される「仮想表ＶＴ１のスキーマ」と、本願補正発明の「利用側アプリケーションごとに定義した統合された表の構造として、表名ごとに列名とデータ型から構成されるデータモデル（以下「論理モデル」という）」とは、「利用側アプリケーションに対して定義した統合された表の構造として、表名に対し、列名を含んで構成されるデータモデル」の点で共通する。
　さらに、引用発明の「仮想表定義（ＭＡＰＰＩＮＧ）」は、データベース１のテーブルＴ１の項目（ｃ１〜ｃ３）及びデータベース２のテーブルＴ２の項目（ｃ５、ｃ６）を、それぞれ、仮想表名（ＶＴ１）の仮想表の項目　（ｉｃ１〜ｉｃ５）にマッピングする」ことを定義するものであるから、「物理モデル」及び「論理モデル」についての次の相違点は別として、本願補正発明の「前記論理モデルの表名に対応して前記物理モデルまたは前記論理モデルのデータ列間の対応関係を」「組として定義したマッピング定義情報」に相当する。
　次に、引用発明では、「アプリケーションからは仮想表上の項目を参照し、データベース上の項目に対してではなく仮想表上の項目に対して問合せを発行し」ているから、引用発明において「クライアントからの問合せを受け付け」ることが、「論理モデル」についての次の相違点は別として、本願補正発明の「前記利用側アプリケーションから論理モデルに対する検索条件項目と論理モデルの表名を含む検索条件を受信」することに相当する。
　次に、引用発明の「問合せ１「ＳＥＬＥＣＴ　ｉｃ１、ｉｃ４、ｉｃ５　ＦＲＯＭ　ＶＴ１　ＷＨＥＲＥ　ｉｃ２＜＝１０　ＡＮＤ　ｉｃ４＞＝１０；」」のうち、「仮想表名」である「ＶＴ１」が、「論理モデル」についての次の相違点は別として、本願補正発明の「検索条件に含まれる前記論理モデルの表名」に相当する。
　次に、引用例の摘記事項（キ）の「仮想表定義７２５によればｉｃ２はｃ２にマッピングされるので、該選言問合せはデータベース１（７１５）にプッシュダウンできる。」（第【００２６】段落第３文）、及び「前記仮想表定義によればｉｃ４はｃ５にマッピングされるため、該選言問合せはデータベース２にプッシュダウンされる。」（同段落第４文）との記載を参照すれば、引用発明の「問合せ生成部」は、「仮想表項目」（ｉｃ２、ｉｃ４）を検索条件項目として含む上記「問合せ１」が投入されると、「選言問合せ処理を該実データベースで実行するように」、２つの条件「ｉｃ２＜＝１０」と「ｉｃ４＞＝１０」を、それぞれ「データベース１」の項目（ｃ２）についての検索条件と、「データベース２」の項目（ｃ５）についての検索条件に「プッシュダウンする問合せ書き替え」を行っていることは明らかである。
　よって、引用発明の「問合せ生成部」と、本願補正発明の「受信した前記検索条件に含まれる前記論理モデルの表名に対応するマッピング定義情報のＴＯ列から検索条件項目を検索し、前記ＴＯ列に対応するＦＲＯＭ列に対する前記物理モデルへの検索条件に変換する変換部」とは、「物理モデル」及び「論理モデル」についての次の相違点は別として、「受信した前記検索条件に含まれる前記論理モデルの表名に対応するマッピング定義情報の検索条件項目を、対応する前記物理モデルヘの検索条件に変換する変換部」である点で共通するといえる。
　次に、引用発明において「該問合せ生成部で生成された前記データベースヘの問合せ」の結果として「実データベースからデータ処理システムにデータが転送される」ことが、「物理モデル」についての次の相違点は別として、本願補正発明の「前記変換部によって変換された前記物理モデルへの検索条件に一致するデータを前記情報源から収集する」ことに相当する。
　次に、引用発明の「データ処理システム」が、「データ型、値変換部１１４」により、「実データベースからデータ処理システムにデータが転送される際に、型変換を実行する」ことと、本願補正発明の「前記収集部によって収集された前記物理モデルのデータを前記マッピング定義情報に基づいて前記論理モデルのデータに変換して出力する」こととは、「物理モデル」及び「論理モデル」についての次の相違点は別として、「前記収集部によって収集された前記物理モデルのデータを前記論理モデルのデータに変換して出力する」点で共通する。
　
　すると、本願補正発明と引用発明とは、次の点で一致する。
＜一致点＞
　異なるシステムにおいて管理されている複数の情報源に存在するデータを収集して統合するデータ統合装置であって、
　前記情報源のデータ構造に基づいて定義される表の名前（以下「表名」という）ごとに、項目を示すデータ列の名前（以下「列名」という）を含んで構成されるデータモデル（以下「物理モデル」という）と、利用側アプリケーションに対して定義した統合された表の構造として、表名に対し、列名を含んで構成されるデータモデル（以下「論理モデル」という）と、前記論理モデルの表名に対応して前記物理モデルまたは前記論理モデルのデータ列間の対応関係を定義したマッピング定義情報を記憶した記憶部と、
　前記利用側アプリケーションから論理モデルに対する検索条件項目と論理モデルの表名を含む検索条件を受信し、受信した前記検索条件に含まれる前記論理モデルの表名に対応するマッピング定義情報の検索条件項目を、対応する前記物理モデルへの検索条件に変換する変換部と、
　前記変換部によって変換された前記物理モデルへの検索条件に一致するデータを前記情報源から収集する収集部と、
　前記収集部によって収集された前記物理モデルのデータを前記論理モデルのデータに変換して出力する出力部と、
　を備えたことを特徴とするデータ統合装置。」
　
　一方で、両者は、次の点で相違する。
＜相違点１＞
　本願補正発明では、「物理モデル」及び「論理モデル」が、それぞれ、「列名」とともに「データ型」（当該項目のデータ値の型）から構成され、「物理モデル」、「論理モデル」及び「マッピング定義情報」が記億部に記憶されているのに対し、引用発明では、「テーブル１のスキーマ」及び「テーブル２のスキーマ」と、「仮想表ＶＴ１のスキーマ」とが、それぞれ項目名（列名）（ｃ１〜ｃ３、ｃ４〜ｃ６）及び仮想表項目名（列名）（ｉｃ１〜ｉｃ５）を含むことは明らかであるものの、「データ型」（当該項目のデータ値の型）を含むか否か明らかでなく、また、引用発明において、「テーブル１のスキーマ」及び「テーブル２のスキーマ」と、「仮想表ＶＴ１のスキーマ」と、「仮想表定義（ＭＡＰＰＩＮＧ）」（マッピング定義情報）とが、データ処理システムの記億部に記憶されているか否かも明らかでない点。
　
＜相違点２＞
　本願補正発明では、「受信した前記検索条件に含まれる前記論理モデルの表名に対応するマッピング定義情報のＴＯ列から検索条件項目を検索し、前記ＴＯ列に対応するＦＲＯＭ列に対する前記物理モデルへの検索条件に変換」し、「前記収集部によって収集された前記物理モデルのデータを前記マッピング定義情報に基づいて前記論理モデルのデータに変換して出力する」のに対し、引用発明では、「仮想表定義（ＭＡＰＰＩＮＧ）」により「仮想表」の「仮想表項目」を検索条件項目として含む「問合せ」を、各データベース内の各テーブルＴ１、Ｔ２の項目についての検索条件に「プッシュダウン」する「問合せ書き替え」を行っていること、また、実データベースからデータ処理システムにデータが転送される際にデータの型変換を行うことが示されているに過ぎない点。
　
＜相違点３＞
　本願補正発明では、アプリケーションごとに「統合された表」が定義され、該「統合された表」の「表名ごと」に、「論理モデル」が設けられているのに対し、引用発明には、アプリケーションに「仮想表」（統合された表）が提供されるものの、アプリケーションごとに「仮想表」（統合された表）定義されているか、不明である点。
　
４．判断
　そこで、上記相違点について検討すると、
＜相違点１＞について：
　データベースに表やテーブルを作成する際、該表やテーブルのカラム（項目）名と当該カラム（項目）のデータ型とを含むスキーマ（データモデル）を定義することは、一般的なことである（必要であれば、特開２００２−７１７７号公報（第【００４２】段落及び第【００４５】段落の記載、第【００４８】〜【００４９】段落の記載参照。）。
　よって、引用発明において、「テーブル１のスキーマ」及び「テーブル２のスキーマ」を、それぞれ項目名（列名）（ｃ１〜ｃ３、ｃ４〜ｃ６）と当該項目のデータ型を含むスキーマ（物理モデル）とすること、及び、「仮想表ＶＴ１のスキーマ」を、仮想表項目名（列名）（ｉｃ１〜ｉｃ５）と、当該仮想表項目のデータ型を含むスキーマ（論理モデル）とすることは、当業者が容易になし得たことである。
　また、スキーマ等の定義情報をシステムに格納しておくことは、上記特開２００２−７１７７号公報第【００２０】段落第２文に「一般に、要素スキーマはＤＢのシステムテーブルと呼ばれる特別の表に格納してある」と記載されているように、一般的なことであるから、引用発明において、「データ処理システム」が、「テーブル１のスキーマ」及び「テーブル２のスキーマ」と、「仮想表ＶＴ１のスキーマ」と、「仮想表定義（ＭＡＰＰＩＮＧ）」（マッピング定義情報）とをデータ処理システムに格納しておくこと（「記億部」に「記憶」すること）も、当業者が必要に応じ適宜なし得たことである。
　
＜相違点２＞について：
　データベースにおいて、複数の表の項目間（データ列間）の対応関係を、各項目名の列の組を含む「変換表」として定義することは、周知技術である（例えば、引用例図１６の「値変換対応表」、特開平５−２７４３５４号公報（図５Ａ、図５Ｂの「データ形式変換表」）、特開２００２−１４９４６８号公報（図３の「実カラム情報３３０」と「仮想表−カラム定義３５０」）参照。）。
　よって、引用発明において、「仮想表」の「仮想表項目」と、データベース１、２内の各テーブルＴ１、Ｔ２の「項目」との間の「マッピング」を、「仮想表定義（ＭＡＰＰＩＮＧ）」を用いて行うことに代え、「仮想表」の「仮想表項目名」のデータ列と、各データベース１、２内の各テーブルＴ１、Ｔ２の「項目名」のデータ列との対応関係を組で定義した変換表（マッピング定義情報）を用いて行うようにし、検索条件の変換と、データの型変換（「データ」の「変換」）とを、該変換表（マッピング定義情報）を用いて行うようにすること、つまり、該変換表（マッピング定義情報）の「仮想表項目名」のデータ列（ＴＯ列）から検索条件項目を検索し、該「仮想表項目名」のデータ列（ＴＯ列）に対応する、テーブルＴ１、Ｔ２の「項目名」のデータ列（ＦＲＯＭ列）に対する「テーブル１のスキーマ」及び「テーブル２のスキーマ」への検索条件に「プッシュダウン」する「問合せ書き替え」を行い（検索条件に変換）し、「書き替え」られた「問合せ」の結果として「実データベースからデータ処理システムに」「転送」される「データ」（前記収集部によって収集された前記物理モデルのデータ）を、該変換表　（マッピング定義情報）に基づいて「仮想表ＶＴ１のスキーマ」のデータ（論理モデルのデータ）に変換して出力することは、当業者が容易になし得たことである。
　また、その際、「仮想表項目名」のデータ列、及びテーブルＴ１、Ｔ２の「項目名」のデータ列に、それぞれ「ＴＯ」、及び「ＦＲＯＭ」との列名を付与することも、当業者が創作力を要せずに適宜なし得たことである。
　
＜相違点３＞について：
　アプリケーションごとに「表」を定義することは、例えば、上記特開２００２−７１７７号公報第【００４７】段落第１文の「ＡＰごとに外部スキーマ４４を管理する」（当審注：「ＡＰ」は、第【０００５】段落第１文に記載されているとおり、「アプリケーション」を意味する。）及び第２１図に示されているように、周知技術である。
　よって、引用発明において、アプリケーションごとに「仮想表」（統合された表）を定義すること、及び、それら「仮想表」（統合された表）の「表名」ごとに、「仮想表ＶＴ１のスキーマ」（論理モデル）を設けることは、当業者が容易になし得たことである。
　
　また、本願補正発明の作用効果も、引用発明及び周知技術から、当業者が予測し得たものである。
　
　以上のとおり、本願補正発明は、引用発明及び周知技術に基づいて当業者が容易に発明をすることができたものである。
　
５．本件補正についての結び
　以上のとおり、本願補正発明は、特許法第２９条第２項の規定により、特許出願の際独立して特許を受けることができないものであるから、本件補正は、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に違反するので、同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　
第３　本願発明について
１．本願発明
　平成２３年８月１０日付けの手続補正は上記のとおり却下されたので、本願の請求項１〜９に係る発明は、平成２３年２月７日付け手続補正書により補正された特許請求の範囲の請求項１〜９に記載されたとおりのものであるところ、請求項１に係る発明（以下、「本願発明」という。）は、次のとおりのものである。
「【請求項１】
　異なるシステムにおいて管理されている複数の情報源に存在するデータを収集して統合するデータ統合装置であって、
　前記情報源に対応する各情報源側のデータモデル（以下「物理モデル」という）と、統合されたデータの利用側アプリケーションごとに定義したデータモデル（以下「論理モデル」という）と、前記論理モデルに対応して前記物理モデルまたは前記論理モデルのデータ列間の対応関係を定義したマッピング定義情報を記憶した記憶部と、
　前記利用側アプリケーションから論理モデルに対する検索条件項目を含む検索条件を受信し、受信した前記検索条件に含まれる前記論理モデルに対応するマッピング定義情報から検索条件項目と一致するデータ列を抽出し、抽出した前記データ列に対応する物理モデルの検索条件項目から、前記物理モデルへの検索条件に変換する変換部と、
　前記変換部によって変換された前記物理モデルへの検索条件に一致するデータを前記情報源から収集する収集部と、
　前記収集部によって収集された前記物理モデルのデータを前記マッピング定義情報に基づいて前記論理モデルのデータに変換して出力する出力部と、
　を備えたことを特徴とするデータ統合装置。」
　
２．引用例
　原査定の拒絶の理由で引用された引用例及びその記載事項は、前記「第２　［理由］２．」に記載したとおりである。
　
３．対比・判断
　本願発明は、上記「第２［理由］」で検討した本願補正発明から、「１．本件補正前及び本件補正後の本願発明」に記載した（１）〜（３）の限定を省いたものに相当する。
　そうすると、本願発明の発明特定事項の全てを含み、更に他の発明特定事項を付加したものに相当する本願補正発明が、前記「第２［理由］４．」に記載したとおり、引用例に記載された発明及び周知技術に基づいて、当業者が容易に発明をすることができたものであるから、本願発明も、同様の理由により、引用例に記載された発明及び周知事項に基づいて当業者が容易に発明をすることができたものである。
　
４．むすび
　以上のとおり、本願の請求項１に係る発明は、特許法第２９条第２項の規定により特許を受けることができないものである。
　従って、その余の請求項について論及するまでもなく、本願は、拒絶すべきものである。
　よって、結論のとおり審決する。