JPWO2004075081A1 - Mobile/Internet commerce payment system - Google Patents

Mobile/Internet commerce payment system Download PDF

Info

Publication number
JPWO2004075081A1
JPWO2004075081A1 JP2004568507A JP2004568507A JPWO2004075081A1 JP WO2004075081 A1 JPWO2004075081 A1 JP WO2004075081A1 JP 2004568507 A JP2004568507 A JP 2004568507A JP 2004568507 A JP2004568507 A JP 2004568507A JP WO2004075081 A1 JPWO2004075081 A1 JP WO2004075081A1
Authority
JP
Japan
Prior art keywords
transaction
data
payment
terminal device
unit
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
Application number
JP2004568507A
Other languages
Japanese (ja)
Inventor
道子 角田
道子 角田
Original Assignee
ソースジャパン株式会社
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by ソースジャパン株式会社 filed Critical ソースジャパン株式会社
Publication of JPWO2004075081A1 publication Critical patent/JPWO2004075081A1/en
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00Commerce
    • G06Q30/06Buying, selling or leasing transactions
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/20Point-of-sale [POS] network systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/22Payment schemes or models
    • G06Q20/24Credit schemes, i.e. "pay after"
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322Aspects of commerce using mobile devices [M-devices]

Abstract

現在のクレジット支払いインフラストラクチャーの利用による店の負担をより軽減できてセキュリティも確保できる支払いの仕組みを提供する.決済情報管理サーバ(0220)が,クレジット会社と通信し,顧客と通信し(与信に基づき,カード番号でない識別情報が含まれた取引可否データを携帯電話(0200)に送信する),さらに店とも通信する(携帯電話と無線リンクされたPOS端末(0210)から取引実行データを受信し,識別情報の照合をする)ようにする.クレジット会社との間のトランザクションは定期的にまとめられた(アグリゲートされた)総額ベースでもよい.取引可否データも総額/残高ベースであってよい(電子マネー).携帯電話の代わりに非接触カードも使用されうる(PCと併用される).We provide a payment system that can reduce the burden on the store due to the use of the current credit payment infrastructure and ensure security. The payment information management server (0220) communicates with the credit company, communicates with the customer (transmits the transaction approval/disapproval data including identification information other than the card number to the mobile phone (0200) based on the credit), and also with the store Communication is performed (transaction execution data is received from the POS terminal (0210) wirelessly linked to the mobile phone and the identification information is collated). Transactions with credit companies may be on a regularly aggregated (aggregated) basis. The transaction approval/disapproval data may also be based on the total amount/balance (electronic money). A contactless card can be used instead of a mobile phone (used in combination with a PC).

Description

本願発明は、携帯端末装置を利用したクレジットシステムによる決済、若しくは携帯端末装置を利用した銀行間等の振替決済のための仕組みと、固定端末装置を利用したインターネット回線網を介した企業間取引の決済、若しくは固定端末装置を利用したネット取引の仕組みに関する。  The present invention provides a mechanism for payment by a credit system using a mobile terminal device or a transfer payment between banks using a mobile terminal device, and a transaction between companies through an internet line network using a fixed terminal device. It relates to the mechanism of settlement or online transactions using fixed terminal devices.

従来より、クレジットカードを直接店舗で提示することなく、携帯電話等の端末を利用してクレジットシステムによる決済を可能とする方法、システム等が提案されている。
例えば、「携帯電話が通信用アンテナに加えて、メモリおよびカードリーダを備え、メモリには、カードリーダから読み込んだ又は携帯電話を使用してインターネット経由でクレジット会社から取得した自己のクレジットカードの個人情報を記憶し、そして、この記憶されたクレジットカードの個人情報をレジに無線通信して送信することを特徴とする携帯電話クレジット決済方法」が存在する(特許文献1参照)。
また、「携帯電話のICメモリ部にクレジット会社で暗号化したクレジットカード番号を含むクレジット情報を記録すると共に、電子決済通信端末との通信を可能にする送受信部が搭載された携帯電話と、店のレジスタなどの装置に搭載または、接続された電子決済通信端末との間で通信を確立し、該クレジットカード機能を有する携帯電話を、該電子決済通信端末の送受信部に近づけることにより、暗号化クレジットカード番号などの決済情報を契約クレジットカード会社に通信回線を介して送信し、契約クレジット会社のみが暗号復元化装置によりカード所有者を認識可能にしたクレジットカード決済機能付携帯電話の決済システム。」と構成したものも存在する(特許文献2参照)。
これらの携帯電話を利用したクレジットシステムによる決済方法等は、クレジットカードに関する情報が暗号化等され直接確認することができないようにしているため、携帯電話を利用しない通常のクレジットシステムによる決済に比べて、一定のレベルでセキュリティを向上させているといえる。
特開2002−279320 特開2002−269485
2. Description of the Related Art Conventionally, methods, systems, and the like have been proposed that enable payment by a credit system using a terminal such as a mobile phone without directly presenting a credit card at a store.
For example, "a cell phone has a memory and a card reader in addition to an antenna for communication, and the memory has an individual of its own credit card read from the card reader or obtained from a credit company via the Internet using the cell phone. There is a mobile phone credit payment method characterized by storing information and wirelessly transmitting the stored personal information of a credit card to a cash register (see Patent Document 1).
In addition, "a mobile phone equipped with a transmission/reception unit that records credit information including a credit card number encrypted by a credit company in an IC memory unit of the mobile phone and enables communication with an electronic payment communication terminal, and a store Encryption by establishing communication with an electronic payment communication terminal mounted on or connected to a device such as a cash register, and bringing the mobile phone having the credit card function close to the transmitting/receiving unit of the electronic payment communication terminal. A mobile phone payment system with a credit card payment function that sends payment information such as a credit card number to a contract credit card company via a communication line so that only the contract credit company can recognize the cardholder by an encryption recovery device. There is also one configured as "" (see Patent Document 2).
The payment method using a credit system using these mobile phones is such that the information related to the credit card is encrypted so that it cannot be directly checked, so compared to payment using a normal credit system that does not use a mobile phone. , It can be said that security is improved at a certain level.
JP-A-2002-279320 JP 2002-269485

しかし、従来提案されている携帯電話を利用したクレジットシステムの決済の仕組みは、例えば、コンビニエンスストア等のように、小額の決済を短時間に多数人について行うような商業店舗等では、実際はあまり利用が促進されていない。
その大きな理由の一つが、携帯電話を利用すると否とに関わらず、クレジットシステムによる決済自体が、現金による決済に比べて店舗の端末における処理や、それに関わる店舗側の人の作業が多いことにある。その主な原因は、クレジットシステムによる決済では、特定の取引が当該クレジットシステムによって決済が可能であるかどうかを取引ごとに判断するための与信処理(取引可否の確認)を、通常は店舗側で行うことが必要となる点にある。この点については、上記特許文献1,2に記載されている従来技術に残された未解決の技術上の課題といえる。
また、かかる特許文献1,2に記載の従来技術では、クレジットカード等の情報は暗号化されているものの、その暗号が復号されて、解読された場合は当該クレジットカードの情報等が漏洩する可能性があり、セキュリティが暗号化技術の限度でしか担保されない。従って、クレジットシステムを利用した決済等、信用取引に利用するにはセキュリティが十分でない。この点、クレジットシステムを利用した決済では、一般的には、店のレジスタ(POS端末装置)とクレジットカード会社のサーバとの間における情報(クレジットシステムによる決済の処理のために必要な情報)の送受信は、通常の通信回線網を使用せず、「CAFIS(Credit and Finance Information System)(登録商標)」等の決済専用の通信回線網を使用することからも、暗号技術のみではセキュリティの確保が十分でないとされていることが分かる。
つまり、かかる特許文献1,2に記載の従来技術のみでは、セキュリティを確保し、かつ、店舗側(POS端末装置)に対して与信処理(取引可否の確認)のための負担をかけることなく携帯電話を利用したクレジットシステムによる決済を行うための仕組を構築することは困難である。
そこで、本願発明は、携帯端末装置を利用したクレジットシステム等による決済、若しくは携帯端末装置や固定端末装置を利用した銀行間等の振替決済のための仕組みであって、当該決済における与信処理(取引可否の確認)のための負担を店舗側(POS端末装置若しくは取引サーバ)にかけることなく、かつ、暗号化技術のみに依存せずにセキュリティを確保できるような仕組みを提供することを目的とする。これにより、コンビニエンスストア等のように、小額の決済を短時間に多数人について行うような商業店舗等でも、携帯電話を利用したクレジットシステム等による決済を促進できる可能性がある。
かかる課題を解決するために、本願発明は、取引データ送信部、取引可否データ受信部、取引実行データ生成部、取引実行データ送信部とを有する携帯端末装置(若しくは固定端末装置)、及び、取引実行データ取得部、決済データ生成部、決済データ送信部とを有するPOS端末装置(若しくは取引サーバ)、及び、取引データ受信部、取引可否データ生成部、取引可否データ送信部、決済データ受信部、取引照合部とを有する決済情報管理サーバとからなる取引システム等を利用する。
クレジットシステム等により決済が可能であるかどうかの与信処理(取引可否の確認)は、予めクレジットカード等の利用者が利用する携帯端末装置(若しくは固定端末装置)からの要求(取引データ)に応じて決済情報管理サーバとクレジットカード会社(サーバ)間等で行われる。そして、その与信処理の結果である「取引の可否」を含む取引可否データが決済情報管理サーバで生成されて、利用者の携帯端末装置に送信される。さらに、その取引可否データに基づいて携帯端末装置で取引実行データ(取引を実行することを示すデータ)が生成されPOS端末装置(若しくは取引サーバ)に送信される。さらに、その取引実行データに基づいてPOS端末装置(若しくは取引サーバ)で決済データ(決済のためのデータ)が生成され、決済情報管理サーバに送信される。取引可否データ、取引実行データ、決済データのいずれも暗号化された取引識別情報が含まれる。この取引識別情報は決済情報管理サーバ内で、取引可否データ、及び決済のための処理に必要な情報(クレジットカード情報やデビットカード情報等)と関連付けられている。そして、決済情報管理サーバで受信される決済データに含まれる取引識別情報と、既に生成された取引可否データに含まれる取引識別情報とがそれぞれ決済情報管理サーバにおいて解読され、比較照合される。さらに、その照合結果が同一であると、取引可否データで示される取引可能な金額の範囲内で、前記決済のための処理に必要な情報を利用してそのまま決済情報管理サーバで決済のための処理が可能となる。つまり、POS端末装置(若しくは取引サーバ)では、従来のようにクレジットカード情報(カード番号等)等を入力し、クレジットカード会社のサーバ等と与信処理(取引の可否の確認)を改めて行う必要がなく負担が軽減される。
また、取引可否データ、取引実行データ、決済データのいずれもクレジットカード番号等を直接読み取ることができる情報は一切含まれていない。従って、当該取引可否データ、取引実行データ、決済データが通信途上等において悪意の第三者に取得されて暗号技術が破られた場合でも直接クレジットカード番号等が漏洩することはなく暗号化技術のみに依存せずにセキュリティを確保することができる。
However, the credit card payment system that has been proposed in the past is not often used in commercial stores, etc., where a small amount of money is settled for a large number of people in a short time, such as a convenience store. Is not promoted.
One of the main reasons for this is that, regardless of whether or not a mobile phone is used, payment by the credit system itself involves more processing at the store terminal and more work by the person at the store than the payment by cash. is there. The main reason for this is that, in the case of payment by credit system, credit processing (confirmation of transaction availability) to determine whether or not a specific transaction can be settled by the credit system is usually performed on the store side. There is a point that needs to be done. This point can be said to be an unsolved technical problem left behind in the related art described in Patent Documents 1 and 2.
In addition, in the related art described in Patent Documents 1 and 2, although the information of the credit card and the like is encrypted, if the code is decrypted and decrypted, the information of the credit card and the like can be leaked. Security, and security is guaranteed only by the limits of encryption technology. Therefore, security is not sufficient for use in credit transactions such as settlement using a credit system. In this regard, in the settlement using the credit system, generally, information (information necessary for processing the settlement by the credit system) between the store register (POS terminal device) and the server of the credit card company is stored. The transmission and reception do not use a normal communication line network, but use a communication line network dedicated to payment such as "CAFIS (Credit and Finance Information System) (registered trademark)". You can see that it is not enough.
In other words, with only the conventional techniques described in Patent Documents 1 and 2, the security is ensured and the store side (POS terminal device) can be carried without burden for credit processing (confirmation of transaction availability). It is difficult to build a mechanism for making payments by a credit system using a telephone.
Therefore, the present invention is a mechanism for payment by a credit system or the like using a mobile terminal device, or transfer payment between banks using a mobile terminal device or a fixed terminal device. The purpose is to provide a mechanism that can secure security without burdening the store side (POS terminal device or transaction server) for confirmation (approval confirmation) and without relying only on encryption technology. .. As a result, there is a possibility that even in a commercial store or the like, such as a convenience store, where a small amount of money is settled for a large number of people in a short time, settlement by a credit system using a mobile phone can be promoted.
In order to solve such a problem, the present invention provides a portable terminal device (or a fixed terminal device) having a transaction data transmitting unit, a transaction permission/inhibition data receiving unit, a transaction execution data generating unit, and a transaction execution data transmitting unit, and a transaction. A POS terminal device (or transaction server) having an execution data acquisition unit, a payment data generation unit, and a payment data transmission unit; and a transaction data reception unit, a transaction approval/disapproval data generation unit, a transaction approval/disapproval data transmission unit, a payment data reception unit, A transaction system or the like including a payment information management server having a transaction matching unit is used.
Credit processing (confirmation of transaction availability) as to whether settlement is possible by a credit system or the like is based on a request (transaction data) from a mobile terminal device (or fixed terminal device) used by a user such as a credit card in advance. Between the payment information management server and the credit card company (server). Then, transaction approval/disapproval data including "transaction approval/disapproval" as a result of the credit processing is generated by the payment information management server and transmitted to the user's mobile terminal device. Further, transaction execution data (data indicating execution of a transaction) is generated on the mobile terminal device based on the transaction approval/disapproval data and transmitted to the POS terminal device (or transaction server). Further, payment data (data for payment) is generated by the POS terminal device (or the transaction server) based on the transaction execution data and transmitted to the payment information management server. The transaction approval/disapproval data, transaction execution data, and settlement data all include encrypted transaction identification information. This transaction identification information is associated with transaction approval/disapproval data and information necessary for processing for settlement (credit card information, debit card information, etc.) in the settlement information management server. Then, the transaction identification information included in the payment data received by the payment information management server and the transaction identification information included in the already generated transaction approval/disapproval data are respectively decoded and compared and compared by the payment information management server. Further, if the collation results are the same, within the range of the transactable amount indicated by the transaction permission/inhibition data, the information necessary for the processing for the settlement is directly used for the settlement by the settlement information management server. Processing becomes possible. In other words, in the POS terminal device (or transaction server), it is necessary to input credit card information (card number, etc.) and perform credit processing (confirmation of transaction availability) again with the credit card company server, etc. The burden is reduced.
Further, none of the transaction approval/disapproval data, the transaction execution data, and the payment data includes information that can directly read the credit card number or the like. Therefore, even if the transaction propriety data, transaction execution data, and settlement data are acquired by a malicious third party during communication and the encryption technology is broken, the credit card number etc. will not be directly leaked and only the encryption technology will be used. Security can be secured without depending on.

図1は、実施形態1の概念の一例を示す図である。
図2は、実施形態1の機能ブロックの一例を示す図である。
図3は、実施形態1の処理の流れの一例を示す図である。
図4は、実施形態1の処理の流れの一例を示す図である。
図5は、実施形態1の処理の流れの一例を示す図である。
図6は、実施形態1の処理の流れの一例を示す図である。
図7は、実施形態2の概念の一例を示す図である。
図8は、実施形態2の機能ブロックの一例を示す図である。
図9は、実施形態2の処理の流れの一例を示す図である。
図10は、実施形態2の機能ブロックの一例を示す図である。
図11は、実施形態1の機能ブロックの一例を示す図である。
図12は、実施形態3の概念の一例を示す図である。
図13は、実施形態3の機能ブロックの一例を示す図である。
図14は、実施形態3の処理の流れの一例を示す図である。
図15は、実施形態4の概念の一例を示す図である。
図16は、実施形態4の機能ブロックの一例を示す図である。
図17は、実施形態4の処理の流れの一例を示す図である。
図18は、実施形態3の取引実行データ生成部の具体例の一例を示す図である。
FIG. 1 is a diagram illustrating an example of the concept of the first embodiment.
FIG. 2 is a diagram illustrating an example of the functional blocks of the first embodiment.
FIG. 3 is a diagram illustrating an example of a processing flow of the first embodiment.
FIG. 4 is a diagram illustrating an example of a processing flow of the first embodiment.
FIG. 5 is a diagram illustrating an example of a processing flow of the first embodiment.
FIG. 6 is a diagram illustrating an example of a processing flow of the first embodiment.
FIG. 7 is a diagram showing an example of the concept of the second embodiment.
FIG. 8 is a diagram illustrating an example of functional blocks of the second embodiment.
FIG. 9 is a diagram illustrating an example of a processing flow of the second embodiment.
FIG. 10 is a diagram showing an example of the functional blocks of the second embodiment.
FIG. 11 is a diagram illustrating an example of the functional blocks of the first embodiment.
FIG. 12 is a diagram showing an example of the concept of the third embodiment.
FIG. 13 is a diagram illustrating an example of functional blocks of the third embodiment.
FIG. 14 is a diagram illustrating an example of a processing flow of the third embodiment.
FIG. 15 is a diagram showing an example of the concept of the fourth embodiment.
FIG. 16 is a diagram illustrating an example of functional blocks of the fourth embodiment.
FIG. 17 is a diagram illustrating an example of the processing flow of the fourth embodiment.
FIG. 18 is a diagram illustrating an example of a specific example of the transaction execution data generation unit according to the third embodiment.

