Information processing program, terminal program, information processing apparatus, and information processing method

Abstract

To provide an information processing program, a terminal program, an information processing apparatus, and an information processing method that enable a settlement using an electronic check even when communication with a bank is impossible.SOLUTION: An information processing program causes a computer to perform the processes of: acquiring an issued electronic check on the mobile terminal of a payer; making a settlement using the acquired electronic check; storing the acquired electronic check; and transmitting the stored electronic check to a bank when communication with a bank becomes possible.SELECTED DRAWING: Figure 14

Description

Technical Field

[0001] The present invention relates to an information processing program, a terminal program, an information processing apparatus, and an information processing method for transmitting an electronic check used for settlement to a bank.

Background Art

[0002] With the progress of IT technology, the use of electronic checks, which are the digitalization of paper checks, has been proposed. For example, Patent Document 1 proposes an electronic check method capable of preventing fraud.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] However, conventional electronic checks are premised on the ability of the terminal that conducts settlement using the electronic check and the bank system that cashes the electronic check to communicate during settlement. Therefore, in the event of a disaster or other situation where the network does not function for an extended period, it is not possible to use electronic checks.

[0005] The present invention has been made in view of such a situation. Its object is to provide an information processing program, a terminal program, an information processing apparatus, and an information processing method that enable settlement using an electronic check even when communication with a bank is impossible.

Means for Solving the Problems

[0006] An information processing program according to an aspect of the present application causes a computer to execute a process of acquiring an electronic check issued by a payer's mobile terminal, performing a settlement using the acquired electronic check, storing the acquired electronic check, and transmitting the stored electronic check to a bank when communication with the bank becomes possible.

Effect of the Invention

[0007] In one aspect of the present application, it is possible to perform a settlement using an electronic check even when communication with the bank is impossible.

Brief Description of the Drawings

[0008]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Figure 15

Figure 16

Figure 17

Figure 18

Figure 19

Figure 20

Figure 21

Figure 22

Figure 23

Mode for Carrying Out the Invention

[0009] The following embodiments will be described with reference to the drawings. In the following description, an electronic signature uses public key cryptography. The public key cryptography uses, for example, the RSA cryptosystem, the DSA signature system, or the ECDSA signature system.

[0010] FIG. 1 is an explanatory diagram showing a configuration example of an electronic check system. The electronic check system 100 includes a user terminal 1 (mobile terminal), a POS terminal 2 (computer, information processing device), and a check server 3. The user terminal 1, the POS terminal 2, and the check server 3 are connected to each other communicably via a network N. In FIG. 1, only one user terminal 1 and one POS terminal 2 are shown, but two or more may be provided.

[0011] The user terminal 1 is a terminal used by end users, here ordinary consumers. Assume that the end user (payer) has already opened an account with a financial institution that requests the issuance of an electronic check. The user terminal 1 is composed of a smartphone, a tablet computer, etc. Figure 2 is a block diagram showing an example of the hardware configuration of the user terminal. The user terminal 1 includes a control unit 11, a main memory unit 12, an auxiliary storage unit 13, a communication unit 14, a display panel 15, and an operation unit 16. Each component is connected by a bus B.

[0012] The control unit 11 has one or more arithmetic processing devices such as a CPU (Central Processing Unit), an MPU (Micro-Processing Unit), and a GPU (Graphics Processing Unit). By reading and executing the control program 1P (program, program product, terminal program) stored in the auxiliary storage unit 13, the control unit 11 performs various information processing, control processing, etc., and realizes various functional units.

[0013] The main memory unit 12 is an SRAM (Static Random Access Memory), a DRAM (Dynamic Random Access Memory), a flash memory, etc. The main memory unit 12 mainly stores temporarily the data necessary for the control unit 11 to execute arithmetic processing.

[0014] The auxiliary storage unit 13 is a hard disk or an SSD (Solid State Drive), etc., and stores the control program 1P and various DBs (Databases) necessary for the control unit 11 to execute processing. The auxiliary storage unit 13 stores a check DB 131 and a secret key 132. The auxiliary storage unit 13 may be a separate external storage device externally connected to the user terminal 1.

[0015] The communication unit 14 communicates with the check server 3 via the network N. Also, 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.

[0016] The display panel 15 can be composed of a liquid crystal panel, an organic EL (Electro Luminescence) display, or the like. The operation unit 16 can be composed of, for example, a touch panel incorporated in the display panel 15, and a user can perform a predetermined operation on the display panel 15. Further, the operation unit 16 can perform operations on the software keyboard displayed on the display panel 15. Note that the operation unit 16 may also be a hardware keyboard, a mouse, or the like.

[0017] The POS terminal 2 is a terminal installed in a retail store or the like. The POS terminal 2 is composed of a POS (Point of sales) register, a tablet computer, or the like. FIG. 3 is a block diagram showing a hardware configuration example of the POS terminal. The POS terminal 2 includes a control unit 21, a main memory unit 22, an auxiliary storage unit 23, a communication unit 24, a display panel 25, an operation unit 26, and an input / output unit 27. Each component is connected by a bus B.

