【事件の表示】
　平成　５年特許願第　５９０８９号「入力チェック処理装置および入力チェック方法」拒絶査定に対する審判事件［平成　６年　９月３０日出願公開、特開平　６−２７４３８９］について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
 １．経緯・本願発明
　本願は、平成５年３月１８日の特許出願であって、原審において平成１３年３月２６日付けで拒絶の理由が通知され、平成１３年６月４日付け意見書が提出されたものの、平成１３年７月２３日付けで拒絶査定された。
　その後、平成１３年８月２９日に拒絶査定に対する審判の請求がなされ、平成１３年９月２８日付けで手続補正書が提出されたことにより、前記審判の請求は特許法第１６１条の２の規定による審査に付され、平成１３年１２月３日付けで特許庁長官に対する報告がされた。
　その後、当審において、平成１４年７月８日付けで拒絶の理由が通知され、平成１４年９月１７日付けで意見書と手続補正書が提出された。更に、平成１４年１０月２８日付けで拒絶の理由（以下、当審で通知した２度目の拒絶の理由という。）が通知され、平成１４年１２月２７日付けで意見書と手続補正書が提出されている。
　
２．当審で通知した２度目の拒絶の理由
　当審で通知した２度目の拒絶の理由は、次のとおりである。
　
 『 本件出願は、明細書及び図面の記載が下記の点で不備のため、特許法第３６条第４項に規定する要件を満たしていない。
　
                      　        記
　
 １．本願の実施例では、画面制御ファイルのチェックファイルレコード番号を用いて入力項目に関係するチェックパターンファイルの対応するレコードを取り出し、何らかのチェックを行うことは理解できるが、このチェックパターンファイルのレコードによりチェックする対象が何であるかが記載されてなく、本願発明を実施できる程度に把握することができない。
　請求人は、別途の機会に、チェックパターンファイルのレコードによりチェックする対象は入力項目（例えば、アスピリン）に付随する入力項目（例えば、薬 品（ａ）、用法（ｂ））であるとの弁明を行っているが、以下の理由でこの弁明は不適切である。
　
（１）明細書の【0029】【0032】段落からみると、図４（ｂ）の画面データファイルから選択して入力された項目がチェックの対象と考えられる。そうすると、アリナミンやアスピリンのような項目名称を持ったものだけがチェックの対象と考えられ、用法（ｂ）のような項目属性は、チェックの対象とならない。なぜなら、用法（ｂ）のような項目属性をチェックすることが明細書には記載されていないからである。さらに、図４（ｂ）の画面データファイルには、用法（ｂ）のような項目が図示されていないだけでなく、仮に、この画面データファイルに用法（ｂ）が登録されていたにしても、この項目属性にはチェックファイルレコード番号が付いていない（空欄）であるから、チェックパターンファイルでチェックすることは出来ない。
　
（２）なお、図４(d-1)には表示内容として、処方　アスピリン・・・・・・・と図示されているが、この例がどういう状況の下での表示内容であるか、また、表示内容がその後の処理等とどのように関連するかが記載されてなく、これをもってアスピリンのような項目名称を画面データファイルから選択したときに、そのチェックの対象が用法等であると理解することはできない。
 結局のところ、画面データファイルから入力項目が入力又は選択されたときに、チェックを行う対象が何であるか不明である。
                      　                      
２−１．（省略）
                      　
２−２．仮に、本願の配列のチェックが薬品名や用法の配列のチェックだとすると、以下の点で不明瞭である。
　
・図４の（ｄ−２）には、テーブル内容として
                      　　　　　　　　Ａ
                      　　アスピリン　ａ　３Ｔ
                      　　１日８回　　ｂ　３日分
 が示されている。
　
 ここで、テーブル（ｄ−２）に展開された項目属性ａ，ｂが、その後どのように使われるのか不明である。また、３Ｔ　１日８回　３日分　がａ，ｂとの関係でどの項目が薬品でどの項目が用法であるのか不明である。
