• ポートフォリオ機能


ポートフォリオを新規に作成して保存
既存のポートフォリオに追加保存

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 特許、登録しない。 G06F
審判 査定不服 4号2号請求項の限定的減縮 特許、登録しない。 G06F
管理番号 1194593
審判番号 不服2006-9655  
総通号数 113 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2009-05-29 
種別 拒絶査定不服の審決 
審判請求日 2006-05-11 
確定日 2009-03-19 
事件の表示 平成10年特許願第368280号「構造化文書作成方法、構造化文書作成装置及び構造化文書作成用プログラムを格納した記憶媒体」拒絶査定不服審判事件〔平成11年10月 8日出願公開、特開平11-272667〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由 1.手続の経緯
本願は、平成10年12月24日(パリ条約による優先権主張1997年12月23日、米国)の出願であって、平成16年11月12日付けで拒絶理由通知がなされ、平成17年1月12日付けで手続補正がなされたが、平成18年4月5日付けで拒絶査定がなされ、これに対し、同年5月11日に拒絶査定不服審判の請求がなされるとともに、同年6月8日付けで手続補正がなされたものである。

2.平成18年6月8日付けの手続補正についての補正却下の決定
[補正却下の決定の結論]
平成18年6月8日付けの手続補正を却下する。

[理由]
(1)補正の目的の適否について
本件手続補正の目的が、平成18年法律第55号改正附則第3条第1項によりなお従前の例によるとされる同法による改正前の特許法第17条の2第4項の規定に適合するか否かを検討する。

上記本件手続補正により、特許請求の範囲の請求項1は、
「SGMLおよびHTMLを処理するコンピュータで実行可能な方法であって、
(a)SGMLの変換用要素を選択する過程と、
(b)前記SGMLの要素に対応するHTMLの要素をユーザによって入力する過程と、
(c)前記HTMLを処理し、前記SGMLの要素を対応する前記HTMLの要素に変換するルールを作成する過程と、
(d)前記ルールを出力する過程と、
を備える構造化文書作成方法であって、前記ルールは前記SGMLに対応する前記HTMLを割り当てないルールを含むことを特徴とする構造化文書作成方法。」
との記載から、
「SGMLおよびHTMLを処理するコンピュータで実行可能な方法であって、
(a)SGMLの変換用要素を選択する過程と、
(b)前記SGMLの要素に対応するHTMLの要素の入力を受け付ける過程と、
(c)前記HTMLの要素を処理し、前記SGMLの要素を対応する前記HTMLの要素に変換するルールを作成する過程と、
(d)前記ルールを出力する過程と、
を備える構造化文書作成方法であって、
前記ルールは、前記HTMLの要素が前記SGMLの要素に対応しない場合、前記SGMLのタグを削除して前記SGMLから前記HTMLへの変換後の表示をしないようにする場合と、前記SGMLのタグをマップしないようにすることで前記SGMLから前記HTMLへの変換後の表示を行うようにする場合とを選択可能である、
ことを特徴とする構造化文書作成方法。」
との記載に補正された。

上記補正内容は、「(b)前記SGMLの要素に対応するHTMLの要素をユーザによって入力する過程」を「(b)前記SGMLの要素に対応するHTMLの要素の入力を受け付ける過程」に補正(以下、「補正1」という。)することと、「前記ルールは前記SGMLに対応する前記HTMLを割り当てないルールを含む」を「前記ルールは、前記HTMLの要素が前記SGMLの要素に対応しない場合、前記SGMLのタグを削除して前記SGMLから前記HTMLへの変換後の表示をしないようにする場合と、前記SGMLのタグをマップしないようにすることで前記SGMLから前記HTMLへの変換後の表示を行うようにする場合とを選択可能である」に補正(以下、「補正2」という。)することを含むものである。
上記補正1については、「前記SGMLの要素に対応するHTMLの要素」の入力を、補正前では「ユーザによって」行うとされていたものを、補正後においては、単に「受け付ける」とするものであって、特許請求の範囲を拡張するものであるから、特許請求の範囲の減縮に該当するとは認められない。
また、上記補正2については、補正前の「前記SGMLに対応する前記HTMLを割り当てないルール」を補正後において限定するものではなく、「前記SGMLのタグを削除して前記SGMLから前記HTMLへの変換後の表示をしないようにする場合」と「前記SGMLのタグをマップしないようにすることで前記SGMLから前記HTMLへの変換後の表示を行うようにする場合」という二つの「表示」の態様を「選択可能」とするものであり、特許請求の範囲を変更するものであるから、特許請求の範囲の減縮に該当するとは認められない。
よって、補正後の請求項1に記載された発明は、補正前の請求項1に記載された発明を特定するために必要な事項を限定して特許請求の範囲の減縮をしたものとは認められず、上記請求項1に係る補正は、平成18年法律第55号改正附則第3条第1項によりなお従前の例によるとされる同法による改正前の特許法第17条の2第4項第2号の規定に適合しない。

さらに、特許請求の範囲の請求項2及び3についても、上記補正1及び補正2と同様の補正がなされており、補正後の請求項2及び3に記載された発明は、補正前の請求項2及び3に記載された発明を特定するために必要な事項を限定して特許請求の範囲の減縮をしたものとは認められず、請求項2及び3に係る補正は、平成18年法律第55号改正附則第3条第1項によりなお従前の例によるとされる同法による改正前の特許法第17条の2第4項第2号の規定に適合しない。

