JP7497833B2 - Methods and systems for charging and depositing legal tender value, electronic money, and other values such as points - Google Patents

Description

The present invention relates to a method and system for charging various types of value.

Traditionally, payments using legal tender value, electronic money, and other intangible assets with monetary value such as points (hereafter referred to as "value") have been widespread. For example, in a typical electronic money payment system, a user charges a certain amount of electronic money in advance or immediately using a specified method, and hands it over to an affiliated store that is also an electronic money user to purchase goods or services sold by the affiliated store. The affiliated store then receives payment such as cash from the electronic money issuer in exchange for electronic money equivalent to the sales proceeds.

Methods for charging electronic money include charging with cash, as well as charging methods linked to a credit card, bank account, or other means that can guarantee payment capacity (see, for example, Patent Document 1). In addition, a method has been disclosed that allows users to select from a selection of multiple charging methods (funding sources) (see, for example, Patent Document 2).

Patent No. 6473487 JP 2018-160267 A

However, when a provider of a payment medium such as a payment card for electronic money or other value or a code that can be used for payment provides the payment medium to an individual or corporate user, the provider is limited to the charging method provided in advance by the provider, resulting in a lack of flexibility.

Therefore, the present invention aims to provide a more flexible method for charging value.

A method of charging value provided by a media provider that offers a settlement medium for payment by value, in which when a user purchases a product or service provided by an affiliated store or business owner via value, an authorization request for the transaction of the product or service is received from the affiliated store or business owner terminal, the user's value balance is confirmed, and when the balance falls below the purchase price of the product or service, value is charged from a funding source preset by the user.

The present invention provides a more flexible method for charging value.

1 is a block diagram showing a charging system according to a first embodiment of the present invention; 2 is a functional block diagram showing the card company terminal 100 of FIG. 1. FIG. 2 is a functional block diagram showing a user terminal 200 of FIG. 1. FIG. 2 is a functional block diagram showing the store terminal 200 of FIG. 1 . 2 is a schematic diagram showing an example of user data stored in the server 100. FIG. 2 is a schematic diagram showing an example of electronic message data stored in the server 100; FIG. 3 is an example of a flowchart relating to a charging method according to the first embodiment of the present invention. 10 is a modified flowchart of the charging method according to the first embodiment of the present invention. 10 is an example of a flowchart relating to a charging method according to a second embodiment of the present invention. 13 is an example of a flowchart relating to a charging method according to a third embodiment of the present invention. 13 is an example of a flowchart relating to a charging method according to a fourth embodiment of the present invention.

The following describes an embodiment of the present invention with reference to the drawings. Note that the embodiment described below does not unduly limit the contents of the present disclosure described in the claims. Furthermore, not all of the components shown in the embodiment are necessarily essential components of the present disclosure.

(Embodiment 1)
<Configuration>
FIG. 1 is a block diagram showing a charging system according to a first embodiment of the present invention.
This embodiment is applicable to values having a certain monetary value, such as legal currency value, electronic money, and various points, and can also be applied to payment media provided by various media providers, such as card media such as prepaid cards, sheet media printed with QR codes or the like, electronic media such as web pages displaying QR codes or the like, and virtual media such as web services and apps. However, in this embodiment, for ease of explanation, a system will be explained using as an example a system composed of a card company terminal 100, which is a terminal of a card company that issues a prepaid card for using electronic money, a user terminal 200, which is a terminal of a user who uses the card, a store terminal 300, which is a terminal of an affiliated store where electronic money issued by the card company can be used in exchange for goods or services, and a funding source from which the user charges the electronic money.

Card companies are known as issuers of credit cards and prepaid cards, and issue cards to users, manage credit, and in the case of prepaid cards, manage the user's electronic money balance and authorize (approve) the transaction when the user uses the prepaid card in exchange for a product at an affiliated store. Users can be individual users or corporate users, and in the case of a corporation, the corporation may issue cards to other corporations as a secondary issuer (partner) and provide services by adding functions that the company provides to the card. In addition, if the user is a corporation and the card company issues the card as a corporate card, the user may issue the card to an employee, who may use the card for business-related purposes such as business trips, meetings, and entertainment.

