【事件の表示】
　特願２００２−５７８１９５「分散データベースに対して協調アクセスを必要とするクエリ処理の方法およびシステム」拒絶査定不服審判事件〔平成１４年１０月１０日国際公開、ＷＯ０２／８００４１、平成１６年１０月　７日国内公表、特表２００４−５３０９７７〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１　手続の経緯
　本願は、２００２年３月２９日（パリ条約による優先権主張外国庁受理　２００１年３月３０日　米国）を国際出願日とする出願であって、平成２０年４月２日付けで拒絶査定がなされ、これに対し、同年７月３日付けで拒絶査定不服審判が請求され、同年８月４日付けで手続補正がなされ、当審において、平成２１年１１月１０日付けで審尋がなされ、平成２２年５月１３日付けで回答書が提出され、同年１２月２７日付けで拒絶理由通知がなされ、平成２３年７月４日付けで手続補正がなされたものである。
　
第２　本願発明
　
　本願の請求項１に係る発明（以下、「本願発明」という。）は、平成２３年７月４日付けの手続補正により補正された特許請求の範囲の請求項１に記載された次のとおりのものである。 
「　複数のデータソースをその中に有するデータベースプールと通信しているシステムにおいて、前記各データソースにはデータのそれぞれの種別の情報が入っており、前記システムに対するユーザクエリを処理する方法は、
　所定のフォーマットで単一のユーザクエリを電子的ネットワーク経由で受信するステップと、
　前記所定のフォーマットに従って前記ユーザクエリを構文解析することによって前記クエリを満たすために必要とされるデータの複数の種別を判定するステップと、
　前記判定されたデータの種別を用いてクエリマップ構造を検索することによって複数のサブクエリを生成するステップと、
　前記データの複数の種別を用いて前記クエリマップ構造を検索することによって前記複数のデータソースから複数の目標のデータソースを識別するステップと、
　前記複数のサブクエリを対応するそれぞれの目標のデータソースに発行することによって前記複数の目標のデータソースからデータを取り出すステップと、
　前記取り出されたデータを前記データの複数の種別に応じて組み合わせて、前記クエリに対する単一の応答を生成するステップと、
　前記ユーザへ前記応答を返すステップと
　を備え、
　前記ユーザクエリは、前記ユーザの金融取引に関する情報に対する要求を備えることを特徴とする方法。」
　
第３　引用例
　
１．特開平１０−４９４１０号公報
　
　特開平１０−４９４１０号公報（以下、「引用例１」という。）には、次の事項が記載されている。
Ａ．「【０００１】
【発明の属する技術分野】本発明は、異なる種類の複数のデータベースを、ネットワークを介して検索する異種データベースアクセス装置に関する。」
　
Ｂ．「【０００８】
【発明が解決しようとする課題】本発明の第１の目的は、データベースの種類やデータの種類によらず共通のアクセスインタフェースにより、かつ、どのローカルデータベースにアクセスすべきかをアプリケーションプログラムが意識することなく、アプリケーションプログラムが複数の異種データベースにアクセスすることが可能なデータベースアクセス装置を提供することである。」
　
Ｃ．「【００１２】
【発明の実施の形態】本発明の請求項１と請求項２に記載の発明は、次の作用を有する。  アプリケーションプログラムから異種データベースアクセス装置への問い合わせは、データ構造格納領域に定義されているデータ構造単位に対して行なえば良いことになる。アクセスすべきローカルデータベースの特定、各ローカルデータベースに固有な事柄（問い合わせ文の表現法、データ型など）は、データ構造単位の定義情報とローカルデータベースのアクセス手段に盛り込まれるので、本データベースアクセス装置を介してアクセスする場合、どのローカルデータベースにどのようなアクセスするかをアプリケーションプログラムは意識する必要がない。」
　
Ｄ．「【００１８】（実施の形態１）図１は異種データベースアクセス装置の構成図である。１０１は問い合わせ処理手段、１０２はデータ構造定義手段、１０３はデータ構造格納領域、１０４はデータキャッシュ手段、１０５はデータキャッシュ領域、１０６はデータキャッシュ領域検索手段、１０７ａ，ｂ，ｃは複数のローカルデータベースアクセス手段である。」
　
Ｅ．「【００２０】ここでの定義は、各ローカルデータベースに関する情報を持っている、異種データベースアクセス装置の管理者が行なう。図３に論理的なデータ構造単位の定義情報の例を２つ示す。ここでは、論理的なデータ構造単位は１つのテーブルであるとし、テーブル名、カラム名、各カラムのデータ型が定義されている。さらに、アクセス先のローカルデータベースの名前と、図２に示されるローカルデータベースのテーブルへの問い合わせ文も定義情報に含める。
【００２１】図３の問い合わせ文は、アクセスするデータベースがＤＢ１であるかＤＢ２であるかによって問い合わせ文の書式が異なる例である。データ構造格納領域に、複数のデータ構造単位に関する定義情報を格納する。」
　
Ｆ．「【００２６】問い合わせ処理手段は、異種データベースアクセス装置に発せられた問い合わせ文（形式は標準ＳＱＬなどにあらかじめ定めておく。）を解釈し、検索対象のデータ構造単位（図３のテーブル名）と検索条件を明確にする。そして、データ構造格納領域を参照して、検索すべきデータ構造単位のキャッシュデータがデータキャッシュ領域に存在するかを判断する。これは、データ構造格納領域にキャッシュ先の番地が格納されているかで知ることができる。」
　
Ｇ．「【００２９】図５に、異種データベースアクセス装置への問い合わせ文の例を２つ示す。図３のように定義されたデータ構造単位（ここでは、テーブル）に対する問い合わせの例である。これらの問い合わせを発行するユーザあるいはアプリケーションプログラムは、異種データベースアクセス装置上のデータ構造単位（テーブルなど）のみを意識すれば良く、元のデータはどのローカルデータベースに格納されているかを意識する必要がない。」
　
Ｈ．「【００３５】（実施の形態２）図７は異種データベースアクセス装置の構成図である。図１の構成図に、各ローカルデータベースの問い合わせ命令生成手段を追加したものである。
【００３６】ローカルデータベースの問い合わせ命令生成手段は、(1)異種データベースアクセス装置への問い合わせ文で与えられた検索条件、(2)データ構造格納領域に格納されているローカルデータベースへの問い合わせ文、(3)現在のキャッシュデータ、の３条件を基に、現在キャッシュされているデータを除外するような新たな検索条件を付け加えた、ローカルデータベースへの問い合わせ文を生成し、それをローカルデータベースアクセス手段に渡す。
【００３７】図８は、異種データベースアクセス装置への問い合わせ文の例である。図９は、図８の問い合わせ文に対して、ローカルデータベースの問い合わせ命令生成手段により生成される問い合わせ文の例である。主キー（レコードを一意に識別するカラム）であるidの値が3と4のデータが既にデータキャッシュ領域に存在していた場合の例である。
【００３８】図８の問い合わせ文で与えられた検索条件（age  30）に加えて、e_idについての条件が付加されている。
【００３９】図１０は、図８の問い合わせ文を、図７の異種データベースアクセス装置に発行した場合の処理を表すフローチャートである。以下、ステップを示す。
【００４０】まず、アプリケーションプログラムが問い合わせ文を発行する（１００１）。次に、問い合わせ処理手段が、アクセス対象のデータ構造単位と検索条件を明確にし、検索条件を、該当するローカルＤＢ問い合わせ命令生成手段へ（１００２）。次に、該当するデータ構造単位のキャッシュデータがあるかを判断する（１００３）。
【００４１】無い場合は、ローカルＤＢの問い合わせ文生成手段が、検索条件と、データ構造格納領域に格納されている問い合わせ文をもとに、ローカルＤＢへの問い合わせ文を生成し、ローカルＤＢアクセスアクセス手段へ渡す（１００４）。次に、ローカルＤＢアクセス手段が、ローカルＤＢへ問い合わせ文を発行する。そして、受け取った検索結果をデータキャッシュ手段へ渡す（１００５）。
【００４２】次に、データキャッシュ手段が、検索結果をキャッシュ領域へ格納し、データ構造格納領域に格納先番地を設定する（１００６）。次に、問い合わせ処理手段が、キャッシュデータ格納番地と検索条件を、データキャッシュ領域検索手段に渡す（１００７）。次に、データキャッシュ領域検索手段が、データキャッシュ領域を検索し、検索条件に合ったデータを呼出し側へ返す（１００８）。
【００４３】一方、ステップ１００３で、キャッシュデータがある場合、問い合わせ処理手段が、キャッシュデータ格納番地と検索条件を、データキャッシュ領域検索手段に渡す（１００９）。次に、データキャッシュ領域検索手段が、データキャッシュ領域を検索し、既にキャッシュされているデータ（レコード）を特定し、該当するローカルＤＢ問い合わせ命令生成手段へ（１０１０）。
【００４４】次に、ローカルＤＢの問い合わせ文生成手段が、データキャッシュ領域に既に存在しているデータを省いた新たな検索条件を求め、データ構造格納領域に格納されている問い合わせ文をもとに、ローカルＤＢへの問い合わせ文を生成し、ローカルＤＢアクセスアクセス手段へ渡す（１０１１）。次に、ローカルＤＢアクセス手段が、ローカルＤＢへ問い合わせ文を発行する。そして、受け取った検索結果をデータキャッシュ手段へ渡す（１０１２）。
【００４５】次に、データキャッシュ手段が、検索結果をキャッシュ領域へ追加格納する（１０１３）。次に、データキャッシュ領域検索手段が、データキャッシュ領域を検索し、検索条件に合ったデータを呼出し側へ返す。
【００４６】以上のように、本装置を使い、本装置の管理者が論理的なデータ構造単位を定義しておくことで、アプリケーションプログラムの開発者は、ローカルデータベースの種類によらず共通のアクセスインタフェースで、かつ、アクセス先のローカルデータベースがどれであるかを意識することなく、アプリケーションプログラムを開発することができる。さらに、一度アクセスされたデータはデータキャッシュ領域に格納されるので、２回目からの検索は、本装置上のデータキャッシュ領域に対して行なわれるため、ローカルデータベースと本装置の間のデータ通信量を減らすことができる。
【００４７】ここで、実施の形態１と２の違いは以下の通りである。実施の形態１では、データ構造単位（テーブルなど）への問い合わせがあると、該当するデータ構造単位の全データが取得され、データキャッシュ領域に格納される。
【００４８】このため、データキャッシュ領域に格納されているデータが少ない間は、ローカルデータベースと本アクセス装置の間のデータ通信量が多くなる。しかし、実施の形態２では、検索条件に合った部分（レコード）のみが取得され、キャッシュされるので、そのようなことはない。」
　
　上記Ａ．〜Ｈ．及び関連する図面の記載によれば、引用例１には以下の事項が記載されているといえる。
　
（１）上記Ｈ．の「【００３５】（実施の形態２）図７は異種データベースアクセス装置の構成図である。図１の構成図に、各ローカルデータベースの問い合わせ命令生成手段を追加したものである。」の記載、
　図７における、「問い合わせ処理手段」、「データ構造格納領域」、「データキャッシュ手段」、「データキャッシュ領域」、「データキャッシュ領域検索手段」、「ローカルデータベース」、「ＤＢ１アクセス手段」〜「ＤＢ３アクセス手段」、「ＤＢ１問い合わせ命令生成手段」〜「ＤＢ３問い合わせ命令生成手段」の記載、
　上記Ｄ．の「【００１８】（実施の形態１）図１は異種データベースアクセス装置の構成図である。１０１は問い合わせ処理手段、１０２はデータ構造定義手段、１０３はデータ構造格納領域、１０４はデータキャッシュ手段、１０５はデータキャッシュ領域、１０６はデータキャッシュ領域検索手段、１０７ａ，ｂ，ｃは複数のローカルデータベースアクセス手段である。」の記載によれば、
　　実施の形態２に係る異種データベースアクセス装置は、
「データ構造格納領域と、
　問い合わせ処理手段と、
　データキャッシュ手段と、
　データキャッシュ領域と、
　データキャッシュ領域検索手段と、
　複数のローカルデータベースアクセス手段と、
　各ローカルデータベースの問い合わせ命令生成手段」とを備えているといえる。
　　
（２）上記Ｈ．の「【００３５】（実施の形態２）図７は異種データベースアクセス装置の構成図である。図１の構成図に、各ローカルデータベースの問い合わせ命令生成手段を追加したものである。」の記載、
　上記Ｈ．の「【００４７】ここで、実施の形態１と２の違いは以下の通りである。実施の形態１では、データ構造単位（テーブルなど）への問い合わせがあると、該当するデータ構造単位の全データが取得され、データキャッシュ領域に格納される。
【００４８】このため、データキャッシュ領域に格納されているデータが少ない間は、ローカルデータベースと本アクセス装置の間のデータ通信量が多くなる。しかし、実施の形態２では、検索条件に合った部分（レコード）のみが取得され、キャッシュされるので、そのようなことはない。」の記載、
　上記Ｅ．の、実施の形態１に係る「【００２０】・・・（中略）・・・図２に示されるローカルデータベースのテーブル」の記載、
　図２の「ＤＢ１のテーブル例
　　テーブル名：　emp_table1
　　カラム名：    e_id    e_name    age    city    image
　　データ型：    int     char       int     char   blob
 　・・・（中略）・・・