また、特許請求の範囲の請求項1乃至3に係る補正が、平成18年法律第55号改正附則第3条第1項によりなお従前の例によるとされる同法による改正前の特許法第17条の2第4項第1号の請求項の削除、第3号の誤記の訂正、第4号の明りょうでない記載の釈明に該当するものでないことは明らかである。

(2)むすび
よって、本件手続補正は、平成18年法律第55号改正附則第3条第1項によりなお従前の例によるとされる同法による改正前の特許法第17条の2第4項に違反するものであり、特許法第159条第1項において読み替えて準用する同法第53条第1項の規定により却下されるべきものである。

3.補正却下の決定を踏まえた検討
(1)本願発明
平成18年6月8日付けの手続補正は、上記のとおり却下されたので、本願の請求項1に係る発明は、平成17年1月12日付け手続補正書の特許請求の範囲の請求項1に記載されたとおりの次のものと認める。(以下、「本願発明」という。)
「SGMLおよびHTMLを処理するコンピュータで実行可能な方法であって、
(a)SGMLの変換用要素を選択する過程と、
(b)前記SGMLの要素に対応するHTMLの要素をユーザによって入力する過程と、
(c)前記HTMLを処理し、前記SGMLの要素を対応する前記HTMLの要素に変換するルールを作成する過程と、
(d)前記ルールを出力する過程と、
を備える構造化文書作成方法であって、前記ルールは前記SGMLに対応する前記HTMLを割り当てないルールを含むことを特徴とする構造化文書作成方法。」

(2)引用例及び周知例
これに対して、原査定の拒絶の理由に引用された特開平9-231220号公報(以下、「引用例」という。)、及び原査定の備考欄において周知例として引用された特開平9-265431号公報(以下、「周知例」という。)には、それぞれ、図面とともに次の事項が記載されている。

(引用例)
A.「【0001】
【発明の属する技術分野】この発明は、元の文書から別の文書を変換して生成する方法、特に、文書の論理構造に注目して文書の変換、生成を行う方法に関する。」

B.「【0009】
【課題を解決するための手段】
(1)本発明の文書変換生成方法は、文書の論理構造に注目して変換元文書を変換し、変換先文書を生成する方法であり、変換元文書を取得する変換元文書取得工程と、変換元文書をその論理構造を構成する要素に分解し、各要素に対応する実データを個別に保持する要素別実データ保持工程と、変換先文書の論理構造を取得する目的論理構造取得工程と、変換先文書の論理構造を維持しながら、その各要素に対し、前記変換元文書に含まれる要素の中で対応させるべきものの指定を受け付ける対応指定受付工程と、指定された対応に従い、前記変換先文書の要素ごとに前記変換元文書全体から必要な実データを一括して読み出し、これをその要素の実データとしてその要素の下に格納していく文書変換工程とを含む。
【0010】この構成において、まず変換元文書が取得される。「文書」とは、文字データやイメージデータで構成されるものだけでなく、論理構造の記述が可能である限り、いかなる情報伝達単位を含んでよい。例えば文字にリンクされた音によって文書の一部を構成してもよい。変換元文書の「取得」とは、入力または作成された変換元文書をデータの形で持つことをいう。
【0011】つづいて、変換元文書が要素に分解され、各要素に対応する実データが個別に保持される。前記領収書の例では、領収書文書を「金額」「内訳」等の要素に分類し、「金額」であれば「1000円」などの実際の値をこの金額の実データとして保持する。
【0012】一方、これと並行して変換先文書の論理構造も取得される。この論理構造を「目的論理構造」と呼ぶ。この後、目的論理構造を維持しながら、その各要素に対し、変換元文書に含まれる要素の中で対応させるべきものの指定が受け付けられる。「目的論理構造を維持しながら」とは「その論理構造を崩すことなく」の意味であり、変換先文書の論理構造を基礎として処理を進めることを意味する。より具体的には、変換の都合等によって、目的論理構造における要素の出現順序と要素の属する階層を変更しないことをいう。例えば、目的論理構造が「請求書」であり、この下に「請求の対象」と「請求金額」があるとき、「請求書」を最上位の階層1とすれば、その下の「請求の対象」と「請求金額」は階層2となる。出現順序は、「請求書」→「請求の対象」→「請求金額」である。従って、上述の領収書を変換元文書、この請求書を変換先文書とする場合、以下のように、目的論理構造をベースとして対応を指定する(これは対応の一例である)。
【0013】1.出現順序1番の「請求書」に対して変換元文書の「領収書」
2.出現順序2番の「請求の対象」に対して変換元文書の「内訳」
3.出現順序3番の「請求金額」に対して変換元文書の「金額」
最後に、指定された対応に従い、変換先文書の要素ごとに前記変換元文書全体から必要な実データを一括して読み出し、これをその要素の実データとしてその要素の下に格納していく。例えば、要素「請求の対象」の場合、変換元文書の「内訳」という要素が持つすべての実データを拾い出し、これを「請求の対象」の下に格納する。これにより、例えば「今月納品分」という文字列データが変換先文書に移動または複写される。この処理は目的論理構造を維持しながら行われるため、最終的に得られる文書は、
(階層1)「請求書」とその実データ
(階層2)「請求の対象」とその実データ
(階層2)「請求金額」とその実データ
となる。この結果、所期の変換が実現する。」

