Settlement system and processing execution method

Abstract

To improve convenience of a user.SOLUTION: A setting information acquisition unit (208) of a payment system (1) acquires setting information about a setting related to a payment service, the setting being specified by a mobile terminal (30) of a user in the payment service. A setting information transmission unit (209) transmits setting information to a wearable device (40) connectable to a mobile terminal (30).SELECTED DRAWING: Figure 10

Description

[Technical Field]

[0001] The present disclosure relates to a payment system, a wearable device, a processing execution method, and a program. [Background technology]

[0002] Conventionally, there is known a technology that enables a user to use a payment service from a wearable device connectable to the user's mobile terminal. For example, Patent Document 1 describes a display control system in which the user's mobile terminal requests a server to issue a code to be used in the payment service based on a token acquired in a previous authentication, the server issues the code and transmits it to the mobile terminal, the mobile terminal transmits the code to a wearable device, and the wearable device displays the code received from the mobile terminal. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Japanese Patent Publication No. 2021-039643 Summary of the Invention [Problem to be solved by the invention]

[0004] However, the technology of Patent Document 1 can display a code on a wearable device, but cannot allow the wearable device to acquire settings related to payment services. With the technology of Patent Document 1, the user must turn on the mobile terminal to check the settings, which does not sufficiently improve user convenience.

[0005] One of the purposes of the present disclosure is to improve user convenience. [Means for solving the problem]

[0006] The payment system according to the present disclosure includes a setting information acquisition unit that acquires setting information regarding the settings for a payment service, which are specified on a user's mobile terminal, and a setting information transmission unit that transmits the setting information to a wearable device that can be connected to the mobile terminal. [Effects of the Invention]

[0007] The present disclosure can improve convenience for users. [Brief explanation of the drawings]

[0008] [Figure 1] FIG. 2 is a diagram illustrating an example of a hardware configuration of a payment system. [Figure 2] FIG. 10 is a diagram illustrating an example of a screen displayed on a mobile terminal. [Figure 3] FIG. 10 is a diagram illustrating an example of a screen displayed on the wearable device. [Figure 4] FIG. 2 is a diagram illustrating an example of functions implemented in the payment system of the first embodiment. [Figure 5] FIG. 10 is a diagram illustrating an example of an ID database. [Figure 6] FIG. 10 is a diagram illustrating an example of a payment database. [Figure 7] FIG. 2 is a diagram illustrating an example of processing executed in the payment system of the first embodiment. [Figure 8] FIG. 2 is a diagram illustrating an example of processing executed in the payment system of the first embodiment. [Figure 9] FIG. 10 is a diagram illustrating an example of a screen displayed on the wearable device. [Figure 10] FIG. 10 is a diagram illustrating an example of functions realized in the payment system of the second embodiment. [Figure 11] FIG. 10 is a diagram illustrating an example of processing executed in the payment system of the second embodiment. [Figure 12] FIG. 10 is a diagram illustrating an example of functions realized in Modifications 1-1 to 1-3. [Figure 13] FIG. 10 is a diagram illustrating an example of usage restriction data. [Figure 14] FIG. 10 is a diagram illustrating an example of restriction removal data. [Figure 15] FIG. 10 is a diagram illustrating an example of a hardware configuration in Modification Example 1-3. [Figure 16] FIG. 10 is a diagram showing an example of a screen displayed on a wearable device in Modification Example 1-3. [Figure 17] FIG. 10 is a diagram showing an example of functions realized in the payment system according to Modifications 1-3 to 1-6. [Figure 18] FIG. 10 is a diagram illustrating an example of a point database. [Figure 19] FIG. 10 is a diagram showing an example of functions realized in Modifications 2-1 to 2-7. [Figure 20] FIG. 10 is a diagram showing an example of a screen transition of a wearable device in Modification Example 2-3. [Figure 21] FIG. 10 is a diagram showing an example of a screen displayed on a mobile terminal according to Modification Example 2-7. DETAILED DESCRIPTION OF THE INVENTION

[0009] [1. First embodiment] A first embodiment will be described as an example of an embodiment of a payment system, a wearable device, a display control method, and a program according to the present disclosure.

[0010] [1-1. Hardware configuration of payment system] Figure 1 is a diagram showing an example of the hardware configuration of a payment system. For example, the payment system 1 includes an ID server 10, a payment server 20, a mobile terminal 30, a wearable device 40, and a store terminal 50. Each of the ID server 10, the payment server 20, the mobile terminal 30, the wearable device 40, and the store terminal 50 is connected to a network N such as the Internet or a LAN. Note that while Figure 1 shows one each of the ID server 10, the payment server 20, the mobile terminal 30, the wearable device 40, and the store terminal 50, there may be multiple ID servers 10, payment servers 20, the mobile terminal 30, the wearable device 40, and the store terminal 50.

[0011] The ID server 10 is a server computer that manages various types of user information. For example, the ID server 10 includes a control unit 11, a storage unit 12, and a communication unit 13. The control unit 11 includes at least one processor. The storage unit 12 includes at least one of a volatile memory such as RAM and a non-volatile memory such as a flash memory. The communication unit 13 includes at least one of a communication interface for wired communication and a communication interface for wireless communication.

[0012] The payment server 20 is a server computer that provides a payment service to users. The payment service is a service that provides electronic payment (cashless payment) to users. For example, the payment server 20 includes a control unit 21, a memory unit 22, and a communication unit 23. The hardware configurations of the control unit 21, the memory unit 22, and the communication unit 23 may be similar to those of the control unit 11, the memory unit 12, and the communication unit 13, respectively.

[0013] The mobile terminal 30 is a mobile (portable) terminal. For example, the mobile terminal 30 is a smartphone, a mobile phone not classified as a smartphone, a tablet, or a laptop. The mobile terminal 30 may also be a wearable device other than the wearable device 40. The mobile terminal 30 includes a control unit 31, a memory unit 32, a communication unit 33, an operation unit 34, and a display unit 35. The hardware configurations of the control unit 31, the memory unit 32, and the communication unit 33 may be similar to those of the control unit 11, the memory unit 12, and the communication unit 13, respectively. The operation unit 34 is an input device such as a touch panel or a mouse. The display unit 35 is a display such as a liquid crystal or organic electroluminescence (EL) display.

[0014] The wearable device 40 is a device that can be worn by a user. For example, the wearable device 40 may be a smart watch, smart glasses, or an accessory-type device. The user can wear the wearable device 40 on any part of the body, such as the arm, finger, neck, or head. The wearable device 40 includes a control unit 41, a storage unit 42, a communication unit 43, an operation unit 44, and a display unit 45. The hardware configurations of the control unit 41, the storage unit 42, the communication unit 43, the operation unit 44, and the display unit 45 may be similar to those of the control unit 11, the storage unit 12, the communication unit 13, the operation unit 34, and the display unit 35, respectively. The wearable device 40 may include a SIM card that can be connected to a public communication line, or may be able to use wireless communication such as a wireless LAN without being connected to a public communication line.

[0015] The store terminal 50 is a terminal of a member store that is a member of the payment service. For example, the store terminal 50 is a POS terminal, a self-checkout terminal, a smartphone, a tablet, a handheld terminal, or a personal computer. The store terminal 50 includes a control unit 51, a memory unit 52, a communication unit 53, an operation unit 54, a display unit 55, and a reading unit 56. The hardware configurations of the control unit 51, the memory unit 52, the communication unit 53, the operation unit 54, and the display unit 55 may be similar to those of the control unit 11, the memory unit 12, the communication unit 13, the operation unit 34, and the display unit 35, respectively. The reading unit 56 is a reading device that reads a code, which will be described later. For example, the reading unit 56 is a camera, a scanner, a barcode reader, a two-dimensional code reader, or a reader / writer.

[0016] The programs stored in the storage units 12, 22, 32, 42, and 52 may be supplied to the ID server 10, the payment server 20, the mobile terminal 30, the wearable device 40, or the store terminal 50 via the network N. Also, at least one of a reading unit (e.g., a memory card slot) that reads a computer-readable information storage medium and an input / output unit (e.g., a USB port) that inputs and outputs data to and from an external device may be included in the ID server 10, the payment server 20, the mobile terminal 30, the wearable device 40, or the store terminal 50. For example, a program stored in an information storage medium may be supplied to the ID server 10, the payment server 20, the mobile terminal 30, the wearable device 40, or the store terminal 50 via at least one of the reading unit and the input / output unit.

[0017] Furthermore, the payment system 1 only needs to include at least one computer. The computers included in the payment system 1 are not limited to the example in FIG. 1 . For example, the payment system 1 may include only the ID server 10 and the payment server 20. In this case, they exist outside the mobile terminal 30, the wearable device 40, and the store terminal 50. The payment system 1 may also include only the payment server 20. In this case, the ID server 10, the mobile terminal 30, the wearable device 40, and the store terminal 50 exist outside the payment system 1.

[0018] For example, the payment system 1 may include only the payment server 20, the mobile terminal 30, and the wearable device 40. In this case, the ID server 10 and the store terminal 50 exist outside the payment system 1. The payment system 1 may include only the payment server 20 and the wearable device 40. In this case, the ID server 10, the mobile terminal 30, or the store terminal 50 exist outside the payment system 1. For example, the payment system 1 may include only the payment server 20 and another computer not shown in FIG. 1 .

[0019] [1-2. Overview of the First Embodiment] In the first embodiment, a user can use the payment service from either the mobile terminal 30 or the wearable device 40. The user can use any payment method for the payment service. A payment method is a method used by a user for payment. For example, a payment method may be a credit card, electronic money, an account such as a bank account, points, cryptocurrency, a debit card, a wallet, or other methods. Codes such as barcodes or two-dimensional codes are also methods for payment, and therefore correspond to payment methods. Payment methods can also be called payment methods because they are sometimes used for payments.

[0020] For example, the mobile terminal 30 stores a mobile terminal app that enables the user to use a payment service from the mobile terminal 30. The mobile terminal app is a payment service application developed for the mobile terminal 30. The mobile terminal app may be distributed from a publicly known app store or from the payment service's website. Once the user installs the mobile terminal app on the mobile terminal 30 and registers as a member of the payment service, the user will be able to use the payment service from the mobile terminal app. Once the user has registered as a member and launched the mobile terminal app, the mobile terminal 30 displays the screen of the mobile terminal app on the display unit 35.

[0021] Fig. 2 is a diagram showing an example of a screen displayed on the mobile terminal 30. For example, when a mobile terminal app is launched, the mobile terminal 30 displays a code screen SC30 on the display unit 35, as shown on the left side of Fig. 2, which includes a barcode C300A generated based on a code ID that can temporarily identify a user and a two-dimensional code C300B generated based on the code ID. The code screen SC30 may display only either the barcode C300A or the two-dimensional code C300B. Hereinafter, when there is no need to distinguish between the barcode C300A and the two-dimensional code C300B, they will be referred to as code C300.

[0022] For example, when the code C300 is read by the reader 56 of the store terminal 50, the payment to the affiliated store is executed based on the code ID obtained from the code C300. The payment flow may be the same as that of known payment services. When the payment is completed, the mobile terminal 30 displays a completion screen SC31 on the display 35, as shown on the right side of Figure 2, indicating that the payment to the affiliated store has been completed.

[0023] It should be noted that the payment methods available to users in the payment service are not limited to having the store terminal 50 read the code C300. Any payment method may be used. For example, the payment method may be a type in which a code displayed on the store terminal 50 is read by the mobile terminal 30, a type in which a code posted at an affiliated store is read by the mobile terminal 30, a type that is completed by operating the mobile terminal 30 alone, a type that uses an IC chip in the mobile terminal 30, online payment (for example, account payment using the user's account, or ID payment using the user's ID), carrier payment that is payment by the carrier used by the mobile terminal 30, or any other type.

[0024] For example, the user can change the payment source by selecting button B301. The payment source is the payment method used to make payments to affiliated stores. In the example on the left side of Figure 2, the payment source is the online electronic money "AAA Cash." The user can change the settings for using points in payments by selecting button B302. The user can display at least one of a barcode and a two-dimensional code that serves as a point card by selecting button B303. Details of the point card will be explained in the modified example below.

[0025] For example, the user can synchronize the mobile terminal 30 and the wearable device 40 with each other by selecting button B304. Details of synchronization will be described later. The mobile terminal 30 and the wearable device 40 may be synchronized automatically even if the user does not select button B304. Once synchronization of the mobile terminal 30 and the wearable device 40 is complete, the user will be able to use the payment service from the wearable device 40.

[0026] For example, wearable device 40 stores a wearable device app that enables a user to use a payment service from wearable device 40. The wearable device app is an application for the payment service developed for wearable device 40. The wearable device app may be distributed from a known app store or from the website of the payment service.

[0027] For example, the mobile terminal 30 executes a mobile terminal app and the wearable device 40 executes a wearable device app, thereby synchronizing the mobile terminal 30 and the wearable device 40. When the user installs the wearable device app on the wearable device 40 and synchronizes the mobile terminal 30 and the wearable device 40 with each other, the user becomes able to use the payment service from the wearable device app. In addition to logging in from the mobile terminal app, logging in from the wearable device app may also be required.

[0028] Fig. 3 is a diagram showing an example of a screen displayed on wearable device 40. Fig. 3 shows an example in which wearable device 40 is a smartwatch. For example, when a wearable device app is launched on wearable device 40, wearable device 40 displays, on display unit 45, a launch request screen SC40 requesting the launch of a mobile terminal app, as shown in the upper left of Fig. 3. If the mobile terminal app is already launched, synchronization may start automatically without displaying the launch request screen SC40.

[0029] For example, when a mobile terminal app is launched on the mobile terminal 30, synchronization between the mobile terminal 30 and the wearable device 40 begins. As shown in the upper right of FIG. 3, the wearable device 40 displays a synchronization screen SC41 indicating that synchronization is in progress on the display unit 45. In this embodiment, an example is given in which a user needs two pieces of authentication information called tokens to use a payment service from the wearable device app, but one or more pieces of authentication information may be required. Details of tokens will be described later. During synchronization, other processes besides issuing tokens may be performed.

[0030] For example, when synchronization between the mobile terminal 30 and the wearable device 40 is completed, as shown in the middle right of Fig. 3, the wearable device 40 communicates with the payment server 20 and displays a code screen SC42 including a barcode C420A generated based on the code ID on the display unit 45. The barcode C420A may be the same as the barcode C300A, or at least a part of it may be different from the barcode C300A. For example, the barcode C420A may be different from the barcode C300A in the type, orientation, size, or a combination thereof.

[0031] For example, when the user taps the wearable device 40 while the barcode C420A is displayed, the wearable device 40 displays a code screen SC42 including a two-dimensional code C420B generated based on the code ID on the display unit 45, as shown in the middle left of Fig. 3. The wearable device 40 may obtain information necessary for displaying the two-dimensional code C420B from the payment server 20 after the tap, or may have already obtained the information from the payment server 20 before the tap.

[0032] For example, two-dimensional code C420B may be the same as two-dimensional code C300B, or at least a part of it may differ from two-dimensional code C300B. Two-dimensional code C420B may differ from two-dimensional code C300B in the type, orientation, size, or a combination of these. Hereinafter, when there is no need to distinguish between barcode C420A and two-dimensional code C420B, they will be referred to as code C420.

[0033] For example, when the store terminal 50 reads the code C420, the payment to the affiliated store is executed based on the code ID acquired from the code C420. The payment flow may be the same as the flow when the payment is executed from a mobile device app. When the payment is completed, the wearable device 40 displays a completion screen SC43 on the display unit 45, as shown in the bottom row of FIG. 3, indicating that the payment to the affiliated store has been completed.

[0034] In the first embodiment, the wearable device 40, not the mobile terminal 30, mainly transmits a code display request for displaying the code C420 to the payment server 20. The code display request is data in a predetermined format for requesting display of the code C420. The code display request may be in any format, for example, a format according to the API specifications of the payment server 20. The code display request may include any information. An example of the information that can be included in the code display request will be described later.

[0035] As described above, in the payment system 1 of the first embodiment, the wearable device 40 takes the lead in sending a code display request to the payment server 20, which reduces the amount of processing that the mobile terminal 30 must perform to display the code C420, thereby reducing the processing load on the mobile terminal 30. This prevents failure to display the code C420 due to an increased processing load on the mobile terminal 30, thereby improving user convenience. The payment system 1 will be described in detail below.

[0036] [1-3. Functions realized by the payment system of the first embodiment] 4 is a diagram showing an example of functions realized by the payment system 1 of the first embodiment. The units realized by the payment system 1 can be configured as a single device or as more finely divided devices.

[0037] [1-3-1. Functions realized by the ID server] For example, the ID server 10 includes a data storage unit 100, a first token request receiving unit 101, a first token issuing unit 102, a first token transmitting unit 103, a first token receiving unit 104, and a first token verifying unit 105. The data storage unit 100 is realized by the storage unit 12. Each of the first token request receiving unit 101, the first token issuing unit 102, the first token transmitting unit 103, the first token receiving unit 104, and the first token verifying unit 105 is realized by the control unit 11.

[0038] [Data storage section] The data storage unit 100 stores various information about each of a plurality of users. For example, the data storage unit 100 stores an ID database DB1.

[0039] FIG. 5 is a diagram showing an example of ID database DB1. ID database DB1 is a database that stores various information about each of multiple users. For example, ID database DB1 stores user IDs, passwords, user basic information, first tokens, and expiration dates of the first tokens. ID database DB1 may also store other information. For example, ID database DB1 may store not only information about users in the payment service, but also information about users in other services that are linked to the payment service.

