【事件の表示】
　平成１０年特許願第３６８２８０号「構造化文書作成方法、構造化文書作成装置及び構造化文書作成用プログラムを格納した記憶媒体」拒絶査定不服審判事件〔平成１１年１０月　８日出願公開、特開平１１−２７２６６７〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願は、平成１０年１２月２４日（パリ条約による優先権主張１９９７年１２月２３日、米国）の出願であって、平成１６年１１月１２日付けで拒絶理由通知がなされ、平成１７年１月１２日付けで手続補正がなされたが、平成１８年４月５日付けで拒絶査定がなされ、これに対し、同年５月１１日に拒絶査定不服審判の請求がなされるとともに、同年６月８日付けで手続補正がなされたものである。
　
２．平成１８年６月８日付けの手続補正についての補正却下の決定
［補正却下の決定の結論］
　平成１８年６月８日付けの手続補正を却下する。
　
［理由］
（１）補正の目的の適否について
　本件手続補正の目的が、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第４項の規定に適合するか否かを検討する。
　
　上記本件手続補正により、特許請求の範囲の請求項１は、
「ＳＧＭＬおよびＨＴＭＬを処理するコンピュータで実行可能な方法であって、
（ａ）ＳＧＭＬの変換用要素を選択する過程と、
（ｂ）前記ＳＧＭＬの要素に対応するＨＴＭＬの要素をユーザによって入力する過程と、
（ｃ）前記ＨＴＭＬを処理し、前記ＳＧＭＬの要素を対応する前記ＨＴＭＬの要素に変換するルールを作成する過程と、
（ｄ）前記ルールを出力する過程と、
を備える構造化文書作成方法であって、前記ルールは前記ＳＧＭＬに対応する前記ＨＴＭＬを割り当てないルールを含むことを特徴とする構造化文書作成方法。」
との記載から、
「ＳＧＭＬおよびＨＴＭＬを処理するコンピュータで実行可能な方法であって、
（ａ）ＳＧＭＬの変換用要素を選択する過程と、
（ｂ）前記ＳＧＭＬの要素に対応するＨＴＭＬの要素の入力を受け付ける過程と、
（ｃ）前記ＨＴＭＬの要素を処理し、前記ＳＧＭＬの要素を対応する前記ＨＴＭＬの要素に変換するルールを作成する過程と、
（ｄ）前記ルールを出力する過程と、
を備える構造化文書作成方法であって、
　前記ルールは、前記ＨＴＭＬの要素が前記ＳＧＭＬの要素に対応しない場合、前記ＳＧＭＬのタグを削除して前記ＳＧＭＬから前記ＨＴＭＬへの変換後の表示をしないようにする場合と、前記ＳＧＭＬのタグをマップしないようにすることで前記ＳＧＭＬから前記ＨＴＭＬへの変換後の表示を行うようにする場合とを選択可能である、
ことを特徴とする構造化文書作成方法。」
との記載に補正された。
　
　上記補正内容は、「（ｂ）前記ＳＧＭＬの要素に対応するＨＴＭＬの要素をユーザによって入力する過程」を「（ｂ）前記ＳＧＭＬの要素に対応するＨＴＭＬの要素の入力を受け付ける過程」に補正（以下、「補正１」という。）することと、「前記ルールは前記ＳＧＭＬに対応する前記ＨＴＭＬを割り当てないルールを含む」を「前記ルールは、前記ＨＴＭＬの要素が前記ＳＧＭＬの要素に対応しない場合、前記ＳＧＭＬのタグを削除して前記ＳＧＭＬから前記ＨＴＭＬへの変換後の表示をしないようにする場合と、前記ＳＧＭＬのタグをマップしないようにすることで前記ＳＧＭＬから前記ＨＴＭＬへの変換後の表示を行うようにする場合とを選択可能である」に補正（以下、「補正２」という。）することを含むものである。
　上記補正１については、「前記ＳＧＭＬの要素に対応するＨＴＭＬの要素」の入力を、補正前では「ユーザによって」行うとされていたものを、補正後においては、単に「受け付ける」とするものであって、特許請求の範囲を拡張するものであるから、特許請求の範囲の減縮に該当するとは認められない。
　また、上記補正２については、補正前の「前記ＳＧＭＬに対応する前記ＨＴＭＬを割り当てないルール」を補正後において限定するものではなく、「前記ＳＧＭＬのタグを削除して前記ＳＧＭＬから前記ＨＴＭＬへの変換後の表示をしないようにする場合」と「前記ＳＧＭＬのタグをマップしないようにすることで前記ＳＧＭＬから前記ＨＴＭＬへの変換後の表示を行うようにする場合」という二つの「表示」の態様を「選択可能」とするものであり、特許請求の範囲を変更するものであるから、特許請求の範囲の減縮に該当するとは認められない。
　よって、補正後の請求項１に記載された発明は、補正前の請求項１に記載された発明を特定するために必要な事項を限定して特許請求の範囲の減縮をしたものとは認められず、上記請求項１に係る補正は、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第４項第２号の規定に適合しない。
　
　さらに、特許請求の範囲の請求項２及び３についても、上記補正１及び補正２と同様の補正がなされており、補正後の請求項２及び３に記載された発明は、補正前の請求項２及び３に記載された発明を特定するために必要な事項を限定して特許請求の範囲の減縮をしたものとは認められず、請求項２及び３に係る補正は、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第４項第２号の規定に適合しない。
　
　また、特許請求の範囲の請求項１乃至３に係る補正が、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第４項第１号の請求項の削除、第３号の誤記の訂正、第４号の明りょうでない記載の釈明に該当するものでないことは明らかである。
　
（２）むすび
　よって、本件手続補正は、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第４項に違反するものであり、特許法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下されるべきものである。
　
３．補正却下の決定を踏まえた検討
（１）本願発明
　平成１８年６月８日付けの手続補正は、上記のとおり却下されたので、本願の請求項１に係る発明は、平成１７年１月１２日付け手続補正書の特許請求の範囲の請求項１に記載されたとおりの次のものと認める。（以下、「本願発明」という。）
「ＳＧＭＬおよびＨＴＭＬを処理するコンピュータで実行可能な方法であって、
（ａ）ＳＧＭＬの変換用要素を選択する過程と、
（ｂ）前記ＳＧＭＬの要素に対応するＨＴＭＬの要素をユーザによって入力する過程と、
（ｃ）前記ＨＴＭＬを処理し、前記ＳＧＭＬの要素を対応する前記ＨＴＭＬの要素に変換するルールを作成する過程と、
（ｄ）前記ルールを出力する過程と、
を備える構造化文書作成方法であって、前記ルールは前記ＳＧＭＬに対応する前記ＨＴＭＬを割り当てないルールを含むことを特徴とする構造化文書作成方法。」
　
（２）引用例及び周知例
　これに対して、原査定の拒絶の理由に引用された特開平９−２３１２２０号公報（以下、「引用例」という。）、及び原査定の備考欄において周知例として引用された特開平９−２６５４３１号公報（以下、「周知例」という。）には、それぞれ、図面とともに次の事項が記載されている。
　
（引用例）
Ａ．「【０００１】
【発明の属する技術分野】この発明は、元の文書から別の文書を変換して生成する方法、特に、文書の論理構造に注目して文書の変換、生成を行う方法に関する。」
　
Ｂ．「【０００９】
【課題を解決するための手段】
（１）本発明の文書変換生成方法は、文書の論理構造に注目して変換元文書を変換し、変換先文書を生成する方法であり、変換元文書を取得する変換元文書取得工程と、変換元文書をその論理構造を構成する要素に分解し、各要素に対応する実データを個別に保持する要素別実データ保持工程と、変換先文書の論理構造を取得する目的論理構造取得工程と、変換先文書の論理構造を維持しながら、その各要素に対し、前記変換元文書に含まれる要素の中で対応させるべきものの指定を受け付ける対応指定受付工程と、指定された対応に従い、前記変換先文書の要素ごとに前記変換元文書全体から必要な実データを一括して読み出し、これをその要素の実データとしてその要素の下に格納していく文書変換工程とを含む。
【００１０】この構成において、まず変換元文書が取得される。「文書」とは、文字データやイメージデータで構成されるものだけでなく、論理構造の記述が可能である限り、いかなる情報伝達単位を含んでよい。例えば文字にリンクされた音によって文書の一部を構成してもよい。変換元文書の「取得」とは、入力または作成された変換元文書をデータの形で持つことをいう。
【００１１】つづいて、変換元文書が要素に分解され、各要素に対応する実データが個別に保持される。前記領収書の例では、領収書文書を「金額」「内訳」等の要素に分類し、「金額」であれば「１０００円」などの実際の値をこの金額の実データとして保持する。
【００１２】一方、これと並行して変換先文書の論理構造も取得される。この論理構造を「目的論理構造」と呼ぶ。この後、目的論理構造を維持しながら、その各要素に対し、変換元文書に含まれる要素の中で対応させるべきものの指定が受け付けられる。「目的論理構造を維持しながら」とは「その論理構造を崩すことなく」の意味であり、変換先文書の論理構造を基礎として処理を進めることを意味する。より具体的には、変換の都合等によって、目的論理構造における要素の出現順序と要素の属する階層を変更しないことをいう。例えば、目的論理構造が「請求書」であり、この下に「請求の対象」と「請求金額」があるとき、「請求書」を最上位の階層１とすれば、その下の「請求の対象」と「請求金額」は階層２となる。出現順序は、「請求書」→「請求の対象」→「請求金額」である。従って、上述の領収書を変換元文書、この請求書を変換先文書とする場合、以下のように、目的論理構造をベースとして対応を指定する（これは対応の一例である）。
【００１３】１．出現順序１番の「請求書」に対して変換元文書の「領収書」
２．出現順序２番の「請求の対象」に対して変換元文書の「内訳」
３．出現順序３番の「請求金額」に対して変換元文書の「金額」
最後に、指定された対応に従い、変換先文書の要素ごとに前記変換元文書全体から必要な実データを一括して読み出し、これをその要素の実データとしてその要素の下に格納していく。例えば、要素「請求の対象」の場合、変換元文書の「内訳」という要素が持つすべての実データを拾い出し、これを「請求の対象」の下に格納する。これにより、例えば「今月納品分」という文字列データが変換先文書に移動または複写される。この処理は目的論理構造を維持しながら行われるため、最終的に得られる文書は、
（階層１）「請求書」とその実データ
（階層２）「請求の対象」とその実データ
（階層２）「請求金額」とその実データ
となる。この結果、所期の変換が実現する。」
　
Ｃ．「【００１９】（４）本発明のある態様では、前記対応指定受付工程はさらに、変換先文書の要素の属性に対し、前記変換元文書に含まれる要素の属性中で対応させるべきものの指定を受け付け、前記文書変換工程はさらに、指定された対応に従い、前記変換先文書の要素の属性に対して前記変換元文書の要素の属性を付与していく。」
　
Ｄ．「【００２３】（７）一方、本発明のある態様では、前記対応指定受付工程はグラフィカルユーザインタフェイス（以下ＧＵＩ）によって前記指定を受け付けるものであり、該工程は、変換元文書の論理構造と変換先文書の論理構造をならべて表示する工程と、これら２つの論理構造からそれぞれ１つの要素が指定されたとき、これらの要素間に設定すべき対応の詳細設定画面を表示する工程と、前記詳細設定画面における設定作業が終了したとき、その詳細設定内容を取り込んで変換指定ファイルを生成する工程を含む。
【００２４】この態様では、まず変換元文書、変換先文書それぞれの論理構造が画面に現れる。論理構造は木構造などで表示すればよい。この画面を見ることにより、対応付けるべき要素が容易に把握される。つぎに、これら２つの論理構造からそれぞれ１つの要素が指定される。これは、少なくとも１つずつの要素が指定されれば足りる意味であり、実際には合計で３以上の要素を指定してもよい。いずれにせよ、この時点で、これらの要素に対応付けがなされることが確定する。
【００２５】ここで、これらの要素間に設定すべき対応の詳細設定画面が表示される。詳細設定とは、前述の論理演算を条件とする場合の条件式の設定などをいう。詳細設定画面における設定作業が終了すれば、その内容を取り込んだ変換指定ファイルが生成される。このファイルは、対応関係と条件などが記述されているだけであり、プログラムを記述してなるものではない。この後、このファイルを逐次読み出し、その詳細設定に従って前記実データの読み出しと格納を実行する。このファイルを一回作成すれば、変換元文書、変換先文書それぞれの論理構造が同じ場合にはいつでもこのファイルを利用することができる。」
　
Ｅ．「【００２６】
【発明の実施の形態】本発明の好適な実施形態を適宜図面を参照しながら説明する。ここでは文書としてＳＧＭＬ文書、その論理構造である文書型定義としてＤＴＤを例に本発明の実施形態を説明する。
【００２７】
実施形態１．
【００２８】［１］変換元文書
図１は変換元文書のＤＴＤ（以下「変換元ＤＴＤ」ともいう）を示す図である。同図において、ＥＬＥＭＥＮＴは各要素名を、またＡＴＴＬＩＳＴは属性とその属性値を表示する。同図第１行のごとく、このＤＴＤでは「報告書１」の後に、（日付，作成者，本文，付録，関連部署）と表記されている。これは「報告書１」という最上位要素のもとに日付等の要素が従属し、これらの要素が必ず左から順に現れることを示す。「付録」に付される？記号は、その要素が０または１回に限って現れることを示す。
【００２９】第２行では「報告書１」の属性として「秘区分」が４つの属性値、極秘、秘、社外秘、指定なしを伴う形で定義されている。これら４つの区分の間に存在する縦線はいずれか１つを選択するオア記号であり、行末の＃ＲＥＱＵＩＲＥＤはその選択行為が必須であることを示す。第３行の「日付」の後の＃ＰＣＤＡＴＡは、実際に文字列データが入力される部分を示す。第５行の「本文」には「段落」と「リスト」が従属しており、＋記号は段落が１回以上、＊記号はリストが０回以上出現することを示す。リストとはいわゆる箇条書き形式の表示で、第７行に示すとおり、リストが存在するときは必ず実体である「項目」が１回以上現れる。第５行でも縦線はオア記号であり、まず（段落＋｜リスト＊）は、次の出現状況を満たす。
【００３０】「段落とリストはいずれか一方が出現する。ただし、段落は１回以上、リストは０回以上出現」実際にはこの（）の外にさらに＋がついているため、この状況自体が１回以上出現する。結果的に段落とリストは、段落が１回以上出現することを前提として、順不同で任意の回数出現しうる。
【００３１】一方、図２は図１のＤＴＤを木構造で表した図である。木構造では、いずれか一方が出現する「段落」と「リスト」は「本文」に斜線で結線され、それ以外の要素は必ず左から順に現れる。ここでは、「報告書１」が階層１、「日付」などが階層２などとなり、最下位は「項目」の階層４である。要素の下に存在する「Ｐ」という記号は、＃ＰＣＤＡＴＡを示している。
【００３２】図３は図１のＤＴＤに従う変換元文書、すなわち変換元のＳＧＭＬ文書を示す図である。＜＞はＳＧＭＬの規則に従って付けられるマークで、＜ｘｘｘ＞がｘｘｘという要素の開始タグ、＜／ｘｘｘ＞が終了タグを示す。＜ｘｘｘ＞と＜／ｘｘｘ＞の間にｘｘｘの実データが記述されるか、ｘｘｘに子要素があればこれを入れ子構造で記述する。同図では、＜段落＞の実データとして文字列ＡＡＡ、ＢＢＢ、ＥＥＥ、＜リスト＞＜項目＞の実データとして文字列ＣＣＣ、ＤＤＤが存在する。
【００３３】［２］変換先文書
一方、図４は目的論理構造である変換先文書のＤＴＤ（以下「変換先ＤＴＤ」ともいう）を示す図である。同図第１、２行からわかるように、この報告書２は「前付け」「本文」「後付け」からなり、「前付け」が子要素として「日付」「送付先」「著者」を持つ。この部分ですでに図１のＤＴＤと構造が違う。同図最終３行の「後付け」「付録」「参考文献」についても同様である。図５は図４のＤＴＤを木構造で表した図であり、図２との構造の相違を容易に把握することができる。
【００３４】図６は変換の結果最終的に得られる変換先文書を示す図で、本実施形態の目的は図３のＳＧＭＬ文書を変換して図６のＳＧＭＬ文書を生成することにある。なお、ＳＧＭＬの記述方法については、例えば「ＳＧＭＬのかきかた」（１９９４年１２月発行所（株）麻布プロデュース）などに掲載されている。
【００３５】［３］構成
図７は本実施形態を実現するためのシステム構成図である。同図において円筒形はデータを保持する構成、一方矩形は実際に処理を行うソフトウエアモジュールを表している。本実施形態を実現するためのハードウエアは、例えばパーソナルコンピュータ（以下ＰＣ）とデータを格納するファイル装置、変換結果を確認するためのプリンタなどでよく、特別な装置を必要としない。以下、本実施形態の処理はこのＰＣ上で行うものとする。」
　
Ｆ．「【００４０】［４］処理動作
図３の文書から図６の文書を変換生成する一連の処理を図７をもとに説明する。
【００４１】まずユーザは、変換元文書を文書データ保持部１から検索する。検索は、例えば「報告書」などの文書の類型タイトルや、作成時期、作成者、文書に含まれる特定のキーワード等をもとに行う。変換元文書が見つかればこれをＰＣのメモリに格納し、その変換元ＤＴＤを文書構造保持部２から読み出して同様にメモリに格納する。
【００４２】つづいて、変換元文書と変換元ＤＴＤを入力ファイルとして文書構造パーサ３を起動する。文書構造パーサ３では、図３の変換元文書を先頭から読み取り、記述のいずれの部分が要素名、属性、属性値、実データ（文字列データ）であるかを、ＤＴＤに照合しながら判断し、これらに異なる記号を付して出力していく。この処理を変換先文書のすべての行が終了するまで繰り返し行う。パーサの出力は解析済みデータ保持部４に格納される。
【００４３】図８は文書構造パーサ３による解析の結果得られた解析済みデータを示す図である。データの出力形式はパーサの種類によりさまざまであるが、ここではＥＳＩＳという形式で出力している。同図のおいて、「（」はタグの開始、「）」はタグの終了、「Ａ」につづく文字は属性、「ＴＯＫＥＮ」につづく文字はその属性に関する属性値、「−」に導かれる文字列が実データを示している。
【００４４】要素別分類処理部５は解析済みデータ保持部４から解析済みデータを読み出し、要素別実データと要素情報を抽出する。前者は図８のデータを行ごとに走査し、「−」に導かれる文字列を抽出することで得られる。図９は要素別実データを示す図であり、ここでは抽出された実データに対し、出現した順にデータ１〜９のヘッダ情報を付加している。一方、要素情報についても同様に、図８のデータを行ごとに走査し、先頭の記号が「（」「）」であればその向きに従って階層の深度を判断し、各要素の階層と親子関係に関する情報を取得していく。図１０はこうして得られた要素情報を示す図であり、要素名、親要素名、さらに親があればその名称といった親子関係とその属性情報、および当該要素の実データの格納先情報を持つ。格納先情報は、要素情報を抽出する際に、「−」の出現回数を計数することによって取得することができる。こうして得られた要素情報と要素別実データは、それぞれ要素情報保持部７、要素別実データ保持部６に格納される。
【００４５】構造変換処理部８は、要素情報、要素別実データ、変換指定ファイルを参照して変換処理を行う。図１１は作成された変換指定ファイルの例、図１２は作成途上の変換指定ファイルの状態をそれぞれ示す図である。変換指定ファイルは変換先ＤＴＤをベースにユーザによって作成されるもので、作成の手順は以下のとおりである。なお、変換先ＤＴＤ自身は、すでに文書構造保持部２に存在するときはこれを読み出して用い、存在しないときは別途作成する。
【００４６】（１）要素名とその階層の書き出し
図２の木構造から図１２の状態を作成する。これは単に、要素名をその階層とともに表示していくことで得られる。例えば「報告書２」は階層１であるため、これを、（１　　報告書２
と記述する。階層１の要素は他にないため階層２に移り、木構造の記述規則どおり、左から順に同様の処理を行う。「前付け」は子要素を持つため、まず「日付」等の子要素を書き出した上で、次の「本文」に移行する。以下同様である。
【００４７】（２）要素間の対応付け
実際の変換処理に用いるべき対応付けの指定を行う。例えば、変換元ＤＴＤの要素Ｓと変換先ＤＴＤの要素Ｔとの間で対応付けがなされた場合、構造変換処理部８において、要素Ｓの実データが要素Ｔの実データとして付与されることになる。対応付けのためにユーザは、図２および図５のＤＴＤを見比べることにより、要素間の対応を見い出す。図１３はユーザが図２および図５のＤＴＤ間に指定しようと考える対応関係を示す図である。これを、
変換先ＤＴＤの要素←変換元ＤＴＤの要素
の順で表現すれば、ユーザは以下の対応付けを行う。
【００４８】
１．日付　←　日付
２．送付先　←　関連部署
３．著者　←　作成者
４．本文の段落　←　本文の段落
５．本文のリストの項目　←　本文のリストの項目
６．付録の段落　←　付録
いま、すでに図１２の状態でこれらの対応のうち左側の要素が表示されているので、右側の要素を図１２の対応要素に組み込んでいけばよい。組み込みの際、同じ要素名（例えば段落）が２回以上存在しうるため、最上位階層から／を用いて階層を明示しながら要素名を書き込む。例えば、６．の場合、図１２の下から２行目の
（４　　段落
の個所に、
＜報告書１／付録
と書き込めばよい。ここで「＜」は、実データを読んで取り込む指示記号である。この対応付けを１〜６に対して行う。つづいて変換先ＤＴＤの要素のうち、要素群を指定する。ここでは「本文」の中の「段落」「リスト」「項目」がそれに当たるため、図１１において、
（３．　段落
：
（４．　項目
というように、「．」をつけて要素群の範囲を明示する。なお、図１１の最下行の”学会予稿集”は、変換元ＤＴＤに対応する要素がないため、別途キーボードから入力した文字列である。」
　
Ｇ．「【００５７】１．ＳＧＭＬ以外への応用
本実施形態ではＳＧＭＬ文書と文書型定義ＤＴＤについて説明した。しかし、論理構造を持つ文書であれば、これら以外のいかなる文書およびその論理構造の組合せに対しても本実施形態は容易に適用可能である。」
　
Ｈ．「【００６３】
実施形態２．
【００６４】［１］構成
このＧＵＩを実現するために本実施形態は、おもに以下のプログラムモジュールを持つ。
【００６５】（１）変換元ＤＴＤと変換先ＤＴＤを木構造に変換するモジュール
（２）これらの木構造をＰＣの画面にならべて表示するモジュール
（３）これらの木構造からそれぞれ１つの要素がクリックされたとき、これをアクションとして受け取るモジュール
（４）このアクションを解釈し、これらの要素間に設定すべき対応の詳細設定画面を表示するモジュール
（５）この詳細設定画面における設定作業が終了したとき、その詳細設定内容を取り込んで変換指定ファイルを生成するモジュール
［２］処理動作
図１６、１７は処理中の特定場面で画面に表示されるＧＵＩを示す図である。処理の流れは以下のとおりである。
【００６６】（１）木構造の表示
ユーザが変換元ＤＴＤと変換先ＤＴＤを決定したとき、これらの木構造が画面に表示される。これは図２、図５の木構造が同一画面に表示されると考えればよい。この状態でＰＣはユーザによる要素の選択待ち状態になる。
【００６７】（２）詳細設定画面の表示
ユーザが図２の「報告書１」と図５の「報告書２」をクリックすると、それぞれ図１６、１７に示す表示が画面に現れる。図１６の要素名１００には「報告書１」、属性名１０１には「秘区分」が表示され、属性値１０２には「極秘」「秘」「社外秘」が選択可能な状態で表示される。一方、図１７の要素名２００には「報告書２」、属性名２０１には「タイプ」が表示され、属性値２０２には「部内」「社内」「指定なし」が選択可能な状態で表示される。さらに同図には、条件の組合せを記述するための論理和ボタン２０３、論理積ボタン２０４、１つの条件の入力の終了を示す終了ボタン２０５、設定中の条件を逐次表示する条件表示欄２０６、設定をキャンセルするキャンセルボタン２０７、設定を登録する登録ボタン２０８が設けられている。
【００６８】この画面において、まず図１７の「部内」をクリックし、つづいて図１６の「極秘」、図１７の「論理和」、図１６の「秘」、終了ボタン２０５の順にクリックする。この時点で図１１の第２行、
［報告書１］秘区分＝極秘｜［報告書１］秘区分＝秘＞［報告書２］タイプ＝部内
が設定される。つぎに図１７の「社内」を選択し、同様の手順で、
［報告書１］秘区分＝社外秘＞［報告書２］タイプ＝社内
が設定される。以下同様で、最終的に登録ボタン２０８を押したとき、設定内容を読み出し、変換指定ファイルが生成される。なお、属性値が１つのみ存在する場合は属性値１０２、２０２の欄にはその属性値のみが表示され、例えば、
［報告書１］属性値＝［報告書２］属性値
という形の変換指定が可能となる。
【００６９】つづいて、実データの対応指示に移る。まず図２と図５の「日付」をそれぞれクリックする。このとき図１０の要素情報における親子関係が参照され、階層経路が明らかになるため、図１１の、
（３    日付    ＜  報告書１／日付
が生成される。以下、同様である。
【００７０】以上本実施形態によれば、変換指定ファイルの作成がさらに容易になるため、ユーザの便宜を図ることができる。」
　
　上記Ａ〜Ｈの記載及び関連する図面を参照すると、次のことがいえる。
　
（あ）上記Ｅの段落【００２６】に「・・・ここでは文書としてＳＧＭＬ文書、その論理構造である文書型定義としてＤＴＤを例に本発明の実施形態を説明する。」と記載され、また、段落【００３５】に「・・・本実施形態を実現するためのハードウエアは、例えばパーソナルコンピュータ（以下ＰＣ）とデータを格納するファイル装置、変換結果を確認するためのプリンタなどでよく、特別な装置を必要としない。以下、本実施形態の処理はこのＰＣ上で行うものとする。」と記載されていることから、上記引用例に記載のものは、「ＳＧＭＬを処理するコンピュータで実行可能な方法」に係るものであるということができる。
　
（い）上記Ｄの段落【００２３】の「一方、本発明のある態様では、前記対応指定受付工程はグラフィカルユーザインタフェイス（以下ＧＵＩ）によって前記指定を受け付けるものであり、該工程は、変換元文書の論理構造と変換先文書の論理構造をならべて表示する工程と、これら２つの論理構造からそれぞれ１つの要素が指定されたとき、これらの要素間に設定すべき対応の詳細設定画面を表示する工程と、前記詳細設定画面における設定作業が終了したとき、その詳細設定内容を取り込んで変換指定ファイルを生成する工程を含む。」との記載、及び上記Ｈに記載の「変換指定ファイル作成用のＧＵＩを利用する」実施形態を参照すると、上記引用例に記載のものは、「ＳＧＭＬの変換元ＤＴＤの要素に対応する変換先ＤＴＤの要素をユーザによって入力する過程」を備えるものであるということができる。
　
（う）上記Ｆの段落【００４６】〜【００４８】の記載や上記Ｈの段落【００６４】〜【００６９】に見られる「変換指定ファイル」の作成手順を参照すると、上記「変換指定ファイル」は、ＳＧＭＬの変換元ＤＴＤの要素と変換先ＤＴＤの要素の対応付けを行いつつ作成されるものであり、その対応付けの過程で、当然、ＳＧＭＬの変換元ＤＴＤと変換先ＤＴＤの要素の処理、すなわち「ＳＧＭＬの処理」が行われるものであるということができる。。
　よって、上記引用例に記載のものは、「ＳＧＭＬを処理し、前記ＳＧＭＬの変換元ＤＴＤの要素を対応する変換先ＤＴＤの要素に変換する変換指定ファイルを作成する過程」を備えるものであるということができる。
　
（え）上記Ｄの段落【００２５】に「・・・その内容を取り込んだ変換指定ファイルが生成される。・・・この後、このファイルを逐次読み出し、その詳細設定に従って前記実データの読み出しと格納を実行する。・・・」と記載されており、上記引用例に記載のものは、「変換指定ファイルを読み出す過程」を備えるものであるということができる。
　
（お）「ＳＧＭＬ文書」は「構造化文書」の一種であり、上記引用例に記載のものは、「構造化文書作成方法」に係るものであるということができる。
　
　上記（あ）〜（お）の事項を踏まえると、引用例には、実質的に次の発明が記載されているものと認められる。（以下、「引用例記載の発明」という。）
「ＳＧＭＬを処理するコンピュータで実行可能な方法であって、
（ａ）ＳＧＭＬの変換元ＤＴＤの変換用要素を選択する過程と、
（ｂ）前記ＳＧＭＬの変換元ＤＴＤの要素に対応する変換先ＤＴＤの要素をユーザによって入力する過程と、
（ｃ）前記ＳＧＭＬを処理し、前記ＳＧＭＬの変換元ＤＴＤの要素を対応する前記変換先ＤＴＤの要素に変換する変換指定ファイルを作成する過程と、
（ｄ）前記変換指定ファイルを読み出す過程と、
を備える構造化文書作成方法。」
　
（周知例）
Ｉ．「【０００１】
【発明の属する技術分野】本発明は、ドキュメントの編集方法に係わり、特に、ＷＷＷ（ワールドワイドウェブ）サーバでグラフィカルな画面を表現するページ記述言語ＨＴＭＬ（ハイパーテキストマークアップランゲージ）で記述されたドキュメントを得るため電子文書標準化のための汎用マークアップ言語ＳＧＭＬ（スタンダードジェネライズドマークアップランゲージ）で記述されたドキュメントを編集する方法に関する。」
　
Ｊ．「【００１４】
【実施例】図４は、本発明の他の実施例のＷＷＷシステムの構成図である。同図において、ドキュメント編集クライアント装置３０と、サーバ装置４０と、ＷＷＷブラウザ装置５２は、例えば、ＬＡＮのようなネットワーク５０によって接続されている。
【００１５】サーバ装置４０のＷＷＷサーバ部４２は、ＷＷＷサーバプログラムにより構成され、ファイルシステム４４内のデータをネットワーク５０に向けて公開している。ドキュメント編集クライアント装置３０は、本発明によるドキュメント編集装置からなり、ＷＷＷのホームページのドキュメントと、ＷＷＷのホームページへのリンク情報を表わすドキュメントを作成、編集し、ＨＴＭＬ形式で記述されたドキュメントをネットワーク５０と、サーバ装置４０のＷＷＷサーバ部４２とを介してサーバ装置４０のファイルシステム４４に登録する。
【００１６】ＷＷＷブラウザ装置５２は、ネットワーク５０と、サーバ装置４０のＷＷＷサーバ部４２とを介して、サーバ装置４０のファイルシステムに登録されているＷＷＷのホームページ及びそのリンク情報を参照、ダウンロードする。上記例の場合に、ドキュメント編集クライアント装置３０においてＳＧＭＬ形式のドキュメントを編集し、ＳＧＭＬ形式のドキュメントをＨＴＭＬ形式のドキュメントに変換し、ＷＷＷのホームページのドキュメントとしてサーバ装置４０のファイルシステム４４に登録する処理を以下に説明する。
【００１７】図４に示す如く、ドキュメント編集クライアント装置３０は、ネットワークインタフェース部（或いは、ネットワークシステム）２４を有し、サーバ装置４０のファイルシステム４４をドキュメント編集クライアント装置３０に接続する。変換ルール格納部１２には、例えば、ＣＲＴと、キーボードと、マウスと、スピーカー（図示しない）とによって構成されたユーザインタフェース部２０を介して変換定義部１４で作成された変換ルールが変換定義ファイルの形で格納されている。図５は、かかる変換定義ファイルの一例を示す図である。例えば、変換定義部１４は、通常のテキストエディタによって構成することができる。
　・・・（中略）・・・
【００２２】変換定義ファイルは、好ましくは、ユーザが予め用途別に作成して変換ルール格納部１２に格納される。ＳＧＭＬの定義の変更、又は、出力すべきＨＴＭＬのレイアウト変更等の要求に応じて、ユーザは、ユーザインタフェース部２０及び変換定義部１４を介して変換ルール格納部１２に格納された変換定義ファイルを修正し、或いは、別途新しい変換定義ファイルを作成する。
【００２３】変換処理部１６は、更に、上記のようにして変換すべきＳＧＭＬファイルが指定されると、ドキュメント格納部２２から変換元のＳＧＭＬファイル、即ち、第１のドキュメントを読み出す。以下では、上記図６に示したＳＧＭＬ形式のドキュメントのファイルが指定された場合を想定する。
【００２４】以下、図６のＳＧＭＬ形式の第１のドキュメントを、図５に示した変換定義ファイルに従ってＨＴＭＬ形式の第２のドキュメントに変換し、第２のドキュメントをサーバ装置４０のファイルシステム４４に登録するドキュメント編集クライアント装置３０の変換処理動作を図８のフローチャートを参照して説明するドキュメント編集クライアント装置３０の変換処理部３０は、必要に応じてユーザから起動される（ステップ３０）。変換処理部３０は、ユーザインタフェース部２０を介して図７に示した画面を表示し（ステップ３２）、ユーザからの変換定義ファイルとＳＧＭＬファイル（“ＳＡＭＰＬＥ２．ＳＧＭＬ”）の指定を受ける（ステップ３４）。
【００２５】利用者が開始ボタンをクリックすると、変換処理部３０は、図５の変換定義ファイルをオープンし、分析処理を開始する。即ち、変換定義ファイルの〔ＷＷＷＨＯＭＥ〕セクションから出力すべきドライブを、〔ＨＴＭＬ〕セクションからリンク情報を、〔ＩＮＤＥＸ〕セクションから書込み情報を取得する（ステップ３６）。次いで、変換処理部３０は、〔ＣＯＮＶＥＲＴ〕セクションから変換のための命令を順次取込み、内部バッファ（図示せず）に格納する（ステップ３８）。
【００２６】次に、変換処理部３０は、変換定義ファイルをクローズすると共に、ＳＧＭＬファイルをオープンし（ステップ４０）、上記内部バッファに格納された命令を順次に読み出し（ステップ４２）、命令がＣＮＶ命令であるかどうかを比較し（ステップ４４）、ＣＮＶ命令であれば、ＣＮＶ命令の第１引き数を第２引き数に置換する（ステップ４６）。図５の変換定義ファイルの１行目のＣＮＶ命令の場合、＜名称＞が＜ＴＩＴＬＥ＞に置換される。命令がＩＮＳ命令である場合、ＩＮＳ命令の引き数の情報が挿入される。図５の変換定義ファイルの２行目のＩＮＳ命令の場合、「＜ＣＥＮＴＥＲ＞本製品に関するデータ＜／ＣＥＮＴＥＲ＞」が挿入される。以下同様にして、内部バッファ中の命令が無くなるまでステップ４２からステップ５０までを繰り返す。
【００２７】全ての命令の処理が終了すると、ＳＧＭＬファイルはＨＴＭＬファイルに変換され、ＳＧＭＬファイルがクローズされ、かつ、出力処理部１８においてＨＴＭＬファイル名（“ＳＡＭＰＬＥ２．ＨＴＭＬ”）が自動的に作成される（ステップ５２）。図９は、上記変換処理によって得られたＨＴＭＬ形式のドキュメントのファイルを示す図である。
【００２８】出力処理部１８は、ネットワークインタフェース部２４を介して上記〔ｐａｔｈ〕セクションから得られたディレクトリに上記得られたＨＴＭＬファイルを出力すると同時に、上記サーバ装置４４のファイルシステム４４からホームページファイルを読み込み、作成したＨＴＭＬファイル（“ＳＡＭＰＬＥ２．ＨＴＭＬ”）へのリンク情報を追加した後、ファイルシステム４４にもう一度設定する。図１０は変換前のリンク先が指定されたＨＴＭＬホームページファイルの例を示す図であり、図１１は変換後のリンク先が指定されたＨＴＭＬホームページファイルの例を示す図である。
【００２９】以上の動作により、ユーザは、簡単な操作だけでＳＧＭＬ形式のドキュメントをＨＴＭＬ形式のドキュメントに変換し、かつ、ＷＷＷサーバのファイルシステムに登録すると共に、リンク情報を同時に更新することが可能になる。図１２は本発明の他の実施例によるドキュメント編集装置の構成図である。図１２のドキュメント編集装置と、図２のドキュメント編集装置との相違点は、以下の通りである。図１２のドキュメント編集装置１０は、変換ルールを作成する変換定義手段１４が省かれている。更に、図１２のドキュメント編集装置１０において、図２の変換処理部１６は、変換定義ファイル１２を読み込み、分析した結果を内部バッファ１９に設定する分析処理部１５と、ドキュメント２２を読み込み、内部バッファに設定された分析結果を順次ドキュメントに適用する編集処理部１７とに分割されている。
【００３０】上記説明では、ＳＧＭＬ形式のドキュメントをＨＴＭＬ形式のドキュメントに変換する場合を例として説明したが、変換定義ファイルの内容を変更するだけで、ＳＧＭＬ形式からＳＧＭＬ形式のドキュメントへの変換の場合の同様に編集することができる。」
　
　上記Ｉ，Ｊの記載及び関連する図面を参照すると、次の技術が周知であるということができる。（以下、「周知技術」という。）
「ドキュメントの形式をＳＧＭＬ形式からＨＴＭＬ形式へと変換する変換ルールを作成して変換定義ファイルの形で変換ルール格納部に格納し、該格納された変換定義ファイルに基いて、ＳＧＭＬ形式のドキュメントをＨＴＭＬ形式のドキュメントに変換すること。」
　
（３）対比
　本願発明と引用例記載の発明とを対比すると、次のことがいえる。
　
（ア）「ＳＧＭＬ」形式の文書も「ＨＴＭＬ」形式の文書も、ともに「構造化文書」であることには変わりなく、本願発明と引用例記載の発明とは、ともに、「構造化文書を処理するコンピュータで実行可能な方法」に係るものである点で共通する。
　
（イ）引用例記載の発明における「ＳＧＭＬの変換元ＤＴＤの変換用要素を選択する過程」と、本願発明における「ＳＧＭＬの変換用要素を選択する過程」とは、「ＳＧＭＬからなる変換元構造化文書の変換用要素を選択する過程」である点で一致するものである。
　
（ウ）同様に、引用例記載の発明における「ＳＧＭＬの変換元ＤＴＤの要素に対応する変換先ＤＴＤの要素をユーザによって入力する過程」と、本願発明における「ＳＧＭＬの要素に対応するＨＴＭＬの要素をユーザによって入力する過程」とは、「変換元構造化文書の要素に対応する変換先構造化文書の要素をユーザによって入力する過程」である点で共通する。
　
（エ）引用例記載の発明における「変換指定ファイル」は、引用例の上記Ｄの段落【００２５】に「・・・対応関係と条件などが記述されている・・・」と記載されているように、「変換元構造化文書の要素」を対応する「変換先構造化文書の要素」に変換する「ルール」を記述するものであるであるということができる。
　よって、本願発明と引用例記載の発明とは、「変換元構造化文書の要素を対応する変換先構造化文書の要素に変換するルールを作成する過程」を備える点で共通するということができる。
　
（オ）引用例記載の発明における「変換指定ファイルを読み出す過程」は、本願発明における「ルールを出力する過程」に相当する。
　
　上記（ア）〜（オ）の事項を踏まえると、本願発明と引用例記載の発明とは、次の点で一致し、また、相違するものと認められる。
　
（一致点）
　本願発明と引用例記載の発明とは、ともに、
「構造化文書を処理するコンピュータで実行可能な方法であって、
（ａ）ＳＧＭＬからなる変換元構造化文書の変換用要素を選択する過程と、
（ｂ）前記変換元構造化文書の要素に対応する変換先構造化文書の要素をユーザによって入力する過程と、
（ｃ）前記変換元構造化文書の要素を対応する変換先構造化文書の要素に変換するルールを作成する過程と、
（ｄ）前記ルールを出力する過程と、
を備える構造化文書作成方法。」
である点。
　
（相違点）
　相違点１：本願発明は、「ＳＧＭＬおよびＨＴＭＬを処理するコンピュータで実行可能な方法」に係るものであって、「（ｂ）変換元構造化文書の要素に対応する変換先構造化文書の要素をユーザによって入力する過程」及び「（ｃ）変換元構造化文書の要素を対応する変換先構造化文書の要素に変換するルールを作成する過程」が、「（ｂ）ＳＧＭＬの要素に対応するＨＴＭＬの要素をユーザによって入力する過程」及び「（ｃ）ＨＴＭＬを処理し、ＳＧＭＬの要素を対応するＨＴＭＬの要素に変換するルールを作成する過程」であるのに対し、引用例記載の発明は、「ＳＧＭＬを処理するコンピュータで実行可能な方法」に係るものであって、上記（ｂ）及び（ｃ）の過程が、「（ｂ）ＳＧＭＬの変換元ＤＴＤの要素に対応する変換先ＤＴＤの要素をユーザによって入力する過程」及び「（ｃ）ＳＧＭＬを処理し、ＳＧＭＬの変換元ＤＴＤの要素を対応する変換先ＤＴＤの要素に変換する変換指定ファイルを作成する過程」である点。
　
　相違点２：「ルール」が、本願発明においては、「ＳＧＭＬに対応するＨＴＭＬを割り当てないルールを含む」ものであるのに対し、引用例記載の発明においては、ＳＧＭＬの変換元ＤＴＤの要素に対応する変換先ＤＴＤの要素を割り当てないルールを含むとはされていない点。
　
（４）判断
　そこで、上記相違点１及び２について検討する。
　
（相違点１について）
　引用例の上記Ｇの記載によれば、引用例記載の発明は、ＳＧＭＬ文書以外のいかなる文書およびその論理構造の組合せに対しても容易に適用可能であるとされ、実際に、上記周知技術に見られるように、ＳＧＭＬ形式の構造化文書を、作成した変換ルールに基いてＨＴＭＬ形式の構造化文書に変換する技術は周知である。
　そして、ＳＧＭＬ形式からＨＴＭＬ形式へ変換する変換ルールを作成する過程で、ＳＧＭＬおよびＨＴＭＬの処理が行われることは、当然のことである。
　してみれば、引用例記載の発明において、上記周知技術を参酌することにより、引用例記載の発明を「ＳＧＭＬおよびＨＴＭＬを処理するコンピュータで実行可能な方法」に係るものとし、「（ｂ）変換元構造化文書の要素に対応する変換先構造化文書の要素をユーザによって入力する過程」及び「（ｃ）変換元構造化文書の要素を対応する変換先構造化文書の要素に変換するルールを作成する過程」を、「（ｂ）ＳＧＭＬの要素に対応するＨＴＭＬの要素をユーザによって入力する過程」及び「（ｃ）ＨＴＭＬを処理し、ＳＧＭＬの要素を対応するＨＴＭＬの要素に変換するルールを作成する過程」とすることは、当業者が容易に想到し得ることである。
　
（相違点２について）
　引用例の上記Ｆの段落【００４８】には、「・・・なお、図１１の最下行の”学会予稿集”は、変換元ＤＴＤに対応する要素がないため、別途キーボードから入力した文字列である。」との記載がなされている。
　すなわち、上記記載によれば、変換先ＤＴＤに存在する要素であっても、変換元ＤＴＤには対応する要素がない場合には、変換元ＤＴＤに新たな要素を付け加えて変換先ＤＴＤの要素とするとされている。
　してみれば、逆に、変換元ＤＴＤに存在する要素であっても、変換先ＤＴＤには対応する要素がない場合に、該当する変換元ＤＴＤの要素を変換先ＤＴＤに割り当てないようにすることは、当業者が容易に想到し得ることである。
　そして、上記周知技術を参酌すれば、ＳＧＭＬ形式の構造化文書に存在する要素であっても、ＨＴＭＬ形式の構造化文書には対応する要素がない場合に、該当するＳＧＭＬ形式の構造化文書の要素をＨＴＭＬ形式の構造化文書に割り当てないようにすることは、当業者が容易に想到し得ることである。
　よって、「ルール」を「ＳＧＭＬに対応するＨＴＭＬを割り当てないルールを含む」ものとすることは、当業者が容易に想到し得ることである。
　
　そして、本願発明の構成によってもたらされる効果も、引用例記載の発明及び上記周知技術から当業者ならば容易に予測することができる程度のものであって、格別のものとはいえない。
　
（５）むすび
　以上のとおり、本願発明は、引用例記載の発明及び上記周知技術に基いて、当業者が容易に発明をすることができたものであるので、特許法第２９条第２項の規定により特許を受けることができない。
　したがって、本願は、他の請求項について検討するまでもなく、拒絶されるべきものである。
　よって、結論のとおり審決する。