C.「【0019】(4)本発明のある態様では、前記対応指定受付工程はさらに、変換先文書の要素の属性に対し、前記変換元文書に含まれる要素の属性中で対応させるべきものの指定を受け付け、前記文書変換工程はさらに、指定された対応に従い、前記変換先文書の要素の属性に対して前記変換元文書の要素の属性を付与していく。」

D.「【0023】(7)一方、本発明のある態様では、前記対応指定受付工程はグラフィカルユーザインタフェイス(以下GUI)によって前記指定を受け付けるものであり、該工程は、変換元文書の論理構造と変換先文書の論理構造をならべて表示する工程と、これら2つの論理構造からそれぞれ1つの要素が指定されたとき、これらの要素間に設定すべき対応の詳細設定画面を表示する工程と、前記詳細設定画面における設定作業が終了したとき、その詳細設定内容を取り込んで変換指定ファイルを生成する工程を含む。
【0024】この態様では、まず変換元文書、変換先文書それぞれの論理構造が画面に現れる。論理構造は木構造などで表示すればよい。この画面を見ることにより、対応付けるべき要素が容易に把握される。つぎに、これら2つの論理構造からそれぞれ1つの要素が指定される。これは、少なくとも1つずつの要素が指定されれば足りる意味であり、実際には合計で3以上の要素を指定してもよい。いずれにせよ、この時点で、これらの要素に対応付けがなされることが確定する。
【0025】ここで、これらの要素間に設定すべき対応の詳細設定画面が表示される。詳細設定とは、前述の論理演算を条件とする場合の条件式の設定などをいう。詳細設定画面における設定作業が終了すれば、その内容を取り込んだ変換指定ファイルが生成される。このファイルは、対応関係と条件などが記述されているだけであり、プログラムを記述してなるものではない。この後、このファイルを逐次読み出し、その詳細設定に従って前記実データの読み出しと格納を実行する。このファイルを一回作成すれば、変換元文書、変換先文書それぞれの論理構造が同じ場合にはいつでもこのファイルを利用することができる。」

E.「【0026】
【発明の実施の形態】本発明の好適な実施形態を適宜図面を参照しながら説明する。ここでは文書としてSGML文書、その論理構造である文書型定義としてDTDを例に本発明の実施形態を説明する。
【0027】実施形態1.ここでは、本実施形態による処理を説明する前に、まず変換元文書と変換先文書の内容を説明する。
【0028】[1]変換元文書
図1は変換元文書のDTD(以下「変換元DTD」ともいう)を示す図である。同図において、ELEMENTは各要素名を、またATTLISTは属性とその属性値を表示する。同図第1行のごとく、このDTDでは「報告書1」の後に、(日付,作成者,本文,付録,関連部署)と表記されている。これは「報告書1」という最上位要素のもとに日付等の要素が従属し、これらの要素が必ず左から順に現れることを示す。「付録」に付される?記号は、その要素が0または1回に限って現れることを示す。
【0029】第2行では「報告書1」の属性として「秘区分」が4つの属性値、極秘、秘、社外秘、指定なしを伴う形で定義されている。これら4つの区分の間に存在する縦線はいずれか1つを選択するオア記号であり、行末の#REQUIREDはその選択行為が必須であることを示す。第3行の「日付」の後の#PCDATAは、実際に文字列データが入力される部分を示す。第5行の「本文」には「段落」と「リスト」が従属しており、+記号は段落が1回以上、*記号はリストが0回以上出現することを示す。リストとはいわゆる箇条書き形式の表示で、第7行に示すとおり、リストが存在するときは必ず実体である「項目」が1回以上現れる。第5行でも縦線はオア記号であり、まず(段落+|リスト*)は、次の出現状況を満たす。
【0030】「段落とリストはいずれか一方が出現する。ただし、段落は1回以上、リストは0回以上出現」実際にはこの()の外にさらに+がついているため、この状況自体が1回以上出現する。結果的に段落とリストは、段落が1回以上出現することを前提として、順不同で任意の回数出現しうる。
【0031】一方、図2は図1のDTDを木構造で表した図である。木構造では、いずれか一方が出現する「段落」と「リスト」は「本文」に斜線で結線され、それ以外の要素は必ず左から順に現れる。ここでは、「報告書1」が階層1、「日付」などが階層2などとなり、最下位は「項目」の階層4である。要素の下に存在する「P」という記号は、#PCDATAを示している。
【0032】図3は図1のDTDに従う変換元文書、すなわち変換元のSGML文書を示す図である。<>はSGMLの規則に従って付けられるマークで、<xxx>がxxxという要素の開始タグ、</xxx>が終了タグを示す。<xxx>と</xxx>の間にxxxの実データが記述されるか、xxxに子要素があればこれを入れ子構造で記述する。同図では、<段落>の実データとして文字列AAA、BBB、EEE、<リスト><項目>の実データとして文字列CCC、DDDが存在する。
【0033】[2]変換先文書
一方、図4は目的論理構造である変換先文書のDTD(以下「変換先DTD」ともいう)を示す図である。同図第1、2行からわかるように、この報告書2は「前付け」「本文」「後付け」からなり、「前付け」が子要素として「日付」「送付先」「著者」を持つ。この部分ですでに図1のDTDと構造が違う。同図最終3行の「後付け」「付録」「参考文献」についても同様である。図5は図4のDTDを木構造で表した図であり、図2との構造の相違を容易に把握することができる。
【0034】図6は変換の結果最終的に得られる変換先文書を示す図で、本実施形態の目的は図3のSGML文書を変換して図6のSGML文書を生成することにある。なお、SGMLの記述方法については、例えば「SGMLのかきかた」(1994年12月発行所(株)麻布プロデュース)などに掲載されている。
【0035】[3]構成
図7は本実施形態を実現するためのシステム構成図である。同図において円筒形はデータを保持する構成、一方矩形は実際に処理を行うソフトウエアモジュールを表している。本実施形態を実現するためのハードウエアは、例えばパーソナルコンピュータ(以下PC)とデータを格納するファイル装置、変換結果を確認するためのプリンタなどでよく、特別な装置を必要としない。以下、本実施形態の処理はこのPC上で行うものとする。」