Card companies can also issue what are called virtual cards, which are prepaid cards that are displayed via an application that the user installs on a mobile device such as a smartphone, or, upon request from the user, can issue what are called physical cards, which are magnetic cards or IC cards with built-in IC chips. Generally, virtual cards are used for transactions such as purchasing products online, such as online shopping, while physical cards are used for transactions such as purchasing products or services in physical stores.

The card company terminal 100, the user terminal 200, the store terminal 300, and the funding source 400 are connected via a network NW. The network NW is composed of the Internet, an intranet, a wireless LAN (Local Area Network), a WAN (Wide Area Network), etc.

The card company terminal 100 may be, for example, a general-purpose computer such as a workstation or personal computer, or may be logically realized by cloud computing. In this embodiment, for convenience of explanation, one card company terminal is shown as an example, but this is not limited to this and multiple terminals may be used.

The user terminal 200 is, for example, an information processing device such as a personal computer or a tablet terminal, but may also be configured as a smartphone, mobile phone, PDA, etc.

The store terminal 300 is a terminal installed at the affiliated store of the card, and may be, for example, a POS/CCT/CAT terminal installed at a supermarket, shopping center, convenience store, etc., but may also be a personal computer, smartphone, tablet terminal, etc. with an application with similar functions. It may also be replaced by an owner's terminal installed at a business owner who carries out business activities, not limited to a store. The store terminal 300 allows operations such as credit card, prepaid card, and debit card settlement at the storefront of the affiliated store. The store terminal 300 is also connected to the card company terminal 100 and terminals of other credit card issuers (not shown) via the network NW so that it can communicate with them. It may also be connected to the card terminal 100, etc. via a card system of an international brand such as VISA (registered trademark).

In this embodiment, system 1 is described as having a card company terminal 100, a user terminal 200, a store terminal 300, and a funding source 400, but as described above, the secondary issuer (partner) can also be the user terminal, and in an example where the partner's card user is another corporation or individual, the partner can be replaced with the card company (card company terminal 100) in this system, and the user of the card issued by the partner can be replaced with the user (user terminal 200) in this system. When the partner is replaced with a card company, it is also possible to use the API (Application Programming Interface) of the original card company.

Figure 2 is a functional block diagram of the card company terminal 100 in Figure 1. The card company terminal 100 includes a communication unit 110, a memory unit 120, and a control unit 130.

The communication unit 110 is a communication interface for communicating with the user terminal 200 and the store terminal 300 via the network NW, and communication is performed according to a communication protocol such as TCP/IP (Transmission Control Protocol/Internet Protocol).

The memory unit 120 stores various control processes and programs for executing the functions of the control unit 130, input data, etc., and is composed of RAM (Random Access Memory), ROM (Read Only Memory), etc. The memory unit 120 also has a user data storage unit 121 that stores various data required for authorization (approval) of a transaction when a card user purchases a product or service at an affiliated store and for charging electronic money, and a message data storage unit 122 that stores data related to authorization messages received from affiliated stores, etc. Furthermore, the memory unit 120 can also temporarily store data communicated with the user terminal 200 and the store terminal 300. Note that a database (not shown) storing various data may be constructed outside the memory unit 120.

The control unit 130 controls the overall operation of the card company terminal 100 by executing the programs stored in the memory unit 120, and is composed of a CPU (Central Processing Unit), a GPU (Graphics Processing Unit), etc. The functions of the control unit 130 include a request reception unit 131 that receives instructions from the user terminal 200 or the store terminal 300, an approval processing unit 132 that performs processing for approval of an authorization request, and a charge processing unit 133 that performs processing related to charging electronic money. The request reception unit 131, approval processing unit 132, and charge processing unit 133 are started by the programs stored in the memory unit 120 and executed by the card company terminal 100, which is a computer (electronic calculator).

