【事件の表示】
　特願２０００−３８３０６１「緊急通報システムと装置」拒絶査定不服審判事件〔平成１４年　６月２８日出願公開、特開２００２−１８３０４６〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願は、平成１２年１２月１８日の出願であって、平成１６年５月１４日付で拒絶査定がなされ、これに対し、同年６月７日に拒絶査定に対する審判請求がなされるとともに、同日付で手続補正がなされたものである。
　
２．平成１６年６月７日付の手続補正についての補正却下の決定
［補正却下の決定の結論］
　　平成１６年６月７日付の手続補正を却下する。
［理由］
　本件補正により、特許請求の範囲の請求項１は、
「個々のデータ送信機を公衆電話網を介してデータ受信機と接続し、さらに該受信機と接続した監視コンピュータにおいて、データ送信機は管理対象物の所定個所に取り付け且つ設備機器を制御可能であり、メールサーバは監視コンピュータとともに閉域ネットワークを構成し且つインターネットに参加し、監視コンピュータは、伝送データをディスクに保存するとともに、このディスクのテキスト保存フォルダを定時的に検索し、未送信ファイルからマスターデータベースに基づいて送信データを作成してから、送信先を決定して連絡用の電子メールをメールサーバへ転送し、一方、データ送信機はデータ受信機にＤＴＭＦ信号を出力するとともに、責任担当者のポケットベルへ通報する機能を有する緊急通報システム。」と補正された。
　この補正は、特許法第１７条の２第１項第３号の規定に基づいて、なされたものであるから、同法同条第３項の規定及び第４項各号の規定に適合したものであるかを検討する。
　前記規定は、以下のとおりのものである。
　第３項　第１項の規定により明細書又は図面について補正をするときは、誤訳訂正書を提出してする場合を除き、願書に最初に添付した明細書又は図面（第３６条の２第２項の外国語書面出願にあつては、同条第四項の規定により明細書及び図面とみなされた同条第２項に規定する外国語書面の翻訳文（誤訳訂正書を提出して明細書又は図面について補正をした場合にあつては、翻訳文又は当該補正後の明細書若しくは図面））に記載した事項の範囲内においてしなければならない。
　第４項　前項に規定するもののほか、第１項第２号及び第３号に掲げる場合において特許請求の範囲についてする補正は、次に掲げる事項を目的とするものに限る。
　第１号　第３６条第５項に規定する請求項の削除
　第２号　特許請求の範囲の減縮（第３６条第５項の規定により請求項に記載した発明を特定するために必要な事項を限定するものであつて、その補正前の当該請求項に記載された発明とその補正後の当該請求項に記載される発明の産業上の利用分野及び解決しようとする課題が同一であるものに限る。）
　第３号　誤記の訂正
　第４号　明りようでない記載の釈明（拒絶理由通知に係る拒絶の理由に示す事項についてするものに限る。）
　当該補正の根拠となる、平成１５年１１月２１日付手続補正書の特許請求の範囲の各請求項は、以下のとおりのものである。
【請求項１】　監視コンピュータにおいて、データ受信機からアスキーコードやＤＴＭＦ信号で受信した伝送データを即時にテキストデータに変換し、テンポラリファイルとしてディスク内のテキスト保存フォルダに保存するとともに、テキスト保存フォルダを定時的に検索し、未送信ファイルが存在すれば、これを情報管理データベースに取り込んでテキストファイルで保存するとともに、この未送信ファイルからマスターデータベースに基づいて送信データを作成してから、送信先を決定して連絡用の電子メールをメールサーバへ転送する緊急通報システム。
【請求項２】　個々のデータ送信機を公衆電話網を介してデータ受信機と接続し、監視コンピュータにおいて、アスキーコードやＤＴＭＦ信号で受信した異常や復旧の伝送データを、常時受信待ちのプログラムによって即時に取り込んでテキストデータに変換し、テンポラリファイルとしてディスク内のテキスト保存フォルダに保存するとともに、定時処理のプログラムによってこのディスクのテキスト保存フォルダを定時的に検索し、未送信ファイルが存在すれば、これを情報管理データベースに取り込んでテキストファイルで保存するとともに、この未送信ファイルを監視コンピュータに読み込み、マスターデータベースから必要なデータ項目を取り出して送信データを作成し、さらに送信先を決定して連絡用の電子メールをメールサーバへ転送する緊急通報システム。
【請求項３】　マスターデータベースは、端末マスタ、回線マスタ、担当マスタ、事項マスタ、管理マスタテーブルで構成し、監視コンピュータにおいてデータ訂正が随時に可能である請求項１または２記載のシステム。
【請求項４】　未送信のテキストファイルを監視コンピュータに読み込み、このテキストファイルからＣＳＶフォーマットの連絡文章を作成した後に連絡用の電子メールをメールサーバへ転送することにより、インターネットを介して各人各地のインターネット対応携帯電話、ピアフ規格の簡易型無線電話、ドメイン加入のノート型パソコン、ドメイン加入のデスクトップパソコンで随時に閲覧できる請求項１または２記載のシステム。
【請求項５】　管理対象物の所定個所に取り付けて測定素子からの出力信号を伝送するデータ送信機と、単数または複数台の送信機と公衆回線網を経由して接続するデータ受信機と、該データ受信機と接続する監視コンピュータと、該監視コンピュータからメール転送が可能なメールサーバと、前記データ送信機のほかに管理対象物に取り付けた別の送信機とを備え、監視コンピュータは、データ受信機からの伝送データをテキストファイルに変換し、新規のテキストファイルを取り込んで情報管理データベースに保存するとともに、送信データから連絡用の電子メールを作成してメールサーバに転送することにより、送信先の担当者がインターネット対応携帯電話によって随時に連絡文章を閲覧でき、一方、別の送信機によって緊急事態を警備会社センターへ通報する緊急通報装置。
【請求項６】　管理対象物の所定個所に取り付けて測定素子からの出力信号を入力し且つ設備機器を制御可能な主制御部のデータ送信機と、単数または複数台のデータ送信機とともに広域ネットワークを構成するデータ受信機と、該受信機と接続する監視コンピュータと、監視コンピュータとともに閉域ネットワークを構成し且つインターネットに
参加するメールサーバとを備え、監視コンピュータにおいて未送信ファイルから送信データを作成し、この送信データから作成する連絡用の電子メールをメールサーバに転送し、一方、送信先の担当者は適宜の接続機器によってメールサーバへアクセスして電子メールを閲覧でき、さらにその担当者が前記の接続機器からＤＴＭＦ信号を管理対象物のデータ送信機へ伝送して管理対象物の設備機器を遠隔操作できる緊急通報装置。
【請求項７】　監視コンピュータとケーブル接続するデータ受信機がデジタル受信機であり、受信したデジタル信号を監視コンピュータへ非同期伝送するとともに、該受信機から特定送信先にオートダイアルで電話コールする請求項５または６記載の装置。
【請求項８】　監視コンピュータとケーブル接続するデータ受信機がボイス機能モデムであり、この場合には受信したＤＴＭＦ信号をデジタル化して監視コンピュータへ非同期伝送する請求項５または６記載の装置。
　ここで、前記手続補正の内容を検討する。
ａ．補正後の請求項１に記載された「データ送信機はデータ受信機にＤＴＭＦ信号を出力する」点については、補正前各請求項には、請求項１．「監視コンピュータにおいて、データ受信機からアスキーコードやＤＴＭＦ信号で受信した伝送データ」、請求項２．「監視コンピュータにおいて、アスキーコードやＤＴＭＦ信号で受信」、請求項６．「その担当者が前記の接続機器からＤＴＭＦ信号を管理対象物のデータ送信機へ伝送」及び請求項７．「データ受信機がボイス機能モデムであり、この場合には受信したＤＴＭＦ信号をデジタル化して監視コンピュータへ非同期伝送する」旨の記載はあるが、「データ送信機」において「データ受信機」にアスキーコードやＤＴＭＦ信号を出力する旨の記載は、存在しないばかりか、それを示唆する記載すらない。
ｂ．補正後の請求項１に記載された「データ送信機はデータ受信機にＤＴＭＦ信号を出力するとともに、責任担当者のポケットベルへ通報する機能を有する」点については、補正前の各請求項には、「連絡用の電子メール」を用いる旨の記載はあるが、「責任担当者のポケットベル」を示唆する記載は、存在しない。
　また、補正前の請求項５及び７には、それぞれ「送信先の担当者がインターネット対応携帯電話によって随時に連絡文章を閲覧」する旨の記載及び「受信機から特定送信先にオートダイアルで電話コールする」という記載はあるが、前記「携帯電話」は、電子メールを閲覧するために用いるものであるし、後記「電話コール」は、「受信機」からなされるものであって、「データ送信機」からなされるものではない。
　上記ａ及びｂによれば、この補正は、補正前の特許請求の範囲の各請求項に記載されていた事項に基づくものではなく、特許法第１７条の２第４項第２号の規定に基づいてなされたものではない。
　また、同法同条同項第１、３及び４号の規定に基づかないことも、いうまでもない。
　以上のとおり、この補正は、前記特許法第１７条の２第４項各号の規定に違反してなされたものである。
　したがって、上記補正は、同法第１５９条第１項の規定において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。 
　よって、結論のとおり決定する。
　
３．本願発明について
　平成１６年６月７日付の手続補正は上記のとおり却下されたので、本願の請求項１に係る発明（以下、同項記載の発明を「本願発明」という。）は、平成１５年１１月２１日付手続補正書の特許請求の範囲の請求項１に記載された事項により特定される、以下のとおりのものである。
「監視コンピュータにおいて、データ受信機からアスキーコードやＤＴＭＦ信号で受信した伝送データを即時にテキストデータに変換し、テンポラリファイルとしてディスク内のテキスト保存フォルダに保存するとともに、テキスト保存フォルダを定時的に検索し、未送信ファイルが存在すれば、これを情報管理データベースに取り込んでテキストファイルで保存するとともに、この未送信ファイルからマスターデータベースに基づいて送信データを作成してから、送信先を決定して連絡用の電子メールをメールサーバへ転送する緊急通報システム。」
　
４．引用例
　原査定の拒絶の理由に引用された本願出願前の平成１２年７月２８日に頒布された引用例、および、その記載事項は、以下のとおりである。
　引用例１：特開２０００−２０９２０４号公報
「【００２６】監視対象とする無線通信網５に何らかの障害が発生し、障害の発生を知らせる監視情報が監視・制御情報専用線７を通じて集中管理システム１に送られてくると、この情報は集中管理手段８で受信され、メール作成手段９へ通知される。メール作成手段９では、集中管理手段８から通知された監視情報を基に、図示するような監視情報送信メール１３を作成する。
【００２７】この監視情報送信メール１３の宛先は、予め宛先アドレスグループファイル１０に登録してある遠隔管理システムの電子メールアドレスを併記した形にする。メールの重要度は、受信した監視情報の障害レベル（重障害、軽障害、ステータス）等に対応させ、高、中、低等に区別して作成する。件名には、少なくとも受信した監視情報の日時／局名称／監視項目名称／状態名称を含ませる。また、本文には、前記件名の記載項目の他に、集中管理手段８による付加情報を《備考》として記載する。
【００２８】メール作成手段９によって作成された前記監視情報送信メール１３は、電子メールサーバ１１を経由してインターネット６へ送信される。遠隔管理システム２は、インターネット６を経由して前記監視情報電子メール１３を受信すると、汎用の電子メールＡＰ１２の一般機能を用いて一般のメールと同様に取り扱い、メール受信画面１４に受信表示する。そして、この送られてきたメールを開くと、図示するような監視情報受信メール１５としてその内容を参照することができ、障害内容を知ることができる。尚、メール受信画面１４には、メールの重要度に応じて例えば「！」等のマークが表示されるので、受信メールが緊急対策を講ずる必要のあるメールであるか否かを簡単に知ることができる。」（公報、第４頁、段落【００２６】乃至【００２８】の記載。）
　これらの記載によれば、引用例１には、「集中管理システム１において、障害の発生を知らせる監視情報が監視・制御情報専用線７を通じて集中管理システム１に送られてくると、この情報は集中管理手段８で受信され、メール作成手段９へ通知され、メール作成手段９は、集中管理手段８から受信した監視情報から、監視情報送信メール１３を作成し、監視情報送信メール１３の宛先は、予め宛先アドレスグループファイル１０に登録してある遠隔管理システムの電子メールアドレスとして、電子メールサーバ１１を経由してインターネット６へ送信される緊急通報システム。」なる発明（以下、引用例発明という。）が記載されている。
　
５．対比
　本願発明と引用例発明とを対比すると、
　引用例発明における「監視情報」及び「監視情報送信メール１３は、電子メールサーバ１１を経由してインターネット６へ送信される」は、本願発明における「伝送データ」及び「連絡用の電子メールをメールサーバへ転送する」に相当する。
　引用例発明における「集中管理手段８」は、引用例発明における「障害の発生を知らせる監視情報が監視・制御情報専用線７を通じて集中管理システム１に送られてくると、この情報は集中管理手段８で受信され」る点からみて、本願発明における「データ受信機」に相当する。
　引用例発明における「集中管理システム」は、本願発明における「監視コンピュータ」に相当する。
　引用例発明における「監視情報送信メール１３の宛先は、予め宛先アドレスグループファイル１０に登録してある遠隔管理システムの電子メールアドレス」からみて、本願発明における「マスターデータベースに基づいて送信先を決定」することも、引用例においてなされている。
　したがって、両者は、「監視コンピュータにおいて、データ受信機から受信した伝送データにより、送信先を決定して連絡用の電子メールをメールサーバへ転送する緊急通報システム。」である点で一致し、以下の点で相違する。
　相違点１：伝送データが、本願発明においては、「アスキーコードやＤＴＭＦ信号」であるのに対し、引用発明においては、特段の記載がない点。
　伝送データを受信してから、電子メールを転送するまでの手順として、
　相違点２：伝送データを受信すると、本願発明においては、第１段階として「即時にテキストデータに変換し、テンポラリファイルとしてディスク内のテキスト保存フォルダに保存し」ているのに対し、引用発明においては、特段の記載がない点。
　相違点３：第２段階として、「テキスト保存フォルダを定時的に検索し、未送信ファイルが存在すれば、これを情報管理データベースに取り込んでテキストファイルで保存するとともに、この未送信ファイルからマスターデータベースに基づいて送信データを作成」してから、電子メールを転送しているのに対し、引用発明においては、特段の記載がない点。
　
６．判断
　前記相違点について検討する。
　相違点１：一般に、「DTMFとは、プッシュ方式の電話機などで、ボタンを押すと発信される音のことである。または、その音に複数の周波数を含ませることでダイヤルする仕組みのこと。プッシュ音、トーン信号と呼ばれることもある。
　1つのボタンを押すと2種類の高さの音が発信されるようになっており、交換局ではこの信号音を元にして電話番号を割り出している。高音系4種類と低音系4種類からそれぞれ1音ずつを組み合わせるため、「0」から「9」の数字、「*」「#」の記号、「A」から「D」までのアルファベットを合わせて16種類の音を表現することが可能である。」というものであるし、また、「アスキーコードとは、1963年にアメリカ規格協会(ANSI)が定めた、情報交換用の文字コードの体系のことである。ASCIIは”American Standard Code for Information Interchange”の略。1967年に国際標準化機構(ISO)で定められた情報交換用符号の国際規格「ISO 646」とほぼ同じ。ASCIIコードはコンピュータ用の英数字のコードとして最も普及しており、原則的にJISローマ字コード（JIS X 0201-1976）と同じ体系を持っている。　いずれのコードも7ビット、128文字が割り当てられており、94字が印字可能なローマ字、数字、記号、34字が制御コードとなっている。実際にはコンピュータは1文字を8ビット(1バイト)で表現するため、256種類の文字を扱うことができるが、ASCIIが定めていない128文字分の拡張領域には、コンピュータメーカーや国によって異なる文字が割り当てられている。日本では、拡張領域にカナ文字を収録したコード体系が「JIS X 0201」として規格化されている。」というものであるが、本願発明において、このビット数も種類も異なったデータをどのようにして伝送データとして、取り扱うのか明瞭に記載されていないが、伝送データとして「DTMF」信号や「アスキーコード」を用いることは、本願出願前周知技術であるから、当該周知技術を引用発明に採用して、本願発明のように構成することは、当業者において、格別の創意を要することなく、なし得たものである。
　前記周知技術の例として、以下の文献を参照すること。
　DTMF信号の事例として特開平１１−３１７８１９号公報、特開平７−５８８７９号公報等を、アスキーコードの事例として特開平１１−３５５３７８号公報等を参照されたい。
　
　相違点２：原審の拒絶の理由において引用した、本願出願前の平成１２年１１月２４日に頒布された、特開２０００−３２２４５３号公報（以下、引用例２という。）には、以下の点が記載されている。
ｂ．「コンピュータ内部に発生したイベントを検出する検出機能と、電子メールを送信するメール送信機能とを有するコンピュータに適用される障害情報支援システムであって、
　前記検出機能より障害のイベントが検出された場合、その障害情報を汎用性のある形式のファイルに変換して保存する障害情報変換保存手段と、
　システム起動時に、予め設定されているメール送信先情報からメールの送付先を含む情報を取得し、メール情報を作成するとともに、前記障害情報変換保存手段にて変換及び保存されたファイルを前記メール情報の添付ファイルとして添付するメール作成手段と、
　前記メール作成手段により作成されたメール情報を前記メール送信機能へ渡す手段とを具備したことを特徴とする障害情報支援システム。」（公報、第２頁、【特許請求の範囲】、【請求項１】の記載。）　
ｃ．「本発明では、コンピュータに障害が発生した際に、イベントログ等の障害情報を汎用性のある形式のファイル、例えばＣＳＶ形式等に変換して保存しておく。また、ＯＳが障害を報知するために画面に表示した障害検出メッセージ等の画面の情報をテキスト形式のファイルに変換して保存しておく。」（公報、第３頁、段落、【００１１】の記載。）
　引用例２に記載された「イベント」は、本願発明における「伝送データ」に相当する。
　また、引用例２に記載された「障害のイベントが検出された場合」は、本願発明における「伝送データを受信」することに相当する。
　引用例２に記載された「検出機能より障害のイベントが検出された場合、その障害情報を汎用性のある形式のファイルに変換」することは、汎用性のある形式のファイルが「ＣＳＶ形式」のものであり、一般に「ＣＳＶ形式」のファイルは、「データベースの各レコードにおいて、フィールドの区切りをカンマ（，）のみで表現する形式のことである。各レコードの区切りは改行で表現し、CSVはシンプルな構成と汎用性の高さを特徴とする、また、ファイルはテキスト形式であるため、テキストエディタでも開くことができる」というものであるから、本願発明における「即時にテキストデータに変換」することは、引用例２に記載されている。
　さらに、引用例２においても「障害情報を汎用性のある形式のファイルに変換して障害情報変換保存手段に保存する」のであるから、本願発明における「ディスク内のテキスト保存フォルダに保存」することは、なされている。
　これを「テンポラリファイル」とするかどうかは、テンポラリファイルが、一般に「一時保存用ファイル」を意味するものであるところから、単なる設計的事項にすぎない。
　したがって、引用例２には、「イベント」（本願発明における「伝送データ」に相当。）を受信すると、「即時にテキストデータに変換し、テンポラリファイルとしてディスク内の障害情報変換保存手段（本願発明における「テキスト保存フォルダ」に相当。）に保存」する点が、記載されており、相違点２として示した、本願発明における第１段階は、引用例２に記載されているように、本願出願前、周知技術であるから、当該周知技術を、引用発明に採用して、本願発明のように構成することは、当業者において、格別の創意を要することなくなし得たものである。。
　
　相違点３：原審の拒絶の理由において引用した、本願出願前の平成１２年４月２１日に頒布された、特開２０００−１１２８０３号公報（以下、引用例３という。）には、「ネットワークに接続されたサーバに格納されてあらかじめ管理対象として登録されている一又は複数の所定のデータファイルの少なくともファイル名と更新日時を含むファイル付属情報、及び、前記ネットワークに接続され、前記データファイル転送先としてあらかじめ登録されている複数のクライアントの少なくともクライアント名とネットワークアドレスを含むクライアント識別情報をそれぞれ管理する管理手段と、
　前記管理手段におけるファイル付属情報を所定時間毎に参照して前記データファイルが更新されたか否かを判断する更新判断手段と、
　前記更新判断手段で更新されたと判断されたデータファイルに関する所定の情報を、前記管理手段のファイル付属情報及びクライアント識別情報に基づいて、前記更新データファイルを必要とする所定のクライアントに転送する更新情報配信手段とを備えることを
　特徴とするデータ自動更新システム。」及び（公報、第２頁、【特許請求の範囲】、【請求項１】の記載。）
「前記請求項１ないし３のいずれかに記載のデータ自動更新システムにおいて、
　前記更新情報配信手段が、前記更新判断手段で所定のデータファイルの更新判断がなされた場合に、前記ネットワークに接続されて前記各クライアントからアクセス可能な所定のファイル格納部へ更新されたデータファイルを転送すると共に、前記データファイルを要求する一又は複数のクライアントに、前記更新されたと判断されたデータファイルに関する所定の情報として、少なくとも更新日時及び前記ファイル格納部のアドレスを含む前記データファイルについての更新情報を転送し、
　前記クライアントが、前記転送されたデータファイルについての更新情報を基に前記ファイル格納部から更新データファイル本体を転送して得ることを特徴とするデータ自動更新システム。」（公報、第２頁、【特許請求の範囲】、【請求項４】の記載。）とが、記載されている。
　この記載によれば、引用例３には、「管理手段におけるファイル付属情報を所定時間毎に参照して前記データファイルが更新されたか否かを判断する更新判断手段と、更新判断手段で更新されたと判断されたデータファイルに関する所定の情報を、前記管理手段のファイル付属情報及びクライアント識別情報に基づいて、前記更新データファイルを必要とする所定のクライアントに転送する更新情報配信手段と、更新判断手段で所定のデータファイルの更新判断がなされた場合に、前記ネットワークに接続されて前記各クライアントからアクセス可能な所定のファイル格納部へ更新されたデータファイルを転送するようにした、データ自動更新システム」という発明が記載されている。
　ここにおいて、引用例３における「所定時間毎に参照」することは、本願発明における「定時的に検索」することであるし、引用例３における「更新されたか否かを判断する」ことは、「更新データファイル」を必要とする所定のクライアントに転送する旨の記載からみて、本願発明における「未送信ファイル」が存在するか否かの判断であり、引用例３における「所定のデータファイルの更新判断がなされた場合に、前記ネットワークに接続されて前記各クライアントからアクセス可能な所定のファイル格納部へ更新されたデータファイルを転送する」に際して、ファイル格納部において、テキストファイルの形式で保存することは、相違点２において説明したとおり、格別のものでもないことから、引用例３には、本願発明における「テキスト保存フォルダを定時的に検索し、未送信ファイルが存在すれば、これを情報管理データベースに取り込んでテキストファイルで保存するとともに、この未送信ファイルからマスターデータベースに基づいて送信データを作成」してから、電子メールを転送する点が記載されている。
　したがって、引用例発明において、引用例３に記載された技術を採用して、本願発明のように構成することに、格別の創意を要するものではない。
　
　そして、本願発明の作用効果も、引用例に記載された発明及び周知慣用技術から当業者が予測できる範囲のものである。
　したがって、本願発明は、引用例に記載された発明及び周知慣用技術に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができないものである。
　
７．むすび
　以上のとおり、本願発明は、引用例に記載された発明及び周知慣用技術に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　よって、結論のとおり審決する。