Payment system, wearable device, processing execution method, and program

Abstract

To improve user convenience. [Solution] The setting information acquisition unit (208) of the payment system (1) acquires setting information relating to the payment service, which is a setting specified by the user's mobile terminal (30) in the payment service. The setting information transmission unit (209) transmits the setting information to a wearable device (40) that can be connected to the mobile terminal (30).

Description

Technical Field

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

Background Art

[0002] Conventionally, a technology for a user to use a payment service from a wearable device connectable to the user's mobile terminal has been known. For example, in Patent Document 1, the user's mobile terminal requests a server to issue a code used in a payment service based on a token obtained by authentication performed in advance, the server issues the code and transmits the code to the mobile terminal, the mobile terminal transmits the code to the wearable device, and a display control system in which the wearable device displays the code received from the mobile terminal is described.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] However, in the technology of Patent Document, although a code can be displayed on the wearable device, the wearable device cannot obtain settings related to the payment service. In the technology of Patent Document 1, since the user needs to start the mobile terminal to check the settings, the convenience of the user cannot be sufficiently improved.

[0005] One object of the present disclosure is to improve user convenience.

Means for Solving the Problems

[0006] The payment system relating to this disclosure includes a setting information acquisition unit that acquires setting information relating to the settings specified on the user's mobile terminal in the payment service, and a setting information transmission unit that transmits the setting information to a wearable device connectable to the mobile terminal. [Effects of the Invention]

[0007] This disclosure can improve user convenience. [Brief explanation of the drawing]

[0008] [Figure 1] This figure shows an example of the hardware configuration of a payment system. [Figure 2] This figure shows an example of a screen displayed on a mobile device. [Figure 3] This figure shows an example of a screen displayed on a wearable device. [Figure 4] This figure shows an example of the functions implemented in the payment system of the first embodiment. [Figure 5] This figure shows an example of an ID database. [Figure 6] This is a diagram showing an example of a payment database. [Figure 7] This figure shows an example of the processing performed in the payment system of the first embodiment. [Figure 8] This figure shows an example of the processing performed in the payment system of the first embodiment. [Figure 9] This figure shows an example of a screen displayed on a wearable device. [Figure 10] This figure shows an example of the functions implemented in the payment system of the second embodiment. [Figure 11] This figure shows an example of the processing performed in the payment system of the second embodiment. [Figure 12] This figure shows an example of the functions realized in the modified versions 1-1 to 1-3. [Figure 13] This figure shows an example of usage restriction data. [Figure 14] It is a diagram showing an example of restriction release data. [Figure 15] It is a diagram showing an example of the hardware configuration in Modifications 1-3. [Figure 16] It is a diagram showing an example of a screen displayed on the wearable device in Modifications 1-3. [Figure 17] It is a diagram showing an example of a function realized in the payment system in Modifications 1-3 to Modifications 1-6. [Figure 18] It is a diagram showing an example of a point database. [Figure 19] It is a diagram showing an example of a function realized in Modifications 2-1 to Modifications 2-7. [Figure 20] It is a diagram showing an example of screen transition of the wearable device in Modification 2-3. [Figure 21] It is a diagram showing an example of a screen displayed on the mobile terminal in Modification 2-7.

Mode for Carrying Out the Invention

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

[0010] [1-1. Hardware Configuration of Payment System] FIG. 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. In FIG. 1, each of the ID server 10, the payment server 20, the mobile terminal 30, the wearable device 40, and the store terminal 50 is shown as one unit, but at least one of the ID server 10, the payment server 20, the mobile terminal 30, the wearable device 40, and the store terminal 50 may exist in multiple units.

