JP7744854B2 - Information processing method, computer program, and information processing device - Google Patents

Description

The present invention relates to an information processing method, etc., related to an electronic payment system.

Electronic payment systems, which allow users to pay for goods and services via electronic data transmission, are becoming increasingly common. However, there is a risk that the balances of users' payment methods may be tampered with. To address this issue, technology has been proposed that verifies authenticity online in real time.

Since systems that require real-time communication with a server at the time of payment cannot be applied to offline payments at stores, etc., payment devices have been proposed that do not require real-time checks and can guarantee the legitimate use of electronic money (Patent Document 1). The payment device described in Patent Document 1 updates the current hash value to a new value based on the current hash value and data generated from the payment transaction each time a payment is made, and signs the current hash value using a private key. The payment device also has a signature unit that generates a signature for the hash value, and a secure element that protects the private key and the signature of the hash value.

Japanese Patent Application Laid-Open No. 2016-139291

However, when the payment device is offline, it makes payments based on its own balance. As a result, the balance is guaranteed solely by the payment device, and it is difficult to say that the accuracy of the balance is fully guaranteed. The present invention was made in light of this situation. Its purpose is to provide an information processing method etc. that can guarantee the accuracy of balances using verification information stored on the terminals of multiple users.

The information processing method disclosed in this application is characterized in that a computer capable of communicating with a payment terminal installed in a facility acquires verification information, including identification information for identifying a first user, a balance, and a date and time, from the first user's terminal device, outputs the acquired verification information to terminal devices of multiple other users different from the first user, and determines whether to allow the payment based on the verification information newly acquired from the first user's terminal device at the time of the first user's payment and the verification information acquired via short-range wireless communication from the terminal devices of the multiple other users.

One aspect of the present invention is that balance accuracy can be guaranteed.

FIG. 1 is an explanatory diagram illustrating an example of the configuration of a balance verification system. FIG. 2 is a block diagram illustrating an example of a hardware configuration of a first terminal. FIG. 2 is a block diagram showing an example of the hardware configuration of a store terminal. FIG. 10 is an explanatory diagram illustrating an example of a balance DB. FIG. 10 is an explanatory diagram illustrating an example of a balance DB of other users. FIG. 10 is an explanatory diagram illustrating an example of a regular customer DB. FIG. 10 is an explanatory diagram illustrating an example of a balance DB. 10 is a flowchart illustrating an example of a procedure for a balance distribution process. 10 is a flowchart illustrating an example of a procedure for a balance receiving process. 10 is a flowchart illustrating an example of a procedure for a balance verification process. 10 is a flowchart illustrating an example of a procedure for a balance return process. 10 is a flowchart showing an example of a procedure for exchanging someone else's balance. 10 is a flowchart illustrating an example of a procedure for a deletion process. 10 is a flowchart showing a part of a balance receiving process or a balance exchanging process with another person. FIG. 2 is an explanatory diagram showing an example of a transaction history DB stored in a store terminal. FIG. 2 is an explanatory diagram showing an example of a transaction history DB stored in the terminal. 10 is a flowchart illustrating an example of a recovery process procedure. FIG. 2 is a block diagram illustrating an example of a hardware configuration of a communication device. 10 is a flowchart illustrating an example of a procedure for a balance exchange process. 10 is a flowchart illustrating another example of the procedure of the balance verification process.

Embodiments will be described below with reference to the drawings. Figure 1 is an explanatory diagram showing an example configuration of a balance verification system. The balance verification system 100 includes a first terminal 1, a second terminal 2, a store terminal 3, and a payment system 4. The first terminal 1, the second terminal 2, the store terminal 3, and the payment system 4 are communicatively connected via a network N. The first terminal 1 and the second terminal 2 can communicate with each other via short-range communication. Similarly, the first terminal 1 and the second terminal 2 can communicate with the store terminal 3 via short-range communication. In Figure 1, only one first terminal 1 is shown, but two or more terminals are possible. Only two second terminals 2 are shown, but three or more are preferable. One second terminal 2 is possible, but this is less preferred. Only one store terminal 3 is shown, but two or more terminals are possible.

The first terminal 1 is a terminal device used by a first user who is attempting to electronically pay for goods or other items at a store. The first terminal 1 may be a smartphone, tablet computer, laptop PC (Personal Computer), etc. The second terminal 2 is a terminal device used by a second user other than the first user. The second terminal 2 may be a smartphone, tablet computer, laptop PC, etc. Both the first user and the second user are users who use the balance verification system 100, and the distinction between first and second users is not fixed. Each user is a first user when attempting to electronically pay for goods or other items, and a second user in other situations. When the user is the first user, the terminal functions as the first terminal 1. When the user is the second user, the terminal functions as the second terminal. Therefore, the same terminal can function as both the first terminal 1 and the second terminal 2. Furthermore, it is possible for one terminal to function as both the first terminal 1 and the second terminal 2 simultaneously.

Store terminal 3 is a terminal used by store (facility) staff. Store terminal 3 may be configured as a smartphone, tablet computer, laptop (Personal Computer), etc. Store terminal 3 has functions such as registering products and calculating the total price of products, and may communicate with payment system 4 to perform electronic payments. In this case, store terminal 3 functions as a payment terminal. Store terminal 3 may also be configured as a so-called POS (Point of Sales) cash register (cash register). From the perspective of being usable even in situations such as a power outage after a disaster, it is desirable for store terminal 3 to be configured as a battery-powered device. Payment system 4 is a system that provides electronic payment services.

Figure 2 is a block diagram showing an example of the hardware configuration of the first terminal 1. The first terminal 1 includes a control unit 11, a main memory unit 12, an auxiliary memory unit 13, a communication unit 14, a short-range communication unit 15, a display panel 16, and an operation unit 17. Each unit is connected by a bus B.

The control unit 11 has one or more arithmetic processing devices such as a CPU (Central Processing Unit), MPU (Micro-Processing Unit), GPU (Graphics Processing Unit), etc. The control unit 11 reads and executes a control program 1P (program, program product) stored in the auxiliary storage unit 13, thereby performing various information processing, control processing, etc. related to the first terminal 1 and realizing various functional units.

The main memory unit 12 is a static random access memory (SRAM), dynamic random access memory (DRAM), flash memory, etc. The main memory unit 12 mainly temporarily stores data required by the control unit 11 to perform arithmetic processing.

The auxiliary memory unit 13 is a hard disk or SSD (Solid State Drive), etc., and stores the control program 1P and various DBs (Databases) required for the control unit 11 to execute processing. The auxiliary memory unit 13 stores a balance DB 131, a third party balance DB 132, and a user ID 133. The user ID 133 (identification information) is a unique ID (identification information) assigned by the balance verification system 100 to the first user using the terminal 1. The auxiliary memory unit 13 may be separate from the first terminal 1 and may be an external storage device connected externally.

