審決検索MVP
← 検索一覧に戻る
特許拒絶査定不服審判

2017-018367

クレジット管理サーバ、クレジット管理方法及びクレジット管理サーバ用プログラム

審判番号
2017-018367
法域
特許
審判種別
拒絶査定不服審判(拒絶査定不服の審決)
出願番号
特願2015-052449外部サイト(J-PlatPat)へ移動します
請求日
2017年12月11日
審決日
2018年12月25日
公報発行日
2019年04月26日
結論
請求不成立
当事者
審判長/審判官
分類
P18 .121-Z (G06Q) / P18 .575-Z (G06Q)
根拠条文(結論部分から自動抽出・参考)
特許法29条2項
条文(本文から自動抽出・参考)
特許法第29条第2項、特許法第17条の2第5項第2号、特許法第17条の2第6項
データ出所
審決公報(SGML)

事件の表示

特願2015- 52449「クレジット管理サーバ、クレジット管理方法及びクレジット管理サーバ用プログラム」拒絶査定不服審判事件〔平成28年 9月29日出願公開、特開2016-173665〕について、次のとおり審決する。

結論

【結 論】 本件審判の請求は、成り立たない。

理由

【理 由】 第1 手続の経緯 本願は、平成27年3月16日に出願された特許出願であって、平成29年2月28日付けで拒絶理由通知がされ、同年5月12日付けで意見書及び手続補正書が提出されたが、同年9月27日付けで拒絶査定(原査定)がされ、同拒絶査定の謄本が請求人に送達された。 これに対し、同年12月11日に拒絶査定不服審判の請求がなされ、それと同時に手続補正がなされたものである。 第2 平成29年12月11日にされた手続補正についての補正の却下の決定 [補正の却下の決定の結論] 平成29年12月11日にされた手続補正(以下、「本件補正」という。)を却下する。 [理由] 1 本件補正について 本件補正は、特許請求の範囲等を変更するものであり、平成29年5月12日に提出された手続補正書に記載された特許請求の範囲の請求項1の記載(下記(1))を同年12月11日に提出された手続補正書に記載された特許請求の範囲の請求項1の記載(下記(2))のとおりに補正することをその一部に含むものである。 (1)平成29年5月12日に提出された手続補正書記載の特許請求の範囲の請求項1 ユーザ端末からユーザを識別するユーザIDを受信するユーザID受信手段と、 決済の種別を決める決済種別データと、当該決済種別データに対応した決済の限度額を示す決済限度額データとを受信する決済データ受信手段と、 受信した前記ユーザIDと、前記決済種別データと、前記決済限度額データとを対応付けて記憶する決済データ記憶手段と、 前記決済データ記憶手段に記憶した前記決済種別データと、前記決済限度額データとを編集する編集手段と、 前記決済データ記憶手段に記憶した前記ユーザIDと、前記決済種別データと、前記決済限度額データとに有効期限を設定する有効期限設定手段と、 前記有効期限設定手段により設定された有効期限を超えた場合、記憶した前記ユーザIDと、前記決済種別データと、前記決済限度額データとを削除する削除手段と、 前記ユーザIDによる決済リクエストであって、前記決済種別データを識別する決済種別認識コードと、当該決済種別データに対応する決済限度額データとを受信した際に、前記決済データ記憶手段に記憶された決済種別データと同一の決済種別であって、かつ当該決済種別データに対応した決済限度額データが前記決済データ記憶手段に記憶された決済限度額内である場合にのみ、決済サーバに決済依頼処理を送信し決済を実行する決済判断手段と、 を備えるクレジット管理サーバ。 (2)平成29年12月11日に提出された手続補正書記載の特許請求の範囲の請求項1(下線は補正箇所を示す。) ユーザ端末からユーザを識別するユーザIDを受信するユーザID受信手段と、 決済の種別を決める決済種別データと、当該決済種別データに対応した決済の限度額を示す決済限度額データとを受信する決済データ受信手段と、 受信した前記ユーザIDと、前記決済種別データと、前記決済限度額データとを対応付けて記憶する決済データ記憶手段と、 前記決済データ記憶手段に記憶した前記決済種別データと、前記決済限度額データとを編集する編集手段と、 前記決済データ記憶手段に記憶した前記ユーザIDと、前記決済種別データと、前記決済限度額データとに有効期限を設定する有効期限設定手段と、 前記有効期限設定手段により設定された有効期限を超えた場合、記憶した前記ユーザIDと、前記決済種別データと、前記決済限度額データとを削除する削除手段と、 前記ユーザIDによる決済リクエストであって、前記決済種別データを識別する決済種別認識コードと、当該決済種別データに対応する決済限度額データとを受信した際に、前記決済データ記憶手段に記憶された決済種別データと同一の決済種別であって、かつ当該決済種別データに対応した決済限度額データが前記決済データ記憶手段に記憶された決済限度額内である場合にのみ、決済サーバに決済依頼処理を送信し決済を実行し、前記決済データ記憶手段に記憶された決済種別データと同一の決済種別でない、または当該決済種別データに対応した決済限度額データが前記決済データ記憶手段に記憶された決済限度額内でない場合には決済サーバとの通信を行わない決済判断手段と、 を備えるクレジット管理サーバ。 (3)目的要件について 請求項1についての補正は、「決済判断手段」が「前記決済データ記憶手段に記憶された決済種別データと同一の決済種別でない、または当該決済種別データに対応した決済限度額データが前記決済データ記憶手段に記憶された決済限度額内でない場合には決済サーバとの通信を行わない」ものである旨を直列的に付加するものであり、特許法第17条の2第5項第2号に規定する特許請求の範囲の減縮を目的とするものである。 そこで、本件補正後の請求項1に記載された発明(以下、「本願補正発明」という。)が同法第17条の2第6項において準用する同法第126条第7項が規定する要件(独立特許要件)を満たすものであるか否かを検討する。 2 独立特許要件違反についての検討 (1)本願補正発明 本願補正発明は、平成29年12月11日に提出された手続補正書記載の特許請求の範囲の請求項1(上記1(2))の記載に照らし、以下のとおりのものと認める。 なお、本願補正発明を認定するにあたり、「決済判断手段」が「受信」する「決済リクエスト」である「当該決済種別データに対応する決済限度額データ」(及び「当該決済種別データに対応した決済限度額データ」)は、本願明細書段落【0069】の記載等からみて、いずれも、「当該決済種別データに対応した決済額データ」の誤記であると認め、この誤記を訂正した。(訂正箇所には下線を引いた。また、便宜的に項番を付した。) A ユーザ端末からユーザを識別するユーザIDを受信するユーザID受信手段と、 B 決済の種別を決める決済種別データと、当該決済種別データに対応した決済の限度額を示す決済限度額データとを受信する決済データ受信手段と、 C 受信した前記ユーザIDと、前記決済種別データと、前記決済限度額データとを対応付けて記憶する決済データ記憶手段と、 D 前記決済データ記憶手段に記憶した前記決済種別データと、前記決済限度額データとを編集する編集手段と、 E 前記決済データ記憶手段に記憶した前記ユーザIDと、前記決済種別データと、前記決済限度額データとに有効期限を設定する有効期限設定手段と、 F 前記有効期限設定手段により設定された有効期限を超えた場合、記憶した前記ユーザIDと、前記決済種別データと、前記決済限度額データとを削除する削除手段と、 G 前記ユーザIDによる決済リクエストであって、前記決済種別データを識別する決済種別認識コードと、当該決済種別データに対応した決済額データとを受信した際に、前記決済データ記憶手段に記憶された決済種別データと同一の決済種別であって、かつ当該決済種別データに対応した決済額データが前記決済データ記憶手段に記憶された決済限度額内である場合にのみ、決済サーバに決済依頼処理を送信し決済を実行し、前記決済データ記憶手段に記憶された決済種別データと同一の決済種別でない、または当該決済種別データに対応した決済額データが前記決済データ記憶手段に記憶された決済限度額内でない場合には決済サーバとの通信を行わない決済判断手段と、 H を備えるクレジット管理サーバ。 (2)引用文献等 ア 引用文献1(主引用文献) 原査定の理由において引用された特開2002-197392号公報(以下、「引用文献1」という。)は、公開日が本願の出願前の平成14年7月12日である特許公報であって、図面とともに、以下の記載がある。 (ア) 「【0001】【発明の属する技術分野】この発明は、カード会社と契約した顧客が本人の意思によりカードを利用することを第三者保証機関に通知することにより、カードの悪用、不正利用を防ぐために、第三者保証機関がカード会社に対して顧客の取引意思有無を保証するカード保証システム及びカード保証方法に関するものである。」 (イ) 「【0009】この発明は上記のような問題点を解決するためになされたもので、以下のことを目的とする。第三者保証機関が、本人認証情報及び取引承認項目を管理することで、本人認証を確実に行う。本人認証を確実に行うことにより、盗難カードや偽造カードによる第三者の不正利用を防止する。インターネットでカード決済をするときも、本人認証を確実に行うことにより、盗難カードや偽造カードによる第三者の不正利用を防止する。第三者保証機関が、本人認証情報及び取引承認項目を管理することで、カード利用者が所有する複数のカード情報を一括管理することができる。それにより、カード利用者が複数のカードを盗まれたり、紛失したときでも、第三者保証機関に連絡することにより、複数のカードの利用を一括して停止することができる。」 (ウ) 「【0019】【発明の実施の形態】実施の形態1.図1は、この発明の実施の形態1である第三者保証機関照会システムを実現するためのシステム構成図である。図1において、1は照会システム、2はカード会社と契約した顧客から必要な情報が送信される端末、3はカード会社の承認部門である。本実施の形態における端末2は、携帯端末または携帯電話など顧客が所有する端末であるとする。また、4は端末2より本人認証情報及びカード利用承認情報を受付ける受付手段、5は受付手段4より渡された本人認証情報により顧客であるかどうかを判定、認証する本人認証手段、6は本人認証手段5が用いる認証情報が格納されている認証情報ファイルである。・・・ 【0020】さらに、7は受付手段4より渡されたカード利用承認情報によりカード毎の利用可能条件を変更するステータス変更手段、8はステータス変更手段7により変更可能なカード毎の利用可能条件が格納されているステータス情報ファイルである。また、9はカード会社の承認部門3から顧客からの取引要求に基づいた取引承認確認を受付け、ステータス情報ファイル8を参照することにより、取引要求を承認するかどうかを承認部門3へ通知する承認手段である。」 (エ) 「【0021】図2は、実施の形態1で用いるステータス情報ファイル8である。ステータス情報ファイル8には、顧客ID11、カードNO12、ステータス13が格納されている。ステータス13は、顧客が指定するカード利用を承認するか否かを示すフラグであり、顧客のみが変更できるものである。例えば「NG」はカード利用を承認しないとし、「OK」はカード利用を承認するとする。ステータス13は、通常「NG」となっていて、顧客がカードを利用しようとするとき「OK」とするものとする。」 (オ) 「【0023】図3は、顧客から本人認証情報及びカード利用承認情報が送信されたときの照会システム1における処理の流れを示すフローチャートである。ステップS1において、端末2より本人認証情報及びカード利用承認情報が送信されると、受付手段4がそれを受信する。受付手段4は本人認証情報を本人認証手段5に、カード利用承認情報をステータス変更手段7へ受け渡す。 【0024】ステップS2において、本人認証手段5が受け渡された本人認証情報と認証情報ファイル6とを比較することにより、顧客であるかどうかを判定し、顧客であるときはその顧客名を認証し、ステップS3に処理が進む。・・・ 【0025】ステップS3では、本人認証手段5が認証した顧客名に基づき、ステータス変更手段7がステータス情報ファイル8の顧客ID11を参照し、カード利用承認情報として送信されたカード番号に基づき参照されたカードNO12のステータス情報13を変更する。 【0026】図3に示した処理は、顧客がカード利用を開始するために、通常「NG」となっているステータス13を「OK」にするとき、または顧客がカード利用を終了するために、「OK」にしたステータス13を「NG」にするとき、行われる。」 (カ) 「【0027】図4は、顧客から取引要求があったとき、例えば顧客が店舗に赴きカードによる買い物をしようとしたときに、照会システム1においてカード会社の承認部門3から取引承認確認を受け付けた後の処理の流れを示すフローチャートである。ステップS11において、取引承認手段9が承認部門3より取引承認確認を受け付け、顧客IDを指定される。その後、ステップS12において取引承認手段9が指定された顧客IDからステータス情報ファイル8を参照し、取引要求を承認していいかどうかを確認する。ステータス情報13が「OK」となっているときは、取引要求を承認するとし、ステップS13で承認部門3へ取引要求を承認する旨を通知する。また、ステータス情報13が「NG」となっているときは、取引要求を承認できないため、ステップS14で承認部門3へ取引要求を不承認とする旨を通知する。」 (キ) 「【0031】さらに本システムによるとインターネットでカード決済するときも本人認証が確実に行えるため、盗難カードや偽造カードによる第三者の不正利用を防止することができる。」 (ク) 「【0031】・・・実施の形態2.実施の形態2におけるシステム構成図は、実施の形態1で示した図1と同様である。また図5は、本実施の形態で用いるステータス情報ファイル8である。ステータス情報ファイル8には、顧客ID11、カードNO12及びステータス選択21、ステータス22及び回数23、開始24、終了25が格納されている。顧客ID11及びカードNO12は図2で示したステータス情報ファイル8と同一であるが、本実施の形態において特徴的なことはカード利用承認を回数または時間制限で指定できることである。 【0032】例えば図5に示したように、ステータス選択21には、「0」、「1」、「2」などの値が指定できるようにする。このとき、「0」は実施の形態1と同様に、「OK」あるいは「NG」をステータス22に指定することとし、顧客から本人認証情報及びカード利用承認情報が送信されたときに切り替えられる。またステータス選択21が「1」のときはカード利用の回数を指定する、「2」のときはカード利用を時間で制限するとし開始及び終了時間を指定する方法とする。 【0033】ステータス選択21に「1」を指定したときは、回数22にカード利用承認回数を指定するようにする。また、ステータス選択21に「2」を指定したときは、開始24及び終了25にカード利用を承認する時間の開始時間及び終了時間を指定する。 【0034】顧客から本人認証情報及びカード利用承認情報が送信されたときの照会システム1における処理の流れは、図3に示したとおりであるが、ステップS1において受け付けるカード利用承認情報に、カード利用承認方法が加えられる。カード利用承認方法について前述のとおりであり、カード利用承認を回数または時間制限で指定するときは同時に、それぞれ回数または時間制限の開始時間及び終了時間を受付けるように構成する。それにより図5に示したステータス情報ファイル8のステータス選択21から終了25までの内容が、随時書き換えられる。 【0035】また、顧客から取引要求があったとき、例えば顧客が店舗に赴きカードによる買い物をしようとしたときに、照会システム1においてカード会社の承認部門3から取引承認確認を受け付けた後の処理の流れは、図4に示したとおりである。ステップS12において、取引要求を承認していいかどうかを確認するとき、ステータス選択21の値により、ステータス22または回数23または開始24及び終了25を参照し、承認または不承認を判定する。 【0036】以上説明したように本実施の形態によると、顧客はカード利用承認方法を選択することができる。回数または時間制限で指定するときは、カード利用終了後、指定の回数または時間により自動的にステータス22が「NG」の状態になるため、図3に示した本人認証情報及びカード利用承認情報が送信する処理は、カード利用を開始するときに一度だけ行えばよい。」 (ケ) 「【0037】また本実施の形態において、顧客は端末2から本人認証情報及びカード利用承認情報を送信するではなく、カード利用のために赴いた店舗に設置された与信照会端末(図示せず)に設置された専用端末(図示せず)から本人認証情報及びカード利用承認情報を送信するように構成することもできる。このように構成することにより、顧客は端末2を有していなくても、赴いた店舗先で本システムを用いることができる。例えば、指紋により本人認証を行うように構成したときは、専用端末(図示せず)に指を挿入することで、本人認証ができる。また、指が挿入されている間のみ、カード利用承認の状態になるように構成すれば、顧客はステータス22を「NG」に戻す必要がなくなる。なお、与信照会端末(図示せず)はカード会社の承認部門3に接続されているものであり、承認部門3は与信照会端末(図示せず)からの照会に基づき、照会システム1へ取引承認確認を行う。」 (コ) 「【0037】・・・実施の形態3.実施の形態3におけるシステム構成図は、実施の形態1で示した図1と同様である。また図6は、本実施の形態で用いるステータス情報ファイル8である。ステータス情報ファイル8には、顧客ID11、カードNO12及びステータス選択31、利用可能カテゴリ32、利用可能範囲33、ステータス34、回数35、開始36、終了37、利用可能金額38が格納されている。顧客ID11及びカードNO12は、図2で示したステータス情報ファイル8と同一である。また、回数35及び開始36及び終了37は、図5で示したステータス情報ファイル8の回数23及び開始24及び終了25と同一である。 【0038】本実施の形態において特徴的なことは、利用可能カテゴリ32及び利用可能範囲33及び利用可能金額38を指定できることである。利用可能カテゴリ32は、例えば貴金属、衣類、生活雑貨など買い物の品目を定めることができる。また、利用可能範囲33は、後述するショッピングモールや百貨店などと限定したり、国内のみという指定や、または海外での利用のときは、国名による指定などが行える。これにより、例えば顧客が店舗に赴きカードによる買い物をしようとしたときに、買い物をするカテゴリ毎に利用可能金額を定めたり、海外での利用予定がないときは利用可能範囲を国内と定めることができる。 【0039】顧客から本人認証情報及びカード利用承認情報が送信されたときの照会システム1における処理の流れは、図3に示したとおりであるが、ステップS1において受け付けるカード利用承認情報に、カード利用承認方法に加えて、利用可能カテゴリ32及び利用可能範囲33及び利用可能金額38が追加される。これにより、実施の形態2で説明したカード利用承認方法と組合わせることもでき、顧客は詳細な指定ができる。」 (サ)図6 イ 周知例1 特開2013-246580号公報(以下、「周知例1」という。)は、公開日が本願の出願前の平成25年12月9日である特許公報であって、図面とともに、以下の記載がある。 (ア) 「【0036】・・・図3に示すとおり、携帯型電話機3は、制御部30と、この制御部30に接続されたメモリ31、RF(Radio Frequency)部32、入力部34、ディスプレイ35、音声入力部36、カメラ部37、及びICチップ38とを備えている。 【0037】・・・また、メモリ31には、携帯型電話機3を所有するカード会員及びその家族会員のクレジットカードに関するカード情報が格納されるカード情報データベース(DB)31Aと、クレジットカードによる取引結果に関する取引明細情報が格納される取引明細情報データベース(DB)31Bとが設けられている。・・・ ・・・ 【0042】 以下、メモリ31に設けられている各データベースの詳細について説明する。 (A)カード情報DB31A 図4は、カード情報DB31Aのレイアウトの一例を示す図である。図4に示すように、カード情報DB31Aは、クレジットカード会社を識別するための会社コードが格納される会社コードフィールド301、クレジットカードを識別するためのカードIDが格納されるカードIDフィールド302、当該クレジットカードの有効期限が格納される有効期限フィールド303、当該クレジットカードが利用可能な限度額が格納される限度額フィールド304、当該クレジットカードの利用額が格納される利用額フィールド305、クレジットカードの事故の種別(不正利用・盗難・紛失等)を示す事故コードが格納される事故コードフィールド306、家族会員が所有するクレジットカード(以下、「家族カード」という)の有無を示す情報が格納される家族カードフィールド307、家族カードを識別するための家族カードIDが格納される家族カードIDフィールド308、及び家族会員が所有する携帯型電話機で受信可能な電子メールのアドレスである家族アドレスが格納される家族アドレスフィールド309を有している。 【0043】 上記のカード情報DB31Aに蓄積されるカード情報は、与信情報送信装置1から受信した情報で構成されている。与信情報送信装置1は、会員情報DB13Aの中からカード情報を構成する情報を抽出し、その抽出した情報を携帯型電話機3に対して送信する。各情報が更新された場合、与信情報送信装置1は、適宜のタイミングでその更新情報を携帯型電話機3に対して送信し、携帯型電話機3は受信した情報を用いてカード情報を更新する。これにより、カード情報DB31Aに格納されるカード情報は最新の内容に保たれることになる。」 「【0056】(2)与信審査処理 クレジットカードを利用して商品の購入を行うカード会員は、購入代金の支払の際に、自らが携帯している携帯型電話機3を、店舗端末4に接続されているR/W装置5に近付ける。これにより、携帯型電話機3が備えるICチップ38が動作し、携帯型電話機3と店舗端末4との間の通信が可能となり、以下の与信審査処理が実行される。 【0057】図8A及び図8Bは、本実施の形態の与信審査システムにおいて実行される与信審査処理の手順を示すフローチャートである。 携帯型電話機3は、店舗端末4との間の通信が可能となった後に、カード情報DB31Aに格納されているカード情報及び生体情報31Cを含む与信審査用情報を送信する(S401)。」 (イ) 「【0060】ステップS505において加盟店情報中の当該店舗に係る情報と自加盟店情報とが一致すると判定した場合(S505でYES)、店舗端末4は、商品情報に含まれている商品の価格と、与信審査用情報に含まれているカード情報の限度額フィールド304及び利用額フィールド305にそれぞれ格納されている限度額及び利用額とを用いて、今回のクレジットカードの決済が利用限度額の範囲内であるか否かを判定する(S506)。より具体的には、限度額から利用額を差し引いた額(すなわち、利用可能額)が商品の価格以上であるか否かを判定する。 【0061】ステップS506において利用限度額の範囲内であると判定した場合(S506でYES)、店舗端末4は、カード情報の事故フィールド306に格納されている情報に基づいて、利用しようとしているクレジットカードが事故に係るカード(不正利用されているクレジットカード及び紛失の申請がなされているクレジットカード等)でないかどうかを判定する(S507)。ここで、事故に係るカードではないと判定した場合(S507でNO)、店舗端末4は後述するステップS510に進む。」 (ウ) 「【0064】ステップS507において事故に係るカードではないと判定した場合(S507でNO)、店舗端末4は、図8Bに示すように、与信が承認されたと判断し、その承認がされたことを示す承認情報を携帯型電話機3に対して送信する(S510)。」 (エ) 「【0066】なお、店舗端末4は、携帯型電話機3に対して送信する承認情報を蓄積しておき、蓄積されている承認情報に基づいて店舗精算に関する店舗精算情報を生成し、閉局される際に専用線ネットワークN2を介して店舗精算システム2に対して当該店舗精算情報を送信する。この店舗精算情報を受信した店舗精算システム2は、上述したように、受信した店舗精算情報に基づいて決済を行うために必要な決済用情報を生成する。このようにして生成された決済用情報は、店舗精算システム2からカードシステムCに設けられている決済システムに対して送られることになる。」 これらの記載によれば、周知例1には、商品の価格と与信情報送信装置から携帯型電話機が受信して携帯型電話機から店舗端末へ送信される最新の与信審査用情報の限度額及び利用額を用いて、今回のクレジットカードの決済が利用限度額の範囲内であるか否かを判定する店舗端末において、与信が承認されたと判断した場合、カードシステムに設けられた決済システムに対して送られる決済用情報の生成に用いられる店舗清算情報を生成して店舗清算システムに対して送信すること、が記載されている。 ウ 周知例2 特開2002-366862号公報(以下、「周知例2」という。)は、公開日が本願の出願前の平成14年12月20日である特許公報であって、図面とともに、以下の記載がある。 (ア) 「【0026】与信確認センタ8は、POSターミナル2からの認証確認要求に応答して、各クレジットカード会社に設置された認証用データベースにアクセスして与信可否データを作成し、当該クレジットカードの与信確認結果をPOSターミナル2に送出するようになっている。なお、各クレジットカード会社が与信確認センタ8を兼ねることも可能である。」 (イ) 「【0032】・・・まず、商品購入希望者が所望の商品の購入を店舗側に申出て、一体型ICカード10を読み出し/書込み装置4にかざす(ステップS1)。 【0033】一体型ICカード10は読み出し/書込み装置4に近づくと、上記カード情報をアンテナ18を介して無線送信する。読み出し/書込み装置4は、上記カード情報を受信してPOSターミナル2に出力する。POSターミナル2の制御部20は上記カード情報を記憶装置22に格納すると共に、当該カード情報のうち機能種別表示データに基づいて当該カードが電子マネーカードの機能を有しているか否かを判断する(ステップS2)。 【0034】・・・当該カードが電子マネーカードの機能を有している場合には、POSターミナル2の制御部20は、記憶装置22に格納した上記カード情報から電子マネー残高R1のデータを取り出す(ステップS3)。 【0035】POSターミナル2の制御部20は、取り出した電子マネー残高R1が商品の販売金額(購入希望者から見れば購入金額)Sより小さいか否かを判断する(ステップS4)。 ・・・ 【0038】次に、ステップS4で電子マネー残高R1が商品の販売金額Sより小さいと判断された場合について説明する。 ・・・ 【0041】購入電子マネー残高R1と自動入金額Dとの合計が販売金額S以上の場合にはステップS8に移行して、POSターミナル2の制御部20は、専用線6を介して与信確認センタ8に対して与信確認要求を送出する。 ・・・ 【0046】与信が認められると判断したら、POSターミナル2の制御部20は、(電子マネー残高R1+自動入金額D=電子マネー残高R3)を計算して、電子マネー残高データとして電子マネー残高R3を格納する(ステップS11)。次いで、(電子マネー残高R3-販売金額S=差引残高R4)を計算する。この差引残高R4は、残高確認のためPOSターミナル2の表示装置24で表示される(ステップS12)。・・・ 【0047】ステップS12で電子マネー残高が確認されたら、ステップS13に移行して、POSターミナル2の制御部20は、記憶装置22内のカード情報のうち電子マネー残高を差引残高R4に書き換え、利用ログの最新データを今回の商品購入データに書き換えてから、記憶装置22内のカード情報を読み出し/書込み装置4を介して一体型ICカード10に送信する(ステップS14)。一体型ICカード10の制御部14は、受信したカード情報を記憶装置12内に格納して電子マネー残高を含む各種データを更新する。 ・・・ 【0049】ステップS13における差引処理の実行により一体型ICカード10に入金された“5000円”の入金額は、電子マネーカード機能とクレジットカード機能の複数一体型ICカード10のクレジット売上として、クレジットカード番号と共にPOSターミナル2からクレジットカード会社に代金請求情報が送信される。クレジットカード会社は加盟店手数料を差引いて支払を実行し、次いで、当該クレジットカード保持者宛てに利用代金請求を行う。」 これらの記載によれば、周知例2には、残高が商品の販売金額より小さい電子マネーへの自動入金に関連して、電子マネーの読み出し/書込み装置からカード情報を受信してクレジットカード会社に対してではなく与信確認センタに対して与信確認要求を送出して与信が認められるか否かを判断するPOSターミナルの制御部において、与信が認められると判断した場合に、電子マネー残高をこれと入金額及び販売金額により計算される差引残高に書換える等を行い、クレジット売上となるこの入金額についてクレジットカード会社に代金請求を送信すること、が記載されている。 (3)引用発明の認定 ア (2)アにおいて上述した引用文献1には、実施の形態1及び実施の形態2を組み合わせられたものである実施の形態3((2)ア(コ)及び(サ))として、カード利用承認情報に、カード利用承認方法に加えて、利用可能カテゴリ及び利用可能範囲及び利用可能金額が追加され、ステータス変更手段により変更可能なカード毎の利用可能条件が格納されているステータス情報ファイルに「顧客ID」、「カードNO」、「ステータス選択」、「利用可能カテゴリ」、「利用可能範囲」、「ステータス」、「回数」、「開始」、「終了」、「利用可能金額」等の項目(【0037】、図6)の値が格納されたものが記載されている。 そして、図6によれば、いずれも「顧客ID」が「12345678」であり、「カードNO」が「35009000△△△△○○○○」又は「34449000△△△△○○××」である3行が示されている。さらに、そのうち、「カードNO」が「34449000△△△△○○××」であり、「利用可能カテゴリ」が「031」又は「032」である2行について、これが「031」の行については、「ステータス選択」、「利用可能範囲」、「回数」がそれぞれ「1」、「1」、「1」であり、「032」の行については、「ステータス選択」、「利用可能範囲」、「開始」、「終了」、「利用可能金額」がそれぞれ「2」、「2」、「200012151010」、「200012151110」、「30000」とされた例が示されている。 してみると、図6には、ステータス情報ファイルが、「顧客ID」の項目の値が同じで「カードNO」の項目の値が異なる複数のレコードや「カードNO」の項目の値が同じで「ステータス選択」や「利用可能範囲」等の項目の値が異なる複数のレコードを格納する例が示されている。そして、「顧客ID」の項目の値が同じで「カードNO」の項目の値が異なる複数のレコードが存在し得る以上、「カードNO」を用いず「顧客ID」のみを用いてステータス情報ファイルのレコードにより示される顧客の有するカード毎の利用条件を特定することはできないから、明示されていないものの、「ステータス情報」の「変更」の際(【0025】)のみならず、「取引要求」に伴う「取引」の「承認」の確認の際の「指定された顧客IDからステータス情報ファイルを参照」(【0027】)にあたっても、「顧客ID」と「カードNO」の両方(又は「カードNO」のみ)が用いられることになる。 イ (2)ア及びアによれば、引用文献1には、実施の形態3((2)ア(コ)及び(サ))に関連して、次の発明(以下、「引用発明」という。)が記載されている。(便宜的にa,b・・・の項番を付し、さらに、引用文献1の対応する段落を付した。) a(b) 店舗などによるカード利用又はインターネットによるカード決済時において(【0031】)カード会社と契約した顧客から必要な情報が送信される端末(【0019】)より送信された本人認証情報及びカード番号を含む(【0025】)カード利用承認情報を受信する受付手段(【0023】)であって、このカード利用承認情報は、カード利用承認方法、利用可能カテゴリ及び利用可能範囲及び利用可能金額が追加されたものである、(【0034】、【0039】)、受付手段と、 受付手段より渡された本人認証情報により顧客であるかどうかを判定、認証する本人認証手段(【0019】)と、 本人認証手段が用いる認証情報が格納されている認証情報ファイル(【0019】)と、 c 「顧客ID」、「カードNO」、「ステータス選択」、「利用可能カテゴリ」、「利用可能範囲」、「ステータス」、「回数」、「開始」、「終了」、「利用可能金額」等の項目(【0037】、図6)により、後記ステータス変更手段により変更可能なカード毎の利用可能条件が格納されているステータス情報ファイル(【0020】)であって、「顧客ID」の項目の値が同じで「カードNO」の項目の値が異なる複数のレコードや「カードNO」の項目の値が同じで「ステータス選択」や「利用可能範囲」等の項目の値が異なる複数のレコードを格納し得るものであり(ア,図6)、この「ステータス」は、通常「NG」となっていて、顧客がカードを利用するとき「OK」とするものであり(【0021】)、この「ステータス選択」は、これが「0」のときは「ステータス」に「OK」または「NG」を指定し、「1」のときはカード利用の回数を指定し、「2」のときはカード利用を時間で制限するとして開始及び終了時間を指定するものであり(【0032】)、 d 受付手段により渡された本人認証情報により本人認証手段が認証した顧客名に基づき顧客IDを参照し、カード利用承認情報として送信されたカード番号に基づき参照されたカードのステータス情報を変更する(【0025】)等により、カード利用承認情報によりカード毎の利用可能条件を変更するステータス変更手段(【0020】)と、 e カード利用承認情報に加えられたカード利用承認方法として、カード利用承認を回数または時間制限で指定するときは、それぞれ回数または時間制限の開始時間及び終了時間を受け付けてステータス情報ファイルの内容が随時書き換えられ(【0033】【0034】)、 f 回数または時間制限で指定するときは、カード利用終了後、指定の回数または時間により自動的にステータスが「NG」の状態になるため、本人認証情報及びカード利用承認情報の送信をカード利用を開始するときに一度だけ行えばよいものであり(【0036】)、 g 顧客から取引要求があったときのカード会社の承認部門から取引承認確認を受け付けて顧客IDが指定され、指定された顧客IDからステータス情報ファイルを参照して取引要求を承認していいかどうかを確認し(【0027】)、その際は「顧客ID」と「カードNO」の両方(又は「カードNO」のみ)が用いられ(ア、図6)、「ステータス選択」に応じて、「ステータス」、指定されたカード利用承認回数を示す「回数」、指定されたカード利用承認時間を示す「開始」及び「終了」を参照して、承認または不承認を判定し(【0032】~【0035】)、取引要求を承認し、承認部門3へ取引要求を承認する旨を通知し(【0027】)、不承認の場合は承認部門へ取引要求を不承認とする旨を通知する、(【0027】)取引承認手段と、 h を備える第三者保証機関照会システム (4)対比 ア 「A ユーザ端末からユーザを識別するユーザIDを受信するユーザID受信手段」と「B 決済の種別を決める決済種別データと、当該決済種別データに対応した決済の限度額を示す決済限度額データとを受信する決済データ受信手段」について 引用発明の「カード会社と契約した顧客」は、本願補正発明の「ユーザ」に相当し、引用発明の「インターネットによるカード決済」の際の「端末」は、このユーザが所有する携帯端末のような端末であるから、本願補正発明の「ユーザ端末」に相当する。 本願発明の「ユーザID」は、クレジット管理サーバ及び決済サーバにおいて、ユーザに対応するカード決済の利用を可能とするための条件を示すものとして記憶されてこの条件の編集と決済リクエストの処理にあたって「ユーザ」を「識別」するもの(クレジットカード会社のような決済処理を行う主体において与信払いを行う処理等の決済処理の対象ユーザと対象ユーザが用いるユーザ端末を識別するもの。本願明細書【0058】【0078】)であるところ、引用発明は、カード会社の承認部門からの取引承認確認の処理を行う第三者保証機関照会システムにおいて、「「カードNO」又は「顧客ID」と「カードNO」の両方」(以下、「カード番号等」という。)を用いて顧客の有するカード毎の利用条件を示すステータス情報ファイルの各レコードの変更及び参照にあたってこのレコードを特定するものであり、その際、レコードの特定に用いられた「カード番号等」が示すユーザとそのユーザが用いた端末が識別されているといえるから、引用発明の「カード番号等」は、本願発明の「ユーザID」に相当する。 引用発明の「カード利用承認情報」中の「利用可能カテゴリ及び利用可能範囲」は、顧客が指定した決済種別であるから、本願補正発明の「決済種別データ」に相当し、この「決済種別データ」とともに「カード利用承認情報」に追加された「利用可能金額」は、決済種別に対応する決済の限度額を示すものであるから、本願補正発明の「決済限度額データ」に相当する。 してみると、引用発明の「受付手段」は、本願補正発明の「ユーザID受信手段」の「ユーザID」を受信する機能と「決済データ受信手段」の「決済種別データ」と「決済限度額データ」を受信する機能とを備えた手段であるから、引用発明は、本願補正発明と同様に、「ユーザID受信手段」と「決済データ受信手段」に相当する機能手段を備えているといえる。 イ 「C 受信した前記ユーザIDと、前記決済種別データと、前記決済限度額データとを対応付けて記憶する決済データ記憶手段」、「D 前記決済データ記憶手段に記憶した前記決済種別データと、前記決済限度額データとを編集する編集手段」について 引用発明の「ステータス情報ファイル」の「顧客ID」及び「カードNO」、「利用可能カテゴリ」及び「利用可能範囲」、「利用可能金額」の項目は、それぞれ、ユーザID、決済種別データ、決済限度額データに対応するものであり、引用発明の「ステータス情報ファイル」は、これらを対応付けられて記憶するものであるから、本願補正発明の「決済データ記憶手段」に相当する。 また、引用発明の「ステータス変更手段」は、ユーザIDが示すカード毎の「決済種別データ」と「決済限度額データ」に対応する「利用可能カテゴリ及び利用可能範囲」と「利用可能金額」を実質的に編集するために用いられるから、本願補正発明の「編集手段」に相当する。 ウ 「E 前記決済データ記憶手段に記憶した前記ユーザIDと、前記決済種別データと、前記決済限度額データとに有効期限を設定する有効期限設定手段」について 引用発明は、利用可能カテゴリ及び利用可能範囲や利用可能金額等であるカード利用承認情報としてカード利用承認の時間制限の開始時間及び終了時間を受け付けてステータス情報ファイルを書き換えるものであるから、本願補正発明と同様に、決済データ記憶手段に記憶したユーザIDと、決済種別データと、決済限度額データとに有効期限を設定するものであるといえ、そのための「有効期限設定手段」に相当する構成を備えるものといえる。 エ 「F 前記有効期限設定手段により設定された有効期限を超えた場合、記憶した前記ユーザIDと、前記決済種別データと、前記決済限度額データとを削除する削除手段」について 引用発明は、カード利用終了後、指定の時間により自動的にステータス22が「NG」の状態になることにより、受信されるユーザID等の情報の送信をカード利用を開始するときに一度だけ行えばよいものであり、本願補正発明の「削除手段」を備えるか否かは明示されていない。(相違点1) オ 「G 前記ユーザIDによる決済リクエストであって、前記決済種別データを識別する決済種別認識コードと、当該決済種別データに対応する決済限度額データとを受信した際に、前記決済データ記憶手段に記憶された決済種別データと同一の決済種別であって、かつ当該決済種別データに対応した決済限度額データが前記決済データ記憶手段に記憶された決済限度額内である場合にのみ、決済サーバに決済依頼処理を送信し決済を実行し、前記決済データ記憶手段に記憶された決済種別データと同一の決済種別でない、または当該決済種別データに対応した決済限度額データが前記決済データ記憶手段に記憶された決済限度額内でない場合には決済サーバとの通信を行わない決済判断手段」について 引用発明の「インターネットによるカード決済」の際の「顧客から取引要求があったときのカード会社の承認部門から取引承認確認」は、カード決済を利用しようとする顧客からの取引要求に伴って与信照会がなされたカード会社の承認部門からのリクエストであり、ユーザのインターネットによるカード決済に伴うリクエストである点で、本願補正発明の「前記ユーザIDによる決済リクエスト」に対応する。 もっとも、ユーザのインターネットによるカード決済に伴うリクエストが「前記ユーザIDによる決済リクエスト」である点(相違点2)、及び、このリクエストとして「決済種別データを識別する決済種別認識コード」と「当該決済種別データに対応した決済額データ」を受信する点(相違点3)については、明示されていない。 引用発明における「取引要求を承認し、承認部門へ取引要求を承認する旨を通知」する処理と「不承認の場合は承認部門へ取引要求を不承認とする旨を通知する」処理は、それぞれ、ユーザのカード決済の利用を可能とする処理と可能としない処理である点で、本願補正発明の「決済サーバに決済依頼処理を送信し決済を実行」する処理と「決済サーバとの通信を行わない」処理に対応している。そして、ユーザのカード決済の利用を可能とする処理については、引用発明の「承認」の通知を受けたカード会社が取引要求に対応する決済を実行することになるから、この「承認」は、本願補正発明の「決済依頼処理」に相当し、引用発明は、本願補正発明と同様に、ユーザのカード決済の利用を可能とする処理として、「決済サーバに決済依頼処理を送信し決済を実行する」ものであるといえる。 もっとも、ユーザのカード決済の利用を可能としない処理については、引用発明は、不承認とする旨の通知を行っているから、この点において、「決済サーバとの通信を行わない」本願補正発明と相違している。(相違点4) 引用発明は、ユーザのカード決済の利用を可能とする処理と可能としない処理の判断にあたって「ステータス情報ファイル」を参照するから、決済データ記憶手段を参照してユーザのカード決済の利用を可能とする処理と可能としない処理のいずれを実行するかの判断が行われる点で、本願補正発明と共通している。 もっとも、ユーザのカード決済の利用を可能とする処理と可能としない処理のいずれを実行するかの判断が「前記決済データ記憶手段に記憶された決済種別データと同一の決済種別であって、かつ当該決済種別データに対応した決済額データが前記決済データ記憶手段に記憶された決済限度額内である場合」か「前記決済データ記憶手段に記憶された決済種別データと同一の決済種別でない、または当該決済種別データに対応した決済額データが前記決済データ記憶手段に記憶された決済限度額内でない場合」かの判断である点(相違点5)については、明示されていない。 カ 「H クレジット管理サーバ」について 引用発明の「第三者保証機関紹介システム」は、ユーザのインターネットによるカード決済に伴う与信照会がなされたカード会社の承認部門からのリクエストを受けた承認に係る処理を行うサーバとして機能するシステムであるから、エ及びオにおいて示した相違点において相違するものの、その余の点では本願発明の「クレジット管理サーバ」に対応している。 キ してみると、本願補正発明と引用発明とは、 <一致点> A ユーザ端末からユーザを識別するユーザIDを受信するユーザID受信手段と、 B 決済の種別を決める決済種別データと、当該決済種別データに対応した決済の限度額を示す決済限度額データとを受信する決済データ受信手段と、 C 受信した前記ユーザIDと、前記決済種別データと、前記決済限度額データとを対応付けて記憶する決済データ記憶手段と、 D 前記決済データ記憶手段に記憶した前記決済種別データと、前記決済限度額データとを編集する編集手段と、 E 前記決済データ記憶手段に記憶した前記ユーザIDと、前記決済種別データと、前記決済限度額データとに有効期限を設定する有効期限設定手段と、 G ユーザのインターネットによるカード決済に伴うリクエストを受信した際に、決済データ記憶手段を参照してユーザのカード決済の利用を可能とする処理を行うと判断された場合、ユーザのカード決済の利用を可能とする処理を行い、ユーザのカード決済の利用を可能としない処理を行うと判断された場合、ユーザのカード決済の利用を可能としない処理を行う、手段と、 を備えるクレジット管理サーバ である点で一致する。 ク そして、以下の点で相違する。 <相違点> (相違点1) 本願補正発明は、「前記有効期限設定手段により設定された有効期限を超えた場合、記憶した前記ユーザIDと、前記決済種別データと、前記決済限度額データとを削除する削除手段」(F)を備えるのに対し、引用発明は、カード利用終了後、時間制限で指定するときは指定の時間により自動的にステータスが「NG」の状態になるものであって、「前記有効期限設定手段により設定された有効期限を超えた場合、記憶した前記ユーザIDと、前記決済種別データと、前記決済限度額データとを削除する削除手段」(F)を備えるか否か明示されていない点。 (相違点2) ユーザのインターネットによるカード決済に伴うリクエストが、本願補正発明では、「前記ユーザIDによる決済リクエスト」であるのに対し、引用発明では、「インターネットによるカード決済」の際の「顧客から取引要求があったときのカード会社の承認部門から取引承認確認」であって、「前記ユーザIDによる決済リクエスト」であると明示されていない点。 (相違点3) ユーザのインターネットによるカード決済に伴うリクエストとして、本願補正発明は「決済種別データを識別する決済種別認識コード」と「当該決済種別データに対応した決済額データ」を受信するのに対し、引用発明は、これを受信するか否か明示されていない点。 (相違点4) ユーザのカード決済の利用を可能としない処理が、本願補正発明では、「決済サーバとの通信を行わない」というものであるのに対し、引用発明では、不承認とする旨の通知を行っており、「決済サーバとの通信を行わない」ものではない点。 (相違点5) ユーザのカード決済の利用を可能とする処理と可能としない処理のいずれを実行するかの判断が、本願補正発明では、「前記決済データ記憶手段に記憶された決済種別データと同一の決済種別であって、かつ当該決済種別データに対応した決済額データが前記決済データ記憶手段に記憶された決済限度額内である場合」か「前記決済データ記憶手段に記憶された決済種別データと同一の決済種別でない、または当該決済種別データに対応した決済額データが前記決済データ記憶手段に記憶された決済限度額内でない場合」かの判断であるのに対し、引用発明では、「ステータス情報ファイルを参照して取引要求を承認していいかどうかを確認し、「ステータス選択」に応じて、「ステータス」、指定されたカード利用承認回数を示す「回数」、指定されたカード利用承認時間を示す「開始」及び「終了」を参照して判定するにあたって、「前記決済データ記憶手段に記憶された決済種別データと同一の決済種別であって、かつ当該決済種別データに対応した決済額データが前記決済データ記憶手段に記憶された決済限度額内である場合」か「前記決済データ記憶手段に記憶された決済種別データと同一の決済種別でない、または当該決済種別データに対応した決済額データが前記決済データ記憶手段に記憶された決済限度額内でない場合」かの判断を行うと明示されていない点。 (5)相違点の判断 ア 相違点1について (ア)カードの利用条件として期間を指定した場合に、その期間の終了後にそのカードが利用できる状態であることを示す状態情報を削除するか否かは、当業者が適宜選択設計すべきことであり、引用発明において、期間終了に伴ってカードが利用できなくなる場合のステータス情報ファイルの利用期間を示す行を削除するように構成することは、当業者が適宜なし得たことである。 (イ)また、引用発明において、指定の時間により自動的にステータスを「NG」の状態にするにあたって時間の指定を含むレコードの削除を伴う方法を採用することも、当業者が適宜選択設計すべきことであって、この観点からも、容易想到でないということができない。 引用発明のステータス情報ファイルにおける「ステータス」が「NG」のレコードとは、ある「カードNO」の値が示すカードについて「ステータス」が「NG」かつ「ステータス選択」が「0」である「通常」を示すレコードである(段落【0021】、【0032】)ところ、ステータス情報ファイルは、「カードNO」の項目の値が同じで「ステータス選択」や「利用可能範囲」等の項目の値が異なる複数のレコードが存在し得るものである(図6)から、開始及び終了時間を指定してカードを利用する際のステータス情報ファイルの編集にあたって、そもそも「通常」を示すレコードを残したままとしておくことが可能であるし、そのように「通常」を示すレコードを残したまま開始及び終了時間を指定した場合には、終了後に「ステータス」を「NG」になるとは、終了後に「ステータス選択」が「2」で「開始」「終了」が指定されたレコードが削除されることによって「カードNO」に対応する「ステータス」が「NG」になるようにするのが自然である。 このように、引用発明においては、「カードNO」に対応する「ステータス」を「NG」にする制御を実現するために、(A)「ステータス選択」が「2」で「開始」「終了」が指定されたレコードの削除を伴わない方法(レコード中の「ステータス」及び「ステータス選択」の値を個別に書き換える方法)と(B)このレコードの削除を伴う方法(「通常」を示すレコードが残されたままであることを前提としてこのレコードを削除する、「通常」を示すレコードを追加しつつこのレコードを削除する、等により、「カードNO」に対応する「ステータス」を「NG」とする方法)のいずれを採用して実現するかについては明示されていないものの、図6に例示された内容等に照らせば、「ステータス」及び「ステータス選択」の値を個別に書き換える必要が生じない(B)の方法の採用がより自然であるといえる。この点、引用文献1の段落【0037】の「指が挿入されている間のみ、カード利用承認の状態になるように構成すれば、顧客はステータス22を「NG」に戻す必要がなくなる。」との記載は、実施の形態1や実施の形態2及び3における「ステータス選択」が「0」の場合についての記載であって、回数や期間を指定した場合の処理と相容れない内容であるから、この記載を根拠として、期間を指定した場合の処理において前者の採用が自然であるということはできない。 もっとも、引用文献1において(A)と(B)のいずれの方法により実現するかが明示されていないこと自体、いずれの方法によるかが記載するまでもない事項であるとの整理を示しているともいえる。 (ウ)以上によれば、引用発明において、期間終了に伴ってカードが利用できなくなる場合のステータス情報ファイルの利用期間を示す行を削除することとして、「前記有効期限設定手段により設定された有効期限を超えた場合、記憶した前記ユーザIDと、前記決済種別データと、前記決済限度額データとを削除する削除手段」を備えるようにすることは、明示されていないものの当業者が適宜なし得たことであるから、引用発明において、「前記有効期限設定手段により設定された有効期限を超えた場合、記憶した前記ユーザIDと、前記決済種別データと、前記決済限度額データとを削除する削除手段」に相当する構成を備えることは、当業者が容易になし得たことである。 イ 相違点2と相違点4について (ア)相違点2と相違点4は、相互に関連しており、まとめて検討する。 (イ)いわゆる与信審査のような、ユーザのインターネットによるカード決済に伴うリクエストを受信してユーザのカード決済の利用を可能とする処理と可能としない処理のいずれを実行するかの判断にあたって、決済を行う計算機ではなく、決済を行う計算機の前段の計算機においてカード番号等による決済リクエストを受信して判断を行い、ユーザのカード決済の利用を可能としない処理として決済を行う計算機への通信を行わないことは、(2)イにおいて上述した周知例1や(2)ウにおいて上述した周知例2にあるように、周知技術である。 (ウ)そして、引用発明の照会システムは、ユーザのインターネットによるカード決済に伴ってカード番号等であるユーザIDによる決済リクエストを受信したカード会社の承認部門からの取引承認確認を受けて、ユーザのカード決済の利用を可能とする処理と可能としない処理のいずれを実行するかを判断するものであって、いわば、与信審査のような判断を決済を行う計算機ではない計算機において行うものである。 (エ)してみると、引用発明において上記周知技術を採用して、与信審査のような判断を計算機を決済を行う計算機の前段の計算機で行うように構成して、カード番号等による決済リクエストを受信してユーザのカード決済の利用を可能としない処理を実行する場合に決済サーバへの通信を行わないようにすることは、当業者が容易になし得たことである。 ウ 相違点3と相違点5について (ア)相違点3と相違点5は、相互に関連しており、まとめて検討する。 (イ)引用発明は、ステータス情報ファイルにおいて、顧客指定によるカード利用承認情報として、カード利用承認時間を示す情報のみならず、決済種別データである利用可能カテゴリ及び利用可能範囲と決済限度額データである利用可能金額とを有しており、そのことによって、「顧客は詳細な指定ができる」(段落【0039】)ものである。 このことから、顧客が詳細に指定したとおりの利用制限の実現に必要な判断がなされていることは、引用文献1に明示されていなくても当然のことであるから、そのために、引用発明において、ステータス情報ファイルにおけるカード利用承認時間を示す情報を参照して判定するにあたって、リクエストとして決済種別を識別するデータと決済額データを受信し、受信したデータに基づいて識別される決済種別がステータス情報ファイルに記憶された決済種別データが示す決済種別と同一であり、かつ、受信した決済額データがその決済種別に対応する決済限度額データが示す決済限度額内である場合を承認とし、受信したデータに基づいて識別される決済種別がステータス情報ファイルに記憶された決済種別データが示す決済種別と同一でない、または、受信した決済額データがその決済種別に対応する決済限度額データが示す決済限度額内でない場合を不承認とすることは、実質的な相違点でないか、相違点であるとしても当業者が適宜なし得たことである。 エ 効果及び総合評価 本願補正発明の相違点1乃至5に係る構成を採用することの効果は、引用文献1及び各周知例の記載に照らして、当業者が当然に予想する範囲のものであって、格別なものでない。 (6)小括 以上のとおり、本願補正発明は、引用発明及び周知技術に基づいて当業者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により独立して特許を受けることができない。 3 補正の却下の決定のまとめ してみると、本件補正は、特許法第17条の2第6項において準用する同法第126条第7項が規定する要件に適合しないものであるから、同法第159条第1項において読み替えて準用する同法第53条第1項の規定により却下すべきものである。 よって、上記補正却下の決定の結論のとおり決定する。 第3 本願発明について 1 本願発明 「第2」において上述したとおり、本件補正は却下されたので、本願の特許請求の範囲は、平成29年5月12日に提出された手続補正書に記載された特許請求の範囲の記載のとおりのものであり、その請求項1に係る発明(以下、「本願発明」という。)は、以下のとおりのものである。 なお、本願発明を認定するにあたっても、「第2」における本願補正発明の認定と同様に、「決済判断手段」が「受信」する「決済リクエスト」である「当該決済種別データに対応する決済限度額データ」(及び「当該決済種別データに対応した決済限度額データ」)は、いずれも、「当該決済種別データに対応した決済額データ」の誤記であると認め、この誤記を訂正した。(訂正箇所には下線を引いた。また、便宜的に項番を付した。) A ユーザ端末からユーザを識別するユーザIDを受信するユーザID受信手段と、 B 決済の種別を決める決済種別データと、当該決済種別データに対応した決済の限度額を示す決済限度額データとを受信する決済データ受信手段と、 C 受信した前記ユーザIDと、前記決済種別データと、前記決済限度額データとを対応付けて記憶する決済データ記憶手段と、 D 前記決済データ記憶手段に記憶した前記決済種別データと、前記決済限度額データとを編集する編集手段と、 E 前記決済データ記憶手段に記憶した前記ユーザIDと、前記決済種別データと、前記決済限度額データとに有効期限を設定する有効期限設定手段と、 F 前記有効期限設定手段により設定された有効期限を超えた場合、記憶した前記ユーザIDと、前記決済種別データと、前記決済限度額データとを削除する削除手段と、 G’前記ユーザIDによる決済リクエストであって、前記決済種別データを識別する決済種別認識コードと、当該決済種別データに対応した決済額データとを受信した際に、前記決済データ記憶手段に記憶された決済種別データと同一の決済種別であって、かつ当該決済種別データに対応した決済額データが前記決済データ記憶手段に記憶された決済限度額内である場合にのみ、決済サーバに決済依頼処理を送信し決済を実行する決済判断手段と、 H を備えるクレジット管理サーバ。 2 引用文献等及び引用発明について 引用文献等及び引用発明については、「第2」の「2」の(2)及び(3)において示したとおりである。 3 判断 本願発明は、「第2」において検討した本願補正発明から、「決済判断手段」が「前記決済データ記憶手段に記憶された決済種別データと同一の決済種別でない、または当該決済種別データに対応した決済限度額データが前記決済データ記憶手段に記憶された決済限度額内でない場合には決済サーバとの通信を行わない」ものである旨の限定事項を除いたものである。 そうすると、本願発明の発明特定事項を全て含み、さらに、該限定事項により限定されたものに相当する本願補正発明が「第2」の「2」において説示したように、引用発明及び周知技術に基づいて当業者が容易に発明をすることができたものであるから、本願発明も、同様の理由により、引用発明及び周知技術に基づいて当業者が容易に発明をすることができたものである。 4 むすび 以上のとおり、本願発明は、特許法第29条第2項の規定により特許を受けることができないから、その他の請求項について検討するまでもなく、本願は拒絶されるべきである。 よって、結論のとおり、審決する。

