【事件の表示】
　特願２００３−２７７５７４「意味分割索引生成・索引検索方法、装置、およびプログラム」拒絶査定不服審判事件〔平成１７年　２月１７日出願公開、特開２００５−　４４１２５〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願は、平成１５年７月２２日の出願であって、平成１９年９月２８日付けで拒絶理由通知がなされ、同年１１月２９日付けで意見書が提出されたが、同年１２月２５日付けで拒絶査定がなされ、これに対し、平成２０年２月７日に拒絶査定不服審判の請求がなされるとともに、同年３月７日付けで手続補正がなされたものである。
　
２．平成２０年３月７日付けの手続補正についての補正却下の決定
［補正却下の決定の結論］
　平成２０年３月７日付けの手続補正を却下する。
　
［理由］
（１）新規事項の追加の有無について
　平成２０年３月７日付けの手続補正（以下、「本件手続補正」という。）の内容は、
（ア）補正前の特許請求の範囲の請求項４，６，８，１０における、
「索引の生成対象となるＩＤの意味構造における固定部長さ情報と帯域部長さ情報が記録されている、記憶装置内のＩＤ情報表を参照して固定部長さ情報と帯域部長さ情報を取得する」、及び
「前記固定部長さ情報と前記帯域部長さ情報により、前記データベース表から取得したＩＤを固定的な固定部、半固定的な帯域部、ランダムな通番部の３つに分割する」
との記載を、補正後の特許請求の範囲の請求項２，４，６，８における、
「索引の生成対象となるＩＤの意味構造における国番号、市外局番、市内局番の長さ情報が記録されている、記憶装置内のＩＤ情報表を参照して国番号、市外局番、市内局番の長さ情報を取得する」、及び
「前記国番号、市外局番、市内局番の長さ情報により、前記データベース表から取得したＩＤを国番号、市外局番、市内局番、加入者番号に分割する」
との記載に補正すること、
（イ）補正前の請求項５，９における、
「前記ＩＤ情報表に固定部長さ情報と帯域部長さ情報を設定する」
との記載を、補正後の請求項３，７における、
「前記ＩＤ情報表に国番号、市外局番、市内局番の長さ情報を設定する」
との記載に補正すること、
（ウ）補正前の請求項７における、
「固定部長さ情報と帯域部長さ情報をレコードとして持つＩＤ情報表を管理するＩＤ情報表管理手段」、及び
「前記ＩＤ情報表管理手段から取得した固定部長さ情報と帯域部長さ情報により前記ＩＤを固定的な固定部、半固定的な帯域部、ランダムな通番部の３つに分割し」
との記載を、補正後の請求項５における、
「国番号、市外局番、市内局番の長さ情報をレコードとして持つＩＤ情報表を管理するＩＤ情報表管理手段」、及び
「前記ＩＤ情報表管理手段から取得した国番号、市外局番、市内局番の長さ情報により前記ＩＤを国番号、市外局番、市内局番、加入者番号に分割し」
との記載に補正すること、
を含むものである。
　
　上記補正内容（ア）〜（ウ）について検討する。
　
　出願当初の明細書の段落【００３５】〜【００４１】、【００４４】〜【００４９】には、次の記載がなされている。
　なお、上記段落の記載において、「
通番
帯域
通番
帯域
　
「【００３５】
  次に、索引の生成の処理を具体例により説明する。
【００３６】
  ＤＮＳ検索処理は、ＤＮＳクライアント装置３がＤＮＳサーバ装置２にドメイン名を問い合わせ、ＤＮＳサーバ装置２がそのドメイン名に対応するリソースレコードを応答する動作である。
【００３７】
  ＤＮＳ名前データベース表２２には、市外局番が３配下（「＋８１−３−ＸＸＸ−ＹＹＹＹ」）の電話番号に対応する名前が管理されているものとする。