[0018] The control unit 21 has one or more arithmetic processing devices such as a CPU, an MPU, and a GPU. The control unit 21 provides various functions by reading and executing the control program 2P (program, program product, information processing program) stored in the auxiliary storage unit 23.

[0019] The main memory unit 22 is an SRAM, a DRAM, a flash memory, or the like. The main memory unit 22 mainly stores temporarily the data necessary for the control unit 21 to execute arithmetic processing.

[0020] The auxiliary storage unit 23 is a hard disk or an SSD, etc., and stores various data necessary for the control unit 21 to execute processing. The auxiliary storage unit 23 stores a check DB 231 and a key DB 232. The auxiliary storage unit 23 may be an external storage device externally connected separately from the POS terminal 2.

[0021] The communication unit 24 communicates with the check server 3 via the network N. Further, the control unit 21 may use the communication unit 24 to download the control program 2P from another computer via the network N or the like and store it in the auxiliary storage unit 23.

[0022] The display panel 25 can be composed of a liquid crystal panel, an organic EL (Electro Luminescence) display, or the like. The operation unit 26 can be composed of, for example, a touch panel incorporated in the display panel 25, and a store clerk can perform a predetermined operation on the display panel 25. Further, the operation unit 26 can perform an operation on a software keyboard displayed on the display panel 25. Note that the operation unit 26 may also be a hardware keyboard, a mouse, or the like.

[0023] The input / output unit 27 exchanges data with other devices. For example, the input / output unit 27 is a communication interface that performs serial communication. The input / output unit 27 performs wired communication according to the USB (Universal Serial Bus) standard or wireless communication according to the Bluetooth (registered trademark) standard. The input / output unit 27 acquires information on barcodes and two-dimensional codes read by the code reader CR.

[0024] The check server 3 is a computer operated by a financial institution that issues electronic checks to end users. The check server 3 is composed of a server computer, a workstation, a PC (Personal Computer), or the like. Further, the check server 3 may be composed of a multi-computer composed of a plurality of computers, a virtual machine virtually constructed by software, or a quantum computer. Furthermore, the functions of the check server 3 may be realized by a cloud service.

[0025] FIG. 4 is a block diagram showing an example of the hardware configuration of the check server. The check server 3 includes a control unit 31, a main storage unit 32, an auxiliary storage unit 33, a communication unit 34, and a reading unit 35. Each configuration is connected by a bus B.

[0026] The control unit 31 has an arithmetic processing unit such as one or more CPUs, MPUs, GPUs, etc. By reading and executing the control program 3P (program, program product) stored in the auxiliary storage unit 33, the control unit 31 provides various functions.

[0027] The main memory unit 32 is an SRAM, DRAM, flash memory, etc. The main memory unit 32 mainly stores temporarily the data necessary for the control unit 31 to execute arithmetic processing.

[0028] The auxiliary storage unit 33 is a hard disk or SSD, etc., and stores various data necessary for the control unit 31 to execute processing. The auxiliary storage unit 33 stores the secret key 331, the check - slip DB 332, and the cashing DB 333. The auxiliary storage unit 33 may be an external storage device externally connected separately from the check - slip server 3. Various DBs, etc. stored in the auxiliary storage unit 33 may be stored in a database server or cloud storage different from the check - slip server 3.

[0029] The communication unit 34 communicates with the user terminal 1 and the POS terminal 2 via the network N. Also, 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 storage unit 33.

[0030] The reading unit 35 reads a portable storage medium 3a including a CD (Compact Disc) - ROM and a DVD (Digital Versatile Disc) - ROM. The control unit 31 may read the control program 3P from the portable storage medium 3a via the reading unit 35 and store it in the auxiliary storage unit 33. Also, the control unit 31 may read the control program 3P from the semiconductor memory 3b.

[0031] Next, the data structure of the electronic check will be described. FIG. 5 is an explanatory diagram showing an example of the data structure of the electronic check. FIG. 5A shows the data structure of the electronic check issued by the bank. The electronic check includes a user ID, a check ID, a user name, an issue date and time, and an electronic signature. The user ID (drawer ID) is an ID that identifies the end user. The check ID is an ID that identifies the check. The user name is the name of the end user. The issue date and time is the date and time when the bank issued the check. The electronic signature is the signature of the bank that issued the check on the check.

[0032] FIG. 5B shows the data structure of the electronic check paid out by the end user. The electronic check is obtained by adding a payout date and time, a redemption deadline, a payout amount, and an electronic signature to the check issued by the bank. The payout date and time is the date and time when the end user pays out the electronic check. The redemption deadline is the deadline by which the electronic check can be redeemed. The payout amount is the amount set by the end user for the electronic check. The electronic signature is the signature of the end user on the electronic check to which the payout date and time, the redemption deadline, and the payout amount are added.

