【事件の表示】
　平成　２年特許願第３１５６３１号「複数領域情報の連続置換処理方式」拒絶査定に対する審判事件［平成　４年　７月　１日出願公開、特開平　４−１８４６２０］について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯等
　本願は、平成２年１１月２０日の出願であって、平成７年１２月１３日付け拒絶理由通知に対して平成８年３月２５日付けで意見書及び手続補正書が提出され、該手続補正書が補正却下の決定がなされ、該決定に対し補正却下不服の審判がなされ、その決定が取り消されたものであって、「複数領域情報の連続置換処理方式」に関するものと認められる。
　
２．当審の拒絶理由
　当審において、平成１１年１１月１８日付けで次の通りの拒絶理由を通知し、期間を指定して意見書の提出を求めた。
　本出願は、明細書及び図面の記載が下記の点で不備のため、特許法第３６条第３項及び第４項に規定する要件を満たしていない。
　　　　　　　　　　　　　記
　明細書には、
　本願発明の概要として
　「ディスプレイ画面上に展開される複数の置換対象領域の持つ情報をそれぞれ別のものに置換する複数領域情報の連続置換方式に関し、
　連続置換処理を実現することで効率的に置換処理を実行できるようにすることを目的とし、
　ディスプレイ画面上に展開される複数の置換対象領域の持つ情報を管理する展開する展開情報管理部と、置換対象領域に設定されるべき情報を領域識別子と対応付けて管理する置換情報管理部と、展開情報管理部の管理する置換対象領域の領域識別子をキーにして置換情報管理部の管理データを参照することで、その置換対象領域に設定されるべき置換情報を特定して、その置換情報と置換対象領域の持つ情報とが一致するか否かを検出し、両者に一致しないものがあることを検出するときに、その不一致の置換情報を領域識別子とともに抽出する突合せ処理部と、突合せ処理部により抽出された突合せ情報を管理する突合せ情報管理部と、突合せ情報管理部の管理する突合せ情報に基づいて、展開情報管理部の管理する置換対象領域の持つ情報を連続的に置き換えていく連続置換処理部とを備えるように構成する。」（平成８年３月２５日付手続補正書第１頁下から第７行目〜第２頁８行目）と記載され、
　産業上の利用分野として、
　「対話処理に従って、入力エントリーを持つフォーマットを作成するデータ処理装置がある。
　この入力エントリーの設定される領域には、項目名が割り付けられており、その項目名に応じて、入力エントリーの桁数／小数部桁数、繰返し数などに規約がある。
　対話処理に従って、入力エントリーを持つフォーマットを作成するデータ処理装置では、従来、対話処理に従ってフォーマットを作成した後、入力エントリーが規約のものになっていない場合には、ユーザが、その規約に反している領域を１つ１つ選択して、その選択した領域の持つ入力エントリーを規約に従うものに手作業で変更するという方法を採っていた。
　このように、従来では、ディスプレイ画面上に展開される置換対象領域の持つ情報を別のものに置換していく場合、ユーザが、手作業でもって、先ず最初に、置換対象領域を指定し、次に置換情報を入力していくことで置換処理を実行していくという方法を採っていた。」（平成８年３月２５日付手続補正書第２頁下から第９行目〜第３頁第５行目）と記載されている。
　しかし、このような記載内容では、次のような素朴な点が疑問が生じることになる。つまり、対話処理に従って、入力エントリーを持つフォーマットを作成するデータ処理装置において、対話処理に従ってフォーマットを作成した後、入力エントリーが規約のものになっていない場合に、規約に反している領域を、ユーザが、その規約に反している領域を１つ１つ選択して、その選択した領域の持つ入力エントリーを規約に従うものに手作業で変更したり、もしくは本願発明のように自動的に規約に合うように置換させるのであれば、ユーザに対話させてフォーマットを作成させるより、エントリー規約をフォーマット作成時に利用し、項目（領域識別子）だけ指定してエントリー規約を自動的に取り込んだ方が良いことになる。すなわち、対話処理に従ってフォーマットを作成する際に、最初から入力エントリ規約を利用するように設計されるのが自然であることからして、本願でいう「対話処理に従って、入力エントリーを持つフォーマットを作成するデータ処理装置」とは、具体的にどのようなものを想定しているのか不明といわざるを得ない。
　なお、従来、「対話処理に従って、入力エントリーを持つフォーマットを作成するデータ処理装置」として想定できるものは、カード型データベースやスプレッド・シートがあるが、該カード型データベースや該スプレッド・シートでは、「対話処理に従ってフォーマットを作成した後、入力エントリーが規約のものになっていない場合には、ユーザが、その規約に反している領域を１つ１つ選択して、その選択した領域の持つ入力エントリーを規約に従うものに手作業で変更する」ようなことや、本願発明のように自動的に置換させたりすることはしておらず、ユーザが入力エントリーを持つフォーマットを作成した際に、入力エントリーが規約の上限値を超えない場合は、エントリー規約に置換しないでそのままユーザの指定したものが採用されるようになっており、入力エントリーが規約の上限値を超えた場合に警告メッセージ等を出すか、強制的に規約の上限値に変えるようになっているのが普通である。
　したがって、「対話処理に従って、入力エントリーを持つフォーマットを作成するデータ処理装置」とは、具体的のどのようなものを想定しているのか不明といわざるを得ず、本願発明がどのような産業上の分野で利用されているものなのか不明である。
　以上のとおりであるから、本願明細書及び図面には、その発明の属する技術分野における通常の知識を有する者が容易にその実施をすることができる程度に、その発明の目的、構成及び効果が記載されているとは認められない。
　
３．請求人の主張
　請求人は、上記当審の拒絶理由に対して、明細書の補正をすることなく、意見書を提出し、概要以下のとおり主張している。
　(１)「しかしながら、「置換情報管理部１２」の管理する置換対象領域に設定されるべき情報は、入力エントリーを持つフォーマットが作成された後、種々の理由で変更されることがあります。
　例えば、最初は社員番号の入力エントリーの大きさを５桁としていたものを、社員の増加に伴って７桁に変更する必要がでてくるといったように、「置換情報管理部１２」の管理する置換対象領域に設定されるべき情報が変更されることが起こります。
　このような場合に、本願発明は特に有効なものとなります。
　審判官は、特許請求の範囲に記載される「突合せ処理部１３」がフォーマット作成時にのみ動作すると考えておられますが、この「突合せ処理部１３」は、それ以外のフォーマット作成後の必要な時に起動されて、「展開情報管理部１１」の管理する置換対象領域の持つ情報と、「置換情報管理部１２」の管理する置換対象領域に設定されるべき情報とを突き合わせて、両者に一致しないものがあればそれを検出する処理を行います。」（意見書第２頁第１２〜２５行目）
　（２）上記主張の根拠として、
　「出願当初の明細書の第９頁第１２行〜第１６行に、「ユーザは、フォーム開発プログラム２０との対話により展開したディスプレイ画面上の項目の持つ属性を、項目ディクショナリ２２の管理する属性に置換しようとするときには、突合せプログラム２３を起動する。」と記載していることから分かるように、「突合せ処理部１３」の起動タイミングは、フォーマット作成時に限られるものではありません。」（意見書第２頁第２６行目〜第３頁第２行目）
　(３)また、想定されるデータ処理装置として、
　「従って、カード型データベースやスプレッドシートのようなものに対して、本願発明を適用することは当然のことながら可能であり、このような場合には、カード型データベースやスプレッド・シートは、とりも直さず、本願発明に言う「対話処理に従って、入力エントリーを持つフォーマットを作成するデータ処理装置」となります。
　その他に、本願発明に言う「対話処理に従って、入力エントリーを持つフォーマットを作成するデータ処理装置」としては、画面帳票定義体を作成するデータ処理装置があります。
　画面帳票定義体では、入力エントリーを定義して、そこにデータを入力していくという構成を採っていますが、この入力エントリーに割り付けられる領域情報（例えば５桁）が誤って設定されたり、作成後に変更されることがあることを考慮して、本願発明が適用されることになります。」（意見書第４頁第２〜１２行目）
　
４．当審の判断
　以下、請求人の主張について検討する。
　請求人は、「審判官は、特許請求の範囲に記載される「突合せ処理部１３」がフォーマット作成時にのみ動作すると考えておられますが、この「突合せ処理部１３」は、それ以外のフォーマット作成後の必要な時に起動されて、「展開情報管理部１１」の管理する置換対象領域の持つ情報と、「置換情報管理部１２」の管理する置換対象領域に設定されるべき情報とを突き合わせて、両者に一致しないものがあればそれを検出する処理を行います。」と主張し、その根拠として、「出願当初の明細書の第９頁第１２行〜第１６行に、「ユーザは、フォーム開発プログラム２０との対話により展開したディスプレイ画面上の項目の持つ属性を、項目ディクショナリ２２の管理する属性に置換しようとするときには、突合せプログラム２３を起動する。」と記載されている点をあげている。
　しかしながら、請求人が主張するように「ユーザは、フォーム開発プログラム２０との対話により展開したディスプレイ画面上の項目の持つ属性を、項目ディクショナリ２２の管理する属性に置換しようとするときには、突合せプログラム２３を起動する。」との記載が認められるものの、この「フォーム開発プログラム２０」は、出願当初の明細書の第８頁第７〜１１行目に「２０はデータ処理装置１の備えるフォーム開発プログラムであって、ユーザとの対話処理に従って、データ情報の表示領域となる項目の配列位置や、それらの属性情報からなるフォーマット情報を作成していくもの」と記載されているのであるから、この「突き合わせ処理部１３」は、フォーマット作成時にのみ動作させるものである。そして平成８年３月２５日付け手続補正書を参酌すると、出願当初の明細書の［産業上の利用分野］の項を、「本発明は、対話処理に従って、入力エントリーを持つフォーマットを作成するデータ処理装置で実行され、ディスプレイ画面上に展開される複数の置換対象領域の持つ情報をそれぞれ別のものに置換する複数領域情報の連続置換処理方式に関し、特に、連続置換処理を実現することで効率的に置換処理を実行できるようにする複数領域の連続置換処理方式に関する。‥‥‥」と補正し、また同手続補正書で、出願当初の［従来の技術］の項を、「対話処理に従って、入力エントリーを持つフォーマットを作成するデータ処理装置がある。‥‥‥」と補正している。該補正事項からしても、本願発明がフォーマットを作成するときに関するものであることは明らかであり、したがって「突き合わせ処理部１３」は、フォーマット作成時にのみ動作させるものである。
　なお、仮に請求人が主張する「この「突合せ処理部１３」が、「それ以外のフォーマット作成後の必要な時に起動されて、「展開情報管理部１１」の管理する置換対象領域の持つ情報と、「置換情報管理部１２」の管理する置換対象領域に設定されるべき情報とを突き合わせて、両者に一致しないものがあればそれを検出する処理」を行うにように構成されるものであれば、「置換情報管理部１２」の置換情報を変えるための構成が必要であることになるが、明細書及び図面を参酌してもそのための構成について何らの記載も見当たらない。
　以上のことを考慮すれば、本願発明は、フォーマット作成時に係わるものであり、請求人が主張する「突合せ処理部１３」は、「それ以外のフォーマット作成後の必要な時に起動され」るものではないのであるから、これを根拠として、「この「突合せ処理部１３」が、「それ以外のフォーマット作成後の必要な時に起動されて、「展開情報管理部１１」の管理する置換対象領域の持つ情報と、「置換情報管理部１２」の管理する置換対象領域に設定されるべき情報とを突き合わせて、両者に一致しないものがあればそれを検出する処理を行います。」との主張は、明細書及び図面に記載された構成に基づかないものであり、請求人の主張は採用できない。
　そうすると、対話処理に従って、入力エントリーを持つフォーマットを作成するデータ処理装置において、対話処理に従ってフォーマットを作成した後、入力エントリーが規約のものになっていない場合に、規約に反している領域を、ユーザが、その規約に反している領域を１つ１つ選択して、その選択した領域の持つ入力エントリーを規約に従うものに手作業で変更したり、もしくは本願発明のように自動的に規約に合うように置換させるのであれば、ユーザに対話させてフォーマットを作成させるより、エントリー規約をフォーマット作成時に利用し、項目（領域識別子）だけ指定してエントリー規約を自動的に取り込んだ方が良いことになる。すなわち、対話処理に従ってフォーマットを作成する際に、最初から入力エントリ規約を利用するように設計されるのが自然であることからして、本願でいう「対話処理に従って、入力エントリーを持つフォーマットを作成するデータ処理装置」とは、具体的にどのように構成されるものであるのか、明細書の記載からは依然として不明のままといわざるを得ない。
　したがって、本願明細書及び図面には、その発明の属する技術分野における通常の知識を有する者が容易にその実施をすることができる程度に、その発明の目的、構成及び効果が記載されているとは認められないとして、当審が通知した先の拒絶理由は解消していない。
　
５．むすび
　以上のとおりであって、本願は、特許法第３６条第３項及び第４項に規定する要件を満たしていないから、拒絶すべきものである。
　よって、結論のとおり審決する。