実施形態と請求の範囲との関係は次のとおりである。実施形態1は、主に、請求の範囲1、4から14等に関する。
実施形態2は、主に、請求の範囲15,16等に関する。
実施形態3は、主に、請求の範囲2等に関する。
実施形態4は、主に、請求の範囲3等に関する。
以下、図1から図18を用いて本願発明の実施形態の一例を説明する。
<<実施形態1>>
<実施形態1の概念>
本実施形態は、携帯電話に代表される携帯端末装置を利用してクレジットシステム等による決済を可能とする仕組みを代表例としている。そして、本実施形態は、特に当該決済における与信処理(取引可否の確認)のための負担を店舗側にかけることなく、かつ、暗号化技術のみに依存せずに、セキュリティを確保できるような仕組みになっている。そして、その応用例として携帯端末装置に代えて固定端末装置を用いる仕組みや、POS端末装置に代えて取引サーバを用いる仕組みをあげている。
図1は、実施形態1の概念の一例を示す図である。同図を用いて、本実施形態の概念の一例を説明する。
クレジットカードの利用者は、クレジットシステムによる決済により、商業店舗で購入した商品の清算を行った。商品の代金は450円であった。その際、クレジットカードを直接当該商業店舗で提示することはなかった。代わりに、予め500円分の商品を自身の利用するクレジットカードの情報に基づいて決済することができるかどうかについて、つまり取引の可否の確認(与信処理)を、自身の携帯電話を利用して通信により決済情報管理サーバに要求した(取引データを送信した)(1)。決済情報管理サーバでは、この利用者による500円分の決済が可能であるか否かを当該利用者が利用するクレジットカード会社のサーバへの問い合わせにより確認した(2)。決済情報管理サーバは、500円分の決済が可能であることを示すデータ(取引の可否を含むデータ)であって、かつ、決済情報管理サーバでのみ解読可能に暗号化された取引識別情報を含むデータである取引可否データを生成して前記利用者の携帯電話に送信した。この取引識別情報は、決済情報管理サーバ内で、「決済のための処理に必要な情報(クレジットカード番号等)」と関連付けられている。(3)。さらに、前記利用者は450円分の買い物をすることを決定し、前記利用者の携帯電話では取引可否データから前記取引識別情報を含む取引実行データが生成されて店のPOS端末装置に渡された(4)。店のPOS端末装置では、改めて取引の可否の確認(与信処理)を行うことなく、渡された取引実行データから前記取引識別情報を含む決済のための決済データを生成して決済情報管理サーバに送信した(5)。決済情報管理サーバは、取引可否データに含まれる暗号化された取引識別情報と、決済データに含まれる暗号化された取引識別情報を復号化して照合し、同一であると判断した。そして、その取引識別情報に基づいて、決済のための処理に必要な情報等を取得して、決済のための処理を行い前記商業店舗での清算は終了した。利用者のクレジットカードの番号等を含む、決済のための処理に必要な情報は、本願発明の取引システムにおいては、決済情報管理サーバでのみ管理されている。その取引識別情報は、決済情報管理サーバで取引可否データに含まれるデータとして生成され、決済情報管理サーバでのみ解読可能なように暗号化されている。そして、暗号化された取引識別情報は、決済情報管理サーバから送信され、携帯端末装置、POS端末装置を経て決済情報管理サーバに戻される。そして、上述のとおり、暗号化された取引識別情報は、携帯端末装置、POS端末装置を経由する間は、他のデータ(取引実行データ、決済データ)に含まれて渡される。そして、取引識別情報が改竄されることなく巡回し、巡回前と後との照合を得て始めて、決済情報管理サーバにおいて決済のための処理に必要な情報を取得し、決済のための処理を可能とした。従って利用者のクレジットカード番号等、決済のための処理に必要な情報が決済情報管理サーバ以外で特定されることはなかった。
<実施形態1の構成>
図2は本実施形態の機能ブロックの一例を図である、同図を用いて本実施形態の構成の一例を説明する。
本実施形態は、携帯端末装置0200、POS端末装置0210、決済情報管理サーバ0220からなる取引システムである。
<携帯端末装置の構成>
「携帯端末装置0200」は、取引データ送信部0201、取引可否データ受信部0202、取引実行データ生成部0203、取引実行データ送信部0204とを有する。また、「携帯端末装置」としては、具体的には携帯電話、PHS、PDA、腕時計等が該当する。
「取引データ送信部0201」は、取引予定額を含む取引データを送信する。
「取引データ」とは、上述のとおり、取引予定額を含むデータである。また、取引データは、これから行おうとする取引を何かしらの形で識別できる情報(予定取引識別情報)を含むようにしてもよい。予定取引識別情報には、例えば、携帯端末装置の利用者が購入を予定する商品に関する情報、かかる利用者が受ける予定のサービスに関する情報、その他取引を行う予定日、場所等に関する情報が含まれる場合がある。取引データにかかる予定取引識別情報を含ませることで、後述する取引可否データが通信途上で不正に取得されて複製され、本来予定していた取引とは別の取引に不正に利用されることを防止することができる。例えば、A商品を購入する取引に関する取引データに、当該A商品の商品コード等を、前記予定取引識別情報として含めることができる。この場合、後述する取引可否データにも当該A商品に関する予定取引識別情報が含まれる。そして、かかる取引可否データに基づいて生成される取引実行データは、A商品を「決済する取引対象」とするものに限定することができる。つまり、A商品を「決済する取引対象」としない取引に、当該取引可否データ、取引実行データを利用することを防止することができる。
「取引予定額」とは取引をするために与信を受けることを希望する金額をいう。例えば、取引予定額とは、クレジットシステム若しくは、銀行間の振替(デビットカードを利用する場合を含む)等による決済を予定する金額をいう。取引予定額とは、例えば、クレジットシステムによる決済で商品の購入代金を清算する場合には、当該商品の代金と同じ金額、若しくは、当該商品の金額を超える金額のいずれを意味するものであってもよい。例えば、商品の代金が450円である場合に、当該代金と同額の450円を取引予定額とすることができる。また、同じく商品の代金が450円である場合に、当該金額を超える500円を取引予定額とすることもできる。つまり、取引予定額は、決済を予定する上限の金額を示す。
取引データは、図示はしないが、かかる取引予定額以外に、携帯端末装置を識別するための情報である携帯端末装置識別情報を含む場合がある。また、取引データは、図示はしないが、携帯端末装置を利用してクレジットシステム等による決済を行う利用者等を単位として、後述する決済情報管理サーバで管理される口座ファイル(後述する「情報蓄積部」に含まれる)と関連付けられた利用者口座情報を含む場合がある。かかる携帯端末装置識別情報、利用者口座情報は、前記利用者の利用するクレジットカードの番号等を直接示すものではない。この携帯端末装置識別情報、利用者口座情報は、後述するように、決済情報管理サーバで受信される。そして、特定の取引予定額について当該利用者の利用するクレジットシステムによる決済が可能であるかどうか、即ち取引の可否を判断するために必要な情報等が、携帯端末装置識別情報、若しくは利用者口座情報に基づいて取得可能となる。「取引の可否を判断するために必要な情報」とは、例えば、前記利用者がクレジットシステムを利用して取引の決済を行う場合は、当該クレジットカードのカード番号、クレジットカードの有効期限、クレジットカードの名義人の氏名、電話番号等の情報を意味する。また、前記利用者がデビットカードを利用して取引の決済を行う場合、当該デビットカードのカード番号、デビットカードの暗証番号等に関する情報を意味する。かかる「取引の可否を判断するために必要な情報」は、後述する「決済のための処理に必要な情報」と同様である。また、当該携帯端末装置識別情報、利用者口座情報は、パスワードの入力と組み合せて、前記利用者の本人の認証に利用されるものであってもよい。また、当該携帯端末装置識別情報、利用者口座情報は、ICカード等に格納し、そのICカードから携帯端末装置が取得するようにしてもよい。
なお、本願における「利用者」とは、別途定義される場合を除き、上述のとおり携帯端末装置(若しくは後述する固定端末装置)を利用してクレジットシステム若しくは銀行間の振替(デビットカードを利用する場合を含む)等による決済を行う者のことをいうものとする。
かかる取引データは、図示はしないが、携帯電話に設けられた入力部を利用して前記利用者が入力した情報、若しくは、携帯電話に設けられた受信部(取引データ特定情報受信部)で受信された情報(取引データ特定情報)に基づいて取得される場合がある。また、取引データは、携帯電話に設けられた読取部(カメラ等)により読み取られた商品に表示されたバーコード形式の情報(取引データ特定情報)、商品のパッケージに添付されたICカードに格納された情報(取引データ特定情報)等に基づいて取得される場合がある。さらに、前記受信部(取引データ特定情報受信部)、若しくは読取部を、赤外線通信(IrFM等)、非接触(RF)タグ、bluetooth等を利用して情報を受信可能に構成し、後述するPOS端末装置からこれらの手段で渡された情報を受信し、その情報に基づいて取引データを取得するように構成してもよい。かかる非接触(RF)タグを利用した通信方式には、電磁結合方式、静電結合方式、電磁誘導方式、マイクロ波方式、光通信方式等の方式が含まれる場合がある。
その他、取引データは携帯端末装置に送出されたメールより、公共料金や各種請求通知書をデータメモリから読み取りその情報(取引データ特定情報)等に基づいて取得される場合がある。
「取引可否データ受信部0202」は、前記取引データ送信部から送信された取引データに応じて取引の可否を含む取引可否データを受信する。
「取引可否データ」とは、上述のとおり、取引の可否を含むデータであり、前記取引データに応じて受信される。「取引の可否」としては、クレジットシステムを利用した決済においては与信結果が該当し、銀行間の振替による決済においては預金者の残高が取引予定額以上にあるか否かに関する残高照会の結果(「与信結果」ともいう。)等が該当する場合がある。また、取引可否データには、後述する決済情報管理サーバでのみ解読可能に暗号された取引識別情報が含まれる。例えば、取引可否データは、「決済可能な限度額A(450円)を、クレジットシステムBで決済することが可能である。」ことを示すと共に、取引識別情報Cを含む情報として取得される場合がある。この場合、取引可否データで示される「クレジットシステムB」は、クレジットシステムを利用した決済のための処理を行うのに必要な情報、例えば、当該クレジットカードのカード番号、有効期限、名義人の氏名、電話番号等の情報は一切含まれない。これらクレジットカードの番号等は、前記取引識別情報と関連付け等されて後述する決済情報管理サーバにおいて保持、蓄積、管理等されている。従って、これらクレジットカードの番号等は、後述する決済情報管理サーバにおいてのみ、前記取引識別情報に基づいて取得等することが可能となる。また、取引可否データには、前記携帯端末識別情報、若しくは前記利用者口座情報を含めることもできる。尚、取引可否データには決済情報管理サーバで管理される口座ファイル(後述する「情報蓄積部」に含まれる)内のクレジットシステム利用者の事故履歴情報や買物履歴情報等の顧客情報を含ませることもある。
「決済可能な限度額」は、上述のとおり、取引可否データによって直接示されるものであってもよく(取引可否データに含まれるものであってもよく)、また、取引可否データに関連付けられたデータによって示されるものであってもよい。後者の場合、例えば、当初に送信された前記取引データ等が前記取引可否データに関連付けられたデータに該当し、当該取引データによって「決済可能な限度額」を特定できるようにしてもよい。この場合、決済可能な限度額を直接示す情報は前記取引可否データに含める必要はない。
また、取引可否データが、「前記取引データに応じて受信される」とは、次の一連のステップを経て取引可否データが受信されることをいう。まず、前記取引データ送信部0201で送信された取引データが後述する決済情報管理サーバの取引データ受信部0221で受信される。次に、取引可否データ生成部0222でその受信された取引データに基づいて取引可否データが生成される。そして、生成された取引可否データが取引可否データ送信部0223から送信されて携帯端末装置0200の取引可否データ受信部0202で受信される。
「取引識別情報」とは、前記取引可否データを識別する情報であり、かつ、前記利用者が利用するクレジットシステム若しくは銀行間の振替(デビットカードを利用する場合を含む)による決済のための処理に必要な情報を識別するための情報をいう(ケースA)。
若しくは、「取引識別情報」とは、取引可否データと関連付けられている情報を意味するものであってもよい(ケースB)。
若しくは、「取引識別情報」とは、前記利用者が利用するクレジットシステム若しくは銀行間の振替(デビットカードを利用する場合を含む)による決済のための処理に必要な情報と関連付けられている情報を意味するものであってもよい(ケースC)。
上記のケースBの取引可否データと、決済のための処理に必要な情報との関連付けは、当初取引データが決済情報管理サーバにて受理され、与信結果が判別された時点に当該サーバのシステムで行われるものとする。
上記のケースCの決済のための処理に必要な情報と、取引可否データとの関連付けは、当初取引データが決済情報管理サーバにて受理され、与信結果が判別された時点に当該サーバのシステムで行われるものとする。
決済のための処理に必要な情報には、例えば、前記利用者がクレジットシステムを利用して決済を行う場合は、当該クレジットカードのカード番号、クレジットカードの有効期限、クレジットカードの名義人の氏名、電話番号等の情報が含まれる。また、決済のための処理に必要な情報には、例えば、前記利用者がデビットカードを利用して決済を行う場合、当該デビットカードのカード番号、デビットカードの暗証番号等に関する情報が含まれる。かかる決済のための処理に必要な情報は、後述する決済情報管理サーバにおいてのみ、前記取引識別情報に基づいて取得することができる。その理由は、当該取引識別情報と当該決済のために必要な情報との関連付けは決済情報管理サーバにおいてのみなされているからである。
前記取引識別情報は、本実施形態を利用して、POS端末装置における与信処理(取引可否の確認)の負担をかけず、かつ、決済を行う際のセキュリティを暗号化技術のみに依存せずに確保し、携帯電話を利用したクレジットシステムによる決済等を行う仕組みを実現するという本願発明の課題を解決する上で重要な役割を果たす。
その理由は、POS端末装置では、クレジットシステム等による決済において、クレジットカード等の情報を入力して、クレジットカード会社のサーバ等との間で与信処理(取引可否の確認)を行う必要がないからである。かかる与信処理の結果は、事前に携帯端末装置に取引可否データとして受信されている。その取引可否データは取引実行データとなって携帯端末装置からPOS端末装置に渡され、その取引実行データは決済データとなってPOS端末装置から決済情報管理サーバに渡される。この間、上述のとおり、POS端末装置では、クレジットカード会社等のサーバとの間で与信処理(取引可否の確認)を行う必要がない。従って、上述のとおり、POS端末装置側の負担が軽減される。
また、決済情報管理サーバ、携帯端末装置、POS端末装置間を結ぶネットワーク上で送受信される暗号化された取引識別情報自体は第三者に取得されてもなんら問題がない。つまり、決済の処理のために必要な情報はネットワーク上を流通しないので、かかる決済のための処理に必要な情報を暗号化して通信途上において秘密を保持する必要がない。従って、決済を行う際のセキュリティを暗号化技術のみに依存せずに確保することができる。また、クレジットシステム等による決済が促進されれば、キャッシャーに現金を一切置かずにクレジットシステム等のみで決済をすることもでき、現金の盗難等の不正行為を防止できる側面も兼ねあわせている。
また、取引識別情報を決済情報管理サーバでのみ解読可能に暗号化する態様としては、文字通り取引識別情報を決済情報管理サーバのみが有する(若しくは利用可能な)鍵で暗号化する場合、また、ネットワークの伝送方式(例えばデータ圧縮方式にもとづく伝送等)に合わせて取引識別情報を何かしらの形に変換する場合等を含む。
「取引実行データ生成部0203」は、前記取引可否データ受信部0202で受信した取引可否データに基づいて取引実行データを生成する。
「取引実行データ」とは、前記取引可否データ(若しくはこれに関連付けられたデータ)で示される決済可能な限度額の範囲内で、クレジットシステム若しくは銀行間の振替(デビットカードを利用する場合を含む)による決済のための処理を行うことを決定し、取引を実行することを示す情報である。そして、取引実行データは、決済情報管理サーバでのみ解読可能に暗号化された取引識別情報を有する。「取引実行データ」には、かかる暗号化された取引識別情報以外に、具体的には、「決済のための処理を行うことを決定したこと示す情報、決済をする金額、決済する取引対象の名称(商品名、サービス名称等)」等が含まれる場合がある。また、取引実行データには、前記携帯端末識別情報、若しくは前記利用者口座情報等を含ませることもできる。かかる、携帯端末識別情報等を取引実行データに含めてPOS端末装置に渡し、POS端末装置から決済データに含めて決済情報管理サーバに渡すことで、いわゆるなりすましの発見が容易となる。つまり、決済データに含まれる携帯端末識別情報等と、前記取引可否データに含まれる携帯端末識別情報等との一致不一致に基づいて、前記取引実行データの送信等が正当な利用者の携帯端末装置から行われたものか、その他の携帯端末装置から行われたもののいずれであるかを決済情報管理サーバが判断できるからである。そして、後者の場合、なりすましの可能性が高いので、決済情報管理サーバでその後の処理を行わないようにすることができる。また、携帯端末装置の利用者の認証はパスワードや携帯端末装置に取付けられた指紋認証により行うことが出来る。
また、上記「商品の金額、当該商品の名称」等の情報は、図示はしないが、携帯電話に設けられた入力部を利用して前記利用者が入力した情報、若しくは、携帯電話に設けられた受信部(取引実行データ特定情報受信部)で受信された情報(取引実行データ特定情報)に基づいて取得される場合がある。その他、取引実行データは携帯端末装置に送出されたメールより、公共料金や各種請求通知書をデータメモリから読み取りその情報(取引実行データ特定情報)等に基づいて取得される場合がある。また、図示はしないが、当該商品の金額等は、携帯電話に設けられた読取部により読み取られた商品に表示されたバーコード形式の情報(取引実行データ特定情報)、商品のパッケージに添付されたICカードに格納された情報(取引実行データ特定情報)等に基づいて取得される場合がある。さらに、前記受信部(取引実行データ特定情報受信部)、若しくは前記読取部を、赤外線通信(IrFM等)、非接触(RF)タグ、bluetooth等を利用して情報を受信可能とし、後述するPOS端末装置からこれらの手段で渡された情報に基づいて当該商品の金額等の情報が取得されるように構成してもよい。また、取引実行データは、前記取引可否データと同様に取引の可否を示すデータであり、例えば、「決済可能な限度額○○円を、クレジットシステムで決済することが可能である。」ことを示す。
また、前記取引可否データに前記携帯端末識別情報、若しくは前記利用者口座情報が含まれている場合、同じ情報を有する携帯端末装置の取引実行データ生成部においてのみ、前記取引実行データの生成ができるようにすることもできる。これにより、取引可否データが通信途上で不正に取得されて、いわゆるなりすましによりその後の処理が行われることを防止できる。
また、取引可否データ、取引実行データは、いずれも「決済可能な限度額」を示さず、単に「取引が可能である」ことを示すデータであってもよい。この場合、POS端末装置では、決済データに含まれる金額関係の情報は「決済をする金額」のみとなる。決済情報管理サーバは、かかる決済データを受信後、かかる決済データに含まれる取引識別情報に基づいて取引可否データを取得し、その取引可否データに基づいて決済可能な限度額を特定する。そして、図示はしないが、かかる決済データで示される「決済をする金額」が、決済可能な限度額の範囲内であれば決済のための処理が可能であることを示す情報(処理可能情報)をPOS端末装置に送信するようにすることができる。一方、かかる決済データで示される「決済をする金額」が、決済可能な限度額の範囲外であれば、決済のための処理が不可能であることを示す情報(処理不能情報)をPOS端末装置に対して送信するようにすることができる。
「取引実行データ送信部0204」は、前記取引実行データ生成部で生成した取引実行データを送信する。取引実行データの送信は、赤外線通信(IrFM等)、非接触(RF)タグ、bluetoothによるPOS端末装置への送信その他、電話回線網、インターネット回線網等の通信ネットワークを介した送信等による方法を用いる場合がある。また、取引実行データの送信には、図示はしないが携帯端末装置に設けられた表示部に前記取引実行データを特定可能なバーコード形式の情報を表示させ、当該バーコード形式の情報をPOS端末装置に設けられたバーコードリーダーで読み取らせることによる情報の受け渡しを含む。
<固定端末装置>
また、本実施形態の取引システムは、携帯端末装置に代えて、固定端末装置を有する取引システムとして構成してもよい。つまり、利用者が利用する端末装置(上述の説明における「携帯端末装置」)は「携帯型」のものには限定されず、「固定型」のものであってもよい。例えば、個人宅に設置される個人用パソコン、会社のオフィスに設置される業務用パソコン等が該当する。この、固定端末装置は、前記携帯端末装置と同様に、前記取引データ送信部、前記取引可否データ受信部、前記取引実行データ生成部、前記取引実行データ送信部とからなる。前記取引データには取引予定額以外に固定端末装置を識別するための情報である固定端末識別情報(IPアドレス等を含む)を含む場合がある。また固定端末装置の「取引実行データ送信部」は、前記取引実行データ生成部で生成した取引実行データを電話回線網、インターネット回線網等の通信ネットワークを介して送信する。前記取引実行データは前記取引実行データ送信部からPOS端末装置(若しくは後述する取引サーバ)へ送信される。この場合、商品の配送情報等を取引実行データに含ますことも出来る。後述するようにPOS端末装置を取引サーバに代えて構成することで、必ずしも商品を販売等する実店舗での取引がなされない法人間の取引の決済や、ネット取引の決済等においても本実施形態の取引システムの利用が容易となる。この場合には商品の配送情報および商品のビリング情報(決済手段や伝票等に関する情報)を取引実行データに含ますことも出来る。
<POS端末装置の構成>
「POS端末装置0210」は、取引実行データ取得部0211と、決済データ生成部0212と、決済データ送信部0213とを有する。また、POS端末装置としては、具体的にはPOSシステムに対応したレジスタ(パソコンベースのものを含む)等が該当する。但し、POS端末装置は無線端末装置(PDA、携帯電話端末等)等であってもよい。
「取引実行データ取得部0211」は、前記携帯端末装置から送信された前記取引実行データを取得する。取引実行データの取得は、赤外線通信(IrFM等)、非接触(RF)タグ、bluetoothによる受信その他、電話回線網、インターネット回線網等の通信ネットワークを介した受信等による方法を用いる場合がある。また、取引実行データの取得には、図示はしないが上述のように携帯端末装置に設けられた表示部に前記取引実行データを特定可能なバーコード形式の情報を表示させ、当該バーコード形式の情報をPOS端末装置に設けられたバーコードリーダーで読み取らせることによる情報の受け渡しを含む。
「決済データ生成部0212」は、前記取引実行データ取得部0211で取得した取引実行データに基づいて決済のためのデータである決済データを生成する。
「決済データ」とは、上述のとおり、決済のためのデータである。具体的には、前記取引実行データに、クレジットシステム若しくは銀行間の振替(デビットカードを利用する場合を含む)による決済における、支払を受ける側の情報等を付加した情報である。「支払を受ける側の情報」とは、POS端末装置を管理運営する者の金融機関口座(クレジットカード加盟店の会員口座若しくは金融機関の入金口座等)に関する情報をいう。そして、決済データは、決済情報管理サーバでのみ解読可能に暗号された前記取引識別情報を含む。
つまり、「決済データ」とは、前記決済が、クレジットシステムによる決済である場合、クレジットシステムにより決済する金額、決済方法(一括、分割、リボルビングの別等)等、前記取引実行データで特定される情報に、POS端末装置を管理運営する者の金融機関の口座(クレジットカード加盟店の会員口座若しくは金融機関の入金口座等)に関する情報等を付加した情報である。また、上述のとおり、決済データには、決済情報管理サーバでのみ解読可能に暗号化された前記取引識別情報が含まれ、当該取引識別情報に基づいて、後述する決済情報管理サーバで、「クレジットカードのカード番号、カードの有効期限、前記利用者の氏名」を取得することができる。また、「クレジットシステムにより決済する金額」は、図示はしないが、POS端末装置に設けられた入力部に入力された数値により特定されるようにしてもよい。また、かかる金額は、図示はしないが、POS端末装置に設けられたバーコードリーダーを利用して、商品のパッケージに表示されたバーコード形式の情報により特定してもよい。また、かかる金額は、公共料金等の請求書に記載された請求番号をバーコードリーダーにより読み取り、又は、前記入力部に入力して、当該請求番号に基づいて後述する決済情報管理サーバのデータベースから取得するようにしてもよい。
但し、決済データは、必ずしも、前記取引実行データに他の情報を付加する必要はなく、前記取引実行データに決済のための処理に必要な情報が全て含まれていれば前記取引実行データと同一の内容を示すデータとして、前記決済データ生成部で生成するようにしてもよい。この場合の決済データも、前記取引実行データに基づいて生成される決済データに該当する。また、決済データに利用者の買物情報を含ませてもよい。かかる利用者の買い物情報は、決済情報管理サーバにて顧客分析に利用することができる。
「決済データ送信部0213」は、前記決済データ生成部0212で生成された決済データを決済情報管理サーバ0220に送信する。決済データの送信は、専用回線、インターネット回線網等の通信ネットワークを介した方法を用いる場合がある。
<取引サーバ>
また、本実施形態の取引システムは、前記POS端末装置に代えて、取引サーバ(パソコンベースのものでもよい)を有する取引システムとして構成してもよい。この取引サーバは、商品、サービスを提供する実店舗に設置される必要はなく、また、商品等を提供する場所と近接した場所に設置される必要はない。また、取引サーバは、前記POS端末装置と同様に、前記取引実行データ取得部、前記決済データ生成部、前記決済データ送信部からなる。この場合、インターネット回線網でアクセス可能なWebサイトを通じて前記利用者が携帯端末装置若しくは固定端末装置で取引サーバにアクセスできるようにする。このように構成することで、必ずしも商品を販売等する実店舗での取引がなされない法人間の取引の決済、公共料金の代金回収や各種支払の決済、ネット取引の決済等においても本実施形態の取引システムの利用が容易となる。また、前記配送情報に加えて宅配業者や運送業者の荷札情報を決済データに含ます事が出来る。又、法人間の取引の決済においては前記ビリング情報(請求書伝票等に関する情報)をもとに取引サーバにて売掛債権の消し込み処理を済ませ、入金依頼情報を決済データに含ます事も出来る。
<決済情報管理サーバの構成>
「決済情報管理サーバ0220」は、取引データ受信部0221と、取引可否データ生成部0222と、取引可否データ送信部0223と、決済データ受信部0224と、取引照合部0225と、情報蓄積部0226とを有する。
「取引データ受信部0221」は、前記携帯端末装置0200の前記取引データ送信部0201から送信された前記取引データを受信する。前記取引データの受信は、電話回線網、インターネット回線網等の通信ネットワークを介した受信等による方法を用いる場合がある。
「取引可否データ生成部0222」は、前記取引データ受信部0221で受信した取引データに基づいて前記取引可否データを生成する。
「取引可否データ」とは、上述のとおり、取引の可否を含むデータである。
図11は、本実施形態の取引システムを構成する決済情報管理サーバの機能ブロックの一例を示した図である。同図を用いて、取引可否データ生成部1122が、前記取引データに基づいて取引可否データを生成する一例について説明する。取引データには、前記取引データを送信する携帯端末装置1100を識別するための情報(携帯端末装置識別情報)等が含まれている。取引データに当該携帯端末装置識別情報が含まれる場合があることは上述したとおりである。決済情報管理サーバ1120は、前記携帯端末装置1100を識別するための情報と関連付けて、前記利用者がクレジットシステムを利用して決済する場合における「決済のための処理に必要な情報」を情報蓄積部1126(データベース)に事前に格納する。決済情報管理サーバ1120は、前記取引データに含まれる携帯端末装置1100を識別するための情報(携帯端末装置識別情報)に基づいて、当該携帯端末装置識別情報と関連付けられた当該「決済のための処理に必要な情報」を取得する。クレジットシステムによる決済における「決済のための処理に必要な情報」とは、例えば、クレジットカードのカード番号、当該カードの有効期限、当該カードを利用する前記利用者(カードの名義人)の氏名等である。そして、当該「決済のための処理に必要な情報」、及び、前記取引データに含まれる前記取引予定額とを当該クレジットカードを発行するクレジットカード会社の管理運営するサーバ等に送信する。クレジットカード会社の運営管理するクレジットカード会社サーバでは当該「決済のための処理に必要な情報」、及び、前記取引データに含まれる「前記取引予定額」とに基づいて、前記利用者が前記取引予定額を、クレジットシステムを利用して決済することができるか否かの与信処理(取引可否の判断)を行う。そして、与信処理(取引可否の判断)の結果、前記取引予定額をクレジットシステムで決済可能であると判断された場合、前記取引予定額で示される範囲内でのクレジットシステムによる決済が可能であることを示す情報(「与信結果(取引の可否)」)を決済情報管理サーバ1120に送信する。決済情報管理サーバ1120は、当該与信結果(取引の可否)を受信する。そして、決済情報管理サーバ1120の取引可否データ生成部1122は、受信した当該与信結果(取引の可否)を示すデータであって、決済のための処理に必要な情報と関連付けられた取引識別情報を含むデータである取引可否データを生成する。生成された取引可否データは、決済情報管理サーバの情報蓄積部1126(データベース)等に蓄積等されて管理される。なお、上述のとおり、同図に示すのは本実施形態の機能ブロック図の一例に過ぎず、本実施形態は、前記「決済のための処理に必要な情報」、「取引可否データ」が、同一の情報蓄積部に蓄積される態様には限定されない。また、かかる情報蓄積部を決済情報管理サーバの外部に設けるように本実施形態の取引システムを構成してもよい。
以上のプロセスで生成された取引可否データの例としては、例えば「決済可能な限度額A(450円)を、クレジットシステムBで決済することが可能である。」ことを示すと共に、取引識別情報Cを含むデータが該当する。この場合、取引可否データで示される「クレジットカードB」は、クレジットカード会社名等が該当し、当該クレジットカードのカード番号、有効期限、名義人の氏名、電話番号等の情報は一切含まれない。クレジットカード会社名は、特定の店舗で当該クレジットカード会社のクレジットカードが利用することができるか否かの判断では必要となるものの、店舗に設置されたPOS端末装置と決済情報管理サーバ若しくはクレジットカード会社の運営管理するサーバとの間の処理連携においては必要ではない。つまり、取引可否データから当該クレジットカード会社名が読み取られた場合であっても、そのクレジットカード会社名のみを利用して、第三者が無断で当該クレジットカードの情報を利用して決済することはできず、セキュリティは確保される。なお、「決済可能な限度額」は、上述のとおり、前記取引可否データに関連付けられた情報(取引データ等)に基づいて特定されるようにしてもよい」。
そして、上述のとおり、取引可否データには、決済情報管理サーバでのみ解読可能に暗号された取引識別情報が含まれる。
「取引可否データ送信部0223(図2参照)」は、前記取引可否データ生成部0222で生成された取引可否データを前記携帯端末装置0200に送信する。前記取引可否データの送信は、電話回線網、インターネット回線網等の通信ネットワークを介した送信等による方法を用いる場合がある。
「決済データ受信部0224」は、前記POS端末装置から送信された決済データを受信する。前記決済データの受信は、専用回線、インターネット回線網等の通信ネットワークを介した受信等による方法を用いる場合がある。
「取引照合部0225」は、前記決済データ受信部で受信した決済データと、前記取引可否データ送信部から送信された取引可否データとを照合する。ここでいう「前記取引可否データ送信部から送信された取引可否データ」とは、前記取引可否データ送信部0223から送信された取引可否データと同一の内容を示す取引可否データであって、決済情報管理サーバ内に存在するものを意味する。例えば、前記情報蓄積部0226に蓄積された取引可否データが該当する。また、前記照合は、決済情報管理サーバが生成した取引可否データに含まれる決済情報管理サーバのみが解読可能な暗号化された取引識別情報と、決済情報管理サーバから携帯端末装置0200及び前記POS端末装置0210を経由して送られてきた決済情報管理サーバのみが解読可能な暗号化された取引識別情報と、を解読し比較することで行う。「決済情報管理サーバから携帯端末装置0200及び前記POS端末装置0210を経由して送られ」とは、取引識別情報が、取引可否データに含まれて決済情報管理サーバ(取引可否データ送信部)から携帯端末装置に送信され、取引実行データに含まれて携帯端末装置(取引実行データ送信部)からPOS端末装置に送信され、決済データに含まれてPOS端末装置(決済データ送信部)から送信されて決済情報管理サーバ(決済データ受信部)で受信されること、即ち巡回したことをいう。また、図示はしないが、暗号化された取引識別情報の解読(復号化)は取引照合部以外の他の機能により実現し、取引照合部では復号化された取引識別情報の照合のみを行うようにしてもよい。また、図示はしないが、前記取引照合部で、前記取引識別情報を暗号化されたままの状態で比較し、前記取引可否データと前記決済データを照合するようにしてもよい。つまり、暗号化された両取引識別情報のビットデータを比較し、両者が一致するか否かに基づいて前記取引可否データと前記決済データの照合を行うようにしてもよい。
取引識別情報が、「決済情報管理サーバのみが解読可能に暗号化されている」とは、上述のとおり、当該暗号を復号して解読するための復号鍵を決済情報管理サーバ以外の他の携帯端末装置0200、POS端末装置0210等と共有しないことを意味する。従って、特殊な暗号化技術を用いた場合のみが該当することを意味するものでない。
また、前記照合は、前記取引可否データに含まれる取引識別情報と、前記決済データに含まれる取引識別情報とが同一か否かを判断することにより行われる。両取引識別情報が同一であるとの照合結果は、その取引識別情報が改竄されることなく巡回したことを示す。そして、前記取引識別情報が同一と判断された場合、その取引識別情報で識別される前記取引可否データ、及び、その取引識別情報と関連付けられている「決済のための処理に必要な情報」を利用してそのまま決済のための処理へと進められる。つまり、POS端末装置では、改めてクレジットカード等の情報を入力して、クレジットカード会社のサーバ等との間で与信処理(取引可否の確認)を行う必要がなくなり負担が軽減される。また、上述のとおり、決済のための処理に必要な情報は、決済情報管理サーバにおいてのみ、前記取引識別情報に基づいて取得等することができることから、暗号化技術のみに依存せずにセキュリティを確保することができる。
上述のように、本実施形態を取引システムとして構成した場合を中心に説明したが、上述の携帯端末装置0200(若しくは固定端末装置)、POS端末装置0210(若しくは取引サーバ)、決済情報管理サーバ0220は単独で構成されるものであってもよい。また、携帯端末装置0200において取引実行データに基づいて決済データを生成し、POS端末装置0210(若しくは取引サーバ)を経由しないで、携帯端末装置0200から直接に決済情報管理サーバ0220へ当該決済データを送出する構成も可能である。また、本明細書において「取引予定額を含む取引データ」、「取引の可否を含む取引可否データ」という記載における、当該「取引予定額」、「取引の可否」とは、それぞれの定義で示した内容(若しくは文字どおりの意味)を示すデータ(情報)であって、前記取引データ等と同様にインターネット回線網等を介して送受信可能な形式のデータ(情報)を意味するものとして説明している。
<実施形態1の処理の流れ>
図3から6は、本実施形態の処理の流れの一例を示すフローチャート図である。同図を用いて本実施形態の処理の流れの一例を説明する。本明細書に示す「処理」は、電子計算機(携帯端末装置、POS端末装置、決済情報管理サーバ、取引サーバ、固定端末装置を含む)に実行させるためのプログラムで実行することができる。また、そのプログラムは、電子計算機によって読み取り可能な記録媒体に記憶させて利用することもできる。以下の実施形態においても同様とする。
最初に、携帯端末装置における処理の流れの一例を、図3を用いて説明する。
まず、取引予定額を含む取引データを送信する(取引データ送信ステップS0301)。次に、前記ステップS0301で送信された取引データに応じて取引の可否を含む取引可否データを受信する(取引可否データ受信ステップS0302)。さらに、前記ステップS0302で受信した取引可否データに基づいて取引実行データを生成する(取引実行データ生成ステップS0303)。最後に、前記ステップS0303で生成された取引実行データをPOS端末装置に送信する(取引実行データ送信ステップS0304)。
次に、POS端末装置における処理の流れの一例を、図4を用いて説明する。
まず、取引実行データを取得する(取引実行データ取得ステップS0401)。次に、前記ステップ0401で取得した取引実行データに基づいて決済のためのデータである決済データを生成する(決済データ生成ステップS0402)。最後に、前記ステップS0402で生成された決済データを決済情報管理サーバに送信する(決済データ送信ステップS0403)。
次に、決済情報管理サーバにおける処理の流れの一例を、図5を用いて説明する。
まず、取引予定額を含む取引データを受信する(取引データ受信ステップS0501)。次に、前記ステップS0501で受信した取引データに基づいて前記取引可否データを生成する(取引可否データ生成ステップS0502)。さらに、前記ステップS0502で生成された取引可否データを送信する(取引可否データ送信ステップS0503)。さらに、前記ステップ0503で送信された取引可否データに基づいて生成された取引実行データから生成された決済のためのデータである決済データを受信する(決済データ受信ステップS0504)。さらに、前記ステップS0502で生成された前記取引可否データに含まれる暗号化された取引識別情報及び前記ステップS0504で受信した決済データに含まれる暗号化された取引識別情報を復号して解読する(取引識別情報解読ステップS0505)。最後に、前記ステップS0505で解読した、前記取引可否データに含まれる取引識別情報と、前記決済データに含まれる取引識別情報とを比較することで、前記ステップS0504で受信した決済データと、前記ステップS0503で送信された取引可否データとを照合する(取引照合ステップS0506)。
最後に、取引システムにおける処理の流れの一例を、図6を用いて説明する。
取引予定額を含む取引データを送信する(取引データ送信ステップS0601)。次に、前記ステップS0601で送信された取引データを受信する(取引データ受信ステップS0602)。さらに、前記ステップS0602で受信した取引データに基づいて前記取引可否データを生成する(取引可否データ生成ステップS0603)。さらに、前記ステップS0603で生成された取引可否データを送信する(取引可否データ送信ステップS0604)。さらに、前記ステップS0601で送信された取引データに応じて取引の可否を含む取引可否データを受信する(取引可否データ受信ステップS0605)。さらに、前記ステップS0605で受信した取引可否データに基づいて取引実行データを生成する(取引実行データ生成ステップS0606)。さらに、前記ステップS0606で生成された取引実行データを送信する(取引実行データ送信ステップS0607)。さらに、前記ステップS0607で送信された取引実行データを取得する(取引実行データ受信ステップS0608)。さらに、前記ステップS0608で受信した取引実行データに基づいて決済のためのデータである決済データを生成する(決済データ生成ステップS0609)。さらに、前記ステップS0609で生成された決済データを送信する(決済データ送信ステップS0610)。さらに、前記ステップS0610で送信された決済データを受信する(決済データ受信ステップS0611)。さらに、前記ステップS0603で生成された前記取引可否データに含まれる暗号化された取引識別情報及び前記ステップS0611で受信した決済データに含まれる暗号化された取引識別情報を復号して解読する(取引識別情報解読ステップS0612)。最後に、前記S0612で解読した、前記取引可否データに含まれる取引識別情報と、前記決済データに含まれる取引識別情報とを比較することで、前記ステップS0611で受信した決済データと、前記ステップS0604で送信された取引可否データとを照合する(取引照合ステップS0613)。
<実施形態1の効果の簡単な説明>
本実施形態の取引システムを利用することにより、クレジットシステム等による決済を、当該決済における与信処理(取引可否の確認)のための負担を店舗側にかけることなく、かつ、暗号化技術のみに依存せずにセキュリティを確保して行うことができる。
<<実施形態2>>
<実施形態2の概念>
本実施形態は、上述の実施形態1の構成を基本とし、さらに前記決済情報管理サーバが、決済金額判断部を有する。そして、前記決済金額判断部が期間集計手段、金額集計手段の一方若しくは双方、並びに、処理データ構成手段を有する取引システムである。本実施形態に係る取引システムは、特に小額の取引の決済を個別に処理する煩雑さを解消するため、決済情報管理サーバ(又はその他の装置、サーバ等)で決済のための処理をまとめて行うことができるようにした。具体的には、一定の金額若しくは一定の期間を基準に前記決済データを集計し、1のトランザクションとして処理するための取引システムとして構成した。
図7は本実施形態の概念の一例を示す図である。同図を用いて本実施形態の概念の一例を説明する。
同図(a)に示すように、利用者は、1月1日に、商業店舗で350円の商品Aを自身の携帯電話を利用してクレジットシステムにより決済するために、携帯電話を利用して決済情報管理サーバに当該350円を決済可能であるか否かを確認した。決済情報管理サーバからは、350円分の決済が可能であることを示す取引可否データAが送信され、利用者は携帯電話でこれを受信し、当該取引可否データAに基づいて生成された取引実行データAをPOS端末装置に送信した。POS端末装置はこれを受信し、決済のためのデータである決済データAを生成して送信し、決済情報管理サーバはこれを受信した。
利用者は、同じ商業店舗で、1月5日には400円の商品Bの買い物をし、1月10日には450円の商品Cの買い物をした。商品B,Cの買い物の決済は、いずれも商品Aの購入時と同様に携帯電話を利用したクレジットシステムによる決済で行った。
決済情報管理サーバでは、1月5日には商品Bの決済のための決済データB受信し(同図(b)参照)、さらに、1月10日には商品Cの決済のための決済データCを受信した(同図(c)参照)。そして、決済情報管理サーバは、1/1〜1/10までに受信した決済データA,B,Cを期間集計して、決済データA,B,Cで特定される1200円分の決済を1のトランザクションとして処理するためのデータである処理データを再構成した。
<実施形態2の構成>
図8は本実施形態の機能ブロック図の一例を示すである。同図を用いて本実施形態の構成の一例を説明する。
本実施形態は、前記実施形態1の構成を基本とし、さらに決済金額判断部0827を有し、前記決済金額判断部0827が、期間集計手段0827a、金額集計手段(1027a:図10参照)の一方若しくは双方と、処理データ構成手段0827bと、を有する取引システムである。
携帯端末装置0800(若しくは固定端末装置)の取引データ送信部0801、取引可否データ受信部0802、取引実行データ生成部0803、取引実行データ送信部0804と、また、POS端末装置0810(若しくは取引サーバ)の取引実行データ取得部0811、決済データ生成部0812、決済データ送信部0813と、また、決済情報管理サーバ0820の取引データ受信部0821、取引可否データ生成部0822、取引可否データ送信部0823、決済データ受信部0824、取引照合部0825、情報蓄積部0826は、実施形態1と対応する部分は共通するので説明を省略する。
「決済金額判断部0827」は、前記取引照合部0825における前記取引識別情報の照合結果が同一である場合に、その取引識別情報を含む決済データで示される金額(決済をする金額)が、予め定められた金額を超えるか否かを判断する。かかる決済金額判断部0827における当該判断は、後述する期間集計手段0827a若しくは金額集計手段(図10の1027a参照)により集計すべぎ決済データに該当するか否かの峻別のために行われる。予め定められた金額を「超える」とは、「以上である」との意で用いてもよい。
「決済金額判断部0827」は、さらに、期間集計手段0827a、金額集計手段(図10の1027a参照)の一方若しくは双方を有する。
「期間集計手段0827a」は、前記決済金額判断部0827で、前記決済データで示される金額(決済をする金額)が予め定められた金額を超えないと判断した場合に、前記決済データを期間集計する。期間集計手段によって集計される決済データは、当該決済データに含まれる取引識別情報に関連付けられた「決済のための処理に必要な情報」等が同一であることを特徴とする。例えば、決済に利用されたクレジットカード(若しくはデビットカード)の番号が同一であり、かつ、当該決済における受取人(決済データで特定されるPOS端末装置の管理運営者)の金融機関の口座(クレジットカード加盟店としての口座を含む)が同一である決済データが期間集計手段によって集計される。
前記期間集計手段0827aによる決済データの集計の一例について説明する。例えば、前記「予め定められた金額」を「500円」等の小額に設定し、1単位の取引として決済するのに適当な金額を「2000円」とした場合を考えてみる。この場合、例えば、当該取引が週1回行われることが予想される場合、決済データを集計すべき期間を4週間と予め定める。そして、前記決済データ受信部0824で受信されて、前記決済金額判断部0827で予め定めた「500円」の金額を超えないと判断された決済データについて、予め定められた「4週間の期間」内の決済データを前記期間集計手段0827aで期間集計する。
また、本実施形態の取引システムは、前記決済金額判断部0827に設けられた前記期間集計手段0827aに代えて、金額集計手段を設けるように、又は前記両手段を併せ持つように構成してもよい。図10は前記期間集計手段を、金額集計手段に代えて構成した取引システムの機能ブロックの一例を示す図である。
「金額集計手段1027a」は、前記決済金額判断部1027で、前記決済データで示される金額(決済をする金額)が予め定められて金額を超えないと判断された場合に、予め定められた金額に達するまで前記決済データを集計する。
例えば、上述同様に、前記決済金額判断部1027で予め定められる金額を「500円」等の小額に設定し、1単位の取引として決済するのに適当な金額を「2000円」とした場合を考えてみる。この場合、前記決済データを集計すべき基準となる金額を「2000円」と予め定める。そして、前記決済金額判断部1027で予め定めた「500円」の金額を超えないと判断された決済データについて、予め定められた「2000円」の金額に達するまで、前記金額集計手段1027aで前記決済データを集計する。
「処理データ構成手段(図8の8027b、図10の1027b)」は、前記期間集計手段(図8の8027a)若しくは前記金額集計手段(図10の1027a)で集計された前記決済データを1のトランザクションとして処理するための処理データに再構成する。
「処理データ」とは、上述のとおり集計した決済データを1のトランザクションとして処理するために再構成したデータである。また、処理データは、集計した各決済データで示される「決済をする金額」の合計額を示す。
例えば、350円の決済のための決済データAと、400円の決済のための決済データと、450円の決済のための決済データとを期間集計した場合、これら決済データA,B,Cが示す合計額である1200円の決済のためのデータとして処理データを再構成する。この場合、図示はしないが、決済のための処理を行う決済処理部において、その「1200円」の決済のための処理を1のトランザクションとして行うことができる。その理由は、上述のとおり、期間集計手段(図8の8027a)若しくは金額集計手段(図10の1027a)で集計される決済データに含まれる取引識別情報に基づいて取得可能な「決済のための処理に必要な情報」等が同一だからである。「決済のための処理に必要な情報」等が同一であるということは、決済データA,B,Cに基づいて取得される決済に利用された「クレジットカード情報(若しくはデビットカード情報)」が同一であり、かつ、当該決済における受取人(決済データで特定されるPOS端末装置の管理運営者)の金融機関の口座(クレジットカード加盟店としての口座を含む)が同一であることを示す。つまり、決済データA,B,Cで特定される決済における、支払者側と受取人側が同一であるため、これらの決済のための処理をまとめて1のトランザクションとして行うことが可能となる。
<実施形態2の処理の流れ>
図9は本実施形態の処理の流れの一例を示すフローチャート図である。同図を用いて本実施形態の処理の流れの一例を説明する。
まず、取引予定額を含む取引データを受信する(取引データ受信ステップS0901)。次に、前記ステップS0901で受信した取引データに基づいて取引の可否を含む取引可否データを生成する(取引可否データ生成ステップS0902)。さらに、前記ステップS0902で生成された取引可否データを送信する(取引可否データ送信ステップS0903)。さらに、前記ステップ0903で送信された取引可否データに基づいて生成された取引実行データから生成された決済のためのデータである決済データを受信する(決済データ受信ステップS0904)。さらに、前記ステップS0901で生成した取引可否データに含まれる暗号化された取引識別情報と、前記ステップS0904で受信した決済データに含まれる暗号化された取引識別情報を復号して解読する(解読ステップS0905)。さらに、前記ステップS0905で解読した取引識別情報を比較して比較することで、前記ステップS0904で受信した決済データと、前記ステップS0903で送信された取引可否データとを照合する(照合ステップS0906)。さらに、前記照合ステップS0906における照合の照合結果が同一である場合、その取引識別情報を含む決済データが予め定められた金額を超えるか否かを判断する(金額判断ステップS0907)。さらに、前記ステップS0907で、予め定められた金額を超えないと判断された決済データを期間集計する(期間集計ステップS0908)。最後に、前記ステップ0908で期間集計した決済データを1のトランザクションとして処理するための処理データとして再構成する(処理データ再構成ステップS0909)。
<実施形態2の効果の簡単な説明>
本実施形態の取引システムを利用することにより、小額の決済のための決済データそれぞれに基づいて決済のための処理を個別にする必要が必ずしもなくなるため、決済のための処理が効率的になる場合がある。上述のとおり、一定の条件を満たす決済データを一定の期間、若しくは一定の金額を基準として集計して1のトランザクションとして処理することができるからである。
また、例えば、コンビニエンスストア等における小額の決済をクレジットシステムにより行うことを促進させるためにクレジットカード会社、コンビニエンスストアが本実施形態の取引システムを利用すると特に便利である。小額の決済において、決済データごとに決済のための処理を行うと、それぞれの処理ごとにクレジットシステムを利用するための最低手数料が発生してしまう。そして、その最低手数料の合計額が、全ての決済データで示される総決済額で決済していたならば発生したであろう手数料を上回る場合がある。加盟店は、このように決済額に対する手数料の比率が大きくなることをきらい、小額の決済をクレジットシステムにより行うことを避ける場合がある。一方、クレジットカード会社は、かかる小額決済を個別に処理する場合、各処理ごとに費用が発生してしまうため、上述のように最低手数料を取らなければ採算があわない。なぜなら、各処理ごとに、上述した「CAFIS(登録商標)」等の決済専用の通信回線を介して、決済のための処理に必要なデータを店側とクレジットカード会社の間で送受信しなければならないからである。つまり、各処理の度に当該通信回線の使用料等が発生してしまうからである。この点、本願発明の取引システムを利用すれば、当該専用の通信回線を使用するのは決済情報管理サーバとクレジットカード会社のサーバ等との間のみで済む。また、上述のとおり決済データを集計して処理を行うので、通信の回数も少なくて済む。つまり、上述のように通信料が多くかかるという問題は発生しない。しかも加盟店サイドのPOS端末装置にて決済データを蓄積し一定の量又は時間にて一括送信処理を行う方法をとれば更に通信料を削減することが出来、本実施形態においてもそれを可能にしている。従って、本願発明の取引システムを利用すれば、クレジットカード会社等が負担する通信料等が軽減される。そして、クレジットカード会社は、利用者から取る手数料を軽減することもできる。このように、本願発明の取引システムは、双方にとってメリットのあるシステムであるといえる。
<<実施形態3>>
<実施形態3の概念>
図12は本実施形態の概念の一例を示す図である。同図を用いて本実施形態の概念の一例を説明する。
本実施形態は、上述の実施形態1の構成を基本とし、さらに、前記取引実行データ生成部が、前記取引可否データ受信部で受信した一の取引可否データに基づいて複数の取引実行データを生成することが可能である取引システムである。
つまり、同図に示すとおり、(1)クレジットカード等の利用者は、予め自身が利用する携帯端末装置(若しくは固定端末装置)を利用して、ある額(例えば2000円)をクレジットシステム等により決済可能であるかどうかの与信処理の結果(取引の可否)を含む取引可否データAを受信する。そして、当該取引可否データAの受信後は、一の取引可否データAが示す決済可能な限度額(2000円)の範囲内で、当該取引可否データAを利用して買い物等ができる。例えば、当該一の取引可否データAに基づいて、(2)特定の店(A店)において「決済をする金額が800円」であることを示す取引実行データを生成してPOS端末に送信して、800円の商品Aを購入できる。さらに、(3)別の店(B店)において「決済をする金額が700円」であることを示す取引実行データを生成してPOS端末装置に送信して、700円の商品Bを購入できる。さらに、(4)別の店(C店)において「決済をする金額が500円」であることを示す取引実行データを生成してPOS端末装置に送信して、500円の商品Cを購入できる。つまり、本願発明の取引システムの携帯端末装置の利用者は、決済の度に上記与信処理の結果を含む取引可否データを受信しなくてすむので便利である。
<実施形態3の構成>
図13は本実施形態の機能ブロックの一例を示す図である。同図を用いて本実施形態の概念の構成の一例を説明する。
上述のとおり、本実施形態は、上述の実施形態1の構成を基本とし、さらに、前記取引実行データ生成部が、前記取引可否データ受信部で受信した一の取引可否データに基づいて複数の取引実行データを生成することが可能である取引システムである。
携帯端末装置1300(若しくは固定端末装置)の取引データ送信部1301、取引可否データ受信部1302、取引実行データ生成部1303、取引実行データ送信部1304と、また、POS端末装置1310(若しくは取引サーバ)の取引実行データ取得部1311、決済データ生成部1312、決済データ送信部1313と、また、決済情報管理サーバ1320の取引データ受信部1321、取引可否データ生成部1322、取引可否データ送信部1323、決済データ受信部1324、取引照合部1325、情報蓄積部1326については、基本とする実施形態1の対応する部分と同様であるので、共通する部分の説明は省略する。なお、同図においては、POS端末装置、決済情報管理サーバの各構成における処理等の対象となる取引データ、取引可否データ、取引実行データ、決済データの図示は省略する。
<取引実行データ生成部について>
「前記取引実行データ生成部1303」は、前記取引可否データ受信部で受信した一の取引可否データに基づいて複数の取引実行データを生成することが可能である。例えば、同図に示すとおり、前記取引実行データ生成部1303で、一の取引可否データに基づいて3つの取引実行データA、B、Cを生成することができる。
つまり、当該複数の取引実行データA、B、Cの各々が示す「決済をする金額」の合計が、前記取引可否データで示される決済可能な限度額を超えない範囲で、前記取引可否データに基づいて複数の取引実行データを前記取引実行データ生成部1303で生成することができる。そして、前記取引実行データ生成部1303で生成される当該複数の取引実行データA、B、Cの各々が示す「決済をする金額」の合計が、当該取引可否データで示される決済可能な限度額に達すると、当該取引可否データに基づいて取引実行データの生成はできなくなる。以下、一の取引可否データに基づいて複数の取引実行データを生成する具体例の一例を説明する。
取引可否データに基づいて取引実行データが生成されると、当該取引可否データに基づいてさらに生成可能な取引実行データの内容が、次に示す「残取引可能金額情報」に基づいて限定される。「残取引可能金額情報」とは、前記取引可否データが示す「決済可能な限度額」から、前記取引実行データが示す「決済をする金額」を差し引いた金額に関する情報をいう。
図18は、前記残取引可能金額情報を利用して、一の取引可否データに基づいて複数の取引実行データを生成する具体例の一例を示す図である。同図を用いて、取引実行データ生成部における取引実行データの生成の一例を説明する。
取引可否データが「取引予定額2000円を、クレジットシステムXで決済することが可能である。」こと等を示すデータである場合を例に考えてみる。当該取引可否データに基づいて、「決済をする金額が800円であることを示す取引実行データA」を生成する。そして、かかる取引実行データの生成と同時に、若しくはその前後で、当該取引可否データに基づいて残り1200円の「決済をする金額」を示す取引実行データが生成可能であることを示す残取引可能金額情報Aが前記取引実行データ生成部で生成され、前記取引可否データと関連付けられて蓄積部に蓄積される(同図(A)参照)。
そして、取引実行データ生成部で、今度は、当該取引可否データ及び前記残取引可能金額情報Aに基づいて、決済をする金額が700円であることを示す取引実行データBを生成する(同図(B)参照)。新たに生成可能な取引実行データの「決済をする金額」は、当該取引可否データで示される決済可能な限度額(2000円)の範囲であって、かつ、当該残取引可能金額情報Aで示される決済可能な限度額(1200円)の範囲に限定される。つまり、取引実行データBで示される「決済をする金額」は「1200円」の範囲に限られる。そして、当該残取引可能金額情報Aが「決済可能な限度額500円を示す残取引可能金額情報B」に更新される。
そして、さらに、取引実行データ生成部で、当該取引可否データ及び残取引可能金額情報Bに基づいて「決済をする金額が500円であることを示す取引実行データC」を生成する(同図(C)参照)。そして、当該残取引可能金額情報Bが「決済可能な限度額0円を示す残取引可能金額情報C」に更新される。こうして当該残取引可能金額情報で示される決済可能な限度額が0円になるまで、当該一の取引可否データに基づいて複数の取引実行データA、B、Cを生成することが可能である。
これらの処理は、上述に示す「前記取引可否データ受信部で受信した一の取引可否データに基づいて複数の取引実行データを生成する」という処理に含まれる。
また、図示はしないが、かかる残取引可能金額情報と関連付けられた取引可否データは、携帯端末装置内のメモリ等に蓄積される。若しくは、かかる残取引可能金額情報は、取引実行データ生成部で生成された後、携帯端末装置から決済情報管理サーバに送信されて決済情報管理サーバで蓄積等されて管理され、再度、前記取引可否データに基づいて取引実行データを生成する際に、携帯端末装置が決済情報管理サーバから受信するようにしてもよい。なお、この残取引可能金額情報が携帯端末装置と決済情報管理サーバとの間でやりとりされても、当該情報自体は個人情報を示すものではなく、本実施形態の取引システムにおいても個人情報が漏洩することはない。
<取引可否データに基づいて複数の取引実行データが生成可能となることの利点>
上述のように、本実施形態では、一の取引可否データに基づいて複数の取引実行データを生成することが可能であり、その利点は、当該取引可否データ、取引実行データを、いわゆる電子マネー的に利用することが可能となる点である。電子マネーとは「電子情報のやりとりによって決済を完了させるシステムの総称である電子マネーシステムにおける当該電子情報」をいう。電子マネーは、電子情報でありながら、現金と同様の自由度をもって決済に利用することができる。そして、本実施形態の取引システムに利用する取引可否データは、取引の度に携帯端末装置(の取引可否データ受信部)で受信する必要がない。本実施形態の取引システムでは、一度携帯端末装置(取引可否データ受信部)で取引可否データを受信すれば、その決済可能な限度額の範囲で、当該取引可否データを現金と同様の自由度をもって決済のための処理に利用することが可能となる。この点で、前記取引可否データを電子マネー的に利用することが可能であるといえる。
電子マネーシステムは、一般的に、「プリペイドカード応用型」「クレジットカード応用型」「預金通貨利用型」「現金通貨型」に大きく分けられる。そして、前記取引可否データ等を利用する本実施形態は、クレジットシステムによる決済に利用する場合、この電子マネーシステムでいうところの「クレジットカード応用型」「現金通貨型」の利点を有する。また、本実施形態は、銀行間の振替(デビットカードを利用する場合を含む)による決済に利用する場合、電子マネーシステムでいうところの「預金通貨利用型」「現金通貨型」の利点を有する。そして、いずれの場合も、これら電子マネーシステムの各方式の有する欠点を有しない点で、これら各電子マネーシステムより優れているといえる。
前記「クレジットカード型の利点」は、既存のクレジットカード決済用の通信網が利用可能であり実用化の可能性が高く、決済可能な限度額が利用者の実際の預金額に限定されない点で利用者にとって利便性が高い点である。また、「現金通貨型の利点」は、決済の匿名性を確保できる点である。また、「預金通貨利用型」の利点とは、比較的簡易な技術的仕組み(銀行の帳簿の書き換え等)で実用化できる点である。また、必ずしも専用の機器を用いる必要がなく、個人のパソコン等からの操作で実現できる点である。
また、「プリペイドカード応用型の欠点」は、コンビニエンスストア等における事前購入の手間がかかる点である。また、「クレジットカード応用型の欠点」は、個人情報の漏洩の可能性あり、決済の匿名性が確保できない点である。また、「預金通貨利用型の欠点」は、決済可能金額が預金額等に限定される点である。また、「現金通貨型」の欠点は、金銭価値を化体させた電子マネー(電子情報)の真正性の確保するための技術的仕組みの構築等の困難性、即ち実用化の困難性がある点である。
電子マネーシステムにおいては、上述の方式のうち、特に「クレジットカード応用型」の実用化が進められているが、上述のとおり、「個人情報の漏洩」等が問題となって真に信頼性の高いシステムは未だに構築されていない。この点、本願発明では、基本とする実施形態1で示したとおり、携帯端末装置、POS端末装置、決済情報管理サーバ間においてはクレジットカード番号等の個人情報はやりとりされない。これらの装置間等でやりとりされるのは個人情報を含まない取引可否データ等のみである。そして、クレジットカード番号等の個人情報は、管理サーバでのみ管理されるので個人情報の漏洩のおそれはなく、また、決済の匿名性が確保される。
なお、上述の電子マネーの「プリペイドカード応用型」の実例としては「VISA Cash(登録商標)」等あり、また、「クレジットカード応用型」の実例としては「Commerce Net」等があり、また、「預金通貨利用型」の実例としては「Financial Service Technology Consortium」等があり、また「現金通貨型」の実例としては「Mondex(登録商標)」等がある。
<実施形態3の処理の流れ>
図14は、本実施形態の処理の流れの一例を示すフローチャート図である。同図を用いて本実施形態の処理の流れの一例を説明する。
まず、取引予定額を含む取引データを送信する(取引データ送信ステップS0401)。次に、前記ステップS1401から送信された取引データに応じて取引の可否を含む取引可否データを受信する(取引可否データ受信ステップS1402)。さらに、前記ステップS1402で受信した取引可否データに基づいて、当該取引可否データで示される決済可能な限度額に満たない金額(決済をする金額)を示す取引実行データを生成する。(取引実行データ生成ステップS1403)。さらに、前記ステップS1403で生成された取引実行データをPOS端末装置に送信する(取引実行データ送信ステップS1404)。さらに、前記取引可否データで示される取引可能な限度額から、前記取引実行データで示される決済をする金額を差し引いた額に関する情報である残取引可能金額情報を前記取引可否データに関連付けて蓄積する(残取引可能金額情報関連付けステップS1405)。さらに、前記取引可否データで示される決済可能な限度額の範囲であって、かつ、前記残取引可能金額情報で示される決済可能な限度額の範囲で示される金額(決済をする金額)を示す取引実行データを生成する(再取引実行データ生成ステップS1406)。
<実施形態3の効果の簡単な説明>
本実施形態を利用することにより、利用者の預金額に必ずしも限定されずに、商品の購入代金等の決済のための処理を簡易に行うことができるようになる。また、決済の匿名性を確保して決済のための処理を行うことが可能となる。さらに、個人間取引の決済のための処理も簡易に行うことができる。
<<実施形態4>>
<実施形態4の概念>
図15は本実施形態の概念の一例を示す図である。同図を用いて本実施形態の概念の一例を説明する。
本実施形態は、上述の実施形態1から3の構成を基本とし、さらに、前記携帯端末装置が、他の電子機器に抜差し可能なチップ型電子機器(ICカード等)である取引システムである。
同図に示すように、電車運賃の自動清算式の改札で利用できる電車運賃清算用プリペイドカード(ICカード:チップ型電子機器)を有する利用者が、電車運賃用プリペイドカードチャージ機器にて当該ICカード(チップ型電子機器)に電車運賃利用分の金額情報をチャージした。そして、当該利用者は、当該ICカード(チップ型電子機器)で電車運賃を精算した。
さらに、当該利用者は、「取引可否データ」を、自身の携帯電話等を利用してサーバより受信し、当該ICカード(チップ型電子機器)に格納した。かかる取引可否データは、利用者がクレジットシステムを利用して、800円を決済可能な限度額として決済のための処理を行うことができることを示すものであった。そして、当該利用者は、800円の商品Aを購入するため、当該ICカード(チップ型電子機器)に格納した取引可否データに基づいて、商品の代金に相当する額の「決済をする金額(800円)」を示す取引実行データを生成し、店のPOS端末装置に送信した。当該利用者は、前記取引実行データを店のPOS端末装置に送信することで商品Aの代金の清算を済ませた。このように、当該ICカード(チップ型電子機器)はクレジットカード代わりに利用することもできた。
現在では、電車の運賃の精算等、いわゆる決済(取引)のためのシステムにICカードが広く利用されている。当該ICカードとしては、例えば、JR東日本(西日本)が運用する「SUICA(登録商標)」等が該当する。そして、ICカードに、本願発明のチップ型電子機器の機能を加えればさらに便利となる。つまり、一のICカードに多くの決済機能を集約できる。そこで、本実施形態を構成する携帯端末装置を、上述のICカードのような態様としても利用できるように「チップ型電子機器」として構成した。また、かかるチップ型電子機器がカード型であれば、利用者は財布に保管して持ち運びできるので便利である。
<実施形態4の構成>
図16は本実施形態の機能ブロック図の一例を示す図である。同図を用いて本実施形態の構成の一例を説明する。
本実施形態は、上述のとおり、実施形態1から3の構成を基本とし、さらに、前記携帯端末装置が、他の電子機器に抜差し可能なチップ型電子機器(ICカード等)である取引システムである。POS端末装置1610(若しくは取引サーバ)の取引実行データ取得部1611、決済データ生成部1612、決済データ送信部1613と、また、決済情報管理サーバ1620の取引データ受信部1621、取引可否データ生成部1622、取引可否データ送信部1623、決済データ受信部1624、取引照合部1625、情報蓄積部1626については、基本とする実施形態1等の対応する部分と同様であるので、共通する部分の説明は省略する。
<チップ型電子機器、他の電子機器について>
「チップ型電子機器1600」は、基本とする実施形態1の携帯電話に代わって本実施形態の取引システムを構成する一部の構成要素であり、他の電子機器に抜差し可能な電子機器である。そして、このチップ型電子機器、及び、他の電子機器の双方で、基本とする実施形態1の携帯端末装置の機能と同様の機能を実現する。例えば、チップ型電子機器1600は、同図に示すとおり、基本とする実施形態1の取引システムを構成する携帯端末装置の有する機能のうち、取引実行データ生成部1603、取引実行データ送信部1604を有する。そして、基本とする実施形態1の取引システムを構成する携帯端末装置の有する他の機能は、前記チップ型電子機器を抜差し可能な前記他の電子機器が有する。つまり、同図に示すとおり、前記取引データ送信部1601、取引可否データ受信部1602は、前記他の電子機器が有するように構成している。前記他の電子機器としては、携帯電話、PDA、パソコン等が該当する。
また、図示はしないが、前記チップ型電子機器が、前記取引データ送信部1601、取引可否データ受信部1602、取引実行データ生成部1603、取引実行データ送信部1604を全て有するように、若しくはいずれか一又は二以上の機能を有するように構成してもよい。従って、前記他の電子機器が、前記取引データ送信部1601、取引可否データ受信部1602、取引実行データ生成部1603を有し、そして、前記チップ型電子機器が前記取引実行データ送信部1604を有するように本実施形態の取引システムを構成することもできる。
チップ型電子機器としては、具体的には、ICカード、通信機能付電子メモリ等が該当する。ICカードは、いわゆる接触型、非接触型のいずれの形式であってもよい。通信機能付電子メモリとは、通信モジュール、即ち、RF回路とベースバンド回路に、情報記憶装置を一体化させた電子機器等が該当する。当該通信モジュールによる通信は、いわゆる電話回線網を利用するものには限定されず、基本とする実施形態1の携帯端末装置の取引実行データ送信部同様に、赤外線通信(IrFM等)、非接触(RF)タグ、bluetoothによる送信その他、インターネット回線網等の通信ネットワークを介した送信等による方法を用いることもできる。また、当該通信モジュールによる通信には、図示はしないがチップ型電子機器に設けられた表示部に前記取引実行データを特定可能なバーコード形式の情報を表示させ、当該バーコード形式の情報をPOS端末装置に設けられたバーコードリーダーで読み取らせることによる情報の受け渡しを含む。
上述のチップ型電子機器、他の電子機器の機能は、ハードウエア的に構成してもよく、また、ソフトウエア的に構成してもよい。当該機能をソフトウエア的に構成する場合、当該機能を実現するプログラムは、前記決済情報管理サーバから、前記他の電子機器、前記チップ型電子機器にダウンロードできるようにするとよい。
前記チップ型電子機器1600を、ICカードの機能を利用して構成した場合における、前記「取引実行データ生成部1603」は、ICカードの情報処理機能を実現する構成(ICカードのマイコン部の「CPU」等)と同じように構成することができる。
また、上述のとおり、前記チップ型電子機器の有する「取引実行データ送信部1604」は、非接触(RF)タグを利用した通信方式により前記取引実行データを前記POS端末装置1610に送信することができる。つまり、チップ型電子機器は非接触型ICカードによるデータ通信と同じようにデータ(取引実行データ)を送信することができる。この場合、前記チップ型電子機器の有する前記取引実行データ送信部1604は、ICカードのデータ送受信機能を実現する構成(「RF−IC」等)と同じように構成することができる。
また、図示はしないが、前記チップ型電子機器には、前記取引実行データを蓄積する機能(チップ型電子機器蓄積部)を設けてもよい。この場合、当該蓄積機能(チップ型電子機器蓄積部)は、ICカードの情報記憶機能(ICカードのマイコン部の「EEPROM:電気的書き換え可能ROM」等)を実現する構成と同じように構成により実現することができる。
上述のとおり、ICカードは、非接触型の形式のものであってもよい。つまり、電磁誘導等によりリーダ・ライタ(本実施形態ではPOS端末装置に相当するもの)と直接接することなく(非接触で)データの送受信を行うことができる。かかる非接触型のICカードには、前記リーダ・ライタと数mm程度間隔で情報のやり取りが可能な「密着型ICカード」とそれ以上の間隔でも情報のやり取りが可能な「リモート式ICカード」があるが、前記チップ型電子機器はいずれの形式のICカードを利用するものであってもよい。
ICカードの機能は上述のとおり電車の運賃清算等、いわゆる決済(取引)のためのシステムに広く利用されている。従って、チップ型電子機器の利用者が既にICカードを所有している場合、当該ICカードの機能に、前記取引実行データ生成部1603、前記取引実行データ送信部1604等の機能を加えて前記チップ型電子機器として構成することができる。
また、前記チップ型電子機器に利用するICカードが有する決済機能として「電車の運賃の精算機能」を例示したが、ICカードの有する決済機能はかかる機能には限定されず、例えばETC(有料自動車道の自動料金収受システム)に利用するETCカードの決済機能等であってもよい。また、前記チップ型電子機器として、本実施形態の取引システムに専用のICカードを利用できることはいうまでもない。
また、チップ型電子機器は、前記ICカードは携帯電話、PDAに組み込まれてもよく(この場合、当該携帯電話、PDAを前記他の電子機器とすることができる)、また、衣服、鞄、財布、メガネ、時計等に貼付等してもよい。
また、チップ型電子機器はICカード類似のものには限定されず、「フラッシュメモリ」等の情報を読み出し可能に記録等する機能を主とするものであって、通信機能を有するものも含まれる。
また、チップ型電子機器は、指紋認証等、バイオメトリクス方式の認証機能を持たせてもよい。
なお、ICカードは「物理的に複製することが非常に困難であり、カード内部へのアクセスが難しく、データの改竄や盗み見が難しい。」という特徴があり、一般的にセキュリティが高いと言われているが、カード内部への不正アクセスを完全に排除できるものではない。従って、クレジットカードの番号を直接ICカードに記憶させて利用する場合、当該情報が不正に取得される危険性がなおある。この点、本実施形態の取引システムにおいては、チップ型電子機器としてICカードを利用した場合でも、当該ICカードにはクレジットカード番号の個人情報は記憶させないため、ICカードの情報が万が一不正に取得されても個人情報の漏洩の心配はない。
決済のためのシステムに利用されるICカードとしては、ソニー株式会社の開発したICカード「Felica(登録商標)」が知られ、上述に示したとおり、実際に電車運賃精算用のカード「SUICA(登録商標)」として利用されている。
しかし、かかるICカード「Felica(登録商標)」を利用した現行の決済システムにおいては、当該ICカード自体に、クレジットカードの番号等を暗号化(共通鍵方式)して記憶させ、若しくは、直接金銭的な価値を有する電子マネー等を記憶させている。従って、そのICカードのセキュリティは暗号技術に依存する。この問題点を解消するため、NTTグループにおいては、一般的に暗号化技術の中でもセキュリティが高いと言われている公開鍵方式を利用する提案もなされている。しかし、かかる仕組みもやはり暗号化技術の限度でしかセキュリティが確保されない。
<決済情報管理サーバについて>
上述の実施形態1で説明したとおり、決済情報管理サーバ1620は、前記携帯端末装置を識別するための情報(携帯端末識別情報)と関連付けて、前記利用者のクレジットカード情報を利用したクレジットシステムによる「決済のための処理に必要な情報」を情報蓄積部1626(データベース)に事前に格納する。本実施形態の場合、前記携帯端末装置が「チップ型電子機器」であるため、決済情報管理サーバの前記情報蓄積部においては、「前記チップ型電子機器を識別するための情報(チップ型電子機器識別情報)」と前記「決済のための処理に必要な情報」を関連付けて蓄積するようにしてもよい。この場合、前記取引データには、当該チップ型電子機器識別情報が含まれるようにすることができる。そして、決済情報管理サーバ1620は、前記取引データに含まれるチップ型電子機器識別情報に基づいて、当該チップ型電子機器識別情報と関連付けられた当該「決済のための処理に必要な情報」を取得する。クレジットシステムによる「決済のための処理に必要な情報」等については上述の実施形態1で説明したとおりであるので説明を省略する。また、前記「携帯端末識別情報」は、前記他の電子機器(携帯電話を含む)を識別するための情報であってもよい。
<実施形態4の処理の流れ>
図17は本実施形態の処理の流れの一例を示すフローチャート図である。同図を用いて本実施形態の処理の流れの一例を説明する。
まず、取引予定額を含む取引データを送信する(取引データ送信ステップS0701)。次に、前記ステップS1701で送信された取引データに応じて取引の可否を含む取引可否データを受信する(取引可否データ受信ステップS1702)。さらに、前記ステップ1702で取得した取引可否データを他の電子機器に抜差し可能なチップ型電子機器に蓄積する(取引可否データ蓄積ステップ1703)。さらに、前記ステップ1703で蓄積した取引可否データに基づいて取引実行データを生成する(取引実行データ生成ステップ1704)。さらに、前記ステップ1704で生成した取引実行データを前記チップ型電子機器に蓄積する(取引実行データ蓄積ステップ1705)。最後に、前記ステップ1705で蓄積した取引実行データをチップ型電子機器からPOS端末装置に非接触(RF)タグを利用した通信方式により送信する(取引実行データ送信ステップ1706)。
<実施形態4の効果の簡単な説明>
本実施形態の取引システムを利用することにより、既に何かしらの決済のシステムに利用されているICカード等に本実施形態のチップ型電子機器の機能を加えることで、多くの決済機能を一のチップ型電子機器(ICカード等)に搭載することができる。また、本実施形態の取引システムに専用のチップ型電子機器(ICカード等)を利用した場合でも、いわゆる携帯電話等に比べて持ち運びが便利となる。
The relationship between the embodiment and the claims is as follows. The first embodiment mainly relates to claims 1, 4 to 14 and the like.
The second embodiment mainly relates to claims 15, 16 and the like.
The third embodiment mainly relates to claims 2 and the like.
The fourth embodiment mainly relates to claims 3 and the like.
Hereinafter, an example of an embodiment of the present invention will be described with reference to FIGS. 1 to 18.
<<Embodiment 1>>
<Concept of Embodiment 1>
This embodiment exemplifies a mechanism that enables payment by a credit system or the like using a mobile terminal device typified by a mobile phone. In addition, the present embodiment is a mechanism that can ensure security without particularly burdening the store for credit processing (confirmation of transaction availability) in the settlement and without relying only on encryption technology. It has become. Then, as an application example thereof, a mechanism of using a fixed terminal device in place of the mobile terminal device and a mechanism of using a transaction server in place of the POS terminal device are mentioned.
FIG. 1 is a diagram illustrating an example of the concept of the first embodiment. An example of the concept of this embodiment will be described with reference to FIG.
Credit card users used the credit system to settle the products purchased at commercial stores. The price of the product was 450 yen. At that time, the credit card was not directly presented at the commercial store. Instead, you can use your own mobile phone to check whether you can settle a product for 500 yen in advance based on the information of the credit card you use, that is, to confirm the transaction (credit processing). Requested to the settlement information management server by communication (transmitted transaction data) (1). The payment information management server confirmed by inquiry to the server of the credit card company used by the user whether or not the user can make a payment for 500 yen (2). The payment information management server stores transaction identification information that is data indicating that payment for 500 yen is possible (data including whether or not the transaction is possible) and that is encrypted only by the payment information management server. The transaction permission/inhibition data, which is the data including the data, is generated and transmitted to the mobile phone of the user. This transaction identification information is associated with "information required for processing for payment (credit card number etc.)" in the payment information management server. (3). Further, the user decides to shop for 450 yen, and the user's mobile phone generates transaction execution data including the transaction identification information from the transaction approval/disapproval data and passes it to the POS terminal device of the store. (4). The POS terminal device of the store generates settlement data for settlement including the transaction identification information from the passed transaction execution data without confirming whether the transaction is permitted (credit processing), and makes it to the settlement information management server. Sent (5). The payment information management server decrypts and verifies the encrypted transaction identification information included in the transaction permission data and the encrypted transaction identification information included in the payment data, and determines that they are the same. Then, based on the transaction identification information, the information necessary for the processing for settlement is acquired, the processing for settlement is performed, and the settlement at the commercial store is completed. In the transaction system of the present invention, the information necessary for the processing including the credit card number of the user and the like is managed only by the payment information management server. The transaction identification information is generated by the payment information management server as data included in the transaction approval/disapproval data, and is encrypted so that it can be decrypted only by the payment information management server. Then, the encrypted transaction identification information is transmitted from the payment information management server and returned to the payment information management server via the mobile terminal device and the POS terminal device. Then, as described above, the encrypted transaction identification information is included in other data (transaction execution data, settlement data) and passed while passing through the mobile terminal device and the POS terminal device. Then, the transaction identification information is circulated without being tampered with, and the information necessary for the processing for settlement is acquired in the settlement information management server only after obtaining the comparison between before and after the circulation, and the processing for settlement is performed. Made possible Therefore, information necessary for processing for payment, such as the user's credit card number, has never been specified except by the payment information management server.
<Structure of Embodiment 1>
FIG. 2 is a diagram showing an example of the functional blocks of this embodiment. An example of the configuration of this embodiment will be described with reference to FIG.
The present embodiment is a transaction system including a mobile terminal device 0200, a POS terminal device 0210, and a payment information management server 0220.
<Configuration of mobile terminal device>
The “portable terminal device 0200” includes a transaction data transmission unit 0201, a transaction permission/inhibition data reception unit 0202, a transaction execution data generation unit 0203, and a transaction execution data transmission unit 0204. Further, the “mobile terminal device” specifically corresponds to a mobile phone, PHS, PDA, wristwatch or the like.
The “transaction data transmitting unit 0201” transmits transaction data including the planned transaction amount.
The “transaction data” is data including the planned transaction amount, as described above. Further, the transaction data may include information (scheduled transaction identification information) that can identify the transaction to be executed in some form. In the case where the planned transaction identification information includes, for example, information about products that the user of the mobile terminal device plans to purchase, information about services that the user plans to receive, and information about other planned dates and places of transactions, etc. There is. By including the planned transaction identification information in the transaction data, it is possible to illegally obtain and duplicate the transaction approval/disapproval data, which will be described later, during the communication, and to illegally use it for a transaction other than the originally planned transaction. Can be prevented. For example, the transaction data relating to the transaction for purchasing the A product can include the product code of the A product as the planned transaction identification information. In this case, the transaction approval/disapproval data, which will be described later, also includes the planned transaction identification information regarding the A product. Then, the transaction execution data generated based on the transaction approval/disapproval data can be limited to those for which the A product is the “transaction target for settlement”. That is, it is possible to prevent the use of the transaction permission/prohibition data and the transaction execution data in a transaction in which the A product is not a “transaction target for settlement”.
The "scheduled transaction amount" is the amount of money that one wishes to receive credit for a transaction. For example, the planned transaction amount is an amount that is scheduled to be settled by a credit system or transfer between banks (including a case of using a debit card). For example, in the case of clearing the purchase price of a product by settlement by a credit system, the planned transaction amount means either the same amount as the price of the relevant product or the amount exceeding the amount of the relevant product. Good. For example, when the price of a product is 450 yen, 450 yen, which is the same as the price, can be set as the planned transaction amount. Similarly, when the price of the product is 450 yen, 500 yen, which exceeds the amount, can be set as the planned transaction amount. In other words, the planned transaction amount indicates the upper limit amount of the transaction scheduled.
Although not shown, the transaction data may include mobile terminal device identification information that is information for identifying the mobile terminal device, in addition to the planned transaction amount. Although not shown in the figure, the transaction data is an account file managed by a payment information management server (described later, “information storage” described below) in units of users who make payments by a credit system using a mobile terminal device. Section)) and associated user account information. The mobile terminal device identification information and the user account information do not directly indicate the credit card number used by the user. The mobile terminal device identification information and the user account information are received by the payment information management server as described later. Then, the information necessary for determining whether or not the specified transaction amount can be settled by the credit system used by the user, that is, the information necessary for determining whether the transaction is possible, is the mobile terminal device identification information or the user account. It can be acquired based on the information. "Information necessary for determining whether or not a transaction is possible" means, for example, when the user uses the credit system to settle a transaction, the card number of the credit card, the expiration date of the credit card, and the credit. This means information such as the name and phone number of the holder of the card. Further, when the user uses the debit card to settle a transaction, it means information about the card number of the debit card, the personal identification number of the debit card, and the like. The "information necessary for determining whether or not the transaction is possible" is the same as the "information necessary for processing for settlement" described later. Further, the portable terminal device identification information and the user account information may be used in combination with the input of a password to authenticate the user himself/herself. Further, the mobile terminal device identification information and the user account information may be stored in an IC card or the like, and the mobile terminal device may acquire the IC card from the IC card.
Note that, unless otherwise defined, the “user” in the present application uses the mobile terminal device (or the fixed terminal device described later) as described above to transfer the credit system or transfer between banks (use a debit card). (Including cases), etc.
Although not shown, such transaction data is received by the information input by the user using the input unit provided in the mobile phone or the reception unit (transaction data specific information receiving unit) provided in the mobile phone. In some cases, it may be acquired based on the information (transaction data identification information) provided. Further, the transaction data is stored in a bar code format information (transaction data identification information) displayed on the product read by a reading unit (camera or the like) provided on the mobile phone, or an IC card attached to the product package. It may be acquired based on the information (transaction data identification information) etc. Furthermore, the receiving unit (transaction data specific information receiving unit) or the reading unit is configured to be able to receive information by using infrared communication (IrFM or the like), a non-contact (RF) tag, Bluetooth, or the like, and a POS described later. You may comprise so that the information passed by these means may be received from a terminal device, and transaction data may be acquired based on the information. Communication methods using such non-contact (RF) tags may include methods such as an electromagnetic coupling method, an electrostatic coupling method, an electromagnetic induction method, a microwave method, and an optical communication method.
In addition, the transaction data may be acquired based on the information (transaction data identification information) by reading the utility bill and various billing notices from the data memory from the mail sent to the mobile terminal device.
The “transaction propriety data receiving unit 0202” receives the transaction propriety data including the propriety of the transaction according to the transaction data transmitted from the transaction data transmitting unit.
As described above, the “transaction propriety data” is data including the propriety of transaction, and is received according to the transaction data. As for "possibility of transaction", the credit result corresponds to the settlement using the credit system, and the result of the balance inquiry regarding whether the balance of the depositor is equal to or more than the planned transaction amount in the settlement by transfer between banks ( Also referred to as "credit result.") Further, the transaction approval/disapproval data includes transaction identification information encrypted so that it can be decrypted only by the payment information management server described later. For example, when the transaction approval/disapproval data is acquired as information including “transaction limit amount A (450 yen) can be settled by credit system B” and including transaction identification information C There is. In this case, the "credit system B" indicated by the transaction approval/disapproval data is the information necessary for performing processing for payment using the credit system, such as the card number of the credit card, the expiration date, and the name of the holder. , Information such as telephone numbers is not included at all. These credit card numbers and the like are associated with the transaction identification information and the like, and are retained, accumulated, and managed in the payment information management server described later. Therefore, these credit card numbers and the like can be obtained based on the transaction identification information only in the payment information management server described later. Further, the transaction approval/disapproval data may include the mobile terminal identification information or the user account information. The transaction approval/disapproval data includes customer information such as accident history information and shopping history information of the credit system user in the account file managed by the payment information management server (included in the "information storage unit" described later). Sometimes.
As described above, the “settlement limit amount” may be directly indicated by the transaction availability data (may be included in the transaction availability data), or may be associated with the transaction availability data. It may be indicated by the data. In the latter case, for example, the transaction data or the like initially transmitted may correspond to the data associated with the transaction approval/disapproval data, and the “transaction limit amount” may be specified by the transaction data. In this case, it is not necessary to include the information directly indicating the settlement limit amount in the transaction approval/disapproval data.
Further, the fact that the transaction permission/inhibition data is “received according to the transaction data” means that the transaction permission/inhibition data is received through the following series of steps. First, the transaction data transmitted by the transaction data transmitting unit 0201 is received by the transaction data receiving unit 0221 of the payment information management server described later. Next, the transaction availability data generation unit 0222 generates transaction availability data based on the received transaction data. Then, the generated transaction feasibility data is transmitted from the transaction feasibility data transmission unit 0223 and received by the transaction feasibility data reception unit 0202 of the mobile terminal device 0200.
The "transaction identification information" is information for identifying the transaction permission/prohibition data, and is a process for settlement by a credit system used by the user or transfer between banks (including a case of using a debit card). Means information for identifying information necessary for (case A).
Alternatively, the “transaction identification information” may mean information associated with the transaction approval/disapproval data (case B).
Alternatively, the "transaction identification information" is information associated with the information necessary for processing for payment by the credit system used by the user or transfer between banks (including the case of using a debit card). May mean (Case C).
In the case B, the transaction approval/disapproval data is associated with the information necessary for the settlement process by the system of the server when the transaction information is initially accepted by the settlement information management server and the credit result is determined. Shall be performed.
The association between the information necessary for the processing for settlement in case C above and the transaction permission/inhibition data is linked by the system of the server when the transaction information is initially accepted by the settlement information management server and the credit result is determined. Shall be performed.
The information necessary for processing for payment includes, for example, when the user makes a payment using a credit system, the card number of the credit card, the expiration date of the credit card, and the name of the credit card holder. , Information such as telephone numbers are included. Further, the information necessary for the processing for settlement includes, for example, information regarding the card number of the debit card, the personal identification number of the debit card, etc. when the user makes settlement using the debit card. The information necessary for the processing for the settlement can be obtained only on the settlement information management server described later based on the transaction identification information. The reason is that the transaction identification information and the information necessary for the settlement are associated with each other in the settlement information management server.
Using the present embodiment, the transaction identification information does not impose a burden of credit processing (confirmation of transaction approval/disapproval) on the POS terminal device and does not rely on only encryption technology for security when performing payment. It plays an important role in solving the problem of the invention of the present application that secures and realizes a mechanism for performing payment by a credit system using a mobile phone.
The reason is that in the POS terminal device, it is not necessary to input information such as a credit card and perform credit processing (confirmation of transaction availability) with a server of a credit card company in payment by a credit system or the like. Is. The result of such credit processing is received in advance by the portable terminal device as transaction permission/inhibition data. The transaction approval/disapproval data is transferred as transaction execution data from the mobile terminal device to the POS terminal device, and the transaction execution data is transferred as payment data from the POS terminal device to the payment information management server. During this period, as described above, the POS terminal device does not need to perform credit processing (confirmation of transaction availability) with a server such as a credit card company. Therefore, as described above, the load on the POS terminal device side is reduced.
Further, there is no problem even if the encrypted transaction identification information itself transmitted/received on the network connecting the payment information management server, the mobile terminal device and the POS terminal device is obtained by a third party. That is, since the information necessary for the settlement process does not circulate on the network, it is not necessary to encrypt the information required for the settlement process and keep the secret during communication. Therefore, security at the time of payment can be ensured without depending only on the encryption technology. Further, if payment by a credit system or the like is promoted, it is possible to settle only by the credit system or the like without placing any cash in the cashier, and it is possible to prevent fraudulent acts such as theft of cash.
As a mode of encrypting the transaction identification information so that it can be decrypted only by the payment information management server, literally, when the transaction identification information is encrypted by a key that only the payment information management server has (or can be used), a network It includes the case where the transaction identification information is converted into some form in accordance with the transmission method (for example, transmission based on the data compression method).
The “transaction execution data generation unit 0203” generates transaction execution data based on the transaction feasibility data received by the transaction feasibility data reception unit 0202.
"Transaction execution data" includes the transfer between credit systems or banks (using a debit card, within the limit of settlement that is indicated by the transaction approval/disapproval data (or data associated therewith). ) Is information indicating that a transaction for settlement is decided and a transaction is executed. Then, the transaction execution data has transaction identification information encrypted so that it can be decrypted only by the payment information management server. In addition to the encrypted transaction identification information, the “transaction execution data” specifically includes “information indicating that processing for settlement has been decided, the amount to be settled, and the transaction target of settlement. “Name (product name, service name, etc.)” etc. may be included. Further, the transaction execution data may include the mobile terminal identification information, the user account information, or the like. By including the mobile terminal identification information and the like in the transaction execution data and passing it to the POS terminal device, and including it from the POS terminal device in the settlement data and passing it to the settlement information management server, so-called impersonation can be easily found. That is, the mobile terminal device of the user who is authorized to transmit the transaction execution data, etc., based on whether the mobile terminal identification information or the like included in the payment data and the mobile terminal identification information or the like included in the transaction availability data match or not. This is because the payment information management server can determine whether the payment is performed by the payment information management server or another mobile terminal device. In the latter case, since there is a high possibility of spoofing, it is possible to prevent the payment information management server from performing subsequent processing. The user of the mobile terminal device can be authenticated by a password or a fingerprint authentication attached to the mobile terminal device.
Although not shown, the information such as “the price of the product and the name of the product” is provided by the user using the input unit provided on the mobile phone or is provided on the mobile phone. It may be acquired based on the information (transaction execution data identification information) received by the receiving unit (transaction execution data identification information receiving section). In addition, the transaction execution data may be obtained based on the information (transaction execution data specifying information) by reading the utility bill and various billing notices from the data memory from the mail sent to the mobile terminal device. Although not shown, the price of the product is attached to the product package, which is the barcode format information (transaction execution data identification information) displayed on the product read by the reading unit provided in the mobile phone. It may be acquired based on the information (transaction execution data identification information) stored in the IC card. Further, the receiving unit (transaction execution data specific information receiving unit) or the reading unit can receive information by using infrared communication (IrFM or the like), non-contact (RF) tag, Bluetooth, etc. Information such as the price of the product may be acquired based on the information passed from the terminal device by these means. Further, the transaction execution data is data indicating whether or not the transaction can be performed, like the transaction permission/inhibition data. For example, it is possible to settle the limit amount XX yen that can be settled by a credit system. Show.
When the transaction permission/inhibition data includes the mobile terminal identification information or the user account information, the transaction execution data can be generated only in the transaction execution data generation unit of the mobile terminal device having the same information. You can also do so. As a result, it is possible to prevent the transaction approval/disapproval data from being illegally acquired during communication and being subjected to subsequent processing by so-called impersonation.
Further, the transaction approval/disapproval data and the transaction execution data may be data that does not indicate the “settlement limit amount” but simply indicates “transaction is possible”. In this case, in the POS terminal device, the amount-related information included in the payment data is only the “payment amount”. After receiving the payment data, the payment information management server acquires the transaction approval/disapproval data on the basis of the transaction identification information included in the payment data, and identifies the limit amount of settlement based on the transaction approval/disapproval data. Although not shown, information indicating that the processing for settlement is possible if the “payment amount” indicated by the settlement data is within the limit of settlement (processable information) Can be transmitted to the POS terminal device. On the other hand, if the “payment amount” indicated by the payment data is out of the limit of the paymentable amount, information indicating that processing for payment is impossible (unprocessable information) is provided to the POS terminal. It can be sent to the device.
The “transaction execution data transmission unit 0204” transmits the transaction execution data generated by the transaction execution data generation unit. The transaction execution data can be transmitted by infrared communication (IrFM, etc.), contactless (RF) tag, transmission to POS terminal device by Bluetooth, or transmission via a communication network such as a telephone network or an internet network. May be used. Further, in transmitting the transaction execution data, although not shown, information in a bar code format capable of specifying the transaction execution data is displayed on a display unit provided in the mobile terminal device, and the information in the bar code format is displayed in the POS terminal. It includes passing information by reading it with a bar code reader provided in the device.
<Fixed terminal device>
Further, the transaction system of the present embodiment may be configured as a transaction system having a fixed terminal device instead of the mobile terminal device. That is, the terminal device used by the user (the “portable terminal device” in the above description) is not limited to the “portable type” and may be the “fixed type”. For example, a personal computer installed in a private home, a business computer installed in an office of a company, or the like is applicable. The fixed terminal device includes the transaction data transmission unit, the transaction permission/inhibition data reception unit, the transaction execution data generation unit, and the transaction execution data transmission unit, like the mobile terminal device. The transaction data may include fixed terminal identification information (including an IP address or the like) that is information for identifying the fixed terminal device in addition to the planned transaction amount. The “transaction execution data transmission unit” of the fixed terminal device transmits the transaction execution data generated by the transaction execution data generation unit via a communication network such as a telephone line network or an internet line network. The transaction execution data is transmitted from the transaction execution data transmission unit to a POS terminal device (or a transaction server described later). In this case, the delivery information of the product can be included in the transaction execution data. As will be described later, by configuring the POS terminal device in place of the transaction server, the present embodiment is also applicable to settlement of transactions between corporations that do not necessarily carry out transactions in actual stores selling goods, settlement of online transactions, and the like. It becomes easy to use the trading system. In this case, it is possible to include the product delivery information and the product billing information (information regarding the payment method, slip, etc.) in the transaction execution data.
<Configuration of POS terminal>
The “POS terminal device 0210” includes a transaction execution data acquisition unit 0211, a payment data generation unit 0212, and a payment data transmission unit 0213. Further, as the POS terminal device, specifically, a register (including a personal computer-based device) corresponding to the POS system corresponds. However, the POS terminal device may be a wireless terminal device (PDA, mobile phone terminal, etc.) or the like.
The “transaction execution data acquisition unit 0211” acquires the transaction execution data transmitted from the mobile terminal device. The transaction execution data may be acquired by a method such as infrared communication (IrFM or the like), contactless (RF) tag, reception by Bluetooth, or reception through a communication network such as a telephone line network or an Internet line network. Further, in order to obtain the transaction execution data, although not shown, as described above, the display unit provided in the mobile terminal device displays the information in the barcode format capable of specifying the transaction execution data, and the barcode format of the barcode format is displayed. It includes passing information by reading the information with a bar code reader provided in the POS terminal.
The “settlement data generation unit 0212” generates settlement data, which is data for settlement, based on the transaction execution data acquired by the transaction execution data acquisition unit 0211.
“Payment data” is data for payment, as described above. Specifically, the transaction execution data is information obtained by adding information on the payee side in payment by a credit system or transfer between banks (including a case of using a debit card). The “information on the side of receiving payment” refers to information about a financial institution account (a member account of a credit card member store or a deposit account of a financial institution) of a person who manages and operates a POS terminal device. Then, the payment data includes the transaction identification information encrypted so that it can be decrypted only by the payment information management server.
That is, the "settlement data" is specified by the transaction execution data such as the amount to be settled by the credit system, the settlement method (batch, division, revolving, etc.) when the settlement is a settlement by the credit system. The information is information in which information relating to an account of a financial institution of a person who manages and operates the POS terminal device (a member account of a credit card member store or a deposit account of a financial institution) is added. In addition, as described above, the payment data includes the transaction identification information that is encrypted so that it can be decrypted only by the payment information management server. The card number of the card, the expiration date of the card, and the name of the user" can be acquired. Although not shown, the “amount to be settled by the credit system” may be specified by a numerical value input to the input unit provided in the POS terminal device. Although not shown, the amount of money may be specified by the barcode format information displayed on the package of the product using a barcode reader provided in the POS terminal device. In addition, the amount of money is read from the database of the payment information management server, which will be described later, based on the billing number read on the billing number written on the bill such as utility bill by a barcode reader or input to the input unit. You may make it acquire.
However, the payment data does not necessarily need to have other information added to the transaction execution data, and is the same as the transaction execution data as long as the transaction execution data includes all information necessary for processing for payment. The payment data generation unit may generate the data indicating the contents of the above. The payment data in this case also corresponds to the payment data generated based on the transaction execution data. Further, the payment data may include the shopping information of the user. The user's shopping information can be used for customer analysis in the payment information management server.
The “payment data transmission unit 0213” transmits the payment data generated by the payment data generation unit 0212 to the payment information management server 0220. The payment data may be transmitted by using a method via a communication network such as a dedicated line or the Internet line network.
<Trading server>
Further, the transaction system of the present embodiment may be configured as a transaction system having a transaction server (may be a personal computer-based one) instead of the POS terminal device. This transaction server does not need to be installed in a physical store that provides products and services, and does not need to be installed in a place close to a place that provides products and the like. The transaction server includes the transaction execution data acquisition unit, the payment data generation unit, and the payment data transmission unit, like the POS terminal device. In this case, the user is allowed to access the transaction server through a mobile terminal device or a fixed terminal device through a website accessible through the Internet network. With such a configuration, the present embodiment is also applicable to settlement of transactions between corporations that do not necessarily carry out transactions at physical stores that sell products, settlement of utility bills and settlement of various payments, settlement of online transactions, etc. It becomes easy to use the trading system. Further, in addition to the above delivery information, the shipping label information of the courier or the shipping company can be included in the settlement data. Also, in the settlement of transactions between corporations, the transaction server may complete the processing of clearing the accounts receivable on the basis of the billing information (information related to invoice slips, etc.) and include the payment request information in the settlement data. I can.
<Configuration of payment information management server>
The “payment information management server 0220” includes a transaction data reception unit 0221, a transaction approval/disapproval data generation unit 0222, a transaction approval/disapproval data transmission unit 0223, a payment data reception unit 0224, a transaction verification unit 0225, and an information storage unit 0226. Have.
The “transaction data receiving unit 0221” receives the transaction data transmitted from the transaction data transmitting unit 0201 of the mobile terminal device 0200. The transaction data may be received by using a method such as reception via a communication network such as a telephone line network or an internet line network.
The “transaction propriety data generation unit 0222” generates the transaction propriety data based on the transaction data received by the transaction data reception unit 0221.
The “transaction propriety data” is data including the propriety of transaction, as described above.
FIG. 11 is a diagram showing an example of the functional blocks of the payment information management server that constitutes the transaction system of this embodiment. An example in which the transaction feasibility data generation unit 1122 generates transaction feasibility data based on the transaction data will be described with reference to FIG. The transaction data includes information (mobile terminal device identification information) for identifying the mobile terminal device 1100 that transmits the transaction data. As described above, the transaction data may include the mobile terminal device identification information. The payment information management server 1120 stores information “information necessary for processing for payment” in the case where the user makes a payment using a credit system, in association with the information for identifying the mobile terminal device 1100. It is stored in the part 1126 (database) in advance. The payment information management server 1120, based on the information (mobile terminal device identification information) for identifying the mobile terminal device 1100 included in the transaction data, relates to the “for payment” associated with the mobile terminal device identification information. Acquire information necessary for processing". "Information required for processing for payment" in the payment by the credit system is, for example, the credit card number, the expiration date of the card, the name of the user who uses the card (name of the card), etc. Is. Then, the “information necessary for processing for settlement” and the planned transaction amount included in the transaction data are transmitted to a server or the like managed and operated by a credit card company that issues the credit card. In the credit card company server operated and managed by the credit card company, the user makes the transaction based on the “information necessary for processing for settlement” and the “scheduled transaction amount” included in the transaction data. Credit processing (determination of transaction availability) is performed to determine whether the planned amount can be settled using the credit system. Then, as a result of credit processing (determination of transaction availability), when it is determined that the planned transaction amount can be settled by the credit system, settlement by the credit system within the range indicated by the planned transaction amount is possible. Information indicating that (“credit result (possibility of transaction)”) is transmitted to the payment information management server 1120. The payment information management server 1120 receives the credit result (transaction availability). Then, the transaction approval/disapproval data generation unit 1122 of the payment information management server 1120 stores the transaction identification information associated with the received credit result (transaction approval/disapproval), which is information necessary for processing for payment. The transaction permission/inhibition data, which is the data including the data, is generated. The generated transaction approval/disapproval data is accumulated and managed in the information accumulating unit 1126 (database) of the payment information managing server. Note that, as described above, what is shown in the figure is only an example of the functional block diagram of the present embodiment, and in the present embodiment, the "information necessary for processing for settlement" and "transaction approval/disapproval data" are It is not limited to a mode in which the information is stored in the same information storage unit. Further, the transaction system of the present embodiment may be configured such that the information storage unit is provided outside the payment information management server.
As an example of the transaction approval/disapproval data generated in the above process, for example, it is shown that "the settlement amount limit A (450 yen) can be settled by the credit system B." and the transaction identification information is shown. The data including C is applicable. In this case, "credit card B" indicated by the transaction approval/disapproval data corresponds to the credit card company name, etc., and does not include any information such as the credit card card number, expiration date, holder's name, and telephone number. .. The credit card company name is necessary for determining whether or not the credit card of the credit card company can be used at a particular store, but the POS terminal device installed at the store and the payment information management server or the credit card. It is not necessary for processing cooperation with the server operated and managed by the company. In other words, even if the credit card company name is read from the transaction approval/disapproval data, only the credit card company name can be used to make a payment using the information on the credit card without the permission of a third party. Security is ensured. Note that, as described above, the “settlement limit amount” may be specified based on the information (transaction data or the like) associated with the transaction propriety data”.
Then, as described above, the transaction approval/disapproval data includes transaction identification information encrypted so that it can be decrypted only by the payment information management server.
The “transaction permission/prohibition data transmission unit 0223 (see FIG. 2)” transmits the transaction permission/prohibition data generated by the transaction permission/prohibition data generation unit 0222 to the portable terminal device 0200. The transaction approval/disapproval data may be transmitted by a method such as transmission via a communication network such as a telephone line network or an internet line network.
The “payment data receiving unit 0224” receives the payment data transmitted from the POS terminal device. The payment data may be received by a method such as reception via a communication line such as a dedicated line or the Internet line network.
The “transaction collating unit 0225” collates the settlement data received by the settlement data receiving unit with the transaction propriety data transmitted from the transaction propriety data transmitting unit. The “transaction permission/prohibition data transmitted from the transaction permission/prohibition data transmission unit” here is transaction permission/prohibition data having the same content as the transaction permission/prohibition data transmitted from the transaction permission/prohibition data transmission unit 0223, and the payment information. It means one that exists in the management server. For example, the transaction approval/disapproval data stored in the information storage unit 0226 is applicable. Further, the collation includes encrypted transaction identification information that can be decrypted only by the payment information management server included in the transaction permission/inhibition data generated by the payment information management server, and the portable information terminal 0200 and the POS terminal from the payment information management server. This is performed by decrypting and comparing the encrypted transaction identification information that can be decrypted only by the payment information management server sent via the device 0210. "Transmitted from the payment information management server via the mobile terminal device 0200 and the POS terminal device 0210" means that the transaction identification information is included in the transaction approval/disapproval data from the payment information management server (transaction approval/disapproval data transmission unit). The data is transmitted to the mobile terminal device, is included in the transaction execution data, is transmitted from the mobile terminal device (transaction execution data transmission unit) to the POS terminal device, and is included in the payment data and is transmitted from the POS terminal device (payment data transmission unit). It is received by the payment information management server (payment data receiving unit), that is, it has patrolled. Further, although not shown, decryption (decryption) of the encrypted transaction identification information is realized by a function other than the transaction collating unit, and the transaction collating unit only collates the decrypted transaction identification information. You can Although not shown, the transaction collation unit may compare the transaction identification information in the encrypted state and collate the transaction approval/disapproval data with the payment data. That is, the encrypted bit data of the transaction identification information may be compared with each other, and the transaction approval/disapproval data and the payment data may be collated based on whether or not they match.
As described above, the transaction identification information is “encrypted so that only the payment information management server can decrypt”, and as described above, the decryption key for decrypting and decrypting the encryption is used by a mobile phone other than the payment information management server. It means not to be shared with the terminal device 0200, the POS terminal device 0210, and the like. Therefore, it does not mean that it is applicable only when a special encryption technique is used.
Further, the matching is performed by determining whether or not the transaction identification information included in the transaction approval/disapproval data and the transaction identification information included in the payment data are the same. The collation result that both transaction identification information are the same indicates that the transaction identification information has circulated without being tampered with. Then, when it is determined that the transaction identification information is the same, the transaction permission/inhibition data identified by the transaction identification information, and the “information necessary for processing for settlement” associated with the transaction identification information You can proceed to processing for payment as it is. That is, in the POS terminal device, it is not necessary to newly input information such as a credit card and perform credit processing (confirmation of transaction availability) with a server of a credit card company, and the burden is reduced. Further, as described above, the information necessary for the processing for payment can be obtained only on the payment information management server based on the transaction identification information, so that security can be ensured without relying only on the encryption technology. Can be secured.
As described above, the case where the present embodiment is configured as a transaction system has been mainly described, but the above-mentioned portable terminal device 0200 (or fixed terminal device), POS terminal device 0210 (or transaction server), and payment information management server 0220. May be configured alone. Also, the settlement data is generated in the mobile terminal device 0200 based on the transaction execution data, and the settlement data is directly sent from the mobile terminal device 0200 to the settlement information management server 0220 without passing through the POS terminal device 0210 (or the transaction server). A configuration for sending out is also possible. Further, in the present specification, the "scheduled transaction amount" and "transaction propriety" in the description of "transaction data including estimated transaction amount" and "transaction propriety data including propriety of transaction" are shown by their respective definitions. The data (information) showing the contents (or the literal meaning), and the data (information) in a format that can be transmitted and received via the Internet network like the transaction data and the like are explained. ..
<Process Flow of First Embodiment>
3 to 6 are flowcharts showing an example of the processing flow of this embodiment. An example of the processing flow of this embodiment will be described with reference to FIG. The "processing" shown in this specification can be executed by a program to be executed by an electronic computer (including a mobile terminal device, a POS terminal device, a payment information management server, a transaction server, and a fixed terminal device). Further, the program can be stored in a recording medium readable by an electronic computer and used. The same applies to the following embodiments.
First, an example of the flow of processing in the mobile terminal device will be described with reference to FIG.
First, the transaction data including the planned transaction amount is transmitted (transaction data transmitting step S0301). Next, the transaction propriety data including the propriety of the transaction is received according to the transaction data transmitted in step S0301 (transaction propriety data reception step S0302). Further, transaction execution data is generated based on the transaction permission/inhibition data received in step S0302 (transaction execution data generation step S0303). Finally, the transaction execution data generated in step S0303 is transmitted to the POS terminal device (transaction execution data transmission step S0304).
Next, an example of the flow of processing in the POS terminal device will be described with reference to FIG.
First, transaction execution data is acquired (transaction execution data acquisition step S0401). Next, payment data, which is data for payment, is generated based on the transaction execution data acquired in step 0401 (payment data generation step S0402). Finally, the payment data generated in step S0402 is transmitted to the payment information management server (payment data transmission step S0403).
Next, an example of the flow of processing in the payment information management server will be described with reference to FIG.
First, the transaction data including the planned transaction amount is received (transaction data receiving step S0501). Next, the transaction permission/prohibition data is generated based on the transaction data received in step S0501 (transaction permission/prohibition data generation step S0502). Further, the transaction propriety data generated in step S0502 is transmitted (transaction propriety data transmission step S0503). Further, the settlement data, which is the data for settlement generated from the transaction execution data generated based on the transaction permission/inhibition data transmitted in step 0503, is received (settlement data receiving step S0504). Further, the encrypted transaction identification information included in the transaction approval/disapproval data generated in step S0502 and the encrypted transaction identification information included in the payment data received in step S0504 are decrypted and decrypted (transaction Identification information decoding step S0505). Finally, by comparing the transaction identification information included in the transaction approval/disapproval data and the transaction identification information included in the payment data, which are decrypted in step S0505, the payment data received in step S0504, and the step The transaction approval/disapproval data transmitted in S0503 is collated (transaction collation step S0506).
Finally, an example of the flow of processing in the transaction system will be described with reference to FIG.
Transaction data including the planned transaction amount is transmitted (transaction data transmission step S0601). Next, the transaction data transmitted in step S0601 is received (transaction data receiving step S0602). Further, the transaction feasibility data is generated based on the transaction data received in the step S0602 (transaction feasibility data generation step S0603). Further, the transaction approval/disapproval data generated in step S0603 is transmitted (transaction approval/disapproval data transmission step S0604). Further, the transaction acceptance/rejection data including the acceptance/rejection of the transaction is received according to the transaction data transmitted in step S0601 (transaction acceptance/rejection data reception step S0605). Further, transaction execution data is generated based on the transaction approval/disapproval data received in step S0605 (transaction execution data generation step S0606). Further, the transaction execution data generated in step S0606 is transmitted (transaction execution data transmission step S0607). Further, the transaction execution data transmitted in step S0607 is acquired (transaction execution data receiving step S0608). Further, payment data, which is data for payment, is generated based on the transaction execution data received in step S0608 (payment data generation step S0609). Further, the payment data generated in step S0609 is transmitted (payment data transmission step S0610). Further, the payment data transmitted in step S0610 is received (payment data receiving step S0611). Further, the encrypted transaction identification information included in the transaction permission/inhibition data generated in step S0603 and the encrypted transaction identification information included in the payment data received in step S0611 are decrypted and decrypted (transaction Identification information decoding step S0612). Finally, by comparing the transaction identification information included in the transaction approval/disapproval data decoded in S0612 with the transaction identification information included in the payment data, the payment data received in step S0611 and the step S0604. It collates with the transaction propriety data transmitted in (transaction collation step S0613).
<A brief description of the effects of the first embodiment>
By using the transaction system of the present embodiment, payment by a credit system or the like does not burden the store for credit processing (confirmation of transaction availability) in the payment and depends only on the encryption technology. It can be done without any security.
<<Embodiment 2>>
<Concept of Embodiment 2>
The present embodiment is based on the configuration of the above-described first embodiment, and the payment information management server further includes a payment amount determination unit. The settlement amount determination unit is a transaction system having one or both of period summing means and amount summing means, and processing data composing means. In order to eliminate the complexity of individually processing the settlement of a small amount of transactions, the transaction system according to the present embodiment collectively performs the settlement processing in the settlement information management server (or other device, server, etc.). I was able to do it. Specifically, it is configured as a transaction system for collecting the settlement data based on a certain amount of money or a certain period of time and processing it as one transaction.
FIG. 7 is a diagram showing an example of the concept of this embodiment. An example of the concept of this embodiment will be described with reference to FIG.
As shown in (a) of the same figure, on January 1, a user uses a mobile phone to settle a 350 yen item A at a commercial store using his/her mobile phone using a credit system. Then, it is confirmed with the payment information management server whether the 350 yen can be settled. From the payment information management server, transaction approval/disapproval data A indicating that 350 yen worth of payment is possible is transmitted, and the user receives the transaction approval/disapproval data A on the mobile phone, and the transaction generated based on the transaction approval/disapproval data A. The execution data A was transmitted to the POS terminal device. The POS terminal device receives this, generates and transmits the payment data A, which is data for payment, and the payment information management server receives this.
At the same commercial store, the user shopped for product B for 400 yen on January 5, and for product C for 450 yen on January 10. The payment for the shopping of the products B and C was made by the credit system using the mobile phone as in the case of purchasing the product A.
The payment information management server receives the payment data B for the payment of the product B on January 5 (see (b) in the figure), and the payment data for the payment of the product C on January 10 C is received (see (c) in the figure). Then, the payment information management server tabulates the payment data A, B, C received from 1/1 to 1/10 for a period of time, and pays 1,200 yen worth of payment specified by the payment data A, B, C. Processing data, which is the data for processing as a transaction of
<Structure of Embodiment 2>
FIG. 8 shows an example of a functional block diagram of this embodiment. An example of the configuration of this embodiment will be described with reference to FIG.
This embodiment is based on the configuration of the first embodiment and further includes a payment amount determination unit 0827, and the payment amount determination unit 0827 is one of the period totaling unit 0827a and the amount totaling unit (1027a: see FIG. 10). Alternatively, the transaction system has both of them and the processing data composing means 0827b.
Transaction data transmission unit 0801, transaction permission/inhibition data reception unit 0802, transaction execution data generation unit 0803, transaction execution data transmission unit 0804 of mobile terminal device 0800 (or fixed terminal device), and POS terminal device 0810 (or transaction server). Transaction execution data acquisition unit 0811, payment data generation unit 0812, payment data transmission unit 0813, and transaction data reception unit 0821 of the payment information management server 0820, transaction permission/inhibition data generation unit 0822, transaction permission/inhibition data transmission unit 0823, and settlement The data receiving unit 0824, the transaction collating unit 0825, and the information storage unit 0826 have the same parts as those in the first embodiment, and therefore description thereof will be omitted.
The “payment amount determination unit 0827”, when the transaction verification information of the transaction verification unit 0825 is the same, the amount indicated by the payment data including the transaction identification information (the amount to be paid) is set in advance. Judge whether the amount exceeds the stipulated amount. The settlement amount determination unit 0827 makes the determination by the period totaling unit 0827a or the amount totaling unit (see 1027a in FIG. 10) described later for the purpose of distinguishing whether or not the total settlement data. "Exceeding" a predetermined amount may be used as "more than".
The “payment amount determination unit 0827” further includes one or both of a period totaling unit 0827a and an amount totaling unit (see 1027a in FIG. 10).
The “period aggregation means 0827a” aggregates the settlement data for a period when the settlement amount determination unit 0827 determines that the amount indicated by the settlement data (the amount to be settled) does not exceed a predetermined amount. To do. The payment data collected by the period collection means is characterized in that the “information necessary for processing for payment” and the like associated with the transaction identification information included in the payment data are the same. For example, the number of the credit card (or debit card) used for the payment is the same, and the account (credit) of the financial institution of the payee (administrator of the POS terminal device specified by the payment data) of the payment. Settlement data having the same (including an account as a card member store) is aggregated by the period aggregation means.
An example of collection of payment data by the period totaling unit 0827a will be described. Consider, for example, the case where the "predetermined amount" is set to a small amount such as "500 yen" and the appropriate amount for settlement as one unit of transaction is "2000 yen". In this case, for example, when the transaction is expected to be performed once a week, the period for which the settlement data should be collected is set to 4 weeks in advance. Then, with respect to the payment data received by the payment data receiving unit 0824 and determined not to exceed the predetermined amount of “500 yen” by the payment amount determining unit 0827, the predetermined “four-week period”. The settlement data in the above is tabulated by the period tabulation means 0827a.
In addition, the transaction system of the present embodiment may be configured such that an amount summing means is provided instead of the period summing means 0827a provided in the settlement amount determination unit 0827, or both of the means are provided. .. FIG. 10 is a diagram showing an example of functional blocks of a transaction system in which the period totaling means is replaced with an amount totalizing means.
The “amount summing unit 1027a” is a predetermined amount when the settlement amount determination unit 1027 determines that the amount (amount to be settled) indicated by the settlement data does not exceed a predetermined amount. Until the payment data is reached.
For example, in the same manner as described above, when the predetermined amount of money is set to a small amount such as “500 yen” by the payment amount determination unit 1027 and the amount of money appropriate for settlement as one unit of transaction is set to “2000 yen”. I'll think about it. In this case, the amount of money, which is a standard for collecting the payment data, is predetermined as “2000 yen”. Then, with respect to the payment data determined by the payment amount determination unit 1027 not to exceed the predetermined amount of “500 yen”, the amount totalizing means 1027a continues until the predetermined amount of “2000 yen” is reached. Summarize payment data.
“Processing data composing means (8027b in FIG. 8, 1027b in FIG. 10)” refers to the settlement data collected by the period totaling means (8027a in FIG. 8) or the amount totalizing means (1027a in FIG. 10). Reconfigure to process data for processing as a transaction.
“Processing data” is data that is reconfigured to process the payment data collected as described above as one transaction. Further, the processing data indicates the total amount of the “payment amount” indicated by the aggregated payment data.
For example, when the payment data A for payment of 350 yen, the payment data for payment of 400 yen, and the payment data for payment of 450 yen are tabulated for a period, these payment data A, B, and C are The processing data is reconfigured as the data for the payment of 1200 yen, which is the total amount shown. In this case, although not shown, in the settlement processing unit that performs processing for settlement, the processing for settlement of “1200 Yen” can be performed as one transaction. The reason is, as described above, the “for payment” that can be acquired based on the transaction identification information included in the payment data collected by the period totaling means (8027a in FIG. 8) or the amount totaling means (1027a in FIG. 10). This is because "information necessary for processing" and the like are the same. The fact that the "information necessary for processing for payment" and the like are the same means that the "credit card information (or debit card information)" used for payment acquired based on the payment data A, B, C It indicates that they are the same, and that the accounts (including the account as a credit card member store) of the financial institution of the payee (management operator of the POS terminal device specified by the payment data) in the payment are the same. That is, since the payer side and the payee side are the same in the settlements specified by the settlement data A, B, and C, it is possible to collectively perform the processing for these settlements as one transaction.
<Processing flow of the second embodiment>
FIG. 9 is a flowchart showing an example of the processing flow of this embodiment. An example of the processing flow of this embodiment will be described with reference to FIG.
First, transaction data including a planned transaction amount is received (transaction data receiving step S0901). Next, based on the transaction data received in step S0901, transaction propriety data including the propriety of transaction is generated (transaction propriety data generation step S0902). Further, the transaction propriety data generated in step S0902 is transmitted (transaction propriety data transmission step S0903). Further, the settlement data, which is the data for settlement generated from the transaction execution data generated based on the transaction permission/inhibition data transmitted in step 0903, is received (settlement data receiving step S0904). Further, the encrypted transaction identification information included in the transaction approval/disapproval data generated in step S0901 and the encrypted transaction identification information included in the payment data received in step S0904 are decrypted and decrypted (decryption step S0905). Further, by comparing and comparing the transaction identification information decrypted in step S0905, the settlement data received in step S0904 and the transaction approval/disapproval data transmitted in step S0903 are collated (collation step S0906). Further, when the collation result of the collation in the collation step S0906 is the same, it is determined whether or not the settlement data including the transaction identification information exceeds a predetermined amount (amount determination step S0907). Furthermore, in step S0907, the payment data determined not to exceed the predetermined amount is tabulated for a period (period tabulation step S0908). Finally, the settlement data aggregated in the above-mentioned step 0908 is reconfigured as processing data for processing as one transaction (processing data reconstruction step S0909).
<A brief description of the effects of the second embodiment>
When the transaction system of the present embodiment is used, it is not always necessary to separate the settlement process based on each settlement data for a small amount of settlement, so that the settlement process becomes efficient. There is. This is because, as described above, payment data satisfying certain conditions can be aggregated and processed as one transaction for a certain period or with a certain amount of money as a reference.
In addition, for example, it is particularly convenient for a credit card company and a convenience store to use the transaction system of the present embodiment in order to promote a small amount of payment at a convenience store or the like by the credit system. In the case of a small amount of payment, when processing for payment is performed for each payment data, a minimum fee for using the credit system is generated for each processing. Then, the total amount of the minimum fees may exceed the fee that would have been incurred if the total settlement amount indicated by all the settlement data was settled. In some cases, the member store refuses to make a small amount of payment by using the credit system because the ratio of the commission to the payment amount becomes large. On the other hand, when a credit card company processes such small amount payments individually, each processing cost will be incurred. Therefore, it is not profitable unless the minimum fee is taken as described above. This is because, for each process, the data necessary for the process for payment must be transmitted and received between the store side and the credit card company through the communication line dedicated to payment such as the above-mentioned "CAFIS (registered trademark)". It will not happen. In other words, the fee for using the communication line is incurred for each process. In this respect, if the transaction system of the present invention is used, the dedicated communication line can be used only between the payment information management server and the server of the credit card company. Further, as described above, the settlement data is totaled and processed, so that the number of times of communication can be reduced. In other words, the problem of high communication charges as described above does not occur. Moreover, if the payment data is stored in the POS terminal device on the side of the member store and the batch transmission process is performed at a fixed amount or time, the communication fee can be further reduced, which is also possible in the present embodiment. ing. Therefore, if the transaction system of the present invention is used, the communication charge etc. that a credit card company or the like bears is reduced. Then, the credit card company can reduce the fee charged by the user. Thus, it can be said that the transaction system of the present invention is a system that is beneficial to both parties.
<<Embodiment 3>>
<Concept of Embodiment 3>
FIG. 12 is a diagram showing an example of the concept of this embodiment. An example of the concept of this embodiment will be described with reference to FIG.
This embodiment is based on the configuration of the above-described first embodiment, and further, the transaction execution data generation unit generates a plurality of transaction execution data based on one transaction approval/disapproval data received by the transaction approval/disapproval data receiving unit. It is a trading system that can do.
That is, as shown in the figure, (1) a user such as a credit card uses a mobile terminal device (or a fixed terminal device) that he/she uses in advance and pays a certain amount (for example, 2000 yen) by a credit system or the like. Transaction permission/inhibition data A including the result of the credit processing indicating whether settlement is possible (transaction permission/inhibition) is received. After the transaction permission/inhibition data A is received, the transaction permission/inhibition data A can be used for shopping within the limit of the settlement limit (2000 yen) indicated by one transaction permission/inhibition data A. For example, based on the one transaction approval/disapproval data A, (2) transaction execution data indicating that the amount to be settled is 800 yen at a specific store (A store) is generated and transmitted to the POS terminal. For 800 yen, you can purchase item A. Further, (3) at another store (B store), transaction execution data indicating that the amount to be paid is 700 yen can be generated and transmitted to the POS terminal device to purchase the product B of 700 yen. .. Further, (4) at another store (C store), transaction execution data indicating that the amount to be settled is 500 yen can be generated and transmitted to the POS terminal device to purchase the product C of 500 yen. . That is, the user of the portable terminal device of the transaction system of the present invention does not have to receive the transaction approval/disapproval data including the result of the credit processing each time the payment is made, which is convenient.
<Structure of Embodiment 3>
FIG. 13 is a diagram showing an example of the functional blocks of this embodiment. An example of the conceptual configuration of this embodiment will be described with reference to FIG.
As described above, the present embodiment is based on the configuration of the above-described first embodiment, and further, the transaction execution data generation unit is configured to perform a plurality of transactions based on one transaction permission/inhibition data received by the transaction permission/inhibition data reception unit. It is a trading system capable of generating execution data.
The transaction data transmission unit 1301, the transaction permission/inhibition data reception unit 1302, the transaction execution data generation unit 1303, the transaction execution data transmission unit 1304 of the mobile terminal device 1300 (or fixed terminal device), and the POS terminal device 1310 (or transaction server). Transaction execution data acquisition unit 1311, payment data generation unit 1312, payment data transmission unit 1313, and transaction data reception unit 1321 of the payment information management server 1320, transaction permission/inhibition data generation unit 1322, transaction permission/inhibition data transmission unit 1323, and settlement. The data receiving unit 1324, the transaction collating unit 1325, and the information accumulating unit 1326 are the same as the corresponding parts of the first embodiment, and thus the description of the common parts will be omitted. In the figure, transaction data, transaction approval/disapproval data, transaction execution data, and settlement data, which are targets of processing in each configuration of the POS terminal device and the settlement information management server, are omitted.
<About the transaction execution data generator>
The “transaction execution data generation unit 1303” is capable of generating a plurality of transaction execution data based on one transaction approval/disapproval data received by the transaction approval/disapproval data receiving unit. For example, as shown in the figure, the transaction execution data generation unit 1303 can generate three transaction execution data A, B, C based on one transaction approval/disapproval data.
That is, the transaction permission/inhibition data is included in the transaction permission/inhibition data within a range in which the sum of the “amount to be settled” indicated by each of the plurality of transaction execution data A, B, and C does not exceed the settlement limit amount indicated in the transaction permission/inhibition data. Based on this, a plurality of transaction execution data can be generated by the transaction execution data generation unit 1303. Then, the sum of the “amount to be settled” indicated by each of the plurality of transaction execution data A, B, and C generated by the transaction execution data generation unit 1303 is the maximum settlement amount shown in the transaction permission/prohibition data. When it reaches, it becomes impossible to generate transaction execution data based on the transaction permission/prohibition data. Hereinafter, an example of a specific example of generating a plurality of transaction execution data based on one transaction approval/disapproval data will be described.
When the transaction execution data is generated based on the transaction feasibility data, the content of the transaction execution data that can be further generated based on the transaction feasibility data is limited based on the "remaining transaction possible amount information" shown below. The “remaining transaction possible amount information” is information on an amount obtained by subtracting the “amount to be settled” indicated by the transaction execution data from the “settlement limit amount” indicated by the transaction propriety data.
FIG. 18 is a diagram showing an example of a specific example of generating a plurality of transaction execution data based on one transaction approval/disapproval data by using the remaining transaction possible amount information. An example of generation of transaction execution data in the transaction execution data generation unit will be described with reference to FIG.
Consider, for example, a case where the transaction approval/disapproval data is data indicating that the planned transaction amount of 2000 yen can be settled by the credit system X. Based on the transaction permission/prohibition data, “transaction execution data A indicating that the amount to be paid is 800 yen” is generated. Then, at the same time as or before or after the generation of the transaction execution data, the remaining transaction possible amount indicating that the transaction execution data indicating the “payment amount” of the remaining 1200 yen can be generated based on the transaction approval/disapproval data. The information A is generated by the transaction execution data generation unit and is stored in the storage unit in association with the transaction permission/inhibition data (see FIG. 11A).
Then, the transaction execution data generation unit generates transaction execution data B, which indicates that the amount to be settled is 700 yen, based on the transaction permission/inhibition data and the remaining transaction possible amount information A (FIG. 8). (See (B)). The “payment amount” of the transaction execution data that can be newly generated is within the range of the settlement limit amount (2000 yen) indicated by the transaction permission/denial data, and is indicated by the remaining transaction possible amount information A. It is limited to the range of payment limit (1200 yen). That is, the “payment amount” indicated by the transaction execution data B is limited to the range of “1200 yen”. Then, the remaining transaction possible amount information A is updated to “remaining transaction possible amount information B indicating a settlement limit of 500 yen”.
Then, the transaction execution data generation unit further generates "transaction execution data C indicating that the amount to be settled is 500 yen" based on the transaction feasibility data and the remaining transaction possible amount information B ((Fig. See C)). Then, the remaining transaction possible amount information B is updated to “remaining transaction possible amount information C indicating a settlement limit of 0 yen”. In this way, it is possible to generate a plurality of transaction execution data A, B, C based on the one transaction approval/disapproval data until the settlement possible limit amount indicated by the remaining transaction possible amount information becomes 0 yen.
These processes are included in the above-described process of “generating a plurality of transaction execution data based on one transaction permission/prohibition data received by the transaction permission/prohibition data receiving unit”.
Although not shown, the transaction availability data associated with the remaining available transaction amount information is stored in a memory or the like in the mobile terminal device. Alternatively, the remaining transaction possible amount information is generated by the transaction execution data generation unit, then transmitted from the mobile terminal device to the payment information management server, accumulated and managed by the payment information management server, and again, the transaction permission/inhibition is returned. The mobile terminal device may receive the transaction execution data from the payment information management server when the transaction execution data is generated based on the data. Even if this remaining transaction possible amount information is exchanged between the mobile terminal device and the payment information management server, the information itself does not indicate personal information, and personal information is leaked in the transaction system of this embodiment. There is nothing to do.
<Advantage of being able to generate multiple transaction execution data based on transaction availability data>
As described above, in the present embodiment, it is possible to generate a plurality of transaction execution data based on one transaction approval/disapproval data, and the advantage thereof is that the transaction approval/disapproval data and the transaction execution data are so-called electronic money-like. This is a point that can be used for. Electronic money refers to “the electronic information in the electronic money system, which is a general term for systems that complete settlement by exchanging electronic information”. Although electronic money is electronic information, it can be used for payment with the same degree of freedom as cash. The transaction approval/disapproval data used in the transaction system of the present embodiment does not have to be received by the portable terminal device (transaction approval/disapproval data receiving unit) for each transaction. In the transaction system of the present embodiment, once the transaction permission/inhibition data is received by the mobile terminal device (transaction permission/inhibition data receiving unit), the transaction permission/inhibition data can be provided with the same degree of freedom as cash within the range of the settlement limit. It can be used for processing for payment. In this respect, it can be said that the transaction approval/disapproval data can be used as electronic money.
Electronic money systems are generally classified into "prepaid card application type", "credit card application type", "deposit currency utilization type", and "cash currency type". The present embodiment using the transaction permission/denial data has the advantages of “credit card application type” and “cash currency type” in this electronic money system when used for settlement by a credit system. In addition, the present embodiment has an advantage of “deposit currency use type” and “cash currency type” in the electronic money system when used for payment by transfer between banks (including the case of using a debit card). .. In any case, it can be said that it is superior to each of these electronic money systems in that it does not have the drawbacks of each method of these electronic money systems.
The "advantage of credit card type" is that the existing communication network for credit card payment can be used and there is a high possibility of practical application, and the limit of payment is not limited to the actual deposit amount of the user. This is a high convenience for users. In addition, the "merit of cash currency type" is that anonymity of payment can be secured. The advantage of the "use of deposit currency" is that it can be put to practical use with a relatively simple technical mechanism (such as rewriting of bank books). In addition, it is not always necessary to use a dedicated device, and it can be realized by an operation from a personal computer or the like.
In addition, "a drawback of prepaid card application type" is that it takes time and effort to make advance purchases at convenience stores and the like. In addition, "a drawback of the credit card application type" is that personal information may be leaked and the anonymity of payment cannot be secured. The "demerit of using deposit currency" is that the settlement amount is limited to the deposit amount. Further, the drawback of the "cash currency type" is that it is difficult to construct a technical mechanism for ensuring the authenticity of electronic money (electronic information) that embodies a monetary value, that is, it is difficult to put it into practical use. It is a point.
In the electronic money system, the "credit card application type" among the above-mentioned methods is being put to practical use. High systems have not yet been built. In this respect, according to the present invention, as shown in the basic embodiment 1, personal information such as a credit card number is not exchanged between the mobile terminal device, the POS terminal device, and the payment information management server. Only the transaction approval/disapproval data that does not include personal information is exchanged between these devices. Since personal information such as credit card numbers is managed only by the management server, there is no risk of leakage of personal information, and the anonymity of payment is secured.
Examples of the above-mentioned "prepaid card application type" of electronic money include "VISA Cash (registered trademark)" and the like, and examples of "credit card application type" include "Commerce Net" and the like. Examples of the “deposit currency utilization type” include “Financial Service Technology Consortium” and the like, and examples of the “cash currency type” include “Mondex (registered trademark)” and the like.
<Process Flow of Embodiment 3>
FIG. 14 is a flowchart showing an example of the processing flow of this embodiment. An example of the processing flow of this embodiment will be described with reference to FIG.
First, transaction data including the planned transaction amount is transmitted (transaction data transmission step S0401). Next, the transaction propriety data including the propriety of the transaction is received according to the transaction data transmitted from the step S1401 (transaction propriety data reception step S1402). Further, based on the transaction permission/inhibition data received in step S1402, transaction execution data indicating an amount (amount to be settled) that does not reach the settlement limit shown in the transaction permission/inhibition data is generated. (Transaction execution data generation step S1403). Further, the transaction execution data generated in step S1403 is transmitted to the POS terminal device (transaction execution data transmission step S1404). Further, the remaining tradeable amount information, which is information on the amount obtained by subtracting the settlement amount shown by the transaction execution data from the tradable limit shown by the transaction allowance data, is stored in association with the transaction acceptability data. (Step S1405 of associating remaining transaction amount information). Furthermore, it indicates the amount of money (the amount of money to be settled) which is within the range of the maximum amount of settlement indicated by the transaction availability data and within the range of the maximum amount of settlement indicated by the remaining transaction possible amount information. Transaction execution data is generated (re-transaction execution data generation step S1406).
<A brief description of the effects of the third embodiment>
By using this embodiment, it is possible to easily perform processing for settlement of the purchase price of a product, etc., without necessarily being limited to the deposit amount of the user. Further, it becomes possible to secure the anonymity of payment and perform the processing for payment. Further, it is possible to easily perform processing for settlement of transactions between individuals.
<<Embodiment 4>>
<Concept of Embodiment 4>
FIG. 15 is a diagram showing an example of the concept of this embodiment. An example of the concept of this embodiment will be described with reference to FIG.
The present embodiment is a transaction system based on the configurations of the above-described first to third embodiments, and further the mobile terminal device is a chip-type electronic device (IC card or the like) that can be inserted into and removed from another electronic device.
As shown in the figure, a user who has a train fare prepaid card (IC card: chip type electronic device) that can be used at a train fare automatic ticket gate, uses the train fare prepaid card charge device to get the IC. I charged the card (chip type electronic device) with the amount information for the train fare usage. Then, the user settles the train fare with the IC card (chip type electronic device).
Further, the user received the “transaction approval/disapproval data” from the server using his/her mobile phone or the like and stored it in the IC card (chip type electronic device). The transaction approval/disapproval data indicates that the user can use the credit system to perform processing for payment with a limit of 800 yen. Then, since the user purchases the product A of 800 yen, based on the transaction approval/disapproval data stored in the IC card (chip-type electronic device), the amount of money corresponding to the price of the product, “the amount to be settled ( Transaction execution data indicating "800 yen)" was generated and transmitted to the POS terminal device of the store. The user has settled the price of the product A by transmitting the transaction execution data to the POS terminal device of the store. Thus, the IC card (chip type electronic device) could be used instead of a credit card.
At present, IC cards are widely used for so-called settlement (transaction) systems such as payment for train fares. The IC card corresponds to, for example, "SUICA (registered trademark)" operated by JR East (West Japan). Further, it becomes more convenient if the function of the chip type electronic device of the present invention is added to the IC card. That is, many payment functions can be integrated in one IC card. Therefore, the mobile terminal device that constitutes the present embodiment is configured as a "chip-type electronic device" so that it can be used as a form like the above-mentioned IC card. If the chip-type electronic device is a card-type, the user can conveniently store it in his wallet and carry it.
<Structure of Embodiment 4>
FIG. 16 is a diagram showing an example of a functional block diagram of the present embodiment. An example of the configuration of this embodiment will be described with reference to FIG.
As described above, the present embodiment is a transaction system based on the configurations of the first to third embodiments, and further, in which the portable terminal device is a chip-type electronic device (IC card or the like) that can be inserted into and removed from another electronic device. is there. The transaction execution data acquisition unit 1611, the payment data generation unit 1612, the payment data transmission unit 1613 of the POS terminal device 1610 (or the transaction server), the transaction data reception unit 1621, and the transaction permission/denial data generation unit 1622 of the payment information management server 1620. Since the transaction approval/disapproval data transmission unit 1623, the payment data reception unit 1624, the transaction collation unit 1625, and the information storage unit 1626 are the same as the corresponding portions of the first embodiment, etc., which are basically the same, description of common portions will be omitted. To do.
<About chip type electronic devices and other electronic devices>
The “chip type electronic device 1600” is a part of the constituent elements of the transaction system of the present embodiment in place of the mobile phone of the first embodiment, and is an electronic device that can be inserted into and removed from other electronic devices. . Then, both the chip-type electronic device and other electronic devices realize the same functions as the functions of the mobile terminal device according to the first embodiment. For example, as shown in the figure, the chip-type electronic device 1600 includes a transaction execution data generation unit 1603 and a transaction execution data transmission unit 1604 among the functions of the mobile terminal device that constitutes the basic transaction system of the first embodiment. Have. The other function of the mobile terminal device that constitutes the basic transaction system of the first embodiment is possessed by the other electronic device into which the chip-type electronic device can be inserted and removed. That is, as shown in the figure, the transaction data transmission unit 1601 and the transaction approval/disapproval data reception unit 1602 are configured to be included in the other electronic device. The other electronic devices include mobile phones, PDAs, personal computers, and the like.
Although not shown, the chip-type electronic device may include all of the transaction data transmission unit 1601, the transaction permission/inhibition data reception unit 1602, the transaction execution data generation unit 1603, and the transaction execution data transmission unit 1604, or any one of them. You may comprise so that it may have one or two or more functions. Therefore, the other electronic device includes the transaction data transmitting unit 1601, the transaction permission/inhibition data receiving unit 1602, and the transaction execution data generating unit 1603, and the chip-type electronic device includes the transaction execution data transmitting unit 1604. Thus, the transaction system of this embodiment can be configured.
Specific examples of the chip-type electronic device include an IC card and an electronic memory with a communication function. The IC card may be of so-called contact type or non-contact type. The electronic memory with a communication function corresponds to a communication module, that is, an electronic device in which an RF circuit and a baseband circuit are integrated with an information storage device. The communication by the communication module is not limited to the one using a so-called telephone line network, and infrared communication (IrFM etc.), non-contact (contactless (contactless) (like the transaction execution data transmission unit of the mobile terminal device of the first embodiment). It is also possible to use an RF) tag, transmission by Bluetooth, or other method such as transmission through a communication network such as the Internet network. Further, in communication by the communication module, although not shown, information in a bar code format capable of specifying the transaction execution data is displayed on a display unit provided in a chip-type electronic device, and the information in the bar code format is displayed by a POS. It includes passing information by reading with a bar code reader provided in the terminal device.
The functions of the above-mentioned chip type electronic device and other electronic devices may be configured by hardware or software. When the function is configured by software, it is preferable that the program that realizes the function can be downloaded from the payment information management server to the other electronic device or the chip-type electronic device.
When the chip-type electronic device 1600 is configured by using the function of the IC card, the “transaction execution data generation unit 1603” realizes the information processing function of the IC card (“ CPU, etc.).
Further, as described above, the “transaction execution data transmission unit 1604” included in the chip-type electronic device may transmit the transaction execution data to the POS terminal device 1610 by a communication method using a contactless (RF) tag. it can. That is, the chip-type electronic device can transmit data (transaction execution data) in the same manner as data communication using a non-contact type IC card. In this case, the transaction execution data transmission unit 1604 included in the chip-type electronic device can be configured in the same manner as the configuration (“RF-IC” or the like) that realizes the data transmission/reception function of the IC card.
Although not shown, the chip-type electronic device may be provided with a function (chip-type electronic device storage unit) for storing the transaction execution data. In this case, the storage function (chip-type electronic device storage unit) has the same configuration as that for realizing the information storage function of the IC card (“EEPROM: electrically rewritable ROM” of the microcomputer unit of the IC card). Can be realized.
As mentioned above, the IC card may be of a non-contact type. That is, data can be transmitted and received without contact (without contact) with the reader/writer (corresponding to the POS terminal device in this embodiment) by electromagnetic induction or the like. Such a non-contact type IC card includes a "contact type IC card" capable of exchanging information with the reader/writer at intervals of several mm and a "remote type IC card" capable of exchanging information at an interval longer than that. However, the chip-type electronic device may use any type of IC card.
As described above, the function of the IC card is widely used in a system for so-called settlement (transaction) such as train fare settlement. Therefore, if the user of the chip-type electronic device already owns the IC card, the function of the IC card is added to the functions of the transaction execution data generation unit 1603, the transaction execution data transmission unit 1604, etc. Type electronic device.
Also, the "freight payment function for trains" has been exemplified as the payment function of the IC card used for the chip-type electronic device, but the payment function of the IC card is not limited to such a function, and for example, ETC (pay car) It may be a settlement function of an ETC card used for a road automatic fee collection system). It goes without saying that an IC card dedicated to the transaction system of this embodiment can be used as the chip-type electronic device.
In the chip-type electronic device, the IC card may be incorporated in a mobile phone or PDA (in this case, the mobile phone or PDA can be the other electronic device), or clothes, a bag, It may be attached to a wallet, glasses, a watch or the like.
Further, the chip type electronic device is not limited to the one similar to the IC card, and mainly has a function of readablely recording information such as “flash memory” and includes a communication function. .
The chip-type electronic device may have a biometrics authentication function such as fingerprint authentication.
The IC card has a feature that "it is very difficult to physically copy it, it is difficult to access the inside of the card, and it is difficult to falsify or snoop data." However, it does not completely prevent unauthorized access to the inside of the card. Therefore, when the credit card number is directly stored in the IC card for use, there is still a risk that the information will be illegally acquired. In this regard, in the transaction system of the present embodiment, even when an IC card is used as the chip-type electronic device, personal information of the credit card number is not stored in the IC card, and therefore, the information of the IC card is illegally obtained. Even if it is done, there is no concern about leakage of personal information.
As an IC card used for a payment system, an IC card “Felica (registered trademark)” developed by Sony Corporation is known, and as described above, a card for train fare settlement “SUICA ( Registered trademark)".
However, in the current payment system using such an IC card “Felica (registered trademark)”, the credit card number or the like is encrypted (common key method) and stored in the IC card itself, or the money is directly paid. It stores electronic money and the like that has a real value. Therefore, the security of the IC card depends on the encryption technology. In order to solve this problem, the NTT Group has also proposed to use a public key method, which is generally said to have high security among encryption techniques. However, the security of such a mechanism is still secured only by the limit of the encryption technology.
<About the payment information management server>
As described in the first embodiment, the payment information management server 1620 uses the credit system that uses the credit card information of the user in association with the information for identifying the mobile terminal device (mobile terminal identification information). “Information necessary for processing for payment” is stored in advance in the information storage unit 1626 (database). In the case of the present embodiment, since the portable terminal device is a “chip-type electronic device”, the information storage unit of the payment information management server displays “information for identifying the chip-type electronic device (chip-type electronic device). The “identification information)” and the “information necessary for processing for payment” may be stored in association with each other. In this case, the transaction data may include the chip-type electronic device identification information. Then, the payment information management server 1620 acquires, based on the chip-type electronic device identification information included in the transaction data, the “information necessary for processing for payment” associated with the chip-type electronic device identification information. To do. The “information necessary for the processing for payment” and the like by the credit system are the same as those described in the above-described first embodiment, and thus the description thereof will be omitted. Further, the “mobile terminal identification information” may be information for identifying the other electronic device (including a mobile phone).
<Process Flow of Embodiment 4>
FIG. 17 is a flowchart showing an example of the processing flow of this embodiment. An example of the processing flow of this embodiment will be described with reference to FIG.
First, transaction data including the planned transaction amount is transmitted (transaction data transmission step S0701). Next, the transaction propriety data including the propriety of the transaction is received according to the transaction data transmitted in the step S1701 (transaction propriety data receiving step S1702). Further, the transaction approval/disapproval data acquired in step 1702 is stored in a chip-type electronic device that can be inserted into and removed from another electronic device (transaction approval/disapproval data storage step 1703). Further, transaction execution data is generated based on the transaction permission/inhibition data accumulated in step 1703 (transaction execution data generation step 1704). Further, the transaction execution data generated in step 1704 is stored in the chip-type electronic device (transaction execution data storage step 1705). Finally, the transaction execution data accumulated in step 1705 is transmitted from the chip type electronic device to the POS terminal device by a communication method using a contactless (RF) tag (transaction execution data transmission step 1706).
<A brief description of the effect of the fourth embodiment>
By using the transaction system of the present embodiment, by adding the function of the chip-type electronic device of the present embodiment to an IC card or the like that has already been used in some kind of payment system, many payment functions can be integrated into a single chip. It can be mounted on electronic devices such as IC cards. Even when a dedicated chip-type electronic device (IC card or the like) is used in the transaction system of the present embodiment, it is more convenient to carry than a so-called mobile phone or the like.

