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

2020-007851

電子決済サーバおよび電子決済方法

審判番号
2020-007851
法域
特許
審判種別
拒絶査定不服審判(拒絶査定不服の審決)
出願番号
特願2018-141101外部サイト(J-PlatPat)へ移動します
請求日
2020年06月08日
審決日
2021年10月04日
公報発行日
2021年11月26日
結論
原査定取消(特許/登録すべき)
当事者
審判長/審判官
分類
P18 .121-WY (G06Q)
条文(本文から自動抽出・参考)
特許法第29条第2項
データ出所
審決公報(SGML)

事件の表示

特願2018-141101「電子決済サーバおよび電子決済方法」拒絶査定不服審判事件〔令和 2年 1月30日出願公開、特開2020- 17171、請求項の数(6)〕について、次のとおり審決する。

結論

【結 論】
原査定を取り消す。
本願の発明は、特許すべきものとする。

理由

目次 ▾ 14項目
【理 由】

第1 手続の経緯

本願は、平成30年7月27日の出願であって、令和元年9月24日付けで拒絶理由通知がされ、同年11月27日に手続補正書が提出され、令和2年3月5日付けで拒絶査定(原査定)がされ、これに対し、同年6月8日に拒絶査定不服審判の請求がされたものである。

第2 原査定の概要

原査定(令和2年3月5日付け拒絶査定)の概要は次のとおりである。

本願請求項1-6に係る発明は、以下の引用文献1、2に基づいて、その発明の属する技術の分野における通常の知識を有する者(以下、「当業者」という。)が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。

引用文献等一覧

1.特開2002-366864号公報

2.特開2002-366862号公報

第3 本願発明

本願請求項1-6に係る発明(以下、それぞれ「本願発明1」-「本願発明6」という。)は、令和元年11月27日提出の手続補正書による補正後の特許請求の範囲の請求項1-6に記載された事項により特定される発明であり、本願発明1は以下のとおりの発明である。

「【請求項1】
ネットワークを介して端末と接続され、少なくともユーザ識別情報とユーザの電子マネーの残高とユーザの設定限度額を含む管理データベースを用いて商取引を決済する電子決済サーバであって、
プロセッサと、コンピュータ可読命令を記録する記録部と、を有し、
前記コンピュータ可読命令が前記プロセッサで実行されると、前記電子決済サーバは、
前記端末からユーザ識別情報と購入額と支払先情報を取得するステップと、
前記端末から取得した前記ユーザ識別情報に基づき、ユーザの前記残高と前記設定限度額を取得するステップと、
前記端末から取得した前記購入額が、ユーザの前記残高より大きく、かつ、ユーザの前記残高と前記設定限度額の合計以下の場合に、ユーザの前記残高を、ユーザの前記残高と前記設定限度額の合計から前記購入額を減じた数値に更新するとともに、前記支払先情報を用いて前記購入額を支払先へ送金するステップを実行し、
前記管理データベースは、ユーザの与信額を含み、
前記電子決済サーバは、前記端末から、前記与信額以下のユーザの希望する金額を取得し、該金額を前記設定限度額として前記管理データベースに登録するステップを実行する、電子決済サーバ。」

なお、本願発明2-6の概要は以下のとおりである。

本願発明2-3は、本願発明1を減縮した発明である。

本願発明4-6は、それぞれ本願発明1に対応する方法、プログラム、記録媒体の発明であり、本願発明1-3とカテゴリないし表現が異なるだけの発明である。

第4 引用文献、引用発明等

1.引用文献1について

原査定の拒絶の理由に引用された上記引用文献1には、図面とともに次の事項が記載されている。

