【事件の表示】
　特願２００２−１９３８５１「ＸＭＬ文書作成システム」拒絶査定不服審判事件〔平成１６年　２月　５日出願公開、特開２００４−　３８４９６〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
　
１．手続の経緯  
　
　本願は、平成１４年７月２日の出願であって、平成１９年７月２３日付けで拒絶査定がなされ、これに対し、平成１９年８月３０日に拒絶査定不服審判の請求がなされるとともに、平成１９年１０月１日付けで手続補正がなされたものである。
　
　
　
２．本願発明
　
　本願の請求項１乃至５に係る発明は、平成１９年１０月１日付けの手続補正書によって補正された明細書及び図面の記載からみて、（後述する誤記を除き）特許請求の範囲の請求項１乃至５に記載されたとおりのものと認められるところ、その請求項１に係る発明（以下、「本願発明」という。）は、次のとおりのものである。  
 　　  
「【請求項１】
　ドキュメント情報を入力することによりＸＭＬ文書を作成するためのＸＭＬ文書作成装置において、
　入力されたドキュメント情報に関して、ＸＭＬ文書のタグとＸＭＬ文書を構成する要素の種別を日本語で記載した構造種別とを対応付けするとともに、タグ属性と前記構造種別の属性を日本語で記載した属性種別とを対応付けしたＤＴＤ変換テーブルに基づいて、構造種別と属性種別とを、ＤＴＤ変換部により対応するタグとタグ属性とに変換する処理を行う前記ＤＴＤ変換部を有することを特徴とするＸＭＬ文書作成装置。」 
　
　ただし、請求項１の「・・・、
前記
前記
　
　
　
３．引用例 
 　　  
　原査定の拒絶の理由３に引用文献１として引用された、特開２０００−３４８０３０号公報（以下、「引用例」という。）には、次の事項が記載又は図示されている。  
　
（ア）  
「　【０００１】
　　【発明の属する技術分野】
　本発明は、文書からタグ付き文書を作成するタグ付き文書作成装置及びその方法に関するものである。」
 　  
（イ） 
「　【０００５】
　　【発明が解決しようとする課題】
　特開平９−１６０９１７号に開示されている発明では、専用の文書入力装置で文書作成する必要があり、ワードプロセサ等で作成してある既存文書をタグ付け文書に変換することができない。またタグ付けの際、文書の中の文字列の意味上のカテゴリーを特定するために、その文字列の文書中の座標を手がかりとしているため、原文書の書式を柔軟に変更することができないという不便さがある。また変換テーブルは単純な文書構造の場合だけが開示されているだけであり、一つの文書要素が他の文書要素を含む図３のような文書構造をもつ文書に対して適用する方法が示されていない。
　　【０００６】
　タグ付け文書を作成するための市販ソフトでは、文書を変換する前に、どんなタグ（文書要素）があるか、そのタグにどんな属性があるか、どんな文書構造になっているかを明らかにした文書型定義（Document Type Definition）が完成していることが前提である。予め市販ソフトに用意されている文書型定義を使用する場合は問題ないが、新規に文書型定義を作成しなければならない場合は、専門の知識が必要な文書型定義を自ら行わなければならない。特に、文書型定義が後付でもよいＸＭＬの場合には余計な手間がかかる。といった問題点がある。
　　【０００７】
　本発明はこれらの点に鑑みてなされたものであり、既存の蓄積されたワープロ作成文書に適用可能な、文書型定義を必要としない、専門知識技術を要せずに容易にある程度複雑な文書構造を持つ文書にも適用可能な、タグ付き文書作成装置・方法を提供することを目的とする。」 
　　 
（ウ） 
「　【０００８】
　【課題を解決するための手段】
　上記課題を解決するために、第１の発明では、原文書の構造定義に従い、前記原文書のデリミタ文字列とタグとの対応関係とともに、タグが表示する文書要素間の階層関係をも表現する変換対応テーブルを用意し、タグ付き文書変換装置は、原文書から前記変換対応テーブルのデリミタ文字列を検出する文字列検出部と、前記デリミタに対応するタグとそのタグの変換対応テーブル上の列位置から、タグの階層を考慮して原文書に適切にタグを挿入するタグ付加部と、から構成する。ここでデリミタ文字列とは文書要素の区切りの目印となる予め定められた文字列のことである。」 
 　 
（エ） 
「　【００１５】
　　【発明の実施の形態】
　以下、本発明の実施の形態を実施例に基づいて説明する。図１１は本発明の一つの実施例としてのタグ付き文書作成装置を示すブロック図である。１はタグ付き文書作成装置であり、文字列検出部１１とタグ付加部１２から成る。２は変換対応テーブルであり、タグ付け処理に先立って予め用意されている。文字列検出部１１は原文書データ２０を読み込み、変換対応テーブル２に定義されたデリミタ文字列を手がかりに原文書から文書要素単位の文字列を抽出する。タグ付加部１２は文字列検出部１１が抽出した文字列ごとに適切な文書要素（タグ）を判定し、変換対応テーブル２を参照しながら文字列の前後に適切なタグを挿入する。その結果タグ付き文書３０が得られる。」
 　 
（オ） 
「　【００１６】
　本実施形態にかかわる実施例における文書変換の手順について具体例をもとに説明して行く。ここでは原文書として図２の「得意先販促報告書」を例に説明する。原文書データは特定のワープロ装置やワープロソフトで作られたものに限定されない。通常のテキストデータである。ただし何らかの定型形式に従って作られているものとし、「キーワード」により「文書要素」が特定できるものとする。「キーワード」とは例えば報告書において‘日付＝’とか‘出席者：’とかの文字列である。ここでいう「文書要素」とは報告書中の意味内容が明示された文字列である。」 
　 
（カ） 
「　【００１７】
　準備の手順は図５のごとくである。先ずステップＳ１において、原文書の文書構造と、区切りとなる「キーワード」を分析する。ここでは図２の原文書の雛形から‘日付＝’や‘【報告】’など、文書の意味内容の区切りとなるキーワードを拾い出し、キーワードで区切られる文書要素を特定し、文書要素間の関係を調べて文書の構造を検討する。次にステップＳ２において、文書要素の意味内容（あるいは文書要素に結びつけられる何かの属性）を表示するタグを定めて、文書要素間の関係を図３のような文書構造図に書き表す。次にステップＳ３にて、文書構造図図３を元に変換対応テーブルを作成する。
　　【００１８】
　変換対応テーブルは図１のような２次元の表である。第１列と第２列はデリミタ部であり、文書の区切りであるデリミタ文字列を置く。デリミタには２種類ある。何かの文書要素の始まりを意味するデリミタを開始デリミタ、文書要素の終わりを意味するデリミタを終了デリミタと呼ぶ。第１列には開始デリミタを置き、同一の文書要素（タグ）に対応する終了デリミタを第２列の同じ行に置く。変換対応テーブルの第３列から右側はタグを置く部分であるタグ部である。各デリミタに対応したタグをそのデリミタと同じ行のそのタグの階層レベルに応じた適切な列のセルに置く。タグの階層レベルとは、あるタグ１の表示する文書要素１が他の文書要素２を含む文書構造を持つとき、文書要素２を表示するタグ２はタグ１より１段下位の階層となる。このような文書要素間の包含関係で定まるタグ間の上下関係のことである。第３列（タグ部の第１列）以降の列は（図１では第７列まで）順に階層レベル１、階層レベル２、…に対応している。」
　
（キ）
「　【００２０】
　尚、図１では左側にデリミタ部、右側にタグ部を置いて変換対応テーブルを構成しているが、デリミタとタグの対応が表現されれば良いので左右逆に配置した変換対応テーブルを用いても構わない。以下の説明は図１に従う。以上で必要な準備が完了したので、図２の雛形によって作成された図４の原文書データを実際に図３の文書構造を持つXML文書に変換して行く。図６はその手順のフローチャートである。以下、図６に従い変換の手順を説明して行く。」
　
（ク）
「　【００２１】
　先ず変換テーブルに定義されている開始デリミタ、終了デリミタを読み込み文字列検出の目印と設定する（ステップＳ１０）。次に原文書データファイルをオープンする（ステップＳ１１）。次に、原文書データをサーチし、設定されたデリミタで区切られる文字列を抽出する（ステップＳ１２）。原文書全てに渡り、抽出した文字列と前後のデリミタを調べて図８のような表を作成する（ステップＳ１４）。図８ではデリミタで前後に挟まれた文字列−抽出文字列と、それに先行するデリミタを、１行にして並べている。説明のため各行に番号を付した。尚５行目の抽出文字列はスペース文字または改行文字のみの文字列である。
　　【００２２】
　図８の表ができれば文字列検出部の動作は終わりである。次にこの図８の表をタグ付加部に読み込ませ（ステップＳ１４）、タグ付加処理を開始させる。タグ付加部でのタグ付加処理（ステップＳ１６）の詳細は図７のフローチャートにより後述する。タグ付け処理の結果図１０のようなタグ付け文書データができる。ステップＳ１８は終了処理であり、タグ付け文書データに必要な仕上げ処理を行う。すなわち得られたタグ付き文書データの前後にルートタグdocument、/documentを付ける。また、ＸＭＬ文書ならばＸＭＬ宣言などの付加を施し、所望の形式のタグ付け文書とする。」
　
　
　以上の引用例の記載によれば、引用例には以下の事項が開示されていると認められる。  
　
（ａ） 
　引用例の上記（エ）の「以下、本発明の実施の形態を実施例に基づいて説明する。図１１は本発明の一つの実施例としてのタグ付き文書作成装置を示すブロック図である。１はタグ付き文書作成装置であり、文字列検出部１１とタグ付加部１２から成る。２は変換対応テーブルであり、タグ付け処理に先立って予め用意されている。文字列検出部１１は原文書データ２０を読み込み、・・・（中略）・・・、変換対応テーブル２を参照しながら文字列の前後に適切なタグを挿入する。その結果タグ付き文書３０が得られる。」という記載、
（なお、「原文書データ２０を読み込」んでいるのであるから、「原文書データ」を入力しているといえることは明らかである。）
　
　引用例の上記（キ）の「尚、図１では左側にデリミタ部、右側にタグ部を置いて変換対応テーブルを構成しているが、デリミタとタグの対応が表現されれば良いので左右逆に配置した変換対応テーブルを用いても構わない。以下の説明は図１に従う。以上で必要な準備が完了したので、図２の雛形によって作成された図４の原文書データを実際に図３の文書構造を持つXML文書に変換して行く。図６はその手順のフローチャートである。以下、図６に従い変換の手順を説明して行く。」という記載から、
（「・・・図４の原文書データを実際に図３の文書構造を持つXML文書に変換・・・」しているのであるから、「ＸＭＬ文書」を「作成」しているといえることは明らかである。） 
　
　引用例には、「原文書データを入力することによりＸＭＬ文書を作成するためのタグ付き文書作成装置」が開示されていると認められる。 
 　 
 　 
（ｂ） 
　上記（ａ）の「原文書データを入力することによりＸＭＬ文書を作成するためのタグ付き文書作成装置」という開示、 
　 
　引用例の上記（エ）の「以下、本発明の実施の形態を実施例に基づいて説明する。図１１は本発明の一つの実施例としてのタグ付き文書作成装置を示すブロック図である。１はタグ付き文書作成装置であり、文字列検出部１１とタグ付加部１２から成る。２は変換対応テーブルであり、タグ付け処理に先立って予め用意されている。文字列検出部１１は原文書データ２０を読み込み、変換対応テーブル２に定義されたデリミタ文字列を手がかりに原文書から文書要素単位の文字列を抽出する。タグ付加部１２は文字列検出部１１が抽出した文字列ごとに適切な文書要素（タグ）を判定し、変換対応テーブル２を参照しながら文字列の前後に適切なタグを挿入する。その結果タグ付き文書３０が得られる。」という記載、
（なお、「タグ付き文書作成装置」が「文字列検出部」及び「タグ付加部」を備えていることは明らかである。）
　 
　引用例の上記（キ）の「準備の手順は図５のごとくである。先ずステップＳ１において、原文書の文書構造と、区切りとなる「キーワード」を分析する。ここでは図２の原文書の雛形から‘日付＝’や‘【報告】’など、文書の意味内容の区切りとなるキーワードを拾い出し、キーワードで区切られる文書要素を特定し、文書要素間の関係を調べて文書の構造を検討する。次にステップＳ２において、文書要素の意味内容（あるいは文書要素に結びつけられる何かの属性）を表示するタグを定めて、文書要素間の関係を図３のような文書構造図に書き表す。次にステップＳ３にて、文書構造図図３を元に変換対応テーブルを作成する。・・・（中略）・・・変換対応テーブルは図１のような２次元の表である。第１列と第２列はデリミタ部であり、文書の区切りであるデリミタ文字列を置く。デリミタには２種類ある。何かの文書要素の始まりを意味するデリミタを開始デリミタ、文書要素の終わりを意味するデリミタを終了デリミタと呼ぶ。第１列には開始デリミタを置き、同一の文書要素（タグ）に対応する終了デリミタを第２列の同じ行に置く。変換対応テーブルの第３列から右側はタグを置く部分であるタグ部である。各デリミタに対応したタグをそのデリミタと同じ行のそのタグの階層レベルに応じた適切な列のセルに置く。タグの階層レベルとは、あるタグ１の表示する文書要素１が他の文書要素２を含む文書構造を持つとき、文書要素２を表示するタグ２はタグ１より１段下位の階層となる。このような文書要素間の包含関係で定まるタグ間の上下関係のことである。第３列（タグ部の第１列）以降の列は（図１では第７列まで）順に階層レベル１、階層レベル２、…に対応している。」という記載、
（なお、「デリミタ」が文書要素の「種別」を表していることは明らかである。また、「デリミタ」は「‘日付＝’や‘【報告】’など」を元にして作成されているのであるから、「デリミタ」は日本語で表現されている。このことは、引用例の「図１」からも明らかである。）
　
　引用例の上記（ク）の「先ず変換テーブルに定義されている開始デリミタ、終了デリミタを読み込み文字列検出の目印と設定する（ステップＳ１０）。次に原文書データファイルをオープンする（ステップＳ１１）。次に、原文書データをサーチし、設定されたデリミタで区切られる文字列を抽出する（ステップＳ１２）。原文書全てに渡り、抽出した文字列と前後のデリミタを調べて図８のような表を作成する（ステップＳ１４）。図８ではデリミタで前後に挟まれた文字列−抽出文字列と、それに先行するデリミタを、１行にして並べている。・・・（中略）・・・。図８の表ができれば文字列検出部の動作は終わりである。次にこの図８の表をタグ付加部に読み込ませ（ステップＳ１４）、タグ付加処理を開始させる。タグ付加部でのタグ付加処理（ステップＳ１６）の詳細は図７のフローチャートにより後述する。タグ付け処理の結果図１０のようなタグ付け文書データができる。ステップＳ１８は終了処理であり、タグ付け文書データに必要な仕上げ処理を行う。すなわち得られたタグ付き文書データの前後にルートタグdocument、/documentを付ける。また、ＸＭＬ文書ならばＸＭＬ宣言などの付加を施し、所望の形式のタグ付け文書とする。」という記載から、
（なお、「タグ付き文書作成装置」が備える「文字列検出部」及び「タグ付加部」によって、「原文書データ」中の「デリミタ」が取り去られ、代わりに「タグ」が付加されている。このことは、引用例の「図４　原文書データ」及び「図８　原文書データをタグ付けした結果」からも明らかである。）
　
　引用例には、「入力された原文書データに関して、ＸＭＬ文書のタグとＸＭＬ文書を構成する文書要素の種別を日本語で記載したデリミタとを対応付けした変換対応テーブルに基づいて、デリミタを、文字列検出部及びタグ付加部により対応するタグに変換する処理を行う、前記文字列検出部及びタグ付加部」が開示されていると認められる。
 　 
 　 
　以上の引用例の記載によれば、引用例には下記の発明（以下、「引用例発明」という。）が開示されていると認められる。  
 　  
「原文書データを入力することによりＸＭＬ文書を作成するためのタグ付き文書作成装置において、
　入力された原文書データに関して、ＸＭＬ文書のタグとＸＭＬ文書を構成する文書要素の種別を日本語で記載したデリミタとを対応付けした変換対応テーブルに基づいて、デリミタを、文字列検出部及びタグ付加部により対応するタグに変換する処理を行う、前記文字列検出部及びタグ付加部を有することを特徴とするタグ付き文書作成装置。」 
　
　
　
４．対比  
　
（１）
　「ドキュメント情報」とは「ドキュメント」本体の情報を含みうる広範囲な意味を持つ一般的な用語であることを鑑みれば、
　
　引用例発明の「原文書データ」は、 
 　 
　本願発明の「ドキュメント情報」に相当する。 
　
　
（２）
　引用例の上記（キ）の「準備の手順は図５のごとくである。先ずステップＳ１において、原文書の文書構造と、区切りとなる「キーワード」を分析する。ここでは図２の原文書の雛形から‘日付＝’や‘【報告】’など、文書の意味内容の区切りとなるキーワードを拾い出し、キーワードで区切られる文書要素を特定し、文書要素間の関係を調べて文書の構造を検討する。次にステップＳ２において、文書要素の意味内容（あるいは文書要素に結びつけられる何かの属性）を表示するタグを定めて、文書要素間の関係を図３のような文書構造図に書き表す。次にステップＳ３にて、文書構造図図３を元に変換対応テーブルを作成する。・・・（中略）・・・変換対応テーブルは図１のような２次元の表である。第１列と第２列はデリミタ部であり、文書の区切りであるデリミタ文字列を置く。・・・（中略）・・・。変換対応テーブルの第３列から右側はタグを置く部分であるタグ部である。各デリミタに対応したタグをそのデリミタと同じ行のそのタグの階層レベルに応じた適切な列のセルに置く。・・・」という記載から、
　「文書構造図」を元に作成される「デリミタ」が（文書要素の種別だけでなく）文書の「構造」の「種別」も表していることは明らかであることから、
 
