Information processing device, information processing method, program, and application program
The information processing device and method facilitate proper remittance by allowing users to allocate funds to another user's account for a set period, ensuring funds are used as intended and distributing any excess back to the contributors.
Patent Information
- Application Number
- JP2023111483
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2023-07-06
- Publication Date
- 2025-01-20
- Estimated Expiration
- 2043-07-06
AI Technical Summary
Conventional electronic payment services often result in money being used improperly by recipients, especially when receiving excessive amounts from multiple parties, leading to improper remittance processing.
An information processing device and method that allows users to allocate a specific amount of money to another user's account for a predetermined period, with payment processing units managing these allocations and deductions based on user settings and preferences.
Enables proper remittance between users by ensuring the allocated funds are used as intended, distributing the burden among multiple contributors and returning any remaining balance to them, thus preventing misuse.
Smart Images

Figure 2025008885000001_ABST
Abstract
Description
[Technical Field]
[0001] The present invention relates to an information processing device, an information processing method, a program, and an application program. [Background technology]
[0002] Conventionally, technologies for enabling person-to-person remittances in electronic payment services have been known. For example, Patent Document 1 discloses a technology that acquires and analyzes messages between users, and when it is estimated that a remittance between the users is necessary, displays a remittance acceptance message on the user's terminal and accepts a remittance instruction. [Prior art documents] [Patent documents]
[0003] [Patent Document 1] Japanese Patent Publication No. 2022-145215 Summary of the Invention [Problem to be solved by the invention]
[0004] The technology described in Cited Document 1 facilitates remittance processing between trusted users, such as family groups. However, with the prior art, remitted money is not always used as intended by the remitter, and the recipient may receive excessive amounts of money from multiple recipients. In other words, with the prior art, remittances between users may not be properly conducted.
[0005] The present invention has been made in consideration of the above circumstances, and one of its objects is to provide an information processing device, an information processing method, a program, and an application program that can realize appropriate remittances between users. [Means for solving the problem]
[0006] One aspect of the present invention is an information processing device that includes a transceiver that receives, from a first user terminal device of multiple first users who use an electronic payment service, a designation to grant an amount limit that can be used for payments in the electronic payment service during a specified period to the electronic payment service account of a second user who uses the electronic payment service, and a payment processing unit that sets the amount limit corresponding to the multiple first users in correspondence with the electronic payment service account of the second user based on the received designation, wherein the payment processing unit deducts the payment amount for the electronic payment service from the amount limit when the amount limit is set in correspondence with the electronic payment service account of the second user and the second user uses the electronic payment service during the specified period. [Effects of the Invention]
[0007] According to one aspect of the present invention, it is possible to provide an information processing device, an information processing method, a program, and an application program that can realize proper remittance between users. [Brief explanation of the drawings]
[0008] [Figure 1] FIG. 1 is a diagram illustrating an example of a configuration for realizing an electronic payment service. [Figure 2] This is a sequence diagram (part 1) illustrating the general flow of electronic payment. [Figure 3] This is a sequence diagram (part 2) illustrating the general flow of electronic payment. [Figure 4] FIG. 2 is a configuration diagram of a payment server 100 according to the first embodiment. [Figure 5] FIG. 10 is a diagram showing an example of the contents of user information 172. [Figure 6] FIG. 10 is a diagram showing an example of the contents of affiliated store / store information 176. [Figure 7] FIG. 10 is a diagram showing an example of a top screen of the payment application 20. [Figure 8] FIG. 2 is a diagram for explaining an outline of a shared wallet function provided by the payment server 100. [Figure 9] FIG. 10 is a diagram showing an example of the contents of shared wallet master information 178. [Figure 10] FIG. 10 is a diagram showing an example of the contents of shared wallet individual information 180. [Figure 11] FIG. 10 is a diagram showing an example of shared wallet provision settings executed on a first user terminal device 10A. [Figure 12] FIG. 10 is a diagram showing an example of a shared wallet request setting executed on the second user terminal device 10B. [Figure 13] FIG. 10 is a diagram showing an example of a payment screen displayed by a second user terminal device 10B in which shared wallet payment is enabled. [Figure 14] FIG. 10 is a diagram showing an example of a payment history viewing screen displayed by the first user terminal device 10A. [Figure 15] FIG. 10 is a diagram showing an example of a screen displayed by the second user terminal device 10B for setting the disclosure range of the shared wallet payment usage history. [Figure 16] FIG. 10 is a diagram showing an example of a benefit provided to the first user terminal device 10A. [Figure 17] FIG. 10 is a diagram showing another example of a benefit provided to the first user terminal device 10A. [Figure 18] FIG. 10 is a diagram showing an example of provision settings for a shared wallet according to a modified example. DETAILED DESCRIPTION OF THE INVENTION
[0009] Hereinafter, with reference to the drawings, embodiments of an information processing device, an information processing method, a program, and an application program of the present invention will be described. A payment app and a payment server work together to provide an electronic payment service. The electronic payment service is a service that supports payments for the purchase of goods and services at a store. A store is, for example, a physical store (real store) existing in real space, but may also include a virtual store for e-commerce. A virtual store may also include a store provided by an entity different from the operator of the electronic payment service. In such a case, when paying for purchases at the virtual store, the user is controlled to transition to the interface screen of the electronic payment service. In an electronic payment service, a store is treated as belonging to, for example, an affiliated store (brand), and processing such as payment when a purchase is made at a store is primarily conducted between the user and the affiliated store. Alternatively, processing such as payment may be conducted between the user and the store.
[0010] [Electronic payment service] FIG. 1 illustrates an example of a configuration for implementing an electronic payment service. The electronic payment service is realized primarily around a payment server 100. The payment server 100 communicates with, for example, one or more first user terminal devices 10A, one or more second user terminal devices 10B, one or more first store terminal devices 50, and one or more second store terminal devices 70 via a network NW. The network NW includes, for example, the Internet, a local area network (LAN), a wireless base station, a provider device, and the like. For convenience of explanation, the following description will be given assuming that there are multiple first user terminal devices 10A and one second user terminal device 10B. However, it is sufficient that there are one or more first user terminal devices 10A for at least one second user terminal device 10B. Furthermore, in the following description, when there is no functional distinction between the first user terminal device 10A and the second user terminal device 10B, they will be referred to as "user terminal devices 10."
[0011] The user terminal device 10 is, for example, a portable terminal device such as a smartphone or tablet terminal. The user terminal device 10 is a computer device having at least an optical reading function, a communication function, a display function, an input acceptance function, and a program execution function. In the following description, components for realizing these functions are referred to as a camera, a communication device, a touch panel, a CPU (Central Processing Unit), etc. In the user terminal device 10, a processor such as a CPU executes a payment app 20, which operates in cooperation with the payment server 100 to provide electronic payment services to users. The payment app 20 is installed on the user terminal device 10 from, for example, an application store, and controls the camera, communication device, touch panel, etc.
[0012] The first store terminal device 50 is installed, for example, in a store. The first store terminal device 50 is a computer device having at least a product price acquisition function, an optical reading function, a program execution function, and a communication function. The first store terminal device 50 includes a so-called POS (Point of Sale) device, and the product price acquisition function and the optical reading function may be realized by the POS device. The store code image 60 is placed in the store and is a code image such as a QR code (registered trademark) printed on a paper or plastic medium. The store code image 60 may be displayed on a display placed in the store (which may be the display of a terminal device such as a smartphone).
[0013] The second store terminal device 70 is used by the operator of the affiliated store. The second store terminal device 70 is a smartphone, tablet terminal, personal computer, etc. An interface for affiliated stores 72 runs on the second store terminal device 70. The interface for affiliated stores 72 may be an app for affiliated stores or a browser. The interface for affiliated stores 72 accepts coupon settings and the like from the operator of the affiliated store and transmits them to the payment server 100. The second store terminal device 70, which is a smartphone, has the function of displaying a code image corresponding to a store code image and reading the code image displayed by the user terminal device 10 by executing the app for affiliated stores.
[0014] The payment server 100 realizes electronic payment based on payment information received from the user terminal device 10 or the first store terminal device 50. The first store terminal device 50 may include a POS device and an affiliated store server, in which case payment information is sent from the POS device via the affiliated store server to the payment server 100. In the following explanation, this distinction will not be made and it is assumed that payment information is sent from the first store terminal device 50.
[0015] 2 and 3 are sequence diagrams illustrating the general flow of electronic payment. There may be two patterns for electronic payment: Pattern 1 and Pattern 2.
[0016] In the case of pattern 1 (hereinafter referred to as user scan) shown in FIG. 2, the user terminal device 10, with the payment application 20 running, decodes the store code image 60 using its optical reading function (S1). The store code image 60 includes store URL (Uniform Resource Locator) information. This store URL is the domain of the electronic payment service to which store identification information has been added, and is associated with an affiliated store ID, store ID, etc. in the payment server 100 (described below). The payment application 20 sends first payment information including the store URL and account ID to the payment server 100 (S2). The payment server 100 searches for store information (described below) using the affiliated store ID and store ID corresponding to the store URL, acquires the affiliated store name and store name information (S3), and sends this to the payment application 20 (S4). The user enters the payment amount into the user terminal device 10 on the screen displaying the affiliated store name and store name (S5). Then, the user terminal device 10 generates second payment information including at least the payment amount and sends it to the payment server 100 (S6). The payment server 100 makes the electronic payment based on the received second payment information (S7). The payment server 100 then sends a payment completion notice (information for displaying a payment completion screen) to the payment app 20 (S8), and the payment app 20 displays the payment completion screen (S9). Note that when the store code image 60 is displayed on a display installed in the store, the store code image 60 may include information on the payment amount in addition to the store URL. In this case, the step of the user inputting the payment amount is omitted, and the payment amount information is included in the first payment information and sent to the payment server 100. Information on the affiliated store name and store name may be included and displayed on the payment completion screen.
[0017] In the case of pattern 2 (hereinafter referred to as store scan) shown in FIG. 3, the payment app 20 sends a request to issue a one-time code to the payment server 100 when the payment app 20 is launched, when a payment operation is performed in the payment app 20, at the automatic update timing (e.g., every minute), and at other timings (S11). The payment server 100 generates a one-time code (S12) and sends it to the payment app 20 (S13). The payment app 20 displays a code image, such as a QR code or barcode, generated based on the one-time code (S14). The user holds (presents) the display surface of the user terminal device 10 over the first in-store terminal device 50, and the first in-store terminal device 50 decodes the code image using its optical reading function and obtains the one-time code, etc. (S15). The first in-store terminal device 50 then generates payment information including the one-time code, payment amount, affiliated store ID, store ID, etc., and sends it to the payment server 100 (S16). The payment amount information is acquired in advance by reading a barcode, manually entering it, etc. Based on the received information, the payment server 100 identifies the user corresponding to the one-time code and performs electronic payment (S17). Then, the payment server 100 sends a payment completion notice to the payment application 20 (S18), and the payment application 20 displays a payment completion screen (S19).
[0018] Note that electronic payment may be performed using only one of the above patterns. Furthermore, the "account ID" described in FIG. 2 may be other information (e.g., a phone number) that can be used as user identification information. Furthermore, issuing a one-time code may be omitted in store scanning, and the payment application 20 may display a code image generated based on the user's account ID. In this case, the payment server 100 identifies the user corresponding to the account ID instead of identifying the user corresponding to the one-time code.
[0019] [Payment server] FIG. 4 is a configuration diagram of the payment server 100 according to the first embodiment. The payment server 100 includes, for example, a communication unit 110, a payment content providing unit 120, a transmission / reception unit 130, a payment processing unit 140, an information management unit 150, and a storage unit 170. The components other than the communication unit 110 and the storage unit 170 are realized by, for example, a hardware processor such as a CPU executing a program (software). Some or all of these components may be realized by hardware (including circuitry) such as an LSI (Large Scale Integration), an ASIC (Application Specific Integrated Circuit), an FPGA (Field-Programmable Gate Array), or a GPU (Graphics Processing Unit), or may be realized by a combination of software and hardware. The program may be stored in advance in a storage device such as an HDD (Hard Disk Drive) or flash memory (a storage device with a non-transitory storage medium), or may be stored in a removable storage medium (a non-transitory storage medium) such as a DVD or CD-ROM, and installed in the storage device by inserting the storage medium into a drive device.
[0020] The storage unit 170 is a HDD, flash memory, RAM (Random Access Memory), etc. The storage unit 170 may be a NAS (Network Attached Storage) device that the payment server 100 can access via a network. The storage unit 170 stores information such as user information 172, payment content information 174, affiliated store / shop information 176, shared wallet master information 178, and shared wallet individual information 180.
[0021] The communication unit 110 is a communication interface for connecting to the network NW, and is, for example, a network interface card.
[0022] The payment content providing unit 120 has, for example, a function of a web server, and provides information (content) for displaying various screens of the electronic payment service to the user terminal device 10. The payment content providing unit 120 reads out necessary content from the payment content information 174 as appropriate and provides it to the user terminal device 10. The user terminal device 10 accepts various inputs from the user while content is being played by the payment application 20, and transmits the above-mentioned payment information and the like to the payment server 100.
[0023] The payment processing unit 140 performs payment processing based on the payment information transmitted by the user terminal device 10 or the first store terminal device 50. The payment processing unit 140 performs payment processing while referring to the user information 172.
[0024] FIG. 5 is a diagram showing an example of the contents of user information 172. User information 172 is an example of user registration information. User information 172 includes, for example, a user URL, account ID, telephone number, and password, as well as associated information such as email address, user ID, name, address, date of birth, registration date, charge balance, deferred payment settings, deferred payment limit, deferred payment usage amount, deferred payment available amount, payment method settings, bank account, credit card number, charge history information, and payment history information. The user URL is used for remittance processing between users. When registering for the electronic payment service, registration of a phone number and password is required. The account ID is issued to the user by the payment server 100, and the user ID can be set by the user (or does not have to be set). The email address, name, address, and date of birth are also information that can be set by the user (or do not have to be set). The registration date is the date on which the user registered for the electronic payment service (the date on which the account was created). Hereinafter, the user's instance (electronic payment account) to which this information is associated will be referred to as an account.
[0025] The charge balance indicates the balance of electronic money set by the user by transferring funds to the account in advance. Transfer methods include transfers from a designated service provider (bank) ATM (Automatic Teller Machine) or from a registered bank account. The deferred payment setting indicates whether the setting for deferred payment electronic payments has been completed and is set to either "completed" or "not completed." The deferred payment limit is the monthly deferred payment limit. The deferred payment usage amount is the amount of deferred payment already used in the current month. The available deferred payment amount is the amount of deferred payment available in the current month, calculated by subtracting the deferred payment usage amount from the deferred payment limit. While the figure shows only one deferred payment limit, in reality, there may also be daily upper limits, and the lower of these may be set as the deferred payment limit. Further details on deferred payment will be discussed later. The payment method setting indicates whether the user will make electronic payments using the charge balance or by deferred payment at that time. The bank account and credit card number are information on the bank account or credit card number (account number, card number) that can be used to deposit funds into the electronic payment service. The charge history information is a history of the user's previous transfers to the electronic payment service to increase the charge balance. The payment history information is information that shows the breakdown of payments made by the user for each payment (date and time, store ID of the store where the purchase was made, payment amount, payment method, etc.).
[0026] 6 is a diagram showing an example of the contents of affiliated store / store information 176. The affiliated store / store information 176 includes, for example, a first table 176A in which an affiliated store ID and a store ID are associated with a store URL, a second table 176B in which an affiliated store ID is associated with an affiliated store name, an affiliated store category, and sales amount (described above), and a third table 176C in which a store ID is associated with a store name. In addition to this information, the affiliated store / store information 176 may also include information such as the store's location and payment pattern.
[0027] The information management unit 150 manages user information 172, affiliated store / store information 176, shared wallet master information 178, and shared wallet individual information 180 based on information acquired from the user terminal device 10 and the second store terminal device 70. The information management unit 150 adds new records, edits, deletes, etc. for the user information 172, affiliated store / store information 176, shared wallet master information 178, and shared wallet individual information 180.
[0028] [Electronic Payment] When payment information is acquired from the user terminal device 10 or the first store terminal device 50, the payment processing unit 140 refers to the user information 172 to acquire the "payment method setting" of the user. For users whose "payment method setting" is set to "charge balance," the payment processing unit 140 performs electronic payment as follows. For example, the payment processing unit 140 performs electronic payment by decreasing the charge balance managed in association with the user ID and increasing the item value of the affiliated store's sales proceeds. The item value of the affiliated store's sales proceeds is not itself used as electronic money, for example, but rather the amount corresponding to the item value of the sales proceeds is transferred to a bank account in a cycle according to an agreement between the affiliated store and the electronic payment service.
[0029] The payment processing unit 140 performs electronic payments for users whose "setting information" is set to "deferred payment" as follows. Deferred payment is set separately from "credit card payment," which is set in cooperation with a credit card company, which is a separate entity from the operator of the electronic payment service. The operator of the electronic payment service acts as the creditor, and allows electronic payments within the deferred payment limit, independent of the remaining balance. To receive the deferred payment service, a user may be required to obtain a credit card provided by the operator of the electronic payment service. The amount used for deferred payment is settled in full on the following month's payment date, for example, by debit from a bank account. In this case, the payment processing unit 140 makes a provisional payment by adding the payment amount to the deferred payment amount and subtracting the same amount from the available deferred payment balance. On the closing date, the payment processing unit 140 performs the process described above to debit the current month's payment on the following month's payment date, or requests the credit card operator to perform this process. If the payment amount exceeds the available deferred payment balance at the time of provisional payment, an error notification is returned to the payment app 20.
[0030] [Top screen] FIG. 7 is a diagram showing an example of the top screen of the payment app 20. A code image CD is displayed on the top screen. The code image CD includes, for example, a barcode and a QR code. Along with the code image CD, text indicating whether electronic payment is to be made using the remaining balance or by deferred payment is also displayed (in the figure, "Balance Payment" is displayed, which means that electronic payment using the remaining balance is set). This text is drawn by the payment app 20 based on information (whether it is balance payment or deferred payment) that is updated by the payment app 20 each time the selector switch SW is operated. The top screen also includes an operation area CA including the selector switch SW and a transition button TB. Note that the "switch" and "button" refer to a graphical user interface (GUI) realized in cooperation with the touch panel. The selector switch SW accepts an operation to switch between electronic payment using the remaining balance and electronic payment by deferred payment. The selector switch SW is set to electronic payment using the remaining balance by default, and each time the user operates the selector switch SW, the setting switches between electronic payment using the remaining balance and electronic payment by deferred payment. The operation area CA has buttons for instructing the main operations in electronic payment, such as a button for instructing scanning (starting user scanning) and a button for instructing charging. When the transition button TB is operated, the screen transitions to a payment screen that displays the code image used for electronic payment and the available balance.
[0031] The operation area CA further displays, for example, a group of buttons (switches) MA for launching mini apps. A mini app is, for example, an app that uses the payment app 20 as a platform. A mini app is, for example, an application program developed by a service provider that provides a service via a service server (not shown) connected to the network NW to run within the payment app 20. The service server may be the payment server 100 itself, or an external server different from the payment server 100. The service provider develops the mini app by referring to an SDK (Software Development Kit), which is a program and technical documentation for app development provided by an administrator of the payment app 20. A mini app is, for example, an app that runs while the payment app 20 is running. For example, some or all of the mini apps may be installed when the payment app 20 is installed, or some or all of the mini apps may be installed from a service server corresponding to the mini app. FIG. 7 shows, as an example, a mini app that provides a shared wallet function, a mini app that provides an insurance-related service, and a mini app that provides a movie-related service. For example, when a user clicks a button indicating a mini-app that provides a shared wallet function, the mini-app accesses the payment server 100 or service server that provides the shared wallet function, allowing the user to use the shared wallet function. Also, for example, when a user clicks a button indicating a mini-app that provides insurance-related services, the mini-app accesses the payment server 100 or service server that provides insurance-related services, allowing the user to perform procedures such as signing up for insurance. Also, for example, when a user clicks a button indicating a mini-app that provides movie-related services, the mini-app accesses the payment server 100 or service server that provides movie-related services, allowing the user to reserve movie tickets, etc. Mini-apps are an example of an "ancillary service" in the claims.
[0032] Here, the shared wallet function refers to a function in which one or more users (hereinafter referred to as first users) who use an electronic payment service use a user terminal device 10 (hereinafter referred to as first user terminal device 10A) to grant a monetary limit that can be used for payments in the electronic payment service during a predetermined period to the account of a user terminal device 10 (hereinafter referred to as second user terminal device 10B) of another user (hereinafter referred to as second user) who uses the electronic payment service, and the second user can make electronic payments using the monetary limit granted by the first user during the predetermined period. The predetermined period is, for example, one month and is set arbitrarily by the first user. The shared wallet function provided by the payment server 100 will be described in detail below.
[0033] [Shared Wallet Function Overview] Figure 8 is a diagram for explaining an overview of the shared wallet function provided by the payment server 100. First, each first user uses the first user terminal device 10A to specify the account ID of the second user and set a monetary limit that the second user can use during a predetermined period. Figure 8 shows, as an example, a case in which four first users specify that the second user be given monetary limits of 5,000 yen, 3,000 yen, 2,000 yen, and 4,000 yen, respectively.
[0034] Next, the payment processing unit 140 provisionally deducts the amount limits granted by each first user from the respective charge balances stored in the user information 172, and aggregates the deducted amounts to grant the second user the set amount (total amount) for the shared wallet. In the case of Figure 8, the payment processing unit 140 aggregates 5,000 yen, 3,000 yen, 2,000 yen, and 4,000 yen to grant 14,000 yen as the set amount for the shared wallet of the second user.
[0035] Next, when the second user makes an electronic payment using the second user terminal device 10B during the specified period, the payment processing unit 140 deducts the payment amount from the set amount of the shared wallet, prioritizing the balance payment or deferred payment set for the second user. At this time, the second user may set on the second user terminal device 10B whether or not to make an electronic payment using the shared wallet (hereinafter referred to as a "shared wallet payment") in priority to the balance payment or deferred payment. For example, the second user may perform an electronic payment using his or her own charge balance or deferred payment balance by disabling the shared wallet payment. In the case of FIG. 8, for example, if the second user makes a shared wallet payment of 6,000 yen during the specified period, the payment processing unit 140 will deduct 6,000 yen from the 14,000 yen at the end of the specified period, leaving the balance of the shared wallet at 8,000 yen.
[0036] Next, the payment processing unit 140 deducts the amount calculated by dividing the payment amount paid to the shared wallet during the specified period by the number of first users from the limit allocated to each first user. For example, in the case of FIG. 8, the payment amount paid to the shared wallet (6,000 yen) is divided by the number of first users (four), resulting in 1,500 yen, which is deducted from the limit allocated to each first user. In other words, in this case, 1,500 yen is deducted from the 5,000 yen, 3,000 yen, 2,000 yen, and 4,000 yen balances, resulting in balances of 3,500 yen, 1,500 yen, 500 yen, and 2,500 yen. Note that for ease of explanation, FIG. 8 illustrates deducting 1,500 yen, calculated by dividing the total payment amount during the specified period (6,000 yen) by the number of first users. However, in reality, each time the second user makes a shared wallet payment during a specified period, the payment amount is divided by the number of first users, and the resulting amount is deducted from the amount limit granted by the first user.
[0037] Next, after a predetermined period of time, the payment processing unit 140 returns the remaining balance, obtained by subtracting the withdrawal amount from the credit limit granted by each first user, to each first user terminal device 10A. More specifically, the payment processing unit 140 adds the remaining balance to the charge balance of the user information 172 associated with each first user. For example, in the case of FIG. 8, the payment processing unit 140 adds the remaining amounts of 3,500 yen, 1,500 yen, 500 yen, and 2,500 yen to the charge balance of the user information 172 associated with each first user terminal device 10A. At this time, the payment processing unit 140 may deduct a predetermined amount as a fee from the remaining balance to be returned to the first user before returning it to the first user. This completes the shared wallet payment process. In this way, shared wallet payments do not irreversibly grant the entire amount limit granted by multiple first users to the second user; rather, the second user uses the amount limit granted by multiple first users only within the scope of his or her own payment amount, and the burden is distributed among the multiple first users, with the remaining amount being returned to the multiple first users.
[0038] Note that, as the second user executes a shared wallet payment during a predetermined period, the limit on one of the first user terminal devices 10A may become zero. For example, if the balances of the first user terminal devices 10A reach 3,500 yen, 1,500 yen, 500 yen, and 2,500 yen, and the second user executes a shared wallet payment of 2,900 yen, the total amount owed by each first user will be 725 yen, but the balance of the third first user will be zero. In this case, the payment processing unit 140 subtracts the remaining amount (225 yen / 3 = 75 yen) from the balances of the remaining three first users, respectively. As a result, the balances of the first user terminal devices 10A will ultimately be 2,700 yen, 700 yen, 0 yen, and 1,700 yen.
[0039] Furthermore, in the above description, an example was described in which the payment amount of the shared wallet payment divided by the number of first users is deducted from the amount limit granted by each first user. However, the present invention is not limited to such a configuration, and the payment processing unit 140 may deduct from each amount limit the payment amount of the shared wallet payment prorated by the amount limit granted by the first user. For example, in the case of Figure 8, if the second user makes a shared wallet payment of 1,400 yen out of the amount limits of 5,000 yen, 3,000 yen, 2,000 yen, and 4,000 yen, the payment processing unit 140 may subtract 500 yen, 300 yen, 200 yen, and 400 yen from the above amount limits, respectively.
[0040] FIG. 9 is a diagram showing an example of the contents of the shared wallet master information 178. The shared wallet master information 178 associates information such as a shared wallet ID, a shared account ID, a source account ID, a set amount (total amount), a usage amount, and a remaining amount. The shared wallet ID is identification information for identifying the set shared wallet. The destination account ID is the account ID of the second user to whom the shared wallet is set. The source account ID is the account ID of the first user who set the shared wallet. The set amount (total amount) indicates the total amount of the limit granted by the first user indicated by the source account ID. The usage amount indicates the amount used by the second user using the shared wallet during the validity period of the shared wallet. The remaining amount is the amount obtained by subtracting the usage amount from the set amount (total amount). As will be described later, the second user sets the validity period and amount limit via the second user terminal device 10B, and the payment processing unit 140 calculates the set amount by aggregating the set amount limits.
[0041] FIG. 10 is a diagram showing an example of the contents of individual shared wallet information 180. Individual shared wallet information 180 is set, for example, for each second user for whom a shared wallet is set (i.e., for each shared account ID), and represents detailed information about the shared wallet set for the second user. Individual shared wallet information 180 associates, for example, information such as the sharing source account ID, set amount (individual), remaining amount, target category, target affiliated store, target service, duration, validity period, and automatic renewal. The set amount (individual) indicates the monetary limit granted by the first user of each sharing source account ID to the second user of the shared destination account ID. The remaining amount indicates the set amount (individual) minus the amount divided by each first user from the second user's usage amount.
[0042] The target category indicates the category of affiliated stores that the first user permits the second user to use for shared wallet payments. For example, for sharing source account ID "001" in Fig. 10, if the second user makes an electronic payment at an affiliated store in the "cafe" or "restaurant" category, the payment processing unit 140 subtracts the payment amount from the set amount (individual) for sharing source account ID "001," whereas if the second user makes an electronic payment at an affiliated store other than the "cafe" or "restaurant" category, the payment processing unit 140 does not subtract the payment amount from the set amount (individual) for sharing source account ID "001," but subtracts the payment amount from the set amount (individual) for other sharing source account IDs.
[0043] The target affiliated store indicates an affiliated store that the first user permits the second user to use the shared wallet payment. For example, for the sharing source account ID "003" in Fig. 10, if the second user makes a shared wallet payment at a member store having a member store ID of "35472" or "46383", the payment processing unit 140 will subtract the payment amount from the set amount (individual) for the sharing source account ID "003", whereas if the second user makes an electronic payment at a store of a member store having a member store ID other than "35472" or "46383", the payment processing unit 140 will not subtract the payment amount from the set amount (individual) for the sharing source account ID "005", but will subtract the payment amount from the set amount (individual) for the other sharing source account IDs.
[0044] The target service refers to a mini-app service for which the first user permits the second user to use shared wallet payment. For example, for sharing source account ID "005" in Fig. 10, if the second user uses a mini-app that provides the "insurance" or "movie" service, the payment processing unit 140 subtracts the payment amount from the set amount (individual) for sharing source account ID "005," whereas if the second user uses a mini-app that provides the "insurance" or "movie" service, the payment processing unit 140 does not subtract the payment amount from the set amount (individual) for sharing source account ID "005," but subtracts the payment amount from the set amount (individual) for the other sharing source account IDs.
[0045] Regarding the conditions regarding the "target category," "target affiliated store," and "target service," if the second user makes a shared wallet payment that satisfies at least one of these conditions, the payment amount may be subtracted from the set amount (individual) of the corresponding first user. For example, for the sharing source account ID "007" in FIG. 10, if the second user makes a shared wallet payment at an affiliated store in the target category "cafe" or "food and drink," or makes a shared wallet payment for a mini-app that provides the target service "movies," the payment processing unit 140 will subtract the payment amount from the set amount (individual) of the sharing source account ID "007." However, if the shared wallet payment by the second user does not satisfy any of these conditions, the payment processing unit 140 may not subtract the payment amount from the set amount (individual) of the sharing source account ID "007," but may subtract the payment amount from the set amount (individual) of another sharing source account ID.
[0046] The validity period indicates a predetermined period during which the first user permits the second user to use the shared wallet payment. When the validity period expires, the information management unit 150 deletes the source account ID and returns the remaining balance to the first user. Furthermore, when the validity period expires, the information management unit 150 deletes the supplier account ID from the shared wallet master information 178 and subtracts the first user's set amount (individual) and burden amount from the set amount (total amount) and usage amount, respectively. Note that the outline of the shared wallet payment shown in FIG. 8 represents the refund process when all first users set the same validity period (e.g., one month) on the same day. To reduce the processing load on the payment server 100, first users may standardize shared wallet setup and settlement on a monthly basis starting from the beginning of the month.
[0047] Automatic renewal is information indicating whether the validity period of the shared wallet will be automatically extended when it expires. Whether or not to enable automatic renewal can be set by the first user on the first user terminal device 10A when the shared wallet is first set up and during the usage period. The duration indicates the length of time that the first user has continuously provided the shared wallet to the second user. As will be described later, a benefit may be granted to the first user who provided the shared wallet depending on the length of the duration.
[0048] Thus, according to this embodiment, when multiple first users use the shared wallet payment function to provide remittance support to a second user, the second user receives support within the amount of the electronic payment made by the first user. This prevents the second user from receiving excessive amounts of remittances from multiple recipients. Furthermore, according to this embodiment, each first user can set items such as target categories, target affiliated stores, and target services as shared wallet payment settings. This allows the second user to use the remitted money as intended by the first user who made the remittance, unlike cash remittances or support through remittances using conventional electronic payment services. In other words, this embodiment enables appropriate remittances between users.
[0049] [New shared wallet settings] The shared wallet payment function will be described in detail below. FIG. 11 is a diagram showing an example of shared wallet provision settings executed on the first user terminal device 10A. The screen shown on the left side of FIG. 11 is displayed, for example, when the mini-app button MA indicating the shared wallet is pressed on the top screen of the payment app 20 shown in FIG. 7 to transition to the shared wallet provision settings screen. As shown on the left side of FIG. 11, the first user terminal device 10A displays, for example, an area A1 for inputting the account ID of the second user to whom the shared wallet will be provided, an area A2 for inputting the set amount of the shared wallet to be provided to the second user, areas A3 to A5 for specifying the payment target for the shared wallet payment (corresponding to the target category, target affiliated store, and target service shown in FIG. 10, respectively), an area A6 for setting the validity period of the shared wallet payment, and a check box C1 for selecting whether to enable automatic renewal. Of these items, the setting of the payment target may be optional. If the first user does not set the payment target, the second user to whom the shared wallet is provided can use the shared wallet payment for all affiliated stores and mini-apps.
[0050] When the first user enters information in the areas corresponding to areas A1 to A6 and in checkbox C1 and presses the Provide button B1, first user terminal device 10A transmits the entered setting information to payment server 100. Upon receiving the setting information, transmitter / receiver 130 transmits information to second user terminal device 10B, which is identified by the account ID included in the setting information, inquiring whether or not to accept the shared wallet provided by the first user, and second user terminal device 10B displays the received inquiry information.
[0051] At this time, as shown in area A7 of Fig. 11, second user terminal device 10B may display the setting information entered by the first user to be used as a reference for the second user's decision. When the second user confirms the displayed content and presses receive button B2, second user terminal device 10B transmits information indicating that the second user has agreed to receive the shared wallet to payment server 100. When transmitter / receiver 130 receives the agreement information, information manager 150 stores the setting information entered by the first user in shared wallet master information 178 and shared wallet individual information 180. This enables shared wallet payment by the second user.
[0052] Fig. 12 is a diagram showing an example of a shared wallet request setting executed on second user terminal device 10B. The screen shown on the left side of Fig. 12 is displayed, for example, when a mini-app button MA indicating a shared wallet is pressed on the top screen of payment application 20 shown in Fig. 7 to transition to a shared wallet request setting screen. As shown on the left side of Fig. 12, first user terminal device 10A displays, for example, an area A8 for inputting the account ID of the first user who will provide the shared wallet, an area A9 for inputting the set amount of the shared wallet to be requested from the first user, areas A10 to A13 for specifying the payment target for the shared wallet payment (corresponding to the target category, target affiliated store, and target service shown in Fig. 10, respectively), an area A13 for setting the validity period of the shared wallet payment, and a checkbox C2 for selecting whether to enable automatic renewal.
[0053] When the second user enters information in the areas corresponding to areas A8 to A13 and in check box C2 and presses request button B3, second user terminal device 10B transmits the input request information to payment server 100. Upon receiving the request information, transmitter / receiver 130 transmits information to first user terminal device 10A identified by the account ID included in the request information, inquiring whether or not to provide the shared wallet requested by the second user, and first user terminal device 10A displays the received inquiry information.
[0054] At this time, as shown in area A14 of FIG. 12, the first user terminal device 10A may display the request information entered by the second user to be used as a reference for the first user's decision. When the first user confirms the displayed content and presses the Provide button B4, the first user terminal device 10A transmits information indicating that the first user has agreed to the provision of the shared wallet to the payment server 100. When the transmission / reception unit 130 receives the consent information, the information management unit 150 stores the request information entered by the second user in the shared wallet master information 178 and the shared wallet individual information 180. This validates the shared wallet payment by the second user. Note that, unlike the receiving process shown in FIG. 11, the first user may edit the received request information on the first user terminal device 10A before pressing the Provide button B4.
[0055] [Shared wallet payment screen] FIG. 13 is a diagram showing an example of a payment screen displayed by the second user terminal device 10B in which shared wallet payment is enabled. The screen shown in FIG. 13 is displayed, for example, when the second user terminal device 10B reads a code image displayed at a store using the user scan shown in FIG. 3. In FIG. 13, reference numeral A15 denotes an area for inputting the payment amount, and reference numeral A16 denotes an area for inputting the payment method. The second user terminal device 10B in which shared wallet payment is enabled displays, for example, balance payment, deferred payment, and shared wallet payment as payment method options. As shown in FIG. 13, for example, when the second user selects deferred payment and shared wallet payment as payment methods and presses the payment button B5 to make an electronic payment, the payment processing unit 140 prioritizes deferred payment and subtracts the payment amount from the balance of the shared wallet. Here, if the balance of the shared wallet is less than the payment amount, the payment processing unit 140 may use another specified payment method to pay the difference between the payment amount and the balance. For example, in the case of FIG. 13, the balance of the shared wallet of 1,500 yen is less than the payment amount of 2,000 yen, so the payment processing unit 140 may process the difference of 500 yen obtained by subtracting 1,500 yen from 2,000 yen as a deferred payment.
[0056] In another embodiment, the payment server 100 may allow the second user terminal device 10B to select only one payment method from among the candidate payment methods. In this case, if shared wallet payment is selected in the situation shown in Figure 13, the payment processing unit 140 will not be able to debit the payment amount of 2,000 yen from the balance of 1,500 yen in the shared wallet, and the electronic payment will result in an error.
[0057] [View shared wallet history] FIG. 14 is a diagram showing an example of a payment history viewing screen displayed by the first user terminal device 10A. As shown in the left portion of FIG. 14, the first user terminal device 10A of the first user who provides the shared wallet displays, for example, a button B6 for viewing the user's own payment history and a button B7 for viewing the history of shared wallet payments made by the second user who provided the shared wallet. When the first user presses button B7, the first user terminal device 10A transmits to the payment server 100 a request to acquire the usage history of shared wallet payments made by the second user. Upon receiving the acquisition request, the transceiver 130 transmits history information of the shared wallet payments to the first user terminal device 10A and displays it on the first user terminal device 10A. More specifically, for example, the first user terminal device 10A displays an area A17 showing the set amount and remaining balance set by the first user and an area A18 showing detailed information of shared wallet payments made by the second user.
[0058] At this time, the transceiver 130 limits the disclosure scope of the shared wallet payment usage history and transmits the usage history to the first user terminal device 10A. More specifically, as shown in area A18, the transceiver 130 displays, for example, only category information of the affiliated store where the shared wallet payment was made and the amount paid by the user at that device. This is because if detailed and real-time information about the shared wallet payment history were disclosed to the first user terminal device 10A, there would be concerns that the privacy of the second user would be violated. Therefore, as described below, the disclosure scope of the shared wallet payment history information may be set by the second user.
[0059] FIG. 15 is a diagram showing an example of a screen displayed by second user terminal device 10B for setting the disclosure scope of the shared wallet payment usage history. As shown in FIG. 15, second user terminal device 10B displays, for example, an area A19 for specifying the account ID of the first user whose shared wallet payment usage history is to be disclosed, an area A20 for setting the disclosure scope, and a button B8 for validating the set disclosure scope. Here, the disclosure scope includes, for example, items such as the payment amount, payment store, payment store (or affiliated store), affiliated store category, payment time, and whether or not real-time notification is enabled. Here, real-time notification means that, when the second user executes the shared wallet payment, information indicating that the shared wallet payment has been executed is notified to first user terminal device 10A in real time. In this way, by providing an interface for setting the disclosure scope of the shared wallet payment usage history, the second user can appropriately set the disclosure scope depending on the relationship with the first user who provides the shared wallet.
[0060] [Shared Wallet Benefits] Furthermore, the payment server 100 or the second user terminal device 10B may provide some kind of benefit to the first user terminal device 10A of the first user who provides the shared wallet. FIG. 16 is a diagram showing an example of a benefit provided to the first user terminal device 10A. When a second user who has received a shared wallet from the first user performs a shared wallet payment during the validity period of the shared wallet, the transceiver 130 may provide a benefit to the first user terminal device 10A of the first user. For example, as shown in FIG. 16, the transceiver 130 may send a message preset by the second user to the first user terminal device 10A, and the first user terminal device 10A may display the received message in the message area A21. In this case, the transceiver 130 may send the message every time the second user performs a shared wallet payment or when the first user's balance becomes zero. The message is an example of "text information" in the claims.
[0061] FIG. 17 illustrates another example of a reward provided to the first user terminal device 10A. The transceiver 130 may provide a reward to the first user terminal device 10A of the first user by referencing the shared wallet individual information 180 if the first user has continuously provided the shared wallet to the second user for a specific period of time or longer. For example, as shown in FIG. 17, the transceiver 130 may transmit a reward image previously selected by the second user to the first user terminal device 10A. The first user terminal device 10A may then display a message area A22 indicating that the reward image has been received and a download button B9 for downloading the reward image. The reward image is an example of "image information" in the claims. These configurations provide a sense of fulfillment to the first user who remits money to the second user, unlike traditional remittances via bank transfers or electronic payment services.
[0062] The conditions for providing the above-described benefits and the benefits themselves are not limited to the examples shown in FIGS. 16 and 17 , and any combination may be implemented. For example, the transceiver 130 may provide a benefit image to the first user terminal device 10A of a first user when a second user who has received a shared wallet from a first user performs a shared wallet payment during the validity period of the shared wallet. Alternatively, the transceiver 130 may send a message to the first user terminal device 10A of the first user when the first user has provided the shared wallet to a second user for a specific period or longer. As another example of a benefit, the payment server 100 may enable a chat function between the first user terminal device 10A of the first user who provided the shared wallet and the second user terminal device 10B of the second user who provided the shared wallet. As another example of a benefit, the payment server 100 may rank the set amount and duration of the shared wallet among multiple first users who provide shared wallets to a specific second user, and display the results on the first user terminal device 10A of each first user. This can give a first user who sends money to a second user a greater sense of fulfillment.
[0063] According to the present embodiment described above, a designation is accepted from the first user terminal devices of multiple first users who use the electronic payment service to grant a credit limit that can be used for payments using the electronic payment service during a specified period to the electronic payment service account of a single second user who also uses the electronic payment service, and based on the accepted designation, a credit limit corresponding to the multiple first users is set in association with the second user's electronic payment service account, and when the credit limit is set in association with the second user's electronic payment service account and the second user uses the electronic payment service during the specified period, the payment amount for the electronic payment service is deducted from the credit limit, thereby enabling appropriate remittances between users.
[0064] [Variations] In the above embodiment, for example, as described with reference to FIG. 11, when providing a shared wallet to a second user, the first user inputs the account ID of the second user. However, the account ID of an electronic payment service is a type of private information used for logging in to the electronic payment service and using various functions. Therefore, when the first user and the second user have a weak direct relationship or when the second user receives shared wallets from multiple first users, it may not be desirable for the second user to notify the first user of the account ID.
[0065] In light of the above circumstances, in this modified example, a first user is configured to input identification information different from the account ID of the second user when providing a shared wallet to a second user. FIG. 18 is a diagram showing an example of shared wallet provision settings according to the modified example. First, the information management unit 150 generates a shared wallet ID in response to a request from a second user terminal device 10B that wishes to generate a shared wallet, and notifies the second user terminal device 10B of the generated shared wallet ID. The shared wallet ID is an example of "second identification information" in the claims.
[0066] Next, as shown in the left part of FIG. 18, the second user confirms the shared wallet ID on the second user terminal device 10B and notifies a specific or unspecified person of his / her shared wallet ID via a messaging app or SNS (social networking services). FIG. 18 illustrates an example in which the second user notifies the first user of the shared wallet ID via a messaging app. This prevents the second user's electronic payment service account from being misused, even if the contents of the messaging app are leaked to the outside. The person who confirmed the shared wallet ID sets up the provision of the shared wallet by entering the confirmed shared wallet ID in the field A23 for entering the shared wallet ID, displayed on the first user terminal device 10A, as shown in the right part of FIG. 18. The other input items are the same as those in FIG. 11, and therefore their description is omitted. Note that, to promote the provision of the shared wallet by the first user, the payment server 100 may provide a link card function, etc., in the messaging app or SNS to smoothly guide the first user to the provision of the shared wallet setup screen.
[0067] According to this modified example described above, by configuring the provision of a shared wallet using identification information different from the second user's account ID, it is possible to realize appropriate transfers between users while protecting the privacy of the second user.
[0068] In the above embodiments and variants, operations mainly performed by the first user terminal device 10A or the second user terminal device 10B may be interpreted as being executed by the payment application 20 installed therein, or as being executed in response to instructions from the payment server 100.
[0069] The above describes the form for carrying out the present invention using an embodiment, but the present invention is not limited to such an embodiment, and various modifications and substitutions can be made within the scope that does not deviate from the gist of the present invention. [Explanation of symbols]
[0070] 10 User terminal device 20. Payment App 100 Payment Server 110 Communications Department 120 Payment Contents Department 130 Transmitter / Receiver 140 Payment processing unit 150 Information Management Department
Claims
1. a transceiver unit that receives, from first user terminal devices of a plurality of first users who use an electronic payment service, a designation to grant an amount limit that can be used for payments in the electronic payment service during a predetermined period to an electronic payment service account of a single second user who uses the electronic payment service; a payment processing unit that sets a price limit corresponding to the plurality of first users in association with an electronic payment service account of the second user based on the received designation, the payment processing unit deducts a payment amount of the electronic payment service from the amount limit when the amount limit is set in association with the electronic payment service account of the second user and the second user uses the electronic payment service during the specified period; Information processing device.
2. The transmitting / receiving unit further receives designation regarding a payment target of the electronic payment service for which the amount limit can be used from some or all of the first user terminal devices of the plurality of first users; the payment processing unit, when the second user executes an electronic payment related to a payment target of the electronic payment service, deducts a payment amount of the electronic payment service from the amount limit; The information processing device according to claim 1 .
3. The payment target is an affiliated store affiliated with the electronic payment service, a category of the affiliated store, or an ancillary service provided via the electronic payment service. The information processing device according to claim 2 .
4. the payment processing unit debits an amount obtained by dividing a payment amount of the electronic payment service by the number of the first users from a monetary limit corresponding to each of the first users; The information processing device according to claim 1 .
5. the payment processing unit deducts, from the amount limits corresponding to the first users, the amount of the payment for the electronic payment service pro rata based on the amount limits corresponding to the first users, respectively; The information processing device according to claim 1 .
6. The information management unit further includes an information management unit that enables the setting of the amount limit in two ways: a proposal to provide the amount limit transmitted from the first user terminal device to the second user terminal device of the second user, and a request to provide the amount limit transmitted from the second user terminal device to the first user terminal device. The information processing device according to claim 1 .
7. the information management unit causes the first user terminal device to transmit the provision offer via second identification information different from identification information for identifying the second user in the electronic payment service; The information processing device according to claim 6.
8. the payment processing unit provisionally debits the amount limit corresponding to the plurality of first users from the electronic payment service accounts of the plurality of first users at the start of the specified period, and returns the surplus amount obtained by subtracting the debit amount from the amount limit corresponding to the plurality of first users to the electronic payment service accounts of the plurality of first users at the end of the specified period; The information processing device according to claim 1 .
9. A storage unit that stores a usage history of the second user using the amount limit, When the transmission / reception unit receives a request to acquire the usage history from the first user terminal device, the transmission / reception unit transmits the usage history to the first user terminal device. The information processing device according to claim 1 .
10. When the transmission / reception unit receives a request to obtain the usage history from the first user terminal device, the transmission / reception unit limits a disclosure range of the usage history and transmits the usage history to the first user terminal device. The information processing device according to claim 9.
11. The transmitting / receiving unit grants a privilege to the first user terminal device when the first user to whom the amount limit has been granted satisfies a predetermined criterion. The information processing device according to claim 1 .
12. The transmitting / receiving unit grants a privilege to the first user terminal device when the second user uses the amount limit during the specified period as the specified criterion. The information processing device according to claim 11.
13. The transmitting / receiving unit grants a privilege to the first user terminal device when a continuous period during which the first user has granted the amount limit to the second user is equal to or longer than a specific period as the predetermined criterion. The information processing device according to claim 11.
14. The benefit is character information or image information set in advance by the second user. The information processing device according to claim 11 .
15. The computer receiving, from first user terminal devices of a plurality of first users who use an electronic payment service, a designation to grant an amount limit available for payments in the electronic payment service during a predetermined period to an electronic payment service account of a single second user who uses the electronic payment service; Based on the received designation, set a monetary limit corresponding to the plurality of first users in association with an electronic payment service account of the second user; the amount limit is set in association with the electronic payment service account of the second user, and when the second user uses the electronic payment service during the specified period, the payment amount of the electronic payment service is debited from the amount limit; Information processing methods.
16. On the computer, accepting, from first user terminal devices of a plurality of first users who use an electronic payment service, a designation to grant an amount limit available for payments in the electronic payment service during a predetermined period to an electronic payment service account of a single second user who uses the electronic payment service; Based on the received designation, a monetary limit corresponding to the plurality of first users is set in association with an electronic payment service account of the second user; the amount limit is set in association with an electronic payment service account of the second user, and when the second user uses the electronic payment service during the specified period, the payment amount of the electronic payment service is debited from the amount limit; program.
17. An application program that cooperates with a first user terminal device of a plurality of first users who use an electronic payment service, and is installed in a second user terminal device of a second user who uses the electronic payment service, receiving, from a first user terminal device of the plurality of first users, a designation to grant an amount limit available for payments in the electronic payment service during a predetermined period to an electronic payment service account of the second user; Based on the received designation, set a monetary limit corresponding to the plurality of first users in association with an electronic payment service account of the second user; the amount limit is set in association with the electronic payment service account of the second user, and when the second user uses the electronic payment service during the specified period, the payment amount of the electronic payment service is debited from the amount limit; Application program.
Citation Information
Patent Citations
Information-processing server, information-processing method, information-processing program, and recording medium on which information-processing program has been recorded
JP2013182489A
Payment propriety determination system, portable terminal, device, and program thereof
JP2016218861A
Transaction device, method, and program
JP2020201573A
Authentication processing device, settlement terminal, setting program, settlement system, and settlement method
JP2021026317A
Value transfer system
JP2021043656A