[0033] Next, the database used in the electronic check system 100 will be described. FIG. 6 is an explanatory diagram showing an example of a check DB. The check DB 131 is stored in the user terminal 1. The check DB 131 includes a user ID column, a check ID column, a user name column, an issue date and time column, an electronic signature column, a payout date and time column, a redemption deadline column, an amount column, a serial number column, and a destination column. The user ID column stores a user ID that can uniquely identify a user. For example, the user ID is the ID of the end user used when downloading the control program 1P to the user terminal 1. The check ID column stores a check ID that identifies a check. The check ID is assigned by the financial institution that issues the check. The user name column stores the name of the end user. The issue date and time column stores the date and time when the financial institution issued the check. The electronic signature column stores the electronic signature of the financial institution that issued the electronic check. The payout date and time column stores the date and time when the end user paid out the electronic check. The redemption deadline column stores the deadline by which the electronic check can be redeemed. The redemption deadline is set based on the payout date. The amount column stores the paid-out amount. The serial number column stores the serial number used for the electronic check. The destination column stores the recipient of the electronic check.

[0034] FIG. 7 is an explanatory diagram showing another example of a check DB. The check DB 231 is stored in the POS terminal 2. The check DB 231 includes a user ID column, a check ID column, a user name column, an issue date and time column, an electronic signature column, a payout date and time column, a redemption deadline column, an amount column, a receipt date and time column, a user signature column, and a status column. Since the user ID column, the check ID column, the user name column, the issue date and time column, the electronic signature column, the payout date and time column, and the redemption deadline column are the same as the corresponding columns in the check DB 131, the description thereof will be omitted. The amount column stores the payout amount of the electronic check. The receipt date and time column stores the date and time when the electronic check was received. The user signature column stores the signature of the end user. The status column stores the status of the electronic check. For example, the status is received, redeemed, etc. Received indicates the state where the check has been received but not redeemed. Redeemed indicates the state where the check has been sent to the financial institution and redeemed.

[0035] FIG. 8 is an explanatory diagram showing an example of a key DB. The key DB 232 is stored in the POS terminal 2. The key DB 232 stores the public keys of the end user and the financial institution. The key DB 232 includes a type column, a user ID column, a financial institution code column, and a public key column. The type column stores the type of the key. Here, the type indicates whether the public key is the key of the end user or the key of the financial institution. The user ID column stores the user ID of the end user when the public key is the key of the end user. The financial institution code column stores the financial institution code when the public key is the key of the financial institution. Note that an ID other than the financial institution code may be stored in the financial institution code column as long as the financial institution can be identified. In that case, the name of the financial institution code column may be another name. The public key column stores the entity of the public key.

[0036] FIG. 9 is an explanatory diagram showing another example of a check DB. The check DB 332 is stored in the check server 3. The check DB 332 includes a user ID column, a check ID column, a user name column, an issue date / time column, an electronic signature column, and a public key column. Since the user ID column, the check ID column, the user name column, and the issue date / time column are the same as the corresponding columns in the check DB 131, the description thereof is omitted. The electronic signature column stores the electronic signature for the electronic check. The public key column stores the public key of the end user.

[0037] FIG. 10 is an explanatory diagram showing an example of a cashing DB. The cashing DB 333 is stored in the check server 3. The cashing DB 333 stores check cashing information. The cashing DB 333 includes a user ID column, a check ID column, a payment date / time column, a destination column, a receipt date / time column, an amount column, and a date / time column. The user ID column stores the user ID of the end user who issued the check. The check ID column stores the check ID. The payment date / time column stores the payment date / time of the check. The destination column stores the name of the party to whom the check was issued, the name of the store where the POS terminal 2 that transmitted the electronic check to the check server 3 is installed, etc. The receipt date / time column stores the date / time when the financial institution received the check. The amount column stores the cashing amount. The date / time column stores the cashing date / time when the electronic check was cashed. For example, the cashing date / time is the point in time when the electronic check is transmitted from the POS terminal 2 to the check server 3 and the verification is successful (the electronic check can be confirmed as genuine) in the check server 3.

