【事件の表示】
　特願２００２−５８２３９４「リモート・データ・ソースからのデータ・ロード」拒絶査定不服審判事件〔平成１４年１０月２４日国際公開、ＷＯ０２／８４５２２、平成１６年１０月２１日国内公表、特表２００４−５３２４６５〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続きの経緯・本願発明
　本願は、平成１４年２月２５日（パリ条約による優先権主張外国庁受理２００１年２月２８日、アメリカ合衆国）を国際出願日とする出願であって、その特許請求の範囲の請求項２に記載された発明（以下、「本願発明」と呼ぶ。）は、平成２２年９月１６日付けの手続補正により補正された特許請求の範囲の請求項２に記載されたとおりのものであり、次のとおりのものと認める。
「【請求項２】
　レコードごとにリモート・データ・ソースからデータをロードするためのシステムであって、
　少なくとも１つのデータ・ソースに結合され、ＤＢＭＳに対してマルチデータベース・アクセス可能なソフトウェア・サーバを有するソース・サイトと、
　構造化照会言語（ＳＱＬ）ステートメントまたはそれと同等のものからなるブロック中のカーソル名によって前記ソース・サイトにデータ・ロードを要求するターゲット・サイトと、
　マルチデータベース・アクセス通信プロトコルに従ってフォーマットされたデータを、レコードごとにトランスポートするデータベース接続通信回線とを具備し、
　ファイル名の代わりにカーソル名を用いて、複数のデータ・ソース区画カーソルによって指示される複数のパラレル・ストリームによって複数の区画に前記データ・ロードをパイプライン方式で実行し、
　前記ターゲット・サイトが前記ソース・サイト内のレコードのアンロードと同時にレコードをロードするシステム。」
　
　
２．引用例記載の発明
　
（１）当審による平成２２年７月７日付けの拒絶理由通知書で引用した「Ｐｉｙｕｓｈ　Ｇｕｐｔａ　ｅｔ　ａｌ．，ＤａｔａＪｏｉｎｅｒ：　Ａ　Ｐｒａｃｔｉｃａｌ　Ａｐｐｒｏａｃｈ　ｔｏ　Ｍｕｌｔｉ−Ｄａｔａｂａｓｅ　Ａｃｃｅｓｓ，Ｐａｒａｌｌｅｌ　ａｎｄ　Ｄｉｓｔｒｉｂｕｔｅｄ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｓｙｓｔｅｍｓ，　１９９４．，　Ｐｒｏｃｅｅｄｉｎｇｓ　ｏｆ　ｔｈｅ　Ｔｈｉｒｄ　Ｉｎｔｅｒｎａｔｉｏｎａｌ　Ｃｏｎｆｅｒｅｎｃｅ　ｏｎ　Ａｕｓｔｉｎ，米国，ＩＥＥＥ　Ｃｏｍｐｕｔ．Ｓｏｃ．，１９９４年　９月２８日，ｐ．２６４」（以下、「引用例１」と呼ぶ。）には、次の記載がある。
　
「DataJoiner is a new Database Middleware product that provides client applications a unified view of this diverse data. It will enable and simplify the development of complex decision support applications. Thus, for instance, a client application can join data distributed across multiple DBMSes using a single SQL statement, as if the data were local.
  DataJoiner, in its first release, will provide client applications (…略…) TRANSPARENT SQL access to heterogeneous, distrebuted data (…略…).」（ｐ．２６４　第２〜８行）