「【0036】【発明の実施の形態】図1は、本発明が適用される電子マネーシステムの構成を表している。このシステムにおいては、インターネット1に任意の数(この例の場合、2台)のユーザ端末2?1,2?2が接続されている。また、インターネット1には、ユーザ端末2?1,2?2がアクセスして商品を購入する任意の数(この例の場合、3台)の加盟店端末4?1乃至4?3が接続されている。
・・・
【0038】インターネット1には、さらに決済装置7が接続されている。この決済装置7においては、ファイヤウォールとして機能するマネーゲート11を介して、決済メニュー(ソフトウエア)12が接続されている。決済メニュー12は、D/e-SCOTT21,Debit22,Edy23,並びにe-Wallet24(いずれもソフトウエア)を有している。マネーゲート11は、インターネット1からの入力を、その内容に対応して、D/e-SCOTT21,Debit22,Edy23,並びにe-Wallet24のいずれかに接続する。」
「【0042】e-Wallet(商標)24は、内蔵するデータベース25に、各ユーザのプリペイド分の金額を記憶する。そして、各ユーザが、インターネット1を介して、加盟店端末4?1乃至4?3から所定の商品を購入したとき、その買い物代金をプリペイド分から減額する。
【0043】決済装置7は、顧客データベース13を有し、この顧客データベース13に各ユーザと加盟店の詳細な情報を記憶する。
【0044】図2は、決算装置7の構成を表している。図2において、CPU(Central Processing Unit)41は、ROM(Read Only Memory)42に記憶されているプログラム、または記憶部48からRAM(Random Access Memory)43にロードされたプログラムに従って各種の処理を実行する。RAM43にはまた、CPU41が各種の処理を実行する上において必要なデータなども適宜記憶される。」
「【0051】次に、図1のシステムにおけるe-Walletを利用して、ユーザが、インターネット1上で商品を購入する場合の動作について、図5乃至図10のフローチャートを参照して説明する。
・・・
【0054】ユーザ端末2のCPU241は、入力部246がユーザにより操作され、加盟店端末4―2乃至4?3のうちの所定の加盟店端末に対するアクセスが指令されたとき、通信部249を制御し、指定された加盟店端末4に対して、インターネット1を介してアクセスさせる。図6を参照して後述するように、このアクセスを受けたとき、加盟店端末4は、商品の画像データを送信してくる(図6および図8のステップS22)。
【0055】そこで、ステップS2において、ユーザ端末2のCPU241は、インターネット1を介して、加盟店端末4から送信されてきた画像データを、通信部249により受信させると、それを出力部247を構成する表示部に出力し、表示させる。これにより、例えば、図11に示されるような商品の写真、商品コード、商品の名称、説明、並びに金額等が表示される。この例においては、商品は、「熊のぬいぐるみ」とされ、その商品コードは「B?100」とされ、その価格(買い物額)は「6000円」とされている。
続きを表示(全26行)
【0056】ユーザは、この表示を見て、その商品を購入するか否かを判断する。購入するとき、ユーザは、入力部246を構成するマウスを操作して、購入ボタン81をクリックする。
【0057】そこで、ステップS3において、CPU241は、ユーザから購入が指示されたか否か、すなわち、購入ボタン81が操作されたか否かを判定し、購入ボタン81が操作されていないと判定された場合、処理を終了させる。
【0058】これに対して、購入ボタン81が操作され、購入が指示されたと判定された場合、ステップS4に進み、CPU241は、加盟店端末4に対して、購入申し込み信号を出力する。この信号の送信に対応して、加盟店端末4は、支払方法選択画面を送信してくる(図6と図8のステップS24)。
【0059】そこで、ステップS5において、CPU241は、通信部249を介して、加盟店端末4から支払方法選択画面のデータを受信すると、これを出力部247の表示部に出力し、表示させる。これにより、例えば、図12に示されるようなウインドウ91が表示される。
【0060】この図12の表示例においては、ウインドウ91に、購入する商品の数を入力する入力欄91Aと、購入する商品の購入金額を支払う方法を指定する欄91Bが表示されている。ユーザは、入力部246を操作して、入力欄91Aに必要な個数を入力し、また、欄91Bに表示されている支払方法の中から、自分自身が希望する支払方法を選択する。E-Wallet24を使用する場合、ユーザは、「電子マネー」の支払方法を選択することになる。
【0061】そこで、CPU241は、ステップS6において、ユーザの指令に基づいて、電子マネーが選択されたとき、通信部249を制御して、これを加盟店端末4に通知させる。この通知に基づいて、後述するように、加盟店端末4は、決済装置7が提供するe-Wallet24の電子マネーに基づく、決済処理を取り扱う会社(管理会社)の一覧のデータを送信してくる(図6と図8のステップS26)。
【0062】そこで、ステップS7において、CPU241は、この管理会社のリストのデータを受信すると、出力部247の表示部にこれを出力し、表示させる。
【0063】このようにして、例えば、図13に示されるような電子マネー取扱会社の一覧が表示される。図13の例においては、A社乃至D社の4社が表示されている。ユーザは、この表示された会社の中から、自分自身がインターネット1上の取引に使用する電子マネーを管理している会社(いまの例の場合、決済装置7を運用する会社)を選択する。この選択も、入力部246を操作することで行われる。
【0064】この選択が行われると(図13における会社選択とOKボタンの押下が行われると)、ステップS8において、CPU241は、選択された会社を決済装置7に通知する。なお、OKボタンの押下は、選択された会社(A社)の特定情報をパラメータに含むURLを生成し、そのURL情報に基づき、A社の決済装置上で管理されている決済画面へダイレクションを行う。
【0065】決済装置7は、この通知に基づいて、パスワード入力画面をユーザ端末2に送信してくる(図7と図8のステップS51,52)。
【0066】そこで、ステップS9において、CPU241は、ステップS8の処理で指定した会社の装置(この例の場合、決済装置7)から送信されてきた本人確認のためのパスワード入力画面のデータを受信すると、これを出力部247の表示部に出力し、表示させる。これにより、例えば、図14に示されるようなパスワード入力画面が表示される。なお、この図14の表示例においては、パスワードの他、会員番号を入力する欄が設けられている。
【0067】ユーザは、この入力画面の各欄に、会員番号とパスワードを入力部246を操作して、入力する。
【0068】そこで、CPU241は、ステップS10において、入力された会員番号とパスワードのデータを取り込むと、これを決済装置7に通知する。
【0069】決済装置7は、この通知に対応してパスワードが正当なものであるか否かを認証し、正しいものであるとの判断結果が得られた場合には、そのユーザの電子マネーの残高を読み取り、それを送信してくる(図7と図8のステップS55)。
【0070】そこで、ステップS11において、CPU241は、決済装置7から送信されてきた残高を受信すると、これを出力部247の表示部に出力し、表示させる。これにより、例えば、図15に示されるような画像が表示される。
【0071】図15の表示例においては、会員番号101のXさんの電子マネーの残高が「5025円」とされ、購入する商品は、商品コードB100の商品とされ、その買い物額は6000円であるとされている。さらに、この場合、買い物額(6000円)が、電子マネーの残高(5025円)より大きいので、「975円不足です」とのメッセージも表示されている。そして、さらにこの表示例においては、「購入しますか」のメッセージと、それに応答するためのYESボタンとNOボタンが表示されている。
【0072】ユーザは、いま自分自身が保持している電子マネーの残高が、買い物額に満たないことを、この表示から知ることができ、それでも商品を購入するか否かを判断し、購入する場合には、YESボタンを操作し、購入しない場合には、NOボタンを操作することになる。
【0073】そこで、ステップS12において、CPU241は、購入が指示されたか否か(YESボタンが操作されたか否か)を判定し、操作されていない場合(NOボタンが操作された場合)、処理を終了させる。
【0074】これに対して、購入が指示されたと判定された場合(YESボタンが操作されたと判定された場合)、ステップS13に進み、CPU241は、決済装置7に対して商品の購入を通知する。なお、図11の購入ボタン81を押したことにより、購入意志があるものとみなして、図15の確認画面の表示を省略して、与信処理を行うことも可能である。
【0075】決済装置7は、この購入通知を受信すると、そのユーザの電子マネーの残高が買い物額以上であるか否かを判定し、買い物額以上である場合には、OK電文を加盟店端末4に送信する(図7と図8のステップS59)。
【0076】また、決済装置7は、残高が買い物額より少ない場合には、与信処理を行い、与信がOKの場合には、やはりOK電文を加盟店端末4に送信する(図7と図9のステップS59)。
【0077】加盟店端末4は、このようなOK電文を受信したとき、商品の配送処理を実行するとともに、ユーザ端末2にメッセージを送信してくる(図6、図8、および図9のステップS29)。」
「【0097】OK電文が受信された場合には、ステップS29に進み、CPU141は上述したように、「ありがとうございました。商品を速やかに発送します。」のようなメッセージを生成し、通信部149からユーザ端末2に送信させる。また、CPU141は、通信部149を介して所定の配送センタに要求し、対応する商品の配送を依頼する。
【0098】その後、ステップS30において、CPU141は、予め設定されている所定日に、決済装置7から買い物額に対応する金額の送金を受ける。より正確には、決済装置7は、この買い物額に対応する電子マネーを、ユーザの口座から加盟店端末4の口座に移動させるので(図7、図8、図9のステップS61)、その分の金額の送金を受ける。」
「【0102】次に、図7のフローチャートを参照して、図5のユーザ端末2と図6の加盟店端末4の処理に対応して実行される決済装置7の処理について説明する。
【0103】ステップS51において、決済装置7のCPU41は、加盟店端末4からの残高照会(図6と図8のステップS28の処理に基づく照会)を受け付けると、ステップS52において、記憶部48に記憶されているユーザを確認するパスワードの入力画面のデータを読み出し、ユーザ端末2に送信させる。
【0104】ユーザは、この入力画面に対応して、パスワードと会員番号を入力し、送信してくる(図5と図8のステップS10)。
【0105】そこで、ステップS53において、CPU41は、ユーザ端末2からのパスワードと会員番号を受信すると、ステップS54において、そのパスワードと会員番号が、記憶部48への顧客データベース13中に記憶されているパスワードと会員番号に一致するか否かを判定し、一致する場合には、本人(真のユーザ)であると判定する。
続きを表示(全28行)
【0106】すなわち、図17に示されるように、顧客データベース13には、各ユーザの会員番号、パスワード、氏名、カナ氏名、生年月日、電話番号、郵便番号、住所、カード番号、カードの有効期限、ユーザが有する銀行口座の銀行コード、銀行の支店コード、口座種別、口座番号、名義人、請求データといった情報、並びに引き落とし日等の情報、決済に使用するのがクレジットカードであるのか、銀行口座であるのか、といった情報を記憶している。
【0107】図17の例では、会員番号が101,102,103の会員の顧客情報が示されている。例えば、受信された会員番号とパスワードが、それぞれ、「101」と「YA12345」であれば、本人であると判定される。
【0108】パスワードと会員番号に基づく認証処理の結果、ユーザが本人であると判定された場合、ステップS55において、CPU41は、そのユーザの電子マネーの残高をデータベース25から読み取り、これをユーザ端末2に送信する。
【0109】データベース25には、図18に示されるように、顧客データベース13に登録されている会員(ユーザ端末2のユーザ)の会員番号、残高、並びに与信レベルが記憶されている。
【0110】図18の例の場合、会員番号101のユーザの残高は5025円、与信レベルはB、会員番号102のユーザの残高は3000円、与信レベルはC、会員番号103のユーザの残高は10000円、与信レベルはAとされている。
【0111】ステップS55の処理で送信される情報には、図15を参照して説明したように、そのユーザの現在の残高(5025円)、買い物額(6000円)が含まれ、この情報に基づいて、ユーザが最終的にその商品を購入するか否かを通知してくる(図5と図8のステップS13)。
【0112】そこで、ステップS56において、CPU41は、ユーザ端末2から購入申し込みを受けたか否かを判定し、購入申し込みを受けていない場合には、処理を終了させる。
【0113】これに対して、購入申し込みを受けた場合には、ステップS57に進み、CPU41は、ステップS55の処理で読み出された残高が、ステップS51の処理で受け付けられた買い物額と等しいか、またはそれより大きいか否かを判定する。
【0114】例えば、いま、会員番号103のユーザが買い物額6000円の商品を購入するものとする。この場合、残高(10000円)(図18)は買い物額(6000円)より大きいので、ステップS58に進み、CPU41は、会員番号103のユーザの残高10000円から、買い物額6000円を減算した値4000円を、新たな残高として、会員番号103のユーザの残高に記録させる(図18の残高10000円を残高4000円に更新させる)。
【0115】そして、ステップS59において、CPU41は、OK電文(決済が正しく行われたことを表す電文)を生成し、通信部49を制御して、インターネット1を介して加盟店端末2に送信させる。
【0116】ステップS60において、CPU41は、買い物額(6000円)を請求データとして、顧客データベース13のそのユーザの請求データの欄に書き込み、記憶させる。
【0117】その後、ステップS61において、CPU41は、請求データとして記憶したユーザの電子マネーを、加盟店端末4口座に移動する。加盟店端末4の口座は、データベース25に設けられている(勿論、決定装置7の外部に設けてもよい)。
【0118】これに対して、例えば、会員番号101のユーザが6000円の買い物額の商品を購入すると、このユーザの残高は、5025円(図18)であるので、ステップS57において、残高(5025円)は、買い物額(6000円)より大きくないと判定される。この場合、ステップS62に進み、CPU41は、与信処理を自分自身で実行するか否かを判定する。与信処理を自分自身で実行しない場合には、ステップS63に進み、CPU41は、通信部49を介して、与信サーバ(例えば、そのユーザのクレジットカードを発行しているクレジットカード会社のカード会社管理装置5)に与信を依頼する。カード会社管理装置5は、この与信の依頼に基づいて、与信処理を実行すると、その結果を通知してくる。
【0119】そこで、ステップS64において、CPU41は、カード会社管理装置5からの与信結果を受信する。その与信結果には、与信レベルが含まれており、CPU41は、その与信レベルに基づいて、その後、ステップS66の処理を実行する。
【0120】一方、ステップS62において、CPU41は、与信処理を自分自身で実行すると判定した場合、ステップS65に進み、与信レベルのテーブル26からそのユーザの貸し越し額を読み出す。
【0121】すなわち、与信レベルのテーブル26には、図19に示されるように、各ユーザの与信レベル(図18)に対応して、貸し越し額が記載されている。図19の例の場合、与信レベルAのユーザの貸し越し額は30000円、与信レベルBのユーザの貸し越し額は5000円、与信レベルCのユーザの貸し越し額は0円(すなわち、プリペイド分のみ)と規定されている。
【0122】図18に示されるように、会員番号101のユーザの与信レベルはBである。従って、図19からそのユーザの貸し越し額が5000円となる。
【0123】ステップS66において、CPU41は、ステップS65で読み出された貸し越し額が0円であるか否か、すなわち、貸し越しが認められないユーザであるか否かを判定する。貸し越し額が0円でない場合には、ステップS67に進み、CPU41は、その貸し越し額を残高に加算する演算を行う。会員番号101のユーザの与信レベルBに基づいて、貸し越し額が5000円となるので、いまの場合、貸し越し額と残高の合計値は、10025円(=5025+5000)となる。
【0124】ステップS68において、CPU41は、ステップS67で演算された貸し越し額と残高の合計値が、買い物額と等しいか、またはそれより大きいか否かを判定する。貸し越し額と残高の合計値が買い物額と等しいか、またはそれより大きい場合には、ステップS69に進み、CPU41は、ステップS67の処理で決定した貸し越し額を、そのユーザに対する自分自身の売上として記憶させる。この記憶された額は、ユーザが指定した口座(クレジットカード、金融機関の口座など)から、所定のタイミング(クレジットカードの場合、所定の引き落とし日、debit決済対応の金融機関の口座の場合、即時)で引き落とされる。
【0125】なお、ステップS69の処理は、ステップS66とS67の間、または、ステップS67とS68の間に挿入するようにしてもよい。この場合、ユーザが途中で購入処理をキャンセルし、ユーザが最終的に商品を購入しなくても、ユーザに対して貸し越しが行われる。
【0126】その後、ステップS58に戻り、それ以降の処理が実行される。
【0127】すなわち、ステップS58において、CPU41は、残高から買い物額を減算した値を新しい残高として更新する。その結果、いまの場合、4025円が残高とされる。ステップS59でOK電文が生成され、加盟店端末4に送信される。
【0128】ステップS60において、CPU41は、買い物額(いまの例の場合、6000円)を請求データとして、そのユーザの顧客データベース13の請求データ欄に記憶させる。
【0129】その後、ステップS61において、上述した場合と同様に、請求データ分の電子マネーが、加盟店端末4の口座に移動される。」

