Information processing device, information processing method, and program

Abstract

The present invention provides an information processing device, an information processing method, and a program that enable users to efficiently configure payment methods available for one service as payment methods for other services. [Solution] In an electronic payment service in which a payment server communicates via a network with one or more user terminal devices, one or more first store terminal devices, one or more second store terminal devices, and an external service server, the payment server 100 includes: an acquisition unit 152 that acquires request information from a user's terminal device of the electronic payment service requesting that the user's account information in the electronic payment service be linked to an external service; a linking unit 154 that links the account information to the external service based on the acquired request information; and a setting unit 158 ​​that, in accordance with the linking, sets the payment methods that the user can use in the electronic payment service included in the account information as payment methods that can be used in the external service.

Description

[Technical Field]

[0001] The present invention relates to an information processing apparatus, an information processing method, and a program. [Background Art]

[0002] Conventionally, there has been known a technique of registering credit card information in a payment application installed in a terminal device such as a smartphone, and performing credit payment via the payment application without exposing a physical credit card to the outside. For example, Patent Document 1 describes a technique in which, when a card registration request is received from a user terminal, authentication is performed based on card information, registered user information, and input information input from the user terminal, and the card is registered in the application based on the authentication result. [Prior Art Documents] [Patent Documents]

[0003] [Patent Document 1] Japanese Unexamined Patent Publication No. 2022-103891 [Summary of the Invention] [Problem to be Solved by the Invention]

[0004] However, the above technique requires a user to manually register credit card information in the application. That is, with the conventional technique, there have been cases where a user cannot efficiently set a payment method available for one service as a payment method for another service.

[0005] The present invention has been made in consideration of such circumstances, and one of the objects of the present invention is to provide an information processing apparatus, an information processing method, and a program that enable a user to efficiently set a payment method available for one service as a payment method for another service. [Means for Solving the Problem]

[0006] One aspect of the present invention is an information processing device comprising: an acquisition unit that acquires request information from a terminal device of a user of an electronic payment service requesting that the user's account information in the electronic payment service be linked to an external service; a linking unit that links the account information to the external service based on the acquired request information; and a setting unit that, in accordance with the linking, sets the payment means that the user can use in the electronic payment service, which are included in the account information, as payment means that can be used in the external service. [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 enable users to efficiently set payment methods available for one service as payment methods for other services. [Brief explanation of the drawing]

[0008] [Figure 1] This diagram shows an example of a configuration for implementing an electronic payment service. [Figure 2] This is a sequence diagram (part 1) illustrating the general flow of electronic payments. [Figure 3] This is a sequence diagram (part 2) illustrating the general flow of electronic payments. [Figure 4] This is a configuration diagram of the payment server 100 according to the first embodiment. [Figure 5] This figure shows an example of the contents of user information 172. [Figure 6] This figure shows an example of the contents of merchant / store information 176. [Figure 7] This figure shows an example of the top screen of a payment app 20. [Figure 8] This diagram shows an example of the process for linking accounts between an electronic payment service and an external service. [Figure 9] This diagram shows an example of the process for provisioning a credit card after account linking is complete. [Figure 10] This figure shows an example of the detailed provisioning process performed by the configuration unit 158. [Figure 11] This diagram shows an example of the relationship between the payment methods of an electronic payment service and the payment methods of an external service. [Figure 12] This figure shows an example of a payment method via an app interface displayed by an external service after the payment method has been linked. [Figure 13] This figure shows an example of a payment method via a web interface displayed by an external service after the payment method has been linked. [Figure 14] This sequence diagram shows an example of the processing flow executed through the collaboration of the payment application 20, the payment server 100, and the external service server 200. [Modes for carrying out the invention]