＜当審による邦訳＞
「データジョイナーは、クライアントアプリケーションにこの多様なデータの統一されたビューを提供する、新しいデータベースミドルウエア製品である。それは、複雑な意思決定支援アプリケーションの開発を可能化、簡単化するであろう。そうして、例えば、クライアントアプリケーションは、あたかもデータがローカルにあるかのように、単一のＳＱＬステートメントを使用して、多数のＤＢＭＳにまたがって分配されたデータを結合することができる。
　データジョイナーは、そのファーストリリースにおいて、クライアントアプリケーションに、異種の分配されたデータへの透明なＳＱＬアクセスを提供するであろう。」
　
　そして、上記記載事項を、同引用例１のｐ．２６４に記載された図面と技術常識に照らせば、引用例１には、以下の発明（以下、「引用例１記載発明」と呼ぶ。）が記載されているといえる。
「複数のＤＢＭＳからデータをロードするためのシステムであって、
　少なくとも１つのＤＢＭＳに結合され、ＤＢＭＳに対してマルチデータベース・アクセス可能なデータベースミドルウエア（データジョイナー）を有するコンピュータと、
　ＳＱＬステートメントによって前記データベースミドルウエア（データジョイナー）を有するコンピュータにデータ・ロードを要求するクライアントコンピュータと、
　データを、トランスポートするデータベース接続通信回線と、
を具備するシステム。」
　
（２）当審による平成２２年７月７日付けの拒絶理由通知書で引用した「ＤＰ−ＵＸ　ＸＤＢＦ／Ｒ説明書，日本，三菱電機インフォメーションテクノロジー株式会社，２０００年　６月２０日，第３版，第４章第２９頁−第４章第３１頁」（以下、「引用例２」と呼ぶ。）には、次の記載がある。
　
ア．
「４．５　カーソル操作関数によるレコードの更新
カーソル操作関数によって、１レコードごとに更新を行います。
カーソル操作関数には次のものがあり、Ｕ＃ＣＮＣＴ関数を実行によって接続したデータベースに対して操作を行います。
また、操作終了後にはＵ＃ＤＳＣＮ関数によってデータベースの接続を切断します。
・Ｕ＃ＯＰＥＮ（カーソルＯＰＥＮ）　・Ｕ＃ＲＥＡＤ（カーソルＦＥＴＣＨ）　・Ｕ＃ＲＥＷＴ（カーソルＵＰＤＡＴＥ）　・Ｕ＃ＥＲＡＳ（カーソルＥＲＡＳＥ）　・Ｕ＃ＣＬＯＳＥ（カーソルＣＬＯＳＥ）」（ｐ．４−２９　第１〜７行）
　
イ．
「（４）カーソル操作の並行実行
オープンＤＢとの１接続内で、複数のカーソルによる並行したアクセスが行えます。
Ｕ＃ＯＰＥＮ関数で１接続内で唯一のカーソルＩＤが返されるので、このカーソルＩＤを使い分けることにより、複数のカーソルを使い分けることができます。」（ｐ．４−３０　図面の下）
　
　また、引用例２のｐ．４−３１には、「カーソル操作の並列実行の例」として、複数のカーソルについてのカーソル操作がパラレル・ストリームによって実行される様子が図示されている。
　
　
３．対比 
　本願発明と引用例１記載発明を対比すると、両者間には、以下の対応関係があるといえる。
（１）引用例１記載発明の「複数のＤＢＭＳ」は、本願発明の「リモート・データ・ソース」に相当する。
（２）引用例１記載発明の「データベースミドルウエア（データジョイナー）を有するコンピュータ」は、本願発明の「ソフトウェア・サーバを有するソース・サイト」に相当する。
（３）引用例１記載発明の「クライアントコンピュータ」は、本願発明の「ターゲット・サイト」に相当する。
　
　したがって、本願発明と引用例１記載発明との間には、以下の一致点、相違点があるといえる。
　
（一致点）
「リモート・データ・ソースからデータをロードするためのシステムであって、
　少なくとも１つのデータ・ソースに結合され、ＤＢＭＳに対してマルチデータベース・アクセス可能なソフトウェア・サーバを有するソース・サイトと、
　構造化照会言語（ＳＱＬ）ステートメントによって前記ソース・サイトにデータ・ロードを要求するターゲット・サイトと、
　データを、トランスポートするデータベース接続通信回線と、
を具備するシステム。」である点。
　
（相違点１）
　本願発明のシステムは、リモート・データ・ソースからのデータのロードを「レコードごと」に行うものであるのに対し、引用例１記載発明のシステムは、リモート・データ・ソース（複数のＤＢＭＳ）からのデータのロードを「レコードごと」に行うものではない点。
　
（相違点２）
　本願発明のターゲット・サイトは、「構造化照会言語（ＳＱＬ）ステートメントまたはそれと同等のものからなるブロック中のカーソル名」によってソース・サイトにデータ・ロードを要求するものであるのに対し、引用例１記載発明のターゲット・サイト（クライアントコンピュータ）は、「構造化照会言語（ＳＱＬ）ステートメントまたはそれと同等のものからなるブロック中のカーソル名」によってソース・サイトにデータ・ロードを要求するものではない点。
　
（相違点３）
　本願発明のデータベース接続通信回線は、「マルチデータベース・アクセス通信プロトコルに従ってフォーマットされたデータを、レコードごとにトランスポートする」ものであるのに対し、引用例１記載発明のデータベース接続通信回線は、「マルチデータベース・アクセス通信プロトコルに従ってフォーマットされたデータを、レコードごとにトランスポートする」ものではない点。
　
（相違点４）
　本願発明のシステムは、データ・ロードを「ファイル名の代わりにカーソル名を用いて、複数のデータ・ソース区画カーソルによって指示される複数のパラレル・ストリームによって複数の区画にパイプライン方式で」実行するものであるのに対し、引用例１記載発明のシステムは、データ・ロードを「ファイル名の代わりにカーソル名を用いて、複数のデータ・ソース区画カーソルによって指示される複数のパラレル・ストリームによって複数の区画にパイプライン方式で」実行するものではない点。
　
（相違点５）
　本願発明のシステムは、「ターゲット・サイトがソース・サイト内のレコードのアンロードと同時にレコードをロード」するように構成されているのに対し、引用例記載のシステムは、「ターゲット・サイトがソース・サイト内のレコードのアンロードと同時にレコードをロード」するように構成されているわけではない点。
　
　
４．当審の判断 
　
（１）上記相違点について 
　
ア．（相違点１、２）について
　下記（ア）〜（ウ）の事情にかんがみれば、引用例１記載発明のターゲット・サイト（クライアントコンピュータ）を、「構造化照会言語（ＳＱＬ）ステートメントまたはそれと同等のものからなるブロック中のカーソル名」によってソース・サイトにデータ・ロードを要求するものとし、引用例１記載発明のシステムを、リモート・データ・ソース（複数のＤＢＭＳ）からのデータのロードを「レコードごと」に行うものとすることは、当業者が容易に推考し得たことというべきである。
（ア）現時点において、データベースの分野における「カーソル」という用語は、「ＳＥＬＥＣＴ文などによるデータベース検索による検索実行の結果を１行ずつ取得して処理するために、データベースサーバ側にある結果集合と行取得位置を示す概念」といった程度の意味を有する用語として広く知られている（http://ja.wikipedia.org/wiki/SQL参照）が、該「カーソル」という用語は、本願出願前に頒布された引用例２の他、拒絶査定に文献４、５として引用された各文献にも、上記意味と矛盾無く使用されているし、本願明細書においても、格別の説明なしに上記意味と矛盾無く使用されている。
　以上の事実からみて、「カーソル」という用語は、本願出願前においても、「ＳＥＬＥＣＴ文などによるデータベース検索による検索実行の結果を１行ずつ取得して処理するために、データベースサーバ側にある結果集合と行取得位置を示す概念」といった程度の意味を有する用語として、当業者に広く知られていたと認められる。
（イ）上記「カーソル」による、１行ずつ、すなわち１レコードごと、の検索結果取得処理が、複数のＤＢＭＳからクライアントコンピュータへ検索結果のデータをロードするためのシステムである引用例１記載発明においても有用な場合があることは、当業者に自明で、引用例１記載発明においてそのようなカーソルによる１レコードごとの検索結果取得処理を採用できない理由はない。
（ウ）引用例１記載発明において上記「カーソル」による１レコードごとの検索結果取得処理を採用する場合に、引用例１記載発明のターゲット・サイト（クライアントコンピュータ）が、「『構造化照会言語（ＳＱＬ）ステートメントまたはそれと同等のものからなるブロック中のカーソル名』によってソース・サイトにデータ・ロードを要求するもの」とされるべきことや、引用例１記載発明のシステムが、「リモート・データ・ソース（複数のＤＢＭＳ）からのデータのロードを『レコードごと』に行うもの」となることは、当業者に自明である。
　
イ．（相違点３）について
　上述したように、引用例１記載発明のシステムを、「リモート・データ・ソース（複数のＤＢＭＳ）からのデータのロードを『レコードごと』に行うもの」とすることは当業者が容易に推考し得たことであるが、そのようにする場合に、引用例１記載発明のデータベース接続通信回線が「マルチデータベース・アクセス通信プロトコルに従ってフォーマットされたデータを、レコードごとにトランスポートする」ものとされるのが望ましいことは、当業者に自明であり、そのようにできない理由はないから、引用例１記載発明のデータベース接続通信回線を「マルチデータベース・アクセス通信プロトコルに従ってフォーマットされたデータを、レコードごとにトランスポートする」ものとすることも、当業者が容易に推考し得たことである。
　
ウ．（相違点４）について
　下記（ア）〜（オ）の事情にかんがみれば、引用例１記載発明のシステムを、「データ・ロードを『ファイル名の代わりにカーソル名を用いて、複数のデータ・ソース区画カーソルによって指示される複数のパラレル・ストリームによって複数の区画にパイプライン方式で』実行するもの」とすることも、当業者が容易に推考し得たことというべきである。
（ア）上記「ア．」で検討したように、引用例１記載発明におけるデータのロードを「ファイル名の代わりにカーソル名を用いて」実行するようにすること自体は、当業者が容易に推考し得たことである。
（イ）上記「２．」の「（２）」の「イ．」の欄に摘記したように、引用例２には、カーソルＩＤを使い分けることにより、複数のカーソルを使い分け、複数のカーソルによる並行したアクセスを行い得ることが記載されている。また、パイプライン方式により各種処理を行うことは周知である。
（ウ）上記引用例２に記載された複数のカーソルによる並行したアクセスや、周知のパイプライン方式による処理が、上記（ア）のように、引用例１記載発明におけるデータのロードを「ファイル名の代わりにカーソル名を用いて」実行するようにしたものにおいても有用な場合があることは、当業者に自明である。
（エ）上記引用例２に記載された複数のカーソルによる並行したアクセスや、周知のパイプライン方式による処理を、上記（ア）のように、引用例１記載発明におけるデータのロードを「ファイル名の代わりにカーソル名を用いて」実行するようにしたものにおいて採用することを妨げるべき事情はない。
（オ）上記引用例２に記載された複数のカーソルによる並行したアクセスや、周知のパイプライン方式による処理を、上記（ア）のように、引用例１記載発明におけるデータのロードを「ファイル名の代わりにカーソル名を用いて」実行するようにしたものにおいて採用する場合に、どの範囲のデータを１つのカーソルに割り当てるかといった事項や、データ・ソースのデータをターゲット・サイトにおいてどのように格納するかといった事項は、当業者がデータの使用目的等に応じて適宜決定すべき事項であり、上記「複数のカーソル」を「複数のデータ・ソース区画カーソル」と呼び得るものとしたり、上記「データのロード」を「複数の区画」に行うようにすることは、当業者が適宜なし得たことである。
　
エ．（相違点５）について 
 　引用例１記載発明に、上記のように引用例２に示される技術や周知の技術を採用した場合に、ソース・サイト内のレコードのアンロードとターゲット・サイトにおけるレコードのロードを同時に行えない理由はなく、それを同時に行うようにすることは、普通のことである。 
　
（２）本願発明の効果について　 
　本願発明の構成によってもたらされる効果は、引用例１、２の記載事項や周知の事項から当業者ならば容易に予測することができる程度のものであって、格別のものとはいえない。 
　
　
５．むすび 
　以上によれば、本願発明は、引用例１記載発明、引用例２の記載事項、及び周知の事項に基づいて、当業者が容易に発明をすることができたものであるから、特許法２９条第２項の規定により特許を受けることができない。
　したがって、本願は、他の請求項に係る発明について検討するまでもなく、拒絶されるべきものである。  
　よって、結論のとおり審決する。