・前記の例で、３Ｔ、１日８回、３日分という項目の配置が入れ替わったときに、例えば、３日分、３Ｔ、１日８回となったときに、前記のチェックパターンファイルの構造でどのようにして配置が間違っていることが検知できるのか不明である。
　
２−３．結局のところ、本願の配列のチェックがどのように行われるかについては不明である。』
 
３．請求人の主張
　
　請求人は、本願発明の入力チェックがどのように行われるものであるのかを明らかにするために、意見書において以下のように説明している。
　　
(1)まず、図４（ｄ−１）のようにデータを入力、表示したものとします。ここでは、表示される項目の中で「アスピリン」について、チェックを行うこととします。
(2)ユーザが図４（ｂ）の画面データファイルから「アスピリン」を選択します（図５：Ｓ１１、Ｓ１２）。
(3)「アスピリン」が選択されると図４（ｃ）の画面制御ファイルを参照して、「アスピリン」の項目属性は「薬品」であり、チェックファイルレコード番号に「Ａ」が設定されていることを認識します（図５：Ｓ１４）。
(4)「次に、チェックパターンファイル中で、レコード番号「Ａ」に記憶されている情報を参照します（図４（ａ））。そこで、「アスピリン」の項目属性は「薬品」であることから、必須属性は「必須」、先頭属性は「先頭」、次項目属性は「薬品（ａ）、用法（ｂ）」であることを認識します（図５：Ｓ１５）。
(5)前記の各種属性情報に基づきチェックを行います。すなわち、１チェック単位内において、「アスピリン」の入力は「必須」であることから入力が省略されていないことをチェックし、「アスピリン」は１チェック単位内において「先頭」に入力されていることをチェックし、「アスピリン」の次には「３Ｔ」、即ち「用法（ｂ）」が入力されていることをチェックします（図５：Ｓ１６）。
　本願発明は以上のように入力チェックを行うものであり、本願発明によれば、上記のように入力されたデータごとの詳細な属性の設定に基づいて、入力データの正当性をチェックすることが可能となります。
　
４．当審の判断
　そこで、請求人が意見書において行っている本願発明の入力チェックについての説明について、以下の（イ）（ロ）の点が出願当初の明細書又は図面に記載されていたかあるいは当初明細書又は図面に記載されていたが如く導き出せるものか検討する。
（イ）本願発明における入力チェックの対象は、図４（ｄ−１）のように入力、表示したものである。
（ロ）「アスピリン」に対する「必須」「先頭」の属性のチェックの次に「３Ｔ」、即ち「用法（ｂ）」が入力されていることがチェックされる。
 
４−１．入力チェックの対象に関する明細書の記載事項
 
【０００３】
　例えば画面上から順次入力された薬品（アリナミン、アスピリンなど）の入力項目やその同一入力項目の回数が妥当であるかなどのチェックを行う場合、プログラムによってそのチェック処理を一々記述していた。
　
【００１２】
　図１は、本発明の１実施例構成図を示す。
　図１において、画面データファイル１は、画面上に表示する画面データ例である。この画面データファイル１上で“Ａ”、“ａ”が項目名称（入力項目名）であって、例えば“アリナミン”、“アスピリン”などである。
　
【００２６】
　図４の（ｄ）は、テーブル展開例を示す。
　図４の（ｄ−１）は、表示内容を示す。これは、画面上の表示内容例を示す。
ここでは、
　　処方　　アスピリン　　３Ｔ（錠）
　　　　　　１日３回　　　３日分
と表示する。
　
【００２９】
　Ｓ１２は、画面内の項目をユーザが選択する。これは、Ｓ１１で画面上に表示された項目のうちからユーザが入力しようとする項目を選択する。Ｓ１３は、終わりか判別する。これは、Ｓ１２の選択の際に、入力の終了が選択されて終わりか判別する。ＹＥＳの場合には、終わる（ＥＮＤ）。一方、ＮＯの場合には、Ｓ１４に進む。
　
４−２．入力チェックの対象についての検討
　本願発明が画面上から入力された入力項目の妥当性をチェックするものであることは理解できる。さて、【0026】段落には、図４（ｄ−１）には表示内容として、処方　アスピリン・・・・・・・と図示されているが、この表示内容はテーブル展開例の中で記載されているにすぎず、ユーザの入力との関連が一切説明されていないため、この記載から図４（ｄ−１）の表示内容がチェックの対象であると理解することはできない。
　
また、【0012】段落の
「 図１において、画面データファイル１は、画面上に表示する画面データ例である。この画面データファイル１上で“Ａ”、“ａ”が項目名称（入力項目名）であって、例えば“アリナミン”、“アスピリン”などである。」
 という記載、および【0029】段落の
  「Ｓ１２は、画面内の項目をユーザが選択する。これは、Ｓ１１で画面上に表示された項目のうちからユーザが入力しようとする項目を選択する。」