本願発明を利用することにより、携帯電話に代表される携帯端末装置を利用したクレジットシステムによる決済を、当該決済における与信処理のための負担を店舗側(POS端末装置)にかけることなく、かつ、暗号化技術のみに依存せずにセキュリティを確保して行うことができるようになる。また、こうしてクレジットシステム等による決済が促進されれば、キャッシャーに現金を一切置かずにクレジットシステム等のみで決済をすることもでき、現金の盗難等の不正行為を防止できる側面も兼ねあわせている。
又、コンビニエンスストア等のように、小額の決済を短時間に多数人について行うような商業店舗等でも、携帯電話を利用したクレジットシステムによる決済を促進される可能性がある。又インターネット回線網を利用したネット取引若しくは法人間の決済においても、当該決済における与信処理のための負担を取引サーバにかけることなく、かつ、暗号化技術のみに依存せずにセキュリティを確保できるようになる。
By using the invention of the present application, payment by a credit system using a mobile terminal device typified by a mobile phone can be performed without burdening the store side (POS terminal device) for credit processing in the payment, and Security can be ensured without depending only on the encryption technology. In addition, if payment by the credit system is promoted in this way, it is possible to settle only by the credit system without placing any cash in the cashier, and it is also possible to prevent fraud such as theft of cash. .
Further, even in a commercial store where a small amount of money is settled for a large number of people in a short time, such as a convenience store, there is a possibility that payment by a credit system using a mobile phone will be promoted. In addition, it is possible to secure security without burdening the transaction server for credit processing in the settlement and without relying only on encryption technology, even in internet transactions using the Internet network or settlement between corporations. become.