[0038] Next, the information processing performed by the electronic check system 100 will be described. FIG. 11 is a flowchart showing an example of the procedure for check issuance processing. In the conventional check mechanism, the check issuance processing corresponds to the procedure for purchasing a checkbook. The end user operates the user terminal 1 to request the issuance of a check. The control unit 11 of the user terminal 1 transmits the issuance request to the check server 3 (step S1). The issuance request includes the user ID. The control unit 31 of the check server 3 receives the issuance request (step S2). The control unit 31 issues a check (step S3). The control unit 31 assigns a check ID. The control unit 31 determines the current date and time as the issuance date and time. The control unit 31 determines the encashment deadline of the electronic check from the issuance date and time. The control unit 31 searches the customer DB (not shown) using the user ID as a key and acquires the user name. The control unit 31 generates an electronic check including the user ID, check ID, user name, and issuance date and time. The control unit 31 signs it (step S4). The control unit 31 electronically signs the generated electronic check using the private key 331. The control unit 31 associates the user ID, check ID, user name, issuance date and time, electronic signature, and the public key of the user and stores them in the check DB 332. The acquisition of the public key of the end user is possible by a known technique. Also, it is desirable to acquire the public key in advance. The control unit 31 transmits the electronically signed electronic check to the user terminal 1 (step S5). The control unit 11 of the user terminal 1 receives the electronic check (step S6). The control unit 11 verifies the electronic check (step S7). The control unit 11 decrypts the electronic signature attached to the electronic check using the public key of a financial institution acquired in advance. The control unit 11 compares the plain text excluding the electronic signature of the electronic check with the plain text obtained as the decryption result. The control unit 11 determines whether the verification was successful (step S8). The control unit 11 confirms that the plain text excluding the electronic signature of the electronic check matches the plain text obtained as the decryption result. The control unit 11 determines that the verification is successful if both plain texts match, and determines that the authentication fails if they do not match. When the control unit 11 determines that the verification was successful (YES in step S8), it stores the electronic check including the electronic signature of the financial institution in the check DB 131 (step S9).In the record stored at this time, in the payment date / time column, usage column, destination column, and amount column, NULL or 0 or an empty string indicating that the value is not set is set. The control unit 11 displays on the display panel 15 that the electronic check has been received (step S10) and ends the process. If the control unit 11 determines that the verification has failed (NO in step S8), it displays an error on the display panel 15 (step S11) and ends the process.

[0039] Figures 12 and 13 are flowcharts showing examples of payment processing procedures. When an end user makes a payment using an electronic check, by operating the user terminal 1 and selecting the payment menu of the electronic check, the payment process is activated. The end user inputs the payment amount and the destination into the user terminal 1. The control unit 11 of the user terminal 1 acquires the amount and the destination (step S21). The control unit 11 generates an electronic check to be paid and performs an electronic signature (step S22). The control unit 11 acquires the data of the electronic check stored in the check DB 131 (values from the user ID column to the electronic signature column), adds to it the payment date / time, the maturity date calculated from the payment date, and the payment amount, and signs it with the private key 132. The control unit 11 generates a two-dimensional code from the signed electronic check (step S23). The control unit 11 stores the payment date / time, maturity date, payment amount, serial number, and electronic signature in the check DB 131 (step S24). The control unit 11 displays the two-dimensional code on the display panel 15 (step S25).

[0040] The end user presents the two-dimensional code displayed on the display panel 15 to the store clerk of the store. The store clerk causes the code reader CR connected to the POS terminal 2 to read the two-dimensional code. The control unit 21 of the POS terminal 2 reads the two-dimensional code via the code reader CR (step S26). The control unit 21 verifies the electronic check obtained by analyzing the two-dimensional code (step S27). The control unit 11 decrypts the user's electronic signature attached to the electronic check with the public key of the user that has been previously acquired and stored in the key DB232. The control unit 21 compares the electronic check excluding the decrypted electronic signature of the electronic check with the electronic check obtained as the decryption result. Further, the control unit 21 decrypts the bank's electronic signature attached to the electronic check obtained with the user's public key with the public key of the bank stored in the key DB232. The control unit 21 compares the part excluding the bank's electronic signature with the electronic check obtained by decrypting with the bank's public key. The control unit 21 determines whether the verification has succeeded (step S28). If the contents of the two sets of electronic checks compared by the control unit 21 match, it determines that the verification is successful, and otherwise it determines that the verification has failed. When the control unit 21 determines that the verification has succeeded (YES in step S28), it displays that the settlement is completed (step S29). At this point, the store clerk may inform the end user that the settlement by the electronic check has been completed and deliver the purchased goods, etc. The control unit 21 stores the electronic check in the check DB231 (step S30). In the receipt date and time column of the check DB231, the current date and time is stored, and in the status column, receipt is stored. The control unit 21 determines whether it is possible to communicate with the check server 3 (step S31). The determination of whether communication is possible is performed, for example, as follows. It is determined by sending a ping (Packet Internet Groper) to the check server 3 and checking whether there is a response. It is determined by whether it is possible to log in to the check server 3 by ftp (file transfer protocol). It is determined by whether it is possible to establish a session with the check server 3 by Web API (Web Application Programming Interface). Before making these determinations, it may be determined by a flag set by the administrator of the POS terminal 2.For example, when the network outside the store such as the Internet is unavailable due to a large-scale disaster or the like, the determination based on the flag is efficient. When the control unit 21 determines that it can communicate with the check server 3 (YES in step S31), it transmits the electronic check to the check server 3 (step S32). The control unit 31 of the check server 3 receives the electronic check (step S33). The control unit 31 verifies the electronic check (step S34). Since this verification is the same as that in step S27, the description is omitted. Note that the electronic check transmitted from the POS terminal 2 to the check server 3 may be electronically signed with the private key of the store. In this case, the check server 3 performs verification using the electronic signature and public key of the store and verification using the electronic signature and public key of the user. Verification of the part issued by the check server 3 itself can be performed using an electronic signature, but it is also possible to compare the electronic check with the content stored in the check DB 332. Moving on to FIG. 13, the control unit 31 determines whether the authentication has been successful (step S35). When the control unit 31 determines that the authentication has been successful (YES in step S35), it performs a transfer (step S36). The control unit 31 withdraws the payment amount of the electronic check from the account of the payer of the electronic check and deposits it into the account of the store. This transfer process may be executed by another computer instead of the check server 3. The control unit 31 determines whether the transfer process has been successful (step S37). The failure of the transfer process is caused by, for example, the expiration of the cashing deadline or the insufficient balance of the end user's account. When the control unit 31 determines that the transfer process has been successful (YES in step S37), it stores the transfer details in the cashing DB 333 (step S38). The control unit 31 transmits the completion to the POS terminal 2 (step S39). The control unit 21 of the POS terminal 2 receives the completion (step S40). The control unit 21 stores "cashed" in the status column of the check DB 231 (step S41) and ends the process. When the control unit 31 determines that the authentication has failed (NO in step S35), or when it determines that the transfer process has failed (NO in step S37), it transmits an error to the POS terminal 2 (step S42). The control unit 31 includes the error type such as "authentication failed" or "transfer failed" in the content to be transmitted. The control unit 21 of the POS terminal 2 receives the error (step S43).The control unit 21 stores an error in the status column of the check DB 231 (step S41) and ends the process. In the case of a failed transfer, it may be treated as a dishonored check as in the case of a conventional check. If the control unit 21 determines that it cannot communicate with the check server 3 (NO in step S31), the process ends. If the control unit 21 determines that the verification has failed (NO in step S28), the control unit 21 displays the error on the display panel 25 (step S44). At this point, the store clerk may inform the end user that the payment by the electronic check was not successful and request a change in the payment method. The control unit 21 stores an authentication error in the status column of the check DB 231 (step S45) and ends the process.

