【事件の表示】
　特願２００２−２３７３７０「決済仲介方法」拒絶査定不服審判事件〔平成１５年　４月１８日出願公開、特開２００３−１１５０２３〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１　手続の経緯
　
　本件出願は，平成１３年５月２５日に出願した特願２００１−１５７５２４号の一部を平成１４年８月１６日に新たな特許出願としたものであって，平成１９年２月１５日付けで拒絶査定がなされ，これに対し，同年３月２９日に拒絶査定に対する審判請求がなされた。そして，当審において，平成２１年１０月３０日付け拒絶理由通知に対し，同年１２月９日付けで手続補正がなされたものである。
　
　
第２　本件発明
　
　平成２１年１２月９日付け手続補正により補正された，補正前請求項３に対応する請求項１に係る発明（以下，「本件発明」という。）は，以下のとおりのものである。（下線は，補正箇所を示すため，請求人が付加したものである。）
　
「【請求項１】
　通信ネットワークを通じて，外部システムである購入者システム及び販売者システムと接続し得る決済仲介システムを介して，該決済仲介システムが備えたプログラムにより下記ステップを実行して
クレジットカードの
　
決済仲介システムは，販売者に対して販売者識別番号を割り当て，該販売者識別番号と販売者システムの端末識別番号とを関連付けて蓄積するステップ，
　
購入者システムは，購入者システムを識別する購入者システム識別情報と，届け先情報とを含む注文情報を，販売者システムに送信するステップ，
　
販売者システムは，前記注文情報を受信したら，運送料金を含む決済総額情報と，届け先情報と，購入者システム識別情報とを包含する注文情報を，決済仲介システムに送信するステップ，
　決済仲介システムが，購入者システム識別情報と，
運送料金を
前記
届け先情報と
　決済仲介システムが，上記ステップにて注文情報を受信したら，当該注文情報中の購入者システム識別情報に基づいてその購入者システムに対し，与信処理開始の依頼と決済仲介システムへのアクセス情報とを送信するステップ，
　決済仲介システムが，上記購入者システムからアクセス要求があったら，蓄積している取引情報のうち少なくとも決済総額情報を含む注文情報と，クレジットカード情報など与信処理に必要な情報の要求とを購入者システムに送信するステップ，
　決済仲介システムが，当該購入者システムから与信処理に必要な情報を受信したら，その与信処理に必要な情報を与信処理センターサーバに送信するステップ，
　決済仲介システムが，当該与信処理センターサーバから与信処理結果を受信したら，自動的或いは要求に応じて，購入者システム又は販売者システム或いは両システムに対して当該与信処理結果を送信するステップ，
　を包含してなる決済仲介方法。」
　
　
第３　当審の拒絶の理由について
　
　当審において，平成２１年１０月３０日付けで通知した拒絶の理由の概要は以下のとおりである。
　
「［理由Ａ］
　本件出願の下記の請求項に係る発明は，その出願前日本国内又は外国において頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて，その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許を受けることができない。
　
　
　　　　　記　　　（引用文献等については引用文献等一覧参照） 
　
引用文献等一覧
　
引用例１：特開平１１−３１６７２９号公報
引用例２：特開２０００−１４８８４１号公報
引用例３：大竹剛，アコム：毎月２割が利用する電子決済，１万会員突破の「アコシス」，日経マルチメディア，日経ＢＰ社，１９９８年９月１５日，第３９号，ｐ．９８〜１０３
引用例４：特開平９−１６７１８５号公報
　
（途中略）
　
４．請求項３，４に係る発明について
　請求項３，４に係る発明は，それぞれ，請求項１，２に係る発明と単にカテゴリーが相違するだけであるから，請求項３，４に係る発明については，実質的に上記１．及び２．で検討したとおりであるので，特許法２９条２項の規定により特許を受けることができないものである。
　
　したがって，請求項３，４に係る発明は，引用発明及び引用例２〜４に記載された事項に基づいて当業者が容易に発明をすることができたものである。
　
（以下略）」
　
　
第４　審判請求人の主張の概要
　
　審判請求人は，平成２１年１２月９日付け意見書により，次のように主張する。
　
「（３）引用発明との対比
（イ）　合議体は，引用文献１（特開平１１−３１６７２９号公報）を主引例として，本願請求項１に係る発明（「本発明１」と称する）の進歩性を否定する論理付けを構築されておられます。
　しかし，引用文献１記載の発明（「引用発明１」と称する）は，その【０００９】などを読めば明らかでありますように，クレジットカードを所有しない人でも利用可能にすることを目的とする発明ですので，技術常識的に考えましても，本発明１のように，クレジットカードの与信処理に関する発明を想到する際の基礎にはなり得ません。明らかな阻害要因であると言えます。
　電子商取引などの分野における発明の審査においては，いくら広い分野から引用文献が採用されると申しましても，この引用発明１は，その主目的がクレジットカードを利用しないことですので，クレジットカードの与信処理に関する本発明１を想到する際の基礎となり得ないことは，明らかであります（争点１）。
（ロ）　引用文献２（特開２０００−１４８８４１号公報）の記載内容を見ますと，この文献に記載された決済処理が，クレジットカードの与信処理と関係ある旨の記載は見当たりません。よって，引用文献２に記載された決済完了までの流れと，本発明１における与信処理までの流れとを結び付ける合理的な理由が認められません（争点２）。
（ハ）　引用文献２の記載内容中には，決済金額の計算に「運送料金」を加算することは記載されていません。しかも，【００７３】を読みますと，「決済サーバ１２０において，請求額の引き落としなどの清算を行って店舗に支払う機能等が必要となるが，これらの機能は，一般的な商品配送や入出金システムとして実現可能であるため，その詳細な説明は省略する。」と記載されています。つまり，商品発送については，一般的な商品配送システムで実現可能であるから，商品配送に関しては引用発明２のシステムから意識的に除外している訳ですから，このような記載は，引用文献２に記載された決済金額の計算に「運送料金」を加算することを想到する際の阻害事由になるものと認められます。また，引用文献２のその他の記載内容を見ましても，決済金額の計算に加算する「手数料」として「運送料金」を想到するに足りる合理的な理由がありません（争点３）。
（二）　引用文献１などを読みましても，決済仲介システムに相当するシステムが，販売者に対して販売者識別番号を割り当て，該販売者識別番号と販売者システムの端末識別番号とを関連付けて蓄積する旨は記載されていません（争点４）。
（ホ）　本発明１では，販売者システムは，購入者システムから注文情報を受信したら，届け先情報を包含する注文情報を決済仲介システムに送信し，決済仲介システムでは届け先情報を蓄積します。これに対し，引用文献１及び引用文献２などを読みましても，届け先情報を包含する注文情報を決済仲介システムに送信する旨も，決済仲介システムが届け先情報を蓄積する旨も記載されておりません。引用文献１及び２の発明においては，そもそも届け先情報を決済仲介システムに送信して蓄積する技術的意味がありませんので，引用文献１及び２の発明に基づいて本発明１を想到し得るはずがありません（争点５）。」
　
　
第５　当審の判断
　
１．引用例　
　
（１）当審拒絶理由で引用した引用例１（特開平１１−３１６７２９号公報）には，図面とともに，次の記載がある。（下線は，当審で付加した。）
　
（ア）「【０００１】
【発明の属する技術分野】本発明は，インターネット課金方法及びシステム及びインターネット課金プログラムを格納した記憶媒体に係り，特に，インターネット上での有料サービスの利用に対する課金を実現するためのインターネット課金方法及びシステム及びインターネット課金プログラムを記録した記録媒体に関する。」
　
（イ）「【００２４】図１は，本発明の動作の概要を説明するためのシーケンスチャートである。まず，プリペイドカード（ＩＣカード，フロッピーディスク，磁気カード等）に設定されたコンテンツサーバのアドレス情報（例えば，ＨＴＴＰにおけるＵＲＬ）に基づいて，
端末からコンテンツサーバに対し有料サービス利用要求が発行される
コンテンツサーバはプリペイドカードの認証及び課金処理を行うことをカード管理サーバに要求し
カード管理サーバは端末との間でカードの認証を行い
認証・課金処理結果をコンテンツサーバに返却する
【００２５】図２は，本発明の一実施例のインターネット課金システムの接続構成の概要を示す図である。
端末１００は，インターネット４００を介してコンテンツサーバ２００との間でコネクション１１を設定し，当該コネクション１１を利用して有料サービスの利用を要求する。コンテンツサーバ２００は，端末１００からの有料サービス利用要求を受けると，カード管理サーバ３００との間にコネクション１２を設定し，当該コネクション１２を利用して，端末１００のＩＰアドレスを送信することにより，プリペイドカードの認証要求及び課金処理要求を行う
【００２６】
カード管理サーバ３００は，コンテンツサーバ２００からの認証要求を受けると，端末１００との間にコネクション１３を設定し，端末１００に対してプリペイドカードのパスワードの演算を要求する。端末１００は，コネクション１３を利用して，カード管理サーバ３００にパスワードの演算結果を送信する。
カード管理サーバ３００は，カードＩＤからパスワードを検索し，端末１００と同一の演算を行ない，送られてきた演算結果と一致すれば，認証成立とする
【００２７】
カード管理サーバ３００は，認証処理及び課金処理終了後，認証結果及び課金処理結果をコンテンツサーバ２００に通知する
認証処理または，課金処理が成立しなかった場合に，コンテンツサーバ２００は，端末１００に対してコネクション１１を利用してカードが使用不可能であることを通知する
【００２８】次に，本発明のインターネット課金システムの構成を説明する。図４は，本発明の一実施例のインターネット課金システムの構成を示す。同図に示す構成は，
プリペイドカードに設定されたコンテンツサーバアドレス情報に基づいてコンテンツサーバ２００にアクセスし，コンテンツサーバ２００の提供する有料サービスの利用を要求する端末１００
当該端末１００からの要求を受けて端末１００に対して有料サービスを提供するコンテンツサーバ２００
コンテンツサーバ２００からの要求を受けてプリペイドカードの認証と，プリペイドカードに対する課金を行うカード管理サーバ３００
【００２９】
端末１００は
コンテンツサーバ２００との間に自動的にコネクションを確立し，有料サービスの利用を要求する
カード管理部１０２は
カード管理サーバ３００からの要求に基づいて，プリペイドカードに格納されたカードＩＤを送信する機能
カード管理サーバ３００からの要求に基づいてプリペイドカードに格納された機密情報（パスワード等）を
カード管理サーバ３００に送信する機能
【００３０】
コンテンツサーバ２００は
端末１００から有料サービスの利用要求があった場合に，カード管理サーバ３００に対してプリペイドカードが正しいものかどうかの認証要求を行う機能を有し
カード管理サーバ３００に対してプリペイドカードに対する課金を要求する機能を有し
【００３１】また，上記の
カード管理サーバ３００は
コンテンツサーバ２００からの認証要求があった場合に，端末１００に対してプリペイドカードの認証を行う機能を有し
有料サービスの利用度合いに応じた課金処理をプリペイドカードに対して実施する機能
　
（ウ）「【００３３】ステップ２０１）  端末１００は，プリペイドカードに設定されたコンテンツサーバアドレス情報（例えばＵＲＬ）を用いて，当該アドレスを有するコンテンツサーバ２００との間にコネクションを設定し，サービスメニューを要求する。。
ステップ２０２）  コネクションが設定されると，コンテンツサーバ２００からVideo のリストなどのサービスメニューが送信される。
【００３４】ステップ２０３）  
ユーザが利用したいサービスを選択すると，コンテンツサーバ２００に対して選択したサービスを利用するために必要なサービス利用ポイント数が設定されたサービス利用要求メッセージが送信される
ステップ２０４）
コンテンツサーバ２００は，カード管理サーバ３００との間にコネクションを設定し，当該コネクションを利用して，端末１００のＩＰアドレスを設定した認証要求メッセージを送信することにより，カード管理サーバに対してプリペイドカードが正しいプリペイドカードか否かの認証要求を行う。また，同時に，カード管理サーバ３００に対して利用サービスのサービス度数を設定した課金処理要求メッセージを送信することにより，課金処理を要求する
【００３５】ステップ２０５）
カード管理サーバ３００は，受信した認証要求メッセージ中の端末１００のＩＰアドレスに基づいて端末１００との間にコネクションを設定し，当該コネクションを利用して，端末１００にカードＩＤを要求する
ステップ２０６）
端末１００はプリペイドカードに格納されたカードＩＤをカード管理サーバ３００に送信する
　
（エ）「【００３９】ステップ２１０）  
カード管理サーバ３００は，カードＩＤを基にデータベースを検索し，該当するカードのサービス利用ポイントの残度数が，課金処理要求メッセージに設定されたサービスポイントより大きければ，該当するカードのサービス利用ポイントを課金処理要求メッセージに設定されたサービスポイント数だけ減算する
【００４０】該当するカードのサービス利用ポイントの残度数が，課金処理要求メッセージに設定されたサービスポイントより小さければ，課金処理不可能とし，処理を終了する。
ステップ２１１）カード管理サーバ３００が端末に対してプリペイドカードの残高，利用日時を通知する。
【００４１】ステップ２１２）  
コンテンツサーバ２００に対して，認証・課金処理結果を通知する。認証・課金処理不可能の場合，処理を終了する
ステップ２１３）  端末１００に対して有料サービスを提供する。図６は，本発明の一実施例の端末１００の制御のフローチャートである。図６を用いて端末の動作を説明する。」
　
（ａ）カード管理サーバ３００はコンピュータであることから，カード管理サーバ３００は，所定の機能を実現するためのプログラムを備えていることは明らかである。
　
（ｂ）上記摘記事項（イ）及び（エ）から，カード管理サーバ３００からコンテンツサーバ２００へ認証・課金処理結果が自動的に送信されることは明らかである。
　
　そうすると，引用例１には次の発明（以下，「引用発明」という。）が記載されている。
　
「インターネットを通じて，外部のものである端末１００及びコンテンツサーバ２００と接続し得るカード管理サーバ３００を介して，該カード管理サーバ３００が備えたプログラムにより下記ステップを実行してプリペイドカードの認証・課金処理を行う方法であって，
　端末１００は，サービス利用要求メッセージをコンテンツサーバ２００に送信するステップ，
　コンテンツサーバ２００は，前記サービス利用要求メッセージを受信したら，利用サービスのサービス度数を設定した課金処理要求メッセージと，端末１００のＩＰアドレスを設定した認証要求メッセージとをカード管理サーバ３００に送信するステップ，
　カード管理サーバ３００が，ＩＰアドレスを設定した認証要求メッセージと利用サービスのサービス度数を設定した課金処理要求メッセージをコンテンツサーバ２００から受信するステップ，
　カード管理サーバ３００が，上記ステップにて課金処理要求メッセージと認証要求メッセージを受信したら，コンテンツサーバ２００から受信した前記認証要求メッセージの中のＩＰアドレスに基づいて端末１００に対し，カードＩＤの要求を端末１００に送信するステップ，
　カード管理サーバ３００が，当該端末１００からカードＩＤを受信したら，カードのサービス利用ポイントの残度数が課金処理要求メッセージに設定されたサービス度数より大きいか判断し，自動的に，コンテンツサーバに対して認証・課金処理結果を通知するステップ，
　を包含してなる認証・課金処理方法。」
　
（２）当審拒絶理由で引用した引用例２（特開２０００−１４８８４１号公報）には，図面とともに，次の記載がある。（下線は，当審で付加した。）
　
（ア）「【０００１】
【発明の属する技術分野】本発明は，例えば，
インターネット等の公用ネットワークにおいて，一般利用者が利用するオンラインショッピング等の決済を行うための受注処理装置，決済処理装置，決済処理システム，及びそれを実施するための処理ステップをコンピュータが読出可能に格納した記憶媒に関するもの
　
（イ）「【００３３】（第１の実施の形態）本発明は，例えば，図１に示すような決済システム１００に適用される。
【００３４】＜システム構成＞決済システム１００は，上記図１に示すように，
店舗サーバ１１０と，決済サーバ１２０と，本システムの利用者（顧客）側の端末装置（クライアントコンピュータ）１４０（１），１４０（２），・・・，１４０（Ｎ）とが，ネットワーク１３０を介して接続された構成としている
【００３５】
クライアントコンピュータ１４０（１），１４０（２），・・・，１４０（Ｎ）は
顧客が自宅から直接操作を行うための情報処理装置
その利用者の要求に応じて，ネットワーク１３０に接続して，ネットワーク１３０を介して店舗サーバ１１０及び決済サーバ１２０とデータ交換を行う機能を備えている
【００３６】
店舗サーバ１１０は，商品の販売を行う業者（商品販売業者）が維持運営する情報処理装置
店舗サーバ１１０は，ネットワーク１３０と常時接続しており，ネットワーク１３０を介してクライアントコンピュータ１４０（Ｘ）に上記商品情報を提示してクライアントコンピュータ１４０（Ｘ）からの注文情報を受注するためのデータ交換を行う機能と，ネットワーク１３０を介して決済サーバ１２０との間でデータ交換を行う機能と，商品対価の決済が完了した場合に商品を顧客に届けるために必要な処理の全て又は一部を行う機能をも備えている
【００３７】
決済サーバ１２０は，商品購入時の顧客の対価支払を上記商品販売業者に代行する，所謂決済代行を行う業者（決済代行業者）が維持運営する情報処理装置である
決済サーバ１２０も，ネットワーク１３０に常時接続しており，ネットワーク１３０を介して店舗サーバ１２０から決済が必要な商品の情報を受け取る機能と，同じくネットワーク１３０を介してクライアントコンピュータ１４０（Ｘ）とデータ交換を行ってその利用者（顧客）を認証して上記商品情報に基づいてクライアントコンピュータ１４０（Ｘ）との間で決済処理を行う機能と，該決済処理の結果を店舗サーバ１２０が取得できるようにする機能
【００３８】
ネットワーク１３０は，クライアントコンピュータ１４０（Ｘ），店舗サーバ１１０，及び決済サーバ１２０を接続する接続手段であって，例えば，インターネット等のネットワークシステムである
　
（ウ）「【００７１】決済予定格納装置３５１は，店舗サーバ１１０の注文受注手段３１３から送信されてきた決済予定データを格納する。
この決済予定データは，少なくとも注文番号と決済金額で構成される
この認証情報は，例えば，決済サーバ１２０を利用可能な利用者のＩＤとパスワード及び該利用者の決済方法（例えば，銀行口座の口座番号やクレジットカード番号）等によって構成される
　
（エ）「【００７３】また，実際に，いわゆるオンラインショッピングシステムを実現するためには，
店舗サーバ１１０において，本注文格納装置３２３の情報に基づいて実際の商品を利用者に配送する機能や，決済サーバ１２０において，請求額の引き落としなどの清算を行って店舗に支払う機能等が必要となるが，これらの機能は，一般的な商品配送や入出金システムとして実現可能である
【００７４】また，１つの店舗サーバ１１０に対し複数の決済サーバ１２０を利用する，或いは１つの決済サーバ１２０が
複数の店舗サーバ１１０からの決済処理を行うという構成にした場合
一方の決済サーバ１２０においても，注文受注手段３１３から受信するデータ項目や，決済結果格納装置３５３に格納する決済結果データに対して，店舗サーバを識別する識別子を用意して，必要に応じて，店舗サーバ毎に決済結果受信手段３１４への伝送データを区別するようにする
　
（オ）「【０１２６】ステップＳ４：クライアントコンピュータ１４０（Ｘ）の閲覧・指示手段３０１は，店舗サーバ１１０の商品情報提供手段３１２から送信されてきた表示用データを受信し，その表示用データの内容に基づいて画面を編集し，それをＣＲＴ２０６上に表示させる。
ステップＳ５：
クライアントコンピュータ１４０（Ｘ）の利用者は，ＣＲＴ２０６に表示されている商品情報に基づいて，希望する商品をＫＢ２０８等を用いて入力する。閲覧・指示手段３０１は，その入力された注文を解析し，店舗サーバ１１０の注文受注手段３１３が解析可能な形式の付加データを作成して，それを注文データとして注文受注手段３１３に対して送信する
【０１２７】ステップＳ６：店舗サーバ１１０の注文受注手段３１３は，クライアントコンピュータ１４０（Ｘ）の閲覧・指示手段３０１から送信されてきた注文データ（付加データ）を受信し，それをＲＡＭ２０２に記憶しておく。
ステップＳ７：
注文受注手段３１３は，ステップＳ６で記憶した注文データに対して，一意に定まる注文番号を発番し，さらに該注文データに含まれる商品コードを用いて，それに対応する商品の単価を商品情報格納装置３２１から検索して取得する。そして，該注文データに含まれる数量を元にして，注文に対して請求すべき決済金額を計算する
【０１２８】尚，ステップＳ７での注文番号は，ここでは各注文を一意に識別するための識別子であって，注文受注手段３１３が，処理時のタイムスタンプ等を使用することによって作成した，一意の注文番号である。また，
決済金額の計算については，手数料や消費税額の計算及び決算額への上乗せを行う
　
（カ）「【０１３３】ステップＳ１３：
店舗サーバ１１０の注文受注手段３１３は，予め設定しておいた決済サーバ１２０の決済手段３４３を示す閲覧データ識別子を指定することにより，例えば，ＷＷＷ機能におけるサーバリダイレクトの方法を用いて，決済サーバ１２０の決済手段３４３に制御を移行する
閲覧データ識別子に付加する付加データとして，少なくともステップＳ７で発番した注文番号を用いるようにする
【０１３４】ステップＳ１４：
決済サーバ１２０の決済手段３４３は，注文受注手段３１３から送信されてきた付加データ（注文番号）を受信し，ＲＡＭ２０２に記憶する
ステップＳ１５：
決済手段３４３は，クライアントコンピュータ１４０（Ｘ）の閲覧・指示手段３０１に送信すべき，閲覧・指示手段３０１が解析可能な形式，例えば，ＨＴＭＬ形式の決済用初期画面の表示用データを編集し，それを閲覧・指示手段３０１に対して送信する
【０１３５】尚，ステップＳ１５で作成される表示用データには，後述するステップＳ１６で閲覧・指示手段３０１によってクライアントコンピュータ１４０（Ｘ）のＣＲＴ２０６上に画面が表示される際に，決済手段３４３がクライアントコンピュータ１４０（Ｘ）の利用者を認証するために必要となるデータ項目（ユーザＩＤ等）が入力可能な画面データを，閲覧・指示手段３０１が作成できるようなデータ，例えば，ＨＴＭＬの場合，上記図６に示した”４５２”部分のデータが含まれる。また，ステップＳ１４で記憶した注文番号についても，後述する図９に示す，上記図８の前半処理に続く後半処理において利用できるように，例えば，ＨＴＭＬの場合，上記図６に示した”４５２”部分のデータを，上記表示用データに含めておく。この場合，”ＴＹＰＥ＝ＨＩＤＤＥＮ”と指定し，クライアントコンピュータ１４０（Ｘ）のＣＲＴ２０６上に注文番号が表示されないようにしておくことも可能である。また，上記図６に示した”４５１”部分に記述する，決済手段３４３の閲覧データ識別子の付加データとして，注文番号の値を指定しておくことも可能である。この場合，さらに，注文番号を，上記の方法以外に決済サーバ１２０のＨＤＤ２０９等に記録しておくことも可能である。
【０１３６】ステップＳ１６：
クライアントコンピュータ１４０（Ｘ）の閲覧・指示手段３０１は，決済サーバ１２０の決済手段３４３から送信されてきた決済用初期画面の表示用データを受信して解析し，それをＣＲＴ２０６に表示させる
【０１３７】上述したような前半処理により，クライアントコンピュータ１４０（Ｘ）側において，
その利用者は，店舗サーバ１１０に対して商品情報の表示画面をＣＲＴ２０６上に呼び出し，ＫＢ２０８を操作して，その表示画面に対して，所望の商品及び数量を一つ以上指定すれば，決済サーバ１２０からの決済用画面がＣＲＴ２０６上に表示されることになる
　
（キ）「【０１４４】ステップＳ２１：クライアントコンピュータ１４０（Ｘ）の閲覧・指示手段３０１は，上記図８のステップＳ１６で
ＣＲＴ２０６上に表示された決済用初期画面にて利用者がＫＢ２０８等を用いて入力した，例えば，ユーザーＩＤとパスワードや，プリペイドカードのパスワード等の認証情報データを読み取り，それを決済サーバ１２０の決済手段３４３が認識可能な付加データとして，決済手段３４３に対して送信する
決済すべき注文の注文番号も送信されていた場合には，その注文番号も付加データの一部として送信する
　
（ク）【０１４７】ステップＳ２３：決済手段３４３は，ステップＳ２２で
認証情報の照合が正しく行われた場合，すなわち認証に成功した場合に
注文番号を元に，決済予定格納装置３５１を検索して該当する決済金額を読み込み，さらにその決済金額等を元にして，利用者が決済金額を確認して決済指示を出すための決済確認画面の表示用データを編集し，それをクライアントコンピュータ１４０（Ｘ）の閲覧・指示手段３０１に対して返信する
　
（３）当審拒絶理由で引用した引用例３（（大竹剛，アコム：毎月２割が利用する電子決済，１万会員突破の「アコシス」，日経マルチメディア，日経ＢＰ社，１９９８年９月１５日，第３９号，ｐ．９８〜１０３）には，図面とともに，次の記載がある。
　
（ア）「ＩＤとパスワードで簡単に商品を注文できることもあり，アコシスは会員の２割が毎月利用する”使われる”サービスに育った。インターネット専用の電子決済としての座を固めつつある。」（第９８ページ右欄下から５行〜同欄最下行）
　
（イ）「注文から発送まで最短２分で処理
　アコシスを使ったショッピングの基本的な流れを見てみると，まず会員は加盟店のホームページにアクセスして商品を注文（図２）。すると注文内容がリンク先のアコシスのホームページに自動的に転送され，そこでは会員がＩＤとパスワードを入力する。入力が終わるとすぐに商品購入の意志確認のための電子メールが会員に届き，会員が「Ｙｅｓ」と入力して返信すれば，注文が完了する仕組みである。
　その後の加盟店とアコシスの販売データの受け渡しなどは，電子メールでやり取りする。加盟店には後日，会員の登録口座から引き落とされた代金から手数料を差し引いた金額が振り込まれる，という流れになる。」(第１０１ページ中欄第１行〜同欄第１８行）
　
（ウ）「ご注文（送料・消費税を含む）」とするホームページ画面が記載されている。（第１００ページ画面３）
　
（４）当審拒絶理由で引用した引用例４（特開平９−１６７１８５号公報）には，図面とともに，次の事項が記載されている。（下線は，当審で付加した。）
　
（ア）「【０００１】
【発明の属する技術分野】この発明は，コンピュータネットワークを用いたオンラインショッピングに関するものである。特に，Ｉｎｔｅｒｎｅｔを介してのオンラインショッピングに関する。また，代金決済は，クレジットカードを用いて行い，クレジットカード情報は，専用のネットワーク上を流れ，カード情報の漏洩を防ぐオンラインショッピングシステムと代金決済方法に関するものである。」
　
（イ）「【００２１】
【発明の実施の形態】
実施の形態１．実施の形態１では，商品の注文データを送信する決済用ネットワークを用いたオンラインショッピングシステムの一例を説明する。図１は，この発明におけるオンラインショッピングシステムの一例を示すシステム構成図である。図１において，Ａ販売店のＡ販売店システム２ａは，ショッピングモールＡ３ａをコンピュータネットワーク４に接続して，ユーザに対してショッピング情報を提供している。同じように，Ｂ販売店のＢ販売店システム２ｂはショッピングモールＢ３ｂを，Ｃ販売店のＣ販売店システム２ｃはショッピングモールＣ３ｃを，それぞれコンピュータネットワーク４に接続して，ユーザに対してショッピング情報を提供している。ユーザは，コンピュータを有するユーザシステム５をコンピュータネットワーク４に接続して，上記ショッピングモールＡ３ａ〜ショッピングモールＣ３ｃのショッピング情報を参照し，購入する商品の注文を行うことができる。また，購入する商品の決済は，決済用ネットワーク６を用いて行う。決済用ネットワーク６は，ユーザシステム５とサービスセンタ７とを接続しており，例えば，ＴＣＰ／ＩＰ（トランスミッションコントロールプロトコル／インターネットプロトコル）を採用しており，公衆回線を用いている。
サービスセンタ７は，ユーザシステム５より商品の注文データである商品データ，個人データ，代金決済データ２１を受信する。サービスセンタ７は，代金の支払いに関する代金決済データを，各種クレジットカード会社である認承センタ１３に送信する。認承センタ１３により認承がされた場合サービスセンタ７は，商品の発送に関する商品データと個人データ２２を該当する販売店に送信する
　
２．対比
　
　引用発明の「インターネット」，「端末１００」，「コンテンツサーバ２００」，「端末１００のＩＰアドレス」は，それぞれ本件発明の「通信ネットワーク」，「購入者システム」，「販売者システム」，「購入者システムを識別するための購入者システム識別情報」に相当する。
　
　引用発明の「カード管理サーバ３００」と，本件発明の「決済仲介システム」とは，「照会処理を行うコンピュータ」で共通する。
　引用発明の「プリペイドカードの認証・課金処理」と，本件発明の「クレジットカードの与信処理」とは，「照会処理」で共通する。
　引用発明の「サービス利用要求メッセージ」と，本件発明の「購入者システムを識別する購入者システム識別情報と，届け先情報とを含む注文情報」とは，「サービス利用要求に関する情報」で共通する。
　引用発明の「利用サービスのサービス度数」と，本件発明の「運送料金を含む決済総額情報」とは，「サービス利用料情報」で共通する。
　引用発明の「前記サービス利用要求メッセージを受信したら，利用サービスのサービス度数を設定した課金処理要求メッセージと，端末１００のＩＰアドレスを設定した認証要求メッセージとをカード管理サーバ３００に送信する」と，本件発明の「前記注文情報を受信したら，運送料金を含む決済総額情報と，届け先情報と，購入者システム識別情報とを包含する注文情報を，決済仲介システムに送信する」とは，「前記サービス利用要求に関する情報を受信したら，サービス利用料情報と，購入者システム識別情報を含む照会処理を依頼する情報を，照会処理を行うコンピュータに送信する」で共通する。
　引用発明の「カードＩＤ」と，本件発明の「クレジットカード情報など与信処理に必要な情報」とは，「照会処理に必要な情報」で共通する。
　引用発明の「認証・課金処理結果」と，本件発明の「与信処理結果」とは，「照会処理結果」で共通する。
　
　そうすると，本件発明と引用発明とは，
　
「通信ネットワークを通じて，外部システムである購入者システム及び販売者システムと接続し得る照会処理を行うコンピュータを介して，該照会処理を行うコンピュータが備えたプログラムにより下記ステップを実行して照会処理を行う方法であって，
　購入者システムは，サービス利用要求に関する情報を，販売者システムに送信するステップ，
　販売者システムは，前記サービス利用要求に関する情報を受信したら，サービス利用料情報と，購入者システム識別情報を含む照会処理を依頼する情報を，照会処理を行うコンピュータに送信するステップ，
　照会処理を行うコンピュータが，サービス利用料情報と，購入者システム識別情報を含む照会処理を依頼する情報を販売者システムから受信するステップ，
　照会処理を行うコンピュータが，販売者システムから前記照会処理を依頼する情報を受信したら，当該注文情報中の購入者システム識別情報に基づいてその購入者システムに対し，照会処理に必要な情報の要求を購入者システムに送信するステップ，
　照会処理を行うコンピュータが，当該購入者システムから照会処理に必要な情報を受信し，自動的に販売者システムに対して当該照会処理結果を送信するステップ，
　を包含してなる照会処理を行う方法。」
　
　で一致し，次の点で相違する。
　
［相違点１］
　本件発明では，照会処理を行うコンピュータが「決済仲介システム」であり，決済仲介システムが照会処理を依頼する情報を「注文案件毎の取引情報として蓄積」し，決済仲介システムが，「与信処理センターサーバ」に照会処理に必要な情報を送信し，当該与信処理センターサーバから照会処理結果を受信する「クレジットカードの与信処理」を行う「決済仲介方法」であり，照会処理に必要な情報が「クレジットカード情報など与信処理に必要な情報」であり，照会処理結果が「与信処理結果」であるのに対し，引用発明では，照会処理を行うコンピュータが「カード管理サーバ」であり，カード管理サーバが照会処理を依頼する情報を注文案件毎の取引情報として蓄積する構成は記載されておらず，照会処理をカード管理サーバが「プリペイドカードの認証・課金処理」を行う「認証・課金処理方法」であり，照会処理に必要な情報が「カードＩＤ」であり，照会処理結果が「認証・課金処理結果」である点。
　
［相違点２］
　本件発明では，決済仲介システムが「販売者に対して販売者識別番号を割り当て，該販売者識別番号と販売者システムの端末識別番号とを関連付けて蓄積する」のに対し，引用発明では，そのような構成は記載されていない点。
　
［相違点３］
　本件発明では，サービス利用要求に関する情報が「購入者システムを識別する購入者システム識別情報と，届け先情報とを含む注文情報」であり，サービス利用料情報が「運送料金を含む決済総額情報」であり，照会処理を依頼する情報が「運送料金を含む決済総額情報と，届け先情報と，購入者システム識別情報とを包含する注文情報」であるのに対し，引用発明では，サービス利用要求に関する情報が「サービス利用要求メッセージ」であり，サービス利用料情報が「利用サービスのサービス度数」であり，照会処理を依頼する情報が「利用サービスのサービス度数を設定した課金処理要求メッセージと，ＩＰアドレスを設定した認証要求メッセージ」である点。
　
［相違点４］
　本件発明では，決済仲介システムが，購入者システムに「与信処理開始の依頼と決済仲介システムへのアクセス情報とを送信」し，「上記購入者システムからアクセス要求があったら，蓄積している取引情報のうち少なくとも決済総額情報を含む注文情報」と「クレジットカード情報など与信処理に必要な情報の要求」を「購入者システムに送信」するのに対し，引用発明では，そのような構成は記載されていない点。
　
３．判断
　
　上記相違点について検討をする。
　
［相違点１］について
　引用例４の上記摘記事項（イ）には，決済を仲介するサービスセンタ７が代金決済データをクレジットカード会社である認承センタ１３に送信する，すなわちサービスセンタ７が認承センタ１３に与信処理を依頼し，その与信処理結果を受け取る構成が記載されていることから，サービスセンタ７と認承センタ１３が行う処理をそれぞれ異なる装置に分けて実行させる構成とするか，これらの処理を１つの装置に実行させる構成とするかは，当業者が適宜選択し得た事項である。
　また，引用例２の上記摘記事項（ウ）には，「この認証情報は，例えば，決済サーバ１２０を利用可能な利用者のＩＤとパスワード及び該利用者の決済方法（例えば，銀行口座の口座番号やクレジットカード番号）等によって構成される」として，電子商取引の分野における決済方法の例としてクレジットカードを用いることが記載されており，クレジットカード決済を採用した場合，注文案件毎に取引情報を管理することは，当業者が適宜なし得たものである。
　そうすると，引用発明において，照会処理を行うコンピュータを「決済仲介システム」とし，決済仲介システムが照会処理を依頼する情報を「注文案件毎の取引情報として蓄積」し，決済仲介システムが，「与信処理センターサーバ」に照会処理に必要な情報を送信し，当該与信処理センターサーバから照会処理結果を受信する「クレジットカードの与信処理」を行う「決済仲介方法」とし，照会処理に必要な情報を「クレジットカード情報など与信処理に必要な情報」とし，照会処理結果を「与信処理結果」とすることは，当業者が容易になし得たものである。
　よって，相違点１に係る構成は，引用発明，引用例２及び４に記載された事項から，当業者が容易に想到し得た事項である。
　
［相違点２］について
　引用例２の上記摘記事項（エ）には，店舗サーバが複数ある場合，決済サーバ１２０において店舗サーバを識別する識別子を用意することが記載されていることから，店舗サーバの識別子を用いて，店舗サーバを管理している者を識別することは，当業者が適宜になし得たものである。
　そうすると，引用発明において，決済仲介システムが「販売者に対して販売者識別番号を割り当て，該販売者識別番号と販売者システムの端末識別番号とを関連付けて蓄積する」ことは，当業者が容易になし得たものである。
　よって，相違点２に係る構成は，引用発明及び引用例２に記載された事項から，当業者が容易に想到し得た事項である。
　
［相違点３］について
　引用例２の上記摘記事項（エ）〜（オ）には，取引の対象を「商品」とし，該商品を利用者に配送すること，決済金額に手数料や消費税額を上乗せすることが記載されていること，また，引用例３の上記摘記事項（イ）及び図２には，取引の対象を「商品」とし，該商品を利用者に配送することが記載されており，さらに引用例３の上記摘記事項（ウ）には，商品代金に送料・消費税を含めることが記載されており，利用者にとって配送料を含めた総額は購入を決断するための重要な判断材料であることから，決済金額の計算に，商品の配送料を含めること，配送することで利用者に商品を届けることのできるサービスにおいて，利用者への届け先の情報は重要であるから，商取引の過程で授受される注文情報に利用者の届け先の情報を含めることは，当業者が容易になし得たものである。
　また，仲介決済システムが購入者にアクセスするための情報を，購入者システムから電子メール等の情報として販売者システム送信し，販売者システムから仲介決済システムに送信することで，仲介決済システムから購入者へアクセス可能とするか，販売者システムが購入者システムのＩＰアドレスを決済仲介システムに送信することで，決済仲介システムから購入者へアクセスを可能とするかは，販売者システムが購入者システムにアクセするための情報の取得方法の単なる選択にすぎない。
　そうすると，引用発明において，サービス利用要求に関する情報を「購入者システムを識別する購入者システム識別情報と，届け先情報とを含む注文情報」とし，サービス利用料情報を「運送料金を含む決済総額情報」とし，照会処理を依頼する情報を「運送料金を含む決済総額情報と，届け先情報と，購入者システム識別情報とを包含する注文情報」とすることは，当業者が容易になし得たものである。
　よって，相違点３に係る構成は，引用発明及び引用例２〜３に記載された事項から，当業者が容易に想到し得た事項である。
　
［相違点４］について
　引用例２の上記摘記事項（ウ），（カ）〜（ク）には，決済用初期画面にて利用者が入力した認証情報（決済サーバ１２０を利用可能な利用者のＩＤとパスワード及び該利用者の決済方法（例えば，銀行口座の口座番号やクレジットカード番号）等）をクライアントコンピュータから決済サーバに送信し，認証に成功した場合，決済サーバは，利用者が確認するための決済金額をクライアントコンピュータに送信することが記載されている。そして，認証処理では，決済を希望しない場合には，ユーザーＩＤとパスワード等を入力しなければいいので，利用者の決済を希望することの意思表示が含まれることは明らかであるから，利用者による決済金額の確認のために決済金額をクライアントコンピュータに送信する前に，利用者に決済を希望する意思があるかを確認することは当業者が適宜なし得たものであり，与信処理に必要な情報をどのようなタイミングで要求するか否かは当業者が適宜決定し得た事項である。
　そうすると，引用発明において，決済仲介システムが，「与信処理開始の依頼と決済仲介システムへのアクセス情報とを送信」し，「上記購入者システムからアクセス要求があったら，蓄積している取引情報のうち少なくとも決済総額情報を含む注文情報」と「クレジットカード情報など与信処理に必要な情報の要求」を「購入者システムに送信」することは，当業者が容易になし得たものである。
　よって，相違点４係る構成は，引用発明及び引用例２に記載された事項から，当業者が容易に想到し得た事項である。
　
　ここで，審判請求人の主張について検討をすると，争点１及び争点２（クレジットカードに関する点）については，上記「［相違点１］について」で検討したとおり，争点３及び争点５(運送料金，届け先情報に関する点）については，上記「［相違点３］について」で検討したとおり，そして，争点４（販売者識別番号と販売者システムの端末識別番号を関連付けて蓄積する点）については，上記「［相違点２］について」で検討したとおり，当業者が引用発明及び引用例２〜４に記載された事項から容易に想到し得たものである。
　よって，当該特徴的な構成が引用発明等から容易に想到し得たものはない旨の審判請求人の上記主張は採用できない。
　
　そして，本件発明の効果は，引用発明及び引用例２〜４に記載された事項から予測できる範囲内のものである。
　
　したがって，本件発明は，引用発明及び引用例２〜４に記載された事項に基づいて当業者が容易に発明をすることができたものである。
　
４．むすび
　
　以上のとおり，本件発明は，引用発明及び引用例２〜４に記載された事項に基づいて当業者が容易に発明をすることができたものであるから，特許法第２９条２項の規定により特許を受けることができない。
　
　よって，結論のとおり審決する。