JP7421743B2 - Payment medium activation method and system - Google Patents

Description

Application of Article 30, Paragraph 2 of the Patent Act Announced at a press conference held on April 25, 2019 in the conference room of Kyash Co., Ltd.

The present invention relates to a payment medium validation method and system.

Traditionally, payments using intangible assets with monetary value (hereinafter referred to as "value") such as legal currency value, electronic money, and other points have been widespread. By charging electronic money equivalent to a certain amount in advance or immediately using a prescribed method and delivering it to a member store that is an electronic money user, a person can purchase products or services sold by that member store, and become a member store. The store receives payment, such as cash, from the electronic money issuer in exchange for electronic money equivalent to the sales proceeds.

In addition to charging with cash, methods for charging electronic money include charging methods linked to objects whose ability to pay can be guaranteed, such as credit cards and bank accounts (for example, Patent Document 1). Furthermore, a method has been disclosed in which a user can select a plurality of charge methods (funding sources) from among options (for example, Patent Document 2).

Patent No. 6473487 Japanese Patent Application Publication No. 2018-160267

Incidentally, payments have traditionally been made at stores using value payment media such as electronic money (for example, physical cards with predetermined card information printed on plastic), but when using payment media, The activation procedure sometimes felt complicated to users, as there were many items to input.

In addition, especially in corporations, when employees use physical cards as corporate cards, the information entered by employees for activation will go through the card company, which means that the card company will be handling a large amount of personal information. This increases the burden of security measures.

Therefore, it is an object of the present invention to provide a simpler method and system for validating payment media, and to reduce the burden of personal information management on payment media providers, especially for corporations.

An activation method for activating a payment medium by a payment medium provider that provides a payment medium for payment by value having monetary value, the method comprising: a user or an administrator registering registration information; Based on the above, the payment medium provider provides the payment medium and identification code to the user or the administrator, and the user issues an activation request including at least the identification code and user identification information or administrator identification information. and activating the payment medium based on the activation request.

According to the present invention, it is possible to provide a simpler method and system for validating a payment medium, and to reduce the burden of personal information management on a payment medium provider, especially when the payment medium is used for corporations.

1 is a block configuration diagram showing a system according to an embodiment of the present invention. 2 is a functional block configuration diagram showing the card company terminal 100 of FIG. 1. FIG. 2 is a functional block configuration diagram showing the user terminal 200 of FIG. 1. FIG. 2 is a functional block configuration diagram showing an administrator terminal 300 in FIG. 1. FIG. 1 is a schematic diagram showing an example of user data stored in a card company terminal 100. FIG. 3 is a schematic diagram showing an example of message data stored in the card company terminal 100. FIG. 3 is a schematic diagram showing an example of administrator data stored in the card company terminal 100. FIG. 7 is a modification example of a flowchart related to an activation method according to an embodiment of the present invention. 7 is an example of a flowchart related to an activation method according to another embodiment of the present invention.

Embodiments of the present invention will be described below with reference to the drawings. Note that the embodiments described below do not unduly limit the content of the present disclosure described in the claims. Furthermore, not all components shown in the embodiments are essential components of the present disclosure.

<Configuration>
FIG. 1 is a block diagram showing a payment medium validation system according to an embodiment of the present invention. As an example, the present embodiment includes a card company terminal 100 that is a terminal of a card company that issues a physical card, a user terminal 200 that is a terminal of a user who uses the physical card, and a user terminal 200 that is a terminal of a user who uses the physical card. The system consists of an administrator terminal 300, which is the administrator's terminal that manages the issuance of physical cards when the user is an employee of the company, and a funding source 400, which is the source of expenditure when the user uses the card. The system will be explained using an example. This system is an example and is not limited to this configuration. For example, if an individual uses a physical card, the administrator terminal 300 may not be provided, and all configurations are interconnected via the network NW. It doesn't have to be done.