The communication unit 14 communicates with the payment system 4 via the network N. The control unit 11 may use the communication unit 14 to download the control program 1P from another computer via the network N, etc., and store it in the auxiliary memory unit 13.

The short-range communication unit 15 communicates in accordance with standards such as the NFC (Near Field Communication) standard, the Bluetooth (registered trademark) standard, the IrDA (Infrared Data Association) standard, and the Wi-Fi (registered trademark) standard. The control unit 11 communicates with the terminal via the short-range communication unit 15 via P2P (Peer to Peer) communication.

The display panel 16 can be configured as a liquid crystal panel or an organic EL (Electro Luminescence) display, etc. The operation unit 17 can be configured as, for example, a touch panel incorporated into the display panel 16, and allows the user to perform predetermined operations on the display panel 16. The operation unit 17 can also be used to perform operations on a software keyboard displayed on the display panel 16. The operation unit 17 may also be a hardware keyboard, mouse, etc.

The second terminal 2 has the same configuration as the first terminal 1, and includes a control unit 21, a main memory unit 22, an auxiliary memory unit 23, a communication unit 24, a short-range communication unit 25, a display panel 26, and an operation unit 27. The functions of each unit constituting the second terminal 2 are the same as those of the corresponding units of the first terminal 1, so illustrations and explanations are omitted. In the following explanation, the first terminal will also be referred to as terminal 1, and the second terminal will also be referred to as terminal 2. Furthermore, the first terminal 1 and second terminal 2 will collectively be referred to as terminals.

Figure 3 is a block diagram showing an example of the hardware configuration of a store terminal. The store terminal 3 includes a control unit 31, a main memory unit 32, an auxiliary memory unit 33, a communication unit 34, a short-range communication unit 35, a display panel 36, and an operation unit 37. Each unit is connected by a bus B.

The control unit 31 has one or more processing units such as a CPU, MPU, GPU, etc. The control unit 31 reads and executes the control program 3P (program, program product) stored in the auxiliary storage unit 33, thereby performing various information processing, control processing, etc. related to the store terminal 3 and realizing various functional units such as an acquisition unit, output unit, and judgment unit.

The main memory unit 32 is an SRAM, DRAM, flash memory, etc. The main memory unit 32 mainly temporarily stores data required by the control unit 11 to perform arithmetic processing.

The auxiliary memory unit 33 is a hard disk or SSD, etc., and stores the control program 3P and various DBs required for the control unit 31 to execute processing. The auxiliary memory unit 33 stores a regular customer DB 331 and a balance DB 332. The auxiliary memory unit 33 may be separate from the store terminal 3 and may be an external storage device connected externally.

The communication unit 34 communicates with the payment system 4 via the network N. The control unit 31 may use the communication unit 34 to download the control program 3P from another computer via the network N, etc., and store it in the auxiliary memory unit 33.

The short-range communication unit 35 communicates in accordance with the NFC standard, Bluetooth (registered trademark) standard, infrared communication standard, Wi-Fi standard, etc.

The display panel 36 can be configured as a liquid crystal panel or an organic EL display, etc. The operation unit 37 can be configured as, for example, a touch panel built into the display panel 36, and allows the user to perform predetermined operations on the display panel 36. The operation unit 37 can also be used to perform operations on a software keyboard displayed on the display panel 36. The operation unit 37 may also be a hardware keyboard, mouse, etc.

Next, we will explain the databases used in the balance verification system 100. Figure 4 is an explanatory diagram showing an example of a balance DB. Balance DB 131 is a database provided in terminal 1. Balance DB 131 stores the amount available for electronic payment, etc. Balance DB 131 includes a service code column, an account ID column, a balance column, and a date and time column. The service code column stores a code or ID that identifies the electronic payment service. The account ID column stores the user's ID for the electronic payment service. The balance column stores the amount available for electronic payment by the user. If the electronic payment service is a prepaid type, the balance column stores the charge balance. If the electronic payment service is a postpaid type, the balance column stores the available amount. The date and time column stores the date and time when the value in the balance column became the value stored. In other words, the date and time column stores the date and time when the electronic payment service was most recently used. Note that if a balance DB131 is constructed for each electronic payment service, or if the balance verification system 100 only allows one electronic payment service per user, the balance DB131 does not need to include a service code string. Also, if the corresponding electronic payment service can be identified from the account ID value, the balance DB131 does not need to include a service code string. Terminal 2 also includes a balance DB231 similar to balance DB131.

Figure 5 is an explanatory diagram showing an example of the other users' balance DB. The other users' balance DB 132 is a database provided in the terminal 1. The other users' balance DB 132 stores information such as the amount that other users can electronically pay. The other users' balance DB 132 includes a user ID column, a service code column, a balance column, a date and time column, and a received date and time column. The user ID column stores the user IDs of other users. The user ID is an ID assigned by the balance verification system 100. The service code column stores a code or ID that identifies the electronic payment service. The balance column stores the amount that other users can electronically pay. The balance column, like the balance column in the balance DB 131, stores the charge balance or available amount. The date and time column stores the date and time when the value in the balance column became the value stored. In other words, the date and time column stores the date and time when other users most recently used the electronic payment service. The received date and time column stores the date and time when other users' balance data was received. Note that the received date and time column is not required. Terminal 2 also has a third party balance DB232 similar to third party balance DB132. In the following description, the balance refers to either or both of the charge balance and the available amount.

Figure 6 is an explanatory diagram showing an example of a regular customer DB. Regular customer DB 331 is a database provided in the store terminal 3. Regular customer DB 331 stores information on regular users at each store. Regular customer DB 331 includes a user ID column, a time period column, and a last visit column. The user ID column stores the user IDs of regular users. The time period column stores the time period during which regular users most often visit the store. In Figure 6, the values in the time period column are represented by numbers. For example, 1 indicates 6:00 to 9:00, 2 indicates 9:00 to 12:00, 3 indicates 12:00 to 15:00, 4 indicates 15:00 to 18:00, and 5 indicates 18:00 to 21:00. The last visit column stores the date and time the user last visited the store. In this specification, various logics are considered for determining whether a user is a regular. For example, a user who visits the store three or more times in three days is considered a regular. A user's store visit history can be created from electronic payments and point system usage history. You can also use the purchase history stored on the POS register or the POS server that manages all POS data.

Figure 7 is an explanatory diagram showing an example of a balance DB. Balance DB 332 is a database provided in the store terminal 3. Balance DB 332 stores the balances of regular users. Balance DB 332 includes a user ID column, a service code column, a balance column, and a date and time column. The user ID column stores the user ID. The service code column stores a code or ID that identifies the electronic payment service. The balance column stores the amount that the user can pay electronically. If the electronic payment service is a prepaid type, the balance column stores the charge balance. If the electronic payment service is a postpaid type, the balance column stores the available amount. The date and time column stores the date and time when the value in the balance column became the value stored.