The request receiving unit 131 receives a request from the user terminal 200 via the communication unit 110, for example, when the user makes a specific request, such as registering user information or issuing a virtual or physical prepaid card, in a user interface displayed via an application installed on the user terminal 200. The request receiving unit 131 also receives a request from the store terminal 300 via the communication unit 110, for example, when the user uses a card to purchase a product or service at an affiliated store, reads the magnetic card with a reader in the store terminal 300, and sends an authorization message to make an authorization request.

When the approval processing unit 132 receives an authorization request for a specific transaction from the store terminal 300, it performs a specified process to approve the transaction.

The charge process 133 performs the charge process of the user's electronic money upon request from the user terminal 200 or by automatic processing.

Figure 3 is a functional block diagram showing the user terminal 200 of Figure 1. The user terminal 200 includes a communication unit 210, a display operation unit 220, a storage unit 230, and a control unit 240.

The communication unit 210 is a communication interface for communicating with the card company terminal 100 via the network NW, and communication is performed according to a communication protocol such as TCP/IP.

The display operation unit 220 is a user interface used by the user to input instructions and display text, images, etc. according to input data from the control unit 240, and is composed of a display, keyboard, and mouse if the user terminal 200 is configured as a personal computer, and is composed of a touch panel, etc. if the user terminal 200 is configured as a tablet terminal. This display operation unit 220 is started up by a control program such as an application program stored in the memory unit 230 and executed by the user terminal 200, which is a computer (electronic calculator).

The memory unit 230 stores programs for executing various control processes and functions within the control unit 240, input data, etc., and is composed of RAM, ROM, etc. The memory unit 230 also temporarily stores the contents of communication with the card company terminal 100.

The control unit 240 controls the overall operation of the user terminal 200 by executing the programs stored in the memory unit 230, and is composed of a CPU, GPU, etc.

The card company terminal 100 may be configured to have all or part of the functions of a control program, such as an application program, stored in the user terminal 200.

Figure 4 is a functional block diagram showing the store terminal 300 of Figure 1. The store terminal 300 includes a communication unit 310, a display operation unit 320, a memory unit 330, a reader 340, and a control unit 350.

The communication unit 310 is a communication interface for communicating with the card company terminal 100 via the network NW (or with the international brand card system (not shown) if the communication goes through an international brand card system), and communication is performed according to a communication protocol such as TCP/IP.

The display operation unit 320 is a user interface used by store staff to input instructions and display text, images, etc. according to input data from the control unit 350; if the store terminal 300 is a POS/CCT/CAT terminal, it is composed of a display, buttons, a pointing device, a keyboard, etc.; if it is a personal computer, it is composed of a display, keyboard, mouse, etc.; if the store terminal 300 is a tablet terminal, it is composed of a touch panel, etc. In addition, this display operation unit 220 is started up by a control program such as an application program stored in the memory unit 230 and executed by the user terminal 200, which is a computer (electronic calculator).

The memory unit 330 stores programs for executing various control processes and functions within the control unit 350, input data, etc., and is composed of RAM, ROM, etc. In addition, the memory unit 230 temporarily stores the contents of communication with the card company terminal 100.

Reader 340 and reader 114 are composed of devices such as a magnetic card reader, a barcode reader, and an IC chip reader, and can read information from prepaid cards, credit cards, debit cards, etc.

The control unit 350 controls the overall operation of the store terminal 300 by executing the programs stored in the memory unit 330, and is composed of a CPU, GPU, etc.

Figure 5 is a schematic diagram showing an example of user data stored in server 100.