[0041] In the payment process shown in FIGS. 12 and 13, the payment is completed when the verification of the electronic check is successful at the POS terminal 2, but the payment may be completed when the transfer process is successful.

[0042] Also, although the redemption deadline is not confirmed in the payment process, it may be confirmed. When the control unit 21 determines that the authentication is successful in step S28 (YES in step S28), the control unit 21 confirms the redemption deadline. When the redemption deadline has passed or when the number of days remaining until the redemption deadline is small, such as 1 day, the control unit 21 displays the error content as a redemption deadline error (step S44). The control unit 21 stores the error content in the status column of the check DB 231 (step S45) and ends the process. The actions that the store clerk can take thereafter are as described above.

[0043] In the payment process, the electronic check is sent from the POS terminal 2 to the check server 3 every time it is received, but it may be sent collectively in a daily batch process or the like. In this case, a process similar to the batch redemption process described later is executed periodically.

[0044] FIG. 14 is a flowchart showing an example of the procedure for lump-sum cashing processing. The lump-sum cashing processing is a process of collectively cashing a large number of uncashed e-checks stored in the POS terminal 2. For example, after a network failure has continued for several days or more due to a disaster or the like, and after the network has become widespread, the lump-sum cashing processing is executed. The POS terminal 2 activates the lump-sum cashing processing according to an instruction from a store clerk or the like, or by detecting the recovery of the network. The control unit 21 of the POS terminal 2 acquires one e-check whose status column is uncashed from among the e-checks stored in the check DB 231 (step S51). The control unit 21 transmits the acquired e-check to the check server 3 (step S52). The control unit 31 of the check server 3 receives the e-check (step S53). The control unit 31 performs verification (step S54). The control unit 31 determines whether the verification was successful (step S55). Since the verification and the determination of the verification result have been described above, the description is omitted. When the control unit 31 determines that the verification was successful (YES in step S55), it determines whether the e-check is within the cashing deadline (step S56). At this time, the period during which the network failure occurred is taken into consideration. If the date and time when the e-check was issued is after the occurrence of the failure and the number of days from the cashing deadline to the day when the lump-sum cashing processing is being performed is within a predetermined number of days, it is treated as being within the cashing deadline. When the control unit 31 determines that the e-check is within the cashing deadline (YES in step S56), it performs a transfer process (step S57). The control unit 31 determines whether the transfer process was successful (step S58). Since the transfer process and the determination of whether the process was successful have also been described above, the description is omitted. When the control unit 31 determines that the transfer process was successful (YES in step S58), it stores the transfer details in the cashing DB 333 (step S59). The control unit 31 transmits the completion to the POS terminal 2 (step S60). The control unit 21 of the POS terminal 2 receives the completion (step S61). The control unit 21 stores "cashed" in the status column of the check DB 231 (step S62).When the control unit 31 determines that the transfer process has failed (NO in step S58), when the control unit 31 determines that the electronic check is not within the encashment deadline (NO in step S56), or when the control unit 31 determines that the verification has failed (NO in step S55), it sends an error to the POS terminal 2 (step S63). The control unit 31 includes error types such as authentication failure, transfer failure, and expired encashment deadline in the content to be sent. The control unit 21 of the POS terminal 2 receives the error (step S64). The control unit 21 stores the error in the status column of the check DB 231 (step S62). The control unit 21 determines whether there is an unprocessed uncashed electronic check (step S65). When the control unit 21 determines that there is an unprocessed uncashed electronic check (YES in step S65), it returns the process to step S51 and processes the unprocessed uncashed electronic check. When the control unit 21 determines that there is no unprocessed uncashed electronic check (NO in step S65), it displays the processing result on the display panel 25 (step S66) and ends the process.