以上の引用文献1の記載によれば、上記引用文献1には次の発明(以下、「引用発明」という。)が記載されていると認められる。

「インターネットに接続された決済装置、任意の数のユーザ端末、任意の数の加盟店端末等からなるシステム(【0036】【0038】)における決済装置(【0038】)であって、
前記決済装置は、CPUとプログラムを記憶するROM及びRAMを備えて、記憶されたプログラムに従って各種の処理を実行するものであり(【0044】)、ユーザと加盟店の詳細な情報を記憶する顧客データベースを有し(【0043】)、
前記決済装置が有するメニューのうち、e-Walletは、内蔵するデータベースに、前記顧客データベースに登録されている会員である前記ユーザ端末の前記ユーザの会員番号と与信レベルとともに各ユーザのプリペイド分の金額である残高を記憶し(【0038】【0042】【0109】)、与信処理で参照される前記与信レベルのテーブルに各ユーザの前記与信レベルに対応する貸し越し額が記載されており(【0120】【0121】)、各ユーザがインターネットを介して前記加盟店端末から所定の商品を購入したとき、その買い物代金をプリペイド分から減額するものであり(【0042】)、
前記決済装置は、顧客データベース中に記憶されているパスワードと会員番号に一致するパスワードと会員番号が受信されて本人(真のユーザ)であると判定されたユーザのユーザ端末から前記ユーザの購入を示す操作に応じた商品の購入通知(【0071】~【0075】【0105】)を受信すると、前記ユーザの電子マネーの残高が買い物額以上であるか否かを判定し、買い物額以上である場合には、OK電文を前記加盟店端末に送信し(【0075】)、買い物額より少ない場合には、前記与信処理を行い、与信がOKの場合にも、前記OK電文を前記加盟店端末に送信し(【0076】)、
前記加盟店端末は、商品の配送処理を実行して前記ユーザの口座から前記加盟店端末の口座への電子マネーの移動である買い物額に対応する金額の送金を受けるものであり(【0097】【0098】)、
前記与信処理を自分自身で実行する場合、前記与信レベルのテーブルからそのユーザの前記与信レベルに対応する前記貸し越し額を読み出し(【0120】)、前記貸し越し額を残高に加算する演算を行い(【0123】)、その合計値が、買い物額と等しいか、またはそれより大きいか否かを判定し(【0124】)、等しいか、またはそれより大きい場合には、決定した前記貸し越し額を前記ユーザが指定した口座から所定のタイミングで引き落とされる額である自分自身の売上として記憶し(【0124】)、残高から買い物額を減算した値を新しい残高として更新し、前記OK電文が生成されて前記加盟店端末に送信され(【0127】)、買い物額を請求データとして前記ユーザの前記顧客データベースに記憶させ(【0128】)、請求データ分の電子マネーが前記加盟店端末の口座に移動される(【0129】)、
決済装置。」