[0040] The user ID is an example of user identification information that can identify a user. In addition to the user ID, there may be an account for logging in to the payment service. The login account may be freely changeable by the user. The login account is also an example of user identification information. For example, the user identification information may be information such as the user's email address, phone number, a mobile terminal ID that can identify the mobile terminal 30, a wearable device ID that can identify the wearable device 40, a random symbol issued by the ID server 10, or other information.

[0041] The code ID is also an ID that can identify a user, and is therefore an example of user identification information. The code ID is updated each time the codes C300 and C420 are displayed. The code ID for the barcode C300A and the code ID for the two-dimensional code C300B may be the same as or different from each other. The code ID for the barcode C420A and the code ID for the two-dimensional code C420B may be the same as or different from each other.

[0042] Furthermore, the user identification information may be information other than the user ID, login account, and code ID. The code ID may be stored in the ID database DB1. The password is information that is confirmed at the time of login. The user basic information is basic information about the user. For example, the user basic information indicates the user's name, gender, date of birth, email address, telephone number, address, or occupation. If there are other services other than the payment service, the user basic information may indicate the service that the user is using. The user ID may be common to the payment service and other services.

[0043] The first token is information used for authentication in the payment service. For example, the first token may be letters, numbers, symbols, or a combination thereof. The first token may include an encrypted (hashed) user ID, or may not include an encrypted user ID. The expiration date of the first token is the date and time when the validity period of the first token ends. For example, the expiration date of the first token is a predetermined time (e.g., 60 days) after the first token is issued. The first token may not have a specific expiration date. The first token may be valid semi-permanently unless a user instructs renewal. The first token may be renewed before its expiration date. The first token may be renewed when some process (e.g., any step in FIG. 7 or FIG. 8) is executed in the payment system 1.

[0044] In the first embodiment, an example is given in which the first token is used to issue a second token, which will be described later. That is, an example is given in which the first token is a token for proving the authority to issue the second token. The first token may also be used for purposes other than issuing the second token. For example, if the second token is not used by the user for a payment service from the wearable device 40, the first token may be used for authentication for the user for a payment service from the wearable device 40. In this case, the second token may not exist. A mode in which the second token does not exist is also within the scope of the present disclosure. For example, the first token may be used to communicate with the payment server 20. The first token may also be called an exchange token for using a specific function or information of the payment system 1.

[0045] The data stored in the data storage unit 100 is not limited to the ID database DB1. The data storage unit 100 may store any data necessary for managing various pieces of information related to users. For example, the data storage unit 100 may store a program that indicates a process for verifying the first token. If the first token is not stored in the ID server 10, the data storage unit 100 may store data other than the program necessary for verifying the first token. These programs and data may be similar to programs and data employed in known tokens.

[0046] [First token request receiver] The first token request receiving unit 101 receives a first token request from a computer that transmits the first token request regarding the issuance of a first token. The first token request is data in a predetermined format for requesting the issuance of a first token. The first token request may be in any format, for example, a format according to the specifications of the API of the ID server 10. The first token request may include any information. For example, the first token request may include a mobile terminal ID of the mobile terminal 30, a wearable device ID of the wearable device, a user ID, an encrypted user ID, other information by which the user ID can be searched, a login account, other information by which the account can be searched, or other information.

[0047] For example, the first token request receiving unit 101 receives the first token request directly or indirectly from a computer that transmits the first token request. "Directly" means that no other computer is involved. "Indirectly" means that another computer is involved. The first embodiment takes as an example a case where the mobile terminal 30 transmits the first token request. Therefore, the first token request receiving unit 101 receives the first token request directly or indirectly from the mobile terminal 30. For example, when the payment server 20 transfers the first token request from the mobile terminal 30 to the ID server 10, the first token request receiving unit 101 receives the first token request indirectly from the mobile terminal 30.

[0048] Note that the first token request may be transmitted from a computer other than the mobile terminal 30. For example, the wearable device 40 may transmit the first token request. In this case, the first token request receiving unit 101 receives the first token request directly or indirectly from the wearable device 40. Alternatively, for example, the first token request receiving unit 101 may receive the first token request from a computer other than the mobile terminal 30 and the wearable device 40.

[0049] [1st Token Issuance Department] The first token issuing unit 102 issues a first token. The first token issuing unit 102 issues the first token based on a predetermined token issuing method. It is assumed that the program and data necessary for issuing the first token are stored in the data storage unit 100. The first token issuing unit 102 issues the first token based on the program and data. The token issuing method may be a known method. For example, the token issuing method may be an issuing method adopted in OAuth2.0 or JWT (JSON Web Token). The token issuing method may be a method of generating random symbols, characters, numbers, or a combination thereof.

[0050] For example, when the first token issuing unit 102 issues a first token for a certain user, it stores the first token in the ID database DB1 in association with the user ID of the user. The user ID may be included in the first token request. In this case, the first token issuing unit 102 identifies the user ID from the first token request. Instead of the user ID, other information that can search for the user ID (for example, a temporarily valid ID) may be included in the first token request. In this case, the first token issuing unit 102 identifies the user ID from the other information. It is assumed that the relationship between the other information and the user ID is defined in the ID database DB1 or another database.

[0051] If an expiration date is set for the first token, the first token issuing unit 102 determines the expiration date of the first token. For example, the first token issuing unit 102 determines a time a predetermined time after the current time as the expiration date of the first token. The first token issuing unit 102 stores the expiration date in the ID database DB1 in association with the first token. For example, the first token issuing unit 102 may encrypt a user ID identified from the first token request and include the encrypted user ID in the first token. In this case, the first token issuing unit 102 may issue the encrypted user ID as is as the first token, or may issue a first token including the encrypted user ID and another portion (for example, a portion such as a random symbol or a portion of hashed user basic information). The encryption may be performed using a known encryption algorithm (for example, RSA encryption).

[0052] [First token transmitter] The first token transmitting unit 103 transmits the first token to the computer that transmitted the first token request. For example, the first token transmitting unit 103 transmits the first token directly or indirectly to the computer that transmitted the first token request. The meanings of the terms "directly" and "indirectly" are as described above. In the first embodiment, the mobile terminal 30 transmits the first token request, and therefore the first token transmitting unit 103 transmits the first token to the mobile terminal 30. When a computer other than the mobile terminal 30 transmits the first token request, the first token transmitting unit 103 only needs to transmit the first token to the other computer.

[0053] If an expiration date is set for the first token, the first token transmitting unit 103 may transmit the first token and the expiration date to the computer that transmitted the first token request. The first token transmitting unit 103 may not transmit the expiration date to the computer that transmitted the first token request. In this case, the expiration date of the first token is managed by the ID server 10. Whether the first token has an expiration date is determined by the ID server 10.

[0054] [First token receiver] The functions of the ID server 10 described below are functions related to verifying the first token. The first token receiving unit 104 receives the first token from the computer that transmits the first token. For example, the first token receiving unit 104 receives the first token directly or indirectly from the computer that transmits the first token. The meanings of the terms "directly" and "indirectly" are as described above. In the first embodiment, the wearable device 40 transmits the first token, so the first token receiving unit 104 receives the first token from the wearable device 40. Furthermore, the wearable device 40 transmits the first token after synchronizing with the mobile terminal 30, so the first token receiving unit 104 receives the first token from the wearable device 40 that has synchronized with the mobile terminal 30.

[0055] In the first embodiment, the wearable device 40 transmits the first token to the payment server 20, and the payment server 20 requests the ID server 10 to verify the first token. Therefore, the first token receiving unit 104 receives the first token indirectly from the wearable device 40 via the payment server 20. That is, the first token receiving unit 104 receives the first token transferred by the payment server 20. Note that the first token receiving unit 104 may receive the first token from a computer other than the wearable device 40. For example, when the mobile terminal 30 transmits the first token, the first token receiving unit 104 may receive the first token from the mobile terminal 30.

[0056] [First Token Verification Unit] The first token verification unit 105 verifies the first token received from the wearable device 40. Verification of the first token means confirming the validity of the first token. The first token verification unit 105 verifies the first token based on a predetermined token verification method. The token verification method may be a known method. For example, the token verification method may be a verification method adopted in OAuth 2.0 or JWT.

[0057] For example, when verifying a first token of a certain user, the first token verification unit 105 determines whether the first token received by the first token reception unit 104 is stored in the ID database DB1 in association with the user ID of the user. If the first token verification unit 105 determines that the first token is not stored in the ID database DB1 in association with the user ID, the first token verification unit 105 determines that the first token is invalid. If the first token verification unit 105 determines that the first token is stored in the ID database DB1 in association with the user ID, the first token verification unit 105 determines that the first token is valid.

[0058] The user ID may be included in the first token request. In this case, the first token verifying unit 105 identifies the user ID from the first token. If the user ID is encrypted and included in the first token, the first token verifying unit 105 decrypts the encrypted user ID included in the first token. The decryption may be performed using a known decryption algorithm (e.g., RSA encryption). Instead of the user ID, other information from which the user ID can be searched (e.g., an ID that can temporarily identify a user) may be included in the first token. In this case, the first token verifying unit 105 identifies the user ID from the other information. The relationship between the other information and the user ID is defined in the ID database DB1 or another database. The user ID or the other information may be data separate from the first token. In this case, the first token receiving unit 104 may receive the user ID or the other information along with the first token.

[0059] Furthermore, if an expiration date is set for the first token, the first token verification unit 105 may determine whether the first token received from the wearable device 40 is within the expiration date. The first token verification unit 105 may make this determination based on the expiration date stored in the ID database DB1, or may make this determination based on the expiration date received together with the first token. The first token verification unit 105 determines that the first token is not valid if the first token is not within the expiration date. The first token verification unit 105 may verify the first token by determining whether the first token is stored in the ID database DB1, regardless of the user ID in particular.

[0060] [1-3-2. Functions realized by the payment server] For example, the payment server 20 includes a data storage unit 200, a second token request receiving unit 201, a second token issuing unit 202, a second token transmitting unit 203, a code display request receiving unit 204, a second token verifying unit 205, a code display information transmitting unit 206, and a payment executing unit 207. The data storage unit 200 is realized by the memory unit 22. Each of the second token request receiving unit 201, the second token issuing unit 202, the second token transmitting unit 203, the code display request receiving unit 204, the second token verifying unit 205, the code display information transmitting unit 206, and the payment executing unit 207 is realized by the control unit 21.

[0061] [Data storage section] The data storage unit 200 stores data necessary for the payment service. For example, the data storage unit 200 stores a payment database DB2.

[0062] 6 is a diagram showing an example of payment database DB2. Payment database DB2 is a database that stores various information for each of multiple users. For example, payment database DB2 stores user IDs, passwords, code IDs, payment method information, setting information, second tokens, and expiration dates of second tokens. Payment database DB2 may also store other information. For example, payment database DB2 may store usage history information related to the usage history of payment services, mobile terminal IDs, wearable device IDs, or first tokens.

[0063] In the first embodiment, a case will be described in which the user ID of a certain user stored in the payment database DB2 is the same as the user ID of the user stored in the ID database DB1, but these user IDs may be different from each other. When these user IDs are different from each other, a relational database indicating the relationship between the user ID stored in the payment database DB2 and the user ID stored in the ID database DB1 is assumed to be stored in the data storage unit 200. The relational database may be stored in the data storage unit 100 of the ID server 10, in a computer other than the ID server 10 and the payment server 20, or in an external information storage medium.

[0064] Payment method information is information that allows a user to identify payment methods that can be used for payment services. The payment methods indicated by the payment method information can be considered as payment methods that are candidates for the payment source. For example, payment method information is information such as a credit card number, electronic money number, bank account number, or point card number. When a card corresponds to the payment method, the payment method information may also include information that allows the identification of the card company that issued the card. The payment methods indicated in the payment method information may be used not only as the payment source but also for other purposes, such as the source of electronic money recharge.

[0065] The setting information is information related to settings specified by the user. For example, the setting information indicates the payment source specified by the user. In the example of FIG. 2, since the user has specified electronic money as the payment source, the setting information indicates that the payment source is electronic money. If the user has specified another payment method such as a credit card as the payment source, the setting information indicates that the payment source is a credit card. The setting information may also indicate settings other than the payment source. For example, the setting information may indicate the setting of the charge source, which is the payment method the user uses to charge electronic money, the setting of whether or not points are applied, the setting of the payment method that the user prefers to use among multiple payment methods (for example, the setting of which of electronic money and points the user prefers to use), the balance of electronic money, the number of points, their expiration dates, the upper limit of the payment method, or other settings.

[0066] In the first embodiment, an example is given of a case where, when a user performs an operation to change the setting information from a mobile terminal app on the mobile terminal 30 (for example, selecting button B304), the setting information associated with the user ID of the user is updated. Furthermore, an example is given of a case where the user cannot change the setting information from the wearable device 40. Note that the user may be able to change the setting information from the wearable device 40. In this case, the payment server 20 may obtain the changes to the setting information specified by the user from the wearable device 40 and change the setting information associated with the user ID of the user.

[0067] The second token is information used for authentication in the payment service. For example, the second token may be letters, numbers, symbols, or a combination thereof. The second token may include an encrypted (hashed) user ID, or may not include an encrypted user ID. The expiration date of the second token is the date and time when the validity period of the second token ends. For example, the expiration date of the second token is a predetermined time (e.g., 60 days) after the second token is issued. The second token may not have a specific expiration date. The second token may be valid semi-permanently unless a user instructs updating. The second token may be updated before its expiration. The second token may be updated when some process (e.g., any step in FIG. 7 or FIG. 8) is performed in the payment system 1. The second token may also be updated when the first token is updated. Conversely, the first token may also be updated when the second token is updated.

[0068] In the first embodiment, an example is given of a case where a second token is issued on the condition that the wearable device 40 possesses a valid first token. Furthermore, an example is given of a case where the second token is used by the wearable device 40 to communicate with the payment server 20. For example, the second token may also be called an access token for the wearable device 40 to access the payment server 20. The second token may be used for purposes other than accessing the payment server 20. For example, the second token may be used for authentication to access a computer other than the payment server 20 (for example, a point server 60 in a modified example described below). The first token may not be particularly required for issuing the second token. In this case, the first token may not exist. A mode in which the first token does not exist is also within the scope of the present disclosure. For example, the second token may be issued after authentication is performed based on authentication information stored in the wearable device 40 or a login account and password entered by the user into the wearable device 40.

[0069] The data stored in the data storage unit 100 is not limited to the payment database DB2. The data storage unit 100 may store any data necessary for the payment service. For example, the data storage unit 100 may store data for various screens displayed on a mobile terminal app and a wearable device app. For example, the data storage unit 100 may store a program that indicates processing for verifying the second token. If the second token is not stored in the payment server 20, the data storage unit 100 may store data other than the program necessary for verifying the second token. These programs and data may be similar to programs and data employed in known tokens.

[0070] [Second token request receiver] The second token request receiving unit 201 receives a second token request from a computer that transmits the second token request regarding the issuance of a second token. The second token request is data in a predetermined format for requesting the issuance of a second token. The second token request may be in any format, for example, a format that conforms to the specifications of the API of the payment server 20. The second token request may include any information. For example, the second token request may include the first token, the mobile terminal ID of the mobile terminal 30, the wearable device ID of the wearable device, a user ID, an encrypted user ID, other information that can be used to search for the user ID, a login account, other information that can be used to search for the account, or other information.

[0071] For example, the second token request receiving unit 201 receives the second token request directly or indirectly from a computer that transmits the second token request. The meanings of "directly" and "indirectly" are as described above. In the first embodiment, an example is taken of a case where the wearable device 40 transmits the second token request. Therefore, the second token request receiving unit 201 receives the second token request directly or indirectly from the wearable device 40. For example, when the mobile terminal 30 transfers the second token request from the wearable device 40 to the payment server 20, the second token request receiving unit 201 receives the second token request indirectly from the wearable device 40.

[0072] Note that the second token request may be transmitted from a computer other than the wearable device 40. For example, the mobile terminal 30 may transmit the second token request. In this case, the second token request receiving unit 201 receives the second token request directly or indirectly from the mobile terminal 30. Alternatively, for example, the second token request receiving unit 201 may receive the second token request from a computer other than the mobile terminal 30 and the wearable device 40.

[0073] [Second Token Issuance Department] The second token issuing unit 202 issues a second token. The second token issuing unit 202 issues the second token based on a predetermined token issuing method. It is assumed that the program and data necessary for issuing the second token are stored in the data storage unit 200. The second token issuing unit 202 issues the second token based on the program and data. The token issuing method may be a known method. For example, the token issuing method may be an issuing method adopted in OAuth2.0 or JWT. The token issuing method may be a method of generating random symbols, letters, numbers, or a combination thereof. Since the second token is issued differently from the first token, the token issuing method for the first token and the token issuing method for the second token may be different from each other.

[0074] For example, when the second token issuing unit 202 issues a second token for a user, it stores the second token in the payment database DB2 in association with the user ID of the user. The user ID may be included in the second token request. In this case, the second token issuing unit 202 identifies the user ID from the second token request. Instead of the user ID, other information (e.g., a temporarily valid ID) that can be used to search for the user ID may be included in the second token request. In this case, the second token issuing unit 202 identifies the user ID from the other information. The relationship between the other information and the user ID is assumed to be defined in the payment database DB2 or another database.