Card companies are so-called issuers of credit cards and prepaid cards, and issue cards to users and manage credit.For example, in the case of prepaid cards, they manage the balance of electronic money of users, When a user uses a prepaid card at a member store in exchange for a product, the transaction is authorized. The user can be an individual user or a corporate user, and in the case of a corporation, that corporation acts as a secondary issuer (partner) and issues the card to another corporation, and the company provides the card. It is also possible to provide services by adding functions to do so. In addition, if the user is an employee of a corporation and the card company issues the card as a corporate card, the administrator of the corporation will issue the card to the business department or employee, and the user will: The card may also be used for business-related purposes such as business trips, meetings, and entertainment.

In addition, card companies issue prepaid cards, such as so-called virtual cards, that are displayed via application software that users have installed on their mobile terminals such as smartphones, or respond to requests from users. Accordingly, it is also possible to issue a magnetic card or an IC card with a built-in IC chip, which is called a physical card, and has predetermined card information printed on plastic such as a credit card or debit card. In general, virtual cards are used for transactions such as purchasing products online, such as online shopping, and physical cards are used for transactions such as purchasing products or services at physical stores. In addition, card companies offer other services, such as services that allow users to make payments using contactless terminals installed at stores, etc. (directly transferring card information) through application software installed on mobile terminals such as smartphones. Payments may be made directly or indirectly.

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

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

The user terminal 200 and the administrator terminal 300 are, for example, information processing devices such as a personal computer or a tablet terminal, but may also be configured by a smartphone, a mobile phone, a PDA, or the like.

The funding source 400 may be in any form as long as it is a value pool, such as a credit card, debit card, bank account, blockchain account, or carrier payment. It may be a value pool that handles value accumulated through card payments (e.g., value accumulated through card payments), value equivalent to financial assets (e.g., credit), or value that users can use for funding.

In this embodiment, the system 1 will be described as having a card company terminal 100, a user terminal 200, an administrator terminal 300, and a funding source 400. Also, in cases where a partner's card user is another corporation or an individual, that partner can be replaced with the card company (card company terminal 100) in this system, and the card issued by that partner can be used. It is also possible to replace the user with the user (user terminal 200) in this system. If the partner is replaced by a card company, it is also possible to use the original card company's API (Application Programming Interface).

FIG. 2 is a functional block diagram of the card company terminal 100 of FIG. 1. As shown in FIG. The card company terminal 100 includes a communication section 110, a storage section 120, and a control section 130.

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

The storage unit 120 stores programs, input data, etc. for executing various control processes and functions within the control unit 130, and is composed of RAM (Random Access Memory), ROM (Read Only Memory), etc. Ru. The storage unit 120 also includes a user data storage unit 121 that stores various data necessary for authorizing transactions and charging electronic money when a card user purchases a product or service at an affiliated store; It has a message data storage section 122, an administrator data storage section 123 (not shown in FIG. 2, and will be described later with reference to FIG. 7), etc., which store data related to the authorization message received from the store. Furthermore, the storage unit 120 can also temporarily store data communicated with the user terminal 200 or the administrator terminal 300. Note that a database (not shown) storing various data may be constructed outside the storage unit 120.

The control unit 130 controls the overall operation of the card company terminal 100 by executing programs stored in the storage unit 120, and receives information from a CPU (Central Processing Unit), GPU (Graphics Processing Unit), etc. configured. The functions of the control unit 130 include a request reception unit 131 that receives instructions from the user terminal 200, a card issuance approval processing unit 132 that performs processing for approval of card issuance requests, and a card issue approval processing unit 132 that performs processing for approval of card issuance requests. It has a validation processing unit 133 that performs processing. The request reception unit 131, card issue approval processing unit 132, and validation processing unit 133 are activated by a program stored in the storage unit 120 and executed by the card company terminal 100, which is a computer (electronic computer). Note that the control unit 130 may include an approval processing unit that performs processing for approval of an authorization request and a charge processing unit that performs processing related to charging electronic money, as necessary. .

The request reception unit 131 allows a user to register user information or issue a virtual or physical card, for example, on a user interface displayed via an application installed on the user terminal 200. When a predetermined request such as the like is made, the request is accepted from the user terminal 200 via the communication unit 110. Additionally, when a user purchases a product or service using a card at a member store, reads the physical card using a reader on the store terminal, and sends an authorization message to request authorization, A request is accepted from the store terminal via the communication unit 110.