審決本文(J-PlatPat)

J-PlatPatの審決検索トップを開きます。番号入力で「審判番号」を選び、下の番号を貼り付けて検索してください。

J-PlatPat 審決検索を開く
2017-018367

番号・当事者・条文・審決分類・商標の称呼が一致(または近い)審決を機械的に集めた候補です。判断内容は各審決の本文でご確認ください。

同じ当事者の審決43件(株式会社オプティム)
  • 2025-013567拒絶査定不服審判 / 2026-08-25 / 原査定取消(特許/登録すべき)情報処理装置、方法、プログラム、およびシステム
    同じ当事者: 株式会社オプティム
  • 2025-009973拒絶査定不服審判 / 2026-08-13 / 原査定取消(特許/登録すべき)情報処理装置、方法、プログラム、およびシステム
    同じ当事者: 株式会社オプティム
  • 2025-011987拒絶査定不服審判 / 2026-07-07 / 請求不成立ジチタイコーシキスーパーアプリ、スーパーアプリ
    同じ当事者: 株式会社オプティム
  • 2025-011283拒絶査定不服審判 / 2026-04-20 / 原査定取消(特許/登録すべき)プログラム、方法、情報処理装置、システム
    同じ当事者: 株式会社オプティム
  • 2024-013410拒絶査定不服審判 / 2025-05-09 / 原査定取消(特許/登録すべき)オプティムファーム、オプティム、ファーム
    同じ当事者: 株式会社オプティム