【００３８】
  ＤＮＳサーバ装置２では、索引生成の事前準備としてＤＮＳサーバ装置２のオペレータが、ＩＤ情報管理部１３を使ってＩＤ情報表１６に固定部長さ情報１６ａおよび帯域部長さ情報１６ｂとしてそれぞれ「５」および「３」を設定する（ステップ１０１）。
【００３９】
  索引構成装置１では、索引生成として、索引生成部１１が、ＩＤ情報管理部１３を使ってＩＤ情報表１６から固定部長さ情報１６ａおよび帯域部長さ情報１６ｂとしてそれぞれ「５」および「３」を取得し（ステップ１０２）、ＤＮＳ名前データベース表２２に格納されているドメイン名２２ａとその格納位置を取得し（ステップ１０３）、固定部長さ情報１６ａおよび帯域部長さ情報１６ｂを使ってドメイン名２２ａを固定部と帯域部と通番部の３つに分割する（ステップ１０４）。例えば、「７．６．５．４．３．２．１．３．１．８．ｅ１６４．ａｒｐａ．」というドメイン名の場合には、固定部長さ情報１６ａおよび帯域部長さ情報１６ｂがそれぞれ「５」、「３」なので、固定部は「３．１．８．ｅ１６４．ａｒｐａ．」、帯域部は「３．２．１」、通番部は「７．６．５．４」となる。
【００４０】
  次に、索引生成部１１は、帯域部索引管理部１４を使って帯域部「３．２．１」に対応する帯域部索引１７の要素を検索して対応する通番部索引１８を選択し（ステップ１０５）、通番部索引管理部１５を使って、選択された通番部索引１８の中に通番部「７．６．５．４」に対応する要素を生成し、生成された要素にレコード格納位置を記憶させる（ステップ１０６）。
【００４１】
  複数のドメイン名がＤＮＳ名前データベース表２２に格納されている場合は、ステップ１０３からステップ１０６を繰り返して索引を生成していく。」
　
「【００４４】
  次に、索引の検索の処理を具体例により説明する。
【００４５】
  「７．６．５．４．３．２．１．３．１．８．ｅ１６４．ａｒｐａ．」というドメイン名に対応するリソースレコードを検索するものとする。
【００４６】
  ＤＮＳクライアント装置３ではネットワーク４を介してＤＮＳサーバ装置２に対して、「７．６．５．４．３．２．１．３．１．８．ｅ１６４．ａｒｐａ．」というドメイン名に対応するリソースレコードを問い合わせる（ステップ２０１）。
【００４７】
  ＤＮＳサーバ装置２では、ＤＮＳ検索処理部２１が問い合わせを受けて、問い合わされたドメイン名に対応するリソースレコードを検索するために、索引を検索する。具体的には、レコードの格納位置を索引検索部１２に問い合わせる（ステップ２０２）。
【００４８】
  索引検索部１２では、ＩＤ情報管理部１３を使ってＩＤ情報管理表１６から固定部長さ情報１６ａおよび帯域部長さ情報１６ｂとしてそれぞれ「５」および「３」を取得し（ステップ２０３）、問い合わされたドメイン名「７．６．５．４．３．２．１．３．１．８．ｅ１６４．ａｒｐａ．」を固定部と帯域部と通番部の３つに分割する（ステップ２０４）。固定部長さ情報１６ａおよび帯域部長さ情報１６ｂがそれぞれ「５」および「３」なので、固定部は「３．１．８．ｅ１６４．ａｒｐａ．」、帯域部は「３．２．１」、通番部は「７．６．５．４」となる。次に、索引検索部１２は、帯域部索引管理部１４を使って帯域部「３．２．１」に対応する帯域部索引１７の要素を検索して対応する通番部索引を確定し（ステップ２０５）、通番部索引管理部１５を使って、確定した通番部索引１８の中から通番部「７．６．５．４」に対応する要素を選択し、選択した要素からレコードの格納位置を確定し（ステップ２０６）、ＤＮＳ検索処理部２１にレコード格納位置を応答する（ステップ２０７）。
