• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 特許、登録しない。 G06F
管理番号 1299162
審判番号 不服2014-1173  
総通号数 185 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2015-05-29 
種別 拒絶査定不服の審決 
審判請求日 2014-01-22 
確定日 2015-03-26 
事件の表示 特願2012-250730「データ統合装置、データ統合方法およびデータ統合プログラム」拒絶査定不服審判事件〔平成25年 2月21日出願公開、特開2013- 37726〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由 【第1】経緯
本願は、平成24年11月14日の出願であって、
2006年(平成18年)1月18日を国際出願日とする特願2007-554771号の一部を、新たに特願2011-175352号として出願し、さらに、その一部を、新たな特許出願としたものであり、
平成25年7月24日付けで拒絶理由が通知され、これに対し、平成25年9月30日付けで手続補正がなされたが、平成25年10月16日付けで拒絶査定がなされ、これに対し平成26年1月22日に拒絶査定不服の審判が請求されたものである。

【第2】本願発明
本願の請求項1?5に係る各発明は,出願当初の特許請求の範囲,明細書及び図面の記載,及び平成25年9月30日付け手続補正書の特許請求の範囲の記載からみて,それぞれ,同手続補正書の特許請求の範囲の請求項1?5に記載した事項により特定されるとおりのものと認められるところ,そのうち,請求項1に係る発明(以下「本願発明」という。)は,下記のとおりのものである。
記(本願発明)
【請求項1】
異なる複数のデータベースそれぞれのデータ構造を定義したデータモデル(以下「物理モデル」という)と、利用側アプリケーションごとに定義された、前記複数のデータベースのデータに関する、当該利用側アプリケーションから参照されるデータ構造を定義したデータモデル(以下「論理モデル」という)と、前記論理モデルと前記物理モデルとの前記データ構造の対応関係を定義したマッピング定義情報を記憶した記憶部と、
前記利用側アプリケーションから前記論理モデルに対する検索条件を受信し、該受信した検索条件を前記物理モデル、前記論理モデル、および前記マッピング定義情報から物理モデルに対する検索条件に変換する第一変換部と、
前記第一変換部によって変換された前記物理モデルへの検索条件に一致するデータを前記複数のデータベースから収集する収集部と、
前記収集した物理モデルのデータを前記物理モデル、前記論理モデル、及び前記マッピング定義情報に基づいて論理モデルのデータに変換する第二変換部と、
前記第二変換部によって変換された論理モデルのデータを出力する出力部と、
を備えたことを特徴とするデータ統合装置。

【第3】当審の判断

[1]引用刊行物の記載
原査定の拒絶の理由に引用された、本願の原出願の国際出願日前に頒布された刊行物である、特開2001-109758号公報(以下、「刊行物1」という。)には、図面とともに、以下の事項(下線は,注目箇所を示すために当審で施したものである。)が記載されている。

〈特許請求の範囲、請求項2,15〉
【請求項2】アプリケーションを実行する少なくとも一つのクライアントと、それぞれにデータベースを備え、アクセス要求にしたがって該データベースを検索する少なくとも一つのサーバとにネットワークで接続され、前記クライアントからの問合せを受け付け、該問合せに対する結果を該クライアントに返す問合せ処理システムであって、前記少なくとも一つのデータベース上の項目、もしくは前記項目に対する演算結果の多重マッピングが可能な仮想項目名を保持して前記アプリケーションに提供する仮想表と、該仮想表を管理する仮想表管理部と、前記問合せを解析する問合せ解析部と、該問合せ解析部で解析された問合せから、該仮想表の定義を用いて前記データベースを参照するデータベース参照問合せを生成する問合せ生成部と、該問合せ生成部で生成された前記データベースへの問合せ処理を実行する問合せ実行部と、を有することを特徴とする問合せ処理システム。

【請求項15】
前記仮想表管理部は、前記仮想表の定義を行うインタフェース手段を有する請求項2記載の問合せ処理システム。

〈発明の属する技術分野〉
【0001】
【発明の属する技術分野】本発明は、データ処理に関し、特に、複数データベースへの統合アクセスを実現する問合せ処理システム及び方法に関する。

〈従来の技術〉
【0002】
【従来の技術】企業内情報システムの再編、企業間提携をはじめとする社会情勢の急速な変化に対応可能な情報システムが求められるようになっている。通常企業内には多数のデータベースが存在し、それぞれのデータベースは膨大なデータを多数のファイルやテーブルに保持している。これらのデータは長い時間をかけて様々な状況下で作成されてきたという経緯から一貫性が無く、(1)別々のデータにアクセスするためには個別のアプリケーションを使用せざるを得ない、(2)新業務の開始、業務内容変更にあたっては新規アプリケーション開発、アプリケーション変更を行わなければならないという問題が指摘されていた。個別データにアクセスするために個別アプリケーションを利用するアプローチは、アプリケーションの数および種類が多くなることに起因する管理の複雑化、多数のアプリケーションの開発および維持にかかるコスト増加、そしてアプリケーション開発に必要となる時間分の業務遅延に起因する非効率化等の数多くの欠点を持つのは明らかである。
【0003】アプリケーションから複数のデータベースを隠蔽する目的で仮想的なテーブル(以下、仮想表と呼ぶ)を作成して該仮想表上の項目から実在するデータベース(以下、実データベースと呼ぶ)上の項目へのマッピングを用いることによって、複数の実データベースへの透過アクセスを実現する方式が、(1)米国特許5873088 “Deｒiｖed daｔa baｓe ｐｒｏceｓｓingｓｙｓｔem enabling ｏne ｐｒｏgｒam ｔｏ acceｓｓ a ｐlｕｒaliｔｙ ｏf daｔa baｓiｓ”(文献1)や、(2)米国特許5675785 “Daｔa ｗaｒehｏｕｓe ｗhichiｓ acceｓｓed bｙ a ｕｓeｒ ｕｓing a ｓchemaｏf ｖiｒｔｕal ｔableｓ”(文献2)に開示されている。(1)は実データベースの論理定義情報と格納情報を用いて複数の実データベースに透過的にアクセスする方式、(2)は仮想テーブルで構成されるスキーマに対して発行された問合せを変換して実データベースにアクセスする方式で、共に実データベースを隠蔽し、アプリケーションから仮想的な表へのアクセスを実データベースへのアクセスに変換することを特徴としていた。仮想的なスキーマを介して実データベースにアクセスするという考え方は、データベース統合やスキーマ統合と呼ばれ、1980年頃より学会を中心として研究が盛んに行われ、例えばA.Sheｔh、J.Laｒｓｏn著、“Fedeｒaｔed DaｔabaｓeSｙｓｔemｓ fｏｒ Managing Diｓｔｒibｕｔed、Heｔeｒｏgeneｏｕｓ、and Aｕｔｏnｏmｏｕｓ Daｔabaｓeｓ”、ACM Cｏmｐｕｔeｒ Sｕｒｖeｙｓ、Vｏl.22、Nｏ.3、ｐｐ.183-236(文献3)に示されている連邦データベースシステムに代表されるいくつかの統合方式が提案されている。これらの方式はいずれも仮想的なスキーマもしくは表から実データベースへのマッピングを用いて、ユーザもしくはアプリケーションから実データベースを隠蔽し、論理的な統合を実現していた・・・(以下略)