検索でもっと見る →
同じ根拠条文の審決7,656件(特許法29条2項)
  • 2025-002862拒絶査定不服審判 / 2026-06-23 / 請求不成立推薦装置、システム、方法及びプログラム
    共通の条文: 特許法29条2項
  • 2025-001082拒絶査定不服審判 / 2026-06-18 / 請求不成立持参収容具利用システム
    共通の条文: 特許法29条2項
  • 2025-012705拒絶査定不服審判 / 2026-04-28 / 請求不成立処理装置、処理方法及びプログラム
    共通の条文: 特許法29条2項
  • 2025-001625拒絶査定不服審判 / 2026-01-26 / 請求不成立異常解析システム、異常解析方法及びプログラム
    共通の条文: 特許法29条2項
  • 2024-017760拒絶査定不服審判 / 2025-09-22 / 請求不成立管理システム、管理装置、及び管理プログラム
    共通の条文: 特許法29条2項
検索でもっと見る →
同じ論点・分野の審決(審決分類)2,133件(121・G06Q、575・G06Q)
  • 2025-002862拒絶査定不服審判 / 2026-06-23 / 請求不成立推薦装置、システム、方法及びプログラム
    共通の審決分類: 121・G06Q、575・G06Q
  • 2025-001082拒絶査定不服審判 / 2026-06-18 / 請求不成立持参収容具利用システム
    共通の審決分類: 121・G06Q、575・G06Q
  • 2025-012705拒絶査定不服審判 / 2026-04-28 / 請求不成立処理装置、処理方法及びプログラム
    共通の審決分類: 121・G06Q、575・G06Q
  • 2025-006950拒絶査定不服審判 / 2026-03-23 / 請求不成立情報処理装置、情報処理方法および情報処理プログラム
    共通の審決分類: 121・G06Q、575・G06Q
  • 2025-004389拒絶査定不服審判 / 2026-02-16 / 原査定取消(特許/登録すべき)情報処理システム、情報処理方法、情報処理プログラム
    共通の審決分類: 121・G06Q、575・G06Q

メモ・タグ(非公開)

あなただけに表示されます。審決本文の公開範囲は変わりません。

メモとタグは Pro の機能です。ログイン/Proでメモを保存