Next, we will explain the processing performed by the balance verification system 100. Before that, we will explain the operating modes of the balance verification system 100. The operating modes of the balance verification system 100 are assumed to be normal mode and disaster mode. Normal mode here refers to a state in which the payment system 4, network N, etc. are functioning normally, and electronic payments can be made normally. Disaster mode refers to a state in which a large-scale disaster such as a widespread earthquake has damaged the network N and payment system 4, making communication with the payment system 4 difficult and preventing electronic payments.

The first user's balance in the electronic payment service is distributed from the first terminal 1 to the second terminal 2 of the second user via the store terminal 3. The second terminal 2 holds the distributed balance of the first user for a predetermined period of time.

In disaster mode, electronic payments are processed differently. Suppose a first user wishes to purchase an item at a store using electronic payment. If a failure occurs in network N or the electronic payment service, the payment cannot be made and the first user cannot purchase the item. However, the balance verification system 100 retrieves from the second terminal 2 the first user's balance that was normally delivered to the second terminal 2, and determines whether the balance held by the first user is valid based on the retrieved balance. If the balance verification system 100 certifies that the first user's electronic payment balance is valid, the first user is permitted to use electronic payment based on that balance.

In order for the balance verification system 100 to verify the balance of a first user more accurately and reliably, it is desirable for the balance collected from the second user to be as recent as possible. It is also desirable to be able to collect balances from as many second users as possible. To achieve this, a network of users is formed based on the store. Here, this network is referred to as a regular customer network. Below, we will explain the processing of the balance verification system 100 using the regular customer network.

(Normal mode)
The process performed by the balance verification system 100 in normal mode will be described. FIG. 8 is a flowchart showing an example of the balance distribution process. The balance distribution process is executed by the store terminal 3. The control unit 31 of the store terminal 3 obtains the balance from the terminal 1 of a first user who visits the store (step S1). For example, the store terminal 3 obtains the balance when the first user makes an electronic payment to purchase a product. The store terminal 3 also transmits a polling signal, and the terminal 1 that receives the polling signal replies with the balance. Alternatively, a service may be provided that provides incentives to users who visit the store. When an operation to notify the user of the visit is performed on the terminal 1, for example, when the terminal 1 reads a two-dimensional code installed in the store, the terminal 1 may transmit the balance to the store terminal 3. Communication between the store terminal 3 and the terminal 1 is assumed to be performed via short-range wireless communication, but may also be via the Internet, etc. The control unit 31 performs polling (step S2). The polling is performed via short-range wireless communication to search for the terminal 2 of a second user who visits the store. The polled terminal 2 returns a user ID. The control unit 31 acquires the returned user ID (step S3). The control unit 31 selects a user ID to be processed from the acquired user IDs (step S4). The control unit 31 references the regular customer DB 331 to determine whether the user with the selected user ID is a regular customer (step S5). If the selected user ID is stored in the regular customer DB 331, the control unit 31 determines that the user is a regular customer. If the current time is not included in the time slot in the time slot column of the regular customer DB 331, the control unit 31 does not need to determine that the user is a regular customer. If the control unit 31 determines that the user with the selected user ID is not a regular customer (NO in step S5), the control unit 31 proceeds to step S7. If the control unit 31 determines that the user with the selected user ID is a regular customer (YES in step S5), the control unit 31 transmits the balance information of the first user to the terminal 2 of the user (step S6). The balance information is the balance plus the first user's user ID and the balance update date and time. The control unit 31 determines whether there is an unprocessed user ID (step S7). If the control unit 31 determines that there is a user ID to be processed (YES in step S7), the process returns to step S4 and processes the unprocessed user ID. If the control unit 31 determines that there is no user ID to be processed (NO in step S7), the process ends. The balance information is also stored in the balance DB 332 of the store terminal 3.

If the number of regular users who have sent their balances during the balance distribution process does not reach the predetermined number, the control unit 31 may repeat the processes from step S2 onwards until the number of regular users who have sent their balances reaches the predetermined number or a predetermined time has passed. Also, polling may not be performed during the balance distribution process. In this case, the control unit 31 generates and sends a packet containing the user ID of the regular user as the destination. If the user ID contained in the packet matches the user ID 233 stored in the auxiliary memory unit 23 on the receiving terminal 2, the control unit 21 accepts the packet. If the user ID contained in the packet does not match the user ID 233, the control unit 21 discards the packet.

Figure 9 is a flowchart showing an example of the balance reception process. The balance reception process corresponds to the balance distribution process and is executed by the terminal 2 that has received polling. The control unit 21 of the terminal 2 receives the polling signal sent by the store terminal 3 (step S21). The control unit 21 sends the user ID 233 stored in the auxiliary memory unit 23 to the store terminal 3 (step S22). The control unit 21 starts the interval timer (step S23). The control unit 21 determines whether balance information has been received from the store terminal 3 (step S24). If the control unit 21 determines that balance information has been received from the store terminal 3 (YES in step S24), it stores the balance information in the other person's balance DB 232 (step S25). If information for the same first user has already been stored, the control unit 21 overwrites it. If the control unit 21 determines that balance information has not been received from the store terminal 3 (NO in step S24), it determines whether a timeout has occurred (step S27). If the control unit 21 determines that a timeout has not occurred (NO in step S27), it returns the process to step S24. If the control unit 21 determines that a timeout has occurred (YES in step S27), or after step S25, it stops the interval timer (step S26) and ends the process.

If polling is not performed during the balance distribution process, even if a packet is received as determined in step S24, if the destination is not the device itself, the control unit 31 determines that the packet has not been received.

The balance distribution process distributes balance information stored on the first terminal 1 used by the first user. The distributed balance information is then stored on the second terminal 2 used by the second user by the balance reception process. As a result, in normal mode, the first user's balance is also stored on the second terminal 2. As mentioned above, the first user also acts as the second user, and the second user also acts as the first user, so users belonging to the regular network will share balances. Because the regular network is a collection of users who visit the same store at the same time, there is a high probability that they will meet in the store, and it is highly likely that their shared balances will be kept up to date.

