【事件の表示】
　特願２００２−３２９８１８「データ管理装置、データ管理方法、およびプログラム」拒絶査定不服審判事件〔平成１６年　６月１０日出願公開、特開２００４−１６４３２０〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願は、平成１４年１１月１３日の出願であって、平成２０年２月１日付けで拒絶理由通知がなされ、同年４月７日付けで手続補正がなされたが、同年４月２５日付けで拒絶査定がなされ、これに対し、同年６月６日に拒絶査定不服審判の請求がなされるとともに、同年７月７日付けで手続補正がなされたものである。
　
２．平成２０年７月７日付けの手続補正についての補正却下の決定
［補正却下の決定の結論］
　平成２０年７月７日付けの手続補正を却下する。
　
［理由］
（１）新規事項の追加の有無について
　平成２０年７月７日付けの手続補正（以下、「本件手続補正」という。）により補正された請求項１，７，８における「前記医用データグループに含まれる医用データの内、削除対象となる医用データを設定する設定手段（工程）」及び「前記設定手段で設定された削除対象となる医用データの内、前記削除禁止情報が付された医用データに関連付けられた医用データ以外の医用データを削除する削除手段（工程）」について検討する。
　
　上記「削除手段（工程）」によって削除される「前記削除禁止情報が付された医用データに関連付けられた医用データ以外の医用データ」は、「前記設定手段で設定された削除対象となる医用データの内」のものであるところ、該「削除対象となる医用データ」は、「前記医用データグループに含まれる医用データの内」のものであるから、結果として、上記「前記削除禁止情報が付された医用データに関連付けられた医用データ以外の医用データ」は、「前記医用データグループに含まれる医用データの内」のものであることになる。
　そこで、「前記医用データグループに含まれる医用データの内」のものである「前記削除禁止情報が付された医用データに関連付けられた医用データ以外の医用データ」を削除する削除手段（工程）が、出願当初の明細書又は図面のすべての記載を総合することにより導かれる技術的事項との関係において、新たな技術的事項を導入するものであるか否かについて、以下、検討する。
　
　出願当初の明細書の段落【００３２】〜【００３３】には、次の記載がなされている。
「【００３２】
　削除禁止とする範囲は種々設定可能である。例えば、画像データに削除禁止フラグが付されたとき、その画像データが属する患者の全データを削除禁止とする。あるいは削除禁止フラグが付された医用データのみ、または医用データから所定範囲の階層の関連データを削除禁止とする。このように少なくとも１個医用データが削除禁止となったときに、同時に削除禁止とされる医用データの集合を「データグループ」と呼ぶ。
【００３３】
　１個のデータグループにおけるデータ日時の管理は、そのデータグループに含まれるすべて医用データについて行ってもよいし、特定の階層に限定してもよい。例えば、画像データの新旧のみに注目してデータグループ全体の削除可否を決定することができる。このようにデータグループ内で新旧の基準となる医用データが設定されているとき、その医用データを注目データと呼ぶ。注目データは複数の階層について設定してもよい。なおデータグループ内の全ての医用データが新旧判定の対象となるとき、注目データは設定されていないとみなす。」
　
　上記記載によれば、「データグループ」として設定された医用データの集合については、少なくとも１個医用データが削除禁止となったときにデータグループ全体が削除禁止とされるとされている。
　すなわち、上記段落【００３２】〜【００３３】に開示された内容は、「医用データグループに含まれる医用データの内、削除を禁止する医用データに対して削除禁止情報を付」した場合、「医用データグループ」全体が削除禁止とされるものであり、「前記医用データグループに含まれる医用データの内」のものである「前記削除禁止情報が付された医用データに関連付けられた医用データ以外の医用データ」は、当然、削除禁止とされるものであるから、当該「医用データ」を削除する削除手段（工程）は、開示されていないというべきである。
　そして、「前記医用データグループに含まれる医用データの内」のものである「前記削除禁止情報が付された医用データに関連付けられた医用データ以外の医用データ」を削除する削除手段（工程）は、出願当初の明細書又は図面の他の箇所を見ても、記載も示唆もされていない事項であり、出願当初の明細書又は図面のすべての記載を総合することにより導かれる技術的事項との関係において、新たな技術的事項を導入するものである。
　
　なお、請求人は、この点について、審判請求書の「請求の理由」を補正した平成２０年７月７日付け手続補正書において、補正の根拠として、上記段落【００３２】の「例えば、画像データに削除禁止フラグが付されたとき、その画像データが属する患者の全データを削除禁止とする。あるいは削除禁止フラグが付された医用データのみ、または医用データから所定範囲の階層の関連データを削除禁止とする。」との記載を挙げているが、当該記載は、データグループをどのような範囲で設定するかについての記載であり、「前記医用データグループに含まれる医用データの内」のものである「前記削除禁止情報が付された医用データに関連付けられた医用データ以外の医用データ」を削除する削除手段（工程）を開示したものではない。
　
　したがって、上記補正内容を含む本件手続補正は、願書に最初に添付した明細書又は図面に記載した事項の範囲内においてしたものであるとは認められず、特許法第１７条の２第３項の規定に違反するものである。
　
（２）補正の目的の適否について
　次に、本件手続補正の目的が平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第４項の規定に適合するか否かについて検討する。
　
　本件手続補正は、特許請求の範囲の記載を、
「【請求項１】　複数の対応データに関連付けられたデータを管理するデータ管理装置において、
　前記複数の対応データを複数の階層で管理し、階層構造で前記複数の対応データに関連付けられたデータを表示させる表示手段と、
　前記複数の対応データに対して、当該複数の対応データの作成日時もしくは参照日時を示す日時データを付す日時記録手段と、
　前記複数の階層の内、削除判定に用いる階層を設定する設定手段と、
　前記設定された削除判定に用いる階層で、前記日時データに基づき対応データを検出し、当該検出された対応データに関連付けられたデータを削除する削除手段とを備えることを特徴とするデータ管理装置。
　【請求項２】　前記複数の対応データに対して、削除禁止情報を付する削除禁止手段と、
　前記削除手段は、前記設定された削除判定に用いる階層で、前記日時データが最も古く、かつ前記削除禁止情報が付されていない対応データを検出し、当該検出された対応データに関連付けられたデータを削除することを特徴とする請求項１に記載のデータ管理装置。
　【請求項３】　前記削除禁止情報による削除禁止が解除されるまでの期間を設定する期間設定手段を有し、
　前記期間設定手段で設定された期間の経過後は、前記削除禁止情報による削除禁止が解除されることを特徴とする請求項２に記載のデータ管理装置。
　【請求項４】　階層数を設定する階層数設定手段と、
　前記削除手段は、前記設定された削除判定に用いる階層と当該設定された削除判定に用いる階層よりも前記階層数だけ上の階層で、前記日時データが最も古い対応データを検出し、当該検出された対応データに関連付けられたデータを削除することを特徴とする請求項１に記載のデータ管理装置。
　【請求項５】　前記設定手段は、ユーザの指示に基づき、前記複数の階層の内、削除判定に用いる階層を設定することを特徴とする請求項１乃至４のいずれかに記載のデータ管理装置。
　【請求項６】　前記削除手段により削除されたデータを保存する補助記憶手段を有することを特徴とする請求項１乃至５のいずれかに記載のデータ管理装置。
　【請求項７】　前記削除手段は、前記設定された削除判定に用いる階層から最上位階層までの中で、前記日時データが最も古い対応データを検出し、当該検出された対応データに関連付けられたデータを削除することを特徴とする請求項１乃至６のいずれかに記載のデータ管理装置。
　【請求項８】　前記複数の対応データに関連付けられたデータを記憶する記憶手段と、
　前記補助記憶手段に保存されたデータを、再度、前記記憶手段に移動させる移動手段とを備えることを特徴とする請求項６に記載のデータ管理装置。
　【請求項９】　前記記憶手段の空き容量を測定する測定手段を備え、
　前記削除手段は、前記空き容量が所定値以下である場合、前記設定された削除判定に用いる階層で、前記日時データが最も古い対応データを検出し、当該検出された対応データに関連付けられたデータを削除することを特徴とする請求項８に記載のデータ管理装置。
　【請求項１０】　複数の対応データを有するデータを管理するデータ管理方法において、
　表示手段が、前記複数の対応データを複数の階層で管理し、階層構造で前記複数の対応データに関連付けられたデータを表示させる表示工程と、
　日時記録手段が、前記複数の対応データに対して、当該複数の対応データの作成日時もしくは参照日時を示す日時データを付す日時記録工程と、
　設定手段が、前記複数の階層の内、削除判定に用いる階層を設定する設定工程と、
　削除手段が、前記設定された削除判定に用いる階層で、前記日時データに基づき対応データを検出し、当該検出された対応データに関連付けられたデータを削除する削除工程とを備えることを特徴とするデータ管理方法。
　【請求項１１】　コンピュータを、
　前記複数の対応データを複数の階層で管理し、階層構造で前記複数の対応データに関連付けられたデータを表示させる表示手段と、
　前記複数の対応データに対して、当該複数の対応データの作成日時もしくは参照日時を示す日時データを付す日時記録手段と、
　前記複数の階層の内、削除判定に用いる階層を設定する設定手段と、
　前記設定された削除判定に用いる階層で、前記日時データに基づき対応データを検出し、当該検出された対応データに関連付けられたデータを削除する削除手段として機能させるためのプログラム。」（以下、「旧請求項」という。）
から、
「【請求項１】　互いに関連付けられた複数の医用データが含まれる医用データグループを管理するデータ管理装置において、
　前記医用データグループに含まれる医用データを表示させる表示手段と、
　前記医用データグループに含まれる医用データそれぞれに対してデータの保存日時もしくは参照日時を示す日時データを付す日時記録手段と、
　前記日時データに基づき、前記医用データグループに含まれる医用データの内、削除を禁止する医用データに対して削除禁止情報を付す削除禁止手段と、
　前記医用データグループに含まれる医用データの内、削除対象となる医用データを設定する設定手段と、
　前記設定手段で設定された削除対象となる医用データの内、前記削除禁止情報が付された医用データに関連付けられた医用データ以外の医用データを削除する削除手段とを備えることを特徴とするデータ管理装置。
　【請求項２】　前記削除禁止情報による削除禁止が解除されるまでの期間を設定する期間設定手段を有し、
　前記期間設定手段で設定された期間の設定後は、前記削除禁止情報による削除禁止が解除されることを特徴とする請求項１に記載のデータ管理装置。
　【請求項３】　前記設定手段は、ユーザの指示に基づき、前記医用データグループに含まれる医用データの内、削除対象となる医用データを設定することを特徴とする請求項１もしくは２のいずれかに記載のデータ管理装置。
　【請求項４】　前記削除手段により削除された医用データを保存する補助記憶手段を有することを特徴とする請求項１乃至３のいずれかに記載のデータ管理装置。
　【請求項５】　前記医用データグループを記憶する記憶手段と、
　前記補助記憶手段に保存された医用データを、再度、前記記憶手段に移動させる移動手段とを備えることを特徴とする請求項４に記載のデータ管理装置。
　【請求項６】　前記記憶手段の空き容量を測定する測定手段を備え、
　前記削除手段は、前記空き容量が所定値以下である場合、前記設定手段で設定された削除対象となる医用データの内、前記削除禁止情報が付された医用データでなく、かつ当該削除禁止情報が付された医用データに対応付けられた医用データでない医用データを削除することを特徴とする請求項５に記載のデータ管理装置。
　【請求項７】　互いに関連付けられた複数の医用データが含まれる医用データグループを管理するデータ管理方法において、
　表示手段が、前記医用データグループに含まれる医用データを表示させる表示工程と、
　日時記録手段が、前記医用データグループに含まれる医用データそれぞれに対してデータの保存日時もしくは参照日時を示す日時データを付す日時記録工程と、
　削除禁止手段が、前記日時データに基づき、前記医用データグループに含まれる医用データの内、削除を禁止する医用データに対して削除禁止情報を付す削除禁止工程と、
　設定手段が、前記医用データグループに含まれる医用データの内、削除対象となる医用データを設定する設定工程と、
　削除手段が、前記設定手段で設定された削除対象となる医用データの内、前記削除禁止情報が付された医用データに関連付けられた医用データ以外の医用データを削除する削除工程とを備えることを特徴とするデータ管理方法。
　【請求項８】　コンピュータを、
　互いに関連付けられた複数の医用データが含まれる医用データグループに含まれる医用データを表示させる表示手段と、
　前記医用データグループに含まれる医用データそれぞれに対してデータの保存日時もしくは参照日時を示す日時データを付す日時記録手段と、
　前記日時データに基づき、前記医用データグループに含まれる医用データの内、削除を禁止する医用データに対して削除禁止情報を付す削除禁止手段と、
　前記医用データグループに含まれる医用データの内、削除対象となる医用データを設定する設定手段と、
　前記設定手段で設定された削除対象となる医用データの内、前記削除禁止情報が付された医用データに関連付けられた医用データ以外の医用データを削除する削除手段として機能させるためのプログラム。」（以下、「新請求項」という。）
に補正することを含むものである。
　
　上記補正は、平成２０年４月２５日付け拒絶査定の備考欄において、審査官が、
「補正後の請求項１〜１１には、前提となるデータの具体的な内容や、データの格納構造、各文言の定義等が何ら明確に記載されておらず、補正後の請求項１〜１１に係る発明は依然として技術的に意味不明である。
　また、「階層」に関する記載も、依然として不明確である。」
と指摘したのを受けてのものであるので、まず、上記補正が上記指摘した不明りょうな記載の釈明となっているかについて検討する。
　してみると、例えば、旧請求項１において「前記複数の対応データを複数の階層で管理し、階層構造で前記複数の対応データに関連付けられたデータを表示させる表示手段」とあったものを新請求項１において「前記医用データグループに含まれる医用データを表示させる表示手段」と補正することについては、「データの格納構造」や「階層」に関する記載の釈明となっていない。
　すなわち、「表示手段」に関する上記補正により、「表示手段」に表示させる対象は、「前記複数の対応データを複数の階層で管理し、階層構造で前記複数の対応データに関連付けられたデータ」から、階層構造とは無関係な「前記医用データグループに含まれる医用データ」に変更されることになるから、このような補正は、表示させる対象を全く変更する補正であり、「データの格納構造」や「階層」に関する記載の釈明をした補正ではない。
　また、上記補正全体を見ても、「データの格納構造」や「階層」に関する記載の釈明はなされていない。
　よって、上記補正は、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第４項第４号の明りょうでない記載の釈明に該当するものではない。
　
　次に、新請求項１が、旧請求項１を引用する旧請求項２に記載された発明を特定するために必要な事項を限定して特許請求の範囲の減縮をしたものに該当するか否かについて検討する。
　上述したように、例えば、旧請求項１において「前記複数の対応データを複数の階層で管理し、階層構造で前記複数の対応データに関連付けられたデータを表示させる表示手段」とあったものを新請求項１において「前記医用データグループに含まれる医用データを表示させる表示手段」と補正することにより、「表示手段」に表示させる対象は、「前記複数の対応データを複数の階層で管理し、階層構造で前記複数の対応データに関連付けられたデータ」から、階層構造とは無関係な「前記医用データグループに含まれる医用データ」に変更されることになるから、このような補正は、明らかに特許請求の範囲の減縮には該当しない。
　また、旧請求項１０の「表示工程」を新請求項７の「表示工程」に変更する補正、及び旧請求項１１の「表示手段」を新請求項８の「表示手段」に変更する補正も、同様に、特許請求の範囲の減縮に該当しないものであるとともに、新請求項７，８は、旧請求項１０，１１には存在しない「削除禁止工程」あるいは「削除禁止手段」を新たに加えるものであることからも、旧請求項１０，１１に記載された発明を特定するために必要な事項を限定して特許請求の範囲の減縮をしたものには該当しない。
　そして、新請求項１，７，８は、他のどの旧請求項に記載された発明を特定するために必要な事項を限定して特許請求の範囲の減縮をしたものにも該当しない。
　よって、上記補正は、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第４項第２号の特許請求の範囲の減縮に該当するものではない。
　
　さらに、上記補正は、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第４項第１号の請求項の削除、第３号の誤記の訂正に該当するものでないことは明らかである。
　
　したがって、本件手続補正は、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第４項の規定に違反するものである。
　
（３）むすび
　上記（１）、（２）で検討したとおり、本件手続補正は、特許法第１７条の２第３項、及び平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第４項の規定に違反するものであり、同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下されるべきものである。
　
３．補正却下の決定を踏まえた検討
（１）本願発明
　平成２０年７月７日付けの手続補正は、上記のとおり却下されたので、本願の請求項１に係る発明は、平成２０年４月７日付け手続補正書の特許請求の範囲の請求項１に記載されたとおりの次のものと認める。（以下、「本願発明」という。）
「複数の対応データに関連付けられたデータを管理するデータ管理装置において、
　前記複数の対応データを複数の階層で管理し、階層構造で前記複数の対応データに関連付けられたデータを表示させる表示手段と、
　前記複数の対応データに対して、当該複数の対応データの作成日時もしくは参照日時を示す日時データを付す日時記録手段と、
　前記複数の階層の内、削除判定に用いる階層を設定する設定手段と、
　前記設定された削除判定に用いる階層で、前記日時データに基づき対応データを検出し、当該検出された対応データに関連付けられたデータを削除する削除手段とを備えることを特徴とするデータ管理装置。」
　
（２）引用例及び周知例
　これに対して、原査定の拒絶の理由に引用された特開平１０−２２４３９５号公報（以下、「引用例」という。）には、図面とともに次の事項が記載されている。
　
Ａ．「【０００１】
【発明の属する技術分野】本発明は、複数の利用者がメッセージを登録及び参照することで、討論、会議、議論、討議、意見交換、世間話などを行なう、いわゆる電子会議システムに関する。
【０００２】
【従来の技術】電子会議システムにおいては、登録されたメッセージを親子関係をつけて管理することで、話の流れをわかりやすくしている。あるメッセージに対してコメントが付けられた場合には、ものとメッセージが親となりコメントのメッセージが子となる。一つのメッセージには複数のコメントを付けることが可能で、討論は一つの木構造を構成する。最初のメッセージをトピックメッセージ（または、単にトピック）、他のメッセージに対するコメントのメッセージをリプライメッセージと呼ぶ。」
　
Ｂ．「【０００６】また、電子会議システムでは利用者の利便のために、利用者履歴情報として利用者毎にどのメッセージを読んだかを記憶しておき、利用者が登録されているメッセージの一覧情報等を表示するような場合に、登録されている全てのメッセージ、もしくは、一覧対象のメッセージの個々について、既に読んだメッセージかそうでないかをチェックし、利用者が区別できるようにしていた。また利用者はこの一覧情報を参照することで、新しいメッセージが登録されているか否かを判断することができた。」
　
Ｃ．「【００１５】
【発明の実施の形態】以下に、本発明の実施の形態を図面を用いて説明する。図１は分散型電子会議システムの構成の一例を示す図である。図中、１−ｎ（１−１、１−２、１−３、１−４）はサーバ、２−ｎ（２−１１、２−１２、２−２１、２−２２、２−３１、２−３２、２−４１、２−４２）はクライアント、３−ｎ（３−１、３−２、３−３、３−４）はＬＡＮ(LocalArea Network)、４はＷＡＮ(Wide Area Network) である。
【００１６】電子会議システムの利用者はクライアント２−ｎからＬＡＮ３−ｎ上のサーバ１−ｎにログインし、サーバにメッセージを登録したり、サーバに登録されているメッセージを参照したりすることで、会議、論議、討議、討論、世間話等を行なう。利用者がログインできるサーバはあらかじめ決められている。クライアント２−１の利用者はサーバ１−１にのみログインすることができる。また、クライアント２−２の利用者はサーバ１−２にのみログインすることができる。
　・・・（中略）・・・
【００２０】図２はサーバ１−ｎの処理のフローを示す図である。図に示す通り、サーバ１−ｎはローカル処理、グローバル処理、インターバル処理の３つの処理を行なう。サーバ１−ｎはクライアント３−ｎから、何らかのリクエストがあった場合には、ローカル処理を行なう。他のサーバからデータが送信されてきた場合にはグローバル処理を行なう。あらかじめ定められたインターバル時間を経過した場合には、インターバル処理を行なう。インターバル時間として１日（２４時間）が指定されている場合は毎日決まった時刻にインターバル処理が実行されることになる。
【００２１】利用者が電子会議システムを利用する場合は、クライアント３−ｎからサーバ１−ｎにログインする必要がある。ログインが完了するとサーバ１−ｎに対して様々なリクエストを行なうことで、サーバ１−ｎがリクエストに応じた処理を行ない、必要に応じてクライアント３−ｎに対してデータを送信する。この電子会議システムでは、種類の異なる話題のために、メッセージを登録する対象として複数のフォルダを有する。個々のフォルダにはそれぞれ一意の名前が付与され、識別される。例えば、食事に関連したメッセージを登録するためのフォルダに対して″ＦＯＯＤ″という名前が付与され、また、スポーツに関連したメッセージを登録するフォルダに対して″ＳＰＯＲＴＳ″という名前が付与され運用される。」
　
Ｄ．「【００２２】次に、本実施の形態で使用するデータについて説明する。図１６にメッセージ管理テーブルの構成を示す。メッセージ管理テーブルは登録されたメッセージ毎に、フォルダ名、メッセージＩＤ、発言者名、作成日時、ファイル名、保留情報を管理する。メッセージＩＤはメッセージを識別ための文字列で、メッセージ毎にことなるメッセージＩＤが付与される。メッセージＩＤに関しては後でより詳細に説明する。
【００２３】フォルダ名メッセージが登録されるフォルダの名前である。発言者名は、メッセージの発言者、即ちメッセージを作成した利用者のサーバ１−ｎでの利用者名である。作成日時は、利用者からの要求によりサーバ１−ｎでメッセージをファイルに格納した日時である。
【００２４】メッセージはファイルとして外部記憶装置に格納される。ファイル名はメッセージを格納したファイルのファイル名である。ファイル名はメッセージを格納する際にサーバが自動的に決定する。一つのファイルには一つのメッセージを格納する。保留情報は、登録されているメッセージを利用者に対して参照可能にするか否かを示す情報で、″ｙｅｓ″または″ｎｏ″のいずれかの値をとる。″ｙｅｓ″の場合には利用者は参照不可能で、″ｎｏ″の場合には利用者は参照可能である。
【００２５】図２１はメッセージの親子関係とメッセージＩＤとの関係を示す図である。討論の元となるメッセージ、即ち討論の最初のメッセージをトピックメッセージ（または、単にトピック）と呼ぶ。トピックメッセージに対するコメントとなるメッセージをリプライメッセージと呼ぶ。リプライメッセージに対するメッセージも同様にリプライメッセージと呼ぶ。
【００２６】図２１において、２１１乃至２２２はメッセージで、メッセージ２１１がトピックメッセージである。メッセージ２１２、メッセージ２１３、メッセージ２１４、メッセージ２１５はメッセージ２１１（トッピック）に対するリプライメッセージで、メッセージ２１１はメッセージ２１２、メッセージ２１３、メッセージ２１４、メッセージ２１５の親メッセージと呼び、メッセージ２１２、メッセージ２１３、メッセージ２１４、メッセージ２１５はメッセージ２１１の子メッセージとも呼ぶ。同様の関係が他のメッセージに対しても同様の関係が成立する。
【００２７】メッセージＩＤは階層番号と、順序番号と、パス情報で表される。階層番号はメッセージの親子関係の階層の何番目の階層のメッセージであるかを表す数値である。順序番号は、あるメッセージに対して何番目のリプライメッセージであるかを表す数値である。トピックメッセージの場合は、そのメッセージが登録されるフォルダにおける何番目のメッセージであるかを表す。
【００２８】順序番号はメッセージを登録するサーバにおいて、登録しようとするメッセージがあるフォルダにおいて何番目のトピックメッセージであるか、または親メッセージに対する何番目のリプライメッセージであるかを表している。同じメッセージに対して別々のサーバでリプライメッセージを登録する場合には、同じ順序番号が使用されるが、次に示すパス情報内のサーバ識別番号によって区別することが可能となる。」
　
Ｅ．「【００４１】図８はメッセージ登録処理のフローを示す図である。登録対象のメッセージの内容をファイルに書き込み（ステップＳ８１）、メッセージテーブルにメッセージのメッセージＩＤと、メッセージを登録しようとする（メッセージを作成した）利用者の名前と、メッセージを作成した日時（クライアントからの発言リクエストに起因する登録処理の場合はファイルへの書き込み日時）と、メッセージを格納したファイルのファイル名と、保留情報として″ｎｏ″を書き込む。
【００４２】次にメッセージを登録したフォルダの最終更新日時をフォルダ管理テーブルから求め、登録したメッセージの作成日時と比較し（ステップＳ８３）、登録したメッセージの作成日時の方が新しい場合にはその作成日時をフォルダ管理テーブルに記録する（ステップＳ８４）。さらに、討論管理テーブルに登録したメッセージに関連する情報を登録する（ステップＳ８５）。即ち、メッセージがトピックメッセージの場合には、メッセージを登録したフォルダ名と、登録したメッセージの作成日時とメッセージＩＤとを討論管理テーブルに新規に登録する。登録したメッセージがリプライメッセージの場合には討論管理テーブルに登録されている日時とメッセージの作成日時とを比較してメッセージの作成日時のほうが新しい場合は討論管理テーブルの更新日時を更新する。」
　
Ｆ．「【００４３】図９は削除処理のフローを示す図である。メッセージを削除する場合には削除対象のメッセージに関する情報が登録されているエントリをメッセージ管理テーブルから削除し（ステップＳ９１）、メッセージが格納されているファイルを削除する（ステップＳ９２）。次に、削除したメッセージのメッセージＩＤを削除テーブルに登録する（ステップＳ９３）。
【００４４】更に、削除したメッセージがそのメッセージの属していた討論で最新のものである場合（この場合には、討論管理テーブルに記憶されている討論の更新日時と削除したメッセージの作成日時が一致する）、メッセージを削除した後でのその討論の中での最新のメッセージの作成日時をその討論の更新日時として討論管理テーブルの更新日時を更新する。削除したメッセージがトピックメッセージの場合には討論管理テーブルからエントリを削除する。
【００４５】また、フォルダの削除がリクエストされた場合には、フォルダに登録されている全てのメッセージに関して上記の削除処理を行なった後に、フォルダ管理テーブルからエントリを削除し、フォルダ名を削除管理テーブルに登録する。図１０はグローバル処理のフローを示す図である。グローバル処理はサーバ間で保持するメッセージを一致させるために必要な処理の一部で、他のサーバから送信されてきたデータに基づいてサーバ内に新たにデータを登録したり、登録されているデータを削除したりする。
　・・・（中略）・・・
図１３を用いてインターバル処理について説明する。インターバル処理はサーバ間で保持するメッセージを一致させるために必要な処理の一部と、サーバで保持するデータの量を削減するための定期的な処理である。
【００５１】まず有効期限切れのメッセージの削除を行なう（ステップＳ１３１）。有効期限切れメッセージ削除処理の詳細については図１４を用いて説明する。有効期限切れメッセージの削除は個々のメッセージ毎に有効期限切れか否かの判定を行なうのではなく、討論毎にその判定を行なう。すなわち、まず討論の有効期限の計算を行なう（ステップＳ１４１）。討論の有効期限は討論管理テーブルに記憶されている日時に対して、予め定められた日数を加算して得られる日時である。現在の日時がこうして得られた有効期限を超えている場合には、その討論全体のメッセージを削除する（ステップＳ１４２、Ｓ１４３）。個々のメッセージの削除については、図９を用いて説明した通りである。なお、予め定められた日数とは、あるサーバで登録されたメッセージが電子会議システムの全てのサーバに転送されるまでに要する日数や、登録されたメッセージを最低何日間削除せずに残しておくか等の運用上の条件によって定められる日数である。」
　
　上記Ｆの段落【００５１】の記載において、「有効期限切れメッセージの削除」にあたり、「有効期限切れか否かの判定」を「討論」毎に行うということは、「討論」という階層を、メッセージの削除を行うか否かを判定する階層として用いていることに他ならない。
　
　よって、上記Ａ〜Ｆの記載及び関連する図面を参照すると、引用例には、実質的に、次の発明が記載されているものと認められる。（以下、「引用例記載の発明」という。）
「複数のメッセージに関連付けられたメッセージを管理する電子会議システムにおいて、
　前記複数のメッセージを複数の階層で管理する手段と、
　前記複数のメッセージに対して、当該複数のメッセージの作成日時を示す日時データを付す日時記録手段と、
　前記複数の階層の内の削除判定に用いる階層で、前記日時データに基づきメッセージを検出し、当該検出されたメッセージに関連付けられたメッセージを削除する削除手段とを備える電子会議システム。」
　
（３）対比
　本願発明と引用例記載の発明とを対比すると、次のことがいえる。
　
（あ）引用例のものは、図２１に見られるように、親子関係を有する対応するメッセージ同士が関連付けられているものである。
　そして、引用例記載の発明における「メッセージ」は、「電子会議システム」が扱う「データ」である。
　よって、引用例記載の発明における「メッセージ」は、本願発明における「対応データ」及び「データ」に相当する。
　
（い）上記（あ）で述べたように、引用例記載の発明の「電子会議システム」は、「メッセージ」という「データ」を扱うものであり、「データ管理装置」と呼び得るものである。
　
（う）本願発明における「日時記録手段」によって付される「日時データ」は、複数の対応データの「作成日時」もしくは「参照日時」のどちらか一方を択一的に示すものである。
　そして、上記（あ）で述べたように、引用例記載の発明における「メッセージ」は、本願発明における「対応データ」及び「データ」に相当するから、本願発明と引用例記載の発明とは、「複数の対応データに対して、当該複数の対応データの作成日時を示す日時データを付す日時記録手段」を備える点において一致する。
　
　よって、上記（あ）〜（う）の事項を踏まえると、本願発明と引用例記載の発明とは、次の点で一致し、また、相違するものと認められる。
　
（一致点）
　本願発明と引用例記載の発明とは、ともに、
「複数の対応データに関連付けられたデータを管理するデータ管理装置において、
　前記複数の対応データを複数の階層で管理する手段と、
　前記複数の対応データに対して、当該複数の対応データの作成日時を示す日時データを付す日時記録手段と、
　前記複数の階層の内の削除判定に用いる階層で、前記日時データに基づき対応データを検出し、当該検出された対応データに関連付けられたデータを削除する削除手段とを備えるデータ管理装置。」
である点。
　
（相違点）
　相違点１：本願発明は、「階層構造で複数の対応データに関連付けられたデータを表示させる表示手段」を備えるのに対し、引用例のものは、引用例の上記Ｂに「利用者が登録されているメッセージの一覧情報等を表示する」との記載はあるものの、「階層構造」で表示させる表示手段を備えるとはされていない点。
　
　相違点２：本願発明は、「複数の階層の内、削除判定に用いる階層を設定する設定手段」を備えるのに対し、引用例のものは、「討論」という階層をメッセージの削除を行うか否かを判定する階層として用いているものの、上記のような「設定手段」を備えるとはされていない点。
　
（４）判断
　そこで、上記相違点１，２について検討する。
　
（相違点１について）
　引用例のものにおいて、「メッセージ」は「階層構造」で管理されているのであるから、引用例の上記Ｂの「利用者が登録されているメッセージの一覧情報等を表示する」との記載のように「メッセージの一覧」を表示させる場合に、「メッセージ」の「階層構造」すなわち親子関係がわかるような形式で表示させるようにすることは、当業者が適宜になし得ることにすぎない。
　よって、引用例記載の発明において、「階層構造で複数の対応データに関連付けられたデータを表示させる表示手段」を備えるようにすることは、当業者が適宜になし得ることである。
　
（相違点２について）
　引用例のものにおいては、「討論」という階層をメッセージの削除を行うか否かを判定する階層として用いることしか示されていない。
　しかしながら、ある一つのテーマの「討論」の下に、複数の関連する個別のテーマの討論を行うことは、ごく普通のことであるから、メッセージの削除を行うにあたり、「討論」全体を削除するように設定したり、「討論」の下のある一つの個別のテーマの討論を削除するように設定したりすることができるような「設定手段」を備えるようにすることは、当業者が必要に応じて適宜になし得ることにすぎない。
　よって、引用例記載の発明において、「複数の階層の内、削除判定に用いる階層を設定する設定手段」を備えるようにすることは、当業者が適宜になし得ることである。
　
（本願発明の作用効果について）
　そして、本願発明の構成によってもたらされる効果も、引用例記載の発明から当業者が容易に予測することができる程度のものであって、格別のものとはいえない。
　
（５）むすび
　以上のとおり、本願発明は、引用例記載の発明に基いて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　したがって、本願は、他の請求項について検討するまでもなく、拒絶されるべきものである。
　よって、結論のとおり審決する。