〈解決するための手段〉
【0010】
【課題を解決するための手段】前記第1の目的を達成するため、本発明ではアプリケーションからの問合せを受け付けるデータ処理システム内に、複数データベースへの多重マッピングが可能な仮想表を設ける。仮想表上の項目は実データベース上の表の項目、もしくは実データベース上のビューの項目、もしくは他の仮想表の項目(以下、単にデータベース上の項目と呼ぶ)、もしくはこれらの項目に対する演算結果にマッピングされ、アプリケーションからは仮想表上の項目を参照し、データベース上の項目に対してではなく仮想表上の項目に対して問合せを発行する。これにより、アプリケーションから複数データベースへのアクセスを隠蔽できる。本発明のデータ処理システムにおける多重マッピングとは、一つの仮想表が異なる条件の複数のマッピングを保持できることを意味する。

〈発明の実施の形態〉
【0013】
【発明の実施の形態】図1に、本発明によるデータ処理システムの好適な実現例を示す。アプリケーション1(102)を実行するクライアント1(101)、アプリケーション2(104)を実行するクライアント2(103)はネットワーク121を介してデータ処理システム105に接続される。ネットワーク121は、イーサネット、光ファイバ、FDDIで接続されるローカルエリアネットワーク(LAN)、もしくはLANよりも低速なインターネットを含んだワイドエリアネットワーク(WAN)でも差し支えない。クライアントは(株)日立製作所のHiｔachiFLORAなどのパーソナルコンピュータ、(株)日立製作所のHiｔachi 3500ワークステーションなどの任意のコンピュータシステムでよい。データ処理システムは、ネットワーク122を介して実データベースを管理するサーバ(126、127)に接続されている。ネットワーク122はネットワーク121と同様に、LAN、もしくはWANで差し支えなく、サーバはその上でデータベースマネージメントシステム(DBMS)(123、124)が稼働する任意の計算機で差し支えない。DBMSは(株)日立製作所のデータベースシステムHiRDBや、Oｒacle社のOｒacle8、IBM社のDB2などの汎用のDBMS製品でよい。

【0014】今アプリケーション2がデータ処理システム上の仮想表119上の項目を参照する問合せ処理要求126を発行したとする。本実施例における仮想表は複数の実データベースを論理的に統合した表であり、仮想表上の項目は実データベース上の項目に多重マッピングされている。例えば、図2は貯蓄平均表201、および顧客貯蓄残高表202という異なる2つの実データベース上に存在する、2つの表が仮想表203に多重マッピングされている例である。仮想表の項目である支店(208)、および貯蓄平均(209)は、貯蓄平均表の支店(203)と貯蓄平均(204)、および顧客貯蓄残高表202の支店(206)と、該顧客貯蓄残高表の1億円以上の高額預金者を除いた顧客の預金すなわち貯蓄額(207)を支店別に集計し、平均を取った値の2通りにマッピングしている。貯蓄平均表の項目は仮想表の項目そのものにマッピングされているのに対し、顧客貯蓄残高表では集計演算の結果が割り当てられているのが大きな相違点であり、本マッピングによる仮想表定義は例えば210に示すような構文で記述可能である。マッピング記述例では仮想表VTの項目である支店と貯蓄平均に対して、貯蓄平均表の項目をマッピングしたVMAP1と、顧客貯蓄残高表から得た集計値をマッピングしたVMAP2が定義されている。

【0016】図1に戻って、データ処理システム105内のアプリケーションマネージャ106はアプリケーション2から発行された問合せをネットワーク経由のクライアントからの問合せ処理要求を受け付ける。受け付けられた問合せは問合せ解析部107で解析され、問合せ最適化部108に転送される。データ処理システムにおける問合せ処理の流れを図1および図11および図13を用いて説明する。問合せ最適化部では、まず受け付けた問合せを図13の1301に示すような選言標準形(diｓjｕncｔiｖe nｏｒmal fｏｒm)に変形する(1102)。ただし、図13の1305の構成要素となっている各ｑは原子論理式を表す。任意の論理式は該標準形へ変換できることが保証されており、変換方法は例えば、Chin-Liang Chang、Richaｒd Chaｒ-Tｕng Lee著、長尾、辻井訳、“コンピュータによる定理の証明”の第2章4節(文献7)に示されている。選言標準形に分解され、外側がORで結合された内部のANDで結合された部分1302を以下では部分問合せと呼ぶ。
【0017】データ処理システム内の問合せ最適化部108では問合せを選言標準形に変形した後、部分レプリカ管理部113で管理される部分レプリカ情報を利用して、部分問合せ単位でデータ処理システム内のストレージ120に格納された部分レプリカ125を利用できるか否かを判定する。ストレージ120は磁気記憶装置、フラッシュメモリ、もしくはメモリで構わない。また部分レプリカ管理部は、部分レプリカをファイルとして管理するのでもデータベースシステムを用いてデータベースとして管理するのでも差し支えない。