2.引用文献2について

原査定の拒絶の理由に引用された上記引用文献2には、図面とともに次の事項が記載されている。

「【0027】図2は、複数機能一体型ICカード(以下、適宜「一体型ICカード」と略称する)10の概略構成を示している。本実施形態の複数機能一体型ICカード10は、電子マネーカード機能とクレジットカード機能とを有している。複数機能一体型ICカード10は、フラッシュEEPROM等の半導体メモリからなる記憶装置12と、外部と通信してデータを送受信するための通信制御部16及びアンテナ18と、それらを統括的に制御する制御部14とを有している。【0028】複数機能一体型ICカード10が読み出し/書込み装置4上にかざされると、複数機能一体型ICカード10のアンテナ18と読み出し/書込み装置4内の不図示のアンテナとの間で電磁波データが送受信されるようになっている。【0029】一体型ICカード10内の記憶装置12には、当該カードが複数機能一体型であることを示す「一体型表示データ」と、電子マネーカードの機能とクレジットカードの機能を双方の機能を有していることを示す「機能種別表示データ」が格納されている。【0030】また、記憶装置12には、「電子マネー残高R1」が格納されている。さらに、記憶装置12には、商品購入の際、電子マネー残高が負にならないように所定の条件の下で自動入金することを承諾するか否かを示す「承諾データ」が格納されている。ここで自動入金とは、入金機から入金して電子マネー残高を増やすのではなく、商品を購入する店舗のPOSターミナル2から当座貸越に類似する態様で電子マネーを充填して一体型ICカード内の電子マネー残高を増加させることである。「承諾データ」は、例えば、「0」、「3000」、「5000」、又は「10000」のいずれかで表現され、「0」は自動入金を承諾しないことを示し、「3000」、「5000」、又は「10000」は、自動入金を承諾すると共にそれぞれの数字が入金額を表している。」