　引用例発明の「ＸＭＬ文書を構成する文書要素の種別を日本語で記載したデリミタ」は、 
 　 
　本願発明の「ＸＭＬ文書を構成する要素の種別を日本語で記載した構造種別」に相当する。 
 　 
 　 
（３）
　引用例発明の「原文書データを入力することによりＸＭＬ文書を作成するためのタグ付き文書作成装置」は、
　
　本願発明の「ドキュメント情報を入力することによりＸＭＬ文書を作成するためのＸＭＬ文書作成装置」に相当する。
　
　
（４）
　引用例発明の「ＸＭＬ文書のタグとＸＭＬ文書を構成する文書要素の種別を日本語で記載したデリミタとを対応付けした変換対応テーブル」は、文書型定義（ＤＴＤ：Document Type Definition）に関する変換対応テーブルの一種であることを鑑みれば、
　
　引用例発明の「ＸＭＬ文書のタグとＸＭＬ文書を構成する文書要素の種別を日本語で記載したデリミタとを対応付けした変換対応テーブル」と、
　
　本願発明の「ＸＭＬ文書のタグとＸＭＬ文書を構成する要素の種別を日本語で記載した構造種別とを対応付けするとともに、タグ属性と前記構造種別の属性を日本語で記載した属性種別とを対応付けしたＤＴＤ変換テーブル」とは、
　
「ＸＭＬ文書のタグとＸＭＬ文書を構成する要素の種別を日本語で記載した構造種別とを対応付けしたＤＴＤ変換テーブル」という点で一致し、
　
　本願発明では、（ＸＭＬ文書のタグとＸＭＬ文書を構成する要素の種別を日本語で記載した構造種別とを対応付けするだけでなく）タグ属性と前記構造種別の属性を日本語で記載した属性種別とを対応付けしたＤＴＤ変換テーブルであるのに対し、
　引用例発明では、そのようなＤＴＤ変換テーブルを開示していない点、
　
　で相違する。
　
　
（５）  
　引用例発明の「入力された原文書データに関して、ＸＭＬ文書のタグとＸＭＬ文書を構成する文書要素の種別を日本語で記載したデリミタとを対応付けした変換対応テーブルに基づいて、デリミタを、文字列検出部及びタグ付加部により対応するタグに変換する処理を行う、前記文字列検出部及びタグ付加部」と、
 　 
　本願発明の「入力されたドキュメント情報に関して、ＸＭＬ文書のタグとＸＭＬ文書を構成する要素の種別を日本語で記載した構造種別とを対応付けするとともに、タグ属性と前記構造種別の属性を日本語で記載した属性種別とを対応付けしたＤＴＤ変換テーブルに基づいて、構造種別と属性種別とを、ＤＴＤ変換部により対応するタグとタグ属性とに変換する処理を行う前記ＤＴＤ変換部」とは、
　
「入力されたドキュメント情報に関して、ＸＭＬ文書のタグとＸＭＬ文書を構成する要素の種別を日本語で記載した構造種別とを対応付けしたＤＴＤ変換テーブルに基づいて、構造種別を、変換部により対応するタグに変換する処理を行う前記変換部」という点で一致し、
　
・本願発明では、（ＸＭＬ文書のタグとＸＭＬ文書を構成する要素の種別を日本語で記載した構造種別とを対応付けするだけでなく）タグ属性と前記構造種別の属性を日本語で記載した属性種別とを対応付けしたＤＴＤ変換テーブルに基づいて、属性種別を、変換部により対応するタグ属性とに変換する処理」も行っているのに対し、
　引用例発明では、ＤＴＤ変換テーブルがタグ属性と前記構造種別の属性を日本語で記載した属性種別までも対応付けるものではなく、属性種別を、変換部により対応するタグ属性とに変換する処理を行っていない点、
　
・本願発明の「変換部」は「ＤＴＤ変換部」であるのに対し、
　引用例発明の「変換部」は「文字列検出部及びタグ付加部」である点、
　
　で相違する。 
　
　
（６） 
　以上のことから、本願発明と引用例発明とは、  
 　  
「ドキュメント情報を入力することによりＸＭＬ文書を作成するためのＸＭＬ文書作成装置において、
　入力されたドキュメント情報に関して、ＸＭＬ文書のタグとＸＭＬ文書を構成する要素の種別を日本語で記載した構造種別とを対応付けしたＤＴＤ変換テーブルに基づいて、構造種別を、変換部により対応するタグに変換する処理を行う前記変換部を有することを特徴とするＸＭＬ文書作成装置。」  
 　  
　という点で一致し、 
 　  
（相違点１）  
　本願発明では、（ＸＭＬ文書のタグとＸＭＬ文書を構成する要素の種別を日本語で記載した構造種別とを対応付けするだけでなく）タグ属性と前記構造種別の属性を日本語で記載した属性種別とを対応付けしたＤＴＤ変換テーブルに基づいて、属性種別を、変換部により対応するタグ属性とに変換する処理」も行っているのに対し、
　引用例発明では、ＤＴＤ変換テーブルがタグ属性と前記構造種別の属性を日本語で記載した属性種別までも対応付けるものではなく、属性種別を、変換部により対応するタグ属性とに変換する処理を行っていない点、 　 
 　 
（相違点２） 
　本願発明の「変換部」は「ＤＴＤ変換部」であるのに対し、
　引用例発明の「変換部」は「文字列検出部及びタグ付加部」である点、
　 
　で相違する。
　 
　 
　 
５．判断  
 　  
（１）相違点１について  
　
　ＸＭＬ文書において、「タグ」に結び付けられる「タグ属性」を備えることが可能であることは、情報処理分野における技術常識である。
　
　また、引用例の上記（キ）の「準備の手順は図５のごとくである。先ずステップＳ１において、原文書の文書構造と、区切りとなる「キーワード」を分析する。ここでは図２の原文書の雛形から‘日付＝’や‘【報告】’など、文書の意味内容の区切りとなるキーワードを拾い出し、キーワードで区切られる文書要素を特定し、文書要素間の関係を調べて文書の構造を検討する。次にステップＳ２において、文書要素の意味内容（あるいは文書要素に結びつけられる何かの
属性
　引用例の「デリミタ」として採用されるものは、「文書要素の意味内容」だけでなく、「文書要素に結びつけられる何かの
属性
　引用例は、ＸＭＬ文書の「タグ」（「構造種別」に対応する情報）に結び付けられる「タグ
属性
　
　したがって、引用例発明において、ＸＭＬ文書のタグへの変換だけでなく、ＸＭＬ文書のタグ属性への変換も可能とするべく、
「ＸＭＬ文書のタグとＸＭＬ文書を構成する要素の種別を日本語で記載した構造種別とを対応付けした変換テーブルに基づいて、構造種別を、変換部により対応するタグに変換する処理」を行うのと同様に、
「ＸＭＬ文書のタグ属性と前記構造種別の属性を日本語で記載した属性種別とを対応付けした変換テーブルに基づいて、属性種別を、変換部により対応するタグ属性に変換する処理」も行うようにすること、
　すなわち、ＤＴＤ変換テーブルを、ＸＭＬ文書のタグとＸＭＬ文書を構成する要素の種別を日本語で記載した構造種別とを対応付けするだけでなく、タグ属性と前記構造種別の属性を日本語で記載した属性種別をも対応付けしたＤＴＤ変換テーブルとし、それに基づいて、属性種別を、変換部により対応するタグ属性とに変換する処理も行うようにすることは、当業者が容易に想到し得ることである。　　 
 　  
 　  
 （２）相違点２について  
 　 