【００４９】
  ＤＮＳ検索処理部２１は、索引検索部１２により検索されたレコード格納位置の情報を元にＤＮＳ名前データベース表２２を検索し、問い合わされたドメイン名「７．６．５．４．３．２．１．３．１．８．ｅ１６４．ａｒｐａ．」に対応するリソースレコード２２ｂを取得し（ステップ２０８）、ＤＮＳクライアント装置３にリソースレコード２２ｂを応答する（ステップ２０９）。」
　
　出願当初の明細書の上記記載における「ＩＤ情報表１６」あるいは「ＩＤ情報管理表１６」が、特許請求の範囲の請求項の記載における「ＩＤ情報表」に対応する表であると解されるところ、上記「ＩＤ情報表１６」あるいは「ＩＤ情報管理表１６」に記録されている情報は、「固定部長さ情報１６ａ」及び「帯域部長さ情報１６ｂ」であるとされている。
　そして、出願当初の明細書の上記記載に示される「７．６．５．４．３．２．１．３．１．８．ｅ１６４．ａｒｐａ．」というドメイン名の場合の具体例では、「固定部長さ情報１６ａ」は「５」、「帯域部長さ情報１６ｂ」は「３」であるとされており、それぞれ、「３．１．８．ｅ１６４．ａｒｐａ．」という固定部、及び「３．２．１」という帯域部の長さ情報を表している。
　すなわち、出願当初の明細書の上記記載において、「ＩＤ情報表１６」あるいは「ＩＤ情報管理表１６」に記録されている「固定部長さ情報１６ａ」及び「帯域部長さ情報１６ｂ」は、それぞれ、国番号と市外局番を併せた部分である固定部の長さ情報、及び市内局番という帯域部の長さ情報という２つの情報である。
　一方、補正後の特許請求の範囲の請求項にいう「国番号、市外局番、市内局番の長さ情報」とは、「国番号」、「市外局番」、「市内局番」それぞれの長さ情報という３つの長さ情報であるとも、あるいは「国番号、市外局番、市内局番」の長さをすべて合計した長さ情報という１つの長さ情報であるとも解釈できる情報である。
　しかるに、出願当初の明細書、特許請求の範囲又は図面の他のいずれの箇所を見ても、「ＩＤ情報表１６」あるいは「ＩＤ情報管理表１６」が、「国番号」、「市外局番」、「市内局番」それぞれの長さ情報という３つの長さ情報、あるいは「国番号、市外局番、市内局番」の長さをすべてを合計した長さ情報という１つの長さ情報を記録するということは、記載も示唆もされていない事項であり、また、このことは、出願当初の明細書、特許請求の範囲又は図面のすべての記載を総合することにより導かれる技術的事項との関係において、新たな技術的事項を導入するものであると認められる。
　
　したがって、上記補正内容（ア）〜（ウ）を含む本件手続補正は、願書に最初に添付した明細書、特許請求の範囲又は図面に記載した事項の範囲内においてしたものであるとは認められず、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第３項の規定に違反するものである。
　
（２）補正の目的の適否について
　次に、本件手続補正の目的が平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第４項の規定に適合するか否かを検討する。
　
　本件手続補正は、上記補正内容（ア）〜（ウ）に加えて、
（エ）補正前の請求項３における、
「ＩＤ体系の意味構造の区分に合わせて、データ列であるＩＤを、固定的な固定部、半固定的な帯域部、ランダムな通番部の３つに分割し」
との記載を、補正後の請求項１における、
「データ列であるＩＤを、国番号、市外局番、市内局番、加入者番号という意味構造に分割し」
との記載に補正することを含むものである。
　
　上記補正内容（ア）〜（ウ）は、「記憶装置内のＩＤ情報表」に記録されている内容を、補正前の「索引の生成対象となるＩＤの意味構造における固定部長さ情報と帯域部長さ情報」から「索引の生成対象となるＩＤの意味構造における国番号、市外局番、市内局番の長さ情報」に補正するものであり、この補正は、上記（１）で検討したように、「長さ情報」を、「国番号と市外局番を併せた部分である固定部の長さ情報及び市内局番という帯域部の長さ情報という２つの情報」から、「「国番号」、「市外局番」、「市内局番」それぞれの長さ情報という３つの長さ情報であるとも、あるいは「国番号、市外局番、市内局番」の長さをすべて合計した長さ情報という１つの長さ情報であるとも解釈できる情報」に変更するものであり、補正前の特許請求の範囲の請求項４乃至１０に記載された発明を特定するために必要な事項を限定して特許請求の範囲の減縮をしたものではない。
　
　次に、上記補正内容（エ）により補正された補正後の記載であるところの「データ列であるＩＤを、国番号、市外局番、市内局番、加入者番号という意味構造に分割し」との記載について検討する。
　上記補正後の記載では、「固定的な固定部」、「半固定的な帯域部」、「ランダムな通番部」という補正前の記載が、「国番号」、「市外局番」、「市内局番」、「加入者番号」に補正されている。
　このうち、「加入者番号」は、「ランダムな通番部」の下位概念に該当するということができるが、「国番号」、「市外局番」、「市内局番」は、どの部分が「固定的な固定部」、「半固定的な帯域部」の下位概念に該当するのかは、一概にいえない。
　すなわち、本願の実施例においては、「ＩＤとしてある市外局番配下の電話番号を管理するデータベース表」（段落【００１４】）を想定しているため、「国番号」、「市外局番」が「固定的な固定部」であり、「市内局番」が「半固定的な帯域部」となっているが、「ＩＤとしてある国内の電話番号を管理するデータベース表」もあり得るのであって、そのような場合には、「国番号」が「固定的な固定部」となり、「市外局番」、「市内局番」が「半固定的な帯域部」となると解される。
　さらに、「ＩＤとして全世界の電話番号を管理するデータベース表」や、「ＩＤとしてある市内局番配下の電話番号を管理するデータベース表」を想定すると、前者の場合には、「国番号」、「市外局番」、「市内局番」のすべてが「半固定的な帯域部」となり、後者の場合には、「国番号」、「市外局番」、「市内局番」のすべてが「固定的な固定部」となると解される。
　このように、「国番号」、「市外局番」、「市内局番」は、どの部分が「固定的な固定部」、「半固定的な帯域部」の下位概念に該当するのかは、一概にいえないから、上記補正内容（エ）は、補正前の特許請求の範囲の請求項３に記載された発明を特定するために必要な事項を限定して特許請求の範囲の減縮をしたものではない。
　
　以上のとおり、上記補正内容（ア）〜（エ）によって補正された補正後の請求項１乃至８に記載された発明は、補正前の請求項３乃至１０に記載された発明を特定するために必要な事項を限定して特許請求の範囲の減縮をしたものとは認められず、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第４項第２号の規定に適合しない。
　
　さらに、上記補正内容（ア）〜（エ）のように補正することが、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第４項第１号の請求項の削除、第３号の誤記の訂正、第４号の明りょうでない記載の釈明に該当するものでないことは明らかである。
　
　したがって、本件手続補正は、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第４項の規定に違反するものである。
　
（３）むすび
　上記（１）、（２）で検討したとおり、本件手続補正は、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第３項及び第４項の規定に違反するものであり、同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下されるべきものである。
　
３．補正却下の決定を踏まえた検討
（１）本願発明
　平成２０年３月７日付けの手続補正は、上記のとおり却下されたので、本願の請求項３に係る発明は、出願当初の特許請求の範囲の請求項３に記載されたとおりの次のものと認める。（以下、「本願発明」という。）
「ＩＤを管理するデータベースにおける索引検索方法であって、
　ＩＤ体系の意味構造の区分に合わせて、データ列であるＩＤを、固定的な固定部、半固定的な帯域部、ランダムな通番部の３つに分割し、
　分割されたＩＤの帯域部に対してハッシュ法を適用して帯域部索引を検索し、複数ある通番部索引の中から１つの通番部索引を選択し、
　分割されたＩＤの通番部に対してツリー法あるいはハッシュ法を適用して選択された通番部索引を検索し、前記ＩＤに対応するレコードの格納位置を確定する索引検索方法。」
　
（２）引用例及び周知例
　これに対して、原査定の拒絶の理由に引用された特開平６−１３９２８０号公報（以下、「引用例」という。）、及び原査定の備考欄において周知例として引用された特開平１１−１３４２３２号公報（以下、「周知例」という。）には、それぞれ、図面とともに次の事項が記載されている。
　
（引用例）
Ａ．「【請求項２】  キーによってデータを検索するファイル管理システムにおいて、
異なる複数のキー値にそれぞれ対応して設けられた複数のツリー構造データファイルと、
第１の検索キー値に応じてそのキー値に対応する前記複数のツリー構造データファイルの１つをハッシュ関数によって選択するハッシュ検索手段と、
このハッシュ検索手段によって選択されたツリー構造データファイルを、第２の検索キー値に応じて検索するツリー検索手段とを具備し、
ハッシュ関数で選択されたツリー構造のデータファイルを検索することを特徴とするファイル管理システム。」
　
Ｂ．「【０００１】
【産業上の利用分野】この発明はファイル管理システムに関し、特にコンピュータシステムの２次記憶装置中のデータを検索するためのファイル管理システムに関する。」
　
Ｃ．「【００１３】図１にはこの発明の一実施例に係わるコンピュータシステムのファイル管理システムの構成が示されている。このファイル管理システム１１は、キー属性認識モジュール１１１、ハッシュ管理モジュール１１２、およびツリー管理モジュール１１３から構成されている。
【００１４】キー属性認識モジュール１１１は、キーＫ全体における部分キーの位置と属性とを認識するためのものであり、キーＫを構成する部分キーＫ１，Ｋ２毎にユーザによって明示的に指定されたアクセス属性を判定し、その判定結果に応じてハッシュ管理モジュール１１２、およびツリー管理モジュール１１３の一方を選択する。例えば、部分キーＫ１がハッシュ属性であり、部分キーＫ２がツリー属性の場合は、キー属性認識モジュール１１１は、部分キーＫ１についてはそれをハッシュ管理モジュール１１２に渡してハッシュ関数による検索を実行させ、部分キーＫ２についてはそれをツリー管理モジュール１１３に渡してツリー構造による検索を実行させる。
【００１５】ハッシュ管理モジュール１１２は、部分キーの属性がハッシュ属性である場合のキーアクセスを管理するためのものであり、ハッシュ関数によるキー検索を行なう。ハッシュ関数は、キーの内部コードからハッシュ表のアドレスへの変換を行なう関数であり、この関数によって得られるアドレスはハッシュアドレスと呼ばれている。
　・・・（中略）・・・
【００１８】データファイル１２は検索対象のデータファイルであり、ツリー構造データファイルとハッシュ編成ファイルの２つの索引構造を有し、例えば、異なる複数のキー値にそれぞれ対応して設けられた複数のツリー構造データファイルと、部分キー値に応じてそのキー値に対応する複数のツリー構造データファイルの１つをハッシュ関数によって選択するハッシュ編成ファイルとから構成されている。
【００１９】例えば、キーＫの第１の部分キーＫ１の属性がハッシュ属性、第２の部分キーＫ２属性がツリー属性の場合を想定する。この場合、ハッシュ管理モジュール１１２は、ハッシュ関数ｈ（Ｋ１）によって、ツリー構造データファイルの先頭レコードのアドレスを求める。次いで、ツリー管理モジュール１１３は、そのハッシュ関数によって求められたツリー構造データファイルを２分木等の手法で検索し、キーＫ２を探す。次に、図２のフローチャートを参照して、ファイル管理システム１１による検索処理動作を説明する。
【００２０】キーの検索においては、まず、検索対象キーＫが利用者により与えられる。ファイル管理システム１１は、その検索対象キーＫを、キー属性認識モジュール１１１によって部分キーに分解して、その属性をチェックする（ステップＳ１１）。この例では、検索対象キーＫは２個の部分キーＫ１、Ｋ２から構成され、部分キーＫ１の属性はハッシュ属性、部分キーＫ２の属性はツリー属性である。
【００２１】これら部分キーの属性は利用者によって明示的に指定されるものであり、例えば、予め部分キー毎に属性を指定しておいても良いし、検索対象キーＫを指定する時に各部分キーに属性情報を付与してもよい。
【００２２】ファイル管理システム１１は、まず、最初の部分キーＫ１についてそれがツリー属性かハッシュ属性かを判断し（ステップＳ１２）、ハッシュ属性であればそれをハッシュ管理モジュール１１２に渡してハッシュ関数による部分キー検索を実行する（ステップＳ１３）。
【００２３】ハッシュ管理モジュール１１２による検索の結果、部分キー値Ｋ１が見つからなければ、検索失敗で検索は終了する（ステップＳ１５，ステップＳ１６）。一方、部分キー値Ｋ１が見つかれば、次の部分キーＫ２の検索を行なう。
【００２４】すなわち、ファイル管理システム１１は、次の部分キーＫ２についてそれがツリー属性かハッシュ属性かを判断し（ステップＳ１２）、ツリー属性であればそれをツリー管理モジュール１１３に渡してツリー構造よる部分キー検索を実行する（ステップＳ１４）。ここでは、ツリー構造の検索は、ハッシュ関数ｈ（Ｋ１）によって求められたツリー構造ファイルについて実行される。
【００２５】ツリー管理モジュール１１３による検索の結果、部分キー値Ｋ２が見つからなければ、検索失敗で検索は終了する（ステップＳ１５，ステップＳ１６）。一方、部分キー値Ｋ２が見つかれば、部分キーＫ２が最終部分キーであることを条件に、検索成功で検索処理が終了する（ステップＳ１７，Ｓ１８）。図３には、データファイル１２の具体的構成の一例が示されている。」
　
Ｄ．「【００２６】このデータファイル１２においては、各レコードに、出身地を示すフィールド、名前を示すフィールド、年齢を示すフィールド等が割り当てられている。データファイル１２から、出身地が“神奈川県”で、名前が“田中”というデータを検索する場合を考える。この場合、検索キーは、出身地を示すフィールドと名前を示すフィールドとの２つの部分キーから構成される。そして、最初の部分キーＫ１は“神奈川県”であり、次の部分キーＫ２は“田中”である。
【００２７】図４には、キー属性認識モジュール１１１に設けられるキー属性認識テーブルの定義内容の一例ず示されている。このキー属性認識テーブルには、各キーとなるフィールドそれぞれについては、そのフィールドの先頭位置とレングス（サイズ）情報、および予めユーザによって指定された属性情報が定義されている。
【００２８】ここでは、先頭位置が“０”でサイズが“５”のフィールドは出身地を示すフィールドであり、このフィールドはハッシュ属性である。また、先頭位置が“５”でサイズが“１５”のフィールドは名前を示すフィールドであり、このフィールドはツリー属性である。
【００２９】このため、キー属性認識モジュール１１１は、最初の部分キーＫ１となる出身地フィールドの値“神奈川県”をハッシュ管理モジュール１１２に渡し、次の部分キーＫ２となる名前フィールドの値“田中”をツリー管理モジュール１１３に渡する。
【００３０】図５には、出身地フィールドの値“神奈川県”をキーとするハッシュ検索の様子と、名前フィールドの値“田中”をキーとするツリー検索の様子が示されている。
【００３１】ハッシュ管理モジュール１１２は、ハッシュ関数ｈ（神奈川）を実行し、その結果Ｔｏで指定される索引ファイルを選定する。索引ファイルＴｏは、神奈川を同一キーとして構成されたツリー構造の索引ファイルである。ツリー管理モジュール１１３は、索引ファイルＴｏを検索し、値“田中”を検索する。」
　
　上記Ｄに記載の具体例では、「部分キーＫ１」として、４７都道府県という限られた数の都道府県のうちの１つの“神奈川県”が例示されており、また、このキーは、地域（帯域）を表すものであるから、「半固定的な帯域部」であるということができる。
　また、「部分キーＫ２」としては、“田中”が例示されており、このキーは、「任意の名前部」であるということができる。
　
　よって、上記Ａ〜Ｄの記載及び関連する図面を参照すると、引用例には、実質的に、次の発明が記載されているものと認められる。（以下、「引用例記載の発明」という。）
「キーを管理するデータファイルにおける索引検索方法であって、
　キーの意味構造の区分に合わせて、データ列であるキーを、半固定的な帯域部、任意の名前部の２つに分割し、
　分割されたキーの帯域部に対してハッシュ法を適用して帯域部索引を検索し、複数ある名前部索引の中から１つの名前部索引を選択し、
　分割されたキーの名前部に対してツリー法を適用して選択された名前部索引を検索する索引検索方法。」
　
（周知例）
Ｅ．「【０００４】
【課題を解決するための手段】本発明は上記課題を解決するために、記憶媒体の記憶領域を所定数の格納領域に分割し、識別符号に所定の演算を施した演算結果に基づいて、当該識別符号が付されたデータを格納すべき格納領域を決定して記録し、当該識別符号が付されたデータが格納された格納領域を検索するようにしたものであり、好ましくは、識別符号を数字または数字に変換可能なアルファベット、記号、漢字等の文字列で構成し、識別符号に施される所定の演算は文字列の数字または文字が変換された数字を加算処理し、得られた和に除算処理した剰余を求めるものとしたり、演算の対象とされる識別符号はデータに付された識別符号の中、特定箇所の符号を除いた識別符号としたものである。」
　
Ｆ．「【００１０】本具体例ではキーコードの文字列を８個の英数字のみで構成し、それらの全てを演算対象としたが、本発明は可変長のキーコードが付されたデータの記録・検索にも同様に適用できる。さらに、キーコード中の幾つかが固定文字列であった場合には、データの配分に偏りが生じる虞があるので、当該文字列を演算対象から除外すればより効率の良いデータの記録・検索を行える。文字列中に漢字や記号等を含む文字列から成るキーコードのデータに対しても同様に本発明を適用できるが、この場合には文字列中の特定の文字の出現頻度が高くなるので、上述の固定文字列に対する対処と同様の手法を取れば、より効果的である。」
　
（３）対比
　本願発明と引用例記載の発明とを対比すると、次のことがいえる。
　
（あ）本願発明における「ＩＤ」も、「キー」の一種であるということができる。
　
（い）引用例記載の発明における「データファイル」は、本願発明における「データベース」に相当する。
　
（う）引用例記載の発明における「任意の名前部」と、本願発明における「ランダムな通番部」とは、ともに、「ランダムなキー部」であるということができる。
　そして、本願発明において、「ランダムなキー部」である「ランダムな通番部」に対して適用される検索法は、「ツリー法あるいはハッシュ法」という択一的な方法となっているが、そのうちの「ツリー法」については、引用例記載の発明において、「任意の名前部」に対して適用される「ツリー法」と同様である。
　
　よって、上記（あ）〜（う）の事項を踏まえると、本願発明と引用例記載の発明とは、次の点で一致し、また、相違するものと認められる。
　
（一致点）
　本願発明と引用例記載の発明とは、ともに、
「キーを管理するデータベースにおける索引検索方法であって、
　キー体系の意味構造の区分に合わせて、データ列であるキーとして、少なくとも、半固定的な帯域部、ランダムなキー部の２つの分割部分を設け、
　分割されたキーの帯域部に対してハッシュ法を適用して帯域部索引を検索し、複数あるランダムなキー部索引の中から１つのランダムなキー部索引を選択し、
　分割されたキーのランダムなキー部に対してツリー法を適用して選択されたランダムなキー部索引を検索する索引検索方法。」
である点。
　
（相違点）
　相違点１：「キー」が、本願発明においては「ＩＤ」であるのに対し、引用例記載の発明においては「ＩＤ」であるとはされていない点。
　
　相違点２：「ランダムなキー部」が、本願発明においては「ランダムな通番部」であるのに対し、引用例記載の発明においては「任意の名前部」である点。
　
　相違点３：本願発明においては、「データ列であるキー（ＩＤ）」を、「固定的な固定部」、「半固定的な帯域部」、「ランダムな通番部」の３つに分割しているのに対し、引用例記載の発明においては、「半固定的な帯域部」、「任意の名前部」の２つの分割部分を設けているものの、「固定的な固定部」を含めた３つには分割していない点。
　
　相違点４：本願発明においては、最終的に、「ＩＤに対応するレコードの格納位置を確定する」という動作を行っているのに対し、引用例のものにおいては、そのような動作を行うことが明示されていない点。
　
（４）判断
　そこで、上記相違点１〜４について検討する。
　
（相違点１について）
　一般に、「ＩＤ」をデータベースにより管理し、該データベースから「ＩＤ」をキーとして情報を引き出すようにすることは、ごく普通に行われていることにすぎないから、引用例記載の発明において、「ＩＤ」をキーとすることは、当業者が容易に想到し得ることにすぎない。
　
（相違点２について）
　データベースにより管理するデータとして、例えば、電話システムにおける加入者番号などの通番データも、ごく一般的なものにすぎない。
　よって、引用例記載の発明において、「ランダムなキー部」を「ランダムな通番部」とすることは、当業者が適宜になし得ることである。
　
（相違点３について）
　周知例の上記Ｅに「・・・演算の対象とされる識別符号はデータに付された識別符号の中、特定箇所の符号を除いた識別符号としたものである。」と記載され、上記Ｆに「・・・さらに、キーコード中の幾つかが固定文字列であった場合には、データの配分に偏りが生じる虞があるので、当該文字列を演算対象から除外すればより効率の良いデータの記録・検索を行える。・・・」と記載されているように、一般に、固定文字列を検索の演算対象外とすることは、周知技術にすぎない。
　してみれば、引用例記載の発明において、「データ列であるキー」に「固定的な固定部」が含まれている場合、その部分を検索の演算対象外とするために、その部分を分けて切り出すようにすること、すなわち、「固定的な固定部」を除いて残りを「半固定的な帯域部」、「ランダムなキー部」の２つに分割するようにすることは、当業者が適宜になし得ることである。
　そして、上記「相違点２について」で検討したように、「ランダムなキー部」を「ランダムな通番部」とすることは、当業者が適宜になし得ることであるから、「固定的な固定部」を除いて残りを「半固定的な帯域部」、「ランダムなキー部」の２つに分割する場合、結果として、キー部全体が「固定的な固定部」、「半固定的な帯域部」、「ランダムな通番部」の３つに分割されることになるものであり、そのようにすることは、当業者が適宜になし得ることである。
　
（相違点４について）
　データベースの検索をキーによって行う場合、最終的にキーに対応するレコードの格納位置を確定することは、ごく普通の動作にすぎない。
　そして、上記「相違点１について」で検討したように、引用例記載の発明において、「ＩＤ」をキーとすることは、当業者が容易に想到し得ることにすぎないから、最終的に、「ＩＤに対応するレコードの格納位置を確定する」という動作を行うようにすることは、当業者が適宜になし得ることにすぎない。
　
（本願発明の作用効果について）
　そして、本願発明の構成によってもたらされる効果も、引用例記載の発明及び上記周知技術から当業者が容易に予測することができる程度のものであって、格別のものとはいえない。
　
（５）むすび
　以上のとおり、本願発明は、引用例記載の発明及び上記周知技術に基いて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　したがって、本願は、他の請求項について検討するまでもなく、拒絶されるべきものである。
　よって、結論のとおり審決する。