【事件の表示】
　特願２００１−３５６４５６「文書の圧縮格納方法」拒絶査定不服審判事件〔平成１５年　５月３０日出願公開、特開２００３−１５７２４９〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯・本願特許請求の範囲の記載
　本願は、平成１３年１１月２１日の出願であって、本願特許請求の範囲の記載は、平成２１年１１月３０日付け手続補正書の【特許請求の範囲】の欄に記載されたとおりであり、その請求項１乃至３の記載は以下のとおりである。
「【請求項１】タグノード（Ｔ）、属性ノード（ＡＴＴＲ）及び／又はテキストノード（ＣＤＡＴＡ）からなる複数種の構造化された文書構造体で各々が表される複数の文書集合を圧縮し、これを高速に検索するためのデータ構造をコンピュータ上で提供するための方法であって、
　コンピュータとして文書を入力する入力部と、前記入力された文書を変換する変換部と、前記入力された文書又は前記変換部において変換された文書を格納する格納部とを備えるものを使用し、
　前記変換部において、前記文書集合を構成する前記複数種の文書構造体を構成する各ノードタグ（Ｔ）に係属する属性ノード（ＡＴＴＲ）又はテキストノード（ＣＤＡＴＡ）を要素として識別するための要素識別子ノードを付与し、
　前記要素識別子ノードに対して、既出の要素識別子ノードには同じＩＤが割り当てられるように整数連番として要素ＩＤを割り当て、
　前記要素ＩＤが割り当てられた要素識別子ノードに対応する属性ノード又はテキストノードに格納された実データに対しては、既出の実データの値には同じＩＤが割り当てられるように整数連番として実データノードＩＤを割り当て、
　前記複数の文書ごとに、前記要素ＩＤと対応する実データノードＩＤとからなる非構造化されたデータの組のリストであって前記要素ＩＤの昇順にソートされたリストを形成し、
　前記要素ＩＤと実データノードＩＤとの組の前記要素ＩＤの昇順にソートされたリストを有する前記複数の文書に文書ＩＤを割り当て、
　前記複数の文書における要素ＩＤと実データノードＩＤとの各組について、前記要素ＩＤごとに、前記実データノードＩＤに対応する実データを有する文書の文書ＩＤを、前記実データごとにリストとして形成する
という一連の処理を行い、その結果得られたデータ構造を検索のために前記コンピュータの前記格納部に格納することを特徴とする方法。
【請求項２】請求項１に記載の方法において、前記複数の文書における要素ＩＤと実データノードＩＤとの各組について、前記要素ＩＤごとに、前記実データノードＩＤに対応する実データを有する文書の文書ＩＤを、前記実データごとにリストとして形成したことにより、
　検索キーとして１組の属性及び実データが与えられた場合には、前記検索キーとして与えられた実データを、前記検索キーとして与えられた属性に対応する要素ＩＤについての対応実データノードＩＤに属するキー値をたどって一致するか否かを判定し、一致する場合には前記実データノードＩＤに対応する実データを有する文書の文書ＩＤを抽出することを特徴とする方法。
【請求項３】文書を入力する入力部と、前記入力された文書を変換する変換部と、前記入力された文書又は前記変換部において変換された文書を格納する格納部とを少なくとも備えた文書圧縮格納装置であって、
　前記変換部は、前記入力部から入力された文書について、タグノード（Ｔ）、属性ノード（ＡＴＴＲ）及び／又はテキストノード（ＣＤＡＴＡ）からなる複数種の構造化された文書構造体で各々が表される複数の文書集合に変換する文書集合変換機能部を有し、
　前記変換部は、さらに、
　前記複数種の文書から文書構造体を構成する各ノードタグ（Ｔ）に係属する属性ノード（ＡＴＴＲ）又はテキストノード（ＣＤＡＴＡ）を要素として識別するための要素識別子ノードを付与する要素識別子ノード付与機能部と、
　前記要素識別子ノードに対して、既出の要素識別子ノードには同じＩＤが割り当てられるように整数連番として要素ＩＤを割り当てる要素ＩＤ割り当て機能部と、
　前記要素ＩＤが割り当てられた要素識別子ノードに対応する属性ノード又はテキストノードに格納された実データに対しては、既出の実データの値には同じＩＤが割り当てられるように整数連番として実データノードＩＤを割り当てる実データノードＩＤ割り当て機能部と、
　前記複数の文書ごとに、前記要素ＩＤと対応する実データノードＩＤとからなる非構造化されたデータの組のリストであって前記要素ＩＤの昇順にソートされたリストを形成する第１のリスト形成機能部と、
　前記要素ＩＤと実データノードＩＤとの組の前記要素ＩＤの昇順にソートされたリストを有する前記複数の文書に文書ＩＤを割り当てる文書ＩＤ割り当て機能部と、
　前記複数の文書における要素ＩＤと実データノードＩＤとの各組について、前記要素ＩＤごとに、前記実データノードＩＤに対応する実データを有する文書の文書ＩＤを、前記実データごとにリストとして形成する第２のリスト形成機能部と
を備えたことを特徴とする装置。」
　
２．当審で通知した拒絶理由
　一方、当審において平成２１年９月２４日付けで通知した拒絶の理由の概要は、以下のとおりである。
「本件出願は、明細書及び図面の記載が下記の点で不備のため、特許法第３６条第６項２号に規定する要件を満たしていない。
　
　　　　　　　　　　　　　　　　　記
　
（１）本願の請求項１及び３に記載されている「前記要素識別子ノードに対して、既出の要素識別子ノードには同じＩＤが割り当てられるように要素ＩＤを割り当て」について、要素識別子ノードが「既出」かどうかをどのようにして判断しているのかが請求項の記載からは不明であるから、上記「既出の要素識別ノード」が何を指しているのかが不明確である。
　より詳細には、要素識別子ノードの位置関係（階層関係）、属性ノードの属性名、タグノードの繰り返し回数などの情報をどのように用いて、あるいは用いずに既出と判断しているのか、そのロジックが不明である。例えば、上記記載に対応すると思われる発明の詳細な説明中の実施例における図６ｂで、同一の階層関係にある「ＥＩＤ：９」と「ＥＩＤ：１０」のうち、「ＥＩＤ：１０」は直前の「ＥＩＤ：９」とタグノードの階層関係は同一であるが、ＩＤは９ではなく１０が割り振られている。また、同図の「ＥＩＤ：１１」と「ＥＩＤ：１６」のうち、「ＥＩＤ：１６」は「ＥＩＤ：１１」と同一の階層関係にあるが、既出とは判断されずに新たなＩＤ（１６）が割り振られている。
　
（２）本願の請求項１及び３に記載されている「前記要素ＩＤが割り当てられた要素識別子ノードに対応する属性ノード又はテキストノードに格納された実データには、別個のノードＩＤを割り当て」について、各々の実データと、別個のノードＩＤとの関係が不明確である。なお、「別個のノードＩＤ」を回答書の補正案に記載されているように「既出の実データの値には同じＩＤが割り当てられるように実データノードＩＤを割り当て」と補正されると、各々の実データとノードＩＤとの関係は明確になるが、その際には上記（１）と同様に実データが「既出」かどうかをどのように判断しているのかを明確にされたい。
　
　よって、本願の請求項１及び３に係る発明、並びに請求項１を引用する請求項２に係る発明は明確でない。」
　
３．当審の判断
拒絶理由通知の記の（１）で指摘した事項について
　上記請求項１及び３には、依然として「既出の要素識別子ノード」なる記載があるが、当審は該「既出の要素識別子ノード」が何を指しているかが依然として不明確であり、結果として請求項１乃至３に係る発明は依然として不明確であると判断する。理由は以下の通りである。
（１）本願の請求項１及び３には「既出の要素識別子ノード」に関しては「前記要素識別子ノードに対して、既出の要素識別子ノードには同じＩＤが割り当てられるように整数連番として要素ＩＤを割り当て」との記載があるのみで、何をもって要素識別子ノードを「既出の要素識別子ノード」と判断しているのかについての説明は無い。
　平成２１年１１月３０日付け手続補正書にて追加された「整数連番として要素ＩＤを割り当てる」という構成を考慮しても、要素識別子ノードが既出であるかどうかを判断することと上記整数連番として要素ＩＤを割り当てることとがどのように関係するのか記載されておらず、「既出の要素識別子ノード」が何を指しているのかは不明確なままである。
（２）上記記載に対応すると思われる発明の詳細な説明を参酌するに、発明の詳細な説明には以下の記載がある。
「【００１５】
　このようにして作成された単位文書整形式スキーマは、XMLデータベースから読み出される文書集合整形式スキーマと併合される。文書集合整形式スキーマが最初の状態において空である場合には、文書１の整形式スキーマを併合した後の文書集合整形式スキーマは、文書１についての単位文書整形式スキーマと同じ構造になる。同様に、文書集合整形式スキーマが最初の状態において空である場合には、文書２の整形式スキーマを併合した後の文書集合整形式スキーマは、文書２についての単位文書整形式スキーマと同じ構造になる。相違点は、文書集合整形式スキーマにおいては、各要素識別子ノードに識別子として識別番号が付されることである。文書１の単位文書整形式スキーマを併合した後の文書集合整形式スキーマを図６(a)に、文書２の単位文書整形式スキーマを併合した後の文書集合整形式スキーマを図６(b)に、それぞれ示す。この処理は、図１に示す変換過程TRにおいて行われる。このようにして生成された文書集合整形式スキーマは、図１に示すようにXMLデータベースとしてメモリに格納される。」
　
　上記記載、及び図６ａ、図６ｂの記載を参酌しても、要素識別子ノードが既出であるかどうかをどのように判断しているのかが不明である。例えば、図６ｂで、要素ＩＤ１１（ＥＩＤ：１１）を割り当てられた要素識別子ノードと要素ＩＤ１６（ＥＩＤ：１６）を割り当てられた要素識別子ノードとは同一の階層関係にあるが、前者は図６ａに登場するＩＤである１１が割り振られているから既出の要素識別子ノードであると判断されたものと考えられ、後者は新たなＩＤである１６が割り振られているから、既出の要素識別子ノードではないと判断されたものと考えられるが、これらがどのようにしてそう判断されたのかが不明である。また、図６ａにおいて要素ＩＤ１６を割り当てられた要素識別子ノードが存在しないことをもって、図６ｂにおいて要素ＩＤ１６を割り当てられた要素識別子ノードが既出の要素識別子ノードではないと判断されたとすると、例えば、担当者が二人に増えた文書を文書３として登録する場合には「担当者」の要素識別子ノードは二つ必要になり、図６ａ及び図６ｂにおいて「担当者」の要素識別子ノードは要素ＩＤ８を割り当てられた要素識別子ノードしかないから二つ目の要素識別子ノードは明らかに既出ではないと判断されるものと考えられるが、図６ａ及び図６ｂには要素ＩＤ８の次の整数連番である９を要素ＩＤとして割り当てられた要素識別子ノードが既に存在するから、要素ＩＤの有無のみでは上記二つ目の要素識別子ノードが既出であるかどうかを判断することはできない。
　また、要素識別子ノードが既出であるかどうかをどのように判断するのかについて、発明の詳細な説明及び図面には上記した箇所以外にも記載が無く、したがって、要素識別子ノードが既出であるかどうかをどのように判断しているのかは発明の詳細な説明及び図面全体を参酌しても依然として不明であり、「既出の要素識別子ノード」が何を指しているのかは依然として不明確である。
（３）審判請求人は平成２１年１１月３０日付け意見書において、以下のように主張している。
「（１）本願の請求項１に係る発明（以下、本願第一発明とします）を、特許請求の範囲に記載された通り補正致しました。補正は、審尋回答書の補正に基づいて、審判官殿の上記ご指摘を踏まえたものであり、その構成は、次の通り、
　（中略）
　以上のような構成としたことにより、本願第一発明は、例えば、本願明細書段落００４２に記載されているように、『本発明により、構造が可変で不確定要素の多い、例えばXML文書のような文書を扱うに際し、その文書構造が変化する場合でも、実データの格納構造を変更することなくXMLドキュメントを管理することができ、しかも、高速な検索や複雑な統計・分析を可能とするXMLデータベースを得ることが可能となる』等の特段かつ有利な効果を奏するものであります。
　また、上述の通り、構成の根拠も明確になり、発明としての意味も明りょうになりましたので、第３６条の拒絶理由は解消いたしました。」
　
　しかし、審判請求人の上記主張は、発明としての意味が明りょうになったと漠然と主張するのみで、何をもって要素識別子ノードを「既出の要素識別子ノード」と判断しているのかについては何ら釈明されていない。
　
　以上のとおりであるから、請求項１及び３に係る発明、並びに請求項１を引用する請求項２に係る発明は明確でない。
　
４．むすび
　以上のとおり、本願の請求項１乃至３に係る発明は明確でない。
　したがって、本願は特許法第３６条６項２号に規定される要件を満たしていないので拒絶されるべきものである。
　よって、結論のとおり審決する。