JP2006330990A - 利用代金徴収システムとそれを実現するためのコンピュータプログラムとその方法 - Google Patents
利用代金徴収システムとそれを実現するためのコンピュータプログラムとその方法 Download PDFInfo
- Publication number
- JP2006330990A JP2006330990A JP2005152334A JP2005152334A JP2006330990A JP 2006330990 A JP2006330990 A JP 2006330990A JP 2005152334 A JP2005152334 A JP 2005152334A JP 2005152334 A JP2005152334 A JP 2005152334A JP 2006330990 A JP2006330990 A JP 2006330990A
- Authority
- JP
- Japan
- Prior art keywords
- price
- customer
- usage fee
- collection device
- withdrawal
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 99
- 238000004590 computer program Methods 0.000 title claims description 12
- 238000012545 processing Methods 0.000 claims abstract description 26
- 238000012797 qualification Methods 0.000 claims description 14
- 238000012546 transfer Methods 0.000 description 17
- 230000002159 abnormal effect Effects 0.000 description 12
- FFBHFFJDDLITSX-UHFFFAOYSA-N benzyl N-[2-hydroxy-4-(3-oxomorpholin-4-yl)phenyl]carbamate Chemical compound OC1=C(NC(=O)OCC2=CC=CC=C2)C=CC(=C1)N1CCOCC1=O FFBHFFJDDLITSX-UHFFFAOYSA-N 0.000 description 2
- 230000005540 biological transmission Effects 0.000 description 2
- 238000013475 authorization Methods 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 238000000151 deposition Methods 0.000 description 1
- 238000010586 diagram Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 239000000284 extract Substances 0.000 description 1
- 230000008685 targeting Effects 0.000 description 1
Images
Landscapes
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
【目的】 一定の収入のない若年層でもクレジットカードを利用でき、且つクレジットカード会社が確実に決済金額を徴収できるシステム等を提供することを目的とする。
【解決手段】 クレジットカードの利用代金を徴収する代金徴収装置(サーバー1)を含むコンピュータシステムである。このサーバー1は、以下の処理を行う。
(1)顧客の預金口座の預金残高を特定すると共に顧客からの提供された担保金を管理する。
(2)顧客が購入した商品の代金を受信して前記預金残高と前記代金に基づいて前記預金口座から前記代金を引落とすことが可能か否かの判断処理を行う。
(3)前記判断処理において引落とし可能と判断された場合は前記預金口座から前記代金を引落とすための処理を行う。
(4)前記判断処理において引落とし不能と判断された場合は前記担保金から前記代金を引き落とすための処理を行う。
【選択図】 図2
【解決手段】 クレジットカードの利用代金を徴収する代金徴収装置(サーバー1)を含むコンピュータシステムである。このサーバー1は、以下の処理を行う。
(1)顧客の預金口座の預金残高を特定すると共に顧客からの提供された担保金を管理する。
(2)顧客が購入した商品の代金を受信して前記預金残高と前記代金に基づいて前記預金口座から前記代金を引落とすことが可能か否かの判断処理を行う。
(3)前記判断処理において引落とし可能と判断された場合は前記預金口座から前記代金を引落とすための処理を行う。
(4)前記判断処理において引落とし不能と判断された場合は前記担保金から前記代金を引き落とすための処理を行う。
【選択図】 図2
Description
本発明は、あらかじめ受領した金額を担保金とし、その範囲内でクレジットカードの利用を認めるクレジットカードシステムに関する。
現在、クレジットカードを所有し、それにより商品を購入する人が急増している。クレジットカード会社が顧客に対しクレジットカードを発行する際は、その顧客に一定の収入があり決済金額を確実に徴収できるか否か等を審査する。そして、その審査に合格した顧客に対してのみクレジットカードが発行される。
よって、定職を持たない人や未成年者は原則としてクレジットカードを所有できないのが現状である。即ち、若年層の多くはクレジットカードを所有できないのが現状である。
なお、本発明においては先行技術文献(特許文献)を特に示さない。クレジットカードの基本的な仕組みは周知であり、特に示す必要がないと考えられるからである。
よって、定職を持たない人や未成年者は原則としてクレジットカードを所有できないのが現状である。即ち、若年層の多くはクレジットカードを所有できないのが現状である。
なお、本発明においては先行技術文献(特許文献)を特に示さない。クレジットカードの基本的な仕組みは周知であり、特に示す必要がないと考えられるからである。
しかし、このような現状は若年層向けの商品やサービスを提供している業者にとっては大きなビジネスチャンスの喪失である。即ち、最近ではインターネットを利用した商品売買が盛んであるが、この取引はクレジットカード決済が主流であるため、クレジットカードを持たない若年層の多くはこの取引を利用できないことがある。よって、若年層をターゲットにした商品を販売する業者にとっては大きなビジネスチャンスの喪失につながるのである。
そこで本発明は、一定の収入のない若年層でもクレジットカードを利用でき、且つクレジットカード会社が確実に決済金額を徴収できるシステム等を提供するものである。
そこで本発明は、一定の収入のない若年層でもクレジットカードを利用でき、且つクレジットカード会社が確実に決済金額を徴収できるシステム等を提供するものである。
本発明は、例えば、次の構成による次の手段を備えるシステム、コンピュータが次のようなステップ(処理)を行う方法、コンピュータを次のように機能させるコンピュータプログラムである。
(1) クレジットカードの利用代金を徴収する代金徴収装置を含むコンピュータシステムであって、
前記代金徴収装置は、顧客の預金口座の預金残高を特定する預金残高特定手段、
顧客から提供された担保金を管理する担保金管理手段、顧客が購入した商品の代金を受信する代金受信手段、前記預金残高と前記代金に基づいて前記預金口座から前記代金を引落とすことが可能か否かの第1判断処理を行う第1判断手段、前記第1判断処理において引落とし可能と判断された場合は前記預金口座から前記代金を引落とすための処理を行う第1引落手段、前記第1判断処理において引落とし不能と判断された場合は前記担保金から前記代金を引き落とすための処理を行う第2引落手段を備える。
(2) 前記代金徴収装置は、顧客の連絡先を記憶する連絡先記憶手段、前記第1判断処理を行う前に前記第1判断処理と同様の処理である第2判断処理を行う第2判断手段、前記第2判断処理において引落とし不能と判断された場合は前記警告メッセージを前記連絡先に送信する警告手段を備える。
(3) 前記代金徴収装置は、前記預金口座から前記代金が正常に引落されたか否かを判断し正常に引落としされた場合は正常引落回数又は正常引落率を集計する正常回数集計手段、顧客を優良会員とみなすための条件を記憶する条件記憶手段、前記正常引落回数又は前記正常引落率と前記条件とを比較し前記正常引落回数が前記条件に合致している場合はその顧客に対し特典を付与する特典付与手段を備える。
(4) 前記代金徴収装置は、会員の地位を記憶する地位記憶手段を備え、
前記特典とは前記会員の地位を上位の地位に更新する処理である。
(5) 前記代金徴収装置は、クレジットカードサービスを享受する資格の有無を管理する資格管理手段を備え、
前記特典とは、正規のクレジットカードサービスを享受する資格を無から有に更新する処理である。
(6) 前記代金徴収装置は、会員の獲得ポイントを管理するポイント管理手段を備え、
前記特典とは会員の前記ポイントを増加させる処理である。
(1) クレジットカードの利用代金を徴収する代金徴収装置を含むコンピュータシステムであって、
前記代金徴収装置は、顧客の預金口座の預金残高を特定する預金残高特定手段、
顧客から提供された担保金を管理する担保金管理手段、顧客が購入した商品の代金を受信する代金受信手段、前記預金残高と前記代金に基づいて前記預金口座から前記代金を引落とすことが可能か否かの第1判断処理を行う第1判断手段、前記第1判断処理において引落とし可能と判断された場合は前記預金口座から前記代金を引落とすための処理を行う第1引落手段、前記第1判断処理において引落とし不能と判断された場合は前記担保金から前記代金を引き落とすための処理を行う第2引落手段を備える。
(2) 前記代金徴収装置は、顧客の連絡先を記憶する連絡先記憶手段、前記第1判断処理を行う前に前記第1判断処理と同様の処理である第2判断処理を行う第2判断手段、前記第2判断処理において引落とし不能と判断された場合は前記警告メッセージを前記連絡先に送信する警告手段を備える。
(3) 前記代金徴収装置は、前記預金口座から前記代金が正常に引落されたか否かを判断し正常に引落としされた場合は正常引落回数又は正常引落率を集計する正常回数集計手段、顧客を優良会員とみなすための条件を記憶する条件記憶手段、前記正常引落回数又は前記正常引落率と前記条件とを比較し前記正常引落回数が前記条件に合致している場合はその顧客に対し特典を付与する特典付与手段を備える。
(4) 前記代金徴収装置は、会員の地位を記憶する地位記憶手段を備え、
前記特典とは前記会員の地位を上位の地位に更新する処理である。
(5) 前記代金徴収装置は、クレジットカードサービスを享受する資格の有無を管理する資格管理手段を備え、
前記特典とは、正規のクレジットカードサービスを享受する資格を無から有に更新する処理である。
(6) 前記代金徴収装置は、会員の獲得ポイントを管理するポイント管理手段を備え、
前記特典とは会員の前記ポイントを増加させる処理である。
本発明には次のような効果がある。
(1)本発明を利用すれば、一定の収入がない人(特に、若年層)であってもクレジットカードを所有し、利用することができる。また、本発明では、予め担保金を徴収するのでクレジットカード会社では確実に決済金額を徴収することができる。そして、これによりカード破産の防止をすることができる。
(2)本発明を利用すれば、決済金額を確実に徴収できるので個人の年収などを調査する必要がなくなる。これにより個人情報を保護することができるのである。
(3)本発明では、非正常振処理になりそうな場合に警告メッセージを送信するので、正常振替になる確率をより高めることができる。
(4)本発明は、優良会員には正規のクレジットカード会員資格を認めるのでクレジットカード会社の潜在的な顧客の発掘をすることができる。更にこの他にも、優良会員には様々な特典を与えるので、顧客に満足を与えることができる。また、これにより利用者は決済金を確実に引き落とせるよう努力するのでクレジットカード会社ではより確実に決済金を徴収できる。
(1)本発明を利用すれば、一定の収入がない人(特に、若年層)であってもクレジットカードを所有し、利用することができる。また、本発明では、予め担保金を徴収するのでクレジットカード会社では確実に決済金額を徴収することができる。そして、これによりカード破産の防止をすることができる。
(2)本発明を利用すれば、決済金額を確実に徴収できるので個人の年収などを調査する必要がなくなる。これにより個人情報を保護することができるのである。
(3)本発明では、非正常振処理になりそうな場合に警告メッセージを送信するので、正常振替になる確率をより高めることができる。
(4)本発明は、優良会員には正規のクレジットカード会員資格を認めるのでクレジットカード会社の潜在的な顧客の発掘をすることができる。更にこの他にも、優良会員には様々な特典を与えるので、顧客に満足を与えることができる。また、これにより利用者は決済金を確実に引き落とせるよう努力するのでクレジットカード会社ではより確実に決済金を徴収できる。
本発明は、あらかじめ受領した金額を担保金とし、その範囲内でクレジットカードの利用を認めるクレジットカードシステム等を提供するものである。以下、図面に基づいて説明する。
本発明の第一実施例を図に基づいて説明する。図1は本発明の実施に必要なハードウェアとそのハードウェアの結びつきを表した概略図である。
これらハードウェアは、クレジットカード会社のA社が利用するサーバー1(代金徴収装置)、銀行Bが利用するサーバー2、チケット販売業者のC社が利用するサーバー3とからなる。
各装置(サーバー1、サーバー2、サーバー3)にはデータの送受信を可能にするためのデータ送信部および受信部が備えられており、これにより各装置同士はインターネット10(或いは、その他の通信手段)を介してデータの送受信が可能になっている。
これらハードウェアは、クレジットカード会社のA社が利用するサーバー1(代金徴収装置)、銀行Bが利用するサーバー2、チケット販売業者のC社が利用するサーバー3とからなる。
各装置(サーバー1、サーバー2、サーバー3)にはデータの送受信を可能にするためのデータ送信部および受信部が備えられており、これにより各装置同士はインターネット10(或いは、その他の通信手段)を介してデータの送受信が可能になっている。
各装置には情報を処理する処理装置、情報を記憶する記憶装置が備えられている。
各装置の記憶装置には本発明を実現するためのコンピュータプログラムや所定のデータが記憶されており、各装置の処理装置はこのコンピュータプログラムの処理命令に従って所定の処理を行う。
各装置の記憶装置には本発明を実現するためのコンピュータプログラムや所定のデータが記憶されており、各装置の処理装置はこのコンピュータプログラムの処理命令に従って所定の処理を行う。
次に、サーバー1の記憶装置に予め記憶されている情報について説明する。
(1)サーバー1には図3(a)に示すような顧客ファイルが記憶されている(連絡先記憶手段、地位記憶手段)。これはクレジットカード会社のA社が顧客情報を管理するためのファイルであり、顧客のクレジットカード番号・氏名・住所・電話番号・メールアドレス(連絡先)・会員ランク(会員の地位)等、図3(a)に示されているデータ項目が各々関連づけられているものである。なお、この顧客ファイル(a)は処理が進むにつれ図3(b)に示すような内容に更新されるのであるが、この点については後述する。
(2)サーバー1には図4(a)に示すような担保金管理ファイルが記憶されている(担保金管理手段)。これはクレジットカード会社のA社が顧客から予め振り込まれた担保金を管理するためのファイルであり、顧客のクレジットカード番号・氏名・担保金・担保金残高・利用額等、図4(a)に示されているデータ項目が各々関連づけられているものである。なお、担保金とは顧客から予めA社の口座(担保金を預かる口座)「YY銀行Y支店YYY−YYYY」に振り込まれた金額を意味するものである。また、この担保金管理ファイル(a)は処理が進むにつれ図4(b)、図5(c)、図5(d)、図6(e)、に示すような内容に更新されるのであるが、この点については後述する。
(1)サーバー1には図3(a)に示すような顧客ファイルが記憶されている(連絡先記憶手段、地位記憶手段)。これはクレジットカード会社のA社が顧客情報を管理するためのファイルであり、顧客のクレジットカード番号・氏名・住所・電話番号・メールアドレス(連絡先)・会員ランク(会員の地位)等、図3(a)に示されているデータ項目が各々関連づけられているものである。なお、この顧客ファイル(a)は処理が進むにつれ図3(b)に示すような内容に更新されるのであるが、この点については後述する。
(2)サーバー1には図4(a)に示すような担保金管理ファイルが記憶されている(担保金管理手段)。これはクレジットカード会社のA社が顧客から予め振り込まれた担保金を管理するためのファイルであり、顧客のクレジットカード番号・氏名・担保金・担保金残高・利用額等、図4(a)に示されているデータ項目が各々関連づけられているものである。なお、担保金とは顧客から予めA社の口座(担保金を預かる口座)「YY銀行Y支店YYY−YYYY」に振り込まれた金額を意味するものである。また、この担保金管理ファイル(a)は処理が進むにつれ図4(b)、図5(c)、図5(d)、図6(e)、に示すような内容に更新されるのであるが、この点については後述する。
次に、本発明を実現するための処理手順について説明する。本発明は図2に示すとおりのフローに従って処理される。以下、これら処理について説明する。
<S1:カード利用及び利用データ受信>
A社の会員である山田さんはチケット販売窓口(或いは、チケット販売サイト)でAチケット3000円分を購入した。これによりサーバー3からサーバー1に対し、図7に示すような利用データ1が送信され、これを受信したサーバー1はこれを記憶装置に記憶する(代金受信手段)。なお、ここでは利用データ1の合計額が商品の代金となる。
A社の会員である山田さんはチケット販売窓口(或いは、チケット販売サイト)でAチケット3000円分を購入した。これによりサーバー3からサーバー1に対し、図7に示すような利用データ1が送信され、これを受信したサーバー1はこれを記憶装置に記憶する(代金受信手段)。なお、ここでは利用データ1の合計額が商品の代金となる。
<S2:担保金残高の範囲内か確認>
次に、サーバー1は利用金額が担保金残高の範囲内かを確認する。即ち、本発明は担保金の範囲内でクレジットカードの利用を認めるものなので、利用額が担保金残高の範囲内であるかを確認するのである。
サーバー1は利用データ1(図7)のクレジットカード番号を検索キーにして担保金管理ファイル(図4a)を検索し、山田さんのレコードを抽出する。そして、抽出したレコードの担保金残高「30000円」と利用データ1の合計額「3000円」とを比較し、担保金残高の範囲内であれば処理S211へ進み、担保金残高を超えていれば処理S221へ進む。
次に、サーバー1は利用金額が担保金残高の範囲内かを確認する。即ち、本発明は担保金の範囲内でクレジットカードの利用を認めるものなので、利用額が担保金残高の範囲内であるかを確認するのである。
サーバー1は利用データ1(図7)のクレジットカード番号を検索キーにして担保金管理ファイル(図4a)を検索し、山田さんのレコードを抽出する。そして、抽出したレコードの担保金残高「30000円」と利用データ1の合計額「3000円」とを比較し、担保金残高の範囲内であれば処理S211へ進み、担保金残高を超えていれば処理S221へ進む。
<S211:担保金管理ファイル更新>
S2において利用金額が担保金残高の範囲内である場合、サーバー1は山田さんの担保金レコードの更新を行う(図4a→図4b)。
サーバー1は、利用データ1(図7)の合計額を担保金レコードの利用額1「3000円」に代入し、担保金残高「30000円」から利用額1を差し引く。更に、利用回数に「1」を加算する。これにより山田さんの担保金レコードは図4bのように更新される。
S2において利用金額が担保金残高の範囲内である場合、サーバー1は山田さんの担保金レコードの更新を行う(図4a→図4b)。
サーバー1は、利用データ1(図7)の合計額を担保金レコードの利用額1「3000円」に代入し、担保金残高「30000円」から利用額1を差し引く。更に、利用回数に「1」を加算する。これにより山田さんの担保金レコードは図4bのように更新される。
<S221:担保金残高不足処理>
一方、S2において利用金額が担保金残高の範囲を超えている場合、サーバー1はサーバー3に対し「利用額が担保金の限度を超えています。」等のエラーメッセージを送信して、クレジットカードが利用できない旨を知らせる。
一方、S2において利用金額が担保金残高の範囲を超えている場合、サーバー1はサーバー3に対し「利用額が担保金の限度を超えています。」等のエラーメッセージを送信して、クレジットカードが利用できない旨を知らせる。
サーバー1は、月末の決済日になるまでこのS1、S2、S211、S221を繰り返す。例えば、図8のような利用データ2を受信した場合は、S2において担保金残高「27000円」(図4b)と利用額(合計額)「4000円」とを比較し、担保金残高の範囲内であればS211において担保金管理レコードを図4bから図5cに更新する。
<S3:決済日か確認>
サーバー1は、サーバー1に備えられている時計から現在の日時を取得して、その日が決済日であるか否かを確認し、決済日であればS311に進み、決済日でなければS1に戻る。なお、決済日は毎月月末日(本実施例では、7月31日)とし、これはサーバー1の記憶装置に記憶されてるものとする。また、決済日の時点で山田さんの担保金レコードの内容は図5cのようになっているものとする。
サーバー1は、サーバー1に備えられている時計から現在の日時を取得して、その日が決済日であるか否かを確認し、決済日であればS311に進み、決済日でなければS1に戻る。なお、決済日は毎月月末日(本実施例では、7月31日)とし、これはサーバー1の記憶装置に記憶されてるものとする。また、決済日の時点で山田さんの担保金レコードの内容は図5cのようになっているものとする。
<S311:預金残高の報告要求>
サーバー1は、各会員についての預金残高報告を銀行に対して行う。例えば、山田さんの預金残高を要求するためサーバー1は図9のような残高報告要求データを銀行のサーバー2に送信する。
サーバー1は、各会員についての預金残高報告を銀行に対して行う。例えば、山田さんの預金残高を要求するためサーバー1は図9のような残高報告要求データを銀行のサーバー2に送信する。
<S312:預金残高報告>
残高報告要求データを受信したサーバー2は図10aのような残高報告データを作成しこれをサーバー1に送信する。サーバー1はこれを受信することにより預金残高を確認・特定する(預金残高特定手段)。なお、ここでは山田さんの預金残高は50000円とする。
残高報告要求データを受信したサーバー2は図10aのような残高報告データを作成しこれをサーバー1に送信する。サーバー1はこれを受信することにより預金残高を確認・特定する(預金残高特定手段)。なお、ここでは山田さんの預金残高は50000円とする。
<S4:正常引落可能か判断(預金残高と利用合計額との比較)>
サーバー1は、図10aの預金残高「50000円」と図5cの利用合計額「7000円」とを比較し、預金口座から利用合計額を引き落とせるか否かを確認する(第1判断処理及び第1判断手段)。即ち、利用合計額が預金残高以内であれば預金口座から引落可能なので処理S411に進む。一方、利用合計額が預金残高を超えるのであれば預金口座から引落不可能なので処理S421に進む。
サーバー1は、図10aの預金残高「50000円」と図5cの利用合計額「7000円」とを比較し、預金口座から利用合計額を引き落とせるか否かを確認する(第1判断処理及び第1判断手段)。即ち、利用合計額が預金残高以内であれば預金口座から引落可能なので処理S411に進む。一方、利用合計額が預金残高を超えるのであれば預金口座から引落不可能なので処理S421に進む。
<S411:正常振替処理>
サーバー1は、顧客レコード(図3a)と担保金管理ファイル(図5c)に基づいて正常振替データ(図11a)を作成し、これを銀行が利用するサーバー3に送信する(第1引落手段)。なお、正常振替データの振替元口座は図3aの顧客レコードの通常引落口座である。山田さんの銀行口座には利用合計額「7000円」を超える「50000円」があるのでここから利用合計額を引き落とすのである。また、振替データとは所定の口座から所定の金額を引き落とすことを依頼するためのデータであるものとする。
これによりサーバー3は山田さんの預金口座から利用合計額を引き落とす処理を行う。
サーバー1は、顧客レコード(図3a)と担保金管理ファイル(図5c)に基づいて正常振替データ(図11a)を作成し、これを銀行が利用するサーバー3に送信する(第1引落手段)。なお、正常振替データの振替元口座は図3aの顧客レコードの通常引落口座である。山田さんの銀行口座には利用合計額「7000円」を超える「50000円」があるのでここから利用合計額を引き落とすのである。また、振替データとは所定の口座から所定の金額を引き落とすことを依頼するためのデータであるものとする。
これによりサーバー3は山田さんの預金口座から利用合計額を引き落とす処理を行う。
<S412:正常引落回数カウント処理>
今回、山田さんはクレジットカードを使用し、正常に引き落とすことができたのでこれを山田さんの正常引落回数としてカウントする(正常回数集計手段)。即ち、サーバー1は、山田さんの顧客レコード(図3a)の正常引落回数「9」に「1」を加算しこれを「10」とする(図3b)。
今回、山田さんはクレジットカードを使用し、正常に引き落とすことができたのでこれを山田さんの正常引落回数としてカウントする(正常回数集計手段)。即ち、サーバー1は、山田さんの顧客レコード(図3a)の正常引落回数「9」に「1」を加算しこれを「10」とする(図3b)。
<S413:担保金管理レコード更新処理>
サーバー1は、図5cのような内容になっている山田さんの担保金管理レコードを図5dのように更新する。即ち、利用合計額を山田さんの預金口座から引き落とすことができたので担保金及び担保金残高を元の「30000円」に戻し、利用額や利用額合計を「0円」の戻す。なお、管理対象月も8月に更新する。
サーバー1は、図5cのような内容になっている山田さんの担保金管理レコードを図5dのように更新する。即ち、利用合計額を山田さんの預金口座から引き落とすことができたので担保金及び担保金残高を元の「30000円」に戻し、利用額や利用額合計を「0円」の戻す。なお、管理対象月も8月に更新する。
<S421:非正常振替処理>
ここまでの例では、サーバー1は図10aのような残高報告データ(預金残高:50000円)を受信することを前提にしているが、図10bのような残高報告データ(預金残高:0円)を受信した場合、サーバー1はこの非正常振替処理を行う。
サーバー1は、顧客レコード(図3a)と担保金管理ファイル(図5c)に基づいて非正常振替データ(図11b)を作成し、これを銀行が利用するサーバー3に送信する(第2引落手段)。なお、非正常振替データの振替元口座は図3aの顧客レコードの担保金口座である。山田さんの銀行口座には利用合計額「7000円」に満たない「0円」しかないので、通常の預金口座からは利用合計額を引き落とすことができない。よって、A社が山田さんの担保金を管理している担保金口座から引き落とすのである。なお、本実施例ではこの担保金口座はこの非正常振替処理においてのみ利用されるものであり、他の決済処理では一切利用されないものとする。
これによりサーバー3は担保金口座から利用合計額を引き落とす処理を行う。
このように本発明では預金口座残高が不足している場合でも担保金口座から引き落とすことができるので、確実に利用金額を引き落とすことができる。
ここまでの例では、サーバー1は図10aのような残高報告データ(預金残高:50000円)を受信することを前提にしているが、図10bのような残高報告データ(預金残高:0円)を受信した場合、サーバー1はこの非正常振替処理を行う。
サーバー1は、顧客レコード(図3a)と担保金管理ファイル(図5c)に基づいて非正常振替データ(図11b)を作成し、これを銀行が利用するサーバー3に送信する(第2引落手段)。なお、非正常振替データの振替元口座は図3aの顧客レコードの担保金口座である。山田さんの銀行口座には利用合計額「7000円」に満たない「0円」しかないので、通常の預金口座からは利用合計額を引き落とすことができない。よって、A社が山田さんの担保金を管理している担保金口座から引き落とすのである。なお、本実施例ではこの担保金口座はこの非正常振替処理においてのみ利用されるものであり、他の決済処理では一切利用されないものとする。
これによりサーバー3は担保金口座から利用合計額を引き落とす処理を行う。
このように本発明では預金口座残高が不足している場合でも担保金口座から引き落とすことができるので、確実に利用金額を引き落とすことができる。
<S422:非正常引落回数カウント処理>
今回、山田さんはクレジットカードを利用し、正常に引き落とすことができなかったので(担保金から引き落としたので)これを山田さんの非正常引落回数としてカウントする。即ち、サーバー1は、山田さんの顧客レコード(図3a)の非正常引落回数「0」に「1」を加算しこれを「1」とする(図示せず)。
今回、山田さんはクレジットカードを利用し、正常に引き落とすことができなかったので(担保金から引き落としたので)これを山田さんの非正常引落回数としてカウントする。即ち、サーバー1は、山田さんの顧客レコード(図3a)の非正常引落回数「0」に「1」を加算しこれを「1」とする(図示せず)。
<S423:担保金管理レコード更新処理>
サーバー1は、図5cのような内容になっている山田さんの担保金管理レコードを図6eのように更新する。即ち、利用合計額を山田さんの預金口座から引き落とすことができなかった(利用額7000円を担保金から引き落としたので)ので担保金及び担保金残高を「23000円」に更新し、利用額や利用額合計を「0円」の戻す。なお、管理対象月も8月に更新する。
サーバー1は、図5cのような内容になっている山田さんの担保金管理レコードを図6eのように更新する。即ち、利用合計額を山田さんの預金口座から引き落とすことができなかった(利用額7000円を担保金から引き落としたので)ので担保金及び担保金残高を「23000円」に更新し、利用額や利用額合計を「0円」の戻す。なお、管理対象月も8月に更新する。
<S5:優良会員認定処理>
次に、サーバー1は山田さんを優良会員とみなすか否かの認定処理を行う。
サーバー1の記憶装置には優良会員と認定するための条件データが記憶されている(図12a:条件記憶手段)。なお、ここでは図12aの正常引落回数及び非正常引落回数が優良会員とみなすための条件となる。サーバー1は、山田さんの顧客レコード(図3a)の正常引落回数・非正常引落回数と条件データの正常引落回数・非正常引落回数とを比較し、山田さんが条件に合致しているか否かを判断する。
そして、条件に合致していれば以下の(処理1)(処理2)(処理3)何れかの処理を行う。
(処理1)サーバー1は、条件データ(12a)の加算ポイント「20」を特典として山田さんの顧客レコードのポイントに加算して増加させる(特典付与手段)。
(処理2)条件データの内容が図12bであれば、特典として会員ランクを「A」(上位の地位)に更新する(特典付与手段)。なお、会員ランク「B」よりも「A」の方がより有利な条件でクレジットカードを利用できるものとする。
(処理3)条件データの内容が図12cであれば、特典として正会員資格を「有」に更新する(特典付与手段)。なお、正会員資格とは担保金を振り込むことなくクレジットカードを利用する資格を意味する。クレジットカード会社はこの情報を基に山田さんに正規のクレジットカード(担保金不要のクレジットカード)を発行するようにしてもよい。
これら処理により山田さんの顧客レコードは図3bのような内容に更新されるのである。
なお、本実施例では正常引落回数・非正常引落回数を優良会員とみなすための要素としているが、これを正常引落率としてもよい。
次に、サーバー1は山田さんを優良会員とみなすか否かの認定処理を行う。
サーバー1の記憶装置には優良会員と認定するための条件データが記憶されている(図12a:条件記憶手段)。なお、ここでは図12aの正常引落回数及び非正常引落回数が優良会員とみなすための条件となる。サーバー1は、山田さんの顧客レコード(図3a)の正常引落回数・非正常引落回数と条件データの正常引落回数・非正常引落回数とを比較し、山田さんが条件に合致しているか否かを判断する。
そして、条件に合致していれば以下の(処理1)(処理2)(処理3)何れかの処理を行う。
(処理1)サーバー1は、条件データ(12a)の加算ポイント「20」を特典として山田さんの顧客レコードのポイントに加算して増加させる(特典付与手段)。
(処理2)条件データの内容が図12bであれば、特典として会員ランクを「A」(上位の地位)に更新する(特典付与手段)。なお、会員ランク「B」よりも「A」の方がより有利な条件でクレジットカードを利用できるものとする。
(処理3)条件データの内容が図12cであれば、特典として正会員資格を「有」に更新する(特典付与手段)。なお、正会員資格とは担保金を振り込むことなくクレジットカードを利用する資格を意味する。クレジットカード会社はこの情報を基に山田さんに正規のクレジットカード(担保金不要のクレジットカード)を発行するようにしてもよい。
これら処理により山田さんの顧客レコードは図3bのような内容に更新されるのである。
なお、本実施例では正常引落回数・非正常引落回数を優良会員とみなすための要素としているが、これを正常引落率としてもよい。
なお、非正常振処理になりそうな場合に警告メッセージを送信して正常振替になる確率を高めてもよい。そのための処理フローは図13の通りである。以下、これら処理について説明する。
(1)サーバー1は<S6:決済日の3日前か>においてその日が決済日の3日前であるか否かを判断する。なお、これは決済日の3日前に限るものではなく、何日前であってもよい。また、3日前に確認することはサーバー1の記憶装置に記憶されているものとする。
(2)その後<S311a:預金残高要求>→<S312a:預金残高要求>→<S4a:正常引落が可能かの判断処理(第2判断処理及び第2判断手段)>を行う。そして、正常引落が不可能と判断された場合にはまず山田さんの電子メールアドレス(連絡先)あてに「預金残高不足です。このままだと担保金から引き落とすことになります。」などの警告メッセージを送信する(警告手段)。なお、山田さんの電子メールアドレスは図3の顧客ファイルから検索したものであり、警告メッセージは予めサーバー1の記憶装置に記憶されていたものとする。また、<S311a:預金残高要求>、<S312a:預金残高要求>、<S4a:正常引落が可能かの判断処理>は前述の<S311:預金残高要求>、<S312:預金残高要求>、<S4:正常引落が可能かの判断処理>と同様の処理である。
(3)次に、サーバー1は<S4:決済日か確認>を行い、決済日当日に改めて<S311:預金残高要求>→<S312:預金残高要求>→<S4:正常引落が可能かの判断処理>及びそれ以降の処理を行う。これにより山田さんが3日以内に預金口座に利用額以上の金額を入金すれば正常振替処理を行うことができる。一方、3日以内に入金がなければ非正常振替処理が行われる。このようにすることにより、正常振替処理がなされる確率が向上するのである。
(1)サーバー1は<S6:決済日の3日前か>においてその日が決済日の3日前であるか否かを判断する。なお、これは決済日の3日前に限るものではなく、何日前であってもよい。また、3日前に確認することはサーバー1の記憶装置に記憶されているものとする。
(2)その後<S311a:預金残高要求>→<S312a:預金残高要求>→<S4a:正常引落が可能かの判断処理(第2判断処理及び第2判断手段)>を行う。そして、正常引落が不可能と判断された場合にはまず山田さんの電子メールアドレス(連絡先)あてに「預金残高不足です。このままだと担保金から引き落とすことになります。」などの警告メッセージを送信する(警告手段)。なお、山田さんの電子メールアドレスは図3の顧客ファイルから検索したものであり、警告メッセージは予めサーバー1の記憶装置に記憶されていたものとする。また、<S311a:預金残高要求>、<S312a:預金残高要求>、<S4a:正常引落が可能かの判断処理>は前述の<S311:預金残高要求>、<S312:預金残高要求>、<S4:正常引落が可能かの判断処理>と同様の処理である。
(3)次に、サーバー1は<S4:決済日か確認>を行い、決済日当日に改めて<S311:預金残高要求>→<S312:預金残高要求>→<S4:正常引落が可能かの判断処理>及びそれ以降の処理を行う。これにより山田さんが3日以内に預金口座に利用額以上の金額を入金すれば正常振替処理を行うことができる。一方、3日以内に入金がなければ非正常振替処理が行われる。このようにすることにより、正常振替処理がなされる確率が向上するのである。
上記実施例おいては特定のケースについて説明したが、本発明はこれら特定のケースに限るものではない。例えば、次のようなケースであっても構わない。
(1)上記実施例では、クレジットカード会社のサーバーが主な処理を行うケースを例に説明したが、本発明はこれに限るものではなく、例えばチケット販売業者のサーバーがこれら処理を行ってもよい。
(2)データの内容は実施例で説明したデータに限らない。即ち、同様の役割を果たすことができれば、他のどのようなデータであっても構わない。
(3)ハードウェアも実施例で説明したものに限らない。即ち、同様の役割を果たすことができれば、他のどのようなハードウェアであっても構わない。例えば、本発明では各処理を複数のサーバーが処理を行っているがこれを一つの装置で行ってもよく、また何台もの装置で行ってもよい。
(4)処理の内容や手順についても実施例で説明したものに限らない。即ち、同様の役割を果たすことができれば、他のどのような処理内容・処理手順であっても構わない。
(5)上記実施例に登場するデータ(データレコード、ファイル)のデータ(データ項目)は、原則として各々関連づけられて(対応づけられて)記憶装置に記憶されているものとする。図面に表されたものについても同様である。
(1)上記実施例では、クレジットカード会社のサーバーが主な処理を行うケースを例に説明したが、本発明はこれに限るものではなく、例えばチケット販売業者のサーバーがこれら処理を行ってもよい。
(2)データの内容は実施例で説明したデータに限らない。即ち、同様の役割を果たすことができれば、他のどのようなデータであっても構わない。
(3)ハードウェアも実施例で説明したものに限らない。即ち、同様の役割を果たすことができれば、他のどのようなハードウェアであっても構わない。例えば、本発明では各処理を複数のサーバーが処理を行っているがこれを一つの装置で行ってもよく、また何台もの装置で行ってもよい。
(4)処理の内容や手順についても実施例で説明したものに限らない。即ち、同様の役割を果たすことができれば、他のどのような処理内容・処理手順であっても構わない。
(5)上記実施例に登場するデータ(データレコード、ファイル)のデータ(データ項目)は、原則として各々関連づけられて(対応づけられて)記憶装置に記憶されているものとする。図面に表されたものについても同様である。
1 クレジットカード会社が利用するサーバー
2 銀行が利用するサーバー
3 チケット販売業者が利用するサーバー
10 インターネット
2 銀行が利用するサーバー
3 チケット販売業者が利用するサーバー
10 インターネット
Claims (18)
- クレジットカードの利用代金を徴収する代金徴収装置を含むコンピュータシステムであって、
前記代金徴収装置は、顧客の預金口座の預金残高を特定する預金残高特定手段、顧客から提供された担保金を管理する担保金管理手段、顧客が購入した商品の代金を受信する代金受信手段、前記預金残高と前記代金に基づいて前記預金口座から前記代金を引落とすことが可能か否かの第1判断処理を行う第1判断手段、前記第1判断処理において引落とし可能と判断された場合は前記預金口座から前記代金を引落とすための処理を行う第1引落手段、前記第1判断処理において引落とし不能と判断された場合は前記担保金から前記代金を引き落とすための処理を行う第2引落手段を備える利用代金徴収システム。 - 前記代金徴収装置は、顧客の連絡先を記憶する連絡先記憶手段、前記第1判断処理を行う前に前記第1判断処理と同様の処理である第2判断処理を行う第2判断手段、前記第2判断処理において引落とし不能と判断された場合は前記警告メッセージを前記連絡先に送信する警告手段を備えることを特徴とする請求項1記載の利用代金徴収システム。
- 前記代金徴収装置は、前記預金口座から前記代金が正常に引落されたか否かを判断し正常に引落としされた場合は正常引落回数又は正常引落率を集計する正常回数集計手段、顧客を優良会員とみなすための条件を記憶する条件記憶手段、前記正常引落回数又は前記正常引落率と前記条件とを比較し前記正常引落回数が前記条件に合致している場合はその顧客に対し特典を付与する特典付与手段を備えることを特徴とする請求項1乃至2記載の利用代金徴収システム。
- 前記代金徴収装置は、会員の地位を記憶する地位記憶手段を備え、
前記特典とは前記会員の地位を上位の地位に更新する処理であることを特徴とする請求項3記載の利用代金徴収システム。 - 前記代金徴収装置は、クレジットカードサービスを享受する資格の有無を管理する資格管理手段を備え、
前記特典とは、正規のクレジットカードサービスを享受する資格を無から有に更新する処理であることを特徴とする請求項3記載の利用代金徴収システム。 - 前記代金徴収装置は、会員の獲得ポイントを管理するポイント管理手段を備え、
前記特典とは会員の前記ポイントを増加させる処理であることを特徴とする請求項3記載の利用代金徴収システム。 - クレジットカードの利用代金を徴収する代金徴収装置を含むコンピュータシステムに処理を命令するものであって、
前記代金徴収装置を、顧客の預金口座の預金残高を特定する預金残高特定手段、顧客から提供された担保金を管理する担保金管理手段、顧客が購入した商品の代金を受信する代金受信手段、前記預金残高と前記代金に基づいて前記預金口座から前記代金を引落とすことが可能か否かの第1判断処理を行う第1判断手段、前記第1判断処理において引落とし可能と判断された場合は前記預金口座から前記代金を引落とすための処理を行う第1引落手段、前記第1判断処理において引落とし不能と判断された場合は前記担保金から前記代金を引き落とすための処理を行う第2引落手段として機能させることを特徴とする利用代金徴収のためのコンピュータプログラム。 - 前記代金徴収装置を、顧客の連絡先を記憶する連絡先記憶手段、前記第1判断処理を行う前に前記第1判断処理と同様の処理である第2判断処理を行う第2判断手段、前記第2判断処理において引落とし不能と判断された場合は前記警告メッセージを前記連絡先に送信する警告手段として機能させることを特徴とする請求項7記載の利用代金徴収のためのコンピュータプログラム。
- 前記代金徴収装置を、前記預金口座から前記代金が正常に引落されたか否かを判断し正常に引落としされた場合は正常引落回数又は正常引落率を集計する正常回数集計手段、顧客を優良会員とみなすための条件を記憶する条件記憶手段、前記正常引落回数又は前記正常引落率と前記条件とを比較し前記正常引落回数が前記条件に合致している場合はその顧客に対し特典を付与する特典付与手段として機能させることを特徴とする請求項7乃至8記載の利用代金徴収のためのコンピュータプログラム。
- 前記代金徴収装置を会員の地位を記憶する地位記憶手段として機能させ、
前記特典とは前記会員の地位を上位の地位に更新する処理であることを特徴とする請求項9記載の利用代金徴収のためのコンピュータプログラム。 - 前記代金徴収装置をクレジットカードサービスを享受する資格の有無を管理する資格管理手段として機能させ、
前記特典とは、正規のクレジットカードサービスを享受する資格を無から有に更新する処理であることを特徴とする請求項9記載の利用代金徴収のためのコンピュータプログラム。 - 前記代金徴収装置を会員の獲得ポイントを管理するポイント管理手段として機能させ、
前記特典とは会員の前記ポイントを増加させる処理であることを特徴とする請求項9記載の利用代金徴収のためのコンピュータプログラム。 - クレジットカードの利用代金を徴収する代金徴収装置を含むコンピュータシステムにより実現される方法であって、
前記代金徴収装置が、顧客の預金口座の預金残高を特定するステップ、顧客から提供された担保金を管理するステップ、顧客が購入した商品の代金を受信するステップ、前記預金残高と前記代金に基づいて前記預金口座から前記代金を引落とすことが可能か否かの第1判断処理を行うステップ、前記第1判断処理において引落とし可能と判断された場合は前記預金口座から前記代金を引落とすための処理を行うステップ、前記第1判断処理において引落とし不能と判断された場合は前記担保金から前記代金を引き落とすための処理を行うステップを行うことを特徴とする利用代金徴収方法。 - 前記代金徴収装置が、顧客の連絡先を記憶するステップ、前記第1判断処理を行う前に前記第1判断処理と同様の処理である第2判断処理を行うステップ、前記第2判断処理において引落とし不能と判断された場合は前記警告メッセージを前記連絡先に送信するステップを行うことを特徴とする請求項13記載の利用代金徴収方法。
- 前記代金徴収装置が、前記預金口座から前記代金が正常に引落されたか否かを判断し正常に引落としされた場合は正常引落回数又は正常引落率を集計するステップ、顧客を優良会員とみなすための条件を記憶するステップ、前記正常引落回数又は前記正常引落率と前記条件とを比較し前記正常引落回数が前記条件に合致している場合はその顧客に対し特典を付与するステップを行うことを特徴とする請求項13乃至14記載の利用代金徴収方法。
- 前記代金徴収装置が会員の地位を記憶するステップを行い、
前記特典とは前記会員の地位を上位の地位に更新する処理であることを特徴とする請求項15記載の利用代金徴収方法。 - 前記代金徴収装置がクレジットカードサービスを享受する資格の有無を管理するステップを行い、
前記特典とは、正規のクレジットカードサービスを享受する資格を無から有に更新する処理であることを特徴とする請求項15記載の利用代金徴収方法。 - 前記代金徴収装置を会員の獲得ポイントを管理するステップを行い、
前記特典とは会員の前記ポイントを増加させる処理であることを特徴とする請求項15記載の利用代金徴収方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2005152334A JP2006330990A (ja) | 2005-05-25 | 2005-05-25 | 利用代金徴収システムとそれを実現するためのコンピュータプログラムとその方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2005152334A JP2006330990A (ja) | 2005-05-25 | 2005-05-25 | 利用代金徴収システムとそれを実現するためのコンピュータプログラムとその方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2006330990A true JP2006330990A (ja) | 2006-12-07 |
Family
ID=37552629
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2005152334A Pending JP2006330990A (ja) | 2005-05-25 | 2005-05-25 | 利用代金徴収システムとそれを実現するためのコンピュータプログラムとその方法 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2006330990A (ja) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2011003037A (ja) * | 2009-06-18 | 2011-01-06 | Mai Barai Kk | クレジットカード番号を用いたプリペイド決済システム及びプリペイド決済の方法 |
WO2014178121A1 (ja) * | 2013-04-30 | 2014-11-06 | 楽天株式会社 | 情報処理システム、情報処理システムの制御方法、および情報処理プログラム |
JP2017515253A (ja) * | 2015-04-21 | 2017-06-08 | 小米科技有限責任公司Xiaomi Inc. | 数値移転方法、端末およびクラウドサーバ |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2002092326A (ja) * | 2000-09-18 | 2002-03-29 | Toshiba Corp | 金融処理システム |
JP2002269354A (ja) * | 2001-03-13 | 2002-09-20 | Yasuhiko Sumita | クレジットカード利用方法 |
JP2003132212A (ja) * | 2001-10-22 | 2003-05-09 | Suruga Bank Ltd | リスク評価に基づくローン設定システム |
JP2005100260A (ja) * | 2003-09-26 | 2005-04-14 | Japan Research Institute Ltd | クレジットカード会社システム |
-
2005
- 2005-05-25 JP JP2005152334A patent/JP2006330990A/ja active Pending
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2002092326A (ja) * | 2000-09-18 | 2002-03-29 | Toshiba Corp | 金融処理システム |
JP2002269354A (ja) * | 2001-03-13 | 2002-09-20 | Yasuhiko Sumita | クレジットカード利用方法 |
JP2003132212A (ja) * | 2001-10-22 | 2003-05-09 | Suruga Bank Ltd | リスク評価に基づくローン設定システム |
JP2005100260A (ja) * | 2003-09-26 | 2005-04-14 | Japan Research Institute Ltd | クレジットカード会社システム |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2011003037A (ja) * | 2009-06-18 | 2011-01-06 | Mai Barai Kk | クレジットカード番号を用いたプリペイド決済システム及びプリペイド決済の方法 |
WO2014178121A1 (ja) * | 2013-04-30 | 2014-11-06 | 楽天株式会社 | 情報処理システム、情報処理システムの制御方法、および情報処理プログラム |
JP5678235B1 (ja) * | 2013-04-30 | 2015-02-25 | 楽天株式会社 | 情報処理システム、情報処理システムの制御方法、および情報処理プログラム |
JP2017515253A (ja) * | 2015-04-21 | 2017-06-08 | 小米科技有限責任公司Xiaomi Inc. | 数値移転方法、端末およびクラウドサーバ |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN106570757B (zh) | 一种基于区块链的众筹方法、装置及系统 | |
Pennathur | “Clicks and bricks”:: e-Risk Management for banks in the age of the Internet | |
KR101379168B1 (ko) | 온라인 인증 서비스 방법 | |
EP0791202B1 (en) | Computerized payment system for purchasing information products by electronic transfer on the internet | |
TW381241B (en) | Electronic wallet based on distributed network | |
US20030163416A1 (en) | Transaction information management system, transcaction information anonymizing server, and transaction information management method | |
US20220230175A1 (en) | Method to be executed by computer system, and computer system | |
EP1873704A1 (en) | Method and system for determining whether the origin of a payment request is a specific e-commerce network source | |
BRPI0613951A2 (pt) | sistema e método para a nova execução e gerenciamento de transações de dados e financeiras | |
US20040153410A1 (en) | Anonymous payment system and method | |
WO2001084906A2 (en) | Advanced asset management systems | |
TW200907843A (en) | Trusted third party clearing house for lead tracking | |
KR20190057909A (ko) | 블록체인 기반 부동산 계약 방법 및 부동산 중개 시스템 | |
Schreft | Risks of identity theft: Can the market protect the payment system? | |
KR102136976B1 (ko) | 토큰화된 모바일 상품권 서비스 방법 및 이를 이용한 서비스 제공 장치 | |
JP2002092328A (ja) | 株式売買システム及び株式売買方法 | |
JP2006330990A (ja) | 利用代金徴収システムとそれを実現するためのコンピュータプログラムとその方法 | |
JP2007047999A (ja) | 証券決済残高管理システム及び証券決済残高管理プログラム | |
KR20110074263A (ko) | 가상 계좌를 이용한 국제 거래 결제 시스템 및 그 방법 | |
KR20110117838A (ko) | 온라인 게임 아이템 거래 중개 시스템 및 그 방법 | |
KR102286045B1 (ko) | 블록체인 기반의 택배 가상 화폐 운영 시스템 및 가상 화폐의 채굴 방법 | |
KR20200003973A (ko) | 암호화폐 거래 시스템 및 암호화폐 거래 서비스의 제공 방법 | |
JP7309995B1 (ja) | 情報処理装置、情報処理方法及び情報処理プログラム | |
KR20140124430A (ko) | 게임 아이템 중개 방법 | |
JP2003507824A (ja) | 電子商取引を行うための保証システムおよびそれに用いる方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20080225 |
|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20100420 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20100525 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20101026 |