[0045] In this embodiment, as described above, even when the POS terminal 2 and the check server 3 cannot communicate, it is possible to perform settlement using an electronic check. As a result, when a batch cashing process is executed after recovery, the risk of non-payment increases, so a limit may be set on the payment amount. FIG. 15 is a flowchart showing another example of the payment process. The control unit 11 of the user terminal 1 activates the payment process by the operation of the end user. The control unit 11 determines whether or not a failure has occurred (step S81). For example, the control unit 11 determines whether or not a failure has occurred based on whether or not it can communicate with the check server 3. When the control unit 11 determines that a failure has occurred (YES in step S81), it determines whether or not a limit amount has been set (step S82). When the control unit 11 determines that the limit amount has been set (YES in step S82), the process proceeds to step S84. When the control unit 11 determines that the limit amount has not been set (NO in step S82), it sets the limit amount (step S83). For example, the control unit 11 extracts electronic checks for the past three months from the check DB 131, calculates the average payment amount per day, sets the calculated value as the limit amount per day, and stores it in the auxiliary storage unit 13. Also, the average amount of the payment amount per payment is calculated from the extracted electronic checks, and the calculated value is set as the limit amount per payment and stored in the auxiliary storage unit 13. The control unit 11 acquires the amount and destination input by the end user (step S84). The control unit 11 determines whether or not the amount is within the limit amount (step S85). For example, when the limit amount is set per payment, the control unit 11 determines based on the magnitude relationship between the limit amount and the acquired amount. When the limit amount is set per day, the control unit 11 determines based on the magnitude relationship between the total amount obtained by adding the acquired amount to the cumulative value of the payment amounts of the electronic checks paid out until that day and the limit amount. Note that the control unit 11 may update the cumulative value each time an electronic check is paid out and store it in the auxiliary storage unit 13. When the control unit 11 determines that the amount is not within the limit amount (NO in step S85), it displays an error on the display panel 15 (step S86) and returns the process to step S84. The maximum allowable payment amount may be displayed in the error display. When the control unit 11 determines that the amount is within the limit amount (YES in step S85), it performs signature (step S22).Since this process is the same as step S22 in FIG. 12, the same reference numerals are used and the description is omitted. When the control unit 11 determines that no failure has occurred (NO in step S81), it acquires the amount and destination input by the end user (step S21). Thereafter, the control unit 11 and the like execute the steps after step S22 in FIG. 12.

[0046] Subsequently, an example of the screen displayed on the user terminal 1 and the POS terminal 2 will be described. FIG. 16 is an explanatory diagram showing an example of a check payout screen. The check payout screen d01 is a screen displayed on the user terminal 1 when making a payment with an electronic check. The check payout screen d01 includes a user ID d011, a user name d012, a payout amount d013, a destination d014, a payout date and time d015, and a two-dimensional code d016. The user ID d011 indicates the user ID assigned to the end user. The user name d012 indicates the name of the end user. The payout amount d013 indicates the payout amount of the issued electronic check. The destination d014 indicates the destination of the electronic check. The payout date and time d015 indicates the payout date and time of the electronic check. The two-dimensional code d016 indicates the content of the electronic check as a two-dimensional code.

[0047] FIG. 17 is an explanatory diagram showing an example of a payment completion screen. The payment completion screen d02 is a screen displayed on the POS terminal 2 when the verification of the electronic check is successful. The payment completion screen d02 includes a user ID d021, a user name d022, a payment amount d023, a payment date and time d024, a result icon d025, a usage record d026, and a signature box d027. The user ID d021 indicates the user ID assigned to the end user. The user name d022 indicates the name of the end user. The payment amount d023 indicates the payment amount of the electronic check. The payment date and time d024 indicates the date and time when the electronic check was paid out. The result icon d025 indicates the authentication result of the electronic check. When the authentication is successful, for example, as shown in FIG. 17, a double circle is displayed. The usage record d026 indicates the number of times the end user has used the electronic check. The number of times can be calculated by referring to the check DB 231. The signature box d027 displays the signature of the end user. In the initial display, the signature box d027 is blank. After the payment completion screen d02 is displayed, the store clerk prompts the user to sign in the signature box d027, and the user signs. Note that it is not essential to have the user sign. In the case of an operation where no signature is required, the signature box d027 is not displayed.