【0023】問合せ最適化部で、全ての部分問合せが部分レプリカを用いて処理可能であると判定された場合、すなわちステップ1103でYeｓが選択された場合には、問合せは部分レプリカに対して適用される(1107)。この場合、問合せは問合せ生成部109で部分レプリカを参照するように書き換えられ、問合せ実行部110がローカルデータベースアクセス部116を介してストレージ120に格納されている部分レプリカ125を用いて問合せ処理を行い、得られたデータを結果127としてアプリケーションマネージャ経由でクライアントに返して問合せ処理を終了する(1108)。問合せ最適化部で、全ての部分問合せは部分レプリカを用いて処理できないと判定された場合、すなわちステップ1103でNｏが選択された場合には、部分問合せのうち少なくとも一つが部分レプリカを用いて処理可能かどうかをチェックする(1104)。一つの部分問合せも部分レプリカを用いて処理できない場合、すなわちステップ1104でNｏが選択された場合には、問合せ全体を実データベースで処理する必要があるため、問合せ生成部で該部分問合せを実データベースを参照する問合せに書き換え、問合せ実行部が必要に応じて問合せの構文を構文変換部115を用いて変換し、リモートデータベースアクセス部111を介して実データベース(117、118)に対して問合せ処理を実行する(1105)。実データベースから得られたデータは、必要に応じてデータ型、値変換部114でデータをクライアントの要求する形式に変換し、結果127としてクライアントに返して問合せ処理を終了する(1108)。問合せ最適化部で部分問合せの少なくとも一つが部分レプリカを用いて処理できると判定された場合、・・・(中略)・・・問合せ実行部が必要に応じて問合せの構文を構文変換部を用いて変換し、リモートデータベースアクセス部111を介して実データベースに対して問合せ処理を実行し、実データベースから得られたデータは、必要に応じてデータ型、値変換部114でデータをクライアントの要求する形式に変換し、該問合せ実行部で前記部分レプリカから得られたデータと前記実データベースより得られた結果を統合し、問合せ126に対する結果127としてクライアントに返して問合せ処理を終了する。・・・(以下略)
【0024】問合せ最適化部で部分レプリカの使用可否を判定した後、選言標準形に変形された問合せは問合せ生成部109に転送される。問合せ生成部では、該問合せを前述したように部分レプリカを参照する問合せと実データベースを参照する問合せに書き替える。部分レプリカを参照する問合せに関してはローカルに書き換えた問合せをストレージ120に転送し、結果を得ることができるが、図8に示すように、クライアント801上のアプリケーション802からの仮想表に対する問合せ803がネットワーク807を介した異なる実データベース810、812間の結合処理808を必要とする場合である。この場合にはデータベース1(810)およびデータベース2(812)から取得するデータ量やネットワーク(807)の帯域幅、および結合結果の大きさの見積り等から、最適な実行方式を決定する必要があり、処理ステップは複雑になる。そこで、図1および図12および図13を用いて具体的なステップを説明する。
【0025】実データベースに対する問合せは問合せ生成部で連言標準形(cｏnjｕncｔiｖe nｏｒmal fｏｒm)に変形される(1202)。連言標準形とは図13の1303に示されるように、外側がAND、内側がORで結合される形であり、選言標準形と同様に任意の論理式は連言標準形に変形できる。変換方法は選言標準形の場合と同様に、文献7の第2章4節に示されている。連言標準形の内部のORで結合された部分1304を選言問合せと呼ぶ。選言問合せが一つの実データベース(117)に対する問合せである場合、すなわちステップ1203でYeｓが選択された場合には、該問合せは該実データベース内のデータのみを用いて処理できるため、問合せ生成部109は該選言問合せ処理を該実データベース117で実行するように処理をプッシュダウンする問合せ書き替えを行う。問合せのプッシュダウンは、データ転送量を削減するために効果が大きい。例えば、図7に示すような仮想表と実データベースが存在する環境を仮定する。図7に示す環境では、725に示される仮想表定義でサーバ1(711)に接続されているデータベース1(715)内のテーブルT1(723)と、サーバ1とは異なるサーバ2(712)に接続されているデータベース2(716)内のテーブルT2(724)の項目が仮想表702にマッピングされている。この時、図9に示した問合せ1(901)が投入されたとすると、2つの条件ic2＜=10とic4＞=10はそれぞれデータベース1、データベース2にプッシュダウンでき、各々のデータベースのデータをデータ処理システムに転送してから該2つの条件を適用するよりもネットワーク710を転送されるデータ量は遥かに小さくなる。
【0026】問合せ1と同様に問合せ3(903)も本発明の問合せ最適化が有効な例である。問合せ3は選言標準形のままでは条件をプッシュダウン可能かどうかは判定できないが、該問合せを連言標準形に変形すると904のようになる。まず、選言問合せ905はic2だけを参照する条件であり、仮想表定義725によればic2はc2にマッピングされるので、該選言問合せはデータベース1(715)にプッシュダウンできる。また、選言問合せ908はic4だけを参照する条件であり、前記仮想表定義によればic4はc5にマッピングされるされるため、該選言問合せはデータベース2にプッシュダウンされる。選言問合せ906および907はデータベース1もしくはデータベース2にプッシュダウンできないが、問合せが連言標準形に変換されているため、前記プッシュダウンされた905および908の適用によって削減されたデータに対してのみ、データ処理システム内で選言問合せ906および907を適用すればよく、データ転送量削減の効果が得られる。

【0039】最後に図1の構文変換部115、およびデータ型、値変換部114について説明する。構文変換部はDBMS毎に問合せ構文が異なる場合に必要となる構文変換を実現する。具体的には構文変換部はデータ処理システムで規定する標準構文と、各DBMSの構文との対応表を保持し、変換が必要な構文は該対応表を用いて置き換えを行い、各DBMS向けに変換する。次にデータ型の変換に関しても構文変換部と同様に、データ処理システムのデータ型と各DBMSのデータ型の対応表を管理し、実データベースからデータ処理システムにデータが転送される際に前記対応表を参照して適切な型変換プログラムモジュールを起動し型変換を実行する。・・・(以下略)

【0041】型、値変換部における値の変換とは、例えば図7の結合処理においてc3、c4が共に整数値で性別を表している項目であっても、c3では男性が0、女性が1であるのに対して、c4では逆に女性が0、男性が1であるように値の意味的な変換が必要となる場合に行う処理である。型変換の場合と同様に、値変換の場合も図16に示す値変換対応表1601を値変換部が管理し、値変換プラグインモジュールを値変換時に適用することによって実現する。例えば、図7の例では、仮想表VT1上の項目ic3では男性が1、女性が0で表されており、c3とは逆であるので、値の変換のためにプラグインモジュールInｖeｒｓeInｔ()を用いることである。

〈図面〉
図1には「データ処理システム105」が、「仮想表119」、「仮想表管理部112」、「問合せ解析部107」、「問合せ生成部109」、「問合せ実行部110」及び「データ型、値変換部114」を有していることが示されている。

図7には「仮想表定義725」として,
「CREATE MAPPING VT1(ic1 INT, ic2 INT, ic3 INT, ic4 INT, ic5 INT) AS
SELECT c1,c2,c3,c5,c6
FROM T1,T2 WHERE c3=c4
MAPNAME VMAP3;」
と記載されている。 (次ページに示す)












図9には、「問合せ1 901」として、
「SELECT ic1,ic4,ic5 FROM VT1 WHERE ic2＜=10 AND ic4＞=10;」と記載されている。

[2]刊行物1に記載された発明(以下,「引用発明」という。)の認定

ア 刊行物1には、「アプリケーションを実行する」「クライアントからの問合せを受け付け、該問合せに対する結果を該クライアントに返す問合せ処理システム、特に、複数データベースヘの統合アクセスを実現する問合せ処理システム」が示される(請求項2、【0001】)。
「問合せ処理システム」は、 概要、
アプリケーションに提供する仮想表と、
前記仮想表の定義を行うインタフェース手段を有し、該仮想表を管理する仮想表管理部と、
前記問合せを解析する問合せ解析部と、
該問合せ解析部で解析された問合せから、仮想表の定義を用いて前記データベースを参照するデータベース参照問合せを生成する問合せ生成部と、該問合せ生成部で生成された前記データベースへの問合せ処理を実行する問合せ実行部とを有している(請求項2,請求項15,図1等)。

イ 実施の形態
請求項2の上記「問合せ処理システム」は、実施の形態では「データ処理システム」(105)と称されている(【0013】、図1等)。
実施の形態として、特に、【0025】に記載される、図7の環境において、図9の「問合せ1 901」が投入された時に「データ処理システム」が行う処理に着目する。

〈図7の環境における図9の「問合せ1 901」の投入〉
図7の環境は、図1において、データ処理システム(105)がデータ処理システム701とされ、仮想表(119)が仮想表702とされ、
「図7に示すような仮想表と実データベースが存在する環境」であって、「仮想表定義725(図7)でサーバ1(711)に接続されているデータベース1(715)内のテーブルT1(723)と、サーバ1とは異なるサーバ2(712)に接続されているデータベース2(716)内のテーブルT2(724)の項目が仮想表702にマッピングされている」環境(【0025】)である。
そして、同環境において図9の「問合せ1 901」が投入されることは、「アプリケーションから」「仮想表上の項目を参照し、データベース上の項目に対してではなく仮想表上の項目に対して」「問い合わせ処理要求」として図9の「問合せ1 901」が「発行」されることを意味し、「これにより、アプリケーションから複数データベースへのアクセスを隠蔽できる」ようになっている(【0014】,【0010】)。