Claims (16)

取引予定額を含む取引データを送信する取引データ送信部と、
前記取引データ送信部から送信された取引データに応じて取引の可否を含む取引可否データを受信する取引可否データ受信部と、
前記取引可否データ受信部で受信した取引可否データに基づいて取引実行データを生成する取引実行データ生成部と、
前記取引実行データ生成部で生成された取引実行データをPOS端末装置に送信する取引実行データ送信部と、
を有する携帯端末装置と、
前記携帯端末装置の前記取引実行データ送信部から送信された取引実行データを取得する取引実行データ取得部と、
前記取引実行データ取得部で取得した取引実行データに基づいて決済のためのデータである決済データを生成する決済データ生成部と、
前記決済データ生成部で生成された決済データを決済情報管理サーバに送信する決済データ送信部と、
を有するPOS端末装置と、
前記携帯端末装置の前記取引データ送信部から送信された取引データを受信する取引データ受信部と、
前記取引データ受信部で受信した取引データに基づいて前記取引可否データを生成する取引可否データ生成部と、
前記取引可否データ生成部で生成された取引可否データを前記携帯端末装置に送信する取引可否データ送信部と、
前記POS端末装置の前記決済データ送信部から送信された決済データを受信する決済データ受信部と、
前記決済データ受信部で受信した決済データと、前記取引可否データ送信部から送信された取引可否データとを照合する取引照合部と、
を有する決済情報管理サーバと、からなり、
前記決済情報管理サーバの前記取引照合部は、前記取引可否データ生成部が生成した取引可否データに含まれる前記決済情報管理サーバのみが解読可能な暗号化された取引識別情報と、前記決済情報管理サーバから前記取引可否データに含まれて携帯端末装置に送信され、前記携帯端末装置から取引実行データに含まれて前記POS端末装置に送信され、前記POS端末装置から決済データに含まれて送信された前記決済情報管理サーバのみが解読可能な暗号化された取引識別情報と、を比較することで前記照合を行う取引システム。
A transaction data transmission unit that transmits transaction data including a planned transaction amount,
A transaction propriety data receiving unit that receives transaction propriety data including propriety of a transaction according to the transaction data transmitted from the transaction data transmission unit;
A transaction execution data generation unit that generates transaction execution data based on the transaction feasibility data received by the transaction feasibility data reception unit;
A transaction execution data transmission unit for transmitting the transaction execution data generated by the transaction execution data generation unit to a POS terminal device;
A mobile terminal device having
A transaction execution data acquisition unit that acquires the transaction execution data transmitted from the transaction execution data transmission unit of the mobile terminal device;
A payment data generation unit that generates payment data that is data for payment based on the transaction execution data acquired by the transaction execution data acquisition unit;
A payment data transmission unit that transmits the payment data generated by the payment data generation unit to a payment information management server;
A POS terminal device having
A transaction data receiving unit that receives the transaction data transmitted from the transaction data transmitting unit of the mobile terminal device;
A transaction propriety data generation unit that generates the transaction propriety data based on the transaction data received by the transaction data reception unit,
A transaction permission/prohibition data transmission unit for transmitting the transaction permission/prohibition data generated by the transaction permission/prohibition data generation unit to the mobile terminal device;
A payment data receiving unit that receives the payment data transmitted from the payment data transmitting unit of the POS terminal device;
A transaction collating unit that collates the settlement data received by the settlement data receiving unit and the transaction feasibility data transmitted from the transaction feasibility data transmitting unit,
And a payment information management server having
The transaction verification unit of the payment information management server includes encrypted transaction identification information that is readable only by the payment information management server included in the transaction approval/disapproval data generated by the transaction approval/disapproval data generation unit, and the payment information management. It is included in the transaction approval/disapproval data from the server and is transmitted to the mobile terminal device, the mobile terminal device is included in the transaction execution data and is transmitted to the POS terminal device, and is transmitted from the POS terminal device in the settlement data. The transaction system for performing the collation by comparing with the encrypted transaction identification information that can be decrypted only by the payment information management server.
前記取引実行データ生成部は、前記取引可否データ受信部で受信した一の取引可否データに基づいて複数の取引実行データを生成することが可能である請求の範囲1に記載の取引システム。The transaction system according to claim 1, wherein the transaction execution data generation unit is capable of generating a plurality of transaction execution data based on one transaction permission/inhibition data received by the transaction permission/inhibition data reception unit. 前記携帯端末装置は、他の電子機器に抜差し可能なチップ型電子機器である請求の範囲1又は2に記載の取引システム。The transaction system according to claim 1, wherein the mobile terminal device is a chip-type electronic device that can be inserted into and removed from another electronic device. 前記POS端末装置を取引サーバに代えて構成した請求の範囲1から3のいずれかに記載の取引システムであって、
前記取引サーバは、
前記取引実行データを、インターネット回線網を介して取得する取引実行データ取得部と、
前記取引実行データ取得部で取得した取引実行データに基づいて決済のためのデータである決済データを生成する決済データ生成部と、
前記決済データ生成部で生成された決済データを決済情報管理サーバに送信する決済データ送信部と、
を有する取引システム。
The transaction system according to any one of claims 1 to 3, wherein the POS terminal device is configured in place of a transaction server,
The transaction server is
A transaction execution data acquisition unit for acquiring the transaction execution data via the Internet network;
A payment data generation unit that generates payment data that is data for payment based on the transaction execution data acquired by the transaction execution data acquisition unit;
A payment data transmission unit that transmits the payment data generated by the payment data generation unit to a payment information management server;
Trading system with.
前記携帯端末装置を固定端末装置に代えて構成した請求の範囲1又は2に記載の取引システムであって、
前記固定端末装置は、
取引予定額を含む取引データを、インターネット回線網を介して送信する取引データ送信部と、
前記取引データ送信部から送信された取引データに応じて取引の可否を含む取引可否データを受信する取引可否データ受信部と、
前記取引可否データ受信部で受信した取引可否データに基づいて取引実行データを生成する取引実行データ生成部と、
前記取引実行データ生成部で生成された取引実行データを、インターネット回線網を介してPOS端末装置又は前記取引サーバに送信する取引実行データ送信部と、
を有する取引システム。
The transaction system according to claim 1 or 2, wherein the mobile terminal device is replaced with a fixed terminal device,
The fixed terminal device,
A transaction data transmission unit that transmits transaction data including a transaction amount, via the Internet network,
A transaction propriety data receiving unit that receives transaction propriety data including propriety of a transaction according to the transaction data transmitted from the transaction data transmission unit;
A transaction execution data generation unit that generates transaction execution data based on the transaction feasibility data received by the transaction feasibility data reception unit;
A transaction execution data transmission unit that transmits the transaction execution data generated by the transaction execution data generation unit to a POS terminal device or the transaction server via an Internet network.
Trading system with.
請求の範囲1に記載のPOS端末装置。The POS terminal device according to claim 1. 請求の範囲4に記載の取引サーバ。The transaction server according to claim 4. 請求の範囲1に記載の携帯端末装置。The mobile terminal device according to claim 1. 請求の範囲5に記載の固定端末装置。The fixed terminal device according to claim 5. 請求の範囲1に記載の決済情報管理サーバ。The payment information management server according to claim 1. 取引予定額を含む取引データを送信する取引データ送信ステップと、
前記取引データ送信ステップで送信された取引データに応じて取引の可否を含む取引可否データを受信する取引可否データ受信ステップと、
前記取引可否データ受信ステップで受信した取引可否データに基づいて取引実行データを生成する取引実行データ生成ステップと、
前記取引実行データ生成ステップで生成された取引実行データをPOS端末装置に送信する取引実行データ送信ステップと、
を電子計算機に実行させる取引プログラム。
A transaction data transmitting step for transmitting transaction data including a planned transaction amount,
A transaction propriety data receiving step of receiving transaction propriety data including propriety of transaction according to the transaction data transmitted in the transaction data transmitting step;
A transaction execution data generation step of generating transaction execution data based on the transaction propriety data received in the transaction propriety data receiving step,
A transaction execution data transmission step of transmitting the transaction execution data generated in the transaction execution data generation step to a POS terminal device;
A trading program that causes an electronic computer to execute.
取引実行データを取得する取引実行データ取得ステップと、
前記取引実行データ取得ステップで取得した取引実行データに基づいて決済のためのデータである決済データを生成する決済データ生成ステップと、
前記決済データ生成ステップで生成された決済データを決済情報管理サーバに送信する決済データ送信ステップと、
を電子計算機に実行させる取引プログラムであって、
前記取引実行データは、
取引予定額を含む取引データに応じて受信される取引の可否を含む取引可否データに基づいて生成されることを特徴とする取引プログラム。
A transaction execution data acquisition step of acquiring transaction execution data,
A payment data generation step of generating payment data that is data for payment based on the transaction execution data acquired in the transaction execution data acquisition step;
A payment data transmitting step of transmitting the payment data generated in the payment data generating step to a payment information management server;
Is a trading program that causes a computer to execute
The transaction execution data is
A transaction program generated based on transaction propriety data including propriety of a transaction received according to transaction data including a planned transaction amount.
取引予定額を含む取引データを受信する取引データ受信ステップと、
前記取引データ受信ステップで受信した取引データに基づいて前記取引可否データを生成する取引可否データ生成ステップと、
前記取引可否データ生成ステップで生成された取引可否データを送信する取引可否データ送信ステップと、
決済のためのデータである決済データを受信する決済データ受信ステップと、
前記取引可否データ生成ステップで生成された前記取引可否データに含まれる暗号化された取引識別情報及び前記決済データ受信ステップで受信した決済データに含まれる暗号化された取引識別情報を復号して解読する取引識別情報解読ステップと、
前記取引識別情報解読ステップで解読した、前記取引可否データに含まれる取引識別情報と、前記決済データに含まれる取引識別情報とを比較することで、前記決済データ受信ステップで受信した決済データと、前記取引可否データ送信ステップで送信された取引可否データとを照合する取引照合ステップと、
を電子計算機に実行させる取引プログラムであって、
前記決済データは、
前記取引可否データに基づいて生成される取引実行データから生成されることを特徴とする取引プログラム
A transaction data receiving step of receiving transaction data including a planned transaction amount, and
A transaction feasibility data generating step of generating the transaction feasibility data based on the transaction data received in the transaction data receiving step,
A transaction feasibility data transmitting step of transmitting the transaction feasibility data generated in the transaction feasibility data generating step,
A payment data receiving step of receiving payment data which is data for payment,
The encrypted transaction identification information included in the transaction availability data generated in the transaction availability data generation step and the encrypted transaction identification information included in the payment data received in the payment data reception step are decrypted and decrypted. Transaction identification information decoding step
By comparing the transaction identification information included in the transaction approval/disapproval data and the transaction identification information included in the payment data, which is decoded in the transaction identification information decoding step, the payment data received in the payment data receiving step, A transaction collating step of collating the transaction feasibility data transmitted in the transaction feasibility data transmitting step,
Is a trading program that causes a computer to execute
The payment data is
A transaction program generated from transaction execution data generated based on the transaction feasibility data.
取引予定額を含む取引データを送信する取引データ送信ステップと、
前記取引データ送信ステップで送信された取引データを受信する取引データ受信ステップと、
前記取引データ受信ステップで受信した取引データに基づいて前記取引可否データを生成する取引可否データ生成ステップと、
前記取引可否データ生成ステップで生成された取引可否データを送信する取引可否データ送信ステップと、
前記取引データ送信ステップから送信された取引データに応じて取引の可否を含む取引可否データを受信する取引可否データ受信ステップと、
前記取引可否データ受信ステップで受信した取引可否データに基づいて取引実行データを生成する取引実行データ生成ステップと、
前記取引実行データ生成ステップで生成された取引実行データを送信する取引実行データ送信ステップと、
前記取引実行データ送信ステップで送信された取引実行データを取得する取引実行データ取得ステップと、
前記取引実行データ取得ステップで取得した取引実行データに基づいて決済のためのデータである決済データを生成する決済データ生成ステップと、
前記決済データ生成ステップで生成された決済データを送信する決済データ送信ステップと、
前記決済データ送信ステップで送信された決済データを受信する決済データ受信ステップと、
前記取引可否データ生成ステップで生成された前記取引可否データに含まれる暗号化された取引識別情報及び前記決済データ受信ステップで受信した決済データに含まれる暗号化された取引識別情報を復号して解読する取引識別情報解読ステップと、
前記取引識別情報解読ステップで解読した、前記取引可否データに含まれる取引識別情報と、前記決済データに含まれる取引識別情報とを比較することで、前記決済データ受信ステップで受信した決済データと、前記取引可否データ送信ステップから送信された取引可否データとを照合する取引照合ステップと、
を電子計算機に実行させる取引プログラム。
A transaction data transmitting step for transmitting transaction data including a planned transaction amount,
A transaction data receiving step of receiving the transaction data transmitted in the transaction data transmitting step,
A transaction feasibility data generating step of generating the transaction feasibility data based on the transaction data received in the transaction data receiving step,
A transaction feasibility data transmitting step of transmitting the transaction feasibility data generated in the transaction feasibility data generating step,
A transaction propriety data receiving step of receiving transaction propriety data including propriety of a transaction according to the transaction data transmitted from the transaction data transmitting step;
A transaction execution data generation step of generating transaction execution data based on the transaction propriety data received in the transaction propriety data receiving step,
A transaction execution data transmission step of transmitting the transaction execution data generated in the transaction execution data generation step,
A transaction execution data acquisition step of acquiring the transaction execution data transmitted in the transaction execution data transmission step,
A payment data generation step of generating payment data that is data for payment based on the transaction execution data acquired in the transaction execution data acquisition step;
A payment data transmitting step of transmitting the payment data generated in the payment data generating step,
A payment data receiving step of receiving the payment data transmitted in the payment data transmitting step,
The encrypted transaction identification information included in the transaction availability data generated in the transaction availability data generation step and the encrypted transaction identification information included in the payment data received in the payment data reception step are decrypted and decrypted. Transaction identification information decoding step
By comparing the transaction identification information contained in the transaction approval/disapproval data and the transaction identification information contained in the payment data, which is decrypted in the transaction identification information decoding step, with the payment data received in the payment data receiving step, A transaction collation step of collating the transaction propriety data transmitted from the transaction propriety data transmitting step,
A trading program that causes an electronic computer to execute.
前記決済情報管理サーバは、さらに、
前記取引照合部における取引識別情報の照合結果が同一である場合に、前記取引識別情報を含む決済データで示される金額が、予め定めた金額を超えるか否かを判断する決済金額判断部を有し、
前記決済金額判断部は、さらに、
決済データが示す金額が、予め定められた金額を超えないと判断された前記決済データを期間集計する期間集計手段と、
前記期間集計手段にて集計された決済データを1のトランザクションとして処理するための処理データに再構成する処理データ構成手段と、
を有する請求の範囲1から5のいずれかに記載する取引システム。
The payment information management server further includes
A transaction amount determination unit that determines whether or not the amount indicated by the transaction data including the transaction identification information exceeds a predetermined amount when the transaction identification information in the transaction collation unit has the same collation result. Then
The settlement amount determination unit further includes
A period totalizing means for totalizing the period of the settlement data determined to have an amount indicated by the settlement data not exceeding a predetermined amount,
Processing data configuration means for reconfiguring the payment data aggregated by the period aggregation means into processing data for processing as one transaction,
The trading system according to any one of claims 1 to 5, further comprising:
前記決済情報管理サーバは、さらに、
前記取引照合部における取引識別情報の照合結果が同一である場合に、前記決済データで示される金額が、予め定めた金額を超えるか否かを判断する決済金額判断部を有し、
前記決済金額判断部は、さらに、
決済データが示す金額が予め定められた金額を超えないと判断された前記決済データを、予め定められた金額に達するまで集計する金額集計手段と、
前記金額集計手段にて集計された決済データを1のトランザクションとして処理するための処理データに再構成する処理データ構成手段と、
を有する請求の範囲1から5のいずれかに記載する取引システム。
The payment information management server further includes
A transaction amount determination unit that determines whether or not the amount indicated by the payment data exceeds a predetermined amount when the transaction identification information in the transaction matching unit has the same matching result,
The settlement amount determination unit further includes
An amount totalizing means for totaling the settlement data, which is determined that the amount indicated by the settlement data does not exceed a predetermined amount, until the amount reaches a predetermined amount,
Processing data configuration means for reconfiguring the payment data aggregated by the amount aggregation means into processing data for processing as one transaction,
The trading system according to any one of claims 1 to 5, further comprising:
JP2004568507A 2003-02-20 2003-09-03 Mobile/Internet commerce payment system Pending JPWO2004075081A1 (en)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2003043405 2003-02-20
JP2003043405 2003-02-20
PCT/JP2003/011234 WO2004075081A1 (en) 2003-02-20 2003-09-03 Mobile net commerce settlement system