When the card issuance approval processing unit 132 receives a card issuance request from the user terminal 200, it performs a predetermined process for approving the request.

When the validation processing unit 133 receives a card validation request from the user terminal 200, it performs a predetermined process for validation, which will be described later.

FIG. 3 is a functional block diagram showing the user terminal 200 of FIG. 1. As shown in FIG. The user terminal 200 includes a communication section 210, a display operation section 220, a storage section 230, and a control section 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, for example.

The display operation unit 220 is a user interface used by the user to input instructions and display text, images, etc. in accordance with input data from the control unit 240. If the user terminal 200 is a tablet terminal, it is composed of a display, a keyboard, and a mouse, and if the user terminal 200 is a tablet terminal, it is composed of a touch panel or the like. This display operation section 220 is activated by a control program such as an application program stored in the storage section 230 and executed by the user terminal 200 which is a computer (electronic computer).

The storage unit 230 stores programs, input data, etc. for executing various control processes and functions within the control unit 240, and is composed of a RAM, a ROM, and the like. Furthermore, the storage unit 230 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 a program stored in the storage unit 230, and is composed of a CPU, a GPU, and the like.

Note that the card company terminal 100 may have all or part of the functions of a control program such as an application program stored in the user terminal 200.

FIG. 4 is a functional block diagram showing the administrator terminal 300 of FIG. 1. As shown in FIG. The administrator terminal 300 includes a communication section 310, a display operation section 320, a storage section 330, and a control section 340.

The communication unit 310 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, for example.

The display operation unit 320 is a user interface used by the administrator to input instructions and display text, images, etc. in accordance with input data from the control unit 340. If the administrator terminal 300 is a tablet terminal, it is composed of a display, a keyboard, and a mouse, and if the administrator terminal 300 is a tablet terminal, it is composed of a touch panel or the like. This display operation section 320 is activated by a control program such as an application program stored in the storage section 330 and executed by the administrator terminal 300 which is a computer (electronic computer).

The storage unit 330 stores programs, input data, etc. for executing various control processes and functions within the control unit 340, and is composed of a RAM, a ROM, and the like. Furthermore, the storage unit 330 temporarily stores the contents of communication with the card company terminal 100.

The control unit 340 controls the overall operation of the administrator terminal 300 by executing a program stored in the storage unit 330, and is composed of a CPU, a GPU, and the like.

Note that the card company terminal 100 may have all or part of the functions of a control program such as an application program stored in the administrator terminal 300.

FIG. 5 is a schematic diagram showing an example of user data stored in the card company terminal 100.

User data 1000 shown in FIG. 5 stores various data related to the user who uses the card. In FIG. 5, for convenience of explanation, an example of one user (a user identified by user ID "10001") is shown, but information on multiple users can be stored. Various data related to users include, for example, user registration information (in the case of individuals, name, date of birth, gender, address, and contact information (phone number, email address, etc.), card information ( For example, card number (PAN), card member name, expiration date (EXP), personal identification number (PIN), security code (CAV/CVC2/CVV2/CID), track data, etc.).In addition, information related to credit (e.g. electronic money balance, usage limit, etc.), user's funding source information (credit card information, debit card information, bank account information, virtual currency account information, carrier payment information, etc.) It will be done.

FIG. 6 is a schematic diagram showing an example of message data stored in the card company terminal 100.

The message data 2000 shown in FIG. 6 stores various data to be stored in the authorization message. Various data related to the authorization message include, for example, information such as card information used at the member store, member store ID, date and time of use, and amount of money used.

FIG. 7 is a schematic diagram showing an example of administrator data 3000 stored in the card company terminal 100 when the user is an employee belonging to a corporation. In this case, it is more preferable that the user data 1000 regarding the employee is not stored in the card company terminal 100. This can reduce the burden on card companies of handling large amounts of personal information.

Administrator data 3000 shown in FIG. 7 stores various data related to administrators. In FIG. 7, for convenience of explanation, an example of one administrator (the administrator identified by the administrator ID "30001") is shown, but information on multiple administrators can be stored. Various data related to the administrator include, for example, the administrator's registration information (in the case of a corporation, the corporation name, contact information, representative name, representative address, etc.), card information (for example, card number (PAN)) , card member corporation name, expiration date (EXP), personal identification number (PIN), security code (CAV/CVC2/CVV2/CID), track data, etc.). In addition, information related to credit (for example, electronic money balance, usage limit, etc.), administrator's funding source information (credit card information, debit card information, bank account information, virtual currency account information, and carrier payment information) etc.) are also included.

