【事件の表示】
　平成　２年特許願第２３１４４６号「データベース処理装置および処理手順生成方法」拒絶査定不服審判事件〔平成　４年　４月１４日出願公開、特開平　４−１１２２４０〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１　経緯
　１）出願日　　　　　　　：平成 2年 8月31日
　２）拒絶査定（起案日）　：平成15年 4月25日
　３）審判請求書(提出日） ：平成15年 6月 5日
　４）手続補正書(提出日） ：平成15年 7月 2日（請求の理由の補正）
　５）拒絶理由（起案日）　：平成15年10月10日
　６）意見書（提出日）　　：平成15年12月22日
　７）手続補正書(提出日)　：平成15年12月22日
　
　
第２　本願発明
　本願発明は、平成15年12月22日付で補正された、特許請求の範囲の請求項１，２に記載の次のとおりのもの（以下、それぞれ、本願発明１，２という。）である。
「【請求項１】　リレーショナルデータベース管理システムにおいて複数の格納構造をサポートするデータベース処理装置において，
　格納構造の種類ごとに，それを構成する基本データ編成の組み合わせに関する情報である構成基本データ編成，組み合わせに関するライブラリ部品名および組み立てパターン名を含む情報を記憶するディクショナリと，
　個々の基本データ編成に対するアクセスメソッドを部品化した基本データ編成のアクセス部品およびそのアクセス部品の組み合わせに関するライブラリ部品の情報を記憶するアクセス部品ライブラリと，
　データベースに対する問い合わせに対して，前記ディクショナリとアクセス部品ライブラリとを参照し，格納構造を構成する基本データ編成のアクセス部品，組み合わせに関するライブラリ部品を組み合わせることにより，いくつかの採択可能なデータベースの処理手順を生成し，採択可能なデータベースの処理手順が複数ある場合には，それらの各処理手順中で用いられた基本データ編成のアクセス部品の実行コストを評価するコスト評価部品を使って，各データベースの処理手順ごとに実行コストを評価し，前記採択可能な複数のデータベースの処理手順の中から最適な処理手順を選択する最適化処理部とを備え，
　基本的なデータ編成の組み合わせによるデータベースの格納構造をもとに，最適化処理におけるアクセススケジュールを生成するようにしたことを特徴とするデータベース処理装置。
【請求項２】　リレーショナルデータベース管理システムにおいて複数の格納構造をサポートするデータベース処理装置におけるデータベース処理手順生成方法において，
　格納構造の種類ごとに，それを構成する基本データ編成の組み合わせに関する格納構造定義情報を記憶するディクショナリから，問い合わせに関係する基本データ編成の組み合わせに関する情報の格納構造定義情報を取り出す処理過程と，
　問い合わせに関係する複数の格納構造定義のそれぞれに関して，基本データ編成のアクセス部品により，生成するデータベース処理手順の一部を構成するアクセス手順を生成する処理過程と，
　問い合わせ全体に対する採択可能ないくつかのデータベース処理手順を，前記アクセス手順の組み合わせによって生成する処理過程と，
　採択可能なデータベースの処理手順が複数ある場合には，それらの各処理手順中で用いられた基本データ編成のアクセス部品の実行コストを評価するコスト評価部品を使って，各データベースの処理手順ごとに実行コストを評価し，前記採択可能な複数のデータベースの処理手順の中から最適な処理手順を選択する処理過程とを有する
　ことを特徴とするデータベース処理手順生成方法。」
　
　
第３　刊行物に記載の発明
１．刊行物１
　本件出願前に、外国において頒布された刊行物であり、前記平成15年10月　9日付の拒絶理由で示した、
 D. S. BATORY, Modeling the Storage Architectures of　Commercial Database Systems, ACM Transactions on Database Systems, Vol. 10, No. 4, December 1985, pages 463-528.
（以下、刊行物１という。）には、関連する図面とともに、次の記載がある。
ア．「The problems in using current models clearly indicate that some fundamental principles of database system implementation are not well understood. A careful examination of several commercial DBMSs reveals that current models presume conceptual-to-internal mappings are simple. That is, given a set of conceptual files and links, there is an obvious mapping to their internal counterparts. In almost all commercial and specialized DBMSs this is definitely not the case.
 In this paper we present the transformation model (TM), a model of physical databases that makes conceptual-to-internal mappings explicit. We identify a set of primitive mappings, called elementary transformations, and show how compositions of these transformations can be used to accurately express the storage architectures of operational DBMSs. By storage architecture we mean the combination of conceptual-to-internal mappings, file structures, and record-linking mechanisms that define a physical database. As examples of the TM’s practicality, we show how the diverse and complex storage architectures that underlie three commercial DBMSs-namely, INQUIRE, ADABAS, and SYSTEM 2000 can be defined in a precise, systematic, and simple way. Models of other commercial DBMSs-relational (MRS, INGRES), network (IDMS, DMS-llOO), and statistical (RAPID, ALDS, CREATABASE)-are presented in [7, 81 and [9]. A preliminary model of IMS has also been developed ([8]).
 A primary goal of this paper is to explain conceptual-to-internal mappings of data. Mappings of operations (e.g., record retrieval, insertion, deletion) are discussed only briefly, but are considered in more detail in [9] and [86].」
（審決仮訳：
　現在のモデルを使用するに当たっての問題は、データ・ベース・システム・インプリメンテーションのいくつかの基本原則が良く理解されていないことであることを明示的に示す。いくつかの商用DBMSの注意深い調査によって、現在のモデルはconceptual-to-internalマッピングを単純なものとみなしていることが明らかになります。 すなわち、1セットのconceptual fileおよびlinkを与えられると、それらの内部相当物に明白なマッピングがあるということです。ほとんどすべての商用及び特定用途のDBMSは、明確にそうではありません。
  この論文では、私たちはtransformation model (TM)、conceptual-to-internalマッピングを明示的にする物理的なデータ・ベースのモデル、を示します。私たちは、elementary transformationsと呼ばれる原始的なマッピングのセットを特定し、運用されているDBMSの記憶アーキテクチャーを正確に表現するために、どのように、これらのtransformationsの合成を使用することができるかを示します。記憶アーキテクチャーは、物理的なデータ・ベースを定義する、conceptual-to-internalマッピング、ファイル構造、及びレコードをリンクするメカニズムの組み合わせを意味します。TMが現実的なものであることの例として、私たちは、それぞれ、 INQUIRE, ADABAS, and SYSTEM 20003のつの商用DBMSの基礎となる、記憶アーキテクチャーが、如何に多様で、複雑であるか、そしてそれらを正確に、システマチックに、そして簡単に定義することができるか、を示します。 他の商用モデルである、DBMSs-relational (MRS, INGRES)，network (IDMS, DMS-llOO)，そしてstatistical (RAPID, ALDS, CREATABASE) は引用論文［7］，［8］，[9]において示されます。IMSの予備モデルも開発されています(引用論文[8])。
　この論文の主要なゴールはデータのconceptual-to-internalマッピングについて説明することです。オペレーション(例えば、レコード検索、挿入、削除)のマッピングは、きわめて簡潔に議論されるが、引用論文[9]および[86]においては、より詳細に考慮されます。）
　
 イ．「Physical databases can be decomposed into a collection of internal files and internal links. An internal file is a set of records that are instances of a single record type. A relationship between two or more internal files is an internal link. Internal links can be understood as generalizations of CODASYL sets; each internal link relates records of one file, called the parent file, to records of other files, called child files. (We draw a distinction here between conceptual files and links, which are defined in database schemas, from internal files and internal links. We will see later that they are quite different.)
  The basic structures of a physical database are simple files and linksets. A simple file is a structure that organizes records of one or more internal files.  Classical simple file structures include hash-based, indexed-sequential, B+ trees, dynamic hash-based, and unordered files. A linkset is a structure that implements one or more internal links. Classical linkset structures include pointer arrays, inverted lists, ring lists, and hierarchical sequential lists. Linksets also deal with the clustering of child records around their parent records (i.e., sequential placement or [24] or “store near” [22]). Catalogs of recognized simple files and linksets are given in Appendix II.
  The structure of a physical database can therefore be specified by (1) decomposing the database into its internal files and links and (2) assigning each internal file to a simple file structure and each internal link to a linkset structure.　Classical examples of decomposition are presented in the next section, along with the introduction of notation which will be used extensively later.」
（審決仮訳：
  物理的なデータ・ベースは、 internal file及びinternal linkの集まりへ分解することができます。一つのinternal fileは、シングル・レコード型の複数のインスタンスである複数のレコードの集合です。 二つかそれ以上のinternal file間の関係はinternal linkです。古典的なsimple file構造は、ハッシュに基づいた、インデックスされたシーケンシャルな、B+木の、動的ハッシュに基づいた、または整列されていない、fileを含んでいます。古典的なlinkset構造は、ポインター配列、反転リスト、リング・リスト、および階層順次リストを含んでいます。Linksetは、親レコードの周りの子レコードのクラスタリング(つまり引用論文[24]に記載の連続する配置、又は、引用論文[22]に記載のStore near)も扱います。認識されたsimple fileおよびlinksetのカタログは付録IIの中で与えられます。
　物理的なデータ・ベースの構造は、したがって、(1)データ・ベースをinternal fileとlinkへ分解し、そして、(2)internal fileをsimple file構造およびlinkset構造へのそれぞれの内部リンクを割り当てることにより、指定することができます。分解の古典的例は、広範囲にその後使用される記法の導入に加えて、次のセクションの中で示されます。）
　
ウ．「3. THE TRANSFORMATION MODEL
A primary function of a DBMS is to map conceptual files and operations to their internal counterparts. INGRES [76], for example, maps relations and relational operations onto inverted files. SYSTEM R [24] and RAPID [83] also begin with relations, but SYSTEM R maps to inverted files with record clustering and RAPID maps to transposed files.
  An intuitive understanding of conceptual-to-internal mappings is gained by recognizing a mapping as a sequence of database definitions that are progressively more implementation-oriented. The sequence begins with definitions of the conceptual files and their links, and ends with definitions of the internal files and their links.  Each intermediate definition contains both conceptual and internal elements, and thus can be identified with a level of abstraction that lies between the “pure” conceptual and “pure” internal levels. In this way physical databases can be modeled at different levels of abstraction.
  Distinguishing different levels in a DBMS and mapping from one level to an adjacent level is usually straightforward. In the DBMSs that the author has studied, only ten different primitive mappings, henceforth called elementary transformations, have been utilized. Elementary transformations can be used singly or in combination to map files and links from one level of abstraction to a lower level. In principle, this means that the conceptual-to-internal mappings of a software-based DBMS can be modeled by (1) taking the generic conceptual files and links that the DBMS supports and (2) applying a well-defined sequence of elementary transformations to produce the internal files and links of the DBMS. In the case of INGRES, SYSTEM R, and RAPID, all begin with the same conceptual files (i.e., relations), but each is distinguished by different sequences of transformations (and hence different sets of internal files and links).  We explain each of the elementary transformations in detail shortly.」
（審決仮訳：　
３．　TRANSFORMATIONモデル
  DBMSの主要な機能はそれらの内部相当物にconceptual file及びオペレーションをマップすることです。引用論文のINGRES[76]では、例えばリレーションと、リレーショナル・オペレーションとインバーテッド・ファイルへマップします。引用論文SYSTEM R[24]およびRAPID[83]は、リレーションに始まり、SYSTEM Rはレコード・クラスタリングのインバーテッド・ファイルへマップし、RAPIDは、転置されたファイルにマップします。
  conceptual-to-internalマッピングについての直感的理解は、マッピングを、漸次、インプリメンテーション・オリエンテッドなデータ・ベース定義の一つのシーケンスと認識することにより獲得されます。そのシーケンスは、conceptual fileおよびそれらのlinkの定義から始まり、internal fileおよびそれらの linkの定義で終わります。個々の中間の定義は概念と内部要素を含んでおり、それ故に、「純粋」概念的と「純粋」内部的の間にある抽象的レベルで特定することができます。このようにして、物理的なデータ・ベースは、抽象度の異なるレベルにモデル化することができます。
  DBMS中の異なるレベルを区別することと、あるレベルを隣接するレベルにマッピングすることは、通常は、簡単です。著者が研究したDBMSでは、今後elementary transformationsと呼ばれる10の異なる原始的なマッピングだけが利用されていました。Elementary transformationsは、単独で、あるいは組み合わせで、fileとlinkを、ある抽象度のレベルからより低いレベルにマップするために使用することができます。原則として、これは、ソフトウェア・ベースのDBMSのconceptual-to-internalマッピングを、(1)DBMSがサポートする一般的なconceptual fileおよびlinkを取得して、(2) DBMSのinternal fileおよびlinkを生成するために、良く定義されたelementary transformationsのシーケンスを適用することによって、モデル化することができることを意味します。INGRES、SYSTEM RおよびRAPIDの場合には、すべてが同じconceptual file(つまりrelations)から始まりますが、しかし、各々は、 transformations の異なるシーケンス(そして、それ故に、異なったinternal fileおよびlinkの集合)によって区別されます。私たちは、各々のelementary transformationsの詳細について、まもなく説明します。）
　
エ．「Conceptual-to-internal mappings are related to the UM in the following way.  The UM relies on decomposition to identify the internal files and links of a physical database. In contrast, the TM starts with conceptual files and links that are supported by a DBMS and shows how their underlying internal files and links are derived. The TM does not introduce new simple file structures or linkset structures. Rather, the TM extends the UM by supplanting the intuitive process of physical database decomposition with conceptual-to-internal mappings. Thus, the primitives for describing DBMS architectures are (1) simple files, which map internal files to pages on secondary storage; (2) linksets, which specify how related records of different files are physically connected, and (3) elementary transformations, which define how abstract (or higher level) files and links are mapped to concrete (or lower level) files and links.」
（審決仮訳：
Conceptual-to-internalマッピングは次のようにUMと関係します。物理的なデータ・ベースの internal fileおよび linkを識別するために、UMは分解に頼ります。対照的に、TMは、DBMSにサポートされるconceptual fileおよびlinkで始まり、それらに内在するinternal fileおよびlinkがどのように導き出されるのかを示します。TMは新しいsimple file構造あるいはlinkset構造を導入しません。もっと正確に言えば、TMは、conceptual-to-internalマッピングで、物理的なデータ・ベースの分解の直感的なプロセスに取って代わることにより、UMを拡張します。このように、DBMSアーキティクチャを説明するプリミティブは、(1)２次記憶装置上のページにinternal fileをマップする、単純なfile、(2)異なるfileの関連するレコードがどのように物理的に接続されるか特定する、linkset、そして、(3)抽象的な（すなわち、より高いレベルの）fileとlinkが、具体的な（すなわち、より低いレベルの）fileとlinkに、如何にしてマップされるかということを定義する、elementary transformations、です。）
　
オ．「3.1 Elementary Transformations
Elementary transformations are rules for mapping files and links at one (higher) level of abstraction to those at the next lower (more concrete) level. Ten elementary transformations are presently recognized. They were discovered as a consequence of studying the storage architectures of SPIRES [74], DMS-1100 [73], TOTAL [20], MRS [49], IDMS [22], INGRES [76], IMS [44], ADABAS [32], INQUIRE [45], RAPID [83], ALDS [14], CREATABASE [61], and SYSTEM 2000 [16]. Models of the storage architectures for most of these systems have been completed.　Table I lists the transformations that are used in each model, and a reference to the model.」
（審決仮訳：
3.1 Elementary Transformations
Elementary transformationsは、fileとlinkについて、ある（より高い）レベルの抽象度のものを次に低い（より具体的な）レベルに、マッピングするためのルールです。現在のところ10個のelementary transformationsが認識されています。それらは、SPIRES [74], DMS-1100 [73], TOTAL [20], MRS [49], IDMS [22], INGRES [76], IMS [44], ADABAS [32], INQUIRE [45], RAPID [83], ALDS [14], CREATABASE [61], and SYSTEM 2000 [16]の記憶アーキテクチャーを研究する結果として発見されました。ほとんどのこれらのシステム用の記憶アーキテクチャーのモデルは完成しました。テーブルＩは、それぞれのモデルにおいて使われ、それぞれのモデルにおいてリファレンスとなったtransformationのリストです。）
　
カ．「The transformations themselves were defined to coincide with familiar physical database concepts or with their generalizations. For example, there is a transformation called segmentation which corresponds to the well-known concept of segmentation [56].」
（審決仮訳：
　transformationそのものは、慣れ親しんだ物理的データベースの概念、又は、それらの概念の一般法則と符合するように定義される。例えば、良く知られた概念であるセグメンテーション[56]と対応するする概念であるsegmentationというtransformationがある。）
　
キ．「We have implemented a file management system, called JUPITER, that is based on the simple file submodel of the UM [31]. JUPITER is consistent with the concepts of internal files and simple files used in this paper. With the JUPITER interface, it is obvious whether functions should be supported by simple files or by elementary transformations. The storage architecture models that we present in this paper are consistent with this interface.」
(審決仮訳：
　我々は、ＵＭ［31］のサブモデルのsimple fileに基づくJUPITERと呼ばれるファイル管理システムを実装しました。JUPITERは、この論文で使用されたinternal fileとsimple fileの考え方を採用するものです。JUPITERのインタフェースにより、機能がsimple file、すなわち、elementary transformationによりサポートされるべきかどうか明らかです。われわれがこの論文で提案する格納アーキテクチャモデルは、このインタフェースに沿ったものです。)
　
　
　１）　引用記載アによると、 刊行物１は、conceptual-to-internalマッピングを明示的にする物理的なデータ・ベースのモデルである、transformation model (TM) を示すものである。
　
　２）　引用記載イによると、internal fileは、ハッシュに基づいた、インデックスされたシーケンシャルな、B+木の、動的ハッシュに基づいた、または整列されていない、ファイルを含む、シングル・レコード型の複数のインスタンスである複数のレコードの集合であり、 二つかそれ以上のinternal fileの間の関係はinternal linkであり、物理的なデータ・ベースは、internal fileおよびinternal linkの集まりへ分解することができるものである。　
　
　３）　引用記載ウによると、elementary transformationsは、単独で、あるいは組み合わせで、fileとlinkを、ある抽象度のレベルからより低いレベルにマップするために使用することができるもので、調査したＤＢＭＳでは、10個の異なるelementary transformationsだけが利用されていた。
　
　４）　引用記載エによると、DBMSアーキティクチャを説明するプリミティブは、(1)２次記憶装置上のページにinternal fileをマップする、simple file、(2)異なるfileの関連するレコードがどのように物理的に接続されるか特定する、linkset、そして、(3)抽象的な（すなわち、より高いレベルの）fileとlinkが、具体的な（すなわち、より低いレベルの）fileとlinkに、如何にしてマップされるかということを定義する、elementary transformations、である。
　
　５）　引用記載オによると、Elementary transformationsは、fileとlinkについて、ある（より高い）レベルの抽象度のものを次に低い（より具体的な）レベルに、マッピングするためのルールである。
　
　以上まとめると、刊行物１には、次の発明が記載されている。（以下、引用発明という。）
　
　データベース管理システムにおいて、conceptual-to-internalマッピングを明示的にするToransformation Modelに基づいた物理的なデータ・ベースであって、
　ハッシュに基づいた、インデックスされたシーケンシャルな、B+木の、動的ハッシュに基づいた、または整列されていない、fileを含む、シングル・レコード型の複数のインスタンスである複数のレコードの集合であるinternal fileと、
　二つかそれ以上のinternal fileの間の関係を示すinternal linkと、
　単独で、あるいは組み合わせで、fileとlinkを、ある抽象度のレベルからより低いレベルにマップするために使用する、segmentationなどの物理的データベースの概念、又は、それらの概念の一般法則と符合するように定義された複数のelementary transformationとを備え、
　前記(1)２次記憶装置上のページにinternal fileをマップする、simple file、(2)異なるfileの関連するレコードがどのように物理的に接続されるか特定する、linkset、そして、(3)抽象的な（すなわち、より高いレベルの）fileとlinkが、具体的な（すなわち、より低いレベルの）fileとlinkに、如何にしてマップされるかということを定義する、elementary transformationを用いて構成された物理的データ・ベース。
　
　
第４　対比・検討
１．本願発明１に係る検討
（１）引用発明１の認定
　　１）　引用発明のfileは、Ｂ＋木、ハッシュ等の格納構造を含むものであるから、引用発明は、複数の格納構造をサポートするデータベース処理装置であると言える。したがって、引用発明のfileの格納構造は、本願発明１の格納構造に相当するもので、引用発明の格納構造は当然記憶されているものと解される。
　
　　２）　引用発明のelementary transformationは、格納構造を構成するsegmentation等の基本データ編成の各々に対応する変換で、単独又は組み合わせによって、格納構造及び格納構造の組み合わせを、最終的には、２次記憶装置等にマッピングするものであるから、引用発明は、前記マッピングの際に、格納構造を構成する基本データ編成の組み合わせに関する情報を記憶し、利用するものと解される。
　したがって、引用発明は、本願発明１と同様、格納構造を構成する基本データ編成の組み合わせに関する情報を記憶し、利用するものである。
　
　　３）　引用発明のelementary transformationは、segmentation等の基本データ編成に対応する変換の単位となるものであって、最下層において、格納構造を２次記憶装置等へマッピングすることで、格納構造に基づいたデータへのアクセスを可能としている。
　したがって、引用発明のelementary transformationは、２次記憶装置等へのアクセスメソッドの基本単位であると言え、本願発明１のアクセスメソッドを部品化した基本データ編成のアクセス部品に相当するものである。また、引用発明１の前記アクセス部品は、当然ながら記憶されて利用されるものと解される。
　
　　４）　引用発明では、データベースに対する問い合わせに対して、問い合わせされた格納構造に対応する単独又は複数のアクセス部品による２次記憶装置等へのマッピングに基づいて、データにアクセスするための処理手順が生成される。
　したがって、引用発明においては、データベースに対する問い合わせに対して、格納構造を構成する基本データ編成のアクセス部品を組み合わせることにより、データベースの処理手順が生成される。
　
　以上のとおりであるから、引用発明は、言い換えれば、次の如き発明（以下、引用発明１と言う。）である。
　
　データベース管理システムにおいて複数の格納構造をサポートするデータベース処理装置において、
　格納構造の種類毎に、格納構造を構成する基本データ編成の組み合わせに関する情報を記憶し、
　個々の基本データ編成に対するアクセスメソッドを部品化した基本データ編成のアクセス部品を記憶し、
　データベースに対する問い合わせに対して、前記記憶した情報およびアクセス部品を基に、前記問い合わせに対応する格納構造を構成する基本データ編成のアクセス部品を組み合わせることにより、データベースの処理手順を生成することで、
　基本的なデータ編成の組み合わせによるデータベースの格納構造をもとに、最適化処理におけるアクセススケジュールを生成するようにしたことを特徴とするデータベース処理装置。　　　
　
（２）対比
　本願発明１と引用発明１とを対比すると、次の点で一致し、相違する。
　
［一致点］
　データベース管理システムにおいて複数の格納構造をサポートするデータベース処理装置において、
　格納構造の種類毎に、格納構造を構成する基本データ編成の組み合わせに関する情報を記憶し、
　個々の基本データ編成に対するアクセスメソッドを部品化した基本データ編成のアクセス部品を記憶し、
　データベースに対する問い合わせに対して、格納構造を構成する基本データ編成のアクセス部品を組み合わせることにより、データベースの処理手順を生成し、
　基本的なデータ編成の組み合わせによるデータベースの格納構造をもとに、最適化処理におけるアクセススケジュールを生成するようにしたことを特徴とするデータベース処理装置。
　
である点。
　
［相違点］
（相違点１）
　本願発明１は、リレーショナル・データベース管理システムに関するものであるが、引用発明１は、データベース管理システムに関するものである点。
　
（相違点２）
　構成基本データ編成に加えて、本願発明１においては、組み合わせに関するライブラリ部品名と組み立てパターン名がディクショナリに記憶されるが、引用発明１では、それらの情報については言及されていない点。
　
（相違点３）
　アクセス部品に関し、個々の基本データ編成に対するアクセスメソッドを部品化した基本データ編成のアクセス部品に加えて、
　本願発明１は、アクセス部品の組み合わせに関するライブラリ部品の情報を記憶し、データベースの処理手順を生成する際に利用するが、
　引用発明１は、そのような名前の情報を記憶すること、及び、利用することについては明示されていない点。
　
（相違点４）
　データベースの処理手順の生成に当たり、本願発明１は、いくつかの採択可能なデータベースの処理手順を生成し、採択可能なデータベースの処理手順が複数ある場合には、それらの各処理手順中で用いられた基本データ編成のアクセス部品の実行コストを評価するコスト評価部品を使って、各データベースの処理手順ごとに実行コストを評価し、前記採択可能な複数のデータベースの処理手順の中から最適な処理手順を選択する最適化処理部とを備え、最適化処理におけるアクセススケジュールを生成するが、引用発明１では、前記最適化処理に関する言及がない点。
　
（３）相違点の検討
（相違点１について）
　リレーショナルデータベースは、データベースの一種であるから、データベース管理システムに係る引用発明１の技術を、リレーショナルデータベースに関する本願発明１において採用する点に、困難性は認められない。
　
（相違点２について）
　本願発明１においては、組み合わせに関するライブラリ部品名、組み立てパターン名、及び、ディクショナリについて、どのような技術的特徴を持つものかの格別の定義がなく、それらの名前はその後も利用されていない。
　したがって、前記相違点２の、組み合わせに関するライブラリ部品名、組み立てパターン名をディクショナリに記憶しておくことは、実質的な相違ではない。
　
（相違点３について）
　本願発明１においては、組み合わせに関するライブラリ部品について、その名前以上の定義はない。その一方、引用発明１は、格納構造に対するアクセス部品の組み合わせに関する情報を記憶し、データベースの処理手順を生成する際に利用していると解される。
　したがって、引用発明１は、前記相違点３の事項を実質的に備えており、前記相違点３は、格別の相違点ではない。
　
（相違点４について）
　問い合わせに対するデータベースの処理手順を生成する際に、複数の採択可能なデータベース処理手順が生成され得ること、その際に、それぞれの処理手順の実行コストを評価して、最適な処理手順を選択することは、周知である（必要であれば、例えば、次の周知例参照。）。
　そして、引用発明１において、前記周知技術を採用し相違点４の如く構成することに困難性は認められない。
 
　周知例1：Matthias Jarke, Jurgen Koch, Query Optimization in Database System, IEEE Computing Serveys, Vol.16, No.2, p.111- 152, June 1984 
　周知例2：関根裕　他，「エクステンシブルＤＢＭＳにおける最適化処理についての考察」，情報処理学会研究報告，Vol.90, No.2, データベースシステム75-2, p.1-9, 1990年1月18日
　
（４）まとめ
　前記（１）〜（３）のとおり、本願発明１は、当業者が引用発明及び周知技術に基づいて容易に想到し得たものであるから、特許法第29条第2項の規定により特許を受けることができない。
　
２．本願発明２に係る検討
（１）引用発明１の認定
　　１）　引用発明のfileは、Ｂ＋木、ハッシュ等の格納構造を含むものであるから、引用発明は、複数の格納構造をサポートするデータベース処理装置であると言える。
　したがって、引用発明のfileの格納構造は、本願発明２の格納構造に相当する。
　
　　２）　引用発明のelementary transformationは、格納構造を構成するsegmentation等の基本データ編成の各々に対応する変換であり、単独又は組み合わせによって、格納構造と格納構造の組み合わせを、２次記憶装置等にマッピングするものである。
　したがって、引用発明においては、本願発明１と同様に、格納構造を構成する基本データ編成の組み合わせに関する情報は、当然、備わっており、処理の過程で取り出されるものと解される。
　
　　３）　引用発明のelementary transformationは、segmentation等の基本データ編成に対応する変換の単位となるものであり、格納構造を２次記憶装置等へマッピングし、格納構造に基づいたデータへのアクセスを可能とするものである。
　したがって、引用発明のelementary transformationは、本願発明１の基本データ編成のアクセス部品に相当するものであり、データベース処理手順の一部を構成するアクセス手順を生成する処理を行うものである。
　
　　４）　引用発明では、データベースに対する問い合わせに対して、問い合わせされた格納構造に対応する単独又は複数のアクセス部品による２次記憶装置等へのマッピングに基づいて、データにアクセスするための処理手順が生成される。
　したがって、引用発明においては、データベースに対する問い合わせに対して、問い合わせ全体に対するデータベース処理手順を，前記アクセス手順の組み合わせによって生成する処理が行われる。
　
　以上のとおりであるから、引用発明は、言い換えれば、次の如き発明（以下、引用発明２と言う。）である。
　
　データベース管理システムにおいて複数の格納構造をサポートするデータベース処理装置におけるデータベース処理手順生成方法において、
　格納構造の種類ごとに、それを構成する基本データ編成の組み合わせに関する格納構造定義情報を記憶して、問い合わせに関係する基本データ編成の組み合わせに関する情報の格納構造定義情報を取り出す処理過程と、
　問い合わせに関係する複数の格納構造定義のそれぞれに関して、基本データ編成のアクセス部品により、生成するデータベース処理手順の一部を構成するアクセス手順を生成する処理過程と、
　問い合わせ全体に対するデータベース処理手順を、前記アクセス手順の組み合わせによって生成することを特徴とするデータベース処理手順生成方法。　
　
（２）対比
　本願発明２と引用発明２とを対比すると、次の点で一致し、相違する。
　
［一致点］
　データベース管理システムにおいて複数の格納構造をサポートするデータベース処理装置におけるデータベース処理手順生成方法において、
　格納構造の種類ごとに、それを構成する基本データ編成の組み合わせに関する格納構造定義情報を記憶して、問い合わせに関係する基本データ編成の組み合わせに関する情報の格納構造定義情報を取り出す処理過程と、
　問い合わせに関係する複数の格納構造定義のそれぞれに関して、基本データ編成のアクセス部品により、生成するデータベース処理手順の一部を構成するアクセス手順を生成する処理過程と、
　問い合わせ全体に対するデータベース処理手順を、前記アクセス手順の組み合わせによって生成することを特徴とするデータベース処理手順生成方法。　
　
［相違点］
（相違点１）
　本願発明２は、リレーショナルデータベース管理システムに係る発明であるが、引用発明２は、データベース管理システムに係る発明である点。
　
（相違点２）
　格納構造定義情報を記憶するのが、本願発明２では、ディクショナリであるが、引用発明２では、記憶場所に特に名前がない点。
　
（相違点３）
　データベース処理手順の生成に当たり、
　本願発明２においては、採択可能ないくつかのデータベース処理手順を生成し、生成した処理手順が複数の場合に、処理手順中で用いられた基本データ編成のアクセス部品の実行コストを評価するコスト評価部品を使って，各データベースの処理手順ごとに実行コストを評価し，前記採択可能な複数のデータベースの処理手順の中から最適な処理手順を選択する処理を行うが、
　引用発明２においては、処理手順生成の詳細及び生成された処理手順のコスト評価と選択に関し、言及されていない点。
　
（３）相違点の検討
（相違点１について）
　リレーショナルデータベースは、データベースの一種であるから、データベース処理手順生成方法に係る引用発明１の技術を、リレーショナルデータベース処理手順生成方法に関する本願発明１において採用することに、困難性は認められない。
　
（相違点２について）
　本願発明２において、格納構造的義情報の記憶場所の名前は、特に利用されているわけではないから、相違点２は、格別のものではない。
　
（相違点３について）
　問い合わせに対するデータベースの処理手順を生成する際に、複数の採択可能なデータベース処理手順が生成され得ること、その際に、それぞれの処理手順の実行コストを評価して、最適な処理手順を選択することは、周知である（必要であれば、例えば、前記１．（３）の（相違点４について）で示した周知例を参照されたい。）。
　そして、引用発明１において、前記周知技術を採用し相違点４の如く構成することに困難性は認められない。　
（４）まとめ
　前記（１）〜（３）のとおり、本願発明２は、当業者が引用発明及び周知技術に基づいて容易に想到し得たものであるから、特許法第29条第2項の規定により特許を受けることができない。
　
　
第５　むすび
　以上のとおり、本願発明１及び２は、当業者が引用発明及び前記周知技術に基づいて容易に想到し得たものであるから、特許法第29条第2項の規定により特許することはできない。
　
　よって、結論のとおり審決する。