　ある機能をひとつの手段によって実現したり、ある機能を複数の手段によって実現したりすることは、情報処理分野における常套手段である。
　
　したがって、引用例発明において、変換に関する処理を、複数の手段（文字列検出部及びタグ付加部）によって実現する代わりに、ひとつの手段（ＤＴＤ変換部）によって実現することは、当業者が容易に想到し得ることである。
　 
　  
　
６．付記
　
（１）
　審判請求人は、平成２１年９月７日付け回答書において、
「すなわち、本願請求項１に記載の発明では、文章（テキスト）、図、表により表現されたリソースを、日本語の構造種別により分けて管理しておりますが（合わせて本願の図１０、図２２等をご参照願います。）、引用文献１には、１つのテキスト文書を超えて、日本語で記載したＸＭＬタグで管理しようとする発想が無い点が全く異なります。」
　及び「すなわち、１つの文章について日本語のキーワードを用いてＸＭＬ文書を簡便に作成するという構成が引用文献１の特徴であるとすれば、本願請求項１等に記載の発明では、個々の文章を簡便に作成するよりも、章・節、文章、画像、表などのリソースを組み合わせた複雑な階層・構造のＸＭＬ文書をより簡便に作成できるという、引用文献等とは全く異なる大きな特徴を有するものであります。」
　と主張している。
　しかしながら、本願発明では、「ドキュメント情報」や「構造種別」について具体的な限定（例：文章（テキスト）、図、表という３種のリソースを前提とした複雑な階層・構造を有していること、１つのテキスト文書を超えて管理されること）は何らされていない。
　したがって、審判請求人の主張は、特許請求の範囲の請求項１にある記載に基づくものではないといえる。
　
　たとえそうでないとしても、文書（テキスト）というリソースだけでなく、図及び表というリソースを用いてドキュメントが構成されることは情報処理分野における技術常識であるから、
　引用例発明において、文書（テキスト）というリソースを取り扱うだけでなく、図及び表というリソースも取り扱えるようにしたり、これらのリソースに対応できるように、複数階層に対応した「変換対応テーブル」（本願発明の「ＤＴＤ変換テーブル」に略対応）を拡充したりすることは、当業者が容易に想到し得ることである。
　
　
（２）
　審判請求人は、平成２１年９月７日付け回答書において、
「さらに、請求項１等に記載の発明によれば、例えば複雑なＸＭＬ文書をより簡便に作成できるという効果以外の効果として、「構造種別および属性種別を、一般的な言語、例えば日本語でより記載すれば、ユーザインターフェ
イスがわかりやすくなる。」（０００７段落）という発想に関しましても、引用文献等には開示も示唆もされておりません。」
　と主張している。
　しかしながら、引用例発明において「デリミタ」等に日本語が使えることから、日本のユーザにとって、ユーザインターフェイスがわかりやすくなっていることは明らかである。
　
　なお、英語圏において開発されたプログラム（例：ＸＭＬ文書を扱えるＯＳ、ＸＭＬ文書を扱えるアプリケーション・ソフトウエア、ＸＭＬ文書を扱えるプログラミング・ソフトウエア）や当該プログラムが扱うデータ（例：ＸＭＬ文書）は、英語圏のユーザが通常用いる英語を前提として仕様が定められることが多かったため、非英語圏（例：日本）のユーザの利便性を向上するために当該プログラム及びデータの仕様をローカライズしてきたこと（例：日本語対応にしてきたこと）は、情報処理分野における周知の技術的歴史的経緯である。
（例：マイクロソフト株式会社のＷｉｎｄｏｗｓやＯｆｆｉｃｅソフトウエアの日本語対応化、プログラミング言語の仕様の日本語化（参考：特開昭６１−２０１１５号公報には、「ＰＲＩＮＴ」命令が「印刷」命令になっている。））
　すなわち、情報処理分野における当業者であれば、英語圏発祥のＸＭＬ技術を基礎とする引用例発明において「デリミタ」等に日本語が使えること（すなわち、引用例発明が日本語対応になっていること）という事実それ自体によって、日本のユーザの利便性を向上するという発想を内在したものとなっていることを自明に理解できる。
　
　
　 
７．むすび  
 　  
　したがって、本願発明は、引用例発明に基づいて、当業者が容易に発明をすることができたものであり、特許法第２９条第２項の規定により特許を受けることができないから、他の請求項について検討するまでもなく、本願は拒絶されるべきものである。  
　
　よって、結論のとおり審決する。