F.「【0040】[4]処理動作
図3の文書から図6の文書を変換生成する一連の処理を図7をもとに説明する。
【0041】まずユーザは、変換元文書を文書データ保持部1から検索する。検索は、例えば「報告書」などの文書の類型タイトルや、作成時期、作成者、文書に含まれる特定のキーワード等をもとに行う。変換元文書が見つかればこれをPCのメモリに格納し、その変換元DTDを文書構造保持部2から読み出して同様にメモリに格納する。
【0042】つづいて、変換元文書と変換元DTDを入力ファイルとして文書構造パーサ3を起動する。文書構造パーサ3では、図3の変換元文書を先頭から読み取り、記述のいずれの部分が要素名、属性、属性値、実データ(文字列データ)であるかを、DTDに照合しながら判断し、これらに異なる記号を付して出力していく。この処理を変換先文書のすべての行が終了するまで繰り返し行う。パーサの出力は解析済みデータ保持部4に格納される。
【0043】図8は文書構造パーサ3による解析の結果得られた解析済みデータを示す図である。データの出力形式はパーサの種類によりさまざまであるが、ここではESISという形式で出力している。同図のおいて、「(」はタグの開始、「)」はタグの終了、「A」につづく文字は属性、「TOKEN」につづく文字はその属性に関する属性値、「-」に導かれる文字列が実データを示している。
【0044】要素別分類処理部5は解析済みデータ保持部4から解析済みデータを読み出し、要素別実データと要素情報を抽出する。前者は図8のデータを行ごとに走査し、「-」に導かれる文字列を抽出することで得られる。図9は要素別実データを示す図であり、ここでは抽出された実データに対し、出現した順にデータ1?9のヘッダ情報を付加している。一方、要素情報についても同様に、図8のデータを行ごとに走査し、先頭の記号が「(」「)」であればその向きに従って階層の深度を判断し、各要素の階層と親子関係に関する情報を取得していく。図10はこうして得られた要素情報を示す図であり、要素名、親要素名、さらに親があればその名称といった親子関係とその属性情報、および当該要素の実データの格納先情報を持つ。格納先情報は、要素情報を抽出する際に、「-」の出現回数を計数することによって取得することができる。こうして得られた要素情報と要素別実データは、それぞれ要素情報保持部7、要素別実データ保持部6に格納される。
【0045】構造変換処理部8は、要素情報、要素別実データ、変換指定ファイルを参照して変換処理を行う。図11は作成された変換指定ファイルの例、図12は作成途上の変換指定ファイルの状態をそれぞれ示す図である。変換指定ファイルは変換先DTDをベースにユーザによって作成されるもので、作成の手順は以下のとおりである。なお、変換先DTD自身は、すでに文書構造保持部2に存在するときはこれを読み出して用い、存在しないときは別途作成する。
【0046】(1)要素名とその階層の書き出し
図2の木構造から図12の状態を作成する。これは単に、要素名をその階層とともに表示していくことで得られる。例えば「報告書2」は階層1であるため、これを、(1 報告書2
と記述する。階層1の要素は他にないため階層2に移り、木構造の記述規則どおり、左から順に同様の処理を行う。「前付け」は子要素を持つため、まず「日付」等の子要素を書き出した上で、次の「本文」に移行する。以下同様である。
【0047】(2)要素間の対応付け
実際の変換処理に用いるべき対応付けの指定を行う。例えば、変換元DTDの要素Sと変換先DTDの要素Tとの間で対応付けがなされた場合、構造変換処理部8において、要素Sの実データが要素Tの実データとして付与されることになる。対応付けのためにユーザは、図2および図5のDTDを見比べることにより、要素間の対応を見い出す。図13はユーザが図2および図5のDTD間に指定しようと考える対応関係を示す図である。これを、
変換先DTDの要素←変換元DTDの要素
の順で表現すれば、ユーザは以下の対応付けを行う。
【0048】
1.日付 ← 日付
2.送付先 ← 関連部署
3.著者 ← 作成者
4.本文の段落 ← 本文の段落
5.本文のリストの項目 ← 本文のリストの項目
6.付録の段落 ← 付録
いま、すでに図12の状態でこれらの対応のうち左側の要素が表示されているので、右側の要素を図12の対応要素に組み込んでいけばよい。組み込みの際、同じ要素名(例えば段落)が2回以上存在しうるため、最上位階層から/を用いて階層を明示しながら要素名を書き込む。例えば、6.の場合、図12の下から2行目の
(4 段落
の個所に、
<報告書1/付録
と書き込めばよい。ここで「<」は、実データを読んで取り込む指示記号である。この対応付けを1?6に対して行う。つづいて変換先DTDの要素のうち、要素群を指定する。ここでは「本文」の中の「段落」「リスト」「項目」がそれに当たるため、図11において、
(3. 段落
:
(4. 項目
というように、「.」をつけて要素群の範囲を明示する。なお、図11の最下行の”学会予稿集”は、変換元DTDに対応する要素がないため、別途キーボードから入力した文字列である。」

G.「【0057】1.SGML以外への応用
本実施形態ではSGML文書と文書型定義DTDについて説明した。しかし、論理構造を持つ文書であれば、これら以外のいかなる文書およびその論理構造の組合せに対しても本実施形態は容易に適用可能である。」

H.「【0063】実施形態2.実施形態1では、変換元DTDと変換先DTDの比較から対応の指定を行った。実施形態2では、この作業の効率改善のために、変換指定ファイル作成用のGUIを利用する文書変換生成方法を説明する。
【0064】[1]構成
このGUIを実現するために本実施形態は、おもに以下のプログラムモジュールを持つ。
【0065】(1)変換元DTDと変換先DTDを木構造に変換するモジュール
(2)これらの木構造をPCの画面にならべて表示するモジュール
(3)これらの木構造からそれぞれ1つの要素がクリックされたとき、これをアクションとして受け取るモジュール
(4)このアクションを解釈し、これらの要素間に設定すべき対応の詳細設定画面を表示するモジュール
(5)この詳細設定画面における設定作業が終了したとき、その詳細設定内容を取り込んで変換指定ファイルを生成するモジュール
[2]処理動作
図16、17は処理中の特定場面で画面に表示されるGUIを示す図である。処理の流れは以下のとおりである。
【0066】(1)木構造の表示
ユーザが変換元DTDと変換先DTDを決定したとき、これらの木構造が画面に表示される。これは図2、図5の木構造が同一画面に表示されると考えればよい。この状態でPCはユーザによる要素の選択待ち状態になる。
【0067】(2)詳細設定画面の表示
ユーザが図2の「報告書1」と図5の「報告書2」をクリックすると、それぞれ図16、17に示す表示が画面に現れる。図16の要素名100には「報告書1」、属性名101には「秘区分」が表示され、属性値102には「極秘」「秘」「社外秘」が選択可能な状態で表示される。一方、図17の要素名200には「報告書2」、属性名201には「タイプ」が表示され、属性値202には「部内」「社内」「指定なし」が選択可能な状態で表示される。さらに同図には、条件の組合せを記述するための論理和ボタン203、論理積ボタン204、1つの条件の入力の終了を示す終了ボタン205、設定中の条件を逐次表示する条件表示欄206、設定をキャンセルするキャンセルボタン207、設定を登録する登録ボタン208が設けられている。
【0068】この画面において、まず図17の「部内」をクリックし、つづいて図16の「極秘」、図17の「論理和」、図16の「秘」、終了ボタン205の順にクリックする。この時点で図11の第2行、
[報告書1]秘区分=極秘|[報告書1]秘区分=秘>[報告書2]タイプ=部内
が設定される。つぎに図17の「社内」を選択し、同様の手順で、
[報告書1]秘区分=社外秘>[報告書2]タイプ=社内
が設定される。以下同様で、最終的に登録ボタン208を押したとき、設定内容を読み出し、変換指定ファイルが生成される。なお、属性値が1つのみ存在する場合は属性値102、202の欄にはその属性値のみが表示され、例えば、
[報告書1]属性値=[報告書2]属性値
という形の変換指定が可能となる。
【0069】つづいて、実データの対応指示に移る。まず図2と図5の「日付」をそれぞれクリックする。このとき図10の要素情報における親子関係が参照され、階層経路が明らかになるため、図11の、
(3 日付 < 報告書1/日付
が生成される。以下、同様である。
【0070】以上本実施形態によれば、変換指定ファイルの作成がさらに容易になるため、ユーザの便宜を図ることができる。」

上記A?Hの記載及び関連する図面を参照すると、次のことがいえる。

(あ)上記Eの段落【0026】に「・・・ここでは文書としてSGML文書、その論理構造である文書型定義としてDTDを例に本発明の実施形態を説明する。」と記載され、また、段落【0035】に「・・・本実施形態を実現するためのハードウエアは、例えばパーソナルコンピュータ(以下PC)とデータを格納するファイル装置、変換結果を確認するためのプリンタなどでよく、特別な装置を必要としない。以下、本実施形態の処理はこのPC上で行うものとする。」と記載されていることから、上記引用例に記載のものは、「SGMLを処理するコンピュータで実行可能な方法」に係るものであるということができる。

(い)上記Dの段落【0023】の「一方、本発明のある態様では、前記対応指定受付工程はグラフィカルユーザインタフェイス(以下GUI)によって前記指定を受け付けるものであり、該工程は、変換元文書の論理構造と変換先文書の論理構造をならべて表示する工程と、これら2つの論理構造からそれぞれ1つの要素が指定されたとき、これらの要素間に設定すべき対応の詳細設定画面を表示する工程と、前記詳細設定画面における設定作業が終了したとき、その詳細設定内容を取り込んで変換指定ファイルを生成する工程を含む。」との記載、及び上記Hに記載の「変換指定ファイル作成用のGUIを利用する」実施形態を参照すると、上記引用例に記載のものは、「SGMLの変換元DTDの要素に対応する変換先DTDの要素をユーザによって入力する過程」を備えるものであるということができる。

(う)上記Fの段落【0046】?【0048】の記載や上記Hの段落【0064】?【0069】に見られる「変換指定ファイル」の作成手順を参照すると、上記「変換指定ファイル」は、SGMLの変換元DTDの要素と変換先DTDの要素の対応付けを行いつつ作成されるものであり、その対応付けの過程で、当然、SGMLの変換元DTDと変換先DTDの要素の処理、すなわち「SGMLの処理」が行われるものであるということができる。。
よって、上記引用例に記載のものは、「SGMLを処理し、前記SGMLの変換元DTDの要素を対応する変換先DTDの要素に変換する変換指定ファイルを作成する過程」を備えるものであるということができる。

(え)上記Dの段落【0025】に「・・・その内容を取り込んだ変換指定ファイルが生成される。・・・この後、このファイルを逐次読み出し、その詳細設定に従って前記実データの読み出しと格納を実行する。・・・」と記載されており、上記引用例に記載のものは、「変換指定ファイルを読み出す過程」を備えるものであるということができる。

(お)「SGML文書」は「構造化文書」の一種であり、上記引用例に記載のものは、「構造化文書作成方法」に係るものであるということができる。

上記(あ)?(お)の事項を踏まえると、引用例には、実質的に次の発明が記載されているものと認められる。(以下、「引用例記載の発明」という。)
「SGMLを処理するコンピュータで実行可能な方法であって、
(a)SGMLの変換元DTDの変換用要素を選択する過程と、
(b)前記SGMLの変換元DTDの要素に対応する変換先DTDの要素をユーザによって入力する過程と、
(c)前記SGMLを処理し、前記SGMLの変換元DTDの要素を対応する前記変換先DTDの要素に変換する変換指定ファイルを作成する過程と、
(d)前記変換指定ファイルを読み出す過程と、
を備える構造化文書作成方法。」

(周知例)
I.「【0001】
【発明の属する技術分野】本発明は、ドキュメントの編集方法に係わり、特に、WWW(ワールドワイドウェブ)サーバでグラフィカルな画面を表現するページ記述言語HTML(ハイパーテキストマークアップランゲージ)で記述されたドキュメントを得るため電子文書標準化のための汎用マークアップ言語SGML(スタンダードジェネライズドマークアップランゲージ)で記述されたドキュメントを編集する方法に関する。」

J.「【0014】
【実施例】図4は、本発明の他の実施例のWWWシステムの構成図である。同図において、ドキュメント編集クライアント装置30と、サーバ装置40と、WWWブラウザ装置52は、例えば、LANのようなネットワーク50によって接続されている。
【0015】サーバ装置40のWWWサーバ部42は、WWWサーバプログラムにより構成され、ファイルシステム44内のデータをネットワーク50に向けて公開している。ドキュメント編集クライアント装置30は、本発明によるドキュメント編集装置からなり、WWWのホームページのドキュメントと、WWWのホームページへのリンク情報を表わすドキュメントを作成、編集し、HTML形式で記述されたドキュメントをネットワーク50と、サーバ装置40のWWWサーバ部42とを介してサーバ装置40のファイルシステム44に登録する。
【0016】WWWブラウザ装置52は、ネットワーク50と、サーバ装置40のWWWサーバ部42とを介して、サーバ装置40のファイルシステムに登録されているWWWのホームページ及びそのリンク情報を参照、ダウンロードする。上記例の場合に、ドキュメント編集クライアント装置30においてSGML形式のドキュメントを編集し、SGML形式のドキュメントをHTML形式のドキュメントに変換し、WWWのホームページのドキュメントとしてサーバ装置40のファイルシステム44に登録する処理を以下に説明する。
【0017】図4に示す如く、ドキュメント編集クライアント装置30は、ネットワークインタフェース部(或いは、ネットワークシステム)24を有し、サーバ装置40のファイルシステム44をドキュメント編集クライアント装置30に接続する。変換ルール格納部12には、例えば、CRTと、キーボードと、マウスと、スピーカー(図示しない)とによって構成されたユーザインタフェース部20を介して変換定義部14で作成された変換ルールが変換定義ファイルの形で格納されている。図5は、かかる変換定義ファイルの一例を示す図である。例えば、変換定義部14は、通常のテキストエディタによって構成することができる。
・・・(中略)・・・
【0022】変換定義ファイルは、好ましくは、ユーザが予め用途別に作成して変換ルール格納部12に格納される。SGMLの定義の変更、又は、出力すべきHTMLのレイアウト変更等の要求に応じて、ユーザは、ユーザインタフェース部20及び変換定義部14を介して変換ルール格納部12に格納された変換定義ファイルを修正し、或いは、別途新しい変換定義ファイルを作成する。
【0023】変換処理部16は、更に、上記のようにして変換すべきSGMLファイルが指定されると、ドキュメント格納部22から変換元のSGMLファイル、即ち、第1のドキュメントを読み出す。以下では、上記図6に示したSGML形式のドキュメントのファイルが指定された場合を想定する。
【0024】以下、図6のSGML形式の第1のドキュメントを、図5に示した変換定義ファイルに従ってHTML形式の第2のドキュメントに変換し、第2のドキュメントをサーバ装置40のファイルシステム44に登録するドキュメント編集クライアント装置30の変換処理動作を図8のフローチャートを参照して説明するドキュメント編集クライアント装置30の変換処理部30は、必要に応じてユーザから起動される(ステップ30)。変換処理部30は、ユーザインタフェース部20を介して図7に示した画面を表示し(ステップ32)、ユーザからの変換定義ファイルとSGMLファイル(“SAMPLE2.SGML”)の指定を受ける(ステップ34)。
【0025】利用者が開始ボタンをクリックすると、変換処理部30は、図5の変換定義ファイルをオープンし、分析処理を開始する。即ち、変換定義ファイルの〔WWWHOME〕セクションから出力すべきドライブを、〔HTML〕セクションからリンク情報を、〔INDEX〕セクションから書込み情報を取得する(ステップ36)。次いで、変換処理部30は、〔CONVERT〕セクションから変換のための命令を順次取込み、内部バッファ(図示せず)に格納する(ステップ38)。
【0026】次に、変換処理部30は、変換定義ファイルをクローズすると共に、SGMLファイルをオープンし(ステップ40)、上記内部バッファに格納された命令を順次に読み出し(ステップ42)、命令がCNV命令であるかどうかを比較し(ステップ44)、CNV命令であれば、CNV命令の第1引き数を第2引き数に置換する(ステップ46)。図5の変換定義ファイルの1行目のCNV命令の場合、<名称>が<TITLE>に置換される。命令がINS命令である場合、INS命令の引き数の情報が挿入される。図5の変換定義ファイルの2行目のINS命令の場合、「<CENTER>本製品に関するデータ</CENTER>」が挿入される。以下同様にして、内部バッファ中の命令が無くなるまでステップ42からステップ50までを繰り返す。
【0027】全ての命令の処理が終了すると、SGMLファイルはHTMLファイルに変換され、SGMLファイルがクローズされ、かつ、出力処理部18においてHTMLファイル名(“SAMPLE2.HTML”)が自動的に作成される(ステップ52)。図9は、上記変換処理によって得られたHTML形式のドキュメントのファイルを示す図である。
【0028】出力処理部18は、ネットワークインタフェース部24を介して上記〔path〕セクションから得られたディレクトリに上記得られたHTMLファイルを出力すると同時に、上記サーバ装置44のファイルシステム44からホームページファイルを読み込み、作成したHTMLファイル(“SAMPLE2.HTML”)へのリンク情報を追加した後、ファイルシステム44にもう一度設定する。図10は変換前のリンク先が指定されたHTMLホームページファイルの例を示す図であり、図11は変換後のリンク先が指定されたHTMLホームページファイルの例を示す図である。
【0029】以上の動作により、ユーザは、簡単な操作だけでSGML形式のドキュメントをHTML形式のドキュメントに変換し、かつ、WWWサーバのファイルシステムに登録すると共に、リンク情報を同時に更新することが可能になる。図12は本発明の他の実施例によるドキュメント編集装置の構成図である。図12のドキュメント編集装置と、図2のドキュメント編集装置との相違点は、以下の通りである。図12のドキュメント編集装置10は、変換ルールを作成する変換定義手段14が省かれている。更に、図12のドキュメント編集装置10において、図2の変換処理部16は、変換定義ファイル12を読み込み、分析した結果を内部バッファ19に設定する分析処理部15と、ドキュメント22を読み込み、内部バッファに設定された分析結果を順次ドキュメントに適用する編集処理部17とに分割されている。
【0030】上記説明では、SGML形式のドキュメントをHTML形式のドキュメントに変換する場合を例として説明したが、変換定義ファイルの内容を変更するだけで、SGML形式からSGML形式のドキュメントへの変換の場合の同様に編集することができる。」

上記I,Jの記載及び関連する図面を参照すると、次の技術が周知であるということができる。(以下、「周知技術」という。)
「ドキュメントの形式をSGML形式からHTML形式へと変換する変換ルールを作成して変換定義ファイルの形で変換ルール格納部に格納し、該格納された変換定義ファイルに基いて、SGML形式のドキュメントをHTML形式のドキュメントに変換すること。」

(3)対比
本願発明と引用例記載の発明とを対比すると、次のことがいえる。

(ア)「SGML」形式の文書も「HTML」形式の文書も、ともに「構造化文書」であることには変わりなく、本願発明と引用例記載の発明とは、ともに、「構造化文書を処理するコンピュータで実行可能な方法」に係るものである点で共通する。

(イ)引用例記載の発明における「SGMLの変換元DTDの変換用要素を選択する過程」と、本願発明における「SGMLの変換用要素を選択する過程」とは、「SGMLからなる変換元構造化文書の変換用要素を選択する過程」である点で一致するものである。

(ウ)同様に、引用例記載の発明における「SGMLの変換元DTDの要素に対応する変換先DTDの要素をユーザによって入力する過程」と、本願発明における「SGMLの要素に対応するHTMLの要素をユーザによって入力する過程」とは、「変換元構造化文書の要素に対応する変換先構造化文書の要素をユーザによって入力する過程」である点で共通する。

(エ)引用例記載の発明における「変換指定ファイル」は、引用例の上記Dの段落【0025】に「・・・対応関係と条件などが記述されている・・・」と記載されているように、「変換元構造化文書の要素」を対応する「変換先構造化文書の要素」に変換する「ルール」を記述するものであるであるということができる。
よって、本願発明と引用例記載の発明とは、「変換元構造化文書の要素を対応する変換先構造化文書の要素に変換するルールを作成する過程」を備える点で共通するということができる。

(オ)引用例記載の発明における「変換指定ファイルを読み出す過程」は、本願発明における「ルールを出力する過程」に相当する。

上記(ア)?(オ)の事項を踏まえると、本願発明と引用例記載の発明とは、次の点で一致し、また、相違するものと認められる。

(一致点)
本願発明と引用例記載の発明とは、ともに、
「構造化文書を処理するコンピュータで実行可能な方法であって、
(a)SGMLからなる変換元構造化文書の変換用要素を選択する過程と、
(b)前記変換元構造化文書の要素に対応する変換先構造化文書の要素をユーザによって入力する過程と、
(c)前記変換元構造化文書の要素を対応する変換先構造化文書の要素に変換するルールを作成する過程と、
(d)前記ルールを出力する過程と、
を備える構造化文書作成方法。」
である点。

(相違点)
相違点1:本願発明は、「SGMLおよびHTMLを処理するコンピュータで実行可能な方法」に係るものであって、「(b)変換元構造化文書の要素に対応する変換先構造化文書の要素をユーザによって入力する過程」及び「(c)変換元構造化文書の要素を対応する変換先構造化文書の要素に変換するルールを作成する過程」が、「(b)SGMLの要素に対応するHTMLの要素をユーザによって入力する過程」及び「(c)HTMLを処理し、SGMLの要素を対応するHTMLの要素に変換するルールを作成する過程」であるのに対し、引用例記載の発明は、「SGMLを処理するコンピュータで実行可能な方法」に係るものであって、上記(b)及び(c)の過程が、「(b)SGMLの変換元DTDの要素に対応する変換先DTDの要素をユーザによって入力する過程」及び「(c)SGMLを処理し、SGMLの変換元DTDの要素を対応する変換先DTDの要素に変換する変換指定ファイルを作成する過程」である点。

相違点2:「ルール」が、本願発明においては、「SGMLに対応するHTMLを割り当てないルールを含む」ものであるのに対し、引用例記載の発明においては、SGMLの変換元DTDの要素に対応する変換先DTDの要素を割り当てないルールを含むとはされていない点。

(4)判断
そこで、上記相違点1及び2について検討する。

(相違点1について)
引用例の上記Gの記載によれば、引用例記載の発明は、SGML文書以外のいかなる文書およびその論理構造の組合せに対しても容易に適用可能であるとされ、実際に、上記周知技術に見られるように、SGML形式の構造化文書を、作成した変換ルールに基いてHTML形式の構造化文書に変換する技術は周知である。
そして、SGML形式からHTML形式へ変換する変換ルールを作成する過程で、SGMLおよびHTMLの処理が行われることは、当然のことである。
してみれば、引用例記載の発明において、上記周知技術を参酌することにより、引用例記載の発明を「SGMLおよびHTMLを処理するコンピュータで実行可能な方法」に係るものとし、「(b)変換元構造化文書の要素に対応する変換先構造化文書の要素をユーザによって入力する過程」及び「(c)変換元構造化文書の要素を対応する変換先構造化文書の要素に変換するルールを作成する過程」を、「(b)SGMLの要素に対応するHTMLの要素をユーザによって入力する過程」及び「(c)HTMLを処理し、SGMLの要素を対応するHTMLの要素に変換するルールを作成する過程」とすることは、当業者が容易に想到し得ることである。

(相違点2について)
引用例の上記Fの段落【0048】には、「・・・なお、図11の最下行の”学会予稿集”は、変換元DTDに対応する要素がないため、別途キーボードから入力した文字列である。」との記載がなされている。
すなわち、上記記載によれば、変換先DTDに存在する要素であっても、変換元DTDには対応する要素がない場合には、変換元DTDに新たな要素を付け加えて変換先DTDの要素とするとされている。
してみれば、逆に、変換元DTDに存在する要素であっても、変換先DTDには対応する要素がない場合に、該当する変換元DTDの要素を変換先DTDに割り当てないようにすることは、当業者が容易に想到し得ることである。
そして、上記周知技術を参酌すれば、SGML形式の構造化文書に存在する要素であっても、HTML形式の構造化文書には対応する要素がない場合に、該当するSGML形式の構造化文書の要素をHTML形式の構造化文書に割り当てないようにすることは、当業者が容易に想到し得ることである。
よって、「ルール」を「SGMLに対応するHTMLを割り当てないルールを含む」ものとすることは、当業者が容易に想到し得ることである。

そして、本願発明の構成によってもたらされる効果も、引用例記載の発明及び上記周知技術から当業者ならば容易に予測することができる程度のものであって、格別のものとはいえない。

(5)むすび
以上のとおり、本願発明は、引用例記載の発明及び上記周知技術に基いて、当業者が容易に発明をすることができたものであるので、特許法第29条第2項の規定により特許を受けることができない。
したがって、本願は、他の請求項について検討するまでもなく、拒絶されるべきものである。
よって、結論のとおり審決する。
 
審理終結日 2009-01-15 
結審通知日 2009-01-20 
審決日 2009-02-02 
出願番号 特願平10-368280
審決分類 P 1 8・ 121- Z (G06F)
P 1 8・ 572- Z (G06F)
最終処分 不成立  
前審関与審査官 長 由紀子和田 財太  
特許庁審判長 長島 孝志
特許庁審判官 手島 聖治
真木 健彦
発明の名称 構造化文書作成方法、構造化文書作成装置及び構造化文書作成用プログラムを格納した記憶媒体  
代理人 酒井 宏明  

プライバシーポリシー   セキュリティーポリシー   運営会社概要   サービスに関しての問い合わせ