当該処理は、【0016】,【0023】,【0025】,図11,図12によれば、
図11のステップ1104でNｏで、「全ての部分問合せは部分レプリカを用いて処理できないと判定された場合」の処理であって、
その処理は、概略、
「問合せ生成部で該部分問合せを実データベースを参照する問合せに書き換え」、「問合せ実行部が」(必要に応じて問合せの構文を構文変換部115を用いて変換し、)リモートデータベースアクセス部111を介して実データベースに対して問合せ処理を実行する(図11,1105,【0023】)ようにされるもので、
その「実データベースに対する問合せ」(図12)では、(「該問合せは該実データベース内のデータのみを用いて処理できる」と判断されて、)問合せ生成部109は選言問合せ処理を該実データベースで実行するように処理をプッシュダウンする問合せ書き替えを行い(1206、【0025】)、
問合せ実行部の問合せ処理の実行によって「実データベースから得られたデータは、必要に応じてデータ型、値変換部114でデータをクライアントの要求する形式に変換し、結果127としてクライアントに返して問合せ処理を終了する」(1108,【0023】)というものである。

〈仮想表定義725(図7)〉
「仮想表定義725(図7)」、すなわち、「CREATE MAPPING VT1(ic1 INT, ic2 INT, ic3 INT, ic4 INT, ic5 INT) AS
SELECT c1,c2,c3,c5,c6
FROM T1,T2 WHERE c3=c4
MAPNAME VMAP3;」は、
図2を参照した【0014】の「仮想表定義」についての説明(「本マッピングによる仮想表定義は例えば210に示すような構文で記述可能である。」),図16、【0025】を参照すれば、
マッピングを定義すると共に、マッピングによって仮想表を定義するものと理解される。
すなわち、「仮想表定義725」は、
マッピング定義情報と、マッピングによる仮想表の定義情報とを含み、
マッピング定義情報として、
マップ名(MAPNAME)がVMAP3であるマッピングが、
実データベース1のテーブルT1及び実データベース2のテーブルT2から表名が「VT1」である仮想表へのマッピングであって、
仮想表「VT1」の項目「ic1」?「ic5」(INT型)は、それぞれ、実データベース1のテーブルT1の項目「c1」?「c3」及び実データベース2のテーブルT2の項目「c4」?「c6」と対応するようにマッピングされること、を定義するとともに、
マッピングによる仮想表の定義情報として、
(マップ名(MAPNAME)がVMAP3というマッピングにより定義されるものであって、)
表名が「VT1」、項目が「ic1」?「ic5」(INT型)である仮想表(「仮想表702(図7)」)であること、を定義している
と理解される。

〈具体的処理〉
以上のことと、図9の「問合せ1 901」、すなわち、「SELECT ic1,ic4,ic5 FROM VT1 WHERE ic2＜=10 AND ic4＞=10;」についての【0025】の「ステップ1203でYeｓが選択された場合には、該問合せは該実データベース内のデータのみを用いて処理できるため、問合せ生成部109は該選言問合せ処理を該実データベース117で実行するように処理をプッシュダウンする問合せ書き替えを行う。・・・この時、図9に示した問合せ1(901)が投入されたとすると、2つの条件ic2＜=10とic4＞=10はそれぞれデータベース1、データベース2にプッシュダウンでき、各々のデータベースのデータをデータ処理システムに転送してから該2つの条件を適用するよりもネットワーク710を転送されるデータ量は遥かに小さくなる。」、及び【0023】「必要に応じてデータ型、値変換部114でデータをクライアントの要求する形式に変換し、結果127としてクライアントに返して問合せ処理を終了する(1108)。」を考慮すれば、
図7の環境において図9の「問合せ1 901」が投入された時の処理は以下のようであると理解される。

アプリケーションから実データベース1,2上の項目に対してではなく「仮想表定義725(図7)」によって定義される、表名が「VT1」でマップ名(MAPNAME)がVMAP3というマッピングにより定義される仮想表である仮想表702(図7)上の項目ic1?ic5を参照する問い合わせ処理要求である「問合せ1 901」が発行され、
問合せ生成部(109)は、この「問合せ1 901」の条件「ic2＜=10」と「ic4＞=10」を、「仮想表定義725(図7)」によって定義されるマッピングの定義情報に従って、実データベース1のテーブルT1の項目c2に対する「c2＜=10」と実データベース2のテーブルT2の項目c5に対する「c5＞=10」にプッシュダウンされ、
問合せ実行部の問合せ処理の実行によって実データベース1,2から得られたデータは、必要に応じてデータ型、値変換部114でデータをクライアントの要求する形式に変換し、結果127としてクライアントに返して問合せ処理を終了する。
なお、「問合わせ1 901」だけでなく図9の「問合わせ3 903」についても、上記と同様の処理がなされる(【0026】)。

ウ 引用発明
以上のことを総合勘案すれば、引用発明(刊行物1記載された発明)として,下記の発明を認めることができる。

記(引用発明)
ｐ :アプリケーションを実行するクライアントからの問合せを受け付け、該問合せに対する結果を該クライアントに返す問合せ処理システム、特に、複数データベースヘの統合アクセスを実現する問合せ処理システム(データ処理システム)であって、
データ処理システムは、
ｑ :アプリケーションに提供する仮想表と、
ｒ :前記仮想表の定義を行うインタフェース手段を有し、該仮想表を管理する仮想表管理部と、
ｓ :前記問合せを解析する問合せ解析部と、
ｔ :該問合せ解析部で解析された問合せから、仮想表の定義を用いて前記データベースを参照するデータベース参照問合せを生成する問合せ生成部と、
ｕ :問合せ生成部で生成された前記データベースへの問合せ処理を実行する問合せ実行部と、
ｖ :データ型、値変換部とを有し、
ｗ :仮想表と実データベースが存在する図7の環境であって、仮想表定義725でサーバ1に接続されている実データベース1内のテーブルT1と、サーバ1とは異なるサーバ2に接続されている実データベース2内のテーブルT2の項目が仮想表702にマッピングされている環境において、
ｘ :アプリケーションからは仮想表上の項目を参照し、データベース上の項目に対してではなく仮想表上の項目に対して、問い合わせ処理要求として「問合わせ1 901」を発行しこれにより、アプリケーションから複数データベースへのアクセスを隠蔽できるようになっており、
ｔ1:問合せ生成部は選言問合せ処理を該実データベースで実行するように処理をプッシュダウンする問合せ書き替えを行うものであり、
ｔ2:「問合せ1 901」:「SELECT ic1,ic4,ic5 FROM VT1 WHERE ic2＜=10 AND ic4＞=10;」が投入されたとすると、
問合せ生成部は、この「問合せ1 901」の条件「ic2＜=10」と「ic4＞=10」を、仮想表定義725によって定義されるマッピングの定義情報に従って、実データベース1のテーブルT1の項目c2に対する「c2＜=10」と実データベース2のテーブルT2の項目c5に対する「c5＞=10」にプッシュダウンし、
ｙ :問合せ実行部の問合せ処理の実行によって実データベース1,2から得られたデータは、必要に応じてデータ型、値変換部114でデータをクライアントの要求する形式に変換し、結果127としてクライアントに返して問合せ処理を終了する問合せ処理システム。

