Information processing method, computer program, and information processing device

Abstract

To provide an information processing method or the like capable of securing accuracy of a balance by verification information stored in terminals of a plurality of users.SOLUTION: An information processing method causes a computer which can communicate with a settlement terminal provided in a facility to perform processing for: acquiring identification information for identifying a first user and verification information including a balance and date and time from a terminal device of the first user; outputting the acquired verification information to terminal devices of a plurality of users different from the first user; and determining whether or not to permit settlement on the basis of verification information newly acquired from the terminal device of the first user and verification information acquired via short-range radio communication from terminal devices of a plurality of other users when the first user performs settlement.SELECTED DRAWING: Figure 10

Description

[Technical Field]

[0001] The present invention relates to an information processing method and the like related to an electronic payment system. [Background technology]

[0002] Electronic payment systems, which allow users to pay for goods and services by electronic data transmission, are becoming increasingly common. However, there is a risk that the balance of the payment method used by the user may be tampered with. To address this issue, technologies have been proposed that verify the validity of payments online in real time.

[0003] Systems that require real-time communication with a server at the time of payment cannot be applied to offline payments at stores, etc., so a payment device that does not require real-time checks and can guarantee the legitimate use of electronic money has been proposed (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 includes a signature unit that generates a signature of the hash value and a secure element that protects the private key and the signature of the hash value. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Japanese Patent Application Laid-Open No. 2016-139291 Summary of the Invention [Problem to be solved by the invention]

[0005] However, when offline, the payment device performs payments based on its own balance. Therefore, 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 has been made in light of this situation. Its purpose is to provide an information processing method and the like that can ensure the accuracy of balances using verification information stored on the terminals of multiple users. [Means for solving the problem]

[0006] The information processing method disclosed in the present application is characterized in that a computer capable of communicating with a payment terminal installed in a facility acquires verification information including identification information, balance, and date and time for identifying a first user from the terminal device of the first user, outputs the acquired verification information to terminal devices of multiple other users different from the first user, and performs a process of determining whether to allow the payment based on the verification information newly acquired from the terminal device of the first user 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. [Effects of the Invention]

[0007] According to one aspect of the present invention, the accuracy of the balance can be guaranteed. [Brief explanation of the drawings]

[0008] [Figure 1] FIG. 1 is an explanatory diagram illustrating an example of the configuration of a balance verification system. [Figure 2] FIG. 2 is a block diagram showing an example of the hardware configuration of a first terminal. [Figure 3] FIG. 2 is a block diagram showing an example of the hardware configuration of a store terminal. [Figure 4] FIG. 10 is an explanatory diagram showing an example of a balance DB. [Figure 5] FIG. 10 is an explanatory diagram showing an example of a balance DB of other users. [Figure 6] FIG. 10 is an explanatory diagram illustrating an example of a regular customer DB. [Figure 7] FIG. 10 is an explanatory diagram showing an example of a balance DB. [Figure 8]10 is a flowchart illustrating an example of a procedure for a balance distribution process. [Figure 9] 10 is a flowchart illustrating an example of a procedure for a balance receiving process. [Figure 10] 10 is a flowchart illustrating an example of a procedure for a balance verification process. [Figure 11] 10 is a flowchart illustrating an example of a procedure for a balance return process. [Figure 12] 10 is a flowchart showing an example of a procedure for exchanging someone else's balance. [Figure 13] 10 is a flowchart illustrating an example of a procedure for a deletion process. [Figure 14] 10 is a flowchart showing a part of a balance receiving process or a balance exchanging process with another person. [Figure 15] FIG. 2 is an explanatory diagram showing an example of a transaction history DB stored in a store terminal. [Figure 16] FIG. 2 is an explanatory diagram showing an example of a transaction history DB stored in a terminal. [Figure 17] 10 is a flowchart illustrating an example of a recovery process procedure. [Figure 18] FIG. 2 is a block diagram illustrating an example of a hardware configuration of a communication device. [Figure 19] 10 is a flowchart illustrating an example of a procedure for a balance exchange process. [Figure 20] 10 is a flowchart illustrating another example of the procedure of the balance verification process. DETAILED DESCRIPTION OF THE INVENTION

[0009] Embodiments will be described below with reference to the drawings. FIG. 1 is an explanatory diagram showing an example of the 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 communicably 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 FIG. 1, only one first terminal 1 is shown, but two or more terminals may be used. Only two second terminals 2 are shown, but three or more terminals are preferred. One second terminal 2 is acceptable, but this is less preferred. Only one store terminal 3 is shown, but two or more terminals may be used.

[0010] The first terminal 1 is a terminal device used by a first user who is attempting to electronically pay for goods or the like at a store. The first terminal 1 may be a smartphone, tablet computer, laptop (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, etc. The first user and the second user are both users who use the balance verification system 100, and the distinction between the first user and the second user is not fixed. Each user is the first user when attempting to electronically pay for goods or the like, and the 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 at the same time.

[0011] The store terminal 3 is a terminal used by store staff at a store (facility). The store terminal 3 may be a smartphone, tablet computer, laptop (Personal Computer), or the like. The store terminal 3 has functions such as registering products and calculating the total price of the products, and may communicate with the payment system 4 to execute electronic payments. In this case, the store terminal 3 functions as a payment terminal. The 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 the event of a power outage after a disaster, it is desirable for the store terminal 3 to be configured as a battery-powered device. The payment system 4 is a system that provides electronic payment services.

[0012] 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.

[0013] The control unit 11 has one or more arithmetic processing devices such as a CPU (Central Processing Unit), an MPU (Micro-Processing Unit), a 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.

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

[0015] The auxiliary storage 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 storage unit 13 stores a balance DB 131, another person's 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 storage unit 13 is separate from the first terminal 1 and may be an external storage device connected externally.

[0016] 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 or the like, and store it in the auxiliary storage unit 13.

[0017] The short-range communication unit 15 performs communication in accordance with the NFC (Near Field Communication) standard, the Bluetooth (registered trademark) standard, the infrared communication (IrDA (Infrared Data Association)) standard, the Wi-Fi (registered trademark) standard, etc. The control unit 11 performs P2P (Peer to Peer) communication with the terminal via the short-range communication unit 15.

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

[0019] 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, and therefore will not be illustrated or described. In the following description, the first terminal will also be referred to as terminal 1, and the second terminal will also be referred to as terminal 2. The first terminal 1 and second terminal 2 will also be collectively referred to as terminals.

[0020] 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.

[0021] The control unit 31 has one or more arithmetic processing units such as a CPU, an MPU, a GPU, etc. The control unit 31 reads and executes a 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, an output unit, a determination unit, etc.

[0022] The main memory unit 32 is an SRAM, a DRAM, a flash memory, etc. The main memory unit 32 mainly temporarily stores data required for the control unit 11 to execute arithmetic processing.

[0023] The auxiliary storage 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 storage unit 33 stores a regular customer DB 331 and a balance DB 332. The auxiliary storage unit 33 may be separate from the store terminal 3 and may be an external storage device connected externally.

[0024] 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 or the like, and store it in the auxiliary storage unit 33.

[0025] The short-range communication unit 35 performs communication in accordance with the NFC standard, Bluetooth (registered trademark) standard, infrared communication standard, Wi-Fi standard, and the like.

[0026] The display panel 36 can be configured with a liquid crystal panel, an organic EL display, or the like. The operation unit 37 can be configured with, for example, a touch panel incorporated in the display panel 36, and allows the user to perform predetermined operations on the display panel 36. The operation unit 37 can also perform operations on a software keyboard displayed on the display panel 36. The operation unit 37 may also be a hardware keyboard, a mouse, or the like.

[0027] Next, the databases used in the balance verification system 100 will be described. FIG. 4 is an explanatory diagram showing an example of the balance DB. The balance DB 131 is a database provided in the terminal 1. The balance DB 131 stores the amount available for electronic payment, etc. The 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 stored in the balance column became the value stored therein. 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 DB 131 is constructed for each electronic payment service, or if the balance verification system 100 only allows one electronic payment service to be used by each user, the balance DB 131 does not need to include a service code column. Even if the corresponding electronic payment service can be identified from the value of the account ID, the service code string does not have to be included in the balance DB 131. The terminal 2 also includes a balance DB 231 similar to the balance DB 131.

[0028] FIG. 5 is an explanatory diagram showing an example of the other users' balance DB. The other users' balance DB132 is a database provided in the terminal 1. The other users' balance DB132 stores information such as the amount of money that other users can electronically pay. The other users' balance DB132 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 an electronic payment service. The balance column stores the amount of money that other users can electronically pay. The balance column, like the balance column in the balance DB131, 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 therein. In other words, the date and time column stores the date and time when other users most recently used an electronic payment service. The received date and time column stores the date and time when balance data for other users was received. Note that the received date and time column is not required. The terminal 2 also has a other users' balance DB232 similar to the other users' balance DB132. In the following description, the balance refers to either or both of the charge balance and the available amount.

[0029] FIG. 6 is an explanatory diagram showing an example of a regular customer DB. The regular customer DB 331 is a database provided in the store terminal 3. The regular customer DB 331 stores information about regular users at each store. The 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 FIG. 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 a store three or more times in three days is considered a regular. A user's store visit history can be created from electronic payments or point system usage history. It is also possible to use the purchase history stored in a POS register or a POS server that collectively manages POS data.

[0030] Figure 7 is an explanatory diagram showing an example of a balance DB. The balance DB 332 is a database provided in the store terminal 3. The balance DB 332 stores the balances of regular users. The 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 electronically pay. 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.

[0031] 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 a normal mode and a 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.

[0032] The balance of the first user 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.

[0033] In disaster mode, electronic payment processing is different. Suppose a first user wishes to purchase a product at a store using electronic payment. If a failure occurs in the network N or the electronic payment service, the payment cannot be made and the first user cannot purchase the product. 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.

[0034] In the balance verification system 100, in order to verify the balance of a first user more accurately and reliably, it is desirable that the balance collected from the second user 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 called a regular customer network. The processing of the balance verification system 100 using the regular customer network is described below.

[0035] (Normal mode) The following describes the processing performed by the balance verification system 100 in normal mode. FIG. 8 is a flowchart showing an example of the balance distribution processing procedure. The balance distribution processing 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 has visited the store (step S1). For example, the store terminal 3 obtains the balance when the first user makes an electronic payment when purchasing 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 a two-dimensional code installed in the store is read by the terminal 1, 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 has visited 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 refers to the regular customer DB 331 and determines 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 balance information of the first user to the terminal 2 of that user (step S6). The balance information is the balance plus the user ID of the first user and the date and time the balance was updated. The control unit 31 determines whether or not 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), it returns the process to step S4 and performs processing for the unprocessed user ID. If the control unit 31 determines that there is no user ID to be processed (NO in step S7), it ends the process. The balance information is also stored in the balance DB 332 of the store terminal 3.

[0036] In the balance distribution process, if the number of regular users who have transmitted their balances does not reach a predetermined number, the control unit 31 may repeat the processes from step S2 onwards until the number of regular users who have transmitted their balances reaches the predetermined number or a predetermined time has passed. Also, polling may not be performed in the balance distribution process. In this case, the control unit 31 generates and transmits 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 storage unit 23, 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.

[0037] FIG. 9 is a flowchart showing an example of the procedure for 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 storage unit 23 to the store terminal 3 (step S22). The control unit 21 starts an interval timer (step S23). The control unit 21 determines whether or not 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 or not a timeout has occurred (step S27). If the control unit 21 determines that the time has not expired (NO in step S27), the process returns to step S24. If the control unit 21 determines that the time has expired (YES in step S27), or after step S25, the control unit 21 stops the interval timer (step S26) and ends the process.

[0038] If polling is not performed in the balance distribution process, even if a packet is received as determined in step S24, if the destination is not the own terminal, the control unit 31 determines that the packet has not been received.

[0039] The balance information stored in the first terminal 1 used by the first user is distributed by the balance distribution process. The distributed balance information is stored in the second terminal 2 used by the second user by the balance reception process. As a result, in normal mode, the balance of the first user is also stored in the second terminal 2. As mentioned above, the first user also takes the position of the second user, and the second user also takes the position of the first user, so users belonging to the regular network will share balances with each other. 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 the balances they share will be kept up to date.

[0040] (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 procedure. The balance verification process is a process 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 the 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 user ID and service code of the first user. 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. When 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 or not a timeout has occurred (step S46). When the control unit 31 determines that the timeout has not occurred (NO in step S46), it returns the process to step S44. When the control unit 31 determines that the 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 or not the declared balance is valid (step S48). The determination method will be described later. The control unit 31 determines whether or not 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 on the display panel 36 (step S51), and ends the process.

[0041] The determination process performed in step S48 is, for example, as follows: If all the values ​​of the balance to be collected 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 balance to be collected do not match but the declared balance is less than the minimum value of the balance to be collected, the control unit 31 determines that the declared balance is valid. Furthermore, if all the values ​​of the balance to be collected 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 balance to be collected do not match and the declared balance exceeds the minimum value of the balance to be collected, the control unit 31 determines that the declared balance is invalid. Furthermore, if the number of the balance to be collected is less than a predetermined number, it may be determined that validity cannot be determined regardless of the value of the balance to be collected, and the settlement may not be permitted.

[0042] FIG. 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 or not it has 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 storage 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 the information is in the possession of the user. If the search does not return a hit, the control unit 21 determines that the information is not in the possession of the user. Even if the search returns a hit, the control unit 21 may determine that the information is not in the possession of the user if the date and time the balance information was updated or received is more than a predetermined time ago, for example, more than three days ago. If the control unit 21 determines that it has the user's balance information (YES in step S62), it transmits the held balance information to the store terminal 3 (step S63) and ends the process. If the control unit 21 determines that it does not have the user's balance (NO in step S62), it ends the process.

[0043] In the 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, the store terminal 3 executes step S50 in the balance verification process shown in Fig. 10, and then executes a process similar to the balance distribution process shown in Fig. 8. Correspondingly, the balance reception process shown in Fig. 9 is executed.

[0044] (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 receiving balance information in the event of 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 in the event of 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.

[0045] FIG. 12 is a flowchart showing an example of the 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 is called the master, and the terminal with which the master communicates is called the slave. For convenience of explanation, the master is called terminal 1 and the slave is called 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 has the 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 the other person's balance information (step S75). The control unit 11 determines whether or not the slave has the 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 has the other person's balance information, and determines not to request the other person's balance information if the slave does not have the other person's balance information. If the control unit 11 determines not to request other users' balance information (NO in step S75), it proceeds to step S81. If the control unit 11 determines to request other users' balance information (YES in step S75), it 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 users' balance information stored in the other users' balance DB 232 to the master (step S78). Note that it is not permitted for the user's own balance information to be included in the other users' balance information to be sent. The control unit 11 of the master receives the other users' balance information (step S79). The control unit 11 stores the other users' balance information in the other users' balance DB 132 (step S80). If the received other users' balance information includes balance information of a user already stored in the other users' balance DB 132, the control unit 11 keeps the most recent balance date and time. Furthermore, when storing the received other users' balance information in the other users' balance DB 132, the reception date and time of the received other users' balance information is used instead of the current value. The control unit 11 determines whether or not 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 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 case of the slave. 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 to the slave (step S85). If the control unit 21 of the slave receives a message that the master does not hold other person's balance information (step S86), it ends the processing.

[0046] Terminals perform balance exchange processing at random time intervals. In the balance exchange processing, whether a terminal becomes a master or a slave depends on the timing of sending or receiving polling. Since the processing will not be performed if both terminals attempting to exchange balances are in a master or slave state, it is desirable to perform the balance exchange processing randomly to avoid this as much as possible. Furthermore, 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 balance exchange processing again.

[0047] The reliability of other people's balance information spread by the StreetPass network is considered to be equivalent to the reliability of other people's balance information spread by the regular user 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.

[0048] 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 tampering with the balance stored in the terminal. Furthermore, if a first user rewrites their own balance and spreads the rewritten balance via the StreetPass network, the store terminal 3 may determine that the first user's balance is valid based on the balance information from the StreetPass network. To avoid this situation, the following is implemented. A balance information source column 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 other user's balance information sent from terminal 2 to the store terminal 3 includes the source information. 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 slightly different from the balance reported as having been obtained from another user's terminal 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 employing this mechanism, the balance verification system 100 can accurately determine the validity of the user balance even for the second or subsequent payments after switching to disaster mode.

[0049] In disaster mode, the 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, the user's balance information after payment is distributed only to the store terminal 3. This makes it possible to prevent a user from tampering with their balance and disguising an illegal balance as legitimate by distributing the tampered results over the StreetPass network.

[0050] (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 or the like to manually switch modes appropriately. The following describes the operation of each device to autonomously switch modes.

[0051] The store terminal 3 switches from normal mode to disaster mode when a communication failure occurs with the payment system 4. Since communication failure may occur for reasons other than a disaster, the store terminal 3 may switch to disaster mode when a predetermined time (for example, one hour) has elapsed since the failure.

[0052] When the store terminal 3 that has switched to disaster mode communicates with a terminal (terminal 1 and terminal 2), the store terminal 3 inquires about the terminal mode at the beginning of the communication. If the terminal replies that it is operating in normal mode, the store terminal 3 will refuse communication and payment. The store terminal 3 may also instruct the terminal to forcibly switch its mode to disaster mode. The store terminal 3 and the terminal will store the date and time when they switched to disaster mode (switching date and time).

[0053] (Other processing) Processing other than that described above will now be described. FIG. 13 is a flowchart showing an example of the procedure for deletion processing. The deletion processing is processing performed by the terminal in normal mode. The deletion processing is processing to delete old other people's balance information. The following explanation will be given of the case where it is performed by the terminal 1. The control unit 11 of the terminal 1 selects one record stored in the other people'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 (for example, 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 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 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 the processing at step S94. If the control unit 11 determines that the selected record is to be deleted (YES in step S92), it deletes the selected record (step S93). The control unit 11 determines whether or not there is an unprocessed record (step S94). If the control unit 11 determines that there is an unprocessed record (YES in step S94), it returns the process to step S91 and processes the unprocessed record. If the control unit 11 determines that there is no unprocessed record (NO in step S94), it ends the process. The determination of whether or not to delete is based on the date and time stored in the date and time column, but the date and time stored in the received date and time column may also be used. Either 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.

[0054] FIG. 14 is a flowchart showing a part of the balance receiving process or the other person's balance exchange process. The process shown in FIG. 14 is performed by the terminal with the aim of reducing the number of records in the other person's balance DB 132, 232. When the process shown in FIG. 14 is executed, it is executed between steps S24 and S25 in the balance receiving 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 be given for 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 DB 132 has a maximum number of records, a maximum storage capacity, etc. set in advance. The control unit 11 refers to the maximum number of records, the maximum storage capacity, etc. to determine whether new other person's balance information can be stored in the other person's balance DB 132. If the new other person's balance information cannot be stored in the other person's balance DB 132, 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 DB132, 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), it sorts the records in the other person's balance DB132 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 DB132 (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 DB132. 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 DB132, the control unit 11 determines to delete the record in the other person's balance DB132, and 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 DB132, the control unit 11 determines not to delete the record in the other person's balance DB132. When the control unit 11 determines to delete the record in the other person's balance DB 132 (YES in step S103), it deletes the record with the maximum balance in 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 if it determines that the records in the other person's balance DB 132 should not be deleted (NO in step S103), it executes step S25, or step S80, step S84, or subsequent steps. 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. In step S104, the record with the maximum balance is deleted because the larger the balance, the higher the possibility of making a purchase that exceeds the balance, and the smaller the balance, the lower the possibility of making a purchase that exceeds the balance.

[0055] (Encryption of other people's balances) The control program 2P is designed so that the balance information of the first user stored in the terminal 2 cannot be accessed by the second user. However, to ensure confidentiality, the balance information of the first user 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 balance information of the first user 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 user ID of the first user 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.

[0056] This embodiment has the following effects. By exchanging the balance (charge balance, available amount) in the electronic payment service immediately before the occurrence of a disaster, users can verify and guarantee the balances with each other after the disaster occurs. And even in a situation where the payment system 4 is not functioning, users can receive electronic payments at the store terminal 3 and purchase goods and services. On the other hand, in the store, only users whose balances are guaranteed to be legitimate can pay for goods and services by electronic payment. Thereby, after the payment system 4 is restored, when a payment amount is billed, it is possible to reduce the risk of the bill being rejected due to insufficient user balance. The determination of whether to permit electronic payment at the store terminal 3 is only a determination of whether the balance has not increased illegally, so compared with the case of making a determination using data other than the balance (credit data such as transaction history, age, occupation, etc.), it is possible to reduce the amount of data exchanged and the amount of battery used.

[0057] (Processing after restoration) The restoration process when the disaster is restored and the use of the payment system 4 becomes possible will be explained. First, the database used for the restoration process will be explained. FIG. 15 is an explanatory diagram showing an example of a transaction history DB stored in the store terminal. The transaction history DB 333 is stored in the auxiliary storage unit 33 of the store terminal 3. The transaction history DB 333 stores the history of electronic payments made in the 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 codes and IDs for specifying electronic payment services. The user ID column stores the user ID. The date and time column stores the date and time of payment. The declared balance column stores the user's balance received from the user before the payment is executed. 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. When the payment is not permitted, the value in the payment amount column is set to NULL or 0.

[0058] Figure 16 is an explanatory diagram showing an example of a transaction history DB stored by a 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 a 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 approved or not. The payment amount column stores the payment amount. If the payment is not approved, the value of the payment amount column is set to NULL or 0. The balance column stores the amount after the payment.

[0059] Records are added to transaction history DB333 and transaction history DB134 after switching to disaster mode, and the addition of records stops when disaster mode ends. In addition to transaction history DB333 and transaction history DB134, terminals 1 and 2 and store terminal 3 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 the transaction history may be stored doubly in transaction history DB333, transaction history DB134 and the transaction history DB used in normal mode.

[0060] FIG. 17 is a flowchart showing an example of the recovery process 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 received the transaction history from all store terminals 3 (step S116). If the payment system 4 determines that it has not received the transaction history (NO in step S116), it returns the process to step S114. If the payment system 4 determines that it has received 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 is used to represent the user's 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 it has completed receiving the transaction history from the terminal 1 of all users extracted in S117 (step S123). If the payment system 4 determines that it has not completed receiving the transaction history (NO in step S123), it returns the process 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 matches the transaction history received from terminal 1 (step S124). The payment system 4 executes the payment for the transaction history that is confirmed to match (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 processing. The control unit 11 of terminal 1 receives the result (step S129).The control unit 11 returns the operation mode to the normal mode (step S130) and ends the process. The results sent from the settlement system 4 may include the total amount of settled transactions and a history of transactions that were not settled due to data inconsistency. In addition, if the unsettled transaction history is to be compensated for by non-life insurance, the settlement system 4 may send the transaction history information to the non-life insurance company.

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

[0062] When the charge function is enabled, it is desirable to set the maximum amount that can be charged at one time as small as possible. Furthermore, even if the reported balance exceeds the collected balance value to be compared when determining the legitimacy of the reported balance, if the difference is considered 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 the charge balance or available amount may increase due to charging after the balance is distributed.

[0063] (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.

[0064] (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 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.

[0065] 18 is a block diagram showing an example of the hardware configuration of the communication device 5. 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 to another unit by a bus B.

[0066] The control unit 51 has one or more arithmetic processing devices such as a CPU, an MPU, a 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.

[0067] The main memory unit 52 is an SRAM, a DRAM, a flash memory, etc. The main memory unit 52 mainly temporarily stores data required for the control unit 51 to execute arithmetic processing.

[0068] The auxiliary storage 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 storage unit 53 stores a 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 storage unit 53 is separate from the communication device 5 and may be an external storage device connected externally.

[0069] 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 the like, and store it in the auxiliary storage unit 53.

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

[0071] FIG. 19 is a flowchart showing an example of the balance exchange process. In FIG. 19, the terminal may be either the first terminal 1 or the second terminal 2, but the following description will be given assuming it is 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 other person's balance is held 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 the other person's balance information (step S145). The control unit 51 determines whether or not the first terminal 1 holds the other person's balance information from the response signal. The control unit 11 determines to request the other person's balance information if the response signal indicates that the first terminal 1 holds the other person's balance information, and determines not to request the other person's balance information if the response signal indicates that the first terminal 1 does not hold the other person's balance information. If the control unit 51 determines not to request other people's balance information (NO in step S145), the process proceeds to step S152. If the control unit 51 determines to request other people's 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 other people's balance information stored in the other people's balance DB 132 to the communication device 5 (step S148). Note that the user's own balance information cannot be included in the other people's balance information to be sent. The control unit 51 of the communication device 5 receives the other people's balance information (step S149). The control unit 51 compares the received other people's 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 people's balance information in the balance DB 531 (step S151). When the received balance information is stored 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 or not it holds balance information to be sent to the first terminal 1 (step S152). If there is at least one piece of balance information other than the other person's balance information received from the first terminal 1, or at least one piece of balance information newer than the received other person's balance information, the control unit 51 determines that it holds balance information to be sent.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 receive the end user's balance information from the store terminal 3 and store it in the balance DB 531.

[0072] FIG. 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 FIG. 10. 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 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 or not 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 or not a timeout has occurred (step S178). If the control unit 51 determines that it has not timed out (NO in step S178), it returns the process to step S176. If the control unit 51 determines that it has timed out (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 or not the declared balance is valid and whether or not 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 it is permitted, and otherwise determines that it is not permitted. The control unit 51 transmits 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 or not (step S183).If the control unit 31 determines that the determination result is permission (YES in step S183), it performs the payment (step S184) 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 determination result is not permission (NO in step S183), it outputs a message to that effect to the display panel 36 (step S185) and ends the process.

[0073] (Expanding the network of regular customers) In the above description, the store terminal 3 distributes balance information and collects verification information using the regular customer network 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 or a utility pole to distribute balance information and collect verification information. The communication device 5 is preferably 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 it is desirable to use encrypted communication 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.

[0074] The operation of the communication device 5 will be described. In the balance distribution process shown in FIG. 8, the store terminal 3 transmits 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 FIG. 8 to distribute balance information only to regular users, but to do so, the communication device must be equipped with the regular user 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. In order to save the storage capacity of 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 terminal of a regular user. In such a case, the communication device 5 distributes the balance information without limiting the destination. Furthermore, the communication device 5 may repeatedly perform distribution until a predetermined time has elapsed.

[0075] 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.

[0076] The following additional notes are provided regarding the above-described embodiments.

[0077] (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; Determine whether to permit the 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 acquired via short-range wireless communication from the terminal devices of the other users. 2. An information processing method comprising:

[0078] (Appendix 14) Performs a judgment process when a communication failure occurs between the payment terminal installed at the facility and the server that handles the payment. 14. The information processing method according to claim 13, [Explanation of symbols]

[0079] 100 Balance Verification System 1 Terminal 1, terminal 11 Control section 12 Main memory 13 Auxiliary storage 131 Balance DB 132 Other people's balance DB 133 User ID 134 Transaction History DB 14 Communications Department 15 Near Field Communication Department 16 Display panel 17 Control section 1P control program 2 Second terminal, terminal 21 Control section 22 Main memory 23 Auxiliary storage 231 Balance DB 232 Other people's balance DB 233 User ID 234 Transaction History DB 24 Communications Department 25 Near Field Communication Department 26 Display panel 27 Control section 2P control program 3. Store terminal 31 Control Unit 32 Main memory 33 Auxiliary storage section 331 Regular DB 332 Balance DB 333 Transaction History DB 34 Communications Department 35 Near Field Communication Department 36 Display panel 37 Control section 3P control program 4. Payment System 5. Communication equipment 51 Control section 52 Main memory 53 Auxiliary storage section 531 Balance DB 532 Balance DB 54 Communications Department 55 Near Field Communication Department 5P control program B Bus N Network

Claims

1. 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; Determine whether to permit the 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 from the terminal devices of other users via short-range wireless communication.

2. An information processing method comprising:

2. When a communication failure occurs between the payment terminal and the server that performs the payment, a determination process is performed.

2. The information processing method according to claim 1,

3. A frequent user is identified based on the frequency of visits to the facility, and verification information is acquired from a terminal device of the identified frequent user.

3. The information processing method according to claim 1 or 2.

4. Identifying a regular user based on the frequency of visits to the facility, and outputting verification information of the first user to a terminal device of the identified regular user.

4. The information processing method according to claim 1, wherein the first and second inputs are input to the first and second inputs.

5. Determine whether to allow payment based on verification information acquired from the terminal device of the frequent user or verification information acquired from the terminal device of another user who has acquired verification information from the terminal device of the frequent user via P2P.

5. The information processing method according to claim 4.

6. The terminal device erases the verification information at a predetermined timing.

6. The information processing method according to claim 1, wherein:

7. If the balance of the first user is higher than the balance obtained from the other user, it is determined that the payment is not permitted.

7. The information processing method according to claim 1, wherein:

8. When the balance of the first user matches the balances acquired from the terminal devices of a predetermined number or more of other users, it is determined that the payment is permitted.

8. The information processing method according to claim 1, wherein:

9. 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; a determination unit that determines whether to permit the 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 from terminal devices of other users via short-range wireless communication; An information processing device comprising:

10. 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; Determine whether to permit the 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 from the terminal devices of other users via short-range wireless communication. A computer program characterized by causing a process to be executed.

Images