[0009] The following describes embodiments of the information processing apparatus, information processing method, and program of the present invention with reference to the drawings. Various devices used to provide services to users or perform internal analysis, such as the "server," "management device," and "information providing device" described below, may be implemented by a distributed group of devices, and the operators of each device may be different. Furthermore, the owner of the hardware of the devices (the provider of the cloud server) and the operator that actually operates them may also be different. The application program and the payment server work together to provide an electronic payment service. In the following description, the application program will be referred to as the payment app. The electronic payment service is a service that supports payment for the purchase of goods and services at a store. A store is, for example, a physical store (real store) that exists in the real world, but may also include a virtual store for e-commerce. A virtual store may include one provided by an entity different from the operator of the electronic payment service. In that case, when settling a purchase at a virtual store, the user may be directed to the interface screen of the electronic payment service. In the electronic payment service, stores are treated as belonging to, for example, affiliated merchants (brands), and processing such as payment when a purchase is made at a store is mainly carried out between the user and the affiliated merchant. Alternatively, payment and other processing may be conducted 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 implemented with a payment server 100 at its core. The payment server 100 communicates with, for example, one or more user terminal devices 10, one or more first store terminal devices 50, one or more second store terminal devices 70, and an external service server 200 via a network NW. The network NW includes, for example, the Internet, a LAN (Local Area Network), a wireless base station, and provider equipment.

[0011] The user terminal device 10 is, for example, a portable terminal device such as a smartphone or tablet. The user terminal device 10 is a computer device having at least optical reading function, communication function, display function, input reception function, and program execution function. In the following description, the components for realizing these functions will be referred to as a camera, communication device, touch panel, CPU (Central Processing Unit), etc. In the user terminal device 10, the payment application 20 is executed by a processor such as the CPU, and it operates in cooperation with the payment server 100 to provide electronic payment services to the user. The payment application 20 is installed on the user terminal device 10, for example, from 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 may include a so-called POS (Point of Sale) device, and the product price acquisition function and 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 paper or plastic media. The store code image 60 may also 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 an operator of a member store. The second store terminal device 70 is a smartphone, a tablet terminal, a personal computer, or the like. In the second store terminal device 70, an interface 72 for member stores operates. The interface 72 for member stores may be a member store application or a browser. The interface 72 for member stores accepts coupon settings and the like from the member store operator, and transmits the same to the settlement server 100. The second store terminal device 70, which is a smartphone, has functions of displaying a code image corresponding to a store code image, and reading a code image displayed by a user terminal device 10, by executing a member store application.

[0014] The settlement server 100 implements electronic settlement based on settlement 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 a member store server. In this case, settlement information is transmitted from the POS device to the settlement server 100 via the member store server. In the following description, this case is not particularly distinguished, and it is assumed that settlement information is transmitted from the first store terminal device 50.

[0015] The external service server 200 provides various services to users who have registered an account via a plurality of types of interfaces including a web interface and an application interface. For example, the external service server 200 provides a web browser installable on the user terminal device 10. By logging into the web browser on the user terminal device 10, for example, the user can use various services such as personalized search and email service according to the user's interests and preferences on the web browser. Further, for example, the external service server 200 provides an application program installable on the user terminal device 10. By logging into the application on the user terminal device 10, for example, the user can use various services such as personalized search and email service on the application.

[0016] Figures 2 and 3 are sequence diagrams illustrating the general flow of electronic payments. There may be two patterns for electronic payments: Pattern 1 and Pattern 2.

[0017] In the case of Pattern 1 shown in Figure 2 (hereinafter referred to as User Scan), 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 contains information about the store URL (Uniform Resource Locator). This store URL is an electronic payment service domain to which information that can identify the store has been added, and is associated with the merchant ID and store ID, etc., at the payment server 100 (described later). The payment application 20 sends the 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 later) from the merchant ID and store ID corresponding to the store URL, obtains the merchant name and store name information (S3), and sends it to the payment application 20 (S4). The user enters the payment amount into the user terminal device 10 on the screen where the merchant name and store name are displayed (S5). The user terminal device 10 then generates second payment information, including at least the payment amount, and sends it to the payment server 100 (S6). The payment server 100 performs electronic payment based on the received second payment information (S7). The payment server 100 then sends a payment completion notification (information for displaying the payment completion screen) to the payment application 20 (S8), and the payment application 20 displays the payment completion screen (S9). If the store code image 60 is displayed on a display placed in the store, the store code image 60 may include payment amount information as well as the store URL. In this case, the procedure for the user to enter the payment amount is omitted, and the payment amount information is included in the first payment information and sent to the payment server 100. Merchant name and store name information may be included and displayed on the payment completion screen.