The user data 1000 shown in FIG. 5 stores various data related to a user who uses a prepaid card. For convenience of explanation, FIG. 5 shows an example of one user (a user identified by user ID "10001"), but information on multiple users can be stored. The various data related to the user include, for example, the user's registration information (in the case of a corporation, the corporation name, representative name, address, and contact information, etc.; in the case of an individual or employee, the name, date of birth, sex, address, and contact information (telephone number, email address, etc.); and in the case of an employee, the employee ID and department, etc.), as well as card information (for example, card number (PAN), card member name, expiration date (EXP), personal identification number (PIN), security code (CAV/CVC2/CVV2/CID), and track data, etc.). Also included is information related to credit (for example, electronic money balance, credit limit, etc.), and the user's funding source information (credit card information, debit card information, bank account information, virtual currency account information, and carrier payment information, etc.)).

Figure 6 is a schematic diagram showing an example of message data stored in server 100.

The message data 2000 shown in FIG. 6 stores various data stored in an authorization message. The various data related to the authorization message includes, for example, information on the card used at the affiliated store, the affiliated store ID, the date and time of use, the amount used, etc.

<Processing flow>
The flow of processing of the charging method executed by the system 1 of this embodiment will be described with reference to Fig. 7. Fig. 7 is an example of a flowchart of the charging method according to the first embodiment of the present invention.

Here, as an example, in order to issue a prepaid card, a user installs an application on his/her user terminal 200, starts the application, registers registration information in a user interface provided, and requests issuance of a card. As the card, a prepaid card called a virtual card, which is displayed via an application installed on the user terminal 200 by the user, and/or a physical card, which is a magnetic card with predetermined card information printed on plastic or an IC card with an IC chip built in, can be issued. The user can use the application in advance to set the desired funding source information (e.g., credit card information, debit card information, bank account information, virtual currency account information, carrier payment information, etc.) for charging electronic money, and charge a predetermined amount of electronic money in advance. Also, charging with cash using an ATM installed in a store such as a convenience store is possible. When the amount of electronic money charged is less than a predetermined amount (e.g., 50,000 yen), charging in predetermined amount units (e.g., 1,000 yen, 5,000 yen, 10,000 yen units) can be selectively used.

First, in the process of SQ101, the user terminal 200 uses a prepaid card to purchase a product or service at an affiliated store. In this case, when the user purchases a product or service at a physical store, the user presents a real prepaid card to the store staff. When the user uses the user terminal 200 to purchase a product or service at an online store, etc., the user inputs information about the virtual card into the purchase screen of the online store.

In the process of SQ102, the store terminal 300 of the affiliated store performs a payment operation for the product or service, and sends an authorization request for the transaction of the product or service to the card company terminal 100. For example, in the case of an online store, the store terminal 300 accepts a purchase request for the product or service from the user terminal 200 via a network and performs payment processing. In the case of a physical store, the store terminal 300 performs payment processing by having a terminal such as a POS/CCT/CAT read the prepaid card. After performing payment processing, the store terminal 300 sends an authorization message and sales data to the card company terminal 100 as an authorization request. Information included in the authorization message includes, for example, the information shown in FIG. 6 (card information, affiliated store ID, date and time, amount used). For example, the authorization message may be a message generated based on the ISO 8583 standard, or a message generated based on the ISO 8583 standard converted into another given format (for example, JSON format) and sent.

Next, in the process of SQ103, when the request reception unit 131 of the card company terminal 100 receives the authorization request, the approval processing unit 132 checks the user's electronic money balance for the amount used. For example, the card company terminal 100 searches for the user ID based on the card number, and refers to the electronic money balance of the target user in the user data 1000 shown in FIG. 5.

Next, in the process of SQ104, the approval processing unit 132 of the card company terminal 100 approves the transaction if the user's electronic money balance is equal to or exceeds the amount used. (If the user's electronic money balance is less than the amount used, the process proceeds to SQ106.)

Next, in the process of SQ105, the communication unit 110 of the card company terminal 100 sends a transaction approval response to the store terminal 300.