「【0040】承諾データが「0」以外(つまり、自動入金可)である場合にはステップS7に移行する。例えば、承諾データが「5000」であるとすると、ステップS7では、電子マネー残高R1と自動入金額D=5000円との合計が、販売金額Sより小さいか否かを判断する。
【0041】購入電子マネー残高R1と自動入金額Dとの合計が販売金額S以上の場合にはステップS8に移行して、POSターミナル2の制御部20は、専用線6を介して与信確認センタ8に対して与信確認要求を送出する。
【0042】購入電子マネー残高R1と自動入金額Dとの合計が販売金額Sより小さい場合にはステップS16に移行して、自動入金手続を続行するか否かを商品購入希望者に問い合わせる表示をPOSターミナル2の表示装置24から行う。手続の続行を希望しない場合は本電子マネー入金システム1の動作を終了し、手続を続行する場合にはステップS8に移行して、POSターミナル2の制御部20は専用線6を介して与信確認センタ8に対して与信確認要求を送出する。
【0043】与信確認要求において、POSターミナル2の制御部20は、クレジットカード番号と有効期限、及び承諾データを送信し、また必要に応じて利用者がキーパッドから入力したインターナショナル・セキュリティ・コードも送信する。
続きを表示(全12行)
【0044】与信確認センタ8は受信したクレジットカード番号に基づいて当該カードを発行したクレジットカード会社を選択し、当該カード会社の認証用データベースにアクセスして与信可否データを作成する。作成された与信可否データはPOSターミナル2に受信される(ステップS9)。
【0045】与信可否データを受信したPOSターミナル2の制御部20は与信限度の判断に移り(ステップS10)、与信が認められないと判断したら本処理を終了して商品取引を不成立にするか、現金その他の方法での代金支払を商品購入希望者に打診する。
【0046】与信が認められると判断したら、POSターミナル2の制御部20は、(電子マネー残高R1+自動入金額D=電子マネー残高R3)を計算して、電子マネー残高データとして電子マネー残高R3を格納する(ステップS11)。次いで、(電子マネー残高R3-販売金額S=差引残高R4)を計算する。この差引残高R4は、残高確認のためPOSターミナル2の表示装置24で表示される(ステップS12)。このとき、ステップS16からステップS8に移行していた場合には、差引残高R4が“0(ゼロ)”となるように、(電子マネー残高R3+“差額分”-販売金額S=差引残高R4=0)を計算して“差額分”を現金その他で補填する必要がある旨を表示する。
【0047】ステップS12で電子マネー残高が確認されたら、ステップS13に移行して、POSターミナル2の制御部20は、記憶装置22内のカード情報のうち電子マネー残高を差引残高R4に書き換え、利用ログの最新データを今回の商品購入データに書き換えてから、記憶装置22内のカード情報を読み出し/書込み装置4を介して一体型ICカード10に送信する(ステップS14)。一体型ICカード10の制御部14は、受信したカード情報を記憶装置12内に格納して電子マネー残高を含む各種データを更新する。
【0048】図5は、上記動作における一体型ICカード10内の記憶装置12に格納された電子マネー残高の推移を示す模式図である。ステップS11での自動入金処理より以前には電子マネー残高は「R1」であったのが(図5(a))、ステップS11乃至S14の手順の結果、差引残高「R4」になっている(図5(b))。
【0049】ステップS13における差引処理の実行により一体型ICカード10に入金された“5000円”の入金額は、電子マネーカード機能とクレジットカード機能の複数一体型ICカード10のクレジット売上として、クレジットカード番号と共にPOSターミナル2からクレジットカード会社に代金請求情報が送信される。クレジットカード会社は加盟店手数料を差引いて支払を実行し、次いで、当該クレジットカード保持者宛てに利用代金請求を行う。
【0050】なお、ステップS14において、読み出し/書込み装置4に一体型ICカード10がかざされていない場合には、POSターミナル2の表示装置24等から再度一体型ICカード10をかざすよう促すようにしてもよい。
【0051】以上説明したように本実施の形態によれば、電子マネー機能が付帯した複数機能一体型ICカードに自動入金がなされるため、電子マネーの残高が少なくなっても、わざわざ専用の入金機まで出向いて入金して電子マネーを充填する操作が不必要になる。さらに、電子マネーが充填されるため、その後も、入金機まで出向かずとも電子マネーを用いた買物を続けることができる。」