[0075] If an expiration date is set for the second token, the second token issuing unit 202 determines the expiration date of the second token. For example, the second token issuing unit 202 determines a time a predetermined time after the current time as the expiration date of the second token. The second token issuing unit 202 stores the expiration date in the ID database DB1 in association with the second token. For example, the second token issuing unit 202 may encrypt a user ID identified from the second token request and include it in the second token. In this case, the second token issuing unit 202 may issue the encrypted user ID as is as the second token, or may issue a second token including the encrypted user ID and other portions (for example, a portion such as a random symbol or a portion of hashed user basic information). The encryption may be performed using a known encryption algorithm (for example, RSA encryption).

[0076] [Second token sending unit] The second token transmitting unit 203 transmits the second token to the computer that transmitted the second token request. For example, the second token transmitting unit 203 transmits the second token directly or indirectly to the computer that transmitted the second token request. The meanings of the terms "directly" and "indirectly" are as described above. In the first embodiment, the wearable device 40 transmits the second token request, and therefore the second token transmitting unit 203 transmits the second token to the wearable device 40. When a computer other than the wearable device 40 transmits the second token request, the second token transmitting unit 203 only needs to transmit the second token request to the other computer.

[0077] If an expiration date is set for the second token, the second token transmitting unit 203 may transmit the second token and the expiration date to the computer that transmitted the second token request. The second token transmitting unit 203 does not need to transmit the expiration date to the computer that transmitted the second token request. In this case, the expiration date of the second token is managed by the payment server 20. Whether the second token has an expiration date is determined by the payment server 20.

[0078] [Code display request receiver] The functions of the payment server 20 described below are functions related to verifying the second token and displaying the code C420 on the wearable device 40. Displaying the code C300 on the mobile terminal 30 may be achieved by a known function.

[0079] The code display request receiving unit 204 receives a code display request for displaying a code used in a payment service from a wearable device 40 connectable to a user's mobile terminal 30 in the payment service. A wearable device 40 connectable to a mobile terminal 30 is a wearable device 40 that can communicate wirelessly with the mobile terminal 30. The wireless communication may be performed using any communication standard such as Bluetooth (registered trademark) or infrared communication. The mobile terminal 30 and the wearable device 40 are connected by pairing. The pairing process may be a known process. For example, the mobile terminal 30 and the wearable device 40 authenticate each other through pairing.

[0080] For example, the code display request receiving unit 204 receives a code display request directly or indirectly from the wearable device 40. The meanings of the words "directly" and "indirectly" are as described above. In the first embodiment, when both the mobile terminal app and the wearable device app are launched, the mobile terminal 30 and the wearable device 40 are synchronized. The code display request receiving unit 204 receives a code display request from the wearable device 40 that has synchronized with the mobile terminal 30. Since the wearable device 40 transmits a code display request after synchronizing with the mobile terminal 30, the code display request receiving unit 204 receives a code display request from the wearable device 40 after the wearable device 40 has synchronized with the mobile terminal 30.

[0081] If the wearable device 40 stores the second token, the wearable device 40 may transmit the code display request without particularly synchronizing with the mobile terminal 30. That is, the wearable device 40 may transmit the code display request before synchronizing with the mobile terminal 30. In this case, the wearable device 40 may determine whether or not the second token is stored in the data storage unit 400 described below, and if it is determined that the second token is stored, may transmit the code display request without synchronizing with the mobile terminal 30.

[0082] In the first embodiment, the code display request includes the second token, and therefore the code display request receiving unit 204 receives the code display request including the second token from the wearable device 40. Note that the code display request does not have to include the second token. For example, the second token may be data separate from the code display request. If the wearable device 40 can be identified by other information, such as a session ID, instead of the second token, the code display request receiving unit 204 may receive the code display request including the other information from the wearable device 40.

[0083] In the first embodiment, the code display request receiving unit 204 receives a code display request including a mobile terminal ID and a wearable device ID from the wearable device 40. The mobile terminal ID is an example of mobile terminal identification information. Therefore, the description of "mobile terminal ID" can be replaced with "mobile terminal identification information." The mobile terminal identification information may be information other than the mobile terminal ID. For example, the mobile terminal identification information may be information such as a phone number in a SIM card, individual identification information of the mobile terminal 30, the MAC address of the mobile terminal 30, identification information uniquely determined by a company operating a payment service, or other information.

[0084] The wearable device ID is an example of wearable device identification information. Therefore, the term "wearable device ID" can be read as "wearable device identification information." The wearable device identification information may be information other than the wearable device ID. For example, the wearable device identification information may be information such as a phone number stored in a SIM card, individual identification information of wearable device 40, the MAC address of wearable device 40, identification information uniquely determined by a company that operates a payment service, or other information.

[0085] The code display request may include any information. For example, the code display request may include a first token. The code display request may include a user ID, information that allows the user ID to be searched (e.g., a temporary ID), a login account, information that allows the login account to be searched (e.g., a temporary ID), or other information.

[0086] [Second Token Verification Unit] The second token verification unit 205 verifies the second token received from the wearable device 40. In this embodiment, since the second token is included in the code display request, the second token verification unit 205 verifies the second token included in the code display request. Verification of the second token is to confirm the validity of the second token. The second token verification unit 205 verifies the second token based on a predetermined token verification method. The token verification method may be a known method. For example, the token verification method may be a verification method adopted in OAuth2.0 or JWT.

[0087] For example, when verifying a second token of a certain user, the second token verification unit 205 determines whether the second token received by the second token receiving unit 404 is stored in the payment database DB2 in association with the user ID of the user. If the second token verification unit 205 determines that the second token is not stored in the payment database DB2 in association with the user ID, the second token verification unit 205 determines that the second token is invalid. If the second token verification unit 205 determines that the second token is stored in the payment database DB2 in association with the user ID, the second token verification unit 205 determines that the second token is valid.

[0088] The user ID may be included in the second token request. In this case, the second token verification unit 205 identifies the user ID from the second token. If the user ID is encrypted and included in the second token, the second token verification unit 205 decrypts the encrypted user ID included in the second token. The decryption may be performed using a known decryption algorithm (e.g., RSA encryption). Instead of the user ID, other information from which the user ID can be searched may be included in the second token. In this case, the second token verification unit 205 identifies the user ID from the other information. The relationship between the other information and the user ID is defined in the payment database DB2 or another database. The user ID or the other information may be data separate from the second token. In this case, the code display request receiving unit 204 may receive the user ID or the other information along with the code display request including the second token.

[0089] Furthermore, if an expiration date is set for the second token, the second token verification unit 205 may determine whether the second token received from the wearable device 40 is within the expiration date. The second token verification unit 205 may make this determination based on the expiration date stored in the payment database DB2, or may make this determination based on the expiration date received together with the second token. The second token verification unit 205 determines that the second token is not valid if the second token is not within the expiration date. The second token verification unit 205 may verify the second token by determining whether the second token is stored in the payment database DB2, regardless of the user ID.

[0090] [Code display information transmission section] When a code display request is received, the code display information sending unit 206 sends code display information related to the display of the code C420 to the wearable device 40. The code display information is information used to display the code C420. In the first embodiment, a code ID corresponds to the code display information, but the code display information may include information other than the code ID (for example, a URL). The code display information may be image data of the code C420.

[0091] In the first embodiment, there are two types of code C420: a barcode C420A and a two-dimensional code C420B. The code display information of the barcode C420A and the code display information of the two-dimensional code C420B may be separate data or may be the same data. For example, the code display information transmitter 206 may transmit to the wearable device 40 the code display information of the barcode C420A and the code display information of the two-dimensional code C420B, respectively, or may transmit code display information indicating the barcode C420A and the two-dimensional code C420B.

[0092] For example, the code display information transmitting unit 206 issues a code ID based on a predetermined ID issuance rule. The ID issuance rule may be any rule. For example, the ID issuance rule may be a rule that indicates that a code ID is to be issued so that it is made up of random letters, numbers, symbols, or a combination thereof. The code display information transmitting unit 206 issues a code ID so that it is different from other code IDs. If an expiration date is set for the code ID, the code display information transmitting unit 206 issues a code ID so that it is different from other code IDs within the expiration date.

[0093] In this embodiment, the code display information is transmitted when the first token is verified, and therefore the code display information transmitting unit 206 transmits the code display information to the wearable device 40 when the first token is verified. The code display information transmitting unit 206 transmits the code display information to the wearable device 40 on the condition that the first token is verified. Here, the first token being verified means that the legitimacy of the first token is confirmed. Note that when the first token is not used, the code display information transmitting unit 206 may transmit the code display information to the wearable device 40 based on other conditions.

[0094] In this embodiment, the code display information transmitting unit 206 transmits the code display information to the wearable device 40 when the second token included in the code display request is verified. The code display information transmitting unit 206 transmits the code display information to the wearable device 40 on the condition that the second token is verified. Here, the second token being verified means that the legitimacy of the second token is confirmed. Note that when the second token is not used, the code display information transmitting unit 206 may transmit the code display information to the wearable device 40 on the condition that the first token is verified.

[0095] [Payment Execution Department] The payment execution unit 207 executes the payment when the code C420 is read. As described above, the payment processing may be the same as publicly known processing. For example, the payment execution unit 207 acquires the code ID read from the code C420 from the store terminal 50. The payment execution unit 207 determines whether the code ID acquired from the store terminal 50 is stored in the payment database DB2. If the payment execution unit 207 determines that the code ID acquired from the store terminal 50 is stored in the payment database DB2, it executes the payment based on the payment method information associated with the code ID. The payment execution unit 207 transmits the result of the payment execution to the store terminal 50.

[0096] [1-3-3. Functions realized on mobile devices] For example, the mobile terminal 30 includes a data storage unit 300, a synchronization unit 301, a first token request transmission unit 302, a first token reception unit 303, a first token transmission unit 304, a transfer unit 305, and a display control unit 306. The data storage unit 300 is realized by the storage unit 32. The synchronization unit 301, the first token request transmission unit 302, the first token reception unit 303, the first token transmission unit 304, the transfer unit 305, and the display control unit 306 are each realized by the control unit 31.

[0097] [Data storage section] The data storage unit 300 stores data necessary for the user to use the payment service. For example, the data storage unit 300 stores a mobile device app. If the user uses the payment service from a browser rather than a mobile device app, the data storage unit 300 stores the browser. The data storage unit 300 may store at least one of a first token and a second token. The data storage unit 300 may store the first token but not the second token. Conversely, the data storage unit 300 may store the second token but not the first token. The data storage unit 300 may store a mobile device ID capable of identifying the mobile device 30. The data storage unit 300 may store a wearable device ID acquired from the wearable device 40. The data storage unit 300 may store a user ID, information capable of searching for the user ID, the user's login account, information capable of searching for the login account, or other information.

[0098] [Synchronization section] The synchronization unit 301 synchronizes the mobile terminal 30 and the wearable device 40. In the first embodiment, the synchronization of the mobile terminal 30 and the wearable device 40 is a process different from the pairing of the mobile terminal 30 and the wearable device 40. The synchronization of the mobile terminal 30 and the wearable device 40 is a process executed by the mobile terminal app and the wearable device app after these apps are launched. In the synchronization of the mobile terminal 30 and the wearable device 40, information required for the user to use the payment service from the wearable device 40 is exchanged.

[0099] On the other hand, pairing of the mobile terminal 30 and the wearable device 40 is a process executed by another program, regardless of the mobile terminal app or the wearable device app. For example, the other program may be an operating system or firmware. Pairing of the mobile terminal 30 and the wearable device 40 is executed based on a procedure defined by a communication protocol of a wireless communication standard. Synchronization of the mobile terminal 30 and the wearable device 40 is executed based on a procedure defined by the payment service, not based on the communication protocol of a wireless communication standard.

[0100] For example, synchronization unit 301 transmits a mobile terminal ID to wearable device 40. Synchronization unit 301 may transmit other information (e.g., information for authentication in a payment service) other than the mobile terminal ID to wearable device 40. The other information may be stored in data storage unit 300, or may be acquired by mobile terminal 30 from another computer (e.g., payment server 20). If the other information is information for authentication in a payment service, payment server 20 may be requested to confirm its validity. For example, if a first token has already been stored in data storage unit 300, synchronization unit 301 may transmit the first token stored in data storage unit 300 to wearable device 40.

[0101] For example, synchronization unit 301 receives a wearable device ID from wearable device 40. Synchronization unit 301 may receive other information (e.g., information for authentication in a payment service) other than the wearable device ID from wearable device 40. The other information may be stored in data storage unit 400, or may be acquired by wearable device 40 from another computer (e.g., payment server 20). If the other information is information for authentication in a payment service, payment server 20 may be requested to confirm its validity. For example, if the second token is already stored in data storage unit 400, synchronization unit 301 may receive the second token stored in data storage unit 400 from wearable device 40.

[0102] [First token request sending unit] The first token request sending unit 302 sends the first token request directly or indirectly to the computer that issues the first token. The meanings of the words "directly" and "indirectly" are as described above. In the first embodiment, the ID server 10 issues the first token, so the first token request sending unit 302 sends the first token request to the ID server 10. If a computer other than the ID server 10 issues the first token, the first token request sending unit 302 only needs to send the first token request to the other computer. If the first token is already stored in the data storage unit 300, the first token request sending unit 302 does not need to send the first token request.

[0103] [First token receiver] The first token receiving unit 303 receives the first token from the computer that issues the first token. For example, the first token receiving unit 303 receives the first token directly or indirectly from the computer that issues the first token. The meanings of the terms "directly" and "indirectly" are as described above. In the first embodiment, the ID server 10 issues the first token, so the first token receiving unit 303 receives the first token from the ID server 10. That is, the first token receiving unit 303 receives the first token from the first token transmitting unit 304 of the ID server 10.

[0104] [First token transmitter] The first token transmitting unit 304 transmits the first token to the wearable device 40. For example, the first token transmitting unit 304 transmits the first token directly or indirectly to the wearable device 40. The meanings of the terms "directly" and "indirectly" are as described above. When the first token receiving unit 303 receives the first token, the first token transmitting unit 304 transmits the first token to the wearable device 40. When the first token is already stored in the data storage unit 300, the first token transmitting unit 304 transmits the first token to the wearable device 40.

[0105] [Transfer Section] The forwarding unit 305 forwards any information to the wearable device 40. The forwarding unit 305 forwards any information to a computer with which the wearable device 40 communicates. The forwarding unit 305 may cause the mobile terminal 30 to function as a hub. The processing of the forwarding unit 305 may be executed by a mobile terminal app or by a program other than a mobile terminal app. The forwarding unit 305 forwards the information to be transferred as is without any particular processing. The forwarding unit 305 may forward information received from the wearable device 40 to the ID server 10, the payment server 20, or another computer. For example, if the wearable device 40 can be connected to a public communication line, the wearable device 40 may transmit the information to be transmitted to the ID server 10, the payment server 20, or another computer without the mobile terminal 30 acting as an intermediary. If the wearable device 40 is not connectable to a public communication line but can connect to a communication device such as a wireless LAN, the wearable device 40 may transmit the information to be sent to the ID server 10, the payment server 20, or another computer without using the mobile terminal 30 as an intermediary.

[0106] [Display control section] The display control unit 306 displays various screens on the display unit 35. For example, the display control unit 306 displays each of the code screen SC30 and the completion screen SC31 on the display unit 35. The display control unit 306 communicates with the ID server 10, the payment server 20, or another computer, receives data necessary to display these screens, and displays these screens on the display unit 35.

[0107] [1-3-4. Functions realized by wearable devices] For example, the wearable device 40 includes a data storage unit 400, a synchronization unit 401, a first token reception unit 402, a second token request transmission unit 403, a second token reception unit 404, a code display request transmission unit 405, a code display information reception unit 406, and a display control unit 407. The data storage unit 400 is realized by the storage unit 42. The synchronization unit 401, the first token reception unit 402, the second token request transmission unit 403, the second token reception unit 404, the code display request transmission unit 405, the code display information reception unit 406, and the display control unit 407 are each realized by the control unit 41.

[0108] [Data storage section] The data storage unit 400 stores data necessary for the user to use the payment service. For example, the data storage unit 400 stores a wearable device app. If the user uses the payment service from a browser rather than the wearable device app, the data storage unit 400 stores the browser. The data storage unit 400 may store a wearable device ID capable of identifying the wearable device 40. If the wearable device 40 receives a mobile terminal ID from the mobile terminal 30, the data storage unit 400 may store the mobile terminal ID. The data storage unit 400 may store the first token, the second token, the mobile terminal ID, and the wearable device ID. The data storage unit 400 may store a user ID, information capable of searching for the user ID, the user's login account, information capable of searching for the login account, or other information.

[0109] [Synchronization section] The synchronization unit 401 synchronizes the mobile terminal 30 and the wearable device 40. For example, the synchronization unit 401 transmits a wearable device ID to the mobile terminal 30. The synchronization unit 401 may transmit other information (e.g., information for authentication in a payment service) other than the wearable device ID to the mobile terminal 30. The other information may be stored in the data storage unit 400, or may be acquired by the wearable device 40 from another computer (e.g., the payment server 20). If the other information is information for authentication in a payment service, the payment server 20 may be requested to confirm its validity.

[0110] For example, if the first token is already stored in the data storage unit 400, the synchronization unit 401 may transmit the first token stored in the data storage unit 400 to the mobile terminal 30. If the second token is already stored in the data storage unit 400, the synchronization unit 401 may transmit the second token stored in the data storage unit 400 to the mobile terminal 30.

