WO2016132791A1 - 情報処理システム及び情報処理方法 - Google Patents
情報処理システム及び情報処理方法 Download PDFInfo
- Publication number
- WO2016132791A1 WO2016132791A1 PCT/JP2016/051311 JP2016051311W WO2016132791A1 WO 2016132791 A1 WO2016132791 A1 WO 2016132791A1 JP 2016051311 W JP2016051311 W JP 2016051311W WO 2016132791 A1 WO2016132791 A1 WO 2016132791A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- user
- payment
- settlement
- request
- transaction
- Prior art date
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
- G06Q20/22—Payment schemes or models
- G06Q20/24—Credit schemes, i.e. "pay after"
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/384—Payment protocols; Details thereof using social networks
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/386—Payment protocols; Details thereof using messaging services or messaging apps
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/401—Transaction verification
Definitions
- the present invention relates to an information processing system and an information processing method.
- the representative user in order to make a split account among a plurality of users, the representative user has to make a payment with a credit card of a specific card company. Therefore, the representative user needs to obtain a credit card of a specific card company in advance.
- credit cards are issued by various card companies, and are not limited to credit cards of a specific card company, and it is preferable that the above-mentioned split payment can be performed.
- a server that requests payment processing for the split account is provided to the credit card company used by each user who pays by split account, and after the representative user has settled, the server sends the card company to each card company. You only need to request payment for split payment.
- An embodiment of the present invention has been made in view of the above points, and an object thereof is to settle payment using a credit card with a split account.
- an embodiment of the present invention is an information processing system including one or more information processing apparatuses, and a first request for requesting consent to make a settlement for a predetermined commercial transaction is first.
- the first credit inquiry means for making a credit inquiry for the credit card used for the settlement
- the response to the first request includes split account information indicating that the settlement is performed by a plurality of users
- the predetermined period of time elapses after the credit inquiry is performed.
- a payment instruction means for instructing to make a payment for the changed commercial transaction when the contents of the commercial transaction are changed.
- payment using a credit card can be settled with a split account.
- FIG. 1 is a configuration diagram of an example of a payment management system according to the first embodiment.
- the payment management system 1 shown in FIG. 1 has a plurality of terminal devices 10, a payment management device 20, one or more store terminals 30, and one or more credit card payment systems 40, and is used in a wide area such as the Internet.
- the network N is communicably connected.
- the terminal device 10 and the store terminal 30 are connected to be communicable via short-range wireless communication such as NFC (Near field communication).
- NFC Near field communication
- the terminal device 10 is, for example, a smartphone, a tablet terminal, a wearable terminal, a notebook PC, a desktop PC, or the like, and is a terminal on which a user performs payment using a credit card.
- a payment application 11 is installed (installed) in the terminal device 10, and the user can use a payment service such as payment by credit card using the payment application 11. In addition, the user can use the payment application 11 to split the credit card payment among other users.
- the payment application 11 of the terminal device 10 manages a user ID that uniquely identifies a user who uses the terminal device 10 in the payment management system 1.
- the terminal devices 10 of user A, user B, and user C are referred to as “terminal device 10-1,” “terminal device 10-2,” and “terminal device 10-3,” respectively.
- the user IDs assigned to the user A, the user B, and the user C are “user_id_a”, “user_id_b”, and “user_id_c”, respectively.
- IM Instant Messenger
- SNS Social Networking Service
- the settlement management device 20 includes one or more information processing devices (computers), and has a settlement management program 21 installed (installed).
- the payment management apparatus 20 uses the payment management program 21 to control various payment-related processes in the payment management system 1. For example, the payment management device 20 requests payment from the terminal device 10 in response to a request from the store terminal 30. In addition, for example, the payment management device 20 requests other terminal devices 10 to make a split payment in response to a request from the terminal device 10.
- the store terminal 30 is a terminal installed in a store such as a POS (PointPOof sale) terminal.
- the store terminal 30 has an NFC reader, for example, and can communicate with the terminal device 10 via short-range wireless communication.
- NFC reader for example
- a store ID that uniquely identifies the store is managed in the payment management system 1.
- the store terminal 30 is not limited to the one described above, and may be an online transaction system that performs online transactions such as e-commerce.
- the present invention can also be applied to the case where the terminal device 10 communicates with the online transaction system via the network N and settles the settlement of the purchased product with other users.
- the credit card payment system 40 is a payment system of a credit card company (hereinafter simply referred to as “card company”).
- card company a payment system of a credit card company
- the credit card payment systems 40 of the card company A, the card company B, and the card company C are referred to as “credit card payment system 40-1,” “credit card payment system 40-2,” and “credit card payment system, respectively. 40-3 ".
- FIG. 2 is a diagram for explaining an outline of processing of the payment management system according to the first embodiment.
- the payment by the credit card performed by the user A using the terminal device 10-1 is performed by the user B (terminal device 10-2) and the user C (terminal device 10-3) with the respective credit cards.
- a case where settlement is made with a split account will be described.
- step S1 it is assumed that the user A purchases a product at the store A using the terminal device 10-1 (step S1). Then, the store terminal 30 of the store A notifies the payment management device 20 of the purchase price “9,000 yen” of the product purchased by the terminal device 10-1 (step S2).
- the user A uses the terminal device 10-1 to notify the settlement management device 20 that the purchase price is settled with a credit card (step S3). Then, the payment management device 20 makes a credit inquiry of the payment amount “9,000 yen” to the credit card payment system 40 of the credit card company used by the user A for payment (step S4).
- the credit inquiry is also called “authorization” (also called “authorization” for short), “provisional billing”, etc., and the credit confirmation (validity confirmation and use) of the card user to the card company.
- the payment amount is temporarily (temporarily) secured when the credit inquiry is approved by the card company.
- the terminal device 10-1 of the user A notifies the settlement management device 20 that the purchase price “9,000 yen” of the merchandise is split between the user B and the user C (step S5).
- the settlement management device 20 gives the purchase amount “3,000 yen” divided by the three persons to the terminal device 10-2 of the user B and the terminal device 10-3 of the user C to the respective terminal devices. 10-2 and the terminal device 10-3 (steps S6-1 and S6-2).
- the settlement management device 20 sends the settlement amount “3,” to the credit card settlement system 40 of each credit card. 000 yen "credit inquiry. Moreover, the payment management apparatus 20 corrects the payment amount of the credit inquiry of the user A performed in the above step S4 to “3,000 yen” (step S7). At this time, the payment management apparatus 20 makes a credit inquiry with the amount of money divided for the credit card payment system 40 of the credit card used by each of the users A, B, and C as a payment amount.
- each credit card settlement system 40 is charged for each settlement amount “3,000 yen” ( Step S8).
- billing confirmation is also referred to as “capture” or “sales billing” and means that the settlement amount of the credit card temporarily secured by the approval of the credit inquiry is confirmed.
- the purchase amount “9,000 yen” of the product purchased by the user A on behalf of the credit card is divided by the user A, the user B, and the user C by the amount “3,000 yen”. You can settle using each credit card.
- the payment management device 20 controls the processing related to the split account as described above, the types of credit cards and card companies used by the user A, the user B, and the user C are not limited. Can be used to settle.
- FIG. 3 is a hardware configuration diagram of an example of the computer according to the first embodiment.
- the computer 100 further includes a CPU (Central Processing Unit) 106, a communication I / F 107, and an HDD (Hard Disk Drive) 108. Each of these hardware is connected by a bus B.
- CPU Central Processing Unit
- the input device 101 includes a keyboard, a mouse, a touch panel, etc., and is used by a user to input each operation signal.
- the display device 102 includes a display and the like, and displays a processing result by the computer 100.
- the input device 101 and the display device 102 may be connected and used when necessary.
- the communication I / F 107 is an interface for connecting the computer 100 to a network. Thereby, the computer 100 can perform data communication via the communication I / F 107.
- the communication I / F 107 of the terminal device 10 includes an NFC chip or the like for performing short-range wireless communication with the store terminal 30.
- the HDD 108 is an example of a non-volatile storage device that stores programs and data.
- the stored programs and data include OS (Operating System) that is basic software for controlling the entire computer 100, application software that provides various functions on the OS (for example, the payment application 11, the payment management program 21), and the like. is there.
- the computer 100 may use a drive device (for example, a solid state drive: SSD) that uses a flash memory as a storage medium instead of the HDD 108.
- a drive device for example, a solid state drive: SSD
- the HDD 108 manages stored programs and data by a predetermined file system and / or DB.
- the external I / F 103 is an interface with an external device.
- the external device includes a recording medium 103a.
- the computer 100 can read and / or write to the recording medium 103a via the external I / F 103.
- Examples of the recording medium 103a include a flexible disk, a CD, a DVD, an SD memory card, and a USB memory.
- the ROM 105 is a nonvolatile semiconductor memory (storage device) that can retain programs and data even when the power is turned off.
- the ROM 105 stores programs and data such as BIOS (Basic Input / Output System), OS settings, and network settings that are executed when the computer 100 is started up.
- BIOS Basic Input / Output System
- the RAM 104 is a volatile semiconductor memory (storage device) that temporarily stores programs and data.
- the CPU 106 is an arithmetic unit that realizes control and functions of the entire computer 100 by reading a program and data from a storage device such as the ROM 105 and the HDD 108 onto the RAM 104 and executing processing.
- the terminal device 10 and the payment management device 20 according to the first embodiment can realize various processes described later by the hardware configuration of the computer 100.
- FIG. 4 is a processing block diagram of an example of the payment management system according to the first embodiment.
- the terminal device 10 is installed with a payment application 11 for using the payment service as described above.
- the payment management apparatus 20 is installed with a payment management program 21 that controls various types of payment processing. Further, the payment management device 20 uses a user ID storage unit 22 and a transaction information storage unit 23.
- the payment application 11 of the terminal device 10 includes a payment method setting unit 111 and a split account user setting unit 112. These units are realized, for example, when the CPU 106 or the like executes the payment application 11.
- the settlement method setting unit 111 sets a settlement method for items purchased via the store terminal 30.
- the payment method set by the payment method setting unit 111 includes items such as “whether the purchase amount is settled with electronic money or a credit card” or “whether the purchase amount is split with other users”. It is.
- the split-account user setting unit 112 sets a user to be split when the payment method setting unit 111 is set to split the purchase amount with other users.
- the settlement management program 21 of the settlement management apparatus 20 includes a settlement processing unit 211, a split account processing unit 212, a credit inquiry unit 213, and a bill confirmation unit 214. These units are realized, for example, when the CPU 106 or the like executes the settlement management program 21.
- the user ID storage unit 22 and the transaction information storage unit 23 are realized by, for example, a storage device connected to the HDD 108 or the settlement management device 20 via a network.
- the settlement processing unit 211 performs processing related to settlement of transactions performed between the terminal device 10 and the store terminal 30. For example, when receiving a payment request from the store terminal 30, the payment processing unit 211 transmits a payment request to the corresponding terminal device 10.
- the split account processing unit 212 performs a process for splitting a settlement of a transaction performed between the terminal device 10 and the store terminal 30 by a plurality of users. For example, the split processing unit 212 requests the settlement processing unit 211 to transmit a payment request for the split purchase amount to the split target user.
- the credit inquiry unit 213 makes a credit card credit inquiry to the credit card settlement system 40.
- the billing confirmation unit 214 confirms the credit card settlement amount approved by the credit inquiry to the credit card settlement system 40.
- the user ID storage unit 22 stores a user ID table 22D.
- the user ID table 22D has data items as shown in FIG. 5, for example. That is, the user ID table 22D includes a user ID that uniquely identifies a user who uses the terminal device 10, a user name of the user, and friend user information indicating information related to a user who is a friend of the user. Yes.
- the first record of the user ID table 22D indicates that the user name of the user with the user ID “user_id_a” is “user A”, and “user B”, “user C”, and the like are friends.
- a user included in friend user information is a candidate for a user to be split. That is, for example, when the user A (trader user) splits the amount of a product purchased (traded) using a credit card with another user, the user A is subject to splitting from the user included in the friend user information. Select one or more users.
- the user who is subject to splitting is not limited to a user who is a friend.
- a user who belongs to the same chat group as the trader user in the IM service or a user who belongs to the same community as the trader user in the SNS service may be a candidate for the user to be split.
- the transaction information storage unit 23 stores a transaction information table 23D.
- the transaction information table 23D has data items as shown in FIG. 6, for example. That is, the transaction information table 23D includes a transaction ID that uniquely identifies a transaction by a transaction user, a transaction amount that indicates a purchase amount of a product, a store ID that indicates a store that has performed a transaction, and a transaction user that indicates a user who has performed the transaction. ID.
- the transaction information table 23D has split account information used when a trader user splits a product traded with a credit card with another user.
- the split account information includes a split account target user ID indicating a split account target user and a split account amount indicating an amount to be settled by each split account target user.
- the record of the transaction ID “TR0001” in the transaction information table 23D is calculated by dividing the transaction amount “9,000 yen” traded by the user ID “user_id_a” (user A) by the user A, the user B, and the user C. This means that you will settle “3,000 yen” at a time.
- the split account information is set in the settlement management device 20 when the trader user sets a split target user via the split account user setting unit 112 of the terminal device 10.
- FIG. 7 is a sequence diagram of an example of the discount payment settlement process according to the first embodiment.
- the payment by the credit card performed by the user A using the terminal device 10-1 is performed by the user B (terminal device 10-2) and the user C (terminal).
- the user B terminal device 10-2
- the user C terminal
- a case where payment is made with a credit card by means of a credit card with the apparatus 10-3) will be described.
- the user A purchases a product, for example, at the store A using the terminal device 10-1 (step S701).
- a store clerk or the like of the store A inputs the amount of the product (transaction amount) to the store terminal 30, and then the user A makes a predetermined position of the store terminal 30 (with the terminal device 10-1). This is performed by placing the terminal device 10-1 at a position where short-range wireless communication is possible.
- the terminal device 10-1 transmits a transaction request including the user ID “user_id_a” of the user A to the store terminal 30 (step S702).
- a transaction request is transmitted through short-range wireless communication such as NFC, for example.
- steps S701 and S7702 are not limited to the case where the user purchases a product at the store, and the same applies when paying for the provision of a service (for example, eating and drinking) at the store.
- a service for example, eating and drinking
- the terminal device 10-1 when the user A uses the terminal device 10-1 to make a payment at an online transaction site such as an e-commerce site, the terminal device 10-1 makes an online transaction system via the network N. A transaction request including the user ID of user A is transmitted.
- the store terminal 30 When the store terminal 30 receives the transaction request, the store terminal 30 assigns a unique transaction ID within the payment management system 1 or for each store. Then, the store terminal 30 settles a settlement request including a transaction ID, a transaction amount, a store ID of the store A, and a user ID included in the transaction request (this is a “trader user ID”). It transmits with respect to the management apparatus 20 (step S703).
- the settlement request includes a transaction ID “TR0001”, a transaction amount “9,000”, a store ID “shop_id_a”, and a trader user ID “user_id_a”.
- the shop terminal 30 received user ID from the terminal device 10, and transmitted to the payment management apparatus 20 with transaction ID, transaction amount, shop ID, etc., it is not restricted to this. That is, in steps S702 and S703 described above, for example, the terminal device 10 may receive a transaction ID, a transaction amount, a store ID, and the like from the store terminal 30 and transmit them to the settlement management device 20 together with the user ID.
- the payment processing unit 211 of the payment management device 20 Upon receiving the payment request, the payment processing unit 211 of the payment management device 20 sends a payment request including the transaction ID and the transaction amount to the terminal device 10-1 of the trader user ID “user_id_a” (ie, user A). (Step S704). At this time, the payment processing unit 211 of the payment management device 20 creates transaction information based on the transaction ID, the transaction amount, the store ID, and the user ID (trader user ID) included in the received payment request. And stored in the transaction information table 23D.
- the terminal device 10-1 Upon receiving the payment request, the terminal device 10-1 displays on the display device 102 a payment method setting screen 1100 as shown in FIG.
- the settlement method setting screen 1100 describes the transaction ID and transaction amount of the product purchase made by the user A, the product name of the purchased product, etc., and the user A has an error in the content of the transaction he has performed. Check if there is any. Then, the user A sets whether the payment method is “electronic money” or “credit card” in the payment method setting field 1101 of the payment method setting screen 1100, and sets other payments in the split-account setting field 1102. Whether or not to split with the user is set, and the “OK” button is pressed (step S705). Here, it is assumed that “credit card” settlement is selected and the credit card information is input in the settlement method setting field 1101, and “account with other users” is set in the split account setting field 1102.
- the payment method setting unit 111 of the terminal device 10-1 generates a payment confirmation including the transaction ID “TR0001”, the payment method “credit card”, and the split payment category “split payment”. It transmits with respect to the payment management apparatus 20 (step S706).
- the payment method includes the “credit card information” (ie, credit card number, security code, expiration date, etc.) set in step S705.
- the credit card of the card company A used by the user A set in step S705 is “credit card A”
- the credit card information of the credit card A is “credit card information A”.
- the credit inquiry unit 213 of the payment management device 20 Upon receipt of the payment confirmation, the credit inquiry unit 213 of the payment management device 20 transmits a credit inquiry to the credit card payment system 40-1 of the card company A based on the credit card information A included in the payment confirmation. (Step S707).
- the credit inquiry includes the transaction amount and the credit card information A. If the credit inquiry is approved, the payment management apparatus 20 receives a credit inquiry result indicating approval from the credit card payment system 40-1.
- the transaction processing unit 211 of the payment management device 20 When the payment processing unit 211 of the payment management device 20 receives the credit inquiry result indicating the approval from the credit card payment system 40-1, the transaction processing unit 211 transmits a transaction completion notification to the store terminal 30 and the terminal device 10-1 (step S1). S708 and S709). Thereby, the purchase (transaction) of the product by the user A using the credit card A is completed. As described above, when the trader user sets to split the purchase price with other users, the transaction is completed when the credit inquiry is approved. Thereby, the transaction between the terminal device 10 of the transaction user and the store terminal 30 can be completed quickly.
- step S705 If user A sets “Do not split” with other users in the split account setting field 1102 in step S705, the charge confirmation unit 214 of the settlement management apparatus 20 after the credit inquiry is approved in step S707. Confirms the bill for the credit inquiry.
- the user A operates the terminal device 10-1 to select a user who accounts for the purchase price of the product purchased above (step S710). That is, the user A operates the terminal device 10-1 to display the split user selection screen 1200 as shown in FIG. 8B on the display device 102, for example.
- the split-account user selection field 1201 one or more users to be split-off are selected and the “OK” button is pressed.
- the candidate for split account displayed in the split account user selection field 1201 may be acquired from the friend user information in the user ID table 22D of the payment management apparatus 20, the storage device of the terminal apparatus 10-1, or the like. You may acquire from the friend user information stored in.
- FIG. 8B shows an example in which “user B” and “user C” are selected in the split-account user selection field 1201.
- the purchase price of the merchandise is split between the three users, “user A”, “user B”, and “user C”, which are trader users. Therefore, the purchase price “9,000 yen” of the merchandise is a discount amount of “3,000 yen” among “user A”, “user B”, and “user C”.
- the split account amount is used as the split account amount.
- the present invention is not limited to this, and the split account amount may be set for each user (an arbitrary amount can be input). .
- the split account user setting unit 112 of the terminal device 10-1 generates a split account request including the transaction ID, the split account target user ID set in step S710 above, and each split account amount, and settles the split account request. It transmits with respect to the management apparatus 20 (step S711).
- the transaction ID is “TR0001”
- the split account target user IDs are “user_id_b” (user B) and “user_id_c” (user C)
- the split account amount is “3,000 yen”.
- the split account processing unit 212 of the settlement management apparatus 20 Upon receipt of the split account request, the split account processing unit 212 of the settlement management apparatus 20 confirms the legitimacy of the split account target user ID and the split account amount included in the split account request, and then displays the corresponding transaction information in the transaction information table 23D. Update (step S712).
- the split information of the transaction information of the transaction ID “TR0001”, the split user ID “user_id_a”, the split user ID “user_id_b” and “user_id_c” set in step S710 above are set as the split user ID. Is added. Further, a discount amount “3,000” for each user of the added split account target user ID is added.
- the split processing unit 212 confirms the following validity. -Refer to the user ID table 22D and confirm whether the trader user and the split target user are friends (or confirm whether they belong to the same group or community). -Check whether or not the total amount of the discount user's split account amount and the split account target user's split account amount is equal to the purchase amount, and the split account processing unit 212 of the settlement management device 20 Then, it requests the terminal device 10 of the user excluding the trader user from the users included in the split account target user ID to transmit a settlement request including the transaction ID and the split account amount. Then, the settlement processing unit 211 transmits the settlement request to the terminal device 10.
- the payment processing unit 211 of the payment management device 20 transmits the payment request to the terminal device 10-2 of the user B and the terminal device 10-3 of the user C (steps S713-1 and S713-2). ).
- the terminal device 10-2 When the terminal device 10-2 receives the settlement request, the terminal device 10-2 causes the display device 102 to display a split account request screen 1300 as shown in FIG. Then, the user B confirms the trader user name (user A), the transaction ID, the split account amount, the product name, etc. displayed on the split account request screen 1300, and approves that he / she pays the split account amount. "Button.
- the terminal device 10-2 changes the screen to a settlement method setting screen 1400 as shown in FIG. 9B, for example.
- the user B sets in the payment method setting field 1401 of the payment method setting screen 1400 whether the payment method is “electronic money” or “credit card”, and presses an “OK” button ( Step S714-1).
- the “credit card” settlement is selected and the credit card information is input in the settlement method setting field 1101.
- the terminal device 10-3 of the user C step S714-2).
- the payment method setting unit 111 of the terminal device 10-2 generates a payment confirmation including the transaction ID “TR0001” and the payment method “credit card”, and transmits the payment confirmation to the payment management device 20.
- the payment method includes the “credit card information” set in step S714-1.
- the credit card of the card company B used by the user B set in step S714-1 is referred to as “credit card B”
- the credit card information of the credit card B is referred to as “credit card information B”.
- the credit card of the card company C used by the user C is “credit card C”
- the credit card information of the credit card C is “credit card information C”.
- the credit inquiry unit 213 of the payment management apparatus 20 Upon receipt of the payment confirmation from the terminal device 10-2, the credit inquiry unit 213 of the payment management apparatus 20 sends the credit card payment system 40-2 of the card company B to the credit card payment system 40-2 based on the credit card information B included in the payment confirmation. Then, a credit inquiry is transmitted (step S716-1). Similarly, when the credit inquiry unit 213 of the payment management apparatus 20 receives the payment confirmation from the terminal device 10-3, the credit card payment system 40- of the card company C based on the credit card information C included in the payment confirmation. A credit inquiry is transmitted to 3 (step S716-2).
- the payment management apparatus 20 receives the credit inquiry result which shows approval from each credit card payment system 40-2 and credit card payment system 40-3.
- step S717 the amount of the credit inquiry performed in step S717 is corrected. That is, the credit inquiry unit 213 of the payment management apparatus 20 performs a credit inquiry that corrects the payment amount of the credit inquiry performed in the above step S707 to a split account amount (here, “3,000 yen”). Transmit to 40-1.
- the payment management apparatus 20 receives a credit inquiry result indicating approval from the credit card payment system 40-1.
- the payment amount as described above may not be corrected.
- the credit inquiry performed in step S707 described above may be canceled and a credit inquiry using the discount amount as the settlement amount may be transmitted to the credit card settlement system 40 again.
- the billing confirmation unit 214 of the settlement management device 20 performs billing confirmation for all credit inquiries made in steps S716-1, S716-2, and S717 to each credit card settlement system 40. (Step S718). As a result, the bill for the discount amount by the respective credit cards is determined among the user A, the user B, and the user C.
- credit card settlement is performed by splitting the price of a product or the like purchased by a credit card on behalf of one user (transactioner user) with a plurality of users. can do.
- a plurality of users who are subject to splitting can make payments using a desired credit card, and the type of credit card, credit card company, and the like are not limited.
- the payment management system 1 when a transaction user splits the price of a product or the like purchased with a credit card with a plurality of users, once the credit inquiry for the credit card is completed, Complete the transaction. Therefore, a store or the like that sells merchandise or the like can quickly conduct a transaction without waiting for all credit inquiries and the like of a plurality of users to be discounted to be completed.
- the payment management system 1 according to the second embodiment will be described.
- the settlement management system 1 according to the second embodiment when a trader user does not set a split account target user or when the split account target user refuses to pay a split account amount, the split account target user responds to a settlement request. Will be described.
- the system configuration and the hardware configuration of the payment management system 1 according to the second embodiment are the same as those in the first embodiment, and a description thereof will be omitted.
- FIG. 10 is a processing block diagram of an example of a payment management system according to the second embodiment.
- the function of the split account processing unit 212A of the payment management apparatus 20 is different from that of the first embodiment.
- the data configuration of the transaction information table 23AD stored in the transaction information storage unit 23A of the settlement management device 20 is different. Therefore, only these parts will be described below.
- the split account processing unit 212A requests the bill finalizing unit 214 to confirm the bill when the trader user does not set the split target user for a predetermined period. To do.
- the split account processing unit 212A updates the split account amount of the trader user in the transaction information table 23AD when the split target user refuses to pay the split account amount.
- the transaction information storage unit 23A stores a transaction information table 23AD.
- the transaction information table 23AD has data items as shown in FIG. 11, for example. In other words, in addition to the data items included in the transaction information table 23D according to the first embodiment, there is a data item for determining whether or not charges can be confirmed for a corresponding split account user ID.
- the billing confirmation availability is updated to “OK” when the payment management apparatus 20 receives a credit inquiry result indicating approval for a credit card credit inquiry used for settlement by the user subject to split account. Therefore, when the payment management device 20 receives a credit inquiry result indicating that the transaction is not possible, or when the payment of the discount account is rejected by the user subject to the split account, the billing confirmation propriety remains “No”.
- FIG. 12 is a sequence diagram of an example of the discount payment settlement process according to the second embodiment.
- FIG. 12 a case where the user C subject to the split account refuses to pay the split account amount will be described.
- description is simplified suitably.
- the user A purchases a product at the store A using the terminal device 10-1 (step S1201). Then, the terminal device 10-1 transmits a transaction request including the user ID of the user A to the store terminal 30 (Step S1202).
- the store terminal 30 When the store terminal 30 receives the transaction request, the store terminal 30 numbers the transaction ID and transmits a settlement request including the transaction ID to the settlement management device 20 (step S1203).
- the payment processing unit 211 of the payment management apparatus 20 Upon receiving the payment request, the payment processing unit 211 of the payment management apparatus 20 transmits a payment request including the transaction ID and the transaction amount to the terminal device 10-1 of the transaction user (user A) ( Step S1204).
- the terminal device 10-1 When the terminal device 10-1 receives the payment request, the terminal device 10-1 displays, for example, a payment method setting screen 1100 on the display device 102. Then, the user A sets a settlement method and whether to split with other users, and presses an “OK” button (step S1205). Here, it is assumed that “credit card” settlement is selected and the credit card information is input in the settlement method setting field 1101, and “account with other users” is set in the split account setting field 1102.
- the payment method setting unit 111 of the terminal device 10-1 generates a payment confirmation and transmits it to the payment management device 20 (step S1206).
- the credit inquiry unit 213 of the payment management apparatus 20 Upon receipt of the payment confirmation, the credit inquiry unit 213 of the payment management apparatus 20 transmits a credit inquiry to the credit card payment system 40-1 of the credit card company A (step S1207). If the credit inquiry is approved, the payment management apparatus 20 receives a credit inquiry result indicating approval from the credit card payment system 40-1.
- the transaction processing unit 211 of the payment management device 20 When the payment processing unit 211 of the payment management device 20 receives the credit inquiry result indicating the approval from the credit card payment system 40-1, the transaction processing unit 211 transmits a transaction completion notification to the store terminal 30 and the terminal device 10-1 (step S1). S1208 and S1209).
- the user A operates the terminal device 10-1 to select a user who accounts for the purchase price of the product purchased above (step S1210). Then, the split account user setting unit 112 of the terminal device 10-1 generates a split request and transmits it to the payment management apparatus 20 (step S1211).
- the split account processing unit 212A of the settlement management apparatus 20 receives the split account request from the terminal apparatus 10-1 within N 1 days after transmitting the transaction completion notification to the terminal apparatus 10-1, it is included in the split account request. After confirming the validity of the split account target user ID and the split account amount, the corresponding transaction information in the transaction information table 23AD is updated (step S1212). At this time, the billing confirmation availability of each split account target user in the transaction information table 23AD is updated to “No”.
- step S1212 the split account processing unit 212A of the payment management apparatus 20 sends the transaction completion notification to the terminal device 10-1, and when N 1 day has passed, the bill confirmation unit 214 is informed in step S1207. Request to confirm the bill for the credit inquiry made. Then, the billing confirmation unit 214 performs billing confirmation for the credit inquiry.
- N 1 day is preferably about 1 to 2 days, for example.
- the split account processing unit 212 of the settlement management apparatus 20 has received a split account request from the terminal device 10-1 within N 1 days after transmitting the transaction completion notification.
- the split account processing unit 212 of the settlement management device 20 requests the settlement processing unit 211 to transmit a settlement request to the terminal device 10 of the user who is the target of split except the trader user. Then, the settlement processing unit 211 transmits the settlement request to the terminal device 10.
- the payment processing unit 211 of the payment management device 20 transmits the request to the terminal device 10-2 of the user B and the terminal device 10-3 of the user C (steps S1213-1 and S1213-2). .
- the terminal device 10-2 When the terminal device 10-2 receives the settlement request, the terminal device 10-2 displays, for example, a split-account request screen 1300 on the display device 102. Then, the user B confirms the contents of the split account request screen 1300 and presses an “approval” button for understanding that the user B pays the split account amount.
- the terminal device 10-2 makes a screen transition to, for example, a settlement method setting screen 1400.
- User B sets the payment method in the payment method setting field 1401 of the payment method setting screen 1400 and presses the “OK” button (step S1214-1).
- the “credit card” settlement is selected and the credit card information is input in the settlement method setting field 1101.
- “electronic money” settlement is set in the settlement method setting field 1101
- the electronic money corresponding to the user B's discount account amount is transferred to the user A's electronic money account, and the user B's discount account amount is calculated. What is necessary is just to control to pay with the credit card A of the user A.
- the terminal device 10-3 displays, for example, a split account request screen 1300 on the display device 102. Then, it is assumed that the user C confirms the content of the split account request screen 1300 and presses a “reject” button for rejecting payment of the split account amount (step S1214-2).
- the payment method setting unit 111 of the terminal device 10-2 generates a payment confirmation and transmits it to the payment management device 20 (step S1215-1).
- the terminal device 10-3 generates a payment rejection including the transaction ID “TR0001” and transmits the transaction rejection to the payment management device 20 (step S1215-2).
- the split account processing unit 212A of the payment management device 20 receives the payment confirmation from the terminal device 10-2 within N 2 days after transmitting the payment request in step S1213-1 to the terminal device 10-2.
- the credit inquiry unit 213 is requested to make a credit inquiry.
- the credit inquiry unit 213 transmits a credit inquiry to the credit card settlement system 40-2 of the card company B based on the credit card information B (step S1216).
- the split account processing unit 212A of the payment management device 20 updates the billing confirmation propriety of the corresponding split account target user in the corresponding transaction information in the transaction information table 23AD to “OK”. That is, the split account processing unit 212A updates the billing confirmation applicability of the split account target user ID “user_id_b” in the transaction information with the transaction ID “TR0001” to “OK”.
- step S1216 the split account processing unit 212A of the payment management apparatus 20 transmits the payment request of step S1213-1 to the terminal device 10-2, and when N 2 days have passed, To send a payment disapproval notice.
- N 2 days are preferably about 2 to 3 days, for example.
- the split account processing unit 212A of the payment management device 20 receives the payment confirmation from the terminal device 10-1 within N 2 days after transmitting the payment request to the terminal device 10-2, and performs the above credit inquiry. It will be described as
- the split account processing unit 212A of the settlement management device 20 refers to the transaction information table 23AD, and determines the discount amount of the split target users (excluding the trader user) whose billing confirmation availability is “No”. An update is made to add to the split user's discount amount (step S1217). That is, here, the split account amount “3,000” of the split account target user ID “user_id_c” is set to “0”, and the split account price of the split account target user ID “user_id_a” (the trader user) is set to “6,000”. Thereby, the transaction user pays the split account amount of the user who is the target of split account who refuses to pay the split account amount. In addition, for the user who is subject to the split account for which no credit inquiry has been made within N 2 days after the payment request is transmitted, the transaction user pays the split account amount of the user who is the target of the split account.
- the credit inquiry unit 213 of the settlement management device 20 corrects the amount of the credit inquiry performed in step S1207 of the trader user (user A) (step S1218). That is, the credit inquiry unit 213 of the payment management apparatus 20 corrects the payment amount of the credit inquiry performed in the above step S1218 to the discount amount (here, “6,000 yen”) updated in the above step S1217.
- the credit inquiry to be sent is transmitted to the credit card settlement system 40-1.
- the split account processing unit 212A of the settlement management device 20 updates the transaction user's billing confirmation availability in the corresponding transaction information in the transaction information table 23AD to “OK”. That is, the split account processing unit 212A updates the billing confirmation availability of the split account target user ID “user_id_a” in the transaction information with the transaction ID “TR0001” to “OK”.
- the split account processing unit 212A of the settlement management device 20 refers to the transaction information table 23AD, and confirms the charge for the credit inquiry of the split account target user whose charge confirmation is “OK” in the corresponding transaction information.
- Request to the bill confirmation unit 214 the billing confirmation unit 214 performs the billing confirmation for each credit card settlement system 40 (step S1219). That is, here, the billing confirmation for the credit inquiry of the user B (user ID “user_id_b”) performed in the above step S1216 and the billing for the credit inquiry of the user A (user ID “user_id_a”) performed in the above step S1218 are performed. Confirm. Thereby, between the user A and the user B, the bill for the discount amount is determined by the respective credit cards.
- the discount amount to be settled is “6,000 yen” for user A and “3,000 yen” for user B (that is, the discount account amount of user C who refused payment is This is added to the user A's discount amount.)
- the transaction user is It is controlled to pay the discounted amount of the rejected user or the user who has passed.
- payment by a credit card can be made by splitting the price of a product etc. purchased by a credit card on behalf of a trader user with a plurality of users. it can.
- a plurality of users who are subject to splitting can make payments using a desired credit card, and the type of credit card, credit card company, and the like are not limited.
- the payment management system 1 when a transaction user splits the price of a product or the like purchased with a credit card with a plurality of users, once the credit inquiry for the credit card is completed, Complete the transaction. Therefore, a store or the like, which is a seller of products, etc., can make a transaction quickly without waiting for all credit inquiries and the like of a plurality of users to be discounted to be completed.
- the payment management system 1 there is a shortage when one or more of the plurality of users subject to the split account refuses to pay the split account amount or passes the approval period. It is possible for the trader user to pay the split account amount.
Landscapes
- Business, Economics & Management (AREA)
- Engineering & Computer Science (AREA)
- Accounting & Taxation (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Strategic Management (AREA)
- Theoretical Computer Science (AREA)
- Finance (AREA)
- Computer Security & Cryptography (AREA)
- Microelectronics & Electronic Packaging (AREA)
- Computer Networks & Wireless Communication (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
- Cash Registers Or Receiving Machines (AREA)
Abstract
1以上の情報処理装置を含む情報処理システムであって、所定の商取引に関して決済を行うことに対する承諾を要求する第1の要求が第1の端末装置に送信されたことで、該第1の端末装置より該第1の要求に対する応答を受信すると、該決済に用いられるクレジットカードについて、与信照会を行う第1の与信照会手段と、前記第1の要求に対する応答に、前記決済を複数のユーザによって行うことを示す割り勘情報が含まれていた場合であって、前記与信照会を行ってから所定の期間が経過する前に、前記所定の商取引の内容が変更された場合に、変更後の該商取引に関して決済を行うよう指示する決済指示手段とを有することにより、上記課題を解決する。
Description
本発明は、情報処理システム及び情報処理方法に関する。
従来より、携帯電話等の端末を用いて、クレジットカードにより決済を行う技術が知られている。また、複数の人間で飲食を行った場合や商品を購入した場合等において、いわゆる割り勘(割り前勘定)で決済をすることが行われている。
このような場合において、代表者ユーザがクレジットカードで決済した後に、他のユーザに対して割り勘分の支払い処理を実行する技術が知られている(例えば特許文献1及び2参照)。これにより、複数のユーザ間で割り勘を行うことができるようになる。
しかしながら、上記の従来技術においては、複数のユーザ間で割り勘を行うためには、代表者ユーザは、特定のカード会社のクレジットカードで決済を行う必要があった。したがって、代表者ユーザは、特定のカード会社のクレジットカードを予め入手しておく必要があった。一方、クレジットカードは様々なカード会社から発行されており、特定のカード会社のクレジットカードに限られず、上記のような割り勘が行えることが好ましい。
ここで、特定のカード会社のクレジットカードに限られずに割り勘による決済を行うためには、例えば次のような構成が考えられる。すなわち、割り勘で支払うユーザのそれぞれが利用するクレジットカードのカード会社に対して割り勘分の支払い処理を要求するサーバを設けて、代表者ユーザが決済した後に、当該サーバがそれぞれのカード会社に対して割り勘分の支払いを要求すればよい。
しかしながら、この場合、割り勘で支払うユーザに、例えば支払い限度額を超過しているユーザ等がいると、当該ユーザの割り勘分の支払い処理を行うことができない。したがって、この場合、割り勘分の支払い合計額と、実際に購入等した商品等の金額とが異なってしまい、問題である。
本発明の一実施形態は、上記の点に鑑みてなされたもので、クレジットカードを用いた支払いを割り勘で決済することを目的とする。
上記目的を達成するため、本発明の一実施形態は、1以上の情報処理装置を含む情報処理システムであって、所定の商取引に関して決済を行うことに対する承諾を要求する第1の要求が第1の端末装置に送信されたことで、該第1の端末装置より該第1の要求に対する応答を受信すると、該決済に用いられるクレジットカードについて、与信照会を行う第1の与信照会手段と、前記第1の要求に対する応答に、前記決済を複数のユーザによって行うことを示す割り勘情報が含まれていた場合であって、前記与信照会を行ってから所定の期間が経過する前に、前記所定の商取引の内容が変更された場合に、変更後の該商取引に関して決済を行うよう指示する決済指示手段とを有することを特徴とする。
本発明の一実施形態によれば、クレジットカードを用いた支払いを割り勘で決済することができる。
以下、本発明の実施形態について図面を参照しながら詳細に説明する。
[第1の実施形態]
<システム構成>
図1は、第1の実施形態に係る決済管理システムの一例の構成図である。図1に示される決済管理システム1は、複数の端末装置10と、決済管理装置20と、1以上の店舗端末30と、1以上のクレジットカード決済システム40と有し、インターネット等の広域的なネットワークNを介して通信可能に接続されている。また、端末装置10と店舗端末30とは、例えばNFC(Near field communication)等の近距離無線通信を介して通信可能に接続される。
<システム構成>
図1は、第1の実施形態に係る決済管理システムの一例の構成図である。図1に示される決済管理システム1は、複数の端末装置10と、決済管理装置20と、1以上の店舗端末30と、1以上のクレジットカード決済システム40と有し、インターネット等の広域的なネットワークNを介して通信可能に接続されている。また、端末装置10と店舗端末30とは、例えばNFC(Near field communication)等の近距離無線通信を介して通信可能に接続される。
端末装置10は、例えばスマートフォン、タブレット端末、ウェアラブル端末、ノートPC、デスクトップPC等であり、ユーザがクレジットカードを用いた決済を行う端末である。端末装置10には決済アプリケーション11が搭載(インストール)されており、ユーザは、決済アプリケーション11を用いて、クレジットカードによる決済等の決済サービスを利用することができる。また、ユーザは、決済アプリケーション11を用いて、クレジットカードによる決済を他のユーザ間で割り勘することができる。
端末装置10の決済アプリケーション11には、決済管理システム1内で端末装置10を利用するユーザを一意に識別するユーザIDが管理されている。以降では、ユーザA、ユーザB、及びユーザCの端末装置10を、それぞれ「端末装置10-1」、「端末装置10-2」、及び「端末装置10-3」とする。また、ユーザA、ユーザB、及びユーザCに付与されたユーザIDを、それぞれ「user_id_a」、「user_id_b」、及び「user_id_c」とする。
なお、上記のユーザIDは、他のサービスと共通に利用されるものであってもよい。他のサービスには、例えば、IM(Instant Messenger)サービスやSNS(Social Networking Service)サービス等が挙げられる。
決済管理装置20は、1以上の情報処理装置(コンピュータ)を含み、決済管理プログラム21が搭載(インストール)されている。決済管理装置20は、決済管理プログラム21を用いて、決済管理システム1の各種の決済に関する処理を制御する。例えば、決済管理装置20は、店舗端末30からの要求に応じて、端末装置10に対して決済を要求する。また、例えば、決済管理装置20は、端末装置10からの要求に応じて、他の端末装置10に対して割り勘分の決済を要求する。
店舗端末30は、例えばPOS(Point of sale)端末等の店舗等に設置される端末である。店舗端末30は、例えばNFCリーダ等を有しており、端末装置10と近距離無線通信を介した通信を行うことができる。また、店舗端末30では、決済管理システム1内で店舗を一意に識別する店舗IDが管理されている。
なお、店舗端末30は、上記で説明したものに限られず、例えばeコマース等のオンライン取引を行うオンライン取引システムであってもよい。すなわち、本発明は、端末装置10がネットワークNを介してオンライン取引システムと通信を行い購入した商品等の決済を、他のユーザとの間で割り勘する場合にも適用され得る。
クレジットカード決済システム40は、クレジットカード会社(以降、単に、「カード会社」と表す)の決済システムである。以降では、カード会社A、カード会社B、及びカード会社Cのクレジットカード決済システム40を、それぞれ「クレジットカード決済システム40-1」、「クレジットカード決済システム40-2」、及び「クレジットカード決済システム40-3」とする。
<処理の概要>
次に、第1の実施形態に係る決済管理システム1の処理の概要について説明する。図2は、第1の実施形態に係る決済管理システムの処理の概要を説明するための図である。図2では、ユーザAが端末装置10-1を用いて行ったクレジットカードによる決済を、ユーザB(端末装置10-2)とユーザC(端末装置10-3)とで、それぞれのクレジットカードにより割り勘で決済する場合について説明する。
次に、第1の実施形態に係る決済管理システム1の処理の概要について説明する。図2は、第1の実施形態に係る決済管理システムの処理の概要を説明するための図である。図2では、ユーザAが端末装置10-1を用いて行ったクレジットカードによる決済を、ユーザB(端末装置10-2)とユーザC(端末装置10-3)とで、それぞれのクレジットカードにより割り勘で決済する場合について説明する。
まず、ユーザAは端末装置10-1を用いて、店舗Aで商品を購入したとする(ステップS1)。すると、店舗Aの店舗端末30は、端末装置10-1により購入された商品の購入金額「9,000円」を決済管理装置20に通知する(ステップS2)。
また、ユーザAは、端末装置10-1を用いて、上記の購入金額の決済をクレジットカードで行うことを決済管理装置20に通知する(ステップS3)。すると、決済管理装置20は、ユーザAが決済に使用したクレジットカードのカード会社のクレジットカード決済システム40に対して、決済金額「9,000円」の与信照会を行う(ステップS4)。
ここで、与信照会とは、「オーソリゼーション(略して「オーソリ」とも称される)」や「仮請求」等とも称され、カード会社に対してカード利用者の信用確認(有効性の確認や利用枠の確認)をすることをいう。与信照会がカード会社により承認されることで、決済金額が一時的に(仮に)確保される。
次に、ユーザAの端末装置10-1は、商品の購入金額「9,000円」を、ユーザBとユーザCとの3人で割り勘することを決済管理装置20に通知する(ステップS5)。すると、決済管理装置20は、ユーザBの端末装置10-2と、ユーザCの端末装置10-3に対して、3人で割り勘された購入金額「3,000円」を、それぞれの端末装置10-2及び端末装置10-3に送信する(ステップS6-1及びS6-2)。
続いて、ユーザB及びユーザCが割り勘された購入金額をクレジットカードで決済することに承認すると、決済管理装置20は、それぞれのクレジットカードのクレジットカード決済システム40に対して、決済金額「3,000円」の与信照会を行う。また、決済管理装置20は、上記のステップS4で行ったユーザAの与信照会の決済金額を、「3,000円」に訂正する(ステップS7)。このとき、決済管理装置20は、ユーザA、ユーザB、及びユーザCのそれぞれが決済に用いるクレジットカードのクレジットカード決済システム40に対して割り勘された金額を決済金額として与信照会を行う。
そして、ステップS7で行ったそれぞれの与信照会がクレジットカード決済システム40により承認されると、それぞれの決済金額「3,000円」の請求確定を、それぞれのクレジットカード決済システム40に対して行う(ステップS8)。
ここで、請求確定とは、「キャプチャ」や「売上請求」等とも称され、与信照会の承認により一時的に確保されたクレジットカードの決済金額を確定させることをいう。
以上により、ユーザAが代表してクレジットカードを用いて購入した商品の購入金額「9,000円」を、ユーザA、ユーザB、及びユーザCの間で割り勘した金額「3,000円」で、それぞれのクレジットカードを用いて決済することができる。また、割り勘に関する処理を上記のように決済管理装置20が制御することにより、ユーザA、ユーザB、及びユーザCが用いるクレジットカードの種類やカード会社は限定されず、それぞれが所望するクレジットカードを用いて決済することができる。
<ハードウェア構成>
次に、第1の実施形態に係る決済管理システム1に含まれる端末装置10及び決済管理装置20のハードウェア構成について説明する。端末装置10及び決済管理装置20は、例えば図3に示されるようなハードウェア構成のコンピュータ100により実現される。図3は、第1の実施形態に係るコンピュータの一例のハードウェア構成図である。
次に、第1の実施形態に係る決済管理システム1に含まれる端末装置10及び決済管理装置20のハードウェア構成について説明する。端末装置10及び決済管理装置20は、例えば図3に示されるようなハードウェア構成のコンピュータ100により実現される。図3は、第1の実施形態に係るコンピュータの一例のハードウェア構成図である。
図3のコンピュータ100は、入力装置101と、表示装置102と、外部I/F103と、RAM(Random Access Memory)104と、ROM(Read Only Memory)105とを備える。また、コンピュータ100は、さらに、CPU(Central Processing Unit)106と、通信I/F107と、HDD(Hard Disk Drive)108とを備える。これらの各ハードウェアは、それぞれがバスBで接続されている。
入力装置101は、キーボードやマウス、タッチパネル等を含み、ユーザが各操作信号を入力するのに用いられる。表示装置102は、ディスプレイ等を含み、コンピュータ100による処理結果を表示する。なお、入力装置101及び表示装置102は必要なときに接続して利用する形態であってもよい。
通信I/F107は、コンピュータ100をネットワークに接続するインタフェースである。これにより、コンピュータ100は通信I/F107を介してデータ通信を行うことができる。なお、端末装置10の通信I/F107には、店舗端末30と近距離無線通信を行うためのNFCチップ等が含まれる。
また、HDD108は、プログラムやデータを格納している不揮発性の記憶装置の一例である。格納されるプログラムやデータには、コンピュータ100全体を制御する基本ソフトウェアであるOS(Operating System)、及びOS上において各種機能を提供するアプリケーションソフトウェア(例えば、決済アプリケーション11、決済管理プログラム21)等がある。なお、コンピュータ100は、HDD108に替え、記憶媒体としてフラッシュメモリを用いるドライブ装置(例えばソリッドステートドライブ:SSD)を利用するものであってもよい。
HDD108は、格納しているプログラムやデータを所定のファイルシステム及び/又はDBにより管理している。外部I/F103は、外部装置とのインタフェースである。外部装置には、記録媒体103a等がある。コンピュータ100は、外部I/F103を介して記録媒体103aの読み取り及び/又は書き込みを行うことができる。記録媒体103aには、フレキシブルディスク、CD、DVD、SDメモリカード、USBメモリ等がある。
ROM105は、電源を切ってもプログラムやデータを保持することができる不揮発性の半導体メモリ(記憶装置)である。ROM105には、コンピュータ100の起動時に実行されるBIOS(Basic Input/Output System)、OS設定、及びネットワーク設定等のプログラムやデータが格納されている。RAM104はプログラムやデータを一時保持する揮発性の半導体メモリ(記憶装置)である。
CPU106は、ROM105やHDD108等の記憶装置からプログラムやデータをRAM104上に読み出し、処理を実行することで、コンピュータ100全体の制御や機能を実現する演算装置である。
第1の実施形態に係る端末装置10及び決済管理装置20は、コンピュータ100のハードウェア構成により、後述する各種処理を実現できる。
<ソフトウェア構成>
次に、本実施形態に係る決済管理システム1のソフトウェア構成について説明する。図4は、第1の実施形態に係る決済管理システムの一例の処理ブロック図である。端末装置10には、上述したように決済サービスを利用するための決済アプリケーション11がインストールされている。また、決済管理装置20には、各種の決済に関する処理を制御する決済管理プログラム21がインストールされている。さらに、決済管理装置20は、ユーザID記憶部22と、取引情報記憶部23とを利用する。
次に、本実施形態に係る決済管理システム1のソフトウェア構成について説明する。図4は、第1の実施形態に係る決済管理システムの一例の処理ブロック図である。端末装置10には、上述したように決済サービスを利用するための決済アプリケーション11がインストールされている。また、決済管理装置20には、各種の決済に関する処理を制御する決済管理プログラム21がインストールされている。さらに、決済管理装置20は、ユーザID記憶部22と、取引情報記憶部23とを利用する。
端末装置10の決済アプリケーション11は、決済方法設定部111と、割り勘ユーザ設定部112とを有する。これらの各部は、例えばCPU106等が決済アプリケーション11を実行することにより実現される。
決済方法設定部111は、店舗端末30を介して購入した商品等の決済方法を設定する。決済方法設定部111により設定される決済方法には、「購入金額を電子マネー又はクレジットカードのいずれで決済するか」や「購入金額を他のユーザと割り勘するか否か」等の項目が含まれる。
割り勘ユーザ設定部112は、決済方法設定部111により購入金額を他のユーザと割り勘するとの設定がなされた場合に、割り勘対象となるユーザを設定する。
決済管理装置20の決済管理プログラム21は、決済処理部211と、割り勘処理部212と、与信照会部213と、請求確定部214とを有する。これらの各部は、例えばCPU106等が決済管理プログラム21を実行することにより実現される。また、ユーザID記憶部22及び取引情報記憶部23は、例えばHDD108又は決済管理装置20とネットワークを介して接続された記憶装置等により実現される。
決済処理部211は、端末装置10と店舗端末30との間で行われた取引の決済に関する処理を行う。例えば、決済処理部211は、店舗端末30から決済要求を受け取ると、該当の端末装置10に対して、決済要求を送信する。
割り勘処理部212は、端末装置10と店舗端末30との間で行われた取引の決済を、複数のユーザで割り勘するための処理を行う。例えば、割り勘処理部212は、割り勘対象のユーザに対して、割り勘された購入金額の決済要求を送信するように決済処理部211に依頼する。
与信照会部213は、クレジットカード決済システム40に対して、クレジットカードの与信照会を行う。
請求確定部214は、クレジットカード決済システム40に対して、与信照会により承認されたクレジットカードの決済金額を確定する。
ユーザID記憶部22は、ユーザIDテーブル22Dを記憶する。ユーザIDテーブル22Dは、例えば図5に示すようなデータ項目を有している。すなわち、ユーザIDテーブル22Dは、端末装置10を利用するユーザを一意に識別するユーザIDと、当該ユーザのユーザ名と、当該ユーザと友達であるユーザに関する情報を示す友達ユーザ情報とを有している。例えば、ユーザIDテーブル22Dの1レコード目は、ユーザID「user_id_a」のユーザのユーザ名は「ユーザA」のであり、「ユーザB」、「ユーザC」等が友達であることを示している。本実施形態では、友達ユーザ情報に含まれるユーザは、割り勘対象となるユーザの候補である。すなわち、例えば、ユーザA(取引者ユーザ)がクレジットカードを用いて購入(取引)した商品の金額を他のユーザと割り勘する場合、ユーザAは、友達ユーザ情報に含まれるユーザから割り勘対象となる1以上のユーザを選択する。
ただし、割り勘対象となるユーザは、友達であるユーザに限られない。例えば、IMサービスにおいて取引者ユーザと同じチャットグループに属しているユーザやSNSサービスにおいて取引者ユーザと同じコミュニティ等に属しているユーザを、割り勘対象となるユーザの候補としてもよい。
取引情報記憶部23は、取引情報テーブル23Dを記憶する。取引情報テーブル23Dは、例えば図6に示すようなデータ項目を有している。すなわち、取引情報テーブル23Dは、取引者ユーザによる取引を一意に識別する取引IDと、商品等の購入金額を示す取引金額と、取引した店舗を示す店舗IDと、取引したユーザを示す取引者ユーザIDとを有する。
また、取引情報テーブル23Dは、取引者ユーザがクレジットカードを用いて取引した商品を他のユーザと割り勘する場合に用いる割り勘情報を有する。割り勘情報には、割り勘対象のユーザを示す割り勘対象ユーザIDと、各割り勘対象のユーザが決済すべき金額を示す割り勘金額とを有する。例えば、取引情報テーブル23Dの取引ID「TR0001」のレコードは、ユーザID「user_id_a」(ユーザA)が取引した取引金額「9,000円」を、ユーザA、ユーザB、及びユーザCで割り勘して「3,000円」ずつ決済することを示している。なお、割り勘情報は、取引者ユーザが、端末装置10の割り勘ユーザ設定部112を介して割り勘対象のユーザを設定することで、決済管理装置20において設定される。
<処理の詳細>
次に、第1の実施形態に係る決済管理システム1の処理の詳細について、図7を用いて説明する。図7は、第1の実施形態に係る割り勘決済処理の一例のシーケンス図である。なお、以降では、図2を用いて説明した場合と同様に、ユーザAが端末装置10-1を用いて行ったクレジットカードによる決済を、ユーザB(端末装置10-2)とユーザC(端末装置10-3)とでクレジットカードにより割り勘で決済する場合について説明する。
次に、第1の実施形態に係る決済管理システム1の処理の詳細について、図7を用いて説明する。図7は、第1の実施形態に係る割り勘決済処理の一例のシーケンス図である。なお、以降では、図2を用いて説明した場合と同様に、ユーザAが端末装置10-1を用いて行ったクレジットカードによる決済を、ユーザB(端末装置10-2)とユーザC(端末装置10-3)とでクレジットカードにより割り勘で決済する場合について説明する。
まず、ユーザAが端末装置10-1を用いて、例えば店舗Aで商品を購入する(ステップS701)。これは、まず、店舗Aの店員等が店舗端末30に商品の金額(取引金額)を入力し、次に、ユーザAが当該店舗端末30の所定の位置(端末装置10-1との間で近距離無線通信が可能な位置)に、端末装置10-1を翳すことにより行われる。
すると、端末装置10-1は、店舗端末30に対して、ユーザAのユーザID「user_id_a」を含む取引要求を送信する(ステップS702)。このような取引要求は、例えば、NFC等の近距離無線通信を介して送信される。
ここで、近距離無線通信には、例えば、BLE(Bluetooth(登録商標) Low Energy)等を用いてもよい。また、ステップS701及びS7702は、ユーザが店舗で商品を購入する場合に限られず、店舗でのサービス(例えば、飲食等)の提供に対する対価を支払う場合についても同様である。
なお、ユーザAが端末装置10-1を用いて、例えばeコマースサイト等のオンライン取引サイトで決済を行った場合には、端末装置10-1は、ネットワークNを介してオンライン取引システムに対して、ユーザAのユーザIDを含む取引要求を送信する。
店舗端末30は、当該取引要求を受信すると、決済管理システム1内又は店舗毎に一意となる取引IDを採番する。そして、店舗端末30は、取引IDと、取引金額と、店舗Aの店舗IDと、当該取引要求に含まれるユーザID(これが「取引者ユーザID」となる。)とを含む決済要求を、決済管理装置20に対して送信する(ステップS703)。ここで、当該決済要求には、取引ID「TR0001」、取引金額「9,000」、店舗ID「shop_id_a」、取引者ユーザID「user_id_a」が含まれるものとする。
なお、上記のステップS702及びS703では、店舗端末30が、端末装置10からユーザIDを受け取って、取引ID、取引金額、店舗ID等と共に決済管理装置20に送信したが、これに限られない。すなわち、上記のステップS702及びS703は、例えば、端末装置10が、店舗端末30から取引ID、取引金額、店舗ID等を受け取って、ユーザIDと共に決済管理装置20に送信するようにしてもよい。
決済管理装置20の決済処理部211は、当該決済要求を受信すると、取引IDと、取引金額とを含む決済要求を、取引者ユーザID「user_id_a」(すなわち、ユーザA)の端末装置10-1に対して送信する(ステップS704)。なお、このとき、決済管理装置20の決済処理部211は、受信した決済要求に含まれる取引IDと、取引金額と、店舗IDと、ユーザID(取引者ユーザID)とに基づき取引情報を作成し、取引情報テーブル23Dに格納する。
端末装置10-1は、当該決済要求を受信すると、例えば図8(a)に示すような決済方法の設定画面1100を、表示装置102に表示させる。決済方法の設定画面1100には、ユーザAを行った商品購入の取引IDや取引金額、購入した商品の商品名等が記載されており、ユーザAは、自身が行った取引の内容に間違いがないかを確認する。そして、ユーザAは、決済方法の設定画面1100の決済方法設定欄1101で、決済方法を「電子マネー」とするか「クレジットカード」とするかを設定するとともに、割り勘設定欄1102で、他のユーザと割り勘するか否かを設定して、「OK」ボタンを押下する(ステップS705)。ここでは、決済方法設定欄1101で「クレジットカード」決済の選択及びクレジットカード情報の入力が行われ、割り勘設定欄1102で他のユーザと「割り勘する」が設定されたものとする。
すると、端末装置10-1の決済方法設定部111は、取引ID「TR0001」と、決済方法「クレジットカード」と、割り勘区分「割り勘する」とを含む決済確認を生成し、当該決済確認を、決済管理装置20に対して送信する(ステップS706)。なお、このとき、決済方法には、上記のステップS705で設定された「クレジットカード情報」(すなわち、クレジットカード番号、セキュリティコード、有効期限等)が含まれる。ここで、上記のステップS705で設定されたユーザAが用いるカード会社Aのクレジットカードを、「クレジットカードA」とし、クレジットカードAのクレジットカード情報を、「クレジットカード情報A」とする。
決済管理装置20の与信照会部213は、当該決済確認を受信すると、当該決済確認に含まれるクレジットカード情報Aに基づき、カード会社Aのクレジットカード決済システム40-1に対して、与信照会を送信する(ステップS707)。なお、当該与信照会には、取引金額と、クレジットカード情報Aとが含まれる。そして、当該与信照会が承認された場合、決済管理装置20は、クレジットカード決済システム40-1から承認を示す与信照会結果を受信する。
決済管理装置20の決済処理部211は、クレジットカード決済システム40-1から承認を示す与信照会結果を受信すると、店舗端末30及び端末装置10-1に対して、取引完了通知を送信する(ステップS708及びS709)。これにより、クレジットカードAを用いたユーザAによる商品の購入(取引)が完了する。このように、取引者ユーザが、購入金額を他のユーザと割り勘することを設定した場合、与信照会が承認された段階で取引を完了させる。これにより、取引者ユーザの端末装置10と店舗端末30との間の取引を迅速に完了させることができる。
なお、上記のステップS705においてユーザAが割り勘設定欄1102で他のユーザと「割り勘しない」を設定した場合、上記のステップS707で与信照会が承認された後、決済管理装置20の請求確定部214は、当該与信照会に対する請求確定を行う。
次に、ユーザAは、端末装置10-1を操作して、上記で購入した商品の購入金額を割り勘するユーザを選択する(ステップS710)。すなわち、ユーザAは、端末装置10-1を操作して、例えば図8(b)に示すような割り勘ユーザ選択画面1200を、表示装置102に表示させる。そして、割り勘ユーザ選択欄1201で、割り勘対象となる1以上のユーザを選択して、「OK」ボタンを押下する。なお、このとき割り勘ユーザ選択欄1201に表示される割り勘対象ユーザの候補は、決済管理装置20のユーザIDテーブル22Dの友達ユーザ情報から取得されてもよいし、端末装置10-1の記憶装置等に格納されている友達ユーザ情報から取得してもよい。
図8(b)は、割り勘ユーザ選択欄1201で、「ユーザB」と「ユーザC」とが選択されている例を示している。この場合、商品の購入金額は、取引者ユーザである「ユーザA」と、「ユーザB」と、「ユーザC」との3人のユーザ間で割り勘が行われる。したがって、商品の購入金額「9,000円」は、「ユーザA」と、「ユーザB」と、「ユーザC」との間でそれぞれ「3,000円」ずつの割り勘金額となる。
なお、購入金額を割り勘した結果、余りが生じる場合(例えば、「10,000円」を3人のユーザで割り勘する場合等)は、余りは予め定められた特定のユーザ(例えば、取引者ユーザ)が支払うようにすればよい。また、上記では、購入金額を、割り勘対象のユーザ数で割った金額を割り勘金額としたが、これに限られず、割り勘金額をユーザ毎に設定(任意の金額を入力)できるようにしてもよい。
端末装置10-1の割り勘ユーザ設定部112は、取引IDと、上記のステップS710で設定された割り勘対象ユーザIDと、それぞれの割り勘金額とを含む割り勘要求を生成し、当該割り勘要求を、決済管理装置20に対して送信する(ステップS711)。ここで、取引IDは「TR0001」、割り勘対象ユーザIDは「user_id_b」(ユーザB)及び「user_id_c」(ユーザC)、割り勘金額はそれぞれ「3,000円」であるものとする。
決済管理装置20の割り勘処理部212は、当該割り勘要求を受信すると、当該割り勘要求に含まれる割り勘対象ユーザID及び割り勘金額の正当性を確認した上で、取引情報テーブル23Dの該当の取引情報を更新する(ステップS712)。ここでは、取引ID「TR0001」の取引情報の割り勘情報について、割り勘対象ユーザIDに、取引者ユーザのユーザID「user_id_a」、上記のステップS710で設定された割り勘対象ユーザID「user_id_b」及び「user_id_c」が追加される。また、追加された割り勘対象ユーザIDのユーザそれぞれの割り勘金額「3,000」が追加される。
ここで、割り勘処理部212は、例えば、以下のような正当性の確認を行う。
・ユーザIDテーブル22Dを参照し、取引者ユーザと割り勘対象のユーザとが友達であるか否かの確認(又は、同一のグループやコミュニティに属しているか否かの確認)
・取引者ユーザの割り勘金額と、割り勘対象のユーザの割り勘金額との合計金額が購入金額に等しいか否かの確認
そして、決済管理装置20の割り勘処理部212は、決済処理部211に対して、割り勘対象ユーザIDに含まれるユーザから取引者ユーザを除くユーザの端末装置10に対して、取引IDと、割り勘金額を含む決済要求を送信するように依頼する。そして、決済処理部211は、当該決済要求を、端末装置10に送信する。ここでは、決済管理装置20の決済処理部211は、ユーザBの端末装置10-2及びユーザCの端末装置10-3に対して、当該決済要求を送信する(ステップS713-1及びS713-2)。
・ユーザIDテーブル22Dを参照し、取引者ユーザと割り勘対象のユーザとが友達であるか否かの確認(又は、同一のグループやコミュニティに属しているか否かの確認)
・取引者ユーザの割り勘金額と、割り勘対象のユーザの割り勘金額との合計金額が購入金額に等しいか否かの確認
そして、決済管理装置20の割り勘処理部212は、決済処理部211に対して、割り勘対象ユーザIDに含まれるユーザから取引者ユーザを除くユーザの端末装置10に対して、取引IDと、割り勘金額を含む決済要求を送信するように依頼する。そして、決済処理部211は、当該決済要求を、端末装置10に送信する。ここでは、決済管理装置20の決済処理部211は、ユーザBの端末装置10-2及びユーザCの端末装置10-3に対して、当該決済要求を送信する(ステップS713-1及びS713-2)。
端末装置10-2は、当該決済要求を受信すると、例えば図9(a)に示すような割り勘要求画面1300を、表示装置102に表示させる。そして、ユーザBは、割り勘要求画面1300に表示された取引者ユーザ名(ユーザA)や取引ID、割り勘金額、商品名等を確認し、自身が割り勘金額を支払うことに了解するための「承認」ボタンを押下する。
すると、端末装置10-2は、例えば図9(b)に示すような決済方法の設定画面1400に画面遷移させる。そして、ユーザBは、決済方法の設定画面1400の決済方法設定欄1401で、決済方法を「電子マネー」とするか「クレジットカード」とするかを設定して、「OK」ボタンを押下する(ステップS714-1)。ここでは、決済方法設定欄1101で「クレジットカード」決済の選択及びクレジットカード情報の入力が行われたものとする。ユーザCの端末装置10-3についても上記と同様である(ステップS714-2)。
すると、端末装置10-2の決済方法設定部111は、取引ID「TR0001」と、決済方法「クレジットカード」とを含む決済確認を生成し、当該決済確認を、決済管理装置20に対して送信する(ステップS715-1)。なお、このとき、決済方法には、上記のステップS714-1で設定された「クレジットカード情報」が含まれる。ここで、上記のステップS714-1で設定されたユーザBが用いるカード会社Bのクレジットカードを、「クレジットカードB」とし、クレジットカードBのクレジットカード情報を、「クレジットカード情報B」とする。
ユーザCの端末装置10-3についても、上記と同様である(ステップS715-2)。なお、ユーザCが用いるカード会社Cのクレジットカードを、「クレジットカードC」とし、クレジットカードCのクレジットカード情報を、「クレジットカード情報C」とする。
決済管理装置20の与信照会部213は、端末装置10-2から当該決済確認を受信すると、当該決済確認に含まれるクレジットカード情報Bに基づき、カード会社Bのクレジットカード決済システム40-2に対して、与信照会を送信する(ステップS716-1)。同様に、決済管理装置20の与信照会部213は、端末装置10-3から当該決済確認を受信すると、当該決済確認に含まれるクレジットカード情報Cに基づき、カード会社Cのクレジットカード決済システム40-3に対して、与信照会を送信する(ステップS716-2)。
そして、上記のそれぞれの与信照会が承認された場合、決済管理装置20は、それぞれのクレジットカード決済システム40-2及びクレジットカード決済システム40-3から承認を示す与信照会結果を、受信する。
決済管理装置20の与信照会部213は、取引者ユーザ以外のすべての割り勘対象のユーザ(ユーザB及びユーザC)の与信照会の承認を受信すると、取引者ユーザ(ユーザA)の上記のステップS707で行った与信照会の金額訂正を行う(ステップS717)。すなわち、決済管理装置20の与信照会部213は、上記のステップS707で行った与信照会の決済金額を、割り勘金額(ここでは、「3,000円」)に訂正する与信照会をクレジットカード決済システム40-1に対して送信する。そして、この決済金額が訂正された与信照会が承認された場合、決済管理装置20は、クレジットカード決済システム40-1から承認を示す与信照会結果を受信する。
なお、カード会社によっては、上記のような決済金額の訂正が行えない場合がある。このような場合は、上記のステップS707で行った与信照会を取り消して、割り勘金額を決済金額とする与信照会を再度、クレジットカード決済システム40に送信すればよい。
最後に、決済管理装置20の請求確定部214は、上記のステップS716-1、S716-2、及びS717で行ったすべての与信照会に対する請求確定を、それぞれのクレジットカード決済システム40に対して行う(ステップS718)。これにより、ユーザA、ユーザB、及びユーザCの間で、それぞれのクレジットカードによる割り勘金額の請求が確定する。
以上により、第1の実施形態に係る決済管理システム1では、一のユーザ(取引者ユーザ)が代表してクレジットカードで購入等した商品等の代金を、複数のユーザで割り勘してクレジットカード決済することができる。しかも、割り勘対象となる複数のユーザは、それぞれ所望のクレジットカードを用いて決済することができ、クレジットカードの種類やクレジットカード会社等は限定されない。
さらに、第1の実施形態に係る決済管理システム1では、取引者ユーザがクレジットカードで購入等した商品等の代金を複数のユーザで割り勘する場合、当該クレジットカードに対する与信照会が完了した時点で一旦取引を完了させる。したがって、商品等を販売する店舗等は、割り勘対象となる複数のユーザのすべての与信照会等が完了するのを待たずに、迅速に取引を行うことができる。
[第2の実施形態]
次に、第2の実施形態に係る決済管理システム1について説明する。第2の実施形態に係る決済管理システム1は、取引者ユーザが割り勘対象のユーザを設定しなかった場合や割り勘対象のユーザが割り勘金額の支払いを拒否した場合、割り勘対象ユーザが決済要求に対して応答しなかった場合等について説明するものである。なお、第2の実施形態に係る決済管理システム1のシステム構成及びハードウェア構成は、第1の実施形態と同様であるため説明を省略する。
次に、第2の実施形態に係る決済管理システム1について説明する。第2の実施形態に係る決済管理システム1は、取引者ユーザが割り勘対象のユーザを設定しなかった場合や割り勘対象のユーザが割り勘金額の支払いを拒否した場合、割り勘対象ユーザが決済要求に対して応答しなかった場合等について説明するものである。なお、第2の実施形態に係る決済管理システム1のシステム構成及びハードウェア構成は、第1の実施形態と同様であるため説明を省略する。
<ソフトウェア構成>
まず、第2の実施形態に係る決済管理システム1のソフトウェア構成について説明する。図10は、第2の実施形態に係る決済管理システムの一例の処理ブロック図である。第2の実施形態に係る決済管理システム1では、決済管理装置20の割り勘処理部212Aの機能が第1の実施形態と異なる。また、決済管理装置20の取引情報記憶部23Aに格納される取引情報テーブル23ADのデータ構成が異なる。したがって、以降では、これらの各部についてのみ説明する。
まず、第2の実施形態に係る決済管理システム1のソフトウェア構成について説明する。図10は、第2の実施形態に係る決済管理システムの一例の処理ブロック図である。第2の実施形態に係る決済管理システム1では、決済管理装置20の割り勘処理部212Aの機能が第1の実施形態と異なる。また、決済管理装置20の取引情報記憶部23Aに格納される取引情報テーブル23ADのデータ構成が異なる。したがって、以降では、これらの各部についてのみ説明する。
割り勘処理部212Aは、第1の実施形態において説明した機能に加えて、取引者ユーザが割り勘対象のユーザを所定の期間、設定しなかった場合、請求確定部214に請求確定を行うように依頼する。また、割り勘処理部212Aは、割り勘対象のユーザが割り勘金額の支払いを拒否した場合等に、取引情報テーブル23ADの取引者ユーザの割り勘金額の更新等を行う。
取引情報記憶部23Aは、取引情報テーブル23ADを記憶する。取引情報テーブル23ADは、例えば図11に示すようなデータ項目を有している。すなわち、第1の実施形態に係る取引情報テーブル23Dが有するデータ項目に加えて、該当の割り勘対象ユーザIDに請求確定を行えるか否かを示す請求確定可否のデータ項目を有する。
請求確定可否は、割り勘対象ユーザが決済に用いるクレジットカードの与信照会に対して承認を示す与信照会結果を、決済管理装置20が受け取った場合に「可」に更新される。したがって、取引不可を示す与信照会結果を決済管理装置20が受け取った場合や割り勘対象のユーザにより割り勘金額の支払いを拒否された場合等は、請求確定可否は「否」のままとなる。
<処理の詳細>
次に、第2の実施形態に係る決済管理システム1の処理の詳細について、図12を用いて説明する。図12は、第2の実施形態に係る割り勘決済処理の一例のシーケンス図である。以降の図12では、割り勘対象のユーザCが、割り勘金額の支払いを拒否した場合について説明する。なお、第1の実施形態と同様の処理を行う箇所については、適宜説明を簡略化する。
次に、第2の実施形態に係る決済管理システム1の処理の詳細について、図12を用いて説明する。図12は、第2の実施形態に係る割り勘決済処理の一例のシーケンス図である。以降の図12では、割り勘対象のユーザCが、割り勘金額の支払いを拒否した場合について説明する。なお、第1の実施形態と同様の処理を行う箇所については、適宜説明を簡略化する。
まず、ユーザAが端末装置10-1を用いて、店舗Aで商品を購入する(ステップS1201)。すると、端末装置10-1は、店舗端末30に対して、ユーザAのユーザIDを含む取引要求を送信する(ステップS1202)。
店舗端末30は、当該取引要求を受信すると、取引IDを採番して、当該取引IDを含む決済要求を、決済管理装置20に対して送信する(ステップS1203)。
決済管理装置20の決済処理部211は、当該決済要求を受信すると、取引IDと、取引金額とを含む決済要求を、取引者ユーザ(ユーザA)の端末装置10-1に対して送信する(ステップS1204)。
端末装置10-1は、当該決済要求を受信すると、例えば決済方法の設定画面1100を、表示装置102に表示させる。そして、ユーザAは、決済方法と、他のユーザと割り勘するか否かとを設定して、「OK」ボタンを押下する(ステップS1205)。ここでは、決済方法設定欄1101で「クレジットカード」決済の選択及びクレジットカード情報の入力が行われ、割り勘設定欄1102で他のユーザと「割り勘する」が設定されたものとする。
すると、端末装置10-1の決済方法設定部111は、決済確認を生成して、決済管理装置20に対して送信する(ステップS1206)。
決済管理装置20の与信照会部213は、当該決済確認を受信すると、クレジットカードAのカード会社Aのクレジットカード決済システム40-1に対して、与信照会を送信する(ステップS1207)。そして、当該与信照会が承認された場合、決済管理装置20は、クレジットカード決済システム40-1から承認を示す与信照会結果を受信する。
決済管理装置20の決済処理部211は、クレジットカード決済システム40-1から承認を示す与信照会結果を受信すると、店舗端末30及び端末装置10-1に対して、取引完了通知を送信する(ステップS1208及びS1209)。
次に、ユーザAは、端末装置10-1を操作して、上記で購入した商品の購入金額を割り勘するユーザを選択する(ステップS1210)。すると、端末装置10-1の割り勘ユーザ設定部112は、割り勘要求を生成して、決済管理装置20に対して送信する(ステップS1211)。
決済管理装置20の割り勘処理部212Aは、端末装置10-1に取引完了通知を送信してからN1日以内に端末装置10-1から当該割り勘要求を受信した場合、当該割り勘要求に含まれる割り勘対象ユーザID及び割り勘金額の正当性を確認した上で、取引情報テーブル23ADの該当の取引情報を更新する(ステップS1212)。このとき、取引情報テーブル23ADの各割り勘対象ユーザの請求確定可否は「否」に更新される。
他方、ステップS1212において、決済管理装置20の割り勘処理部212Aは、端末装置10-1に取引完了通知を送信してからN1日を経過した場合、請求確定部214に対して、ステップS1207で行った与信照会に対する請求確定を行うように依頼する。そして、請求確定部214は、当該与信照会に対する請求確定を行う。これにより、取引者ユーザの端末装置10が取引完了通知を受信した後、N1日以内に割り勘対象となるユーザの設定が行われない場合は、取引者ユーザが購入金額の全額を決済するように制御される。したがって、取引者ユーザが割り勘対象となるユーザを長期間設定しないことにより、請求確定が長期間行われないといった事態を防止することができる。なお、N1日は、例えば、1日ないし2日程度が好ましい。以降では、決済管理装置20の割り勘処理部212は、取引完了通知を送信してからN1日以内に端末装置10-1から割り勘要求を受信したものとして説明する。
決済管理装置20の割り勘処理部212は、決済処理部211に対して、取引者ユーザを除く割り勘対象のユーザの端末装置10に決済要求を送信するように依頼する。そして、決済処理部211は、当該決済要求を、端末装置10に送信する。ここでは、決済管理装置20の決済処理部211は、ユーザBの端末装置10-2及びユーザCの端末装置10-3に対して、当該要求を送信する(ステップS1213-1及びS1213-2)。
端末装置10-2は、当該決済要求を受信すると、例えば割り勘要求画面1300を、表示装置102に表示させる。そして、ユーザBは、割り勘要求画面1300の内容を確認し、自身が割り勘金額を支払うことに了解するための「承認」ボタンを押下する。
すると、端末装置10-2は、例えば決済方法の設定画面1400に画面遷移させる。そして、ユーザBは、決済方法の設定画面1400の決済方法設定欄1401で、決済方法を設定して、「OK」ボタンを押下する(ステップS1214-1)。ここでは、決済方法設定欄1101で「クレジットカード」決済の選択及びクレジットカード情報の入力が行われたものとする。なお、決済方法設定欄1101において「電子マネー」決済が設定された場合、ユーザBの割り勘金額分の電子マネーをユーザAの電子マネー口座に送金するようにして、当該ユーザBの割り勘金額分をユーザAのクレジットカードAで決済するように制御すればよい。
他方、端末装置10-3は、当該決済要求を受信すると、例えば割り勘要求画面1300を、表示装置102に表示させる。そして、ユーザCは、割り勘要求画面1300の内容を確認し、割り勘金額の支払いを拒否するための「拒否」ボタンを押下したものとする(ステップS1214-2)。
すると、端末装置10-2の決済方法設定部111は、決済確認を生成して、決済管理装置20に対して送信する(ステップS1215-1)。他方、端末装置10-3は、取引ID「TR0001」を含む決済拒否を生成し、当該取引拒否を、決済管理装置20に対して送信する(ステップS1215-2)。
次に、決済管理装置20の割り勘処理部212Aは、端末装置10-2にステップS1213-1の決済要求を送信してからN2日以内に端末装置10-2から当該決済確認を受信した場合、与信照会部213に与信照会を依頼する。そして、与信照会部213は、クレジットカード情報Bに基づき、カード会社Bのクレジットカード決済システム40-2に対して、与信照会を送信する(ステップS1216)。そして、決済管理装置20の割り勘処理部212Aは、上記の与信照会が承認された場合、取引情報テーブル23ADの該当の取引情報における該当の割り勘対象ユーザの請求確定可否を「可」に更新する。すなわち、割り勘処理部212Aは、取引ID「TR0001」の取引情報における割り勘対象ユーザID「user_id_b」の請求確定可否を「可」に更新する。
他方、ステップS1216において、決済管理装置20の割り勘処理部212Aは、端末装置10-2にステップS1213-1の決済要求を送信してからN2日を経過した場合、端末装置10-2に対して決済不可通知を送信する。
以上のように、取引者ユーザを除く割り勘対象のユーザの与信照会は、当該割り勘対象のユーザの端末装置10に対して決済要求を送信してからN2日以内に行う必要がある。N2日を経過した場合には、後述するように、取引者ユーザが、N2日経過時点で与信照会を行っていない割り勘対象のユーザの割り勘金額を支払うこととする。したがって、割り勘対象のユーザが、割り勘金額に対して長期間、支払いを承認しないことにより、請求確定が長期間行われないといった事態を防止することができる。なお、N2日は、例えば、2日ないし3日程度が好ましい。以降では、決済管理装置20の割り勘処理部212Aは、端末装置10-2に決済要求を送信してからN2日以内に端末装置10-1から決済確認を受信し、上記の与信照会が行われたものとして説明する。
続いて、決済管理装置20の割り勘処理部212Aは、取引情報テーブル23ADを参照し、請求確定可否が「否」となっている割り勘対象のユーザ(取引者ユーザを除く)の割り勘金額を、取引者ユーザの割り勘金額に上乗せする更新を行う(ステップS1217)。すなわち、ここでは、割り勘対象ユーザID「user_id_c」の割り勘金額「3,000」を「0」にする一方、割り勘対象ユーザID「user_id_a」(取引者ユーザ)の割り勘金額を「6,000」とする。これにより、割り勘金額の支払いを拒否した割り勘対象のユーザの割り勘金額は、取引者ユーザが支払うこととなる。また、決済要求を送信してからN2日以内に与信照会が行われなかった割り勘対象のユーザについても、同様に、当該割り勘対象のユーザの割り勘金額は、取引者ユーザが支払うこととなる。
決済管理装置20の与信照会部213は、取引者ユーザ(ユーザA)の上記のステップS1207で行った与信照会の金額訂正を行う(ステップS1218)。すなわち、決済管理装置20の与信照会部213は、上記のステップS1218で行った与信照会の決済金額を、上記のステップS1217で更新された割り勘金額(ここでは、「6,000円」)に訂正する与信照会をクレジットカード決済システム40-1に対して送信する。そして、決済管理装置20の割り勘処理部212Aは、上記の与信照会が承認された場合、取引情報テーブル23ADの該当の取引情報における取引者ユーザの請求確定可否を「可」に更新する。すなわち、割り勘処理部212Aは、取引ID「TR0001」の取引情報における割り勘対象ユーザID「user_id_a」の請求確定可否を「可」に更新する。
最後に、決済管理装置20の割り勘処理部212Aは、取引情報テーブル23ADを参照して、該当の取引情報において、請求確定可否が「可」となっている割り勘対象ユーザの与信照会に対する請求確定を、請求確定部214に対して依頼する。そして、請求確定部214は、当該請求確定を、それぞれのクレジットカード決済システム40に対して行う(ステップS1219)。すなわち、ここでは、上記のステップS1216で行ったユーザB(ユーザID「user_id_b」)の与信照会に対する請求確定と、上記のステップS1218で行ったユーザA(ユーザID「user_id_a」)の与信照会に対する請求確定とを行う。これにより、ユーザA及びユーザBの間で、それぞれのクレジットカードにより割り勘金額の請求が確定する。なお、このとき、決済される割り勘金額は、上述した通り、ユーザAは「6,000円」、ユーザBは「3,000円」となる(すなわち、支払いを拒否したユーザCの割り勘金額が、ユーザAの割り勘金額に上乗せされている。)。このように、割り勘対象の複数のユーザのうちの1以上のユーザが、割り勘金額の支払いを拒否した場合や承認期間(上記のN2日)を徒過した場合等は、取引者ユーザが当該拒否したユーザや当該徒過したユーザの割り勘金額を支払うように制御される。
<まとめ>
以上のように、第1の実施形態に係る決済管理システム1では、取引者ユーザが代表してクレジットカードで購入等した商品等の代金を、複数のユーザで割り勘してクレジットカード決済することができる。しかも、割り勘対象となる複数のユーザは、それぞれ所望のクレジットカードを用いて決済することができ、クレジットカードの種類やクレジットカード会社等は限定されない。
以上のように、第1の実施形態に係る決済管理システム1では、取引者ユーザが代表してクレジットカードで購入等した商品等の代金を、複数のユーザで割り勘してクレジットカード決済することができる。しかも、割り勘対象となる複数のユーザは、それぞれ所望のクレジットカードを用いて決済することができ、クレジットカードの種類やクレジットカード会社等は限定されない。
さらに、第1の実施形態に係る決済管理システム1では、取引者ユーザがクレジットカードで購入等した商品等の代金を複数のユーザで割り勘する場合、当該クレジットカードに対する与信照会が完了した時点で一旦取引を完了させる。したがって、商品等の販売元である店舗等は、割り勘対象となる複数のユーザのすべての与信照会等が完了するのを待たずに、迅速に取引を行うことができる。
また、第2の実施形態に係る決済管理システム1では、割り勘対象の複数のユーザのうちの1以上のユーザが、割り勘金額の支払いを拒否した場合や承認期間を徒過した場合等は、不足分の割り勘金額を取引者ユーザが支払うようにすることができる。
以上、本発明の好ましい実施形態について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、請求の範囲に記載された本発明の要旨の範囲内において、種々の変形又は変更が可能である。
本願は、日本国に2015年2月16日に出願された基礎出願2015-027316号に基づくものであり、その全内容はここに参照をもって援用される。
1 決済管理システム
10 端末装置
11 決済アプリケーション
20 決済管理装置
21 決済管理プログラム
22 ユーザID記憶部
22D ユーザIDテーブル
23 取引情報記憶部
23D 取引情報テーブル
30 店舗端末
40 クレジットカード決済システム
111 決済方法設定部
112 割り勘ユーザ設定部
211 決済処理部
212 割り勘処理部
213 与信照会部
214 請求確定部
N ネットワーク
10 端末装置
11 決済アプリケーション
20 決済管理装置
21 決済管理プログラム
22 ユーザID記憶部
22D ユーザIDテーブル
23 取引情報記憶部
23D 取引情報テーブル
30 店舗端末
40 クレジットカード決済システム
111 決済方法設定部
112 割り勘ユーザ設定部
211 決済処理部
212 割り勘処理部
213 与信照会部
214 請求確定部
N ネットワーク
Claims (8)
- 1以上の情報処理装置を含む情報処理システムであって、
所定の商取引に関して決済を行うことに対する承諾を要求する第1の要求が第1の端末装置に送信されたことで、該第1の端末装置より該第1の要求に対する応答を受信すると、該決済に用いられるクレジットカードについて、与信照会を行う第1の与信照会手段と、
前記第1の要求に対する応答に、前記決済を複数のユーザによって行うことを示す割り勘情報が含まれていた場合であって、前記与信照会を行ってから所定の期間が経過する前に、前記所定の商取引の内容が変更された場合に、変更後の該商取引に関して決済を行うよう指示する決済指示手段と
を有することを特徴とする情報処理システム。 - 前記第1の要求に対する応答に、前記割り勘情報が含まれていたことで、該複数のユーザのうち、前記第1の要求に対して応答したユーザを除く残りのユーザそれぞれに新たに商取引が発生した場合に、該新たに発生した商取引に関して決済を行うことに対する承諾を、該残りのユーザが有する第2の端末装置に対して要求する第2の要求を送信する送信手段と、
前記第2の端末装置より前記第2の要求に対する応答を受信すると、該残りのユーザのうち、クレジットカードを使用して決済を行うことを希望するユーザのそれぞれに発生した商取引の決済に用いられるクレジットカードについて、与信照会を行う第2の与信照会手段と、
前記第2の与信照会手段により行われた与信照会の結果に基づいて、前記所定の商取引の内容を変更する変更手段と
を有することを特徴とする請求項1に記載の情報処理システム。 - 前記変更手段は、
前記新たに発生した商取引のうち決済が行われる商取引を、前記第2の与信照会手段により行われた与信照会に基づいて特定し、該決済が行われる商取引の内容に基づいて、前記所定の商取引の内容を変更することを特徴とする請求項2に記載の情報処理システム。 - 前記第2の要求には、前記残りのユーザそれぞれに新たに発生した商取引の金額である割り勘金額が含まれることを特徴とする請求項2又は3に記載の情報処理システム。
- 前記割り勘金額は、前記残りのユーザそれぞれに指定された金額または前記所定の商取引の金額を、前記複数のユーザで均等に配分した金額であることを特徴とする請求項4に記載の情報処理システム。
- 前記第2の与信照会手段は、
前記残りのユーザに電子マネーを使用して決済を行うことを希望するユーザが含まれる場合、該ユーザのそれぞれに発生した商取引の決済を、該商取引の金額に対応する電子マネーを前記第1の要求に対して応答したユーザに対して支払うことで行うことを特徴とする、請求項2ないし5のいずれか1項に記載の情報処理システム。 - 前記決済指示手段は、
前記第1の要求に対する応答に、前記割り勘情報が含まれていた場合であっても、前記所定の商取引の内容が変更されることなく、前記与信照会を行ってから所定の期間が経過した場合には、前記所定の商取引に関して決済を行うよう指示することを特徴とする請求項1に記載の情報処理システム。 - 所定の商取引に関して決済を行うことに対する承諾を要求する第1の要求が第1の端末装置に送信されたことで、該第1の端末装置より該第1の要求に対する応答を受信すると、該決済に用いられるクレジットカードについて、与信照会を行う与信照会工程と、
前記第1の要求に対する応答に、前記決済を複数のユーザによって行うことを示す割り勘情報が含まれていた場合であって、前記与信照会を行ってから所定の期間が経過する前に、前記所定の商取引の内容が変更された場合に、変更後の該商取引に関して決済を行うよう指示する決済指示工程と
を有することを特徴とする情報処理方法。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
KR1020177020836A KR102002111B1 (ko) | 2015-02-16 | 2016-01-18 | 정보처리 시스템 및 정보처리 방법 |
CN201680006523.4A CN107251070A (zh) | 2015-02-16 | 2016-01-18 | 信息处理***和信息处理方法 |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2015-027316 | 2015-02-16 | ||
JP2015027316A JP2016151785A (ja) | 2015-02-16 | 2015-02-16 | 情報処理システム及び情報処理方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2016132791A1 true WO2016132791A1 (ja) | 2016-08-25 |
Family
ID=56622375
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/JP2016/051311 WO2016132791A1 (ja) | 2015-02-16 | 2016-01-18 | 情報処理システム及び情報処理方法 |
Country Status (5)
Country | Link |
---|---|
US (1) | US20160239838A1 (ja) |
JP (1) | JP2016151785A (ja) |
KR (1) | KR102002111B1 (ja) |
CN (1) | CN107251070A (ja) |
WO (1) | WO2016132791A1 (ja) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2020017052A (ja) * | 2018-07-25 | 2020-01-30 | 楽天株式会社 | 決済システム、決済方法、及びプログラム |
JP2020113124A (ja) * | 2019-01-15 | 2020-07-27 | 東芝テック株式会社 | 情報処理装置及び情報処理プログラム |
JP2020129280A (ja) * | 2019-02-08 | 2020-08-27 | 株式会社メルカリ | 情報処理方法、情報処理装置、及び情報処理プログラム |
Families Citing this family (15)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CA3215168A1 (en) * | 2016-02-01 | 2017-08-01 | UGO Mobile Solutions L.P. | Stored-value card agent |
JP2018036977A (ja) * | 2016-09-02 | 2018-03-08 | 富士ゼロックス株式会社 | 情報処理装置及びプログラム |
CN107392582B (zh) * | 2017-05-22 | 2020-04-28 | 阿里巴巴集团控股有限公司 | 资源转移的实现方法和装置、收付款的实现方法和装置 |
JP6391779B1 (ja) * | 2017-07-13 | 2018-09-19 | 株式会社ぐるなび | 決済支援方法、決済支援装置、及び決済支援プログラム |
CN112036854A (zh) * | 2018-08-13 | 2020-12-04 | 创新先进技术有限公司 | 收款控制方法、装置、服务器及可读存储介质 |
CN112889080B (zh) * | 2018-08-14 | 2024-05-24 | 维萨国际服务协会 | 用于划分移动装置交易的***、方法和计算机程序产品 |
JP6684873B2 (ja) * | 2018-08-21 | 2020-04-22 | 株式会社ぐるなび | 決済支援方法、決済支援装置、及び決済支援プログラム |
JP6934461B2 (ja) * | 2018-09-28 | 2021-09-15 | 富士通フロンテック株式会社 | 情報処理装置および情報処理システム |
JP6640313B1 (ja) * | 2018-11-16 | 2020-02-05 | 株式会社メルカリ | 情報処理方法、情報処理装置、及びプログラム |
JP7092699B2 (ja) * | 2019-02-08 | 2022-06-28 | 株式会社メルカリ | 情報処理方法、情報処理装置、及び情報処理プログラム |
JP2020129279A (ja) * | 2019-02-08 | 2020-08-27 | 株式会社メルカリ | 情報処理方法、情報処理装置、及び情報処理プログラム |
JP7332858B2 (ja) * | 2019-05-10 | 2023-08-24 | 株式会社Mixi | 電子決済システム、情報処理装置及び電子決済プログラム |
KR20220107259A (ko) * | 2019-12-05 | 2022-08-02 | 라인 페이 가부시키가이샤 | 프로그램, 정보처리방법, 단말 |
JP2021196628A (ja) | 2020-06-09 | 2021-12-27 | トヨタ自動車株式会社 | ウォレットサーバ、ウォレットシステム、およびプログラム |
JP6976467B1 (ja) * | 2021-03-16 | 2021-12-08 | Kddi株式会社 | 決済処理装置及び決済処理方法 |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20020103753A1 (en) * | 2001-01-31 | 2002-08-01 | Michael Schimmel | Charge splitter application |
JP2004280318A (ja) * | 2003-03-14 | 2004-10-07 | Hitachi Ltd | 割り前勘定決済方法 |
JP2005107778A (ja) * | 2003-09-30 | 2005-04-21 | Japan Research Institute Ltd | 売上情報処理方法およびクレジットカードシステム |
JP2009205434A (ja) * | 2008-02-27 | 2009-09-10 | Rakuten Inc | 電子商取引システム |
JP2009230312A (ja) * | 2008-03-21 | 2009-10-08 | Hitachi Software Eng Co Ltd | クレジットカード決済システムおよび方法 |
Family Cites Families (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1512419A (zh) * | 2002-12-27 | 2004-07-14 | 桥本胜美 | 信贷货款的垫付支付方法 |
US20050125347A1 (en) * | 2003-12-08 | 2005-06-09 | Akialis Ronald P.Jr. | Bill payment authorization system and method |
KR20120008229A (ko) * | 2010-07-16 | 2012-01-30 | 주식회사 디자인메이드 | 청구금액 분할 결제 방법 |
JP5667419B2 (ja) * | 2010-11-24 | 2015-02-12 | 株式会社ミクシィ | ソーシャルネットワーキングサービス提供サーバ、及び同サービスにおけるプレゼント贈答方法 |
KR20120108447A (ko) * | 2011-03-24 | 2012-10-05 | 서동석 | 신용카드 및 통신 단말기를 이용한 더치페이 방법 및 시스템 |
US20130006853A1 (en) * | 2011-06-28 | 2013-01-03 | Christopher David Amundsen | Enterprise system, method and computer program product for aggregating and pro rating expenses across members of a networked virtual collective |
US9355394B2 (en) * | 2011-08-11 | 2016-05-31 | Visa International Service Association | Systems and methods of aggregating split payments using a settlement ecosystem |
KR20130089896A (ko) * | 2012-01-10 | 2013-08-13 | 한국정보통신주식회사 | 더치 페이 결제 기능을 구비하는 휴대 단말기, 결제 단말기 및 결제 대행 서버, 및 이를 이용한 결제 방법 및 결제 대행 방법 |
JP5836162B2 (ja) * | 2012-03-08 | 2015-12-24 | 株式会社日本総合研究所 | クレジットカードシステム |
JP2013225228A (ja) * | 2012-04-23 | 2013-10-31 | Naohiro Segawa | 共同購入装置、共同購入方法、およびプログラム |
KR20140065700A (ko) * | 2012-11-20 | 2014-05-30 | 주식회사 주피터라이프시스템 | 스마트폰을 이용한 공동 분담 결제 시스템 및 방법 |
JP5911415B2 (ja) * | 2012-12-05 | 2016-04-27 | インターナショナル・ビジネス・マシーンズ・コーポレーションInternational Business Machines Corporation | 割り勘による支払いを支援するシステム及び方法 |
CN103500401A (zh) * | 2013-09-27 | 2014-01-08 | 华为技术有限公司 | 一种支付方法、装置及*** |
-
2015
- 2015-02-16 JP JP2015027316A patent/JP2016151785A/ja active Pending
- 2015-08-19 US US14/830,451 patent/US20160239838A1/en not_active Abandoned
-
2016
- 2016-01-18 WO PCT/JP2016/051311 patent/WO2016132791A1/ja active Application Filing
- 2016-01-18 KR KR1020177020836A patent/KR102002111B1/ko active IP Right Grant
- 2016-01-18 CN CN201680006523.4A patent/CN107251070A/zh active Pending
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20020103753A1 (en) * | 2001-01-31 | 2002-08-01 | Michael Schimmel | Charge splitter application |
JP2004280318A (ja) * | 2003-03-14 | 2004-10-07 | Hitachi Ltd | 割り前勘定決済方法 |
JP2005107778A (ja) * | 2003-09-30 | 2005-04-21 | Japan Research Institute Ltd | 売上情報処理方法およびクレジットカードシステム |
JP2009205434A (ja) * | 2008-02-27 | 2009-09-10 | Rakuten Inc | 電子商取引システム |
JP2009230312A (ja) * | 2008-03-21 | 2009-10-08 | Hitachi Software Eng Co Ltd | クレジットカード決済システムおよび方法 |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2020017052A (ja) * | 2018-07-25 | 2020-01-30 | 楽天株式会社 | 決済システム、決済方法、及びプログラム |
JP7053396B2 (ja) | 2018-07-25 | 2022-04-12 | 楽天グループ株式会社 | 決済システム、決済方法、及びプログラム |
JP2020113124A (ja) * | 2019-01-15 | 2020-07-27 | 東芝テック株式会社 | 情報処理装置及び情報処理プログラム |
JP2020129280A (ja) * | 2019-02-08 | 2020-08-27 | 株式会社メルカリ | 情報処理方法、情報処理装置、及び情報処理プログラム |
Also Published As
Publication number | Publication date |
---|---|
JP2016151785A (ja) | 2016-08-22 |
CN107251070A (zh) | 2017-10-13 |
KR20170102282A (ko) | 2017-09-08 |
US20160239838A1 (en) | 2016-08-18 |
KR102002111B1 (ko) | 2019-07-26 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
WO2016132791A1 (ja) | 情報処理システム及び情報処理方法 | |
US20130036000A1 (en) | Financial transaction system and method | |
JP6657364B1 (ja) | 情報処理装置、支払管理方法、プログラム、管理方法、及びユーザ機器 | |
CN103270523A (zh) | 延期支付以及选择性的资金和支付 | |
US11354650B2 (en) | Payment card asset construction service | |
JP2020030462A (ja) | 情報処理装置、情報処理方法および情報処理プログラム | |
KR20140106012A (ko) | 모바일 쇼핑에서의 대리 결제 시스템 및 방법 | |
KR101931802B1 (ko) | 원리금 수취권 거래 시스템 및 방법 | |
JP2023039762A (ja) | 電子決済システム、電子決済方法、およびプログラム | |
KR20160044193A (ko) | 대출 서비스 제공 장치 및 방법 | |
US10242354B2 (en) | Selectively providing cash-based e-commerce transactions | |
TW201327446A (zh) | 網路平台信託交易方法及該網路交易平台 | |
US20210304159A1 (en) | Server, computer-readable recording medium and system | |
KR101666084B1 (ko) | 매출채권 담보대출 관리시스템 및 관리방법 | |
KR20180130980A (ko) | 프랜차이즈 대출 서비스를 제공하는 컴퓨팅 장치 및 방법 | |
JP2018124640A (ja) | 貿易支援方法、仮想通貨管理方法、貿易支援システム、仮想通貨管理システム、貿易支援プログラム、および仮想通貨管理プログラム | |
JP2020123394A (ja) | 情報処理システム及び情報処理方法 | |
JP6564118B1 (ja) | 情報処理装置、情報処理方法および情報処理プログラム | |
KR20210095022A (ko) | 분할, 병합 및 형태 변경이 가능한 원리금 수취권 가공 시스템 | |
KR20110123492A (ko) | 중고 도서 거래 방법 및 시스템 | |
JP2016110491A (ja) | 取引情報処理システム | |
KR102662576B1 (ko) | 제휴 판매사에 예약 대신 결제 처리를 제공하기 위한 관계 생성 서비스 제공 방법 및 이를 이용한 시스템 | |
JP7141504B1 (ja) | 提供装置、提供方法及び提供プログラム | |
JP7195391B1 (ja) | 電子決済システム、電子決済サーバ、電子決済方法、およびプログラム | |
JP7319406B2 (ja) | 提供装置、提供方法及び提供プログラム |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 16752180 Country of ref document: EP Kind code of ref document: A1 |
|
ENP | Entry into the national phase |
Ref document number: 20177020836 Country of ref document: KR Kind code of ref document: A |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
122 | Ep: pct application non-entry in european phase |
Ref document number: 16752180 Country of ref document: EP Kind code of ref document: A1 |