In the above SQ103, if the user's electronic money balance is less than the usage amount, then in the process of SQ106, the charge processing unit 133 of the card company terminal 100 checks the registered information in the user data 1000 shown in FIG. 5 and checks the funding source of the user. For example, if the user is an individual or a corporate business, the funding source registered by the individual or corporation (including, but not limited to, credit cards, debit cards, bank accounts, virtual currency accounts, and carrier billing) is identified. Also, if the user is a partner company acting as a secondary business, the funding source registered by the company is confirmed. Also, if the user is linked to an expense-bearing department at a corporate company, the department is identified and the funding source registered by the department is confirmed.

Next, in SQ107, the charge processing unit 133 of the card company terminal 100 charges a predetermined amount of electronic money from the funding source according to the funding source of the user. Here, the charge amount can be either electronic money equivalent to the shortfall in the amount used, or electronic money equivalent to an amount preset by the card company or the user. For example, if the user is a partner company and the funding source registered by the partner company is a bank account, the charge processing unit 133 converts, for example, cash equivalent to the shortfall into electronic money from the bank account, thereby increasing the amount of electronic money. Also, for example, if the user belongs to the sales department of a company, the charge processing unit 133 increases the amount of electronic money from the funding source set for the sales department.

Next, in the process of SQ108, the approval processing unit 132 of the card company terminal 100 confirms that the user's electronic money balance is equal to or exceeds the amount used and approves the transaction, and in the process of SQ109, the communication unit 110 of the card company terminal 100 sends a response of approval of the transaction to the store terminal 300.

As described above, through the charging method of this embodiment, card companies can provide a flexible method of charging electronic money based on the funding source set by the card user. In particular, when a card company issues a card to a corporate enterprise such as a partner company, the corporate enterprise, including the partner company, has a need to utilize its own funding source as a charging resource, and the charging method of this embodiment can flexibly respond to such needs.

(Modification)
FIG. 8 is a modified flowchart of the charging method according to the first embodiment of the present invention.

This modified example has the same basic structure as the charging method shown in Figure 7, but is an electronic money charging method that is particularly applicable when the card user is a corporate enterprise and the corporate enterprise wants to set up a funding source according to its business purposes.

First, in the process of SQ201, the user terminal 200 uses a prepaid card to purchase a product or service at an affiliated store. In this case, when the user purchases a product or service at a physical store, the user presents a real prepaid card to the store staff. When the user uses the user terminal 200 to purchase a product or service at an online store, etc., the user enters information about the virtual card into the purchase screen of the online store.

In the process of SQ202, the store terminal 300 of the affiliated store performs a payment operation for the product or service, and sends an authorization request for the transaction of the product or service to the card company terminal 100. For example, in the case of an online store, the store terminal 300 accepts a purchase request for the product or service from the user terminal 200 via a network and performs payment processing. In the case of a physical store, the store terminal 300 performs payment processing by having a terminal such as a POS/CCT/CAT read the prepaid card. After performing payment processing, the store terminal 300 sends an authorization message and sales data to the card company terminal 100 as an authorization request. Information included in the authorization message includes, for example, the information shown in FIG. 6 (card information, affiliated store ID, date and time, amount used). For example, the authorization message may be a message generated based on the ISO 8583 standard, or a message generated based on the ISO 8583 standard converted into another given format (for example, JSON format) and sent.

Next, in the process of SQ203, when the request reception unit 131 of the card company terminal 100 receives the authorization request, the approval processing unit 132 checks the user's electronic money balance for the amount used. For example, the card company terminal 100 searches for the user ID based on the card number, and refers to the electronic money balance of the target user in the user data 1000 shown in Figure 5.

Next, in the process of SQ204, the approval processing unit 132 of the card company terminal 100 approves the transaction if the user's electronic money balance is equal to or exceeds the amount used. (If the user's electronic money balance is less than the amount used, the process proceeds to SQ206.)

Next, in the processing of SQ205, the communication unit 110 of the card company terminal 100 sends a transaction approval response to the store terminal 300.