　ＤＢ２のテーブル例
　　テーブル名： EMP_TABLE2
　　カラム名：   EMPNO    ENAME   SAL
　　データ型：   integer      text       integer」の記載によれば、
　実施の形態２の異種データベースアクセス装置は、実施の形態１の異種データベースアクセス装置に問い合わせ命令生成手段を追加して、テーブルを格納したローカルデータベースから取得されるデータを、実施の形態１の「該当するデータ構造単位の全データ」から、「検索条件に合った部分（レコード）のみ」に変更するものである。
　したがって、実施の形態２の異種データベースアクセス装置は、「テーブルを格納した複数のローカルデータベースにアクセス」するものである。
　
（３）前記（２）において記載したとおり、実施の形態２は、実施の形態１の異種データベースアクセス装置に問い合わせ命令生成手段を追加し、ローカルデータベースから取得されるデータを、実施の形態１の「該当するデータ構造単位の全データ」から、「検索条件に合った部分（レコード）のみ」に変更するものであり、データ構造格納領域及び定義情報については変更されていない。
　したがって、実施の形態１のデータ構造格納領域及び定義情報に係る、
　上記Ｅ．の「【００２０】ここでの定義は、各ローカルデータベースに関する情報を持っている、異種データベースアクセス装置の管理者が行なう。図３に論理的なデータ構造単位の定義情報の例を２つ示す。ここでは、論理的なデータ構造単位は１つのテーブルであるとし、テーブル名、カラム名、各カラムのデータ型が定義されている。さらに、アクセス先のローカルデータベースの名前と、図２に示されるローカルデータベースのテーブルへの問い合わせ文も定義情報に含める。
【００２１】図３の問い合わせ文は、アクセスするデータベースがＤＢ１であるかＤＢ２であるかによって問い合わせ文の書式が異なる例である。データ構造格納領域に、複数のデータ構造単位に関する定義情報を格納する。」の記載によれば、
　実施の形態２に係るデータ構造格納領域は、実施の形態１に係るデータ構造格納領域と同様に「データ構造単位のテーブル名と、アクセス先のローカルデータベースの名前と、ローカルデータベースのテーブルへの問い合わせ文とを含んだ、各ローカルデータベースに関する定義情報」を格納するといえる。
　
（４）上記（１）〜（３）を総合すると、引用例１には、
「テーブルを格納した複数のローカルデータベースにアクセスし、
　データ構造単位のテーブル名と、アクセス先のローカルデータベースの名前と、ローカルデータベースのテーブルへの問い合わせ文とを含んだ、各ローカルデータベースに関する定義情報を格納するデータ構造格納領域と、
　問い合わせ処理手段と、
　データキャッシュ手段と、
　データキャッシュ領域と、
　データキャッシュ領域検索手段と、
　複数のローカルデータベースアクセス手段と、
　各ローカルデータベースの問い合わせ命令生成手段と、
　を備えた異種データベースアクセス装置」が記載されているといえる。
　
（５）上記Ｈ．の「【００３９】図１０は、図８の問い合わせ文を、図７の異種データベースアクセス装置に発行した場合の処理を表すフローチャートである。以下、ステップを示す。
【００４０】まず、アプリケーションプログラムが問い合わせ文を発行する（１００１）。」の記載、
　図１０の、ステップ（１００１）〜（１０１３）を含むフローチャートの記載によれば、
　ステップ（１００１）〜（１０１３）の処理方法は、「異種データベースアクセス装置において、アプリケーションプログラムから前記異種データベースアクセス装置に発行された問い合わせ文を処理する方法」といえる。
　
（６）上記Ｈ．の「【００３９】図１０は、図８の問い合わせ文を、図７の異種データベースアクセス装置に発行した場合の処理を表すフローチャートである。以下、ステップを示す。
【００４０】まず、アプリケーションプログラムが問い合わせ文を発行する（１００１）。」の記載、
　図８の「select  id, name,age, image from emp_image where age  30;」の記載、
　上記Ｆ．の、実施の形態１に係る「【００２６】問い合わせ処理手段は、異種データベースアクセス装置に発せられた問い合わせ文（形式は標準ＳＱＬなどにあらかじめ定めておく。）を解釈し、」の記載によれば、
　ステップ（１００１）は、異種データベースアクセス装置が「アプリケーションプログラムから、ＳＱＬ形式の問い合わせ文を受信するステップ」といえる。
　
（７）上記Ｈ．の「【００４０】まず、アプリケーションプログラムが問い合わせ文を発行する（１００１）。次に、問い合わせ処理手段が、アクセス対象のデータ構造単位と検索条件を明確にし、検索条件を、該当するローカルＤＢ問い合わせ命令生成手段へ（１００２）。」の記載、
　上記Ｈ．の「【００３７】図８は、異種データベースアクセス装置への問い合わせ文の例である。」の記載、
　図８の「select  id, name.age, image  from emp_image  where  age  30;」の記載、
　上記Ｈ．の「【００３８】図８の問い合わせ文で与えられた検索条件（age  30）」の記載、
　図３の、実施の形態１に係る「テーブル名：　emp_image」の記載、
　上記Ｅ．の、実施の形態１に係る「【００２０】・・・（中略）・・・ここでは、論理的なデータ構造単位は１つのテーブルであるとし、」の記載によれば、
　ステップ（１００２）は、問い合わせ処理手段が、アプリケーションプログラムから受信したＳＱＬ形式の問い合わせ文に含まれる、アクセス対象のデータ構造単位のテーブル名（図８の「emp_image」）と検索条件（図８の「age  30」）を明確にし、当該検索条件を、該当するローカルデータベースの問い合わせ命令生成手段に送るステップといえる。
　
　さらに、上記Ｃ．の「【００１２】
・・・（中略）・・・アクセスすべきローカルデータベースの特定、各ローカルデータベースに固有な事柄（問い合わせ文の表現法、データ型など）は、データ構造単位の定義情報とローカルデータベースのアクセス手段に盛り込まれるので、本データベースアクセス装置を介してアクセスする場合、どのローカルデータベースにどのようなアクセスするかをアプリケーションプログラムは意識する必要がない。」の記載、
　上記Ｅ．の「【００２０】・・・（中略）・・・図３に論理的なデータ構造単位の定義情報の例を２つ示す。ここでは、論理的なデータ構造単位は１つのテーブルであるとし、テーブル名、カラム名、各カラムのデータ型が定義されている。さらに、アクセス先のローカルデータベースの名前と、図２に示されるローカルデータベースのテーブルへの問い合わせ文も定義情報に含める。」の記載、
図３の「例１
　　　　　　テーブル名：　emp_image
　　　　　　カラム名：　   id       name     age      image 
　　　　　　・・・（中略）・・・
　　　　　　アクセス先：　　ＤＢ１
　　　　　　・・・（中略）・・・
　　　例２
　　　　　　テーブル名： emp_sal
　　　　　　カラム名：     id       sal
　　　　　　・・・（中略）・・・
　　　　　　アクセス先：  ＤＢ２」の記載によれば、
　定義情報は、「アクセスすべきローカルデータベースの特定」のために用いられ、データ構造単位のテーブル名（図３の「emp_image」、「emp_sal」）に対して、アクセス先のローカルデータベースの名前（図３の「ＤＢ１」、「ＤＢ２」）を定義するものである。
　ステップ（１００２）において、問い合わせ処理手段は、検索条件を、該当するローカルデータベースの問い合わせ命令生成手段に送るが、このときに、定義情報を用いて、問い合わせ文に含まれるテーブル名からアクセスすべきローカルデータベースを特定することは明らかである。
　したがって、ステップ（１００２）は、「前記問い合わせ処理手段が、前記アプリケーションプログラムからの前記問い合わせ文に含まれる、アクセス対象のデータ構造単位のテーブル名と検索条件を明確にし、前記定義情報を用いて、前記テーブル名に基づいてアクセスすべきローカルデータベースを特定し、前記検索条件を、前記特定されたローカルデータベースの問い合わせ命令生成手段に送るステップ」といえる。
　
（８）上記Ｈ．の「【００４０】まず、アプリケーションプログラムが問い合わせ文を発行する（１００１）。次に、問い合わせ処理手段が、アクセス対象のデータ構造単位と検索条件を明確にし、検索条件を、該当するローカルＤＢ問い合わせ命令生成手段へ（１００２）。次に、該当するデータ構造単位のキャッシュデータがあるかを判断する（１００３）。
【００４１】無い場合は、ローカルＤＢの問い合わせ文生成手段が、検索条件と、データ構造格納領域に格納されている問い合わせ文をもとに、ローカルＤＢへの問い合わせ文を生成し、ローカルＤＢアクセスアクセス手段へ渡す（１００４）。次に、ローカルＤＢアクセス手段が、ローカルＤＢへ問い合わせ文を発行する。そして、受け取った検索結果をデータキャッシュ手段へ渡す（１００５）。
【００４２】次に、データキャッシュ手段が、検索結果をキャッシュ領域へ格納し、データ構造格納領域に格納先番地を設定する（１００６）。次に、問い合わせ処理手段が、キャッシュデータ格納番地と検索条件を、データキャッシュ領域検索手段に渡す（１００７）。次に、データキャッシュ領域検索手段が、データキャッシュ領域を検索し、検索条件に合ったデータを呼出し側へ返す（１００８）。」の記載によれば、
　上記ステップ（１００３）〜（１００８）は、
「　前記アクセス対象のデータ構造単位のキャッシュデータがあるかを判断するステップ（１００３）と、
　前記アクセス対象のデータ構造単位のキャッシュデータが無い場合、前記特定されたローカルデータベースの前記問い合わせ文生成手段が、前記検索条件と、前記データ構造格納領域に格納されている前記定義情報の前記問い合わせ文とをもとに、前記特定されたローカルデータベースの問い合わせ文を生成し、前記ローカルデータベースアクセス手段へ渡すステップ（１００４）と、
　前記ローカルデータベースアクセス手段が、前記特定されたローカルデータベースへ前記生成された問い合わせ文を発行し、受け取った検索結果を前記データキャッシュ手段へ渡すステップ（１００５）と、
　前記データキャッシュ手段が、前記検索結果を前記キャッシュ領域へ格納し、前記データ構造格納領域に格納番地を設定するステップ（１００６）と、
　前記問い合わせ処理手段が、前記格納番地と前記検索条件を、前記データキャッシュ領域検索手段に渡すステップ（１００７）と、
　前記データキャッシュ領域検索手段が、前記データキャッシュ領域を検索し、前記検索条件に合ったデータを呼出し側へ返すステップ（１００８）」といえる。
　
　上記（１）〜（８）によれば、引用例１には、次の発明（以下、「引用発明」という。）が記載されている。
　
＜引用発明＞
「テーブルを格納した複数のローカルデータベースにアクセスし、
　データ構造単位のテーブル名と、アクセス先のローカルデータベースの名前と、ローカルデータベースのテーブルへの問い合わせ文とを含んだ、各ローカルデータベースに関する定義情報を格納するデータ構造格納領域と、
　問い合わせ処理手段と、
　データキャッシュ手段と、
　データキャッシュ領域と、
　データキャッシュ領域検索手段と、
　複数のローカルデータベースアクセス手段と、
　各ローカルデータベースの問い合わせ命令生成手段と、
　を備えた異種データベースアクセス装置において、アプリケーションプログラムから前記異種データベースアクセス装置に発行された問い合わせ文を処理する方法は、
　アプリケーションプログラムから、ＳＱＬ形式の問い合わせ文を受信するステップ（１００１）と、
　前記問い合わせ処理手段が、前記アプリケーションプログラムからの前記問い合わせ文に含まれる、アクセス対象のデータ構造単位のテーブル名と検索条件を明確にし、前記定義情報を用いて、前記テーブル名に基づいてアクセスすべきローカルデータベースを特定し、前記検索条件を、前記特定されたローカルデータベースの問い合わせ命令生成手段に送るステップ（１００２）と、
　前記アクセス対象のデータ構造単位のキャッシュデータがあるかを判断するステップ（１００３）と、
　前記アクセス対象のデータ構造単位のキャッシュデータが無い場合、前記特定されたローカルデータベースの前記問い合わせ文生成手段が、前記検索条件と、前記データ構造格納領域に格納されている前記定義情報の前記問い合わせ文とをもとに、前記特定されたローカルデータベースの問い合わせ文を生成し、前記ローカルデータベースアクセス手段へ渡すステップ（１００４）と、
　前記ローカルデータベースアクセス手段が、前記特定されたローカルデータベースへ前記生成された問い合わせ文を発行し、受け取った検索結果を前記データキャッシュ手段へ渡すステップ（１００５）と、
　前記データキャッシュ手段が、前記検索結果を前記キャッシュ領域へ格納し、前記データ構造格納領域に格納番地を設定するステップ（１００６）と、
　前記問い合わせ処理手段が、前記格納番地と前記検索条件を、前記データキャッシュ領域検索手段に渡すステップ（１００７）と、
　前記データキャッシュ領域検索手段が、前記データキャッシュ領域を検索し、前記検索条件に合ったデータを呼出し側へ返すステップ（１００８）と、
　を備えることを特徴とする方法。」
　
２．特開平７−９８６６９号公報
　
　特開平７−９８６６９号公報（以下、「引用例２」という。）には、次の事項が記載されている。
　
Ｉ．「【０００１】
【産業上の利用分野】本発明は、ネットワークに接続された複数の情報処理装置を備える分散データベース管理システムに関する。」
　
Ｊ．「【００６９】（２）論理データベースアクセス制御部の処理
論理データベースアクセス制御部１０は、最初にアプリケーションプログラム実行手段２からCONNECT構文を受け付け、構文バッファ６へ格納した後、該CONNECT構文と、CONNECT構文を発行したＯＳユーザのＩＤおよびグループＩＤとをテーブル位置検索部７へ通知する。また論理データベースアクセス制御部１０は、CONNECT構文以降にアプリケーションプログラム実行手段２から受け取ったテーブルアクセス構文に関しても、同様に構文バッファ６へ格納した後、テーブル位置検索部７へ通知する。」
　
Ｋ．「【００７９】Ｓ５０８においてアクセス不可を示す情報を受け取った場合、テーブル位置検索部７は、現在ログイン中の物理データベース１にアクセス対象のテーブルが格納されていないと判断し、該物理データベース１からログアウトするDISCONNECT構文を作成して発行した後（Ｓ５０９）、論理データベース制御ブロック１３に登録された次に優先順位の高い物理データベース１の物理データベース名称および物理データベースアカウントを用いて（Ｓ５１０）、Ｓ５０６〜Ｓ５０８のテーブル位置検索処理を繰り返す。なお、Ｓ５１０において、次に優先順位の高い物理データベース１が登録されていない場合、テーブル位置検索部７は、処理をＳ５１４に進め、アクセスできないことをアプリケーションプログラム実行手段２に通知する。
【００８０】Ｓ５０８において、ある物理データベース１から処理結果を受け取った場合、テーブル位置検索部７は、テーブル位置を現在ログイン中の物理データベース１と決定し、論理データベースアクセス制御部１０を介して処理結果をアプリケーションプログラム実行手段２へ返して（Ｓ５１１）、次の構文の入力を待つ（Ｓ５１２）。」
　
Ｌ．「【０２４９】（実施例１１）本実施例１１によれば、論理データベースアクセス機能による分散検索処理が実現される。本実施例１１の分散データベースアクセス管理部３は、異なる物理データベース１に格納されている複数のテーブルを対象としたジョイン（分散検索）に関しても、テーブル位置を意識することなく実現できる。
【０２５０】Ａ．テーブル位置検索部の処理
本実施例１１の分散データベースアクセス管理部３の構成は、実施例１の場合と同様であり、各構成要素の処理の流れも実施例１の場合と同様である。ただし、分散データベースアクセス管理部３は、複数のSELECT構文を保持することのできるSELECT構文格納領域（図示せず）と、SELECT構文の処理結果を複数保持することのできるSELECT構文結果格納領域（図示せず）と、SELECT構文の分解処理中かどうかを示すフラグを保持するSELECT構文処理中フラグ格納領域（図示せず）を、さらに備える。なお、SELECT構文処理中フラグ格納領域の初期値は０である。また、テーブル位置検索部７の処理が実施例１とは異なっている。本実施例１１のテーブル位置検索部７の処理の流れを図３５に示す。なお、実施例１で用いたものと同じ符号の付されたステップの処理は、実施例１のそれと同様である。
【０２５１】（１）SELECT構文の分解（Ｓ３５０〜Ｓ３５４）
通常、ジョインには、複数のテーブル名称が記述された１つのSELECT構文が使用される。そこで、本実施例１１のテーブル位置検索部７は、CONNECT構文による最初のログイン（Ｓ５０６）後、構文バッファ６に保持されている、次に実行すべきテーブルアクセス構文が、複数のテーブルの指定されたSELECT構文であるかどうか検査し（Ｓ３５０）、複数のテーブルの指定されたSELECT構文であれば、該SELECT構文を解釈、分解して、指定された複数のテーブルの個々のテーブルをアクセスするSELECT構文を作成し、これをSELECT構文格納領域に格納し（Ｓ３５１）、SELECT構文処理中フラグ格納領域に１を格納し（Ｓ３５２）、分解後のSELECT構文（ひとつのテーブルの記述されたSELECT構文）をひとつ上記SELECT構文格納領域から読み出して、構文バッファ６に、つぎに処理すべき構文として格納して（Ｓ３５３）、つぎにログインすべき物理データベース１を、処理中の論理データベース４に属する最も優先順位の高い物理データベース１とし（Ｓ３５４）、構文転送処理（Ｓ５０７）に処理を進める。また、ステップＳ３５０において、処理対象が、複数のテーブルの指定されたSELECT構文ではない場合、本実施例１１のテーブル位置検索部７は、そのまま処理を構文転送処理（Ｓ５０７）に進める。
【０２５２】（２）結果の蓄積（Ｓ３５５〜Ｓ３５９）
構文転送（Ｓ５０７）の結果、アクセス成功の応答を受け付けると、本実施例１１のテーブル位置検索部７は、SELECT構文処理中フラグ格納領域に保持された値（SELECT構文処理中フラグ）が１かどうか検査し（Ｓ３５５）、１でなければ、そのまま処理をＳ５１１に進める。SELECT構文処理中フラグが１であれば、本実施例１１のテーブル位置検索部７は、通知された処理結果をSELECT構文結果格納領域に格納する（Ｓ３５６）。
【０２５３】つぎに、本実施例１１のテーブル位置検索部７は、SELECT構文格納領域に、未処理の分解後SELECT構文が残っているかどうか検査し（Ｓ３５７）、残っていれば、つぎに処理すべき分解後SELECT構文をSELECT構文格納領域から読み出して、構文バッファ６に格納し（Ｓ３５８）、つぎにログインすべき物理データベース１を、処理中の論理データベース４に属する最も優先順位の高い物理データベース１として（Ｓ３５９）、処理をステップＳ５０７に戻す。
【０２５４】（３）結果の結合（Ｓ３６０〜Ｓ３６１）
ステップＳ３５７において、SELECT構文格納領域に、未処理の分解後SELECT構文が残っていなければ、本実施例１１のテーブル位置検索部７は、SELECT構文結果格納領域に蓄積されている処理結果を結合し（Ｓ３６０）、SELECT構文処理中フラグ格納領域に０を格納して（Ｓ３６１）、処理をステップＳ５１１に進める。
【０２５５】Ｂ．本実施例１１の効果
以上のように、本実施例１１の論理データベースアクセス機能によると、単一の物理データベース１に格納されたテーブルに対するジョインと同様のSELECT構文により、同一論理データベース内の異なる物理データベース１に格納された複数のテーブルをジョインできる。」
　
　上記Ｉ．〜Ｌ．及び関連する図面の記載によれば、引用例２には、実施例１１について以下の事項が記載されている。
「分散データベース管理システムにおいて、単一の物理データベースに格納されたテーブルに対するジョインと同様のSELECT構文により、同一論理データベース内の異なる物理データベースに格納された複数のテーブルをジョインする分散検索処理方法であって、
　アプリケーションプログラム実行手段から受け取ったテーブルアクセス構文を構文バッファへ格納し、
　CONNECT構文による最初のログインを行い（Ｓ５０６）、
　構文バッファに保持されている、次に実行すべきテーブルアクセス構文が、複数のテーブルを指定するSELECT構文であるかどうか検査し（Ｓ３５０）、複数のテーブルを指定したSELECT構文ではない場合、ステップＳ５０７に進み、
　複数のテーブルを指定するSELECT構文であれば、当該SELECT構文を解釈、分解して、指定された複数のテーブルの個々のテーブルをアクセスするSELECT構文を作成し、これをSELECT構文格納領域に格納し（Ｓ３５１）、
　SELECT構文処理中フラグ格納領域に１を格納し（Ｓ３５２）、
　分解後のSELECT構文をひとつ上記SELECT構文格納領域から読み出し、前記構文バッファに、つぎに処理すべき構文として格納し（Ｓ３５３）、
　ログインすべき物理データベースを、処理中の論理データベースに属する最も優先順位の高い物理データベースとし（Ｓ３５４）、
　構文バッファのSELECT構文をログインすべき物理データベースに転送し（Ｓ５０７）、
　前記転送の結果として、アクセス可否の応答を受け付け（Ｓ５０８）、
　アクセス成功の応答を受け付けると、SELECT構文処理中フラグ格納領域に保持された値が１かどうか検査し（Ｓ３５５）、１でなければ、そのまま処理をステップＳ５１１に進め、
　SELECT構文処理中フラグ格納領域に保持された値が１であれば、通知された処理結果をSELECT構文結果格納領域に格納し（Ｓ３５６）、
　SELECT構文格納領域に、未処理の分解後SELECT構文が残っているかどうか検査し（Ｓ３５７）、
　残っていれば、つぎに処理すべき分解後SELECT構文をSELECT構文格納領域から読み出して、構文バッファに格納し（Ｓ３５８）、
　ログインすべき物理データベースを、処理中の論理データベースに属する最も優先順位の高い物理データベースとし（Ｓ３５９）、処理をステップＳ５０７に戻し、
　SELECT構文格納領域に、未処理の分解後SELECT構文が残っていなければ、SELECT構文結果格納領域に蓄積されている処理結果を結合し（Ｓ３６０）、
　SELECT構文処理中フラグ格納領域に０を格納し（Ｓ３６１）、
　処理結果をアプリケーションプログラム実行手段へ返し（Ｓ５１１）、
　上記ステップＳ５０８においてアクセス不可の応答を受け付けると、現在ログイン中の物理データベースにアクセス対象のテーブルが格納されていないと判断し、該物理データベースからログアウトし（Ｓ５０９）、
　次に優先順位の高い物理データベースをログインすべき物理データベースとして（Ｓ５１０）、ステップＳ５０６に戻る、
分散検索処理方法。」
　
第４　対比
　
　次に、本願発明と引用発明とを対比する。
・引用発明の「ローカルデータベース」は、本願発明の「データソース」に相当し、
　引用発明の「複数のローカルデータベース」全体は、本願発明の「複数のデータソースをその中に有するデータベースプール」に相当し、
　引用発明の「テーブルを格納した複数のローカルデータベースにアクセス」する「異種データベースアクセス装置」は、本願発明の「複数のデータソースをその中に有するデータベースプールと通信しているシステム」に相当する。
　
・引用発明の「データ構造単位のテーブル名」は、本願発明のデータの「種別」に相当し、
　引用発明の各ローカルデータベースが、「データ構造単位のテーブル名」に対応するテーブルを格納することは、本願発明の「前記各データソースにはデータのそれぞれの種別の情報が入っており」に相当する。
　
・引用発明の「アプリケーションプログラムから前記異種データベースアクセス装置に発行された問い合わせ文を処理する方法」と、本願発明の「前記システムに対するユーザクエリを処理する方法」は、ともに「前記システムに対するクエリを処理する方法」の点で共通する。
　
・引用発明の「アプリケーションプログラムから、ＳＱＬ形式の問い合わせ文を受信するステップ（１００１）」において、「ＳＱＬ形式の問い合わせ文」は、ＳＱＬフォーマットにしたがって記述された単一の文からなるクエリといえる。
　したがって、引用発明の上記ステップ（１００１）と、本願発明の「所定のフォーマットで単一のユーザクエリを電子的ネットワーク経由で受信するステップ」は、ともに「所定のフォーマットで単一のクエリを受信するステップ」の点で共通する。
　
・引用発明において、アプリケーションプログラムからの問い合わせ文は、ＳＱＬフォーマットの構文といえる。
　したがって、引用発明のステップ（１００２）において、「前記問い合わせ処理手段が、前記アプリケーションプログラムからの前記問い合わせ文に含まれる、アクセス対象のデータ構造単位のテーブル名と検索条件を明確に」することは、ＳＱＬフォーマットにしたがってクエリを構文解析することによって、クエリを満たすために必要とされる「データ構造単位のテーブル名」すなわちデータの「種別」を判定することといえる。
　したがって、引用発明のステップ（１００２）における「前記問い合わせ処理手段が、前記アプリケーションプログラムからの前記問い合わせ文に含まれる、アクセス対象のデータ構造単位のテーブル名と検索条件を明確にし」と、本願発明の「前記所定のフォーマットに従って前記ユーザクエリを構文解析することによって前記クエリを満たすために必要とされるデータの複数の種別を判定するステップ」は、ともに「前記所定のフォーマットに従って前記クエリを構文解析することによって前記クエリを満たすために必要とされるデータの種別を判定するステップ」の点で一致する。
　
・引用発明の「データ構造単位のテーブル名と、アクセス先のローカルデータベースの名前と、ローカルデータベースのテーブルへの問い合わせ文とを含んだ、各ローカルデータベースに関する定義情報」は、アプリケーションプログラムからの問い合わせ文に含まれるテーブル名を、アクセス先のローカルデータベースに関連付ける構造を有するといえるから、本願発明の「クエリマップ構造」に相当する。
　
・引用発明は、ステップ（１００２）において「前記定義情報を用いて、前記テーブル名に基づいてアクセスすべきローカルデータベースを特定し、前記検索条件を、前記特定されたローカルデータベースの問い合わせ命令生成手段に送」り、ステップ（１００４）において、「前記特定されたローカルデータベースの前記問い合わせ文生成手段が、前記検索条件と、前記データ構造格納領域に格納されている前記定義情報の前記問い合わせ文とをもとに、前記特定されたローカルデータベースの問い合わせ文を生成」する。
　上記処理は、判定された「データ構造単位のテーブル名」すなわちデータの「種別」を用いて、「定義情報」すなわち「クエリマップ構造」を検索することによって、「ローカルデータベースの問い合わせ文」すなわち「サブクエリ」を生成することといえる。
　したがって、引用発明におけるステップ（１００２）及びステップ（１００４）の上記処理と、本願発明の「前記判定されたデータの種別を用いてクエリマップ構造を検索することによって複数のサブクエリを生成するステップ」は、ともに「前記判定されたデータの種別を用いてクエリマップ構造を検索することによってサブクエリを生成するステップ」の点で共通する。
　
・引用発明のステップ（１００２）における「前記定義情報を用いて、前記テーブル名に基づいてアクセスすべきローカルデータベースを特定し」は、「テーブル名」すなわち「データの種別」を用いて、「定義情報」すなわち「クエリマップ構造」を検索することによって、複数のデータソースから目標のデータソースを識別することといえる。
　したがって、引用発明のステップ（１００２）における「前記定義情報を用いて、前記テーブル名に基づいてアクセスすべきローカルデータベースを特定し」と、本願発明の「前記データの複数の種別を用いて前記クエリマップ構造を検索することによって前記複数のデータソースから複数の目標のデータソースを識別するステップ」は、ともに「前記データの種別を用いて前記クエリマップ構造を検索することによって前記複数のデータソースから目標のデータソースを識別するステップ」の点で共通する。
　
・引用発明の「前記ローカルデータベースアクセス手段が、前記特定されたローカルデータベースへ前記生成された問い合わせ文を発行し、受け取った検索結果を前記データキャッシュ手段へ渡すステップ（１００５）」と、本願発明の「前記複数のサブクエリを対応するそれぞれの目標のデータソースに発行することによって前記複数の目標のデータソースからデータを取り出すステップ」は、ともに「前記サブクエリを対応する目標のデータソースに発行することによって前記目標のデータソースからデータを取り出すステップ」の点で共通する。
　
・引用発明の「前記データキャッシュ領域検索手段が、前記データキャッシュ領域を検索し、前記検索条件に合ったデータを呼出し側へ返すステップ（１００８）」と、本願発明の「前記ユーザへ前記応答を返すステップ」は、ともに「応答を返すステップ」の点で共通する。
　
　したがって、本願発明と引用発明は、以下の点で一致する。
　
＜一致点＞
「　複数のデータソースをその中に有するデータベースプールと通信しているシステムにおいて、前記各データソースにはデータのそれぞれの種別の情報が入っており、前記システムに対するユーザクエリを処理する方法は、
　所定のフォーマットで単一のクエリを受信するステップと、
　前記所定のフォーマットに従って前記クエリを構文解析することによって前記クエリを満たすために必要とされるデータの種別を判定するステップと、
　前記判定されたデータの種別を用いてクエリマップ構造を検索することによってサブクエリを生成するステップと、
　前記データの種別を用いて前記クエリマップ構造を検索することによって前記複数のデータソースから目標のデータソースを識別するステップと、
　前記サブクエリを対応する目標のデータソースに発行することによって前記目標のデータソースからデータを取り出すステップと、
　応答を返すステップと、
　を備えることを特徴とする方法。」
　
　そして、本願発明と引用発明は、以下の点で相違する。
＜相違点１＞
　クエリが、本願発明では「ユーザクエリ」であるのに対し、引用発明ではアプリケーションプログラムから発行された問い合わせ文である点。
　また、本願発明は、応答を「ユーザ」へ返すのに対し、引用発明は、検索条件に合ったデータすなわち応答を「呼出し側」の「アプリケーションプログラム」へ返す点。
　
＜相違点２＞
　本願発明は、ユーザクエリを電子的ネットワーク経由で受信するのに対し、引用発明は、アプリケーションプログラムの問い合わせ文を、どのような通信路を経由して受信するのか不明である点。
　
＜相違点３＞
　本願発明は、判定される種別が「複数」の種別であるのに対し、引用発明は、ステップ（１００２）において明確にされる「テーブル名」が「複数」のテーブル名であるかどうか不明である点。
　本願発明は、生成されるサブクエリが「複数」のサブクエリであるのに対し、引用発明は、ステップ（１００４）において生成される問い合わせ文が「複数」の問い合わせ文であるのかどうか不明である点。
　本願発明は、目標のデータソースの識別に用いられるデータの種別が「複数」の種別であり、識別される目標のデータソースが「複数」の目標のデータソースであるのに対し、引用発明は、アクセスすべきローカルデータベースの特定に用いられるテーブル名が「複数」のテーブル名であるかどうか不明であり、特定されるアクセスすべきローカルデータベースが「複数」のローカルデータベースであるかどうか不明である点。
　本願発明は、目標のデータソースに発行されるサブクエリが「複数」のサブクエリであり、その目標のデータソースが「それぞれ」の目標のデータソースであるの対し、引用発明は、ローカルデータベースに発行される問い合わせ文が「複数」の問い合わせ文であるかどうか不明であり、そのローカルデータベースが「それぞれ」のローカルデータベースであるかどうか不明である点。
　本願発明は、データを取り出すデータソースが「複数」のデータソースであるのに対し、引用発明は、検索結果を受け取るローカルデータベースが「複数」のローカルデータベースであるかどうか不明である点。
　本願発明は、「前記取り出されたデータを前記データの複数の種別に応じて組み合わせて、前記クエリに対する単一の応答を生成するステップ」を備えるのに対し、引用発明は、このステップを備えていない点。
　
＜相違点４＞
　本願発明におけるユーザクエリは、「前記ユーザの金融取引に関する情報に対する要求を備える」のに対し、引用発明におけるアプリケーションプログラムからの問い合わせ文は、「ユーザの金融取引に関する情報に対する要求」ではない点。
　
第５　判断
　
＜相違点１＞について
　引用例１の上記Ｇ．には、以下の事項が記載されている。
「【００２９】図５に、異種データベースアクセス装置への問い合わせ文の例を２つ示す。図３のように定義されたデータ構造単位（ここでは、テーブル）に対する問い合わせの例である。これらの問い合わせを発行するユーザあるいはアプリケーションプログラムは、異種データベースアクセス装置上のデータ構造単位（テーブルなど）のみを意識すれば良く、元のデータはどのローカルデータベースに格納されているかを意識する必要がない。」
　上記記載によれば、ユーザが、問い合わせ文を異種データベースアクセス装置へ発行することも示唆されており、この問い合わせ文は「ユーザクエリ」といえる。
　したがって、引用発明において、アプリケーションプログラムをユーザに変更して、そのユーザからの問い合わせ文を「ユーザクエリ」とし、検索条件に合ったデータすなわち応答を呼出し側の「ユーザ」へ返して、引用発明を上記相違点１に係る本願発明の構成を備えるようにすることは容易に想到し得ることである。
　
＜相違点２＞及び＜相違点４＞について
　電子的ネットワークは周知の通信路である。
　また、ユーザが、電子的ネットワーク経由で、金融機関等のデータベースに「ユーザの金融取引に関する情報に対する要求」を備えたクエリを発行することも周知である。
　また、前記「＜相違点１＞について」に記載したように、引用例１には、ユーザが、問い合わせ文を異種データベースアクセス装置へ発行することも示唆されている。
　してみると、引用発明において、引用例１の上記記載事項、及び、上記周知事項を適用して、異種データベースアクセス装置への問い合わせ文を、「電子的ネットワーク経由」で受信し、その問い合わせ文を「前記ユーザの金融取引に関する情報に対する要求を備える」ユーザクエリとすることにより、上記相違点２及び上記相違点４に係る本願発明の構成を備えるようにすることは容易に想到し得ることである。
　
＜相違点３＞について
　引用例１の図５には、実施の形態１に係る異種データベースアクセス装置への問い合わせ文として、次の問い合わせ文が例示されている。
「例１
　　　select   name, image  from  emp_image  where  id   10;
　例２
      select   name, age, sal  from emp_image, emp_sal where emp_image.id = emp_sal.id;」
