【事件の表示】
　平成１１年特許願第３７５７１８号「階層リンク・テーブルを備えたデータベース・システム」拒絶査定不服審判事件〔平成１３年　７月１０日出願公開、特開２００１−１８７４７７〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願は、平成１１年１２月２８日の出願であって、平成１７年４月８日付で拒絶査定がなされ（発送日同年４月１９日）、これに対し、同年５月１３日に拒絶査定不服審判の請求がなされるとともに、同日付で手続補正がなされたものである。
　
２．平成１７年５月１３日付の手続補正についての補正却下の決定
［補正却下の決定の結論］
　平成１７年５月１３日付の手続補正を却下する。
［理由］
（１）平成１７年５月１３日付の手続補正書により補正された本願発明
　本件補正により、特許請求の範囲の請求項１は、下記のように補正された。
「一定の業務を実行するための業務処理プログラムの処理で用いられるデータを格納し管理するためのデータベース・システムであって、
上記業務処理プログラムの処理で用いられるデータをノード・データとしてデータレコードに格納するノード・データベースと、
上記業務処理プログラムごとに対応して設けられ、上記ノード・データベースに格納されたノードの属性情報についてデータベース間での親子関係を定義する関連付け情報を、データレコードのデータ項目として保持する親子リンク・テーブルと、
を具備するデータベース・システム。」
　
　上記補正は、旧請求項１の発明特定事項である「親子リンク・テーブル」について、「上記業務処理プログラムごとに対応して設けられ、上記ノード・データベースに格納された属性情報であるデータベース（エンティティ）間の親子関係を定義する関連付け情報をデータレコードのデータ項目として保持する親子リンク・テーブル」という記載を「上記業務処理プログラムごとに対応して設けられ、上記ノード・データベースに格納されたノードの属性情報についてデータベース間での親子関係を定義する関連付け情報を、データレコードのデータ項目として保持する親子リンク・テーブル」と技術的に限定するものである。
　したがって、本件補正は、特許請求の範囲の減縮を目的とするものに該当する。
　
　そこで、本件補正後の請求項１に記載された発明（以下、「本願補正発明」という。）が特許出願の際独立して特許を受けることができるものであるかについて以下に検討する。
　
（２）引用発明の認定
（２−１）引用例１
　原査定の拒絶の理由に引用された平岡　昭夫、リンク指向ＤＢＭＳ　Ｇ−ＢＡＳＥにおけるリンク機能の拡張とその応用、情報処理学会研究報告、社団法人　情報処理学会、１９９１．０３．１１、Ｖｏｌ．９１，Ｎｏ．２２（９１−ＤＢＳ−８２−５）、ｐｐ．１−１０．（以下、「引用例」という。）には、図面とともに、以下（ア）〜（エ）の事項が記載されている。
　　　
（ア）
「１はじめに
ＵＮＩＸ／ＷＳ１上のＤＢＭＳとしては、リレーショナルデータモデルをべースとしたＤＢＭＳが現在主流であり、標準データベース操作言語ＳＱＬ［１］は普及段階に入っている。Ｅ．Ｆ．Ｃｏｄｄ［２］によって提案されたリレーショナルデータモデルは、明確な数学的基盤に基づいているうえに、判り易いことも手伝って、ＵＮＩＸ／ＷＳ上の主流データモデルとなっている。
　ところが、ワークステーション上では、従来の事務処理にはなかったデータベースの応用分野が広がりつつある。たとえぼ、ＣＡＤシステムや、画像処理システム、文書処理システム、マルチメディアシステムなどの核にＤＢＭＳを使用する研究が多数試みられている［３］［４］。
　このような分野に利用されるＤＢＭＳは多様で複雑なデータを扱わなければならない。たとえば、個々のデータが複雑な関連をもっていて、ある関連によって結びつけられるデータの集合が意味をもつことがある。機械設計の分野における階層構造データはこの代表例である。また、文書構造を表す揚合などにも階層構造によるデータの管理は重要である。単純な表構造しかもたないリレーショナルデータモデルは、複雑なデータを表の組みわせで表現しなければならないため、ユーザに対して大きな負担を強いている。
（中略）
　我々はこれらの問題に対して、レコード間の関連を直接表現できるリンク機能を提案してきた［９］。リンクは、グラフデータモデル［１０］と呼ばれる新しいデータモデルの機能の一部である。Ｇ−ＢＡＳＥ２［１１］はグラフデータモデルをべースに開発された本格的ＤＢＭＳである。
　本稿ではリンク機能に対して行った機能拡張を紹介し、リンク機能を階層データに応用した例について説明する。」（第２頁左欄第１〜４０行目）
　
（イ）
「２グラフデータモデル
リレーショナルデータベースの持つ簡潔さを保ちつつも、データ間の関連を直観的に表現できるように拡張されたモデルがグラフデータモデルである。
　データベースの設計を行う際に、実世界のデータ構造を表現する概念モデルとして実体関連（Ｅ−Ｒ）モデル［１２］が使われることが多い。リレーショナルモデルの場合この概念モデルから正規化という手順を踏んでより効果的なデータベース設計を行わなければならない。ところが、正規化を行うことで表は分割され、さらに表と表の関連を表すための中間表（関連表）などを用意することから、表の数が多くなり、操作時には表間の関連をつかみにくくなるという問題がある。
　グラフデータモデルではこれらの問題を解決するためデータモデルの中にタプルとタプルの関連を直接表すことのできるリンク型というオブジェクトを導入した。このグラフデータモデルをべースに開発されたＤＢＭＳがＧ−ＢＡＳＥである。
　グラフデータモデルではリレーショナルデータベースで云う表をレコード型と呼んでいる。そして、各行をレコード（または、レコードオカレンス）と呼ぶ。レコード型を構成する列をフィールドと呼ぶ。複数のレコード型、リンク型をまとめたものをデータベースと呼ぶ。システム中に作成できるデータベースの個数に制限はない。
　Ｇ−ＢＡＳＥの場合データベースの構造（スキーマ）を表現するために、データ定義言語（ＤＤＬ）を使用する。図１に簡単な人事データベースのＤＤＬ文による定義例を示す。社員と組織という２つのレコード型が定義されている。フィールドごとにその名前とデータ型が宣言されている。
　ここで、社員が所属する組織のレコードとの関連をリンク型で表現するためには次のように宣言する。
　
　ｒｅａｌ　ｌｉｎｋ　社員　．．／所属／．．組織；
　ｄａｔａｂａｓｅ　”／ｄｅｍｏ／ｊｉｎｊｉ”；
　
　ｒｅｃｏｒｄ　社員（
　　　　　社員番号　ｉｎｔｅｇｅｒ（４），
　　　　　氏名　　　ｃｈａｒａｃｔｅｒ（３２），
　　　　　住所　　　ｖａｒｉａｂｌｅ　ｃｈａｒａｃｔｅｒ（２５６），
　　　　　生年月日　ｄａｔｅ，
　　　　　趣味　　　ｖａｒｉａｂｌｅ　ｃｈａｒａｃｔｅｒ
　）ｋｅｙ（社員番号）；
　
　ｒｅｃｏｒｄ　組織（
　　　　　組織名　　ｃｈａｒａｃｔｅｒ（６４），
　　　　　売上高　　ｉｎｔｅｇｅｒ（４），
　　　　　担当分野　ｖａｒｉａｂｌｅ　ｃｈａｒａｃｔｅｒ（２５６）
　）ｋｅｙ（組織名）；
　
　　　図１：人事データベースのスキーマ
　
　（図２は省略）
　
　この宣言文で社員レコード型と組織レコード型の間にリンク型所属３が定義され、社員と組織の間の関連を表現できるようになる。
　Ｇ−ＢＡＳＥの中でリンク型はつねに．．／＜リンク名＞／．．という記法で定義、参照される。リンク型は２つのレコード型間でのみ定義される。図２はこのデータ定義をＥ−Ｒモデルで表現した図（スキーマダイアグラム）である。
　Ｇ−ＢＡＳＥではこのように宣言したスキーマファイルをＤＤＬプロセッサにかけることで、データベースが作成される。
　作成されたデータベースには必要なデータを格納しなければならない。データベースのデータに対する操作はデータベース操作言語（ＤＭＬ）によって表され、ＤＭＬプロセッサによって実行される。レコード型にレコードを格納する揚合はｉｎｓｅｒｔ文を使用する。
　
　　ｉｎｓｅｒｔ　社員　ｓｅｔ　社員番号＝２３０１９９，
　　　　　　　　　氏名　＝”平岡”，
　　　　　　　　　住所　＝”東京都中野区”，
　　　　　　　　　生年月日　＝‘１９５９／１１／９‘，
　　　　　　　　　趣味　＝”読書”；
　
　レコード型にレコードを格納しただけではリンクは接続されない。両端のレコードを指定し、ｃｏｎｎｅｃｔ文を使って、リンクを接続する。
　
　　ｆｏｒ　社員［名前＝”平岡”］　．．組織
　　　　　［名前＝”ソフトウェア事業部”］
　　　　　ｃｏｎｎｅｃｔ　社員　．．／所属／．．組織；
　
　ｆｏｒ文は必要なレコードの集合を求めるための検索構文で、ここでは社員、組織それぞれのレコード型に対して［］内の条件を満たすレコードの組が結果として得られる。ｃｏｎｎｅｃｔ文はｆｏｒ文で得られたレコードの組に対して実行されることになる。レコード型のレコードを削除する場合にはｄｅｌｅｔｅ文を使用し、リンクを切断する場合にほ、ｄｉｓｃｏｎｎｅｃｔ文を使用する。
　Ｇ−ＢＡＳＥのＤＭＬではレコードを検索する操作はパス集合を作ることによって実行される。パスとはレコード型と実リンク型を交互にたどってえられるレコードの集合でパス式によって表現される。
　図３において始端レコード（１〜４）からリンク（矢印）をたどって得られるレコードの組がパスである。パスのあつまりがパス集合である。１つのレコードに複数のリンクが接続されている場合には、それぞれをたどったレコードの組が別のパスとして得られる。
　社員と組織の関連所属リンク型をたどって得られるある組織に属する社員（と指定した組織）のパスは次のようなパス式によって表現される。
　
　　社員　．．／所属／．．組織［組織名＝”〜”］
　
　前述のｆｏｒ文はこのパス式で作られるパス集合の各パスに対する操作を指定する構文である。たとえば、パス式上のフィールド値を得る場合にはｐｒｉｎｔ文をｆｏｒ＋パス式の後に指定すれぼよい。
　
　　ｆｏｒ　社員　．．／所属／．．組織［組織名＝”〜”］
　　　　　　ｐｒｉｎｔ　社員．氏名，社員．住所；
　
（図３は省略）
　
　リンク型の両端にあるレコード型をそれぞれ始端レコード型、終端レコード型と呼ぶ。パス式中でリンクは左から右にたどられる。リンク型は双方向にたどることができるが、リンクの定義に対して逆方向にたどる場合には組織．．／ｉｎｖｅｒｓｅ　所属／．．社員のようにｉｎｖｅｒｓｅを指定する。逆方向のリンクに対して名前を指定することもできる。
　パス式のもっとも簡単な形式はレコード型１つである。複数のレコード型、リンク型をたどるにはパス式中にレコード型、リンク型を繰返し指定すれぱよい。
　
　　社員　．．／所属／．．　組織　．．／場所／．．事業所
　
　Ｇ−ＢＡＳＥではリンクを使用しなくても、レコード型それぞれに対してリレーショナルデータモデルに対する操作と同じ集合演算（ｕｎｉｏｎ，ｊｏｉｎ，ｄｉｆｆｅｒｅｎｃｅ等）が用意されている。
　図２の例では社員と組織という多対１の簡単な関連を表しているため、リレーショナルデータモデルでも簡単に表現できる。しかし、社員が複数の組織に兼務している場合、一般にリレーショナルデータモデルでは中間表を用意しなければならなくなる。このような場合でも、グラフデータモデルではリンク機能を使って多対多の関連を簡潔に表すことができる。
　以上のようにデータ間の関連を表すリンク機能によって、Ｇ−ＢＡＳＥはＥ−Ｒモデルをほとんどそのまま表現でき、リレーショナルデータモデルで問題となる正規化の手続を大幅に削減している。」（第２頁右欄第８行目から第４頁右欄第３行目）
　
（ウ）「３　拡張されたリンク機能
我々は、Ｇ−ＢＡＳＥのリンク機能をより完全なものにするため、リンク（関連）に対して情報を持たせることを可能にした。リンクに持たせた情報のことをリンクフィールドと呼んでいる。
　例えば、業者と製品の間に納入という関係がある場合を考える。
　
　　ｄａｔａｂａｓｅ　”／ｄｅｍｏ／納品管理”；
　
　　ｒｅｃｏｒｄ　業者　（
　　　　　　社名　　　　　　ｃｈａｒａｃｔｅｒ（６４），
　　　　　　住所　　　　　　ｖａｒｉａｂｌｅ　ｃｈａｒａｃｔｅｒ（２５６）
　　）；
　
　　ｒｅｃｏｒｄ製品（
　　　　　　製品番号　　　　ｉｎｔｅｇｅｒ（４），
　　　　　　製品名　　　　　ｃｈａｒａｃｔｅｒ（１２８）
　　）；
　
　ある業者がある製品を納入しているという関連は業者．．／納入／．．製品というリンク型で表される。しかし、業者がその製品を単価いくらで、どれだけ納入しているかを表すためには、納入というリンクに対して、単価や個数といった情報を持たさなけれぼならない。我々はこれらの情報をリンクフイールドとして定義できるようにリンク機能を拡張した。
　
　リンクフィールドを含むリンクの宣言の例を示す。
　
　　ｒｅａｌ　ｌｉｎｋ　業者．．／納入／．．製品（
　　　　　　単価　　　　　ｉｎｔｅｇｅｒ（４），
　　　　　　個数　　　　　ｉｎｔｅｇｅｒ（２），
　　　　　　納期　　　　　ｄａｔａ
　　）；
　
　リンクを接続するｃｏｎｎｅｃｔ文もリンクフィールドに値を代入できるように拡張された。
　
　　ｃｏｎｎｅｃｔ　業者．．／納入／．．製品
　　　　　　ｓｅｔ　単価　＝　１９８０００，　個数　＝　２０；
　
　またパス式の中にリンクフィールドの値に対する条件を指定できるように拡張した。レコード型のフィールドとリンク型のフィールドを区別するため、フィールドを参照する時にはレコード型名、リンク型名を指定する。
　
　　ｆｏｒ　業者　．．／納入／．．　製品
　　　　　　［製品．製品名　＝”ネジＡ”
　　　　　　　ａｎｄ　納入．個数　＞＝１０］
　　　　　　Ｐｒｉｎｔ　業者．社名，業者．住所，
　　　　　　　　　　　　納入．個数；
　
　この例４ではネジＡを１０個以上納入している業者を検索し、その社名、住所と納入個数を出力している。
　今回のリンクに対する拡張により、Ｇ−ＢＡＳＥはＥ−Ｒモデルで表現された概念スキーマを、そのまま表現できるようになった。図４にレコード型業者，製品とリンク型納入についてのスキーマ図を示す（レコード型のフィールドは省略している）。
　一般にリレーショナルデータベースでは、納入という関連をユーザが作成する表で管理しなければならない。業者、製品リレーションに個々のタプルを識別するフィールド（結合列）を用意し、そのタプル間の組をこの表に格納する。格納されるタプルの識別子を持つ業者、製品が実際に存在することもユーザの責任で調べなければならない５。
　例のような単純なスキーマならば簡単かもしれないが、実際に使用される複雑なスキーマのなかで、関連するテーブルを管理していくのはユーザにとって大きな負担である。さらに、製品→業者、業者→製品の検索を行う場合、３つの表の結合オペレーションを行わなければならないため、データ量が多くなった場合、性能が著しく低下することが予想される。
　Ｇ−ＢＡＳＥでリンク型を定義したした場合、２つのリンクファイルが作られる。それぞれを順リンクファイル、逆リンクファイルと呼ぶ。各ファイルはＢ＋ｔｒｅｅ（Ｂ＋木）で構成され、キーとしてリンクが接続されている始端レコードのレコード識別子（ＵＲＩ：Ｕｎｉｑｕｅ　Ｒｅｃｏｒｄ　Ｉｄｅｎｔｉｆｉｅｒ）が格納される。サーチの結果得られる値は終端レコードのＵＲＩである。これらのファイルを検索することで、リンクを順方向、またほ逆方向に高速にたどることができるようになっている（図５参照）。
　新たに追加した機能であるリンクフィールドはリンクレコードファイルに格納される。２つのリンクファイルはこのリンクレコードファイルに対する索引ファイルの関係になっている。これらのファイルはすべてリンクの接続／切断操作にしたがって自動的に更新される。
　以上のような物理的な構造はユーザからは見えない。ユーザにとって、リンクはあくまで、ｃｏｎｎｅｃｔ文で接続し、ｄｉｓｃｏｎｎｅｃｔ文で切断するだけの論理的な構成要素に見える。
　リンクフィールドの追加に伴い、リンクに対するｕｐ−ｄａｔｅ操作が追加された。また、従来同じレコードオカレンスの組の間には１本のリンクしか接続できなかったが、今度の機能拡張で可能になった。たとえば、同じ業者が同じ製品を異なる値段で納入するという情報も表現できるようになった。リンクの順方向／逆方向それぞれに異なる値を持たせることも検討したが、あまりニーズがなかったので今回の拡張からは除かれた。」（第４頁右欄第１７行目から第６頁左欄第１１行目）
　
（エ）「５　階層型データに対するリンク機能の応用
我々は、Ｇ−ＢＡＳＥのリンク機能の有効な応用例として階層型データの取り扱いを考えている。以下では部品表管理を例にリンクを使って階層型データを表現し、操作する方法を考察した。
　機械設計などの現場では、部品を管理するために部品表を使用している。部品表の構造の特徴は、親部品とその子部品からなる木構造である。木構造の葉にあたる部分に最小単位の部品情報が格納され、中間ノードは複数の部品から構成されるユニットである。いくつかのユニットの組みあわせによって製品が構成される。
　部品表は親部品を起点とし最小部品単位にいたる木構造である。ところが、下位の部品またはユニットは複数の親ノードを持っている共通部品であることも許される。たとえば、ＣというユニットがＡ，Ｂ両方の構成部品であることが許されなければならない。したがって、部品表木構造の上位ノード対下位ノードの関連は多対多の関連となっている（図６参照）。
　部品表に対する代表的な検索操作は『ある部品の子部品すべてを得る（部品展開）』と『指定された部品を使っているすべての親部品を検索する』であり、部品表の木構造を下位方向、上位方向にトラバースする（たどる）操作が基本となる。
　Ｇ−ＢＡＳＥではこのような部品の階層構造を表すために、リンク機能を使用する。上位部品と下位部品の関連をリンクを接続することで表現する。実際の応用を考える場合、１つの親部品に対する子部品群は単なる集合ではなく、親部品から見た時に個々を識別するべき情報が必要となる。また、同じ親部品を持つ子部品間での順序づけも必要な機能である。このような情報は子部品が持つべき情報ではなく、親部品との相対的関連に基づく属性と考えられる。今回の拡張により、親部品−子部品間の関連情報をリンクフィールドで表現することが可能になった。
　単純な部品のスキーマ構造を例としてあげる。最小単位の部品と中間ユニットを別のレコード型で表現する方が現実的ではあるが、ここでは簡単のためすべての部品（木構造のノード）を同じレコード型部品で表現している。
　
　　ｒｅｃｏｒｄ　部品（
　　　　　　部品名　　　　ｖａｒｉａｂｌｅ　ｃｈａｒａｃｔｅｒ（１００），
　　　　　　付属情報　　　ｃｈａｒａｃｔｅｒ（１５０）
　　）ｋｅｙ（部品名）；
　
　　ｒｅａｌ　ｌｉｎｋ　部品　．．／子部品／．．　部品　｛
　　　　　　番号　　　　　ｉｎｔｅｇｅｒ（４），
　　　　　　色　　　　　　ｃｈａｒａｃｔｅｒ（１６），
　　　　　　倍率　　　　　ｄｏｕｂｌｅ，
　　　　　　位置［２］　　ｄｏｕｂｌｅ
　　｝；
　
　部品間の親子関係を表現するためにリンク型子部品を定義した（図７参照、フィールドは省略）。このリンク型は同じレコード型に属するレコード間の関連を示している自己参照型リンクである。各リンクは親部品から見た子部品の番号と、変倍率、相対位置（Ｘ座標，Ｙ座標）、色情報（カラー）をリンクフィールドとして持つ。同じ部品レコードも異なる番号、相対位置で別の親部品から参照される場合がある。
　このような簡単なスキーマによって、先に述べた木構造を表現することができる。『親部品を１つ指定して子部品を検索する』検索操作は、リンク機能を使って次のように表現できる。
　
　　ａｌｉａｓ　親　部品；
　　ａｌｉａｓ　子　部品；
　
　　ｆｏｒ　親［＜条件式＞］　．．／子部品／．．　子
　　　　　　ｏｒｄｅｒ　子部品．番号
　　　　　　ｐｒｉｎｔ　子．部品名；
　
　レコード異称（ａｌｉａｓ）は同じレコード型の実体に対して、異なるスコープを与えるための宣言である。上記の例では＜条件式＞を満たす部品を１つ検索し、その部品を親部品として持つ子部品をリンクフィールド番号の順に出力する。
　複数のレベルの親子関係を表現するにはｆｏｒ文を入れ子形式にすることで、実現できる８。
　
　　ａｌｉａｓ　ｐ０　部品；
　　ａｌｉａｓ　ｐ１　部品；
　　ａｌｉａｓ　ｐ２　部品；
　
　　ｔａｒｇｅｔ　ｔ０　ｐ０；
　　ｔａｒｇｅｔ　ｔ１　ｐ１；
　　ｔａｒｇｅｔ　ｔ２　ｐ２；
　
　　ｆｉｎｄ　ｔ０　＝　ｐ０［＜条件式＞］；
　　ｆｏｒ　ｔ０　｛
　　　　　　ｐｒｉｎｔ　Ｎａｍｅ，Ｉｄ；
　　　　　　ｆｉｎｄ　ｔ１　＝　ｐ０　．．／子部品／．．ｐ１
　　　　　　　　　　　　　　　　ｏｒｄｅｒ　子部品．番号；
　　　　　　ｆｏｒ　ｔ１　｛
　　　　　　　　　　ｐｒｉｎｔ　”　　　　”，　Ｎａｍｅ，Ｉｄ；
　　　　　　　　　　ｆｉｎｄ　ｔ２　＝　ｐ１　．．／子部品／．．ｐ２
　　　　　　　　　　　　　　　　　　　　ｏｒｄｅｒ　子部品．番号；
　　　　　　　　　　ｆｏｒ　ｔ２｛
　　　　　　　　　　　　　　　．．．．．．．．．．．．．．．．．．．．
　　　　　　　　　　｝；
　　　　　　｝；
　　｝；
　
　上の検索では、基本的に親部品に対してすぐ下の子部品しか検索することができない。ある親が指定されたときにその子供をすべて再帰的に得るためにはターゲットを使用する。ターゲットとはパス式によって検索されたレコード群を一時的に保持するための表である。この表の実体はレコード型であり、ターゲット異称を宣言することで同じレコード型上に異なるスコープを作ることができる。
　
　　ｖａｒ　ｃｎｔ；
　　ａｌｉａｓ　親　部品；
　　ａｌｉａｓ　子　部品；
　　ｔａｒｇｅｔ　ｔｐ　親；
　　ａｌｉａｓ　ｔｃ　ｔａｒｇｅｔ　ｔｐ　子；
　
　　ｆｉｎｄ　ｔｃ＝子［＜条件式＞］；
　　ｗｈｉｌｅ　ｃｎｔ　！＝　０
　　｛
　　　　　　ｓｅｔ　ｃｎｔ　＝　ｃｏｕｎｔ（ｔｃ）；
　　　　　　ｆｉｎｄ　ｔｃ　＝　子［ｐａｔｈ　ｔｃ　ｏｒ
　　　　　　　　　　　　　　ｔｐ　．．／子部品／．．子
　　　　　　　　　　　　　　［子部品．色＝”赤”］］；
　　｝
　
　上の検索文を実行することで、＜条件式＞に適合した親部品に対する子部品のなかで色が赤に指定されている子部品の集合を再帰的に得る。ｗｈｉｌｅ文の終了条件は、条件を満たすレコードをターゲットに追加してもターゲット上のパスの数が増えないことである。これは、現在夕ーゲット上にあるレコードに対して条件を満たす子部品が得られないことを意味する。
　このように、Ｇ−ＢＡＳＥではリンク機能を用いることで階層構造データを簡潔に表現できる。前章で述べたように、リンク機能を利用する場合、中間表を使った結合操作に比べて検索速度も速い。
　以前のバージョンではリンクに対する属性を持たせることができなかっため、親部品に対する子部品の番号（または、順序）を指定することができなかった。これは、現実的な応用を考える場合大きな問題点であった。我々は、３章で述べたリンクフィールド機能を拡張することによってこの問題を解決した。ここでは、階層構造のデータとして部品表を例としてあげたが、ほかにも文書の構造を表現する応用も研究されている。」（第７頁右欄第１行目から第９頁左欄下から６行目）
　
　以上の引用例の記載によれば、引用例には以下の事項が開示されていると認められる。
　
（ａ） 引用例の上記（ア）の「ワークステーション上では、従来の事務処理にはなかったデータベースの応用分野が広がりつつある。たとえぼ、ＣＡＤシステムや、画像処理システム、文書処理システム、マルチメディアシステムなどの核にＤＢＭＳを使用する研究が多数試みられている（中略）このような分野に利用されるＤＢＭＳは多様で複雑なデータを扱わなければならない。たとえば、個々のデータが複雑な関連をもっていて、ある関連によって結びつけられるデータの集合が意味をもつことがある。機械設計の分野における階層構造データはこの代表例である。（中略）我々はこれらの問題に対して、レコード間の関連を直接表現できるリンク機能を提案してきた［９］。リンクは、グラフデータモデル［１０］と呼ぼれる新しいデータモデルの機能の一部である。Ｇ−ＢＡＳＥ２［１１］はグラフデータモデルをべースに開発された本格的ＤＢＭＳである。」という記載から、引用例には、機械設計等の業務を実行するためのＣＡＤシステムで用いられるデータを格納し管理するためのＤＢＭＳが記載されているといえる。
　
（ｂ） 引用例の上記（イ）の「リレーショナルデータベースの持つ簡潔さを保ちつつも、データ間の関連を直観的に表現できるように拡張されたモデルがグラフデータモデルである。
　データベースの設計を行う際に、実世界のデータ構造を表現する概念モデルとして実体関連（Ｅ−Ｒ）モデル［１２］が使われることが多い。リレーショナルモデルの場合この概念モデルから正規化という手順を踏んでより効果的なデータベース設計を行わなければならない。ところが、正規化を行うことで表は分割され、さらに表と表の関連を表すための中間表（関連表）などを用意することから、表の数が多くなり、操作時には表間の関連をつかみにくくなるという問題がある。
　グラフデータモデルではこれらの問題を解決するためデータモデルの中にタプルとタプルの関連を直接表すことのできるリンク型というオブジェクトを導入した。このグラフデータモデルをべースに開発されたＤＢＭＳがＧ−ＢＡＳＥである。
　グラフデータモデルではリレーショナルデータベースで云う表をレコード型と呼んでいる。そして、各行をレコード（または、レコードオカレンス）と呼ぶ。レコード型を構成する列をフィールドと呼ぶ。複数のレコード型、リンク型をまとめたものをデータベースと呼ぶ。」という記載や、「この宣言文で社員レコード型と組織レコード型の間にリンク型所属３が定義され、社員と組織の間の関連を表現できるようになる。
　Ｇ−ＢＡＳＥの中でリンク型はつねに．．／＜リンク名＞／．．という記法で定義、参照される。リンク型は２つのレコード型間でのみ定義される。図２はこのデータ定義をＥ−Ｒモデルで表現した図（スキーマダイアグラム）である。」という記載、及び、「データ間の関連を表すリンク機能によって、Ｇ−ＢＡＳＥはＥ−Ｒモデルをほとんどそのまま表現でき、リレーショナルデータモデルで問題となる正規化の手統を大幅に削減している。」という記載、並びに、図２などから、引用例のＤＢＭＳは、業務処理で用いられるデータを、Ｅ−Ｒモデルで表現した図（スキーマダイアグラム）におけるノードに対応するデータを、レコード型に格納する手段を備えているといえる。
　
（ｃ） 引用例の上記（イ）の「グラフデータモデルではこれらの問題を解決するためデータモデルの中にタプルとタプルの関連を直接表すことのできるリンク型というオブジェクトを導入した。このグラフデータモデルをべースに開発されたＤＢＭＳがＧ−ＢＡＳＥである。
　グラフデータモデルではリレーショナルデータベースで云う表をレコード型と呼んでいる。そして、各行をレコード（または、レコードオカレンス）と呼ぶ。レコード型を構成する列をフィールドと呼ぶ。複数のレコード型、リンク型をまとめたものをデータベースと呼ぶ。」という記載や、「この宣言文で社員レコード型と組織レコード型の間にリンク型所属３が定義され、社員と組織の間の関連を表現できるようになる。」という記載、上記（ウ）の「Ｇ−ＢＡＳＥでリンク型を定義したした場合、２つのリンクファイルが作られる。それぞれを順リンクファイル、逆リンクファイルと呼ぶ。各ファイルはＢ＋ｔｒｅｅ（Ｂ＋木）で構成され、キーとしてリンクが接続されている始端レコードのレコード識別子（ＵＲＩ：Ｕｎｉｑｕｅ　Ｒｅｃｏｒｄ　Ｉｄｅｎｔｉｆｉｅｒ）が格納される。サーチの結果得られる値は終端レコードのＵＲＩである。これらのファイルを検索することで、リンクを順方向、またほ逆方向に高速にたどることができるようになっている（図５参照）。」という記載、及び、上記（エ）の「機械設計などの現場では、部品を管理するために部品表を使用している。部品表の構造の特徴は、親部品とその子部品からなる木構造である。木構造の葉にあたる部分に最小単位の部品情報が格納され、中間ノードは複数の部品から構成されるユニットである。いくつかのユニットの組みあわせによって製品が構成される。（中略）部品表木構造の上位ノード対下位ノードの関連は多対多の関連となっている（図６参照）。（中略）Ｇ−ＢＡＳＥではこのような部品の階層構造を表すために、リンク機能を使用する。上位部品と下位部品の関連をリンクを接続することで表現する。」という記載、並びに、図５、図６などから、引用例のＤＢＭＳは、Ｅ−Ｒモデルで表現した図（スキーマダイアグラム）におけるリンクに対応するものとして、レコード型に格納したデータの親子関係を定義するリンクをＢ＋ｔｒｅｅのリンクファイルとして保持する手段を備えているといえる。
　
　したがって、引用例には、以下の発明（以下、「引用発明」という。）が開示されていると認められる。
　
「機械設計等の業務を実行するためのＣＡＤシステムで用いられるデータを格納し管理するためのＤＢＭＳであって、
業務処理で用いられるデータを、Ｅ−Ｒモデルで表現した図（スキーマダイアグラム）におけるノードに対応するデータをレコード型に格納する手段と、
Ｅ−Ｒモデルで表現した図（スキーマダイアグラム）におけるリンクに対応するものとして、レコード型に格納したデータの親子関係を定義するリンクをＢ＋ｔｒｅｅのリンクファイルとして保持する手段とを
備えたＤＢＭＳ。」
　
（３）対比
　そこで、本願補正発明と引用発明とを対比する。
　
（Ａ）引用発明の「機械設計等の業務を実行するためのＣＡＤシステム」、「ＤＢＭＳ」は、本願補正発明の「一定の業務を実行するための業務処理プログラム」、「データベース・システム」に、それぞれ、相当するから、引用発明と本願補正発明とは、一定の業務を実行するための業務処理プログラムの処理で用いられるデータを格納し管理するためのデータベース・システムである点で共通している。
　
（Ｂ）引用発明の「Ｅ−Ｒモデルで表現した図（スキーマダイアグラム）におけるノードに対応するデータ」、「レコード型」は、本願補正発明の「ノード・データ」、「データレコード」に、それぞれ、相当するから、引用発明も、本願補正発明と同様に、業務処理プログラムの処理で用いられるデータをノード・データとしてデータレコードに格納するノード・データベースを備えているといえる。
　
（Ｃ）引用発明の「レコード型に格納したデータ」は、例えば社員の氏名や住所等の属性情報を保持していることから、本願補正発明の「ノード・データベースに格納されたノードの属性情報」に、相当しているといえる。
　また、引用発明の「レコード型に格納したデータの親子関係を定義するリンク」も、本願補正発明の「ノードの属性情報についてデータベース間での親子関係を定義する関連付け情報」に、相当しているといえる。
　したがって、引用発明も、本願補正発明と同様に、ノード・データベースに格納されたノードの属性情報についてデータベース間での親子関係を定義する関連付け情報を、データレコードのデータ項目として保持する手段を備えているといえる。
　ただし、本願補正発明が、親子関係を定義する関連付け情報を業務処理プログラムごとに対応して設けているのに対し、引用発明では、業務処理プログラムごとに対応して設けているか否か不明な点、及び、本願補正発明が、親子関係を定義する関連付け情報をテーブルで保持しているのに対し、引用発明では、Ｂ＋ｔｒｅｅのリンクファイルとして保持している点で相違している。
　
　したがって、両者は、
「一定の業務を実行するための業務処理プログラムの処理で用いられるデータを格納し管理するためのデータベース・システムであって、
業務処理プログラムの処理で用いられるデータをノード・データとしてデータレコードに格納するノード・データベースと、
ノード・データベースに格納されたノードの属性情報についてデータベース間での親子関係を定義する関連付け情報を、データレコードのデータ項目として保持する手段と
を備えたデータベース・システム。」
の点で一致し、以下の点で相違している。
　
（相違点１）本願補正発明が、親子関係を定義する関連付け情報を業務処理プログラムごとに対応して設けているのに対し、引用発明では、業務処理プログラムごとに対応して設けているか否か不明な点。
　
（相違点２）本願補正発明が、親子関係を定義する関連付け情報をテーブルで保持しているのに対し、引用発明では、Ｂ＋ｔｒｅｅのリンクファイルとして保持している点。
　
（４）判断
　
（相違点１について）
　データベース・システムの技術分野において、業務処理プログラムごとに複数の表（ノード）間の関係づけをビューとして設けておき、業務処理プログラムで用いる構成は、本願出願前に周知の技術に過ぎず、引用発明のリンクもビューを代替する手段であるから、引用発明において、当該周知技術を採用して、親子関係を定義する関連付け情報（リンク）を業務処理プログラムごとに対応して設ける構成とすることは、当業者が容易に想到し得たものである。
　
（相違点２について）
　データベース・システムの技術分野において、複数の表（ノード）間の関係づけをテーブル（中間表や関連表）で保持する構成は、引用発明の上記（イ）にも「リレーショナルモデルの場合この概念モデルから正規化という手順を踏んでより効果的なデータベース設計を行わなければならない。ところが、正規化を行うことで表は分割され、さらに表と表の関連を表すための中間表（関連表）などを用意する」と従来例として記載されているように、本願出願前に周知の技術に過ぎないから、引用発明において、親子関係を定義する関連付け情報をＢ＋ｔｒｅｅのリンクファイルとして保持する構成に代えて、当該周知技術を採用して、親子関係を定義する関連付け情報をテーブルで保持する構成とすることは、当業者が容易に想到し得たものである。
　
　また、本願補正発明の効果についてみても、上記構成の採用に伴って、当然に予測される程度のものに過ぎず、格別顕著なものがあるとは認められない。
　
　したがって、本願補正発明は、引用例に記載された発明並びに周知の技術に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許出願の際独立して特許を受けることができないものである。
　
（５）むすび
　以上のとおり、本件補正は、平成１８年改正前特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に違反するので、同法第１５９条第１項の規定において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　
３．本願発明について
　平成１７年５月１３日付の手続補正は上記のとおり却下されたので、本願の請求項１に係る発明（以下、「本願発明」という。）は、平成１５年９月２２日付の手続補正書の特許請求の範囲の請求項１に記載された事項により特定される、以下のとおりのものである。
　
「一定の業務を実行するための業務処理プログラムの処理で用いられるデータを格納し管理するためのデータベース・システムであって、
上記業務処理プログラムの処理で用いられるデータをノード・データとしてデータレコードに格納するノード・データベースと、
上記業務処理プログラムごとに対応して設けられ、上記ノード・データベースに格納された属性情報であるデータベース（エンティティ）間の親子関係を定義する関連付け情報をデータレコードのデータ項目として保持する親子リンク・テーブルと
を具備するデータベース・システム。」
　
　（１）引用例
　原査定の拒絶の理由に引用された引用例の記載事項は、前記「２．（２）」に記載したとおりである。　
　
　（２）対比・判断
　本願発明は、前記２．で検討した本願補正発明から、請求項１の発明特定事項である「親子リンク・テーブル」について、「上記業務処理プログラムごとに対応して設けられ、上記ノード・データベースに格納された属性情報であるデータベース（エンティティ）間の親子関係を定義する関連付け情報をデータレコードのデータ項目として保持する親子リンク・テーブル」という記載を「上記業務処理プログラムごとに対応して設けられ、上記ノード・データベースに格納されたノードの属性情報についてデータベース間での親子関係を定義する関連付け情報を、データレコードのデータ項目として保持する親子リンク・テーブル」とする技術的限定を削除したものである。
　そうすると、本願発明に技術的限定を付加した本願補正発明が、前記２．（４）に記載したとおり、引用例に記載された発明並びに周知技術に基づいて、当業者が容易に発明をすることができたものであるから、本願補正発明から技術的限定を取り除いた本願発明も同様の理由により、引用例に記載された発明並びに周知技術に基づいて、当業者が容易に発明をすることができたものである。　
　
　（３）むすび
　以上のとおりであるから、本願発明は、引用例に記載された発明並びに周知技術に基づいて当業者が容易に発明をすることができたものであり、特許法第２９条第２項の規定により特許を受けることができない。
　したがって、本願は、他の請求項について特に検討するまでもなく、拒絶されるべきものである。
　よって、結論のとおり審決する。