[0048] The present embodiment has the following effects. Even when the POS terminal 2 and the check server 3 cannot communicate, it is possible to perform payment by electronic check. When the cause of the inability to communicate is due to a large-scale network failure, there is a high possibility that cashless payment cannot be used. Therefore, an end user who does not have cash on hand will have difficulty purchasing goods or services, but if an electronic check is used, it will be possible to purchase goods or services.

[0049] Furthermore, when the payment process is as shown in FIG. 15, when a failure occurs, a limit amount is set for the payment amount of the electronic check. Thereby, when the batch redemption process is executed after recovery, it is possible to suppress the generation of non-paying electronic checks.

[0050] In this embodiment, although it has been described that the destination to which the end user pays out the e-check is a store, it is not limited thereto. It may be paid out to other end users or various organizations (foundation, incorporated association, NPO corporation, unincorporated association, etc.).

[0051] (Management function) Next, the management function will be described. As an example of the management function for users, the e-check history display function will be described. The history display function is a function that enables the end user to confirm the paid-out e-checks. FIG. 18 is a flowchart showing an example of the procedure of the history display process. When the end user selects the issuance history menu from the menu displayed on the user terminal 1, the history display process is activated. The control unit 11 of the user terminal 1 transmits a status request for the e-check to the check server 3 (step S91). The status request includes the user ID. The control unit 31 of the check server 3 receives the status request (step S92). The control unit 31 searches the cashing DB 333 using the user ID as a key and extracts the cashing information (step S93). The control unit 31 transmits the cashing information in which the check ID is associated with the cashing date and time to the user terminal 1 (step S94). The control unit 11 of the user terminal 1 receives the cashing information (step S95). The control unit 11 sets the status of the checks stored in the check DB 131 based on the cashing information (step S96). The set status may be stored in the check DB 131, or may be stored in a temporary storage area provided in the main storage unit 12 or the auxiliary storage unit 13. The status of the checks not included in the cashing information is set as uncashed. The control unit 11 creates a history for display (step S97). The control unit 11 displays the history on the display panel 15 (step S98) and ends the process.

[0052] FIG. 19 is an explanatory diagram showing an example of a history display screen. The history display screen d03 displays the payout history of the e-checks. The history display screen d03 includes a check ID d031, an issue date and time d032, a destination d033, an amount d034, and a status d035. The check ID d031 indicates the check ID. The issue date and time d032 indicates the issue date and time of the e-check. The destination d033 indicates the destination of the e-check. The amount d034 indicates the amount paid out. The status d035 indicates the status of the e-check. When the e-check has already been cashed, the cashing date is displayed in the status d035. When the e-check has not yet been cashed, "not cashed" is displayed in the status d035.

[0053] Next, as an example of the management function for stores, the status display function of the received e-checks will be described. The status function is a function that enables confirmation of the status of the e-checks already acquired from the end user. FIG. 20 is a flowchart showing an example of the procedure of the status display process. When a store clerk selects the check list menu from the menu displayed on the POS terminal 2, the status display process is activated. The control unit 21 of the POS terminal 2 acquires the e-check from the check DB 231 (step S111). The control unit 21 creates a display screen for displaying the acquired e-check (step S112). The control unit 21 displays the created display screen on the display panel 25 (step S113), and ends the process.

[0054] FIG. 21 is an explanatory diagram showing an example of a status display screen. The status display screen d04 displays the status (cashing status) of the electronic check. The status display screen d04 includes a receipt date and time d041, a user name d042, and a payout amount d043. Further, the status display screen d04 includes a cashing deadline d044 and an uncashed display d045, or a cashed display d046, depending on the status of the electronic check. The receipt date and time d041 indicates the date and time when the electronic check was received. The user name d042 indicates the name of the user who issued the electronic check. The payout amount d043 indicates the payout amount of the electronic check. When the electronic check is uncashed, the cashing deadline d044 and the uncashed display d045 are displayed. The cashing deadline d044 indicates the cashing deadline of the electronic check. The uncashed display d045 indicates that the electronic check is uncashed. When the electronic check has been cashed, the cashed display d046 is displayed. The cashed display d046 includes the cashing date and a character string indicating that it has been cashed.

[0055] (Creditworthiness determination) When the store attempts to accept an electronic check, the creditworthiness of the electronic check to be accepted may be determined using the cashing record of the electronic check used by the end user. FIG. 22 is a flowchart showing an example of the procedure for creditworthiness determination processing. The control unit 21 of the POS terminal 2 acquires the cashing record of the end user who issued the electronic check (step S121). The control unit 21 searches the check DB 231 using the user ID included in the electronic check as a key, and acquires the cashing record of the end user, that is, the check data whose status column is cashed. The control unit 21 calculates the creditworthiness (step S122). For example, if the average amount obtained from the cashing record and the payout amount are close, the creditworthiness is increased, and if the difference between the two amounts is large, the creditworthiness is decreased. Also, the creditworthiness may be increased or decreased according to the number of times the electronic check is used. In the case of a new end user with no cashing record, the creditworthiness is set to an intermediate level.

