ポートフォリオを新規に作成して保存 |
|
|
既存のポートフォリオに追加保存 |
|
PDFをダウンロード |
審決分類 |
審判 査定不服 2項進歩性 特許、登録しない。 G06F |
---|---|
管理番号 | 1211068 |
審判番号 | 不服2007-23796 |
総通号数 | 123 |
発行国 | 日本国特許庁(JP) |
公報種別 | 特許審決公報 |
発行日 | 2010-03-26 |
種別 | 拒絶査定不服の審決 |
審判請求日 | 2007-08-30 |
確定日 | 2010-02-04 |
事件の表示 | 特願2002-193851「XML文書作成システム」拒絶査定不服審判事件〔平成16年 2月 5日出願公開、特開2004- 38496〕について、次のとおり審決する。 |
結論 | 本件審判の請求は、成り立たない。 |
理由 |
1.手続の経緯 本願は、平成14年7月2日の出願であって、平成19年7月23日付けで拒絶査定がなされ、これに対し、平成19年8月30日に拒絶査定不服審判の請求がなされるとともに、平成19年10月1日付けで手続補正がなされたものである。 2.本願発明 本願の請求項1乃至5に係る発明は、平成19年10月1日付けの手続補正書によって補正された明細書及び図面の記載からみて、(後述する誤記を除き)特許請求の範囲の請求項1乃至5に記載されたとおりのものと認められるところ、その請求項1に係る発明(以下、「本願発明」という。)は、次のとおりのものである。 「【請求項1】 ドキュメント情報を入力することによりXML文書を作成するためのXML文書作成装置において、 入力されたドキュメント情報に関して、XML文書のタグとXML文書を構成する要素の種別を日本語で記載した構造種別とを対応付けするとともに、タグ属性と前記構造種別の属性を日本語で記載した属性種別とを対応付けしたDTD変換テーブルに基づいて、構造種別と属性種別とを、DTD変換部により対応するタグとタグ属性とに変換する処理を行う前記DTD変換部を有することを特徴とするXML文書作成装置。」 ただし、請求項1の「・・・、前記DTD変換部により対応するタグとタグ属性とに変換する処理を行うDTD変換部」という記載は、「前記DTD変換部により」という記載の前に「DTD変換部」という記載はないことから、「・・・、DTD変換部により対応するタグとタグ属性とに変換する処理を行う前記DTD変換部」という記載の誤記であることは明らかであるので、上記の如く認定する。 3.引用例 原査定の拒絶の理由3に引用文献1として引用された、特開2000-348030号公報(以下、「引用例」という。)には、次の事項が記載又は図示されている。 (ア) 「 【0001】 【発明の属する技術分野】 本発明は、文書からタグ付き文書を作成するタグ付き文書作成装置及びその方法に関するものである。」 (イ) 「 【0005】 【発明が解決しようとする課題】 特開平9-160917号に開示されている発明では、専用の文書入力装置で文書作成する必要があり、ワードプロセサ等で作成してある既存文書をタグ付け文書に変換することができない。またタグ付けの際、文書の中の文字列の意味上のカテゴリーを特定するために、その文字列の文書中の座標を手がかりとしているため、原文書の書式を柔軟に変更することができないという不便さがある。また変換テーブルは単純な文書構造の場合だけが開示されているだけであり、一つの文書要素が他の文書要素を含む図3のような文書構造をもつ文書に対して適用する方法が示されていない。 【0006】 タグ付け文書を作成するための市販ソフトでは、文書を変換する前に、どんなタグ(文書要素)があるか、そのタグにどんな属性があるか、どんな文書構造になっているかを明らかにした文書型定義(Document Type Definition)が完成していることが前提である。予め市販ソフトに用意されている文書型定義を使用する場合は問題ないが、新規に文書型定義を作成しなければならない場合は、専門の知識が必要な文書型定義を自ら行わなければならない。特に、文書型定義が後付でもよいXMLの場合には余計な手間がかかる。といった問題点がある。 【0007】 本発明はこれらの点に鑑みてなされたものであり、既存の蓄積されたワープロ作成文書に適用可能な、文書型定義を必要としない、専門知識技術を要せずに容易にある程度複雑な文書構造を持つ文書にも適用可能な、タグ付き文書作成装置・方法を提供することを目的とする。」 (ウ) 「 【0008】 【課題を解決するための手段】 上記課題を解決するために、第1の発明では、原文書の構造定義に従い、前記原文書のデリミタ文字列とタグとの対応関係とともに、タグが表示する文書要素間の階層関係をも表現する変換対応テーブルを用意し、タグ付き文書変換装置は、原文書から前記変換対応テーブルのデリミタ文字列を検出する文字列検出部と、前記デリミタに対応するタグとそのタグの変換対応テーブル上の列位置から、タグの階層を考慮して原文書に適切にタグを挿入するタグ付加部と、から構成する。ここでデリミタ文字列とは文書要素の区切りの目印となる予め定められた文字列のことである。」 (エ) 「 【0015】 【発明の実施の形態】 以下、本発明の実施の形態を実施例に基づいて説明する。図11は本発明の一つの実施例としてのタグ付き文書作成装置を示すブロック図である。1はタグ付き文書作成装置であり、文字列検出部11とタグ付加部12から成る。2は変換対応テーブルであり、タグ付け処理に先立って予め用意されている。文字列検出部11は原文書データ20を読み込み、変換対応テーブル2に定義されたデリミタ文字列を手がかりに原文書から文書要素単位の文字列を抽出する。タグ付加部12は文字列検出部11が抽出した文字列ごとに適切な文書要素(タグ)を判定し、変換対応テーブル2を参照しながら文字列の前後に適切なタグを挿入する。その結果タグ付き文書30が得られる。」 (オ) 「 【0016】 本実施形態にかかわる実施例における文書変換の手順について具体例をもとに説明して行く。ここでは原文書として図2の「得意先販促報告書」を例に説明する。原文書データは特定のワープロ装置やワープロソフトで作られたものに限定されない。通常のテキストデータである。ただし何らかの定型形式に従って作られているものとし、「キーワード」により「文書要素」が特定できるものとする。「キーワード」とは例えば報告書において‘日付=’とか‘出席者:’とかの文字列である。ここでいう「文書要素」とは報告書中の意味内容が明示された文字列である。」 (カ) 「 【0017】 準備の手順は図5のごとくである。先ずステップS1において、原文書の文書構造と、区切りとなる「キーワード」を分析する。ここでは図2の原文書の雛形から‘日付=’や‘【報告】’など、文書の意味内容の区切りとなるキーワードを拾い出し、キーワードで区切られる文書要素を特定し、文書要素間の関係を調べて文書の構造を検討する。次にステップS2において、文書要素の意味内容(あるいは文書要素に結びつけられる何かの属性)を表示するタグを定めて、文書要素間の関係を図3のような文書構造図に書き表す。次にステップS3にて、文書構造図図3を元に変換対応テーブルを作成する。 【0018】 変換対応テーブルは図1のような2次元の表である。第1列と第2列はデリミタ部であり、文書の区切りであるデリミタ文字列を置く。デリミタには2種類ある。何かの文書要素の始まりを意味するデリミタを開始デリミタ、文書要素の終わりを意味するデリミタを終了デリミタと呼ぶ。第1列には開始デリミタを置き、同一の文書要素(タグ)に対応する終了デリミタを第2列の同じ行に置く。変換対応テーブルの第3列から右側はタグを置く部分であるタグ部である。各デリミタに対応したタグをそのデリミタと同じ行のそのタグの階層レベルに応じた適切な列のセルに置く。タグの階層レベルとは、あるタグ1の表示する文書要素1が他の文書要素2を含む文書構造を持つとき、文書要素2を表示するタグ2はタグ1より1段下位の階層となる。このような文書要素間の包含関係で定まるタグ間の上下関係のことである。第3列(タグ部の第1列)以降の列は(図1では第7列まで)順に階層レベル1、階層レベル2、…に対応している。」 (キ) 「 【0020】 尚、図1では左側にデリミタ部、右側にタグ部を置いて変換対応テーブルを構成しているが、デリミタとタグの対応が表現されれば良いので左右逆に配置した変換対応テーブルを用いても構わない。以下の説明は図1に従う。以上で必要な準備が完了したので、図2の雛形によって作成された図4の原文書データを実際に図3の文書構造を持つXML文書に変換して行く。図6はその手順のフローチャートである。以下、図6に従い変換の手順を説明して行く。」 (ク) 「 【0021】 先ず変換テーブルに定義されている開始デリミタ、終了デリミタを読み込み文字列検出の目印と設定する(ステップS10)。次に原文書データファイルをオープンする(ステップS11)。次に、原文書データをサーチし、設定されたデリミタで区切られる文字列を抽出する(ステップS12)。原文書全てに渡り、抽出した文字列と前後のデリミタを調べて図8のような表を作成する(ステップS14)。図8ではデリミタで前後に挟まれた文字列-抽出文字列と、それに先行するデリミタを、1行にして並べている。説明のため各行に番号を付した。尚5行目の抽出文字列はスペース文字または改行文字のみの文字列である。 【0022】 図8の表ができれば文字列検出部の動作は終わりである。次にこの図8の表をタグ付加部に読み込ませ(ステップS14)、タグ付加処理を開始させる。タグ付加部でのタグ付加処理(ステップS16)の詳細は図7のフローチャートにより後述する。タグ付け処理の結果図10のようなタグ付け文書データができる。ステップS18は終了処理であり、タグ付け文書データに必要な仕上げ処理を行う。すなわち得られたタグ付き文書データの前後にルートタグ 以上の引用例の記載によれば、引用例には以下の事項が開示されていると認められる。 (a) 引用例の上記(エ)の「以下、本発明の実施の形態を実施例に基づいて説明する。図11は本発明の一つの実施例としてのタグ付き文書作成装置を示すブロック図である。1はタグ付き文書作成装置であり、文字列検出部11とタグ付加部12から成る。2は変換対応テーブルであり、タグ付け処理に先立って予め用意されている。文字列検出部11は原文書データ20を読み込み、・・・(中略)・・・、変換対応テーブル2を参照しながら文字列の前後に適切なタグを挿入する。その結果タグ付き文書30が得られる。」という記載、 (なお、「原文書データ20を読み込」んでいるのであるから、「原文書データ」を入力しているといえることは明らかである。) 引用例の上記(キ)の「尚、図1では左側にデリミタ部、右側にタグ部を置いて変換対応テーブルを構成しているが、デリミタとタグの対応が表現されれば良いので左右逆に配置した変換対応テーブルを用いても構わない。以下の説明は図1に従う。以上で必要な準備が完了したので、図2の雛形によって作成された図4の原文書データを実際に図3の文書構造を持つXML文書に変換して行く。図6はその手順のフローチャートである。以下、図6に従い変換の手順を説明して行く。」という記載から、 (「・・・図4の原文書データを実際に図3の文書構造を持つXML文書に変換・・・」しているのであるから、「XML文書」を「作成」しているといえることは明らかである。) 引用例には、「原文書データを入力することによりXML文書を作成するためのタグ付き文書作成装置」が開示されていると認められる。 (b) 上記(a)の「原文書データを入力することによりXML文書を作成するためのタグ付き文書作成装置」という開示、 引用例の上記(エ)の「以下、本発明の実施の形態を実施例に基づいて説明する。図11は本発明の一つの実施例としてのタグ付き文書作成装置を示すブロック図である。1はタグ付き文書作成装置であり、文字列検出部11とタグ付加部12から成る。2は変換対応テーブルであり、タグ付け処理に先立って予め用意されている。文字列検出部11は原文書データ20を読み込み、変換対応テーブル2に定義されたデリミタ文字列を手がかりに原文書から文書要素単位の文字列を抽出する。タグ付加部12は文字列検出部11が抽出した文字列ごとに適切な文書要素(タグ)を判定し、変換対応テーブル2を参照しながら文字列の前後に適切なタグを挿入する。その結果タグ付き文書30が得られる。」という記載、 (なお、「タグ付き文書作成装置」が「文字列検出部」及び「タグ付加部」を備えていることは明らかである。) 引用例の上記(キ)の「準備の手順は図5のごとくである。先ずステップS1において、原文書の文書構造と、区切りとなる「キーワード」を分析する。ここでは図2の原文書の雛形から‘日付=’や‘【報告】’など、文書の意味内容の区切りとなるキーワードを拾い出し、キーワードで区切られる文書要素を特定し、文書要素間の関係を調べて文書の構造を検討する。次にステップS2において、文書要素の意味内容(あるいは文書要素に結びつけられる何かの属性)を表示するタグを定めて、文書要素間の関係を図3のような文書構造図に書き表す。次にステップS3にて、文書構造図図3を元に変換対応テーブルを作成する。・・・(中略)・・・変換対応テーブルは図1のような2次元の表である。第1列と第2列はデリミタ部であり、文書の区切りであるデリミタ文字列を置く。デリミタには2種類ある。何かの文書要素の始まりを意味するデリミタを開始デリミタ、文書要素の終わりを意味するデリミタを終了デリミタと呼ぶ。第1列には開始デリミタを置き、同一の文書要素(タグ)に対応する終了デリミタを第2列の同じ行に置く。変換対応テーブルの第3列から右側はタグを置く部分であるタグ部である。各デリミタに対応したタグをそのデリミタと同じ行のそのタグの階層レベルに応じた適切な列のセルに置く。タグの階層レベルとは、あるタグ1の表示する文書要素1が他の文書要素2を含む文書構造を持つとき、文書要素2を表示するタグ2はタグ1より1段下位の階層となる。このような文書要素間の包含関係で定まるタグ間の上下関係のことである。第3列(タグ部の第1列)以降の列は(図1では第7列まで)順に階層レベル1、階層レベル2、…に対応している。」という記載、 (なお、「デリミタ」が文書要素の「種別」を表していることは明らかである。また、「デリミタ」は「‘日付=’や‘【報告】’など」を元にして作成されているのであるから、「デリミタ」は日本語で表現されている。このことは、引用例の「図1」からも明らかである。) 引用例の上記(ク)の「先ず変換テーブルに定義されている開始デリミタ、終了デリミタを読み込み文字列検出の目印と設定する(ステップS10)。次に原文書データファイルをオープンする(ステップS11)。次に、原文書データをサーチし、設定されたデリミタで区切られる文字列を抽出する(ステップS12)。原文書全てに渡り、抽出した文字列と前後のデリミタを調べて図8のような表を作成する(ステップS14)。図8ではデリミタで前後に挟まれた文字列-抽出文字列と、それに先行するデリミタを、1行にして並べている。・・・(中略)・・・。図8の表ができれば文字列検出部の動作は終わりである。次にこの図8の表をタグ付加部に読み込ませ(ステップS14)、タグ付加処理を開始させる。タグ付加部でのタグ付加処理(ステップS16)の詳細は図7のフローチャートにより後述する。タグ付け処理の結果図10のようなタグ付け文書データができる。ステップS18は終了処理であり、タグ付け文書データに必要な仕上げ処理を行う。すなわち得られたタグ付き文書データの前後にルートタグ (なお、「タグ付き文書作成装置」が備える「文字列検出部」及び「タグ付加部」によって、「原文書データ」中の「デリミタ」が取り去られ、代わりに「タグ」が付加されている。このことは、引用例の「図4 原文書データ」及び「図8 原文書データをタグ付けした結果」からも明らかである。) 引用例には、「入力された原文書データに関して、XML文書のタグとXML文書を構成する文書要素の種別を日本語で記載したデリミタとを対応付けした変換対応テーブルに基づいて、デリミタを、文字列検出部及びタグ付加部により対応するタグに変換する処理を行う、前記文字列検出部及びタグ付加部」が開示されていると認められる。 以上の引用例の記載によれば、引用例には下記の発明(以下、「引用例発明」という。)が開示されていると認められる。 「原文書データを入力することによりXML文書を作成するためのタグ付き文書作成装置において、 入力された原文書データに関して、XML文書のタグとXML文書を構成する文書要素の種別を日本語で記載したデリミタとを対応付けした変換対応テーブルに基づいて、デリミタを、文字列検出部及びタグ付加部により対応するタグに変換する処理を行う、前記文字列検出部及びタグ付加部を有することを特徴とするタグ付き文書作成装置。」 4.対比 (1) 「ドキュメント情報」とは「ドキュメント」本体の情報を含みうる広範囲な意味を持つ一般的な用語であることを鑑みれば、 引用例発明の「原文書データ」は、 本願発明の「ドキュメント情報」に相当する。 (2) 引用例の上記(キ)の「準備の手順は図5のごとくである。先ずステップS1において、原文書の文書構造と、区切りとなる「キーワード」を分析する。ここでは図2の原文書の雛形から‘日付=’や‘【報告】’など、文書の意味内容の区切りとなるキーワードを拾い出し、キーワードで区切られる文書要素を特定し、文書要素間の関係を調べて文書の構造を検討する。次にステップS2において、文書要素の意味内容(あるいは文書要素に結びつけられる何かの属性)を表示するタグを定めて、文書要素間の関係を図3のような文書構造図に書き表す。次にステップS3にて、文書構造図図3を元に変換対応テーブルを作成する。・・・(中略)・・・変換対応テーブルは図1のような2次元の表である。第1列と第2列はデリミタ部であり、文書の区切りであるデリミタ文字列を置く。・・・(中略)・・・。変換対応テーブルの第3列から右側はタグを置く部分であるタグ部である。各デリミタに対応したタグをそのデリミタと同じ行のそのタグの階層レベルに応じた適切な列のセルに置く。・・・」という記載から、 「文書構造図」を元に作成される「デリミタ」が(文書要素の種別だけでなく)文書の「構造」の「種別」も表していることは明らかであることから、 引用例発明の「XML文書を構成する文書要素の種別を日本語で記載したデリミタ」は、 本願発明の「XML文書を構成する要素の種別を日本語で記載した構造種別」に相当する。 (3) 引用例発明の「原文書データを入力することによりXML文書を作成するためのタグ付き文書作成装置」は、 本願発明の「ドキュメント情報を入力することによりXML文書を作成するためのXML文書作成装置」に相当する。 (4) 引用例発明の「XML文書のタグとXML文書を構成する文書要素の種別を日本語で記載したデリミタとを対応付けした変換対応テーブル」は、文書型定義(DTD:Document Type Definition)に関する変換対応テーブルの一種であることを鑑みれば、 引用例発明の「XML文書のタグとXML文書を構成する文書要素の種別を日本語で記載したデリミタとを対応付けした変換対応テーブル」と、 本願発明の「XML文書のタグとXML文書を構成する要素の種別を日本語で記載した構造種別とを対応付けするとともに、タグ属性と前記構造種別の属性を日本語で記載した属性種別とを対応付けしたDTD変換テーブル」とは、 「XML文書のタグとXML文書を構成する要素の種別を日本語で記載した構造種別とを対応付けしたDTD変換テーブル」という点で一致し、 本願発明では、(XML文書のタグとXML文書を構成する要素の種別を日本語で記載した構造種別とを対応付けするだけでなく)タグ属性と前記構造種別の属性を日本語で記載した属性種別とを対応付けしたDTD変換テーブルであるのに対し、 引用例発明では、そのようなDTD変換テーブルを開示していない点、 で相違する。 (5) 引用例発明の「入力された原文書データに関して、XML文書のタグとXML文書を構成する文書要素の種別を日本語で記載したデリミタとを対応付けした変換対応テーブルに基づいて、デリミタを、文字列検出部及びタグ付加部により対応するタグに変換する処理を行う、前記文字列検出部及びタグ付加部」と、 本願発明の「入力されたドキュメント情報に関して、XML文書のタグとXML文書を構成する要素の種別を日本語で記載した構造種別とを対応付けするとともに、タグ属性と前記構造種別の属性を日本語で記載した属性種別とを対応付けしたDTD変換テーブルに基づいて、構造種別と属性種別とを、DTD変換部により対応するタグとタグ属性とに変換する処理を行う前記DTD変換部」とは、 「入力されたドキュメント情報に関して、XML文書のタグとXML文書を構成する要素の種別を日本語で記載した構造種別とを対応付けしたDTD変換テーブルに基づいて、構造種別を、変換部により対応するタグに変換する処理を行う前記変換部」という点で一致し、 ・本願発明では、(XML文書のタグとXML文書を構成する要素の種別を日本語で記載した構造種別とを対応付けするだけでなく)タグ属性と前記構造種別の属性を日本語で記載した属性種別とを対応付けしたDTD変換テーブルに基づいて、属性種別を、変換部により対応するタグ属性とに変換する処理」も行っているのに対し、 引用例発明では、DTD変換テーブルがタグ属性と前記構造種別の属性を日本語で記載した属性種別までも対応付けるものではなく、属性種別を、変換部により対応するタグ属性とに変換する処理を行っていない点、 ・本願発明の「変換部」は「DTD変換部」であるのに対し、 引用例発明の「変換部」は「文字列検出部及びタグ付加部」である点、 で相違する。 (6) 以上のことから、本願発明と引用例発明とは、 「ドキュメント情報を入力することによりXML文書を作成するためのXML文書作成装置において、 入力されたドキュメント情報に関して、XML文書のタグとXML文書を構成する要素の種別を日本語で記載した構造種別とを対応付けしたDTD変換テーブルに基づいて、構造種別を、変換部により対応するタグに変換する処理を行う前記変換部を有することを特徴とするXML文書作成装置。」 という点で一致し、 (相違点1) 本願発明では、(XML文書のタグとXML文書を構成する要素の種別を日本語で記載した構造種別とを対応付けするだけでなく)タグ属性と前記構造種別の属性を日本語で記載した属性種別とを対応付けしたDTD変換テーブルに基づいて、属性種別を、変換部により対応するタグ属性とに変換する処理」も行っているのに対し、 引用例発明では、DTD変換テーブルがタグ属性と前記構造種別の属性を日本語で記載した属性種別までも対応付けるものではなく、属性種別を、変換部により対応するタグ属性とに変換する処理を行っていない点、 (相違点2) 本願発明の「変換部」は「DTD変換部」であるのに対し、 引用例発明の「変換部」は「文字列検出部及びタグ付加部」である点、 で相違する。 5.判断 (1)相違点1について XML文書において、「タグ」に結び付けられる「タグ属性」を備えることが可能であることは、情報処理分野における技術常識である。 また、引用例の上記(キ)の「準備の手順は図5のごとくである。先ずステップS1において、原文書の文書構造と、区切りとなる「キーワード」を分析する。ここでは図2の原文書の雛形から‘日付=’や‘【報告】’など、文書の意味内容の区切りとなるキーワードを拾い出し、キーワードで区切られる文書要素を特定し、文書要素間の関係を調べて文書の構造を検討する。次にステップS2において、文書要素の意味内容(あるいは文書要素に結びつけられる何かの属性)を表示するタグを定めて、文書要素間の関係を図3のような文書構造図に書き表す。次にステップS3にて、文書構造図図3を元に変換対応テーブルを作成する。・・・(中略)・・・変換対応テーブルは図1のような2次元の表である。第1列と第2列はデリミタ部であり、文書の区切りであるデリミタ文字列を置く。・・・(中略)・・・。変換対応テーブルの第3列から右側はタグを置く部分であるタグ部である。各デリミタに対応したタグをそのデリミタと同じ行のそのタグの階層レベルに応じた適切な列のセルに置く。・・・」という記載から(下線は当審にて付加)、 引用例の「デリミタ」として採用されるものは、「文書要素の意味内容」だけでなく、「文書要素に結びつけられる何かの属性」でも良いのであるから、 引用例は、XML文書の「タグ」(「構造種別」に対応する情報)に結び付けられる「タグ属性」(すなわち、「構造種別の属性」に対応する情報)への変換を示唆しているといえる。 したがって、引用例発明において、XML文書のタグへの変換だけでなく、XML文書のタグ属性への変換も可能とするべく、 「XML文書のタグとXML文書を構成する要素の種別を日本語で記載した構造種別とを対応付けした変換テーブルに基づいて、構造種別を、変換部により対応するタグに変換する処理」を行うのと同様に、 「XML文書のタグ属性と前記構造種別の属性を日本語で記載した属性種別とを対応付けした変換テーブルに基づいて、属性種別を、変換部により対応するタグ属性に変換する処理」も行うようにすること、 すなわち、DTD変換テーブルを、XML文書のタグとXML文書を構成する要素の種別を日本語で記載した構造種別とを対応付けするだけでなく、タグ属性と前記構造種別の属性を日本語で記載した属性種別をも対応付けしたDTD変換テーブルとし、それに基づいて、属性種別を、変換部により対応するタグ属性とに変換する処理も行うようにすることは、当業者が容易に想到し得ることである。 (2)相違点2について ある機能をひとつの手段によって実現したり、ある機能を複数の手段によって実現したりすることは、情報処理分野における常套手段である。 したがって、引用例発明において、変換に関する処理を、複数の手段(文字列検出部及びタグ付加部)によって実現する代わりに、ひとつの手段(DTD変換部)によって実現することは、当業者が容易に想到し得ることである。 6.付記 (1) 審判請求人は、平成21年9月7日付け回答書において、 「すなわち、本願請求項1に記載の発明では、文章(テキスト)、図、表により表現されたリソースを、日本語の構造種別により分けて管理しておりますが(合わせて本願の図10、図22等をご参照願います。)、引用文献1には、1つのテキスト文書を超えて、日本語で記載したXMLタグで管理しようとする発想が無い点が全く異なります。」 及び「すなわち、1つの文章について日本語のキーワードを用いてXML文書を簡便に作成するという構成が引用文献1の特徴であるとすれば、本願請求項1等に記載の発明では、個々の文章を簡便に作成するよりも、章・節、文章、画像、表などのリソースを組み合わせた複雑な階層・構造のXML文書をより簡便に作成できるという、引用文献等とは全く異なる大きな特徴を有するものであります。」 と主張している。 しかしながら、本願発明では、「ドキュメント情報」や「構造種別」について具体的な限定(例:文章(テキスト)、図、表という3種のリソースを前提とした複雑な階層・構造を有していること、1つのテキスト文書を超えて管理されること)は何らされていない。 したがって、審判請求人の主張は、特許請求の範囲の請求項1にある記載に基づくものではないといえる。 たとえそうでないとしても、文書(テキスト)というリソースだけでなく、図及び表というリソースを用いてドキュメントが構成されることは情報処理分野における技術常識であるから、 引用例発明において、文書(テキスト)というリソースを取り扱うだけでなく、図及び表というリソースも取り扱えるようにしたり、これらのリソースに対応できるように、複数階層に対応した「変換対応テーブル」(本願発明の「DTD変換テーブル」に略対応)を拡充したりすることは、当業者が容易に想到し得ることである。 (2) 審判請求人は、平成21年9月7日付け回答書において、 「さらに、請求項1等に記載の発明によれば、例えば複雑なXML文書をより簡便に作成できるという効果以外の効果として、「構造種別および属性種別を、一般的な言語、例えば日本語でより記載すれば、ユーザインターフェ イスがわかりやすくなる。」(0007段落)という発想に関しましても、引用文献等には開示も示唆もされておりません。」 と主張している。 しかしながら、引用例発明において「デリミタ」等に日本語が使えることから、日本のユーザにとって、ユーザインターフェイスがわかりやすくなっていることは明らかである。 なお、英語圏において開発されたプログラム(例:XML文書を扱えるOS、XML文書を扱えるアプリケーション・ソフトウエア、XML文書を扱えるプログラミング・ソフトウエア)や当該プログラムが扱うデータ(例:XML文書)は、英語圏のユーザが通常用いる英語を前提として仕様が定められることが多かったため、非英語圏(例:日本)のユーザの利便性を向上するために当該プログラム及びデータの仕様をローカライズしてきたこと(例:日本語対応にしてきたこと)は、情報処理分野における周知の技術的歴史的経緯である。 (例:マイクロソフト株式会社のWindowsやOfficeソフトウエアの日本語対応化、プログラミング言語の仕様の日本語化(参考:特開昭61-20115号公報には、「PRINT」命令が「印刷」命令になっている。)) すなわち、情報処理分野における当業者であれば、英語圏発祥のXML技術を基礎とする引用例発明において「デリミタ」等に日本語が使えること(すなわち、引用例発明が日本語対応になっていること)という事実それ自体によって、日本のユーザの利便性を向上するという発想を内在したものとなっていることを自明に理解できる。 7.むすび したがって、本願発明は、引用例発明に基づいて、当業者が容易に発明をすることができたものであり、特許法第29条第2項の規定により特許を受けることができないから、他の請求項について検討するまでもなく、本願は拒絶されるべきものである。 よって、結論のとおり審決する。 |
審理終結日 | 2009-11-19 |
結審通知日 | 2009-11-24 |
審決日 | 2009-12-07 |
出願番号 | 特願2002-193851(P2002-193851) |
審決分類 |
P
1
8・
121-
Z
(G06F)
|
最終処分 | 不成立 |
前審関与審査官 | 今村 剛 |
特許庁審判長 |
田口 英雄 |
特許庁審判官 |
和田 財太 小曳 満昭 |
発明の名称 | XML文書作成システム |
代理人 | 平木 祐輔 |
代理人 | 今村 健一 |
代理人 | 今村 健一 |
代理人 | 平木 祐輔 |
代理人 | 渡辺 敏章 |
代理人 | 渡辺 敏章 |
代理人 | 渡辺 敏章 |
代理人 | 平木 祐輔 |
代理人 | 今村 健一 |