<Processing flow>
With reference to FIG. 8, the processing flow of the physical card validation method executed by the system 1 of this embodiment, especially for individuals, will be described. FIG. 8 is an example of a flowchart of a method for validating a physical card according to an embodiment of the present invention.

First, in order to issue a physical card, the user accesses a website or application software from the user terminal 200, registers user data on the provided user interface (S101), and requests the issuance of a physical card. Execute (S102).

Note that the user data registered at the time of processing in S102 should include at least information necessary for approval for issuing a physical card (S103), which will be described later. As a more specific example, when issuing a prepaid card as a physical card, it is sufficient that at least the above-mentioned user's registration information (for example, name, address, etc.) is registered. Here, if a virtual card has already been issued via a website or application software, the information registration (S101) may be omitted and the user data registered at the time of virtual card issuance may be referred to. Further, when issuing a physical card such as a credit card or a debit card, it is also necessary to register information about the user (for example, occupation, income, etc.) that is used in conventional card issuance examinations. Regarding other user data, it is sufficient that each piece of information is registered by the required timing, for example, funding source information only needs to be registered by the time the physical card is used. Furthermore, as will be described later, the card information of the physical card may be registered at the time of validation processing.

Next, the card company approves the issuance of a physical card based on the user data received from the user terminal 200 (S103).

Next, if approved, the card company will send a physical card to the user. At this time, for example, an identification code linked to the physical card and readable by the user terminal 200 is sent along with the physical card. In this embodiment, since the identification code and the user data are not linked to each other in the server 100 at this point, it is convenient for the card company to issue a physical card, but this is not limited to this. It may be linked. Further, the identification code may be one that can be read by image recognition, such as a one-dimensional code such as a bar code, or a two-dimensional code such as a QR code. Further, for example, information stored in an IC chip of a physical card may be read as an identification code by the user terminal 200 directly or indirectly via a reader or the like.

Next, the user starts the application software and reads the identification code linked to the physical card using the user terminal 200 (S104). Then, an activation request including the read identification code and user identification information (for example, an administrator ID, particularly a user ID linked to application software, etc.) is sent to the card company terminal 100 (S105). Note that this transmission may be performed simply by the user executing a transmission instruction (for example, by pressing the send button), but at least in cases where it is sufficient that the validation procedure is simple. If necessary, the user may be prompted to input personal information or other information that is missing for use, and such information may also be transmitted.

Finally, based on the identification code and user identification information received at the card company terminal 100, a process of linking the user data and the physical card and activating the physical card is executed (S108).

As a result, when activating a payment medium such as a physical card, users only need to use application software to read the identification code sent by the payment medium provider, such as a credit card company, making it easier than before. Validation processing will be executed.

<Processing flow>
With reference to FIG. 9, the processing flow of the physical card validation method executed by the system 1 of this embodiment, especially for corporations, will be described. FIG. 9 is an example of a flowchart related to a physical card validation method according to another embodiment of the present invention.

First, in order to issue a physical card to an employee, the administrator accesses a website or application software from the administrator terminal 300, registers administrator data on the provided user interface (S101), and issues the physical card to the employee. An issuance request is made (S102).

Note that the administrator data registered in the process of S102 should include at least information necessary for approval for issuing a physical card (S103), which will be described later. As a more specific example, when issuing a prepaid card as a physical card, the registration information of the above-mentioned administrator (for example, corporate name, contact information, representative name, representative address, number of cards, etc.) must be at least It only needs to be registered. Here, if a virtual card has already been issued via application software, the administrator data registered at the time of issuing the virtual card may be referred to. Furthermore, when issuing a credit card, debit card, or the like as a physical card, it is also necessary to register information regarding the administrator (for example, capital, etc.) used in conventional card issuance examination. Regarding other user data, it is sufficient that each piece of information is registered by the required timing, for example, funding source information may be registered by the time an employee uses a physical card.