[0018] In the case of Pattern 2 shown in Figure 3 (hereinafter referred to as Store Scan), when the payment app 20 is launched, when a payment operation is performed in the payment app 20, when it is time for an automatic update (for example, every minute), and at other times, the payment app 20 sends a request to the payment server 100 to issue a one-time code (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 that was generated based on the one-time code (S14). The user holds the display surface of the user terminal device 10 over the first store terminal device 50 (presents it), and the first store terminal device 50 decodes the code image using its optical reading function and obtains the one-time code, etc. (S15). Then, the first store terminal device 50 generates payment information including the one-time code, payment amount, merchant ID, store ID, etc., and sends it to the payment server 100 (S16). The payment amount information is obtained in advance by barcode scanning or manual input. Based on the received information, the payment server 100 identifies the user corresponding to the one-time code and performs the electronic payment (S17). The payment server 100 then sends a payment completion notification to the payment app 20 (S18), and the payment app 20 displays a payment completion screen (S19).

[0019] Furthermore, electronic payment may be performed using only one of the above patterns. Also, the "account ID" explained in Figure 2 may be other information that can be used as user identification information (for example, a phone number). In addition, the issuance of a one-time code may be omitted during store scanning, and the payment app 20 may display a code image generated based on the user's account ID. In that case, the payment server 100 will identify the user corresponding to the account ID instead of identifying the user corresponding to the one-time code.

[0020] [Payment Server] Figure 4 is a configuration diagram of a payment server 100 according to the first embodiment. The payment server 100 includes, for example, a communication unit 110, a payment content provision unit 120, a payment processing unit 130, an information management unit 140, an information processing unit 150, and a storage unit 170. The information processing unit 150 further includes an acquisition unit 152, a cooperation unit 154, a determination unit 156, and a setting unit 158. Components other than the communication unit 110 and the storage unit 170 are realized, for example, by 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 LSI (Large Scale Integration), ASIC (Application Specific Integrated Circuit), FPGA (Field-Programmable Gate Array), and GPU (Graphics Processing Unit), or by the cooperation of software and hardware. The program may be stored in advance on a storage device such as an HDD (Hard Disk Drive) or flash memory (a storage device equipped with a non-transient storage medium), or it may be stored on a removable storage medium such as a DVD or CD-ROM (a non-transient storage medium) and installed on the storage device when the storage medium is inserted into the drive device.

[0021] The storage unit 170 can be an HDD, flash memory, RAM (Random Access Memory), etc. The storage unit 170 may also be a NAS (Network Attached Storage) device that can be accessed by the payment server 100 via the network. The storage unit 170 stores information such as user information 172, payment content information 174, and merchant / store information 176.

[0022] The communication unit 110 is a communication interface for connecting to a network NW. The communication unit 110 is, for example, a network interface card.

[0023] The payment content provision unit 120, for example, has the functionality 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 provision unit 120 reads the necessary content from the payment content information 174 as appropriate and provides it to the user terminal device 10. The user terminal device 10 receives various inputs from the user while the content is being played by the payment application 20 and transmits the aforementioned payment information and other data to the payment server 100.

[0024] The payment processing unit 130 performs payment processing based on 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.

[0025] Figure 5 shows 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, user URL, account ID, telephone number, password, as well as information such as email address, user ID, name, address, date of birth, registration date, charge balance, credit payment settings, credit payment limit, credit payment amount, available credit payment amount, payment method settings, bank account, credit card number, balance card number, charge history information, and payment history information. The user URL is used for money transfer processing between users. When registering for a new electronic payment service, registration of a telephone number and password is mandatory. The account ID is issued to the user by the payment server 100, and the user ID is an ID that the user can set at will (or not set). Similarly, the email address and name, address, and date of birth are also information that the user can set at will (or not set). The registration date is the date the user registered for the electronic payment service (the date the account was created). Hereafter, the user instance (electronic payment account) to which this information is associated will be referred to as an account.

[0026] The charge balance is information indicating the balance of electronic money set by the user by sending money to their account in advance. Methods of sending money include sending from an ATM (Automatic Teller Machine) of a designated provider (bank) and sending from a registered bank account. The credit payment setting indicates whether or not the user has completed the settings to enable electronic payments by credit card, and is set to either "Completed" or "Not Completed". The credit payment limit is the monthly limit for credit payments, the credit payment amount is the amount already used for credit payments in the current month, and the available credit payment amount is the amount available for credit payments in the current month, calculated by subtracting the credit payment amount from the credit payment limit. While the diagram shows only one credit payment limit, in reality there are also daily limits, and the lower of these may be set as the credit payment limit. Further details on credit payments will be described later. The payment method setting indicates whether the user will use electronic payment with the charge balance or payment by credit card at that time. The bank account and credit card number are, respectively, bank account or credit card number information (account number, card number) that can be used to deposit funds into the electronic payment service. The balance card number is card number information that identifies the balance card. Here, a balance card means a virtual card that a user can pre-charge from their bank account or charge balance and use to perform electronic payments using the charged balance. By using a balance card, a user can, for example, make an online payment on an online shopping site that does not support charge balance payments by entering the balance card number. In this case, the online shopping site sends payment information (including, for example, the payment amount and balance card number) to the payment server 100, and the payment server 100 performs the payment by subtracting the payment amount from the charge balance.

[0027] Credit cards and balance cards may be integrated and issued as a single hybrid card. In this case, the hybrid card may be a physical card rather than a virtual card. When a hybrid card is issued, the payment app 20 is configured to allow the user to switch between balance payment and credit payment as the payment method for the hybrid card. This allows users to make balance payments or credit payments even at physical stores of merchants that do not participate in the electronic payment service, by using the hybrid card to make payments at the store's credit payment terminal. The charge history information is a record of when the user has previously sent money to the electronic payment service to increase their balance. The payment history information shows the details of each payment made by the user (date and time, store ID of the store where the purchase was made, payment amount, payment method, etc.).

[0028] Figure 6 shows an example of the contents of the merchant / store information 176. The merchant / store information 176 includes, for example, a first table 176A in which the merchant ID and store ID are associated with the store URL, a second table 176B in which the merchant name and sales amount (as described above) are associated with the merchant ID, and a third table 176C in which the store name is associated with the store ID. In addition to this information, the merchant / store information 176 may also include information such as the merchant or store category, the store's location, and payment patterns.

[0029] The Information Management Unit 140 manages user information 172 and affiliated store / store information 176 based on information obtained from the user terminal device 10 and the second store terminal device 70. The Information Management Unit 140 performs operations such as adding, editing, and deleting new records for user information 172 and affiliated store / store information 176.

[0030] As described later, the information processing unit 150 performs account linking between the electronic payment service and external services provided by the external service server 200, and the associated linking of payment methods. Details of the processing performed by the information processing unit 150 will be described later. The information processing unit 150 is an example of an "information processing device" in the claims.

[0031] [Electronic payment] When the payment processing unit 130 obtains payment information from the user terminal device 10 or the first store terminal device 50, it refers to the user information 172 to obtain the user's "payment method setting". 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, which is managed in association with the user ID, and increasing the value of the merchant's sales proceeds item. For example, the value of the merchant's sales proceeds item is not used as electronic money itself, but rather the amount corresponding to the value of the sales proceeds item is transferred to the bank account in a cycle according to the agreement between the merchant and the electronic payment service.

[0032] The payment processing unit 130 performs electronic payment as follows for users whose "settings information" is set to "credit payment". Credit payment is a payment method in cooperation with a credit card company, which is a separate entity from the electronic payment service operator. The electronic payment service operator acts as the donor and allows electronic payment within the credit limit, without relying on the charge balance. In order to use the credit payment service, users may be required to obtain a credit card provided by the electronic payment service operator. The amount used by credit payment is settled in a lump sum for the month on the payment date of the following month, for example, by withdrawal from a bank account. In this case, the payment processing unit 130 performs a provisional settlement by adding the settlement amount to the amount used by credit payment and subtracting the same amount from the available credit payment limit. When the closing date arrives, it processes the payment for the current month to be withdrawn on the payment date of the following month as described above, or requests the credit card company operator to perform the said process. If the settlement amount exceeds the available credit payment limit at the time of provisional settlement, an error notification is sent back to the payment app 20.

[0033] [Top screen] Figure 7 shows an example of the top screen of the payment app 20. The top screen displays a code image CI. The code image CI includes, for example, barcodes and QR codes. Next to the code image CI, there is a toggle switch SW for switching between electronic payment using the charged balance or electronic payment using credit. Note that "switch" and "button" refer to GUI (Graphical User Interface) implemented in conjunction with the touch panel. In Figure 7, "Credit" is displayed, which means that the setting is for electronic payment using credit. The user can switch between electronic payment using the charged balance or electronic payment using credit by, for example, swiping the toggle switch SW.

[0034] The top screen also includes an operation area OA, and transition buttons TB1, TB2, and TB3. The operation area OA is equipped with buttons that instruct the main operations in electronic payment, such as a button to initiate scanning (start user scanning), a button to send the charge balance to other users, a button to display the points earned by the user, and a button to display the history of electronic payments performed by the user. When transition button TB1 is pressed, the user transitions to a payment screen that displays the code image used for electronic payment and the available amount. When transition button TB2 is pressed, the user transitions to a screen that displays the available amount for balance payment or credit payment. In Figure 7, since electronic payment using the charge balance is set, when transition button TB2 is pressed, the available amount for balance payment is displayed.

[0035] At the bottom of the operating area OA, for example, a group of buttons (switches) M1, M2, ... for launching mini-applications are displayed. A mini-application is an application that operates using the payment application 20 as a platform and provides some kind of service. The service provider develops the mini-application by referring to the SDK (Software Development Kit), which consists of application development programs and technical documents provided by the administrator of the payment application 20. A mini-application is an application that operates when the payment application 20 is running. For example, when the payment application 20 is installed, some or all of the mini-application may be installed, or some or all of the mini-application may be installed from the service server corresponding to the mini-application. For example, when a mini-application is launched, the mini-application accesses an external service server 200 that provides the service corresponding to the mini-application, and the mini-application and the external service server 200 cooperate to provide services to the user. In this case, the external service server 200 may be the payment server 100 itself. In Figure 7, as an example, buttons M1 for a mini-app that provides a function related to coupons usable in electronic payment services offered by a merchant, and buttons M2 for a mini-app that provides a function for investing in investment products (e.g., stocks and bonds) offered by a securities company are displayed. However, buttons for launching various types of mini-apps may be displayed, such as reservation apps for amusement facilities like movie theaters, or payment apps for paying public transportation fares.

[0036] [Integration with external services] The transition button TB3 is a transition button for linking the electronic payment service account with the account for the external service provided by the external service server 300. When the transition button TB3 is operated, the payment application 20 transitions to a screen for linking the electronic payment service account with the account for the external service provided by the external service server 300. In this embodiment, the case in which the payment methods available to the user in the electronic payment service are linked to the external service server 300 in conjunction with the account linking will be described below.

[0037] Figure 8 shows an example of the flow of account linking between an electronic payment service and an external service. The screen shown in Figure 8 is displayed, for example, when the user presses the transition button TB3 on the top screen of the payment app 20 shown in Figure 7.

[0038] As shown in the left part of Figure 8, for example, when a user presses the transition button TB3 on the top screen, the payment app 20 displays information on the screen indicating that it will link the electronic payment service account to an external service. In the left part of Figure 8, area A1 shows a list of permissions and information of the electronic payment service account provided to the external service through the linkage. The payment app 20 displays, for example, in area A1 that payment by electronic payment service is possible when making a payment at the external service, that payment by electronic payment service is continuously available for payments at the external service (for example, a subscription at the external service), that it will partially refer to the phone number registered with the electronic payment service, that it will refer to the information and card information registered with the electronic payment service, that it will refer to the user's payment information and service usage history, and that it will refer to identity verification information (for example, name, date of birth, address, etc.).

[0039] When the user confirms the agreement displayed in area A1 and presses the transition button TB4, the payment app 20 sends a request to the payment server 100 requesting that the user's account information for the electronic payment service be linked to an external service. On the other hand, when the user presses the transition button TB5, the payment app 20 transitions to, for example, the top screen shown in Figure 7 without performing the account information linkage.

[0040] When the acquisition unit 152 of the payment server 100 acquires request information from the payment application 20, the linking unit 154 links (shares) the user's account information (in this case, account information may include the user's identification information stored in the user information 172, as well as the contents of the consent items described in area A1) to the external service server 200 via the network NW.