ｗ1 :但し、仮想表定義725は、
「CREATE MAPPING VT1(ic1 INT, ic2 INT, ic3 INT, ic4 INT, ic5 INT) AS
SELECT c1,c2,c3,c5,c6
FROM T1,T2 WHERE c3=c4
MAPNAME VMAP3;」であって
ｗ2:マッピング定義情報と、マッピングによる仮想表の定義情報とを含み、
マッピング定義情報として、
マップ名(MAPNAME)がVMAP3であるマッピングが、
実データベース1のテーブルT1及び実データベース2のテーブルT2から表名が「VT1」である仮想表へのマッピングであって、
仮想表「VT1」の項目「ic1」?「ic5」(INT型)は、それぞれ、実データベース1のテーブルT1の項目「c1」?「c3」及び実データベース2のテーブルT2の項目「c4」?「c6」と対応するようにマッピングされること、を定義するとともに、
マッピングによる仮想表の定義情報として、
(マップ名(MAPNAME)がVMAP3というマッピングにより定義されるものであって、)
表名が「VT1」、項目が「ic1」?「ic5」(INT型)である仮想表(「仮想表702(図7)」)であること、を定義するものである。

[3]本願発明と引用発明との対比(対応関係)

(1)本願発明(構成要件の分説)

本願発明は,以下のように要件A?Gに分説することができる。
本願発明(分説)
A 異なる複数のデータベースそれぞれのデータ構造を定義したデータモデル(以下「物理モデル」という)と、利用側アプリケーションごとに定義された、前記複数のデータベースのデータに関する、当該利用側アプリケーションから参照されるデータ構造を定義したデータモデル(以下「論理モデル」という)と、前記論理モデルと前記物理モデルとの前記データ構造の対応関係を定義したマッピング定義情報を記憶した記憶部と、
B 前記利用側アプリケーションから前記論理モデルに対する検索条件を受信し、該受信した検索条件を前記物理モデル、前記論理モデル、および前記マッピング定義情報から物理モデルに対する検索条件に変換する第一変換部と、
C 前記第一変換部によって変換された前記物理モデルへの検索条件に一致するデータを前記複数のデータベースから収集する収集部と、
D 前記収集した物理モデルのデータを前記物理モデル、前記論理モデル、及び前記マッピング定義情報に基づいて論理モデルのデータに変換する第二変換部と、
E 前記第二変換部によって変換された論理モデルのデータを出力する出力部と、
を備えたことを特徴とする
F データ統合装置。

(2)本願発明と引用発明との対比(対応関係)

本願発明の各構成要件について,引用発明と対応する。

対比の前に、本願発明の「データベース」、「データ構造を定義したデータモデル」、「物理モデル」、「論理モデル」、「異なる複数のデータベースそれぞれのデータ構造を定義したデータモデル(以下「物理モデル」という)」、「該受信した検索条件を前記物理モデル、前記論理モデル、および前記マッピング定義情報から物理モデルに対する検索条件に変換する第一変換部」の解釈について検討するに、
・請求項1の従属項である請求項2には、「前記物理モデルは、前記情報源のデータ構造に基づいて定義される表の名前(以下「表名」という)ごとに、項目を示すデータ列の名前(以下「列名」という)と当該項目のデータ値の型(以下「データ型」という)から構成されるデータモデルであり、前記論理モデルは、利用側アプリケーションごとに定義した統合された表の構造として、表名ごとに列名とデータ型から構成されるデータモデルであり」と記載され、
明細書には、「図3は、表の構造(スキーマ)の一例を示す説明図である。図3において、301は表のスキーマであり、表名=表Aと各列の列名、型、制約を示しており、302は、上記301のスキーマに基づく実際の表Aを示している。」(【0056】)、「物理モデル111の表および列」,「論理モデル112の表および列」(【0100】)と記載されていること、
・上記「表名」のような「(どの表か)表を識別する情報」と、例えば、その表の列項目名(列名)や型のような「その表を構成する列の属性情報」が分かれば特定の表が特定の構造であることがわかる、つまり、「表を識別する情報」と「その表を構成する列の属性情報」からなるデータは、「表のデータ構造を定義した」ものとなっていること、
からすれば、
本願発明の上記「データベース」とは「表」(のデータベース)を含んでいうものであり、
上記「データ構造を定義したデータモデル」とは、「表を識別する情報とその表を構成する列の属性情報とからなる」データモデルを含んでいうものと解される。

そして、「物理モデル」、「論理モデル」とは、明細書の【0044】「図2-1において、実線は表の実体を示し、破線は仮想的な表を示す。」に照らせば、「実体の表のデータモデル」、「仮想表のデータモデル」と含むものと解される。

また、「異なる複数のデータベースそれぞれのデータ構造を定義したデータモデル(以下「物理モデル」という)」(を記憶した記憶部)は、
・その「それぞれのデータ構造を定義したデータモデル」との記載ぶり、
・明細書の【0037】?【0044】中の「物理モデル111」、特に【0044】「物理モデル111の各テーブル241?243」(【0044】)と図2-1に照らせば、
1つの「データモデル」が、異なる複数のデータベースのデータ構造の定義情報(上記アから、「表を識別する情報とその表を構成する列の属性情報とからなる型データ」と解される。)を有していて、これを記憶部に記憶することを特定するものと解される。
つまり、「異なる複数のデータベースそれぞれのデータ構造を定義したデータモデル(以下「物理モデル」という)」は、「異なる複数のデータベースそれぞれのデータ構造を定義した1のデータモデル(以下「物理モデル」という)」と解される。

さらに、「該受信した検索条件を前記物理モデル、前記論理モデル、および前記マッピング定義情報から物理モデルに対する検索条件に変換する第一変換部」については、次のように解される。
すなわち、「第一変換部」についての上記記載は、その字義からすれば、検索条件の変換は、「前記物理モデル」と「前記論理モデル」と「前記マッピング定義情報」とから行われると読めるが、
「マッピング定義情報」は、そもそも、要件Aで「前記論理モデルと前記物理モデルとの前記データ構造の対応関係を定義した」ものであって、「物理モデル」のデータ構造と「論理モデル」のデータ構造(情報)を含んでいるものであるから、「マッピング定義情報」に基づいて行われれば、自ずと、「物理モデル」と「論理モデル」に基づいて行われることにもなっていると解される。
また、このことは、【0061】に「 図5は、統合エンジンのアーキテクチャ(マッピングの定義)を示す説明図である。マッピングの定義は、たとえば図1に示したメタ情報整備機能117のオペーレーションとして実行される。マッピングの定義は、定義済みの物理モデルに基づいて、論理モデルを定義するものである。」とあるように、「論理モデル」は「マッピングの定義」によって定義されるものでもあり、「マッピング定義情報」は、「物理モデル」に基づいているものとされていることからも理解されることであるし、
明細書の段落【0079】に「 図12のフローチャートにおいて、まず、論理モデルに対する検索式とマッピング定義によって、物理モデルの検索式を作成する(ステップS1201)。」とあることからも、理解されることである。

以上を踏まえて、以下、対比する。

ア 要件Aについて

ア-1 要件Aの「異なる複数のデータベースそれぞれのデータ構造を定義したデータモデル(以下「物理モデル」という)」(を記憶した記憶部を備える)について