「【0095】また、上記実施の形態では、一体型ICカード10内に格納されたカード情報の1つである承認データは、「0」、「3000」、「5000」、「10000」の4種類としているが、それ以外でももちろんよく、種類の増減や自動入金額は自由に選択して採用することができる。また、商品購入時の電子マネー残高の不足額分だけが充填されるようにしてもよいし、自動入金時に自動入金額をカード使用者がその場で決定するシステムにしてももちろんよい。」

したがって、上記引用文献2には、電子マネーカードの機能を有するICカードに、商品購入の際、電子マネー残高が負にならないように所定の条件の下で自動入金することを承諾するか否か及び承諾する場合の自動入金金額を示す承諾データを格納しておき、入金機からの入金によらずに商品を購入する店舗から当座貸越に類似する態様で電子マネーを充填して電子マネー残高を増加させること、承諾データが「0」以外であり自動入金可である場合に、電子マネー残高と自動入金額との合計が販売金額より小さいか否かを判断して、その合計が販売金額以上の場合、与信確認センタに対し与信確認要求を送出し、与信が認められると判断したら、電子マネー残高と自動入金額を加算した金額を新たな電子マネー残高として格納することで、入金機まで出向かずとも電子マネーを用いた買い物を続けることができること、承認データの種類の増減や自動入金額は自由に選択して採用することができること、が記載されていると認められる。

第5 対比・判断

1.本願発明1について

(1)対比

本願発明1と引用発明とを対比すると、次のことがいえる。

ア 引用発明における「インターネット」、「ユーザ端末」は、それぞれ本願発明1における「ネットワーク」、「端末」に相当する。

引用発明における「決済装置」は、CPUとプログラムを記憶するROM及びRAMを備えて、記憶されたプログラムに従って各種の処理を実行するものであり、ユーザがインターネットを介して加盟店端末から所定の商品を購入したとき、その買い物代金をプリペイド分から減額し、商品の配送処理を実行する加盟店端末に買い物額に対応する金額の送金を行うことで、商取引を決済するものであるから、下記の相違点を除いて、本願発明1の、プロセッサとコンピュータ可読命令を記録する記録部とを有して、コンピュータ可読命令がプロセッサで実行されることで商取引の決済のための処理を実行するものである「電子決済サーバ」に相当するといえる。