[0056] FIG. 23 is a flowchart showing another example of the payment process. The process shown in FIG. 23 shows a part of the payment process and is a process added to the content of the payment process shown in FIGS. 12 and 13. In step S28 of FIG. 12, when the control unit 21 determines that the verification is successful (YES in step S28), a credit rating determination is performed (step S131). The credit rating determination is as shown in FIG. 22. The control unit 21 determines whether the credit rating obtained by the determination is equal to or higher than a predetermined threshold value (step S132). When the control unit 21 determines that the credit rating is equal to or higher than the threshold value (YES in step S132), the process proceeds to step S29 of FIG. 12. When the control unit 21 determines that the credit rating is less than the threshold value (NO in step S132), the credit rating is displayed on the display panel 25 (step S133). The store clerk checks the credit rating, determines whether to approve the settlement, and inputs the determination result through the operation unit 26. The control unit 21 receives the determination result (step S134). The control unit 21 determines whether to settle based on the determination result (step S135). When the control unit 21 determines to settle (YES in step S135), the process proceeds to step S29. When the control unit 21 determines not to settle (NO in step S135), the process proceeds to step S45.

[0057] By rejecting the acceptance of a check with a low credit rating, the store can reduce the risk that the received check will be dishonored. Especially in the event of a disaster or the like, when communication with the check server 3 is impossible and the check cannot be cashed immediately, reducing the dishonor risk is important for the store.

[0058] (Payment with the received check) In the above description, the check acquired by the store is assumed to be sent to the bank and cashed, but this is not the only case. It may be allowed for the payment check to circulate. That is, the store uses the uncashed check stored in the store's check DB 231 for payment.

[0059] When a store uses an electronic check for payment, the store electronically signs the electronic check to be used. The signed electronic check is converted into a two-dimensional code and presented to the payee. When the store makes a payment using an electronic check, depending on the transaction amount, it is possible to use multiple electronic checks. In this case, multiple electronic checks can be combined into one, and the store can electronically sign the combined electronic check, which may also be in the form of a two-dimensional code. For example, when 100 checks are combined, a transaction for the total amount of 100 checks can be made by reading the newly created two-dimensional code.

[0060] 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 this time should be considered as illustrative in all respects and not restrictive. The scope of the present invention is shown not by the above meaning but by the claims, and it is intended that all modifications within the meaning and scope equivalent to the claims are included. In addition, the claims use a format (multi-claim format) in which claims that cite two or more other claims are described, but it is not limited to this. A format in which a multi-claim (multi-multi-claim) that cites at least one multi-claim may be described.

Explanation of Signs

[0061] 100: Electronic check system 1: User terminal 11: Control unit 12: Main memory unit 13: Auxiliary storage unit 131: Check DB 132: Private key 14: Communication unit 15: Display panel 16: Operation unit 1P: Control program 2: POS terminal 21: Control unit 22: Main memory unit 23: Auxiliary storage unit 231: Check DB 232: Key DB 24: Communication unit 25: Display panel 26: Operation unit 27: Input / output unit 2P: Control program 3: Check server 31: Control unit 32: Main storage unit 33: Auxiliary storage unit 331: Secret key 332: Check DB 333: Cashing DB 34: Communication unit 35: Reading unit 3P: Control program 3a: Portable storage medium 3b: Semiconductor memory B: Bus CR: Code reader N: Network

Claims

1. Obtain an electronic check issued by the payer's mobile terminal, Perform settlement using the obtained electronic check, Store the obtained electronic check, When communication with the bank becomes possible, transmit the stored electronic check to the bank An information processing program for causing a computer to execute the process.

2. The electronic check is signed with the payer's electronic signature, and when it can be confirmed as genuine by the electronic signature, perform settlement The information processing program according to Claim 1.

3. Display a list of information on the obtained electronic check including the payer ID, amount, payment date and time, and cashing status associated with the payer The information processing program according to Claim 1 or Claim 2.

4. Issue an electronic check including the payer ID and amount associated with the payer, Display the issued electronic check A terminal program for causing a mobile terminal to execute the process.

5. Perform an electronic signature on the electronic check, Convert the signed electronic check into a two-dimensional code, Display the obtained two-dimensional code The terminal program according to Claim 4.

6. Display a list of information on the issued electronic check including the amount, payment date and time, and cashing status The terminal program according to Claim 4 or Claim 5.

7. An information processing apparatus provided with a control unit, The control unit, Obtain an electronic check issued by the payer's mobile terminal, Perform settlement using the obtained electronic check, Store the obtained electronic check, When communication with the bank becomes possible, transmit the stored electronic check to the bank An information processing apparatus that executes the process.

8. Obtain an electronic check issued by the payer's mobile terminal, Perform settlement using the obtained electronic check, Store the obtained electronic check, When communication with the bank becomes possible, transmit the stored electronic check to the bank An information processing method executed by a computer for the process.

Images