If the user's electronic money balance falls below the amount used in SQ203 above, then in processing SQ206, the charge processing unit 133 of the card company terminal 100 checks the business purpose of the transaction and the funding source corresponding to that purpose from the information in the message data 2000 shown in FIG. 6. For example, the store's attributes (e.g., restaurant, hotel, taxi, etc.) are checked from the affiliated store ID in the message data 2000, and if the attribute is a restaurant, the business purpose is determined as entertainment expenses. Then, the funding source corresponding to the business purpose (e.g., including but not limited to credit card, debit card, bank account, virtual currency account, and carrier payment) is identified.

Next, in SQ207, the charge processing unit 133 of the card company terminal 100 charges a predetermined amount of electronic money from the funding source according to the funding source for business use. Here, the charge amount can be either an amount of electronic money equivalent to the shortfall in the amount used, or an amount of electronic money preset by the card company or the user. For example, in the above example, if the funding source for the entertainment expenses was a bank account, the charge processing unit 133 performs a process of converting, for example, cash equivalent to the shortfall into electronic money from the bank account, thereby increasing the amount of electronic money.

Next, in the process of SQ208, the approval processing unit 132 of the card company terminal 100 confirms that the user's electronic money balance is equal to or exceeds the amount used and approves the transaction, and in the process of SQ109, the communication unit 110 of the card company terminal 100 sends a response of approval of the transaction to the store terminal 300.

As described above, through this modified example, card companies can provide a flexible method for charging electronic money based on the funding source set according to the user's business purpose. Note that this modified example can be applied not only to corporate businesses, but also to sole proprietors and individual card users.

<Embodiment 2>
9 is an example of a flowchart relating to a charging method according to a second embodiment of the present invention. This embodiment is a charging method for value such as electronic money that can be applied when an individual or corporation who is a card user wants to set up multiple funding sources. In this embodiment, the basic system configuration is the same as that of the first embodiment shown in FIG. 1, and the basic processing in the card company terminal 100 is the same as the processing according to the first embodiment shown in FIG. 7, so a description of processing other than the processing for charging electronic money from a funding source will be omitted.

First, in the process of SQ301, if the user's electronic money balance is insufficient to cover the amount used to purchase a product or service, the charge processing unit 133 of the card company terminal 100 makes a charge request to the first funding source (e.g., a bank account). In this case, the user can register multiple funding sources in advance as sources for charging, and can set a funding source for priority charging.

In the process of SQ302, the terminal managing the first funding source (e.g., a bank account) accepts a request from the card company terminal 100 and checks the user's account balance. This process can also be performed by the card company terminal 100 obtaining the user's balance information from the first funding source to check the balance. This step can also be omitted if the card company terminal 100 determines an amount in advance (such as a shortfall or a set amount) and requests the first funding source to charge electronic money equivalent to that amount.

Next, in the process of SQ303, the charge processing unit 133 of the card company terminal 100 charges electronic money from the first funding source. If the first funding source is a bank account, a predetermined amount of cash is converted into electronic money and charged. Here, the charge amount can be an amount of electronic money equivalent to the shortfall in the amount used, or an amount of electronic money preset by the card company or user. When the balance of the electronic money after charging is equal to or exceeds the amount used inquired from the store terminal, the card company terminal 100 ends the charge process.

If the balance of electronic money is still insufficient to cover the usage amount even after charging electronic money from the first funding source, the charge processing unit 133 of the card company terminal 100 requests a charge from the second funding source (e.g., a credit card) as processing of SQ304. In this case, the user can set the order in which to request a charge from multiple funding sources.

Next, in the process of SQ305, the terminal managing the second funding source (e.g., a credit card) accepts a request from the card company terminal 100 and checks the user's account balance. In this process, the card company terminal 100 can also check the balance by obtaining the user's balance information from the second funding source. Here, for example, when requesting a charge from the credit card company, the credit card company terminal checks the user's available amount, etc., to check the balance. Also, this step can be omitted if the card company terminal 100 determines an amount in advance (such as a shortfall or a set amount) and requests the second funding source to charge electronic money equivalent to that amount.

