【事件の表示】
　特願２０１５−　５２４４９「クレジット管理サーバ、クレジット管理方法及びクレジット管理サーバ用プログラム」拒絶査定不服審判事件〔平成２８年　９月２９日出願公開、特開２０１６−１７３６６５〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１　手続の経緯
　本願は、平成２７年３月１６日に出願された特許出願であって、平成２９年２月２８日付けで拒絶理由通知がされ、同年５月１２日付けで意見書及び手続補正書が提出されたが、同年９月２７日付けで拒絶査定（原査定）がされ、同拒絶査定の謄本が請求人に送達された。
　これに対し、同年１２月１１日に拒絶査定不服審判の請求がなされ、それと同時に手続補正がなされたものである。
　
第２　平成２９年１２月１１日にされた手続補正についての補正の却下の決定
［補正の却下の決定の結論］
　平成２９年１２月１１日にされた手続補正（以下、「本件補正」という。）を却下する。
　
［理由］
１　本件補正について
　本件補正は、特許請求の範囲等を変更するものであり、平成２９年５月１２日に提出された手続補正書に記載された特許請求の範囲の請求項１の記載（下記（１））を同年１２月１１日に提出された手続補正書に記載された特許請求の範囲の請求項１の記載（下記（２））のとおりに補正することをその一部に含むものである。
　
（１）平成２９年５月１２日に提出された手続補正書記載の特許請求の範囲の請求項１
　ユーザ端末からユーザを識別するユーザＩＤを受信するユーザＩＤ受信手段と、
　決済の種別を決める決済種別データと、当該決済種別データに対応した決済の限度額を示す決済限度額データとを受信する決済データ受信手段と、
　受信した前記ユーザＩＤと、前記決済種別データと、前記決済限度額データとを対応付けて記憶する決済データ記憶手段と、
　前記決済データ記憶手段に記憶した前記決済種別データと、前記決済限度額データとを編集する編集手段と、
　前記決済データ記憶手段に記憶した前記ユーザＩＤと、前記決済種別データと、前記決済限度額データとに有効期限を設定する有効期限設定手段と、
　前記有効期限設定手段により設定された有効期限を超えた場合、記憶した前記ユーザＩＤと、前記決済種別データと、前記決済限度額データとを削除する削除手段と、
　前記ユーザＩＤによる決済リクエストであって、前記決済種別データを識別する決済種別認識コードと、当該決済種別データに対応する決済限度額データとを受信した際に、前記決済データ記憶手段に記憶された決済種別データと同一の決済種別であって、かつ当該決済種別データに対応した決済限度額データが前記決済データ記憶手段に記憶された決済限度額内である場合にのみ、決済サーバに決済依頼処理を送信し決済を実行する決済判断手段と、
　を備えるクレジット管理サーバ。
　
（２）平成２９年１２月１１日に提出された手続補正書記載の特許請求の範囲の請求項１（下線は補正箇所を示す。）
　ユーザ端末からユーザを識別するユーザＩＤを受信するユーザＩＤ受信手段と、
　決済の種別を決める決済種別データと、当該決済種別データに対応した決済の限度額を示す決済限度額データとを受信する決済データ受信手段と、
　受信した前記ユーザＩＤと、前記決済種別データと、前記決済限度額データとを対応付けて記憶する決済データ記憶手段と、
　前記決済データ記憶手段に記憶した前記決済種別データと、前記決済限度額データとを編集する編集手段と、
　前記決済データ記憶手段に記憶した前記ユーザＩＤと、前記決済種別データと、前記決済限度額データとに有効期限を設定する有効期限設定手段と、
　前記有効期限設定手段により設定された有効期限を超えた場合、記憶した前記ユーザＩＤと、前記決済種別データと、前記決済限度額データとを削除する削除手段と、
　前記ユーザＩＤによる決済リクエストであって、前記決済種別データを識別する決済種別認識コードと、当該決済種別データに対応する決済限度額データとを受信した際に、前記決済データ記憶手段に記憶された決済種別データと同一の決済種別であって、かつ当該決済種別データに対応した決済限度額データが前記決済データ記憶手段に記憶された決済限度額内である場合にのみ、決済サーバに決済依頼処理を送信し決済を実行
し、前記決済データ記憶手段に記憶された決済種別データと同一の決済種別でない、または当該決済種別データに対応した決済限度額データが前記決済データ記憶手段に記憶された決済限度額内でない場合には決済サーバとの通信を行わない
　を備えるクレジット管理サーバ。
　
（３）目的要件について
　請求項１についての補正は、「決済判断手段」が「
前記決済データ記憶手段に記憶された決済種別データと同一の決済種別でない、または当該決済種別データに対応した決済限度額データが前記決済データ記憶手段に記憶された決済限度額内でない場合には決済サーバとの通信を行わない
　そこで、本件補正後の請求項１に記載された発明（以下、「本願補正発明」という。）が同法第１７条の２第６項において準用する同法第１２６条第７項が規定する要件（独立特許要件）を満たすものであるか否かを検討する。
　
２　独立特許要件違反についての検討
（１）本願補正発明
　本願補正発明は、平成２９年１２月１１日に提出された手続補正書記載の特許請求の範囲の請求項１（上記１（２））の記載に照らし、以下のとおりのものと認める。
　なお、本願補正発明を認定するにあたり、「決済判断手段」が「受信」する「決済リクエスト」である「当該決済種別データに対応する決済限度額データ」（及び「当該決済種別データに対応した決済限度額データ」）は、本願明細書段落【００６９】の記載等からみて、
いずれも、「当該決済種別データに対応した決済額データ」の誤記であると認め、この誤記を訂正し
　
Ａ　ユーザ端末からユーザを識別するユーザＩＤを受信するユーザＩＤ受信手段と、
Ｂ　決済の種別を決める決済種別データと、当該決済種別データに対応した決済の限度額を示す決済限度額データとを受信する決済データ受信手段と、
Ｃ　受信した前記ユーザＩＤと、前記決済種別データと、前記決済限度額データとを対応付けて記憶する決済データ記憶手段と、
Ｄ　前記決済データ記憶手段に記憶した前記決済種別データと、前記決済限度額データとを編集する編集手段と、
Ｅ　前記決済データ記憶手段に記憶した前記ユーザＩＤと、前記決済種別データと、前記決済限度額データとに有効期限を設定する有効期限設定手段と、
Ｆ　前記有効期限設定手段により設定された有効期限を超えた場合、記憶した前記ユーザＩＤと、前記決済種別データと、前記決済限度額データとを削除する削除手段と、
Ｇ　前記ユーザＩＤによる決済リクエストであって、前記決済種別データを識別する決済種別認識コードと、
当該決済種別データに対応した決済額データ
当該決済種別データに対応した決済額データ
当該決済種別データに対応した決済額データ
Ｈ　を備えるクレジット管理サーバ。
　
（２）引用文献等
ア　引用文献１（主引用文献）
　原査定の理由において引用された特開２００２−１９７３９２号公報（以下、「引用文献１」という。）は、公開日が本願の出願前の平成１４年７月１２日である特許公報であって、図面とともに、以下の記載がある。
　
（ア）
「【０００１】【発明の属する技術分野】この発明は、
カード会社と契約した顧客が本人の意思によりカードを利用することを第三者保証機関に通知する
第三者保証機関がカード会社に対して顧客の取引意思有無を保証する
　
（イ）
「【０００９】この発明は上記のような問題点を解決するためになされたもので、以下のことを目的とする。第三者保証機関が、本人認証情報及び取引承認項目を管理することで、本人認証を確実に行う。本人認証を確実に行うことにより、盗難カードや偽造カードによる第三者の不正利用を防止する。インターネットでカード決済をするときも、本人認証を確実に行うことにより、盗難カードや偽造カードによる第三者の不正利用を防止する。
第三者保証機関が、本人認証情報及び取引承認項目を管理する
　
（ウ）
「【００１９】【発明の実施の形態】実施の形態１.図１は、この発明の実施の形態１である第三者保証機関照会システムを実現するためのシステム構成図である。図１において、１は照会システム、２はカード会社と契約した顧客から必要な情報が送信される端末、３はカード会社の承認部門である。本実施の形態における端末２は、携帯端末または携帯電話など顧客が所有する端末であるとする。また、４は端末２より本人認証情報及びカード利用承認情報を受付ける受付手段、５は受付手段４より渡された本人認証情報により顧客であるかどうかを判定、認証する本人認証手段、６は本人認証手段５が用いる認証情報が格納されている認証情報ファイルである。・・・
【００２０】さらに、７は受付手段４より渡されたカード利用承認情報によりカード毎の利用可能条件を変更するステータス変更手段、８はステータス変更手段７により変更可能なカード毎の利用可能条件が格納されているステータス情報ファイルである。また、９はカード会社の承認部門３から顧客からの取引要求に基づいた取引承認確認を受付け、ステータス情報ファイル８を参照することにより、取引要求を承認するかどうかを承認部門３へ通知する承認手段である。」
　
（エ）
「【００２１】図２は、実施の形態１で用いるステータス情報ファイル８である。ステータス情報ファイル８には、顧客ＩＤ１１、カードＮＯ１２、ステータス１３が格納されている。ステータス１３は、顧客が指定するカード利用を承認するか否かを示すフラグであり、顧客のみが変更できるものである。例えば「ＮＧ」はカード利用を承認しないとし、「ＯＫ」はカード利用を承認するとする。ステータス１３は、通常「ＮＧ」となっていて、顧客がカードを利用しようとするとき「ＯＫ」とするものとする。」
　
（オ）
「【００２３】図３は、顧客から本人認証情報及びカード利用承認情報が送信されたときの照会システム１における処理の流れを示すフローチャートである。ステップＳ１において、端末２より本人認証情報及びカード利用承認情報が送信されると、受付手段４がそれを受信する。受付手段４は本人認証情報を本人認証手段５に、カード利用承認情報をステータス変更手段７へ受け渡す。
【００２４】ステップＳ２において、本人認証手段５が受け渡された本人認証情報と認証情報ファイル６とを比較することにより、顧客であるかどうかを判定し、顧客であるときはその顧客名を認証し、ステップＳ３に処理が進む。・・・
【００２５】ステップＳ３では、本人認証手段５が認証した顧客名に基づき、ステータス変更手段７がステータス情報ファイル８の顧客ＩＤ１１を参照し、カード利用承認情報として送信されたカード番号に基づき参照されたカードＮＯ１２のステータス情報１３を変更する。
【００２６】図３に示した処理は、顧客がカード利用を開始するために、通常「ＮＧ」となっているステータス１３を「ＯＫ」にするとき、または顧客がカード利用を終了するために、「ＯＫ」にしたステータス１３を「ＮＧ」にするとき、行われる。」
　
（カ）
「【００２７】図４は、顧客から取引要求があったとき、例えば顧客が店舗に赴きカードによる買い物をしようとしたときに、照会システム１においてカード会社の承認部門３から取引承認確認を受け付けた後の処理の流れを示すフローチャートである。ステップＳ１１において、取引承認手段９が承認部門３より取引承認確認を受け付け、顧客ＩＤを指定される。その後、ステップＳ１２において取引承認手段９が指定された顧客ＩＤからステータス情報ファイル８を参照し、取引要求を承認していいかどうかを確認する。ステータス情報１３が「ＯＫ」となっているときは、取引要求を承認するとし、ステップＳ１３で承認部門３へ取引要求を承認する旨を通知する。また、ステータス情報１３が「ＮＧ」となっているときは、取引要求を承認できないため、ステップＳ１４で承認部門３へ取引要求を不承認とする旨を通知する。」
　
（キ）
「【００３１】さらに本システムによるとインターネットでカード決済するときも本人認証が確実に行えるため、盗難カードや偽造カードによる第三者の不正利用を防止することができる。」
　
（ク）
「【００３１】・・・実施の形態２.実施の形態２におけるシステム構成図は、実施の形態１で示した図１と同様である。また図５は、本実施の形態で用いるステータス情報ファイル８である。ステータス情報ファイル８には、顧客ＩＤ１１、カードＮＯ１２及びステータス選択２１、ステータス２２及び回数２３、開始２４、終了２５が格納されている。顧客ＩＤ１１及びカードＮＯ１２は図２で示したステータス情報ファイル８と同一であるが、本実施の形態において特徴的なことはカード利用承認を回数または時間制限で指定できることである。
【００３２】例えば図５に示したように、ステータス選択２１には、「０」、「１」、「２」などの値が指定できるようにする。このとき、「０」は実施の形態１と同様に、「ＯＫ」あるいは「ＮＧ」をステータス２２に指定することとし、顧客から本人認証情報及びカード利用承認情報が送信されたときに切り替えられる。またステータス選択２１が「１」のときはカード利用の回数を指定する、「２」のときはカード利用を時間で制限するとし開始及び終了時間を指定する方法とする。
【００３３】ステータス選択２１に「１」を指定したときは、回数２２にカード利用承認回数を指定するようにする。また、ステータス選択２１に「２」を指定したときは、開始２４及び終了２５にカード利用を承認する時間の開始時間及び終了時間を指定する。
【００３４】顧客から本人認証情報及びカード利用承認情報が送信されたときの照会システム１における処理の流れは、図３に示したとおりであるが、ステップＳ１において受け付けるカード利用承認情報に、カード利用承認方法が加えられる。カード利用承認方法について前述のとおりであり、カード利用承認を回数または時間制限で指定するときは同時に、それぞれ回数または時間制限の開始時間及び終了時間を受付けるように構成する。それにより図５に示したステータス情報ファイル８のステータス選択２１から終了２５までの内容が、随時書き換えられる。
【００３５】また、顧客から取引要求があったとき、例えば顧客が店舗に赴きカードによる買い物をしようとしたときに、照会システム１においてカード会社の承認部門３から取引承認確認を受け付けた後の処理の流れは、図４に示したとおりである。ステップＳ１２において、取引要求を承認していいかどうかを確認するとき、ステータス選択２１の値により、ステータス２２または回数２３または開始２４及び終了２５を参照し、承認または不承認を判定する。
【００３６】以上説明したように本実施の形態によると、顧客はカード利用承認方法を選択することができる。回数または時間制限で指定するときは、カード利用終了後、指定の回数または時間により自動的にステータス２２が「ＮＧ」の状態になるため、図３に示した本人認証情報及びカード利用承認情報が送信する処理は、カード利用を開始するときに一度だけ行えばよい。」
　
（ケ）
「【００３７】また本実施の形態において、顧客は端末２から本人認証情報及びカード利用承認情報を送信するではなく、カード利用のために赴いた店舗に設置された与信照会端末（図示せず）に設置された専用端末（図示せず）から本人認証情報及びカード利用承認情報を送信するように構成することもできる。このように構成することにより、顧客は端末２を有していなくても、赴いた店舗先で本システムを用いることができる。例えば、指紋により本人認証を行うように構成したときは、専用端末（図示せず）に指を挿入することで、本人認証ができる。また、指が挿入されている間のみ、カード利用承認の状態になるように構成すれば、顧客はステータス２２を「ＮＧ」に戻す必要がなくなる。なお、与信照会端末（図示せず）はカード会社の承認部門３に接続されているものであり、承認部門３は与信照会端末（図示せず）からの照会に基づき、照会システム１へ取引承認確認を行う。」
　
（コ）
「【００３７】・・・実施の形態３.実施の形態３におけるシステム構成図は、実施の形態１で示した図１と同様である。また図６は、本実施の形態で用いるステータス情報ファイル８である。ステータス情報ファイル８には、顧客ＩＤ１１、カードＮＯ１２及びステータス選択３１、利用可能カテゴリ３２、利用可能範囲３３、ステータス３４、回数３５、開始３６、終了３７、利用可能金額３８が格納されている。
顧客ＩＤ１１及びカードＮＯ１２は、図２で示したステータス情報ファイル８と同一である。
回数３５及び開始３６及び終了３７は、図５で示したステータス情報ファイル８の回数２３及び開始２４及び終了２５と同一である。
【００３８】本実施の形態において特徴的なことは、利用可能カテゴリ３２及び利用可能範囲３３及び利用可能金額３８を指定できることである。利用可能カテゴリ３２は、例えば貴金属、衣類、生活雑貨など買い物の品目を定めることができる。また、利用可能範囲３３は、後述するショッピングモールや百貨店などと限定したり、国内のみという指定や、または海外での利用のときは、国名による指定などが行える。これにより、例えば顧客が店舗に赴きカードによる買い物をしようとしたときに、買い物をするカテゴリ毎に利用可能金額を定めたり、海外での利用予定がないときは利用可能範囲を国内と定めることができる。
【００３９】顧客から本人認証情報及びカード利用承認情報が送信されたときの照会システム１における処理の流れは、図３に示したとおりであるが、
ステップＳ１において受け付けるカード利用承認情報に、カード利用承認方法に加えて、利用可能カテゴリ３２及び利用可能範囲３３及び利用可能金額３８が追加される。
　
（サ）図６
　
　
イ　周知例１
　特開２０１３−２４６５８０号公報（以下、「周知例１」という。）は、公開日が本願の出願前の平成２５年１２月９日である特許公報であって、図面とともに、以下の記載がある。
　
（ア）
「【００３６】・・・図３に示すとおり、携帯型電話機３は、制御部３０と、この制御部３０に接続されたメモリ３１、ＲＦ（Radio Frequency）部３２、入力部３４、ディスプレイ３５、音声入力部３６、カメラ部３７、及びＩＣチップ３８とを備えている。
【００３７】・・・また、メモリ３１には、携帯型電話機３を所有するカード会員及びその家族会員のクレジットカードに関するカード情報が格納されるカード情報データベース（ＤＢ）３１Ａと、クレジットカードによる取引結果に関する取引明細情報が格納される取引明細情報データベース（ＤＢ）３１Ｂとが設けられている。・・・
・・・
【００４２】
  以下、メモリ３１に設けられている各データベースの詳細について説明する。
  （Ａ）カード情報ＤＢ３１Ａ
  図４は、カード情報ＤＢ３１Ａのレイアウトの一例を示す図である。図４に示すように、