引用発明の「問合せ処理システム(データ処理システム)」は、
ｑ「アプリケーションに提供する仮想表」と、ｒ「前記仮想表の定義を行うインタフェース手段を有し、該仮想表を管理する仮想表管理部」を有するものであるから、ｗ、ｗ1、ｗ2の「仮想表定義725」を作成していると理解されるところ、
その作成には、前提として、「問合せ処理システム」が、「実データベース1のテーブルT1」を識別できることと、「実データベース1のテーブルT1」が「c1」、「c2」,「c3」という項目名の列を有していることを知識として有していることが必要であることは明らかである。したがって、上記「問合せ処理システム」が、「実データベース1のテーブルT1」についての「表を識別する情報とその表を構成する列の属性情報」を知識として有していることは明らかである。そして、これらを合わせた情報が表の構造を定義するデータモデルを示していることは、当業者に明らかである。そして、知識として有しているのであるから、これを(当然に備えているといえる)記憶部に記憶していると普通に想定される。
すなわち、引用発明は、データベース(T1)のデータ構造を定義したデータモデル(物理モデル)を記憶部に記憶しているということができる。
このことは、「実データベース2のテーブルT2」についても同様であり、かつ、テーブルT1とテーブルT2は実体のある異なる複数の表であることは明らかであるから、引用発明は、データベース(T1)とは異なるデータベース(T2)のデータ構造を定義したデータモデル(物理モデル)も記憶部に記憶しているということができる。
もっとも、それらデータモデルは、実体の表ごとに別異に存在していると想定されるに止まり、1つのデータモデルが実体の表T1とT2の構造を定義するデータを有しているとまではいえない。
つまり、引用発明は、異なる複数のデータベースそれぞれのデータ構造を定義した、それぞれ別異のデータモデル(物理モデル)を記憶した記憶部、を備えている、ものということができる。
そうすると、本願発明と引用発明は、
「異なる複数のデータベースそれぞれのデータ構造を定義した(1つ又はそれぞれ別異の)データモデル(以下「物理モデル」という)を記憶した記憶部」を備える点で一致するものの、
記憶部に記憶する上記(1つ又はそれぞれ別異の)データモデル(以下「物理モデル」という)が、
本願発明では、1つのデータモデル(物理モデル)であるのに対して、
引用発明では、それぞれ別異のデータモデル(物理モデル)である点で相違する。

ア-2 要件Aの「利用側アプリケーションごとに定義された、前記複数のデータベースのデータに関する、当該利用側アプリケーションから参照されるデータ構造を定義したデータモデル(以下「論理モデル」という)」(を記憶した記憶部を備える)について

上記Aのデータモデル(論理モデル)が、「利用側アプリケーションごとに定義された、前記複数の「表」のデータに関する、当該利用側アプリケーションから参照される「表を識別する情報とその表を構成する列の属性情報とからなる仮想表のデータモデル」(を記憶した記憶部)を含むと解されるのは上記のとおりである。

引用発明の「問合せ処理システム(データ処理システム)」は、
ｑ「アプリケーションに提供する仮想表」を有し、ｗ「仮想表と実データベースが存在する図7の環境であって、仮想表定義725でサーバ1に接続されている実データベース1内のテーブルT1と、サーバ1とは異なるサーバ2に接続されている実データベース2内のテーブルT2の項目が仮想表702にマッピングされている環境」であることから、当然、ｗ1、ｗ2の「仮想表定義725」を記憶する記憶部を備えているといえるところ、
「仮想表定義725」は、「マッピングによる仮想表の定義情報」として、ｗ2「(マップ名(MAPNAME)がVMAP3というマッピングにより定義されるものであって、)
表名が「VT1」、項目が「ic1」?「ic5」(INT型)である仮想表(「仮想表702(図7)」)であること、を定義するもの」を含んでおり、ここで、仮想表がセットされ、定義されている。
すなわち、その「VT1」は仮想表を識別するデータであり、項目「ic1」?「ic5」(INT型)は、その仮想表「VT1」を構成する列の属性情報であるから、これらは、「表を識別する情報とその表を構成する列の属性情報とからなる」「型データ(データモデル)」といえ、したがって、「データ構造を定義したデータモデル(論理モデル)」がセットされており、「データ構造を定義したデータモデル(論理モデル)」を「記憶する記憶部」を備えている、ということができる。

また、引用発明において、ｘ「アプリケーションからは仮想表上の項目を参照しデータベース上の項目に対してではなく仮想表上の項目に対して、問い合わせ処理要求として「問合わせ1 901」を発行」するものであるから、上記「仮想表定義725」に含まれる「表名「VT1」、項目「ic1」?「ic5」」は、「アプリケーションからから参照される」ことができるようになっているものである。また、このことからみても、それら「表名「VT1」、項目「ic1」?「ic5」(INT型)」は、仮想表定義情報として、参照され得るように記憶されているということができる。
また、それらは、「実データベース1のテーブルT1の項目「c1」?「c3」及び実データベース2のテーブルT2の項目「c4」?「c6」」に関するものであるから、要件Aの「前記複数のデータベース(表)のデータに関する」ものである。

そうすると、引用発明も、要件Aの上記「前記複数のデータベースのデータに関する、利用側アプリケーションから参照されるデータ構造を定義したデータモデル(以下「論理モデル」という)」「を記憶した記憶部を備える」といえ、この点において、本願発明と相違しない。
もっとも、引用発明では、「利用側アプリケーションごとに定義された、」とはしておらず、この点、本願発明とは相違する。

ア-3 「前記論理モデルと前記物理モデルとの前記データ構造の対応関係を定義したマッピング定義情報を記憶した記憶部と」(を備える)について

要件Aの「前記論理モデルと前記物理モデルとの前記データ構造の対応関係を定義したマッピング定義情報」は、
明細書の【0100】の「物理モデル111の表および列から論理モデル112の表および列への対応関係を示すマッピング定義を定義するように構成し、」という記載と、上述した「物理モデル」・「論理モデル」についての解釈に照らせば、
「実体の表のデータモデルの表および列から、これに対応する仮想表のデータモデルの表及び列への対応関係を定義する」情報とを含むと解されるところ、
引用発明のｗ1の「仮想表定義725」が含むｗ2のマッピング定義情報は、テーブルT1の項目「c1」?「c3」及びテーブルT2の項目「c4」?「c6」から仮想表「VT1」の項目「ic1」?「ic5」(INT型)への対応関係を定義するものであるから、実体の表のデータモデルと仮想表のデータモデルとの対応関係を定義したマッピング定義情報といえ、記憶部に記憶されていると当然に想定されるものである。
したがって、引用発明も、要件Aの上記「前記論理モデルと前記物理モデルとの前記データ構造の対応関係を定義したマッピング定義情報」「を記憶した記憶部を備える」といえ、この点において、本願発明と相違しない。

ア-4 まとめ(要件A)
以上によれば、
本願発明と引用発明とは、
異なる複数のデータベースそれぞれのデータ構造を定義した1つ又はそれぞれ別異のデータモデル(以下「物理モデル」という)と、前記複数のデータベースのデータに関する、利用側アプリケーションから参照されるデータ構造を定義したデータモデル(以下「論理モデル」という)と、前記論理モデルと前記物理モデルとの前記データ構造の対応関係を定義したマッピング定義情報を記憶した記憶部(を備え)の点で一致し、
記憶部に記憶する上記1つ又はそれぞれ別異のデータモデル(以下「物理モデル」という)が、
本願発明では、1つのデータモデル(物理モデル)であるのに対して、
引用発明では、それぞれ別異のデータモデル(物理モデル)である点、
および、
上記利用側アプリケーションから参照されるデータ構造を定義したデータモデル(以下「論理モデル」という)が、
本願発明では、利用側アプリケーションごとに定義されたデータモデル、とするのに対して、
引用発明では、そうとはしていない点
で相違する。

イ 要件Bについて
要件B「前記利用側アプリケーションから前記論理モデルに対する検索条件を受信し、該受信した検索条件を前記物理モデル、前記論理モデル、および前記マッピング定義情報から物理モデルに対する検索条件に変換する第一変換部と、」