Next, in the process of SQ306, the charge processing unit 133 of the card company terminal 100 charges electronic money from the second funding source. If the second funding source is a credit card, the charge processing unit 133 of the card company terminal 100 charges electronic money equivalent to a predetermined amount and transmits the amount information to the credit card company terminal. Here, the charge amount can be either the electronic money equivalent to the shortfall in the amount used, or the electronic money equivalent to an amount preset by the card company or the user. When the balance of the electronic money after charging is equal to or exceeds the amount used inquired from the store terminal, the card company terminal 100 ends the charge process. Note that if the electronic money balance is insufficient for the amount used, or if another funding source is set, the card company terminal 100 makes a charge request to that funding source, or sends a notice of non-approval of the transaction to the store terminal.

As described above, through this embodiment, card companies can provide users with even more flexible methods for charging electronic money.

<Embodiment 3>
Fig. 10 is an example of a flowchart relating to a charging method according to a third embodiment of the present invention. This embodiment is another example of a charging method for value such as electronic money that can be applied when an individual or corporation who is a card user wants to set up multiple funding sources. Note that in this embodiment, the basic system configuration is the same as the configuration of the first embodiment shown in Fig. 1, and the basic processing in the card company terminal 100 is the same as the processing according to the first embodiment shown in Fig. 7, so a description of processing other than the processing for charging electronic money from a funding source will be omitted.

First, in the process of SQ401, if the user's electronic money balance is insufficient to cover the amount used to purchase a product or service, the charge processing unit 133 of the card company terminal 100 sets, for multiple pre-set funding sources, a first funding source (e.g., a bank account) with a relatively high priority and a second funding source (e.g., another bank account) with a low priority, and checks the balances of these funding sources. The amount to be charged from the first funding source and the amount to be charged from the second funding source can then be determined based on a certain ratio or other criteria, and can be determined so that the total of the charge amounts from both funding sources is the same as or exceeds the shortfall.

Next, in processing SQ402, the charge processing unit 133 of the card company terminal 100 makes a charge request to the first funding source (e.g., a bank account).

Next, in the process of SQ403, the charge processing unit 133 of the card company terminal 100 charges electronic money from the first funding source. If the first funding source is a bank account, a predetermined amount of cash is converted into electronic money and charged. Here, the charge amount can be a certain percentage (e.g., 600 yen equivalent) of the electronic money equivalent to the shortfall in the amount used (e.g., 1,000 yen equivalent).

Next, in processing SQ404, the charge processing unit 133 of the card company terminal 100 makes a charge request to a second funding source (e.g., another bank account).

Next, in the process of SQ405, the charge processing unit 133 of the card company terminal 100 charges electronic money from the second funding source. If the second funding source is a bank account, a predetermined amount of cash is converted into electronic money and charged. Here, the charge amount can be a certain percentage (e.g., 400 yen equivalent) of the electronic money equivalent to the shortfall in the amount used (e.g., 1,000 yen equivalent). As a result, the sum of the charge amount from the first funding source and the charge amount from the second funding source is the same as the shortfall, and the card company terminal 100 can approve the transaction.

As described above, through this embodiment, card companies can provide users with even more flexible methods for topping up their electronic money through collaboration between multiple funding sources.

<Embodiment 4>
Fig. 11 is an example of a flowchart relating to a charging method according to a third embodiment of the present invention. This embodiment is yet another example of a charging method for value such as electronic money that can be applied when an individual or corporation who is a card user wants to set up multiple funding sources. In this embodiment, the basic system configuration is the same as that of the first embodiment shown in Fig. 1, and the basic processing in the card company terminal 100 is the same as the processing according to the first embodiment shown in Fig. 7, so a description of processing other than the processing for charging electronic money from a funding source will be omitted.

First, in the process of SQ501, if the user does not have enough electronic money to cover the amount of the purchase of the product or service, the charge processing unit 133 of the card company terminal 100 inquires about the credit score of the user from the first funding source (e.g., a social network system) that is accessed first among multiple pre-set funding sources.