Publications (1)

Publication Number Publication Date
JPWO2004075081A1 true JPWO2004075081A1 (en) 2006-06-01

Family

ID=32905429

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2004568507A Pending JPWO2004075081A1 (en) 2003-02-20 2003-09-03 Mobile/Internet commerce payment system

Country Status (3)

Country Link
JP (1) JPWO2004075081A1 (en)
AU (1) AU2003261898A1 (en)
WO (1) WO2004075081A1 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2016534459A (en) * 2013-08-30 2016-11-04 ジエマルト・エス・アー How to authenticate a transaction

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007219959A (en) * 2006-02-18 2007-08-30 Sii Data Service Kk Order settlement system, order settlement method, and mobile terminal having order settlement function
EP2118837A4 (en) * 2007-01-09 2012-07-11 Visa Usa Inc Mobile phone payment process including threshold indicator
US20120084162A1 (en) * 2010-10-05 2012-04-05 Merrill Brooks Smith Systems and methods for conducting a composite bill payment transaction
FR2992754B1 (en) * 2012-06-28 2014-07-11 Bruno Morel METHOD AND DEVICE FOR COMMUNICATING BETWEEN TERMINAL AND RECORDING MACHINE

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH09218903A (en) * 1995-12-14 1997-08-19 Cybercash Inc Electronic transfer system and method therefor
WO2001009807A1 (en) * 1999-08-02 2001-02-08 E-Mark Systems Inc. Electronic settlement system, and settlement device and terminal
WO2001035570A1 (en) * 1999-11-05 2001-05-17 Netcharge.Com, Inc. Payment method and system for online commerce
JP2001344537A (en) * 2000-05-31 2001-12-14 Ntt Docomo Inc Electronic value system, communication terminal and server
JP2001344545A (en) * 2000-03-29 2001-12-14 Ibm Japan Ltd Processing system, server, processing terminal, communication terminal, processing method, data managing method, processing performing method and program
JP2001527672A (en) * 1997-04-15 2001-12-25 テレフオンアクチーボラゲツト エル エム エリクソン(パブル) Telecommunication / data communication payment method and apparatus
JP2002024730A (en) * 2000-07-10 2002-01-25 Hitachi Ltd Electronic payment method and system by cellular phone
JP2003006544A (en) * 2001-06-21 2003-01-10 Mitsubishi Electric Corp System terminal, electronic settlement system and electronic settlement method

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5991750A (en) * 1997-10-24 1999-11-23 Ge Capital System and method for pre-authorization of individual account transactions
EP0917119A3 (en) * 1997-11-12 2001-01-10 Citicorp Development Center, Inc. Distributed network based electronic wallet
WO2001097118A1 (en) * 2000-06-14 2001-12-20 Takako Jogu Settling method using mobile phone and mobile phone
JP2004513438A (en) * 2000-10-31 2004-04-30 ウリ テクノロジー インク Electronic commerce system and method
JP2002366869A (en) * 2001-06-11 2002-12-20 Sony Corp Electronic commerce assisting method and electronic commerce method using the same

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH09218903A (en) * 1995-12-14 1997-08-19 Cybercash Inc Electronic transfer system and method therefor
JP2001527672A (en) * 1997-04-15 2001-12-25 テレフオンアクチーボラゲツト エル エム エリクソン(パブル) Telecommunication / data communication payment method and apparatus
WO2001009807A1 (en) * 1999-08-02 2001-02-08 E-Mark Systems Inc. Electronic settlement system, and settlement device and terminal
WO2001035570A1 (en) * 1999-11-05 2001-05-17 Netcharge.Com, Inc. Payment method and system for online commerce
JP2001344545A (en) * 2000-03-29 2001-12-14 Ibm Japan Ltd Processing system, server, processing terminal, communication terminal, processing method, data managing method, processing performing method and program
JP2001344537A (en) * 2000-05-31 2001-12-14 Ntt Docomo Inc Electronic value system, communication terminal and server
JP2002024730A (en) * 2000-07-10 2002-01-25 Hitachi Ltd Electronic payment method and system by cellular phone
JP2003006544A (en) * 2001-06-21 2003-01-10 Mitsubishi Electric Corp System terminal, electronic settlement system and electronic settlement method

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2016534459A (en) * 2013-08-30 2016-11-04 ジエマルト・エス・アー How to authenticate a transaction