イ 引用発明における「ユーザの会員番号」、「ユーザのプリペイド分の金額である残高」は、それぞれ本願発明1の「ユーザ識別情報」、「ユーザの電子マネーの残高」に相当し、引用発明の「データベース」と本願発明1の「管理データベース」とは、ユーザ識別情報とユーザの電子マネーの残高を含み、電子決済サーバにおける商取引の決済に用いられるデータベースである点で、共通している。

ウ 引用発明の、顧客データベース中に記憶されているパスワードと会員番号に一致するパスワードと会員番号が受信されて本人(真のユーザ)であると判定されたユーザのユーザ端末から受信される「ユーザの購入を示す操作に応じた商品の購入通知」は、商品購入にかかる決済金額の情報とともに、購入を行ったユーザの会員番号であるユーザ識別情報とこの決済金額の送金が行われて支払いがなされる加盟店端末を示す情報とを含むことが明らかであり、引用発明における、この「購入通知」の「受信」は、本願発明1の「前記端末からユーザ識別情報と購入額と支払先情報を取得する」ことに相当する。

エ 引用発明の「ユーザの電子マネーの残高が買い物額以上であるか否か」の「判定」のために、取得したユーザ識別情報に対応するデータベースに記憶された残高の読み出しが行われることは明らかであり、この残高の読み出しと、本願発明1の「前記端末から取得した前記ユーザ識別情報に基づ」く「ユーザの前記残高と前記設定限度額」の「取得」とは、端末から取得したユーザ識別情報に基づき、ユーザの電子マネーの残高を取得することである点で共通する。

オ 引用発明の「ユーザの与信レベルに対応する貸し越し額」と本願発明1の「設定限度額」とは、決済の際に取得されて残高との合計額の範囲での商取引の決済にあたって送金先への決済金額の送金を可能とするために残高に充当される額(以下「決済時残高充当額」という。)である点で、共通している。

よって、本願発明1と引用発明とは、「端末から取得した購入額が、ユーザの電子マネーの残高より大きく、かつ、ユーザの前記残高と決済時残高充当額の合計以下の場合に、ユーザの前記残高を、ユーザの前記残高と前記決済時残高充当額の合計から前記購入額を減じた数値に更新するとともに、前記支払先情報を用いて前記購入額を支払先へ送金する」ものである点で共通するといえる。

カ したがって、本願発明1と引用発明との間には、次の一致点、相違点があるといえる。

(一致点)

「ネットワークを介して端末と接続され、少なくともユーザ識別情報とユーザの電子マネーの残高を含むデータベースを用いて商取引を決済する電子決済サーバであって、
プロセッサと、コンピュータ可読命令を記録する記録部と、を有し、
前記コンピュータ可読命令が前記プロセッサで実行されると、前記電子決済サーバは、
前記端末からユーザ識別情報と購入額と支払先情報を取得するステップと、
前記端末から取得した前記ユーザ識別情報に基づき、ユーザの前記残高と決済時残高充当額を取得するステップと、
前記端末から取得した前記購入額が、ユーザの前記残高より大きく、かつ、ユーザの前記残高と前記決済時残高充当額の合計以下の場合に、ユーザの前記残高を、ユーザの前記残高と前記決済時残高充当額の合計から前記購入額を減じた数値に更新するとともに、前記支払先情報を用いて前記購入額を支払先へ送金するステップを実行する、
電子決済サーバ。」

(相違点)

(相違点1)本願発明1の「データベース」は、決済時残高充当額として「ユーザの設定限度額」を含み、かつ、「ユーザの与信額」も含む「管理データベース」であるのに対し、引用発明の「データベース」は、決済時残高充当額として「ユーザの設定限度額」を含まず、「ユーザの与信額」も含まない点。

(相違点2)決済時残高充当額が、本願発明1では、「前記与信額(ユーザの与信額)以下のユーザの希望する金額」である「設定限度額」が管理データベースに登録されたものであるのに対し、引用発明では、ユーザの与信レベルに対応する貸し越し額であって、ユーザの与信額以下のユーザの希望する金額でない点。

(2)相違点についての判断

ア 相違点1と相違点2とは、関連しているので、まとめて検討する。

イ 「第4 引用文献、引用発明等」の「2.引用文献2について」に記載のとおり、引用文献2には、電子マネーカードの機能を有するICカードに、商品購入の際、電子マネー残高が負にならないように所定の条件の下で自動入金することを承諾するか否か及び承諾する場合の自動入金金額を示す承諾データを格納しておき、入金機からの入金によらずに商品を購入する店舗から当座貸越に類似する態様で電子マネーを充填して電子マネー残高を増加させること、承諾データが「0」以外であり自動入金可である場合に、電子マネー残高と自動入金額との合計が販売金額より小さいか否かを判断して、その合計が販売金額以上の場合、与信確認センタに対し与信確認要求を送出し、与信が認められると判断したら、電子マネー残高と自動入金額を加算した金額を新たな電子マネー残高として格納することで、入金機まで出向かずとも電子マネーを用いた買い物を続けることができること、承認データの種類の増減や自動入金額は自由に選択して採用することができること、が記載されている。