カード情報ＤＢ３１Ａ
当該クレジットカードの有効期限が格納される有効期限フィールド３０３、当該クレジットカードが利用可能な限度額が格納される限度額フィールド３０４、当該クレジットカードの利用額が格納される利用額フィールド３０５、
【００４３】
  上記の
カード情報ＤＢ３１Ａに蓄積されるカード情報は、与信情報送信装置１から受信した情報で構成されている。
カード情報ＤＢ３１Ａに格納されるカード情報は最新の内容に保たれる
　
「【００５６】（２）与信審査処理
  クレジットカードを利用して商品の購入を行うカード会員は、購入代金の支払の際に、自らが携帯している携帯型電話機３を、店舗端末４に接続されているＲ／Ｗ装置５に近付ける。これにより、携帯型電話機３が備えるＩＣチップ３８が動作し、携帯型電話機３と店舗端末４との間の通信が可能となり、以下の与信審査処理が実行される。
【００５７】図８Ａ及び図８Ｂは、本実施の形態の与信審査システムにおいて実行される与信審査処理の手順を示すフローチャートである。
  
携帯型電話機３は、
カード情報ＤＢ３１Ａに格納されているカード情報
を含む与信審査用情報を送信する
　
（イ）
「【００６０】ステップＳ５０５において加盟店情報中の当該店舗に係る情報と自加盟店情報とが一致すると判定した場合（Ｓ５０５でＹＥＳ）、
店舗端末４は、商品情報に含まれている商品の価格と、与信審査用情報に含まれているカード情報の限度額フィールド３０４及び利用額フィールド３０５にそれぞれ格納されている限度額及び利用額とを用いて、今回のクレジットカードの決済が利用限度額の範囲内であるか否かを判定する（Ｓ５０６）。
【００６１】ステップＳ５０６において
利用限度額の範囲内であると判定した場合（Ｓ５０６でＹＥＳ）
店舗端末４は後述するステップＳ５１０に進む。
　
（ウ）
「【００６４】ステップＳ５０７において事故に係るカードではないと判定した場合（Ｓ５０７でＮＯ）、
店舗端末４は、図８Ｂに示すように、与信が承認されたと判断し、その承認がされたことを示す承認情報を携帯型電話機３に対して送信する（Ｓ５１０）。
　
（エ）
「【００６６】なお、
店舗端末４は、携帯型電話機３に対して送信する承認情報を蓄積しておき、蓄積されている承認情報に基づいて店舗精算に関する店舗精算情報を生成し
店舗精算システム２に対して当該店舗精算情報を送信
受信した店舗精算情報に基づいて決済を行うために必要な決済用情報を生成
生成された決済用情報は、店舗精算システム２からカードシステムＣに設けられている決済システムに対して送られる
　
　これらの記載によれば、周知例１には、商品の価格と与信情報送信装置から携帯型電話機が受信して携帯型電話機から店舗端末へ送信される最新の与信審査用情報の限度額及び利用額を用いて、今回のクレジットカードの決済が利用限度額の範囲内であるか否かを判定する店舗端末において、与信が承認されたと判断した場合、カードシステムに設けられた決済システムに対して送られる決済用情報の生成に用いられる店舗清算情報を生成して店舗清算システムに対して送信すること、が記載されている。
　
ウ　周知例２
　特開２００２−３６６８６２号公報（以下、「周知例２」という。）は、公開日が本願の出願前の平成１４年１２月２０日である特許公報であって、図面とともに、以下の記載がある。
　
（ア）
「【００２６】
与信確認センタ８は、ＰＯＳターミナル２からの認証確認要求に応答して、各クレジットカード会社に設置された認証用データベースにアクセスして与信可否データを作成し、当該クレジットカードの与信確認結果をＰＯＳターミナル２に送出するようになっている。
　
（イ）
「【００３２】・・・まず、
商品購入希望者が所望の商品の購入を店舗側に申出て、一体型ＩＣカード１０を読み出し／書込み装置４にかざす
【００３３】一体型ＩＣカード１０は読み出し／書込み装置４に近づくと、上記カード情報をアンテナ１８を介して無線送信する。
読み出し／書込み装置４は、上記カード情報を受信してＰＯＳターミナル２に出力する。
【００３４】・・・当該カードが電子マネーカードの機能を有している場合には、ＰＯＳターミナル２の制御部２０は、記憶装置２２に格納した上記カード情報から電子マネー残高Ｒ１のデータを取り出す（ステップＳ３）。
【００３５】ＰＯＳターミナル２の制御部２０は、取り出した電子マネー残高Ｒ１が商品の販売金額（購入希望者から見れば購入金額）Ｓより小さいか否かを判断する（ステップＳ４）。
・・・
【００３８】次に、ステップＳ４で電子マネー残高Ｒ１が商品の販売金額Ｓより小さいと判断された場合について説明する。
・・・
【００４１】購入電子マネー残高Ｒ１と自動入金額Ｄとの合計が販売金額Ｓ以上の場合にはステップＳ８に移行して、
ＰＯＳターミナル２の制御部２０は、
与信確認センタ８に対して与信確認要求を送出する。
・・・　
【００４６】
与信が認められると判断したら、ＰＯＳターミナル２の制御部２０は、（電子マネー残高Ｒ１＋自動入金額Ｄ＝電子マネー残高Ｒ３）を計算して、電子マネー残高データとして電子マネー残高Ｒ３を格納する（ステップＳ１１）。次いで、（電子マネー残高Ｒ３−販売金額Ｓ＝差引残高Ｒ４）を計算する。
【００４７】
ステップＳ１２で電子マネー残高が確認されたら、ステップＳ１３に移行して、ＰＯＳターミナル２の制御部２０は、記憶装置２２内のカード情報のうち電子マネー残高を差引残高Ｒ４に書き換え、利用ログの最新データを今回の商品購入データに書き換えて
一体型ＩＣカード１０に送信する（ステップＳ１４）
一体型ＩＣカード１０の制御部１４は、受信したカード情報を記憶装置１２内に格納して電子マネー残高を含む各種データを更新する
・・・　
【００４９】
ステップＳ１３における差引処理の実行により一体型ＩＣカード１０に入金された“５０００円”の入金額は、
クレジット売上として、クレジットカード番号と共にＰＯＳターミナル２からクレジットカード会社に代金請求情報が送信される。
　
　これらの記載によれば、周知例２には、残高が商品の販売金額より小さい電子マネーへの自動入金に関連して、電子マネーの読み出し／書込み装置からカード情報を受信してクレジットカード会社に対してではなく与信確認センタに対して与信確認要求を送出して与信が認められるか否かを判断するＰＯＳターミナルの制御部において、与信が認められると判断した場合に、電子マネー残高をこれと入金額及び販売金額により計算される差引残高に書換える等を行い、クレジット売上となるこの入金額についてクレジットカード会社に代金請求を送信すること、が記載されている。
　
（３）引用発明の認定
ア　（２）アにおいて上述した引用文献１には、実施の形態１及び実施の形態２を組み合わせられたものである実施の形態３（（２）ア（コ）及び（サ））として、
カード利用承認情報に、カード利用承認方法に加えて、利用可能カテゴリ及び利用可能範囲及び利用可能金額が追加され、
「カードＮＯ」
「利用可能カテゴリ」、「利用可能範囲」
「利用可能金額」
　そして、図６によれば、いずれも「顧客ＩＤ」が「１２３４５６７８」であり、「カードＮＯ」が「３５００９０００△△△△○○○○」又は「３４４４９０００△△△△○○××」である３行が示されている。さらに、そのうち、「カードＮＯ」が「３４４４９０００△△△△○○××」であり、「利用可能カテゴリ」が「０３１」又は「０３２」である２行について、これが「０３１」の行については、「ステータス選択」、「利用可能範囲」、「回数」がそれぞれ「１」、「１」、「１」であり、「０３２」の行については、「ステータス選択」、「利用可能範囲」、「開始」、「終了」、「利用可能金額」がそれぞれ「２」、「２」、「２０００１２１５１０１０」、「２０００１２１５１１１０」、「３００００」とされた例が示されている。
　してみると、図６には、ステータス情報ファイルが、「顧客ＩＤ」の項目の値が同じで「カードＮＯ」の項目の値が異なる複数のレコードや「カードＮＯ」の項目の値が同じで「ステータス選択」や「利用可能範囲」等の項目の値が異なる複数のレコードを格納する例が示されている。そして、「顧客ＩＤ」の項目の値が同じで「カードＮＯ」の項目の値が異なる複数のレコードが存在し得る以上、「カードＮＯ」を用いず「顧客ＩＤ」のみを用いてステータス情報ファイルのレコードにより示される顧客の有するカード毎の利用条件を特定することはできないから、明示されていないものの、「ステータス情報」の「変更」の際（【００２５】）のみならず、「取引要求」に伴う「取引」の「承認」の確認の際の「指定された顧客ＩＤからステータス情報ファイルを参照」（【００２７】）にあたっても、「顧客ＩＤ」と「カードＮＯ」の両方（又は「カードＮＯ」のみ）が用いられることになる。
　
イ　（２）ア及びアによれば、引用文献１には、実施の形態３（（２）ア（コ）及び（サ））に関連して、次の発明（以下、「引用発明」という。）が記載されている。（便宜的にａ，ｂ・・・の項番を付し、さらに、引用文献１の対応する段落を付した。）
　
ａ（ｂ）　店舗などによるカード利用又はインターネットによるカード決済時において（【００３１】）カード会社と契約した顧客から必要な情報が送信される端末（【００１９】）より送信された本人認証情報及び
カード番号
利用可能カテゴリ及び利用可能範囲
利用可能金額
　受付手段より渡された本人認証情報により顧客であるかどうかを判定、認証する本人認証手段（【００１９】）と、
　本人認証手段が用いる認証情報が格納されている認証情報ファイル（【００１９】）と、
ｃ　
「顧客ＩＤ」、「カードＮＯ」、
「利用可能カテゴリ」、「利用可能範囲」
「利用可能金額」
ステータス情報ファイル（【００２０】）であって、「顧客ＩＤ」の項目の値が同じで「カードＮＯ」の項目の値が異なる複数のレコードや「カードＮＯ」の項目の値が同じで「ステータス選択」や「利用可能範囲」等の項目の値が異なる複数のレコードを格納し得るものであり（ア，図６）
ｄ　受付手段により渡された本人認証情報により本人認証手段が認証した顧客名に基づき顧客ＩＤを参照し、カード利用承認情報として送信された
カード番号に基づき参照されたカードのステータス情報を変更する（【００２５】）等により
利用可能条件を変更
ｅ　カード利用承認情報に加えられたカード利用承認方法として、カード利用承認を回数または時間制限で指定するときは、それぞれ回数または
時間制限の開始時間及び終了時間
ｆ　回数または時間制限で指定するときは、カード利用終了後、指定の回数または時間により自動的にステータスが「ＮＧ」の状態になるため、本人認証情報及びカード利用承認情報の送信をカード利用を開始するときに一度だけ行えばよいものであり（【００３６】）、
ｇ　
顧客から取引要求があったときのカード会社の承認部門から取引承認確認
ｈ　を備える第三者保証機関照会システム
　
（４）対比
ア　「Ａ　ユーザ端末から
ユーザを識別するユーザＩＤ
決済の種別を決める決済種別データ
当該決済種別データに対応した決済の限度額
　引用発明の「カード会社と契約した顧客」は、本願補正発明の「ユーザ」に相当し、引用発明の「インターネットによるカード決済」の際の「端末」は、このユーザが所有する携帯端末のような端末であるから、本願補正発明の「ユーザ端末」に相当する。
　本願発明の「ユーザＩＤ」は、クレジット管理サーバ及び決済サーバにおいて、ユーザに対応するカード決済の利用を可能とするための条件を示すものとして記憶されてこの条件の編集と決済リクエストの処理にあたって「ユーザ」を「識別」するもの（クレジットカード会社のような決済処理を行う主体において与信払いを行う処理等の決済処理の対象ユーザと対象ユーザが用いるユーザ端末を識別するもの。本願明細書【００５８】【００７８】）であるところ、引用発明は、カード会社の承認部門からの取引承認確認の処理を行う第三者保証機関照会システムにおいて、「「カードＮＯ」又は「顧客ＩＤ」と「カードＮＯ」の両方」（以下、「カード番号等」という。）を用いて顧客の有するカード毎の利用条件を示すステータス情報ファイルの各レコードの変更及び参照にあたってこのレコードを特定するものであり、その際、レコードの特定に用いられた「カード番号等」が示すユーザとそのユーザが用いた端末が識別されているといえるから、引用発明の「カード番号等」は、本願発明の「ユーザＩＤ」に相当する。
　引用発明の「カード利用承認情報」中の「利用可能カテゴリ及び利用可能範囲」は、顧客が指定した決済種別であるから、本願補正発明の「決済種別データ」に相当し、この「決済種別データ」とともに「カード利用承認情報」に追加された「利用可能金額」は、決済種別に対応する決済の限度額を示すものであるから、本願補正発明の「決済限度額データ」に相当する。
　してみると、引用発明の「受付手段」は、本願補正発明の「ユーザＩＤ受信手段」の「ユーザＩＤ」を受信する機能と「決済データ受信手段」の「決済種別データ」と「決済限度額データ」を受信する機能とを備えた手段であるから、引用発明は、本願補正発明と同様に、「ユーザＩＤ受信手段」と「決済データ受信手段」に相当する機能手段を備えているといえる。
　
イ　「Ｃ　
受信した前記ユーザＩＤ
決済種別データ
決済限度額データ
編集
　引用発明の「ステータス情報ファイル」の「顧客ＩＤ」及び「カードＮＯ」、「利用可能カテゴリ」及び「利用可能範囲」、「利用可能金額」の項目は、それぞれ、ユーザＩＤ、決済種別データ、決済限度額データに対応するものであり、引用発明の「ステータス情報ファイル」は、これらを対応付けられて記憶するものであるから、本願補正発明の「決済データ記憶手段」に相当する。
　また、引用発明の「ステータス変更手段」は、ユーザＩＤが示すカード毎の「決済種別データ」と「決済限度額データ」に対応する「利用可能カテゴリ及び利用可能範囲」と「利用可能金額」を実質的に編集するために用いられるから、本願補正発明の「編集手段」に相当する。
　
ウ　「Ｅ　前記決済データ記憶手段に記憶した前記ユーザＩＤと、前記決済種別データと、前記決済限度額データとに
有効期限を設定
　引用発明は、利用可能カテゴリ及び利用可能範囲や利用可能金額等であるカード利用承認情報としてカード利用承認の時間制限の開始時間及び終了時間を受け付けてステータス情報ファイルを書き換えるものであるから、本願補正発明と同様に、決済データ記憶手段に記憶したユーザＩＤと、決済種別データと、決済限度額データとに
有効期限を設定
　
エ　「Ｆ　前記有効期限設定手段により設定された有効期限を超えた場合、記憶した前記ユーザＩＤと、前記決済種別データと、前記決済限度額データとを削除する削除手段」について
　引用発明は、カード利用終了後、指定の時間により自動的にステータス２２が「ＮＧ」の状態になることにより、受信されるユーザＩＤ等の情報の送信をカード利用を開始するときに一度だけ行えばよいものであり、本願補正発明の「削除手段」を備えるか否かは明示されていない。（相違点１）
　
オ　「Ｇ　
前記ユーザＩＤによる決済リクエストであって、前記決済種別データを識別する決済種別認識コードと、当該決済種別データに対応する決済限度額データ
　引用発明の「インターネットによるカード決済」の際の「顧客から取引要求があったときのカード会社の承認部門から取引承認確認」は、カード決済を利用しようとする顧客からの取引要求に伴って与信照会がなされたカード会社の承認部門からのリクエストであり、ユーザのインターネットによるカード決済に伴うリクエストである点で、本願補正発明の「前記ユーザＩＤによる決済リクエスト」に対応する。
　もっとも、ユーザのインターネットによるカード決済に伴うリクエストが「前記ユーザＩＤによる決済リクエスト」である点（相違点２）、及び、このリクエストとして「決済種別データを識別する決済種別認識コード」と「当該決済種別データに対応した決済額データ」を受信する点（相違点３）については、明示されていない。
　
　引用発明における「取引要求を承認し、承認部門へ取引要求を承認する旨を通知」する処理と「不承認の場合は承認部門へ取引要求を不承認とする旨を通知する」処理は、それぞれ、ユーザのカード決済の利用を可能とする処理と可能としない処理である点で、本願補正発明の「決済サーバに決済依頼処理を送信し決済を実行」する処理と「決済サーバとの通信を行わない」処理に対応している。そして、ユーザのカード決済の利用を可能とする処理については、引用発明の「承認」の通知を受けたカード会社が取引要求に対応する決済を実行することになるから、この「承認」は、本願補正発明の「決済依頼処理」に相当し、引用発明は、本願補正発明と同様に、ユーザのカード決済の利用を可能とする処理として、「決済サーバに決済依頼処理を送信し決済を実行する」ものであるといえる。
　もっとも、ユーザのカード決済の利用を可能としない処理については、引用発明は、不承認とする旨の通知を行っているから、この点において、「決済サーバとの通信を行わない」本願補正発明と相違している。（相違点４）
　
　引用発明は、ユーザのカード決済の利用を可能とする処理と可能としない処理の判断にあたって「ステータス情報ファイル」を参照するから、決済データ記憶手段を参照してユーザのカード決済の利用を可能とする処理と可能としない処理のいずれを実行するかの判断が行われる点で、本願補正発明と共通している。
　もっとも、ユーザのカード決済の利用を可能とする処理と可能としない処理のいずれを実行するかの判断が「前記決済データ記憶手段に記憶された決済種別データと同一の決済種別であって、かつ当該決済種別データに対応した決済額データが前記決済データ記憶手段に記憶された決済限度額内である場合」か「前記決済データ記憶手段に記憶された決済種別データと同一の決済種別でない、または当該決済種別データに対応した決済額データが前記決済データ記憶手段に記憶された決済限度額内でない場合」かの判断である点（相違点５）については、明示されていない。
　
カ　「Ｈ　クレジット管理サーバ」について
　引用発明の「第三者保証機関紹介システム」は、ユーザのインターネットによるカード決済に伴う与信照会がなされたカード会社の承認部門からのリクエストを受けた承認に係る処理を行うサーバとして機能するシステムであるから、エ及びオにおいて示した相違点において相違するものの、その余の点では本願発明の「クレジット管理サーバ」に対応している。
　
キ　してみると、本願補正発明と引用発明とは、
　
＜一致点＞
Ａ　ユーザ端末からユーザを識別するユーザＩＤを受信するユーザＩＤ受信手段と、
Ｂ　決済の種別を決める決済種別データと、当該決済種別データに対応した決済の限度額を示す決済限度額データとを受信する決済データ受信手段と、
Ｃ　受信した前記ユーザＩＤと、前記決済種別データと、前記決済限度額データとを対応付けて記憶する決済データ記憶手段と、
Ｄ　前記決済データ記憶手段に記憶した前記決済種別データと、前記決済限度額データとを編集する編集手段と、
Ｅ　前記決済データ記憶手段に記憶した前記ユーザＩＤと、前記決済種別データと、前記決済限度額データとに有効期限を設定する有効期限設定手段と、
Ｇ　ユーザのインターネットによるカード決済に伴うリクエストを受信した際に、決済データ記憶手段を参照してユーザのカード決済の利用を可能とする処理を行うと判断された場合、ユーザのカード決済の利用を可能とする処理を行い、ユーザのカード決済の利用を可能としない処理を行うと判断された場合、ユーザのカード決済の利用を可能としない処理を行う、手段と、
　を備えるクレジット管理サーバ
　
である点で一致する。
　
ク　そして、以下の点で相違する。
＜相違点＞
（相違点１）
　本願補正発明は、「前記有効期限設定手段により設定された有効期限を超えた場合、記憶した前記ユーザＩＤと、前記決済種別データと、前記決済限度額データとを削除する削除手段」（Ｆ）を備えるのに対し、引用発明は、カード利用終了後、時間制限で指定するときは指定の時間により自動的にステータスが「ＮＧ」の状態になるものであって、「前記有効期限設定手段により設定された有効期限を超えた場合、記憶した前記ユーザＩＤと、前記決済種別データと、前記決済限度額データとを削除する削除手段」（Ｆ）を備えるか否か明示されていない点。
　
（相違点２）
　ユーザのインターネットによるカード決済に伴うリクエストが、本願補正発明では、「前記ユーザＩＤによる決済リクエスト」であるのに対し、引用発明では、「インターネットによるカード決済」の際の「顧客から取引要求があったときのカード会社の承認部門から取引承認確認」であって、「前記ユーザＩＤによる決済リクエスト」であると明示されていない点。
　
（相違点３）
　ユーザのインターネットによるカード決済に伴うリクエストとして、本願補正発明は「決済種別データを識別する決済種別認識コード」と「当該決済種別データに対応した決済額データ」を受信するのに対し、引用発明は、これを受信するか否か明示されていない点。
　
（相違点４）
　ユーザのカード決済の利用を可能としない処理が、本願補正発明では、「決済サーバとの通信を行わない」というものであるのに対し、引用発明では、不承認とする旨の通知を行っており、「決済サーバとの通信を行わない」ものではない点。
　
（相違点５）
　ユーザのカード決済の利用を可能とする処理と可能としない処理のいずれを実行するかの判断が、本願補正発明では、「前記決済データ記憶手段に記憶された決済種別データと同一の決済種別であって、かつ当該決済種別データに対応した決済額データが前記決済データ記憶手段に記憶された決済限度額内である場合」か「前記決済データ記憶手段に記憶された決済種別データと同一の決済種別でない、または当該決済種別データに対応した決済額データが前記決済データ記憶手段に記憶された決済限度額内でない場合」かの判断であるのに対し、引用発明では、「ステータス情報ファイルを参照して取引要求を承認していいかどうかを確認し、「ステータス選択」に応じて、「ステータス」、指定されたカード利用承認回数を示す「回数」、指定されたカード利用承認時間を示す「開始」及び「終了」を参照して判定するにあたって、「前記決済データ記憶手段に記憶された決済種別データと同一の決済種別であって、かつ当該決済種別データに対応した決済額データが前記決済データ記憶手段に記憶された決済限度額内である場合」か「前記決済データ記憶手段に記憶された決済種別データと同一の決済種別でない、または当該決済種別データに対応した決済額データが前記決済データ記憶手段に記憶された決済限度額内でない場合」かの判断を行うと明示されていない点。
　
（５）相違点の判断
ア　相違点１について
（ア）カードの利用条件として期間を指定した場合に、その期間の終了後にそのカードが利用できる状態であることを示す状態情報を削除するか否かは、当業者が適宜選択設計すべきことであり、引用発明において、期間終了に伴ってカードが利用できなくなる場合のステータス情報ファイルの利用期間を示す行を削除するように構成することは、当業者が適宜なし得たことである。
（イ）また、引用発明において、指定の時間により自動的にステータスを「ＮＧ」の状態にするにあたって時間の指定を含むレコードの削除を伴う方法を採用することも、当業者が適宜選択設計すべきことであって、この観点からも、容易想到でないということができない。
　引用発明のステータス情報ファイルにおける「ステータス」が「ＮＧ」のレコードとは、ある「カードＮＯ」の値が示すカードについて「ステータス」が「ＮＧ」かつ「ステータス選択」が「０」である「通常」を示すレコードである（段落【００２１】、【００３２】）ところ、ステータス情報ファイルは、「カードＮＯ」の項目の値が同じで「ステータス選択」や「利用可能範囲」等の項目の値が異なる複数のレコードが存在し得るものである（図６）から、開始及び終了時間を指定してカードを利用する際のステータス情報ファイルの編集にあたって、そもそも「通常」を示すレコードを残したままとしておくことが可能であるし、そのように「通常」を示すレコードを残したまま開始及び終了時間を指定した場合には、終了後に「ステータス」を「ＮＧ」になるとは、終了後に「ステータス選択」が「２」で「開始」「終了」が指定されたレコードが削除されることによって「カードＮＯ」に対応する「ステータス」が「ＮＧ」になるようにするのが自然である。
　このように、引用発明においては、「カードＮＯ」に対応する「ステータス」を「ＮＧ」にする制御を実現するために、（Ａ）「ステータス選択」が「２」で「開始」「終了」が指定されたレコードの削除を伴わない方法（レコード中の「ステータス」及び「ステータス選択」の値を個別に書き換える方法）と（Ｂ）このレコードの削除を伴う方法（「通常」を示すレコードが残されたままであることを前提としてこのレコードを削除する、「通常」を示すレコードを追加しつつこのレコードを削除する、等により、「カードＮＯ」に対応する「ステータス」を「ＮＧ」とする方法）のいずれを採用して実現するかについては明示されていないものの、図６に例示された内容等に照らせば、「ステータス」及び「ステータス選択」の値を個別に書き換える必要が生じない（Ｂ）の方法の採用がより自然であるといえる。この点、引用文献１の段落【００３７】の「指が挿入されている間のみ、カード利用承認の状態になるように構成すれば、顧客はステータス２２を「ＮＧ」に戻す必要がなくなる。」との記載は、実施の形態１や実施の形態２及び３における「ステータス選択」が「０」の場合についての記載であって、回数や期間を指定した場合の処理と相容れない内容であるから、この記載を根拠として、期間を指定した場合の処理において前者の採用が自然であるということはできない。
　もっとも、引用文献１において（Ａ）と（Ｂ）のいずれの方法により実現するかが明示されていないこと自体、いずれの方法によるかが記載するまでもない事項であるとの整理を示しているともいえる。
（ウ）以上によれば、引用発明において、期間終了に伴ってカードが利用できなくなる場合のステータス情報ファイルの利用期間を示す行を削除することとして、「前記有効期限設定手段により設定された有効期限を超えた場合、記憶した前記ユーザＩＤと、前記決済種別データと、前記決済限度額データとを削除する削除手段」を備えるようにすることは、明示されていないものの当業者が適宜なし得たことであるから、引用発明において、「前記有効期限設定手段により設定された有効期限を超えた場合、記憶した前記ユーザＩＤと、前記決済種別データと、前記決済限度額データとを削除する削除手段」に相当する構成を備えることは、当業者が容易になし得たことである。
　
イ　相違点２と相違点４について
（ア）相違点２と相違点４は、相互に関連しており、まとめて検討する。
　
（イ）いわゆる与信審査のような、ユーザのインターネットによるカード決済に伴うリクエストを受信してユーザのカード決済の利用を可能とする処理と可能としない処理のいずれを実行するかの判断にあたって、決済を行う計算機ではなく、決済を行う計算機の前段の計算機においてカード番号等による決済リクエストを受信して判断を行い、ユーザのカード決済の利用を可能としない処理として決済を行う計算機への通信を行わないことは、（２）イにおいて上述した周知例１や（２）ウにおいて上述した周知例２にあるように、周知技術である。
　
（ウ）そして、引用発明の照会システムは、ユーザのインターネットによるカード決済に伴ってカード番号等であるユーザＩＤによる決済リクエストを受信したカード会社の承認部門からの取引承認確認を受けて、ユーザのカード決済の利用を可能とする処理と可能としない処理のいずれを実行するかを判断するものであって、いわば、与信審査のような判断を決済を行う計算機ではない計算機において行うものである。
　
（エ）してみると、引用発明において上記周知技術を採用して、与信審査のような判断を計算機を決済を行う計算機の前段の計算機で行うように構成して、カード番号等による決済リクエストを受信してユーザのカード決済の利用を可能としない処理を実行する場合に決済サーバへの通信を行わないようにすることは、当業者が容易になし得たことである。
　
ウ　相違点３と相違点５について
（ア）相違点３と相違点５は、相互に関連しており、まとめて検討する。
　
（イ）引用発明は、ステータス情報ファイルにおいて、顧客指定によるカード利用承認情報として、カード利用承認時間を示す情報のみならず、決済種別データである利用可能カテゴリ及び利用可能範囲と決済限度額データである利用可能金額とを有しており、そのことによって、「顧客は詳細な指定ができる」（段落【００３９】）ものである。
　このことから、顧客が詳細に指定したとおりの利用制限の実現に必要な判断がなされていることは、引用文献１に明示されていなくても当然のことであるから、そのために、引用発明において、ステータス情報ファイルにおけるカード利用承認時間を示す情報を参照して判定するにあたって、リクエストとして決済種別を識別するデータと決済額データを受信し、受信したデータに基づいて識別される決済種別がステータス情報ファイルに記憶された決済種別データが示す決済種別と同一であり、かつ、受信した決済額データがその決済種別に対応する決済限度額データが示す決済限度額内である場合を承認とし、受信したデータに基づいて識別される決済種別がステータス情報ファイルに記憶された決済種別データが示す決済種別と同一でない、または、受信した決済額データがその決済種別に対応する決済限度額データが示す決済限度額内でない場合を不承認とすることは、実質的な相違点でないか、相違点であるとしても当業者が適宜なし得たことである。
　
エ　効果及び総合評価
　本願補正発明の相違点１乃至５に係る構成を採用することの効果は、引用文献１及び各周知例の記載に照らして、当業者が当然に予想する範囲のものであって、格別なものでない。
　
（６）小括
　以上のとおり、本願補正発明は、引用発明及び周知技術に基づいて当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により独立して特許を受けることができない。
　
３　補正の却下の決定のまとめ
　してみると、本件補正は、特許法第１７条の２第６項において準用する同法第１２６条第７項が規定する要件に適合しないものであるから、同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　よって、上記補正却下の決定の結論のとおり決定する。
　
第３　本願発明について
１　本願発明
　「第２」において上述したとおり、本件補正は却下されたので、本願の特許請求の範囲は、平成２９年５月１２日に提出された手続補正書に記載された特許請求の範囲の記載のとおりのものであり、その請求項１に係る発明（以下、「本願発明」という。）は、以下のとおりのものである。
　なお、本願発明を認定するにあたっても、「第２」における本願補正発明の認定と同様に、「決済判断手段」が「受信」する「決済リクエスト」である「当該決済種別データに対応する決済限度額データ」（及び「当該決済種別データに対応した決済限度額データ」）は、
いずれも、「当該決済種別データに対応した決済額データ」の誤記であると認め、この誤記を訂正し
　
Ａ　ユーザ端末からユーザを識別するユーザＩＤを受信するユーザＩＤ受信手段と、
Ｂ　決済の種別を決める決済種別データと、当該決済種別データに対応した決済の限度額を示す決済限度額データとを受信する決済データ受信手段と、
Ｃ　受信した前記ユーザＩＤと、前記決済種別データと、前記決済限度額データとを対応付けて記憶する決済データ記憶手段と、
Ｄ　前記決済データ記憶手段に記憶した前記決済種別データと、前記決済限度額データとを編集する編集手段と、
Ｅ　前記決済データ記憶手段に記憶した前記ユーザＩＤと、前記決済種別データと、前記決済限度額データとに有効期限を設定する有効期限設定手段と、
Ｆ　前記有効期限設定手段により設定された有効期限を超えた場合、記憶した前記ユーザＩＤと、前記決済種別データと、前記決済限度額データとを削除する削除手段と、
Ｇ’前記ユーザＩＤによる決済リクエストであって、前記決済種別データを識別する決済種別認識コードと、
当該決済種別データに対応した決済額データ
当該決済種別データに対応した決済額データ
Ｈ　を備えるクレジット管理サーバ。
　
２　引用文献等及び引用発明について
　引用文献等及び引用発明については、「第２」の「２」の（２）及び（３）において示したとおりである。
　
３　判断
　本願発明は、「第２」において検討した本願補正発明から、「決済判断手段」が「
前記決済データ記憶手段に記憶された決済種別データと同一の決済種別でない、または当該決済種別データに対応した決済限度額データが前記決済データ記憶手段に記憶された決済限度額内でない場合には決済サーバとの通信を行わない
　
　そうすると、本願発明の発明特定事項を全て含み、さらに、該限定事項により限定されたものに相当する本願補正発明が「第２」の「２」において説示したように、引用発明及び周知技術に基づいて当業者が容易に発明をすることができたものであるから、本願発明も、同様の理由により、引用発明及び周知技術に基づいて当業者が容易に発明をすることができたものである。
　
４　むすび
　以上のとおり、本願発明は、特許法第２９条第２項の規定により特許を受けることができないから、その他の請求項について検討するまでもなく、本願は拒絶されるべきである。
　よって、結論のとおり、審決する。