【事件の表示】
　特願２００３−　５４０５０「予約受付方法、事前呼出方法及びそのプログラム」拒絶査定不服審判事件〔平成１６年　９月２４日出願公開、特開２００４−２６５０７４、請求項の数（２）〕について、次のとおり審決する。
【結　論】
　原査定を取り消す。
　本願の発明は、特許すべきものとする。
【理　由】
１．手続の経緯
　本願は、平成１５年２月２８日の出願であって、平成１６年５月２８日付けで拒絶理由通知がなされ、これに対して同年８月６日付けの手続補正書による補正がなされ、平成１７年３月９日付けで再度拒絶理由通知がなされ、これに対して同年５月６日付けの手続補正書による補正がなされたが、同年９月１３日付けで拒絶の査定がなされ、同年１０月２０日付けで拒絶査定を不服として審判請求がなされ、同年１１月１８日付けの手続補正書による補正がなされた。
　そこで、当審で審理を行った結果、平成１８年９月２２日付けで拒絶理由通知がなされ、これに対して同年１１月１７日付けの手続補正書による補正がなされたものである。
　
２．本願の発明
　本願の発明は、平成１８年１１月１７日付けの手続補正書により補正された本願の特許請求の範囲の請求項１および２に記載された事項により特定される、以下のとおりのものであると認める。
「【請求項１】
　リモートサーバと、前記リモートサーバに接続可能なユーザ端末と、前記リモートサーバに接続可能な受付処理装置からなる予約受付システムによる予約受付方法であって、
（１）前記受付処理装置が、前記予約受付システムが正常に動作していることを表すオンラインフラグがオンか否かを定期的に判断するステップと、
（２）前記受付処理装置が、前記（１）のステップで前記オンラインフラグがオンであると判断した場合、前記受付処理装置が備えるメイン側状況データファイルから、最新の予約受付番号及び現在呼び出し中の予約受付番号を含む予約受付の情報である状況データを読み出し、その状況データを含む定期通信メッセージを前記リモートサーバに送信するステップと、
（３）前記リモートサーバが、前記定期通信メッセージを受信し、その定期通信メッセージに含まれる状況データを、前記リモートサーバが備えるリモート側状況データファイルに保存するステップと、
（４）前記リモートサーバが、前記定期通信メッセージに応答して所定の応答メッセージを前記受付処理装置に送信するステップと、
（５）前記受付処理装置が、前記定期通信メッセージを送信してから所定期間内に前記応答メッセージを受信したか否かを判断するステップと、
（６）前記受付処理装置が、前記（５）のステップで前記応答メッセージを受信しなかったと判断した場合、前記オンラインフラグをオフにするステップと、
（７）前記受付処理装置が、入力操作に応じて予約依頼情報を入力されるステップと、
（８）前記ユーザ端末が、入力操作に応じて予約依頼情報を入力されるステップと、
（９）前記ユーザ端末が、前記（８）のステップで入力された前記予約依頼情報を前記リモートサーバに送信するステップと、
（１０）前記リモートサーバが、前記ユーザ端末から前記予約依頼情報を受信したとき、その予約依頼情報を受信する前の所定期間内に前記定期通信メッセージを受信しているか否かを判断するステップと、
（１１）前記リモートサーバが、前記（１０）のステップで前記所定期間内に前記定期通信メッセージを受信していると判断した場合、前記（９）のステップで前記ユーザ端末から受信した前記予約依頼情報を前記リモートサーバが備えるリモート側受付データファイルに保存するステップと、
（１２）前記リモートサーバが、前記（１１）のステップの後、仮予約受付完了通知を前記ユーザ端末に送信するステップと、
（１３）前記リモートサーバが、前記（１０）のステップで前記所定期間内に前記定期通信メッセージを受信していないと判断した場合、エラー通知を前記ユーザ端末に送信するステップと、
（１４）前記受付処理装置が、前記（５）のステップで前記応答メッセージを受信したと判断した場合、前記リモート側受付データファイルに保存されている予約依頼情報を前記受付処理装置に送信するように前記リモートサーバに要求するステップと、
（１５）前記リモートサーバが、前記受付処理装置からの予約依頼情報の送信要求に応じて、前記リモート側受付データファイルから予約依頼情報を読み出して前記受付処理装置に送信するステップと、
（１６）前記受付処理装置が、前記（７）のステップで予約依頼情報の入力があった時、または前記（１５）のステップで予約依頼情報の送信があった時、最新の発行済み予約受付番号からカウントアップした予約受付番号を、前記（７）のステップで入力または前記（１５）のステップで送信された予約依頼情報の順に発行するステップと、
（１７）前記受付処理装置が、前記発行した予約受付番号を含む状況データを前記メイン側状況データファイルに保存するステップと、
（１８）前記受付処理装置が、前記（１６）のステップで発行した予約受付番号に基づいて発券するステップと、
（１９）前記受付処理装置が、前記（１６）のステップで発行した予約受付番号を前記リモートサーバに送信するステップと、
（２０）前記リモートサーバが、前記受付処理装置から送信された前記予約受付番号を前記ユーザ端末に送信するステップと、
（２１）前記ユーザ端末が、入力操作に応じて予約受付番号を入力されるステップと、
（２２）前記ユーザ端末が、前記入力された予約受付番号を前記リモートサーバに送信するステップと、
（２３）前記リモートサーバが、前記リモート側状況データファイルから状況データに含まれる現在呼び出し中の予約受付番号を読み出し、前記ユーザ端末から送信された予約受付番号からその読み出した現在呼び出し中の予約受付番号を減算して待ち人数を算出するステップと、
（２４）前記リモートサーバが、算出した待ち人数を前記ユーザ端末に送信するステップとを備えることを特徴とする予約受付方法。
　　【請求項２】
　請求項１に記載の予約受付方法であってさらに、
　前記リモートサーバが、算出した待ち人数にあらかじめ定められた予想時間を乗算して待ち時間を算出するステップを備え、前記リモートサーバが、算出した待ち時間を算出した待ち人数とともに前記ユーザ端末に送信することを特徴とする予約受付方法。」
　
３．原査定の理由
　原査定の理由の概要は、平成１７年３月９日付けの手続補正書により補正された特許請求の範囲の請求項1から５に係る発明は、引用刊行物（特開２００２−１６３５１２号公報）及び引用刊行物（特開２００２−８７５２１号公報）に開示された内容に照らして進歩性を有さないから、特許法２９条２項の規定により特許を受けることができず、本願は拒絶をすべきものである、というものである。
　
４．当審の拒絶理由通知の理由
　（４−１）平成１８年９月２２日付けで通知された当審の拒絶理由
　平成１８年９月２２日付けで通知された当審の拒絶理由の概要は、平成１７年１１月１８日付けの手続補正書により補正された特許請求の範囲の請求項1及び同請求項1を引用する請求項２について、各ステップ群が整理した態様で記載されておらず、装置間の関連構成が不明であり、意義が不明な用語があって、発明の構成が全体として明確でない点で不備であり、同請求項３について、各装置が備えるプログラムが、「請求項１又は２に記載のステップをコンピュータに実行させるための」プログラムとして単一の概念でまとめられる性質のものでなく、発明の構成が全体として明確でない点で不備であるから、特許法第３６条第６項第２号に規定する要件を満たしていない、というものである。  
　
５．当審の判断
　（５−１）原査定の理由（特許法第２９条第２項）について
　上記原査定の引用刊行物である特開２００２−１６３５１２号公報には、「目的の場所の端末と遠隔地の携帯端末等の双方の端末からの予約がサーバで一元管理され、順番待ちの番号が発行され、該番号の入力により待ち人数もしくは待ち時間が端末に表示される」技術が開示されている（同引用刊行物中の段落【０００１】及び【０００８】ないし【００１０】並びに図１）。
　また、同じく上記原査定の引用刊行物である特開２００２−８７５２１号公報には、「セキュリティ確保のために、ユーザ端末から送信されたデータがファイアウォール外のサーバで受け付けられ、該データが、ファイアウォール内のサーバからの要求により該ファイアウォール外に設けたサーバから該ファイアウォール内のサーバに送信され、該送信されたデータが該ファイアウォール内のサーバで処理され、該処理されたデータが該ファイアウォール外のサーバに送信され、該ユーザ端末の要求により、該処理されたデータが、該ファイアウォール外のサーバから該ユーザ端末に送信される」技術の周知例が開示されている（同引用刊行物中の段落【００２２】ないし【００５０】並びに図１及び４の記載）。
　
　これに対し、本願の請求項１に係る発明では、
「（１）前記受付処理装置が、前記予約受付システムが正常に動作していることを表すオンラインフラグがオンか否かを定期的に判断するステップと、
（２）前記受付処理装置が、前記（１）のステップで前記オンラインフラグがオンであると判断した場合、前記受付処理装置が備えるメイン側状況データファイルから、最新の予約受付番号及び現在呼び出し中の予約受付番号を含む予約受付の情報である状況データを読み出し、その状況データを含む定期通信メッセージを前記リモートサーバに送信するステップと、
（３）前記リモートサーバが、前記定期通信メッセージを受信し、その定期通信メッセージに含まれる状況データを、前記リモートサーバが備えるリモート側状況データファイルに保存するステップと、
（４）前記リモートサーバが、前記定期通信メッセージに応答して所定の応答メッセージを前記受付処理装置に送信するステップと、
（５）前記受付処理装置が、前記定期通信メッセージを送信してから所定期間内に前記応答メッセージを受信したか否かを判断するステップと、
（６）前記受付処理装置が、前記（５）のステップで前記応答メッセージを受信しなかったと判断した場合、前記オンラインフラグをオフにするステップ」、並びに、
「（１０）前記リモートサーバが、前記ユーザ端末から前記予約依頼情報を受信したとき、その予約依頼情報を受信する前の所定期間内に前記定期通信メッセージを受信しているか否かを判断するステップと、
（１１）前記リモートサーバが、前記（１０）のステップで前記所定期間内に前記定期通信メッセージを受信していると判断した場合、前記（９）のステップで前記ユーザ端末から受信した前記予約依頼情報を前記リモートサーバが備えるリモート側受付データファイルに保存するステップ」
を備えるものである。
　
　そして、上記各引用刊行物には、前記（１）から（６）のステップからなるところの、受付処理装置から最新の状況データを含む定期通信メッセージをリモートサーバに送信し、リモートサーバから前記定期通信メッセージに応答して所定の応答メッセージを受付処理装置に返信するという、本来的には受付処理装置とリモートサーバとの状況データの整合を図るために行われる双方向の定期通信を利用して、予約受付システムが正常に動作していることを確認する一連の工程、並びに（１０）、（１１）のステップからなるところの、所定期間内に前記定期通信メッセージを受信していることを条件として、ユーザ端末から受信した予約依頼情報をリモートサーバがリモート側受付データファイルに保存するプロセスを備える一連の工程を備える構成は記載されておらず、また、上記各引用刊行物において、前記したところの、（１）から（６）のステップからなる予約受付システムの動作確認のための一連の工程、並びに（１０）、（１１）のステップからなるユーザ端末からの予約依頼情報をリモートサーバが保存するための一連の工程を備える構成を示唆する根拠も見当たらない。
　
　また、前記したところの、（１）から（６）のステップからなる予約受付システムの動作確認のための一連の工程、並びに（１０）、（１１）のステップからなるユーザ端末からの予約依頼情報をリモートサーバが保存するための一連の工程を備える構成により、本願の請求項１に係る発明は、「電気通信回線やリモートサーバに障害が発生していることを容易に認識でき、迅速な対応を行うことができる」という明細書記載の効果を奏するものと認められる。
　
　そうすると、本願の請求項１に係る発明について、上記引用刊行物である特開２００２−１６３５１２号公報及び特開２００２−８７５２１号公報に記載された事項に基づいて当業者が容易に発明をすることができたとする原査定の理由は維持できない。
　
　請求項２は、請求項１の発明にさらに限定を加えたものであるから、請求項２に係る発明についても、上記の結論がそのまま当てはまる。
　
　（５−２）平成１８年９月２２日付けで通知した当審の拒絶理由（特許法第３６条第６項第２号）について　
　審判請求人は、平成１８年１１月１７日付けの手続補正書により明細書の記載を補正し、特許請求の範囲は上記「２．本願の発明」の項で摘記したとおりに補正された。
　これによって、上記の当審の拒絶理由は解消された。
　
６．むすび
　したがって、本願の各請求項に係る発明は、上記各引用刊行物に記載された発明に基いて、当業者が容易に発明をすることができたものとはいえないから、本願の各請求項に係る発明について、原査定の拒絶の理由によって拒絶すべきものとすることはできない。
　また、他に本願の各請求項に係る発明を拒絶すべき理由を発見しない。
　
　よって、結論のとおり審決する。