しかしながら、相違点1と相違点2に係る本願発明1の構成は、要するに、ユーザの与信額以下のユーザの希望する金額を決済時残高充当額となる「設定限度額」として「ユーザの与信額」と関連づけて電子決済サーバによって参照されるデータベースに登録しておき、電子決済サーバが決済の際にこれを取得して残高との合計額の範囲での商取引の決済及び送金先への決済金額の送金を可能とすることで、決済時には与信のための処理を行わないものであって、決済時に与信のための処理を行うことを前提とする引用文献2に記載された技術とは異なる。

ウ 以上のとおり、本願発明1は、当業者であっても、引用発明及び引用文献2に記載された技術的事項に基づいて容易に発明をすることができたものとはいえない。

エ なお、原審が拒絶理由通知とともに示した先行技術文献のうち、特開2007-213399号公報(以下「参考文献」という。)には、決済に先だって与信がなされた少額について決済時には与信を行わずに残高に充当する緊急チャージを可能とすることを示す記載がある。(段落【0034】~【0036】、【0043】、【0052】~【0059】(摘記省略))

この参考文献の記載は、残高等をサーバ側でなく端末側で管理し、緊急チャージのためのサーバへのアクセスがないことを前提としたものであり、これに対して、本願発明1及び引用発明は、残高等をサーバ側で管理するものであって、決済時の残高の充当にあたってサーバへのアクセスが必要となるものである。

よって、参考文献は、本願発明1及び引用発明とは前提が異なる文献であって、参考文献の記載を考慮しても、本願発明1が容易想到であるとはいえない。

2.本願発明2、3について

本願発明2、3も、本願発明1の相違点1及び相違点2に係る構成と同一の構成を備えるものであるから、本願発明1と同じ理由により、当業者であっても、引用発明及び引用文献2に記載された技術的事項に基づいて容易に発明をすることができたものとはいえない。

3.本願発明4-6について

本願発明4-6は、それぞれ本願発明1に対応する方法、プログラム、記録媒体の発明であり、本願発明1の相違点1及び相違点2に係る構成と対応する構成を備えるものであるから、本願発明1と同様の理由により、当業者であっても、引用発明及び引用文献2に記載された技術的事項に基づいて容易に発明をすることができたものとはいえない。

第6 原査定について

原査定では、本願発明1-6が引用発明及び引用文献2に記載された技術的事項に基づいて当業者が容易に発明をすることができたとするにあたって、請求項1の「前記電子決済サーバは、前記端末から、前記与信額以下のユーザの希望する金額を取得し、該金額を前記設定限度額として前記管理データベースに登録する」との記載では、本願発明1の電子決済サーバがユーザの希望する金額として、与信額より大きな額を取得した場合に、設定限度額として登録できるのかできないのか、限定されていない旨、説示している。

しかし、本願発明1は、「ユーザの希望する金額」を取得した電子決済サーバが管理データベースを参照して「前記与信額以下」であると判断して決済時残高充当額となる設定限度額として登録するのであって、与信額より大きな額を設定限度額として登録するものでない。このことは、請求項1が上記の記載に加えて「前記管理データベースは、ユーザの与信額を含み、」とも記載していることから明らかであるし、明細書の段落【0022】【0034】【0037】【0038】の記載や審判請求書における主張も、このことと整合するものとなっている。

よって、原査定の上記説示には誤りがあり、第5に示したとおり、本願発明1-6は、引用発明及び引用文献2に記載された技術的事項に基づいて当業者が容易に発明をすることができたものとはいえない。

第7 むすび

以上のとおり、本願発明1-6は、当業者が引用発明及び引用文献2に記載された技術的事項に基づいて容易に発明をすることができたものではない。したがって、原査定の理由によっては、本願を拒絶することはできない。

また、他に本願を拒絶すべき理由を発見しない。

よって、結論のとおり審決する。

審決本文(J-PlatPat)

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

J-PlatPat 審決検索を開く
2020-007851

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

同じ当事者の審決1件(株式会社 みずほ銀行)
  • 2020-011971拒絶査定不服審判 / 2021-07-26 / 原査定取消(特許/登録すべき)決済システム及び決済方法
    同じ当事者: 株式会社 みずほ銀行
同じ論点・分野の審決(審決分類)2,129件(121・G06Q)
  • 2025-007249拒絶査定不服審判 / 2026-08-27 / 原査定取消(特許/登録すべき)顧客管理装置、顧客管理方法、及びプログラム
    共通の審決分類: 121・G06Q
  • 2026-004837拒絶査定不服審判 / 2026-08-27 / 原査定取消(特許/登録すべき)情報処理システム、情報処理方法及びプログラム
    共通の審決分類: 121・G06Q
  • 2025-013567拒絶査定不服審判 / 2026-08-25 / 原査定取消(特許/登録すべき)情報処理装置、方法、プログラム、およびシステム
    共通の審決分類: 121・G06Q
  • 2025-011274拒絶査定不服審判 / 2026-08-24 / 原査定取消(特許/登録すべき)案内ロボット制御装置、案内ロボット制御方法、及びコンピュータプログラム
    共通の審決分類: 121・G06Q
  • 2024-007053拒絶査定不服審判 / 2026-08-24 / 原査定取消(特許/登録すべき)機器性能値予測方法、システム、およびプログラム
    共通の審決分類: 121・G06Q

メモ・タグ(非公開)

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

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