(Disaster mode)
The process performed by the balance verification system 100 in disaster mode will be described. FIG. 10 is a flowchart showing an example of the balance verification process. The balance verification process is executed by the store terminal 3. A first user visits a store and requests electronic payment to pay for a purchase. The control unit 11 of the terminal 1 sends a payment request to the store terminal 3. The payment request includes a user ID, balance, and service code (optional, same below). The control unit 31 of the store terminal 3 receives the request (step S41). The control unit 31 performs polling (step S42). The signal sent as polling includes the first user's user ID and service code. The control unit 31 starts an interval timer (step S43). The control unit 31 determines whether balance information has been received (step S44). If the control unit 31 determines that balance information (verification information) has not been received (NO in step S44), the process proceeds to step S46. If the control unit 31 determines that the balance information has been received (YES in step S44), it stores the balance information in a temporary storage area provided in the auxiliary storage unit 13 or the like (step S45). The control unit 31 determines whether a timeout has occurred (step S46). If the control unit 31 determines that a timeout has not occurred (NO in step S46), it returns the process to step S44. If the control unit 31 determines that a timeout has occurred (YES in step S46), it stops the interval timer (step S47). The control unit 31 compares the balance collected from terminal 2 stored in the temporary storage area (hereinafter referred to as the "collected balance") with the balance acquired from terminal 1 (hereinafter referred to as the "declared balance") and determines whether the declared balance is valid (step S48). The determination method will be described later. The control unit 31 determines whether to permit the payment based on the determination result (step S49). If the declared balance is valid and exceeds the payment amount, the control unit 31 determines that the payment is permitted; otherwise, it determines that the payment is not permitted. If the control unit 31 determines that the payment is permitted (YES in step S49), it performs the payment (step S50) and ends the process. If the device performing the payment is another device such as a POS register, it sends a payment instruction to that device. The payment instruction includes payment information (user ID, declared balance, payment amount, service code, etc.). If the control unit 31 determines that the payment is not permitted (NO in step S49), it outputs a message to that effect to the display panel 36 (step S51) and ends the process.

The determination process performed in step S48 is, for example, as follows: If all the values of the collected balances match and the declared balance matches or is less than that value, the control unit 31 determines that the declared balance is valid. If all the values of the collected balances do not match but the declared balance is less than the minimum value of the collected balance, the control unit 31 determines that the declared balance is valid. Furthermore, if all the values of the collected balances match and the declared balance exceeds that value, the control unit 31 determines that the declared balance is invalid. If all the values of the collected balances do not match and the declared balance exceeds the minimum value of the collected balance, the control unit 31 determines that the declared balance is invalid. Furthermore, if the number of collected balances is less than a specified number, it may be determined that validity cannot be determined, regardless of the value of the reported balance, and payment may not be permitted.

Figure 11 is a flowchart showing an example of the balance reply process. The balance reply process corresponds to the balance verification process and is executed by the polled terminal 2. The control unit 21 of the terminal 2 receives the polling signal sent by the store terminal 3 (step S61). The control unit 21 determines whether it holds balance information for the user whose user ID is included in the polling signal (step S62). The control unit 21 searches the other person's balance DB 232 stored in the auxiliary memory unit 23 using the received user ID as a key. If the polling signal contains a service code, the control unit 21 includes the received service code in the search conditions. If the search returns a hit, the control unit 21 determines that it holds the information. If the search does not return a hit, the control unit 21 determines that it does not hold the information. Even if the search returns a hit, the control unit 21 may determine that it does not hold the information if the date and time the balance information was updated or received is more than a predetermined time in the past, for example, more than three days ago. If the control unit 21 determines that it holds the user's balance information (YES in step S62), it sends the held balance information to the store terminal 3 (step S63) and ends the processing. If the control unit 21 determines that it does not hold the user's balance (NO in step S62), it ends the processing.

In disaster mode, if the first user is permitted to make a payment, the first user's balance after the payment is also distributed to the second user. That is, after executing step S50 in the balance verification process shown in FIG. 10, the store terminal 3 executes a process similar to the balance distribution process shown in FIG. 8. Correspondingly, the balance reception process shown in FIG. 9 is executed.

(StreetPass Network)
In order to increase the reliability of determining the legitimacy of a first user's balance, it is necessary to obtain balance information from a predetermined number of second users. The regular customer network aims to increase the probability of receiving balance information during normal times and the probability of returning balance information during a disaster by grouping regular customers of the same store. However, it is conceivable that the regular customer network alone will not be able to collect balance information from a sufficient number of second users during a disaster. Therefore, a StreetPass network is formed to complement the regular customer network. Any user of the balance verification system 100 can participate in the StreetPass network.

Figure 12 is a flowchart showing an example procedure for the other person's balance exchange process. The other person's balance exchange process is a process for exchanging other person's balance information between users of the balance verification system 100. In the following explanation, the terminal that initiates communication will be called the master, and the terminal with which the master communicates will be called the slave. For convenience of explanation, the master will be referred to as terminal 1 and the slave as terminal 2. The control unit 11 of the master performs polling (step S71). The control unit 21 of the slave receives the polling signal (step S72). The control unit 21 responds to the master (step S73). The control unit 21 includes information on whether or not the slave holds other person's balance in the response signal. The control unit 11 of the master receives the response (step S74). The control unit 11 determines whether or not to request other person's balance information (step S75). The control unit 11 determines whether or not the slave holds other person's balance information from the response signal. The control unit 11 determines to request the other person's balance information if the slave holds other person's balance information, and determines not to request the information if the slave does not hold other person's balance information. If the control unit 11 determines not to request other user's balance information (NO in step S75), the process proceeds to step S81. If the control unit 11 determines to request other user's balance information (YES in step S75), the control unit 11 sends a balance information request to the slave (step S76). The control unit 21 of the slave receives the request (step S77). The control unit 21 sends the other user's balance information stored in the other user's balance DB 232 to the master (step S78). Note that the transmitted other user's balance information cannot include the user's own balance information. The control unit 11 of the master receives the other user's balance information (step S79). The control unit 11 stores the other user's balance information in the other user's balance DB 132 (step S80). If the received other user's balance information includes balance information of a user already stored in the other user's balance DB 132, the control unit 11 retains the most recent balance date and time. Furthermore, when storing the received other user's balance information in the other user's balance DB 132, the reception date and time of the received other user's balance information is used instead of the current value. The control unit 11 determines whether it holds other person's balance information other than the other person's balance information received from the slave (step S81). If the control unit 11 determines that it holds other person's balance information other than the received other person's balance information (YES in step S81), it transmits the other person's balance information other than the received other person's balance information to the slave (step S82). The control unit 21 of the slave receives the other person's balance information (step S83). The control unit 21 stores the other person's balance information in the other person's balance DB 232 (step S84) and ends the processing. The selection and rejection of other person's balance information to be stored is the same as in the slave case. If the control unit 11 determines that it does not hold other person's balance information other than the received other person's balance information (NO in step S81), it transmits this information to the slave (step S85). If the control unit 21 of the slave receives a message indicating that the master does not hold other person's balance information (step S86), it ends the processing.

Terminals perform balance exchange processing at random time intervals. Whether a terminal becomes a master or slave in a balance exchange processing depends on the timing of sending or receiving polling. If both terminals attempting to exchange balances are in a master or slave state, the processing will not take place. To avoid this, it is desirable to perform the balance exchange processing randomly. In addition, to prevent repeated balance exchange processing between the same combination of terminals, it is desirable to keep a record of balance exchange processing for a predetermined period of time, and to prevent terminals that have recently performed a balance exchange processing from performing the processing again.