　これらの問い合わせ文は、ＳＱＬ形式で記述されたSELECT構文であり、例２の問い合わせ文は、アクセス対象となる２つのテーブル名「emp_image」「emp_sal」を含んでいる。
　したがって、引用例１には、異種データベースアクセス装置への問い合わせ文として、複数のテーブル名を記述したSELECT構文が示唆されている。
　また、引用例１の図３には、２つのテーブル名「emp_image」「emp_sal」に関して、以下の定義情報が記載されている。
「例１
　　　テーブル名：　emp_image
　　　カラム名：　   id       name     age      image 
　　　データ型：    integer    string     integer   blob
　　　アクセス先：　　ＤＢ１
　　　問い合わせ文： select  e_id, e_name, age, image  from emp_table1;
　　　キャッシュ先番地：　a10
　例２
　　　テーブル名： emp_sal
　　　カラム名：     id       sal
　　　データ型：   integer    integer
　　　アクセス先：  ＤＢ２
　　　問い合わせ文：　SELECT  EMPNO, SAL  FROM  EMP_TABLE2;
　　　キャッシュ先番地： al1」
　この定義情報によれば、テーブル名「emp_image」に対応するアクセス先はローカルデータベース「ＤＢ１」で、テーブル名「emp_sal」に対応するアクセス先はローカルデータベース「ＤＢ２」である。
　したがって、上記定義情報に基づけば、図５に記載された例２の問い合わせ文が、異なるローカルデータベースに格納された複数のテーブルをアクセス先とするSELECT構文であることは明らかである。
　一方、引用例２に記載された前記分散検索処理方法は、異なるデータベースに格納された複数のテーブルをアクセス先とするSELECT構文の処理方法といえる。
　この分散検索処理方法は、複数のテーブルを指定するSELECT構文を解釈、分解して、個々のテーブルにアクセスする複数のSELECT構文を生成し、分解後の複数のSELECT構文を、個々のテーブルを格納する複数のデータベースに転送し、複数のデータベースから得られた処理結果を結合し、アプリケーションプログラム実行手段へ返すものである。
　ここで、複数のテーブルを指定するSELECT構文を解釈、分解して、個々のテーブルにアクセスする複数のSELECT構文を生成することは、単一のクエリを構文解析して、指定された複数のテーブル名すなわち「複数」の種別を判定し、判定されたデータの種別を用いて、「複数」のサブクエリを生成することといえる。
　また、分解後の複数のSELECT構文を、個々のテーブルを格納する複数のデータベースに転送して、処理結果を得ることは、「複数」のサブクエリを対応する「それぞれ」の目標のデータソースに発行することによって、「複数」の目標のデータソースからデータを取り出すことといえる。
　また、複数のデータベースから得られた処理結果を結合することは、複数のデータベースから取り出されたデータを、複数のテーブルすなわち複数の種別に応じて組み合わせて、クエリに対する単一の応答を生成するステップといえる。
　してみると、引用発明において、異種データベースアクセス装置への問い合わせ文を、異なるローカルデータベースに格納された複数のテーブルをアクセス先とする問い合わせ文として、その問い合わせ文を処理するために引用例２の記載事項を適用し、
　これにより、ステップ（１００２）において、異種データベースアクセス装置への問い合わせ文に含まれる「複数」のテーブル名を明確にし、「複数」のテーブル名に基づいてアクセスすべき「複数」のローカルデータベースを特定し、
　ステップ（１００４）において、ローカルデータベースの「複数」の問い合わせ文を生成し、
　ステップ（１００５）において、生成された「複数」の問い合わせ文を「それぞれ」のローカルデータベースへ発行し、「複数」のローカルデータベースから受け取った検索結果を複数のテーブル名に応じて結合して単一の応答を生成することにより、上記相違点３に係る本願発明の構成を備えるようにすることは容易に想到し得ることである。
　
　そして、本願発明の作用効果も、引用発明、引用例１及び引用例２の記載事項並びに周知事項から当業者が予測できる範囲のものである。
　
　したがって、本願発明は、引用発明、引用例１及び引用例２の記載事項並びに周知事項に基づいて当業者が容易に発明をすることができたものであり、特許法第２９条第２項の規定により特許を受けることができない。
　　
第６　むすび
　
　以上のとおりであるから、本願発明は、引用発明、引用例１及び引用例２の記載事項並びに周知事項に基づいて当業者が容易に発明をすることができたものであり、特許法第２９条第２項の規定により特許を受けることができない。
　したがって、他の請求項について検討するまでもなく、本願は拒絶されるべきものである。
　よって、結論のとおり審決する。