【事件の表示】
　平成１０年特許願第　１８６３７号「データベースへのファイルシステムインタフェース」拒絶査定不服審判事件〔平成１０年　９月１４日出願公開、特開平１０−２４７１５５〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願は、平成１０年１月３０日（パリ条約による優先権主張１９９７年１月３１日、アメリカ合衆国）の出願であって、平成２０年４月２５日付けで拒絶査定がなされ、これに対し、同年７月９日に拒絶査定不服審判の請求がなされるとともに、同日付けで手続補正がなされたものである。
　
２．本願発明
　本願の請求項１に係る発明は、平成２０年７月９日付けの手続補正書により補正された特許請求の範囲の請求項１に記載されたとおりの次のものと認める。（以下、「本願発明」という。）
「データベース内の情報にアクセスするためにコンピュータシステム上で遂行される方法であって、
　前記コンピュータシステムが、データベースオブジェクトに対応する情報を、１つ以上のファイルシステムオブジェクトとして使用可能にするステップと、
　前記データベースが、前記使用可能なファイルシステムオブジェクトに対応するファイルシステム要求を、アプリケーションから受信するステップと、
　前記コンピュータシステムが、前記アプリケーションからの前記ファイルシステム要求を、データベース動作に変形するステップを備え、前記コンピュータシステムが、前記情報を、１つ以上のファイルシステムオブジェクトをもつファイル・システム構造として使用可能にするステップは、前記アプリケーションに対して透過的であり、
　前記データベースオブジェクトに関連する情報を、ファイルシステムオブジェクトとして前記アプリケーションに戻すステップを更に備えている、
　方法。」
　
３．引用例
　原査定の拒絶の理由に引用された特開平８−３１４７８７号公報（以下、「引用例」という。）には、図面とともに次の事項が記載されている。
　
Ａ．「【０００１】
【産業上の利用分野】本発明は、コンピュータネットワーク上で分散したデータファイルに対して特にフラットデータファイル、データベースの区別なくアクセスできる方式に関する。」
　
Ｂ．「【００１３】即ち、本発明は、分散ファイルシステムにおいて、ネットワーク内の複数のコンピュータ上に存在するアプリケーションシステムのそれぞれのアプリケーションプログラム部がアクセスするフラットデータファイル及びデータベースファイル（ＤＢＭＳ）のロケーション情報、ファイルアクセス諸元情報を一元管理し、ネットワークコンピュータ上にそれぞれ設定し、業務アプリケーションプログラム部立ち上げ時に、上記ロケーション管理ファイルロード機能を通して読み込み、本業務アプリケーションプログラム部がアクセスするフラットデータファイル又はデータベース（ＤＢＭＳ）とのアクセスパスを確立し、実ファイルアクセスに備える。
【００１４】業務アプリケーションプログラム部より上記ロケーションファイルをロードする時は業務アプリケーションが必要とするファイル名称をキーとしてそれぞれのフラットデータファイル及びデータベース（ＤＢＭＳ）情報をロードし、ファイルアクセスパス確立機能部にて行う。
【００１５】前述したファイルアクセスパス確立機能部にてフラットデータファイル及びデータベース（ＤＢＭＳ）の存在場所を意識することなく、業務アプリケーションプログラム部はローカルにアクセスしたいフラットデータファイルが存在すると同様にアクセス命令をコールするだけでよい。業務アプリケーションプログラム部がアクセスしたいデータがデータベース（ＤＢＭＳ）であった場合は、ファイルアクセス命令インターフェースにてデータベースＳＱＬ変換機能部にてアクセス命令をデータベース用ＳＱＬに変換してデータベース（ＤＢＭＳ）をアクセスすることを可能にする。」
　
Ｃ．「【００１８】図１は本発明が適用されるコンピュータネットワークシステムの概略図を示している。データが各コンピュータ間を伝送されるために必要なデータ伝送路２０、コンピュータからなるデータ処理装置１１、１４、及び１７と、データ処理装置１１、１４、及び１７内の業務アプリケーションプログラム部（ＡＰ）１３、１６、及び１９がアクセスするデータが格納されている磁気ディスク１２、１５、及び１８から構成されている。
【００１９】図２は本発明に従って業務アプリケーションプログラム部２１（図１の業務アプリケーションプログラム部１３、１６、及び１９の内の一つである。）よりコールする時の概要を図示したものである。業務アプリケーションプログラム部２１より、ファイルアクセスパス確立機能部２２を読み出し、ファイルロケーション管理ファイル２３（図１の磁気ディスク１２に格納されている。）に登録されている情報より、業務アプリケーションプログラム部２１でアクセス対象となっているデータファイル又はデータベース（ＤＢＭＳ）のアクセスパスを確立する流れを示している。
【００２０】図３は図２のファイルロケーション管理ファイル２３を示しており、業務アプリケーションプログラム部２１がアクセスするデータファイル又はデータベース（ＤＢＭＳ）等を図１のコンピュータネットワーク上に配置している情報（ロケーション情報）、アクセス形態情報、ファイル種別等が登録されており、それらの情報はアプリケーション名を検索キーとして、そのアプリケーションがアクセスの対象とするファイル名、ファイル種別（フラットファイルかデータベースか）、またそのファイルのアクセス形態、ファイル諸元、どのコンピュータ上にそのアクセス対象ファイルが存在するかを見るために、ホスト名等が検索できる。
【００２１】それらの情報より前述したファイルアクセスパス確立機能部２２は、アクセス形態に登録されている、ファイルアクセス方式にのとってアクセスパスを確立する。・・・（後略）・・・」
　
Ｄ．「【００２６】図５はファイルアクセス命令の内部処理を表しいる。このファイルアクセス命令とは通常コンピュータシステム上でデータファイル読み込み処理書き込み処理のことを言う。
【００２７】ステップ５１にて前述したファイルロケーション管理ファイル２３（図３）にファイル種別がフラットデータファイルと登録されているか、データベース（ＤＢＭＳ）と登録されているかを判断し、フラットデータファイルであった場合は、ステップ５３において、業務アプリケーションプログラム部２１にて指定されたデータファイルの読み込み処理（又は書き込み処理）を行う。
【００２８】ファイル種別がデータベースファイル（ＤＢＭＳ）と判断された場合は、ステップ５２においてデータベースＳＱＬ変換機能リンク処理を行った後、上述のステップ５３における処理を行う。
【００２９】図６にデータベースＳＱＬ変換機能の概略図を示している。データベースＳＱＬ変換機能６１にて業務アプリケーションプログラム部２１の前述したファイルアクセス命令から、例えば読み込み命令ＲＥＡＤ、書き込み命令ＷＲＩＴＥ、上書き命令ＲＥＷＲＩＴＥ、削除命令ＤＥＬＥＴＥ等からデータベース６２をアクセスするためのＳＱＬに変換する。変換時、ある一定の規則にのとって変換される。
【００３０】図７に変換の規則を定義したデータベースＳＱＬ変換テーブルのイメージ図を示す。
【００３１】コンピュータシステムにおいて業務アプリケーションプログラム部からデータファイルをアクセスする場合、通常、データベース（ＤＢＭＳ）と異り、図７で示したような規則性のあるアクセスになる。そこでデータベース（ＤＢＭＳ）をアクセスする場合も業務アプリケーションプログラム部からフラットデータファイルをアクセスする時と同様なアクセス方式を図７のように定義することができる。もちろん、データベース（ＤＢＭＳ）特有のアクセス方法を使いたい場合には、図７のデータベースＳＱＬ変換テーブルに登録することにより業務アプリケーションプログラムを、フラットデータファイルアクセス時からデータベース（ＤＢＭＳ）アクセス用にカストマイズする必要はない。」
　
　上記Ｂの段落【００１５】には、ファイルアクセスパス確立機能部にて、業務アプリケーションプログラム部は、データベース（ＤＢＭＳ）に対するアクセスを、フラットデータファイルにアクセスするのと同様にアクセス命令をコールするだけでよいことが示されていることから、引用例の「コンピュータネットワークシステム」は、「データベースへのアクセスを、フラットデータファイルへのアクセスとして扱うことを可能にするステップ」を備え、このステップは、「業務アプリケーションプログラム部に対して透過的である」といえる。
　
　よって、上記Ａ〜Ｄの記載及び関連する図面を参照すると、引用例には、次の発明が記載されているものと認められる。（以下、「引用例記載の発明」という。）
「データベースにアクセスするためにコンピュータネットワークシステム上で遂行される方法であって、
　前記コンピュータネットワークシステムが、データベースへのアクセスを、フラットデータファイルへのアクセスとして扱うことを可能にするステップと、
　データベースＳＱＬ変換機能部が、前記扱うことを可能にしたフラットデータファイルに対応するファイルアクセス命令を、業務アプリケーションプログラム部から受信するステップと
　前記データベースＳＱＬ変換機能部が、前記業務アプリケーションプログラム部からの前記ファイルアクセス命令を、データベースをアクセスするためのＳＱＬに変換するステップを備え、
　前記コンピュータネットワークシステムが、データベースへのアクセスを、フラットデータファイルへのアクセスとして扱うことを可能にするステップは、業務アプリケーションプログラム部に対して透過的である、
　方法。」
　
４．対比
　本願発明と引用例記載の発明とを対比すると、次のことがいえる。
　
（あ）引用例記載の発明において、「データベースにアクセスする」とは、データベースに格納されている情報にアクセスすることであるといえる。そして、引用例記載の発明における「コンピュータネットワークシステム」は、本願発明における「コンピュータシステム」に相当するものであるから、引用例記載の発明における「データベースにアクセスするためにコンピュータネットワークシステム上で遂行される方法」は、本願発明における「データベース内の情報にアクセスするためにコンピュータシステム上で遂行される方法」に相当するものである。
　
（い）引用例記載の発明における「データベース」及び「フラットデータファイル」は、本願発明における「データベースオブジェクト」及び「ファイルシステムオブジェクト」に相当するものである。そして、引用例記載の発明において、データベースをアクセスすることにより得られる情報は、本願発明における「データベースオブジェクトに対応する情報」に相当するものであるといえる。
　一般に、データベースは、必要とする情報に応じた問い合わせを行うことにより、種々の情報を取得することができるものであるから、引用例記載の発明において「データベースへのアクセスを、フラットデータファイルへのアクセスとして扱うこと」は、「データベースに対する種々の情報を取得するためのアクセスを、１つ以上のフラットデータファイルへのアクセスとして扱うこと」を意味するものであり、換言すると「データベースをアクセスすることにより得られる種々の情報を、１つ以上のフラットデータファイルとして使用可能にすること」を意味するものである。
　よって、引用例記載の発明における「コンピュータネットワークシステムが、データベースへのアクセスを、フラットデータファイルへのアクセスとして扱うことを可能にするステップ」は、本願発明における「コンピュータシステムが、データベースオブジェクトに対応する情報を、１つ以上のファイルシステムオブジェクトとして使用可能にするステップ」に相当するものである。
　
（う）引用例記載の発明における「ファイルアクセス命令」及び「業務アプリケーションプログラム部」は、本願発明における「ファイルシステム要求」及び「アプリケーション」に相当するものである。
　そして、本願発明における「データベース」は、「ファイルシステム要求」を受信する機能を有することから、その機能部分を「受信手段」と呼び得るものである。また、引用例記載の発明における「データベースＳＱＬ変換機能部」も、「ファイルシステム要求」を受信する機能を有することから、その機能部分を「受信手段」と呼び得るものである。
　
（え）引用例記載の発明における「データベースＳＱＬ変換機能部」は、「コンピュータネットワークシステム」の構成要素の一部であるから、「コンピュータネットワークシステム」が、「業務アプリケーションプログラム部からのファイルアクセス命令を、データベースをアクセスするためのＳＱＬに変換」しているといえる。
　そして、引用例記載の発明において「データベースをアクセスするためのＳＱＬに変換」することは、本願発明における「データベース動作に変形する」ことに相当するものである。
　
　上記（あ）〜（え）の事項を踏まえると、本願発明と引用例記載の発明とは、次の点で一致し、また、相違するものと認められる。
　
（一致点）
　本願発明と引用例記載の発明とは、ともに、
「データベース内の情報にアクセスするためにコンピュータシステム上で遂行される方法であって、
　前記コンピュータシステムが、データベースオブジェクトに対応する情報を、１つ以上のファイルシステムオブジェクトとして使用可能にするステップと、
　受信手段が、前記使用可能なファイルシステムオブジェクトに対応するファイルシステム要求を、アプリケーションから受信するステップと、
　前記コンピュータシステムが、前記アプリケーションからの前記ファイルシステム要求を、データベース動作に変形するステップを備え、前記コンピュータシステムが、前記情報を、１つ以上のファイルシステムオブジェクトとして使用可能にするステップは、前記アプリケーションに対して透過的である、
　方法。」
である点。
　
（相違点）
　相違点１：「受信手段」の機能を、本願発明においては、「データベース」が奏するのに対し、引用例記載の発明においては、「データベースＳＱＬ変換機能部」が奏する点。
　
　相違点２：本願発明は、「データベースオブジェクトに対応する情報」を「ファイル・システム構造」として使用可能にしているに対し、引用例記載の発明は、そのようなものとはされていない点。
　
　相違点３：本願発明は、「データベースオブジェクトに関連する情報を、ファイルシステムオブジェクトとして前記アプリケーションに戻すステップ」を備えているのに対し、引用例には、業務アプリケーションプログラム部にどのように戻すのかについては言及されていない点。
　
５．当審の判断
　そこで、上記相違点１〜３について検討する。
　
（相違点１について）
　本願発明は、アプリケーションから受信する機能を含めて、「データベース」と呼んでいるのに対し、引用例記載の発明は、業務アプリケーションプログラム部から受信する機能を奏する構成を、「データベース」には含めずに「データベースＳＱＬ変換機能部」と呼んでいるにすぎず、表現上の差異でしかない。
　よって、引用例記載の発明においても、「データベースＳＱＬ変換機能部」をも含めて「データベース」と呼ぶようにすることにより、「受信手段」の機能を「データベース」が奏するようにすることは、当業者が適宜なし得ることである。
　
（相違点２について）
　上記４．（い）で検討したように、引用例記載の発明は、データベースをアクセスすることにより得られる種々の情報を、１つ以上のフラットデータファイルとして使用可能にするものである。そして、引用例の上記Ｂに記載されているように、引用例記載の発明は分散ファイルシステムに関するものであるから、「１つ以上のフラットデータファイル」を「１つ以上のフラットデータファイルをもつファイル・システム構造」として扱うことにより、引用例記載の発明における「データベースオブジェクトに対応する情報」を「ファイル・システム構造」として使用可能にすることは、当業者が適宜なし得ることである。
　
（相違点３について）
　引用例記載の発明は、フラットデータファイルとデータベースを区別なくアクセスできるようにするために、フラットデータファイルにアクセスするのと同様にデータベースにアクセスすることができるようにするものであるから、データベースにアクセスして取得した情報をフラットデータファイルとして業務アプリケーションプログラム部に戻すことは、ごく自然なことである。
　よって、引用例記載の発明において、「データベースオブジェクトに関連する情報を、ファイルシステムオブジェクトとして前記アプリケーションに戻すステップ」を備えるようにすることは、当業者が適宜なし得ることである。
　
（本願発明の作用効果について）
　そして、本願発明の構成によってもたらされる効果も、引用例記載の発明から当業者が容易に予測することができる程度のものであって、格別のものとはいえない。
　
６．むすび
　以上のとおり、本願発明は、引用例記載の発明に基いて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　したがって、本願は、他の請求項について検討するまでもなく、拒絶されるべきものである。
　よって、結論のとおり審決する。