[0041] In response to the coordination by the coordination unit 154, the setting unit 158 ​​sets the payment methods available to the user in the electronic payment service, as included in the account information, as payment methods available in the external service. For example, referring to the user information 172 in Figure 5, the user with account ID "001" can use charge balance, credit payment, credit card, and balance card as payment methods in the electronic payment service. Therefore, the setting unit 158 ​​configures the external service server 200 to make these payment methods available in the external service (or sends a request to the external service server 200 to make them available).

[0042] The right side of Figure 8 shows a notification screen indicating that the linking by the linking unit 154 and the settings by the setting unit 158 ​​have been completed. As shown in the right side of Figure 8, when the payment application 20 receives completion information from the payment server 100 indicating that the electronic payment service account has been linked to the external service, it displays the completion information on the screen. Furthermore, the payment application 20 displays, for example, notification information on area A2 indicating that the payment method is available on a device or service that is logged into the external service, and a list of payment methods linked to the external service.

[0043] For example, in the right-hand portion of Figure 8, the payment app 20 indicates that it has linked its charge balance, credit payment, balance card, and credit card to an external service as payment methods. Note that the difference between credit payment and credit card is that with credit payment, an electronic payment service is involved in the execution of the payment, whereas with a credit card, the payment is executed without the involvement of an electronic payment service (except when the electronic payment service itself is the issuer of the credit card).