Next, the card company approves the issuance of a physical card based on the administrator data received from the administrator terminal 300 (S104).

Next, if approved, the card company sends the physical card to the administrator, and the administrator distributes it to the user, who is an employee. At this time, an identification code linked to the physical card and readable by the user terminal 200 is sent along with the physical card. In this embodiment, since the identification code and user data are not linked to each other in the server 100 at this point, it is convenient for the card company to issue a physical card, but this is not limited to this. It may be linked. Further, the identification code may be one that can be read by image recognition, such as a one-dimensional code such as a bar code, or a two-dimensional code such as a QR code. Furthermore, for example, information stored in an IC chip of a physical card may be read as an identification code by the user terminal 200 directly or indirectly via a reader or the like.

Next, the user starts the application software and reads the identification code linked to the physical card using the user terminal 200 (S104). Then, an activation request including the read identification code and administrator identification information (for example, an administrator ID, particularly an administrator ID linked to application software, etc.) is transmitted to the card company terminal 100 (S105). Note that this transmission may be performed simply by the user executing a transmission instruction (for example, by pressing the send button), but at least in cases where it is sufficient that the validation procedure is simple. If necessary, the user may be prompted to input information other than personal information, and this information may also be transmitted. Furthermore, if the card company can accept the handling of personal information, the user's personal information (for example, name, employee number, etc.) may be included.

Finally, based on the identification code and administrator identification information received at the card company terminal 100, the administrator data is linked to the physical card, and a process of activating the physical card is executed (S108).

In addition, in Figures 8 and 9, the process up to the activation of the physical card has been explained, but after that, the virtual card issuance procedure is performed via a website or application software, etc., and it is linked to the physical card. You may also do so.

As a result, when activating a payment medium such as a physical card, users only need to use application software to read the identification code sent by the payment medium provider, such as a credit card company, making it easier than before. Validation processing will be executed. Furthermore, since the payment medium provider does not have to handle a large amount of personal information of users who are employees, the burden of personal information management on the payment medium provider can be reduced.

The application of the above embodiment is not limited to the activation method for physical cards, but is also applied to values having a certain monetary value, including electronic money, legal currency value, various points, etc. It 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 applications.

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

1 system
100 Card company terminal 110 Communication section 120 Storage section 130 Control section 200 User terminal 300 Administrator terminal 400 Funding source NW network

Claims (5)

The server is
a first reception step of accepting a payment medium issuance request from a terminal operated by an administrator;
an issuance step of issuing the payment medium to be used for payment by an employee engaged in the work of the administrator, based on the first reception step ;
a second reception step of accepting the validation request for the payment medium issued in the issuing step from a terminal operated by the employee ;
an activation step of activating the payment medium in a state where the payment medium and the administrator who made the issuance request for the payment medium are stored in a database in association with each other based on the activation request;
How to enable it . 2. The validation method according to claim 1, wherein in the issuing step , the payment medium is issued to the administrator. 2. The validation method according to claim 1 , wherein the second receiving step is executed by receiving a code linked to the payment medium from a terminal operated by the employee. a first reception step of accepting a payment medium issuance request from a terminal operated by an administrator;
an issuance step of issuing the payment medium to be used for payment by an employee engaged in the work of the administrator, based on the first reception step ;
a second reception step of accepting the validation request for the payment medium issued in the issuing step from a terminal operated by the employee ;
an activation step of activating the payment medium in a state where the payment medium and the administrator who made the issuance request for the payment medium are stored in a database in association with each other based on the activation request;
A server that runs to the computer,
a first reception step of accepting a payment medium issuance request from a terminal operated by an administrator;
an issuance step of issuing the payment medium to be used for payment by an employee engaged in the work of the administrator, based on the first reception step ;
a second reception step of accepting the validation request for the payment medium issued in the issuing step from a terminal operated by the employee ;
an activation step of activating the payment medium in a state where the payment medium and the administrator who made the issuance request for the payment medium are stored in a database in association with each other based on the activation request;
A program to run.