[0111] For example, the synchronization unit 401 receives a mobile terminal ID from the mobile terminal 30. The synchronization unit 401 may receive other information (e.g., information for authentication in a payment service) other than the mobile terminal ID from the mobile terminal 30. The other information may be stored in the data storage unit 400, or the wearable device 40 may acquire the other information from another computer (e.g., the payment server 20). If the other information is information for authentication in a payment service, the payment server 20 may be requested to confirm its validity. For example, if the first token has already been stored in the data storage unit 300, the synchronization unit 401 may receive the first token stored in the data storage unit 300 from the mobile terminal 30.

[0112] [First token receiver] The first token receiving unit 402 receives the first token from the computer that transmits the first token. In the first embodiment, the ID server 10 transmits the first token to the mobile terminal 30, and the mobile terminal 30 transmits the first token to the ID server 10. Therefore, the first token receiving unit 402 receives the first token indirectly from the ID server 10 via the mobile terminal 30. That is, the first token receiving unit 402 receives the first token transferred by the mobile terminal 30 from which the ID server 10 received the first token.

[0113] In the first embodiment, when synchronizing with the mobile terminal 30, the first token receiving unit 402 receives the first token from the mobile terminal 30. Note that the first token receiving unit 402 may receive the first token from a computer other than the mobile terminal 30. For example, when the payment server 20 transmits the first token, the first token receiving unit 402 may receive the first token from the payment server 20.

[0114] [Second token request sending unit] The second token request sending unit 403 sends the second token request directly or indirectly to the computer that issues the second token. The meanings of the words "directly" and "indirectly" are as described above. In the first embodiment, the payment server 20 issues the second token, so the second token request sending unit 403 sends the second token request to the payment server 20. If a computer other than the payment server 20 issues the second token, the second token request sending unit 403 only needs to send the second token request to the other computer. If the second token is already stored in the data storage unit 400, the second token request sending unit 403 does not need to send the second token request.

[0115] [Second token receiving unit] The second token receiving unit 404 receives the second token from the computer that issues the second token. For example, the second token receiving unit 404 receives the second token directly or indirectly from the computer that issues the second token. The meanings of the words "directly" and "indirectly" are as described above. In the first embodiment, the payment server 20 issues the second token, so the second token receiving unit 404 receives the second token from the payment server 20. That is, the second token receiving unit 404 receives the second token from the second token transmitting unit 203 of the payment server 20.

[0116] [Code display request sending section] The code display request sending unit 405 sends a code display request regarding the display of the code C420 used in the payment service to the payment server 20 of the payment service. For example, the code display request sending unit 405 sends the code display request directly or indirectly to the payment server 20. The meanings of the words "directly" and "indirectly" are as described above. In the first embodiment, the payment server 20 acquires the code display information, and therefore the code display request sending unit 405 sends the code display request to the payment server 20. When a computer other than the payment server 20 (for example, the ID server 10) acquires the code display information, the code display request sending unit 405 only needs to send the code display request to the other computer.

[0117] [Code display information receiver] The code display information receiving unit 406 receives code display information related to the display of a code from the payment server 20. For example, the code display information receiving unit 406 receives the code display information directly or indirectly from the payment server 20. The meanings of the words "directly" and "indirectly" are as described above. In the first embodiment, the code display information receiving unit 406 receives the code display information from the code display information sending unit 206 of the payment server 20.

[0118] [Display control section] The display control unit 407 displays the code C420 on the display unit 45 based on the code display information. For example, if the code ID corresponds to the code display information, the display control unit 407 encodes the code ID and generates image data of the code C420. The display control unit 407 displays the code C420 on the display unit 45 based on the image data. If the image data of the code C420 corresponds to the code display information, the display control unit 407 displays the code C420 on the display unit 45 based on the code display information, which is image data.

[0119] [1-3-5. Functions realized by store terminals] For example, the store terminal 50 includes a data storage unit 500 and a payment execution unit 501. The data storage unit 500 is realized by the storage unit 52. The payment execution unit 501 is realized by the control unit 51.

[0120] [Data storage section] The data storage unit 300 stores data necessary for the affiliated store to use the payment service. For example, the data storage unit 300 stores an app for the affiliated store.

[0121] [Payment Execution Department] The payment execution unit 501 executes the payment. As described above, the payment processing may be the same as publicly known processing. For example, when the reading unit 56 reads the codes C300 and C420, the payment execution unit 501 acquires a code ID from the codes C300 and C420. The payment execution unit 501 transmits the code ID to the payment server 20. The payment execution unit 501 acquires the execution result of the payment from the payment server 20. The payment execution unit 501 displays a screen showing the execution result of the payment on the display unit 55.

[0122] [1-4. Processing Executed in the Payment System of the First Embodiment] 7 and 8 are diagrams showing an example of processing executed in the payment system 1 of the first embodiment. The processing in FIGS. 7 and 8 is executed by the control units 11, 21, 31, 41, and 51 executing programs (for example, mobile terminal apps, wearable device apps, or other programs) stored in the storage units 12, 22, 32, 42, and 52, respectively. Before the processing in FIGS. 7 and 8 is executed, it is assumed that pairing (connection of non-synchronized terminals) between the mobile terminal 30 and the wearable device 40 has already been completed.

[0123] 7, when the user operates operation unit 34 to select a mobile terminal app, mobile terminal 30 starts the mobile terminal app (S100). In S100, mobile terminal 30 may execute a login process with payment server 20 to allow the user to log in to the payment service. When the user operates operation unit 44 to select a wearable device app, wearable device 40 starts the wearable device app (S101).

[0124] The wearable device 40 transmits a synchronization start request to the mobile terminal 30 regarding the start of synchronization (S102). The synchronization start request is data in a predetermined format indicating a request to start synchronization. The synchronization start request may include a wearable device ID, information capable of identifying a wearable device app, or a combination of these. The mobile terminal 30 receives the synchronization start request from the wearable device 40 (S103).

[0125] The mobile terminal 30 determines whether a first token within the expiration date is stored in the storage unit 32 (S104). If it is determined in S104 that a first token within the expiration date is stored in the storage unit 32 (S104: Y), the mobile terminal 30 proceeds to the processing of S110, which will be described later. If it is determined in S104 that a first token within the expiration date is not stored in the storage unit 32 (S104: N), the mobile terminal 30 transmits a first token request to the ID server 10 (S105).

[0126] The ID server 10 receives a first token request from the mobile terminal 30 (S106). The ID server 10 issues a first token based on a predetermined token issuing method (S107). In S107, the ID server 10 determines the expiration date of the first token. The ID server 10 identifies the user ID based on the first token request, and stores the first token and the expiration date in the ID database DB1 in association with the user ID.

[0127] The ID server 10 transmits the first token and the expiration date to the mobile terminal 30 (S108). The mobile terminal 30 receives the first token and the expiration date from the ID server 10 (S109). In S109, the mobile terminal 30 records the first token and the expiration date in the storage unit 32. The mobile terminal 30 transmits the first token to the wearable device 40 (S110). In S110, the mobile terminal 30 may transmit the mobile terminal ID together with the first token to the wearable device 40.

[0128] The wearable device 40 receives the first token and the expiration date from the mobile terminal 30 (S111). In S111, the wearable device 40 records the first token and the expiration date in the storage unit 42. The wearable device 40 transmits a second token request including the first token to the payment server 20 (S112).

[0129] The payment server 20 receives the second token request from the wearable device 40 (S113). The payment server 20 executes a first token verification process with the ID server 10 to verify the first token included in the second token request (S114). In S114, the payment server 20 requests the ID server 10 to verify the first token. The ID server 10 verifies the first token based on the request from the payment server 20. The payment server 20 receives the verification result of the first token.

[0130] The payment server 20 determines whether the first token is valid or not based on the processing result of S114 (S115). If it is determined in S115 that the first token is not valid (S115: N), an error occurs and this processing ends. If it is determined in S115 that the first token is valid (S115: Y), the payment server 20 issues a second token (S116). In S116, the payment server 20 determines the expiration date of the second token. The payment server 20 identifies the user ID based on the second token request, and stores the second token and expiration date in the payment database DB2 in association with the user ID.

[0131] The payment server 20 transmits the second token and the expiration date to the wearable device 40 (S117). At the time of processing S117, the payment server 20 may generate code display information and transmit it to the wearable device 40. The wearable device 40 receives the second token and the expiration date from the payment server 20 (S118). In S118, the wearable device 40 records the second token and the expiration date in the storage unit 42. This completes synchronization.

[0132] Thereafter, when the wearable device 40 performs any communication with the payment server 20, it transmits the second token to the payment server 20. Note that the wearable device 40 may determine whether or not a second token within the expiration date is stored in the storage unit 42 at the time the wearable device app is launched (at the time of S101). If it is determined that a second token within the expiration date is stored in the storage unit 42, synchronization between the mobile terminal 30 and the wearable device 40 may be omitted. In this case, the wearable device 40 may execute the processing from S119 onwards without synchronizing with the mobile terminal 30. If it is determined that a second token within the expiration date is not stored in the storage unit 42, the processing of S103 may be executed.

[0133] Before the processing of S119 described below is executed, the wearable device 40 may transmit the mobile terminal ID and the wearable device ID to the payment server 20. As in Modification 1-1 described below, a combination of the mobile terminal ID and the wearable device ID may be stored in the payment server 20. After the second token and expiration date are recorded in the storage unit 42 in S118, the process moves to Fig. 8, where the wearable device 40 transmits a code display request including the second token to the payment server 20 (S119). The code display request also includes the wearable device ID.

[0134] The payment server 20 receives a code display request from the wearable device 40 (S120). The payment server 20 executes a second token verification process to verify the second token included in the code display request (S121). The payment server 20 determines whether the second token is valid or not based on the processing result of S121 (S122). If it is determined in S122 that the second token is not valid (S122: N), an error occurs and this process ends.

[0135] If it is determined in S122 that the second token is valid (S122: Y), the payment server 20 issues a code ID as code display information (S123). In S123, the payment server 20 stores the code ID in the payment database DB2. As in the second embodiment described below, it may be determined whether the payment source can be used on the wearable device 40. Furthermore, if the payment source can be used on the wearable device 40, the processing from S123 onwards may be executed. If the payment source cannot be used on the wearable device 40, an error may occur.

[0136] The payment server 20 transmits code display information to the wearable device 40 (S124). The wearable device 40 receives the code display information from the payment server 20 (S125). The wearable device 40 generates a code C420 based on the code ID received as the code display information, and displays a code screen SC42 on the display unit 45 (S126). When the user taps the code screen SC42 in S126, switching between the barcode C420A and the two-dimensional code C420B is executed. When the store terminal 50 reads the code C420, it executes a payment process with the payment server 20 (S127), and this process ends.

[0137] [1-5. Summary of the first embodiment] The payment system 1 of the first embodiment receives a code display request from the wearable device 40. When the code display request is received, the payment system 1 transmits code display information to the wearable device 40. As a result, the wearable device 40 is the main party in transmitting the code display request, thereby reducing the processing load on the mobile terminal 30. This prevents failure to display the code C420 due to an increase in the processing load on the mobile terminal 30, thereby improving user convenience. The user can reliably display the code C420 on the wearable device 40 and smoothly use the payment service. For example, the user can use the payment service using only the wearable device 40, even if the user does not carry the mobile terminal 30. As long as the wearable device 40 stores the second token, it can communicate with the payment server 20 to obtain the code display information, even if the user does not have the mobile terminal 30. For example, assume that a user synchronizes the mobile terminal 30 and the wearable device 40 at home and stores the second token in the wearable device 40. Suppose that the user then visits an affiliated store wearing the wearable device 40 and leaving the mobile terminal 30 at home. If the wearable device 40 can transmit the second token to the payment server 20 using a public communication line or the affiliated store's wireless LAN, the code C420 can be displayed on the wearable device 40 even if the user does not have the mobile terminal 30. This improves user convenience. For example, if the code display request is sent primarily from the mobile terminal 30, the user must carry both the mobile terminal 30 and the wearable device 40. However, according to the payment system 1 of the first embodiment, the user can use the payment service from the wearable device 40 even if he or she does not have the mobile terminal 30.

[0138] Furthermore, in the payment system 1, the mobile terminal 30 and the wearable device 40 are synchronized when both the mobile terminal app and the wearable device app are launched. The payment system 1 receives a code display request from the wearable device 40 that has synchronized with the mobile terminal 30. This allows the payment system 1 to make synchronization of the mobile terminal 30 and the wearable device 40 a condition for the code display request, thereby improving security. For example, even if a third party obtains a user's wearable device 40, the third party cannot use the payment service from the wearable device 40 unless it is synchronized with the user's mobile terminal 30, so the payment system 1 can improve security.

[0139] Furthermore, in the payment system 1, when the wearable device 40 synchronizes with the mobile terminal 30, it receives a first token from the mobile terminal 30. The payment system 1 receives the first token from the wearable device 40 that has synchronized with the mobile terminal 30. The payment system 1 verifies the first token received from the wearable device 40. If the first token is verified, the payment system 1 transmits code display information to the wearable device 40. In this way, the payment system 1 can enhance security by not only synchronizing the mobile terminal 30 and the wearable device 40 but also verifying the first token.

[0140] Furthermore, the payment system 1 receives a code display request including the second token from the wearable device 40. The payment system 1 verifies the second token included in the code display request. If the second token included in the code display request is verified, the payment system 1 transmits code display information to the wearable device 40. In this way, the payment system 1 can enhance security by not only synchronizing the mobile terminal 30 and the wearable device 40 but also verifying the second token.

[0141] Furthermore, in the payment system 1, the wearable device 40 receives a mobile terminal ID from the mobile terminal 30. The payment system 1 receives a code display request including the mobile terminal ID and the wearable device ID from the wearable device 40. By acquiring the mobile terminal ID and the wearable device ID, the payment system 1 can manage which pair of mobile terminal 30 and wearable device 40 a user uses to use the payment service. For example, if fraud occurs in the payment service, the payment system 1 can identify the pair of mobile terminal 30 and wearable device 40 in which the fraud occurred, making it easier to deal with the fraud after it occurs.

[0142] Furthermore, the wearable device 40 transmits a code display request to the payment server 20 regarding the display of the code C420 used in the payment service. The wearable device 40 receives code display information regarding the display of the code C420 from the payment server 20. The wearable device 40 displays the code C420 on the display unit 45 based on the code display information. This reduces the processing load on the mobile terminal 30, as the wearable device 40 is the main party in transmitting the code display request. This prevents failure to display the code C420 due to an increase in the processing load on the mobile terminal 30, thereby improving user convenience. For example, as described above, a user can use a payment service from the wearable device 40 even if they do not have the mobile terminal 30.

[0143] [2. Second Embodiment] Next, a second embodiment will be described, which is an example of an embodiment of the payment system 1, wearable device 40, processing execution method, and program according to the present disclosure. In the second embodiment, a description of the same configuration as in the first embodiment will be omitted. For example, the hardware configuration of the payment system 1 may be the same as in the first embodiment.

[0144] [2-1. Overview of the Second Embodiment] In the second embodiment, an example is given in which the wearable device 40 acquires a first token in the same manner as in the first embodiment. Furthermore, an example is given in which the wearable device 40 acquires a second token based on the first token in the same manner as in the first embodiment. The wearable device 40 can access the payment server 20 using the second token and acquire various information from the payment server 20. The code display information described in the first embodiment is an example of information acquired using the second token.

[0145] In the second embodiment, an example is given in which the wearable device 40 acquires setting information from the payment server 20 based on the second token. Furthermore, an example is given in which the setting information indicates a payment source specified by the user on the mobile terminal 30. As described in the first embodiment, the user can set any payment method as the payment source. The wearable device 40 may support all payment methods, or may support only some of the payment methods. Upon acquiring the setting information from the payment server 20, the wearable device 40 displays the information of the payment source specified by the user on the mobile terminal 30 on the display unit 45. The wearable device 40 may not display the information of the payment source acquired from the payment server 20 on the display unit 45, or may only display part of it.

[0146] 9 is a diagram showing an example of a screen displayed on the wearable device 40. For example, when the wearable device 40 completes synchronization with the mobile terminal 30, the wearable device 40 can switch between a state in which a barcode C420A is displayed and a state in which a two-dimensional code C420B is displayed, as shown in the upper part of FIG. 9. This is as described in the first embodiment. For example, when a user performs an operation to display setting information from the operation unit 44 of the wearable device 40, the wearable device 40 displays a setting content screen SC44 indicating the contents of the setting information on the display unit 45, as shown in the lower part of FIG.

[0147] In the example at the bottom of FIG. 9 , the setting content screen SC44 displays electronic money "AAA Cash" as the payment source information specified by the user. The user can switch between a state in which the code C420 is displayed and a state in which the payment source information is displayed by performing an operation such as swiping on the operation unit 44 of the wearable device 40. In the second embodiment, an example is given in which the payment source is changed from the mobile terminal 30, but the payment source may also be changed from the wearable device 40.

[0148] As described above, in the second embodiment, the wearable device 40 acquires setting information indicating the settings of the payment service specified by the user from the payment server 20. Based on the setting information, the wearable device 40 displays on the display unit 45 a setting content screen SC44 indicating the settings of the payment source, etc., specified by the user from the mobile terminal 30. In this way, the payment system 1 is designed to improve user convenience. Details of the second embodiment will be described below.

