ポートフォリオ機能
| ポートフォリオを新規に作成して保存 |
|
|
| 既存のポートフォリオに追加保存 |
|
PDFをダウンロード
|
| 審決分類 |
審判 査定不服 2項進歩性 特許、登録しない(前置又は当審拒絶理由) G06F |
|---|---|
| 管理番号 | 1234354 |
| 審判番号 | 不服2008-2050 |
| 総通号数 | 137 |
| 発行国 | 日本国特許庁(JP) |
| 公報種別 | 特許審決公報 |
| 発行日 | 2011-05-27 |
| 種別 | 拒絶査定不服の審決 |
| 審判請求日 | 2008-01-25 |
| 確定日 | 2011-03-24 |
| 事件の表示 | 特願2002-582394「リモート・データ・ソースからのデータ・ロード」拒絶査定不服審判事件〔平成14年10月24日国際公開、WO02/84522、平成16年10月21日国内公表、特表2004-532465〕について、次のとおり審決する。 |
| 結論 | 本件審判の請求は、成り立たない。 |
| 理由 |
1.手続きの経緯・本願発明 本願は、平成14年2月25日(パリ条約による優先権主張外国庁受理2001年2月28日、アメリカ合衆国)を国際出願日とする出願であって、その特許請求の範囲の請求項2に記載された発明(以下、「本願発明」と呼ぶ。)は、平成22年9月16日付けの手続補正により補正された特許請求の範囲の請求項2に記載されたとおりのものであり、次のとおりのものと認める。 「【請求項2】 レコードごとにリモート・データ・ソースからデータをロードするためのシステムであって、 少なくとも1つのデータ・ソースに結合され、DBMSに対してマルチデータベース・アクセス可能なソフトウェア・サーバを有するソース・サイトと、 構造化照会言語(SQL)ステートメントまたはそれと同等のものからなるブロック中のカーソル名によって前記ソース・サイトにデータ・ロードを要求するターゲット・サイトと、 マルチデータベース・アクセス通信プロトコルに従ってフォーマットされたデータを、レコードごとにトランスポートするデータベース接続通信回線とを具備し、 ファイル名の代わりにカーソル名を用いて、複数のデータ・ソース区画カーソルによって指示される複数のパラレル・ストリームによって複数の区画に前記データ・ロードをパイプライン方式で実行し、 前記ターゲット・サイトが前記ソース・サイト内のレコードのアンロードと同時にレコードをロードするシステム。」 2.引用例記載の発明 (1)当審による平成22年7月7日付けの拒絶理由通知書で引用した「Piｙｕｓh Gｕｐｔa eｔ al.,DaｔaJｏineｒ: A Pｒacｔical Aｐｐｒｏach ｔｏ Mｕlｔi-Daｔabaｓe Acceｓｓ,Paｒallel and Diｓｔｒibｕｔed Infｏｒmaｔiｏn Sｙｓｔemｓ, 1994., Pｒｏceedingｓ ｏf ｔhe Thiｒd Inｔeｒnaｔiｏnal Cｏnfeｒence ｏn Aｕｓｔin,米国,IEEE Cｏmｐｕｔ.Sｏc.,1994年 9月28日,ｐ.264」(以下、「引用例1」と呼ぶ。)には、次の記載がある。 「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 (…略…).」(ｐ.264 第2?8行) ＜当審による邦訳＞ 「データジョイナーは、クライアントアプリケーションにこの多様なデータの統一されたビューを提供する、新しいデータベースミドルウエア製品である。それは、複雑な意思決定支援アプリケーションの開発を可能化、簡単化するであろう。そうして、例えば、クライアントアプリケーションは、あたかもデータがローカルにあるかのように、単一のSQLステートメントを使用して、多数のDBMSにまたがって分配されたデータを結合することができる。 データジョイナーは、そのファーストリリースにおいて、クライアントアプリケーションに、異種の分配されたデータへの透明なSQLアクセスを提供するであろう。」 そして、上記記載事項を、同引用例1のｐ.264に記載された図面と技術常識に照らせば、引用例1には、以下の発明(以下、「引用例1記載発明」と呼ぶ。)が記載されているといえる。 「複数のDBMSからデータをロードするためのシステムであって、 少なくとも1つのDBMSに結合され、DBMSに対してマルチデータベース・アクセス可能なデータベースミドルウエア(データジョイナー)を有するコンピュータと、 SQLステートメントによって前記データベースミドルウエア(データジョイナー)を有するコンピュータにデータ・ロードを要求するクライアントコンピュータと、 データを、トランスポートするデータベース接続通信回線と、 を具備するシステム。」 (2)当審による平成22年7月7日付けの拒絶理由通知書で引用した「DP-UX XDBF/R説明書,日本,三菱電機インフォメーションテクノロジー株式会社,2000年 6月20日,第3版,第4章第29頁-第4章第31頁」(以下、「引用例2」と呼ぶ。)には、次の記載がある。 ア. 「4.5 カーソル操作関数によるレコードの更新 カーソル操作関数によって、1レコードごとに更新を行います。 カーソル操作関数には次のものがあり、U#CNCT関数を実行によって接続したデータベースに対して操作を行います。 また、操作終了後にはU#DSCN関数によってデータベースの接続を切断します。 ・U#OPEN(カーソルOPEN) ・U#READ(カーソルFETCH) ・U#REWT(カーソルUPDATE) ・U#ERAS(カーソルERASE) ・U#CLOSE(カーソルCLOSE)」(ｐ.4-29 第1?7行) イ. 「(4)カーソル操作の並行実行 オープンDBとの1接続内で、複数のカーソルによる並行したアクセスが行えます。 U#OPEN関数で1接続内で唯一のカーソルIDが返されるので、このカーソルIDを使い分けることにより、複数のカーソルを使い分けることができます。」(ｐ.4-30 図面の下) また、引用例2のｐ.4-31には、「カーソル操作の並列実行の例」として、複数のカーソルについてのカーソル操作がパラレル・ストリームによって実行される様子が図示されている。 3.対比 本願発明と引用例1記載発明を対比すると、両者間には、以下の対応関係があるといえる。 (1)引用例1記載発明の「複数のDBMS」は、本願発明の「リモート・データ・ソース」に相当する。 (2)引用例1記載発明の「データベースミドルウエア(データジョイナー)を有するコンピュータ」は、本願発明の「ソフトウェア・サーバを有するソース・サイト」に相当する。 (3)引用例1記載発明の「クライアントコンピュータ」は、本願発明の「ターゲット・サイト」に相当する。 したがって、本願発明と引用例1記載発明との間には、以下の一致点、相違点があるといえる。 (一致点) 「リモート・データ・ソースからデータをロードするためのシステムであって、 少なくとも1つのデータ・ソースに結合され、DBMSに対してマルチデータベース・アクセス可能なソフトウェア・サーバを有するソース・サイトと、 構造化照会言語(SQL)ステートメントによって前記ソース・サイトにデータ・ロードを要求するターゲット・サイトと、 データを、トランスポートするデータベース接続通信回線と、 を具備するシステム。」である点。 (相違点1) 本願発明のシステムは、リモート・データ・ソースからのデータのロードを「レコードごと」に行うものであるのに対し、引用例1記載発明のシステムは、リモート・データ・ソース(複数のDBMS)からのデータのロードを「レコードごと」に行うものではない点。 (相違点2) 本願発明のターゲット・サイトは、「構造化照会言語(SQL)ステートメントまたはそれと同等のものからなるブロック中のカーソル名」によってソース・サイトにデータ・ロードを要求するものであるのに対し、引用例1記載発明のターゲット・サイト(クライアントコンピュータ)は、「構造化照会言語(SQL)ステートメントまたはそれと同等のものからなるブロック中のカーソル名」によってソース・サイトにデータ・ロードを要求するものではない点。 (相違点3) 本願発明のデータベース接続通信回線は、「マルチデータベース・アクセス通信プロトコルに従ってフォーマットされたデータを、レコードごとにトランスポートする」ものであるのに対し、引用例1記載発明のデータベース接続通信回線は、「マルチデータベース・アクセス通信プロトコルに従ってフォーマットされたデータを、レコードごとにトランスポートする」ものではない点。 (相違点4) 本願発明のシステムは、データ・ロードを「ファイル名の代わりにカーソル名を用いて、複数のデータ・ソース区画カーソルによって指示される複数のパラレル・ストリームによって複数の区画にパイプライン方式で」実行するものであるのに対し、引用例1記載発明のシステムは、データ・ロードを「ファイル名の代わりにカーソル名を用いて、複数のデータ・ソース区画カーソルによって指示される複数のパラレル・ストリームによって複数の区画にパイプライン方式で」実行するものではない点。 (相違点5) 本願発明のシステムは、「ターゲット・サイトがソース・サイト内のレコードのアンロードと同時にレコードをロード」するように構成されているのに対し、引用例記載のシステムは、「ターゲット・サイトがソース・サイト内のレコードのアンロードと同時にレコードをロード」するように構成されているわけではない点。 4.当審の判断 (1)上記相違点について ア.(相違点1、2)について 下記(ア)?(ウ)の事情にかんがみれば、引用例1記載発明のターゲット・サイト(クライアントコンピュータ)を、「構造化照会言語(SQL)ステートメントまたはそれと同等のものからなるブロック中のカーソル名」によってソース・サイトにデータ・ロードを要求するものとし、引用例1記載発明のシステムを、リモート・データ・ソース(複数のDBMS)からのデータのロードを「レコードごと」に行うものとすることは、当業者が容易に推考し得たことというべきである。 (ア)現時点において、データベースの分野における「カーソル」という用語は、「SELECT文などによるデータベース検索による検索実行の結果を1行ずつ取得して処理するために、データベースサーバ側にある結果集合と行取得位置を示す概念」といった程度の意味を有する用語として広く知られている(http://ja.wikipedia.org/wiki/SQL参照)が、該「カーソル」という用語は、本願出願前に頒布された引用例2の他、拒絶査定に文献4、5として引用された各文献にも、上記意味と矛盾無く使用されているし、本願明細書においても、格別の説明なしに上記意味と矛盾無く使用されている。 以上の事実からみて、「カーソル」という用語は、本願出願前においても、「SELECT文などによるデータベース検索による検索実行の結果を1行ずつ取得して処理するために、データベースサーバ側にある結果集合と行取得位置を示す概念」といった程度の意味を有する用語として、当業者に広く知られていたと認められる。 (イ)上記「カーソル」による、1行ずつ、すなわち1レコードごと、の検索結果取得処理が、複数のDBMSからクライアントコンピュータへ検索結果のデータをロードするためのシステムである引用例1記載発明においても有用な場合があることは、当業者に自明で、引用例1記載発明においてそのようなカーソルによる1レコードごとの検索結果取得処理を採用できない理由はない。 (ウ)引用例1記載発明において上記「カーソル」による1レコードごとの検索結果取得処理を採用する場合に、引用例1記載発明のターゲット・サイト(クライアントコンピュータ)が、「『構造化照会言語(SQL)ステートメントまたはそれと同等のものからなるブロック中のカーソル名』によってソース・サイトにデータ・ロードを要求するもの」とされるべきことや、引用例1記載発明のシステムが、「リモート・データ・ソース(複数のDBMS)からのデータのロードを『レコードごと』に行うもの」となることは、当業者に自明である。 イ.(相違点3)について 上述したように、引用例1記載発明のシステムを、「リモート・データ・ソース(複数のDBMS)からのデータのロードを『レコードごと』に行うもの」とすることは当業者が容易に推考し得たことであるが、そのようにする場合に、引用例1記載発明のデータベース接続通信回線が「マルチデータベース・アクセス通信プロトコルに従ってフォーマットされたデータを、レコードごとにトランスポートする」ものとされるのが望ましいことは、当業者に自明であり、そのようにできない理由はないから、引用例1記載発明のデータベース接続通信回線を「マルチデータベース・アクセス通信プロトコルに従ってフォーマットされたデータを、レコードごとにトランスポートする」ものとすることも、当業者が容易に推考し得たことである。 ウ.(相違点4)について 下記(ア)?(オ)の事情にかんがみれば、引用例1記載発明のシステムを、「データ・ロードを『ファイル名の代わりにカーソル名を用いて、複数のデータ・ソース区画カーソルによって指示される複数のパラレル・ストリームによって複数の区画にパイプライン方式で』実行するもの」とすることも、当業者が容易に推考し得たことというべきである。 (ア)上記「ア.」で検討したように、引用例1記載発明におけるデータのロードを「ファイル名の代わりにカーソル名を用いて」実行するようにすること自体は、当業者が容易に推考し得たことである。 (イ)上記「2.」の「(2)」の「イ.」の欄に摘記したように、引用例2には、カーソルIDを使い分けることにより、複数のカーソルを使い分け、複数のカーソルによる並行したアクセスを行い得ることが記載されている。また、パイプライン方式により各種処理を行うことは周知である。 (ウ)上記引用例2に記載された複数のカーソルによる並行したアクセスや、周知のパイプライン方式による処理が、上記(ア)のように、引用例1記載発明におけるデータのロードを「ファイル名の代わりにカーソル名を用いて」実行するようにしたものにおいても有用な場合があることは、当業者に自明である。 (エ)上記引用例2に記載された複数のカーソルによる並行したアクセスや、周知のパイプライン方式による処理を、上記(ア)のように、引用例1記載発明におけるデータのロードを「ファイル名の代わりにカーソル名を用いて」実行するようにしたものにおいて採用することを妨げるべき事情はない。 (オ)上記引用例2に記載された複数のカーソルによる並行したアクセスや、周知のパイプライン方式による処理を、上記(ア)のように、引用例1記載発明におけるデータのロードを「ファイル名の代わりにカーソル名を用いて」実行するようにしたものにおいて採用する場合に、どの範囲のデータを1つのカーソルに割り当てるかといった事項や、データ・ソースのデータをターゲット・サイトにおいてどのように格納するかといった事項は、当業者がデータの使用目的等に応じて適宜決定すべき事項であり、上記「複数のカーソル」を「複数のデータ・ソース区画カーソル」と呼び得るものとしたり、上記「データのロード」を「複数の区画」に行うようにすることは、当業者が適宜なし得たことである。 エ.(相違点5)について 引用例1記載発明に、上記のように引用例2に示される技術や周知の技術を採用した場合に、ソース・サイト内のレコードのアンロードとターゲット・サイトにおけるレコードのロードを同時に行えない理由はなく、それを同時に行うようにすることは、普通のことである。 (2)本願発明の効果について 本願発明の構成によってもたらされる効果は、引用例1、2の記載事項や周知の事項から当業者ならば容易に予測することができる程度のものであって、格別のものとはいえない。 5.むすび 以上によれば、本願発明は、引用例1記載発明、引用例2の記載事項、及び周知の事項に基づいて、当業者が容易に発明をすることができたものであるから、特許法29条第2項の規定により特許を受けることができない。 したがって、本願は、他の請求項に係る発明について検討するまでもなく、拒絶されるべきものである。 よって、結論のとおり審決する。 |
| 審理終結日 | 2010-10-20 |
| 結審通知日 | 2010-10-26 |
| 審決日 | 2010-11-08 |
| 出願番号 | 特願2002-582394(P2002-582394) |
| 審決分類 |
P
1
8・
121-
WZ
(G06F)
|
| 最終処分 | 不成立 |
| 前審関与審査官 | 上嶋 裕樹 |
| 特許庁審判長 |
小曳 満昭 |
| 特許庁審判官 |
池田 聡史 長島 孝志 |
| 発明の名称 | リモート・データ・ソースからのデータ・ロード |
| 復代理人 | 正林 真之 |
| 代理人 | 上野 剛史 |