[0044] [Provisioning] In this way, users can link to external services using multiple payment methods available in the electronic payment service through simple operations such as pressing the consent button TB4. However, if, for example, an external service provides the functionality of a digital wallet that encrypts a credit card and enables credit card payment (contactless payment) using the terminal device, then the execution of processes generally called provisioning, such as encryption processing and validity verification processing by the credit card issuer, is required. Below, as an example, we will describe a case in which an external service provides the functionality of a digital wallet corresponding to a credit card, and provisioning of the credit card is performed accordingly. However, the present invention is not limited to such a configuration, and similarly, when an external service provides the functionality of a digital wallet corresponding to the balance card or hybrid card mentioned above, provisioning such as encryption processing and validity verification processing of these balance cards and hybrid cards is also performed.

[0045] The determination unit 156 determines, in response to the cooperation by the cooperation unit 154, whether the payment methods available to the user in the electronic payment service correspond to a digital wallet provided by an external service. More specifically, the determination unit 156 may determine whether the payment methods available to the user in the electronic payment service include a credit card. In the case of the right side of Figure 8, the determination unit 156 determines that a credit card, which is one of the payment methods available to the user in the electronic payment service, corresponds to a digital wallet. Therefore, the determination unit 156 causes the payment application 20 to display a transition button TB6 to guide the user to set up touch payment. When the user presses the transition button TB6, the payment application 20 transitions to a screen for performing provisioning. On the other hand, when the user presses the transition button TB7, the payment application 20 transitions to, for example, the top screen of Figure 7 without performing provisioning.