[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 a 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 settlement server 20 is a server computer that provides a settlement service to users. The settlement service is a service that provides electronic payment (cashless payment) to users. For example, the settlement server 20 includes a control unit 21, a storage unit 22, and a communication unit 23. The hardware configurations of the control unit 21, the storage unit 22, and the communication unit 23 may be the same as those of the control unit 11, the storage unit 12, and the communication unit 13, respectively.

[0013] The mobile terminal 30 is a portable (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 be another wearable device different from the wearable device 40. The mobile terminal 30 includes a control unit 31, a storage unit 32, a communication unit 33, an operation unit 34, and a display unit 35. The hardware configurations of the control unit 31, the storage unit 32, and the communication unit 33 may be the same as those of the control unit 11, the storage 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 an organic EL.

[0014] The wearable device 40 is a device that a user can wear. For example, the wearable device 40 may be a smartwatch, smart glasses, or an accessory-type device. The user can wear the wearable device 40 on any part of their body, such as their arm, fingers, 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 configuration of the control unit 41, storage unit 42, communication unit 43, operation unit 44, and display unit 45 may be the same as that of the control unit 11, storage unit 12, communication unit 13, operation unit 34, and display unit 35, respectively. The wearable device 40 may include a SIM card that can connect to a public communication line, or it may be able to use wireless communication such as Wi-Fi without connecting to a public communication line.

[0015] The store terminal 50 is a terminal of a merchant participating in 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 storage unit 52, a communication unit 53, an operation unit 54, a display unit 55, and a reading unit 56. The hardware configuration of the control unit 51, storage unit 52, communication unit 53, operation unit 54, and display unit 55 may be the same as that of the control unit 11, storage unit 12, communication unit 13, operation unit 34, and display unit 35, respectively. The reading unit 56 is a reading device that reads the codes 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] Furthermore, programs stored in memory units 12, 22, 32, 42, and 52 may be supplied to the ID server 10, payment server 20, mobile terminal 30, wearable device 40, or store terminal 50 via the network N. In addition, at least one of a reading unit (e.g., a memory card slot) for reading computer-readable information storage media and an input / output unit (e.g., a USB port) for inputting and outputting data with external devices may be included in the ID server 10, payment server 20, mobile terminal 30, wearable device 40, or store terminal 50. For example, a program stored on the information storage media may be supplied to the ID server 10, payment server 20, mobile terminal 30, wearable device 40, or store terminal 50 via at least one of the reading unit and the input / output unit.

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

[0018] For example, payment system 1 may include only a payment server 20, a mobile terminal 30, and a wearable device 40. In this case, the ID server 10 and the store terminal 50 are located outside of payment system 1. Payment system 1 may include only a payment server 20 and a wearable device 40. In this case, the ID server 10, the mobile terminal 30, or the store terminal 50 are located outside of payment system 1. For example, payment system 1 may include only a payment server 20 and other computers not shown in Figure 1.

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

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

[0021] Figure 2 shows an example of a screen displayed on the mobile terminal 30. For example, when a mobile terminal application is launched, as shown on the left side of Figure 2, the mobile terminal 30 displays a code screen SC30 on the display unit 35, which includes a barcode C300A generated based on a code ID that can temporarily identify the user, and a two-dimensional code C300B generated based on the said code ID. The code screen SC30 may display only one of either the barcode C300A or the two-dimensional code C300B. Hereafter, when barcode C300A and two-dimensional code C300B are not distinguished, they will be referred to as code C300.

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

[0023] Furthermore, the payment methods available to users through the payment service are not limited to the method of having the store terminal 50 read code C300. The payment method may be any method. 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 the merchant is read by the mobile terminal 30, a type that is completed solely by operations on the mobile terminal 30, a type that utilizes the IC chip of the mobile terminal 30, online payment (for example, account payment using the user's account, ID payment using the user's ID), carrier payment which is the payment method of the carrier used by the mobile terminal 30, or other types.

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

[0025] For example, a user can synchronize the mobile terminal 30 and the wearable device 40 by selecting button B304. Details of the synchronization will be described later. The mobile terminal 30 and the wearable device 40 may synchronize automatically even if the user does not select button B304. Once the 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, a wearable device 40 stores a wearable device app that allows the user to access payment services from the wearable device 40. The wearable device app is an application for a payment service developed for the wearable device 40. The wearable device app may be distributed from a publicly known app store or from the payment service's website.

[0027] For example, synchronization between the mobile terminal 30 and the wearable device 40 is performed when the mobile terminal 30 runs the mobile terminal application and the wearable device 40 runs the wearable device application. Once a user installs the wearable device application on the wearable device 40 and synchronizes the mobile terminal 30 and the wearable device 40, they can use the payment service from the wearable device application. Login may be required not only from the mobile terminal application but also from the wearable device application.

[0028] Figure 3 shows an example of a screen displayed on a wearable device 40. In Figure 3, the example is that the wearable device 40 is a smartwatch. For example, when a wearable device app is launched on the wearable device 40, the wearable device 40 displays a launch request screen SC40 on the display unit 45, requesting the launch of the mobile device app, as shown in the upper left of Figure 3. If the mobile device app is already running, the launch request screen SC40 may not be displayed, and synchronization may start automatically.

[0029] For example, when a mobile device application is launched on the mobile device 30, synchronization between the mobile device 30 and the wearable device 40 begins. As shown in the upper right of Figure 3, the wearable device 40 displays a synchronization screen SC41 on the display unit 45 to indicate that synchronization is in progress. In this embodiment, we take the example of a case where two pieces of authentication information called tokens are required for a user to use a payment service from the wearable device application, but there may be one or more. Details of tokens will be described later. Other processes besides token issuance may be performed during synchronization.

[0030] For example, once the synchronization between the mobile terminal 30 and the wearable device 40 is complete, the wearable device 40 communicates with the payment server 20, as shown in the middle right of Figure 3, and displays a code screen SC42, which includes 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 type, orientation, size, or combination thereof of the barcode C420A may differ from the barcode C300A.

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

[0032] For example, a two-dimensional barcode C420B may be the same as a two-dimensional barcode C300B, or at least a part of it may differ from a two-dimensional barcode C300B. A two-dimensional barcode C420B may differ from a two-dimensional barcode C300B in terms of the type of barcode itself, orientation, size, or a combination of these. Hereafter, when barcode C420A and two-dimensional barcode C420B are not distinguished, they will be referred to as code C420.

[0033] For example, when code C420 is read by the store terminal 50, a settlement is executed for payment to the merchant based on the code ID obtained from code C420. The settlement flow may be the same as the flow when a settlement is executed from a mobile terminal app. Once the settlement is complete, the wearable device 40 displays a completion screen SC43 on the display unit 45, as shown in the bottom of Figure 3, indicating that the payment to the merchant has been completed.

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

[0035] As described above, in the first embodiment of the payment system 1, the wearable device 40 primarily transmits a code display request to the payment server 20, thereby reducing the amount of processing that the mobile terminal 30 must perform to display code C420, and thus reducing the processing load on the mobile terminal 30. This prevents failures in displaying code C420 due to a high processing load on the mobile terminal 30, and thus improves user convenience. The details of the payment system 1 will be described below.

[0036] [1-3. Functions realized in the payment system of the first embodiment] Figure 4 shows an example of the functions realized in the payment system 1 of the first embodiment. The various parts realized in the payment system 1 can be configured by combining them into a single device or by further distributing them among multiple devices.

[0037] [1-3-1. Functions implemented 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 transmission unit 103, a first token receiving unit 104, and a first token verification unit 105. The data storage unit 100 is implemented by a storage unit 12. Each of the first token request receiving unit 101, the first token issuing unit 102, the first token transmission unit 103, the first token receiving unit 104, and the first token verification unit 105 is implemented by a control unit 11.

[0038] [Data Storage Unit] The data storage unit 100 stores various types of information for multiple users. For example, the data storage unit 100 stores the ID database DB1.

[0039] Figure 5 shows an example of the ID database DB1. The ID database DB1 is a database that stores various information for each of multiple users. For example, the ID database DB1 stores user ID, password, basic user information, first token, and the expiration date of the first token. The ID database DB1 may also store other information. For example, the ID database DB1 may store not only user information for the payment service, but also user information for other services that are linked to the payment service.

[0040] A 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 into 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, user identification information may be the user's email address, phone number, mobile device ID that can identify the mobile device 30, wearable device ID that can identify the wearable device 40, random symbols 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 barcode C300A and the code ID for 2D code C300B may be the same or different from each other. The code ID for barcode C420A and the code ID for 2D code C420B may be the same or different from each other.

[0042] Furthermore, user identification information may include information other than the user ID, login account, and code ID. The ID database DB1 may store the code ID. The password is the information verified during login. User basic information is basic information about the user. For example, user basic information may include the user's name, gender, date of birth, email address, telephone number, address, or occupation. If other services besides the payment service exist, user basic information may indicate the services the user is using. The user ID may be the same for 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 it may not include an encrypted user ID. The expiration date of the first token is the date and time when the period in which the first token is valid 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 does not necessarily have an expiration date set. The first token may be valid semi-permanently unless the user instructs it to be renewed. The first token may be renewed before its expiration date. The first token may be renewed when some process in payment system 1 (e.g., any of the steps in Figures 7 and 8) is executed.

[0044] In the first embodiment, the first token is used for issuing the second token, which will be described later. Specifically, the first token is a token that proves the authority to issue the second token. The first token may be used for purposes other than issuing the second token. For example, if the second token is not used by the user for payment services from the wearable device 40, the first token may be used for authentication of the user for payment services from the wearable device 40. In this case, the second token may not exist. The absence of the second token is also within the scope of this 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 specific functions 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 only needs to store data necessary for managing various types of user information. For example, the data storage unit 100 may store a program that indicates the 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 other data besides the program necessary for verifying the first token. These programs and data may be the same as those used in known tokens.

[0046] [First Token Request Receiving Unit] The first token request receiving unit 101 receives a first token request from a computer that transmits a first token request relating to 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 corresponding to the API specifications of the ID server 10. The first token request may include any information. For example, the first token request may include the mobile terminal ID of the mobile terminal 30, the wearable device ID of the wearable device, the user ID, the encrypted user ID, other information that allows the user ID to be searched, a login account, other information that allows the account to be searched, or other information.

[0047] For example, the first token request receiving unit 101 receives the first token request directly or indirectly from the computer that sends the first token request. Direct means without another computer being involved. Indirect means with another computer being involved. In the first embodiment, we take the case where the mobile terminal 30 sends the first token request as an example. In this case, the first token request receiving unit 101 receives the first token request directly or indirectly from the mobile terminal 30. For example, when the settlement server 20 forwards 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] Furthermore, a computer other than the mobile terminal 30 may also send the first token request. For example, the wearable device 40 may send 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, the first token request receiving unit 101 may also receive the first token request from a computer other than the mobile terminal 30 and the wearable device 40.

[0049] [First Token Issuance Department] The first token issuing unit 102 issues a first token. The first token issuing unit 102 issues a first token based on a predetermined token issuing method. 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 a 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 issuance method used in OAuth 2.0 or JWT (JSON Web Token). The token issuing method may be a method for generating random symbols, characters, numbers, or combinations thereof.

[0050] For example, when the first token issuing unit 102 issues a first token for a user, it stores the first token in the ID database DB1, associating it with the user's user ID. 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. The first token request may also include other information that allows searching for the user ID (e.g., a temporarily valid ID). In this case, the first token issuing unit 102 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.

[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 the expiration date of the first token to be a predetermined time after the present time. 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 the user ID identified from the first token request and include it 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 it may issue a first token that includes the encrypted user ID and other parts (for example, a part with random symbols, or a part with hashed basic user information). Encryption should be performed using a known encryption algorithm (for example, RSA encryption).

[0052] [First Token Transmission Unit] The first token transmission unit 103 transmits the first token to the computer that sent the first token request. For example, the first token transmission unit 103 transmits the first token directly or indirectly to the computer that sent the first token request. The meanings of "directly" and "indirectly" are as described above. In the first embodiment, since the mobile terminal 30 sends the first token request, the first token transmission unit 103 transmits the first token to the mobile terminal 30. If a computer other than the mobile terminal 30 sends the first token request, the first token transmission unit 103 only needs to transmit the first token to the other computer.

[0053] If the first token has an expiration date, the first token transmission unit 103 may transmit the first token and its expiration date to the computer that sent the first token request. The first token transmission unit 103 does not have to transmit the expiration date to the computer that sent the first token request. In this case, the expiration date of the first token is managed by the ID server 10. The ID server 10 determines whether the first token has expired or not.

[0054] [First Token Receiving Unit] The functions of the ID server 10 described below relate to the verification of 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 "directly" and "indirectly" are as described above. In the first embodiment, since the wearable device 40 transmits the first token, the first token receiving unit 104 receives the first token from the wearable device 40. Furthermore, since the wearable device 40 transmits the first token after synchronizing with the mobile terminal 30, 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 a first token to the payment server 20, and the payment server 20 requests the ID server 10 to verify the first token. The first token receiving unit 104 then indirectly receives the first token 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. The first token receiving unit 104 may also receive the first token from a computer other than the wearable device 40. For example, if a mobile terminal 30 transmits the first token, the first token receiving unit 104 may receive the first token from the mobile terminal 30.

[0056] [Token Verification Unit 1] The first token verification unit 105 verifies the first token received from the wearable device 40. Verification of the first token is to confirm the legitimacy 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 publicly known method. For example, the token verification method may be a verification method adopted in OAuth 2.0 or JWT.

[0057] For example, when the first token verification unit 105 verifies a user's first token, it determines whether the first token received by the first token receiving unit 104 is stored in the ID database DB1 in association with the user's user ID. 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, it determines that the first token is not valid. 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, it 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 verification 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 verification unit 105 decrypts the encrypted user ID included in the first token. Decryption may be performed using a known decryption algorithm (e.g., RSA encryption). The first token may contain other information that allows the user ID to be retrieved (e.g., an ID that can temporarily identify a user) instead of the user ID. In this case, the first token verification 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 separate data from the first token. In this case, the first token receiving unit 104 may receive the user ID or the other information together with the first token.

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

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

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

[0062] Figure 6 shows an example of a payment database DB2. The payment database DB2 is a database that stores various information for each of multiple users. For example, the payment database DB2 stores user ID, password, code ID, payment method information, settings information, second token, and the expiration date of the second token. Other information may also be stored in the payment database DB2. For example, the payment database DB2 may store usage history information related to the usage history of payment services, mobile terminal ID, wearable device ID, or first token.

[0063] In the first embodiment, the case is 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 same user stored in the ID database DB1, but these user IDs may be different from each other. If these user IDs are different from each other, a relational database showing the relationship between the user ID stored in the payment database DB2 and the user ID stored in the ID database DB1 is 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 another computer other than the ID server 10 and the payment server 20, or on an external information storage medium.

[0064] Payment method information is information that identifies the payment methods available to a user through a payment service. The payment methods indicated by the payment method information can be considered as potential payment sources. For example, payment method information may include information such as credit card numbers, electronic money numbers, bank account information, or point card numbers. If a card is the payment method, the payment method information may also include information that identifies the card issuer. The payment methods indicated in the payment method information may be used not only as payment sources but also for other purposes, such as the source of electronic money top-ups.

[0065] Configuration information is information related to the settings specified by the user. For example, configuration information indicates the payment source specified by the user. In the example in Figure 2, since the user has specified electronic money as the payment source, the configuration 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 configuration information indicates that the payment source is a credit card. Configuration information may also indicate settings other than the payment source. For example, configuration information may indicate the setting of the charging source, which is the payment method used by the user to charge electronic money, the setting of whether or not to use points, the setting of the payment method that the user prefers to use among multiple payment methods (for example, the setting of which the user prefers to use among electronic money and points), 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 where, when a user performs an operation to change setting information from a mobile terminal application on a mobile terminal 30 (for example, selecting button B304), the setting information associated with the user's user ID is updated. Furthermore, an example is given where the user cannot change the setting information from the wearable device 40. However, the user may be allowed to change the setting information from the wearable device 40. In this case, the payment server 20 should 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's user ID.

[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 it may not include an encrypted user ID. The expiration date of the second token is the date and time when the period in which the second token is valid ends. For example, the expiration date of the second token may be a predetermined time (e.g., 60 days) after the second token is issued. The second token does not necessarily have an expiration date set. The second token may be valid semi-permanently unless the user instructs it to be renewed. The second token may be renewed before its expiration date. The second token may be renewed when some process in payment system 1 (e.g., any step in Figures 7 and 8) is executed. The second token may be renewed when the first token is renewed. Conversely, the first token may be renewed when the second token is renewed.

[0068] In the first embodiment, an example is given where a second token is issued on the condition that the wearable device 40 possesses a valid first token. Furthermore, an example is given where the second token is used for the wearable device 40 to communicate with the payment server 20. For example, the second token may 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 another computer other than the payment server 20 (for example, the point server 60 in the modified example described later). The first token is not specifically required for the issuance of the second token. In this case, the first token may not exist. The absence of the first token is also within the scope of this disclosure. For example, the second token may be issued after authentication is performed based on authentication information stored in the wearable device 40, or based on 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 only needs to store the data necessary for the payment service. For example, the data storage unit 100 may store data from various screens displayed on mobile terminal applications and wearable device applications. For example, the data storage unit 100 may store a program that indicates the process 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 the same as those used in known tokens.

[0070] [Second Token Request Receiving Unit] The second token request receiving unit 201 receives a second token request from a computer that transmits a second token request relating to 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 corresponding to the API specifications 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, the user ID, the encrypted user ID, other information that allows the user ID to be searched, a login account, other information that allows the account to be searched, or other information.

[0071] For example, the second token request receiving unit 201 receives the second token request directly or indirectly from the computer that transmits the second token request. The meanings of "directly" and "indirectly" are as described above. In the first embodiment, we take the case where the wearable device 40 transmits the second token request as an example. In this case, 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 forwards the second token request from the wearable device 40 to the settlement server 20, the second token request receiving unit 201 receives the second token request indirectly from the wearable device 40.

[0072] Furthermore, a computer other than the wearable device 40 may send the second token request. For example, the mobile terminal 30 may send 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, the second token request receiving unit 201 may also 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 a second token based on a predetermined token issuance method. 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 a second token based on the program and data. The token issuance method may be a known method. For example, the token issuance method may be an issuance method adopted in OAuth 2.0 or JWT. The token issuance method may be a method for generating random symbols, characters, numbers, or combinations thereof. Since the second token is issued differently from the first token, the token issuance method for the first token and the token issuance 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 settlement database DB2, associating it with the user's user ID. 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. The second token request may also include other information that allows searching for the user ID (e.g., a temporarily valid ID). 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 defined in the settlement 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 the expiration date of the second token to be a predetermined time after the present time. 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 the 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 it may issue a second token that includes the encrypted user ID and other parts (for example, a part with random symbols, or a part with hashed basic user information). Encryption should be performed using a known encryption algorithm (for example, RSA encryption).

[0076] [Second Token Transmission Unit] The second token transmission unit 203 transmits the second token to the computer that sent the second token request. For example, the second token transmission unit 203 transmits the second token directly or indirectly to the computer that sent the second token request. The meanings of "directly" and "indirectly" are as described above. In the first embodiment, since the wearable device 40 transmits the second token request, the second token transmission unit 203 transmits the second token to the wearable device 40. If another computer other than the wearable device 40 transmits the second token request, the second token transmission unit 203 only needs to transmit the second token request to the other computer.

[0077] If the second token has an expiration date, the second token transmission unit 203 may transmit the second token and its expiration date to the computer that sent the second token request. The second token transmission unit 203 does not have to transmit the expiration date to the computer that sent the second token request. In this case, the expiration date of the second token is managed by the settlement server 20. The settlement server 20 determines whether the second token has expired or not.

[0078] [Code display request receiving unit] The functions of the payment server 20 described below relate to the verification of the second token and the display of code C420 on the wearable device 40. The display of code C300 on the mobile terminal 30 may be implemented by a publicly known function.

[0079] The code display request receiving unit 204 receives a code display request from a wearable device 40 that can connect to the user's mobile terminal 30 in the payment service, regarding the display of a code used in the payment service. The wearable device 40 that can connect to the mobile terminal 30 is a wearable device 40 that can communicate wirelessly with the mobile terminal 30. Wireless communication may be performed by any communication standard such as Bluetooth® 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 by 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 "directly" and "indirectly" are as described above. In the first embodiment, the mobile terminal 30 and the wearable device 40 synchronize when both the mobile terminal application and the wearable device application are launched. The code display request receiving unit 204 receives a code display request from the wearable device 40, which is synchronized with the mobile terminal 30. Since the wearable device 40 sends a code display request after synchronizing with the mobile terminal 30, the code display request receiving unit 204 receives the code display request from the wearable device 40 after the wearable device 40 has synchronized with the mobile terminal 30.

[0081] Furthermore, if the wearable device 40 has stored the second token, it may send a code display request without specifically synchronizing with the mobile terminal 30. That is, the wearable device 40 may send a code display request before synchronizing with the mobile terminal 30. In this case, the wearable device 40 will determine whether or not the second token is stored in the data storage unit 400 described later, and if it is determined that the second token is stored, it may send a code display request without synchronizing with the mobile terminal 30.

[0082] In the first embodiment, since the code display request includes a second token, the code display request receiving unit 204 receives a code display request including the second token from the wearable device 40. Note that the code display request does not necessarily have to include a 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 a second token, the code display request receiving unit 204 may receive a code display request including such other information from the wearable device 40.

[0083] In the first embodiment, the code display request receiving unit 204 receives a code display request from the wearable device 40, which includes a mobile terminal ID and a wearable device ID. The mobile terminal ID is an example of mobile terminal identification information. Therefore, wherever "mobile terminal ID" is written, it can be read as "mobile terminal identification information." The mobile terminal identification information may be other information besides the mobile terminal ID. For example, the mobile terminal identification information may be information such as a telephone number in the SIM card, individual identification information of the mobile terminal 30, the MAC address of the mobile terminal 30, identification information uniquely determined by a business operator that operates a payment service, or other information.

[0084] The wearable device ID is an example of wearable device identification information. Therefore, wherever "wearable device ID" is written, it can be read as "wearable device identification information." Wearable device identification information may be other information besides the wearable device ID. For example, wearable device identification information may be information such as the phone number on the SIM card, the individual identification information of wearable device 40, the MAC address of wearable device 40, identification information uniquely determined by the payment service provider, or other information.

[0085] The code display request may include any information. For example, the code display request may include the 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 Department] 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 OAuth 2.0 or JWT.

[0087] For example, when the second token verification unit 205 verifies a user's second token, it determines whether the second token received by the second token receiving unit 404 is stored in the settlement database DB2 associated with the user's user ID. If the second token verification unit 205 determines that the second token is not stored in the settlement database DB2 associated with the user ID, it determines that the second token is not valid. If the second token verification unit 205 determines that the second token is stored in the settlement database DB2 associated with the user ID, it 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. Decryption may be performed using a known decryption algorithm (e.g., RSA encryption). The second token may contain information other than the user ID that allows for the retrieval of the user ID. 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 settlement database DB2 or another database. The user ID or the other information may be separate data 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 containing the second token.

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

[0090] [Code display information transmission unit] When a code display request is received, the code display information transmission unit 206 transmits code display information relating to the display of code C420 to the wearable device 40. The code display information is information used to display code C420. In the first embodiment, the case in which the code ID corresponds to the code display information is given as an example, but the code display information may include other information other than the code ID (for example, a URL). The code display information may also be image data of code C420.

[0091] In the first embodiment, there are two codes C420: barcode C420A and two-dimensional code C420B. The code display information for barcode C420A and the code display information for two-dimensional code C420B may be separate data or the same data. For example, the code display information transmission unit 206 may transmit the code display information for barcode C420A and the code display information for two-dimensional code C420B to the wearable device 40, or it may transmit code display information indicating both barcode C420A and two-dimensional code C420B.

[0092] For example, the code display information transmission 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 the code ID will be issued in the form of random characters, numbers, symbols, or combinations thereof. The code display information transmission unit 206 issues a code ID that is not the same as another code ID. If the code ID has an expiration date, the code display information transmission unit 206 issues a code ID that is not the same as another code ID that is within its expiration date.

[0093] In this embodiment, code display information is transmitted when the first token is verified. Therefore, the code display information transmission unit 206 transmits the code display information to the wearable device 40 when the first token is verified. The code display information transmission unit 206 transmits the code display information to the wearable device 40 on the condition that the first token is verified. Here, verification of the first token means that the validity of the first token is confirmed. If the first token is not used, the code display information transmission 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 transmission unit 206 transmits code display information to the wearable device 40 when the second token included in the code display request is verified. The code display information transmission unit 206 transmits code display information to the wearable device 40 on the condition that the second token is verified. Here, verification of the second token means that the validity of the second token is confirmed. If the second token is not used, the code display information transmission unit 206 may transmit code display information to the wearable device 40 on the condition that the first token is verified.

[0095] [Payment Processing Department] The payment execution unit 207 executes the payment when code C420 is read. As mentioned above, the payment process may be the same as publicly known processes. For example, the payment execution unit 207 obtains the code ID read from code C420 from the store terminal 50. The payment execution unit 207 determines whether the code ID obtained from the store terminal 50 is stored in the payment database DB2. If the payment execution unit 207 determines that the code ID obtained 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 payment execution result to the store terminal 50.

[0096] [1-3-3. Functions implemented 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 implemented by a storage unit 32. Each of 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 is implemented by a control unit 31.

[0097] [Data Storage Unit] The data storage unit 300 stores data necessary for the user to use the payment service. For example, the data storage unit 300 stores the mobile terminal application. If the user uses the payment service from a browser instead of the mobile terminal application, the data storage unit 300 stores the browser. The data storage unit 300 may store at least one of the first token and the 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 terminal ID that can identify the mobile terminal 30. The data storage unit 300 may store a wearable device ID obtained from the wearable device 40. The data storage unit 300 may store a user ID, information that can search for the user ID, the user's login account, information that can search for the login account, or other information.

[0098] [Classmates] 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 different process 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 performed by the mobile terminal application and the wearable device application after they have been launched. During the synchronization of the mobile terminal 30 and the wearable device 40, information necessary for the user to use the payment service from the wearable device 40 is exchanged.

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

[0100] For example, the synchronization unit 301 transmits a mobile terminal ID to the wearable device 40. The synchronization unit 301 may also transmit other information (for example, authentication information for a payment service) to the wearable device 40. This other information may be stored in the data storage unit 300, or the mobile terminal 30 may obtain it from another computer (for example, the payment server 20). If the other information is authentication information for a payment service, the synchronization unit 301 may request the payment server 20 to verify its validity. For example, if a first token is already stored in the data storage unit 300, the synchronization unit 301 may transmit the first token stored in the data storage unit 300 to the wearable device 40.

[0101] For example, the synchronization unit 301 receives a wearable device ID from the wearable device 40. The synchronization unit 301 may also receive other information from the wearable device 40 besides the wearable device ID (for example, authentication information for a payment service). This other information may be stored in the data storage unit 400, or the wearable device 40 may obtain it from another computer (for example, the payment server 20). If the other information is authentication information for a payment service, the synchronization unit 301 may request the payment server 20 to verify its validity. For example, if a second token is already stored in the data storage unit 400, the synchronization unit 301 may receive the second token stored in the data storage unit 400 from the wearable device 40.

[0102] [First Token Request Transmission Unit] The first token request transmission unit 302 transmits a first token request directly or indirectly to the computer that issues the first token. The meanings of "directly" and "indirectly" are as described above. In the first embodiment, the ID server 10 issues the first token, so the first token request transmission unit 302 transmits a 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 transmission unit 302 only needs to transmit a first token request to the other computer. If the first token is already stored in the data storage unit 300, the first token request transmission unit 302 does not need to transmit a first token request.

[0103] [First Token Receiving Unit] 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 "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 Transmission Unit] The first token transmitting unit 304 transmits a first token to the wearable device 40. For example, the first token transmitting unit 304 transmits the first token to the wearable device 40 directly or indirectly. The meanings of "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. If 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 transfer unit 305 transfers arbitrary information to the wearable device 40. The transfer unit 305 also transfers arbitrary information to a computer that is the communication partner of the wearable device 40. The mobile terminal 30 may function as a hub through the transfer unit 305. The processing of the transfer unit 305 may be executed by a mobile terminal application or by a program other than a mobile terminal application. The transfer unit 305 transfers the information to be transferred as is, without any special processing. The transfer unit 305 may transfer the 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 connect to a public communication line, the wearable device 40 may send 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 capable of connecting to a public communication line but is capable of connecting to communication equipment such as a wireless LAN, 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.

[0106] [Display Control Unit] The display control unit 306 displays various screens on the display unit 35. For example, the display control unit 306 displays 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 other computers to receive the data necessary for displaying 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 receiving unit 402, a second token request transmission unit 403, a second token receiving unit 404, a code display request transmission unit 405, a code display information receiving unit 406, and a display control unit 407. The data storage unit 400 is implemented by a storage unit 42. Each of the synchronization unit 401, the first token receiving unit 402, the second token request transmission unit 403, the second token receiving unit 404, the code display request transmission unit 405, the code display information receiving unit 406, and the display control unit 407 is implemented by a control unit 41.

[0108] [Data Storage Unit] The data storage unit 400 stores data necessary for the user to use the payment service. For example, the data storage unit 400 stores the wearable device application. If the user uses the payment service from a browser instead of the wearable device application, the data storage unit 400 stores the browser. The data storage unit 400 may also store a wearable device ID that can identify 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 also store the mobile terminal ID. The data storage unit 400 may also store a first token, a second token, a mobile terminal ID, and a wearable device ID. The data storage unit 400 may also store a user ID, information that allows searching for the user ID, the user's login account, information that allows searching for the login account, or other information.

[0109] [Classmates] The synchronization unit 401 synchronizes the mobile terminal 30 and the wearable device 40. For example, the synchronization unit 401 transmits the wearable device ID to the mobile terminal 30. The synchronization unit 401 may also transmit other information (for example, authentication information for a payment service) to the mobile terminal 30. This other information may be stored in the data storage unit 400, or the wearable device 40 may obtain it from another computer (for example, the payment server 20). If the other information is authentication information for a payment service, the payment server 20 may be requested to verify its validity.

[0110] For example, if a 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 a 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 also receive other information from the mobile terminal 30 besides the mobile terminal ID (for example, authentication information for a payment service). This other information may be stored in the data storage unit 400, or the wearable device 40 may obtain it from another computer (for example, the payment server 20). If the other information is authentication information for a payment service, the synchronization unit 401 may request the payment server 20 to verify its validity. For example, if the first token is already 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 Receiving Unit] 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 that has been forwarded by the mobile terminal 30, which has received the first token from the ID server 10.

[0113] In the first embodiment, the first token receiving unit 402 receives the first token from the mobile terminal 30 when it is synchronized with the mobile terminal 30. The first token receiving unit 402 may also receive the first token from a computer other than the mobile terminal 30. For example, if 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 Transmission Unit] The second token request transmission unit 403 transmits a second token request directly or indirectly to the computer that issues the second token. The meanings of "directly" and "indirectly" are as described above. In the first embodiment, the settlement server 20 issues the second token, so the second token request transmission unit 403 transmits a second token request to the settlement server 20. If a computer other than the settlement server 20 issues the second token, the second token request transmission unit 403 only needs to transmit a second token request to the other computer. If the second token is already stored in the data storage unit 400, the second token request transmission unit 403 does not need to transmit a 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 "directly" and "indirectly" are as described above. In the first embodiment, since the settlement server 20 issues the second token, the second token receiving unit 404 receives the second token from the settlement server 20. That is, the second token receiving unit 404 receives the second token from the second token transmitting unit 203 of the settlement server 20.

[0116] [Code display request transmission unit] The code display request transmission unit 405 transmits a code display request to the payment server 20 of the payment service regarding the display of code C420 used in the payment service. For example, the code display request transmission unit 405 transmits the code display request to the payment server 20 directly or indirectly. The meanings of "directly" and "indirectly" are as described above. In the first embodiment, since the payment server 20 acquires the code display information, the code display request transmission unit 405 transmits the code display request to the payment server 20. If another computer other than the payment server 20 (for example, the ID server 10) acquires the code display information, the code display request transmission unit 405 should transmit the code display request to the other computer.

[0117] [Code display information receiving unit] 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 code display information from the payment server 20 directly or indirectly. The meanings of "directly" and "indirectly" are as described above. In the first embodiment, the code display information receiving unit 406 receives code display information from the code display information transmitting unit 206 of the payment server 20.

[0118] [Display Control Unit] The display control unit 407 displays 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 for code C420. Based on this image data, the display control unit 407 displays code C420 on the display unit 45. If the image data for code C420 corresponds to the code display information, the display control unit 407 displays code C420 on the display unit 45 based on the code display information, which is the image data.

[0119] [1-3-5. Functions implemented on 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 implemented by a storage unit 52. The payment execution unit 501 is implemented by a control unit 51.

[0120] [Data Storage Unit] The data storage unit 300 stores the data necessary for merchants to use the payment service. For example, the data storage unit 300 stores the merchant's application.

[0121] [Payment Processing Department] The settlement execution unit 501 executes the settlement. As mentioned above, the settlement process may be the same as publicly known processes. For example, when the reading unit 56 reads codes C300 and C420, the settlement execution unit 501 obtains a code ID from codes C300 and C420. The settlement execution unit 501 transmits the code ID to the settlement server 20. The settlement execution unit 501 obtains the settlement execution result from the settlement server 20. The settlement execution unit 501 displays a screen showing the settlement execution result on the display unit 55.

[0122] [1-4. Processing performed in the payment system of the first embodiment] Figures 7 and 8 show an example of processing performed by the payment system 1 of the first embodiment. The control units 11, 21, 31, 41, and 51 execute programs (for example, mobile terminal applications, wearable device applications, or other programs) stored in the storage units 12, 22, 32, 42, and 52, respectively, thereby executing the processing shown in Figures 7 and 8. It is assumed that the mobile terminal 30 and the wearable device 40 have already been paired (connected, but not synchronized).

[0123] As shown in Figure 7, when the user operates the control unit 34 of the mobile terminal 30 to select a mobile terminal application, the mobile terminal 30 launches the mobile terminal application (S100). In S100, the mobile terminal 30 may also perform a login process with the payment server 20 for the user to log in to the payment service. When the user operates the control unit 44 of the wearable device 40 to select a wearable device application, the wearable device application launches (S101).

[0124] The wearable device 40 sends 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 the wearable device ID, information that can identify the wearable device application, or a combination thereof. The mobile terminal 30 receives the synchronization start request from the wearable device 40 (S103).

[0125] The mobile terminal 30 determines whether or not a first token within its validity period is stored in the storage unit 32 (S104). If it is determined in S104 that a first token within its validity period is stored in the storage unit 32 (S104:Y), the process proceeds to S110, which will be described later. If it is determined in S104 that a first token within its validity period is not stored in the storage unit 32 (S104:N), the mobile terminal 30 sends a request for a first token to the ID server 10 (S105).

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

[0127] The ID server 10 transmits the first token and expiration date to the mobile terminal 30 (S108). The mobile terminal 30 receives the first token and expiration date from the ID server 10 (S109). In S109, the mobile terminal 30 records the first token and 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 along with the first token to the wearable device 40.

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

[0129] The payment server 20 receives a second token request from the wearable device 40 (S113). The payment server 20 performs 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 settlement 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 process terminates. If it is determined in S115 that the first token is valid (S115:Y), the settlement server 20 issues a second token (S116). In S116, the settlement server 20 determines the expiration date of the second token. Based on the second token request, the settlement server 20 identifies the user ID and stores the second token and its expiration date in the settlement database DB2 in association with that user ID.

[0131] The payment server 20 transmits the second token and 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 expiration date from the payment server 20 (S118). In S118, the wearable device 40 records the second token and expiration date in the storage unit 42. Synchronization is then completed.

[0132] Thereafter, the wearable device 40 sends the second token to the payment server 20 whenever it communicates with the payment server 20. The wearable device 40 may also determine whether a second token within its validity period is stored in the storage unit 42 at the time the wearable device application is launched (at the time of S101). If it is determined that a second token within its validity period 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 omit synchronization with the mobile terminal 30 and execute the processes from S119 onwards. If it is determined that a second token within its validity period is not stored in the storage unit 42, the process in S103 may be executed.

[0133] Before the processing in S119 described later is executed, the wearable device 40 may send the mobile terminal ID and the wearable device ID to the payment server 20. As shown in the modified example 1-1 described later, the combination of the mobile terminal ID and the wearable device ID may be stored in the payment server 20. When the second token and expiration date are recorded in the storage unit 42 in S118, the process moves to Figure 8, and the wearable device 40 sends 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 performs a second token verification process to verify the second token included in the code display request (S121). Based on the result of the process in S121, the payment server 20 determines whether the second token is valid or not (S122). If it is determined in S122 that the second token is not valid (S122:N), an error occurs and this process terminates.

[0135] In S122, if the second token is determined to be valid (S122:Y), the settlement server 20 issues a code ID as code display information (S123). In S123, the settlement server 20 stores the code ID in the settlement database DB2. As with the second embodiment described later, it may also be determined whether the payer can be used with the wearable device 40. Furthermore, if the payer can be used with the wearable device 40, the processes from S123 onwards may be executed. If the payer cannot be used with 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 code C420 based on the code ID received as code display information and displays the code screen SC42 on the display unit 45 (S126). In S126, if the user taps the code screen SC42, a switch between barcode C420A and two-dimensional code C420B is performed. When the store terminal 50 reads code C420, it performs payment processing with the payment server 20 (S127), and this process ends.

[0137] [1-5. Summary of the First Embodiment] In the first embodiment, the payment system 1 receives a code display request from the wearable device 40. When the payment system 1 receives a code display request, it transmits code display information to the wearable device 40. As a result, the wearable device 40 takes the lead in transmitting the code display request, reducing the processing load on the mobile terminal 30. Therefore, it is possible to prevent failures in displaying code C420 due to a high processing load on the mobile terminal 30, thereby improving user convenience. Users can reliably display code C420 on the wearable device 40 and use the payment service smoothly. For example, a user can use the payment service with only the wearable device 40, without carrying the mobile terminal 30. If the wearable device 40 stores the second token, it can communicate with the payment server 20 and obtain code display information even if the user does not have the mobile terminal 30. For example, suppose 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 the user then wears the wearable device 40 and visits a merchant while leaving the mobile terminal 30 at home. If the wearable device 40 can transmit a second token to the payment server 20 using a public communication line or the merchant's Wi-Fi, the code C420 can be displayed on the wearable device 40 even if the user does not have the mobile terminal 30 with them. This improves user convenience. For example, if the mobile terminal 30 is the primary source for sending the code display request, 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 they do not have the mobile terminal 30 with them.

[0138] Furthermore, when both the mobile terminal application and the wearable device application are launched, the payment system 1 synchronizes the mobile terminal 30 and the wearable device 40. 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 the synchronization of the mobile terminal 30 and the wearable device 40 a condition for the code display request, thereby enhancing security. For example, even if a third party obtains the 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, thus enhancing security for the payment system 1.

[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 sends code display information to the wearable device 40. In this way, the payment system 1 can enhance security not only by synchronizing the mobile terminal 30 and the wearable device 40, but also by verifying the first token.

[0140] Furthermore, the payment system 1 receives a code display request containing a 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 the code display information to the wearable device 40. In this way, the payment system 1 can enhance security not only by synchronizing the mobile terminal 30 and the wearable device 40, but also by 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 from the wearable device 40 that includes the mobile terminal ID and the wearable device ID. This allows the payment system 1 to manage which pair of mobile terminal 30 and wearable device 40 the user uses to access the payment service by obtaining the mobile terminal ID and the wearable device ID. 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 that was involved in the fraud, making it easier to deal with the situation after the fraud occurs.

[0142] Furthermore, the wearable device 40 sends a code display request to the payment server 20 regarding the display of code C420 used in the payment service. The wearable device 40 receives code display information regarding the display of code C420 from the payment server 20. Based on the code display information, the wearable device 40 displays code C420 on the display unit 45. As a result, the wearable device 40 takes the lead in sending the code display request, reducing the processing load on the mobile terminal 30. Therefore, it is possible to prevent failures in displaying code C420 due to a high processing load on the mobile terminal 30, thereby improving user convenience. For example, as mentioned above, a user can use the payment service from the wearable device 40 even without having the mobile terminal 30 with them.

[0143] [2. Second Embodiment] Next, a second embodiment, which is an example of an embodiment of the payment system 1, wearable device 40, processing execution method, and program related to this disclosure, will be described. In the second embodiment, the same configuration as in the first embodiment will not be described. 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, the wearable device 40 acquires a first token in the same manner as in the first embodiment. Furthermore, 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 obtain various information from the payment server 20. The code display information described in the first embodiment is an example of information obtained using the second token.

[0145] In the second embodiment, an example is given where the wearable device 40 obtains configuration information from the payment server 20 based on the second token. Furthermore, an example is given where the configuration 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 only some payment methods. When the wearable device 40 obtains configuration information from the payment server 20, it 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 obtained from the payment server 20 on the display unit 45, or may only display a portion of it.

[0146] Figure 9 shows an example of a screen displayed on the wearable device 40. For example, once synchronization with the mobile terminal 30 is complete, the wearable device 40 can switch between a state in which barcode C420A is displayed and a state in which two-dimensional code C420B is displayed, as shown in the upper part of Figure 9. This point is as explained 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 showing the content of the setting information on the display unit 45, as shown in the lower part of Figure 9.

[0147] In the lower example of Figure 9, the settings screen SC44 displays the electronic money "AAA Cash" as the payment source information specified by the user. The user can switch between the state in which code C420 is displayed and the state in which the payment source information is displayed by performing operations such as swiping on the operation unit 44 of the wearable device 40. In the second embodiment, the case in which the payment source is changed from the mobile terminal 30 is given as an example, 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 obtains setting information from the payment server 20 that indicates the settings for the payment service specified by the user. Based on the setting information, the wearable device 40 displays a setting screen SC44 on the display unit 45 that shows the settings for the payment source, etc., specified by the user from the mobile terminal 30. In this way, the payment system 1 enhances user convenience. The details of the second embodiment will be described below.

[0149] [2-2. Functions realized in the payment system of the second embodiment] Figure 10 shows an example of the functions implemented in the payment system 1 of the second embodiment. Similar to the first embodiment, the components implemented in the payment system 1 can be configured by combining them into a single device or by further distributing them among multiple 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 mobile terminal 30 may be the primary entity that transmits the code display request. Alternatively, in the second embodiment, instead of a payment method that displays a code on the wearable device 40, a payment method that utilizes the communication function of the wearable device 40 to perform the payment may be used.

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

[0152] [2-2-1. Functions implemented by the ID server] For example, the functions of the ID server 10 may be the same as those of the first embodiment.

[0153] [2-2-2. Functions implemented by the payment server] For example, the payment server 20 includes a configuration information acquisition unit 208 and a configuration information transmission unit 209. Each of the configuration information acquisition unit 208 and the configuration information transmission unit 209 is implemented by the control unit 21. Other functions shown in Figure 10 may be the same as in the first embodiment. For example, the code display request receiving unit 204 may be the same as in the first embodiment. The code display request receiving unit 204 may receive code display requests relating to the display of a code used in a payment service, and may include a user ID. The code display request receiving unit 204 may receive code display requests from a wearable device 40. The code display request receiving unit 204 may receive code display requests from a 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 an encrypted user ID.

[0154] [Configuration Information Acquisition Unit] The setting information acquisition unit 208 acquires setting information relating to the payment service, which is the setting specified on the user's mobile terminal 30 in the payment service. In the second embodiment, since the setting information is stored in the payment database DB2, 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 can acquire the setting information from the other database. If the setting information is recorded on a computer or information storage medium other than the payment server 20, the setting information acquisition unit 208 can acquire the setting information from the other computer or information storage medium.

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

[0156] [Configuration Information Transmission Unit] The configuration information transmission unit 209 transmits configuration information to a wearable device 40 that can be connected to the mobile terminal 30. For example, the configuration information transmission unit 209 transmits configuration information to the wearable device 40 directly or indirectly. The meanings of direct and indirect are as described in the first embodiment. For example, the configuration information transmission unit 209 may transmit only configuration information to the wearable device 40, or it may transmit other information along with the configuration information.

[0157] In the second embodiment, the setting information transmission unit 209 transmits setting information and code display information related to the display of a code to the wearable device 40. That is, the setting information transmission 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 for transmitting the code display information may be the same as in the first embodiment. The setting information transmission unit 209 may include the code display information transmission unit 206 described in the first embodiment. The setting information transmission unit 209 may transmit the setting information and the code display information separately to the wearable device 40.

[0158] [2-2-3. Functions implemented on mobile devices] The functions implemented 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 implemented by a control unit 41. Other functions shown in Figure 10 may be the same as in the first embodiment. In the second embodiment, the case in which the code display request transmission unit 405 corresponds to the request transmission unit is given as an example. The request transmission unit transmits a predetermined request to the payment server 20. The predetermined request may be a code display request or a setting information request for obtaining setting information. That is, setting information may be obtained 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 configuration information request to the payment server 20 for obtaining configuration information, separate 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 configuration information request is data in a predetermined format for requesting configuration information. The configuration information request may be in any format, for example, a format corresponding to the API specifications of the payment server 20. The configuration information request may include any information. For example, the configuration information request may include a first token, a 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 that allows the user ID to be searched, a login account, other information that allows the account to be searched, or other information.

[0161] [Configuration Information Receiving Unit] The configuration information receiving unit 408 receives configuration information from the payment server. The configuration information receiving unit 408 also receives configuration information from a computer that acquires configuration information. For example, the configuration information receiving unit 408 receives configuration information directly or indirectly from a computer that manages configuration information. The meanings of "directly" and "indirectly" are as described above. In the second embodiment, as in the first embodiment, the payment server 20 manages the configuration information, so the configuration information receiving unit 408 receives configuration information from the payment server 20. That is, the configuration information receiving unit 408 receives configuration information from the configuration information transmitting unit 209 of the payment server 20. In the second embodiment, the data storage unit 400 may store the configuration information received by the configuration information receiving unit 408.

[0162] [Processing Execution Unit] The processing execution unit 409 executes processing related to payment services based on the configuration information. Processing related to payment services is processing that is performed based on the configuration information. For example, the processing execution unit 409 may execute processing to display the settings indicated by the configuration information on the display unit 45 as processing related to payment services. The processing execution unit 409 may also execute processing to encode the configuration information into code C420 as processing related to payment services. The processing execution unit 409 may also execute processing to transmit the configuration information to the store terminal 50 via wireless communication as processing related to payment services. The processing execution unit 409 may also execute processing to send a payment request to the payment server 20 based on the configuration information as processing related to payment services.

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

[0164] [2-3. Processing performed in the payment system of the second embodiment] Figure 11 shows an example of the process performed by the payment system 1 of the second embodiment. The control units 11, 21, 31, 41, and 51 execute programs (for example, a mobile terminal application, a wearable device application, or other programs) stored in the storage units 12, 22, 32, 42, and 52, respectively, thereby executing the process shown in Figure 11. It is assumed that the mobile terminal 30 and the wearable device 40 have already been paired before the process shown in Figure 11 is executed.

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

[0166] Based on user input, the wearable device 40 displays the settings indicated by the setting information on the setting details screen SC44 (S204). As explained with reference to Figure 9, based on user input, the wearable device 40 switches between a state where the code screen SC42 is displayed and a state where the setting details screen SC44 is displayed. When the code screen SC42 is 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 this process ends.

[0167] [2-4. Summary of the second embodiment] The payment system 1 of the second embodiment acquires setting information related to the settings of the payment service. The payment system 1 transmits the setting information to a wearable device 40 that can be connected to a mobile terminal 30. This allows the wearable device 40 to acquire the setting information, thereby improving 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, thus improving user convenience. For example, the user does not need to make settings on the wearable device 40, thus improving user convenience. For example, the wearable device 40 does not need to have functions such as setting the payment source, so the development cost of the wearable device application can also be reduced.

[0168] Furthermore, payment system 1 receives a code display request that includes a user ID. Based on the user ID included in the code display request, payment system 1 obtains configuration information. This allows payment system 1 to obtain the configuration information in a single, continuous process upon receiving a code display request and transmit it to the wearable device 40, thereby improving user convenience.

[0169] Furthermore, the payment system 1 transmits configuration information and code display information related to the display of a code to the wearable device 40. This allows the payment system 1 to acquire configuration information in a series of steps for acquiring code display information and transmit it to the wearable device 40, thereby improving user convenience.

[0170] Furthermore, the wearable device 40 sends a predetermined request to the payment server 20. The wearable device 40 receives configuration information from the payment server 20. The payment system 1 executes processing related to the payment service based on the configuration information. This allows the wearable device 40 to perform flexible processing according to the configuration information, thereby improving user convenience. For example, if the wearable device 40 displays the settings indicated by the configuration information, the user can check the settings on the wearable device 40, thus improving user convenience for the payment system 1.

[0171] [3. Variant] This disclosure is not limited to the embodiments described above. This disclosure may be modified as appropriate without departing from the spirit of this disclosure.

[0172] [3-1. Modified Examples of the First Embodiment] Figure 12 shows an example of the functions realized in Modification 1-1 to Modification 1-3. For example, the payment server 20 includes a combination storage unit 210, a usage restriction unit 211, and a restriction release unit 212. Each of the combination storage unit 210, the usage restriction unit 211, and the restriction release unit 212 is realized by the control unit 21.

[0173] [Variation 1-1] For example, in the first embodiment, the payment server 20 is shown to obtain a mobile terminal ID and a wearable device ID from the wearable device 40. The payment server 20 may also 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 when fraud occurs in the payment service, when there is a risk of fraud in the payment service, or when a report is made by a user (for example, a report of loss of the mobile terminal 30 or the wearable device 40).

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

[0175] For example, the wearable device 40 can send the mobile terminal ID and wearable device ID to the payment server 20 at any time. In the modified example 1-1, we take the case where the wearable device 40 sends the mobile terminal ID and wearable device ID to the payment server 20 after the second token has been issued and before the code display request has been sent. The wearable device 40 may also send the second token to the payment server 20 along with the mobile terminal ID and wearable device ID.

[0176] The wearable device 40 may also transmit the mobile terminal ID and wearable device ID to the payment server 20 at other times. For example, the wearable device 40 may transmit the mobile terminal ID and 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 wearable device ID, to the payment server 20. Alternatively, for example, when issuing the first token, 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.

[0177] For example, the wearable device 40 may transmit the mobile terminal ID and the wearable device ID when sending a code display request. That is, the wearable device 40 may send a code display request to the payment server 20 that includes the mobile terminal ID and the wearable device ID. 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 user's wearable device 40, the combination storage unit 210 stores the combination of the mobile terminal ID and the wearable device ID in the payment database DB2, associating it with the user's user ID. The payment server 20 may also receive a user ID from the wearable device 40 along with the mobile terminal ID and wearable device ID, or it may receive other information (e.g., a temporary ID) that allows the user ID to be searched. The method by which the payment server 20 identifies the user ID may be a publicly 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 the combination of the mobile terminal ID and the wearable device ID. Restricting the use of the mobile terminal 30 means preventing the use of payment services from the mobile terminal 30. For example, preventing the display of code C300 on the mobile terminal 30, preventing the execution of a payment even if code C300 displayed on the mobile terminal 30 is read, or preventing the execution of a payment even if a request for payment execution is received from the mobile terminal 30 constitutes restricting the use of the mobile terminal 30. The usage restriction unit 211 may associate a usage restriction flag in the payment database DB2 with the mobile terminal ID of the mobile terminal 30 subject to usage restriction, indicating whether or not it is subject to usage restriction. 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 the wearable device 40 means preventing the use of payment services from the wearable device 40. For example, preventing the display of code C420 on the wearable device 40, preventing payment from being executed even if code C420 displayed on the wearable device 40 is read, or preventing payment from being executed even if a request for payment execution is received from the wearable device 40 are equivalent to restricting the use of the wearable device 40. The usage restriction unit 211 may associate a usage restriction flag indicating whether or not the wearable device 40 subject to usage restriction is subject to usage restriction with the wearable device ID of the wearable device 40 subject to usage restriction in the payment database DB2. The usage restriction unit 211 may restrict the use of the wearable device 40 based on the usage restriction flag.

[0181] For example, the usage restriction unit 211 restricts the use of at least one of the mobile terminal 30 and the wearable device 40 based on usage restriction data indicating usage restrictions corresponding to a combination of mobile terminal ID and wearable device ID. The usage restriction data is 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 table format, mathematical formula format, part of a program, machine learning model, or other format. Based on the usage restriction data, the usage restriction unit 211 determines whether to restrict a user's use of the mobile terminal 30, restrict the user's use of the wearable device 40, or restrict the use of both.

[0182] Figure 13 shows an example of usage restriction data. In the example in Figure 13, the usage restriction data indicates usage restrictions according to the blacklist. The blacklist is a list that shows at least one of the mobile terminal IDs and wearable device IDs that are subject to usage restrictions. Modification 1-1 gives an example in which the blacklist is stored in the data storage unit 200. The blacklist may be stored in a computer other than the payment server 20, or in an external information storage medium.

[0183] The method for adding at least one of the mobile terminal ID and wearable device ID to the blacklist may be a publicly known method. For example, the payment server 20 may receive a blacklist created by the administrator from the administrator's terminal, and record the blacklist in the data storage unit 200. Alternatively, instead of receiving the blacklist itself from the administrator's terminal, the payment server 20 may receive at least one of the mobile terminal ID and wearable device ID specified by the administrator and add that at least one to the blacklist stored in the data storage unit 200.

[0184] Furthermore, at least one of the mobile device IDs and wearable device IDs to be added to the blacklist may be automatically identified by the payment service rather than being specified by the administrator. For example, the payment server 20 may determine whether the fraud detection conditions for fraud detection are met based on the usage status of the payment service (e.g., payment location, payment amount, or payment date and time), and based on the result of this determination, at least one of the mobile device IDs and wearable device IDs may be added to the blacklist. Fraud detection may be performed by 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 the mobile terminal IDs and wearable device IDs subject to usage restrictions based on usage restriction data and a blacklist, and restricts the use of that at least one. That is, the usage restriction unit 211 identifies a combination of mobile terminal IDs and wearable device IDs stored in the payment database DB2, determines whether at least one of the identified mobile terminal IDs and wearable device IDs has been added to the blacklist, and decides whether to restrict the use of at least one of the identified mobile terminal IDs and wearable device IDs based on the result of this determination and the usage restriction data.

[0186] For example, if a mobile terminal ID is added to a blacklist, and the wearable device ID associated with that mobile terminal ID is not added to the blacklist (as in pattern (1) in Figure 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 aforementioned usage restriction process on both the mobile terminal 30 and the wearable device 40 whose combinations are 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 that mobile terminal ID.

[0187] For example, if a mobile terminal ID is not added to the blacklist, but the wearable device ID associated with that mobile terminal ID is added to the blacklist (as in pattern (2) in Figure 13), the usage restriction unit 211 will not restrict the use of the mobile terminal 30 indicated by that mobile terminal ID, but will restrict the use of the wearable device 40 indicated by that wearable device ID. In this case, of the mobile terminal 30 and wearable device 40 whose combination is stored in the payment database DB2, the usage restriction unit 211 will not perform the aforementioned usage restriction processing on the mobile terminal 30, but will perform the aforementioned usage restriction processing on the wearable device 40.

[0188] For example, if a mobile terminal ID is added to a blacklist and the wearable device ID associated with that mobile terminal ID is also added to the blacklist (as in pattern (3) in Figure 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 performs the aforementioned usage restriction process on both the mobile terminal 30 and the wearable device 40 whose combinations are stored in the payment database DB2.

[0189] The usage restriction processing by the usage restriction unit 211 is not limited to the above example. The usage restriction unit 211 may perform usage restrictions according to the combination of the mobile terminal ID and the wearable device ID. For example, the usage restriction unit 211 may perform usage restrictions 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, based on a usage restriction flag associated with the mobile terminal ID of a 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 a wearable device ID, based on a usage restriction flag associated with the wearable device ID of a certain wearable device 40.

[0190] The payment system 1 in Modification 1-1 stores the combination of the mobile terminal ID and the wearable device ID received from the wearable device 40. Based on this combination, the payment system 1 restricts the use of at least one of the mobile terminal 30 and the wearable device 40. This allows the payment system 1 to enhance the security of the payment service. For example, with usage restriction data like that shown in Figure 13, the payment system 1 can implement usage restrictions according to each pattern shown in the usage restriction data, thus increasing the flexibility of the payment service.

[0191] [Variation 1-2] For example, in Modification 1-1, the restriction 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 restriction means making the at least one of the restricted devices available for use with the payment service again. In other words, lifting the restriction means returning to the state before the restriction was imposed. Modification 1-2 gives an example of a case where the lifting is performed according to the combination of the mobile terminal 30 and the wearable device 40. For example, removal from the blacklist or changing the value of the usage restriction flag constitutes lifting the restriction.

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

[0193] For example, the administrator of a payment service removes at least one of the mobile device ID and wearable device ID from the blacklist. Instead of the administrator manually removing the ID from the blacklist, the removal may be performed automatically by a program. For example, at least one of the mobile device ID and wearable device ID may be automatically removed from the blacklist after a predetermined period of time has elapsed since it was added. Removal from the blacklist may be performed by a machine learning model. Publicly known methods may also be used for removal from the blacklist.

[0194] For example, the restriction removal unit 212 removes the restriction on at least one of the mobile terminal 30 and the wearable device 40 based on restriction removal data indicating the removal of the restriction corresponding to the combination of the mobile terminal ID and the wearable device ID. The restriction removal data is stored in the data storage unit 200. The restriction removal data may be in any format. For example, the restriction removal data may be in table format, mathematical formula format, part of a program, machine learning model, or other format of data. Based on the restriction removal data, the restriction removal unit 212 determines whether to remove the restriction on the mobile terminal 30, the restriction on the wearable device 40, or the restriction on both.

[0195] Figure 14 shows an example of restriction removal data. In the example in Figure 14, the restriction removal data indicates the removal of restrictions in response to removal from the blacklist. For example, the restriction removal unit 212 identifies at least one of the mobile terminal ID and wearable device ID whose usage restrictions are lifted based on the restriction removal data and the blacklist, and lifts the usage restrictions on that at least one.

[0196] For example, if a mobile device ID is added to a blacklist, and the wearable device ID associated with that mobile device ID is not added to the blacklist (as in pattern (1) in Figure 13), and then the mobile device ID is removed from the blacklist, the restriction removal unit 212 will remove the usage restrictions on both the mobile device 30 indicated by the mobile device ID and the wearable device 40 indicated by the wearable device ID. In this case, the restriction removal unit 212 will perform the aforementioned restriction removal process on both the mobile device 30 and the wearable device 40 whose combinations are stored in the payment database DB2.

[0197] For example, if a mobile device ID is not added to the blacklist, but the wearable device ID associated with that mobile device ID is added to the blacklist (as in pattern (2) in Figure 13), and then the wearable device ID is removed from the blacklist, the restriction removal unit 212 removes the usage restriction on the wearable device 40 indicated by that wearable device ID. In this case, since the use of the mobile device 30 indicated by that mobile device ID is not restricted in the first place, the restriction removal process is not performed on the mobile device 30. The usage restriction unit 211 then performs the aforementioned restriction removal process on the wearable device 40, out of the mobile device 30 and wearable device 40 whose combination is stored in the payment database DB2.

[0198] For example, if a mobile device ID is added to a blacklist, and the wearable device ID associated with that mobile device ID is also added to the blacklist (as shown in pattern (3) in Figure 13), and then the mobile device ID is removed from the blacklist, the restriction removal unit 212 will remove the usage restriction on the mobile device 30 indicated by that mobile device ID. In this case, the usage restriction unit 211 will execute the aforementioned restriction removal process on the mobile device 30, out of the mobile device 30 and wearable device 40 whose combination is stored in the payment database DB2. The usage restriction on the wearable device 40 will not be removed.

[0199] For example, if a mobile device ID is added to a blacklist, and the wearable device ID associated with that mobile device ID is also added to the blacklist (as shown in pattern (3) in Figure 13), and then the wearable device ID is removed from the blacklist, the restriction removal unit 212 will not remove the usage restriction. In this case, the use of the mobile device 30 indicated by the mobile device ID and the wearable device 40 indicated by the wearable device ID will remain restricted.

[0200] For example, if a mobile device ID is added to a blacklist, and the wearable device ID associated with that mobile device ID is also added to the blacklist (as shown in pattern (3) in Figure 13), and both the mobile device ID and the wearable device ID are removed from the blacklist, the restriction removal unit 212 removes both the usage restriction on the mobile device 30 indicated by the mobile device 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 restrictions according to the combination of the mobile terminal ID and the wearable device ID. For example, the restriction removal unit 212 may remove restrictions without using a blacklist or restriction removal data. The restriction removal unit 212 may remove the restriction on a wearable device 40 indicated by a wearable device ID associated with a mobile terminal ID, based on a usage restriction flag associated with the mobile terminal ID of a certain mobile terminal 30. Conversely, the restriction removal unit 212 may remove the restriction on a mobile terminal 30 indicated by a mobile terminal ID associated with a wearable device ID, based on a usage restriction flag associated with the wearable device ID of a certain wearable device 40.

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

[0203] [Modification 1-3] For example, in the first embodiment, the wearable device 40 was shown to display a payment code C420, but the wearable device 40 may also display a code for a point card. In the modified example 1-3, the payment code C420 described in the first embodiment is referred to as the first code C420, and the code for a point card is referred to as the second code.

[0204] Figure 15 shows an example of the hardware configuration in Modification 1-3. As shown in Figure 15, the payment system 1 includes a point server 60. The point server 60 is a server computer that provides point services to users. The point service is a service in which users can use points. For example, the point server 60 includes a control unit 61, a storage unit 62, and a communication unit 63. The hardware configurations of the control unit 61, the storage unit 62, and the communication unit 63 may be the same as those of the control unit 11, the storage 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. If these operators are different, they are assumed to be in a cooperative relationship and able to provide each other with information as appropriate.

[0205] Figure 16 shows an example of a screen displayed on the wearable device 40 in Modification 1-3. The example in Figure 16 differs from the example in Figure 3 in that the wearable device 40 displays a point card screen SC45, which includes a second code C450 as a point card, on the display unit 45. The user can switch between displaying the code screen SC42 and the point card screen SC45 by operating the operation unit 44 (for example, by swiping). In the example in Figure 16, the second code C450 is shown to be a barcode, but the second code C450 may also be a two-dimensional code. The second code C450 may be a code not only for the user to earn points, but also for the user to make payments with the points they have. The processing flow for making payments with points may be the same as the processing used in known point cards.

[0206] Figure 17 shows an example of the functions implemented in the payment system 1 in the modified versions 1-3 to 1-6. In modified version 1-3, the example is given where the wearable device 40 communicates directly with the point server 60 to display the second code C450. However, the wearable device 40 may also display the second code C450 by communicating indirectly with the point server 60 via the payment server 20. In this case, the second code display request, which will be described later, is sent from the wearable device 40 to the payment server 20. The payment server 20 only needs to obtain the second code display information from the point server 60 and send 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 the first code C420. For the sake of explanation, the only difference is that the code C420 in the first embodiment is written as the 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, the explanation of the first code display request receiving unit 204 can be understood by replacing the word "code" with "first code" in the explanation of the code display request receiving unit 204 in the first embodiment.

[0208] In Modification 1-3, the code display information transmission unit 206 described in the first embodiment is a first code display information transmission unit 206 that transmits first code display information relating to the display of a first code C420 used in a payment service to a wearable device 40. For the sake of explanation, the only difference is that the code C420 in the first embodiment is written as the first code C420, and the processing of the first code display information transmission unit 206 is the same as that of the code display information transmission unit 206 described in the first embodiment. That is, in the description of the code display information transmission unit 206 in the first embodiment, the word "code" should 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 transmission unit 602, and a point processing unit 603. The data storage unit 600 is implemented by a storage unit 62. The second code display request receiving unit 601, the second code display information transmission unit 602, and the point processing unit 603 are each implemented by a control unit 61. The data storage unit 600 stores the point database DB3.

[0210] Figure 18 shows an example of a points database DB3. The points database DB3 is a database that stores various information about multiple users in a points service. For example, the points database DB3 stores user ID, password, point card ID, and point balance. Other information may also be stored in the points database DB3. For example, the points database DB3 may store usage history information related to the usage history of the points service.

[0211] Modification 1-3 describes a case where the user ID of a certain user stored in the payment database DB2 is the same as the user ID of the same user stored in the points database DB3, but these user IDs may be different. If these user IDs are different, a relational database showing the relationship between the user ID stored in the payment database DB2 and the user ID stored in the points database DB3 is 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 another computer other than the payment server 20 and the points server 60, or on an external information storage medium.

[0212] The point card ID is point identification information that can identify the points held by the user. Point identification information may be other information besides the point card ID. For example, the point identification information may be a user ID. That is, the user identification information in a point service may correspond to the point identification information. In Modification 1-3, the point card ID is given as an example where it is a temporary ID, similar to the 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 from the wearable device 40 regarding the display of the second code C450. The second code display request differs from the first code display request in that it concerns the display of the second code C450, but is otherwise the same as 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 that conforms to the API specifications of the point server 60.

[0214] For example, the second code display request may include any information. For example, the second code display request may include a second token, a user ID, information that makes the user ID searchable (e.g., a temporary ID), a login account, information that makes the login account searchable (e.g., a temporary ID), a mobile device ID, a wearable device ID, or other information.

[0215] In Modification 1-3, the second code display request includes a second token. The point server 60 requests the settlement server 20 to verify the second token included in the second code display request. When the settlement server 20 receives 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 settlement server 20.

[0216] For example, the second code display information transmission unit 602 transmits second code display information to the wearable device 40 regarding 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 code C420. In the modified example 1-3, the case in which the point card ID corresponds to the second code display information is given as an example, but the second code display information may also include other information other than the point card ID (for example, a URL). The second code display information may also be image data of the second code C450.

[0217] For example, the second code display information transmission 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 will be issued in a random form of letters, numbers, symbols, or a combination thereof. The second code display information transmission unit 602 issues a point card ID that is not the same as another point card ID. If the point card ID has an expiration date, the second code display information transmission unit 602 issues a point card ID that is not the same as another point card ID that is still within its expiration date.

[0218] In Modification 1-3, the second code display information transmission 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 transmission unit 602 transmits the second code display information to the wearable device 40 on the condition that the second token is verified. Here, verification of the second token means that the validity of the second token is confirmed. If the second token is not used, the second code display information transmission 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 to provide point services to the user. The point service process may be the same as known processes. For example, the point processing unit 603 obtains the 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 obtained from the store terminal 50 is stored in the point database DB3. If the point processing unit 603 determines that the point card ID obtained from the store terminal 50 is stored in the point database DB3, it executes a process to increase the point balance associated with the point card ID, provided that a payment is executed. The point server 60 only needs to obtain information from the payment server 20 indicating that a payment has been executed. The point balance may be increased immediately or after a certain amount of time has elapsed. The point processing unit 603 transmits the result of the process performed by the point processing unit 603 to the store terminal 50.

[0220] In Modification 1-3, the code display request transmission unit 405 and the code display information receiving unit 406 described in the first embodiment are referred to as the first code display request transmission unit 405 and the first code display information receiving unit 406, respectively. For the sake of explanation, the only difference is that the code C420 in the first embodiment is written as the first code C420, and the processing of the first code display request transmission unit 405 and the first code display information receiving unit 406 is the same as that of the code display request transmission unit 405 and the code display information receiving unit 406 described in the first embodiment. That is, in the description of the first code display request transmission unit 405 and the first code display information receiving unit 406 in the first embodiment, the word "code" should be read as "first code".

[0221] The wearable device 40 in the modified example 1-3 includes a second code display request transmission unit 410 and a second code display information receiving unit 411. Each of the second code display request transmission unit 410 and the second code display information receiving unit 411 is implemented by a control unit 41.

[0222] The second code display request transmission unit 410 transmits a second code display request to the point server 60. For example, the second code display request transmission unit 410 transmits a second code display request to the point server 60 directly or indirectly. The meanings of "directly" and "indirectly" are as described above. In the modified example 1-3, since the point server 60 acquires the code display information, the second code display request transmission unit 410 transmits a second code display request to the point server 60. If another computer other than the point server 60 (for example, the payment server 20) acquires the second code display information, the second code display request transmission unit 410 only needs to transmit 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 "directly" and "indirectly" are as described above. In the modified 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] In the modified example 1-3, the display control unit 407 displays the second code C450 on the display unit 45 based on the second code display information. For example, if the point card ID corresponds to the second code display information, the display control unit 407 encodes the point card ID and generates image data for the second code C450. Based on this image data, the display control unit 407 displays the second code C450 on the display unit 45. If the image data for 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 the image data.

[0225] In the modified example 1-3, the payment system 1 transmits first code display information to the wearable device 40. The payment system 1 also 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] [Modifications 1-4] For example, in Modification 1-3, the case where the first code display information transmission unit 206 and the second code display information transmission unit 602 are implemented by separate servers is given as an example, but the first code display information transmission unit 206 and the second code display information transmission unit 602 may also be implemented by the same server. In Modification 1-4, the case where the first code display information transmission unit 206 and the second code display information transmission unit 602 are implemented by the settlement server 20 is given as an example. The first code display information transmission unit 206 of the settlement server 20 is as described in Modification 1-3.

[0227] For example, the second code display information transmission unit 602 of the payment server 20 is implemented by the control unit 21. The payment server 20 may also include a second code display request receiving unit 601. The second code display request receiving unit 601 of the payment server 20 is implemented by the control unit 21. If the first code display request and the second code display request are not made separately but are combined into a single code display request, the code display request receiving unit 204 described in the first embodiment may receive that single 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 Modification 1-3 in that the wearable device 40 sends the second code display request to the payment server 20 instead of the point server 60, but is otherwise the same. The second code display request receiving unit 601 of the payment server 20 only needs to receive the second code display request from the wearable device 40 directly or indirectly.

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

[0230] Furthermore, the payment server 20 may generate the second code display information itself instead of 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 transmission unit 602 of the payment server 20 transmits the second code display information generated by the payment server 20 to the wearable device 40. In addition, the first code display information transmission unit 206 and the second code display information transmission unit 602 may transmit the first code display information and the second code display information to the wearable device 40 together at once, rather than transmitting them separately.

[0231] In the modified version 1-4 of the payment system 1, the first code display information transmission unit 206 and the second code display information transmission unit 602 are implemented by the same server. This simplifies the configuration of the payment system 1 because the functions for transmitting the first code display information and the functions for transmitting the second code display information can be combined on the same server. For example, the payment system 1 can transmit the first code display information and the second code display information together at once. The wearable device 40 no longer needs to obtain the first code display information and the second code display information from separate servers.

[0232] [Variations 1-5] For example, a user may be using a payment service but not possessing a point card (i.e., not using the point service). In this case, the processing in Modification 1-3 and 1-4 may be performed only for users who possess a point card. The point server 60 in Modification 1-5 includes an association determination unit 604. The association determination unit 604 is implemented by the control unit 61. The association determination unit 604 determines whether or not information related to the second code C450 is associated with a user. In Modification 1-5, the information related to the second code C450 is the user ID in the point database DB3, or various information associated with that user ID (e.g., point balance). For users who do not possess a point card, this information is not stored in the point database DB3.

[0233] In Modification 1-5, similar to Modification 1-3, an example is given in which the second code display information transmission unit 602 is implemented 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 or not 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 the information regarding 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 the information regarding the second code C450 is not associated with the user.

[0234] In the modified example 1-5, the second code display information transmission unit 602 transmits the second code display information to the wearable device 40 based on the determination result of the association determination unit 604. For example, if the second code display information transmission unit 602 determines that information regarding the second code C450 is not associated with the user, it does not transmit the second code display information to the wearable device 40. If it determines that information regarding the second code C450 is associated with the user, it transmits the second code display information to the wearable device 40. When combining modified examples 1-4 and 1-5, the association determination unit 604 can be implemented by the payment server 20.

[0235] In the modified example 1-5, the payment system 1 determines whether or not information regarding the second code C450 is associated with the user. Based on the result of this determination, the payment system 1 transmits the second code display information to the wearable device 40. This prevents the second code C450 from being displayed on the wearable device 40 of users for whom the second code C450 is unnecessary (wearable device 40 of users who do not possess a point card).

[0236] [Variations 1-6] For example, as shown 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 receive a reward through payment. In Modifications 1-3 to 1-5, points were explained as an example of a reward, but the reward is not limited to points. For example, the reward may be a discount obtained by using a coupon, or a product or service obtained by using a coupon. The processing required for displaying the first code C420 and the second code C450 may be the same as in Modifications 1-3 to 1-5.

[0237] In the modified example 1-6, the display control unit 407 displays the other of the first code C420 and the second code C450 when one of the two is read. For example, the display control unit 407 displays the second code C450 when the first code C420 is read. 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 only needs to detect that the first code C420 has been read by receiving the 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 only needs to detect that the second code C450 has been read based on the notification from the point server 60. When the display control unit 407 receives this notification, it displays the first code C420.

[0239] In the payment system 1 of the modified example 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 receive benefits through payment. When either the first code C420 or the second code C450 is read, the payment system 1 displays the other of the two codes. This eliminates the need for the user to perform an operation to switch between the display of the first code C420 and the second code C450, thus improving user convenience.

[0240] [Variations 1-7] For example, the mobile terminal 30 may be able to connect to multiple wearable devices 40. In Modification 1-7, multiple wearable devices 40 pair with one mobile terminal 30. The multiple wearable devices 40 may pair with the mobile terminal 30 at the same time, or they may pair separately without pairing with the mobile terminal 30 at the same time. 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 wearable devices 40 may store a second token issued for that wearable device 40, which is issued based on a first token common to all of the 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 all of these wearable devices 40.

[0242] In Modification 1-7, the code display request receiving unit 204 receives a code display request from each of the wearable devices 40, which includes a second token stored in the wearable device 40. The code display information transmitting unit 206 transmits code display information to the wearable device 40 when the second token included in the code display request received from each of the wearable devices 40 has been verified. These processes may be the same as those described in the first embodiment and Modifications 1-1 to 1-6.

[0243] In the modified example 1-7, the payment database DB2 stores the wearable device ID of each wearable device 40 connected to a certain mobile terminal 30, and the second token in association with it. When the second token verification unit 205 performs verification of a second token received from a wearable device 40, it should perform verification based on the second token stored in the payment database DB2 associated 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 the modified example 1-7, each of the multiple wearable devices 40 stores a second token issued for that wearable device 40, which is issued based on a first token common to all of the multiple wearable devices 40. The payment system 1 receives a code display request from each of the multiple wearable devices 40 that includes 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. As a result, the user can use the payment service from multiple wearable devices 40, thus improving user convenience. Furthermore, since separate second tokens can be issued to multiple wearable devices 40 using a common first token, the payment system 1 can simplify the management of the first token.

[0245] [3-2. Modified Examples of the Second Embodiment] Figure 19 shows an example of the functions implemented 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 shortage 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 shortage 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 implemented by the control unit 21.

[0246] [Variation 2-1] For example, in the second embodiment, the configuration information is given as an example of a case where the configuration information indicates the settings regarding the payment source in the payment service. The wearable device 40 may not have any restrictions on the payment source, or it may support only some payment sources. In the modified example 2-1, an example is given of 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 by whether or not the payment source set by the user is a bank account.

[0247] The payment system 1 in Modification 2-1 includes an availability determination unit 213. The availability determination unit 213 determines whether the payment source indicated by the configuration information is available on the wearable device 40. The availability data indicating the payment sources available on 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, machine learning model, or other format. The available payment sources may be defined for each user. In Modification 2-1, the availability data indicates that a bank account is not available as a payment source.

[0248] For example, the availability determination unit 213 determines whether the current payment source is available on the wearable device 40 based on the configuration information stored in the payment database DB2 and the available data. The availability determination unit 213 determines that the payment source is available on the wearable device 40 if the current payment source indicated by the configuration information is not a bank account. The availability determination unit 213 determines that the payment source is not available on the wearable device 40 if the current payment source indicated by the configuration information is a bank account.

[0249] In the modified example 2-1, the setting information transmission unit 209 transmits setting information to the wearable device 40 based on the determination result of the availability determination unit 213. For example, the setting information transmission unit 209 transmits setting information to the wearable device 40 if it is determined that the payment source is available to the wearable device 40. If it is determined that the payment source is not available to the wearable device 40, the setting information transmission unit 209 may not transmit setting information to the wearable device 40, but instead send an error notification or a notification prompting the wearable device 40 to change the payment source.

[0250] In the modified example 2-1, the payment system 1 determines whether the payment source indicated by the configuration information is available on the wearable device 40. Based on the result of this determination, the payment system 1 transmits the configuration information to the wearable device 40. This ensures that the payment system 1 can reliably process payments using an available payment source from the wearable device 40.

[0251] [Modification 2-2] For example, in Modification 2-1, the payment source may be automatically changed. The payment system 1 in Modification 2-2 includes a first automatic change unit 214. The first automatic change unit 214 automatically changes the payment source if it determines that the payment source indicated by the setting information is not available on the 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 the payment database DB2. The first automatic change unit 214 updates the setting information so that any one of the identified payment methods available on the wearable device 40 is set as the payment source. The updated setting information may be transmitted to the wearable device 40.

[0252] In the modified version 2-2, payment system 1 automatically changes the payment source if it is determined that the payment source indicated in the configuration information is not available on the wearable device 40. This eliminates the need for the user to manually change the payment source, thus improving user convenience.

[0253] [Modification 2-3] For example, if a user attempts to make a payment using the wearable device 40, the balance of the 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 in Modification 2-3 includes a balance shortage determination unit 215 and a screen transition unit 216. The balance shortage determination unit 215 determines whether the balance of the payment method used by the user in the payment service is insufficient. Modification 2-3 takes the case where the user pays with points as an example. The payment server 20 in Modification 2-3 can query the points from the points server 60 described in Modification 1-3. For example, the balance shortage determination unit 215 obtains the point balance from the points server 60. The balance shortage determination unit 215 obtains the payment amount from the store terminal 50. The balance shortage determination unit 215 determines whether the balance is insufficient by determining whether the payment amount is greater than the balance.

[0255] Note that the user may make a payment using electronic money. The balance of the electronic money may be stored in the settlement database DB2, or may be stored in another database other than the settlement database DB2. The balance of the electronic money may be stored in another computer other than the settlement 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 settlement database DB2, another database, another computer, or an external information storage medium and make a determination.

[0256] FIG. 20 is a diagram showing an example of screen transition of the wearable device 40 in the modification 2-3. When it is determined that the balance is insufficient, the screen transition unit 216 transitions the screen of the wearable device 40 to a screen for the user to use another settlement means different from the settlement means. For example, when the point balance is insufficient, the screen transition unit 216 transitions from the point card screen SC45 to the code screen SC42.

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

[0258] The payment system 1 of Modification Example 2-3 determines whether the balance of the payment method used by the user in the payment service is insufficient. When it is determined that the balance is insufficient, the payment system 1 causes the screen of the wearable device 40 to transition to a screen for the user to use another payment method different from the payment method. As a result, the user does not have to perform an operation to transition to the screen of another payment method, so the payment system 1 can improve the convenience for the user.

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

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

[0261] For example, when it is determined that the balance of points is insufficient, the second automatic change unit 217 may automatically change the payment source to the 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 change of the payment source, the reading of the code C420 may be requested again. However, in Modification Example 2-4, it is assumed that the payment is automatically executed based on the changed payment source without the code C420 being read again.

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

[0263] [Modification 2-5] For example, Modification 2-3 describes a case where a screen transition occurs based on the result of determining insufficient balance, and Modification 2-4 describes a case where the payment source is automatically changed based on the result of determining insufficient balance. However, auto-charging of the payment method may also be performed based on the balance determination result. The payment system 1 in Modification 2-5 includes an insufficient balance determination unit 215 and an auto-charge execution unit 218. The insufficient balance determination unit 215 may be the same as in Modifications 2-3 and 2-4, but in Modification 2-5, the payment method is assumed to be electronic money. As explained in Modification 2-3, payment may be made with electronic money.

[0264] The auto-charge execution unit 218, when it determines that the balance is insufficient, performs an auto-charge of the payment method based on the insufficient balance. The auto-charge execution unit 218 calculates the insufficient amount based on the difference between the payment amount and the balance of the electronic money. The auto-charge execution unit 218 may decide on the insufficient amount as the charge amount, or it may decide on the charge amount as the insufficient amount plus a predetermined value. The auto-charge execution unit 218 performs an auto-charge based on the determined charge amount. The charge may be performed by a known method. For example, the auto-charge execution unit 218 performs a payment by the amount of the charge amount based on a charge source specified in advance by the user, and performs a process to increase the balance of the payment method. After the auto-charge is performed, the payment is executed.

[0265] In the modified version 2-5, payment system 1 automatically recharges the payment method based on the insufficient balance when it is determined that the balance is insufficient. This eliminates the need for the user to manually recharge when the balance is insufficient when making a payment using the wearable device 40, thus improving user convenience.

[0266] [Modification 2-6] For example, the display control unit 306 of the mobile terminal 30 may display information about the wearable device 40 on the mobile terminal 30. In the example in Figure 2, when the user selects button B304 and synchronization is performed, the display control unit 306 may display the name and wearable device ID of the synchronized wearable device 40 on the code screen SC30 or another screen. The mobile terminal 30 shall obtain the name and wearable device ID of the wearable device 40 from the wearable device 40 during synchronization.

[0267] In the modified version 2-6, the payment system 1 displays information about the wearable device 40 on the mobile terminal 30. This allows the user to check information about the wearable device 40 on the mobile terminal 30, thus improving user convenience.

[0268] [Modification 2-7] For example, in Modification 2-1, a case is given where there are restrictions on the payment methods available from the wearable device 40. If the payment source set by the user is not available from the wearable device 40, the mobile terminal 30 may notify the user of this fact. The notification may be made via a screen on the mobile terminal app, the notification function of the mobile terminal app, a push notification, a banner notification, a pop-up notification, or by other means.

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

[0270] Figure 21 shows an example of a screen displayed on the mobile terminal 30 of the modified 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 Figure 21, the notification unit 219 notifies the user if the user has specified a setting that is not available on the wearable device 40. The notification unit 219 also notifies the user if the user has specified a setting that is available on the wearable device 40.

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

[0272] In the modified version 2-7, the payment system 1 determines whether a setting specified on the mobile terminal 30 is available on the wearable device 40. The payment system 1 notifies the user of the result of this determination. This allows the user to know whether the setting they are trying to specify on the mobile terminal 30 is available on the wearable device 40, thereby improving user convenience.

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

[0274] For example, the functions described as being realized by the ID server 10 may be realized by the settlement server 20, the mobile terminal 30, the wearable device 40, or other computers. The processes described as being realized by the settlement server 20 may be realized by the ID server 10, the mobile terminal 30, the wearable device 40, or other computers. The processes described as being realized by the mobile terminal 30 may be realized by the ID server 10, the settlement server 20, the wearable device 40, or other computers. The processes described as being realized by the wearable device 40 may be realized by the ID server 10, the settlement server 20, the mobile terminal 30, or other computers. The processes described as being realized by the ID server 10, the settlement server 20, the mobile terminal 30, the wearable device 40, or other computers may be shared by a plurality of computers.

[0275] [4. Supplementary Note] For example, the settlement system may have the following configuration.

[0276] [4-1. Supplementary Note of the First Embodiment] For example, the settlement system of the first embodiment may have the following configuration. (1-1) A code display request receiving unit that receives a code display request regarding the display of a code used in the settlement service from a wearable device connectable to a user's mobile terminal in the settlement service, A code display information transmitting unit that transmits code display information regarding the display of the code to the wearable device when the code display request is received, A settlement system including the above. (1-2) The aforementioned mobile terminal stores a mobile terminal application for the user to use the payment service from the mobile terminal, The wearable device stores a wearable device application that allows the user to use the payment service from the wearable device. When both the mobile terminal application and the wearable device application are launched, the mobile terminal and the wearable device synchronize. 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 aforementioned payment system A first token issuing unit that issues a first token used for authentication in the aforementioned payment service, A first token transmission unit that transmits the first token to the mobile terminal, It further includes, The mobile terminal receives the first token from the first token transmission unit, When the wearable device synchronizes with the mobile terminal, it receives the first token from the mobile terminal. The aforementioned payment system A first token receiving unit that receives the first token from the wearable device synchronized with the mobile terminal, A first token verification unit that verifies the first token received from the wearable device, It further includes, The code display information transmission unit transmits the code display information to the wearable device when the first token is verified. The payment system described in (1-1) or (1-2). (1-4) The aforementioned payment system A second token issuing unit that issues a second token used for authentication in the aforementioned payment service, A second token transmission unit that transmits the second token to the wearable device, It further includes, The wearable device receives the second token from the second token transmission unit, 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 transmission unit transmits the code display information to the wearable device when the second token included in the code display request has been verified. The payment system described in any of (1-1) to (1-3). (1-5) The aforementioned 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 from the wearable device, which includes the mobile terminal identification information and the wearable device identification information. The payment system described in any of (1-1) to (1-4). (1-6) The aforementioned payment system A combination storage unit that stores the combination of the mobile terminal identification information and the wearable device identification information received from the wearable device, Based on the above combination, a usage restriction unit restricts the use of at least one of the mobile terminal and the wearable device, The payment systems described in (1-5) further include the following. (1-7) The payment system further includes a restriction release unit that, after the use of at least one of the mobile terminal and the wearable device has been restricted, releases the restriction on at least one based on the combination thereof. The payment system described in (1-5) or (1-6). (1-8) The code display information transmission unit is a first code display information transmission unit that transmits first code display information relating to the display of a first code used in a payment service to the wearable device. The payment system further includes a second code display information transmission unit that transmits second code display information relating to the display of a second code different from the first code to the wearable device. The payment system described in any of (1-1) to (1-7). (1-9) The first code display information transmission unit and the second code display information transmission unit are implemented by the same server. The payment system described in (1-8). (1-10) The payment system further includes an association determination unit that determines whether or not information relating to 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 the determination result of the association determination unit. The payment system described in (1-8) or (1-9). (1-11) The aforementioned code 1 is a code for the user to make a payment, The second code is a code that allows the user to earn a reward through the payment, The payment system further includes a display control unit that displays the other of the first code and the second code when one of the first code and the second code is read. The payment system described in any of (1-8) to (1-10). (1-12) The aforementioned mobile terminal is capable of connecting to multiple of the aforementioned wearable devices. Each of the plurality of wearable devices stores a second token issued for the wearable device, which is issued based on a first token common to the plurality of wearable devices. The code display request receiving unit receives the code display request, which includes the second token stored in the wearable device, from each of the plurality of wearable devices. 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 each of the plurality of wearable devices has been verified. The payment system described in any of (1-1) to (1-11).

[0277] [4-2. 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 related to the settings specified on the user's mobile device in a payment service, A setting information transmission unit that transmits the setting information to a wearable device that can connect to the aforementioned mobile terminal, A payment system that includes this. (2-2) The payment system further includes a code display request receiving unit that receives a code display request relating to the display of a code used in the payment service, the code display request including user identification information capable of identifying 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 relating to the display of the code to the wearable device. The payment system described in (2-2). (2-4) The aforementioned configuration information indicates the settings related to the 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 the determination result of the availability determination unit. The payment system described in either (2-1) or (2-3). (2-5) The payment system further includes a first automatic change unit that automatically changes the payment source if 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 aforementioned payment system A balance shortage determination unit that determines whether or not 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, the screen transition unit transitions the wearable device screen to a screen for the user to use a payment method other than the payment method, A payment system described in any of (2-1) to (2-5), which further includes the above. (2-7) The aforementioned payment system 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 second automatic change unit automatically changes the payment source to another payment method different from the aforementioned payment method if it is determined that the balance is insufficient. A payment system described in any of (2-1) to (2-6), which further includes the above. (2-8) The aforementioned payment system A balance shortage determination unit that 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, an auto-charge execution unit executes an auto-charge of the payment method based on the insufficient balance, A payment system described in any of (2-1) to (2-7), which further includes the above. (2-9) The payment system further includes a display control unit that causes the mobile terminal to display information related to the wearable device. The payment system described in any of (2-1) to (2-8). (2-10) The aforementioned payment system When the setting is specified on the mobile terminal, the availability determination unit 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, A payment system described in any of (2-1) to (2-9), which further includes the above. [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 Storage 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 Reader unit, 60 Point server, 100 Data storage unit, 101 First token request receiving unit, 102 First token issuing unit, 103 First token transmission unit, 104 First token receiving unit, 105 First token verification unit, 200 Data storage unit, 201 Second token request receiving unit, 202 Second token issuing unit, 203 Second token transmission unit, 204 Code display request receiving unit, 205 206 Second Token Verification Unit, 207 Code Display Information Transmission Unit, 208 Set Information Acquisition Unit, 209 Set 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 transmission unit, 411 Second code display information receiving unit, 500 Data storage unit, 501 Settlement execution unit, 600 Data storage unit, 601 Second code display request receiving unit, 602 Second code display information transmission unit, 603 Point processing unit, 604 Association determination unit, DB1 ID database, DB2 Settlement database, DB3 Point database, B301, B302, B303,B304 Button, C300 Code, C300A Barcode, C300B 2D Code, C420 Code, C420A Barcode, C420B 2D Code, SC30 Code Screen, SC31 Completion Screen, SC40 Startup Request Screen, SC41 Synchronization Screen, SC42 Code Screen, SC43 Completion Screen, SC44 Settings Screen, SC45 Point Card Screen.

Claims

[Claim 1] A setting information acquisition unit that acquires setting information related to the settings specified on the user's mobile device in a payment service, A setting information transmission unit that transmits the setting information to a wearable device that can connect to the aforementioned mobile terminal, A payment system that includes this.

Images