Next, in the process of SQ402, the first funding source (e.g., a social network system) refers to the user's attribute information and behavioral history on the social network to calculate a credit score. For example, the social network system checks the user's profile information and calculates the user's credit score based on a predetermined criterion. For example, the social network system calculates a credit score based on the user's profile information (e.g., place of employment, age, number of friends, etc.) and/or the user's actions (e.g., the number of "likes" received on a post, the number of comments received on a post, etc.). There are various possible ways of allocating scores; for example, the more information entered into the profile, the higher the score can be set, or a score can be assigned for each predetermined action, and the scores can be accumulated according to the number of actions.

Next, in the process of SQ403, the social network system transmits the calculated credit score to the card company terminal 100. The social network system transmits the calculated credit score (e.g., 90 points) to the card company terminal 100.

Next, in the process of SQ405, the charge processing unit 133 of the card company terminal 100 transmits the credit score of the user to the second funding source (e.g., a credit card). When making an authorization request, the charge processing unit 133 can transmit information necessary for credit, such as the amount of the product or service purchased by the user, in the form of an authorization message, etc.

Next, in the process of SQ406, the second funding source (e.g., a credit card company terminal) refers to the received user's credit score and/or checks other credit information. Credit information may include, for example, the user's credit card credit limit, usage history, etc.

Then, the second funding source provides credit to the card company terminal 100 based on the result of the credit check. If the second funding source is a credit card, it notifies the card company terminal 100 that the purchase is permitted, for example, for a 500 yen T-shirt, based on the user's credit score (e.g., 90 points) and/or other credit information.

As described above, through this embodiment, card companies can provide more flexible methods for charging electronic money by providing credit through collaboration between multiple funding sources.

The application of the above first to fourth embodiments is not limited to the charging method for a prepaid card for using electronic money, but can be applied to any value having a certain monetary value, including legal currency value and various points, and can also be applied to payment media provided by media providers, such as sheet media printed with QR codes, electronic media such as web pages displaying QR codes, and virtual media such as web services and apps.

In addition, the application of the above first to fourth embodiments is not limited to charging value having monetary value, but can also be applied to a method of depositing money by transferring value held by another user.

Although the disclosed embodiments have been described above, they can be embodied in various other forms and can be implemented with various omissions, substitutions, and modifications. These embodiments and variations, as well as omissions, substitutions, and modifications, are included in the technical scope of the claims and their equivalents.

1 Charging system 100 Card company terminal, 110 Communication unit, 120 Memory unit, 130 Control unit, 200 User terminal, 300 Store terminal, NW Network

Claims (3)

A server,
an acceptance unit for accepting a payment request for a transaction including an amount;
a balance storage unit for storing a balance associated with a user;
A resource storage unit that stores a charge resource previously associated with the user;
and a control unit for approving the transaction based on the payment request;
The control unit is
if said balance is sufficient to cover said amount, approving said payment request;
If the balance is insufficient for the amount, a charge request is made to a terminal that manages the charge resource using the charge resource;
A server that approves the transaction if the charge request is accepted by the terminal. A method for controlling a server, comprising:
accepting a payment request for the transaction including an amount;
storing a balance associated with the user;
storing a charge resource pre-associated with said user;
and approving the transaction based on the payment request;
In the step of approving the transaction,
if the balance is sufficient to cover the amount, approving the payment request;
If the balance is insufficient for the amount, a charge request is made to a terminal that manages the charge resource using the charge resource;
and if the charge request is accepted by the terminal, approving the transaction. On the computer,
accepting a payment request for the transaction including an amount;
storing a balance associated with the user;
storing a charge resource pre-associated with said user;
approving the transaction based on the payment request;
In the step of approving the transaction,
if the balance is sufficient to cover the amount, approving the payment request;
If the balance is insufficient for the amount, a charge request is made to a terminal that manages the charge resource using the charge resource;
and if the charge request is accepted by the terminal, approving the transaction.