[0149] [2-2. Functions realized by the payment system of the second embodiment] 10 is a diagram showing an example of functions realized by the payment system 1 of the second embodiment. As in the first embodiment, the units realized by the payment system 1 can be configured by consolidating them into one device or by distributing them into smaller devices.

[0150] In the second embodiment, the payment system 1 may not include at least some of the functions described in the first embodiment. For example, the payment system 1 may not include a configuration in which the wearable device 40 transmits a code display request. In this case, the code display request may be transmitted mainly by the mobile terminal 30. As another example, the second embodiment may use a payment method in which payment is performed using the communication function of the wearable device 40, rather than a payment method in which a code is displayed on the wearable device 40.

[0151] When combining the first and second embodiments, the payment system 1 may have the wearable device 40 send a code display request. It should be obvious to those skilled in the art from the description of this disclosure that both the payment system 1 in which the wearable device 40 sends a code display request and the payment system 1 in which the mobile terminal 30 sends a code display request are described herein. Hereinafter, an example will be given in which the payment system 1 has the same functions as the first embodiment, as well as the functions described in the second embodiment.

[0152] [2-2-1. Functions realized by the ID server] For example, the function of the ID server 10 may be the same as that in the first embodiment.

[0153] [2-2-2. Functions realized by the payment server] For example, the payment server 20 includes a setting information acquisition unit 208 and a setting information transmission unit 209. The setting information acquisition unit 208 and the setting information transmission unit 209 are each realized by the control unit 21. Other functions shown in FIG. 10 may be the same as those in the first embodiment. For example, the code display request receiving unit 204 may be the same as those in the first embodiment. The code display request receiving unit 204 may receive a code display request related to the display of a code used in a payment service, the code display request including a user ID. The code display request receiving unit 204 may receive a code display request from the wearable device 40. The code display request receiving unit 204 may receive a code display request from the mobile terminal 30. For example, since the second token included in the code display request includes an encrypted user ID, the code display request may include the encrypted user ID.

[0154] [Settings information acquisition section] The setting information acquisition unit 208 acquires setting information relating to the settings for the payment service, which are settings specified on the user's mobile terminal 30 for the payment service. In the second embodiment, the setting information is stored in the payment database DB2, so the setting information acquisition unit 208 acquires the setting information from the payment database DB2. If the setting information is stored in a database other than the payment database DB2, the setting information acquisition unit 208 may acquire the setting information from the other database. If the setting information is recorded in a computer or information storage medium other than the payment server 20, the setting information acquisition unit 208 may acquire the setting information from the other computer or information storage medium.

[0155] For example, the setting information acquisition unit 208 identifies the user ID of the user for whom setting information is to be acquired, based on information acquired from the wearable device 40. This information may be the user ID itself, or other information (e.g., a temporary ID) that allows the user ID to be searched for. The setting information acquisition unit 208 acquires setting information associated with the user ID. For example, the setting information acquisition unit 208 may acquire setting information based on the user ID included in the second token. When the second token is included in the code display request as in the first embodiment, the setting information acquisition unit 208 may acquire setting information based on the user ID included in the second token.

[0156] [Settings information transmission section] The setting information transmission unit 209 transmits setting information to the wearable device 40 that can be connected to the mobile terminal 30. For example, the setting information transmission unit 209 transmits setting information directly or indirectly to the wearable device 40. The meanings of "directly" and "indirectly" are as explained in the first embodiment. For example, the setting information transmission unit 209 may transmit only the setting information to the wearable device 40, or may transmit other information together with the setting information.

[0157] In the second embodiment, the setting information transmitting unit 209 transmits setting information and code display information related to the display of the code to the wearable device 40. That is, the setting information transmitting unit 209 transmits setting information together with the code display information to the wearable device 40. The setting information may be included in the code display information. Conversely, the code display information may be included in the setting information. The method of transmitting the code display information may be the same as in the first embodiment. The setting information transmitting unit 209 may include the code display information transmitting unit 206 described in the first embodiment. The setting information transmitting unit 209 may transmit the setting information and the code display information separately to the wearable device 40.

[0158] [2-2-3. Functions realized on mobile devices] The functions realized by the mobile terminal 30 may be the same as those in the first embodiment.

[0159] [2-2-4. Functions realized by wearable devices] For example, the wearable device 40 includes a setting information receiving unit 408 and a processing execution unit 409. The setting information receiving unit 408 and the processing execution unit 409 are realized by the control unit 41. Other functions shown in FIG. 10 may be the same as those in the first embodiment. Note that the second embodiment takes as an example a case where the code display request sending unit 405 corresponds to the request sending unit. The request sending unit sends a predetermined request to the payment server 20. The predetermined request may be a code display request or a setting information request for acquiring setting information. That is, the setting information may be acquired in response to a setting information request rather than in response to a code display request. The setting information request may be included in the code display request.

[0160] For example, the wearable device 40 may send a setting information request to the payment server 20 to acquire setting information, separately from the code display request. In this case, the request sending unit has a different function from the code display request sending unit 405. The setting information request is data in a predetermined format for requesting setting information. The setting information request may be in any format, for example, a format according to the specifications of the API of the payment server 20. The setting information request may include any information. For example, the setting information request may include the first token, the second token, the mobile terminal ID of the mobile terminal 30, the wearable device ID of the wearable device, a user ID, an encrypted user ID, other information by which the user ID can be searched, a login account, other information by which the account can be searched, or other information.

[0161] [Settings information receiver] The setting information receiving unit 408 receives setting information related to settings from the payment server. The setting information receiving unit 408 receives setting information from a computer that acquires the setting information. For example, the setting information receiving unit 408 receives the setting information directly or indirectly from a computer that manages the setting information. The meanings of the words "directly" and "indirectly" are as described above. In the second embodiment, as in the first embodiment, the payment server 20 manages the setting information, and therefore the setting information receiving unit 408 receives the setting information from the payment server 20. That is, the setting information receiving unit 408 receives the setting information from the setting information transmitting unit 209 of the payment server 20. In the second embodiment, the data storage unit 400 may store the setting information received by the setting information receiving unit 408.

[0162] [Processing execution section] The processing execution unit 409 executes processing related to the payment service based on the setting information. The processing related to the payment service is processing executed based on the setting information. For example, the processing execution unit 409 executes processing for displaying the settings indicated by the setting information on the display unit 45 as processing related to the payment service. The processing execution unit 409 may execute processing for encoding the setting information into code C420 as processing related to the payment service. The processing execution unit 409 may execute processing for transmitting the setting information to the store terminal 50 via wireless communication as processing related to the payment service. The processing execution unit 409 may execute processing for transmitting a payment request to the payment server 20 based on the setting information as processing related to the payment service.

[0163] [2-2-5. Functions realized by store terminals] The functions realized by the store terminal 50 may be the same as those in the first embodiment.

[0164] [2-3. Processing executed in the payment system of the second embodiment] Fig. 11 is a diagram showing an example of processing executed in the payment system 1 of the second embodiment. The processing in Fig. 11 is executed by the control units 11, 21, 31, 41, and 51 executing programs (for example, mobile terminal apps, wearable device apps, or other programs) stored in the storage units 12, 22, 32, 42, and 52, respectively. Before the processing in Fig. 11 is executed, it is assumed that the mobile terminal 30 and the wearable device 40 have already been paired.

[0165] In the second embodiment, the same processes as S100 to S123 are executed. Fig. 11 shows the subsequent processes. The payment server 20 acquires setting information based on the user ID included in the code display request (S200). The payment server 20 transmits setting information and code display information to the wearable device 40 (S201). The wearable device 40 receives the setting information and code display information from the payment server 20 (S202). The wearable device 40 generates a code C420 based on the code ID received as the code display information, and displays a code screen SC42 on the display unit 45 (S203).

[0166] The wearable device 40 displays the settings indicated by the setting information on the setting content screen SC44 based on the user's operation (S204). As described with reference to FIG. 9, the wearable device 40 switches between a state in which the code screen SC42 is displayed and a state in which the setting content screen SC44 is displayed based on the user's operation. With the code screen SC42 displayed, the store terminal 50 reads the code C420. Upon reading the code C420, the store terminal 50 executes a payment process with the payment server 20 (S205), and the process ends.

[0167] [2-4. Summary of the second embodiment] The payment system 1 of the second embodiment acquires setting information related to settings for a payment service. The payment system 1 transmits the setting information to a wearable device 40 connectable to a mobile terminal 30. This allows the wearable device 40 to acquire the setting information, so the payment system 1 can improve user convenience. For example, if the wearable device 40 displays the settings indicated by the setting information, the user can check the settings on the wearable device 40, so the payment system 1 can improve user convenience. For example, the user does not need to configure the settings on the wearable device 40, so the payment system 1 can improve user convenience. For example, the wearable device 40 does not need to have a function such as setting the payment source, so the development costs of the wearable device app can be reduced.

[0168] Furthermore, the payment system 1 receives a code display request including the user ID. The payment system 1 acquires setting information based on the user ID included in the code display request. As a result, when the payment system 1 receives a code display request, it can acquire setting information in a series of steps and transmit it to the wearable device 40, thereby improving user convenience.

[0169] Furthermore, the payment system 1 transmits setting information and code display information related to the display of the code to the wearable device 40. This allows the payment system 1 to acquire setting information and transmit it to the wearable device 40 in the same sequence as acquiring the code display information, thereby improving user convenience.

[0170] Furthermore, the wearable device 40 transmits a predetermined request to the payment server 20. The wearable device 40 receives setting information from the payment server 20. The payment system 1 executes processing related to the payment service based on the setting information. This allows the wearable device 40 to execute flexible processing according to the setting information, thereby improving user convenience. For example, when the wearable device 40 displays the settings indicated by the setting information, the user can check the settings on the wearable device 40, and therefore the payment system 1 can improve user convenience.

[0171] [3. Modifications] The present disclosure is not limited to the above-described embodiments, and may be modified as appropriate without departing from the spirit of the present disclosure.

[0172] [3-1. Modification of the first embodiment] 12 is a diagram showing an example of functions realized in Modifications 1-1 to 1-3. For example, the payment server 20 includes a combination storage unit 210, a usage restriction unit 211, and a restriction lifting unit 212. Each of the combination storage unit 210, the usage restriction unit 211, and the restriction lifting unit 212 is realized by the control unit 21.

[0173] [Variation 1-1] For example, in the first embodiment, the payment server 20 acquires the mobile terminal ID and the wearable device ID from the wearable device 40. When fraud occurs in the payment service, when there is a risk of fraud in the payment service, or when there is a report from the user (for example, a report of loss of the mobile terminal 30 or the wearable device 40), the payment server 20 may prevent future fraud by restricting the use of at least one of the mobile terminal 30 and the wearable device 40 based on the combination of the mobile terminal ID and the wearable device ID.

[0174] Payment system 1 of modification 1-1 includes combination storage unit 210 and usage restriction unit 211. Combination storage unit 210 stores combinations of mobile terminal IDs and wearable device IDs received from wearable device 40. Modification 1-1 takes as an example a case where combination storage unit 210 stores combinations of mobile terminal IDs and wearable device IDs in payment database DB2. Combination storage unit 210 may store combinations of mobile terminal IDs and wearable device IDs in a database other than payment database DB2 (for example, a database dedicated to the above combinations), in a computer other than payment server 20, or in an external information storage medium.

[0175] For example, the wearable device 40 can transmit the mobile terminal ID and the wearable device ID at any timing to the payment server 20. Variation 1-1 takes as an example a case where the wearable device 40 transmits the mobile terminal ID and the wearable device ID to the payment server 20 after the second token is issued and before the code display request is transmitted. The wearable device 40 may transmit the second token to the payment server 20 together with the mobile terminal ID and the wearable device ID.

[0176] Note that the wearable device 40 may transmit the mobile terminal ID and the wearable device ID to the payment server 20 at another timing. For example, the wearable device 40 may transmit the mobile terminal ID and the wearable device ID when transmitting the second token request. That is, the wearable device 40 may transmit the second token request including the mobile terminal ID and the wearable device ID to the payment server 20. As another example, the mobile terminal 30 may transmit its own mobile terminal ID and the wearable device ID received from the wearable device 40 to the payment server 20 when issuing the first token.

[0177] For example, the wearable device 40 may transmit the mobile terminal ID and the wearable device ID when transmitting a code display request. That is, the wearable device 40 may transmit a code display request including the mobile terminal ID and the wearable device ID to the payment server 20. The payment server 20 may receive the mobile terminal ID and the wearable device ID from the wearable device 40 separately, rather than receiving them all at once.

[0178] For example, when the payment server 20 receives a mobile terminal ID and a wearable device ID from a wearable device 40 of a certain user, the combination storage unit 210 stores the combination of the mobile terminal ID and the wearable device ID in the payment database DB2 in association with the user ID of the user. The payment server 20 may receive the user ID together with the mobile terminal ID and the wearable device ID from the wearable device 40, or may receive other information (e.g., a temporary ID) that can be used to search for the user ID. The method by which the payment server 20 identifies the user ID may be a known method.

[0179] The usage restriction unit 211 restricts the use of at least one of the mobile terminal 30 and the wearable device 40 based on a combination of the mobile terminal ID and the wearable device ID. Restricting the use of the mobile terminal 30 means making it impossible to use a payment service from the mobile terminal 30. For example, restricting the use of the mobile terminal 30 means not displaying the code C300 on the mobile terminal 30, not executing a payment even if the code C300 displayed on the mobile terminal 30 is read, or not executing a payment even if a request for executing a payment is received from the mobile terminal 30. The usage restriction unit 211 may associate a usage restriction flag, which indicates whether or not the mobile terminal 30 is subject to usage restriction, with the mobile terminal ID of the mobile terminal 30 in the payment database DB2. The usage restriction unit 211 may restrict the use of the mobile terminal 30 based on the usage restriction flag.

[0180] Restricting the use of wearable device 40 means making it impossible to use a payment service from wearable device 40. For example, preventing code C420 from being displayed on wearable device 40, preventing payment even when code C420 displayed on wearable device 40 is read, or preventing payment even when a request for payment execution is received from wearable device 40 corresponds to restricting the use of wearable device 40. In payment database DB2, usage restriction unit 211 may associate a usage restriction flag indicating whether or not wearable device 40 is subject to usage restriction with the wearable device ID of wearable device 40 that is subject to usage restriction. Usage restriction unit 211 may restrict the use of wearable device 40 based on the usage restriction flag.

[0181] For example, the usage restriction unit 211 restricts the usage of at least one of the mobile terminal 30 and the wearable device 40 based on usage restriction data indicating usage restrictions according to a combination of a mobile terminal ID and a wearable device ID. The usage restriction data is assumed to be stored in the data storage unit 200. The usage restriction data may be in any format. For example, the usage restriction data may be in a table format, a mathematical formula format, part of a program, a machine learning model, or data in another format. Based on the usage restriction data, the usage restriction unit 211 determines whether to restrict a user's usage of the mobile terminal 30, restrict the user's usage of the wearable device 40, or restrict both of these.

[0182] Fig. 13 is a diagram showing an example of usage restriction data. In the example of Fig. 13, the usage restriction data indicates usage restrictions according to a blacklist. The blacklist is a list indicating at least one of the mobile terminal IDs and the wearable device IDs that are subject to usage restrictions. Variation example 1-1 takes as an example a case where the blacklist is stored in data storage unit 200. The blacklist may be stored in a computer other than payment server 20 or in an external information storage medium.

[0183] The method for adding at least one of the mobile terminal ID and the wearable device ID to the blacklist may be a known method. For example, the payment server 20 may receive a blacklist created by an administrator who manages the payment service from the administrator terminal of the administrator, and record the blacklist in the data storage unit 200. The payment server 20 may receive at least one of the mobile terminal ID and the wearable device ID designated by the administrator, rather than receiving the blacklist itself from the administrator terminal, and add the at least one to the blacklist stored in the data storage unit 200.

[0184] Furthermore, at least one of the mobile terminal ID and the wearable device ID to be added to the blacklist may be automatically identified by the payment service, rather than being designated by an administrator. For example, the payment server 20 may determine whether a fraud detection condition for fraud detection is met based on the usage status of the payment service (e.g., payment location, payment amount, or payment date and time), and add at least one of the mobile terminal ID and the wearable device ID to the blacklist based on the result of the determination. Fraud detection may be performed using a machine learning model. Publicly known methods may be used for fraud detection in the payment service.

[0185] For example, the usage restriction unit 211 identifies at least one of a portable terminal ID and a wearable device ID that are subject to usage restriction based on the usage restriction data and the blacklist, and restricts the use of at least one of them. That is, the usage restriction unit 211 identifies a combination of a portable terminal ID and a wearable device ID stored in the payment database DB2, determines whether or not at least one of the identified portable terminal ID and wearable device ID has been added to the blacklist, and determines whether or not to restrict the use of at least one of the identified portable terminal ID and wearable device ID based on the result of the determination and the usage restriction data.

[0186] For example, when a mobile terminal ID is added to the blacklist and the wearable device ID associated with the mobile terminal ID is not added to the blacklist (pattern (1) in FIG. 13), the usage restriction unit 211 restricts the use of both the mobile terminal 30 indicated by the mobile terminal ID and the wearable device 40 indicated by the wearable device ID. In this case, the usage restriction unit 211 executes the above-mentioned usage restriction process for both the mobile terminal 30 and the wearable device 40 whose combination is stored in the payment database DB2. Note that the wearable device ID associated with a mobile terminal ID is the wearable device ID that is paired with the mobile terminal ID.