Also Published As

Publication number Publication date
AU2003261898A1 (en) 2004-09-09
WO2004075081A1 (en) 2004-09-02

Similar Documents

Publication Publication Date Title
US8025223B2 (en) System and method for mass transit merchant payment
KR100366060B1 (en) Optical payment transceiver and system using the same
US6764001B1 (en) Electronic money system and transaction method using the same
AU2006268199B2 (en) Apparatus and method for integrated payment and electronic merchandise transfer
US9280689B2 (en) Method and apparatus for conducting offline commerce transactions
TWI570640B (en) Mechanism to allow the use of disposable cards on a system designed to accept cards conforming to the standards of the global payments industry
CN101840550A (en) Method for realizing purposes of generating and paying bill on site
US20060004658A1 (en) Method of processing credit payments at delivery
US20100241536A1 (en) Electronic settlement method and electronic settlement device
KR100792959B1 (en) Filling money, payment and supplement service system using ic-card and method using the same at on-line and off-line
KR100945415B1 (en) Systen and Method for Processing Settlement by Overseas Card and Card Terminal Device
JP2004062771A (en) Settlement system using account of internet bank
KR20180089136A (en) Electronic transation method and system using virtual payment information
JPWO2004075081A1 (en) Mobile/Internet commerce payment system
CN101258509A (en) Apparatus and method for integrated payment and electronic merchandise transfer
TW587224B (en) Mobile payment method
US20020103767A1 (en) Transaction and logistics integrated management system (TALISMAN) for secure credit card payment and verified transaction delivery
JP2000306032A (en) Electronic currency utilizing portable telephone and electronic wallet
WO2014025738A1 (en) Transferable-ownership payment instrument and methods of use therefor
KR20100138068A (en) A system for accumulating the changes and the method of providing the change accumulation service
KR20100122329A (en) An tour credit card issuing and settlement system and the method thereof
KR20040072537A (en) System for Exchange of Electronic Currency and Electronic Securities
KR20020024096A (en) System and Method for transaction function using electronic purse
KR20100099784A (en) System and method for managing exchange traffic card with check card application and recording medium
JP2007114898A (en) Prepaid ic card check system

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20081209

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20090121

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20090407