および【0034】段落の
「以上によって、画面データファイル１の内容を画面上に表示し、ユーザがこの画面上で選択して入力したことに対応して・・・・・・」
　の記載からみて、ユーザが入力する項目というのは、図４（ｂ）に示されるような画面データファイルから入力項目を選択することによって項目の入力を行うことと捉えることは可能であるが、図４（ｄ−１）のように入力するということを導き出すことはできない。
　従って、当初明細書又は図面に（イ）の点が記載されていないだけでなく、記載されているが如く導き出せるということはできない。
　
４−３．用法のチェックについての検討
　次にチェックの手法については、明細書の【0030】〜【0034】段落に記載されており、ここにおいて例えば「アスピリン」という項目自体について必須、先頭、次項目などの属性のチェックを行うことは記載されているが、「アスピリン」の次に用法が入力されていることをチェックすることは記載されていないし、また、そのことを導き出す記載も見い出すことはできない。
　従って、当初明細書又は図面に（ロ）の点が記載されていないだけでなく、記載されているが如く導き出せるということはできない。
　
　なお、意見書における本願発明の説明には、
「(3)・・・画面制御ファイルを参照して、「アスピリン」の項目属性は「薬品」であり・・・・」
「(4)・・・・そこで、「アスピリン」の項目属性は薬品であることから、必須属性は「必須」、先頭属性は「先頭」、次項目属性は「薬品（ａ）、用法（ｂ）」であることを認識します（図５：Ｓ１５）。
　(5)前記の各種属性情報に基づきチェックを行います。・・・・」
と説明されている。この記載からみると画面制御ファイルでアスピリンの項目属性が薬品であるから、チェックレコードファイルの薬品の行に関するチェックを行っているように説明されているが、このような説明も明細書又は図面から導き出せる事項ではない。
　
　また、請求人は、当審で２度目に通知した拒絶の理由の２−２．で指摘した「３Ｔ、１日８回、３日分という項目の配置が入れ替わったときに、例えば、３日分、３Ｔ、１日８回となったときに、前記のチェックパターンファイルの構造でどのようにして配置が間違っていることが検知できるのか不明である。」との点について前記意見書には何ら説明をしていない。
　
  以上のとおりであるから、当審で２度目に通知した拒絶の理由の１．の点、すなわち、「チェックパターンファイルのレコードによりチェックする対象が何であるかが記載されてなく、本願発明を実施できる程度に把握することができない。」及び　２-３．の点、すなわち、「結局のところ、本願の配列のチェックがどのように行われるかについては不明である。」
の点は解消しておらず、本願明細書又は図面の記載は、当業者が容易にその実施をすることが出来る程度に、その発明の構成を記載したものであるとは認められない。
　
 ５．むすび
　以上のとおり、本願明細書又は図面の説明は、当業者が容易にその実施をすることができる程度に、その発明の構成を記載したものとは認められず、特許法第３６条第４項に規定する要件を満たしていない。
　よって、結論のとおり審決する。