[0187] For example, when a mobile terminal ID has not been added to the blacklist and a wearable device ID associated with the mobile terminal ID has been added to the blacklist (pattern (2) in FIG. 13), the usage restriction unit 211 does not restrict the use of the mobile terminal 30 indicated by the mobile terminal ID, but restricts the use of the wearable device 40 indicated by the wearable device ID. In this case, of the mobile terminals 30 and wearable devices 40 whose combination is stored in the payment database DB2, the usage restriction unit 211 does not execute the above-mentioned usage restriction process for the mobile terminal 30, but executes the above-mentioned usage restriction process for the wearable device 40.

[0188] For example, when a mobile terminal ID is added to the blacklist and a wearable device ID associated with the mobile terminal ID is also added to the blacklist (pattern (3) in FIG. 13), the usage restriction unit 211 restricts the use of both the mobile terminal 30 indicated by the mobile terminal ID and the wearable device 40 indicated by the wearable device ID. In this case, the usage restriction unit 211 executes the above-described usage restriction process for both the mobile terminal 30 and the wearable device 40 whose combination is stored in the payment database DB2.

[0189] The usage restriction process by the usage restriction unit 211 is not limited to the above example. The usage restriction unit 211 may perform usage restriction according to a combination of a mobile terminal ID and a wearable device ID. For example, the usage restriction unit 211 may perform usage restriction without using a blacklist or usage restriction data. The usage restriction unit 211 may restrict the use of a wearable device 40 indicated by a wearable device ID associated with a mobile terminal ID of a certain mobile terminal 30, based on a usage restriction flag associated with the mobile terminal ID of the certain mobile terminal 30. Conversely, the usage restriction unit 211 may restrict the use of a mobile terminal 30 indicated by a mobile terminal ID associated with the wearable device ID of the certain wearable device 40, based on a usage restriction flag associated with the wearable device ID of the certain wearable device 40.

[0190] The payment system 1 of Variation 1-1 stores the combination of the mobile terminal ID and the wearable device ID received from the wearable device 40. The payment system 1 restricts the use of at least one of the mobile terminal 30 and the wearable device 40 based on the combination. This allows the payment system 1 to improve the security of the payment service. For example, according to the usage restriction data shown in FIG. 13, the payment system 1 can impose usage restrictions according to each pattern indicated in the usage restriction data, thereby increasing the flexibility of the payment service.

[0191] [Variation 1-2] For example, in Modification 1-1, restrictions on the use of at least one of the mobile terminal 30 and the wearable device 40 may be lifted under certain conditions. Lifting the restrictions means making the at least one of the restricted devices available for use in the payment service again. In other words, lifting the restrictions means returning the device to the state before the restrictions were imposed. Modification 1-2 takes as an example a case where the restrictions are lifted depending on the combination of the mobile terminal 30 and the wearable device 40. For example, removal from a blacklist or a change in the value of the usage restriction flag corresponds to lifting the restrictions.

[0192] The payment system 1 of Modification 1-2 includes a restriction lifting unit 212. After the use of at least one of the mobile terminal 30 and the wearable device 40 has been restricted, the restriction lifting unit 212 lifts the restriction on at least one of the mobile terminal 30 and the wearable device 40 based on the combination of the mobile terminal 30 and the wearable device 40. Modification 1-2 takes as an example a case where a blacklist is stored in the data storage unit 200, as in Modification 1-1.

[0193] For example, an administrator of a payment service deletes at least one of a mobile terminal ID and a wearable device ID from the blacklist. Instead of the administrator manually deleting from the blacklist, the deletion from the blacklist may be performed automatically by program processing. For example, when a predetermined time has passed since at least one of a mobile terminal ID and a wearable device ID was added to the blacklist, the at least one of the mobile terminal ID and the wearable device ID may be automatically deleted from the blacklist. The deletion from the blacklist may be performed by a machine learning model. A known method may be used for the deletion from the blacklist.

[0194] For example, the restriction lifting unit 212 lifts the restriction on at least one of the mobile terminal 30 and the wearable device 40 based on restriction lifting data indicating the lifting of restrictions according to a combination of a mobile terminal ID and a wearable device ID. The restriction lifting data is assumed to be stored in the data storage unit 200. The restriction lifting data may be in any format. For example, the restriction lifting data may be in a table format, a mathematical formula format, part of a program, a machine learning model, or data in another format. The restriction lifting unit 212 determines whether to lift the restriction on the mobile terminal 30, the restriction on the wearable device 40, or both of these, based on the restriction lifting data.

[0195] Fig. 14 is a diagram showing an example of restriction lifting data. In the example of Fig. 14, the restriction lifting data indicates restriction lifting in response to removal from the blacklist. For example, the restriction lifting unit 212 identifies at least one of the mobile terminal ID and the wearable device ID for which usage restrictions are to be lifted, based on the restriction lifting data and the blacklist, and lifts the usage restrictions on at least one of them.

[0196] For example, if a certain mobile terminal ID is added to the blacklist and the wearable device ID associated with that mobile terminal ID is not added to the blacklist (the state of pattern (1) in FIG. 13), and then that mobile terminal ID is deleted from the blacklist, restriction lifting unit 212 lifts the usage restrictions on both the mobile terminal 30 indicated by that mobile terminal ID and the wearable device 40 indicated by that wearable device ID. In this case, restriction lifting unit 212 executes the restriction lifting process described above for both the mobile terminal 30 and the wearable device 40 whose combination is stored in payment database DB2.

[0197] For example, when a certain mobile terminal ID has not been added to the blacklist and a wearable device ID associated with the mobile terminal ID has been added to the blacklist (pattern (2) in FIG. 13), and the wearable device ID is then deleted from the blacklist, restriction removal unit 212 removes the usage restriction on wearable device 40 indicated by the wearable device ID. In this case, since the use of mobile terminal 30 indicated by the mobile terminal ID is not restricted in the first place, restriction removal processing is not executed for the mobile terminal 30. Usage restriction unit 211 executes the restriction removal processing described above for wearable device 40 among the mobile terminals 30 and wearable devices 40 whose combinations are stored in payment database DB2.

[0198] For example, if a certain mobile terminal ID is added to the blacklist and a wearable device ID associated with the mobile terminal ID is also added to the blacklist (pattern (3) in FIG. 13), and then the mobile terminal ID is deleted from the blacklist, restriction lifting unit 212 lifts the usage restriction on the mobile terminal 30 indicated by the mobile terminal ID. In this case, of the mobile terminals 30 and wearable devices 40 whose combination is stored in payment database DB2, usage restriction unit 211 executes the restriction lifting process described above on the mobile terminal 30. The usage restriction on the wearable device 40 is not lifted.

[0199] For example, if a mobile terminal ID is added to the blacklist and a wearable device ID associated with the mobile terminal ID is also added to the blacklist (pattern (3) in FIG. 13), and then the wearable device ID is deleted from the blacklist, restriction removal unit 212 does not remove the usage restriction. In this case, the use of both the mobile terminal 30 indicated by the mobile terminal ID and the wearable device 40 indicated by the wearable device ID continues to be restricted.

[0200] For example, when a mobile terminal ID is added to the blacklist and a wearable device ID associated with the mobile terminal ID is also added to the blacklist (pattern (3) in Figure 13), and then both the mobile terminal ID and the wearable device ID are deleted from the blacklist, the restriction removal unit 212 removes both the usage restriction on the mobile terminal 30 indicated by the mobile terminal ID and the usage restriction on the wearable device 40 indicated by the wearable device ID.

[0201] The restriction removal process by the restriction removal unit 212 is not limited to the above example. The restriction removal unit 212 may remove the restriction according to the combination of the mobile terminal ID and the wearable device ID. For example, the restriction removal unit 212 may remove the restriction without using a blacklist or restriction removal data. The restriction removal unit 212 may remove the restriction on the wearable device 40 indicated by the wearable device ID associated with a certain mobile terminal 30, based on a usage restriction flag associated with the mobile terminal ID of the mobile terminal 30. Conversely, the restriction removal unit 212 may remove the restriction on the mobile terminal 30 indicated by the mobile terminal ID associated with the wearable device ID of the certain wearable device 40, based on a usage restriction flag associated with the wearable device ID of the wearable device 40.

[0202] In the payment system 1 of Variation 1-2, after the use of at least one of the mobile terminal 30 and the wearable device 40 is restricted, the payment system 1 lifts the restriction on at least one of the mobile terminal 30 and the wearable device 40 based on the combination of the mobile terminal 30 and the wearable device 40. This allows the payment system 1 to prevent a decrease in user convenience while increasing the security of the payment service. For example, according to the restriction lifting data shown in FIG. 14, the payment system 1 can lift restrictions according to each pattern indicated in the restriction lifting data, thereby increasing the flexibility of the payment service.

[0203] [Variation 1-3] For example, in the first embodiment, the wearable device 40 displays the payment code C420, but the wearable device 40 may display a code as a point card. In Modification 1-3, the payment code C420 described in the first embodiment is referred to as a first code C420. The code as a point card is referred to as a second code.

[0204] FIG. 15 is a diagram showing an example of the hardware configuration in Modification 1-3. As shown in FIG. 15, the payment system 1 includes a point server 60. The point server 60 is a server computer that provides a point service to users. The point service is a service in which users use points. For example, the point server 60 includes a control unit 61, a memory unit 62, and a communication unit 63. The hardware configurations of the control unit 61, the memory unit 62, and the communication unit 63 may be similar to those of the control unit 11, the memory unit 12, and the communication unit 13, respectively. The operator of the point service and the operator of the payment service may be the same or different from each other. If these operators are different from each other, these operators are in a cooperative relationship and can provide each other with information as appropriate.

[0205] FIG. 16 is a diagram showing an example of a screen displayed on the wearable device 40 in Modification Example 1-3. The example of FIG. 16 differs from the example of FIG. 3 in that the wearable device 40 displays a point card screen SC45 including a second code C450 as a point card on the display unit 45. The user can switch between the display of the code screen SC42 and the display of the point card screen SC45 by operating the operation unit 44 (for example, by swiping). In the example of FIG. 16, the second code C450 is a barcode, but the second code C450 may also be a two-dimensional code. The second code C450 may be a code that the user uses not only to earn points but also to make payments with their owned points. The processing flow for making payments with their owned points may be similar to the processing employed in known point cards.

[0206] FIG. 17 is a diagram showing an example of functions implemented in the payment system 1 in Modifications 1-3 to 1-6. Note that Modification 1-3 takes as an example a case where the wearable device 40 communicates directly with the point server 60 to display the second code C450, but the wearable device 40 may also display the second code C450 by indirectly communicating with the point server 60 via the payment server 20. In this case, a second code display request, which will be described later, is transmitted from the wearable device 40 to the payment server 20. The payment server 20 may acquire second code display information from the point server 60 and transmit it to the wearable device 40.

[0207] In Modification 1-3, the code display request receiving unit 204 described in the first embodiment is a first code display request receiving unit 204 that receives a first code request for displaying a first code C420. For convenience of explanation, the only difference is that the code C420 in the first embodiment is described as first code C420, and the processing of the first code display request receiving unit 204 is the same as that of the code display request receiving unit 204 described in the first embodiment. That is, in the explanation of the first code display request receiving unit 204 in the first embodiment, the word "code" can be read as "first code."

[0208] In Modification 1-3, the code display information transmitting unit 206 described in the first embodiment is a first code display information transmitting unit 206 that transmits first code display information related to the display of a first code C420 used in a payment service to the wearable device 40. For convenience of explanation, the only difference is that the code C420 in the first embodiment is described as first code C420, and the processing of the first code display information transmitting unit 206 is the same as that of the code display information transmitting unit 206 described in the first embodiment. That is, in the explanation of the code display information transmitting unit 206 in the first embodiment, the word "code" can be read as "first code."

[0209] For example, the point server 60 includes a data storage unit 600, a second code display request receiving unit 601, a second code display information transmitting unit 602, and a point processing unit 603. The data storage unit 600 is realized by the storage unit 62. Each of the second code display request receiving unit 601, the second code display information transmitting unit 602, and the point processing unit 603 is realized by the control unit 61. The data storage unit 600 stores a point database DB3.

[0210] FIG. 18 is a diagram showing an example of the point database DB3. The point database DB3 is a database that stores various information about each of multiple users in the point service. For example, the point database DB3 stores a user ID, a password, a point card ID, and a point balance. The point database DB3 may also store other information. For example, the point database DB3 may store usage history information about the usage history of the point service.

[0211] In Modification 1-3, a case will be described in which the user ID of a certain user stored in the payment database DB2 is the same as the user ID of the user stored in the point database DB3, but these user IDs may be different from each other. When these user IDs are different from each other, a relational database indicating the relationship between the user ID stored in the payment database DB2 and the user ID stored in the point database DB3 is assumed to be stored in the data storage unit 600. The relational database may be stored in the data storage unit 200 of the payment server 20, in a computer other than the payment server 20 and the point server 60, or in an external information storage medium.

[0212] The point card ID is point identification information that can identify points held by a user. The point identification information may be information other than the point card ID. For example, the point identification information may be a user ID. In other words, the user identification information in a point service may correspond to the point identification information. In variant example 1-3, the point card ID is an example of a temporary ID, similar to a code ID. The point card ID may have an expiration date.

[0213] The second code display request receiving unit 601 receives a second code display request for displaying the second code C450 from the wearable device 40. The second code display request differs from the first code display request in that the second code display request is for displaying the second code C450, but is otherwise similar to the first code display request. That is, the second code display request is data in a predetermined format for requesting the display of the second code C420. The second code display request may be in any format, for example, a format according to the API specifications of the point server 60.

[0214] For example, the request to display the second code may include any information, such as a second token, a user ID, information that allows the user ID to be searched (e.g., a temporary ID), a login account, information that allows the login account to be searched (e.g., a temporary ID), a mobile terminal ID, a wearable device ID, or other information.

[0215] In variant 1-3, the second code display request includes a second token. The point server 60 requests the payment server 20 to verify the second token included in the second code display request. When the payment server 20 accepts the request to verify the second token, the second token verification unit 205 verifies the second token. The method for verifying the second token is as described in the first embodiment. The second token verification unit 205 transmits the verification result to the point server 60. The point server 60 receives the verification result of the second token from the payment server 20.

[0216] For example, the second code display information transmitter 602 transmits to the wearable device 40 second code display information relating to the display of a second code C450 that is different from the first code C420. The second code display information is information used to display the code C420. In variant example 1-3, a point card ID corresponds to the second code display information, but the second code display information may include information other than the point card ID (for example, a URL). The second code display information may be image data of the second code C450.

[0217] For example, the second code display information transmitting unit 602 issues a point card ID based on a predetermined ID issuance rule. The ID issuance rule may be any rule. For example, the ID issuance rule may be a rule that indicates that the point card ID should be issued to be random letters, numbers, symbols, or a combination of these. The second code display information transmitting unit 602 issues a point card ID so that it is different from other point card IDs. If an expiration date is set for the point card ID, the second code display information transmitting unit 602 issues a point card ID so that it is different from other point card IDs that are within the expiration date.

[0218] In variant example 1-3, the second code display information transmitting unit 602 transmits the second code display information to the wearable device 40 when the second token included in the second code display request is verified. The second code display information transmitting unit 602 transmits the second code display information to the wearable device 40 on the condition that the second token is verified. Here, the second token being verified means that the legitimacy of the second token is confirmed. Note that when the second token is not used, the second code display information transmitting unit 602 may transmit the second code display information to the wearable device 40 on the condition that the first token is verified.

[0219] The point processing unit 603 executes a process for providing a point service to a user. The process for the point service may be similar to a known process. For example, the point processing unit 603 acquires a point card ID read from the second code C460 from the store terminal 50. The point processing unit 603 determines whether the point card ID acquired from the store terminal 50 is stored in the point database DB3. If the point processing unit 603 determines that the point card ID acquired from the store terminal 50 is stored in the point database DB3, the point processing unit 603 executes a process for increasing the point balance associated with the point card ID, on the condition that payment is executed. The point server 60 may acquire information indicating the execution of payment from the payment server 20. The point balance may be increased immediately or after a certain period of time has passed. The point processing unit 603 transmits a result of the process executed by the point processing unit 603 to the store terminal 50.

[0220] In Modification 1-3, the code display request transmitting unit 405 and the code display information receiving unit 406 described in the first embodiment are referred to as a first code display request transmitting unit 405 and a first code display information receiving unit 406, respectively. For convenience of explanation, the only difference is that the code C420 in the first embodiment is described as a first code C420, and the processing of the first code display request transmitting unit 405 and the first code display information receiving unit 406 is the same as that of the code display request transmitting unit 405 and the code display information receiving unit 406 described in the first embodiment. That is, in the explanation of the first code display request transmitting unit 405 and the first code display information receiving unit 406 in the first embodiment, the term "code" may be read as "first code."

[0221] The wearable device 40 of the modification 1-3 includes a second code display request sending unit 410 and a second code display information receiving unit 411. Each of the second code display request sending unit 410 and the second code display information receiving unit 411 is realized by the control unit 41.

[0222] The second code display request sending unit 410 sends a second code display request to the point server 60. For example, the second code display request sending unit 410 sends the second code display request directly or indirectly to the point server 60. The meanings of the words "directly" and "indirectly" are as described above. In variant example 1-3, the point server 60 acquires the code display information, so the second code display request sending unit 410 sends a second code display request to the point server 60. If a computer other than the point server 60 (for example, the payment server 20) acquires the second code display information, the second code display request sending unit 410 only needs to send a second code display request to the other computer.