イ-1 「前記利用側アプリケーションから前記論理モデルに対する検索条件を受信し」とする構成について

引用発明のｘ「アプリケーションからは仮想表上の項目を参照し、データベース上の項目に対してではなく仮想表上の項目に対して、問い合わせ処理要求として「問合わせ1 901」を発行しこれにより、アプリケーションから複数データベースへのアクセスを隠蔽できるようになっており」、
ｔ2の「問合せ1 901」:「SELECT ic1,ic4,ic5 FROM VT1 WH
ERE ic2＜=10 AND ic4＞=10;」が投入される」構成は、
上記イ-1の「前記利用側アプリケーションから前記論理モデルに対する検索条件を受信し」に相当する構成ということができることは、これまでの検討から明らかである。

イ-2 「該受信した検索条件を前記物理モデル、前記論理モデル、および前記マッピング定義情報から物理モデルに対する検索条件に変換する第一変換部と、」について

引用発明のｔ1「問合せ生成部は選言問合せ処理を該実データベースで実行するように処理をプッシュダウンする問合せ書き替えを行うものであり」、ｔ2の「問合せ生成部は、この「問合せ1 901」の条件「ic2＜=10」と「ic4＞=10」を、仮想表定義725によって定義されるマッピングの定義情報に従って、実データベース1のテーブルT1の項目c2に対する「c2＜=10」と実データベース2のテーブルT2の項目c5に対する「c5＞=10」にプッシュダウンし、」の構成は、
上記イ-2の「該受信した検索条件を」「前記マッピング定義情報から」実体の表の「表を識別する情報」と「その表を構成する列の属性情報」からなるデータモデル(物理モデル)に対する検索条件に変換する」ものであるといえるところ、その変換は、上記のとおり、自ずと「物理モデル」と「論理モデル」に基づいて行われることにもなっていると解される。
そうすると、引用発明は、上記イ-2の「該受信した検索条件を前記物理モデル、前記論理モデル、および前記マッピング定義情報から物理モデルに対する検索条件に変換する第一変換部」に相当する構成を備えている。

イ-3 まとめ
以上によれば、要件Bにおいて、引用発明は本願発明と相違しない。

ウ 要件C、D,Eついて
要件C「前記第一変換部によって変換された前記物理モデルへの検索条件に一致するデータを前記複数のデータベースから収集する収集部と、」
要件D「前記収集した物理モデルのデータを前記物理モデル、前記論理モデル、及び前記マッピング定義情報に基づいて論理モデルのデータに変換する第二変換部と、」
要件E「前記第二変換部によって変換された論理モデルのデータを出力する出力部と、
を備えた」について

引用発明のｙの「問合せ実行部の問合せ処理の実行によって実データベース1,2から」「データ」を得る構成は、上記要件C「前記第一変換部・・・収集部」に相当する構成ということができる。
引用発明のｙの上記により「得られたデータは、必要に応じてデータ型、値変換部114でデータをクライアントの要求する形式に変換」する構成は、「前記収集した物理モデルのデータを」「前記マッピング定義情報に基づいて論理モデルのデータに変換する第二変換部」に相当する構成といえるところ、上記ウ-2で説示したと同様、その変換は、「前記物理モデル、前記論理モデル、及び前記マッピング定義情報に基づいて」いるともいえ、したがって、引用発明の上記ｙの「得られたデータは、・・・形式に変換」する構成は、要件D「前記収集した物理モデルの・・・第二変換部」に相当する構成ということができる。
引用発明のｙの、「変換」したデータを「結果127としてクライアントに返」す構成は、要件E「前記第二変換部によって変換された論理モデルのデータを出力する出力部」に相当する構成ということができる。
以上、要件C,D,Eにおいて、本願発明と引用発明とは相違しない。

エ 要件F「データ統合装置」について
引用発明の「問合せ処理システム(データ処理システム)」が、「データ統合装置」といい得ることは、ｐの「複数データベースヘの統合アクセスを実現する」装置といい得ることから明らかである。

[4]一致点,相違点
以上の対比結果によれば,本願発明と引用発明との一致点,相違点は次のとおりであることが認められる。

[一致点]
A’異なる複数のデータベースそれぞれのデータ構造を定義した(1つ又はそれぞれ別異の)データモデル(以下「物理モデル」という)と、前記複数のデータベースのデータに関する、利用側アプリケーションから参照されるデータ構造を定義したデータモデル(以下「論理モデル」という)と、前記論理モデルと前記物理モデルとの前記データ構造の対応関係を定義したマッピング定義情報を記憶した記憶部と、
B 前記利用側アプリケーションから前記論理モデルに対する検索条件を受信し、該受信した検索条件を前記物理モデル、前記論理モデル、および前記マッピング定義情報から物理モデルに対する検索条件に変換する第一変換部と、
C 前記第一変換部によって変換された前記物理モデルへの検索条件に一致するデータを前記複数のデータベースから収集する収集部と、
D 前記収集した物理モデルのデータを前記物理モデル、前記論理モデル、及び前記マッピング定義情報に基づいて論理モデルのデータに変換する第二変換部と、
E 前記第二変換部によって変換された論理モデルのデータを出力する出力部と、
を備えたことを特徴とする
F データ統合装置。

[相違点]
[相違点1]
A’の「記憶部」に記憶する「異なる複数のデータベースそれぞれのデータ構造を定義した1つ又はそれぞれ別異のデータモデル(以下「物理モデル」という)」が、
本願発明では、1つのデータモデル(物理モデル)であるのに対して、
引用発明では、それぞれ別異のデータモデル(物理モデル)である点、
[相違点2]
A’の「記憶部」に記憶する「利用側アプリケーションから参照されるデータ構造を定義したデータモデル(以下「論理モデル」という)」が、
本願発明では、利用側アプリケーションごとに定義されたデータモデル、とするのに対して、
引用発明では、そうとはしていない点

[5]相違点等の判断

(1)[相違点の克服]
引用発明を出発点とし,
引用発明の、「記憶部」に記憶する「異なる複数のデータベースそれぞれのデータ構造を定義したそれぞれ別異のデータモデル(物理モデル)」を、「異なる複数のデータベースそれぞれのデータ構造を定義した1つのデータモデル(物理モデル)」とし(以下、「相違点1の克服という」)、
引用発明の、「利用側アプリケーションから参照されるデータ構造を定義したデータモデル(以下「論理モデル」という)」を、利用側アプリケーションごとに定義されたデータモデルとする(以下、「相違点2の克服」という)こと(合わせて「相違点の克服」という)で、上記[相違点]は克服され,本願発明に到達する。

(2)[相違点の克服]の容易性判断

ア [相違点1の克服]について
引用発明は、複数のデータベース(実データベース1のテーブルT1と実データベース2のテーブルT2)を(仮想的に)統合する「仮想表定義725」を作成するものであるところ、その作成上、統合すべき又は統合が想定される複数のデータベースのデータ構造はまとめて1つのモデルとして記憶する方が便利であることは明らかであることからすれば、上記[相違点1の克服]は、当業者が容易に想到し得ることである。
さらに、異なる複数の表(データベース)の構造定義を1つのデータモデルに格納することはごく普通のことにすぎない｛例えば、下記周知例1(図4,【0005】?【0014】,特に【0013】【0014】),周知例2(図4,【0037】?【0045】)参照｝ことからみても、上記[相違点1の克服]は、当業者が容易に想到し得ることである。

