Information processing device, information processing method, and program
The information processing device and method improve user confidence in peer-to-peer electronic payment services by ensuring accurate identification through real-name verification and notification for users who do not meet predetermined conditions, addressing privacy concerns in electronic payment services.
Patent Information
- Application Number
- JP2025011617
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- Filing Date
- 2025-01-27
- Publication Date
- 2026-01-27
- Estimated Expiration
- 2045-01-27
AI Technical Summary
Users in electronic payment services have low confidence in using peer-to-peer communication due to privacy concerns, as identification information such as names is not necessarily made public, leading to difficulties in identifying remittance recipients.
An information processing device and method that includes a determination unit to check if the displayed identification information meets predetermined conditions and a notification unit to prompt users to change their display name to a real name or authenticate their identity if the conditions are not met, thereby improving user confidence in peer-to-peer transactions.
Enhances user trust in peer-to-peer communication by ensuring that display names are accurate and reliable, facilitating secure and confident transactions.
Smart Images

Figure 0007807579000001_ABST
Abstract
Description
[Technical Field]
[0001] The present invention relates to an information processing device, an information processing method, and a program. [Background technology]
[0002] Conventionally, in the field of electronic payment services, there are known technologies that enable communication and remittance between users using peer-to-peer communication. For example, Patent Document 1 describes a technology that, when multiple users are paying a bill, allows a user to select a remittance after knowing the amount to be paid to other users. [Prior art documents] [Patent documents]
[0003] [Patent Document 1] Patent No. 7598508 Summary of the Invention [Problem to be solved by the invention]
[0004] The technology described in Patent Document 1 assumes that when a user selects a remittance, multiple users have already identified each other by referring to identification information such as names. However, in real-world electronic payment services, identification information such as names is not necessarily made public from the perspective of privacy protection. As a result, users sometimes have low confidence in using peer-to-peer communication on electronic payment services.
[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, and a program that can improve users' confidence in using peer-to-peer communication on electronic payment services. [Means for solving the problem]
[0006] One aspect of the present invention is an information processing device that includes a determination unit that determines, for each user of an electronic payment service, whether the user's identification information displayed by the user in peer-to-peer communication with other users satisfies predetermined conditions, and a notification unit that outputs notification information regarding a change in the identification information to the user's terminal device if it is determined that the identification information does not satisfy the predetermined conditions. [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, and a program that can improve users' confidence in using peer-to-peer communication on an electronic payment service. [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. 10 is a diagram illustrating the flow of a remittance function using peer-to-peer communication. [Figure 9] FIG. 10 is another diagram for explaining the flow of a remittance function using peer-to-peer communication. [Figure 10] FIG. 10 is a diagram showing an example of a receipt screen displayed on the payment application 20 of the remittance recipient user. [Figure 11]10 is a diagram showing an example of notification information notified by a notification unit 154. FIG. [Figure 12] 10 is a diagram showing another example of notification information notified by the notification unit 154. FIG. [Figure 13] 10 is a diagram showing yet another example of notification information notified by the notification unit 154. FIG. [Figure 14] 10 is a diagram showing an example of alert information notified by a notification unit 154. FIG. [Figure 15] 10 is a sequence diagram showing an example of the flow of processing executed by the payment application 20 and the payment server 100 in cooperation with each other. FIG. [Figure 16] 10 is a flowchart showing an example of the flow of processing executed by the payment server 100. DETAILED DESCRIPTION OF THE INVENTION
[0009] Hereinafter, with reference to the drawings, embodiments of an information processing device, an information processing method, and a program according to the present invention will be described. Various devices, such as a "server," a "management device," and an "information processing device," that provide services to users and perform internal analysis, may be implemented as a group of distributed devices, and each device may be operated by a different business. Furthermore, the hardware owner (the cloud server provider) and the business that actually operates the device may also be different. An application program and a payment server work together to provide an electronic payment service. In the following description, the application program is referred to as a "payment app." An 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-world store) that exists in real space, but may also include a virtual store for e-commerce transactions. A virtual store may also include a store operated by an entity other than the operator of the electronic payment service. In such a case, a transition to an interface screen for the electronic payment service may be performed when making a payment for a purchase at the virtual store. 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 the store is primarily conducted between the user and the affiliated store. Alternatively, processing such as payment may be carried out between the user and the store.
[0010] [Electronic payment service] Figure 1 shows an example of a configuration for realizing an electronic payment service. The electronic payment service is realized mainly by a payment server 100. The payment server 100 communicates with, for example, one or more user terminal devices 10, 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 LAN (Local Area Network), a wireless base station, a provider device, etc.
[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 payment processing unit 130, an information management unit 140, an information processing 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 (a storage device having a non-transitory storage medium) such as an HDD (Hard Disk Drive) or flash memory, 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. Information processing unit 150 further includes a determination unit 152, a notification unit 154, and a change unit 156, and details of these functional units will be described later. Information processing unit 150 is an example of an "information processing device" in the claims.
[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, and affiliated store / shop information 176.
[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 130 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 130 performs payment processing while referring to the user information 172.
[0024] FIG. 5 is a diagram showing an example of the contents of the user information 172. The user information 172 is an example of user registration information. The user information 172 includes, for example, a user URL, an account ID, a telephone number, a password, as well as information associated with the user, such as an email address, a user ID, a name, an address, a date of birth, a display name, a registration date, a charge balance, a credit card payment setting, a credit card limit, a credit card payment amount used, a credit card payment available amount, a payment method setting, a bank account, a 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 telephone number and a password is required. The account ID is issued to the user by the payment server 100, and the user ID is an ID that 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 display name is information indicating the name displayed between users in peer-to-peer communication between users, which will be described later. The display name is also information that can be set by the user. In this embodiment, if a user does not set a display name, the user's telephone number is set as the default. The registration date is the date the user registered with the electronic payment service (the date the account was created). Personal authentication is information indicating whether the user has completed personal authentication (eKYC) on the electronic payment service using an official ID card, driver's license, etc. In other words, if the user has completed personal authentication, the accuracy of the name, address, and date of birth stored in the user information 172 is guaranteed. Hereinafter, the user instance (electronic payment account) to which this information is associated is referred to as an account. The display name is an example of "identification information" in the claims.
[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 bank's ATM (Automatic Teller Machine) or from a registered bank account. The credit payment setting indicates whether the settings for electronic credit payment have been completed and is set to either "Completed" or "Not Completed." The credit payment limit is the monthly credit payment limit. The credit payment amount is the amount of credit payment already used in the current month. The available credit payment amount is the amount of credit payment available in the current month, calculated by subtracting the credit payment amount from the credit payment limit. While the figure shows only one credit payment limit, in reality, there may also be daily limits, and the lower of these may be set as the credit payment limit. Further details on credit payments will be discussed later. The payment method setting indicates whether the user will currently make electronic payments using the charge balance or by credit payment. 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 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 category of the affiliated store or store, the store's location, and payment patterns.
[0027] The information management unit 140 manages the user information 172 and the affiliated store / store information 176 based on information acquired from the user terminal device 10 and the second store terminal device 70. The information management unit 140 adds new records to, edits, deletes, etc. the user information 172 and the affiliated store / store information 176.
[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 130 references 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 130 performs electronic payment as follows: For example, the payment processing unit 130 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 130 performs electronic payments for users whose "setting information" is set to "credit card payment" as follows. Credit card payment is a payment method 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, allowing electronic payments within the credit card payment limit and independent of the remaining balance. To receive the credit card payment service, a user may be required to obtain a credit card provided by the operator of the electronic payment service. The monthly amount used for credit card payment is settled on the following month's payment date, for example, by debit from a bank account. In this case, the payment processing unit 130 makes a provisional settlement by adding the settlement amount to the credit card payment amount and subtracting the same amount from the available credit card balance. On the closing date, the payment processing unit 130 performs the process described above to debit the current month's payment on the following month's payment date, or requests the credit card company operator to perform this process. If the settlement amount exceeds the available credit card balance at the time of provisional settlement, 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 application 20. A code image CI is displayed on the top screen. The code image CI includes, for example, a barcode and a QR code. A selector switch SW is displayed next to the code image CI, allowing the user to select whether to make an electronic payment using the remaining balance or a credit card payment. The "switch" and "button" refer to a graphical user interface (GUI) implemented in cooperation with a touch panel. In FIG. 7, "credit" is displayed, indicating that the electronic payment is set to be made using a credit card. For example, a user can swipe the selector switch SW to select whether to make an electronic payment using the remaining balance or a credit card payment. The top screen also includes an operation area OA, a transition button TB1, and a transition button TB2. The operation area OA includes buttons for instructing key operations in electronic payment, such as a button for instructing scanning (starting a user scan), a button for transferring the remaining balance to another user, a button for displaying the points earned by the user, and a button for displaying the history of electronic payments made by the user. When transition button TB1 is pressed, the screen transitions to a payment screen that displays the code image used for electronic payment and the available balance. When transition button TB2 is pressed, the screen transitions to a screen that displays the available balance for balance payment or credit payment. In Figure 7, electronic payment using the charge balance is set, so when transition button TB2 is pressed, the available balance for balance payment is displayed.
[0031] Below the operation area OA, a group of buttons (switches) M1, M2, ... for launching mini apps are further displayed. A mini app is an app that operates using the payment app 20 as a platform and provides some kind of service. A service provider develops a mini app by referring to a Software Development Kit (SDK), which is an app development program and technical documentation provided by the administrator of the payment app 20. A mini app is an app that operates while the payment app 20 is running. For example, a part or all of the mini app may be installed when the payment app 20 is installed, or a part or all of the mini app may be installed from a service server corresponding to the mini app. For example, when a mini app is launched, it accesses a service server (not shown) that provides a service corresponding to the mini app, and the mini app and the service server work together to provide the service to the user. In this case, the service server may be the payment server 100 itself or an external server different from the payment server 100. 7 shows, as an example, a mini-app button M1 that provides a function for viewing information about coupons offered by affiliated stores, and a mini-app button M2 that provides a function for viewing information about stamp cards, but buttons for launching various types of mini-apps, such as an investment app for managing a charge balance or a payment app for paying public transportation fares, may also be displayed.Furthermore, the functions using peer-to-peer communication described below may be implemented as mini-apps.
[0032] [Remittance function] FIG. 8 is a diagram illustrating the flow of a remittance function using peer-to-peer communication. The screen shown on the left side of FIG. 8 is the screen to which the user transitions when, for example, the user presses the "Send" button in the operation area OA of the top screen shown in FIG. 7. In FIG. 8, area A1 includes a button (history button) for selecting the display of remittance history and a button (friend button) for selecting the recipient user. Area A2 represents the screen that is displayed in response to the button selected by the user in area A1. Area A2 in FIG. 8 represents, as an example, the content that is displayed when the user selects the "friend button" in area A1.
[0033] As shown in Figure 8, when a user selects the "Friends button" in area A1, the payment application 20 displays a list of users who are potential recipients of remittances. At this time, the list of users displayed may include, for example, users to whom the remitter has previously sent remittances, or users who have been searched for in the search box SB (using a phone number, account ID, display name, etc.). Furthermore, for example, the payment application 20 may link with other (social networking service) applications or messaging applications to display other users registered in these SNS applications or messaging applications.
[0034] As shown in area A2, users who are potential recipients of remittances are displayed with their own display names or their default phone numbers. When the remittance source user selects (clicks) a recipient user from the displayed list of users, the payment application 20 transitions the user to a chat room using peer-to-peer communication with the selected user, as shown in the right part of FIG. 8. The chat room includes, for example, a remittance button B1 for sending remittances to the selected user, a request button B2 for requesting a remittance from the selected user, and a message box MB for chatting with the selected user. In other words, the chat room combines a remittance function and a messaging function between users.
[0035] FIG. 9 is another diagram illustrating the flow of the remittance function using peer-to-peer communication. The screen shown in FIG. 9 is displayed, for example, when a user presses the remittance button B1 on the screen on the right side of FIG. 8. The screen shown on the left side of FIG. 9 includes, for example, an area A3 for inputting the remittance amount and an execute button B3 for executing the remittance of the input remittance amount. When the user inputs the remittance amount in area A3 and presses the execute button B3, the payment processing unit 130 deducts the remittance amount from the charge balance of the remitter user and simultaneously adds the remittance amount to the charge balance of the recipient user.
[0036] Thereafter, as shown in the right part of Figure 9, the payment application 20 of the remittance source user displays message information MS1 in the chat room indicating that the remittance has been completed. At the same time, the payment application 20 of the remittance destination user displays information indicating that the remittance has been received from the remittance source user. At this time, the payment application 20 of the remittance destination user also displays the display name of the remittance source user, so that the remittance destination user can know who has sent the remittance.
[0037] FIG. 10 is a diagram showing an example of a receipt screen displayed on the payment app 20 of the remittance recipient user. The screen shown in FIG. 10 corresponds to the remittance completion screen (the screen displayed on the payment app 20 of the remittance sender user) shown on the right side of FIG. 9, and represents a receipt completion screen displayed on the payment app 20 of the remittance recipient user. As shown in FIG. 10, the receipt completion screen includes an area A4 showing the display name of the remittance sender user and message information MS2 indicating that the remittance has been completed. The user who has received the remittance can understand from whom they have received the remittance by checking area A4 showing the display name of the remittance sender user.
[0038] [Display name change notification] As described above, electronic payment services allow users to transfer money to each other using peer-to-peer communication. When a remittance recipient user receives a remittance from a remittance source user, the remittance recipient user's display name is displayed in the payment app 20 along with the remittance amount, as described above. However, as shown in FIG. 10 , if the remittance source user sets the display name to the default (i.e., to the phone number), the remittance recipient user will see the remittance source user's phone number and may have difficulty identifying who has remitted the money. Conversely, if the remittance recipient user sets the display name to the default, the remittance source user may have difficulty identifying who to remit the money to when selecting the remittance destination user in the left section of FIG. 8 . As a result, users may have low confidence in using peer-to-peer communication in conventional electronic payment services.
[0039] The determination unit 152 determines whether the display name set for each user of the electronic payment service satisfies a predetermined condition. Here, the predetermined condition includes, for example, whether the set display name matches at least a portion of the name of the user authenticated by identity authentication. In this case, "matching at least a portion" may, more specifically, mean that the display name matches the entire last name and first name, the entire last name, the entire first name, a portion of the last name and first name, or a portion of the first name of the user authenticated by identity authentication. If the user has not performed identity authentication, the determination unit 152 automatically determines that the set display name does not satisfy the predetermined condition. Alternatively, the predetermined condition may be that the user has changed the default telephone number. In this case, even if the display name set by the user is different from the user's real name (e.g., a nickname or a character name), the determination unit 152 determines that the set display name satisfies the predetermined condition.
[0040] The determination unit 152 determines whether the display name satisfies a predetermined condition, for example, when the remittance source user executes peer-to-peer communication for remittance. More specifically, the determination unit 152 performs the above determination when the payment application 20 of the remittance source user transitions to the chat room shown in the right part of Fig. 8. As another aspect, the determination unit 152 may perform the above determination when the "Send" button shown on the top screen shown in Fig. 7 is pressed (i.e., the timing one step before the peer-to-peer communication is actually executed).
[0041] If the determination unit 152 determines that the display name does not satisfy a predetermined condition, the notification unit 154 outputs notification information regarding a change in the display name. Fig. 11 is a diagram showing an example of notification information notified by the notification unit 154. Fig. 11 shows notification information NI that is displayed in the payment app 20 of a remittance source user when the display name is not set (i.e., the display name is set to the phone number as default) and the user has been authenticated.
[0042] 11, the notification information NI includes suggested information PI suggesting changing the display name to the real name, a change to real name button B3, and a delete button B4 for deleting the notification information NI. The suggested information PI includes, for example, the user's current display name (i.e., the default phone number) and a suggested name (i.e., the real name). The suggested information PI in FIG. 11 includes the user's first and last names, but as described above, the suggested information PI may be either or part of the user's first and last names.
[0043] When the user presses the Change button B3, the payment application 20 sends information indicating that the Change button B3 has been pressed to the payment server 100, and the change unit 156 changes the display name of the user to their real name. More specifically, the change unit 156 updates the "display name" in the user information 172 from the default setting to their real name. On the other hand, when the user presses the Delete button B4, the payment application 20 deletes the proposed information PI. The Change button B3 is an example of an "interface element for changing identification information" in the claims. That is, according to this embodiment, the user does not need to go to a settings screen or enter their name to change their display name; they simply click the Change button B3. This allows the remitter to change their display name without burdening them and improves their trust in using peer-to-peer communication on the electronic payment service.
[0044] FIG. 12 is a diagram showing another example of notification information notified by the notification unit 154. In the case of FIG. 11, the notification unit 154 notifies the user to change the display name to a real name including a full name and a given name. On the other hand, as shown in FIG. 12, the notification unit 154 may output a plurality of patterns of display name candidates including at least one of a full name and a given name from the user's display name, and allow the user to select from them. This makes it possible to more effectively encourage users who are hesitant to make their entire real name public to change their display name. The display name candidates are an example of "identification information candidates" in the claims.
[0045] 12 shows an example of a display name candidate in which the user's first and last name are written in katakana. However, the present invention is not limited to such a configuration, and the notification unit 154 may output the display name candidate in other notations, such as hiragana or kanji. In another aspect, the notification unit 154 may output the display name candidate with part of the real name masked.
[0046] 11 and 12 is based on the premise that the user has already been authenticated (i.e., the name including the first and last name is correct). However, if the user has not been authenticated, there is no real name to be suggested to change, and therefore the notification unit 154 may suggest to the user that the user should be authenticated before suggesting a change to the real name.
[0047] [Notice regarding the execution of personal authentication] FIG. 13 is a diagram showing yet another example of notification information notified by the notification unit 154. FIG. 13 shows notification information NI displayed in the payment app 20 of a remitter user who has not performed identity authentication. As shown in FIG. 13, the notification information NI includes suggested information PI suggesting identity authentication, an identity authentication execution button B5, and a delete button B6 for deleting the notification information NI. When the user presses the execute button B5, the payment app 20 transitions to a screen for identity authentication (eKYC) and performs identity authentication by, for example, having the user upload information such as an official ID card or driver's license and comparing it with the identity image uploaded by the user. Upon completion of identity authentication, the notification unit 154 may subsequently output notification information NI to the payment app 20 suggesting that the user change the display name to their real name, as shown in FIGS. 11 and 12. This allows the user to be efficiently guided from identity authentication to changing the display name.
[0048] In the above description, the predetermined condition is defined as the set display name matching at least a part of the name of the user authenticated by identity authentication. However, the predetermined condition may include multiple conditions. For example, the predetermined condition may include the remittance source user transferring a predetermined amount or more, or transferring a predetermined number of times or more within a predetermined period. This allows notifications to be sent only to users who frequently use the remittance function of the electronic payment service, preventing annoying notifications from being sent to all users.
[0049] [Alert information notification] In another aspect, when the sending user executes a remittance, the determination unit 152 determines whether the display name of the user selected as the remittance destination satisfies the above-mentioned specified condition, and if it is determined that the display name of the user selected as the remittance destination does not satisfy the specified condition, the notification unit 154 may output alert information to the payment application 20 of the sending user before the remittance is executed.
[0050] FIG. 14 is a diagram showing an example of alert information notified by the notification unit 154. The screen shown in the left part of FIG. 14 represents the same step as the screen shown in the right part of FIG. 8, except that the display name of the recipient user is set to the default. In this case, as shown in the right part of FIG. 14, when the remitter user presses the remittance button B1, the notification unit 154 outputs alert information to confirm whether the recipient user is correct. At this time, if the recipient user has already performed identity authentication, the notification unit 154 may display part of the user's real name. When the user presses button B7, the payment application 20 proceeds to the left part of FIG. 9 (remittance step 3), while when the user presses button B8, the payment application 20 cancels the remittance. The output of the alert information is not limited to this timing and may be executed between the left part (remittance step 3) and the right part (remittance step 4) of FIG. 9. The output of the alert information may be executed at any timing before the remittance is executed.
[0051] [Processing flow] Fig. 15 is a sequence diagram showing an example of the flow of processing executed by cooperation between payment application 20 and payment server 100. The processing of the sequence diagram shown in Fig. 15 is executed, for example, when a user presses the "Send" button on the top screen shown in Fig. 7.
[0052] First, the payment application 20 receives a selection of a remittance destination user from the remittance source user and transitions to a remittance screen (chat room) (S31). Next, the payment application 20 notifies the payment server 100 of the transition to the remittance screen, including the user's account ID (S32). Next, the determination unit 152 determines whether the user's display name associated with the account ID satisfies a predetermined condition (S33). Here, the determination unit 152 determines that the user's display name does not satisfy the predetermined condition, that is, the user has set the display name to the default and does not match at least a part of the user's real name.
[0053] Next, the notification unit 154 outputs notification information regarding the change of the display name to the payment application 20 (S34). Next, the payment application 20 accepts consent to the change of the display name on the user terminal device 10 and transmits it to the payment server 100 (S35). Next, the change unit 156 changes the display name (S36). Next, the notification unit 154 outputs notification information indicating that the change of the display name has been completed to the payment application 20 (S37). Next, the payment application 20 executes the remittance process (S38).
[0054] According to the processing of the sequence diagram described above, when a remittance is received from a remittance source user, the remittance destination user can confirm the display name set as the real name. Furthermore, when a remittance source user who has changed their display name receives a remittance from another user at a later date, the display name set as the real name will be displayed as a possible remittance destination, allowing the remittance to be received more reliably. In other words, this improves users' confidence in using peer-to-peer communication on electronic payment services.
[0055] 16 is a flowchart showing an example of the flow of processing executed by the payment server 100. The processing of the flowchart shown in FIG. 16 is a detailed version of the processing of S33 and S34 in the sequence diagram shown in FIG.
[0056] First, the payment server 100 receives a notification of transition to a remittance screen from the payment application 20 of the remitter user (S100). Next, the determination unit 152 determines whether the user has been authenticated (S102). If it is determined that the user has not been authenticated, the notification unit 154 outputs notification information regarding the execution of authentication to the payment application 20 (S104).
[0057] On the other hand, if it is determined that the user has been authenticated, the determination unit 152 determines whether the user's display name satisfies a predetermined condition (S106). If it is determined that the user's display name satisfies the predetermined condition, the payment server 100 ends the process. On the other hand, if it is determined that the user's display name does not satisfy the predetermined condition, the notification unit 154 outputs notification information regarding the change in the display name to the payment app (S108). This ends the process of this flowchart.
[0058] In the process of the above flowchart, if it is determined that the user has not been authenticated, the notification unit 154 executes the notification process of S104. However, the present invention is not limited to such a configuration, and the notification process of S104 may be omitted, and the notification unit 154 may execute at least the notification process of S108.
[0059] Furthermore, in the above embodiment, for convenience of explanation, a distinction is made between the processing of payment application 20 and the processing of payment server 100 (information processing unit 150). However, the present invention is not limited to such a configuration, and the roles of the processing of payment application 20 and the processing of payment server 100 may be interchanged. For example, the processing of determination unit 152 and notification unit 154 of payment server 100 may be implemented as functions of payment application 20. In that case, payment server 100 has only the function of change unit 156 and changes the display name in user information 172.
[0060] Furthermore, in the above embodiment, a remittance function is cited as an example of a function using peer-to-peer communication on an electronic payment service. However, the present invention is not limited to such a function, and the function using peer-to-peer communication may be other functions, such as a chat function between users or a coupon transfer function that can be used for electronic payment services. Here, a coupon refers to a benefit in which a predetermined amount of the payment amount is cashed back when an electronic payment is made at a store of the issuing member store.
[0061] For example, when the present invention is applied to a chat function, the determination unit 152 may perform the above determination when one user sends a first message to another user, and the notification unit 154 may output notification information regarding a change in display name before sending the message. Also, when the present invention is applied to a coupon transfer function, the determination unit 152 may perform the above determination when one user transfers a coupon to another user, and the notification unit 154 may output notification information regarding a change in display name before transferring the coupon.
[0062] According to the embodiment described above, for each user of an electronic payment service, it is determined whether the user's identification information displayed in peer-to-peer communication with other users satisfies a predetermined condition, and if it is determined that the identification information does not satisfy the predetermined condition, notification information regarding a change in the identification information is output to the user's terminal device, thereby improving the user's confidence in using peer-to-peer communication on the electronic payment service.
[0063] 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]
[0064] 10 User terminal device 20. Payment App 100 Payment Server 120 Payment Contents Department 130 Payment processing unit 140 Information Management Department 150 Information Processing Department 152 Judgment section 154 Notification Department 156 Changes 170 Storage section
Claims
1. a determination unit that determines, for each user of an electronic payment service, whether or not the user has already performed personal authentication on the electronic payment service at the time the user starts peer-to-peer communication with another user, and determines whether or not the user's identification information displayed in the peer-to-peer communication satisfies a predetermined condition; a notification unit that outputs notification information regarding a change in the identification information to a terminal device of the user when the user has already performed the personal authentication and it is determined that the identification information does not satisfy the predetermined condition, the predetermined condition is that the identification information matches the first or last name of the user authenticated by the personal authentication; The notification information recommends changing the identification information to the first or last name of the user authenticated by the personal authentication. Information processing device.
2. When it is determined that the user has not yet performed the personal authentication, the notification unit outputs, to the terminal device, notification information recommending that the user perform the personal authentication on the electronic payment service. The information processing device according to claim 1 .
3. the notification information includes an interface element for changing the identification information on the electronic payment service; the information processing device further includes a change unit that changes the identification information in response to an operation of the interface element by the user; The information processing device according to claim 1 .
4. The notification unit outputs the notification information to the terminal device, including one or more identification information candidates based on the first name or last name of the user authenticated by the personal authentication, the change unit accepts a selection of the one or more identification information candidates from the terminal device, and changes the identification information to the selected identification information candidate. The information processing device according to claim 3 .
5. the determination unit determines whether the identification information of the other user satisfies the predetermined condition; the notification unit outputs alert information to the terminal device of the other user when it is determined that the identification information of the other user does not satisfy the predetermined condition. The information processing device according to claim 1 .
6. The computer For each user of the electronic payment service, at the time when the user starts peer-to-peer communication with another user, determine whether the user has already performed personal authentication on the electronic payment service, and determine whether the user's identification information displayed in the peer-to-peer communication satisfies a predetermined condition; If it is determined that the user has already performed the personal authentication and the identification information does not satisfy the predetermined condition, outputting notification information regarding a change in the identification information to the terminal device of the user; the predetermined condition is that the identification information matches the first or last name of the user authenticated by the personal authentication; The notification information recommends changing the identification information to the first or last name of the user authenticated by the personal authentication. Information processing methods.
7. On the computer, For each user of an electronic payment service, when the user starts peer-to-peer communication with another user, a determination is made as to whether or not the user has already performed personal authentication on the electronic payment service, and whether or not the user's identification information displayed in the peer-to-peer communication satisfies a predetermined condition; If it is determined that the user has already performed the personal authentication and the identification information does not satisfy the predetermined condition, outputting notification information regarding a change in the identification information to the terminal device of the user; the predetermined condition is that the identification information matches the first or last name of the user authenticated by the personal authentication; The notification information recommends changing the identification information to the first or last name of the user authenticated by the personal authentication. program.
Citation Information
Patent Citations
E-mail creation device and program
JP2012014311A
Payment management device, user terminal, payment management method, and display control method
JP7598508B1
JPP7598508B