[0223] The second code display information receiving unit 411 receives the second code display information from the point server 60. For example, the second code display information receiving unit 411 receives the second code display information directly or indirectly from the point server 60. The meanings of the words "directly" and "indirectly" are as described above. In variant example 1-3, the second code display information receiving unit 411 receives the second code display information from the second code display information transmitting unit 602 of the point server 60.

[0224] The display control unit 407 in modification 1-3 displays the second code C450 on the display unit 45 based on the second code display information. For example, if a point card ID corresponds to the second code display information, the display control unit 407 encodes the point card ID and generates image data of the second code C450. The display control unit 407 displays the second code C450 on the display unit 45 based on the image data. If the image data of the second code C450 corresponds to the second code display information, the display control unit 407 displays the second code C450 on the display unit 45 based on the second code display information, which is image data.

[0225] The payment system 1 of Modification 1-3 transmits first code display information to the wearable device 40. The payment system 1 transmits second code display information to the wearable device 40. This allows the payment system 1 to display not only the first code C420 but also the second code C450 on the wearable device 40, thereby improving user convenience.

[0226] [Variation 1-4] For example, in Modification 1-3, an example is given in which the first code display information transmitting unit 206 and the second code display information transmitting unit 602 are realized by separate servers, but the first code display information transmitting unit 206 and the second code display information transmitting unit 602 may be realized by the same server. Modification 1-4 takes as an example a case in which the first code display information transmitting unit 206 and the second code display information transmitting unit 602 are realized by the payment server 20. The first code display information transmitting unit 206 of the payment server 20 is as described in Modification 1-3.

[0227] For example, the second code display information transmitting unit 602 of the payment server 20 is realized by the control unit 21. The payment server 20 may include a second code display request receiving unit 601. The second code display request receiving unit 601 of the payment server 20 is realized by the control unit 21. When the first code display request and the second code display request are not made separately but are combined into one code display request, the code display request receiving unit 204 described in the first embodiment may receive the one code display request.

[0228] For example, the second code display request receiving unit 601 of the payment server 20 receives the second code display request from the wearable device 40. This differs from variant 1-3 in that the wearable device 40 transmits the second code display request to the payment server 20 instead of the point server 60, but is otherwise similar. The second code display request receiving unit 601 of the payment server 20 may receive the second code display request directly or indirectly from the wearable device 40.

[0229] For example, the second code display information sending unit 602 of the payment server 20 sends the second code display information to the wearable device 40. The payment server 20 may request the point server 60 to generate the second code display information. In this case, the point server 60 acquires the second code display information and sends it to the payment server 20 based on the request from the payment server 20. The payment server 20 receives the second code display information from the point server 60. The second code display information sending unit 602 of the payment server 20 sends the second code display information received from the point server 60 to the wearable device 40.

[0230] The payment server 20 may generate the second code display information by itself, rather than requesting the point server 60 to generate the second code display information. In this case, the payment server 20 may store the point database DB3. The second code display information transmitting unit 602 of the payment server 20 transmits the second code display information generated by the payment server 20 to the wearable device 40. The first code display information transmitting unit 206 and the second code display information transmitting unit 602 may transmit the first code display information and the second code display information to the wearable device 40 all at once, rather than transmitting them separately.

[0231] In the payment system 1 of variation 1-4, the first code display information transmitting unit 206 and the second code display information transmitting unit 602 are realized by the same server. This allows the function for transmitting the first code display information and the function for transmitting the second code display information to be integrated into the same server, simplifying the configuration of the payment system 1. For example, the payment system 1 can transmit the first code display information and the second code display information together at the same time. This eliminates the need for the wearable device 40 to obtain the first code display information and the second code display information from separate servers.

[0232] [Variation 1-5] For example, even if a user uses a payment service, the user may not have a point card (do not use the point service). In this case, the processing of Modifications 1-3 and 1-4 may be executed only for users who have a point card. The point server 60 of Modification 1-5 includes an association determination unit 604. The association determination unit 604 is realized by the control unit 61. The association determination unit 604 determines whether information related to the second code C450 is associated with the user. In Modification 1-5, the information related to the second code C450 is a user ID in the point database DB3 or various information associated with the user ID (e.g., point balance). For users who do not have a point card, this information is not stored in the point database DB3.

[0233] In Modification 1-5, as in Modification 1-3, an example is taken of the case where the second code display information transmission unit 602 is realized by the point server 60. For example, when the point server 60 receives a second code display request, the association determination unit 604 identifies the user ID of the user of the wearable device 40 that sent the second code display request, and determines whether the user ID is stored in the point database DB3. If the association determination unit 604 determines that the user ID is stored in the point database DB3, it determines that information related to the second code C450 is associated with the user. If the association determination unit 604 determines that the user ID is not stored in the point database DB3, it determines that information related to the second code C450 is not associated with the user.

[0234] The second code display information transmitting unit 602 of Modification Example 1-5 transmits the second code display information to the wearable device 40 based on the determination result of the association determining unit 604. For example, if it is determined that the information on the second code C450 is not associated with the user, the second code display information transmitting unit 602 does not transmit the second code display information to the wearable device 40, and if it is determined that the information on the second code C450 is associated with the user, the second code display information transmitting unit 602 transmits the second code display information to the wearable device 40. When Modification Examples 1-4 and 1-5 are combined, the association determining unit 604 may be realized by the payment server 20.

[0235] The payment system 1 of Modification 1-5 determines whether information related to the second code C450 is associated with a user. Based on the result of the determination, the payment system 1 transmits second code display information to the wearable device 40. This enables the payment system 1 to prevent the second code C450 from being displayed on the wearable device 40 of a user who does not need the second code C450 (a wearable device 40 of a user who does not have a point card).

[0236] [Variation 1-6] For example, as in Modifications 1-3 to 1-5, the first code C420 may be a code for the user to make a payment. The second code C450 may be a code for the user to acquire a benefit through payment. In Modifications 1-3 to 1-5, points have been described as an example of a benefit, but the benefit is not limited to points. For example, the benefit may be a discount obtained by using a coupon, or a product or service obtained by using a coupon. The processing required for displaying each of the first code C420 and the second code C450 may be the same as in Modifications 1-3 to 1-5.

[0237] In Modification Example 1-6, when one of the first code C420 and the second code C450 is read, the display control unit 407 displays the other of the first code C420 and the second code C450. For example, when the first code C420 is read, the display control unit 407 displays the second code C450. When the first code C420 is read by the store terminal 50, the process described in the first embodiment is executed, and the payment server 20 notifies the wearable device 40 that the first code C420 has been read. The wearable device 40 may detect that the first code C420 has been read by a notification from the payment server 20. When the display control unit 407 receives the notification, it displays the second code C450.

[0238] For example, the display control unit 407 may display the first code C420 when the second code C450 is read. When the second code C450 is read by the store terminal 50, the point server 60 notifies the wearable device 40 that the second code C450 has been read. The wearable device 40 may detect that the second code C450 has been read from the notification from the point server 60. When the display control unit 407 receives the notification, it displays the first code C420.

[0239] In the payment system 1 of variation 1-6, the first code C420 is a code used by the user to make a payment. The second code C450 is a code used by the user to obtain a benefit through payment. When one of the first code C420 and the second code C450 is read, the payment system 1 displays the other of the first code C420 and the second code C450. This eliminates the need for the user to perform an operation to switch the display of the first code C420 and the second code C450, thereby improving user convenience.

[0240] [Variation 1-7] For example, the mobile terminal 30 may be connectable to multiple wearable devices 40. In Modification 1-7, multiple wearable devices 40 are paired with one mobile terminal 30. The multiple wearable devices 40 may be paired with the mobile terminal 30 simultaneously, or may be paired separately without being paired with the mobile terminal 30 simultaneously. The mobile terminal 30 synchronizes with each of the multiple wearable devices 40. The process by which each wearable device 40 synchronizes with the mobile terminal 30 may be the same as in the first embodiment. Each wearable device 40 may have the same functions as in the first embodiment and Modifications 1-1 to 1-6.

[0241] For example, each of the multiple wearable devices 40 may store a second token issued for that wearable device 40 based on a first token common to the multiple wearable devices 40. Each wearable device 40 has the functions described in the first embodiment. The second token issued for one wearable device 40 is different from the second token issued for another wearable device 40. However, the first token is common to these wearable devices 40.

[0242] The code display request receiving unit 204 of Modification 1-7 receives, from each of the multiple wearable devices 40, a code display request including a second token stored in the wearable device 40. When the second token included in the code display request received from each of the multiple wearable devices 40 is verified, the code display information sending unit 206 sends code display information to the wearable device 40. This series of processes may be similar to the processes described in the first embodiment and Modifications 1-1 to 1-6.

[0243] In addition, the payment database DB2 of Modifications 1-7 stores the wearable device ID of each wearable device 40 connected to a certain mobile terminal 30 in association with the second token. When verifying a second token received from a certain wearable device 40, the second token verification unit 205 performs verification based on the second token stored in the payment database DB2 in association with the wearable device ID of the wearable device 40 and the second token received from the wearable device 40.

[0244] In the payment system 1 of Variation 1-7, each of the multiple wearable devices 40 stores a second token issued for that wearable device 40, the second token being issued based on a first token common to the multiple wearable devices 40. The payment system 1 receives, from each of the multiple wearable devices 40, a code display request including the second token stored in that wearable device 40. When the second token included in the code display request received from each of the multiple wearable devices 40 is verified, the payment system 1 transmits code display information to that wearable device 40. This allows the user to use the payment service from multiple wearable devices 40, thereby improving user convenience. Furthermore, because different second tokens can be issued for multiple wearable devices 40 using a common first token, the payment system 1 can simplify management of first tokens.

[0245] [3-2. Modification of the second embodiment] 19 is a diagram showing an example of functions realized in Modifications 2-1 to 2-7. For example, in Modifications 2-1 to 2-7, the payment server 20 includes an availability determination unit 213, a first automatic change unit 214, a balance insufficiency determination unit 215, a screen transition unit 216, a second automatic change unit 217, and a notification unit 219. Each of the availability determination unit 213, the first automatic change unit 214, the balance insufficiency determination unit 215, the screen transition unit 216, the second automatic change unit 217, the auto-charge execution unit 218, and the notification unit 219 is realized by the control unit 21.

[0246] [Variation 2-1] For example, in the second embodiment, the setting information indicates the setting related to the payment source for a payment service. The wearable device 40 may not have any restrictions on the payment source, or may only support some payment sources. Variation 2-1 illustrates a case where payment from the wearable device 40 cannot be made using a bank account as the payment source. In this case, the availability of the payment source may be determined depending on whether the payment source set by the user is a bank account.

[0247] The payment system 1 of variant 2-1 includes an availability determination unit 213. The availability determination unit 213 determines whether the payment source indicated by the setting information is available for use with the wearable device 40. Availability data indicating the payment sources available for use with the wearable device 40 is stored in the data storage unit 200. The availability data may be in any format. For example, the availability data may be in table format, mathematical formula format, part of a program, a machine learning model, or other format. The available payment sources may be determined for each user. In variant 2-1, the availability data indicates that a bank account is not available as a payment source.

[0248] For example, the usability determination unit 213 determines whether the current payment source can be used with the wearable device 40 based on the setting information and usability data stored in the payment database DB2. If the current payment source indicated by the setting information is not a bank account, the usability determination unit 213 determines that the payment source can be used with the wearable device 40. If the current payment source indicated by the setting information is a bank account, the usability determination unit 213 determines that the payment source cannot be used with the wearable device 40.

[0249] The setting information transmitting unit 209 in the modification 2-1 transmits setting information to the wearable device 40 based on the determination result of the availability determining unit 213. For example, when it is determined that the payment source is available for use with the wearable device 40, the setting information transmitting unit 209 transmits setting information to the wearable device 40. When it is determined that the payment source is not available for use with the wearable device 40, the setting information transmitting unit 209 may notify the wearable device 40 of an error or a notification urging the wearable device 40 to change the payment source, without transmitting the setting information.

[0250] The payment system 1 of variant example 2-1 determines whether the payment source indicated by the setting information is usable by the wearable device 40. Based on the result of the determination, the payment system 1 transmits the setting information to the wearable device 40. This enables the payment system 1 to reliably make payments using a payment source that is usable by the wearable device 40.

[0251] [Variation 2-2] For example, in Modification 2-1, the payment source may be automatically changed. Payment system 1 of Modification 2-2 includes a first automatic change unit 214. The first automatic change unit 214 automatically changes the payment source when it is determined that the payment source indicated in the setting information cannot be used by wearable device 40. For example, the first automatic change unit 214 identifies multiple payment methods available to the user based on payment method information stored in payment database DB2. The first automatic change unit 214 updates the setting information so that any one of the identified multiple payment methods available to wearable device 40 is set as the payment source. The updated setting information may be transmitted to wearable device 40.

[0252] Payment system 1 of modification 2-2 automatically changes the payment source when it is determined that the payment source indicated in the setting information cannot be used by wearable device 40. This eliminates the need for the user to perform an operation to change the payment source, and payment system 1 can improve user convenience.

[0253] [Variation 2-3] For example, when a user attempts to make a payment from the wearable device 40, the balance of electronic money or points set as the payment source may be insufficient. In this case, the wearable device 40 may automatically transition to a screen for using other payment methods.

[0254] The payment system 1 of variant 2-3 includes a balance insufficiency determination unit 215 and a screen transition unit 216. The balance insufficiency determination unit 215 determines whether the balance of the payment method used by the user in the payment service is insufficient. Variation 2-3 takes as an example a case where the user makes payment with points. The payment server 20 of variant 2-3 can inquire about points from the point server 60 described in variant 1-3. For example, the balance insufficiency determination unit 215 obtains the point balance from the point server 60. The balance insufficiency determination unit 215 obtains the payment amount from the store terminal 50. The balance insufficiency determination unit 215 determines whether the balance is insufficient by determining whether the payment amount is greater than the balance.

[0255] The user may also make payment using electronic money. The balance of the electronic money may be stored in the payment database DB2, or in a database other than the payment database DB2. The balance of the electronic money may be stored in a computer other than the payment server 20, or in an external information storage medium. The balance shortage determination unit 215 may obtain the balance of the electronic money from the payment database DB2, another database, another computer, or an external information storage medium and make the determination.

[0256] 20 is a diagram showing an example of screen transition of wearable device 40 in Modification 2-3. When it is determined that the balance is insufficient, screen transition unit 216 transitions the screen of wearable device 40 to a screen that allows the user to use a payment method other than the payment method. For example, when the point balance is insufficient, screen transition unit 216 transitions from point card screen SC45 to code screen SC42.

[0257] For example, the screen transition unit 216 may perform a screen transition from the point card screen SC45 to the code screen SC42 by transmitting an instruction to the wearable device 40 to perform a screen transition. The instruction may include code display information. The wearable device 40 performs a screen transition based on an instruction from the payment server 20. Note that the method by which the wearable device 40 displays the code screen SC42 may be the same as in the first or second embodiment. The method by which the wearable device 40 displays the point card screen SC45 may be the same as in Modifications 1-3 to 1-6.

[0258] In Variation 2-3, payment system 1 determines whether the balance of the payment method used by the user in the payment service is insufficient. If it is determined that the balance is insufficient, payment system 1 transitions the screen of wearable device 40 to a screen that allows the user to use another payment method different from the current payment method. This eliminates the need for the user to perform an operation to transition to the screen for the other payment method, thereby enabling payment system 1 to improve user convenience.

[0259] [Variation 2-4] For example, in Modification 2-3, a screen transition is performed based on the result of the insufficient balance determination, but the payment source may be automatically changed based on the result of the insufficient balance determination. The payment system 1 of Modification 2-4 includes a balance insufficiency determination unit 215 and a second automatic change unit 217. The balance insufficiency determination unit 215 may be the same as in Modification 2-3.

[0260] When it is determined that the balance of a certain payment method is insufficient, the second automatic changing unit 217 automatically changes the payment source to another payment method different from the payment method. For example, the second automatic changing unit 217 identifies multiple payment methods available to the user based on payment method information stored in payment database DB2. The second automatic changing unit 217 updates the setting information so that any one of the identified multiple payment methods available to wearable device 40 is set as the payment source. The updated setting information may be transmitted to wearable device 40.

[0261] For example, if it is determined that the points balance is insufficient, the second automatic change unit 217 may automatically change the payment source to a credit card registered by the user. The payment process after the payment source is automatically changed may be the same as a known process. After the payment source is changed, reading of the code C420 may be requested again, but in variant example 2-4, the payment is automatically executed based on the changed payment source without reading the code C420 again.

[0262] The payment system 1 of Variation 2-4 determines whether the balance of the payment method used by the user for the payment service is insufficient. If it is determined that the balance is insufficient, the payment system 1 automatically changes the payment source to another payment method different from the payment method. This eliminates the need for the user to perform an operation to change the payment source, thereby improving user convenience.

[0263] [Variation 2-5] For example, in Variation 2-3, a case where a screen transition is performed based on the result of a balance insufficiency determination was described, and in Variation 2-4, a case where the payment source is automatically changed based on the result of a balance insufficiency determination was described, but auto-charge of the payment means may also be performed based on the result of the balance determination. The payment system 1 of Variation 2-5 includes a balance insufficiency determination unit 215 and an auto-charge execution unit 218. The balance insufficiency determination unit 215 may be the same as in Variations 2-3 and 2-4, but in Variation 2-5, the payment means is electronic money. As explained in Variation 2-3, payment may also be made with electronic money.

