ポートフォリオを新規に作成して保存 |
|
|
既存のポートフォリオに追加保存 |
|
PDFをダウンロード |
審決分類 |
審判 査定不服 2項進歩性 取り消して特許、登録 G06F 審判 査定不服 特36条6項1、2号及び3号 請求の範囲の記載不備 取り消して特許、登録 G06F 審判 査定不服 特36条4項詳細な説明の記載不備 取り消して特許、登録 G06F |
---|---|
管理番号 | 1164363 |
審判番号 | 不服2003-999 |
総通号数 | 95 |
発行国 | 日本国特許庁(JP) |
公報種別 | 特許審決公報 |
発行日 | 2007-11-30 |
種別 | 拒絶査定不服の審決 |
審判請求日 | 2003-01-16 |
確定日 | 2007-10-02 |
事件の表示 | 平成 9年特許願第 80575号「データベース管理システム」拒絶査定不服審判事件〔平成10年10月13日出願公開、特開平10-275158、請求項の数(2)〕について、次のとおり審決する。 |
結論 | 原査定を取り消す。 本願の発明は、特許すべきものとする。 |
理由 |
1.手続の経緯、本願の請求項に係る発明 本願は、平成9年3月31日の出願であって、平成14年9月6日付けで拒絶理由通知がなされ、これに対して、同年11月14日付けの手続補正書により補正されたが、同年12月12日付けで拒絶査定された。これに対して、平成15年1月16日付けで審判請求がなされると共に、同年2月17日付けの手続補正書により補正されたが、当審において平成19年3月23日付けで拒絶理由通知がなされた。さらに、これに対して、同年5月25日付けの手続補正書により補正されたものであるところ、その特許請求の範囲の請求項に係る発明は、次に掲げるものである。 「【請求項1】必要なデータを複数のデータベースのいずれかから取得するためのデータベース管理システムにおいて、 単一の各データベースに対応して設けられ、対応するデータベースにアクセスするための単一又は複数のデータアクセス手段と、 各データ項目の名称とそのデータ項目のデータを取得すべき各データベースをアクセスする単一のデータアクセス手段との対応関係を記述した項目テーブル手段と、 指定されたデータ項目の名称に対応するデータアクセス手段を上記項目テーブル手段を参照して決定する決定手段と、 該決定手段にて決定されたデータアクセス手段を起動し、指定されたデータ項目のデータを取得するアクセス起動手段と を有するデータベース管理システム。 【請求項2】請求項1記載のデータベース管理システムにおいて、 各データアクセス手段がアクセスするデータベースから指定されたデータ項目の名称を含む所定数のデータ項目の名称について、当該所定数のデータ項目のデータが取得されるように構成するとともに、 データベースから取得された所定数のデータ項目のデータをデータ項目の名称と対応づけて蓄積する蓄積手段と、 指定されたデータ項目の名称に対応するデータ項目のデータが該蓄積手段に既に蓄積されているか否かを判定する判定手段と、 判定手段が該蓄積手段に指定されたデータ項目の名称に対応するデータ項目のデータが既に蓄積されていると判定したときに、指定されたデータ項目の名称に対応したデータアクセス手段を決定することなく該蓄積手段に蓄積された当該指定されたデータ項目の名称に対応するデータ項目のデータを取得する制御手段と を有するデータベース管理システム。」 2.原査定の拒絶の理由 原査定の拒絶の理由は、概略、下記のとおりである。 「この出願の下記の請求項に係る発明は、その出願前日本国内又は外国において頒布された下記の刊行物に記載された発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。 記 (引用文献等については引用文献等一覧参照) 【請求項1】引用文献1-4 (中略) 【請求項2】引用文献1-4 (中略) 引 用 文 献 等 一 覧 1.特開平2-12563号公報 2.特開平6-67867号公報 3.特開平5-197600号公報 4.特開平7-65032号公報」 3.当審の拒絶の理由 当審による平成19年3月23日付の拒絶理由の概略は、本件出願は、明細書及び図面の記載が不備のため、特許法第36条第4項及び第6項に規定する要件を満たしていない、というものである。 4.当審の判断 4.1.特許法第36条の要件について 本願の明細書及び図面の記載は、前記1.のとおり、平成19年5月25日付手続補正により補正された結果、特許法第36条第4項及び第6項第1、2号に規定する要件を満たすものとなった。 4.2.特許法第29条第2項の要件について 4.2.1.刊行物 原審の拒絶の理由で引用された前記刊行物1-4には、以下の事項が開示されている。 [刊行物1] 刊行物1には、情報処理装置の情報管理方式に関して、以下の事項が記載されている。 「【特許請求の範囲】 1、ホスト(10)と、端末(20)と、簡易言語により指定された処理内容および検索条件を画面に表示しこの端末に与える入力装置(30)と、上記端末の処理結果を編集して画面に表示する出力装置(40)とを備え、 上記ホストは、その所有する情報を保存する第一のデータベース(11)を含み、 上記端末は、その所有する情報を保存する第二のデータベース(21)と、上記処理内容および上記検索条件に基づいてデータ処理の制御を行いこの第二のデータベース内を検索して該当するレコードを受け取る制御部(23)を含むデータ処理手段(22)とを含む情報管理方式において、 上記データ処理手段は、処理対象データベースの格納場所を判別する判別部(25)と、この判別部の判別結果が上記ホスト側の場合に処理指令を上記ホストに送信しその検索結果を受信する通信部(24)と、この検索結果を受け取りまたは上記判別部の判別結果が上記端末側の場合に上記制御部の検索した該当するレコードを受け取りデータの結合および加工を行い上記出力装置に与える結合部(26)とを含み、 上記制御部は、上記判別部、上記通信部および上記結合部の制御を行う手段を含み、 上記ホストは、上記通信部の処理指令に基づいて上記第一のデータベース内を検索し、検索結果を返信するデータベース制御手段(12)を含むことを特徴とする情報管理方式。」 「 次に、保険業務における契約者-覧リストの作成を例にとり第1図?第3図を参照して具体的な処理の流れを説明する。まず、操作者は、入力装置30より処理内容(契約者-覧リスト作成)および検索条件(支部番号150)を含む指定情報61を指定する。 指定を受けたデータ処理手段22内の制御部23は契約者-覧リスト作成処理を契約者-覧リストの項目62および顧客データベース51、下位住所データベース52、契約内容データベース53へのアクセス処理を含んだ処理定義ロジックに変換する(Sl)。 制御部23の処理定義ロジックにしたがい、まず顧客データベース51の格納場所の判別を判別部25にて行う(S2)。判別部25からデータベース11内との判別結果を受け(33)、顧客データベースlOの検索条件下(支部番号150)の検索↑旨令の送信を通信部24にて行う(S6)。指令を受けたデータベース制御手段12はデータベース11内の顧客データベース51を検索し、該当レコードの内容をデータ処理手段22の通信部24に返信する(S7)。 受信した顧客データベース51の内容のうち制御部23は次の検索キーとして地区番号と契約者番号を受け取り、また結合部22は契約音名および生年月日を受け取り加工し契約者-覧リストロ3を出力装置40へ送る(S5)。 すべての該当するレコードの処理を終了しないので(S8)、下位住所データベース52の格納場所の判別を判別部25にて行う(S2)。判別部25よりデータベース21内との判別結果(S3)を受けた制御部23は、データベース21内の下位住所データベース52を検索キー101で検索し該当レコード内容を受け取る(S4)。結合部26は、下位住所データベース52の内容のうち住所を受け取り、契約者-覧リストロ3と結合し、契約者-覧リストロ4を出力装置40へ送る(S5)。」 [刊行物2] 刊行物2には、アプリケーションプログラムのデータベースアクセス方式に関して、以下の事項が記載されている。 「【請求項1】 アプリケーションプログラムにおいてデータベース管理システムのアクセス処理を行うアプリケーションプログラムのデータベースアクセス方式であって、 データベース管理システムの種別に依存しない形でインタフェース処理を行うアプリケーションプログラムインタフェースと、 複数の各々のデータベース管理システムに対してそれぞれにアクセス処理を行う各処理実行部と、 前記アプリケーションプログラムインターフェイスからの接続要求に基づいて操作対象のデータベース管理システムに対するアクセス処理を行う処理実行部とアプリケーションプログラムインターフェイスとの間の接続を行うサーバーとを備えることを特徴とするアプリケーションプログラムのデータベースアクセス方式。 【請求項2】 前記アプリケーションプログラムインターフェイスからの接続要求に基づいて、前記サーバーが処理実行部とアプリケーションプログラムインターフェイスとの間の接続を行う際に参照する各データベースに対する管理情報を格納したテーブルを更に備えることを特徴とする請求項1に記載のアプリケーションプログラムのデータベースアクセス方式。」 「【0022】アプリケーションプログラム(10)に備えられたアプリケーションプログラムインタフェース(11)は、データベース管理システムの種別に依存しないインタフェース処理を行い、各処理実行部(13)が複数の各々のデータベース管理システムに対してそれぞれのアクセス処理(5,7)を行う。また、サーバー(12)は、アプリケーションプログラムインターフェイス(11)からの接続要求に基づいて、対象のデータベース管理システムに対するアクセス処理を行う個別の処理実行部(13a,13b)と接続要求を出したアプリケーションプログラムインターフェイス(11)との間の接続を行う。 【0023】このため、サーバーが処理実行部とアプリケーションプログラムとの接続を行う際に参照する各データベースに対応する管理情報を格納したテーブル(14)が備えられおり、サーバー(12)は、テーブル(14)の内容を参照して、サーバーが処理実行部とアプリケーションプログラムインターフェイスとの間の接続を行う。」 「【0036】また、処理実行部エントリテーブル14は、サーバー12がアプリケーションプログラム10からのデータベース接続要求に対して接続処理を行う場合に参照される管理情報が登録されているテーブルであり、接続要求されるDBMS名に対して、DBMSベンダ用処理実行部名を対応させて登録してある。アプリケーションプログラム10における処理の中からの接続要求に対して、DBMSベンダ用処理実行部13の何れのDBMSのアクセス処理部(13a,13b)との接続を行うかの対応が参照される。 【0037】図3は処理実行部エントリテーブルの構成例を示す図である。処理実行部エントリテーブル14は、具体的に説明すると、図3に示すように、DBMSの名前を登録するDBMS名フィールド31と、対応DBMSのアクセスツールを登録するDBMSアクセス処理実行部名フィールド32とから構成されており、DBMS名に対応して起動すベきDBMSアクセス処理実行部の名前を登録してあるエントリテーブルである。また、この分散型データベースシステムにおいて接続可能な各々のDBMSを管理している管理情報となっている。前述したように、アプリケーションプログラムインタフェース11からDBMS名を指定した接続要求が発行された場合、サーバー12が、処理実行部エントリテーブル14を参照して、DBMS名から対応するDBMSアクセス処理実行部プログラム名を知り、該当のDBMSアクセス処理実行部プログラムを起動する。 【0038】次に、このような動作環境で動作するアプリケーションプログラム10におけるデータベースに対するアクセス処理の概略を説明する。まず、アプリケーションプログラム10の処理において、データベース操作での共通データ型の解釈処理が行なわれ、DBMSのアクセス処理を行うステップに処理が進行すると、アプリケーションプログラムインタフェース11が、アプリケーションプログラム本体部分とのインタフェース処理により、サーバー12に対してDBMSに接続要求を発行する。サーバー12は、アプリケーションプログラムインターフェイス11からの接続要求に基づいて、処理実行部エントリテーブル14における対応情報を参照して、対象のデータベース管理システムに対するアクセス処理を行うDBMSベンタ用処理実行部13の対応のアクセス処理部を起動し、次にアプリケーションプログラムインタフェース11を介してアプリケーションプログラム10の本体部との間の接続を行う。これにより、接続されたDBMSベンタ用処理実行部13の例えばDBMSアクセス処理部13bは、操作対象のDBMSに対してのアクセス処理を行う。」 [刊行物3] 刊行物3には、データベースアクセス方式に関して、以下の事項が記載されている。 「【請求項1】 データベースをアクセスするためのメッセージを生成する共通データベースアクセスィンタフェースと、 前記共通データベースアクセスインタフェースからのメッセージ受信し、その内容に応じたデータベースアクセスを行う共通データベースアクセス手段と、 互いに異なるデータベースアクセスインタフェースと、 前記互いに異なるデータベースアクセスインタフェースを用いて作成されているデータベースアクセス処理を行う固有データベースアクセスインタフェースとを有することを特徴とするデータベースアクセス方式。」 [刊行物4] 刊行物4には、データベース言語変換機能を持つ情報処理システムに関して、以下の事項が記載されている。 「【請求項1】 固有形式のデータベース言語をサポートし、固有形式のデータからなるデータベースを管理するデータベース管理システムが搭載された複数の第1のサーバ計算機と、 この複数の第1のサーバ計算機が接続されている第1のネットワークと、 標準形式のデータベース言語によるデータベース問い合わせを行う少なくとも1つのクライアント計算機と、 この少なくとも1つのクライアント計算機が接続されている第2のネットワークと、 標準形式のデータベース言語を予め定められた固有形式のデータベース言語に変換するための第1の変換ルーチンが前記各データベース管理システムに対応してそれぞれ登録された第1の変換ルーチン登録手段と、前記データベース管理システムからのデータベース問い合わせの結果データを標準形式に変換するための第2の変換ルーチンが同管理システムに対応してそれぞれ登録された第2の変換ルーチン登録手段と、前記第1のサーバ計算機のデータベース管理システムにより管理されるデータベース、同管理システムに対応する前記第1の変換ルーチン、同管理システムに対応する前記第2の変換ルーチン、及び同管理システムが搭載されている前記第1のサーバ計算機のネットワークアドレスを指定する情報が登録された複数のエントリからなる変換規則管理テーブルとを有する、前記第1及び第2のネットワークに接続された第2のサーバ計算機であって、 前記クライアント計算機から送信された前記標準形式のデータベース言語を受信して、この受信データベース言語の指定するデータベース名を持つ前記変換規則管理テーブル内エントリをサーチして、当該エントリ情報の示す前記第1の変換ルーチンを前記第1の変換ルーチン登録手段から呼び出し、この変換ルーチンをもとに前記受信データベース言語の指定するデータベース名のデータベースを管理する前記データベース管理システムに固有の形式のデータベース言語に変換した後、この固有形式のデータベース言語を、当該エントリ情報の示すネットワークアドレスを持つ前記第1のサーバ計算機に送信し、この固有形式データベース言語の実行結果として、送信先の前記第1のサーバ計算機から返される固有形式の結果データを、当該エントリ情報の示す前記第2の変換ルーチン登録手段内の第2の変換ルーチンをもとに標準形式のデータに変換して、前記受信データベース言語の送信元の前記クライアント計算機に返す第2のサーバ計算機とを具備することを特徴とするデータベース言語変換機能を持つ情報処理システム。」 4.2.2.本願の請求項に係る発明と刊行物1-4に記載された発明との対比・検討 本願の請求項に係る発明は、「各データ項目の名称とそのデータ項目のデータを取得すべき各データベースをアクセスする単一のデータアクセス手段との対応関係を記述した項目テーブル手段」を発明特定事項として有している。 一方、前記刊行物1-4には、本願の請求項に係る発明の前記発明特定事項は開示されておらず、また、示唆もされていない。 確かに、刊行物2には、「サーバーが処理実行部とアプリケーションプログラムインターフェイスとの間の接続を行う際に参照する各データベースに対する管理情報を格納したテーブル」(【請求項2】)を備える旨の記載があり、このテーブルは発明の詳細な説明の段落【0037】によれば、「DBMS」と「DBMSアクセス処理実行部プログラム」との対応を示すものであって、刊行物2における「DBMSアクセス処理実行部プログラム」は本願の請求項に係る発明における「データアクセス手段」に相当するものであるということはできるが、「DBMS」は本願の請求項に係る発明における「データ項目の名称」に相当するものではなく、刊行物2におけるテーブルは、「データ項目の名称」と「データアクセス手段」との対応を示すものではないから、刊行物2には、本願の請求項に係る発明の前記発明特定事項である「各データ項目の名称とそのデータ項目のデータを取得すべき各データベースをアクセスする単一のデータアクセス手段との対応関係を記述した項目テーブル手段」に関する事項を開示し又は示唆する記載はない。 そして、本願の請求項に係る発明は「データ項目の名称」と「データアクセス手段」との対応関係を記述した「項目テーブル手段」を有することにより、「対象とするデータベースが追加になっても、その追加になったデータベースに対応するデータアクセス手段を追加して、このデータアクセス手段とデータ項目との対応関係を項目テーブル手段に追記することにより新たなデータベース管理システムを構築することができる。」との効果を奏するものである。 したがって、本願の請求項に係る発明は、前記刊行物1-4に記載された各発明に基づいて当業者が容易に発明をすることができたものであるということはできない。 5.むすび 以上のとおりであるから、本願発明が特許法第29条第2項の規定により特許を受けることができないものとする原査定の理由、並びに、本件出願は特許法第36条第4項及び第6項に規定する要件を満たしていないとする当審の拒絶の理由によっては本願を拒絶することはできない。 また、他に本願を拒絶すべき理由を発見しない。 よって結論のとおり審決する。 |
審決日 | 2007-09-20 |
出願番号 | 特願平9-80575 |
審決分類 |
P
1
8・
536-
WY
(G06F)
P 1 8・ 537- WY (G06F) P 1 8・ 121- WY (G06F) |
最終処分 | 成立 |
前審関与審査官 | 高瀬 勤 |
特許庁審判長 |
小林 信雄 |
特許庁審判官 |
森次 顕 山本 穂積 |
発明の名称 | データベース管理システム |
代理人 | 伊東 忠彦 |