【事件の表示】
　特願２００２−２６８７４９「データ授受システム」拒絶査定不服審判事件〔平成１６年　４月　８日出願公開、特開２００４−１１０１６４〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願は、平成１４年９月１３日の出願であって、平成１７年４月１２日付けで拒絶査定がされ、これに対し、同年５月１９日に拒絶査定に対する審判請求がなされるとともに、同年５月２３日付けで手続補正がなされた。その後、当審において、当該手続補正が平成１８年６月１４日付けの補正の却下の決定により却下され、同日付けで拒絶の理由が通知され、これに対し、平成１８年８月２１日付けで、手続補正がなされたものである。
　
２．本願発明
　本願の請求項１に係る発明（以下、「本願発明」という。）は、平成１８年８月２１日付けの手続補正書により補正された明細書及び図面の記載からみて、その特許請求の範囲の請求項１に記載された次のとおりのものである。
　「データ授受サーバー装置と、該データ授受サーバー装置との間で通信をする端末と、該データ授受サーバー装置との間で通信をするコンピューターとを具備するデータ授受システムにおいて、
　前記端末は、
　　請求金額のデータ項目を含む複数のデータ項目に対応した複数のデータの入力を受け付ける第１の受付手段と、
　　前記複数のデータと、該複数のデータの総件数についてのデータと、該複数のデータの合計請求金額についてのデータと、を含むデータファイルを送信する第１の送信手段と、を具備し、
　前記データ授受サーバー装置は、
　　前記データファイルを受信する受信手段と、
　　前記受信されたデータファイルに含まれる各データについて、数字データのデータ項目に、対応する数字が入っている場合には該数字が該データ項目に対応した正当なデータであると判定し、文字データのデータ項目に、対応する文字が入っている場合には該文字が該データ項目に対応した正当なデータであると判定する第１の判定手段と、
　　前記受信されたデータファイルに含まれる各データを読み込む読込手段と、
　　前記読込手段が読み込んだデータの件数と、前記受信されたデータファイルに含まれている、複数のデータの総件数についてのデータとが一致している場合には、該受信されたデータファイルが正当なデータファイルであると判定する第２の判定手段と、
　　前記読込手段が読み込んだデータの請求金額と、前記受信されたデータファイルに含まれている、複数のデータの合計請求金額についてのデータとが一致している場合には、該受信されたデータファイルが正当なデータファイルであると判定する第３の判定手段と、
　　前記第１の判定手段により、あるデータがデータ項目に対応した正当なデータであると判定されていない場合には、前記受信されたデータファイルに正当でないデータが含まれていると判定し、前記第２の判定手段および前記第３の判定手段の少なくともいずれか１つにより、前記受信されたデータファイルが正当なデータファイルであると判定されていない場合には、該データファイルに正当でないデータが含まれていると判定する第４の判定手段と、
　　前記第４の判定手段により、前記受信されたデータファイルに正当でないデータが含まれていると判定されていない場合には、該データファイルが正当である旨を記述した正当記述データを記憶する正当記述データ記憶手段と、
　　前記第４の判定手段により、前記受信されたデータファイルに正当でないデータが含まれていると判定されていない場合には、該データファイルが正当であるとして、該正当なデータファイルを記憶する正当データファイル記憶手段と、
　　前記第４の判定手段により、前記受信されたデータファイルに正当でないデータが含まれていると判定された場合には、前記受信されたデータファイルに含まれているデータと、前記対応する数字または前記対応する文字と、前記受信されたデータファイルに含まれている、複数のデータの総件数についてのデータおよび複数のデータの合計請求金額についてのデータと、前記読込手段が読み込んだデータの件数および請求金額とに基づいて、正当でないデータのエラーの詳細を示すエラー情報を生成する生成手段と、
　　前記エラー情報を記憶するエラー情報記憶手段と、
　　前記正当記述データ記憶手段に正当記述データが記憶されている場合は前記正当記述データを前記端末に送信し、前記エラー情報記憶手段にエラー情報が記憶されている場合は前記エラー情報を前記端末に送信する記述データ送信手段と、
　　前記正当データファイル記憶手段に記憶された前記正当なデータファイルを前記コンピューターに、１日当たりの設定された回数だけ送信する正当ファイル送信手段と、を具備し、
　前記コンピューターは、
　　前記正当ファイル送信手段により送信された前記データファイルを受信する受信手段と、
　　前記受信されたデータファイルに含まれる各データに基づいて処理を行う処理手段と、
　　前記処理が実行されたことを前記データ授受サーバー装置に送信する送信手段と、を具備し、
　前記端末は、
　　前記エラー情報および前記正当記述データのうちのいずれか１つを前記データ授受サーバー装置から受信する受信手段と、
　　前記受信されたエラー情報または前記受信された正当記述データを表示する表示手段と、
　　前記表示されたエラー情報に対応したデータを訂正する指示を受け付ける第２の受付手段と、
　　前記訂正されたデータを含むデータファイルを前記データ授受サーバー装置に送信する第２の送信手段と、
　　前記データ授受サーバー装置に記憶されているデータファイルを削除する削除手段と、を具備することを特徴とするデータ授受システム。」
　
３．当審の拒絶の理由
　当審において平成１８年６月１４日付けで通知した拒絶の理由のうち、理由Ｃは「本件出願の下記の請求項に係る発明は、その出願前日本国内または外国において頒布された下記の刊行物に記載された発明に基づいて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。」というものであり、刊行物として特開平１１−１０２４００号公報を引用し、さらに周知例として特開平９−１９０４８２号公報を提示したものである。
　
４．引用例
　上記拒絶の理由において引用した特開平１１−１０２４００号公報（以下、「引用例」という。）には、図面と共に、以下の事項が記載されている。
（１）「【請求項１】  顧客側コンピュータおよび該顧客側コンピュータと接続される金融機関側コンピュータを含む自動決済システムにおいて、
前記金融機関側コンピュータは、
顧客と金融機関との間の契約に基づく顧客契約情報を記憶する顧客契約情報記憶手段と、
前記顧客契約情報を登録する顧客契約情報登録手段と、
前記顧客契約情報の存在を確認する顧客契約情報存在確認手段と、
顧客と金融機関との間の前記契約に基づく取引データの集計を行う集計手段と、
前記取引データまたは前記集計手段により得られた集計結果に基づいて顧客との取引の受付の可否を決定する受付可否決定手段と、
前記集計結果および前記受付可否決定手段により決定された決定結果を含むデータを前記顧客側コンピュータへ転送する金融機関側転送手段とを備え、
前記顧客側コンピュータは、
データ入力手段と、
前記データ入力手段により入力したデータを前記金融機関側コンピュータへ転送する顧客側転送手段と、
前記金融機関側転送手段により転送された前記結果を含むデータを表示する表示手段と、
前記表示手段により表示された前記結果を含むデータに基づいて、顧客と金融機関との間の前記契約に基づく取引の決済を行う決済手段とを備えたことを特徴とする自動決済システム。」
　
（２）「【請求項４】  請求項１記載の自動決済システムにおいて、
前記受付可否決定手段は、前記データ入力手段から入力した顧客社員データの形式が所定の形式に適合しない場合、エラー結果を含むデータを前記金融機関側転送手段により前記顧客側コンピュータへ転送して、該エラー結果を含むデータを前記表示手段により表示することを特徴とする自動決済システム。」
　
（３）「【００３３】（実施の形態１）図３は、本発明の一実施の形態である顧客側コンピュータ３００と金融機関側コンピュータ３４０の構成を示す図である。
【００３４】図３において、顧客側コンピュータ３００は、顧客社員データ・ファイル・フォーマット５００（後述の図５参照）の形式のデータ等を入力するデータ入力手段３１０、受付可否等の各種の結果を表示する表示手段３０５、金融機関側コンピュータ３４０から通知された受付可否に基づき決済を行う決済手段３１５および付属のカード・リーダ３２０、顧客側コンピュータ３００と金融機関側コンピュータ３４０との間のデータの入出力を制御する入出力制御部３２５、顧客社員データ・ファイル３２３、顧客社員データ登録手段３２４を有する。
【００３５】金融機関側コンピュータ３４０は、顧客側コンピュータ３００と金融機関側コンピュータ３４０との間のデータの入出力を制御する入出力制御部３５０、顧客の契約に関する情報を格納する顧客契約情報ファイル３９０、顧客契約情報ファイル３９０等を格納する顧客データベース３８５、顧客データベース３８５を管理するデータベース管理システム３５５、入出力制御部３５０およびデータベース管理システム３５５を含むオペレーティング・システム３４５を有しており、このオペレーティング・システム３４５の下に、顧客の契約情報の存在について確認を行うために用いる顧客契約情報存在確認手段３６５、顧客の振替金額や手数料等を集計する集計手段３７５、顧客の振替要求の受付可否を決定する受付可否決定手段３８０、顧客の契約情報を顧客契約情報ファイル３９０に登録する顧客契約情報登録手段３８３を有している。営業店３３０、３３５は顧客の振込先となる口座が存在する営業店である。手数料を求めるための手数料ファイル（図示せず）も、金融機関側コンピュータ３４０内に有している。
【００３６】図４は、顧客契約情報ファイル・フォーマット４００を例示する図である。図４に示すように、顧客契約情報ファイル・フォーマット４００は、例えば、顧客を識別する顧客コード、顧客名、金融機関側が顧客に対して設定した与信ランク、顧客の口座番号、給与振替かその他の振替かを示す振替種類、毎月か毎期末か等を示す振替サイクル、振替サイクルの振替指定日を示す振替日等を有している。
【００３７】顧客の契約情報の登録は、金融機関側コンピュータ３４０の顧客契約情報登録手段３８３を用いて、顧客契約情報ファイル・フォーマット４００（図４）の形式の顧客契約情報ファイル３９０を作成することにより行う。この場合、元となる顧客契約は、通常の書面による契約である。
【００３８】顧客社員データ・ファイル３２３への登録は、データ入力手段３１０から顧客社員データ・ファイル・フォーマット５００（図５）の形式のデータを入力して顧客社員データ・ファイル３２３を作成する顧客社員データ登録手段３２４を用いることにより行うことができる。
【００３９】図５は、顧客社員データ・ファイル・フォーマット５００を例示する図である。図５に示すように、顧客社員データ・ファイル・フォーマット５００は、例えば、社員を識別する社員番号、社員名、社員の給与を示す金額等を有している。」
　
（４）「【００４３】図７は、取引データの送信における金融機関側コンピュータ３４０の処理を示すフローチャートである。
【００４４】図７において、顧客側コンピュータ３００から取引処理要求の受信を行う（Ｓ１００）。取引処理要求とは、例えば上述の給与振替要求等であり、顧客を識別する顧客コードも顧客側から転送されてくる。次に、顧客契約情報存在確認手段３６５を用いて、この顧客と取引が可能か否かを確認する（Ｓ１０５）。顧客契約情報存在確認手段３６５が取引可能と確認したか否かを判断し（Ｓ１１０）、取引不可能と判断した場合は取引不成立の処理を行い（Ｓ１６０）終了する。この確認により、金融機関との書面による契約に基づいて登録されていない顧客が顧客契約情報ファイル３９０へアクセスすることを禁止することができるので、顧客の情報を保護することができる。
【００４５】取引可能と判断した場合は顧客側コンピュータ３００から顧客社員データ・ファイル・フォーマット５００の形式のデータを受信する（Ｓ１１５）。この受信したフォーマットのチェックの結果が正しいか否かを判断して（Ｓ１１７）、正しければ終了し、正しくなければ顧客側コンピュータに受付不可を送信する（Ｓ１４５）。これにより、従来、営業店を介して通知していたフォーマット・チェックの結果を、即座に顧客側へ伝えることができる。」
　
　また、図３より、顧客側コンピュータには、「顧客社員データ登録手段」、「入出力制御部」、金融機関側コンピュータには、「入出力制御部」、「受付可否決定手段」、が記載され、「顧客側コンピュータ」の「入出力制御部」と「金融機関側コンピュータ」の「入出力制御部」が接続されていることが記載されており、「顧客側コンピュータ」と「金融機関側コンピュータ」とのデータの授受は、両「入出力制御部」を介して行われるものと認める。
　
　よって、引用例には以下の発明（以下「引用例発明」という）が開示されている。
　「顧客側コンピュータおよび該顧客側コンピュータと接続される金融機関側コンピュータを含む自動決済システムにおいて、
　前記顧客側コンピュータは、
　顧客社員データ登録手段と、
　金融機関側コンピュータと接続された入出力制御部を備え、
　前記顧客社員データ登録手段により入力したデータを入出力制御部を介し前記金融機関側コンピュータへ転送し、
　前記金融機関側コンピュータは、
　入出力制御部と
　前記取引データに基づいて顧客との取引の受付の可否を決定する受付可否決定手段とを備え、
　前記受付可否決定手段は、前記顧客社員データ登録手段から入力した顧客社員データの形式が所定の形式に適合しない場合、エラー結果を含むデータを前記入出力制御手段を介し前記顧客側コンピュータへ転送する、
自動決済システム。」
　
５．周知例
　当該技術分野の周知技術を以下に検討する。
［周知例１］
　当該技術分野の周知技術を開示する、本願出願前に公開された特開２００２−１５０１９５号公報には、図面と共に以下の事項が記載されている。
「【００１１】
【発明の実施の形態】図１は本発明の一実施形態を示すネットワーク全体構成図である。図１に示す如く、本実施形態では、決済サーバー１０、販売者サーバー１２、およびユーザ端末（例えばパーソナルコンピュータ、あるいは、携帯電話やＰＤＡ等の携帯型情報処理端末）１４がインターネット１６を介して相互に接続されている。また、決済サーバー１０には、決済用銀行（決済サーバー１０からの指示に応じて口座開設、口座引き落とし、口座振替等の決済処理を行うべき旨の契約を決済サーバー１０の運営会社との間で締結した金融機関）の口座管理を行うホストコンピュータ１８が専用回線１９を介して接続されている。なお、決済サーバー１０の運営会社が金融機関である場合には、その運営会社自身が決済用銀行となることができる。
【００１２】決済サーバー１０および販売者サーバー１２は、共に、大容量記憶装置（例えばハードディスク）や通信インターフェース等を備えたコンピュータシステムであり、インターネット１６からアクセスしてきたユーザ端末１４と、例えばＨＴＴＰ等のプロトコルに従ってデータ通信を行うことでＷＷＷサーバとして機能する。
【００１３】販売者サーバー１２は、電子商店のＷＷＷサーバーとして機能し、ユーザはそのユーザ端末１４から販売者サーバー１２にアクセスすることで、当該電子商店から所望の商品の購入注文を行うことができる。本実施形態では、このように販売者サーバー１２にて行った購入注文に係わる代金決済が、決済サーバー１０を介して、決済用銀行に開設した購入者の口座から引き落とすことにより行われる。」（段落【００１１】−【００１３】）
　
　上記周知例１の記載からみて、ＷＷＷを用いた決済システムにおいて、インターネットを介して直接ユーザとデータの授受を行うＷＷＷサーバ等のサーバと振込等の決済処理を行うコンピュータを分離して構成することは周知技術（以下「周知技術１」という。）である。
　
［周知例２］
　当該技術分野の周知技術を開示する、本願出願前に公開された特開２００１−３５１０２４号公報には、図面と共に以下の事項が記載されている。
　「【００７０】本決済装置１ａは、図３に示すように、上記ウェブサーバ１００ａ、アプリケーションサーバ１００ｂ及びゲイトウェイ１２０を介してつながるメインフレーム１２１上に構成されている。すなわち、該決済装置１ａの構成は、通信手段２ａと、決済手段３ａとを有している。
【００７１】そのうち上記通信手段２ａは、上記ウェブサーバ１００ａで構成され、電子ショッピングサイトＳ側にあるＨＴＭＬ文を前記ブラウザ３０１が読み込み、そこに設定された接続先情報（或いは電子ショッピングサイトＳの商品発送後乃至サービス提供後請求してくる場合に送られる電子メールに含まれた接続先情報）に基づき、ユーザＡのブラウザ３０１が決済装置１ａの前記通信手段２ａにアクセスしてきた時に、ユーザＡのブラウザ３０１から、下記のような仕組みによって、上記振込依頼情報を受け取る構成である。尚、ウェブサーバ１００ａの上記通信装置１０７は、インターネット４００につながっており、そのため、上記ウェブサーバ１００ａは、インターネット４００を介して、上記電子ショッピングサイトＳのウェブサーバ２００、他のウェブサーバ、或いはユーザＡを含む多くのユーザサイドのコンピュータに接続できるようになっている。
【００７２】後述する図６に示されたボタンに組み込まれた接続先情報（ＵＲＬ情報）により、自動的に本決済装置１ａにあるページが開かれると、後述する図１６(ａ)に示されるようなジャバスクリプトによる「open」コマンドが上記ブラウザ３０１により実行され、別ウィンドウとして開かれて、上記振込依頼情報が、前記通信手段２ａに引き継がれる。
【００７３】また同図(ｂ)は、同一ウィンドウの中で遷移して、上記振込依頼情報を、前記通信手段２ａに引き渡す際に利用できるＨＴＭＬの「form」タグのハイパーリンク機能の記述例である。
【００７４】また上記決済手段３ａは、アプリケーションサーバ１００ｂ及びゲイトウェイ１２０を介してつながるメインフレーム１２１で構成されており、受け取った上記振込依頼情報に基づき、アプリケーションサーバ１００ｂで所定の振込の命令を出力し、メインフレーム１２１でその振込処理を実行する構成である。」（段落【００７０】−【００７４】）
　「【００７８】またユーザＡが商品の購入乃至サービスの提供の申し込みをした時点で、前記電子ショッピングサイトＳのアプリケーションサーバ２０１により、その商品の購入乃至サービスの提供を行う処理が実施される。他方、支払方法の選択処理で、上述のように、上記選択ボタンのクリックにより、本決済装置１ａを利用したインターネット４００上での振込処理によることが選択された場合は、上記ブラウザ３０１に対し、本決済装置１ａのＵＲＬ情報が与えられ、ユーザＡのブラウザ３０１は、自動的に本決済装置１ａの前記通信手段２ａにリンクされる。この時同時にブラウザ３０１上に上記ジャバスクリプトと共に振込依頼情報が、組み込まれる（図中）。
【００７９】該振込依頼情報の詳細は、取引識別番号（後述のＥＤＩ情報がある場合は省略）、電子ショッピングサイトＳの企業コード（本決済装置により予め割り振られている振込先情報）、振込依頼人番号或いはＥＤＩ情報（半角英数字２０桁以内と規定されている）、振込金額、振込処理完了時の戻りＵＲＬ情報（振込が完了した旨を電子ショッピングサイトＳで画面表示するため）、振込処理未完了時の戻りＵＲＬ情報（振込が行われなかった旨を電子ショッピングサイトＳで画面表示するため）などである。これ以外にも、該サイトが利用する認証方式（電子ショッピングサイトの要望により、電子認証書方式やＩＤパスワード方式などが選択可能）、電子ショッピングサイトの認証情報（電子認証書方式の場合認証局ＣＡの発行した電子認証書、ＩＤパスワード方式の場合ＩＤとパスワード）、振込先銀行コード、振込先支店コード、振込先科目コード、振込先口座番号などの情報を含んでいても良い。但し、本構成では、振込先銀行コード、振込先支店コード、振込先科目コード、振込先口座番号などの情報は、予め本決済装置１ａ側にユーザ情報として登録されており、前記企業コードが受け渡されることで、登録されたデータとの照合から、これらは明らかになる。
【００８０】上記ブラウザ３０１が本決済装置１ａの通信手段２ａに接続した際、所定のページが開かれ、上記ジャバスクリプトの実行により、別ウィンドウが開かれて、そこへ振込依頼情報が受け渡される（図中）。この接続の際、ユーザＡが画面の指示に従って入力する顧客ＩＤ及びパスワードと、予め本決済装置１ａ側に登録されているこれらのユーザ対応情報とを照合し、その照合結果が合致すれば（本人確認ができれば）、ログインが許可される（図中）。この照合によって、本決済装置１ａの設置された金融機関における振込依頼人側の口座も特定されることになる。
【００８１】ログイン後、本決済装置１ａにより、受け取った上記振込依頼情報に基づいて、振込処理内容が提示され、それに関して、ユーザＡの選択、書き込み・内容訂正・削除及び確認などの指示を待つ（図中）。
【００８２】これらの結果、ユーザＡがその振込処理内容にそのまま或いは訂正後同意する指示を出せば（図中）、その指示は通信手段２ａによって決済手段３ａに渡され、前記アプリケーションサーバ１００ｂにより、前記メインフレーム１２１に対し、振込指示命令が出力される。その命令に対し、メインフレーム１２１によって、振込依頼人の口座から上記振込金額に相当する金額の引き落としが可能か否かが判定され、該引き落としが可能である場合に、該振込依頼人の口座からその金額が引き落とされる。そして振込先が上記金融機関内の口座であれば、即座に振込処理がなされ、また他の金融機関の口座であれば、前記全銀ＥＤＩなどを利用して、該口座に対して振込処理が行われる。
【００８３】上述した振込処理完了時の戻りＵＲＬ情報が通知されている場合は、上記引落の成立と振込の完了の通知が、前記メインフレーム１２１より決済手段３ａに届いた時に、その通知は、前記取引識別番号（又はＥＤＩ情報）と共に、後述する図１７(ａ)に示すようなジャバスクリプトとして、アプリケーションサーバ１００ｂ上のＨＴＭＬ文に組み込まれる（或いは同図(ｂ)に示すように、ＨＴＭＬの「form」タグのハイパーリンク機能の記述としても良い）。同時に該ＨＴＭＬ文には、電子ショッピングサイトＳへ戻るボタンが組み込まれるが、該ボタンに、上記戻りＵＲＬ情報がセットされる。該ＨＴＭＬ文が、ユーザＡのブラウザ３０１に読み込まれ、ユーザＡにより上記ボタンがクリックされると、上記戻りＵＲＬ情報に従って、該ブラウザ３０１の画面が遷移する（図中）。該ブラウザ３０１には、元の電子ショッピングサイトＳの振込完了を示す画面が表示される（図中）。その際に、引落の成立と振込の完了が、電子ショッピングサイトＳのアプリケーションサーバ２０１に通知される。
【００８４】また振込処理未完了時の戻りＵＲＬ情報が通知されている場合は、上記引落の不成立と振込が完了していない旨の通知が、前記メインフレーム１２１より決済手段３ａに届いた時に、その通知は、前記取引識別番号（又はＥＤＩ情報）と共に、上述のようなジャバスクリプト（或いは「form」タグのハイパーリンク機能の記述）として、アプリケーションサーバ１００ｂ上のＨＴＭＬ文に組み込まれる。同時に該ＨＴＭＬ文には、電子ショッピングサイトＳへ戻るボタンが組み込まれるが、該ボタンに、上記振込処理未完了時の戻りＵＲＬ情報がセットされる。該ＨＴＭＬ文が、ユーザＡのブラウザ３０１に読み込まれ、ユーザＡにより上記ボタンがクリックされると、上記振込処理未完了時の戻りＵＲＬ情報に従って、該ブラウザ３０１の画面が遷移する（図中）。該ブラウザ３０１には、元の電子ショッピングサイトＳの振込ができなかったことを示す画面が表示される（図中）。その際に、引落の不成立又は振込の未完了が、電子ショッピングサイトＳのアプリケーションサーバ２０１に通知される。
【００８５】この構成では、主に、電子ショッピングサイトＳ側に対し、上記引落処理及びそれに続く振込処理が行われたこと或いは行われなかったことをリアルタイムで知らせることができるようになる。またこのＵＲＬ情報に従って画面遷移したブラウザ３０１は、それに基づき、元の電子ショッピングサイトＳの振込完了を示す画面又は振込が完了しなかったことを示す画面を、ユーザＡに表示する。
【００８６】この他、決済手段３ａから、前記通信手段２ａを介して、電子ショッピングサイトＳのアプリケーションサーバ２０１に通知される情報としては、本決済装置１ａが置かれる金融機関のコード、認証局ＣＡが発行した電子認証書である銀行認証情報、振込依頼人番号又はＥＤＩ情報、振込引落確認情報、振込金額などを含んでいても良い。」（段落【００７８】−【００８６】）
　
　上記段落【００７８】−【００８６】には、ＷＷＷを用いた決済システムにおいて、振込がメインフレームにより完了又は未完了となった場合、それぞれの場合について、その旨の情報が、アプリケーションサーバ、ウェブサーバを通じユーザブラウザに表示される技術が記載されており、当該技術は周知技術（以下「周知技術２」という。）であるといえる。
　また、上記段落【００７８】−【００８６】より、ＷＷＷを用いた決済システムにおいて、ユーザからサーバ上の取引情報の編集及び削除を行う技術は周知周知技術（以下「周知技術３」という。）であるといえる。
　さらに、周知例２にも上記周知技術１と同様に、ＷＷＷを用いた決済システムにおいて、インターネットを介して直接ユーザとデータの授受を行うＷＷＷサーバ等のサーバと振込等の決済処理を行うコンピュータを分離して構成する技術が記載されている。
　
［周知例３］
　当該技術分野の周知技術を開示する、本願出願前に公開された特開平１１−２１９３９４号公報には、図面と共に以下の事項が記載されている。
　「【０００４】
【課題を解決するための手段】本発明は、これらの課題を解決する手段として当該装置を提供する。この装置は、活字印書された財務諸表（貸借対照表、損益計算書、利益処分案、販売費及び一般管理費、製造原価明細書等）をスキャナーによりイメージ入力し、入力結果を記憶する手段がある。入力されたイメージは、ページ毎に管理され財務諸表の特徴を利用しデジタル文字に置換するプログラムを介してデジタル化する手段と、デジタル化された結果を勘定科目を表す文字列と数値（金額）に所定の方法で分割し、勘定科目が正確に変換されたかを自動チェックするための勘定科目辞書との突合チェック手段がある。さらに突合チェックにおいて勘定科目辞書の中に一致した文字列がない時、誤読文字が含まれる文字列として判定する。さらに、誤読文字を自動的に正しい文字に置換するための手段として、１つには誤読辞書置換機能があり、さらに高精度置換を計る機能として誤読辞書置換機能を補完するためのプログラム対応機能がある。」（段落【０００４】）
　「【００１０】さらに金額については、各財務諸表ごとのチェックと各大分類グループ、中分類グループ単位のチェック及び各財務諸表間との論理チェックについて会計処理の記載方法を利用したバランスチェック手段がある。バランスチェックにおいては、登録されているパターンを利用し、グループごとの大・中分類それぞれの金額とその属するグループ内の明細科目の金額を合算し会計処理の記載方法にあわせチェックする。アンバランスの時は、金額数値の誤読がある事になるんで赤字表示されたグループについて、バランスがあうまで修正を繰り返し、バランスがあったところで入力は、終了する手段を備えている。」（段落【００１０】）
　
　上記周知例３の記載からみて、個々の金額データと合計金額データが予め与えられている場合、個々の金額データの合計値と合計金額データとの照合を行うことにより、データの正当性をチェックする技術は周知技術（以下「周知技術４」という。）であるといえる。
　
［周知例４］
　当該技術分野の周知技術を開示する、本願出願前に公開された特開平２−２６００５４号公報には、図面（特に図４）と共に以下の事項が記載されている。
　「【特許請求の範囲】
　端末とホストコンピュータ間でファイルの転送を行う端末ホストコンピュータ間ファイル転送方式において、
　データファイルおよび送信済履歴、受信済履歴等の管理情報を保持管理するデータプール機構と、データ件数チェック手段と、問合せ処理手段とを含むファイル転送システムをホストコンピュータ側に設け、
　データ件数チェック手段を含むファイル転送システムを端末側に設け、
　１送受信単位内に複数の論理ファイルのそれぞれに対応するレコード群をその論理ファイルＩＤと一緒に含めるとともにレコード件数情報を持たせ、
　該レコード件数情報と実際に受信したレコード件数との比較を端末とホストコンピュータとに設けられた前記データ件数チェック手段でチェックし必要に応じて自動再送を行いながらファイル転送を進め、
　更に端末からの問合せ要求に対しホストコンピュータの前記問合せ処理手段が前記データプール機構を参照して問合せ結果を求めて端末に返答する構成を有することを特徴とする端末ホストコンピュータ間ファイル転送方式。」（特許請求の範囲）
　
　上記周知例４の記載からみて、データを転送する際に、転送するデータにデータ件数の情報を付加し、受信側でデータ件数のチェックを行う技術は、周知技術（以下「周知技術５」という。）であるといえる。
　
［周知例５］
　当該技術分野の周知技術を開示する、平成１８年６月１４日付け拒絶理由の通知において、周知例として提示された、本願出願前に公開された特開平９−１９０４８２号公報には、図面と共に以下の事項が記載されている。
　「【００１２】
【課題を解決するための手段】本発明は、ＯＣＲとコンピュータシステムとを利用して構成された帳票読取システムであって、予め設定された項目に対応する項目データ以外に、項目毎に定義された項目チェックデータが記録された帳票を使用する。
【００１３】システムは、ＯＣＲ手段から出力された項目データに基づいて、所定の帳票データ処理を実行するデータ処理手段および項目チェックデータに基づいて項目データの所定のチェック処理を実行するデータチェック処理手段を有する。
【００１４】データチェック処理手段は、項目チェックデータに基づいて、項目データが予め定義した内容と一致するデータ内容であるか否かをチェックする。項目チェックデータは、例えば対応する項目データの文字種、桁数、または年月日等の場合には使用される数字の範囲などを指定するデータである。
【００１５】データチェック処理手段は、項目チェックデータにより、例えば年月日の項目データとして読取られた読取データに、年月日としては有り得ない数字や文字が含まれていれば誤ったデータとして判定し、そのチェック結果を出力する。
【００１６】このようなシステムによれば、帳票を変更した場合でも、予め設定された項目チェックデータを使用することにより、修正処理用プログラムを変更する必要はない。また、読取対象として新たな帳票を追加した場合に、その帳票の項目データの中で、新たな項目データに関する項目チェックデータを追加するだけで、新たな修正処理用プログラムを作成する必要はない。」（段落【００１２】−【００１６】）
　
　上記周知例５の記載からみて、あるデータのデータ項目が、対応する文字種、数字の範囲等が指定されたものでない場合、誤ったデータであると判定する技術は、周知技術（以下「周知技術６」という。）であるといえる。
　
５．対比
　そこで、本願発明と引用例発明とを比較する。 
　引用例発明の「金融機関側コンピュータ」は、引用例には明示の記載はないものの、技術常識を勘案すると、振り込み処理等の各種銀行業務に関する処理をも合わせて行うことは明らかである。したがって、引用例発明の「金融機関側コンピュータ」は、本願発明の「データ授受サーバ装置」と「該データ授受サーバー装置との間で通信をするコンピューター」の機能を兼ね備えたものに対応する。
　してみれば、引用例発明の「金融機関側コンピュータ」と本願発明の「データ授受サーバー装置」及び「該データ授受サーバー装置との間で通信をするコンピューター」を合わせたものは、その顧客側の端末とデータを授受すると共にデータを処理する手段（以下「データ授受・処理手段」という。）であるという点で共通している。
　次に、引用例発明の「顧客側コンピュータ」は、本願発明の「データ授受サーバー装置との間で通信をする端末」に対応する。
　してみれば、引用例発明の「顧客側コンピュータおよび該顧客側コンピュータと接続される金融機関側コンピュータ」との点と、本願発明の「データ授受サーバー装置と、データ授受サーバー装置との間で通信をする端末」は、「データ授受・処理手段と、データ授受・処理手段との間で通信をする端末」であるという点で共通している。さらに、引用例発明の「顧客側コンピュータおよび該顧客側コンピュータと接続される金融機関側コンピュータを含む自動決済システム」と本願発明の「データ授受サーバー装置と、該データ授受サーバー装置との間で通信をする端末と、該データ授受サーバー装置との間で通信をするコンピューターとを具備するデータ授受システム」とでは、「データ授受・処理手段と、該データ授受・処理手段との間で通信をする端末とを具備するデータ授受システム」である点で共通している。
　引用例発明の「顧客社員データ登録手段」は、図５等を参酌すると、顧客社員データが「複数のデータ項目に対応した複数のデータ」を持つことが明らかであるから、本願発明の「複数のデータ項目に対応した複数のデータの入力を受け付ける受付手段」に相当する。
　引用例発明の「前記顧客社員データ登録手段により入力したデータを入出力制御部を介し前記金融機関側コンピュータへ転送し」との点と本願発明の「前記複数のデータと、該複数のデータの総件数についてのデータと、該複数のデータの合計請求金額についてのデータと、を含むデータファイルを送信する第１の送信手段」との点とでは、両者は「前記複数のデータを含むデータファイルを送信する送信手段」である点で共通している。
　引用例発明の「金融機関側コンピュータ」の「入出力制御部」は、そのデータファイルを受信する機能において、本願発明の「前記データ授受サーバー装置」の「前記データファイルを受信する受信手段」に対応する。
　引用例発明の「前記取引データに基づいて顧客との取引の受付の可否を決定する受付可否決定手段」との点と、本願発明の第１−４の判定手段とでは、その細部において相違するものの、「受信されたデータファイルが正当であるか否かを判定する手段」を具備する点で共通している。
　さらに、引用例発明の「前記受付可否決定手段は、前記顧客社員データ登録手段から入力した顧客社員データの形式が所定の形式に適合しない場合、エラー結果を含むデータを前記入出力制御手段を介し前記顧客側コンピュータへ転送する」との点と、本願発明の「前記正当記述データ記憶手段に正当記述データが記憶されている場合は前記正当記述データを前記端末に送信し、前記エラー情報記憶手段にエラー情報が記憶されている場合は前記エラー情報を前記端末に送信する記述データ送信手段」では、両者は、「エラー情報を端末に送信する送信手段」である点で共通している。
　
　よって、引用例発明と本願発明とでは、
　「データ授受・処理手段と、該データ授受・処理手段との間で通信をする端末とを具備するデータ授受システムにおいて、
　前記端末は、
　　複数のデータ項目に対応した複数のデータの入力を受け付ける受付手段と
　　前記複数のデータを含むデータファイルを送信する送信手段と、を具備し、
　前記データ授受サーバー装置は、
　　前記データファイルを受信する受信手段と、
　　受信されたデータファイルが正当であるか否かを判定する手段と、
　　エラー情報を端末に送信する送信手段、を具備する
　データ授受システム」との点で一致し、以下の点で相違する。
　
［相違点１］ 
　上記「データ授受・処理手段」に対応する構成として、本願発明は「データ授受サーバー装置」と「該データ授受サーバー装置との間で通信をするコンピュータ」との２つの装置を具備するのに対し、引用例発明は「該顧客側コンピュータと接続される金融機関側コンピュータ」との単体の装置から構成されるものである点。
　
［相違点２］ 
　本願発明の「端末」は、「前記複数のデータと、該複数のデータの総件数についてのデータと、該複数のデータの合計請求金額についてのデータと、を含むデータファイルを送信する第１の送信手段」を具備するのに対し、引用例発明では端末が金融機関側コンピュータに転送するデータに「該複数のデータの総件数についてのデータと、該複数のデータの合計請求金額についてのデータ」は含まれない点。
　また、当該点に関連し、本願発明は「前記読込手段が読み込んだデータの件数と、前記受信されたデータファイルに含まれている、複数のデータの総件数についてのデータとが一致している場合には、該受信されたデータファイルが正当なデータファイルであると判定する第２の判定手段」及び「前記読込手段が読み込んだデータの請求金額と、前記受信されたデータファイルに含まれている、複数のデータの合計請求金額についてのデータとが一致している場合には、該受信されたデータファイルが正当なデータファイルであると判定する第３の判定手段」を具備するのに対し、引用例発明は、当該手段に対応する手段は具備しない点。
　
［相違点３］ 
　本願発明の「データ授受サーバー装置」は、「前記受信されたデータファイルに含まれる各データについて、数字データのデータ項目に、対応する数字が入っている場合には該数字が該データ項目に対応した正当なデータであると判定し、文字データのデータ項目に、対応する文字が入っている場合には該文字が該データ項目に対応した正当なデータであると判定する第１の判定手段」を具備するのに対し、引用例発明は、「前記取引データに基づいて顧客との取引の受付の可否を決定する受付可否決定手段とを備え」るものである点。
　
［相違点４］
　本願発明の「データ授受サーバー装置」は、「前記受信されたデータファイルに含まれる各データを読み込む読込手段」を具備するのに対し、引用例発明では、特に対応する記載はない点。
　
［相違点５］
　本願発明の「データ授受サーバー装置」は、「前記第１の判定手段により、あるデータがデータ項目に対応した正当なデータであると判定されていない場合には、前記受信されたデータファイルに正当でないデータが含まれていると判定し、前記第２の判定手段および前記第３の判定手段の少なくともいずれか１つにより、前記受信されたデータファイルが正当なデータファイルであると判定されていない場合には、該データファイルに正当でないデータが含まれていると判定する第４の判定手段」を具備するのに対し、引用例発明は、「前記取引データに基づいて顧客との取引の受付の可否を決定する受付可否決定手段とを備え」るものである点。
　
［相違点６］
　本願発明の「データ授受サーバー装置」は、「前記第４の判定手段により、前記受信されたデータファイルに正当でないデータが含まれていると判定されていない場合には、該データファイルが正当である旨を記述した正当記述データを記憶する正当記述データ記憶手段」を具備するのに対し、引用例発明では、特に対応する記載はない点。
　
［相違点７］
　本願発明の「データ授受サーバー装置」は、「前記第４の判定手段により、前記受信されたデータファイルに正当でないデータが含まれていると判定されていない場合には、該データファイルが正当であるとして、該正当なデータファイルを記憶する正当データファイル記憶手段」を具備するのに対し、引用例発明では、特に対応する記載はない点。
　
［相違点８］
　本願発明の「データ授受サーバー装置」は、［前記第４の判定手段により、前記受信されたデータファイルに正当でないデータが含まれていると判定された場合には、前記受信されたデータファイルに含まれているデータと、前記対応する数字または前記対応する文字と、前記受信されたデータファイルに含まれている、複数のデータの総件数についてのデータおよび複数のデータの合計請求金額についてのデータと、前記読込手段が読み込んだデータの件数および請求金額とに基づいて、正当でないデータのエラーの詳細を示すエラー情報を生成する生成手段」及び「前記エラー情報を記憶するエラー情報記憶手段」を具備するのに対し、引用例発明では、特に対応する記載はない点。
　
［相違点９］ 
　本願発明の「データ授受サーバー装置」は、「前記正当記述データ記憶手段に正当記述データが記憶されている場合は前記正当記述データを前記端末に送信し、前記エラー情報記憶手段にエラー情報が記憶されている場合は前記エラー情報を前記端末に送信する記述データ送信手段」を具備するのに対し、引用例発明は「前記受付可否決定手段は、前記顧客社員データ登録手段から入力した顧客社員データの形式が所定の形式に適合しない場合、エラー結果を含むデータを前記入出力制御手段を介し前記顧客側コンピュータへ転送する」ものであり、特に、本願発明の「前記正当記述データ記憶手段に正当記述データが記憶されている場合は前記正当記述データを前記端末に送信し」との点に対応する点は引用例発明には存在しない点。
　
［相違点１０］
　本願発明の「データ授受サーバー装置」は、「前記正当データファイル記憶手段に記憶された前記正当なデータファイルを前記コンピューターに、１日当たりの設定された回数だけ送信する正当ファイル送信手段」を具備するのに対し、引用例発明は、対応する手段は具備しない点。
　
［相違点１１］
　本願発明の、「コンピューター」は、「前記正当ファイル送信手段により送信された前記データファイルを受信する受信手段と、前記受信されたデータファイルに含まれる各データに基づいて処理を行う処理手段と、前記処理が実行されたことを前記データ授受サーバー装置に送信する送信手段と、を具備」するものであるのに対し、本願発明の「コンピュータ」に一応対応する引用例発明の「金融機関側コンピュータ」は、当該各手段を具備しない点。
　
［相違点１２］
　本願発明の、「端末」は、「前記エラー情報および前記正当記述データのうちのいずれか１つを前記データ授受サーバー装置から受信する受信手段と、前記受信されたエラー情報または前記受信された正当記述データを表示する表示手段と、前記表示されたエラー情報に対応したデータを訂正する指示を受け付ける第２の受付手段と、前記訂正されたデータを含むデータファイルを前記データ授受サーバー装置に送信する第２の送信手段と、前記データ授受サーバー装置に記憶されているデータファイルを削除する削除手段」とを具備するものであるのに対し、引用例発明は、対応する手段は具備しない点。
　
６．当審の判断
　以下、上記相違点について検討する。 
［相違点１について］
　上述のように、ＷＷＷを用いた決済システムにおいて、インターネットを介して直接ユーザとデータの授受を行うＷＷＷサーバ等のサーバと振込等の決済処理を行うコンピュータを分離して構成する決済システムは、周知（周知技術１）である。
　よって、引用例発明に周知技術１を適用し、データ授受・処理手段として「金融機関側コンピュータ」をインターネットを介して直接ユーザとデータの授受を行うＷＷＷサーバ等のサーバと振込等の決済処理を行うコンピュータとを用いることは、当業者が適宜設計的になしえた事項である。
　したがって、本願発明の「データ授受サーバー装置と、該データ授受サーバー装置との間で通信をする端末と、該データ授受サーバー装置との間で通信をするコンピューターとを具備するデータ授受システム」との構成は、引用例発明及び周知技術１に基づき、当業者が適宜なしえた事項である。
　
［相違点２について］
　一般に、データを送信したり処理したりする際のデータフォーマットは、技術的に格別の困難がない限り、当業者が適宜設計的に決定できるものである。また、一般に、あるデータの正当性を確認するために、確認に用いるデータを付加して、当該データの通信及び各種処理を行うことは周知である。特に、データを転送する際に、転送するデータにデータ件数の情報を付加し、受信側でデータ件数のチェックを行う技術は周知（周知技術５）である。また、特に金銭情報を含むデータにおいて、個々の金額データと合計金額データが予め与えられている場合、個々の金額データの合計値と合計金額データとの照合を行うことにより、データの正当性をチェックする技術は周知（周知技術４）である。
してみれば、引用例発明の複数の振込等の請求金額の項目を含むデータを送信する際のデータフォーマットにデータの正当性を確認するためのデータとして、として、データの総件数及び合計請求金額を付加し、当該総件数及び合計請求金額を用いてデータの正当性のチェックを行うことは、当業者が容易に想到できた事項である。
　よって、送信するデータファイルに「該複数のデータの総件数についてのデータと、該複数のデータの合計請求金額についてのデータ」を含むようにすること、及び、データ授受サーバー装置が「前記読込手段が読み込んだデータの件数と、前記受信されたデータファイルに含まれている、複数のデータの総件数についてのデータとが一致している場合には、該受信されたデータファイルが正当なデータファイルであると判定する第２の判定手段」及び「前記読込手段が読み込んだデータの請求金額と、前記受信されたデータファイルに含まれている、複数のデータの合計請求金額についてのデータとが一致している場合には、該受信されたデータファイルが正当なデータファイルであると判定する第３の判定手段」を具備するよう構成することは、引用例発明及び周知技術４，５に基づき容易に想到できた事項である。
　
［相違点３について］
　上述のように、あるデータのデータ項目が、対応する文字種、数字の範囲等が指定されたものでない場合、誤ったデータであると判定する技術は周知（周知技術６）である。よって、引用例発明の「フォーマットチェック」の具体的な方法として、周知技術６を採用し、「前記受信されたデータファイルに含まれる各データについて、数字データのデータ項目に、対応する数字が入っている場合には該数字が該データ項目に対応した正当なデータであると判定し、文字データのデータ項目に、対応する文字が入っている場合には該文字が該データ項目に対応した正当なデータであると判定する第１の判定手段」となすことは、引用例発明及び周知事項６に基づき当業者が容易に想到できた事項である。
　
［相違点４について］
　引用例発明においても、受信されたデータファイルが正当であるか否かを判定する手段に相当する事項は記載されているのであるから、その前提として、引用例発明が「前記受信されたデータファイルに含まれる各データを読み込む読込手段」に相当する手段を具備することは明らかである。
　よって、相違点４は実質的な相違点とは認められない。
　
［相違点５について］
　上述のとおり、相違点２及び３で検討したように、金額を含む複数のデータからなるデータファイルが正しいか否かを判定する技術として、データの総件数によるもの、個々の金額と合計金額との比較によるもの、及び、各項目毎の文字や数字の正当性のチェックによるものは、何れも周知である。してみれば、データファイルの整合性のチェックの技術として、上記の技術を適宜組み合わせて採用することは、明らかに当業者の通常の創作能力の内のものといえる。
　してみれば、「前記第１の判定手段により、あるデータがデータ項目に対応した正当なデータであると判定されていない場合には、前記受信されたデータファイルに正当でないデータが含まれていると判定し、前記第２の判定手段および前記第３の判定手段の少なくともいずれか１つにより、前記受信されたデータファイルが正当なデータファイルであると判定されていない場合には、該データファイルに正当でないデータが含まれていると判定する第４の判定手段」は、引用例発明及び周知技術４−６に基づき、当業者が容易に想到できた事項である。
　
［相違点６について］
　引用例発明では、エラーがあった場合に「エラー結果を含むデータを前記入出力制御手段を介し前記顧客側コンピュータへ転送する」旨の記載があるのみで、エラーがない場合の動作については明示がない。
　しかしながら、ＷＷＷを用いた決済システムにおいて、振込がメインフレームにより完了又は未完了となった場合、それぞれの場合について、その旨の情報が、アプリケーションサーバ、ウェブサーバを通じユーザブラウザに表示される技術は周知（周知技術２）であるから、引用例発明において、エラーがない場合は、その旨のメッセージを送信するよう構成することは、当業者が適宜なしえた事項である。また、その際に、当該メッセージを一次的に記憶手段に記憶することも技術的に常套手段である。よって、「前記第４の判定手段により、前記受信されたデータファイルに正当でないデータが含まれていると判定されていない場合には、該データファイルが正当である旨を記述した正当記述データを記憶する正当記述データ記憶手段」は、引用例発明及び周知技術２に基づき当業者が容易に想到できた事項である。
　
［相違点７について］
　引用例発明においても、決済を行う以上、フォーマットチェックの結果が正しいデータファイルに基づいて決済を行うことは明らかであるから、フォーマットチェックの結果が正しいデータファイルを記憶しておく必要があることも明らかである。してみれば、本願発明の「前記第４の判定手段により、前記受信されたデータファイルに正当でないデータが含まれていると判定されていない場合には、該データファイルが正当であるとして、該正当なデータファイルを記憶する正当データファイル記憶手段」は、引用例発明には対応する明示の記載はないものの、引用例発明に基づき、当業者が容易に想到できた事項である。
　
［相違点８について］
　引用例発明においてもエラー結果を含むデータを顧客側コンピュータへ転送するものであるから、何らかの「エラー情報を生成する生成手段」及び「前記エラー情報を記憶するエラー情報記憶手段」に相当する手段を備えていることは明らかである。ここで、既に検討したとおり「前記受信されたデータファイルに含まれているデータと、前記対応する数字または前記対応する文字と、前記受信されたデータファイルに含まれている、複数のデータの総件数についてのデータおよび複数のデータの合計請求金額についてのデータと、前記読込手段が読み込んだデータの件数および請求金額とに基づいて」エラーの判定を行うことは、周知技術４及び５に基づき当業者が容易に想到できた事項である。さらに、エラー判定により得られるエラー情報として、どれだけ詳細な情報をユーザに提示するかは、当業者が適宜設計的に決定できた事項であるから、当該エラーの判定によって得られた「正当でないデータのエラーの詳細を示すエラー情報」を生成することも、当業者が容易に想到できた事項である。また、後続する処理のために、情報を記憶することも常套手段であるから、「前記エラー情報を記憶するエラー情報記憶手段」を具備することも、当業者が容易に想到できた事項である。
　よって、本願発明の相違点８に係る事項は、引用例発明及び周知技術４及び５に基づき当業者が容易に想到できた事項である。
　
［相違点９について］
　相違点６及び８について検討したとおり、正当記述データ及びエラー情報を端末に送信することは、周知である。この場合、「前記正当記述データ記憶手段に正当記述データが記憶されている場合は前記正当記述データを前記端末に送信し、前記エラー情報記憶手段にエラー情報が記憶されている場合は前記エラー情報を前記端末に送信する」よう「記述データ送信手段」を構成することも、情報処理としては、単に記憶手段の内容に応じて送信する情報を切り替えているだけであるから、当業者が容易に想到できた事項である。
　よって、本願発明の相違点９に係る事項は、引用例発明及び周知技術２，４及び５に基づき当業者が容易に想到できた事項である。
　
［相違点１０について］ 
　一般に、ホストコンピュータの処理の効率化、負荷の時間的分散化のために、データを纏めて送信・処理する所謂バッチ処理を採用することは、技術的に常套手段である。また、そのバッチ処理の頻度等についても、当業者が適宜設計的に決定できる事項である。
　よって、相違点１について検討したように、引用例発明に記載された「金融機関側コンピュータ」に替えて「データ授受サーバ」と「コンピュータ」に分割した構成の採用を検討する当業者が、併せてバッチ処理を行うか否か、さらに、バッチ処理を行う場合にはその頻度について検討することも、設計的になしえた事項である。
したがって、本願発明の「前記正当データファイル記憶手段に記憶された前記正当なデータファイルを前記コンピューターに、１日当たりの設定された回数だけ送信する正当ファイル送信手段」は、引用例発明及び周知技術１に基づき当業者が容易に想到できた事項である。
　
［相違点１１について］
　引用例発明においても、フォーマットチェックの結果が正しいデータファイルに基づいて、金融機関側コンピュータが決済を行うものであるから、「各データに基づいて処理を行う処理手段」は示唆されている。
　また、上述のようにＷＷＷを用いた決済システムにおいて、インターネットを介して直接ユーザとデータの授受を行うＷＷＷサーバ等のサーバと振込等の決済処理を行うコンピュータを分離して構成することは周知技術（周知技術１）である。
　よって、本願発明の「コンピューター」が、「前記正当ファイル送信手段により送信された前記データファイルを受信する受信手段と、前記受信されたデータファイルに含まれる各データに基づいて処理を行う処理手段と、前記処理が実行されたことを前記データ授受サーバー装置に送信する送信手段と、を具備」するよう構成することは、相違点１で検討したように、引用例発明の金融機関側コンピュータを周知技術に基づき、ＷＷＷサーバ及び決済処理等を行うコンピュータに分割して構成することを検討する際に、必然的に導かれる事項であり、引用例発明及び周知技術１に基づき当業者が容易に想到できた事項である。
　
［相違点１２について］
　まず、相違点３，４において、検討したとおり、正当記述データ及びエラー情報を端末に送信することは周知であることから、当該情報を端末において表示することも当業者が容易に想到できた事項であり、引用例には明示の記載はないものの、「前記エラー情報および前記正当記述データのうちのいずれか１つを前記データ授受サーバー装置から受信する受信手段と、前記受信されたエラー情報または前記受信された正当記述データを表示する表示手段」は、当業者が引用例発明及び上記周知技術６に基づき容易に想到できた事項である。
　次に、一般に、サーバ等に送信したデータを端末側から訂正及び削除する技術は周知であるところ、さらに、ＷＷＷを用いた決済システムにおいて、ユーザからサーバ上の取引情報の編集及び削除を行う技術は周知（周知技術３）である。
　してみれば、本願発明の、「端末」が、「前記表示されたエラー情報に対応したデータを訂正する指示を受け付ける第２の受付手段」と、「前記訂正されたデータを含むデータファイルを前記データ授受サーバー装置に送信する第２の送信手段」と、「前記データ授受サーバー装置に記憶されているデータファイルを削除する削除手段」を具備する点は、何れも、引用例発明及び周知技術３に基づき、当業者が容易に想到できた事項である。
　
　なお、請求人は、平成１８年８月２１日付け意見書（以下、単に「意見書」という。）で、上記相違点１及び１０に関し、以下のような意見を述べている。
「（６−２）　引用例の発明は、審判官殿が認定されていますように、「データ授受システム」が「該データ授受サーバー装置との間で通信をするコンピューター」を備えていません。本発明は、このコンピューターと、データ授受サーバー装置と、を備えています。
　本発明では、「データ授受サーバー装置」と「コンピューター」とが分離されていることにより、データ授受サーバー装置での処理とコンピューターでの処理を完全に分離することができます。したがいまして、たとえデータ授受サーバー装置の処理が膨大になったとしてオーバーフローが発生したとしても、コンピューターに影響を及ぼすことはあり得ません。特に、コンピューターが、例えば、大規模なデータを入力しこのデータに基づいて処理を行う大型のコンピューターなどのように貴重なリソースである場合には、本発明を適用すると、このような大型コンピューターを有効活用することができます。
　もし、「データ授受サーバー装置」と「コンピューター」とが同一の装置である場合には、膨大なデータを含むデータファイルが正当でない場合、コンピューターは結果的には無駄となる処理に多くのリソースを使用してしまい、また修正したデータファイルに基づいて再度膨大な時間がかかる可能性がある処理を行うことになります。したがいまして、データ処理を行うコンピューターが大型コンピューターや高速コンピューターのような貴重なリソースの場合、リソースの有効活用が図れなくなるだけでなく、期日までに処理しなければならないデータファイルを処理できないことにもなりかねません。
　また、データ授受サーバー装置は、「正当データファイル記憶手段に記憶された前記正当なデータファイルを前記コンピューターに、１日当たりの設定された回数だけ送信」します。
　データ授受サーバー装置がまだコンピューターに送信していない正当なデータファイルは、データ授受サーバー装置にあります。したがいまして、正当なデータファイルがデータ授受サーバー装置にある間は、端末から処理前の正当なデータファイルを削除することができます。例えば、端末のユーザーが正当なデータファイルをデータ授受サーバー装置に送信した後に、このデータファイルの処理が不要になった場合に、正当なデータファイルを削除することができます。これにより、データ授受サーバー装置から送信されるデータファイルを処理するコンピューターのリソースの無駄な使用を防止することができます。
　引用例には、「金融機関側コンピュータ」としての記載しかなく、本発明のように、端末から送信したデータファイルを、コンピューターでの処理前に、データ授受サーバー装置から削除することの思想は全く開示されていません。さらに引用例では、データ授受サーバー装置の処理とコンピューターとの処理を分離する旨の記載も示唆もありません。したがいまして、引用例から本発明のこの効果を引き出すことはできません。
　以上によりまして、審判官殿の、「コンピューター」を処理に応じて適宜分割し、本発明の「データ授受サーバー装置」と「該データ授受サーバー装置との間で通信をするコンピューター」とすることは、当業者が容易に想到できたもの、とのご指摘は到底承服できません。」
　しかしながら、上記意見は明らかに周知である上記周知例１，２に記載された周知技術を考慮しないものである。また、「大型コンピューターを有効活用することができ」る及び「データ授受サーバー装置から送信されるデータファイルを処理するコンピューターのリソースの無駄な使用を防止することができ」るとの効果も、当該周知技術から当然得られる効果であり、上記相違点１及び１０に関する判断を覆すものではない。
　
　次に、請求人は意見書において、相違点２，３及び５に関し、以下のような意見を述べている。
「（６−１）　本発明は、データ授受サーバー装置で、第１の判定手段が、受信されたデータファイルに含まれる各データについて、数字データのデータ項目に、対応する数字が入っている場合には該数字が該データ項目に対応した正当なデータであると判定し、文字データのデータ項目に、対応する文字が入っている場合には該文字が該データ項目に対応した正当なデータであると判定します。
　さらに、本発明は、データファイルには、含まれている複数のデータの総件数についてのデータと、含まれている複数のデータの合計請求金額についてのデータとが含まれていますので、データ授受サーバー装置では、第２の判定手段が、読み込んだデータの件数と、受信されたデータファイルに含まれている、複数のデータの総件数についてのデータとが一致している場合には、該受信されたデータファイルが正当なデータファイルであると判定し、第３の判定手段が、読み込んだデータの請求金額と、受信されたデータファイルに含まれている、複数のデータの合計請求金額についてのデータとが一致している場合には、該受信されたデータファイルが正当なデータファイルであると判定します。
　またさらに、第４の判定手段が、第１の判定手段により、あるデータがデータ項目に対応した正当なデータであると判定されていない場合には、受信されたデータファイルに正当でないデータが含まれていると判定し、第２の判定手段および第３の判定手段の少なくともいずれか１つにより、受信されたデータファイルが正当なデータファイルであると判定されていない場合には、該データファイルに正当でないデータが含まれていると判定します。
　データ項目のチェック等について、審判官殿は、「情報処理システム一般において、データファイル中の数字、文字等のデータ項目のチェックを行い、正当なデータファイルは、さらに処理を行い、正当でない場合は、ユーザ等にその旨表示等することは、周知である。また、この場合データファイルのフォーマットに応じて適宜判定ルールを定義し、これに基づいてチェックを行うことも周知である（例えば特開平０９−１９０４８２）」として、「本発明は当業者が容易に想到できたものである」と認定されていました。
　しかしながら、上記の本発明が行う第１、第２、第３、第４の判定手段で行われる判定は、周知の事項ではありません。例えば、特開平０９−１９０４８２（以下、周知例と称します）の段落［００１６］には、「予め設定された項目チェックデータを使用することにより、修正処理用プログラムを変更する必要はない。」、「新たな項目データに関する項目チェックデータを追加するだけで、新たな修正処理用プログラムを作成する必要はない。」との記載があり、周知例には、確かに、データに基づいて適宜判定ルールを変更することは開示されていますが、本発明で行っている判定については何の示唆すらありません。
　本発明は、第１の判定手段で、受信されたデータファイルに含まれる各データについて、数字データのデータ項目に、対応する数字が入っている場合には該数字が該データ項目に対応した正当なデータであると判定し、文字データのデータ項目に、対応する文字が入っている場合には該文字が該データ項目に対応した正当なデータであると判定し、第４の判定手段により、データファイルに正当でないデータが含まれているかどうかを判定することができ、端末のユーザーがデータファイルに含まれるデータのエラー情報の取得も可能にします。また、第２、第３の判定手段では、受信されたデータファイルが正当なデータファイルであるかを判定することにより、データファイルが正当なデータのみを含んでいるかを判定することができます。これら判定手段は、データファイルが正当なデータのみを含んでいるかを３重にチェックすることにより、データファイルが確実に正当なデータのみを含んでいることを判定することができます。このような３重のチェックによる判定は、本発明に特有のものであり、周知例および引用例（特開平１１−１０２４００号公報）に記載も示唆もありません。
　したがいまして、審判官殿の認定は到底承服できません。」
　しかしながら、上記意見は明らかに周知である上記周知例３−５に記載された周知技術を考慮しないものである。（周知例５については、上記摘記した意見で言及されているが、十分考慮されたものとはいえない。）
　すなわち、請求人が主張する「本発明で行っている判定」のうち、第１−３の判定手段で行われる各判定方法は、既に検討したとおり、周知例３−５から把握されるように何れも周知であり、これらの判定方法を適宜組み合わせることも、当業者にとって容易に想到できたことである。さらに、その効果も当業者にとって予想の範囲内のものである。
　よって、上記意見は、上記相違点２，３及び５に関する判断を覆すものではない。
　
　次に、請求人は意見書において、相違点６，８及び９に関し、以下のような意見を述べている。
「（６−３）　審判官殿が指摘されていますように、引用例の請求項４には、「前記受付可否決定手段は、前記データ入力手段から入力した顧客社員データの形式が所定の形式に適合しない場合、エラー結果を含むデータを前記金融機関側転送手段により前記顧客側コンピュータへ転送」するとの記載があります。すなわち、「データの形式が所定の形式に適合しない場合」、「金融機関側コンピュータ」から「顧客側コンピュータ」へ「エラー結果を含むデータを」「転送」しています。
　この請求項４に対応する記載である引用例の段落［００４５］の「取引可能と判断した場合は顧客側コンピュータ３００から顧客社員データ・ファイル・フォーマット５００の形式のデータを受信する（Ｓ１１５）。この受信したフォーマットのチェックの結果が正しいか否かを判断して（Ｓ１１７）、正しければ終了し、正しくなければ顧客側コンピュータに受付不可を送信する（Ｓ１４５）。これにより、従来、営業店を介して通知していたフォーマット・チェックの結果を、即座に顧客側へ伝えることができる。」を参照しますと、金融機関側コンピュータは、フォーマットのチェックの結果が正しくないと判断した場合に、顧客側コンピュータに送信するのは受信不可（フォーマット・チェックの結果）との結果だけでありますので、引用例の請求項４の「エラー結果を含むデータ」とは、「受信不可（フォーマット・チェックの結果）」のみを意味しています。また、引用例には、受信不可となったエラーの詳細について、「顧客側コンピュータ」へ送信するとの記載はありません。したがいまして、本発明が行うように「受信されたデータファイルに正当でないデータが含まれていると判定された場合には、前記判定基準と、前記受信されたデータファイルに含まれている、複数のデータの総件数についてのデータおよび複数のデータの合計請求金額についてのデータと、前記読込手段が読み込んだデータの件数および請求金額とに基づいて、正当でないデータのエラーの詳細を示すエラー情報」を生成し、「エラー情報を前記端末に送信する」ことは引用例に記載も示唆もありません。
　したがいまして、本発明が引用例から容易に推考しうるものであるとは決して認めることはできません。」
　しかしながら、上記意見は明らかに周知である上記周知例２−５に記載された周知技術を考慮しないものである。また、相違点６，８及び９については上記検討したとおりであるから、「本発明が行うように「受信されたデータファイルに．．．正当でないデータのエラーの詳細を示すエラー情報」を生成し、「エラー情報を前記端末に送信する」ことは引用例に記載も示唆もありません。」との上記意見は、採用できない。
　
　次に、請求人は意見書において、相違点９，１０に関し、以下のような意見を述べている。
　「（６−４）　引用例の図７、段落［００４４］、［００５０］の記載を参照しますと、引用例では、Ｓ１６０の「取引不成立の処理」後、および、Ｓ１５５の「取引成立の処理」後に、取引不成立であるか取引成立であるかの旨を「金融機関側コンピュータ３４０」から「顧客側コンピュータ３００」へ送信していません。
　さらに、引用例には、図９を参照して、「顧客の希望する取引額（振込額と手数料等）を集計」（Ｓ１２０）（段落［００５０］）し、「この取引額が顧客の与信ランクからみて妥当な範囲内にあるか否かを判断」（Ｓ１２５）（段落［００５０］）することにより、受け付け可否を決定するとの記載があります。この図９の場合でもＳ１６０の「取引不成立」後、および、Ｓ１５５の「取引成立」後に、取引不成立であるか取引成立であるかの旨を「金融機関側コンピュータ３４０」から「顧客側コンピュータ３００」へ送信していません。
　引用例の図９の場合には、さらに、Ｓ１３５で「顧客側コンピュータに受付可を送信」（段落［００５０］）しているにもかかわらず、Ｓ１６０で「取引不成立」になる場合があります。
　したがいまして、引用例の発明では、顧客側コンピュータが、受け付け不可、受け付け可を受信しても、それだけで取引成立か取引不成立かを確実に知ることはできません。
　一方、本発明は、「前記正当データファイル記憶手段に記憶された前記正当なデータファイルを前記コンピューターに、１日当たりの設定された回数だけ送信」し、かつ、「前記正当記述データ記憶手段に正当記述データが記憶されている場合は前記正当記述データを前記端末に送信し、前記エラー情報記憶手段にエラー情報が記憶されている場合には前記エラー情報を前記端末に送信」し、「前記コンピューター」は、「前記受信されたデータファイルに含まれる各データに基づいて処理を行」いますので、端末のユーザは、「正当記述データ」を受け取れば、データ授受サーバー装置に送信したデータファイルがコンピューターで処理されることがわかります。すなわち、引用例のように、「顧客側コンピュータに受付可を送信」しているにもかかわらず（「正当記述データ」を受け取っても）、取引が不成立（処理が行われない）であることは、本発明ではあり得ません。本発明は、端末が正当記述データを受け取れば、端末側から削除手段により意図的にデータ授受サーバー装置に記憶されているデータファイルを削除しない限り、コンピューターで必ず処理が行われ、端末が不当記述データを受け取ればコンピューターで必ず処理は行われません。
　したがいまして、本発明が引用例から容易に推考しうるものであるとは決して認めることはできません。」
　しかしながら、本願明細書段落【００６７】に「【００６７】
　また、それぞれの件数に対応して金額も表示される。すなわち、委託者がＷｅｂアプリケーションサーバー１１１に送信したデータファイル中で請求した合計金額、このデータファイル中のデータのうち、データが正当であると判定された件の合計金額、正当であると判定されたデータのうち他の金融機関等との間で決済が完了した件の合計金額、および、ユーザーから送信されたデータのうち判定基準により不能と判定された件および正当であると判定されたデータのうち他の金融機関等との間で決済をすることができなかった件の合計金額が表示される。」との記載がある。よって、「顧客側コンピュータに受付可を送信」しているにもかかわらず（「正当記述データ」を受け取っても）、取引が不成立（処理が行われない）であることは、本発明ではあり得ません。」との意見は失当であり、「したがいまして、本発明が引用例から容易に推考しうるものであるとは決して認めることはできません。」との意見は採用することができない。
　
　次に、請求人は意見書において、相違点１２に関し、以下のような意見を述べている。
　「（６−５）　引用例には、本発明の「表示されたエラー情報に対応したデータを訂正する」記載も示唆もありません。引用例の発明では、金融機関側コンピュータが受付可の決定を行った場合において、「顧客側から取引の決済の確認を受けたか否かを判断」（段落［００５０］）しているに過ぎず、金融機関側コンピュータが受付不可の決定を行った場合には「顧客側コンピュータ３００に受け付け不可を送信して（Ｓ１４５）終了する。」（段落［００５１］）との記載があるに過ぎません。引用例には、「顧客側コンピュータ」で、「金融機関側コンピュータ」に送信した「取引処理要求」［００４４］に対して訂正を行うことの記載も示唆もありません。引用例で本発明に対応する処理を行うためには、図９のＳ１５０で「取引の決済の確認」を「顧客側コンピュータ」で行わず、Ｓ１６０で取引不成立にした後で、修正した「取引処理要求」を新たに「金融機関側コンピュータ」に送信することが必要となります。しかし、引用例によりますと、「顧客側から取引の決済の確認を受けたか否かを判断し（Ｓ１５０）、受けた場合は取引成立の処理を行い（Ｓ１５５）、受けなかった場合は取引不成立の処理（Ｓ１６０）を行って終了」（段落［００５０］）しますので、引用例の発明では、「Ｓ１６０で取引不成立にした後で、修正した「取引処理要求」を新たに「金融機関側コンピュータ」に送信する」ことは行いません。また、引用例には、「取引の決済の確認」を「顧客側コンピュータ」で行わない記載も示唆もありません。したがいまして、図９のＳ１５０で「取引の決済の確認」を「顧客側コンピュータ」で行わず、Ｓ１６０で取引不成立にした後で、修正した「取引処理要求」を新たに「金融機関側コンピュータ」に送信することを引用例から行うことは想定されていません。 　したがいまして、審判官殿が指摘されています「ＮＧデータの原因となるエラー情報を生成する生成手段、及び、エラー情報記憶手段をさらに具備し、記述データ送信手段から不当記述データとして送信する程度のことは、当業者が適宜、引用例発明に付加し得たものである。」は到底承服できません。」
　しかしながら、上記意見は明らかに周知である上記周知例２に記載された周知技術を考慮しないものである。したがって、上記相違点１２について検討したとおりであり、上記請求人の意見は採用できない。
　
　次に、相違点１−１２を全体としてみた場合でも、引用例に記載された発明及び周知技術に基づいて、当業者が容易に想到できたと判断せざるを得ない。そして、本願発明の作用効果も、引用例、及び、周知技術から当業者が予測できる範囲のものである。
　よって、本願発明は、引用例発明、及び、周知技術に基づいて、当業者が容易に発明をすることができたものである。
　
７．むすび
　以上のとおり、本願の請求項１に係る発明は、引用例に記載された発明に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　
　したがって、本願の他の請求項について検討するまでもなく、本願は拒絶されるべきものである。