[0046] Figure 9 shows an example of the process for provisioning a credit card after account linking is complete. The screen shown in Figure 9 is displayed, for example, when the user presses the transition button TB6 on the payment app 20 screen shown on the right side of Figure 8.

[0047] As shown on the left side of Figure 9, for example, when a user presses the transition button TB6 on the screen of the payment app 20 shown on the right side of Figure 8, the payment app 20 displays information indicating that a digital wallet will be set up in an external service. In the left side of Figure 9, area A3 displays notification information indicating that contactless payment at stores will be enabled by setting up the digital wallet. When the user confirms the notification information displayed in area A3 and presses the transition button TB8, the payment app 20 works with the setting unit 158 ​​of the payment server 100 to perform provisioning to add the credit card to the digital wallet. On the other hand, when the user presses the transition button TB9, the payment app 20 transitions to, for example, the screen on the right side of Figure 8 without performing provisioning.

[0048] Once provisioning is complete, the payment app 20 displays information indicating that the credit card has been added to the digital wallet and contactless payment has been enabled, as shown in area A4 on the right side of Figure 9. This allows users to make electronic payments when purchasing goods or services at physical stores without exposing their physical credit card to anyone.

[0049] Furthermore, in conventional technology, when a user sets up a credit card in a digital wallet, this is achieved through individual operations that link the terminal device used to set up the digital wallet with the credit card information. On the other hand, according to this embodiment, by performing account linking between the electronic payment service and an external service, it becomes possible to seamlessly set up a credit card in a digital wallet, reducing the burden on the user compared to conventional technology that requires individual operations to link the terminal device with the credit card information.