[0264] When it is determined that the balance is insufficient, the auto-charge execution unit 218 executes auto-charge of the payment means based on the shortfall in the balance. The auto-charge execution unit 218 calculates the shortfall based on the difference between the payment amount and the balance of electronic money. The auto-charge execution unit 218 may determine the shortfall as the charge amount directly, or may determine the shortfall plus a predetermined numerical value as the charge amount. The auto-charge execution unit 218 executes auto-charge based on the determined charge amount. The charge may be executed by a known method. For example, the auto-charge execution unit 218 executes payment by the charge amount based on a charge source designated in advance by the user, and executes processing to increase the balance of the payment means. After the auto-charge is executed, the payment is executed.

[0265] In the payment system 1 of Variation 2-5, when it is determined that the balance is insufficient, the payment system performs auto-charging of the payment means based on the shortfall in the balance. This eliminates the need for the user to instruct charging when the balance is insufficient for payment using the wearable device 40, thereby improving user convenience.

[0266] [Variation 2-6] For example, the display control unit 306 of the mobile terminal 30 may cause the mobile terminal 30 to display information about the wearable device 40. In the example of Fig. 2, when the user selects button B304 to execute synchronization, the display control unit 306 may cause the name and wearable device ID of the wearable device 40 synchronized with the mobile terminal 30 to be displayed on the code screen SC30 or another screen. The mobile terminal 30 acquires the name and wearable device ID of the wearable device 40 from the wearable device 40 at the time of synchronization.

[0267] Payment system 1 of Variation 2-6 causes mobile terminal 30 to display information about wearable device 40. This allows the user to check information about wearable device 40 on mobile terminal 30, and therefore payment system 1 can improve user convenience.

[0268] [Variation 2-7] For example, in Modification 2-1, an example is given of a case where there are restrictions on the payment methods that can be used from the wearable device 40. If the payment source set by the user cannot be used from the wearable device 40, a notification to that effect may be displayed on the mobile terminal 30. The notification may be displayed on a screen on the mobile terminal app, by a notification function of the mobile terminal app, by a push notification, a banner notification, a pop-up notification, or by other methods.

[0269] The payment system 1 of Modification 2-7 includes an availability determination unit 213 and a notification unit 219. When a setting is specified on the mobile terminal 30, the availability determination unit 213 determines whether the setting is available for use on the wearable device 40. This is different from Modification 2-1 in that the timing of determining availability is when the setting is specified on the mobile terminal 30, but the method of determining availability may be the same as in Modification 2-1.

[0270] Fig. 21 is a diagram showing an example of a screen displayed on the mobile terminal 30 of Modification Example 2-7. The notification unit 219 notifies the user of the determination result of the availability determination unit 213. As shown in the upper part of Fig. 21, when the user specifies a setting that is not available on the wearable device 40, the notification unit 219 notifies the user to that effect. When the user specifies a setting that is available on the wearable device 40, the notification unit 219 notifies the user to that effect.

[0271] For example, the notification unit 219 sends the mobile terminal 30 a notification including information indicating the determination result of the usability determination unit 213 (in the example at the top of FIG. 21, a message saying "The current payment source cannot be used from the wearable device"). Based on the notification, the mobile terminal 30 displays the code screen SC30. The determination result of the usability determination unit 213 may be notified by an image such as an icon, in addition to a message. Note that, as shown at the bottom of FIG. 21, the wearable device 40 may display a message indicating that the current payment source cannot be used on the code screen SC42. In this case, the code C420 may not be displayed.

[0272] In the payment system 1 of Variation 2-7, when a setting is specified on the mobile terminal 30, the payment system 1 determines whether the setting can be used on the wearable device 40. The payment system 1 notifies the user of the result of the determination. This allows the user to know whether the setting they are trying to specify on the mobile terminal 30 can be used on the wearable device 40, thereby enabling the payment system 1 to improve user convenience.

[0273] [3-3. Other Modifications] For example, at least two of the first embodiment, the second embodiment, modifications 1-1 to 1-7, and modifications 2-1 to 2-7 may be combined.

[0274] For example, a function described as being implemented by the ID server 10 may be implemented by the payment server 20, the mobile terminal 30, the wearable device 40, or another computer. A process described as being implemented by the payment server 20 may be implemented by the ID server 10, the mobile terminal 30, the wearable device 40, or another computer. A process described as being implemented by the mobile terminal 30 may be implemented by the ID server 10, the payment server 20, the wearable device 40, or another computer. A process described as being implemented by the wearable device 40 may be implemented by the ID server 10, the payment server 20, the mobile terminal 30, or another computer. A process described as being implemented by the ID server 10, the payment server 20, the mobile terminal 30, the wearable device 40, or another computer may be shared among multiple computers.

[0275] [4. Notes] For example, the payment system can be configured as follows:

[0276] [4-1. Supplementary notes on the first embodiment] For example, the payment system of the first embodiment can also be configured as follows. (1-1) a code display request receiving unit that receives a code display request for displaying a code used in a payment service from a wearable device that can be connected to a user's mobile terminal in the payment service; a code display information sending unit that sends code display information regarding the display of the code to the wearable device when the code display request is received; Payment systems, including: (1-2) the mobile terminal stores a mobile terminal app that enables the user to use the payment service from the mobile terminal; the wearable device stores a wearable device app that enables the user to use the payment service from the wearable device; When both the mobile terminal app and the wearable device app are launched, the mobile terminal and the wearable device are synchronized; the code display request receiving unit receives the code display request from the wearable device synchronized with the mobile terminal; The payment system described in (1-1). (1-3) The payment system includes: a first token issuing unit that issues a first token used for authentication in the payment service; a first token transmitting unit that transmits the first token to the mobile terminal; Further comprising: the mobile terminal receives the first token from the first token transmitter; the wearable device receives the first token from the mobile terminal when synchronizing with the mobile terminal; The payment system includes: a first token receiving unit that receives the first token from the wearable device that is synchronized with the mobile terminal; a first token verification unit that verifies the first token received from the wearable device; Further comprising: the code display information transmission unit transmits the code display information to the wearable device when the first token is verified. A payment system according to (1-1) or (1-2). (1-4) The payment system includes: a second token issuing unit that issues a second token used for authentication in the payment service; a second token transmitter that transmits the second token to the wearable device; Further comprising: the wearable device receives the second token from the second token transmitter; the code display request receiving unit receives the code display request including the second token from the wearable device; The payment system further includes a second token verification unit that verifies the second token included in the code display request; the code display information sending unit sends the code display information to the wearable device when the second token included in the code display request is verified. A payment system according to any one of (1-1) to (1-3). (1-5) the mobile terminal stores mobile terminal identification information that can identify the mobile terminal; the wearable device stores wearable device identification information that can identify the wearable device; the wearable device receives the mobile terminal identification information from the mobile terminal; the code display request receiving unit receives the code display request including the mobile terminal identification information and the wearable device identification information from the wearable device; A payment system according to any one of (1-1) to (1-4). (1-6) The payment system includes: a combination storage unit that stores a combination of the mobile terminal identification information and the wearable device identification information received from the wearable device; a usage restriction unit that restricts usage of at least one of the portable terminal and the wearable device based on the combination; The payment system according to (1-5) further includes: (1-7) the payment system further includes a restriction removal unit that, after the use of at least one of the mobile terminal and the wearable device has been restricted, removes the restriction on the at least one of the mobile terminal and the wearable device based on the combination. A payment system according to (1-5) or (1-6). (1-8) the code display information transmission unit is a first code display information transmission unit that transmits, to the wearable device, first code display information related to the display of a first code used in a payment service; The payment system further includes a second code display information transmitter that transmits second code display information regarding a display of a second code different from the first code to the wearable device. A payment system according to any one of (1-1) to (1-7). (1-9) The first code display information transmitting unit and the second code display information transmitting unit are realized by the same server. A payment system according to (1-8). (1-10) The payment system further includes an association determination unit that determines whether information about the second code is associated with the user; the second code display information transmission unit transmits the second code display information to the wearable device based on a determination result of the association determination unit. A payment system according to (1-8) or (1-9). (1-11) the first code is a code for the user to make a payment, The second code is a code for the user to obtain a benefit through the payment, The payment system further includes a display control unit that, when one of the first code and the second code is read, displays the other of the first code and the second code. A payment system according to any one of (1-8) to (1-10). (1-12) the mobile terminal is connectable to a plurality of the wearable devices; each of the plurality of wearable devices stores a second token issued for that wearable device, the second token being issued based on a first token common to the plurality of wearable devices; the code display request receiving unit receives, from each of the plurality of wearable devices, the code display request including the second token stored in the wearable device; the code display information transmission unit transmits the code display information to each of the wearable devices when the second token included in the code display request received from the wearable device is verified. A payment system according to any one of (1-1) to (1-11).

[0277] [4-2. Supplementary notes on the second embodiment] For example, the payment system of the second embodiment can also be configured as follows. (2-1) a setting information acquisition unit that acquires setting information regarding the setting for the payment service, the setting information being specified on the user's mobile terminal; a setting information transmission unit that transmits the setting information to a wearable device connectable to the mobile terminal; Payment systems, including: (2-2) The payment system further includes a code display request receiving unit that receives a code display request related to display of a code used in the payment service, the code display request including user identification information that can identify the user; the setting information acquisition unit acquires the setting information based on the user identification information included in the code display request. The payment system described in (2-1). (2-3) the setting information transmission unit transmits the setting information and code display information related to display of the code to the wearable device. The payment system described in (2-2). (2-4) the setting information indicates a setting related to a payment source in the payment service; The payment system further includes an availability determination unit that determines whether the payment source indicated by the setting information is available on the wearable device; the setting information transmission unit transmits the setting information to the wearable device based on a determination result of the availability determination unit. A payment system according to any one of (2-1) to (2-3). (2-5) The payment system further includes a first automatic change unit that automatically changes the payment source when it is determined that the payment source indicated by the setting information is not available on the wearable device. The payment system described in (2-4). (2-6) The payment system includes: a balance shortage determination unit that determines whether the balance of the payment method used by the user in the payment service is insufficient; a screen transition unit that, when it is determined that the balance is insufficient, transitions the screen of the wearable device to a screen that allows the user to use a payment method other than the payment method; The payment system according to any one of (2-1) to (2-5), further comprising: (2-7) The payment system includes: a balance shortage determination unit that determines whether the balance of the payment method used by the user for the payment service is insufficient; a second automatic change unit that automatically changes the payment source to another payment means different from the payment means when it is determined that the balance is insufficient; The payment system according to any one of (2-1) to (2-6), further comprising: (2-8) The payment system includes: a balance shortage determination unit that determines whether the balance of the payment method used by the user for the payment service is insufficient; an auto-charge execution unit that, when it is determined that the balance is insufficient, executes auto-charge of the payment means based on the shortfall in the balance; The payment system according to any one of (2-1) to (2-7), further comprising: (2-9) The payment system further includes a display control unit that causes the mobile terminal to display information about the wearable device. A payment system according to any one of (2-1) to (2-8). (2-10) The payment system includes: an availability determination unit that, when the setting is specified on the mobile terminal, determines whether the setting is available on the wearable device; a notification unit that notifies the user of the determination result of the availability determination unit; The payment system according to any one of (2-1) to (2-9), further comprising: [Explanation of symbols]

[0278] 1 Payment system, N Network, 10 ID server, 11, 21, 31, 41, 51, 61 Control unit, 12, 22, 32, 42, 52, 62 Memory unit, 13, 23, 33, 43, 53, 63 Communication unit, 20 Payment server, 30 Mobile terminal, 34, 44, 54 Operation unit, 35, 45, 55 Display unit, 40 Wearable device, 50 Store terminal, 56 Reading unit, 60 Point server, 100 Data memory unit, 101 First token request receiving unit, 102 First token issuing unit, 103 First token transmitting unit, 104 First token receiving unit, 105 First token verifying unit, 200 Data memory unit, 201 Second token request receiving unit, 202 Second token issuing unit, 203 Second token transmitting unit, 204 Code display request receiving unit, 205 Second token verification unit, 206 Code display information transmission unit, 207 Payment execution unit, 208 Setting information acquisition unit, 209 Setting information transmission unit, 210 Storage unit, 211 Usage restriction unit, 212 Restriction release unit, 213 Availability determination unit, 214 First automatic change unit, 215 Insufficient balance determination unit, 216 Screen transition unit, 217 Second automatic change unit, 218 Auto-charge execution unit, 219 Notification unit, 300 Data storage unit, 301 Synchronization unit, 302 First token request transmission unit, 303 First token reception unit, 304 First token transmission unit, 305 Transfer unit, 306 Display control unit, 400 Data storage unit, 401 Synchronization unit, 402 First token reception unit, 403 Second token request transmission unit, 404 Second token reception unit, 405 Code display request transmission unit, 406 Code display information reception unit, 407 Display control unit, 408 setting information receiving unit, 409 processing execution unit, 410 second code display request transmitting unit, 411 second code display information receiving unit, 500 data storage unit, 501 payment execution unit, 600 data storage unit, 601 second code display request receiving unit, 602 second code display information transmitting unit, 603 point processing unit, 604 association determination unit, DB1 ID database, DB2 payment database, DB3 point database, B301, B302, B303,B304 button, C300 code, C300A barcode, C300B two-dimensional code, C420 code, C420A barcode, C420B two-dimensional code, SC30 code screen, SC31 completion screen, SC40 startup request screen, SC41 synchronization screen, SC42 code screen, SC43 completion screen, SC44 setting contents screen, SC45 point card screen.

Claims

1. a setting information acquisition unit that acquires setting information regarding the setting for the payment service, the setting information being specified on the user's mobile terminal; a setting information transmission unit that transmits the setting information to a wearable device connectable to the mobile terminal; Payment systems, including:

2. The payment system further includes a code display request receiving unit that receives a code display request related to display of a code used in the payment service, the code display request including user identification information that can identify the user; the setting information acquisition unit acquires the setting information based on the user identification information included in the code display request. The payment system according to claim 1 .

3. the setting information transmission unit transmits the setting information and code display information related to display of the code to the wearable device. The payment system according to claim 2 .

4. the setting information indicates a setting related to a payment source in the payment service; The payment system further includes an availability determination unit that determines whether the payment source indicated by the setting information is available on the wearable device; the setting information transmission unit transmits the setting information to the wearable device based on a determination result of the availability determination unit. A payment system according to any one of claims 1 to 3.

5. The payment system further includes a first automatic change unit that automatically changes the payment source when it is determined that the payment source indicated by the setting information is not available on the wearable device. The payment system according to claim 4.

6. The payment system includes: a balance shortage determination unit that determines whether the balance of the payment method used by the user in the payment service is insufficient; a screen transition unit that, when it is determined that the balance is insufficient, transitions the screen of the wearable device to a screen that allows the user to use a payment method other than the payment method; The payment system according to any one of claims 1 to 3, further comprising:

7. The payment system includes: a balance shortage determination unit that determines whether the balance of the payment method used by the user for the payment service is insufficient; a second automatic change unit that automatically changes the payment source to another payment means different from the payment means when it is determined that the balance is insufficient; The payment system according to any one of claims 1 to 3, further comprising:

8. The payment system includes: a balance shortage determination unit that determines whether the balance of the payment method used by the user for the payment service is insufficient; an auto-charge execution unit that, when it is determined that the balance is insufficient, executes auto-charge of the payment means based on the shortfall in the balance; The payment system according to any one of claims 1 to 3, further comprising:

9. The payment system further includes a display control unit that causes the mobile terminal to display information about the wearable device. A payment system according to any one of claims 1 to 3.

10. The payment system includes: an availability determination unit that, when the setting is specified on the mobile terminal, determines whether the setting is available on the wearable device; a notification unit that notifies the user of the determination result of the availability determination unit; The payment system according to any one of claims 1 to 3, further comprising:

11. A wearable device connectable to a user's mobile terminal in a payment service, a request sending unit that sends a predetermined request to the server of the payment service; a setting information receiving unit that receives setting information regarding the payment service, which is a setting specified on the mobile terminal, from the server; a processing execution unit that executes processing related to the payment service based on the setting information; Wearable devices, including

12. a request sending step of sending a predetermined request by a wearable device connectable to a mobile terminal of a user in the payment service; a setting information acquisition step of acquiring setting information regarding the setting specified on the mobile terminal when the request is received, the setting information being related to the payment service; a setting information transmitting step of transmitting the setting information to a wearable device connectable to the mobile terminal; a setting information receiving step of receiving setting information relating to the setting; a processing execution step of executing a process related to the payment service based on the setting information; A processing execution method including:

13. a setting information acquisition unit that acquires setting information regarding the setting for the payment service, the setting information being specified on the user's mobile terminal; a setting information transmission unit that transmits the setting information to a wearable device connectable to the mobile terminal; A program that allows a computer to function as a

14. A wearable device connectable to a user's mobile terminal in a payment service, a request sending unit that sends a predetermined request to the server of the payment service; a setting information receiving unit that receives setting information regarding the setting for the payment service, which is specified on the mobile terminal, from the server; a processing execution unit that executes processing related to the payment service based on the setting information; A program that allows a computer to function as a

Images