The reliability of other people's balance information spread via the StreetPass network is considered to be equivalent to the reliability of other people's balance information spread via the regular network. Therefore, even when operating the StreetPass network, the contents of the balance verification process and balance reply process in disaster mode are considered to be similar.

After switching to disaster mode, the first payment each user makes is verified using the balance information stored in normal mode, so reliability is high. However, reliability decreases in disaster mode. This is because communication with the payment system 4 is not possible in disaster mode, making it difficult to detect if a user tampers with the balance stored in their terminal. Furthermore, if a first user rewrites their own balance and spreads the rewritten balance via the StreetPass network, there is a risk that the store terminal 3 will determine that the first user's balance is legitimate based on the balance information from the StreetPass network. To avoid this situation, the following is implemented: A column for the source of balance information is provided in the other user's balance DB 132 of terminal 1 and the other user's balance DB 232 of terminal 2. The source column stores source information, indicating whether the other user's balance was obtained from the store terminal 3 or another user's terminal. Then, in the balance return process, the source information is included in the other user's balance information sent by terminal 2 to the store terminal 3. In the balance verification process performed by the store terminal 3, when determining whether the first user's balance is valid, if the declared balance matches or is only slightly different from the balance reported as having been obtained from another user's device and is larger than the balance reported as having been obtained from the store terminal 3, it is determined that the balance may have been tampered with and the payment is not permitted. By adopting this mechanism, the balance verification system 100 can accurately determine the validity of the user's balance even for payments made after switching to disaster mode.

In disaster mode, operation of the StreetPass network may be stopped. In other words, in disaster mode, the process of exchanging other people's balances is not executed. In disaster mode, post-payment user balance information is distributed only to the store terminal 3. This makes it possible to prevent users from tampering with their balances and disguising fraudulent balances as legitimate by distributing the results of the tampering over the StreetPass network.

(Mode switching)
In the balance verification system 100, it is important to switch from normal mode to disaster mode appropriately. This is because the electronic payment processing performed by the store terminal 3 differs between normal mode and disaster mode. It is desirable for the user to manually switch modes appropriately. The following describes how each device autonomously switches modes.

If a communication failure with the payment system 4 occurs, the store terminal 3 switches from normal mode to disaster mode. Since communication failure may occur for reasons other than a disaster, the store terminal 3 may switch to disaster mode after a predetermined time (e.g., one hour) has elapsed since the failure.

When store terminal 3, which has switched to disaster mode, communicates with terminals (terminal 1 and terminal 2), store terminal 3 will inquire about the terminal's mode at the beginning of the communication. If the terminal replies that it is operating in normal mode, communication and payment will be rejected. Furthermore, store terminal 3 may instruct the terminal to forcibly switch its mode to disaster mode. Store terminal 3 and the terminal will store the date and time when they switched to disaster mode (switching date and time).

(Other processing)
Processing other than that described above will now be described. FIG. 13 is a flowchart showing an example of the deletion processing procedure. The deletion processing is a processing performed by the terminal in normal mode. The deletion processing is a processing for deleting old other person's balance information. The following explanation will be given for the case where the deletion processing is performed by the terminal 1. The control unit 11 of the terminal 1 selects one record stored in the other person's balance DB 132 as the processing target (step S91). The control unit 11 compares the date and time in the date and time column of the selected record with the current date and time and determines whether the selected record is to be deleted (step S92). If a predetermined period (e.g., half a day to one day) or more has passed since the date and time of the selected record, the control unit 11 determines that the selected record is to be deleted. If the predetermined period has not passed since the date and time of the selected record, the control unit 11 determines that the selected record is not to be deleted. If the control unit 11 determines that the selected record is not to be deleted (NO in step S92), the control unit 11 proceeds to step S94. If the control unit 11 determines that the selected record is to be deleted (YES in step S92), the control unit 11 deletes the selected record (step S93). The control unit 11 determines whether or not there are any unprocessed records (step S94). If the control unit 11 determines that there are any unprocessed records (YES in step S94), the control unit 11 returns the process to step S91 and processes the unprocessed records. If the control unit 11 determines that there are no unprocessed records (NO in step S94), the control unit 11 ends the process. While the determination of whether or not to delete a record is based on the date and time stored in the date and time column, the date and time stored in the received date and time column may also be used. Only one of the dates and times may be used, or both dates and times may be used. The deletion process is repeatedly executed at a predetermined timing, such as once a day.

Figure 14 is a flowchart showing part of the balance reception process or the other person's balance exchange process. The process shown in Figure 14 is performed by the terminal with the aim of reducing the number of records in the other person's balance DB132, 232. When executing the process shown in Figure 14, it is executed between steps S24 and S25 in the balance reception process. It is also executed between steps S79 and S80 and between steps S83 and S84 in the other person's balance exchange process. The following explanation will explain the case where it is executed by the terminal 1. If the answer is YES in step S24, or after executing step S79 or step S83, the control unit 11 determines whether the capacity is exceeded (step S101). For example, the other person's balance DB132 has a maximum number of records, a maximum storage capacity, etc. set in advance. The control unit 11 references the maximum number of records, maximum storage capacity, etc. to determine whether new other person's balance information can be stored in the other person's balance DB132. If the new other person's balance information cannot be stored in the other person's balance DB132, the control unit 11 determines that the capacity is exceeded. If the new other person's balance information can be stored in the other person's balance DB 132, the control unit 11 determines that the capacity is not exceeded. If the control unit 11 determines that the capacity is exceeded (YES in step S101), the control unit 11 sorts the records in the other person's balance DB 132 in ascending order by the value in the balance column (step S102). The control unit 11 determines whether to delete the record in the other person's balance DB 132 (step S103). The control unit 11 determines whether the balance value of the other person's balance information to be stored is smaller than the minimum balance value in the other person's balance DB 132. For example, if the balance value of the other person's balance information to be stored is smaller than the maximum balance value in the other person's balance DB 132, the control unit 11 determines to delete the record in the other person's balance DB 132. However, if the balance value of the other person's balance information to be stored exceeds the maximum balance value in the other person's balance DB 132, the control unit 11 determines not to delete the record in the other person's balance DB 132. If the control unit 11 determines to delete the record from the other person's balance DB 132 (YES in step S103), it deletes the record with the maximum balance from the other person's balance DB 132 (step S104). If the control unit 11 determines that the capacity is not exceeded (NO in step S101) or determines not to delete the record from the other person's balance DB 132 (NO in step S103), it executes step S25, or step S80, step S84, or subsequent steps. Note that if there are multiple records of other person's balance information to be newly stored, the control unit 11 repeatedly executes step S103. Also, in step S101, the control unit 11 makes a determination taking into account the number of records to be newly stored. The reason for deleting the record with the maximum balance in step S104 is that the larger the balance, the higher the likelihood of making a purchase that exceeds the balance, and the smaller the balance, the lower the likelihood of making a purchase that exceeds the balance.