[0050] Figure 10 shows an example of the detailed provisioning process. The screen shown on the far left of Figure 10 is displayed, for example, when the user presses the transition button TB8 on the screen of the payment application 20 shown on the left side of Figure 9. For the sake of brevity of the explanation below, the payment application 20 will be described as the main entity in operation, but provisioning is performed while communicating with the setting unit 158 ​​of the payment server 100 (for example, while receiving control from the setting unit 158), and the payment application 20 may simply display a screen.

[0051] First, the payment app 20 displays a screen for confirming the user's address information, for example, on area A5. The user's address information can be displayed, for example, the address information stored in user information 172. Once the user confirms the address information and presses the transition button TB10, the payment app 20 proceeds to the device selection screen, the second from the left in Figure 10. The device selection screen is for specifying the terminal device on which to set up the digital wallet. For example, Figure 10 shows a device selection screen where the user selects one of two devices (a smartphone corresponding to the transition button TB11, and a tablet terminal corresponding to the transition button TB12).

[0052] When a user selects a device from the device selection screen and presses the corresponding transition button (transition button TB11 or TB12 in Figure 10), the payment app 20 connects to the bank server of the bank associated with the credit card. The bank to connect to at this time can be identified, for example, based on the bank account stored in the user information 172. After connecting to the bank server, the payment app 20 then displays the terms and conditions of the issuer that issued the credit card. When the user confirms the terms and conditions of the issuer and presses the transition button TB13, provisioning is completed and the user transitions to the screen shown on the right side of Figure 9.

[0053] Figure 11 is a diagram illustrating an example of the relationship between payment methods of an electronic payment service and payment methods of an external service. The left side of Figure 11 shows the payment methods available to the user within the electronic payment service, and the right side of Figure 11 shows the payment methods available in the external service that become available by linking the user account of the electronic payment service. For example, the external service provides multiple payment methods that can be used through multiple types of interfaces, including a web interface and an application interface, and the determination unit 156 determines whether each of the multiple payment methods available to the user within the electronic payment service corresponds to each of the multiple payment methods provided by the external service.

[0054] If the setting unit 158 ​​determines that each of the multiple payment methods available to the user in the electronic payment service corresponds to each of the multiple payment methods provided by the external service, it sets each of the multiple payment methods available to the user in the electronic payment service to each of the multiple payment methods provided by the external service (or sends request information to the external service server 200 to request setting). Alternatively, the external service server 200 may have a correspondence determination function in the determination unit 156 and a payment method setting function in the setting unit 158, and the payment application 20 or payment server 100 may simply send information about the payment methods available to the user in the electronic payment service to the external service server 200 and request the external service server 200 to determine the correspondence and set the payment methods.

[0055] In the situation shown in Figure 11, for example, the payment methods available to the user in the electronic payment service include the charge balance, credit payment, balance card, and credit card, and the payment methods provided by the external service include payment methods via the app interface (e.g., purchasing apps and services in the app store), payment methods via the web interface (e.g., on a web browser screen), and digital wallets. In this case, the determination unit 156 determines whether each of the charge balance, credit payment, balance card, and credit card corresponds to each of the payment methods via the app interface, payment methods via the web interface, and digital wallets. In the case of Figure 11, the determination unit 156 determines that the charge balance, credit payment, balance card, and credit card all correspond to payment methods via the app interface, the balance card and credit card correspond to payment methods via the web interface, and the credit card corresponds to a digital wallet. Therefore, the setting unit 158 ​​sets the payment methods of the electronic payment service in conjunction with the payment methods of the external service, as shown by the arrows in Figure 11.

[0056] Figure 12 shows an example of a payment method via an app interface displayed by an external service after the payment method has been linked. As an example, Figure 12 shows a case where, after the payment method has been linked, the user logs in to an external service and accesses the app store provided by that external service.

[0057] As shown in Figure 12, when a user selects an app to purchase and proceeds to the purchase screen, the external service displays the payment methods linked from the electronic payment service, namely, the charge balance, credit payment, balance card, and credit card, as shown in area A6. The user can select one of the displayed payment methods and press the payment button to perform electronic payment through the external service. For example, in Figure 12, since the user has selected the charge balance, the external service server 200 sends information to the payment server 100 indicating that the charge balance has been selected as the payment method and that the payment amount is 100 yen, and the payment processing unit 130 of the payment server 100 executes a charge balance payment of 100 yen.