イ [相違点2の克服]について
以下の事情からすれば、上記[相違点2の克服]も、当業者が容易に想到し得ることである。
引用発明では、「仮想表定義725」によってT1とT2を仮想的に統合しているが、T1とT2の組み合わせとは異なる複数のデータベースを統合しようとすることも当業者にごく普通に想定されるところ、
仮想表定義を用いるデータベースの統合技術は、そもそも、複数の個別データベースにアクセスするために個別アプリケーションを利用する欠点を解消するために考案されたものであること(刊行物1の段落【0002】,【0003】)からすれば、1のアプリケーションから当該複数の個別データベースを仮想統合する特定の1の仮想表定義を利用して当該複数の個別データベースへの透過アクセスを行うものが想定されるのであり、
このことからすれば、上記のようにT1とT2の組み合わせとは異なる複数の個別データベースを統合しようとする際には、別の仮想表定義を用いる別のアプリケーションとすることが、まず想起される。
また、アプリケーション毎に「表」を定義することは、ごく一般的である(例えば、下記周知例2の【0047】?【0049】、特に【0047】参照)。
これらのことからすれば、上記[相違点2の克服]も、当業者が容易に想到し得ることであるというべきである。

記(周知例)
○周知例1:特開平9-245048号公報(【0013】【0014】のみ摘示)
【0013】データの定義とは、リレーショナルデータモデルを構成する表を定義することをいう。表は図4に符号7a,7b,7c,…で示すように、リレーショナルデータモデル3に格納されており、各表は一定のデータの集まりを格納している。表の各列8は項目と呼ばれ、一定の属性のデータを格納している。また、表の各行9はレコードと呼ばれ、複数のの属性を有するデータの集まりとなっている。
【0014】データの定義では、上記個々の表を定義する。具体的には、表の構造を定義することであり、表の名前、各項目の属性名、データ型の割り当て、インデックスの作成等を指定する(CREATE文)。

○周知例2:特開2002-7177号公報
【0037】図4は,マルチデータベース定義手段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などの属性を保持する。DB表宣言名164とは,統合スキーマ内でユニークに与えられるDB表の別名であり,異なるDB間で表名が同一のDB表がある場合に,これらを一意に識別するために用いられる。本実施例では,DB表161がDB表宣言名164を保持する点に特徴がある。DB表161は,複数のDB表カラム162を包含する構成である。
【0042】DB表カラム162は,DB表161が包含するカラムに関するデータ項目であり,DB表内でユニークなカラム名,カラムのデータ型,データ長,データのスケール(位取り),NULL可であるか,主キーであるか,外部キーであるか,といった属性を持つ。また,DB表カラム162は,一つの共通DB表カラム163を包含する構成である。
【0043】共通DB表カラム163は,DB表カラム162をマルチデータベースサーバ10のデータ型(以下,共通データ型と呼ぶ)に対応付けるための情報を保持するデータ項目である。DB表カラム162は,各DBMSごとに異なるデータ型(以下,要素データ型と呼ぶ)を持つため,マルチデータベースサーバ10ではこれを共通データ型に統一する必要がある。・・・(以下略)
【0045】要素スキーマ24は,DB表161とDB表カラム162から構成され,各DBシステム情報160単位に管理される。本実施例では,DB表カラム162が共通DB表カラム163を包含する構成となっている点に特徴がある。共通DB表カラム163は,概念的には,要素スキーマ間の差異を吸収するスキーマ・アダプタとして機能する。
【0047】APシステム情報170は,マルチデータベースサーバ10がAPごとに外部スキーマ44を管理するために必要なデータ項目であり,統合スキーマ12内でユニークなAP名などの属性を保持する。APシステム情報170は,複数の仮想表171とレプリカ表181を包含する構成である。

ウ まとめ
以上によれば、引用発明を出発点とし,
引用発明の、「記憶部」に記憶する「異なる複数のデータベースそれぞれのデータ構造を定義したそれぞれ別異のデータモデル(物理モデル)」を、「異なる複数のデータベースそれぞれのデータ構造を定義した1つのデータモデル(物理モデル)」とし、
引用発明の、「利用側アプリケーションから参照されるデータ構造を定義したデータモデル(以下「論理モデル」という)」を、利用側アプリケーションごとに定義されたデータモデルとすることで、本件発明に至ることは、当業者が容易になし得たことである。

エ 補足(予備的検討)
上記[3]対比の(2)「イ-2」において、引用発明の「仮想表定義725」に含まれる「マッピングによる仮想表の定義情報」の「VT1」と項目「ic1」?「ic5」(INT型)は、「データ構造を定義したデータモデル(論理モデル)」に相当すると判断したが、
仮に、「仮想表定義725に含まれる「マッピングによる仮想表の定義情報」は、あくまで「マッピング定義情報」であって、これとは別の「論理モデル」ではないから、本願発明の「論理モデル」とはいえない」とした場合についても、念の為検討しておく。
仮にそうであったとしても、上記「イ-2」でも言及したように、引用発明では、ｘ「アプリケーションからは仮想表上の項目を参照しデータベース上の項目に対してではなく仮想表上の項目に対して、問い合わせ処理要求として「問合わせ1 901」を発行しこれにより、アプリケーションから複数データベースへのアクセスを隠蔽できるようになって」いて、アプリケーションからは、実データベースは遮蔽され「仮想表」と仮想表上の「項目」だけから、希望する「問合わせ」(引用発明の「問合わせ1 901」や「問合わせ3 903」(刊行物1【0026】)が発行されるようになっているのであるから、マッピング定義や実データベースの情報も含まれる「仮想表定義725」とは別に、仮想表とその項目を特定する「仮想表の定義情報」(「VT1」と項目「ic1」?「ic5」(INT型))を用意し提供するようにすることは自然でありかつ便利であることは当業者に自明である。
すなわち、当業者であれば、アプリケーションから参照される仮想表定義情報(論理モデル)を、マッピング定義や実データベースの情報も含まれる「仮想表定義725」とは別に具備する構成とすることは容易に想到し得ることと言うべきである。
したがって、仮に、上記のように「仮想表定義725に含まれる・・・本願発明の「論理モデル」とはいえない」といえたとしても、このことにより、本願発明が進歩性があるとはできない。

(3)まとめ(相違点等の判断)
以上,引用発明を出発点として,上記[相違点の克服]をすることで,本願発明に構成に達するところ,同克服は,刊行物1及び周知事項に基づいて当業者が容易になし得ることである。
効果についてみても,構成の採用に伴って予測し得ない格別顕著なものがあるとも認められない。

【第4】むすび

以上のとおり,本願の請求項1に係る発明は,上記刊行物1に記載された発明及び技術常識に基づいて当業者が容易に発明をすることができたものであるから,特許法第29条第2項の規定により特許を受けることができない。
それ故,本願の他の請求項について検討するまでもなく,本願は拒絶すべきものである。

よって,結論のとおり審決する。
 
審理終結日 2015-01-23 
結審通知日 2015-01-27 
審決日 2015-02-09 
出願番号 特願2012-250730(P2012-250730)
審決分類 P 1 8・ 121- Z (G06F)
最終処分 不成立  
前審関与審査官 野田 佳邦  
特許庁審判長 小曳 満昭
特許庁審判官 乾 雅浩
千葉 輝久
発明の名称 データ統合装置、データ統合方法およびデータ統合プログラム  
代理人 酒井 昭徳  

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