(Encryption of other people's balances)
The control program 2P is designed so that the first user's balance information stored in the terminal 2 cannot be accessed by the second user. However, to ensure confidentiality, the first user's balance information may be encrypted and stored in the other user's balance DB 232. For example, public key cryptography is used for encryption. In the balance distribution process, the control unit 31 of the store terminal 3 encrypts the first user's balance information using the public key of the balance verification system 100 and sends the encrypted balance information to the terminal 2. The control unit 21 of the terminal 2 receives the encrypted balance information and stores it in the other user's balance DB 232. Note that the first user's user ID is not encrypted. In the balance reply process, the control unit 21 associates the encrypted balance information with the specified user ID, reads it from the other user's balance DB 232, and sends it to the store terminal 3. In the balance verification process, the store terminal 3 decrypts the balance information using the private key of the balance verification system 100.

This embodiment provides the following advantages. By exchanging balances (charge balance, available balance) in electronic payment services immediately before a disaster occurs, users can mutually verify and guarantee their balances after the disaster occurs. Users can then accept electronic payments at the store terminal 3 and purchase goods and services even when the payment system 4 is not functioning. Meanwhile, the store only pays for goods and services from users whose balances are guaranteed to be valid. This reduces the risk of a request being rejected due to insufficient balance when a payment is requested after the payment system 4 is restored. Because the store terminal 3 determines whether to allow an electronic payment based solely on whether the balance has been fraudulently increased, it is possible to reduce the amount of data exchanged and the amount of battery power used compared to when data other than the balance (credit data such as transaction history, age, and occupation) is used for the determination.

(Post-recovery processing)
15 is a diagram illustrating an example of a transaction history DB stored in the store terminal. The transaction history DB 333 is stored in the auxiliary memory unit 33 of the store terminal 3. The transaction history DB 333 stores the history of electronic payments made in disaster mode. The transaction history DB 333 includes a service code column, a user ID column, a date and time column, a declared balance column, a guaranteed balance column, a result column, and a payment amount column. The service code column stores a code or ID that identifies the electronic payment service. The user ID column stores the user ID. The date and time column stores the date and time of the payment. The declared balance column stores the user's balance received from the user before the payment is made. The guaranteed balance column stores the user's balance determined by the balance verification process. The result column stores the determination result of whether the payment is possible. The payment amount column stores the payment amount. If the payment is not permitted, the value of the payment amount column is set to NULL or 0.

Figure 16 is an explanatory diagram showing an example of a transaction history DB stored by the terminal. Transaction history DB 134 is stored in the auxiliary memory unit 13 of terminal 1. Transaction history DB 134 stores the history of electronic payments made in disaster mode. A transaction history DB 234 similar to transaction history DB 134 is also stored in the auxiliary memory unit 23 of terminal 2. Transaction history DB 134 includes a store ID column, a service code column, a date and time column, a declared balance column, a result column, a payment amount column, and a balance column. The store ID column stores the store ID that can uniquely identify the store where the payment was made. The service code column stores a code or ID that identifies the electronic payment service. The date and time column stores the date and time of the payment. The declared balance column stores the balance sent to the store terminal 3 before the payment was made. The result column stores the result of whether the payment was allowed or not. The payment amount column stores the payment amount. If the payment is not allowed, the value of the payment amount column is set to NULL or 0. The balance column stores the amount after the payment.

Records are added to transaction history DB333 and transaction history DB134 after switching to disaster mode, and record addition stops when disaster mode ends. In addition to transaction history DB333 and transaction history DB134, terminals 1 and 2 and store terminal 3 also have a transaction history DB used in normal mode. Transaction history in disaster mode may be stored only in transaction history DB333 and transaction history DB134 and transferred to the transaction history DB used in normal mode after recovery, or it may be stored doubly in transaction history DB333 and transaction history DB134 and the transaction history DB used in normal mode.

Figure 17 is a flowchart showing an example of the recovery processing procedure. The payment system 4 requests the store terminal 3 for the transaction history during the period in disaster mode (step S111). The control unit 31 of the store terminal 3 receives the request (step S112). The control unit 31 transmits the transaction history stored in the transaction history DB 333 to the payment system 4 (step S113). The payment system 4 receives the transaction history (step S114). The payment system 4 stores the received transaction history (step S115). The payment system 4 determines whether it has completed receiving the transaction history from all store terminals 3 (step S116). If the payment system 4 determines that it has not completed receiving the transaction history (NO in step S116), it returns the process to step S114. If the payment system 4 determines that it has completed receiving the transaction history (YES in step S116), it extracts the users included in the stored transaction history (step S117). The payment system 4 requests the transaction history from the terminal 1 of the extracted user (step S118). Here, terminal 1 represents the user terminal. The control unit 11 of terminal 1 receives the request (step S119). The control unit 11 transmits the transaction history stored in the transaction history DB 134 to the payment system 4 (step S120). The payment system 4 receives the transaction history (step S121). The payment system 4 stores the received transaction history (step S122). The payment system 4 determines whether reception of the transaction history from the terminal 1 of all users extracted in S117 is complete (step S123). If the payment system 4 determines that reception of the transaction history is not complete (NO in step S123), the process returns to step S121. If the payment system 4 determines that reception of the transaction history is complete (YES in step S123), it verifies whether the transaction history received from the store terminal 3 and the transaction history received from terminal 1 are consistent (step S124). The payment system 4 executes settlement for the transaction history for which consistency has been confirmed (step S125). The payment system 4 transmits the result to the store terminal 3 and terminal 1 (step S126). The control unit 31 of the store terminal 3 receives the result (step S127). The control unit 31 returns the operating mode to normal mode (step S128) and ends the process. The control unit 11 of terminal 1 receives the result (step S129). The control unit 11 returns the operating mode to normal mode (step S130) and ends the process. The result transmitted from the payment system 4 may include the total amount of settled transactions and transaction history that was not settled due to data inconsistency. Furthermore, if unsettled transaction history is to be compensated for with non-life insurance, the payment system 4 may send the transaction history information to the non-life insurance company.

The balance verification system 100 utilizes the fact that the first user's balance decreases with each payment, and verifies the balance by determining whether the balance reported by the first user exceeds the first user's balance stored by the second user. Therefore, in disaster mode, the charge function that increases the balance is disabled for prepaid electronic payment services.

When the charge function is enabled, it is desirable to keep the maximum amount that can be charged at one time as small as possible. Furthermore, when determining the legitimacy of the declared balance, even if the declared balance exceeds the collected balance value that is being compared, if the difference is deemed small when taking into account the maximum chargeable amount, the balance can be determined to be valid and payment can be permitted. This is because after the balance is distributed, the charge balance or available amount may increase due to a charge.

(Use in vending machines)
The balance verification system 100 can also be configured as a vending machine that performs electronic payments. In the above-described embodiment, the balance distribution process and balance verification process performed by the store terminal 3 are performed by the vending machine. However, since vending machines are considered to be used by an unspecified number of people compared to stores, the balance distribution process does not determine whether a customer is a regular or not. The vending machine distributes balance information to any recipient.

(Expansion of the StreetPass network)
In the above-mentioned StreetPass network, balance information is exchanged between user terminals, but to allow more users to share their balances, an intermediary device is employed. For example, a communication device is attached to a traffic light or a utility pole to distribute and verify balance information. The communication device performs the other party balance exchange process shown in Figure 12 with the terminal as a master or slave. Note that since the communication device is assumed not to have its own balance information, it transmits all of its balance information to the terminal as other party balance information.

Figure 18 is a block diagram showing an example of the hardware configuration of a communication device. The communication device 5 includes a control unit 51, a main memory unit 52, an auxiliary memory unit 53, a communication unit 54, and a short-range communication unit 55. Each unit is connected by a bus B.

The control unit 51 has one or more arithmetic processing units such as a CPU, MPU, GPU, etc. The control unit 51 reads and executes a control program 5P (program, program product) stored in the auxiliary storage unit 53, thereby performing various information processing, control processing, etc., and realizing various functional units.

The main memory unit 52 is an SRAM, DRAM, flash memory, etc. The main memory unit 52 mainly temporarily stores data required by the control unit 51 to perform arithmetic processing.

The auxiliary memory unit 53 is a hard disk or SSD, etc., and stores the control program 5P and various DBs required for the control unit 51 to execute processing. The auxiliary memory unit 53 stores the balance DB 531. The record layout of the balance DB 531 is the same as the other person's balance DB 132 provided in the first terminal 1. The auxiliary memory unit 53 is separate from the communication device 5 and may be an external storage device connected externally.

The communication unit 54 communicates with the store terminal 3 and the like via the network N. The control unit 51 may use the communication unit 54 to download the control program 5P from another computer via the network N and store it in the auxiliary memory unit 53.

The short-range communication unit 55 performs communication in accordance with the NFC standard, Bluetooth (registered trademark) standard, infrared communication standard, Wi-Fi (registered trademark) standard, etc. The control unit 51 performs P2P communication with the terminal via the short-range communication unit 55.

Figure 19 is a flowchart showing an example of the balance exchange process. In Figure 19, the terminal may be either the first terminal 1 or the second terminal 2, but the following explanation will be based on the first terminal 1. The control unit 51 of the communication device 5 performs polling (step S141). The control unit 11 of the first terminal 1 receives the polling signal (step S142). The control unit 11 responds to the communication device 5 (step S143). The control unit 11 includes information on whether or not the first terminal 1 has a third party balance in the response signal. The control unit 51 of the communication device 5 receives the response (step S144). The control unit 51 determines whether or not to request third party balance information (step S145). The control unit 51 determines from the response signal whether or not the first terminal 1 has third party balance information. The control unit 11 determines to request the third party balance information if the response signal indicates that the first terminal 1 has the third party balance information, and determines not to request the third party balance information if the response signal indicates that the first terminal 1 does not have the third party balance information. If the control unit 51 determines not to request other users' balance information (NO in step S145), the process proceeds to step S152. If the control unit 51 determines to request other users' balance information (YES in step S145), the control unit 51 sends a balance information request to the first terminal 1 (step S146). The control unit 11 of the first terminal 1 receives the request (step S147). The control unit 11 sends the other users' balance information stored in the other users' balance DB 132 to the communication device 5 (step S148). Note that the user's own balance information cannot be included in the other users' balance information to be sent. The control unit 51 of the communication device 5 receives the other users' balance information (step S149). The control unit 51 compares the received other users' balance information with the balance information stored in the balance DB 531 using the user ID and discards the older balance information (step S150). The control unit 51 stores the other users' balance information in the balance DB 531 (step S151). When storing the received balance information in the balance DB 532, the reception date and time of the received balance information is used instead of the current value. The control unit 51 determines whether it has balance information to send to the first terminal 1 (step S152). The control unit 51 determines that it has balance information to send if it has any balance information other than the other person's balance information received from the first terminal 1, or if it has any balance information newer than the received other person's balance information. If the control unit 51 determines that it has balance information to send (YES in step S152), it selects the balance information to send (step S153). The control unit 51 sends the selected balance information to the first terminal 1 (step S154). The control unit 11 of the first terminal 1 receives the other person's balance information (step S155). The control unit 11 of the first terminal 1 stores the other person's balance information in the other person's balance DB 132 (step S156) and ends the process. If the control unit 51 determines that it does not have balance information to send (NO in step S152), it sends a message to that effect to the first terminal 1 (step S157). The control unit 11 of the first terminal 1 receives a message that the communication device 5 does not have balance information to send to others (step S158) and ends the process. Note that the communication device 5 may also receive the end user's balance information from the store terminal 3 and store it in the balance DB 531.

Figure 20 is a flowchart showing another example of the balance verification process. This balance verification process is performed in disaster mode, similar to the process shown in Figure 10. A first user visits a store and requests electronic payment to pay for a purchase. The control unit 11 of terminal 1 sends a payment request to the store terminal 3. The payment request includes the user ID, balance, and service code (optional, same below). The control unit 31 of the store terminal 3 receives the request (step S171). The control unit 31 sends a verification request to the communication device 5 (step S172). The verification request includes at least the user ID and balance. The control unit 51 of the communication device 5 receives the verification request (step S173). The control unit 51 performs polling (step S174). The signal sent as polling includes the user ID and service code of the first user. The control unit 51 starts an interval timer (step S175). The control unit 51 determines whether balance information has been received (step S176). If the control unit 51 determines that it has not received the balance information (NO in step S176), it proceeds to step S178. If the control unit 51 determines that it has received the balance information (YES in step S176), it stores the balance information in a temporary storage area provided in the auxiliary storage unit 53 or the like (step S177). The control unit 51 determines whether a timeout has occurred (step S178). If the control unit 51 determines that a timeout has not occurred (NO in step S178), it returns the process to step S176. If the control unit 51 determines that a timeout has occurred (YES in step S178), it stops the interval timer (step S179). The control unit 51 compares the collected balance stored in the temporary storage area with the declared balance, and determines whether the declared balance is valid and whether to permit the settlement (step S180). The determination method is the same as the method described above. If the declared balance is valid and exceeds the settlement amount, the control unit 51 determines that the settlement is permitted; otherwise, it determines that the settlement is not permitted. The control unit 51 sends the determination result to the store terminal 3 (step S181). The control unit 31 of the store terminal 3 receives the determination result (step S182). The control unit 31 determines whether the determination result is permission (step S183). If the control unit 31 determines that the determination result is permission (YES in step S183), the control unit 31 performs the payment (step S184) and ends the process. Note that if the device performing the payment is another device such as a POS register, a payment instruction is sent to that device. The payment instruction includes payment information (user ID, declared balance, payment amount, service code, etc.). If the control unit 31 determines that the determination result is permission not allowed (NO in step S183), a message to that effect is output to the display panel 36 (step S185) and the process ends.

(Expanding the network of regular customers)
In the above description, the distribution of balance information and the collection of verification information using the regular customer network are performed by the store terminal 3 via short-range wireless communication, which limits the geographical range in which distribution and collection are possible. Therefore, the range can be expanded by using a terminal other than the store terminal 3. For example, the above-mentioned communication device 5 may be attached to a traffic light, a utility pole, or the like to distribute balance information and collect verification information. The communication device 5 is installed in a location with high foot traffic and easily accessible for power. The communication device 5 can communicate with the store terminal 3, as well as the first terminal 1 and the second terminal 2 (user terminals). Communication between the communication device 5 and the store terminal 3 may be wired or wireless, but encrypted communication is desirable to prevent data tampering. Furthermore, communication between the communication device 5 and the first terminal 1 and the second terminal 2 is assumed to be encrypted short-range wireless communication, but is not limited to this.

The operation of the communication device 5 will now be described. In the balance distribution process shown in Figure 8, the store terminal 3 sends balance information (balance, user ID of the first user, and balance update date and time) to the communication device 5 and requests distribution. The communication device 5 distributes the balance information. At this time, polling may be performed as in Figure 8 to distribute balance information only to regular users, but to do so, the communication device must be equipped with the regular customer DB 331 provided in the store terminal 3. Alternatively, the communication device 5 must inquire of the store terminal 3 whether the responding user is a regular user. To conserve storage capacity in the communication device 5 or reduce the amount of communication between the communication device 5 and the store terminal 3, the distribution destination may not be limited to the terminals of regular users. In such cases, the communication device 5 distributes balance information without limiting the recipient. The communication device 5 may also repeatedly distribute the balance information until a predetermined time has elapsed.

The technical features (constituent elements) described in each embodiment can be combined with each other, and by combining them, new technical features can be formed.
The embodiments disclosed herein are to be considered as illustrative in all respects and not restrictive. The scope of the present invention is defined by the claims, not by the above meaning, and is intended to include all modifications within the meaning and scope of the claims.

The following additional notes are provided regarding the above embodiments.

(Appendix 13)
A user terminal, a terminal capable of communicating with the user terminal, and a computer capable of communicating with the user terminal,
acquiring verification information including identification information for identifying a first user, a balance, and a date and time from a terminal device of the first user;
outputting the acquired verification information to terminal devices of a plurality of other users different from the first user;
An information processing method characterized by performing processing to determine whether to permit payment based on verification information newly acquired from the terminal device of the first user at the time of payment by the first user and verification information acquired via short-range wireless communication from terminal devices of multiple other users.

(Appendix 14)
14. The information processing method according to claim 13, further comprising: performing a determination process when a communication failure occurs between a payment terminal installed in a facility and a server that performs payment.

100 Balance verification system 1 First terminal, terminal 11 Control unit 12 Main memory unit 13 Auxiliary memory unit 131 Balance DB
132 Other people's balance DB
133 User ID
134 Transaction history DB
14 Communication unit 15 Near field communication unit 16 Display panel 17 Operation unit 1P Control program 2 Second terminal, terminal 21 Control unit 22 Main memory unit 23 Auxiliary memory unit 231 Balance DB
232 Other people's balance DB
233 User ID
234 Transaction history DB
24 Communication unit 25 Near field communication unit 26 Display panel 27 Operation unit 2P Control program 3 Store terminal 31 Control unit 32 Main memory unit 33 Auxiliary memory unit 331 Regular customer DB
332 Balance DB
333 Transaction history DB
34 Communication unit 35 Near field communication unit 36 Display panel 37 Operation unit 3P Control program 4 Payment system 5 Communication device 51 Control unit 52 Main memory unit 53 Auxiliary memory unit 531 Balance DB
532 Balance DB
54 Communication unit 55 Short-range communication unit 5P Control program B Bus N Network

Claims (10)

A computer that can communicate with a payment terminal installed in the facility
acquiring verification information including identification information for identifying a first user, a balance, and a date and time from a terminal device of the first user;
outputting the acquired verification information to terminal devices of a plurality of other users different from the first user;
An information processing method characterized by performing a process of determining whether to permit payment based on verification information newly acquired from the terminal device of the first user at the time of payment by the first user and verification information of the first user acquired via short-range wireless communication from terminal devices of multiple other users. 2. The information processing method according to claim 1, further comprising: performing a determination process when a communication failure occurs between the payment terminal and a server that performs payment. 3. The information processing method according to claim 1, further comprising: identifying a regular user based on a frequency of visits to the facility; and acquiring verification information from a terminal device of the identified regular user. The information processing method according to any one of claims 1 to 3, further comprising identifying a regular user based on a frequency of visits to the facility, and outputting verification information of the first user to a terminal device of the identified regular user. The information processing method according to claim 4, characterized in that it is determined whether to allow payment based on verification information obtained from the terminal device of the regular user or verification information obtained from the terminal device of another user who has obtained verification information from the terminal device of the regular user via P2P. The information processing method according to claim 1 , wherein the terminal device erases the verification information at a predetermined timing. The information processing method according to claim 1 , further comprising determining that the payment is not permitted if the balance of the first user is higher than the balance acquired from the other user. The information processing method according to any one of claims 1 to 7, characterized in that it is determined that payment is permitted when the balance of the first user matches the balances obtained from the terminal devices of a predetermined number or more other users. an acquisition unit that acquires verification information including identification information for identifying a first user, a balance, and a date and time from a terminal device of the first user;
an output unit that outputs the acquired verification information to terminal devices of a plurality of other users different from the first user;
and a determination unit that determines whether to permit payment based on verification information newly acquired from the terminal device of the first user at the time of payment by the first user and verification information of the first user acquired via short-range wireless communication from terminal devices of multiple other users. A computer that can communicate with the payment terminal
acquiring verification information including identification information for identifying a first user, a balance, and a date and time from a terminal device of the first user;
outputting the acquired verification information to terminal devices of a plurality of other users different from the first user;
A computer program that executes a process to determine whether to permit a payment based on verification information newly acquired from the terminal device of the first user at the time of the payment by the first user and verification information of the first user acquired via short-range wireless communication from terminal devices of multiple other users.