[0058] Figure 13 shows an example of a payment method via a web interface displayed by an external service after the payment method has been linked. As an example, Figure 13 shows a case where, after the payment method has been linked, the user logs in to the external service and accesses an online shopping site using the web browser provided by the external service.

[0059] As shown in Figure 13, when a user selects an item to purchase and proceeds to the purchase screen, the external service displays the payment methods linked from the electronic payment service, namely credit cards and balance cards, as shown in area A7. For example, if a user selects a credit card, they would normally need to enter their credit card number into the input form IN. However, in this embodiment, as described above, since the user's credit card information is linked to the external service, the web browser provided by the external service automatically fills (autofills) the linked credit card number into the input form IN and presents it to the user. The user can then verify the correctness of the automatically entered credit card number and press the payment button to execute the electronic payment through the external service.

[0060] Thus, according to this embodiment, even if there are multiple payment methods available in the electronic payment service, the user can link and set them up as payment methods available in external services with simple operations. In particular, in the conventional technology, when a user sets up a payment method in an external service, it was necessary to add a payment method for each individual service provided by the external service, but according to this embodiment, the burden on the user in setting up such payment methods can be reduced.

[0061] [Process flow] Figure 14 is a sequence diagram showing an example of the processing flow executed through the collaboration of the payment application 20, the payment server 100, and the external service server 200. The processing shown in the sequence diagram of Figure 14 is executed, for example, when a user presses the transition button TB4 to request account linking on the screen shown on the left side of Figure 8.

[0062] First, the payment application 20 sends an account linking request to the payment server 100 (step S10). Next, when the payment server 100 receives the account linking request, it performs account linking and payment method configuration on the external service server 200 (step S12). Next, when the external service server 200 has completed the account linking and payment method configuration, it sends a completion notification to the payment server 100 (step S14).

[0063] Next, the payment server 100 determines whether the linked payment method is compatible with a digital wallet (including credit cards) (step S16). Here, we assume that it is determined that the linked payment method is compatible with a digital wallet. In that case, the payment server 100 displays an account linking completion notification and a digital wallet setup guide on the payment app 20, as shown on the right side of Figure 8 (step S18).

[0064] Next, the payment app 20 sends a digital wallet setup request to the payment server 100 in response to the user's actions (step S20). Upon receiving the digital wallet setup request, the payment server 100 performs provisioning (step S22). Once provisioning is complete, the payment server 100 sends a digital wallet setup completion notification to the payment app 20 (step S24). This completes the process described in this flowchart.

[0065] For the sake of clarity, the above explanation distinguishes between the software functions of the payment application 20, the payment server 100, and the external service server 200. However, the division of these software functions may be rearranged as appropriate. For example, the payment application 20 may have the function of linking user account information instead of the payment server 100, and may directly request the external service server 200 to link account information and set up payment methods without going through the payment server 100. Alternatively, the external service server 200 may have some or all of the functions of the payment server 100, and the payment application 20 and the external service server 200 may communicate to perform the linking of account information and setting up payment methods.

[0066] According to the embodiment described above, the user can link and configure payment methods available in the electronic payment service as payment methods available in external services with simple operations, and if the user has payment methods available in a digital wallet, provisioning for activation of the digital wallet is performed after the linking. In other words, this makes it possible for the user to efficiently configure payment methods available in one service as payment methods in other services.

[0067] Although embodiments for carrying out the present invention have been described above using examples, the present invention is not limited in any way to these embodiments, and various modifications and substitutions can be made without departing from the spirit of the present invention. [Explanation of Symbols]

[0068] 10. User terminal device 20 Payment Apps 100 Payment Servers 120 Payment Content Provision Department 130 Payment Processing Unit 140 Information Management Department 150 Information Processing Unit 152 Acquisition Department 154 Liaison Department 156 Judgment section 158 Settings Section 200 External Service Servers

Claims

[Claim 1] An acquisition unit that acquires request information from the terminal device of a user of an electronic payment service requesting that the user's account information in the electronic payment service be linked to an external service, Based on the acquired request information, a linking unit links the account information to the external service, In accordance with the aforementioned collaboration, the system includes a setting unit that sets the payment methods available to the user in the electronic payment service, as included in the account information, as payment methods available to the external service. Information processing device.

Images